PostgreSQL-тің сенімділігі: Patroni және Pacemaker 3 түйінді кластерде

Мақсат: PostgreSQL-дің қалыпты және арзан шешімдермен апаттан аман қалуы

PostgreSQL-дің сенімділігі — бұл «идеал архитектура» үшін емес, істеп тұрған бизнес үзіліске түспесін деген мақсат үшін керек. Көбіне проблема өзек дерекқорда емес, ол қоршаған ортада: жабдық, желі, қуат немесе адам факторы.

Практикада жағдайлар осылай көрінеді: түйін кенеттен қатып қалады (ландинг, қайта жүктеу, қуат блогының өлімі), диск қатесі немесе орын таусылады, желі үзіліп немесе пакеттер "жүзеді", ОС немесе PostgreSQL жаңартуы сәтсіз аяқталады, конфигурацияға өзгеріс енгізіледі немесе команда қате орында команда жібереді.

Ең жиі кездесетін қателік — «бір реплика қойсақ жетеді» ойы. Реплика өздігінен рольдерді шешпейді: primary жоғалғанда, standby-ды қауіпсіз әрі жылдам primary ету керек, екі активті дерекқор болмауы тиіс. Егер проблема желіде болса, бір standby оңай қауіп көзіне айналуы мүмкін: әр түйін екінші бірінің «өлгенін» ойлайды.

Қолдануға болатын нақты қадамдар, қымбат SAN-сыз:

• 3 қатысушыдан тұратын кластер құру (1 primary, 1 replica және кворум немесе координация түйіні);
• автоматты переключениеге анық ережелер мен тайминг қою;
• алдын ала рұқсат етілген деректер жоғалуын (RPO) және тоқтап қалу уақытын (RTO) келісу;
• апаттарды үнемі тексеріп тұру, құжатқа үміттенбеу.

Риск әрқашан қалады. Асинхронды репликацияда соңғы транзакциялар primary құлаған кезде жоғалуы мүмкін. Желілік үзілістерде fencing болмаса, split brain алынып тастау қиын қайшыларға әкеледі.

Егер өте қысқаша айтсақ, Patroni мен Pacemaker/Corosync ойлау деңгейінде ерекшеленеді. Patroni PostgreSQL-ге жақынырақ: ол репликация рөлдерін түсінеді және лидер таңдау үшін сыртқы DCS-ке сүйенеді. Pacemaker/Corosync — жалпы кластер менеджері: ол ОС пен сервистер деңгейінде ресурстарды басқарады. Екі жол да қолжетімділікті береді, бірақ қателік бағасы көбіне желі мен failover ережелерінде болады, құрал таңдауында емес.

Өмірден мысал: клиникада күні бойы пациент жазбалары қайтып келеді. Егер primary жаңартудан кейін қайта жүктелсе, кластер репликаны бірнеше минутта көтеруі керек. Команда алдын ала қанша деректер жоғалтуға болатындығын және жүйенің қалпына келгенін қалай тексеретінін білуі тиіс.

Негізгі түсініктер: HA, репликация, RPO/RTO және quorum

PostgreSQL үшін жоғары қолжетімділік (HA) — бұл база апаттарды осылай өткізіп, қолданба жұмысы жалғасатын және резервтік түйінге ауысу тез болатын жағдай. Қарапайым сызбада бір primary бар (жазбаларды қабылдайды) және бір немесе бірнеше standby бар (өзгерістерді репликация арқылы қабылдайды және жаңа primary болуға дайын).

Репликация — primary-ден standby-ге өзгерістер жіберіледі деген сөз. Егер автоматты переключение (failover) болса, бөлек компонент (мысалы, Patroni немесе Pacemaker) қашан және кім primary болатынын шешеді.

RPO: қанша дерек жоғалтуға болады

RPO (Recovery Point Objective) — уақыт бойынша рұқсат етілген деректер жоғалтуы. RPO = 0 — расталған жазбаларды жоғалтқыңыз келмейді. RPO = 10 секунд — соңғы 10 секундтағы өзгерістерді жоғалтуға болады.

