Что такое SLD и зачем оно нужно?
Одна из важнейших задач IT-подразделения предприятия – защита данных от воздействия различных внешних факторов, как то: пожар, землятрясение, наводнение и прочие катастрофы. Традиционно для этого используются различные технологии репликации данных. Однако обычно репликация позволяет синхронизовать (с тем или иным значением RPO) один и тот же набор данных только между двумя дата-центрами. И для многих заказчиков этого вполне достаточно. Для многих, но не для всех. Если заказчику требуется нулевое RPO, значит, необходимо использовать синхронную репликацию. Однако синхронная репликация позволяет размещать дата-центры на расстоянии порядка 100к м друг от друга. В случае серьезной катастрофы, или просто если два дата-центра расположены слишком близко друг от друга, оба ДЦ могут пострадать одновременно – и данные будут потеряны.
Итак, если предприятию требуется обеспечить исключительно высокий уровень защиты данных, а именно:
- репликация одного и того-же набора данных между тремя дата-центрами,
- нулевое RPO при отказе любого из 3 дата-центров,
- продолжение работы при последовательном отказе любых двух дата-центров,
— для таких требовательных заказчиков мы можем предложить специальное решение: HPE 3PAR Synchronous Long Distance (SLD).
SLD – это репликация на большие расстояния без потери данных. Как это работает, я постараюсь объяснить ниже.
Какие виды репликации поддерживаются
Сначала хочу напомнить какие виды репликации и какие топологии поддерживаются семейством массивов HPE 3PAR StoreServ.
Массивы 3PAR StoreServ поддерживают 3 режима репликации (Remote Copy):
- cинхронный (Synchronous) режим (RPO=0);
- асинхронный периодический (Asynchronous Periodic) режим (min RPO=5 мин);
- асинхронный потоковый (Asynchronous Streaming) режим (RPO около 10 сек).
Если синхронный режим, надеюсь, не требует пояснений, то для асинхронных режимов кратко опишу, как они работают:
- асинхронный периодический режим: для синхронизации томов используются мгновенные снимки (snapshots), создаваемые через заданный интервал времени; на удаленный массив реплицируются только новые блоки, содержащиеся в новом снимке по сравнению с предыдущим снимком;
- асинхронный потоковый режим: новые блоки накапливаются в локальном массиве в течении небольшого периода времени (измеряемого долями секунды) и затем реплицируются на удаленный массив.
Добавлю к этому, что во всех 3 режимах, естественно, поддерживается консистентность данных при репликации.
В качестве транспортного уровня для репликации можно использовать следующие 3 варианта:
- Remote Copy over Fibre Channel (RCFC) – для репликации используются FC порты массива и в качестве каналов передачи данных используется сеть FC;
- Remote Copy over Internet Protocol (RCIP) — для репликации используются встроенные IP порты массива (1GbE или 10GbE – в зависимости от модели массива) и в качестве каналов передачи данных используется сеть IP;
- Remote Copy over FCIP (Fibre Channel over IP) — для репликации используются FC порты массива и в качестве каналов передачи данных используется сеть IP. FCIP предполагает применение дополнительных преобразователей (gateways) протоколов FC-IP.
И, наконец, поддерживаемые тополигии/конфигурации репликации:
- One-to-one: репликация выполняется только между двумя массивами;
- Many-to-many: N массивов могут реплицировать данные на другие M массивов. Максимальные значния на сегодня для N и М =4. Пример такой конфигурации приведен на рисунке ниже:
Рис.1. Конфигурация репликации many-to-many. Каждый массив реплицирует данные на 4 других массива. Все направления репликации могут быть двунаправленными. Здесь речь идет, разумеется, о репликации разных наборов данных (томов) на разные массивы.
- Synchronous Long Distance (SLD) – специальный режим репликации, позволяющий одновременно реплицировать один и тот же набор данных (томов) с одного массива на два других массива. Именно этот режим репликации мы и рассмотрим подробно далее.
Как устроено SLD
Итак, SLD – это:
- Одновременная репликация группы томов с одного массива (А) на 2 других массива (В и С). При этом репликация на один массив (В) выполняется в синхронном режиме, а репликация на другой массив (С) – в асинхронном периодическом режиме. См. ниже рис.2. Таким образом, массивы А и В могут быть расположены относительно недалеко друг от друга (максимальное расстояние определяется максимально допустимым для синхронной репликации временем задержки между двумя массивами RTT = 10 ms). Напротив, массив С может быть удален от массивов А и В на значительное расстояние (максимальное расстояние определяется максимально допустимым для асинхронной периодической репликации временем задержки между двумя массивами RTT = 120 ms).
- Обеспечение RPO=0 на удаленном массиве С. Напомню, что, поскольку массив С расположен достаточно далеко, репликация на него в синхронном режиме невозможна, и единственный способ обеспечить переключение на удаленный массив С без потери данных (при отказе основного массива А или при плановом переключении) – это использование технологии SLD.
Рис.2. схема SLD.
Работает SLD следующим образом: в штатном режиме данные реплицируются с массива А на массивы В и С. При этом между массивами В и С также настроена асинхронная периодическая репликация, которая в штатном режиме находится в пассивном состоянии (на рис.2. показана пунктирной линией). При отказе основного массива А автоматически активируется репликация с массива В на массив С, и данные, которые были записаны на массив В, но не были записаны на массив С, будут скопированы на массив С. Таким образом, после отказа массива А, массивы В и С будут автоматически синхронизованы вплоть до последнего блока, который был записан на массив А перед его отказом.
После синхронизации массивов В и С работа с данными может быть продолжена, в качестве основного массива может быть выбран как массив С, так и массив В. При этом никакие данные, которые были записаны на массив А, не будут потеряны (RPO=0) и будет выполняться репликация между массивами В и С, обеспечивая непрерывную защиту данных уже после отказа одного из трех массивов.
После восстановления массива А новые данные, которые были записаны на массивы В и С, будут скопированы на массив А, после чего можно будет вернуться к штатному режиму работы с использованием массива А в качестве основого массива.
В заключение хочу отметить еще два важных момента:
- Массивы А и В, между которыми выполняется синхронная репликация, могут быть использованы одинаковым образом, т.е., оба эти массива могут одновременно быть главными массивами. В этом случае один набор томов будет реплицироваться с массива А на массивы В и С. Другой набор томов будет реплицироваться с массива В на массивы А и С.
- SLD можно использовать одновременно с технологией 3PAR Peer Persistence – что позволит выполнять переключение между массивами А и В полностью в автоматическом режиме. Технология 3PAR Peer Persistence также позволяет хостам прозрачно переключаться между двумя массивами (между массивами А и В в данном случае) и в онлайне перемещать виртуальные машины между двумя массивами (между двумя площадками). Подробнее про Peer Persistence можно узнать здесь.
Владимир Коробейников, @Vladkor
Комментарии (11)
reallord
26.01.2017 10:56И интересно для каких бизнес-задач SLD пригоден с учетом того, что для томов виртуализации не поддерживаються логическая консистентность данных на уровне приложений.
Vladkor
26.01.2017 12:08ни о каких ограничениях на применимость SLD (как и вообще репликации) для тех или иных приложений я не слышал. в том числе и для систем серверной виртуализации.
говоря о "томах виртуализации" — вы имеете в виду виртуальные машины? для синхронного режима репликации данные будут консистентны (и на уровне приложений) просто потому, что данные на локальном и удаленном массивах будут всегда идентичны. для асинхронного режима репликации для наших массивов HPE 3PAR StoreServ можно использовать доп. функционал (сейчас это называется RMC), который позволяет обеспечить консистентость для таких задач, как VMware, Hyper-V, Oracle, MS-SQL, Exchange.
helgisbox
26.01.2017 13:13Данные с СУБД Oracle, например можно синхронизировать (горячее резервирование) между несколькими удаленными экземплярами средствами самой же СУБД. При этом если делать синхронизацию на уровне систем хранения, собственно данные в целевых точках синхронизации, не будут валидными с точки зрения СУБД.
1) Если все данные предприятия хранятся в самой базе данных, то зачем способ синхронизации на уровне устройств хранения данных нужен?!
2) Каковы конкретные примеры использования?Vladkor
26.01.2017 13:20Если с массивом работает только одно приложение (Oracle или какое другое) и это приложение умеет реплицировать на большие расстояния (несколько сотен км) с нулевым RPO — тогда да, вполне можно обойтись средствами репликации приложения. Однако, обычно с массивом работает несколько (или даже много) разных задач — в этом случае проще сделать аппаратную репликацию средствами массивов.
По поводу консистентности:
Vladkor
26.01.2017 13:31По поводу консистентности:
- при синхронной репликации данные на обоих массивах будут всегда идентичны и при этом, что важно, последовательность записи блоков на удаленном массиве будет такой же, как и на локальном массиве.
- при асинхронной репликации для наших массивов HPE 3PAR StoreServ можно использовать доп. функционал (сейчас это называется RMC), который позволяет обеспечить консистентость и для Oracle в том числе.
- redo logs также нужно реплицировать, как и прочие данные
helgisbox
26.01.2017 13:40Красиво, если есть ссылки на мануалы, прошу поделиться. Хотелось бы встретить в них именно любимое слово Oracle в контексте синхронной репликации.
ceperaang
29.01.2017 14:04В начале говорится о том, что у обычной синхронной репликации есть недостаток — оба массива слишком близко и могут умереть одновременно. А потом представляется решение, которое от одновременной смерти двух массивов так и не защитит.
Vladkor
30.01.2017 11:11В случае отказа любых двух массивов решение позволяет продолжать работу и, в зависимости от того какие 2 массива отказали, RPO будет или нулевым, или несколько больше нуля. В статье говорится об обеспечении нулевого RPO при последовательном (не одновременном) отказе любых 2 массивов. Конечно, при последовательном отказе массивов в синхронной паре, интервал времени между отказом 1-го и 2-го массивов не должен быть слишком маленьким: второй массив должен успеть реплицировать данные на удаленный третий массив. И еще раз: даже при одновременном отказе двух массивов в синхронной паре — остается живым третий массив с RPO=5 мин.
mickvav
Каких-нибудь синтетических тестов на типовых задачах не проводили?
Зависит ли задержка при записи от удаленности дата-центров и как система ведет себя при потерях пакетов в каналах?
Vladkor
mickvav
Хочется увидеть сравнительное тестирование на какой-нибудь реальной задаче с конкурентами — тем же DRBD, например. А так — статья по документации вендора (да, я понимаю, что вы и есть вендор) без дополнительной обкатки/сравнения. Скучно.