Planejar e implementar um plano de alta disponibilidade e recuperação de desastres que atenda a todos os contratos de nível de serviço não é uma tarefa trivial e requer uma compreensão muito clara dos pontos fortes e fracos nativos do SQL Server. Ao combinar requisitos com uma combinação de recursos, alguns dos detalhes críticos podem ser encobertos e, neste post, apresentarei algumas distorções comuns e suposições ruins que podem se infiltrar em uma solução - fazendo com que erramos o alvo em nossos objetivos de ponto de recuperação e tempo de recuperação. Alguns dos exemplos de distorções ou autoilusões que detalho aqui podem ser generalizados em diferentes características e alguns são específicos de cada característica.
"Testamos nosso plano de recuperação de desastres quando lançamos nosso projeto e sabemos que funcionará"
Trabalhei com clientes que de fato acertaram sua abordagem de recuperação de desastres – uma vez. Mas uma vez que todos se sentiram confiantes na eficácia da solução, nenhum outro exercício de recuperação de desastres foi realizado novamente. Claro – enquanto isso, a camada de dados e o aplicativo continuam mudando ao longo do tempo. Essas alterações introduzem novos objetos e processos que são críticos para o aplicativo. E mesmo que tudo permaneça estático após o lançamento, você ainda precisa levar em conta a rotatividade de pessoal e os diversos conjuntos de habilidades. A equipe de hoje pode realizar com sucesso um exercício de recuperação de desastres? E mesmo a melhor equipe precisa de prática contínua.
"Não teremos perda de dados porque estamos usando espelhamento de banco de dados síncrono"
Digamos que você esteja usando espelhamento de banco de dados síncrono entre duas instâncias do SQL Server, com cada instância em um data center separado. Neste exemplo, suponha que a latência da transação seja aceitável apesar de ser uma sessão de espelhamento de banco de dados síncrono com alguns quilômetros entre os data centers. Você não tem uma testemunha na mistura porque deseja controlar o failover do espelho do banco de dados manualmente.
Agora, digamos que seu data center de recuperação de desastres desapareça, mas seu data center principal ainda está disponível. Seu banco de dados principal está desconectado do banco de dados espelho, mas ainda está aceitando conexões e modificações de dados. E quanto ao requisito “sem perda de dados” agora? Se as transações forem executadas no principal desconectado por mais uma hora, qual é o seu plano se o data center principal também for perdido?
"Nosso empresário diz que podemos perder até 12 horas de dados"
É importante fazer algumas perguntas mais de uma vez e para mais de um indivíduo em uma organização. Se alguém lhe disser que “12 horas de perda de dados são aceitáveis” – pergunte novamente ou pergunte qual seria a consequência dessa perda de dados. Pergunte a outras pessoas também. Eles podem dar-lhe um requisito muito mais rigoroso. Descobri que os objetivos do ponto de recuperação exigem alguma negociação e mais do que algumas discussões ponderadas e deliberadas.
"Estamos usando [espelhamento de banco de dados ou grupos de disponibilidade] e estamos cobertos para o que precisamos em caso de desastre"
O espelhamento de banco de dados e os grupos de disponibilidade certamente podem ser usados para protegê-lo no nível do banco de dados, mas e o resto? E seus logins? Pacotes SSIS? Empregos? Bancos de dados de modelo de recuperação não-FULL? Servidores vinculados?
"Estamos usando o recurso XYZ do SQL Server, então não perderemos nenhuma transação em andamento"
Não desculpe. Embora alguns recursos permitam redirecionamento transparente, isso não é o mesmo que reter e persistir transações abertas no momento do failover. Nenhum recurso do SQL Server oferece essa funcionalidade hoje.
"A equipe que dá suporte à camada de dados para este aplicativo odeia o recurso XYZ do SQL Server, mas estamos avançando porque foi isso que nos foi recomendado por um consultor externo"
Embora fosse bom se as pessoas não desenvolvessem preconceitos específicos em relação aos recursos do SQL Server, esse geralmente não é o caso. Se você tentar forçar soluções em uma equipe que não está de acordo com eles, você corre o risco de uma falha predeterminada. Como parte dos exercícios de HA/DR em que ajudei no passado, estou sempre interessado em ouvir sobre as experiências anteriores das pessoas com recursos específicos. Por exemplo, algumas empresas aproveitam muito bem centenas de instâncias de cluster de failover – enquanto outras as evitam devido a experiências ruins de versões anteriores. Ao planejar uma solução, você não pode ignorar o histórico ou as predisposições da equipe que será responsável por implantar e apoiar a solução recomendada.
"Como DBA, decido qual tecnologia de HA/DR usar para a camada de dados, então vamos usar grupos de disponibilidade daqui para frente"
Um administrador de banco de dados poderia configurar o espelhamento de banco de dados com pouco ou nenhum envolvimento com outras equipes. Agora, com grupos de disponibilidade, mesmo que um administrador de banco de dados possa fazer tudo sozinho, pode ser imprudente fazê-lo. Afinal, se você estiver implantando grupos de disponibilidade para fins de recuperação de desastres, desejará que todos os envolvidos em uma operação de recuperação de desastres estejam cientes de sua solução e dos requisitos necessários para voltar a ficar online e recuperar dados com êxito. Com os grupos de disponibilidade, você precisará pensar no cluster de failover do Windows Server, nas configurações de quorum, nos votos do nó, no ouvinte do grupo de disponibilidade e muito mais. Se você precisar de outras pessoas para facilitar uma solução, certifique-se de que elas estejam envolvidas com a recomendação inicial.
"Estamos usando grupos de disponibilidade para que possamos ter disponibilidade somente leitura em caso de interrupção de nossa réplica de leitura/gravação"
Este é apenas um exemplo de um cenário “e se”. Com qualquer implementação de funcionalidade, você desejará imaginar as várias maneiras pelas quais a falha pode ocorrer – e, em seguida, certifique-se de testá-la para garantir que seus requisitos ainda sejam atendidos. Por exemplo – se você acha que suas réplicas assíncronas somente leitura do grupo de disponibilidade do SQL Server 2012 estarão disponíveis quando a réplica de leitura/gravação estiver indisponível, você ficará desagradavelmente surpreso ao ver o
Unable to access database 'XYZ' because its replica role is RESOLVING which does not allow connections mensagem em produção. "Testamos o recurso XYZ do SQL Server e o failover foi rápido, por isso estabelecemos que podemos cumprir nossos objetivos de tempo de recuperação facilmente"
Digamos que você decida usar o espelhamento de banco de dados para alta disponibilidade no nível do banco de dados do usuário. Você quer um failover rápido (medido em segundos) e, de fato, vê um failover rápido durante o teste. Mas era um teste realista? Você estava empurrando uma carga de trabalho significativa? No exemplo de espelhamento de banco de dados, a parte mais longa de sua operação de failover pode ser para as operações de redo. Se você não estiver conduzindo cargas de trabalho realistas, não poderá realmente dizer que seu failover será realmente “rápido”.
"Se tivermos um desastre e precisarmos recuperar e reconciliar dados, descobriremos quando chegar a hora"
Este é difícil. Digamos que você tenha um desastre e precise tornar seu data center secundário operacional. Você decide forçar o serviço para os bancos de dados mais críticos no datacenter secundário e agora tem uma divisão na linhagem de modificações de dados (algumas linhas não reconciliadas no datacenter primário e agora novas modificações no datacenter secundário). Eventualmente, seu data center principal é colocado online – mas agora você tem dados que precisam ser recuperados e reconciliados antes que você possa restabelecer a solução geral de HA/DR. O que você faz? O que você pode fazer? Essa discussão raramente é fácil e pode depender de vários fatores, como os pacotes de software que você comprou, a complexidade da camada de dados e as ferramentas de convergência de dados à sua disposição. Na verdade, a discussão geralmente é tão difícil que as pessoas não a têm. Mas se os dados forem críticos o suficiente para você configurar um data center secundário, uma parte importante da discussão deve incluir a melhor forma de recuperar os dados e também reconciliá-los após a ocorrência de um desastre.
Resumo
Este artigo incluiu apenas alguns exemplos de como podemos nos iludir pensando que uma solução está atendendo plenamente aos seus requisitos. Embora seja da natureza humana fazer isso – quando se trata de perda de dados e continuidade de negócios, nossos trabalhos dependerão de sermos mais agressivos ao testar nossas próprias crenças e suposições.
