Дискова підсистема

Коли ми говоримо про ресурси дискової підсистеми, то назвати їх можна три: обсяг місця, швидкість читання і запису в Мб / сек і швидкість читання-запису в кількості операцій введення-виведення в секунду (Input / Output per second, IOPS, або просто I / O)

Поговоримо спочатку про обєм Я приведу міркування, на які слід орієнтуватися, і приклад розрахунку

Міркування такі:

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

Q якщо для всіх або частини ВМ ми плануємо використовувати тонкі (thin) диски, то слід спланувати їх первинний обєм та подальше зростання (тут і далі під thin-дисками розуміється відповідний тип vmdkфайлов, тобто функція thin provisioning в реалізації ESX (i) Справа в тому, що функціонал thin provisioning може бути реалізований на системі зберігання незалежно від ESX (i), і я маю на увазі не функціонал систем зберігання)

Q за замовчуванням для кожної ВМ гіпервізор створює файл підкачки, по раз-

заходам дорівнює обєму її оперативної памяті Цей файл підкачки розташовується в папці ВМ (за замовчуванням) або на окремому LUN

Q якщо плануються до використання знімки стану, то під них теж

слід запланувати місце За точку відліку можна взяти такі міркування:

• якщо знімки стану існуватимуть короткий період після створення, наприклад тільки на час резервного копіювання, то під них запасаем відсотків десять від розміру диска ВМ

• якщо знімки стану використовуватимуться з середньою або непрогнозованою інтенсивністю, то для них має сенс закласти близько 30% від розміру диска ВМ

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

Приблизна формула виглядає наступним чином:

Обсяг місця для групи ВМ = Кількість ВМ × (Розмір диска × T +

+ Розмір диска × S + Обсяг памяті – Обєм памяті × R)

Тут:

Q T – коефіцієнт тонких (thin) дисків Якщо такі диски не використовуються, дорівнює 1 Якщо використовуються, то абстрактно оцінку дати складно, залежить від характеру додатки в ВМ По суті, thin-диски займають місця на системі зберігання менше, ніж номінальний розмір диска Так от – цей коефіцієнт показує, яку частку від номінального розміру займають диски віртуальних машин

Q S – розмір знімків стану 10/30/200 відсотків, залежно від про-

должительности безперервного використання

Q R – відсоток зарезервованої памяті Зарезервована память у файл підкачки не поміщається, файл підкачки створюється меншого розміру Розмір його дорівнює: обсяг памяті ВМ мінус обсяг зарезервованої памяті

Оціночні вхідні дані, для прикладу, см в табл 13

Таблиця 13 Дані для планування обсягу дискової підсистеми

Група ВМ

Розмір дисків одній ВМ, Гб

Використовуються тонкі диски

Приблизний розмір снапшотов

Середній розмір ОЗУ ВМ, Гб

Резервування ОЗУ,%

Количе ство ВМ в групі

Інфраструктура

20

Ні

10%

2

0

15

Сервери додатків

20 + 20

Ні

10%

2

0

20

Критичні сервери додатків

20 + 80

Ні

10%

6

50

10

Тестові і тимчасові

20

Так

200%

2

0

20

Отримуємо оцінку необхідного обєму:

Q інфраструктурна група – 15 × (20 + 20 × 10% + 2 – 2 × 0) = 360 Гб

Q сервери додатків – 20 × (40 + 40 × 10% + 2 – 2 × 0) = 920 Гб

Q критичні сервери – 10 × (100 + 100 × 10% + 6 – 6 × 05) = 1130 Гб

Q тестові і тимчасові – 20 × (20 × 30% + (20 × 30%) × 200% + 2 – 2 × 0) =

= 400 Гб

Всього отримуємо 2810 Гб Зазвичай рекомендується розміщувати 8-15 ВМ на один LUN Розмір одного LUN обмежений як абсолютний максимум 2 Тб мінус 512 байт

Отже, ми можемо створити два LUN по 1,4 Тб і приблизно порівну розподілити між ними віртуальні машини Або створити 4-5 LUN по 600 – 800 Гб і помістити машини різних груп на різні LUN Обидва варіанти (і проміжні між ними) прийнятні Вибір між ними робиться, виходячи з інших переваг (наприклад, організаційних)

Ще одним ресурсом дискової підсистеми є продуктивність У разі віртуальних машин швидкість в Мб / сек не є надійним критерієм їм, тому що при зверненні великої кількості ВМ на одні й ті ж диски звернення йдуть непослідовно Для віртуальної інфраструктури більше важливою характеристикою є кількість операцій введення-виведення (IOPS, Input / Output per second) нашої інфраструктури повинна дозволяти більше цих операцій, ніж їх запитують віртуальні машини

Який шлях проходять звернення гостьовій ОС до фізичних дискам в загальному випадку:

1 Гостьова ОС передає запит драйверу контролера SAS / SCSI (який для неї емулює гіпервізор)

2 Драйвер передає його на сам віртуальний контролер SAS / SCSI

3 Гипервизор перехоплює його, обєднує з запитами від інших ВМ і передає загальну чергу драйверу фізичного контролера (HBA у разі FC і апаратного iSCSI або Ethernet-контролер у разі NFS і програмного iSCSI)

4 Драйвер передає запит на контролер

5 Контролер передає його на систему зберігання, по мережі передачі даних

6 Контролер системи зберігання приймає запит Запит цей – операція читання або запису з якогось LUN або томи NFS

7 LUN – це «віртуальний розділ» на масиві RAID, що складається з физиче ських дисків Тобто запит передається контролером СГД на диски цього масиву RAID

Де може бути вузьке місце дискової підсистеми:

Q швидше за все, на рівні фізичних дисків Важливо кількість фізичних дисків в масиві RAID Чим їх більше, тим краще операції читання-запису можуть бути распараллелен Також чим швидше (в термінах I / O) самі диски, тим краще

Q різні рівні масивів RAID володіють різною продуктивністю За-

кінчені рекомендації дати складно, тому що, крім швидкості, типи RAID відрізняються ще вартістю і надійністю Однак базові міркування звучать так:

• RAID-10 – найшвидший, але найменш ефективно використовує простір дисків, віднімаючи 50% на підтримку відмовостійкості

• RAID-6 – найнадійніший, але страждає низькою продуктивністю на записи (30-40% від показників RAID-10 при 100% записи), хоча читання з нього таке ж швидке, як з RAID-10

• RAID-5 компромісний Продуктивність на запис краще RAID-6 (але гірше RAID-10), вище ефективність зберігання (на відмовостійкість забирається ємність лише одного диска) Але RAID-5 страждає від серйозних проблем, повязаних з довгим відновленням даних після виходу з ладу диска в разі використання сучасних дисків великої ємності і великих RAID-груп, під час якого залишається незахищеним від іншого збою (перетворюючись в RAID-0) і різко втрачає в продуктивності

• RAID-0, або «RAID з нульовою отказоустойчивостью», для зберігання значимих даних використовувати не можна

Q налаштування системи зберігання, зокрема кеша контролерів системи зберігання Вивчення документації СГД важливо для правильної її налаштування та експлуатації

Q мережа передачі даних Особливо якщо планується до використання IP

СГД, iSCSI або NFS Я ні в якому разі не хочу сказати, що не треба їх використовувати, – такі системи давно і багатьма експлуатуються Я хочу сказати, що треба постаратися переконатися, що переносимої в віртуальне середовище навантаженні вистачить пропускної здатності мережі з планованою пропускною здатністю

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

Розберемо приклад Приймемо, що наші ВМ будуть створювати навантаження до 1000 IOps, 67% з яких становитиме читання, а 33% – запис Скільки і яких дисків нам потрібно у випадку використання RAID-10 і RAID-5

У масиві RAID-10 в операціях читання беруть участь відразу всі диски, а в операції запису – лише половина (бо кожен блок даних записується відразу на два диска) У масиві RAID-5 в читанні беруть участь всі диски, але при записі кожного блоку виникають накладні витрати, повязані з підрахунком і зміною контрольної суми Можна вважати, що одна операція запису на масив RAID-5 викликає чотири операції записи безпосередньо на диски

Для RAID-10:

Q читання – 1000 × 0,67% = 670 IOps

Q запис – 1000 × 0,33% = 330 × 2 (так як у записі бере участь лише половина

дисків) = 660 IOps

Всього від дисків нам треба 1330 IOps Якщо поділити 1330 на кількість IOps, заявлене в характеристиках продуктивності одного диска, отримаємо необхідну кількість дисків у масиві RAID-10 під вказану навантаження

Для RAID-5:

Q читання – 1000 × 0,67% = 670 IOps

Q запис – 1000 × 0,33% = 330 × 4 = 1320 IOps

Всього нам від дисків треба 1990 IOps

За документації виробників один жорсткий диск SAS 15k обробляє 150-180 IOps Один диск SATA 72k – 70-100 IOps Проте є думка, що краще орієнтуватися на дещо інші цифри: 50-60 для SATA і 100-120 для SAS

Закінчимо приклад

При використанні RAID-10 і SATA нам буде потрібно 22-26 дисків

При використанні RAID-5 і SAS нам буде потрібно 16-19 дисків

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

За кадром залишаються методики одержання необхідного для ВМ кількості IOPS і ставлення читання до запису Для вже існуючої інфраструктури (при перенесенні її в віртуальні машини) ці дані можна отримати за допомогою спеці них засобів збору інформації, наприклад VMware Capacity Planner Для інфра структури планованої – з документації до додатків і власного досвіду

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

*

*