Перенесення корпоративних сервісів у публічну або приватну хмару викликає багато питань. Підготували посібник про те, як підготуватися до міграції, вибрати постачальника послуг та самі застосунки для розміщення у хмарі, а також кілька рекомендацій, які допоможуть оптимізувати процес.
- Публічні та приватні хмари для бізнесу
- Міграція бізнес-застосунків у хмару: основні аспекти
- Вибір корпоративних програм для міграції в хмару
- Міграція корпоративних застосунків до публічної хмари
- Публічна чи приватна хмара?
- Критерії оцінки застосунків
- Профілювання застосунків
- Планування міграції
- Чому важливо довірити реалізацію проєкту професіоналам
- Резюме
Публічні та приватні хмари для бізнесу
Хмара являє собою модель послуг, в якій провайдер на своєму майданчику виділяє у користування клієнтів IT-ресурси на базі власного обладнання, а клієнти отримують до цих ресурсів доступ через мережу. Публічна хмара (Public Cloud), під якою ми також розуміємо IaaS або «інфраструктуру як сервіс», дозволяє використовувати сервери, сховища даних та мережеві послуги.
Особливості публічної хмари для бізнесу:
- гнучка модель оплати: лише за виділені провайдером ресурси;
- еластичність: можна швидко отримувати додаткові ресурси за запитом;
- оптимізація початкових витрат: нульові або мінімальні вкладення у розгортання IT-інфраструктури у хмарі;
- відмовостійкість та висока доступність даних: у будь-який момент сервіси доступні з будь-якої точки світу за наявності стабільного інтернет-підключення.
Компанії, які висувають підвищені вимоги до безпеки, бажають монопольно розпоряджатися виділеними провайдером IT-ресурсами або потребують індивідуальної конфігурації цих ресурсів, віддають перевагу приватній хмарі — Private Cloud. У цьому випадку вони отримують доступ не тільки до віртуальних серверів та сховища, але також до апаратної частини та гіпервізору. У приватній хмарі ви можете самостійно займатися адмініструванням та отримати більше інструментів для контролю та керування, ніж у Public Cloud.
Незалежно від вибору моделі хмарних послуг вам необхідно вирішити, які саме бізнес-застосунки ви перенесете в хмару і як реалізуєте це на практиці. Обрана стратегія та перелік сервісів, що підлягають міграції, вплинуть не лише на складність реалізації проєкту та кінцевий результат, а й на задоволеність користувачів — ваших клієнтів.
Пропонуємо розглянути організаційні та технічні аспекти міграції бізнес-застосунків у хмару.
Міграція бізнес-застосунків у хмару: основні аспекти
Деякі корпоративні сервіси стикаються зі складністю масштабування або недостатньо високою відмовостійкістю. Хоча хмара сама по собі не дозволяє подолати внутрішні обмеження на розширення або підвищити доступність додатків, міграція інфраструктури в хмару може принести вашій компанії відчутні фінансові вигоди, особливо якщо 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
Масштабованість
Найкомфортніше в хмарі бізнес-сервісам, що підтримують горизонтальне масштабування. Динамічне виділення обчислювальних ресурсів ідеально підходить для багаторівневих застосунків з функцією балансування навантаження. Вам необхідно ознайомитися з положеннями провайдера, в яких він описує порядок такого масштабування та запобігання конфліктним ситуаціям при перевищенні припустимого ліміту ресурсів.
Публічна чи приватна хмара?
Після оцінки потреби в ресурсах, сумісності платформ, можливості масштабування та інших аспектів міграції в публічну хмару може виникнути питання доцільності використання складнішого рішення корпоративного рівня — приватної хмари. Вона дозволяє залучити більше інструментів безпеки, відповідати специфічним вимогам до апаратної платформи та при певних обставинах виявляється економічно вигіднішою у довгостроковій перспективі.
Обираючи між публічною та приватною хмарою, слід детально вивчити вимоги до захисту даних, фізичної архітектури, обсягів трафіку та все те, що також може впливати на продуктивність та працездатність бізнес-застосунків.
Можливості кастомізації
Під індивідуальні вимоги клієнта та його бізнес-застосунків можна побудувати лише приватну хмару. У публічній ви отримуєте пул необхідних ресурсів із конкретними характеристиками, які не можна кастомізувати під конкретні завдання. У приватній хмарі, навпаки, можна обрати бажану кількість процесорів з певними параметрами (частота, покоління, виробник), об’єм та інші характеристики оперативної пам’яті, розміри сховища та отримати інші компоненти для своїх задач — наприклад, конкретні моделі відеокарт.
Обсяги споживаних ресурсів
У більшості випадків нераціонально переносити в публічну хмару навантаження, які генерують інтенсивний мережевий трафік через можливий вплив на них «сусідів». Аналогічна ситуація з іншими обчислювальними ресурсами — процесорною потужністю та дисковими накопичувачами. Таким чином, високонавантажені, вимогливі до якості сервісу віртуальні машини рекомендується розміщувати у приватній хмарі.
Керування даними
Окремі бізнес-застосунки регулярно обмінюються даними з локальним сховищем на стороні клієнта або зі сторонніми ресурсами. Під час оцінювання можливості міграції всі подібні взаємозв’язки мають бути проаналізовані та збережені або ж архітектура застосунку має бути перебудована з урахуванням нових вимог хмарної ІТ-інфраструктури.
Інтеграція із застарілими застосунками
Деякі сучасні бізнес-застосунки досі працюють із застарілим ПЗ, що може викликати проблеми в процесі міграції в хмару. Якщо ці залежності не можна адаптувати для роботи в хмарній IT-інфраструктурі, варто розглянути можливість міграції таких застосунків у Private Cloud.
Масштабування
Публічна хмара масштабується практично миттєво — з моменту надсилання запиту до фактичного виділення ресурсів може пройти менш як година. Приватна хмара щодо цього не така гнучка: на замовлення, постачання та введення в експлуатацію допоміжних апаратних ресурсів може знадобитися 2-3 тижні. Але можна спрацювати на випередження: спланувати масштабування та заздалегідь надіслати запит на додаткові ресурси у провайдера.
Вартість володіння
У моделі IaaS до певної конфігурації розміри регулярних платежів за порівнянних обсягів ресурсів будуть нижчими, ніж у Private Cloud. З невеликою кількістю ресурсів у останнього буде вищою сукупна вартість володіння внаслідок появи інсталяційного платежу. Якщо IT-інфраструктура досягла таких розмірів, що її доцільно виносити у приватну хмару, розмір щомісячного платежу здебільшого буде нижчим, ніж при сплаті аналогічного обсягу ресурсів у публічній хмарі.
Відповідність специфічним вимогам
В IaaS ви можете встановлювати ОС та застосунки, в той час, як у Private Cloud у вас буде прямий доступ до апаратної частини IT-інфраструктури та гіпервізору. Це важливо, якщо ви плануєте отримати більше інструментів для контролю та керування, а також самостійно займатись адмініструванням, щоб оптимізувати інфраструктуру під конкретні бізнес-задачі.
Критерії оцінки застосунків
Після вибору хмарної моделі та сервісів необхідно переконатися у відсутності технічних обмежень на міграцію та розпочати підготовку до перенесення бізнес-застосунків.
Архітектура
Від архітектури залежить те, чи підходить додаток для перенесення в хмару і яким чином буде здійснюватися міграція. Розбираємо, як різні типи архітектури впливають на міграцію застосунків у хмару.
Застосунки з багаторівневою архітектурою
Багато бізнес-застосунків створюються з використанням декількох рівнів, що дозволяє відокремити основні модулі від додаткових функцій. Так виглядає архітектура у трирівневому застосунку:
- рівень управління даними, що включає реляційні та інші компоненти баз даних;
- рівень бізнес-логіки, який використовує платформу застосунків чи контейнери (Java EE/Microsoft.NET);
- рівень подання, що відповідає за взаємодію з інтерфейсами користувача або іншими зовнішніми системами.
Застосунки з багаторівневою архітектурою можна переносити повністю або помодульно всередині кожного рівня. У будь-якому випадку кожен з них, як і компоненти всередині рівнів, необхідно оцінювати окремо, коли йдеться про перенесення в хмару. Також різні рівні застосунків можуть висувати різні вимоги до безпеки.
Вертикально- і горизонтально-масштабовані застосунки
Вертикально-масштабовану (scaling up) архітектуру мають застосунки, які можуть отримувати користь внаслідок виділення додаткових ресурсів (переважно процесорної потужності та пам’яті) на одному й тому ж сервері чи вузлі.
Горизонтально-масштабовану (scaling out) архітектуру мають застосунки, які можуть отримувати користь внаслідок збільшення кількості серверів чи вузлів. Відповідно, коли навантаження виросте, потрібно розгорнути додаткові вузли, а коли потреба в ресурсах зменшиться, невикористані сервери/вузли можна буде відключити. Такі застосунки з’явилися пізніше вертикально-масштабованих, а період їхнього активного поширення пов’язаний з масовим переходом на архітектуру х86.
Географічна доступність
Географія користувачів бізнес-сервісів буває досить широкою або, навпаки, до застосунку можуть звертатися лише з одного регіону. Це також необхідно врахувати до міграції у хмару. Щоб бути ближчим до своїх користувачів, великий бізнес може розмістити застосунки в кількох дата-центрах, розташованих у регіонах з найбільшою інтенсивністю запитів. Можливий інший варіант, коли окремі застосунки потрібно буде цілеспрямовано зробити недоступними в деяких локаціях з міркувань безпеки або інших причин. Таким чином, при виборі хмари важливо переконатися, що ви можете контролювати, оптимізувати та відстежувати їхню локацію та віддаленість від кінцевих користувачів.
Профілювання застосунків
Процедура профілювання дозволяє отримати реальну статистику про використання застосунку ще до міграції та оцінити реальні масштаби розгортання. Дані необхідно збирати протягом 10-15 днів поспіль, щоб зафіксувати всі щоденні та щотижневі відхилення від звичайного навантаження.
Вам належить зібрати дані про використання потужностей процесора, пам’яті, сховища, пропускної здатності, кількості запитів та користувачів сервісу. На рівні вузла ці дані можна буде використати для аналізу кількості та конфігурації віртуальних машин, які знадобляться у хмарі.
Додатково до збору статистики важливо виконати профілювання дій користувачів: оцінити кількість одночасно підключених клієнтів, швидкість виконання запитів та транзакцій, тривалість затримок. Ця інформація стане в пригоді для тестування роботи застосунку у хмарі та вибору оптимальної конфігурації хмарних ресурсів на основі результатів тесту, а також прогнозування витрат на хмарну IT-інфраструктуру.
Планування міграції
Останнім етапом буде розробка робочого плану та безпосередньо сама міграція даних у хмару. Складність його реалізації безпосередньо залежатиме від типу застосунків та вимог до безперервності їх виконання. Якщо навіть мінімальний час простою критичний для бізнесу, бажано розбити процес міграції на кілька етапів так, щоб на будь-якому з них застосунки залишалися доступними. Перенесення до хмар першої частини сервісів буде тестовим. Використовуючи заздалегідь підготовлений план тестування та автоматичні тести, можна змоделювати дії різних типів користувачів та навантажень на додаток. За результатами буде зрозуміло, на яку кількість хмарних ресурсів вам необхідно надіслати запит до провайдера.
Чому важливо довірити реалізацію проєкту професіоналам
Аналіз, вибір оптимальної моделі хмари, розробка плану міграції та поетапне перенесення застосунків у хмару можуть виявитися складним завданням для компанії, в якій IT не є профільним напрямком. Тоді реалізацію даного проєкту слід довірити професіоналам, які накопичили велику експертизу та досвід у задачах подібної до вашої, а також розуміють, як саме застосунки взаємодіють один з одним, зовнішніми ресурсами та базовою IT-інфраструктурою.
З 2010 року команда сертифікованих фахівців Colobridge накопичила великий практичний досвід у питаннях міграції у хмару і не зупиняється на здобутому: співробітники регулярно підвищують компетенції та актуалізують знання. Вони виконають комплекс робіт з перенесення IT-інфраструктури та даних у публічну або приватну хмару, а також забезпечать цілодобову підтримку кількома мовами включно з українською та російською.
Резюме
Під час вибору хмарної моделі, оцінювання застосунків та плануванні їхнього перенесення в хмару необхідно враховувати безліч факторів. Насамперед проаналізуйте самі застосунки та їх сумісність з різними типами хмарних моделей. Після цього складіть плани міграції та тестування на кожному етапі перенесення даних. Хоча універсального підходу до міграції у хмару не існує, підготовлена командою наших експертів інформація допоможе зробити цей процес максимально м’яким та безболісним для вашого бізнесу, мінімізувати ризики простою застосунків та на виході отримати очікувані результати. Платформа Colobridge ідеально підходить для розміщення будь-яких IT-застосунків та пропонує більше, ніж альтернативні майданчики, у тому числі дозволяючи реалізувати передові галузеві рішення від двох незалежних географічно віддалених дата-центрів класу Tier III+ із рук єдиного провайдера.
