HENGOO.RU

My new techie blog

noreply@blogger.com (Vasily Pantyukhin) — Thu, 20 Apr 2017 06:43:00 +0000

Теперь пишу здесь oldhenhut.com

Новые возможности Fibre Channel 16Gbps

noreply@blogger.com (Vasily Pantyukhin) — Tue, 02 Aug 2011 14:06:00 +0000

В конце прошлого года я попытался выдать военную тайну о новых функциях 16Gbps коммутаторов Brocade. Прошло пол года и в мае эти коммутаторы были наконец-то официально отрелизены. Пришло время более подробно разобраться, что из обещанного было реализовано и о каких новых функциях не говорили совсем. Пару месяцев назад я написал об этом статью и вот наконец-то ее хоть и в раздербаненном виде, но опубликовали здесь и здесь.
Мне все-таки больше нравится первоначальный вариант. Поэтому я решил поделиться с вами сокровенными знаниями в изначальном виде.

Иногда мне кажется, что чем точнее наука, тем более суеверными являются ученые. Вот взять Computer science и ИТ, как область ее прикладного применения.
Здесь гадания уже давно превратились в отдельный бизнес, дающий хлеб различным аналитикам, экспертам и, конечно, нашему брату журналисту. Существует масса глобальных и микро-предсказаний, куда будут двигаться технологии, когда потребитель увидит той или иной новый продукт или даже сбудутся ли гадания других гадалок (сколько копий поломано вокруг Закона Мура). Более того, иногда прогнозы становятся законами, уже не предсказывающими, а самостоятельно влияющими на всю индустрию.

Инфраструктура сетей хранения является одним из важнейших компонентов любого центра обработки данных. Поэтому потребитель особенно пристально следит за глобальными предсказаниями в этой области. Итак: “скорость передачи данных в SAN будет удваиваться каждые 3-4 года”.

Время пришло и наши ожидания сбылись. Компания Brocade объявила о выходе своих новых продуктов 16Gbps Fibre Channel. В чем же преимущество предложенных новых технологий и насколько они в данный момент востребованы потребителем? В этой статье я хочу порассуждать именно на эти темы. Причем наибольший акцент хотелось бы сделать не на количественных характеристиках: “быстрее, выше, сильнее”, это разумеется само собой, но не всегда является главным аргументом для приобретения новых продуктов, а на качественно новых их возможностях.

Коммутаторы 16Gbps построены на новых чипах ASIC шестого поколения, которые в продолжение старой традиции были названы Condor 3.

Характеристики	Поколение ASIC
Характеристики	1	2	3	4	5	6	7
Название ASIC	Stitch	Loom	Bloom, Bloom-II	Condor / Goldeneye	Condor 2 / Goldeneye 2	Condor 3	?
Количество портов ASIC	2	4	8	32 / 24	40 / 24	48
Год выхода	1997	1999	2001	2004	2008	2011	2014
Кол-во портов	2	4	8	32 / 24	40 / 24
Скорость передачи	1,063Gbps	1,063Gbps	2,126Gbps	4,252Gbps	8,5Gbps	14,025Gbps	28,05Gbps
Кодирование	8B/10B	8B/10B	8B/10B	8B/10B	8B/10B	64B/66B	64B/66B
Теоретическая максимальная пропускная способность	103 MB/s	103 MB/s	206 MB/s	412 MB/s	825 MB/s	1642 MB/s	3284 MB/s
Реальная максимальная пропускная способность	90 MB/s	95 MB/s	190 MB/s	380 MB/s	760 MB/s	1552 MB/s	3104 MB/s

Важной особенностью нового ASIC является использование не классического кодировании 8b/10b, применяемого во всех предыдущих реализациях протокола Fibre Channel, а более экономичного 64b/66b. Международный Комитет Технологических Стандартов T11 постановил, что теперь именно такой способ кодирования сигналов будет стандартом для всех новых протоколов передачи, включая 10G Ethernet и 16G Fibre Channel. Ведь это позволяет снизить накладные расходы на кодирование с 25% до 3%.

Означает ли смена схемы кодирования протокола, что существующие у Заказчиков устройства, работающие на 2,4 или 8Gbps, будет нельзя подключать к новым коммутаторам? Конечно можно, защита инвестиций потребителей является одним из важнейших приоритетов. Condor 3 полнофункционально работает с оконечными устройствами и коммутаторами предыдущих поколений. В этом случае будет использоваться старая схема кодирования 8b/10b .

ASIC Condor 3 может осуществлять коммутацию 420 млн. фреймов в секунду. HBA 16Gbps обеспечивают пропускную способность до 500 тыс. операций ввода вывода в сек. (IOPS) Только вдумайтесь в эти огромные числа! Задержки при коммутации внутри чипа ASIC составляют максимум 0,8мкс, а между различными ASIC – всего 2,4мкс. Напомню, что время ожидания считывания данных с жесткого диска минимум на три порядка больше.
Так что можно однозначно говорить, что инфраструктура сети передачи данных, построенная на современном оборудовании Brocade никогда не станет бутылочным горлышком, ограничивающим количество IOPS или увеличивающим время отклика транзакционных приложений.

Для обеспечения высокого уровня производительности передачи данных между значительно удаленными друг от друга площадками, входящими в катастрофоустойчивый комплекс хранения, чипы Condor 3 имеют более 8 тыс. входных буферов, поддерживающих работу групп из 16 или 24 портов (в 32 и 48-портовых платах соответственно). Для поддержки мультиплексирования трафика 16Gbps внутри каналов DWDM предусмотрен режим работы на скорости 10Gbps.
Специальный режим исправления ошибок FEC (Forward Error Correction) при передаче данных между портами коммутаторов, работающими на скорости 16 или 10Gbps, вносит минимальную задержку 0,4мкс.

Для обеспечения большей гибкости обеспечения качества уровней сервиса (Quality Of Services, QoS), количество Virtual Channels (VC) было увеличено до 40. Также появилась возможность обнаружения и восстановления потерянных буферных кредитов на уровне Virtual Channels. В ASIC Condor 2 такая функциональность работала только на уровне физических портов.

Чипы Condor 3 совместно с новой версией операционной среды FOS 7.0 предлагают несколько совершенно новых функциональных возможностей. Это компрессия данных при передаче между портами коммутаторов (между 16Gbps E-портами). Алгоритм McLZO, разработанный для достижения максимальной скорости упаковки и распаковки данных, позволяет добиться уровня компрессии 2:1. Данная функциональность особенно актуальна в SAN с узким каналом между удаленными площадками.

Для увеличения уровня безопасности при передаче данных на дальние расстояния совместно с компрессией можно использовать шифрование данных. Шифрование осуществляется аппаратным способом прямо “на лету”. Применяется крипто-стойкий алгоритм AES-GCM с 256bit ключами. Использование возможностей компрессии и шифрования данных вносит совсем незначительные задержку 6мкс. и потому совершенно не влияет на производительность передачи данных.

Как вы помните, в продуктах Brocade 8Gbps появилась новая возможность объединения до трех директоров DCX или DCX-4S в единую высокопроизводительную фабрику при помощи линков ICL (Inter-Chassis Links). Второе поколение ICL в коммутаторах 16Gbps развивает эту идею. И здесь изменения значительны. Во первых, появилась возможность выбора топологии подключения директоров друг к другу. В относительно простых конфигурациях лучшим решением является объединение до трех директоров в топологию “каждый с каждым” (mesh). В SAN, требующих большого количества портов для подключения оконечных устройств, возможна организация топологии “центр-периферия” (core-edge), объединяющая при помощи линков ICL до шести директоров.

Вместо коротких 2м. медных кабелей в новом решении будут использоваться оптические линки длиной до 50м. Модули QSFP (Quad SFP) работают с четырьмя линками 16Gbps, идущими к различным ASIC на платах CR (Core Routing blades). Для обеспечения производительности и отказоустойчивости между директорами возможно подключение по меньшей мере четырьмя ICL, что гарантирует минимальную скорость межкоммутаторных соединений 256Gbps. Транкинг позволяет объединить до 4 ICL в единый агрегированный канал, увеличивая не только общую производительность, но и отказоустойчивость соединения.
Применение в качестве соединений коммутаторов не классических каналов ISL (Inter-Switch Link), а линков ICL позволяет использовать порты директоров только для подключения оконечных устройств. В максимальной конфигурации, отказ от iSL позволяет подключить в SAN на треть (33%) больше портов серверов и дисковых массивов.

Для передачи на скорости 16Gbps, в новых коммутаторах, естественно, будут использоваться новые оптические модули SFP. И в них Brocade тоже реализовала несколько новых инновационных улучшений.
Скорость передачи возрастает за счет увеличения частоты очень коротких лазерных импульсов, Однако, в оптических каналах передачи существует модовая дисперсия, искажающая форму этих импульсов, растягивая их во времени. Идущие друг за другом импульсы начинают накладываться друг на друга и их уже не возможно однозначно детектировать. Именно по этой причине длина оптических кабелей ограничена. При удвоении скорости передачи с 4Gbps до 8Gbps в кабелях OM2, максимальная длина кабеля уменьшилась аж в 3 раза с 150м. до 50м.

Скорость передачи	Максимальная длина кабеля OM1	Максимальная длина кабеля OM2	Максимальная длина кабеля OM3	Максимальная длина кабеля OM4
1Gbps	300	500	860	-
2Gbps	150	300	500	-
4Gbps	50	150	380	400
8Gbps	21	50	150	190
16Gbps	15	35	100	125

В новых SFP 16Gbps используется специальная синхронизирующая схема CDR (Clock and Data Recovery). За счет нее при увеличении скорости передачи с 8Gbps до 16Gbps в кабелях OM3, ограничение максимальной длины кабеля уменьшилась всего лишь в 1,5 раза с 150м. до 100м. Brocade разработала технологию при которой размер и стоимость дополнительной схемы CDR стали достаточно малы и их реализация в SFP практически не влияет на цену модулей.

Переход на новые 16Gbps SFP позволяет на 25% уменьшить энергопотребление в расчете на переданный бит информации. Один порт 16Gbps потребляет всего 0,75Вт, в то время как для работы двух портов 8Gbps необходим 1Вт. Казалось бы различие совершенно незначительно, однако, в масштабах большого ЦОД такое снижение энергопотребления и соответствующее уменьшение тепловыделения позволит несколько снизить операционные затраты на поддержание работы комплекса. Соглашусь, этот параметр не является сколько-нибудь значимым в контексте принятия решения в пользу перехода на новую инфраструктуру 16Gbps, однако все-таки приятен в качестве дополнительного “бонуса”.

С увеличение скорости передачи данных даже небольшие дефекты кабелей или коннекторов становятся критичными. Новый диагностический режим работы портов (D_Ports) позволяет значительно ускорить процесс тестирования кабельной системы, а также поиска и устранения неисправностей в фабрике. Тесты работоспособности модулей SFP, измерения длины кабелей, а также замеры задержек передач и различных метрик производительности выполняются на индивидуальных портах и никак не влияют на работоспособность остальной фабрики. Новая версия FOS 7.0 позволяет запускать тесты как из командной строки, так и применяя графический интерфейс. Расширенные возможности аудита различных событий в логах RASlogs и Audit Logs позволят получать подробную информацию о происходящих в SAN событиях.

Теперь немного о новшествах в администрировании и управлении. И здесь наиболее ярко выделяется новость о появлении давно ожидаемой функциональности динамического выделения ресурсов в фабрике (Dynamic Fabric Provisioning, DFP). Она позволяет значительно ускорить и упростить процесс зонирования и LUN-маскирования новых серверов с 16Gbps HBA, а также избежать перенастройки SAN в случае замены оборудования.
Как это работает? Не обошлось, конечно, без виртуализации. Коммутаторы в фабрике генерируют список возможных виртуальных адресов FA-WWN (Fabric-Assigned Port World Wide Names). Один или несколько FA-WWN назначаются конкретным физически портам. Далее адреса FA-WWN можно использовать для зонирования в фабрике или настройки LUN-маскирования на дисковых массивах.

При подключении сервера к физическому порту коммутатора, его HBA в процессе соединения с фабрикой (FLOGI) получают и назначают себе в качестве WNN виртуальный FA-WWN. Так как все необходимые настройки были сделаны заранее, ресурсы хранения сразу становятся доступны серверу. При замене HBA, новая карта получит и будет работать со старым FA-WWN. Соответственно, никакой перенастройки SAN не понадобится.
Преимущества функциональности DFP в администрировании SAN особенно заметны при использовании в сетях с большим количеством блейд-серверов, коммутаторы которых работают в режиме AG (Acess Gateway).

Мы поговорили о различных замечательных технических новшествах. Однако, сами по себе они вряд ли кому-нибудь нужны. В чем же заключаются реальные преимущества использования продуктов 16Gbps в комплексах хранения?
Во первых, это, конечно, большая пропускная способность каналов передачи. Однако, здесь сразу следует оговориться. Производительность инфраструктуры SAN является важным фактором не для всех типов задач. Так, большинство OLTP баз данных или Web-приложений очень чувствительны к ограничениям количества операций ввода-вывода и задержкам передачи. В тоже время суммарные объемы генерируемых ими данных не велики и обычно не могут загрузить даже 4Gbps каналы. Очевидно, что переключение таких серверов на инфраструктуру 16Gbps с точки зрения производительности не даст ни каких преимуществ.

В тоже время существует ряд задач, которым уже тесно в рамках производительности каналов 8Gbps, используемых в настоящее время. Это, конечно, резервное копирование и восстановление данных, класс приложений, которые называют интеллектуальный анализ данных (data mining), а также задачи потоковой обработки данных, например, видео-потоков. Преимущества “широких” каналов 16Gbps очевидны также при миграции данных. Так для переноса 1TB информации теперь понадобится всего лишь 10 минут. Согласитесь, звучит впечатляюще!

Преимущества централизованного администрирования, управления и гибкой доставки приложений в последнее время сделали очень популярной идею использования инфраструктуры виртуальных рабочих мест (Virtual Desktop Infrastructure, VDI). Однако, одновременная загрузка огромного количества пользовательских сессий, например, в начале рабочего дня, создает колоссальную нагрузку на SAN. И здесь использование инфраструктуры 16Gbps может существенно снизить время ожидания и общую удовлетворенность пользователей.

Надо отметить, что количество задач, требовательных к полосе пропускания каналов передачи, неуклонно растет. Усиливающаяся популярность технологий виртуализации, увеличение многопоточности приложений, использование больших объемов памяти RAM, производительных шин PCIe 3.0 и накопителей flash позволяют обрабатывать и передавать огромные потоки данных, что в свою очередь, требует от сети хранения данных все большей и большей производительности.

Увеличение пропускной способности каналов позволяет объединять коммутаторы в сети с требуемым уровнем переподписки, но меньшим количеством ISL. Особенно это актуально для блейд-серверов в которых используются внутренние коммутаторы-лезвия. В центрах обработки данных с большим количеством коммутаторов и блейд-серверов переход части инфраструктуры на 16Gbps коммутаторы значительно упростит работу с кабельной системой в целом (то, что в английской терминологии называется cable management), а также процедуры поиска и устранения неисправностей в SAN. Меньшее количество требуемых портов снижает общую стоимость владения.

Новая продуктовая линейка Brocade включает в себя два директора DCX 8510-8 и 8510-4, коммутатор 6510 и адаптеры 1860, которые могут работать как 16Gbps HBA и как карты 10Gbps Ethernet CNA. Крупные производители оборудования уже поддержали инициативу постепенного перехода на новые 16Gbps технологии. Так, мировой лидер в производстве систем хранения компания EMC самой первой объявила о своей поддержке этих продуктов Brocade в рамках семейства Connectrix.

В начале статьи мы начали говорить о предсказаниях. На самом деле я лукавил, прогнозы в области ИТ в большинстве своем делаются не по расположению звезд и форме кофейной гущи, а на основе “дорожных карт” производителей оборудования и ПО, а также понимания реальных потребностей потребителей.
Воспользуюсь случаем и сделаю и свой собственный прогноз. В течении ближайшего года технологии FC 16Gbps органично займут свою нишу в эволюционном развитии сетей хранения данных. Однако старые технологии 4Gbps и 8Gbps свои позиции сдадут не сразу, а будут вытесняться постепенно с появлением новых задач и ростом нагрузки на каналы передачи данных.
Наступают интересные времена, активное продвижение конвергентных сетей начинает заметно теснить старый добрый Fibre Channel SAN. Актуальная на сегодня задача построения облачных инфраструктур в ближайшие несколько лет подтолкнет потребителей к построению гибридных сетей передачи и хранения данных, включающих в себя как классические FC, так и новые CEE технологии.

Уильям Шокли

noreply@blogger.com (Vasily Pantyukhin) — Sun, 05 Jun 2011 18:29:00 +0000

В истории науки много очень одиозных фигур. Уильям Шокли как раз такой. Он сумел прославится в двух своих ипостасях: с одной стороны как выдающийся ученый (помните из курса физики его транзистор?), а с другой стороны как популяризатор идей генетически определенного интеллектуального превосходства одних людей над другими. Причем, второй своей деятельностью он известен даже более, чем первой.

Ну что же, теорию поверяем экспериментом. Окружающий меня ворох электроники подтверждает тот факт, что принципы, заложенные в транзистор работают. А вот общение с моим старым приятелем, здоровеееенным таким черным уроженцем Тринидада, а последние 25 лет нативным Американцем, умницей с совершенно русской душой, расизму не способствует. Ну и оставим все это на совести товарища Шокли и просто посмотрим на его интересную биографию.

Уильям Брэдфорд Шокли (Shockley) родился в Лондоне (1910 г.), но в раннем детстве с семьей переехал в Калифорнию. Физикой заинтересовался под влиянием соседа, преподававшего сию науку в Станфордском университете. Школа, бакалавриат, аспирантура в знаменитом ныне MIT. Докторская диссертация по физике твердого тела. Здесь я отвлекусь, стукну себя пяткой в грудь и пустив скупую слезу вспомню, что тоже ФТТ заканчивал... но не там... и без аспирантур... и единственное, что помню из Физики, так EMC, как минимум в квадрате (на правах рекламы) ;)) .

В 1936 г. Шокли начинает работать в лаборатории телефонной компании Bell, где предложил план разработки твердотельных усилителей как альтернативы вакуумным электронным лампам. Однако, в то время с соответствующими материалами было туго и его идея не осуществилась.

Во время второй мировой войны Уильям Шокли работает над военными проектами, в частности над электроникой полевой радарной станции. Позже он участвует в исследованиях противолодочных операций, решая такие задачи, как разработка оптимальных схем сбрасывания глубинных бомб при охоте за подводными лодками и выбор времени и целей для бомбардировочной авиации.

По окончании войны Шокли возвращается в Bell Labs в качестве директора программы исследований по физике твердого тела. К тому времени наиболее важными и распространенными электронными устройствами были усилительные лампы. Однако срок их службы был достаточно коротким, для подогрева катодов требовался дополнительный расход энергии, а сами хрупкие стекляшки занимали много места. Группа Шокли надеялись преодолеть эти недостатки, надеясь найти способ использования полупроводниковых элементов.
Уже через 2 года они достигли первого успеха, построив транзистор на основе германия. А идея замены точечных контактов выпрямляющими переходами между областями p- и n-типа в том же кристалле, привела к появлению плоскостного транзистора.

В 1956г. Шокли и два других члена его исследовательской группы Бардин и Браттейн за свою работу были удостоены Нобелевской премии. На церемонии презентации член Шведской королевской академии наук Рудберг назвал их достижение «образцом предвидения, остроумия и настойчивости в достижении цели».

После ухода из Bell Labs Шокли создает свою собственную компанию Shockley Semiconductor Laboratory. Он часто говорил, что главной целью является сделать миллион долларов, по тем временам огромнейшие деньги. У Шокли была идея, как удешевить транзисторы. Всего-то надо было научится делать их не из дорогого германия, а из очень дешевого кремния.
Расположить новую компанию решили в Калифорнии в маленьком городке Маунтин-Вью. Причин для этого было две: во-первых, недалеко оттуда жила мать Шокли, а во-вторых, Стэнфордский университет владел землей в Маунтин-Вью и предоставлял её инновационным компаниям на очень выгодных условиях. Предприятие, занимавшееся кремниевыми полупроводниками, стало первым в местечке, которое чуть позднее получило неофициальное название Кремниевая долина (многие предпочитают называть ее Силиконовой, так, конечно, не грамотно, но зато намного приятнее на ощупь :) ).

В общем Шокли чувствовал, что находится в нужном месте и в нужное время на переднем крае истории. Осталось только найти подходящих людей. И здесь педант вовсе не хотел полагаться на случайности. Он пытался, но так и не смог привлечь в свою компанию своих бывших сотрудников из Bell Labs. В итоге он сформировал группу из молодых специалистов по электронике, недавно окончивших американские университеты.

Однако отбор претендентов был очень жесткий. Цитата из книжки "Как сдвинуть гору Фудзи?":
"В тот день он интервьюировал Джима Гиббонса - молодого парня лет двадцати с небольшим. Гиббонc уже защитил докторскую диссертацию в Стэнфорде. Он также учился в Кембридже, так как выиграл Фулбрайтовскую стипендию. Все это происходило во временном офисе Шокли - ангаре из гофрированного железа. Гиббонс и Шокли уселись друг напротив друга, Шокли взял секундомер и задал первый вопрос.

В теннисном турнире сто двадцать семь участников, - размеренно произнес он. - В первом туре сто двадцать шесть игроков составят шестьдесят три пары, победители которых выйдут в следующий тур, и еще один игрок выходит во второй тур без игры. В
следующем туре - шестьдесят четыре игрока сыграют тридцать два матча. Сколько всего матчей понадобится, чтобы определить победителя?
Шокли включил секундомер. Прошло меньше минуты, и Гиббонс ответил: «Сто двадцать шесть». «Как вы догадались? - спросил Шокли. - Вы знали ответ заранее?»

Гиббонс просто объяснил, что каждый игрок перед тем, как его выбьют из турнира, должен сыграть хотя бы один матч. Для того чтобы определить победителя, 126 игроков должны проиграть, следовательно, понадобится именно 126 матчей.
Шокли чуть не сорвался от раздражения: именно таким способом он сам решил эту задачу, сказал он Гиббонсу. Гиббонс почувствовал, что Шокли не нравится, когда другие с такой легкостью могут использовать «его» метод.

Шокли сообщил условия следующей задачи и снова включил секундомер. Эта задача оказалась для Гиббонса более трудной. Он обдумывал ее уже довольно долго и не находил ответа. Гиббонc заметил, что с каждой минутой атмосфера становилось менее напряженной.
Шокли, у которого его быстрый ответ на первую задачу вызвал раздражение, теперь расслабился, как человек, комфортно расположившийся в теплой ванне. Наконец Шокли остановил секундомер и сказал, что на решение второй задачи Гиббонc уже потратил вдвое больше времени, чем сотрудники его лаборатории в среднем. Он заявил это с заметным удовлетворением. Гиббонc был принят на работу."

Надо отметить, что многим сотрудникам не нравился такой высокомерный и даже параноидальный стиль управления Шокли. Известен случай, когда его секретарь порезала палец, и он чтобы найти виновного заставил всех сотрудников компании пройти проверку на детекторе лжи. Позднее все-таки выяснилось, что секретарь сама нечаянно порезалась канцелярской кнопкой.

Решение Шокли прекратить перспективные исследования в области кремниевых полупроводников для сотрудников стало последней каплей. Восемь молодых сотрудников, которую назвали «вероломной восьмеркой» предложила главному инвестору компании Бекману заменить Шокли на профессионального менеджера. Бекман отказался. Тогда парни уволились и основали свою собственную компанию Fairchild Semiconductor (все еще существует). Кстати, среди отщепенцев были знаменитые ныне основатели Intel Гордон Мур и Роберт Нойс.
С уходом восьмерки, Shockley Semiconductor Laboratory потеряла большую часть своих лучших сотрудников; через несколько месяцев закрылась.

В 1963 г. Шокли стал преподавать в Станфордском университете. Там он серьезно заинтересовался идеями улучшения общества, которые в итоге вызвали горячие споры среди ученых-генетиков. Шокли утверждал, что человечеству угрожает своего рода «ухудшение породы», поскольку у людей с более низким коэффициентом умственного развития рождается больше детей, чем у людей с высоким IQ.
Многие его высказывания были очень резкими и одиозными. Так, он прочел целую серию лекций, в которых призывал к стерилизации малообеспеченных негритянок. Шокли неоднократно публично заявлял о том, что несколько порций его спермы хранится в специальном банке спермы, созданным для искусственного оплодотворения высокоинтеллектуальных женщин семенем лауреатов Нобелевской премии для появления на свет сверходаренных детей.

Шокли два раза. был женат. Второй раз, кстати, на медицинской сестре по уходу за псих-больными. В молодые годы он был заядлым альпинистом. По словам его второй жены, Уильям относился к альпинизму не как к отдыху, а как к еще одной серьезной проблеме, которую требовалось решить. В более зрелом возрасте он предпочитал заниматься парусным спортом, плаванием и нырянием за жемчугом.

Вот такой вот интересный и противоречивый человек. Ну что же, у каждого свои тараканы... Хм, надо и себе для проформы завести парочку... ;)

Контроль передачи данных в конвергентных сетях. часть 3

noreply@blogger.com (Vasily Pantyukhin) — Tue, 31 May 2011 07:46:00 +0000

Часть 2 здесь

Давайте сравним методы контроля передачи данных в Fibre Channel и 10GE. Основная из задача – обеспечивать временную остановку передачи данных в случае нехватки входящих буферов портов-получателей. Напомню, что в FC используется механизм контроля счетчиков буферных кредитов. Объединяясь в фабрику, порты коммутаторов обмениваются информацией об общем количестве входных буферов и выставляют соответствующие значения счетчиков буферных кредитов (BB-credits). Отправив пакет, порт декрементирует свой счетчик. Если он обнуляется, отправитель должен остановить передачу. Порт-получатель в свою очередь, обязан явно сообщать о каждой освободившейся ячейке буфера посылкой слова-примитива Receiver Ready (R_RDY), Получив R_RDY, порт получатель инктеменитует значение BB credits.
Такой механизм гарантирует, что порты отправитель и получатель всегда имеют точную информацию о количестве свободных буферов на другом конце линка.

Очень важно отметить, что R_RDY является не FC фреймом (с заголовком, payload, CRC и т. д.), а 4byte (40bit) словом, т. е. объектом минимального размера, допустим для передачи по протоколу Fibre Channel. Соответственно, с точки зрения утилизации каналов накладные расходы контроля передачи данных практически не заметны.

Однако у каждой медали есть обратная сторона. Время между отправкой фрейма и получением сигнала R_RDY сильно зависит от расстояния между портами. Чем больше расстояние, тем дольше отправитель должен ждать инкрементации BB Credits. А это, в случае нехватки кредитов, приводит к задержкам передачи данных и падению загрузки линка.

На приведенном графике значение длины линка, при котором начинается падение утилизации канала, зависит от скорости передачи (Transfer Rate) и количества входных буферов. Увеличение количества доступных входных буферов, приводит к тому, счетчик буферных кредитов обнулится на больших расстояниях. Соответственно, точка перегиба на графике сдвигается вправо.

Давайте теперь рассмотрим протокол Ethernet. Он не имеет примитивов и предусматривает передачу данных в сети только фреймами. Минимальный размер фрейма 64bytes. Если бы в этом протоколе контроль передачи данных был реализован таким же образом, как и в FC, он был бы в 16 раз менее эффективным. Поэтому и был выбран другой метод. Вместо того чтобы постоянно сообщать о количестве свободных буферов, устройства в Ethernet явно сообщают только о событии, когда их не хватает. Таким образом, существенно экономится пропускная способность каналов.

Главным недостатком этого механизма является то, что как и в Fibre Channel, общая эффективность контроля передачи данных заметно падает с увеличением длины линка. Утилизация длинных линков становится низкой.

Для полной загрузки линков на больших расстояниях необходимо либо отключать механизм контроля передачи, либо увеличивать количество входных буферов в коммутаторах, соответствующим образом сдвинув пороговые значения.

На самом деле это выбор без выбора, ведь с отключением Flow Control появится вероятность потери фреймов, что для трафика FCoE совершенно не приемлемо. Поэтому производители увеличивают количество буферных ячеек. На данный момент Cisco повысила максимальную длину линков между своими коммутаторами с 300м. до 3км. (NX-OS 5.0(2)N1.1).

Nexus 55xx - Nexus 55xx – 3км.
Nexus 50x0 - Nexus 50x0 - 3 км.
Nexus 50x0 - Nexus 55xx - 3 км.
Nexus 55xx - Nexus 2232 – 300м.
Nexus 50x0 - Nexus 2232 – 300м.

