Lenovo ThinkSystem DM Series үшін тоқтаусыз СХД ауыстыру

Қолданыста тоқтаусыз СХД ауыстыру деген не

Практикада тоқтаусыз СХД ауыстыру дегеніміз — пайдаланушылар жұмысын жалғастыра береді, ал негізгі сервистер (пошта, дерекқорлар, файлдар, виртуалды жұмыс үстелдері) тоқтамайды. Дегенмен кейбір «шекаралы» тәуекелдер қалады: жолдарды қысқа уақытқа ауыстыру, LUN-дардың қайта тіркелуі, multipath жаңартулары немесе нақты қосымшаға сезімтал жағдайда қысқа үзіліс.

Маңыздысы: бұл тек «жаңа all-flash СХД алу» емес. Жоба бірнеше компонентке тәуелді: массив, SAN және Ethernet желілері, гипервизор, қосымшалар, резервтеу және мониторинг. Бір элементтің нашар жұмысы жобаны массив жағынан емес, тәуелділіктер арқылы құлатады: zoning/masking қателері, жүктелген аплинктер, ескі HBA драйверлері, multipath-тің қолдамайтын нұсқалары немесе резервтік интеграциялардың ұмытылуы.

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

Жобаның басқарылуын қамтамасыз ету үшін алдын ала артефакттер дайындайды. Минимум келесідей:

• ағымдық және мақсатты архитектура схемасы (SAN, Ethernet, зоналар, жолдар)
• бақылау нүктелері мен жауапты тұлғалар көрсетілген қадамдық жұмыс жоспары
• тез әрі «батылдықсыз» орындалатын қайтару жоспары
• тәуекел матрицасы және «тоқтау» шарттары (кешігулер, қателер, қолжетімділік бойынша)
• ауыстыру уақытындағы коммуникация жоспары

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

Алдын ала тексеру және табыс критерийлері

Тоқтаусыз СХД ауыстырудың алдын ала көріністі өтуі үшін бастапқы нүктені бекіту керек. Бұл формальдылық емес, тар шекараларды алдын ала көруге және табыс нені білдіретінін келісуге мүмкіндік береді.

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

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

Байланыстар мен үйлесімділікті бөлек инвентаризациялаңыз: FC/iSCSI/NFS/SMB, multipath схемасы, HBA және драйвер нұсқалары, MPIO/DSM баптаулары, jumbo frames параметрлері (қолданылса), сондай-ақ қолжетімділікке әсер ететін барлық зоналар, VLAN және ACL.

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

Табыс критерийлерін санмен бекіту артық болмайды:

• шың уақыттағы кешігулер келісілген шектен жоғары болмауы
• IOPS пен өткізу қабілеті бастапқы деңгейден төмен болмауы
• жол қателері нөлге жақын және multipath дұрыс жұмыс істеуі
• сынақ сценарийінде RPO/RTO орындалуы
• деректер бүтіндігінің расталуы және қалпына келтіру тесттерінің сәтті өтуі

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

Желілерді дайындау: тұйықсыз SAN және Ethernet

Желі көбінесе «тоқтаусыз СХД ауыстыру» сценарийіндегі негізгі тәуекелге айналады. All-flash массив төмен кешігулерді бере алады, бірақ оған тек қана хранилищамен жолдар тұрақты, болжамды және жасырын тар шекарасыз болғанда қол жеткізуге болады.

Бірінші шешім — протокол мен топология. SAN үшін әдетте FC немесе iSCSI қолданылады. Екі жағдайда да сақтау трафигін оқшаулау маңызды: iSCSI үшін бөлек VLAN және FC үшін бөлек фабрика (немесе айқын бөлінген VSAN). Резервтік көшіру, репликация және пайдаланушы трафигін бір кең доменде түсінікті ережелерсіз араластырмаңыз.

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

Миграцияға дейін жиі өнімділікке кедергі келтіретін баптауларды тексеріңіз:

• MTU: барлық жол бойынша бір өлшем (iSCSI үшін jumbo frames жиі қолданылады, бірақ тек барлық жерде бірдей болса)
• Flow control: Ethernet-те микроөткізілімдер мен кешігулерді болдырмау үшін саналы түрде қосыңыз
• QoS: сақтау трафигі басқа критикалық трафикпен бөліссе қажет
• LACP: агрегаттау үшін жарамды, бірақ хештеу мен жол симметриясын тексеріңіз
• Хосттардағы мультипасинг: барлық жолдардың көрініп тұрғанын және «тек біреуі белсенді» сценарийі жоқтығын растаңыз

FC үшін zoning пен алиастарды жеке тексеріңіз: қосымша зоналар, қиылысулар, қате WWPN-дар жоқ па, және «бір инициатор тобы — бір таргет жиынтығы» принципіне сай ма. iSCSI үшін адресация, маршрутизация, ACL және discovery-дің дұрыс желілерде көрінуі тексеріледі.

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

Қысқа мысал: бір сегменттегі қабаттағы коммутатор мен ядро арасында MTU басқа болып қалады. Нәтижесінде фондық көшірмелер қалыпты жүрсе де, шың IOPS кезінде пакеттер жоғалту және кешігулер өседі. Бұл тек жолдағы параметрлерді толық тексергеннен кейін ғана шешіледі.

Lenovo ThinkSystem DM Series-ті миграцияға дайындау

Тоқтаусыз ауыстыру тыныш өтуі үшін жаңа Lenovo ThinkSystem DM Series-ті енді екінші күннен бастап ең маңызды сервистерді қабылдайтындай етіп дайындаңыз. Мақсат — көшіру алдында желі, қолжетімділік және жүктеме орналастырудан сюрприздерді жою.

Басты «гигиена» мен тексерулерден бастаңыз. Контроллерлер мен домендегі уақыт, дұрыс DNS және NTP — логтар үшін ғана емес, Kerberos пен аудит қызметтерінің дұрыс жұмысы үшін маңызды. Содан кейін түйіндер, коммутаторлар мен хосттар арасындағы байланыс: пинг, MTU (jumbo frames қолдансаңыз), дұрыс VLAN және асимметриялық маршрутизацияның болмауын тексеріңіз.

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

Миграция басталмас бұрын орындауға тиісті практикалық минимум:

• DNS/NTP және басқару мен деректер желілерінің барлығының қолжетімділігін тексеріңіз.
• Тесті том немесе LUN жасап, бір хостқа жалғап multipath-ты тексеріңіз.
• Инициатор топтары (FC/iSCSI) мен экспорт ережелерін (NFS) немесе құқықтарды (SMB) алдын ала шаблон бойынша орнатыңыз.
• Атаулар, блок көлемдері, теңестіру және қолжетімділік саясаттары қосымшалар талаптарына сай екенін тексеріңіз.
• Қызметтік тапсырмаларға (snapshot, журналдар, уақытша көшірмелер) және болжанған өсуге орын қалдырыңыз.

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

Миграция жоспары: әдістер мен жұмыс тәртібі

Миграция жоспары — қысқа әрі нақты құжат: деректерді қалай Lenovo ThinkSystem DM Series all-flash-қа тасымалдаймыз, қандай ретпен, нәтижені қалай тексереміз және қажет болса қалай қайтамыз. Одан тыс жоспар болмаса, тоқтаусыз ауыстыру біртұтас әрекеттер жиынына айналады.

Миграция әдісін қалай таңдау керек

Әдіс деректердің қайда тұрғанына және кім басқаратына байланысты: хостта, гипервизорда немесе СХД-да. Әдетте бір негізгі жол және бір резерв таңдалады.

