Налаштування віртуальної інфраструктури: оптимізація кластера VDI

Ну як оптимізація. Креативні зусилля по вирівнюванню кренящейся і хитається інфраструктури, яку з усіх сил намагалися утримати способом «нічого не чіпайте, все може зламатися». Небезпечна фраза, швидко перетворюється в життєву філософію ІТ спеціаліста, який зупинився в розвитку. Джерело «ошаманивания» ІТ.

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



Отже, дано:
Інфраструктура віртуалізації VMware Enterprise Plus. Включає продуктив, тестову зону і VDI. Останній реалізований на базі продукту fujitsu Pano Logic, який вже 2 роки як не оновлюється і, судячи з усього, не підтримується.
Основний модернізований кластер — VDI, як самий об'ємний критичний сервіс і найщільніший з утилізації ресурсів. Реалізований на базі повних клонів, бо пов'язані клони pano manager сам по собі не розуміє, а купувати ще й View бізнес не хоче.

В якості СГД використовується набір масивів EMC — кілька CX4-240 і пара VNX. А також є такий шедевр як IBM SVC. Використовується для консолідації та віртуалізації зберігання (тобто lun монтуються з стораджей на SVC, там об'єднуються в пули, а на цих пулах вже створюються нові LUN, що віддаються серверів). Всі сховища підключені по FC SAN.

Так як документації не було, вивчати, як живе і працює доводилося наживую. При цьому деякі нешкідливі, здавалося б, зміни, які інколи приводили до несподівано неприємних наслідків, виявляючи дивні налаштування і милиці.

Швидка навігація:

1. Підсистема зберігання
2. Мережа
3. Обчислювальні ресурси

1. Підсистема зберігання

Цей напрямок я почав ще до звільнення колеги, оскільки SAN і була основною моєю зоною відповідальності.

1.1 VAAI
Перше, що мене здивувало — використання великої кількості датасторов маленького (1ТБ) розміру. Навіщо — ніхто пояснити не зміг. Спроба консолідувати в датасторы побільше відразу виявила проблему — занадто велика кількість scsi-блокувань, як наслідок високі latency і бут-шторми, як явище. Дивним було те, що система зберігання вела себе, як ніби не підтримувала VAAI. Але у властивостях датасторов явно вказано «Hardware Acceleration: Supported».

Розуміння прийшло, коли вводили новий хост в кластер. Колега згадав, що перед експлуатацією «треба ввести команду — відключити якусь штуку, яка призводить до проблем при роботі з SVC». «Штукою» виявився параметр VMFS3.HardwareAcceleratedLocking, що виставляється 0. Іншими словами, відключалася, мабуть, найважливіша функція VAAI — Atomic Test and Set (ATS) — дозволяє при зміні метаданих датастора (включення/вимикання, міграція і розтягування тонких дисків ВМ) блокувати не весь датастор, а конкретні сектори на дисках.

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

Рекомендації: З точки зору продуктивності, менша кількість великих за розміром LUN вигідніше, ніж велика кількість маленьких — тут і оверхед на обслуговування кожного LUN та розпаралелювання запитів і погіршення ефективності роботи різних рівнів кеша. (Рекомендація EMC по зниженню навантаження на SP: Reduce the number of LUNs by consolidating LUNs where possible. If a RAID group has multiple LUNs being used for the same host and application, then this can lead to linked contention, large seek distances and poor use of cache. Replacing with these fewer, larger LUNs will also reduce the amount of statistics which need to be monitored, therefore further reducing SP Utilization.)

При використанні систем віртуалізації зберігання, переконайтеся, що вони «інтелектуальнішим» розташованого нижче рівня, або хоча б не вбивають функціонал сховищ. У нашому випадку SVC явно була «дурніші» масивів EMC, відмовлялася бачити LUN'и більше 2 ТБ і робила безглуздим такі фічі, як автотиринг (і підозрюю, що Flash Cache).
Ну і звичайно варто переконатися, що обладнання зберігання підтримує VAAI, і, більш того, що цей функціонал не заблоковано на рівні інфраструктури віртуалізації.

1.2 Зонінг і розподіл по масивам
Другий момент — дивний розкид різних категорій даних по масивам. БД упереміш з файл-серверами та VDI в хаотичному порядку були розкидані по всьому стораджам за принципом «де було місце». Не кажучи вже про те, що частина датасторов була підключена безпосередньо до EMC-масивів, а частина — через SVC.

Після тривалих міграцій і перерозподілів вдалося розподілити дані найбільш оптимальним чином — самі ресурсопотребляющие (продуктивні сервери і VDI) скласти на VNX'и, а кларионы віддати під бекапи і менш вимогливі сервіси. У SVC залишилися тільки безпосередньо проброшенные сервери LUN, всі датасторы я з неї витяг. Кількість зон на комутаторах скоротилося с ~120 до ~75, з урахуванням того, що раніше зустрічалися зони типу «багато таргетов — багато ініціаторів», а зараз не більше одного ініціатора в зоні. Просто тому, що дані певного типу, з якими працювали певні сервери лежать тепер на одній СГД, а не на трьох різних.

У чому профіт — зайві зони створювали зайве навантаження в SAN-мережі, використання різнорідної навантаження (IO-інтенсивного типу БД і послідовного запису, типу бекапів/файл-серверів) на одному масиві шкодить продуктивності. Використання в одній зоні більше одного ініціатора — bad practice.

1.3 Параметри Path Selection
# esxcli storage nmp device list на хостах показала, що
а) здебільшого для вибору шляхів до датасторов використовується політика Round Robin,
б) Для частини датасторов (перших шести) на перших двох хостах зміна шляху відбувається через 3 IOPS
Path Selection Policy Device Config: {policy=iops,iops=3,
на інших — дефолтний значення
Path Selection Policy Device Config: {policy=rr,iops=1000,
в) На останніх п'яти хостах кластера для частини датасторов взагалі використовувався Fixed (все спілкування з СГД йде по одному шляху, поки він доступний).

Вибір Path Selection Policy визначається моделлю і вендором СГД. У більшості випадків, для конфігурація active-active використовується round robin, через який-ніякий, але балансування навантаження. За замовчуванням зміна шляху відбувається через 1000 iops. Проте в деяких випадках це може призвести до затримок. kb від VMware, де рекомендується змінити це значення на 1. тести, показують, що продуктивність підсистеми зберігання в цьому випадку реально вище.

Рекомендації: налаштовуйте multipathing у відповідності з рекомендаціями вендорів для ваших конфігурацій. І стежте за тим, щоб на всіх хостах вони були однаковими. Добре в цьому допомагають Host Profiles в VMware.

2. Мережа

В цілях налаштування балансування навантаження, всі комутатори блейд-кошики кластера VDI були об'єднані в стек, організований EtherChannel і load balancing в розділі Teaming and Failover був налаштований як Route Based on IP Hash. Справа в тому, що IP Hash працює тільки поверх EtherChannel і з EtherChannel сумісний тільки IP Hash. Однак коли кластер виріс до другої блейд-кошики, комутатори якої не підтримували EtherChannel, з'явилася проблема. Проблема проявлялася у вигляді жорсткого MAC-флаппинга на комутаторах другого кошика (зі слів мережевиків) і відкинути прийнятих пакетів на першій (від 10 до 100 в секунду, за даними системи моніторингу).

Важлива рекомендація — не змінюйте налаштування мережі масово для всього кластера. Перевіривши на одному хості і переконавшись, що все в порядку, ми відключили EtherChannel на всіх інших. І втратили доступ до всіх, крім першого. 15 болісних хвилин, поки відходили від шоку і повертали конфігурацію назад, ніхто, крім щасливчиків розміщених на першому сервері, не міг працювати. Надалі змінювали налаштування по одному вузлу, виводячи його попередньо в Maintenance Mode. Паралельно я вважав загальні людино-години простою, множачи 15 на 1300 (кількість VDI) і ділячи на 60. Дякую керівництву за розуміння… А адже це було вже не перше потрясіння, сязанное з віртуальними десктопами.
До речі, вже не знаю чому, але поки я не пересоздал dvSwitch, хост при кожному ребуті видавав помилку: LACP Error: <щось на тему того, що поточна конфігурація підтримує IP Hash only>. Хоча EtherChannel був відключений. Новий dvSwitch таку помилку не показував. Перенесення хостів та віртуальних машин в новий розподілений комутатор спалив ще пачку нервових клітин, але все обійшлося.

Попутно я перенастроил використання аплінк. Перед початком роботи всі портгруппы були налаштовані однаково:



Я зробив так:



В якості способу організації балансування — Route based on physical NIC load (наступний за списком інтерфейс вибирається, якщо поточний завантажений більш ніж на 70%).

Висновки — настройка балансування та відмовостійкості мережі — процес творчий. Але подальший монторинг показав, що при такій конфігурації а) зникли втрати пакетів першої блейд-кошики, б) балансування навантаження по аплінків стала більш рівномірною, в) рідко, але бували раніше випадки, що хост раптом ставав недоступним. За останні кілька місяців такого не було жодного разу. в) Масовий vMotion (висновок сервера в Maintenance Mode, наприклад) не впливає на трафік ВМ.

