Vmware папки для хостов и кластеров

Как переместить сервер в кластер VMware vSphere. Создание виртуальной среды. Часть. 4

Описывается как переместить сервер в кластер VMware vSphere с включенным режимом EVC. Четвертая часть цикла “Создание виртуальной среды из нескольких серверов”. Дается пошаговая инструкция с пояснениями. Продолжаем создание простой виртуальной среды VMware vSphere. Мы установили и настроили гипервизор ESXi на двух серверах (“Как установить гипервизор ESXi” и “Как настроить гипервизор ESXi“) подключили один NAS к обоим (“Как подключить NAS к гипервизору ESXi“), который может быть общим для обоих хранилищем данных. Создали на обоих серверах одинаковую инфраструктуру виртуальных сетей, как это описано в “Как создать виртуальную среду VMware vSphere“.

На одном из этих серверов установили и настроили VMware vCenter Server Appliance (“Как установить vCenter сервер” и “Как настроить сетевой адаптер vCenter Appliance” и, “Как улучшить безопасность vCenter Appliance“), создали Центр обработки данных (Datacenter) (см. “Как создать центр обработки данных VMware vSphere“), добавили в него оба наших сервера (“Как добавить сервер в ЦОД VMware vSphere“) и только что создали кластер с EVC (“Как создать кластер в ЦОД VMware vSphere“). Теперь надо переместить оба наших сервера в кластер, чтобы иметь возможность миграции работающих виртуальных машин между серверами и включить технологию высокой доступности для критических приложений. Рассмотрим, как это может быть сделано.

Как переместить сервер в кластер VMware vSphere

На первый взгляд кажется, что все просто. В таблице кластеров виртуальной среды нажать на третью слева иконку “Move hosts into Cluster” (Переместить сервер в кластер), получаем всплывающее окно c аналогичным названием (Рис. 1.), ставим галочки у названий серверов, нажимаем кнопку “OK” внизу справа и все.

Рис. 1. Перемещение серверов в кластер

Только есть одна маленькая проблема. Если включен режим EVC (а мы его включили), то в кластер нельзя перенести или добавить сервера с включенными виртуальными машинами. А у нас точно есть одна виртуальная машина – VMware vCenter Server Appliance, причем она включена и мы ее в настоящий момент используем. Если все другие виртуальные машины можно на некоторое время выключить, то, если выключим vCenter, то ничего добавить или переместить в кластер не сможем.

Поэтому пойдем о обход:

переместим в кластер один сервер, на котором нет vCenter Server Appliance. Можем выключить все остальные виртуальные машины, если они есть, и просто его переместить.
выключим vCenter Server Appliance и, соединившись напрямую с гипервизором ESXi, переместим эту виртуальную машину вручную на сервер, который только что переместили в кластер. Если есть NAS, то все просто. Если нет, то придется файлы перемещать через внешний носитель.
запустим vCenter Server Appliance и переместим в кластер второй сервер, при необходимости выключив все остальные виртуальные машины.

Попробуем все это проделать.

