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 nos nossos negócios. "Se a sua infraestrutura de backup não consegue acompanhar a explosão de dados nem manter o ritmo da mobilidade da cloud computing, a sua base de dados irá sofrer... Portanto, é absolutamente importante garantir que a sua infraestrutura de backup seja muito mais ágil e dinamicamente dimensionável do que ela é hoje."―Darryl Smith Smith, que é responsável por todas as bases 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 oferece-nos a sua visão da salvação do backup. Para obter mais informações e recursos, visite www.emc.com/BackupLeader. ENQUANTO ARQUITETO DE ORACLE, POR É O BACKUP IMPORTANTE PARA A SUA TRANQUILIDADE? Sou responsável por garantir que as bases de dados da EMC se encontram íntegras, ativas e a funcionar e são capazes de atender os nossos utilizadores empresariais, de modo a que estes recebam a informação necessária. Se eu ou a minha equipa não trabalharmos, tudo irá parar. Se a base de dados que sustenta a aplicação de CRM, a aplicação de apoio ao cliente ou qualquer aplicação que esteja a executar não funcionar, a sua aplicação não irá funcionar. Para que eu faça o meu trabalho, o backup é essencial. Uma das principais dificuldades no início de nossa jornada para a cloud era o facto de que a nossa infraestrutura de backup não estava a acompanhar o ritmo. Dependíamos de infraestruturas legadas e de soluções de backup ponto a ponto. Isso era um problema para a minha tranquilidade — e continua a ser um problema para muitas organizações hoje em dia. 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 CLOUD? Exato. Se a sua infraestrutura de backup não consegue acompanhar a explosão de dados nem manter o ritmo da mobilidade da cloud computing, a sua base de dados irá sofrer. FOLHETO Isso poderia significar qualquer coisa, desde a redução na performance da aplicação até a perda de dados ou até mesmo a falha total da aplicação, o que obviamente seria crítico para uma empresa. Portanto, é absolutamente importante garantir que a sua infraestrutura de backup seja muito mais ágil e dinamicamente dimensionável do que ela é hoje. O QUE FEZ NOS ÚLTIMOS DOIS ANOS PELA TRANSFORMAÇÃO DO BACKUP? Hoje, do ponto de vista do servidor, estamos 94% virtualizados. Do ponto de vista da base de dados, estamos aproximadamente 84% virtualizados e agora estamos a virtualizar com a maior rapidez 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 o nosso agendador de backup, o EMC NetWorker, e em dispositivos de tape ou disco — dispositivos de tape virtual com disco de reserva. As tapes, obviamente, são uma tecnologia muito antiga, por isso foram substituídas por bibliotecas de tape virtual. Mas mesmo essas não eram escaláveis, por isso medimos, quantificamos e restringimos constantemente a utilização destes recursos. Este era realmente o nosso principal problema: Tínhamos um número limitado de recursos e um número cada vez maior de bases de dados, além de um volume cada vez maior de dados que precisavam de backup. Para acompanhar a nossa virtualização, basicamente abandonámos todas as nossas plataformas legadas. Até os nossos nós de armazenamento do NetWorker foram virtualizados. EM QUE PONTO SE ENCONTRA ATUALMENTE A SUA TRANSFORMAÇÃO DO BACKUP? Agora, 24 meses depois, estamos a avançar para o dimensionamento da nossa infraestrutura. Os nossos dispositivos de tape são coisa do passado, e estamos a substituir os de tape virtual por dispositivos Data Domain, que têm muita mais capacidade e throughput e podem armazenar dados por muito, mas muito mais tempo graças à deduplicação. Essa primeira etapa realmente ajudou na redução das restrições na nossa capacidade. Agora sabemos que, se precisarmos de recuperar um backup, poderemos recuperá-lo muito rapidamente e não teremos de depender de tapes e armazenamento em outros locais. Porém, ainda estamos a gerir o backup como se tivéssemos essas antigas restrições, e é aí que realmente precisamos de começar a levar as coisas para o próximo nível. Também trabalhamos na "base 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 os 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 irá ocorrer, porque removemos as variáveis. Estamos a fazer o mesmo com algumas das nossas bases de dados com maior dimensão. Trabalhámos com as equipas de backup e projetámos um backup descarregado. O que quero dizer é que pegamos num clone do armazenamento, montámo-lo num servidor proxy ou num nó de armazenamento do NetWorker e fazemos o backup da base de dados a partir daí. Nesse caso, o backup da base 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 a alta velocidade. Esses são dois exemplos do que estivemos a trabalhar com a equipa de backup a fim de fornecer um backup que seja realmente confiável e dimensionável, que essencialmente podemos configurar e esquecer. PARECE QUE ESTÁ A TRABALHAR DE MODO DIFERENTE COM A SUA EQUIPA DE BACKUP. COMO MUDARAM OS PROCESSOS? A substituição da nossa infraestrutura é somente um ponto de partida na transformação do modo de funcionamento da nossa infraestrutura de backup. Realmente precisamos de trabalhar mais nos processos e procedimentos. É bom ter, por exemplo, um agendador que abranja toda a empresa. Mas tentar gerir manualmente componentes e recursos individuais atrapalha a capacidade de dimensionar dinamicamente, não permitindo ter a agilidade que a cloud computing exige. A verdadeira chave para essa transformação total é reunir todos esses grupos, membros e habilidades individuais num conjunto maior de habilidades. Falamos sobre isso constantemente quando falamos sobre a transformação da TI, que todas as habilidades precisam de ser reunidas. Isso não significa necessariamente que uma pessoa tem de saber tudo, mas que as pessoas com diferentes conjuntos de habilidades precisam de trabalhar em sintonia para realmente se tornarem parte dessa equipa central de arquitetura e, ao mesmo tempo, partilharem o conhecimento. COMO MUDARAM AS RELAÇÕES COM A EQUIPA DE BACKUP? Bem, o relacionamento estava a ficar tenso. Estávamos a ter muitas dificuldades com os backups, e as equipas de backup estavam constantemente a lidar com problemas. A tensão estava realmente nos dois lados — tanto a equipa de backup quanto os DBAs estavam muito frustrados. Eles estavam a lidar com questões quotidianas e a solucionar problemas constantemente. Isso era um problema constante e não só dificultava os relacionamentos mas também a nossa capacidade de oferecer um serviço aos nossos utilizadores empresariais. A equipa de backup tem atuado, tipicamente, nos bastidores. 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 já não funciona. A equipa de backup realmente precisava de ser uma parte maior da equipa de TI e ajudá-la na transformação geral. Se não for assim, terá problemas. As suas bases de dados não funcionarão como deveriam — perderão tempo na tentativa de gravar os backups. Em caso de falha, não conseguirá recuperar os seus sistemas nem dados. Mais do que nunca, o backup realmente tem de ser uma prioridade. QUAL É A DIREÇÃO QUE ESTÁ A TOMAR? O QUE É A SALVAÇÃO DO BACKUP PARA SI? Bem, não usamos 100% de backup como serviço hoje, nós usamo-lo de modo limitado. Por exemplo, todas as nossas outras ofertas de TI como serviço, infraestrutura como serviço, bem como as nossas ofertas de bases 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 da nossa infraestrutura de backup é que os seus administradores se tornem responsáveis pela infraestrutura e pelo planeamento da capacidade a fim de garantir que exista capacidade suficiente. Quanto a mim, como consumidor, como o DBA que está a consumir esses serviços de backup, preciso de ser capaz de configurar os meus próprios backups, executá-los quando eu quiser e poder fazer recuperações conforme necessário sem ter que depender de outro grupo para garantir que tudo esteja a funcionar. Portanto, o meu ideal é executar uma consola onde eu possa agendar todos os meus backups de bases 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 os meus backups fossem assim tão fáceis. QUAIS TECNOLOGIAS DA EMC ESTÁ A UTILIZAR? COMO MUDARAM ELAS O JOGO? Uma das primeiras medidas que tomámos foi comprar sistemas EMC Data Domain, mesmo antes da EMC ter comprado a empresa. A nossa escolha ocorreu em função da deduplicação. É claro que já tínhamos o Avamar, e ele tinha uma deduplicaçã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 as bases de dados, precisávamos de algo com uma capacidade muito maior; por isso, passamos a usar o Data Domain para as nossas bases 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 de gravar num dispositivo de tape. Os sistemas operacionais normalmente não têm dispositivos de tape integrados. Assim, o NetWorker atua como esse dispositivo de tape 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, no nosso caso, no dispositivo Data Domain. Essa integração é muito importante. Uma das tecnologias mais recentes que estamos a analisar é o DD Boost do Data Domain. Ele também se integra ao RMAN. Assim o DBA pode usar os seus backups RMAN tradicionais e beneficiar de um produto como o DD Boost, sem precisar de saber nada sobre o produto, mas com o controlo nas suas mãos. Outro motivo para estarmos a trabalhar arduamente na implementação do DD Boost é que ele reduz os recursos necessários para fazer os backups, já que muito da deduplicação é descarregada no próprio servidor de base de dados. Então, passo a enviar muito menos dados pela rede. Isso permitirá que eu faça o backup de muitas mais coisas de uma só vez, sejam bases de dados ou sistemas operativos. Porém, o mais importante é que os meus backups poderão ir um pouco mais longe. Portanto agora posso ter uma infraestrutura que se adequará à mobilidade da cloud computing. Outra coisa que estamos a fazer é usar os dispositivos Data Domain para fazer o backup diretamente. Ou seja, podemos usar produtos como o VMware Data Director, configurar alguns dos 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 sistema de ficheiros que vão diretamente para o Data Domain. EMC2, EMC e o logótipo da EMC são marcas registadas ou comerciais da EMC Corporation nos Estados Unidos e em outros países. VMware é marca registada ou comercial da VMware, Inc. nos Estados Unidos e em outras jurisdições. © Copyright 2012 EMC Corporation. Todos os direitos reservados. Publicado nos EUA. 11/12 Folheto H11297. www.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 aviso prévio.