четверг, 28 августа 2014 г.

О типах репликации в семействе СХД IBM Storwize


В свете достаточно высокой популярности семейства СХД IBM Storwize часто приходится отвечать на вопросы о выборе правильного типа репликации между двумя СХД. Попробую коротко изложить отличия и сценарии использования каждого типа.

Всего их три:
  • Metro mirror – синхронная репликация
  • Global mirror – асинхронная репликация
  • Global Mirror with Changed Volumes – асинхронная репликация на основе снапшотов


Metro mirror представляет из себя классический вариант, при котором Primary система при запросе на запись отдаёт подтверждение хосту только после получения соответсвующего подтверждения от Secondary системы. Очерёдность представлена на рисунке.
Применять такую жёсткую схему стоит в случаях где критична потеря каждого байта информации и содержание абсолютно идентичной копии должно быть важнее потерь в производительности вызванных задержками в двустороннем обмене данными. Идеальный вариант это собственная оптика. Максимальная дистанция - 300км, при этом стоит помнить, что каждый километр волокна это ~5мкс, плюс каждое активное устройство на пути добавит не менее 25мкс.

Global mirror выполняет те же функции, но без ожидания подтверждения записи от Secondary системы. Данная схема выдвигает достаточно жесткие требования к каналу связи - двусторонние задержки должны составлять не более 80мкс.
При такой схеме в случае остановки основной системы возможны некоторые потери данных на второстепенной СХД. Поэтому для полноценного Failover`а необходимо применение средств восстановления таких потерь. Такая схема позволяет достичь высокой производительности на боевой системе, но выдвигает повышенные требования к каналу связи, т.к. процесс записи изменений напрямую зависит от интенсивности работы на боевой системе.

Global Mirror with Change Volumes позволяет обойти ограничения первых двух случаев и справиться с ошибками перегрузки каналов связи, хостов и СХД вовлечённых в процесс. По умолчанию каждые 300с (диапазон может быть изменён 60-86400с) создаётся снапшот, который и подлежит репликации. Т.о. значительно экономится трафик между двумя СХД, ведь в реплику не попадает весь процесс изменений между контрольными точками.
 
Если процесс копирования не завершается с за установленный период, то следующий процесс не начнётся пока текущие изменения не буду записаны в реплику. следующий цикл в этом случае стартует сразу по окончанию предыдущего. В большинстве случаев репликации по IP стоит применять именно этот тип.

3 комментария:

  1. diz:
    Добрый день, Антон!

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

    ОтветитьУдалить
  2. Да, давно не было чего нибудь новенького. Продолжайте

    ОтветитьУдалить
  3. название статьи поправьте "О типах репликации в сИмействе СХД IBM Storwize"

    ОтветитьУдалить