Ir para o conteúdoIr para navegação de página: página anterior [tecla de acesso p]/próxima página [tecla de acesso n]
documentation.suse.com / Documentação do SUSE Enterprise Storage 7.1 / Guia de Implantação / Apresentando o SUSE Enterprise Storage (SES) / Requisitos e recomendações de hardware
Aplica-se a SUSE Enterprise Storage 7.1

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 Visão geral da rede

 

O Ceph tem várias redes lógicas:

  • Uma rede de front end chamada public network.

  • Uma rede interna confiável, a rede de back end, chamada cluster network. Isso é opcional.

  • Uma ou mais redes de cliente para gateways. Isso é opcional e está fora do escopo deste capítulo.

A rede pública é a rede pela qual os daemons do Ceph se comunicam entre si e com seus clientes. Isso significa que todo o tráfego de cluster do Ceph passa por essa rede, exceto quando há uma rede de cluster configurada.

A rede de cluster é a rede de back end entre os nós OSD para replicação, reequilíbrio e recuperação. Se configurada, essa rede opcional deve oferecer o dobro da largura de banda da rede pública com replicação de três vias padrão, já que o OSD primário envia duas cópias para outros OSDs por meio dessa rede. A rede pública está em um lado entre os clientes e os gateways para se comunicar com monitores, gerenciadores, nós MDS e nós OSD. Ela também é usada por monitores, gerenciadores e nós MDS para se comunicar com os nós OSD.

Visão geral da rede
Figura 2.1: Visão geral da rede
 

2.1.1 Recomendações de rede

 

Recomendamos uma única rede tolerante a falhas com largura de banda suficiente para atender aos seus requisitos. Para o ambiente de rede pública do Ceph, recomendamos duas interfaces de rede de 25 GbE (ou mais rápidas) vinculadas por meio de 802.3ad (LACP). Essa é considerada a configuração mínima do Ceph. Se você também usa uma rede de cluster, recomendamos quatro interfaces de rede de 25 GbE vinculadas. A vinculação de duas ou mais interfaces de rede proporciona melhor throughput por meio da agregação de links e, considerando os links e switches redundantes, melhora a tolerância a falhas e a capacidade de manutenção.

Você também pode criar VLANs para isolar diferentes tipos de tráfego em uma vinculação. Por exemplo, você pode criar uma vinculação para fornecer duas interfaces VLAN: uma para a rede pública e a segunda para a rede de cluster. No entanto, isso não é necessário ao configurar o projeto de rede do Ceph. Os detalhes sobre a vinculação das interfaces estão disponíveis em https://documentation.suse.com/sles/15-SP3/html/SLES-all/cha-network.html#sec-network-iface-bonding.

É possível aprimorar a tolerância a falhas por meio do isolamento dos componentes em domínios de falha. Para melhorar a tolerância a falhas da rede, a vinculação de uma interface de duas Placas de Interface de Rede (NIC, Network Interface Cards) separadas oferece proteção contra falhas de uma única NIC. Da mesma forma, criar uma vinculação entre dois switches protege contra falhas de um switch. Recomendamos consultar o fornecedor do equipamento de rede para projetar o nível de tolerância a falhas necessário.

Importante
Importante: Rede de administração não suportada

A configuração de rede de administração adicional, que permite, por exemplo, separar projetos de rede SSH, Salt ou DNS, não foi testada nem é suportada.

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 Ceph MONs e OSDs não serão iniciados corretamente (a execução do systemctl status ceph\* resultará em erros do tipo “impossível vincular”). Para evitar esse problema, recomendamos aumentar o tempo de espera do cliente DHCP para pelo menos 30 segundos em cada nó no 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.1.1.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. Defina a rede de cluster usando o seguinte comando: 

    # ceph config set global cluster_network MY_NETWORK

    Reinicie os OSDs para vinculação à rede de cluster especificada: 

    # systemctl restart ceph-*@osd.*.service

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

2.1.1.2 Nós de monitoramento em sub-redes diferentes

 

Se os nós do monitor estiverem em várias sub-redes, por exemplo, localizados em salas distintas e processados por switches diferentes, você precisará especificar o endereço da rede pública na notação CIDR: 

cephuser@adm > ceph config set mon public_network "MON_NETWORK_1, MON_NETWORK_2, MON_NETWORK_N

Por exemplo: 

cephuser@adm > ceph config set mon public_network "192.168.1.0/24, 10.10.0.0/16"
Atenção
Atenção

Se você especificar mais de um segmento de rede para a rede pública (ou cluster), conforme descrito nesta seção, cada uma dessas sub-redes deverá ser capaz de rotear para todas as outras. Do contrário, os MONs e outros daemons do Ceph em diferentes segmentos de rede não poderão se comunicar, e o resultado será um cluster dividido. Além disso, se você usa um firewall, certifique-se de incluir cada endereço IP ou sub-rede em seu iptables e abrir as portas para eles em todos os nós, conforme necessário.

2.2 Configurações de várias arquiteturas

 

