Виртуалды машиналарды көшіру кезіндегі лицензиялар: vMotion және құжаттама

Неліктен ВМ-ды көшіру лицензиялық тәуекелдер тудыруы мүмкін

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

Ажыратуға әдетте терминологиядан басталады. ВМ-ды көшіру (vMotion/Live Migration) — орындау орнын өзгерту. Деректерді көшіру — файлдар, базалар немесе дискілерді жаңа орынға көшіріп қою, бірақ оларды жаңа темірде іске қоспау. Резервтен қалпына келтіру — бөлек сценарий, онда ПО негізгі жүйенің орнына іске қосылуы мүмкін және арнайы ережелерге бағынады. Адамдар осы жағдайларды шатастырады, ал тексерушілер қатаң қарайды: ПО нақты қай жерде жұмыс істеді және қандай ресурстар қолданылды.

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

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

Қатер гипервизормен ғана шектелмейді. Әдетте бірнеше қабат әсерленеді: гипервизор мен кластер функциялары, қонақтық ОС (арнайы серверлік редакциялар мен виртуалды даналарға құқықтар), СУБД және платформалар (көбіне CPU/хостқа байланған), сондай-ақ қолданбалы өнімдер (почта, ERP, VDI, қорғау құралдары), мұнда орнату орны мен қолдану орны маңызды.

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

Виртуализациядағы лицензиялау модельдері туралы қысқаша

Проблемалар vMotion немесе Live Migration технологиясынан емес, ПО-ға құқық қалай сатып алынғанынан туындайды. Бірдей ВМ-ды көшіру бір модельде толық жарамды, ал басқа модельде дау туғызуы мүмкін. Сондықтан алдын ала "пайдалану орны" қай жерде саналады және вендор "көшірме" деп нені атайтынын түсіну маңызды.

Лицензия темірге байланған (хост, сокеттер, ядролар)

Бұл модельде құқықтар физикалық серверге есептеледі, ал ВМ сол лицензияланған хостта жұмыс істейді. "Серверді жабу" дегеніміз — оның параметрлеріне жеткілікті лицензия болуы (көбінесе сокеттер немесе ядролар) және ережелер сол хостта қажетті ВМ санын іске қосуға рұқсат беруі.

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

Лицензия ВМ-ға немесе қолданушы/құрылғыға арналған

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

Мысал: сервиске 200 қызметкер қатынаса, ал лицензиялар "100 пайдаланушыға" деп алынған және нақты кімнің қолы бар екені тіркелмеген. ВМ басқа түйінге көшіп, техникалық өзгеріс болмағанымен, аудитте бұл модель серверге емес, қолжетімділікке арналғаны анықталуы мүмкін.

Жазылым (подписка) және мерзімсіз лицензия

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

Мобильдік құқықтар мен шектеулер

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

Dev/test және өндіріс — әртүрлі ережелер

Даму және тест үшін лицензиялар әдетте арзанырақ болады, бірақ олар тірі пайдаланушыларға қызмет көрсетуге құқық бермейді. Қауіпті жағдай: тест ВМ қате түрде прод-кластерге түсіп, жұмыс жүктемесін орындаса. Техникалық тұрғыдан жұмыс істесе де, лицензиялық жағынан бұл басқа қолдану саналады.

Әр өнім үшін қысқа "паспорт" ұстау ыңғайлы: лицензия бірлігі не (хост, ядро, ВМ, пайдаланушы, құрылғы), қай жерде қолдануға рұқсат (кластер, алаң, ел, нақты хосттар), мобильдік құқық бар ма және қандай шарттармен (көшіру жиілігі, DR), жазылым мен қолдаудың аяқталуы не өзгерте алады, dev/test қолдануға рұқсат бар ма және қандай шектеулер.

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

vMotion/Live Migration сценарийлері және жиі кездесетін қателіктер