Brocade, вроде, пока ограничивает длину линков 300м.

Контроль передачи данных в конвергентных сетях. часть 2

noreply@blogger.com (Vasily Pantyukhin) — Wed, 18 May 2011 16:13:00 +0000

Часть 1 здесь
Использовалась статья Cisco

Итак, мы остановились на том, что чем длиннее кабель, тем раньше должна быть передана пауза. Насколько раньше? Для того чтобы не потерять ни одного фрейма данных, “запаса” свободных буферов должно быть достаточно для сохранения всех фреймов которые будут посланы, пока PAUSE дойдет до отправителя и будет им обработана. Пороговое значение количества свободных буферов, при котором высылается пауза должно быть установлено, учитывая следующие факторы:

Обмен данными возможен в обоих направлениях. Если порт получатель уже начал передавать какой-то пакет, то прерывать эту передачу для того, чтобы послать PAUSE не разумно. Поэтому будет задержка, достаточная для передачи данных объемом MTU-1bit (рассматриваем самый худший случай). Напоминаю, MTU = Maximum Transmission Unit. Так как MTU для различных CoS может быть разным, нужно брать максимальный.

Скорость распространения электромагнитного сигнала в меди составляет около 70% от скорости в вакууме. В оптическом кабеле она еще чуть меньше и составляет 65%. Поэтому каждые 100м. кабеля добавляют 476нс. (медь) или 513нс. (оптика) задержки. За время пока PAUSE путешествует по 100м. кабелю, порт-отправитель на 10Gbps передаст 641byte (берем худший случай более медленной оптики). А так как на момент отправки PAUSE по кабелю к получателю уже передавались какие-то данные, этот объем надо удвоить. Округленно получаем 1300bytes на каждые 100м.

При получении PAUSE порт получатель должен ее обработать и подать команду на остановку трафика. Протокол PFC предписывает это сделать не более чем за 60 квантов времени (кванты обсуждались в предыдущем посте), что эквивалентно передаче 512bits * 60 квантов = 3840bytes.

После того, как послана команда на остановку трафика, необходимо все-таки дождаться, пока пакет, который уже начался передаваться, полностью уйдет. Соответственно, опять будет задержка, достаточная для передачи данных объемом MTU-1bit (самый плохой случай). причем здесь должно приниматься во внимание MTU только CoS FCoE.

Суммарно, мы получаем постоянную задержку, эквивалентную 9216bytes (максимальное MTU Ethernet) + 3840bytes + 2240bytes (максимальное MTU FCoE) = 15296bytes, а также задержку, 1300bytes на каждые 100м. кабеля. На максимально допустимой в данный момент длине кабеля 300м. мы получим задержку эквивалентную 15296bytes + 3 * 1300bytes = 19196bytes.

Есть еще один момент, о котором не стоит забывать. Он заключается в том, что буферная память организована не как единое непрерывное хранилище данных, а виде отдельных ячеек или блоков. Размеры этих ячеек зависят от конкретной модели устройств. Так, Cisco в своих коммутаторах Nexus 5000 и экстендерах Nexus 2000 они составляют 160bytes и 80bytes соответственно.

Ethernet фрейм минимального размера 64bytes в буферах Nexus 5000 будет занимать всего 40% объема ячейки. А так как неиспользованная память в ячейках применяться для хранения других данных уже не может, оставшиеся 96bytes просто пропадают.

Итак, в самом худшем случае фреймов 64bytes мы имеем 60% накладные расходы на использованный объем буферной памяти. Наши 19196bytes поместятся в 300 пакетов размером 64bytes. Это, в свою очередь, приведет к использованию 300 * 160bytes = 48000bytes буферной памяти (около 1/10 от общего объема памяти в Nexus 5000).

Итак, в рассмотренном конкретном примере, пороговое значение, при котором высылается PAUSE на передачу FCoE, равно 300 буферных ячеек. Использование функциональности lossless Ethernet с другими сетевыми протоколами, например iSCSI, за счет снижения количества ретрансмитов данных дает дополнительные преимущества производительности. Однако, стоит учитывать, что в этом случае пороговое значение паузы будет еще выше. В случае Cisco Nexus 5000 оно будет равно 409 буферных ячеек.

В данный момент Cisco NX-OS поддерживает PFC только до 3 CoS:

1x FCoE (mini Jumbo MTU 2240bytes)
1x сетевой трафик с jumbo MTU 9216bytes
1x сетевой трафик со стандартным MTU 1500bytes

Часть 3 здесь...

Контроль передачи данных в конвергентных сетях. часть 1

noreply@blogger.com (Vasily Pantyukhin) — Sun, 15 May 2011 20:14:00 +0000

Использовалась статья Cisco

Традиционный протокол Ethernet изначально разрабатывался для передачи данных по ненадежным носителям. Он совсем не гарантирует того, что все посланные пакеты данных будут обязательно получены соответствующими устройствами.

Одной из причин ненадежности Ethernet заключается в отсутствии обратной связи между получателем данных и их отправителем. Проблема особенно критична в сетях с большим количеством хопов (hops). Часто бывает так, что отправитель передает данные с большей скоростью, чем получатель их обрабатывает. Это приводит к тому, что входные буферы получателя быстро заполняются (buffer overflow), а новые пакеты, которые хранить уже негде, просто отбрасываются (drop). Причем, никакого уведомления об этом отправитель не получает.

В сетях передачи данных такая ситуация не является критичной. Обнаружив, что каких-то Ethernet фреймов не хватает (drop detection), протоколы сетевого (3) уровня просят переслать их заново. Получив недостающие пакеты, эти протоколы их упорядочивают (in-order) и передают выше по стеку.

Ситуация значительно хуже в сетях хранения данных. Протокол Fibre Channel не осуществляет ретрансмиссию только отдельных фреймов (так же, как и не допускают доставку пакетов в неправильной последовательности - out of order delivery). В случае обнаружения потери части фреймов, устройствам приходится передавать заново всю последовательность (sequence). Естественно, это приводит к катастрофическому падению производительности.

Для того, чтобы избежать возможность потери фреймов в связи с переполнением входных буферов принимающих устройств, реализован специальный механизм контроля передачи данных (flow control). В “чистом” Fibre Channel этот механизм работает на уровне FC2. Он построен на первоначальном обмене информацией о количестве имеющихся в наличии входных буферов, дальнейшем уменьшении значений счетчиков буферных кредитов (BB credits) при отправке данных и их инкрементации при получении от порта-соседа коротких сообщений R_RDY об освобождении буферов. Подробнее в 3 части.

В конвергентных сетях на базе 10Gbps Ethernet при передаче FCoE трафика мы также обязаны использовать контроль передачи данных. Однако там для этого используется совсем другой подход. Порт-получатель данных постоянно следит за количеством своих свободных буферов. Как только он видит, что их количество достигает некого минимального уровня, порту-отправителю посылается специальный (MAC control frame) фрейм PAUSE, уведомляющий о необходимости на какое-то время приостановить передачу всех данных. Однако, такой подход не является оптимальным, так как в конвергентных сетях остановка FCoE трафика не должна приводить к задержке передачи данных других сетевых протоколов.
Поэтому механизм контроля передачи данных на базе PAUSE расширен функциональностью PFC (Priority Flow Control). Различным протоколам назначаются соответствующие классы сервиса (Classes of Services, CoS). Значение CoS передается в одном из полей VLAN-тега пакетов (VLAN tag). Контроль передачи осуществляется независимо для каждого из 8x возможных CoS. Структура пакетов не использующих и использующих PFC показана на рисунке.

Продолжительность паузы для каждого CoS определена в соответствующем 2byte поле количеством квантов времени. Один квант представляет собой время, необходимое для передачи 512bits данных на текущем Transfer Rate (в данном случае 10Gbps). Значение ноль принудительно снимает передачу данных с паузы.
Насколько я понял, в данный момент коммутаторы Cisco не пытаются интеллектуально подходить к определению необходимой продолжительности паузы. Вместо этого выставляется очень большое значение PAUSE, а затем явным образом снимается контрольным фреймом со значением 0. Как это работает у других, я не знаю.

Для того, чтобы установить паузу на передачу данных, порт получатель должен сгенерить управляющий фрейм, передать его по кабелям в виде оптического или электрического сигнала (ох, как я всем надоел своими сетованиями на то, что скорость распространения электромагнитной волны в нашей Вселенной такая маленькая ;) ), после чего этот фрейм должен быть обработан отправителем. Все это происходит отнюдь не мгновенно. Поэтому получатель должен постоянно следить за своими буферами и заранее (!) отправлять PAUSE, предполагая скорое переполнение своих буферов. Чем длиннее кабель, тем раньше должна быть передана пауза.

Часть 2 здесь...

Заполнители в FC

noreply@blogger.com (Vasily Pantyukhin) — Fri, 06 May 2011 09:22:00 +0000

Мой старый приятель и бывший коллега Юра Яворский описал интересный случай из практики траблшутинга SAN. С согласия Юры (большое спасибо!) делюсь с вами.

"Столкнулся недавно с интересной особенностью при настройке оборудования у клиента. Система хранения IBM (LSI) ни в какую не виделась коммутатором Brocade, а инициаторы работали нестабильно, т.е. порты коммутатора то "видели" их, то нет. Ошибка явно была связана с потерей синхронизации в линке. Причем ручные настройки портов ни к чему не приводили. Оказалось, что в новых версиях прошивки FOS значения примитивов заполнителей на каждом порту по умолчанию стоят в ARB. Помогает в этой ситуации смена значения на IDLE при помощи команды portCfgFillWord. Смена значения по умолчанию производителем тоже была не случайна. Дело в том, что по стандарту FC-FS-3 действительно должен использоваться примитив ARBff. Вот выдержка из указанного стандарта:

10.3.5 Emission Lowering Protocol

An FC-0 standard (e.g., FC-PI-3) may specify the use of Emission Lowering Protocol when using the 8B/10B transmission code.

When Emission Lowering Protocol is used, the Fill Word shall be the ARBff Ordered Set.

When Emission Lowering Protocol is not used, the Fill Word shall be the Idle Ordered Set.

Причина кроется в интерференции волн при использовании слов заполнителей IDLE. Таким образом на частотах 8,5GHz использование ARBff строго рекомендовано. Источники ниже:

ftp://ftp.t11.org/t11/member/fc/fs-2/04-680v0.pdf

http://www.t10.org/ftp/t11/document.05/05-462v1.pdf

Почему же порты некоторых оконечных устройств продолжают работать в несовместимом формате? Ответ думаю прост – несоблюдение стандартов. Хотя вопрос может быть тонким и рекомендация все равно остается рекомендацией. Поэтому именно для возможности гибкой настройки примитивов в FOS и была добавлена команда portCfgFillWord."

Я честно говоря не предполагал, что использование ARB дает заметные преимущества еще и с точки зрения уменьшения EMI (в документах по ссылкам даны графики). Интересно.

На всякий случай напомню, что изначально примитивы ARB() применялись только для арбитража доступа устройств в топологии FC_AL. Однако Brocade нашла еще одно применение для них. Они используются для идентификации Virtual Channels (VC). Коммутатор следит за адресом AL_PA заполнителя ARB(). Фрейм, идущий за ARB() с неким AL_PA, считается принадлежащим соответствующему VC. Соответствие AL_PA и номера виртуального канала показано в таблице.

Тип порта	Кол-во VC	VC	Приоритет	AL_PA	Описание
F	1	VC7	2 или 3 (по умолчанию 3)	0xda	Подключение к N-порту
FL	1	VC7	2 или 3 (по умолчанию 3)	0xda	Подключение к NL-порту
E FC_SW2	1	VC0	0	0xef	Подключение к E-порту в режиме совместимости (InterOp)
E	8	VC0	0	0xef	Служебный трафик (класса F)
		VC1	1	0xe8	Служебный трафик (F_BSY и F_RJT, опционально контроль линка трафика класса 2)
		VC2	2 или 3 (по умолчанию 2)	0xe4	Данные оконечных устройств (класса 2 или 3)
		VC3	2 или 3 (по умолчанию 2)	0xe2	Данные оконечных устройств (класса 2 или 3)
		VC4	2 или 3 (по умолчанию 2)	0xe1	Данные оконечных устройств (класса 2 или 3)
		VC5	2 или 3 (по умолчанию 2)	0xe0	Данные оконечных устройств (класса 2 или 3)
		VC6	2 или 3 (по умолчанию 3)	0xdc	Multicast трафик (класса 3)
		VC7	2 или 3 (по умолчанию 3)	0xda	Multicast и broadcast трафик (класса 3)
C	17				Используется только при прямом соединении ASIC Condor друг с другом.

A great place to work

noreply@blogger.com (Vasily Pantyukhin) — Fri, 15 Apr 2011 15:26:00 +0000

Пятница вечер. Настроение уже не рабочее. Предлагаю расслабить мозг и потратить три минуты на что-нибудь бессмысленное. Например, посмотреть драйвовый клип про мою родную Мега-корпорацию.

Народ, по моему, делает это с удовольствием :) Даже Туччи, Холлис и другие генералы отметились.

Кстати, как-то мне удалось побывать в том самом сборочном цехе, где в самом начале какой-то чувак шуруповертами машет. Однако, с непривычки такое огромное количество Symmetrix в одном месте впечатляет. Вот где настоящие мужики-то работают, все железное!!!
А тут топчешь батоны, только Вселенную зря греешь...

Добавлено: в этом году мне представилась возможность побывать в Лас Вегасе на главном стораджевом событии года EMC World Однозначно, лучшая техническая конференция из всех, на которых я побывал! Соотношение правильных знаний и минимального количества бул-шит маркетинга превзошло все ожидания.
Ну, да не об этом речь. В предпоследний день конференции EMC организовало пьянку-гулянку с группой The Fray на сцене. Они сыграли и песню, которая была в клипе. Так вот, в качестве гитариста на сцену вышел сам Генералисимус Джо Тучи. Есть еще порох у чувака! Я честно удивился. Было драйвово...

Нюансы работы Principal switch

noreply@blogger.com (Vasily Pantyukhin) — Thu, 07 Apr 2011 19:58:00 +0000

В комментариях к посту Приостановка передачи в SAN Виктор (кстати, огромное спасибо) задал очень интересные вопросы. Чтобы их не потерять, я решил ответить в отдельном посте.

Вопросы синим, ответы зеленым.

1) В той статье, на стр.51 указывается, что если Fabric стабильна и если подключается новый switch, то выборы Principal switch не происходят. Что означает "стабильна"?

