Considerações sobre instalações de SQL Server em cluster

Após a série de 4 artigos sobre como instalar uma instância em cluster, venho passar algumas considerações básicas sobre o ambiente em que o SQL Server será instalado:

Rede
Considere sempre utilizar, pelo menos, duas redes distintas. Uma para ligar a aplicação com o SQL Server e outra para a gestão da instância. Uma terceira rede poderia ser adicionada para transferencia de ficheiros de backup.
Ah, isso sem contar a rede de storage…

A regra básica é: Dividir ao máximo!

Discos
A mesma regra serve para os discos, tente distribuir os discos por “funções”, tendo o maior número possível de discos isolados. Considere ter um disco dedicado para dados (mdf e ndf), ficheiros de t-log (ldf) e para a TempDB e, talvez, um disco exclusivo para se criar ficheiros para alojar exclusivamente non-clustered indexes – Isso diminuirá a pressão dos ficheiros de dados assim como a sua fragmentação.

Sobre a TempDB, todo o cuidado é pouco…
Em alguns casos, é interessante ter um disco para os ficheiro de T-Log da TempDB separado dos ficheiros de dados. Aliás, falando em ficheiros de dados da TempDB, tenha em atenção o número de ficheiros a se adicionar…Não deixe a configuração default, mas também não exagere na quantidade de ficheiros.
Em casos de cluster, especificamente paraversões de SQL Server 2012+, considere a utilização de um disco local rápido, como um Fusion-IO ou algo com um bom rácico preço/performance.

Atenção as dependências
Tenha muito cuidado ao gerir as dependência de um cluster. Uma dependência mal feita pode custar caro. Um exemplo: Ao se associar os discos ao SQL Server na instalação, estamos automaticamente criando uma dependência no SQL Server Engine. Ou seja, o SQL Server Engine depende dos discos para ficar online, se um disco ficar offline por qualquer motivo, o SQL Server Engine ira ficar offline também. Na mesma onda, o SQL Server Agent depende do SQL Server Engine e, também, ficará offline.

Onde eu quero chegar aqui? A dependência dos discos é importante? Sim, mas por exemplo, um disco de backup não precisa ser uma dependência do SQL Server. Assim como a rede de backups ou a rede de gestão não precisam ser uma dependência do Hostname Virtual do SQL Server.

Configurações gerais
Não se esqueça de definir a memória mínima e máxima e de definir planos de backup, manutenção de índices e estatísticas de uma forma apropriada.

Tenha em conta que um plano de disaster recovery poderá ser necessário, e dependendo da tecnologia utilizada, o servidor de DR pode trazer mais vantagens… Ou seja, não será apenas um servidor de standby, consumindo recursos a espera de um eventual desastre.

Falando em DR, aproveito para lembrar que no SQL Saturday, em Abril, teremos um workshop muito bom de um amigo meu, chamado Edwin Sarmiento, que virá para Portugal especialmente para este evento. O preço do Workshop é de apenas € 100 e ainda é oferecido o curso completo com videos, disponível em https://www.udemy.com/sqlserverhadrdeepdive/. O preço deste Deep Dive, é de $315.

Ou seja, por € 100 você terá a formação directamente com o Edwin e ainda leva o curso para rever os pontos chave.

Ficam aqui os detalhes do workshop. Eu estarei lá!!!

High Availability & Disaster Recovery Deep Dive

High Availability and Disaster Recovery (HA/DR) is an area that every SQL Server DBA needs to be comfortable with. In this full-day workshop, learn what needs to be considered when embarking on a HA/DR project, the different features and technologies available in SQL Server, and implement them accordingly to meet service level agreements of mission-critical databases.

You will learn:
§  What requirements need to be met when implementing an HA/DR project
§  How to identify different SQL Server features and technologies – backup, recovery, database mirroring, log shipping, clustering, AlwaysOn – that can be used in addressing HA/DR requirements
§  How to implement the appropriate technology to meet HA/DR service level agreements

A group discount (20%) for every 5 registrations is available, so if you want to bring along your whole team – contact us to know the details! 

