A maneira que 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 de 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 com essa solução.

E a reportagem? Nenhum, NULL, inexistente. Uma instância de cluster de failover tem um nó ativo entregando 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 de 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 geralmente é mínimo no tempo.

Alguma abstração do cliente? Sim, isso será incorporado de forma inata com o nome da rede virtual para a instância de cluster de failover. Isso sempre apontará para o nó ativo que está 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 a pena observar que objetos de servidor, como logons e trabalhos do SQL Server Agent, não farão parte da solução de alta disponibilidade, e uma consideração especial precisa ser tomada para garantir que eles sejam implementados corretamente com um grupo de disponibilidade. Não é um requisito excessivamente pesado, mas precisa ser cuidado.

E a reportagem? 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ório. Existem dois relacionamentos de confirmação, síncrono e assíncrono. Na minha opinião e pelo que vi na prática, é que sua réplica secundária síncrona está aí esperando um desastre. Pense nisso como aquela réplica que está pronta para realizar um failover sem perda de dados no caso de um problema. Depois, há réplicas assíncronas que podem lidar com essa carga de trabalho de relatórios. Você não está usando esta réplica como a solução mencionada acima, mas mais ainda para coisas como relatórios. As cargas de trabalho de relatório podem ser apontadas para essa 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 da réplica de SECONDARY_NORMAL para PRIMARY_NORMAL. Para que haja failover automático, você precisa ter uma réplica secundária síncrona que esteja 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 do cliente? Sim, você pode configurar opcionalmente um ouvinte do Grupo de Disponibilidade AlwaysOn. Isso é basicamente apenas um nome de rede virtual (pode ser visto por meio do WSFC como um recurso de cluster no grupo de clusters do AG) que aponta para a réplica primária atual. Esta é uma parte fundamental para mudar sua carga de trabalho de relatórios, bem como configurar uma lista de roteamento somente leitura em todos os servidores que você deseja redirecionar o tráfego ReadOnly (isso é definido por meio 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 precisaria definir uma 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. Este será um subconjunto dos dados (pode incluir todos os dados, mas isso não será aplicado. Ou seja, você cria uma nova tabela no banco de dados do editor e isso não será enviado automaticamente aos assinantes). No que diz respeito ao HA, este é o fundo do barril e não o agruparei com uma solução de HA sólida.

E a reportagem? Uma ótima solução para relatar um subconjunto de dados, sem dúvida. Se você tem um banco de dados de 1 TB altamente transacional e deseja manter essa carga de trabalho de relatórios fora do banco de dados OLTP, a replicação transacional é uma ótima maneira de enviar um subconjunto de dados para um assinante (ou assinantes) para a carga de trabalho de relatórios. O que acontece se desse 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.

Resumo

O que se resume a um punhado de 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. O que precisamos lidar com HA geograficamente disperso ? (a replicação de armazenamento é cara, mas obrigatória com uma FCI. Os AGs não exigem armazenamento compartilhado de instâncias autônomas, 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 clusterizada

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

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

3. Failover automático? O "mais" automático. Não precisa de testemunha, é um aglomerado. Este é o trabalho de um cluster, para torná-lo o mais simples possível. Agora com qualquer um desses, quando acontece um failover você vai "sentir", porque o SQL tem que iniciar ou as conexões tem que apontar. Aqui, quando isso acontecer, você basicamente se sentirá como uma reinicialização do SQL, os bancos de dados voltarão e executarão a recuperação/etc.

Se eu tiver um cliente dizendo "Quero estar totalmente atualizado com todos os bancos de dados, todos os logins, etc" em um ambiente de alta disponibilidade em meu data center local porque tenho uma tolerância incrivelmente baixa para tempo de inatividade, consideraria Instâncias de cluster de failover (embora o última opção que você menciona é um forte concorrente, exceto por ter que fazer alguma sobrecarga de gerenciamento). Eu provavelmente faria um FCI local e um secundário assíncrono de AG para proteger contra falha de site ou falha de SAN.

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

1. Que tipo de carga de trabalho? Honestamente, eu não iria aqui para muitos casos de necessidade de Alta Disponibilidade ou Recuperação de Desastres como primeira escolha. Não no SQL 2012 com certeza. Mas basicamente isso é bom se você tivesse que ir a um data center que não estivesse próximo, não pudesse usar um AG (talvez um problema de domínio impedindo você de usar o cluster do Windows necessário para o AG), talvez você quisesse ser no padrão 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. Ele tem sobrecarga, pode ficar fora de sincronia, você pode desenvolver problemas com desempenho no lado da fonte, etc.
3. Failover Automático - Não. Você tem que gerenciá-lo sozinho. Ou através de CNAMEs que apontam para um ou outro, e teoricamente você poderia escrever seu próprio processo para fazer isso, mas fora da caixa? Observe aqui.

dois (ou mais) SQL Servers em um SQL Server Availability Group, configurados em um modo de confirmação síncrona

Isso é o que tenho ajudado as pessoas a implementar cada vez mais ultimamente, embora às vezes eu ainda vá para o clustering.

1. Que tipo de carga de trabalho? Isso é ótimo quando tenho um conjunto gerenciável de bancos de dados para manter sincronizado e os recursos e tempo para garantir que os trabalhos, logins, novos bancos de dados etc. automatize um pouco disso para você, tornando-o ainda mais forte como uma opção). Eu gosto disso quando quero manter as coisas completamente separadas. Estou protegendo contra problemas de hardware, problemas de sistema operacional, problemas de instalação de SQL, problemas de patch e problemas de SAN/armazenamento. Eu também recebo o benefício da capacidade de ter um secundário (se eu quiser pagar uma licença corporativa por ele) para ser um secundário ativo que eu possa ler, fazer backups etc. Além disso, no futuro, posso adicionar um terceiro secundário que é assíncrono em um site remoto e tem failover/DR.
2. Contras/Preocupações Licenciamento, número máximo de réplicas, custos de licenciamento para aproveitar alguns dos maiores benefícios (secundário ativo), requer empresa, requer duas vezes mais armazenamento do que clustering.
3. Failover Automático - Sim. Isso pode ocorrer com uma configuração de testemunha, e os desenvolvedores do seu aplicativo podem se conectar ao ouvinte em vez de a um nó para que o failover aconteça com onde o ouvinte aponta e você deve estar bem lá. Então, sim, você pode fazer isso aqui - e deve - mas é claro que você deve testá-lo bem.

Resumo

HA e DR são diferentes. E essas tecnologias ajudam a fornecer pedaços de ambos. Alta Disponibilidade significa (para mim) que você pode se recuperar rapidamente se algo ruim acontecer com uma máquina, você está com um Objetivo de Ponto de Recuperação e um Objetivo de Tempo de Recuperação curtos. Isso é clustering e um AG síncrono.

Recuperação de desastres é "você pode se levantar quando tiver uma falha, mesmo em sua solução de alta disponibilidade. Para mim, isso pode ser AGs quando você vai para outro data center, espelhamento ou até replicação.

Também é importante considerar o que é compartilhado .

O cluster de failover usa dois ou mais nós de servidor compartilhando uma matriz de disco. Se a matriz de disco ficar inativa, você perderá o serviço, independentemente de quantos nós de servidor existam. Se a sala do servidor onde está localizada a matriz de disco pegar fogo ou inundar, você perderá o serviço.

Grupos de Disponibilidade AlwaysOn e Espelhamento de Banco de Dados são uma tecnologia de cluster de "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 servidores podem estar em várias salas de servidores, protegendo você contra incêndios e inundações.

Apenas para completar, existe a opção de usar o espelhamento simples e antigo. As vantagens aqui incluem ter duas cópias do banco de dados sem a complexidade de usar grupos de disponibilidade e sem precisar de armazenamento compartilhado para cluster de failover. 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 ser capaz de tentar novamente quaisquer transações que estejam ocorrendo no momento do failover.