Fundamentos de Redes de Armazenamento

250 Capítulo 7 Seção 3 Recuperação de Desastres e Backup na Nuvem Fazendo Backup na Nuvem Temos considerado as diferentes tecnologias de backup e técnicas em outros tópicos nesta publicação, e nesta seção focaremos em questões específicas relacionadas à nuvem. Em contraste com o backup tradicional, em que uma organização realiza o backup de dados armazenados localmente para dispositivos de backup locais, o backup na nuvem gira em torno do envio de cópias para um provedor de nuvem. Como acontece com a maioria dos serviços, há mais de um modelo possível. O primeiro deles é puro backup em nuvem, onde os dados locais são copiados diretamente para a nuvem do provedor de serviços. O segundo modelo é conhecido como backup de nuvem híbrida, onde os dados são copiados para um dispositivo de armazenamento intermediário que reside entre a sua infraestrutura e a nuvem. O dispositivo híbrido de nuvem oferece a vantagem de reter os dados localmente para suavizar o transporte para a nuvem em casos de Restores rápidos serem necessários. Muitas aplicações de backup agora têm a opção de restaurar os dados para a nuvem. Backup 'Puro' na Nuvem O principal benefício de um modelo 'puro' ou completo na nuvem é que é fácil de implementar, escalável e muito bem adequado para organizações que não possuem habilidades internas de departamento de TI. Os custos destes serviços normalmente rastreiam o uso e permitem às organizações a capacidade de modelar com precisão os seus custos de backup alinhados com o crescimento de dados de backup projetado. Isso pode remover a difícil tarefa de provisionar a totalidade os custos de armazenamento de backup local ao produzir projeções de orçamento.

251 As principais desvantagens do backup puro na nuvem é que ele é restringido pela largura de banda disponível entre o site principal dos clientes e o data center da nuvem. Para organizações com grandes (e talvez complexos) requisitos de backup, isso pode ser problemático. Da mesma forma, restaurar dados como parte de uma estratégia de DR pode ser impactado por conexões relativamente lentas entre o site dos clientes e o backup na nuvem. Backup de Nuvem Híbrida O backup de nuvem híbrida ocorre quando uma organização quer mitigar o desafio de uma conexão relativamente lenta com a nuvem, tendo um dispositivo de armazenamento intermediário localizado em seu site local. Este dispositivo intermediário pode ser, por exemplo, um appliance NAS que atua como um alvo de backup local e, em seguida, faz backup dos dados para uma nuvem externa. Esta abordagem tem a vantagem adicional de que os restores rápidos podem ser executados a partir deste appliance NAS local. Se uma estratégia de backup de armazenamento em camadas (por exemplo, avô, pai, filho*) for utilizada na nuvem, dados mais antigos podem ser restaurados para o appliance NAS a partir da nuvem. Quando um restore é necessário a partir de um backup recente, os dados estão prontos no local no NAS e podem ser rapidamente acessados. Alternativamente, restores a partir de conjuntos de backup externos baseados em nuvem podem ser acessados a partir do NAS no local e requisições restauradas a partir daí.

