Сравнение на VMDK Thick Provision Lazy-Zeroed и Eager-Zeroed, Thin Provision WindowsPro
Ако създадете нов виртуален твърд диск под VMware ESXi, можете да избирате между три различни варианта. Това, което на пръв поглед изглежда като решение между тънка и дебела подготовка, става много по-сложно, когато влезе в действие споделеното хранилище.
Основната грижа при осигуряването на място за съхранение във виртуална среда е, че приложенията трябва да консумират само толкова ресурси за съхранение, колкото всъщност се нуждаят. Несъответствия могат да възникнат, например, когато софтуерът очаква определено дисково пространство, когато е инсталиран, но след това се справя с по-малко по време на работа.
Тънка провизия от хипервизора
Очевидният отговор на този проблем изглежда е VMDK с тънко осигуряване. Те не запазват място за съхранение, когато са създадени, но нарастват с количеството данни, които гост операционната система съхранява в тях. Всъщност те са интересна опция за системи за съхранение, които не предлагат тънка провизия, като локални към локални дискове.
Недостатъкът на този тип VMDK е, че трябва постоянно да наблюдавате капацитета за съхранение, така че свръхбукирането на ресурси да не доведе до пълни дискове и произтичащите от това тесни места. Освен това производителността на такива VMDK е малко по-лоша от тази на дебелите варианти.
Лесно разпределение на паметта чрез бекенда за съхранение
Ако използвате масиви за съхранение, ще използвате опцията за бедно разпределение на съхранение на ниво LUN. Тънката подготовка тогава засяга не само отделни VMDK, но и цели хранилища на ESXi. От чисто техническа гледна точка там могат да се създават и VMDK от типа Thin Provision, но няма много смисъл да се приемат два пъти управленските усилия без очевидни предимства.
Ако прехвърлите тънката провизия към бекенда за съхранение, обикновено се използват VMDK от дебел нулиран мързелив тип. Въпреки че запазват цялото пространство за съхранение на томовете на VMFS, те се държат по подобен начин като тънките VMDK на масиви за съхранение с постно разпределение на съхранението, защото там използват блокове само когато системата за гости съхранява данни.
Дебела резервация, нула за нуждите за най-добро представяне
От друга страна, виртуалните дискове от тип дебела нулировка с нулево нулиране сами по себе си не са подходящи за тънко осигуряване, тъй като те не само запазват дисковото пространство, предназначено за тях, когато са създадени, но и презаписват всички блокове с нули. Ако този процес може да бъде възложен на масив чрез команда VAAI, тогава предоставянето едва ли ще отнеме повече време, отколкото при мързеливи нули. Но този VMDK предлага най-доброто представяне след това.
Ясни връзки на прости системи за съхранение
В системите за съхранение, които не могат сами да хостват тънки дискове, опциите VMDK са относително ясни. Тънката провизия може да се извърши само чрез хипервизора и при дебела провизия е важно да се прецени дали се предпочита по-кратко време за провизиране (мързеливо-нулирано) пред малко по-добра производителност (нетърпеливо нулирано).
Проблем с рекултивацията на мъртвото пространство
За масиви за съхранение, които могат да осигурят тънко осигуряване на хранилища за данни, производителите на системите за съхранение обикновено препоръчват използването на дебели VMDK от мързеливо нулевия тип.
Проблем с това съзвездие беше така нареченото възстановяване на мъртво пространство до vSphere 5, тъй като системата за съхранение не беше информирана, ако например VMDK беше мигриран към друга система с помощта на Storage vMotion и следователно вече не беше необходим. Следователно не може да освободи мястото, заето от VMDK.