Link para inscrição: https://www.eventbrite.pt/e/bilhetes-high-availability-disaster-recovery-deep-dive-by-edwin-sarmiento-9168803137 

Até a próxima!!!

Passo-a-Passo: Instalação de uma instância SQL Server 2012 em cluster – Parte 4

Chegamos a última parte desta série de artigos. Para fechar com chave de ouro, vamos falar sobre Distributed Transaction Coordinator, ou simplesmente DTC. Vou tentar passar uma explicação simples e, em seguida, demonstrar como se preparar o DTC para uma instância em Cluster.

O que é o MS DTC?
O MS DTC é um serviço do SO, que vem instalado automaticamente e corre sob a conta de serviço “Network Service”. A sua função é assegurar que as transacções distribuídas são consistentes, mesmo que haja uma falha.

Estas transacções distrinbuidas, podem ser inicializaras quando uma transacção está lidando com múltiplos computadores via rede OU quando a transacção esta lidando com múltiplos processos no mesmo computador.

Todos os participantes desta transacção distribuída trabalham em sincroniza com os outros participantes (computadores) envolvidos a transacção, sempre a espera de efectuar um commit ou abortar o trabalho. Por esta razão, temos que garantir que todos os intervenientes podem se comunicar pela rede.

Preciso configurar o MS DTC no meu ambiente?
A resposta a esta questão, é a padrão para o SQL Server: Depende.
Você precisa entender se o sistema em questão irá ou não lidar com transacções distribuídas.
Se você tem mais do que uma instância no mesmo computador, você não irá precisar do DTC. De outra forma, se você tiver um cluster de dois nós com instâncias correndo em nós diferentes e comunicando entre si, o MS DTC será utilizado.

Outra possibilidade, é você ter o SSIS instalado, além da componente de engine. Neste caso, o MS DTC poderá ser necessário também.

Para mais informação, verifique este link:  http://msdn.microsoft.com/en-us/library/ms189910#MSDTC

Como confirgurar o MS DTC em cluster?
Desde o Windows Server 2008, a instalação de mais do que uma instância do MS DTC é permitida em um servidor/cluster. Então para uma instância de SQL Server em cluster, é uma boa pratica ter uma Role exclusiva para o MS DTC e uma dedicada para cada Role contendo o SQL Server.

Como documentado pela Microsoft, o SQL Sevrer segue o seguinte caminho para escolher o MS DTC a ser utilizado:

  • Utiliza o MS DTC instalado no grupo local, senão
    • Utiliza a instância mapeada do MS DTC, senão
      • Utiliza a instância MS DTC padrão do cluster, senão
        • Utiliza o MS DTC local da máquina aonde o serviço esta a correr.

Para configurar o MS DTC em cluster, precisamos de um disco (que não precisa ser exclusivo) e um hostname.

Para configurar um role exclusiva para o MS DTC, siga os passos:

  1. Clique com o botão direito sobre Roles e escolha a opção “Configure Role”.

    Screen Shot 2014-01-02 at 14.18.43

  2. Uma nova janela irá abrir. Clique em “next”.

    Screen Shot 2014-01-02 at 14.18.52

  3. Escolha a opção “Distributed Transaction Coordinator (DTC)”. Clique em  “Next”.

    Screen Shot 2014-01-02 at 14.19.11

  4. Preencha o hostname no campo “Name” e o IP na coluna “Networks. Clique em “Next”.

    Screen Shot 2014-01-02 at 14.20.33

  5. Escolha o disco a ser utilizado. Clique em “Next”.

    Screen Shot 2014-01-02 at 15.14.42

  6. Reveja as configurações e clique em “Next”.

    Screen Shot 2014-01-02 at 15.14.57

  7. A instalação irá correr, e no fim será apresentado um relatório. Clique em “Finish”.

    Screen Shot 2014-01-02 at 15.15.11

  8. Agora você poderá ver uma nova Role criada, com os recursos seleccionados e o serviço do MS DTC.

