Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
Aplica-se a SUSE Enterprise Storage 5

2 Requisitos e recomendações de hardware

Os requisitos de hardware do Ceph dependem bastante da carga de trabalho de E/S. Os requisitos e as recomendações de hardware a seguir devem ser considerados um ponto de partida para o planejamento detalhado.

Em geral, as recomendações apresentadas nesta seção são baseadas em cada processo. Se houver vários processos localizados na mesma máquina, os requisitos de CPU, RAM, disco e rede deverão ser incrementados.

2.1 Nós de armazenamento de objetos

2.1.1 Requisitos mínimos

  • No mínimo, 4 nós OSD, com 8 discos OSD cada, são necessários.

  • Para OSDs que não usam BlueStore, 1 GB de RAM por terabyte de capacidade bruta do OSD é o mínimo exigido para cada nó de armazenamento OSD. É recomendável 1,5 GB de RAM por terabyte de capacidade bruta do OSD. Durante a recuperação, 2 GB de RAM por terabyte de capacidade bruta do OSD pode ser o ideal.

    Para OSDs que usam BlueStore, primeiro calcule o tamanho de RAM recomendado para os OSDs que não usam BlueStore, depois calcule 2 GB mais o tamanho do cache de RAM do BlueStore que é recomendado para cada processo de OSD e escolha o maior valor de RAM entre os dois resultados. Observe que o cache padrão do BlueStore é de 1 GB para HDD e de 3 GB para unidades SSD, por padrão. Em resumo, escolha o maior de:

    [1GB * OSD count * OSD size]

    ou

    [(2 + BS cache) * OSD count]
  • 1,5 GHz de um núcleo de CPU lógico por OSD é o mínimo necessário para cada processo do daemon OSD. É recomendável 2 GHz por processo do daemon OSD. Observe que o Ceph executa um processo do daemon OSD por disco de armazenamento. Não são considerados discos reservados exclusivamente para uso como diários OSD, diários WAL, metadados omap ou qualquer combinação desses três casos.

  • 10 Gb Ethernet (duas interfaces de rede vinculadas a vários switches).

  • Discos OSD nas configurações JBOD.

  • Os discos OSD devem ser usados exclusivamente pelo SUSE Enterprise Storage.

  • Disco/SSD dedicado para o sistema operacional, preferencialmente em uma configuração de RAID 1.

  • Se este host OSD hospedar parte de um pool de cache usado para criação de camada de cache, aloque pelo menos mais 4 GB de RAM.

  • Por motivos de desempenho do disco, os nós OSD devem estar completamente vazios e não devem ser virtualizados.

2.1.2 Tamanho mínimo do disco

Há dois tipos de espaço em disco necessários para execução no OSD: o espaço para o diário do disco (para FileStore) ou o dispositivo WAL/BD (para BlueStore) e o espaço principal para os dados armazenados. O valor mínimo (e padrão) para o diário/WAL/BD é de 6 GB. O espaço mínimo para os dados é de 5 GB, pois as partições menores do que 5 GB recebem automaticamente o peso de 0.

Portanto, embora o espaço mínimo em disco para um OSD seja de 11 GB, não é recomendável um disco menor do que 20 GB, mesmo para fins de teste.

2.1.3 Tamanho recomendado para o dispositivo WAL e BD do BlueStore

Dica
Dica: Mais informações

Consulte a Seção 1.4, “BlueStore” para obter mais informações sobre o BlueStore.

