1. Попередній сайзінг - запорука успіху
2. Особливості настройки віртуальних машин
3. Нюанси роботи з Hot Add
4. Особливості Scale UP, Scale OUT-підходу
5. управління пам'яттю
6. висновок

гостьовий пост компанії ІТ-ГРАД . Перехід в хмару - актуальне завдання, з якою сьогодні стикаються багато компаній. Віртуалізувати парк локальних серверів і перенісши на хмарну майданчик додатки, організація позбавляється від ряду проблем, з якими доводилося стикатися раніше. Однак правильність конфігурації віртуального середовища, зокрема віртуальних машин, залишається питанням номер один. На що звернути увагу при роботі з ВМ, як створити максимально продуктивну інфраструктуру і не допустити помилок - розповімо в цій статті.

Попередній сайзінг - запорука успіху

Перед тим як приступити до розгортання ВМ в хмарі провайдера , Необхідно визначити хоча б її приблизний розмір. При цьому важливо розуміти, що не завжди більше ресурсів означає більше продуктивності. До того ж, якщо компанія стикається з питанням міграції вже існуючих додатків, слід проаналізувати дані моніторингу. Це дозволить визначити, які ресурси вимагає ВМ і в якому обсязі.

Перенесення додатків в хмару провайдера

При перенесенні програми з локальної інфраструктури в хмарну переконайтеся в коректності роботи програмного забезпечення. Тобто додаток, яке тепер знаходиться всередині ВМ, необхідно протестувати. Якщо це великоваговий софт, ще на початковому етапі рекомендують дотримуватися такої методики: запустити ВМ на одному ESXi-сервері, зарезервувавши при цьому ресурси процесора і пам'яті. Після чого почати тестування на визначення продуктивності та працездатності, а отримані результати занести в baseline. Додатково оцінюється, як додаток працює на певній архітектурі в умовах відсутності робочих навантажень.

Після того як статистика по ВМ і додатків зібрана, створюються умови, наближені до робочих: до хосту додають кілька додаткових віртуальних машин, формуючи додаткову навантаження. При цьому кожна ВМ використовує виділені під неї ресурси процесора і пам'яті. Тепер, коли навантаження зросло, знову запускають тест продуктивності і порівнюють отримані результати з уже наявними baseline. На цьому етапі важливо зрозуміти, знижуються чи показники продуктивності і наскільки. Якщо в умовах збільшеного навантаження додатки працюють штатно, а продуктивність хоч і впала, але є достатньою для функціонування сервісів, можна продовжувати збільшувати кількість ВМ. Але робити це необхідно уважно, постійно відстежуючи розподіл ресурсів.

Особливості настройки віртуальних машин

Під час налаштування віртуальних машин в середовищі VMware слід звертати увагу на такий параметр, як кількість віртуальних процесорів. Бажано, щоб цей показник був не більший 8. Також важливо розуміти, що, якщо віртуальна машина використовує більше ядер і більше пам'яті, ніж припадає на один процесор, відбувається звернення до пам'яті іншого CPU, в результаті чого знижується продуктивність, оскільки такий процес виконується повільно . Це пов'язано з архітектурою нерівномірного доступу до пам'яті, або NUMA.

NUMA-архітектура. Відзначимо, що більшість сучасних процесорів відносяться до представників NUMA-архітектури, де у кожного CPU існує власна локальна пам'ять. При цьому CPU і RAM в сукупності об'єднуються в NUMA-вузол. Таким чином, ОС віртуальної машини використовує локальну пам'ять процесора і в разі її браку звертається до віддаленої пам'яті іншого NUMA-вузла. Важливо розуміти, що доступ до локальної RAM здійснюється швидше, ніж до віддаленої.

Сценарій, за якого віртуальна машина асоціюється з однією фізичною NUMA-вузлом і використовує локальну пам'ять, є ідеальним. Але якщо виникає необхідність створити ВМ, фізично перевищує розмір NUMA-вузла, варто звернути увагу на відповідність фізичної NUMA і віртуальної. Також корисно використовувати параметр cores per socket. Надаючи віртуальній машині кілька віртуальних процесорів, можна визначити варіанти їх відображення всередині ВМ: як один CPU з великою кількістю ядер, кілька одноядерних процесорів або інші комбінації.

