1. Пропоноване рішення проблем віртуалізації
2. Малюнок 1. Приклад повної віртуалізації
3. Рішення
4. Блок-схема алгоритму
5. План Server-VM
6. Малюнок 2. Блок-схема відображення Server-VM
7. Малюнок 3. Блок-схема відображення Storage-VM
8. Вихідні дані
9. План Server-VM
10. Лістинг 2. Фрагмент коду початкової перевірки
11. Лістинг 3. Фрагмент коду призначення залишилися користувачів
12. Лістинг 5. Фрагмент коду ініціалізації ratio на пристроях зберігання
13. Лістинг 6. Фрагмент коду перевірки розподілу ratio
14. Приклад вихідних даних
15. Малюнок 4. Приклад вихідних даних алгоритму Virtual Machine Deployment Map в XML-форматі
16. Поділіться своєю думкою
17. Ресурси для скачування

Простий і ефективний спосіб масового розгортання віртуальних машин

Пропоноване рішення проблем віртуалізації

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

Говорячи про віртуалізації, треба пам'ятати, що її можна реалізувати не єдиним способом. На практиці є багато способів досягнення одного і того ж результату за допомогою різних рівнів абстракції.

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

Малюнок 1. Приклад повної віртуалізації

проблеми віртуалізації

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

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

Рішення

У статті пропонується оптимальне, просте і ефективне рішення проблеми - алгоритм Virtual Machine Deployment Map (план розгортання віртуальних машин). Беручи до уваги наявність різних серверів і ресурсів зберігання даних, алгоритм намагається розподілити групи віртуальних машин на доступні сервери пропорційно наявним ресурсам. Алгоритм також мінімізує число базових віртуальних машин в кожній групі, тим самим істотно зменшуючи пам'ять, необхідну для розгортання.

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

Крім того, алгоритм управляє розподілом навантаження груп віртуальних машин ( "золотих образів") між серверами і пристроями зберігання, намагаючись мінімізувати число "золотих образів". Таким чином, він надає ефективну методику оптимізації ресурсів груп "золотих образів" між різними серверами і пристроями зберігання, яка залежить від конфигурируемого коефіцієнта розподілу. Він навіть забезпечує високу готовність при розгортанні віртуальних машин.

Наш алгоритм створює план архітектури розгортання і відображення розгортання між віртуальними клієнтами, серверами і пристроями зберігання (відображення віртуальних клієнтів на сервери і віртуальних дисків на пристрої зберігання). Це дозволяє інженеру по розгортанню і системному адміністратору знати, яка буде створена віртуальна машина і на якому сервері. Він також пропонує спосіб поділу пам'яті відповідно до вимог до пам'яті всіх віртуальних машин.

Залежно від бізнес-вимог цей план може бути представлений або в графічному, або в XML-форматі.

Блок-схема алгоритму

Алгоритм ділиться на дві частини:

• План Server-VM
• План Storage-VM

План Server-VM

Він виконує відображення Server-VM (сервер на віртуальну машину). На малюнку 2 показано відображення Server-VM.

Малюнок 2. Блок-схема відображення Server-VM

План Storage-VM

Це план, грунтуючись на вихідних даних плану Server-VM, відображає віртуальні машини на логічні пристрої. Ці логічні пристрої повинні бути створені на відповідних пристроях зберігання і відображені на сервери, зазначені у вихідних даних плану Storage-VM (пристрій зберігання на віртуальну машину).

Малюнок 3. Блок-схема відображення Storage-VM

подробиці алгоритму

Передбачається, що адміністратор має наведені нижче вихідні дані для алгоритму.

Вихідні дані

список серверів

Кожен сервер характеризується кількістю ядер процесора, сокетов, пам'яті і т.д.

Тип користувача

Кожна група користувачів має свої вимоги до обладнання. Як правило, в організації є три типи користувачів:

• Користувачі Power. Це ті, хто пред'являє максимальні вимоги до ресурсів (процесор, пам'ять) - наприклад, розробники.
• Користувачі Knowledge. Це ті, хто у своїй повсякденній діяльності пред'являє середні вимоги до ресурсів - наприклад, тестувальники.
• Користувачі Task. Це ті, хто в повсякденній роботі не має занадто високих вимог до ресурсів - наприклад, менеджери.

Список "золотих образів"

Цей список містить інформацію про кількість і типи користувачів кожного "золотого образу". У кожній організації є різні проекти і набори ПО і устаткування для кожного з них. Кожен проект має власні вимоги до пам'яті і типам користувачів (Power, Knowledge або Task). Наприклад, організація має два "золотих образу" (проекту) наступних конфігурацій:

• Проекту Golden Image 1 потрібні 5 користувачів Power, 3 користувача Knowledge і 1 користувач Task.
• Проекту Golden Image 2 потрібні 4 користувача Power, 0 користувачів Knowledge і 1 користувач Task.

Список пристроїв зберігання

Кожен запис містить інформацію про загальний розмір пам'яті, доступної на цьому пристрої.

Алгоритм використовує коефіцієнт (ratio) і пропорцію для відображення користувачів на сервери.

План Server-VM

1. ініціалізація
   1. Задати кількість ядер процесора і пам'яті на кожному сервері.
   2. Встановити змінні TotalAvailableCore і TotalAvailableMemory, підсумовуючи ядра і пам'ять зі списку серверів.
   3. Задати число користувачів на кожному сервері рівним нулю.
2. Переглянути список "золотих образів" і підрахувати загальну кількість користувачів Power (totalPUsers), Knowledge (totalKUsers) і Task (totalTUsers).
3. Відсортувати список серверів в порядку убування числа ядер, доступних для розподілу ресурсів. Це необхідно для розподілу навантаження.
4. Створити змінну status (див. Лістинг 1) і для всіх типів користувачів присвоїти їй значення unallocated. Ця змінна буде перевірятися в процесі виконання алгоритму, щоб гарантувати відображення на сервери всіх користувачів.

Лістинг 1. Фрагмент коду призначення змінної status

status.setPUnallocated (totalPUsers); status.setKUnallocated (totalKUsers); status.setTUnallocated (totalTUsers);

1. Виконати первинну перевірку (див. Лістинг 2). Цей крок дозволяє переконатися, що загальні ресурси серверів перевищують ресурси, необхідні для відображення користувачів на системи.

Лістинг 2. Фрагмент коду початкової перевірки

performInitialValidation () {tCoresRequired = totalTUsers * coreTUsage kCoresRequired = totalKUsers * coreKUsage pCoresRequired = totalPUsers * corePUsage totalCoresRequired = tCoresRequired + kCoresRequired + pCoresRequired; tMemoryRequired = totalTUsers * memoryTUsage kMemoryRequired = totalKUsers * memoryKUsage pMemoryRequired = totalPUsers * memoryPUsage totalMemoryRequired = tMemoryRequired + kMemoryRequired + pMemoryRequired; If (totalAvailableMemory> = totalMemoryRequired && totalAvailableCores> = totalCoresRequired) Перейти на крок 6 (описаний нижче); else Вивести повідомлення "недостатньо ресурсів"; }

тут:

• coreTUsage, coreKUsage, corePUsage - це число ядер, необхідне для користувачів Task, Knowledge і Power відповідно;
• memoryTUsage, memoryKUsage і memoryPUsage - це кількість пам'яті, необхідне для користувачів Task, Knowledge і Power відповідно.

