SAN com algumas unidades SSD ou muitos HDDs antiquados?

Minha empresa está tentando descobrir que tipo de SAN comprar. Isso é especificamente para servidores de banco de dados que estão se tornando restritos a E / S (o armazenamento é DAS no momento, mas estamos atingindo o limite de um único servidor e também queremos adicionar cluster).

Precisamos de uma solução que produza cerca de 3000 IOPS a longo prazo (atualmente atingimos o pico em torno de 1000 IOPS). A maioria de nossas operações de banco de dados são pequenas leituras / gravações. Com base em discussões com engenheiros da HP e outras pessoas on-line, um HP P2000 com 24 SAS HDs em uma configuração RAID 10 fornecerá pouco menos dessa velocidade por ~ $ 20K. Adicionar controladores e outros itens para criar a SAN nos coloca em torno de nosso orçamento máximo de US $ 30 mil.

Mas online, vejo que muitos SSDs SAS oferecem velocidades de 80.000 IOPS +. Isso é realista de se esperar? Em caso afirmativo, seria realista obter uma SAN de nível de entrada P2000 ou similar e lançar alguns SSDs lá? Nossos bancos de dados são pequenos, apenas um total de TB. Se fizéssemos isso, teríamos o dinheiro restante para comprar uma segunda SAN para espelhamento / failover, o que parece prudente.

Eu posso falar sobre as especificidades do que você está tentando realizar. Honestamente, eu não consideraria um HP P2000 / MSA2000 básico para seu propósito.

Esses dispositivos têm muitas limitações e, do ponto de vista do conjunto de recursos da SAN, nada mais são do que uma caixa de discos. Sem camadas, sem armazenamento em cache inteligente, no máximo 16 discos em um grupo de discos virtuais , recursos baixos de IOPS, suporte ruim a SSD (especialmente na unidade selecionada).

Você precisaria avançar para o HP MSA2040 para ver qualquer benefício de desempenho ou suporte oficial com SSDs. Além disso, você realmente deseja usar o iSCSI?

O DAS pode ser sua melhor opção se você puder tolerar o armazenamento local. O armazenamento flash PCIe estará dentro do seu orçamento, mas a capacidade precisará ser planejada com cuidado.

Você pode elaborar as especificações dos seus servidores reais? Marca / modelo, etc.

Se o armazenamento em cluster for obrigatório, outra opção é executar a unidade HP MSA2040, mas use uma unidade SAS em vez do iSCSI. Isso é menos oneroso que os outros modelos, permite conectar de 4 a 8 servidores, oferece baixa latência e excelente taxa de transferência e ainda pode suportar SSDs. Mesmo com os modelos Fiber ou iSCSI, esta unidade oferece mais flexibilidade do que a que você vinculou.

A regra de ouro que eu uso para E / S de disco é:

• 75 IOPs por eixo para SATA.

• 150 IOPs por eixo para FC / SAS

• 1500 IOPs por eixo para SSD.

Assim como as IOPs por matriz, considere também as IOPs por terabyte. Não é incomum acabar com uma taxa de IOP / TB muito ruim se estiver usando SATA + RAID6. Isso pode não parecer muito, mas muitas vezes você acaba com alguém identificando 'espaço livre' em uma matriz e deseja usá-lo. É comum as pessoas comprarem shows e ignorarem Iops, quando na verdade o oposto é verdadeiro na maioria dos sistemas empresariais.

Em seguida, adicione o custo da penalidade de gravação para RAID:

• 2 para RAID1, RAID1 + 0
• 4 para RAID5 (ou 4)
• 6 para RAID6.

A penalidade de gravação pode ser parcialmente atenuada, com grandes caches de gravação e nas circunstâncias certas. Se você tiver muitas E / S de gravação sequencial (como logs de banco de dados), poderá reduzir significativamente essas penalidades de gravação no RAID 5 e 6. Se você pode escrever uma faixa completa (por exemplo, um bloco por eixo), não precisa ler para calcular a paridade.

Suponha um conjunto 8 + 2 RAID 6. Em operação normal para uma única E / S de gravação, você precisa:

