Продолжаем говорить о дизайне VDI. Предыдущие части доступны по ссылкам.
Часть 1. Введение
Часть 2. Постановка задачи
Часть 3. Верхнеуровневая архитектура
Часть 4. Подсистема VMware Horizon
Часть 5. Подсистема виртуализации
Часть 6. Лицензирование VDI
Часть 7. Виртуальные машины
При использовании классических систем хранения существует два основных варианта планирования архитектуры.
Вариант первый – выбрать дисковый массив, который соответствует текущим требованиям по емкости и производительности. Это позволит снизить первоначальные затраты, однако может создать сложности при масштабировании решения. И если с дисковым пространством все относительно просто, требуется пространство – покупаете дополнительные диски/дисковые полки и подключаете к массиву, то с наращиванием производительности могут возникать проблемы. Рано или поздно производительность массива упрется в контроллеры или интерфейсы передачи данных. Это потребует либо апгрейда массива путем замены/добавления контроллеров (если такая возможность поддерживается), либо покупкой второго массива, что приведет к увеличению затрат на обслуживание.
Вариант второй – это выбрать массив более высокого класса, который гарантированно обеспечит масштабирование и требуемый уровень производительности для целевой нагрузки, приобрести массив с небольшим числом накопителей, и постепенно расширять его. Однако такой вариант потребует больших затрат на начальных этапах, кроме того, постепенный апгрейд обычно обходится дороже, чем единоразовая покупка.
Если отойти от классических массивов, то появляется возможность по использованию программно-конфигурируемых хранилищ, поддерживающих горизонтальное масштабирование по аналогии с вычислительной подсистемой, либо гиперконвергентных решений, которые позволяют одновременно наращивать вычислительные и дисковые ресурсы.
При планировании хранения для VDI следует учитывать, что далеко не все технологии хранения, поддерживаемые в vSphere, поддерживаются и для Horizon. Так среди известных ограничений:
В этом плане NAS хранилища гораздо площе, т.к. не имеют многих ограничений блочного доступа.
К преимуществам vSAN можно отнести простоту развертывания, высокую производительности и экономию на внедрении за счет использования лицензий vSAN for Horizon Advanced, входящих в бандлы Horizon Advanced или Enterprise.
При выборе конфигурации сервера для vSAN можно приобрести предопределенные и протестированные вендорами конфигурации – vSAN Ready Nodes от различных производителей (HPE, Dell, Cisco, Huawei, Lenovo и другие), либо самостоятельно собирать серверы из совместимых компонентов (https://www.vmware.com/resources/compatibility/search.php?deviceCategory=vsan).
К преимуществам vSAN (как и многих других программно-конфигурируемых хранилищ) относится возможность горизонтального масштабирования. vSAN поддерживает создание кластеров до 64 узлов для локального кластера или до 31 узла – для территориально распределенного (stretched) кластера.
vSAN можно запустить даже на одном сервере, т.н. bootstrap режим, который используется для установки и развертывания виртуальной инфраструктуры с нуля, когда нет работающего сервера vCenter. Однако следует помнить, что такая конфигурация официально не поддерживается VMware.
Минимальная поддерживая конфигурация - два хоста. Двухузловой кластер может использоваться в небольших инсталляциях в филиалах (Branch office). Важным требованием для развертывания двухузловой конфигурации является наличие узла-свидетеля на третьей площадке. Узел свидетель представляет собой виртуальную машину с установленным гипервизором ESXi, которые хранит witness компоненты и выступает арбитром для предотвращения возникновения split brain.
Если говорить о варианте развертывания без использования специализированных компонентов, то минимальное кол-во хостов – 3. В данной конфигурации каждый хост хранит данные ВМ и witness компоненты, которые автоматически распределяются по хостам. Для трехузлового кластера возможна настройка режима избыточного хранения – Fault to Tolerate = 1, при котором vSAN создает и поддерживает в синхронном состоянии две копии данных, так, что отказ одного любого компонента (жесткого диска, SSD, контроллера, либо хоста целиком) не приведет к потере данных.
Часто в официальных руководствах можно встретить рекомендацию по использованию в кластере vSAN не менее 4-х узлов. Откуда взялась данная рекомендация?
Это сделано для того, чтобы в случае отказа одного хоста, или переводе его в режим обслуживания, в кластере осталось 3 узла и была возможность восстановить избыточность данных. В случае 3-узлового кластера отказ одного хоста позволит сохранить доступ к данным (при FTT=1) однако двух оставшихся хостов будет недостаточно, чтобы хранить две копии данных и witness компоненты, такой кластер будет работать в деградировавшем режиме, пока третий хост не вернется в строй. По этой же причине VMware рекомендует резервировать в кластере часть дискового пространства (порядка 30%), которое будет использоваться для восстановления избыточности хранения в случае отказа хоста.
Еще одна причина для резервирования дискового пространства, когда на накопителе, хранящем данные (capacity device) остается менее 20% свободного пространства, vSAN запускает процедуру балансировки компонентов по другим хостам, что может создать дополнительную нагрузку на дисковую подсистему. Для этих целей VMware и рекомендует оставлять резерв порядка 30% для восстановления избыточности при отказе или переводе в режим обслуживания хоста в кластере.
Для того, чтобы vSAN мог хранить данные на хосте, на нем должна быть создана, по крайней мере, одна дисковая группа. Дисковая группа включает в себя накопители двух типов:
Следует помнить, что в vSAN отличается подход к работе с flash кэшем для гибридных и all-flash конфигураций.
Для гибридных конфигураций flash кэш делится в соотношении 70/30 на кэш для операций чтения и кэш для операций записи.
В all flash конфигурациях вся емкость Performance tier выделяется под кэш на запись. Чтение же выполняется напрямую с flash накопителей, относящихся к capacity tier.
При планировании конфигурации накопителей VSAN следует помнить, что максимальный размер кэша на запись для одной дисковой группы составляет 600 Гигабайт. Это не слишком критично для гибридных конфигураций, поскольку будет являться ограничением только при использовании SSD накопителей объемом более 2 ТБ под кэш. В all-flash конфигурациях накопители объемом более 600 ГБ на дисковую группу не будут полностью утилизироваться. С другой стороны, использование накопителей большей емкости позволит уменьшить износ и повысить ресурс SSD за счет использования технологий типа TRIM, обеспечивающих равномерную перезапись данных по всем ячейкам.
Управление настройками VSAN осуществляется гранулярно при помощи политик хранения (Storage Policies) для каждого объекта.
VSAN позволяет хранить следующие типы объектов
Перечень настроек VSAN:
Number of Failures To Tolerate - определяет кол-во копий объектов, которые размещаются на хранилище VSAN. Фактически, данная настройка определяет, какое число одновременных отказов в кластере объект может перенести с гарантированным сохранением доступа к данным. Копии объектов размещаются на разных хостах кластера, что позволяет переживать отказ любого аппаратного компонента сервера - жёсткого диска, flash накопителя, HBA адаптера, сервера целиком, а при использовании совместно с механизмом Fault Domain - стойки или всей площадки (при реализации распределенного кластера VSAN). Параметр может принимать значение от 0 до 3.
Минимальное значение FTT=0, означает, что на VSAN размещается всего одна копия данных без резервирования, что, эквивалентно JBOD или RAID-0 конфигурации дисковой подсистемы.
При FTT=1 в кластере хранятся две копии данных - аналог raid 10, что позволяет обеспечивать доступность при отказе любого одного компонента VSAN. Для данного режима также поддерживается режим erasure coding.
При FTT=2 в кластере хранятся три копии данных, что позволяет гарантированно пережить отказ одновременно любых двух компонентов. Для FTT=2 Vmware заявляет о доступности данных на уровне 99.9999%. Для данного режима такжеподдерживается erasure coding, о котором ниже.
Наконец, FTT=3 обеспечивает хранение четырёх копий данных и позволяет пережить отказ любых трёх компонентов.
В VSAN 6.6 данная политика были изменена из-за появления механизма Local Protection for Stretched Clusters. До этого при настройке Stretched VSAN Cluster поддерживался лишь режим FTT=1, при котором одна копия объекта хранилась на хостах на одной площадке, а вторая копия - на второй. Это означало, что при отказе площадки, доступной оставалась только одна копия данных для которой VSAN не восстанавливал избыточность и любой последующий отказ на второй площадке мог привести к потере данных.
В VSAN 6.6 появилась возможность дополнительно защищать данные на каждой из площадок.
Параметр Primary level of failures to tolerate определяет уровень защиты данных между площадками (хранить 1 или 2 копии).
Параметр Secondary level of failures to tolerate определяет уровень защиты данных внутри площадки и может принимать значение от 0 до 3.
В таблице приведена информация о требованиях к минимальному числу хостов в кластере и накладных расходах на хранения при разных уровнях PFTT и SFTT.
Number of Disk Stripes Per Object – управляет настройками страйпинга (размазыванием) копии объекта по накопителям Capacity Tier.
Параметр может принимать значение от 1 до 12. Параметр определяет – на каком минимальном числе накопителей Capacity Tier будет размещаться объект.
Каждая копия объекта состоит из одного или более компонентов, которые, в свою очередь, хранится на одном из накопителей capacity tier. Все компоненты, которые хранят данные объекта, объединяются в страйп (аналог RAID-0). Данные распределяеются по компонентам равномерно, блоками (chunk) размером по 1 МБ.
В каких случаях может происходить разделение копии объекта на несколько компонентов? Во-первых, размер компонента не может превышать 255 ГБ, поэтому если размер (копии) объекта больше 255 ГБ, то он разбивается на пропорциональное число компонентов. Например, виртуальный диск размером 1 ТБ, имеющий одну копию на VSAN, будет состоять минимум из 5 компонентов (без учета политики FTT).
Во-вторых, объект может разбиваться на компоненты, если на физическом накопителей capacity tier недостаточно свободного места. Например, если надо сохранить объект размером 100 ГБ, а на дисках осталось по чуть более 50 ГБ свободного пространства, то объект будет разделен на два компонента по 50 ГБ.
В-третьих, если для объекта задана настройка Number of Disk Stripes Per Object больше 1, то для соответствия требованиям политики VSAN разделит объект на нужное число компонентов. Следует помнить, что данная политика определяет только минимальное число дисков для размещения компонентов, поэтому вполне возможна ситуация, когда реальное число компонентов больше того, что указано в политике.
Object Space Reservation, по умолчанию все объекты на VSAN, кроме файла подкачки ВМ создаются тонкими, т.е. без резервирования дискового пространства (Space Reservation = 0) и растут по мере заполнения данными.
Данная политика позволяет регулировать какой объем дискового пространства будет резервироваться для объекта. В случае 100% резервации вы получите обычные thick диски, при 0% - тонкие, при любых значения между - что-то среднее.
Flash Read Cache Reservation - политика определяет какой объем кэш памяти на чтение резервируется для данного объекта. По умолчанию резко для объектов равен 0%, однако для обеспечения гарантированного уровня производительности вы можете зарезервировать часть пространства. Для вм horizon по умолчанию используется настройка которая для replica дисков резервирует 10% дискового пространства на чтение. Эта политика не применяется для all flash конфигураций.
Force Provisioning - политика, которая определяет - возможно ли создать объект на VSAN, в случае, когда не могут быть выполнены остальные политики, например, если недостаточно хостов или дискового пространства для создания нужного количества копий. Если политика не включена то объект не создастся, если не сможет удовлетворять всем требованиям политики.
Failure Tolerance Method - включает или отключает режим erasure coding для объекта для экономии дискового пространства. При отключенном EC VSAN хранит несколько полных копий объектов для обеспечения избыточности сетевой аналог raid1/10, при включенном ec для обеспечения избыточности используются хэш суммы, аналог raid5 для FTT=1 и raid6 - для FTT=2.
Использование EC позволяет существенно снизить требования к дисковому пространства. Цена за экономию - большая нагрузка на дисковую подсистему. Данная политика работает только для all-flash конфигураций VSAN.
Disable Object Checksum включает или отключает использование контрольных сумм для выявления и исправления одиночных ошибок при записи или чтении данных. Создает большую нагрузку на процессор.
IOPS limit for object – доступна только в редакции vSAN Enterprise. Ограничивает кол-во IOPS для объекта. В качестве размера блока для IO операции берется 32 КБ, таким образом, чтение или запись блока размером 64 КБ будет считаться уже за 2 IO операции.
Еще одна политика, которая не имеет прямого отношения к VSAN, но может использоваться совместно - это политики Storage I/O Control, позволяющие гарантировать определнный уровень производительности ввода вывода для виртуалтных машин, начиная с vSphere 6.6 настройки SIOC также задаются через механизм Storage Policies и позволяют задавать лимиты и резервирование IOPS.
SIOC может пригодиться как для решения проблем с boot или antivirus storm, когда несколько ВМ могут репетировать большое кол-во запросов вода вывода к дисковой подсистеме, так и для приоритизации операций ввода-вывода для ВМ в целях обеспечения лучшего уровня производительности для привилегированных пользователей.
В случае с VSAN вы можете достаточно просто выполнять сайзинг дисковой подсистемы на случай дальнейшего роста. Вы можете начать с небольшого кол-ва хостов, обеспечивающих работу виртуальных десктопов и в дальнейшем масштабировать кластер , увеличивая число узлов и одновременно расширяя вычислительные ресурсы и ресурсы хранения.
Продолжение доступно по ссылкам:
Дополнительные материалы:
Часть 1. Введение
Часть 2. Постановка задачи
Часть 3. Верхнеуровневая архитектура
Часть 4. Подсистема VMware Horizon
Часть 5. Подсистема виртуализации
Часть 6. Лицензирование VDI
Часть 7. Виртуальные машины
8.1 Масштабирование СХД
VDI представляет собой прекрасный пример системы, которая масштабируется горизонтально. Из-за того, что один виртуальный десктоп потребляет небольшую часть вычислительных ресурсов, и таких десктопов много, суммарная нагрузка может быть равномерно распределена между физическими серверами. Поэтому сервер становится единицей масштабирование, добавление нового сервера в кластер позволяет запустить дополнительные 50, 100, 200 виртуальных десктопов.При использовании классических систем хранения существует два основных варианта планирования архитектуры.
Вариант первый – выбрать дисковый массив, который соответствует текущим требованиям по емкости и производительности. Это позволит снизить первоначальные затраты, однако может создать сложности при масштабировании решения. И если с дисковым пространством все относительно просто, требуется пространство – покупаете дополнительные диски/дисковые полки и подключаете к массиву, то с наращиванием производительности могут возникать проблемы. Рано или поздно производительность массива упрется в контроллеры или интерфейсы передачи данных. Это потребует либо апгрейда массива путем замены/добавления контроллеров (если такая возможность поддерживается), либо покупкой второго массива, что приведет к увеличению затрат на обслуживание.
Вариант второй – это выбрать массив более высокого класса, который гарантированно обеспечит масштабирование и требуемый уровень производительности для целевой нагрузки, приобрести массив с небольшим числом накопителей, и постепенно расширять его. Однако такой вариант потребует больших затрат на начальных этапах, кроме того, постепенный апгрейд обычно обходится дороже, чем единоразовая покупка.
Если отойти от классических массивов, то появляется возможность по использованию программно-конфигурируемых хранилищ, поддерживающих горизонтальное масштабирование по аналогии с вычислительной подсистемой, либо гиперконвергентных решений, которые позволяют одновременно наращивать вычислительные и дисковые ресурсы.
8.2 Типы хранилищ
vSphere поддерживает следующие типы хранилищ:- Блочные с файловой системой VMFS версии 3, 5 или 6 (локальные диски, тома, подключаемые по SAS, iSCSI, FC, FCoE).
- Файловые (NFS v3, NFS v4.1).
- Объектные (хранилище VMware VSAN, Dell EMC ScaleIO).
- Блочные или файловые с поддержкой Virtual Volumes (VVOL).
В таблице приведено сравнение типов хранилищ по ряду параметров. Некоторые модели СХД могут накладывать дополнительные ограничения, например, на максимальный размер LUN под хранилища, наличие или отсутствие поддержки VAAI, возможностям по репликации и т.д.
Функции | Блочное хранилище (VMFS) | Сетевой каталог (NFS) | Объектное хранилище (VSAN) |
| Среда передачи данных | SAS, Ethernet, Fibre Channel | Ethernet | Ethernet |
| Максимальный размер хранилища | 64 ТБ | 64 ТБ | 64 ТБ |
| Максимальный размер VMDK | 62 ТБ | 62 ТБ | 62 ТБ |
| Максимальное число хостов, которым может быть презентовано хранилище | 64 | n/a | 64 |
| Кол-во хранилищ на один хост | 512 | 256 | 1 |
| Кол-во ВМ на один хост | 1024 | 1024 | 200 |
| Включенных ВМ на одном хранилище | 2048 | n/a | 6000 |
| Поддержка составных хранилищ (extent) | Да | Нет | Нет |
| Поддержка многопутевого ввода-вывода (multipathing) | Да, для балансирования нагрузки и отказоустойчивости | Поддерживается в NFS v4 для обеспечения отказоустойчивости | Не применимо* |
| Поддержка SIOC | Да | Нет | Да |
| Поддержка Raw Device Mapping | Да | Нет | Да** |
| Поддержка VAAI | Да, зависит от массива | Да, зависит от массива | Не применимо |
| Поддержка VASA | Да, зависит от массива | Да, зависит от массива | Да |
| Поддержка VVOLS | Да | Да, кроме NFS v4.1 | Нет |
| Поддержка шифрования VM Encryption | Да | Да | Да, также поддерживается VSAN Data at Rest Encryption |
| Поддержка Virtual Flash Read Cache (vFlash) | Да | Да | Нет |
| Поддержка Storage DRS | Да | Да, кроме NFS v4.1 | Нет |
| Поддержка vSphere Replication | Да | Да | Да |
| Поддержка аппаратной репликации | Да | Да | Нет |
* VSAN является распределенной системой хранения. Передача данных между узлами выполняется через VMKernel интерфейсы. Агрегация каналов средствами виртуального коммутатора и/или несколько VMKernel интерфейсов на одном хосте поддерживаются, но только для обеспечения отказоустойчивости.
** В VSAN 6.5 появилась функция Software iSCSI Target, позволяющая презентовать LUN, хранящиеся на VSAN клиентским устройствам по протоколу iSCSI, данные LUN могут быть презентованы как RDM диски виртуальным машинам. В vSAN 6.7 такие LUN могут использоваться в качестве общих дисков для кластеров Windows Server Failover Cluster.При планировании хранения для VDI следует учитывать, что далеко не все технологии хранения, поддерживаемые в vSphere, поддерживаются и для Horizon. Так среди известных ограничений:
- Отсутствие поддержки vFlash для Automated Pool десктопов.
- Отсутствие поддержки Storage vMotion для Linked-Clone десктопов.
- Storage DRS кластеры поддерживаются только для пулов с Full-clone десктопами.
- Отсутствие поддержки vSphere Replication.
8.3 Сайзинг размера хранилищ
Несмотря на ограничение в максимальный размер хранилища VMFS в 64 ТБ на практике вы вряд ли будет использовать такие большие хранилища. Причин так делать может быть много:- Ограничение на максимальные размер LUN со стороны СХД.
- Решение проблем с производительностью. На производительность блочного доступа большое влияние может оказывать глубина очереди команд (Queue Depth). Глубина очереди есть у накопителей, адаптеров ввода-вывода, портов массива, есть она и у LUN. При размещении большого количества ВМ на одном LUN, подключенного к большому числу хостов, вы можете упереться в размер очереди к логическому тому. Еще одна проблема с производительностью касается старых массивов, а также некоторых конфигураций на современных массивах. До появления VAAI ATS в vSphere 4.0 запуск ВМ, расширение thin диска, создание снапшота требовали временной блокировки всего LUN. При большом количестве ВМ подобные операции происходят достаточно часто, что может приводить к уменьшению производительности. Практически все современные массивы поддерживают VAAI, однако в некоторых случаях он может отключаться (например, при настройке репликации LUN на удаленный массив).
- Балансирование нагрузки на сеть хранения. При блочном доступе в один момент времени доступ к LUN со одного хоста осуществляется через один путь. Увеличив числов LUN, вы можете настроить доступ к ним, используя разные пути до массива.
- Использование разных LUN под хранение разных типов данных. Помимо очевидного преимущества в виде тиринга средствами Horizon, например, размещение linked-clone реплик на LUN на Flash накопителях, дельта дисков на LUN на SAS дисках, а persistent дисков на SATA, это также может пригодиться в случаях, когда вы планируете использовать репликацию средствами СХД для катастрофоустойчивых сценариев, чтобы, например, чтобы вынести файлы подкачки ВМ на отдельный LUN и не реплицировать его вместе с дисками виртуальных машин.
- Ограничения и рекомендации со стороны VMware. Согласно VMware Horizon 7 Sizing Limits and Recommendations на одном логическом томе рекомендуется размещать не более 500 ВМ.
8.4 VMware vSAN
Одним из вариантов организации хранения ВМ для VDI является использование SDS на базе VMware vSAN.К преимуществам vSAN можно отнести простоту развертывания, высокую производительности и экономию на внедрении за счет использования лицензий vSAN for Horizon Advanced, входящих в бандлы Horizon Advanced или Enterprise.
При выборе конфигурации сервера для vSAN можно приобрести предопределенные и протестированные вендорами конфигурации – vSAN Ready Nodes от различных производителей (HPE, Dell, Cisco, Huawei, Lenovo и другие), либо самостоятельно собирать серверы из совместимых компонентов (https://www.vmware.com/resources/compatibility/search.php?deviceCategory=vsan).
К преимуществам vSAN (как и многих других программно-конфигурируемых хранилищ) относится возможность горизонтального масштабирования. vSAN поддерживает создание кластеров до 64 узлов для локального кластера или до 31 узла – для территориально распределенного (stretched) кластера.
vSAN можно запустить даже на одном сервере, т.н. bootstrap режим, который используется для установки и развертывания виртуальной инфраструктуры с нуля, когда нет работающего сервера vCenter. Однако следует помнить, что такая конфигурация официально не поддерживается VMware.
Минимальная поддерживая конфигурация - два хоста. Двухузловой кластер может использоваться в небольших инсталляциях в филиалах (Branch office). Важным требованием для развертывания двухузловой конфигурации является наличие узла-свидетеля на третьей площадке. Узел свидетель представляет собой виртуальную машину с установленным гипервизором ESXi, которые хранит witness компоненты и выступает арбитром для предотвращения возникновения split brain.
Если говорить о варианте развертывания без использования специализированных компонентов, то минимальное кол-во хостов – 3. В данной конфигурации каждый хост хранит данные ВМ и witness компоненты, которые автоматически распределяются по хостам. Для трехузлового кластера возможна настройка режима избыточного хранения – Fault to Tolerate = 1, при котором vSAN создает и поддерживает в синхронном состоянии две копии данных, так, что отказ одного любого компонента (жесткого диска, SSD, контроллера, либо хоста целиком) не приведет к потере данных.
Часто в официальных руководствах можно встретить рекомендацию по использованию в кластере vSAN не менее 4-х узлов. Откуда взялась данная рекомендация?
Это сделано для того, чтобы в случае отказа одного хоста, или переводе его в режим обслуживания, в кластере осталось 3 узла и была возможность восстановить избыточность данных. В случае 3-узлового кластера отказ одного хоста позволит сохранить доступ к данным (при FTT=1) однако двух оставшихся хостов будет недостаточно, чтобы хранить две копии данных и witness компоненты, такой кластер будет работать в деградировавшем режиме, пока третий хост не вернется в строй. По этой же причине VMware рекомендует резервировать в кластере часть дискового пространства (порядка 30%), которое будет использоваться для восстановления избыточности хранения в случае отказа хоста.
Еще одна причина для резервирования дискового пространства, когда на накопителе, хранящем данные (capacity device) остается менее 20% свободного пространства, vSAN запускает процедуру балансировки компонентов по другим хостам, что может создать дополнительную нагрузку на дисковую подсистему. Для этих целей VMware и рекомендует оставлять резерв порядка 30% для восстановления избыточности при отказе или переводе в режим обслуживания хоста в кластере.
Для того, чтобы vSAN мог хранить данные на хосте, на нем должна быть создана, по крайней мере, одна дисковая группа. Дисковая группа включает в себя накопители двух типов:
- Накопитель для Performance Tier, который используется для кэширования операций ввода/вывода – это Flash накопитель с SATA, SAS или PCI-E (включая NVMe) интерфейсом. Для создания дисковой группы в ней обязательно должен присутствовать один (не более и не менее) Flash накопитель для Performance Tier.
- Накопители для Capacity Tier, которые используются для хранения данных ВМ. В качестве накопителя могут использоваться жесткие диски с интерфейсом SATA/SAS – такие конфигурации носят название гибридные (Hybrid), или Flash накопители – такие конфигурации называются All-Flash. В одной дисковой группе может присутствовать от 1 до 7 накопителей Capacity Tier. Смешивание hybrid и all-flash накопителей в рамках дисковой группы, хоста, или всего кластера не поддерживается. Единственное исключение – миграция с hybrid на all-flash конфигурации.
Следует помнить, что в vSAN отличается подход к работе с flash кэшем для гибридных и all-flash конфигураций.
Для гибридных конфигураций flash кэш делится в соотношении 70/30 на кэш для операций чтения и кэш для операций записи.
В all flash конфигурациях вся емкость Performance tier выделяется под кэш на запись. Чтение же выполняется напрямую с flash накопителей, относящихся к capacity tier.
При планировании конфигурации накопителей VSAN следует помнить, что максимальный размер кэша на запись для одной дисковой группы составляет 600 Гигабайт. Это не слишком критично для гибридных конфигураций, поскольку будет являться ограничением только при использовании SSD накопителей объемом более 2 ТБ под кэш. В all-flash конфигурациях накопители объемом более 600 ГБ на дисковую группу не будут полностью утилизироваться. С другой стороны, использование накопителей большей емкости позволит уменьшить износ и повысить ресурс SSD за счет использования технологий типа TRIM, обеспечивающих равномерную перезапись данных по всем ячейкам.
Управление настройками VSAN осуществляется гранулярно при помощи политик хранения (Storage Policies) для каждого объекта.
VSAN позволяет хранить следующие типы объектов
- Виртуальные диски (vmdk).
- Снапшоты виртуальных дисков (-delta.vmdk).
- Файл подкачки ВМ (vswp).
- Конфигурационный раздел, где хранится файл настроек (.vmx), файлы журналов (.log), файл настроек биоса (.nvram) и т.д.
Перечень настроек VSAN:
Number of Failures To Tolerate - определяет кол-во копий объектов, которые размещаются на хранилище VSAN. Фактически, данная настройка определяет, какое число одновременных отказов в кластере объект может перенести с гарантированным сохранением доступа к данным. Копии объектов размещаются на разных хостах кластера, что позволяет переживать отказ любого аппаратного компонента сервера - жёсткого диска, flash накопителя, HBA адаптера, сервера целиком, а при использовании совместно с механизмом Fault Domain - стойки или всей площадки (при реализации распределенного кластера VSAN). Параметр может принимать значение от 0 до 3.
Минимальное значение FTT=0, означает, что на VSAN размещается всего одна копия данных без резервирования, что, эквивалентно JBOD или RAID-0 конфигурации дисковой подсистемы.
При FTT=1 в кластере хранятся две копии данных - аналог raid 10, что позволяет обеспечивать доступность при отказе любого одного компонента VSAN. Для данного режима также поддерживается режим erasure coding.
При FTT=2 в кластере хранятся три копии данных, что позволяет гарантированно пережить отказ одновременно любых двух компонентов. Для FTT=2 Vmware заявляет о доступности данных на уровне 99.9999%. Для данного режима такжеподдерживается erasure coding, о котором ниже.
Наконец, FTT=3 обеспечивает хранение четырёх копий данных и позволяет пережить отказ любых трёх компонентов.
В VSAN 6.6 данная политика были изменена из-за появления механизма Local Protection for Stretched Clusters. До этого при настройке Stretched VSAN Cluster поддерживался лишь режим FTT=1, при котором одна копия объекта хранилась на хостах на одной площадке, а вторая копия - на второй. Это означало, что при отказе площадки, доступной оставалась только одна копия данных для которой VSAN не восстанавливал избыточность и любой последующий отказ на второй площадке мог привести к потере данных.
В VSAN 6.6 появилась возможность дополнительно защищать данные на каждой из площадок.
Параметр Primary level of failures to tolerate определяет уровень защиты данных между площадками (хранить 1 или 2 копии).
Параметр Secondary level of failures to tolerate определяет уровень защиты данных внутри площадки и может принимать значение от 0 до 3.
В таблице приведена информация о требованиях к минимальному числу хостов в кластере и накладных расходах на хранения при разных уровнях PFTT и SFTT.
Режим | Мин. Кол-во хостов (локальный кластер PFTT=0) | Требование к дисковому пространству % (локальный кластер) | Мин. кол-во хостов (stretched кластер) | Требование к дисковому пространству % (stretched кластер PFTT=1) |
| SFTT=0 | 1 | 100% | 2 | 200% |
| SFTT=1 (Mirroring) | 2 + witness или 3 | 200% | 4 | 400% |
| SFTT=1 + Erasure Coding | 4 | 133% | 8 | 266% |
| SFTT=2 (Mirroring) | 5 | 300% | 10 | 600% |
| SFTT=2 + Erasure Coding | 6 | 150% | 12 | 300% |
| SFTT=3 (Mirroring) | 7 | 400% | 14 | 800% |
Number of Disk Stripes Per Object – управляет настройками страйпинга (размазыванием) копии объекта по накопителям Capacity Tier.
Параметр может принимать значение от 1 до 12. Параметр определяет – на каком минимальном числе накопителей Capacity Tier будет размещаться объект.
Каждая копия объекта состоит из одного или более компонентов, которые, в свою очередь, хранится на одном из накопителей capacity tier. Все компоненты, которые хранят данные объекта, объединяются в страйп (аналог RAID-0). Данные распределяеются по компонентам равномерно, блоками (chunk) размером по 1 МБ.
В каких случаях может происходить разделение копии объекта на несколько компонентов? Во-первых, размер компонента не может превышать 255 ГБ, поэтому если размер (копии) объекта больше 255 ГБ, то он разбивается на пропорциональное число компонентов. Например, виртуальный диск размером 1 ТБ, имеющий одну копию на VSAN, будет состоять минимум из 5 компонентов (без учета политики FTT).
Во-вторых, объект может разбиваться на компоненты, если на физическом накопителей capacity tier недостаточно свободного места. Например, если надо сохранить объект размером 100 ГБ, а на дисках осталось по чуть более 50 ГБ свободного пространства, то объект будет разделен на два компонента по 50 ГБ.
В-третьих, если для объекта задана настройка Number of Disk Stripes Per Object больше 1, то для соответствия требованиям политики VSAN разделит объект на нужное число компонентов. Следует помнить, что данная политика определяет только минимальное число дисков для размещения компонентов, поэтому вполне возможна ситуация, когда реальное число компонентов больше того, что указано в политике.
Object Space Reservation, по умолчанию все объекты на VSAN, кроме файла подкачки ВМ создаются тонкими, т.е. без резервирования дискового пространства (Space Reservation = 0) и растут по мере заполнения данными.
Данная политика позволяет регулировать какой объем дискового пространства будет резервироваться для объекта. В случае 100% резервации вы получите обычные thick диски, при 0% - тонкие, при любых значения между - что-то среднее.
Flash Read Cache Reservation - политика определяет какой объем кэш памяти на чтение резервируется для данного объекта. По умолчанию резко для объектов равен 0%, однако для обеспечения гарантированного уровня производительности вы можете зарезервировать часть пространства. Для вм horizon по умолчанию используется настройка которая для replica дисков резервирует 10% дискового пространства на чтение. Эта политика не применяется для all flash конфигураций.
Force Provisioning - политика, которая определяет - возможно ли создать объект на VSAN, в случае, когда не могут быть выполнены остальные политики, например, если недостаточно хостов или дискового пространства для создания нужного количества копий. Если политика не включена то объект не создастся, если не сможет удовлетворять всем требованиям политики.
Failure Tolerance Method - включает или отключает режим erasure coding для объекта для экономии дискового пространства. При отключенном EC VSAN хранит несколько полных копий объектов для обеспечения избыточности сетевой аналог raid1/10, при включенном ec для обеспечения избыточности используются хэш суммы, аналог raid5 для FTT=1 и raid6 - для FTT=2.
Использование EC позволяет существенно снизить требования к дисковому пространства. Цена за экономию - большая нагрузка на дисковую подсистему. Данная политика работает только для all-flash конфигураций VSAN.
Disable Object Checksum включает или отключает использование контрольных сумм для выявления и исправления одиночных ошибок при записи или чтении данных. Создает большую нагрузку на процессор.
IOPS limit for object – доступна только в редакции vSAN Enterprise. Ограничивает кол-во IOPS для объекта. В качестве размера блока для IO операции берется 32 КБ, таким образом, чтение или запись блока размером 64 КБ будет считаться уже за 2 IO операции.
Еще одна политика, которая не имеет прямого отношения к VSAN, но может использоваться совместно - это политики Storage I/O Control, позволяющие гарантировать определнный уровень производительности ввода вывода для виртуалтных машин, начиная с vSphere 6.6 настройки SIOC также задаются через механизм Storage Policies и позволяют задавать лимиты и резервирование IOPS.
SIOC может пригодиться как для решения проблем с boot или antivirus storm, когда несколько ВМ могут репетировать большое кол-во запросов вода вывода к дисковой подсистеме, так и для приоритизации операций ввода-вывода для ВМ в целях обеспечения лучшего уровня производительности для привилегированных пользователей.
В случае с VSAN вы можете достаточно просто выполнять сайзинг дисковой подсистемы на случай дальнейшего роста. Вы можете начать с небольшого кол-ва хостов, обеспечивающих работу виртуальных десктопов и в дальнейшем масштабировать кластер , увеличивая число узлов и одновременно расширяя вычислительные ресурсы и ресурсы хранения.
Продолжение доступно по ссылкам:
Часть 10. Организация подключения и безопасность
Часть 11. Доступность VDI, Резервное копирование и аварийное восстановление
Часть 11. Доступность VDI, Резервное копирование и аварийное восстановление
Дополнительные материалы:
- VMware vSAN Design and Sizing Guide: https://storagehub.vmware.com/export_to_pdf/vmware-r-virtual-san-tm-design-and-sizing-guide
- VMware Horizon 6 Storage Considerations (https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/vmware-horizon-view-mirage-workspace-portal-app-volumes-storage.pdf).
- VMware vSphere Storage DRS Interoperability (https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/vsphere-storage-drs-interoperability-white-paper.pdf).
0 коммент.:
Отправить комментарий