Mehrere CEPH Pools pro CRUSH Rule - Verwendeter Speicherplatz

T

TanDE

Member
Proxmox Subscriber
Sep 5, 2022
30
3
13
Hallo zusammen,

ich habe eine Frage zu CEPH Pools mit unterschiedlichen Crush Rules. Wir haben im Einsatz: HDD's, SSD's und NVMe's. Bei den SSDs und NVMes gibt es nur einen einzigen Pool pro Typ/Crush Rule, aber für HDD haben wir einen Pool für die VMs und einen CEPHFS Pool. Dieser verwendet ebenfalls HDDs. Nun ist es so, das wir beim belegten Speicherplatz theoretisch "falsche" Werte angezeigt bekommen. Ich habe für die CEPHFS Pools eine (rel. niedrige) Target Size angegeben, da hier nicht viel an Daten drin liegt. Trotzdem passen die anzeigten Werte nicht.

ceph_hdd
RAW USED: 63.74%
Pool Used: 80.41%

1707495930905.png

1707496290938.png
Hat hier jemand eine Idee? Lieg es evtl. an der Target Ratio von 1.0?

Btw: Im CephFS liegen nur ISO Images, aber ich habe keinen weiteren Shared Storage, worauf ich für die paar hundert GB ausweichen könnte.

LG
Tan
 
@gurubert Vielen Dank für den Hinweis. Hier dann noch die Ausgabe von "osd df tree" für die HDDs (auch als Text File im Anhang).
Eigentlich sollte das relativ "symmetrisch" sein. Nur 4TB Festplatten gleichmäßig auf 7 (CEPH) Hosts verteilt. Es fehlen aktuell 2 Festplatten / OSDs.

Code: 
# ceph osd df tree hdd
ID   CLASS  WEIGHT     REWEIGHT  SIZE     RAW USE  DATA     OMAP     META     AVAIL     %USE   VAR   PGS  STATUS  TYPE NAME
 -1         259.79926         -  120 TiB   77 TiB   76 TiB  117 MiB  161 GiB    44 TiB  63.74  1.00    -          root default
 -3          34.49455         -   18 TiB   12 TiB   12 TiB   18 MiB   26 GiB   6.4 TiB  65.04  1.02    -              host pve01
 12    hdd    3.63869   1.00000  3.6 TiB  2.7 TiB  2.7 TiB  4.0 MiB  6.0 GiB  1003 GiB  73.07  1.15  110      up          osd.12
 13    hdd    3.63869   1.00000  3.6 TiB  2.4 TiB  2.4 TiB  3.7 MiB  5.0 GiB   1.3 TiB  65.40  1.03  101      up          osd.13
 14    hdd    3.63869   1.00000  3.6 TiB  2.2 TiB  2.2 TiB  3.3 MiB  5.1 GiB   1.4 TiB  60.68  0.95   95      up          osd.14
 15    hdd    3.63869   1.00000  3.6 TiB  2.3 TiB  2.3 TiB  3.5 MiB  4.9 GiB   1.4 TiB  62.69  0.98   97      up          osd.15
140    hdd    3.63869   1.00000  3.6 TiB  2.3 TiB  2.3 TiB  3.5 MiB  5.3 GiB   1.3 TiB  63.35  0.99  101      up          osd.140
 -8          34.49455         -   18 TiB   11 TiB   11 TiB   17 MiB   24 GiB   7.3 TiB  59.92  0.94    -              host pve02
 16    hdd    3.63869   1.00000  3.6 TiB  2.2 TiB  2.2 TiB  3.4 MiB  5.2 GiB   1.4 TiB  60.62  0.95   94      up          osd.16
 17    hdd    3.63869   1.00000  3.6 TiB  2.3 TiB  2.3 TiB  3.4 MiB  4.8 GiB   1.4 TiB  62.00  0.97   97      up          osd.17
 18    hdd    3.63869   1.00000  3.6 TiB  2.3 TiB  2.3 TiB  3.4 MiB  5.2 GiB   1.4 TiB  62.57  0.98   98      up          osd.18
 19    hdd    3.63869   1.00000  3.6 TiB  1.9 TiB  1.9 TiB  2.9 MiB  4.4 GiB   1.7 TiB  52.79  0.83   80      up          osd.19
