X

AlwaysOn FCI VS AlwaysOn AG – Relações: Custo X Benefício X Necessidade

5/5 - (3 votes)

 

O assunto começa prometendo ser extenso, interessante e com uma pitada de polêmica…

Prossigamos então com as definições: (Segundo Edvaldo Castro)

    WSFC
    Windows Server Failover Cluster: É o serviço do Windows Server que suporta e coordena os recursos de um Cluster de Failover, construído para prover disponibilidade para uma ou mais aplicações e/ou serviços.

 

    AlwaysOn FCI
    AlwaysOn Failover Cluster Instances: É o modo de instalação do SQL Server para que este possa fazer uso do WSFC e trabalhar com alta disponibilidade (HA), sendo capaz de estar “Ativo” em um nó do Cluster de Failover por vez em quaisquer nós que tenham sido previamente configurados para isto. Esta forma de alta disponibilidade do SQL Server já está presente desde as versões mais antigas, sendo aprimorado a cada nova versão, juntamente com o WSFC.

 

    AlwaysOn AG
    AlwaysOn Availability Groups: Feature nova no SQL Server lançada com a versão 2012 do produto, provê alta disponibilidade a nível de banco de dados, podendo agrupar um conjunto de bancos em uma mesma instância atribuir um nome virtual que será acessível pelas aplicações independente da réplica (cluster node) onde este grupo de disponibilidade estiver ativo. É a solução de Alta disponibilidade mais recente do SQL Server e está se tornando cada vez mais popular

Custo X Benefício

Para quaisquer ferramentas, features ou produtos que se deseja implementar, existem dois lados que são: Benefício(Prós) e Custo(Contras). Com as soluções de alta disponibilidade apresentadas para o SQL Server não é diferente, cada uma delas oferece um ou mais benefícios, mas também existe um “preço” a ser pago (não necessariamente, algo financeiro).
A seguir um pouco dos pontos de benefício e custo destas features (Segundo Edvaldo Castro).
 

WSFC

O WSFC é a base para as soluções de Alta Disponibilidade apresentadas neste artigo (AlwaysOn FCI e AlwaysOn AG).
Basicamente, o WSFC é um serviço do windows que pode “clusterizar” diversas aplicações provendo Alta Disponibilidade a nível de servidor (seja ele físico ou virtual). Enquanto o serviço clusterizado é executado um dos nós do cluster, um ou mais nós estarão em estado passivo, prontos para assumirem o serviço clusterizado no caso de uma falha no nó primário que force um failover entre estes nós.

 

AlwaysOn FCI

É a nomenclatura nova para uma instalação “clusterizada” do SQL Server, permitindo que um nó passivo assuma em caso de falha no nó ativo.
 

    Prós
  • Menor custo com relação a armazenamento, visto que os dados são entregues em discos compartilhados entre os nós do cluster.
  • Dependendo do contrato e tipo de licenciamento, pode ser mais barato, pois não há necessidade (em alguns casos) de licenciamento do nó passivo.
  • Failover da instância como um todo (Logins, Jobs, Planos de Manutenção, Alertas, etc), não havendo a necessidade de controles externos dos itens correlacionados à instância.
  • O MSDTC (Microsoft Distributed Transaction Coordinator) é suportado, diferente do AG que não é suportado (Deverá ser suportado a partir da versão 2016)

 

    Contras
  • Resiliência e confiabilidade no seu sistema de armazenamento, pois caso uma LUN falhe sem possibilidades de recuperação, o sistema ficará indisponível, e possivelmente sem possibilidade de recuperação dos dados contidos neste disco.
  • Sub utilização de servidores (dependendo do desenho do cluster), visto que o nó passivo fica “ocioso” esperando que ocorra uma falha no nó ativo.
  • Configuração e troubleshooting geralmente complexos
  • Failover mais lento que o AlwaysOn AG

 

