Основы виртуализации: Архитектура и управление VMware vSphere

Архитектура и компоненты VMware vSphere

Переход от физической инфраструктуры к виртуальной требует понимания того, как программное обеспечение взаимодействует с аппаратным обеспечением. Платформа VMware vSphere — это не просто одна программа, которую можно установить на компьютер. Это комплексный набор программных продуктов, которые работают совместно, создавая надежную, масштабируемую и отказоустойчивую среду для запуска виртуальных машин.

Чтобы успешно развертывать тестовые среды, настраивать сети и планировать миграцию физических серверов (P2V — Physical to Virtual), необходимо разобраться в фундаменте: как устроена архитектура vSphere и за что отвечает каждый её компонент.

Фундамент виртуализации: Гипервизор VMware ESXi

В основе всей платформы лежит VMware ESXi — это гипервизор первого типа (Type 1 hypervisor). Термин «первый тип» означает, что гипервизор устанавливается непосредственно на «голое железо» (bare-metal), то есть прямо на физический сервер без использования промежуточной операционной системы вроде Windows или Linux.

Главная задача ESXi — абстрагировать физические ресурсы сервера (процессор, оперативную память, дисковое пространство и сетевые адаптеры) и распределять их между виртуальными машинами (ВМ).

> Гипервизор работает как строгий, но справедливый управляющий зданием. Он берет огромное физическое здание (сервер) и делит его на изолированные офисы (виртуальные машины), следя за тем, чтобы ни один арендатор не забрал себе всё электричество или воду, оставив других ни с чем.

Поскольку ESXi не имеет тяжеловесной графической оболочки и лишних фоновых служб, он занимает минимум места на диске (всего несколько сотен мегабайт) и потребляет ничтожно мало оперативной памяти для собственной работы. Это позволяет отдать максимум ресурсов полезной нагрузке — виртуальным машинам.

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

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

Где: * — максимально допустимое суммарное количество виртуальных ядер для всех ВМ на хосте. * — количество доступных физических ядер на сервере. * — коэффициент переподписки (Ratio). Для тестовых сред он может составлять 4 или даже 6, а для высоконагруженных баз данных строго 1.

Если у вас есть физический сервер с 16 ядрами (), и вы разворачиваете тестовую среду с коэффициентом , то . Вы можете безопасно распределить 64 виртуальных ядра () между вашими тестовыми машинами.

Мозг инфраструктуры: VMware vCenter Server

Если ESXi — это мускулы, выполняющие тяжелую работу по запуску ВМ, то vCenter Server — это мозг всей инфраструктуры.

Управлять одним сервером ESXi можно напрямую через его собственный веб-интерфейс. Но когда в компании появляется два, десять или сто серверов, настраивать каждый из них по отдельности становится невозможно. vCenter Server представляет собой централизованную службу управления, которая объединяет разрозненные хосты ESXi в единый пул ресурсов.

Начиная с версии vSphere 7.0, vCenter Server поставляется исключительно в виде готового виртуального модуля — vCenter Server Appliance (vCSA), который работает на базе оптимизированной операционной системы Photon OS от VMware. Все необходимые службы, включая аутентификацию (Single Sign-On) и управление сертификатами, теперь консолидированы внутри этого модуля.

Именно vCenter Server открывает доступ к продвинутым корпоративным функциям, ради которых компании выбирают VMware:

* High Availability (HA) — обеспечение отказоустойчивости. Если один физический сервер ESXi внезапно выходит из строя (например, сгорел блок питания), vCenter Server фиксирует это и автоматически перезапускает виртуальные машины упавшего хоста на других, исправных серверах кластера. * vMotion — технология «живой» миграции. Позволяет перемещать работающую виртуальную машину с одного физического сервера на другой без прерывания её работы и потери сетевых соединений. Это незаменимо при плановом обслуживании оборудования. * Distributed Resource Scheduler (DRS) — автоматическая балансировка нагрузки. Если vCenter видит, что один ESXi перегружен, а другой простаивает, он автоматически переместит часть ВМ на свободный сервер с помощью vMotion.

!Схема архитектуры VMware vSphere

