Обычно для синхронной репликации это не больше 300км. Pure требует от каналов репликации задержку не более 5ms. Обычно задержка составляет 1ms на 100км, но это не точно.
Во всех DR (Disaster Recovery) решениях медиатор/кворум устройство рекомендуется размещать на третьей площадке. Как раз на тот случай, если у клиента отсутствует третья площадка — есть облачный медиатор который предоставляется Pure, но для его использования СХД нужен выход в интернет.
В крайнем случае вы конечно можете разместить медиатор на одной из площадок, где стоит СХД. Но тогда в случае обрыва репликационных каналов — выигрывать будет именна та СХД, которая стоит вместе с медиатором. А в случае падения всей площадки где стоит СХД+Медиатор, вторая СХД просто перейдет в режим ReadOnly.
В данной статье описана именно синхронная active/active репликация, Pure так же поддерживает и асинхронную репликацию.
Спасибо!
Новые линейки IBM Storwize и Flashsystem по сути несут в себе весь функционал SVC. HyperSwap это feature этих СХД, которая по сути является аналогом ActiveCluster. Я немного почитал про HyperSwap и судя по документации там тоже поддерживается режим работы active/active, когда чтение/запись возможна на любую из СХД.
Тестировали тоже, к сожалению забыли об этом в статье упомянуть. В случае обрыва сети между ЦОДами, медиатор выбирал одну из СХД, которая продолжит работать. Вот кстати failover сценарии из документации по ActiveCluster.
За какое время происходит переключение путей в растянутой FC фабрике? По вашей логике, если это значение >0, то никто не обеспечивает RTO=0.
Вы вообще представляете как работает FC SAN и Multipathing на хостах? :)
За переключение путей отвечает хост (точнее multipating software). В случае пропадания СХД из SAN, multipathing мгновенно отрабатывает это событие (современные multipath решения умеют смотреть в SAN). Исключение составляют события, когда СХД остается в SAN фабрике, но по каким то причинам «не отвечает» на scsi команды, обычно такое может происходить из за высокой нагрузки на СХД или на SAN. В таком случае на хостах срабатывают таймауты. Никакой разницы при переключении путей между растянутой SAN и локальной — нет.
В статье описан тест, когда мы по питанию отключали одну из СХД. Никакого прерывания в вводе/выводе не происходило, ни на секунду. Multipathing мгновенно отрабатывал это событие и переключал активные пути на резервную СХД.
Oracle RAC по умолчанию имеет значение disktimeout = 200 секундам. Как с этим жить фанатам RTO= абсолютному 0?
Опять вас не понимаю. В случае выхода из строя одной из СХД, multipathing мгновенно отрабатывает (см. тесты в статье) и резервная СХД уже готова принять на себя ввод/вывод, никакие таймауты на хостах не срабатывают и не важно какие значения они имеют.
Т.е. в случае выхода из строя контроллера на первой площадке, данные записанные на второй площадке буду с обоих контроллеров «пихаться» в живой контроллер на первой. Все верно? Или все таки все POD переедут на один контроллер на второй площадке?
Куда будет писать данные живой контроллер на первой площадке? В один контроллер на второй? Вообще в нормально режиме как выбирается контроллер, которому передать данные на удаленной площадке?
К сожалению у меня нет ответа на данный вопрос. Это внутренние алгоритмы работы и они нигде не описаны.
Сборка метро кластера возможна, если заказчик не хочет давать массивам выход в интернет и нет возможности подключить облачный Cloud Mediator?
Возможна. Он может работать и без медиатора, только в таком случае возможна ситуация split-brain. Pure предоставляют возможность скачать медиатор в виде OVA образа и развернуть локально на площадке.
Как отработает кластер split-brain, если обе площадки работают, но пропала связь с Cloud Mediator и оборвались каналы репликации?
Если связь с медиатором и каналы репликации оборвались одновременно, то ввод/вывод будет заблокирован на обеих СХД. Только администратор сможет вручную выбрать, какая из СХД продолжит работать.
В случае если сначала оборвался канал репликации, то медиатор выберет, какая из СХД продолжит работать, а какая перейдет в состояние readonly. Затем, если оборвется связь до медиатора, уже ничего не произойдет и доступ к данным будет продолжен через одну из СХД.
Репликационные порты массивов должны быть подключены через коммутатор (прямое подключение array1ctl0 <-> array2ctl0 не поддерживается). Каждому репликационному порту назначается собственный IP адрес, таким образом каждый видит каждого. В случае выхода из строя контроллера на первой площадке, ничего не изменится для второй.
Solaris и Linux по дефолту имеют 60 секунд scsi timeout.
Который невозможно поменять? Так себе аргумент
С вашим подходом, можно выкрутить таймаут в 120+ секунд и заявить, что СХД обеспечивает Transperent Failover! Ведь ОС не заметит пропадание дисков… Но вот любое приложение может заметить и отвалиться… И тут вы скажите подкрутить таймаут в приложении, верно? Пусть тоже подождет 120 секунд :) Но ведь, это означет, что все пользователи приложения теперь тоже должны подождать 120 секунд… А если это крупный банк или ритейл компания, где каждая транзакция или каждый клиент на счету. Как ни говори, а это простой бизнеса. Ваш подход — подкрутить таймауты, не серьезен.
Еще раз повторюсь, в статье описаны решения, которые обеспечивают RTO&RPO = 0. MetroCluster таким не является (ссылка выше).
Я очень рад за клиентов которые успешно внедрили и используют MetroCluster. Означает, что это решение полностью покрывает их потребности и SLA.
Solaris и Linux по дефолту имеют 60 секунд scsi timeout.
VMware вроде 140 секунд, виртуальные машины вероятно переживут такое пропадание дисков, приложения которые работают в ВМ — вряд ли.
То есть в большинстве случаев, мы получим простой бизнеса.
Вот и главное отличие этих решений, в случае active/active кластеров, такой как Pure Storage ActiveCluster — резервная площадка всегда готова, что бы принять нагрузку на себя. И здесь действительно RTO&RPO = Zero.
Есть еще аргументы в пользу NetApp MetroCluster? Или теперь понятно почему его нет в списке конкурентных решений?
На сколько мне известно, в случае выхода из строя одной площадки (одной СХД NetApp), хост на какое то время теряет доступ к дискам. NetApp`у нужно время что бы поднять SVM на другой площадке, плюс поднять и залогинить все WWNы в фабрику, после чего хост восстановит доступ к лунам. Если у вас есть другая информация — прошу подкрепить ее документаций или failover-тестами.
DellEMC VPLEX не является СХД, это виртуализатор в первую очередь.
Совершенно верно. В таких решениях как ActiveCluster, когда LUNы доступны на запись на обеих площадках, необходим контроль со стороны хостов за порядком записи на эти LUNы. Для этого прекрасно подходят кластерные файловые системы, такие как VMFS, Veritas CFS, OCFS и другие.
В этой статье я перечислил именно те конкурентные продукты, которые позволяют выполнять запись на обе площадки в один момент времени и выполнять Transperent Failover (то есть хост не замечает потерю LUNa в случается выхода из строя одной СХД, теряется только часть путей до LUNа). NetApp MetroCluster ни хуже, ни лучше, у него другая идеология работы, поэтому я его не включал в этот перечень конкурентных продуктов.
Если вы имеете в виду NetApp MetroCluster, то этот продукт больше соответствует классичейской синхронной репликации. Так как данные доступны на чтение/запись только на одном массиве.
В статье же перечислены технологии которые позволяют выполнять операции чтения/записи через любой массив в кластере, в любой момент времени.
В крайнем случае вы конечно можете разместить медиатор на одной из площадок, где стоит СХД. Но тогда в случае обрыва репликационных каналов — выигрывать будет именна та СХД, которая стоит вместе с медиатором. А в случае падения всей площадки где стоит СХД+Медиатор, вторая СХД просто перейдет в режим ReadOnly.
В данной статье описана именно синхронная active/active репликация, Pure так же поддерживает и асинхронную репликацию.
Новые линейки IBM Storwize и Flashsystem по сути несут в себе весь функционал SVC. HyperSwap это feature этих СХД, которая по сути является аналогом ActiveCluster. Я немного почитал про HyperSwap и судя по документации там тоже поддерживается режим работы active/active, когда чтение/запись возможна на любую из СХД.
Вы вообще представляете как работает FC SAN и Multipathing на хостах? :)
За переключение путей отвечает хост (точнее multipating software). В случае пропадания СХД из SAN, multipathing мгновенно отрабатывает это событие (современные multipath решения умеют смотреть в SAN). Исключение составляют события, когда СХД остается в SAN фабрике, но по каким то причинам «не отвечает» на scsi команды, обычно такое может происходить из за высокой нагрузки на СХД или на SAN. В таком случае на хостах срабатывают таймауты. Никакой разницы при переключении путей между растянутой SAN и локальной — нет.
В статье описан тест, когда мы по питанию отключали одну из СХД. Никакого прерывания в вводе/выводе не происходило, ни на секунду. Multipathing мгновенно отрабатывал это событие и переключал активные пути на резервную СХД.
Опять вас не понимаю. В случае выхода из строя одной из СХД, multipathing мгновенно отрабатывает (см. тесты в статье) и резервная СХД уже готова принять на себя ввод/вывод, никакие таймауты на хостах не срабатывают и не важно какие значения они имеют.
К сожалению у меня нет ответа на данный вопрос. Это внутренние алгоритмы работы и они нигде не описаны.
Возможна. Он может работать и без медиатора, только в таком случае возможна ситуация split-brain. Pure предоставляют возможность скачать медиатор в виде OVA образа и развернуть локально на площадке.
Если связь с медиатором и каналы репликации оборвались одновременно, то ввод/вывод будет заблокирован на обеих СХД. Только администратор сможет вручную выбрать, какая из СХД продолжит работать.
В случае если сначала оборвался канал репликации, то медиатор выберет, какая из СХД продолжит работать, а какая перейдет в состояние readonly. Затем, если оборвется связь до медиатора, уже ничего не произойдет и доступ к данным будет продолжен через одну из СХД.
С вашим подходом, можно выкрутить таймаут в 120+ секунд и заявить, что СХД обеспечивает Transperent Failover! Ведь ОС не заметит пропадание дисков… Но вот любое приложение может заметить и отвалиться… И тут вы скажите подкрутить таймаут в приложении, верно? Пусть тоже подождет 120 секунд :) Но ведь, это означет, что все пользователи приложения теперь тоже должны подождать 120 секунд… А если это крупный банк или ритейл компания, где каждая транзакция или каждый клиент на счету. Как ни говори, а это простой бизнеса. Ваш подход — подкрутить таймауты, не серьезен.
Еще раз повторюсь, в статье описаны решения, которые обеспечивают RTO&RPO = 0. MetroCluster таким не является (ссылка выше).
Я очень рад за клиентов которые успешно внедрили и используют MetroCluster. Означает, что это решение полностью покрывает их потребности и SLA.
Других способов репликации не заявлено.
Репликационный порт не один, их 4 штуки на массив, то есть 40Gb/s.
Думаю в следующих версиях firmware возможность использования VVOLs будет добавлена.
Без ActiveCluster, работа с VVOLs поддерживается.
Предложите это клиенту при покупке NetApp и зафиксируйте в договоре :)
Сам NetApp заявляет, что MetroCluster обеспечивает RPO Zero и RTO under 120 seconds.
Пруф — www.netapp.com/us/products/backup-recovery/metrocluster-bcdr.aspx
Solaris и Linux по дефолту имеют 60 секунд scsi timeout.
VMware вроде 140 секунд, виртуальные машины вероятно переживут такое пропадание дисков, приложения которые работают в ВМ — вряд ли.
То есть в большинстве случаев, мы получим простой бизнеса.
Вот и главное отличие этих решений, в случае active/active кластеров, такой как Pure Storage ActiveCluster — резервная площадка всегда готова, что бы принять нагрузку на себя. И здесь действительно RTO&RPO = Zero.
Есть еще аргументы в пользу NetApp MetroCluster? Или теперь понятно почему его нет в списке конкурентных решений?
DellEMC VPLEX не является СХД, это виртуализатор в первую очередь.
В этой статье я перечислил именно те конкурентные продукты, которые позволяют выполнять запись на обе площадки в один момент времени и выполнять Transperent Failover (то есть хост не замечает потерю LUNa в случается выхода из строя одной СХД, теряется только часть путей до LUNа). NetApp MetroCluster ни хуже, ни лучше, у него другая идеология работы, поэтому я его не включал в этот перечень конкурентных продуктов.
В статье же перечислены технологии которые позволяют выполнять операции чтения/записи через любой массив в кластере, в любой момент времени.