Немного о дизайне VDI. Часть 11. Доступность VDI, Резервное копирование и аварийное восстановление

Продолжаем говорить о дизайне VDI. Предыдущие части доступны по ссылкам.
Часть 1. Введение
Часть 2. Постановка задачи
Часть 3. Верхнеуровневая архитектура
Часть 4. Подсистема VMware Horizon
Часть 5. Подсистема виртуализации
Часть 6. Лицензирование VDI
Часть 7. Виртуальные машины
Часть 8. Подсистема хранения
Часть 9. Сетевая подсистема

Часть 10. Организация подключения и безопасность

11.1 Доступность компонентов

В больших инфраструктурах обеспечение доступности VDI является одной из важнейших задач при планировании архитектуры. Отказ одного из компонентов VDI может привести к недоступности всей системы, и как следствие, к невозможности для пользователей продолжать свою работу.

При планировании доступности VDI следует определить перечень возможных отказов, от которых планируется защищаться, и мер, которые позволять снизить вероятность их возникновения, либо ускорить восстановление.

Рассмотрим случай, связанный с отказом клиентского устройства / тонкого клиента. Причины отказа могут быть различными, например, аппаратный сбор, сбой программного обеспечения, некорректно выполненная процедура обновления ОС или прошивки. Снизить вероятность аппаратного сбоя можно за счет использования более надежных моделей клиентских устройств от проверенных производителей, а также за счет проведения периодического обслуживания оборудования, настройки мониторинга клиента. Перед массовой установкой обновления должны проверяться на тестовой группе. Эти же рекомендации могут применяться и к серверному оборудованию и ПО для снижения вероятности возникновения подобных сбоев.

В случае отказа клиентского устройства должны быть предусмотрены варианты оперативного восстановления работы, например:

• Наличие резерва на замену. Для территориально удаленных площадок может потребовать организацию склада на местах для снижения времени доставки устройства до рабочего места.
• Наличие сервисного контракта с поставщиком для оперативной замены или ремонта устройства.
• Организация подключения пользователя с другого рабочего места, оборудованного клиентским устройством. Стандартизация моделей и конфигурации клиентских устройств позволит упростить реализацию данного варианта.

Другой пример – отказ WAN канала до удаленной площадки приведет к невозможности подключения к VDI инфраструктуре. Для снижения риска возможно арендовать WAN канал через другого провайдера или на время недоступности канала организовать подключение пользователей к VDI через Интернет (например, разрешить сотрудникам подключаться и работать из дома).

Выход из строя физического сервера из-за отказа аппаратного обеспечения или сбоя гипервизора влечет за собой недоступность виртуальных машин, которые работали на сервере. Аппаратные компоненты сервера (адаптеры ввода-вывода, устройства хранения, блоки питания, вентиляторы системы охлаждения, модули оперативной памяти) могут резервироваться, что снижает вероятность выхода сервера из строя из-за отказа одного из компонентов, а также позволяет производить обслуживание и замену компонентов на горячую. При наличии нескольких блоков питания с возможностью резервирования по схеме N+N рекомендуется подключать их к независимым линиям электропитания. Это же касается подключения сетевых адаптеров к Ethernet коммутаторам и адаптеров ввода-вывода к коммутаторам сети хранения – подключение сервера к нескольким коммутаторам и настройка teaming’а и multipathing’а позволит проводить обслуживание коммутаторов без необходимости выключать сервер.

Для снижения времени простоя ВМ могут использоваться следующие механизмы повышения доступности:

• Настройка vSphere High Availability для автоматизации запуска ВМ на других физических сервера.
• Настройка Fault Tolerance для критичных ВМ.
• Резервирование на уровне приложений, запущенных внутри ВМ. Установка дополнительных экземпляров серверов View Connection Server, создание избыточных виртуальных десктопов в Floating Pool, кластеризация SQL Server и т.п. При резервировании на уровне приложений совместно с DRS следует помнить о необходимости использования правил Anti-Affinity Rules, что поможет избежать ситуации, при которой узлы кластеризованного приложения окажутся на одном физическом сервере и могут стать недоступны одновременно из-за сбоя сервера.

Для большинства приложений в случае сбоя ВМ или гостевой ОС может использоваться один из следующих вариантов восстановления:

• Восстановление ВМ из актуальной резервной копии. Ряд СРК предоставляют возможность снижения RTO за счет быстрого запуска ВМ непосредственно с хранилища резервных копий, так называемое мгновенное восстановление (например, Veeam VM Instant Recovery).
• Настройка репликации ВМ (например, средствами vSphere Replication или Veeam Backup & Replication), переключение на реплику.
• Создание мгновенного снимка перед обновлением или изменением настроек для быстрого отката изменения внутри ВМ.