| Характеристика | Автономный хост ESXi | Кластер под управлением vCenter | |---|---|---| | Управление | Локальное (через веб-интерфейс одного сервера) | Централизованное (единая консоль для всех серверов) | | Отказоустойчивость (HA) | Нет (при поломке сервера ВМ недоступны) | Да (автоматический перезапуск ВМ на другом хосте) | | Миграция (vMotion) | Нет (требуется выключение ВМ для переноса) | Да (перемещение ВМ без прерывания работы) | | Шаблоны и клонирование | Ограничено | Полная поддержка создания шаблонов для быстрого развертывания |

Анатомия виртуальной машины

С точки зрения пользователя, виртуальная машина — это обычный компьютер с Windows или Linux. Но с точки зрения гипервизора ESXi, виртуальная машина — это просто набор файлов, лежащих в определенной папке на хранилище.

Понимание файловой структуры критически важно для настройки резервного копирования и миграции (P2V). Когда специальная программа конвертирует ваш старый физический сервер в виртуальный, она по сути считывает данные с физического жесткого диска и упаковывает их в эти специфические файлы.

Ключевые компоненты виртуальной машины:

Важнейшим программным компонентом любой ВМ является набор утилит VMware Tools. Это пакет специализированных драйверов и служб, который устанавливается внутрь гостевой операционной системы (Windows или Linux).

Без VMware Tools виртуальная машина будет работать, но крайне неэффективно: графика будет тормозить, сетевой адаптер не сможет выдать максимальную скорость, а vCenter не сможет корректно выключить машину (придется «выдергивать виртуальный шнур питания»). Установка VMware Tools — это обязательный шаг после развертывания любой новой ВМ.

Сети и хранилища: связующие звенья

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

Datastore (Хранилище данных) — это логический контейнер, который скрывает от гипервизора специфику физического оборудования. Физически это может быть локальный жесткий диск внутри сервера, внешний дисковый массив (SAN), подключенный по оптике, или сетевое хранилище (NAS). Для ESXi всё это выглядит как стандартизированный Datastore, куда он складывает файлы .vmx и .vmdk.

Для работы таких функций, как High Availability (HA) и vMotion, критически важно использовать общее хранилище (Shared Datastore). Если файлы ВМ лежат на локальном диске первого сервера, второй сервер при поломке первого просто не сможет до них добраться, чтобы перезапустить машину.

vSwitch (Виртуальный коммутатор) — это программный сетевой свитч, работающий внутри гипервизора ESXi.

Представьте себе обычный офисный сетевой коммутатор, к которому проводами подключены компьютеры. vSwitch делает то же самое, но в программной среде. Виртуальные машины подключаются к vSwitch своими виртуальными сетевыми картами. Сам vSwitch, в свою очередь, привязан к физической сетевой карте сервера (Uplink), через которую трафик выходит в реальную физическую сеть предприятия.

Понимание того, как ESXi распределяет ресурсы, как vCenter управляет кластером, и из каких файлов состоит виртуальная машина, является ключом к успешному администрированию VMware vSphere. Эта архитектурная база позволит в дальнейшем осознанно подходить к созданию отказоустойчивых кластеров, настройке сложных сетевых топологий и планированию стратегий резервного копирования.

Развертывание и управление виртуальными машинами

В предыдущем материале мы разобрали фундамент платформы VMware vSphere: узнали, как гипервизор ESXi делит физические ресурсы, зачем нужен vCenter Server и из каких файлов состоит виртуальная машина. Теперь пришло время перейти от архитектурной теории к практике.

Управление виртуальной инфраструктурой — это не просто умение нажимать кнопки в интерфейсе. Это понимание логики того, как машины создаются, как они взаимодействуют с сетями и хранилищами, и как обеспечить их бесперебойную работу.

Жизненный цикл виртуальной машины: от ручной установки к шаблонам

Процесс создания новой виртуальной машины (ВМ) во многом напоминает сборку физического компьютера, только происходит это программно. Администратор через консоль vCenter Server задает параметры будущего «компьютера»: выделяет количество виртуальных процессоров (vCPU), объем оперативной памяти, создает виртуальный жесткий диск (файл .vmdk) и размещает его на выбранном хранилище — Datastore.

Обязательным шагом является подключение ВМ к сети. Для этого виртуальный сетевой адаптер машины подключается к нужной группе портов на виртуальном коммутаторе — vSwitch. Только после этого машина сможет получить IP-адрес и общаться с другими серверами.

