Гипервизорға арналған желі карталары мен HBA: Dell және HPE үшін тексеру тізімі

Гипервизорға арналған NIC және HBA-ны алдын ала неге тексеру керек

Виртуализацияны жоспарлап жатсаңыз және темірді тексермей қою — жаңа қозғалтқышты орнатып, беріліс қорапты ашпастан жүгіру сияқты. Желі адаптерлері (NIC) мен HBA сақтау үшін бірдей көрінуі мүмкін, бірақ VMware, Hyper-V және KVM-та әртүрлі мінез көрсете алады. Себеп көбіне порт жылдамдығында емес, драйверлерде, прошивкада және гипервизордың offload пен SR-IOV-пен қалай жұмыс істейтінінде болады.

Ең жағымсыз жайт — ақау ашық қате түрінде көрінбеуі мүмкін. Dell немесе HPE сервері жүктеліп, интерфейстер Up болып тұруы мүмкін, бірақ жүктеме түскенде: кейде пакет жоғалту, ВМ-дердегі «тұрып қалулар», IOPS төмендеуі, iSCSI үзілуі, миграциялардың кездейсоқ сәтсіздігі пайда болуы ықтимал. Соның салдарынан жылжымалы миграция, төзімділік, репликация және резервтік көшіру секілді базалық мүмкіндіктер зардап шегеді.

Әдетте жағдай былай болады: гипервизорды жаңартқаннан кейін басқару желісі қалыпты жұмыс істейді, ал басқа порт арқылы өтетін storage трафигі таймаут бере бастайды. Себеп — қолайсыз драйвер нұсқасы, offload логикасының өзгеруі немесе SR-IOV әдепкі бойынша қосылып, сіздің ВМ мен желі инфрақұрылымы шектеулерін есепке алмау болуы мүмкін.

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

• гипервизорды жаңарту немесе жаңа ағымға көшу (мысалы, LTS)
• NIC/HBA-ны басқа чипке немесе ревизияға ауыстыру
• өнімділік үшін ускорения қосу (offload, SR-IOV, RDMA)
• кластерді жаңа Dell/HPE хосттарына көшіру немесе сақтау схемасын өзгерту

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

Желі карталары мен HBA: олар не және не үшін жауап береді

Желі адаптері (Ethernet NIC) мен HBA көріністе ұқсас болуы мүмкін, бірақ міндеттері әр түрлі. NIC — қалыпты IP-трафикті тасымалдайды. HBA — сақтау жүйесіне арнайы протоколдар арқылы қолжетімділік береді. Таңдаудан бұрын өз желілеріңізді, трафик түрлерін және сақтау қалай қосылғанын нақтылап алыңыз.

Қандай адаптерлер болады

Көбінесе кездесетіні:

• Ethernet NIC: 1/10/25/40/100GbE — басқару желісі, ВМ трафигі және сервистік VLAN-дар үшін
• FC HBA: Fibre Channel арқылы SAN-ға қосылу (әдетте enterprise сыртқы СХД)
• SAS HBA: SAS-дискілерге немесе сыртқы JBOD-қа қосылу, кейде таспа кітапханаларына
• конвергентті адаптерлер (CNA): бір адаптер Ethernet пен FC over Ethernet ретінде істей алады (модель мен конфигурацияға тәуелді)

Бір NIC жиі бірнеше ағымды жабады: ВМ трафигі, миграциялар (vMotion/Live Migration), iSCSI/NFS/SMB арқылы сақтау, репликация және бэкаптар. Мұнда тек жылдамдық пен порт саны ғана емес, VLAN қолдауы, драйвер жұмысы және offload тұрақтылығы маңызды.

HBA сақтау жүйесі IP емес немесе SAN-ның ең тұрақты жұмысын қажет ететін жерлерге қажет. FC HBA серверді SAN фабрикасына және СХД-дегі LUN-дарға қосады. SAS HBA дискілік алқапқа немесе библиотекаға тікелей қол жеткізу береді және кейде бөлек IP сақтау құрғаннан оңайырақ болады.

