Vmware 6 5 настройка

Обновлено: 04.07.2024

В vSphere 6.5 появилась встроенная возможность организации отказоустойчивого сервера vCenter High Availability (VCHA). Архитектурно решение VCHA реализации за счет создания пассивной копии сервера vCenter, которая выполняется на другом узле ESXi, чем обеспечивается высокая доступность экземпляра vCenter при аппаратных или программных проблемах.

Архитектура высокой доступности сервера VMWare vCenter 6.5

Архитектура отказоустойчивого VCHA состоит из 3 узлов: активного, пассивного экземпляра vCenter Server Appliance и хоста-свидетеля. Активный экземпляр vCenter Appliance имеет два сетевых интерфейса: стандартный интерфейс управления (eth0) и специальный интерфейс HA (eth1). VCHA реплицирует данные с активной ноды на пассивную по HA сети. База данных активной копии vCenter реплицируется в синхронном режиме, а файловая система – в асинхронном. У пассивной копии также 2 сетевых интерфейса, однако основной его интерфейс eth0 с теми же FQDN, IP и MAC неактивен. Интерфейс активируется в случае сбоя основного экземпляра сервера vCenter. Свидетель является последним элементом архитектуры VCHA. Он используется для предоставления ресурса-кворума, информируя кластер о том, какой из узлов является активным в текущий момент времени. В нормальном режиме работы все три компонента кластера должны быть доступны.

При сбое, на пассивной ноде активируется интерфейса eth0. С помощью механизма Gratuitous ARP выполняется оповещение устройств в широковещательном домене о появлении новой привязки IP и MAC. Если оригинальная нода после сбоя опять появляется в сети, она снова становится активной и репликация восстанавливается. В том случае, если он полностью утрачена, ее можно удалить из конфигурации и пересоздать кластер VCHA.

Что потребуется для организации высокодоступного сервера vCenter

vCenter Server Appliance версии 6.5

Лицензия vCenter Standard
Размер развертывания vCSA: Small, Medium или Large (но не tiny)
Встроенный или внешний Platform Services Controller (PSC)

Рекомендуется использовать как минимум 3 хоста

Отдельная HA сеть, отделенная от сети управления
Сетевая задержка между двумя узлами не более 10мс
Статические IP адреса на нодах

Настройка высокой доступности vCenter

Настройку HA для vCenter следует начать с создания новой отдельной HA сети. В нашем примере мы добавим группу портов HA в существующий виртуальный коммутатор. Т.к. мы используем стандартные виртуальные коммутаторы, группа портов HA добавится на 3 хостах.

После создания сети, щелкните ПКМ по серверу vCenter Server в разделе навигации клиента vSphere Web Client. В меню выберите vCenter HA Settings.

В меню vCenter HA нажмите на кнопку Configure в правом верхнем углу.

Есть два варианта настройка HA.

Basic – автоматическое клонирование сервера и настройка всех трех узлов
Advanced – настраиваемый вариант развёртывания, клонирование сервера и настройка узлов кластера выполняется в ручном режиме.

Укажем IP адрес и подсеть для HA интерфейса на активной ноде. В качестве сети нужно выбрать созданную ранее выделенную сеть HA.

Укажите IP адрес пассивной (Passive) ноды и свидетеля (Witness).

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

Если все ОК, нажмите кнопку Finish для начала развертывания.

Запустите процесс клонирования и автоматической настройки трех узлов. Процесс выполнения развертывания можно отслеживать в разделе Recent Tasks.

После завершения развертывания в иерархии vCenter появятся два новых узла. Как вы видите, для пассивной копии vCenter добавлена постфикс –peer , а для свидетеля –witness.