Запускаем vSphere Web клиент (см. “Что такое vSphere Web Client“) и входим как администратор vCenter.
Определяем какой сервер будем добавлять первым – тот, на котором нет виртуальной машины vCenter Server Appliance. Выключаем все виртуальные машины, если они есть. Для этого открываем терминал каждой машины, входим как администратор этой виртуальной машины и выключаем операционную систему. Ожидаем, пока не увидим, что машина выключена и переходим к следующей.
Выбираем “vCenter” в первом ряду иконок, затем “Clusters” (Кластеры) и нажимаем третью слева иконку “Move hosts into Cluster” (Переместить сервер в кластер), в выпадающем окне (Рис. 1.) отмечаем галочкой только нужный сервер и нажимаем кнопку “OK” справа внизу.
Пытаемся запустить выключенные виртуальные машины и получаем проблему. Когда создавали кластер, мы включили функцию “Admission Control” (Контроль запуска виртуальных машин), которая не позволяет администратору запускать виртуальные машины, если нарушаются условия для обеспечения высокой доступности приложений. Пока в кластере есть только один сервер, поэтому, при его аварии, ни о какой высокой доступности речи быть не может – условия нарушены и мы не сможем запустить ничего.
Выбираем кластер, раскрываем выпадающее меню “Actions” (Действия) и выбираем “Settings” (Параметры). Находим и выключаем “Admission Control“. Теперь можно запустить все выключенные виртуальные машины. Надо не забыть опять включить “Admission Control“, когда начнем устанавливать режим высокой доступности для виртуальных машин.
Перемещаем виртуальную машину vCenter Server Appliance “вручную” на сервер, который только что перенесли в кластер. Как это сделать описано в “Как переместить виртуальную машину между серверами vSphere”.
Запускаем vCenter Server Appliance и открываем vSphere Web клиент опять.
Выключаем все виртуальные машины на втором сервере (см п. 2.).
Переносим оставшийся сервер в кластер, как это описано в п. 3.
Все. Мы успешно перенесли наши сервера в кластер. Теперь можем использовать технологии высокой доступности и перемещать виртуальные машины между серверами, не выключая их.

Читайте так же:

Как отключить адблок в яндекс браузере

Описано как переместить сервер в кластер VMware vSphere с включенным режимом EVC. Четвертая часть цикла “Создание виртуальной среды из нескольких серверов”. Дается пошаговая инструкция с пояснениями.

16 самых больших ошибок при настройке кластеров HA и DRS VMWARE

Включить EVC режим на кластерах, и стараться использовать оборудование, которое имеет очень похожие процессоры. Не смешивайте процессоры Intel и AMD. И даже если все ЦПУ одного вендора, новые процессоры будут поддерживать дополнительные инструкции не доступные на старых моделях. Обратите внимание на Процессоры, которые вы покупаете.

Снапшоты — зло, и вы НЕ должны их использовать, кроме как в редких случаях. Убедитесь, что ваши VMDK в presistent режиме или используйте RDM. Серверы должны видеть исходный и целевой датастор, и кластер должен иметь достаточно ресурсов, чтобы в момент переноса иметь две одновременно запущенные копии ВМ.

Планируйте необходимые ресурсы кластера и учитывайте необходимость резерва. Как правило, резервы по ресурсам на хостах должны в сумме быть как один полноценный сервер. Решением является использование политики admission control и планирование выхода из строя одного хоста.

Не все ВМ являются критичными и у каждой есть разный приоритет перезапуска. Резервирование всего выделенного хоста может быть нерациональным. Используйте для резерва процент ресурсов, который чуть меньше, чем вклад каждого хоста в полный кластер, в отношении на суммарное количество хостов. Например, в четырех узловом кластере, каждый сервер вносит 25%, в этом случае можно установить процент резерва примерно 20 или 15%.

Если вы используете предложение из 4-го пункта, необходимо правильно настроить приоритет перезапуска VM, поскольку вы не будете резервировать ресурсы кластера для перезапуска ВСЕХ ваших виртуальных машин. Установите обычным ВМ низкий приоритет, а отдельным ВМ поднимите приоритет до среднего или высокого по мере необходимости.

Плохая идея! Никогда, никогда, никогда не делайте этого! Включите опцию – «do not power on if inadequate cluster resources»

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

Отказоустойчивость должна предусматривать вариант отказа самого большого сервера в кластере. Если есть кластер из шести серверов с 96 ГБ оперативной памяти, и затем вы добавляете сервер с 384 ГБ оперативной памяти, будут слишком разбалансированные расчеты для резервирования, и у вас останется много неиспользованных ресурсов.