AlwaysOn AG

 

    Prós
  • Disponibilidade de grupos de bancos de dados, com Listener (Nomes Virtuais) para estes grupos de bancos de dados
  • Réplicas Secundárias disponíveis para leitura, possibilitando direcionamento do workload de relatórios para as réplicas secundárias.
  • Possibilidade de execução dos Backups de Log de transações nas réplicas secundárias (e Backup Full com “COPY_ONLY”
  • Failover MUITO mais rapido, pois o único recurso do cluster que vai ser movido entre as réplicas são: Listener, IP e Recurso do AG.
  • Alta Disponibilidade e Recuperação de Desastre configurados juntos e de maneira simples, quando se aloca uma réplica em um site remoto.
    Contras
  • Espaço de armazenamento multiplicado pelo número de réplicas na solução de AG
  • Obrigatoriedade de licenciamento das réplicas secundárias, caso as mesmas sejam utilizadas para leitura*
  • Objetos inerentes à instância não são replicados e devem ser controlados externamente à solução de AG.
  • MSDTC (Microsoft Distributed Transaction Coordinator) não suportado (Até a versão 2014). Se o negócio utiliza transações distribuídas, o AlwaysOn AG passa a ser uma opção não muito viável.

 

Necessidade

 

Antes de decidir ou ser tendencioso na escolha de qual solução de Alta Disponibilidade utilizar para um ambiente, é necessário analisar criteriosamente qual a necessidade real e qual a solução melhor se adapta ao cenário.
É preciso levar-se em conta fatores financeiros, esforço administrativo, esforço para implantação, tempo, e o mais importante de tudo, se atende às demandas de disponibilidade do negócio. Neste ponto é preciso que haja eficácia e eficiência, para se tirar melhor proveito da solução escolhida para implantação.

 

Conclusão:

Independente se o demandante é um cliente externo de consultoria, ou um ambiente onde o profissional está administrando diariamente, é perigoso e pode custar caro não atentar-se aos itens que mais se adequam a este ambiente.
Muitas tecnologias e soluções novas são lançadas cada vez mais rápido, é humanamente impossível, desnecessário e às vezes até prejudicial, estar sempre atualizado com estas novas tecnologias.
Nos casos de Alta Disponibilidade de ambientes em SQL Server, por exemplo, o AlwaysOn Availability Groups, apesar de ser uma das novidades do SQL Server, e certamente a que pode fazer mais “barulho positivo” à imagem do profissional que teve a ideia, desenhou e implementou o projeto, não é a única solução e tampouco a melhor em todos os casos.
Avaliar meticulosamente cada cenário e traçar um mapeamento entre prós e contras, custos e benefícios dentre outros itens de avaliação, é com certeza a melhor abordagem e melhor forma de um profissional apresentar uma solução de Alta Disponibilidade que melhor se adeque ao ambiente, nos quesitos Custo x Benefício x Necessidade.

Obrigado pela leitura, e lembre-se: Nem tudo que é novidade é aplicável e melhor para todos.

Abraços,

Edvaldo Castro

 

Referências:

  1. Windows Server Failover Clustering (WSFC) with SQL Server
Edvaldo Castro:

View Comments (8)

  • Edvaldo, ótimo artigo, muito bem explanado.

    Um ponto pró que eu vejo no Always On FCI é que ele não é Enterprise Only como o Always On AG, ou seja, ele pode ser configurado na versão Standard e BI com limite de dois nós.

    Parabéns pelo artigo :)

    • Valeu Marcel,

      Eu a ideia foi justamente mostrar que para cada ambiente existe uma solução que se adequa melhor, e que independente de qualquer seja mais nova, é sempre muito importante (e benéfico para o cliente) que seja implementada a melhor solução para seu negócio, e não necessariamente a que está no "auge".

      Obrigado,

      Abraço,

      Edvaldo Castro

  • Legal seu artigo, seria interessante falar também do Database Mirroring. Esse Always on é só pra quem tem o SQL 2012 ou superior.

    • Obrigado Josias,

      Neste ponto eu quis focar um pouco mais nas soluções que utilizam o WSFC como base.
      O Mirroring está marcado como deprecated há algumas versões e finalmente vai sair de cena no SQL Server 2016.

      De qualquer maneira, dá um ótimo post falar sobre esta transição, e o que vai substituí-lo.

      Obrigado pela visita e pelo comentário.

      abraços,

      Edvaldo Castro

      • É verdade, o Mirroring não o usa como pré-req, desculpe-me pela desatenção rs. Me tire uma dúvida, onde você leu que o Mirroring está marcado como deprecated? É alguma informação oficial da Microsoft ou rumores? Tenho mais de 8 bases em mirror no meu ambiente e possivelmente, em um futuro próximo terei que migrar.

Related Post