Épico
Verificação do alinhamento do WAFL
Sugerir alterações
PDFs
O alinhamento correto do WAFL é essencial para um bom desempenho. Embora o ONTAP gere blocos em 4KB unidades, esse fato não significa que o ONTAP realize todas as operações em 4KB unidades. Na verdade, o ONTAP suporta operações de blocos de diferentes tamanhos, mas a contabilidade subjacente é gerenciada pela WAFL em 4KB unidades.
O termo "alinhamento" refere-se a como Oracle I/o corresponde a essas 4KB unidades. O desempenho ideal requer um bloco Oracle 8KBi para residir em dois blocos físicos de 4KB WAFL em uma unidade. Se um bloco é compensado por 2KB, este bloco reside em metade de um bloco 4KB, um bloco 4KB completo separado e, em seguida, metade de um terceiro bloco 4KB. Este arranjo causa degradação do desempenho.
O alinhamento não é um problema com sistemas de arquivos nas. Os arquivos de dados Oracle estão alinhados ao início do arquivo com base no tamanho do bloco Oracle. Portanto, os tamanhos de bloco de 8KB, 16KB e 32KB estão sempre alinhados. Todas as operações de bloco são compensadas desde o início do arquivo em unidades de 4 kilobytes.
Os LUNs, em contraste, geralmente contêm algum tipo de cabeçalho de driver ou metadados do sistema de arquivos no início que cria um deslocamento. O alinhamento raramente é um problema em sistemas operacionais modernos porque esses sistemas operacionais são projetados para unidades físicas que podem usar um setor 4KB nativo, que também requer que e/S sejam alinhados aos limites 4KB para um desempenho ideal.
Há, no entanto, algumas exceções. Um banco de dados pode ter sido migrado de um sistema operacional antigo que não foi otimizado para e/S 4KB, ou erro de usuário durante a criação da partição pode ter levado a um deslocamento que não está em unidades de tamanho 4KB.
Os exemplos a seguir são específicos do Linux, mas o procedimento pode ser adaptado para qualquer sistema operacional.
Alinhado
O exemplo a seguir mostra uma verificação de alinhamento em um único LUN com uma única partição.
Primeiro, crie a partição que usa todas as partições disponíveis na unidade.
[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]#
O alinhamento pode ser verificado matematicamente com o seguinte 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
A saída mostra que as unidades são 512 bytes e o início da partição é 32 unidades. Este é um total de 32 x 512 de 16.834 bytes, que é um múltiplo inteiro de 4KB blocos WAFL. Esta partição está corretamente alinhada.
Para verificar o alinhamento correto, execute as seguintes etapas:
-
Identifique o identificador universal único (UUID) do LUN.
FAS8040SAP::> lun show -v /vol/jfs_luns/lun0 Vserver Name: jfs LUN UUID: ed95d953-1560-4f74-9006-85b352f58fcd Mapped: mapped` ` -
Insira o shell do nó no controlador 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. -
Inicie coleções estatísticas no UUID alvo identificado no primeiro passo.
FAS8040SAP-02*> stats start lun:ed95d953-1560-4f74-9006-85b352f58fcd Stats identifier name is 'Ind0xffffff08b9536188' FAS8040SAP-02*>
-
Execute algumas I/O.. É importante usar o
iflagargumento para garantir que a e/S seja síncrona e não armazenada em buffer.
Tenha muito cuidado com este comando. Reverter os ifargumentos eofdestrói os dados.[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
-
Pare as estatísticas e veja o histograma de alinhamento. Toda a e/S deve estar no
.0balde, o que indica e/S que está alinhada a um limite de bloco 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%
Desalinhado
O exemplo a seguir mostra e/S desalinhadas:
-
Crie uma partição que não esteja alinhada a um limite 4KB. Este não é um comportamento padrão em sistemas operacionais 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. -
A partição foi criada com um deslocamento de 33 setores em vez do padrão 32. Repita o procedimento descrito em "Alinhado". O histograma aparece da seguinte forma:
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%
O desalinhamento é claro. A e/S cai principalmente no bucket**
.1, que corresponde ao deslocamento esperado. Quando a partição foi criada, ela foi movida 512 bytes mais para o dispositivo do que o padrão otimizado, o que significa que o histograma é deslocado em 512 bytes.Além disso, a
read_partial_blocksestatística é diferente de zero, o que significa que I/o foi realizado que não preencheu um bloco 4KB inteiro.
Refazer o registo
Os procedimentos aqui explicados são aplicáveis aos datafiles. Os logs do Oracle refazer e os logs de arquivamento têm padrões de e/S diferentes. Por exemplo, refazer o Registro é uma substituição circular de um único arquivo. Se o tamanho padrão de bloco de 512 bytes for usado, as estatísticas de gravação são semelhantes a isso:
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%
A e/S seria distribuída em todos os intervalos de histograma, mas isso não é uma preocupação de desempenho. No entanto, as taxas de refazer o log extremamente altas podem se beneficiar do uso de um tamanho de bloco de 4KBMB. Nesse caso, é desejável garantir que os LUNs de refazer o log estejam alinhados corretamente. No entanto, isso não é tão crítico para um bom desempenho como o alinhamento de arquivos de dados.