• Host-based миграция: ОЖ деңгейінде көшіру. Файл деректері мен қарапайым сервистерге жарамды, бірақ рұқсаттар, жолдар мен синхрондау уақытта тәртіп талап етеді.
• Storage-based миграция: томдар/LUN-дарды массивтердің өз құралдарымен көшіру. Көп деректер үшін және қайталанатын процесс қажет болғанда ыңғайлы, бірақ зоналар, маппинг пен multipath үйлесімдігін алдын ала тексеру керек.
• Репликация: алдымен деректерді синхрондап, кейін қысқа ауыстыруды жасайсыз. Үлкен көлемдер үшін және кішкентай терезе талап етілгенде тиімді.
• vMotion/Storage vMotion: егер негізгі жүктеме виртуализацияда болса, бұл көбіне ең жұмсақ жол. Бірақ трафик шыңдары мен кешігулерді бақылау қажет.

Қайдан бастау керек: реттілік

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

Тұрақтылық үшін алдын ала қай жерде quiesce (I/O-ды тоқтату) қажет екені, қай жерде snapshot жеткілікті екені және «қысқа ауысу сәті» қалай өтетіні анықталуы керек. Онлайн миграция кезінде де әдетте координатталған кішігірім интервал қажет болады, мысалы монтирования нүктелерді ауыстыру немесе datastore-тарды қайта жалғау үшін.

Атаулар беру ережелерін (томдар/LUN, datastores, хост топтары және маппинг) алдын ала бекітіңіз. Біркелкі схема қате қосылымдардың тәуекелін азайтады.

Қайтару жоспары формальд емес, нақты болуы тиіс: не қайтарылады (маппинг, жолдар, монтирование нүктелері), қалай бүтіндікті тексереміз және қайтару жаңа деректерді қайта жазбайтынына қалай көз жеткіземіз. Минимум — бақылау нүктелері, әрекеттер тізімі және қайта жалғастыру/қайтару шешімін қабылдау критерийлері.

Қадамдық тоқтаусыз миграция

Жаңа массивті ескімен параллель түрде қосқаныңыз жөн. Алдымен барлық қажетті хосттардың томдарды бірдей көретінін, multipath пен жол теңгерім саясаттарын тексеріңіз. Қосымша бір жол жоғалғанда қолданбалар ауысуды байқамауы маңызды.

Одан әрі жұмысты кішкене партиялармен орындаңыз. Осылайша мәселені ерте табуға және критикалық жүйелерге әсер етпеуге болады.

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

1. Жаңа СХД-ны өндіріске қосып, барлық SAN фабрикаларын және қажетті Ethernet VLAN-дарын жалғаңыз, хосттарда мақсатты жол саясатын қосып, әр серверде кемінде екі тәуелсіз жолдың бар-жоғын тексеріңіз.

2. 1–2 аса маңызды емес сервис бойынша пилот жасаңыз. Бастапқы метрикаларды тіркеп, көшіруден кейін оларды салыстырыңыз (кешігулер, IOPS, өткізу қабілеті). Мысалы: түнде бір файл ресурсын және бір кішкентай кластерлік томды көшіріп, таңертең жауап беру уақытын мен лог қателерін тексерді.

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

4. Финалдық синхрондау мен монтирование нүктелерін ауыстыру үшін қысқа терезеде ауыстырыңыз. Мақсат — ауысу сәтінде параметрлердің мүмкіндігінше азы ғана өзгеруі және деректердің алдын ала өзекті болуы.

5. Ауыстырғаннан кейін қолданбаны пайдаланушы көзінен тексеріңіз: кіру, негізгі операциялар, есептер. Содан кейін схемаларды, инвентаризацияны, LUN/том сипаттамаларын, сондай-ақ мониторинг порогтары мен объектілердің атауларын жаңартыңыз, солайша жаңа метрикалар ескі деректер арасында жоғалмайды.

Әр қадамда өнімділікті бақылау

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

