Desmistificando o Storage Corporativo

De uma década para cá, o storage corporativo se tornou cada vez mais presente na infraestrutura de TI das empresas. É um equipamento fundamental para quem deseja disponibilidade e alto desempenho. O problema é que, por se tratar de uma tecnologia relativamente recente, e que poucos profissionais, particularmente em início de carreira, têm a oportunidade de conhecer de perto, acaba se criando um mito em torno do assunto, o que só contribui para a falta de informação. E porque é importante conhecer o storage? Porque o volume de dados vem crescendo em um ritmo vertiginoso, e nada indica que essa tendência vá mudar nos próximos anos. Para lidar com volumes de dados multi-terabyte, o armazenamento local (disco interno) simplesmente não é uma opção. Fora isso, conforme o volume de dados aumenta, em muitos casos a demanda por desempenho aumenta, logo é necessário um equipamento que tenha os recursos e a robustez necessária para suportar essa demanda.

Com base em tudo o que foi citado, este artigo se propõe a desmistificar o storage ao abordar os principais assuntos relacionados de forma clara e objetiva. A ideia não é que o leitor se transforme em um especialista em storage da noite para o dia, mas sim que o conteúdo exposto aqui sirva de ponto de partida para um aprendizado mais profundo, sem deixar de lado a necessidade do saber prático para o dia a dia.

Configuração Física

Neste tópico mostraremos os componentes de hardware mais comuns em uma solução de storage, bem como um exemplo de arquitetura típica de SAN.

Hardware

Como usuários finais de um storage corporativo, vemos apenas os discos acessíveis por um servidor. Para nós e para o servidor é transparente se esse disco é local ou se faz parte de uma SAN (Storage Area Network). A seguir, descrevemos os equipamentos necessários para que uma solução desse tipo funcione corretamente.

Storage

O storage é um equipamento que permite a instalação de uma grande quantidade de discos de tipos diversos (veja o BOX 1) e possui formas de conectividade para permitir o acesso por diversos servidores. O storage é tipicamente composto por:

· Controladoras ou storage processors (Figura 1), que gerenciam toda a configuração do equipamento, a conectividade externa, o acesso aos discos e ao cache de dados. Normalmente há mais de uma, para redundância em caso de falha;

· Gavetas ou Drive enclosures (Figura 2), que são os acessórios que recebem os discos.

Os equipamentos mais sofisticados são construídos de forma modular, de modo que é possível a expansão pela adição de mais controladoras ou drive enclosures posteriormente. Na Figura 3 é possível ver um storage completo com seus módulos montado em rack.

Figura 1. Storage Processor.

Figura 2. Drive Enclosure.

Figura 3. Storage montado em rack, visão frontal.

Switch

Os switches (Figura 4) têm o papel de implementar a conectividade entre os servidores e o storage. Normalmente é utilizado mais de um, também por questões de redundância.

A conexão com os servidores é feita a partir de cabos, cujo tipo varia de acordo com o switch utilizado. Os tipos mais comuns atualmente são:

· Fiber Channel (FC), que utiliza fibra ótica para o tráfego de dados, e que suporta desde distâncias pequenas (até 100m, chamada “shortwave”) até grandes distâncias (até 50 km, chamada “longwave”). Conexões FC utilizam um tipo de switch especial comumente chamado de “SAN switch”;

· iSCSI (Internet SCSI), que utiliza switches de rede comuns e cabos de rede UTP (par trançado) ou fibra ótica.

As conexões FC podem operar em velocidades que variam de 1 a 16 Gbps, sendo que as mais comuns atualmente são de 4 e 8 Gbps. As conexões iSCSI dependem da infraestrutura de rede, e podem utilizar conexões de 1 ou 10 Gbps, dependendo do switch de rede utilizado.

O fato de a tecnologia iSCSI utilizar switches de rede comuns traz uma grande vantagem em termos de custo, pelo fato desta infraestrutura já existir nas empresas, mas normalmente com desempenho inferior aos switches FC (Fiber Channel), devido ao fato de trafegar comandos SCSI sobre o protocolo TCP/IP, o que tem um impacto significativo. Switches FC é a escolha comum em soluções que demandam alto desempenho.

As conexões FC e iSCSI de 10 Gbps, que utilizam fibras óticas como meio, necessitam de transceivers (conversores de mídia) para cada porta de conexão. Esses conversores (veja a Figura 5) se chamam GBIC (Gigabit Interface Converter), e servem para converter o sinal da fibra (luz) para o sinal eletrônico do switch e vice-versa. Na Figura 6 é possível ver um exemplo de conector de fibra ótica, utilizado para conexão com GBICs.

É comum se utilizar o termo “fabric” para descrever o switch SAN.

Figura 4. Switch SAN. Repare nas portas vazias, prontas para receber as GBICs.

Figura 5. GBIC – Gigabit Interface Converter

Figura 6. Conector de fibra ótica

HBA (Host Bus Adapter)

HBA (Figura 7) é a placa que instalamos nos servidores para permitir a conectividade com a SAN. Normalmente possuem duas portas (para redundância) eexistem modelos específicos para conexões FC e iSCSI (no caso do iSCSI, podem ser utilizadas até placas de rede comuns).

A HBA utilizada em conexões FC possui um identificador único chamado WWN (World Wide Name), que possui papel similar a um endereço MAC de uma placa de rede. Esse identificador é utilizado nas configurações realizadas nos switches SAN para identificar as conexões de cada servidor.

Figura 7. HBA – Host Bus Adapter.

Todos esses equipamentos se comunicam utilizando os comandos do protocolo SCSI (Small Computer System Interface), criado nos anos 80 e que originou diversos conectores, que começaram a cair em desuso com a chegada do SAS (que significa Serial Attached SCSI, uma evolução dos padrões anteriores). Os conectores SCSI se foram, mas o protocolo permaneceu.

Arquitetura Física Típica

Um disco tradicional funciona dentro do servidor, com distâncias de cabos pequenas (10-20 cm) e com cabeamento e conectores protegidos pelo gabinete. Quando falamos de SAN, os equipamentos muitas vezes estão em racks separados, e às vezes até em prédios separados, o que traz um fator de risco adicional à solução. Por esse motivo a redundância é fundamental em uma solução de storage.

No diagrama apresentado na Figura 8 podemos ver uma arquitetura típica de SAN: um storage com duas controladoras que possuem duas portas cada, dois switches SAN e alguns servidores. Cada controladora passa por cada um dos switches, e cada porta das placas HBA dos servidores também vão para switches separados. Dessa forma, se um switch,uma controladora ou uma porta de HBA falhar, o sistema inteiro continua a funcionar.

abrir imagem em nova janela

Figura 8. Arquitetura Típica de uma SAN

Configuração lógica

Depois de explicar os componentes físicos da solução, vamos à configuração lógica dos equipamentos.

Uma vez que o storage esteja instalado (processo que normalmente é feito pelo fabricante), os servidores com suas placas HBA, e tudo isso conectado através de switches SAN, como no desenho da Figura 8, temos duas tarefas importantes:

· Configuração dos discos: é a configuração dos discos para permitir que sejam utilizados pelas aplicações;

· Configuração da conectividade: é a configuração que permite que todos os equipamentos se comuniquem entre si, e mais importante, que não acessem recursos indevidamente.

Configuração dos discos – O que é RAID ?

Quando pensamos em storage corporativo, 100% das vezes pensamos em RAID. O RAID traz diversas vantagens em relação à configuração de um disco stand alone, como por exemplo, segurança e melhor desempenho. Aqui vale uma pausa para discutirmos o que é RAID. O termo RAID significa Redundant Array of Independent Disks, eé uma tecnologia que permite o agrupamento lógico de discos (array) para obter melhor desempenho, segurança ou custo.O RAID é classificado em níveis (levels), que determinam o funcionamento dos discos na configuração selecionada, e o tipo de redundância.

Para determinar o nível de RAID ideal para cada caso sempre devem levar em conta três fatores: custo, desempenho e segurança de dados. Normalmente quando obtém o melhor em dois desses fatores, se perde no terceiro. É tudo uma questão de escolher o mais apropriado para cada necessidade.