На свете существует замечательный гипервизор ESXi от компании VMWare, и все в нем хорошо, но вот требования к “железу”, на котором он может работать, весьма нескромные. ESXi принципиально не поддерживает программные RAID’ы, 100-мегабитные и дешевые гигабитные сетевые карты, поэтому попробовать, каков он в работе, можно только закупившись соответствующим оборудованием.
Однако ESXi самые “вкусные” возможности ESXi открываются тогда, когда у нас есть не один, а несколько хостов ESXi — это кластеризация, живая миграция, распределенное хранилище VSAN, распределенный сетевой коммутатор и т.п. В этом случае затраты на тестовое оборудование уже могут составить приличную сумму. К счастью, ESXi поддерживает Nested Virtualization — то есть способность запускаться из-под уже работающего гипервизора. При этом и внешний гипервизор понимает, что его гостю нужен доступ к аппаратной виртуализации, и ESXi знает, что работает не на голом железе. Как правило, в качестве основного гипервизора также используется ESXi — такая конфигурация поддерживается VMWare уже довольно давно. Мы же попробуем запустить ESXi, использую гипервизор QEMU. В сети есть инструкции и на этот счет, но, как мы увидим ниже, они слегка устарели.

Для начала обозначим версию QEMU, на которой будем ставить эксперименты:

Последняя на данный момент версия, но у меня фокус получался даже на 2.4.0.
Затем отключим невежливое поведение модуля KVM в моменты, когда гость пытается читать машинно-специфические регистры, которых на самом деле нет. По-умолчанию, KVM в ответ на это генерирует внутри гостя исключение General protection fault, отчего гость ложится в синий (в нашем случае-розовый) экран смерти. Сделаем под рутом:

В некоторых дистрибутивах модуль kvm грузится по умолчанию с нужными параметрами, в некоторых — нет. В любом случае нужно проверить dmesg на наличие строк

Если этих строк нет — добавить в /etc/modprobe.d/kvm.conf строку

и перезагрузиться. Для процессора Intel строка примет вид:

Попробуем решить проблему “в лоб” — пойдем на сайт VMWare, зарегистрируемся там и скачем последний на данный момент образ VMware-VMvisor-Installer-201701001-4887370.x86_64.iso.

Не будем измудряться, создадим аналог “флешки” на 16Gb, возьмем наверняка поддерживаемую сетевую карту e1000, поставим RAM в 4 Gb (с меньшим количеством памяти ESXi гарантированно не встанет) и запустим установку, полагая, что в такой конфигурации ESXi как минимум не увидит IDE-диска:

И тут нас ждет первая неожиданность — ESXi не только обнаруживает наш IDE-диск, но и успешно ставиться на него, правда, на пять минут подвисая на 27% установки:

А вот 8086:100e — это идентификатор чипа “Intel 82540EM Gigabit Ethernet Controller”, который с некоторых пор объявлен unsupported, т.е. он работает, но с ним не работает техническая поддержка.

Вообще, QEMU поддерживает эмуляцию разных сетевых карт:

но не все они работают в ESXi одинаково хорошо, например, с формально поддерживаемым e1000e не работает проброс портов в user-режиме сети, а у vmxnet3 пропадает половина пакетов. Так что остановимся на e1000.

Перезагружаем ВМ и видим, что гипервизор стартовал успешно. Собственно, и все — патчить QEMU для ESXi, как рекомендуют некоторые руководства, не нужно.

Нужно отметить, что я использую параметр nocow=on при создании диска, поскольку диск ВМ будет лежать на btrfs, которая сама по себе является ФС с концепцией copy-on-write. Если добавить к этому то, что и thin-provisioned диск формата qcow2 тоже реализует этот принцип, то получится кратное увеличение числа записей на диск. Параметр nocow=on заставляет qemu-img создавать файл с атрибутом nocow и тем самым блокировать механизм copy-on-write в btrfs для конкретного файла.

В режиме сети user внутри ВМ работает легковесный DHCP-сервер, поэтому адрес присваивать не нужно, однако придется пробрасывать порты. Заходим в консоль QEMU, нажав Ctrl+Alt+1, вводим там команду

и пробрасываем 443 порт с сетевого интерфейса виртуальной машины на 4443 порт хоста. Затем в браузере набираем

Удивительно, но установщик ESXi даже создал в свободной области диска “хранилище” размером целых 8Gb. Первый делом поставим пакет с обновленным Web-интерфейсом, потому что разработка этого полезнейшего компонента идет быстрее, чем выходят новые версии ESXi. Идем в консоль QEMU по Ctrl+Alt+1 и пробрасываем там 22 порт:

потом переключаемся в консоль гипервизора по Ctrl+Alt+2, нажимаем F2 — Troubleshooting Options — Enable SSH и подключаемся клиентом SSH:

Идем во временный каталог

Как видно, размер Web-интерфейса — чуть больше трех мегабайт.

Теперь попробуем улучшить нашу виртуальную машину. Первым делом сменим контроллер дисков с IDE на AHCI, потому что реализация контроллера PIIX3 1996 года выпуска в QEMU, как бы это сказать, слегка тормознутая. А контроллер AHCI (эмулируется чипсет Intel ICH9) во-первых, быстрее, а, во вторых, поддерживает очереди команд NCQ.

Даже по уменьшению времени загрузки компонентов гипервизора видно, что прирост в скорости мы получили. На радостях заходим в Web-интерфейс и… как это нет дисков? На вкладке “Adapters” AHCI-контроллер имеется, однако диски на нем не определяются. А как же тогда загрузился гипервизор? Очень просто — на начальном этапе загрузчик считывает данные диска при помощи BIOS и видеть диски напрямую ему не нужно. После того, как компоненты загружены в память, загрузчик передает на них управление, а инициализация гипервизора проходит уже без обращений к диску.

Как бы то ни было, ESXi 6.5 дисков на AHCI-контроллере не видит, а вот ESXi 6.0 эти диски видел — зуб даю. С помощью Google и такой-то матери выясняем причину: в ESXi 6.5 старый драйвер ahci замене на полностью переписанный драйвер vmw_ahci, из-за чего у кучи народа тормозят SSD, а у нас не определятся диски. Согласно совету из статьи делаем на гипервизоре

перезагружаемся и… ничего не происходит. А чего мы хотели? Дисков-то нет, записывать конфигурацию некуда, следовательно, наши изменения и не сохранились. Надо вернуться на IDE-диск, выполнить эту команду и уже потом загружаться с AHCI — тогда диски определяться.

USB 3.0 диски тоже не определяются. Видимо, и здесь драйвер переписан. Ну что ж, мы уже знаем, что делать. Идем в консоль гипервизора, там пишем

Когда система загрузится, зайдем в Storage — Devices и увидим там нашу флешку. Кстати, с USB 3.0 контроллером nec-usb-xhci система загружается намного быстрее, чем с ich9-usb-ehci2.

Итак, минимум два драйвера контроллера диска в ESXi 6.5 переписаны заново по сравнению с ESXi 6.0. А казалось бы — только цифра после точки в номере версии изменилась, можно сказать, минорный релиз.

Если мы добавим к конфигурации виртуальной машины диск объемом 1 Tb, то сможем создать полноценное хранилище в дополнение к диску с гипервизором. Чтобы система грузилась с usb-диска, а не с ahci, воспользуемся параметром bootindex. Обычно для управления порядком загрузки применяют параметр -boot, но в нашем случае он не поможет, потому что диски “висят” на разных контроллерах. Заодно заменим платформу со старого чипсета 440fx на новый Q35/ICH9.

Заходим в консоль — вот они, наши диски.

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

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

Теперь нам нужен виртуальный коммутатор. Долгое время для этих целей принято было использовать встроенный в ядро Linux виртуальный коммутатор, управляемый утилитой brctl. Сейчас же принято решать задачу через Open vSwitch — реализацию коммутатора, предназначенную именно для виртуальных сред. Open vSwitch имеет встроенную поддержку VLAN, протоколов туннелирования (GRE и т.п) для объединения нескольких коммутаторов и, что самое интересное — технологии OpenFlow. Иными словами, в коммутатор можно загружать правила фильтрации L2/L3 в удобочитаемом формате. Раньше для фильтрации требовалось использовать iptables/ebtables, а, как говориться, хорошую вещь “ebtables” не назовут.

Установим Open vSwitch, если он еще не стоит:

Создадим виртуальный коммутатор:

Добавим в него интерфейсы:

Посмотрим, что получилось:

Теперь присвоим интерфейсу коммутатора адрес:

Казалось бы, достаточно просто изменить тип сети в командной строке QEMU с user на tap, примерно так:

и все будет работать.

Зайдем в консоль ESXi и присвоим ему адрес — 192.168.101.2, а затем проверим связь:

….
и из консоли ESXi — F2- Test Network

Все работает, пинги ходят.

Сделаем копию диска esxi_6.5-1.qcow2 и запустим второй экземпляра ESXi:

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

Ясно, что мы напортачили с mac-адресами, и действительно, QEMU присваивает всем tap-адаптерам один и тот же mac-адрес, если не указано иное.

Выключим оба ESXi’а, укажем им уникальные mac’и и запустим снова.

И в другой консоли:

К нашему громадному удивлению, проблема с пингами никуда не делась, мало того, команда arp показывает, что не изменились и MAC-адреса гипервизоров. Тут самое время вспомнить, как устроена сеть в ESXi: физическая сетевая карта переведена в “неразборчивый режим” и подключена в качестве одного из портов к виртуальному коммутатору. Другим портом к этому коммутатору подключен интерфейс vmkernel, который и является сетевой картой с точки зрения гипервизора. В момент установки ESXi аппаратный адрес физической сетевой карты клонируется в vmkernel, чтобы не смущать системного администратора. После этого его можно изменить только удалив интерфейс и создав его заново или же указав гипервизору, что следует переконфигурировать vmkernel из-за изменения адреса физической карты.

Существенная различие между указанными способами состоит в том, что первый не требует перезагрузки гипервизора, а второй — требует.

Выполнив эти нехитрые операции, мы получим в одной сети два гипервизора.

Теперь можно ставить vCenter и проверять”живую миграцию”. С некоторых пор vCenter доступен в виде образа виртуальной машины с Linux и соответствующими службами на борту. Именно такой вариант мы попробуем установить. Берем образ VMware-VCSA-all-6.5.0-5178943.iso, монтируем его в хостовой ОС, запускаем инсталлятор из каталога vcsc-ui-installer\lin64 и разворачиваем образ, следуя указаниям мастера. Для виртуальной машины потребуется 10 Gb оперативной памяти, так что на хостовой системе неплохо было бы иметь минимум 16 Gb. Впрочем, у меня образ развернулся и на 12 Gb RAM, съев всю доступную память и загнав систему в своп.

После установки VCSA заходим в Web-интерфейс с учетными данными вида administrator@mydomain.tlb и паролем, которые мы указали при настройке SSO. После этого добавляем в vCenter оба хоста и получаем простейший кластер, в котором работает живая миграция. Настроим vMotion на сетевых картах обоих хостов, создадим виртуальную машину TestVM и убедимся, что она может переезжать с одного хоста на другой, меняя как хост, так и хранилище.

Кстати, на предыдущих версиях ESXi до 6.0 включительно виртуальную машину невозможно было запустить в режиме вложенной виртуализации без добавления строки

в ее конфигурационный файл. В ESXi 6.5 этого делать не требуется, и виртуальная машина запускается без вопросов.

В заключение — небольшой лайфхак. Допустим, вам нужно скопировать файл диска ВМ из хранилища ESXi куда-нибудь на сервер резервных копий, при этом у вас нет возможности пользоваться FastSCP из состава Veeam Backup and Replication. Вам на помощь придет старый добрый rsync, нужно только найти бинарный файл, который запуститься на ESXi. К сожалению, в rsync вплоть до версии 3.0.9 включительно есть баг, из-за которого некорректно обрабатываются большие файлы на томах VMFS, поэтому стоит использовать rsync версии 3.1.0. и выше. Взять его можно здесь.

«Сервер vCenter — упрощенное и эффективное ПО для управления серверами

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

Сервер VMware vCenter — это централизованная платформа для управления средами VMware vSphere, с помощью которой можно автоматизировать виртуальную инфраструктуру и безопасно предоставлять к ней доступ в гибридном облаке.»

От себя же добавлю, что все основные «вкусняшки» виртуализации от VMware доступны только при наличии VCenter Server. Конечно, если вам не нужно централизованное управление хостами, живая миграция виртуальных машин и многое другое, вы вполне можете обойтись функционалом бесплатного ESXi, но, если хочется большего, давайте перейдем к вопросу