RPO репликация режиміне тікелей байланысты:

• Асинхронды: primary жазбаны клиентке дереу растайды, standby кейінірек жетеді. Жылдам, бірақ primary құлаған кезде кей транзакциялар жоғалуы мүмкін.
• Синхронды: primary жазбаны тек standby қабылдағаннан кейін растайды. Бұл RPO-ны нөлге жақындатады, бірақ желі кешігулеріне сезімтал.

RTO: қанша уақытта жұмыс қалпына келеді

RTO (Recovery Time Objective) — шыдамдылықпен қабылданатын тоқтап қалу уақыты. Оған апатты анықтау, жаңа primary таңдау, клиенттерді ауыстыру және кештерді жылыту мен байланыстарды қалпына келтіру кіреді.

Егер қызмет минут ішінде қалпына келуі керек болса, детекция, таймауттар және өздігінен переключение осы минутқа сай болуы тиіс. Мониторинг апатты 60 секундта анықтаса, ал failover тағы 30 секунд алса, онда RTO екі минуттан кем бола алмайды.

Quorum: неге жай ғана жаңа primary таңдау керек емес

Quorum — көпшілік ережесі. Ол кластерді split brain-нан сақтайды, яғни екі түйін бір уақытта primary болмауы тиіс.

Мысал: желі екі бөлікке бөлінді. Егер екі жақ өздерін билеуші санаса, әрқайсысы primary көтеріп, жазуды қабылдай алады. Байланыс қалпына келсе, деректер сәйкес келмейді және оларды біріктіру қиын болады.

Сондықтан HA кластерде primary тағайындау құқығын тек қатысушылардың көпшілігін көретін тарапқа немесе бөлек арбитрге беріңіз. Автоматты failover-ды орнатпас бұрын, «шындық» қайда сақталатынын және жүйе екінші жаққа жазуды қалай тыйып тұрғанын шешіңіз.

Минимальды архитектура: қанша түйін қажет және қандай рольдер

Автоматты авариялық переключение үшін минималды жұмыс схемасы көбіне үш түйінге тіреледі. Екі түйін (primary + replica) репликация жүргізе алады, бірақ желі немесе түйіннен біреу «аңтықса» кім дұрыс екенін сенімді шешу қиын. Үшінші қатысушы кворум үшін қажет, әйтпесе қарапайым тоқтап қалу немесе екі «басты» пайда болуы мүмкін.

Ең түсінікті минимум — бір жерде үш түйін (немесе егер желі сенімді және кешігулер болжамды болса, екі жерде де). «2 түйін + сыртқы witness» варианты да жұмыс істейді: witness — жеңіл виртуалды машина, басқа сегментте орналаса алады. Оның міндеті — шешім қабылдауға көмектесу, деректер сақтау емес.

Ролдер әдетте:

• Primary — жазбаларды қабылдайды және шынайы дерек көзі есептеледі.
• Replica (standby) — WAL қабылдап, primary-ге көтерілуге дайын.
• Кворум түйіні — DCS (мысалы, etcd/Consul) немесе witness/арбитр, тәсілге байланысты.

Маңызды: кворум түйіні деректерді сақтамайды. Ол split brain қауіпін төмендетеді.

Осы схема жұмыс істеуі үшін тек «үш машина» жеткіліксіз — тәртіп керек. Алдын ала PostgreSQL параметрлерін (репликация, таймауттар, слоттар, синхрондық режим), жаңартулар тәртібін (бір түйіннен бастап, репликаны тексеріп), және қолмен failover кімге жататынын анықтаңыз.

Әдеттегі минимум: репликация кешігуін және диск орнын бақылайтын мониторинг, барлық түйіндерде бірдей уақыт (NTP), тұрақты DNS және атаулар, және переключения туралы алерттер.

