Привет, Хабр! Меня зовут Дмитрий Гайдамак, я руковожу отделом ИТ в дирекции автоматизации проектного блока ПИК. Это — вторая статья из цикла о внедрении VDI на крупном предприятии (первую статью, с предысторией, уже публиковали в блоге).
Пришло время разобраться с самой сложной частью запоминающих устройств — с дисками. Здесь на сцену выходит vSAN со своими особенностями.
Тонкости сайзинга хранилища: почему vSAN
Первый кластер в нашей пилотной конфигурации VDI состоял всего из двух серверов и был рассчитан примерно на 80 рабочих мест. При скромных начальных требованиях к виртуальным машинам мы могли бы спокойно разместить их данные на какой-нибудь простой СХД (вариант с локальными датасторами даже не стоит рассматривать как недостаточно гибкий). Но мы понимали, что рано или поздно придётся масштабироваться — и вот тут начали появляться нюансы.
На тот момент мы не знали, какое количество операций ввода-вывода будет генерировать рабочая станция VDI в течение дня, и просто поверили на слово интегратору, посчитавшему для нас нужные цифры. Сейчас могу с уверенностью сказать: ферма из ста рабочих станций, где работают проектировщики, способна сгенерировать 15–25 тысяч IOPS на чтение и примерно столько же на запись (на бэкэнде vSAN с Parity FT=2, что близко к RAID 6 на СХД). Особенно утром, когда все одновременно открывают проекты.
Если экстраполировать, становится ясно, какую нагрузку приходится выдерживать датастору каждый день. В случае с СХД сотня пользователей не вызовет проблем, но тысяча уже окажется не по зубам железу начального уровня, и придётся обзавестись новой, более серьёзной СХД.
В итоге мы резонно рассудили, что для упрощения масштабирования следует разместить данные на vSAN — виртуальном датасторе, собранном из локальных дисков гипервизоров. В этом случае и объём, и пропускная способность хранилища будут автоматически расширяться при изменении количества серверов в кластере. Да и в целом хотелось, чтобы VDI был автономным и не зависел от внешних факторов.
Тонкости сайзинга хранилища: сколько vSAN
Неожиданно мы застряли на первом же шаге. Вопросы дискового пространства оказались далеко не такими тривиальными, как ожидалось. Horizon уже в 2018 году использовал технологию Linked Clones, которая позже эволюционировала в Instant Clones, для создания виртуальных машин. Обе технологии по своей сути довольно просты — они основаны на механизме снапшотов VMware, где под капотом используется обычный дифференциальный диск.
Это положительно влияет не только на время создания клонов (как и следует из названия Instant Clones), но и на занимаемое ими место на диске.
Клоны создаются из «золотого образа» — заранее подготовленной виртуальной машины, служащей шаблоном для пользовательских ВМ. «Золотой образ» может быть довольно объёмным — наш, к примеру, занимает более 150 ГБ — однако его клоны весят на порядок меньше.
Основная часть данных берётся из заранее созданного системой снапшота «золотого образа», а фактически место на диске занимают только пользовательские файлы и данные системного диска, изменённые в процессе эксплуатации клона.
Значит, достаточно посчитать суммарный объём пользовательских дисков и добавить сотню гигабайт сверху? Нет, не совсем так.
После подсчёта суммарного объёма пользовательских дисков следует понять, какую политику хранения применить для датастора. Политика хранения — это набор правил, по которым данные будут размещаться на дисках. В одном датасторе vSAN может применяться сразу несколько разных политик, но в нашем примере предположим, что для него задана одна общая политика.
Erasure Coding
Для средних и крупных кластеров VDI с vSAN на NVMe-дисках подойдёт политика Erasure Coding с параметром FT = 2. Она обеспечивает высокую отказоустойчивость и низкие издержки хранения, но требует наличия не менее шести (а лучше — семи) хостов в кластере и предъявляет повышенные запросы к производительности дисков.
Стоит отметить, что эта политика использует ресурсы ЦП в процессе ввода-вывода. На современном железе влияние на производительность пренебрежимо мало, поэтому мы не будем его учитывать.
Параметр FT (Fault Tolerance) указывает, скольких хостов кластер может лишиться, прежде чем возникнет угроза потери данных. В данном случае допускается потеря двух хостов.
Эта политика похожа по принципу работы на RAID-6. В страйпе, помимо данных, хранятся несколько контрольных хэш-сумм, с помощью которых можно восстановить информацию при утрате части дисков.
Отпечаток данных на датасторе при такой политике составляет 150%, то есть файл размером 100 ГБ фактически займёт около 150 ГБ.
Mirror
В небольших кластерах из-за малого количества хостов использовать Erasure Coding невозможно. К счастью, существует политика Mirror (аналог RAID-1). Она требует наличия всего трёх (в идеале — четырёх) хостов и обеспечивает наилучшую производительность.
При использовании этой политики объекты на датасторе хранятся в двух и более экземплярах, предотвращая тем самым потерю данных. Естественно, такая схема значительно расходует дисковое пространство: при FT = 1 отпечаток составит 200%, при FT = 2 — 300%.
А что делать, если в кластере всего два хоста? Даже для Mirror этого маловато, не говоря уже о Erasure Coding. К счастью, д��я этого случая у VMware предусмотрено решение 2-Node vSAN Cluster with Witness Appliance. Название длинное, но суть проста: где-то в стороне от кластера размещается ВМ-свидетель, которая следит за паритетом между двумя копиями данных. Таким образом, собирается полноценный кворум из трёх участников, и кластер получает право называться отказоустойчивым.
Сжатие и дедупликация
Теперь, когда у нас есть эта полезная информация, мы можем наконец посчитать… А, стоп, всё ещё не можем.
Помимо политики хранения, на отпечатки данных в датасторе влияет ещё и политика сжатия — вернее, даже две: Compression или Compression + Deduplication.
Я настоятельно рекомендую всегда включать одну из них, ведь, если политики хранения увеличивают отпечаток данных на дисках, то политики сжатия — наоборот, уменьшают.
Магия достигается в два этапа в момент записи данных на диски. Сначала данные дедуплицируются. В очень упрощённом виде это означает, что при обнаружении одинаковых фрагментов данных в разных местах датастора vSAN помечает их как дубликаты и оставляет только одну копию. Речь здесь идёт не об отдельных файлах, а о блоках размером 4 Кб.
Потом данные сжимаются. Если блок может быть сжат на 50% и более, он будет сжат и только после этого отправлен на хранение.
Степень экономии дискового пространства сильно зависит от характера данных, однако, по моему опыту, для VDI с нагрузкой в виде проектировщиков:
Compression — уменьшает объём данных примерно в 1,3 раза.
Compression + Deduplication — в 2–4 раза.
Естественно, эффект экономии места достигается за счёт снижения производительности дисковой подсистемы, которое зависит от профиля нагрузки. Практика показала, что с профилем нагрузки VDI снижение от сжатия пренебрежимо мало, а от дедупликации больше, но всё ещё не критическое.
Включать или не включать эти технологии — личное дело каждого администратора. Моя рекомендация: — с Erasure Coding использовать Compression для лучшей производительности, а с Mirror — Compression + Deduplication для лучшей экономии дискового пространства.
Резервы под Rebuild и Operations
И нет, на этом мы еще не закончили.
Следует помнить о необходимости резервирования пространства на vSAN под операции и rebuild. Под rebuild резервируется «сырая» ёмкость одного хоста — это позволит кластеру восстановиться в случае аварии.
Резерв под операции вычисляется по формуле, подробнее о которой можно почитать здесь, а мы для простоты будем считать, что это около 10% от объёма датастора.
Резервируется пространство не просто так — мы убедились в этом на собственном опыте, когда из-за отсутствия резерва под операции один из наших кластеров перестраивался после аварии почти 9 суток �� при этом тормозил так, что работать на нём было невозможно. К счастью, работа этого кластера была для нас не критична, но урок из ситуации мы извлекли: не перегружай датастор!
Thin Provisioning и клоны
Последний рывок. По умолчанию (и мы это умолчание менять не собираемся) на vSAN все объекты создаются «тонкими», то есть не занимают выделенное под них пространство без необходимости.
Например, выданный пользователю диск на 50 ГБ фактически занимает не 50, а лишь столько, сколько на нём реально записано — скажем, 20 ГБ.
Дальше всё зависит от политики компании, характера пользователей и типов файлов, с которыми они работают. У нас потребители в среднем используют около 40-60% выделенного им объёма. Таким образом, при планировании итоговой ёмкости мы просто умножаем расчётный объём данных на 0,4-0,6.
Клоны, хоть и являются дифференциальными копиями, всё равно занимают некоторое пространство, поэтому их расчётный объём нужно дополнить примерно на 25–30% от размера золотого образа. Сам золотой образ на этом фоне пренебрежимо мал, можно его не учитывать.
Итоговый расчёт
Теперь мы наконец можем посчитать планируемый объём данных по следующей формуле:
Число пользователей × (Требуемый объём личного хранилища + Объём «золотого образа» × 25%) × Политика хранения × Коэффициент тонкости / Коэффициент сжатия × 110% (операции).
Дисклеймер: формула составлена по личному опыту и может не подойти для вашего сценария! К тому же, цифры ориентировочны.
Объём хоста (резерва под rebuild) нам на этом этапе неизвестен, поэтому размер датастора следует прикидывать без него и добавить позже.
Хорошей практикой будет увеличить итоговую цифру ещё на 30–40%, чтобы обеспечить датастору запас прочности, иначе можно столкнуться с неприятными сюрпризами. Помните: с датасторами лучше перебрать, чем недобрать.
Пример расчёта для 1 000 пользователей с объёмом хранилища 175 ГБ и размером «золотого образа» 150 ГБ, политика хранения — Erasure Coding, политика сжатия — Compression Only, пользователи в среднем потребляют 60% выделенного им объёма диска:
1 000 × (175 + 150 × 25%) × 150% × 60% / 130% × 110% × 130% = 210 375 ГБ без учёта резерва на rebuild.
Наконец, мы получили приблизительную требуемую ёмкость дисковой подсистемы кластера. Пора спроектировать саму дисковую подсистему! Вы ещё здесь? Тогда поехали.
Тонкости сайзинга хранилища: как vSAN
Сколько будет пользователей, какое количество нужно хостов и какой объём «сырого» дискового пространства требуется в кластере, мы уже посчитали. Осталось понять, сколько и каких дисков нужно поставить в хосты. И, к счастью, это несложно.
Для начала нужно определиться с архитектурой vSAN. Здесь есть два варианта:
OSA (Original Storage Architecture) — классическая (не значит устаревшая!) архитектура, использующая кэширующие диски. Все накопители делятся на Cache и Capacity. Capacity-диски предоставляют кластеру ёмкость, а Cache-диски служат буферами, через которые проходит вся запись.
ESA (Express Storage Architecture) — новая архитектура, не предполагающая выделенных кэширующих дисков. Все накопители в ней являются кэширующими, а пространство под кэш выделяется динамически.
При всех очевидных плюсах ESA выбор совместимого железа пока сильно ограничен. А использовать с vSAN неподдерживаемое оборудование я никому не рекомендую.
OSA, напротив, имеет гораздо более широкий список сертифицированных устройств.
Ознакомиться со списками доступного оборудования и выбрать подходящее можно по ссылкам: OSA, ESA. Если используете SAS/SATA-диски, следует убедиться, что дисковые контроллеры HBA/RAID тоже находятся в этом списке и работают в нужном режиме.
На какой бы архитектуре вы ни остановились, дальше нужно определить, сколько capacity-дисков потребуется для обеспечения нужного объёма. Делается это просто — делением общего требуемого объёма на объём одного диска.
При выборе помните о ряде ограничений:
на одном хосте может быть не более 5 дисковых групп;
в одной группе — до 7 capacity-дисков;
всего на хосте — не более 35 дисков.
На практике для проектировочного VDI я рекомендую использовать по 4–5 capacity-дисков на хост, не более 2–3 на дисковую группу (только в vSAN OSA, разумеется).
Дисковая группа в vSAN OSA — это набор из нескольких capacity-дисков и одного cache-диска. Объём cache-диска должен составлять около 10% от общего объёма capacity-дисков.
Почему я не рекомендую ставить слишком много capacity-дисков в одну группу?
Во-первых, максимальный объём cache-диска ограничен 600 Гб в vSAN 7 и 1,6 Тб в vSAN 8 (вы можете использовать в качестве кэширующих диски большего объёма, но объём кэша от этого не увеличится). Рекомендованное VMware соотношение в 10% соответственно ограничивает общий объём capacity-дисков в группе до 6 ТБ (допустимо до 8 ТБ) и до 16 ТБ.
Во-вторых, cache-диск в группе всегда один, и, чем больше capacity-дисков вы добавляете, тем выше нагрузка на кэш и тем быстрее он изнашивается.
Итоговое решение, конечно, зависит от сценария использования и характеристик выбранных накопителей — выдержат ли они нужную нагрузку по IOPS и не выйдут ли из строя раньше времени из-за постоянной перезаписи.
Пример:
Число хостов | ДГ на хост | Cache на ДГ | Capacity на ДГ | Объём Cache | Объём Capacity | Объём ДГ | Объём хоста | Объём кластера |
10 | 2 | 1 | 2 | 1 Тб | 4 Тб | 8 Тб | 16 Тб | 160 Тб |
Выбирая конкретные модели дисков, следует руководствоваться не только листом совместимости, но и их производительностью. Помните, в начале статьи я говорил про IOPS? Диски следует выбирать исходя из того, чтобы capacity-тир мог уверенно писать с нужной скоростью, а cache-тир уверенно поглощал скачки нагрузки. Спрогнозировать нагрузку без практического опыта очень тяжело, поэтому следует уточнить цифры у коллег, уже имеющих дело с похожей нагрузкой, или же брать диски с большим запасом. Не стоит забывать и о параметре TBW, который особенно важен для cache-тира — чем ��ольше, тем лучше.
Для справки приведу графики средней нагрузки на дисковую подсистему с кластера из 19 серверов приблизительно на 1000 ВМ. Это нагрузка на backend при использовании Erasure Coding, FT=2. Немалая её часть падает в первую очередь на cache-тир.
Здесь виден пик в 150k IOPS и 5 Гб/сек. Это не худший сценарий, а обычный рабочий день — обе цифры следует как минимум удвоить при планировании.
Заключение
Вот мы и добрались до конца второй части статьи. С железом почти покончено. План нашего внедрения становится всё толще и к этому моменту уже содержит подробную информацию о желаемой конфигурации рабочих мест, количестве серверов, их аппаратной начинке, размере датастора и дисках, на которых он будет базироваться.
В следующей части мы коснёмся сетевого оборудования и сразу же погрузимся на уровень ниже — к списку компонентов Horizon и плану взаимодействия между ними.