Переваг використання IP Hash, порівняно з LB, я не бачу.

3. Обчислювальні ресурси

Мені відразу здалося, що 1,5 ГБ RAM для віртуальних десктопів на Windows 7 — це знущання над користувачами. І швидше за все негативний вплив на дискову підсистему з-за свопінгу всередині ОС. Ось тільки надлишком пам'яті не було. Ризик втрати відмовостійкості і свопінгу на рівні віртуальних машин був більш негативним фактором. Ідея прийшла з новини про відключення кошти Transparent Pages Sharing з налаштувань за замовчуванням в майбутніх версіях vSphere. Точніше, з дискусії про неї на facebook.

Короткий зміст:

Фіча відключається, оскільки є гіпотетична загроза безпеки (can be abused to gain unauthorized access to data *under certain highly controlled conditions*).
У більшості реалізацій технологія дійсно майже даремна з тих часів як з'явилася ASLR і підтримка великих сторінок пам'яті. Оскільки знайти дві однакові сторінки при розмірі оних в 2 МБ менш імовірно, ніж в 4 КБ. А для серверної віртуалізації сторінки в 2 МБ куди критичніше, в плані продуктивності, ніж економія пам'яті.

Однак, чому б не перевірити її на кластері VDI?

Я вніс такі зміни в Advanced Settings хоста:
Mem.AllocGuestLargePage = 0 замість 1 — відключення великих сторінок пам'яті
Mem.ShareScanGhz = 6 замість 4 — підвищення частоти сканування
Mem.ShareScanTime = 30 замість 60 — підвищення швидкості сканування

