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

Поэтому обнаружение аномалий является важным и может дать интересные инсайты. Рассмотрим следующие сценарии:

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

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

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

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

Алгоритм Хольта-Винтерса

Алгоритм Holt-Winters (HW), разработанный Хольтом и Винтерсом, помогает построить модель для сезонного временного ряда (например, с учетом суточной сезонности). Эта техника улучшает существующие средства обнаружения аномалий Avi Load Balancer, которое использует алгоритм экспоненциально взвешенного скользящего среднего (EWMA). Если EWMA звучит непонятно, то для быстрого освежения памяти хорошо подходит учебник "Прогнозирование: принципы и практика". По сути, EWMA тесно следует за кривой данных, однако он работает так, что периодические компоненты данных просто игнорируются. Этот момент учитывается при декомпозиции сигнала алгоритмом Хольта-Винтерса. Для сравнения прогностических моделей двух алгоритмов рассмотрим интервалы прогнозирования 80% и 95% EWMA и HW при применении к одним и тем же данным.

Для повышения точности не должно быть игнорирования сезонности входного ряда данных. Алгоритм Хольта-Винтерса работает путем разбиения указанного временного ряда на три компоненты:

• Уровень: Можно представить как усреднение входного сигнала.
• Тренд: Представляет собой наклон или общее направление движения данных.
• Сезонность: Отражает периодичность данных.

На рисунке ниже представлены три составляющие временного ряда (под основным сигналом), который мы прогнозировали выше:

Временной ряд может иметь аддитивную/мультипликативную тенденцию/сезонность. Для простоты в данной статье мы предполагаем применение алгоритма Хольта-Винтерса к временному ряду с аддитивной тенденцией и аддитивной сезонностью (additive-trend-additive-seasonality, HW-AA), так как это ближе к факторам в реальной жизни. Для такого ряда компоненты тренда и сезонности увеличиваются линейно и суммируются, чтобы составить точки данных на прогрессирующих временных срезах. Временной ряд представлен следующим образом:

Где отдельные компоненты вычисляются следующим образом:

Обратите внимание, что каждое уравнение компоненты по сути представляет собой расчет в стиле EWMA. Для дальнейшего понимания обратитесь к книге "Прогнозирование: принципы и практика".

Несколько слов о параметрах сглаживания alpha, beta, gamma. Как общее руководство, инженеры используют уравнение для определения параметров сглаживания, как это рекомендуется в статье "Обнаружение аномалий во временных рядах для мониторинга сети".

Это уравнение подчеркивает, какую важность мы хотим придать историческим данным. Например, в Avi, когда применяется алгоритм HW к метрике, представляющей пропускную способность приложения, вес 95% придается сэмплам (с интервалам 5 минут) за последний час. Подставим эти значения в уравнение выше:

Эта схема применима и к другим параметрам сглаживания. Обратите внимание, что, как видно из уравнений выше, объем памяти, потребляемый алгоритмом HW, пропорционален сезонному периоду. В контексте аналитического движка Avi это означает занимаемый объем памяти размером 96 КБ на метрику. Поэтому из тысячи метрик, анализируемых Avi, VMware внимательно балансирует применение алгоритма HW только к наиболее значимым сезонным метрикам, не перегружая операции.

Для оценки нашего выбора параметров для встраиваемой реализации алгоритма HW мы сравниваем прогнозные значения с уже известным временным рядом. Вот результат:

По оси X отложено время t, а по оси Y - соответствующее значение выборки данных. График представляет собой сравнение исходных и прогнозируемых значений, а также обозначает интервалы прогнозирования с доверительной вероятностью 95%. Легко заметить, что исходные и прогнозируемые данные довольно хорошо совпадают.

