Hitachi VSP E-Series критикалық қолданбаларға: SLA чек-листі

Критикалық жүйелер үшін жоғары SLA қайдан басталады

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

Көбінесе SLA-ды «бұзады» сирек апаттар емес, тұрмыстық мәселелер: тіректегі қуат жоғалуы, бір контроллердің қайта жүктелуі, SAN-желінің үзілгені, multipath-тың дұрыс бапталмауы, әкімшінің жұмыс уақытында тәуекелді операция орындауы. Сондықтан Hitachi VSP E-Series деңгейіндегі СХД-ны критикалық жүйелерге таңдау тек енгізу схемасы ойластырылған кезде мағыналы: қуат пен порттар бойынша резервтеу, дұрыс zoning, өзгерістер жоспары және таралған жауапкершілік.

Екі компаниядағы бірдей массивтер әртүрлі нәтиже беруі мүмкін. Бірінде ақау шамалы байқалады, өйткені деректерге тәуелсіз екі жол бар және жаңартулар процедура бойынша орындалады. Екіншісінде — бір коммутатор, бір жол, «уақытша» баптаулар және күннің ортасында жаңарту. Соңында мәселе «СХД сәтсіз болды» сияқты көрінеді, бірақ шын мәнінде ақау оны қоршаған архитектура мен эксплуатация тәртібінің нәтижесі болады.

IOPS пен көлемді талқылай бастамас бұрын, қолжетімділік пен қалпына келтірудің базалық параметрлерін бекітіңіз. Минимум қажет:

• RPO (қанша дерек жоғалуы мүмкін),
• RTO (қанша уақытта қалпына келтіру қажет),
• жоспарлы терезелер (қашан өзгерістерге рұқсат етіледі),
• қабылданатын тәуекелдер (бизнес қандай сирек оқиғаларды қабылдайды).

Бизнеспен SLA туралы сөйлесуді «жылдамдық» емес, нақты талаптар деңгейінде өткізу үшін пайдалы сұрақтар:

• Тоқтау нені білдіреді: қолданбаның қолжетімсіздігі, деградация, функциялардың бір бөлігінің жоғалуы ма?
• Әр жүйе үшін айына нақты қанша минут тоқтау рұқсат етіледі?
• Қанша дерек жоғалуы қабылданады: 0 секунд, 5 минут, 1 сағат?
• Қандай «пик» кезеңдер бар, оларда жұмыстарға тыйым салынған (есеп беру, төлем кезеңдері)?
• Авариялық жоспарды тоқтату, кері қайтару және іске қосу туралы шешімді кім қабылдайды?

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

SLA-ны нақты техникалық талаптарға айналдыру

SLA тек санға және тексерілетін жағдайларға аударылса ғана пайдалы. Одан бастаңыз: қандай тоқтау жалпы қабылданады. Мысалы, 99,99% қолжетімділік жылына шамамен 52 минут тоқтауды, ал 99,9% — шамамен 8 сағат 46 минутты құрайтынын есте сақтаңыз. Осы минуттар мен сағаттарды апаттар, деградация, қалпына келтіру және жоспарлы жұмыстар бойынша жіктеу маңызды.

Қызмет қолжетімділігі мен сақтау жүйесінің қолжетімділігін ажыратыңыз. СХД қолжетімді болуы мүмкін, бірақ бизнес-қызмет қолжетімсіз болуы мүмкін — себебі қосымша деңгейінде, SAN-желісінде немесе кластерде ақау бар. Сондықтан талаптарды екі деңгейде бекіткен жөн: сақтау платформасы не қамтамасыз етеді (қосалқы мүмкіндік, компоненттерді ауыстыру уақыты, қызмет көрсету режімі) және бүкіл жүйеге не қажет (серверлер, желі және процестерді қосқанда).

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

SLA эксплуатация кезінде тексерілетін болу үшін алдын ала метрикалар мен шектер туралы келісіңіз. Әдетте бақылауға тұрарлық:

• оқу және жазу кешігулерінің 95/99-процентильдері;
• компонент сәтсіздігінен кейінгі деградация режимінде жұмыс уақыты;
• қалыпты өнімділікке оралу нақты уақыты;
• көшірмеден қалпына келтіру жылдамдығы мен сәттілігі;
• инцидент бойынша реакция және сервис келу уақыты.