Қандай шешім сізге керек екенін қалай түсінуге болады

Сақтаудың түріне және төзімділік талаптарына қарай бағыттаңыз. Егер сыртқы СХД FC арқылы қосылған болса, FC HBA қажет. Егер сақтау iSCSI арқылы болса, жақсы NIC пен бөлек storage желісі жиі жеткілікті.

Сатып алудан бұрын тексеріңіз:

• сақтау протоколы (FC, iSCSI, NFS/SMB, SAS)
• қанша тәуелсіз жол қажет (2 порт, 2 адаптер, 2 коммутатор)
• қай трафиктерді физикалық түрде бөлу керек (миграциялар, storage, VM)
• SR-IOV немесе passthrough деңгейіндегі оқшаулау керек пе

Жалпы ереже: алдымен желілер мен сақтау жолдарын жобалап, сосын Dell немесе HPE және таңдалған гипервизорға сай нақты модельдерді таңдаңыз.

VMware, Hyper-V және KVM үшін сәйкестікті қайдан іздеу керек

Сәйкестікті тексеру формалдық емес. Бір адаптердің атауы ұқсас болуы мүмкін, бірақ ревизия, прошивка немесе OEM-орындау әртүрлі болады — гипервизор оны басқа түрде көруі мүмкін. "Желі карталары мен HBA гипервизорға" тақырыбында басты бағдар — нақты гипервизор мен оның нұсқасының ресми сәйкестік тізімдері (HCL).

VMware-та әдетте HCL-ға модель және драйвер бойынша қарайды: нақты идентификаторлар, қолдау көрсетілетін ESXi нұсқалары және функциялар туралы ескертпелер (мысалы, SR-IOV немесе offload). Hyper-V үшін Windows Server нұсқасы мен драйвер моделінен бастау практичнее: драйвер сіздің ОС тармағына арналса, тұрақтылық мүмкіндігі жоғары. KVM-та сәйкестік көбінесе дистрибутивке (мысалы, RHEL немесе Ubuntu) және ядро нұсқасына байланады: бір чип жаңа ядода жақсы жұмыс істейді, ескісінде ақау көрсетуі мүмкін.

Dell пен HPE деректерін бөлек тексеріңіз. Оларда OEM-нұсқалары бір чипсетпен болғанымен әр түрлі Part Number, власная прошивка және драйвер пакеті болуы мүмкін. Сондай-ақ BIOS/UEFI және микрокодтың ұсынылған нұсқалары маңызды: кейде мәселе гипервизорда емес, "BIOS + NIC/HBA прошивка" құрамында болады.

Адаптердің сипаттамасын оқығанда тек "10/25/100G" дегенге ғана назар аудармай, чипсет моделін, ревизиясын, PCIe буынын және порт түрін (SFP28/QSFP28, Base-T) нақтылаңыз. Бұл драйверге, қуат тұтынуға және нақты слоттармен сәйкестігіне әсер етеді.

Сатып алудан бұрын бір орында жинаңыз:

• нақты Part Number пен маркетингтік атау (Dell/HPE спецификациясындағыдай)
• PCI ID (Vendor/Device) және ревизия (егер үлгі бар болса)
• прошивка нұсқасы және оны жаңарту утилитасы
• драйвер нұсқасы (қандай гипервизор/ОС үшін көрсетілген)
• сервер туралы мәлімет: модель, BIOS/UEFI және таңдалған гипервизор (билдпен)

Жоба мысалы: Dell жүйесінде бір чипсетте екі "ұқсас" 25G карта таңдасаңыз, біреуі OEM-бұлдыр болуы мүмкін және басқа драйвер пакетін талап етуі, ал екіншісінде SR-IOV тек белгілі бір прошивкада тұрақты жұмыс жасауы ықтимал. Мұндай жағдайды алдын ала байқасаңыз, пилот ешқандай тосынсыйсыз өтеді.

