віртуальні Операційні системи в хмарі. Витрати та переваги

У цій статті старший ІТ-архітектор COMPAREX AG Ерік Берг розповість про використання віртуальних машин у хмарі, переваги та супутніх витратах.

Віртуальні машини є частиною рішень «Інфраструктура як послуга» Azure. За великим рахунком, немає суттєвих відмінностей між віртуальними системами в Azure та іншими системами, які розміщуються у спеціальному центрі зберігання і обробки даних (ЦОД) компанії. Всі вони мають певний комплект апаратного обладнання (CPU, RAM, HDD, мережа) і операційну систему. Тим не менш, віртуальні машини, використовувані Azure, строго стандартизовані з метою оптимізації ресурсів і витрат.

Приклади класів:
Клас ВМ Ядра CPU RAM HDD #
A2 2 3,5 ГБ 4
A11 Intel Xeon E5-2670 16 ядер @ 2,6 ГГц 112 ГБ 16
D4 8 28 ГБ 400 GB local SSD
G5 32 448 ГБ 64
6596 GB local SSD

Витрати
Будь-яке категоричне припущення про те, що управління віртуальними машинами в Azure призведе до скорочення витрат, найімовірніше, є помилковим. Кількість витрат, що виникають у зв'язку з використанням ВМ у Azure, дорівнює витратам, пов'язаним з використанням спеціального ЦОД.

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

Саме такого роду гнучкість надає цінність віртуальним машинам, використовуваним в Azure. Більш того, при використанні віртуальних машин, користувач може не використовувати своє власне апаратне обладнання.

Тестування/Розробка
Системи експлуатаційного тестування або розробки програм є ідеальним сценарієм використання ВМ Azure, оскільки початкові переваги одразу ж проявляють себе навіть на базовому рівні.

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

Угода про рівень обслуговування (SLA)
Питання доступності є ключовим для виділення віртуальних машин в Azure. Для того щоб пролити світло на це питання, важливо зрозуміти те, яким чином структуровані центри зберігання і обробки даних і де розміщуються ВМ.

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

Не варто забувати, що системи, запущені в одному і тому ж домені збою та / або оновлення, при певних обставинах можуть піддаватися одночасного збою!
Саме тому SLA не укладаються в якій би то не було формі для окремих ВМ у Azure. Для того щоб отримати гарантовану доступність, необхідно використовувати, як мінімум, дві віртуальні машини в одній групі доступності. Так система налаштована таким чином, щоб гарантувати управління пропонують однакові послуги ВМ на провідних ЕОМ. Таким чином, у групі доступності завжди буде функціонувати щонайменше одна віртуальна машина.


Угода про рівень обслуговування для віртуальних машин в Azure.

Поставка
В каталозі Azure доступні кілька шаблонів для постачання віртуальних машин. Шаблони насправді являють собою зображення ВМ, які Microsoft регулярно оновлює. Вони включають операційні системи Windows Server, а також Ubuntu або CentOS.

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

Насамперед, можлива міграція 1:1 віртуальних машин, які колись використовувалися локально в Azure. Тут, локальний файл VHD переміщається в обліковий запис зберігання Azure, з якої він може бути запущений за допомогою ВМ Azure.


Міграція ВМ у Azure

Існує ще один метод зберігання зображень ВМ в каталозі. Тут віртуальна машина і всі її параметри можуть бути підготовлені в локальному середовищі. Система готується до розгортання за допомогою утиліти Sysprep, і після завершення всіх конфігурацій створюється відповідне зображення. Потім дане зображення завантажується в Azure і використовується для створення нових ВМ.


Завантажити власне зображення в Azure

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


Створіть власне зображення в Azure

В ув'язненні
Віртуальні машини Azure, які виступають в якості невід'ємних елементів рішення IaaS можуть вільно використовуватися, при цьому витрати будуть тільки в період їх фактичного використання. Це створює численні сценарії, за якими модифікації/поставки можуть привести до помітного зменшення витрат. Тим не менш, всі можливі сценарії мають одну загальну рису: апаратне та інше обладнання можна не задіяти. Внаслідок цього користувачі зосередять свою увагу на дійсно головному – віртуальних машинах.
Джерело: Хабрахабр

0 коментарів

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