Однако ручная установка операционной системы с ISO-образа — процесс долгий. Если вам нужно развернуть тестовую среду из десяти серверов, ручная работа займет весь день. Для расчета затрат времени можно использовать простую формулу:

Где: * — общее время развертывания инфраструктуры. * — количество необходимых виртуальных машин. * — время установки и базовой настройки одной ОС (обычно около 30-40 минут).

Чтобы избежать потери времени, в VMware vSphere используется механизм шаблонов (Templates).

Шаблон — это «золотой образ» виртуальной машины. Администратор один раз создает ВМ, устанавливает на нее операционную систему, накатывает все необходимые обновления, устанавливает пакет драйверов VMware Tools и корпоративный софт. Затем эта машина конвертируется в шаблон. Шаблон нельзя случайно включить или изменить — он доступен только для чтения.

Когда разработчикам нужна новая тестовая среда, администратор просто разворачивает новые ВМ из этого шаблона. Процесс занимает 2-3 минуты, так как гипервизор просто копирует готовый файл .vmdk на хранилище.

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

P2V-миграция: перенос физических серверов в виртуальную среду

Одной из самых частых задач при внедрении VMware является перенос старых физических серверов в новую виртуальную инфраструктуру. Этот процесс называется P2V-миграцией (Physical to Virtual).

Представьте старый сервер бухгалтерской базы данных. На нем установлена операционная система десятилетней давности, специфические драйверы и сложное программное обеспечение, дистрибутивы которого давно утеряны. Установить всё это с нуля на новую ВМ практически невозможно. Здесь на помощь приходят утилиты для конвертации (например, VMware vCenter Converter).

Логика работы P2V-миграции состоит из нескольких этапов:

!Схема процесса P2V-миграции

После завершения процесса старый физический сервер выключается, а в vCenter включается его точная виртуальная копия. Пользователи в сети даже не замечают подмены, так как виртуальная машина сохраняет старое имя и IP-адрес.

Снапшоты: безопасные эксперименты в тестовых средах

При работе с тестовыми средами разработчикам часто нужно проверять рискованные обновления или изменения кода. В физическом мире неудачное обновление Windows или базы данных означало бы долгий процесс восстановления из резервной копии. В vSphere для этого существует механизм снапшотов (Snapshots — снимки состояния).

Снапшот позволяет мгновенно «заморозить» текущее состояние виртуальной машины (ее диск, оперативную память и настройки).

Как это работает технически? Когда вы делаете снапшот, гипервизор ESXi блокирует основной файл диска .vmdk для записи (он становится Read-Only). Одновременно создается новый пустой файл — Delta-диск. Все новые изменения, которые происходят в гостевой ОС, теперь записываются только в этот дельта-диск.

Если эксперимент прошел неудачно, администратор нажимает кнопку «Revert to Snapshot». Гипервизор просто удаляет дельта-диск со всеми ошибками и снова подключает ВМ к исходному, чистому файлу .vmdk. Машина мгновенно возвращается в прошлое.

Критически важное правило: Снапшот — это не резервная копия!

Если основной файл .vmdk будет поврежден или удален с хранилища Datastore, дельта-диск станет абсолютно бесполезным, так как он содержит только разницу, а не полные данные. Кроме того, длительное хранение снапшотов (более 2-3 дней) сильно замедляет работу ВМ, так как гипервизору приходится постоянно вычислять, из какого файла (основного или дельты) читать данные.

Резервное копирование и отказоустойчивость (HA)

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

В традиционной физической инфраструктуре для бэкапа приходилось устанавливать программу-агент внутрь каждой операционной системы. Это нагружало сеть и процессоры серверов. В среде VMware vSphere используется безагентное резервное копирование на уровне гипервизора.

Система резервного копирования общается напрямую с vCenter Server. Процесс выглядит так:

Такой подход позволяет делать бэкапы десятков машин одновременно, вообще не затрагивая их внутренние операционные системы.

Помимо защиты данных, важно обеспечить доступность самих сервисов. За это отвечает кластерная функция High Availability (HA).

