Як реплікація Active-Active забезпечує високу доступність
Активно-активна реплікація забезпечує роботу систем без простоїв, навіть під час збоїв. Завдяки одночасному оброблянню трафіку кількома серверами, ця конфігурація забезпечує безперервне обслуговування, скорочує час відновлення до нуля та покращує продуктивність. Ось що вам потрібно знати:
- Що це таке: Усі сервери працюють, розподіляють робоче навантаження та залишаються синхронізованими.
- Чому це важливо: Простої коштують бізнесу грошей та довіри. Активно-активні системи підтримують майже ідеальний час безвідмовної роботи (99.999%), що означає лише 5,26 хвилини простою на рік.
- Як це працює: Поєднує балансування навантаження, синхронізацію даних у режимі реального часу та автоматичне перемикання на резервний ПК для безперебійної роботи.
- Ключові переваги: Зменшення часу простою, глобальна масштабованість та обслуговування без перебоїв.
- виклики: Управління узгодженістю даних, операційною складністю та вищими витратами.
Ця архітектура ідеально підходить для таких галузей, як електронна комерція, фінанси та охорона здоров'я, де кожна секунда безвідмовної роботи має значення. Хоча це вимагає ретельного планування та ресурсів, результатом є безперебійне обслуговування та задоволення клієнтів.
Реплікація в кількох центрах обробки даних: пояснення архітектури Active-Pasive проти Active-Active
sbb-itb-59e1987
Як працює реплікація Active-Active
Як працює активно-активна реплікація: три основні механізми
Активно-активна реплікація полягає у забезпеченні високої доступності шляхом поєднання балансування навантаження, синхронізація в реальному часі, і автоматичне перемикання на резервний пристрій. Разом ці механізми створюють систему, яка продовжує працювати безперебійно, навіть за умови неочікуваних збоїв.
Балансування навантаження для розподілу трафіку
В основі управління трафіком лежить балансувальник навантаження, який розподіляє вхідні запити між усіма активними вузлами. Зазвичай використовується кілька методів:
- Кругова система: Послідовно призначає запити вузлам. Хоча це просто, це не враховує фактичне навантаження на кожному сервері.
- Зважений розподіл: Надсилає більше трафіку до віртуальні приватні сервери з більшою ємністю, що робить його ідеальним для систем з різними апаратними характеристиками.
- Найменша кількість з'єднань: Спрямовує трафік на сервер, який обробляє найменшу кількість активних сеансів, запобігаючи перевантаженню під час нерівномірних робочих навантажень.
- Найменший час відгуку: Направляє запити на найшвидший сервер, що є критично важливим для застосунків, де низька затримка є ключовою.
Для систем, розподілених по кількох регіонах, Маршрутизація Anycast це революційний процес. Він дозволяє серверам у різних місцях використовувати одну IP-адресу. Таким чином, трафік автоматично перенаправляється до найближчого справного вузла. Якщо регіональний центр обробки даних вимикається, трафік безперешкодно переходить до інших місць без перерв.
Після налаштування балансування навантаження наступним кроком є забезпечення синхронізації всіх вузлів.
Синхронізація даних у реальному часі
Збереження узгодженості даних між вузлами є важливим, і це досягається за допомогою безперервної реплікації. Різні системи вирішують цю проблему по-різному:
- Системи, засновані на консенсусі: Такі інструменти, як CockroachDB, використовують алгоритми, такі як Raft, для забезпечення узгодженості. Запис підтверджується лише після того, як більшість (часто 2 з 3 вузлів) його підтверджують. Такий підхід дозволяє уникнути конфліктів і може відновитися з мережевих розділів менш ніж за 20 секунд.
- Системи на основі CRDT: Redis використовує типи реплікованих даних без конфліктів (CRDT) для обробки одночасного запису в кількох регіонах. Хоча локальні дані можуть короткочасно відрізнятися, зрештою вони сходяться до єдиного узгодженого стану. Спеціальний процес синхронізації керує змінами, використовуючи часткову синхронізацію для рутинних оновлень та повну синхронізацію для відновлення втрачених реплік.
"Бази даних Active-Active використовують лише безконфліктно репліковані типи даних (CRDT). Ці типи даних забезпечують передбачуване вирішення конфліктів і не вимагають жодної додаткової роботи з боку програми чи клієнта". – Redis Software
Системи, що використовують CRDT, можуть досягати блискавичної затримки читання та запису – часто менше 1 мілісекунди. Однак для обробки метаданих та журналів синхронізації такий рівень продуктивності вимагає до вдвічі більше пам'яті, ніж стандартна реплікація. Такі інструменти, як NTP або Chrony, є критично важливими для синхронізації годинників вузлів, забезпечуючи безперебійний зв'язок у кластері.
Ця синхронізація гарантує, що дані залишаються узгодженими та надійними, навіть у складних розподілених системах.
Автоматичне перемикання на резервний комп'ютер під час збоїв вузлів
Коли вузли виходять з ладу, активна реплікація втручається, щоб забезпечити їхню роботу. Завдяки балансуванню навантаження та синхронізованим даним система може миттєво адаптуватися. Ось як це працює:
- Виявлення в режимі реального часу: Балансувальники навантаження та глобальні менеджери трафіку (GTM) контролюють стан вузлів за допомогою сигналів серцевого ритму та перевірок доступності з урахуванням затримки. Якщо вузол виходить з ладу, трафік негайно перенаправляється на справні вузли.
- Висока доступність репліки Redis: У таких системах, як Redis, репліки шардів автоматично перепризначаються іншим вузлам, що гарантує, що жодна точка відмови не перерве роботу.
- Системи, засновані на консенсусі: Ці системи надсилають запити на реплікацію до кількох реплік (принаймні 3), щоб зберегти цілісність даних, навіть якщо один вузол стає недоступним.
Для міжрегіональних налаштувань глобальний менеджер трафіку гарантує, що користувачі перенаправляються до найближчого операційного регіону. Перевірки справності з урахуванням затримки допомагають уникнути застарілих даних під час відновлення після відмови, тоді як реалізації Redis можуть використовувати механізми Pub/Sub для ефективнішого моніторингу потоків реплікації, ніж просте зчитування наборів даних.
Переваги реплікації Active-Active
Активно-активна реплікація – це революційний спосіб мінімізувати час простою, ефективно масштабувати системи та забезпечити безперебійне обслуговування. Поєднуючи балансування навантаження, синхронізацію в режимі реального часу та автоматичне перемикання на резервний ПК, вона забезпечує високу доступність, як ніщо інше. Serionion‘Інфраструктура повною мірою використовує ці функції для забезпечення безперебійної та ефективної роботи систем.
Зменшення простоїв
Однією з видатних переваг реплікації «активно-активно» є її здатність скоротити час простою майже до нульового рівня. Оскільки всі вузли активні та обробляють запити одночасно, немає затримки в очікуванні активації резервної системи у разі збою одного вузла. Робоче навантаження миттєво розподіляється між рештою вузлів, що забезпечує нульові помітні перебої в роботі.
"Щоб сервер вважався ‘високодоступним’, він повинен досягти часу безвідмовної роботи мережі 99.999%". – Глосарій розробників мереж Microsoft
Досягнення часу безвідмовної роботи "п’ять дев’яток" – 99.999% – означає лише близько 5,26 хвилин простою на рік. Активно-активні архітектури усувають поодинокі точки відмови, гарантуючи, що проблеми з обладнанням, збої програмного забезпечення або проблеми з мережею не призведуть до збою системи.
Але скорочення простоїв – це лише початок. Активно-активна реплікація також проявляє себе добре, коли справа доходить до глобального масштабування.
Масштабованість та підтримка кількох регіонів
Активно-активні середовища спрощують масштабування. Додавання нових вузлів одразу збільшує пропускну здатність системи, оскільки кожен вузол може обробляти як читання, так і запис. Таке горизонтальне масштабування дозволяє лінійно зростати продуктивності з кожним додатковим вузлом.
Географічний розподіл робить ще один крок. Розподіляючи вузли по регіонах – наприклад, один у Вірджинії, інший у Каліфорнії та третій в Ірландії – користувачі підключаються до найближчого вузла. Така схема забезпечує блискавично швидкий час відгуку, часто менше 1 мілісекунди, як для читання, так і для запису даних. Крім того, якщо центр обробки даних вимикається через збій або катастрофу, трафік автоматично перенаправляється на інші вузли без будь-яких перерв у обслуговуванні.
Технічне обслуговування без переривання роботи
Планове технічне обслуговування більше не вимагає простоїв або попередніх попереджень для клієнтів. Та сама синхронізація в режимі реального часу, яка обробляє збої вузлів, також забезпечує безперебійне технічне обслуговування. Коли вузлу потрібні оновлення, виправлення безпеки або заміна обладнання, його можна перевести в автономний режим, поки інші вузли продовжують керувати всім вхідним трафіком.
"Oracle GoldenGate пропонує ці активні рішення як для проектів високої доступності, так і для проектів оновлення та міграції з нульовим часом простою". – Oracle
Після завершення технічного обслуговування автономний вузол автоматично повторно синхронізується з будь-якими пропущеними оновленнями. Такий підхід гарантує безпеку та актуальність систем, не порушуючи роботу користувачів або бізнес-операцій.
Проблеми розгортання Active-Active
Активно-активна реплікація пропонує незаперечні переваги, але також створює для організацій низку технічних труднощів. Успішне впровадження цієї схеми вимагає ретельного управління координацією, узгодженістю та витратами в розподілених системах.
Управління узгодженістю даних
Синхронізація в реальному часі є основою надійності в активних розгортаннях, але вона також створює значні труднощі. Однією з найскладніших проблем є обробка одночасного запису даних на різних вузлах. Наприклад, якщо два користувачі оновлюють один і той самий запис одночасно на різних серверах, система повинна вирішити, яку зміну зберегти. Звичайні стратегії вирішення цих конфліктів включають принцип "Перемагає останній запис", призначення пріоритету певним вузлам або використання власної логіки злиття.
"Мультимастер не усуває конфлікти, він просто переміщує їх. У таких ситуаціях виникатимуть конфлікти, деякі через затримку, деякі з інших причин. Логіка вирішення проблем стає критично важливою"."
- Ян Віремєвич, старший менеджер з продуктів, Percona
Географічна відстань між вузлами додає ще один рівень складності. Наприклад, затримка мережі між США та Австралією може призвести до затримок передачі даних у 150–200 мс, що потенційно може призвести до тимчасової передачі вузлами застарілих даних або пропуску останніх оновлень під час резервного копіювання. Ця проблема ускладнюється проблемами синхронізації годинника; якщо годинники сервера зміщуються, вирішення конфліктів на основі позначок часу може стати ненадійним, що ще більше ускладнює узгодженість.
Операційна складність
Запуск активно-активної системи далеко не простий. Ці середовища вимагають спеціалізованих знань та постійного контролю. Рутинні завдання, такі як оновлення схеми або розгортання, несуть підвищений ризик порушення реплікації та вимагають ретельного планування, щоб уникнути простоїв.
"Активний-активний — це не той скорочений шлях, яким часто здається. Це не просто ‘високоякісна дія’, а покращення. Це являє собою фундаментальну зміну дизайну системи зі значними постійними витратами на інженерію, експлуатацію та управління продуктом"."
- Ян Віремєвич, старший менеджер з продуктів, Percona
Операційний моніторинг стає значно вимогливішим в активних конфігураціях. Командам необхідно пильно стежити за затримкою реплікації, станом вузлів, перевірками узгодженості та трасуванням транзакцій на кількох вузлах з можливістю запису. Крім того, ці системи часто потребують більше пам'яті – іноді вдвічі більше, ніж стандартні конфігурації реплікації – для керування метаданими та журналами синхронізації. У деяких випадках політики вилучення можуть активуватися, коли використання пам'яті досягає позначки 80%, щоб забезпечити безперебійне поширення між кластерами.
Вплив на витрати
Розгортання «активно-активне» мають високу ціну. Вони вимагають більше апаратних ресурсів, вищої пропускної здатності мережі та висококваліфікованого персоналу для управління системою. Крім того, рішення «активно-активне» корпоративного рівня часто мають високі витрати на ліцензування порівняно зі стандартними конфігураціями. Перш ніж перейти на таку архітектуру, організаціям слід ретельно розглянути, чи можуть простіші варіанти, такі як регіональні репліки читання, шардінг або активно-пасивні налаштування, задовольнити їхні потреби за нижчою ціною. Хоча ці проблеми є суттєвими, їх вирішення є важливим для досягнення високої доступності, яку прагнуть забезпечити активно-активні архітектури.
Поширені шаблони розгортання Active-Active
Організації використовують кілька добре зарекомендували себе шаблонів для впровадження реплікації «актив-актив», кожен з яких адаптований до конкретних операційних потреб. Ці підходи базуються на основних механізмах систем «актив-актив», застосовуючи їх у різних сценаріях розгортання. Вибір правильного шаблону залежить від вимог та обмежень вашої системи.
Багаторегіональні кластери баз даних
Одним із найпопулярніших шаблонів є розподіл кластерів баз даних по кількох географічних регіонах. Ця схема розміщує незалежні кластери баз даних у таких місцях, як східне узбережжя США, Європа та Азія, причому кожен кластер керує локальними операціями читання та запису. Користувачі підключаються до найближчого кластера, забезпечуючи субмілісекундна затримка для локальних запитів. Однак синхронізація даних між регіонами призводить до затримок через фізичні відстані.
Наприклад, якщо користувач оновлює свій профіль у Нью-Йорку, може знадобитися деякий час, щоб зміни відобразилися в Європі чи Азії. Такі системи, як CockroachDB, вирішують цю проблему за допомогою реплікації на основі консенсусу, яка вимагає більшості реплік (зазвичай трьох) для підтвердження запису перед його фіксацією. Це забезпечує високу узгодженість між усіма вузлами.
"Багатоактивна доступність надає переваги, подібні до традиційних понять високої доступності, але також дозволяє читати та записувати дані з кожного вузла вашого кластера, не створюючи жодних конфліктів". – CockroachDB
Цей шаблон добре підходить для глобальних застосунків, які вимагають дотримання законів про місцезнаходження даних, або для систем з високим трафіком, таких як платформи електронної комерції та фінансові послуги. Однак, він може бути не найкращим вибором для застосунків зі складною логікою транзакцій, які не можуть впоратися з кінцевою узгодженістю.
Деякі розгортання йдуть далі, включаючи логіку реплікації безпосередньо в рівень програми для додаткової стійкості.
Реплікація на рівні застосунків
У цьому шаблоні логіка перемикання на резервний архів вбудована безпосередньо в програму, а не покладається виключно на базу даних. Програма активно відстежує стан реплік бази даних і перемикає з'єднання, коли виявляє збій. Наприклад, якщо локальна репліка Redis переходить в автономний режим, програма може негайно перенаправити її на віддалену репліку в іншому регіоні.
Механізм публікації/підписки часто використовується для підвищення надійності шляхом відстеження стану реплік. Хоча цей підхід пропонує розробникам більше контролю над компромісами щодо узгодженості, він пов'язаний з певними труднощами. Асинхронна реплікація під час відновлення після відмови може призвести до пропуску операцій запису.
"Відмовостійке перемикання з’єднання Active-Active може покращити доступність даних, але може негативно вплинути на узгодженість даних. Застосунок, який перемикається на іншу репліку, може пропустити операції запису". – Redis
Цей метод забезпечує гнучкість, але вимагає ретельного проектування для балансування доступності та узгодженості.
Реплікація віртуальних машин та серверів
Інший підхід передбачає реплікацію віртуальних машин (ВМ) та серверів на різних сайтах. Для цього часто використовуються "розтягнуті кластери", де хости у двох фізичних місцях працюють в одному віртуалізованому середовищі. Для такої конфігурації важливо синхронно реплікувати сховище, доступне та придатне для запису з обох сайтів, а також підключення до мережі другого рівня з низькою затримкою.
Цей шаблон ідеально підходить для аварійного відновлення та забезпечення безперервності бізнесу. Під час звичайної роботи робочі навантаження можна розподілити між двома сайтами. У разі збою всі робочі навантаження автоматично переносяться на сайт, що залишився. Однак для його реалізації потрібна значна інфраструктура, включаючи спільні мережі та синхронізоване сховище, що може збільшити як вартість, так і складність.
Висновок
Активно-активна реплікація відіграє вирішальну роль для компаній, де навіть мить простою є неприйнятною. Завдяки підтримці всіх вузлів онлайн та активній обробці трафіку, ця схема досягає Цільовий час відновлення (RTO) нуль – немає потреби чекати на роботу резервного сервера, оскільки кожен сервер вже працює.
Як згадувалося раніше, ця архітектура пропонує очевидні експлуатаційні переваги, включаючи покращений час безвідмовної роботи та продуктивність. На відміну від активно-пасивних систем, які залишають ресурси бездіяльними, активно-активні конфігурації повністю використовують апаратне забезпечення. Відновлення роботи відбувається за лічені секунди, а сучасні конструкції забезпечують мінімальну затримку для локальних запитів. Для таких галузей, як платформи для торгівлі акціями або телекомунікаційні послуги, де кожна мілісекунда на рахунку, цей рівень продуктивності може стати домінантним.
"Терпимість втрати даних у більшості галузей промисловості наблизилася до нуля. Там, де колись прийнятними вважалися хвилини простою, сьогодні допустимий рівень простою також рухається до однозначних хвилин або навіть секунд". – Біла книга Precisely
Однак ця надійність пов'язана з додатковою складністю. Забезпечення узгодженості даних між кількома активними вузлами вимагає вдосконалених механізмів вирішення конфліктів, синхронізованих годинників та постійного моніторингу затримки реплікації. Крім того, вимоги до пам'яті можуть подвоїтися для обробки метаданих та журналів реплікації. Але для організацій, де час безвідмовної роботи безпосередньо впливає на дохід та довіру клієнтів, ці проблеми є необхідним компромісом.
Незалежно від того, чи керуєте ви багаторегіональними кластерами баз даних, використовуєте реплікацію на рівні додатків чи розгортаєте розтягнуті кластери в центрах обробки даних, активна реплікація перетворює високу доступність на практичну реальність. Це не просто вибір дизайну – це стратегічна необхідність для компаній, які не можуть дозволити собі перебої. Завдяки передовим рішенням активної реплікації Serverion ваші послуги залишаються доступними, незалежно від перешкод.
поширені запитання
Коли варто обирати активно-активний варіант замість активно-пасивного?
Коли ваша заявка вимагає постійна доступність, найвища продуктивність під час стрімких заторів, масштабованість, і географічна надмірність, активна-активна схема — це правильний вибір. Хоча це пов’язано зі збільшенням витрат на інфраструктуру та додатковою складністю, вона забезпечує високу надійність та доступність для систем, які не можуть дозволити собі простої.
Як системи active-active запобігають конфліктам запису?
Активно-активні системи вирішують конфлікти запису, використовуючи безконфліктно репліковані типи даних (CRDT). Вони розроблені для забезпечення остаточна узгодженість шляхом автоматичної синхронізації операцій читання та запису між кількома репліками. CRDT самостійно вирішують конфлікти, усуваючи необхідність ручного виправлення. Цей метод забезпечує узгодженість даних, одночасно підтримуючи високу доступність у розподілених системах.
Що потрібно для активного проведення заходів у різних регіонах?
Запуск активно-активної реплікації в різних регіонах вимагає глобальне рішення для управління дорожнім рухом для ефективної обробки маршрутизації запитів. Цього можна досягти за допомогою таких інструментів, як менеджери трафіку на основі DNS або балансувальники навантаження. Для налаштування також потрібна інфраструктура, здатна синхронізація реплікації даних зберігаючи послідовність, часто за допомогою таких підходів, як остаточна узгодженість.
Щоб забезпечити безпечну та надійну систему, впровадьте TLS-шифрування для безпеки мережі. Крім того, важливо враховувати такі фактори, як затримка, операційні витрати, і складність управління. Ці міркування є важливими для підтримки високої доступності та надійних можливостей аварійного відновлення.
