Категорії
VMware: Гайди з розгортання та налаштування

Настройка, мониторинг и администрирование VMware vSAN 7.0U1

Прочитав статью «Дизайн и разворот vSAN 7.0U1», мы научились создавать кластер виртуального хранилища данных согласно разработанному дизайну, а также построили весь необходимый фундамент для его последующей настройки. Теперь настало время разобраться с этой самой настройкой, внедрить подходящие политики хранения для виртуальных машин, назначить другой необходимый функционал и научиться пользоваться этим продуктом во всем его многообразии.

В качестве исходных данных будем предполагать, что работаем в существующей среде vSphere 7.0U1, готов новый кластер vSAN, хосты внутри него включены в соответствующие fault domain и прописаны все сетевые настройки.

Политики хранения виртуальных машин

Немного о политиках хранения данных говорилось в материале «Дизайн и разворот vSAN 7.0U1», когда обсуждали краеугольные камни построения конфигурации vSAN.

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

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

  • правила обслуживания данных (управление IOPS для объекта vSAN),
  • правила размещения на основе емкости (можно указать резервирование емкости с учетом расширения и т.п.),
  • правила размещения на основе тегов (сортировка по ссылочным тегам для определения местонахождения ВМ).

Исходя из этого можно сделать вывод, что выбираемая для хранилища политика представляет собой набор правил (их группы), общих для всех типов хранилищ и не зависящих от datastore, включая Storage I/O control, репликацию, шифрование и др.

Можно использовать политики дефолтные (предустановленные) или новые пользовательские. Чтобы просмотреть список уже существующих политик и убедиться в достаточности их функционала, следует в веб-клиенте vSphere зайти в раздел «Shortcuts» меню, где найти «VM Storage Policies»:

Страница с политиками выглядит вот так:

И здесь во вкладке «Rules» конкретно выбранной политики как раз и можно выяснить о ней все подробности.

Политика по умолчанию

В соответствии с дефолтной политикой внедряются такие параметры:

  • Site disaster tolerance – нет (стандартный кластер);
  • Failures to tolerate – 1 сбой (зеркалирование RAID-1);
  • Количество дисковых полос на каждый объект – 1;
  • Лимиты IOPS для объекта – нет;
  • Резервация пространства для объекта – Thin provisioning;
  • Резервация для Flash-кэша на чтение – 0%;
  • Отключение контрольной суммы объекта – не отключена;
  • Force provisioning – не назначено:

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

Если в «Shortcuts» веб-клиента vSphere в секции «Monitoring» выбрать «VM Storage Policies»:

мы увидим список уже существующих политик хранения (в базовом варианте будут только дефолтные). Над ним будет кнопка «Create VM Storage Policy»:

После нажатия на которую откроется соответствующий визард. Пробежимся по его пунктам:

  • «Name and discription». Здесь указывается название для новой политики и опционально можно привести к ней описание;
  • «Policy structure». Тут надо выбрать «Enable rules for “vSAN” Storage», чтобы установить специфическое для vSAN правило:

  • «vSAN». В этом пункте непосредственно задается набор правил, и в нем последовательно нужно пройти по всем трем вкладкам:
    • «Availability». Назначается доступность объектов, то есть «failures to tolerate»:

    • «Advanced Policy Rules». Здесь задается число страйпов на объект, лимиты IOPS для каждого, тип резервирования пространства для объекта, резервация для Flash-кэша на чтение, включается или отключается проверка контрольной суммы для объекта и Force provisioning, если необходим:

В нашем примере пусть будет так:

  • «Tags». Если нужно присвоить правилу тэг, нажимаем кнопочку «Add tag rule»:

  • «Storage compatibility». В этом пункте приводится список дата-стораджей, которые совместимы с задаваемой политикой:

  • «Review and finish». Если все назначенное устраивает, жмем «Finish».

Изменение политик хранилища

Однажды созданную политику хранилища всегда можно перенастроить. К примеру, хочется назначить параметру «Object space reservation» не «Thin provisioning» (задавалось выше в примере создания новой политики), а кастомное значение 25%. Это означает, что после переконфигурирования каждый объект стораджа будет резервировать четверть VMDK в хранилище vSAN. В цифрах, если, например, все виртуальные машины были развернуты, суммарно, с 40ГБ VMDK и назначенным «Failures to tolerate=1 failure – RAID-1 (Mirroring)», размер резервирования будет 20 ГБ.

Перейдем непосредственно к редактированию. Заходим в список политик, находим ту, которую необходимо изменить, и выбираем опцию «Edit Settings» – откроется окно «Edit VM Storage Policy», где прощелкиваем все без изменений до третьего пункта конфигурации «vSAN» и проходим во вторую вкладку «Advanced Policy Rules». Находим там «Object space reservation» и в выпадающем меню выбираем нужное значение, отличное от предыдущего:

Далее идем по пунктам визарда, не меняя более ничего, пока не закончим редактирование по кнопке «Finish».

После этого покажется всплывающее предупреждение, демонстрирующее пользователю, для скольких виртуальных машин станет теперь реальностью измененная политика хранения. Если политика переконфигурирована не в окно maintenance, рекомендуется выбрать в нем в выпадающем меню «Manually later»:

Если же ситуация для перемены политики удобная (в процессе окно техобслуживания), применяем ее сразу.

Пока этого не сделать, статус машин будет ненадлежащим. В этом легко убедиться, если выбрать измененную политику и кликнуть на вкладку «VM Compliance» вверху. Тогда будут показаны машины с ней, однако их состояние теперь обозначается как несоответствующее («Out of Date»).

Поэтому, когда настанет момент вернуться к этому вопросу, следует обязательно выбрать в списке политик ту, которую переконфигурировали, и нажать вверху на кнопочку «Reapply VM Storage Policy»:

И снова – предупреждение о том, что для изменения политик этого конкретного числа ВМ потребуется определенное время и системные ресурсы. Соглашаемся кнопкой «ОК»:

Теперь после проверки соответствия в списке политик ошибок не обнаружится.

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

Сброситься в дефолтные значения можно по одной замечательной кнопке в управлении политиками «Reset to Factory Defaults»:

Разворот виртуальных машин в vSAN и операции с ними

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

Создание новой виртуальной машины в vSAN

Сейчас будем рассматривать разворот ВМ с политикой по умолчанию, в которой прописано создание зеркальной копии данных машины и помещение ее на другой хост для отказоустойчивости при любом одиночном сбое, а также резервация пространства по thin-provision типу – для экономии места (о назначении пользовательских настраиваемых политик хранения см. выше).

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