Если физический хост ESXi выходит из строя, vCenter Server (или другие хосты в кластере) фиксируют потерю связи. Функция HA автоматически берет файлы .vmx и .vmdk упавших машин с общего хранилища Datastore и регистрирует их на выживших хостах ESXi.

При настройке HA администратор может задать Restart Priority (приоритет перезапуска). Например, контроллеры домена и серверы баз данных получат высокий приоритет и будут запущены первыми, а тестовые серверы разработчиков — низкий приоритет, и запустятся только тогда, когда критическая инфраструктура уже будет работать.

Понимание этих механизмов — от развертывания из шаблонов до безагентного бэкапа — позволяет администратору превратить набор разрозненных серверов в гибкое, управляемое и отказоустойчивое частное облако.

Настройка виртуальных сетей и хранилищ

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

В архитектуре VMware vSphere за эти задачи отвечают виртуальные сети и хранилища. Понимание принципов их работы критически важно для обеспечения отказоустойчивости, изоляции тестовых сред и успешной миграции физических серверов.

Анатомия виртуальной сети: vSwitch и Uplink

В физическом мире сервер подключается кабелем к аппаратному коммутатору (свитчу), который направляет пакеты данных к другим устройствам. В среде vSphere этот процесс полностью эмулируется программно с помощью виртуального коммутатора (vSwitch).

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

Чтобы виртуальные машины могли общаться не только друг с другом внутри одного хоста, но и с внешним миром (интернетом или корпоративной сетью), виртуальному коммутатору нужен выход наружу. Этот выход называется Uplink.

Uplink — это физический сетевой адаптер (сетевая карта) самого сервера ESXi, который в терминологии VMware обозначается как vmnic (например, vmnic0, vmnic1). Виртуальный коммутатор берет трафик от виртуальных машин и отправляет его через Uplink в физическую сеть.

> Виртуальный коммутатор не требует сложной настройки маршрутизации внутри себя. Он работает на канальном уровне (L2) и просто передает кадры от виртуальных портов к физическим адаптерам.

Группы портов: логическая изоляция трафика

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

Для решения этой проблемы используются группы портов (Port Groups). Это логические шаблоны настроек внутри vSwitch, к которым подключаются виртуальные машины.

Каждой группе портов можно назначить свой VLAN ID (идентификатор виртуальной локальной сети), политики безопасности и ограничения пропускной способности.

Типичное разделение групп портов на хосте ESXi выглядит так: * Management Network: Служебная сеть для управления самим гипервизором (доступ к веб-интерфейсу, подключение к vCenter). * vMotion Network: Выделенная сеть для миграции работающих виртуальных машин между физическими серверами. * VM Network (Production): Сеть для рабочих серверов компании. * VM Network (Test): Изолированная сеть для тестовых сред разработчиков.

!Схема подключения виртуальных машин к физической сети через vSwitch

Хранилища данных: фундамент отказоустойчивости

Второй важнейший компонент инфраструктуры — это Datastore (хранилище данных). Это логический контейнер, который скрывает от администратора физические особенности жестких дисков и предоставляет единое пространство для размещения файлов виртуальных машин (конфигураций .vmx и виртуальных дисков .vmdk).

Хранилища глобально делятся на два типа: локальные и общие.

| Характеристика | Локальное хранилище (Local Storage) | Общее хранилище (Shared Storage) | | :--- | :--- | :--- | | Физическое расположение | Жесткие диски внутри самого сервера ESXi | Внешняя система хранения данных (СХД), подключенная по сети | | Доступность | Доступно только одному конкретному хосту ESXi | Доступно одновременно всем хостам ESXi в кластере | | Поддержка High Availability (HA) | Нет. Если сервер сгорит, данные ВМ будут недоступны | Да. При сбое сервера другие хосты запустят ВМ с общего хранилища | | Сценарий использования | Тестовые среды, некритичные сервисы, кэш | Промышленные базы данных, критичные корпоративные сервисы |

Для построения надежного частного облака использование общего хранилища (по протоколам iSCSI, Fibre Channel или NFS) является обязательным условием. Только когда файлы виртуальной машины лежат на независимой СХД, кластер VMware может обеспечить непрерывность бизнеса.

Файловая система VMFS: магия совместного доступа

