Продолжаем говорить о дизайне VDI. Предыдущие части доступны по ссылкам:
Часть 1. Введение
Часть 2. Постановка задачи
Разработка верхнеуровневой архитектуры позволяет сформировать общее понимание назначения и принципов работы системы. Отличие верхнеуровневой архитектуры (HLD – high level design) от низкоуровневой архитектуры (LLD – low level design) заключает в широте охвата и меньшей детализации. На уровне High Level Design нет необходимости спускаться до уровня физических компонентов – указания количества и моделей серверов, процессоров, клиентских устройств, конкретных настроек ПО. HLD должен однозначно отвечать на вопросы – из каких блоков/подсистем состоит система и как они взаимодействуют друг с другом.
Начать проектирование можно с простой концептуальной схемы, которая будет показывать основные блоки, из которых состоит VDI:
На этом этапе можно составить таблицу соответствия требований и решений, которые обеспечивают их реализацию. Например:
Выбор тех или иных решений может приводить к возникновению дополнительных требований и ограничений. Например, использование All-flash vSAN требует наличие 10G Ethernet сети; Linked-Clone ВМ не поддерживают Storage vMotion миграцию; не все приложения могут быть упакованы и доставлены при помощи ThinApp или App Volumes.
При проектировании больших инфраструктур также следует помнить об максимумах, поддерживаемых в той или иной версии продукта. Один сервер View Connection Server может обслуживать до 4000 виртуальных десктопов (или до 2000 в версии 7.1 и ниже), чего более чем достаточно для большинства VDI инфраструктур, а группа серверов (Pod) до 20000 одновременных подключений (до 10000 в Horizon 7.1 и ниже). Несколько Pod могут объединяться между собой в федерацию (данный режим носит название – Cloud Pod Architecture) для организации работы еще большего числа пользователей (Horizon 7.0 поддерживает до 50000 одновременных подключений, Horizon 7.2 – до 120000 подключений, а Horizon 7.3 – до 140000 подключений). О других ограничениях можно узнать из документа VMware Horizon 7 Sizing Limits and Recommendations https://kb.vmware.com/kb/2150348
В зависимости от количества пользователей можно выделить несколько типов инсталляций VDI.
Небольшие инсталляции до 200 виртуальных десктопов (2-3 хоста), где, как правило, служебные ВМ и виртуальные десктопы в целях оптимизации использования ресурсов размещаются на одних и тех же хостах.
Для больших VDI сред (более 2000 ВМ) может потребоваться развернуть несколько серверов vCenter Server. Несмотря на то, что один сервер vCenter поддерживает до 10000 одновременно запущенных ВМ (в vCenter Server 6.5 – до 25000), он может стать узким местом при выполнении операций по созданию, запуску или обновлению виртуальных десктопов. В Horizon для одного сервера vCenter по умолчанию настроен лимит на количество одновременных операций по созданию десктопов (не более 20 для обычных десктопов, не более 8 – для Linked Clone десктопов), что может привести к длительным процедурам создания или обновления ВРС.
Так, например, если развертывание одной ВМ с использованием Linked Clones занимает 5 минут, то при стандартных настройках View для развертывания 1000 ВМ на одном vCenter потребуется порядка 10.5 часов. Для развертывания 2000 ВМ на одном vCenter может потребоваться уже 21 час. Кроме того, отказ vCenter может повлечь за собой невозможность управления большим количеством десктопов. В этом случае установка нескольких серверов vCenter позволить уменьшить домен отказа и распараллелить операции по обслуживанию десктопов.
Обратной стороной такого решения является необходимость обслуживания нескольких серверов vCenter, PSC, Composer, а также настройка Enhanced Linked Mode для получения возможности управления несколькими инсталляциями vCenter из единой консоли.
Помимо развертывания нескольких серверов vCenter в больших инсталляциях также разделяют кластеры vSphere в зависимости от характера нагрузки. Можно выделить два типа кластеров.
Первый тип кластера – ресурсный. В этом кластере находятся хосты, которые обслуживают виртуальные десктопы.
Второй тип кластера – служебный или инфраструктурный. В этом кластере находятся хосты, которые обеспечивают работу служебных ВМ – брокеров VDI, серверов vCenter, балансировщиков нагрузки, файловых серверов, СУБД, серверов для вспомогательных сервисов и т.д.
Разнесение ВМ по разным кластерам продиктовано следующими соображениями.
Снижение затрат на лицензирование. Windows Server требуется лицензировать только на хостах с запущенными ВМ Windows Server. Это же касается лицензий на СРК, если требуется бекапить только служебные ВМ.
Оптимизация нагрузки. Хосты в ресурсном кластере и инфраструктурном кластере могут различаться по аппаратной конфигурации. Как правило на хостах ресурсного кластера выше показатель консолидации, такие серверы имеют более мощные процессоры, больше ОЗУ по сравнению с инфраструктурными хостами. Во многих случаях, когда в организации уже развернута виртуальная инфраструктура, служебные ВМ размещаются на существующих мощностях.
Безопасность. Для хостов, обеспечивающих работу служебных ВМ и виртуальных десктопов, могут выполняться разные настройки безопасности, они могут подключаться к разным сетям, управляться администраторами.
Каждый ресурсных кластер (или группа кластеров) управляется своим сервером vCenter Server, имеет свой набор хранилищ и виртуальных сетей. Все это в совокупности образует стандартизованный блок, который обслуживает свой набор виртуальных десктопов (1000 – 10000 ВМ). Все управляющие серверы ресурсных блоков могут размещаться на вычислительных мощностях инфраструктурного блока. Использование блочного подхода позволит упростить масштабирование и обслуживание инфраструктуры за счет унификации архитектуры и модульности.
Такая инфраструктура может масштабироваться как горизонтально – путем увеличения количества ресурсных блоков, так и вертикально – блок могут расширяться за счет добавления дополнительных хостов, хранилищ и виртуальных сетей, по мере увеличения числа пользователей.
Для огромных VDI сред (от 10000 виртуальных десктопов) может потребоваться развернуть несколько Pod инсталляций Horizon View и объединить их в общую федерацию. На рисунке показан пример инфраструктуры на 16000 виртуальных десктопов.
От чего зависит размер и конфигурация одного блока? Во-первых – от ограничений, накладываемых ПО (vCenter Server, ESXi), во-вторых – от конфигурации виртуальных десктопов и физических хостов.
Текущие максимумы vSphere позволяют создавать кластеры вплоть до 64 узлов. При этом в кластере может быть запущено до 8000 ВМ, защищаемых при помощи HA. При использовании хранилища VSAN в кластере может быть развернуто до 6000 ВМ. Эти лимиты с лихвой перекрывают рекомендации вендора по количеству ВМ, управляемых одной инсталляцией vCenter Server – 4000 ВМ (или 2000 в старых версиях).
https://blogs.vmware.com/performance/2015/03/failover-time-vcenter-server-6-0-protected-vsphere-ha.html
Но даже для таких "небольших" инсталляций есть варианты. Что лучше – развернуть один кластер на 4000 ВМ или несколько кластеров меньшего размера?
Большой по размеру кластер позволяет резервировать меньших ресурсов для обеспечения заданного уровня доступности и эффективнее балансировать нагрузку между узлами.
Сравним два варианта – два кластера по 11 узлов и один 22 узловой кластер. При одинаковом уровне резервирования ресурсов по схеме N+1, в первом случае потребуется зарезервировать ресурсы 2 узлов, а во втором – всего один. Кроме того, 22 узловой кластер позволит обеспечить уровень резервирования N+2 при одинаковых накладных расходах с двумя 11-узловыми кластерами, что позволит гарантированно переживать отказ сразу двух хостов или же переживать отказ одного хоста в момент проведения работ по обслуживанию в кластере.
С другой стороны, для корректной работы механизмов HA и DRS, требуется, чтобы все узлы кластера имели идентичную конфигурацию хранилищ и сети – все общие хранилища должны быть подключены ко всем хостам, хосты должны иметь идентичную конфигурацию групп портов или подключаться к одному распределенном виртуальному коммутатору. Создавая несколько кластеров, вы тем самым уменьшаете размер домена отказа, но в тоже время повышаете накладные расходы на администрирование.
Говоря о распределении ВМ в крупных инсталляциях может возникнуть закономерный вопрос: что является более оптимальным – равномерное распределение десктопов по всем блокам/кластерам/хостам или ассиметричная конфигурация? Например, при необходимости размещения 9000 ВМ у вас есть вариант использовать три блока по 3000 ВМ или три блока по 4000/4000/1000 ВМ. Каждый из вариантов имеет свои плюсы.
Первый вариант позволяет упростить конфигурирование на начальных этапах, обеспечивает более равномерную загрузку всех компонентов, однако может усложнить масштабирование в будущем, поскольку потребует перенастройку всех трех блоков.
Второй вариант – сложнее в первоначальной настройке из-за ассиметричной конфигурации, однако в дальнейшем проще в масштабировании, т.к. потребует настроить только один блок из трех.
На размер блока также влияет показатель консолидации – количество запускаемых ВМ на одном хосте, который напрямую связан с аппаратной конфигурацией ВМ и хостов. Например, для размещения 100 ВМ, каждая из которых имеет по 4 ГБ ОЗУ серверу потребуется 440 ГБ (с учетом 10% запаса для работы гипервизора и накладные расходы). Это весьма далеко от оптимальных значений по объему оперативной памяти (как правило, в серверах устанавливается 384 ГБ или 512 ГБ ОЗУ модулями по 16, 32 или 64 ГБ для организации многоканального режима работы). Поэтому в данном случае более оптимальным может являться размещение на одном сервере 85 или 115 ВМ.
Большое влияние на архитектуру VDI оказывает требование по обеспечению катастрофоустойчивой защиты виртуальных десктопов. Если говорить о доступных вариантах, то катастрофоустойчивая VDI инфраструктура может быть реализована следующими методами:
Совместимость версий продуктов VMware Можно посмотреть по ссылке: https://partnerweb.vmware.com/comp_guide2/sim/interop_matrix.php
При выборе ПО также следует руководствоваться сроками окончания поддержки на те или иные версии ПО: https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/support/product-lifecycle-matrix.pdf
Продолжение доступно по ссылкам:
Часть 1. Введение
Часть 2. Постановка задачи
3.1 Концептуальная схема
После выработки и фиксации основных требований наступает черед разработки верхнеуровневой архитектуры.Разработка верхнеуровневой архитектуры позволяет сформировать общее понимание назначения и принципов работы системы. Отличие верхнеуровневой архитектуры (HLD – high level design) от низкоуровневой архитектуры (LLD – low level design) заключает в широте охвата и меньшей детализации. На уровне High Level Design нет необходимости спускаться до уровня физических компонентов – указания количества и моделей серверов, процессоров, клиентских устройств, конкретных настроек ПО. HLD должен однозначно отвечать на вопросы – из каких блоков/подсистем состоит система и как они взаимодействуют друг с другом.
Начать проектирование можно с простой концептуальной схемы, которая будет показывать основные блоки, из которых состоит VDI:
- Виртуальные десктопы.
- Инфраструктура.
- Клиенты.
Виртуальные десктопы (виртуальные рабочие станции / виртуальные ПК) представляют собой виртуальные машины с установленной ОС и набором приложений. Помимо ОС и приложений виртуальные десктопы также могут хранить пользовательские настройки (рабочее окружение) и различные документы, с которыми работают пользователи.
Одной из первых задач при проектировании данного блока является типизация/группировка виртуальных десктопов по определенному набору параметров (аппаратным характеристикам, установленной ОС и приложениям, типу создания и обновления), что позволяет уменьшить количество уникальных десктопов, упростить сайзинг ресурсов, развертывание, поддержку и резервирование таких десктопов.
Помимо крайне редкого случая One size fits all, когда предполагается использовать всего один тип виртуального десктопа для всех пользователей, можно группировать виртуальные десктопы по отделам (как правило сотрудники одного отдела выполняют однотипные функции, имеют одинаковые компьютеры и используют одинаковый набор приложений), либо более укрупненно – по категориям пользователей. Примеры распространенных категорий пользователей:
Task Worker – пользователь, работающий с определенным ПО и выполняющий ограниченный набор операций. Пример – сотрудники call-центра, сотрудники поддержки 1-й линии, помощники менеджеров. Task Worker’ы обычно используют только офисный пакет, web-браузер, почтовый клиент, и для них не требуется установка дополнительного ПО.
Knowledge Worker – пользователь, работающий с различным набором ПО, включая ПО для создания и редактирования документов, просмотра видео и flash-анимации. Для работы таким пользователям может потребоваться различное периферийное оборудование: принтеры, сканеры, аудио-гарнитуры, web-камеры, а также возможность подключения USB накопителей для копирования файлов. Пользователи могут работать не только из офиса, но и удаленно подключаться к виртуальным десктопам через Интернет.
Power User – продвинутый пользователь. Такие пользователи занимаются ресурсоемкими задачами для которых требуются производительные виртуальные десктопы. К этой категории можно отнести разработчиков ПО. Таким пользователя обычно требуется административный доступ к виртуальному десктопу для установки и работы со сторонним ПО.
Designer – отдельная категория продвинутых пользователей. Используют различные приложения для работы с графикой (ПО для редактирования изображений, ПО для 3D моделирования, CAD/CAM системы). Таким пользователям требуется специализированное оборудование – графические ускорители, мониторы с высоким разрешением, мощные тонкие клиенты для обеспечения надлежащего уровня производительности при работе с графикой.
Contractor – подрядчик. Временные сотрудники, которые работают с определенным набором ПО. Пользователям может потребоваться административный доступ и/или установка дополнительного ПО, а также удаленный доступ из Интернет.
VIP User – привилегированные пользователи. Несмотря на то, что данная категория обычно самая малочисленная, VIP пользователи предъявляют самые высокие требования к производительности, доступности и функциональным возможностям VDI.
Выделив основные категории пользователей станет возможным определить оптимальные вычислительные ресурсы, необходимые для работы виртуальных десктопов каждого типа, необходимый набор ПО, тип десктопов, способ их создания и т.д. Более подробно о типах десктопов будет рассказано в разделе 4. Подсистема VMware Horizon.
Перейдем к детализации инфраструктуры. Инфраструктурный блок можно разделить на несколько составных частей: подсистему виртуализации, обеспечивающую запуск виртуальных десктопов и служебных ВМ, подсистему брокеров VDI, обеспечивающую создание, управление, назначение десктопов пользователям, контроль за подключением к виртуальным десктопам, а также различные вспомогательные сервисы, обеспечивающие мониторинг, резервное копирование, балансирование нагрузки, антивирусную защиту, доставку приложений на десктопы и т.д.
Способ разбиения инфраструктуры составные части может различаться в каждом конкретном случае, например, можно выделить серверное оборудование, дисковое хранилище, сеть передачи данных в отдельные модули, входящие в состав подсистемы виртуализации, либо описать их в качестве подсистем, с которыми взаимодействует подсистема виртуализации. Это же касается и вспомогательных сервисов, они могут быть реализованы в качестве подсистем, входящих в состав VDI инфраструктуры, либо, что чаще встречается на практике, это могут быть выделенные системы, которые уже эксплуатируются у заказчика, и с которыми требуется настроить интеграцию для VDI инфраструктуры.
Более подробно о подсистеме виртуализации будет рассказано в разделе "5. Подсистема виртуализации".
О брокерах VDI будет написано в разделе "4. Подсистема VMware Horizon".
Более подробно о вспомогательных сервисах будет рассказано в разделе "12. Дополнительные сервисы (доставка приложений, мониторинг) ".
Наконец, клиентские устройства. Помимо выбора типа клиентских устройств, следует учитывать место, откуда будут подключаться пользователи (внутренние доверенные сети или Интернет), а также периферийные устройства, которые будут подключаться к виртуальным десктопам.
В качестве клиентских устройств могут выступать различные устройства – стационарные компьютеры или ноутбуки под управлением Windows, MAC OS X, Linux, мобильные устройства (смартфоны, планшеты) под управлением iOS, Android, Windows Phone, тонкие или нулевые клиенты, а также устройства, поддерживающие HTML5 веб-браузеры.
О клиентских устройствах мы поговорим в разделе "10. Организация подключения и безопасность".
Доступ из недоверенных сетей может повлечь за собой дополнительные требования к безопасности – двухфакторная аутентификация, отключение возможности копирования файлов, использование только защищенных соединений и т.д.
Одной из первых задач при проектировании данного блока является типизация/группировка виртуальных десктопов по определенному набору параметров (аппаратным характеристикам, установленной ОС и приложениям, типу создания и обновления), что позволяет уменьшить количество уникальных десктопов, упростить сайзинг ресурсов, развертывание, поддержку и резервирование таких десктопов.
Помимо крайне редкого случая One size fits all, когда предполагается использовать всего один тип виртуального десктопа для всех пользователей, можно группировать виртуальные десктопы по отделам (как правило сотрудники одного отдела выполняют однотипные функции, имеют одинаковые компьютеры и используют одинаковый набор приложений), либо более укрупненно – по категориям пользователей. Примеры распространенных категорий пользователей:
Task Worker – пользователь, работающий с определенным ПО и выполняющий ограниченный набор операций. Пример – сотрудники call-центра, сотрудники поддержки 1-й линии, помощники менеджеров. Task Worker’ы обычно используют только офисный пакет, web-браузер, почтовый клиент, и для них не требуется установка дополнительного ПО.
Knowledge Worker – пользователь, работающий с различным набором ПО, включая ПО для создания и редактирования документов, просмотра видео и flash-анимации. Для работы таким пользователям может потребоваться различное периферийное оборудование: принтеры, сканеры, аудио-гарнитуры, web-камеры, а также возможность подключения USB накопителей для копирования файлов. Пользователи могут работать не только из офиса, но и удаленно подключаться к виртуальным десктопам через Интернет.
Power User – продвинутый пользователь. Такие пользователи занимаются ресурсоемкими задачами для которых требуются производительные виртуальные десктопы. К этой категории можно отнести разработчиков ПО. Таким пользователя обычно требуется административный доступ к виртуальному десктопу для установки и работы со сторонним ПО.
Designer – отдельная категория продвинутых пользователей. Используют различные приложения для работы с графикой (ПО для редактирования изображений, ПО для 3D моделирования, CAD/CAM системы). Таким пользователям требуется специализированное оборудование – графические ускорители, мониторы с высоким разрешением, мощные тонкие клиенты для обеспечения надлежащего уровня производительности при работе с графикой.
Contractor – подрядчик. Временные сотрудники, которые работают с определенным набором ПО. Пользователям может потребоваться административный доступ и/или установка дополнительного ПО, а также удаленный доступ из Интернет.
VIP User – привилегированные пользователи. Несмотря на то, что данная категория обычно самая малочисленная, VIP пользователи предъявляют самые высокие требования к производительности, доступности и функциональным возможностям VDI.
Выделив основные категории пользователей станет возможным определить оптимальные вычислительные ресурсы, необходимые для работы виртуальных десктопов каждого типа, необходимый набор ПО, тип десктопов, способ их создания и т.д. Более подробно о типах десктопов будет рассказано в разделе 4. Подсистема VMware Horizon.
Перейдем к детализации инфраструктуры. Инфраструктурный блок можно разделить на несколько составных частей: подсистему виртуализации, обеспечивающую запуск виртуальных десктопов и служебных ВМ, подсистему брокеров VDI, обеспечивающую создание, управление, назначение десктопов пользователям, контроль за подключением к виртуальным десктопам, а также различные вспомогательные сервисы, обеспечивающие мониторинг, резервное копирование, балансирование нагрузки, антивирусную защиту, доставку приложений на десктопы и т.д.
Способ разбиения инфраструктуры составные части может различаться в каждом конкретном случае, например, можно выделить серверное оборудование, дисковое хранилище, сеть передачи данных в отдельные модули, входящие в состав подсистемы виртуализации, либо описать их в качестве подсистем, с которыми взаимодействует подсистема виртуализации. Это же касается и вспомогательных сервисов, они могут быть реализованы в качестве подсистем, входящих в состав VDI инфраструктуры, либо, что чаще встречается на практике, это могут быть выделенные системы, которые уже эксплуатируются у заказчика, и с которыми требуется настроить интеграцию для VDI инфраструктуры.
Более подробно о подсистеме виртуализации будет рассказано в разделе "5. Подсистема виртуализации".
О брокерах VDI будет написано в разделе "4. Подсистема VMware Horizon".
Более подробно о вспомогательных сервисах будет рассказано в разделе "12. Дополнительные сервисы (доставка приложений, мониторинг) ".
Наконец, клиентские устройства. Помимо выбора типа клиентских устройств, следует учитывать место, откуда будут подключаться пользователи (внутренние доверенные сети или Интернет), а также периферийные устройства, которые будут подключаться к виртуальным десктопам.
В качестве клиентских устройств могут выступать различные устройства – стационарные компьютеры или ноутбуки под управлением Windows, MAC OS X, Linux, мобильные устройства (смартфоны, планшеты) под управлением iOS, Android, Windows Phone, тонкие или нулевые клиенты, а также устройства, поддерживающие HTML5 веб-браузеры.
О клиентских устройствах мы поговорим в разделе "10. Организация подключения и безопасность".
Доступ из недоверенных сетей может повлечь за собой дополнительные требования к безопасности – двухфакторная аутентификация, отключение возможности копирования файлов, использование только защищенных соединений и т.д.
3.2 Логический дизайн
Закончив с концептуальной схемой, пришло время переходить к логическому дизайну и согласованию используемых технических решений. Выбор используемых продуктов и технологий, в первую очередь, должен быть обусловлен имеющимися требованиями и ограничениям, сформированными на этапе постановки задачи, во вторую – финансовыми соображениями, в третью – простотой реализации и дальнейшей поддержки решения.На этом этапе можно составить таблицу соответствия требований и решений, которые обеспечивают их реализацию. Например:
Требование | Компонент | Технология / ПО |
| Требуется обеспечить централизованное управление виртуальными десктопами | VDI брокер | Horizon View |
| Должен быть обеспечен безопасный доступ из сети Интернет | Удаленный доступ | Unified Access Gateway |
| В случае отказа сервера VDI должно быть обеспечено автоматическое перенаправление подключений на резервный сервер | Балансирование доступа | F5 BIG-IP |
| Гипервизор должен быть совместим с ПО управления виртуальными десктопами | Платформа виртуализации | vSphere Desktop |
| Для экономии дискового пространства все виртуальные десктопы должны создаваться из единого образа с использованием технологии дельта-копий | Виртуальные десктопы | Persistent Linked Clones |
| В качестве ОС на виртуальных десктопах должна использоваться поддерживаемая клиентская версия ОС Windows | ОС для виртуальных десктопов | Windows 10 Enterprise |
| Подключение к виртуальным десктопом должно осуществляться с существующих ПК пользователей или с тонких клиентов | Доступ к виртуальным десктопам | Клиент Horizon Client Тонкие клиенты Dell Wyse |
| На всех виртуальных десктопах должно быть предустановлено антивирусное ПО | Антивирусная защита ВМ | Kaspersky Security Light Agent |
| Должен быть обеспечен мониторинг всех компонентов VDI инфраструктуры | Мониторинг | vRealize Operations for Horizon |
| Должна быть предусмотрена возможность установки на виртуальные десктопы дополнительного ПО не входящего в состав эталонного образа | Доставка приложений | ThinApp, App Volumes |
| Профили и настройки пользователей должны храниться на выделенном файловом сервере | Управление профилями и настройками рабочего стола пользователей | User Environment Manager |
| Для ПО виртуализации должны использоваться стандартные серверы для установки в 19" стойку | Типы серверов | Rackmount серверы |
| Для хранения данных виртуальных машин должно использоваться распределенное хранилище на базе локальных накопителей, устанавливаемых в серверы | Хранилище данных | vSAN |
Выбор тех или иных решений может приводить к возникновению дополнительных требований и ограничений. Например, использование All-flash vSAN требует наличие 10G Ethernet сети; Linked-Clone ВМ не поддерживают Storage vMotion миграцию; не все приложения могут быть упакованы и доставлены при помощи ThinApp или App Volumes.
При проектировании больших инфраструктур также следует помнить об максимумах, поддерживаемых в той или иной версии продукта. Один сервер View Connection Server может обслуживать до 4000 виртуальных десктопов (или до 2000 в версии 7.1 и ниже), чего более чем достаточно для большинства VDI инфраструктур, а группа серверов (Pod) до 20000 одновременных подключений (до 10000 в Horizon 7.1 и ниже). Несколько Pod могут объединяться между собой в федерацию (данный режим носит название – Cloud Pod Architecture) для организации работы еще большего числа пользователей (Horizon 7.0 поддерживает до 50000 одновременных подключений, Horizon 7.2 – до 120000 подключений, а Horizon 7.3 – до 140000 подключений). О других ограничениях можно узнать из документа VMware Horizon 7 Sizing Limits and Recommendations https://kb.vmware.com/kb/2150348
В зависимости от количества пользователей можно выделить несколько типов инсталляций VDI.
Небольшие инсталляции до 200 виртуальных десктопов (2-3 хоста), где, как правило, служебные ВМ и виртуальные десктопы в целях оптимизации использования ресурсов размещаются на одних и тех же хостах.
Для больших VDI сред (более 2000 ВМ) может потребоваться развернуть несколько серверов vCenter Server. Несмотря на то, что один сервер vCenter поддерживает до 10000 одновременно запущенных ВМ (в vCenter Server 6.5 – до 25000), он может стать узким местом при выполнении операций по созданию, запуску или обновлению виртуальных десктопов. В Horizon для одного сервера vCenter по умолчанию настроен лимит на количество одновременных операций по созданию десктопов (не более 20 для обычных десктопов, не более 8 – для Linked Clone десктопов), что может привести к длительным процедурам создания или обновления ВРС.
Так, например, если развертывание одной ВМ с использованием Linked Clones занимает 5 минут, то при стандартных настройках View для развертывания 1000 ВМ на одном vCenter потребуется порядка 10.5 часов. Для развертывания 2000 ВМ на одном vCenter может потребоваться уже 21 час. Кроме того, отказ vCenter может повлечь за собой невозможность управления большим количеством десктопов. В этом случае установка нескольких серверов vCenter позволить уменьшить домен отказа и распараллелить операции по обслуживанию десктопов.
Обратной стороной такого решения является необходимость обслуживания нескольких серверов vCenter, PSC, Composer, а также настройка Enhanced Linked Mode для получения возможности управления несколькими инсталляциями vCenter из единой консоли.
Помимо развертывания нескольких серверов vCenter в больших инсталляциях также разделяют кластеры vSphere в зависимости от характера нагрузки. Можно выделить два типа кластеров.
Первый тип кластера – ресурсный. В этом кластере находятся хосты, которые обслуживают виртуальные десктопы.
Второй тип кластера – служебный или инфраструктурный. В этом кластере находятся хосты, которые обеспечивают работу служебных ВМ – брокеров VDI, серверов vCenter, балансировщиков нагрузки, файловых серверов, СУБД, серверов для вспомогательных сервисов и т.д.
Разнесение ВМ по разным кластерам продиктовано следующими соображениями.
Снижение затрат на лицензирование. Windows Server требуется лицензировать только на хостах с запущенными ВМ Windows Server. Это же касается лицензий на СРК, если требуется бекапить только служебные ВМ.
Оптимизация нагрузки. Хосты в ресурсном кластере и инфраструктурном кластере могут различаться по аппаратной конфигурации. Как правило на хостах ресурсного кластера выше показатель консолидации, такие серверы имеют более мощные процессоры, больше ОЗУ по сравнению с инфраструктурными хостами. Во многих случаях, когда в организации уже развернута виртуальная инфраструктура, служебные ВМ размещаются на существующих мощностях.
Безопасность. Для хостов, обеспечивающих работу служебных ВМ и виртуальных десктопов, могут выполняться разные настройки безопасности, они могут подключаться к разным сетям, управляться администраторами.
Каждый ресурсных кластер (или группа кластеров) управляется своим сервером vCenter Server, имеет свой набор хранилищ и виртуальных сетей. Все это в совокупности образует стандартизованный блок, который обслуживает свой набор виртуальных десктопов (1000 – 10000 ВМ). Все управляющие серверы ресурсных блоков могут размещаться на вычислительных мощностях инфраструктурного блока. Использование блочного подхода позволит упростить масштабирование и обслуживание инфраструктуры за счет унификации архитектуры и модульности.
Для огромных VDI сред (от 10000 виртуальных десктопов) может потребоваться развернуть несколько Pod инсталляций Horizon View и объединить их в общую федерацию. На рисунке показан пример инфраструктуры на 16000 виртуальных десктопов.
Текущие максимумы vSphere позволяют создавать кластеры вплоть до 64 узлов. При этом в кластере может быть запущено до 8000 ВМ, защищаемых при помощи HA. При использовании хранилища VSAN в кластере может быть развернуто до 6000 ВМ. Эти лимиты с лихвой перекрывают рекомендации вендора по количеству ВМ, управляемых одной инсталляцией vCenter Server – 4000 ВМ (или 2000 в старых версиях).
https://blogs.vmware.com/performance/2015/03/failover-time-vcenter-server-6-0-protected-vsphere-ha.html
Но даже для таких "небольших" инсталляций есть варианты. Что лучше – развернуть один кластер на 4000 ВМ или несколько кластеров меньшего размера?
Большой по размеру кластер позволяет резервировать меньших ресурсов для обеспечения заданного уровня доступности и эффективнее балансировать нагрузку между узлами.
Сравним два варианта – два кластера по 11 узлов и один 22 узловой кластер. При одинаковом уровне резервирования ресурсов по схеме N+1, в первом случае потребуется зарезервировать ресурсы 2 узлов, а во втором – всего один. Кроме того, 22 узловой кластер позволит обеспечить уровень резервирования N+2 при одинаковых накладных расходах с двумя 11-узловыми кластерами, что позволит гарантированно переживать отказ сразу двух хостов или же переживать отказ одного хоста в момент проведения работ по обслуживанию в кластере.
С другой стороны, для корректной работы механизмов HA и DRS, требуется, чтобы все узлы кластера имели идентичную конфигурацию хранилищ и сети – все общие хранилища должны быть подключены ко всем хостам, хосты должны иметь идентичную конфигурацию групп портов или подключаться к одному распределенном виртуальному коммутатору. Создавая несколько кластеров, вы тем самым уменьшаете размер домена отказа, но в тоже время повышаете накладные расходы на администрирование.
Говоря о распределении ВМ в крупных инсталляциях может возникнуть закономерный вопрос: что является более оптимальным – равномерное распределение десктопов по всем блокам/кластерам/хостам или ассиметричная конфигурация? Например, при необходимости размещения 9000 ВМ у вас есть вариант использовать три блока по 3000 ВМ или три блока по 4000/4000/1000 ВМ. Каждый из вариантов имеет свои плюсы.
Первый вариант позволяет упростить конфигурирование на начальных этапах, обеспечивает более равномерную загрузку всех компонентов, однако может усложнить масштабирование в будущем, поскольку потребует перенастройку всех трех блоков.
Второй вариант – сложнее в первоначальной настройке из-за ассиметричной конфигурации, однако в дальнейшем проще в масштабировании, т.к. потребует настроить только один блок из трех.
На размер блока также влияет показатель консолидации – количество запускаемых ВМ на одном хосте, который напрямую связан с аппаратной конфигурацией ВМ и хостов. Например, для размещения 100 ВМ, каждая из которых имеет по 4 ГБ ОЗУ серверу потребуется 440 ГБ (с учетом 10% запаса для работы гипервизора и накладные расходы). Это весьма далеко от оптимальных значений по объему оперативной памяти (как правило, в серверах устанавливается 384 ГБ или 512 ГБ ОЗУ модулями по 16, 32 или 64 ГБ для организации многоканального режима работы). Поэтому в данном случае более оптимальным может являться размещение на одном сервере 85 или 115 ВМ.
Большое влияние на архитектуру VDI оказывает требование по обеспечению катастрофоустойчивой защиты виртуальных десктопов. Если говорить о доступных вариантах, то катастрофоустойчивая VDI инфраструктура может быть реализована следующими методами:
- Развертывание двух полностью независимых инфраструктур (основной и резервной).
- Частичное резервирование инфраструктур с возможность ручного или полуавтоматического переключения или внешних механизмов, обеспечивающих катастрофоусточивость (репликацию томов СХД, резервное копирование и использование сценариев автоматического развертывания и т.д.).
- Создание территориально-распределенной инфраструктуры, обеспечивающей автоматическое переключение между площадками, которые могут работать в режиме active-active (Stretched Cluster).
Для всех вариантов могут использоваться механизмы, обеспечивающие балансировку подключений между площадками. Более подробно о вариантах обеспечения катастрофоустойчивости в главе "11. Доступность, Резервное копирование и аварийное восстановление".
3.3 Выбор версий и определение совместимости ПО
Несмотря на то, что выбор конкретных версий используемого ПО не является первоочередной задачей при планировании верхнеуровневой архитектуры, они могут наложить серьезные ограничения на планируемую инфраструктуру, в первую очередь, из-за ограничений по совместимости (в организации может быть развернуто ПО резервного копирования, мониторинга или безопасности, которое не совместимости с последними версиями ПО VDI). Кроме того, часть функциональных возможностей доступны только в определенных версиях ПО (например, Blast появился в Horizon 7.0, дедупликация и компрессия в VSAN 6.2 и выше и т.д., поддержка vCenter Server Appliance HA в vCenter 6.5 и т.д.). Для решения этой задачи требуется подготовить матрицу совместимости. Пример таблицы.Horizon | vSphere | vSAN | vCenter | vROps for Horizon |
| 7.3 | 6.5d | 6.6 | 6.5d | 6.5.1 |
| 7.0 | 6.0 | 6.0 | 6.0 | 6.1 |
Совместимость версий продуктов VMware Можно посмотреть по ссылке: https://partnerweb.vmware.com/comp_guide2/sim/interop_matrix.php
При выборе ПО также следует руководствоваться сроками окончания поддержки на те или иные версии ПО: https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/support/product-lifecycle-matrix.pdf
Продолжение доступно по ссылкам:
