Risponderò in due parti: prima "perché la risposta tradizionale sulla separazione sequenziale e casuale spesso non si applica."
Quindi discuterò i potenziali vantaggi della separazione dei file sul disco fisico di Windows e dell'aggiunta di vHBA aggiuntivi e della distribuzione dei dischi fisici tra di loro.
In attesa del vantaggio derivante dalla separazione di I / O casuali e sequenziali a livello del disco fisico di Windows, in genere si presuppongono dispositivi HDD per l'archiviazione dei dati. Inoltre, presuppone in genere che dischi fisici Windows separati significino dispositivi HDD separati. L'idea è che alcuni set di HDD gestiscono principalmente I / O sequenziali del disco e hanno un movimento della testina del disco molto limitato (ad esempio gli HDD che ospitano un singolo txlog occupato) mentre un set separato di HDD gestisce I / O casuali del disco.
Quelle ipotesi raramente valgono oggi, specialmente in una macchina virtuale. Innanzitutto, a meno che i dischi fisici di Windows delle macchine virtuali non siano RDM, più di essi potrebbero trovarsi in un singolo archivio dati o forse più archivi dati si trovano su un singolo LUN host ESXi. Quindi ciò che è separato nell'ospite può essere mescolato a livello di host ESXi.
Ma supponiamo che vengano utilizzati RDM o che ogni disco fisico guest sia sul proprio archivio dati, sul proprio LUN ESXi. Anche in questo caso, sequenziale separato da io casuale nell'ospite viene spesso mescolato all'array, poiché i LUN presentati all'host ESXi potrebbero provenire dallo stesso singolo pool di dispositivi disco. Quasi ogni array di archiviazione lo fa ora - esclusivamente o come opzione per facilitare la gestione e aumentare l'efficienza dell'array / l'utilizzo delle risorse.
Infine, oggi tanto spazio di archiviazione è tutto flash o flash ibrido + HDD. Senza alcun movimento della testa di cui preoccuparsi, il flash non si preoccupa della separazione del sequenziale per casuale ... non si preoccupa nemmeno della tessitura IO.
Quindi ... questi sono tutti i motivi che separano sequenziale da casuale potrebbe non essere così benefico. Il prossimo motivo per cui la diffusione di file su dischi fisici e la diffusione di dischi fisici su vHBA possono comunque migliorare le prestazioni.
* In questo esempio di HDD ho citato espressamente un singolo registro delle transazioni. Quando diversi flussi IO sequenziali su disco separati (ad es. 8 registri delle transazioni occupati) si svolgono sugli stessi HDD - a meno che in qualche modo quasi tutta l'attività si trovi all'interno della cache SAN - lo spostamento costante della testa tra le tracce IO sequenziali porta alla tessitura IO. Questo è un tipo specifico di crash della testa del disco che porta a una latenza del disco "peggiore di quella casuale". Succede su RAID5 e RAID10, sebbene RAID10 possa tollerare solo un po 'più di variazione in questo senso rispetto a RAID5 prima di un degrado significativo.
Ora, dato che le discussioni a lungo termine su come la separazione sequenziale da casuale potrebbe non aiutare, come può ancora aiutare la diffusione di file su dischi fisici? Come può aiutare la distribuzione di dischi fisici tra i vHBA?
Riguarda le code IO del disco.
Qualsiasi disco fisico o LogicalDisk di Windows può avere fino a 255 I / O disco in sospeso alla volta in quello che perfmon viene indicato come "Coda disco corrente". Dagli IO del disco in sospeso nella coda del disco fisico, storport può passare fino a 254 al minidriver. Ma il minidriver può anche avere sia una coda di servizio (passata al livello inferiore successivo) sia una coda di attesa. E si può dire a Storport di abbassare il numero che passa da 254.
In un guest VMware per Windows, il driver pvscsi ha una profondità predefinita della coda "dispositivo" di 64, in cui il dispositivo è un disco fisico. Quindi, sebbene perfmon possa mostrare fino a 255 IO del disco in "lunghezza della coda del disco corrente" per un singolo disco fisico, solo fino a 64 di questi sarebbero passati al livello successivo alla volta (a meno che le impostazioni predefinite non vengano modificate).
Quanti IO del disco possono essere eccezionali per unoregistro delle transazioni occupato alla volta? Bene, le scritture del registro delle transazioni possono avere dimensioni massime di 60 KB. Durante un ETL su larga scala, vedrò spesso ogni scrittura sul txlog a 60kb. Il txlog writer può avere fino a 32 scritture da 60kb in sospeso su un txlog alla volta. E se avessi un txlog di gestione temporanea occupato e un dx txlog occupato sullo stesso disco fisico, con impostazioni VMware predefinite? Se entrambi i txlog raggiungono il massimo a 32 scritture eccezionali da 60kb ciascuna, quel disco fisico si trova alla sua profondità di coda di 64. Ora ... e se ci fossero anche file flat come sorgente ETL sul disco fisico? Bene ... tra le letture per i flatfile e le scritture su txlog, dovrebbero usare la coda di attesa, perché solo 64 possono uscire alla volta. Per i database con txlog occupati del genere, sia server fisici che virtuali, consiglio txlog sul proprio disco fisico, con nient'altro sul disco fisico. Ciò impedisce l'accodamento a quel livello ed elimina anche qualsiasi preoccupazione per il contenuto dell'interlacciamento di più file (che è una preoccupazione molto, molto minore in questi giorni).
Quanti IO del disco possono essere in sospeso in un file di riga alla volta (dal punto di vista di SQL Server, non necessariamente sottoposti a livelli inferiori)? Non c'è davvero un limite in SQL Server stesso (che ho trovato, comunque). Ma supponendo che il file si trova su un singolo Disco fisico di Windows (non mi consiglia di utilizzare i dischi dinamici a strisce a SQL Server, questo è un argomento per un'altra volta), non v'è un limite. Sono i 255 che ho menzionato prima.
Con la magia del readahead di SQL Server e l'IO asincrono, ho visto 4 query simultanee ciascuna in esecuzione nell'unità seriale una "lunghezza della coda del disco corrente" totale di oltre 1200! A causa del limite 255, ciò non è nemmeno possibile con tutti i contenuti del file di riga su un singolo disco fisico. Era contro un filegroup primario con 8 file, ognuno sul proprio disco fisico.
Quindi le letture readahead possono essere molto aggressive e possono stressare le code IO. Possono essere così aggressivi che altri file di righe leggono e scrivono finendo per aspettare. Se i registri delle transazioni si trovano sullo stesso disco fisico dei file di riga, durante le letture simultanee di lettura e scrittura di txlog è molto facile attendere che avvenga. Anche se quell'attesa non è al livello di "lunghezza della coda del disco corrente", potrebbe essere in attesa nella coda del dispositivo (64 per impostazione predefinita con pvscsi).
Anche le letture di backup su file di righe possono essere aggressive, soprattutto se il buffercount è stato ottimizzato per massimizzare la velocità di backup.
C'è un altro tipo di SQL Server io di cui tenere conto quando si considera di isolare txlogs: query spill to tempdb. Quando si verifica lo spill di query, ogni operazione di spilling scrive su tempdb. Hai un sacco di lavoratori paralleli che si rovesciano tutti contemporaneamente? Questo può essere un bel carico di scrittura. Mantenere un txlog occupato e file di righe importanti lontano da quello può essere davvero utile :-)
Ora è possibile modificare la profondità della coda dei dispositivi predefinita per il driver pvscsi. Il valore predefinito è 64 e può essere impostato su un massimo di 254, ovvero il numero massimo di storport che verranno trasmessi. Ma fai attenzione a cambiarlo. Consiglio sempre di allineare la profondità della coda del dispositivo guest con la profondità della coda LUN dell'host ESXi sottostante. E impostare la profondità della coda LUN dell'host ESXi per best practice di array. Usi un EMC VNX? La profondità della coda LUN host deve essere 32. L'ospite utilizza RDM? Grande. Impostare la profondità della coda del dispositivo pvscsi guest su 32 in modo che sia allineata con la profondità della coda LUN dell'host ESXi. EMC VMAX? In genere 64 a livello di host ESXi, 64 in guest. Pure / Xtremio / IBM FlashSystem? A volte la profondità della coda LUN dell'host viene impostata su 256! Vai avanti e imposta la profondità della coda del dispositivo pvscsi su 254 (massimo possibile).
Ecco un link con le istruzioni.
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2053145
Il link parla anche di requestringpages - WhatAreThose ?? Determinano la profondità della coda per l'adattatore pvscsi stesso. Ogni pagina fornisce 32 slot nella profondità della coda dell'adattatore. Per impostazione predefinita, requestringpages è 8 per una profondità della coda dell'adattatore di 256. Può essere impostato su 32 per 1024 slot di profondità della coda dell'adattatore.
Diciamo che tutto è predefinito. Ho 8 dischi fisici con file di righe su di essi e SQL Server è leggermente occupato. Esiste una media di 32 "lunghezza della coda del disco corrente" su 8 e nessuno è superiore a 64 (tutto si adatta alle varie code di servizio del dispositivo). Fantastico: questo dà 256 OIO. Si adatta alle code di servizio del dispositivo, si inserisce nella coda di servizio dell'adattatore, quindi tutti i 256 escono dal guest per le code a livello di host ESX.
Ma ... se le cose diventano un po 'più impegnative, quindi una media di 64 con una coda di alcuni dischi fisici fino a 128. Per quei dispositivi con più di 64 in sospeso, l'eccesso è in coda di attesa. Se nella coda di servizio dei dispositivi sono presenti più di 256 tra gli 8 dischi fisici, il sovraccarico si trova in una coda di attesa fino a quando non si aprono gli slot nella coda di servizio dell'adattatore.
In tal caso, l'aggiunta di un altro vHBA pvscsi e la diffusione dei dischi fisici tra di loro raddoppia la profondità totale della coda dell'adattatore a 512. È possibile trasferire più io dall'ospite all'host contemporaneamente.
Qualcosa di simile potrebbe essere ottenuto rimanendo in un adattatore pvscsi e aumentando le pagine di richiesta. Andare a 16 produrrebbe 512 slot e 32 produrrà 1024 slot.
Quando possibile, raccomando di allargare (aggiungendo adattatori) prima di approfondire (aumentando la profondità della coda dell'adattatore). Ma ... su molti dei sistemi più occupati, devo fare entrambe le cose: mettere 4 vHBA sul guest e aumentare la richiesta di pagine a 32.
Ci sono anche molte altre considerazioni. Cose come sioc e limitazione della profondità della coda adattiva se vengono utilizzati vmdks, configurazione del multipath, configurazione dell'adattatore ESXi oltre la profondità della coda LUN, ecc.
Ma non voglio esagerare con il mio benvenuto :-)
Lonny Niederstadt @sqL_handLe