Енгізуге дейінгі тексеріс: қадамдық жоспар

NIC пен HBA кейіннен тосынсый болмасын десеңіз, тексеруді шағын жоба ретінде жүргізген жөн: темір мен слоттардан бастап пилот пен қабылдау критерийлеріне дейін. Dell пен HPE типтік платформаларында PCIe нұсқасы немесе алынған слот секілді ұсақ мәселе шынайы өткізу қабілетіне әсер етуі мүмкін.

1. Сервер бойынша бастапқы деректерді тіркеңіз: модель, CPU және чипсет ұрпағы, қолжетімді PCIe слоттары (нұсқасы және жолдар саны), қай слоттар бос емес (RAID, GPU, қосымша HBA), қуат беру және салқындату конфигурациясы. Практикада 2x25GbE жоспарлап, бос слоттың PCIe x8 болып шығуы мүмкін — адаптер жұмыс істейді, бірақ күтілген жылдамдықты бермейді.

2. Мәселеге сай адаптер таңдаңыз, тек қораптағы санға емес. Порт түрі (мысалы, мыс немесе оптика), резервтеу үшін порт саны, қажет жылдамдық және сақтау протоколдары маңызды.

3. Тексеруді қысқа бақылау тізіміне жинаңыз:

• сіздің VMware/Hyper-V/KVM нұсқаңызбен және қонақ ОС-пен сәйкестігі
• минималды прошивка нұсқалары (NIC/HBA, BIOS, iLO/iDRAC) және қолжетімді драйверлер
• басқару утилиталары керек пе және оларды қалай жаңартасыз
• offload және SR-IOV бойынша жоспар: не бірден қосасыз, не тест ретінде қалдырасыз
• пилот критерийлері: жүктеме, қабылданатын латенттілік, бір порт немесе контроллер ақауы, ВМ миграциясының мінезі

4. 1–2 хостта пилотпен аяқтаңыз. Нақты жүктемені өткізіңіз: бірнеше ВМ, миграциялар, резервтеу (LACP/teaming) және апат сценарийі.

Драйверлер мен прошивкалар: сәйкессіздікке қалай ұстамау керек

NIC пен HBA-да жиі істен шығу темірден емес, драйвер, адаптер прошивкасы және гипервизор нұсқасының ұштасуынан болады. "Драйвер орнатылған" деген сөз ештеңе кепілдемейді, егер прошивка сол нұсқаға сай болмаса. Осылайша жүктеме кезінде плавающие үзілістер, өнімділік деградациясы немесе ерекше таймауттар пайда болады.

VMware, Hyper-V және KVM үшін әдіс ұқсас: алдымен қолда бар комбинацияны таңдаңыз, оны тіркеңіз және тек бақылаулы терезеде жаңартыңыз. Бұл NIC пен HBA сақтау, кластерлік желі немесе vMotion/Live Migration-ды қамтамасыз еткен кезде әсіресе маңызды.

Туған драйверлер (nativ) немесе vendor-пакеттер

Гипервизордың туған драйверлері әдетте ұстауға оңай және жаңартулармен аз қақтығысады. Vendor-пакеттер (сервер немесе чипсет өндірушісінен) керек кезде пайдалы: жаңа ревизияларды, нақты түзетулерді немесе SR-IOV/ offload сияқты функцияларды қамтамасыз ету үшін. Туған драйверде бұл функциялар шектеулі болуы мүмкін.

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

Енгізуден бұрын тіркеңіз:

• гипервизор нұсқасы және патч деңгейі
• NIC/HBA драйвер нұсқасы
• адаптер прошивкасы және (бар болса) option ROM
• сервер BIOS/UEFI нұсқасы, PCIe және IOMMU-ға әсер ететін параметрлер
• жоспарланған жаңарту терезесінің күні және құрамдас бөліктері

