O que é Storage, SAN, NAS, SAS, iSCSI, Fiber Channel, JBOD? Guia Definitivo!

Esse artigo apresenta um overview geral sobre o tema Storage, entrando em alguns detalhes técnicos quando necessário. É recomendado algum conhecimento de redes e sistemas operacionais e servidores para uma melhor compreensão.

Índice

  1. Introdução
  2. Tipos de Storage
    1. JBOD
    2. Gerenciado
    3. Virtualizado
    4. Virtualizado com Camadas
    5. NAS, Object Storage e VTLs
  3. Conectividade
    1. SAS
    2. Fibre Channel
    3. iSCSI
    4. Rede comum ou NAS
  4. Escalabilidade
    1. SAN
    2. Multipath
  5. Segurança
    1. HDs Spare
    2. Snapshots
    3. Replicação
    4. Criptografia
  6. Quando usar e quais aplicações

1. Introdução

Storage, genericamente falando, é um termo técnico em TI, que indica um dispositivo de armazenamento.

Seria correto chamar um HD, um DVD, um cartão SD (usado em celulares e câmeras) e até um Pendrive de Storage, pois é o local onde se armazenam dados, mas normalmente o termo Storage é usado para referenciar um equipamento mais complexo, onde se instalam diversos drives de disco (HDD) ou estado sólido (SSD), com controladora, cache e várias redundâncias para que esse equipamento não apresente falhas.

Nesse artigo utilizaremos o termo HDs para referenciar tanto Discos Rígidos (HDD) quanto Discos de Estado Sólido (SSDs).

O principal uso do Storage é para aumentar a capacidade e performance do armazenamento de um servidor ou conjunto de servidores; como escrevemos na matéria sobre IOPS, para obter uma determinada performance a um custo razoável, é necessário unir vários HDs utilizando RAID.

Dependendo da aplicação, são necessários até dezenas de HDs, o que não seria viável dentro do gabinete de um único servidor, pois o gabinete do servidor precisa armazenar outros componentes como placa mãe, CPU, memória e placas de rede.

Instala-se então um gabinete externo para acomodar e energizar os HDs, conectados ao servidor para que o mesmo possa ter acesso e controle dos discos.

A diferença física externa entre um servidor e um Storage pode ser imperceptível para olhos menos experientes, ou seja, ambos estarão em um gabinete de aço muito similar, com fontes redundantes, duas conexões de energia elétrica e até cabos de redes (Storages mais avançados tem interfaces de administração via rede).

Exemplo de um Storage Dell PowerVault MD1200 e um Servidor Dell R720, ambos para montagem em rack com a tampa frontal. A diferença de cor se deve à diferença de iluminação das fotos. Ambos são muito similares. Obs.: nas versões mais novas a Dell passou a adotar tampas frontais diferentes para Storage e Servidores, mas ainda pode causar confusão para profissionais menos experientes.

Já removendo a tampa da frente, normalmente o Storage apresenta todos os HDs com capacidade Hot Plug, isto é, podem ser removidos ou inseridos sem desligar a energia elétrica, enquanto que o servidor normalmente terá conexões USB, drives de CDs/DVD, entrada para teclado e mouse para manutenção e poucos HDs, mas existem exceções, alguns servidores podem ter tantos HDs quanto um Storage de pequeno porte.

Storage Dell PowerVault MD1200 com 12 discos de 3,5″

Para utilizar o Storage no servidor, os HDs do Storage são acessados como se fossem HDs comuns depois de instalados os drivers. Basta formatar normalmente. No Windows é necessário escolher uma letra e no Linux é necessário montar uma partição.

Os Storages podem compreender desde alguns poucos HDs (normalmente 12 para começar em um ambiente corporativo) até dezenas ou centenas de HDs.

Exemplo de Storage com 96 discos, sendo 4 gavetas com 24 discos cada.

Normalmente o Storage tem uma “gaveta” ou gabinete principal, onde ficam as controladoras e são conectados aos demais gabinetes de HDs. Esse gabinete principal pode ter ou não HDs, dependendo do modelo.

As controladoras é que definem o tipo de RAID, divisões dos HDs e quais servidores terão acesso a quais Volumes.

A expansão se dá por gabinetes mais simples sem controladoras, apenas com as conexões físicas para os HDs com fontes de alimentação e ventilação para refrigeração.

É nas controladoras onde são encaixados cabos para conectar aos servidores, mas normalmente um Storage não possui muitas portas para conexão.

Para conectar acima de 4 servidores (até centenas se for o caso), é necessário montar uma SAN ou Storage Area Network.

Uma SAN consiste em dois Switches (dois por conta da redundância, mas usando apenas um funcionaria), onde são conectados os Storages e os Servidores, podendo haver mais de um Storage na mesma SAN. É uma rede específica para tráfego de dados entre esses equipamentos.