Жақсы базалық тест — типтік жұмыс күні: бірнеше VM, дерекқор немесе файл сервисі, плюс фондық тапсырмалар (резервтеу, антивирус, есептер). Бастапқы массивте, Lenovo ThinkSystem DM Series-ке қосқан соң және финалдық ауысудан кейін нәтижелерді алыңыз.

Қандай метрикалар жинау керек

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

• Кешігулер (latency): орташа және p95, оқу және жазу бойынша бөлек.
• IOPS және өткізу қабілеті (MB/s): latency сияқты кезеңдер бойынша.
• Кезек тереңдігі: LUN/томдар мен хост жағында, қай жерде «торап» пайда болып тұрғанын түсіну үшін.
• Хосттар: CPU ready (виртуализация үшін), storage queue, қателер және multipath флаппингі.
• СХД: контроллер жүктемесі, кэш, диск топтарының/агрегаттардың жағдайы және фондық процестер (rebuild, tiering, дедупликация).

Қабылдау және деградация кезінде не істейміз

Қабылдау шекараларын алдын ала санмен бекітіңіз. Мысал: критикалық сервистер үшін p95 кешігу бастапқыдан 20%-дан артық нашарламауы тиіс, ал сол жүктеме профиліндегі IOPS төмендемеуі керек.

Егер деградация байқалса, ретпен әрекет етіңіз:

• p95 пен кезекті салыстырыңыз: сол жүктеме кезінде кезек өсуі көбіне жолда тар шекара барлығын білдіреді (HBA, SAN, порттар, MTU, multipath policy қате).
• Тесті және фондық тапсырмалардың СХД-да бір уақытта келе жатпағанын тексеріңіз (инициализация, rebuild, snapshot, репликация).
• Хосттар CPU ready немесе виртуализация лимиттеріне жетіп тұрған жоқтығын тексеріңіз — әйтпесе мәселе хранилищада емес.
• Миграцияның параллелизмін уақытша азайтыңыз, сонда өндірістің IOPS-тарын «жеп алмайсыз».

Мысал: деректерді көшіру кезінде p95 кешігу 2 мс-ден 6 мс-ге өсті. Хосттағы кезек өсіп жатыр, multipath қателері жоқ. СХД контроллерлерінің жүктемесі жоғары және фондық операциялар белсенді. Көбіне фондық тапсырмаларды жылжытса немесе миграция жылдамдығын шектесе, жағдай жақсарады; содан кейін сол сценариймен тестті қайталап әсерін растаңыз.

Жұмыс істемеу және қалпына келтіру тесттері: міндетті тексерістер

Тесттерді ауыстыру күні емес, алдын ала өткізу жақсы — ескі СХД әлі бар кезінде. Сол арқылы миграциядан кейін сервистер кабель, порт немесе түйіннің бұзылуын қалай өткеретінін тексересіз.

Минималды сынақтар жиынтығы

Бастаңыз күнделікті жиі болатын қателерден: нашар контакт, кездейсоқ шығарылған патчкорд, коммутатор портын өшіру. Әр тестте тек «пинг» емес, қосымшалардың мінез-құлқын бақылаңыз: ілінісу бар ма, I/O қателері немесе кешігулер көбейе ме.

• Бір жолдың істен шығуы: бір кабельді немесе портты өшіріп, I/O екінші жол арқылы ешқандай қолмен әрекетсіз жалғасатынын тексеріңіз.
• Коммутатор немесе фабрика істен шығуы: бір SAN коммутаторын (немесе IP арқылы қолжетімд болса Ethernet тармағын) оқшаулап, томдарға қолжетімділік сақталатынын тексеріңіз.
• Контроллердің жоспарлы failover-ы: өндіруші нұсқаулығы бойынша ауыстыруды бастаңыз және негізгі сервистердің (дерекқор, файл бөлісу, виртуализация) қалай әрекет ететінін байқаңыз.
• Нормалдыққа оралу: қуат/сілтеме қалпына келтірілгеннен кейін жүйе штаттық күйге қайтып келіп, «адал» қалпына келтірілуін тексеріңіз.

