Как добиться репликации с нулевым RPO на большие расстояния

[mickvav]

Каких-нибудь синтетических тестов на типовых задачах не проводили?
Зависит ли задержка при записи от удаленности дата-центров и как система ведет себя при потерях пакетов в каналах?

[Vladkor]

• для синхронного режима репликации (хост получает подтверждение о записи блока данных только после успешной записи этого блока в кэш удаленного массива) — задержка записи (для хоста) будет прямо пропорциональна расстоянию между массивами. (при условии, конечно, что задержка при записи в локальный массив заметно ниже задержки при репликации между массивами).
• для асинхронного режима репликации (хост получает подтверждение о записи блока данных сразу после записи блока в кэш локального массива) — задержка записи (для хоста) не будет зависеть от расстояния между массивами
• если пакеты теряются в канале, то они будут повторно передаваться (реплицироваться) массивом. при этом есть предельно допустимая величина потери пакетов в канале, на пример, для режима асинхронной потоковой репликации: Packet loss ratio cannot exceed 0.0012% average measured over 24 hours.

[mickvav]

Хочется увидеть сравнительное тестирование на какой-нибудь реальной задаче с конкурентами — тем же DRBD, например. А так — статья по документации вендора (да, я понимаю, что вы и есть вендор) без дополнительной обкатки/сравнения. Скучно.

[reallord]

И интересно для каких бизнес-задач SLD пригоден с учетом того, что для томов виртуализации не поддерживаються логическая консистентность данных на уровне приложений.

[Vladkor]

ни о каких ограничениях на применимость SLD (как и вообще репликации) для тех или иных приложений я не слышал. в том числе и для систем серверной виртуализации.
говоря о "томах виртуализации" — вы имеете в виду виртуальные машины? для синхронного режима репликации данные будут консистентны (и на уровне приложений) просто потому, что данные на локальном и удаленном массивах будут всегда идентичны. для асинхронного режима репликации для наших массивов HPE 3PAR StoreServ можно использовать доп. функционал (сейчас это называется RMC), который позволяет обеспечить консистентость для таких задач, как VMware, Hyper-V, Oracle, MS-SQL, Exchange.

[Sergery8205]

Данные с СУБД Oracle, например можно синхронизировать (горячее резервирование) между несколькими удаленными экземплярами средствами самой же СУБД. При этом если делать синхронизацию на уровне систем хранения, собственно данные в целевых точках синхронизации, не будут валидными с точки зрения СУБД.

1) Если все данные предприятия хранятся в самой базе данных, то зачем способ синхронизации на уровне устройств хранения данных нужен?!

2) Каковы конкретные примеры использования?

[Vladkor]

Если с массивом работает только одно приложение (Oracle или какое другое) и это приложение умеет реплицировать на большие расстояния (несколько сотен км) с нулевым RPO — тогда да, вполне можно обойтись средствами репликации приложения. Однако, обычно с массивом работает несколько (или даже много) разных задач — в этом случае проще сделать аппаратную репликацию средствами массивов.
По поводу консистентности:

[Vladkor]

По поводу консистентности:

• при синхронной репликации данные на обоих массивах будут всегда идентичны и при этом, что важно, последовательность записи блоков на удаленном массиве будет такой же, как и на локальном массиве.
• при асинхронной репликации для наших массивов HPE 3PAR StoreServ можно использовать доп. функционал (сейчас это называется RMC), который позволяет обеспечить консистентость и для Oracle в том числе.
• redo logs также нужно реплицировать, как и прочие данные

[Sergery8205]

Красиво, если есть ссылки на мануалы, прошу поделиться. Хотелось бы встретить в них именно любимое слово Oracle в контексте синхронной репликации.

[Vladkor]

В случае отказа любых двух массивов решение позволяет продолжать работу и, в зависимости от того какие 2 массива отказали, RPO будет или нулевым, или несколько больше нуля. В статье говорится об обеспечении нулевого RPO при последовательном (не одновременном) отказе любых 2 массивов. Конечно, при последовательном отказе массивов в синхронной паре, интервал времени между отказом 1-го и 2-го массивов не должен быть слишком маленьким: второй массив должен успеть реплицировать данные на удаленный третий массив. И еще раз: даже при одновременном отказе двух массивов в синхронной паре — остается живым третий массив с RPO=5 мин.