Релиз VMware vSAN 7 Update 3

В прошлом году стала доступна новая версия VMware vSAN 7 Update 3, которая доставляет гибкость, устойчивость и готовность к будущим нагрузкам в инфраструктуру. Чтобы материал не остался лежать в столе, я решил опубликовать его сейчас.

VMware vSAN предоставляет общую модель управления в периметре, облаке или корневом центре обработки данных (ЦОД). В новом релизе увеличена надежность платформы, упрощено управление и просмотр, а также расширена инфраструктура для разработки.

Улучшения платформы.

Улучшенная устойчивость для пограничных развертываний и наблюдателя.

Растянутые кластеры vSAN – это мощная топология, которая обеспечивает полную устойчивость в окружении, даже в случае выхода из строя географического расположения (сайта) по какой-либо из причин. VMware vSAN 7 Update 3 увеличивает доступность данных в случае недоступности сайта данных с последующей запланированной или не запланированной доступностью хоста наблюдателя. Доступность данных достигается за счет обеспечения защиты виртуальных машин и данных на уровне сайта, когда сайт данных и хост наблюдатель отключены (Offline). Эта возможность похожа своим поведением на конфигурацию синхронной репликации в массиве хранилища, она применима не только к растянутым кластерам (Stretched Clusters), но и к двух-узловым кластерам vSAN.

Многие клиенты VMware нашли двух-узловую топологию vSAN экстраординарно эффективной для сценариев с удаленным расположением, а также для реализации в периметре. Двух-узловые топологии высоко эффективны за счет предоставления устойчивости к событиям выхода из строя одного из хостов. В vSAN 7 Update 3 эта возможность была расширена за счет добавления вторичного уровня устойчивости. Практически также как растянутые кластеры vSAN, двух-узловые топологии теперь предлагают второй уровень устойчивости при наличии трех и более дисковых групп на хосте. Это значит, что топология способна выдержать полный выход из строя одного хоста, отказ наблюдателя и выход из строя дисковой группы на оставшемся хосте и при этом предоставлять полную доступность данных.

Поддержка хранения ключей через Trusted Platform Module (TPM) на хосте.

VMware vSAN предлагает службы шифрования для обеспечения целостности данных, хранящихся в окружении. Для шифрования данных в состоянии покоя (Data-at-Rest Encryption) управление ключами может обеспечиваться за счет vSphere Native Key Provider (NKP) или внешней службы управления ключами (KMS). В vSAN 7 Update 3 представлена полная поддержка использования Trusted Platform Module (TPM) на хостах с кластером vSAN для сохранения распределенных ключей, что защищает от ошибок коммуникаций с поставщиком ключей. Использование TPM полностью поддерживается при помощи vSphere NKP или внешнего управления ключами (KMS) и является одним из лучших методов построения надежного метода распространения и хранения ключей.

Упрощенное управление.

Анализатор ввода/вывода виртуальной машины, интегрированный в vCenter Server.

Поиск узких мест производительности в распределенных системах хранения, таких как vSAN может стать серьезным испытанием. В vSAN 7 Update 3 добавлен VM I/O Trip Analyzer для определения основных точек конкуренции. За счет возможности иллюстрации части пути данных в интерфейсе vCenter Server, администраторам предоставляется визуализация с индикацией возможных причин. Новая возможность не только отобразит визуальный путь данных, но и измерит вариативность (стандартное отклонение) времени задержки системы, которое поможет администраторам ответить на вопросы производительности и согласованности компонентов. Это дополняет существующие представления производительности vSAN, а также обеспечивает подробности ввода/вывода (IO Insight) для гранулированного отслеживания профилей ввода/вывода определенных виртуальных машин.

Корреляция проверок здоровья Skyline для vSAN.

Проверки здоровья Skyline для кластера vSAN – это внушительный список проверок для захвата наиболее популярных ошибок, таких как ошибки в настройке. Новая логика vSAN 7 Update 3 обладает способностью понять связь между проверками здоровья для более быстрого и эффективного устранения неисправностей. Понимание связей между несколькими вызванными проверками здоровья позволяет быстрее выявлять корневую причину неисправности, что поможет устранить большинство или даже все предупреждения. Функционал также доступен через API, что позволяет использовать его в других решениях, таких как vRealize Operations.

Расширения мониторинга сети.

VMware vSAN 7 Update 3 представил несколько новых метрик и проверок здоровья для предоставления лучшей видимости фабрики коммутации, подключенной к хостам vSAN, и возможности убедиться в наивысшем уровне целостности кластера. Обнаружение дублирования IP-адресов теперь является частью проверок здоровья, как и обнаружение ошибок синхронизации LACP, которые могут привести к задержкам в конфигурации.

Интеллектуальные рабочие потоки остановки и запуска кластера.

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

Расширение vLCM для поддержки дополнительных рабочих потоков vSAN.

vSphere Lifecycle Manager (vLCM) представил полностью новые уровни управления жизненным циклом хостов в кластерах vSphere и vSAN. VMware vSAN 7 Update 3 предоставил поддержку для топологий vSAN с выделенным хостом-наблюдателем (Witness Host Appliance). Как растянутые кластеры, так и двух-узловые окружения с выделенным наблюдателем, теперь могут управляться и обновляться при помощи vLCM. Дополнительно vSphere Lifecycle Manager теперь может выполнять проверку устройств хранения NVMe по списку совместимого оборудования (HCL).

Доставка инфраструктуры для разработки.

VMware продолжает расширять возможности vSphere и vSAN для соответствия потребностям разработчиков и администраторов. Современная инфраструктура – это ключ к быстрой и эффективной доставке сервисов.

Поддержка растянутых кластеров vSAN для кластеров Kubernetes.

Инфраструктура для разработки должна соответствовать множеству требований организации и разработчиков, которые создают и управляют приложениями. Доступность на уровне сайта часто является одним из таких требований. VMware vSAN 7 Update 3 представляет расширения в платформе для обеспечения требований к устойчивости на уровне сайта. Растянутые кластеры могут быть идеальными для окружений, использующих постоянные тома в оригинальном Kubernetes. Все те же возможности устойчивости, присутствующие в растянутых кластерах vSAN и доступные для традиционных рабочих нагрузок, будут доступны для Kubernetes, в том числе второй уровень устойчивости и привязка к сайту (Site-affinity).

Новые сертифицированные облачные решения и улучшенное обновление.

Вместе с новейшей версией vSAN стали доступны новые сертифицированные операторы постоянных сервисов от партнеров. Партнеры VMware – независимые поставщики программного обеспечения, самостоятельно выпускают анонсы своих предложений, но самое интересное здесь заключается в том, что начиная с VMware vSAN 7 Update 3 операторы могут обновляться без необходимости в обновлении vSphere, vSAN или vCenter Server. Разделение управления жизненным циклом постоянных сервисов (Persistent Services) обозначает более простые обновления для клиентов.

Файловые и блочные постоянные тома в vSphere с Tanzu.