“Стабильна” в данном контексте означает, что в фабрике не происходит процессов перевыборов Principal коммутатора или других переходных процессов.

Правда ли, что если Fabric имеет несколько switch-ей, и если на них выключено питание, а затем включено, то 1-й из них, кто загрузится быстрее будет Principal switch?

Да, если они заранее соединены ISLs между ними.

Тогда, как в этом случае форсировать выборы другого Principal switch-а, когда все остальные switch-и загрузятся если мне этого захочется и кстати: а какая может быть объективная причина это сделать, если Fabric работает без проблем?

Principal коммутатор рекомендуется загружать в первую очередь. Форсировать можно выключением текущего Principal, тогда назначится коммутатор с установленным флагом Principal Selection Mode или с минимальным WWN.

Если все работает без проблем, я считаю, форсировать ничего не надо. Однако поставить флаг все же стоит. Эта процедура совершенно безопасная, а соответствующий Principal коммутатор будет выбран (важно, что здесь используется “жесткий” термин selected, а не “справедливый” elected) после следующей модернизации микрокода.

2) Можно ли более подробно пояснить: как выполняется сравнение WWN как операция над ASCII строками при выборе Principal switch? Вы сравниваете два WWN: 10:00:00:0d:ec:01:00:00 и 10:00:00:0d:ec:0a:00:00. ASCII код a (97) больше, чем ASCII код 1 (49). Выигрывает меньшее по идее.

Да, вы правы. В статье ошибка, должно быть наоборот.

Так как свои статьи я обычно перечитываю достаточно редко, то обнаружил ее совершенно случайно только прошлым летом. Интересно, что до вас ее никто еще не заметил ;) или поленился сказать.

3) Могли бы ли вы пояснить ситуацию со временем: одна из функций Principal switch – синхронизация времени во всей Fabric. Как тогда следует пользоваться командами «tsclockserver ip_addr_ntp_server» и «date»? По идее я должен дать их только на Principal switch?

Команда tsclockserver используется для синхронизации Principal коммутатора с NTP сервером, соответственно пользоваться ей надо только на Principal switch.

Как тогда Principal switch заставит другие switch-и синхронизировать время с его собственным?

Principal switch будет периодически (каждые 64 сек.) рассылать другим коммутаторам ELS фреймы с адреса FFFFF6.

Надо ли что-то делать на других switch-ах?

Нет, все распространение апдейтов времени на остальные коммутаторы происходит автоматически. На всех коммутаторах есть свой локальный Time Server daemon (LOCL), однако с NTP сервером соединяется и бродкастит время только Principal switch. Получив апдейт, коммутатор переписывает свои локальные установки времени.

Что произойдет со временем, если произойдут перевыборы Principal switch-а?

При присоединении к фабрике новый коммутатор получает от Principal switch IP адреса всех NTP серверов и сохраняет их где-то во flash памяти. Я предполагаю, что после перевыборов новый Principal switch просто синхронизируется с NTP сервером.

4) Насчет zoning: если я хочу использовать только лишь zoning на основе PID, то мне следует опасаться перевыборов Principal switch? Тогда единственный способ избежать проблем – это включить на каждом switch-е Insistent Domain ID Mode командой «configure» ?

Включенный флаг Insistent Domain ID Mode вообще является best practice не зависимо от способа зонирования. В случае использования в любых настройках фабрики или адресации оконечных устройств 24-битных адресов PID, этот параметр становится критичным и обязательным к применению.

5) В целом: в чем заключается весь полезный функционал Principal switch? Только лишь в автоматическом назначении Domain ID и синхронизации времени?

Это основные его функции. Замете, принципиально важные для функционирования фабрики.

Также Principal switch участвует в выборе Principal ISLs, по которым в дальнейшем будет передаваться информация об изменении конфигурации фабрики. Spanning tree гарантирует невозможность “закольцовывания” служебного трафика.

Сейчас точно не припомню в каких коммутаторах (Brocade, Cisco или McData) (где-то записано, но на бумажных носителях Ctrl-F не работает ;( ) управление и мониторинг фабрикой осуществляется только через Principal switch. Т. е. даже когда вы задаете команду с какого-то другого коммутатора, она по протоколу IPFC (не путать с FCIP) засылается на Management server,находящийся на Principal switch, который, в свою очередь, формирует ответ и посылает обратно на коммутатор, с которого пришел запрос. Именно по этому рекомендуется “рулить” фабрикой с Principal коммутатора.

Добавлено в ответ на комментарий все-таки нашел в своих записях упоминание о том, что так работают коммутаторы Cisco. Источник - общение за кофе с преподавателем курсов по Cisco MDS в 2006 г. Если это правда, то и в современных коммутаторах так.

Какова ситуация с Brocade не знаю. При случае спрошу (важно знать кого ;) ).

В документации по Cisco упоминание про Principal switch так найти и не смог.Есть более пространное: "An NMS (network management systems) host running IP protocol over a FC interface can access the switch using the IPFC functionality. If the NMS does not have a Fibre Channel HBA, in-band management can still be performed using one of the switches as an access point to the fabric."

Самый эффективный протокол

noreply@blogger.com (Vasily Pantyukhin) — Mon, 28 Mar 2011 17:12:00 +0000

Недавно попались на глаза расчеты эффективности различных протоколов. Как-то они мне показались не убедительными: то поле в хедере забудут, то из максимального payload не вычтут часть накладных расходов. В общем, решил все пересчитать сам и свести в одну табличку, пригодится в качестве шпаргалки по протоколам.
Может тоже что-нибудь забыл, зато с честной совестью и ощущением полной собственной правоты ;)

Напомню, "эффективность" считается как отношение максимального объема полезных данных к сумма всех передаваемых данных.

Размеры в байтах. Аббревиатуры: SOF - Start Of Frame, EOF - End Of Frame, IFG - Iner-Frame Gap.

Поле	Ethernet (Untagged Standard Frames)	Ethernet (Tagged Standard Frames)	Ethernet (Tagged Jumbo Frames)	iSCSI (Tagged Standard Frames)	iSCSI (Tagged Jumbo Frames)	FCIP (Untagged Baby Jumbo Frames)	FCoE (Untagged Baby Jumbo Frames)	Fibre Channel (FCP, Class3)	SAS
Preamble	7	7	7	7	7	7	7
Ethernet SOF	1	1	1	1	1	1	1
Ethernet Header	14	16	16	16	16	14	14
IP Header				20	20	20
TCP Header				20	20	20
iSCSI Header				48	48
FCIP Header						24
FCoE Header							16
SOF						4	4	4	4
FC Header						24	24	24
SAS Header									24
Maximum payload	1500	1500	9000	1412	8912	2112	2112	2112	1024
CRC	4	4	4	4	4	4	4	4	4
EOF + Padding						4	4	4	4
IFG	12	12	12	12	12	12	12	24	2
SAS R_RDY and ACK overhead									8
Efficiency	97,98%	97,85%	99,63%	92,11%	98,66%	94,33%	96,39%	97,24%	95,70%

Пятиминутная медитация на таблицу в качестве сатори дает общее понимание структуры протоколов... Для совсем ленивых прилагаю уже пережеванную картинку... ;)

В общем, получается, что самый "выгодный" стораджевый протокол все-таки Jumbo iSCSI...
Ему бы еще и остальные достоинства FC или хотя бы FCoE.... ;) но это тема отдельного разговора.

Кстати, понравилась эта статья про Etherner фреймы, кратко и очень толково. В контексте активного продвижения 10G CEE в мир storage, все дружно вспоминаем уже позабытую. сетевую теорию... :)

Дедупликация фиксированными и изменяющимися блоками

noreply@blogger.com (Vasily Pantyukhin) — Sun, 20 Mar 2011 17:29:00 +0000

Очень простой и понятный пример того, какие преимущества дает использование дедупликация блоками динамически изменяющегося размера. Взято здесь.

Итак, в текстовый файл мы записали фразу “deduplication technologies are becoming more an more important now.” и прогнали по ней два алгоритма дедупликации: один с фиксированным размером блока (для простоты взят размер в 8 символов), а другой с изменяющимся. Получаем такой расклад:

Ох ты, а в тексте-то ошибка. :( Надо срочно ее исправить и дописать букву "d" в слово "end". Однако, это приведет к тому, что весь последующий текст сдвинется на один символ. Соответственно, это приведет к изменению 4 блоков фиксированного размера.

А вот в случае динамически изменяющихся размеров, "пострадает" только 1 блок. Количество информации, которое необходимо записать на хранилище в этом случае значительно меньше. Сочетая такие алгоритмы с методом дедупликации на клиенте, мы, к тому же, заметно разгружаем сеть передачи данных.

EMC Avamar использует дедупликацию на клиенте блоками изменяющегося размера. Алгоритм называется “sticky byte factoring”. Размер блока динамически вычисляется по предетерменированным паттернам данных и может варьироваться от 1byte до 64Kbyte (в среднем 24Kbyte). Для вычисления хэш-сумм (их там несколько типов: атомарные для каждого блока, композитные для групп блоков и корневые для всего объекта) используется специальная катящаяся (rolling) хэш-функция. Не смотря на то, что на ее вход поступают данные различного размера, результат ее работы (хэш-сумма) всегда имеет фиксированную длину 20byte. В общем, лихо закручен сюжет, я в подробностях даже не пытался разобраться... может вы попробуете? ;) здесь кое-что есть для затравки...

Принцип KISS

noreply@blogger.com (Vasily Pantyukhin) — Sun, 13 Mar 2011 19:31:00 +0000

В этот раз no comments... ;)

Келли Джонсон - инженер Локхид Мартин
KISS - "Keep it simple, Stupid!" - "Делай проще, тупица!"

Уильям Оккам - английский монах-францисканец
"Не следует множить сущее без необходимости"

Леонид Сухоруков - советский и украинский писатель
"Сложнее всего постигается простота"

Альберт Энштейн - ...
"Все должно быть изложено так просто, как только возможно, но не проще"

Леонардо да Винчи - итальянский художник и ученый
"Простота — это то, что труднее всего на свете; это крайний предел опытности и последнее усилие гения"

Фредерик Шопен - польский композитор
"Простота является высшей целью, достижимой, когда вы преодолели все трудности"

Коко Шанель - французский модельер
"Простота есть ключ к истинной элегантности"

Антуан де Сент-Экзюпери - французский писатель, летчик
"Совершенство достигнуто не тогда, когда нечего добавить, а тогда, когда нечего убрать"

Ричард Фейнман - американский физик
"Природа великолепно проста и потому великолепно красива"

Алан Перлис - ученый computer science
"Глупцы игнорируют сложность. Прагматики терпят ее. Некоторые могут избегать ее. Гении ее устраняют"

Проблемы с SFP

noreply@blogger.com (Vasily Pantyukhin) — Tue, 08 Mar 2011 21:31:00 +0000

Потери в оптическом линке мы обсуждали здесь…

В этом посте мне хотелось бы продолжить тему и обсудить несколько ситуаций возникновения проблем в модулях SFP о которых администраторы SAN иногда забывают.

В соответствии со спецификацией, SFP приемник и передатчик работают в неком диапазоне мощностей. Слишком маленькая мощность сигнала приводит к ошибкам за счет ограниченной чувствительности приемника. Слишком большая, ведет к насыщению характеристик приемника и тоже к его нестабильной работе.

Для того, чтобы избежать проблем, старайтесь соблюдать следующие best practices:

модули на концах одного линка должны быть однотипными
не используйте «левые» кабели неизвестного происхождения
соблюдайте соответствие между дальнобойностью SFP и длиной кабеля

Здорово, когда все работает как надо. Однако интересно, что же произойдет, если по каким-то причинам, мы выйдем из разрешенного диапазона? Опыт показывает, что в случае SFP 1, 2 или 4Gbps небольшое нарушение спецификации обычно не приводит к каким-либо серьезным негативным последствиям. А вот 8Gbps модули к таким нарушениям толерантны в меньшей степени. Это сразу заметно по увеличивающемуся количеству ошибок на соответствующих портах.

Давайте рассмотрим некоторые варианты проблем.

Реальная получаемая мощность Rx выше допустимого максимального значения в спецификации Rx Max.

Такая ситуация чаще всего случается когда затухание в оптическом канале не достаточно. Звучит странно, но слишком мало тоже плохо ;) .

Типичные параметры дальнобойных SFP приведены в таблице.

SFP Type	Tx Min (dB)	Tx Max (dB)	Min Rx (dB)	Rx Max (dB)	Max Loss (Link Budget) (dB)
2Gbps LW	-11.7	-3.0	-20.0	-3.0
4Gbps 4 км LW	-11.2	-1.0	-16 -12 (типично)	-1.2	4.9
4Gbps 10 км LW	-8.4	-1.0	-16.0 -12.0 (типично)	-1.0	7.8
4Gbps 30 км LW	0.0	+5.0	-18.0	0.0	18.0
8Gbps 10 км LW	-8.4	+0.5	-13.8 -9.0 (типично)	+0.5	6.4
8Gbps 25 км LW	0.0	+5.0	-13.8	+0.5	16.2

Предположим, что мы соединяем модули 2Gbps и 8Gbps. Обратите внимание на то, что Rx Max модуля 2Gbps составляет всего -3dBm. Чаще всего затухания в кабелях за счет соединений в патч-панелях достаточно велико. Однако, в некоторых случаях, например, при использовании самодельных или не подходящих кабелей, его может не хватить и 2Gbps SFP, сверх меры накачанный энергией (Tx 0-5dBm), корректно работать не будет.

Теперь давайте рассмотрим ситуацию с разнесенной конфигурацией SAN. Предположим, расстояние между удаленными площадками 20 км. Для повышения общей пропускной способности каналов, между площадками используется активное оборудование DWDM.
Какие SFP должны использоваться для организации “длинных” ISL в такой конфигурации? Начинающий администратор может рассуждать так. Расстояние между площадками 20 км. Соответственно, в FC коммутаторах должны использоваться модули 8Gbps 25 км LW, а количество буферных кредитов должно быть не менее 80. Правильно? Отчасти…

Контроль передачи данных в ISL будет работать между портами коммутаторов не зависимо от того используется ли DWDM или нет. FC ничего не знает об уплотнении WDM. Световой сигнал от одного до другого конца ISL будет проходить ровно 20 км, что будет приводить к соответствующим задержкам получения R_RDY. Поэтому и количество буферных кредитов должно строго рассчитываться по расстоянию.