Жеке-жеке жоспарлы жұмыстар не екенін бекітіңіз. Микрокод жаңарту, батарея ауыстыру, полк кеңейту, DR тесттері жоспарлы жұмыстың құрамына кіреді ме? Критикалық жүйелер үшін Hitachi VSP E-Series негізінде тоқтатусыз қызмет көрсету және нақты жұмыс терезесі талап етілуі жиі кездеседі, сондықтан жоспарлы әрекеттер күтпеген тоқтауға ұқсамасын.

Резервтеу: қандай ақауды тоқтатусыз өткізуі тиіс

Жоғары SLA қарапайым ережеден басталады: кез келген жалғыз ақау қызметті тоқтатпауы керек. Hitachi VSP E-Series деңгейіндегі СХД үшін бұл тек «екі контроллер» ғана емес, сонымен бірге қолданбадан дискке дейінгі барлық жолдың екіталай болуы дегенді білдіреді.

Нақты қандай элементтер дубльденуі тиіс

Жүйені тізбек ретінде қараңыз. Оның ішінде жұп болмайтын немесе айналып өту жолы жоқ элемент — болашақ тоқтау нүктесі.

• Контроллерлер: екі контроллер (active-active немесе автоматты takeover бар), кэшті айнаға алу және кэш қорғанысы (батарея/flash) платформаның талаптарына сәйкес.
• Порттар және ішкі жолдар: front-end және back-end, шиналар және полк қосылымдары бір сымның сәтсіздігі диск бөлігін қолжетімсіз етпеуі тиіс.
• Қуат: СХД-де кемінде екі тәуелсіз қуат блогы, үстеме жағдайда стояктағы әртүрлі PDU/сызықтардан беру жақсы.
• Салқындату: резервті вентиляторлар және бір модуль сәтсіз болғанда қызып кетпеу мен өнімділіктің күрт төмендемеуі.
• Сақтау желісіне қолжетімділік: екі тәуелсіз SAN-фабрика (Fabric A және Fabric B), бөлек коммутаторлар, порттар және кабельдер.

Тіпті мінсіз СХД хосттарда бір жол қалса көмектеспейді. Multipath бапталған және тексерілген болуы керек: екі HBA (немесе iSCSI/NVMe-oF үшін екі желілік порт), әртүрлі слоттар/шиналар, әртүрлі коммутаторлар. Маңыздысы — тек «қосу» емес, бір жол үзіліп қалғанда I/O қатып қалмай жалғасатынына көз жеткізу.

Схемада SPOF жоқ екенін қалай тексеру керек

Қажет әдіс — әр элементті «ойша өшіру» және LUN/томдарға қолжетімділік не болатынын тексеру.

• Бір контроллерді өшіріңіз: қолжетімділік сақталады ма, кэш жоғалмай ма, өнімділік қабылданбайтын деңгейге түседі ме?
• Бір SAN-коммутаторды алыңыз: екінші фабрика арқылы жол сақталады ма?
• Сервердегі бір HBA/портты өшіріңіз: қолданба жұмысын жалғастыра ма?
• Бір PDU-ны сөндіріңіз: екі БП СХД немесе сервердің екі блоктары бірден өшіп қалмай ма?
• Бір кабельді үзіңіз (FC/Ethernet): физикалық екінші кабель бар ма және ол сол маршрутта жүрмей ме?

Практикалық мысал: егер дерекқорға бір сервер екі контроллерге қосылған болса, бірақ екі кабель бір SAN-коммутаторға түссе, сол коммутатордың істен шығуы «дискілерге кенет қолжетімсіздік» сияқты көрінеді. Қағазда бәрі дубльденген, ал іс жүзінде SPOF қалады.

СХД ішіндегі деректер қорғау: тек RAID-тен ғана емес

RAID жиі сенімділіктің негізгі жауабы ретінде қабылданады. Бірақ жоғары SLA үшін бұл жеткіліксіз: диск ақауы, массивті қалпына келтіру және жоспарлы жұмыстар кезінде деректермен не болатыны маңызды. Бұл Hitachi VSP E-Series базасында дерекқорлар, виртуализация және қаржылық транзакциялар үшін әсіресе өзекті.

RAID деңгейі жүктеме профиліне сәйкес таңдалады. «Салмақты» кездейсоқ жазбалар (мысалы, OLTP) үшін болжаулы кешігу маңызды. Үлкен көлемдер мен үлкен дискілер үшін басты қауіп — ұзақ rebuild, сонда екінші ақаудың болуы айтарлықтай ықтимал. Практикада ең жақсысы — «ең жылдам RAID» емес, қалпына келтіруді дерек жоғалтпай және өнімділіктің күрт төмендемей өткізе алатын шешім.