Вместе с новейшей редакцией, использование файловых томов с множественным доступом для записи (Read-Write-Many, RWM) теперь поддерживается в vSphere с Tanzu, в дополнение к блочным томам с единичным доступом для записи (Read-Write-Once, RWO), поддерживаемым в предыдущих версиях. Предоставление полностью новых уровней гибкости и эффективности для микро-сервисов с целью упрощения монтирования и доступа к постоянным томам, как и другим подам в кластере. Тома с множественным доступом для записи (RWM) могут быть легко предоставлены гостевым кластерам Tanzu Kubernetes Grid (TKG) при помощи файловых служб vSAN.

Дальнейшие шаги.

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

Подробнее познакомиться с новыми возможностями VMware vSphere 7 Update 3 можно при помощи моей статьи «Релиз VMware vSphere 7 Update 3».

Новое в VMware vSAN 7 Update 2

Обладая клиентской базой в 30 000 внедрений, команда разработки VMware vSAN не останавливается на достигнутом и продолжает реализовывать инновации. 9 марта 2021 года был анонсирован vSAN 7 Update 2, который доставляет гибкую, устойчивую, готовую к текущим и будущим нагрузкам инфраструктуру, что позволит клиентам соответствовать динамическим требованиям бизнеса без компромиссов в производительности, эффективности или надежности. Команда разработки расширила удобство vSAN, развернутого на различных физических топологиях, чтобы клиенты могли лучше удовлетворять потребности роста рабочих нагрузок.

Масштабирование без компромиссов.

Вычислительные кластеры vSAN HCI Mesh.

VMware представила потрясающую новую возможность в vSAN HCI Mesh:

• В vSAN 7 Update 2 традиционные кластеры vSphere могут монтировать удаленное хранилище данных vSAN (Datastore). 
• Вычислительные кластеры HCI Mesh могут потреблять ресурсы хранилища, предоставляемые удаленными кластерами vSAN. 
• Кластеры vSphere могут подключаться к традиционным массивам хранилища. 

Вычислительные кластеры HCI Mesh используют протоколы vSAN для максимальной эффективности и возможности клиента с легкостью удовлетворить потребности любого сценария применения. 

Наиболее важное заключается в том, что вычислительные кластеры HCI Mesh не требуют какого-либо лицензирования vSAN.

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

Одна из наиболее интересных возможностей, относящихся к HCI Mesh – это интеграция с политиками хранения (Storage Policies). Теперь, при определении политик хранения, администратор может выбирать тип службы данных (такой как дедубликация и сжатие (Deduplication and Compression) или шифрование в состоянии покоя (Data-at-rest Encryption)).

Расширенные файловые службы.

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

Улучшения растянутого кластера.

Конфигурация растянутого кластера должна учитывать не только различные сценарии отказа, но и условия восстановления. vSAN 7 Update 2 представил интеграцию с размещением данных и распределенным планировщиком ресурсов (DRS), таким образом, вслед за восстановлением после сбоя, DRS будет удерживать состояние виртуальной машины в сайте, до тех пор, пока данные не будут повторно синхронизированы. Это гарантирует, что операции чтения не будут использовать каналы между сайтами (ISL). Только после полной повторной синхронизации DRS начнет перемещать состояние виртуальных машин в требуемые сайты в соответствии с правилами DRS. Это улучшение может существенно сократить не нужные операции чтения и освободить ресурсы каналов между сайтами (ISL) для выполнения повторной синхронизации с восстанавливаемым сайтом. Также следует отметить что vSAN 7 Update 2 увеличил максимальное количество хостов растянутого кластера до 40.

vSAN через RDMA.

Удаленный прямой доступ к памяти (RDMA) – технология, которая позволяет системам обходить процессор и отправлять данные с меньшей задержкой и сокращением накладных вычислительных затрат. В результате получается не только сократить потребление вычислительных ресурсов, но и увеличить производительность хранилища. Гиперконвергкнтная архитектура идеально подходит для RDMA и vSAN 7 Update 2 представил поддержку RDMA over Converged Ethernet version 2 (RCoEv2). Кластеры будут автоматически определять поддержку RDMA, что, в свою очередь, приведет к увеличению производительности приложений и консолидации нагрузок.

Оптимизация производительности.

В vSAN 7 Update 2 улучшена производительность и эффективность процессора при обработке операций RAID 5/6. Это обеспечивает эффективность пространства за счет очищающего кодирования (Erasure Coding) и в то же время увеличивает производительность приложений, сокращая накладные расходы процессора на каждую операцию ввода/вывода.

AMD EPYC.

В гипервизор и пути данных vSAN были добавлены оптимизации для соответствия возможностям процессоров AMD EPYC.

Инфраструктура разработки и искусственного интеллекта (AI).

Совместимое с S3 хранилище объектов для искусственного интеллекта/машинного обучения (AI/ML) и облачных приложений (Cloud Native Apps).

В начале февраля 2021-го года была анонсирована доступность Cloudian HyperStore и MinIO Object Storage на платформе постоянных данных vSAN. Теперь клиенты могут эффективно разворачивать, потреблять и управлять объектным хранилищем (совместимым с S3) для искусственного интеллекта/машинного обучения (AI/ML) и облачных приложений прямо из VMware HCI. Современные приложения могут быть развернуты при помощи нескольких кликов. Подобная автоматизация упрощает развертывание и настройку, а также гарантирует настройку решения в соответствии с рекомендациями производителя.

Расширенное облачное хранилище в vSphere и vSAN.

Облачное хранилище (Cloud Native Storage) в vSphere и vSAN было расширено для лучшей поддержки приложений с отслеживанием состояния на базе Kubernetes. Пользователи устаревшего облачного поставщика vSphere (vSphere Cloud Provider, vCP) могут легко мигрировать на драйвер интерфейса хранилища контейнеров (Container Storage Interface, CSI). Это позволяет Kubernetes развертывать и управлять постоянными томами, запущенными на платформе vSphere, которые поддерживают изменение размера без остановки. Использование драйвера CSI в vSphere и vSAN позволяет администраторам и разработчикам эффективно разворачивать, управлять и вести мониторинг приложений в контейнерах и виртуальных машинах, развернутых на единой платформе.

Улучшенная безопасность.

Простой поставщик ключей vSphere.

Вместе с vSphere и vSAN 7 Update 2 была представлена поддержка компонента «Native Key Provider», который может упростить управление ключами для окружений, использующих шифрование. Встроенная служба управления ключами (KMS) идеально подходит для vSAN в двух-узловых топологиях, развертывания в периметре, также это отличный пример, демонстрирующий подход VMware к внутренней безопасности. Дополнительно Native Key Provider поддерживает работу с ESXi Key Persistence для устранения зависимостей.

Инструменты для изолированных окружений.

Skyline Health Diagnostics – это инструмент самообслуживания, который добавляет некоторые преимущества Skyline Health напрямую в изолированное окружение. Инструмент запускается администратором с требуемой частотой. Он будет сканировать журналы для обнаружения ошибок и выдачи уведомлений к важным ошибкам со ссылками на соответствующие статьи в базе знаний (KB). Разработчики ставили перед собой цель – сократить время, которое администраторы тратят на устранение ошибок в изолированных окружениях.

Улучшения шифрования передаваемых данных (Data In Transit, DIT).

Модуль криптографии для шифрования DIT прошел проверку FIPS 140-2.

