O que a palavra SSD esconde sobre o storage do seu fornecedor

Uma página de encomenda de hosting dá-lhe números exatos para núcleos e RAM e uma palavra para o storage, normalmente SSD. Essa única palavra cobre o maior fosso de qualidade do setor. Dois fornecedores podem imprimir a mesma palavra e estar a uma arquitetura inteira de distância: um guarda os seus dados num disco consumer atrás de uma placa RAID dentro do seu servidor, o outro guarda-os num array all-flash dedicado que continua a servir depois de esse servidor morrer. Aqui fica a diferença, em termos simples, e no fim, as cinco perguntas que vão arrancar a verdade a qualquer fornecedor, incluindo a nós.

Uma palavra, SSD, cobre três arquiteturas diferentes

O storage no hosting vem em três níveis, e o texto de produto dos três lê-se quase da mesma forma.

1. 01Disco local. Discos dentro do servidor, no controlador do próprio servidor. Rápido de aprovisionar e barato de vender, e o storage partilha todos os destinos da máquina: fonte de alimentação, backplane, motherboard, controlador. O nível inteiro é um único failure domain.
2. 02SSD atrás de uma única placa RAID. É aqui que está, na realidade, a maior parte do hosting vendido como enterprise. Os discos são normalmente componentes consumer ou prosumer escolhidos ao gigabyte, e o RAID protege-o de exatamente uma coisa, um disco morto, que é a falha mais barata que o storage tem. Não faz nada por um controlador morto, um backplane morto ou um servidor morto.
3. 03Uma SAN a sério. Storage como sistema de engenharia próprio: um array dedicado com dois controladores, os seus próprios discos e a sua própria rede para lá chegar. O array tem uma vida independente de qualquer nó de computação, o que muda o aspeto de um dia mau.

Não consegue distinguir estes níveis a partir do texto, porque o texto não o diz. Os mesmos cinco padrões aparecem em toda a categoria, parafraseados aqui porque são normas omnipresentes e não o pecado de uma empresa em particular.

Nenhuma destas frases diz que o storage é um array redundante separado, all-flash, acedido por dois fabrics independentes, que sobrevive à morte de qualquer servidor. Essa frase custa dinheiro a sério para poder ser impressa, por isso as páginas que a podem imprimir, imprimem-na. Quando o texto pára no adjetivo, a arquitetura normalmente também pára aí. Esse é o sinal.

Uma SAN mantém os seus dados vivos quando o servidor que corre a sua carga de trabalho morre

O objetivo de uma SAN é a separação de destinos. O seu disco é um LUN num array dedicado, e o servidor que corre a sua carga de trabalho é apenas a máquina que neste momento o monta.

A velocidade é a parte com que o texto começa sempre, por isso aqui fica a nossa, na única formulação que pomos por escrito: os nossos arrays servem num dígito de milissegundos ou melhor.

Normalizámos numa única plataforma de storage e aprendemo-la de cor

Normalizámos em HPE 3PAR all-flash sobre Fibre Channel: uma plataforma, escolhida e dominada. Só nos desviamos quando um trabalho o merece genuinamente. A normalização é o que compra a profundidade por trás de cada resposta deste artigo. O argumento geral a favor de hardware com opinião está no seu próprio artigo.

O seu próprio array corre sem contador

O block storage alugado cobra o disco ao gigabyte, outra vez pelo IOP aprovisionado, e outra vez à saída. É o seu array. Não há contador por IOP nem portagem de egress sobre os seus próprios dados. A economia completa do contador no disco, incluindo o que essas linhas de fatura da cloud cobram realmente e o que custa um pico real em flash que nos pertence, está em o contador no seu disco.

Cinco perguntas expõem o storage de qualquer fornecedor num único e-mail

Tudo o que está acima comprime-se em cinco perguntas. Levam um e-mail a enviar, e são muito difíceis de responder de forma impressionante sem uma SAN a sério por trás. Aqui ficam, com as nossas respostas registadas.