А вот с длинноволоновыми SFP рассуждения администратора не верны. Порт FC коммутатора подключается к активному DWDM, находящемуся на той же площадке. Именно DWDM должен иметь мощные модули для передачи сигнала на большие расстояния. А в ISL порт коммутатора нужно подключить самый банальный “короткострельный” SW SFP.
В случае, если на концах короткого линка от коммутатора к DWDM будут стоять LW SFP, сигнал, полученный приемником будет намного превышать допустимые нормы Rx Max и, конечно, ничего не заработает.

Реальная получаемая мощность Rx ниже допустимого минимального значения в спецификации Rx Min

Одной из причин возникновения проблемы является банальная грязь на оптических коннекторах. Если после чистки лучше не стало, нужно попробовать подключить новый кабель и провести мониторинг количества ошибок. Конечно, предварительно следует обнулить счетчики ошибок при помощи следующих команд: Brocade portstatsclear, Cisco clear counters interface.

Не помогло? Ну, тогда последовательно (по одному за раз) начинаем менять SFP на концах плохого линка.

Реальная передаваемая мощность Tx выше допустимого максимального значения в спецификации Tx Max

Однозначно, это “битый” SFP. Даже в случае, когда затухание в линке велико и на порт получатель придет импульс мощностью ниже Rx Max, все равно остается высокая вероятность искажения сигнала и появления ошибок приема. Так что обязательно следует поменять модуль.

Реальная передаваемая мощность Tx ниже допустимого минимального значения в спецификации Tx Min

Ситуация похожа на предыдущую. Даже в случае, когда мощность полученного сигнала будет чуть больше Rx Min, возможна нестабильная работа такого линка. Со временем, когда оптические характеристки кабеля и коннекторов ухудшаться, канал перестанет работать совсем. Что бы не рисковать, лучше поменять SFP при первой же возможности.

Ну и в заключение примеры диагностических команд, при помощи которых можно посмотреть текущие и пороговые значения мощностей приемника и передатчика:

Brocade
SwitchName:admin> sfpshow 9/11
Identifier: 3 SFP
Connector: 7 LC
Transceiver: 1501001200000000 100,200,400_MB/s SM lw Long_dist
Encoding: 1 8B10B
Baud Rate: 42 (units 100 megabaud)
Length 9u: 30 (units km)
Length 9u: 255 (units 100 meters)
Length 50u: 0 (units 10 meters)
Length 62.5u:0 (units 10 meters)
Length Cu: 0 (units 1 meter)
Vendor Name: BROCADE
Vendor OUI: 00:05:1e
Vendor PN: 57-1000020-01
Vendor Rev: A
Wavelength: 1310 (units nm)
Options: 001a Loss_of_Sig,Tx_Fault,Tx_Disable
BR Max: 0
BR Min: 0
Serial No: WEF10825000009K
Date Code: 080618
DD Type: 0x68
Enh Options: 0xf0
Status/Ctrl: 0x0
Alarm flags[0,1] = 0x0, 0x0
Warn Flags[0,1] = 0x0, 0x0
Alarm Warn
low high low high
Temperature: 36 Centigrade -3840 19200 -2560 17920
Current: 24.392 mAmps 12.620 100.238 20.000 63.246
Voltage: 3241.1 mVolts 50.0 5000.0 150.0 4500.0

RX Power: -0.9 dBm (816.0 uW) 0.0 uW 0.0 uW 0.0 uW 0.0 uW

TX Power: 2.4 dBm (1753.8 uW) 4.0 uW 1584.9 uW 6.3 uW 1000.0 uW

Cisco
switch# show interface transceiver detail
mA: milliamperes, dBm: decibels (milliwatts), NA or N/A: not applicable.
++ : high alarm, + : high warning, - : low warning, -- : low alarm.
A2D readouts (if they differ), are reported in parentheses.
The threshold values are calibrated.

High Alarm High Warn Low Warn Low Alarm
Temperature Threshold Threshold Threshold Threshold
Port (Celsius) (Celsius) (Celsius) (Celsius) (Celsius)
------- ------------------ ---------- --------- --------- ---------
Gi1/0/1 46.0 110.0 103.0 -8.0 -12.0
Gi1/0/2 46.5 110.0 103.0 -8.0 -12.0

High Alarm High Warn Low Warn Low Alarm
Voltage Threshold Threshold Threshold Threshold
Port (Volts) (Volts) (Volts) (Volts) (Volts)
------- --------------- ---------- --------- --------- ---------
Gi1/0/1 3.26 4.00 3.70 3.00 2.95
Gi1/0/2 3.28 4.00 3.70 3.00 2.95

High Alarm High Warn Low Warn Low Alarm
Current Threshold Threshold Threshold Threshold
Port (milliamperes) (mA) (mA) (mA) (mA)
------- ----------------- ---------- --------- --------- ---------
Gi1/0/1 24.9 84.0 70.0 4.0 2.0
Gi1/0/2 29.6 84.0 70.0 4.0 2.0

Optical High Alarm High Warn Low Warn Low Alarm

Transmit Power Threshold Threshold Threshold Threshold

Port (dBm) (dBm) (dBm) (dBm) (dBm)

------- ----------------- ---------- --------- --------- ---------

Gi1/0/1 3.0 ( 0.6) 8.1 6.9 -2.0 -3.9

Gi1/0/2 3.0 ( 0.6) 8.1 7.0 -2.0 -3.9

Optical High Alarm High Warn Low Warn Low Alarm

Receive Power Threshold Threshold Threshold Threshold

Port (dBm) (dBm) (dBm) (dBm) (dBm)

------- ----------------- ---------- --------- --------- ---------

Gi1/0/1 8.1 ( -4.7) 8.1 8.1 8.1 8.1

Gi1/0/2 8.1 ( 2.5) 8.1 8.1 8.1 8.1

Архитектура FCoE плат

noreply@blogger.com (Vasily Pantyukhin) — Sat, 05 Mar 2011 06:54:00 +0000

Я достаточно долго очень скептически относился к шумихе вокруг новомодного ныне FCoE. Недостатков множество, большая их часть лежит на поверхности и не заметить их очень трудно. Это и расстояние, ограниченное всего 300 м., и отсутствие мультихоповости (с поддержкой FC портов пока нет ни у кого), принципиальная невозможность маршрутизации (layer 2, однако), затянувшийся процесс стандартизации протоколов, ну и конечно, кусачая цена.
Однако, активный пушинг этой технологии на рынок мега-корпорацией Cisco и догонялки других вендоров сделали свое дело. Насчет CEE и FCoE еще можно ворчать, но игнорировать их уже точно нельзя.

Честно признаюсь, ни одного случая использования FCoE в серьезном продуктиве я пока не знаю. Однако, во многих российских компаниях уже сейчас собирают стенды и начинают обкатывать такие решения. Для того, чтобы понимать чего сейчас можно и, что особенно важно, нельзя ожидать от конвергенции сетей, следует потихоньку «въезжать» в соответствующие технологии.

В этом посте захотелось поговорить о внутренней архитектуре конвергентного оборудования, предлагаемого Brocade, на примере платы FCOE10-24 для директоров DCX. Коммутатор Brocade 8000 устроен практически так же, с единственным принципиальным отличием: его «Core» функциональность и нативные FC порты находятся не на отдельных платах, а помещены в единый корпус коммутатора. С новой линейкой VDX я пока знаком понаслышке, так что напишу о ней, когда разберусь.

Итак, начнем сразу с ограничений использования. В одном коммутаторе не может использоваться более 4x FCOE10-24 (FOS v6.4.1_fcoe). Ни в коем случае нельзя соседствовать ни с кем, кроме обычных 16, 32 и 48-портовых FC модулей. Никаких FA, FR или FX,а так же FC8-64 модулей! В качестве оконечных устройств допускается применять CNA от Brocade, Emulex или Qlogic, а также FC и нативные FCoE интерфейсы дисковых массивов.

Интересное ограничение касается количества Fibre Channel ISL hops. Их не должно быть больше 3x. С точки зрения best practice так было рекомендовано всегда, но в данном случае присутствует жесткое “not supported”.

На платах расположены 24x порта 10GE. Для использования FCoE и CEE никаких дополнительных лицензий не требуется, только железо.

По доброй традиции можно применять только Brocade-branded SFP+. FCoE, конечно, ходит только на короткие расстояния, а LR SFP предназначены только для сетевого трафика. Медные twinax cables использовать нельзя. Они подходят только для 8000 коммутаторов.

Тип SFP	Тип оптического кабеля	Максимальная длина
SFP+ SR (Short Reach)	Multi Mode	33 м (OM1) 82 м (OM2) 300 м (OM3) 380 м (OM4)
SFP+ LR (Long Reach)	Single Mode	2,5 км (трафик CEE) 10 км (трафик Ethernet)

С точки зрения внутренней архитектуры, FCOE10-24 можно рассматривать, как два объединенных коммутатора. ASIC Anvil отвечает за передачу CEE, а 8Gbps Condor2 за FC трафик. Оба они используют способ коммутации Cut-through.

Плата построена на базе 3x чипов Anvil. Каждый из них отвечает за группу из 8x TE портов (Ten gigabit Ethernet). ASICs всех плат в DCX связаны друг с другом и логически представляют из себя единый коммутатор, обрабатывающий весь Ethernet и CEE трафик. Anvil также отвечает и за работу протокола FIP (FCoE Initialization Protocol) и распознав FCoE, перенаправляет трафик на FPGAs Zeus.

Zeus используется как переходник для связи Anvil-Condor2 и обеспечивает инкапсуляцию / декапсуляцию FCoE фреймов. Он также отвечает за предоставление FPMA (Fabric Provided MAC Address), которые нужны для корректной маршрутизации фреймов FCoE в сети Ethernet.

Весь FC трафик обрабатывается единственным ASIC Condor2. Для представления FCoE портов в FC фабрике он формирует виртуальные VF порты (Virtual Fabric Ports). Для передачи данных на FC платы, ASIC Condor2 соединен с ASICs обоих Core blades.

Давайте рассмотрим весь путь прохождения фреймов. Когда CEE порт получает фрейм FCoE, он адресует его “своему” ASIC Anvil, который, в свою очередь перенаправляет данные для декапсуляции на Zeus. Далее данные передаются на Condor2. Каждому физическому TE порту может соответствовать только один виртуальный VE порт (и наоборот). В примере на рисунке, TE порт 23 смаплен на VF порт 23.
После этого данные уже путешествуют по протоколу FC и, пройдя backplain, уходят на ASICs, находящиеся на Core Blades.

Интересный нюанс. В каналах Anvil-Zeus трафик кодируется 64b/66b, а в Zeus-Condor2 используется 8b/10b. Каждому транку от Zeus на ASIC Condor2 выделяется 74x буферных кредита.

Группа из 8x TE портов может в максимуме получить до 80Gbps. Однако, суммарная пропускная способность каналов Anvil-Zeus ограничена всего 20Gbps. Внутренние пути Zeus-Condor2 представляют собой два транка по 16Gbps, но для того, чтобы соответствовать потоку данных с Anvil, пропускная способность снижена до 10Gbps.

В итоге, группа из 8x портов может использовать до 20Gbps внутренней пропускной способности платы. Простая арифметика дает нам переподписку 4:1.
Для более эффективного распределения нагрузки при подключении оконечных устройств к плате рекомендуется придерживаться “четверок” портов, т. .е подключаться в следующей последовательности:

0, 4, 8, 12, 16, 20;
1, 5, 9, 13, 17, 21
2, 6, 10, 14, 18, 22
3, 7, 11, 15, 19, 23

Теперь поговорим об CEE трафике. Мы уже знаем, что все ASICs Anvil объединены в единый Ethernet коммутатор. Трафик, который не является FCoE и предназначенный порту, находящемуся на том же самом Anvil коммутируется локально, не выходя наружу ASIC.

Если же порт назначения находится на соседнем Anvil или другой плате, то он, минуя Zeus и Condor2, по отдельным каналам перенаправляется на ASIC одного из Core blades и далее к Anvil назначения.

Каждый чип Anvil подключен к Core Blades посредством двух каналов 4x 8Gbps (итого 64Gbps). Соответственно, переподписка Ethernet трафика равна 80:64. Задержки передачи очень малы и не превышают 5 мкс.

Вот такая штуковина… :)

VMAX на TV

noreply@blogger.com (Vasily Pantyukhin) — Tue, 01 Mar 2011 19:46:00 +0000

Любители шпионских фильмов и сериалов конечно сразу заметили появление на экранах product placement массива EMC VMAX. Индикаторы рынка свидетельствуют о том, что после каждого показа продажи этого продукта в ведущих мегамаркетах и турецких off-license Великобритании и Соединенных штатов возрастали на 8-12%.

Тем же, кто невнимательно смотрит телевизор или попросту его не имеет, предоставляю фото-улики из фильмов "24 часа", "Никита" и "Тайные операции"... ;)

Кстати, в данный момент EMC активно ведет переговоры об активном плейсменте VNX-ов в "Докторе Хаузе" и VNXe в новом сезоне "Южного парка"... :)

Chad's world эпизод 2

noreply@blogger.com (Vasily Pantyukhin) — Wed, 23 Feb 2011 08:12:00 +0000

Наконец-то нашел свободный час для разбора не просмотренных новостей за последний месяц и с удивлением узнал, что уже вышел второй эпизод Chad's World.

Известный блоггер Virtual Geek (Чад Сакач) с главным vSpecialist-ом Вейдом О'Хэрроу показывают новые EMC-шные lowend массивы VNXe 3100 и 3300, Unisphere GUI-рулилку, плагин Virtual Storage Integrator (VSI4) для интеграции функций мониторинга и управления ресурсами хранения в vCenter и, в заключение, большой VNX с 3,5 и 2,5 дюймовыми SAS и flash дисками, подключенный по 10GE.
Новые железки, свежий софт, парни дурачатся... в общем, совмещаем приятное с полезным... :)

Все по аглицки, но очень понятно...
Изи, EMC... демо тайм, экселээээнт :)))

Потери в оптическом линке

noreply@blogger.com (Vasily Pantyukhin) — Mon, 21 Feb 2011 20:19:00 +0000

Продолжаем изучать оптическую науку в контексте пользы SAN администратору. О характеристиках SFP мы поговорили здесь и здесь. Сегодня обсудим как рассчитываются потери в линке.

Все активные и пассивные компоненты оптического линка вызывают потери. На их уровень влияют следующие факторы:

Количество пар коннекторов на протяжении всего линка
Количество и тип сращиваний кабеля (splices)
Натяжение и сильные перегибы кабеля
Изменения температуры
Ухудшение характеристик оптического кабеля и передатчика со временем, флуктуаций мощности источников питания

Для оценки того, насколько потери в линке близки к граничным значениям, необходимо вычислить оптический бюджет линии связи (link loss budget, в литературе еще используются термины link margin и power budget). Знание link loss budget позволяет контролировать уровень потерь, допустимых для стабильной и надежной передачи данных, помогает при выборе типов SFP (850nm или 1300nm) и оптического кабеля (MultiMode или SingleMode), а также используется при оценке его максимально допустимой длины.

Для учета потерь в линке будут использоваться следующие величины:

Термин	Измеряется	Описание
Transmitter power	-dBm	Уровень мощности лазера передатчика.
Receiver sensitivity	-dBm	Минимальная мощность, которая может быть надежно детектирована приемником.
Cable attenuation	dB/km	Уровень затухания в кабеле на единицу расстояния.
Connector pair (tx/rx)	количество*dB	Уровень потерь на коннекторах, формирующих линк. Коннекторы оконечных устройств в вычисления не включаются.
Cable splice	количество*dB	Уровень потерь на механических соединениях и сращиваниях кабеля.
Safety margin	dB	Запас на потери, которые потенциально могут возникнуть в будущем за счет старения кабеля и передатчика. Этот запас позволяет также учесть небольшие ошибки проектирования и дополнительные соединения, если в процессе эксплуатации кабель будет поврежден

Надеюсь, вы помните, что такое dB и чем он отличается от dBm… ;) Если нет,, то советую почитать известный ресурс.

На рисунке показано, как все вышеописанные факторы влияют на потери в линке.

Перейдем к арифметике. Для вычисления оптического бюджета линии связи необходимо сделать несколько действий. Сначала определим усиление системы (Link budget):

Link budget=Transmitter power – Receiver sensitivity

Далее нужно оценить общий уровень потерь в линке (Total link loss):

Total link loss=Cable attenuation + Loss from connector pairs + Loss from splices

Если нет точных данных об уровне потерь, для грубой оценки типичные и максимальные значения можно взять из таблицы:

Потери	Условия	Максимальные потери по стандарту	Типичные потери
Cable attenuation	Кабель 50/125μm OM3 Multimode, лазер 850nm	3,5 dB/Km	3,0 dB/km
	Кабель 50/125μm OM3 Multimode, лазер 1300nm	1,5 dB/km	1,0 dB/km
	Кабель 9/125μm OM3 Singlemode, лазер 1300nm	1 dB/km	0,4 dB/km
	Кабель 9/125μm OM3 Singlemode, лазер 1500nm	1 dB/km	0,3 dB/km
Connector pair	Коннекторы LC	0,75 dB	0,3 dB
Connector pair	Коннекторы MPO (Multifiber Push-On)	0,75 dB	0,5 dB
Cable splice	Механическое соединение	0,3 dB	0,2 dB
Cable splice	Сплавка	0,05 dB	0,05 dB
Safety margin		3,0 dB	0,7 dB

Ну, а теперь уже можно вычислить Link loss budget:

Link loss budget=Link budget – Total link loss – Safety margin

Обратите внимание, на то, что для гарантированно стабильной передачи данных Link loss budget должен быть больше 0.

Давайте потренируемся и для примера рассмотрим вот такую конфигурацию:

Total link loss=(0,02km+1km+2km+0,01km) * 0,4dB/km + 8* 0,3 dB +1 * 0,05 dB = 3,7 dB (потери мощности в 2,34 раза).

Предположим, что на обоих коммутаторах установлены Brocade 8G 10km SFP со следующими параметрами (взято из спецификации):
-Transmit:
Average power: -8.4 to 0.5 dBm

-Receive:
Unstressed sensitivity: 29 ?W, -15.4 dBm

Link budget=-8,4 dBm – (-15,4 dBm) = 7 dB

Теперь рассчитаем оптический бюджет

Link loss budget= 7 dB - 3,7 dB - 0,7 dB = 2,6 dB

Соответственно, рассматриваемый оптический линк будет обеспечивать стабильную передачу данных и по потерям даже имеет запас в 2,6 dB.

Характеристики SFP. Часть 2

noreply@blogger.com (Vasily Pantyukhin) — Tue, 08 Feb 2011 20:52:00 +0000

Часть 1 здесь

Short Wavelength 850nm transceiver

Long Wavelength 1310nm transceiver

Для передачи данных по оптическим каналам используются лазеры с частотой вблизи инфракрасного диапазона. При увеличении длины волны уменьшается рассеивание, но возрастает поглощение электромагнитной волны. Вместе с эффектами влияния всяких примесей и гидроскильных ионов в составе кварцевого стекла, эти физические эффекты дают забавную “горку с трамплинами” характеризующую зависимость величины затухания сигнала от длины волны.

Из графика видно, что на кривой затухания есть три ложбинки при 0,85, 1,3 и 1,55мкм. Их называют окнами прозрачности оптоволокна. При таких длинах волн затухание минимально, поэтому именно они используются для передачи сигнала на сравнительно большие расстояния.

Производство передатчиков и приемников, работающих с длиной волны 850nm наименее трудозатратно и достаточно дешево. Именно это окно используется для передачи данных, так называемыми, коротковолновыми (Short-Wavelength, SWL) модулями SFP.

Общие потери окна 1310nm. намного ниже, чем у 850nm. Вследствие этого оно позволяет работать на более длинных дистанциях и используется в длинноволновых (Long-Wavelength, LWL) модулях SFP. Однако производство оборудования, работающего на данной длине волны заметно дороже.

Третье окно обеспечивает минимально возможные потери. Именно оно сейчас активно используется при передаче данных с применением технологии спектрального уплотнения WDM (Wavelength-Division Multiplexing).

Кстати, в настоящее время оптоволокно с приведенными выше на рисунке характеристиками уже считается устаревшим. Различные технологии позволяют убирать некоторые пики. Например, избавиться от пика между 2 и 3 окнами, получив ложбину во всем диапазоне от 1300 до 1600нм.

9mkm single-mode fiber

50mkm multi-mode fiber

62,5mkm multi-mode fiber

Теперь поговорим о модах.

Лазер генерирует не идеально тонкий луч, а световой пучок. Этот пучок можно умозрительно разделить на большое количество лучей, входящих в оптоволокно в разных местах плоскости его среза и под разнообразными углами. В зависимости от характеристик источника света и волокна, через оптический линк могут проходить как тысячи, так и лишь один луч. Эти лучи света принято называть модами.

Итак, лазер одновременно вводит в оптоволокно большое количество мод, распространяющихся под разными углами и, соответственно, проходящих разное расстояние. Поэтому время прохождения волокна от начала до конца для разных мод будет различным. Это приводит к тому, что короткий острый световой импульс на выходе будет достаточно размазан. Данный эффект называется модовой дисперсией.

Если входные импульсы следуют друг за другом достаточно часто, то выходные сигналы за счет модовой дисперсии станут перекрываться друг с другом и различить их друг от друга приемнику будет нелегко. Возникнет множество ошибок. Модовая дисперсия является основным фактором, ограничивающим Transfer Rate. Она также заметно влияет на максимальное расстояние устойчивой передачи данных.

К счастью, законы физики в нашей Вселенной таковы, что при уменьшении диаметра волокна количество распространяющихся в нем мод начинает снижаться. А по мере приближения диаметра к длине волны передаваемого света остается все лишь одна мода. Такое волокно называют (какой сюрприз ;) ) одномодовым (Single Mode, SM). По таким оптическим линкам возможна передача данных на большие расстояния. Стандартный диаметр одномодового волокна очень мал - всего 9мкм,. поэтому изготавливать его достаточно сложно и дорого.

Многомодовые волокна обычно имеют диаметр 50мкм или 62,5мкм. Она намного дешевле, чем одномодовые. К тому же больший диаметр заметно упрощает их оконцовку и сращивание.

Operating distances

*OM1 62.5 μm (200-500 MHzkm)**	Distance
2 Gbit/sec Fibre Channel	0.5 to 150 m
4 Gbit/sec Fibre Channel	0.5 to 70 m
8 Gbit/sec Fibre Channel	0.5 to 21 m
*OM2 50 μm (500 MHzkm)**	Distance
2 Gbit/sec Fibre Channel	0.5 to 300 m
4 Gbit/sec Fibre Channel	0.5 to 150 m
8 Gbit/sec Fibre Channel	0.5 to 50 m
*OM3 50 μm (1500 MHzkm)**	Distance
2 Gbit/sec Fibre Channel	0.5 to 500 m
4 Gbit/sec Fibre Channel	0.5 to 380 m
8 Gbit/sec Fibre Channel	0.5 to 150 m

Существует международный стандарт, предусматривающий разделение многомодовых волокон на классы OM1, OM2, OM3 и OM4 на основе характеристики произведения ширины полосы пропускания на расстояние (см. в таблице выше).

Класс OM1 разрабатывался еще для сетей Ethernet 10 и 100Mbit/s. В качестве источника света тогда в основном применялись светоизлучающие диоды LED. Характеристик этих излучателей и волокна OM1 было вполне достаточно для реализации канала дляной до 2000м низкоскоростных технологий передачи данных.

В качестве излучателя оптических импульсов в оборудовании, работающим на Transfer Rate 1Gbps и более вместо диодов LED используются лазерные источники сигнала. В таких условиях волокно OM1 может устойчиво передавать сигнал лишь на небольшие расстояния. Поэтому все-таки резоннее использовать оптические линки лучшего качества – OM2 или даже OM3.

Волокна класса OM4 планируется использовать в будущем с оборудованием 40Gbps. Одномодовое оптоволокно представлено классами OS1 и OS2.

Для отличия волокон принято (но не обязательно) использовать различные цвета окраски внешней оболочки кабеля.
• желтый – одномодовое волокно 9мкм
• оранжевый - многомодовое волокно 62.5/50мкм, OM1/0M2+

• голубой - многомодовое волокно 50мкм OM3/OM4

Далее поговорим о потерях в оптическом линке

Характеристики SFP. Часть 1

noreply@blogger.com (Vasily Pantyukhin) — Sun, 06 Feb 2011 18:57:00 +0000

Когда в прошлом году я был в Белоруссии у одного из своих любимых заказчиков, услышал, как один из инженеров попросил своего коллегу:: “Тащи-ка еще жменьку сфпишек” :) . Оптические модули давно уже стали настолько повсеместно используемыми, что многие к ним уже относятся как к расходному материалу, а их количество меряют просто горстями :) .
На днях я по какой-то надобности открыл спецификацию на модуль SFP и вдруг понял, что некоторые обозначения и цыфирки для меня совершенно загадочны. Подумал, почитал и написал сие эссе…

Объяснение наиболее употребительных характеристик, взятых из спецификаций на современные модули SFP.

Up to 8.5Gbps - максимальная скорость передачи (Transfer Rate). Обозначение Gbps (или Gbit/s или Gb/s) в зависимости от контекста может использоваться двумя способами: просто как название интерфейса, или для определения его реального Transfer Rate. Поэтому во избежание путаницы, интерфейсы, все же, лучше называть 1GFC, 2GFC, 4GFC, 8GFC и 16GFC. Теперь разберемся с Transfer Rate. При передаче, transceiver испускает лазерные импульсы с частотой 1,063GHz, 2,126GHz, 4,252GHz, 8,5GHz или 14,025GHz. Импульс соответствует одному биту данных. Стоп…. не так… не биту, а боду. И здесь это не синонимы, ведь на уровне FC-1 данные кодируются методом 8b/10b и каждые 8 бит информации передаются 10 бодами. Так что, метрика Gbit/s в данном конкретном случае используется не верно. Должно быть Gbod/s. Однако исторически сложилось, что в литературе принято использовать именно этот термин, так что расслабимся и просто будем помнить, что за ним стоит реально.

Tri-Rate 2.125/4.25/8.5 Gb/s Fibre Channel – поддержка работы в одном из трех (triple) Transfer Rate. Обратите внимание, что на 1,063GHz современные 8GFC SFP уже не работают.

bi-directional data links – модуль SFP объединяет в себе сразу передатчик (transmitter) и приемник (receiver). Поэтому он поддерживает одновременную передачу и прием данных по двум линкам в рамках единого канала. Еще со времен радио, такие устройства называются transceiver. Именно поэтому модули SFP являются трансиверами.

Duplex LC connector – сдвоенный разъем LC, совмещающий в едином пластиковом корпусе одновременно 2 оптоволоконных ввода. Намного удобнее, по сравнению с использованием двух отдельных линков. По крайней мере, не надо задумываться в какой разъем надо вставлять каждое волокно, чтобы передатчик на одном конце “светил” в приемник на другом… и никак по другому ;) . Сейчас большинство кабелей, сделанных заводским способом именно такие.

1310nm Fabry-Perot laser transmitter - полупроводниковый лазер с классическим резонатором Фабри-Перо (помните школьный курс физики? ;) ). Удивительно, но эта штука (в смысле резонатор, а не лазер) была придумана еще в 1899 г. французскими физиками Перо и Фабри и до сих пор активно используется. Он представляет собой два, параллельно расположенных и обращенных друг к другу зеркала, между которыми формируется резонансная стоячая оптическая волна. Одно из зеркал делается более пропускающим для вывода излучения в этом направлении. В настоящее время такой резонатор используется в длинноволновых модулях SFP.

850nm Oxide VCSEL laser transmitter - поверхностно-излучающий лазер с вертикальным резонатором (Vertical Cavity Surface Emitting Laser). Полупроводниковый лазер, излучающий свет в направлении, перпендикулярном поверхности кристалла, в отличие от обычных лазерных диодов, излучающих в плоскости, параллельной поверхности. По сравнению с резонаторами Fabry-Perot, которые часто требуют специальных оптических элементов (coupling) для ввода луча в волокно, VCSEL имеет резонатор, расположенный перпендикулярно плоскости подложки; а это, в свою очередь, облегчает тестирование лазеров в процессе производства и снижению стоимости их сборки. Пока чаще используются в коротковолновых модулях SFP.

FC-PI-4 compliance – соответствует 4 стандарту ANSI FC-PI (Fibre Channel - Physical Interface), описывающему электрические и оптические спецификации на нижнем физическом уровне FC-0 (что такое уровни FC еще помните?). FC-PI-4 содержит все требования предыдущих стандартов FC-PI, FC-PI-2 и SM-LL-V. Стандарт FC-PI-3 описывает требования к интерфейсам XFI+ для 10GFC, а FC-PI-5 – новые 16GFC интерфейсы.