Это запутанная тема для многих. До версии vSphere 5.0 в этой настройке можно было сделать ошибки, которые давали не совсем ожидаемые результаты. Можно на уровне хоста настроить отключение виртуальных машин при изоляции, но на уровне каждой конкретной виртуальной машины изменить настройки, если на ВМ есть критические приложения, для которых нужно убедиться, что их отключение не случайная ошибка. Начиная с версии 5.0 к настройке изоляции хоста добавились хартбиты хранилища, которые используются только в случае, если сеть хоста не доступна. Серверы в кластере должны иметь по крайней мере одно общее хранилище.

Используйте shares вместо reservations и ограничьте использование affinities (или anti-affinities) правил. Эти ограничения могут оказать влияние на производительность DRS. Используйте с осторожностью!

Читайте так же:

Хост процесс для задач

Никогда не делайте это, никогда, никогда! Ограничивайте использования памяти с помощью приложений, если это возможно. Например, вы можете настроить SQL, чтобы ограничить объем памяти, который он будет использовать внутри гостевой виртуальной машины.

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

Расчёты по DRS cлишком сложны

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

Хотя технически ограничение на кластер 32 узла, но лучше использовать не более 16-24. Чем больше хостов, тем больше расчетов у DRS и все больше и больше потребление ресурсов.

Это новые значения в схеме лицензирования vSphere 5.0. Назначайте нужное количество памяти и виртуальных ЦП для ВМ. Не будьте слишком либеральны. Делайте правильный размер VM, не увеличивайте их ресурсы без необходимости.

Как построить HA кластер в VMware

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

1. Общие сведения

*Общее хранилище данных может представлять собой не только «железную» СХД, но и быть программным. У VMware для этой цели есть продукт vSAN (virtual storage area network). У RedHat есть GlusterFS и т.д.

2. Список терминов

3. Последовательность создания HA кластера

4. Isolation Response

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

В первом случае, стоит выбрать значение параметра Isolation Response — Leave powered on, тогда все машины, продолжат свою работу, невзирая на то, что прекратят получать сигналы доступности.

По умолчанию Isolation Response установлен в режиме Power off. Мы не знаем как будут развиваться события в момент гипотетического отказа, поэтому мы рекомендуем оставлять значение IR в состоянии Power off, чтобы избежать риска появления в сети конфликтующих машин с одинаковыми сетевыми настройками.

5. Резервация ресурсов (Reservation)

6. Параметр Failover Capacity

После расчета слотов определяется сам параметр Failover Capacity. Он измеряется в целых числах и обозначает, какое максимальное количество узлов в кластере одновременно может выйти из строя. При этом все машины должны продолжать функционировать.

Иллюстрируем параметр Failover Capacity. Возьмем два случая (по вертикали: 1-й случай — отказ одного узла ESXi, 2-й случай — отказ 2-х узлов ESXi).

Первый случай: 3 узла ESXi, по 4 слота на каждом, 6 виртуальных машин.
В этом случае при выходе из строя одного узла (например, №3), ВМ 4,5,6 будут запущены на других узлах (в нашем случае №2, показаны стрелками), однако, при выходе из строя еще одного узла, свободных слотов под запуск ВМ не останется.

Второй случай: 3 узла ESXi, по 4 слота на каждом, 4 виртуальные машины.
В этом случае, свободных слотов хватит, даже если упадет сразу 2 узла ESXi(в нашем случае, ВМ перенесутся на хост №1).

Технически параметр Failover Capacity рассчитывается следующим образом: из количества всех узлов в кластере мы вычитаем отношение количества виртуальных машин в кластере к количеству слотов на одном узле ESXi. Если получается не целое число, округляем вниз.

Для первого случая: 3-6/4=1.5 Округляем до 1;
Для второго случая: 3-4/4=2 Так и остается 2;

7. Admission Control

Admission Control мы условно разделили на состояние Admission Control (состояние ADC ) и параметр Admission Control (параметр ADC ).

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

8. Рекомендации по созданию кластера HA

Мы представим общие рекомендации по созданию кластера HA :

esxi cluster