Para adicionar um instância do MS DTC na Role do SQL Server, siga os passos:

  1. Clique com o botão direito na Rola do SQL Server, clique em: “Add Resource”->”More Resources” -> “Distributed Transaction Coordinator” (como na imagem).

    Screen Shot 2014-01-02 at 15.30.50

  2. O recurso será criado na Role, agora será necessário configura-lo. Clique com o botão direito sobre “New Distributed Transaction Coordinator” e clique em “Properties”.

    Screen Shot 2014-01-02 at 15.31.20

  3. Conforme referido anteriormente, o DTC precisa de um hostname e um disco. Nas dependências, seleccione estes dois recursos e clique em OK.

    Screen Shot 2014-01-02 at 15.32.44

  4. Agora vamos iniciar o recurso.

    Screen Shot 2014-01-02 at 15.32.55

Como preparar a rede para transacções distribuídas?
Nota: Em ambientes de cluster, você deverá efectuar estes passos apenas uma vez.

  1. Em “Server Manager” clique em “Tools”->”Component Services” ou simplesmente execute o comando “dcomcnfg”.

    Screen Shot 2014-01-02 at 15.33.55

  2. Expanda a árvore, clique com o botão direito na instância de MS DTC desejada e escolha a opção “Properties”.

    Screen Shot 2014-01-03 at 11.46.28

  3. Na tab “Security” seleccione “Network DTC Acess” assim como “Allow Inbound” e “Allow Outbound”, como mostrado na imagem. Clique em OK.

    Screen Shot 2014-01-03 at 11.49.02

  • Descrevendo, por alto cada uma das opções…
    • Network DTC Access“: Activa/Desactiva o acesso a rede.
    • Allow inbound“:  Permite a execução de uma transacção distribuída, iniciada em outra máquina, na máquina na qual esta opção esta activa.
    • Allow outbound“:  Permite que uma transacção distribuída iniciada localmente seja executada em uma outra máquina.
    • Enable XA transactions” e “Enable SNA LU 6.2 Transactions“: Activa/Desactiva estas especificações particulares de transações distribuídas.

Resolvendo problemas com o MS DTC
Existe uma tool chamada DTC Ping que pode nos ajudar a verificar se o DTC está funcionando correctamente em todos os computadores que deverão estar envolvidos em uma transacção.

Siga este link para efectuar o Download: http://www.microsoft.com/en-us/download/details.aspx?id=2868

Recomendo a leitura do seguinte artigo, para aprender como utilizar esta tool, assim como resolver possíveis error: Troubleshooting MSDTC issues with the DTCPing tool.

Outra optima tool é a DTC Tester. Aonde podemos simular transacções distribuídas utilizando o SQL Server:

Screen Shot 2014-01-03 at 14.15.25
Para fazer download siga este link: http://support.microsoft.com/kb/293799 .

Fim
Chegamos ao fim desta série. Existem muitas coisas para se falar sobre best practices e configurações particulares do SQL Server. Certamente iremos abordar estes assuntos nos próximos posts!