Por boa prática, a SAN é isolada da rede comum, dependendo do tipo de conexão, os cabos e conectores não são nem compatíveis com a rede comum de dados.

Não confundir SAN com NAS, que é um tipo específico de Storage que vamos ver logo abaixo. Voltaremos a falar sobre SAN também.

Para uma melhor compreensão, vamos explorar mais os tipos de Storage, conectividade e escalabilidade a seguir:

2. Tipos de Storage

A primeira classificação feita em Storages é de acordo com as funcionalidades do equipamento, são classificados basicamente em cinco tipos:

2.1. JBOD ou DAS

Just a Bunch Of Disks” ou “um punhado de discos” é o tipo mais simples de Storage, que normalmente serve apenas para energizar os HDs e fornecer uma porta de conexão até o servidor.

Também são chamados de DAS (Direct Attached Storage), pois são Storages conectados diretamente ao servidor, embora o uso de DAS não são limitados para esse tipo de Storage.

Nesse tipo de Storage, não existe nenhuma inteligência de gestão dos HDs, a inteligência é feita em uma placa instalada no servidor, uma controladora RAID, responsável por distribuir os dados nos HDs, cuidando da redundância e monitorando a saúde dos mesmos.

São normalmente Storages pequenos, onde pode-se instalar 8, 12 ou 16 HDs (dependendo do modelo e do fabricante) e idealmente são ligados a um único servidor (alguns modelos permitem ligar dois servidores sem redundância) através de um cabo SAS (antigamente eram cabos SCSI).

São recomendados para aplicações específicas, como banco de dados, ou virtualização em apenas um servidor, o que os torna limitados para serem usados em ambientes pequenos que demandem alta performance, mas normalmente sem redundância dos servidores.

2.2. “Inteligente” ou Gerenciado

O próximo nível de sofisticação é adicionar uma controladora diretamente no Storage, ou seja, a placa responsável pelo RAID passa a fazer parte do Storage, que faz a gerência dos HDs e pode distribuir “fatias” do Storage entre vários servidores.

Nesse storage, normalmente existem duas placas controladoras redundantes, duas fontes de energia e redundância em todas as conexões internas e externas.

Eles podem ser conectados a um ou mais servidores, separando uma quantidade específica de HDs para cada servidor em um RAID específico, fornecendo performance e ao mesmo tempo possibilitando implementar redundâncias entre os servidores, para ser usado em clusters de virtualização ou clusters de banco de dados.

Exemplo de um Storage conectado a dois servidores

Na imagem de exemplo acima, o Storage “separou” 7 HDs para formar um grupo de RAID 5, criar um Volume e apresentar ao Servidor 1 e outros 3 HDs para formar outro grupo de RAID 5, criar outro Volume e apresentar ao Servidor 2.

Volume é o nome que se dá aos blocos de discos apresentados aos servidores, normalmente o controle de acesso a esses blocos é configurado no Storage. Alguns fabricantes chamam esses blocos de LUNs ou Disk Groups ou ainda Disk Volumes, para fins didáticos, vamos usar apenas o termo Volume.

A quantidade de servidores conectados depende da conectividade do Storage, que vamos abordar mais abaixo.

Esse tipo de Storage tem se tornado cada vez mais raro, uma vez que ele é muito semelhante ao Storage Virtualizado em termos de hardware, os fabricantes tem evoluído seus produtos para serem todos Virtualizados.

Quando conectados diretamente aos servidores, a arquitetura ainda é chamada de DAS (Direct Attached Storage), diferente da SAN (Storage Area Network) onde temos Switches no caminho para distribuir a conexão entre Storages e Servidores.

2.3. “Virtualizado”

No Storage Virtualizado os HDs são organizados em RAIDs, mas depois uma camada de virtualização cria fatias sobre esse RAID e distribui para as aplicações em diversos servidores.

Exemplo de um Storage Virtualizado

Na imagem exemplo, todos os HDs foram configurados com um único RAID, o que resulta em um Volume grande que pode ser alocado.

Esse Volume é dividido em vários Volumes Virtuais, que são apresentados aos servidores e pode-se deixar uma parte do Volume sem alocar (espaço livre), para uso futuro.

A vantagem inicial dessa configuração é poder usar o espaço livre conforme demanda. Por exemplo, quando se instala um ambiente novo, não tem como ter certeza do crescimento dos dados e é melhor deixar essa decisão para depois.

Conforme o uso vai crescendo, é possível alocar dinamicamente o espaço livre para os Volumes que necessitam. Essa manobra normalmente é possível de executar sem interrupção dos sistemas.