Және де HA болса да бэкаптар міндетті. Репликация түйіннің құлауынан қорғайды, бірақ адам қателігі, деректерді жою, нашар миграция немесе деректің жай ғана бұзылуынан сақтамайды. Бэкаптарды кластерден бөлек сақтау және қалпына келтіруді үнемі тексеріп тұру практикалық тәсіл.

Patroni немесе Pacemaker/Corosync: практикалық айырмашылықтар

Қымбат меншік кластерлерсіз PostgreSQL-тің сенімділігін қамтамасыз ету керек болса, әдетте екі тәсілдің бірін таңдайды.

Patroni нақты PostgreSQL және оның рольдері жағынан жұмыс істейді. Pacemaker/Corosync ОС деңгейінде ресурстарды басқарып, PostgreSQL-ді бір ресурс ретінде көтереді.

Patroni: PostgreSQL логикасы арқылы басқару

Patroni кластер логикасын базаға жақын ұстанады: кім primary, кім standby, қашан failover жасау керегі. Шешім сыртқы DCS (распределенное состояние) және саясаттарға сүйенеді: кандидат таңдаудағы шектеулер, реплика кешігуі, таймауттар.

Күнделікті пайдалану кезінде бұл көбіне болжамды және жылдам переключение береді, кластер мінез-құлқын DBA командасы оңай түсінеді.

Pacemaker/Corosync: ОС деңгейінде басқару

Pacemaker/Corosync компанияда Pacemaker стандарты болса, fencing және регламенттер қатаң болса және кластер бірнеше ресурстарды басқаруы тиіс болса жарайды.

Мұндағы конфигурация ресурс PostgreSQL-ды сипаттауды, орналастыру ережелерін, тәуелділіктерді және түйінді оқшаулау (fencing) сценарийін қамтиды. Бұл жол эксплуатациядан жоғары тәртіп талап етеді: systemd өзгерістері, желі параметрлері және ОС жаңартулары кластер ережелерін есепке алынып тексерілуі тиіс.

Таңдау әдетте қарапайым сұрақтардан басталады. Егер DBA білімдері күшті және рол логикасы маңызды болса — Patroni ыңғайлырақ. Егер Pacemaker тәжірибесі бар және қауіпсіздік бойынша fencing міндетті болса — Pacemaker/Corosync жарамды. Егер бірнеше ресурсқа біркелкі басқару керек болса (VIP, сервистер, қосымшалар) — Pacemaker жиі жеңеді.

Екі тәсілде де күрделілік бірдей: желі (кешігулер мен пакеттер жоғалту), апаттарды тұрақты тестілеу, өзгерістер бақылауы және адал RPO/RTO тексерісі. Қателіктің көбі процесстерден шығады: кім және қашан конфигурация өзгертеді, қалай ораламыз, бөліп тұру кезінде не істеу керек.

Желі талаптары: кешігулер, жоғалтулар, уақыт және қолжетімділік

PostgreSQL-дің сенімділігі үшін желі жиі «қалың каналдан» маңызды. Репликация мен кворум компоненттері кішкентай хабарламалармен жұмыс істейді, бірақ кешігулерге, пакеттер жоғалтуға және тұрақтылыққа қатты сезімтал.

Егер желі «кейде секіреді» болса, репликация жай ғана баяуламастан басқа, жалған авариялық переключенияға апарады.

Жоғары кешігулер реплика кешігуін және синхронды репликацияда транзакция растауын ұзартады. Пакеттер жоғалту мен джиттер (кешігулердің секіруі) кластердің heartbeat-ына және репликация байланысына зиян келтіреді: сессиялар кесіледі, түйіндер бір-бірін «көрмей» қалады, және кластер қате шешімдер қабылдай бастайды.

Уақыт, DNS және failover-ды бұзатын «оған ұқсас мелочи"

Түйіндердегі бірдей уақыт тек «әдемілік үшін» емес. NTP болмаса, таймауттар оғаш жұмыс істейді, метрикалар мен логтар шатасады. DNS те тұрақты болуы керек: егер DCS немесе түйін атауы кездейсоқ шешілсе, failover сәтсіз болады.

