Partition Offset e Cluster Size – Como verificar?

Boa tarde!

Várias vezes referi a importância de termos o offset das partições e o tamanho do cluster bem definidos.

Para uma performance óptima, do lado do SQL Server, temos que assegurar que o offset da partição é de 1024 Kb (ou 1048576 Bytes). Já no caso do cluster, o valor a se ter em conta é 64Kb.

O ideal é verificar estes valores antes da instalação do SQL Server, pois o “remédio”é reformatar os disco.

Como verificar estes valores?

Verificar o offset de todas as partições:

Execute na command line o seguinte:
wmic partition get BlockSize, StartingOffset, Name, Index

O output será algo como o seguinte:
BlockSize  Index  Name                   StartingOffset
512        0      Disk #4, Partition #0  1048576
512        0      Disk #5, Partition #0  135266304
512        1      Disk #5, Partition #1  17408
512        0      Disk #3, Partition #0  1048576
512        0      Disk #1, Partition #0  1048576
512        1      Disk #1, Partition #1  105906176
512        2      Disk #1, Partition #2  52428800000
512        0      Disk #2, Partition #0  1048576
512        0      Disk #0, Partition #0  1048576

A coluna StartingOffset devolve os valores que queremos. Para relacionar os discos com uma letra, verifique o valor na coluna “Name”, e compare o número do disco com o valor descrito na tool “Disk Management” do Windows.

Verificar o tamanho da allocation unit:

Execute na command line o seguinte:
fsutil fsinfo ntfsinfo <drive letter>
Exemplo:

fsutil fsinfo ntfsinfo f:

O output será equivalente ao seguinte:
NTFS Volume Serial Number :       0x66ac6ab3ac6a7d85
Version :                         3.1
Number Sectors :                  0x0000000055701fff
Total Clusters :                  0x000000000aae03ff
Free Clusters  :                  0x000000000963a5c8
Total Reserved :                  0×0000000000000000
Bytes Per Sector  :               512
Bytes Per Cluster :               4096
Bytes Per FileRecord Segment    : 1024
Clusters Per FileRecord Segment : 0
Mft Valid Data Length :           0×0000000000140000
Mft Start Lcn  :                  0x00000000000c0000
Mft2 Start Lcn :                  0×0000000000000002
Mft Zone Start :                  0x00000000000c0140
Mft Zone End   :                  0x00000000000cc940
RM Identifier:        BE2060B1-AFBC-11DF-9B68-1CC1DE750143

A informação a reter aqui é “Bytes Per Cluster”.  Neste caso o disco está formatado com blocos de 4Kb. O está longe dos 64Kb recomendados.


A verificação destes pontos é muito importante e, acredite, isso influencia na performance do SQL Server, principalmente se o offset estiver mal definido.

Até a próxima!

SMB File Share e SQL Server: Uma opção a se considerar

Introdução
Quando relacionamos file shares e bases de dados, muitas pessoas torcem o nariz – mas hoje a realidade é outra, e pormos utilizar file shares, em alguns casos, em produção.
A Microsoft passou os últimos anos a trabalhar em melhorias no SMB (Service Message Block), que passou a ser muito mais confiável hoje em dia.

No passado, era possível a utilização de shares para alojamento de ficheiros dados e logs, porém a trace flag 1807 deveria estar activa. De qualquer maneira, isso não era oficialmente suportado, por conta do risco de que erros na rede pudessem danificar a integridade das base de dados, alem de implicações a nível de performance.

Hoje em dia a realidade é diferente. Apartir do SQL Servr 2012 é possível utilizar file shares de forma suportada para alojar as bases de dados de sistema, assim como user databases. Isso tudo graças as melhorias de feitas no SMB durante os últimos anos. E ainda melhor! Esta opção se aplica a instâncias stand-alone e em cluster ! Aliás, hoje em dia é possível se criar um cluster inteiro baseado em file shares (mesmo para o Quorum do WFC).