Если вы подключите обычный внешний жесткий диск с файловой системой NTFS или FAT32 к двум компьютерам одновременно и попытаетесь записать данные, файловая система мгновенно разрушится. Традиционные файловые системы рассчитаны на то, что ими управляет только одна операционная система.

В кластере VMware десятки серверов ESXi должны одновременно читать и писать данные на один и тот же логический том СХД. Для этого VMware разработала собственную кластерную файловую систему — VMFS (Virtual Machine File System).

Главная особенность VMFS — механизм распределенных блокировок (Distributed Lock Management). Когда виртуальная машина запущена на хосте ESXi №1, гипервизор блокирует только конкретный файл .vmdk этой машины. Остальное пространство хранилища остается свободным. В это же время хост ESXi №2 может спокойно создавать, удалять или изменять другие виртуальные машины на том же самом Datastore.

Управление дисковым пространством: Thick и Thin Provisioning

При развертывании новой виртуальной машины (или при P2V-миграции старого физического сервера) администратор должен создать для нее виртуальный жесткий диск. vSphere предлагает два основных подхода к выделению места: фиксированный и динамический.

Thick Provision (толстый диск) — гипервизор сразу резервирует весь запрошенный объем на хранилище. Если вы создали диск на 100 ГБ, на Datastore мгновенно будет занято 100 ГБ, даже если внутри гостевой операционной системы файлы занимают всего 15 ГБ. Это гарантирует, что машине всегда хватит места, и обеспечивает максимальную производительность.

Thin Provision (тонкий диск) — гипервизор создает файл, который изначально занимает ровно столько места, сколько реально весят данные внутри него. По мере того как пользователь сохраняет новые файлы в виртуальной машине, файл .vmdk постепенно увеличивается в размерах, вплоть до заданного лимита.

Тонкие диски позволяют существенно экономить дорогостоящее место на СХД, особенно в тестовых средах. Однако они порождают явление переподписки (Oversubscription).

Для оценки рисков переподписки можно использовать коэффициент аллокации:

Где: * — коэффициент переподписки. * — сумма максимальных объемов всех созданных тонких дисков. * — реальная физическая емкость хранилища Datastore.

Если у вас есть Datastore объемом 500 ГБ, и вы создали на нем 10 виртуальных машин, каждой из которых выделили тонкий диск на 100 ГБ, то ГБ.

В этом случае . Коэффициент больше единицы означает, что вы пообещали виртуальным машинам в два раза больше места, чем у вас есть физически. Пока машины пустые, система работает отлично. Но если все разработчики одновременно начнут загружать большие базы данных, физическое место на Datastore закончится. Это приведет к экстренной приостановке всех виртуальных машин на этом хранилище.

Грамотное проектирование виртуальной инфраструктуры требует баланса. Для критичных баз данных используют толстые диски и выделенные группы портов с высоким приоритетом трафика. Для массовых тестовых сред применяют тонкие диски и изолированные VLAN, чтобы разработчики могли безопасно экспериментировать, не влияя на работу основного бизнеса.

Миграция физических серверов

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

Процесс переноса операционной системы, приложений и данных с аппаратного сервера в виртуальную машину называется P2V-миграцией (Physical-to-Virtual). Понимание механики этого процесса и умение управлять мобильностью виртуальных машин — ключевые навыки администратора VMware vSphere.

Анатомия P2V-миграции

Главная проблема переноса физического сервера заключается в аппаратной зависимости. Операционная система (например, Windows Server или Linux) при установке на «железо» интегрирует в свое ядро драйверы конкретных устройств: контроллеров жестких дисков (RAID), сетевых адаптеров, чипсетов материнской платы.

Если просто скопировать файлы с физического жесткого диска на виртуальный и попытаться запустить систему, она не загрузится. Операционная система попытается обратиться к физическому RAID-контроллеру, которого в виртуальной среде нет, и выдаст критическую ошибку (знаменитый «синий экран смерти» или Kernel Panic).

Чтобы решить эту проблему, используются специализированные инструменты, такие как VMware vCenter Converter Standalone. Процесс миграции с их помощью делится на несколько логических этапов.

Этап 1: Сбор данных и создание целевой ВМ

Утилита-конвертер подключается к исходному физическому серверу (через специальный агент или по протоколу SSH) и анализирует его конфигурацию: разметку дисков, объем оперативной памяти, количество процессоров.