O SUSE Enterprise Storage suporta as arquiteturas x86 e Arm. Ao considerar cada arquitetura, é importante notar que, de uma perspectiva de núcleo por OSD, frequência e RAM, não há diferença real entre as arquiteturas de CPU quanto ao dimensionamento.

Assim como nos processadores x86 menores (sem servidor), os núcleos de desempenho mais baixo com base em Arm podem não oferecer uma experiência ideal, principalmente quando usados para pools codificados para eliminação.

Nota
Nota

Em toda a documentação, SYSTEM-ARCH é usado no lugar de x86 ou Arm.

2.3 Configuração de hardware

 

Para obter a melhor experiência do produto, recomendamos começar com a configuração de cluster recomendada. Para um cluster de teste ou um cluster com menos requisitos de desempenho, documentamos uma configuração de cluster mínima suportada.

2.3.1 Configuração de cluster mínima

 

Uma configuração de cluster mínima do produto consiste em:

  • Pelo menos quatro nós físicos (nós OSD) com colocation de serviços

  • Ethernet dupla de 10 Gb como rede vinculada

  • Um Nó de Admin separado (pode ser virtualizado em um nó externo)

Veja abaixo uma configuração detalhada:

  • Nó de Admin separado com 4 GB de RAM, quatro núcleos, capacidade de armazenamento de 1 TB. Normalmente, esse é o nó do Master Salt. Os serviços e gateways do Ceph, como Ceph Monitor, Servidor de Metadados, Ceph OSD, Gateway de Objetos ou NFS Ganesha, não são suportados no Nó de Admin, pois ele precisa orquestrar os processos de atualização e upgrade do cluster de forma independente.

  • Pelo menos quatro nós OSD físicos, com oito discos OSD cada. Consulte a Seção 2.4.1, “Requisitos mínimos” para obter os requisitos.

    A capacidade total do cluster deve ser dimensionada de modo que, mesmo com um nó indisponível, a capacidade total usada (incluindo redundância) não exceda 80%.

  • Três instâncias do Ceph Monitor. Os monitores precisam ser executados do armazenamento SSD/NVMe, não de HDDs, por motivos de latência.

  • É possível fazer colocation dos monitores, do Servidor de Metadados e dos gateways nos nós OSD. Consulte a Seção 2.12, “OSD e monitor que compartilham um servidor” para saber sobre colocation do monitor. Se você fizer colocation dos serviços, os requisitos de memória e CPU precisarão ser somados.

  • O iSCSI Gateway, o Gateway de Objetos e o Servidor de Metadados exigem pelo menos 4 GB de RAM incremental e quatro núcleos.

  • Se você usa CephFS, S3/Swift ou iSCSI, serão necessárias pelo menos duas instâncias das respectivas funções (Servidor de Metadados, Gateway de Objetos, iSCSI) para redundância e disponibilidade.

  • Os nós devem ser dedicados ao SUSE Enterprise Storage e não devem ser usados para nenhuma outra carga de trabalho física, em containers ou virtualizada.

  • Se qualquer um dos gateways (iSCSI, Gateway de Objetos, NFS Ganesha, Servidor de Metadados etc.) for implantado em VMs, essas VMs não deverão ser hospedadas em máquinas físicas que processam outras funções do cluster. (Isso é desnecessário, pois eles são suportados como serviços com colocation.)

  • Ao implantar serviços como VMs em hipervisores fora do cluster físico principal, os domínios de falha devem ser respeitados para garantir a redundância.

    Por exemplo, não implante várias funções do mesmo tipo no mesmo hypervisor, como várias instâncias de MONs ou MDSs.

  • Na implantação em VMs, é importante principalmente garantir que os nós tenham uma forte conectividade de rede e uma boa sincronização de horário.

  • Os nós do hipervisor devem ser dimensionados adequadamente para evitar a interferência de outras cargas de trabalho que consomem recursos de CPU, RAM, rede e armazenamento.

Configuração de cluster mínima
Figura 2.2: Configuração de cluster mínima
 

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

 

Depois que você aumentar o cluster, recomendamos realocar os Ceph Monitors, os Servidores de Metadados e os Gateways para nós separados para melhorar a tolerância a falhas.

  • Sete Nós de Armazenamento de Objetos

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

    • A capacidade total do cluster deve ser dimensionada de modo que, mesmo com um nó indisponível, a capacidade total usada (incluindo redundância) não exceda 80%.

    • Ethernet de 25 Gb ou superior, cada uma vinculada ao cluster interno e à rede pública externa.

    • Mais de 56 OSDs por cluster de armazenamento.

    • Consulte a Seção 2.4.1, “Requisitos mínimos” para ver outras recomendações.

  • Nós dedicados de infraestrutura física.

2.3.3 Configuração de múltiplos caminhos

 

Para usar um hardware de múltiplos caminhos, verifique se o LVM vê multipath_component_detection = 1 no arquivo de configuração na seção devices. É possível executar o comando lvm config para verificar isso.

Se preferir, verifique se o LVM filtra os componentes mpath de um dispositivo por meio da configuração do filtro do LVM. Esse procedimento será específico do host.

Nota
Nota

