Мережева підсистема

З приводу мережі Тут міркувань три:

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

2 Необхідна доступність Тут нам допоможе дублювання – знову ж за рахунок угруповання мережевих контролерів (Teaming)

3 Безпека Тут може допомогти фізична ізоляція трафіку по різних мережевим контролерам та / або використання VLAN

Для реалізації всіх міркувань нам може знадобитися кілька (багато ☺) мережевих контролерів Абсолютний мінімум – 1 Ідеальний мінімум – 4 або навіть 6, залежно від планованих до використання функцій vSphere Такі функції, як vMotion, Fault Tolerance, робота з системами зберігання поверх протоколу IP, вимагають ресурсів мережі, і під них рекомендується виділяти окремі фізичні контролери

Як порахувати, скільки потрібно в конкретному випадку

Мережа нам потрібна для:

1 Управління Інтерфейс Service Console (для ESX) або інтерфейс VMker nel, налаштований для Management traffic (для ESXi)

2&nbsp&nbsp&nbsp vMotion

3&nbsp&nbsp&nbsp Fault Tolerance

4 iSCSI і / або NFS, якщо вони будуть використовуватися

5 ВМ Серед ВМ може бути кілька груп ВМ, кожній з яких може знадобитися виділений мережевий інтерфейс (або не один)

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

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

Для Fault Tolerance міркування приблизно ті ж, що і для vMotion Але, швидше за все, необхідність наявності дублюючого контролера для FT вірогідніша Проте навантаження на мережевий контролер з боку інших завдань може перешкодити нормальній роботі Fault Tolerance Вірно і у зворотний бік: якщо трафік Fault Tolerance буде досить великий, він може заважати іншим завданням, якщо вони поділяють один і той же фізичний мережевий інтерфейс

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

Для ВМ – залежить від ваших потреб Який передбачається організація віртуальної мережі Чи зможуть всі ВМ використовувати один і той же контролер (групу контролерів) Чи необхідно дублювання

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

Також залежно від планованого навантаження можна задуматися над оправданностью застосування контролерів 10 Гб Ethernet У першу чергу це може виявитися актуально для трафіку СГД по протоколу IP і для Fault Tolerance

Заключний питання Припустимо, ви визначилися з конфігурацією СГД Порахували, скільки процесорної потужності та оперативної памяті необхідно вам для розміщення всіх ВМ Але як розподілити їх по серверам Наприклад, 16 процесорів і 256 Гб ОЗУ можна розмістити в 4 чотирипроцесорних серверах по 64 Гб в кожному або 8 двопроцесорних по 32 Гб Що вибрати при інших рівних

Тут (як і скрізь в цьому розділі) складно дати однозначні рекомендації, тому наводжу свої міркування

1 Модельний ряд того постачальника серверного обладнання, з яким ви працюєте Якщо всі ваші використовувані сервери (нехай інших моделей) зроблені фірмою XYZ і ви ними задоволені, настійно рекомендую не «розводити зоопарк» і не пускатися в експерименти з іншими постачальниками Потім самі будете не раді

2 Звичайно, попередня рада не включає ситуації, коли вас не влаштовує якість чи рівень підтримки наявних серверів, або ваш постачальник не пропонує серверів потрібної конфігурації

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

4 Великі сервери створюють менші накладні витрати, а також дозволяють вмістити сумарно більше ВМ У нашому прикладі це можна проіллю стрировать таким чином У кожен з чотирьох серверів по 64 Гб ви зможете з достатнім комфортом розмістити по 21 ВМ по 3 Гб ОЗУ

кожна (всього виходить 4 × 21 = 84 ВМ) У кожний з восьми серверів по

32 Гб – по десять таких же ВМ, всього виходить 8 × 10 = 80 Разом напів-

чає, що в більш великих серверах щільність розміщення ВМ вище і,

відповідно, в той же сумарна кількість ОЗУ можна вмістити більше ВМ Якщо ж врахувати економію від Transparent Page Sharing, то різниця стане ще більш помітна

