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

Говорити про гібридну інфраструктуру можна лише тоді, коли окремі хмарні та серверні моделі використання обчислювальних послуг взаємопов’язані та працюють у синергії. Для встановлення взаємозв’язків використовуються кілька технологій: VPN (віртуальна приватна мережа), WAN (глобальна мережа) та доступ до API (інтерфейс прикладного програмування).

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

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

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

Добре якщо принципи ціноутворення дозволяють виконувати бюджетування на рік уперед (для послуг Colocation).

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

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

Якщо у вас є чим доповнити що до SLA, буду вдячний. А наступного разу поговоримо про таку тему, як перелік доступних послуг та служба техпідтримки.

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

Публічна чи приватна хмара?

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

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

Можливості кастомізації

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

Обсяги споживаних ресурсів

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

Керування даними

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

Інтеграція із застарілими застосунками

Деякі сучасні бізнес-застосунки досі працюють із застарілим програмним забезпеченням, що може викликати проблеми в процесі міграції в хмару. Якщо ці залежності не можна адаптувати для роботи в хмарній 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-інфраструктури та даних у публічну або приватну хмару, а також забезпечать цілодобову підтримку кількома мовами включно з українською.

Резюме

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

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

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

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

Деякі корпоративні сервіси стикаються зі складністю масштабування або недостатньо високою відмовостійкістю. Хоча хмара сама не дозволяє подолати внутрішні обмеження на розширення або підвищити доступність застосунків, компанія може отримати відчутні фінансові вигоди від міграції в хмару, особливо якщо раніше 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-інфраструктуру після збою та повернути працездатність бізнес-додатків й цифрових сервісів. Щоб реалізувати це на практиці, зазвичай необхідні значні матеріальні та людські ресурси. З огляду на складність реалізації та вартість технічного рішення прийнятним для багатьох компаній може виявитися те, що називають Disaster Recovery, або аварійним відновленням.

Що таке Disaster Recovery

Disaster Recovery (або просто DR) – це набір інструментів та спеціалізоване програмне забезпечення, які вкупі допомагають швидко відновити IT-інфраструктуру, а також дані, роботу всіх систем та сервісів після збою.

Скільки коштують скомпрометовані або вкрадені дані:

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

Способи організації Disaster Recovery

У бізнеса є щонайменше три способи реалізувати післяаварійне відновлення IT-інфраструктури. Розглянемо кожен із них.

Зробити самостійно на своїй інфраструктурі

Варіант із розгортанням резервного майданчика on-premise, тобто на локальному майданчику – найбільш трудомісткий та дорогий. У цьому випадку компанії фактично доведеться збудувати інфраструктуру, яка дублює основну. А це пов'язане не лише з великими капітальними витратами, а й з необхідністю залучення фахівців із вузькими компетенціями.

Побудувати Disaster Recovery на орендованих фізичних серверах

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

Розгорнути Disaster Recovery у хмарі

Хмарна інфраструктура, навпаки, приваблює своєю гнучкістю та простим масштабуванням. Тому багато компаній із сегмента SMB вважають за краще розгортати резервні копії IT-інфраструктури на хмарних платформах. Великий плюс у тому, що у хмарі можна прозоро керувати обсягом ресурсів, необхідних для виконання Disaster Recovery: резервувати продуктивне сховище для копії IT-інфраструктури разом із пулом необхідних потужностей для її розгортання або користуватися лише сховищем, а віртуальні ресурси отримати за фактом (втім, без гарантій з боку провайдера, що необхідні ресурси будуть доступні в потрібний момент).

Disaster Recovery as a Service

DRaaS (Disaster Recovery as a Service) є післяаварійним відновленням за моделлю «як послуга». У разі серйозного збою сисадмін за лічені хвилини зможе розгорнути у хмарі робочу копію IT-інфраструктури на резервному майданчику Disaster Recovery, наданому провайдером. Одночасно на основному майданчику розпочнуться відновлювальні роботи відповідно до заздалегідь розробленого плану післяаварійного відновлення (Disaster Recovery Plan). Іншими словами, сервісна модель Disaster Recovery – клонування інфраструктури в хмару у разі настання аварії та до її усунення на основному майданчику.

