Жоғары қолжетімді виртуализация кластері: желі, кворум, тәуелділіктер

Қандай ақаулардан өтуіңіз керек

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

Тұрақты виртуализация кластері үшін мақсатты ақаулар мен жауапкершілік шектерін алдын ала тізіп алыңыз:

• бір хосттың (түйіннің) істен шығуы
• бір коммутатордың немесе бір желілік сымның істен шығуы
• сақтау жүйесінің ақауы немесе оған бір жолдың жоғалуы
• екі площадка болса, площадкалар арасындағы байланыс үзілісі
• маңызды инфрақұрылымдық сервис (DNS, AD, NTP) істен шығуы

Одан кейін «сезім» емес, сандар арқылы талқылауға мүмкіндік беретін метрикалар керек. RTO — қызмет қанша минутта қалпына келуі тиіс. RPO — қанша дерек жоғалтуға болады. Сондай-ақ деградация терезесін белгілеу пайдалы: мысалы, алғашқы 10 минут ішінде пайдаланушылар баяулауды қабылдайды, бірақ қолжетімділік сақталады.

Ең жағымсыз тоқтаулар — жасырын SPOF-тан келеді. Классика: кластерге арналған бір ғана коммутатор, бір DNS-сервер, бір домен администратордың бір ғана есептік жазбасы, автоматтандыруды бұғаттайтын бір лицензия сервері немесе мониторинг сервері. Формальды түрде кластер тірі, бірақ сервис қосылмайды.

Түйіннің сөну сынағынан табысты өту — жай ғана «ВМ басқа хостта жүктелді» емес. Критерийлерді алдын ала анықтаңыз:

• пайдаланушылар мен қосымшалар шынымен кіріп, жұмыс істей алады
• деректер бүтін, синхронсыздық және жоғалған транзакциялар жоқ
• қалпына келтіру келісілген RTO/RPO шегіне сыйдырылады
• не болғаны және не істеу керектігі анық (логтар, оповещениелер, нұсқаулар)
• апаттан кейін жүйе алдын-ала болжамды күйге келеді, қолмен жасалатын «костыльдер»сыз

Мысал: бухгалтерия бір ВМ-де, домен мен DNS — басқа ВМ-де. Хост құлаған кезде кластер екі ВМ-ді де қайта қосады, бірақ DNS кейін қосылатын болса, адамдар «бәрі сынды» деп көрінеді, ал виртуалдар жұмыс істеп тұрады. Мұндай тәуелділіктерді енгізерден бұрын анықтау керек.

Қарапайым және артықшылығы аз HA архитектурасы

Отказоустойчивый (жоғары қолжетімді) виртуализация кластерін минималды схемадан бастап жинау оңайырақ — және кез келген бір элементтің істен шығуы бірден бәрін құлатпауы керек. HA-ның практикалық мәні — түйінді, портты, сымды немесе коммутаторды біреу істен шықса да жалпы тоқтауды болдырмау.

Кіші ЦОД немесе офис үшін минималды жұмыс конфигурациясы — 2–3 түйін және бірнеше логикалық бөлінген желілер. Физикалық түрде порттар аз болса да, барлығын бір «жалпы» трафикке араластырмау маңызды.

Әдетте жеткілікті жиынтық:

• кластерді басқару желісі (гипервизорға кіру, қызметтік трафик)
• виртуалдық машиналар желісі (пайдаланушы сервисі)
• сақтау жүйесіне қолжетімділік желісі (егер СХД бөлек болса)
• миграция желісі (ВМ-ді түйіндер арасында жылжыту)

Әрі қарай: VLAN арқылы бөліссеңіз бе, әлде «темірмен» бөлу әлде. Егер екі тәуелсіз физикалық сызық пен екі коммутатор бар болса және жүктеме тәуекелі төмен — VLAN жеткілікті. Сақтау немесе миграцияға бөлек порт жұбы керек, егер трафик ауыр (деректер базасы, бэкап, VDI) немесе VM желісіндегі қате сақтау қолжетімділігіне әсер етпеуі тиіс.