Outra vantagem é que a performance de todos os discos ficam disponíveis para todas as aplicações, por exemplo, se for configurado um RAID 10 sobre 12 discos e tenha um total de 1Tb de dados, mesmo apresentando apenas um Volume Virtual de apenas 100Gb, a performance de todos os discos estará disponível.

Isso normalmente é bom, pois algumas aplicações podem ter um pico de uso momentâneo e terá a performance de todos os discos disponível.

O problema acontece quando o Storage é subdimensionado e não entrega os IOPS necessários para todas as aplicações, o que pode causar gargalos e lentidão no ambiente, como tratamos na matéria sobre erros nos projetos de Virtualização.

Ainda nas vantagens, como os dados não estão atrelados fisicamente aos HDs, vários fabricantes permitem a alteração do tipo de RAID ou mesmo alternar os Volumes entre HDs de diferentes performance.

Por exemplo, pode-se fazer uma configuração inicial de um volume para Banco de Dados em RAID 10 sobre discos SSD, ou seja, a configuração mais performática sobre os HDs mais rápidos possível, mas também a mais cara.

Na imagem abaixo, podemos ver o Volume 1 com essa configuração:

Exemplo de Storage com 3 gavetas de 12 HDs cada, sendo que cada gaveta tem HDs de tipos diferentes (orientado para melhor performance ou melhor custo), utilizado 10 discos para criação do RAID e 2 de Spare.

Se essa aplicação de banco de dados for depois descontinuada ou substituída e for usada apenas como legado, não faz sentido manter esses dados sobre essa configuração mais cara.

Em um Storage Virtualizado é possível alterar o tipo de RAID e até movimentar os dados entre discos diferentes, digamos, movendo esses dados legados para discos de 7200 RPMs em RAID 6, sem interrupção. Basta fazer a configuração na interface de gerência que o Storage cuida da movimentação dos dados.

O contrário também é possível, digamos que o Volume 5 do exemplo que foi inicialmente configurado sobre discos de 7200 RPMS e RAID 6 não está fornecendo performance suficiente para a aplicação.

Esse volume pode ser movimentado para discos mais rápidos de 15000 RPMS e RAID 10 com apenas um comando.

Claro que esse processo pode demorar até algumas horas, mas não há interrupção nos serviços nem necessidade de reconfiguração dos servidores e aplicações.

Se o Storage não fosse virtualizado, esse processo teria que ser feito manualmente, alocando os discos, criando o RAID, formatando o Volume, copiando os dados através de um servidor, etc, ou seja, um baita trabalho manual com possibilidades de erros e parada dos sistemas.

Obs.: se você prestou atenção, nos desenhos indico que os RAIDs foram feitos com 10 discos, mas foram desenhados 12 discos. Isso é porque 2 discos foram deixados para Spare (reserva), explicamos mais abaixo.

2.4. Virtualizado com Camadas

Alguns Storages Virtualizados mais avançados ainda contam com um recurso de “Tier” ou Camadas, que serve para distribuir os blocos nas camadas conforme o uso e necessidade de performance.

Por exemplo, um Storage com Camadas pode ter várias configurações de discos e RAIDs e os Volumes Virtuais são distribuídos automaticamente entre eles pela controladora.

Na imagem abaixo, temos 4 Volumes para dados, que estão distribuídos nas camadas conforme o tamanho e prioridade que foram configurados.

Storage Virtualizado em Camadas

Volume 1: foi configurado uma prioridade Alta, mas ele é grande e o uso principal acontece apenas em alguns blocos que estão na camada mais nobre, os blocos pouco acessados estão em uma camada intermediária.

Volume 2: é o maior volume, configurado com uma prioridade Média, alguns blocos são muito acessados e estão na camada mais rápida, ao mesmo tempo que a maioria dos blocos são pouquíssimo acessados e estão nas camadas mais baratas.

Volume 3 foi configurado com prioridade Baixa, então os dados dele nunca estarão na camada mais nobre do Storage.

Já o Volume 4 foi configurado com prioridade altíssima e como é pequeno o suficiente, todos seus dados estão na camada mais nobre do Storage.

A principal vantagem do Storage Virtualizado em Camadas é ter performance adequada por um custo de aquisição mais acessível para todo o espaço em disco necessário e pouca necessidade de gerência, já que toda a performance é garantida pela controladora baseado em configurações de prioridade prévia.

Claro que esse modelo começa a fazer sentido apenas em ambientes maiores, com várias dezenas de discos ou até mesmo centenas de discos, pois ainda é necessário adquirir discos de altíssima performance junto com os discos de maior armazenamento, e o software sendo mais complexo, acaba custando um pouco mais nas controladoras do que Storages Gerenciados ou Virtualizados.

2.5. NAS, Object Storages e VTLs

Um tipo de equipamento mais específico oferecido pelos fabricantes são os Storages do tipo NAS e Object Storages.