Головні переваги DRaaS перед іншими способами реалізації Disaster Recovery:

• швидке відновлення інфраструктури даних;
• оптимізація витрат на післяаварійне відновлення ІТ-інфраструктури;
• можливість реплікації «гарячих даних» як реального часу;
• гнучкі умови ліцензування спеціалізованого ПЗ провідних вендорів;
• після відновлення з архіву дані зберігають консистентність;
• просте масштабування рішення у хмарі.

Характеристики Disaster Recovery

На терміни та вартість післяаварійного відновлення впливають дві ключові характеристики – RTO та RPO. Що вони означають та на що впливають?

RTO

RTO (Recovery time objective, або «цільовий час відновлення») – це часовий проміжок, протягом якого IT-інфраструктура залишатиметься недоступною у разі аварії чи іншого інциденту. Допустиме значення RTO визначається специфікою та потребами бізнес. Фактично це час, протягом якого цифрові послуги компанії можуть простоювати без відчутних наслідків. Чим менше значення RTO, тим дорожче обійдеться послуга Disaster Recovery.

RPO

RPO (Recovery point objective, або «цільова точка відновлення») – це часовий проміжок, дані за який можуть бути втрачені без серйозних наслідків. Наприклад, для RPO, що дорівнює одній годині, резервне копіювання виконується чітко один раз на 60 хвилин. Так само й IT-інфраструктура після відновлення повернеться до того стану, в якому була за годину або менше до аварійного інциденту (на практиці багато залежить від того, коли саме стався збій – через 5, 15, 30 або 55 хвилин після створення копії). Чим меншим є значення RPO, тим частіше виконується резервування IT-інфраструктури та дорожче коштує DR-сервіс відновлення.

Визначити оптимальні значення RTO та RPO – означає знайти компроміс між вартістю вирішення післяаварійного відновлення та серйозністю наслідків простою для бізнесу.

Щоб визначити оптимальні параметри RTO/RPO, достатньо відповісти на два основні питання: чи будуть для вашого бізнесу актуальними дані тижневої/місячної давності, та втрату даних за який період ваш бізнес може пережити? (наприклад, за годину, добу, тиждень або інший час).

Згідно зі статистикою Colobridge, найчастіше клієнти обирають варіант робити резервне копіювання один раз на добу і переважно в нічний час – коли їх IT-системи найменш навантажені, а також зберігають останні сім архівних копій. Тоді максимальний обсяг даних, що теоретично може втратити бізнес, відповідає одному робочому дню. У такому сценарії розміри репозиторію в 1,3-1,4 рази перевищуватимуть обсяг зайнятих даних. Наприклад, віртуальна машина розмірами 100 ГБ займе у репозиторії до 140 ГБ.

Кому потрібний Disaster Recovery?

Зазвичай до послуги Disaster Recovery вдаються компанії, які прагнуть додатково захистити свою IT-інфраструктуру і готові виділити на це певну частку бюджету. Colobridge рекомендує послугу Disaster Recovery as a Service насамперед для корпоративного сектору – зокрема, клієнтам із фінансового та банківського сектору, інтернет-магазинам, аграрним компаніям та будь-яким іншим, у яких від доступності та стабільної роботи їх цифрових сервісів безпосередньо залежать доходи та репутація бізнесу.

Disaster Recovery у банківській сфері

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

Disaster Recovery у сфері обслуговування

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

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

Чим відрізняються бекапи від Disaster Recovery?

Сервіси створення бекапів (наприклад, BaaS – Backup as a Service) передбачають використання хмарного репозиторію тільки для зберігання архівних копій, тоді як з DRaaS клієнт отримує сервіс дзеркалювання у хмарі провайдера IT-інфраструктури та можливість запускати віртуальні сервери в автоматичному режимі, якщо виникне аварійна ситуація.

