Fundamentos de Redes de Armazenamento

200 Archiving O backup inclui dados operacionais que estão em constante mudança e cujo objetivo é restaurar em um ponto no tempo. Por comparação, o archiving é composto por dados que nunca devem mudar e, se houver alteração, devem deixar um registro para auditoria - normalmente para cumprir as obrigações legislativas, regulatórias e de compliance. O archiving pode ser acompanhado por uma estratégia de limpeza onde os dados operacionais que deixaram de ser úteis, como dados ativos, podem ser arquivados de acordo com regras pré- definidas. O período na qual os dados são retidos tem de ser definido corporativamente. As tecnologias e processos tipicamente associados ao archiving incluem: Content Addressable Storage (CAS) ou Armazenamento Associativo - a alteração de dados cria automaticamente um novo identificador exclusivo para eles, mantendo os dados que não foram alterados com seu identificador exclusivo original. O efeito disto é deixar um registro para auditoria de quaisquer alterações (trata-se de erradicar as tentativas de alterar retroativamente as informações que podem conduzir a consequências legais ou regulamentares). A tecnologia utilizada é tipicamente disco WORM (Write Once Read Many - Grave uma Vez Leia Várias), Fita (opcionalmente WORM) ou armazenamento ótico. Espelhamento O espelhamento requer fazer uma cópia completa dos dados primários e armazená-los em um sistema de disco secundário. Se um sistema de disco falhar, os dados permanecem disponíveis no outro sistema de disco. O espelhamento não protege contra corrupção dos arquivos de dados ou ataque de vírus, pois todos os dados - bons ou ruins - são espelhados. Ponto no Tempo (PiT) O termo ponto no tempo é muitas vezes chamado de snapshot ou ceckpoint. Em intervalos regulares, os metadados ou ponteiros dos dados armazenados são copiados para a memória. Antes de qualquer dado ser alterado no snapshot, os dados originais são salvos em outro lugar no dispositivo de armazenamento de dados. Se ocorrer um erro durante o processo, você pode voltar para o último snapshot e recuperar os ponteiros armazenados naquele momento. É importante entender que existe apenas uma cópia dos dados, de modo que outra proteção, como espelhamento ou backup, pode ser aconselhável. As vantagens de usar uma cópia PiT é que oferece proteção de dados contínua, pois todas as mudanças de dados são registradas, o que significa que podemos voltar para qualquer ponto no tempo. A frequência com que uma cópia PiT é feita depende da política definida para atender as prioridades e requisitos organizacionais.

201 Siglas Comuns CDP - Proteção Contínua de Dados (Continuous Data Protection) D2T - Disco para Fita (Disk to Tape) -movendo informação de disco para fita - modelo de backup tradicional D2D - Disco para Disco (Disk to Disk) - permite rapidez nos processos de backup e Restore, uma vez que já está em um formato utilizável. D2D2T- Disco para Disco para Fita (Disk to Disk to Tape) - é usado para backup em fases, dando rapidez ao processo. Efetivamente, temos dados primários, uma cópia secundária dos nossos dados em um ponto no tempo (em disco) e então usamos a cópia de ponto no tempo para criar uma terceira cópia (em fita). 3PC - 3rdParty Copy - remove todos os servidores do fluxo de dados de backup, usando um appliance.

202 Capítulo 6 Seção 2 Técnicas e Tecnologias de Backup em Fita Introdução O backup e o Restore referem-se à criação e retenção de cópias de dados operacionais a serem usados como uma fonte de dados, com o único propósito de restaurar dados específicos ou completos do sistema, após uma simples perda de dados ou uma falha completa do sistema. A política de backup de uma organização deve ser baseada em prioridades definidas pelo negócio (como deve ser feito o backup dos dados, quais dados devem ser restaurados rapidamente em caso de falha, etc.). É só depois disto definido que uma solução eficaz de backup pode ser implantada. O Desafio do Backup O maior desafio do backup, que existe em qualquer ambiente empresarial, é o grande volume de dados existentes e a janela de tempo para se realizar o backup. O desafio é que estamos nos movendo em direções opostas - os dados estão crescendo e a janela do tempo está encolhendo. As organizações não tem apenas operações 9x5 (9 horas/dia, 5 dias/semana), sem atividade durante a noite, quando os backups podem ser executados. O desafio do backup é 'podemos ter dados suficientes copiados para um local alternativo dentro de uma janela específica' e, nesta seção, vamos considerar algumas das opções disponíveis.

203 Backup versus Archiving A diferença entre os dados copiados para fins de archiving e dados copiados para backup é que o material arquivado é formado por dados imutáveis, copiados e armazenados apenas para referência, enquanto os dados de backup são dinâmicos e refletem as mudanças de estado dos sistemas de armazenamento de dados primários. Existem várias opções de tecnologia para fazer o backup de dados, dependendo dos requisitos do RPO/RTO. Mídia de Backup A tecnologia mais amplamente utilizada é o backup em fita. A fita continua a ser usada como um meio de backup. Ao contrário dos discos, o meio de dados, a fita, é separado do mecanismo de leitura e gravação – assim, a falha do mecanismo não impacta a capacidade de acessar os dados, o que não acontece se o armazenamento em disco for usado. A desvantagem potencial para a fita é que é uma tecnologia de acesso sequencial, perdendo da capacidade de acesso aleatório da tecnologia de disco. Em alguns casos, o backup é feito em um sistema de armazenamento de disco. A fim de se manter a compatibilidade com o software de backup existente, estes sistemas de disco emulam unidades de fita e são conhecidos como fitas virtuais. O backup D2D (disco para disco) também é usado, sem emulação de fita. Técnica de Backup Tradicional O modelo de backup tradicional basicamente copia os dados de backup através da rede local (LAN). Os três componentes de um ambiente de backup tradicional baseado em LAN incluem: – Um servidor de backup que mantém horários e catálogos de dados de toda a empresa e controla a cópia dos dados para a mídia de backup; – Os servidores de mídia copiam dados para mídia de backup sob o controle do servidor mestre de backup; – O cliente de backup é o software que está instalado no servidor de aplicação e transfere dados de backup do armazenamento primário para o servidor mestre de backup pela LAN. O conceito de um cliente de backup é derivado da arquitetura cliente/servidor, onde o cliente de backup comunica-se com um servidor de backup para completar o processo de backup. Estas funções são tarefas modulares de software e podem ser colocadas no mesmo servidor ou divididas entre vários servidores (tipicamente dedicados).

204 A configuração mostrada aqui tem o servidor de backup e o de mídia montados em servidores diferentes. Operacionalmente, o cliente de backup lê os dados do armazenamento primário, copia os dados pela LAN e escreve-os em fita. O servidor de mídia cria um índice de fita com um catálogo dos índices mantidos pelo servidor de backup. Este catálogo pode ser usado para otimizar o Restore de um único arquivo a partir da fita, avançando rapidamente a fita para a localização exata do arquivo – evitando a necessidade de procurar o arquivo que estamos buscando através de uma fita (ou fitas). Em uma operação 9x5 com a rede local e servidores de aplicação ociosos durante a noite, esta configuração funciona bem, mas à medida que nos movemos para uma operação 24x7 (24 horas/dia, 7 dias/semana), o fluxo de dados de backup acaba competindo com os dados operacionais por largura de banda de rede e os servidores que estão sendo colocados em modo off- line para realizar backup podem se transformar em um grande problema.

205 Técnica de Backup Livre de LAN O backup livre de LAN retira o tráfego de backup da rede local, conectando o dispositivo de backup em fita diretamente na SAN (rede de armazenamento de dados). O servidor de aplicação move dados do dispositivo primário de armazenamento de dados (disco) para a fita de backup pela SAN. Usar o servidor de aplicação para backup de seus próprios dados, do disco para fita, potencializa a capacidade da SAN de mover em alta velocidade um grande volume de dados, reduzindo o potencial da LAN tornar-se um gargalo de desempenho. Em grandes organizações com enormes quantidades de dados contínuos, usar a LAN como um caminho de backup pode dobrar o fluxo de dados tipicamente trafegado em operação normal. Com uma SAN, a largura de banda disponível é geralmente maior e é configurado para lidar com um fluxo de dados mais contínuo.