São Storages especializados para determinadas aplicações, por exemplo, NAS é acrônimo para Network Attached Storage, é um tipo de Storage que é ligado diretamente à rede, cuja função é servir arquivos sem precisar de um servidor para isso.

Ele se comporta como um servidor de Arquivos comum, como se fizéssemos o compartilhamento de uma unidade no Windows Server e acessasse normalmente pelas estações.

Existem NAS de pequeno porte, com apenas 1 ou 2 HDs em RAID 1, que podem ser instalados em residências ou pequenos escritórios para servir como Media Servers, onde os dispositivos podem ser configurados para fazer backup automaticamente das Fotos, Filmes e outros dados.

Para ambientes corporativos, os NAS são compatíveis com ambientes Linux e Windows e normalmente integrados ao Active Directory para gestão dos acessos.

Ainda em ambientes corporativos existem recursos específicos nesses Storages:

  • Deduplicação ou desduplicação, que garante que arquivos iguais sejam armazenados apenas uma vez no Storage, economizando espaço em disco
  • Compactação automática dos dados armazenados, gerando menos uso de disco e menos IOPS
  • Versionamento, uma espécie de backup online, que armazena cópias quando arquivos são sobrescritos e permite recuperar versões mais antigas dos mesmos
  • Replicação, permitindo a cópia automática dos arquivos entre dois NAS em localidades diferentes, para fins de proteção contra desastre

Alguns NAS são chamados de Object Storage, pois possuem protocolos proprietários para compactação de determinados tipos de arquivos, como imagens e vídeos.

Esses protocolos permitem uma compressão maior para esses tipos de mídia, ao mesmo tempo que tem performance otimizada para servir esse tipo de arquivo.

E ainda existem alguns NAS que são específicos para backup, que podem ser usados como uma VTL (Virtual Tape Library), simulando uma unidade de backup em fita, mas na verdade armazenando os dados em discos, para maior performance.

As VTLs costumam conseguir armazenar várias versões de backup, muito superior à sua capacidade de disco, graças à compactação extrema e deduplicação. Os dados de backup tendem a ser repetidos no dia a dia, o que permite que esses Storages armazenem apenas uma cópia desses dados, utilizando novo espaço apenas para dados novos.

A vantagem de utilizar um NAS realmente está no fato de ser um hardware e software mais especializado para a função, o que pode ser interessante pelos recursos avançados de gestão e redundância, mas deve se levar em conta os custos envolvidos (são mais caros do que Storages normais para a mesma capacidade física, mas normalmente mais baratos para a capacidade lógica) e soluções alternativas em software (existem Softwares capazes de habilitar recursos como compactação e deduplicação em servidores comuns).

3. Conectividade

Outra classificação dada aos Storages é quanto à conectividade dos mesmos com os servidores que usarão seus recursos.

As interfaces de conectividade é que determinam se é possível ou não criar uma SAN.

Existem basicamente 4 tipos possíveis de conexão:

3.1. SAS – Serial Attached SCSI

Storages que usam a conexão SAS são normalmente os mais simples e mais limitados. Os cabos SAS não podem chegar a distâncias muito longas, apenas 10 metros pela especificação, o que limita a instalação em ambientes muito grandes.

Por conta dessa limitação, normalmente os Storages SAS são instalados no mesmo Rack que os servidores que irão utilizá-lo, no máximo no Rack ao lado, limitando a quantidade de discos do Storage e a quantidade de servidores que podem ser conectados.

Visão traseira de um Storage SAS compatível com rack de 19″, nas laterais estão as fontes de energia redundantes, na parte central são duas controladoras com duas portas SAS cada, observe que os componentes são Hot Plug.

Por outro lado, a performance é excelente, um cabo SAS pode chegar a 22.5Gbit/s (versão 2017), mas mesmo as versões anteriores de 12Gb/s e 6Gb/s já tinham performance superior a outras conexões em seu tempo e ainda tem performance excelente para maioria das aplicações de hoje em dia.

Para mais detalhes técnicos, essa matéria na Wikipedia (em inglês) é bem completa.

Normalmente Storages com conexão SAS tem poucas portas de conexão, até 8 nos modelos mais avançados, o que permite conectar até 4 servidores com redundâncias, ou 8 servidores sem as redundâncias. Esse é outro fator que limita esses Storages para serem usados apenas em ambientes pequenos.

Até existiram Switches SAS no mercado, com 16 portas, uma configuração com 2 Switches SAS e 1 Storage permitiria montar uma SAN e conectar até 15 servidores em redundância, mas foram descontinuados por baixa demanda.

3.2. Fibre Channel

Como o nome sugere, Fibre Channel utiliza Fibra Ótica para conexão entre o Storage e os Servidores.

