Комментарии 37
В минусы допишите «масштабирование». Его там практически нет. Ну и да, надежность вследствие фактически отсутствия резервирования.
Можете объяснить, чем не устраивает, скажем, market.yandex.ru/model.xml?modelid=9367687&hid=91095? Нам ведь не FCoE гонять, а обычный TCP.
У всех свитчей она разная. Есть low-latency модели.
Ну и проводилась ли работа со стеком TCP? Там полно способов повысить эффективность утилизации полосы.
Остальные компоненты перечислим в таблице (к ценам можно придираться – но порядок такой):
Можете объяснить, чем не устраивает, скажем, market.yandex.ru/model.xml?modelid=9367687&hid=91095? Нам ведь не FCoE гонять, а обычный TCP.
Латентность
У всех свитчей она разная. Есть low-latency модели.
Ну и проводилась ли работа со стеком TCP? Там полно способов повысить эффективность утилизации полосы.
С сетью проблемы?
4x1Gb:
2x10Gb:
1x40Gb:
2x10Gb:
1x40Gb:
Как вы можете SAS сравнивать c iSCSI? iSCSI для проброса в другой город, SAS из области DAS.
А современные СХД умеют подключаться к SAS коммутаторам? Или на это нужно будет обращать внимание? Под заказ допустим вместо Fiber Channel можно без проблем попросить SAS?
Для СХД начального уровня (HP MSA2000, IBM DS 3500, DELL MD3200) производитель предлагает разные варианты интерфейсов подключения: SAS, iSCSI (1gbe/10gbe), FC. На это нужно обратить внимание при заказе. О поддержке SAS у более взрослых моделей я не слышал.
Dell MD3200 с FC не бывает. FC в линейке Dell PowerVault есть только в моделях MD36xx
И, кстати, задумайтесь: почему производители не используют SAS в СХД более высокого уровня…
И, кстати, задумайтесь: почему производители не используют SAS в СХД более высокого уровня…
Используют ;) У всех СХД на бэкэнде теперь SAS :)
почему производители не используют SAS в СХД более высокого уровня
строить SAN на базе SAS протокола стало возможно только с выходом SAS v2. А это случилось совсем недавно — 4 года назад. И конкуренция с FC и iSCSI возможна только по цене. В старших СХД эта разница на фоне стоимости самих хранилищ не заметна. Да и ограничения на длину кабеля + отсутствие приятных фич вроде репликации делает невостребованной мощь таких систем. Как-то так…
И, кстати, задумайтесь: почему производители не используют SAS в СХД более высокого уровня…
Маркетинг, ничего более.
Dell по этой же причине не поставляет MD3200 с FC-портами, хотя оригинальная CTS2600 их поддерживает и у других вендоров такая опция имеется.
Сравниваете абсолютно разные решения для разных сегментов с разным уровнем отказоустойчивости, соответственно получаете разную стоимость.
Какое железное решение используете?
Хотелось бы видеть результаты теста в виде красивой таблички
(http://habrahabr.ru/post/78632/)
Например:
FCOE Raid60 Lun 0 60Gb 4 Path MPIO Policy: Round Robin With Subset
Хотелось бы посмотреть на latency Вашей системы при высокой нагрузке
(http://habrahabr.ru/post/78632/)
Например:
FCOE Raid60 Lun 0 60Gb 4 Path MPIO Policy: Round Robin With Subset
Хотелось бы посмотреть на latency Вашей системы при высокой нагрузке
Товарищи! Аккуратнее используйте SCSI (SAS, SATA и т.п.) протокол для доступа к датасторам виртуализации. Количество Outstanding IO на один LUN по умолчанию равно 32. И когда у вас на датасторе куча виртуалок начинает драться за диск и число Outstanding IO переваливает 32, то происходят страшные вещи. Да, это число можно увеличить, но с увеличением этого числа неотъемлемо растет response time — учтите! Поэтому все вменяемые крупные организации используют NFS в качестве доступа к датасторам. (да, дастору можно собрать из кучи LUN'ов, но… вы поняли).
В тесте в IOMeter'e стоит Outstanding IO = 10 это далеко от дефолтного предела, советую увеличить этот параметр скажем до 30, погонять засечь производительность и потом до, скажем, 50-и… вообщем поиграться с этим параметром.
По мне так у этого решения нет преимуществ кроме цены. Как это вообще бэкапится?
В тесте в IOMeter'e стоит Outstanding IO = 10 это далеко от дефолтного предела, советую увеличить этот параметр скажем до 30, погонять засечь производительность и потом до, скажем, 50-и… вообщем поиграться с этим параметром.
По мне так у этого решения нет преимуществ кроме цены. Как это вообще бэкапится?
У меня вопрос:
Все мои эксперименты с SAS приводили к выводу, что SAS внутри обычная SCSI, то есть шина. Как только один из дисков начинает козлить, все соседи по хосту (HBA) перестают нормально работать. Другими словами, одинокий дядел в полке всю полку переводит в режим «хреново».
Для SAS-устройств мне удалось достоверно повторяемо воспроизвести проблему только для довольно глючных SSD-дисков одного производителя, имя которого они просили не называть (вроде бы баг в прошивке уже поправили).
Для комбинации SATA-дисков (в sas-enclosure) у меня есть боевой скрипт, который мучает один диск, а в результате отваливается целиком полка: github.com/amarao/lsi-sata-fuckup
Поясните про устойчивость конфигурации, пожалуйста.
Повторю: дело не в конкретном устройстве/lun'е, а в том, что глюки одного устройства, выносят все остальные устройства на шине.
Все мои эксперименты с SAS приводили к выводу, что SAS внутри обычная SCSI, то есть шина. Как только один из дисков начинает козлить, все соседи по хосту (HBA) перестают нормально работать. Другими словами, одинокий дядел в полке всю полку переводит в режим «хреново».
Для SAS-устройств мне удалось достоверно повторяемо воспроизвести проблему только для довольно глючных SSD-дисков одного производителя, имя которого они просили не называть (вроде бы баг в прошивке уже поправили).
Для комбинации SATA-дисков (в sas-enclosure) у меня есть боевой скрипт, который мучает один диск, а в результате отваливается целиком полка: github.com/amarao/lsi-sata-fuckup
Поясните про устойчивость конфигурации, пожалуйста.
Повторю: дело не в конкретном устройстве/lun'е, а в том, что глюки одного устройства, выносят все остальные устройства на шине.
Все диски внутри полки подключаются к контроллеру (одному или двум). Задач контроллера понять, что в массиве есть проблемный диск и вывести его из работы. HBA сервера подключается через SAS свич к выходу контроллера полки. Т.е. зависимость качества работы среды передачи данных не может зависеть от конкретного диска — только от работы контроллера полки. В данном случае уже не важно, какой протокол используется в SAN — SAS, FC, iSCSI…
Отказоустойчивость же классическая — MPIO, два независимых пути, два контроллера
Отказоустойчивость же классическая — MPIO, два независимых пути, два контроллера
Эх, счастливый Вы человек. Не видели Вы видимо никогда дисков с проблемными fw/неправильно функционирующем контроллером, который намертво вешает всю бекенд петлю массива. Как бывший сервисный инженер по кое-каким мидренджевым массивам, могу сказать что такая проблема — это основная причина всех серьёзных даунтаймов после кривых рук администраторов и электропитания.
Такие диски иногда вообще не опознаются контроллером как сбойные и найти без использования определенных утилит (не доступных конечному заказчику) невозможно.
Такие диски иногда вообще не опознаются контроллером как сбойные и найти без использования определенных утилит (не доступных конечному заказчику) невозможно.
Огромное спасибо. Я всё думал, есть ли эта проблема у более навороченных топологий, чем несколько полок к нескольким рейдам.
ЗЫ В лаборатории я как-то сумел добиться зависания контроллера всего лишь задрочив хотплаг (много-много раз вставлять/вынимать диск). В какой-то момент контроллер повис и повесил остальные диски, в т.ч. в других полках.
ЗЫ В лаборатории я как-то сумел добиться зависания контроллера всего лишь задрочив хотплаг (много-много раз вставлять/вынимать диск). В какой-то момент контроллер повис и повесил остальные диски, в т.ч. в других полках.
Может я чего-то не понимаю, но диски в полках подключаются не к контроллерам, а к enclosure. А фактическая топология SAS заканчивается на HBA (то есть HBA работает с диском напрямую).
multipath (по-крайней мере в той реализации, как я его видел и щупал) создаёт два блочных устройства на хосте, у которых совпадают ID. Демон/модуль ядра объединяет их в новое устройство, которое имеет резервированный путь.
Но есть один нюанс… Резервируется путь, а не устройство. Другими словами, если диск говорит «иди наюх», а контроллер послушно идёт, то диск попросит на юх как первый контроллер, так и второй. А пострадают все остальные.
Я топологии с sas-коммутаторами в боевом режиме не щупал, но по всему тому, что я знаю и наблюдал в лабораториях, проблема будет ровно такая же.
Вся проблема заключается в том, что внутри HBA что SCSI, что SAS, есть одно и то же. Если по шине (таки шине!) одно устройство не закончило обрабатывать команду (не операцию «читать/писать», а команду, в терминах SAS), то другое не сможет общаться с контроллером.
Вся драма состоит именно в «шинном» подходе. Вы его можете видеть в /sys на любом хосте, подключенном к sas-топологии.
Условно говоря:
/sys/devices/pci0000:00/0000:00:05.0/0000:02:00.0/host0/port-0:1/expander-0:1/port-0:1:7/end_device-0:1:7/target0:0:26/0:0:26:0/enclosure_device:Slot 11
Вот если это Slot 11 повиснет, то повиснет всё, что подключено к host0 (все порты, экспандеры, экстендеры, таргеты, слоты и т.д.) Будет host1 (другой HBA) или другое PCI-E устройство — всё будет ок.
Проблема в том, что все виденные мною SAS HBA ведут себя аналогично — каждый HBA даёт только один хост.
Буду очень рад, если опровергните, но на данный момент я воспринимаю любое упоминание SAS как симптом «глюки потом будут».
А ещё проблема усугубляется тем, что по мере работы увеличивается частота отказа (в т.ч. в режиме «что-то странное») у дисков, то есть постепенно железка начинает всё чаще странно замирать или зависать.
ЗЫ Любопытно, но SATA-контроллеры без экспандеров такой проблеме не подвержены — там по хосту на устройство.
multipath (по-крайней мере в той реализации, как я его видел и щупал) создаёт два блочных устройства на хосте, у которых совпадают ID. Демон/модуль ядра объединяет их в новое устройство, которое имеет резервированный путь.
Но есть один нюанс… Резервируется путь, а не устройство. Другими словами, если диск говорит «иди наюх», а контроллер послушно идёт, то диск попросит на юх как первый контроллер, так и второй. А пострадают все остальные.
Я топологии с sas-коммутаторами в боевом режиме не щупал, но по всему тому, что я знаю и наблюдал в лабораториях, проблема будет ровно такая же.
Вся проблема заключается в том, что внутри HBA что SCSI, что SAS, есть одно и то же. Если по шине (таки шине!) одно устройство не закончило обрабатывать команду (не операцию «читать/писать», а команду, в терминах SAS), то другое не сможет общаться с контроллером.
Вся драма состоит именно в «шинном» подходе. Вы его можете видеть в /sys на любом хосте, подключенном к sas-топологии.
Условно говоря:
/sys/devices/pci0000:00/0000:00:05.0/0000:02:00.0/host0/port-0:1/expander-0:1/port-0:1:7/end_device-0:1:7/target0:0:26/0:0:26:0/enclosure_device:Slot 11
Вот если это Slot 11 повиснет, то повиснет всё, что подключено к host0 (все порты, экспандеры, экстендеры, таргеты, слоты и т.д.) Будет host1 (другой HBA) или другое PCI-E устройство — всё будет ок.
Проблема в том, что все виденные мною SAS HBA ведут себя аналогично — каждый HBA даёт только один хост.
Буду очень рад, если опровергните, но на данный момент я воспринимаю любое упоминание SAS как симптом «глюки потом будут».
А ещё проблема усугубляется тем, что по мере работы увеличивается частота отказа (в т.ч. в режиме «что-то странное») у дисков, то есть постепенно железка начинает всё чаще странно замирать или зависать.
ЗЫ Любопытно, но SATA-контроллеры без экспандеров такой проблеме не подвержены — там по хосту на устройство.
то есть HBA работает с диском напрямую
С физическими дисками внутри полок HBA на прямую не работает. Он работает с LUN как с физическим диском. SAS шина внутри полки не связана с HBA. Т.е. угроза «иди наюх» только на уровне отказа СХД.
От кривого FW для дисков мы защищены точно так же, как и в случае iSCSI или иного протокола построения SAN.
Вы знаете, мой опыт работы с полками говорит о том, что петля, проходящая через полки, образует шину, то есть контроллер полки — равноправное с дисками устройство (target), способное реагировать на команды «помигай лампочкой диска 12» или «отключи питание диска 20».
Если я не прав, то я бы хотел понять, как выглядит работа HBA с диском.
Контроллер (WWN ='foo'), диск (wwn = 'bar1' и 'bar2' для разных голов).
Программа: open('/dev/mapper/mp333',O_DIRECT); ioctl(3,BLKDISCARD)
Линукс: sec_erase -> /dev/mapper/mp333
девпаппер: упс, bar1 в дауне. Эй, bar2, sec_erase
Линукс в районе посылки bio в драйвер HBA: эй, bar2, WRITE SAME (16) UNMAP.
HBA: это я, foo, эй ты, bar2, WRITE SAME (16) UNMAP
диск: это я, bar2, foo: ok
(дальше запрос возвращается по стеку назад из ioctl).
Если не так, то как?
Если же мы говорим про iscsi, а точнее, про DHT подход к хранению данных, то он базируется на идее commodity hardware, когда в сервере SAS'а может вообще не быть, а быть штук 6 sata-дисков. Или даже sas есть, но умный ceph так данные размазывает, что копии данных лежат на разных серверах/стойках.
Если же напрямую сравнивать scsi и iscsi, то главная разница состоит в том, что iscsi основывается на tcp, а он в свою очередь никак не является шинным протоколом, то есть обеспечивает гарантированную доставку, в которой каждый коннект изолирован от соседа. ethernet никаких специфичных таракнов в районе «команда залипла» так же не имеет.
С учётом же сегодняшнего нигилизма по сравнению к старым моделям SAN, каждый экспортируемый том будет отдельным target'ом, то есть никакой взаимосвязи так же не будет.
Цеф, гластер и вастскай, вон, вообще отказываются от использования iscsi/nfs и пилят свои протоколы, чтобы клиент мог без чужой помощи ошибки копий обрабатывать.
Если я не прав, то я бы хотел понять, как выглядит работа HBA с диском.
Контроллер (WWN ='foo'), диск (wwn = 'bar1' и 'bar2' для разных голов).
Программа: open('/dev/mapper/mp333',O_DIRECT); ioctl(3,BLKDISCARD)
Линукс: sec_erase -> /dev/mapper/mp333
девпаппер: упс, bar1 в дауне. Эй, bar2, sec_erase
Линукс в районе посылки bio в драйвер HBA: эй, bar2, WRITE SAME (16) UNMAP.
HBA: это я, foo, эй ты, bar2, WRITE SAME (16) UNMAP
диск: это я, bar2, foo: ok
(дальше запрос возвращается по стеку назад из ioctl).
Если не так, то как?
Если же мы говорим про iscsi, а точнее, про DHT подход к хранению данных, то он базируется на идее commodity hardware, когда в сервере SAS'а может вообще не быть, а быть штук 6 sata-дисков. Или даже sas есть, но умный ceph так данные размазывает, что копии данных лежат на разных серверах/стойках.
Если же напрямую сравнивать scsi и iscsi, то главная разница состоит в том, что iscsi основывается на tcp, а он в свою очередь никак не является шинным протоколом, то есть обеспечивает гарантированную доставку, в которой каждый коннект изолирован от соседа. ethernet никаких специфичных таракнов в районе «команда залипла» так же не имеет.
С учётом же сегодняшнего нигилизма по сравнению к старым моделям SAN, каждый экспортируемый том будет отдельным target'ом, то есть никакой взаимосвязи так же не будет.
Цеф, гластер и вастскай, вон, вообще отказываются от использования iscsi/nfs и пилят свои протоколы, чтобы клиент мог без чужой помощи ошибки копий обрабатывать.
да, так тоже можно делать. Вопрос главный зачем =)
у нас в хостинге с вируталок по iSCSI или с виндовой ноды идет ну от силы 100Мбит трафика, ну 200 в пиках. не мегаБайт, а мегабит. А на ноде 150 ВМ.
Нет смысла DAS устраивать на каждую ноду в отдельности. Имеет смысл DASы подцепить через коммуатор на нексенту, винду или иной файлер, а с него уже раздавать.
и кстати если поставить 4Гб FC, то цена решения уменьшится на порядок без потери производительности — вы меряете IOPS, а не линейные операции в терабайты размером.
у нас в хостинге с вируталок по iSCSI или с виндовой ноды идет ну от силы 100Мбит трафика, ну 200 в пиках. не мегаБайт, а мегабит. А на ноде 150 ВМ.
Нет смысла DAS устраивать на каждую ноду в отдельности. Имеет смысл DASы подцепить через коммуатор на нексенту, винду или иной файлер, а с него уже раздавать.
и кстати если поставить 4Гб FC, то цена решения уменьшится на порядок без потери производительности — вы меряете IOPS, а не линейные операции в терабайты размером.
Нет смысла DAS устраивать на каждую ноду в отдельности.
DAS — это не наш случай. LUN с СХД отдается в общее пользование нескольким нодам. Так же, как это делается по iSCSI. Просто SAS команды не заворачиваются в EtherNet фреймы, а передаются «как есть».
там еще засада — мы используем 1U сервера и надо ставить плату 10Г или 4х1G для работы кластера. HBA контроллер просто некуда ставить зачастую. А что бывает если LUN отдать на несколько нод сразу под вируталки, уже писали выше — лок-лок и катарсис с последующим просветлением. получается надо много LUN, а еще правильнее как в старые добрые времена — 1 ВМ == 1 LUN. но тут начинаются приколы — ну не так просто LUN управлять на DAS корзинках, на каждую ручками ходить и резать.
Про настройку SAS коммутаторов хорошо написано в блоге True System:
true-system.blogspot.ru/search/label/SAS6160
true-system.blogspot.ru/search/label/SAS6160
Меня удивляет, когда в полку люди ставят 12 SATA дисков и загадочно так говорят, «она подключена одним четырехканальными SAS 2 кабелем, что теоретически даст 24 Gb/s».
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Опыт организации SAN на SAS