Помимо наличия политики (предустановленной или собственноручно настроенной), необходимо убедиться, что для разворота ВМ хватает места: проверить емкость можно кликнув на имя интересующего кластера и пройдя по следующему пути меню: «Monitor – vSAN – Capacity»:

Сама же процедура создания виртуальной машины состоит в следующем:

  • На левой панели идем в «Hosts and Clusters», ищем нужный хост, кликаем на нем правой кнопкой мыши и выбираем пункт меню «New Virtual Machine», после чего откроется мастер-установщик;
  • «Select a creation type». Здесь выбираем «Create a new virtual machine». «Next»;
  • «Select a name and a folder». Придумываем имя для виртуальной машине и выбираем для нее папку:

«Next»;

  • «Select a compute resource». Выбираем «vSAN Cluster» в качестве вычислительного ресурса. «Next»;
  • «Select storage». Здесь нужно выбрать вверху в выпадающем меню удовлетворяющую политику (у нас – Default), тогда выведутся все соответствующие ей хранилища vSAN:

«Next»;

  1. «Select compatibility». В этом пункте выбирается совместимость с версией ESXi (у нас – надо все оставить по дефолту). «Next»;
  2. «Select a guest OS». Индивидуально выбираем нужную операционку для этой ВМ (у нас – тоже по умолчанию). «Next»;
  3. «Customize hardware». Аналогично изменений можно не делать;
  4. «Ready to complete». Проверяем все настройки и соглашаемся с разворотом кнопкой «Finish».

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

Когда ВМ создана, нужно проверить ее объекты. Для этого в инвентаре кликаем на нее и переходим на вкладку «Configure», где выбираем «Policies». Должно быть презентовано два объекта: «VM home» и «Hard disk 1»:

В колонке «Compliance Status» статус дисков отмечен, как соответствующий. Это означает, что с применением выбранной политики для них у vSAN все в порядке. Также это проверить можно в мониторинге кластера, зайдя на его вкладку «Monitor» и выбрав «Virtual Objects»:

Если здесь поставить галочку на конкретном диске, например, на «Hard 1», и нажать на «View Placement Details», откроется вот такое вот окошко:

где отразится физическое расположение RAID 1-конфигурации с двумя компонентами, каждый из которых соответствует зеркальной копии виртуального диска. Причем разные компоненты расположены на различных хостах. Это означает, что для этого диска нами применилась политика отказоустойчивости «tolerate 1». Там же, как мы видим, предусмотрен и свидетель.

Кстати, благодаря выбору тонкого типа разворота, новая машинка заняла минимум места. Вот скриншот мониторинга емкости кластера (было использовано 133,01 ГБ, а стало – 133,73 ГБ):

Конечно, это потому, что на ВМ ничего особо и не устанавливалось.

По этому принципу можно разворачивать все виртуальные машины хранилища данных. О лимитах на их количество, а также о других ограничениях можно почитать в разделе «О кластере vSAN» статьи «Дизайн и разворот vSAN 7.0U1».

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

Предположим, у нас уже есть развернутая в хранилище vSAN виртуальная машина с заданной политикой. Но, по прошествии времени пришло понимание, что она не устраивает и нуждается в изменении. Это несложно сделать, если зайти на вкладку «Configure» этой машины в инвентаре vCenter и выбрать «Policies». Покажется список дисков с примененной существующей политикой, а вверху будет кнопочка «EDIT VM STORAGE POLICIES»:

Если ее нажать, попадем в окно редактирования, где нужно из выпадающего меню выбрать другую политику, после чего нажать «ОК»:

Теперь в списке «Policies» этой виртуальной машины политика будет другой.

Клонирование виртуальной машины

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

Перед клонированием ВМ следует убедиться, что она включена, а затем предпринять такие действия:

  • Заходим на виртуальную машину и сверху в выпадающем меню «Actions» находим пункт «Clone» – «Clone to Virtual Machine…»:

  • Открывается окно помощника, в котором в первом пункте меню «Select a name and a folder» назначается новое имя для склонированной машины, а также ее папка:

  • «Select a compute resource». Выбираем кластер vSAN:

  • «Select storage». Здесь демонстрируются два блока – соответствующий родительскому дата-сторадж и несоответствующий. Мы хотим разместить наш клон там же, где родительская машина, поэтому выбираем объект из первого:

  • «Select clone options». Если не нужно ничего экзотического и кардинально отличного от свойств родительской ВМ, оставляем все по дефолту;
  • «Ready to complete». Проверяем сделанные назначения и заканчиваем клонирование по кнопке «Finish».

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

Применение vMotion в vSAN

Не новички в администрировании vSphere давно знакомы с таким незаменимым решением, как vMotion. Не прерывающую работу виртуальных машин, нивелирующую простои, как таковые, функцию миграции «на живую» поистине переоценить сложно:

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

В статьях «Инсталляция обновления VMware vSAN 7.0U1» и «Дизайн и разворот vSAN 7.0U1» немного упоминалось о сети vMotion. Резюмируя и дополняя эту информацию отметим следующие опорные моменты:

  • Сеть vMotion должна отличаться от сети vSAN (для оптимизации производительности);
  • Сервис vMotion должен быть включен и на исходном хосте, и на целевом для миграции в настройках порта VMkernel:

  • Типы IP-адресации целевого хоста и исходного совпадают;
  • Если миграция производится на длинные дистанции, виртуальные машины должны быть подключены к L2-сети, при этом сеть vMotion должна быть подключена на уровне L3, а задержка между хостами не должна превышать 150мс, шифрование включается по желанию.

Попробуем смигрировать ВМ с хоста на хост, а также перенести ее из хранилища (если это не vSAN) в vSAN, и наоборот.

Миграция ВМ в vSAN между хостами

Для начала уточняем, на каком хосте находится подлежащая переносу виртуальная машина. Это можно сделать на вкладке «Summary» ВМ:

Затем пошагово проходим процедуру:

  • В «Actions» вверху ищем в выпадающем меню «Migrate…»:

  • «Select a migration type». Выбирается тип миграции:
    • сменить вычислительный ресурс для виртуальной машины на другой хост или кластер,
    • сменить хранилище на совместимое,
    • сменить и вычислительный ресурс, и хранилище.

Нам нужно именно сменить хост, поэтому останавливаемся на первом варианте:

  • «Select a compute resource». В табличках этого пункта предложено выбрать хост, кластер, ресурс-пул или vApp, и если кликнуть на определенный вид ресурса, ниже помощник продемонстрирует, что к нему относится и что может «переехать» в данном случае:

  • «Select networks». Здесь выбираем целевой хост:

  • «Select vMotion priority». Назначается степень приоритетности работы vMotion. Крайне рекомендовано предпочитать первый пункт (по умолчанию):

  • «Ready to complete». Проверяем свой выбор и запускаем миграцию кнопочкой «Finish».