Existem vários níveis de RAID, mas os que foram consagrados pelo uso e, portanto são os mais comuns, são apresentados a seguir:

· 0 (striping): É o nível de RAID que oferece o melhor desempenho e custo, com a contrapartida de não oferecer segurança. Os dados são distribuídos pouco a pouco em cada disco do array, o que faz com que o acesso de leitura e escrita seja muito rápido, mas em caso de perda de um disco, o array inteiro falha. Só é utilizado em situações particulares onde a segurança de dados não é importante (por exemplo, discos temporários para renderização de vídeos, que demandam alto desempenho, mas que o processo pode ser reiniciado caso os discos falhem);

· 1 (mirroring - espelhamento): Oferece ótima relação entre desempenho e segurança, com o custo de utilizar no mínimo metade do espaço total para garantir a redundância. Todos os dados que são gravados em um disco são automaticamente gravados em um ou mais discos, o que garante a segurança dos dados caso um disco falhe. Teoricamente, no entanto, é possível utilizar mais de dois discos em RAID 1, o que aumentaria o número de cópias dos dados (um array RAID 1 com três discos, por exemplo, possui o dado original em um disco mais duas cópias), mas na prática isso não é comum. Normalmente são utilizados apenas dois discos para formar um array RAID 1, que tolera a perda de apenas um disco;

· 10 (striping de mirror): Funciona como um array RAID 0 construído no topo de dois ou mais arrays RAID 1. Com isso oferece desempenho próximo ao do RAID 0 com a redundância do RAID 1. É o nível mais indicado quando se deseja máximo desempenho com segurança, mas é o mais caro de todos: utiliza metade do espaço total para redundância, como no RAID 1, e são necessários ao menos quatro discos para formar um array RAID 10.

Para este nível de RAID, o mecanismo de tolerância a falhas é um pouco mais complicado. Um array RAID 10 tolera a perda de até um disco por “array” RAID 1, ou seja, se temos seis discos em RAID 10, podemos pensar em três pares de discos em RAID 1 unidos para formar um array RAID 0. Nesse caso, podemos perder até um disco de cada par, mas não os dois discos de um mesmo par;

· 5 (striping com paridade distribuída): Oferece ótima relação entre custo e segurança, mas o desempenho de escrita é abaixo dos demais devido ao esforço de manutenção dos dados de paridade, que servem para reconstruir o array no caso de falha de um disco. Utiliza normalmente o espaço de um disco apenas para manter a redundância, e são necessários no mínimo três discos para formar um array RAID 5. Tolera a perda de até um disco.

O cálculo de paridade, que garante a segurança do RAID 5, funciona da seguinte forma: pense em três discos idênticos, onde todas as posições de gravação de dados possuem um endereço específico que seja comum a todos os discos, ou seja, a terceira posição de todos os discos se chama “3”, por exemplo. Ao gravar um bit em um determinado endereço, a controladora RAID faz um cálculo (XOR, operador lógico “ou exclusivo”) entre esse bit e o bit do endereço três de um dos discos vizinhos, gerando um terceiro bit, que é o bit de paridade. Esse bit de paridade será gravado no endereço três de um disco diferente dos dois utilizados para o cálculo. Isso é realizado para todos os dados que são gravados em um array RAID 5, e esse processo é feito de uma forma que a cada dado gravado, a combinação de discos utilizados para gerar a paridade e o disco utilizado para gravá-la sejam diferentes. Dessa forma, quando um disco é perdido, é possível reconstruir os seus dados a partir dos dados e bits de paridade dos demais;

· 6 (striping com dupla paridade): Similar ao RAID 5, mas grava dois bits de paridade para cada bit gravado. Por isso tem desempenho de escrita fraco, mas tem a grande vantagem de suportar a falha de até dois discos do array.

Para concluir, vale notar que boa parte dos equipamentos atuais de storage suporta a configuração de um ou mais discos como hot-spare, que têm a função de “estepe” em situações de falha. Nesses casos, o storage, ao detectar uma falha, pode iniciar um rebuild do array utilizando o disco de spare automaticamente, sem intervenção humana.