Бастапқыда мына нәрселерді тексеріңіз: түйіндер арасындағы тұрақты кешігулер, артық шыңдарсыз; межтүйіндік арнада пакеттер жоғалуы минималды; барлық түйіндерде NTP орнатылған; DNS сенімді немесе /etc/hosts статикалық жазбалар қолдануға негіз болса — солай жасаңыз. Мүмкін болса, межтүйіндік трафикке жеке желі немесе VLAN бөліп беріңіз (репликация, quorum).

Порттар және сегментация

Әдетте клиенттік қосылым және репликация үшін TCP 5432 қажет. Қосымша stack-ке байланысты Patroni сыртқы DCS-ке (etcd/Consul) қосылуды талап етеді, ал Pacemaker/Corosync өз арналары арқылы күйді бөліседі. Ең маңыздысы — межтүйіндік байланыс пен DCS-ке қолжетімділік екі жақтан да ашық және жолда сүзгіден өтпеуі.

Желінің кінәратына тән белгілер: реплика кейде догоняет, кейде кенеттен кейін қалды; логта reconnect және timeout көп; кластер менеджері периодты түрде түйінді «өлді» деп белгілейді; failover себепсіз іске қосылады; ping-тер көбіне қалыпты, бірақ сирек кешігулер мен пакет жоғалтулар байқалады.

Егер арзан HA құрсаңыз, өлшеуден бастаңыз. Белгіленген бір тәулікте межтүйіндік кешігуді, пакет жоғалтуды және тұрақтылықты өлшеу — өндірісте «құпия» failover-ды түзетуден арзан.

Quorum, split brain және fencing: қалай екі primary-ды болдырмау

Split brain — желілік үзіліс кезінде кластер екі бөлікке бөлініп, әрқайсысы өз жеке primary-ын көтеретін жағдай. Ең қиын сценарий — қолданбалар әр түрлі primary-ларға жазады, байланыс қалпына келгенде деректер бір-бірімен сәйкес келмейді.

Бұл әдетте PostgreSQL-де емес, байланыстағы мәселенің салдары: қысқа үзілістер, асимметриялық қолжетімділік (A B-ні көреді, бірақ B A-ны көрмейді), DNS мәселелері, кешігулер мен пакеттер жоғалту. Осы кезде HA менеджері бірден және анық шешім қабылдауы тиіс: кім primary қалсын, кім тоқтауы керек.

3 қатысушыда quorum «2 из 3» логикасы бойынша жұмыс істейді. Тек көпшілік шешім қабылдай алады. Бұл екі түйінді схемаға қарағанда қауіпсіз.

Кластер күйі қайда сақталатыны тәсілге байланысты. Patroni-де «шындық» сыртқы DCS-та: онда лидерлік блок, TTL және метадеректер сақталады. Pacemaker/Corosync-та Corosync мүшелік және quorum үшін жауап береді, ал Pacemaker ресурстарды іске қосып/өткізеді.

Кейде witness (arbitrator) қосады, сол арқылы толық серверсіз көпшілік алынады. Ол дауыстық көмек көрсетеді, бірақ кім primary болу керектігін сенімді анықтау мүмкіндігін толық шешпейді.

Split brain-ға қарсы негізгі механизм — fencing, көбіне STONITH арқылы («тоққа қосып өшіру»). Қатаң логика: егер кластер ескі primary шынымен өшкеніне сенімді болмаса, оны қуаттан ажыратқан дұрыс, екі primary тәуекелін алмастырудан гөрі.

Практикалық ереже: егер fencing-ті кепілдендіре алмасаңыз, split brain-нан қорғанысқа кепіл бере алмайсыз.