206 Nesta configuração, o servidor de backup, o servidor de mídia e o cliente de backup ainda existem - todos estão em execução no servidor de aplicação. Estas funções de software permitem que o servidor de aplicação leia os dados do disco (armazenamento primário) e escreva diretamente para a fita de backup. O servidor de aplicação também irá construir seu próprio índice e catálogo de fita. Isso funcionaria bem para uma operação 9x5, onde os servidores estão ociosos durante a noite, disponibilizando tempo de processamento para a atividade de backup, sem impactar as principais operações da organização. Mas se estamos diante de uma operação 24x7, provavelmente não iremos querer que o servidor de aplicação seja responsável por fazer o backup, porque ele vai ocupar muitos recursos da CPU e potencialmente afetar as atividades de atendimento da empresa. Neste ponto, podemos separar o componente de servidor de mídia em seu próprio servidor dedicado. Funcionalmente, o servidor de backup envia uma lista de arquivos ou registros através da LAN para o cliente de backup no servidor de aplicação. O cliente de backup traduz a lista em endereços de dados no sistema primário de armazenamento em disco e envia estes para o servidor de mídia. O servidor de mídia, em seguida, inicia uma cópia dos dados no sistema de disco primário para a fita de backup. Para fazer isto, os dados no sistema de disco primário precisam estar congelados enquanto o backup está ocorrendo. Assim, para que esta configuração de backup funcione, ela terá de ser usada em conjunto com técnicas de cópia de ponto no tempo*, tais como snapshots* ou quebra de espelhamento*.

207 Dessa forma, o cliente de backup do servidor de aplicação é chamado para o backup (pelo servidor de backup), o cliente de backup vai copiar os metadados para o servidor de mídia, e em seguida, a transferência de dados atuais ocorre sobre a rede SAN. Uma vez que o catálogo é construído, ele ainda volta via LAN para o servidor de backup. Então, a menos que haja milhões de arquivos pequenos, é improvável que a rede LAN apresente um gargalo que limite seu desempenho (com a evolução da internet das coisas – IoT, milhões de pequenos arquivos serão constantemente gerados e podem se tornar a força propulsora para adoção dessa técnica).

208 Técnica de Backup sem Servidor Com backup sem servidor, movemos as funções do servidor de mídia para um appliance localizado dentro da própria SAN. Este appliance pode ser um dispositivo independente ou pode ser um recurso opcional construído em um switch SAN (normalmente um switch Fibre Channel director*). O modelo de backup sem servidor usa o appliance SAN para implementar cópias diretas de sistema de armazenamento para sistema de armazenamento para executar backups. Isso libera os servidores para executar as aplicações, enquanto os backups estão executando em segundo plano, como uma atividade autônoma na SAN. Um servidor ainda é necessário para o gerenciamento do backup, mas nenhum dado de backup passa através desse servidor. Assim como no backup, no LAN Free, os dados do disco de armazenamento primário precisam ser congelados antes que o backup possa iniciar. Isto pode ser feito tirando uma cópia de ponto no tempo (PiT* - snapshot* ou quebra de espelhamento*). Uma vez que esta cópia é tirada, os dados primários são liberados para que a aplicação possa continuar trabalhando, e o backup inicia usando o PiT como a origem dos dados. Para que o appliance (por vezes referido como um ‘movedor de dados’) saiba quando iniciar um backup, um comando específico (SCSI XCOPY) é enviado junto com uma lista de endereços no disco de armazenamento primário de dados para que os dados possam ser copiados. Em resumo, o que estamos realmente fazendo é muito parecido com o backup livre de LAN, onde o componente de servidor de mídia está separado. As funções de servidor de backup, cliente de backup e servidor de mídia permanecem, mas a tecnologia e as técnicas para a implantação deles se adaptaram para atender aos novos requisitos. * Abordado em outra parte desta publicação

209 Capítulo 6 Seção 3 Replicação de Dados Introdução A replicação de dados normalmente se refere ao backup de dados para o disco, em vez de fita. Existem duas abordagens básicas para a replicação de dados. A primeira delas é atender a um requisito para a recuperação de falha – e a retomada das atividades de negócio após uma perda ou interrupção dos dados. Técnicas como: ponto no tempo (PiT) e cópias de dados (por exemplo snapshot*) podem ser usadas para proporcionar uma recuperação mais rápida dos dados, do que soluções de backup baseadas em fita. A segunda abordagem é um requisito para a tolerância de falhas, garantindo a continuidade das atividades comerciais, evitando a interrupção ou perda significativa de dados. Isto requer uma recuperação quase instantânea, e é tipicamente um caso para o uso de dados espelhados*, outra técnica de cópia PiT. Técnicas de Cópia de Ponto no Tempo Ambos snapshots e espelhamentos são cópias consistentes e utilizáveis de dados em um determinado ponto no tempo.

210 Snapshots* Um snapshot é uma representação virtual de um volume em um determinado ponto no tempo. Os snapshots não capturam dados, apenas os ponteiros (metadados) dos dados. Uma vez que os ponteiros tenham sido copiados e armazenados, quaisquer dados que tenham sido alterados desde o último snapshot serão copiados. A vantagem de usar snapshots é que a capacidade consumida pelos ponteiros é muito menor do que espelhamento dos dados, mas por outro lado, os dados copiados são atualizados somente no último snapshot. Então, os snapshots são uma representação virtual de um determinado ponto no tempo e uma quebra de espelhamento é uma cópia completa de um determinado ponto no tempo.

211 Espelhamento* Os dados escritos no armazenamento primário são automaticamente copiados em tempo real para o armazenamento espelhado, oferecendo uma recuperação quase instantânea no caso de uma perda de dados ou falha no Storage. Espelhamento de dados obtém uma cópia completa dos dados do armazenamento primário. A quebra de espelhamento (split mirror) é uma técnica usada para fazer uma cópia de um ponto no tempo de um sistema de disco espelhado. Isto requer um terceiro disco espelhado que funcione ao lado dos discos de espelhamento existentes. Para fazer uma quebra de espelhamento, o array de disco é momentaneamente congelado (da mesma forma que nos snapshots) e a terceira unidade é desconectada de quaisquer operações de gravação de dados adicionais de modo que os dados nessa unidade são efetivamente 'congelados' em um ponto no tempo. Os dois discos restantes são então liberados para continuar a operar como um par espelhado, garantindo tolerância a falha do sistema de disco e proteção de dados. O disco que é separado pode ser usado para fazer um backup para fita.

212 Backups Sintéticos A técnica de backup baseada em disco, que incorpora cópias PiT, chama-se backup sintético. O backup sintético elimina a necessidade de realizar backups completos recorrentes. Isto pode ser útil para fazer um backup de recursos remotos onde o desempenho da conectividade pode ser limitado. Uma política de backup sintético permite que ele seja reconstruído a partir de um backup completo (chamado de backup base) e subsequentes backups incrementais. O backup sintético resultante torna-se então o novo backup base. Depois disso, apenas backups incrementais são necessários até que o próximo backup sintético seja criado. O backup sintético é tão atual quanto o último backup incremental que ele contém. Os componentes de um backup sintético são: 1. Backup Base - o primeiro backup a ser executado é associado com o backup sintético. O backup base é executado apenas uma vez, e faz backup de todos os arquivos (backup completo). 2. Backups Incrementais Recorrentes - os backups subsequentes fazem uma cópia de segurança dos arquivos que são alterados após o backup base. A frequência com que os backups incrementais são executados é definida pela política de backup. 3. Backups Sintéticos Recorrentes - os dados do backup base e dos backups incrementais são combinados para formar um backup sintetizado completo, efetivamente criando um novo backup completo. O backup completo sintetizado torna-se um novo backup base. Este é um processo de repetição com a frequência definida pela Política de backup.

213 O backup sintético aproveita algumas das mesmas técnicas do PiT* como snapshots*, mas tem a vantagem de não ter que fazer uma reconstrução completa de todos os backups incrementais desde o backup inicial, quando um Restore é necessário. Apenas o último backup sintético precisa passar por recombinação com as cópias incrementais desde que foi criado. Cada vez que um novo backup completo (sintético) é criado, ele cria uma oportunidade para que o backup em fita seja realizado. Se a política de backup é bem elaborada, então a frequência de criar um novo backup sintético pode ser sincronizada com um backup em fita (por exemplo, a cada meia-noite para empresas que cobram alguns dos seus clientes diariamente). As políticas de backup de cada organização devem ser adaptadas para atender às demandas de negócio, considerando o volume de dados que não pode ser perdido e que é criado ao longo do tempo. Replicação Síncrona e Assíncrona Quando estamos espelhando (ou replicando) dados, há duas maneiras como isso pode ser implementado - de maneira síncrona ou assíncrona. Replicação Síncrona Garante \"perda zero de dados\" de forma que uma escrita não é considerada completa até a confirmação de escrita pelos sistemas de armazenamento primário e secundário. A redução do desempenho da aplicação é diretamente proporcional a distância entre os sistemas de armazenamento primário e secundário.