Жасырын SPOF көбінесе мына жерлерде пайда болады, «бәрі дубляцияланған сияқты», бірақ бір нүкте ұмытылған кезде:

• барлық стойкаға бір аплинк немесе бір коммутатор
• тәуелсіз коммутаторлары жоқ бір LACP-агрегат
• резервтелмеген VM желісінің бір ғана gateway-і
• кіріс пен сервистерге тәуелді бір домен контроллері немесе DNS

Орналастырудың екі анық жолы бар. Hyperconverged (сақтау түйіндер ішінде) кабельдер мен әкімшілендіру жағынан оңай, бірақ ресурстар мен желіні есептеу қажет. Бөлек сақтау рөлдерді айқынырақ бөледі, бірақ тағы бір маңызды құрамдас қосып, бөлек жолдар талап етеді.

Қарапайым ереже: кез келген бір қателік деградацияға әкелуі мүмкін, бірақ толық тоқтауға — жоқ.

Кластер желісі: трафикті бөлу және төзімділік

Желі HA-дағы «жасырын» SPOF бола береді: екі кабель бар сияқты, бірақ бір қате переключатель бүкіл кластерді құлатуы мүмкін. Алдымен жылдамдықтан емес, рөлдерді бөліп, резервтеу жоспарын түсіну маңызды.

Көп жағдайда бірнеше логикалық желі (көбіне VLAN) және әрқайсының өз мақсаты болуы керек. Management — хосттарды және кластерді басқару үшін, production — виртуалдық машиналар трафигі үшін, storage — СХД қолжетімділігі (iSCSI, NFS, FC over IP), replication — түйіндер арасындағы репликация, live migration — ВМ миграциясы. Барлығын бір жазық желіге араластырсаңыз, ВМ-нің «әдеттегі» жүктемесі миграцияға немесе дискке қолжетімділікке кедергі жасайды.

Резервтеу нақты болуы тиіс: екі коммутатор, әр хосттан екі аплинк, мүмкіндігінше әртүрлі кабель трассасы және қуат көзі. Кіші офисте бұл ToR-коммутатор жұбы және әр серверге екі желі порты болуы мүмкін; критикалық жүйелер үшін production және storage үшін бөлек жұптар қажет.

Жиі қателік — каналдарды агрегаттау. LACP, MLAG және ұқсас схемалар бір коммутатор жағы қате болғанда екі линк те блокталатындай етіп орнатылуы ғажап емес. Алдын ала келісіңіз: кім LACP режиміне, таймерлерге, hashing-ке жауапты және бір қатысушы істен шыққанда не болады.

MTU және jumbo frames бойынша ереже қарапайым: жолдың бүкіл траекториясын бақылап тұратын жерде ғана қосыңыз. Егер бір бөлігі 9000, ал басқа 1500 болса, қызық тайм-ауттар пайда болады: ping жауап береді, ал сақтау жүйесі «құрылады».

Енгізбес бұрын мінімалды тексерулер:

• хосттағы бір портты өшіріп, сақтау мен байланыс үзілмейтінін тексеру
• бір коммутаторды өшіріп, түйіндер мен ВМ қолжетімділігін тексеру
• тест аймағында Loop жасау, STP және порт қорғанысын тексеру
• барлық жол бойынша MTU-ны тексеру (әсіресе storage және migration)
• LACP қателігі кезінде желі толықтай жоғалмайтынын тексеру

Егер жобаны интегратормен жасасаңыз, бұл тексерулерді қабылдаудың міндетті шарты ретінде бекітіңіз. Интеграция тәжірибесінде (соның ішінде GSE.kz деңгейіндегі серверлер мен инфрақұрылым негізінде) дәл осындай тесттер HA-ның бір коммутаторда тұрып қалғанын тез көрсетеді.

Кворум және split-brain-нан қорғау