Аналитический движок Avi применяет несколько методов обнаружения аномалий к одному временному ряду. Как описано выше, эти методы обнаружения используют варианты EWMA и HW. Таким образом, результаты каждой модели подвергаются режиму консолидации ALL или ANY, где либо все результаты должны согласиться с решением (о маркировке точки данных как аномальной) или же достаточно и одного. Выбор режима консолидации зависит от баланса между ложноположительными и истинными результатами. В режиме ALL ожидаются более частые ложноположительные результаты с более точными истинными, так как диагностика хотя бы одной моделью достаточна для пометки выборки данных как аномальной. В отличие от этого, режим ALL требует единогласного решения алгоритмов, что требует большей уверенности в маркировке выборки данных. Следовательно, это делает более сложным пометку правильных данных как аномальных (соответственно, меньше ложноположительных, но и меньше истинных результатов). В рамках этого подхода VMware предустанавливает режимы в зависимости от конкретной метрики, основываясь на опыте наблюдений.

Вот преимущества подхода Avi:

• Inline - это встроенная функция контроллера доставки приложений (Application Delivery Controller, ADC), она не требует дополнительных настроек или использования стороннего программного обеспечения.
• Быстрый и действенный - обнаружение аномалий выполняется в реальном времени, а администраторам предоставляются средства по автоматизации их обработки (например, добавление ресурсов). Администраторам не нужно вручную блокировать клиентов, запускать новый сервер или увеличивать ёмкость на основе прогнозов использования ресурсов и т. д.
• Интеллектуальный - машинное обучение операционным шаблонам и поведению позволяет аналитическому движку Avi принимать лучшие решения по обнаружению аномалий, прогнозированию нагрузки, планированию эластичной ёмкости и т. д.

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

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

VMware Cloud Foundation 5.1 и vSAN 8 Update 2 вносят новые улучшения в архитектуру хранения данных vSAN Express Storage Architecture (ESA), которые помогают лучше понять потребление емкости в кластерах.

Часто задаваемые вопросы администраторов

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

Стек хранения данных ESA обрабатывает и хранит данные иначе, чем Original Storage Architecture (OSA). В результате, его накладные расходы на хранение метаданных, файловых систем и необходимая емкость для обеспечения надежности хранения основных данных на случай сбоя также отличаются. Недавние улучшения в vSAN 8 U2 и VMware Cloud Foundation 5.1 включают изменения в пользовательском интерфейсе, которые позволяют лучше учитывать эти накладные расходы. Эти улучшения упрощают понимание потребления емкости. Давайте посмотрим, что изменилось и рассмотрим пример использования емкости хранения для ESA.

Пример потребления храненилищ в ESA

