Ikke kast bort tid på å gjenvinne plass på tynn utstyrte VM-er

Da VMware vSphere 4 introduserte tynn forsyning for de virtuelle maskinens diskfiler (VMDK-er), var mange vSphere-administratorer veldig glade for å introdusere denne funksjonen i den virtualiserte infrastrukturen. Tynn tildeling forbruker i utgangspunktet bare plass som gjestestyringssystemet bruker den. Jeg liker å likestille dette med kakediagrammet som Windows tildeler for en stasjonsbokstav for å representere bruken. Hvis en 40 GB C: \ -stasjon kun bruker 18, 5 GB, vil kakediagrammet være nesten halvfullt. VMDK-filen bruker bare denne mengden også når tynn avsetning er i bruk.

Dette er greit for første gangs klargjøring og normal organisk vekst av en virtuell VMware-maskin. En god representasjon av en virtuell maskins diskbruk er i vSphere Client's Resources-delen, der en virtuell maskins disponerte og brukte lagringsmengder vises. Figur A viser en filserver i mitt personlige laboratorium som viser disse tildelingene. Figur A

Klikk på bildet for å forstørre det.

Fra et kontinuerlig planleggingsperspektiv har denne virtuelle maskinen mye ikke-tildelt plass, noe som kan forårsake et problem hvis andre virtuelle maskiner som dette begynner å konsumere mer av tildelingen. Koblingen for å oppdatere lagringsbruk er interessant; den vil oppgi hvordan den virtuelle maskinens forbruk har økt, men det hjelper lite å gjenspeile redusert forbruk.

Den tynne tilrettelagte VMDK er virkelig et enveis trafikkfenomen. Selv om det kan gå ned, hvis en stor mengde diskforbruk fjernes, er det ikke sikkert at lagringsbruksdisplayet går ned. Triks som Storage vMotion (til og med å konvertere VMDK-er til tykke og tilbake til tynne) oppgaver, reduserer heller ikke nødvendigvis forbruket. På grunn av dette kan det opprettes en virtuell maskin som kanskje bare bruker 30 GB i gjestestyringssystemet, men som fremdeles vises i vSphere Client og i en VMDK som bruker mye mer.

I laboratoriet mitt har jeg en virtuell SQL Server-maskin som hadde en 100 GB-database. Jeg slettet testdatabasen, og størrelsen på den virtuelle maskinen i Windows gikk ned til 30 GB rekkevidde. VSphere Client rapporterer fortsatt 100 GB data som brukes, selv etter en Storage vMotion-oppgave. Den gode nyheten er at påfølgende skriver til den virtuelle maskinen (si hvis jeg la til en 40 GB database) ville fungert innenfor den allerede forbrukte tildelingen.

Den eneste måten å virkelig redusere bruken på er å ha en ny region innen VMDK, noe som realistisk best gjøres med en ny VMDK; Dette er upraktisk for den daglige driften. Hvis det er en spesiell situasjon hvor en stor mengde lagring blir gjenvunnet, er det kanskje en grunn til en engangsoppgave.

Tynn tilførsel er ikke en hellig gral av effektivitet, men snarere en bekvemmelighet for å holde utnyttelsen høy. Fra lagringsperspektivet for tynn foredling, les et innlegg av Chris Evans i Storage Architect-bloggen om dette emnet. Videre kan tynn tildeling av VMDK-er forårsake unødig strid for I / O-ressurser på en datastore, som er en helt egen diskusjon.

Hvilke erfaringer har du hatt med tynnprimering av virtuelle maskiner og gjenvinning av plass? Gi oss beskjed i diskusjonen.

© Copyright 2021 | pepebotifarra.com