Азure Dedicated Host: домени відмовостійкості та зони доступності. Повний посібник з високої доступності

By Mirko Peters · 2026-10-25

Дізнайтеся, як налаштувати домени відмовостійкості та зони доступності Azure Dedicated Host, щоб створювати високодоступні хмарні архітектури підприємства з однією орендою.

Automatically translated with AI from the original post. Read the English original

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

Головне

• Зони доступності ізолюють групи dedicated hosts за незалежною фізичною інфраструктурою живлення, охолодження та мережі в межах одного регіону Azure.
• Домени відмовостійкості розподіляють dedicated hosts між окремими серверними стійками, захищаючи від локальних апаратних збоїв.
• Групи хостів є логічними контейнерами, які встановлюють регіональні та зональні межі для вашої виділеної фізичної інфраструктури.
• Ручне розміщення ВМ між різними доменами відмовостійкості гарантує, що резервні копії застосунку ніколи не опиняться на одній фізичній серверній стійці.
• Поєднання резервування на рівні зон із розділенням за доменами відмовостійкості забезпечує безвідмовність рівня підприємства для критично важливих робочих навантажень.

Розуміння архітектури Azure Dedicated Host

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

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

Роль групп хостів

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

Групи хостів спрощують управління, об’єднуючи кілька фізичних серверів під однією адміністративною парасолькою. Вони також забезпечують суворі правила розміщення. Група хостів не може охоплювати кілька зон доступності: якщо ваша архітектура вимагає резервування між зонами, потрібно створити окремі групи хостів для кожної зони. Щойно група хостів активна, ви можете додавати до неї dedicated hosts і розподіляти віртуальні машини.

Майстерність зон доступності для регіональної стійкості

Зони доступності — це фізично відокремлені локації в межах одного регіону Azure. Кожна зона має власне незалежне джерело живлення, окремі системи охолодження та надійну мережеву інфраструктуру. Якщо несподіваний збій живлення або локальний відмова інфраструктури вплине на Zone 1, Zone 2 і Zone 3 продовжуватимуть працювати без перерви.

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

• Створіть групу хостів A у Availability Zone 1 і призначте їй виділені хости.
• Створіть групу хостів B у Availability Zone 2 і також призначте їй виділені хости.
• Розгорніть основну віртуальну машину з базою даних на виділеному хості в Zone 1.
• Розгорніть репліку або вторинну віртуальну машину з базою даних на виділеному хості в Zone 2.

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

Зменшення апаратних ризиків за допомогою доменів відмов

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

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

Проєктування резервування на рівні стійок

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

Щоб усунути цю точку єдиного збою, виконайте такі кроки:

1. Налаштуйте групу хостів так, щоб вона використовувала щонайменше два домени відмов.
2. Розгорніть виділений хост A і призначте його до домену відмов 1.
3. Розгорніть виділений хост B і призначте його до домену відмов 2.
4. Розмістіть першу віртуальну машину веб-застосунку на хості A.
5. Розмістіть другу віртуальну машину веб-застосунку на хості B.

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

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

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

Щоб послухати детальний огляд апаратної ізоляції, механіки ліцензування та поширених пасток у цінноутворенні, обов’язково послухайте повний епізод подкасту M365 FM Podcast і отримайте більше експертних порад щодо хмари!

Поширені запитання

Чи може один Azure Dedicated Host охоплювати кілька зон доступності?

Ні. Окрема група хостів і пов’язані з нею виділені хости мають перебувати в межах однієї зони доступності. Щоб використовувати кілька зон, потрібно створити окремі групи хостів для кожної зони.

Чим відрізняється зона доступності від домену відмов на виділених хостах?

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

Чи потрібно налаштовувати домени відмов для віртуальних машин на виділених хостах?

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

Чи можна використовувати автоматичне розміщення віртуальних машин у кількох доменах відмов у групі вузлів?

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