Supondo que você precise garantir que seu aplicativo que depende do SQL Server 2012 como back-end do banco de dados esteja disponível o tempo todo, mesmo se um computador servidor falhar.

Como desenvolvedor e não DBA, estou tentando entender quando usar qual cenário para meu failover / alta disponibilidade:

• Dois (ou mais) servidores em um cluster de Failover do Windows, SQL Server como uma instância em cluster
• Duas (ou mais) instâncias do SQL Server mantidas atualizadas com replicação transacional
• Dois (ou mais) servidores SQL em um grupo de disponibilidade do SQL Server, configurado em um modo de confirmação síncrona

Qual de cada um desses cenários funciona para que tipo de carga de trabalho e que tipo de falha / interrupção pode ser tratado por esses cenários? Eles são comparáveis ​​/ trocáveis?

A maneira como eu sempre gosto de visualizar soluções de alta disponibilidade é a seguinte:

Instância de cluster de failover do SQL Server (FCI)

O que é altamente disponível? A instância inteira. Isso inclui todos os objetos do servidor (logins, trabalhos do SQL Server Agent, etc.). Isso também inclui bancos de dados e suas entidades que os contêm. É uma ótima solução para instâncias do SQL Server altamente disponíveis, porque esse será o nível de contenção dessa solução.

E os relatórios? Nenhum, NULL, inexistente. Uma instância de cluster de failover possui um nó ativo que entrega o grupo de clusters que contém a instância, VNN, etc. e todos os outros nós são passivos, ociosos (no que diz respeito ao grupo de clusters atual) e aguardando um failover.

O que acontece quando há failover? O tempo de inatividade para uma FCI será determinado pela quantidade de tempo que o nó passivo leva para capturar o recurso de cluster e colocar a instância do SQL Server em um estado de execução. Isso normalmente é mínimo no tempo.

Alguma abstração de cliente? Sim, isso será incorporado internamente com o nome da rede virtual para a instância do cluster de failover. Isso sempre apontará para o nó ativo que está atualmente entregando o recurso de cluster do SQL Server.

Grupos de disponibilidade AlwaysOn

O que é altamente disponível? Um grupo de disponibilidade será a contenção lógica de alta disponibilidade aqui, enquanto um grupo de disponibilidade consiste em vários bancos de dados e um nome de rede virtual (o ouvinte, um recurso de cluster opcional). Vale ressaltar que objetos do servidor, como logons e trabalhos do SQL Server Agent, não farão parte da solução de HA, e é necessário ter uma consideração especial para garantir que eles sejam implementados corretamente com um grupo de disponibilidade. Não é um requisito excessivamente pesado, mas precisa ser tratado.

E os relatórios? Essa é uma ótima solução para relatórios, embora eu provavelmente não usaria uma réplica síncrona como minha instância de relatórios. Existem dois relacionamentos de confirmação, síncrona e assíncrona. Na minha opinião e pelo que vi na prática, é que sua réplica secundária síncrona está lá esperando por um desastre. Pense nisso como a réplica que está pronta para executar um failover sem perda de dados no caso de um problema. Existem réplicas assíncronas que podem lidar com essa carga de trabalho de relatório. Você não está usando esta réplica como a solução acima mencionada, mas muito mais para coisas como relatórios. As cargas de trabalho de relatório podem ser apontadas para esta réplica (direta ou indiretamente por meio de roteamento somente leitura por meio do ouvinte).

O que acontece quando há failover? Para uma réplica secundária de confirmação síncrona emparelhada com failover automático, essa será a alteração do estado da função de réplica de SECONDARY_NORMAL para PRIMARY_NORMAL. Para que haja failover automático, é necessário ter uma réplica secundária síncrona sincronizada no momento, e o que está implementado é a Política de Failover Flexível para determinar quando, de fato, esse failover deve ocorrer. Essa política é realmente configurável.

Alguma abstração de cliente? Sim, opcionalmente, você pode configurar um ouvinte do AlwaysOn Availability Group. Isso é basicamente apenas um nome de rede virtual (pode ser visto no WSFC como um recurso de cluster no grupo de clusters do AG) que aponta para a réplica primária atual. Essa é uma parte essencial da alteração da carga de trabalho de relatórios, além de configurar uma lista de roteamento somente leitura em todos os servidores que você deseja redirecionar o tráfego ReadOnly (isso é definido através da cadeia de conexão, com o .NET Framework Provider for SQL Server, este será o parâmetro Application Intent , definido como ReadOnly ). Você também precisa definir um URL de roteamento somente leitura para cada réplica que deseja receber essa carga de trabalho de relatório enquanto estiver na função de réplica secundária.