Жаңартулардан кейінгі тосынсыйларды қалай болдырмау керек

Типтік сценарий: хосттарды жаңарттыңыз, ал бір тәуліктің ішінде iSCSI тоқтап немесе 10/25GbE портында ара-тұра линк жоғалуы басталды. Көп жағдайда гипервизор драйверді жаңартты, ал прошивка ескі күйінде қалды (немесе керісінше).

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

• адаптерді шексіз қайта инициализациялау
• link flap (линк көтеріліп-түсіп отыру)
• өткізу кезектерінде немесе storage-командаларда timeout
• firmware mismatch немесе unsupported firmware деген хабарлар
• пакет қателері мен throughput-тың жүктеме кезінде күрт төмендеуі

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

Offload және ускорения: не қосып, не сақтықпен тестілеу керек

NIC-тегі offload функциялары CPU-ны айтарлықтай босатуы мүмкін, бірақ виртуализацияда кейде олар сирек және жағымсыз ақаулар көзіне айналады. VMware, Hyper-V немесе KVM үшін Dell және HPE серверлерінде NIC пен HBA таңдап жатқанда, қауіпсіз базалық профильді және тест жоспарын алдын ала анықтаңыз.

Көбіне тұрақтылыққа әсер ететін үлкен разгрузкалар: TSO (үлкен пакеттерді сегментациялау), LRO/GRO (агрегация) және checksum offload. Linux-та олар әдетте жақсы мінез көрсетеді, бірақ VM-желіде пакет жоғалту, өзгермелі джиттер немесе тек кейбір ВМ-дерде проблема тудыруы мүмкін. Симптом байқасаңыз, vSwitch, драйвер және хост ОЖ деңгейінде осы опцияларды тексеруден бастаңыз.

Қайсы виртуализациялық ускоренияны әдетте қосады

Көптеген типтік жүктемелер үшін пайдалысы — RSS (трафикті бірнеше ядроға тарату), кезектер және дұрыс interrupt moderation. Hyper-V-та бұл жиі VMQ мен vRSS-пен бірге келеді, VMware-та дұрыс кезектер мен драйвердың жүктеме астындағы жұмысы маңызды. Негізгі бағыт: егер трафик бір ядроға жабысып қалса, ядролар мен кезектерге бөлу параметрлерін қараңыз, тек "порт жылдамдығын" ғана емес.

Overlay-желілер (VXLAN/Geneve) және мұнда неге сақ болу керек

VXLAN/Geneve үшін offload комбинациясы гипервизор нұсқасы, драйвер және прошивка сәйкестігіне тәуелді. Кейде overlay offload қосу үлкен артықшылық береді, ал кейде MTU-ға немесе көптеген ВМ-ге байланысты жағдайды нашарлатуы мүмкін. NSX, OVN/OVS, OpenStack немесе Hyper-V ішіндегі SDN қолдансаңыз, overlay үшін бөлек тест бекітіңіз.

Параметрлерге қатысты тәртіпті ұстанған жөн:

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

Практика мысалы: ВМ ішіндегі VoIP-қа қатысты секірістер пайда болса, хостта LRO/GRO-ны өшіру жиі көмектеседі. Сол кезде RSS пен дұрыс кезектерді қосып қалдыру арқылы өнімді сақтап, кіші пакеттердегі ақауды алып тастауға болады.

SR-IOV және passthrough: талаптар мен шектеулер

SR-IOV vSwitch жеткіліксіз болғанда керек. Ол бір физикалық адаптерді виртуалдық функцияларға (VF) бөледі және әр ВМ адаптерге дербес, тікелей жақын қолжетімділік алады. Бұл әдетте латентті төмендетіп, CPU жүктемесін азайтады. Passthrough (DirectPath I/O, DDA және баламалары) бір қадам әрі қарай: сіз бүкіл адаптерді немесе портты бір ВМ-ге бересіз.