Қарапайым тілмен кворум — кластердің түйіндер немесе желі жоғалған кезде кімнің жұмысын жалғастыратынын шешетін ереже. Кворумсыз кластер екі жақта бірдей «тірі» болуға тырысуы мүмкін, әрі бұл көбіне проблемамен аяқталады.

Неліктен split-brain қауіпті

Split-brain — түйіндер бір-бірімен байланысын жоғалтқанда ақша, бірақ әрқайсысы өзін бастапқы деп есептеп, виртуалдық машиналарды іске қосқанда пайда болады. Ең жаман сценарий — бір VM екі жақтан бірдей сақтау жүйесіне жазып, файлдық жүйе бұзылады және транзакциялар жоғалады.

Кворум дәл осы сәтте кластердің бір «жартысын» жұмысқа қалдыру немесе екіншісін қауіпсіз режимге аудару үшін қажет.

Witness: қандай түрлері бар және қайда орналастыру керек

Кворумға қосымша дауыс ретінде witness (куәгер) қосады — 1:1 дауда шешім қабылдауға көмектеседі.

Варианттар:

• сыртқы witness ретінде бөлек сервер немесе сервис
• диск-куәгер (барлық түйіндерге қолжетімді ортақ диск немесе том)
• басқа площадкада немесе сегментте орналасқан witness

Қойылымның негізгі ережесі: witness түйіндер сияқты бір себеппен «өшпеуі» керек. Егер екі хост пен witness бір коммутаторға, бір ИБП-ге немесе бір байланыс сызығына тәуелді болса, бұл қорғау емес, иллюзия.

Кіші офис үшін практикалық нұсқа: екі түйін серверлік кабинетте тұрсын, ал witness басқа шкафта немесе бөлмеде, немесе басқа сегменттегі кішкене бөлек хостта болсын — тәуелсіз қуат пен басқа коммутаторға портпен.

Жоғары қолжетімді виртуализация кластері үшін мына тесттер мен критерийлерді алдын ала жазып қойыңыз:

• түйіндер арасындағы байланыс үзіліп, witness тірі болғанда кім активті болады
• witness жоғалғанда түйіндер байланысы сақталса кластер жұмысын жалғастыра ма
• бір түйін құлаған кезде ВМ-дер екіншіде іске қосылады ма
• бір желі сегменті (мысалы, storage-желі) үзілісі
• коммутатордың бір мезгілдегі істен шығуы, оған witness байланбауы тиіс

Егер инфрақұрылымды сатып алу мен іске қосу үшін жобаласаңыз, бұл тесттерді қабылдауға енгізіңіз.

Домендік және инфрақұрылымдық тәуелділіктер: не HA-ны тоқтатады

Тіпті жоғары қолжетімді кластер түйіннің құлауын аман өткізсе де, сыртқы тәуелділіктер себепті «көтерілмей» қалуы мүмкін. Виртуалдық машиналар қайта қосылады, бірақ сервистер іске қосылмайды: DNS табылмайды, IP берілмейді, доменге кіру болмайды, сертификаттар бұзылады, уақыт сәйкес келмейді.

Ең қауіпті жағдай — бүкіл площадканың жоғалуы. Егер барлық негізгі сервистер (AD, DNS, NTP, PKI) тек бір жерде болса, резервте кластер жұмыс істесе де, пайдаланушылар кіре алмайды, қосымшалар дерекқорларды көрмейді, администратор инфрақұрылымды басқара алмайды.

Апат кезінде локалды түрде әр площадкада немесе тәуелсіз қуат пен желі бар бөлек аймақта қолжетімді болуы тиіс минимум:

• DNS (және сервис аймақтары үшін жергілікті резолверлер)
• DHCP (немесе маңызды түйіндер үшін статикалық адрестер)
• NTP (кемінде бір сенімді уақыт көзі)
• AD/LDAP (кем дегенде екі домен контроллері, әртүрлі отказ домендерінде)
• PKI/сертификаттар және лицензия сервисі (егер қолданбалар оларсыз іске қосылмаса)

Бұл қызметтерді орналастыруға қатысты практикалық ереже: барлық «негізгі» тәуелділіктерді бір гипервизорға қоймаңыз.