Чтобы проверить, удачно ли смигрировали машину, заходим снова на ее вкладку «Summary» и проверяем, поменялся ли внизу адрес хоста:

Миграция виртуальной машины с другого типа хранилища на vSAN, и наоборот

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

Действия практически аналогичны тому, что было описано выше в «Миграция ВМ в vSAN между хостами», но в первом пункте «Select a migration type» выбираем вторую возможность «Change storage only»:

Далее назначаем хранилище в «Select datastore» (целевое):

Проверяем все в «Ready to complete» и инициируем миграцию кнопкой «Finish».

После успешной миграции в «Summary» виртуальной машины увидим информацию:

Обратная операция выполняется точно так же, только в качестве целевого датастора выбирается vSAN.

Снятие снэпшота ВМ

Функция снятия снэпшотов виртуальных машин – моментальных снимков состояния объекта среды (конфигурации ВМ, состояния памяти, виртуальных дисков) – абсолютно нативна для vSphere и широко используема на практике.

Важно! Снэпшот – это не бэкап. VMware не рекомендует применять снэпшоты в стратегии бэкапирования.

Она полезна, когда, к примеру, не так пошел апгрейд или выползли ошибки при установке патчей. Благодаря ей машину всегда можно вернуть в состояние, предшествующее инициации этих процедур. С ней нет нужды создавать множество виртуальных машин, чтобы протестировать на них нечто – можно просто раз за разом откатываться на исходный вариант снэпшота и пробовать следующее.

В организации снэпшотов используется иерархическая структура по принципу «родительский – дочерний» – своеобразное дерево сохраненных состояний, гуляя по которому можно всегда вернуться в исходную точку:

Виртуальные машины из vSAN можно снэпшотить очень просто – точно так же, как и любые другие. Причем, в отличии от описанной выше процедуры клонирования, совершенно нет разницы, включена ВМ или выключена. Никакого дополнительного инструментария устанавливать не требуется. Пробежимся по основным пунктам процедуры:

  • Ищем в инвентаре vCenter подлежащую снэпшотированию ВМ и в верхнем меню «Actions» выбираем пункт «Snapshots» – «Take snapshot…»:

  • В появившемся окне задаем название для этого снэпшота и опционально – его описание:

После нажатия кнопки «ОК» система сообщит, что снэпшот был успешно снят.

Когда у нас есть в наличии хотя бы один готовый снэпшот (для него, кстати, предусмотрен индивидуальный разреженный формат «.vsanSparse», для которого характерно длительное хранение снимков и полный лимит в 32 штуки), его меню в «Actions» предложит несколько дополнительных функций. Например, можно быстро вернуться к самому последнему сделанному или же управлять любым из сохраненных:

Справа внизу дерева снэпшотов, как мы видим, есть кнопки для удаления всех сделанных для этой машины снимков комплексом («DELETE ALL»), удаления («DELETE») и восстановления состояния ВМ («REVERT TO»):

Справа же идентификационная информация, содержащая все отметки, которые мы делали при его создании, включая опцию снятия состояния памяти машины и гостевой файловой системы, а также занимаемый им размер. Эти параметры, кстати, можно отредактировать кнопкой «Edit» под ними.

Чтобы узнать дельту объекта снэпшот, в пользовательском интерфейсе следует зайти в кластер vSAN, после чего выбрать вкладку «Monitor», в правом меню найти блок «vSAN» и щелкнуть на «Virtual Objects»:

Важно! Вовремя удаляйте все снэпшоты с дисков виртуальной машины. Хранение более двух недель по best practice считается неадекватным.

Файловая служба vSAN

Родная файловая служба vSAN упрощает управление хранилищем, что помогает снизить зависимость от существующих решений. С недавних пор «семерка» поддерживает NFS v3 и v4.1 во всем многообразии их использования. Включение этих служб аналогично тому, как это делается для других кластерных служб, вроде дедупликации, компрессии, шифрования и iSCSI. И при этом доступ к общим файловым ресурсам предоставляется непосредственно из пользовательского интерфейса vCenter и получать его могут не только ВМ, но и контейнеры:

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

Включение файловой службы vSAN

  • В разделе «Configure» секции vSAN ищем в левой панели «Services» и в строке «File Service» нажимаем на «Enable»:

  • Откроется мастер-помощник конфигурирования, в пункте «Introduction» которого нас знакомят с возможностями файловой службы и предупреждают о вышеупомянутой информации, которую необходимо собрать заранее. По кнопке «Next» переходим далее:

  • «File service Agent». Выбор из автоматической загрузки агента файлового сервера и ручного метода (последний актуален только при отсутствии интернета). Обязательно поставить галочку на «Trust the certificate»:

«Next»;

  • «Domain». Выбираем имя домена и заносим все данные о названии файловой службы, DNS-сервера и DNS-suffix, после чего жмем «Next»;
  • «Networking». Здесь из выпадающего списка выбирается соответствующая сеть, в которой и будут разворачиваться агенты файловой службы и откуда можно достучаться до расшаренных ресурсов хранилища данных. Также прописывается маска подсети и шлюз:

  • «IP Pool». Заполняется основной IP-адрес для доступа к общим ресурсам NFS v4.1, а также пул IP-адресов, которыми станут пользоваться агенты файлового сервера. Нужно, чтобы каждому хосту соответствовал свой IP-адрес, связанный с DNS-именем. Если адреса создавались в непрерывном диапазоне, мастер-помощник может их заполнить автоматически:

После ввода всех адресов следует нажать кнопку «Lookup DNS» для автоматического заполнения соответствующими именами DNS;

  • «Review». Проверяем, все дли правильно задали и начинаем разворот по кнопке «Finish».

В результате получим новые созданные агенты файловых сервисов (под каждый хост – свой) и сможем увидеть их, если расширим список ESX-агентов.

Расшаривание файловых ресурсов

Как только файловые службы будут включены, в «vSAN» раздела «Configuration» появится новое меню «File Share Services». Если в них зайти и нажать на кнопку «Add», стартует мастер-помощник «Create file share»:

  • В первом его пункте «General» нужно назвать наш будущий общий файловый ресурс, выбрать для него политику хранения, потолок использования ресурсов, а также назначить квоты, после которых в UI «File Services Shares» в строке этого ресурса полоса заполнения станет красного цвета и хелс-чек выдаст предупреждение:

  • «Net access control». Здесь задается сеть (диапазон сетей), которая будет иметь доступ к расшариваемым ресурсам – можно вообще закрыть доступ, позволить его с любого IP, либо же выбрать пользовательские значения, введя их под третьей строкой и выбрав тип разрешения:

  • «Review». Как обычно, все проверяем и инициируем создание общего доступа к файловым ресурсам кнопкой «Finish».