Упрощенное управление.

Расширения vSphere Lifecycle Manager (vLCM).

vSAN 7 Update 2 доставляет три расширения в vSphere Lifecycle Manager:

• vLCM расширил возможности выбора систем Hitachi Vantara UCP-HC и Hitachi Advanced Servers в дополнение к серверам Dell 14G, HPE10G и Lenovo ThinkAgile, которые работают с vLCM.
• vLCM теперь поддерживает кластеры vSphere с Tanzu и сетями NSX-T.
• Создание кластера было упрощено за счет возможности выбора образа с существующего хоста.

Улучшенная устойчивость данных.

В случае возникновения незапланированного отключения vSAN 7 Update 2 будет немедленно записывать все инкрементальные обновления на дополнительный хост, помимо хостов, удерживающих активную реплику объекта. Это поможет гарантировать устойчивость измененных данных в случае отключения еще одного хоста, удерживающего активную реплику объекта. Данная возможность построена на базе улучшений, представленных в vSAN 7 Update 1, где эта техника использовалась для запланированных событий обслуживания. Это улучшение надежности данных имеет еще одно преимущество: сокращение времени за которое выполняется повторная синхронизация устаревших объектов.

Проактивная высокая доступность (Proactive HA).

vSAN 7 Update 2 теперь поддерживает vSphere Proactive HA, что позволяет превентивно мигрировать состояние приложений и любые потенциально сохраненные данные на другой хост.

Расширенный мониторинг.

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

Быстрая загрузка vSphere.

Быстрая загрузка (Quick Boot) была расширена новой опцией «приостановка в памяти» (Suspend-to-memory). Это обеспечивает быструю установку исправлений с низким влиянием на vSphere без необходимости выполнять полную эвакуацию хоста.

Следующие шаги.

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

Дополнительные сведения о VMware vSphere 7 Update 2 можно получить в моей статье «Релиз VMware vSphere 7 Update 2».

Рекомендации по проектированию VMware vSAN: Дедубликация и сжатие

В предыдущей статье «Рекомендации по проектированию VMware vSAN: Использование устройств хранения большого объема» мы рассмотрели множество базовых вещей по поводу применения двухуровневой системы хранения vSAN и того как оборудование может менять производительность системы. Остался не закрытым вопрос, связанный с программными параметрами – как дедубликация и сжатие влияют на производительность? Сегодня мы рассмотрим, что это такое, как они применяются в vSAN, а также как и при каких условиях влияют на производительность.

Дедупликация и сжатие.

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

Метод, который используется для достижения эффективности пространства зависит от конечного решения и может оказывать влияние на уровень сохранения пространства, а также на требуемую нагрузку для достижения результата. Не имеет значения, какой метод используется, обе техники (дедубликация и сжатие) условно патогенные возможности обеспечения эффективности пространства: уровень сохраненного пространства не гарантируется. Для сравнения, техники размещения данных с использованием очищающего кодирования (Erasure Codes), такие как RAID5 или RAID6 детерминированы: они предоставляют гарантированный уровень эффективности пространства для данных, сохранённых устойчивым образом.

Реализация дедубликации и сжатия в vSAN.

Дедубликация и сжатие (DD&C) в vSAN включаются на уровне кластера, как единая возможность эффективности пространства. Процесс выполняется, когда данные достигают уровня хранения (Capacity Tier) – сразу после отправки уведомления обратно в виртуальную машину. Минимизация любых форм манипуляции данными до отправки уведомления позволяет сохранять низким уровень задержки, наблюдаемый в виртуальной машине.

После доставки данных, процесс дедубликации будет искать возможность выполнить дедубликацию блока данных (4КБ) в рамках дисковой группы: домена дедубликации vSAN. Эта задача сопровождается процессом сжатия. Если блок данных (4КБ) может быть сжат до 50% объема или более – то он сжимается, иначе блок остаётся прежним и сохраняется на уровне хранения (Capacity Tier).

Такое применение DD&C позволяет избежать удара по производительности, который происходит в линейных системах, выполняющих дедубликацию данных до отправки ответа гостевой системе. Это также позволяет избежать дополнительных нагрузок, связанных с дедубликацией уже хранящихся данных. Несмотря на то, что процесс DD&C происходит после отправки подтверждения записи гостевой виртуальной машине, включение его в vSAN может повлиять на производительность в ряде случаев, которые мы рассмотрим дальше.

Основы двухуровневой системы хранения.

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

Двухуровневые системы, такие как vSAN, имеют два теоретических максимума производительности: Burst Rate, представляющий возможности буферного уровня (Buffer Tier) и Steady-State Rate, представляющий возможности уровня хранения (Capacity Tier). Лежащее в основе каждого уровня оборудование имеет огромное влияние на производительность каждого из уровней, в то же время программные параметры, приложения и рабочие нагрузки также могут оказывать влияние.

Максимумы производительности хостов vSAN будут находится где-то между максимальными значениями Burst Rate и Steady-State Rate. Длительные синтетические тесты с использованием HCIBench создают достаточную нагрузку в окружении для расчета примерных значений при помощи временных графиков. Производственные нагрузки могут превысить максимально возможные значения при неправильном дизайне решения.

Потенциальное влияние на производительность.

Дедубликация и сжатие создают вычислительные нагрузки на оперативную память и дополнительный ввод/вывод. Это в любом случае так, вне зависимости от способа реализации. Все зависит от того, когда, где и как это происходит. В vSAN это происходит при перемещении данных с буферного уровня на уровень хранения, что в свою очередь, снижает эффективную пропускную способность уровня хранения (Capacity Tier). Далее это может снизить максимальное значение Steady-State Rate, которое мог бы предоставить кластер. Другими словами, кластер с включённым DD&C имеет такую же производительность, что и кластер с отключенным DD&C, у которого менее производительные устройства на уровне хранения.

При условии, что остальные переменные остаются неизменными, снижение максимального значения Steady-State Rate уровня хранения будет демонстрировать следующее поведение:

• Буфер записи может заполняться быстрее, так как разница в производительности между уровнями увеличилась за счёт снижения производительности уровня хранения (Capacity Tier).
• Буфер записи будет очищаться медленнее из-за снизившейся производительности доставки.
• Время подтверждения записи (задержка записи) гостевой виртуальной машины может быть поражено, если начнется доставка. Уровень влияния зависит от нескольких факторов, в том числе и от скорости доставки на уровень хранения (Capacity Tier). Это наиболее частый сценарий, когда агрегированный рабочий набор данных значительно превышает ёмкость буферного уровня (Buffer Tier) или при быстром цикле загрязнения, который в значительной степени зависит от уровня хранения (Capacity Tier).
• Время подтверждения записи (задержка записи) гостевой виртуальной машины останется неизменным если буфер не достигнет какого-либо предела. Это типично для малых агрегированных рабочих наборов, которые свободно помещаются на уровне буфера (Buffer Tier) и не испытывают проблем с доставкой буфера.

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

Очищающее кодирование (Erasure Coding) RAID5/6 – это другая опция эффективности пространства, включаемая на уровне виртуальной машины или виртуального диска (VMDK) при помощи политик хранилища (Storage Policy). Совместное использование техник эффективности хранения также может привести к заметному влиянию на производительность.

