28 марта 2011 г.

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

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

20 марта 2011 г.

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

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

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


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


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

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

13 марта 2011 г.

Принцип KISS

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

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

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

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

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

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

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

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

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

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

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

9 марта 2011 г.

Проблемы с SFP

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

В этом посте мне хотелось бы продолжить тему и обсудить несколько ситуаций возникновения проблем в модулях 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