SAN com algumas unidades SSD ou muitos HDDs antiquados?

Question

Minha empresa está tentando descobrir que tipo de SAN comprar. Isso é especificamente para servidores de banco de dados que estão se tornando restritos de E / S (o armazenamento é DAS agora, mas estamos atingindo o limite de um único servidor e gostaríamos de adicionar também o 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 das nossas operações de banco de dados são pequenas leituras / gravações. Com base em discussões com engenheiros da HP e outros on-line, um HP P2000 com 24 HDs SAS em uma configuração RAID 10 oferecerá pouco menos que essa velocidade por ~ $ 20K. Adicionar controladores e outros itens para construir a SAN nos coloca em torno do nosso orçamento máximo de $ 30K.

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

    

Answer 1

Eu posso falar sobre os detalhes do que você está tentando realizar. Honestamente, eu não consideraria um HP P2000 / MSA2000 básico para o 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 hierarquia, sem cache inteligente, um máximo de 16 discos em um grupo Disco virtual , baixos recursos de IOPS, suporte deficiente a SSD (especialmente na unidade selecionada).

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

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

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

Se o armazenamento em cluster for imprescindível, outra opção é fazer a unidade HP MSA2040, mas usar uma unidade SAS em vez de iSCSI. Isso é menos dispendioso do que os outros modelos, permite a conexão de 4 a 8 servidores, oferece baixa latência e excelente taxa de transferência, e ainda suporta SSDs. Mesmo com os modelos Fiber ou iSCSI, esta unidade lhe daria mais flexibilidade do que aquela que você vinculou.

    

Answer 2

A regra geral que eu uso para o disco IO é:

• 75 IOPs por fuso para SATA.

• 150 IOPs por fuso para FC / SAS

• 1500 IOPs por fuso para SSD.

Assim como os IOPs por array também consideram IOPs por terabyte. Não é incomum acabar com uma PIO muito ruim por taxa de TB se estiver fazendo SATA + RAID6. Isso pode não parecer muito, mas você geralmente acabará com alguém localizando 'espaço livre' em um array e deseja usá-lo. É comum as pessoas comprarem gigs e ignorarem iops, quando realmente o oposto é verdadeiro na maioria dos sistemas corporativos.

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

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

A penalidade de gravação pode ser parcialmente atenuada em grandes caches de gravação e nas circunstâncias corretas. Se você tiver muitos IOs de gravação seqüencial (como logs de banco de dados), você poderá reduzir significativamente as penalidades de gravação no RAID 5 e 6. Se você conseguir escrever uma faixa completa (por exemplo, um bloco por fuso), não precisará ler para calcular a paridade.

Assuma um conjunto RAID 6 8 + 2. Em operação normal para um único IO de gravação, você precisa:

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

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

Isso faz com que a sua pena de escrita seja 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 no disco imediatamente. Ele opera sob uma restrição de tempo suave - desde que, em média, suas gravações recebidas não excedam a velocidade do fuso, todas poderão ser executadas na 'velocidade do cache'.

Read IO, por outro lado, sofre uma restrição de tempo - você não pode completar uma leitura até que os dados tenham sido buscados. Os algoritmos de cache de leitura e carregamento de cache se tornam importantes nesse ponto - padrões de leitura previsíveis (por exemplo, sequenciais, como se obteria a partir do backup) podem ser previstos e pré-buscados, mas padrões de leitura aleatórios não podem.

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

• a maior parte do seu IO 'banco 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 da sua IO 'log' é de 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 relação entre os dois é difícil é difícil de dizer. Depende do que o DB faz.

Como o IO de leitura aleatória é o pior caso para o armazenamento em cache, é onde o SSD realmente se encaixa - muitos fabricantes não se incomodam com o armazenamento em cache do SSD, porque é praticamente a mesma velocidade. Então, especialmente para coisas como bancos de dados temporários e índices, o SSD oferece um bom retorno sobre o investimento.

    

Answer 3

Sua análise está correta.

Use alguns HDDs para vários GBs e vários HDDs para algumas IOps.
Use alguns SSDs para muitos IOPs e muitos SSDs por alguns GBs

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

Quantas IOps você realmente obterá desses SSDs variam muito com base na infraestrutura de armazenamento (ewwhite vai elaborar sobre isso), mas é razoável obter esse tipo de velocidade. Especialmente com o Raid10, onde a paridade não está sendo calculada.

    

Answer 4

Recentemente, construí um par de servidores de armazenamento para meu empregador, usando o chassi Dell C2100, executando o FreeBSD 10.1 com doze drives SATA corporativos "SE" de 2TB 7200 rpm da Western Digital. As unidades estão em um único pool do ZFS que consiste em dois dispositivos virtuais RAIDZ-2 de 6 unidades (vdevs). Anexado ao pool estão um par de SSDs Intel DC S3500 que são supercap protegidos contra perda de energia, eles são usados como SLOG e L2ARC. Carregar o teste deste servidor através do iSCSI, consegui atingir 7500-8200 IOPS. Nosso custo total, incluindo discos rígidos, era de cerca de US $ 2700 por servidor.

No tempo em que esses sistemas baseados em BSD foram executados, uma de nossas unidades SAN MSA2012i sofreu duas falhas de controlador, e nossa outra unidade MSA2012i corrompeu um volume grande de NTFS que exigiu 12 horas de inatividade para reparo.

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