Seleção do nível de RAID

Para determinar qual nível de RAID devemos utilizar, é preciso pensar em quatro questões importantes:

· Quanto espaço é necessário?

· Qual é o orçamento?

· Qual é a necessidade de segurança?

· Qual é a necessidade de desempenho?

Na prática, essas perguntas devem vir antes da compra dos equipamentos, para determinar a configuração do equipamento a ser comprado. No entanto, para o nosso exercício mental de não especialistas, vale fazê-las agora, supondo que temos ao nosso dispor todos os recursos que desejarmos (a realidade normalmente é bem diferente).

Conhecer bem os níveis de RAID, ao ponto de sugerir com autoridade qual deve ser utilizado, é fundamental para todo profissional de infraestrutura, até para evitar generalizações do tipo “RAID 5 é ruim” ou “RAID 10 é o melhor”. Cada um é mais apropriado para determinado caso.

Para responder às três primeiras perguntas, não é preciso um grande esforço, e elas estão intimamente ligadas. No entanto, a resposta à questão do desempenho é a mais complicada e que exige mais atenção. Na seção final deste artigo, que fala de workloads e IOPS, podemos ver uma explicação detalhada sobre a relação entre workload, IOPS e nível RAID, bem como exemplos dessa lógica.

Uma vez determinado o nível RAID, podemos criar nosso primeiro array de discos, também conhecido como RAID group. Esse array deve ser dividido em Logical Units, ou LUNs (LUN no singular). A logical unit é como uma partição de disco, só que de fato é a partição de um array, que por sua vez é a união de vários discos (partição da união?!?). Simplificando: os discos são unidos fisicamente como um array com a configuração de nível RAID, e depois divididos logicamente em LUNs para serem acessados pelos servidores. Uma vez que a LUN seja apresentada ao servidor, este passa a tratá-la como um disco comum, que deve ser formatado para depois ser utilizado.

Configuração da conectividade

Para que o disco possa ser apresentado ao servidor, existem mais alguns passos a serem realizados, que estão relacionados à segurança:

· Zoning: é a configuração feita no switch SAN que diz quais portas falam com quais. Normalmente é feita de forma que a HBA de um servidor acesse somente a HBA da controladora do storage, de modo a não permitir acessos indevidos;

· Configuração de Storage Groups: é a configuração feita no storage que diz quais LUNs podem ser acessadas por quais servidores. É a segunda camada de proteção a acessos indevidos, ao não permitir que um servidor acesse um disco que não lhe pertence. Aqui vale um parêntese: em ambientes de cluster, onde dois ou mais servidores precisam acessar um determinado disco, todos os servidores devem fazer parte do mesmo storage group que os discos, e o controle de qual servidor acessa qual disco é feito via software.

O ato de adicionar uma LUN a um storage group existente configura o ato de apresentar o disco para o servidor. A partir deste momento, o disco estará visível para o sistema operacional.

Concluídas estas tarefas, o storage está pronto para ser utilizado.

Funcionalidades importantes

Após ler a explicação até aqui, deve estar claro que o storage oferece uma série de vantagens em relação a uma configuração de disco interno, principalmente na capacidade de implementar soluções de alto desempenho.

Além disso, o storage normalmente possui uma série de funcionalidades adicionais que são menos conhecidas, mas não menos importantes, do ponto de vista de gerenciamento. A seguir estão descritas algumas dessas funcionalidades:

· Clone: é a capacidade de clonar os dados de uma determinada LUN. A vantagem do clone em comparação a uma cópia de arquivos do sistema operacional, é que o clone ocorre inteiro dentro do storage, sem tráfego pela SAN, e por isso tende a ser muito mais rápido. É útil em migrações de servidores onde se deseja ter um backup completo e rápido;