Опции настройки.

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

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

• Более быстрые устройства на уровне хранения (Capacity Tier). Если при включении DD&C задержка виртуальных машин будет больше, чем ожидалось, необходимо рассмотреть более быстрые устройства на уровне хранения. Это может помочь противодействовать сокращённой производительности при включенном DD&C. Недостаточно производительные устройства на уровне хранения (Capacity Tier) – одна из наиболее частых причин ошибок производительности.
• Использование большего числа дисковых групп. Это будет добавлять больше ёмкости буфера, увеличивая ёмкость для горячих рабочих наборов данных и сокращая безотлагательность доставки данных. Необходимо использовать минимум две дисковые группы, рекомендованная конфигурация – три дисковые группы.
• Следует обратить внимание на новые устройства хранения высокой плотности для уровня хранения, чтобы соответствовать требованиям объема (ёмкости). Если они будут соответствовать требованиям производительности, то это может позволить отказаться от использования DD&C. Подробнее об этом я писал в предыдущей статье: «Рекомендации по проектированию VMware vSAN: Использование устройств хранения большого объема».
• Использование новейшей версии vSAN. Последние редакции vSAN сфокусированы на улучшении производительности для кластеров с DD&C: улучшении целостности задержки в виртуальных машинах и увеличении скорости доставки через программные оптимизации.
• Выборочное включение DD&C. Необходимо включать DD&C только в тех кластерах, которые представляют подходящую производительность для поддержки необходимых рабочих нагрузок. Опционально, политики хранилища для эффективности пространства, такие как RAID-5/6 должны быть применены для отдельных рабочих нагрузок, где они наиболее чувствительны. Также существуют компромиссные решения для производительности за счёт использования очищающего кодирования (Erasure Coding).

Итоги.

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

P.S. Предыдущие статьи цикла:

• Рекомендации по проектированию VMware vSAN: Быстрые устройства хранения или быстрая сеть
• Рекомендации по проектированию VMware vSAN: Использование устройств хранения большого объема.

Рекомендации по проектированию VMware vSAN: Использование устройств хранения большого объема.

Окружения vSAN и VMware vCloud Foundation (VCF) на базе vSAN предлагают экстраординарную гибкость в масштабировании. Емкость можно увеличивать вертикально, добавляя устройства в хосты, или горизонтально, за счет добавления новых узлов. Вместе с представленной поддержкой емкости устройств до 32 Тб в vSAN 7, необходимо разобраться – как же экстремально большие флэш-устройства влияют на проектирование? Рассмотрим вопрос проектирования более детально.

Больший объем хранилища эквивалентен большему объему потенциального ввода/вывода.

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

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

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

Рекомендации для шины устройства и протокола.

Многие устройства высокой плотности привязаны к числовому значению объема и не предполагают уровней производительности и целостности, как правило ожидаемых в корпоративных окружениях. Флэш-устройства хранения с интерфейсом SATA относятся к данной категории. Такие устройства будут постоянно перегружены в борьбе за производительность и целостность из-за различных ограничений протокола, таких как: полудуплексная сигнализация, одно-командные очереди и более ресурсоемкая обработка ввода/вывода процессором. Устройства с SATA-подключением лучше подходят для конечных устройств и домашнего сегмента, так как характеристики SATA не рассчитаны на одновременный двунаправленный доступ к общему хранилищу.

При рассмотрении возможности использования устройств большого объема, следует отталкиваться от флэш-устройств на базе SAS. Следует отметить, что NVMe – это превосходный стандарт и это лишь вопрос времени, когда этот высокоэффективный протокол шины захватит корпоративные окружения. Устройства NVMe с использованием NAND флэш ИЛИ 3D XPoint уже доминируют в областях с фокусом на производительности, таких как кэширование и буферизация.

Устройства высокой плотности могут создавать излишнюю нагрузку на общих адаптерах шины хоста (HBA), SAS в данном случае подходит лучше, чем SATA, но узкие места все равно могут возникать на общем контроллере, по мере увеличения траффика. Устройства NVMe не подвержены подобным проблемам, так как каждое устройство NVMe содержит собственный контроллер.

Рекомендация: Для устройств с большим объемом необходимо использовать как минимум устройства на базе SAS, идеальным же выбором на данный момент являются устройства NVMe.

Рекомендация.

Для устройств с большим объемом необходимо использовать как минимум устройства на базе SAS, идеальным же выбором на данный момент являются устройства NVMe.

Рекомендации по проектированию дисковых групп (Disk Group).

Использование устройств со значительно большим объемом, неизбежно будет приводить к большему объему рабочих нагрузок, что в свою очередь может создавать дополнительный стресс на уровне буферизации. Это происходит из-за того, что дополнительные виртуальные машины обычно увеличивают агрегированный размер рабочего набора между хостами в кластере. Больший объем рабочих нагрузок, как правило, обозначает больше горячих данных. Несмотря на то, что vSAN Design and Sizing Guide описывает подбор размера уровня буфера в окружении с использованием только флэш-накопителей (All-flash) на базе информации о производительности, использование буфера большого объема для обеспечения большего объема рабочих нагрузок является разумным шагом.

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

Рекомендация.

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

Рассчитывая необходимую производительность, зачастую слишком много внимания уделяют уровню хранения (Capacity Tier), особенно при увеличении емкости на хостах. Уровень буферизации (Buffer Tier) обеспечивает максимальное увеличение скорости ввода/вывода, а уровень хранения (Capacity Tier) обеспечивает максимальную скорость постоянного хранилища. Когда уровень хранения (Capacity Tier) не обладает достаточной высокой производительностью, длительная запись на высоком уровне может сокрушить возможности буфера. Скорость очистки буфера, обычно (но не всегда) зависит от производительности уровня хранения. В таком случае использование более быстрых флэш-устройств и/или их большего количества может увеличить производительность уровня хранения. Это поможет сократить задержку на уровне буфера за счет более быстрой очистки (передачи) и позволит избежать задержки на уровне гостевых виртуальных машин.

Отключение дедубликации (Deduplication) и сжатия (Compression) также являются возможными опциями увеличения производительности уровня хранения. Дедубликация и сжатие – это процессы, которые требуют дополнительной нагрузки во время опустошения буфера, напрямую сокращающие скорость опустошения. Устройства большего размера, предоставленные кластеру, могут обеспечить требуемый объем, без необходимости включения данных возможностей.

Рекомендация.

Если требуется обеспечить производительность уровня хранения, рекомендуется использовать высокопроизводительные устройства SAS или NVMe на уровне хранения.

Рекомендации по времени эвакуации и восстановления.

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

 