Іске қоспас бұрын мына нәрселерді тексеріңіз: түйінді қашықтан өшіру жолы бар ма, таймауттар секундтық желі «мигацияларына» жауап бермейтіндей орнатылған ба, quorum дұрыс есептеледі ме және желілік үзілісті нақты сынап көрдіңіз бе (бар болғаны postgres процесін тоқтатып қана емес).

Қадам-қадам: Patroni негізіндегі 3 түйінді кластер

Типтік Patroni сызбасы: екі PostgreSQL түйіні (primary және standby) және DCS. Минималды бір etcd түйіні мүмкін, бірақ ол DCS жоғалғанда әлсіз. Практикада DCS үшін де кворум қажет (мысалы, 3 узел etcd).

1) Түйіндер мен PostgreSQL дайындау

Барлығына бірдей орта жасаңыз: бір PostgreSQL нұсқасы, бірдей кеңейтімдер және деректер жолдары. Алдын ала порттарды, түйін атауларын және DNS орнатыңыз. Уақыт синхрондалғанын (NTP), түйіндер арасындағы порттар ашықтығын, дискінің кешігуі жоқтығын және файлдар лимитінің дұрыс екенін тексеріңіз.

Сондай-ақ репликация және әкімшілік үшін бөлек аккаунттар жасаңыз және postgresql.conf-те минималды репликация параметрлерін бекітіңіз.

2) Репликация: WAL, слоттар және базалық көшірме

Болашақ primary-да wal_level=replica орнатыңыз, max_wal_senders ең кемінде қажет мөлшерде қойыңыз және archive_mode қажет болса іске қосыңыз. Репликация слоттары қолданылса, WAL реплика оны алмағанша жойылмауы үшін пайдалы.

Standby-ды pg_basebackup арқылы немесе Patroni-дің bootstrap механизмін пайдаланып көтеріңіз. Реплика таза басталып, primary-ді көріп, lag өлшенетін болуы маңызды.

3) DCS (etcd) және қолжетімділікті тексеру

DCS орналастырып, кез келген түйін Patroni-ден кілттерді сенімді оқу/жазу жасай алатындығын тексеріңіз. DCS периодты қолжетімсіз болса, Patroni жиі лидерді қайта сайлауға мәжбүр болады.

4) Patroni конфигурациясы және failover саясаты

patroni.yml-де кластер атауы, DCS қосылым параметрлері және PostgreSQL баптаулары көрсетіледі. TTL, loop_wait (лидер жаңартудың жиілігі), retry_timeout, maximum_lag_on_failover және кандидат шектеулері (tags) сияқты параметрлер failover-дың мінезін анықтайды.

Клиенттердің қалай қосылатынын ойластырыңыз. Егер қосымшалар түйін IP-ға тікелей қосылса, переключение болғанда олар ескі primary-ге жазуды жалғастырады. Әдетте бір кіріс нүктесі қажет: виртуалды IP, балансировщик немесе прокси.

5) Тексеру: switchover және апат

Алдымен қолмен switchover жасап, жаңа primary жазуды қабылдайтынын және бұрынғы primary репликаға айналғанын тексеріңіз. Сосын primary-ді имитациялап (postgres тоқтату немесе желіні өшіру) автоматты failover уақытын өлшеңіз.

Пайдалы тесттер: қолмен switchover пен уақытын өлшеу, primary-ды тоқтатып автоматты failover күту, түйінді қайтарып standby ретінде қосу (қосымша тазартусыз), деректер жоғалтуды тексеру (соңғы транзакциялар мен lag), және қолданба тесті — автоматты қайта қосылды ма.

Егер бұл тесттер тұрақты өтсе, негізгі схема өміршең болып есептеледі, әрі қарай нақты жүктеме бойынша RPO/RTO өлшенеді.

Қадам-қадам: Pacemaker/Corosync астында PostgreSQL

Pacemaker/Corosync классикалық Linux HA ережелерімен және fencing міндетті болғанда жиі таңдалады. Төменде 3 қатысушы үшін логика: екі PostgreSQL түйіні және үшінші — дауыс беруші.

1) ОС және Corosync дайындау

