В соответствии со стандартами Fibre Channel, 24-битный адрес FCID оконечных устройств состоит из Domain ID (первые 8 бит) и Port ID (PID) (последние 16 бит, которые состоят из 8 бит Area ID и 8 бит Node ID). В коммутаторах Brocade, PID зависит от номера физического порта, к коротому подключены HBA и дисковые массивы. Поэтому при переключении в другой порт коммутатора всегда меняется FCID устройства, что, в свою очередь, требует перестройки путей в HP-UX и AIX (в свежих версиях этих ОС, вроде, эту проблему побороли).
И вот, наконец-то свершилось. Появилась замечательная возможность использования WWN-Based Persistent PID. Эта функциональность позволяет на этапе PLOGI гарантировать привязку PID оконечных устройств не к номеру порта, а к их уникальным WWN. Теперь у нас есть возможность подключать оптические кабели доступа к оконечным устройствам в любой порт коммутатора не влияя на их PID. Опция включается следующим образом:
Синтаксис команд прост и комментировать их я не буду.
Работать Persistent PID будет только с FOS версии 6.3 и только на коммутаторах DCX, DCX-4S, 5100 и 5300. Естественно, использовать ее можно будет исключительно в рамках одного физического или логического коммутатора.
27 февраля 2010 г.
26 февраля 2010 г.
Тим Беренс-ли
Мой календарь подсказывает, что именно сегодня 26 февраля 19 лет назад известный ученый Тим Беренс-ли (Tim Berners-Lee), который общепризнанно считается "отцом Internet", представил коллегам в институте CERN свой первый прототип web-браузера. Я к своему стыду достаточно мало знал об этом выдающемся человеке и прочитал несколько его биографий. Что ж, надо отметить, что Тим презабавнейший дядька. Вот несколько интересных фактов.
Я всегда почему-то думал, что раз Тим "придумал" Internet, то он обязательно должен быть американцем. Ан нет, он англичанин. Конечно, сейчас он живет в США (преподает в MIT), но переехал туда достаточно поздно (в 1994 г.), когда ему уже было под 40.
Когда он учился в Оксфордском университете, его лишили доступа к компьютеру лаборатории ядерной физики за то, что... он играл в игрушки. Правда, в каких-то биографиях указывается, что все-таки за "проведение хакерской атаки". Я лично с большей охотой верю первой версии...
Тим известен своей манерой очень быстро говорить. Так ли это, можно увидеть, например, на этом видео. Я особого криминала не узрел. Возможно стало сказываться благотворное влияние многолетнего опыта преподавания. Как бы то ни было, ходят байки, что когда Беренс-ли работал в CERN, некоторые его коллеги специально общались с ним только по-французски, надеясь таким образом снизить темп лавины его слов.
Тим считает, что в будущем понятие WWW (World Wide Web) будет заменено понятием GGG (Giant Global Graph). «Гигантский глобальный граф», звучит достаточно жутко... мне почему-то сразу представляется краб огромных размеров, захватывающий Вселенную. Похоже жена права, я параноик %)
Однажды, перед огромной аудиторией ему пришлось решать проблемы со своим компьютером. После того, как трудность была преодолена, он заявил: "Разве стоял бы я здесь перед вами, если бы оно и так работало как надо?".
"Если бы я знал тогда, сколько людей будут указывать URL,то не стал бы использовать в синтаксисе два слэша",- Тим Бернерс-Ли.
Я всегда почему-то думал, что раз Тим "придумал" Internet, то он обязательно должен быть американцем. Ан нет, он англичанин. Конечно, сейчас он живет в США (преподает в MIT), но переехал туда достаточно поздно (в 1994 г.), когда ему уже было под 40.
Когда он учился в Оксфордском университете, его лишили доступа к компьютеру лаборатории ядерной физики за то, что... он играл в игрушки. Правда, в каких-то биографиях указывается, что все-таки за "проведение хакерской атаки". Я лично с большей охотой верю первой версии...
Тим известен своей манерой очень быстро говорить. Так ли это, можно увидеть, например, на этом видео. Я особого криминала не узрел. Возможно стало сказываться благотворное влияние многолетнего опыта преподавания. Как бы то ни было, ходят байки, что когда Беренс-ли работал в CERN, некоторые его коллеги специально общались с ним только по-французски, надеясь таким образом снизить темп лавины его слов.
Тим считает, что в будущем понятие WWW (World Wide Web) будет заменено понятием GGG (Giant Global Graph). «Гигантский глобальный граф», звучит достаточно жутко... мне почему-то сразу представляется краб огромных размеров, захватывающий Вселенную. Похоже жена права, я параноик %)
Однажды, перед огромной аудиторией ему пришлось решать проблемы со своим компьютером. После того, как трудность была преодолена, он заявил: "Разве стоял бы я здесь перед вами, если бы оно и так работало как надо?".
"Если бы я знал тогда, сколько людей будут указывать URL,то не стал бы использовать в синтаксисе два слэша",- Тим Бернерс-Ли.
25 февраля 2010 г.
Утилизация каналов и локализация трафика в SAN
О переподписке SAN здесь...
Характеристикой текущего уровня нагрузки на канал является его утилизация. Мы уже обсуждали эту метрику в разделе Utilization. Напомню, что она определяется как процентное отношение текущего значения Bandwidth линка или агрегированного канала к его максимальной полосе пропускания. В качестве максимальной Bandwidth обычно берется теоретическая, а не экспериментальная величина. Например, для каналов 4Gbps она равна не ~360MB/s, а 400MB/s.
Приведу пример: сервер, загружающий 60MB/s линка 4Gbps, утилизирует его всего на 15% ( (60/400)*100% ). Как вы помните, оптимальным значением утилизации считается 72%. Это значение может быть изменено с учетом нагрузки в пиковые периоды или в расчете на ее значительное увеличение в ближайшем будущем.
Все производители коммутаторов для сетей SAN позволяют узнать текущее значение Bandwidth и оценить утилизацию каналов. Для получения расширенных отчетов о производительности часто необходимы дополнительные лицензии.
Для снижения уровня утилизации линков следует подключать оконечные устройства таким образом, чтобы количество каналов передачи было минимальным. В этом смысле идеальной является конфигурация, в которой весь трафик локализован внутри коммутаторов. Например, подключение HBAs и портов дисковых массивов, с которыми взаимодействует сервер, к одному FC коммутатору. Дополнительным преимуществом такой конфигурации также будет являться уменьшение количества коммутирующих элементов, через которые придется пройти данным. Это приведет к уменьшению задержек.
Более широко посмотрев на проблему, можно говорить о полезности локализации трафика внутри фабрик, как физических, так и виртуальных (Cisco VSANs и Brocade Virtual Fabrics).
В случае коммутаторов Brocade, мы имеем еще одну возможность локализации трафика внутри группы портов одного модуля ASIC. За подробностями отсылаю к многочисленным документам, непосредственно посвященным оптимизации сетей хранения.
К сожалению, в большинстве случаев локализовать весь трафик не удается. Это обычно связано либо с требованиями к географическому разнесению серверов и устройств хранения, либо просто с недостаточным количеством портов на отдельных коммутаторах. Иногда дисковые массивы и серверы намеренно подключаются к различным, логически выделенным именно для этих целей коммутаторам. Такой подход позволяет унифицировать правила подключения устройств разных типов и, соответственно, заметно упростить управление всей SAN.
О маршрутизации и агрегирование каналов в SAN здесь...
Характеристикой текущего уровня нагрузки на канал является его утилизация. Мы уже обсуждали эту метрику в разделе Utilization. Напомню, что она определяется как процентное отношение текущего значения Bandwidth линка или агрегированного канала к его максимальной полосе пропускания. В качестве максимальной Bandwidth обычно берется теоретическая, а не экспериментальная величина. Например, для каналов 4Gbps она равна не ~360MB/s, а 400MB/s.
Приведу пример: сервер, загружающий 60MB/s линка 4Gbps, утилизирует его всего на 15% ( (60/400)*100% ). Как вы помните, оптимальным значением утилизации считается 72%. Это значение может быть изменено с учетом нагрузки в пиковые периоды или в расчете на ее значительное увеличение в ближайшем будущем.
Все производители коммутаторов для сетей SAN позволяют узнать текущее значение Bandwidth и оценить утилизацию каналов. Для получения расширенных отчетов о производительности часто необходимы дополнительные лицензии.
Для снижения уровня утилизации линков следует подключать оконечные устройства таким образом, чтобы количество каналов передачи было минимальным. В этом смысле идеальной является конфигурация, в которой весь трафик локализован внутри коммутаторов. Например, подключение HBAs и портов дисковых массивов, с которыми взаимодействует сервер, к одному FC коммутатору. Дополнительным преимуществом такой конфигурации также будет являться уменьшение количества коммутирующих элементов, через которые придется пройти данным. Это приведет к уменьшению задержек.
Более широко посмотрев на проблему, можно говорить о полезности локализации трафика внутри фабрик, как физических, так и виртуальных (Cisco VSANs и Brocade Virtual Fabrics).
В случае коммутаторов Brocade, мы имеем еще одну возможность локализации трафика внутри группы портов одного модуля ASIC. За подробностями отсылаю к многочисленным документам, непосредственно посвященным оптимизации сетей хранения.
К сожалению, в большинстве случаев локализовать весь трафик не удается. Это обычно связано либо с требованиями к географическому разнесению серверов и устройств хранения, либо просто с недостаточным количеством портов на отдельных коммутаторах. Иногда дисковые массивы и серверы намеренно подключаются к различным, логически выделенным именно для этих целей коммутаторам. Такой подход позволяет унифицировать правила подключения устройств разных типов и, соответственно, заметно упростить управление всей SAN.
О маршрутизации и агрегирование каналов в SAN здесь...
22 февраля 2010 г.
О поисковых запросах и кризисе
Сегодня я случайно наткнулся на такую забавную штуку, как Google Trends и попробовал с ней немного поэкспериментировать.. Так как в данный момент моя сфера интересов в основном находится в стораджевом мире, я попробовал следующий запрос "netapp storage, hitachi storage, emc storage, ibm storage, hp storage". В итоге я получил такую картинку:
Как трактовать результаты? Ну, во первых, надо знать о том, что верхний график показывает количество поисковых запросов.Для удобства оценки я поставил нормировку результатов по минимальному графику. NetApp считается за 1. Остальные места распределились очень предсказуемо. Самым раскрученным брендом оказался HP. Понятно, что такие гигантские показатели достигнуты не только за счет запросов о системах хранения данных, но и, банально, о ближайших складах бумаги и картриджей. IBM сильно отстает от HP, но все же занимает почетную вторую строчку в рейтинге. И тоже не только за счет своих дисковых массивов. В общем, эксперимент не удался. Нужен какой-то более умный запрос, позволяющий более четко сфокусироваться на системах хранения данных. При этом он должен быть достаточно популярным. Так, запрос "HDS storage" обработан быть не может, т. к. "do not have enough search volume to show graphs". Я пока такого запроса не придумал.
Хорошо, давайте посмотрим на вендоров, которые работают только в сегменте хранения данных и исключим HP и IBM: "netapp|"Network appliance", emc|"emc corporation", hds|"hitachi data systems"".
Для чистоты эксперимента я включил как краткие, так и полные имена компаний, хотя, конечно, краткие генерят принципиально большее количество поисковых запросов.
Итак, как вы видите, результаты тоже достаточно предсказуемы. Чаще всего у Гугла интересуются компанией EMC. Количество запросов о NetApp и HDS приблизительно одинаково.
Нижний график показывает частоту упоминаний в масс-медиа. Прискорбно отметить, что HDS по этому параметру очевидный аутсайдер. Надо чаще хвастаться своими успехами.
Основным ньюз-мейкером остается EMC.
Запросы из России по поводу netapp, hds, emc не являются частыми. Зато интересно отметить, что наша Родина является лидером по запросам "hp storage". На втором месте Вьетнам... ;)
Конечно, к приведенным результатам стоит относится с большой долей скепсиса. Google Trends может только косвенно отражать реальную популярность того или иного бренда.
Ну и в заключение картинка с Google Finance. Похоже, что те, кто вещает об окончании кризиса отчасти говорят правду. По крайней мере, на сегодняшний момент финансовые показатели компаний достигли или даже превысили значения первой половины 2008 г. Хотя, к этому тоже стоит относиться с осторожностью.. ;)
Добавлено
Кстати, оказывается что Google Trends используется в проекте Google Flu для предсказания динамики интенсивности заболевания гриппом в разных странах.
Как трактовать результаты? Ну, во первых, надо знать о том, что верхний график показывает количество поисковых запросов.Для удобства оценки я поставил нормировку результатов по минимальному графику. NetApp считается за 1. Остальные места распределились очень предсказуемо. Самым раскрученным брендом оказался HP. Понятно, что такие гигантские показатели достигнуты не только за счет запросов о системах хранения данных, но и, банально, о ближайших складах бумаги и картриджей. IBM сильно отстает от HP, но все же занимает почетную вторую строчку в рейтинге. И тоже не только за счет своих дисковых массивов. В общем, эксперимент не удался. Нужен какой-то более умный запрос, позволяющий более четко сфокусироваться на системах хранения данных. При этом он должен быть достаточно популярным. Так, запрос "HDS storage" обработан быть не может, т. к. "do not have enough search volume to show graphs". Я пока такого запроса не придумал.
Хорошо, давайте посмотрим на вендоров, которые работают только в сегменте хранения данных и исключим HP и IBM: "netapp|"Network appliance", emc|"emc corporation", hds|"hitachi data systems"".
Для чистоты эксперимента я включил как краткие, так и полные имена компаний, хотя, конечно, краткие генерят принципиально большее количество поисковых запросов.
Итак, как вы видите, результаты тоже достаточно предсказуемы. Чаще всего у Гугла интересуются компанией EMC. Количество запросов о NetApp и HDS приблизительно одинаково.
Нижний график показывает частоту упоминаний в масс-медиа. Прискорбно отметить, что HDS по этому параметру очевидный аутсайдер. Надо чаще хвастаться своими успехами.
Основным ньюз-мейкером остается EMC.
Запросы из России по поводу netapp, hds, emc не являются частыми. Зато интересно отметить, что наша Родина является лидером по запросам "hp storage". На втором месте Вьетнам... ;)
Конечно, к приведенным результатам стоит относится с большой долей скепсиса. Google Trends может только косвенно отражать реальную популярность того или иного бренда.
Ну и в заключение картинка с Google Finance. Похоже, что те, кто вещает об окончании кризиса отчасти говорят правду. По крайней мере, на сегодняшний момент финансовые показатели компаний достигли или даже превысили значения первой половины 2008 г. Хотя, к этому тоже стоит относиться с осторожностью.. ;)
Добавлено
Кстати, оказывается что Google Trends используется в проекте Google Flu для предсказания динамики интенсивности заболевания гриппом в разных странах.
21 февраля 2010 г.
Переподписка в SAN - часть 2
Первая часть здесь...
С точки зрения оконечных устройств переподписка обычно рассматривается в следующих контекстах:
Максимальные значения Fan-out определяются ограничениями самого дискового массива. В конфигурациях с большим количеством серверов необходимо учитывать, что кроме Fan-out на порт дискового массива, существуют ограничения на количество подключений HBAs в расчете на каждую SP, а также на все хранилище. В таблице показаны значения Fan-out для дисковых массивов Clariion CX4 при использовании Flare различных версий.
Оптимальные значения этой метрики сильно зависят от нагрузки с серверов.
Максимальные значения Fan-in определяются ограничением самой HBA. Типичным значением является 4:1.
Fan-out и Fan-in обычно анализируются совместно с ISL oversubscription. Если Fan-out больше значения переподписки, то при возникновении проблем следует распределить нагрузку по большему количеству портов дискового массива. Если наоборот, значит необходимо добавить ISLs, переключить порты оконечных устройств, чтобы локализовать трафик или подключить порты дискового массива к платам с низким уровнем переподписки.
Очень важно понимать, что высокий уровень любой из вышеперечисленных метрик переподписки сам по себе не указывает на наличие каких-либо проблем в SAN. Он лишь является индикатором того, что соответствующие компоненты сети потенциально могут быть перегружены. Низкий уровень нагрузки оконечных устройств и локализация трафика в рамках самих коммутаторов, обсуждаемые в следующем разделе, позволяют без каких-либо проблем использовать сети SAN с высоким значением переподписки.
Об утилизация каналов и локализация трафика в SAN здесь...
С точки зрения оконечных устройств переподписка обычно рассматривается в следующих контекстах:
- Fan-out характеризует требования порта устройства хранения к соответствующим HBAs. Оно равно отношению суммы Transfer Rates всех HBAs, обменивающихся информацией с одним из портов дискового массива, к скорости этого порта. При использовании Dual или Quad HBAs, подключенные порты, конечно, необходимо учитывать индивидуально.
Максимальные значения Fan-out определяются ограничениями самого дискового массива. В конфигурациях с большим количеством серверов необходимо учитывать, что кроме Fan-out на порт дискового массива, существуют ограничения на количество подключений HBAs в расчете на каждую SP, а также на все хранилище. В таблице показаны значения Fan-out для дисковых массивов Clariion CX4 при использовании Flare различных версий.
Модель CX4 | Fan-out Flare R29/R28.7 | ||||
На FC порт | На 1Gbit/s iSCSI порт | На 10Gbit/s iSCSI порт | На SP | На весь массив | |
CX4-120 | 256/256 | 256/128 | 256/NA | 256/128 | 512/256 |
CX4-240 | 256/256 | 256/256 | 512/NA | 512/256 | 1024/512 |
CX4-480 | 256/256 | 256/256 | 1024/NA | 1024/256 | 2048/512 |
CX4-960 | 512/256 | 256/256 | 1024/NA | 4096/512 | 8192/1024 |
Оптимальные значения этой метрики сильно зависят от нагрузки с серверов.
- Fan-in характеризует требования HBA к соответствующим портам устройства хранения. Оно равно отношению суммы Transfer Rates портов дисковых массивов, обменивающихся информацией с одной из HBA, к скорости этой HBA.
Максимальные значения Fan-in определяются ограничением самой HBA. Типичным значением является 4:1.
Fan-out и Fan-in обычно анализируются совместно с ISL oversubscription. Если Fan-out больше значения переподписки, то при возникновении проблем следует распределить нагрузку по большему количеству портов дискового массива. Если наоборот, значит необходимо добавить ISLs, переключить порты оконечных устройств, чтобы локализовать трафик или подключить порты дискового массива к платам с низким уровнем переподписки.
Очень важно понимать, что высокий уровень любой из вышеперечисленных метрик переподписки сам по себе не указывает на наличие каких-либо проблем в SAN. Он лишь является индикатором того, что соответствующие компоненты сети потенциально могут быть перегружены. Низкий уровень нагрузки оконечных устройств и локализация трафика в рамках самих коммутаторов, обсуждаемые в следующем разделе, позволяют без каких-либо проблем использовать сети SAN с высоким значением переподписки.
Об утилизация каналов и локализация трафика в SAN здесь...
19 февраля 2010 г.
Переподписка в SAN - часть 1
При проектировании любого комплекса всегда требуется найти компромисс между его производительностью и стоимостью. Гарантированно высокое качество обслуживания потребует предоставления ресурсов, необходимых для обмена информацией на максимальной скорости между всеми устройствами в сети. Но в реальной жизни, уровень и продолжительность нагрузки различных оконечных устройств в SAN все время изменяется и достаточно редко достигает максимума. Поэтому знания или разумные предположения о требованиях к производительности передачи данных в сетях хранения, позволяют значительно уменьшить количество ресурсов и, тем самым, сократить стоимость решения.
Для описания меры занижение количества предоставляемых ресурсов используется термин переподписка (oversubscription). При анализе производительности передачи данных в сети хранения необходимо рассматривать максимальное, текущее и оптимальное значения oversubscription.
С точки зрения коммутатора переподписка обычно рассматривается в следующих контекстах:
Например, адаптер HBA 4Gbps, подключенный к порту коммутатора 2Gbps, имеет переподписку 2:1. Для такой конфигурации порт коммутатора может стать узким местом при нагрузке больше 180MB/s. Текущее значение переподписки портов обычно варьируется в диапазоне 2:1 – 1:4. Оптимальным вариантом, конечно, будет подключать устройства так, чтобы oversubscription была равна 1:1.
Например, рассмотрим 32-портовый коммутатор 4Gbps, соединенный с остальной фабрикой двумя 4Gbps ISL. К коммутатору подключено 16x 4Gbps устройств и 8x 2Gbps устройств. В этом случае максимальная переподписка ISL равна 15:1 ( (32-2)*4:(2*4) ). А текущее значение oversubscription будет равно 10:1 ( (16*4+8*2:(2*4) ).
Оптимальным уровнем переподписки ISL, который обычно закладывается при дизайне SAN, считается 6:1 - 12:1.
Вторая часть здесь...
Для описания меры занижение количества предоставляемых ресурсов используется термин переподписка (oversubscription). При анализе производительности передачи данных в сети хранения необходимо рассматривать максимальное, текущее и оптимальное значения oversubscription.
С точки зрения коммутатора переподписка обычно рассматривается в следующих контекстах:
- Переподписка портов характеризует требования оконечных устройств к ресурсам соответствующих портов коммутатора. Она равна отношению Transfer Rates портов устройства и коммутатора.
Например, адаптер HBA 4Gbps, подключенный к порту коммутатора 2Gbps, имеет переподписку 2:1. Для такой конфигурации порт коммутатора может стать узким местом при нагрузке больше 180MB/s. Текущее значение переподписки портов обычно варьируется в диапазоне 2:1 – 1:4. Оптимальным вариантом, конечно, будет подключать устройства так, чтобы oversubscription была равна 1:1.
Производитель | Коммутаторы и платы | Количество и тип портов | Количество FE портов в группе | Transfer Rate BE каналов группы портов | Oversubscription | ||||
1Gbps | 2Gbps | 4Gbps | 8Gbps | 10Gbps | |||||
Brocade | 200E | 16x 4Gbps | 16 | - | нет | нет | нет | - | - |
5000 | 32x 4Gbps | 32 | - | нет | нет | нет | - | - | |
4900 | 64x 4Gbps | 16 | 64Gbps | нет | нет | нет | - | - | |
7500 | 16x 4Gbps | 8 | 32Gbps | нет | нет | нет | - | - | |
FC4-16 | 16x 4Gbps | 16 | 64Gbps | нет | нет | нет | - | - | |
FC4-32 | 32x 4Gbps | 16 | 32Gbps | нет | нет | 2:01 | - | - | |
FC4-48 | 48x 4Gbps | 24 | 32Gbps | нет | 1,5:1 | 3:01 | - | - | |
FC4-16IP | 8x 4Gbps | 8 | 64Gbps | нет | нет | нет | - | - | |
FC4-18i | 16x 4Gbps | 8 | 32Gbps | нет | нет | нет | - | - | |
300E | 24x 4Gbps | 24 | - | нет | нет | нет | нет | - | |
5100 | 40x 4Gbps | 40 | - | нет | нет | нет | нет | - | |
5300 | 80x 4Gbps | 16 | 128Gbps | нет | нет | нет | нет | - | |
FC8-16 в 48K | 16x 8Gbps | 16 | 64Gbps | нет | нет | нет | 2:01 | - | |
FC8-32 в 48K | 32x 8Gbps | 16 | 32Gbps | нет | нет | 2:01 | 4:01 | - | |
FC8-48 в 48K | 48x 8Gbps | 24 | 32Gbps | нет | 1,5:1 | 3:01 | 6:01 | - | |
FC8-16 в DCX | 16x 8Gbps | 16 | 128Gbps | нет | нет | нет | нет | - | |
FC8-32 в DCX | 32x 8Gbps | 16 | 128Gbps | нет | нет | нет | нет | - | |
FC8-48 в DCX | 48x 8Gbps | 24 | 128Gbps | нет | нет | нет | 1,5:1 | - | |
FC10-6 | 6x 12.75Gbps | 3 | 32Gbps | - | - | - | - | нет | |
Cisco | MDS 9124 | 24x 4Gbps | 6 | 12.8 Gbps | нет | нет | 1,9:1 | - | - |
MDS 9222i | 18x 4Gbps | 6 | 12.8 Gbps | нет | нет | 1,9:1 | - | - | |
MDS 9134 | 32x 4Gbps / | 04.янв | 16Gbps | нет | нет | нет | - | нет | |
2x 12,75Gbps | |||||||||
DS-X9324-18K9 | 18x 4Gbps | 6 | 12.8 Gbps | нет | нет | 1,9:1 | - | - | |
DS-X9324-18FK9 | |||||||||
DS-X9124 | 24x 4Gbps | 6 | 12.8 Gbps | нет | нет | 1,9:1 | - | - | |
DS-X9148 | 48x 4Gbps | 12 | 12.8 Gbps | нет | 1,9:1 | 3,75:1 | - | - | |
DS-X9112 | 12x 4Gbps | 3 | 12.8 Gbps | нет | нет | нет | - | - | |
DS-X9224-96K9 | 24x 8Gbps | 3 | 12.8 Gbps | нет | нет | нет | 1,9:1 | - | |
DS-X9248-96K9 | 48x 8Gbps | 6 | 12.8 Gbps | нет | нет | 1,9:1 | 3,75:1 | - | |
DS-X9248-48K9 | 48x 8Gbps | 12 | 12.8 Gbps | нет | 1,9:1 | 3,75:1 | 7,5:1 | - | |
DS-X9704 | 4x 12,75Gbps | 1 | 12.8 Gbps | - | - | - | - | нет |
- Переподписка ISL характеризует требования оконечных устройств к ISLs коммутатора. Она равна отношению суммы Transfer Rates портов, к которым подключены оконечные устройства, к сумме скоростей всех портов ISL коммутатора.
Например, рассмотрим 32-портовый коммутатор 4Gbps, соединенный с остальной фабрикой двумя 4Gbps ISL. К коммутатору подключено 16x 4Gbps устройств и 8x 2Gbps устройств. В этом случае максимальная переподписка ISL равна 15:1 ( (32-2)*4:(2*4) ). А текущее значение oversubscription будет равно 10:1 ( (16*4+8*2:(2*4) ).
Оптимальным уровнем переподписки ISL, который обычно закладывается при дизайне SAN, считается 6:1 - 12:1.
Вторая часть здесь...
Подписаться на:
Сообщения (Atom)