Докладний опис можливостей розробки Microsoft Azure Cloud Services



Поговоримо сьогодні про одне з фундаментальних сервісів платформи Microsoft Azure — Cloud Services.

Основна ідея Cloud Services полягає в реалізації багаторівневого розв'язання за допомогою одного або декількох веб-ролей і робітників ролей (web-роль, worker-роль) для розподіленої обробки запитів або даних.

Отже, ввідний визначення: Cloud services (Хмарні служби) Microsoft Azure — це можливість створювати багатокомпонентні додатки, кілька переосмислені в бік рольової моделі і гнучкого масштабування.

Наприклад, при збільшенні навантаження можна масштабувати тільки обробник на стороні сервера, але залишити кількість примірників веб-фронтенда.

Примітка:
Загальні моменти і основні відмінності між Cloud Services Web Sites, яким чином реалізує ту або іншу функцію або сценарій кожна зі служб можна подивитися в статті Порівняння сайтів Azure, хмарних служб і віртуальних машин на російському і на англійській мовою.
Архітектура Cloud Services і ролі



Розглянемо принцип рольової моделі на основі типового Web-додатки, написаного з використанням MVC (Model-View-Controller).
  • Подання (Web-інтерфейсу);
  • Контролер (Шар бізнес-логіки);
  • Шар доступу до джерела даних.


Доступ до додатка здійснюється по кінцевій точці доступу (HTTP або HTTPS).

  • Подання змінює свою назву на Web-роль;
  • Контролер — Worker-роль;
  • Шар доступу до джерела даних може бути реалізований всередині окремої Worker-ролі.


Для отримання даних від подання (Webролі) обробником-контролером (Worker-роллю) традиційно використовується Middleware у вигляді сервісу черг.

При цьому в якості Middleware може виступати наприклад Microsoft Azure Storage Queue або Microsoft Azure Service Bus.

Використання Middleware є прекрасним прикладом розробки відмовостійких розподілених додатків.
Замість розробки тісно пов'язаної системи, для якої втрата одного з компонентів (наприклад, Web-ролі) буде означати непрацездатність всієї системи і втрату даних розробник може використовувати Middleware в режимі брокера (Brokered Messaging).

Це означає, що Web-роль просто кладе повідомлення в сервіс Middleware (чергу), де вони зберігаються до тих пір, поки ними не займеться збирач сміття, або поки вони не обработаются примірниками Worker-ролі.

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

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

Як видно на малюнку архітектури Cloud Services, кожна з ролей існує у певній кількості примірників, які виконують одну й ту ж функцію ролі.

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

Нижче детально описано типи ролей і їх основні характеристики:



  • Web-роль. Web-роль містить набір примірників-серверів з віртуальними машинами, на яких встановлено IIS 7/7.5 і за замовчуванням відкриті кілька стандартних портів доступу з HTTP. Безпека Web-ролі забезпечується сертифікатом, прив'язаним до будь-якій точці входу HTTPS.
  • Worker-роль. Worker-роль містить набір примірників-серверів з віртуальними машинами, на яких виконується бізнес-логіка, зазвичай отримує дані для своєї роботи з Web-ролі.
    За замовчуванням вхідні підключення до віртуальної машини на примірнику Worker-ролі, заборонені.
    Проекти Worker-ролей використовують таку програмну модель — наследуясь від RoleEntryPoint, клас, виконує бізнес-логіку Worker-ролі, реалізує три методу:
    1. OnStart() — викликається при запуску ролі, повертає статус «Busy» балансировщику навантаження до тих пір, поки не зазначено інше;
    2. Run() — виконується постійно, містить основну логіку;
    3. OnStop() — виконується при відключенні ролі, 30 секунд і може бути використаний для закриття підключень, видалення об'єктів і т. д.


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

Конфігурація Cloud Service
Для опис конфігурації, під Cloud Services будемо розуміти проект, тобто набір файлів, який описує хмарний сервіс. Цей проект можна використовувати в Visual Studio.

Отже, конфігурація складається з двох XML-файлів:

  • Файл визначення сервісу (Service Definition file, з розширенням .csdef). Задає параметри Microsoft Azure для налаштування хмарної служби (опис ролей, точки входу та налаштування конфігурації без заданих значень).
  • Файл конфігурації сервісу (Service Configuration file, з розширенням .cscfg). Містить безпосередні значення для різних параметрів, наприклад, кількість екземплярів-серверів, які будуть обслуговувати конкретну роль.
У файлах конфігурації Microsoft Azure також є можливість задати два параметра, що вказують версію операційної системи, яка буде обслуговувати розгорнутий сервіс. Перший параметр — «сімейство» операційної системи, атрибут osFamily, другий osVersion — «версія» операційної системи.

Сервіс Microsoft Azure, отримав дану настройку здійснює пошук конкретного образу операційної системи певного розробником сімейства. Стандартне значення цієї настройки «*», що означає, що сервіс буде запущено на новій версії операційної системи і буде оновлюватися по мірі виходу нових версій.

Обидва конфігураційних файлів при розгортанні рішення Cloud Service Microsoft Azure обробляються спеціальним автоматичним сервісом Azure Fabric, який, ґрунтуючись на цих файлах, виробляє пошук вільних ресурсів, які відповідають конфігурації, ініціює створення і встановлення віртуальних машин і подальше розгортання рішення.

