Віртуалізація має великі переваги, але бувають випадки, коли віртуалізований сервер потребує більшої продуктивності і його слід перенести на фізичний.
Моє запитання: як ти скажеш, коли ці часи? Я шукаю вимірювані дані та показники, які показують, що переміщення сервера до його власного фізичного поля може суттєво змінити продуктивність. Мене особисто цікавить Windows, але, мабуть, основні речі однакові на всіх платформах.
Відповіді:
Один з випадків, коли мені довелося здійснити V2P, був для скриньки MS SQL, яка працювала на двоядерному процесорі 3,2 ГГц (загальний процесор 14,4 ГГц), який ми перенесли на кластер ESX 2.5, де базове обладнання було новішим і більше повільніші ядра (2,4 ГГц IIRC). Якщо додати в ~ 10% накладні витрати навіть при 4 vCPU, цей VM міг отримати лише ефективний загальний процесор 8-8,5 ГГц. 60% пік процесора до міграції став 90-100% після міграції, клієнт захотів простір, щоб ми повернулися до фізичного. Щоб відповісти на ваше запитання конкретно, ми побачили, що коробка працює на 100% процесора по всій платі в Perfmon та у клієнта VI. Кращим рішенням (на мій погляд) було б оновлення до більш швидкого процесора, але є такі кращі випадки, коли це не економічно, особливо з тенденцією до уповільнення процесора '
За допомогою ESX 4 ми можемо зіткнутися з таким вікном до 8 vCPU, але на той момент це було не так.
Що стосується пошуку меж продуктивності, які можуть вказувати на те, що вам потрібно відмовитися від свого віртуального комп'ютера, а потім із гостем Windows на середовищі VMWare, тоді поєднання Perfmon та VI-клієнта повинно бути більш ніж завданням пошуку будь-яких віртуальних машин, які продуктивністю обмежені самі . Додайте до аналітики SAN, якщо ви можете, але якщо SAN виявить проблему, ви майже напевно будете переробляти сховище, щоб виділити та \ або посилити обсяги, на яких зберігаються віртуальні диски VM. Те саме стосується будь-якої іншої комбінації ОС \ Hypervisor - отримуйте будь-яку внутрішню статистику, але ви можете співвіднести їх з поглядом Hypervisor про те, що відбувається, тому що 100% процесора, який повідомляється у VM (наприклад), не обов'язково означає, що Hypervisor ніколи не може доставити більше продуктивності,
Я не погоджуюся з тим, що віртуальний сервер потрібно перенести на фізичний через продуктивність. Гіпервізори зараз настільки близькі до металу, що практично не (удар призначений) практично не вдарило. Особливо зараз, коли багато виробників плат включають гіпервізори на чіпсеті. Якби ви взяли два сервери з однаковим обладнанням, один запускав одного гостя і один працював з точною копією цього гостя на фізичному обладнанні, вам важко буде помітити різницю в продуктивності, я думаю.
Є й інші причини, хоча вам може знадобитися фізичний сервер, а не віртуальний. Один з них - сумісність обладнання. Якщо ваша програма вимагає нестандартного обладнання з власною унікальною шиною, можливо, ви не зможете запустити це у віртуальній машині.
Мені хочеться почути, що мають сказати інші. Чудове запитання.
ПРИМІТКА. У нас є віртуалізовані сервери, а потім поставлені на одне і те ж обладнання лише для того, щоб ми любили знімок / vmotion.
Я не фахівець з цього питання, але в цілому кажучи: дуже голодні програми вводу / виводу (особливо ті, хто пише мало і швидко) - це ті, хто отримує власний фізичний сервер.
Їх теж не важко знайти, ви просто запускаєте монітор продуктивності та шукаєте високі час очікування вводу / виводу.
Крім того, бази даних високого класу зазвичай отримують власний виділений сервер із кількох причин:
Це дуже залежить від послуги, яку вона виконує.
Я, як правило, переглядаю ресурси, які використовуються, і визначаю, чи справді вони є недорогими для цього гостя та послугами, які він надає.
Це так:
Якщо у вас є двоядерний (2vSMP), гість 4 Гб оперативної пам’яті, який працює на веб-сервері (IIS), і ви не збільшуєте запити процесора та оперативної пам’яті, то, можливо, гостю не потрібно більше обладнання.
Ми натрапили на випадки, коли запуск бази даних Oracle на платформі віртуалізації наближається до такої ж продуктивності, що і апаратний сервер аналогічного розміру.
Очевидно, що якщо ви хотіли мати 16-ядерний сервер як віртуальний комп'ютер, у вас можуть виникнути проблеми з його виконанням, а також з виділеним обладнанням.
Коли ВМ голодують за ресурси (або, можливо, голодують інші ВМ за ресурси), наприклад:
Я б сказав, що коли сервер знаходиться в точці, коли він споживає достатньо ресурсів сервера, що він не може спільно використовувати обладнання.
ESX, ESXi та Window Hyper V мають забезпечити реальні показники. Тому поки одна з машин не використовує 90% ресурсів самостійно, вам не потрібно переходити до реального обладнання.
Винятком є те, що ви не хочете, щоб такі речі, як ваші 2 контролери домену в одному полі, якщо апаратне забезпечення вийшло з ладу.
Я сумніваюся, що на це є загальна відповідь, але якщо ви переживаєте за виступ, то це те, що ви повинні дивитись. Очевидним було б перевірити, чи ви збільшили CPU, I / O, ...
Але також тестування продуктивності та орієнтири також допоможуть вам вирішити, чи є певна кара за віртуальний вигляд та чи розумне наявність єдиного VM на хості.
Спочатку потрібно визначити, який ресурс є вузьким місцем.
Монітор продуктивності Windows ( perfmon ) пропонує безліч лічильників для різних аспектів, таких як черга диска, статистика віртуальної пам'яті тощо.
Якщо ви пов'язані з диском, надання прямому доступу віртуальної машини до диска замість чогось на зразок файлу vmx з VMWare може допомогти дуже багато.
Я думаю, що все залежить від двох факторів:
тільки мої 2cts.