Pull to refresh
3
0
Send message

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

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


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

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

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

  • для синхронного режима репликации (хост получает подтверждение о записи блока данных только после успешной записи этого блока в кэш удаленного массива) — задержка записи (для хоста) будет прямо пропорциональна расстоянию между массивами. (при условии, конечно, что задержка при записи в локальный массив заметно ниже задержки при репликации между массивами).
  • для асинхронного режима репликации (хост получает подтверждение о записи блока данных сразу после записи блока в кэш локального массива) — задержка записи (для хоста) не будет зависеть от расстояния между массивами
  • если пакеты теряются в канале, то они будут повторно передаваться (реплицироваться) массивом. при этом есть предельно допустимая величина потери пакетов в канале, на пример, для режима асинхронной потоковой репликации: Packet loss ratio cannot exceed 0.0012% average measured over 24 hours.
хм, боюсь, что я не очень понимаю о чем вы… MSA — это массив с блочным доступом (по iSCS и/или FC). соответственно репликация возможна только на уровне томов (LUN). Да, в MSA репликация называется remote snap — это асинхронный режим репликации.
О каком таком layer3 вы говорите? если речь про репликацию по IP — то все работает (remote snap).
а чем remote snap не устраивает?
репликация в MSA существует с испокон веков, на блочном уровне, точно не на файловом
если вы слышали о технологии Thin Provisioning, то возможно понимаете, как важно знать когда примерно аллокированная емкость (used capacity) сравняется с физической емкостью массива. это важно знать, чтобы заранее планировать апгрейд емкости. таки волшебный capacity usage forecast и позволяет оценить когда этот момент наступит: завтра или через год.
мы используется коммуникационный протокол HTTPS для передачи информации в зашифрованном виде (SSL/TLS) от массива в HPE 3PAR Central.

Information

Rating
Does not participate
Registered
Activity