214 Replicação Assíncrona Com a replicação assíncrona, a escrita dos dados é considerada completa assim que o sistema de armazenamento primário confirma a escrita. O sistema de armazenamento secundário é atualizado, mas provavelmente com um pequeno atraso. O impacto de desempenho da aplicação é minimizado, mas não é garantido que o segundo sistema de armazenamento tenha a cópia atualizada dos dados (isso dependerá da distância entre os sistemas de armazenamento primário e secundário). A decisão de implantar uma operação síncrona ou assíncrona é operacional. Se, por exemplo, estivéssemos replicando dados para mais de um site, a consistência da replicação poderia ser considerada completa se a cópia tivesse sido feita para apenas um dos sites ou teríamos que esperar por ambos para completar? * Abordado em mais detalhes em outra parte dessa publicação

215 Capítulo 6 Seção 4 Proteção Externa de Dados (Off-Site) Introdução Em muitos casos, as organizações protegem seus dados valiosos tendo uma cópia remota dos dados primários. Normalmente as cópias remotas devem estar localizadas fora do raio de ameaça de qualquer evento significativo, que possa afetar os dados mantidos localmente (por exemplo, terremotos, enchentes, grandes cortes de energia, etc.). Guarda Externa de Fitas Algumas organizações optam por uma estratégia de guarda externa de dados, o envio de dados críticos para fora do site principal, como parte de um plano de recuperação de desastre. Para muitas empresas, o armazenamento de fita em guarda off-site, para recuperação de desastre, continua a ser uma solução prática e econômica para backup e arquivamento. Quando as fitas de backup ou de archive são movidas, tipicamente as organizações garantem um transporte seguro, armazenamento e um bom sistema de rastreamento de fitas, para garantir que os seus dados sejam facilmente localizados caso seja necessário (afinal de contas, o total de todos os dados da organização está contido no backup, sem a proteção de segurança do data center).

216 Guarda Eletrônica (e-Vaulting) O e-Vaulting não pode ser considerado um evento síncrono, pois o atraso na comunicação a distância traria um sério impacto no servidor de aplicação do site principal. Tipicamente, a técnica utilizada é obter uma cópia de ponto no tempo (PiT)* e enviar os dados inalterados através da conexão de longa distância, sem impactar o funcionamento normal do servidor de aplicação do site principal.

217 Site de Recuperação de Falha (Failover) O e-Vaulting é uma solução eficaz para backup remoto, mas se a organização precisar mover os dados para um site remoto em caso de um grande problema no site principal, a replicação assíncrona não é suficiente, pois não garante que os dados estejam atualizados. Nestas circunstâncias, apenas uma cópia síncrona irá atender aos requisitos. No entanto, o espelhamento síncrono tem o potencial de impactar o desempenho da aplicação de negócios da empresa, devido ao atraso no espelhamento de dados através de um link de longa distância. Isto significa que a velocidade e o custo do link de longa distância* entre os sites tornam-se relevantes e precisam ser considerados como parte de uma estratégia mais ampla de armazenamento de dados. Uma consideração adicional da solução de espelhamento síncrono é que, se os dados originais estiverem corrompidos, os dados espelhados também serão corrompidos. Por outro lado, se ocorrer corrupção de dados com uma solução PiT, os dados podem ser restaurados para um estado anterior, antes da corrupção ocorrer. Isso seria muito difícil de conseguir com uma solução de espelhamento. * Abordado em mais detalhes em outra parte dessa publicação

218 Capítulo 6 Seção 5 Proteção de Dados e Criptografia Introdução Encriptar dados armazenados é uma estratégia de proteção de dados amplamente aceita. Existem normas da indústria para encriptar dados armazenados e estes são criados e mantidos através do Institute of Electrical and Electronics Engineers (IEEE) e Security in Storage Working Group (SISWG) e inclui uma série de normas para a proteção de dados armazenados e para a gestão da chave correspondente. O padrão IEEE é conhecido como P1619. Este padrão tem vários padrões distintos dentro dele. Estes são associados ao local onde a criptografia de dados realmente ocorre. O padrão para criptografia baseada em disco é o P1619.0, o padrão para criptografia de armazenamento de fita é P1619.1 e o gerenciamento de chaves P1619.3. Introdução à Criptografia A criptografia de dados transforma fluxos de dados inseguros (texto simples) em um fluxo de dados ilegível (texto criptografado) para qualquer pessoa, exceto para aqueles que possuem informação privilegiada, geralmente referida através de uma chave. O processo inverso (tornar a informação criptografada legível novamente) é chamado de decriptografia. A criptografia é amplamente utilizada e pode ser usada para criptografar dados armazenados (de arquivos únicos para discos rígidos inteiros e fitas de backup), dados transmitidos através das redes ou até mesmo infraestruturas de comunicação inteiras. Chaves O acesso a dados encriptados depende da utilização de uma 'chave' secreta. Uma chave é um pedaço de informação que é conhecido para aqueles que têm permissão de acesso aos dados e é usada como parte da transformação de texto não criptografado em texto criptografado durante a criptografia, ou vice-versa durante a decriptografia.

219 Geralmente, existem dois tipos de chaves: chaves simétricas e chaves assimétricas. As chaves simétricas são utilizadas tanto para criptografia quanto para decriptografia de dados. As Chaves assimétricas usam uma chave para encriptar o fluxo de dados e outra para decriptografá-lo. Isto permite que a chave que encripta os dados torne-se pública (chave pública) enquanto apenas a segunda chave (privada) pode decriptografar os dados. Isso permite que as pessoas criptografem os dados para serem enviados para um único dispositivo ou local, sem que nenhum dos remetentes tenha a capacidade de decriptografar quaisquer dados. Um usuário pode publicar sua chave pública, mantendo sua chave privada em segredo.

220 Força da Criptografia A técnica de criptografia descreve como é difícil ‘quebrá-la’ (este parece ser um jogo de gato e rato, com decifradores de código e mecanismos de codificação competindo uns com os outros constantemente). O fator determinante da força de qualquer técnica de criptografia é o comprimento em bits da chave de criptografia. O comprimento em bits refere-se a quantos bits de dados a chave consiste e é um indicador de quão difícil é quebrar o sistema de criptografia. Quanto mais bits na chave, mais difícil é decriptografar os dados, simplesmente tentando todas as chaves possíveis. Tentar quebrar uma chave de 56 bits usando uma combinação de bits pode levar cerca de uma semana (a menos que uma agência do governo esteja envolvida). A cada vez que você adiciona um bit extra ao comprimento da chave, o tempo deste tipo de operação 'de quebra' pode dobrar. A maioria dos algoritmos modernos operam usando 128 ou, de forma crescente, 256 bits. Por exemplo, o padrão IEEE P1619 é baseado em chave de 128 bits, enquanto as fitas LTO (LTO-4, LTO-5 e LTO-6) utilizam criptografia de 256 bits no hardware da unidade. Criptografia Baseada em Host (Servidor) A criptografia baseada em host pode ser mais útil quando a criptografia é necessária para um único servidor ou um conjunto limitado de servidores. Criptografar dados em um host permite que os dispositivos criptografados sejam acessados simultaneamente sem ter que se preocupar se a criptografia é suportada pela infraestrutura básica. Além disso, o host criptografado garante a criptografia dos dados que se movem entre o host e o dispositivo de armazenamento. No entanto, a desvantagem do host criptografado é colocar uma carga computacional no servidor e talvez impactar no desempenho da aplicação e desduplicação.

221 Criptografar os Dados para o Disco A criptografia de disco usa software ou hardware para criptografar todos os dados de um disco ou volume, a fim de impedir o acesso não autorizado ao armazenamento de dados. Mesmo quando tudo em um disco é criptografado, é importante deixar o registro de inicialização mestre (MBR - Master Boot Record) não criptografado. O MBR é necessário para carregar o sistema operacional a partir do disco rígido, o que significa que, se o MBR é encriptado, seria necessário haver alguma interface de usuário para permitir que o MBR seja decriptado. No entanto, existem alguns sistemas de criptografia de disco rígido baseados em hardware que podem encriptar todo o disco rígido, incluindo o MBR. A fim de tornar o MBR acessível, a chave MBR deve estar disponível antes que haja uma interface de usuário pedindo uma senha. Criptografar um disco inteiro com uma única chave nem sempre é apropriado, pois nem todos os usuários têm permissão para acessar todos os dados no sistema de disco. Uma solução para isso é dividir o disco em partições (volumes), cada uma com sua própria chave.