Veja a seguir várias regras para dimensionamento de dispositivo WAL/BD. Ao usar o DeepSea para implantar OSDs com o BlueStore, ele aplica as regras recomendadas automaticamente e notifica o administrador sobre o fato.

  • 10 GB do dispositivo de BD para cada Terabyte da capacidade do OSD (1/100º do OSD).

  • Entre 500 MB e 2 GB para o dispositivo WAL. O tamanho do WAL depende do tráfego de dados e da carga de trabalho, não do tamanho do OSD. Se você souber que um OSD é fisicamente capaz de processar pequenas gravações e sobregravações a um throughput muito elevado, será preferível ter mais WAL do que menos WAL. Um dispositivo WAL de 1 GB é uma boa solução que atende à maioria das implementações.

  • Se você pretende colocar o dispositivo WAL e BD no mesmo disco, recomendamos usar uma única partição para ambos os dispositivos, em vez de ter uma partição separada para cada um. Dessa forma, o Ceph pode usar o dispositivo BD também para operação de WAL. Portanto, o gerenciamento do espaço em disco é mais eficaz, pois o Ceph usa a partição BD para o WAL apenas quando há necessidade dela. Outra vantagem é que há pouca probabilidade de a partição WAL ficar cheia, e quando ela não for totalmente usada, seu espaço não será desperdiçado, mas usado para operação de BD.

    Para compartilhar o dispositivo BD com o WAL, não especifique o dispositivo WAL, mas apenas o dispositivo BD:

    bluestore_block_db_path = "/path/to/db/device"
    bluestore_block_db_size = 10737418240
    bluestore_block_wal_path = ""
    bluestore_block_wal_size = 0
  • Se preferir, você poderá colocar o WAL em seu próprio dispositivo separado. Nesse caso, é recomendável o dispositivo mais rápido para a operação de WAL.

2.1.4 Usando SSD para diários OSD

As SSDs (Solid-State Drives – Unidades de Estado Sólido) não têm partes móveis. Isso reduz o tempo de acesso aleatório e a latência de leitura enquanto acelera o throughput de dados. Como o preço delas por 1 MB é significativamente maior do que o preço dos discos rígidos giratórios, as SSDs são adequadas apenas para armazenamento menor.

Os OSDs podem observar um aprimoramento significativo no desempenho armazenando o diário em uma SSD e os dados de objeto em um disco rígido separado.

Dica
Dica: Compartilhando uma SSD para vários diários

Como os dados do diário ocupam relativamente pouco espaço, você pode montar vários diretórios de diário em um único disco SSD. Com cada diário compartilhado, lembre-se de que o desempenho do disco SSD é reduzido. Não recomendamos compartilhar mais do que seis diários no mesmo disco SSD, e 12 nos discos NVMe.

2.1.5 Número máximo recomendado de discos

Você poderá ter quantos discos forem permitidos em um servidor. Há algumas coisas que devem ser consideradas na hora de planejar o número de discos por servidor:

  • Largura de banda de rede. Quanto mais discos você tiver em um servidor, mais dados deverão ser transferidos por placa(s) de rede para as operações de gravação em disco.

  • Memória. Para atingir o melhor desempenho, reserve pelo menos 2 GB de RAM por terabyte de espaço em disco instalado.

  • Tolerância a falhas. Em caso de falha no servidor inteiro, quanto mais discos ele tiver, mais OSDs o cluster perderá temporariamente. Além disso, para manter as regras de replicação em execução, você precisa copiar todos os dados do servidor com falha para os outros nós no cluster.

2.2 Nós do monitor

  • Pelo menos três nós do Ceph Monitor são necessários. O número de monitores deve ser sempre ímpar (1+2n).

  • 4 GB de RAM.

  • Processador com quatro núcleos lógicos.

  • Uma SSD ou outro tipo de armazenamento rápido o bastante é altamente recomendado para monitores, principalmente para o caminho /var/lib/ceph em cada nó do monitor, pois o quorum pode ficar instável com altas latências de disco. É recomendada a configuração de dois discos no RAID 1 para redundância. É recomendável o uso de discos separados ou, pelo menos, de partições de disco separadas para que os processos do monitor protejam o espaço em disco disponível do monitor contra eventos como arquivo de registro muito grande.

  • Deve haver apenas um processo do monitor por nó.

  • A combinação de nós OSD, de monitor ou do Object Gateway apenas será suportada se houver recursos de hardware suficientes disponíveis. Isso significa que os requisitos para todos os serviços precisam ser incrementados.

  • Duas interfaces de rede vinculadas a vários switches.

2.3 Nós do Object Gateway

Os nós do Objeto Gateway devem ter de seis a oito núcleos de CPU e 32 GB de RAM (recomenda-se 64 GB). Quando outros processos são colocalizados na mesma máquina, os requisitos precisam ser incrementados.

2.4 Nós do servidor de metadados

O dimensionamento apropriado dos nós do Servidor de Metadados depende do caso de uso específico. Em geral, quanto mais arquivos abertos o Servidor de Metadados tiver que processar, mais CPU e RAM serão necessárias. Veja a seguir os requisitos mínimos:

  • 3G de RAM por cada daemon do Servidor de Metadados.

  • Interface de rede vinculada.

  • CPU de 2.5 GHz com, no mínimo, 2 núcleos.

