Висока доступність TAK Server: кластеризація, відмовостійкість і нуль простою

TAK Server — це серце тактичної єдиної оперативної картини. Кожна подія Cursor on Target (CoT) — кожне повідомлення про позицію, кожен контакт, кожне накладення — проходить через нього. Коли цей сервер падає, спільна картина одночасно завмирає для кожного під'єднаного оператора. У гарнізоні це незручність; під час операції це втрата ситуаційної обізнаності в найгірший можливий момент. Тому висока доступність — не розкішна функція серйозного розгортання TAK, а різниця між інфраструктурою, яку можна поставити за місією, і інфраструктурою, яку не можна. Ця стаття розглядає, як запускати TAK Server без єдиної точки відмови: кластеризувати рівень застосунку, реплікувати базу даних, балансувати клієнтське навантаження та проєктувати відмовостійкість, яка завершується швидше, ніж оператор може це помітити.

Чому єдиний вузол TAK Server є єдиною точкою відмови

Типова інсталяція TAK Server — це єдиний застосунок Java, підкріплений єдиною базою даних PostgreSQL/PostGIS на єдиному хості. Вона працює, її просто розгорнути, і для невеликого підрозділу вона цілком адекватна. Але ця простота приховує чотири окремі домени відмови, будь-який з яких обвалює всю картину: процес застосунку може впасти або вичерпати купу; хост може втратити живлення, мережу або диск; база даних може пошкодитися, заповнити свій том або потрапити в дедлок; а мережевий шлях між клієнтами та сервером може бути перерваний. У одновузловому дизайні вони не є незалежними — втрата будь-якого з них є тотальною.

Висока доступність означає проєктування кожного з цих доменів так, щоб жодна окрема відмова не була фатальною. Рівень застосунку стає кластером взаємозамінних вузлів. База даних стає реплікаованим набором «первинний плюс резервний» з автоматичним підвищенням. Клієнтське з'єднання стає збалансованою віртуальною кінцевою точкою з перевіркою стану, а не жорстко прописаним хостом. Результат — система, де вузол можна втратити — через збій, перезавантаження для оновлення чи знищену серверну кімнату — а оператори зберігають свою картину.

Режим кластера TAK Server: площина обміну повідомленнями

Фундаментом високої доступності TAK Server є режим кластера. У одновузловому розгортанні події CoT маршрутизуються через внутрішньопроцесні черги — площина обміну повідомленнями живе всередині одного запущеного застосунку. У режимі кластера ця площина виноситься на спільну фабрику повідомлень, щоб кілька вузлів TAK Server могли співпрацювати як один логічний сервер. Подія CoT, опублікована клієнтом, під'єднаним до вузла A, розподіляється фабрикою і доставляється клієнтам, під'єднаним до вузла B, причому ці клієнти ніколи не знають, що вони на різних машинах.

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

Бездержавні вузли, спільний стан

Кардинальне правило проєктування кластера TAK Server полягає в тому, що вузли застосунку мають бути бездержавними. Усе, що оператор втратив би, якби вузол зник, має жити поза вузлом: збережений CoT у базі даних, стан груп і місій у базі даних і жива маршрутизація підписок у фабриці повідомлень. Коли це правило дотримане, відмова вузла є неподією для даних — єдина вартість полягає в тому, що клієнти на мертвому вузлі мають повторно під'єднатися, і ця вартість обмежена тим, наскільки швидко балансувальник навантаження і клієнти помічають відмову.

Висока доступність бази даних: справжнє вузьке місце

Щойно рівень застосунку кластеризований, база даних PostgreSQL/PostGIS стає домінантною єдиною точкою відмови — кожен кластеризований вузол залежить від однієї бази даних, тож незахищена база даних зводить нанівець усю стійкість рівня застосунку. Висока доступність бази даних спирається на три компоненти, що працюють разом.

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

Автоматична відмовостійкість. Сама лише реплікація не виконує перемикання — щось має виявити, що первинний вузол мертвий, і підвищити резервний. Patroni, що працює як агент на кожному вузлі бази даних, виконує цю роль. Він використовує розподілене сховище конфігурації — etcd або Consul, розгорнуте як непарний кворум із трьох або п'яти учасників — щоб тримати блокування лідера. Якщо первинний вузол припиняє оновлювати своє блокування, Patroni обирає найактуальніший резервний вузол і підвищує його до первинного, зазвичай протягом 5–15 секунд.

Маршрутизація з'єднань. Вузли TAK Server повинні завжди під'єднуватися до тієї бази даних, яка наразі є первинною, без переконфігурації. Маршрутизатор з'єднань — PgBouncer або HAProxy перед портами бази даних — відстежує поточного лідера (Patroni оновлює його кінцеві точки стану під час підвищення) і маршрутизує трафік запису відповідно. З погляду TAK Server база даних є єдиним стабільним віртуальним IP; підвищення резервного вузла за цим IP невидиме.

Цілі відновлення визначають дизайн