vMotion/Live Migration көбіне таза техникалық функция ретінде қабылданады: ВМ көшірілді, сервис сезбейді. Бірақ лицензия үшін маңыздысы — жүктеме нақты қай жерде орналасқаны және вендор оны қалай санайтыны. Сондықтан виртуализация жақсы бапталған болса да, виртуалды машиналарды көшіру кезінде лицензиялық мәселелер туындауы мүмкін.

Кластер ішінде: әдетте тыныш, бірақ емес

Егер ВМ бір кластер ішіндегі хосттар арасында көшсе және барлық хосттар лицензиямен жабылған болса (процессорлар/ядролар бойынша немесе хост жазылымы бойынша), тәуекелдер әдетте төменірек. Аудиторға бұл логикалық көрінеді: лицензия хосттар тобымен бекітілген, ал ВМ сол топ ішінде ауысады.

Қателіктер детальдардан басталады: кластерге жаңа хост қосылды; түйіндердің бір бөлігі басқа редакцияда; немесе лицензия барлық узелдерге бірдей құқықты талап етеді.

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

Тіпті бір ЦОД ішінде басқа кластерге өту да жауапты өзгертеді: "қандай хосттар іске қосуға қолжетімді" деген сұрақ мүмкін өзгереді. Кейбір лицензия ережелері ВМ-ның нақты іске қосылған жеріне емес, кластердегі потенциалды іске қосу мүмкіндігіне қарайды.

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

Басқа алаң немесе DR: техника емес, құқық өзгереді

Басқа ЦОД немесе DR-ға көшу кезінде шарттар өзгереді: басқа заңды тұлға, басқа келісім, басқа есеп әдісі (мысалы, резервтік қуатқа бөлек лицензия қажет). Тіпті инфрақұрылым ұқсас болса да, ПО-ға құқықтар екінші сайтқа бөлек жабуды талап етуі немесе тек авариялық режимде іске қосуға рұқсат етуі мүмкін.

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

Салқын миграция және живая: есептеудегі айырмашылық

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

Уақытша хосттар жұмыстар кезеңінде

Жаңарту кезінде жиі уақытша түйіндер қосылады немесе қызмет көрсету режимі қосылады. Егер уақытша хост лицензиямен жабылмаса, бірақ оған ВМ түсуі мүмкін болса, бұл қызыл тумақ.

Алдын ала анықтап қою пайдалы: нақты қай хосттарқа ВМ түсуі мүмкін, қандай хосттар лицензиямен жабылған, автоматты орналастыруды уақытша шектеу (affinity/anti-affinity ережелері), тесттік іске қосулар мен DR валидациясы регламенті және кластердегі өзгерістер журналы (хосттарды қосу, ядро санын арттыру, редакцияларды өзгерту).

Лицензия "қайда тұрады": хост, кластер немесе алаң

vMotion/Live Migration қосылғанда, сұрақ көбіне ВМ қазір қайда тұрғанында емес, минуттан кейін қайда түсуі мүмкін екенінде. Аудит үшін бұл шешуші: жиі лицензияланады факт іске қосылу емес, іске қосуға құқық белгілі бір темір жиынтығында. Сондықтан шекараларды "кластер" деп емес, нақты хосттар тізімі мен планировщик ВМ-ды қай ережелер бойынша қоныстандыратынын сипаттаған жөн.

Практикада бірнеше нұсқа кездеседі.

Ең түсінікті — хостқа (немесе оның процессор/ядроларына) байлану: онда потенциалды ВМ қабылдай алатын әр сервер лицензиямен жабылуы керек. Тағы бір нұсқа — кластер немесе хосттар пулына лицензиялау: аудитормен қай түйінде ВМ іске қосылғаны маңызды емес, егер түйіндер алдын ала анықталған топқа кірсе. Сирегірек алаңға (site) немесе арнайы зонаға байлау кездеседі, мысалы DR-алаңға жеке шарттармен.

Кілтті жәйт: потенциалды іске қосу орны көбіне көрінгеннен кеңірек.

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