252 Opções de Backup em Nuvem Muitos fornecedores de software de backup agora incluem opções em seus produtos para backups em nuvem. A maioria (mas não todas) é focada na redução do impacto de conexões relativamente lentas entre o site do cliente e a nuvem. As opções incluem: – Criptografia fim a fim*, onde os dados não são apenas criptografados em trânsito para o provedor, mas também enquanto estão em repouso nas instalações do provedor; – Backup Incremental* onde apenas os dados que foram alterados desde o último backup completo são movidos para a nuvem; – Desduplicação* que elimina dados redundantes e repetidos antes de transmitir o backup para a nuvem; – Compressão de dados* que comprime o fluxo de dados (sempre que possível). Alguns fornecedores de hardware têm capacidades de aceleração de fita como recursos opcionais em directors Fibre Channel e switches usando conexões FCIP diretas para a nuvem. A operação acontece na camada de comando SCSI* e melhora as operações de backup/Restore, permitindo uma transmissão de dados mais rápida entre o host e o drive de fita sobre o link de rede WAN*. Considerações de Backup em Nuvem Ao considerar uma estratégia de backup que inclui o uso da nuvem, há algumas questões importantes que precisam ser consideradas. – A primeira é a segurança. É importante garantir que a criptografia fim a fim seja implementada, afinal de contas, todos os dados da organização estão sendo enviados a um terceiro. Criptografia fim a fim significa que os dados não só devem ser criptografados em trânsito para o provedor, mas também enquanto em repouso na instalação do provedor de serviços da nuvem. As organizações com dados altamente sensíveis também devem considerar a posse das chaves de criptografia* em seu data center, e não no provedor de serviços na nuvem (certifique-se de que as chaves estão em um lugar seguro, geralmente fora do local em caso de um evento importante); – Outro ponto de preocupação é a flexibilidade. Por exemplo, algumas organizações podem querer realizar a recuperação em uma instalação secundária de sua escolha em vez de ser forçado a recuperar para o seu site principal (no caso de alguma falha catastrófica, como uma inundação, um evento sísmico ou mesmo uma grande falha de energia). O provedor de serviços na nuvem deve ser capaz de manter o nível contratado de serviço de Restore para este local secundário; – O custo do backup na nuvem a longo prazo precisa ser considerado. As soluções de backup em nuvem tendem a oferecer baixos custos iniciais. Isso pode parecer muito atraente inicialmente, mas como os volumes de dados inexoravelmente irão crescer, o mesmo

253 acontece com o custo de backup baseado em nuvem, uma vez que a maioria dos provedores de serviços de nuvem cobram pelos volumes de dados que estão sendo armazenados e protegidos na nuvem. Backup dentro do data center próprio pode ter uma despesa inicial significativa, mas quando os volumes de dados crescem, os custos incrementais de aquisição de fitas extras são relativamente pequenos. Esta é uma decisão de custo/benefício e deve ser considerada antes de embarcar em qualquer estratégia de backup baseada em nuvem. Recuperação de Desastres como um Serviço (DRaaS) Introdução A Recuperação de Desastres como um Serviço (DRaaS - Disaster Recovery as a Service) não é um modelo de serviços reconhecido pelo NCITS - National Committee for Information Technology Standards (mais informações sobre os modelos normalizados NCITS podem ser consultadas em: http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf). DRaaS é um termo industrial para se referir a serviços específicos que os provedores de nuvem podem oferecer em qualquer um dos modelos padrão. É importante notar que este serviço normalmente baseia-se no backup de dados para a nuvem (para facilitar a recuperação de desastres). Isso não significa necessariamente incluir cláusulas de continuidade dos negócios (BC - Business Continuity), a localidade e estrutura para manter os elementos importantes de uma empresa funcionando enquanto uma recuperação de desastres é executada. Alguns provedores de DRaaS oferecem algum elemento adicional como serviço de continuidade de negócios, mas isso não é uma oferta de serviço amplamente oferecida.