Em cada versão do Windows, uma versão nova do SMB “vem agarrada”, e no actual Windows Server 2012 R2 nós já estamos na versão 3.02, mas foi na versão 3.0 que as grandes melhorias a nível de performance e funcionalidade vieram.

Segue uma lista com as versões do Windows e SMB e a melhoria mais relevante trazida, no meu ponto de vista:

  • Windows Server 2008 (SMB 2.0)
    Durabilidade, que ajuda na recuperação de falhas ma rede.
  • Windows Server 2008 R2 (SMB 2.1)
    Melhorias de performance significantes, focando em estilos de carga como OLTP.
  • Windows Server 2012 (SMB 3.0)
    Suporte a failover transparente da file share, com zero downtime.
  • Windows Server 2012 R2 (SMB 3.02)
    O MTU vem activo por padrão, o que melhora significativamente a performance de grandes ficheiros sequenciais, a exemplo de data warehouse além de backups ou restores.


Como funciona?

Para começar a utilizar file shares para alojar as suas bases de dados, algumas regras devem ser seguidas. Para começar, as contas de serviço do SQL Server Engine a Agent devem ter FULL CONTROL  e permissões NTFS nas pastas partilhadas.

Outra informação importante é sobre os Universal Naming Convention (UNC) suportados:

  • \ServerNameShareName
  • \ServerNameShareName

Já os seguintes  não são suportados:

  • Não podemos utilizar loopback, ou seja, a share não pode pertencer a nenhum dos nós do cluster.
  • Shares administrativas, como \\servername\x$
  • Outros formatos de UNC, como \\?x:\
  • Network drives mapeados.

O processo de se instalar uma instância utilizando SMB é tão simples quanto indicar a UNC ao invés de um disco mapeado por uma letra, como se mostra na imagem abaixo:


outra opção é executar o comando “CREATE DATABASE” apontando para os ficheiros de dados e log que estão na rede:

Note que para instalações de cluster as file shares não irão fazer parte do grupo do SQL Server, ou seja, não serão controladas pelo cluster.


Atenção!

Ao se utilizar file shares como opção de storage, a performance da rede passa a ser mais do que crítica. Em uma situação normal, nós já temos um bom trafego na rede, mas agora temos um tempero a mais – o acesso aos ficheiros é feito pela rede!

Então o que se fazer? 
Eu tenho duas sugestões:

  1. Criar uma rede dedica para acesso a file share. Desta forma a conexão dos clientes a instância, seus acessos RDP, a transferencias de ficheiros (como SP ou Hot-fixes) não irá interferir com o acesso aos dados.
  2. Monitorar! Como não temos controle do que acontece no servidor de file share, temos que monitorar o máximo possível, desta forma podemos despistar problemas. Podemos monitorizar os seguintes pontos:
    • Contadores do disco.
    • Utilização do CPU.
    • Utilização da memória.

Para finalizar, como podemos aproveitar esta possibilidade?

Antes de qualquer coisa, em um ambiente em cluster,  a utilização da SAN é a melhor opção, assim como em standalone discos locais são preferíveis.

De qualquer forma, o uso do SMB pode ser benéfico em alguma situação específicas:

  • Montar instancias low-cost em cluster.
  • Servidores não produtivos ou de DR.
  • Alojamento de uma Bases de dados leve.
  • Ficheiros de dados com histórico.
  • Storage temporário – para emergências.
  • Migrações.

Em Resumo
Temos hoje mais uma opção para alojar as nonas bases de dados, para infâncias em cluster ou standalone. De qualquer forma, devemos planear com cuidado as nossas estratégias, porque infelizmente, o melhor ainda é moais custoso (€€).
Tudo depende do orçamento, do propósito das bases de dados e suas características.

Espero que o artigo tenha sido útil!

Até a próxima!!

Clustered Shared Volumes (CSV) #SQL2014

