Сайзінг і планування

У цьому розділі мені б хотілося позначити деякі питання сайзінга апаратного забезпечення під vSphere Питання виду «який сервер вибрати під улюблений гіпервізор» – один з популярних і найбільш дратівливих – Тому що таке формулювання питання некоректна

Те, що написано далі, ні в якій мірі не «Повне і абсолютне керівництво з підбору обладнання завжди», немає Це трохи теорії про те, що таке продуктивність, – як показує мій пятирічний досвід ведення ІТ-курсів, навіть у найдосвідченіших людей бувають прогалини в звичайних для когось іншого речах Це невеликі нюанси вибору обладнання, повязані саме з віртуалізацією Це питання, на які не можна давати відповідь абстрактно, але про які варто задуматися, маючи на руках дані конкретного випадку

Отже – нам потрібно обладнання під ESX (i) Що далі

Найголовніше для розуміння, нехай і очевидне до неможливості, – це таке міркування:

Кількість ресурсів, якими повинен володіти сервер під ESX (i), залежить від суми вимог для виконання всіх завдань, які ми збираємося виконувати в ВМ на цьому сервері І ще від того, чи будемо ми використовувати деякі функції vSphere (в першу чергу HA / FT), так як ці функції вимагають ресурсів понад необхідні для роботи ВМ

Поговоримо про всі підсистеми – процесор, память, диски, мережу Найбільша і складна тема – це дискова підсистема Чи повинна вона бути представлена ​​системою зберігання даних (СГД) або обійдемося локальними дисками сервера –

це питання відносно простий Є бюджет на СГД – вона нам потрібна ☺ На немає і суду немає Яку саме СГД використовувати – чи буде це система з підключенням з оптики, Fibre Channel SAN Або досить буде 1 Гбіт підключення Ethernet і це буде iSCSI SAN Або це буде iSCSI, але з 10 Гбіт підключенням Або NFS Варіантів маса Які диски там будуть стояти Або варто задуматися не про диски, а про SSD-накопичувачах

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

Для вже існуючої інфраструктури статистику використання тієї чи іншої підсистеми має сенс отримувати за допомогою відповідних засобів моніторингу Мені відомо рішення від Майкрософт – System Center Operations Manager (OpsMgr, SCOM)

Ну а найбільш правильно і зручно використовувати спеціалізоване засіб аналізу інфраструктури для її віртуалізації – VMware Capacity Planner Послуги з обстеження з його допомогою надають компанії-партнери VMware

Для планованих систем цифри по передбачуваного навантаження беруться з тих же джерел, що і при сайзінге фізичних серверів, – з відповідної документації, навантажувальних тестів і досвіду

Мені бачаться два моменти, повязаних з вибором процесорів в сервер під ESX (i)

Перший – який продуктивністю вони повинні володіти, і другий – накладаються чи на процесори якісь умови з точки зору деяких функцій vSphere

Про продуктивність поговоримо трохи пізніше, зараз про функціонал

Процесор – це єдиний компонент сервера, яка не віртуалізується Це означає, що гостьова ОС бачить тактову частоту і, найголовніше, набори інструкцій (типу SSE4 і т п) фізичної процесора Якщо ВМ просто і без затій працює на якомусь ESX-сервері, то від такого стану речей нам ні холодно, ні жарко Проблеми починаються, якщо ми хочемо здійснити живу міграцію (ту, що у VMware називає vMotion) цієї ВМ на другий ESX (i)

Висновок: якщо ми припускаємо використання vMotion, то ЦП на цих серверах повинні бути однаковими Розкриємо нюанси

«Подібність» тут має бути за функціями цих процесорів Наприклад, набір інструкцій SSE 42 – якщо їх підтримує ЦП сервера, то наявність цих інструкцій побачить і гостьова ОС Якщо на ЦП іншого сервера цих инструк ций не буде, а ми Мігруємо включену ВМ на цей сервер, то гостьова ОС надзвичайно здивується неможливості використовувати те, що тільки що було до-

ступні І може померти, сама ОС або програму Щоб такого не було, vCenter в принципі не дасть нам мігрувати ВМ між серверами з різними ЦП

Резюме: не важливі тактова частота, розмір кеш-памяті і кількість ядер Важливі підтримувані функції, тобто покоління ЦП, версія прошивки і (важливо) настройки BIOS Деякі функції можуть включатися / вимикатися з BIOS, тому начебто однакові ЦП можуть виявитися несумісними з точки зору vMotion До речі кажучи, не завжди легко знайти відмінності в налаштуванні У моїй практиці в таких ситуаціях допомагав скидання налаштувань BIOS на значення за замовчуванням

Далі Забудьте попередній абзац ☺

