Alta Disponibilidade no SQL Server 2005/2008

Uma visão geral de soluções de alta disponibilidade no SQL Server 2005/2008

 

 

Alta disponibilidade pode ser definida como uma solução que mascara os efeitos de uma falha de hardware ou software e mantém a disponibilidade dos aplicativos, de modo a minimizar o tempo de inatividade de um sistema.

Para algumas empresas, esta definição significa que deverá existir um hardware redundante igual ao de produção, o que requer que os dados e o hardware tenham duração e disponibilidade de 99,995 % ou mais.  Outras empresas necessitam apenas que os dados propriamente ditos tenham alta disponibilidade, sem tanta preocupação com o desempenho do nível de produção caso um failover (processo no qual uma máquina assume os serviços de outra, quando esta última apresenta alguma falha) seja necessário.

Para determinar a melhor solução de alta disponibilidade, é necessário avaliar questões referentes aos tipos de interrupções que poderão ocorrer e indicar como isso afeta seus Contratos de Nível de Serviço (SLAs). As interrupções que podem afetar a disponibilidade são:

·           Desempenho Planejado: normalmente é uma manutenção programada sobre a qual os usuários dos sistemas são informados com antecedência;  

·           Não Planejado: geralmente resulta de uma falha de hardware ou software que torna os dados inacessíveis; e

·           Degradação do Desempenho: a degradação do desempenho também pode provocar interrupções, e normalmente é medida no tempo de resposta do usuário final.

 

E por fim, identificar o nível de atividade dos dados e se estes devem estar sempre on-line ou off-line ocasionalmente. A seguir será descrito previamente cada opção de disponibilidade disponível para o Microsoft SQL Server 2005, que seriam: Cluster de Failover, Espelhamento de banco de dados, Log Shipping e Replicação.

Cluster de Failover

O Cluster de failover é basicamente uma solução de hardware que consiste em um grupo de computadores independentes que trabalham juntos para aumentar a disponibilidade de aplicativos e serviços. Os servidores em cluster (chamados de nós) são conectados através de cabos físicos e de software. Se um dos nós do cluster falhar, outro começará a fornecer os serviços, sendo que os usuários do sistema teriam o mínimo de interrupções nos serviços.

Um requisito inicial que deve ser verificado antes da instalação do cluster é identificar se o hardware é certificado pela Microsoft. Este deve constar na lista de soluções de hardware certificada, chamada de Hardware Compatibility List (HCL). Por ser uma solução de alta disponibilidade, é preciso assegurar que componentes lógicos e físicos funcionam da maneira adequada.

Para uma solução em cluster, são necessários os seguintes componentes físicos (ver Figura 1):

·         Nós de cluster (Cluster Nodes): é um servidor que faz parte do cluster e compartilha os recursos do cluster. Todos os nós do cluster devem possuir o mesmo sistema operacional e plataforma (32 bits ou 64 bits).

·         Rede Privada (Private Network): a função da rede privada é verificar se os nós que compõem o cluster estão funcionando e disponíveis. A rede privada é implementada através de uma placa de rede dedicada e exclusiva no nó do cluster.

·         Rede Pública (Public Network): a função da rede pública é permitir que as aplicações conectem-se no cluster e que o cluster possa conectar-se na rede. A rede pública é implementada através de uma placa de rede dedicada e exclusiva no nó do cluster.

·         Conjunto de discos compartilhados (Shared Disk Array): conjunto de discos físicos (SCSI ou Fiber Channel) que são acessados pelos nós do cluster. O conjunto de discos compartilhados também é conhecido como “storage do cluster”. A “storage” apresenta para os nós do cluster um conjunto lógico de discos que são acessados pelo sistema operacional como se fossem discos internos do servidor. O serviço de cluster da Microsoft implementa o conceito de shared nothing disk, pois desta forma somente um nó do cluster tem acesso exclusivo a uma ou mais unidades lógicas da “storage” de cada vez.

·         Disco de Quorum (Quorum Disk): é uma unidade lógica na “storage” que contém o arquivo de log e informações de estado do cluster. O nó que for o dono do disco de quorum é o nó responsável pelo cluster.

 

 

Figura 1. Cluster Completo

Na Figura 1 é possível visualizar como ficaria um cluster completo com todos os seus componentes mais um disco onde possui uma instalação de uma instância (serviço) do SQL Server. No caso de uma falha no nó principal, o segundo nó assumirá os serviços que estavam sendo disponibilizados, sendo transparente para o usuário final. A mudança entre os nós pode ser feita de forma manual ou automática.

Espelhamento de banco de dados