Если все проделано правильно, в разделе «File Services Shares» появится запись, вида:

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

Подмонтирование общего файлового ресурса

В пользовательском интерфейсе «File Services Shares» нажимаем на последнюю кнопку верхнего меню «Copy URL» и в выпадающем списке выбираем нужный тип файловой системы, чтобы получить сам URL:

Далее поступаем, в зависимости от особенностей гостевой операционной системы машины, на которую нам и нужно подмонтировать новосозданный расшаренный файловый ресурс. Возьмем самый сложный случай: например, у нас ОС Photon. Тогда в командной строке системы вводим:

mount 10.159.23.90:/app-share /mnt/app-share

(После «mount» подставляется скопированный адрес.)

Проверить удачность подмонтирования можно командой:

mount | grep app-share

где «app-share» – заданное название расшаренной файловой службы.

Так как мы скопировали URL для NFS v4.1, у нас высветится такое сообщение:

type nfs4 (rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=10.159.24.19,local_lock=none,addr=10.159.23.90)

Масштабирование хранилища vSAN

О начальном выборе размера и составе архитектуры vSAN некоторые базовые вещи упоминались в статье «Дизайн и разворот vSAN 7.0U1». Теперь же обсудим эту тему в самых, что ни на есть, деталях.

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

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

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

Замечания по увеличению кэша и емкости на базе существующих нод

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

В идеале, изначально задать отношение кэш-памяти к емкости с хорошим запасом. Но, затем в процессе наращивания объемов емкости постоянно необходимо держать в голове проверку размера кэша. Более того, следует помнить, что, когда ситуация достигнет своей критической точки, придется срочно менять текущее кэш-устройство на более мощное, а это затратно, если vSAN уже эксплуатируется.

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

Масштабирование vSAN путем добавления хоста в кластер

Перед тем, как приступить к горизонтальному масштабированию vSAN, проверяем, по традиции, свободную емкость (о том, как это выяснить, писалось выше в подразделе «Создание новой виртуальной машины в vSAN»):

Хост у нас, конечно же, уже создан и подключен к сети vSAN. Далее поступаем так:

  • Находим в инвентаре vCenter новый хост, кликаем правой кнопкой по нему и в выпавшем меню отыскиваем пункт «Move To…»:

  • Далее в окне нужно будет выбрать нужный кластер – именно в него мы и будем переносить новый хост;
  • Теперь нас подвели к выбору ресурс-пулов для процедуры. Здесь можно без зазрений совести оставлять все по дефолту, так как это означает, что будет задействован корневой пул:

Кнопка «ОК» запустит процесс переноса, результат которого можно проверить в разделе «Hosts and Clusters» дата-центра:

Очевидно, что емкость хранилища никак не изменилась. Это потому, что мы еще не добавили ни одного диска на этот хост. Группы дисков в новодобавленный хост вносить придется вручную, зайдя на кластер и выбрав в левой панели «Disk Management», после чего откроется список подключенных к хостам дисков, в верхней части которого есть соответствующая пиктограмма:

Дальнейшее аналогично тому, что предлагалось сделать в разделе «Создание кластера vSAN вручную» материала «Дизайн и разворот vSAN 7.0U1».

Когда все будет готово, сведения о емкости изменятся:

Управление vSAN и простейший функционал

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

Maintenance Mode (ММ)

В режиме техобслуживания хоста выполняются очень многие задачи по управлению виртуальным хранилищем, а также переконфигурирование. Перед его погружением в режим maintenance следует выяснить, на каком именно хосте находится ВМ – это показывается во вкладке «Summary» машины:

Затем нужно убедиться, что все компоненты группы дисков расположены на том же хосте. Для этого заходим на кластер vSAN и в разделе «Monitor» выбираем «Virtual Objects», где ищем интересующую нас виртуальную машину, после чего кликаем на «View Placement Details». Если поставить галочку в «Group components by host placement», список ниже продемонстрирует, на каком хосте сейчас находится каждый объект:

Если все хорошо, и все нуждающиеся в применении каких-то действий в режиме техобслуживания компоненты собраны вместе, переходим в список хостов, находим там нашего героя и кликаем на него правой кнопкой мыши. В появившемся меню ищем «Maintenance Mode» – «Enter Maintenance Mode»:

После этого вылетит окно, вида:

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

  • «Full data migration»,
  • «Ensure accessibility»,
  • «No data migration».

Подробно об этих режимах писалось в статье «Инсталляция обновления VMware vSAN 7.0U1».

Нам сейчас важно, чтобы данные на ВМ были доступны, поэтому останавливаемся на среднем пункте. В результате получим предупреждение:

Так как у нас полностью автоматизированный DRS-кластер, наши машинки смигрируются самостоятельно после нажатия кнопки «ОК».

Итак, теперь, когда хост ушел на maintenance, можно приступить к проверке состояния. Если мы зайдем на него, в левой панели выберем наш кластер и под ним – «Physical disk placement», список справа покажет все компоненты дисков с отметкой о статусе (все, что «Active» – это активно-активные части дисков, и они доступны, так как мы это разрешили, выбрав ранее «Ensure accessibility», а вот хосты-свидетели, напротив, – в статусе «Absent», так как они на локальном хранилище):

Вывести хост из режима техобслуживания можно, снова выбрав его в инвентаре, кликнув правой кнопкой и в «Maintenance Mode» нажав на «Exit Maintenance Mode». Либо же подождать 60 минут (значение «vsan.ClomdRepairDelay» по дефолту) для автоматической перестройки компонентов. После этого все, что «Absent» снова станет «Active».

Выбор «Full data migration» при выведении хоста в окно техобслуживания позволит иметь доступ и к его базовым компонентам, и к свидетелю. Однако не прямо в том месте, где они должны находиться изначально, а где-то еще в кластере.

Важно! Такое доступно исключительно для кластеров с «NumberOfFailuresToTolerate = 1» и при наличии четырех и более хостов в нем.

Если попытаться отправить сразу несколько хостов в ММ, или же выводить один, пока другой еще не вернулся, система выдаст предупреждение, чтобы избежать сбоев. Ведь в таких ситуациях может как раз происходить ресинхронизация, могут мигрировать данные и находится в процессе другие обычные для этого режима действия, а результатом станет недоступность объектов vSAN и другие проблемы:

Управление аппаратными устройствами хранилища