5 З іншого боку, не можна забивати всі сервери під завязку Треба подумати і про доступність своїх служб Розумно запланувати, що один з серверів може відмовити, а ще один у це час може знаходитися на обслуговуванні (наприклад, оновленні ПЗ або устаткування) Разом ми хочемо, щоб наше рішення зберігало доступність при одночасному виході з ладу двох вузлів У першому випадку ми таким чином позбавляємося половини (4 – 2 = 2) серверів І виходить, що ми можемо задіяти з користю лише

256 – (2 × 64) = 128 Гб ОЗУ і розмістити в них тільки (4 – 2) × 21 = 42 ВМ

У другому випадку нам залишається вже 8 – 2 = 6 серверів з 256 – (2 × 32) =

= 194 Гб, в яких поміститься (8 – 2) × 10 = 60 ВМ Як бачимо, з урахуванням

планування доступності перевагу в нашому прикладі виявляється

вже на боці більш модульної архітектури

6 З третього боку, ви ні під яким виглядом не зможете розділити навантаження однієї ВМ між декількома серверами (принаймні, на поточному етапі розвитку технологій віртуалізації) Іншими словами, якщо вам раптом одного разу буде потрібно створити ВМ з обємом ОЗУ 40 Гб, то другий сценарій (сервери по 32 Гб) вам просто не підійде (без урахування можливо стей з оптимізації використання памяті, які ми тут не станемо враховувати для наочності) А ось першим варіантом (сервери по 64 Гб) такий сценарій виявиться цілком під силу

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

8 Сервери-леза (Blade servers) мають масу переваг з точки зору вартості володіння (витрати на управління, обслуговування, харчування та охолодження) Вони також відмінно відповідають пята міркуванню, наведеним вище, – адже кожне лезо є порівняно невеликий складовою інфраструктури У результаті вихід з ладу відразу декількох з них навряд чи сильно зменшить сумарну потужність системи Блейд-сервери також вкрай ефективні з точки зору зменшення проблем і головного болю – куди подіти все ці кабелі Припустимо, що, слідуючи міркувань відмовостійкості, ми будемо використовувати 6 одногігабітних мережевих інтерфейсів (2 = управління + vMotion, 2 = iSCSI, 2 = віртуальні машини) Не забудемо про мережу IPMI \ iLO – у підсумку 7 інтерфейсів (і кабелів) на сервер 8 серверів віртуалізації у результаті дають нам 56 кабелів, які до того ж треба кудись підключати, тобто буде потрібно ще і 56 мережевих портів У випадку з блейд-серверами кількість кабелів (і портів) скорочується до 10-12

9 З іншого боку, варто задуматися про збої не тільки на рівні кожного леза окремо, а й кожної корзини (шасі) А ось вихід з ладу цілої кошика виявиться таки більш істотний, ніж навіть пари звичайних стоечних серверів, хоча, звичайно, куди менш імовірний

10 З третього боку, збільшуючи нашу інфраструктуру і піднімаючи вимоги до доступності, може знадобитися вести рахунок вже не на втрату окремих серверів або кошиків, а цілих стійок І тут немає особливої ​​різниці, втратили ви стійку з лезами або стійку з звичайними серверами Тобто переваги лез можуть знову вийти на перший план

Загалом, сподіваюся, що загальну ідею і способи оцінки привабливості різних підходів до вибору типу серверів ви зрозуміли і це виявилося для вас корисним Далі вам доведеться вирішувати самим, керуючись подібними або якимись зовсім іншими міркуваннями

Але, як це не дивно, аналогічні міркування можуть діяти не тільки на обладнання і доступність служб, а й на ліцензування ПЗ, яке ви плануєте запускати у віртуальних машинах Рекомендую заздалегідь ознайомитися з тонкощами ліцензування цього ПО і нюансами, повязаними з ВІРТУАЛ зацией

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

Інші виробники можуть накладати обмеження на перепрівязку ліцензій між серверами і вважають таким перенесенням операції міграції ВМ (наприклад, vMotion) І тут, вже навпаки, великі сервери, які знижують частоту (або необхідність) перенесення ВМ, можуть виявитися вигідніше

Джерело: Міхєєв М О Адміністрування 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>

*

*