SQL Server: Proteção de dados a todo custo

  • Artigo

A manutenção da alta disponibilidade dos armazenamentos de dados corporativos gerenciados com o SQL Server é um elemento essencial de qualquer estratégia de gerenciamento de dados.

Paul S. Randal

Sem a capacidade ininterrupta de armazenar e recuperar dados, os negócios seriam paralisados. Além das pessoas, os dados são cada vez mais o ativo mais importante de qualquer empresa. E o SQL Server 2008 ou o SQL Server 2008 R2 estão, frequentemente, no coração de qualquer estratégia de gerenciamento de dados. Portanto, seguindo essa linha de raciocínio, os desenvolvedores e DBAs são os responsáveis por manter a empresa em funcionamento.

Mas que volume de orientação propriamente dita é transmitido dos gerentes das unidades de negócios para aqueles que são responsáveis pela camada de dados? Os requisitos comerciais são comunicados claramente? Eles são comunicados de uma forma que os profissionais de tecnologia conseguem converter em uma estratégia de produção?

Em determinados segmentos de mercado, existem requisitos normativos rígidos a respeito de aspectos de infraestrutura, como auditoria de segurança, criptografia de dados e retenção de dados. O não atendimento desses requisitos pode levar a multas ou advertências para a empresa, além da perda de credibilidade e de receitas futuras. Muitas vezes, o pior que pode acontecer em um mercado altamente competitivo.

Alinhe sua estratégia de gerenciamento de dados

Existem certos requisitos comerciais cuja comunicação pelos líderes corporativos parece mais simples ou mais direta, como aqueles relacionados a segurança, geração de relatórios, gerenciamento de cargas de trabalho e auditoria. Felizmente, eles também são mais fáceis de implementar dentro da estrutura do SQL Server 2008:

  • Você pode atender a requisitos de segurança de dados usando recursos como a Criptografia de Dados Transparente, que criptografa os dados silenciosamente, e o Gerenciamento Extensível de Chaves, que permite armazenar chaves de criptografia “externamente”, longe dos dados criptografados.
  • Você pode atender a requisitos de geração de relatórios com o SQL Server Reporting Services.
  • O Administrador de Recursos pode ajudá-lo a prever o desempenho da carga de trabalho.
  • Você pode usar o SQL Server Audit para atender a requisitos abrangentes de auditoria.

No entanto, existem dois requisitos comerciais importantes que muitas vezes são malcomunicados: o tempo de inatividade do sistema e a perda de dados aceitável. Eles são conhecidos como RTO (Objetivo de tempo de recuperação) e POR (Objetivo de ponto de recuperação), respectivamente. Infelizmente, é muito comum ver os gerentes comerciais negligenciando o RTO e o RPO, para depois descobrirem que a camada de dados não está tão protegida quanto eles gostariam quando acontece um desastre, o que leva a tempo de inatividade e perdas de dados.

Seja você um gerente comercial ou um DBA, reserve um minuto agora para considerar se você sabe com certeza se a camada de dados está tão protegida quanto a empresa necessita. Caso chegue à conclusão de que ela não está, qual é seu plano para resolver a situação?

Não entrar em pânico nem ser complacente são as reações apropriadas. Apagar o incêndio para depois criar uma estratégia na próxima semana é uma receita de desastre por si própria. É preciso atenção e disciplina para projetar e implementar uma estratégia apropriada e abrangente de alta disponibilidade e recuperação de desastres (HA/DR) do SQL Server. Ignorar o problema é um convite à calamidade e o equivalente à negligência comercial.

Defina os requisitos

A chave para criar uma estratégia bem-sucedida é, primeiro, definir os requisitos comerciais. Depois, é preciso equilibrá-los em relação às limitações comerciais. É nesse ponto que os líderes de TI e das unidade de negócios têm que se reunir para encarar os fatos. Os requisitos estratégicos devem encapsular os seguintes fatores para cada parte de dados relevante às operações comerciais:

  1. Qual a importância desta parte de dados em comparação com o restante do armazenamento de dados corporativo? Os gerentes comerciais geralmente afirmam que tudo tem prioridade máxima e deve ser protegido igualmente. Isso funciona com pequenas quantidades de dados, mas se torna cada vez menos prático quando há vários terabytes espalhados em diversas instâncias do SQL Server.
  2. Que quantidade de dados a empresa pode perder sem ser prejudicada? Os proprietários de empresas, obviamente, gostariam de ter zero perda de dados, mas isso nem sempre é prático.
  3. Por quanto tempo os dados podem ficar indisponíveis? Os proprietários de empresas também gostariam de ter zero tempo de inatividade, mas, infelizmente, isso não pode ser conseguido na realidade. Mas é possível se aproximar bem disso.
  4. O primeiro ou o segundo fator se alteram em vários momentos do dia ou aos finais de semana? Isso pode ter um efeito profundo sobre sua capacidade de atender a requisitos. Ter zero tempo de inatividade e perda de dados é muito mais possível por um período limitado, por exemplo, das 9h00 às 17h00 aos finais de semana, em comparação com o acesso total 24 x 365.
  5. É aceitável comprometer o desempenho da carga de trabalho para preservar a disponibilidade e a durabilidade dos dados? As únicas tecnologias capazes de fornecer zero perda de dados exigem o espelhamento síncrono dos registros de logs de transação ou gravações no subsistema de E/S. Ambos podem levar a atrasos de processamento. É uma troca.

