Comments 9
Как то не совсем понятен принцип работы «LSI Syncro, внутреннее исполнение»
Как именно осуществляется подключение к накопителям и где находится эта «линия синхронизации», если каналы sas не пересекаются?
Как именно осуществляется подключение к накопителям и где находится эта «линия синхронизации», если каналы sas не пересекаются?
Смотрите, общее хранилище кластера в коробке — это два SAS-экспандера с общей дисковой полкой. С одной стороны к этим экспандерам подключаются жесткие диски (поскольку это SAS, то каждый диск можно подключить одновременно к двум экспандерам), а с другой к ним подключаются контроллеры Syncro. Соответственно, линия синхронизации (точнее две линии) это Syncro1 — SAS экспандер — Syncro 2.
Как-то вот так:
Как-то вот так:
Спасибо. Кажется разобрался. Использование «LSI Syncro, внутреннее исполнение» доступно только для многонодовых серверов, у которых есть соответствующий бэкплейн.
Скажите, а эта штука всё так же вешается намертво при выполнении скрипта github.com/amarao/lsi-sata-fuckup? Я всё надеюсь, что хоть кого-то в LSI волнует качество их продуктов (служба поддержки к таковым не относится)…
Оно по умолчанию не рассчитано на работу с SATA, поскольку весь Shared сразу же упрется в один канал SATA-соединения с диском.
У меня нет железобетонного доказательства (как с SATA), но по слайдам по устройству SAS'а, есть стойкое ощущение, что у SAS'ов будет такая же проблема. Более того, по отзывам коллег, с глючными sas-дисками ровно так же зависал весь бэкплейн, и приходилось искать «какой диск вынуть», чтобы бэкплейн перестал виснуть.
Собственно, слайды www.scsita.org/library/presentations/SAS_Architecture_Overview.pdf,
proof-картинка:
Собственно, слайды www.scsita.org/library/presentations/SAS_Architecture_Overview.pdf,
proof-картинка:
Попробовать можно, но пока это не верифицируется на уровне SAS — это автоматически вычеркивает нас из культурного разговора с вендором, потому что «не пихайте, чего нет в HCL), а глючных SAS у нас на руках нет.
Да и жалоб на зависание бэкплейна оптом не было, так что вероятность возникновения проблемы явно небольшая (да, мы понимаем, что когда оно случится в продакшене — никому с размера вероятности легче не станет). При случае посмотрим, но пока наше мнение не изменилось: надо смотреть протокол, чтобы понимать, как именно устройство умудряется поставить в неприличную позу весь бэкплейн.
Кстати, хороший вопрос к Вам и Вашим коллегам: а у вас среди зависших были варианты с парой экспандеров на бекплейн, то есть работающим MPIO?
Да и жалоб на зависание бэкплейна оптом не было, так что вероятность возникновения проблемы явно небольшая (да, мы понимаем, что когда оно случится в продакшене — никому с размера вероятности легче не станет). При случае посмотрим, но пока наше мнение не изменилось: надо смотреть протокол, чтобы понимать, как именно устройство умудряется поставить в неприличную позу весь бэкплейн.
Кстати, хороший вопрос к Вам и Вашим коллегам: а у вас среди зависших были варианты с парой экспандеров на бекплейн, то есть работающим MPIO?
Я это понимаю. Но тут-то вопрос другой. Не глюки с конкретной моделью HDD, а общетеоретическая проблема, когда один «плохой» диск портит жизнь всей полке. То есть даже если это HCL-диск, но, например, с битой памятью. Сама теоретическая возможность, что он может прервать работу соседних дисков, ставит крест на любых рейдах.
В MPIO, насколько я могу судить по искуственным конструкциям с iscsi, ситуация повторится с точностью до запятой.
Предположим, у нас идеальные диски в полке, все, кроме одного. Этот один, на выполнение какой-то команды (например, WRITE SAME, с флагом discard) вместо адекватного ответа, лочит канал.
Голова №1 посылает запрос к «плохому» диску. Экстендер устанавливает канал, диск уходит в неответ (то есть не посылает CLOSE).
Голова №2 перепосылает запрос (обычный multipath). Запрос к тому же плохому диску. Экстендер устанавливает канал, диск уходит в неответ.
Обе головы не могут больше общаться с другими дисками без посылки SCSI bus reset. Что, мягко говоря, ставит на колени любую производительность.
В этом и проблема — я ни разу не видел решение на extender'ах, которое бы было rock solid. Зато я точно знаю, что в режиме direct connect диск может хоть лезгинку плясать, это его личные проблемы, на соседях это никак не сказывается.
В принципе, на expander'ах я видел условно-надёжное решение, когда собирался raid1 из двух экспандеров, в режиме «лево-право», с мыслью, что если один зависнет, то рейд «всего лишь» потеряет половину своих дисков.
В контексте mpt2sas это требует ребута сервера, но в контексте задачи предполагалось, что в этой ситуации вся нагрузка быстро-быстро с оставшейся половинки raid1 (то есть raid0) утаскивается, после чего с сервером можно делать что угодно.
Костыли жуткие, ну а что делать?
В MPIO, насколько я могу судить по искуственным конструкциям с iscsi, ситуация повторится с точностью до запятой.
Предположим, у нас идеальные диски в полке, все, кроме одного. Этот один, на выполнение какой-то команды (например, WRITE SAME, с флагом discard) вместо адекватного ответа, лочит канал.
Голова №1 посылает запрос к «плохому» диску. Экстендер устанавливает канал, диск уходит в неответ (то есть не посылает CLOSE).
Голова №2 перепосылает запрос (обычный multipath). Запрос к тому же плохому диску. Экстендер устанавливает канал, диск уходит в неответ.
Обе головы не могут больше общаться с другими дисками без посылки SCSI bus reset. Что, мягко говоря, ставит на колени любую производительность.
В этом и проблема — я ни разу не видел решение на extender'ах, которое бы было rock solid. Зато я точно знаю, что в режиме direct connect диск может хоть лезгинку плясать, это его личные проблемы, на соседях это никак не сказывается.
В принципе, на expander'ах я видел условно-надёжное решение, когда собирался raid1 из двух экспандеров, в режиме «лево-право», с мыслью, что если один зависнет, то рейд «всего лишь» потеряет половину своих дисков.
В контексте mpt2sas это требует ребута сервера, но в контексте задачи предполагалось, что в этой ситуации вся нагрузка быстро-быстро с оставшейся половинки raid1 (то есть raid0) утаскивается, после чего с сервером можно делать что угодно.
Костыли жуткие, ну а что делать?
Sign up to leave a comment.
Аппаратный Shared DAS или зачем нужен LSI Syncro