Існує безліч визначень хмарних обчислень, але найбільш ємне і широко визнане прінаджежіт Національному інституту стандартів і технологій США (National Institute of Standards and Technology, NIST). NIST визначив п'ять основних ознак, три моделі обслуговування і чотири моделі розгортання. У сукупності п'ять ознак складають визначення, тобто тільки рішення, що володіє наступними ознаками, може називатися «хмарою»:
Також в NIST визначили три моделі обслуговування, або, як іноді їх називають, рівні архітектури:
Нарешті, в NIST визначили чотири моделі розгортання:
Знайомство з хмарою
У команді Microsoft Services спроектовано, створено і реалізовано рішення Private Cloud / IaaS на базі Windows Server, Hyper-V і System Center. Протягом всіх статей цієї серії ми постараємося показати, як можна інтегрувати і розгорнути кожен складовий продукт як рішення і при цьому забезпечити такі основні атрибути хмари, як еластичність, підтримка пулів ресурсів і самообслуговування.
Як вичерпного визначення хмари ми скористаємося моделями розгортання NIST. Термін «приватна хмара» буде використовуватися в різних контекстах без вказівки даної моделі обслуговування.
Крім характеристик, описаних у визначенні NIST, ми встановимо кілька додаткових вимог до цього проекту:
В одній з команд Microsoft зібрали і визначили ці принципи. Команда оцінила роботу організації Global Foundation Services (GFS), в чиєму віданні перебувають наші глобальні ЦОД, відділу MSIT, який управляє інфраструктурою і додатками Microsoft, а також декількох великих клієнтів, які погодилися взяти участь в дослідженні. Озброївшись зазначеними визначеннями і прийнятими вимогами, ми перейшли до етапу проектування архітектури. Тут ми визначили вимоги і створили відповідну їм модель архітектури.
Базова архітектура Private Cloud / IaaS
Мал. 1. Основа базової архітектури
Рівень обладнання включає обладнання ЦОД і механічні системи, а також підсистему зберігання, мережа і обчислювальну інфраструктуру. Для взаємодії з розташованими вище шарами архітектури кожен з цих елементів повинен надавати інтерфейси управління. Як приклади можна привести сервери, що підтримують інтерфейси Web Services-Management (WS-Management) і масиви сховищ, що надають інтерфейси на основі Windows PowerShell або SMI-S (Storage Management Initiative - Specification).
У Microsoft стверджують, що програма Hyper-V Cloud FastTrack створена для об'єднання ПО Microsoft, єдиних стандартів, отриманих від партнерів OEM перевірених конфігурацій для обчислень, мереж і сховищ, а також додаткових компонентів ПО з метою створення приватних хмарних рішень. Такі компанії, як Hewlett-Packard Co. Dell Inc. IBM Corp. Fujitsu, Hitachi Ltd. і NEC Corp. є партнерами FastTrack і надають інтегровані і перевірені рішення рівня обладнання.
За рівнем віртуалізації слід рівень автоматизації (рис. 2). Рівні автоматизації, управління і оркестрації будуються від більш дрібних до більших відповідно до процесу автоматизації ІТ. Найнижчий з них - рівень автоматизації - включає технології, такі як Windows PowerShell 2.0, Windows Management Instrumentation (WMI) і WS-Management. Ці фундаментальні технології забезпечують інтерфейс між вищими рівнями систем управління і фізичними та віртуальними ресурсами.
Мал. 2. Модель архітектури, яка використовується для побудови моделі приватного хмари
В явному вигляді цей рівень зазвичай в традиційних ІТ-структурах не зустрічається, але він надзвичайно важливий для забезпечення ознак хмари. Він пов'язує безліч продуктів, технологій і процесів, що дозволяють повністю автоматизувати ІТ-процеси. System Center Configuration Manager автоматизує розгортання виправлень, але його інтеграція з системою обслуговування і управління або додатковими сторонніми продуктами і рішеннями вимагає координації (оркестрації) наскрізних процесів, в яких задіяно безліч продуктів.
Для реалізації цього рівня використовується System Center Opalis (його назва незабаром замінять на System Center Orchestrator). Opalis інтегрує набір System Center і сприяє інтеграції з безліччю сторонніх і партнерських рішень. Рівень оркестрації допомагає створювати робочі процеси або завдання по автоматизації таких складних завдань, як розгортання кластерів, внесення виправлень на хостах і підготовка віртуальних машин до роботи.
Інтерфейси самообслуговування користувачів і адміністратора
Для багатьох ІТ-організацій визначений у NIST ознака самообслуговування за запитом або призначене для користувача самообслуговування є досконалою новинкою. Перш за все, мова йде про усунення бар'єрів між потребами користувачів в ІТ-ресурсах і можливістю їх доставки. Наприклад, в деяких організаціях з моменту подання запиту на установку нового сервера до його безпосередньої готовності до роботи проходить до півроку. Обмеження процесу і технології призводять до затримок.
Функція самообслуговування вимагає нового інтерфейсу, що дає користувачам можливість запитувати ресурси. Найчастіше це реалізується як ІТ-портал самообслуговування, де користувачам доступний каталог сервісів, з якого вони можуть вибрати потрібний, наприклад установку нової віртуальної машини.
В нашій базової архітектурі ми визначили і інтерфейс самообслуговування і централізований інтерфейс адміністратора ІТ. Для створення інтерфейсу споживача Microsoft пропонує використовувати System Center Virtual Machine Manager (VMM) Self-Service Portal 2.0, а для нестандартних сценаріїв і хостингу - Dynamic Datacenter Toolkit for Hosters (DDTK-H). У нашому рішенні використовується індивідуальна версія DDTK-H зважаючи на необхідність особливої настройки і автоматизації. Ми очікуємо, що в майбутніх продуктах Microsoft буде більше готових рішень.
Інтерфейс адміністратора створений за допомогою System Center Service Manager (SCSM) і інтерфейсів System Center. SCSM - найновіший продукт Microsoft. Він надає базу даних управління конфігурацією (CMDB), а також надійне рішення управління змінами. У нашому рішенні всі стандартні операції формуються у вигляді запитів на зміни в SCSM. Вони ініціюють автоматизовані робочі процеси в Opalis. Так ми забезпечуємо належне врядування змінами, надаючи розвинені можливості автоматизації.
Логічна модель Private Cloud / IaaS
Одним з ключових відмінностей приватного хмари від традиційних ЦОД і серверних інфраструктур є абстрагування від таких фізичних ресурсів, як сервери, мережі та дискові ресурси. Вони об'єднуються на більш високому рівні в пули ресурсів, дефектні домени, домени поновлення і т. Д. Ці логічні об'єднання відносяться до фізичної інфраструктури та допомагають приймати поінформовані рішення щодо підготовки та управління ресурсами. Для нашої базової архітектури ми вибрали логічну модель, спираючись на результати робіт, проведених Microsoft Global Foundation Services, Windows Azure і MSIT (рис. 3).
Мал. 3. Логічна модель угруповання Private Cloud / IaaS
Визначення об'єктів наступні.
Структура Fabric IaaS Вся інфраструктура і системи в рамках управління базової архітектури. Fabric може складатися з безлічі сайтів і ЦОД.
ЦОД / сайт Фізичне розташування або знаходження сайту одного або більше пулів ресурсів.
Пул ресурсів Пул ресурсів, що включає сервер, мережа і сховище, надає в спільне використання загальне обладнання та вихідні конфігураційні параметри. Вони не використовують спільно єдину точку відмови з будь-яким іншим пулом ресурсів (за винятком власних потреб). Пул ресурсів можна поділити на дефектні домени, визначивши дефектний домен як групу компонентів інфраструктури із загальною для всіх конфігурацією, який не використовує спільно єдину точку відмови з будь-яким іншим дефектним доменом. Для простоти в нашому рішенні пул ресурсів і дефектний домен еквіваленти.
Одиниця масштабування Це набір, що складається з сервера, мережі та пристрої зберігання і розгортається як єдиний модуль. Це найменший модуль з тих, що розгорнуті в структурі ЦОД. Залежно від величини споживача це може бути четирехузловой кластер Hyper-V або повна стійка 64 блейд-серверів. Розмір компонента зазвичай задається, виходячи з усередненої квартальної потреби в нових ресурсах. Замість того щоб щоразу, коли будуть потрібні додаткові ресурси, розгортати окремий сервер, можна розгортати компонент для задоволення потреби і збереження можливості подальшого зростання.
Кластер хостів Це група, що включає від двох до шістнадцяти серверів Hyper-V в відмовостійкої кластерної конфігурації, і пов'язані з ними мережі і сховища.
Домен оновлень Це набір елементів інфраструктури в пулі ресурсів, який можна підтримувати, відключати або оновлювати, не викликаючи при цьому будь-яких простоїв віртуальних машин або робочих процесів, що виконуються в пулі ресурсів. У цій архітектурі кожен вузол в кожному з кластерів пулу ресурсів утворює домен оновлень. Оскільки кожен кластер має резервний вузол (15 + 1), можна підтримувати по одному вузлу в кожному кластері без простоїв (віртуальні машини мігрують за межі кластера для виконання операцій обслуговування). Так все вузли в одному пулі ресурсів утворюють один домен поновлення, такі вузли - у другому домені поновлення і т. Д. (Рис. 4).
Мал. 4. Пул ресурсів з дочірніми одиницями масштабування
Необхідність визначення і реалізації цих контейнерів обумовлена тим, що з їх допомогою можна автоматизувати інтелектуальну ініціацію і управління. Наприклад, при роботі з веб-фермою з чотирьох серверів потрібно бути впевненим у високому рівні доступності як мінімум одного з сайтів в разі збою. Треба просто подбати про те, щоб запит на ініціацію розподілявся на два сайти і два або більше пулу ресурсів. Це забезпечується визначенням пулів ресурсів і їх прив'язкою до фізичної інфраструктури. Правильна організація віртуальних машин дозволяє домогтися гнучкості сервісу.
Базова реалізація Private Cloud / IaaS
Логічне та фізичне поділ платформи управління від платформи розміщення віртуальної машини допомагає виконувати масштабування кожної з них незалежно (рис. 5). У центрі схеми на рис. 5 показані пули ресурсів в рамках системи управління та все рішення цілком, яке може бути розгорнуто в існуючому ЦОД.
Мал. 5. Логічна діаграма реалізації архітектури
Автоматизоване розгортання - один з ключових елементів базової реалізації, службовець для поліпшення і прискорення розгортання та послідовності реалізації. Це насправді так, тому що Microsoft Services працює з широким діапазоном партнерів і споживачів. Для автоматизації розгортання в базовій реалізації передбачений безкоштовний набір інструментів Microsoft Deployment Toolkit (MDT) і Microsoft Services Hydration Framework. MDT розширює можливості автоматизації розгортання.
Визначення обов'язкових областей докладного проекту - це наступний етап процесу проектування. Ось ці області:
Базова архітектура забезпечує наявність всіх ознак хмари відповідно до визначення NIST і механізм для розширеної автоматизації ІТ. При виборі сценарію автоматизації ми зосередили увагу на підвищеної складності, більш високих витратах і ризики для користувача помилок в сценаріях. З цією метою в рішенні автоматизовані наступні процеси:
установка управління структурою Fabric:
підготовка до роботи одиниці масштабування (хост-кластера):
установка виправлень одиниці масштабування (хост-кластера):
підтримка хоста:
підготовка віртуальної машини:
скасування ініціації віртуальної машини:
У наступній статті цієї серії ми вивчимо детальний проект архітектури управління структурою Fabric, включаючи проект управління структурою Fabric кластера Hyper-V, проект віртуалізованого кластера SQL і проект кожного з продуктів System Center. Крім того, ми розповімо про проект одиниці масштабування, що містить кластери Hyper-V з 16 вузлів.