Skip to main content
Enterprise applications
Se proporciona el idioma español mediante traducción automática para su comodidad. En caso de alguna inconsistencia, el inglés precede al español.

Verificación de la alineación de WAFL

Colaboradores

La correcta alineación de WAFL es fundamental para un buen rendimiento. Aunque ONTAP gestiona bloques en 4KB unidades, este hecho no significa que ONTAP realice todas las operaciones en 4KB unidades. De hecho, ONTAP admite operaciones de bloque de diferentes tamaños, pero la contabilidad subyacente es administrada por WAFL en 4KB unidades.

El término “alineación” se refiere a cómo Oracle I/O corresponde a estas 4KB unidades. Para obtener un rendimiento óptimo, el bloque de 8KB KB de Oracle debe residir en dos bloques físicos de 4KB WAFL en una unidad. Si un bloque se equipara con 2KB, este bloque reside en la mitad de un bloque de 4KB KB, un 4KB bloque completo independiente y, a continuación, la mitad de un tercer bloque de 4KB KB. Esta disposición provoca una degradación del rendimiento.

La alineación no es un problema en los sistemas de archivos NAS. Los archivos de datos de Oracle se alinean con el inicio del archivo en función del tamaño del bloque de Oracle. Por lo tanto, los tamaños de bloque de 8KB, 16KB y 32KB se alinean siempre. Todas las operaciones de bloque se desplazan desde el inicio del archivo en unidades de 4 kilobytes.

Por el contrario, los LUN suelen contener algún tipo de encabezado de controlador o metadatos del sistema de archivos en su inicio que crea una desviación. La alineación rara vez es un problema en los sistemas operativos modernos, ya que estos sistemas operativos están diseñados para unidades físicas que podrían utilizar un sector nativo de 4KB, que también requiere que la E/S se alinee con los límites de 4KB para un rendimiento óptimo.

Sin embargo, hay algunas excepciones. Es posible que una base de datos se haya migrado desde un SO antiguo que no estaba optimizado para 4KB E/S, o que se haya producido un error de usuario durante la creación de la partición que podría haber producido un desplazamiento que no está en unidades de 4KB GB de tamaño.

Los siguientes ejemplos son específicos de Linux, pero el procedimiento se puede adaptar para cualquier sistema operativo.

Alineado

El siguiente ejemplo muestra una comprobación de alineación en una sola LUN con una partición única.

En primer lugar, cree la partición que utiliza todas las particiones disponibles en la unidad.

[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]#

La alineación se puede comprobar matemáticamente con el siguiente 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

La salida muestra que las unidades son de 512 bytes, y el inicio de la partición es de 32 unidades. Esto es un total de 32 x 512 = 16.834 bytes, que es un múltiplo completo de bloques de 4KB WAFL. Esta partición está correctamente alineada.

Para verificar la alineación correcta, lleve a cabo los siguientes pasos:

  1. Identifique el identificador único universal (UUID) de la LUN.

    FAS8040SAP::> lun show -v /vol/jfs_luns/lun0
                  Vserver Name: jfs
                      LUN UUID: ed95d953-1560-4f74-9006-85b352f58fcd
                        Mapped: mapped`                `
  2. Introduzca el shell del nodo en la controladora 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.
  3. Inicie recopilaciones estadísticas en el UUID de destino identificado en el primer paso.

    FAS8040SAP-02*> stats start lun:ed95d953-1560-4f74-9006-85b352f58fcd
    Stats identifier name is 'Ind0xffffff08b9536188'
    FAS8040SAP-02*>
  4. Realice algunas operaciones de I/O. Es importante utilizar el iflag Argumento para asegurarse de que la E/S es síncrona y no se almacena en búfer.

    Nota Tenga mucho cuidado con este comando. Inversión del if y.. of los argumentos destruyen los datos.
    [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
  5. Detenga las estadísticas y visualice el histograma de alineación. Todas las operaciones de I/O deben estar en la .0 Bucket, que indica las I/O alineadas con un límite de bloque de 4KB KB.

    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%

Mal alineado

En el siguiente ejemplo, se muestran operaciones de I/O mal alineadas:

  1. Cree una partición que no se alinee con un límite 4KB. Este no es el comportamiento predeterminado en los sistemas operativos modernos.

    [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.
  2. La partición se ha creado con un desplazamiento de 33 sectores en lugar del 32 por defecto. Repita el procedimiento descrito en "Alineado". El histograma aparece de la siguiente manera:

    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%

    La desalineación es clara. La E/S cae principalmente en el* *.1 período, que coincide con el desplazamiento esperado. Cuando se creó la partición, se movió 512 bytes más al dispositivo que el valor predeterminado optimizado, lo que significa que el histograma está compensado en 512 bytes.

    Además, el read_partial_blocks La estadística es diferente de cero, lo que significa que se han realizado I/O que no han llenado todo un bloque de 4KB KB.

Registro de repetición

Los procedimientos que se explican aquí son aplicables a los archivos de datos. Los redo logs y archive logs de Oracle tienen patrones de E/S diferentes. Por ejemplo, redo log es una sobrescritura circular de un único archivo. Si se utiliza el tamaño predeterminado de bloque de 512 bytes, las estadísticas de escritura se ven algo así:

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%

La E/S se distribuiría en todos los bloques de histograma, pero esto no supone un problema de rendimiento. Sin embargo, las tasas de redo-log extremadamente altas podrían beneficiarse del uso de un tamaño de bloque de 4KB KB. En este caso, es conveniente asegurarse de que los LUN de redo registro están alineados correctamente. Sin embargo, esto no es tan importante para un buen rendimiento como la alineación de archivos de datos.