Pull to refresh

Comments 32

Итак, что же нам предлагает Microsoft из коробки:

•Всё, что может быть виртуализовано, можно реплицировать.



Это, прямо скажем, не совсем так. Здесь прямым текстом сказано, что Exchange не поддерживается. С AD тоже могут быть проблемы, как и в принципе с любой системой, где есть собственные механизмы репликации, работающие параллельно с Hyper-V Replica. Так что в вашем чеклисте пункт про консистентность данных и поддержку приложений я бы вынес на первое место — для начала надо выяснить, стоит ли вообще пытаться включать репликацию, а уж потом разбираться с тем, куда и как.
C AD версии 2012+ никаких проблем не наблюдается и это вполне поддерживаемый сценарий. Более того он уже был отработан нами в аварийной ситуации. Аварийный фейловер отработал корректно, и после плановый (в обратную сторону), после устранения аварии, так же корректно. При наличии механизма VM GenerationID проблем не замечено.
А так же нельзя реплицировать виртуалки, к которым подключено внешнее хранилище (direct-attached storage).
Я имел в виду компоненты виртуальных сред, а не конкретные приложения.

Exchange это отдельная тема. Да, официально это не поддерживается. Даже больше скажу — официально машинам с Exchange нельзя делать hypervisor snapshot. Это можно найти в той же презентации, где говорится о запрете реплики. Кстати, там же делается забавная оговорка — раньше это было not recommended, а теперь мы решили перенести это в раздел not supported.

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

P.S. Не буду показывать пальцем на приложения которые уже давно всё это официально поддерживают =)
«если нет возможности использовать выделенную сеть для репликации» — собственно я так и не нашел информации, как сделать выделенную сеть для репликации? Беглый гуглинг, сказал, что официально это не работает, а неофициально есть какие-то странные хаки.
А вообще да, отличный инструмент катастрофоустойчивости, удобный и бесплатный.
Приписка официально, у майкрософта значит дословно следующее: Мы никак не можем научить нашу техподдержку решать проблемы сложнее эникейства, поэтому поддерживать их не будем.
Но что есть то есть — встроенных средств дна уровне гипервизора для направления трафика репликации на определённый интерфейс нет и приходится каждый раз изобретать.
Возможно, «официально» это не работает, потому что нет смысла специально работать над этой фичей. Зачем может понадобиться выделенная сеть именно для Hyper-V Replica?
Ну, у меня в стойке стоит сервер гипервизора и репликации. На мой взгляд логично соединить их напрямую патчкордом и настроить репликацию только через этот интерфейс, что бы не гонять приличный объем данных через общую сеть.
«Приличный объем» — это сколько конкретно в цифрах, вы у себя реальный трафик меряли? «Много» (для современных сетей) бывает довольно редко, особенно в ситуации, когда всего-то пара серверов.

