Порівняння 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.