Eu sou um grande fã da Ceph, a solução de software de código aberto, massivamente escalonável e definida para armazenamento. A sua capacidade de auto-cura e lidar com eventos de cluster de outra forma traumáticos (oh, você perdeu um nó? não há problema!), combinado com a falta de pontos únicos de falha, torna-o um favorito meu.
Below são três princípios simples que podem ajudar a impulsionar o design de clusters grandes ou pequenos.
Se o seu maior foco for dólares por megabyte de armazenamento, então naturalmente você pode gravitar em direção aos servidores que podem levar o maior número de discos, e os maiores discos que você pode obter.
Lê cuidadosamente aqui. Há algumas considerações com clusters ‘estreitos e profundos’:
- Cada nó contém uma percentagem maior dos dados do seu cluster. Exemplo: em um cluster de três nós cada nó retém 33% dos seus dados. Em um cluster de dez nós, é apenas 10% por nó. A perda de um único nó em um pequeno cluster resultará em substancialmente mais migração de dados, particularmente quando o cluster começar a preencher, e potencialmente uma interrupção se você não tiver configurado corretamente as proporções completa e quase completa do seu cluster.
- Forçando mais tráfego de rede através de menos nós. Ceph é um sistema de armazenamento baseado em rede, então com menos nós você está forçando muito tráfego de clientes sobre menos placas de rede. Isso se torna pior à medida que o número de discos por nó aumenta, já que você tem mais OSDs competindo por largura de banda limitada. Pior ainda, durante os eventos de recuperação o seu tráfego de recuperação compete com a E/S do cliente através da sua rede, impactando ainda mais a experiência do usuário.
- Para altas contagens de disco por nó, o controlador de disco pode ser um gargalo se ele não tiver largura de banda suficiente para carregar todos os seus discos na velocidade máxima.
- Aumentando o tempo de recuperação e cura quando você perde um nó inteiro, já que mais dados precisam ser replicados e recuperados.
Aggregate cluster escalas de desempenho muito bem como o número de nós aumenta. Aqui você pode encontrar uma comparação de um cluster de 3 nós versus 5 nós com BlueStore.
Se você está visando um cluster grande, resista à tentação de empacotar todos os discos no menor número possível de nós.
Para resumir:
- Escalas de cefalópodes muito bem, pois o número de nós aumenta.
- Dispondo muito poucos nós no cluster, você coloca mais dados de cluster em cada nó, aumentando a E/S de recuperação e o tempo de recuperação.
- Pode começar com apenas três nós, mas se puder distribuir os seus discos por mais nós, é melhor fazê-lo.
Sê generoso com a rede
Não vale a pena colocar mídia rápida em um servidor e depois manobrá-los com uma conexão de rede 1GbE. Aponte para 10GbE para produção, no mínimo, e melhor ainda procurar ter múltiplas interfaces 10Gb ligadas com Link Aggregation Control Protocol (LACP) para aumentar a largura de banda. Ceph é um sistema de armazenamento baseado em rede, portanto uma coisa que o cluster não deve faltar é largura de banda de rede.
Sempre separe sua rede voltada para o público de sua rede interna de cluster. A rede pública irá transportar tráfego cliente, enquanto a rede interna irá transportar tráfego de batimento cardíaco, replicação e recuperação entre OSDs. Se você puder dispensar os OSDs, carregue essas duas redes através de interfaces separadas. Separá-las melhora a capacidade de resposta dos clientes durante os eventos de recuperação e ajuda a completar os eventos de recuperação mais rapidamente, já que a E/S da recuperação não está competindo com a E/S do cliente na mesma DNI.
Remmbre-se também que a rede interna carrega o tráfego de replicação, portanto cada escrita na rede pública causará (n-1) escritas na rede interna, onde n é o número de réplicas. A Ceph só reconhecerá uma escrita para o cliente quando ela tiver sido escrita para a revista/WALs de todas as réplicas – para que você não queira que as escritas de réplicas fiquem engarrafadas na rede. Se você estiver fazendo uso pesado de pools replicados, considere dimensionar sua rede de cluster para ser n-1 vezes maior que a rede pública.
Lastly, para redundância assegure-se de que você está cabeando seus nós para switches redundantes no topo do rack. Você não quer perder um nó inteiro – ou conjunto de nós – porque um único switch falhou!
Para resumir:
- 10Gbit Ethernet para produção no mínimo.
- Separe suas redes públicas e de cluster, idealmente em diferentes NICs, mas pelo menos em VLANs/subnets diferentes.
- Recorde a regra (n-1) para dados replicados – considere dimensionar sua rede interna para ser n-1 vezes maior que a rede pública.
- Não se esqueça de instalar cabos para redundância, e estabelecer corretamente seus laços no nível do sistema operacional.
- E como um extra: não se esqueça dos jumbo frames em suas interfaces!
Mídia flash para metadados BlueStore.
Ceph reconhece uma gravação para o cliente apenas uma vez que os dados tenham sido escritos no log write-ahead (WAL) do OSD primário e nos WALs de todas as réplicas. Então, quanto mais rápido a escrita no WAL, mais rápido o Ceph irá reconhecer a escrita, e melhor o IOPS para o cliente.
Seu WAL, e idealmente seus metadados do BlueStore RocksDB, devem estar na mídia mais rápida que você pode obter – SSD no mínimo, e NVMe se possível. Se você está construindo um cluster HDD completo, considere gastar um pouco mais por nó e adicionar pelo menos dois dispositivos de mídia rápida para metadados e WAL.
Para evitar gargalos no seu dispositivo de mídia rápida, considere a velocidade de gravação sustentada dos seus discos de dados e compare-a com a velocidade de gravação sustentada do seu dispositivo rápido. Se o seu HDD pode gravar a 100MB/s sustentados e a sua SSD pode gerenciar 500MB/s sustentados, então mais de 4-5 OSDs por SSD e você será gargaloado pela SSD para gravação. O NVMe é perfeito para esse caso de uso, dada sua velocidade de gravação sustentada pode chegar aos gigabytes por segundo.
Lastly, sempre tenha mais de um dispositivo SSD/NVMe por nó para metadados/WAL para garantir que você não perca todos os OSDs no nó se um dispositivo de metadados falhar.
Para resumir:
- Ceph reconhece uma escrita em um cliente quando ela foi escrita no WAL do OSD primário e nos WALs de todas as réplicas. Ele faz isso para preservar a integridade dos seus dados.
- WAL e RocksDB devem estar na mídia mais rápida que você pode obter – idealmente NVMe – para obter uma resposta ao cliente o mais rápido possível.
- Não sobrecarregue sua assinatura de dispositivos rápidos para o seu WAL/RocksDB. Se o fizer, você está apenas deslocando o gargalo para o seu dispositivo rápido.
- Deixe mais de um dispositivo rápido para evitar perder todos os OSDs em um nó se seu dispositivo WAL falhar.
Summing up
Ceph é um sistema de armazenamento baseado em software de rede que se dimensiona horizontalmente excepcionalmente bem. Acima estão apenas alguns princípios para ajudá-lo a montar um sistema de alto desempenho – não vá muito estreito ou profundo, mantenha o cluster alimentado com largura de banda e use mídia rápida para seus metadados e WAL.