Isso requer que placas especializadas sejam instaladas nos servidores, cabeamento apropriado seja utilizado, além claro do Storage suportar esse tipo de conexão.

É considerado o tipo de conexão mais nobre de um Storage, com baixa latência e alta performance.

Embora o protocolo especifique velocidades de até 128Gb/s, muitos equipamentos implementam apenas 16Gb/s ou no máximo 32Gb/s, isso porque, para atingir o limite, são necessários centenas de HDs, o que normalmente não existe na maioria dos ambientes, ou não seria viável para um servidor processar.

Usando Fibre Channel é possível montar uma “rede” SAN especializada, onde os cabos utilizados são diferentes dos cabos da LAN.

É até possível ter servidores conectados a quilômetros de distância, desde que tenha a conexão de Fibra Ótica e conectores adequados.

3.3. iSCSI

iSCSI é uma forma de conexão aos Storages que utiliza a rede IP, placas de rede comuns, Switches e cabos de redes comuns para essa tarefa.

É bem comum utilizarem Switches e cabos de 10Gbits/s, alguns Storages de alta performance podem utilizar conexões de 40Gbits/s ou 100Gbits/s e os de baixo custo com redes de 1Gbit/s.

Algumas configurações específicas podem utilizar uma mescla dessas tecnologias, também é bem possível que os dois cabos que normalmente seriam necessários para redundância, estejam ativos simultaneamente, dobrando a performance de acesso.

Embora seja possível funcionar o protocolo iSCSI sobre a Internet, não é recomendável que se utilizem muitos Switches e roteadores no caminho, nem que se utilize de distâncias muito longas, para evitar alta latência e problemas com os Jumbo Frames.

Aliás, em SAN de iSCSI é um dos locais onde recomenda-se utilizar os Jumbo Frames, com MTU de 9000 bytes.

Existe uma discussão entre fabricantes sobre iSCSI vs Fibre Channel, onde tentam impressionar nos números, 4Gb vs 8Gb vs 10Gb vs 16Gb vs 2x10Gb, etc… na prática, para SAN com até algumas dezenas de servidores, a diferença é bem pequena.

Claro que, ao utilizar uma SAN iSCSI de 1Gbit, ao transferir arquivos grandes vai ser bem mais demorado do que nas outras opções, mas na operação do dia a dia, em uso de banco de dados, ambiente virtual, em até dezenas de servidores, as opções acima de 8Gb e 10Gb são bem equivalentes.

3.4. Rede comum ou NAS

Storages do tipo NAS normalmente consistem em um único gabinete físico, ou alguns poucos gabinetes de disco conectados à controladora principal.

A controladora principal costuma ser conectada à rede comum, para que o NAS possa compartilhar seus Volumes através de protocolos comuns de compartilhamento de arquivos, disponíveis para acesso em estações Windows e Linux.

É um pouco diferente dos outros tipos de Storage, pois normalmente não serve servidores e sim estações de trabalho.

O principal diferencial dos Storages do tipo NAS estão em suas capacidades de economizar espaço em disco, gestão de arquivos, versionamento e outras funcionalidades para arquivos, por isso na parte de redes eles são apenas normais, como já tratamos anteriormente.

4. Escalabilidade

A maioria dos Storages consegue gerenciar dezenas de discos, mas as limitações começam a aparecer quando chegamos perto das centenas de discos.

É comum nos Storages de menor porte que as gavetas de disco sejam conectadas utilizando cabos SAS, o que permite à controladora principal acessar e gerenciar todos os discos.

Mas por limitações do protocolo SAS, existe uma quantidade específica de discos que uma controladora pode endereçar, se o Storage não permitir múltiplas controladoras trabalhando em simultâneo, encontrará o limite em poucas centenas de discos (96 discos em alguns modelos, 192 em outros).

Também, uma controladora costuma ter uma quantidade específica de Cache para agilizar as respostas e possui CPU e memória para gerenciar o armazenamento dos blocos. Esses recursos podem se esgotar em ambientes mais complexos.

Para superar esses limites, é necessário que o Storage possua a capacidade de ter várias controladoras operando em simultâneo, ou múltiplas conexões com as gavetas de discos, para poder ter múltiplos canais para endereçar os discos.

Claro que estamos falando de Storages com milhares de discos, usado por grandes corporações, citamos esse caso apenas como exemplos dos problemas que começam a aparecer em grandes ambientes, mas claro, é endereçado pelos principais fabricantes com modelos top de linha.

Exemplo de Storage de médio porte, no rack à esquerda, na parte superior, estão duas controladoras, na sequência 4 gavetas de disco rápidos, depois 23 gavetas de discos de alta capacidade, apesar do tamanho físico (2m x 60cm x 1m cada rack), ainda estamos falando de “apenas” 372 discos.

4.1. SAN (Storage Area Network)

