Як спланувати міграцію бізнес-застосунків у хмару. Частина перша

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

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

Розглянемо організаційні та технічні аспекти міграції бізнес-застосунків у хмару.

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

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

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

Звідки можна мігрувати бізнес-застосунки:

• окремий сервер (малий і середній бізнес);
• побудований клієнтом дата-центр (великий бізнес);
• орендований клієнтом сервер (локально чи у дата-центрі);
• сервер, розміщений у локально розгорнутій хмарі;
• SaaS-сервіс (імпорт або перенесення даних).

Куди саме у хмару можна мігрувати бізнес-застосунки:

• у загальнодоступну хмару;
• у приватну хмару;
• у гібридне середовище: комбінація приватної та загальнодоступної хмари.

Можливі окремі випадки перенесення даних. Наприклад, міграція типу P2V (Physical-to-Virtual), коли фізичний сервер повністю переноситься у віртуальне середовище включно з операційною системою, застосунками та їхніми даними. Існують спеціальні програмні рішення (конвертери), що дозволяють автоматизувати процес такої міграції та скоротити кількість помилок, які можуть виникнути при цьому. Якщо ж додаток був розміщений на віртуальному сервері, його достатньо змігрувати/конвертувати.

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

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

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

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

Після визначення списку застосунків-кандидатів на перенесення у хмару необхідно детально вивчити технічні та організаційні аспекти міграції. Зробимо це на прикладі Public Cloud, який пропонують постачальники послуг у вигляді продукту з назвою IaaS (Infrastructure as a Service).

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

Що слід передбачити та вивчити до міграції IT-інфраструктури у публічну хмару?

Перш за все звернемо увагу на договір та SLA.

Необхідно зрозуміти, який рівень доступності гарантує постачальник послуг та яку фінансову відповідальність несе у разі невиконання зобов’язань. Тут важливо розрізняти доступність IT-інфраструктури (сервери, системи зберігання даних) від доступності мережної інфраструктури та доступності сервісів самого дата-центру, що обов’язково підтверджується сертифікатами. Якщо для ЦОД, розташованих у США, оцінити надійність можна за рівнем Tier (класифікація Uptime Institute), то якість роботи та надійність європейських дата-центрів зазвичай підтверджують відразу кілька сертифікатів: ISO/IEC 27001:2005, ISAE3402/SSAE16, ISO 9001, ISO/IEC 27001:2005 та інші.

На що ще варто звернути увагу у договорі та SLA:

• які послуги адміністрування можна запросити у провайдера;
• на яких умовах надається підтримка апаратного забезпечення, адміністрування віртуальних машин, ОС та окремих застосунків;
• які рівні обслуговування діють для конкретних продуктів і від чого вони залежать (варіанти: від локації дата-центру, типу дисків і віртуальних машин тощо);
• на які випадки не поширюється гарантія постачальника послуг;
• процедура виплати компенсації та її розміри у разі порушення SLA.

Важливо також звернути увагу на роботу БД на новій платформі.

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

У більшості випадків розгортання застосунків у публічній хмарі дозволяє бізнесу оптимізувати витрати на ІТ-інфраструктуру. Це можливо завдяки переходу від моделі фактичного володіння IT-інфраструктурою (капітальні витрати, CapEx) до оплати необхідних ресурсів за підпискою (операційні витрати, OpEx). Однак для застосунків, які повинні бути доступні постійно і вимагають великих обсягів обчислювальних ресурсів, довгострокова вартість володіння в публічній хмарі може виявитися вищою, ніж вартість розгортання та подальшої підтримки приватної хмари.

Ще одне важливе питання – управління безпекою та надійністю зберігання.

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

Деякі провайдери пропонують додаткові послуги для підвищення надійності та відмовостійкості клієнтської IT-інфраструктури. Прикладами таких послуг можуть бути BaaS та DRaaS.

BaaS («бекап як сервіс») дозволяє комплексно керувати створенням, зберіганням та відновленням даних із резервних копій. Провайдер надає відповідне за обсягом сховище на базі свого дата-центру, а також спеціалізоване ПЗ, яке дозволяє значною мірою автоматизувати роботу з бекапами та додатково убезпечити дані від випадкового чи навмисного видалення. Це може статися внаслідок несправності або вилучення обладнання, кібератак, пожеж та інших стихійних лих на майданчику клієнта, а також людського чинника.

DRaaS («аварійне відновлення як сервіс») дозволяє в стислі терміни та максимально ефективно відновлювати IT-інфраструктуру після серйозного збою з копії, що зберігається у хмарному репозиторії на боці провайдера. Замовник отримує ПЗ для синхронізації даних, а також допомогу в підготовці та реалізації плану аварійного відновлення.

Принцип роботи сервісу BaaS:

Джерело: veeam.com

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

У наступній частині ми розглянемо ще низку важливих питань у контексті піднятої теми – «Обсяги споживаних ресурсів», «Вартість володіння», «Профілювання застосунків» та ін.

Ready, set, buy! Посібник для початківців - як придбати Copilot для Microsoft 365