Serviços de cópia de segurança
Nada dá mais medo ao pessoal de TI do que a perda de dados. A estratégia mais eficaz de prevenir a perda de dados é fazer uma cópia de segurança dos volumes de armazenamento, máquinas virtuais, bases de dados e outros sistemas que armazenam dados, para que os respetivos dados possam ser restaurados. Os fornecedores de serviços cloud oferecem serviços de cópias de segurança para este fim. De um modo geral, estes serviços podem ser utilizados para fazer cópias de segurança de dados armazenados no local, bem como de dados armazenados na cloud e as cópias de segurança podem geograficamente replicadas e dispersas para evitar eventos resultantes na perda de dados em todo um datacenter ou região do mundo.
A cloud pública proporciona recursos fluidos em elevado volume (não apenas grandes segmentos de armazenamento, mas agrupamentos de armazenamento altamente dimensionáveis). São, pelo menos, tão versáteis e, em alguns casos, mais versáteis do que os sistemas de armazenamento de cópias de segurança e as unidades de banda que estão a substituir. Além disso, estão a dar novas oportunidades às organizações para implementar redundâncias, ativações pós-falha e redes de segurança inacessíveis para muitos quando todos os recursos eram comprados a partir de capital de trabalho. As opções de armazenamento na cloud pública desempenham uma função que os datacenters sempre necessitaram, mas que tinha sido difícil de obter até recentemente.
Serviços de cópias de segurança com base na cloud
O que caracteriza os serviços de cópias de segurança modernos oferecidos pelos fornecedores de serviços cloud públicos (CSP) é a forma como alargam a infraestrutura dos seus clientes. Antes do aparecimento destes serviços, a estratégia de cópia de segurança das organizações tinha dois escalões: criar cópias de segurança de volumes de dados que alojavam bases de dados e criar cópias de segurança de imagens de máquinas virtuais que alojavam cargas de trabalho fundamentais. A teoria por detrás das cópias de segurança era que um evento causa uma falha num servidor quando ocorre uma falha no sistema. Nesta situação, a melhor medida a tomar era restaurar o estado desse servidor a partir de uma imagem de uma cópia de segurança.
A infraestrutura baseada na cloud torna obsoleta a teoria das cópias de segurança. Nos sistemas modernos, os servidores são constituídos por software e não hardware. Os servidores virtuais são alojados por uma infraestrutura virtual baseada no hipervisor, como o NSX do VMware, ou montados em contentores e alojados por sistemas operativos virtuais. Em ambos os casos, as imagens de software das cargas de trabalho das aplicações e dos serviços são geridas, atualizadas e protegidas de forma contínua. Os componentes de software ativos são réplicas dessas instâncias originais seguras ou, no que toca à contentorização, são os produtos das instâncias originais armazenadas em repositórios de contentores montados automaticamente conforme necessário. Uma falha de hardware que feche um nó de servidor indisponibiliza os servidores alojados por esse nó durante algum tempo. A infraestrutura reencaminha o tráfego do nó e tenta substituí-lo. O gestor de infraestruturas não está a fazer nada que ainda não tenha feito no processo normal de administração do sistema.
No entanto, como uma análise rápida dos datacenters modernos pode revelar, nem todas as infraestruturas modernas são baseadas na cloud. Alguns serviços continuam a ser alojados em datacenters bare-metal no local. As redes cliente/servidor completas com middleware continuam a existir em abundância. Num sistema híbrido, onde uma parte criada há alguns anos está ligada a outra parte criada no século passado, continua a ser necessário armazenar informações suficientes sobre todas as partes do mesmo. Deste modo, se ocorrer um desastre, o sistema pode ser restaurado de forma prática e rápida numa nova localização com um impacto mínimo nos níveis de serviço. Com as estratégias de cópia de segurança modernas, a cloud pública pode ser essa localização, mesmo que o sistema esteja alojado fora da cloud.
AWS Backup
No início de 2019, o Amazon Web Services recriou o respetivo serviço de cópias de segurança baseado na cloud para os ambientes híbridos na cloud dos clientes. No centro do novo AWS Backup, cuja consola baseada no browser é apresentada na Figura 2, está um motor de política semelhante ao árbitro das regras de uma firewall. Com este motor, o administrador das cópias de segurança escreve regras que especificam os seguintes aspetos:
Os recursos num sistema que necessitam de cópias de segurança
Como e com que frequência deve ser criada cada cópia de segurança
O local onde as imagens das cópias de segurança devem ser armazenadas
Como e com que frequência a integridade das imagens das cópias de segurança devem ser monitorizadas
Durante quanto tempo as imagens das cópias de segurança devem ser armazenadas
As circunstâncias sob as quais deve ser efetuada a recuperação e o restauro
O itinerário completo com todas as políticas ativas é conhecido como o plano de cópias de segurança. Nesse plano, cada regra aplica-se aos recursos na cloud do AWS que requerem uma cópia de segurança em conformidade com o valor da respetiva etiqueta, que é um nome aleatório dado pelo administrador. Para incluir um recurso como um volume do Elastic Block Storage (EBS) num plano de cópias de segurança, o respetivo administrador só precisa de atribuir ao recurso um nome de etiqueta que o AWS Backup reconheça. Deste modo, o administrador ou a pessoa responsável pelos recursos do AWS não tem de utilizar a consola do AWS Backup para estabelecer um recurso dentro das competências dessa pessoa como parte de um plano de cópias de segurança existente.
![Figure 2: The AWS Backup console. [Courtesy Amazon]](../../cmu-cloud-admin/cmu-disaster-recovery-backup/media/fig9-2.png)
Figura 2: O console do AWS Backup. [Cortesia Amazon]
Os recursos no local podem ser incorporados num plano de cópias de segurança através do Gateway de Armazenamento do AWS. Com o AWS Backup, o Gateway de Armazenamento funciona como um wrapper da API nos dispositivos e volumes de armazenamento físico, o que os torna acessíveis aos serviços do AWS.
Originalmente, o Gateway de Armazenamento permitia substituições de recursos existentes no armazenamento físico pelos recursos equivalentes baseados na cloud através da mesma interface. Por exemplo, um volume iSCSI no local pode ser encapsulado num local que o AWS chama volume colocado em cache. Este wrapper torna o armazenamento na cloud acessível às aplicações existentes no local sem que os clientes tenham de voltar a conceber essas aplicações. Os dados frequentemente acedidos podem continuar a ser armazenados no volume iSCSI como uma cache, o que reduz a latência. Em alternativa, as alterações recentes aos conteúdos do volume do gateway podem ser armazenadas localmente como instantâneos. No entanto, o Gateway de Armazenamento também suporta volumes armazenados. Nestes volumes, o dispositivo no local continua a manter uma cópia local completa do volume e o Gateway de Armazenamento espelha essa cópia na cloud. O novo AWS Backup tira partido da troca de funções do Gateway de Armazenamento com os volumes físicos e transforma a cópia local na cópia de segurança do volume baseado na cloud. Além disso, adiciona uma consola de gestão de política centralizada com regras que gerem o armazenamento de ambas as réplicas.
No caso da recuperação após desastre, um dos maiores benefícios de um CSP é a capacidade de arquivar rapidamente os dados fundamentais de uma organização em localizações distantes, de modo a obter redundância geográfica ou georredundância. O AWS funciona com datacenters da cloud no maior número de zonas de disponibilidade para qualquer CSP. Promove a capacidade nativa de as aplicações alojadas efetuarem automaticamente uma ativação pós-falha para alternarem entre zonas. Esta capacidade também se aplica à redundância de cópias de segurança de dados. No entanto, as zonas de ativação pós-falha são conhecidas por residirem na mesma região do AWS. Numa situação de desastre extremo (que as seguradoras e, por conseguinte, os gestores de riscos têm em conta), como uma falha de fornecimento de energia, podem ocorrer falhas nas zonas de disponibilidade adjacentes.
Um programador de software ou um operador de TI com experiência em programação pode escrever políticas personalizadas para o encaminhamento de georredundância específico de uma organização que utilize o serviço de encaminhamento de baixo nível do AWS, o Route 53. No entanto, este método é muito trabalhoso. Recentemente, o AWS tem oferecido um serviço mais acessível denominado AWS Global Accelerator, que é outro motor de política que guia o tráfego e orienta o Route 53 quanto ao local onde os serviços e o armazenamento devem ser alojados.1 O Global Accelerator também pode ser visto como um "super-balanceador" que permite a distribuição de vários sites para aplicações alojadas (e dados fundamentais) entre zonas de disponibilidade dispersas.
Outra forma de garantir que as cópias de segurança dos dados são armazenadas numa região suficientemente distante, como sugerido pelos técnicos da Amazon, é estabelecer um registo (contentor de cópias de segurança geral do AWS) como o destino inicial para as cópias de segurança e replicar esse registo para uma localização redundante em qualquer zona de disponibilidade designada. O AWS oferece a Replicação Entre Regiões (CRR) como um serviço separado.2 O AWS atribui um preço ao serviço de cópias de segurança de acordo com o volume por gigabyte armazenado e por gigabyte restaurado.
Numa perspetiva de arquitetura, o AWS Backup foi concebido para espelhar os recursos do AWS. Pode tornar os recursos no local parte desse plano através de duas ações. Em primeiro lugar, ao converter esses recursos locais em volumes remotos do AWS (remotos na perspetiva da Amazon) e, em segundo lugar, incluir a interface do AWS Backup com o wrapper nesses recursos locais.
Azure Backup
O Azure Backup é igualmente capaz de criar cópias de segurança de recursos no local (servidores e máquinas virtuais) e de recursos alojados no Azure. Não visa alterar a política de cópias de segurança no datacenter. Tem apenas como objetivo substituir as unidades de banda e os discos locais pelo armazenamento na nuvem. A localização baseada na cloud para as cópias de segurança de ficheiros e volumes no Azure é denominada Cofre de Serviços de Recuperação. A respetiva consola baseada no browser é apresentada na Figura 3. Durante o processo de configuração deste cofre através do portal do Azure, o administrador transfere e instala o agente do lado do cliente conhecido como agente dos Serviços de Recuperação do Microsoft Azure ou "MARS". No Windows Server, o MARS é executado como um aplicativo, parecendo muito com um complemento do System Center. (Como alternativa, um administrador pode preferir usar o System Center Data Protection Manager, onde a funcionalidade MARS já está incorporada.) O administrador localiza os volumes e serviços na rede cujos dados requerem backup e o MARS distribui seus agentes para os endereços de servidor responsáveis por esses componentes.
![Figure 3: The console for Azure Recovery Services Vault. [Courtesy Microsoft]](../../cmu-cloud-admin/cmu-disaster-recovery-backup/media/fig9-3.png)
Figura 3: O console do Cofre dos Serviços de Recuperação do Azure. [Cortesia Microsoft]
O modelo de entrega do Azure Backup é baseado nos objetivos ao nível do serviço para a recuperação após desastre. Estes fornecem métricas razoáveis para determinar durante quanto tempo uma organização não pode ter acesso ao motor do seu negócio e quantos dados pode perder num evento de desastre. Estes objetivos específicos (RPO, RTO e retenção) serão abordados na próxima lição sobre a recuperação após desastre.
O tipo de recuperação utilizado pelo Azure Backup (contrariamente ao do Azure Site Recovery, o serviço de recuperação após desastre da Microsoft) é totalmente baseado na replicação de dados e não no serviço de restauro. Por exemplo, um cliente pode utilizar o Azure Backup para produzir réplicas de ficheiros de imagem de máquinas virtuais (VHD). No entanto, o restauro de um VHD reproduz novamente o ficheiro de imagem arquivado no armazenamento local e não reinicia o servidor virtual baseado no VHD.
O Azure Backup cobra apenas o espaço de armazenamento consumido mensalmente sem taxas adicionais pelos restauros. O respetivo modelo de preços está ligado às opções de redundância. Atualmente, o Azure oferece duas dessas opções: Armazenamento Localmente Redundante (LRS), que é o mais barato e replica dados três vezes dentro de um data center do Azure, e Armazenamento com Redundância Geográfica (GRS), que replica dados em uma região secundária geograficamente distante da região primária.
Cópias de segurança do Google Cloud Storage
A Google oferece vários escalões do Cloud Storage com base na classe dos dados armazenados (por exemplo, ficheiros persistentemente disponíveis, armazenamento de blocos para imagens de máquinas virtuais e armazenamento de objetos para vídeos). Não promove explicitamente um serviço de cópias de segurança de marca para qualquer um dos escalões, embora os serviços de armazenamento possam ser (e são) utilizados para fins de criação de cópias de segurança e recuperação. A Google assume que as cópias de segurança são um dos principais motivos pelos quais as empresas investem em armazenamento na cloud em grandes volumes.
![Figure 4: The contents of a Google Cloud Storage bucket. [Courtesy Google]](../../cmu-cloud-admin/cmu-disaster-recovery-backup/media/fig9-4.jpg)
Figura 4: O conteúdo de um bucket do Google Cloud Storage. [Cortesia Google]
Tal como o AWS, a Google denomina o respetivo contentor de armazenamento geral registo. A Figura 4 mostra um passo do processo de importação de dados do armazenamento local para um registo do Google Cloud Storage (GCS). A forma como baseia o respetivo modelo de entrega em três parâmetros é semelhante à do Azure. Os parâmetros fundamentais do GCS são:
Desempenho: neste contexto, é sinónimo de disponibilidade (quão rápido os servidores respondem aos pedidos de leitura de dados dos clientes)
Retenção: quanto tempo o cliente espera manter os dados armazenados na cloud
Padrões de acesso: relacionados com a acessibilidade (frequência com que o cliente espera ler ou recuperar os dados armazenados)
Ao inicializar um registo, o cliente do GCS escolhe a respetiva classe de armazenamento, que especifica a política de replicação. Quando o registo começar a ser utilizado para cópias de segurança, esta escolha irá determinar a dispersão dos dados armazenados. Atualmente, o GCS oferece três opções de geolocalização:
Regional: armazenamento apenas numa região específica do território do serviço Google
Birregional: replicação em dois territórios selecionados do serviço
Multirregional: distribuição redundante em vários territórios do serviço
Em seguida, o GCS subdivide as respetivas classes de armazenamento de registos com base na frequência de acesso:
Disponibilidade Padrão/Elevada: dados rapidamente acessíveis para as aplicações e utilizadores
Coldline: permite ao cliente trocar parte das taxas de armazenamento mensal pelos custos de acesso e transferência. Aplica-se aos dados que são acedidos apenas algumas vezes por ano
Nearline: troca de meio-termo para dados acedidos cerca de uma vez por mês
A abordagem da Google para promover a respetiva infraestrutura de cloud às empresas é apresentar os serviços como um tipo de aplicação não visível. Pode ser mais difícil para a Google oferecer a aplicação e o respetivo método de utilização como serviços separados, como vender um forno e uma subscrição de cozinha como suplemento.
Deste modo, a organização cliente do GCS seleciona a infraestrutura necessária para os trabalhos planeados e personaliza as definições dessa infraestrutura como funcionalidades de uma aplicação. (Como a AWS e o Azure, o Google oferece um dispositivo de montagem em rack para data centers com a finalidade expressa de transferência de alta velocidade entre armazenamento local e em nuvem.) Esses recursos podem ser ajustados ao longo do tempo, dependendo de como o uso desse armazenamento muda. Por exemplo, imagine que uma empresa produtora de vídeos necessita de uma grande quantidade de armazenamento de cópias de segurança para várias versões de um filme que está a ser editado. Durante o processo de edição, essas cópias podem ser obtidas frequentemente, logo o cliente pode definir o registo como armazenamento Padrão no território Regional. Quando o vídeo for concluído e publicamente distribuído, poderá ser necessário manter cópias para o ano seguinte, embora possa não aceder às mesmas com frequência. Nesse caso, o registo Standard pode ser transferido para um registo Coldline com território Birregional para fins de arquivo e segurança.
Referências
Amazon Web Services, Inc. Gerenciamento de tráfego com o AWS Global Acceleratorhttps://aws.amazon.com/blogs/networking-and-content-delivery/traffic-management-with-aws-global-accelerator/.
Amazon Web Services, Inc. Visão geral da configuração da replicaçãohttps://docs.aws.amazon.com/AmazonS3/latest/dev/replication-how-setup.html.