Специалисты компании V-Grade, помогут сделать для Вас быстрый и правильный расчёт esxi cluster.
Достаточно написать письмо на почту с темой письма «VMware HA кластер»vmware@v-grade.ru.
Так же можете задать вопросы на тему:
esxi cluster setup
vmware esxi cluster free
HA кластер

Читайте так же:

После установки яндекс браузера не запускается

Почему мы лучшие на рынке виртуализации VMware?

Компания V-GRADE v-grade.ru принадлежит,
ООО «Прогресс-Медиа» progm.ru.
Более 11 лет специализируется на решениях VMware.
Дата присвоения ОГРН: 19.05.2008
Адрес: 140072 , Московская обл., г.Люберцы, рп. Томилино,
ПРЕДОСТАВЛЕНИЕ СВЕДЕНИЙ ИЗ ЕГРЮЛ/ЕГРИП
ИНН: 7718705095
ОГРН: 1087746654753

Работая с нами Вы, получите:

Наши цены ниже по целому ряду причин:
V-GRADE — является Официальным Партнером VMware уровня Enterprise;
Работаем без посредников , напрямую с VMware, Veeam.

Контакты:
тел.: +7 (495)662-58-98
vmware@v-grade.ru

Наши эксперты:

У нас есть конфигуратор VMware, лучшие цены, актуальные статьи. лучшие эксперты.

Особенности VMware vSAN 6.5: FAQ и настройка кластера

VMware Virtual SAN (vSAN) это высокопроизводительное решение для хранения данных корпоративного класса для гиперконвергентной инфраструктуры. vSAN позволяет объединять SSD накопители и обычные диски, подключенные к локальным ESXi серверам, в общее высокоустойчивое хранилище данных, к которому могут обращаться все узлы кластера vSphere. Если ранее для обеспечения высокой доступности администраторам VMware нужно было использовать SAN, NAS или DAS, то в случае vSAN потребность в выделенном внешнем общем хранилища исключается, при этом добавляется новый программный уровень, который может использовать локальные диски отдельных локальных серверов для обеспечения такой же отказоустойчивости и набора функций SAN.

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

Основные возможности VMware vSAN

Встроенный функционал защиты и обеспечения высокой доступности данных с отказоустойчивостью, асинхронной репликацией на большие расстояния и растянутыми кластерами между географически разнесенными сайтами.
Использование распределенного RAID и зеркалирования кэша для защиты данных от потери отдельного диска, сервера или целой стойки
Минимизация задержек хранилищ за счет ускорения операций чтения/записи с дисков за счет встроенного кэша на сервере, хранящиегося на локальных SSD дисках
Программная дедупликация и сжатие данных при минимальными затратами ресурсов CPU и памяти
Возможность без простоя наращивать емкость и производительность сети хранения за счет добавления новых серверов и дисков
Политики хранения виртуальных машин позволяют автоматизировать балансировку и выделение ресурсов хранения и QoS.
Полная интеграция со стеком VMware, включая vMotion, DRS, высокую доступность (High Availability), отказоустойчивость (Fault Tolerance), Site Recovery Manager, vRealize Automation и vRealize Operations.
Поддержка iSCSI подключений
Возможность прямого подключения двух улов перекрёстным кабелем (VSAN Direct Connect).
Полная поддержка vSphere Integrated Containers для запуска контейнеров для DevOps на vSAN
Нет необходимости разворачивать дополнительные компоненты, виртуальные машины и интерфейсы управления.

VMware vSAN: системные требования

Требуется VMware vCenter Server 6.5 и хосты с ESXi 6.5
Минимум 3 хоста в кластере (максимум 64), однако можно реализовать vSAN и на двух хостах, но потребуется отдельный хост-свидетель
Каждый сервера ESXi в кластере vSAN должен иметь как минимум один SSD диск (флешку) для кэша, и как минимум один SSD/HDD для данных
Наличие SATA/SAS HBA или RAID-контроллера в режиме pass-through или в режиме RAID 0
Минимум 1 ГБ сетевая карта (рекомендуется 10 Гб)
Все хосты должны быть подключены к сети vSAN через сеть L2 или L3
На физических коммутаторах, которые обрабатывают трафик vSAN должна быть включено многоадресное вещание (мультикаст)
Поддерживаются как IPv4 так и IPv6.
Информацию о совместимости с конкретным железом нужно смотреть в соответствующем документе на сайте VMware