Затем конвертер связывается с сервером управления vCenter и отдает команду гипервизору ESXi создать новую, пока еще пустую виртуальную машину с аналогичными характеристиками.

Этап 2: Клонирование данных

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

Для обеспечения целостности данных в среде Windows используется служба теневого копирования томов — VSS (Volume Shadow Copy Service). Она делает мгновенный снимок файловой системы, замораживая ее состояние на определенный момент времени. Конвертер копирует этот замороженный слепок на виртуальный диск .vmdk, расположенный на хранилище Datastore.

Этап 3: Реконфигурация (аппаратная абстракция)

Это самый важный этап, на котором происходит «магия» отвязки от железа. Конвертер вмешивается в системные файлы скопированной операционной системы:

* Удаляет драйверы физического оборудования (RAID-контроллеров, специфичных сетевых карт). Внедряет драйверы виртуальных устройств VMware (например, виртуального контроллера LSI Logic SAS или VMware Paravirtual*). * Устанавливает набор драйверов и утилит VMware Tools, необходимых для корректной работы мыши, видеоадаптера и управления питанием.

Этап 4: Финальная синхронизация

Пока шло копирование основного объема данных (что может занять часы), пользователи продолжали работать с исходным сервером и изменили часть файлов. Конвертер выполняет финальную синхронизацию: останавливает службы на физическом сервере, докопирует последние изменения, выключает физический сервер и автоматически включает готовую виртуальную машину.

> Успешная P2V-миграция требует подготовки. Перед запуском конвертера необходимо очистить физический сервер от временных файлов, удалить утилиты управления аппаратным обеспечением (например, софт для ИБП или управления RAID-массивом) и отключить антивирус, который может заблокировать процесс клонирования.

Мобильность внутри кластера: технология vMotion

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

Эта технология называется vMotion (живая миграция). Она была представлена в 2003 году и стала революцией в индустрии центров обработки данных.

!Схема работы VMware vMotion

Как работает vMotion «под капотом»

Перенос работающей виртуальной машины — сложный инженерный процесс, который происходит за миллисекунды.

Для пользователей этот процесс выглядит как кратковременная задержка отклика (обычно менее одного сетевого пинга), после чего система продолжает работать как ни в чем не бывало.

Требования для работы vMotion

Чтобы живая миграция прошла успешно, инфраструктура должна соответствовать строгим архитектурным правилам:

* Общее хранилище (Shared Storage): Файлы виртуальной машины (.vmdk, .vmx) не перемещаются по сети. Оба хоста ESXi (исходный и целевой) должны иметь одновременный доступ к одному и тому же Datastore. Передается только вычислительное состояние (содержимое RAM и регистров CPU). Выделенная сеть: Для передачи гигабайтов оперативной памяти требуется высокая пропускная способность. Создается отдельная группа портов vMotion Network* с физическими адаптерами (Uplink) не менее 1 Гбит/с (рекомендуется 10 Гбит/с и выше). Совместимость процессоров: Целевой хост должен поддерживать те же наборы процессорных инструкций (SSE, AVX и т.д.), что и исходный. Если процессоры принадлежат к разным поколениям, используется технология EVC (Enhanced vMotion Compatibility*), которая программно маскирует новые инструкции, приводя все хосты в кластере к единому базовому уровню.

Для оценки времени первоначального копирования памяти при vMotion можно использовать базовую формулу пропускной способности:

Где: * — время передачи в секундах. * — объем выделенной оперативной памяти виртуальной машины (в мегабайтах). * — реальная пропускная способность сети vMotion (в мегабайтах в секунду).

Например, если виртуальная машина имеет 16 ГБ оперативной памяти ( МБ), а сеть vMotion работает на скорости 1 Гбит/с (что на практике дает около МБ/с), то базовое копирование займет секунды. После этого начнется итеративная синхронизация измененных страниц.

Альтернативные виды миграции

Не всегда инфраструктура позволяет использовать vMotion. Если у вас нет общего хранилища или вы используете бесплатную версию гипервизора, применяются другие подходы.

Холодная миграция (Cold Migration): Виртуальная машина полностью выключается. Ее файлы копируются по сети с локального диска одного сервера на локальный диск другого. После завершения копирования машина включается на новом месте. Это самый надежный, но требующий длительного простоя способ.