Егер жобаңызда латенттілікке жоғары талап болса (VDI, телеком, жоғары жүктемелі шлюздер, storage-трафик), SR-IOV жиі пайда береді. Бірақ оның төленетін бағасы — икемділік пен эксплуатацияның қарапайымдылығының төмендеуі.

Қосу алдында не тексеру керек

Dell пен HPE серверлерінде (және жалпы) бастапқы шарттар:

• IOMMU: Intel VT-d немесе AMD-Vi CPU мен чипсетті қолдауы тиіс
• BIOS/UEFI параметрлері: VT-d/AMD-Vi және SR-IOV-пен байланысты опциялар қосулы болуы тиіс
• драйверлер мен прошивканың сәйкестігі: гипервизор сіздің NIC моделінде SR-IOV-пен жұмысқа қабілетті болуы, ал хост драйвері VF-тарды дұрыс құруы қажет
• желі қауіпсіздігі жоспары: трафиктің бір бөлігі vSwitch-ті айналып өткенде қалай сүзілетіні мен сегментация қалай орындалатынын ойластыру

Жиі ұмытылатын шектеулер

SR-IOV және passthrough кейбір әдеттегі операцияларды шектейді:

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

SR-IOV керек пе деп шешу: егер желіні өңдеуде CPU шектеуге соғылып отырсаңыз, бір ВМ-қа ең жоғары өткізу қабілеті немесе минималды латенттілік керек болса, пилотқа SR-IOV енгізіңіз. Егер миграциялар, унификация және қарапайым эксплуатация маңыздырақ болса, әуелі стандартты vSwitch-пен бастаңыз және ускоренияны тек өлшенгеннен кейін қосыңыз.

Мысалы: банктағы VDI кластерінде көп ВМ стандартты vSwitch-та қалады, ал графикамен жұмыс істейтін пулдар немесе шлюзтер үшін ғана SR-IOV қосуға болады.

Сақтау үшін HBA тексерісі: FC, SAS және iSCSI

HBA сақтау жүйесінде жиі тар жерде болмайды — мәселе көбіне сәйкестік пен конфигурацияда, олар гипервизор орнатылғаннан кейін көрініп шығады. Бұл Dell және HPE-дегі үлкен масштабты енгізулерге дейін тексеруге лайық.

FC HBA (SAN)

Бастапқыда гипервизор сіздің FC HBA моделі мен прошивка нұсқасын қолдай ма тексеріңіз. Қайталанатын проблема — адаптер көрінеді, бірақ драйверге немесе ескі firmware-ге байланысты тұрақсыз жұмыс істейді.

Сонымен қатар физика мен режимдерді тексеріңіз. Оптика және кабель түрінің SAN талаптарына сай екеніне көз жеткізіңіз, және жылдамдық (16G/32G) HBA, коммутатор және массив жағында үйлесімді болсын. FC-да duplex әдетте қолмен бапталмайды, бірақ жылдамдық пен сызық қателерін журналдан бақылау қажет.

Егер LUN-ға виртуалды машиналар арқылы қатынауды жоспарласаңыз, NPIV қолдауы мен виртуалды WWPN санының шектеулерін алдын ала тексеріңіз. Бұл VMware үшін жиі маңызды және зонирлеу, қауіпсіздік талаптары үшін шешуші.

SAS HBA және iSCSI арқылы NIC

SAS-та алдын ала нақтылаңыз: сізге таза HBA (JBOD, passthrough) керек пе немесе RAID режимі қажет пе. Кластерлі виртуализация мен сыртқы СХД үшін көбіне HBA режимі қолайлы. Әйтпесе кэштеу саясаттары қақтығысуы және күтпеген латенттілік пайда болуы мүмкін. Сондай-ақ backplane-пен сәйкестік, queue depth және таймауттарды тексеріңіз: жүктеме кезінде дәл осы параметрлер сақтау жүйесінің тұрып қалуына әкелуі мүмкін.