Кластер в примере ниже состоит из 8 хостов ESXi, работающих на платформе vSAN 8 U2. Каждый хост оснащен четырьмя устройствами хранения емкостью 1.6 ТБ, обеспечивая чуть менее 6 ТБ на хост или примерно 47 ТБ для кластера. В этом кластере ESA работает около 100 виртуальных машин, каждой из которых назначена специфичная для кластера политика хранения данных по умолчанию с RAID-6 под управлением функции автоматического управления политиками vSAN ESA. Также там включена функция возврата пространства хранилищ TRIM/UNMAP vSAN. Для ясности, в этом кластере не включены механизмы управления емкостью операционного резерва и резерва восстановления хоста (Operation's Reserve и Host Rebuild Reserve). Хотя этот пример использует кластер в варианте развертывания vSAN HCI, результаты будут такими же, как и в кластере, работающем на vSAN Max.

vSAN представляет емкость кластера на странице Summary, которая делится на два раздела. Раздел "Capacity Overview" показывает, сколько доступной емкости используется, а "Usage breakdown" подробно описывает тип данных, в настоящее время хранящихся в кластере.

Представление Capacity Overview

В этом примере пользовательский интерфейс показывает, что кластер предоставляет 46.57 ТБ отформатированной сырой емкости. Маленькая вертикальная линия на графике обзора емкости представляет "порог операций" (operations threshold), который отражает рекомендуемый лимит потребления емкости (в данном случае - 38.27 ТБ), который обеспечивает операционную деятельность vSAN.

Хотя на кластере хранится почти 31 ТБ данных гостевых виртуальных машин, метаданных объектов и снимков, фактически используемая емкость составляет 17.69 ТБ после учета сжатия данных, что экономит 13.70 ТБ. Сжатие данных в ESA гораздо лучше, чем в OSA, но, конечно, коэффициенты сжатия, которых вы достигнете, будут полностью зависеть от типа данных, хранящихся в вашей среде.

Представление Usage breakdown

В разделе "Usage breakdown" подробно описывается распределение данных после сжатия, исключая свободную емкость. Нововведением в vSAN 8 U2 и VMware Cloud Foundation является значение "ESA object overhead" в категории "System usage". Она отображает метаданные, создаваемые в отношении объекта и реплицированных данных. В этом примере оно составляет около 11.96% от хранимых данных. Указанные накладные расходы объекта ESA рассчитываются после сжатия данных, так что чем лучше сжатие, тем меньше необходимо накладных расходов.

Рекомендация: используйте представление "Usage breakdown" только для хорошо заполненных кластеров. Поскольку расчет ведется только по записанным данным, новые кластеры, в которых очень мало или вообще нет виртуальных машин, могут показывать проценты накладных расходов, гораздо выше ожидаемых. Это связано с тем, что в кластере кроме стандартных, глобальных системных накладных расходов, практически нет других данных.

Результат

Этот конкретный пример демонстрирует, что ESA, даже после учета различных накладных расходов, может защищать данные с высоким уровнем устойчивости (FTT=2) таким образом, что практически все накладные расходы на отказоустойчивость и метаданные компенсируются. В этом примере на кластере, который предоставляет около 46 ТБ сырой емкости, было примерно 15 ТБ данных гостевых виртуальных машин, которые после учета накладных расходов и сжатия потребовали около 17,7 ТБ сырого хранилища. Предполагая тот же уровень сжатия для новых данных, можно было бы хранить еще 15 ТБ дополнительных данных в высокоустойчивом виде и оставаться в пределах базового порога операций для кластера в 38.27 ТБ.

По сравнению с OSA, ESA обеспечивает более высокую устойчивость (поскольку большинство клиентов используют менее устойчивый FTT=1 вместо FTT=2 на OSA), гораздо более высокую производительность и улучшенную эффективность использования пространства для снижения затрат. Intel недавно опубликовала материал, который подтверждает это мнение: "Beyond Savings:  How Server Consolidation with VMware vSAN 8 Boosts Performance by more than 7.4x!". И в отличие от традиционного модульного массива хранения, вы получаете полностью распределенную систему хранения, которую можно масштабировать постепенно и экономично, используя ваши любимые серверы.

Оценка требований к хранению данных

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

У компании VMware вышла полезная многим администраторам решения vRealize Operations (vROPs) онлайн-утилита для сайзинга управляющей инфраструктуры - vRealize Operations Sizing Tool. Она будет полезна администраторам и консультантам, которые планируют развертывание инфраструктуры vROPs и подбирают для этого оборудование и необходимые мощности.

В случае прикидочного расчета нужно просто выбрать версию vRealize Operations Manager и указать тип сайзинга Basic:

Это даст обобщенные требования к оборудованию при минимальном вводе данных. В basic-режиме вы просто задаете параметры своей виртуальной инфраструктуры, условия хранения данных на серверах vROPs и планируемый рост инфраструктуры:

Также параметр High Availability удвоит число необходимых узлов за счет введения резервных.

Итогом будут рекомендации по числу и конфигурации узлов, которые будут обслуживать сервисы мониторинга vROPs (для этого надо нажать на ссылку View Recommendations):

Полученный отчет можно выгрузить в PDF-формат. Кстати, если нажмете на вкладку Environment, то можно будет скорректировать данные, не начиная процесс с начала.

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

После параметров объектов vCenter вы сможете задать имеющиеся или планируемые Management Packs от сторонних производителей или самой VMware (и число отслеживаемых объектов в них):

Если же у вас уже есть инфраструктура vRealize Operations, то vRealize Operations Sizing Tool - это хорошее средство, чтобы проверить, что вы правильно подобрали конфигурацию узлов под vROPs.

Для этого надо пойти в раздел Administration > History > Audit > System Audit и там посмотреть итоговое настроенное число объектов (Objects) и метрик (Metrics):

После этого вы можете вбить это число в разделе Other Data Sources и получить расчет параметров сервера, который более-менее должен сходиться с вашей конфигурацией узлов:

Компания VMware сделала доступной небольшую онлайн-утилиту для сайзинга серверов хранения виртуальных машин, работающих в отказоустойчивых кластерах хранилищ - VMware vSAN Sizer. Также она производит подбор необходимых конфигураций серверов (для расчетов принимается, что все узлы будут использовать конфигурацию All-Flash SSD).

VMware vSAN Sizer доступен по адресу: https://vsansizer.vmware.com/

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

На первом этапе нам показывают, сколько нужно серверов и неразмеченного хранилища (Raw Storage):

Ниже мы видим технические характеристики каждого из хостов ESXi:

Ну а в рамках дополнительной информации можно вывести параметры дисковых групп (кэш и емкость хранения). В моем случае это 2 дисковых группы:

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

Компания VMware, оказывается, имеет интересный инструмент для расчета стоимости владения инфраструктурой хранения на базе локальных серверов VMware Virtual SAN TCO and Sizing Calculator. Понятно, что инструмент это больше маркетинговый, чем приложимый к реальному миру, но давайте все же взглянем на него. Напомним, кстати, также, что недавно была анонсирована новая версия VMware Virtual SAN 6.2.

Первое, что нам нужно ввести - это основные параметры инфраструктуры (можно выбрать между серверной виртуализацией и виртуализацией настольных ПК). Сначала нужно указать число виртуальных машин и число ВМ на сервер VMware ESXi. Далее можно использовать один для всех профиль виртуальной машины, а можно добавить несколько:

Если вы не знаете, что такое FTT (Failures to tolerates) - загляните вот в эту нашу заметку.

Далее мы вычисляем требуемую полезную емкость, необходимую для размещения виртуальных машин в кластерах Virtual SAN с учетом требуемого уровня отказоустойчивости:

Затем мы переходим к кастомизации так называемой "Ready Node" (об этом мы писали вот тут). Это типовой серверный узел, который будет исполнять как виртуальные машины, так и хранить их на своих локальных дисках.

Также в самом начале нужно задать "Performance profile", то есть типовую предполагаемую конфигурацию хранилища/производительности дисков для узла Virtual SAN. Внизу будет выведена примерная стоимость инфраструктуры хранения:

Кстати, у VMware есть инструмент Virtual SAN Ready Node Configurator, который поможет определиться с точной конфигурацией узла и создать спецификацию на него с учетом производителя серверов, которые вы обычно закупаете для своей инфраструктуры.

Ну а далее мы получаем overview из параметров, которыми будет обладать ваша виртуальная инфраструктура:

Ниже вы увидите распределение дискового пространства по VMDK-дискам, их репликам и прочим вспомогательным компонентам.

Внизу вы увидите конфигурацию хостов и кластера Virtual SAN, а также обобщенную спецификацию на узел. После этого переходим к параметрам расчета стоимости владения (TCO - total cost of ownership). Это такой метод сравнения затрат, когда вы сравниваете один способ реализации хранения машин без кластера хранилищ на базе локальных дисков с инфраструктурой Virtual SAN за определенный промежуток времени (обычно 3 или 5 лет).

Вводим параметры лицензирования и его тип, а также стоимость поддержки для Virtual SAN. Ниже вводим параметры текущей серверной конфигурации без VSAN:

Далее нам показывают "экономию" на трудозатратах (операционные издержки), а также на электропитании и охлаждении:

Ну а в конце приводится сводная таблица по капитальным и операционным затратам, полученная в сравнении использования Virtual SAN-конфигурации и развертывания традиционных дисковых массивов. Обратите внимание, что даже в дефолтном примере капитальные затраты с VSAN существенно выше:

Ниже идут различные графики про экономию денег в различных аспектах:

И в завершение - структура издержек на владение инфраструктурой хранения c VSAN и без него:

Инструмент интересный, но бесполезный. Пользуйтесь!

Компания Nutanix выпустила полезную утилиту сайзинга хранилищ и конфигурации узлов под виртуализацию VMware и Citrix, которая позволяет рассчитать необходимую конфигурацию СХД под выбранный сценарий - Nutanix sizer tool.

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

После того, как мы выберем необходимый сценарий консолидации систем на СХД, нам нужно выбрать тип инфраструктуры виртуализации под который мы будем проводить рассчеты (workload type):

• Виртуализация настольных ПК (VDI)
• Виртуализация серверов (Server Virtualization)

Далее мы выбираем тип профиля виртуальной нагрузки (виртуальной машины) - он может быть одним из трех:

легкий (small)

средний (medium)

тяжелый (large)

Единственное значение, которое можно изменить - это число виртуальных машин на рабочую нагрузку (максимально - 25).

Для примера введем одну нагрузку типа small, одну medium и одну large по 25 виртуальных машин в каждой.

В итоге получим следующие параметры узлов Nutanix (все спецификации можно найти тут):

• Nodes = 3 штуки NX-3050 по 256 GB RAM в каждом узле
• Cluster = 1
• Rack Space = 2U

Пример итоговой конфигурации для серверной виртуализации:

Если же мы выберем тип нагрузки VDI, то увидим следующие параметры:

Там мы выбираем тип пользователя и его тип нагрузки:

• Task Worker (легкие задачи)
• Knowledge Worker (сложные задачи)
• Power User (сложные и административные задачи)

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

• VMware View Linked Clones
• VMware View Full Closes
• Citrix XenDesktop MCS
• Citrix XenDesktop PVS
• Citrix XenDesktop Full Clones

Максимальное число пользователей для выбранной спецификации рабочей нагрузки может быть до 1000.

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

• В качестве рабочей нагрузки можно указать серверы Exchange или серверы SQL
• VDI Workload: неактивные опции могут быть изменены.
• Server Workload: неактивные опции могут быть изменены.
• Число vCPU на физическое ядро (pCPU) можно определить в Advanced Settings.
• Для всех типов рабочей нагрузки можно определить следующие опции:
  • Целевой кластер (Target Cluster)
  • Домен доступности ВМ (Availability Domain)
  • Поддержка техники N-Plus
  • Фактор контейнерной репликации (Container Replication Factor)
  • Возможность сжатия данных (Compression)
  • Дедупликация на уровне контейнера (Container Dedupe) - экономит дисковое пространство пользователей
  • Встроенная дедупликация "на-лету" - Inline Dedupe.

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

• CPU
• RAM
• SSD
• HDD

Пример серьезной инфраструктуры из трех стоек:

Скачать Nutanix sizer tool можно по этой ссылке.

На днях компания VMware выпустила долгожданный онлайн-сервис Virtual SAN Sizing Tool, который позволяет оценить необходимые аппаратные мощности, требующиеся для поддержания инфраструктуры хранилищ VSAN на базе локальных дисков серверов VMware ESXi.

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

а также типовая аппаратная конфигурация хост-сервера ESXi:

Для виртуальных машин вам могут показаться непонятными параметры "Number of failures to tolerate" и "Number of disk stripes per object" - о них мы писали вот в этой статье.

В качестве результата расчетов будет выведена следующая информация:

• Число хостов заданной конфигурации, необходимых для поддержания инфраструктуры VSAN.
• Размер SSD-диска для дисковой группы HDD на хосте.
• Максимумы по числу компонентов в кластере (машины, диски).
• Полезная емкость кластера (зависит также от параметра FTT).
• Емкость кластера по оперативной памяти.

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

При расчетах используются следующие допущения:

• Все хосты кластера имеют одинаковый аппаратный профиль, включая число HDD и SSD-дисков, объем памяти и количество ядер CPU.
• Предполагается, что у всех виртуальных машин одинаковые требования к хранилищу: как по дисковой емкости и числу дисков, так и по нагрузке на СХД.
• Предполагается, что у всех виртуальных машин одинаковая VSAN Policy, то есть параметры FTT и disk stripes per object.

Никаких кнопок для начала расчета нажимать не нужно - данные формируются "на лету". Приступить к работе с VMware Virtual SAN Sizing Tool можно по этой ссылке.

Как многие знают, в VMware vSphere 5.5 появились возможности Virtual SAN, которые позволяют создать кластер хранилищ для виртуальных машин на основе комбинации SSD+HDD локальных дисков серверов VMware ESXi. Не так давно вышла обновленная бета этого решения, кроме того мы не так давно писали о производительности VSAN тут и тут.

Сегодня же мы поговорим о том, как нужно сайзить хранилища Virtual SAN в VMware vSphere, а также немного затронем тему отказоустойчивости. Более детальную информацию можно найти в VMware Virtual SAN Design & Sizing Guide, а ниже мы расскажем о подходе к планированию хранилищ VSAN вкратце.

Объекты и компоненты Virtual SAN

Начнем с простого ограничения по объектам (objects) и компонентам (components), которое есть в VSAN. Виртуальные машины, развернутые на vsanDatastore, могут иметь 4 типа объектов:

• Домашняя директория виртуальной машины Virtual Machine ("namespace directory").
• Объект файла подкачки - swap object (для включенной ВМ).
• Виртуальный диск VMDK.
• Дельта-диски для снапшотов. Каждый дельта-диск - это отдельный объект.

Каждый объект, в зависимости от типа RAID, рождает некоторое количество компонентов. Например, один VMDK, размещенный на двух томах страйпа (RAID 0) рождает два объекта. Более подробно об этом написано вот тут.

Так вот, ограничения тут следующие:

• Максимальное число компонентов на 1 хост ESXi: 3000.
• Максимальное число компонентов для одного объекта: 64 (это включает в себя тома страйпов и также реплики VMDK с других хостов).

На практике эти ограничения вряд ли актуальны, однако о них следует знать.

Сколько дисков потребуется для Virtual SAN

Во второй бета-версии VSAN (и, скорее всего, так будет в релизной версии) поддерживается 1 SSD-диск и до 7 HDD-дисков в одной дисковой группе. Всего на один хост VMware ESXi поддерживается до 5 дисковых групп. Таким образом, на хосте поддерживается до 5 SSD-дисков и до 35 HDD-дисков. Надо убедиться, что контроллеры хоста поддерживают необходимое количество дисков, а кроме того нужно проверить список совместимости VSAN HCL, который постоянно пополняется.

Также надо учитывать, что кластер хранилищ Virtual SAN поддерживает расширение как путем добавления новых дисков, так и посредством добавления новых хостов в кластер. На данный момент VMware поддерживает кластер хранилищ максимум из 8 узлов, что суммарно дает емкость в дисках в количестве 40 SSD (1*5*8) и 280 HDD (7*5*8).

Сколько дисковой емкости нужно для Virtual SAN (HDD-диски)

Необходимая емкость под размещение VMDK зависит от используемого параметра FailuresToTolerate (по умолчанию 1), который означает, какое количество отказов хостов может пережить кластер хранилищ. Если установлено значение 1, то реплика одного VMDK будет размещена на дисках еще одного из хостов кластера:

Тут можно сказать о том, как работает отказоустойчивость кластера Virtual SAN. Если отказывает хост, на котором нет виртуальной машины, а есть только VMDK или реплика, то виртуальная машина продолжает работу с основной или резервной копией хранилища. В этом случае начнется процесс реконструкции реплики, но не сразу - а через 60 минут, чтобы дать время на перезагрузки хоста (то есть если произошел не отказ, а плановая или внеплановая перезагрузка), а также на короткие окна обслуживания.

А вот если ломается хост, где исполняется ВМ - начинается процедура восстановления машины средствами VMware HA, который перезапускает ее на другом хосте, взаимодействуя при этом с Virtual SAN.

Более подробно этот процесс рассмотрен вот в этой статье и вот в этом видео:

Однако вернемся к требующейся нам емкости хранилищ. Итак, если мы поняли, что значит политика FailuresToTolerate (FTT), то требуемый объем хранилища для кластера Virtual SAN равняется:

Capacity = VMDK Size * (FTT + 1)

Что, в принципе, и так было очевидно.

Сколько дисковой емкости нужно для Virtual SAN (SSD-диски)

Теперь перейдем к SSD-дискам в кластере VSAN, которые, как известно, используются для вспомогательных целей и не хранят в себе данных виртуальных машин. А именно, вот для чего они нужны (более подробно об этом тут):

• Read Cache - безопасное кэширование операций на чтение. На SSD-диске хранятся наиболее часто используемые блоки, что уменьшает I/O read latency для ВМ.
• Write Buffering - когда приложение внутри гостевой ОС пытается записать данные, оно получает подтверждение записи тогда, когда данные фактически записаны на SSD (не на HDD), таким образом твердотельный накопитель используется как буфер на запись, что небезопасно при внезапном пропадании питания или отказе хоста. Поэтому данные этого буфера дублируются на других хостах кластера и их SSD-дисках.

Так каковы же рекомендации VMware? Очень просты - под SSD кэш и буфер неплохо бы выделять 10% от емкости HDD-дисков хоста. Ну и не забываем про значение FailuresToTolerate (FTT), которое в соответствующее число раз увеличивает требования к емкости SSD.

Таким образом, необходимая емкость SSD-хранилищ равна:

Capacity = (VMDK Size * 0.1) * (FTT + 1)

Ну и напоследок рекомендуем отличнейший список статей на тему VMware Virtual SAN:

• VSAN Part 1 – A first look at VSAN
• VSAN Part 2 – What do you need to get started?
• VSAN Part 3 – It is not a Virtual Storage Appliance
• VSAN Part 4 – Understanding Objects and Components
• VSAN Part 5 – The role of VASA
• VSAN Part 6 – Manual or Automatic Mode
• VSAN Part 7 – Capabilities and VM Storage Policies
• VSAN Part 8 – The role of the SSD
• VSAN Part 9 – Host Failure Scenarios and vSphere HA interop
• VSAN Part 10 – Changing VM Storage Policy on-the-fly

На небезызвестном ресурсе myvirtualcloud.net появилась первая версия калькулятора XenDesktop VDI Calculator, который помогает рассчитать необходимое количество хост-серверов для размещения требуемого количества виртуальных ПК с решением Citrix XenDesktop (напомним, что ранее был выпущен калькулятор для VMware View, а также для PCoIP). В качестве ПО для VDI используются версии XenDesktop 5.0 and 5.5.

На данный момент в качестве серверной платформы виртуализации пока поддерживается только VMware vSphere 5, но, надо сказать, что этот продукт в большенстве случаев и используется в качестве платформы для XenDesktop с доставкой десктопов через MCS (Machine Creation Services) для крупных инсталляций.

Основные возможности XenDesktop VDI Calculator:

• Поддержка многоядерных CPU 
• Поддержка 32-битных разрешений в гостевой ОС виртуальных ПК
• Платформа - VMware vSphere 5.0
• Поддержка использования 3D-графики в ПК
• Расчет выделенных десктопов и пулов
• Расчет выделения CPU для ВМ
• Поддержка swap-файлов ВМ на локальном хранилище
• Поддержка Delivery Controller High Availability
• Расчет IOPs'ов на базе типа нагрузки, уровня RAID и т.п.
• Расчет overhead'а на поддержку ВМ
• Поддержка VM memory reservation 
• Учет overhead'а на гипервизор
• Учет выключенных виртуальных ПК
• Учет хранилищ, в том числе для выключенных ВМ

Использовать XenDesktop VDI Calculator можно по этой ссылке.

Мы уже писали об утилите VDI Sizing Tool от отчественного разработчика Василия. Она позволяет сымитировать нагрузку на виртуальные ПК предприятия (VMware View или Citrix XenDesktop) с помощью специальных агентов и измерить производительность решения (старт приложений, создание RDP-сессии и т.д.).

Недавно вышла версия VDI Sizing Tool 0.2. В новой версии утилиты появилась поддержка VMware View Client для протоколов RDP и PCoIP. А на сайте автора появилась статья про сравнение потребления ресурсов протоколами PCoIP и RDP:

http://vdi-sizing.com/uploads/widget/docs/RDP_vs_PCoIP.pdf

Вот результаты тестирования для 10 виртуальных машин:

Подробнее - в доке.

Как вы знаете, хорошая компания Veeam Software делает не только всем известный Veeam Backup and Replication, но и полезный продукт Veeam Reporter, который позволяет вести трекинг изменений виртуальной инфраструктуры VMware vSphere и получать отчетность обо всех ее аспектах. О продукте Veeam Reporter мы уже писали.

Сейчас компания Veeam работает над созданием второй версии Capacity Planning Report pack for Veeam Reporter, которая позволит осуществлять планирование мощностей инфраструктуры виртуализации VMware vSphere. Он станет частью законченного решения для мониторинга и отчетности Veeam ONE.

Какими возможностями будет обладать Capacity Planning Report pack for Veeam Reporter:

• Recommendations for hardware planning and provisioning. В рамках этих возможностей можно будет получать грамотные рекомендации по планированию новых серверных мощностей и дозакупке хранилищ. В отличие от других решений по capacity planning, которые идентифицируют проблемные области и предсказывают, когда пороговые значения будут превышены, Capacity Planning Report pack анализирует узкие места в производительности и росте инфраструктры и выдает конкретные рекомендации по оборудованию и хранилищам, а также их конфигурациям.

• Enhanced what-if analysis. В дополнение к сценариям моделирования развития инфраструктуры, которые есть в текущей версии, появятся новые типы конфигураций хостов и виртуальных машин, которые можно использовать для анализа в стиле "что произойдет, если будет как есть, или как будет, если мы добавим такие-то мощности".

• Identification of over-provisioned storage. При использовании thin provisioning для виртуальных машин может возникнуть ситуация, когда машины при росте данных могут заполнить хранилище, что вызовет отказ гостевых ОС. Capacity Planning Report pack все это учитывает и своевременно дает рекомендации по хранилищам.

А теперь, слайды:

Приятно, что Capacity Planning Report pack for Veeam Reporter будет доступен абсолютно бесплатно для всех текущих и новых пользователей Veeam Reporter и Veeam ONE.

Автор сайта vdi-sizing.com, Василий, прислал нам ссылку на свою утилиту VDI Sizing Tool (VST), которая позволяет тестировать производительность и возможности консолидации виртуальных ПК (например, VMware View 4.x).

Эта утилита имитирует пользовательскую нагрузку в виртуальных ПК и измеряет время различных событий (старт приложений, создание RDP-сессии и т.д.), по результатам чего можно принять решение о выборе необходимого решения для виртуализации настольных ПК (сейчас их несколько, наиболее популярные - VMware View и Citrix XenDesktop).

VDI Sizing Tool содержит два компонента - user workload и loadmaster. User workload запускается в каждом тестируемом виртуальном ПК и симулирует обычные пользовательские действия - открытие документов MS Office, работу в браузере и т.п.

Loadmaster - запускается на стороне клиента виртуального ПК (например, там, где установлен VMware View Client) и тестирует соединение по RDP: собирает информацию о производительности при удаленной работе (latency), а также контролирует работу агентов LoadSlave, если используется мультиклиентное тестирование (в целях повышения объективности результатов).

Интересно, что в разделе Download можно найти документ "Sample measurements", где приведены результаты работы программы.

А в следующей версии VST автор обещает нам новые возможности:

• Поддержка новых приложений в качестве нагрузки: PDF viewers, archivers и т.п.
• Workload customization
• Счетчики и метрики производительности для популярных VDI-решений: VMware, Microsoft и Citrix
• Автоматизация развертывания виртуальных ПК (клонирование виртуальных машин и т.п.)

Скачать VDI Sizing Tool можно по этой ссылке. Можете в комментариях позадавать автору вопросы - я думаю, он постарается ответить.