Прямо из веб-интерфейса виртуальной среды можно управлять аппаратной частью кластера vSAN, а именно:

  • Добавлять в дисковую группу хоста или удалять из нее диски (в том числе дисковую группу общего пользования);
  • Маркировать устройства как локальные (если в наличии внешние SAS, vSAN их опознает как удаленные, и обозначать их локальными приходится вручную);
  • Удалить информацию о партициях устройства (если этого не сделать для девайсов, которые ранее где-то использовались и несут на себе остаточную информацию о разделах, vSAN попросту не разрешит их использовать у себя);
  • Маркировать устройства как флэш- или хард-диск (если автоматически не идентифицируются);
  • Включать или выключать локаторы LED для определения местоположения компонентов хранилища:

Кое-что из этого списка можно делать и напрямую из управления кластером vSAN, предварительно, естественно, убедившись, что участвующие в этом хосты погрузились в ММ.

Удаление и эвакуация диска

Сначала займемся эвакуацией. Заходим на вкладку «Configure» кластера vSAN в выбираем на левой панели «Disk Management». Справа будет список хостов, в котором находим эвакуируемую группу дисков на одном из них:

Важно! Устройства этой дисковой группы лучше переписать себе в блокнот, так как потом придется ее перестроить.

Под ней будет маленький блок с иконками действий, вида:

Добавить диск в выбранную дисковую группу
Просмотреть результат ожидаемой эвакуации диска или дисковой группы
Удалить (и опционально эвакуировать) данные из диска в дисковой группе
Включить LED-индикатор локации  выбранного диска
Выключить LED-индикатор локации  выбранного диска
Важно! Эти кнопки предоставляются утилитой. Например, для НР-контроллеров она называется «hpssacli», и ее можно, по желанию, включать и выключать. Доступность такой возможности, как таковой, нужно проверить в документации вендора оборудования. Если у вас LSI-контроллеры, устанавливать отдельно подобные кнопки не нужно, так как весь аналогичный функционал и так будет на борту ESXi.

Нам нужна третья сверху кнопка (выделенная красным на предыдущем скриншоте). После клика на нее выскочит окно, в котором можно выбрать опцию «Evacuate all data to other hosts» и нажать «Delete»:

По завершению этой операции удаленный диск более не будет доступен в списке дисковой группы.

Добавление удаленной дисковой группы

Чтобы вернуть удаленную дисковую группу, следует вручную добавить ее на хост по методу, описанному в подразделе «Масштабирование vSAN путем добавления хоста в кластер» выше. Если все делается правильно, увидим окно:

И по кнопке «CREATE» наша дисковая группа вновь воссоздастся на указанном хосте.

Миграция гибридного кластера в all-flash vSAN кластер

Иногда в рамках совершенствования среды требуется перенести гибридный кластер в all-flash. Например, если хочется поработать с дедупликацией и компрессией, улучшить производительность своего хранилища.

Важно! Реализуемо исключительно в рамках VCG.

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

  1. Заходим в веб-клиенте vSphere в кластер vSAN;
  2. Удаляем гибридную дисковую группу для каждого хоста в кластере (на вкладке «Configure» в секции vSAN выбираем «Disk Management», кликаем в окне «Disk Groups» на нужную группу и жмем на иконку «Remove the disk group», но в следующем окне выбираем «Full data migration», после чего соглашаемся с удалением);
  3. Удаляем физические HDD-диски с хоста;
  4. Добавляем на него флэш-устройства (предварительно проверить, не осталось ли там старых партиций);
  5. Создаем all-flash дисковые группы на каждом устройстве.

После завершения миграции необходимо проверить, достаточно ли емкости в кластере, даже при не включенных дедупликации и компрессии или RAID-5/6. Если без них не обойтись, стоит рассмотреть перенос некоторых ВМ за пределы кластера, пока инициированная миграция дисков не будет завершена.

Важно! Лучше заменять гибридные дисковые группы all-flash-аналогами такой же, либо большей емкости.

Безопасное стирание данных на декомиссованном устройстве хранения vSAN

Удаление диска, очевидно, никаким образом не стирает с него данные. А чтобы выполнить вездесущие требования NIST и подготовить освободившийся диск к дальнейшему использованию, или же просто грамотно и безопасно вывести его из эксплуатации, следует выполнить ряд важных действий по его т. н. «secure wipe».

В vSAN 7.0U1 предложен новый метод для этого с использованием API или PowerCLI. Сегодня мы поговорим о последнем, как наиболее удобном для администраторов среды. Оговоримся, что дальнейшие шаги возможны, исключительно в случае выбора опции «Evacuate all data» при удалении диска из группы.

Важно! Безопасное удаление занимает какое-то количество времени. Проводить нужно в окне техобслуживания.

Список команд PowerCLI для безопасного удаления данных с диска:

  • «Wipe-Disk –Disk <Disk[]> -RunAsync» – выдает список дисков для очистки;
  • «Query-Wipe-Status <Disk[]>» – выдает список дисков, возвращая список статусов очищаемого диска;
  • «Abort-Wipe-Disk <Disk[]>» – выдает список дисков для отмены их очистки и возвращения статуса; 

Вот пример практического использования этих команд в живой среде:

Важно! На некоторых старых поколениях оборудования эта возможность не поддерживается (применимо только к флэш-устройствам NVMe, SATA и SAS). Совместимость с ней по каждой конкретной модели диска проверяем по VCG.

Lifecyle Management

Lifecyle Management – понятие не новое для администраторов виртуальных сред. В vSphere без него никуда, особенно если речь идет о производственных системах. По счастью VMware разработала встроенное в продукт комплексное ПО, благодаря которому обновление и управление жизненным циклом среды стало гораздо удобнее за счет автоматизации и friendly-интерфейса.

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

vSAN vLCM способен предложить все то же самое, что и для других кластеров. И если у нас закачено требуемое обновление, он может применить его, как только к конкретному кластеру, так и ко всей HCI в целом. Кроме того, т. н. vLCM Desired Image включает в себя не только новую версию ESXi, но и аддоны вендора, а также обновления управляющих микропрограмм и драйверов.