Como já comentamos, a maioria das controladoras de Storages possui apenas algumas portas para conexão com servidores.

Isso limitaria muito o uso dos Storages, ou seria muito caro adicionar diversas portas para conectar múltiplos servidores, sem a certeza de que seriam utilizadas essas portas nos ambientes menores.

Para contornar essa limitação e permitir aumento do ambiente com os investimentos sob medida, são criados ambientes SAN.

Para montar uma SAN (Storage Area Network), conectamos o Storage a um Switch (Switch de Fibra Ótica para Storages Fibre Channel, ou Switches comuns de redes para Storages iSCSI).

A fim de manter a redundância e evitar um único ponto de falha, as SAN são normalmente compostas por dois Switches e cada controladora do Storage é conectada simultaneamente em ambos.

O mesmo acontece com os servidores, todos são conectados aos dois Switches, criando redundância para todas as conexões.

Exemplo de SAN com conexões redundantes para o Storage e para os Servidores

Assim, temos escalabilidade, podendo inclusive adicionar mais Controladoras de Storage ou mais Switches para suportar uma quantidade maior de Servidores.

4.2. Multipath

Considerando os ambientes SAN com redundância, onde servidores são conectados por no mínimo duas interfaces aos Storages, não faz sentido utilizar apenas uma interface em produção e deixar a outra em Standby.

Para contornar essa limitação, existe um recurso chamado Multipath, que em uma tradução literal significa Múltiplos Caminhos.

É uma solução de software, onde as requisições de leitura são enviadas para as duas conexões, normalmente alternando entre elas a cada pacote solicitado.

Isso permite praticamente dobrar a velocidade de transmissão, em um ambiente com Storage iSCSI de 10Gbits, teríamos 20Gbits possíveis de performance de transmissão.

Digo que é performance possível, pois o limitador possivelmente serão os discos, a não ser que seja uma configuração de tamanho razoável, será difícil sustentar 20Gbits/s de leitura ou gravação por longos períodos.

5. Segurança

Além dos recursos de gerência dos dados, distribuição entre os discos de alta performance e baixo custo, redundância e proteção dos dados, a maioria dos Storages ainda possuem alguns recursos avançados para aumentar a segurança dos dados, listados abaixo:

5.1. HDs de Spare

Os HDs estão sujeitos a falhas, tanto mecânicas para os discos (HDDs) quanto de desgaste para os SSDs.

Para evitar problemas de fabricação de uma série específica de HDs, normalmente os fabricantes de Storage usam discos de diversos lotes diferentes na composição para cada clientes, distribuindo os discos em múltiplos clientes, diminuindo assim a chance que uma falha de fabricação afete um cliente determinado e corrompa os dados.

Mesmo com esses cuidados, os HDs instalados em um mesmo Storage acabam passando pelo mesmo stress no dia a dia, como vibrações durante o transporte, flutuações de energia em caso de problemas na alimentação, pequenas descargas de energia estática ou por indução, calor concentrado em determinadas áreas.

Com isso, a possibilidade de falha nos HDs de um determinado Storage depois de um tempo de operação aumenta e a probabilidade de dois HDs apresentarem problemas em um intervalo pequeno é maior ainda devido ao stress compartilhado.

Nesses casos, a falha de 2 ou 3 HDs no intervalo de algumas horas pode ocorrer e mesmo nos RAIDs mais seguros, caso a empresa não detecte a falha dos HDs e não faça a substituição rapidamente, isso geraria um cenário catastrófico de perda de dados.

Por conta disso, é boa prática que em Storages maiores existam alguns discos que ficam em modo Spare, ou modo de espera. Nos equipamentos mais avançados, esses HDs ficam até desligados (é possível observar o led apagado).

Quando ocorrer a falha de um HD, o disco Spare é automaticamente energizado e o Storage começa a reconstrução do RAID com os dados existentes nos demais discos.

Esse processo pode demorar algumas horas, mas o fato de iniciar a reconstrução do RAID imediatamente é o suficiente para minimizar a possibilidade de problemas simultâneo nos demais HDs, diminuindo em muito a probabilidade de perda de dados.

A quantidade de HDs de Spare recomendada varia a cada fabricante, mas tende a ser 1 disco a cada 12 até 1 disco a cada 6, isto é, uma gaveta com 12 discos costuma ter 2 discos de Spare e 10 discos para uso.

5.2. Snapshots

Snapshot é um recurso aplicado aos Volumes (área de disco apresentada aos servidores) que permite “tirar uma foto” dos dados em um determinado momento do tempo e depois acessar esses dados como se fosse um Volume comum, ou mesmo restaurar os dados desse momento no tempo.

Esse recurso é encontrado em Storages gerenciados, mas é mais comum encontrá-los em Storages Virtualizados, onde o ônus do recurso é menor.

