VMware VMFS Datastore - Block size?

[Buzz76]

Driver å oppretter endel Datastores på 1TB hver på et FC SAN, men er blitt usikker på hva for BlockSize jeg skal benytte.

 

Bruker Thick provisioning.

 

Default er 1MB men begrenser filstørrelse til 256GB.

Har derfor valgt 2MB BlockSize for fil størrelser opp til 512GB hvilket er nok.

 

Men så leser jeg flere som anbefaler 8MB BlockSize med argumenter som at

- fordi ytelsen blir bedre

- mindre IO

- opptil 2TB fil størrelse

- minimalt med bortkastet plass fordi du allikevel har få filer iom at Datastore benyttes til VM's

 

Samtidig har jeg inntrykk av at VMware anbealer minst mulig BlockSize.

 

Noen med erfaring og tanker rundt dette?

Endret 27. juni 2011 av Buzz76

[wsp]

Tradisjonelt har det pga ytelse vært anbefalt å bruke preallokerte disker i VMware, men ny teknologi har muliggjort å bruke thin provisioning uten nevneverdig ytelsesdegradering.

 

8 MB blokkstørrelse gir bedre ytelse enn annen blokkstørrelse når man bruker thin provisioning, snapshot eller linked clones. Dette fordi disse filene vil da vokse med 8MB hver gang istedet for feks 1 eller 2 MB. Tradisjonelt sett har det vært slik at hver gang en slik fil vokser vil all IO på dette LUNet stoppe (på alle tilknyttede servere) da det sendes ut en scsi reservation. Siden VMFS 3.31 er forøvrig dette blitt noe bedre da det ble innført optimistic locking som prøver å konsolidere flere scsi reservations slik at det blir færre stopp. Hvs man derimot har et lagringssystem som støtter VAAI vil dette problemet være enda mindre da det vil bli brukt Hardware Assisted Locking.

 

Merk at blokkstørrelsen du setter kun gjelder for vmdk-filer. VMFS bruker sub-block allocation slik at loggfiler, konfigurasjonsfiler osv uansett bruker 64k blokkstørrelse.

 

Lars

[Buzz76]

Så hvis det ikke er noe negativt å benytte 8MB blocksize, hva er da vitsen med å kunne velge mindre?

[wsp]

Forskjellen var større i VMFS2-verdenen da det ikke fantes sub block allocation og mange småfiler ville da kaste bort mye plass pga overhead. Nå er det ingen grunn til å velge annet enn 8MB lenger og tror nok dette valget er her mest pga historiske årsaker og ser for meg at det forsvinner i en eller annen framtidig versjon.

 

Lars