222 Uma segurança granular maior pode ser alcançada usando criptografia no sistema de arquivos. Assim, um invasor não pode extrair informações de arquivos e pastas criptografados. Deve-se lembrar que, ao contrário da criptografia do disco inteiro, a criptografia na camada do sistema de arquivos normalmente não criptografa os metadados do sistema de arquivos (por exemplo, estrutura de diretório, nomes de arquivos, datas de modificação, etc.) que pode permitir que um hacker saiba o que está em um disco, mas não tenha acesso aos dados reais. Em alguns casos, uma empresa pode optar por um servidor de criptografia, onde é realizado a criptografia, e é responsável pela distribuição e controle das chaves. Isto é geralmente implantado em sistemas pequenos, com um número limitado de usuários. Discos Autocriptografados A inovação mais recente é ter a unidades de disco rígido individuais com criptografia embarcada. Estes são conhecidos como discos autocriptografados (SEDs - Self Encrypting Disks). Um SED tem um circuito construído no chip controlador da unidade de disco que encripta todos os dados para a mídia magnética, e decripta todos os dados da mídia automaticamente. Os SEDs encriptam o tempo todo a partir de sua fabricação, funcionando como qualquer outro disco rígido, com a criptografia sendo completamente transparente ou invisível para o usuário.

223 Para proteger os dados contra roubo, o usuário fornece uma senha. Esta senha é usada pela unidade para encriptar ou decriptar a chave de criptografia da mídia. Desta forma, nem mesmo a chave de criptografia de mídia pode ser conhecida sem saber a senha. A vantagem desta abordagem é que os SEDs fazem toda a criptografia dentro da unidade de disco, o que significa que as chaves de criptografia de disco nunca estão presentes no servidor ou memória. A autenticação do usuário é feita dentro do SED e nunca é exposta dentro do servidor. Isto significa que o disco por si só é seguro, e só pode ser acessado em combinação com uma senha, que pode ser mantida separadamente do servidor e do disco. Isto significa que o acesso ao data center é insuficiente para ser capaz de acessar os dados armazenados no disco. Criptografar os Dados para a Fita* Não existe um único ponto num ecossistema de armazenamento de dados em que a criptografia de dados deve ser implantada. Por exemplo: a criptografia de fita é muitas vezes implementada na fita ou no dispositivo, tendo como exemplo mais fortemente implantado a família de unidades de fita LTO disponíveis de vários fornecedores. Existem também alguns appliances in-line. Estes appliances se posicionam entre a origem dos dados de backup e o dispositivo de fita de destino e criptografam os dados em tempo real. Normalmente, eles estão tipicamente localizados em uma SAN. A criptografia na camada de software encripta os dados no servidor ou no cliente de backup, e em seguida, os envia para o dispositivo de fita. No entanto, criptografar dados na origem irá remover a capacidade de aplicar a desduplicação*, já que isso requer reconhecer blocos de dados idênticos em texto simples. Quando for necessária a desduplicação, esta deve ser efetuada antes de o fluxo de dados ser criptografado. O maior desafio é o gerenciamento de chave. A perda de chaves resulta em dados perdidos. Algumas organizações gerenciam suas chaves manualmente, mas este processo deve ser o mais automatizado possível. Alguns produtos de software de backup são totalmente integrados a unidades de fita compatíveis com LTO (por exemplo) para que o software cuide do gerenciamento de chaves. Esta é uma boa solução, pois elimina a preocupação de ter que introduzir outro componente cuidando do gerenciamento de chaves

224 Gestão da Chave de Criptografia A utilização da criptografia nos sistemas de armazenamento e a estratégia de montagem dos dados armazenados ‘na nuvem’ estão criando a necessidade de se padronizar a maneira de gestão das chaves de criptografia através de diversas infraestruturas. Esta necessidade foi intensificada por regulamentações do segmento e do governo, que exigem a criptografia dos dados armazenados. O Protocolo de Interoperabilidade de Gerenciamento de Chaves (KMIP - Key Management Interoperability Protocol) está surgindo como padrão, com os fornecedores incorporando KMIP em seus produtos e aumentando o uso de armazenamento baseado em nuvem*, sendo os principais fomentadores para sua adoção. O KMIP define o protocolo usado para requisição e entrega de chaves entre qualquer servidor de gerenciamento de chaves e sistema de criptografia (um servidor de gerenciamento de chaves é um servidor dedicado que armazena e distribui todas as chaves, sob solicitação, tendo como base políticas definidas). O KMIP usa formatos padrão para nomear e identificar chaves. O KMIP está disponível sem royalties da OASIS (Advancing Open Standards for the Information Society) **. Abstraindo a tarefa de gerenciar chaves das aplicações que as usam, o padrão permite que chaves sejam gerenciadas dentro da empresa para dados e aplicativos criptografados na nuvem, e com produtos de diferentes fornecedores.

225 Criptografar os Dados em Movimento Além de usar a criptografia para proteger os dados que estão sendo armazenados (dados em repouso), temos que estar cientes de que os dados que se movem entre o servidor e o dispositivo de armazenamento também podem estar vulneráveis. Tipicamente, o sistema de conexão será uma rede de armazenamento*. Estes podem ser baseados em IP (Internet Protocol) ou em Fibre Channel* (FC). Uma solução é encriptar e decriptar dados no servidor. No entanto, isso coloca uma carga computacional no servidor, que pode impactar o desempenho da aplicação de negócios de uma empresa. A alternativa é usar as ferramentas de criptografia disponíveis nas redes de armazenamento. Protocolo de Segurança de Internet (IPsec - Internet Protocol Security) Para redes de armazenamento baseadas em IP, o Protocolo de Segurança de Internet (IPsec) oferece uma segurança de ponta a ponta. O IPsec protege as comunicações IP autenticando e criptografando cada pacote IP, incluindo protocolos para autenticação caso os servidores e dispositivos conectados tenham autorização para acessar as chaves de criptografia a serem usadas durante a transferência de dados. O IPsec pode ser usado para proteger todo e qualquer tráfego através de uma rede IP, enquanto outros tipos de segurança de rede devem ser suportados por software em execução no servidor. O IPsec não requer nenhum software especial no servidor ou no dispositivo de armazenamento, portanto, não afeta o desempenho do servidor. Criptografia do Fibre Channel A especificação Fibre Channel* para protocolos de segurança (FC-SP) é um padrão abrangente de segurança em SANs Fibre Channel. Este padrão inclui segmentar uma rede Fibre Channel para minimizar o risco de acesso não autorizado e autenticar switches e usuários finais que querem se juntar à rede. Não existe um equivalente atual ao IPsec para criptografar os dados em movimento. Um fabricante (Cisco) criou a sua própria capacidade de criptografia para o Fibre Channel, aumentando a especificação FC-SP. Esta capacidade proprietária é conhecida como TrustSec. Isto não é uma criptografia fim a fim, uma vez que só suporta links entre os switches Fibre Channel da Cisco. Ele é projetado principalmente para atender a segurança da conexão entre dois switches Fibre Channel em longas distâncias entre data centers, onde a ligação de dados está fora do controle do data center. Em alguns casos, a criptografia TrustSec é realizada dentro do data center para clientes focados na segurança, como serviços de defesa e inteligência. Se o IP for utilizado para conectar data centers isolados, as conexões de fibra podem ser FC-IP* (Fibre Channel sobre IP). Neste caso, o IPsec poderia ser usado para encriptar os dados no link. * Abordado em mais detalhes em outra parte dessa publicação ** https://www.oasis-open.org/org/faq