1. Обчислити ratio (коефіцієнт). Даний модуль намагається під час відображення розподілити навантаження, збалансувати "золоті образи" (GI) і оптимізувати базову віртуальну машину в частках змінної divisor. Якщо всіх користувачів можна розподілити на всі сервери в частках divisor (divisor - конфігурується змінна, яку адміністратор встановлює в залежності від потреб), цей модуль повертає true. Тим самим гарантується одночасне відображення на сервер тільки даного безлічі користувачів. Це дозволяє оптимізувати клонування GI і гарантувати, що таких образів буде не дуже багато.
   1. Додати образи на сервери і встановити відповідні значення Power, Knowledge і Тask в нуль; також встановити в нуль значення необхідної сервера пам'яті.
   2. Переглянути всі GI, що розподіляються на сервери відповідно до ratio.

      Лістинг 3. Фрагмент коду призначення залишилися користувачів

      for (k = 0; k <goldenImageList.size (); k ++) {pUsersRemaining = goldenImageList.get (k) .getPUserCount (); kUsersRemaining = goldenImageList.get (k) .getKUserCount (); tUsersRemaining = goldenImageList.get (k) .getTUserCount ();
      1. Обчислити частки користувачів Power, Knowledge і Task, що розподіляються одночасно.

         Лістинг 4. Фрагмент коду ініціалізації частки divisor для кожного типу користувачів

         pUnit = pUsersRemaining / divisor; kUnit = kUsersRemaining / divisor; tUnit = tUsersRemaining / divisor totalUsersUnit = 128 / divisor; // максимальне число користувачів сервера = 128
      2. Обчислити pratio, tratio і kratio:
         Переглянути список серверів.
         {
         • pratio на i-му сервері = (ядер на i-му сервері / всього ядер) * (pUnit)
         • Якщо ratio більше числа залишилися користувачів Power:
           pratio на i-му сервері і Golden Image k = pUnit- (GiPCount / divisor);
         • Якщо частка divisor не може бути розподілена:
           pratio на i-му сервері і Golden Image k = 0;
         • Якщо загальне число користувачів на даному сервері більше 128:
           pratio = totalUsersUnit - число користувачів на i-му сервері;
         • // Перевірити можливість розміщення pratio на даному сервері
           // Величина приросту дорівнює 0.1, оскільки pratio обчислюється з точністю
           // до одного десяткового знака
           for (j = 1; j <= pratio на i-му сервері і Golden Image k; j = j + 0.1)
           {
           Обчислити фактичне число pusers,
           яке можна розмістити на i-му сервері
           }
         • Якщо розміщення неможливо:
           pratio = 0
           інакше
           pratio = числу користувачів, яке не можна розмістити.
         • Оновити інформацію сервера: зменшити ресурси процесора і пам'яті і збільшити кількість зовнішньої пам'яті в залежності від pratio.
         • Змінити число користувачів Golden Image, яке можна розподілити на цей сервер.
         • Виконати ті ж дії для користувачів Knowledge і Task.
         } // Кінець кроку ii
      3. Відобразити нерозподілених користувачів:
         • Вказати число користувачів, які не були розподілені відповідно до ratio (виконати для користувачів p, k і t).
           pUnallocated + = pUnit - (GiPCount / divisor);
         • Пройти по відсортовані методом бульбашки списку серверів і відобразити залишилися користувачів Power, Knowledge і Task на даний GI, грунтуючись на divisor.
      4. Вивести попередження, якщо який-небудь користувач не може бути розподілений ні на один сервер. } // Кінець кроку b
   3. Перевірити змінну status. Якщо який-небудь користувач залишився нерозподіленим, вивести попередження "недостатньо ресурсів". В іншому випадку перейти до плану Storage-VM.

План Storage-VM

Вихідні дані

В якості вихідних даних для списку пристроїв зберігання використовується план Server-VM, згенерований у результаті виконання наведеного вище алгоритму.

1. Задати TotalStorage, підсумовуючи обсяг доступної пам'яті з storageList. Створити змінну status і для всіх типів користувачів присвоїти їй значення unallocated. Ця змінна буде перевірятися в процесі виконання алгоритму, щоб гарантувати відображення на сервери всіх користувачів (див. лістинг 1 ).
2. Виконати первинну перевірку. Перевірити, чи не перевищує пам'ять, необхідна для всіх віртуальних машин, загальний обсяг доступної зовнішньої пам'яті.
3. Обчислити Storage Ratio (коефіцієнт пристрої зберігання). Тут обчислюється число користувачів Power, Knowledge і Task, розподіляється на кожен пристрій зберігання згідно доступної пам'яті.
   1. Переглянути StorageList.
      For i = 0 to StorageList size
      • Обчислити ratio для користувачів Power, Knowledge і Task на цьому пристрої зберігання.