Ще в ESX 35 Update 2 і тим більше у версії 4 VMware реалізувала і пропонує нам функцію EVC – Enhanced vMotion Compatibility Суть цієї функції – в тому, що ми можемо «привести до єдиного знаменника» різні ЦП на групі серверів Наприклад, у нас є сервери з ЦП поновее – підтримуючі набори інструкцій до SSE 42 І є сервери з ЦП постарше, що підтримують набір інструкцій SSE 4 Якщо ми обєднаємо дві ці групи серверів і включимо для них EVC, то більш нові ЦП вимкнуть у себе SSE 42 І всі ці сервери (їх ЦП) стануть сумісні для vMotion

Проте для роботи EVC потрібно, щоб всі процесори підтримували технологію «AMD-V Extended Migration» або «Intel VT FlexMigration» Це:

Q для AMD: процесори Opteron ™ починаючи з моделей Rev E / F

Q для Intel: починаючи з Core ™ 2 (Merom)

Детальну інформацію про моделі можна почерпнути або в списку сумісності, або у статті бази знань http://kbvmwarecom/kb/1003212

Резюме: якщо ми набуваємо процесори з підтримкою цієї технології, то ми можемо не хвилюватися – сумісність для vMotion буде забезпечена Ціною цього буде недоступність частини нових функцій в нових ЦП Як правило, це більш ніж допустима жертва

Треба розуміти, що vMotion між серверами з процесорами різних виробників (c AMD на Intel і назад) неможливий ні за яких умов

Спробую резюмувати

1 Якщо ви вибираєте процесори в сервер під ESX, припускаєте вико вання живої міграції aka vMotion і

• це будуть перші ESX (i) сервери вашої інфраструктури – то вибирати можна досить вільно (див ще міркування з продуктивності) Якщо в середньостроковій перспективі планується докуповувати ще сервери, то краще зараз вибирати процесори поновее (з останньої групи сумісності EVC), щоб в майбутніх серверах ще були доступні до замовлення такі ж (або представники тієї ж групи)

• у вас вже є кілька ESX (i)-серверів, до них треба докупити ще

Процесори з підтримкою EVC можна використовувати в одному «кластері EVC» з процесорами, що не підтримують Extended Migration / FlexMigration У такому випадку процесори без підтримки EVC повинні бути однакові між собою

2 Якщо vMotion НЕ передбачається до використання, то звертати увагу потрібно лише на міркування продуктивності Однак у силу того, що на момент написання у VMware залишилися тільки дві редакції vSphere, що не включають vMotion, – Free і Essentials, краще виходити з можливого включення vMotion в майбутньому

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

можливість є непідтримуваної Вас цікавить настройкаOptions

CPUID Mask Advanced Нарешті, можна просто відключити перевірку совме-

Стімость ЦП на рівні налаштувань vCenter Докладніше дивіться у відповідному розділі – про vMotion

Друга після vMotion функція, яка має власні вимогами до процесорів, – це VMware Fault Tolerance, FT

Для серверів, на яких працює VMware Fault Tolerance, повинні виконуватися всі умови для vMotion Плюс до того тактові частоти процесорів на різних серверах не повинні відрізнятися більш ніж на 300 МГц Нарешті, ця функція працює тільки на процесорах зі списку:

Q  Intel 31xx, 33xx, 34xx, 35xx, 36xx, 52xx, 54xx, 55xx, 56xx, 65xx, 74xx, 75xx

Q  AMD 13xx, 23xx, 41xx, 61xx, 83xx

Актуальну інформацію про моделі процесорів для FT шукайте у статті бази знань VMware № 1008027 (http://kbvmwarecom/kb/1008027)

На продуктивність процесорної підсистеми впливають:

1) кількість ядер (ну і самих процесорів, само собою)

2) їх тактова частота

3) розмір кеш-памяті

4) підтримувані інструкції

В ідеалі ми купуємо самий новий процесор (з максимумом підтримуваних інструкцій), з максимальним розміром кеша, максимальними тактовою частотою і кількістю ядер У реальності ж це не завжди можливо, та й не завжди виправдано

Найефективніше у загальному випадку – використовувати менше процесорних сокетів і більше ядер, з тих міркувань, що ESX (i) ліцензується на процесори Отримаємо більш ефективне співвідношення ціни і продуктивності Але не забуваємо про те, що ESXi з безкоштовною ліцензією запрацює на сервері не більше ніж з двома процесорами, і для всіх ліцензій, крім Advanced і Enterprise Plus, можливе використання процесорів не більше ніж з шістьма ядрами (інформація вірна на момент написання)

Ще один нюанс: один віртуальний процесор дорівнює одному ядру фізично-