Одной и той же сети с пропускной способностью 10 Gbps для хостов, которые теперь обладают новым объемом, в 4, 8 или 12 раз больше предыдущих конфигураций, может попросту не хватить для обеспечения такой плотности виртуальных машин на хостах. Подробнее об этом я писал в статье «Рекомендации по проектированию VMware vSAN: Быстрые устройства хранения или быстрая сеть». Корректно сбалансированный кластер vSAN будет всегда иметь доступные хосты для любых потенциальных повторных синхронизаций объектов данных, которые помогают поддерживать их на заданном уровне соответствия. Процесс автоматизирован и прозрачен для администратора. Но скорость, с которой он происходит, зависит от производительности сети и устройств хранения. Предполагаемое время эвакуации хоста и восстановления приближается к уровню комфорта, когда необходимое время для переноса всей емкости с одного хоста на другой в случае выхода хоста из строя не выходит за рамки возможного простоя.

Рекомендация.

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

Рекомендации по количеству хостов.

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

Рекомендация.

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

Итоги.

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

VMware vSphere 7: Современные приложения и Kubernetes

Мощь vSphere всегда заключалась в ее возможности поддерживать любые приложения (на базе архитектуры x86), запуская эти приложения быстро и безопасно, при этом предоставляя окружение с простым управлением. За последние 20 лет, клиенты и партнёры VMware запустили порядка 70 миллионов приложений на vSphere. Несмотря на то что современные приложения нормально запускаются на vSphere, главный вопрос, который стоял перед командой разработки – как сделать vSphere лучшим местом для запуска новых приложений, лучше, чем любые другие современные инфраструктуры. VMware уверена, что vSphere 7 с Kubernetes, может стать лучшем местом для размещения современных приложений.

На VMworld 2019, был анонсирован Project Pacific, предварительная версия для ознакомления с технологией того, как VMware интегрирует Kubernetes с vSphere. Это очевидная и достаточно обоснованная идея – взять лучшее из Kubernetes и применить к vSphere, в то же время лучшее из vSphere применить к Kubernetes. vSphere 7 – это результат данной фундаментальной работы с технологиями. В отличие от многих других анонсов вокруг vSphere 7, Project Pacific не является компонентом vSphere – это и есть vSphere. Сама vSphere была существенно расширена для включения всех этих потрясающих новых возможностей.

Joe Beda, автор фразы, что Kubernetes – это “платформа платформ”. Иначе говоря, Kubernetes – это потрясающая платформа, на которой можно создавать другие новые платформы. VMware использовала Kubernetes и как инфраструктурный интерфейс, и как интерфейс расширения для доставки множества новых возможностей в vSphere. Это значит, что все потрясающие новые возможности vSphere находятся в ней, но также они доступны через новый путь – через Kubernetes. Это открывает потрясающую возможность для разработчиков, которые используют интерфейс Kubernetes для разработки и запуска современных приложений.

Project Pacific обеспечивает это мощное расширение возможностей за счёт vSphere через Kubernetes. VMware использовала эту расширяемость для доставки новых дифференцированных сервисов поверх vSphere и VMware Cloud Foundation. Этот набор сервисов называется VMware Cloud Foundation Services:

Tanzu Runtime Services

Tanzu Kubernetes Grid (TKG) предоставляет целостные возможности Kubernetes в облаках. С его помощью клиенты могут быстро разворачивать и управлять кластерами Kubernetes в любых расположениях, где требуется запускать рабочие нагрузки на базе Kubernetes (на базе vSphere и не только). Целью TKG является доставка комплексных возможностей при помощи Kubernetes вне зависимости от фоновой инфраструктуры. Однако, когда TKG запущен на vSphere, можно использовать все инновации, созданные в рамках проекта Project Pacific, способные предложить лучшие возможности клиентам.

Например, кластеры Kubernetes могут быть самостоятельно развернуты разработчиками (Self-service) поверх vSphere через интерфейс Kubernetes. Администраторы виртуальных инфраструктур будут иметь полное представление данных кластеров и того, что разработчики будут разворачивать. Администраторы vSphere будут иметь возможность применять инструменты и политики vSphere к этим кластерам и подам, иначе говоря, TKG предлагает потрясающие возможности как для разработчиков, так и администраторов.

Hybrid Infrastructure Services.

Сервисы гибридной инфраструктуры (Hybrid Infrastructure Services) в большей степени это ключевые возможности vSphere или программно-определенного центра обработки данных (SDDC), предоставленные через Kubernetes. Службы сети и хранилища представлены функциональными возможностями хранилища vSphere (или vSAN) и NSX соответственно, позволяя любой рабочей нагрузке Kubernetes получать преимущества от оригинальных технологий SDDC.

vSphere Pod Service объединяет лучшее от контейнеров и виртуализации, запуская каждый под Kubernetes в собственной динамически создаваемой виртуальной машине. Идея здесь заключается в том, чтобы использовать изоляцию и безопасность виртуальной машины вместе с простотой и возможностями настройки пода. Поды vSphere также являются сущностями в vSphere, таким образом, администраторы виртуальных инфраструктур могут получить полную видимость пода из vSphere Client и использовать существующие инструменты для управления подами vSphere, также как виртуальными машинами.

Virtual Machine Service, несмотря на то что находится в предварительной версии для ознакомления с технологией, позволяет управлять виртуальными машинами при помощи Kubernetes. В такой модели все компоненты приложения: виртуальные машины, контейнеры и прочее – могут управляться через и при помощи Kubernetes.

Будущие сервисы (Future Services).

Как обсуждалось ранее, Kubernetes – это мощная точка расширения, и многие партнеры VMware создают интеграции Kubernetes для своих собственных задач. Теперь, когда vSphere 7 имеет интерфейс Kubernetes, команда разработки исследует вопрос, как помочь повысить интеграцию партнёрских решений в дополнение к vSphere. В данной расширяемой модели, партнерские решения будут предлагаться через Tanzu Application Catalog (ранее известного как Bitnami). Вместо того чтобы использовать только статические образы, партнерские решения должны быть актуальными сервисами, которые могут запускаться на любой инфраструктуре vSphere, где потребуется клиенту. Простым нажатием кнопки разработчик должен получать базу данных, систему обмена сообщениями, инфраструктуру машинного обучения или что-либо еще, разворачиваемое рядом с разрабатываемым приложением или запускаемое в производственную среду. Данная модель возможна благодаря интеграции vSphere с Kubernetes.

Управление с фокусом на приложениях (Application-Focused Management).

Как было сказано ранее, интеграция Kubernetes внутрь vSphere обеспечивает массу инноваций. С технической точки зрения все эти новые сервисы и приложения вытекают в большее число объектов, которыми должны управлять администраторы vSphere. В связи с этим, каждое приложение более не обозначает отдельную виртуальную машину. Теперь одно логическое приложение может объединять множество виртуальных машин, подов и некоторых из описанных ранее сервисов. Таким образом, в дополнение к поддержке Kubernetes в vSphere, потребовалось обновить способы управления окружениями vSphere, обеспечив возможность управления в значительно большем масштабе. Это называется управлением с фокусом на приложениях (Application-Focused Management).

Новые возможности управления были достигнуты за счет использования пространств имен (Namespaces) Kubernetes для группировки виртуальных машин, подов и сервисов, которые являются частью логического приложения. Таким образом, администратор может управлять пространством имен напрямую, вместо явного управления всеми его компонентами.

Эволюция администрирования виртуальных инфраструктур.

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

Заключение.

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

P.S. Это заключительная статья с описанием изменений vSphere 7, если вы пропустили предыдущие не забудьте познакомиться с ними:

• VMware vSphere 7: Основные службы для современного гибридного облака
• VMware vSphere 7: Компоненты и технологии для гибридного облака

Релиз VMware vSAN 7

VMware анонсировала новейший релиз лидирующего в индустрии программного обеспечения для реализации гиперконвергентной инфраструктуры – VMware vSAN 7. vSAN вместе с его богатой экосистемой партнеров эволюционирует, как платформа для построения частных и публичных облаков. Далее, рассмотрим, как vSAN 7 помогает ускорить модернизацию центров обработки данных (ЦОД) при помощи новых возможностей и улучшений.

Гиперконвергентная инфраструктура (HCI) была быстро адаптирована организациями всех размеров для лучшего обеспечения бизнес требований. Большинство организаций, заинтересованы в более быстрой доставке новых товаров и услуг клиентам и сотрудникам; так как новые технологии существенно сократили время на разработку и доставку информационных продуктов, лица принимающие решения, относительно инфраструктуры информационных технологий, нуждаются в платформе, которая позволит быстро доставлять новые решения. Для этого было определено несколько путей:

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

Примечание.

Источник: Perry, Christian. Voice of the Enterprise, Servers and Converged Infrastructure, Budget and Outlook, 2019. 451 Research.

В соответствие с трендами и потребностями индустрии vSAN 7 упрощает управление инфраструктурой за счёт сокращения инструментария, необходимого для управления жизненным циклом серверов. Организации теперь могут унифицировать блочное и файловое хранилище при помощи vSAN, что сокращает потребность в сторонних решениях и ускоряет развертывание общих файловых ресурсов. Также vSAN включает новые возможности, расширяющие облачные приложения, за счет обеспечения поддержки файловых служб и дополнений vSphere для Kubernetes (ранее известного как Project Pacific) через VMware Cloud Foundation.

Упрощение обновления кластеров при помощи vSphere Lifecycle Manager.

Управление жизненным циклом – это продолжительная по времени задача, общая для администраторов, поддерживающих свои инфраструктуры при помощи нескольких инструментов, которые требуют специализированных навыков. На данный момент, клиенты VMware используют два разных интерфейса для управления: vSphere Update Manager (VUM) для обновления программного обеспечения и драйверов, а также утилиты, предоставляемые производителями серверов для обновления микропрограммного обеспечения (Firmware). В данном релизе, VMware HCI предоставляет основу для нового, унифицированного механизма обновления программного обеспечения и управления микропрограммным обеспечением – vSphere Lifecycle Manager (vLCM).

vLCM построен с моделью постоянного состояния, которая предоставляет управление жизненным циклом для гипервизоров, а также полного стека драйверов и микропрограммного обеспечения для серверов входящих в состав центра обработки данных (ЦОД). vLCM может быть использован для применения образа, мониторинга соответствия и восстановления кластера, если в нем есть отклонения. Это сокращает трудозатраты на мониторинг соответствия для отдельных компонентов и помогает поддерживать целостное состояние всего кластера с соблюдением VMware Compatibility Guide (VCG). vLCM – это новый эффективный подход для создания комплексного управления жизненным циклом в масштабе.

Встроенные файловые службы (Native File Services) для vSAN.

Встроенные файловые службы (Native File Service), интегрированные в vSAN, упрощают управление хранилищем, так как они помогают сократить зависимость от сторонних решений. vSAN 7 теперь поддерживает NFS v3 и v4.1, что в результате обеспечивает новые сценарии применения. Включение файловых служб происходит так же, как и включение других возможностей уровня кластера, таких как службы iSCSI, шифрование, дедубликация и сжатие. Весь жизненный цикл развертывания и поддержки файловых служб может быть выполнен через пользовательский интерфейс vCenter. Данная возможность помогает обеспечить широкий диапазон сценариев применения, требующих файловых служб с простой интеграцией.

Развертывание современных приложений на vSAN при помощи Enhanced Cloud Native Storage.

vSAN 7 расширяет и укрепляет возможности облачного хранилища, впервые представленные в vSAN 6.7 Update 3. vSAN теперь поддерживает использование встроенных файловых служб в качестве постоянных томов для кластеров Kubernetes. В дополнение к файловым службам, vSAN обеспечивает дополнение vSphere для Kubernetes (ранее известное как Project Pacific), которое обеспечивает возможность развертывания на хранилище (Datastore) vSAN рабочих нагрузок в контейнерах с сохранением состояния.

Общие улучшения.

Интегрированное представление DRS о конфигурациях растянутого кластера (Stretched Cluster).

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

Немедленная операция восстановления после замены наблюдающего хоста (Witness Host) vSAN.

vSAN 7 расширяет логику замены и повторной синхронизации наблюдающего хоста (Witness Host) vSAN для растянутого кластера (Stretched Cluster) и двух-узловых топологий. Когда устройство хоста наблюдателя vSAN должно быть заменено, это может быть легко сделано при помощи кнопки “Replace Witness” в vCenter. После замены, vSAN вызывает немедленную операцию восстановления, быстро приводя хост наблюдения vSAN к полноценному состоянию. Это улучшение помогает устранить уязвимость переходного процесса в защите уровня сайта за счёт расширения процесса восстановления хоста наблюдения vSAN.

Перенаправление ввода/вывода растянутого кластера (Stratched Cluster) на основе дисбаланса объема между сайтами.

Топология растянутого кластера (Stretched Cluster) vSAN предоставляет устойчивость виртуальных машин и данных в случае отключения сайта. Гибкость vSAN позволяет администраторам детально настраивать параметры конфигурации для отдельных виртуальных машин с разными уровнями защиты или связями (Affinity). В результате может получиться дисбаланс доступного объема в одном сайте по сравнению с остальными. vSAN 7 представил новую интеллектуальную возможность минимизировать влияние на производительность в связи с ограничивающими условиями. При обнаружении дисбаланса, vSAN проверяет множество параметров на основе того, что они ограничивают ввод/вывод и перенаправляет активный ввод/вывод в здоровый сайт. Эти предотвращающие проблемы шаги происходят без остановки работы виртуальных машин. Подобная оптимизация является отличным примером того, как представленные аналитические возможности vSAN гарантируют прогнозируемую работу несмотря на широкое разнообразие условий.

Точность отчетов об использованном пространстве на уровне виртуальных машин vSAN в интерфейсе vCenter.

vSAN 7 представил новый уровень целостности при создании отчётов об уровне объема виртуальных машин в vCenter для виртуальных машин, запущенных на vSAN. Изначально, vCenter рассчитывал объем для виртуальных машина на vSAN также, как и для виртуальных машин, размещенных на традиционном хранилище. Текущие улучшения помогут обозначить различия в отчётных данных между традиционными виртуальными машинами и vSAN в таких областях как представление кластера и хоста.

Улучшенные отчёты о памяти для будущих оптимизаций.

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

Видимость объектов vSphere Replication в представлении объема vSAN.

