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):
- O que precisa estar altamente disponível ?
- O que o SLA determina para HA / DR?
- Que tipo de relatório ocorrerá e quais latências são aceitáveis?
- 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)
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.
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ó.
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.
É isso que tenho ajudado as pessoas a implementar cada vez mais ultimamente, embora às vezes eu ainda vá para o agrupamento.
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.
fonte
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.
fonte
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.
fonte