Я установил на 4 узлах совершенно новую ОС с Proxmox. На каждом узле есть 2xNVMe и 1xHD, одна NIC публичная, одна NIC частная. В публичной сети есть дополнительный интерфейс Wireguard, работающий для связи с кластером PVE. Частный интерфейс должен использоваться только для будущего распределенного хранилища.
# 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
Узлы в порядке, и кластер PVE работает как положено.
# 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
Брандмауэр PVE активен в кластере, но есть правило, что все узлы PVE могут общаться друг с другом по любому протоколу на любом порту на любом интерфейсе. Это правда - я могу пинговать, ssh и т. д. между всеми узлами на всех IP.
Затем я установил ceph.
pveceph install
На первом узле я инициализировал ceph с помощью
pveceph init -network 10.255.255.0/24
pveceph createmon
Это работает.
Во втором случае - попробовал то же самое (не уверен, нужно ли устанавливать опцию -network- пробовал и с ней, и без нее). Тоже работает.
Но pveceph createmon дает сбой на любом узле с:
# pveceph createmon
got timeout
Я также могу достичь порта 10.255.255.1:6789 на любом узле. Что бы я ни пробовал - я получаю "got timeout" на любом узле, кроме node1. Отключение брандмауэра также не дает никакого эффекта.
Когда я убираю эту -networkопцию, я могу запускать все команды. Похоже, что он не может общаться через второй интерфейс. Но интерфейс в порядке.
Когда я устанавливаю сеть на 10.3.0.0/24и кластер-сеть на 10.255.255.0/24тоже работает, но я хочу, чтобы вся ceph-коммуникация работала через 10.255.255.0/24. Что не так?
решение1
Для справки: в официальной документации упоминается, что большие кадры обеспечивают существенное повышение производительности:
https://ceph.io/en/news/blog/2015/ceph-loves-jumbo-frames/
Я, например, заметил улучшение производительности чтения/записи примерно на 1400% после изменения MTU на 6 настроенных нами узлах (3 узлах хранения, 3 узлах вычислений).
И нет, это не опечатка. Мы перешли от 110 МБ/с чтения/записи при ddтестировании в виртуальных машинах Linux к 1,5-1,6 ГБ/с впоследствии (публичная сеть 1 Гбит/с, частная сеть 10 Гбит/с, OSD на твердотельных накопителях SATA).
Nota Bene: изменение MTU на всех сетевых интерфейсах (публичных И частных) кажется весьма важным! В нашем случае изменение только на частных сетевых картах привело к тому, что вся система сошла с ума.
Из документа Redhat:
Важный
Для Red Hat Ceph Storage требуется одинаковое значение MTU на всех сетевых устройствах на пути связи, как для общедоступных, так и для кластерных сетей.
Надеюсь, это кому-нибудь поможет!
решение2
Проблема в том, что MTU 9000 — это проблема. Даже когда я запускаю весь кластер Proxmox через частную сеть, возникают ошибки.
ip link set enp3s0 mtu 1500
Итак, у Ceph есть проблема с большими кадрами.