Verifica dell'allineamento di WAFL
Suggerisci modifiche
PDF
Il corretto allineamento dell'WAFL è fondamentale per garantire buone prestazioni. Sebbene ONTAP gestisca blocchi in 4KB unità, questo fatto non significa che ONTAP esegua tutte le operazioni in 4KB unità. Infatti, ONTAP supporta operazioni a blocchi di diverse dimensioni, ma la contabilità sottostante è gestita da WAFL in 4KB unità.
Il termine "allineamento" si riferisce al modo in cui l'i/o Oracle corrisponde a queste unità 4KB. Per ottenere prestazioni ottimali è necessario che un blocco Oracle 8KB risieda su due blocchi fisici da 4KB WAFL su un'unità. Se un blocco è sfalsato di 2KB, questo blocco risiede su metà di un blocco 4KB, un blocco 4KB completo separato e quindi sulla metà di un terzo blocco 4KB. Questa disposizione causa un peggioramento delle prestazioni.
L'allineamento non è un problema con i file system NAS. I file di dati Oracle sono allineati all'inizio del file in base alle dimensioni del blocco Oracle. Pertanto, le dimensioni dei blocchi di 8KB, 16KB e 32KB sono sempre allineate. Tutte le operazioni di blocco sono sfalsate dall'inizio del file in unità di 4 kilobyte.
I LUN, al contrario, contengono generalmente qualche tipo di intestazione del driver o metadati del file system all'inizio che creano un offset. L'allineamento è raramente un problema nei sistemi operativi moderni, perché questi sistemi operativi sono progettati per unità fisiche che potrebbero utilizzare un settore 4KB nativo, che richiede anche l'allineamento dell'i/o ai confini del 4KB per ottenere prestazioni ottimali.
Ci sono, tuttavia, alcune eccezioni. È possibile che un database sia stato migrato da un sistema operativo meno recente non ottimizzato per i/o 4KB o che un errore utente durante la creazione della partizione abbia causato un offset che non è in unità di 4KB.
I seguenti esempi sono specifici per Linux, ma la procedura può essere adattata per qualsiasi sistema operativo.
Allineato
L'esempio seguente mostra un controllo dell'allineamento su un singolo LUN con una singola partizione.
Innanzitutto, creare la partizione che utilizza tutte le partizioni disponibili sul disco.
[root@host0 iscsi]# fdisk /dev/sdb
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel with disk identifier 0xb97f94c1.
Changes will remain in memory only, until you decide to write them.
After that, of course, the previous content won't be recoverable.
The device presents a logical sector size that is smaller than
the physical sector size. Aligning to a physical sector (or optimal
I/O) size boundary is recommended, or performance may be impacted.
Command (m for help): n
Command action
e extended
p primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-10240, default 1):
Using default value 1
Last cylinder, +cylinders or +size{K,M,G} (1-10240, default 10240):
Using default value 10240
Command (m for help): w
The partition table has been altered!
Calling ioctl() to re-read partition table.
Syncing disks.
[root@host0 iscsi]#
L'allineamento può essere controllato matematicamente con il seguente comando:
[root@host0 iscsi]# fdisk -u -l /dev/sdb Disk /dev/sdb: 10.7 GB, 10737418240 bytes 64 heads, 32 sectors/track, 10240 cylinders, total 20971520 sectors Units = sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 4096 bytes I/O size (minimum/optimal): 4096 bytes / 65536 bytes Disk identifier: 0xb97f94c1 Device Boot Start End Blocks Id System /dev/sdb1 32 20971519 10485744 83 Linux
L'output mostra che le unità sono 512 byte, e l'inizio della partizione è 32 unità. Si tratta di un totale di 32 x 512 = 16.834 byte, ovvero un multiplo intero di 4KB blocchi WAFL. Questa partizione è allineata correttamente.
Per verificare il corretto allineamento, attenersi alla seguente procedura:
-
Identificare l'UUID (Universal Unique Identifier) del LUN.
FAS8040SAP::> lun show -v /vol/jfs_luns/lun0 Vserver Name: jfs LUN UUID: ed95d953-1560-4f74-9006-85b352f58fcd Mapped: mapped` ` -
Immettere la shell del nodo sul controller ONTAP.
FAS8040SAP::> node run -node FAS8040SAP-02 Type 'exit' or 'Ctrl-D' to return to the CLI FAS8040SAP-02> set advanced set not found. Type '?' for a list of commands FAS8040SAP-02> priv set advanced Warning: These advanced commands are potentially dangerous; use them only when directed to do so by NetApp personnel. -
Avviare le raccolte statistiche sull'UUID di destinazione identificato nel primo passaggio.
FAS8040SAP-02*> stats start lun:ed95d953-1560-4f74-9006-85b352f58fcd Stats identifier name is 'Ind0xffffff08b9536188' FAS8040SAP-02*>
-
Eseguire alcuni i/O. È importante utilizzare
iflagArgomento per assicurarsi che i/o sia sincrono e non bufferizzato.
Prestare molta attenzione con questo comando. Inversione del ife.ofgli argomenti distruggono i dati.[root@host0 iscsi]# dd if=/dev/sdb1 of=/dev/null iflag=dsync count=1000 bs=4096 1000+0 records in 1000+0 records out 4096000 bytes (4.1 MB) copied, 0.0186706 s, 219 MB/s
-
Arrestare le statistiche e visualizzare l'istogramma di allineamento. Tutti i i/o devono trovarsi in
.0Bucket, che indica i/o allineato al limite di un blocco 4KB.FAS8040SAP-02*> stats stop StatisticsID: Ind0xffffff08b9536188 lun:ed95d953-1560-4f74-9006-85b352f58fcd:instance_uuid:ed95d953-1560-4f74-9006-85b352f58fcd lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_align_histo.0:186% lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_align_histo.1:0% lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_align_histo.2:0% lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_align_histo.3:0% lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_align_histo.4:0% lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_align_histo.5:0% lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_align_histo.6:0% lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_align_histo.7:0%
Disallineato
L'esempio seguente mostra i/o disallineati:
-
Creare una partizione che non si allinea a un confine 4KB. Questo non è il comportamento predefinito sui sistemi operativi moderni.
[root@host0 iscsi]# fdisk -u /dev/sdb Command (m for help): n Command action e extended p primary partition (1-4) p Partition number (1-4): 1 First sector (32-20971519, default 32): 33 Last sector, +sectors or +size{K,M,G} (33-20971519, default 20971519): Using default value 20971519 Command (m for help): w The partition table has been altered! Calling ioctl() to re-read partition table. Syncing disks. -
La partizione è stata creata con un offset a 33 settori anziché con il valore predefinito 32. Ripetere la procedura descritta in "Allineato". L'istogramma viene visualizzato come segue:
FAS8040SAP-02*> stats stop StatisticsID: Ind0xffffff0468242e78 lun:ed95d953-1560-4f74-9006-85b352f58fcd:instance_uuid:ed95d953-1560-4f74-9006-85b352f58fcd lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_align_histo.0:0% lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_align_histo.1:136% lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_align_histo.2:4% lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_align_histo.3:0% lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_align_histo.4:0% lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_align_histo.5:0% lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_align_histo.6:0% lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_align_histo.7:0% lun:ed95d953-1560-4f74-9006-85b352f58fcd:read_partial_blocks:31%
Il disallineamento è chiaro. L'i/o rientra principalmente in* *
.1benna, che corrisponde all'offset previsto. Quando la partizione è stata creata, è stata spostata di 512 byte più avanti nel dispositivo rispetto al valore predefinito ottimizzato, il che significa che l'istogramma è spostato di 512 byte.Inoltre, il
read_partial_blocksLe statistiche sono diverse da zero, il che significa che è stato eseguito l'i/o che non ha riempito l'intero blocco da 4KB KB.
Ripristina la logging
Le procedure qui spiegate sono applicabili ai file di dati. I log di ripristino e gli archivi di Oracle hanno modelli di i/o diversi. Ad esempio, il redo logging è una sovrascrittura circolare di un singolo file. Se si utilizza la dimensione predefinita del blocco da 512 byte, le statistiche di scrittura sono simili a queste:
FAS8040SAP-02*> stats stop StatisticsID: Ind0xffffff0468242e78 lun:ed95d953-1560-4f74-9006-85b352f58fcd:instance_uuid:ed95d953-1560-4f74-9006-85b352f58fcd lun:ed95d953-1560-4f74-9006-85b352f58fcd:write_align_histo.0:12% lun:ed95d953-1560-4f74-9006-85b352f58fcd:write_align_histo.1:8% lun:ed95d953-1560-4f74-9006-85b352f58fcd:write_align_histo.2:4% lun:ed95d953-1560-4f74-9006-85b352f58fcd:write_align_histo.3:10% lun:ed95d953-1560-4f74-9006-85b352f58fcd:write_align_histo.4:13% lun:ed95d953-1560-4f74-9006-85b352f58fcd:write_align_histo.5:6% lun:ed95d953-1560-4f74-9006-85b352f58fcd:write_align_histo.6:8% lun:ed95d953-1560-4f74-9006-85b352f58fcd:write_align_histo.7:10% lun:ed95d953-1560-4f74-9006-85b352f58fcd:write_partial_blocks:85%
L'i/o viene distribuito in tutti i bucket di istogramma, ma non si tratta di un problema di prestazioni. Velocità di redo-logging estremamente elevate potrebbero, tuttavia, trarre vantaggio dall'utilizzo di dimensioni del blocco di 4KB KB. In questo caso, è consigliabile assicurarsi che i LUN di redo-logging siano allineati correttamente. Tuttavia, questo non è importante per le buone prestazioni come l'allineamento dei file dati.