Мне регулярно приходится читать документы в которых псевдо-наукообразие слога органично сочетается с полной бессмыслицей и попиранием основ Великого-Могучего. Лидером популярности употребления в таких документах, бесспорно, является слово "системный". Считается, что его округлое, чуть щелестящее звучаение успокаивает заказчика и притупляет критическое восприятие действительности, что, в свою очередь, позволяет быстренько ему что-нибудь втюхать.
Надо отдать должное, что обычно "системщину" в документы наливают дозировано. Достаточно, что бы запутать читателя и уверить его в том, что его природное скудоумие все равно не позволит проникнуться глубиной проработки вопроса, но не до полного отрубона мозгов и потери ориентации в пространстве. Однако иногда появляются по настоящему шедевральные эпосы. Как-то мне на проработку проекта попался в руки документ, составленный в одном из крупных интеграторов. В первых же 7 предложениях вариации на слово "системный" встретились 15!!! раз. Например, "Повышение доступности систем реализуется путем построения системы быстрого автоматического развертывания данных систем в резервном вычислительном центре". Звучит, как мантра, а прочтение всего документа вобще вводит в транс.
Силища!!! Уж поверьте мне, Системному архитектору...
31 марта 2010 г.
28 марта 2010 г.
RAID write penalty
Отношение количества Back-end и Front-end операций при записи данных называется Write Penalty (WP).
WP зависит от типа нагрузки и уровня RAID. Чем ниже ее значение, тем более эффективно работает этот тип RAID на операциях записи.
Рассмотрим некоторые примеры:
Замечу, что т. к. WP RAID5 full stripe <2, при последовательной записи RAID5 будет заметно производительней RAID10. Чем больше шпинделей, тем меньше WP.
WP зависит от типа нагрузки и уровня RAID. Чем ниже ее значение, тем более эффективно работает этот тип RAID на операциях записи.
Рассмотрим некоторые примеры:
- RAID10 WP=2.
- RAID5 WP=4.
- RAID6 WP=6.
- RAID5 запись полным страйпом (full stripe write, MR3) WP=1+1/#data disks.
Замечу, что т. к. WP RAID5 full stripe <2, при последовательной записи RAID5 будет заметно производительней RAID10. Чем больше шпинделей, тем меньше WP.
- RAID5 full stripe write если есть cache backfill WP=1+(1+#back fill disks)/#data disks.
- Clariion snapshot RAID5 Flare R24 WP=7.25, Flare R26 WP=6.50.
- Clariion snapshot фрагментированный RAID5 Flare R24 WP=10.50.
- Clariion snapshot RAID10 Flare R24 WP=8, Flare R26 WP=6.
26 марта 2010 г.
Заметки на полях (Clariion RAID)
- Stripe element size = 64KB или 128 блоков. Менять его не стоит.
- Использование RAID6 при random writes маленькими блоками нагружает backend на 50% больше по сравнению с RAID5 . Sequential writes в RAID6 на 10% медленнее, чем в RAID5. Random и sequential reads – одинаково.
- При random writes маленькими блоками или выключенном write cache RAID5 и RAID6 заметно проигрывают RAID10.
- Чем меньше дисков в RAID5, тем лучше уровень защиты и меньше время RAID reconstruction.
- Оптимальный размер RAID5 - 4+1. Больше 9+1 делать категорически не стоит.
- Оптимальный размер RAID6 - 8+2 (распределенный между различными шинами 2 DAE 5+5) или 10+2 (распределенный между 3 DAE 5+5).
- RAID3 лучше использовать при sequential reads >2MB и размерах блока >64KB.
- Считается, что RAID10 стоит выбирать при random read >20%.
- В RAID10 уровень защиты и время RAID reconstruction от количества дисков не зависит.
- Backend IOPS = read% * frontend IOPS + WP * write% * frontend IOPS, Backend MB/s = read MB/s + WP * write MB/s . Например, IO блоками 8KB 70/30 r/w, RAID5, 2000 frontend IOPS, backend IOPS=0,7*2000+0,3*4*2000=1400+2400=3800
- Primary и Secondary sub-mirrors в RAID10 рекомендуется создавать на различных buses (удобнее скриптом из CLI).
- Создание RAID5 на дисках DAE на различных buses уменьшает время rebuild.
- Процесс RAID group expansion очень сильно понижает производительность всего массива.
16 марта 2010 г.
И на старуху проруха
Начну издалека. Переехала наша семья около года назад в новую квартиру с таким длииинным коридором. Я сразу настроил IDSL и WiFi для наших нескольких ноутбуков и принтера. Все отлично работало, но... в связи с отсутствием телевизора, появилась у нас приятная привычка во время ужина на кухне смотреть какие-нибудь мультики или фильмы. И вот незадача, мультфильмы реально притормаживают. Изображение застревает на несколько секунд и чихает.
Всякое файло у нас лежит на самодельном NAS и отдается наружу через точку доступа, находящейся в "большой" комнате. Берем ноутбук и идем по коридору в комнату... становится все лучше и лучше... возвращаемся обратно, снова все портится. Какой вывод? Кирпичные стены с арматурой как-то экранируют и гадят сигнал.
А надо отметить, не люблю я всю эту возню с домашней электроникой. Купил, когда без этого уже нельзя обойтись, потратил пару часов на настройку и забыл рутовые пароли... докручивание и тюнинг противоречат моему представлению о комфортных домашних устройствах. В общем, по ленности своей я все время откладывал решение проблемы. О системном подходе, не могло быть и речи... какое-там сканирование сети и анализ ;) Раз на кухне работает хуже, чем в комнате, значит надо как-то усилить сигнал. И вот, в прошлое воскресенье я случайно наткнулся на Linksys-овскую точку доступа, подаренную когда-то мега-корпорацией Cisco и валявшуюся в забытом уголке шкафа. Увидел и решил все-таки попробовать установить эту коробочку на кухне и настроить WDS. Потратил кучу времени на апгрейд фирмвари, покурил документацию и выяснил, что, во первых, мой Linksys не поддерживает WDS, во вторых, если бы даже поддерживал, то не обязан был бы работать с основной точкой доступа Netgear, а в третьих WDS вобще не работает с WPA, что совсем не зер гут.
Разочарованный поражением, я решил попить чайку и между делом подумал, о том, что не плохо было бы попробовать поменять канал, на котором работает моя точка доступа. Через 30 секунд все заработало просто отлично. И тут я сразу вспомнил о системном подходе, скачал софтинку и просканировал WiFi сети вокруг. Оказалось, что на канале, на который была настроена моя беспроводная сеть висели еще 2 соседские точки доступа. Гипотеза об экранировании была верна... но наоборот. Не на кухне искажался мой полезный сигнал, а в комнате экранировались помехи. :)
Всякое файло у нас лежит на самодельном NAS и отдается наружу через точку доступа, находящейся в "большой" комнате. Берем ноутбук и идем по коридору в комнату... становится все лучше и лучше... возвращаемся обратно, снова все портится. Какой вывод? Кирпичные стены с арматурой как-то экранируют и гадят сигнал.
А надо отметить, не люблю я всю эту возню с домашней электроникой. Купил, когда без этого уже нельзя обойтись, потратил пару часов на настройку и забыл рутовые пароли... докручивание и тюнинг противоречат моему представлению о комфортных домашних устройствах. В общем, по ленности своей я все время откладывал решение проблемы. О системном подходе, не могло быть и речи... какое-там сканирование сети и анализ ;) Раз на кухне работает хуже, чем в комнате, значит надо как-то усилить сигнал. И вот, в прошлое воскресенье я случайно наткнулся на Linksys-овскую точку доступа, подаренную когда-то мега-корпорацией Cisco и валявшуюся в забытом уголке шкафа. Увидел и решил все-таки попробовать установить эту коробочку на кухне и настроить WDS. Потратил кучу времени на апгрейд фирмвари, покурил документацию и выяснил, что, во первых, мой Linksys не поддерживает WDS, во вторых, если бы даже поддерживал, то не обязан был бы работать с основной точкой доступа Netgear, а в третьих WDS вобще не работает с WPA, что совсем не зер гут.
Разочарованный поражением, я решил попить чайку и между делом подумал, о том, что не плохо было бы попробовать поменять канал, на котором работает моя точка доступа. Через 30 секунд все заработало просто отлично. И тут я сразу вспомнил о системном подходе, скачал софтинку и просканировал WiFi сети вокруг. Оказалось, что на канале, на который была настроена моя беспроводная сеть висели еще 2 соседские точки доступа. Гипотеза об экранировании была верна... но наоборот. Не на кухне искажался мой полезный сигнал, а в комнате экранировались помехи. :)
15 марта 2010 г.
Странный read prefetching
В прошлом посте я немного рассказал, как работает read prefetching. Продолжая эту тему, я хочу привести один интересный пример анализа предвыборки данных. К слову, это графики реально работающеuj Clariion. Я натолкнулся на них несколько дней назад, анализируя производительность массива одного из наших заказчиков.
Попробуйте предложить несколько гипотез, почему при таком достаточно стабильном и очень высоком значении метрики Used Prefetches, говорящей о высокой эффективности предварительной выборки данных, график относительного количества попаданный в кэш Read Cache Hit Ratio имеет несколько ошеломляюще огромных провалов.
Не читайте пока дальше, подумайте пару минут….
Мой вариант объяснения такого, странного на первый взгляд, поведения сразу становится очевиден, если вы посмотрите на следующий график:
Значительное уменьшение Read Size приводит к очень сильному росту Throughput.
Запросы на чтение последовательны, но поступают они с очень высокой скоростью (Throughput). Поэтому, конечно, Prefetching срабатывает и молотит на полную катушку. Однако, данные предвыборки не успевают быть доставлены с медленных дисков в кэш до того, как на них поступает запрос. Это, конечно ведет к увеличению событий Read miss и, соответственно, провалам в Read Cache Hit Ratio.
Если бы такие запросы были бы постоянными, то разумнее всего было бы вообще выключить prefetching для этого LUN. Тем не менее, учитывая высокое количество запросов блоками большого размера в другие промежутки времени, делать это все-таки не разумно.
Попробуйте предложить несколько гипотез, почему при таком достаточно стабильном и очень высоком значении метрики Used Prefetches, говорящей о высокой эффективности предварительной выборки данных, график относительного количества попаданный в кэш Read Cache Hit Ratio имеет несколько ошеломляюще огромных провалов.
Не читайте пока дальше, подумайте пару минут….
Мой вариант объяснения такого, странного на первый взгляд, поведения сразу становится очевиден, если вы посмотрите на следующий график:
Значительное уменьшение Read Size приводит к очень сильному росту Throughput.
Запросы на чтение последовательны, но поступают они с очень высокой скоростью (Throughput). Поэтому, конечно, Prefetching срабатывает и молотит на полную катушку. Однако, данные предвыборки не успевают быть доставлены с медленных дисков в кэш до того, как на них поступает запрос. Это, конечно ведет к увеличению событий Read miss и, соответственно, провалам в Read Cache Hit Ratio.
Если бы такие запросы были бы постоянными, то разумнее всего было бы вообще выключить prefetching для этого LUN. Тем не менее, учитывая высокое количество запросов блоками большого размера в другие промежутки времени, делать это все-таки не разумно.
13 марта 2010 г.
Read prefetching в Clariion
Предварительная выборка данных с дисков в кэш при запросах на чтение называется Prefetching. Используя эту функциональность Storage Processor (SP) пытается заранее приготовить данные, которые могут понадобиться серверу в ближайшем будущем (механизм read-ahead). Получив запрос на чтение двух последовательно идущих блоков и обнаружив их отсутствие в кэш (read miss), SP в рамках одной или нескольких операций считывает с дисков не только запрашиваемые данные, но и определенное количество последующих блоков. Во многих случаях такой подход дает очень значительный выигрыш в производительности по сравнению со стандартной обработкой отдельных read misses.
Read prefetching настраивается индивидуально для каждой LUN. Возможны 3 типа предвыборки данных (Prefetch type)
В случае variable type вместо Prefetch size и Segment size должны настраиваться Prefetch multiplier и Segment multiplier. Они задают соотношение размера затребованного блока и объема Prefetching. Так при размере блока 16KB, Prefetch multiplier 8 и Segment multiplier 4, будет осуществляться предварительная выборка данных двумя сегментами по 64KB. По умолчанию оба параметра multiplier равны 4.
При запросах очень большого размера prefetching перестает работать эффективно и тратит ресурсы дискового массива вхолостую. Поэтому его лучше отключить. Параметр Disable size говорит системе когда это следует сделать. Он дается в количестве блоков (по 512KB) и по умолчанию равен 129 (чуть больше 64KB).
Скорость доставки данных при prefetching определяется производительностью дисков. При большом количестве последовательных запросов (обычно маленькими блоками) система просто не успевает сделать предвыборку и prefetching начинает просто мешать. Параметр Idle count (честно говоря не понимаю, при чем здесь idle, хотя причина такого названия, скорее всего историческая... в старых документах определение параметра было другим) ограничивает количество необработанных запросов к LUN, при котором работает prefetching. По умолчанию, если количество таких запросов превышает 40, предвыборка выключается.
Read prefetching настраивается индивидуально для каждой LUN. Возможны 3 типа предвыборки данных (Prefetch type)
- none – функциональность выключена на данном томе
- constant – размер предварительной выборки данных фиксирован
- variable – размер предварительной выборки данных зависит от размер запрашиваемого блока (задан по умолчанию)
В случае variable type вместо Prefetch size и Segment size должны настраиваться Prefetch multiplier и Segment multiplier. Они задают соотношение размера затребованного блока и объема Prefetching. Так при размере блока 16KB, Prefetch multiplier 8 и Segment multiplier 4, будет осуществляться предварительная выборка данных двумя сегментами по 64KB. По умолчанию оба параметра multiplier равны 4.
При запросах очень большого размера prefetching перестает работать эффективно и тратит ресурсы дискового массива вхолостую. Поэтому его лучше отключить. Параметр Disable size говорит системе когда это следует сделать. Он дается в количестве блоков (по 512KB) и по умолчанию равен 129 (чуть больше 64KB).
Скорость доставки данных при prefetching определяется производительностью дисков. При большом количестве последовательных запросов (обычно маленькими блоками) система просто не успевает сделать предвыборку и prefetching начинает просто мешать. Параметр Idle count (честно говоря не понимаю, при чем здесь idle, хотя причина такого названия, скорее всего историческая... в старых документах определение параметра было другим) ограничивает количество необработанных запросов к LUN, при котором работает prefetching. По умолчанию, если количество таких запросов превышает 40, предвыборка выключается.
10 марта 2010 г.
Первый телефонный звонок
Календарь показывает, что именно сегодня 10 марта в 1876 г. Александром Беллом был сделан первый телефонный звонок. На самом деле это не совсем так. Прибор для передачи звуков электромагнитным током без использования батареи был готов еще в июле 1875 г. Его идея появилась когда во время опытов свободный конец одной из пластинок на передающей стороне линии по какой-то причине приварился к контакту. Ассистент Белла механик Томас Ватсон устраняя эту неисправность начал нецензурно ругаться. Белл в это время работал с приемными пластинками в другой комнате. Именно едва различимое среди шума крепкое словцо помощника натолкнуло изобретателя на идею использования для передачи голоса тока магнитной индукции.
А вот первый успешный двухсторонний телефонный звонок был сделан действительно 10 марта. Ватсон смог не только услышать известную фразу Белла: "Ватсон, идите сюда, я хочу вас видеть", но и ответить на нее.
Спустя всего 5 месяцев был сделан первый звонок на большое расстояние. Белл позвонил с семейной фермы Брентфорд, находящейся в Канаде, в Париж... который расположен в том же округе Онтарио на расстоянии 16 км. Ох уж эти североамериканцы, со своими "оригинальными" географическими названиями... :)
Телефон, запатентованный Александром Беллом, назывался "говорящий телеграф". Его трубка служила по очереди и для передачи, и для приёма человеческой речи и не имела звонка. Для вызова использовался свисток. Звонок был изобретён ассистентом Белла Томасом Ватсоном парой лет позже.
Сам Белл не любил пользоваться своим изобретением. Он говорил: "Я не могу позволить себе роскошь, чтобы ход моих рассуждений прерывали. В момент зарождения идеи мой ум напоминает идеально гладкую водную поверхность. А звонок телефона в этот момент вызывает такой же эффект, как упавший в воду кирпич. Когда я думаю, то не желаю, чтобы кто-либо меня беспокоил. Сообщения могут подождать. Идеи - нет!". Золотые слова... ;)
В августе 1877 г. между Томасом Эдисоном и Александром Беллом возник принципиальный спор. Эдисон утверждал, что лучшим вариантом приветствия по телефону является слово "hello" (привет), а вот Белл считал лучшим вариантом слово "ahoy" (Эй, кто там?). Как мы знаем, победил Эдисон....
Александр Белл умер в 1922 г. В знак уважения в день его похорон в США на одну минуту были прекращены все телефонные разговоры. Спустя 47 после изобретения в Штатах было уже более 13 миллионов телефонов.
А вот первый успешный двухсторонний телефонный звонок был сделан действительно 10 марта. Ватсон смог не только услышать известную фразу Белла: "Ватсон, идите сюда, я хочу вас видеть", но и ответить на нее.
Спустя всего 5 месяцев был сделан первый звонок на большое расстояние. Белл позвонил с семейной фермы Брентфорд, находящейся в Канаде, в Париж... который расположен в том же округе Онтарио на расстоянии 16 км. Ох уж эти североамериканцы, со своими "оригинальными" географическими названиями... :)
Телефон, запатентованный Александром Беллом, назывался "говорящий телеграф". Его трубка служила по очереди и для передачи, и для приёма человеческой речи и не имела звонка. Для вызова использовался свисток. Звонок был изобретён ассистентом Белла Томасом Ватсоном парой лет позже.
Сам Белл не любил пользоваться своим изобретением. Он говорил: "Я не могу позволить себе роскошь, чтобы ход моих рассуждений прерывали. В момент зарождения идеи мой ум напоминает идеально гладкую водную поверхность. А звонок телефона в этот момент вызывает такой же эффект, как упавший в воду кирпич. Когда я думаю, то не желаю, чтобы кто-либо меня беспокоил. Сообщения могут подождать. Идеи - нет!". Золотые слова... ;)
В августе 1877 г. между Томасом Эдисоном и Александром Беллом возник принципиальный спор. Эдисон утверждал, что лучшим вариантом приветствия по телефону является слово "hello" (привет), а вот Белл считал лучшим вариантом слово "ahoy" (Эй, кто там?). Как мы знаем, победил Эдисон....
Александр Белл умер в 1922 г. В знак уважения в день его похорон в США на одну минуту были прекращены все телефонные разговоры. Спустя 47 после изобретения в Штатах было уже более 13 миллионов телефонов.
9 марта 2010 г.
Morley Parity
В большинстве книжек, объясняющих устройство RAID5, показана следующая картинка:
В случае дисковых массивов Clariion, классическая схема претерпевает несколько изменений. Во первых, если посмотреть на "моргание лампочек" при нагрузке на RAID group, можно заметить, что огоньки бегут справа на лево. Это означает, что адресация LBA томов в RAID организована начиная с дисков с большими номерами:
Во вторых, с FLARE версии 22 parity "перемещается" на следующий диск не в каждом stripe, а чередуя 8 stripes подряд. Такая организация называется Parity Morley.
Скептик сразу заметит, что такие большие блоки надо еще поискать. Соглашусь с этим лишь отчасти. Кроме очевидных IO patterns резервного копирования или потоковой записи изображений, существуют масса других приложений, инициирующих в Back-end операции чтения или записи большими блоками. Во первых, необходимо учитывать процесс предвыборки данных при чтении (read prefetch). А во вторых возможности "склеивания" нескольких последовательно идущих операций записи в Back-end блоки больших размеров (write coalescing).
RAID6 тоже использует Morley Parity.
Желающие отключить Morley Parity (ума не приложу, зачем это может понадобиться) могут использовать следующую команду naviseccli –h bind –messner r5 –parityelements 1
В случае дисковых массивов Clariion, классическая схема претерпевает несколько изменений. Во первых, если посмотреть на "моргание лампочек" при нагрузке на RAID group, можно заметить, что огоньки бегут справа на лево. Это означает, что адресация LBA томов в RAID организована начиная с дисков с большими номерами:
Во вторых, с FLARE версии 22 parity "перемещается" на следующий диск не в каждом stripe, а чередуя 8 stripes подряд. Такая организация называется Parity Morley.
Что нам дает использование этой схемы? Такой подход позволяет более эффективно выполнять операции с большими блоками. Ведь вместо записи или чтения отдельных stripe elements по 64KB, дисковый массив может оперировать в Back-end данными размером до 512KB на каждый шпиндель. Величина "выигрыша" зависит от того, с какими блоками выполняется опрерация. На картинке ниже приведены 2 примера, поясняющих это:
Скептик сразу заметит, что такие большие блоки надо еще поискать. Соглашусь с этим лишь отчасти. Кроме очевидных IO patterns резервного копирования или потоковой записи изображений, существуют масса других приложений, инициирующих в Back-end операции чтения или записи большими блоками. Во первых, необходимо учитывать процесс предвыборки данных при чтении (read prefetch). А во вторых возможности "склеивания" нескольких последовательно идущих операций записи в Back-end блоки больших размеров (write coalescing).
RAID6 тоже использует Morley Parity.
Желающие отключить Morley Parity (ума не приложу, зачем это может понадобиться) могут использовать следующую команду naviseccli –h bind –messner r5 –parityelements 1
6 марта 2010 г.
Афоризмы Дейкстры
В посте про маршрутизацию в SAN я упоминал, что протокол FSPF использует алгоритм Дейкстры. Вот несколько фактов об этом интересном человеке.
Э́дсгер Ви́бе Де́йкстра (Edsger Wybe Dijkstra) известен своим вкладом в теорию графов, создание операционной системы THE, появление семафоров для синхронизации процессов в многозадачных системах, методологию структурного программирования, разработку языка программирования Алгол. Этот острый на язык человек также является автором широко известных высказываний о программировании и компьютерных системах, многие из которых впоследствии стали народными афоризмами.
Приведу здесь некоторые:
Э́дсгер Ви́бе Де́йкстра (Edsger Wybe Dijkstra) известен своим вкладом в теорию графов, создание операционной системы THE, появление семафоров для синхронизации процессов в многозадачных системах, методологию структурного программирования, разработку языка программирования Алгол. Этот острый на язык человек также является автором широко известных высказываний о программировании и компьютерных системах, многие из которых впоследствии стали народными афоризмами.
Приведу здесь некоторые:
- “Приходится признать, что главная задача компьютерной науки — «не запутать все до неузнаваемости» — так и не была достигнута. Увы, большинство наших систем слишком сложны, чтобы не тревожиться об их состоянии, они слишком хаотичны и запутанны, чтобы с ними можно было чувствовать себя уверенно и спокойно”
- “Практически невозможно научить хорошо программировать студентов, ориентированных первоначально на БЕЙСИК: как потенциальные программисты они умственно оболванены без надежды на исцеление”
- “Использование Кобола калечит ум. Его преподавание, следовательно, должно рассматриваться как уголовное преступление”
- “Вопрос «умеет ли компьютер думать» имеет не больше смысла, чем вопрос «умеет ли подводная лодка плавать»”
- “Проекты, предлагающие программирование на естественном языке, гибельны по своей сути”
- “Невозможно заточить карандаш тупым топором. Столь же тщетно пытаться сделать это десятком тупых топоров”
- Решение СССР клонировать компьютеры IBM/360 при разработке серии ЕС ЭВМ было названо Дейкстрой, который в то время работал на одного из конкурентов IBM, “величайшей диверсией Запада против СССР”
2 марта 2010 г.
Кем быть
Нужные работники столяры и плотники... Работают в соответсвии с должностными инструкциями на основании записи в трудовой книжке. Хорошие специальности, понятные.
А вот есть другие профессии, ну совсем не понятные. Для многих из нас известная история про папу тапера в борделе давно уже не анекдот, а суровая правда. Ну на самом деле, на вопрос "чем занимаешься?" порой, трудно понятно ответить даже своему брату IT-шнику, не то что человеку далекому от этих высоких сфер..
Ситуацию усугубляет полная неразбериха с названиями должностей. Размытые силуэты "менеджеров" и "консультантов" вряд ли когда-нибудь создадут четкое представление о роде занятий человека, носящего сей гордый титул. В западных компаниях еще круче. Позиция, на которую берут человека, обычно называется по английски. А вот перевод названия на великий-могучий - это занятие, требующее смекалки и выдумки.
Вот, например, возьмем меня... рядового Solutions Architect. Большой Англа-Русский словарь и творческий размах - это все, что было нужно для создания такого шедевра в моей трудовой книжке:
"Специалист по принятию решений"... принять решение или , чисто, вопросы порешать (solutions)? это комне, обращайтесь... ;)
Ну, и немного о том, чем все-таки на самом деле приходится заниматься. Лет 5 назад с какой-то рабочей проблемой пришла одна из наших менеджеров, очень, кстати, милая девушка, и сказала (дословно): "Вася, меня все послали на%^& и я пришла к тебе...". С тех пор ко мне все ходят и ходят...
А вот есть другие профессии, ну совсем не понятные. Для многих из нас известная история про папу тапера в борделе давно уже не анекдот, а суровая правда. Ну на самом деле, на вопрос "чем занимаешься?" порой, трудно понятно ответить даже своему брату IT-шнику, не то что человеку далекому от этих высоких сфер..
Ситуацию усугубляет полная неразбериха с названиями должностей. Размытые силуэты "менеджеров" и "консультантов" вряд ли когда-нибудь создадут четкое представление о роде занятий человека, носящего сей гордый титул. В западных компаниях еще круче. Позиция, на которую берут человека, обычно называется по английски. А вот перевод названия на великий-могучий - это занятие, требующее смекалки и выдумки.
Вот, например, возьмем меня... рядового Solutions Architect. Большой Англа-Русский словарь и творческий размах - это все, что было нужно для создания такого шедевра в моей трудовой книжке:
"Специалист по принятию решений"... принять решение или , чисто, вопросы порешать (solutions)? это комне, обращайтесь... ;)
Ну, и немного о том, чем все-таки на самом деле приходится заниматься. Лет 5 назад с какой-то рабочей проблемой пришла одна из наших менеджеров, очень, кстати, милая девушка, и сказала (дословно): "Вася, меня все послали на%^& и я пришла к тебе...". С тех пор ко мне все ходят и ходят...
1 марта 2010 г.
Маршрутизация и агрегирование каналов в SAN
Об утилизации каналов и локализации трафика здесь...
Маршрутизация – это процесс определения точного пути передачи фреймов между оконечными устройствами. Для построения таблиц маршрутизации в коммутаторах фабрики используется протокол FSPF (Fabric Shortest Path First), основанный на алгоритме Дейкстры (Dijkstra). Каждому ISL в фабрике ставится в соответствие значение веса (cost), зависящее от Transfer Rate линка. Вес линка можно установить и вручную. Общий вес пути равен сумме весов всех ISLs из которых он состоит. При наличии нескольких возможных путей между сервером и дисковым массивом, данные всегда передаются по пути с наименьшим весом.
В случае, если между двумя оконечными устройствами существуют сразу несколько путей с одинаковым весом, решение о доставке по конкретному маршруту принимается на основании следующих политик:
Важно понимать, что политики маршрутизации различаются только принципами, по которым парам портов взаимодействующих оконечных устройств на некую продолжительность времени выделяется один из эквивалентных путей передачи. Политики 1 и 2 никак не зависят от нагрузки или типа ввода-вывода. По сути, маршрут выдается на все время, пока устройства будут подключены к фабрике (имеется ввиду логическое подключение, например, перегрузка драйвера HBA может привести к изменению маршрута).
Продолжительность выделения маршрута в политике 3 зависит от объема данных FCP-обмена (exchange) и, следовательно, может варьироваться в очень широких пределах. Поэтому данные различных приложений будут неравномерно загружать доступные пути.
Из вышесказанного следует, что маршрутизация в фабрике не может балансировать нагрузку (load-balancing). Применяемые политики позволяют только с той или иной степенью равномерности разделять нагрузку (load-sharing) между эквивалентными с точки зрения FSPF путями.
Однако, в коммутаторах Brocade существует способ балансировки нагрузки на уровне фабрики. Имеется ввиду агрегирование каналов двух непосредственно соединенных друг с другом коммутаторов, которое называется транкинг (Trunking). При передаче данных по логическому агрегированному каналу, коммутаторы оптимальным образом распределяют фреймы по линкам, составляющим транк (до 4x каналов в транке в 1/2Gbps и до 8x в 4/8Gbps коммутаторах). Т. е. балансировка нагрузки происходит на уровне фреймов размером 2KB, что достаточно эффективно. Между несколькими транками, так же, как и между обычными ISL, возможен load-sharing на уровне маршрутизации.
Функциональность агрегирования каналов, реализованная в коммутаторах Cisco, называется Port Channel. К сожалению, в отличие от Brocade Trunking, она не балансирует нагрузку на уровне фреймов. По сути, это просто дополнительная опция к политикам маршрутизации Exchange-based или Flow-based. Нагрузка просто разделяется между линками, составляющими агрегированный канал, на уровне FCP-обменов или потоков. Однако, в отличие от неагрегированных линков, таблицы маршрутизации Port Channel являются общими для всех линков, составляющих логический канал (до 16x). Поэтому при разрыве или добавлении физического линка, протоколу FSPF нет необходимости прерывать передачу трафика во всей фабрике и начинать достаточно ресурсоемкую процедуру обследования путей.
Обратите внимание на то, что функциональность Cisco Trunking используется совсем в другом контексте и не имеет никакого отношения к агрегированию каналов.
Маршрутизация – это процесс определения точного пути передачи фреймов между оконечными устройствами. Для построения таблиц маршрутизации в коммутаторах фабрики используется протокол FSPF (Fabric Shortest Path First), основанный на алгоритме Дейкстры (Dijkstra). Каждому ISL в фабрике ставится в соответствие значение веса (cost), зависящее от Transfer Rate линка. Вес линка можно установить и вручную. Общий вес пути равен сумме весов всех ISLs из которых он состоит. При наличии нескольких возможных путей между сервером и дисковым массивом, данные всегда передаются по пути с наименьшим весом.
В случае, если между двумя оконечными устройствами существуют сразу несколько путей с одинаковым весом, решение о доставке по конкретному маршруту принимается на основании следующих политик:
№ | Brocade | Cisco | Описание |
1 | Port-based | не использ. | Маршрут выделяется на основании хешей номера входящего порта и Domain ID следующего коммутатора. |
2 | Device-based | Flow based | Маршрут выделяется на основании хешей FCID порта устройства-источника (Source ID, S_ID) и FCID порта устройства-назначения (Destination ID, D_ID). |
3 | Dynamic Path Selection (DPS) | Exchange-based | Маршрут выделяется на основании хешей FCID порта устройства-источника, FCID порта устройства-назначения и номеров FCP обмена (Originator eXchange ID, OXID и Receiver eXchange ID, RXID). |
Важно понимать, что политики маршрутизации различаются только принципами, по которым парам портов взаимодействующих оконечных устройств на некую продолжительность времени выделяется один из эквивалентных путей передачи. Политики 1 и 2 никак не зависят от нагрузки или типа ввода-вывода. По сути, маршрут выдается на все время, пока устройства будут подключены к фабрике (имеется ввиду логическое подключение, например, перегрузка драйвера HBA может привести к изменению маршрута).
Продолжительность выделения маршрута в политике 3 зависит от объема данных FCP-обмена (exchange) и, следовательно, может варьироваться в очень широких пределах. Поэтому данные различных приложений будут неравномерно загружать доступные пути.
Из вышесказанного следует, что маршрутизация в фабрике не может балансировать нагрузку (load-balancing). Применяемые политики позволяют только с той или иной степенью равномерности разделять нагрузку (load-sharing) между эквивалентными с точки зрения FSPF путями.
Однако, в коммутаторах Brocade существует способ балансировки нагрузки на уровне фабрики. Имеется ввиду агрегирование каналов двух непосредственно соединенных друг с другом коммутаторов, которое называется транкинг (Trunking). При передаче данных по логическому агрегированному каналу, коммутаторы оптимальным образом распределяют фреймы по линкам, составляющим транк (до 4x каналов в транке в 1/2Gbps и до 8x в 4/8Gbps коммутаторах). Т. е. балансировка нагрузки происходит на уровне фреймов размером 2KB, что достаточно эффективно. Между несколькими транками, так же, как и между обычными ISL, возможен load-sharing на уровне маршрутизации.
Функциональность агрегирования каналов, реализованная в коммутаторах Cisco, называется Port Channel. К сожалению, в отличие от Brocade Trunking, она не балансирует нагрузку на уровне фреймов. По сути, это просто дополнительная опция к политикам маршрутизации Exchange-based или Flow-based. Нагрузка просто разделяется между линками, составляющими агрегированный канал, на уровне FCP-обменов или потоков. Однако, в отличие от неагрегированных линков, таблицы маршрутизации Port Channel являются общими для всех линков, составляющих логический канал (до 16x). Поэтому при разрыве или добавлении физического линка, протоколу FSPF нет необходимости прерывать передачу трафика во всей фабрике и начинать достаточно ресурсоемкую процедуру обследования путей.
Обратите внимание на то, что функциональность Cisco Trunking используется совсем в другом контексте и не имеет никакого отношения к агрегированию каналов.
Подписаться на:
Сообщения (Atom)