Для компенсації збільшення навантаження на процесор я відключив фішки vNuma, як непотрібні у випадку ВМ, у яких менше 8 vCPU. Дані установки (разом з налаштуваннями Path Selecting Policy) я поширив на всі хости з допомогою Host Profiles. Результат можна побачити на скріні нижче.



Пояснення по параметрам:
Якщо дві ВМ спільно використовують 100 МБ пам'яті, то параметр Shared буде дорівнює 200 МБ, а Shared Common — 100 МБ.
Як можна побачити з результатів моніторингу за місяць, Shared Common виріс у чотири рази, а Shared — в шість. Сумарна економія пам'яті склала майже 700 ГБ, тобто на 600 ГБ більше, порівняно зі станом на 26 жовтня. Це майже чверть всіх ресурсів кластера. Правда середнє завантаження процесора зросла з 50-60% до 70-90%.
5 листопада спостерігається невеликий спад, оскільки Mem.ShareScanTime і Mem.ShareScanGhz довелося повернути в значення за замовчуванням щоб знизити завантаження процесора. Зараз вона тримається на 60-80% Тим не менш, економія все одно залишилася значна і з'явилася можливість всім машинам, які мали 1,5 ГБ пам'яті збільшити її обсяг до 2.

Вплив цих змін з точки зору «чуйності» дискової підсистеми можна оцінити по картинці нижче. Наведено значення Read Latency для декількох датасторов. На жаль, на цей період припали експерименти з вікнами обслуговування SCCM, які давали нічні піки з фантастичними значеннями до 80 секунд і зробили абсолютно непоказательными середні значення. З цієї причини я не став приводити сам графік — нічні піки вбили всю наочність денного навантаження. Але можна оцінити зміну за мінімальним значенням часу відгуку (перші колонки).



Перший час взагалі незвично було бачити свідчення середньої Latency в «зеленій» зоні — 10-20 мс. Звично було, що майже ніколи не опускалися нижче 30.

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

Дякую за увагу.

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.