Гібридна хмара
Гібридна хмара — це ІТ-архітектура, яка поєднує локальну (on-premise) або приватну інфраструктуру з одним чи кількома провайдерами публічної хмари в єдине скоординоване середовище, а не в ізольовані силоси. Організації розміщують робочі навантаження, дані та управління там, де це диктують вимоги до вартості, продуктивності, затримки або відповідності нормативним вимогам, зазвичай використовуючи спільний інструментарій для послідовного розгортання, захисту та моніторингу всього середовища.
На практиці гібридна хмара зазвичай означає, що організація тримає частину систем на власному обладнанні — у дата-центрі, на колокації або на виділених (bare-metal) серверах, які вона володіє чи орендує, — тоді як інші системи працюють у провайдерів публічної хмари, таких як AWS, Azure чи Google Cloud. Такий поділ свідомий: чутливі до затримок або регульовані робочі навантаження часто залишаються ближче до бізнесу, тоді як навантаження, яким вигідні еластична потужність, керовані сервіси або географічне охоплення, переносяться в хмару. Гібридна хмара відрізняється від мультихмари (multi-cloud), яка означає одночасне використання двох або більше провайдерів публічної хмари; гібридне середовище завжди включає щонайменше один компонент поза публічною хмарою — приватний дата-центр, edge-обладнання або локальні (on-premise) сервери. Багато організацій одночасно використовують обидва підходи — гібридний між локальною інфраструктурою та хмарою, і мультихмарний між кількома провайдерами в межах хмарної частини.
Поширені причини переходу на гібридну модель включають вимоги щодо резидентності даних і регуляторні вимоги, які змушують тримати певні дані на інфраструктурі, яку організація контролює напряму, наявні капітальні інвестиції в обладнання, яке ще не амортизоване, робочі навантаження зі стабільним, передбачуваним навантаженням, які дешевше запускати на власних серверах, ніж на орендованій хмарній потужності, а також прагнення уникнути залежності від одного провайдера. Гібридні конфігурації також поширені під час міграцій: команда поступово переносить робочі навантаження в хмару, місяцями чи роками запускаючи старі й нові системи паралельно, замість того щоб перемикатися одразу. Компроміс полягає в операційному навантаженні: локальні та хмарні середовища зазвичай мають окремі консолі, окремі облікові дані, окремий моніторинг і окремі процеси встановлення патчів, тож одну й ту саму політику безпеки чи процедуру реагування на інциденти доводиться реалізовувати двічі, двома різними способами.
Чому гібридна хмара важлива
Гібридна хмара важлива, тому що більшість реальних інфраструктурних середовищ є гібридними незалежно від того, чи планувала це команда, — компанія купує іншу зі своїм власним дата-центром, регуляторна вимога змушує тримати певні дані локально, або застосунок просто неможливо економічно перенести. Якщо ставитися до локальної інфраструктури та хмари як до окремих світів, це означає дублювання засобів контролю безпеки, політик доступу та журналів аудиту — і саме тут з'являються прогалини: правило файрвола, застосоване в хмарній консолі, але забуте на боці bare-metal, або runbook реагування на інциденти, який працює лише для одного середовища. Для регульованих галузей і всіх, хто звітує перед аудиторами, питання «хто змінив цей сервер і коли» потребує однакової відповіді незалежно від того, стоїть сервер у стійці колокації чи в регіоні публічної хмари — а це важко гарантувати без спільного рівня керування для обох середовищ.
Як Sencai допомагає
Sencai ставиться до локальних і bare-metal серверів як до повноцінних цілей, а не як до додаткової функції: той самий легкий fleet-агент, що працює на хмарних інстансах, працює на будь-якому Linux-сервері, забезпечуючи ідентичний моніторинг, встановлення патчів, інвентаризацію ПЗ та автоматизацію runbook з погодженням на затвердження, тож процедура реагування на інциденти, написана один раз, працює однаково всюди. З боку хмари Sencai підключає наявні облікові записи у 11 провайдерів (BYOC, нічого не мігрує) або розгортає й тарифікує керовану потужність під власним обліковим записом, інвентаризує ресурси одразу після підключення облікового запису та записує кожну дію в незмінний, пов'язаний хешами журнал аудиту — єдина консоль управління, єдиний журнал аудиту для обох світів.
Управління гібридною та локальною інфраструктурою →