Replicação Transacional

O que é altamente disponível? Isso é discutível, mas não vou dizer nada . Não vejo a replicação como uma solução de alta disponibilidade. Sim, as modificações de dados estão sendo enviadas aos assinantes, mas estamos falando no nível da publicação / artigo. Esse será um subconjunto dos dados (pode incluir todos os dados, mas isso não será imposto. Ou seja, você cria uma nova tabela no banco de dados do editor e não será automaticamente enviada aos assinantes). No que diz respeito à HA, este é o fundo do poço e eu não o agruparei lá com uma solução sólida de HA.

E os relatórios? Uma ótima solução para gerar relatórios sobre um subconjunto de dados, sem dúvida. Se você possui um banco de dados de 1 TB altamente transacional e deseja manter essa carga de trabalho de relatório fora do banco de dados OLTP, a replicação transacional é uma ótima maneira de enviar um subconjunto de dados a um assinante (ou assinantes) para a carga de trabalho de relatório. O que acontece se desses 1 TB de dados, sua carga de trabalho de relatórios for de apenas 50 GB? Esta é uma solução inteligente e relativamente configurável para atender às suas necessidades de negócios.

Sumário

O que se resume a isso são algumas perguntas que precisam ser respondidas (em parte pela empresa):

1. O que precisa estar altamente disponível ?
2. O que o SLA determina para HA / DR?
3. Que tipo de relatório ocorrerá e quais latências são aceitáveis?
4. Com o que precisamos lidar com HA geograficamente dispersa ? (a replicação de armazenamento é cara, mas é essencial para uma FCI. Os AGs não exigem armazenamento compartilhado de instâncias independentes e você pode usar uma testemunha de compartilhamento de arquivos para quorum, eliminando potencialmente a necessidade de armazenamento compartilhado)

dois (ou mais) servidores em um cluster de Failover do Windows, SQL Server como uma instância em cluster

1. Que tipo de carga de trabalho? "Depende" - mas, sério, isso é útil para um aplicativo on-line onde você precisa ter um local no data center de alta disponibilidade. Você está protegido contra falhas de uma máquina ou de um sistema operacional. Os logins, trabalhos, novos bancos de dados, manutenção etc. são automaticamente mantidos em sincronia pelo fato de ser um cluster com dois nós que são exatamente os mesmos compartilhando o mesmo armazenamento, para que tenham os mesmos bancos de dados do sistema. Failover muito rápido, mas ainda existe um soluço que parece uma reinicialização do SQL Server quando o failover ocorre.

2. Contras / preocupações - O único ponto de falha é o seu armazenamento e todos os seus componentes. Os fornecedores de SAN sempre dizem "SANs não falham", mas há muitas partes móveis em uma rede de área de armazenamento e, como eu escrevi aqui , elas podem. Além disso - você está pagando por um servidor secundário que não pode fazer nada além de esperar e agora. Agora você pode executar o Active / Active / Multi-Node e ter duas instâncias ativas que podem executar failover em qualquer direção e usar o segundo nó.

3. Failover automático? O "mais" automático. Nenhuma testemunha é necessária, é um cluster. Esse é o trabalho de um cluster, para torná-lo o mais transparente possível. Agora, com qualquer uma dessas opções, quando ocorrer um failover, você "sentirá" isso, porque o SQL precisa ser inicializado ou as conexões precisam apontar. Aqui, quando isso acontecer, você basicamente se sentirá como uma reinicialização do SQL, os DBs retornam e executam a recuperação / etc.

Se um cliente disser "Quero estar totalmente atualizado com todos os bancos de dados, logins etc." em um ambiente de Alta Disponibilidade no meu datacenter local, porque tenho uma tolerância incrivelmente baixa para o tempo de inatividade, consideraria Instâncias de Cluster de Failover (embora o A última opção mencionada é um forte candidato, exceto por ter que fazer algumas despesas gerais de gerenciamento). Eu provavelmente faria um FCI local e um AG assíncrono secundário para proteger contra falhas no site ou SAN.

duas (ou mais) instâncias do SQL Server atualizadas com replicação transacional