O funcionamento de Snapshots em Storages Virtualizados normalmente é o seguinte: o operador pede para o Storage executar um Snapshot em um determinado momento (digamos, antes de iniciar uma rotina de upgrade do ERP).

A partir desse momento, novos dados no Volume são armazenados em novas áreas de disco, quando os servidores pedirem por esses dados, serão usados essas novas áreas.

Caso o operador precise, poderá dar um comando para o Storage retornar os dados no momento em que o Snapshot foi tirado.

Alguns Storages permitem criar novos Volumes a partir do Snapshot, onde só é ocupado espaço em disco relativo aos dados diferentes entre os Volumes, com isso, a criação de ambientes de testes e homologação fica muito mais fácil.

Algumas implementações podem reservar um espaço para Snapshot como estratégia de backup rápida, como forma de complementar os backups externos, melhorando ainda mais a disponibilidade dos dados e resiliência a falhas.

Essa estratégia de backup é comum e recomendada por exemplo em provedores de Nuvem.

5.3. Replicação

Para fins de recuperação de desastres, alguns Storages podem oferecer o recurso de Replicação Offsite, ou seja, replicação dados em outro datacenter.

Normalmente com um link dedicado de dados é possível replicar de forma síncrona (isto é, armazenar simultaneamente nos dois lugares) até alguns quilômetros de distância. É um recursos para empresas grandes (em área territorial) ou que coincidam de ter alguma filial próximo ao ponto de origem dos dados, onde é possível criar esse link dedicado.

De forma assíncrona, é possível criar cópias até do outro lado do planeta, alguns Storages permitem por exemplo a replicação dos Snapshots. Se demorar, por exemplo, 40 minutos para transferir um Snapshot entre os datacenters, pode-se criar um plano de replicação de hora em hora.

Com os modelos de NAS, também existem estratégias de replicação, por exemplo, usando equipamentos Storage NAS instalados nas filiais replicando para um Storage central na matriz, todos os arquivos são replicados automaticamente e quase instantaneamente, sem necessidade de rotinas e com vários recursos para salvar largura de banda. É uma estratégia interessante, pois mantem a performance para acesso aos mesmos arquivos nas filiais e matriz muito alta, enquanto oferece redundância dos dados.

Enfim, dependendo da necessidade de proteção contra desastres, utilizar os recursos existentes nos Storages pode ser uma solução.

5.4. Criptografia

Presente nos HDs do tipo empresariais, é possível que os discos tenham os dados armazenados de forma criptografada automaticamente, sem a necessidade de instalar softwares adicionais.

Isso é importante em várias indústrias, evitando espionagem e vazamento de dados.

Esse tipo de disco se comunica com o Storage e a partir daí passa a criptografar automaticamente os dados, caso o disco seja instalado em outro equipamento, os dados estarão inacessíveis, pois a chave pertencia àquele conjunto.

Para o sistema operacional que está acessando, o uso é transparente e não existe impacto de performance, pois normalmente existe um chip integrado on HD para o serviço de cifrar e decifrar os dados.

Enfim, um recurso simples, que protege os dados corporativos de forma transparente.

6. Quando usar ou não Storage e qual tipo para cada aplicação

Como toda resposta para projetos de TI, depende da situação, vamos analisar alguns casos.

Principais benefícios de utilizar Storage:

  • Centralização dos dados
  • Melhoria de performance
  • Melhoria de gerenciamento de espaço disponível para as aplicações – se você comprar 10 servidores com 1Tb de espaço cada, caso 1 dos servidores precise de mais espaço com o tempo, não tem como tirar um pedaço de HD dos demais para instalar esse servidor, já com o Storage, pode-se comprar os mesmos 10x1Tb de HDs, distribuir 500Gb cada servidor e ir alocando espaço conforme os dados crescem.
  • Possibilidades de replicação, snapshots e outros recursos de segurança

Alguns entraves:

  • Necessidade de treinamento de um profissional, ou terceirização do gerenciamento do Storage – por mais simples que seja, sempre haverão situações mais complexas que precisem de alguém treinado, como upgrade de firmware, mas isso pode ser fornecido pelo fabricante do Storage durante o período de garantia ou por uma empresa de serviços
  • Custo de aquisição – principalmente para projetos pequenos, de 1 ou 2 servidores

Alguns projetos onde o Storage oferece benefícios claros:

  • Virtualização de Servidores – como explicamos nesse outro artigo sobre virtualização de servidores, com uma SAN é possível utilizar recursos avançados de virtualização criando um cluster
  • Virtualização de Desktops – para centralização dos dados e melhor performance, embora depende do projeto
  • Cluster de Banco de Dados – com versões específicas de banco de dados, é possível colocar 2 ou mais servidores trabalhando simultaneamente sobre os mesmos dados, provendo mais performance e resiliência do ambiente
  • Projetos de CFTV – devido à alta demanda de espaço, é comum projetos maiores utilizarem Storage para armazenar os dados
  • Projetos que envolvam replicação de dados – como replicação entre filial e matriz, ou mesmo replicação dos dados a distância