254 Operação de DRaaS O DRaaS (com suporte a BC) permite aos usuários executar uma instância* de uma máquina virtual (VM)* no data center do provedor de serviços na nuvem. Esta VM é uma réplica da VM operacional no site principal dos clientes. Em caso de falha, a VM remota (na nuvem) pode ser usada no lugar da VM original, seja no local principal do cliente ou a partir de um local secundário (no caso de um evento importante no local primário). Assumindo que toda a questão da conectividade pode ser resolvida (um evento importante pode comprometer a conectividade), isso significa que os usuários podem estar de volta ativos em questão de minutos. Como os fornecedores de DRaaS alavancam a virtualização para fornecer esta funcionalidade, os servidores físicos do cliente podem precisar ser virtualizados ou o fornecedor de serviços na nuvem pode precisar ter capacidade de conversão física-virtual no seu lado. DRaaS - Considerações Operacionais É importante entender qual nível de desempenho pode ser esperado durante um grande evento de DR/BC. Dada a duração da interrupção e o tempo que levará para restaurar o data center primário do cliente, a aplicação pode estar em execução na VM do provedor da nuvem por algum tempo. É importante considerar se o provedor de nuvem pode se comprometer a cumprir um acordo de nível de serviço (SLA) com base no desempenho durante esse tempo. Como uma extensão desta questão, deve lembrar-se que no caso de um evento particularmente catastrófico (incêndio, inundação, evento sísmico) que tem consequências mais amplas ocorrendo, o provedor de serviços de nuvem terá que ser capaz de hospedar aplicações de muitas organizações simultaneamente em seu data center. No caso de um desastre regional, existe o potencial dos prestadores de serviços de nuvem serem sobrecarregados com pedidos de recuperação. Um SLA que cobre este tipo de situação pode precisar ser verificado para que o cliente esteja confiante em manter suas próprias prioridades de negócio. Caso todo o data center da organização seja destruído, a questão é como os dados do cliente serão recuperados. Em vez de esperar por um download sobre uma conexão relativamente lenta, pode ser mais eficiente obter as fitas de backup ou discos enviados a partir do provedor de serviços de nuvem para o local de recuperação para uma operação de recuperação local. Qualquer SLA com o prestador de serviços em nuvem deve incluir referência a este caso, caso seja necessário. * Abordado em mais detalhes em outra parte dessa publicação

255 Capítulo 7 Seção 4 Acordos de Nível de Serviços (SLAs) de Armazenamento e a Nuvem Introdução Um acordo de nível de serviço de armazenamento em nuvem (SLA) entre um fornecedor de serviço de armazenamento em nuvem e um cliente especifica detalhes do serviço a ser fornecido, geralmente em termos quantificáveis de entrega de serviço. Por exemplo, um SLA de armazenamento em nuvem pode exigir que o serviço tenha 99,9% de disponibilidade e a compensação na qual o usuário tem direito caso o provedor não consiga fornecer este nível de serviço. Níveis de Serviço Alguns provedores de serviços de armazenamento em nuvem fazem provisão para níveis de desempenho que podem ser esperados (por exemplo, quanto tempo um pedido de leitura de dados pode demorar, quantas tentativas são permitidas antes do nível de serviço ser considerado degradado, etc.). Questões como estas podem ser um \"grande problema\", a menos que sejam totalmente definidas em um SLA, uma vez que é necessário saber o quão degradado um serviço tem que estar antes que a compensação seja paga. Sem definição, isso seria um julgamento subjetivo e criaria, potencialmente, conflitos legais. Compensação Qualquer SLA deve definir as condições para compensar os clientes, caso as especificações não sejam cumpridas. Alguns prestadores de serviços de armazenamento em nuvem oferecem créditos com base na discrepância entre as especificações do SLA e os níveis de serviço reais entregues, não o reembolso real de dinheiro! Qual Prestador de Serviços? Os serviços públicos de armazenamento em nuvem são susceptíveis de fornecer um nível de serviço padronizado e pré-definido, que provavelmente será o mesmo para todos os usuários. No entanto, uma empresa que estabelece um serviço com um provedor de armazenamento privado em nuvem pode ser capaz de negociar um acordo mais personalizado. Se uma organização requer um SLA que exija serviços como políticas específicas de retenção e onde os dados devem ser armazenados, isso pode exigir o trabalho com um prestador de serviços de nuvem especializado (privado).