К тому же best practice в любом случае советует разделять сети хостов гипервизоров и гостей, то есть служебная подсеть и так выделяется.
Ок, у меня есть служебная подсеть (физически) и общая (физически). Гипервизор находится в обоих. Сервер репликации тоже. Как сделать, что бы репликация ходила только по служебной сети?
К слову, в 2003/2008 сервере можно было сделать выделенный management интерфейс сетевой, в 2012 я не могу найти такой возможности. Без иронии, если подскажете как это делается в двенашке — буду признателен.
Да, это именно те самые «какие-то странные хаки» о которых я говорил выше. Это рабочее решение? Да, конечно. Это «нормальное» решение? Нет.
Просто странно видеть такое шаманство для, на мой взгляд, очевидно полезной функции когда всё остальное работает из коробки в 3 клика.
К слову да, керберос там нужен, отлично. Можно ведь добавить в сеть репликации еще и контроллер домена, например, пускай он их там между собой авторизует, но пусть это будет удобно.
Кто-б знал.
Видимо будет дальше развиваться идея external-internal-private сетей.
Просто на мой взгляд реплика это такой «кластер для бедных», именно что катастрофоустойчивость. И если есть полноценный отказоустойчивый кластер с резервным копированием, то зачем вообще репликация нужна? Видимо эти не очевидные ограничения — политические.
Вот когда кластера перестанут зависеть от общих дисков, тогда репликация станет никому не нужна.
Ну хранилище же тоже можно в failover кластер засунуть. Дисковые полки тоже резервируются.
Понятно, что а) резервное копирование не отменяет, пожалуй, вообще ни что и б) Всегда есть какая-то вероятность, что всё будет очень плохо.
Да, но сколько будет стоить резервация дисковой полки, особенно если речь идёт про SAN? Это вариант уже банковского и промышленного сектора.
Ну да, это понятно.
На примере нашей организации, например, если какой-то сервис не будет работать сутки, то это конечно плохо, но миллионных убытков не будет. Даже тысячных не будет. Главное не потерять данные. По этому катастрофоустойчивости достаточно.
Понятно, что постепенно надёжность растёт всё медленнее, а цена все быстрее. Ну и нет придела совершенству. В безопасности, к слову, абсолютно так же.
Hyper-V Replica это в первую очередь инструмент Disaster Recovery. Если сгорит ваш ЦОД, а у вас нет реплики в другом ЦОДе (в другом конце города или в другом городе), то вас никакое резервирование полок не спасет от, в лучшем случае, огромного простоя (учитываем время восстановления из резервной копии), в худшем случае, от потери вообще всей инфраструктуры.
Хмм, а зачем гипервизор в обеих сетях?

Выделенная сеть делается точно так же — если у вас два адаптера, то в простейшем случае один настраиваете просто как обычный сетевой адаптер (он и будет служебным), а на второй вешаете виртуальный свитч со снятой галкой «Allow management operation system to share this network adapter» (соответственно, через него будет ходить весь трафик гостей).
Ок, а если у меня на 2012 файловый сервер, например. Как мне на нём сделать management интерфейс?
Гипервизор в общей сети как раз потому, что с него бывает нужен доступ на тот же файловый сервер, который тоже в общей сети.
Что вы вкладываете в понятие management interface в данном случае?

Гипервизор в общей сети как раз потому, что с него бывает нужен доступ на тот же файловый сервер


Для этого не нужен сетевой интерфейс в той же сети, нужна маршрутизация между сетями.
Я подразумевал физически изолированную сеть для серверов по которой бы ходил «служебный» трафик и происходило бы всё администрирование и не было бы ПК пользователей, только админские (отдельным интерфейсом физическим). Ну а вторым сетевым интерфейсом те же ПК уже бы общались с пользователями в «общей» сети.
Да, вариант с маршрутизацией и кучей ACL почему-то не пришел в голову.
Как я написал в статье — процесс репликации съест столько канала связи, сколько сможет, задавив весь остальной трафик на своём пути. Эффект очень напоминает ситуацию с одновременным запуском нескольких торентов с множеством сидов.
Подскажите, как быть с сетевыми адаптерами в разных сайтах, если в одном подключение реплицируемой машины по VLAN ID 1002 в другом — по VLAN ID 2? В таком случае только VMM поможет?
Вероятно я не правильно понял вопрос, или есть какие то инфраструктурные особенности т.к. хочется предложить самый дуболомный вариант с настройкой маршрутизаци между вланами. И при чём тут VMM тоже не очень понятно…
Между сервером исходником и сервером приемником должен быть маршрут. Как ip-пакеты от одного дойдут к другому — вопросы к вашим сетевым инженерам.
Мы для таких целей пользуемся Handy Backup — она и Hyper-V умеет реплицировать, и железо почти не нагружает. (Извините, что ссылок две — там то ли админы тормозные, то ли просто русского варианта статьи нет, но я нашёл только англ. рук-во по Hyper-V.)

P.S. Намаявшись со встроенными средствами Microsoft, я стал искренним фанатом этой проги. Пора с них деньги начать брать за рекламу :).
Я конечно могу подсказать действительно хорошую программу для бекапов и реплик, но обещал без рекламы =)
Как у нее с поддержкой кластеров и CSV\SMB-хранилищ?
Я про Handy Backup. А вы наверное про Veem Backup? =)))
Sign up to leave a comment.