Hot spare те жай ғана «белгі» емес. Қанша резервті диск бар, олар класы мен көлемі бойынша сәйкес пе, реконструкция қалай бапталған: rebuild басымдылығы, полкқа жүктемені шектеу, бірнеше ақау үшін ережелер — бұл маңызды. Нашар реконструкция саясаты жасырын тоқтауды тудыруы мүмкін: формальды жүйе жұмыс істеп тұрғанымен, қолданбалар таймауттарға байланысты қателер бере бастайды.

Сатып алу және эксплуатацияда не тексеруге болады

Жиі ұмытылатын практикалық пункттер:

• Snapshots: сақтау жиілігі мен тереңдігі. Снимоктар логикалық қателерден қорғауы тиіс, бірақ массивтің метадеректерін және қосымша жазуды тым жүктемемеуі керек.
• Шифрлау: кілттер қайда сақталады, кімде рұқсат бар, контроллер алмастырылғаннан немесе апаттан кейін қалпына келтіру қалай жүреді.
• Дискілердің қызмет ету циклы: бір партиядан бірнеше тоқтау болмас үшін жасы бойынша жоспарлы алмастыру.
• Деградацияны мониторингі: шектер, хабарландырулар және инженер әрекеттері rebuild басталмай тұрып.

Мысалы: әр 5 минут сайынғы snapshot қателікті өшіруден кейін деректі қайтаруға көмектеседі, бірақ жүктеме қосады. Пикик уақыттардағы әсерді алдын ала өлшеп, қолданба иесімен компромисс келісу жақсы.

Репликация және DR схемалары: моданы емес RPO/RTO-ны таңдаңыз

Hitachi VSP E-Series-ті критикалық қолданбаларға қарастырғанда, технология атауларынан бастамаңыз — екі саннан бастаңыз: RPO және RTO. Қалғанының бәрі осы сандарды қамтамасыз етудің тәсілі.

Локалдық отказоустойчивтік (бір площадка ішіндегі) контроллерлер, полкалар, порттар, SAN жолдары және кейде желінің бір бөлігімен болатын сәтсіздіктерді жабады. DR (екінші площадка) өрт, объектінің қуатсыздығы, ғимараттың қолжетімсіздігі немесе қаладағы ірі апат сияқты оқиғалар үшін қажет.

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

Асинхронды репликация желілерге оңайрақ, бірақ RPO есептелетін болады. Оны есептеу: өзгерістер орташа көлемі, тасымалдау терезесі және репликация қызметінің тоқтау уақыты. Пиктерді (мысалы, күннің жабылуы) және тасымалдау кезегінің өсуін міндетті түрде ескеріңіз.

Active-active немесе active-passive таңдау көбінесе операцияларға келіп тіреледі.

Active-passive көбіне қолданбалар мен қолдау үшін оңайырақ: бір орталық жұмыс істейді, екінші жүктемені қабылдауға дайын болады.

Active-active RTO-ны азайтады, бірақ тәртіпті талап етеді: бірдей баптаулар, бөліктенген желіні бақылау және даулы жағдайларда кім басым екені туралы ережелер.

DR-жоспарының қысқаша практикалық минимумы:

• Әр қызмет үшін RPO/RTO бекітіңіз, «жүйе бойынша» емес;
• Ауыстыру триггерлерін және шешім қабылдаушыларды сипаттаңыз, жалған ауысуларды болдырмау үшін;
• Ауыстыруды мерзіммен және үлкен өзгерістерден кейін тестілеңіз;
• Нәтижелерді журналдаңыз: уақыт, дерек жоғалуы, қолмен қадамдар, жұмыс істемеген заттар;
• Сценарийлерді бөліңіз: площадка апаты, СХД апаты, қолданба апаты, адам қатесі.

Мысал: төлем жүйесіне RTO 30 минут және RPO 0–5 минут қажет болса, жиі локалдық отказоустойчивтік «кіші» ақаулар үшін және екінші площадкаға асинхронды репликация RPO-ны шектеп отыратын комбинация қолданады, үнемі тестілеп тұру арқылы RPO пикке сай ұсталады.

Микрокод жаңарту саясаты: жайдан жай тоқтауға ұрынбаңыз