226 Capítulo 6 Seção 6 Controles de Acesso para Proteção de Dados Introdução O controle de acesso é um assunto importante por si só, por isso só seremos capazes de cobrir seletivamente alguns dos conceitos importantes nesta seção. O objetivo do controle de acesso é garantir que apenas pessoas e dispositivos que estão autorizados a ter acesso a um sistema sejam autorizados a entrar. Para ambientes de armazenamento de dados, o controle de acesso concentra-se na rede de armazenamento onde o potencial para uma presença indesejada é mais acentuado. Dentro de SANs*, o controle de acesso é supervisionado pela inteligência dentro dos switches que compõem a rede ou fabric. Segurança AAA A abordagem convencional para o controle de acesso de rede ou fabric é baseada no que é conhecido como segurança AAA. AAA é uma abreviatura para os três principais elementos envolvidos – Autenticação, Autorização e Auditoria. A Autenticação é um meio de identificar quem está autorizado a se conectar à rede/fabric. Isso inclui a exigência de um login e senha e a capacidade de desafiar um usuário que já está conectado. O processo de autenticação para verificar a identidade da pessoa ou dispositivo que acessa o switch é baseado na combinação de ID do usuário e senha fornecida pela entidade que tenta acessar a rede/fabric. O switch suportará a autenticação local (com base numa base de dados de usuários e senhas aprovados mantida localmente) ou a autenticação remota (com um ou mais servidores RADIUS ou TACACS+ – definidos a seguir). A Autorização entra em cena assim que a fase de autenticação tenha sido concluída com sucesso. O processo de autorização seleciona os recursos e capacidades de rede/fabric a que a entidade recentemente associada tem acesso. Esta informação é descarregada no(s) switch(es) a partir de servidores AAA, tais como RADIUS e TACACS+, que autorizam os usuários para direitos específicos. A Auditoria é o terceiro e último processo. O processo de auditoria requer que o switch colete dados sobre as entidades conectadas e mantenha um log de cada ação usada para acessá-lo. Esta informação pode ser usada para gerar relatórios para fins de resolução de problemas e auditoria. Os logs de conta podem estar localmente no switch ou enviados para servidores remotos AAA.

227 Protocolos de Segurança RADIUS e TACACS+ Existem dois protocolos principais de segurança AAA – RADIUS (Remote Access Dial-In User Service) e TACACS+ (Terminal Access Controller Access-Control System). Ambos funcionam em um servidor dedicado e conectam-se a uma rede/fabric através da conexão de gerenciamento em um único switch na rede/fabric. Através desta única conexão, eles estão disponíveis para todos os switches na rede/fabric. Neste momento você pode estar se perguntando: por que existem dois protocolos de segurança AAA? A resposta é que foram concebidos para cumprir dois requisitos (sobrepostos). O TACACS+ é usado principalmente para a administração de dispositivos AAA, mas também é possível usá-lo para alguns tipos de acesso à rede AAA, enquanto o RADIUS é o protocolo de escolha para o acesso à rede AAA.

228 TACACS+ O TACACS+ é um protocolo de segurança derivado de um protocolo de segurança original conhecido como TACACS. Enquanto o TACACS+ pode ser derivado do TACACS, ele é um protocolo completamente separado e não retrocompatível. O protocolo de segurança TACACS+ fornece validação centralizada dos usuários que tentam obter acesso a um switch de rede/fabric. O TACACS+ é arquitetado para administração de dispositivos que podem ser, por natureza, muito interativos, com a necessidade de autenticar uma vez, mas autorizar muitas vezes. Por exemplo, um switch de rede/fabric pode precisar autorizar a atividade de um usuário cada vez que há uma interação com a rede/fabric. O TACACS+ destina-se a satisfazer esse tipo de necessidade de autorização. As comunicações TACACS+ são totalmente criptografadas. Com TACACS+, cada um dos três processos AAA são operações distintas. RADIUS O RADIUS protege as redes contra acesso não autorizado. Normalmente, um cliente RADIUS executa em um switch de rede/fabric e envia pedidos de autenticação para um servidor central RADIUS que contém todas as informações de autenticação do usuário e acesso ao serviço de rede. Quando um outro switch, dispositivo ou usuário quer se juntar ao fabric/rede, o servidor RADIUS emite uma aceitação, rejeição ou desafio de resposta (redigite senha, etc.) que irá determinar se a conexão é validada e se o switch, dispositivo ou usuário pode então ser conectado. RADIUS versus TACACS+ Uma diferença entre RADIUS e TACACS+ é que autenticação e autorização não são processos em uma transação de RADIUS. Quando o pedido de autenticação é enviado para um servidor AAA, o cliente AAA espera que o resultado da autorização seja enviado de volta em resposta – TACACS+ trata a autenticação e a autorização como processos separados. Outro diferenciador entre RADIUS e TACACS+ é que a interação completa com o servidor TACACS+ é criptografada enquanto RADIUS apenas criptografa senhas. Basicamente, o diferencial operacional é que o RADIUS (acesso à rede) gira em torno de quem se juntou à rede/fabric, como eles autenticaram, quanto tempo eles ficaram, etc. enquanto o TACACS+ (dispositivo administrativo.) gira em torno de questões de como e quando um determinado comando foi inserido.

229 DH-CHAP (Diffie-Hellman augmented Challenge Handshake Authentication Protocol) O CHAP original (Challenge Handshake Authentication Protocol) é um protocolo que requer uma autenticação antes de cada interação entre duas entidades (usuários/dispositivos/switches) em uma rede/fabric. A característica que torna CHAP diferente é que a autenticação necessária muda a cada interação entre essas entidades. O DH-CHAP veio evoluindo adicionando segurança adicional usando o que é conhecido como Diffie-Hellman Key Exchange (nomeado em homenagem a Whitfield Diffie e Martin Hellman). Isto adicionou a capacidade de usar um sistema de chave pública* – mais ou menos a mesma metodologia que é usada em processos de criptografia. O DH-CHAP permite que apenas dispositivos confiáveis sejam adicionados a uma rede/fabric, o que impede que dispositivos não autorizados acessem o switch. O DH-CHAP requer uma senha e um protocolo de autenticação de troca de chaves que suporta a autenticação tanto de switch para switch como de host para switch. O Fibre Channel incorporou a DH-CHAP na norma FC-SP (Fibre Channel Security Protocol). * Abordado em mais detalhes em outra parte dessa publicação

230 Capítulo 6 Seção 7 Proteção de Dados e 'a Nuvem' Introdução As organizações usam a nuvem para proteção de dados de várias maneiras. Algumas optam pela nuvem como o núcleo de sua estratégia de proteção de dados, enquanto outras usam a nuvem como um complemento à sua estratégia interna de proteção de dados. Os backups de nuvem são muitas vezes considerados uma boa alternativa para backups locais, porque eles permitem backups de dados sendo armazenados de forma segura fora do local, sem os desafios de envio e armazenamento de mídia removível em um local remoto. Opções de Backup em Nuvem Um dos primeiros usos que as pessoas encontraram para 'a nuvem' foi como um backup. Em contraste com o backup tradicional, o backup em nuvem gira em torno do envio de cópias fora do local para um provedor de nuvem. O método mais simples de implantação de backup em nuvem é ter os dados de backup copiados diretamente para a nuvem do provedor de serviços. A maioria dos softwares de backup tradicionais tem a opção de oferecer suporte para backup direto na nuvem. A abordagem alternativa é usar o que é conhecido como backup de nuvem híbrida. Com esta abordagem, uma cópia de ponto no tempo (PiT) dos dados será feita. Isto é então usado como base para que os dados sejam copiados para a nuvem - proporcionando a vantagem de reter os dados localmente para mitigar o problema de uma conexão mais lenta à nuvem e para ter um backup disponível no local no caso de um Restore rápido ser necessário. O termo backup de nuvem híbrida pode ser enganador porque sugere que o backup é projetado para proteger uma nuvem híbrida* ou depende de uma nuvem híbrida*. Um backup de nuvem híbrida tem pouco a ver com uma nuvem híbrida e é mais precisamente descrito como um backup híbrido que alavanca a nuvem.

231 Backup 'Nativo' na Nuvem Com backup 'nativo' na nuvem, os backups vão diretamente para a nuvem do provedor de serviços. O principal benefício desta abordagem é que ela é fácil, escalável e não requer internamente competências de TI especializadas. Além disso, isso pode permitir que as organizações possam razoavelmente projetar com precisão seus custos de suporte, com base na antecipação do crescimento de dados de backup. Podem haver benefícios nos custos de OpEx pois a necessidade de administrar o backup é removida. As principais desvantagens com uma nuvem 'nativa' são que ela é muito restrita pela largura de banda disponível entre o site principal e a nuvem. Isto o torna inadequado para organizações com grandes e complexos requisitos de backup. Isso iria monopolizar as conexões à Internet.