Подготовка к установке.

Что такое VCenter Server Appliance? Это виртуальная машина VMware, предварительно сконфигурированная, которая может работать на одном из хостов, которыми управляет. Есть VCenter, который устанавливается на физический или виртуальный сервер с Windows, но это требует лицензирования windows(доп. расходы), да и по функционалу Virtual Appliance сейчас не уступает виндовому собрату. Поэтому ставим Appliance.))

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

Посмотреть требования для установки VCSA можно по ссылке:

Размер инфраструктуры	Процессор	ОЗУ
Tiny environment (up to 10 hosts or 100 virtual machines)	2	10 GB
Small environment (up to 100 hosts or 1,000 virtual machines)	4	16 GB
Medium environment (up to 400 hosts or 4,000 virtual machine)	8	24 GB
Large environment (up to 1,000 hosts or 10,000 virtual machines)	16	32 GB
X-Large environment (up to 2,000 hosts or 35,000 virtual machines)	24	48 GB

По месту на диске: от 250 ГБ.

Хост ESXi, на который ставится VCSA, должен быть доступен с компьютера, на котором запущен установщик.

Установка VCenter Server Appliance 6.5

Откройте скачанный ISO-образ, перейдите в папку vcsa-ui-installer -> win32(при установке с компьютера с Windows) и запустите файл installer.exe

На первом экране мастера установки выберите необходимое действие(в нашем случае Install).

На следующем экране нажмите Next.

Примите условия лицензионного соглашения и нажмите Next.

На следующем шаге оставляем по умолчанию Embedded Platform Sevice Controller и жмем Next.

Далее нужно указать хост esxi, на котором разворачиваем VCSA и пароль от учетной записи root(для хоста).

На следующем экране задаем имя нашей ВМ и пароль для учетной записи root(для ВМ).

Выбираем конфигурацию нашей ВМ в зависимости от размера нашей инфраструктуры.

Указываем datastore, на котором будут располагаться файлы виртуальной машины VCSA(здесь можно выбрать «тонкий» формат дисков ВМ, установив соответствующий чекбокс).

На следующем экране вводим имя системы(в данном примере я использую IP-адрес) и сетевые параметры.

Проверяем настройки и жмем Finish.

Начнется развертывание VCSA.

По завершении установки вы увидите следующее:

Второй этап — настройка VCSA.

Жмем Next.

Определяем настройки синхронизации времени, с хостом или с серверами точного времени в Интернете.

В случае синхронизации с серверами в Интернете, укажите имена серверов через запятую.

Еще: Как развернуть виртуальную машину vmware из шаблона.

Также, можно включить или отключить SSH доступ

Дальше идут настройки SSO-домена(Single Sign On). Можно создать новый SSO-domain или присоединиться к существующему.

Задаем имя домена, сайта и пароль администратора.

На следующем экране снимаем галку, если не хотим присоединяться к программе VMware Customer Experience Improvement Program.

Ну и на завершающем этапе, проверяем настройки и жмем Finish.

Начнется настройка VCSA.

Перейдя по ссылке, можно выбрать либо Web-client либо HTML5-client(с ограниченной функциональностью).

Жмакнув на ссылку vSphere Web Client откроется страница входа, где, разрешив использование флэш-плеера

и введя учетные данные administrator@vsphere.local,

вы сможете попасть в интерфейс управления VCenter.

Выключаем ВМ VCSA, кликаем по ней правой кнопкой мыши и выбираем пункт Upgrade VM Compatibility

Выбираем совместимость с ESXi 6.5 и жмем Upgrade

Подтверждаем согласие с обновлением ВМ, нажав Yes

После этого заходим в настройки ВМ, выбираем VM Options->General Options и выбираем версию ОС VMware Photon OS(64 bit)

Вот так происходит установка VCenter Server Appliance 6.5. О его настройке постараюсь написать позже, если кому-то интересно.

05.02.2020

VMWare

комментариев 17

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

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

Примечание. Аналогом vSAN у Microsoft является технология Storage Spaces Direct (S2D), появившаяся в Windows Server 2016.

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

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

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).

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