СХД микрокодын жаңарту — жай рәсім емес. Жоғары SLA жүйелерінде бұл қатені жою және осалдықтарды жабу тәсілі, бірақ дұрыс ережелерсіз — күтпеген тоқтаулардың бір көзі. Hitachi VSP E-Series үшін алдын ала қашан жаңартатындығын, үйлесімділікті қалай тексеретінін және мәселе шықса не істейтінін сипаттаңыз.

Әдетте комбинация қолданылады. Жоспарлы жаңартулар (мысалы, тоқсан сайын) болжамдылық береді. Оқиға бойынша жаңартулар қажет болғанда — маңызды осалдық, бұрын белгілі қате немесе өндірушінің сіздің конфигурацияға ұсынысы. Саясатта шұғыл жаңарту себебі және шешім қабылдаушы көрсетілуі маңызды.

Барлық жұмыстардан бұрын тексеріңіз: үйлесімділік тек СХД-де ғана емес, қоршаған ортаға қатысты да тексеріледі. Көп жағдайда мәселе микрокод емес, оның байланысы: multipath нұсқалары, HBA-драйверлер, коммутаторлардың прошивкалары, zoning параметрлері және FC-адаптер прошивкалары.

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

Қызмет көрсету терезесі SLA-ны «жеп қоймауы» үшін алдын ала үш нәрсені бекітіңіз:

• оралу жоспары және қайтару нүктесі (өнімділік деградациясы немесе жол қателері шықса не істеу);
• жұмыстарды тоқтату критерийлері (қандай симптомдарда тоқтатамыз және ораламыз);
• жауапкершілікті бөлу: жоспарды кім дайындайды, кім орындайды, нәтижені кім қабылдайды.

Практикада интегратор сценарий мен тәуекел тізімін дайындайды, эксплуатация терезені және қолданбаның қолжетімділігін бекітеді, ал бизнес алдын ала келісілген метрикалар бойынша қалыпқа қайтарылуын қабылдайды.

Қызмет талаптары: 24/7 қолдауды дұрыс таңдау

24/7 қолдау «жалпы қажет» емес — нақты тәуекелдерге қарай шешіледі. Hitachi VSP E-Series негізіндегі критикалық қолданбалар үшін түнде және демалыста қандай оқиғалар жедел шешілуі тиіс, қайсысы жұмыс уақытын күте алатынын алдын ала анықтаңыз.

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

Реакция мен қалпына келтіруді араластырмаңыз

Келісімшартта реакция мен қалпына келтіруге қатысты бөлек көрсетіңіз.

Реакция — «инженер байланысқа шығып, талдауды бастағанға дейінгі уақыт».

Қалпына келтіру — қызметті жұмыс күйіне қайтаруға дейінгі уақыт. Уақытша шешім де есепке алынады, егер ол тоқтауды жойса.

Шартта нақты қалпына келтіру көрсетілмесе, чатта жылдам жауап алсаңыз да, бірнеше сағатқа қызмет тоқтап қалуы мүмкін.

Запчасти, мониторинг, эскалация және есеп беру

Келісім жасамас бұрын нақты практикалық мәселелерді нақтылаңыз, олар инциденттің нәтижесін шеше алады:

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

Мысал: түнде «репликация қызылға өтті», бірақ пайдаланушылар әлі жұмыс істейді. Егер мониторинг 24/7 болмаса, мәселені таңертең ғана көреді де RPO жоғалады. Егер мониторинг болса, бірақ аймақта запчастылар жоқ болса, қалпына келтіру логистикаға тіреледі. Сондықтан уәде емес, өлшенетін пунктер мен түсінікті процесс талап етіңіз.

Жоғары SLA үшін конфигурация таңдау қадамдары

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

Содан кейін мақсатты SLA таңдап, оны ақшаға аударыңыз. Бизнес үшін тоқтау минутының нақты бағасы белгілі болса, резервтеу деңгейін, DR схемасын және сервисті келісу оңайырақ болады.

Практикалық жұмыс тәртібі:

• қолданбалардың талаптарын жинаңыз: IOPS/кешігу, көлемдер, жұмыс терезелері, өсу, қызметтердің критикалықлігі;
• SLA және қабылданатын тоқтауды анықтап, «тәуекел бюджетін» бекітіңіз;
• RPO/RTO бекітіп, осы цифрларға сәйкес репликация мен DR таңдаңыз;
• end-to-end отказоустойчивтікті жобалаңыз: хосттар, SAN, массив, қуат, площадкалар;
• микрокод жаңарту саясатын, ауысым тесттерінің графигін және қабылдау критерийлерін келісіңіз.