232 Backup de Nuvem Híbrida Para as organizações que produzem grandes quantidades de dados e têm um requisito para operações de restore rápido, uma estratégia híbrida pode ser uma opção. O backup de nuvem híbrida consiste em uma capacidade de armazenamento baseada em disco que atua como um meio de backup local (por exemplo, técnicas de cópia de ponto no tempo*, bibliotecas de fita virtual* ou um dispositivo NAS* que liga à nuvem). Esses dados armazenados localmente são então copiados para a nuvem. Quando um restore é necessário a partir de um backup recente, os dados estão prontos no local e podem ser acessados rapidamente. Alternativamente, os dados podem ser restaurados a partir de backup externo baseado em nuvem para este armazenamento no local sob demanda e restaurado para o sistema principal a partir de lá. Desta forma, uma organização pode ter a velocidade de um backup local com a proteção de um backup em nuvem. Para tal, são necessários investimento e gestão adicionais dos dispositivos de armazenamento internos e a definição desta implantação torna-se uma análise custo/benefício, em vez de uma decisão tecnológica.

233 Considerações para a Proteção de Dados na Nuvem Ao desenvolver uma estratégia de proteção de dados baseada em nuvem, uma abordagem híbrida, que usa disco no site e fita na nuvem, é um modelo muito eficaz. Algumas organizações podem dispensar o uso de fita devido à falta de requisitos de retenção de longo prazo, mas isto é bem incomum. Outras organizações podem não ser capazes de usar uma nuvem pública* por causa de preocupações de segurança, mas elas ainda podem considerar uma estratégia de nuvem privada* onde elas podem controlar as questões de segurança. Archiving A proteção de dados em nuvem também pode incluir a manutenção de dados arquivados na nuvem. No entanto, isto levanta a questão de saber como satisfazer as autoridades reguladoras quanto à validade dos dados. Neste caso, o recurso WORM* (Write Once Read Many) existente em sistemas de fita pode oferecer alguma proteção quando os dados de backup estão fora do controle imediato da organização. No entanto, há mais uma questão que precisa de ser analisada: a opinião das autoridades reguladoras sobre a localização física dos dados. A preocupação aqui é que se os dados são armazenados em um local onde a lei permite às autoridades acessar os dados dentro de sua jurisdição – onde os dados são armazenados torna-se uma questão. Localização Por exemplo, se uma empresa europeia guardasse dados na nuvem e armazenasse-os nos EUA (e vice-versa), as autoridades legais poderiam exigir o acesso. Isso pode ser superado exigindo que o provedor de serviços mantenha todos os dados de backup com uma jurisdição. No entanto, torna-se mais uma questão para os fornecedores de Software como um Serviço* (SaaS), uma vez que isto também se aplica a dados ‘vivos’, o que significa que o poder de computação (servidores) também deve estar localizado dentro de uma jurisdição especificada. Alguns prestadores de serviços já estão criando data centers especificamente localizados, que fazem parte de uma implantação de nuvem maior, a fim de resolver este problema.

234 Dependência do Fornecedor de Nuvem? Aqui fazemos a pergunta – o que acontece com seus dados se você quiser trocar de provedor de serviços? A resposta realmente depende de como você estabeleceu seu contrato de serviço com o provedor de nuvem. Em um cenário, você não tem outra opção senão deixar seus dados de longo prazo com o provedor de serviços existente e pagar pelo armazenamento até que, basicamente, os dados ‘envelheçam’. Da perspectiva de backup, o primeiro backup para o novo provedor de serviços deve invalidar os backups anteriores armazenados no primeiro provedor – mas e os dados arquivados que precisam ser retidos no longo prazo? Se o atual provedor de serviços de nuvem armazena os dados arquivados em fitas para retenção de longo prazo, então haverá, sem dúvida, uma opção em adquirir essas fitas, mas isso seria muito melhor se negociado no início, em vez de ter que chegar a um acordo dado o fato de que o primeiro provedor está te perdendo como cliente. Existe outro ponto de atenção se as fitas tiverem de ser transferidas de um provedor de nuvem para outro. Certifique-se de que os seus auditores e departamento jurídico concordem com a sua estratégia de retenção e transferência, uma vez que existe o risco de substituição das fitas, enquanto em trânsito, se não for criado um registro de auditoria. Segurança A segurança é uma preocupação comum sobre qualquer serviço em nuvem. É importante que os serviços de backup fornecidos em nuvem ofereçam criptografia completa de ponta a ponta, onde os dados não são apenas criptografados em trânsito para o provedor, mas também enquanto em repouso nas instalações do provedor. Uma segunda questão é: quem tem as chaves de criptografia? As organizações com dados sensíveis devem considerar serviços que lhes permitam possuir e manter as chaves de criptografia, em vez de deixar com o provedor.

235 E Realmente se Economiza? Uma das questões que não devemos perder de vista é que algumas organizações veem o backup na nuvem como um exercício de economia de custos. Esta suposição é algo que não pode ser considerado como certo pois o custo potencial do produto em nuvem deve ser considerado ao longo do tempo. Os serviços de backup baseados na nuvem tendem a ser atraentes pelo seu baixo custo inicial, mas quando esses custos são multiplicados ao longo dos anos, os produtos de backup na nuvem podem realmente ser mais caros do que os tradicionais (backup local). O que tende a ser ignorado é que o volume de dados provavelmente continuará a crescer. A maioria dos provedores de serviços de nuvem cobra pela capacidade de dados que estão protegendo e este custo vai crescendo em proporção direta. Fazendo Backup na Nuvem Quando estamos considerando a proteção de dados na nuvem surge uma questão: como a própria nuvem protege seus dados? Por exemplo, como os provedores de nuvem que oferecem Software como um Serviço (SaaS* - é tipicamente o tipo de serviço fornecido pelo Microsoft Office 365 e Salesforce) protegem os dados dos seus clientes em uma implantação na nuvem? A maioria das organizações assume que, como seus dados estão na nuvem baseada em SaaS, ela também está protegida. O backup 'nuvem para nuvem' protege contra este tipo de perda de dados, onde a própria nuvem SaaS pode estar usando outro provedor de serviços em nuvem para fazer backup de seus próprios dados e de seus clientes para um local remoto. Se este for o caso, então todas as advertências que se aplicam para fazer backup de seus próprios dados para a nuvem precisam ser consideradas ao comprar serviços do provedor SaaS.

236 Recuperação de Desastres como um Serviço (DRaaS) A recuperação de desastre como serviço (DRaaS) é a replicação e hospedagem de servidores (físicos ou virtuais), como parte de um serviço na nuvem, para prover o failover no caso de uma catástrofe no site principal. É importante, se considerarmos esta opção, que os requisitos e expectativas de DRaaS sejam documentados num acordo de nível de serviço (SLA) e que o fornecedor de nuvem forneça capacidades de failover. Financeiramente, isto pode ser feito através de um contrato ou de uma base pay-per-use. O DRaaS pode ser especialmente útil para PMEs (pequenas e médias empresas) que não dispõem dos conhecimentos necessários para implementar e manter um plano eficaz de recuperação de catástrofes. A vantagem da utilização de DRaaS também significa que não há investimento de capital nem despesas operacionais na manutenção e testes do ambiente de DR. A desvantagem, obviamente, é que a empresa deve confiar que o prestador de serviços DRaaS pode implementar o plano em caso de catástrofe e cumprir os objetivos definidos de tempo de recuperação (RTO)* e de ponto de recuperação (RPO)*.