Alguns projetos onde o Storage não faz sentido:

  • Clusters de servidores para Processamento – alguns aplicativos usam uma pequena quantidade de dados e sobre os mesmos realizam um processamento intensivo para encontrar soluções, por exemplo, numa pesquisa de moléculas, nesse caso, um simples compartilhamento de arquivos feito a partir de um servidor principal é o suficiente para gerenciar o cluster e armazenar os resultados
  • Cluster de Big Data – normalmente esse tipo de cluster usa armazenamento distribuído, com cada servidor tendo uma parte dos dados para consultar, filtrar e processar e no final unificar os resultados, esse tipo de cluster tem suas políticas próprias de replicação de dados entre os nós e curiosamente, não é recomendável nem utilizar RAID sobre os discos dos nós (já escrevemos sobre isso nesse outro artigo)

Sobre o tipo da conexão do Storage e limitação de usos:

  • NAS – ideal para servir arquivos em um ambiente de Desktops. Alguns NAS suportam o protocolo NFS que pode ser usado para Cluster de Virtualização, claro que é recomendável isolar o ambiente
  • iSCSI 1Gbit – funciona bem para virtualização e banco de dados genéricos (ERPs, CRMs, etc), pode apresentar lentidão em backup ou quando precisar transferir muitos dados pela limitação das interfaces
  • iSCSI 10Gbit – ótimo desempenho para virtualização, arquivos e bancos de dados genéricos
  • Fibre Channel – ótimo desempenho para virtualização, arquivos, bancos de dados, principalmente em ambientes maiores, também é o modelo recomendável se houverem transferências de arquivos muito grandes, como em edição de vídeos

Enfim, existem Storages para todos os tipos de aplicações, use o conhecimento dos fornecedores, parceiros e consultores para escolher a melhor opção para sua empresa.

Matéria originalmente publicada no Blog do Sky Monitor.

Fernando Ulisses dos Santos

Mais artigos deste autor »

Empreendedor em Empresas de Tecnologia da Informação.

Pós-Graduado em Segurança da Informação, certificado VMware VCAP-DTD.

Atualmente trabalha no seu mais novo projeto, o Sky Monitor.

Idealizou e criou o PowerBiz, ferramenta para Convertion Rate Optimization em Marketing Digital.

Criou o Business Monitor, um mini sistema de BI para geração de Dashboards em tempo real.

Fundador da Blue Solutions, onde trabalhou em dezenas de projetos de virtualização, reestruturação, implantação e migração de Datacenter em empresas de todos os portes.


3 Comentários

PAULO CESAR ALVES DA SILVA
1

Muito boa essa explicação, direto ao ponto! Parabéns!
Me surgiu uma dúvida, é possível utilizar discos de mais de um storage de protocolos diferentes ao mesmo tempo?

Fernando Ulisses dos Santos
2

Oi Paulo,
Sim, é possível e bem simples de fazer, não tem nenhum requisito especial.
No caso de uma iSCSI e NFS pode-se utilizar a mesma interface, fazíamos bastante isso em laboratório, armazenando templates de máquinas virtuais no ambiente NFS (um Storage SO-HO) e instanciando no ambiente iSCSI (um Storage Enterprise).
Para Fibre Channel, basta o servidor ter as duas interfaces, uma para Fibre Channel e outra de rede 10Gb para conectar ao iSCSI.
Não é comum adquirir esse tipo de estrutura, pois as interfaces extras e cabos extras encarecem o projeto e a manutenção, mas pode ser usado, por exemplo, durante a migração entre ambientes.
Já tive esse tipo de caso, migrando um ambiente virtual entre um storage Fibre Channel e um iSCSI, instalamos uma interface de iSCSI em um dos servidores antigo e conectamos ao Storage novo (ele já estava conectado no Storage antigo), nós fazíamos o vMotion da máquina virtual para esse servidor que estava nas duas SANs, depois fazíamos um Storage vMotion dos discos da SAN antiga (Fibre) para a nova (iSCSI) e no final fazíamos o vMotion da máquina virtual para um servidor novo, migramos dezenas de máquinas virtuais entre servidores e Storages sem downtime.

Edison José da Silva Junior
3

Matéria excelente, parabéns! Sanou muitas das minhas dúvidas, e com toda certeza consegui expandir muito meu conhecimento.

Deixe seu comentário

Seu endereço de e-mail não será publicado. Campos com * são obrigatórios!