Obrigado pela leitura!!

    Passo-a-Passo: Instalação de uma instância SQL Server 2012 em cluster – Parte 3

    Em continuação da série, iremos hoje entender como se adicionar um nó a uma instalação já feita, sendo esta uma instância em um nó ou mais.

    Para seguir com is passos seguintes, é obrigatório ter pelo menos um nó instalado. Caso queira começar a instalação do zero, leia a parte 2 desta série.

    Continuando… Conecte no nó em que a instalação será feita, no nosso caso W2012SRV04, e siga os seguintes passos:

    1. Com os mesmo binários utilizados na instalação anterior, clique em Setup.exe.

      Screen Shot 2013-12-09 at 12.38.54

    2. O “SQL Server Installation Center” Abrirá.

      Screen Shot 2013-12-09 at 12.39.28

    3. Ainda no “SQL Server Installation Center”, clique em “Installation” e selecione “Add node to a SQL Server failover cluster”.

      Screen Shot 2013-12-09 at 22.38.41

    4. Aguarde a verificação, e clique em “OK”.

      Screen Shot 2013-12-18 at 14.46.07

    5. O setup irá buscar por actualizações. Mantenha a opção “Include SQL Server product updates” marcada e clique em “Next”.

      Screen Shot 2013-12-09 at 22.39.51

    6. Outra verificação irá correr para identificar possíveis problemas. Clique em “Next”.

      Screen Shot 2013-12-09 at 22.42.01

    7. Indique a chave e clique em “Next”.

      Screen Shot 2013-12-09 at 22.42.17

    8. Aceite os termos e clique em “Next”.

      Screen Shot 2013-12-09 at 22.42.28

    9. Agora confirme as definições de IP, assim como você fez no primeiro nó. Clique em “Next”.

      Screen Shot 2013-12-09 at 22.45.02

    10. Indique as passwords para as contas de serviço do Engine e do Agent. Clique em “Next”.

      Screen Shot 2013-12-09 at 22.45.36

    11. Como no nó anterior, você tem a opção de enviar relatórios de erro para a Microsoft. Clique em “Next”.

      Screen Shot 2013-12-09 at 22.46.14

    12. Agora o setup irá verificar se o processo de instalação irá ser bloqueado durante a instalação. Clique em “Next” no fim desta verificação.

      Screen Shot 2013-12-09 at 22.46.26

    13. Reveja as opções escolhidas e clique em “Install”.

      Screen Shot 2013-12-09 at 22.46.47

    14. Agora tenha paciencia… A instalação está a ser feita :) Clique em “Next” quando estiver completa.

      Screen Shot 2013-12-09 at 22.47.00

    15. Sucesso! O nó agora faz parte da instância!! Verifique se todas as features foram instaladas correctamente. Clique em “Close”.

      Screen Shot 2013-12-09 at 22.56.08

    No fim desta instalação, você terá mais um nó disponível para correr a sua instância. Isso significa que podemos fazer failover do nó  W2012SRV03 para o nó W2012SRV04. Agora temos uma solução de high availability montada, que nós ajudará a recuperar em caso de falha de hardware.

    Por algum outro motivo, como em uma manutenção, você pode querer efectuar um failover manualmente. Para fazer isso abra o  Failover Cluster Manager (o mesmo utilizado no artigo anterior), clique com o botão direito sobre a Role do SQL Server (no nosso caso “SQL Server (DB)”) ae escolha a opção “Move”. Duas opção estarão disponíveis – “Best Possible Node” e “Select Node…”

    Ambas são válidas, mas a segunda te da a oportunidade de escolha o nó para o qual iremos mover a Role. O que é útil no caso de termos mais do que dois nós disponíveis.

    Screen Shot 2013-12-18 at 16.38.27
    É isso por hoje! Estarei de volta em breve com a última parte desta série, falando sobre MS DTC em instância em cluster.

    Até a próxima!!

    Passo-a-Passo: Instalação de uma instância SQL Server 2012 em cluster – Parte 2

    Em continuação do nosso guia de instalação de uma instância de SQL Server 2012 em cluster, vamos agora começar a por as mãos na massa… Começando pelo primeiro nó!

    O objectivo deste segundo artigo é mostrar como instalar o primeiro nó de uma instância de SQL Server 2012 e como gerir a mesma de uma forma básica, utilizando a ferramenta Failover Cluster Manager.

    Para refrescar a nossa memória, esse á a nossa infra-estrutura:

    Screen Shot 2013-12-12 at 12.03.53

    Para mais detalhes sobre os pré-requisitos e uma explicação geral, de uma olhada na primeira parte desta série de artigos.

    A instalação:  Começando pelo primeiro nó

    Vamos lá! Se você ainda se recordar, nós temos dois passos a cumprir. Para já, iremos instalar uma nova instância em um dos nós, o que ira gerar uma nova “Role” no nosso WFC. Iremos trabalhar no nó W2012SRV03.

    Seguem os passos:

    1. Com a media do SQL Server disponível, clique em “Setup”, como na image abaixo:Screen Shot 2013-12-09 at 12.38.54
    2. O “SQL Server Installation Center” irá abrir. Clique em “Installation” no menu a esquerda e, de seguida, em “New SQL Server Failover Cluster Installation”:
      Screen Shot 2013-12-09 at 12.39.28
    3. O instalador irá varrer o sistema em busca de algum possível constrangimento que impossibilite a instalação. No fim, clique em Ok.
      Screen Shot 2013-12-09 at 16.22.39
    4. Neste passo novas actualizações serão buscadas. Recomendo que estas sejam incluídas na instalação. Clique em “Next”.
      Screen Shot 2013-12-09 at 16.23.21
    5. Agora os ficheiros de supporte ao setup serão extraídos e instalados. Clique em “Install”.
      Screen Shot 2013-12-09 at 16.25.48
    6. Finalmente temos o setup pronto. Agora mais um check será executado para validar problemas com a instalação do SQL Server. Clique em “Next”.
      Screen Shot 2013-12-09 at 16.26.54
      Boa prática:
      Recomenda-se que exista um recurso MS DTC em cluster, assim como um recurso MS DTC dedicado a cada grupo do SQL Server.
      Segue um bom artigo sobre este tema: http://blogs.msdn.com/b/cindygross/archive/2009/02/22/how-to-configure-dtc-for-sql-server-in-a-windows-2008-cluster.aspx

    7. Neste passo, mencione a chave do SQL Server e clique em “Next”.
      Screen Shot 2013-12-09 at 16.29.32
    8. Selecione a check box ao lado de “I accept the license terms” e clique em “Next”.
      Screen Shot 2013-12-09 at 16.30.08
    9. Para instalar uma instância de SQL Server, escolha a opção “SQL Server Feature Installation”. Clique em “Next”.
      Screen Shot 2013-12-09 at 16.31.27
    10. Aqui nós temos algumas opções para instalar features, divididas em dois grupos:  “Instance Features” e “Shared Features”.
      Em “Instance Features” escolha “Database Engine Services”.
      Em “Shared Features” escolha “Management Studio (complete)”. mais um ponto importante aqui é o disco/directoria que as “Shared tools” serão instalados. Uma boa prática é ter um disco local dedicado a estes binários do SQL Server. Neste caso, estarei utilizando o disco de sistema,  pois este é o meu laboratório, mas isso não é uma boa prática para ambientes produtivos! Clique em “Next”.Screen Shot 2013-12-09 at 16.38.20
    11. Neste passo, mais um check tentará identificar possíveis problemas na instalação das features seleccionadas. Aguarde o fim e clique em “Next”.
      Screen Shot 2013-12-09 at 16.39.02
    12. Este é um passo importante. Aqui será definido o Network Name da instância (um dos requisitos ditos no artigo anterior), assim como se iremos utilizar uma instância nomeada ou não e a directoria raiz da instância.
      Pontos a se considerar aqui:
      – Como vemos em “Detected SQL Server instances and Features on this computer” eu já tenho uma outra instância instalada. Então tenho que instalar uma instância nomeada e alterar o Instance ID para evitar conflitos.
      – Baseado na informação acima, para conectar na instância teremos que indicar o seguinte: SQL04DB.
      –  Outro ponto importante aqui é o “Instance root directory”: Como já disse anteriormente recomendo o uso de um disco dedicado aos binários do SQL Server. Evite utilizar o disco de sistema para este fim.
      Preencha todos os pontos e clique em “Next”.
      Screen Shot 2013-12-09 at 16.46.40
    13. Neste passo temos apenas uma verificação de que os nossos requisitos de espaço em disco estão ok. Clique em “Next”.
      Screen Shot 2013-12-09 at 16.47.02
    14. Agora devemos escolhe o nome do Cluster Resource Group a ser criado. O instalador sugere um nome, porém podemos altera-lo.
      Também podemos ver os nomes reservados e já utilizados. Escolha o seu nome preferido e clique em “Next”.Screen Shot 2013-12-09 at 16.47.37
    15. Agora os discos! Mais um dos requisitos… neste ponto nós teremos a informação de todos os discos que fazem parte do cluster, assim como os que estão disponíveis ou não. Para esta demo, criei apenas uma LUN, por conta disso tenho apenas um disco no meu cluster (meu Quorum é uma fileshare :). Seleccione o(s) disco(s) necessários e clique em “Next”.Screen Shot 2013-12-09 at 16.50.23
    16. Você se lembra de que mais um dos requisitos era um IP? Pois é.. chegou a hora de utiliza-lo!! Seleccione a rede desejada (que o IP faz parte), desmarque a opção DHCP e preencha o IP na coluna “Address”.
      E … “Next”!
      Screen Shot 2013-12-09 at 16.56.12
    17. Segue aqui o nosso último requisito: Contas de Serviço. Preencha a informação sobre as contas do SQL Server Engine e Agent (login e password).
      Nota: Para uma instância em cluster, o “Startup Type” deverá ser “Manual”. O Cluster Service irá ser o ponto de gestão dos serviços.
      Clique em “Next”.
      Screen Shot 2013-12-09 at 17.03.20
    18. No mesmo passo, Temos outra tab onde podemos definir a collation do nosso engine. Por padrão temos “Latin1_General_CI_AS”.
      Para mais info sobre collations clique aqui. Esta é uma escolha importante que, se for mal definida, irá gerar uma grande dor de cabeça para ser alterada após a instalação.Screen Shot 2013-12-09 at 17.05.59
    19. Agora precisamos definir o modo de autenticação da nossa instância.
      As opções são “Windows Authentication”, que tirará benefício dos logins da AD e do Windows  , outra opção é “Mixed Mode”, que além dos benefícios da anterior adiciona logins geridos pelo SQL Server (menos seguros). Se você escolher “Mixed Mode” um login chamado “sa”, membro da fixed server role “Sysadmin” será activado. Por esta razão você terá que definir uma password para este login. na caixa abaixo, devemos definir todos os logins (AD e Windows) que terão acesso como Sysadmin a instância.Screen Shot 2013-12-09 at 17.10.25
    20. Agora é hora de definir a estratégia dos nosso discos.
      Este é um passo que merece um artigo por si só…. Estou utilizando apenas um disco neste guia, mas a recomendação é utilizar um disco para casa ponto.
      A regra geral é: Quanto mais espalhado melhor.
      Podemos user o seguinte layout:
      Screen Shot 2013-12-16 at 17.02.52

      Deste layout, o unico que não podemos definir de raiz é o disco para guardar os non-clustered indexes (mais um tema para artigo aqui).
      Pontos chaves deste assunto:

      • isolar a TempDB em um disco rápido. Lembre-se: Apartir do SQL Servr 2012 podemso alocar nossa TempDB em um disco local para instalações em cluster!
      • Coloque os ficheiros de dados e de logs em discos separados.
      • Peça para a equipa de storage discos com o nível de RAID apropriado.
      • Atenção ao offset das partições e tamanho dos blocos, mesmo em instalações superiores a Windows 2008.

      Após considerar todos estes pontos, preencha os campos e clique em “Next”.
      Screen Shot 2013-12-09 at 17.10.25

    21. Aqui você irá definir se enviará os erros para a Microsoft ou não, para melhorias no produto. Clique em “Next”.Screen Shot 2013-12-09 at 17.11.40
    22. Neste passo, será verificado se a instalação poderá ser bloqueada. Após os check, clique em “Next”.Screen Shot 2013-12-09 at 17.12.21
    23. Reveja as opções escolhidas, se estiver de acordo clique em  “Install”.
      Screen Shot 2013-12-09 at 17.12.32
    24. Aguarde pela instalação.
      Screen Shot 2013-12-09 at 17.13.21
    25. Nesta janela teremos a confirmação se as features foram instaladas correctamente ou não.
      Screen Shot 2013-12-09 at 17.20.21

    Nesta segunda parte, nós passamos por todos os passos para instalar o primeiro nó de uma instância em Cluster. Obviamente no seu ambiente existirão pequenas diferenças, mas passamos por todos os passos necessários para a instalação do primeiro nó.

    O próximo passo agora será a adição dos outros nós a esta instância já criada no WFC.

    Para gerir uma instancia em cluster, devemos utilizar a ferramenta Failover Cluster Manaeger.

    Utilizando o Failover Cluster Manager
    Como já temos um nó da nossa instância em cluster instalado, precisamos agora de gerir seus recursos e o Failover Cluster Manager é a ferramenta que suporta estas acções.

    Siga os seguintes passos para abrir o FCM:

    • Clique em “Windows Key”+R.
    • Escreva “cluadmin.msc” e clique em “Ok”.
    • O Windows Failover Cluster será aberto.

    Screen Shot 2013-12-17 at 12.39.52

    Na imagem acima, podemos ver duas “Roles”, representando duas instâncias em cluster. A Role com nome de “SQL Server (DB)” é a que nós acabamos de instalar.

    Seleccione esta Role para ver seus recursos (resources), como IPs, Discos, Serviçoes, etc..

    Neste ponto, temos a instância em cluster instalada em um nó apenas, então não temos a opção de fazer um failover para outro nó!

    Para parar o serviço do SQL Server, o que irá parar o serviço do Agente que é seu dependente, clique com o botão esquerdo sobre o serviço do SQL Server Engine e siga o demonstrado na imagem:

    Screen Shot 2013-12-17 at 12.49.06

    Para iniciar a instância, faça o mesmo, mas escolha a seguinte opção:
    Screen Shot 2013-12-17 at 12.51.49
    Nota: Quando o SQL Server é iniciado, o serviço de Agente deve ser iniciado manualmente. Para reduzir os passos necessários, o mais fácil é iniciar o serviço do SQL Server pelo Agent. Mas porque isso? Como o SQL Server Agent depende do Engine para funcionar, se enviarmos o comando para o Agent ser iniciado, o WFC irá levantar a sua dependência, no caso o SQL Server Engine. Assim em um passo levantamos dois serviços.

    Outra questão muito importante são as dependências do SQL Server.

    Para verificar as dependencias:

    • Clique com o botão esquerdo no serviço do SQL Server Engine.
    • Clique em Properties.
    • Seleccione a tab “Dependencies”.
    Screen Shot 2013-12-17 at 13.11.50
    Desta forma podemos ver todos os recursos dos quais o SQL Server engine é dependente. Olhando para imagem, verificamos que se ambos “Cluster Disk 1″ ou “SQL Server network name (SQL04)” falharem, a nossa instância irá efectuar um failover ou parar!!

    Todos os recursos de cluster podem ter dependências baseadas em outros recursos. Por exemplo, “SQL Server network name (SQL04)” é dependente do IP. Se o IP falhar, o “SQL Server network name (SQL04)” irá ficar offline. Por sua Vez o SQL Server é dependente do “SQL Server network name (SQL04)”… Assim no final desta cadeia de dependências, o SQL Server irá parar porque o recurso de IP falhou.

    O que tirar daqui?
    Verifique as dependências e condições, pois uma configuração apropriada poderá aumentar a taxa de disponibilidade da instância.


    Um exemplo prático:
    Discos de backup são importantes, mas não vitais para o serviço do SQL Server. Porém, se o SQL Server depender do disco de backup e este falhar, o SQL Server irá parar. Isso não faz sentido.
    Tirando a dependência do disco de backup, os backups podem falhar, mas o serviço continuará online. Desta forma podemos corrigir o problema do disco sem efeitos colaterais para o cliente final.

    Então, de atenção a estas opções!

    Próximos passos?
    Ao completar este segundo passo, nós já temos uma instância em cluster a funcionar em um nó… Precisamos completar isso!

    Irei postar mais duas partes:

    • Adicionar outro nó a uma instalação de uma WFCI
    • Configuração de um MS DTC dedicado a Role do SQL Server.

    Se você perdeu o primeiro artigo da série, fica o link:
    Passo-a-Passo: Instalação de uma instância SQL Server 2012 em cluster – Parte 1

    Até a próxima!

    Passo-a-Passo: Instalação de uma instância SQL Server 2012 em cluster – Parte 1

    Introdução
    Neste artigo irei mostrar como é feita a instalação de uma instância de SQL Server 2012 em cluster. No nosso caso iremos utilizar um cluster com dois nós.

    No geral, a instalação e divide em duas partes distintas:

    1. Instalação de uma nova instância em cluster.
    2. Adição dos outros nós a instância já instalada (no ponto 1).

    Para um cluster com mais do que dois nós, o segundo ponto será executado em todos os nós, excepto o que foi utilizado para a execução do ponto 1.

    O que é uma inst|ancia em cluster?
    Basicamente, uma instância em cluster é uma instalação do SQL Server engine e agent baseada no serviço de Windows Failover Cluster (WFC). O motivo principal de um serviço de WFC é proteger nosso sistema de falhas de hardware.

    Em um cenário de um cluster com dois nós, estamos a falar de dois servidores, como configurações de hardware similares, ligados por um serviço de WFC. Tendo uma instância de SQL Server instalada sobre esta solução, podemos chamar esta instância de Clustered Instance, ou Instância em Cluster.
    Esta instância em cluster, poderá estar activa em apenas um nó, ficando os outros nós IDLE, a espera de um possível failover.

    Outro ponto importante é o facto de que o WFC aceita storage partilhado, tipicamente SAN, para guardar os ficheiros das bases de dados. Porém, os binários gerados pela instalação do SQL Server deverão ficar em um disco local, pertencente ao nó em questão.

    Além da SAN, podemos também utilizar SMB Fileshares para uma instalação em cluster. Clique aqui para mais informações.

    Também apartar do SQL Server 2012, podemos alocar a nossa TempDB em um disco local, o nos garante alguns benefícios.

    Baseado nas informações dadas, conseguimos perceber que o WFC é uma solução e alta disponibilidade (HA), e isso não inclui balanceamento de carga (LB) ou recuperação de desastres (DR). Para atingirmos um nível em que as três solução estarão em conjunto, o AlwaysON é uma excelente solução.

    Pressuposto
    Estarei assumindo que neste ponto nós já temos um cluster montado, com dois ou mais nós.
    Normalmente os DBAs recebem o ambiente pronto, criado pelos administradores de sistema. De qualquer forma, após esta série, irei escrever um ártigo de como se criar um cluster de dois nós do zero. Fique ligado!!

    Pré-Requisitos
    Antes de começarmos, temos que ter os seguintes pontos garantidos:

    • Um hostname virtual. No nosso exemplo usaremos: “SQL04″.
    • Um IP virtual, a.k.a vIP. No nosso exemplo usaremos: 192.168.123.124.
    • Shared Storage disponível. A boa prática é ter, pelo menos, um disco dedicado aos ficheiros de dados, outro para logs e uma para a TempDB. Essa seria uma configuração mínima aceitável para produção. No nosso exemplo irei utilizar um disco para tudo, mas isso é um péssima ideia.
    • Contas de Serviço: 
      • Uma para o SQL Server Engine outra para SQL Server Agent (boa prática). 
      • Usaremos as seguintes contas: SSLABSVCSQLSRVENG e SSLABSVCSQLAGT.
      • Atenção: as contas de serviço são contas de domínio. Não existe outra hipótese, nosso cluster deverá fazer parte de um domínio!

    Nosso Ambiente
    Neste guia, iremos utilizar o seguinte ambiente, baseado em máquinas virtuais:

    • Dois nós com Windows Server 2012 R2:
      • W2012SRV03 – 192.168.123.205
      • W2012SRV04 – 192.168.123.206
    • Ambos os nós irão fazer parte do seguinte cluster:
      • W2012CLT02 – 192.168.123.111
    • Storage:
      • Como estou utilizando um ambiente de laboratório, A minha SAN é uma Synology Diskstation. Apenas para informação, o IP da SAN é: 192.168.123.103.
    • Para o SQL Server:
      • Virtual Hostname – SQL04
      • vIP – 192.168.123.124
      • Versão do SQL Server: Microsoft SQL Server 2012 (SP1) – 11.0.3128.0 (X64)  -  Enterprise Edition


    Permissões para o login utilizado durante a instalação
    Para instalar o SQL Server, estarei utilizando um login pertencente ao domínio, SSLABDBA.
    Este login tem permissões administrativas em anos os nós do cluster (W2012SRV03 e W2012SRV04). 
    o login “SSLABdba” é um simples utilizador do domínio e não tem nenhum privilégio especial no domínio SSLAB.

    Próximo post
    Fica já marcado para a próxima terça-feira a continuação deste artigo. Passaremos finalmente para o primeiro passo: “Instalação de uma nova instância em cluster”.

    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!!!)