· Snapshot: é a capacidade de tirar uma “fotografia” de uma determinada LUN em uma posição no tempo. Snapshots normalmente são implementados utilizando uma técnica chamada “copy-on-write”, que somente grava a versão antiga dos dados no snapshot conforme estes são alterados na LUN original. Dessa forma, o snapshot tem um tamanho bastante pequeno quando criado, e vai crescendo conforme a LUN original é alterada. A função mais importante do snapshot é permitir que se restaure o estado dos dados de uma LUN àquele que existia no momento em que o snapshot foi criado. É útil em aplicações de patches, quando se deseja poder desfazer as alterações sem restaurar um backup, por exemplo;

· Thin provisioning: é a capacidade de alocar uma LUN que possua alocação dinâmica, ou seja, podemos criar uma LUN “thin” de 100 GB, mas ela só ocupará o espaço que estiver em uso pelo servidor, similar aos discos de crescimento dinâmico dos produtos de virtualização. Isso é útil quando não temos uma estimativa precisa da necessidade de alocação de espaço para um servidor, e, portanto não queremos comprometer uma área do storage desnecessariamente;

· Storage Pools e Tiering: é a alternativa aos arrays/RAID groups tradicionais, e que vem ganhando espaço ultimamente. Em vez de configurar arrays para cada aplicação, selecionando um tipo de disco específico, alguns equipamentos oferecem a opção de criar um storage pool com muitos, se não todos os discos do storage, misturando discos rápidos e lentos. O storage passa então a analisar a carga submetida e a identificar o perfil de acesso de cada dado. Uma vez identificado o perfil, o storage realoca dados muito acessados para discos mais rápidos, e dados pouco acessados para discos mais lentos.

As LUNs são criadas diretamente sobre o storage pool, e você pode recomendar (repare o termo) em qual camada (“tier”) de discos aquela LUN deve operar. No final, quem decide onde a LUN vai ficar é o storage, após a análise, que tipicamente ocorre uma vez por dia. A ideia aqui é que o storage tem mais condições do que nós de analisar os dados de acesso para decidir onde é melhor colocar cada LUN, e ele tem a capacidade de refazer essa alocação todos os dias. Na prática, nem os fabricantes recomendam o uso de pools para aplicações que exigem máximo desempenho, mas para ambientes onde o desempenho não é tão crítico, a facilidade de administração é bastante compensadora, pois libera o administrador da tarefa de controlar a ocupação array por array;

· Replicação block-level: é a capacidade de manter uma replicação online de LUNs no mesmo storage ou em storages diferentes, até em localidades diferentes, no nível de bloco do disco, sem se importar com o conteúdo. A LUN replicada fica em um estado chamado de “crash-consistent”, ou seja, similar ao estado em que um disco fica quando o computador é desligado abruptamente. Contudo, com os file systems modernos (NTFS, ext3, ext4) que possuem journaling, isso normalmente não é um problema. Essa funcionalidade é muito útil para a criação de sites de contingência (disaster recovery). Soluções de replicação block-level normalmente precisam de um software opcional instalado no storage, comprado à parte.

Workloads, IOPS, eficiência de espaço e “calculadora RAID”

Normalmente utilizamos a métrica de IOPS (I/Os por segundo) para falar de desempenho, ou mais especificamente de carga de trabalho (workload), quando vamos especificar a necessidade de desempenho de um array de discos para uma determinada aplicação, e a partir dessa informação realizar o dimensionamento apropriado. Cada tipo de disco possui um valor nominal de IOPS suportado, que somado ao tipo de RAID e à quantidade de discos do array nos dá uma estimativa de quantos IOPS o array irá suportar.

Na Tabela 1 podemos ver uma lista de valores típicos de IOPS para modelos comuns de disco, retirada do manual de um equipamento de porte intermediário de um grande fabricante do mercado (considerando I/O randômico, pior caso).

Tabela 1. Valores médios de IOPS por tipo de disco.

Cada nível de RAID, devido às suas particularidades de implementação, possui determinado fator de impacto de escrita. O fator de impacto funciona como um multiplicador, de modo que para obtermos a quantidade real de escritas que serão realizadas no array, é preciso multiplicar a quantidade de escritas realizadas pelo sistema operacional pelo fator de impacto.

Quanto maior o fator de impacto, menor o desempenho de escrita no array. A Tabela 2 mostra os fatores de impacto para os níveis de RAID mais comuns.

