Alta disponibilidade no SQL Server

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (1)  (0)

Este artigo apresenta soluções de alta disponibilidade para o SQL Server. Serão discutidas estratégias para garantir a continuidade dos negócios de sua empresa.

Fique por dentro
A necessidade de continuidade das atividades de negócio leva empresas de tecnologia a criarem sistemas de alta disponibilidade. O SQL Server apresenta várias tecnologias deste tipo, considerando questões como tempo de recuperação, capacidade de manter as informações íntegras, dentre outras.

Neste artigo apresentaremos uma visão geral de cada uma delas, suas características e sugestões de uso. Conhecer as soluções de alta disponibilidade do SQL Server permite que definamos estratégias que estejam melhor alinhadas às restrições impostas pelo cenário que estamos tratando.

Um sistema de alta disponibilidade é aquele que permanece disponível a maior parte do tempo, minimizando ao máximo riscos de parada do sistema. Como muitos sistemas de informação têm como elemento central bancos de dados relacionais, a continuidade dos negócios depende da disponibilidade destes bancos.

Um sistema de gerenciamento de banco de dados depende de vários componentes de hardware e software para rodar e a alta disponibilidade é conseguida com redundâncias que tentam eliminar pontos únicos de falha (Single Point Of Failure - SPOF) de cada componente do sistema

O SQL Server fornece boas alternativas de alta disponibilidade que trabalham em conjunto com outras tecnologias de software e hardware que também eliminam pontos únicos de falha, aumentando assim a confiabilidade do sistema como um todo.

Assim, a camada de hardware da solução de alta disponibilidade deve ser levada em consideração pensando-se em dispositivos tolerantes a falha. Para servidores físicos, os pontos de atenção são a fonte de alimentação, o armazenamento e a rede.

Esta lista foca nos principais componentes que podem ter redundância, o que garante que o hardware onde rodam sistema operacional e softwares que fornecem serviços aos usuários não fique vulnerável a falhas. Vale notar também que estas opções de hardware são independentes de software e podem atender a várias plataformas como Windows, Linux e Unix, e SGBDs como SQL Server e Oracle.

Apesar da virtualização ser uma realidade hoje em dia, não iremos entrar nesse detalhe pois algumas características de proteção de máquinas virtuais não se aplicam a servidores de banco de dados, pois não contemplam o conceito de transação, conceito este que é essencial para o funcionamento e garantia de consistência dos mesmos.

Em se tratando de software, a versão 2012 do SQL Server apresenta as opções de alta disponibilidade listadas a seguir:

· AlwaysOn Failover Cluster Instances: com base no Windows System Failover Cluster (WSFC), fornece alta disponibilidade através de redundância no nível da instância.

Na prática, são duas instâncias de mesmo nome rodando em servidores diferentes que estão ligados ao mesmo storage. No entanto, a instância permanece ativa em um único nó do cluster usando exclusivamente o storage que atende a todos os servidores do cluster;

· AlwaysOn Availability group: permite que um ou mais bancos de dados de uma instância tenham uma cópia da base em outro servidor de SQL Server. O termo “réplica”, neste artigo, se referenciará a cópias de um banco de dados principal que fica em modo read/write;

· Database mirroring: espelhamento de um banco de dados de um servidor principal em outro servidor secundário, que pode permitir failover manual ou instantâneo e automático. A base principal é chamada de principal database, enquanto que a base redundante é chamada mirrored database. Esta funcionalidade será removida em futuras versões do SQL Server;

· Log Shipping: também opera no nível de banco de dados e pode manter uma ou mais cópias de um banco de dados principal. As cópias são chamadas de bases secundárias e são warm databases, ou seja, podem ser usadas apenas para leitura. Um exemplo seria seu uso para apoiar a geração de relatórios.

Veremos a " [...]

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?