27 февраля 2010 г.

Brocade Persistent PID

В соответствии со стандартами 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. Естественно, использовать ее можно будет исключительно в рамках одного физического или логического коммутатора.

26 февраля 2010 г.

Тим Беренс-ли

Мой календарь подсказывает, что именно сегодня 26 февраля 19 лет назад известный ученый Тим Беренс-ли (Tim Berners-Lee), который общепризнанно считается "отцом Internet", представил коллегам в институте CERN свой первый прототип web-браузера. Я к своему стыду достаточно мало знал об этом выдающемся человеке и прочитал несколько его биографий. Что ж, надо отметить, что Тим презабавнейший дядька. Вот несколько интересных фактов.

Я всегда почему-то думал, что раз Тим "придумал" 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 здесь...

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 для предсказания динамики интенсивности заболевания гриппом в разных странах.

21 февраля 2010 г.

Переподписка в SAN - часть 2

Первая часть здесь...

С точки зрения оконечных устройств переподписка обычно рассматривается в следующих контекстах:
  • 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.

С точки зрения коммутатора переподписка обычно рассматривается в следующих контекстах:
  • Переподписка портов характеризует требования оконечных устройств к ресурсам соответствующих портов коммутатора. Она равна отношению 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.


Вторая часть здесь...