VMware ESXi -pullonkaulojen järjestelmällinen selvitys
Hidas virtuaalikone ei kerro vielä, mikä resurssi on loppumassa. Käyttäjän kokema viive voi syntyä sovelluksesta, vieraskäyttöjärjestelmästä, prosessorin ajoituksesta, muistipaineesta, datastoresta tai fyysisestä verkosta. VMware ESXi näyttää jokaisesta kerroksesta mittareita, mutta yksittäinen korkea arvo ei ilman ajankohtaa ja työkuorman tuntemusta todista pullonkaulaa.
Hyvä vianrajaus alkaa tarkasta oireesta: mikä palvelu hidastui, milloin ongelma alkoi, ketä se koskee ja palautuuko toiminta itsestään. Vertaa samaa aikaväliä ESXi-isäntään, virtuaalikoneeseen ja riippuviin palveluihin. Muuta vain yksi asia kerrallaan ja kirjaa tulos, jotta korjaus ei perustu sattumaan.
VMware ESXi -ympäristön vertailutaso
Kerää normaalin päivän perustaso ennen häiriötä. Tallenna isännän CPU-käyttö, ready-aika, käytetty ja aktiivinen muisti, ballooning, swap, datastore-viive, IOPS, verkkoliikenne sekä pudotetut paketit. Erottele työpäivän huippu, yövarmistukset ja huoltoikkunat. Ilman vertailutasoa tavallinen varmistuspiikki voi näyttää poikkeamalta.
Määritä valvonnalle kaksi tasoa: varoitus antaa aikaa tutkia kehitystä, kriittinen hälytys vaatii toimenpiteen. Kiinteä prosenttiraja ei sovi kaikkeen. Esimerkiksi korkea CPU-käyttö voi olla tehokasta kapasiteetin hyödyntämistä, jos ready-aika on pieni ja sovellus vastaa tavoiteajassa.
VMware ESXi -prosessorin CPU ready
Virtuaalikoneen vCPU suorittaa työtä fyysisellä prosessorilla silloin, kun ESXi:n ajoitin antaa sille aikaa. CPU ready mittaa aikaa, jonka vCPU on valmis suorittamaan mutta odottaa vuoroaan. Korkea ready voi syntyä isännän ylikuormasta tai liian suuresta vCPU-määrästä. Suuri virtuaalikone tarvitsee useita ajoitusresursseja ja voi odottaa, vaikka sen oma keskimääräinen CPU-käyttö näyttää matalalta.
Älä lisää vCPU:ita automaattisesti hitaalle palvelimelle. Tarkista ensin vieraskäyttöjärjestelmän CPU-kuorma, ready-aika, isännän kokonaiskuorma ja sovelluksen säikeistys. Jos neljän vCPU:n kone käyttää jatkuvasti vain yhtä ydintä, pullonkaula voi olla sovelluksessa. Jos ready kasvaa ruuhka-aikana useissa koneissa, isännän konsolidointisuhde tai kuorman sijoittelu tarvitsee muutosta.
VMware ESXi -muistipaine ja palautusmekanismit
Virtuaalikoneelle määritetty muisti, vieraskäyttöjärjestelmän käyttämä muisti ja ESXi:n aktiiviseksi arvioima muisti ovat eri mittareita. Isäntä voi ylivarata muistia, mutta paineen kasvaessa se käyttää muistinhallinnan mekanismeja. Ballooning pyytää vieraskäyttöjärjestelmää luovuttamaan vähemmän tärkeää muistia takaisin hypervisorille. Hypervisorin swap on raskaampi vaihtoehto, koska ESXi ei tiedä, mitkä sivut ovat sovellukselle tärkeitä.
Jatkuva swap in tai swap out on selvä tutkimuskohde. Tarkista myös virtuaalikoneen oma sivutus, sillä vieraskäyttöjärjestelmä voi kärsiä muistipulasta ennen isäntää. Reservation takaa muistia mutta vähentää klusterin joustavuutta; limit voi kuristaa virtuaalikonetta, vaikka isännällä olisi vapaata kapasiteettia. Käytä niitä vain dokumentoidusta syystä.
VMware ESXi -datastoren viive
Tallennusongelma näkyy usein käyttäjälle koko sovelluksen hitautena. Tarkastele luku- ja kirjoitusviivettä, IOPS-määrää, siirtokokoa ja jonoja. Kokonaisviive voidaan jakaa laitteessa syntyvään ja ESXi-kernelissä jonottavaan osuuteen. Jos laiteviive kasvaa, taustalla voi olla levyjärjestelmän kuorma, välimuisti, polku tai verkko. Jos kernel-jono kasvaa, isännän ajoitus tai jonoasetukset voivat olla mukana.
Yhdistä havainto tallennusjärjestelmän omaan valvontaan. Snapshot-konsolidointi, varmistus, datastore-siirto ja tietokannan huoltotehtävä voivat osua samaan ajankohtaan. Keskimääräinen viive koko tunnilta peittää muutaman minuutin piikin, joten käytä riittävän tiheää näytteenottoa.
VMware ESXi -verkon suorituskyky
Seuraa fyysisten uplinkkien käyttöastetta, virheitä, pudotettuja paketteja ja linkin vaihtumista. Tarkista myös porttiryhmän, virtuaalikoneen vNICin ja vieraskäyttöjärjestelmän laskurit. Jos vain yksi virtuaalikone kärsii, ongelma voi olla sen ajurissa, asetuksessa tai sovelluksessa. Jos usean porttiryhmän liikenne hidastuu samalla uplinkillä, fyysinen linkki tai kytkinpolku on todennäköisempi kohde.
Varmistukset ja vMotion voivat täyttää linkin lyhyeksi ajaksi. Erota raskas VMkernel-liikenne tuotantoverkosta tai rajoita se suunnitellusti. Tarkista MTU koko polulla; osittainen jumbo frame -määritys aiheuttaa vaikeasti tulkittavia yhteysongelmia eikä suorituskykyetua.
VMware ESXi esxtop-työkalulla
esxtop näyttää reaaliaikaisen näkymän prosessoriin, muistiin, tallennuslaitteisiin, virtuaalilevyihin ja verkkoon. Se on tehokas, mutta suuri määrä sarakkeita voi johtaa väärään päätelmään. Aloita oireen mukaisesta näkymästä, säädä päivitysväliä ja tallenna havainto. Yksittäinen ruutu ei riitä trendin todistamiseen.
Batch-tilassa kerätty aineisto voidaan analysoida jälkikäteen, mikä on hyödyllistä lyhyen ruuhkan tutkimisessa. Keräys kasvattaa kuitenkin lokimäärää, joten määritä kesto ja tallennuspaikka etukäteen. Sulje SSH tutkimuksen jälkeen, jos se avattiin vain esxtopia varten.
VMware ESXi -virtuaalikoneen oikea mitoitus
Rightsizing tarkoittaa resurssien sovittamista todelliseen tarpeeseen. Liian pieni virtuaalikone sivuttaa tai jonottaa, mutta liian suuri kone kuluttaa ajoitus- ja kapasiteettiresursseja turhaan. Arvioi huippukuorma, kasvuvara ja sovelluksen lisensointimalli. Pienennä resursseja vain huoltoikkunassa ja seuraa vaikutusta sovittuun palvelutasoon.
NUMA-rakenne korostuu suurissa virtuaalikoneissa. Jos vCPU- ja muistimäärä ylittää fyysisen NUMA-solmun koon, muistiviive voi kasvaa. Älä muuta NUMA-asetuksia oletuksesta ilman mitattua ongelmaa ja alustan toiminnan ymmärtämistä.
VMware ESXi -vianrajaus vaiheittain
Varmista ensin aika, tapahtuman laajuus ja äskettäiset muutokset. Vertaa sovelluslokia ja vieraskäyttöjärjestelmän mittareita ESXi:n laskureihin. Tarkista sen jälkeen isännän jaetut resurssit sekä fyysinen laitteisto. Jos ongelma alkoi versionvaihdon jälkeen, etusivun VMware ESXi 8 -osio auttaa muistamaan laite- ja ajuriyhteensopivuuden merkityksen, mutta varsinainen syy todetaan mittareista ja lokeista.
Muutos tehdään hypoteesin testaamiseksi: esimerkiksi vCPU-määrää pienennetään, jotta ready-aika laskee, tai varmistusikkunaa siirretään, jotta datastore-viive tasaantuu. Jos odotettu mittari ei muutu, palauta asetus ja arvioi seuraava selitys. Tämä estää usean yhtäaikaisen muutoksen synnyttämän uuden ongelman.
Yhteenveto VMware ESXi -suorituskyvystä
Suorituskykyä hallitaan perustasolla, oikeilla mittareilla ja toistettavalla tutkimusprosessilla. CPU ready kertoo ajoituksen odotuksesta, ballooning ja swap muistipaineesta, datastore-viive I/O-polusta ja verkkolaskurit liikenteen häviöstä. Yhdistä aina ESXi:n havainto sovelluksen käyttäytymiseen ennen korjausta.