1. Que tipo de carga de trabalho? Sinceramente, eu não iria aqui em muitos casos de necessidade de alta disponibilidade ou recuperação de desastres como primeira opção. Não no SQL 2012, com certeza. Mas, basicamente, isso é bom se você tivesse que ir a um datacenter que não estivesse perto, não conseguiria usar um AG (talvez um problema de domínio o impedisse de usar o cluster do Windows necessário para o AG), talvez desejasse estar no padrão do SQL Server, que pode fazer replicação, mas não AGs, mas você ainda queria ter a capacidade de ler no lado secundário e ser assíncrono.
2. Contras / preocupações - É replicação. Possui sobrecarga, pode ficar fora de sincronia, você pode desenvolver problemas com o desempenho no lado da fonte etc.
3. Failover automático - Não. Você precisa gerenciar sozinho. Ou através dos CNAMEs que apontam para um ou outro, e você poderia teoricamente escrever seu próprio processo para fazer isso, mas fora da caixa? Observe aqui.

dois (ou mais) servidores SQL em um grupo de disponibilidade do SQL Server, configurado em um modo de confirmação síncrona

É isso que tenho ajudado as pessoas a implementar cada vez mais ultimamente, embora às vezes eu ainda vá para o agrupamento.

1. Que tipo de carga de trabalho? Isso é ótimo quando eu tenho um conjunto gerenciável de bancos de dados para manter a sincronização, e os recursos e tempo para garantir que tarefas, logins, novos bancos de dados etc. fiquem sincronizados (embora a equipe do SQL Skills tenha construído um ótimo complemento para automatize isso para você, tornando-o ainda mais forte). Eu gosto disso quando quero manter as coisas completamente separadas. Eu estou protegendo contra problemas de hardware, problemas do sistema operacional, problemas de instalação do SQL, problemas de patches e problemas de SAN / armazenamento. Também tenho o benefício da capacidade de ter um secundário (se eu quiser pagar uma licença corporativa por ele) ser um secundário ativo do qual posso ler, fazer backups etc. etc. Além disso, no futuro, posso adicionar um terceiro secundário assíncrono em um site remoto e com failover / DR.
2. Contras / preocupações Licenciamento, número máximo de réplicas, custos de licenciamento para tirar proveito de alguns dos maiores benefícios (secundário ativo), requer empresa, requer o dobro de armazenamento que o armazenamento em cluster.
3. Failover automático - Sim. Isso pode ocorrer com uma configuração de testemunha, e os desenvolvedores de aplicativos podem se conectar ao ouvinte em vez de um nó, para que o failover aconteça com o local em que o ouvinte aponta e você deve ser bom lá. Então, sim, você pode fazer isso aqui - e deve - mas é claro que deve testá-lo bem.

Sumário

HA e DR são diferentes. E essas tecnologias ajudam a fornecer partes de qualquer um. Alta disponibilidade significa (para mim) que você pode recuperar rapidamente se algo ruim acontecer a uma máquina, você terá um objetivo de ponto de recuperação e um objetivo de tempo de recuperação curtos. Isso é cluster e um AG síncrono.

Disaster Recovery é "você pode se levantar quando tem uma falha, mesmo em sua solução de HA. Para mim, isso pode ser AGs quando você vai para outro data center, espelhando ou mesmo replicando.

Também é importante considerar o que é compartilhado .

O clustering de failover usa dois ou mais nós do servidor que compartilham uma matriz de disco. Se a matriz de discos ficar inativa, você perderá o serviço, independentemente de quantos nós de servidor houver. Se a sala do servidor em que a matriz de discos estiver localizada pegar fogo ou inundar, você perderá o serviço.

Os Grupos de Disponibilidade AlwaysOn e o Espelhamento de Banco de Dados são uma tecnologia de cluster "nada compartilhado". O banco de dados está presente em várias matrizes de disco em vários servidores. Se você tiver bons links de rede, os vários serviços podem estar em várias salas de servidores, protegendo-o contra incêndios e inundações.

Apenas para completar, existe a opção de usar o espelhamento antigo simples. As vantagens aqui incluem ter duas cópias do banco de dados sem a complexidade do uso de Grupos de Disponibilidade e sem a necessidade de armazenamento compartilhado para o Failover Clustering. A desvantagem, embora leve, é que o espelhamento está obsoleto.

Os tempos de failover com espelhamento são da ordem de 10 segundos, embora o código do aplicativo precise tentar novamente todas as transações que estão ocorrendo no momento do failover.