Vladkor Jan 25 2017 at 16:46

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

5 min

6.9K

Hewlett Packard Enterprise corporate blogIT Infrastructure*Server Administration*Data storage*Data storages*

+19

Comments 11

mickvav Jan 25 2017 at 21:07

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

Vladkor Jan 26 2017 at 11:50

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

mickvav Jan 27 2017 at 08:33

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

reallord Jan 26 2017 at 10:56

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

Vladkor Jan 26 2017 at 12:08

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

Sergery8205 Jan 26 2017 at 13:13

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

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

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

Vladkor Jan 26 2017 at 13:20

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

Vladkor Jan 26 2017 at 13:31

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

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

Sergery8205 Jan 26 2017 at 13:40

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

UFO just landed and posted this here

Vladkor Jan 30 2017 at 11:11

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