VMware vSphere Replication – это основанное на гипервизоре решение асинхронной репликации для виртуальных машин vSphere. Оно предоставляет простой и эффективный механизм для защиты и восстановления виртуальных машин. Репликация vSphere входит во все редакции, начиная с vSphere Essentials Plus Kit. vSAN 7 представил значительное улучшение для окружений, использующих vSphere Replication – администраторы теперь могут легко определять объекты данных, связанные с vSphere Replication на уровне объекта виртуальной машины, а также в представлениях объема на уровне кластера. Эта осведомленность о данных vSphere Replication помогает администратору определять ресурсы, используемые для нужд асинхронной репликации.

Поддержка для устройств большего объема.

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

Встроенная поддержка горячего добавления NVMe.

NVMe помогла установить новый уровень производительности для систем хранения. vSphere 7 представил одну возможность, которая соответствует или превышает возможности, связанные с более старыми устройствами SAS и SATA: поддержка горячего подключения устройств NVMe в vSphereи vSAN. Это предоставляет новый уровень гибкости и удобства обслуживания для хостов с устройствами NVMe, увеличивая время непрерывной работы за счёт упрощения задач обслуживания, связанных с добавлением, удалением и перемещением устройств хранения в хостах. Современные хосты могут иметь десятки подключенных устройств NVMe и преимущества от горячего подключения должно помочь как большим, так и маленьким окружениям.

Удаление требования Eager Zero Thick (EZT) для общих дисков в vSAN.

Данный релиз также представил улучшенную гибкость для приложений виртуальных машин (таких как Oracle RAC), использующих общие виртуальные диски. vSAN 7 устраняет предварительное требование формата Eager Zero Thick от дисков с флагами мульти-записи (Multi-Writer).

Заключение.

VMware vSAN 7 модернизирует гиперконвергентную инфраструктуру за счёт предоставления администраторам унифицированной плоскости управления хранилищем для блочных и файловых протоколов, а также предоставляет значительные улучшения, которые обеспечивают великолепное решение, как для традиционных, так и для облачных приложений. vSphere Lifecycle Manager сокращает сложность мониторинга и поддержки инфраструктуры за счёт консолидации инструментов обновления программного обеспечения, драйверов и микропрограммного обеспечения (Firmware), а также предоставляет модель требуемого состояния с применением требуемого образа. Общие файловые ресурсы vSAN 7 позволяют администраторам быстро разворачивать общие файловые ресурсы через единый рабочий поток; интегрированные общие файловые ресурсы также сокращают зависимость от сторонних решений и упрощают управление жизненным циклом. Так как облачные приложения под управлением Kubernetes также могут получить преимущества от общих файловых ресурсов vSAN, команда ИТ может консолидировать больше рабочих нагрузок в гиперконвергентной инфраструктуре (HCI) на базе vSAN и сделать её более эффективной. Дополнительные улучшения предоставляющие широкое разнообразие преимуществ, от расширенного мониторинга инфраструктуры, который помогает администраторам планировать будущие потребности, до инфраструктуры, готовой к завтрашнему дню, за счёт поддержки накопителей большего объема и увеличенного времени непрерывной работы за счёт горячего подключения NVMe. vSAN остаётся предпочтительной платформой, как для традиционных приложений, так и для эволюционирующих современных приложений, за счет бесшовной эволюции и быстрого внедрения инноваций.

P.S. С другими новыми возможностями VMware vSphere 7 можно познакомиться в статье «VMware vSphere 7: Основные службы для современного гибридного облака».

Рекомендации по проектированию VMware vSAN: Быстрые устройства хранения или быстрая сеть

Доставка наивысшего уровня производительности в центре обработки данных (ЦОД) – это задача с множеством условий. Определение каждого отдельного программного или аппаратного компонента очень важно, но потенциальные узкие места не видны сразу из-за того, что все компоненты неразрывно связанны и оказывают непосредственное влияние друг на друга. Это одна из причин, по которой рекомендуется использовать структурированное устранение неисправностей производительности vSAN при помощи платформы, которая учитывает все эти факторы.

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

Обработка ввода/вывода (I/O Processing) в vSAN.

Одна из сильных сторон vSphere – это возможность приоритезации. Ассортимент планировщиков, встроенных в гипервизор управляет процессами на процессоре хоста, входящей и исходящей сетевой активностью и вводом/выводом хранилища. Так как планировщики – это процессы уровня ядра, они выполняют свою работу крайне эффективно.

VMware vSAN использует собственный планировщик для определения и приоритезации различных типов ввода/вывода хранилища, запущенного через стек. Это часть работы, которая делает компонент Adaptive Resync, представленный в vSAN 6.7, столь эффективным. Обратите внимание, что данные механизмы помогают приоритезировать локальные действия ввода/вывода на хосте. 

Устройства хранения (Storage Devices).

Исходная производительность устройств хранения сильно различается, даже если рассматривать только твердотельные накопители. Устройства SATA, SAS и NVMe имеют существенные отличия, выливающиеся, в итоге, в производительность, а также в целостность. Даже самые быстрые устройства NVMe, использующие NAND флеш, не являются лидерами производительности, новые технологии, такие как 3D XPoint (Intel Optane) позволяют преодолеть некоторые препятствия, связанные с NAND. Индустрия хранения развивается очень быстро, но благодаря архитектуре vSAN, новые технологии можно гранулировано встраивать, позволяя инфраструктуре ЦОД эволюционировать.

При планировании высокопроизводительного кластера vSAN, необходимо использовать быстрые устройства хранения на буферном уровне (Buffer Tier) и на уровне ёмкости (Capacity Tier). Устройства хранения – это часть финального отрезка пути данных и менее производительные устройства могут привести к невозможности соответствия необходимым ожиданиям производительности.

Сетевое взаимодействие (Networking).

Сетевые коммутаторы и интерфейсы, подключенные к ним – это то, что связывает все компоненты воедино. Сетевое взаимодействие играет особенно важную роль в гиперконвергентной инфраструктуре (HCI), так как действия ввода/вывода могут быть расширены за пределы локального хоста. К сожалению, промышленная практика ссылки на спецификацию коммутатора просто по максимальной скорости порта отменяет все важные подробности коммутационного оборудования. Возможности коммутационного оборудования зависят от многих факторов, таких как: пропускная способность соединительной платы, доступный объем буферизации портов на коммутаторе, а также являются ли платы ASIC достаточно мощными для соответствия требованиям обработки пактов в окружении. Эти факторы зачастую и являются причинами недостаточной производительности. John Nicholson выпустил отличную серию статей на эту тему и, совместно с Broc Yanda, презентовал сессию на VMworld.

Другое испытание с коммутационным оборудованием заключается в том, что его типичный жизненный цикл в производстве дольше, чем у прочих активов центра обработки данных (ЦОД). Продолжительный жизненный цикл обозначает, что архитектору нужно быть более осведомлённым о будущих требованиях и, в связи с их изменениями, возможно, придется инвестировать раньше, чем планировалось.

Как они опираются друг на друга.