Cara nova no SQL Server 2014, a tecnologia “Clustered Shared Volumes”, ou simplesmente CSV, não é tão nova assim no mundo Microsoft. CSVs eram até então utilizados para facilitar a gestão de máquinas virtuais, facilitando o acesso aos ficheiros VHD através de um volume partilhado e acessível a todos os nós. Suportado desde o Windows 2008 R8 esta possibilidade é agora aceite pelo SQL Server 2014!

Basicamente, os CSV simplificam a gestão de storage mantendo um volume acessível por todos os nós de um cluster, em simultâneo.  Sendo que um nó é o owner do volume – o “Coordinator Node”.
O Coordinator Node tira vantagem do protocolo SMB (Server Message Block) para gerir as operações de I/O entre os nós do cluster sobre o volume. Todas as operações de escrita de meta dados são geridas e passadas pelo Coordinator, já as operações de escrita e leitura de dados são passadas de forma directa ao storage partilhado.

Esta estratégia também aumenta a robustez de um cluster, pois é aberto mais um caminho de acesso alternativo aos dados contidos no volume. Este caminho é utilizado caso haja uma falha, que por sua vez pode ser detectada através do sistema de detecção e recuperação de falhas de I/O. O cluster irá escolher o melhor caminho para efectuar as operações de I/O, escolhendo a rede com o melhor tempo de resposta – o que também pode ser definido manualmente.

O CSV é um “NTFS reparse point”, assim como um mountpoint, e é acessível através da path %SystemDrive%ClusterStorage, ou seja, não é montado como um disco – o que tem suas vantagens e desvantagens. Podemos verificar, na imagem seguinte, dois CSV montados.

O caminho de acesso ao volume será o mesmo em todos os nós do cluster e estarão, em condições normais, sempre activos e acessíveis para leitura e escrita – Obviamente respeitando as permissões de acesso aos ficheiros. 
Como o volume já está montado e acessível em todos os nós, o failover de uma instância de SQL Server terá o seu tempo muito reduzido, pois não será mais preciso “desmontar” o volume de um nó e “montar” no futuro nó activo. Assim sendo, apenas os serviços do SQL Server irão ficar offline em um nó e online em outro nó. Se juntarmos a esta festa um disco local para a TempDB, teremos um startup bem eficiente.
Como criar um CSV?
Não há mistério! Uma vez tendo discos disponíveis no cluster, basta clicar “sobre” o disco desejado, com o botão direito, e aceder as opções associadas a este disco, assim sendo ao seleccionar a opção “Add to Cluster Shared Volumes” o trabalho estará feito. Simples assim, como mostra a seguinte imagem.

Na conclusão do processo, podemos verificar que a coluna “Assigned To” irá apresenta o texto “Clustered Shared Volume”, ao invés de uma “Role” específica. O disco estará acessível por todos os nós.

No SQL Server, o CSV desejado deverá ser especificado durante a instalação. Estamos ainda no CTP1 do SQL Server 2014, e pelo menos na minha instalação tive alguns comportamentos estranhos, que também podem ser questões de permissões no Windows.

Seguem alguns pontos a estudar:

  • Adicionando outro CSV ao cluster, não consigo adicionar ao SQL Server.
  • Pela GUI do SQL Server (SSMS), não consigo navegar até a root do CSV. 
  • Consigo criar BDs no CSV, porém, tenho que inserir a path manualmente (nada de seleccionar com a interface). Outra opção é por script.
  • Ainda não fiquei esclarecido se um CSV pode ou não ser utilizado por mais do que uma instância, já que o mesmo não depende de uma role.
  • Seria possível escolher outro disco senão o C: para servir de base?

Como disse, esta é a CTP1 e é óbvio que isso tudo será resolvido. Irei continuar sobre o assunto de forma a esclarecer estes pontos e testar os limites do CSV no SQL Server.

Espero que o post seja interessante, e se você já tem alguma experiência sobre o assunto, a comunidade agradece o seu comentário neste post.

Até a próxima (no PASS Summit 2013!!!)