Porque normalizámos em HPE 3PAR all-flash

O nosso block storage corre em arrays HPE 3PAR all-flash, acedidos sobre Fibre Channel. Esta frase descreve mais uma decisão do que um produto: uma família de arrays, escolhida deliberadamente e aprendida em profundidade, em vez de um menu de níveis de storage montado a partir do que o canal oferecia. Este artigo é a defesa dessa decisão, e da ideia de perguntar a qualquer fornecedor que avalie se alguma vez tomou uma assim.

Cinco níveis de storage num menu significam cinco plataformas operadas de forma superficial

Abra as páginas de encomenda da maioria dos fornecedores e o storage é um dropdown: um nível SATA, um nível SSD, um nível NVMe, às vezes um nível de desempenho sem arquitetura nenhuma por trás das palavras. Cada linha desse menu é uma plataforma distinta que alguém tem de operar, com os seus próprios controladores, os seus próprios modos de falha, a sua própria telemetria e o seu próprio percurso de atualização de firmware. Um menu de cinco linhas é uma funcionalidade de compras. É também uma decisão de pessoal, porque a atenção da engenharia divide-se pelo número de plataformas que tem de cobrir.

Atenção dividida é profundidade perdida. Uma equipa que opera cinco famílias de arrays detém cinco fatias finas de experiência, e quando uma dessas plataformas se porta mal às 3 da manhã, a probabilidade de a pessoa de prevenção já ter trabalhado exatamente esta avaria exatamente nesta máquina cai a cada linha extra do menu. Nós reduzimos o menu.

A profundidade acumula-se quando todos os incidentes caem na mesma plataforma

Dominar uma plataforma é tanto um inventário de trabalho como um inventário mental: runbooks escritos sobre a telemetria real desta plataforma em vez de um manual genérico, e engenheiros no quadro que conseguem ler o interior do array e diagnosticá-lo ao nível do firmware.

A acumulação é o objetivo. Cada incidente que qualquer pessoa da equipa trabalha passa a fazer parte de uma biblioteca de falhas partilhada para a mesma máquina, de modo que o décimo encontro com uma classe de avaria começa da memória em vez da documentação. Espalhe os mesmos incidentes por um catálogo de cinco plataformas e a biblioteca fragmenta-se: a maioria das avarias é enfrentada por alguém que as vê pela primeira vez, e uma avaria vista pela primeira vez demora mais tempo exatamente no momento em que a sua carga de trabalho menos o pode suportar.

O que a profundidade compra, no dia a dia

O HPE 3PAR Peer Persistence mantém os volumes online se um array for abaixo, e os nossos engenheiros leem tempos de serviço e telemetria de caminhos nos arrays por rotina, por isso uma pergunta sobre storage é respondida a partir do array, não a partir de uma fila do fabricante. Distinguir um array doente de um caminho doente exige essa profundidade, nas mãos das mesmas pessoas que operam a SAN todos os dias.

A máquina em si, no registo público

Uma visita curta àquilo em que normalizámos, com todas as afirmações retiradas do registo público. O HPE 3PAR 8450 é o modelo all-flash da família 8000: dois a quatro nós controladores num backplane passivo full-mesh, um design a que a HPE chama Mesh-Active porque cada volume está ativo em todos os controladores ao mesmo tempo. Não há um controlador primário a partir do qual fazer failover. A família saiu no final de 2015, mas a linhagem é mais antiga e melhor: a 3PAR foi fundada em 1999 por arquitetos de sistemas da Sun Microsystems, o nome significa literalmente 3 Partners, e a empresa foi pioneira do thin provisioning. Em 2010 a HP e a Dell travaram uma guerra pública de ofertas por ela, da oferta inicial da Dell a $18 por ação até à oferta vencedora da HP a $33, cerca de $2,35 mil milhões. Gente séria quis muito esta máquina.

A ideia que tornou a 3PAR famosa é o chunklet, o termo oficial no documento de arquitetura da HPE. O sistema operativo corta cada disco em chunklets de 1 GiB e constrói o RAID a partir deles em vez de a partir de discos inteiros, de modo que cada volume acaba distribuído por todos os discos, atrás de todos os controladores e de todas as portas. Duas coisas resultam daí. Desempenho: não há disco quente, porque nenhum volume vive num disco em particular. E rebuilds: a capacidade de reserva está espalhada por todo o array em vez de estacionada num disco de reserva inativo, por isso um rebuild são muitos discos a ajudar ao mesmo tempo em vez de um único disco a beber por uma palhinha.

Cada controlador transporta também o Thin Express ASIC da HPE, de quinta geração no 8450, ao lado da CPU, a fazer em silício o trabalho em que os arrays de software queimam núcleos: detetar e descartar fluxos de zeros inline, calcular hashes de blocos para dedupe, calcular a paridade RAID e carimbar checksums de ponta a ponta, da porta do host até ao disco. Esse chip é grande parte da razão pela qual o array move block I/O sem drama.

Estas são afirmações da HPE, do documento de arquitetura, não resultados do nosso laboratório. A que merece ser sublinhada é a primeira: o próprio documento da HPE assinala que os arrays de dois controladores caem em cache write-through quando um controlador morre, o que é uma forma educada de dizer que ficam de rastos. Um 3PAR de quatro nós mantém a write cache espelhada e continua. É essa a diferença entre uma falha de controlador que aparece no seu gráfico de latência e uma que não aparece.

Uma nota honesta sobre esse número. As brochuras da HPE referem a família 8000 a escalar para lá de um milhão de IOPS nas configurações de topo, e os 3PAR maiores vão ainda mais alto. Os 545 mil são o que um 8450 registou de facto no benchmark independente, com a tabela de preços anexada: 23 cêntimos por IOPS SPC-1, o mais barato dos dez arrays mais rápidos da lista na altura. O medido vence a brochura, por isso o número medido é o que citamos.

Uma década em produção significa que o firmware está assente, os modos de falha estão documentados, as peças são abundantes, e nada do que esta máquina faz surpreende os engenheiros que a dominaram. É essa a nossa doutrina numa frase, e tem artigo próprio: compre a máquina séria.

Só nos desviamos quando o trabalho o merece

Normalização sem cláusula de saída é dogma, por isso aqui fica a nossa: só nos desviamos quando um trabalho o merece genuinamente. A versão geral deste argumento, incluindo porque é que uma base conhecida é o que torna seguro projetar uma verdadeira exceção, cobre as nossas decisões de rede, computação e fabric a par do storage em temos opiniões fortes sobre hardware. Este é o capítulo do storage.

Se está a avaliar um fornecedor, as perguntas sobre storage que vale a pena fazer, incluindo as que a maioria dos fornecedores não consegue responder, estão em o segredo sujo do seu fornecedor é o storage.