Түйін атауларын бекітіп, NTP орнатып, кластерге бөлек желі немесе VLAN бөліп беріңіз. Мұнда жылдамдықтан гөрі болжамдылық маңызды. Corosync адрестер бойынша барлық қатысушылар арасында байланыс тұрақты екенін тексеріңіз; DNS немесе /etc/hosts ауысса болмайды.

2) PostgreSQL ресурсы: іске қосу, тоқтату және промоут

Pacemaker-ге primary мен standby дегенді түсіндіру керек. Әдетте PostgreSQL үшін OCF агент пайдаланылады — ол сервис басқаруды және репликаны көтеруді біледі.

Барлығы негізінен үш топ параметрге келеді: data directory жолы және health-check параметрлері, орналастыру шектеулері (primary тек бір түйінде болуы тиіс), және орын тәртібі (не бірінші көтеріледі және не бірге көшіріледі).

Егер синхронды репликация қолданса, оны промоут ережелерімен үйлестіріңіз. Әйтпесе кластер растайтын нәрсені күтуі мүмкін, ал оның жоқтығы кездейсоқ блокировка тудырады.

3) Клиент қосылымы: виртуалды IP

Қолданбалар үшін ең түсінікті әдіс — виртуалды IP (VIP), ол активті түйінге көшеді. Клиенттер бір адреске қосылады, ал Pacemaker VIP-ды және primary рөлін бірге ауыстырады.

VIP тек primary-да ғана көтерілуі керек. Егер ол standby-ға көшсе, қолданбалар қате түйінге жазуы мүмкін.

4) Fencing (STONITH): оны қосу ұсынылады

Fencing түйінді қатты ажыратып, ескі primary шынымен өшірілгеніне кепіл береді. IPMI/iDRAC/iLO немесе басқаша басқарылатын PDU бар болса, оны қолданған дұрыс.

Екі сценарийді бөлек тексеріңіз: "түйін қатып қалған" және "түйін желіні жоғалтқан". Fencing жоқ кезде Pacemaker жиі қолжетімділік пен дерек қауіпсіздігі арасында таңдау жасауға мәжбүр болады.

5) Қысқа апатты тексеріс

Қысқа тест жасаңыз: дерекқорға жазба жазыңыз, активті түйіннің қуатын немесе желісін өшіріңіз (тек postgres қызметін емес), VIP көшкенін және екінші түйіннің primary болғанын растаңыз. Содан кейін қанша транзакция жоғалғанын (RPO) және қолжетімділіктің қалпына келу уақытын (RTO) өлшеңіз.

Failover сценарийлері және RPO/RTO тексерісі

HA орнату жеткіліксіз. Нақты апаттарда жүйенің қалай әрекет ететінін алдын ала білу және RPO мен RTO-ны нақты өлшеу маңызды.

Үш апат сценарийі, оларды жаттықтыру қажет

1. Primary құлауы (процесс, ОС, қуат). Әр түрлі түрін бөлек тексеріңіз. Postgres процесін тоқтату қуат жоғалтудан оңай шешіледі.

2. Түйіндер арасындағы желі үзілісі және split brain қатері. Бұл ең қауіпті жағдай. Қорғаныш — quorum және fencing: «жеңілген» түйін тоқтатылып немесе оқшаулануы керек, содан кейін екінші ғана жазуға көшуі тиіс. Тестте нақты желілік үзілісті имитациялау маңызды, тек postgres процесін тоқтату жеткіліксіз.

3. Дисктің деградациясы немесе реплика кешігулерінің өсуі. Апат жасырын болуы мүмкін: primary жұмыс істейді, бірақ репликалар артта қалып, нақты RPO өседі. Мониторинг lag-ке жауап беруі және переключение саясаты үлкен кешігулердегі түйінді primary етуге жол бермеуі тиіс.

Фактикалық RPO және RTO қалай өлшеу

