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

Спосіб, яким підприємства думають про свою інфраструктуру, змінився.

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

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

Sovereignty: отримання контролю над вашим металом

Більшість підприємств, які прагнуть покращити контроль над своїми даними та інфраструктурою, починають з суверенітету даних. Резиденція даних, шифрування, контроль доступу та нормативні рамки – це найвидиміші вимоги, і їх зазвичай вирішують першими. Ці заходи є необхідними, але відповідають лише на частину питання. Для детального розгляду факторів, що рухають суверенітетом, та чому суверенітет даних недостатній, відвідайте нашу веб-сторінку і наш білий документ “Суверенна хмара: важливий посібник для підприємств.”

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

Операційна залежність – ризик суверенітету

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

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

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

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

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

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

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

Автоматизація безпосереднього металу робить суверенітет сталим

Автоматизація безпосереднього металу вирішує ці ризики, вводячи узгодженість на найнижчому рівні стеку. Замість того щоб розглядати фізичні сервери як особливі випадки, вона treats them as flexible programmable assets, establishing the same processes from virtual machines to bare metal.

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

  • Прозора інвентаризація обладнання: Сервери та їх внутрішні апаратні можливості виявляються, інвентаризуються та вводяться в експлуатацію, забезпечуючи єдине джерело правди. Це є важливим, коли власність на інфраструктуру та конфігурація повинні бути показаними регуляторам і аудиторам, підтримуючи надій compliance у суверенній хмарі.
  • Повторювальне надання: Серверами надаються так само кожен раз, використовуючи визначені та версійовані процеси. Це полегшує відновлення інфраструктури, коли суверенітет залежить від відтворюваності, а не від довіри.
  • Чітка власність на pipeline надання: Організація контролює, як машини виявляються, конфігуруються та вводяться в експлуатацію, без покладання на інструменти певних постачальників або зовнішніх учасників, зберігаючи оперативний контроль над фізичним рівнем.
  • Швидші, надійніші операції: Нове обладнання може бути швидко додане, замінене або перепрофільоване, що дозволяє суверенним платформам масштабуватися, відновлюватися і еволюціонувати без втрати контролю під час рутинних змін чи надзвичайних подій.
  • Тестування обладнання до і після виробництва: Обладнання необхідно протестувати перед введенням в експлуатацію, що допомагає забезпечити, щоб тільки відомі, відповідні машини входили до суверенної інфраструктури.
  • Менше залежності від племінного знання: Операційні знання закріплюються в системах і процесах, а не тільки в головах людей, зменшуючи ризик залежності від конкретних осіб, а не від самої організації.

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

Закриття прогалини з MAAS

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

Розгортайте будь-яку ОС на будь-якому апаратному забезпеченні за допомогою MAAS

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

  • Контроль життєвого циклу від початку до кінця: MAAS автоматизує повний життєвий цикл фізичних машин, від виявлення та введення в експлуатацію до розгортання, повторного використання та демонтажу. Використовуючи стандартні інтерфейси управління за межами каналу, такі як IPMI або RedFish, він забезпечує управління живленням та наданням на широкому діапазоні сертифікованого обладнання без потреби у спеціальних інструментах постачальників.
  • Інфраструктура як код для безпосереднього металу: Стабільний, добре визначений API дозволяє керувати обладнанням програмно та інтегрувати його в існуючі робочі процеси. Розгляд фізичної інфраструктури як коду робить provision повторюваним, перевіряємим та легшим для еволюції без покладання на ручне втручання.
  • Валідація обладнання в масштабі: Вбудовані діагностики дозволяють протестувати машини перед їх введенням в експлуатацію і знову, коли їх переробляють або перепрофілюють. Це допомагає підтримувати здоровий і відповідний пул серверів, що є важливим для передбачуваних операцій і надійного відновлення.
  • Точна обліковість та обізнаність про конфігурацію: Детальна інвентаризація обладнання робить можливим розміщення навантажень на основі реальних можливостей.
  • Інтегроване конфігурування мережі та послуги: MAAS конфігурує мережеві інтерфейси серверів з об’єднаннями, VLAN, зв’язками та адресами, і інтегрує високодоступні, відкриті DHCP та DNS сервіси.

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

Висновки та наступні кроки

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

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

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

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

Зв’яжіться з нами сьогодні

Цікавитеся, як запустити Ubuntu у вашій організації?

Підписка на розсилку

Отримуйте останні новини та оновлення від Ubuntu у свій inbox.

ВSubmitting this form, I confirm that I have read and agree to Політику конфіденційності Canonical.