Nutanix и режим Linked Clones в VMware

Работающие с VDI знают очень удобный механизм организации виртуальных дисков для таких виртуальных машин в VMware, так называемые Linked Clones. Механизм этот основывается на том факте, что, очень часто, виртуальные десктопы, разворачиваемые пользователям, очень мало отличаются один от другого. Есть некий эталонный образ OS, и прикладных программ в нем, а небольшое количество индивидуальных данных, таких как настройки профилей пользователя или его индивдуальные данные на этом десктопе, составляет сравнительно небольшой объем. Этот небольшой индивидуальный объем данных записывается в отдельный «дельта-файл», а все остальные данные образа неизменными берутся из одного эталонного образа. Соответственно же записи данных, если их делает пользователь такого виртуального десктопа, прозрачным для него образом отправляются в «дельта-файл», а чтения основного объема данных, например при загрузке, делаются из эталонного образа.

Проблема с Linked Clones заключаются в том, что этот механизм реализован самим VMware ESX, и прозрачен для хранилища, а значит нет никаких способов как-то на этот механизм и его работу повлиять.

А для Nutanix это все очень нехорошо, так как такой механизм доступа к данным ломает всю отлаженную кластерную кухню доступа в NDFS. Как вы уже должны были узнать, основной принцип NDFS заключается в стремлении выполнять весь ввод-вывод максимально «локально», к данным, находящимся на локальных дисках конкретно этого узла, а если данные, к которым VM данного узла обращаются, находятся нелокально, а на дисках соседней ноды, то логика NDFS постарается их переместить, что в нашем случае совсем не нужно, ведь к эталонному образу постоянно обращаются множество VM с разных нод.

Вообразите себе, что у нас есть десяток нодов, по 30-50 VM с включенным режимом Linked Clones на каждой, использующих один эталонный образ VMDK, расположенный локально только для одной ноды, и по сети, с неизбежным результатом в виде падения latency, для других.

Проблема в том, что сама vSphere никак не сообщает о таком режиме (в виде файла-эталона и множества «дельт») наружу не сообщает, из добрых побуждений, для упрощения работы с «классическими» стораджами, и обеспечивая «прозрачность» на уровне VM.
Процедура загрузки при этом, например, порождает сильный boot storm, когда множество загружающихся на разных узлах виртуальных десктопов пойдут ломиться по сети в эталонному образу на одной ноде, неизбежно и безнадежно ее перегружая сетевым трафиком, не спасают никакие кэши на SSD.

По этой причине, Nutanix пришлось придумать способ с этой ситуацией справляться.
Использован простой и не лишенный изящества способ.

NDFS следит за характером доступа, и если обнаруживает, что на узле есть некий файл, из которого исключительно читают, но никогда не пишут (эталонный файл-образ), причем к такому файлу доступ регулярно происходит по сети, с разных узлов кластера, то она считает, что этот файл — это тот самый эталонный образ виртуального десктопа, и его можно заснэпшотить, и затем раскопировать по кластерным нодам, и потом перемаршрутизировать доступ так, чтобы обращение на чтение для ноды шло к такой локальной для нее «теневой копии».

Если вдруг NDFS обнаруживает, что в файл была осуществлена запись (например если мы вдруг изменили эталонный образ, обновили версию программы, антивирусных баз или пропатчили OS), то теневые копии инвалидируются, и затем, если к этому vdisk вновь наблюдается такой характер доступа, как описан выше, процедура по созданию и раскидыванию «теневых копий» по локальным дискам нод повторяется.

Данная фича отключена по умолчанию, и должна быть включена вручную в случаях, если ваша VDI-система использует Linked Clones. Для этого используется изменение параметра gflag stargate_admctl_shadow_vdisk_support_enabled в значение true

Такой «теневой» vdisk имеет специальный способ именования
NFS:{inode_id}#{base vdisk id}@{controller vm id}

Исходный vdisk-образ будет иметь в свойствах поле shadow_read_requests со значением true
vdisk_id: 537628
vdisk_name: "NFS:537628”
nfs_file_name: "base2”
shadow_read_requests: true

Теневая копия будет иметь следующие свойства (обратите, как vdisk_name ссылается на оригинальный vdisk) Параметр mutability state для теневой копии устанавливается в значение kImmutableShadow в конфиге
vdisk_id: 568747
vdisk_name: "NFS:537628#537628@7"
parent_vdisk_id: 537628
mutability_state: kImmutableShadow
nfs_file_name: "base2"

Nutanix и режим Linked Clones в VMware: 2 комментария

  1. comotoza

    gflags в целом не рекомендуют редактировать до вмешательства инженеров Nutanix
    в новых версиях сделали попроще — включить функционал на уровне кластера, далее он сам поймет машины к котором идет только обращение на чтение, после 100 чтений пометит vdisk для работы shadow vm, при различных операциях типа recompose при пересобирании новой реплики убивает старые shadow vm (идет запись) и делает все по новой

    If the write request comes to these disks, then this feature is disabled for the vdisk.
    — verify that VMs are provisioned using linked clone.
    -verify using ncli cluster version, that cluster is running 3.5.2 ( do not apply on versions
    lower than 3.5.2)
    — ncli command was introduced in 3.5.2 to enable shadow vdisk per container basis.
    ( which will modify zookeeper database instead of gflags)

    ncli cluster edit-params enable-shadow-clones=true

  2. Уведомление: X vs. Y: VSAN 6.0. Что нового? - Virtualization solution with a nuts

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *