Fragen zu ceph nach Upgrade 5.4 auf 6.0

[Mario Hosse]

Hallo,

vielen Dank für die Anleitung und die geleistete Arbeit für das Upgrade.
Das Upgrade ging auf allen Nodes ohne Probleme durch.

Auf allen Nodes bekomme ich nach einem Reboot immer wieder die folgenden gleichen Meldungen pro Host:

1. Device-ID alle mon nach Reboot:

Jul 21 18:16:38 prox4d ceph-mon[2735]: 2019-07-21 18:16:38.480 7fa8976ef700 -1 mon.prox4d@3(electing) e8 failed to get devid for : fallback method has serial ''but no model

2. Meldung, dass die "device-class" zu "ssd" geändert werden soll auf allen osd und allen hosts :

Jul 21 16:59:34 prox3c ceph-osd[2762]: 2019-07-21 16:59:34.692 7fb65be0bf80 -1 osd.10 20026 mon_cmd_maybe_osd_create fail: 'osd.10 has already bound to class 'nvme', can not reset class to 'ssd'; use 'ceph osd crush rm-device-class <id>' to remove old class first': (16) Device or resource busy

Da alle OSD nvme-Disk sind, habe ich laut Ceph-Doc versucht die device-class zu löschen und neu zu setzen mit:

ceph osd crush rm-device-class osd.0 osd.1 osd.2 osd.3 osd.4 osd.5 osd.6 osd.7 osd.8 osd.9 osd.10 osd.11 osd.12 osd.13 osd.14 osd.15 osd.16 osd.17 osd.18 osd.20 osd.21 osd.22 osd.23

ceph osd crush set-device-class nvme osd.0 osd.1 osd.2 osd.3 osd.4 osd.5 osd.6 osd.7 osd.8 osd.9 osd.10 osd.11 osd.12 osd.13 osd.14 osd.15 osd.16 osd.17 osd.18 osd.20 osd.21 osd.22 osd.23

Ohne Erfolg, nach einem Reboot kommt pro OSD wieder diese Meldung.

3. OSD numa_affinity

Jul 21 16:59:45 prox3c ceph-osd[2746]: 2019-07-21 16:59:45.284 7f9baa8e1700 -1 osd.14 20026 set_numa_affinity unable to identify public interface 'ceph_public' numa node: (2) No such file or directory

Das Interface ceph_public ist in der ceph.conf beschrieben mit public network = 192.xxx.xx3.0/24. Warum kann er das Netzwerk nicht identifizieren?

Hier dazu ein Ausschnitt aus der ceph.conf (debug, fsid und andere Abschnitte entfernt):

[global]
auth_client_required = none
auth_cluster_required = none
auth_service_required = none
cluster network = 192.xxx.xx4.0/24
mon_host = 192.xxx.xx3.1,192.xxx.xx3.2,192.xxx.xx3.3,192.xxx.xx3.4
mon_allow_pool_delete = true
mon_pg_warn_max_object_skew = 100000
mon_pg_warn_max_per_osd = 32768
mon_pg_warn_min_per_osd = 0
mon_cluster_log_file_level = info
ms_type = async
rbd_readahead_disable_after_bytes = 0
rbd_readahead_max_bytes = 4194304
osd_pg_bits = 8
osd_pgp_bits = 8
osd_journal_size = 5120
osd_pool_default_min_size = 1
osd_pool_default_size = 2
perf = true
public network = 192.xxx.xx3.0/24
mutex_perf_counter = true
throttler_perf_counter = false
rbd_cache = false

Anmerkungen zum Upgrade:
In der Upgradebeschreibung sind folgende Fragen unbeantwortet:

a) In der /etc/pve/ceph.conf

[global]
mon_host = 192.xxx.xx3.1,192.xxx.xx3.2,192.xxx.xx3.3,192.xxx.xx3.4

In der Cehp-Doc werden die Hosts durch ein Koma getrennt, in der Proxmoxbeschreibung durch ein Leerzeichen. Welche Schreibweise ist besser für die Zukunft?


b) Unter /etc/pve/ceph.conf stehen Monitoreinträge, können diese entfernt werden, da es jetzt den "mon_host =" Eintrag in der Sektion [global] gibt oder wird der hostname an diesen noch aufgelöst?

[mon.prox2b]
host = prox2b
mon addr = 192.xxx.xx3.2

[mon.prox3c]
host = prox3c
mon addr = 192.xxx.xx3.3

[mon.prox1a]
host = prox1a
mon addr = 192.xxx.xx3.1

[mon.prox4d]
host = prox4d
mon addr = 192.xxx.xx3.4

Das System ist ein 4 Node Supermicro 2028BT-HNR+ mit je 6x NVME a 4TB, 512GB RAM.
Vielen Dank für die Hilfe!

 

[Alwin]

1. Device-ID alle mon nach Reboot:

Was steht den davor und danach im Log?

2. Meldung, dass die "device-class" zu "ssd" geändert werden soll auf allen osd und allen hosts :

Steht hier auch mehr vor und danach im Log? Wenn die Device-Class entfernt wird, ist dann keine mehr im 'ceph osd crush tree' zu sehen? Wie schaut die Crushmap aus?

3. OSD numa_affinity

Da versucht die OSD sich auf die NUMA node zu setzen, wo auch die Netzwerkkarte für das Public Net hängt.

Das System ist ein 4 Node Supermicro 2028BT-HNR+ mit je 6x NVME a 4TB, 512GB RAM.

Wie sind die Nodes per Netzwerk angeschlossen?

a) In der /etc/pve/ceph.conf

Ceph kann all diese Varianten verwenden, ob sich das mal ändert hängt aber ganz von den Ceph Entwicklern ab.

b) Unter /etc/pve/ceph.conf stehen Monitoreinträge, können diese entfernt werden, da es jetzt den "mon_host =" Eintrag in der Sektion [global] gibt oder wird der hostname an diesen noch aufgelöst?

Beim erstellen des ersten MONs wird ein Eintrag gebraucht. Es schadet aber auch nicht diese stehen zu lassen, da mit unserem Tooling die eh auch aufgeräumt werden.

 

[Mario Hosse]

Hallo Alwin,

danke für die Antworten und im folgenden die verlangten Informationen.
Sollte noch etwas fehlen einfach schreiben!

Was steht den davor und danach im Log?

Hier eine Ausgabe:

Jul 22 11:52:59 prox1a systemd[4253]: Reached target Sockets.
Jul 22 11:52:59 prox1a systemd[4253]: Reached target Basic System.
Jul 22 11:52:59 prox1a systemd[4253]: Reached target Default.
Jul 22 11:52:59 prox1a systemd[4253]: Startup finished in 66ms.
Jul 22 11:52:59 prox1a systemd[1]: Started User Manager for UID 0.
Jul 22 11:52:59 prox1a systemd[1]: Started Session 1 of user root.
Jul 22 11:53:41 prox1a ceph-osd[2725]: 2019-07-22 11:53:41.900 7fedd15e0f80 -1 osd.3 20115 log_to_monitors {default=true}
Jul 22 11:53:41 prox1a ceph-osd[2725]: 2019-07-22 11:53:41.904 7fedd15e0f80 -1 osd.3 20115 mon_cmd_maybe_osd_create fail: 'osd.3 has already bound to class 'nvme', can not reset class to 'ssd'; use 'ceph osd crush rm-device-class <id>' to remove old class first': (16) Device or resource busy
Jul 22 11:53:41 prox1a ceph-osd[2725]: 2019-07-22 11:53:41.912 7fedca8d3700 -1 osd.3 20115 set_numa_affinity unable to identify public interface 'ceph_public' numa node: (2) No such file or directory
Jul 22 11:53:48 prox1a ceph-osd[2731]: 2019-07-22 11:53:48.116 7f5e09283f80 -1 osd.2 20115 log_to_monitors {default=true}
Jul 22 11:53:48 prox1a ceph-osd[2731]: 2019-07-22 11:53:48.120 7f5e09283f80 -1 osd.2 20115 mon_cmd_maybe_osd_create fail: 'osd.2 has already bound to class 'nvme', can not reset class to 'ssd'; use 'ceph osd crush rm-device-class <id>' to remove old class first': (16) Device or resource busy
Jul 22 11:53:48 prox1a ceph-osd[2731]: 2019-07-22 11:53:48.124 7f5e02576700 -1 osd.2 20115 set_numa_affinity unable to identify public interface 'ceph_public' numa node: (2) No such file or directory
Jul 22 11:53:49 prox1a ceph-osd[2729]: 2019-07-22 11:53:49.372 7fbe266c3f80 -1 osd.20 20115 log_to_monitors {default=true}
Jul 22 11:53:49 prox1a ceph-osd[2729]: 2019-07-22 11:53:49.376 7fbe266c3f80 -1 osd.20 20115 mon_cmd_maybe_osd_create fail: 'osd.20 has already bound to class 'nvme', can not reset class to 'ssd'; use 'ceph osd crush rm-device-class <id>' to remove old class first': (16) Device or resource busy
Jul 22 11:53:49 prox1a ceph-osd[2729]: 2019-07-22 11:53:49.380 7fbe1f9b6700 -1 osd.20 20115 set_numa_affinity unable to identify public interface 'ceph_public' numa node: (2) No such file or directory
Jul 22 11:53:49 prox1a ceph-osd[2728]: 2019-07-22 11:53:49.832 7fd87a9f4f80 -1 osd.0 20115 log_to_monitors {default=true}
Jul 22 11:53:49 prox1a ceph-osd[2727]: 2019-07-22 11:53:49.836 7f714ee17f80 -1 osd.4 20115 log_to_monitors {default=true}
Jul 22 11:53:49 prox1a ceph-osd[2728]: 2019-07-22 11:53:49.836 7fd87a9f4f80 -1 osd.0 20115 mon_cmd_maybe_osd_create fail: 'osd.0 has already bound to class 'nvme', can not reset class to 'ssd'; use 'ceph osd crush rm-device-class <id>' to remove old class first': (16) Device or resource busy
Jul 22 11:53:49 prox1a ceph-osd[2727]: 2019-07-22 11:53:49.840 7f714ee17f80 -1 osd.4 20115 mon_cmd_maybe_osd_create fail: 'osd.4 has already bound to class 'nvme', can not reset class to 'ssd'; use 'ceph osd crush rm-device-class <id>' to remove old class first': (16) Device or resource busy
Jul 22 11:53:49 prox1a ceph-osd[2728]: 2019-07-22 11:53:49.840 7fd873ce7700 -1 osd.0 20115 set_numa_affinity unable to identify public interface 'ceph_public' numa node: (2) No such file or directory
Jul 22 11:53:49 prox1a ceph-osd[2727]: 2019-07-22 11:53:49.844 7f714810a700 -1 osd.4 20115 set_numa_affinity unable to identify public interface 'ceph_public' numa node: (2) No such file or directory
Jul 22 11:53:50 prox1a ceph-osd[2730]: 2019-07-22 11:53:50.952 7fe1965baf80 -1 osd.1 20115 log_to_monitors {default=true}
Jul 22 11:53:50 prox1a ceph-osd[2730]: 2019-07-22 11:53:50.956 7fe1965baf80 -1 osd.1 20115 mon_cmd_maybe_osd_create fail: 'osd.1 has already bound to class 'nvme', can not reset class to 'ssd'; use 'ceph osd crush rm-device-class <id>' to remove old class first': (16) Device or resource busy
Jul 22 11:53:50 prox1a ceph-osd[2730]: 2019-07-22 11:53:50.960 7fe18f8ad700 -1 osd.1 20115 set_numa_affinity unable to identify public interface 'ceph_public' numa node: (2) No such file or directory

Diese sind 1:1 kopiert. Danach kommt bis zu meiner Anmeldung nichts mehr.

Steht hier auch mehr vor und danach im Log? Wenn die Device-Class entfernt wird, ist dann keine mehr im 'ceph osd crush tree' zu sehen? Wie schaut die Crushmap aus?

Leider nicht siehe log-Ausgabe oben.

Im crush tree ist die device-class nvme gesetzt trotzt Meldung im log:

ceph osd crush tree
ID CLASS WEIGHT TYPE NAME
-1 2095.91992 root default
-3 523.97998 host prox1a
0 nvme 87.33000 osd.0
1 nvme 87.33000 osd.1
2 nvme 87.33000 osd.2
3 nvme 87.33000 osd.3
4 nvme 87.33000 osd.4
20 nvme 87.33000 osd.20
-5 523.97998 host prox2b
5 nvme 87.33000 osd.5
6 nvme 87.33000 osd.6
7 nvme 87.33000 osd.7
8 nvme 87.33000 osd.8
9 nvme 87.33000 osd.9
21 nvme 87.33000 osd.21
-7 523.97998 host prox3c
10 nvme 87.33000 osd.10
11 nvme 87.33000 osd.11
12 nvme 87.33000 osd.12
13 nvme 87.33000 osd.13
14 nvme 87.33000 osd.14
22 nvme 87.33000 osd.22
-9 523.97998 host prox4d
15 nvme 87.33000 osd.15
16 nvme 87.33000 osd.16
17 nvme 87.33000 osd.17
18 nvme 87.33000 osd.18
19 nvme 87.33000 osd.19
23 nvme 87.33000 osd.23

crushmap:

# begin crush map
tunable choose_local_tries 0
tunable choose_local_fallback_tries 0
tunable choose_total_tries 50
tunable chooseleaf_descend_once 1
tunable chooseleaf_vary_r 1
tunable chooseleaf_stable 1
tunable straw_calc_version 1
tunable allowed_bucket_algs 54

# devices
device 0 osd.0 class nvme
device 1 osd.1 class nvme
device 2 osd.2 class nvme
device 3 osd.3 class nvme
device 4 osd.4 class nvme
device 5 osd.5 class nvme
device 6 osd.6 class nvme
device 7 osd.7 class nvme
device 8 osd.8 class nvme
device 9 osd.9 class nvme
device 10 osd.10 class nvme
device 11 osd.11 class nvme
device 12 osd.12 class nvme
device 13 osd.13 class nvme
device 14 osd.14 class nvme
device 15 osd.15 class nvme
device 16 osd.16 class nvme
device 17 osd.17 class nvme
device 18 osd.18 class nvme
device 19 osd.19 class nvme
device 20 osd.20 class nvme
device 21 osd.21 class nvme
device 22 osd.22 class nvme
device 23 osd.23 class nvme

# types
type 0 osd
type 1 host
type 2 chassis
type 3 rack
type 4 row
type 5 pdu
type 6 pod
type 7 room
type 8 datacenter
type 9 region
type 10 root

# buckets
host prox1a {
id -3 # do not change unnecessarily
id -4 class nvme # do not change unnecessarily
# weight 523.980
alg straw2
hash 0 # rjenkins1
item osd.0 weight 87.330
item osd.2 weight 87.330
item osd.3 weight 87.330
item osd.4 weight 87.330
item osd.20 weight 87.330
item osd.1 weight 87.330
}
host prox2b {
id -5 # do not change unnecessarily
id -6 class nvme # do not change unnecessarily
# weight 523.980
alg straw2
hash 0 # rjenkins1
item osd.5 weight 87.330
item osd.6 weight 87.330
item osd.7 weight 87.330
item osd.8 weight 87.330
item osd.9 weight 87.330
item osd.21 weight 87.330
}
host prox3c {
id -7 # do not change unnecessarily
id -8 class nvme # do not change unnecessarily
# weight 523.980
alg straw2
hash 0 # rjenkins1
item osd.10 weight 87.330
item osd.11 weight 87.330
item osd.12 weight 87.330
item osd.13 weight 87.330
item osd.14 weight 87.330
item osd.22 weight 87.330
}
host prox4d {
id -9 # do not change unnecessarily
id -10 class nvme # do not change unnecessarily
# weight 523.980
alg straw2
hash 0 # rjenkins1
item osd.15 weight 87.330
item osd.16 weight 87.330
item osd.18 weight 87.330
item osd.19 weight 87.330
item osd.23 weight 87.330
item osd.17 weight 87.330
}
root default {
id -1 # do not change unnecessarily
id -2 class nvme # do not change unnecessarily
# weight 2095.920
alg straw2
hash 0 # rjenkins1
item prox1a weight 523.980
item prox2b weight 523.980
item prox3c weight 523.980
item prox4d weight 523.980
}

# rules
rule replicated_rule {
id 0
type replicated
min_size 1
max_size 10
step take default
step chooseleaf firstn 0 type host
step emit
}

# end crush map

Da versucht die OSD sich auf die NUMA node zu setzen, wo auch die Netzwerkkarte für das Public Net hängt.

Spielt das eine Rolle? In den Systemen habe ich 2xCPU. Ich habe die Numa-Nodes zugewiesen mit zum Beispiel Host1 (Es spielt keine Rolle ob die Zuweisung erfolgt ist. Die Meldung kommt mit und ohne Zuweisung):

prox1a
ceph config set osd.0 osd_numa_node 0
ceph config set osd.1 osd_numa_node 0
ceph config set osd.2 osd_numa_node 0
ceph config set osd.3 osd_numa_node 1
ceph config set osd.4 osd_numa_node 1
ceph config set osd.20 osd_numa_node 1

ceph osd numa-status
OSD HOST NETWORK STORAGE AFFINITY CPUS
0 prox1a - 1 0 0-11,24-35
1 prox1a - 1 0 0-11,24-35
2 prox1a - 1 0 0-11,24-35
3 prox1a - 1 1 12-23,36-47
4 prox1a - 1 1 12-23,36-47
5 prox2b - 1 0 0-11,24-35
6 prox2b - 1 0 0-11,24-35
7 prox2b - 1 0 0-11,24-35
8 prox2b - 1 1 12-23,36-47
9 prox2b - 1 1 12-23,36-47
10 prox3c - 1 0 0-11,24-35
11 prox3c - 1 0 0-11,24-35
12 prox3c - 1 0 0-11,24-35
13 prox3c - 1 1 12-23,36-47
14 prox3c - 1 1 12-23,36-47
15 prox4d - 1 0 0-11,24-35
16 prox4d - 1 0 0-11,24-35
17 prox4d - 1 0 0-11,24-35
18 prox4d - 1 1 12-23,36-47
19 prox4d - 1 1 12-23,36-47
20 prox1a - 1 1 12-23,36-47
21 prox2b - 1 1 12-23,36-47
22 prox3c - 1 1 12-23,36-47
23 prox4d - 1 1 12-23,36-47

Wie sind die Nodes per Netzwerk angeschlossen?

Netzwerkkonfig:

2x 40GB im OVS Bond

auto lo
iface lo inet loopback
iface ens3 inet manual
iface ens3d1 inet manual

allow-vmbr0 verwaltung
iface verwaltung inet static
address 192.xxx.xx8.1
netmask 255.255.255.0
gateway 192.xxx.xx8.147
ovs_type OVSIntPort
ovs_bridge vmbr0
ovs_options tag=1
mtu 9000

allow-vmbr0 ceph_public
iface ceph_public inet static
address 192.xxx.xx3.1
netmask 255.255.255.0
ovs_type OVSIntPort
ovs_bridge vmbr0
ovs_options tag=40
mtu 9000

allow-vmbr0 ceph_cluster
iface ceph_cluster inet static
address 192.xxx.xx4.1
netmask 255.255.255.0
ovs_type OVSIntPort
ovs_bridge vmbr0
ovs_options tag=50
mtu 9000

allow-vmbr0 bond0
iface bond0 inet manual
ovs_bonds ens3d1 ens3
ovs_type OVSBond
ovs_bridge vmbr0
ovs_options bond_mode=balance-tcp lacp=active other_config:lacp-time=fast
pre-up (ip link set mtu 9000 dev ens3d1 && ip link set mtu 9000 dev ens3 && /sbin/ethtool -C ens3 adaptive-rx off rx-usecs 0 tx-frames 64 && /sbin/ethtool -C ens3d1 adaptive-rx off rx-usecs 0 tx-frames 64)
mtu 9000

auto vmbr0
iface vmbr0 inet manual
ovs_type OVSBridge
ovs_ports bond0 verwaltung ceph_public ceph_cluster corosync migration
mtu 9000

allow-vmbr0 corosync
iface corosync inet static
address 192.xxx.xx2.1
netmask 255.255.255.0
ovs_type OVSIntPort
ovs_bridge vmbr0
ovs_options tag=60
mtu 9000

allow-vmbr0 migration
iface migration inet static
address 192.xxx.xx1.1
netmask 255.255.255.0
ovs_type OVSIntPort
ovs_bridge vmbr0

 

[Alwin]

Diese sind 1:1 kopiert. Danach kommt bis zu meiner Anmeldung nichts mehr.

In den Logs der jeweiligen OSD könnte noch mehr zu sehen sein. Wurden die OSDs bereits mit ceph-volume erstellt? Falls nicht, wäre es ein Versuch wert, da sich das on-disk Format sowieso etwas geändert hat. Auch könnte ein 'osd_class_update_on_start = false' das neue Setzen verhindern.

Spielt das eine Rolle? In den Systemen habe ich 2xCPU. Ich habe die Numa-Nodes zugewiesen mit zum Beispiel Host1 (Es spielt keine Rolle ob die Zuweisung erfolgt ist. Die Meldung kommt mit und ohne Zuweisung):

Dabei geht es primär um die Latenz. Das Fehlschlagen der Erkennung liegt wahrscheinlich am OVS, da der Bond kein Device ist.

int get_iface_numa_node(                                                      
  const std::string& iface,                                                  
  int *node)                                                                 
{                                                                          
  string fn = std::string("/sys/class/net/") + iface + "/device/numa_node";

Aus dem Ceph Code.

 

[Mario Hosse]

Hallo Alwin,

vielen Dank für die schnelle Reaktion auf meine Anfrage.

In den Logs der jeweiligen OSD könnte noch mehr zu sehen sein.

In den OSD-Logs gibt es nur die Meldung:

2019-07-20 22:34:34.695 7febbfff9f80 -1 osd.21 19897 log_to_monitors {default=true}
2019-07-20 22:34:34.695 7febbfff9f80 1 bluestore(/var/lib/ceph/osd/ceph-21) collect_metadata devices span numa nodes 1
2019-07-20 22:34:34.699 7febbfff9f80 -1 osd.21 19897 mon_cmd_maybe_osd_create fail: 'osd.21 has already bound to class 'nvme', can not reset class to 'ssd'; use 'ceph osd crush rm-device-class <id>' to remove old class first': (16) Device or resource busy
2019-07-20 22:34:34.699 7febbfff9f80 0 osd.21 19897 done with init, starting boot process
2019-07-20 22:34:34.715 7febb92ed700 -1 osd.21 19897 set_numa_affinity unable to identify public interface 'ceph_public' numa node: (2) No such file or directory
2019-07-20 22:34:34.715 7febb92ed700 1 bluestore(/var/lib/ceph/osd/ceph-21) collect_metadata devices span numa nodes 1
2019-07-20 22:34:34.715 7febb92ed700 1 bluestore(/var/lib/ceph/osd/ceph-21) collect_metadata devices span numa nodes 1

Im mon-Log direkt nach dem Upgrade auf ceph 14.2.1 diese Zeilen:

2019-07-20 22:46:27.938 7fec15cc53c0 -1 WARNING: 'mon addr' config option v1:192.xxx.xx3.2:6789/0 does not match monmap file
continuing with monmap configuration
2019-07-20 22:46:27.938 7fec15cc53c0 0 starting mon.prox2b rank 1 at public addrs [v2:192.xxx.xx3.2:3300/0,v1:192.xxx.xx3.2:6789/0] at bind addrs [v2:192.xxx.xx3.2:3300/0,v1:192.xxx.xx3.2:6789/0] mon_data /var/lib/ceph/mon/ceph-prox2b fsid 75f1cff9-0580-45a4-934b-40ae9ff832b7
2019-07-20 22:46:27.938 7fec15cc53c0 0 mon.prox2b@-1(???).mds e1 new map
2019-07-20 22:46:27.938 7fec15cc53c0 0 mon.prox2b@-1(???).mds e1 print_map
e1
enable_multiple, ever_enabled_multiple: 0,0
compat: compat={},rocompat={},incompat={1=base v0.20,2=client writeable ranges,3=default file layouts on dirs,4=dir inode in separate object,5=mds uses versioned encoding,6=dirfrag is stored in omap,8=file layout v2}
legacy client fscid: -1

No filesystems configured

2019-07-20 22:46:27.938 7fec15cc53c0 0 mon.prox2b@-1(???).osd e19932 crush map has features 288514051259236352, adjusting msgr requires
2019-07-20 22:46:27.938 7fec15cc53c0 0 mon.prox2b@-1(???).osd e19932 crush map has features 288514051259236352, adjusting msgr requires
2019-07-20 22:46:27.938 7fec15cc53c0 0 mon.prox2b@-1(???).osd e19932 crush map has features 1009089991638532096, adjusting msgr requires
2019-07-20 22:46:27.938 7fec15cc53c0 0 mon.prox2b@-1(???).osd e19932 crush map has features 288514051259236352, adjusting msgr requires
2019-07-20 22:46:27.946 7fec15cc53c0 0 mon.prox2b@-1(probing) e8 my rank is now 1 (was -1)
2019-07-20 22:46:28.150 7fec0e7c6700 0 log_channel(cluster) log [INF] : mon.prox2b calling monitor election
2019-07-20 22:46:28.170 7fec0e7c6700 -1 mon.prox2b@1(electing) e8 failed to get devid for : fallback method has serial ''but no model
2019-07-20 22:46:33.106 7fec0e7c6700 -1 mon.prox2b@1(electing) e8 failed to get devid for : fallback method has serial ''but no model
2019-07-20 22:46:33.126 7fec0e7c6700 0 mon.prox2b@1(peon) e8 handle_command mon_command({"prefix":"df","format":"json"} v 0) v1
2019-07-20 22:46:33.126 7fec0e7c6700 0 log_channel(audit) log [DBG] : from='client.? v1:192.xxx.xx3.4:0/2926339885' entity='client.admin' cmd=[{"prefix":"df","format":"json"}]: dispatch
2019-07-20 22:46:33.206 7fec0e7c6700 0 mon.prox2b@1(peon) e8 handle_command mon_command({"prefix":"df","format":"json"} v 0) v1
2019-07-20 22:46:33.206 7fec0e7c6700 0 log_channel(audit) log [DBG] : from='client.? v1:192.xxx.xx3.3:0/795302344' entity='client.admin' cmd=[{"prefix":"df","format":"json"}]: dispatch
2019-07-20 22:46:33.614 7fec0e7c6700 0 mon.prox2b@1(peon) e8 handle_command mon_command({"format":"json","prefix":"df"} v 0) v1
2019-07-20 22:46:33.614 7fec0e7c6700 0 log_channel(audit) log [DBG] : from='client.? v1:192.xxx.xx3.1:0/2178833905' entity='client.admin' cmd=[{"format":"json","prefix":"df"}]: dispatch
2019-07-20 22:46:38.410 7fec0e7c6700 0 mon.prox2b@1(peon) e8 handle_command mon_command({"format":"json","prefix":"df"} v 0) v1
2019-07-20 22:46:38.410 7fec0e7c6700 0 log_channel(audit) log [DBG] : from='client.? v1:192.xxx.xx3.2:0/3554144239' entity='client.admin' cmd=[{"format":"json","prefix":"df"}]: dispatch
2019-07-20 22:46:38.638 7fec0e7c6700 0 mon.prox2b@1(peon) e8 handle_command mon_command({"format":"json","prefix":"df"} v 0) v1
2019-07-20 22:46:38.638 7fec0e7c6700 0 log_channel(audit) log [DBG] : from='client.? v1:192.xxx.xx3.2:0/3079754212' entity='client.admin' cmd=[{"format":"json","prefix":"df"}]: dispatch
2019-07-20 22:46:40.694 7fec0e7c6700 0 mon.prox2b@1(peon) e8 handle_command mon_command({"format":"json","prefix":"df"} v 0) v1
2019-07-20 22:46:40.694 7fec0e7c6700 0 log_channel(audit) log [DBG] : from='client.? v1:192.xxx.xx3.3:0/2761254847' entity='client.admin' cmd=[{"format":"json","prefix":"df"}]: dispatch
2019-07-20 22:46:43.090 7fec09fbd700 4 rocksdb: [/root/sources/pve/ceph/ceph-14.2.1/src/rocksdb/db/db_impl_write.cc:1423] [default] New memtable created with log file: #920945. Immutable memtables: 0.

2019-07-20 22:46:43.090 7fec12fcf700 4 rocksdb: [/root/sources/pve/ceph/ceph-14.2.1/src/rocksdb/db/db_impl_compaction_flush.cc:86] [JOB 3] Syncing log #920942
2019-07-20 22:46:43.090 7fec12fcf700 4 rocksdb: (Original Log Time 2019/07/20-22:46:43.092828) [/root/sources/pve/ceph/ceph-14.2.1/src/rocksdb/db/db_impl_compaction_flush.cc:1560] Calling FlushMemTableToOutputFile with column family [default], flush slots available 1, compaction slots avai
lable 1, flush slots scheduled 1, compaction slots scheduled 0

Ich denke diese Zeilen helfen auch nicht wirklich weiter.

Wurden die OSDs bereits mit ceph-volume erstellt? Falls nicht, wäre es ein Versuch wert, da sich das on-disk Format sowieso etwas geändert hat. Auch könnte ein 'osd_class_update_on_start = false' das neue Setzen verhindern.

Zum "ceph-volume" brauche ich Hilfe. Wie kann ich das feststellen mit welcher Version das Filesystem erstellt wurde? Ich habe das ceph-Cluster mit der Proxmoxversion 5.3.8 erstellt, also luminos mit ceph-disk? Muss ich die Disk entfernen und neu in das Cluster holen oder gibt es eine cli-Möglichkeit das on-disk Format zu ändern?

Den Parameter 'osd_class_update_on_start = false' werde ich testen und ein Rückmeldung geben.

Dabei geht es primär um die Latenz. Das Fehlschlagen der Erkennung liegt wahrscheinlich am OVS, da der Bond kein Device ist.

int get_iface_numa_node(                                                    
  const std::string& iface,                                                
  int *node)                                                               
{                                                                        
  string fn = std::string("/sys/class/net/") + iface + "/device/numa_node";

Aus dem Ceph Code.

Am ceph_public-Interface fehlt das gesamte Unterverzeichnis "/sys/class/net/ceph_public/device". Um den String "/device/numa_node" zu bekommen, müsste aus der OVS-Konfiguration auf die physikalischen Interfaces ens3 und ens3d1 zurückgegriffen werden. In meinem Fall steht in der Datei numa_node eine "1" für beide Karten (1 x Dualportnetzwerkkarte). Eine Idee wäre in der OVS-Konfiguration beim Start auf die physikalische Netzwerkkarte zu verweisen, hier "/sys/class/net/ens3/device/numa_node" und "/sys/class/net/ens3d1/device/numa_node".

 

[Alwin]

2019-07-20 22:34:34.699 7febbfff9f80 -1 osd.21 19897 mon_cmd_maybe_osd_create fail: 'osd.21 has already bound to class 'nvme', can not reset class to 'ssd'; use 'ceph osd crush rm-device-class <id>' to remove old class first': (16) Device or resource busy

Ich hab jetzt zwar nichts direkt damit gefunden, aber evtl könnte ein entfernen der Device-Class und ein anschließender neustart der OSD helfen. Vorausgesetzt 'osd_class_update_on_start' ist auf True.

Zum "ceph-volume" brauche ich Hilfe. Wie kann ich das feststellen mit welcher Version das Filesystem erstellt wurde? Ich habe das ceph-Cluster mit der Proxmoxversion 5.3.8 erstellt, also luminos mit ceph-disk? Muss ich die Disk entfernen und neu in das Cluster holen oder gibt es eine cli-Möglichkeit das on-disk Format zu ändern?

Ja das wäre ein neu erstellen der OSDs. Das Format ist leider nicht vermerkt (zumindest sehe ich es nicht ), da viele Dinge direkt in die RocksDB geschrieben werden.

 

[Mario Hosse]

Ich hab jetzt zwar nichts direkt damit gefunden, aber evtl könnte ein entfernen der Device-Class und ein anschließender neustart der OSD helfen. Vorausgesetzt 'osd_class_update_on_start' ist auf True.

osd_class_update_on_start = true

Zuordnung gelöscht, reboot osd, Ergebnis "ssd" wird zugewiesen.

Ich habe jetzt

osd_class_update_on_start = false

gesetzt und die Meldung ist weg.
Ich kann nicht nachvollziehen, warum ceph die Klasse ssd automatisch setzen will.

Ja das wäre ein neu erstellen der OSDs. Das Format ist leider nicht vermerkt (zumindest sehe ich es nicht ), da viele Dinge direkt in die RocksDB geschrieben werden.

Ok, kann ich aber erst im September versuchen.

Wichtiger wäre mir aber das Problem mit der cpu-Zuweisung der OSD mit ovs und der zitierten

ceph/src/common/pick_address.cc

zu lösen. Wobei sich ceph und ovs einig werden müssten, wie es zu lösen ist.

Vielen Dank für Deine Hilfe. Da die Probleme nicht wirklich gelöst sind, lasse ich den Thread offen stehen.

 

[Alwin]

Ich kann nicht nachvollziehen, warum ceph die Klasse ssd automatisch setzen will.

Ceph scheint die Devices falsch zu erkennen, ich nehme an weil diese U2 sind.

Wichtiger wäre mir aber das Problem mit der cpu-Zuweisung der OSD mit ovs und der zitierten

Ja das wird wohl nicht so einfach sein, da jedes virtuelle Device leider nicht erkannt wird.

:~# ceph daemon osd.1 config show | grep -i numa
    "osd_numa_auto_affinity": "true",
    "osd_numa_node": "-1",
    "osd_numa_prefer_iface": "true",

Aber das setzen von 'osd_numa_auto_affinity' auf 'false' koennte zumindest die autom. Erkennung abschalten.

Da alle Punkte Ceph-spezifisch sind, schadet es sicher nicht auch auf die Ceph mailing Liste [0] und in den Bugtracker [1] zu schreiben.

[0] https://lists.ceph.io/postorius/lists/ceph-users.ceph.io/
[1] https://tracker.ceph.com/

 

[Mario Hosse]

Ceph scheint die Devices falsch zu erkennen, ich nehme an weil diese U2 sind.

Hast du richtig erkannt, die sind U2.

Ja das wird wohl nicht so einfach sein, da jedes virtuelle Device leider nicht erkannt wird.

:~# ceph daemon osd.1 config show | grep -i numa
    "osd_numa_auto_affinity": "true",
    "osd_numa_node": "-1",
    "osd_numa_prefer_iface": "true",

Aber das setzen von 'osd_numa_auto_affinity' auf 'false' koennte zumindest die autom. Erkennung abschalten.

Da alle Punkte Ceph-spezifisch sind, schadet es sicher nicht auch auf die Ceph mailing Liste [0] und in den Bugtracker [1] zu schreiben.

[0] https://lists.ceph.io/postorius/lists/ceph-users.ceph.io/
[1] https://tracker.ceph.com/

Danke für die Links.

Ich habe einen Bugreport zur fehlenden numa_node Datei eingestellt unter:
https://tracker.ceph.com/issues/40937