Комментарии 8
Добавлю — восстановление реплицированных VM может стать проблемой, во всяком случае, это не HA кластер, который в случае сбое одного узла «все сделает сам», например сетевые настройки реплицированных VM приходится настраивать в ручном режиме, и это «не баг, а хитрая фича».
По поводу скорости — у меня репликация 0.5ТБ в 6 VM успешно работает на канале 50 Мбит/с с RPO «умолчанию» в 4 часа.
А сейчас я тестирую Amazon Storage gateway, которая добавит некоторого спокойствия моим VM:-)
По поводу скорости — у меня репликация 0.5ТБ в 6 VM успешно работает на канале 50 Мбит/с с RPO «умолчанию» в 4 часа.
А сейчас я тестирую Amazon Storage gateway, которая добавит некоторого спокойствия моим VM:-)
Нельзя ли поподробнее про сетевые настройки реплицированных VM? SRM создает заготовку под репликат машины без сетевых настроек?
При использовании vSphere Replication никаких автоматических действий не производится, и после recovery VM администратору необходимо войти на машину, назначить новую портгруппу, при необходимости (если меняется ip адресация, в данном проекте — не меняется) — назначить новый ip адрес. В случае использования SRM эти действия (назначение портгруппы, адресов и т.п.) выполняет сам SRM при failover-е (автоматическом или инициированном администратором)
Интересное применение. А на вашей площадке поднималась отдельная vSphere-а под этого заказчика, либо реплицировались с «общей» vSphere-ой, на которой живут много заказчиков?
Для данного конкретного проекта использовалась общая инфраструктура (безусловно, с ограничением прав на уровне объектов vSphere, не объектов Replication). Т.к. сам Replication не имеет эффективной системы разграничения прав, для дальнейших проектов у нас прорабатываются различные варианты, как выделенные физические инфратруктуры, так и возможность использования nested virtualization (хотя прибегать к такому варианту конечно-же не хочется — не многих заказчиков это устроит)
Если в VM запущена база данных, то сохранится ли целостность базы? Какие могут быть проблемы и как их можно решить? Нужно ли базы данных реплицировать отдельно, не средствами VmWare?
Что происходит при возврате на основную площадку — есть ли способ это сделать быстро, передавая только изменения с момента переезда?
Что происходит при возврате на основную площадку — есть ли способ это сделать быстро, передавая только изменения с момента переезда?
VMware умеет обеспечивать целостность данных в VM средствами vmware tools quiescence, реально это работает в windows для VSS-aware приложений. В принципе могут сущестовать агенты на уровне приложения, взаимодействующие с vmware tools, либо можно написать необходимые скрипты. Если этого не делать — то в результате будет получена reset-consistent копия; сохранится ли в таком случае целостность БД — вопрос к ее структуре и внутренним механизмам обеспечения целостности.
Обратная репликация, как впрочем и первоначальная прямая, может быть произведена с использованием seed дисков, заранее скопированных в offline (или сохранившихся на основной площадке). В таком случае на обеих сторонах будут пересчитаны контрольные суммы дисков и переданы только измененнные данные. Это быстрее полной репликации, хотя и медленнее пересылки заведомо известных дельт, как в случае с регулярной синхронизацией.
Обратная репликация, как впрочем и первоначальная прямая, может быть произведена с использованием seed дисков, заранее скопированных в offline (или сохранившихся на основной площадке). В таком случае на обеих сторонах будут пересчитаны контрольные суммы дисков и переданы только измененнные данные. Это быстрее полной репликации, хотя и медленнее пересылки заведомо известных дельт, как в случае с регулярной синхронизацией.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Резервная площадка в облаке с использованием vSphere Replication