• инфрақұрылымдық рөлдер үшін бөлек ВМ-дер (барлығын бір ВМ-ге қоспаңыз)
• әртүрлі хосттар мен стойкаларға тарату
• жиі қызмет көрсетілетін хостқа бір ғана DNS/DC қоймау
• бір коммутатор істен шыққанда да оларға қолжетімділікті қамтамасыз ету

Уақытқа ерекше көңіл бөліңіз. NTP-ның синхронсыздығы доменге кіруді бұзуы, Kerberos-ақаулары, мерзімі өткен сертификаттар және API қателеріне әкеледі. Түйіннің құлау тестінде тек ВМ-нің іске қосылғанын ғана емес, пайдаланушылардың шынайы кіруін және уақыт пен сертификаттарға тәуелді сервистердің жұмысын тексеріңіз.

Сақтау және қолжетім жолдары: ең жиі тоқтау себебі

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

Ең жиі жасырын SPOF былай көрінеді: сақтау әр түйінге бір кабельмен, бір коммутатор арқылы немесе бір SAN-зона арқылы қосылған. Формальды түрде екі түйін бар және HA қосулы, бірақ бір порт немесе бір коммутатор бүкіл кластердің тағдырын шешеді.

Жолдарды резервтеу: жұмыс істейтін минимум

Жақсы базалық схема тәуелсіз жолдарға айналады: СХД-да екі контроллер (немесе екі тәуелсіз сақтау түйіні), екі коммутатор, әр серверде екі желілік немесе FC-порт және гипервизорларда multipath. Сол кезде кез келген бір элемент жоғалғанда ВМ-дер деректерді оқып-жаза береді.

Типтік тұзақтар, оларды іске қоспас бұрын табу маңызды:

• бір «негізгі» том (datastore) резерв жұбысыз немесе анық қалпына келтіру стратегиясы жоқ
• барлық үшін бір SAN-зона, конфигурация қатесі барлық түйіндердің қолжетімін бірден үзіп тастауы мүмкін
• асимметриялық жолдар (біреуі жылдам, екіншісі «құрал ретінде»), апат кезінде кешігулер күрт өседі

Алдын ала және тестте не тексеру керек

Жауапкершілік шегін алдын ала анықтаңыз: кластер ВМ-дерді қайта жүктеп, әрекеттер тәртібін қамтамасыз етеді; ал СХД томдарға дұрыс блоктау және төзімді қолжетімділік қамтамасыз етуі тиіс.

Тесттерде тек «ВМ тірі ме» емес, жүктеме астындағы мінез-құлықты тексеріңіз:

• бір жолды (порт, кабель, коммутатор) өшіру және кешігулердің өсуі
• СХД контроллерлер арасында ауысу және қалпына келтіру уақыты
• multipath дүрус жұмыс істейді ме, өшкен жолда «жабысып» қалмай ма
• жол оралғаннан кейін ешқандай шторм немесе қайталама ақау жоқ па
• журнал мен ВМ консистенттігі бұзылған жоқ па

Практикалық мысал: екі түйінді кластер S200 деңгейіндегі серверлерде сенімді көрінуі мүмкін, бірақ нақты төзімділік осы екі түйіннің кез келген бір қателікте бірдей сақтауды қалай көретініне байланысты анықталады.

HA кластерді жобалаудың қадамдық жоспар

Жақсы жоғары қолжетімді кластер баптаудан емес, нақты күтулерден басталады. Қандай ақауларды және қандай уақытта өткізетініңізді алдын ала келістірмесеңіз, «қағазда HA» болады да, нақты өмірде тоқтаулар болады.

1) Мақсаттар мен ақау сценарийлерін бекітіңіз

Ең ықтимал 3–5 жағдайды сипаттаңыз: бір хосттың істен шығуы, коммутатордың құлауы, линк үзілуі, сақтау қолжетімсіздігі, AD/DNS мәселесі. Жанында талапты көрсетіңіз: қанша минутқа дейін тоқтау рұқсат етіледі және қанша дерек жоғалтуға болады. Бұл кворум, желі және сақтау таңдауына тікелей әсер етеді.

