Backup Transformation from the Inside

TRANSFORMAÇÃO DO BACKUP
DE DENTRO PARA FORA
O arquiteto chefe de Oracle da EMC tem algo a dizer
O que é a transformação do backup e por que é tão crucial para a integridade e o
bem-estar de uma organização? Nestas perguntas e respostas, Darryl Smith,
arquiteto chefe de Oracle na EMC e veterano na guerra de backups, oferece a visão
de um profundo conhecedor sobre a necessidade e o impacto da transformação do
backup dentro do departamento de TI da EMC e em nossos negócios.
"Se sua infraestrutura de backup não
consegue acompanhar a explosão de
dados nem manter o ritmo da
mobilidade da computação em nuvem,
seu banco de dados vai sofrer...
Portanto, é absolutamente importante
garantir que sua infraestrutura de
backup seja muito mais ágil e
dinamicamente dimensionável do que
ela é hoje."―Darryl Smith
Smith, que é responsável por todos os bancos de dados da EMC, principalmente o
Oracle, mas também o SQL Server, MySQL, Postgres e Greenplum, descreve as
alterações de pessoal e de processos que a TI da EMC enfrentou e os efeitos
revolucionários que elas tiveram. Ele também olha para o futuro e nos oferece sua
visão da salvação do backup.
Para obter mais informações e recursos, visite brazil.emc.com/BackupLeader.
COMO UM ARQUITETO DE ORACLE, POR
QUE O BACKUP É IMPORTANTE PARA SUA
TRANQUILIDADE?
Sou responsável por garantir que os bancos de dados da EMC estejam íntegros,
ativos e funcionando e sejam capazes de atender a nossos usuários de negócios a
fim de que estes recebam a informação necessária. Se eu ou minha equipe não
aparecer no trabalho, tudo para. Se o banco de dados que sustenta o aplicativo de
CRM, o aplicativo de atendimento ao cliente ou qualquer aplicativo que você esteja
executando não funcionar, seu aplicativo não trabalhará.
Para que eu faça meu trabalho, o backup é essencial. Uma das principais dificuldades
no início de nossa jornada para a nuvem era o fato de que nossa infraestrutura de
backup não estava acompanhando o ritmo. Estávamos dependendo de
infraestruturas legadas e de soluções de backup ponto a ponto. Isso era um
problema para minha tranquilidade — e continua sendo um problema para muitas
organizações hoje.
ENTÃO A TRANSFORMAÇÃO DO BACKUP É
MUITO IMPORTANTE?
Sim. É algo que temos realmente de fazer. Não pode continuar a fazer o backup do
modo que sempre fez no passado porque o modo antigo não pode ser dimensionado
e não funciona em infraestruturas de cloud virtualizadas. Isso deve-se ao facto de
que todas as aplicações, desde os pequenos sistemas de agendamento de salas de
conferências até o seu ERP mais essencial ou aplicações de apoio ao cliente,
realmente dependem de dados. Portanto, é essencial que os dados sejam
protegidos, o que não é possível sem a transformação do backup.
ISSO PODE AFETAR OS ESFORÇOS DE
VIRTUALIZAÇÃO E NUVEM?
Exato. Se sua infraestrutura de backup não consegue acompanhar a explosão de
dados nem manter o ritmo da mobilidade da computação em nuvem, seu banco de
dados sofrerá.
FOLHETO
Isso poderia significar qualquer coisa, desde redução no desempenho do aplicativo
até a perda de dados ou até mesmo a falha total do aplicativo, o que obviamente
seria crítico para uma empresa. Portanto, é absolutamente importante garantir que
sua infraestrutura de backup seja muito mais ágil e dinamicamente dimensionável do
que ela é hoje.
O QUE VOCÊ FEZ NOS ÚLTIMOS DOIS ANOS
PELA TRANSFORMAÇÃO DO BACKUP?
Hoje, do ponto de vista do servidor, estamos 94% virtualizados. Do ponto de vista
do banco de dados, estamos aproximadamente 84% virtualizados e, agora, estamos
virtualizando o mais rapidamente possível. Isso tem grandes implicações no backup.
Quando começamos, usávamos metodologias de backup tradicionais. Fazíamos o
backup usando o RMAN tradicional para nosso agendador de backup, o EMC
NetWorker, e em dispositivos de fita ou disco — dispositivos de fita virtual com disco
de reserva. As fitas, obviamente, são uma tecnologia muito antiga, portanto as
substituímos por bibliotecas de fita virtual. Só que elas também não podem ser
dimensionadas, e estávamos constantemente medindo, quantificando e restringindo
o uso desses recursos.
Este era realmente nosso principal problema: tínhamos um número limitado de
recursos e um número cada vez maior de bancos de dados, além de um volume cada
vez maior de dados que precisava de backup. Para acompanhar nossa virtualização,
basicamente abandonamos todas as nossas plataformas legadas. Até nossos nós de
armazenamento do NetWorker foram virtualizados.
EM QUE PONTO SUA TRANSFORMAÇÃO DO
BACKUP ESTÁ HOJE?
Agora, 24 meses depois, estamos avançando para o dimensionamento de nossa
infraestrutura. Nossos dispositivos de fita são coisa do passado, e estamos
substituindo os de fita virtual por dispositivos Data Domain, que têm muito mais
capacidade e throughput e podem armazenar dados por muito, mas muito mais
tempo graças à desduplicação. Essa primeira etapa realmente ajudou na redução das
restrições em nossa capacidade. Agora sabemos que, se precisarmos restaurar um
backup, poderemos recuperá-lo muito rapidamente e não teremos de depender de
fitas e armazenamento em outros locais. Porém, ainda estamos gerenciando o
backup como se tivéssemos essas antigas restrições, e é aí que realmente
precisamos começar a levar as coisas para o próximo nível.
Também trabalhamos no "banco de dados como serviço", onde pudemos automatizar
completamente o backup e a recuperação para que praticamente não exigissem
intervenção. Quando não tínhamos essa grande proliferação de dados, quando não
tínhamos computação móvel, podíamos configurar nossos backups e praticamente
esquecê-los, e isso era ótimo. Agora a vida é muito mais complicada, mas, ao
sermos capazes de automatizar os backups e criar scripts completos para eles, não
nos preocupamos mais se o backup ocorrerá, porque removemos as variáveis.
Estamos fazendo o mesmo com alguns de nossos bancos de dados muito grandes.
Trabalhamos com as equipes de backup e projetamos um backup descarregado. O
que quero dizer é que pegamos um clone do armazenamento, o montamos em um
servidor proxy ou em um nó de armazenamento do NetWorker e fazemos o backup
do banco de dados a partir daí. Nesse caso, o backup do banco de dados ou do
servidor proxy é conectado diretamente ao Data Domain; portanto, não temos
limitações de recursos. Logo, esses backups funcionam atualmente sem falhas e em
alta velocidade.
Esses são dois exemplos do que estivemos trabalhando com a equipe de backup a
fim de fornecer um backup que seja realmente confiável e dimensionável, que
essencialmente podemos configurar e esquecer.
PARECE QUE VOCÊ ESTÁ TRABALHANDO DE
FORMA DIFERENTE COM SUA EQUIPE DE
BACKUP. COMO OS PROCESSOS MUDARAM?
A substituição de nossa infraestrutura é somente um ponto de partida na
transformação de como nossa infraestrutura de backup funciona. Realmente
precisamos trabalhar mais em processos e procedimentos. É bom ter, por exemplo,
um agendador que abranja toda a empresa. Mas tentar gerenciar manualmente
componentes e recursos individuais atrapalha a capacidade de dimensionar
dinamicamente, bem como o impede de ter a agilidade que a computação em
nuvem exige.
A verdadeira chave para essa transformação total é reunir todos esses grupos,
membros e habilidades individuais em um conjunto maior de habilidades. Falamos
sobre isso o tempo todo quando falamos sobre a transformação da TI, que todas as
habilidades precisam ser reunidas. Isso não significa necessariamente que uma
pessoa tem de saber tudo, mas que as pessoas com diferentes conjuntos de
habilidades precisam trabalhar em sintonia para realmente se tornarem parte dessa
equipe central de arquitetura e, ao mesmo tempo, compartilharem o conhecimento.
COMO AS RELAÇÕES COM A EQUIPE DE
BACKUP MUDARAM?
Bem, o relacionamento estava ficando tenso. Estávamos tendo muitas dificuldades
com os backups, e as equipes de backup estavam constantemente lidando com
problemas. A tensão estava realmente nos dois lados — tanto a equipe de backup
quanto os DBAs estavam muito frustrados. Eles estavam lidando com questões
cotidianas e resolvendo problemas constantemente. Isso era um problema constante
e não somente dificultava os relacionamentos, mas também nossa capacidade de
oferecer um serviço a nossos usuários de negócios.
A equipe de backup tem atuado, tipicamente, nos bastidores. Você não ouve falar
deles; eles não são realmente parte do panorama maior da TI; eles não fazem parte
do processo de tomada de decisões. Eles apenas fazem os backups. Porém, esse tipo
de pensamento ou cultura simplesmente não funciona mais. A equipe de backup
realmente precisava ser uma parte da equipe maior de TI e ajudá-la na
transformação geral. Se não for assim, você terá problemas. Seus bancos de dados
não funcionarão como deveriam — perderão tempo na tentativa de gravar os
backups. No caso de falha, você não conseguirá recuperar seus sistemas nem dados.
Mais do que nunca, o backup realmente tem de ser uma prioridade.
QUAL É A DIREÇÃO QUE VOCÊ ESTÁ
TOMANDO? O QUE É A SALVAÇÃO DO BACKUP
PARA VOCÊ?
Bem, não usamos 100% de backup como serviço hoje, nós o usamos de modo
limitado. Por exemplo, todas as nossas outras ofertas de TI como serviço,
infraestrutura como serviço, bem como nossas ofertas de banco de dados como
serviço fazem uso de backups, e esses backups são totalmente automatizados e
fornecidos como serviços.
Assim, o objetivo final ou a meta da transformação de nossa infraestrutura de
backup é que seus administradores se tornem responsáveis pela infraestrutura e
pelo planejamento da capacidade a fim de garantir que exista capacidade suficiente.
Quanto a mim, como consumidor, como o DBA que está consumindo esses serviços
de backup, preciso ser capaz de configurar meus próprios backups, executá-los
quando eu quiser e poder fazer restaurações conforme necessário sem ter que
depender de outro grupo para garantir que tudo esteja funcionando. Portanto, meu
ideal é executar um console onde eu possa agendar todos os meus backups de
bancos de dados e não me preocupar se tenho ou não capacidade.
É quase igual à energia. Quando acendo as luzes, espero que elas acendam, porque
há energia suficiente para acendê-las. Gostaria que meus backups fossem assim tão
fáceis.
QUAIS TECNOLOGIAS DA EMC VOCÊ ESTÁ
USANDO? COMO ELAS MUDARAM O JOGO?
Uma das primeiras medidas que tomamos foi comprar sistemas EMC Data Domain,
mesmo antes de a EMC ter comprado a empresa. Nossa escolha ocorreu em função da
desduplicação. É claro que já tínhamos o Avamar, e ele tinha uma desduplicação
bastante boa. Ele é ótimo para fazer o backup de sistemas operacionais e desktops, e
tínhamos investido bastante nele para isso. Porém, para os bancos de dados,
precisávamos de algo com uma capacidade muito maior; por isso, passamos a usar o
Data Domain para nossos bancos de dados.
Sempre tivemos o NetWorker, que tornava os backups muito mais fáceis. Os DBAs
estavam acostumados a usar o RMAN para fazer backups, mas o RMAN precisa gravar
em um dispositivo de fita. Os sistemas operacionais normalmente não têm dispositivos
de fita integrados. Assim, o NetWorker atua como esse dispositivo de fita virtual para o
backup do RMAN, integrando-se totalmente. O DBA pode simplesmente iniciar um
backup, e o NetWorker, por meio dos nós de armazenamento, fará o backup, em nosso
caso, no dispositivo Data Domain. Essa integração é muito importante.
Uma das tecnologias mais recentes que estamos analisando é o DD Boost do Data
Domain. Ele também se integra ao RMAN. Assim o DBA pode usar seus backups RMAN
tradicionais e se beneficiar de um produto como o DD Boost, sem precisar saber nada
sobre o produto, mas com o controle em suas mãos.
Outro motivo por estarmos trabalhando arduamente na implementação do DD Boost é
que ele reduz os recursos necessários para fazer os backups, já que muito da
desduplicação é descarregada no próprio servidor de banco de dados. Então, passo a
enviar muito menos dados pela rede. Isso permitirá que eu faça o backup de muito mais
coisas de uma só vez, sejam bancos de dados ou sistemas operacionais. Porém, o mais
importante é que meus backups poderão ir um pouco mais longe. Então agora posso ter
uma infraestrutura que se adequará à mobilidade da computação em nuvem.
Outra coisa que estamos fazendo é usar os dispositivos Data Domain para fazer o backup
diretamente. Ou seja, podemos usar produtos como o VMware Data Director, configurar
alguns de nossos datastores como montagens NFS do Data Domain e simplesmente criar
clones do armazenamento e gravá-los diretamente no dispositivo Data Domain. Podemos
fazer a mesma coisa com ferramentas como Export ou Data Pump do Oracle ou ainda
backups manuais. No SQL Server, às vezes, só fazemos backups manuais do file system
que vão diretamente para o Data Domain.
EMC2, EMC e o logotipo da EMC são marcas registradas ou comerciais da EMC Corporation nos Estados
Unidos e em outros países. VMware é marca registrada ou comercial da VMware, Inc. nos Estados
Unidos e em outras jurisdições. © Copyright 2012 EMC Corporation. Todos os direitos reservados. 11/12
Folheto H11297.
http://brazil.emc.com
A EMC assegura que as informações apresentadas neste documento estão corretas na data da
publicação. As informações estão sujeitas a alterações sem prévio aviso.