DRaaS має значну перевагу перед BaaS: він дозволяє швидко включити необхідну точку, щоб як велика, так і невелика компанія якнайшвидше і бажано непомітно для клієнтів повернулися до нормального режиму роботи. Це стає можливим завдяки тому, що дані розміщуються на продуктивному сховищі замість того, щоб зберігатися в заархівованому вигляді, як у випадку з BaaS. Крім того, хмарний провайдер Disaster Recovery as Service пропонує більше налаштувань, можливість гнучкого керування частотою створення (за розкладом) та параметрами відновлення віртуальних машин із резервних копій.

Реплікація IT-інфраструктури у хмару за допомогою DRaaS зовсім не означає відмову від традиційних бекапів. Клієнти можуть користуватися цими двома інструментами одночасно: «гарячі дані» копіювати раз на кілька годин і зберігати протягом двох-трьох днів, а копії «негарячих систем» робити щодня та зберігати їх, наприклад, тиждень. Налаштування інфраструктури в концепції Disaster Recovery компанія робить відповідною під свої вимоги.

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

За оцінками експертів McKinsey, у найближчі три роки глобальні витрати на перенесення даних у хмару сягнуть 100 млрд дол.

Бізнес прагне більш ефективно використовувати публічні хмари, але часто не може досягти успіху, тому що стикається з проблемами у процесі міграції даних та на пізніших етапах. Очікується, що до 2024 року більшість компаній витрачатиме на оплату IaaS, PaaS або SaaS до 80% бюджету, закладеного на розміщення IT-ресурсів. Однак для цього будуть потрібні певні зусилля з боку самого бізнесу та постачальників хмарних технологій.

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

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

З 2019 до 2021 року бізнес переніс близько 45% витрат на IT в хмару. Майже дві третини (65%) опитаних керівників повідомляли, що їхні компанії збільшили свої хмарні бюджети під час пандемії, а 55% – що розмістили більше робочих навантажень у хмарі, ніж планували спочатку. В абсолютній більшості випадків «хмарна історія» довела свою ефективність на практиці, тому ще 40% компаній планують прискорити темпи міграції до публічних хмар у майбутньому.

До 2024 середньостатистична компанія витрачатиме на хмарні продукти до 80% бюджету, виділеного на розміщення робочих навантажень.

Очікується, що з 2021 по 2024 роки у публічній хмарі витрати на розміщення вертикально масштабованих додатків (управління складом у роздрібній торгівлі, управління корпоративними ризиками в банківській сфері та іншими) щороку зростатимуть більш ніж на 40% порівняно з витратами на розміщення горизонтально масштабованих програм (наприклад, платформи для взаємодії з клієнтами). А компанії у сфері охорони здоров’я та виробництва планують витрачати приблизно вдвічі більше на вертикальні програми, ніж на горизонтальні.

Попри те, що компанії переносять дедалі більше робочих навантажень в публічну хмару, помилки в міграції, як і раніше, призводять до невиправданого зростання матеріальних витрат. За даними McKinsey, середньостатистична компанія щорічно витрачає на міграцію в хмару на 14% більше запланованого, а 38% організацій зіткнулися з тим, що перенесення даних на cloud-платформу зайняло як мінімум на 25% більше часу, ніж планувалося спочатку.

У глобальному масштабі підвищення витрат на 14% виражається в сотнях мільярдів доларів. Якщо не контролювати витрати в цьому напрямку, протягом трьох років вартість компаній, що зіткнулися з цією проблемою, може скоротитися більш як на 500 млрд дол.!

Більшість компаній до 35% своїх потреб в управлінні хмарними ресурсами задовольняють коштом залучення штатних IT-фахівців. Проте їхня частка зросте до 50% вже 2024 року. Це означає, що бізнес по всьому світу найближчим часом прагнутиме найняти або перекваліфікувати не менше 1 млн експертів у хмарних обчисленнях. Підвищений попит, мабуть, викличе ще більший дефіцит персоналу з відповідними навичками. Частково розв'язати цю проблему можна залученням системних інтеграторів.

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