iSCSI NIC арқылы болса, басты мәселелер — біртұтас MTU (jumbo frames тек барлық жерде қосулы болғанда), MPIO/multipath және пакет жоғалтуларға тұрақтылық. DCB тек желі шын мәнінде сол үшін дайын болғанда ғана ақылға сәйкес, әйтпесе диагностика күрделене түседі.

Пилотқа дейін төзімділік схемасын бекітіңіз:

• минимум 2 адаптер немесе 2 порты
• 2 тәуелсіз жол (екі FC фабрикасы немесе екі iSCSI коммутатор)
• PCIe слоттары бойынша мүмкіндігінше бөліну және әр түрлі контроллерлерге қосу
• әр түрлі кабельдер және коммутатордағы әр түрлі порттар
• бір жолды ажыратқанда ВМ тоқтамайтынын тексеру

Мысалы: екі процессорлы Dell немесе HPE серверінде екі FC HBA әр түрлі слоттарға қойып, екі SAN коммутаторына қосып, драйверлер, таймауттар мен multipath мінезін тестілеңіз. Бұл драйвер, таймаут және multipath мәселелерін ең жылдам көрсетеді.

Пилотта қалай тестілеу: тұрақтылық пен өнімділік

Пилотты бір–екі типтік хостта және өндірісте қолданылатын BIOS, прошивка және драйвер нұсқаларымен жасаңыз. Мақсат — драйвер, offload және SR-IOV мәселелерін сатып алу немесе масштабты енгізу алдында табу.

Желіге жылдам тесттер

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

• өткізу қабілеті: бір және бірнеше ағындар, екі бағытта
• латенттілік және джиттер: қысқа пакеттер және аралас жүктеме
• жоғалту және дроптар: жүктемені жоғарыдан қанықтыруға дейін көтеріп, шекті табу
• жүктеме астындағы мінез: миграция ВМ немесе бэкапты параллель іске қосу
• желідегі CPU: бірдей тестте offload қосулы және өшірулі жағдайды салыстыру (мысалы, LRO/TSO)

Гипервизор мен хост интерфейстерінде тек жылдамдықты ғана емес, сонымен қатар кезектердің өсуі, vSwitch немесе порт топтарында дроптар, retransmits, порттағы қателер, пакет өңдеуге CPU-ның күтпеген өсуі сияқты симптомдарды бақылаңыз. SR-IOV қосқанда, стандартты vNIC пен VF арасындағы латенттілік пен CPU жүктемесін бөлек салыстырыңыз.

Сақтау тесттері (HBA)

FC/SAS/iSCSI үшін тұрақтылық жылдамдықтан маңыздырақ. Бірнеше сағат бойы жүктеме беріңіз: оқу, жазу, аралас профильдер, әр түрлі блок өлшемдері. Латенттіктің өсуін, таймауттарды, жол қателерін және қайта әрекеттерді қадағалаңыз, сондай-ақ жүйенің ақау өткендегі мінезін тексеріңіз.

Контролденген жағдайларда failover тесттерін өткізіңіз:

• бір HBA немесе NIC портын ажырату
• кабельді шығарып көру
• коммутаторды қайта жүктеу немесе бір uplink-ті өшіру
• активті I/O кезінде хостты қайта жүктеу
• LACP/teaming-ті жүктеме астында ауыстыру

Жетістік критерийлерін алдын ала келісіп алыңыз: қабылданатын латенттілік, жол қателерінің болмауы, тұрақты throughput және ақаудан кейінгі болжамды қалпына келу.

Таңдау және баптау кезіндегі типтік қателіктер

Виртуализациядағы ең қымбат мәселелердің бастауы әдетте NIC пен HBA айналасындағы ұсақ-түйек. Dell пен HPE-де бір атаумен түрлі ревизиялар, прошивкалар және OEM-орындаулар жасырын болуы мүмкін. Бұл — драйверлер мен гипервизорларда әртүрлі мінезге әкеледі.