2) Схема салыңыз: желілер, рөлдер, тәуелділіктер

Бір схемада кластер түйіндері, коммутаторлар, басқару, VM-трафик, сақтау, миграция секілді жеке желілер және witness пен сыртқы тәуелділіктер: AD, DNS, NTP, жаңарту репозиторийлері болуы тиіс. Жиі болатын тұзақ: «HA бар, бірақ AD құлады, және кейбір сервистер көтеріле алмайды».

3) Маңызды ВМ-дерді орналастыруды ойластырыңыз

Алдын ала қандай ВМ-дерді бір түйінде ұстамау қажет екенін және қайсысын бірінші қосу керектігін шешіңіз. Анти-аффинити ережелері, іске қосу преференциялары және ресурстар резервациясы (CPU/RAM) көмекші болады, сонда түйіннің құлауын қалғаны жабыспай өтеді.

Іске қосардан бұрын минималды баптауды бекітіңіз:

• ВМ орналастыру және іске қосу приоритеттері
• кворум параметрлері және байланыс жоғалғанда мінез-құлық
• witness ролін кім және қайда атқаратыны
• overcommit шектеулері және ресурс резервтері
• міндетті тәуелділіктер тізімі (AD/DNS/NTP/сақтау)

4) Мониторингті алдын ала баптаңыз

Алерттер іске қосуға дейін керек: линк жоғалту, кешігулердің өсуі, дискілер деградациясы, датастарлардың толуы, кластер қателері және флаптаушы порттар. Хаттамалар инфрақұрылым бір бөлігі қолжетімсіз болса да хабарлауға тиіс.

5) Тесттер мен кері қайтару жоспарын жасаңыз

«Қалай бұзамыз» және «қалай қалпына келтіреміз» қысқа сценарийін жасап, жауаптыларды және жұмыс тәртібін бекітіңіз. Тек түйіннің құлауын емес, «жартылай» апаттарды да сынау: түйіндер арасындағы байланыс үзілуі, бір коммутаторды ажырату, witness-ті қолжетімсіз ету. Тесттен кейін схеманы және нұсқауларды жаңартыңыз.

Егер жаңа темірге кластер құрып жатсаңыз, қажетті желі карталарын және накопительдерді қолдауын, сондай-ақ сервистік қолдауды алдын ала тексеріңіз. Қазақстандағы ұйымдар үшін жиі жеткізу мерзімдері мен жергілікті қолдаудың болуы маңызды, сондықтан GSE.kz сияқты жергілікті өндірушілер мен 24/7 қолдауды бастапқы кезеңде ескерген жөн.

Офис немесе филиалға арналған қарапайым схема мысалы

Филиалға жиі талап: 2 түйінді кластер, бір сервер құлаған кезде негізгі сервис жоғалтпайтын болу (файлдар, 1С, пошта, терминалдар). Бұл жақсы минимум, бірақ «жасырын» SPOF-тарды алдын ала жою керек.

Схема: екі виртуализация хосты (мысалы, GSE S200 Series серверлері), ортақ сақтау (немесе платформа қолдайтын болса жергілікті дискілер мен репликация) және шешім үшін үшінші компонент — witness. Виртуалдар: бизнес-сервистер мен домен қызметтері.

Рөлдерді былайша бөлу ұсынылады:

• DNS/AD: кемінде екі домен контроллері, әр түйінде біреуі (екі бөлек ВМ). Сол кезде бір түйін құлағанда логин, DNS және GPO жоғалмайды.
• NTP: домен контроллерден әдеттегі түрде емес, бөлек сенімді уақыт көзі (сыртқы және ішкі). Барлық түйіндер мен DC бірдей синхрондалсын.
• Witness: сол сақтау немесе сол түйінде болмауы керек. Идеал — бас офисіндегі шағын VM немесе филиалда басқа қуат пен басқару желісінде тұрған кішкентай құрылғы.
• Мониторинг: бөлек ВМ (бас офиске қоюға болады), апат кезінде не істен шыққанын көру үшін.

