Я припускаю, що ви збираєтеся віртуалізувати сервери, а не настільні комп’ютери, все в порядку? Далі я припускаю, що ви будете використовувати кілька серверів ESX / ESXi для доступу до вашої пам’яті та керувати ними vCenter Server.
Приймаючи рішення про розмір LUN та кількість VMFS, ви врівноважуєте декілька факторів: продуктивність, гнучкість конфігурації та використання ресурсів, при цьому пов'язані підтримувані максимальні налаштування вашої інфраструктури.
Ви можете отримати найкращі показники за допомогою відображення від 1 ВМ до 1 LUN / VMFS. Немає конкуренції між машинами на одній і тій же VMFS, немає блокуючих суперечок, кожне навантаження розділене і все є goood. Проблема полягає в тому, що ви збираєтеся керувати нечестивою кількістю LUN, можете потрапити на підтримувані максимальні межі, зіткнетесь з головними болями зі зміною розміру та міграцією VMFS, недовикористаними ресурсами (цей єдиний відсотковий вільний простір у VMFS додається) і взагалі створюєте те, що не приємно керувати.
Інша крайність - один великий VMFS, призначений для розміщення всього. Ви отримаєте найкраще використання ресурсів таким чином, не буде жодної проблеми з вирішенням того, що робити, де розгортатись, і проблеми, коли VMFS X є гарячою точкою, а VMFS Y простоює. Витрати становлять сукупні показники. Чому? Через блокування. Коли один ESX пише в заданий VMFS, інші блокуються на час, необхідний для завершення вводу-виводу та повинні повторити спробу. Це коштує продуктивності. Поза межами ігрового майданчика / тесту та середовищ розробки неправильний підхід до конфігурації сховища.
Загальноприйнята практика полягає у створенні сховищ даних досить великих розмірів для розміщення кількох віртуальних машин та розділення наявного місця для зберігання на шматки відповідного розміру. Яка кількість ВМ залежить від віртуальних машин. Можливо, ви хочете отримати одну або декілька критичних виробничих баз даних на VMFS, але дозволити три-чотири десятки машин для тестування та розробки на одній сховищі даних. Кількість VM в сховищі даних також залежить від вашого обладнання (розмір диска, об / хв, кеш-пам'ять контролерів тощо) та моделей доступу (для будь-якого рівня продуктивності ви можете розміщувати набагато більше веб-серверів на тому ж VMFS, ніж поштові сервери).
Менші сховища даних мають ще одну перевагу: вони заважають фізично забивати занадто багато віртуальних машин на сховищі даних. Жоден об'єм тиску управління не помістить зайвий терабайт віртуальних дисків на пів-терабайт-накопичувачі (принаймні, доки вони не почують про тонке забезпечення та дедуплікацію).
Ще одне: при створенні цих сховищ даних стандартизуйте на розмір одного блоку. Це спрощує багато чого пізніше, коли ви хочете зробити щось у сховищах даних і побачити некрасиві помилки "не сумісні".
Оновлення : DS3k матиме активні / пасивні контролери (тобто будь-який даний LUN може обслуговуватися або контролером A, або B; доступ до LUN через невласний контролер несе штрафну ефективність), тож виплатити буде мати рівну кількість LUN , рівномірно розподілений між контролерами.
Я міг би уявити, починаючи з 15 ВМ / LUN з простором до 20 або більше.