2.5 Master Salt

Pelo menos 4 GB de RAM e uma CPU quad-core são necessárias. Isso inclui o openATTIC em execução no master Salt. Para clusters grandes com centenas de nós, 6 GB de RAM é a sugestão.

2.6 Nós do iSCSI

Os nós do iSCSI devem ter de seis a oito núcleos de CPU e 16 GB de RAM.

2.7 Recomendações de rede

O ideal é que o ambiente de rede em que você pretende executar o Ceph seja um conjunto vinculado de no mínimo duas interfaces de rede, que é dividido logicamente em uma parte pública e uma parte interna confiável por meio de VLANs. Se possível, o modo de vinculação recomendado é 802.3ad para fornecer largura de banda e resiliência máximas.

A VLAN pública serve para fornecer o serviço aos clientes, enquanto a parte interna permite a comunicação de rede autenticada no Ceph. O principal motivo disso é que, embora o Ceph ofereça autenticação e proteção contra ataques depois que as chaves secretas estão em vigor, as mensagens usadas para configurar essas chaves poderão ser transferidas abertamente e serão vulneráveis.

Dica
Dica: Nós configurados por DHCP

Se os nós de armazenamento foram configurados por DHCP, os tempos de espera padrão talvez não sejam suficientes para que a rede seja configurada corretamente antes que os vários daemons do Ceph sejam iniciados. Se isso acontecer, os MONs e OSDs do Ceph não serão iniciados corretamente (a execução de systemctl status ceph\* resultará em erros "não é possível vincular"). Para evitar esse problema, é recomendável aumentar o tempo de espera do cliente DHCP para, pelo menos, 30 segundos em cada nó no seu cluster de armazenamento. Para fazer isso, mude as seguintes configurações em cada nó:

Em /etc/sysconfig/network/dhcp, defina

DHCLIENT_WAIT_AT_BOOT="30"

Em /etc/sysconfig/network/config, defina

WAIT_FOR_INTERFACES="60"

2.7.1 Adicionando uma rede privada a um cluster em execução

Se você não especificar uma rede de cluster durante a implantação do Ceph, ele assumirá um ambiente de rede pública única. Enquanto o Ceph funciona bem com uma rede pública, seu desempenho e segurança melhoram quando você define uma segunda rede privada de cluster. Para suportar duas redes, cada nó do Ceph precisa ter pelo menos duas placas de rede.

Você precisará aplicar as mudanças a seguir a cada nó do Ceph. É relativamente rápido fazer isso em um cluster pequeno, mas pode ser muito demorado se você tem um cluster com centenas ou milhares de nós.

  1. Pare os serviços relacionados ao Ceph em cada nó do cluster.

    Adicione uma linha a /etc/ceph/ceph.conf para definir a rede de cluster. Por exemplo:

    cluster network = 10.0.0.0/24

    Se for necessário atribuir endereços IP estáticos ou anular as configurações de rede de cluster especificamente, você poderá fazer isso com o comando opcional cluster addr.

  2. Verifique se a rede privada de cluster funciona conforme esperado no nível do OS.

  3. Inicie os serviços relacionados ao Ceph em cada nó do cluster.

    sudo systemctl start ceph.target

2.7.2 Nós do monitor em sub-redes diferentes

Se os nós do monitor estiverem em várias sub-redes (por exemplo, localizados em salas distintas e atendidos por switches diferentes), você precisará ajustar o arquivo ceph.conf de acordo. Por exemplo, se os nós tiverem endereços IP 192.168.123.12, 1.2.3.4 e 242.12.33.12, adicione as seguintes linhas à seção global:

[global]
[...]
mon host = 192.168.123.12, 1.2.3.4, 242.12.33.12
mon initial members = MON1, MON2, MON3
[...]

Além disso, se você precisar especificar um endereço ou uma rede pública por monitor, adicione uma seção [mon.X] por monitor:

[mon.MON1]
public network = 192.168.123.0/24

[mon.MON2]
public network = 1.2.3.0/24

[mon.MON3]
public network = 242.12.33.12/0

2.8 Limitações de nomeação

