В данной статье описывается, как развернуть дома полноценную лабораторию VMware Cloud Foundation (VCF) на одном физическом компьютере. Мы рассмотрим выбор оптимального оборудования, поэтапную установку всех компонентов VCF (включая ESXi, vCenter, NSX, vSAN и SDDC Manager), разберем архитектуру и взаимодействие компонентов, поделимся лучшими практиками для работы в условиях ограниченных ресурсов, а также обсудим вопросы обновления и резервного копирования.
1. Рекомендации по выбору оборудования
Процессор. Для лаборатории VCF критически важно, чтобы процессор поддерживал аппаратную виртуализацию – Intel VT-x с EPT или AMD-V с RVI. Без этих технологий вы не сможете запускать гипервизоры (ESXi) внутри виртуальных машин (т.е. использовать nested virtualizaton). Подойдут современные многопоточные CPU Intel Core/Xeon или AMD Ryzen/EPYC с достаточным числом ядер. Количество ядер влияет на то, сколько нагрузок вы сможете запустить параллельно.
Например, минимально комфортная конфигурация для полной VCF-лаборатории на одном хосте – около 12 физических ядер (или 24 логических потока с Hyper-Threading). В официальных рекомендациях инструмент Holodeck (часто используемый для автоматизированного развертывания VCF) требует 16 ядер, но в тестовой среде энтузиасты успешно запускают VCF даже на одном хосте с 12 ядрами.
При выборе между Intel и AMD можно ориентироваться на бюджет и энергопотребление. Многие отмечают, что AMD-процессоры дают больше ядер за ту же цену и энергоэффективнее, поэтому все чаще используются в домашних лабораториях (см. статью VMware Cloud Foundation (VCF) Homelab Hardware Options). Главное – убедиться, что модель CPU не устарела настолько, чтобы ее поддержка исчезла в новых версиях VMware (проверить совместимость можно в базе знаний VMware по поддержке CPU).
Оперативная память (RAM). VCF включает множество компонентов, поэтому памяти требуется много. Оптимальный объем ОЗУ – 128 ГБ и более. На таком объеме можно запустить все необходимые виртуальные машины (4 узла ESXi, vCenter, NSX Manager, SDDC Manager и др.) в минимальных конфигурациях. Энтузиасты сообщают, что благодаря использованию самых малых шаблонов развёртывания компонентов VCF (vCenter – Tiny, Log Insight – xSmall и т.п.) им удалось свободно использовать VCF на хосте с 128 ГБ RAM.
Если 128 ГБ вам недоступно, минимально возможный вариант – около 64 ГБ, но в этом случае придется существенно урезать настройки и не запускать все компоненты одновременно. Помните, что память обычно заканчивается быстрее всего при экспериментах, поэтому стоит установить максимально возможный объем RAM для вашей платформы. Полезно также проверить поддержку функции Memory Tiering (в vSphere 8) – при наличии скоростного NVMe-накопителя гипервизор может использовать его как дополнительный уровень памяти, что частично компенсирует нехватку ОЗУ.
Хранилище. Производительность и объем дисковой подсистемы сильно влияют на работу VCF-лаборатории. Рекомендуется использовать твердотельные накопители (SSD или NVMe). Общий необходимый объем – от 2 ТБ и выше, так как придется хранить образы нескольких виртуальных ESXi и всех управляющих ВМ. Идеально – NVMe SSD с высокой скоростью, особенно для тех данных, где важны IOPS (например, для кэша vSAN). Хорошей стратегией будет сочетание: один быстрый NVMe-диск под основные рабочие нагрузки (в том числе под файлы ВМ nested-узлов ESXi и их виртуальные диски для vSAN), а дополнительный SATA SSD или HDD – под менее критичные данные (образы ISO, резервные копии и пр.).
В лаборатории Jimmy Mankowitz, например, использовались NVMe SSD емкостью 1 ТБ для емкостных дисков vSAN и SATA SSD ~960 ГБ для кэш-дисков. В нашем случае, когда все виртуальные узлы находятся на одном физическом сервере, можно поступить проще: создать для каждого nested-ESXi по два виртуальных диска – небольшой (скажем, 40–50 ГБ) для кэша vSAN и большего объема (200–300 ГБ) для емкости vSAN.
Важно: при размещении нескольких виртуальных дисков на одном физическом носителе используйте тонкое развертывание дисков (thin provisioning), чтобы не резервировать весь объем сразу. Это позволит экономно расходовать место, поскольку далеко не все виртуальные диски будут заполнены в тестовой среде. Кроме того, thin-диски вместе с механизмом компрессии и дедупликации памяти на уровне ESXi помогут оптимизировать расход ресурсов.
Сетевые адаптеры. Для одиночного хоста достаточно одного физического сетевого адаптера, но лучше иметь 2 и более портов. Один интерфейс можно выделить под управление и внешний доступ, а второй – под внутренний трафик (vSAN, vMotion, оверлей NSX). В реальных развертываниях VCF требуются высокоскоростные каналы (10 Гбит/с), однако для домашней лаборатории обычно используются 1 Гбит/с порты.
Если есть возможность, можно установить недорогую 10 Гбит/с карту (например, SFP+ или 10Gbase-T) – это ускорит обмен данными vSAN и NSX, но тогда и домашний коммутатор должен поддерживать 10 Гбит. В крайнем случае и 1 Гбит/с подойдет, просто операции ввода-вывода могут выполняться медленнее. Убедитесь, что выбранный сетевой адаптер совместим с VMware ESXi (карты Intel PRO/1000, I350, X520/X710 и аналогичные обычно хорошо поддерживаются драйверами, как и адаптеры Broadcom/Emulex/Marvell для серверов).
Конфигурация сети должна предусматривать работу с VLAN (802.1Q), так как в лаборатории VCF придется разделять трафик по типам (управление, vSAN, vMotion, NSX и т.д.). Если у вашего коммутатора нет поддержки VLAN, можно ограничиться одной общей подсетью, но это не отражает лучших практик и затруднит эмуляцию реального окружения. В крайнем случае, все сети (Management, vMotion, vSAN и пр.) могут быть логически разнесены по разным IP-сетям, но идти через один несегментированный порт – это не идеально с точки зрения безопасности и отладки. Рекомендуется хотя бы настроить на виртуальном коммутаторе ESXi специальные порты с тегом VLAN 4095 (trunk mode), чтобы изолировать трафик виртуальных сегментов внутри хоста. Мы вернемся к сетевой настройке далее, при развертывании.
Итог по оборудованию: оптимальным для одной машины будет мощный сервер с 12–16 ядрами, 128 ГБ RAM, ~2 ТБ SSD/NVMe и двумя гигабитными (или лучше 10-гигабитными) NIC. Это существенно ниже требований промышленного развертывания (в продакшене на VCF обычно закладывают 4 сервера только под management domain и еще минимум 3 под каждый домен нагрузок (например, как здесь это реализовано на базе двух физических серверов), но путем уплотнения ресурсов мы сможем запустить VCF даже на такой домашней конфигурации. Например, известно, что с включением всех оптимизаций лаба VCF запускается на одном хосте с 12 CPU и 128 ГБ ОЗУ. Если ваш бюджет ограничен, можно начинать и с 64 ГБ RAM и меньшим числом ядер, но тогда, возможно, стоит рассмотреть развёртывание не всех компонентов или использовать трюк с однокомпонентным развертыванием (об этом далее). В любом случае, убедитесь, что ваше оборудование исправно охлаждается (нагрузка будет серьезной) и бесперебойно питается (желательно ИБП, чтобы долгий процесс развертывания не прервался из-за скачка электричества).
2. Развертывание всех компонентов VCF (пошагово)
Развертывание VMware Cloud Foundation в лабораторных условиях – это нетривиальный процесс, включающий nested-виртуализацию (запуск ESXi как ВМ внутри гипервизора), настройку сетей и использование специального средства Cloud Builder для автоматической установки компонентов. Ниже приведен пошаговый план, как поднять все составляющие VCF на одном физическом сервере.
Шаг 1: Базовый гипервизор на физическом хосте
Первым делом установите на сам физический сервер гипервизор, который будет выступать слоем L1 – платформой для всех других виртуальных машин. Оптимальный выбор – VMware ESXi (новейшей версии, совместимой с VCF, например 8.0 U3). ESXi максимально эффективно использует ресурсы и официально поддерживает nested-виртуализацию VMware. Альтернативный вариант – использовать VMware Workstation Pro на существующей ОС (например, Windows), однако это даст лишний оверхед и усложнит сетевую часть. Поэтому рекомендуется выделить машину полностью под ESXi. Установите ESXi на ваш сервер (можно на небольшой отдельный SSD/USB-диск) и выполните базовую настройку: назначьте IP-адрес для Management Network (в вашей домашней сети или отдельной), включите доступ по SSH и т.д.
После установки ESXi убедитесь, что в настройках BIOS сервера включены опции виртуализации (Intel VT-x/VT-d или AMD-V/Vi) – без них ESXi не позволит запускать «виртуализированные» гостевые гипервизоры. Если всё в порядке, подключитесь к ESXi через vSphere Client с другого компьютера и подготовьте хост к следующему шагу.
Шаг 2: Настройка сети на уровне физического ESXi (L1)
Прежде чем создавать вложенные гипервизоры, нужно настроить виртуальные коммутаторы на физическом хосте так, чтобы обеспечивать связь между nested-ESXi (слой L2) и внешним миром. Создайте на ESXi стандартный vSwitch (или распределенный vDS, если у вас будет vCenter для L1, но для одного хоста достаточно стандартного) и прикрепите к нему физический NIC, который пойдет для лабораторного трафика. Этот vSwitch будет обслуживать все VLAN, используемые внутри VCF. Рекомендуется настроить Trunk-порт с VLAN ID 4095 – это означает, что портгруппа сможет пропускать трафик всех VLAN (виртуальный аналог trunk-порта коммутатора). Например, можно создать на vSwitch0 портгруппу типа «VCF-Transit» с VLAN 4095.
Включите расширенные настройки безопасности на этой портгруппе:
Promiscuous Mode (режим прослушивания всех пакетов) = Accept
Forged Transmits = Accept
MAC Address Changes = Accept
Эти параметры нужны для корректной работы вложенных ESXi, чтобы их трафик свободно проходил через виртуальный коммутатор верхнего уровня. Без режима Promiscuous виртуальные машины внутри nested-ESXi не смогут взаимодействовать, так как внешний коммутатор будет отбрасывать «неизвестные» MAC-адреса. Также установите MTU 9000 (jumbo frames) на этом vSwitch, если планируете задействовать NSX-T – оверлей-сети NSX выигрывают от более крупного MTU, снижая накладные расходы.
Если в сервере несколько физических NIC, разумно разнести трафик: например, NIC1 использовать для управления (Management, доступ с домашней сети), а NIC2 – для всего остального (vSAN, vMotion, NSX). В упомянутой ранее лаборатории на 2 физических хоста автор подключал 1-гигабитный порт под управление, а 10-гигабитные – под vSAN/vMotion. В нашей однохостовой лабе можно все пустить через один порт с VLAN, либо если есть 2+ портов – задействовать их для разных vSwitch (например, vSwitch0 – Management на NIC1, vSwitch1 – vSAN+vMotion на NIC2). Однако для упрощения можно оставить один объединенный коммутатор – в конце концов, физически у нас один хост, и разнос трафика носит логический характер.
DNS и сервисы. На этом этапе также позаботьтесь о службах инфраструктуры: DNS и NTP. VCF очень требователен к правильному DNS-сопряжению – у всех основных компонентов должны быть разрешаемые имена (A-запись) и обратные записи (PTR) на IP. Если в вашей домашней сети уже есть DNS-сервер – пропишите там необходимые записи (для ESXi-хостов, для будущего vCenter, NSX Manager, SDDC Manager и пр. с придуманными именами домена). Если нет – можно развернуть локальный DNS-сервер как ВМ (например, Windows Server (AD DS) или Linux + BIND) на этом же хосте или воспользоваться файлом hosts на Cloud Builder (временное решение). Также убедитесь, что все системы будут иметь доступ к единому NTP-серверу (можно использовать интернет NTP или поднять свой). В лабораторном сценарии Cloud Builder может даже выполнить роль DHCP, DNS и BGP сервера при автоматической установке, но при ручной подготовке лучше настроить эти вещи самостоятельно.
Шаг 3: Создание вложенных узлов ESXi (слой L2)
Теперь создадим четыре виртуальные машины, которые будут эмулировать физические узлы Management Domain VCF (в стандартной архитектуре их 4). Каждой ВМ установим гипервизор ESXi 8.x. Этот процесс включает несколько этапов:
Создание ВМ. В vSphere Client (на вашем физическом хосте) создайте первую виртуальную машину. Укажите гостевую ОС как VMware ESXi (соответствующей версии). Назначьте ресурсы: как минимум 4 vCPU (лучше 6-8 vCPU, если позволяет общее число ядер), 16–32 ГБ RAM, включите опцию передачи виртуализации в гостевую ОС (Expose hardware virtualization to guest). Последнее критично, иначе ESXi внутри не запустит свои виртуальные машины. Добавьте диск для самого ESXi (например, 10–20 ГБ). Затем добавьте еще два диска: один поменьше (например, 30–50 ГБ) для кэша vSAN, и второй большего размера (100–200 ГБ) для емкостного хранилища vSAN. Обязательно установите эти диски как "Independent, persistent" и без активирования снапшотов, если планируете использовать автоматизированное развертывание (VCF Lab Constructor может этого требовать).
Сеть. Подключите сетевой адаптер ВМ к портгруппе trunk (VCF-Transit), созданной на шаге 2. В параметрах сети ВМ можно указать VLAN 4095 или «All (4095)» для приема всех VLAN (если vSwitch не trunk, а portgroup с конкретным VLAN, то укажите соответствующий VLAN ID для Management-сети). Обычно проще использовать trunk.
Установка ESXi. Подключите ISO-образ установочного диска VMware ESXi (той же версии, что на физическом, либо совместимой – например, ESXi 8.0) к CD-приводу ВМ и запустите ее консоль. Пройдите установку ESXi как обычно, выбрав в качестве целевого диска первый виртуальный диск (10–20 ГБ). После установки настройте Management Network: задайте статический IP из вашего диапазона управления (например, 192.168.70.11/24 для host1, .12 для host2 и т.д., если выбрана подсеть 192.168.70.0/24 под management), маску, шлюз, DNS-сервер и уникальное имя хоста (FQDN, например esxi-mgmt-1.lab.local). Убедитесь, что каждый nested-ESXi пингуется и резолвится по имени.
Повторите для 4 узлов. Создайте еще три аналогичные ВМ для ESXi2, ESXi3, ESXi4. Можно ускорить процесс: настроив первую, сделать из нее шаблон (template) и развернуть остальные с помощью шаблона, затем поправить сетевые настройки вручную. Либо можно воспользоваться сценариями автоматизации. Например, существует Ansible-плейбук, автоматически создающий и настраивающий nested-ESXi. Но для понимания процесса можно выполнить и вручную (установка 4 узлов займет ~30 минут при наличии заранее загруженного ISO.
Проверка соединения между узлами. После запуска всех четырех ВМ ESXi, убедитесь что вы можете к ним подключиться через vSphere Client (к каждому по IP). Они пока независимы, не в кластере – это нормально. Важно, чтобы каждый из них видел друг друга по сети управления. Если они в одном VLAN и подсети – пропингуйте (со страницы DCUI или через ssh, разрешив SSH на них). Также проверьте доступность DNS с nested-ESXi (nslookup hostname другого хоста) и NTP (ntpq –p).
Примечание: хотя стандартным для VCF является 4-host management domain, в лаборатории допускается сократить число узлов. Известен трюк от инженеров VMware, позволяющий развернуть VCF даже на одном узле ESXi – Cloud Builder можно сконфигурировать так, чтобы он игнорировал проверку на 4 хоста. В этом случае он развернет кластер vSAN из 1 узла (без отказоустойчивости). Однако такой сценарий официально не поддерживается VMware. Тем не менее, если ресурсы очень ограничены, можно попробовать установить только один nested-ESXi и применять особую настройку (об этом далее, когда будем запускать Cloud Builder). В этой статье мы исходим из классического сценария (4 узла), так как он максимально приближен к реальной архитектуре и позволяет изучить все компоненты.
Шаг 4: Деплой VMware Cloud Foundation (Cloud Builder и SDDC Manager)
Когда 4 виртуальных хоста ESXi готовы, следующим шагом идет развертывание самих компонентов Cloud Foundation: vCenter, NSX-T, SDDC Manager и др. В ручном режиме установить их по отдельности – чрезвычайно трудоемкая задача. Поэтому VMware предоставляет специальный автоматизированный инструмент Cloud Builder. Это готовый виртуальный модуль (OVA-шаблон), который нужно развернуть и сконфигурировать, чтобы он поднял всю инфраструктуру VCF автоматически.
Получение Cloud Builder. Зайдите на портал VMware (my.vmware.com) и скачайте OVA-шаблон VMware Cloud Foundation Cloud Builder нужной версии (совместимой с версией VCF, которую планируете, например VCF 5.1 -> Cloud Builder 5.1). Учтите, что скачивание требует учетной записи с правами загрузки (в программе vExpert или по trial-приглашению). В некоторых случаях Cloud Builder OVA можно получить через обращение к представителю VMware.
Развертывание Cloud Builder. Импортируйте OVA Cloud Builder на физический ESXi-хост (L1) – НЕ внутрь одного из nested-ESXi! Cloud Builder должен иметь доступ к всем четырем ESXi, то есть находиться в той же физической сети управления. Поэтому разверните его прямо на вашем основном хосте ESXi. Выделите Cloud Builder ВМ ресурсы: ~4 vCPU, 18–20 ГБ RAM, 100 ГБ диск. Подключите сетевой адаптер Cloud Builder к тому же vSwitch/портгруппе, что и management-сеть ваших nested-ESXi (например, VLAN 70 или trunk). Задайте Cloud Builder статический IP в сети Management (например, 192.168.70.10) и соответствующий hostname (cloudbuilder.lab.local). После включения Cloud Builder некоторое время инициирует свои сервисы, затем станет доступен веб-интерфейс по HTTPS (https://<IP_CloudBuilder>/) – убедитесь, что можете открыть его.
Подготовка параметров развертывания. Cloud Builder требует от нас файл конфигурации, описывающий всю нашу будущую инфраструктуру: IP-адреса, пароли, VLAN ID, имена хостов и т.д. Этот файл можно подготовить в виде Excel Workbook или JSON. Проще использовать готовый шаблон Excel (скачивается с VMware) – Deployment Parameter Workbook, заполнить его, а затем импортировать в Cloud Builder (сервис сам конвертирует в JSON).
В workbook необходимо указать:
Список ESXi-хостов для Management Domain (их IP, пароли администратора). У нас их 4 (или 1, если вы решились на unsupported-сценарий).
Планируемые адреса для VCF-менеджеров: vCenter (MGMT), NSX Manager, Edge (если требуется), SDDC Manager, PSC (если отдельный, но в новых версиях vCenter уже используется embedded PSC), и так далее.
VLAN ID для разных сетей: Management, vMotion, vSAN, NSX-T Overlay, NSX-T Edge Uplink и т.п. (например, Management VLAN 70, vMotion 71, vSAN 72, Overlay 74, как в примере ниже).
IP-пулы для NSX-T TEP (Tunnel Endpoints) на хостах.
Данные о серверах DNS, NTP.
Пароли для всех компонентов (ESXi, vCenter SSO, NSX admin и т.п.).
Лицензионные ключи для vSphere, vSAN, NSX, если вы их уже получили. Однако, начиная с VCF 5.1.1 доступен режим License Later – можно вообще не указывать ключи на этапе развертывания, работая в trial-режиме. Для этого в JSON добавляется флаг "deployWithoutLicenseKeys": true, либо в интерфейсе Cloud Builder в мастере установки вы отмечаете «License Now: No» и оставляете поля пустыми. Мы воспользуемся этой возможностью, чтобы не привязывать сразу лицензии (получим 60-дневный триал).
Пример сетевой схемы и адресации. Для ясности спланируйте небольшую сетевую схему. Например:
Management Network: VLAN 70, подсеть 192.168.70.0/24. В ней будут IP всех ESXi (192.168.70.11–14), Cloud Builder (.10), vCenter (.20), SDDC Manager (.21), NSX Manager (.22), и Jump-host VM (.100, об этом позже).
vMotion Network: VLAN 71, подсеть 192.168.71.0/24, IP для vmk vMotion на каждом ESXi (.11–.14).
vSAN Network: VLAN 72, подсеть 192.168.72.0/24, IP для vmk vSAN на каждом ESXi.
NSX-T Host Overlay (TEP): VLAN 74, подсеть 192.168.74.0/24, IP для TEP на каждом ESXi (Cloud Builder сам назначит/настроит, нужно только указать диапазон). Для экономии можно задать один TEP на хост.
NSX Edge Uplink (если у вас будет Edge): VLAN 75 (или используйте вашу внешнюю сеть без VLAN, если Edge будете подключать к домашнему роутеру).
DNS/NTP: например, DNS = 192.168.70.1 (если у вас уже есть на .1 DNS или ваш домашний роутер), либо адрес вашего локального DNS-сервера.
Если не используете отдельные VLAN, можно указать одинаковую VLAN (или 0, если без тегов) для Management, а vMotion/vSAN задать как разные IP-сети но без VLAN тегов – однако Cloud Builder может потребовать VLAN ID для разных сетей, поэтому лучше настроить как полагается.
Запуск развертывания (Bring-Up). После заполнения Workbook загрузите файл в Cloud Builder. Он проверит параметры (Validation). Если где-то ошибка (особенно DNS!) – исправьте. На этом этапе, если вы собираетесь развернуть менее 4 узлов (например, 1 узел), выполните хак: зайдите по SSH на сам Cloud Builder VM и выполните:
Это снизит требование к минимальному числу узлов management domain до 1 (подробнее тут). После этого верификация с одним узлом должна проходить без проблем.
Далее в веб-интерфейсе Cloud Builder нажмите "Bring-up" для запуска автоматического развертывания VCF. Процесс займёт от 2 до 4 часов (в зависимости от производительности вашего хоста). Cloud Builder в автоматическом режиме сделает следующее:
Установит на указанные 4 ESXi необходимую конфигурацию (включая объединение их в кластер vSphere и включение vSAN на них). vSAN используется как основное хранилище для management domain, поэтому Cloud Builder сконфигурирует диск-группы на каждом узле (беря по одному диску как кэш и одному как capacity – те самые виртуальные диски, что мы добавили). Если вы развернули один узел, он поднимет однозвеный кластер vSAN (без реплик).
Развернет виртуальную машину vCenter Server Appliance (VCSA) для Management Domain на одном из этих хостов. VCSA будет развёрнута с форматом размера Tiny (в лабораторном JSON так и указывается), чтобы минимизировать потребление ресурсов.
Развернет и настроит NSX-T Manager. Обычно для отказоустойчивости разворачивается кластер из 3 NSX Manager Appliance, но в JSON можно указать режим Compact = true, тогда будет один NSX Manager (для экономии ресурсов). Cloud Builder свяжет NSX с vCenter, зарегистрирует соответствующие VIB модули на хостах (NSX-T Data Plane). Все узлы ESXi станут подготовленными transport-node в NSX-T fabric, с поднятыми TEP интерфейсами на VLAN Overlay.
Развернет SDDC Manager – центральную управляющую машину Cloud Foundation. SDDC Manager – это отдельный виртуальный модуль (virtual appliance), который берет на себя координацию всех компонентов (мониторинг, добавление новых доменов, обновление и пр.). Он тоже будет размещен на одном из ESXi management cluster.
(Опционально) Развернет дополнительные компоненты, если они отмечены: например, платформу логирования vRealize Log Insight (vRLI) для Management Domain, или контроллеры нагрузки (NSX ALB) и другие, в зависимости от версии VCF. В старых версиях (VCF 3.x) автоматически ставился vRealize Suite (логирование, мониторинг), в новых это опционально. В нашем случае, если цель – минимальный работающий VCF, можно не развертывать ничего лишнего.
Cloud Builder автоматизирует взаимодействие между компонентами – он использует API vCenter, NSX и прочих, чтобы связать их воедино. Например, регистрирует NSX Manager под управлением SDDC Manager, создаёт в SDDC Manager запись о новом Management Domain и т.д. По завершении процесса у вас будет полностью функционирующий Management Domain VCF. Это означает:
Кластер из 4 ESXi с включенным vSAN (именно на нем будет храниться теперь все – и ВМ самого vCenter, NSX, SDDC Manager).
vCenter Server, управляющий этим кластером (Single Sign-On домен можно указать свой, например vsphere.local).
NSX-T – запущен менеджер, все 4 хоста добавлены в NSX Fabric и объединены виртуальной распределенной сетью (NSX создаст внутренний vSwitch – N-VDS или использует vSphere Distributed Switch – в новых версиях NSX-T интегрируется с VDS).
SDDC Manager – веб-интерфейс будет доступен по своему адресу и готов принимать дальнейшие команды (например, развертывание дополнительных Workload Domain, управление жизненным циклом и т.д.).
Шаг 5: Проверка и дальнейшая настройка
После успешного bring-up зайдите в интерфейсы компонентов:
SDDC Manager – основной интерфейс управления VCF. Зайдите по HTTPS на адрес SDDC Manager (указанный в конфигурации, порт 443) под учетной записью admin/пароль (который вы задали). Вы увидите панель управления, где отображается состояние системы, ресурсы и домены. Например, там будет один Management Domain с перечислением ресурсов (хосты, кластер, использованные CPU/RAM) и возможность добавить Workload Domain. Ниже мы рассмотрим интерфейс подробнее.
vCenter Server – подключитесь через vSphere Web Client. Убедитесь, что внутри vCenter виден кластер Management с 4 хостами, включен vSAN (один общий datastore). Проверьте, что статус кластерных служб (vSphere HA, DRS) и vSAN зеленый. В нашем лабораторном случае кластер может быть помечен как не удовлетворяющий требование (например, DRS в режиме Partial, если ресурсов мало), но главное – работоспособность.
NSX-T Manager – откройте веб-интерфейс NSX. Войдите под администратором. Убедитесь, что все 4 ESXi отображаются как Transport Nodes, что создан Overlay Segment (например, для сети Tier-0 или просто Host TEPs). По сути, NSX в Management Domain нужен для будущих сетей нагрузок и для вспомогательных сетей (например, Application Virtual Networks для компонентов vRealize). На данном этапе в NSX-T можно ничего не менять – VCF настроил все по умолчанию.
Network connectivity – проверьте, что все новые ВМ (vCenter, SDDC, NSX) доступны по сети, пингуются по IP и именам. Особенно важно, чтобы SDDC Manager мог по DNS обращаться к vCenter и NSX, и наоборот, иначе возникнут предупреждения.
Теперь вы имеете рабочую основу VCF - Management Domain развернут. Если бы у вас было больше хостов, на этом этапе вы могли бы через SDDC Manager создавать Workload Domain – то есть дополнительные кластера ESXi для конкретных задач (подразумевается, что для них нужны отдельные физические сервера). В нашем случае, на одном физическом ресурсе, добавить домен нагрузок не получится (нет свободных узлов). Поэтому мы будем использовать единственный management cluster и для тестовых нагрузок тоже (это называется Consolidated Architecture, когда управляемые рабочие нагрузки запускаются вместе с управляющими ВМ на одном кластере). SDDC Manager распознает этот сценарий и пометит домен как Management/VI (объединенный).
Добавление виртуальных машин с рабочими нагрузками. Вы можете развернуть внутри получившейся инфраструктуры любые тестовые ВМ (например, доп. контроллер домена AD, jump-host для доступа, тестовые серверы). Делать это можно через знакомый интерфейс vCenter – т.е. VCF не ограничивает возможности vSphere. Имейте в виду, что все новые ВМ должны храниться на vSAN (поскольку в management cluster нет альтернативных хранилищ). Также убедитесь, что они подключены к нужным сетям. Например, если вы хотите, чтобы тестовая ВМ была доступна из домашней сети, самый простой путь – подключить ее к той же портгруппе management, которая проброшена на физический NIC (в таком случае она получит IP из вашей домашней сети или VLAN). Более изолированный способ – настроить в NSX сегмент и Edge, но это выходит за рамки базового развёртывания.
Мы успешно установили все основные компоненты VCF. Далее разберём, как устроена архитектура этой лаборатории и как взаимодействуют компоненты.
3. Архитектура и взаимосвязь компонентов VCF
Обзор компонентов VCF. VMware Cloud Foundation представляет собой полный стек программно-определяемого центра обработки данных (SDDC), интегрирующий гипервизор, виртуализацию хранения и сети, а также средства автоматизации управления. В состав VCF входят основные продукты VMware: vSphere (ESXi + vCenter для вычислительной виртуализации), vSAN (программно-определяемое хранилище на локальных дисках), NSX-T (виртуализация сети, включая распределенный коммутатор, маршрутизацию, фаерволы и т.д.) и SDDC Manager (управляющий оркестратор). Также могут быть включены инструменты из семейства vRealize/Aria (Log Insight для логов, Operations для мониторинга, Automation для автоматизации развертываний), но они вторичны. Проще говоря, VCF предоставляет всё необходимое, чтобы развернуть частное облако на базе инфраструктуры vSphere.
Основной логической единицей в архитектуре Cloud Foundation является домен (Workload Domain). Домен – это изолированная группа ресурсов, обычно соответствующая кластеру (или нескольким кластерам) vSphere, со своим набором вычислительных, сетевых и storage-ресурсов. VCF разделяет домен управления (Management Domain) и домены рабочей нагрузки (VI Workload Domains).
Management Domain – специальный домен, который развертывается первым и содержит инфраструктурные сервисы: SDDC Manager, vCenter Server для управления инфраструктурой, NSX Manager для управления сетями, и т.д. Этот домен служит "сердцем" всей системы – в нем работают компоненты управления для всех остальных доменов. Management Domain развертывается на базе четырех узлов ESXi (минимум), объединенных в кластер с vSAN и NSX. Почему 4? Это позволяет обеспечить отказоустойчивость для vSAN (минимум 3 узла + 1 свидетель для кворума) и зарезервировать ресурсы под сервисы. Все vCenter и NSX Manager, которые нужны для других доменов, также размещаются в Management Domain. В контексте нашего лаба Management Domain – это как раз тот кластер из 4 nested-ESXi, который мы развернули. Мы использовали vSAN внутри него, как того требует архитектура (в Management Domain принципиально только vSAN может быть основным хранилищем).
VI Workload Domain – домен для пользовательских рабочих нагрузок (виртуальных машин приложений, VDI, контейнеров и т.п.). Обычно каждый такой домен – это отдельный кластер ESXi с собственным vCenter Server и NSX (либо NSX может быть общим между доменами по решению дизайна). Например, можно создать домен «База данных» из 3 узлов для СУБД, домен «VDI» из 4 узлов для виртуальных рабочих столов и т.д. VCF позволяет изолировать их друг от друга на уровне управления и ресурсов. Однако в маленькой среде все роли могут быть объединены.
Consolidated Architecture. В минимальных лабораторных сценариях допускается, что Management Domain выполняет также роль Workload Domain, т.е. на том же кластере запускаются и управляемые нагрузки. Это называется объединенной (consolidated) архитектурой. Она характерна для POC и небольших развёртываний – в этом случае в системе будет всего один vCenter (управляющий всеми узлами) и один NSX менеджер, а SDDC Manager все равно видит один Management Domain. Наша однохостовая лаборатория как раз относится к consolidated-сценарию: мы будем запускать тестовые ВМ на management-кластере, т.к. других кластеров у нас нет.
SDDC Manager. Он выступает надстройкой, координирующей несколько vCenter (каждый обслуживает свой домен/кластер), а те в свою очередь управляют ресурсами ESXi-кластеров. В стандартной (разделенной) архитектуре минимум два домена – Management и один Workload – имеют отдельные vCenter, изолируя нагрузки от управления. В нашем случае (consolidated) фактически один vCenter и один домен совмещают обе функции, но концептуально роли остаются теми же.
Через SDDC Manager администратор выполняет развертывание новых доменов, мониторинг состояния оборудования, а также жизненный цикл (обновления, патчи) всех продуктов VMware в составе VCF. SDDC Manager отслеживает как физические ресурсы (серверы, сеть, хранилище), так и логические (кластеры, пуулы ресурсов). В нашем случае SDDC Manager развернут как ВМ на management-кластере и зарегистрирован с vCenter и NSX. Он "знает" обо всех четырех узлах, объединенных в один домен.
В SDDC Manager мы можем выполнять дальнейшие шаги: например, при наличии дополнительных хостов – commission (добавить в инвентарь) и затем создать новый Workload Domain через мастер. Также SDDC Manager используется для запусков обновлений – он может поочередно обновить ESXi, vCenter, NSX на всех узлах, согласованно, что упрощает жизнь администратора. Можно сказать, SDDC Manager – мозг VCF, объединяющий разные компоненты в единое целое.
vCenter Server. Каждый домен (management или workload) управляется своим экземпляром vCenter Server. В нашей лабе развернут один vCenter (для management domain). Он выполняет стандартные функции: управление ресурсами ESXi, создание/настройка кластеров, распределение ВМ, миграции, мониторинг и т.д. Интересно отметить, что одной лицензии vCenter хватает на все экземпляры vCenter в рамках Cloud Foundation – т.е. VCF поставляется с правом на несколько vCenter, но для нас это не столь важно. Через vCenter мы можем управлять настройками vSphere, которые Cloud Builder сделал автоматически – например, проверить Distributed Switch, через который соединены хосты. В VCF 4.x+ NSX-T может интегрироваться с vCenter (VDS 7.0), так что логический коммутатор NSX может быть представлен как портгруппа в vCenter.
NSX-T и сеть. VMware NSX-T Data Center – компонент VCF, отвечающий за виртуализацию сети и безопасность. NSX предоставляет распределенный виртуальный коммутатор (аналоги стандартных vSwitch, но единый на все хосты) и позволяет создавать оверлейные сети (overlay), независимые от физической топологии. В Cloud Foundation NSX-T Manager размещается в Management Domain и управляет сетью для всех доменов (по умолчанию). То есть, если вы создадите новый Workload Domain, вы можете либо подключить его к уже существующему кластеру NSX (тому, что развернут), либо развернуть отдельный NSX Manager cluster для нового домена – на усмотрение (VCF позволяет шарить NSX между доменами или разделять). В нашем случае нет дополнительных доменов, NSX Manager один. Он уже подготовил transport-узлы (ESXi) и создал необходимые логические сегменты.
Для чего используется NSX в Management Domain? Прежде всего, для предоставления сети для возможных компонентов Aria Suite (Aria Automation, Orchestrator и др.), которые VMware называет Application Virtual Networks (AVN) – они рекомендуют их размещать на изолированных сегментах NSX поверх BGP.
Если такие компоненты не используются, NSX пока что не задействован активно. Однако мы можем использовать NSX и для наших собственных ВМ: например, создать логический сегмент (Layer2) и подключать к нему тестовые ВМ – тогда эти ВМ смогут взаимодействовать в изолированной сети, которая существует только внутри NSX. Можно даже поднять Tier-1 и Tier-0 маршрутизаторы NSX, чтобы организовать выход этих сегментов наружу (через Edge).
Отметим основные моменты сетевой архитектуры в нашей лабе Cloud Foundation:
У каждого ESXi в management domain есть как минимум два виртуальных сетевых интерфейса (VMkernel): один Management (управление, он же используется для трафика vCenter, NSX control-plane) и один для vSAN. Также часто выделяют интерфейс для vMotion, но Cloud Builder мог объединить vSAN и vMotion на одну подсеть или разделить – зависит от настроек. Предположим, у нас Management на VLAN 70, vMotion на VLAN 71, vSAN на VLAN 72. Это традиционное разделение для обеспечения производительности.
Distributed Switch (vDS). Cloud Builder, скорее всего, создал распределенный коммутатор для management domain, на котором висят все 4 хоста. На нем настроены группы портов под Management, vMotion, vSAN с соответствующими VLAN. Например, VDS-MGMT с портгруппой Management (VLAN 70), vMotion (71), vSAN (72). В упомянутой консоли SDDC Manager можно видеть эти сети на уровне домена.
NSX-T Overlay. Cloud Foundation настроит NSX-T, создав Transport Zone и подключив хосты к ней. Каждый ESXi получил на своем VDS (или N-VDS) по Tunnel Endpoint (TEP) – это VMkernel-интерфейс, через который он будет обмениваться туннельным трафиком Geneve с другими узлами NSX. Эти TEP находятся в отдельной VLAN (скажем, VLAN 74) и подсети (в примере 192.168.74.0/24). Если хостов несколько, между ними уже сейчас установлена mesh-сеть туннелей (но так как на всех хостах пока нет пользовательских сегментов, туннели простаивают). Если хост один – туннели никуда не идут, но NSX всё равно требует настроить TEP.
Tier-0 / Edges. Cloud Builder также мог развернуть шаблонные Edge (NSX Edge) ВМ, если вы указали это в настройках (к примеру, для организации маршрутизации и подключения к внешней сети). В лаборатории на одном хосте Edge может работать, но помните, что Edge – это обычная ВМ, которую лучше располагать не на тех же узлах, которые она обслуживает (в продакшене на отдельном Edge Cluster). В нашем случае, если требуется доступ логических сетей NSX наружу, можно развернуть одну Edge VM на этом же кластерe. Она подключается одним интерфейсом к overlay (через TEP, как хост) и другим – к внешней сети (например, VLAN 70 или другой, которая имеет выход в интернет). Настройка Edge и Tier-0 маршрутизатора выходит за рамки данной статьи, упомянем лишь, что BGP часто используется для динамического обмена маршрутами между Tier-0 и физическим роутером. Если BGP для вас сложен, можно настроить статический маршрут или просто NAT на Edge.
Аппаратный уровень и внешний доступ. В реальной инфраструктуре VCF предполагает, что у вас есть как минимум два физических коммутатора (для отказоустойчивости) и маршрутизатор верхнего уровня, который будет граничить с NSX (через BGP). В домашней лаборатории роль маршрутизатора обычно играет ваш домашний роутер или L3-коммутатор, а иногда вообще не требуется сложной топологии. Тем не менее, продумайте, как вы будете получать доступ к компонентам (vCenter, SDDC Manager, NSX) из своей обычной среды (например, с ноутбука).
Если вы разместили Management-сеть (все адреса .70.x) внутри изолированной VLAN, которую домашний роутер не знает, то наиболее простой способ – использовать Jump Host.
Jump Host – это виртуальная машина (Windows или Linux) с двумя сетевыми интерфейсами: один подключен к Management сети VCF, второй – к вашей домашней сети. На Jump Host вы можете установить VPN, RDP или просто браузер и необходимые клиентские приложения (vSphere Client) и таким образом, находясь дома, заходить на Jump Host, а с него – в изолированную лабораторию. Ниже на схеме показано, как Jump Host (Windows 10) подключается одновременно к VCF LAN (например, 10.0.0.0/24) и локальной сети (192.168.0.0/24):
Если же вы сделали Management сеть той же, что и ваша локальная (например, все в 192.168.0.x), тогда компоненты доступны напрямую, но возникает риск пересечения IP и имён. Более чисто – выделить отдельные подсети и VLAN и использовать либо маршрутизацию, либо Jump Host. В любом случае, для простоты первоначальной настройки можно на том же физическом хосте (или на кластере vSAN) быстро поднять одну ВМ Windows, подключить ее к двум сетям и тем самым решить вопрос доступа.
Управление ресурсами. Поскольку у нас одна физическая машина, все компоненты делят ее CPU, память и диск. vSphere (vCenter) распределяет эти ресурсы по стандартным алгоритмам: DRS (если включен) балансирует загрузку между хостами, HA обеспечивает перезапуск ВМ при сбоях. Но в лаборатории с одним хостом отказоустойчивости нет – если хост упадет, все выключится. Поэтому при обновлениях/перезагрузках планируйте вручную простои. Полезно настроить в кластерe пулы ресурсов (Resource Pool) – например, выделить пул «Management VMs» и задать для него повышенный shares (приоритет) по CPU и памяти. Поместив SDDC Manager, vCenter, NSX в этот пул, вы защитите их от потенциального «выдавливания» ресурсами тестовых ВМ. Также можно вручную ограничивать потребление ресурсов тестовых ВМ (через лимиты CPU/RAM), чтобы даже в нагрузке они не отъели слишком много у инфраструктуры.
Архитектура Cloud Foundation призвана обеспечить унифицированное управление: все компоненты интегрированы. Пример: когда через SDDC Manager вы запускаете процедуру апгрейда, он по API опрашивает vCenter о версии ESXi, затем подгружает ISO, ставит каждый хост в Maintenance Mode по очереди, обновляет ESXi, перезагружает, проверяет vSAN, затем обновляет vCenter Appliance, NSX Manager – и так по списку, пока весь стек не перейдет к новой версии. Такие сквозные операции – одно из преимуществ VCF перед разнородной самосборной средой.
Развернув лабораторию VCF, вы фактически получили уменьшенную копию частного enterprise-облака. Далее мы рассмотрим рекомендации по эксплуатации этой среды в условиях ограниченных ресурсов.
4. Лучшие практики для лабораторной среды VCF
Разворачивая Cloud Foundation на домашнем железе, мы сильно выходим за рамки «обычного» использования (где десятки серверов и мощные СХД). Поэтому важно применять оптимизации и соблюдать лучшие практики, чтобы система работала приемлемо и ее было удобно администрировать.
Оптимизация использования ресурсов:
Минимальные конфигурации компонентов. Разворачивая VCF, мы уже заложили уменьшенные шаблоны для всех возможных ВМ. Убедитесь, что в JSON-файле/Workbook вы выбрали самые маленькие размеры для vCenter (Tiny), NSX Manager (Medium или Compact – NSX-T 3.x поддерживает режим Compact = 1 manager/1 controller), SDDC Manager (он, к счастью, не требует много – обычно 4 CPU/16 GB). Не устанавливайте опциональные пакеты, которые вам не нужны (vRealize Suite Lifecycle Manager, vRA etc.) – их всегда можно добавить потом. Такой подход позволил вложить Cloud Foundation в 128 ГБ ОЗУ. Если вы видите, что какая-то ВМ использует не весь выделенный ресурс (например, vCenter Tiny из 12 ГБ RAM фактически потребляет 6 ГБ), вы можете тонко настроить ресурсы – в лаборатории допускается, например, уменьшить vCenter RAM до 8 ГБ (хотя это ниже минимальных требований) или NSX Manager до 12 ГБ. Конечно, это не поддерживается официально, но может сэкономить память. Делайте это осторожно и по одной ВМ, отслеживая стабильность.
Дедупликация и shared memory. ESXi-гипервизор умеет использовать TPS (Transparent Page Sharing) – объединять идентичные страницы памяти между ВМ. В нашем случае у нас сразу несколько однотипных ОС: четыре хоста ESXi – их hypervisor-код в памяти идентичен, следовательно, ESXi на L1 сможет дедуплицировать часть этих данных. Аналогично, три NSX Manager (если вы развернули кластер) будут иметь много общих страниц (это PhotonOS Linux + Java). Этот механизм может сэкономить несколько гигабайт RAM автоматически. Главное, не отключайте TPS. Помните, что начиная с vSphere 6.0, TPS между разными ВМ по умолчанию ограничен (из соображений безопасности), но в лаборатории можно включить меж-ВМ шаринг (Parameter Mem.ShareForceSalting на ESXi = 0). Это небезопасно для multi-tenant среды, но дома – вполне подойдет.
Обмен виртуальной памятью и баллунинг. При нехватке ОЗУ ESXi использует balloon driver и свопинг. В nested-окружении balloon вряд ли сработает (так как VMware Tools не работают в ESXi-ВМ), а вот своп – будет. Поэтому, если у вас, например, 96 ГБ, а все ВМ в сумме хотят 110 ГБ, ESXi будет 14 ГБ свопить на диск. Это сильно замедлит эти ВМ. Рекомендуется избегать постоянного свопа: лучше вручную снизить их память или выключить некоторые. Не задавайте резервирования (Memory Reservation) на ВМ в таком случае, т.к. это только усугубит (ESXi придется гарантировать память, вытесняя другие ВМ полностью на своп). Пусть гипервизор динамически все балансирует. Если заметили, что swaping активен – попробуйте отключить один NSX Manager (при в кластере их три, один можно временно выключить) или уменьшить размер его памяти.
Ограничение фоновых процессов. В лабораторном vCenter стоит отключить лишние сервисы, например, vSAN Performance Service (если вам не нужно детальное отслеживание метрик vSAN), CEIP/telemetry, vSAN CLOMD elasticity. Каждая такая служба чуть грузит систему – можно их выключить через UI/API. Для NSX-T желательно не включать функции типа IDPS, URL filter и т.п., которые просто съедят CPU.
Тонкое выделение дисков и экономия места. Мы уже использовали thin-диски для nested ESXi. Аналогично, все ВМ (vCenter, NSX, SDDC) по умолчанию развернуты тонко. Следите за заполненностью vSAN datastore – не переполняйте его. vSAN обычно начинает ругаться при заполнении >80%. Контролируйте, чтобы лишние ISO и снапшоты ВМ не заполняли хранилище. Если нужно, подключите дополнительное хранилище: например, NFS NAS. Вы можете подключить NAS напрямую к ESXi L1 (например, Synology NAS) и хранить на нем образы ISO или даже второстепенные ВМ (не участвующие в VCF). Это снимает часть нагрузки с vSAN.
PowerCLI автоматизация для приостановки/запуска. Если ресурс совсем на пределе, вы можете разработать скрипт, который, скажем, останавливает NSX Manager cluster (2 из 3 узлов) в то время, когда вы не тестируете сети, и запускает их, когда нужно. Или, например, у вас VDI Workload Domain – вы держите его выключенным, пока не нужен. Написав парочку PowerCLI/PowerShell скриптов и задач по расписанию, можно динамически "отдыхать" ресурсы. Главное – не выключайте одновременно все NSX Managers или vCenter, иначе SDDC Manager будет в панике. Но один NSX manager из трех можно.
Администрирование и управление тестовой средой:
DNS и сертификаты. Удостоверьтесь, что нет DNS-проблем – в VCF очень много интеграций по именам. Если вы вдруг меняете IP/имя чего-то, поправьте DNS/hosts везде. Для простоты можно добавить в файл hosts на вашей рабочей машине записи для основных узлов (vcenter.lab.local, sddc.lab.local и т.д.), чтобы быстро к ним обращаться. С точки зрения сертификатов, в лаборатории можно оставить самоподписанные (они сгенерировались при установке). Если хотите поэкспериментировать, можно поднять внутренний CA (например, Microsoft AD CS) и заменить сертификаты через VMware Certificate Manager или API, но это необязательно и достаточно сложно.
Мониторинг. Включите в vCenter алармы на исчерпание ресурсов (CPU, память, место) – они помогут отреагировать, если что-то вдруг начало неконтролируемо расти (например, лог-файлы). Полезно развернуть vRealize Log Insight (он же теперь Aria Operations for Logs) – он к VCF обычно прилагается. В лаборатории можно поставить его в Tiny-размере на тот же кластер. Он соберет логи со всех ESXi, vCenter, NSX и SDDC Manager, предоставив единый журнал. Это облегчит отладку, если будут ошибки. Но Log Insight потребует ~8 ГБ RAM и ~100 ГБ места, имейте в виду.
Резервное копирование. Даже лабораторную среду бывает жалко потерять, особенно после долгой настройки. Для основных виртуалок настройте процедуры бэкапа:
vCenter Server: используйте встроенный механизм File-Based Backup (через VAMI интерфейс vCenter) – он может по расписанию выгружать конфигурацию vCenter на SFTP/FTP. Настройте его и сохраняйте бэкап хотя бы раз в неделю.
NSX-T Manager: у NSX также есть функция резервной копии (в Web UI, раздел System > Backup). Настройте target (тот же SFTP) и сохраняйте бэкап NSX. В случае чего, NSX Manager можно восстановить из этого бэкапа на новую развернутую ВМ.
SDDC Manager: можно либо вручную снять снапшот SDDC Manager VM (когда она выключена) или сделать ее клонирование, либо использовать процедуру, описанную здесь. Но поскольку SDDC Manager хранит не так много важных данных (в основном инвентарь и state), если вы потеряете его, можно в крайнем случае развернуть его заново.
Хосты ESXi: особого бэкапа не надо – их конфигурация небольшая, и хранится также в SDDC/vCenter (inventory). Можно сохранять бэкап профиля хоста (host profile).
Виртуальные машины инфраструктуры: в небольшой лабе можно делать периодически снапшоты VM vCenter, NSX, SDDC (например, перед экспериментами с обновлением). Важно: не держите снепшоты длительно (vSAN не любит старые снимки, к тому же будет расход места), удаляйте или откатывайтесь в течение нескольких дней максимум.
Обновления. VMware активно выпускает обновления безопасности и патчи. В 60-дневной изолированной лабе можно особенно не стремиться обновляться, если всё работает. Но, например, может выйти патч ESXi или NSX с исправлением, интересным вам. Через SDDC Manager удобно использовать Lifecycle Manager (LCM): он может показать доступные обновления для VCF (если есть интернет, или вы можете вручную загрузить пакеты). Поскольку у нас весьма нестандартное окружение, сначала изучите Release Notes – поддерживается ли обновление в consolidated-режиме (обычно да). Можно провести обновление всего стека (SDDC Manager сделает это автоматически, перезагружая компоненты по очереди). Рекомендуется не обновлять вручную компоненты отдельно, иначе SDDC Manager потеряет синхронизацию версий. Всегда используйте именно встроенный LCM в SDDC Manager.
Практика восстановления. Хорошей идеей будет попробовать имитацию отказа и восстановление. Например, что если у вас упадет NSX Manager (в лабе с одним NSX – это проблема, так что можно протестировать, подняв новую NSX Manager VM и подключив к кластеры). Что если vCenter сломался? – тогда выручит File-Based Backup восстановление. Лаба – место, где не страшно потрогать любую "красную кнопку".
Документируйте и автоматизируйте. Ведите журнал изменений: запишите IP и пароли всех компонентов, VLAN ID, учетные записи. В Enterprise для этого используют VMware Cloud Foundation Planner/Tracker, а вы можете просто текстовый файл или таблицу. Также, если вы будете уничтожать и развёртывать лабу заново, автоматизация с помощью VCF Lab Constructor (VLC) или API-скриптов может сильно сэкономить время в будущем. Сохранив ваш JSON-файл конфигурации Cloud Builder, вы потом легко развернёте среду заново при необходимости.
Советы по обновлению и расширению:
В период триального окна (60 дней) постарайтесь изучить как можно больше возможностей. Попробуйте добавить еще один (nested) хост в management cluster через интерфейс SDDC Manager – увидите, как добавляется узел (для этого сначала сделайте “commission host” в SDDC Manager, затем “expand cluster”). Можете протестировать функцию Workload Domain creation: например, освободите 3 nested-ESXi из management cluster (оставив 1 для mgmt, что VCF не позволит штатно, но в лабе можно это обойти), и попробуйте создать VI Domain из них – так вы увидите процесс развертывания второго vCenter и NSX.
Если в ходе экспериментов что-то пошло не так (например, не поднялся Cloud Builder или NSX с первого раза) – не отчаивайтесь и не бойтесь снести неудачную конфигурацию полностью. Лаборатория ценна тем, что ее можно собрать заново. Иногда быстрее начать с нуля, чем чинить частично сконфигурированный VCF, тем более что продукт очень комплексный и вручную править конфигурацию трудно. Поэтому на всякий случай сохраняйте копии рабочих конфигов (JSON), чтобы при необходимости быстро повторить деплой.
Расширение физического хоста: если у вас появятся дополнительные ресурсы (например, второй такой же сервер), вы можете попробовать распределить лабу: например, 4 узла ESXi на одном физическом, 3 на другом, соединив 10G линком – это приближает к реальности и снимает часть нагрузки. VCF поддерживает vSAN растянутые (stretched) кластеры и подобное, но в лабе проще разбросать узлы management cluster по двум машинам. SDDC Manager не заметит разницы – для него важно, что есть 4 ESXi, доступных по сети. Таким образом, поэтапно можно наращивать полигон.
Подытоживая: придерживаясь данных рекомендаций, ваша лаборатория VCF пусть и не сможет похвастаться высокой производительностью, но будет работать достаточно стабильно, чтобы дать вам возможность изучить все основные функции Cloud Foundation. Вы на практике убедитесь, как взаимодействуют vSphere, vSAN и NSX в рамках единой платформы, и как SDDC Manager облегчает их координацию.
Заключение
Мы рассмотрели процесс создания домашней лаборатории VMware Cloud Foundation на одном физическом сервере – от подбора компонентов, развертывания всех необходимых виртуальных машин, до настройки сетевого взаимодействия и лучших практик эксплуатации. Такая лаборатория, пусть и ограниченная по производительности, предоставляет уникальную возможность получить опыт работы с полнофункциональным частным облаком VMware. Вы познакомитесь с архитектурой VCF: взаимодействием vSphere, vSAN, NSX-T и SDDC Manager, а также научитесь применять техники оптимизации, чтобы уложиться в скромные ресурсы. Не забудьте воспользоваться триальным периодом максимально эффективно – изучите интерфейсы, попробуйте добавлять/удалять узлы, настраивать NSX-сегменты, проводить обновления через SDDC Manager. Этот практический опыт ценен для системного инженера, позволяя отработать навыки без риска для боевой инфраструктуры.
Лаборатория VMware Cloud Foundation – отличный полигон для экспериментов с современными технологиями программно-определяемых датацентров. Успехов в ваших исследованиях и дальнейшего погружения в мир VMware VCF!
RSS