O espelhamento de banco de dados é basicamente uma solução de software para aumentar a disponibilidade dos dados, dando suporte a failover quase instantâneo. O espelhamento de banco de dados mantém duas cópias de um único banco de dados em servidores diferentes. Uma instância do servidor atua como banco de dados para os clientes (servidor principal) enquanto a outra instância funciona como servidor em espera ativa ou passiva (servidor de espelho), dependendo da configuração.

A configuração mais simples do espelhamento do banco de dados envolve apenas os servidores: principal e espelho. Nessa configuração, se o servidor principal for perdido, o servidor espelho poderá ser usado como um servidor de espera passiva (a mudança deve ocorrer de forma manual), onde poderá ocorrer possível perda de dados (Ver Figura 2).

Figura 2. Espelhamento de Banco de Dados

 

Outra configuração é dita como modo de alta segurança com failover. Neste caso envolverá mais uma instância de servidor de banco de dados, conhecido como testemunha, que possibilita que o servidor espelho atue como um servidor em espera ativa (a mudança ocorre de forma automática) (ver Figura 3). O failover do banco principal para o banco de espelho normalmente demora vários segundos.  

Figura 3. Espelhamento com Servidor de Testemunha

 

As Figuras 2 e 3 demonstram como resultaria a configuração do espelhamento de banco de dados com e sem o servidor de testemunha. Caso ocorra uma falha no banco de dados principal o servidor espelho deverá assumir o seu lugar, fazendo com que os usuários possam continuar acessando o aplicativo, mesmo após a ocorrência de alguma falha.

O espelhamento de banco de dados oferece os seguintes benefícios:

·         Detecção e failover automático;

·         Failover manual;

·         Redirecionamento transparente para os clientes;

·         Opera em nível de banco de dados;

·         Usa uma única cópia duplicada do banco de dados;

·         Usa servidores padrão;

·         Fornece relatórios no servidor de espelho, usando cópias do banco de dados (instantâneos);

·         Quando opera sincronicamente, proporciona zero perda de trabalho por meio de confirmação atrasada no banco de dados principal.

Log Shipping (Envio de Logs)

Assim como o espelhamento de banco de dados, o Log Shipping também é uma solução de software. Este recurso pode ser utilizado para manter um ou mais banco de dados de espera passiva (banco de dados secundário) para um banco de dados de produção (banco de dados primário).

O Log Shipping permite o envio automático de backups do log de transações (ver Nota DevMan 1) de um banco de dados primário para um banco de dados secundário. Os backups de logs de transação são aplicados individualmente aos bancos de dados secundários, dessa forma existindo cópias do banco de dados primário. Uma terceira instância de servidor opcional, conhecido como servidor monitor, registra o histórico e o status das operações de backup e restauração e podendo emitir alertas se essas operações não forem executadas corretamente.

A Figura 4 mostra a configuração do envio de logs com uma instância do servidor primário, uma instância secundária e uma instância de servidor monitor. Esta figura ilustra as etapas executadas pelos backups, cópia e restauração:

1.      A instância do servidor primário executa o trabalho de backup do log de transações do banco de dados primário. Essa instância do servidor coloca o backup do log em um arquivo de backup de log primário, enviado para a pasta de backup.

2.      A instância de servidor secundário executa seu próprio trabalho de cópia do arquivo de backup de log primário para a sua própria pasta de destino local.

3.      O servidor secundário executa seu próprio trabalho de restauração do arquivo de backup de log a partir da pasta de destino local no banco de dados secundário local.

 

 

As instâncias de servidor primário e secundário enviam seus próprios históricos e status para a instância do servidor de monitoramento.

 

Figura 4. Configuração Típica Log Shipping

 

O Log Shipping envolve um atraso modificável pelo usuário entre o momento em que o servidor primário cria um backup de log do banco de dados e quando o servidor secundário restaura um banco do backup. Antes que um failover possa ocorrer, um banco de dados deve ser atualizado completamente pela aplicação manual de quaisquer backups de log não restaurados.

Esta solução fornece a flexibilidade de suportar vários bancos de dados de espera, oferecendo as seguintes funcionalidades:

·         Suporte a vários bancos de dados secundários em várias instâncias de servidor para um único banco de dados primário;

·         Permite um atraso especificado pelo usuário entre o momento em que o servidor primário faz backup do log do banco de dados primário e quando os servidores secundários devem restaurar o backup de log. Um atraso mais longo pode ser útil, por exemplo, se dados forem alterados acidentalmente no banco de dados primário. Se a alteração acidental for notada rapidamente, um atraso pode permitir que você recupere dados ainda inalterados de banco de dados secundário, antes que alteração seja refletida.

 

Se precisar de vários bancos de dados de espera, poderá usar o Log Shipping independentemente ou como um suplemento para o espelhamento de banco de dados.

Replicação