Quick Migration: Технология, встроенная в системы резервного копирования (например, от компании Veeam). Она позволяет перенести ВМ между хостами без общего хранилища. Система сначала копирует файлы дисков в фоновом режиме, затем приостанавливает ВМ, докопирует изменения и запускает ее на новом месте. Простой в этом случае есть, но он измеряется минутами, а не часами, как при холодной миграции.

Storage vMotion: Родственная технология, которая решает обратную задачу. Она позволяет переместить файлы виртуальной машины (ее виртуальные диски) с одного Datastore на другой (например, со старой СХД на новую), не выключая саму виртуальную машину и не меняя хост ESXi, на котором она работает.

Понимание этих механизмов позволяет администратору гибко управлять ресурсами дата-центра: балансировать нагрузку, выводить физические серверы в ремонт без остановки бизнес-процессов и безопасно переносить устаревшие системы в современную облачную среду.

Отказоустойчивость и резервное копирование

После успешной миграции физических серверов в виртуальную среду перед администратором встает новая задача. Виртуальные машины отвязаны от конкретного «железа», но физические серверы (хосты ESXi), на которых они работают, по-прежнему подвержены поломкам. Сгорают блоки питания, выходят из строя модули оперативной памяти, обрываются сетевые кабели.

В традиционной физической инфраструктуре поломка сервера означает длительный простой: нужно заказать детали, дождаться доставки, заменить компоненты и восстановить данные. В архитектуре VMware vSphere аппаратный сбой обрабатывается совершенно иначе благодаря встроенным механизмам кластеризации и защиты данных.

Архитектура отказоустойчивости: VMware HA

Базовый уровень защиты от аппаратных сбоев обеспечивает технология High Availability (HA). Ее главная задача — минимизировать время простоя сервисов, если физический сервер внезапно выходит из строя.

Для работы HA хосты ESXi объединяются в логическую группу — кластер. Внутри кластера серверы постоянно обмениваются короткими сетевыми сообщениями, которые называются Heartbeats (сердцебиения). Один из серверов выбирается главным (Master), остальные становятся подчиненными (Slaves). Главный узел каждую секунду проверяет, «бьется ли сердце» у остальных.

Если один из хостов перестает отвечать по сети, кластер не спешит объявлять его мертвым (возможно, просто отошел сетевой кабель управления, но сам сервер и виртуальные машины на нем продолжают работать). Включается второй уровень проверки — Datastore Heartbeating. Главный узел проверяет общее хранилище данных: если пропавший сервер перестал обновлять свои файлы блокировок на хранилище, значит, он действительно вышел из строя.

Как только факт сбоя подтвержден, VMware HA инициирует процесс восстановления:

!Схема работы кластера VMware HA

> Важно понимать: VMware HA не предотвращает перезагрузку операционной системы. При сбое хоста виртуальная машина аварийно выключается (как при выдергивании шнура питания) и загружается заново на другом сервере. Простой составляет от 1 до 3 минут — ровно столько, сколько требуется гостевой ОС для загрузки.

Аналогия из жизни: Представьте таксопарк. Если у одного из водителей ломается машина прямо на маршруте, диспетчер (Master-узел) немедленно отправляет к пассажирам новую свободную машину. Пассажирам (виртуальным машинам) придется выйти из сломанного авто и сесть в новое (перезагрузка), но они гарантированно доедут до пункта назначения без необходимости самостоятельно чинить двигатель.

Непрерывная доступность: Fault Tolerance

Для 95% корпоративных систем простой в 2-3 минуты при аппаратном сбое абсолютно приемлем. Но существуют критические сервисы (биржевые торги, системы управления производством, шлюзы процессинга банковских карт), для которых даже секундная задержка оборачивается колоссальными убытками.

Для таких систем используется технология Fault Tolerance (FT) — непрерывная доступность с нулевым временем простоя.

Механика работы FT кардинально отличается от HA. При включении FT для виртуальной машины гипервизор создает ее точную теневую копию (Secondary VM) на другом физическом хосте. Обе машины работают одновременно в режиме vLockstep.