Для некоторых компонентов высокая доступность и отказоустойчивость могут быть обеспечены на уровне приложений.

Например, в VDI инфраструктуре может быть развернуто несколько экземпляров пограничных серверов (View Security Server или Unified Access Gateway) и настроено балансирование нагрузки между серверами при помощи внешнего балансировщика. Это же касается серверов View Connection Server, в одном Pod может быть развернуто до семи серверов, которые будут реплицировать конфигурацию друг с другом, в случае отказа, вышедший сервер может быть удален из кластера и заменен новым сервером-репликой.

Для серверов vCenter Server и PSC в Embedded режиме можно настроить двухузловой кластер vCenter High Availability (для vCenter Server Appliance 6.5 или выше), обеспечивающий репликацию конфигурации и автоматическое переключение на резервный узел. Для сервера vCenter Server под Windows можно настроить защиту служб средствами Microsoft Failover Cluster (для vCenter 5.5 U3 или выше). Для внешних серверов PSC можно развернуть несколько экземпляров серверов в одном SSO домене с репликацией и балансировкой подключений с использованием внешнего балансировщика.

СУБД SQL Server, обслуживающий базы vCenter Server, View Composer и View Event Log, можно кластеризовать с использованием SQL Failover Cluster в конфигурации с общим диском, либо с использованием групп доступности SQL AlwaysOn.

Из всех основных компонентов Horizon, пожалуй, только View Composer не имеет собственных механизмов защиты на уровне приложений и не поддерживает кластеризацию. Для него могут применяться средства защиты на уровне ВМ или на уровне гипервизора.

11.2 Резервное копирование VDI

Резервное копирование серверов View Connection Server выполняется автоматически встроенными средствами. По умолчанию каждый сервер View выполняет архивирование раз в день. Файл с архивом сохраняется локально, поэтому рекомендуется перенести его на сетевое хранилище. Данный бекап может использоваться для восстановления конфигурации View на свежеустановленный сервер Connection Server.

Помимо архива с конфигурацией ценность представляет также цифровые сертификаты и файл конфигурации locked.properties (если вы вносили в них изменения), однако они редко меняются и не требуют регулярного резервного копирования. В качестве альтернативного вариант можно выполнять резервное копирования сервера View целиком в виде виртуальной машины или через агента СРК, установленного в гостевой ОС. 