141    hdd    3.63869   1.00000  3.6 TiB  2.2 TiB  2.2 TiB  3.4 MiB  4.6 GiB   1.4 TiB  61.60  0.97   94      up          osd.141
-10          34.49455         -   18 TiB   12 TiB   12 TiB   18 MiB   24 GiB   6.4 TiB  64.77  1.02    -              host pve03
 20    hdd    3.63869   1.00000  3.6 TiB  2.4 TiB  2.4 TiB  3.6 MiB  5.1 GiB   1.2 TiB  65.67  1.03   97      up          osd.20
 21    hdd    3.63869   1.00000  3.6 TiB  2.3 TiB  2.3 TiB  3.5 MiB  3.5 GiB   1.4 TiB  62.04  0.97   98      up          osd.21
 78    hdd    3.63869   1.00000  3.6 TiB  2.5 TiB  2.5 TiB  3.8 MiB  5.1 GiB   1.1 TiB  68.75  1.08  102      up          osd.78
 79    hdd    3.63869   1.00000  3.6 TiB  2.5 TiB  2.5 TiB  3.9 MiB  4.8 GiB   1.2 TiB  67.82  1.06  101      up          osd.79
142    hdd    3.63869   1.00000  3.6 TiB  2.2 TiB  2.2 TiB  3.3 MiB  5.2 GiB   1.5 TiB  59.57  0.93   91      up          osd.142
-13          34.49455         -   18 TiB   11 TiB   11 TiB   17 MiB   22 GiB   7.0 TiB  61.57  0.97    -              host pve04
 30    hdd    3.63869   1.00000  3.6 TiB  2.5 TiB  2.5 TiB  3.8 MiB  4.6 GiB   1.2 TiB  68.21  1.07  104      up          osd.30
 31    hdd    3.63869   1.00000  3.6 TiB  2.0 TiB  2.0 TiB  3.1 MiB  3.7 GiB   1.6 TiB  55.50  0.87   82      up          osd.31
 82    hdd    3.63869   1.00000  3.6 TiB  1.9 TiB  1.9 TiB  3.0 MiB  3.8 GiB   1.8 TiB  51.41  0.81   76      up          osd.82
 83    hdd    3.63869   1.00000  3.6 TiB  2.5 TiB  2.5 TiB  4.0 MiB  5.0 GiB   1.1 TiB  70.08  1.10  107      up          osd.83
143    hdd    3.63869   1.00000  3.6 TiB  2.3 TiB  2.3 TiB  3.5 MiB  4.9 GiB   1.4 TiB  62.63  0.98   98      up          osd.143
-21          34.49455         -   18 TiB   11 TiB   11 TiB   18 MiB   24 GiB   7.0 TiB  61.37  0.96    -              host pve06
 48    hdd    3.63869   1.00000  3.6 TiB  1.9 TiB  1.9 TiB  3.0 MiB  3.8 GiB   1.8 TiB  51.43  0.81   81      up          osd.48
 49    hdd    3.63869   1.00000  3.6 TiB  2.5 TiB  2.5 TiB  3.9 MiB  4.9 GiB   1.1 TiB  68.55  1.08  102      up          osd.49
 86    hdd    3.63869   1.00000  3.6 TiB  2.1 TiB  2.1 TiB  3.5 MiB  4.7 GiB   1.5 TiB  57.82  0.91   86      up          osd.86
 87    hdd    3.63869   1.00000  3.6 TiB  2.4 TiB  2.4 TiB  3.7 MiB  5.4 GiB   1.2 TiB  66.71  1.05  101      up          osd.87
144    hdd    3.63869   1.00000  3.6 TiB  2.3 TiB  2.3 TiB  3.5 MiB  5.0 GiB   1.4 TiB  62.34  0.98   95      up          osd.144
-25          43.66325         -   15 TiB  9.8 TiB  9.7 TiB   15 MiB   20 GiB   4.8 TiB  67.05  1.05    -              host pve08
 90    hdd    3.63869   1.00000  3.6 TiB  2.1 TiB  2.1 TiB  3.2 MiB  4.7 GiB   1.5 TiB  59.04  0.93   90      up          osd.90
 91    hdd    3.63869   1.00000  3.6 TiB  2.5 TiB  2.5 TiB  3.7 MiB  4.8 GiB   1.2 TiB  67.69  1.06  103      up          osd.91
 93    hdd    3.63869   1.00000  3.6 TiB  2.3 TiB  2.2 TiB  3.4 MiB  4.7 GiB   1.4 TiB  61.89  0.97   98      up          osd.93
145    hdd    3.63869   1.00000  3.6 TiB  2.9 TiB  2.9 TiB  4.4 MiB  6.0 GiB   761 GiB  79.57  1.25  121      up          osd.145
-29          43.66325         -   15 TiB  9.9 TiB  9.9 TiB   15 MiB   20 GiB   4.7 TiB  67.96  1.07    -              host pve09
 94    hdd    3.63869   1.00000  3.6 TiB  2.3 TiB  2.3 TiB  3.4 MiB  4.3 GiB   1.4 TiB  62.39  0.98   96      up          osd.94
 95    hdd    3.63869   1.00000  3.6 TiB  2.6 TiB  2.6 TiB  4.0 MiB  5.3 GiB   1.0 TiB  72.42  1.14  109      up          osd.95
 96    hdd    3.63869   1.00000  3.6 TiB  2.6 TiB  2.6 TiB  4.0 MiB  5.5 GiB   1.0 TiB  71.47  1.12  109      up          osd.96
 97    hdd    3.63869   1.00000  3.6 TiB  2.4 TiB  2.4 TiB  3.6 MiB  5.3 GiB   1.3 TiB  65.58  1.03  102      up          osd.97
                          TOTAL  120 TiB   77 TiB   76 TiB  117 MiB  161 GiB    44 TiB  63.74
MIN/MAX VAR: 0.81/1.25  STDDEV: 6.13
 

Attachments

  • ceph_osd_tree_hdd.txt
    5.5 KB · Views: 1
gurubert said:
Das weight der Hosts passt nicht zur Summe der OSDs. Ist da etwas manuell geändert worden?
Click to expand...
Nein, zumindest nicht wissentlich. Ich wüsste spontan gar nicht, wie und wo ich das setzen/überschreiben kann. Das Cluster ist ca. 3-4 Jahre alt und wurde regelmäßig um weitere Hosts erweitert. Die Crush Map haben wir nie manuell bearbeitet. Insgesamt sind 10 Hosts im Cluster, auf 7 sind aber nur OSDs aktiv.

Wobei mir gerade auffällt: Die höhere Host Weight bei PVE08 und PVE09 liegt an größeren SSDs, die nur in diesen beiden Hosts verbaut sind.

Sorry, ich hätte wahrscheinlich nicht die gefilterte Ausgabe senden dürfen. Die Hosts Weights werden dann anscheinend nicht anteilig dargestellt.

Im Anhang jetzt nochmal die vollständige Ausgabe von "ceph osd df tree" und nicht "ceph osd df tree hdd". :)
 

Attachments

  • ceph_osd_df_tree.txt
    20.2 KB · Views: 2
gurubert said:
Kannst Du bitte die Einstellungen für die Full-Ratios zeigen?

Bash: 
ceph config show-with-defaults osd.0 | grep full_ratio
Click to expand...

Ja klar:

Code: 
# ceph config show-with-defaults osd.0 | grep full_ratio

mon_osd_backfillfull_ratio                                  0.900000                                                                                                                                   default
mon_osd_full_ratio                                          0.950000                                                                                                                                   default
mon_osd_nearfull_ratio                                      0.850000                                                                                                                                   default
osd_failsafe_full_ratio                                     0.970000                                                                                                                                   default
osd_pool_default_cache_target_full_ratio                    0.800000                                                                                                                                   default
 
Der prozentuale Füllstand der Pools ergibt sich aus Pooldaten + max. Available.

Also für ceph_hdd: 25TB belegt + 6,2 TB = 31,2TB. 25TB von 31,2TB sind etwa 80,4%.
Für cephfs_data ebenso: 146GB belegt plus 6.2TB ergibt 6,346TB. 146GB davon sind etwa 2,25%.

Der Wert für max Available pro Pool ergibt sich aus der Replikation des Pools (üblicherweise 33% vom Brutto) und der OSD full ratio (also 95% von der verfügbaren Nettokapazität).
 
Last edited:
  • Like
Reactions: TanDE
gurubert said:
Der prozentuale Füllstand der Pools ergibt sich aus Pooldaten + max. Available.

Also für ceph_hdd: 25TB belegt + 6,2 TB = 31,2TB. 25TB von 31,2TB sind etwa 80,4%.
Für cephfs_data ebenso: 146GB belegt plus 6.2TB ergibt 6,346TB. 146GB davon sind etwa 2,25%.

Der Wert für max Available pro Pool ergibt sich aus der Replikation des Pools (üblicherweise 33% vom Brutto) und der OSD full ratio (also 95% von der verfügbaren Nettokapazität).
Click to expand...

Vielen Dank für die detaillierte Erklärung. Ich habe das gerade mal mit den konkreten Werten durchgerechnet (sofern ich das richtig verstanden habe) und dann bestätigt sich meine Vermutung, das durch den zweiten Pool (ceph_fs) nur die hälfte des verfügbaren Speicherplatzes pro Pool herangezogen wird. Da der ceph_fs Pool aber nie mehr als ein paar hundert GB halten wird (da nur ISO Images), geht hier doch in Summe eine ganze Menge an Speicherplatz verloren.

Code: 
33x HDDs (je 3,64TB)
ca. 120 TB /3
= 40 TB netto Kapazität
Full Ratio (40*0,95) = 38 TB

Belegt: ca. 25,5 TB
Frei: 12,5 TB (auf Basis Full Ratio 38TB)

Max available: 12,5 TB / 2 Pools mit der selben CRUSH Rule???

Ich dachte eigentlich (bzw. hatte gehofft), das hier auch die hinterlegte "Target Size" des jeweiligen Pools berücksichtigt wird. Gibt es irgendeine andere Möglichkeit, das zu umgehen / anders zu lösen?

Ich würde z.B. gerne testweise einen weiteren "kleinen" Pool mit Erasure Coding auf die HDDs legen. Das würde ja dann theoretisch sofort dazu führen, das CEPH den vorhandenen (vollen) Pool "ceph_hdd" als vollständig FULL betrachtet. Würde dieser dann im worst case direkt auf readonly gehen?
 
Ein Pool selber belegt keinen Platz. Es sind nur die Daten im Pool, die zählen. Ein zusätzlicher Pool führt also nicht dazu, dass andere Pools "sofort" keinen Platz mehr haben.
Erst wenn sich die Pools mit Daten füllen nehmen sie sich natürlich den gemeinsam genutzten Platz auf den OSDs gegenseitig weg.
Die "Target Size" ist nur für den Autoscaler interessant, der anhand dieser die optimale Anzahl der PGs zu ermitteln versucht.
 
TanDE said:
33x HDDs (je 3,64TB) ca. 120 TB /3 = 40 TB netto Kapazität Full Ratio (40*0,95) = 38 TB Belegt: ca. 25,5 TB Frei: 12,5 TB (auf Basis Full Ratio 38TB) Max available: 12,5 TB / 2 Pools mit der selben CRUSH Rule???
Click to expand...
Nein. Ich habe hier auf einem Testcluster diese Zahlen:

Code: 
--- RAW STORAGE ---
CLASS     SIZE    AVAIL     USED  RAW USED  %RAW USED
hdd     16 TiB   15 TiB  478 GiB   478 GiB       2.96
ssd    7.8 TiB  7.8 TiB  1.1 GiB   1.1 GiB       0.01
TOTAL   24 TiB   23 TiB  479 GiB   479 GiB       1.98
 
--- POOLS ---
POOL              ID  PGS   STORED  OBJECTS     USED  %USED  MAX AVAIL
.mgr               1    1  1.3 MiB        2  3.8 MiB      0    2.5 TiB
test               2   32     73 B        1   12 KiB      0    4.8 TiB
whirlpool          3   64     11 B        1   12 KiB      0    4.8 TiB
cephfs_data        4   64  100 GiB   25.97k  300 GiB   1.99    4.8 TiB
cephfs_metadata    5   16  199 MiB       93  596 MiB      0    2.5 TiB
cephfs.test.meta   6   16  415 KiB       24  1.3 MiB      0    2.5 TiB
cephfs.test.data   7  128      0 B        0      0 B      0    4.8 TiB
cephfs_dataec      8   32   11 GiB    3.27k   17 GiB   0.12    9.6 TiB
.nfs               9   32  9.9 KiB        8   75 KiB      0    4.8 TiB

Die Pools auf den HDDs haben alle 4,8TB verfügbar, was etwa 15TB / 3 - 5% ist.
Die Pools auf den SSDs haben alle 2,5TB verfügbar, was etwa 7,8TB / 3 - 5% ist.
Der EC-Pool liegt auf den HDDs mit k=4 und m=2 und hat deshalb 9,6TB bzw 15TB * 4 / (4 + 2) - 5% verfügbar.

Der niedrigere Wert für max avail Space bei den beiden Pools (6,2TB anstatt rechnerisch ca 14TB) kann ich grad auch nicht erklären. Ich kann mir nur vorstellen, dass die Berechnung hier anders ist, weil die HDDs ungleich auf die Hosts verteilt sind: Manche haben 5 und zwei nur 4 HDDs.
 
  • Like
Reactions: TanDE
TanDE said:
Ich würde z.B. gerne testweise einen weiteren "kleinen" Pool mit Erasure Coding auf die HDDs legen.
Click to expand...
Was erhoffst du dir davon? Wirklich sinnvoll kannst du hier nur mit 4/2 ran gehen, das bietet dir eine Effizienz von 66,67 %. Die nächste beliebte und sinnvolle Stufe wäre 8/3, dafür brauchst du aber auch mind. 11 Nodes.

EC kostet dich aber Ressourcen und du wirst hier vermutlich nur die Hälfte der Leistung eines Replica 3 Pools haben. Du musst dir bei EC bewusst sein darüber, dass die Kombination aus K + M entscheidend ist dafür, wie viele Kopien neu geschrieben und berechnet werden müssen. Bei 4/2 werden also insgesamt 6 Datenblöcke neu geschrieben, wovon aber auch zwei berechnet und gespeichert werden müssen, das kostet Latenz und genau dieses macht die Performance. Alle Kopien dieser Blöcke müssen angefasst werden, wenn sich auch nur ein Byte darin ändert. Für sich schnell und häufig ändernde Daten ist EC also eher ungeeignet.
Ich finde EC cool und wenn du die passende Hardware dafür hast, macht das auch Spaß, aber ich glaube nicht, dass du bei deinem Setup viel Spaß mit EC haben wirst.

Bei EC brauchst du mind. die Anzahl an Server die sich aus K + M ergeben. Mehr Server als z. B. die 6 oder 11 macht aber Sinn, für den Fall, dass dir ein Server ausfällt oder wegen Wartungen gerade offline ist. Ich würde für EC immer zu einem 8/3 raten, da du hier mit 72,73% Effizienz einen deutlichen Vorteil gegenüber 4/2 oder Replica 2 bzw. 3 hast. Bedenke auch, dass sich die Werte nachträglich nicht verändern lassen, wenn du also jetzt einen 4/2 anlegst müsstest du anschließend einen neuen mit 8/3 anlegen und die Daten dorthin verschieben.
 
  • Like
Reactions: Falk R., TanDE and gurubert
gurubert said:
Ein Pool selber belegt keinen Platz. Es sind nur die Daten im Pool, die zählen. Ein zusätzlicher Pool führt also nicht dazu, dass andere Pools "sofort" keinen Platz mehr haben.
Erst wenn sich die Pools mit Daten füllen nehmen sie sich natürlich den gemeinsam genutzten Platz auf den OSDs gegenseitig w
gurubert said:
Nein. Ich habe hier auf einem Testcluster diese Zahlen:

Code: 
--- RAW STORAGE ---
CLASS     SIZE    AVAIL     USED  RAW USED  %RAW USED
hdd     16 TiB   15 TiB  478 GiB   478 GiB       2.96
ssd    7.8 TiB  7.8 TiB  1.1 GiB   1.1 GiB       0.01
TOTAL   24 TiB   23 TiB  479 GiB   479 GiB       1.98
 
--- POOLS ---
POOL              ID  PGS   STORED  OBJECTS     USED  %USED  MAX AVAIL
.mgr               1    1  1.3 MiB        2  3.8 MiB      0    2.5 TiB
test               2   32     73 B        1   12 KiB      0    4.8 TiB
whirlpool          3   64     11 B        1   12 KiB      0    4.8 TiB
cephfs_data        4   64  100 GiB   25.97k  300 GiB   1.99    4.8 TiB
cephfs_metadata    5   16  199 MiB       93  596 MiB      0    2.5 TiB
cephfs.test.meta   6   16  415 KiB       24  1.3 MiB      0    2.5 TiB
cephfs.test.data   7  128      0 B        0      0 B      0    4.8 TiB
cephfs_dataec      8   32   11 GiB    3.27k   17 GiB   0.12    9.6 TiB
.nfs               9   32  9.9 KiB        8   75 KiB      0    4.8 TiB

Die Pools auf den HDDs haben alle 4,8TB verfügbar, was etwa 15TB / 3 - 5% ist.
Die Pools auf den SSDs haben alle 2,5TB verfügbar, was etwa 7,8TB / 3 - 5% ist.
Der EC-Pool liegt auf den HDDs mit k=4 und m=2 und hat deshalb 9,6TB bzw 15TB * 4 / (4 + 2) - 5% verfügbar.

Der niedrigere Wert für max avail Space bei den beiden Pools (6,2TB anstatt rechnerisch ca 14TB) kann ich grad auch nicht erklären. Ich kann mir nur vorstellen, dass die Berechnung hier anders ist, weil die HDDs ungleich auf die Hosts verteilt sind: Manche haben 5 und zwei nur 4 HDDs.
Click to expand...
gurubert said:
Nein. Ich habe hier auf einem Testcluster diese Zahlen:

Code: 
--- RAW STORAGE ---
CLASS     SIZE    AVAIL     USED  RAW USED  %RAW USED
hdd     16 TiB   15 TiB  478 GiB   478 GiB       2.96
ssd    7.8 TiB  7.8 TiB  1.1 GiB   1.1 GiB       0.01
TOTAL   24 TiB   23 TiB  479 GiB   479 GiB       1.98
 
--- POOLS ---
POOL              ID  PGS   STORED  OBJECTS     USED  %USED  MAX AVAIL
.mgr               1    1  1.3 MiB        2  3.8 MiB      0    2.5 TiB
test               2   32     73 B        1   12 KiB      0    4.8 TiB
whirlpool          3   64     11 B        1   12 KiB      0    4.8 TiB
cephfs_data        4   64  100 GiB   25.97k  300 GiB   1.99    4.8 TiB
cephfs_metadata    5   16  199 MiB       93  596 MiB      0    2.5 TiB
cephfs.test.meta   6   16  415 KiB       24  1.3 MiB      0    2.5 TiB
cephfs.test.data   7  128      0 B        0      0 B      0    4.8 TiB
cephfs_dataec      8   32   11 GiB    3.27k   17 GiB   0.12    9.6 TiB
.nfs               9   32  9.9 KiB        8   75 KiB      0    4.8 TiB

Die Pools auf den HDDs haben alle 4,8TB verfügbar, was etwa 15TB / 3 - 5% ist.
Die Pools auf den SSDs haben alle 2,5TB verfügbar, was etwa 7,8TB / 3 - 5% ist.
Der EC-Pool liegt auf den HDDs mit k=4 und m=2 und hat deshalb 9,6TB bzw 15TB * 4 / (4 + 2) - 5% verfügbar.