Тесттің сәтті өткенін қалай түсінеміз

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

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

Тоқтаусыз ауыстырудағы жиі қателер

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

Ең көп кездесетін тұзақтардың бірі — сақтау трафигін және пайдаланушы трафигін бір желіге оқшаулаусыз араластыру. Нәтижесінде резервтік көшірулер, жаңартулар және массивтік көшірулер iSCSI/NFS/SMB немесе репликациямен бәсекелесіп, пайдаланушылар «баяулауды» сезінеді.

Екінші типтік мәселе — MTU сәйкессіздігі. Мысалы, серверлерде jumbo frames қосылған, ал бір коммутаторда немесе аплинкте MTU 1500 қалды. Бұл миграцияда кездейсоқ өнімділік төмендеуі, қайта жіберулер мен кешігулердің тұрақсыз шыңдарын береді.

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

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

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

Алдын ала көптеген проблемаларды анықтайтын қысқа тексеріс:

• сақтау және пайдаланушы желілері бөлінген бе (VLAN/физикалық бөлу, қажет болғанда QoS)?
• барлық жолда MTU бірдей ме: сервер, коммутатор, аплинктер, СХД порттары?
• жолдар шынымен тәуелсіз бе (түрлі коммутаторлар/модульдер/қуат, ортақ сәтсіздік нүктесі жоқ па)?
• «алдында» метрикалар бар және «кейін» салыстыруға анық шек бар ма?
• миграция уақыты мен темпі таңдалғанда түнгі тапсырмалар мен резервтеу терезелері ескерілді ме?

Ауыстырудан бұрынғы қысқа чек-лист

Lenovo ThinkSystem DM Series all-flash-қа финалдық ауысым алдында 20–30 минут уақыт бөліп, жағдайды тексеріңіз. Тәжірибеде әдетте барлық мәселелер массивтен емес, асығыстық пен келісімсіздіктен шығады.

Алдымен ұйымдастырушылық аспектіні тексеріңіз. Өзгеріс терезесі ИТ ғана емес, сервистер иелерімен де келісілген болуы керек. Жұмыс кезінде шешім қабылдайтын бір жауапты және коммуникация үшін бір адам тағайындаңыз, және вендор, желі тобы мен виртуализация әкімшілерінің байланыс мәліметтерін қолыңызда ұстаңыз.

Техникалық тармақтарды тексеріңіз:

• Актуалды резервтік көшірме бар және кем дегенде бір критикалық сервис (мысалы, дерекқор немесе файл ресурсы) қалпына келтіріліп тексерілген.
• Желіні тесттер растайды: екі тәуелсіз жол, дұрыс SAN зоналары немесе VLAN, бірдей MTU, порттарда қателер мен discard жоқ.
• Миграцияға дейінгі бастапқы өлшеулер тіркелген: кешігулер, IOPS және өткізу қабілеті негізгі жүктемелер үшін, және кешігу бойынша мақсатты шек бар.
• Қайтару жоспары жазбаша: нені қалай кері қайтару, қанша уақыт алады және кім орындайды.
• Failover тесттері алдын ала өткізілген: бір жол, бір коммутатор немесе контроллер оқшауланып, нәтиже жазылған.

Останавливать критерийлерін де келісіңіз. Мысалы: кешігулер келісілген шектен 10 минуттан ұзаған жағдайда, ОС-та I/O қателер пайда болғанда немесе FC/iSCSI таймауттары артқан кезде миграция тоқтатылады.

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

Мысал сценарий: кеңседегі және ЦОД-тағы жұмыс істеп тұрған миграция

Шарттар: кеңседе және ЦОД-та екі виртуализация кластері бар. Оларда кешігулерге сезімтал дерекқормен бірге файл сервисі және бірнеше прикладтық жүйелер жұмыс істейді. Шың жүктеме таңертеңгі әдеттегі кірістерге тура келеді. Мақсат — тоқтаусыз СХД ауыстыру, пайдаланушыларға байқалатын регрессиясыз.

