Vérification de l'alignement WAFL
Suggérer des modifications
PDF
Un alignement WAFL correct est essentiel pour de bonnes performances. Même si ONTAP gère des blocs dans des unités de 4 Ko, ONTAP ne réalise pas forcément toutes les opérations dans des unités de 4 Ko. ONTAP prend en charge les opérations en mode bloc de différentes tailles, mais la comptabilité sous-jacente est gérée par WAFL en unités de 4 Ko.
Le terme « alignement » fait référence à la manière dont les E/S Oracle correspondent à ces unités de 4 Ko. Pour optimiser les performances, un bloc Oracle de 8 Ko doit résider sur deux blocs physiques WAFL de 4 Ko sur un disque. Si un bloc est décalé de 2 Ko, ce bloc réside dans la moitié d'un bloc de 4 Ko, dans un bloc séparé complet de 4 Ko, puis dans la moitié d'un troisième bloc de 4 Ko. Cette configuration entraîne une dégradation des performances.
L'alignement n'est pas un problème avec les systèmes de fichiers NAS. Les fichiers de données Oracle sont alignés sur le début du fichier en fonction de la taille du bloc Oracle. Par conséquent, les tailles de bloc de 8 Ko, 16 Ko et 32 Ko sont toujours alignées. Toutes les opérations de bloc sont décalées par rapport au début du fichier en unités de 4 kilo-octets.
Les LUN, en revanche, contiennent généralement au départ un type d'en-tête de pilote ou de métadonnées de système de fichiers qui crée un décalage. L'alignement est rarement un problème dans les systèmes d'exploitation modernes, car ces systèmes d'exploitation sont conçus pour des disques physiques pouvant utiliser un secteur natif de 4 Ko. De plus, ils requièrent l'alignement des E/S sur les limites de 4 Ko pour des performances optimales.
Il y a toutefois quelques exceptions. Une base de données a peut-être été migrée à partir d'un système d'exploitation plus ancien qui n'a pas été optimisé pour les E/S de 4 Ko, ou une erreur de l'utilisateur lors de la création de la partition a pu entraîner un décalage qui ne se situe pas dans des unités de 4 Ko.
Les exemples suivants sont spécifiques à Linux, mais la procédure peut être adaptée à n'importe quel système d'exploitation.
Aligné
L'exemple suivant montre une vérification d'alignement sur une seule LUN avec une seule partition.
Tout d'abord, créez la partition qui utilise toutes les partitions disponibles sur le lecteur.
[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'alignement peut être vérifié mathématiquement à l'aide de la commande suivante :
[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
Le résultat indique que les unités sont de 512 octets et que le début de la partition est de 32 unités. Il s'agit d'un total de 32 x 512 = 16,834 octets, soit un ensemble de blocs WAFL de 4 Ko. Cette partition est correctement alignée.
Pour vérifier que l'alignement est correct, procédez comme suit :
-
Identifier l'UUID (identifiant universel unique) de la LUN
FAS8040SAP::> lun show -v /vol/jfs_luns/lun0 Vserver Name: jfs LUN UUID: ed95d953-1560-4f74-9006-85b352f58fcd Mapped: mapped` ` -
Entrez le shell du nœud sur le contrôleur 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. -
Démarrer les collections statistiques sur l'UUID cible identifié dans la première étape.
FAS8040SAP-02*> stats start lun:ed95d953-1560-4f74-9006-85b352f58fcd Stats identifier name is 'Ind0xffffff08b9536188' FAS8040SAP-02*>
-
Certaines E/S. Il est important d'utiliser le
iflagArgument permettant de s'assurer que les E/S sont synchrones et non mises en tampon.
Faites très attention avec cette commande. Inversion du ifetofles arguments détruisent les données.[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
-
Arrêtez les statistiques et affichez l'histogramme d'alignement. Toutes les E/S doivent se trouver dans le
.0Bucket, qui indique les E/S alignées sur les limites d'un bloc de 4 Ko.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%
Mauvais alignement
L'exemple suivant illustre un mauvais alignement des E/S :
-
Créez une partition qui ne s'aligne pas sur une limite de 4 Ko. Il ne s'agit pas d'un comportement par défaut sur les systèmes d'exploitation modernes.
[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 partition a été créée avec un décalage de 33 secteurs au lieu du décalage de 32 par défaut. Répétez la procédure décrite à la section "Aligné". L'histogramme s'affiche comme suit :
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%
Le mauvais alignement est clair. Les E/S tombent principalement dans le* *
.1godet, qui correspond au décalage attendu. Lorsque la partition a été créée, elle a été déplacée de 512 octets plus loin dans le périphérique que la valeur par défaut optimisée, ce qui signifie que l'histogramme est décalé de 512 octets.De plus, le
read_partial_blocksCes statistiques ne sont pas égales à zéro, ce qui signifie que des E/S n'ont pas rempli un bloc de 4 Ko entier.
Fichiers de reprise
Les procédures décrites ici s'appliquent aux fichiers de données. Les journaux de reprise et d'archivage Oracle ont différents modèles d'E/S. Par exemple, la journalisation de reprise est un remplacement circulaire d'un seul fichier. Si la taille de bloc par défaut de 512 octets est utilisée, les statistiques d'écriture se ressemblent à ceci :
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%
Les E/S sont réparties dans tous les compartiments de l'histogramme, mais cela n'est pas un problème de performances. Toutefois, des taux de journalisation de reprise extrêmement élevés peuvent bénéficier d'une taille de bloc de 4 Ko. Dans ce cas, il est conseillé de vérifier que les LUN de journalisation de reprise sont correctement alignées. Cependant, cette condition n'est pas aussi importante pour de bonnes performances que l'alignement des fichiers de données.