Жиі болатын бір қате — референс картасына "ұқсас" картаны сатып алу, бірақ басқа ревизиямен. Қағазда бәрі сәйкес: жылдамдық, порттар, чип. Бірақ тәжірибеде SR-IOV көтерілмейді немесе offload тұрақсыз жұмыс істейді, себебі vendor-пакет нақты құрылғы идентификаторына арналған.

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

Физикалық деңгей де маңызды. Түрлі оптика, DAC-кабельдер және әртүрлі порт жылдамдықтарын араластырсаңыз, жүктеме кезінде link down немесе ұсақ қателерге тап болуыңыз мүмкін. Мысалы, миграция кезінде бәрі қалыпты көрінсе, түні бойы бэкап жүріп жатқанда бір порт секундтап үзіліп қалуы мүмкін.

Енгізуге дейін жиі ұмытылатындардың тізімі:

• нақты ревизия мен OEM-нұсқаны тексеруді ұмытпаңыз (Dell және HPE үшін маңызды) — драйверлер темірге сай болуы керек
• нұсқалардың сәйкестігін тексеріңіз: гипервизор, драйвер және прошивка бір жиын ретінде болуы тиіс
• кабельдер мен трансиверлер: бір жылдамдық, бір стандарт және сәйкестік расталған болу керек
• offload функцияларын бір-бірлеп қосып тестілеңіз, бәрін бірден қоспаңыз
• PCIe және NUMA бойынша орналастыру: дұрыс емес слот жоғары жүктеме кезінде өнімділікті төмендетуі мүмкін

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

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

Гипервизорға арналған желі карталары мен HBA туралы айтар болсақ, қазір бір сағат тексеруге кетіргеніңіз, кейінге қарағанда әлдеқайда үнемді. Тексеру сатып алу мен енгізуден бұрын сәйкес комбинацияларды тез ұстауға және Dell немесе HPE-дегі нақты не сұрау керектігін анықтауға көмектеседі.

• адаптердің нақты моделін сәйкестендіріңіз: тек атауы емес, ревизиясы, PCIe ұрпағы және порт түрі (1/10/25/40/100G, FC және т.б.)
• гипервизордың нақты нұсқасын және оның қолдауын тексеріңіз, жай ғана "VMware совместимо" деп сеніп қалмаңыз — кейде мәселе минорлық релизде болады
• нұсқаларды бекітіңіз: драйвер, NIC/HBA прошивкасы, сервер BIOS/UEFI және өндіруші басқару пакеттері
• баптауларды қараңыз: MTU, teaming/bonding, vSwitch параметрлері, RSS/VMQ, содан кейін ғана offload пен SR-IOV қажет болса қосыңыз
• төзімділікті бағалаңыз: екі тәуелсіз жол, слоттар/контроллерлер бойынша бөлу және жүктеме кезінде failover-ды нақты тексеру

Егер offload немесе SR-IOV қоссаңыз, бұл реттелетін эксперимент ретінде жүргізілуі тиіс. Барлығын бірден қосып жіберсеңіз, кейін не жағдайды нашарлатқанын анықтау қиын болады: ол драйвер тұрақсыздығы ма, әлде мониторинг пен қауіпсіздік саясатының бұзылуы ма.

Тексерістен кейінгі келесі қадамдар

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

• эталонды сақтаңыз: модельдер, сериялық нөмірлер, прошивка және драйвер нұсқалары, негізгі vSwitch/teaming параметрлері және VLAN саясаты
• жаңарту жоспарын жасаңыз: кім, қашан және қандай ережелер бойынша BIOS, прошивка және драйверлер жаңартылатынын және қалай откат жасалатынын анықтаңыз
• қысқа пилот өткізіңіз: ВМ миграциясы, хостты қайта жүктеу, бір линк өшіру, желі мен сақтау жүктемесі тесттері

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