• Leia o bloco 'atualizado'.
• Leia o primeiro bloco de paridade
• Leia o segundo bloco de paridade
• Recompute a paridade.
• escreva todos os 3. (6 IOs).

Com uma gravação em faixa completa em cache - por exemplo, 8 'pedaços' consecutivos do tamanho da faixa RAID, você pode calcular a paridade em todo o lote, sem precisar de uma leitura. Então você só precisa de 10 gravações - uma para cada dado e duas paridades.

Isso torna sua penalidade de gravação 1.2.

Você também precisa ter em mente que o IO de gravação é fácil de armazenar em cache - não é necessário colocá-lo em disco imediatamente. Ele opera com uma restrição de tempo branda - desde que, em média, suas gravações recebidas não excedam a velocidade do eixo, tudo poderá ser executado na 'velocidade de cache'.

O IO de leitura, por outro lado, sofre uma restrição de tempo difícil - você não pode concluir uma leitura até que os dados sejam buscados. Os algoritmos de cache de leitura e carregamento de cache se tornam importantes nesse ponto - padrões de leitura previsíveis (por exemplo, seqüenciais, como você obteria do backup) podem ser previstos e pré-buscados, mas os padrões de leitura aleatórios não podem.

Para bancos de dados, geralmente sugiro que você assuma que:

• a maior parte do seu pedido de informação de base de dados é de leitura aleatória. (por exemplo, ruim para acesso aleatório). Se você puder pagar a sobrecarga, o RAID1 + 0 é bom - porque os discos espelhados fornecem duas fontes de leitura.

• a maior parte do seu IO 'log' é gravação sequencial. (por exemplo, bom para armazenamento em cache e, ao contrário do que muitos DBAs sugerem, você provavelmente deseja RAID50 em vez de RAID10).

A proporção dos dois é difícil, é difícil dizer. Depende do que o DB faz.

Como a E / S de leitura aleatória é o pior caso de armazenamento em cache, é onde o SSD realmente se destaca - muitos fabricantes não se incomodam em armazenar em cache o SSD porque, de qualquer maneira, é a mesma velocidade. Portanto, especialmente para itens como bancos de dados temporários e índices, o SSD oferece um bom retorno sobre o investimento.

Sua análise está bastante correta.

Use alguns HDDs para muitos GBs e muitos HDDs para algumas IOps.
Use alguns SSDs para muitas IOPs e muitos SSDs para alguns GBs

O que é mais importante para você? O espaço é o grande fator de custo para as soluções SSD, já que o preço por GB é muito maior. Se você está falando de um IOPs 4K necessários de um banco de dados de 200 GB, um par de SSDs o levará até lá. Ou uma matriz de 24 discos de 15 mil unidades, deixando muito espaço para armazenamento em massa.

A quantidade de IOps que você realmente obterá desses SSDs varia muito com base na infraestrutura de armazenamento (o ewwhite irá elaborar isso), mas é razoável obter esse tipo de velocidade. Especialmente com o Raid10, onde a paridade não está sendo computada.

Recentemente, construí um par de servidores de armazenamento para o meu empregador, usando o chassi Dell C2100, executando o FreeBSD 10.1 com doze unidades SATA corporativas Western Digital "SE" de 2 TB e 7200 rpm. As unidades estão em um único pool ZFS, composto por dois dispositivos virtuais RAIDZ-2 de 6 unidades (vdevs). Anexados ao pool, há um par de SSDs Intel DC S3500 supercap protegidos contra perda de energia; eles são usados ​​como SLOG e L2ARC. Ao testar o servidor em iSCSI, consegui atingir 7500-8200 IOPS. Nosso custo total, incluindo discos rígidos, foi de cerca de US $ 2700 por servidor.

No período em que esses sistemas baseados em BSD estão em execução, uma de nossas unidades SAN HP MSA2012i sofreu duas falhas no controlador e nossa outra unidade MSA2012i corrompeu um grande volume NTFS, exigindo 12 horas de tempo de inatividade para reparo.

A Dell e a HP vendem 10% de hardware e 90% prometem suporte que você nunca poderá utilizar.