Тож справді, що таке надмірність віртуалізації і коли я повинен турбуватися?

Я шукаю хороших правил, щоб зрозуміти, коли НЕ віртуалізувати машину.

Наприклад, я знаю, що повністю пов'язаний з процесором процес з майже 100% -ою ефективністю, ймовірно, не є гарною ідеєю для віртуалізації, але чи є сенс виконувати щось, що використовує процесор більшу частину часу "значну кількість" (скажімо, 40 або 50%)?

Інший приклад: якщо я віртуалізую 1000 машин, навіть якщо вони використовуються лише з легким або помірним рівнем використання, можливо, було б погано запустити це на хості з лише 4 ядрами.

Чи може хтось узагальнити підказки щодо віртуалізації на основі завантаженості машини чи великої кількості гостьових машин у порівнянні з ресурсами хоста?

Я зазвичай віртуалізую на хостах Windows за допомогою VirtualBox або VMWare, але я припускаю, що це досить загальне питання.

Дискова підсистема. Зазвичай це найменш доступний ресурс. Пам'ять, звичайно, але це одне.

Обмеження дискової підсистеми працює обома способами. Якщо в системі використовується багато дискового вводу / виводу, інші гості сповільнюються. Якщо цей гість у виробництві, він, швидше за все, потребує швидкого реагування на веб-запити. Це може бути дуже неприємно, а також великою причиною, чому не орендувати віртуальне обладнання. Ви можете мінімізувати цю проблему, використовуючи спеціальні диски.

Використовуючи в гостях лише 512 Мб пам'яті, розміщується весь кеш диска на хості. І це не однаково розділено між гостями.

Не турбуйтеся про IO CPU. Таким чином віртуалізація є дуже ефективною, часто пов'язаною, як лише декілька процесів, що працюють в одній системі. Я рідко бачу мульти-ксеонні системи, що працюють на 100% на процесорі.

редагувати: друкарські помилки

Речі, які я ніколи не помістив би в машині:

• Все, що використовує конкретне обладнання, яке неможливо віртуалізувати: зазвичай графіка, досить багато апаратних модулів захисту, все, що стосується індивідуальних драйверів (наприклад, мережеві драйвери, наприклад).

• Системи з видачею ліцензій. Деякі плати за програмне забезпечення на фізичний процесор або ядро, незалежно від того, скільки ви виділили для VM. Ви б потрапили під час аудиту, якби у вас було ліцензійне програмне забезпечення для одного ядра, що працює в VM на 32-ядерному сервері.

Речі, які я б перешкоджала введенню в VM:

• Програмне забезпечення, яке вже докладає зусиль для використання всіх ресурсів товарного обладнання. Машини, що працюють як частина "великих даних" зусиль, як hadoop, як правило, розроблені для роботи на голому металі.

• Все, що буде тонко налаштоване, щоб використовувати ресурси. Коли ви дійсно починаєте налаштовувати базу даних, VM, які претендують на ресурси, дійсно збираються запустити ключ.

• Все, що вже має велике вузьке місце. Вона вже не грає добре з собою, швидше за все, не буде грати добре з іншими.

Є кілька речей, які є досить приголомшливими для розміщення в машинах віртуального управління:

• Все, що витрачає досить багато часу на простої. Хости комунальних служб, такі як пошта та DNS, важко сформували достатньо навантаження на сучасне обладнання, щоб гарантувати спеціальні сервери.

• Програми, які самостійно не змінюють масштаб (або легко). Спадковий код досить часто потрапляє до цієї категорії. Якщо додаток не розшириться, щоб зайняти сервер, використовуйте безліч віртуальних серверів.

• Проекти / програми, які починаються невеликими, але зростають. Набагато простіше додавати ресурси до VM (а також переходити на новіші, більші апаратні засоби), на відміну від запуску на голий метал.

Крім того, я не впевнений, чи перебільшуєте ви розміщення величезної кількості VM на одному хості, але якщо ви намагаєтесь отримати велике співвідношення VM: HW, ви можете замість цього розглянути ESX, Xen, KVM. Ви проїдете набагато краще, ніж використовувати VMware або virtualbox в Windows.

Є два моменти на ефективність віртуалізації.

• спільне вузьке місце
• емуляція

На загальних вузьких місцях, хто ще на тому ж залізі? Якщо ви знаходитесь у віртуалізованому середовищі, ви дуже залежні від того, щоб партнер хостингу був чесним з вами.

Я думаю, що головне питання для ефективності роботи (особливо інтерактивності) - це частини емуляції системи віртуалізації. Це відрізняється залежно від налаштування. Диск та мережа - типові кандидати. Як правило, емуляція подвоює "вартість" виконання дії, тому будь-який час затримки апаратного забезпечення слід вважати подвоєним, а будь-яке число наповнення повинно бути вдвічі меншим.

Зрештою, будь-яке навантаження високої продуктивності не повинно бути віртуалізованим. Навички виртуалізації у виконанні нетривіальні. Результати моїх тестів дивіться тут:

http://www.altechnative.net/2012/08/04/virtual-performance-part-1-vmware/

ОТОХ, якщо ви хочете об'єднати ряд машин, які весь час простоюють, віртуалізація - це шлях вперед.

Гарна відповідь від anttiR.

Крім того, критичні за часом системи. Я просто з'ясував, що гниль за розміром Hyper-V (vm повільно відстає; всі сучасні ОС в vm роблять це, часто переставляють) не грає добре з деякими критичними додатками, які я розробляю. Крім того, я збираюся використовувати там багато процесора, і я планую отримати 12-ядерну машину саме для цієї програми у виробництві.