Два числа керують рівнем бази даних. Цільова точка відновлення (RPO) — це те, скільки даних ви можете дозволити собі втратити; для зафіксованого збереження CoT відповідь для тактичної системи зазвичай нульова, що зобов'язує мати синхронний резервний вузол. Цільовий час відновлення (RTO) — це те, як довго може тривати відмовостійкість; з Patroni і справним кворумом це вікно підвищення в 5–15 секунд. Визначте обидва явно перед провіжинінгом — вони диктують, чи можете ви терпіти лише асинхронну реплікацію і наскільки агресивними мають бути таймери виявлення відмови.

Балансування навантаження та повторне під'єднання клієнтів

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

Балансувальник навантаження рівня 4 — HAProxy, режим потоку NGINX або хмарний L4-балансувальник — представляє єдиний віртуальний IP для TLS-портів клієнтів і розподіляє нові з'єднання серед справних вузлів TAK Server за принципом найменшої кількості з'єднань або кругового перебору. Активні перевірки стану кінцевої точки статусу кожного вузла видаляють відмовлений вузол з ротації протягом інтервалу перевірки стану. Критично, що балансувальник повинен працювати на рівні 4 і пропускати TLS без змін, оскільки TAK Server використовує взаємну автентифікацію за клієнтським сертифікатом, яка має завершуватися на вузлі застосунку, а не на балансувальнику.

Коли вузол відмовляє, сокети його клієнтів розриваються. Кожен клієнт виявляє мертвий сокет через TCP keepalive і повторно під'єднується до віртуального IP, де балансувальник маршрутизує його до вузла, що вцілів. Оскільки кожен вузол спільно використовує одну базу даних і фабрику повідомлень, повторно під'єднаний клієнт миттєво ресинхронізується з поточною картиною. Сприйнятий простій повністю керується інтервалом keepalive клієнта та частотою перевірок стану балансувальника — налаштуйте обидва до кількох секунд, і оператор бачить миттєвий стан «повторного під'єднання», а не втрату обізнаності.

Планування потужності тут теж має значення. Розмірте кластер так, щоб втрата одного вузла все ще залишала достатньо запасу, аби поглинути всю популяцію клієнтів — правило N+1. Якщо два вузли кожен працюють поблизу насичення і один помирає, кожен відкинутий клієнт повторно під'єднується до вузла, що вцілів, і перевантажує його, перетворюючи відмову одного вузла на каскад. Закладіть кожному вузлу нести його сталу частку плюс повну частку відмовостійкості та перевірте під навантаженням, що вузол, який вцілів, може взяти стрибок без вичерпання купи чи лімітів з'єднань.

Обслуговування без простоїв

Той самий механізм, що переживає незаплановану відмову, також уможливлює планове обслуговування без простою. Щоб пропатчити або оновити вузол, осушіть його: дайте балансувальнику навантаження вказівку припинити надсилати нові з'єднання, дайте наявним клієнтам поступово відключитися або повторно під'єднатися деінде, потім вимкніть вузол, оновіть його та поверніть у ротацію. Прокручування кластера по одному вузлу за раз тримає сервіс безперервно доступним. Оновлення бази даних дотримуються тієї самої логіки у зворотному порядку — спершу оновіть резервні вузли, потім виконайте контрольоване перемикання, яке підвищує вже оновлений резервний вузол, тож первинний ніколи не буде вузлом під ключем. Це перетворює вікно обслуговування з запланованого простою на прозору операцію поступового прокручування.

Географічна надлишковість і федерація

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

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

Там, де незалежним майданчикам потрібно спільно використовувати картину без спільної бази даних, правильним інструментом є федерація, а не кластеризація. Федерація з'єднує окремі кластери TAK Server і обмінює CoT між ними за політикою — механізм, розглянутий у налаштуванні федерації TAK Server. Кластеризація дає вам єдиний стійкий сервер; федерація з'єднує кілька стійких серверів через організаційні та географічні межі. Зріле розгортання використовує обидва: кожне командування запускає кластеризований, високодоступний TAK Server, а федерація зшиває ці кластери в картину масштабу театру.

Операційна дисципліна: тестування відмови

Дизайн високої доступності, який ніколи не перемикався по-справжньому, є гіпотезою, а не спроможністю. Найважливіша операційна практика — навмисно й повторно викликати відмову: вимкнути вузол застосунку під навантаженням і виміряти час повторного під'єднання клієнтів; вимкнути первинний вузол бази даних і підтвердити, що Patroni підвищує резервний вузол у межах RTO з нульовою втратою збереженого CoT; розділити сховище кворуму і перевірити, що кластер відмовляється від split-brain. Проводьте ці навчання проти реалістичної кількості клієнтів і щільності треків, а не на порожньому сервері. Ціль — відмовостійкість менш ніж за 30 секунд без дій оператора, і єдиний спосіб довіряти цьому числу — отримати його під навантаженням, навмисно, багато разів.