При восстановлении сервера В инсталляциях Horizon, включающей несколько серверов View в одном Pod, следует помнить о репликации LDAP базы между несколькими серверами, при восстановлении сервера View из бекапа (https://docs.vmware.com/en/VMware-Horizon-7/7.1/com.vmware.horizon-view.installation.doc/GUID-04ADFC96-5EBA-4561-B02C-B70CBE3B1D6A.html).

Сервер View Security Server в отличие от Connection Server не имеет встроенного механизма резервного копирования, т.к. Security Server не хранит никаких данных на самом сервере (за исключением сертификата и того же файла locked.properties). Бекап сервера View Security Server может выполняться целиком в виде ВМ или через агента, установленного в гостевой ОС. В качестве альтернативного варианта можно рассмотреть установку сервера Security Server с нуля с восстановлением конфигурационных файлов и цифрового сертификата.

Сервер Unified Access Gateway, как правило, не нуждается в регулярном резервном копировании, т.к. повторная установка с нуля в большинстве случаев будет проще и быстрее.

Сервер View Composer. Конфигурация Composer хранится в базе поэтому требуется бекапить СУБД, где размещается БД Composer. В качестве альтернативного варианта можно использовать функцию экспорта конфигурации из БД Composer при помощи утилиты командной строки sviconfig. На самом сервере важно сохраниться сертификат. Сервер может быть забекаплен целиком, либо можно забекапить цифровой сертификат.

Сервер vCenter Server поддерживает полное резервное копирование и восстановление на уровне ВМ. При восстановлении из бекапа следует помнить о том, что конфигурация vCenter, восстанавливаемая из бекапа (распределенного коммутатора, состава и настроек кластеров, пулов ресурсов), и текущая конфигурация виртуальной инфраструктуры могут различаться. Помимо восстановления ВМ целиком, в vCenter Server Appliance, начиная с версии 6.5, появился встроенный бекап (File-Based Backup), который позволяет сохранить архив с настройками vCenter на внешнем хранилище, а затем использовать его при развертывании нового апплайнса с нуля.

Что касается резервного копирования и восстановления виртуальных десктопов, то тут следует учитывать следующие моменты:

• Не имеет практического смысла выполнять резервное копирование для floating и non-persistent десктопов, т.к. такие ВМ не предназначены для хранения на них постоянных данных. Гораздо более уместным будет периодическое копирование эталонного образа и проработка возможности оперативного создания большого числа ВМ (например, при помощи механизмов Linked Clone или Instant Clone). При необходимости сохранения изменений в таких виртуальных десктопах, могут использоваться Writable Volumes, доступные в ПО App Volumes. Сами Writable Volumes могут бекапиться с использованием вспомогательных утилит (например, https://labs.vmware.com/flings/app-volumes-backup-utility).
• Если требуется сохранять только данные и настройки пользователей, то более простым вариантом является предварительная настройка перемещаемых профилей и перенаправление рабочих каталогов пользователей с виртуальных десктопов на выделенный файловый сервер, откуда, в свою очередь, они смогут централизованно бекапиться.
• Если вариант с переносом данных на файловый сервер не подходит, например, из-за необходимости бекапить и восстанавливать данные за пределами пользовательских каталогов, вы можете использовать агент СРК, установленный в гостевой ОС. Большинство современных СРК поддерживают резервное копирование клиентских ОС (например, Veeam Agent for Microsoft Windows, Symantec Backup Exec, Microsoft SCDPM и другие). Данный вариант следует применять с осторожностью для Linked Clones ВМ, т.к. восстановление большого объема данных приведет к разрастанию delta-дисков.

11.3 Аварийное восстановление VDI инфраструктуры

Рассмотрим два основных способа организации аварийного восстановления:

• Развертывание Horizon в режиме федерации, включающей несколько Cloud Pod.
• Создание территориально-распределенного кластера vSphere.

Организация федерации из двух и более Pod, размещенных на разных площадках, и использующих разные вычислительные ресурсы для запуска десктопов доступна в VMware Horizon, начиная с 6 версии. Данный вариант позволяет объединить несколько локальных пулов десктопов на нескольких территориально-удаленных площадках в один глобальный пул. При подключении к серверу Connection Server, входящему в федерацию, и выборе глобального пула пользователю будет предоставлена ВМ из одного из локальных пулов, например, из того Pod, к которому подключился пользователь, или с той площадки, которая является для пользователя домашней (Home Site).

В случае отказа площадки и одного из Pod, пользователь может подключиться к другому Pod и запросить виртуальный десктоп из него. К недостаткам данного подхода относится то, что аварийное переключение возможно только для floating pool десктопов. В случае с dedicated пулами, администраторам потребуется отвязать назначенные пользователям виртуальные десктопы перед тем, как пользователи смогут подключиться к глобальному пулу и запросить новый выделенный десктоп. Cloud Pod не предоставляет механизмов по синхронизация данных ВМ между площадками, поэтому копирование эталонных образов, сохранение данных пользователей и установленных приложений и перенос их на десктопы на резервной площадке должно выполняться сторонними средствами. 

Развертывание территориально-распределенной виртуальной инфраструктуры с использованием метро-кластеров (vSphere Metro Storage Cluster). Данный вариант подразумевает создание общего распределенного хранилища, доступного серверам виртуализации на обеих площадках, средствами системы хранения данных. Контроллеры СХД хранят копии данных на каждой из площадок и в реальном времени синхронизируют все изменения. В случае отказа СХД на любой из площадок, серверы виртуализации на второй площадке сохраняют доступ к своей копии данных и могут продолжать работу. Создание территориально-распределенных СХД поддерживается многими производителями, среди примеров реализации можно отметить NetApp MetroCluster, VMware vSAN Stretched Cluster, EMC VPLEX Metro, HPE 3PAR Peer Persistence, HDS GAD и многие другие. К плюсам подобного подхода относится прозрачность работы для ВМ и приложений, для компонентов Horizon такая инсталляция не отличается от обычного HA кластера, возможность обеспечивать катастрофоустойчивую защиту для любых типов виртуальных десктопов. К минусам данного варианта относятся высокие требования к полосе пропускания и задержкам каналов передачи данных из-за необходимости постоянной синхронизации данных между площадками. Кроме того, метро-кластеры требуют наличие территориально-распределенных L2 сетей для сохранения сетевой доступности при переносе ВМ из одной площадки на другую.