Тому правильна налаштування конфігураційних файлів має велике значення при розгортанні в хмару.

Оточення
Кожен примірник Сloud Services надає розробнику два розташування для розгорнутого рішення — Production та Staging, які використовуються для варіанту, що працює в реальному середовищі, і рішення, розгорнутого для тестування, відповідно.



У процесі розгортання розробник проводить налаштування того розташування, в якому буде розгорнуто його рішення.
Ці розташування, називаються осередками розгортання і відрізняються ттільки доменним ім'ям і внутрішніми правилами маршрутизації.

Для Production-осередки налаштовується DNS-ім'я, вказане розробником при створенні Cloud Service, наприклад, http://appname.cloudapp.net, для Staging ж створюється тимчасове DNS-ім'я наступного типу http://[guid].cloudapp.net.

Після успішного тестування рішення в Staging, розробнику не потрібно розгортати рішення Production, досить на порталі управління ініціювати процедуру VIP Swap, яка свою чергу відправить запит балансировщику навантаження для того, щоб «поміняти місцями» VirtualIP, що використовується для розгортання.

Таким чином, без переносів і міграцій, за кілька хвилин рішення з Staging-комірки переходить в Production.

При виявленні помилок у клітинці Production, процедура VIP Swap може бути ініційована повторно для продовження тестування рішення в Staging-клітинці, яка до речі не доступна користувачеві.



Масштабування Cloud Service
Microsoft Azure Cloud Services існує можливість автоматичного масштабування на основі завантаження CPU або поточного кількості повідомлень в черзі сховища Microsoft Azure.

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

Щоб налаштувати автоматичне масштабування хмарного сервісу, необхідно вказати період очікування (у хвилинах) перед кожною зміною масштабу.



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

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





Часто при масштабуванні ролі вигідно масштабувати також і базу даних, яка використовується додатком. Якщо база даних пов'язана з хмарної службою, можна змінити версію і розмір бази даних SQL на порталі управління.



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

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



Також можлива установка додаткового програмного забезпечення, яке називається WASABi, для здійснення автомасштабирования без участі порталу управління Azure, з допомогою REST API.

Azure Tools for Visual Studio
Пакет інструментів Microsoft Visual Studio корисний розробникам для створення, управління, запуску і розгортання Web-додатків в Microsoft.

Пакет містить в собі шаблони проектів (Web-ролі, Worker-ролі і т. д.), можливості віддаленої налагодження та створення віртуальних машин, Emulator Express, розширення інтерфейсу Visual Studio, розширення Storage Explorer і Server Explorer, інтегроване розгортання за допомогою Web Deploy в хмару, IntelliTrace і інше.

Останній випуск Azure Tools підтримується наступними версіями Visual Studio:

  • Visual Studio 2012
  • Visual Studio 2013
  • Visual Studio Express 2012 для Web
  • Visual Studio Express 2013 Web


Microsoft Azure SDK
Для забезпечення функціональності, яку розробник використовує локально, необхідний Azure SDK. Azure SDK не включений в .NET Framework за замовчуванням і встановлюється окремо.

Основні компоненти Azure SDK — емулятор обчислень і сховища, необхідний для запуску, налагодження і тестування Cloud Services на локальному комп'ютері, що дуже зручно в умовах відсутності підключення до Інтернету.

Емулятор обчислень надає графічний інтерфейс для виконання базових завдань з управління і перегляду діагностичних логів робочого рішення Cloud Service.



Нижче перераховані деякі відмінності між рішенням, запущеним в емуляторі, і запущеним в хмарі, що означає необхідність тестування деяких частин рішення саме в хмарі:

  • Емулятор підтримує обмежену кількість ролей і примірників. Максимальна кількість ролей на розгортання дорівнює 50.
  • Емулятор надає запущеним рішенням адміністраторські права, тоді як рішення, запущене в Azure, за замовчуванням не має адміністраторських прав.
  • Емулятор не моделює повністю балансування навантаження.
  • Емулятор використовує IIS Express, а в Azure — IIS.
  • емулятор обчислень всі ролі виконуються на локальному комп'ютері, тоді як в Azure виконуються на окремих віртуальних машинах.
Повний перелік відмінностей доступний за наступною посилання.

Емулятор сховища забезпечує локальне середовище, для моделювання трьох сервісів сховища Azure на локальному комп'ютері — блобов, таблиць і черг. Основним механізмом локального емулятора сховища є SQL Server.

Зараз графічний інструмент емулятора вважається застарілим і в майбутньому буде виключено з SDK. Доступ до функцій емулятора тепер забезпечує командний рядок.

Антивірус для Cloud Services
Не так давно компанія Microsoft представила антивірус для хмарних сервісів Microsoft, забезпечує захист у реальному часі або за розкладом, а так само надає збір інформації про атаки вашого облікового запису через Microsoft Diagnostics.

Антивірус в Azure побудований на тій же платформі, що і Microsoft Security Essentials [MSE], Microsoft Forefront Endpoint Protection, Microsoft System Center Endpoint Protection, Windows Intune, і Windows Defender для Windows, 8.0 і вище. І призначений для роботи у фоновому режимі.

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

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

Нижче представлена загальна схема забезпечення роботи інструменту антивіруса Microsoft Azure для хмарних сервісів і віртуальних машин:



Корисні посилання


Джерело: Хабрахабр

0 коментарів

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