SFF-8472 Diagnostic Monitoring Interface for Optical Transceivers – поддержка диагностических возможностей в соответствии с стандартом SFF-8472. Позволяет в режиме реального времени отслеживать такие параметры модуля, как мощность передаваемого и принимаемого сигнала, ток смещения лазера, температура корпуса и напряжение питания.

RoHS compliant and Lead Free – директива Restriction of Hazardous Substances, ограничивающая содержание вредных веществ, принятая Европейским Союзом и вступившая в силу в 2006 г. Она препятствует использованию в электронном оборудовании шести опасных веществ: свинец, ртуть, кадмий, шестивалентный хром, полибромированные бифенолы и полибромированный дифенол-эфир. Если техника не соответствует этой директиве, то продавать в Европе ее нельзя.

IEC 60825-1 Class 1 / CDRH Class 1 laser eye safe – класс 1 по стандартам безопасности лазерной аппаратуры. Соответствует лазерным системам очень малой мощности, не способным создавать опасный для человеческого глаза уровень облучения даже при долговременном прямом наблюдении. Звучит заманчиво, но, не смотря на это, смотреть все же не рекомендую ;)

Hot-pluggable SFP+ footprint - версия форм-фактора SFP, предназначенная для работы с 8GFC и 10GbE. С принятием стандарта SFP+ в 2009 г. был сделан ряд на первый взгляд не заметных, но значимых для стабильности передачи данных на высоких Transfer Rates изменений, например, улучшена геометрия контактов, изменена конструкция фиксирующей пружинки и т. д. Форм-фактор SFP+ полностью совместим с SFP.
В настоящий момент Brocade для своих 64-портовых 8Gbps плат поставляет модули форм-фактора miniSFP. По сравнению с SFP/SFP+ (14,8/12,4/56,7 мм) miniSFP (11,7/10,25/56.40 мм) имеют заметно меньшие размеры, что позволяет добиться большей плотности размещения портов на плате.

Metal enclosure, for lower EMI – для уменьшения уровня электромагнитных помех (EMI, Electro-Magnetic Interference), модуль помещен в металлический кожух. Это так же позволяет увеличить плотность размещения портов.

Extended operating temperature range: -5°C to 85°C – рабочий температурный диапазон
Storage temperature –40°C to 100°C – температура хранения модулей. Заметьте, что хранить на сильном морозе можно, а вот работать лучше все-таки в отапливаемом помещении.

В следующей части вспомним физику, поговорим о "модной" специфике и о том, зачем укорачивать и удлинять волны...

Коммутаторы Brocade 16Gbps

noreply@blogger.com (Vasily Pantyukhin) — Tue, 21 Dec 2010 19:48:00 +0000

Declaimer: за что купил, за то и продаю. До официального релиза, все это слухи, слухи… а меня в этот раз подписывать ничего не заставляли, так что…

Компания Brocade уже с лета говорит о том, что в начале 2011 г. появятся коммутаторы 16Gbps. В этом посте немного подробностей о новых продуктах.

Коммутаторы 16Gbps построены на новых ASIC Condor 3 (будут ли Goldeneye 3 я, честно говоря, не знаю). В контексте эволюции поколений эти ASIC являются шестым поколением.

Поколение ASIC	1	2	3	4		5	6	7
ASIC	Stitch	Loom	Bloom, Bloom-II	Condor / Goldeneye	Egret	Condor 2 / Goldeneye 2	Condor 3	?
Количество портов ASIC	2	4	8	32 / 24	bridge chip 3x4Gbps в 12,75Gbps	40 / 24	48
Год выхода	1997	1999	2001	2004	2007	2008	2011	2014
Кол-во портов	2	4	8	32 / 24		40 / 24
Transfer Rate	1,063Gbps	1,063Gbps	2,126Gbps	4,252Gbps	12,75Gbps	8,5Gbps	14,025Gbps	28,05Gbps
Кодирование	8B/10B	8B/10B	8B/10B	8B/10B	64B/66B	8B/10B	64B/66B	64B/66B
Теоретическая макс. Bandwidth half duplex	100 MB/s	100 MB/s	200 MB/s	400 MB/s		800 MB/s	1600 MB/s	3200 MB/s
Реальная макс. Bandwidth half duplex	90 MB/s	95 MB/s	190 MB/s	380 MB/s		760 MB/s	1552 MB/s	3104 MB/s
Внешние модули коммутаторов	GBIC	GBIC	SFP	SFP	XFP	SFP+	SFP+	SFP+
Длина линков OM3 Link	860	860	500	380	300	150	100	60

48 портов Condor 3 работают в режимах 2GFC, 4 GFC, 8 GFC, 10 GFC и 16 GFC (обратите внимание 1 GFC больше не поддерживается, зато поддерживается 10 GFC). По типам, порты могут быть EX/E/F/M/D.
Пропускная способность 768Gbps позволяет передавать до 350 млн. фреймов в сек.

Важной особенностью нового ASIC является использование не классического кодировании 8b/10b, а более экономного 64b/66b. Группа ANSI T11 решила, что теперь именно такой способ кодирования будет стандартом для 10G Ethernet и 16G FC. Это позволяет снизить накладные расходы на кодирование с 25% до 3%.
Как вы помните у Brocade уже были платы с 10GFC на чипах Egret, в которых также использовалось кодирование 64b/66b. Однако, они не были обратно совместимы с классическими 1,2,4,8Gbps, использующими 8b/10b. В отличии от Egret, новый Condor 3 будет совместим с 2,4,8Gbps. Правда, на сколько я понял, 8b/10b-64b/66b autonegotiation работать не будет.

Буферы портов сделаны в 4 раза больше - 8KB (для чего это нужно, я пока не понял). Общего количества буферов хватит для передачи данных на расстояния до 21000 км.
С FOS 7.0 (предположительно, Q2/2011) появится новая функциональность обнаружения и восстановления потерянных буферных кредитов на уровне Virtual Channels. В Condor 2 такая функциональность работала только на уровне портов.

Количество Virtual Channels (VCs) увеличено до 40.
В trunk как и раньше можно объединять до 8x ISLs (в сумме 128Gbps).

В качестве дополнительных вкусностей Condor 3 поддерживает:

Шифрование данных E-порт в E-порт на лету (алгоритм AES-GCM, 256bit ключи) (вроде, будет поддерживаться только с FOS 7.0, Q2/2011)
Компрессия данных E-порт в E-порт (алгоритм McLZO, дополнительная лицензия не нужна) (вроде, будет поддерживаться только с FOS 7.0, Q2/2011)
Совместимость с 10G Ethernet

Что пока известно о продуктах? Будут объявлены директоры DCX 8510, коммутаторы 6510 и 16Gbps HBA. Надеюсь, что маркетинг Brocade все-таки изменит эти интуитивно непонятные названия, например на какой-нибудь DCX+ ;) .

Директоры Brocade DCX 8510-8 и DCX 8510-4:

Максимум до 384 портов 16Gbps
Платы FC16-32 и FC16-48
C FOS 7.0 (предположительно, Q2/2011) поддержка плат FC8-64 (все знают , что такие уже вышли? ;) ), FX8-24 (маршрутизация), FS8-18 (шифрование) и FCoE10-24 (FCoE)
C FOS 7.0 update (предположительно, Q4/2011) поддержка плат FC8-32 и FC8-48 (жаль, что поздновато)
Общая пропускная способность - 8.2Tbps
Пропускная способность на слот - 512Gbps
Архитектура такая же, как и в 8Gbps DCX: 8x ASICs на платах CR и по 2x ASICs на платах ввода-вывода
32x 64Gbps QSFP ICL в директорах DCX 8510-8
16x 64Gbps QSFP ICL в директорах DCX-8510-4
Общая пропускная способность ICL - 2Tbps (в 4x раза больше, чем в директорах 8Gbps)
C FOS 7.0 поддержка для подключения к ICL универсальных оптических кабелей (до 50 метров)
Объединение до 5x директоров при помощи ICL в топологию mesh (можно организовывать core-edge прямо на ICL, правда, oversubscription все равно будет)
Лицензия ICL ports-on-demand

Коммутаторы Brocade 6510

Размер 1U
48 портов 16Gbps FC
Общая пропускная способность - 768Gbps

HBAs Brocade 16 Gbps:

До 1600 MB/sec и 500K IOPs на порт
Поддержка функциональности SR-IOV, QoS, N_Port Trunking

ИТ-афоризмы

noreply@blogger.com (Vasily Pantyukhin) — Tue, 12 Oct 2010 19:02:00 +0000

Во натолкнулся на несколько забавностей... :)

“A fool with a tool is still a fool.”
Дурак с инструментом… все равно дурак.

“Know what you are automating before you automate it.”
Узнайте, что вы автоматизируете, до того, как начнете автоматизировать.

“Real men don't click.”
Реальные пацаны не кликают. (в смысле пользуются только CLI ;) )

“Windows is like a submarine. As soon you open up a window, the problems begins”
Windows как подводная лодка: проблемы начинаются сразу, как только вы откроете окно.

You can have it done right, cheap, or quick. Pick two.
Вам все сделают правильно, дешево и быстро… (подчеркните только два варианта)

“OSI layer 8 error”.
Ошибка восьмого уровня модели OSI.

“Nothing is permanent, except for temporary solutions.”
Ничто так не постоянно, как временное.

“There are only 2 types of people..people that have experienced a harddisk crash and people that are going to expierence a harddisk crash!”
Существуют всего 2 типа людей: те, кто не понаслышке знает, что такое крэш диска, и те, кто уже скоро об этом узнают…

"There are only 10 types of people in the world: Those who understand binary, and those who don't"
В мире существуют только 10 типов людей: тех кто понимает двоичное исчисление и тех кто нет.

Нет повода не...

noreply@blogger.com (Vasily Pantyukhin) — Sun, 10 Oct 2010 18:47:00 +0000

Сегодня я совершенно случайно обнаружил, что день-то праздничный. Это, конечно, не День взятия Бастилии, но повод закусить, определенно, есть... :) По календарю сегодняшнее число 10.10.10. Безмерно ликовать и радоваться можно по двум причинам:

-во первых, 101010 само по себе красиво. Особенно, если вспомнить об этом в 10:10...

-а во вторых, любой ИТ-шник сразу переведет его из bin в dec и получит... о чудо... 42 !!! , что, как всем известно, есть ответ на "Самый главный вопрос жизни, Вселенной и вообще"... ;)

PS я вот все думаю над вопросом... %( может "приборы?"

PPS "Life, the Universe & Tape or Disk" еще раз, для тех кто читал оригинал.. :)))

Статья "Эффективное хранение данных"

noreply@blogger.com (Vasily Pantyukhin) — Fri, 08 Oct 2010 18:40:00 +0000

Журнал опубликовал мою статейку. Исключительно в целях бессмысленного повышения энтропии Вселенной запощу ее и сюда ;) . Оригинал здесь.

PS мне сказали, что название должно быть именно таким... :) от этого и плясал...

"Люди общаются друг с другом посредством слов. Однако некоторые слова от частого использования затираются и теряют свой смысл. От регулярного бездумного употребления превратилось в бессмыслицу и слово “эффективность”. Мы постоянно видим его в маркетинговых брошюрах, слышим в докладах конференций и презентациях продуктов. Постепенно слово перестало что-либо означать, стало просто обязательным атрибутом расхваливания товаров.

В этой статье я тоже хотел бы поговорить об эффективности. Но для начала надо вернуть слову смысл и разобраться, какой же все-таки эффект мы ожидаем получить от пресловутых эффективных продуктов и решений. С точки зрения бизнеса эффективность всегда выражается в денежных единицах. Их можно либо заработать, либо сэкономить. Тот, кто обслуживает информационные системы, знает, что зарабатывать и экономить можно на простоте и скорости администрирования, качественном удовлетворении требований бизнеса к производительности, скорости доступа к информации и надежности ее хранения.

Современная действительность такова, что для того, чтобы оставаться лидером рынка, необходимо постоянно рассчитывать, каков будет реальный эффект от применения каждой новой технологии или продукта. Именно поэтому инновационный подход компании EMC всегда ориентирован на конкретную выгоду заказчиков. В качестве примера рассмотрим несколько наиболее интересных новых технологий хранения данных, а также проследим, какой потенциальный эффект на бизнес они могут оказать.

Начнем с обсуждения очень актуальной проблемы. Мир тонет. Наша маленькая планета буквально захлебывается в колоссальных объемах данных, которые с каждым годом увеличиваются в сумасшедшей прогрессии. Для борьбы с потопом можно, конечно, использовать самый простой метод — постоянно приобретать новые емкости, тем самым, увеличивая доступное пространство хранения. К сожалению, этот способ хорош только на первых порах. После достижения некого критического уровня суммарных емкостей в любой компании остро встают вопросы роста капитальных и операционных затрат (из-за необходимости увеличения площадей серверных комнат для размещения нового оборудования), увеличения численности группы администрирования СХД и поиска дефицитных дорогостоящих “стораджевиков”. Каждый год приходится выкладывать все возрастающие суммы на сервисную поддержку. Мониторинг такого комплекса и управление им превращаются в кошмар. Начинают играть заметную роль факторы, которые раньше совсем не принимались во внимание. Например, стоимость электропитания или отвод тепла из серверной. Безрадостная картина, не правда ли?

К счастью, кроме способа экстенсивного расширения ресурсов существует метод их более интенсивного использования. Для начала задумаемся, каким образом потребляется емкость хранения. Для примера рассмотрим полезные данные размером 1 Tбайт. Помещенные в некую СУБД за счет разреженности они могут занимать заметно больший объем, скажем 2 Tбайт. Объем данных со временем растет, и администратор СХД просто обязан выделять тома с неким запасом по емкости. Допустим, в текущий момент утилизация выделенных томов равна 50%, что в итоге приводит к потреблению 4 Tбайт. Для защиты информации применяется RAID. При использовании зеркалирования RAID10 нам потребуются 8 Tбайт физической емкости. Катастрофоустойчивое решение предполагает реализацию репликации на удаленный дисковый массив, и это приводит к потреблению дополнительных 8 Tбайт. Полное и инкрементальное резервное копирование за неделю потребует не менее 2,5 Tбайт, а для его выполнения в горячем режиме необходимо использовать функциональность мгновенных снимков, что в среднем увеличивает потребление ресурсов хранения еще на 20% от полезного объема. Средам тестирования и разработки также нужна физическая емкость, скажем 500 Гб в RAID5. Итого, в нашем примере при хранении 1 Tбайт полезной информации придется выделить объем более 19 Tбайт. В англоязычной литературе для обозначения потребляемого брутто-объема данных используется термин data footprint. Интересно, что даже небольшое сокращение объема полезных данных, например за счет их архивирования, приведет к значительному снижению потребляемой емкости.