Лицензирование VMware vSAN

vSAN лицензируется в расчете по CPU, виртуальным машинам или конкурентным пользователю и поставляется в трех редакциях: Standard, Advanced и Enterprise.

Enterprise лицензия – требуется для использования QoS и растянутых кластеров
Advanced лицензия нужна для поддержки дедубликации, сжатия и RAID 5/6
Standard – базовый функционал

Читайте так же:

Как восстановить историю браузера яндекс

Лицензия vSAN можно использовать на любой версии vSphere 6.5.

Есть дополнительные способы сэкономить за счет использовании пакета Virtual SAN для ROBO, или приобретения набора лицензий Standard илиAdvanced в количестве 25 штук для удаленных филиалов. Более подробную информацию о лицензировании vSAN смотрите на сайте VMware.

Настройка сети и портов vSAN

Перед настройкой vSAN нужно убедится, что на каждом хосте кластере настроен порт VMkernel для трафика vSAN. В веб-клиенте vSphere по очереди выберите каждый сервер, на котором вы хотите использовать vSAN. Выберите вкладку Configure-> Networking -> VMKernel Adapters -> нажмите Add Host Networking. Убедитесь, что выбран тип VMkernel Network Adapter и нажмите Далее.

Создайте новый виртуальный коммутатор (New standard switch) и нажмите Next.

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

Укажите имя порта VMkernel и, если нужно, его VLAN ID. Обязательно поставьте галку напротив опции Virtual SAN и нажмите Next.

Укажите сетевые параметры порта VMkernel.

Если вы настраиваете сеть vSAN на тестовом стенде с ограниченным количеством физических интерфейсов, выберите сеть управления (Management Network) и в списке поддерживаемых служб поставьте галку у пункта Virtual SAN. При такой конфигурации трафик vSAN будет идти через общую сеть управления, чего в продуктивных развертываниях делать не стоит.

Настройка vSAN

Как мы уже говорили, для настройки vSAN дополнительно доставлять что+то на гипервизор не нужно, весь функционал уже имеется. Вся что требуется от администратора – настроить vSAN через интерфейс веб клиента vSphere (vSAN пока не поддерживает модный HTML5 клиент).

Чтобы включить vSAN найдите нужный кластер в консоли vSphere и перейдите на вкладку Configure. Разверните раздел Virtual SAN и выберите General. В нем должно быть указано, что Virtual SAN не включен. Нажмите на кнопку Configure.

По умолчанию в хранилище vSAN будут добавлены любые подходящие диски. Чтобы вручную выбрать диски, измените параметр назначения дисков на Manual. Здесь же можно включить опцию сжатия данных, отказоустойчивости.

На странице валидации сети должны появится подтверждения о том, что каждый хост в кластере подключен к сети vSAN.

Проверьте выбранные настройки и нажмите Finish. Дождитесь окончания выполнения задачи, после чего виртуальная сеть SAN объединит все локальные диски серверов выбранного кластера в распределенное хранилище vSAN. Данное хранилище представляет собой один единый VMFS датастор, на который вы сразу же можете поместить виртуальные машины. Настройки vSAN в дальнейшем можно будет изменить в том же разделе (вкладка кластера Configure -> Virtual SAN).

Vmware папки для хостов и кластеров

