Вход|Регистрация

Неразборчивое о виртуальном
Записи с меткой vSphere Replication

About vSphere Replication

Среда, 28 ноября 2012, 21:48

Технология vSphere Replication уже довольно хорошо известна и начинает понемногу использоваться в продуктивных системах. С выходом vSphere 5.1 механизм репликации был полностью отвязан от SRM и архитектурно значительно упростился:

  • Серверы VRMS и VRS были объеденены в один VR Appliance
  • VR Appliance больше не требует внешней БД
  • Один VR Appliance может обслуживать до 500 вм (ранее была неофициальная информация о 50-100)
  • Появилась возможность указывать определённый порт vmkX для трафика репликации (только в web-клиенте!)

Ниже некоторые особенности работы vSphere Replication:

1. Для снижения нагрузки на канал при первоначальной репликации виртуальных машин, на вторую площадку можно отвезти копии их vmdk-дисков. Важно помнить, что даже если вдруг офлайновые копии будет полностью идентичными, при запуске репликации на продуктивном массиве временно возрастёт нагрузка I/O на чтение. Дело в том, что при запуске репликации vmdk-файлы поблочно считывыаются и для каждого блока данных сохраняется значение его хеша. По данным значениям будут отобраны блоки, которые необходимо синхронизировать на этапе Full Sync.


2. Снапшоты создаёются только на второй площадке! На защищаемой площадке используется механизм Light-Weight Deltas (LWD). По заверениям инженеров VMware yикакого отношения к снапшотам и CBT он не имеет (иначе реплицируемые машины крайне сложно было бы бекапить средствами резервного копирования, использующими тотже CBT).


3. На удалённом сайте всегда существует непротеворечивая копия диска. Все изменения пишутся в redo-лог (снапшот). Когда истекает время, заданное параметром PRO для данной вм и на удалённый сайт приходит подтверждение, что все нужные блоки переданы (при загруженном канале сроки могут срываться) происходит коллапс дельта-диска и оригинального vmdk-файла. Только после этого создаётся новый снапшот.

4. Сердце vSphere Replication - механизм планирования передачи реплецируемых блоков. Именно он позволяет гибко выдерживать заданные значение RPO для машин, учитывая что нагрузка на каждую из них может быть разной в произвольный промежуток времени.

На рисунке схематично изображена передача данных для десяти вм (G1-G10). Некоторые реплицируются часто и мало (низкое значение PRO), некоторые - реже и их дельта значительно больше (больше PRO, частое изменение данных в госте). Нижняя полоска (Bandwith) наглядно демонстрирует насколько суммарно нагружен при этом канал передачи данных.

Заявляется что его движок ведёт некую статистику времени передачи данных в прошлый промежуток синхронизации и, соответсвенно, сколько предположительно потребуется для передачи всех данных в текущей итерации. При недостаточности канала репликации планировщик старается минимизировать отклонение от PRO для всех вм, без выделения приоритетных.

Написать комментарий
⇤ Последнее
Первое ⇥
← Позже 1-я (и последняя) страница Раньше →