Em geral, o Ceph não suporta caracteres não ASCII em arquivos de configuração, nomes de pool, nomes de usuário, etc. Ao configurar um cluster do Ceph, é recomendável usar apenas caracteres alfanuméricos simples (A-Z, a-z, 0-9) e pontuação mínima ('.', '-', '_’) em todos os nomes de objeto/configuração do Ceph.

2.9 OSD e monitor que compartilham um servidor

Embora seja tecnicamente possível executar Ceph OSDs e Ceph Monitors no mesmo servidor em ambientes de teste, é altamente recomendável ter um servidor separado para cada nó do monitor em produção. O principal motivo é o desempenho: quanto mais OSDs o cluster tiver, mais operações de E/S os nós do monitor precisarão executar. E, quando um servidor for compartilhado entre um nó de monitor e OSD(s), as operações de E/S do OSD serão um fator limitador para o nó do monitor.

Uma outra consideração é quando se deve compartilhar discos entre um OSD, um nó de monitor e o sistema operacional no servidor. A resposta é simples: se possível, dedique um disco separado ao OSD e um servidor separado a um nó de monitor.

Embora o Ceph suporte OSDs com base em diretório, um OSD deve sempre ter um disco dedicado diferente do sistema operacional.

Dica
Dica

Se for realmente necessário executar um nó OSD e de monitor no mesmo servidor, execute o monitor em um disco separado por meio da montagem do disco no diretório /var/lib/ceph/mon para obter um desempenho um pouco melhor.

2.10 Configuração mínima do cluster

  • Quatro Nós de Armazenamento de Objetos

    • 10 Gb Ethernet (duas redes vinculadas a vários switches)

    • 32 OSDs por cluster de armazenamento

    • Diário OSD pode residir no disco OSD

    • Disco de OS dedicado para cada Nó de Armazenamento de Objetos

    • 1 GB de RAM por TB de capacidade bruta do OSD para cada Nó de Armazenamento de Objetos

    • 1,5 GHz por OSD para cada Nó de Armazenamento de Objetos

    • Ceph Monitors, Ceph Gateway e Servidores de Metadados podem residir em Nós de Armazenamento de Objetos

      • Três nós do Ceph Monitor (requer SSD como unidade dedicada do OS)

      • Nós de Ceph Monitors, Object Gateways e Servidores de Metadados requerem implantação redundante

      • iSCSI Gateways, Object Gateways e Servidores de Metadados requerem mais 4 GB de RAM e quatro núcleos

  • Nó de gerenciamento separado com 4 GB de RAM, quatro núcleos, capacidade de 1 TB

2.11 Configuração recomendada do cluster de produção

  • Sete Nós de Armazenamento de Objetos

    • Nenhum nó único excede ~ 15% do total de armazenamento

    • 10 Gb Ethernet (quatro redes físicas vinculadas a vários switches)

    • Mais de 56 OSDs por cluster de armazenamento

    • Discos de OS RAID 1 para cada nó de armazenamento OSD

    • SSDs para Diário com o diário de SSD de proporção 6:1 para OSD

    • 1,5 GB de RAM por TB de capacidade bruta do OSD para cada Nó de Armazenamento de Objetos

    • 2 GHz por OSD para cada Nó de Armazenamento de Objetos

  • Nós dedicados de infraestrutura física

    • Três nós do Ceph Monitor: 4 GB de RAM, processador de 4 núcleos, SSDs RAID 1 para disco

    • Um nó de gerenciamento SES: 4 GB de RAM, processador de 4 núcleos, SSDs RAID 1 para disco

    • Implantação física redundante de nós de gateway ou Servidor de Metadados:

      • Nós do Object Gateway: 32 GB de RAM, processador de 8 núcleos, SSDs RAID 1 para disco

      • Nós do iSCSI Gateway: 16 GB de RAM, processador de 4 núcleos, SSDs RAID 1 para disco

      • Nós do Servidor de Metadados (um ativo/um standby ativo): 32 GB de RAM, processador de 8 núcleos, SSDs RAID 1 para disco

2.12 SUSE Enterprise Storage e outros produtos da SUSE

Esta seção contém informações importantes sobre a integração do SUSE Enterprise Storage com outros produtos da SUSE.

2.12.1 SUSE Manager

O SUSE Manager e o SUSE Enterprise Storage não estão integrados, portanto, o SUSE Manager não pode gerenciar um cluster do SUSE Enterprise Storage neste momento.

Imprimir esta página