Uma boa maneira de pensar nisso é considerar o impacto sobre a empresa de ter cada uma das partes de dados inacessível ou perdida. Você poderá se surpreender quando considerar e quantificar as ramificações em potencial para seus clientes, a imagem de sua empresa e seus controles regulatórios.

Defina as limitações

Um dos erros mais comuns ao se projetar e implementar uma estratégia de HA/DR é prosseguir com o design técnico sem antes considerar os fatores limitantes. Isso significa retornar à prancheta de desenho — o que é um enorme desperdício de tempo e dinheiro — ou implementar uma estratégia abaixo dos padrões que não atendo aos requisitos comerciais.

Existem muitas limitações, tanto técnicas quanto não técnicas. O fator predominante é, geralmente, o orçamento. Mais hardware significa mais consumo de energia, que significa mais dissipação de calor, que significa mais ar condicionado, que significa ainda mais consumo de energia, que significa, coletivamente, mais espaço necessário e mais dinheiro do orçamento alocado para essa infraestrutura física. Você também deve levar em conta o custo do hardware, as licenças adicionais do SQL Server e do Windows, a largura de banda da rede e, possivelmente, ainda mais pessoas para gerenciar os sistemas adicionais e o restante do data center.

As concessões e o quebra-cabeça corporativo

Depois de se familiarizar com todas as limitações técnicas, o truque é chegar ao meio-termo mais eficaz. Você precisa de uma lista de prioridades com os dados que são mais importantes para a empresa. Devido às limitações sob as quais você estará trabalhando, será preciso avaliar as tecnologias que ajudam a atender aos requisitos comerciais mais importantes.

É essencial que você não tente simplesmente adaptar uma tecnologia encarregada de atender a novos requisitos comerciais. Não se comprometa nem escolha uma tecnologia sem avaliá-la adequadamente em relação às suas prioridades comerciais. É sempre melhor ter mais trabalho no começo e, depois, percorrer o processo corretamente. Você acabará com uma estratégia melhor que economiza tempo e dinheiro a longo prazo.

Se você achar que não pode atender aos requisitos comerciais com as tecnologias pelas quais pode pagar, terá que trabalhar com os líderes das unidades de negócios para alterar esses requisitos de forma a refletir as realidades orçamentárias. Como tecnólogo, por exemplo, não faz sentido concordar com um requisito comercial de zero perda de dados se o orçamento for insuficiente para a tecnologia síncrona. Quando ocorrer um desastre, as expectativas dos gerentes comerciais não serão atendidas e a culpa pela situação cairá sobre a equipe de TI.

Uma das coisas mais difíceis de se fazer durante o projeto de uma estratégia de HA/DR é, geralmente, garantir que ela seja um componente harmonioso da estratégia geral de TI da organização. Por exemplo, se você for o DBA de uma grande corporação, provavelmente existem outras equipes responsáveis pelos servidores Windows, pela rede, pelo armazenamento, pela infraestrutura física, etc. Se a empresa precisar que um determinado banco de dados esteja disponível quatro horas depois de qualquer desastre, você poderá ter de envolver todas essas equipes para garantir que a coisa aconteça. Isso traz para a mistura políticas e relacionamentos entre as equipes. As outras equipes terão de concordar em cumprir com os mesmos contratos de nível de serviço que a equipe da camada de dados e também com as expectativas da empresa como um todo e as promessas feitas a ela.

Testando, testando

Se você achar que sua camada de dados não está devidamente protegida, é provável que a estratégia de HA/DR não esteja sendo adequadamente testada em sua empresa, também. É imperativo, quando se passa pelo processo de projetar e implementar um estratégia de HA/DR, que se teste o sistema realmente para ver se ele pode responder na eventualidade de uma crise.

Isso é mais fácil na teoria do que na prática, no entanto. Convencer os gerentes comerciais a conduzir um teste que pode resultar em tempo de inatividade é um desafio. Você pode argumentar que é melhor conduzir um teste quando todos estão no local, esperando por um “desastre”, e prontos para corrigir quaisquer problemas rapidamente. A alternativa pode ser descobrir um projeto falho quando um desastre realmente ocorrer às duas da manhã em um feriado, quando há apenas uma equipe reduzida à mão.

Muito embora você possa vir a descobrir que sua camada de dados não está protegida a um nível aceitável contra tempo de inatividade e perda de dados, existem muitas opções para se implementar uma estratégia de HA/DR usando o SQL Server 2008 ou o SQL Server 2008 R2. Compreenda as várias tecnologias e seus prós e contras e examine as arquiteturas que outras empresas implantaram com êxito. Confira os seguintes white papers e postagens de blog para obter mais informações:

Certifique-se de trabalhar para implantar uma estratégia válida. Essa é a única maneira de proteger sua empresa e evitar tempos de inatividade inesperados.

Paul Randal

Paul S. Randalé diretor administrativo da SQLskills.com, diretor regional da Microsoft e um MVP no SQL Server. Ele trabalhou na equipe do Mecanismo de Armazenamento do SQL Server na Microsoft de 1999 a 2007. Paul escreveu o DBCC CHECKDB/repair para o SQL Server 2005 e foi responsável pelo mecanismo de armazenamento principal durante o desenvolvimento do SQL Server 2008. Randal é especialista em recuperação de desastre, alta disponibilidade e manutenção de bancos de dados, e participa regularmente de conferências em todo o mundo. Ele mantém um blog em SQLskills.com/blogs/paul, e seu Twitter é o twitter.com/PaulRandal.

Conteúdo relacionado