Как многие уже слышали, совсем недавно вышла первая версия продукта VMware VSAN, который был выпущен одновременно с релизом обновленной платформы VMware vSphere 5.5 Update 1.
Многие уже принялись тестировать это решение, которое (что похвально) теперь работает производительнее своей же бета-версии:
И в то же время линейно масштабируется по количеству узлов ESXi с точки зрения производительности:
Как мы уже упоминали, существование виртуальных машин в кластере VSAN на дисках хост-серверов VMware ESXi определяется политикой хранилищ (Storage Policy), которую можно задать в vSphere Client:
Создаем новую политику:
Далее создаем набор Rule Set в рамках политики, в который можно включить несколько правил для хранилищ (для этой политики они все будут соблюдаться):
Политика работает всегда, когда мы пытаемся создать новую виртуальную машину в кластере хранилищ VSAN. При этом, если мы не задаем правила в политике, то она дефолтно использует значения Numbers of failures to tolerate = 1 и Number of disk stripes per object = 1.
Рассмотрим правила, работающие в политиках, подробнее:
Numbers of failures to tolerate (на рисунке обозначено цифрой 2) - это правило политики означает, какое количество отказов хостов может пережить кластер хранилищ. Если установлено значение 1 (по умолчанию), то реплика одного VMDK будет размещена на дисках еще одного из хостов кластера. То есть, по-сути, это RAID-1 для виртуальных машин в рамках кластера:
Интересен тут аспект, что FailuresToTolerate (FTT) дефолтно установлен в значение 1 только если вы не используете других правил. А вот если вы его не зададите, но выставите, например, правило Number of disk stripes per object, то значение FTT будет равно нулю, а значит данные в кластере будут размещены без избыточности - с риском для их утери. Поэтому будьте осторожны и прочитайте на эту тему вот эту статью.
Максимальное значение параметра FailuresToTolerate равно трем. Для того, чтобы выдержать N сбоев потребуется N+1 копий виртуальной машины на хостах, а самих хостов потребуется 2N+1.
И имейте в виду, что если Number of failures to tolerate=0, то при переводе хоста в режим обслуживания (Maintenance mode) возникнет серьезная задержка, так как VSAN будет переносить диски машин с этого хоста на другие.
Number of disk stripes per object - число HDD-дисков на хосте, по которому будет распределена каждая реплика виртуальной машины. Значение больше чем 1 создает что-то типа виртуального RAID-0, который будет отзеркалирован на другие хосты, где находится реплика этой ВМ. Такая конфигурация может повысить производительность подсистемы ввода-вывода (но не факт - см. здесь), однако приводит к более высокой степени использования дисковой емкости. Плюс сюда добавляется усложнение конфигурации дисковой подсистемы. В целом, этот параметр менять не рекомендуется, достаточно дефолтного значения 1. Максимальное значение этого параметра равно 12.
Flash Read Cache Reservation - это процент дисковой емкости от Storage object (иными словами, виртуального диска VMDK машины), который будет зарезервирован для кэша на чтение на SSD-диске. Тут нужно использовать значения не более 1% (а вообще параметр можно указывать в сотых долях процента). То есть если у вас машина с диском 100 ГБ, то под кэш в случае 1% будет использован 1 ГБ, чего более чем достаточно. Вообще, этот параметр менять не рекомендуется (и пока нет рекомендаций по его применению). По умолчанию он равен 0 (то есть, нет резервирования кэша), максимальное значение = 100%.
Force Provisioning - этот параметр позволяет развернуть виртуальную машину в кластере хранилищ даже в том случае, если VM Storage Policy не соблюдается на хранилищах. Для этого нужно установить значение отличное от нуля. В этом случае виртуальная машина будет отображаться как non-compliant на вкладке VM Summary, а также в соответствующих представлениях интерфейса VM Storage Policy. Учитывайте, что если не удается соблюсти условия резервирования хотя бы для одной реплики ВМ, то она не будет развернута, даже если параметр Force Provisioning включен. По умолчанию, естественно, Force Provisioning выключен.
Object space reservation - это правило определяет процент дисковой емкости от объема виртуального диска ВМ, который должен быть зарезервирован на хранилище при создании виртуальной машины. В кластере VSAN все виртуальные машин по умолчанию создаются как Thin Provisioned (то есть с дисками, растущими по мере наполнения их данными). По умолчанию установлено значение 0% - то есть нет вообще никакого резервирования пространства. Если вы поставите Object Space Reservation в значение 100%, то виртуальные машины будут создаваться с дисками типа Thick. Однако это будут диски типа lazy zeroed thick (LZT), но не eager zeroed thick (EZT) - об их отличиях мы писали тут.
Так-то если подумать, то становится понятно, что для большинства случаев вполне достаточно будет дефолтной конфигурации - то есть однократная избыточность при хранении ВМ на хостах, а сами виртуальные диски пусть хранятся каждый на своем физическом, чтобы не мутить никаких лишних сложностей.
RSS