Tabela 2. Fatores de Impacto de Escrita por nível de RAID.

Quando dizemos que o RAID 5 possui impacto 4, isso significa que para cada escrita realizada por uma aplicação no servidor, o storage irá realizar 4 escritas nos discos que compõem o array.

Outra informação importante é a eficiência de espaço de cada nível de RAID. Precisamos desses valores para determinar qual será o espaço útil do nosso array. Na Tabela 3 podemos ver as fórmulas de eficiência de espaço para os níveis de RAID mais comuns.

Tabela 3. Eficiência de Espaço por nível de RAID.

Resumindo, para determinar a configuração de um array é preciso considerar:

· Capacidade de IOPS do tipo de disco selecionado;

· Distribuição do I/O entre leituras e escritas (percentual de cada), para avaliar o impacto da escolha do nível do RAID;

· Eficiência do nível do RAID escolhido, para determinar quanto espaço útil terá disponível.

Outra informação importante é o tipo de I/O realizado pela aplicação, se sequencial ou randômico. No nosso caso, como estamos utilizando valores de IOPS pensando em acesso randômico, que é o pior caso, podemos ignorar essa informação (o arquiteto de storage normalmente não pode, mas nós não somos os especialistas aqui).

Tomando como base os números das Tabelas 1, 2 e 3, podemos pensar em uma série de cálculos para nos guiar no dimensionamento de arrays.

Para exercitar os conceitos apresentados, propomos dois exemplos aqui, que demonstram bem a complexidade do assunto storage, e que servirão como base para o cálculo de dimensionamento.

Exemplo 1: Dimensione um array de discos em um storage para suportar um banco de dados de 5 TB. Temos a informação de que é um banco de dados com grande volume de transações durante o dia, que em momentos de pico atinge 5.000 IOPS, e que 60% desse acesso é de escrita.

Ao analisar o enunciado do problema, podemos perceber que:

· 60% do acesso é de escrita. Assim sendo, não faz sentido escolhermos um nível de RAID que penalize muito a escrita, como os níveis 5 ou 6. Por se tratar de um banco de dados, podemos supor que há a necessidade de redundância, o que faz com que descartemos o nível 0. Nossa escolha nesse caso será pelo RAID 10;

· Comparando a demanda de IOPS (5.000) com o volume de IOPS médio suportado por um disco rápido, não-SSD (180, de acordo com a Tabela 1), podemos perceber que precisaremos de muitos discos:

5.000 IOPS / 180 IOPS por disco = 27,7 discos

· Ao considerarmos que 60% desse acesso é de escrita, e o fator de impacto de escrita do RAID 10 é 2, de acordo com a Tabela 2, temos o seguinte cálculo:

( ((5000 * 60%) * 2) + (5000 * 40%) ) / 180 = 44,4 discos

Decompondo a fórmula, temos que:

60% de 5000 IOPS de escrita = 3000 IOPS

40% de 5000 IOPS de leitura = 2000 IOPS

3000 IOPS de escrita * 2 (fator de impacto de escrita do RAID 10) = 6000 IOPS

Total de IOPS = 6000 + 2000 = 8000 IOPS

8000 (Total de IOPS) /180 (IOPS por disco) = 44,4 discos

Desse exemplo, podemos derivar a seguinte fórmula:

D = ( ((iops * w) * i) + (iops * r) ) / iops_avg

Onde:

D: Total de discos a ser utilizado;

iops: Total de IOPS para o qual se deseja dimensionar o array;

i: fator de impacto de escrita para o nível de RAID;

w: percentual de escrita dos IOPS totais;

r: percentual de leitura dos IOPS totais;

iops_avg: IOPS médio do tipo de disco a ser utilizado no array;

Após calcular a quantidade de discos necessária, é preciso definir o tamanho do disco a ser utilizado. Ao consultar a Tabela 3 podemos obter a fórmula de eficiência de espaço do RAID 10, que é x/2, onde x é a capacidade somada de todos os discos. Pelo cálculo anterior, identificamos que precisamos de 5 TB em 44 discos. Logo, temos:

5000 = 44x/2

ou

x = 10000/44

x = 227 GB por disco

Arredondando o resultado obtido para o próximo tamanho comum de disco, temos discos de 300 GB. Para confirmarmos se o nosso cálculo está correto, podemos inverter a conta, e com o tamanho de disco proposto, temos:

(300*44)/2 = 6600 GB

Assim, com 44 discos FC ou SAS de 15.000 RPM e 300 GB, conseguimos atender à demanda do nosso banco de dados com folga.

Exemplo 2: Dimensione um array de discos em um storage para suportar um servidor de arquivos de 10 TB. Temos a informação de que é um servidor de arquivos pouco utilizado, com muitos dados históricos, que em momentos de pico atinge 500 IOPS, e que 80% desse acesso são de leitura.

Ao analisar o enunciado do problema, podemos perceber que:

· 80% do acesso são de leitura e precisamos de 10 TB úteis. Nesse caso, podemos escolher um nível de RAID mais econômico, como o 5 ou 6. Para efeito de comparação, faremos a conta com os dois;

· Se o servidor de arquivos é pouco utilizado, podemos configurar o nosso array com discos mais lentos e baratos. Escolhemos, então, os discos NL-SAS de 7200 RPM, que fazem 90 IOPS cada.

A seguir é apresentado o exemplo de cálculo para um RAID 5 com discos NL-SAS de 7200 RPM:

Quantidade de IOPS médio do disco NL-SAS 7200 RPM (Tabela 1): 90

Fator de impacto do RAID 5 (Tabela 2): 4

Eficiência de espaço do RAID 5 (Tabela 3): 1-1/n

Repetindo a fórmula do exemplo anterior, temos:

( ((500 * 20%) * 4) + (500 * 80%) ) / 90 = 8,88 discos

Arredondando para o inteiro mais próximo, temos 9 discos em RAID 5.

Para determinar o tamanho do disco desejado, utilizamos a fórmula de eficiência do RAID 5:

1-(1/9) = 0,89

10 TB (total de espaço necessário) / 9 discos / 0,89 = 1,25 TB por disco

Agora, faremos o cálculo considerando o uso de RAID 6 com discos NL-SAS de 7200 RPM:

Quantidade de IOPS médio do disco NL-SAS 7200 RPM (Tabela 1): 90

Fator de impacto do RAID 6 (Tabela 2): 6

Eficiência de espaço do RAID 6 (Tabela 3): 1-2/n

Repetindo a fórmula do exemplo anterior, temos:

( ((500 * 20%) * 6) + (500 * 80%) ) / 90 = 11,11

Arredondando para o inteiro mais próximo, temos 11 discos em RAID 6.

Para determinar o tamanho do disco desejado, utilizamos a fórmula de eficiência:

1-(2/11) = 0,81

10 TB (total de espaço necessário)/ 11 discos / 0,81 = 1,12 TB por disco

Nos dois casos, arredondando o resultado para o próximo tamanho de disco existente no mercado, temos discos de 1,5 TB. Se optarmos pelo RAID 6, serão necessários dois discos a mais, porém com suporte à falha de até dois discos, o que pode ser uma vantagem dependendo da importância dos dados em questão.

Conclusão

Neste artigo foram apresentados os principais componentes envolvidos em uma solução de storage corporativo, as principais configurações necessárias e foi fornecida uma explicação sobre RAID e suas indicações. Além disso, foram mostrados exemplos de workload e de dimensionamento para volume e desempenho.

É importante reforçar que sempre devemos confiar o trabalho de configuração ao arquiteto ou administrador do storage, que tem a experiência para avaliar todos os parâmetros necessários e tomar a melhor decisão possível. Estes profissionais normalmente precisam levar em consideração outros fatores ao desenhar uma solução de storage, como o número ótimo de discos por array dependendo do nível de RAID e a quantidade de discos disponível. A questão é que, apesar de ser o especialista em storage, nem sempre esse técnico é especialista na sua aplicação, e aí é importante saber falar a “língua” do storage para conseguir estabelecer essa ponte e obter o melhor resultado possível.