237 Preocupações ao Considerar uma Estratégia DRaaS É importante que qualquer fornecedor de serviços na nuvem de DRaaS tenha a capacidade de suportar os requisitos de DR de várias organizações simultaneamente. Se ocorrer uma catástrofe numa vasta área (clima, atividade sísmica, interrupção da rede elétrica, etc.), os provedores de nuvem DRaaS podem ficar sobrecarregados com múltiplos pedidos simultâneos de recuperação de inúmeros clientes. Comprometendo-se com cada SLA, o provedor de serviços deverá atender sua contingência, mesmo que o data center na nuvem não tenha sido dimensionado corretamente para suportá-la. O SLA proporciona uma forma de garantir que o desempenho é aceitável para uso a longo prazo. Outra consideração importante é como o data center principal deve retornar à operação normal após o site principal retornar à sua eficiência operacional. A pergunta que precisa ser feita ao provedor de serviços aqui é: existe uma maneira de recuperar inteligentemente os dados de modo que apenas os dados que mudaram sejam restaurados, enquanto a aplicação estava funcionando na nuvem? Isso exigirá um recurso de transferência em massa, como o envio de discos rígidos ou mídia de fita para o site principal para facilitar uma recuperação local mais rápida ou o Restore será sobre a conexão relativamente lenta para o provedor de nuvem. Se estas perguntas não puderem ser respondidas, então pode ser prudente considerar outro prestador de serviços ou ter um plano específico de organização no site principal. (esta última opção anula muitos dos benefícios de uma implantação de DRaaS) Sumário Nesta seção, demos apenas uma ideia das questões, desafios e soluções de proteção de dados que a nuvem traz. O que precisamos lembrar é que, à medida que mais e mais dados são criados e carregados para a nuvem, proteger esses dados torna-se crítico. Para isso, os provedores de serviços de nuvem podem precisar copiar dados para outro provedor de nuvem e existem soluções onde cópias secundárias de dados de backup podem residir no site de um cliente na cloud, bem como carregadas na cloud. Existem muitas opções disponíveis para garantir que os dados que residem na nuvem sejam protegidos. Os usuários não devem cometer o erro de assumir que seus dados estão seguros só porque estão na nuvem. * Abordado em mais detalhes em outra parte dessa publicação