го сервера як максимум Не можна взяти два фізичних ядра і обєднати в одне

віртуальне, можна тільки «поділити» одну фізичну на кілька віртуаль них Тому чим більшою частотою будуть володіти вибрані вами процесори, тим більшою максимальною продуктивністю буде володіти один віртуаль ний процесор

Останнє, на мою думку, менш критично

Процесор виконує інструкції Ці інструкції виконуються з тим чи іншим пріоритетом, який традиційно називається «кільцем» (ring) Кільце 0 має найбільший пріоритет, і саме в цьому кільці працює ядро ОС, що управляє всіма ресурсами

Але У разі використання віртуалізації ОС декілька, і ресурсами сервера повинен управляти гіпервізор, розподіляючи ці ресурси між ОС в ВМ Виходів декілька:

Q в ESX (i) реалізована технологія під назвою «Binary translation» – про-

програмний механізм «витіснення» ядра гостьової ОС з нульового кільця ESX (i) на льоту підміняє інструкції процесора таким чином, що працюють вони на рівні вище нульового кільця, а ядру гостьової операційної системи здається, що воно насправді в нульовому кільці Таким чином, ESX (i) може працювати на процесорах без апаратної підтримки ВІРТУАЛ зації Гипервизор працює в кільці 0 Це найстаріший механізм, який у наш час вважається успадкованим Він володіє найвищими накладними витратами і взагалі не працює для 64-бітних гостьових ОС

Q паравіртуалізації ОС Ядро гостьовий ОС може бути змінено для кор-

ректно роботи в ВМ – тоді гіпервізорами не потрібно примусово «виганяти» ядро ​​з нульового кільця У силу необхідності зміни коду ОС на рівні ядра, притому зміни різного роду для різних гіпервізорів, паравіртуалізації не стала масовою Проте використання паравір туалізованних ОС в ВМ на сучасних гіпервізорами дозволяє знизити накладні витрати на віртуалізацію Відомі мені джерела говорять про приблизно 10%-ної різниці в порівнянні з непаравіртуалізованнимі ОС Для запуску паравіртуалізованних гостьових ОС немає необхідності в апаратній підтримці віртуалізації Паравіртуалізації де-факто мало актуальна для ESX (i), тому тут згадується для повноти картини

Q та сама апаратна підтримка віртуалізації Вона реалізується за допомогою на-

щью технологій Intel VT (Virtualization Technology) або AMD-V Якщо процесор володіє цією можливістю, то це означає, що він надає для гіпервізора специфічний пріоритет Цей пріоритет зазвичай називають кільце -1 (мінус один) Специфічність проявляється в тому, що виконувані в цьому кільці інструкції, з одного боку, ще пріоритет неї, ніж інструкції кільця нульового а з іншого – в мінус перший кільці можуть виконуватися не всі інструкції Втім, все, необхідні гіпервізорами, в наявності Таким чином, якщо процесори сервера володіють апаратною підтримкою віртуалізації, то гіпервізор на такому сервері може

запускати будь гостьові операційні системи без необхідності їх модифікації Цей режим є штатним для ESX (i)

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

Однак можливість реалізувати віртуальну інфраструктуру навіть на серверах без апаратної підтримки віртуалізації є архіполезной, якщо подібна задача перед вами все-таки встала

До ОЗУ вимог особливо немає Її просто має бути достатньо Груба оцінка достатнього обєму:

1 Беремо інформацію про те, скільки памяті необхідно кожній ВМ Підсумовуємо Округляємо до зручного для установки в сервер обсягу

2 Хоча при сайзінге це враховувати не слід, але частина памяті виявиться вільною У цьому допоможуть механізми ESX (i) по роботі з памяттю Враховувати ж при плануванні ці механізми не рекомендується унаслідок того, що в загальному випадку ефект економії не гарантується Втім, ви можете вивести і використовувати свій коефіцієнт залежно від власного досвіду, розуміння специфіки планованого навантаження і готовності йти на ризик не повністю здійснились прогнозів

3 Крім того, різні ВМ можуть дійсно використовувати свою память повністю в різний час Отже, сумарний обсяг використаної памяті на сервері в середньому виявиться менше сумарного обсягу памяті, виділеної для всіх віртуальних машин На цей ефект теж не рекомендують покладатися при сайзінге

4 З причин з пунктів 2 і 3 робити великий запас по памяті не слід

Втім, більшість інфраструктур мають звичай рости і в бік збільшення кількості ВМ, і у бік збільшення навантаження на існуючі ВМ, так що при такій перспективі памяті краще взяти більше

Джерело: Міхєєв М О Адміністрування VMware vSphere 41 – М: ДМК Пресс, 2011 – 448 с: Ил

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*