Адал сандар алу үшін тек переключение уақытын емес, деректер жоғалуын да тіркеңіз. Жай тәсіл: дерекқорда меткаға қатар жазып отыру (мысалы, әр секунд сайын timestamp қосу) және авариядан кейін жаңа primary қай меткаға жеткенін салыстыру.

Әр тестте мына мәліметтерді тіркеген дұрыс: инцидент уақыты, клиенттер алғаш қателік алған уақыты, жазудың қайта жұмыс істеген уақыты (RTO), авария алдында расталған соңғы транзакция және кейінгі алғашқы транзакция (RPO негізі), сондай-ақ lag-тің мәндері.

RPO репликация режиміне тәуелді. Синхронды режимде және дұрыс таңдалған синхронды standby бар болса, жоғалту нөлге жақын болады, бірақ RTO ұзаруы мүмкін. Асинхронды режимде RTO жиі аз, бірақ RPO — репликаның қанша ақпаратты өткізіп үлгермегені.

Тесттерді қауіпсіз өткізіңіз: терезені келісіңіз, откат жоспары болсын және нәтижелерді тіркеңіз (сценарий, RPO, RTO, қорытынды және түзетулер). Қайталаулардан кейін әдетте failover-ды бұзатын "мелочи" шығады: таймауттар, қате quorum есептеулері, тым агрессивті тексерулер, қолданбалардың қайта қосылуға дайын еместігі.

Жиі кездесетін қателер, тез чек-лист және келесі қадамдар

Көбінесе Postgres емес, оның айналасындағы конфигурациялар құлайды. Система «тірі» көрінеді, бірақ нақты апат уақытында проблемалар шығады: қысқа желі үзілістері, түйін қайта жүктелуі, диск деградациясы.

Типтік қателіктер:

• Таймауттар тым қысқа. Желі 2–3 секундқа «сеп» жасағанда кластер primary-ды өлі деп санап, рольдер ауысады.
• Шынайы fencing жоқ. Бұл split brain-ға әкеледі.
• Репликацияны бэкаптармен шатастыру. Репликация адам қатесін, жойылған деректерді немесе нашар миграцияны қорғамайды.
• Қолданбаның қосылуын дұрыс ойламау. Клиенттер түйін IP-ына тікелей қосылса, failover кейін олар қайда қосылу керектігін білмейді. Бір кіріс нүктесі (VIP, прокси, балансировщик немесе DNS қысқа TTL-мен) қажет және оны да переключение сияқты сынау керек.

Іске қосар алдында тез чек-лист

• Таймауттар желіні өлшеу негізінде орнатылған ба, сезім бойынша емес.
• Fencing конфигурацияланған және түйінді қашықтан өшіру мүмкіндігі тексерілген.
• Бэкаптар бар және бөлек стендте қалпына келтіру тексерілген.
• Қолданба primary-дың өзгеруін көтере алады (қайта қосылу, қосылым пулдары).
• Минимум үш жаттығу өткізілді: primary құлауы, желілік үзіліс және түйінді кластерге қайтару.

Келесі қадамдар

Практикалық жол — үш қатысушыдан тұратын пилоттан бастаңыз, мақсатты RPO/RTO бекітіңіз және тек содан кейін продқа жылжытыңыз. Параллель түрде құжаттама жасаңыз: кім failover туралы шешім қабылдайды, тұтастықты қалай тексереміз, түйінді қалай қайтару керек, қай метрикалар мен логтарға қарау керек.

Егер сіз инфрақұрылымда (қуат, диск, қашықтан басқару fencing, стойка және желі) шектелсеңіз, оны алдын ала ойластырыңыз. Мұндай жобаларда интегратор көмегі пайдалы: кластер мен DCS инфрақұрылымын орнатып, сервистік модельді қамтамасыз ете алатын провайдер. Мысалы, GSE.kz серверлер мен 24/7 қолдауды қамтамасыз етеді — бұл fencing пен қалпына келтіру аппаратқа және регламентке байланған жобаларда ыңғайлы.