Одним из самых интересных нововведений в 10й версии Veeam для сервис-провайдеров, он же Veeam Cloud Connect, на мой взгляд является возможность выполнения репликации виртуальных машин клиента не только в выделенную со стороны сервис-провайдера виртуальную инфраструктуру VMware и Hyper-V, но и в облако под управлением vCloud Director.
Как по мне, это отличная возможность и для клиентов, и для сервис-провайдеров. Первые получают достаточно простой метод организации DR в своей компании, а вторые получают возможность предоставлять больше услуг своим клиентам и, тем самым, увеличивать свой доход.
Под катом мы пройдемся по этапам настройки репликации как на стороне сервис-провайдера, так и на стороне клиента.
Я не буду в подробностях расписывать, как устанавливается Veeam со стороны провайдера и со стороны клиента и беру в расчет, что читатель уже знаком с тем, как работает Veeam Cloud Connect и из каких компонентов он состоит. Так же я не беру в расчет настройку облака vCloud, создание виртуального датацентра и выделение прав пользователям в этом датацентре.
Моя тестовая инсталляция состоит из трех основных компонентов:
- Облако на базе VMware vCloud Director 10 с хостами ESXi 6.7 со стороны сервис-провайдера;
- Veeam Cloud Connect 10a со стороны сервис-провайдера;
- Veeam Backup and Replication 10a и инсталляция VMware vSphere 7 со стороны клиента.
Важный момент, который нужно учесть при планировании репликации – версия гипервизоров ESXi в облаке сервис-провайдера и версия гипервизоров на стороне клиента.
Почему это важно? – При создании виртуальной машины, если не указано вручную, виртуальной машине выставляется максимально доступная версия Virtual Hardware для гипервизора, на котором она создается.
Так, например, при создании виртуальной машины на ESXi 7, версия виртуальной машины будет равна 17, в то время, как максимальная версия гипервизоров ESXi 6.7 – 15 (таблица версий vHardware и гипервизоров ESXi).
Запустить виртуальную машину 17 версии на гипервизорах ESXi 6.7, к сожалению, не удастся без понижения версии виртуальной машины.
В случае неподдерживаемой версии vHardware, при запуске процесса репликации в облако, Veeam об этом сообщит и завершит задание с ошибкой.
В примере ниже, я буду использовать виртуальные машины с vHardware = 15, выставляя в процессе создания виртуальной машины совместимость с гипервизорами ESXi 6.7.
В целом, задачу можно разбить на два больших пункта – настройки со стороны поставщика услуг и настройки со стороны потребителя услуг.
Пройдемся по пунктам, которые необходимо выполнить на своей стороне сервис-провайдеру:
- Выполнить настройки со стороны облачного датацентра. Создать ресурсы, учетные записи, передать доступ клиенту;
- Подготовить инфраструктуру Veeam Cloud Connect, установить ПО Veeam, настроить один или несколько компонентов Veeam Cloud Gateway, настроить балансировщик;
- Подключить vCloud Director к Veeam Cloud Connect;
- Создать потребителя ресурсов vCloud и сообщить клиенту о том, что настройка со стороны сервис провайдера выполнена.
Мы создали виртуальный датацентр клиента в VMware vCloud, Veeam Cloud Connect у нас установлен, Cloud Gateway мы так же добавили, возможно, включили их в пул. Теперь займемся непосредственно настройкой репликации в облако.
В первую очередь необходимо подключить инфраструктуру VMware vSphere и vCloud Director к установленному ранее Veeam Cloud Connect. Здесь нет ничего сложного, на закладке Backup Infrastructure в разделе Managed Servers добавляем vCloud Director:
Нам потребуются адреса контроллеров vCloud, с которыми может и будет взаимодействовать Veeam, а также учетные записи для доступа к vCloud и VMware vSphere. На данном шаге крайне важно, чтобы настройки DNS были корректны и все компоненты vCloud и vSphere были доступны по именам, если таковые используются.
По окончанию процесса добавления, в разделе Managed Servers у нас появится vCloud Director, а также VMware vCenter Server.
На этом процесс интеграции Veeam и VMware на стороне сервис-провайдера закончен.
Следующим шагом необходимо предоставить возможность клиенту выполнять репликацию в свой облачный датацентр.
Данная процедура несколько отличается от привычного управления пользователями в Cloud Connect, заключающегося в создании связки пользователь-пароль и выделения ресурсов, как дисковых, так и вычислительных.
Для аутентификации пользователей в данном случае используются учетные записи из организации vCloud Director, и управление данными записями производится там же клиентом самостоятельно. Все, что нужно сделать сервис-провайдеру в данном случае, это «разрешить» клиенту выполнять репликацию в выделенные для него ресурсы в vDC с помощью Veeam.
Как это делается? В разделе Cloud Connect, где мы обычно создаем пользователей и назначаем им ресурсы (Tenants), мы добавляем нового клиента, но уже указываем, что это аккаунт vCloud Director:
В следующем окне, необходимо будет связать клиента Veeam с его организацией в vCloud Director:
В конкретном случае, я привязываю ранее созданною в vCloud организацию testOrg к нашему Tenant аккаунту в Veeam Cloud Connect.
Следующим шагом мы получим список всех vDC в данной организации, на которые можно делать реплику:
Каждый из vDC является отдельным пулом ресурсов, куда клиент сможет делать реплику.
В целом в настройках аккаунта нет ничего сложного. Настройки сети я целенаправленно опустил, поскольку это вполне сойдет за тему отдельной статьи.
По окончанию мы получаем готовый аккаунт клиента:
Теперь в раздел Replica org vDCs, можно будет наблюдать за утилизацией ресурсов в виртуальных датацентрах клиента:
На этом, настройка со стороны Veeam и, в целом, сервис-провайдера закончена. Если коротко резюмировать – мы разрешили клиенту выполнять репликацию в свой виртуальный датацентр через наш Veeam Cloud Connect.
Этап второй. Перемещаемся на сторону клиента, который хочет сделать репликацию своих машин Offsite.
В меню Backup Infrastructure нас интересует пункт Service Providers. Добавляем нового:
Здесь мы указываем либо адрес балансировщика нагрузки, который выполняет распределение запросов между компонентами Cloud Gateway сервис-провайдера, либо адрес самого Cloud Gateway (данные адреса должны быть предоставлены сервис-провайдером клиенту):
Принимаем сертификат и указываем учетные данные для подключения:
Этот этап крайне интересный. В качестве логина и пароля мы должны указать учетную запись с правами Organization Administrator (OrgAdmin) от нашего виртуального датацентра в формате Имя_организации\Учетная_Запись.
Повторюсь – указывается тот же аккаунт, которым клиент входит в консоль VMware vCloud Director.
На следующем этапе будут видны ресурсы, доступные для реплики. Фактически, это ресурсы виртуального датацентра клиента:
После окончания процесса добавления облачных ресурсов, в пункте меню Managed Servers появится новый пункт vCloud Director с содержимым в виде так называемых Cloud Hosts:
Эти хосты ничто иное, как vDC клиента и точки, куда клиент может делать репликацию.
На этом шаге со стороны клиента заканчивается этап по подключению облачных ресурсов к своему серверу резервного копирования.
Последним шагом мы проверим то, ради чего все и затевалось – репликация виртуальных машин из инфраструктуры VMware vSphere в облако VMware vCloud Director.
На стороне клиента создаем привычный многим Replication Job и выбираем виртуальные машины, копии которых хотим разместить в облаке:
На следующем этапе, в разделе Host or Cluster, выбираем Cloud Host и один из доступных vDC, в котором планируется разместить реплики:
Там же мы выбираем vApp, в котором будут размещены виртуальные машины и дисковое хранилище (vApp Cloud Connect 1 создается по умолчанию):
Все дальнейшие пункты аналогичны стандартному процессу создания задачи репликации виртуальных машин.
В процессе создания задачи мы можем указать следующие интересные моменты:
- Сеть, в которую будут подключены будущие машины (Network remapping). Если таковая не указана, Veeam выберет сам;
- Указать используемые для задачи Proxy, а также WAN акселераторы (если используются).
К сожалению, функция Re-IP при репликации в облако не доступна.
Запустим созданную задачу и проверим, что будет происходить со стороны клиента и сервис провайдера.
Для клиента все выглядит вполне привычным образом, правда есть несколько интересных моментов:
Один из них связан с тем, что при создании задачи резервного копирования не была указана сеть для виртуальной машины, и, поскольку аналогичная существующей сети в vCloud Veeam найти не смог, он выбрал одну из доступных в vDC сетей.
Второй момент заключается в последовательной обработке виртуальных машин. При тесте, можно заметить, что вторая машина какое-то время находится в статусе Pending с сообщением Cloud Resource not ready. По умолчанию, при создании сервис-провайдером Tenant аккаунта, в секции Bandwidth ограничивается количество параллельных задач и равняется 1 (параметр можно изменить), и означает, что клиент может одновременно загружать через Cloud Gateway только один виртуальный диск. Также, сервис-провайдер может ограничивать скорость загрузки виртуальных дисков и резервных копий.
В списке запущенных задач на сервере Veeam Cloud Connect, сервис-провайдер видит что-то похожее. Чем удобно? – видно ошибки, предупреждения, всегда можно проконсультировать клиента в случае каких-либо проблем при репликации:
После окончания процесса репликации, клиент привычные взгляду реплики:
Сервис-провайдер так же видит все реплики клиентов:
Стоит отметить, что включить реплики провайдер не может, однако может их удалить.
И, то, ради чего все затевалось изначально – реплики виртуальных машин клиента в VMware vCloud Director:
Теперь проверим как работают наши реплики. Выберем обе машины и создадим Failover Plan:
Failover Plan позволяет выбрать порядок запуска виртуальных машин, выставить задержку между их включением:
Например, сперва мы включаем сервер базы данных, затем сервера приложений и после этого уже балансировщики.
Переходи в Failover Plans, выбираем ранее созданный план, правой кнопкой по названию – Start.
Начнется запуск виртуальных машин в облаке. Если обратить внимание, одна из машин уже запущена, вторая еще нет, здесь в дело вступил Delay по запуску машин, выставленный ранее в настройках Failover Plan.
Итак, мы имеем две запущенные реплики в облаке, работающие параллельно с основными машинами на площадке клиента:
С данными репликами можно сделать следующие операции:
- Permanent Failover – машины на основном сайте клиента будут остановлены. Реплика станет активной;
- Undo Failover – машины в облаке будут остановлены, машины на сайте клиента продолжат работать;
- Failback to Production – Все изменения, сделанные на машинах в облаке будут синхронизированы с машинами, расположенными на продуктивном сайте клиента, после чего машины в облаке будут выключены (нужно понимать, что машины на основной площадке будут выключены на момент синхронизации).
Я внес изменения в каждую из реплик, работающих в облаке. Проверим, как отработает Failback to Production и Undo Failover.
Внесем изменения в машины:
Проверим, как отработает Undo Failover для машины vm_linux-cloud-1:
Из сообщения все понятно. Машина в облаке будет отключена и возвращена на состояние последней точки репликации. С машиной в продуктивной среде никаких изменений не произошло:
Теперь выполним Failback to Production для vm_linux-cloud-2. Veeam предлагает ряд опций, таких как замена оригинальной VM, восстановление в качестве другой виртуальной машины, чтобы сохранить оригинальную машину невредимой:
Поскольку это тестовая инфраструктура, я восстановлю реплику поверх оригинальной VM.
Veeam предупреждает о том, что реплика будет также отключена:
На момент переноса изменений из реплики в машину на стороне клиента, обе VM будут выключены. Проверим результат переноса:
Видно, что изменения, сделанные в реплике VM, были перенесены на продуктивную виртуальную машину.
Следующим шагом необходимо либо подтвердить перенос виртуальной машины из облака обратно в инфраструктуру клиента (Commit Failback), либо откатить изменения (Undo Failback).
- Undo Failback – изменения сделанные с момента операции Failover to Production в реплике будут отменены. Реплика будет включена обратно;
- Commit Failback – Реплика останется выключенной. Виртуальная машина в инфраструктуре клиента теперь является основной.
Как можно заметить, конечная цель достигнута. Репликация в облако была произведена успешно, так же успешно был выполнен процесс переноса изменений из облака обратно к клиенту.
Остался открытый вопрос – что будет, если удалить реплики в консоли Veeam? – Все вполне ожидаемо, VM удалятся из виртуального датацентра клиента, тем самым высвободив ресурсы.
В качестве заключения:
Veeam позволяет настроить репликацию в облако провайдера за кратчайшее время. Настройка со стороны как сервис-провайдера, так и со стороны клиента занимает не больше часа и не требует каких-либо продвинутых навыков.
При планировании использования данной возможности требуется всегда учитывать версии VMware vSphere и vHardware со стороны провайдера и потребителя, если версия потребителя выше, чем версия провайдера, при репликации могут возникнуть проблемы.
Так же стоит не забывать про ограничения по количеству параллельных задач для клиентов, ограничения по пропускной способности.
В целом, это отличный и доступный вариант организовать репликацию продуктивной площадки vSphere в облако.