Сокращение data footprint заметно снижает капитальные и операционные затраты и поэтому является одной из основных задач оптимизации хранения данных. Давайте рассмотрим две современных технологии, которые компания EMC предлагает для решения этой задачи: динамическое выделение ресурсов хранения (virtual provisioning) и компрессия данных.

Динамическое выделение ресурсов хранения позволяет не резервировать заранее дисковое пространство под рабочие тома, а автоматически делать это из общего пула ресурсов по мере роста данных. В дисковых массивах CLARiiON в новой 30-й версии операционной среды Flare функциональность пулов была значительно расширена. Поддерживаются RAID 5, 6 и 10. В пуле можно одновременно создавать как классические чуть более производительные “толстые” тома с предварительным резервированием ресурсов, так и динамические “тонкие” тома. Оптимизирована технология динамического расширения пулов при добавлении новых дисков. Теперь это происходит без использования функциональности MetaLUN.

Если серверы заказчика работают с операционной системой Windows Server 2008, для сокращения data footprint в пулах можно применить технологию изъятия неиспользуемых ресурсов томов (LUN shrink). Видимый размер тома уменьшается мгновенно. Реальное же его сокращение реализуется в дисковом массиве при помощи фоновых процессов, которые выискивают 8-Kбайт блоки, заполненные нулями, и возвращают их обратно в пул.

Подобная технология подойдет и владельцам других операционных систем. Для освобождения неиспользуемых ресурсов рекомендуется провести миграцию данных на “тонкие” тома. При этом 8-Kбайт блоки нулей, как и в случае технологии LUN shrink, возвращаются в общий пул. Данная функциональность работает и при миграции данных с других дисковых массивов с помощью SANcopy.

Стоит заметить, что применение общего пула позволяет значительно сократить время создания и расширения ресурсов хранения, тем самым в долговременной перспективе заметно снизить затраты на администрирование комплекса.

Для дополнительного снижения потребляемой емкости можно воспользоваться компрессией томов. При включении эта функциональность совершенно прозрачно для пользователя перемещает данные на “тонкие” тома, освобождая неиспользуемые ресурсы. Во время такой миграции прямо “на лету” обнаруживаются и сжимаются повторяющиеся элементы данных в блоках по 64 Kбайт. К блокам, в которых можно сжать менее 8 Кбайт данных, компрессия не применяется. В дальнейшем для снижения нагрузки на дисковый массив компрессия работает в фоновом режиме, но не постоянно, а только при достижении пороговых значений. Процесс начинается при любом из двух условий: было изменено 10% данных тома или модифицировано 10 Гб информации. При чтении данных сжатая информация загружается в кэш и там автоматически распаковывается. Данные на диске остаются в компрессированном виде. Для контроля нагрузки на процессоры дискового массива каждому тому можно устанавливать один из трех приоритетов. При низком приоритете дополнительная загрузка CPU не превышает 15%.

Независимое тестирование компании Enterprise Strategy Group показало, что 100- Гб том с файловой системой NTFS, заполненный 75 Гб различных данных (видео, документы MS Office, текст, бинарные файлы), после применения компрессии стал занимать всего 54 Гб. Поразительные результаты, правда? Другие тесты показывают, что особенно эффективно использовать сжатие данных в виртуальной среде VMware.

В NAS-устройствах хранения EMC Celerra потребляемую емкость можно сократить за счет одновременного применения компрессии на уровне блоков и дедупликации файлов. Эффект экономии дискового пространства может достигать 50%. Как это работает? Специальный фоновый процесс сканирует устройство хранения и по характеристикам последнего времени доступа и модификации идентифицирует неактивные файлы. Далее такие файлы сжимаются при помощи механизма компрессии, аналогичному используемому в дисковых массивах CLARiiON. Одновременно с этим выполняется вычисление уникального хэша данных файла. Результат записывается в специальную скрытую область. Если хэшы нескольких файлов совпадают, то вместо всех дублированных копий записываются короткие ссылки на оригинальные данные. При модификации файлов перестраиваются ссылки только на измененные блоки. Такой подход позволяет значительно повысить скорость доступа к файлам большого размера.

Еще один эффективный способ сокращения издержек на хранение данных и понижения общей стоимости владения (TCO) — это динамическое выделение ресурсов в зависимости от ценности информации и требований производительности доступа к ней. Именно для этих целей компания EMC предлагает технологию FAST (Fully Automated Storage Tiering), которая позволяет автоматизировать перемещение данных в соответствии с уровнем активности доступа к ним. Вкратце рассмотрим, как это работает. В единый пул ресурсов могут быть объединены накопители трех разных типов flash (EFD), FC и SATA. Дисковый массив постоянно осуществляет мониторинг загрузки томов, на которых включена функциональность FAST, и в соответствии с активностью доступа к ним перемещает блоки данных на наиболее подходящий уровень хранения. “Горячие” данные попадают на производительные накопители flash. Редко требуемые размещаются на дисках SATA. Для обеспечения оптимального соотношения гранулярности перемещения и уменьшения дополнительных накладных расходов, связанных с внутренним копированием данных, данные перемещаются блоками в 1 Гб. Перенос информации осуществляется в соответствии с заранее установленными расписаниями. Приоритеты размещения данных на дисках с различными уровнями производительности могут задаваться специальными правилами.

Возвращаясь к главной теме этой статьи, опять зададимся вопросом: “В чем заключается эффективность?”. Дело в том, что технология FAST позволяет добиваться очень высоких показателей цена/производительность. Оптимальное для каждого конкретного заказчика сочетание накопителей различных типов, объединенных в общий пул ресурсов с заданными требованиями к производительности, позволяет гибко организовывать хранение данных, минимизируя удельную стоимость хранения. При этом решение будет адаптивным. Оно станет динамически приспосабливать комплекс хранения под изменяющиеся нужды бизнеса. Упрощение первоначального планирования размещения данных и отсутствие необходимости постоянной ручной оптимизации производительности дает возможность заметно снизить затраты на управление комплексом хранения. (способы расчета конфигурации под FAST обсуждались здесь)

Как уже упоминалось в начале статьи, мерилом эффективности любой технологии являются выгоды для бизнеса. Нужного эффекта можно достичь тысячами различных способов. Поэтому поиск технологических решений, оптимальных для каждой конкретной компании, - непростая задача, требующая как знаний, так и интуиции. Самым действенным способом выработки нужного решения является обсуждение продуктов и технологических нюансов с коллегами, имеющими опыт реализации и администрирования реально функционирующих комплексов хранения."

PS Картинка к комментарию
Я проверил на демо-массиве, все три типа RAID поддерживаются.

Встреча со Стивом Тодом

noreply@blogger.com (Vasily Pantyukhin) — Mon, 04 Oct 2010 18:51:00 +0000

FYI
К сожалению, только для Питерцев... :( ну, а тем кому повезло ;) , настоятельно рекомендую...

-----Original Message-----
From: emc-academic-alliance-russia-newsletters@googlegroups.com
Sent: Monday, October 04, 2010 10:41 PM
To: EMC Academic Alliance Russia Newsletters
Subject: EMC Academic Alliance Russia Newsletter #35/10

Уважаемые коллеги!

Сотрудник корпорации ЕМС Стив Тод (Steve Todd)
http://stevetodd.typepad.com/my_weblog/steve-todd-curriculum-vitae.html
занимает должность инженера.
Однако его интересы простираются далеко за пределы его должностных
функций.
Его врожденные способности к систематизации информации и искренний
интерес к информационным технологиям, вместе со способностями к работе
с аудиторией привели к тому, что Стив
- написал и издал книгу по основам корпоративного предпринимательства,
- регулярно проводит публичные выступления как перед сотрудниками
различных подразделений корпорации, так и перед сотрудниками других
корпораций и студенческой аудиторией различных стран.

Стив приезжал и в Россию год назад.
Его выступление запомнилось непринужденностью обстановки, яркой
харизмой и умением просто рассказать о сложном.
Уверен, те кто был на встрече с Тодом захотят прийти снова.
Не только захватывающе, но и поучительно посмотреть как технический
специалист может позиционировать себя в качестве собеседника и
соучастника.

Встречайте:

Стив Тодд, заслуженный инженер компании EMC, прочитает лекцию "Global
High-Tech Innovations" сразу в двух петербургских вузах:

7 октября в четверг в 16 30 в Санкт-Петербургском государственном
университете информационных технологий, механики и оптики (ИТМО,
Кронверский пр, актовый зал)
и

8 октября в пятницу в 13 00 в Санкт-Петербургском государственном
университете (СПБГУ, Петергоф, Университетский пр., д.28, мат-мех,
ауд. 405)

Стив Тодд является заслуженным инженером в корпорации EMC. Созданная
им программная реализация технологии RAID была одной из первых и
наиболее успешных за всю историю индустрии хранения данных. В мире
установлено более полумиллиона устройств хранения CLARiiON, которые
защищают наиболее важную и критичную информацию планеты с помощью
созданных Стивом алгоритмов. Стив является (со)автором более чем 160
патентов в различных областях информационных технологий.
Лекция будет посвящена следующим основным вопросам:
-    Глобализация инноваций
-    Последние инновационные достижения в мире, созданные разработчиками
программного обеспечения
-    Изменение корпоративной культуры в области инноваций на примере
корпорации EMC
-    Советы по успешной карьере в области ИТ

Блог Стива Тодда: http://bit.ly/aaMVWi
Книга Стива Тодда "Инновации, влияющие на мир" http://www.booklocker.com/books/4145.html

Регистрация:
http://vkontakte.ru/event20037521 - ИТМО
http://vkontakte.ru/event20043544    - СПБГУ

PS. Встреча пройдет на хорошем международном английском языке. Перевод и запись ранее обсуждались, но положительного решения пока нет

Приостановка передачи в SAN

noreply@blogger.com (Vasily Pantyukhin) — Sat, 02 Oct 2010 20:43:00 +0000

Один из читателей блга прислал мне чрезвычайно интересный вопрос по поводу приостановки передачи данных в фабрике. Дмитрий, большое спасибо.
Ответом я решил поделиться со всеми и сделал из него такой короткий пост. Сори, если он получился слишком техническим и не понятным…

Одними из наиболее распространенных причин приостановки передачи данных в фабрике сети SAN являются процессы перестроения (Build Fabric) и реконфигурации фабрики (Reconfigure Fabric).

Для начала разберемся в принципиальных различиях между ними.
Процесс Build Fabric (BF) является не разрушающим (non-disruptive), т. е. хотя передача данных на какой-то небольшой период времени приостанавливается, но никакая информация не теряется. Это связано с тем, что списки Domain ID не обнуляются и адресация всех устройств гарантированно сохраняется. Principal Switch, приоритеты и маршруты передачи остаются прежними. Открытые exchange не сбрасываются.

Процесс Reconfigure Fabric (RCF), напротив, является разрушающим (disruptive) и передаваемые данные всегда теряются. Ведь списки Domain ID непременно сбрасываются и Domain ID назначаются заново. Если Domain ID какого-либо коммутатора изменился, после обязательного повторного логина в фабрику всех оконечных устройств изменятся и адреса соответствующих N-портов. При RCF весь трафик класса F прерывается. Обязательно начинается процесс перевыборов Principal Switch. По времени RCF продолжительнее, чем BF.

Ниже приведены несколько примеров ситуаций, для разрешения которых используются эти процессы.

Новый коммутатор с чистым списком Domain ID присоединяется к уже функционирующей фабрике. Ему нужно назначить Domain ID, поэтому начнется процесс BF.
Сливаются две продуктивные фабрики, имеющие собственные списки Domain ID. При этом, одинаковых Domain ID в этих фабриках нет. В этом случае необходимо вместо двух независимых Principal Switch выбрать один. В ходе процесса BF выбирается новый единый Principal Switch.
Предыдущий случай, но в фабриках есть совпадающие Domain ID. Конфликт надо разрешить, поэтому начинается процесс RCF.
Соединяются два новых коммутатора с девственно чистыми списками Domain ID. Начинаются выборы Principal Switch и, соответственно, процесс BF (или RCF).
Если по каким-то причинам разрывается upstream principal ISL. Для нахождения альтернативного пути запускается BF. Если такой путь не найден, то после BF проходит RCF.
Если какой-то коммутатор пытается достигнуть Domain ID, которого нет в фабрике, Principal Switch начинает RCF.
В случае наличия сегментированных портов, модернизация микрокода может вызвать BF или даже RCF.
При разрыве trunk master в 1Gbps и 2Gbps коммутаторов Brocade запускается BF.
Если Principal Switch выключился или начал перегружаться, начинаются перевыборы и процесс RCF.
Если по какой-то причине процесс BF закончился не удачно (не были получены пакеты подтверждения), начинается RCF.
В коммутаторах Cisco вы можете принудительно вручную рестартовать домен. При disruptive restart запускается RCF, при nondisruptive restart – BF. Сделать disruptive restart обязательно придется, если захочется сменить текущее значение Domain ID (например, для разрешения конфликта). Изменение параметра Preferred Domain ID по понятным причинам потребует всего лишь nondisruptive restart.

Избежать задержек передачи данных в результате BF или RCF не возможно. Ведь эти процессы предназначены для обеспечения жизнедеятельности самой фабрики. Однако, в некоторых случаях можно значительно сократить время BF и минимизировать его влияние на коммутаторы. Так, в коммутаторах Cisco при включенной опции fast restart, выход из строя Principal Link не вызывает полноценный Build Fabric. Если между коммутаторам существует дублирующий линк, то процесс его назначения Principal Link затронет не всю VSAN, а только два соответствующих коммутатора и займет всего несколько миллисекунд. Если дублирующего линка нет, то опция, конечно не поможет…

Остается вопрос, как же все-таки минимизировать воздействие описанных выше процессов на SAN? Ответ вы, конечно, знаете сами. Обязательное построение сети хранения в виде двух физически или логически (VSAN) изолированных друг от друга redundant фабрики вкупе с ПО multipathing!!!

Добавлено Brocade утверждает,что в современных релизах FOS Reconfigure Fabric никогда не происходит. Охотно верю.