Puncte:0

Probleme de utilizare ridicată a procesorului și stabilitate în timpul migrației live

drapel br

Am căutat o problemă și mă străduiesc să obțin un răspuns sau o soluție definitivă la o problemă.

În timpul migrărilor live ale VM-urilor între două gazde, gazda care primește VM-ul va vedea un singur nucleu al procesorului crește la 100%, iar performanța și stabilitatea sunt afectate. De exemplu, managerul de activități va răspunde lent, va îngheța/bâlbâi și va pierde date pentru a le afișa pe grafice... pe toată durata migrărilor live. Vitezele de migrare live sunt maxime la 6-7 Gpbs. Serverul de trimitere vede o creștere a utilizării nucleului procesorului, dar aceasta este răspândită pe 2-3 nuclee și nu mai mult de 50% fiecare.

Am activat vrss și vmmq, setați corect numărul de cozi disponibile urmând diverse ghiduri disponibile pe internet. Pot partaja acele setări dacă doresc. Înțeleg că atunci când utilizați LBFO nu puteți activa vmmq (VMMQEnabledRequested = True, dar VMMQEnabled = False), așa că am setat o gazdă să folosească un comutator SET, fără nicio modificare sau îmbunătățire.

Folosim Windows Server 2016 Core edition doar cu rolurile Hyper-V care rulează, nu avem alți agenți sau aplicații instalate â aceasta este o configurare vanilla. Acest lucru se întâmplă și pe toate clusterele noastre (care sunt identice).

Setările VMQ sunt setate pentru a evita nucleul 0 și, în mod normal, vedem numai nucleul 4, 6 sau 8, atingând 100% â adică NICIODATĂ core 0 și niciodată pe nuclee de până la 16 (procedura unică) sau 32 (procedura dublă) .

Folosim 2 x 10Gbe pe o placă Intel duală (placă PCI unică) și suntem într-o echipă SIT LBFO setată la Hyper-V mai degrabă decât la Dynamic (deși setările nu fac nicio diferență).

Rețeaua este definită folosind SCVMM, iar gazdele folosesc SCVMM Virtual Switch pentru rețeaua dedicată Live Migration.

În prezent, folosim SMB pentru migrații live, deoarece putem limita debitul SMB pentru a se menține sub limita CPU de 100%, dar această problemă apare indiferent de utilizarea TCP/IP, Comprimare sau SMB (deși compresia utilizează procesorul pentru o perioadă mult mai scurtă) . NOTĂ: accelerarea SMB este dezactivată pentru testarea mea.

Problema cheie pe care dorim să o rezolvăm este că serviciul VMMS uneori se blochează/se blochează în timpul evenimentelor de scurgere a gazdei. De exemplu. dacă efectuăm CAU și fiecare gazdă este drenată la rândul său, uneori obținem un eșec deoarece o gazdă nu reușește să dreneze toate VM-urile. În acest scenariu, serverul cu probleme vede migrațiile live „blocate” la 3% (în FCM) și nu puteți migra sau reporni VM-urile (se închid și nu revin niciodată) și majoritatea instrumentelor legate de hyper-v nu mai funcționează (de exemplu, get-vm se blochează și nu răspunde niciodată), iar SINGURA remediere la aceasta este resetarea hard a gazdei (oprirea/repornirea nu se finalizează). Nu putem găsi cauza acestui lucru și singurele simptome pe care le vedem sunt problemele de stabilitate a gazdei, așa cum s-a menționat mai sus.

Vă rog să-mi spuneți ce informații aveți nevoie pentru a vă ajuta să vă consiliați în această problemă.

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.