256 Considerações Alguns prestadores de serviços de armazenamento podem cobrar um adicional por cópias geograficamente dispersas de dados, a fim de garantir que as questões de regulamentação e conformidade não sejam comprometidas por um local que sofra um grande desastre (por exemplo, incêndio). Outro desafio é que múltiplas cópias não protegem um cliente dos pedidos mais comuns de recuperação, tais como restaurar dados que foram corrompidos pelo usuário ou um erro do lado do cliente. Cópias remotas somente replicam o problema. Da mesma forma, quaisquer dados que sejam apagados no site do cliente antes de serem copiados para a nuvem não podem ser recuperados, não importando quantas cópias estejam disponíveis em todo o mundo. Esta questão só pode realmente ser tratada através do uso de cópias* de ponto no tempo. Isto terá de ser alcançado no local de origem do cliente (exigindo competências e investimento) ou como parte do serviço de nuvem (encargos adicionais). Leia Atentamente Assim como acontece com todos os acordos legais, os grandes problemas podem residir nos detalhes. Por exemplo, se um prestador de serviços oferece um tempo de funcionamento garantido (por exemplo, 99,9%), é importante compreender o que isso realmente significa. É importante entender em que momento o relógio começa a contar para medir o tempo de inatividade. Pode ser escrito no SLA que o tempo de inatividade medido não começa a contar até que, talvez, 10 ou 15 minutos tenham decorridos desde que o cliente teve pela última vez acesso ao seu armazenamento de dados. Neste cenário, poderia haver múltiplas interrupções de 8 ou 9 minutos e isso manteria o nível de serviço dentro dos Termos do SLA. É importante lembrar, ao considerar uma solução de armazenamento em nuvem, que os serviços em nuvem inicialmente evoluíram como serviços genéricos oferecidos a um mercado consumidor, ao invés de ofertas especializadas para usuários de negócios. Isto significa que, cada vez que qualquer coisa fora da oferta genérica seja necessária, poderá haver um custo adicional (cópias adicionais, localização específica, frequência de backup, etc.).

257 Sumário Em resumo, estabelecer um SLA de armazenamento de dados eficaz com um provedor de nuvem requer algum pensamento estratégico e análise custo antes de prosseguir. Uma estratégia bem planejada será boa para o cliente e para o provedor de serviços e pode pagar por si mesmo a médio e longo prazo. Os usuários precisam entender completamente no que estão se metendo ao enviar os dados para a nuvem e, acima de tudo, entender todas as cláusulas, incluindo as letras miúdas do SLA antes de se comprometer. * Abordado em mais detalhes em outra parte dessa publicação

258 Referências Aqui está uma lista de referências independente de fornecedores de redes de armazenamento. Há muitos outros geralmente em sites patrocinados por fornecedores de hardware/software. http://www.snia.org/education/dictionary http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf http://fibrechannel.org/

259 \"Sam\" Samuel, tem décadas de experiência na indústria de TI e, ao longo de muitos anos, especializou-se em armazenamento de dados. Com sede no Reino Unido, Sam tem mais recentemente produzido e ministrado treinamentos para grandes empresas de TI em todo o mundo. Seu início de carreira foi no exército, onde seu foco principal estava no rádio e no radar. Desde então, ele trabalhou internacionalmente como engenheiro de campo e de suporte para alguns dos maiores nomes na indústria de TI. Sam tem se envolvido com a SNIA (Storage Network Industry Association) desde seus primeiros dias e foi fundamental na criação do primeiro programa de certificação SNIA. Este esforço em apoio à SNIA resultou em um prêmio reconhecendo o excelente serviço de Sam para a educação de redes de armazenamento. A característica do trabalho de Sam é a capacidade de pegar questões técnicas complexas e apresentá-las de uma forma fácil de entender. Ed Frymoyer é empresário e fundador da FMJO, LLC, dba Infinity I/O(IIO) e tem sido líder em redes de armazenamento e educação de redes de armazenamento por mais de três décadas. A IIO fornece os principais materiais de treinamento para educação e certificação de redes de armazenamento em todo o mundo. Ele tem sido um membro ativo do comitê SNIA EdComm e tem atuado como gerente e trabalhado em grandes empresas nas indústrias de Informática e Telecomunicações. Ele é membro de vários conselhos universitários. Ed tem um PhD em Física e pós-graduação em Engenharia Elétrica.