Многим из вас знакомы продукты компании StarWind, предназначенные для создания отказоустойчивых хранилищ под различные платформы виртуализации. Одним из лидеров отрасли является решение StarWind Virtual SAN, у которого есть множество функций хранения, обеспечения доступности и защиты данных. А сегодня мы поговорим еще об одном бизнесе компании StarWind - программно аппаратных комплексах для специальных задач...
Недавно мы писали о новых возможностях платформы виртуализации VMware vSphere 7 Update 1, а также решения для создания отказоустойчивых хранилищ на базе хостов VMware vSAN 7 Update 1. В статье о vSAN мы упоминали о том, что VMware расширяет службы vSAN Native File Services за счет поддержки протокола SMB. Он интегрирован с Microsoft Active Directory и поддерживает аутентификацию Kerberos. Давайте посмотрим на эти возможности подробнее.
Во-первых, начнем с небольшого обзора от Дункана Эппинга:
Поддержка протокола SMB была введена в vSAN не просто так - целью была поддержка постоянных томов read-write many (RWM) volumes для cloud native applications (то есть современных приложений, исполняемых в контейнерах Docker под управлением Kubernetes). Для доступа поддерживаются хранилища SMB версий v2.1, так и v3 (SMB v1 находится в статусе Deprecated).
SMB-хранилища, создаваемые в vSAN, могут быть доступны из Windows-клиентов (версии 8/2012+) и Mac-клиентов (OS 10 и позднее). Это, совместно с поддержкой Active Directory, делает SMB-хранилища отличным вариантом для:
VDI-сценариев, где пользователи предпочитают перенаправление каталога user/home на выделенную файловую шару.
Файловые ресурсы, обслуживающие различные топологии (например, удаленные офисы или филиалы), могут управляться напрямую из vSAN, без необходимости иметь отдельную ВМ для предоставления общего доступа к папкам.
Файловые шары видны через Windows MMC, где администраторы могут:
Смотреть число клиентских соединений к шаре
Смотреть число открытых файлов
Управлять разрешениями и безопасностью (в стиле NTFS)
Закрывать клиентские соединения
Закрывать открытые файлы
Как мы писали выше, поддерживается и протокол аутентификации Kerberos, который предотвращает доступ NFS-клиентов через более уязвимые методы доступа, такие как auth_sys. vSAN поддерживает 3 модели аутентификации:
KRB5, который проводит только безопасную аутентификацию (только на NFS v4.1)
KRB5I, включая аутентификацию и проверку контрольных сумм
KRB5P, включая аутентификацию, проверку контрольных сумм и шифрование
Надо отметить, что несмотря на то, что VMware vSphere 7 U1 поддерживает кластеры до 64 хостов, службы Native File Services поддерживают доступ до 32 хостов к файловым шарам.
Теперь службы Skyline Health (ранее это называлось "vSAN Health") содержат дополнительные хэлсчеки, включая file server health и share health:
Тут есть три основных типа проверок:
Проверки Infrastructure health checks - развернута ли машина FSVM и демон VDFS, а также есть ли файловая система root на хосте. Если чего-то из этого нет, то проверка показывает красный сигнал.
Проверки File Server Health checks показывают, все ли в порядке с файловым сервером на отдельных хостах, и есть ли там файловая система root. Если что-то из этого не в порядке - показывается красный сигнал.
Проверки Share Health отвечают за статус объектов файловых шар. Если служба протокола не работает для данного объекта, то показывается красный сигнал. Также могут быть оповещения для шар - и тогда будет желтый.
Для файловых шар SMB появился мониторинг производительности в интерфейсе vSAN UI. Можно смотреть за пропускной способностью (throughput), IOPS, задержками (latency) на уровне отдельной шары в реальном времени. Можно увеличивать временное окно просмотра для отдельных метрик. Также эти метрики доступны через API, поэтому такие продукты, как vRealize Operations также будут их использовать.
Доступную емкость SMB-хранилищ можно отслеживать через vSAN Capacity view:
Если вы нажмете на ссылку File shares overview в левом нижнем углу, то сможете открыть просмотр емкости на уровне отдельных шар. На картинке ниже представлен микс из SMB и NFS хранилищ, столбики в Usage/Quota показывают жесткие аппаратные квоты с цветовым кодированием заполненности:
Ну и напоследок небольшой обзор VMware vSAN File Services от VMware:
Компания VMware анонсировала новую версию платформы для создания отказоустойчивых хранилищ для виртуальных машин VMware vSAN 7.0 Update 1. Напомним, что о прошлой версии vSAN 7 мы писали вот тут.
Данная версия vSAN сфокусирована на функциях по обеспечению эффективности датацентра, которые нацелены на увеличения возврата инвестиций в оборудование и программное обеспечение:
Новые возможности VMware vSAN 7 U1 можно разделить на 3 категории:
Эффективность и производительность
Упрощение операций с инфраструктурой хранения
Интеграция с облачной инфраструктурой
1. Технология HCI Mesh
Главная из новых возможностей - это технология VMware HCI Mesh, которая позволяет смонтировать датасторы удаленного кластера vSAN (который выступает в роли "сервера" для кластеров-клиентов):
В такой схеме можно использовать несколько кластеров-клиентов для монтирования датастора, но надо соблюдать правило доступа: не более 64 хостов ESXi к одному датастору, включая хосты серверного кластера.
В такой конфигурации можно делать vMotion виртуальных машин между кластерами vSAN, но хранилище (Storage vMotion) при этом перемещать нельзя.
Также в топологии HCI Mesh можно использовать подход Full Mesh, когда один и тот же кластер выступает и клиентом, и сервером:
Подход Full Mesh позволит вам сбалансировать потребление емкости кластеров хранилищ. При этом есть ограничение: каждый серверный кластер может экспортировать не более 5 датасторов для клиентских кластеров, а каждый клиентский - монтировать не более 5 датасторов серверных кластеров.
Особенности технологии HCI Mesh:
Минимальное число узлов кластера-клиента и кластера-сервера - 2 узла
Технически Compute-only vSAN cluster (без своих датасторов) сейчас работает, но не рекомендуется к использованию и не поддерживается
Поддерживается одновременное использование хранилищ Hybrid (SSD+HDD) и All-Flash одновременно
Небольшой обзор технологии:
2. Поддержка SMB для vSAN Native File Services
VMware расширяет службы vSAN Native File Services за счет поддержки протокола SMB. Он интегрирован с Microsoft Active Directory и поддерживает аутентификацию Kerberos. Таким образом, vSAN теперь поддерживает NFS (версии 3 и 4.1) и SMB.
3. Шифрование vSAN Data-in-Transit Encryption
Теперь в vSAN 7 Update 1 есть возможность шифрования при передаче данных между узлами кластера по протоколу TCP с использованием крипто-модуля FIPS-2. При этом вам не потребуется использовать Key Management Server (KMS).
Также надо отметить, что одновременное использование HCI Mesh и Data-in-Transit Encryption не поддерживается.
4. Техника SSD Secure Erase
В vSAN 7 Update 1 появился надежный способ удаления данных с SSD-дисков. Пока это поддерживается только для оборудования Dell и HPE. Например, это можно будет использовать для готовых серверных узлов vSAN Ready Nodes и комплектов DellEMC VxRail.
5. Общая оптимизация производительности
Как и всегда, VMware проводит работу над улучшением vSAN в контексте производительности. Заявляется, что vSAN 7 Update 1 работает примерно на 30% быстрее при выполнении операций, чем vSAN 6.7 U3 (который до этого был самым производительным).
6. Возможность использования компрессии без дедупликации
Ранее vSAN позволял использовать две этих технологии только вместе, а сейчас можно использовать только сжатие данных, не нагружая вычислительные ресурсы движком дедупликации. Теперь технология работает так:
Дедупликация
На уровне дисковой группы
Работает при дестейджинге данных на capacity tier
Работа с фиксированными блоками 4 КБ
Компрессия
Работает после дедупликации, но до того, как данные дестейджатся
Если блок можно сжать до 2 КБ или менее, то он сжимается
Иначе сохраняется блок 4 КБ
Компрессия работает значительно быстрее дедупликации, поэтому ее отдельно удобно использовать для OLTP-нагрузок.
7. Функция Enhanced durability при выполнении операций обслуживания
Если хост ESXi находится в режиме обслуживания (maintenance mode), то vSAN теперь имеет механизм защиты данных, которые в этот период находятся только в одном экземпляре (у них был задан failures to tolerate равный 1, а а хост перевели в режим обслуживания - и теперь есть только одна активная реплика данных).
В таком случае vSAN понимает, что у вас был FTT=1, и на время обслуживания все операции записи начинает дублировать на выделенный хост для delta writes, чтобы вы не потеряли данные во время отказа хоста с единственной копией данных:
При выходе хоста ESXi из режима обслуживания происходит обновление его данных с временного хранилища, после чего оно высвобождается для дальнейшего использования. Интересно, что для этих целей можно использовать и witness-хост.
Данный механизм можно использовать как для RAID Mirroring, так и для Erasure Coding.
8. Быстрая перезагрузка и ускоренный апгрейд кластеров
Существенное ускорение апгрейда кластеров за счет более быстрой перезагрузки хостов
Метаданные хоста записываются на диск перед перезагрузкой и восстанавливаются в память после загрузки - это ускоряет актуализацию метаданных
Как результат - хосты загружаются до 5 раз быстрее
9. Общий witness-хост для нескольких кластеров
Это очень удобно для ROBO-инсталляций. vSAN 7 Update 1 поддерживает до 64 кластеров в двухузловых конфигурациях с общим witness для ROBO-сценариев (это решения для удаленных офисов и филиалов - Remote or Branch Offices).
10. Оптимизация всегда доступной емкости (Slack Space)
По рекомендациям VMware нужно было всегда держать 25-30% свободной емкости хранилищ в кластере. Это называлось Slack Space. Теперь это называется Reserved Capacity, и ее необходимый объем зависит о числа узлов в кластере (чем меньше узлов - тем меньше емкость), например:
12 node cluster = ~16%
24 node cluster = ~12%
48 node cluster =~ 10%
Эта емкость нужна для:
Операций Resync при изменении политик, ребалансировке, перемещении данных (Operations Reserve)
Активностей Rebuild при отказах хранилищ и хостов (Host Rebuild Reserve)
Надо понимать, что Reserved Capacity предотвращает только развертывание новых виртуальных машин, но не затрагивает ввод-вывод уже имеющихся.
Также Reserved Capacity - это опциональный механизм, который не включен по умолчанию:
Функция vSAN Reserved Capacity не поддерживается для растянутых кластеров и двухузловых конфигураций.
11. Улучшения vSphere Lifecycle Manager (vLCM)
Еще в vSAN 7 поддерживались узлы Dell и HPE для решения vLCM, теперь же к ним добавилось и оборудование Lenovo ReadyNode.
Сам vLCM получил следующие улучшения:
Работа с vSAN Fault Domains, двухузловыми конфигурациями и растянутыми кластерами (Stretched Clusters)
Предпроверки Hardware compatibility pre-checks
Параллельное обновление кластера до 64 хостов
Поддержка окружений с NSX-T 3.1
12. Упрощенная маршрутизация для некоторых топологий
Раньше для топологии vSAN с внешним witness должны были иметь статическую маршрутизацию. Теперь в vSAN 7 Update 1 можно добавить шлюз по умолчанию и не прописывать статические маршруты:
13. Утилита vSAN I/O Insight
С помощью этого средства можно анализировать I/O-паттерны для анализа рабочих нагрузок в кластере. Это утилита, встроенная в vSphere Client, в которой доступен большой набор паттернов метрик и гистограмм для анализа таких вещей, как R/W ratio, Seq/Random ratio, 4K aligned / unaligned ratio, IO size distribution.
Все это позволяет не пользоваться сторонними утилитами для решения узких проблем, а понимать их природу прямо из vSphere Client:
14. Улучшения сервисов для Cloud native applications
Платформа vSAN Data Persistence
- это новый фреймворк для партнеров, который позволяет интегрировать информацию о приложениях для операционных задач через API.
SAN Direct Configuration - это альтернативный способ для прямой интеграции сервисов с хранилищами vSAN.
Улучшения интеграции с vSphere with Tanzu за счет расширений для томов гостевых кластеров TKG, а также получения информации о состоянии томов TKG supervisor и guest.
Доступность для загрузки VMware vSAN 7 Update 1 ожидается в самое ближайшее время, следите за нашими новостями.
Это статья нашего спонсора - компании ИТ-ГРАД, предоставляющей в аренду виртуальные машины из облака. Гиперконвергентность – быстрорастущий сегмент СХД. Переход от традиционной архитектуры к HCI выбирают все больше компаний. Хотите узнать почему? В статье мы ответим на этот вопрос и расскажем для каких задач подходит VMware vSAN...
Иногда в кластере хранилищ VMware vSAN случается такая ситуация, что один из хостов ESXi оказывается "пустым", то есть не содержит компонентов виртуальных машин. При этом хранилища остальных хостов в кластере могут быть загружены почти полностью.
В этом случае надо посмотреть на интерфейс vSphere Client в разделе vSAN health check - там может быть такое сообщение для проблемного хоста:
vSAN node decommission state
Означает это, что хост находится в режиме обслуживания с точки зрения vSAN (Node Decommission State). При этом, например, с точки зрения хостов ESXi кластера VMware vSphere / HA он может не быть в maintenance mode. Поэтому может сложиться впечатление, что хост просто не принимает дисковые объекты по каким-то причинам.
Это состояние рассинхрона кластера vSphere и кластера vSAN. Лечится следующей командой по SSH, которая выведет узел vSAN из режима обслуживания, после чего он оживет на прием компонентов:
localcli vsan maintenancemode cancel
Также вы можете кликнуть правой кнопкой на хосте ESXi, перевести его в режим обслуживания, а потом вернуть обратно:
Это отменит и перевод в режим обслуживания vSAN, после чего хост сможет размещать дисковые объекты виртуальных машин (для этого надо запустить операцию Rebalance). Более подробно об этом в KB 51464.
На сайте проекта VMware Hans-on Labs (HOL) появились две новые лабораторные работы, посвященные новой версии продукта для создания отказоустойчивых хранилищ VMware vSAN 7.
Лабораторные работы VMware HoL позволяют освоить работу с различными продуктами и технологиями, проходя по шагам интерфейса. Такой способ отлично подходит для обучения работе с новыми версиями решений без необходимости их развертывания.
Напомним, что в последнее время мы уже писали об обновлениях лабораторных работ:
Хранилища vSAN Cloud Native Storage (CNS) для контейнеров кластеров Kubernetes
Мониторинг состояния, доступных емкостей и производительности
Облуживание и управление жизненным циклом хранилищ и виртуальных машин
Шифрование и безопаность платформы
Вторая лабораторная работа посвящена мастеру QuickStart для пошагового создания кластера хранилищ vSAN, с помощью которого можно быстро освоить его основные настройки и конфигурации:
Несмотря на то, что компания VMware представила версию средства для создания отказоустойчивых хранилищ vSAN 6.5 еще в 2016 году, многие крупные компании продолжают ей пользоваться. Между тем, надо понимать, что скоро браузеры отключат поддержку Flash, и все консоли на базе этой технологии (а именно на ней работает старый vSphere Web Client) просто прекратят работать (в Chrome это запланировано на декабрь этого года).
Чтобы вы могли и дальше использовать vSAN 6.5, нужно накатить патч vSAN 6.6.1 Patch 05 (вышел еще 30 июля), в котором добавлена поддержка технологии HTML5, поддерживающейся всеми современными браузерами. О возможностях vSAN 6.6.1 мы писали вот тут.
В новом апдейте vSAN 6.6.1 на базе мажорной версии 6.5 есть следующие нововведения:
Отчеты о производительности вы можете найти в Cluster > вкладка Monitor > секция vSAN > Performance
Добавлена панель общей информации в разделе Virtual object, показывающая размещение и доступность объектов в кластере. Также можно фильтровать список по статусу и типу объектов.
В разделе Virtual Objects/ View data placement есть чекбокс "Group components by host placement", который дает возможность увидеть состояние компонентов данных и быстрее обнаружить потенциальные проблемы на хостах ESXi.
Также из блога VMware мы утянули вот такое видео с обзором интерфейса HTML5 для vSAN 6.6.1:
Производительность дисковой подсистемы в Linux зависит от различных параметров и настроек, одной из которых является тип планировщика для работы с потоком ввода-вывода (I/O scheduler). Если вы планируете использовать продукт StarWind VSAN for vSphere для создания программных хранилищ на базе виртуальных машин Linux (Virtual Storage Appliance), то информация ниже может быть вам полезна.
В зависимости от типа целевого хранилища, иногда целесообразно поменять используемый тип планировщика. Чтобы вывести текущий тип I/O scheduler, нужно выполнить следующую команду для выбранного устройства:
В данном случае мы видим, что тип планировщика - это noop (он же none). В зависимости от версии ядра Linux, он также может быть выставлен как mq-deadline. Кстати, обратите внимание, что тип планировщика указывается на уровне отдельного дискового устройства.
Считается, что для SSD и NVMe-устройств лучше ставить планировщик none / noop, который уменьшает нагрузку на CPU, а вот для HDD-дисков лучше использовать mq-deadline, который показывает лучшие результаты по итогам синтетических тестов.
Чтобы поменять планировщик на noop для диска sdb, нужно выполнить следующую команду:
# echo noop > /sys/block/sdb/queue/scheduler
Потом надо обязательно проверить, что планировщик поменялся, следующей командой:
Но это все меняет тип планировщика на время, до перезагрузки, чтобы вы могли проверить разные планировщики и сделать тесты производительности. Чтобы сохранить эти изменения, нужно изменить файл scheduler.rules в директории /etc/udev/rules.d/
Например, если вы хотите поменять планировщик на noop для устройства sdb и установить политику "no read ahead" для него, то нужно добавить туда следующую строчку:
Рекомендуется выставлять одинаковый тип планировщика на всех узлах, где расположены хранилища StarWind VSAN. Также надо отметить, что последние версии продукта StarWind VSAN for vSphere при установке автоматически выставляют тип планировщика noop для SSD-хранилищ.
Как многие из вас знают, у компании StarWind, выпускающей лучший продукт Virtual SAN для создания программных iSCSI хранилищ под виртуализацию, есть и программно-аппаратный комплекс HyperConverged Appliance (HCA). Чтобы управлять этим решением в контексте всей инфраструктуры, существует продукт StarWind Command Center, на который мы сегодня посмотрим.
Таги: StarWind, Command Center, Hardware, HCA, Appliance, Storage, Hyper-V
Возможно, некоторые администраторы VMware vSphere попадали в ситуацию, когда один из датасторов в виртуальной инфраструктуре оказывался не привязанным ни к какому хосту ESXi, но при этом у него также была неактивна опция Delete Datastore из контекстного меню:
Такой зомби-датастор можно удалить только из базы данных vCenter Server Appliance (vCSA), поэтому вы полностью должны быть уверены в том, что он не используется никаким из хостов, а также в том, что он не презентует никакое физическое устройство в вашей инфраструктуре.
Первое что вам надо сделать - это включить доступ к vCSA по SSH (картинки - отсюда):
Далее нужно зайти по SSH на vCSA, запустить там шелл командой shell и далее запустить утилиту psql для работы с базой данных следующей командой:
После этого нужно найти id датастора следующей командой:
VCDB=# SELECT id FROM vpx_entity WHERE name = 'MyStubbornDatastore';
Когда вы нашли id, нужно удалить упоминание об этом датасторе из таблиц базы данных vCSA следующими командами:
DELETE FROM vpx_ds_assignment WHERE ds_id=3089;
DELETE FROM vpx_datastore WHERE id=3089;
DELETE FROM vpx_vm_ds_space WHERE ds_id=3089;
При выполнении второй операции вы получите следующую ошибку:
ERROR: update or delete on table "vpx_datastore" violates foreign key constraing "fk_vpxspace"
DETAIL: Key (id)=(3089) is still referenced from table "vpx_vm_ds_space".
Не обращайте на нее внимания и выполняйте третью. Затем нужно перезагрузить vCSA и снова выполнить второй DELETE, который в этот раз должен завершиться успешно. После этого датастор пропадет из списка в vSphere Client.
Помните, что выполняя данную операцию, вы должны понимать, что именно делаете:)
Некоторые функции vCloud Director (VCD) по работе с виртуальными машинами по-прежнему недоступны через стандартные командлеты PowerCLI, поэтому к ним необходимо обращаться через VCD API.
Jon Waite в своем блоге опубликовал PowerCLI-сценарий, с помощью которого можно обратиться к VCD API и увеличить размер загрузочного диска ВМ. Надо сказать, что при подобного рода манипуляциях (как увеличение, так и уменьшение диска) всегда есть риск потери данных, поэтому обязательно сделайте резервную копию.
Стандартное определение функции - на входе объект виртуальная машина и новый желаемый размер первого (загрузочного) диска в МБ.
7-9
Одна команда, разделенная на 3 строчки. Вызов VCD API для определения поддерживаемых версий API, чтобы не хардкодить конкретную версию в скрипте.
10-12
Обрабатывает результат прошлой строчки, определяет последнюю актуальную версию VCD API и сохраняет $APIVersion для использования позднее.
14
Определяет SessionId для текущей сессии PowerCLI (Connect-CIServer), чтобы использовать API-запросы на строчках 17 и 27.
15
Получает хэш $Headers для отправки API-запросов (переменные SessionId и APIVersion были получены ранее).
16
Определяет API URI через поддерживаемый VM HTTP reference.
17
Получает представление XML секций virtualHardwareSection/disks определенной ВМ.
19-20
Находит первый диск, привязанный к ВМ (ResourceType 17 = Hard Disk)
22-23
Обновляет размер диска ВМ на базе входного параметра емкости у функции. На самом деле у VCD достаточно обновить capacity, а VirtualQuantity обновляем для консистентности (в байтах).
24
Добавляем дополнительное значение к $Header, чтобы обозначить Content-Type, который мы отправляем обратно к API.
26-34
Попытки обновить API измененным XML, включая новый размер диска и возвращаем ошибку с описанием, если операция прошла неудачно.
После выполнения сценария нужно будет, само собой, расширить соответствующий раздел гостевой системы. Современные версии Windows и Linux могут раскатывать существующий раздел на весь размер физического устройства даже без перезагрузки машины.
Пример использования сценария:
PS /> $VM = Get-CIVM -Name 'TestVM01'
PS /> $VM | Update-CIVMBootDisk -NewSizeMB 2048
Disk resize for VM TestVM01 submitted successfully.
Не все администраторы знают, что при апгрейде VMware ESXi на более новую мажорную версию есть возможность сохранить предыдущую конфигурацию гипервизора для возможности отката в случае неудачного обновления. Такая возможность, например, есть при апгрейде ESXi 6.5 на версию 6.7.
Для этого нужно во время установки выбрать пункт "Upgrade ESXi, preserver VMFS datastore". Под датастором тут имеется в виду, что на нем сохранится предыдущая установка ESXi:
Кстати, как видно из скриншота, можно сделать и свежую установку ESXi с возможностью отката к предыдущей версии.
Итак, вы сделали апгрейд ESXi, но что-то пошло не так. Например, ваше железо больше не поддерживается (к примеру, CPU), и вам надо сделать откат к прошлой версии ESXi. Для этого во время загрузки вам нужно нажать комбинацию клавиш Shift + <R>:
После этого можно будет выбрать предыдущую версию ESXi и заменить ей новую установку, полностью откатившись к прошлому гипервизору и его настройкам:
Также можно делать бэкап и восстановление конфигурации VMware ESXi - об этом рассказано в KB 2042141.
Мы уже очень много писали о нововведениях VMware vSphere 7, но все еще есть о чем рассказывать. Не так давно мы говорили об улучшениях горячей миграции виртуальных машин vMotion в ESXi 7 (и тут), а сегодня посмотрим, как был улучшен механизм горячей миграции хранилищ Storage vMotion.
При миграциях SVMotion используется техника Fast Suspend and Resume (FSR), которая очень близка к vMotion, но не идентична ему. При горячей миграции хранилища ВМ происходит создание теневой копии этой машины на том же хосте ESXi, куда подцепляются новые хранилища или устройства, после чего происходит копирование метаданных памяти и состояния устройств от исходной ВМ к целевой. В этот момент машина "замирает" примерно на 1 секунду, а затем происходит включение уже целевой ВМ, а исходная ВМ выключается и удаляется:
Такая же методика применяется и для механизма Hot Add / Remove, который позволяет добавлять и удалять устройства виртуальной машины "на горячую" без необходимости ее выключения. Для выключенной ВМ добавление и удаление устройств - это лишь изменения в конфигурационном файле VMX.
Сам процесс FSR в целом работал довольно неплохо для небольших виртуальных машин, а прерывание работы ВМ укладывалось, как правило, в одну секунду. Но для больших машин (Monster VM) процесс копирования метеданных памяти мог занять продолжительное время.
Во время приостановки ВМ происходит копирование блоков памяти Page Frames (PFrames), представляющих собой маппинги между виртуальной памятью машины и физическими адресами Machine Page Numbers (MPN).
Эти блоки и нужно скопировать во время паузы FSR:
До VMware vSphere 7 во время копирования метаданных памяти использовался только один vCPU машины, в то время как остальные процессоры ВМ ждали окончания процесса и простаивали:
Очевидно, что для больших машин с большим объемом памяти и числом vCPU процесс работал неоптимально. В VMware vSphere 7 для копирования блоков PFrame используются все vCPU. Метаданные памяти разделяются на сегменты, и за копирование каждого сегмента отвечает свой виртуальный процессор. Сам процесс копирования происходит в параллельном режиме, что существенно экономит время на копирование:
Для обычных ВМ это улучшение вряд ли получится почувствовать на практике, но если вы используете Monster VMs, то эффект от обновленного FSR можно будет заметить. Например, VMware взяла машину с 1 ТБ памяти и 48 vCPU, которую перемещала под нагрузкой с помощью Storage vMotion. Так вот время переключения со старым FSR составило 7.7 секунды, а с новым - около 0.5 секунды для VMware vSphere 7:
Мы много писали о возможностях новой версии платформы VMware vSphere 7 (например, тут и тут), но нововведений там столько, что это не уместить и в десять статей. Сегодня мы поговорим об изменениях в структуре разделов
(Partition Layout), которые произошли в VMware ESXi 7.
Первое, что надо отметить, что до vSphere 7 разделы были фиксированного объема, а их нумерация была статической, что ограничивало возможности по управлению ими, например, в плане поддержки больших модулей, функций отладки и стороннего ПО.
Поэтому в vSphere 7 были увеличены размеры загрузочных областей, а системные разделы, которые стали расширяемыми, были консолидированы в один большой раздел.
В VMware vSphere 6.x структура разделов выглядела следующим образом:
Как мы видим, размеры разделов были фиксированы, кроме раздела Scratch и опционального VMFS datastore. Они зависят от типа загрузочного диска (boot media) и его емкости.
В VMware vSphere 7 произошла консолидация системных разделов в область ESX-OSData:
Теперь в ESXi 7 есть следующие 4 раздела:
System boot - хранит boot loader и модули EFI. Формат: FAT16.
Boot-banks (2 штуки)
- системное пространство для хранения загрузочных модулей ESXi. Формат: FAT16.
ESX-OSData - унифицированное хранилище дополнительных модулей, которые не необходимы для загрузки. К ним относятся средства конфигурации и сохранения состояния, а также системные виртуальные машины. Формат: VMFS-L. Для этой области нужно использовать долговременные хранилища на базе надежных устройств.
Как вы видите, ESX-OSData разделен на две части: ROM-data и RAM-data. Часто записываемые данные, например, логи, трассировка томов VMFS и vSAN EPD, глобальные трассировки, горячие базы данных - хранятся в RAM-data. В области ROM-data хранятся нечасто используемые данные, например, ISO-образы VMware Tools, конфигурации, а также дампы core dumps.
В зависимости от размера устройства, куда устанавливается ESXi, меняется и размер всех областей, кроме system boot:
Если размер устройства больше 128 ГБ, то ESXi 7 автоматически создает VMFS-тома.
Когда вы используете для запуска ESXi устройства USB или карточки SD, то раздел ESX-OSData создается на долговременном хранилище, таком как HDD или SSD. Когда HDD/SSD недоступны, то ESX-OSData будет создан на USB-устройстве, но он будет содержать только ROM-data, при этом RAM-data будет храниться на RAM-диске (и не сохранять состояние при перезагрузках).
Для подсистем ESXi, которым требуется доступ к содержимому разделов, используются символьные ссылки, например, /bootbank и /altbootbank. А по адресу /var/core лежат дампы core dumps:
В VMware vSphere Client можно посмотреть информацию о разделах на вкладке Partition Details:
Ту же самую информацию можно получить и через интерфейс командной строки ESXi (команда vdf):
Обратите внимание, что соответствующие разделы смонтированы в BOOTBANK1 и 2, а также OSDATA-xxx.
Кстати, вы видите, что OSDATA имеет тип файловой системы Virtual Flash File System (VFFS). Когда OSDATA размещается на устройствах SDD или NVMe, тома VMFS-L помечаются как VFSS.
ESXi поддерживает множество устройств USB/SD, локальных дисков HDD/SSD, устройств NVMe, а также загрузку с тома SAN LUN. Чтобы установить ESXi 7 вам нужно выполнить следующие требования:
Boot media размером минимум 8 ГБ для устройств USB или SD
32 ГБ для других типов устройств, таких как жесткие диски, SSD или NVMe
Boot device не может быть расшарен между хостами ESXi
Если вы используете для установки ESXi такие хранилища, как M.2 или другие не-USB девайсы, учитывайте, что такие устройства могут быстро износиться и выйти из строя, например, если вы используете хранилища VMFS на этих устройствах. Поэтому удалите тома VMFS с таких устройств, если они были созданы установщиком по умолчанию.
За время карантина компания StarWind Software выпустила пару небольших обновлений своего флагманского продукта StarWind Virtual SAN V8, предназначенного для создания программных и программно-аппаратных хранилищ под виртуализацию.
Продукт продолжает развиваться, ведется большая работа над улучшением производительности и ошибками, давайте посмотрим, что в нем появилось интересного для платформ vSphere и Hyper-V:
Для виртуального модуля StarWind VSAN for vSphere OVF (версия 20200515) была обновлена версия ядра Linux.
Функция полной синхронизации с проверкой контрольных сумм (CRC), добавленная в прошлом релизе, теперь используется только для хранилищ на базе MS Storage Spaces. В этом случае тип синхронизации (Full или Full hash) показан в Management Console.
Для старых хранилищ используется старый алгоритм с копированием данных без дополнительной проверки CRC, чтобы не влиять на производительность.
Для запроса CRC исправлена проблема с Memory alignment. Также была исправлена проблема совместимости для виртуального модуля StarWind VSA.
Множество исправлений ошибок, в том чиле важных с возможным повреждением данных - поэтому обязательно нужно обновиться.
StarWindX PowerShell Module
Добавлена проверка размера сектора для образа Flat Image - нельзя создать Flat Device с размером сектора 512 бай при физическом размере 4096 байт.
Добавлен параметр валидации формата (format) для вызова Add-RamDevice. Допустимые значения: fat16, fat32, ntfs, raw.
Добавлен параметр "force" для команды "remove".
Добавлено свойство CreateTapeOnExport для вызова VTL ApplyReplicationSettings(). Подробнее в сэмпле скрипта VTLReplicationSettings.ps1.
Нотификации по электронной почте и в интерфейсе
Запись нотификаций в текстовый файл не всегда теперь держит его открытым, а открывает и закрывает при необходимости.
Улучшена безопасность при работе с SMTP и пофикшен баг с отсылкой письма без аутентификации.
Установщик
Число файлов в Log Rotate было увеличено до 20 во время обновлений существующих установок.
Management Console
Пофикшена ошибка с отображением событий из Event Log в зоне нотификаций. Иногда эти события не отображались.
Хранилища Flat Storage
Улучшена обработка ответов для команд UNMAP/TRIM от хранилищ с файловой системой ReFS.
Прочее
Исправления для процессинга команды EXTENDED COPY(LID4), которая возвращала ошибки в прошлых версиях.
Скачать самый свежий релиз StarWind Virtual SAN V8 for Hyper-V от 6 мая 2020 (build 13586) года можно по этой ссылке, а StarWind VSAN for vSphere OVF (версия 20200515 от 18 мая) - по этой ссылке.
Frank Denneman обратил внимание на одну интересную новую функцию VMware vSphere 7 - возможность миграции vMotion для виртуальных машин с привязанными ISO-образами.
Как знают администраторы vSphere, часто приходится привязывать ISO-образ к консоли виртуальной машины, чтобы установить какое-то ПО. Нередко этот ISO находится на локальном хранилище машины администратора:
В таком случае, при попытке миграции vMotion данной виртуальной машины выдается ошибка о невозможности выполнения операции в связи с привязанным и активным локальным ISO к виртуальному устройству CD/DVD:
Усугубляется это еще и тем, что такие машины исключаются из миграций DRS, а также не могут быть смигрированы автоматически при переводе хоста ESXi в режим обслуживания (Maintenance mode). Как это обычно бывает, администратор узнает об этом в самом конце, минут через 10 после начала операции по переводу на обслуживание - и агрится от такой ситуации.
Поэтому в VMware vSphere 7 такое поведение пофиксили: теперь при миграции vMotion
виртуальное устройство с локальным файлом отсоединяется от исходной машины по команде процесса VMX, все операции с ним буферизуются, далее происходит миграция машины на другой хост, подцепление к нему виртуального устройства с вашим ISO и накатывание буфера.
После переключения машины на другой хост ESXi, VMRC-консоль показывает подключение вашего локального ISO уже к целевой машине:
Казалось бы, мелочь, но иногда может сэкономить немного времени администратора. Для работы этой фичи нужно, чтобы оба хоста VMware ESXi были седьмой версии или выше.
Недавно компания VMware выпустила интересный документ, объясняющий иногда возникающие проблемы с производительностью операций чтения с NFS-хранилищ для серверов VMware ESXi версий 6.x и 7.x. В документе "ESXi NFS Read Performance: TCP Interaction between Slow Start and Delayed Acknowledgement" рассматривается ситуация с эффектом Slow Start и Delayed Acknowledgement.
Этот эффект возникает в некоторых сценариях с низким процентом потери пакетов (packet loss), когда используется fast retransmit на передатчике и selective acknowledgement (SACK) на приемнике. Для некоторых реализаций стека TCP/IP в случаях, когда передатчик входит в состояние slow start при включенной отложенной квитанции приема пакетов (delayed ACK), квитанция о приеме первого сегмента slow start может быть отложена на время до 100 миллисекунд. Этого оказывается достаточно, чтобы снизить последовательную скорость чтения с NFS-хранилища на величину до 35% (при этом потери пакетов не будут превышать 0.02%).
Более подробно механика возникновения этого эффекта описана в документе. Там же рассказывается и метод борьбы с этим: если вы подозреваете, что у вас подобная проблема, надо просто отключить ESXi NFS Client Delayed ACK и посмотреть, стало ли лучше. Для этого в консоли нужно выполнить следующую команду:
esxcli system settings advanced set -o "/SunRPC/SetNoDelayedAck" -i 1
После этого убеждаемся, что настройка установлена:
esxcli system settings advanced list | grep -A10 /SunRPC/SetNoDelayedAck
Более подробно об этом можно также почитать в KB 59548.
После этого нужно снова провести тесты на последовательное чтение. Если не помогло, то лучше вернуть настройку назад, указав в качестве параметра первой команды -i 0.
Если вы на своем Mac решили установить VMware ESXi 7 в виртуальной машине на флешке, то с настройками по умолчанию этого сделать не получится - USB-устройство не обнаружится установщиком и не будет видно в разделе настроек USB & Bluetooth виртуальной машины.
Eric Sloof написал, что перед развертыванием ESXi, чтобы установщик увидел USB-диск, нужно перевести USB Compatibility в режим совместимости с USB 3.0:
После этого можно будет выбрать ваш USB-диск для установки ESXi 7.0:
Многие из вас знакомы с решением VMware App Volumes, которое предназначено для распространения готовых к использованию приложений VMware ThinApp посредством подключаемых виртуальных дисков к машинам. Те из вас, кто его используют, время от времени, наверняка, сталкиваются с проблемой недостатка места на пользовательских томах Writable Volumes, которые забиваются неизвестно чем:
Напомним, что Writable Volumes - это персонализированные тома, которые принадлежат пользователям. Они хранят настройки приложений, лицензионную информацию, файлы конфигураций приложений и сами приложения, которые пользователь установил самостоятельно. Один такой диск может быть назначен только одному десктопу, но его можно перемещать между десктопами. Соответственно, такие тома могут легко заполняться, и пользователи начинают жаловаться.
Aresh Sarkari написал полезный скрипт, который выявляет заполненные тома Writable Volumes в инфраструктуре App Volumes (меньше 3 ГБ свободного места), формирует CSV-файл с данными о них и посылает его по электронной почте администратору:
####################################################################
# Get List of Writable Volumes from AppVolumes Manager for free space less than 3 GB out of 30 GB
# Author - Aresh Sarkari (@askaresh)
# Version - V2.0
####################################################################
# Run at the start of each script to import the credentials
$Credentials = IMPORT-CLIXML "C:\Scripts\Secure-Creds\SCred_avmgr.xml"
$RESTAPIUser = $Credentials.UserName
$RESTAPIPassword = $Credentials.GetNetworkCredential().Password
$body = @{
username = “$RESTAPIUser"
password = “$RESTAPIPassword”
}
Invoke-RestMethod -SessionVariable DaLogin -Method Post -Uri "https://avolmanager.askaresh.com/cv_api/sessions” -Body $body
$output = Invoke-RestMethod -WebSession $DaLogin -Method Get -Uri "https://avolmanager.askaresh.com/cv_api/writables" -ContentType "application/json"
$output.datastores.writable_volumes | Select-Object owner_name, owner_upn,total_mb, free_mb, percent_available, status | Where-Object {$_.free_mb -lt 3072} | Export-Csv -NoTypeInformation -Append D:\Aresh\Writableslt3gb.$(Get-Date -Format "yyyyMMddHHmm").csv
#send an email (provided the smtp server is reachable from where ever you are running this script)
$emailfrom = 'writablevolumes@askaresh.com'
$emailto = 'email1@askaresh.com', 'email2@askaresh.com' #Enter your SMTP Details
$emailsub = 'Wrtiable Volumes Size (free_mb) less than 3 GB out of 30 GB - 24 Hours'
$emailbody = 'Attached CSV File from App Volumes Manager. The attachment included the API response for all the Writable Volumes less than 3 GB of free space'
$emailattach = "D:\Aresh\Writableslt3gb.$(Get-Date -Format "yyyyMMddHHmm").csv"
$emailsmtp = 'smtp.askaresh.com'
Send-MailMessage -From $emailfrom -To $emailto -Subject $emailsub -Body $emailbody -Attachments $emailattach -Priority High -DeliveryNotificationOption OnFailure -SmtpServer $emailsmtp
Последняя версия сценария PowerCLI для поиска заполненных томов доступна в репозитории на GitHub. Там же, кстати, есть сценарий для поиска Writable Volumes со статусом Disabled или Orphaned.
Не так давно мы писали о новых возможностях платформы для создания отказоустойчивых хранилищ виртуальных машин в инфраструктуре виртуализации VMware vSAN 7.0. Компания VMware недавно сделала доступными для загрузки все компоненты обновленной виртуальной инфраструктуры, но новые возможности получили далеко не все пользователи - их набор зависит от имеющейся лицензии.
Давайте посмотрим, какие возможности есть в каждом из четырех доступных изданий VMware vSAN 7.0:
Standard (гибридные хранилища HDD+SSD)
Advanced (All-Flash хранилища)
Enterprise (возможности для предприятий)
Enterprise Plus (гиперконвергентная инфраструктура)
Возможности vSAN 7
Политики хранилищ Storage Policy Based Management (SPBM)
На днях на сайте проекта VMware Labs появилась полезная администраторам vSphere штука - утилита vSphere Replication Capacity Planning, позволяющая определить реальное потребление трафика репликации виртуальными машинами и размер передаваемой дельты данных. Это позволяет планировать сетевую инфраструктуру и принимать решения о выделении канала еще до того, как вы включите репликацию для всех своих виртуальных машин.
Утилита Replication Capacity Planning показывает графики, касающиеся объема передачи сетевого трафика LWD (lightweight delta - изменения с момента последней репликации) во времени, а также метрики по размеру дельты в различных временных масштабах - часы, дни, недели и месяцы.
Также в результате работы этого средства для виртуальной машины будет показано, какой объем вычислительных ресурсов и хранилища под реплики вам потребуется на целевой площадке (без учета актуальной политики хранилищ там):
Решение vSphere Replication Capacity Planning развертывается как виртуальный модуль (Virtual Appliance), для его работы потребуется VMware ESXi 6.0 или более поздней версии. Скачать его можно по этой ссылке. Документация доступна здесь.
Кластер отказоустойчивых хранилищ VMware vSAN состоит из нескольких хостов ESXi, на локальных хранилищах которых создаются дисковые группы, где размещаются данные виртуальных машин. В процессе создания, перемещения и удаления дисковых объектов ВМ распределение емкости на дисках может изменяться, иногда довольно существенно.
Все это приводит к дисбалансу кластера по дисковой емкости, что создает разную нагрузку на устройства, а это не очень хорошо:
В случае возникновения подобного дисбаланса в кластере VMware vSAN, в консоли vSphere Client на вкладке Monitor, в разделе vSAN Health появляется нотификация vSAN Disk Balance (выполняется эта проверка каждые 30 минут по умолчанию):
Чтобы устранить подобные ситуации, в кластере VMware vSAN есть механизм автоматической балансировки - Automatic Rebalance, который относится к дисковым объектам кластера vSAN, которые распределяются по дисковым группам разных хостов. Если данная настройка включена, то кластер vSAN автоматически наблюдает за балансом распределения дисковых объектов по хостам ESXi и выравнивает нагрузку на дисковые устройства.
По умолчанию пороговое значение составляет 30% (параметр Average Load Varinace - среднее значение разницы между минимальной и максимальной используемой емкостью на дисках в процентах). Это означает, что когда разница нагрузки между двумя дисковыми устройствами достигнет этого значения - начнется автоматическая перебалансировка и перемещение дисковых объектов. Она будет продолжаться, пока это значение не снизится до 15% или меньшей величины.
Также перебалансировка сама запустится, когда диск заполнен на более чем 80%. Надо помнить, что операция эта создает нагрузку на дисковые хранилища, поэтому надо учитывать, что у вас должен быть некоторый запас по производительности, чтобы автоматическая балансировка не съела полезные ресурсы.
В случае если у вас включена настройка Automatic Rebalance, кластер vSAN будет стараться поддерживать этот хэлсчек всегда зеленым. Если же отключена - то в случае возникновения дисбаланса загорится алерт, и администратору нужно будет вручную запустить задачу Rebalance Disks.
Эта опция называется ручной проактивной балансировкой кластера, она становится доступной когда разница в использовании дисковой емкости двух или более дисков начинает превышать 30%:
Если вы запускаете такую балансировку вручную, то продлится она по умолчанию 24 часа и затем сама остановится.
Надо понимать, что операция ребалансировки - это совершенно другая операция, нежели vSAN Resync. Она служит только целям сохранения равномерной нагрузки в кластере с точки зрения дисков.
Также есть возможность контроля операций ребалансировки с помощью интерфейса Ruby vSphere Console (RVC). Для этого вам нужно сменить пространство имен (namespace) на computers и выполнить следующую команду для кластера, чтобы посмотреть информацию о текущем балансе:
vsan.proactive_rebalance_info <номер кластера vSAN или символ "." для текущего пути консоли RVC>
Результат выполнения команды будет, например, таким:
/localhost/Test-DC/computers/Test-CL> vsan.proactive_rebalance_info .
2019-08-16 19:31:08 +0000: Retrieving proactive rebalance information from host esxi-3.labs.org ...
2019-08-16 19:31:08 +0000: Retrieving proactive rebalance information from host esxi-1.labs.org ...
2019-08-16 19:31:08 +0000: Retrieving proactive rebalance information from host esxi-2.labs.org ...
2019-08-16 19:31:09 +0000: Fetching vSAN disk info from esxi-3.labs.org (may take a moment) ...
2019-08-16 19:31:09 +0000: Fetching vSAN disk info from esxi-2.labs.org (may take a moment) ...
2019-08-16 19:31:09 +0000: Fetching vSAN disk info from esxi-1.labs.org (may take a moment) ...
2019-08-16 19:31:10 +0000: Done fetching vSAN disk infos
Proactive rebalance start: 2019-08-16 19:30:47 UTC
Proactive rebalance stop: 2019-08-17 19:30:54 UTC
Max usage difference triggering rebalancing: 30.00%
Average disk usage: 56.00%
Maximum disk usage: 63.00% (17.00% above minimum disk usage)
Imbalance index: 10.00%
No disk detected to be rebalanced
В этом случае ребалансировка не требуется. Если же вы, все-таки, хотите ее запустить, то делается это следующей командой:
vsan.proactive_rebalance -s <номер кластера vSAN или символ "." для текущего пути консоли RVC>
Ну и вы можете изменить время, в течение которого будет идти ручная ребалансировка. Для этого задайте значение в секундах следующей командой (в данном примере - это 7 дней):
На днях компания VMware объявила о скором выпуске платформы виртуализации VMware vSphere 7.0, где будет много интересных новых возможностей. Одновременно с этим было объявлено и о будущем релизе новой версии VMware vSAN 7.0 - решения для организации отказоустойчивых хранилищ для виртуальных машин на базе локальных хранилищ хост-серверов VMware ESXi.
Давайте посмотрим, что интересного было анонсировано в новой версии решения VMware vSAN 7:
1. Интеграция с vSphere Lifecycle Manager (vLCM) для обновления кластеров
Ранее администраторы vSphere использовали Update Manager (VUM) для обновлений платформы и драйверов, а утилиты от производителей серверов для обновления их микрокода (firmware). Теперь эти процессы объединяются в единый механизм под управлением vSphere Lifecycle Manager:
vLCM можно использовать для применения установочных образов, отслеживания соответствия (compliance) и приведения кластера к нужному уровню обновлений. Это упрощает мониторинг инфраструктуры на предмет своевременных обновлений и соответствия компонентов руководству VMware Compatibility Guide (VCG) за счет централизованного подхода на уровне всего кластера.
2. Службы Native File Services for vSAN
С помощью служб Native File Services кластер vSAN теперь поддерживает управление внешними хранилищами NFS v3 и v4.1. Это позволяет использовать их совместно с другими возможностями, такими как службы iSCSI, шифрование, дедупликация и компрессия. Теперь через интерфейс vCenter можно управлять всем жизненным циклом хранилищ на базе разных технологий и превратить его в средство контроля над всей инфраструктурой хранения.
3. Развертывание приложений с использованием Enhanced Cloud Native Storage
Напомним, что функции Cloud Native Storage появились еще VMware vSAN 6.7 Update 3. Cloud Native Storage (CNS) - это функциональность VMware vSphere и платформы оркестрации Kubernetes (K8s), которая позволяет по запросу развертывать и обслуживать хранилища для виртуальных машин, содержащих внутри себя контейнеры. По-сути, это платформа для управления жизненным циклом хранения для контейнеризованных приложений.
Теперь эти функции получили еще большее развитие. Тома persistent volumes могут поддерживать шифрование и снапшоты. Также полностью поддерживается vSphere Add-on for Kubernetes (он же Project Pacific), который позволяет контейнеризованным приложениям быть развернутыми в кластерах хранилищ vSAN.
4. Прочие улучшения
Тут появилось довольно много нового:
Integrated DRS awareness of Stretched Cluster configurations. Теперь DRS отслеживает, что виртуальная машина находится на одном сайте во время процесса полной синхронизации между площадками. По окончании процесса DRS перемещает машину на нужный сайт в соответствии с правилами.
Immediate repair operation after a vSAN Witness Host is replaced.
Теперь процедура замены компонента Witness, обеспечивающего защиту от разделения распределенного кластера на уровне площадок, значительно упростилась. В интерфейсе vCenter есть кнопка "Replace Witness", с помощью которой можно запустить процедуру восстановления конфигурации и замены данного компонента.
Stretched Cluster I/O redirect based on an imbalance of capacity across sites. В растянутых кластерах vSAN можно настраивать защиту от сбоев на уровне отдельных ВМ за счет выделения избыточной емкости в кластере. В результате на разных площадках могут оказаться разные настройки, и появится дисбаланс по доступной емкости и нагрузке по вводу-выводу. vSAN 7 позволяет перенаправить поток ввода-вывода на менее загруженную площадку прозрачно для виртуальных машин.
Accurate VM level space reporting across vCenter UI for vSAN powered VMs. Теперь в vSAN 7 есть возможности точной отчетности о состоянии хранилищ для виртуальных машин, точно так же, как и для остальных хранилищ в представлениях Cluster View и Host View.
Improved Memory reporting for ongoing optimization. Теперь в интерфейсе и через API доступна новая метрика потребления памяти во времени. Она позволяет понять, как меняется потребление памяти при изменениях в кластере (добавление и удаление хостов, изменение конфигурации).
Visibility of vSphere Replication objects in vSAN capacity views. vSAN 7 позволяет администраторам идентифицировать объекты vSphere Replication на уровне виртуальных машин и кластеров, что упрощает управление ресурсами для нужд репликации.
Support for larger capacity devices. Теперь vSAN 7 поддерживает новые устройства хранения большой емкости и плотности носителей.
Native support for planned and unplanned maintenance with NVMe hotplug. Для устройств NVMe теперь доступна функция горячего добавления и удаления, что позволяет сократить время и упростить процедуру обслуживания.
Removal of Eager Zero Thick (EZT) requirement for shared disk in vSAN.
Теперь общие диски в vSAN не требуется создавать в формате EZT, что ускоряет развертывание в кластере vSAN нагрузок, таких как, например, Oracle RAC.
Больше информации о новых возможностях можно почитать в даташите о vSAN 7. Ну а технические документы будут постепенно появляться на StorageHub. Как и VMware vSphere 7, планируется, что решение vSAN 7 выйдет в апреле этого года.
На днях пришла пара важных новостей о продуктах компании StarWind Software, которая является одним из лидеров в сфере производства программных и программно-аппаратных хранилищ для виртуальной инфраструктуры.
StarWind HCA All-Flash
Первая важная новость - это выпуск программно-аппаратного комплекса StarWind HyperConverged Appliance (HCA) All-Flash, полностью построенного на SSD-накопителях. Обновленные аппаратные конфигурации StarWind HCA, выполненные в форм-факторе 1 или 2 юнита, позволяют добиться максимальной производительности хранилищ в рамках разумной ценовой политики. Да, All-Flash постепенно становится доступен, скоро это смогут себе позволить не только большие и богатые компании.
Решение StarWind HCA - это множество возможностей по созданию высокопроизводительной и отказоустойчивой инфраструктуры хранилищ "все-в-одном" под системы виртуализации VMware vSphere и Microsoft Hyper-V. Вот основные высокоуровневые возможности платформы:
Поддержка гибридного облака: кластеризация хранилищ и active-active репликация между вашим датацентром и любым публичным облаком, таким как AWS или Azure
Функции непрерывной (Fault Tolerance) и высокой доступности (High Availability)
Безопасное резервное копирование виртуальных машин
Проактивная поддержка вашей инфраструктуры специалистами StarWind
И многое, многое другое
Сейчас спецификация на программно-аппаратные модули StarWind HCA All-Flash выглядит так:
После развертывания гиперконвергентной платформы StarWind HCA она управляется с помощью единой консоли StarWind Command Center.
Ну и самое главное - программно-аппаратные комплексы StarWind HCA All-Flash полностью на SSD-дисках продаются сегодня, по-сути, по цене гибридных хранилищ (HDD+SSD). Если хотите узнать больше - обращайтесь в StarWind за деталями на специальной странице. Посмотрите также и даташит HCA.
Давайте посмотрим, что нового появилось в StarWind Virtual SAN V8 for Hyper-V:
Ядро продукта
Добавлен мастер для настройки StarWind Log Collector. Теперь можно использовать для этого соответствующее контекстное меню сервера в Management Console. Там можно подготовить архив с логами и скачать их на машину, где запущена Management Console.
Исправлена ошибка с заголовочным файлом, который брал настройки из конфига, но не существовал на диске, что приводило с падению сервиса.
Улучшен вывод событий в файлы журнала, когда в системе происходят изменения.
Улучшена обработка ответов на команды UNMAP/TRIM от аппаратного хранилища.
Добавлена реализация процессинга заголовка и блога данных дайждестов iSCSI на процессорах с набором команд SSE4.2.
Максимальное число лог-файлов в ротации увеличено с 5 до 20.
Механизм синхронной репликации
Процедура полной синхронизации была переработана, чтобы избежать перемещения данных, которые уже есть на хранилище назначения. Делается это путем поблочного сравнения CRC и копирования только отличающихся блоков.
Исправлена ошибка падения сервиса в случае выхода в офлайн партнерского узла при большой нагрузке на HA-устройство.
Значение по умолчанию пинга партнерского узла (iScsiPingCmdSendCmdTimeoutInSec) увеличено с 1 до 3 секунд.
Исправлена ошибка с утечкой памяти для состояния, когда один из узлов был настроен с RDMA и пытался использовать iSER для соединения с партнером, который не принимал соединений iSER.
Нотификации по электронной почте
Реализована поддержка SMTP-соединений через SSL/STARTTLS.
Добавлена возможность аутентификации на SMTP.
Добавлена возможность проверки настроек SMTP путем отправки тестового сообщения.
Компоненты VTL и Cloud Replication
Список регионов для всех репликаций помещен во внешний файл JSON, который можно просто обновлять в случае изменений на стороне провайдера.
Исправлена обработка баркодов с длиной, отличающейся от дефолтной (8 символов).
Исправлена ошибка падения сервиса при загрузке tape split из большого числа частей (тысячи).
Исправлены ошибки в настройках CloudReplicator Settings.
Модуль StarWindX PowerShell
Обновился скрипт AddVirtualTape.ps1, был добавлен учет параметров, чувствительных к регистру.
Для команды Remove-Device были добавлены опциональные параметры принудительного отсоединения, сохранения сервисных данных и удаления хранимых данных на устройстве.
Добавлен метод IDevice::EnableCache для включения и отключения кэша (смотрите примеры FlashCache.ps1 и FlushCacheAll.ps1).
VTLReplicationSettings.ps1 — для назначения репликации используется число, кодирующее его тип.
Свойство "Valid" добавлено к HA channel.
Сценарий MaintenanceMode.ps1 — улучшенная обработка булевых параметров при исполнении сценария из командной строки.
Тип устройства LSFS — удален параметр AutoDefrag (он теперь всегда true).
Средство управления Management Console
Небольшие улучшения и исправления ошибок.
Скачать полнофункциональную пробную версию StarWind Virtual SAN for Hyper-V можно по этой прямой ссылке. Release Notes доступны тут.
Таги: StarWind, Update, Storage, iSCSI, HCA, Hardware, SSD, HA, DR
Cody Hosterman, известный своими заметками про PowerCLI, написал интересную статью о том, как запоминать дефолтные параметры на примере свойств соединения с дисковым массивом. Это может вам оказаться полезным, например, в случае если вы работаете с дисковым массивом в интерактивном режиме, при этом не хотите каждый раз указывать параметры соединения.
К примеру, при использовании модуля PureStorage.FlashArray.VMware есть возможность передавать параметры соединения, сохраненные в глобальной переменной $Global:DefaultFlashArray. Неудобство этого метода в том, что каждый раз вы должны указывать параметр -Array:
Поэтому в PowerCLI заложен отличный механизм дефолтных параметров для нужных вам командлетов. Например, можно создать переменную с параметрами соединения с массивом:
Далее можно записать эту переменную в дефолтные параметры:
$PSDefaultParameterValues = @{
"*-pfa*:Array"=$flashArray;
}
Это позволит для параметра, называющегося Array применять параметры соединения из переменной $flashArray. При этом эти параметры будут применяться только для командлетов, содержащих "-pfa" в своем названии (они есть только в модуле PureStoragePowerShellSDK).
Для всего модуля и всех командлетов нет простого способа задать дефолтные параметры, но можно получить в сценарии список всех доступных командлетов и для всех них прописать правило использования параметра -Array:
После этого вы сможете просто использовать командлеты без параметров, например, Get-PfaVolumes, чтобы получить все тома с заданного в дефолтном соединении массива:
Аналогично способ будет работать и для всех остальных параметров командлетов и любых других модулей.
Сегодня мы расскажем об отличиях коммерческой и бесплатной версий одного из лучших решений для создания отказоустойчивых программных хранилищ под виртуальные машины StarWind Virtual SAN. Последний раз мы писали о сравнении возможностей платной и бесплатной версий в далеком 2017 году, и с тех пор, конечно же, много что изменилось.
Многие администраторы виртуальных инфраструктур в курсе про технологию NVMe (интерфейс Non-volatile Memory дисков SSD), которая была разработана для получения низких задержек и эффективного использования высокого параллелизма твердотельных накопителей. Такие устройства хоть и стоят дороже, но уже показывают свою эффективность за счет использования десятков тысяч очередей команд, что дает очень низкие задержки, требующиеся в таких сферах, как системы аналитики реального времени, онлайн-трейдинг и т.п.
К сожалению, протокол iSCSI (да и Fibre Channel тоже) разрабатывался тогда, когда инженеры еще не думали об архитектуре NVMe и высоком параллелизме, что привело к тому, что если использовать iSCSI для NVMe, использование таких хранилищ происходит неэффективно.
Главная причина - это одна очередь команд на одно устройство NVMe, которую может обслуживать iSCSI-протокол, весь смысл параллелизма теряется:
Вторая проблема - это то, что iSCSI использует процессор для диспетчеризации операций ввода-вывода, создавая дополнительную нагрузку на серверы, а также имеет некоторые сложности по перенаправлению потоков операций для нескольких контроллеров NVMe и устройств хранения на них.
Для этого и был придуман протокол NVMe over Fabrics (NVMe-oF), который не имеет таких ограничений, как iSCSI. Еще один его плюс - это то, что он обратно совместим с такими технологиями, как InfiniBand, RoCE и iWARP.
Компания StarWind сделала свою реализацию данного протокола для продукта StarWind Virtual SAN, чтобы организовать максимально эффективное использование пространства хранения, организованного с помощью технологии NVMe. Об этом было объявлено еще осенью прошлого года. Он поддерживает 64 тысячи очередей, в каждой из которых, в свою очередь, может быть до 64 тысяч команд (в реальной жизни в одной очереди встречается до 512 команд).
Важный момент в реализации NVMe-oF - это применение технологии RDMA, которая позволяет не использовать CPU для удаленного доступа к памяти и пропускать к хранилищу основной поток управляющих команд и команд доступа к данным напрямую, минуя процессоры серверов и ядро операционной системы.
Также RDMA позволяет маппить несколько регионов памяти на одном NVMe-контроллере одновременно и организовать прямое общение типа точка-точка между инициаторами разных хостов (несколько Name Space IDs для одного региона) и этими регионами без нагрузки на CPU.
Такой подход, реализованный в продуктах StarWind, дает потрясающие результаты в плане производительности, о которых мы писали вот в этой статье. К этой статье можно еще добавить то, что реализация инициатора NVMe-oF на базе Windows-систем и таргета на базе Linux (который можно использовать в программно-аппаратных комплексах StarWind Hyperconverged Appliances, HCA) дала накладные издержки на реализацию всего 10 микросекунд по сравнению с цифрами, заявленными в даташитах производителя NVMe-устройств. Знающие люди поймут, насколько это мало.
Еще надо отметить, что бесплатный продукт StarWind NVMe-oF initiator - это единственная программная реализация инициатора NVMe-oF на сегодняшний день. В качестве таргета можно использовать решения Intel SPDK NVMe-oF Target и Linux NVMe-oF Target, что позволяет не зависеть жестко от решений StarWind.
Подробнее о StarWind NVMe-oF initiator можно узнать вот в этой статье. А загрузить его можно по этой ссылке.
На сайте проекта VMware Labs очередное обновление: вышло интересное средство для мониторинга кластеров VMware vSAN - мобильная утилита vSAN Live. С помощью данного приложения для iOS (9.0+) или Android (4.1+) можно организовать мониторинг инфраструктуры отказоустойчивых хранилищ vSAN, находясь за пределами инфраструктуры компании (например, в отпуске или командировке).
Полный список возможностей утилиты vSAN Live:
Дэшборд с обзором всех кластеров vSAN.
Полный набор выполняемых для vSAN хэлс чеков.
Просмотр структуры кластера, включая Fault domain и статусы хостов.
Простое переключение между серверами vCenter.
Просмотр конфигурации кластера, включая настройки vSAN и статус сервиса.
Полнофункциональный мониторинг производительности для виртуальных машин и кластера в целом, а также мониторинг емкости хранилищ кластера.
Самое полезное - это возможность выполнять health checks, что даст возможность понять, что и где сломалось в кластере vSAN:
Скачать приложение vSAN Live можно по этим ссылкам:
Для начала работы с приложением нужно скачать сертификат, расположенный на сервере vCenter по адресу:
https://<VC_FQDN>/afd/vecs/ca
Для установки сертификата на iOS:
Идем в Settings -> General -> Profiles -> CA -> Install
Далее: Settings -> About -> Certificate Trust Settings -> CA (enable)
Для установки сертификата на Android:
Открываем сертификат -> Даем ему имя -> Ставим "Credential Use: VPN and apps" -> жмем OK
Пока это всего лишь первая версия утилиты, в дальнейшем, будем надеяться, там появится еще больше интересных функций.
В последних числах августа компания StarWind Software, выпускающая продукты для организации хранилищ под виртуализацию, выпустила обновленную версию решения для создания iSCSI-хранилищ на платформах vSphere и Hyper-V - StarWind Virtual SAN V8 build 13182. Давайте посмотрим, что нового появилось в этом продукте...