Der niedrigere Wert für max avail Space bei den beiden Pools (6,2TB anstatt rechnerisch ca 14TB) kann ich grad auch nicht erklären. Ich kann mir nur vorstellen, dass die Berechnung hier anders ist, weil die HDDs ungleich auf die Hosts verteilt sind: Manche haben 5 und zwei nur 4 HDDs.
Click to expand...
Click to expand...

Evtl. könnte die Erklärung folgende sein (eine OSD liegt tatsächlich bei fast 80%, der Host bei dem vor kurzem eine OSD ausgefallen ist):

1707914001219.png
1707914018461.png
Das würde zumindest erklären, warum MAX AVAIL deutlich niedriger ist als RAW AVAIL(/3).

Btw: Sollte der Balancer das nicht automatisch ausgleichen? Oder nur, wenn es sinnvoll und effizient ist?
 
  • Like
Reactions: gurubert
sb-jw said:
Was erhoffst du dir davon? Wirklich sinnvoll kannst du hier nur mit 4/2 ran gehen, das bietet dir eine Effizienz von 66,67 %. Die nächste beliebte und sinnvolle Stufe wäre 8/3, dafür brauchst du aber auch mind. 11 Nodes.

EC kostet dich aber Ressourcen und du wirst hier vermutlich nur die Hälfte der Leistung eines Replica 3 Pools haben. Du musst dir bei EC bewusst sein darüber, dass die Kombination aus K + M entscheidend ist dafür, wie viele Kopien neu geschrieben und berechnet werden müssen. Bei 4/2 werden also insgesamt 6 Datenblöcke neu geschrieben, wovon aber auch zwei berechnet und gespeichert werden müssen, das kostet Latenz und genau dieses macht die Performance. Alle Kopien dieser Blöcke müssen angefasst werden, wenn sich auch nur ein Byte darin ändert. Für sich schnell und häufig ändernde Daten ist EC also eher ungeeignet.
Ich finde EC cool und wenn du die passende Hardware dafür hast, macht das auch Spaß, aber ich glaube nicht, dass du bei deinem Setup viel Spaß mit EC haben wirst.

Bei EC brauchst du mind. die Anzahl an Server die sich aus K + M ergeben. Mehr Server als z. B. die 6 oder 11 macht aber Sinn, für den Fall, dass dir ein Server ausfällt oder wegen Wartungen gerade offline ist. Ich würde für EC immer zu einem 8/3 raten, da du hier mit 72,73% Effizienz einen deutlichen Vorteil gegenüber 4/2 oder Replica 2 bzw. 3 hast. Bedenke auch, dass sich die Werte nachträglich nicht verändern lassen, wenn du also jetzt einen 4/2 anlegst müsstest du anschließend einen neuen mit 8/3 anlegen und die Daten dorthin verschieben.
Click to expand...
Vielen Dank auch Dir für die sehr ausführliche Antwort. Mit dem Thema EC hatte ich mich bis dato auch nur oberflächlich befasst. Der Test ist zeitlich auch noch nicht fest eingeplant.

Zu deinem Einwand: Ja, das ergibt definitiv Sinn, nur geht es in diesem Fall ausschließlich um "kalte" Daten einer Backup Lösung, die ausschließlich Nachts sequentiell Daten in Files auf einem ReFS (Windows) schreibt. Performance ist hier relativ uninteressant und in diesem Zeitraum passiert auch sonst nichts im HDD Pool / Cluster. Ich würde ehrlich gesagt auch keine aktiven VMs im CEPH auf HDDs legen. Mir geht es bei dem Vorhaben primär um ein "gesundes" Verhältnis zwischen Storage Kosten und den abgelegten Daten (es sind ja schon Backups). Eine Effizienzsteigerung von 33% auf 66% wäre schon mal ein guter Anfang ;-) Und CPU Ressourcen / Reserven sind Nachts auch genügend vorhanden.
 
TanDE said:
Btw: Sollte der Balancer das nicht automatisch ausgleichen? Oder nur, wenn es sinnvoll und effizient ist?
Click to expand...
Ja, das würde er tun. Dein Cluster muss dafür Healthy sein, ansonsten stellt der seinen Dienst erstmal ein. Die nächste Hürde sind aber auch 5 % an misplaced Objects. Der Balancer ist aber auf jeden Fall aktiviert?