Лістинг 5. Фрагмент коду ініціалізації ratio на пристроях зберігання

pratio пристрою i = обсяг i / загальний обсяг * totalPUsers kratio пристрою i = обсяг i / загальний обсяг * totalKUsers tratio пристрою i = обсяг i / загальний об'емy * totalTUsers

• Округлити обчислені ratio і перевірити, чи можна розподілити користувачів на пристрій зберігання.

Лістинг 6. Фрагмент коду перевірки розподілу ratio

For (j = 1; j <= Storage (i) .getPCount (); j ++) {if ((j * PUserStorageRequired) <= Storage i.getAvailableStorage ()) {// продовжити; } Else {Storage (i) .PCount = (j - 1); break; }} // Кінець for j

• Оновити: доступну зовнішню пам'ять на i-му сервері і змінну status для відображених користувачів p.
• Повторити ті ж дії для користувачів Knowledge і Task.

// Кінець кроку a

1. Відобразити нерозподілених користувачів: Перевірити змінну status для нерозподілених користувачів. Якщо такі є, впорядкувати список пристроїв зберігання в порядку убування доступної пам'яті і відобразити на них користувачів.
2. Відобразити VM2Lun. Якщо який-небудь користувач все-таки залишився нерозподіленим, вивести попередження "недостатньо ресурсів". В іншому випадку створити логічні пристрої і відобразити на них віртуальну машину.
   1. Переглянути serverVMMap і виконати ітерацію по кожному GI, який має бути відображений на цей сервер.
   2. Задати pRemaining = числу користувачів p для GI, який повинен бути розподілений на сервер (i).
   3. Задати обсяг логічного пристрою і число користувачів на цьому пристрої рівними нулю.
   4. For p = 1 to p <= pRemaining:
      • Збільшити обсяг логічного пристрою для pUser, які можу бути розміщені, беручи до уваги наведені нижче міркування.
      • Обсяг логічного пристрою менше 500 ГБ.
      • Число користувачів на логічному пристрої не перевищує 30.
      • Число користувачів р не перевищує числа користувачів, розподілених на пристрій зберігання на кроці 3 .
      • Оновити ресурси після кожного зменшення р.
      • Якщо обсяг логічного пристрою = 500 або кількість користувачів пристрою = 30, відобразити логічний пристрій на сервер і створити новий пристрій.

Примітка.
Повторити ті ж дії для користувачів Knowledge і Task.

1. Вивести плани Server-VM і Storage-VM в графічному або XML-форматі.

Приклад вихідних даних

На малюнку 4 представлений приклад вихідних даних алгоритму Virtual Machine Deployment Map в XML-форматі.

Вхідні дані: Server1 і Server2

"Золотий образ" (GI):

• GI1 має 20 користувачів Power, 30 користувачів Knowledge і 12 користувачів Task.
• GI2 має 7 користувачів Power, 1 користувача Knowledge і 2 користувачів Task.

Пристрій зберігання: Storage1

Малюнок 4. Приклад вихідних даних алгоритму Virtual Machine Deployment Map в XML-форматі

Вихідні дані:

• Для Server1 потрібні 2 логічних пристрої. На Lun1 розподілені 10 P, 15 K і 7 T користувачів з GI1, а на Lun2 - 7 P, 1 K і 2 T користувачів з GI2.
• Для Server2 потрібно 1 логічний пристрій. На Lun3 розподілені 10 P, 15 K і 5 T користувачів з GI1.
• На Storage1 створено 3 логічних пристрої - Lun1, Lun2 і Lun3 об'ємом 120, 75 і 100 ГБ відповідно.

Поділіться своєю думкою

Залиште ваші коментарі та побажання до даної статті в розділі Коментарі.

Ресурси для скачування

Схожі теми

Підпишіть мене на повідомлення до коментарів