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

Будь-яка архітектура, безперечно, починається зі стандартів. Мабуть, самий ємний і адекватний стандарт, а також цілий комплекс всіляких описів і визначень поставив «Національний інститут стандартів і технологій США» (National Institute of Standards and Technology) - NIST. Згідно зі стандартами NIST, хмарним може називатися тільки рішення, що володіє таким набором характеристик: самообслуговування на вимогу, широкий мережевий канал, підтримка пулів ресурсів, швидка масштабованість і еластичність, можливість вимірювання споживання сервісів. NIST визначає також три рівня архітектури - IaaS (інфраструктура як сервіс), SaaS (програмне забезпечення як сервіс) і PaaS (платформа як сервіс). З точки зору моделей розгортання Інститут також не пропонує нічого нового, розділяючи хмари на приватне, загальне, суспільне становище і гібридне.

Як я говорив на початку тексту, сьогоднішнє завдання полягає в тому, щоб визначити і зрозуміти архітектуру хмарних рішень і принципи їх проектування. Тому курс узятий на досить просту і прозору модель, дану фахівцем Microsoft Девідом Зембицький (David Ziembicki). Власне кажучи, ця архітектура не є його особистим винаходом, але він дуже докладно і, головне, без зайвих складнощів описав її в матеріалі « From Virtualization to Dynamic IT », Опублікованому ще в 2010 році в The Architecture Journal. Мабуть, текст пана Зембицький можна стиснути до наступної ілюстрації-схеми, дбайливо перекладеної на російську мову.

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

Почнемо з рівня обладнання. В архітектурі хмарного рішення рівень обладнання - найбільш важливий і базовий рівень. У нього входить все обладнання дата-центру, включаючи механічні системи, а не тільки інтелектуальні. Тут же знаходяться підсистема зберігання, мережа і обчислювальна інфраструктура. Для зв'язку з наступним рівнем - рівнем віртуалізації - в рамках кожної підсистеми передбачені інтерфейси управління. Це можуть бути сервери, що підтримують інтерфейси, СГД і так далі.

Віртуалізація є одним з ключових рівнів архітектури хмарного рішення. Як пише Девід Зембицький, віртуалізація - це критично важливий рівень архітектури, який необхідний для того, щоб досягти високого рівня зрілості ІТ-інфраструктури, проте інші рівні, такі як автоматизація і оркестрації, не менш важливі. Віртуалізація дозволяє використовувати віртуальні машини і мережі (включаючи мережі типу VLAN), дає можливість надавати ресурси зберігання, складені із загальних дисків кластерів і віртуальних дисків. Віртуалізація допомагає забезпечити значну частину обов'язкових ознак хмарного рішення по класифікації NIST. Це, як ви вже зрозуміли, підтримка пулів ресурсів і гнучкість. Крім того, ця технологія прискорює спільне використання та підготовку ресурсів до роботи.

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

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

Ще одна складова архітектури хмар - це рівень оркестрації. У чистому вигляді він практично не зустрічається, проте неможливо переоцінити його важливість для забезпечення відповідності принципам хмарних технологій NIST. Це сполучна ланка між великою кількістю технологій і процесів, які допомагають автоматизувати ІТ-інфраструктуру. По суті, цей рівень необхідний для того, щоб координувати наскрізні процеси, в яких бере участь безліч ІТ-продуктів. Рівень оркестрації створює робочі процеси і завдання по автоматизації таких непростих завдань, як розгортання кластерів, внесення виправлень на хостах і підготовка віртуальних машин до роботи.

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

Подібний чисто інструментальний підхід до опису архітектури хмарного рішення, ймовірно, зіб'є з толку частина читачів. Однак лише розуміння архітектури не тільки в контексті, а й у деталях дозволяє ІТ-фахівця заявити, що він розбирається в хмарних технологіях.