Schau mal in der Doku dazu: https://docs.ceph.com/en/latest/rados/operations/balancer/#throttling

TanDE said:
Ja, das ergibt definitiv Sinn, nur geht es in diesem Fall ausschließlich um "kalte" Daten einer Backup Lösung, die ausschließlich Nachts sequentiell Daten in Files auf einem ReFS (Windows) schreibt.
Click to expand...
TanDE said:
Und CPU Ressourcen / Reserven sind Nachts auch genügend vorhanden.
Click to expand...
Grundsätzlich ist das ja dann okay, du darfst aber dennoch nicht vergessen, dass die CPUs der Nodes dadurch mehr belastet sind und sich das auch negativ auf die VMs oder Replica Pools auswirken kann (nicht muss).
Ich nehme mal an, dass du keine Backups von VMs machen die auf dem CEPH laufen und deren Backups in das gleiche System schiebst? :)
(Backups gehören immer getrennt aufbewahrt, gerade bei einem CEPH kann ein Fehler bei der Bedienung katastrophale folgen haben - wobei ich aber auch sagen muss, dass ich bei CEPH noch nie einen Datenverlust hatte obwohl ich auch mal alle Mons gekillt habe oder versehentlich mehrere OSDs mit gleichen Kopien gezogen habe. CEPH ist sehr Robust und steckt viel weg, aber ggf. eben auch nicht alles.)

TanDE said:
Mir geht es bei dem Vorhaben primär um ein "gesundes" Verhältnis zwischen Storage Kosten und den abgelegten Daten (es sind ja schon Backups).
Click to expand...
Das ist absolut immer das Thema und genau dafür gibt es EC :)
 
  • Like
Reactions: TanDE
sb-jw said:
Ja, das würde er tun. Dein Cluster muss dafür Healthy sein, ansonsten stellt der seinen Dienst erstmal ein. Die nächste Hürde sind aber auch 5 % an misplaced Objects. Der Balancer ist aber auf jeden Fall aktiviert?

Schau mal in der Doku dazu: https://docs.ceph.com/en/latest/rados/operations/balancer/#throttling



Grundsätzlich ist das ja dann okay, du darfst aber dennoch nicht vergessen, dass die CPUs der Nodes dadurch mehr belastet sind und sich das auch negativ auf die VMs oder Replica Pools auswirken kann (nicht muss).
Ich nehme mal an, dass du keine Backups von VMs machen die auf dem CEPH laufen und deren Backups in das gleiche System schiebst? :)
(Backups gehören immer getrennt aufbewahrt, gerade bei einem CEPH kann ein Fehler bei der Bedienung katastrophale folgen haben - wobei ich aber auch sagen muss, dass ich bei CEPH noch nie einen Datenverlust hatte obwohl ich auch mal alle Mons gekillt habe oder versehentlich mehrere OSDs mit gleichen Kopien gezogen habe. CEPH ist sehr Robust und steckt viel weg, aber ggf. eben auch nicht alles.)


Das ist absolut immer das Thema und genau dafür gibt es EC :)
Click to expand...
Ja Balancer ist aktiv, das hatte ich gestern noch geprüft. CEPH ist auch Healthy. Wahrscheinlich entstand der leichte Unterschied wg. der defekten Disk.

Bzgl. Backups: Ja natürlich ;-) Es handelt sich um Off-Site Backups unserer Kunden (die per WAN reinkommen). Unsere eigenen Backups liegen auf einem dedizierten PBS und extern in einem anderen RZ.

Gestern einen EC Pool erstellt. Top :) Ich habe dann mal 500 GB vom Replicated zum EC Pool verschoben. CPU technisch an keiner Stelle zu erkennen. Naja, über den Datendurchsatz der HDDs brauchen wir nicht zu sprechen :-/ <100 MB/s.
 
You must log in or register to reply here.

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Quick Navigation

Home Get Subscription Wiki Downloads Proxmox Customer Portal About

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!
Community platform by XenForo® © 2010-2024 XenForo Ltd.
Top Bottom
Back