Кластер High Availability (высокой доступности) это то, ради чего многие и внедряют платную виртуализацию. Когда на сервере ESXi работает несколько виртуальных машин, файлы этих машин лежат на локальных дисках или даже на системе хранения данных, а кластер не создан, и вдруг этот сервер выходит из строя. Тогда все выключается и ждет пока человек вмешается в процесс. А Человек — системный администратор спит дома и на работу скорее всего ~~опаздает~~ задержется, и в дороге ему начнут звонить недовольные и спрашивать когда, когда… Вот для таких случаев и настраивается HA Cluster. С ним все происходит автоматически, один сервер ESXi выходит из строя — ВМ, которые были запущены на нем, перезапускаются на другом сервере кластера. И еще одно применение HA, если гостевая операционная система внутри виртуальной машины зависает и перестает отвечать на запросы, такая ВМ автоматически перезапускается. Вот этот функционал я и покажу в текущей статье.

Естественно, все не так просто, и перед HA , было произведено немало настроек, посмотреть можно тут.

У меня тут два сервера ESXi, которые управляются через vCenter server. Создано 2 виртуальные машины, файлы которых лежат на LUN-е системы хранения данных FreeNAS (все это было описано ранее). И я создаю новый кластер.

Читайте так же:

Браузер сохраняет картинки в формате webp

Название кластера, и галочка только напротив HA. Про DRS будет отдельная статья.

Host Monitoring status — это основной механизм в HA, отслеживает состояние серверов ESXi и по результату данного мониторинга происходят уже действия, такие как перезапуск виртуальных машин, например.
Admission Control — если в кластере HA может не хватить ресурсов для запуска виртуальных машин с вышедшего из строя сервера ESXi то лишние виртуальные машины не даст запустить Admission control (надеюсь понятно). А вот сколько сервером может выйти одновременно из строя серверов указывается через Admission control policy (по умолчанию 1).
Альтернативно можно также настроить политику, чтобы она оставляла ресурсы CPU и памяти. Но многие администраторы сразу отключают этот искуственный контроль — раздражает сильно.

тут все по-умолчанию

VM Monitoring — как только Windows (например) внутри виртуальной машины вылетает в BSOD, VM Monitoring отслеживает, что ОС не отвечает на запросы и перезагружает ВМ.

EVC — encahced vMotion compatibility — если у вас разные процессоры в серверах ESXi или разное количество ядер, то процесс миграции виртуальной машины vMotion может закончиться неудачей. Такие серверы добавить в кластер HA с ВЫключенной EVC не получится. EVC приводит серверы к общему знаменателю, чтобы они могли работать в кластере и обеспечивать отказоустойчивость. EVC в основном смотрит на процессор, понижая функциональность всех процессоров до самого слабого в кластере.

Сохранять файл подкачки в папке виртуальной машины.

Все готово, кластер почти создан

Создан успешно. Слева вверху видим сам кластер и наши ESXi серверы отдельно. Теперь нужно перенести хосты в кластер. Действуем мышкой, Drug-and-Drop

На каждый сервер ESXi во время добавления в кластер устанавливается агент HA. Если интересно, как именно работает, HA, как установленные агенты обмениваются информацией и устравают выборы мастера, погуглите. Мне важно, что HA работает теперь лучше чем в VMware vSphere 4.1

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

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

Да мы уверены, что хотим выключить, хоть он и не в Maintenance mode. Этот режим нужен, чтобы корректно выводить сервер из эксплуатации, чтобы нечаянно не погасить ВМ, а мне именно это и нужно сейчас.

Выключаешь, укажи причину.

Сначала агент HA, забил тревогу. Потом на виртуальной машине появился красный восклицательный знак.

Отвалился ESXi хост

WinXP почти вернулся в сторой.

Видим что запустился WindowsXP на 115 хосте.

Включил обратно хост 106, но виртуальные машины остались на 115. Чтобы они вернулись обратно нужно делать миграцию vMotion руками . Чтобы они вернулись автоматически требуется DRS.

Давайте уберем надоедливую ошибку «This host currently has no management network redundancy», она говорит о том, что вся отказоустойчивость у нас кончается на одной единственной сетевой карточке. Можно двумя путями пойти, добавить второй сетевой интерфейс (на 106 хосте так сделаю) или просто отключить ошибку, чтобы не отображаласть (для всего кластера).