A replicação é utilizada para copiar dados para um servidor e distribuí-los para outros servidores. Também pode ser utilizada para copiar, transformar e distribuir os dados personalizados entre os múltiplos servidores. Usando a replicação, é possível distribuir dados para diferentes locais e para usuários remotos e móveis através de redes locais e de longa distância, conexões dial-up, conexões sem fio e a Internet. Algumas razões para usar a replicação incluem:

·         Sincronizar alterações para bancos de dados remotos com um banco de dados central. Por exemplo, se a equipe de vendas utiliza laptops remotos, você pode precisar criar uma cópia de dados para a região de vendas da equipe no laptop. Mais tarde, um vendedor no campo poderá desconectado da rede, acrescentar informações ou fazer alterações. Com a replicação, essas modificações seriam sincronizadas com o banco de dados central.

·         Criar múltiplas instâncias de um banco de dados para que você possa distribuir a carga de trabalho. Por exemplo, se tiver um banco de dados central que é atualizado regularmente, talvez seja recomendável obter alterações para os bancos de dados departamentais à medida que elas ocorram. Os empregados podem então acessar os dados departamentais em vez de tentar se conectar ao banco de dados central.

·         Mover conjuntos de dados específicos de um servidor central e distribuí-los para vários outros servidores. Por exemplo, usar a replicação para um banco de dados central que precisasse distribuir os dados de vendas para todos os bancos de dados de lojas de departamento da empresa.

 

A replicação foi projetada para atender às necessidades de uma ampla variedade de ambientes. A arquitetura de replicação é dividida em vários processos, procedimentos e componentes diferentes, cada um dos quais é utilizado para personalizar a replicação para uma situação particular. A arquitetura de replicação inclui:

·         Componentes da replicação: são os componentes servidores e dados na replicação. Sendo eles:

o   Publicador: são servidores que disponibilizam os dados para a replicação em outros servidores. Também monitoram alterações nos dados e mantêm outras informações sobre o banco de dados de origem. Todo agrupamento de dados tem apenas um publicador.

o   Distribuidor: são servidores que distribuem os dados replicados. Os distribuidores armazenam o banco de dados de distribuição, os metadados, os dados históricos e (para replicação transacional) as transações.

o   Assinante: são servidores de destino para replicações. Esses servidores armazenam os dados replicados e recebem atualizações. Os assinantes também podem fazer alterações em dados. Os dados podem ser publicados em múltiplos assinantes.

·         Agentes e trabalhos de replicação: Aplicativos que auxiliam no processo de replicação.

·         Variantes da replicação: São os tipos de replicação, sendo elas:

o   Replicação Transacional: normalmente é usada em cenários de servidor para servidor que requerem alta taxa de transferência, incluindo: melhora da escalabilidade e disponibilidade; armazenamento de dados data warehouse e relatórios; integração de dados de vários sites; integração de dados heterogêneos e descarregamento de processamento em lote.

o   Replicação de Mesclagem: é projetada principalmente para aplicativos móveis ou de servidor distribuído que possuem possíveis conflitos de dados. Os cenários comuns incluem: troca de dados com usuários móveis; aplicativos de POS (ponto de vendas) para o consumidor e integração de dados de vários sites.

o   Replicação de Instantâneo (Snapshot): é usada para fornecer o conjunto inicial de dados para replicação transacional e de mesclagem. Ela também pode ser usada quando as atualizações completas de dados estiverem apropriadas.

 

A Figura 5 demonstra como ficaria a arquitetura da replicação.

Figura 5. Replicação

 

A replicação possibilita disponibilidade em tempo real e escalabilidade entre servidores. Suporta filtragem para fornecer um subconjunto de dados nos Assinantes e também permite atualizações particionadas. Os Assinantes ficam online e disponíveis para relatórios e outras funções, sem recuperação de consultas.

Configurando Espelhamento de Banco de Dados

Agora que conhecemos as soluções disponíveis para disponibilidade de um banco de dados, vamos agora simular uma das soluções de disponibilidade que o SQL Server 2005/2008 fornece levando em consideração o seguinte estudo de caso: você é administrador de um banco de dados de uma empresa que vende seus produtos através da web. É preciso garantir a disponibilidade dos dados, sem qualquer tipo de interrupção. Analisando o ambiente do cliente, você decide implementar o espelhamento do banco com espera ativa.

                Antes de aprendermos como criar um espelhamento no banco, vamos criar o banco de dados SQLMagazine e as tabelas que o compõem: PRODUTOS, CLIENTES e VENDAS (Ver Listagem 1). Para executar a Listagem 1, abra o SQL Server Management Studio, conecte-se na instância que será o serviço principal do espelhamento. Em seguida, na barra de ferramentas solicite uma nova query (Ver Figura 6).

Figura 6. Solicitando uma nova query

Listagem 1. Criando banco de dados e tabelas

USE [MASTER]

...