Планировщики на базе хоста, такие как vSAN, приоритезируют ввод/вывод по мере его генерации хостом или поступления на аппаратный стек хоста. Они не поддерживают сеть и не предполагают, что другие пакеты могут ожидать отправки на хост. Но неправильно подобранные коммутаторы, не справляющиеся с нагрузкой, могут привести к падению производительности. Если сеть испытывает перегрузки какой угодно формы (пропускная способность, обработка или буферизация), это может стать аспектом правил TCP. По мере увеличения частоты сброса пакетов увеличивается количество повторных передач. Не смотря на надёжность TCP, шаги обработки при перенасыщении становятся дорогостоящими для пиковой производительности и целостности. Хуже всего то, что перенасыщение оказывает влияние на все системы, подключенные к коммутаторам.

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

Например, если клиент использует скромные коммутаторы 10 Gb и рассматривает 25/100 Gb – это решение приходит не от уровня утилизации коммутаторов, а с целью исключить узкое место на уровне коммутаторов, не позволяющее узлам использовать свой потенциал по максимуму. Вместе с увеличением производительности хостов, необходимо увеличивать и производительность сети.

Итоги.

Оптимизация производительности часто заключается в исключении узких мест там, где их легче обнаружить и исключить. Инвестиции в более производительное коммутационное оборудование поможет сместить вопрос конкуренции в сторону хоста, где за счет соответствующих планировщиков – управление проще, а восстановление требуемого уровня производительности при помощи более быстрых устройств хранения легче. Хорошие коммутаторы стоят достаточно дорого, но с учётом более продолжительного жизненного цикла коммутаторов и возможностью vSAN легко добавлять новое, более быстрое оборудование, это становится мудрым шагом в любом проекте центра обработки данных (ЦОД).

Основная поддержка VMware vSphere 6.0 заканчивается в 2020 году

12 марта 2020 года заканчивается основная поддержка (General Support) для VMware vSphere 6.0.

Окончание поддержки распространяется на:

• vCenter Server 6.0.
• vCenter Update Manager 6.0.
• ESXi 6.0.
• Site Recovery Manager 6.0 и 6.1.
• vSAN 6.0, 6.1 и 6.2.
• vSphere Data Protection 6.0 и 6.1.
• vSphere Replication 6.0 и 6.1.

Узнать подробности жизненного цикла продуктов VMware можно на странице Lifecycle Support.

Для сохранения полного уровня поддержки и сервисов подписки, VMware рекомендует обновиться до vSphere 6.5 или 6.7. Обратите внимание, что обновление до vSphere 6.5 или 6.7 не только даст все возможности vSphere, но также обеспечит и новейшим релизом vSAN и его возможностями (при наличии лицензии vSAN).

Если нет возможности обновиться с vSphere 6.0 до окончания основной поддержки, при наличии активных сервисов поддержки и подписки, можно приобрести расширенную поддержку (Extended Support) сроком на один год с возможностью продлить поддержку максимум на два года после даты окончания основной поддержки. Дополнительная информация находится на странице расширенной поддержки.

Technical Guidance для vSphere 6.0 доступны до 12 марта 2022, в основном через портал самостоятельной помощи. В рамках фазы Technical Guidance, VMware не предлагает поддержку нового оборудования, обновления серверных/клиентских/гостевых операционных систем, новые обновления или исправления ошибок кроме обозначенных. За дополнительной информацией обратитесь к VMware Lifecycle Support Phases.

Обновление до VMware vSphere 6.7.

Для получения дополнительной информации о преимуществах и способах обновления vSphere посетите VMware vSphere Update Center. VMware продлила основную поддержку для vSphere 6.5 и 6.7 до полных 5 лет с момента релиза, они заканчиваются 15 ноября 2021 года.

Я уже записал веб-каст на тему обновления до VMware vSphere 6.7. Он будет опубликован ближайшее время.

Релиз VMware PowerCLI 11.4.0

Август сложится крайне насыщенным на релизы продуктов VMware, можете посмотреть мои анонсы VMware vSphere 6.7 Update 3 и VMware vSAN 6.7 Update 3. Команда разработки PowerCLI не осталась в стороне и также анонсировала релиз PowerCLI версии 11.4.0!

Обновления в PowerCLI 11.4.0:

• Добавлена поддержка Horizon View 7.9.
• Обновлены и добавлены новые командлеты в модуль Storage.
• Обновлены командлеты модуля HCX.

Рассмотрим обновления подробней.

Обновления модуля Storage.

Модуль Storage получил набор обновлений, многие из которых связаны с поддержкой новых возможностей vSAN 6.7U3. Первое улучшение добавлено в командлеты Get-VsanClusterConfiguration и Set-VsanClusterConfiguration. Эти командлеты теперь поддерживают доступ и настройку добавленных возможностей превентивной балансировки (Proactive Rebalance) и базовых предпочтений (Baseline Preference) vSphere Update Manager.

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

В модуль хранилища также были добавлены новые командлеты. В первую очередь командлет Add-VsanObjectToRepairQueue – он может исправить объекты vSAN, указанные в команде. Данная возможность ранее была доступна при помощи командлета Repair-VsanObject, однако последний был модифицирован и стал псевдонимом для командлета Add-VsanObjectToRepairQueue. Оставшиеся два новых командлета – это Get-VsanResyncingOverview и Get-VsanEnterMaintenanceMode – оба этих командлета работают только с кластерами vSAN 6.7U3 и более новыми.

Обновления модуля HCX.

Модуль HCX интенсивно развивается, начиная со своего самого первого релиза и PowerCLI 11.4.0 продолжил этот тренд. В модуле было обновлено 6 командлетов для добавления новых возможностей. Командлет Get-HCXAppliance возвращает новую информацию о текущей версии виртуального устройства (Appliance), а также о любых доступных версиях, которые существуют. Команндлет может быть объединен в конвейере с командлетом New-HCXAppliance, что позволит обновить устройство до одной из доступных версий. Командлету Get-HCXContainer теперь добавлена способность выводить контейнеры типа «OrgVdc». Командлету Get-HCXNetwork была добавлена способность просматривать два дополнительных типа сетей: «NsxtSegment» и «OrgVdcNetwork». Далее командлет New-HCXNetworkExtension, который может теперь работать с сетями типа «NsxtSegment». Ну и последний – Get-HCXServiceMesh, который обладает новыми свойствами, для просмотра статусов нескольких служб.

Также в модуле HCX был устранен ряд прочих ошибок. Ссылочный тип командлетов был обновлен для соответствия типам объектов .NET от HCX Migration. Командлеты Get-HCXServiceMesh и Get-HCXInterconnectStatus были обновлены для исправления ошибок. Ну и наконец свойство DestinationNetworkValue теперь корректно отображается для объектов репликации.

Итог.

Релиз PowerCLI, имеет некоторые существенные обновления. PowerCLI 11.4.0 представил новую поддержку для Horizon 7.9, новые возможности для объектов vSAN 6.7 Update 3 и несколько обновлений в модуле HCX.

Для получения дополнительной информации по изменениям в VMware PowerCLI 11.4.0, включая улучшения, расширения безопасности и устаревшие возможности, обратитесь к VMware PowerCLI Change Log. Для получения дополнительной информации по отдельным возможностям продукта обратитесь к VMware PowerCLI 11.4.0 User’s Guide. Для получения дополнительной информации по отдельным командлетам обратитесь к VMware PowerCLI 11.4.0 Cmdlet Reference.