Филиалдағы ең жиі қауптер — storage үшін бір коммутатор немесе басқару желісі үшін бір gateway. Егер бір коммутатор өшсе, екі түйін «тірі» болғанмен, сақтау қолжетімсіздігіне ұшырайды. Егер gateway құласа, басқару мен witness бір мезгілде жоғалып, лидерлік үшін дау туындайды.

Бір түйін құлаған жағдайда сервистер әдетте екіншіге көшеді: кей ВМ жылдам, кейбірі баяу (диск тексерулері, қолданба жүктелуі). Қалған түйінге жүктеме күрт өседі, сондықтан оның ресурстары сақтандырылуы тиіс.

Түйіндер арасындағы байланысты үзу кезінде кворум шешім қабылдайды: көп дауысы бар жақ жұмысын жалғастырады. Witness 1+1 схемасында split-brain болмауы үшін қажет: бір түйін жұмыс істейді, екіншісі VM-ді тоқтатады және байланыс қалпына келгенше күтеді.

Жиі қателер және жасырын SPOF-тар

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

Біріншісі — желі. Барлық кластер, сақтау және басқару трафигі бір коммутаторға немесе бір аплинк арқылы өтсе, сіз бүкіл инфрақұрылым үшін бір ғана «светшоқ» аласыз. Түйін құлау тесті көркем болуы мүмкін, бірақ нақты коммутатор құлаған кезде кластер барлықымен бірдей байланыс жоғалтып, болжанбайтын күйде болады.

Екінші — witness-тің сол жерде орналасуы. Егер witness сол стойкада және сол желіде тұрса, ол да көмектеспейді. Нәтижесінде кворум формалдылыққа айналады: бір инцидентте түйіндер мен арбитр екеуі де жоғалады.

Үшінші — домендік тәуелділіктер. AD, DNS және NTP бір ВМ-де, резервсіз және қалпына келтіру жоспары болмағанда, сол ВМ-нің бұзылуы «жоғары қолжетімді кластерді» тек хосттар жиынтығына айналдырады: жүйелер логин, атаулар және уақытты жоғалтады. Мысалы: AD бар ВМ қуаттан кейін қосылмайды, хосттар атаумен СХД-ға қол жеткізе алмайды, кей сервистер іске қосылмай қалады және қолмен шешуге бірнеше сағат кетеді.

Тағы бір қате — күту: HA бэкаптың, қалпына келтірудің және қарапайым документацияның орнын баспайды. Соларсыз түйін құлауынан аман қалуыңыз мүмкін, бірақ деректі жою, шифрлаушы шабуыл немесе әкімші қателігінен аман қалмайсыз.

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

Пилот алдында қысқа өзін-өзі тексеру:

• басқару мен сақтауға кемінде екі тәуелсіз желі жолы бар ма
• witness түрлі отказ доменінде орналасқан ба (қуат, стойка, желі)
• AD/DNS/NTP таралған ба және олардың қалпына келу сценарийі бар ма
• бэкаптар және тексерілген қалпына келтіру бар ма
• жоспарлы жұмыстар тәртібі және инцидент кезінде шешім қабылдайтын тұлғалар анықталған ба

Егер жаңа серверлерге кластер құрып жатсаңыз (филиал немесе мемлекеттік орган үшін), осы тармақтарды ТИЗ-ге алдын ала енгізіңіз. Бұл бірінші өшіруден кейін «жасырын» SPOF-тарды емдеуден әлдеқайда арзан болады.

Түйіндердің құлауы мен желі үзілістерін тексеру чек-листі

Тестке дейін

Отказоустойчивосты тестін мини-маневр ретінде өткізіңіз: мақсат анық және оралу нүктесі бар. Бастамас бұрын ВМ және кластер конфигурациясының соңғы резервтік көшірмелерін тексеріп, жұмыс терезесін келісіңіз және нақты кері қайтару жоспарын дайындаңыз.