Якщо віртуальна машина цілком поміщається на фізичний NUMA-вузол, cores per socket не впливає на продуктивність. Якщо ж програма має обмеження за кількістю процесорів, слід використовувати цю метрику, щоб ПО зверталося до доступним CPU.

Для наочності розглянемо приклад, в якому компанія переносить базу даних SQL Server 2012 версії Standard в хмара по моделі IaaS . Така БД має обмеження на використання процесорних сокетів, за замовчуванням рівне 4. Отже, якщо ВМ необхідно 32 віртуальних процесора або 32 потоку виконання, можна використовувати комбінацію з 4 гнізд з 8 ядрами.

Нюанси роботи з Hot Add

Що робити, якщо ресурсів віртуальної машини в якийсь момент стає недостатньо, а зупиняти роботу додатків або ВМ не представляється можливим? На допомогу приходить опція Hot Add, яка дозволяє на льоту додавати ресурси процесора і пам'яті. При цьому важливо розуміти, що Hot Add для процесора, іменований в налаштуваннях ВМ як Hot Plug, призводить до відключення vNUMA.

Опція CPU Hot Add

Отже, машині з активованою опцією CPU Hot Add не буде видно поділу NUMA-вузлів, а вільну пам'ять ОС буде розцінювати як єдине плоске простір. Слід мати на увазі, що такий сценарій підходить далеко не для всіх додатків. Тому Hot Add по процесору не завжди вигідно використовувати.

Особливості Scale UP, Scale OUT-підходу

При переході на віртуальну майданчик більшість компаній йде по шляху найменшого опору: з одного ресурсоемкого фізичного хоста, на якому, наприклад, знаходилася велика кількість баз даних, переносять вміст, розміщуючи БД в межах однієї віртуальної машини. І в разі, якщо потрібно наростити ресурси, адміністратор додає до існуючої ВМ додаткові обчислювальні потужності: збільшує обсяг пам'яті і кількість процесорів. Такий механізм є варіантом вертикального масштабування, або Scale UP, про що докладніше розповідалося в статті Віртуальний ЦОД .

У випадку зі Scale OUT, або горизонтальним масштабуванням, в інфраструктуру додаються нові ресурси, наприклад збільшують кількість віртуальних машин в складі кластера. Отже, плюс озвученого підходу полягає в тому, що при виході будь-якої одиниці з ладу це не впливає на цілісність інфраструктури.

управління пам'яттю

Під час налаштування пам'яті і розподілі обсягу між віртуальними машинами не забувайте про фізичний хост. Крім RAM, яку використовують ВМ, фізичний вузол також має потребу в ресурсах. Тому для сервера виділяють кілька додаткових гігабайт, а при створенні віртуальних машин цей об'єм не задіють.

Приклад того, як не варто використовувати RAM. На фізичному вузлі з пам'яттю в 120 Гб і двома процесорами по 8 ядер вирішили розгорнути чотири ВМ, кожна з яких використовує 32 Гб RAM і 8 ядер CPU. У такому сценарії сукупний обсяг пам'яті, необхідний для віртуальних машин, перевищує доступні розміри хоста. На практиці розглянутий підхід краще не використовувати. І хоча на VMware ESXi така конфігурація запуститься, продуктивність при цьому буде далека від оптимальної. Тому перш ніж створювати віртуальні машини, визначитеся з об'ємом пам'яті, який необхідно виділити для хоста.

висновок

Приділяючи увагу особливостям налаштування віртуальних машин в IaaS-хмарі сервіс-провайдера , Пам'ятайте: від обраної стратегії залежить кінцевий результат. Оскільки вимоги до інфраструктури різних компаній можуть сильно відрізнятися, слід використовувати максимально наближений до вимог організації варіант конфігурації.

Посилання на статтю в блозі ІТ-ГРАД.