Ele não é recomendado e deverá ser considerado apenas se multipath_component_detection = 1 não puder ser definido.

Para obter informações sobre configuração de múltiplos caminhos, consulte https://documentation.suse.com/sles/15-SP3/html/SLES-all/cha-multipath.html#sec-multipath-lvm.

2.4 Nós de armazenamento de objetos

 

2.4.1 Requisitos mínimos

 

  • As seguintes recomendações de CPU consideram os dispositivos independentemente do uso pelo Ceph:

    • 1x Thread de CPU de 2 GHz por spinner.

    • 2x Threads de CPU de 2 GHz por SSD.

    • 4x Threads de CPU de 2 GHz por NVMe.

  • Redes separadas de 10 GbE (pública/cliente e interna), 4x 10 GbE necessário, 2x 25 GbE recomendado.

  • RAM total necessária = número de OSDs x (1 GB + osd_memory_target) + 16 GB.

    Consulte o Seção 28.4.1, “Configurando o dimensionamento automático do cache” para obter mais detalhes sobre osd_memory_target.

  • Discos OSD nas configurações de JBOD ou nas configurações individuais de RAID-0.

  • Diário OSD pode residir no disco OSD.

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

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

  • Aloque pelo menos 4 GB de RAM adicional se esse host OSD for hospedar parte de um pool de cache usado para camadas de cache.

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

  • Por motivos de desempenho do disco, os nós OSD estão completamente vazios. Nenhuma outra carga de trabalho deve ser executada em um nó OSD, a menos que seja uma configuração mínima de Ceph Monitors e Ceph Managers.

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

Nota
Nota

Verifique se os nós OSD não têm dispositivos de blocos em rede mapeados, como iSCSI ou imagens de Dispositivo de Blocos RADOS.

2.4.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 dispositivo WAL/BD e o espaço principal para os dados armazenados. O valor mínimo (e padrão) para o 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.4.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.

  • Recomendamos reservar 4 GB para o dispositivo WAL. O tamanho mínimo do BD é 64 GB para cargas de trabalho apenas RBD, mas o tamanho recomendado do BD para cargas de trabalho do Gateway de Objetos e do CephFS é 2% da capacidade do dispositivo principal (sendo no mínimo 196 GB).

    Importante
    Importante

    Recomendamos volumes de BD maiores para implantações de alta carga, principalmente se houver uso elevado do RGW ou CephFS. Reserve parte da capacidade (slots) para instalar mais hardware e ter mais espaço no banco de dados, se necessário.

  • 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 é totalmente usada, o espaço dela não é desperdiçado, mas usado para operação do BD.

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

    Encontre mais informações sobre como especificar um layout de OSD no Seção 13.4.3, “Adicionando OSDs por meio da especificação DriveGroups”.

2.4.4 SSD para partições WAL/BD

 

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 ao armazenar as partições WAL/BD em um SSD e os dados de objetos em um disco rígido separado.

Dica
Dica: Compartilhando um SSD com várias partições WAL/BD

Como as partições WAL/BD ocupam relativamente pouco espaço, você pode compartilhar um disco SSD com várias partições WAL/BD. Com cada partição WAL/BD, lembre-se de que o desempenho do disco SSD é reduzido. Não recomendamos compartilhar mais do que seis partições WAL/BD no mesmo disco SSD, e 12 nos discos NVMe.

2.4.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. RAM acima de 2 GB é usada para o cache do BlueStore. Com o osd_memory_target padrão de 4 GB, o sistema tem um tamanho de cache inicial razoável para mídia giratória. Se você usa SSD ou NVME, considere aumentar o tamanho do cache e a alocação de RAM por OSD para maximizar o desempenho.

  • 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.5 Nós do monitor

 

  • Pelo menos três nós MON 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, MON ou do Gateway de Objetos 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.6 Nós do Gateway de Objetos

 

Os nós do Gateway de Objetos devem ter pelo menos seis núcleos de CPU e 32 GB de RAM. Quando outros processos são colocalizados na mesma máquina, os requisitos precisam ser incrementados.

2.7 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:

  • 4 GB de RAM para cada daemon do Servidor de Metadados.

  • Interface de rede vinculada.

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

2.8 Nó de Admin

 

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

2.9 Nós do Gateway iSCSI

 

Os nós do Gateway iSCSI devem ter pelo menos seis núcleos de CPU e 16 GB de RAM.

2.10 SES e outros produtos da SUSE

 

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

2.10.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 SES neste momento.

2.11 Limitações de nome

 

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.12 OSD e monitor que compartilham um servidor

 

Embora seja tecnicamente possível executar OSDs e MONs 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 MON precisarão executar. E, quando um servidor for compartilhado entre um nó do MON e o(s) OSD(s), as operações de E/S do(s) OSD(s) serão um fator limitador para o nó do monitor.

Outra consideração é quando se deve compartilhar discos entre um OSD, um nó do MON 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 OSD e um nó do MON no mesmo servidor, execute o MON em um disco separado por meio da montagem do disco no diretório /var/lib/ceph/mon para melhorar um pouco o desempenho.