«Резервті блоктары бар СХД» дегеннен аспаңыз. SLA көбіне түйіспелерде түседі: бір SAN-коммутатордың жұбы жоқ, кабель трассалары бірдей, екі контроллер немесе екі қуат блогы бір PDU-да, есептелмеген порт лимиттері немесе хосттағы кезектер.

Мысал: төлем жүйесіне RPO нөлге жақын және RTO 15 минут қажет болса, бұл әдетте синхронды репликацияны талап етеді (егер сай ара қашықтықтағы кешігулер мүмкіндік берсе), плюс дайын сценарийлер. Егер площадкалар алыс болса, синхрондық мүмкін болмауы ықтимал — онда адал түрде асинхронды репликация таңдап, процесстермен өтем жасаған жөн.

Жаңартулар мен апаттармен қалай өмір сүретініңізді бөлек бекітіңіз. Келісімдерде жалпы сөздер емес, тексерілетін параметрлер болуы керек:

• микрокод жаңартулардың терезелері мен жиілігі, проблема болғанда оралу тәртібі;
• DR-тесттердің тәртібі және сәтті ауысу критерийлері;
• реакция уақыты мен қалпына келтіру уақыты (араластырмаңыз);
• 24/7 запчастылар мен инженерлер, эскалация маршруттары;
• приемкада қандай өлшенетін көрсеткіштер: кешігу, өткізу қабілеті, нода ақауындағы жұмыс.

Интегратор тартсаңыз, бір құжатты талап етіңіз: «талап -> техникалық шешім -> тест» матрицасы. Ол SLA қағазда емес, іс жүзінде жабылғанын тез көрсетеді.

Жоғары SLA үшін СХД таңдау кезінде жиі кездесетін қателіктер

Қарапайым қателіктер — қымбат СХД да тоқтаудан сақтай алмайды, егер талаптар мен архитектура «сезіммен» жиналған болса. Төменде Hitachi VSP E-Series таңдау кезінде және жалпы жоғары SLA үшін СХД таңдағанда жиі кездесетін қателіктер.

Архитектура және есептеулердегі қателіктер

Бірінші проблема түрі — резервтеу қағазда бар, бірақ нақты дерек жолында жоқ. Екі контроллер бар деп сатып алып, кейін бір SAN-коммутатор, бір HBA немесе multipath баптамасында бір жол қалдырылады. Соның нәтижесінде контроллер емес, «кішігірім» элемент қызметті тоқтатады.

Екінші типтік қате — RPO мен RTO-ны нақты цифрлармен бекітпеу. «Әрқашан жұмыс істеуі керек» деген сөз инцидент кезінде дауға әкеледі: бір топ үшін минуттар қабылданса, басқалар үшін тек синхронды репликация және автоматты фейловер қажет.

Үшінші — өнімділікті сынақ ортада есептеу. Сынақтар нақты өндірістік IOPS/кешігу профилін қайталамаса, қолданба жауап күтуі мен қалпына келтіру жылдамдығы жөнінде қате үміт пайда болады.

Эксплуатация және қолдаудағы қателіктер

Жоғары SLA — бұл сондай-ақ өзгерістер тәртібі мен тәртіп. Микрокод саясаты, қызмет көрсету терезелері және оралу критерийлері болмаса, жаңарту тәжірибеге айналып, күтпеген тоқтау тәуекелін тудырады.

DR-процедураларды төмен бағалау да жиі кездеседі. Репликация бапталған болуы мүмкін, бірақ қалпына келтірудің тұрақты тесттері, рұқсаттар, желілер, DNS және іске қосу тәртібі тексерілмесе, нақты апат бәрін кеш ашады.

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

Мысал: қаржылық жүйеде түнгі есептеу 2 сағатқа созылады. Егер RTO бекітілмеген болса, апатта «таңға дейін қалпына келтіреміз» дегенді қабылдауға болады, бірақ бизнес өңдеу терезесін жоғалтады. Егер RTO 15 минут деп бекітілсе, репликацияға, өнімділіктің жүктемеге немесе сервистік қолдауға нақты талаптар қойылады.

Сценарий мысалы: төлем жүйесі және 99,99% талап