Қарапайым сценарийді елестетіңіз: сервис 6 хосттан тұратын кластерде жұмыс істейді, бірақ "сақтық үшін" тағы 2 жаңа сервер қосылды және сол кластерге енгізілді. ВМ бірде-бір рет соларға көшпесе де, көптеген лицензиялау модельдерінде осы 2 хост потенциалды мақсат болып есептеледі және оларды жабу қажет болуы мүмкін.

Кейін дау шықпасын десеңіз, шекараларды және ерекшеліктерді құжатта алдын ала тіркеңіз:

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

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

Қадам-қадам: жоспарлы миграциядан бұрын лицензияларды тексеру

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

1) ВМ және ПО-ның нақты тізімін жинаңыз

Инвентаризациядан бастаңыз: ВМ тізімі, олардың мақсаты және орнатылған ПО. Нұсқалар, редакциялар және жиі бөлек лицензияланатын компоненттерді (сервер рөлдері, модульдер, резервтеу агенттері) тіркеңіз.

2) ВМ қай жерлерге шын мәнінде көшуі мүмкін екенін анықтаңыз

Әр ВМ-ны DRS саясаты, affinity/anti-affinity, желі мен сақтау шектеулеріне байланысты қай кластерлерге, пулдарға және хосттар топтарына түсуі мүмкін екенін сопоставьте. Жиі қате — тек жұмыстар жоспары көрсеткен мақсатты хостты тексеріп, автоматты көшіруге қолжетімді альтернативті түйіндерді ұмыту.

3) Барлық мүмкін мақсатты хосттардың лицензиямен жабылуын тексеріңіз

Әр өнімнің лицензиялау моделін инфрақұрылыммен салыстырыңыз.

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

4) Мобильдік құқықтар мен уақыттық шарттарды ескеріңіз

Кейбір вендорлар көшірмеге тек белгілі шарттармен рұқсат береді: белсенді қолдау, "мобильдік құқықтар", қайта тағайындау жиілігіне шек қою. Тәуелсіз түрде DR-ға авариялық көшу қалай есептелетінін қарайтын жеке тексеріңіз.

5) Жұмысқа кіріспес бұрын шешімді тіркеңіз

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

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

Дауды болдырмау үшін құжатта не тіркеу керек

vMotion немесе Live Migration қосылғанда ВМ минуттар ішінде көшіп кетуі мүмкін, ал лицензиялық сұрақтар көбіне айлардан кейін, аудит немесе мердігер ауысқанда шығады. Дауды "қай хостта болған" сияқты еске алып шешпеу үшін, қандай фактілерді құжат арқылы дәлелдеуге болатынын алдын ала келісіңіз.

1) "Сәйкестендіру картасы" және растайтын пакет

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

Практикалық минимум:

• "ПО → ВМ → сервис/иегері → кластер немесе хосттар тобы → алаң (ЦОД/DR)" байланысы;
• құқықтарды растайтын құжаттар: келісім-шарттар, кілттер/сертификаттар, жазылымдар, шоттар, қосымша келісімдер, сондай-ақ дау туатын түсініктемелер бойынша вендордың ресми хаттары;
• лицензия шарттарын түсінікті түрде: метрика (ядролар, сокеттер, пайдаланушылар, ВМ, инстанстар), көшіру құқығы, география немесе заңды тұлға бойынша шектеулер.

2) Техникалық фактілер, өзгерістер журналы және жауапкершілік

Даулар көбіне техникалық фактілер құжатта болмауынан басталады. Лицензия хосттардың конфигурациясына, планировщик ережелеріне және миграция шектеулеріне байланысты болуы мүмкін.

Не тіркеу керек және үнемі жаңартып отыру қажет:

• хосттардың инвентаризациясы: модель, сокеттер/ядролар, қосылған функциялар, кластер құрамы, әр өнім үшін "лицензияланатын аймаққа" кіретін хосттар;
• миграция ережелері: ВМ қайда көшуі мүмкін, қандай хосттар шетте қалды, қандай саясаттар қолданылады (affinity/anti-affinity, кластердан шығуға тыйым, "DR тек оқиға кезінде");
• өзгерістер журналы: көшіру күні, себебі (жоспарлы жұмыс, апат, теңестіру), кім бекітті, қандай тикет немесе бұйрық;
• рөлдер: лицензиялар үшін кім жауапты (сатып алу), ВМ орналастыру үшін кім (ИТ), тәуекелдер мен допустар үшін кім (қауіпсіздік), сервис иесі — көшіру туралы шешімді кім қабылдайды.

Қарапайым мысал: коммерциялық СУБД-сы бар ВМ прод-кластерден көрші кластерге түнде көшірілді. Жарты жыл ішінде аудитте көрінді: көрші кластер әлдеқайда қуатты CPU-ларға ие, ал құқықтар тек "прод-зонаға" сатып алынған. Егер құжатта көшіру шектеуі және бұл тасымалдау ерекше жағдай ретінде өтінішпен, бекітумен және қайтарумен тіркелсе, дау деректерге негізделіп шешіледі, есте сақтауға емес.

Қайталанатын қателіктер және даулы тұстар

Тексеру кезінде ең жиі қате — виртуалды машиналарды көшіру кезіндегі лицензияларды статикалық сурет ретінде қарастыру: "ВМ осы хостта тұр, демек бәрі дұрыс". vMotion және Live Migration орналастыруды динамикалық қылады, ал ПО-ға құқық көбіне ВМ-ға емес, оны орналастыруға қабілетті физикалық ресурстарға байланады.

Көбінесе кездесетін қателіктер

Қауіп — инфрақұрылым лицензияланғаннан кең етіп бапталған. Көптеген жағдайларда тек ағымдағы хост есепке алынады, бірақ ВМ автоматты түрде қайда кетуі мүмкін пул толығымен есепке алынбайды. Автоматты көшіруді ажыраусыз қосып қою, хост топтары бойынша шектеулерсіз. Уақытша серверлерді есепке алмау: "жөндеуде", "кеңейтуге", "пилотқа" арналған хосттар да есепке кіруі мүмкін, егер соларға ВМ түсуі ықтимал болса. ВМ-ды тест ортасына көшіру және онда өндірістік жүктемені бірнеше күнге іске қосу — қауіп. Көшірме (backup) ұстау құқығымен екінші көшірмені параллель іске қосу құқығын шатастыру — қауіп. Резервтік көшірме мен жылы/ыстық резерв — әртүрлі сценарийлер.

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

Қай нәрселер бойынша жиі дау болады

Даулар көбіне лицензия шарттары мен виртуализация баптаулары терминдерінің әртүрлі түсініктерінен туындайды.

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

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

Практикалық мысал: сервисті DR-алаңға көшіру

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

Оқиға: прод алаңында микрокод жаңартулары жоспарланған, сондықтан кейбір хосттарды кезекпен алып шығу қажет. IT командасы екі аптаға Live Migration-ды DR бағытында уақытша қосуды қалайды, бірнеше ВМ-ды DR-ге тоқтаусыз көшіру жоспарланады.

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

Шешім әдетте үш бөліктен тұрады.

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

Екіншіден, режимдерді бөледі: кей жерде Live Migration тек DR ішінде қалдырылып, алаңдар арасында көшу тек шектелген терезеде қосылады.

Үшіншіден, растайтын құжаттарды дайындайды: кім уақытша өзгерісті бекітті, қандай мерзімге, қандай ВМ-лар қамтылды және қандай лицензиялар бұл жағдайды жабады.

Жобаның папкасына әдетте қойылатын құжаттар, олар көп дауды шешеді:

• сәйкестік матрицасы: ВМ/сервис → ПО және редакция → лицензия моделі → рұқсат етілген хосттар тізімі;
• жұмыстар регламенты немесе бұйрық: мерзімдер, жауапты тұлғалар, рұқсат етілген миграция бағыттары;
• кластер баптауларының алдын ала және кейінгі снимкасы (миграция саясаты, affinity/anti-affinity, хост пулдары);
• көшіру журналы: күн, ВМ, қайдан-қаға, себеп, рұқсат берген;
• лицензия бойынша қысқа қорытынды: қандай хосттар жабылған және неге бұл жеткілікті таңдаған шектеулерде.

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

Миграцияларды қосар алдында жылдам чек-лист

Автоматты миграция ыңғайлы, бірақ аудит үшін тосынсыйды да тез жасайды. vMotion/Live Migration-ды өндірісте қосар алдында бір рет келесі тексерістерді өткізіп, нәтижесін тіркеу пайдалы. Бұл әсіресе кластер өз бетінше ВМ-ды қайда қоюды шешетін жағдайда маңызды.

Алдымен шекараларды анықтаңыз: ВМ шын мәнінде қай жерде түсуі мүмкін. Әкімшілер көбіне 3–4 түйінді ойлайды, ал DRS саясаты немесе ұқсас механизмдер одан көбірек, соның ішінде кеңеюден кейінгі жаңа хосттарды да қосуы мүмкін.

Бес тексеріс, олар көбінесе негізгі тәуекелдерді жабады:

• планировщик ережелері бойынша ВМ кластердегі кез келген хостқа миграциялана ала ма екенін тексеріңіз; егер ерекшеліктер бар болса (affinity/anti-affinity, host groups, белгілі түйіндерге тыйым), оларды тіркеңіз;
• ПО құқықтарының барлық потенциалды іске қосу хосттарын қамтитынын растаңыз, соның ішінде резервтік және жөндеу кезінде жүктемені қабылдайтын уақытша түйіндер;
• лицензия шарттарындағы шектеулерді салыстырыңыз: хостқа бекіту минималды мерзімі, қайта тағайындау жиілігі, бөлінген процессор/ядро талаптары; алдын ала осы ережелерді қалай дәлелдейетініңізді ойластырыңыз;
• авариялық режимді жеке талдаңыз: DR-фейловер кезінде және қайтару кезінде не болады; бұл рұқсат етілгенін көрсететін дәлелдер керек (келісім шарты тармағы, вендор хаты, саясаттағы сценарий);
• тесттік миграциядан кейін инвентаризация мен өзгерістер журналын жаңартыңыз: қазір ВМ қайда жұмыс істейді, қандай өнімдер орнатылған, сервис иесі кім, не өзгерді.

Кішкене мысал: команда автоматты миграцияны 6 хосттық кластерде қосты. Айдан кейін 2 жаңа түйін қосылды және ВМ-лар соларға барып тұра бастады. Техникалық бәрі дұрыс еді, бірақ құжатта жаңа хосттар жабылмағандықтан ішкі тексерісте бұл лицензиясыз пайдалану ретінде көрінді.

Егер инфрақұрылым кезең-кезеңімен жаңартылып жатса (серверлер, СХД, алаңдар), жаңа хосттарды қосқанда лицензиялық шарттарды кім тексеретіні алдын ала белгіленсін.

Келесі қадамдар: ұтымды процесс құру

Миграциялардың жазғызыққа айналмауы үшін қарапайым процесс қажет, ол ИТ, сатып алу және қауіпсіздік үшін түсінікті. Мақсат — vMotion немесе Live Migration-ды тыйым салу емес, әр миграция лицензия ережелеріне сай өтіп, құжатталып қалуы.

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

Содан кейін сегментация көмектеседі. Әртүрлі лицензия модельдері бір ортада жақсы үйлеспейді. Хосттарды топтарға бөліңіз: қатты темірге байланған ПО үшін бөлек кластер, мобильдік құқықтары бар ПО үшін бөлек кластер, тест ортасы үшін бөлек кластер. Осылайша миграция саясаттарын жеңілдетіп, ВМ-ды қателесіп "сол жерге" көшіру тәуекелін азайтасыз.

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

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

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