Ең алдымен жаңа Lenovo ThinkSystem DM Series all-flash тест контурында көтеріледі: сол SAN және Ethernet сегменттеріне қосылады, multipath, қолжетімділік саясаттары, драйвер нұсқалары және типтік операциялар (snapshot, клонинг, қалпына келтіру) тексеріледі. Тестте кешігулердің болжамды болуы және мониторингтің тәуелді метрикаларды жинауы расталуы керек.

Одан кейін кезең-кезеңімен өтеді: бірінші түндері шамамен 20–30% жүктемені, бірақ аса маңызды емес бөлігін көшіреді. Әр түннен кейін пауза жасап, «тыныш» мәселелерді табады: сирек болатын жол қателері, кезекке байланысты деградациялар, қате MTU немесе zoning баптаулары.

Оперативті бақылау бірнеше сигнал бойынша жүреді және алдын ала паузалар тағайындалады:

• негізгі LUN/томдарға арналған p95 оқу/жазу кешігуі
• multipath қателерінің өсуі, порттардың флаптары, CRC
• HBA/FC порттарындағы және хосттағы кезектер
• нақты IOPS және өткізу қабілеті бастапқы сызықпен салыстырғанда
• қосымшалардан келетін шағымдар (таймауттар, сұраулардың ұзарту)

Төзімділік тесттері келісілген терезеде жоспарланады: алдымен бір фабриканың жұмысы имитацияланады (оқшаулау/өшіру), содан кейін контроллердің failover-ы жасап тексеріледі. Маңыздысы — сервистер «түсіп» кетпеуі, кешігулер мен қателер рұқсат етілген шектерде қалуы.

Итогтық есепте бастапқы және алынған IOPS пен кешігулер (p95 қосылып) көрсетіледі, порт жүктемелері, жол қателері статистикасы, әр кезеңнің уақыты, нақты тәуекел және қабылданған шешімдер (паузалар, қайтарулар). Мониторинг баптауларын, алерт праговын, тексеру кестесін және тұрақты төзімділік тест сценарийлерін эксплуатация стандартына қосыңыз.

Миграциядан кейін: нәтижені бекіту және одан кейінгі қадамдар

Деректер жаңа СХД-да жұмыс істеп, сервистер жұмыс істеп тұрғаннан кейін жоба әлі аяқталған жоқ. Ең жағымсыз сюрприздер көбіне ауысым кезінде емес, бірнеше күн өткенде пайда болады: резервтік көшірулер, айлық есепті жабу, «ауыр» есептер.

Бастапқы 1–2 аптада тұрақтандыру режимінде болыңыз: кешігулер мен IOPS-ты күнделікті бастапқы желімен салыстырып, жол қателері мен кезектердің күйін тексеріңіз. Алерттер мен қарапайым есептер орнатыңыз, осылайша ауытқуларды пайдаланушылар анықтай бастағанға дейін ұстайсыз.

Стандартты минимум стабилизация кезеңінде:

• оқу/жазу кешігулері мен пулдардың толу деңгейі бойынша порогтық алерттер
• жолдар (MPIO) жағдайын, порттарды және коммутатор қателерін бақылау
• ең маңызды томдар бойынша күнделікті метрикаларға шолу
• резервтік және ауыр тапсырмалар кестелерін тексеру
• не өзгертілгені туралы қысқа журнал

Одан кейін оңтайландыруға кірісіңіз. Көбінесе миграциядан кейін «мурагер» баптаулар қалады: ескі кэш саясаттары, порттардың теңгерілмеуі, уақытша көшіру томдары. Пайдаланылмайтын LUN/томдарды алып тастаңыз, фронтенд порттары бойынша баланс пен томаралық өлшемдердің қосымшалар қажеттіліктеріне сәйкестігін тексеріңіз.

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

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

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