6 мая 2011 г.

Заполнители в FC
Мой старый приятель и бывший коллега Юра Яворский описал интересный случай из практики траблшутинга
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 Приоритет AL_PA Описание
порта
VC
F 1 VC7 2 или 3 (по умолчанию 3) 0xda Подключение к N-порту
FL 1 VC7 2 или 3 (по умолчанию 3) 0xda Подключение к NL-порту
E
1 VC0 0 0xef Подключение к E-порту в режиме совместимости (InterOp)
FC_SW2
E 8 VC0 0 0xef Служебный трафик (класса F)
Служебный трафик (F_BSY и F_RJT, опционально контроль
VC1 1 0xe8
линка трафика класса 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)
Используется только при прямом соединении ASIC Condor друг
C 17
с другом.

2 коммент. Автор: Vasily Pantyukhin

4 апреля 2010 г.

Заметки на полях (Clariion LUNs и MetaLUNs)

После удаления LUNs стоит делать дефрагментацию RAID group.

При fastbind процесс background initialization для 4Gbps FC дисков 146GB 15Krpm проходит за ~1,5
часа, а SATA II 4Gbps 500GB 7,2Krpm за ~8,5 часа.

При background initialization average write size будет >512KB.

При создании MetaLUN, все LUNs будут автоматически trespassed на SP, который является default
owner для base LUN. Об этом стоит помнить при сбалансированном распределении LUNs по SPs.

Не стоит менять размер stripe element компонент.

Используйте в качестве компонентов RAID groups с количеством дисков >=4.

MetaLUN стоит строить из RAID одинакового размера (например, RAID 10 4+4 или RAID5 4+1).
Иначе разобраться с проблемами в производительности будет очень сложно.

В MetaLUNs нельзя смешивать FC и SATA.

Striping MetaLUNs имеют лучше производительность, но больше ограничений.

Члены Striping MetaLUNs не могут быть в различных RAID и должны иметь одинаковый размер в
блоках.

Члены Concatenation MetaLUNs могут быть на одной RAID group. В случае Striping этого делать
категорически нельзя.

Hybrid MetaLUNs более экономичны (популярны с MS Exchange).

Размер MetaLUN stripe element = Количество дисков данных * Stripe multiplier

Stripe multiplier определяется автоматически по количеству дисков данных.

Количество дисков данных Stripe multiplier

2 8
3 6
4 4
5 3
6 3
7 3
8 2

Если несколько MetaLUNs на одних и тех же RAID groups, то следует назначать base LUN на
различных RAID groups (rotate).

Процесс MetaLUN expansion сильно понижает производительность всего массива.

ID членов MetaLUNs автоматически перенумеровываются в высокие номера.

Ограничения на количество LUNs в различных версиях Flare показаны в таблице:

Ограничения LUNs Flare R29/R28.7

Модель CX4
Max # LUNs Max # LUNs / Storage Group Max # Storage Groups
CX4-120 1024/1024 512/256 256/128
CX4-240 2048/1024 512/256 512/256
CX4-480 4096/4096 1024/256 1024/512
CX4-960 8192/4096 1024/512 2048/1024

0 коммент. Автор: Vasily Pantyukhin

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 очень сильно понижает производительность всего массива.

0 коммент. Автор: Vasily Pantyukhin

10 февраля 2010 г.

Заметки на полях (HBA) -2

Какие моменты стоит учитывать для того, чтобы достичь высокого уровня нагрузки с одного сервера? Они
очевидны:
 Во-первых, реальные данные не могут просто взяться из /dev/null. Их надо сначала создать
посредством каких-либо вычислений либо скопировать из другого хранилища. Поэтому для
генерации такого плотного потока информации понадобится действительно мощный сервер и
высокопроизводительный источник данных.

Во-вторых, для обеспечения таких предельно высоких значений Bandwidth и Throughput

драйверам HBA потребуются значительные ресурсы сервера. Это приведет к дополнительной
достаточно высокой нагрузке на центральные процессоры и шины ввода-вывода.

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

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

Еще короткие заметки о HBA...

0 коммент. Автор: Vasily Pantyukhin

5 февраля 2010 г.

Заметки на полях (HBA)

У карт HBA с драйверами под различные операционные системы существуют множество
параметров, настройка которых может повлиять на производительность I/O. В качестве примера
приведу параметры Maximum Scatter/Gather List и Maximum Sectors. Их настройка всегда очень
индивидуальна и обязательно требует предварительных экспериментов с замерами
производительности.

Если вы обнаружили, что серверу доступно меньшее количество томов, чем было настроено на
дисковом массиве, возможно, необходимо увеличить значение параметра LUNs Per Target.

Пользователям дисковых массивов EMC настоятельно рекомендую перед подключению сервера к

дисковому массиву почитать соответствующий документ Connectivity Guide (как всегда, свежие
версии доступны на Powerlink). В зависимости от типа HBA и операционной системы там могут
даваться более детальные рекомендации по настройке параметров HBA.

Еще короткие заметки о HBA...

0 коммент. Автор: Vasily Pantyukhin

26 ноября 2009 г.

Заметки на полях (файловые системы)

Буферизация файловых систем является одной из причин небольших значений hit on reread.

Некоторые системы, например, VxFS или AIX, реализуют механизм предшествующего чтения
(Read-ahead). Это приводит к увеличению Request Size на чтение.

В NTFS любые IO больших размеров все равно передаются блоками по 512K.

 Если NTFS переформатирована с экстентами не-default размера, то дефрагментировать ее уже
нельзя (добавлено: гуру утверждают, что давно можно).

2 коммент. Автор: Vasily Pantyukhin

16 ноября 2009 г.

Заметки на полях (базы данных)

Скорее не полноценный пост, а памятка самому себе...

Стоит всегда стараться изолировать log-файлы от данных СУБД на отдельном RAID10.

Если Response Time файлов данных СУБД <6ms – отлично, 6-20ms – приемлемо, >20ms – плохо.

Если Response Time log-файлов СУБД <2ms – отлично, 2-6ms – приемлемо, 6-15ms – скоро
начнутся проблемы, >15ms – проблемы уже начались.