Сондай-ақ критикалық сервистер мен олардың иелерінің қысқа тізімін жасаңыз: мысалы, бухгалтерия, пошта, 1С, VDI, файлдық шары. Бұл қай сервис «өздігінен көтерілуі тиіс» екенін тез анықтауға көмектеседі.

Тест кезінде

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

• Желі: хосттағы бір портты өшіріп, содан кейін бір коммутаторды өшіріп, gateway істен шығуын тексеріңіз. Егер түрлі MTU бар болса (мысалы, storage үшін), апат кезінде жасырын пакет жоғалтулар болмауын қадағалаңыз.
• Кворум: witness-ті өшіріп, кворум сақтала ма тексеріңіз. Содан кейін түйіндер арасындағы байланысты үзіп, қайсысы активті екенін бақылаңыз.
• Тәуелділіктер: апат кезінде DNS/NTP/AD қолжетімділігін тексеріңіз. Әкімші басқару консоліне кіре алатынын және сертификаттарға тәуелді сервистер дұрыс жұмыс істейтінін растаңыз.

Қарапайым мысал: бір хостты өшіру ВМ-дердің 2–3 минутта көшуіне әкеледі, бірақ кейбір пайдаланушылар кіре алмай қалады, себебі DNS сол ВМ-ге тәуелді болды және уақытылы қосылмады. Бұл кластер қатесі емес — жасырын тәуелділік.

Әр сценарийден кейін фактілерді тіркеңіз: қызметтер бойынша нақты RTO, не сынғаны, қандай алерттер келді немесе келмеді және қандай түзетулер қажет (желіні өзгерту, witness орналастыру, DNS/NTP/AD-ты қайта бөлу, автозапуск тәртібі).

Келесі қадамдар: схеманы жұмыс жобасына дейін жеткізу

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

Жинақ құжаттар, оларды жинау және тексеру үшін беріңіз:

• схема (физикалық және логикалық): түйіндер, желілер, коммутаторлар, сақтау, witness, басқару нүктелері
• ақаулар матрицасы: не сыналды (түйін, линк, коммутатор, домен контроллері), не болуы тиіс (ВМ қайта жүктеу, деградация, тоқтату)
• тест жоспары: іс-әрекет тәртібі, күтілетін уақыт, нәтижені кім растайды
• тәуелділіктер реестрі: DNS, AD, NTP, DHCP, PKI, бэкап, консольге қолжетім
• кері қайтару жоспары: егер тест немесе жаңарту дұрыс өтпесе қызметті қалай қайтару керек

Содан кейін әсері бар приоритет бойынша жүріңіз. Алдымен желідегі және witness-дегі айқын SPOF-тарды жойыңыз (бір коммутатор, бір линк, witness бір отказ доменінде). Содан кейін домендік және инфрақұрылымдық тәуелділіктерді тексеріңіз (мысалы, кластер ВМ-ді көтере алады, бірақ DNS/NTP жоқ). Тек соған дейін барып сақтау мен барлық жолдарды мінсіздікке жеткізіңіз.

HA үшін темірді таңдағанда запас қойыңыз. Бір түйін құлаған кезде қалғандары жүктемені «қызыл аймаққа» ұрынбай көтеруі керек. Алдын ала талап ету пайдалы: екі блок питания, трафикті бөлу үшін жеткілікті желі порттары, диск схемасының анықтылығы және өсуге резерв, қашықтан консольге қолжетім.

Күрделі желі (бірнеше VLAN, L3, қауіпсіздік зоналары), екі және одан көп площадка немесе мемлекеттік сатып алу талаптары болса, интегратор шақыру тиімді.

Қазақстанда GSE серверлері отандық өндірісте болғаны ыңғайлы: жобаны жинау, тестілеу және 24/7 қолдау бір контурда болуы мүмкін. Бұл тек жинау емес, тұрақты түрде тестілеу және нәтижелерді бекіту қажет болғанда пайдалы.