238 Capítulo 7 Seção 1 Virtualização de Armazenamento Utilizada na Nuvem Introdução O que um consumidor de serviço na nuvem espera experimentar é um ambiente abstrato onde efetivamente experimenta uma aplicação totalmente suportada sem ter qualquer conhecimento dos recursos que são usados para fornecer o serviço. Isso requer que qualquer serviço na nuvem seja baseado em tecnologias e técnicas de virtualização. A principal característica de um ambiente na nuvem é a capacidade de implantar recursos e aplicações sob demanda, em vez de respeitar prazos alongados na aquisição de infraestrutura de TI no data center tradicional, onde novos recursos devem ser instalados, configurados e integrados em sistemas existentes. Isso inclui a rápida implantação de capacidade de armazenamento de dados para atender às mudanças no ambiente de negócios de uma empresa. A alocação rápida de recursos e a realocação dinâmica facilitam a escalabilidade para corresponder às necessidades de negócios em mudança, sendo ágil na liberação de recursos conforme a prioridade específica de negócios diminui. Do ponto de vista econômico, o custo do provisionamento de novos serviços e da gestão das necessidades existentes é muito reduzido. Neste capítulo, focaremos no papel do armazenamento, na prestação de serviços eficazes em nuvem. A fim de cobrir este assunto, é necessário fazer algumas suposições sobre os níveis existentes de compreensão das implementações de nuvens. Por exemplo, existe uma conscientização assumida de modelos de serviço na nuvem como os descritos no http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf e uma apreciação das técnicas de virtualização do servidor - como o papel do hypervisor) em uma máquina virtual (VM) (https://en.wikipedia.org/wiki/Hypervisor. Estes serão apenas referidos à medida que surgirem e não se prevê um entendimento profundo. Então, com estas ressalvas, vamos começar. A virtualização dos servidores no data center foi acompanhada pela virtualização no armazenamento, conduzindo a uma terminologia de armazenamento lógico e abstrato, como armazenamento de instância, armazenamento efêmero e armazenamento persistente. Este capítulo irá mapear algumas dessas novas terminologias de nuvem e técnicas para a tecnologia tradicional de armazenamento de dados.

239 Revisão de Terminologia Terminologia de Armazenamento Físico • Direct Attach Storage (DAS)* é o modelo de armazenamento mais evidente tipicamente encontrado em dispositivos como laptops, tablets e computadores de mesa. A característica fundamental do DAS é que o servidor (computador) e o armazenamento estão intrinsecamente unidos. SCSI e SATA são exemplos típicos de protocolos DAS. • Network Attached Storage (NAS) * utiliza protocolos de sistemas de arquivos para se comunicar entre os servidores e o dispositivo de armazenamento. NFS* e CIFS* são exemplos de protocolos NAS. NAS permite que vários servidores compartilhem o acesso a arquivos. Vários servidores podem ler o mesmo arquivo ao mesmo tempo, e vários servidores podem colocar novos arquivos no sistema de arquivos ao mesmo tempo.

240 Cada sistema de arquivos NAS é um espaço de nomes único, e o sistema de arquivos é a unidade primária usada para gerenciar o NAS. – Um espaço de nomes único é uma forma de descrever a forma como um NAS gerencia seu sistema de arquivos internamente. Cada arquivo sob o controle do NAS Head* é unicamente identificável e acessível dentro do ambiente de armazenamento NAS, não importando como o servidor (que armazenou os dados) os enxerga. É uma função do NAS Head reconstruir um arquivo no formato que o servidor espera receber quando o arquivo for acessado. – Um espaço de nomes único é benéfico porque simplifica a gestão para um controlador NAS (NAS Head). A alternativa seria gerenciar cada sistema individual separadamente - uma sobrecarga significativa tanto em termos de desempenho e poder computacional requerido no NAS Head. • Storage Area Network (SAN)* é um sistema de comunicação gerenciado entre dispositivos de armazenamento e servidor sobre uma rede/fabric usando o mesmo tipo de transferências de blocos de dados que são usados para se comunicar com discos diretamente conectados. Fibre Channel e iSCSI são exemplos de protocolos SAN. • Dispositivos de infraestrutura de armazenamento físico que criam armazenamento virtual* basicamente segmentam grupos de capacidade de armazenamento físico e apresenta-os para servidores como discos virtuais (lógicos)*. Estas unidades virtuais (lógicas) de capacidade são referidas como Volumes ou LUNs (LUN é um acrônimo para Logical Unit Number - um termo originalmente usado no SCSI tradicional*). As LUNs são normalmente geradas em ambientes SAN onde a capacidade de armazenamento é consolidada (agrupada).

241 VMs, Hypervisors e Armazenamento Quando nos movemos para um ambiente de nuvem que é fortemente dependente da utilização de máquinas virtuais (VMs), elas podem ser rapidamente implantadas e reimplantadas. As máquinas virtuais são criadas pelo hypervisor - um software que gerencia múltiplos sistemas operacionais ou múltiplas instâncias do mesmo sistema operacional em um único servidor. Cada instância do sistema operacional é conhecida como uma máquina virtual (VM). O hypervisor emula um ambiente de hardware para cada VM, incluindo processamento, memória e armazenamento. De uma perspectiva de armazenamento, a maioria dos hypervisors escolhem emular unidades de disco físico locais usando o modelo DAS. Esses discos virtuais criados por hypervisors são criados como parte integral de uma VM. Eles não têm uma \"vida\" independente - eles existem apenas enquanto a VM existir. Se a VM é excluída, então o disco virtual será excluído também.

242 No entanto, se algumas VMs quiserem compartilhar capacidade de armazenamento comum, o modelo DAS acaba sendo uma limitação. Uma resposta óbvia seria considerar o uso de LUNs que podem ser criadas a partir de conjuntos de armazenamento físico a partir da infraestrutura de armazenamento físico, normalmente usando uma SAN. Afinal, em servidores não-virtualizados, as LUNs são apresentadas como discos virtuais (lógicos). No entanto, quando utlizamos VMs, isso também tem um grande inconveniente. Apresentar uma (ou talvez duas) LUNs a um único servidor funciona, mas o que acontece quando você está apresentando LUNs a várias VMs, todas localizadas em um mesmo servidor (e normalmente é quase certo que haverá muitos servidores físicos)? O grande número de LUNs que precisaria ser apresentado, reapresentado e gerenciado supera as habilidades do hardware do sistema de armazenamento. Este desafio só pode ser enfrentado pelo hypervisor criando e entregando os discos virtuais necessários. Estes discos podem ser armazenados nas LUNs apresentadas a um servidor físico. O armazenamento compartilhado também facilita outra característica da virtualização do servidor, o movimento dinâmico das VMs entre servidores, que exige o acesso de armazenamento compartilhado durante a migração. A fim de tornar mais fácil esta migração dinâmica, alguns hypervisors tratam os discos virtuais criados como arquivos em um sistema de arquivos (por exemplo: NFS ou CIFS). Isso permite a migração de discos virtuais gerados pelo hypervisor de um servidor físico para outro, apenas executando uma transferência de arquivos. Esta seria uma operação muito desafiadora se nós apenas usássemos as LUNs geradas pela infraestrutura de armazenamento de disco físico.

243 O hypervisor situa-se entre o sistema operacional na VM e a capacidade física de armazenamento de disco que está acessando. O hypervisor intercepta transferências de dados (escrita e leitura) e redireciona-os para o armazenamento físico que foi alocado. Como resultado, quando o sistema operacional em uma VM está acessando os discos virtuais gerados pelo hypervisor, o protocolo que é usado é interno e não precisa ser associado com transferências em bloco (DAS, SAN) ou transferências de arquivos (NAS). O modelo no qual o hypervisor é projetado (DAS, NAS, SAN) é a separação entre o sistema operacional da VM e o sistema de armazenamento físico subjacente, ou seja, significa que podemos ter um modelo mix and match. Por exemplo, o sistema operacional da VM poderia acreditar que ele está se comunicando com um disco DAS (baseado em transferência de bloco), enquanto o armazenamento físico subjacente poderia ser um NAS (baseado em arquivo).

244 Este exemplo de DAS na VM e do NAS no sistema de armazenamento físico subjacente é amplamente implantado. Esta configuração permite o armazenamento (físico) de discos virtuais do hypervisor como arquivos (ver acima) em um repositório central de compartilhamento de arquivos do tipo NAS. Se a VM for migrada para outro servidor físico, o disco virtual ainda fica disponível através do NAS. * Abordado em mais detalhes em outra parte dessa publicação

245 Capítulo 7 Seção 2 Modelos de Armazenamento na Nuvem Introdução A virtualização é o carro-chefe para construção de ambientes na nuvem. Como não existe um ambiente padrão para uma nuvem, com algumas organizações implementando nuvens privadas dentro de seus data centers próprios e outras oferecendo serviços em nuvem, a forma como o armazenamento de dados virtualizado é implementado reflete esta diversidade. Nesta seção vamos explorar como a virtualização na nuvem pode ser implantada em uma série de diferentes modelos de armazenamento na nuvem. Um modelo de armazenamento não é um protocolo de armazenamento e pode ser implantado independentemente do protocolo de armazenamento físico que sustenta esse modelo. Modelos de Armazenamento na Nuvem Armazenamento de Instância 'Instância' é um termo usado para se referir a máquinas virtuais individuais que funcionam em servidores físicos dentro da nuvem. Quando uma máquina virtual (VM) é criada, suas características são baseadas em imagens padrão de VMs pré-definidas armazenadas na nuvem. Por exemplo, uma imagem conteria detalhes de recursos como poder computacional, tamanho da memória e capacidade de armazenamento que precisam ser alocados. Uma única imagem pode ser usada para qualquer número de instâncias (VMs). Cada instância (VM) começa como esta imagem de base, mas pode ser modificada uma vez que é validada. Quaisquer alterações feitas à instância (VM) não afetam a imagem base armazenada na nuvem. Novas imagens podem ser criadas lançando uma imagem padrão existente como uma instância (VM), modificando essa instância (VM) e, em seguida, gravando-a como uma nova imagem 'padrão'.

246 O armazenamento de instância refere-se ao recurso de armazenamento atribuído a uma única instância (VM). O armazenamento de instância é o modelo que mais reflete os ambientes de armazenamento virtualizados baseados em infraestrutura física. O armazenamento de instância é tipicamente implementado usando a conexão do tipo DAS entre o hypervisor e a VM do sistema operacional. O armazenamento de instância também é referido como armazenamento efêmero. Por exemplo, se você implantar OpenStack* Nova por conta própria, os discos virtuais associados com as VMs são 'efêmeros', o que significa que (do ponto de vista do usuário) eles efetivamente desaparecem quando uma máquina virtual é terminada.

247 Armazenamento de Volume O armazenamento de instância, no entanto, tem suas limitações, uma vez que muitas aplicações que são executadas na nuvem (Software como um Serviço - SaaS) tipicamente diferenciam os dados associados ao sistema operacional (SO) e à aplicação de software a partir de dados do usuário, tais como bases de dados ou arquivos. A razão para considerar a separação destes dados é poder permitir que a VM que está executando o sistema operacional e o software de aplicação possam ser reconfigurados sem impactar os dados do usuário. Isso permite que o provedor de serviços em nuvem (SaaS) adapte dinamicamente o serviço fornecido sem ter que fazer quaisquer alterações aos dados do usuário. A partir de uma perspectiva de armazenamento, isso é conseguido através da implementação do novo sistema operacional e requisito de aplicação em uma nova VM, permitindo que o disco virtual seja migrado ou montado como uma nova instância do disco virtual. Isto assegura que o disco virtual (e os dados do usuário) sobrevivam ao fim da VM original. Quando um disco virtual (e seus dados) sobrevive à exclusão de uma VM, isso é conhecido como armazenamento persistente. Armazenamento persistente significa que o recurso de armazenamento sobrevive a qualquer outro recurso e está sempre disponível. Tipicamente isso é possível anexando o disco virtual do hypervisor ao SO como DAS e, na camada física, ter o disco virtual armazenado como um arquivo compartilhado em um dispositivo de rede de armazenamento. OpenStack Cinder* é um exemplo deste método.

248 Armazenamento na Nuvem baseado em Objetos Um dos encantos de se usar uma nuvem é que os recursos podem estar disponíveis independentemente da sua localização física – tudo isso estando 'na nuvem'. Isto pode significar que o servidor físico que suporta VMs não precisa estar localmente no data center. Isso cria um desafio onde várias VMs podem estar acessando os mesmos dados (compartilhados). Anteriormente, vimos que isso pode ser conseguido através de um NAS conectado localmente como um dispositivo de compartilhamento de arquivos que tem o controle do seu próprio espaço de nomes interno (espaço de nomes identifica um conjunto de arquivos, de modo que não há nenhuma ambiguidade quando esses arquivos, mesmo se gerados ou armazenados por diferentes dispositivos ou em locais diferentes, forem misturados). No entanto, quando os servidores das VM não estão localmente no mesmo data center é impraticável tentar acessar os dados compartilhados através de links de longa distância. Isto significa que os dados compartilhados precisam ser replicados no site remoto. Consequentemente, pode haver várias infraestruturas de armazenamento na nuvem, cada uma armazenando os mesmos dados compartilhados, mas usando o seu próprio espaço de nomes, resultando em um mesmo arquivo tendo um nome diferente, dependendo de onde ele está localizado na nuvem. Como resultado, os dados compartilhados precisam ser sincronizados em toda a nuvem quando quaisquer alterações são feitas localmente e isso requer um sistema de endereçamento comum para identificar arquivos específicos. O armazenamento baseado em objetos oferece um espaço de nomes global entre localidades distintas. O armazenamento de dados baseado em objetos permite que um arquivo (um objeto) seja identificado e rastreado de forma única em todo o ecossistema da nuvem, mesmo que ele possa residir em vários sistemas de arquivos compartilhados, localizados separadamente. Isto permite que quaisquer alterações feitas a um arquivo, em qualquer local, sejam diretamente correlacionadas com todas as outras instâncias desse arquivo através da nuvem para sincronização. Isso cria um potencial para alguma inconsistência de dados através da nuvem enquanto a sincronização ocorre. Quando isso é um problema, servidores com VM e armazenamento físico devem estar localizados no mesmo data center. O Openstack's Swift* é um exemplo de usar o armazenamento baseado em objetos em um ambiente de nuvem. O OpenStack também pode armazenar imagens de máquina virtual (VM) dentro de um sistema de armazenamento baseado em objetos.

249 Sumário Assim como DAS, SAN e NAS fornecem um conjunto de ferramentas para atender a uma variedade de requisitos de armazenamento físico, a instância, o volume e o armazenamento de objetos fornecem modelos de armazenamento para atender aos requisitos da nuvem. Nenhum modelo de armazenamento em nuvem é passível de atender a todos os casos de uso necessários por conta própria. Por isso, é provável que haja uma abordagem de combinar tecnologias diferentes para oferecer a correspondência necessária para atender grandes implementações em nuvem. Armazenamento de instância e volume funcionam como uma unidade de disco lógica cuja capacidade reside nos modelos existentes de armazenamento DAS e NAS. Estes modelos de armazenamento virtual estão em camadas acima dos protocolos de armazenamento físico existentes. Armazenamento baseado em objetos proporciona uma abordagem diferente para gerenciar o dado armazenado, focando primariamente em implementações de nuvem de larga escala. • Abordado em mais detalhes em outra parte dessa publicação