Antes de falar sobre a importância do alinhamento de discos, precisamos antes saber algumas nomenclaturas importantes.
Abaixo adicionei uma foto de um disco para podermos entender melhor.
Nomenclaturas:
Sectors: representa o menor pedaço de dados que pode ser lido ou escrito em um disco físico. A maioria dos discos possuem
setores (
sectors) de 512 bytes. Discos novos podem oferecer setores com tamanhos 1KB, 2KB, ou 4KB.
Clusters: são conhecidos por muitos como
unidade de alocação de arquivo (
file allocation unit). Seu tamanho é determinado quando a partição é formatada pelo Sistema Operacional. Cluster é definido por um grupo de setores (sectors) , seu tamannho ira depender do valor que foi definido para o
file alocation unit. A maioria dos discos utilizam o tamanho de um
setor de 512 bytes, considerando um file alocation unit de 64k então, 64K/512 bytes teremos 128 setores por cluster. Lembrando que
Cluster = file alocation unit.
Track: cada lado de um disco (
Platter) possui milhares de
trilhas (
tracks) onde são inseridos os
setores (
sectors) e por sua vez os
clusters
Platters: são um ou mais
pratos (
Platters )de formato circular e de metal (quantidade depende do Hard Disk) onde são armazenadas as informações na superfície.
Stripe Unit Size: define o tamanho que os dados serão distribuídos entre os discos de um grupo RAID-0, RAID-10 ou RAID5.
Agora que entendemos as nomenclaturas podemos começar a falar sobre a importância de se alinhar um disco. O alinhamento de discos deve ser considerado para os volumes que são utilizados pelos arquivos de dados e transaction log do SQL Server.
Outra consideração importante é que o alinhamento deve ser considerado no Windows Server 2003 que não faz o alinhamento do disco por default. No Windows Server 2008 o alinhamento de discos é feito de forma automática, no entanto eu quero deixar um alerta devido ao que tenho visto em meus clientes aqui nos EUA que estão utilizando Windows Server 2008 e mesmo assim não estão com os discos alinhados. Em caso de migrações de Windows Server 2003 para Windows Server 2008, geralmente a storage é apresentada para o novo Sistema Operacional, no caso o Windows Server 2008, sem precisar redefinir os particionamentos. Mesmo sabendo que no Windows Server 2008 o alinhamento é feito por default, nesse caso não será feito porque as partições foram criados enquanto estavam no Windows Server 2003. O alinhamento é feito durante a criação da partição.
Para entendermos o porquê é necessário o alinhamento de um disco, devemos entender que todo disco usa algum espaço para armazenar informações sobre a partição, que então irão utilizar alguns setores ocultos (hidden sectors). Especialmente no Windows Server 2003 são reportados 63 setores ocultos por default. Considerando que cada setor possui
512 bytes então temos que
63 * 512 = 31.5 K que o disco ira utilizar para armazenar informações sobre a partição.
Tendo esse numero em mente vamos entender porque o disco fica desalinhado. Guarde bem em sua memória esses numeros.
Se você precisar consultar a nomenclatura acima novamente, sinta-se a vontade. Para refrescar a sua memória o
Stripe Unit Size é determinado pela equipe de Storage no momento de criação das Luns, vamos considerar 64K para o nosso exemplo.
Stripe Unit Size é o tamanho do “pedaço” de dados que será distribuído entre os discos de um Array da Storage.
Temos a seguinte configuração para usarmos como exemplo.
Stripe Size = 64K
Alocation Unit Size ou Cluster Size = 64K
Exemplo de um disco desalinhado.
No exemplo acima podemos ver uma situação de disco desalinhado, o
Stripe Unit Size definido pela equipe de storage, possui um tamanho de 64k e esta representado na cor Azul na primeira linha da figura. O
Stripe Unit Size define os limites fisicos de armazenamento para o Array.
Na segunda linha em amarelo podemos ver os setores que são utilizados para armazenar informações sobre a partição. Lembre-se que no Windows Server 2003 por default é utilizado 63 setores, considerando que o tamanho do setor é 512 bytes então teremos 31.5 K. Eu disse para você memorizar esse número. Repare que esse valor não preenche totalmente o tamanho definido pelo
Stripe Unit Size que é 64K, deixando um espaço a ser preenchido. Então imagina o que irá acontecer quando os dados de usuário começar a ser gravado no disco.
Como exemplificado na linha 3 os dados de usuário, representado na cor verde, que nesse caso possui tamanho de alocação de 64K, definido pelo
Alloc Unit Size, ira ser inserido entre dois espaços definidos no disco pelo
Stripe Unit Size. Sempre que um dado de usuário ser inserido nos próximos espaços estará desalinhado em relação ao
Stripe Unit Size definido para o Array.
Então como podemos resolver esse problema? Imagine se de alguma forma você reservasse um espaço para armazenamento de informações sobre a partição, onde o dado representado em amarelo preenchesse os 64K ao invés de 31.5K e então utilizar todo espaço definido pelo
Stripe Unit no nosso exemplo a area em azul. Aconteceria que o próximo dado de usuário a ser inserido, representado em verde, iniciaria a partir do segundo
Stripe Unit de 64K, evitando que a alocação feita pelo usuário não estaria entre dois espaços definidos pelo
Stripe Unit. Consequentemente evitando o IO em dois lugares distintos onde precisaria apenas um.
Vamos ver agora como ficaria um exemplo utilizando um alinhamento onde reservaremos todo o espaço de 64K definido pelo Stripe Unit.
Nesse exemplo acima ao inves de usar o alinhamento default do Windows Server 2003 e utilizar apenas 31.5K, fizemos diferente e definimos o parametro
align para 64K que esta representado em amarelo.
Isso irá preencher todo o espaço de 64K definido pelo parametro
Stripe Unit, então as próximas alocações de dados de usuários, iniciara e terminara dentro do espaço definido pelo
Stripe Unit.
Mesmo se for definido o
Alloc Unit size/Cluster Size que é o bloco de dados gravado pelo usuário de 4K, estara ainda assim dentro do limite de 64K. Nesse caso serão necessarios 16 blocos de alocação de dados para preencher um Stripe Unite. Repare 16 * 4 = 64K portanto ainda estara alinhado.
Após entender essa teoria concluímos que o parâmetro
Align dividido pelo
Stripe Unit Size devera ser um numero inteiro sempre.
Como não se sabe a quantidade de espaço necessário para armazenar informações sobre a partição para os diferentes discos existentes no mercado, então a Microsoft recomenda utilizar o valor de alinhamento como 1024k ou 1MB.
Isso significa que assim como fizemos com 64k reservando espaço para dados de partição para garantir que os dados de usuário sejam gravados de acordo com o
Stripe Unit, que nesse exemplo é 64K, podemos fazer o mesmo usando o valor 1024K recomendado pela Microsoft.
Se pegarmos o exemplo que usamos anteriormente usando um alinhamento de 64k ao invés de 31.5K (Windows Server 2003 Default) e um
Stripe Unit Size de 64K temos o seguinte:
64K / 64K = 1 onde o resultado é igual a 1 bloco de
Stripe Unit. Representado em amarelo, usamos 1 unidade para
setores ocultos, para então iniciar a gravação dos usuários de acordo com os limites fisicos definidos pelo parametro
Stripe Unit Size.
Podemos fazer o mesmo com o parametro de alinhamento 1024K e
Stripe Unit Size de 64k
1024K / 64K = 16 o resultado aqui é também um numero inteiro, que significa que antes de iniciar a gravação de dados de usuários, iremos preencher 16 unidades de amarelo para
setores ocultos, para então iniciar a gravação dos dados de usuário. Isso irá resultar que serão preenchidos 16 unidades de 64K para iniciar a gravação dos dados de usuário, que por sua vez estará alinhado com os limites fisicos definidos por
Stripe Unit Size
Considerações
Align value : Stripe Unit Size deve ser um numero inteiro para que o disco grave de forma alinhada.
Allocation Unit Size que são blocos de dados de usuário, recomenda-se ser o mesmo valor de
Stripe Unit Size.
Espero que tenham gostado do Post sobre alinhamento de discos e aguardo comentários caso tenham alguma dúvida. Em um outro post mostrarei como fazer o alinhamento de discos.
Para maiores informações e detalhes recomendo a leitura do Whitepaper Disk Partition Alignment Best Practices for SQL Server
http://msdn.microsoft.com/en-us/library/dd758814(v=sql.100).aspx