Важно! Аддоны драйверов и микропрограмм не распространяются через официальный депозиторий обновлений VMware (для vSAN в составе vSphere это, к примеру:
https://my.vmware.com/web/vmware/downloads/info/slug/datacenter_cloud_infrastructure/vmware_vsan/7_0#product_downloads).
Их можно найти в специальном хранилище конкретного поставщика аппаратного оборудования. Доступ к его контенту можно получить, установив плагин менеджера поддержки hardware в качестве расширения существующего vCenter Server. Выбор конкретных аддонов и методы их интеграции в виртуальную среду нужно уточнять у вендора.

В статье «Инсталляция обновления VMware vSAN 7.0U1» подробно говорилось о том, как осуществить подготовку к апдейту нашего хранилища данных, а также рассказывалось о некоторых отличных от vLCM методах его проведения. Сейчас же остановимся конкретно на Lifecyle Management, предварительно скачав его образ из официального хранилища обновлений (см. выше):

  • Находим в «Updates» – «Hosts» нашего новосозданного по данным в статье «Дизайн и разворот vSAN 7.0U1» рекомендациям кластера vSAN пункт «Baselines» и нажимаем на кнопку «MANAGE WITH A SINGLE IMAGE»:

  • Изменившееся окно напомнит о подготовительных действиях (все это рассказывалось в статье об инсталляции обновления) и предложит две кнопки на выбор:
    • «Setup image»,
    • «Import image».

Так как у нас образ уже закачен, жмем на первую:

  • Step 1. Далее мастер-обновлений предложит выбрать искомую версию ESXi и опционально здесь же можно отметить релевантные аддоны вендора, а также обновления драйверов и микропрограмм. После этого следует нажать на «Validate», чтобы убедиться в совместимости и наличии, а затем и «Save».
  • Step 2. Здесь нужно проверить совместимость предлагаемых обновлений для каждого нуждающегося в них хоста кнопкой вверху справа «Check compliance»:

После этого нажимаем на «Finish image setup» для старта установки обновлений.

Важно! Эта процедура привязывает vLCM к кластеру и отключает любые ранее доступные с vSphere Update Manager (VUM) базовые апдейты и линии обновлений. Процедура необратима.

По завершению этих действий vLCM станет постоянно самостоятельно проверять статус vSAN и устанавливать для него обновления, если потребуется. Однако это будет касаться исключительно апдейтов ESXi, а для полной валидности нам необходимо настроить репозитории на получение драйверов и микропрограмм, в числе прочего, с Hardware Support Manager (HSM) вендора.

Использование HSM в vLCM

В качестве примера рассмотрим интеграцию OpenManage от Dell в VMware vCenter. Привязку и конфигурирование самого делловского HSM подробно изучать смысла нет, так как эти шаги сильно разнятся от вендора к вендору. Но, генеральная линия поведения будет состоять в следующем:

  • Развернуть HSM-appliance (индивидуальная схема);
  • Зарегистрировать плагин HSM в vCenter;
  • Сконфигурировать доступ к хостам в профиле кластера;
  • Сконфигурировать профиль репозитория (места, где vLCM будет получать новые драйвера и микропрограммы).

Установить же аддоны драйверов и микропрограмм с помощью vLCM можно следующим образом:

  • Заходим в vCenter и выбираем там в «Cluster» – «Updates»;
  • Кликаем на правой панели на «Image» и нажимаем кнопку справа сверху «Edit»:

  • Здесь нажимаем на пиктограмму «ручки»:

  • В появившемся окне выбираем желаемый HSM (предварительно созданный в профиле HSM аддон драйвера и микропрограмм) и подтверждаем все кнопкой «Select» внизу:

  • Далее необходимо проверить соответствие указанного аддона кнопкой «Check compliance» вот здесь:

Оптимизация пространства в vSAN

С целью повышения эффективности пространства в vSAN в плане потребления емкости, роста производительности и доступности применяются такие классы функций:

  • дедупликация и компрессия,
  • новое поколение файлов подкачки.

На первых двух функциях подробно остановимся ниже. Сейчас же уделим внимание swap-файлу vSAN.

Этот файл пользуется той же политикой хранилища, что и объект vSAN, к которому он прикреплен. И размер swap-файла, глобально, рассчитывается по формуле:

SwapFileSize = VMMemorySize – MemoryReservationSize.

Важно! При мирроринге соответствующие значения удваиваются.

Логично, что в огромных средах размер файлов подкачки занимает серьезное место.

Он создается в момент включения ВМ, и, если хост исчерпает свою физическую память, вместо нее используется swap. Начиная с версии 6.7, своп-объекты по умолчанию создаются thin-provision. В advanced-настройках хоста рекомендуется назначать SwapThickProvisionedDisabled для vSAN для обеспечения дополнительной экономии места:

Дедупликация и компрессия

Для all-flash-конфигураций предусмотрены функции дедупликации и компрессии, и все необходимые для их грамотного использования теоретические знания можно почерпнуть в статье «Дизайн и разворот vSAN 7.0U1». Там было рассказано, и как подключить их опционал непосредственно при создании кластера. Но, если это по какой-то причине не было сделано сразу (а затем возникла необходимость), или же в процессе функции зачем-то отключались, обратно их включить совсем не сложно:

  • Заходим на вкладку «Configure» нашего кластера и в секции «vSAN» кликаем на раздел «Services» под ним. Ищем в таблице справа «Deduplication and compression» и нажимаем напротив этой строки кнопочку «Edit»:

  • Откроется окошко, в котором надо соответствующий ползунок перевести в активное состояние:

После нажатия кнопки «Apply» какое-то время процесс будет в прогрессе.

Чтобы проверить работу дедупликации и компрессии, загрузим HCIbench и с его помощью создадим 32 идентичные ВМ. Зафиксируем перед этим значения емкости, чтобы потом сравнить с состоянием после:

Новые 32 машины будут содержать каждая по два 100 ГБ VMDK:

После этого снова заглянем в «Monitor» – «Capacity» нашего кластера:

Как мы видим, соотношение экономии пространства подросло до 4.36х. Такое впечатляющее значение достигнуто, преимущественно, по причине пустых дисков в составе. Теперь попробуем создать FIO-профиль со 100%-записями по всему VMDK, половина из которых будет рандомной:

Проверяем емкость:

Очевидно, что экономия снизилась до 3.2х.

Теперь попробуем использовать все рандомные записи и установим резервацию пространства для объекта на уровне 100%, отредактировав политику хранения:

Теперь в данных по емкости будет такое:

Вообще же эффективность работы функций дедупликации и компрессии удобно смотреть в истории сохранений DD&C кластера. Если используете vRealize Operations, нужно просто зайти на панель «vSAN operations» – там будет целый список метрик, в числе которых и те, что связаны с DD&C. Выбрав какую-то из них, например, «DD&C ratio», получим соответствующее представление:

Если с vRealize Operations не работаете, просто заходим на «Monitor» – «Capacity» и кликаем на вкладку «History». После этого откроется интерфейс, в котором можно задавать просмотр множества интересных вещей, менять форму отображения, период и т.д. В итоге получим что-то вроде такого:

Важно! Некоторые форматы кластеров не обладают достаточным количеством ресурсов для полной эвакуации дисков, которая требуется, когда мы меняет формат дисков с целью применить на них дедупликацию и компрессию. Например, это трех-нодовый кластер без запаса для эвакуации реплики или свидетеля при сохранении полной защиты, или же четырех-нодовый кластер с уже имеющимися объектами RAID-5. В этих случаях включить DD&C помогает галочка на параметре «Allow Reduced Redundancy».

RAID-5/RAID-6 Erasure Coding

Применение кодирования со стиранием RAID-5, вместо двойного или тройного расхода при RAID-1 (FTT = 1/2), задействует только 33% дополнительного хранилища. Что же касается RAID-6, речь идет лишь о 50% превышении.

Для включения RAID-5 (RAID-6) следует завести минимум четыре (шесть) хоста с конфигурацией 3 + 1 (4 + 2). Эти уровни кодирования доступны через управление политиками (SPBM) и тоже вносят свой вклад в экономию места в хранилище. О том, как менять атрибуты в политиках рассказывалось выше в соответствующем разделе.

Автоматическая ребалансировка в кластере vSAN

В статье «Дизайн и разворот vSAN 7.0U1» мы говорили о том, как важно добиться баланса в кластере vSAN. Сама природа распределенного виртуального хранилища свидетельствует о том, что это решение самостоятельно управляет сегрегацией нагрузок среди узлов-участников, поэтому уже в процессе использования оно станет пытаться проводить корректировки в соответствии с произошедшими переменами в архитектуре.

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

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

Ребалансировка в vSAN бывает двух типов:

  • Реактивная – в момент обнаружения устройства, достигшего 80% порога использования емкости, хранилище попробует отправить часть данных на другие менее нагруженные устройства. Эта функция автоматизированная и нерегулируемая;
  • Проактивная – vSAN оценивает использование емкости по каждому объекту, и, если какой-то из них потребляет непропорционально большое ее количество по сравнению с потреблением сотоварищами (разница должна превышать 30%, по умолчанию), тут же перебалансирует нагрузки.

Безусловно, все изменения в балансе происходят в соответствии с заданными политиками хранения. До версии 6.7U3 второй тип означал личное вмешательство администратора. Однако теперь эта функция аналогично стала автоматической.

Но, ее можно сделать доступной или недоступной (последнее, конечно же, не рекомендуется, разве что вы работаете с очень маленькой средой и в состоянии постоянно мониторить ее статус) прямо в веб-клиенте vSphere, зайдя на vCenter во вкладку «Configure» и в левой панели под «vSAN» найдя «Services». Там надо кликнуть на «Advanced options», после чего откроется специальное окно вида:

В нем, как мы видим, помимо выставления таймера восстановления объектов, включения тонкого типа свопа и возможности подстроить систему под особенности больших сред, присутствует специальный ползунок «Automatic Rebalance». Вот его и нужно передвинуть в активную позицию.

После того, как эта опция будет включена, на вкладке мониторинга в соответствующем блоке «vSAN Disk Balance» появится кнопка «Configure Automatic Rebalance»:

и процесс станет автоматическим.

Шифрование

Шифрование в vSAN включается и настраивается на уровне датастораджа, после чего каждый объект хранилища оказывается под надежной защитой в самых разных ситуациях его жизненного цикла. И сейчас мы поговорим о том, как развернуть систему шифрования в своем хранилище данных с нуля, как создать KMS-сервер и подключиться к нему, расскажем о механизме повторного шифрования данных, а также особенностях защиты data-at-rest и data-in-transit.

Добавление KMS в vCenter

Предположим, нам удалось успешно создать экземпляр KMS-сервера/кластера (см. рекомендации «Дизайн и разворот vSAN 7.0U1»). Конкретика процедуры зависит от выбора вендора этого сервера и знакомиться с ней лучше в его документации. Первоначальная его конфигурация выполняется прямо в vCenter Server, в пользовательском интерфейсе vSphere. Сервер KMS следует присоединить к vCenter и установить между ними доверительную связь следующим образом:

  • Заходим на vCenter Server во вкладку «Configure», кликаем в левой панели на «Key Management Servers» и нажимаем кнопку «Add» вверху правее. После этого появится диалоговое окно, вида:

Там необходимо оставить первую строчку «Create new cluster» без изменений, а ниже придумать имя нового KMS-кластера, прописать все его сетевые характеристики и ввести пользовательскую аутентификацию для будущей с ним работы (опционально);

  • Обозначаем связь с новосозданным сервером как доверенную (согласно инструкциям вендора). В большинстве случаев нужно просто левее кнопки «ADD» зайти в «Establish trust» и нажать ниже данных по этому серверу кнопку «Make KMS trust vCenter»:

Успешность конфигурации и правильность статуса подключения KMS будет выглядеть так:

Включение/выключение шифрования в vSAN

После того, как наш KMS создан и настроен, включить шифрование в vSAN можно очень быстро (если речь о новом кластере vSAN, как активировать в нем шифрование в процессе создания было показано в статье «Дизайн и разворот vSAN 7.0U1»). Очевидно, что это относится к data-at-rest модели. Заходим на кластер во вкладку «Configure», ищем в левой панели под «vSAN» – «Services» и в строке «Encryption» нажимаем на «Edit»:

Переводим ползунок в активное состояние и выбираем назначенный кластер KMS. «Apply».

На скриншоте можно рассмотреть опцию с местом для галочки «Erase disks before use» – это очень важная с точки зрения понимания сути шифрования и безопасности вещь, поэтому вкратце с ней познакомимся. Если у нас есть старый диск в составе кластера, и мы включаем на нем шифрование, защищены будут только новозаписанные данные. Однако, как мы помним, в процессе шифрования vSAN переформатирует диски, временно переписывая их содержимое куда-то внутри кластера. Соответственно, вместе с зашифрованными впоследствии данными по нему пустятся «гулять» и вещи абсолютно незащищенные. Более того, через них злоумышленник может попробовать достучаться и до защищенных. Словом, позволить себе не ставить эту галочку можно только в том случае, если мы создаем кластер с абсолютно нулевыми дисками, либо же добавляем в уже существующий старые, подвергнутые процедуре безопасного стирания, описанной выше.

Второе интересное там место – опция «Allow reduced redundancy». Разрешить снизить избыточность бывает полезно в случае, когда после шифрования и, соответственно, перемещения данных для удаления и переформатирования группы дисков, есть опасения, что для обратной операции может не хватить ресурсов. Если строим систему с нуля этой опцией можно пренебречь.

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

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

Повторное шифрование

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

Функция Encryption Rekey встроена по умолчанию в шифрование vSAN. Ее суть в доступности возможности генерации новых ключей по одной из двух моделей:

  • shallow rekey,
  • deep rekey.

Первый – высокоуровневое повторное шифрование, когда ключ для данных пакуется с помощью нового ключа. Deep rekey – это полное перешифрование всех данных, и активируется оно галочкой в «Also re-encrypt all data on the storage using the new keys» (см. скриншот ниже). Последнее занимает много времени и не лучшим образом сказывается на производительности.

Важно! Перенести процесс генерации новых ключей на другой сервер KMS при deep rekey невозможно. Однако в shallow rekey можно с легкостью распределить нагрузки.

После включения шифрования в кластере vSAN слева от кнопки «Edit» в строке «Encryption» появится кнопка «Generate new encryption keys» – это активация shallow rekey. Если ее нажать, увидим такое окно:

Включение шифрования data-in-transit в vSAN

Best practice – применять обе модели шифрования в vSAN: и data-at-rest, и data-in-transit. Такая политика называется сквозным шифрованием и обеспечивает максимальную защиту данных в виртуальной среде из всех возможных. Data-in-transit использует тот же криптографический модуль, что и шифрование данных внутри хранилища, и включается/выключается оно аналогично на уровне кластера. При этом, как нами уже отмечалось в статье «Дизайн и разворот vSAN 7.0U1», внешний KMS-кластер защита информации в пути не применяет, опираясь на генерацию собственных ключей хостом.

Чтобы включить шифрование data-in-transit в vSAN-кластере поступаем так:

  1. Заходим на вкладку «Configure» кластера и в левой панели в секции «vSAN» кликаем под ним на «Services». В строке «Data-In-Transit encryption» нажимаем на кнопку «Edit»;
  2. Включаем «Data-In-Transit encryption» и обозначаем интервал повторного шифрования;
  3. Соглашаемся с настройкой по кнопке «Apply».

Мониторинг vSAN

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

Для помощи нам в этом деле vSAN предлагает многофункциональный и бесподобно информативный мониторинг, который, в целом, дает представление о:

  • производительности,
  • общем состоянии «здоровья» хранилища,
  • текущих операциях перебалансировки и ресинхронизации внутри кластера,
  • расширенных возможностях благодаря встроенным панелям vROPS.

Там будут отражены все предупреждения и ошибки, а также другая диагностическая информация, полезная в troubleshooting и управлении кластером. Пробежимся по главным разделам мониторинга.

Общее состояние кластера (Skyline Health)

Хелс-чеком здесь заправляет утилита «vSAN Skyline Health», которая, по сути, является консолидированной проверкой работоспособности кластера, в т. ч. в отношении его отказоустойчивости и производительности. Чтобы его провести, нужно из инвентаря vCenter зайти на интересующий объект кластера, затем на вкладке «Monitor» в секции «vSAN» нажать на «Skyline Health»:

Здесь могут отражаться следующие нехорошие сигналы:

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

Расшифруем значки, которые нам может выдать в качестве индикации мониторинг:

Active Здоровы и функционируют верно
Reconfiguring В процессе применения измененных политик хранилища
Absent Недоступны из-за сбоя
Active – stale Недоступны из-за синхронизации с другими компонентами этого же объекта vSAN
Degraded Невозвращаемые по причине обнаруженного критического отказа объекты

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

Следующими в очередности идут алерты о совместимости. vSAN постоянно и в автоматическом режиме обращается к VCG, поэтому особенное внимание этому моменту нужно уделять после произведенных апдейтов, замены оборудования или применения нового ПО.

Несогласованность конфигурации – это, как правило, все те ошибки, которые мы допускаем в процессе создания и последующего администрирования vSAN. Часто в процессе настройки, разворота объектов машем рукой на предупреждение о несоответствии или откладываем уточнение параметров «на потом», если это позволяют мастера-помощники, но благодаря тому, что наш хелс-чек бдит неустанно, он всегда нам услужливо подскажет, что и где было сделано не так.

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

Емкость

К этому пункту мониторинга, как вы, пожалуй, заметили, мы постоянно обращались на протяжении всего этого материала, проверяя достаточность места на хостах и дисках, отмечая, насколько оптимальнее используется пространство благодаря дедупликации и компрессии, а также во многих других случаях. Напомним, получить эту информацию достаточно просто: нужно зайти на вкладку «Monitor» кластера, найти в левой панели «vSAN» и под ним – «Capacity». Там предоставляется две возможности по кнопкам «Capasity Usage» и «Capasity History» (текущее состояние и история изменений, соответственно):

Ресинхронизация

Еще одним полезным отображением на той же панели мониторинга является «Resyncing Objects». Если кликнуть на этот пункт, система нам продемонстрирует все операции по ресинхронизации или ребалансингу в кластере:

Обычно, рост активности в этом разделе мониторинга указывает на следующие проблемы:

  • сбой хоста или диска в кластере,
  • удаление устройства из кластера,
  • превышение 80%-границы потребления своей емкости диском,
  • реализацию изменения в политиках хранения.

К тому же, к этой информации обязательно стоит обращаться, как только мы собираемся сделать любую операцию в кластере, особенно в отношении переконфигурирования, добавления или удаления мощностей, погружения в режим техобслуживания, установки обновлений. В принципе, все эти случаи нами уже упоминались выше, а также в статье «Дизайн и разворот vSAN 7.0U1», так что повторяться, думается, не стоит.

Производительность

Информация о текущей производительности в доказательстве своей пользы, бесспорно, не нуждается. При этом можно выбирать диаграмму чего конкретно хочется посмотреть: кластера, хостов, ВМ или VMDK, физических дисков – полный список перечислять очень долго. Но, вдруг понадобится что-то специфическое – с ним ознакомиться можно здесь.

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

  1. Зайти на вкладку «Configure»нашего кластера;
  2. Выбрать в секции «vSAN» – «Services»;
  3. В открывшемся списке найти «Performance Service» и нажать «Edit»:

Например, если хочется посмотреть на производительность виртуальных машин, кликаем на кнопочку «VM» сверху и получаем:

Список целевых отображений растет с расширением горизонтов vSAN. Например, на скриншоте выше у нас только две кнопки: «VM» и «Backend». Но если добавить файловую службу, она появится следующей и т.д. Например, вот так:

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

Если хочется узнать больше об администрировании, в частности о перенастройке в работающей среде сети и ее компонентов, о работе с дочерними объектами и более гибком применении политик, глубокой настройке vSAN 7.0U1, а также об управлении растянутыми и двух-нодовыми кластерами, обязательно постарайтесь попасть на соответствующий авторизованный курс VMware.