Аналіз показав, що серед тих, хто досяг успіху в питаннях міграції на cloud-платформи, на 32% частіше зустрічаються активно залучені до процесу керівники. У них на 9% більше шансів розробити детальну дорожню карту міграції та на 57% – найняти фахівців з необхідними навичками.

Хмарний продукт «інфраструктура як сервіс» та оренда виділеного сервера – дві популярні послуги, які мають і схожість, і принципові відмінності. В них по-різному реалізовано порядок виділення ресурсів, відрізняється вартість володіння і рівень контролю IT-інфраструктури. Як зробити обґрунтований вибір з урахуванням бюджету та поточних бізнес-потреб?

Головне про послуги IaaS та Dedicated Server

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

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

«Інфраструктура як сервіс» – це хмарна послуга, що орієнтована на клієнтів, які:

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

В разі Dedicated Server клієнт орендує повністю апаратно-програмний комплекс, що розташований на території ЦОД провайдера. Додатково до виділених серверів можна орендувати мережеве обладнання, СЗД та ПЗ, а також придбати послуги за сервісною моделлю (as a Service), наприклад Firewall as a Service. З Dedicated Server клієнт отримує доступ до обладнання Enterprise-рівня провідних світових вендорів: Dell, HPE, SuperMicro, Cisco, Juniper, Brocade та інших.

Глобальний ринок Dedicated Server зростає швидкими темпами: за даними IDC, до 2025 року він перевищить 7,6 млрд дол, щороку зростаючи в середньому на 150%.

IaaS та Dedicated Server: чим схожі ці продукти?

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

Принципові відмінності між IaaS та Dedicated Server

Ізоляція. В Dedicated Server вплив «сусідів» виключено, тому що обладнання та дані ізольовані. В IaaS такий вплив теоретично можливий у невеликій кількості випадків, але постачальники послуг постійно працюють над тим, щоб його мінімізувати.

Швидкість введення в експлуатацію. В IaaS користуватися ресурсами у хмарі для розміщення IT-інфраструктури можна вже протягом найближчих кількох годин (максимум доба) після укладення договору. В Dedicated-моделі – через кілька днів або тижнів, якщо клієнт замовив нестандартну конфігурацію та обладнання для неї буде поставлятися за індивідуальним замовленням.

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

Можливості кастомізації. Вони практично безмежні в Dedicated-послузі, але обмежені в моделі «інфраструктура як сервіс». У ній клієнт не може змінювати конфігурацію хмари на запит – наприклад, замість процесорів Intel вибрати AMD.

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

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

Dedicated Server та IaaS: основні помилки при виборі

Іноді здається, що під ваші завдання ідеально підходить IaaS, але на практиці виявляється, що Dedicated Server краще відповідає потребам бізнесу та навпаки. У фахівців Colobridge є кілька подібних кейсів. Чому таке трапляється та коли дійсно має сенс переглянути рішення про вибір?

Не був проведений аудит поточних навантажень. Через це ви первісно неправильно оцінили навантаження на бізнес-додатки. Ситуацію можна легко виправити, якщо врешті решт ви виберете IaaS, але це критично для клієнтів послуги Dedicated Server. В останньому випадку не варто розраховувати на оперативну зміну конфігурації виділеного сервера через низку технічних та організаційних моментів. Водночас в моделі «інфраструктура як сервіс» можна провести тестування навантаження до укладення договору, а потім швидко – практично на льоту – змінювати конфігурації виділених серверів.

Не врахований стрибкоподібний характер навантажень на бізнес-додатки. Dedicated-модель знову програє в гнучкості, тому що не дозволяє в стислий термін отримати додаткові ресурси. Якщо на рівні проєкту не було закладено достатньо запасу потужності, у користувачів можуть виникнути проблеми з доступом. У хмарній моделі IaaS завжди можна відправити запит провайдеру та отримати рівно стільки ресурсів, скільки необхідно найближчого дня або навіть найближчу годину.

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

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

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

Необхідно робити регулярні бекапи даних. В Dedicated Server треба самостійно налаштовувати ПЗ для резервного копіювання. З IaaS клієнт отримує готовий сервіс, де це створення резервних копій відбувається автоматично.

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