Первичная машина получает запросы от пользователей, обрабатывает их и отправляет результаты. Теневая машина получает абсолютно те же самые входные данные по выделенной высокоскоростной сети (FT Logging Network) и выполняет те же самые процессорные инструкции в ту же самую миллисекунду. Однако ее сетевой вывод блокируется гипервизором, чтобы в сети не появилось два сервера с одинаковыми IP-адресами.

Если хост с Первичной машиной сгорает, гипервизор мгновенно «снимает блокировку» с Теневой машины. Она становится Первичной и продолжает работу ровно с той же инструкции процессора. Пользователи не замечают сбоя: TCP-сессии не обрываются, пинг не теряется, перезагрузки не происходит.

За эту магию приходится платить высокую цену: * Теневая машина потребляет 100% вычислительных ресурсов на втором хосте, не принося полезной работы в штатном режиме. * Требуется колоссальная пропускная способность сети (минимум 10 Гбит/с) для синхронизации памяти и инструкций процессора. * Существуют жесткие ограничения на количество виртуальных процессоров (vCPU) для FT-машин.

Резервное копирование на уровне гипервизора

Технологии HA и FT защищают инфраструктуру от поломки «железа». Но они абсолютно бесполезны против логических ошибок: если администратор случайно удалит базу данных или вирус-шифровальщик уничтожит файлы, Fault Tolerance заботливо и без задержек синхронизирует это удаление на теневую копию.

Единственный способ защиты от потери данных — регулярное резервное копирование (Backup).

В физическом мире для бэкапа требовалось устанавливать специальную программу-агент внутрь каждой операционной системы. В среде VMware vSphere используется безагентное резервное копирование на уровне образа (Image-level backup).

Процесс выглядит так:

Этот подход позволяет копировать десятки виртуальных машин одновременно, не нагружая их процессоры и сеть агентами.

Оптимизация: Changed Block Tracking (CBT)

Полное копирование виртуального диска объемом 1 ТБ каждый день занимает слишком много времени и места на сервере бэкапов. Чтобы решить эту проблему, VMware разработала технологию Changed Block Tracking (CBT).

CBT — это функция ядра гипервизора, которая работает как журнал учета. Она отслеживает, какие именно блоки (секторы) на виртуальном диске были изменены с момента последнего резервного копирования.

Когда система бэкапа приходит на следующую ночь, она не копирует весь терабайт. Она запрашивает у CBT список измененных блоков. Гипервизор отвечает: «Изменились только блоки с 500 по 1024». Система копирует только эти несколько гигабайт. Это называется инкрементальным резервным копированием.

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

Где: * — общий объем хранилища, необходимый для бэкапов. * — размер первой полной резервной копии (обычно равен занятому месту на диске ВМ). * — количество дней хранения (глубина архива). * — средний объем данных, который меняется за один день.

Пример расчета: У вас есть файловый сервер объемом 2000 ГБ (). Ежедневно пользователи изменяют или добавляют около 50 ГБ документов (). Политика безопасности требует хранить бэкапы за последние 30 дней ().

Считаем: ГБ.

Если бы технологии CBT не существовало и нам приходилось бы каждый день делать полные копии, для хранения 30 точек восстановления потребовалось бы ГБ. Благодаря отслеживанию измененных блоков мы экономим более 94% дискового пространства.

Аварийное восстановление (Disaster Recovery)

Резервное копирование спасает от удаления файлов, а кластер HA — от поломки сервера. Но что делать, если в дата-центре произошел пожар, затопление или полное отключение электричества на несколько суток?

Для защиты от глобальных катастроф применяется подход Disaster Recovery (DR). Он подразумевает наличие второго, резервного дата-центра, расположенного в другом здании или даже другом городе.

С помощью встроенного инструмента vSphere Replication виртуальные машины асинхронно (с небольшой задержкой) копируются через интернет или выделенный канал на резервную площадку. Если основной дата-центр уничтожен, администратор использует продукт VMware Site Recovery Manager (SRM). SRM по заранее написанному сценарию автоматически включает реплики виртуальных машин в резервном дата-центре, меняет им IP-адреса и перенастраивает маршрутизацию, возвращая бизнес к жизни за считанные часы.

Грамотное комбинирование технологий High Availability, инкрементального резервного копирования и планов аварийного восстановления позволяет создать инфраструктуру, которая способна пережить практически любой сбой без критических последствий для бизнеса.