Банк төлем жүйесін елестетейік: 24/7 жұмыс істейді, SLA 99,99% — жылына шамамен 52 минут тоқтау, оған жоспарлы жұмыстар да кіреді. Екі ЦОД бар: негізгі және резервтік. Мақсат қарапайым: нода, SAN-коммутатор немесе бір площадканың істен шығуы ұзақ инцидентке айналмауы тиіс.

Hitachi VSP E-Series деңгейіндегі сақтау үшін RPO мен RTO-ны схема таңдаудан бұрын цифрлармен бекіту әдетте орындалады. Мысалы: транзакциялардың көбіне RPO 0 және негізгі ЦОД жоғалғанда RTO 15 минут.

Репликация: синхронды немесе асинхронды

Егер ЦОД-тар арасындағы кешігу аз және канал тұрақты болса — синхронды репликация таңдалады, RPO 0 алу үшін. Егер қашықтық үлкен немесе канал төмен кешігу кепілдемесе — асинхронды схема таңдалып, адал түрде RPO-ны (мысалы, 30–120 секунд) қабылдайды, бірақ байланысқа төзімділігі артады.

Қорытынды шешімнен бұрын тексеріңіз:

• шынайы кешігу мен джиттерді пиковые сағаттарда;
• қолжетімді өткізу қабілеті мен оның резерві;
• split-brain сценарийі және кім актив болатыны туралы ереже.

Резервтеу және тесттер бойынша минимум

Көпір элементте ақауға ұшырамау үшін минимум:

• екі тәуелсіз SAN fabric және хосттарда multipath;
• қолданба мен дерекқор кластері, кворум атағын анықтау;
• қуат және басқару желілерінің резервтенуі;
• аймақ, коммутатор және контроллер апатына бөлек жоспар.

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

Приемка және аудит үшін алдын ала дайын жинақ: архитектура схемасы, қызметтер бойынша RPO/RTO матрицасы, runbook ауысу үшін, тест хаттамалары, өзгерістер журналы (микрокодпен қоса) және 24/7 қолдаудың контактілері мен реакция уақыты, эскалация мәліметтері.

Қысқа чек-лист — финалдық таңдау және сатып алу алдында

Сатып алудан бұрын СХД-ны және қоршаған ортаны соңғы рет тексеру маңызды. Күшті сақтау платформа да байқалмай қалған SPOF немесе DR-ды тексермеген жағдайда қызметтен құтқара алмайды.

Спецификацияға қол қою алдындағы жылдам тексеру

Әр пункт бойынша жазбаша жауаптар жинаңыз: не жасалған, кім жауапты, қалай тексеріледі.

• SPOF: екі тәуелсіз қуат және электр тізбегі, екі SAN-коммутатор, хостта екі HBA, СХД-да разнесенные порттар, multipath бапталған және тексерілген. DNS, аккаунттар, құқықтар және консольге қолжетімділікті бөлек тексеріңіз.
• DR және репликация: тесттер кестесі бар (жиілігі сізге сай), анық сценарийлер (площадка апаты, массив жоғалуы, логикалық қате), жауаптылар тағайындалған және нақты ауысу уақыты өлшенген.
• Микрокод: жаңартулар регламенті бекітілген, терезелер келісілген, ОС, HBA және SAN микрокодымен үйлесімділік тексерілген. Оралу жоспары және оралатын критерийлер бар.
• 24/7 сервис: реакция және қалпына келтіру уақыты, запчастылардың қай жерде екенін нақтылау, эскалация және инциденттен кейінгі есептер көрсетілген.
• Приемка: өшіру тесттері, сәттілік критерийлері және нәтижелерді кім қол қоятыны алдын ала анықталған.

Осы тексеруден кейін әдетте архитектурада немесе процестерде не жетіспейтіні көрініп қалады.

Келесі қадам — бастапқы деректер жинап, алдын ала жоба тексерісін интегратормен, мысалы GSE.kz-пен өткізу. GSE.kz Қазақстанда жүйелік интегратор және есептеу техникасын өндіруші ретінде жұмыс істейтіндіктен, тексеріс барысында инфрақұрылым мен қолдауды бір жоспарға жинау ыңғайлы болады.

Минималды деректер пакеті: қолданбалар тізімі және олардың RPO/RTO, ағымдағы IOPS/кешігулер, SAN картасы, ОС және драйвер нұсқалары, өзгерістер графигі және жұмыс терезелері.