Instalei em 4 nós um sistema operacional completamente novo com Proxmox. Cada nó possui 2xNVMe e 1xHD, uma NIC pública e uma NIC privada. Na rede pública há uma interface wireguard adicional em execução para comunicação do cluster PVE. A interface privada deve ser usada apenas para o próximo armazenamento distribuído.
# ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc mq state UP group default qlen 1000
link/ether 6c:b3:11:07:f1:18 brd ff:ff:ff:ff:ff:ff
inet 10.255.255.2/24 brd 10.255.255.255 scope global enp3s0
valid_lft forever preferred_lft forever
inet6 fe80::6eb3:11ff:fe07:f118/64 scope link
valid_lft forever preferred_lft forever
3: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether b4:2e:... brd ff:ff:ff:ff:ff:ff
inet 168..../26 brd 168....127 scope global eno1
valid_lft forever preferred_lft forever
inet6 2a01:.../128 scope global
valid_lft forever preferred_lft forever
inet6 fe80::b62e:99ff:fecc:f5d0/64 scope link
valid_lft forever preferred_lft forever
4: vmbr0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UNKNOWN group default qlen 1000
link/ether a2:fd:6a:c7:f0:be brd ff:ff:ff:ff:ff:ff
inet6 2a01:....::2/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::..:f0be/64 scope link
valid_lft forever preferred_lft forever
6: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
link/none
inet 10.3.0.10/32 scope global wg0
valid_lft forever preferred_lft forever
inet6 fd01:3::a/128 scope global
valid_lft forever preferred_lft forever
Os nós estão bem e o cluster PVE está funcionando conforme o esperado.
# pvecm status
Cluster information
-------------------
Name: ac-c01
Config Version: 4
Transport: knet
Secure auth: on
Quorum information
------------------
Date: Tue Dec 15 22:36:44 2020
Quorum provider: corosync_votequorum
Nodes: 4
Node ID: 0x00000002
Ring ID: 1.11
Quorate: Yes
Votequorum information
----------------------
Expected votes: 4
Highest expected: 4
Total votes: 4
Quorum: 3
Flags: Quorate
Membership information
----------------------
Nodeid Votes Name
0x00000001 1 10.3.0.4
0x00000002 1 10.3.0.10 (local)
0x00000003 1 10.3.0.13
0x00000004 1 10.3.0.16
O firewall PVE está ativo no cluster, mas há uma regra de que todos os nós PVE podem se comunicar entre si em qualquer protocolo, em qualquer porta e em qualquer interface. Isso é verdade - posso fazer ping, ssh, etc. entre todos os nós em todos os IPs.
Então instalei o ceph.
pveceph install
No primeiro nó eu inicializei o ceph com
pveceph init -network 10.255.255.0/24
pveceph createmon
Isso funciona.
No segundo - tentei o mesmo (não tenho certeza, se preciso definir a -networkopção - tentei com e sem). Isso também funciona.
Mas pveceph createmon falha em qualquer nó com:
# pveceph createmon
got timeout
Também posso acessar a porta 10.255.255.1:6789 em qualquer nó. O que quer que eu tente - estou recebendo um "tempo limite" em qualquer nó e depois no nó1. Além disso, desabilitar o firewall não tem nenhum efeito.
Quando removo a -networkopção, posso executar todos os comandos. Parece que não consegue falar através da segunda interface. Mas a interface está boa.
Quando defino network 10.3.0.0/24e cluster-network, 10.255.255.0/24ele também funciona, mas quero que toda a comunicação ceph seja executada via 10.255.255.0/24. O que está errado?
Responder1
Apenas para referência, a documentação oficial menciona os jumbo frames como trazendo importantes melhorias de desempenho:
https://ceph.io/en/news/blog/2015/ceph-loves-jumbo-frames/
Eu, por exemplo, vi melhorias no desempenho de leitura/gravação de cerca de 1400% após alterar o MTU nos 6 nós que configuramos (3 de armazenamento, 3 de computação).
E não, isso não é um erro de digitação. Passamos de 110 MB/s de leitura/gravação com ddtestes em VMs Linux para 1,5-1,6 GB/s posteriormente (rede pública de 1 Gbps, rede privada de 10 Gbps, OSDs em SSDs SATA).
Nota Bene: alterar o MTU em todas as interfaces de rede (pública E privada) parece muito importante! No nosso caso, alterá-lo apenas nas NICs privadas fez com que todo o sistema ficasse confuso.
Do documento de Redhat:
Importante
O Red Hat Ceph Storage exige o mesmo valor de MTU em todos os dispositivos de rede no caminho de comunicação, de ponta a ponta para redes públicas e de cluster.
Espero que isso ajude alguém! Saúde
Responder2
O problema é que o MTU 9000 é um problema. Mesmo quando executo o cluster Proxmox completo por meio da rede privada, há erros.
ip link set enp3s0 mtu 1500
Portanto, o Ceph tem um problema com jumbo frames.