Comments 59
Кстати, правда, как вы решаете проблему split brain?
Ну, как я уже упомянул, проблема split brain возникает только для тех приложений, которые пишут в общие данные. Если, допустим, данные не общие, то каждый «брэйн» будет писать в свои, а затем, после восстановления соединения между половинками кластера, данные между оригиналом и ее «отставшей» копией засинхронизируются автоматически.
Проблеме split brain может быть подвержена такая система, как Oracle RAC, например, где записи делаются хоть и с арбитром, но в общую базу (в случае разделения половин кластера у нас окажется две несинхронные копии этой базы, обе при этом будут «частично актуальны»).
Для решения проблемы split brain нужен сайт-арбитр, который по избыточному каналу сможет принять решение о том, «кто виноват и что делать».
Сейчас есть два варианта решения. Для Oracle RAC есть так называемый Tiebreaker server, использующий Operations Manager (за деньги), это решение описано, например в «TR-3816 Providing Zero Downtime with Oracle RAC, EDC, ASM and Metrocluster», либо, по-моему даже бесплатно, плагином к ApplianceWatch.
Operations Manager и ApplianceWatch это софтовые продукты NetApp для контроляи управления (netto знает ;), уточню для читающих комментарии).
Проблеме split brain может быть подвержена такая система, как Oracle RAC, например, где записи делаются хоть и с арбитром, но в общую базу (в случае разделения половин кластера у нас окажется две несинхронные копии этой базы, обе при этом будут «частично актуальны»).
Для решения проблемы split brain нужен сайт-арбитр, который по избыточному каналу сможет принять решение о том, «кто виноват и что делать».
Сейчас есть два варианта решения. Для Oracle RAC есть так называемый Tiebreaker server, использующий Operations Manager (за деньги), это решение описано, например в «TR-3816 Providing Zero Downtime with Oracle RAC, EDC, ASM and Metrocluster», либо, по-моему даже бесплатно, плагином к ApplianceWatch.
Operations Manager и ApplianceWatch это софтовые продукты NetApp для контроляи управления (netto знает ;), уточню для читающих комментарии).
Да про софт знаю, спасибо.
А насколько вообще Metrocluster популярен в мире? Почему о нем так редко упоминают?
А насколько вообще Metrocluster популярен в мире? Почему о нем так редко упоминают?
Ну не могу сказать что редко упоминают. Хотя согласен, что стоило бы чаще, вот, видите, рассказываю :)
Вообще метрокластер, как я знаю, очень популярен в Германии (там вообще NetApp как-то экстремально популярен, он там даже обгоняет EMC по продажам!), например только за 2010 год, и только среди опубликованных компанией Customer Stories, куда, конечно, попадает совсем немного из общего количества внедрений, систем с метрокластером около 20!
Причем очень разные по «профилю» компании. Там и промышленные предприятия (Porsche, DEMAG), страховые, издательская компания (Corelio), датацентр грузового порта в Копенгагене, даже интернетный фотосервис (ORWO).
Вообще метрокластер, как я знаю, очень популярен в Германии (там вообще NetApp как-то экстремально популярен, он там даже обгоняет EMC по продажам!), например только за 2010 год, и только среди опубликованных компанией Customer Stories, куда, конечно, попадает совсем немного из общего количества внедрений, систем с метрокластером около 20!
Причем очень разные по «профилю» компании. Там и промышленные предприятия (Porsche, DEMAG), страховые, издательская компания (Corelio), датацентр грузового порта в Копенгагене, даже интернетный фотосервис (ORWO).
Просто Германия маленькая страна и метрокластер со своими 100км укладывается в размеры страны, а у нас просто расстояния в России не те, вот и популярность низкая :)
Ну, как сказать «маленькая» :)
Россия тут тоже не показательный пример, подавляющее число систем NetApp сегодня продается, увы, «в Москве и области».
Россия тут тоже не показательный пример, подавляющее число систем NetApp сегодня продается, увы, «в Москве и области».
Я вообще мечтаю сделать «облако» с метрокластером на V-Series (есть куча «тупых» FC полок), VMWare и QinQ между датацентрами…
P.S. завтра, кстати, уже VMware Forum 2011 буду там… слушать… а когда свои мечты осуществлю, то буду расказывать :)))
P.S. завтра, кстати, уже VMware Forum 2011 буду там… слушать… а когда свои мечты осуществлю, то буду расказывать :)))
VmWare FT не самый лучший пример для показа работы MetroCluster. SiteRecoveryManager был бы понягляднее :) А так да, круто безусловно.
В данном случае мне просто лень было рисовать для статьи картинку топологии, и я украл их с сайта VMware:
kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1001783
:)
kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1001783
:)
SRM теоретически не нужен если у нас метрокластер (т.е. данные УЖЕ доступны в DR датацентре и готовы к использованию без всяких миграционных процессов).
А вот если у нас скажем простой snapmirror тогда да — SRM сильно упростит выполнения сценария DR.
А вот если у нас скажем простой snapmirror тогда да — SRM сильно упростит выполнения сценария DR.
Какой красивый огонь на картинке.
У нас есть старенький метрокластер на fas 3020c.
Работает стабильно, но достаточно сложен был в сборке и первоначальной настройке.
До состояния split-brain довести пока не удавалось (надеюсь что и не удастся :-) ), а гибель сайта целиком тестировали неоднократно.
Работает стабильно, но достаточно сложен был в сборке и первоначальной настройке.
До состояния split-brain довести пока не удавалось (надеюсь что и не удастся :-) ), а гибель сайта целиком тестировали неоднократно.
«одна половина будет находиться в Москве, а другая, например, в Зеленограде, причем работать обе половины будут синхронно»
Ой ли? Что за волшебная технология передачи данных? Что за среда передачи данных?
Ой ли? Что за волшебная технология передачи данных? Что за среда передачи данных?
Репликация — чистый FC, кластерный интерконнект — FC-VI (Fibre Channel — Virtual Interface). Для межузлового соединения необходим dark fiber, то есть эксклюзивно используемое оптоволокно.
Тогда наверное правильно будет говорить об асинхроной репликации все-таки?
Нет, репликация синхронная.
Мммм… Задам вопрос по другому:
Какая максимальная дистанция Для выполнения описанной вами репликации?
И второй вопрос: что вы подразумеваете под синхронной репликацией?
Какая максимальная дистанция Для выполнения описанной вами репликации?
И второй вопрос: что вы подразумеваете под синхронной репликацией?
Максимальная дистанция зависит от кабеля и его свойств, от допустимых для приложения задержек, от наличия соответствующих SFP на коммутаторе и лицензий. Но при наличии всего необходимого возможна установка синхронной репликации на расстоянии до 100 км, далее величины задержек уже становятся неприемлемыми для работы.
Синхронная репликация, это репликация данных на вторичный сторадж, которая осуществляется непосредственно в момент и в процессе записи данных на первичный сторадж.
Ну я же вам ниже привел ссылку на техдоку, посмотрите, там понятно.
Синхронная репликация, это репликация данных на вторичный сторадж, которая осуществляется непосредственно в момент и в процессе записи данных на первичный сторадж.
Ну я же вам ниже привел ссылку на техдоку, посмотрите, там понятно.
Обычно синхронная репликация — это когда мы ждем подтверждения записи с удаленной точки. При указанных вами 100 км на каждую операцию чтения потребуется минимум 1 миллисекунда. А на запись — 2. Это без учета накладных расходов на обработку fc-фреймов. Количество буферов для fc мне уже лень считать, но оно будет огромным, и одним донор-портом тут явно не отделаться.
Понятне чем в тексте по ссылке я вам точно не объясню. Там, кстати, есть все расчеты. Ну не заставляйте меня копировать оттуда сюда абзацы текста. :)
Ну чудо там вроде не описано. Честно скажу: читал по диагонали.
Возьмем для примера приложение генерящее 1000 иопсов. Стандартное такое приложение. При этом длина кабеля пусть составит 100 метров. Для выполнения операции чтения 1000 нс. Записи — 2000 нс. Я учитываю только время на передачу сигнала. Без времени на обработку
При 100 км, как я написал выше чтение 1 мс, запись — 2 мс. То есть 1000 иопсов мы уже не получим. А получим что-то около 1 (одного) иопса :)
Нигде не ошибся?
Возьмем для примера приложение генерящее 1000 иопсов. Стандартное такое приложение. При этом длина кабеля пусть составит 100 метров. Для выполнения операции чтения 1000 нс. Записи — 2000 нс. Я учитываю только время на передачу сигнала. Без времени на обработку
При 100 км, как я написал выше чтение 1 мс, запись — 2 мс. То есть 1000 иопсов мы уже не получим. А получим что-то около 1 (одного) иопса :)
Нигде не ошибся?
Значит где-то ошиблись :)
Ошибся с чем? По версии инженеров NetApp сколько иопсов будет при таких вводных?
Вы чертовски логичны, за недостатком знаний даже не знаю что возразить. Но факт есть факт — оно работает и мне как админу без разницы что лежит там на низком уровне. Меня устраивает что задержки в приемлемых пределах и задача решается.
Кстати, тот же EMC со своим SRDF/S и наверняка куча других вендоров делают то же самое.
Кстати, тот же EMC со своим SRDF/S и наверняка куча других вендоров делают то же самое.
Я не знаю что делают те или инные вендоры. Во всех документах связанных с синхронной репликацией озвучивается гораздо меньшие расстояния. До 10 км, кажется.
Мне стало интересно, что я получу имея такое приложение. Вообще у меня запросы чуть меньше в 700 иопсов (30/70 чтение/запись) но кто знает что будет завтра.
Идем дальше: конкретно к компании нетап у меня претензий нет, имеются претензии к подаче информации. IT менеджеры, прочитав такую простыню тут же загорятся покупкой, ок. Их дело, но когда эта хрень будет работать не так как говорят рекламные проспекты, потому что «есть нюанс». Это будет уже головняк технарей. Я сразу попытался выяснить этот нюанс, и судя по ответам представителя компании, где-то здесь и зарыта собака.
Ситуация похожа на технологию fault tolerance от vmware. По проспектам все красиво, но почему-то я не встречал ее реального использования. А все потому что она не поддерживает smp и является асинхронной. Хотя к чести вмвари, они все эти «тонкости» никогда и не скрывали.
Мне стало интересно, что я получу имея такое приложение. Вообще у меня запросы чуть меньше в 700 иопсов (30/70 чтение/запись) но кто знает что будет завтра.
Идем дальше: конкретно к компании нетап у меня претензий нет, имеются претензии к подаче информации. IT менеджеры, прочитав такую простыню тут же загорятся покупкой, ок. Их дело, но когда эта хрень будет работать не так как говорят рекламные проспекты, потому что «есть нюанс». Это будет уже головняк технарей. Я сразу попытался выяснить этот нюанс, и судя по ответам представителя компании, где-то здесь и зарыта собака.
Ситуация похожа на технологию fault tolerance от vmware. По проспектам все красиво, но почему-то я не встречал ее реального использования. А все потому что она не поддерживает smp и является асинхронной. Хотя к чести вмвари, они все эти «тонкости» никогда и не скрывали.
Прошло 5 лет, а ваш вопрос остался без ответа=) Обидно.
Не знаю, актуально ли еще, но напишу:
Вы ошиблись дважды. Если у вас задержка 1мс, то вы успеете 1000 IOPS получить, а не 1. Но это произойдет только в том случае, если у вас IOPS следуют друг за другом и каждый следующий ждет подтверждения предыдущего. Если бы приложения работали именно так, то какой бы огромный массив у вас не был, вы бы не получили никогда более 150IOPS, так как работал бы только один диск (на флеше получили бы побольше).
Но, что прекрасно, приложения генерят несколько потоков данных, которые могут обрабатываться параллельно. То есть в канал сразу полетят, например, 50 потоков, с каждого можно выжать 1000IOPS, вот у вас и 50к IOPS получилось.
Много раз видел перегруженные СХД, в которых при задержке 20-30мс было около 100к IOPS.
Надеюсь, смог донести мысль.
Не знаю, актуально ли еще, но напишу:
Вы ошиблись дважды. Если у вас задержка 1мс, то вы успеете 1000 IOPS получить, а не 1. Но это произойдет только в том случае, если у вас IOPS следуют друг за другом и каждый следующий ждет подтверждения предыдущего. Если бы приложения работали именно так, то какой бы огромный массив у вас не был, вы бы не получили никогда более 150IOPS, так как работал бы только один диск (на флеше получили бы побольше).
Но, что прекрасно, приложения генерят несколько потоков данных, которые могут обрабатываться параллельно. То есть в канал сразу полетят, например, 50 потоков, с каждого можно выжать 1000IOPS, вот у вас и 50к IOPS получилось.
Много раз видел перегруженные СХД, в которых при задержке 20-30мс было около 100к IOPS.
Надеюсь, смог донести мысль.
И, кстати, фраза «админу без разницы что лежит на низком уровне», не прибавляет этому админу стоимости на рынке труда :)
И не отнимает если задача решается без «нюансов» :)
Бывает по разному. В больших компаниях алминистратор системы хранения, администратор сети, администратор базы данных и администратор SAN (и сотрудник техподдержки) это все разные люди.
Ситуация, когда администратор системы хранения не знает, для чего используется «выше по иерархии» нарезанный и выданный им LUN довольно обычна, равно как и dba чаще всего не знает как организовано то, что он получил от storage admin.
Ситуация, когда администратор системы хранения не знает, для чего используется «выше по иерархии» нарезанный и выданный им LUN довольно обычна, равно как и dba чаще всего не знает как организовано то, что он получил от storage admin.
Извините, вовремя не увидел ваш вопрос.
Мне показалось что глава 3.2 и Appendix B в приведенном документе дает достаточно исходной информации, чтобы разобраться в вопросе.
В целом, эта тема далеко выходит за рамки данной статьи, это уже пресейловая работа, и если у вас есть интерес (в смысле не чтобы «слоники побегали», а действительный интерес под какой-то проект), то давайте переместимся в почту с этим, комменты на хабре не лучшее и не самое удобное место для этого разговора.
Мне показалось что глава 3.2 и Appendix B в приведенном документе дает достаточно исходной информации, чтобы разобраться в вопросе.
В целом, эта тема далеко выходит за рамки данной статьи, это уже пресейловая работа, и если у вас есть интерес (в смысле не чтобы «слоники побегали», а действительный интерес под какой-то проект), то давайте переместимся в почту с этим, комменты на хабре не лучшее и не самое удобное место для этого разговора.
Я выше написал почему меня интересует данный вопрос. Расчет кредитов не даст ответа на мой вопрос, так как это касается фабрики. Например, интересный факт: при 100 км в кабеле единовременно находятся 642 кб данных при 10gfc. :) Вот для этого нужны кредиты.
Я уже понял ЦА этой статьи не технари. Если ко мне подойдет менеджер я выскажу ему свои опасения.
Я уже понял ЦА этой статьи не технари. Если ко мне подойдет менеджер я выскажу ему свои опасения.
Ну аудитория Хабра все же диктует определенную «популярность» и «доступность» изложения, неизбежная плата за широту охвата аудитории.
Вот тема загрузки линукса на игровой приставке Dingoo или тема копирайтов и Михалкова здесь встречает куда больший отклик, чем тема рассказа про Fibre Channel. :)
Вот тема загрузки линукса на игровой приставке Dingoo или тема копирайтов и Михалкова здесь встречает куда больший отклик, чем тема рассказа про Fibre Channel. :)
Хотя мы уже завершили дискуссию, но недавно мне попалась на глаза интересная статья про большую реализацию метрокластера на предельной дальности в весьма большом по масштабам проекте. Посмотрите, возможно найдете зацепку понять для себя, как это работает
www.netapp.com/us/communities/tech-ontap/tot-tsystems-case-study-0909.html
www.netapp.com/us/communities/tech-ontap/tot-tsystems-case-study-0909.html
Кстати в указанной вами доке тип синхронизации для fabric metrocluster скромно опущен.
Не может такого быть.
Но даже если это отчего-то и так (нет времени сейчас найти это непоседственно в тексте) — он синхронный, другого в метрокластере просто нет.
Верьте мне. :)
Но даже если это отчего-то и так (нет времени сейчас найти это непоседственно в тексте) — он синхронный, другого в метрокластере просто нет.
Верьте мне. :)
Страница 5, глава 2.2
2.2 OPERATION
MetroCluster (either stretch or fabric) behaves in most ways just like an HA pair controller. All of the protection provided by core NetApp technology (RAID-DP®, Snapshot™ copies, automatic
controller failover) also exists in a MetroCluster configuration (Figure 1). However, MetroCluster adds complete synchronous mirroring along with the ability to perform a complete site failover from a storage perspective with a single command
стр 13. глава 2.10
As a high-availability solution, MetroCluster is often compared with other synchronous replication products. Even though it includes SyncMirror, MetroCluster is differentiated by the following features:
Вы невнимательны.
2.2 OPERATION
MetroCluster (either stretch or fabric) behaves in most ways just like an HA pair controller. All of the protection provided by core NetApp technology (RAID-DP®, Snapshot™ copies, automatic
controller failover) also exists in a MetroCluster configuration (Figure 1). However, MetroCluster adds complete synchronous mirroring along with the ability to perform a complete site failover from a storage perspective with a single command
стр 13. глава 2.10
As a high-availability solution, MetroCluster is often compared with other synchronous replication products. Even though it includes SyncMirror, MetroCluster is differentiated by the following features:
Вы невнимательны.
В деталях рассказывать будет много, но если любопытно, то можете попробовать самостоятельно прочитать:
media.netapp.com/documents/tr-3548.pdf
media.netapp.com/documents/tr-3548.pdf
Мне честно говоря даже не хочется читать статью, которая начинается с такой серьёзной логической ошибки. Результат опроса IT специалистов конечно же косвенно связан с вероятностью происхождения того или иного сбоя, но никак не напрямую. Намного логичнее делать выводы о вероятности сбоя из статистики по реально произошедшим сбоям.
Сумма процентов побольше 100% выходит. Любопытно.
Опять таки эта статистика ничего не говорит об общей надёжности датацентров. Она может быть очень даже высокой, но вот если что-то и сломается, тогда уже эта статистика начинает работать.
Сумма процентов побольше 100% выходит. Любопытно.
Опять таки эта статистика ничего не говорит об общей надёжности датацентров. Она может быть очень даже высокой, но вот если что-то и сломается, тогда уже эта статистика начинает работать.
Статья не претендует на абсолютно точную научную работу в области расчета рисков. Цель упоминания результатов данного отчета была исключительно в том, чтобы привлечь внимание к тому факту, что устойчивости к аппаратным сбоям и отказам самой системы хранения еще не достаточно для сохранения работоспособности системы в целом и доступности ее данных.
Да. График привлекает внимание. Рассуждение под ними отпугивают своей нелогичностью.
мнение <> факт
Логично, что собрать статистику сбоев датацентров значительно сложнее, чем просто опросить кучу айтишников. Правда первое было бы действительно полезно, а от опроса толку мало.
В целом статья просто смахивает на рекламу. У кого-то может сложиться впечатление, что это прям единственное решение. ;)
мнение <> факт
Логично, что собрать статистику сбоев датацентров значительно сложнее, чем просто опросить кучу айтишников. Правда первое было бы действительно полезно, а от опроса толку мало.
В целом статья просто смахивает на рекламу. У кого-то может сложиться впечатление, что это прям единственное решение. ;)
1. Я с удовольствием сменю приведенные данные на предоставленные вами, если они окажутся более аккуратны и достоверны.
2. Я готов добавить в статью (хотя это и странно для статьи в корпоративном блоге) описание аналогичного решения от другого производителя, если вы мне его покажете и расскажете о нем, хотя бы вкратце, насколько оно аналогично описываемому.
2. Я готов добавить в статью (хотя это и странно для статьи в корпоративном блоге) описание аналогичного решения от другого производителя, если вы мне его покажете и расскажете о нем, хотя бы вкратце, насколько оно аналогично описываемому.
1. Предлагаете мне бесплатно поработать на Вас? Забавно.
Нет. Давайте уж лучше сами.
2. Не стоит. Но благодарю за предложение.
Нет. Давайте уж лучше сами.
2. Не стоит. Но благодарю за предложение.
2. Конечно же наш любимый EMC с SRDF, но… по гибкости, как MetroCluster, пытаются все же сделать VPLEX. Но упаси вас господь работать с решениями EMC (IMHO)
RazB0YniK, да это реклама! Все бы такую рекламу делали т.к. в отличии от остальных сторадж вендоров NetApp не занимается умалчиванием чего-либо.
track, про V-Series пишите обязательно… тоже людям мозг взорвет и по-любому будет интересно :)
RazB0YniK, да это реклама! Все бы такую рекламу делали т.к. в отличии от остальных сторадж вендоров NetApp не занимается умалчиванием чего-либо.
track, про V-Series пишите обязательно… тоже людям мозг взорвет и по-любому будет интересно :)
SRDF это же вроде на Симметриксе? Согласен, в принципе (хотя и плохо знаю EMC-шные дела, а у них есть прозрачный для приложений тэйковер?), но это совсем другого ценового диапазона решение.
Да, SRDF это на Симетриксе, прозрачный… ух… ну в EMC в это верят… продукт называется Cluster Enabler и это СОФТ устанавливаемый на ХОСТ подключенный к СХД. Чувствуете разницу? :) Только VPLEX может за собой спрятать все это безобразие.
Про SRDF и Cluster Enabler на пальцах www.youtube.com/watch?v=g5Hhzay4Dqs
Цены, да, космические (без кавычек — они действительно КОСМИЧЕСКИЕ)
Про SRDF и Cluster Enabler на пальцах www.youtube.com/watch?v=g5Hhzay4Dqs
Цены, да, космические (без кавычек — они действительно КОСМИЧЕСКИЕ)
Работает только с FC полками.
Возможно уже этом году появится SAS-to-FC bridge для этой проблемы.
Интересно будет посмотреть насколько они смогут сохранить плюсы SAS при таком «изврате».
Мне нравится элегантнейшее решение, но будущее его туманно.
Как только RPO/RTO может быть обеспечен синхронным\асинхронным SnapMirror то гораздо дешевле сделать полуручные процедуры DR (vFiler DR тот же очень элегантен).
Мне нравится элегантнейшее решение, но будущее его туманно.
Как только RPO/RTO может быть обеспечен синхронным\асинхронным SnapMirror то гораздо дешевле сделать полуручные процедуры DR (vFiler DR тот же очень элегантен).
Sign up to leave a comment.
NetApp Metrocluster