usługi prawne, ochrona danych, bezpieczne systemy informatyczne

ich war hier: ProxmoxCephCluster

Revision history for ProxmoxCephCluster


Revision [4755]

Last edited on 2025-02-21 10:48:32 by WojciechLisiewicz
Additions:
ceph osd crush rule create-replicated <rule-name> <root> <failure-domain> <class>
Deletions:
ceph osd crush rule create-replicated <rule-name> <root> <failure-domain> <class>

Revision [4754]

Edited on 2025-02-21 10:48:16 by WojciechLisiewicz
Additions:
((3)) Weiterführende Quellen
Auf jeden Fall sinnvoll: https://forum.proxmox.com/threads/ceph-classes-rules-and-pools.60013/

Revision [4753]

Edited on 2025-02-21 10:16:45 by WojciechLisiewicz
Additions:
%%(bash)
%%(bash)
Deletions:
%%(perl)
%%(perl)

Revision [4752]

Edited on 2025-02-21 10:16:01 by WojciechLisiewicz
Additions:
%%(perl)
%%
Deletions:
%(perl)
%

Revision [4751]

Edited on 2025-02-21 10:15:40 by WojciechLisiewicz
Additions:
Die Einrichtung nach Vorbereitung der passenden Netzwerke ist sehr simpel - hier die etwas komplexeren Fragen, nachdem die einfachen Schritte erledigt sind:
((3)) CRUSH & device classes
Sinnvoll ist vor allem die Trennung verschiedener Arten von Datenträgern - in unserem System wollen wir VM-Datenträger von Anwendungsdaten in der Weise behandeln, dass wir:
- SATA-SSD-s für Daten nutzen ("mittel-schnell")
- NVME-SSD-s für Betriebssysteme ("sehr schnell")
nutzen. Dafür brauchen wir verschiedene Befehle:
%(perl)
# die Klassen erst mal nur anzeigen:
ceph osd crush tree --show-shadow
# crush rule für die Klasse definieren:
ceph osd crush rule create-replicated <rule-name> <root> <failure-domain> <class>
%

Revision [4750]

Edited on 2025-02-20 23:13:48 by WojciechLisiewicz
Additions:
((2)) Sinnvolle Operationen
Das Netzwerk ist in einem Cluster mit sehr vielen Netzwerkgeräten verbunden - Switche, Netzwerkkarten, Verkabelung... Vor diesem Hintergrund ist es nützlich, einige Funktionen im Linux Netzwerk Stack zu beherrschen. Die [[ Doku dazu ist hier zu finden]].

Revision [4746]

Edited on 2025-02-20 19:51:31 by WojciechLisiewicz

No Differences

Revision [4745]

Edited on 2025-02-20 19:28:57 by WojciechLisiewicz
Additions:
((2)) Bestandteile
Ein Ceph-System setzt sich zusammen aus verschiedenen Diensten (//daemons//):
- Ceph Monitor (ceph-mon, or MON)
- Ceph Manager (ceph-mgr, or MGS)
- Ceph Metadata Service (ceph-mds, or MDS)
- Ceph Object Storage Daemon (ceph-osd, or OSD)
((2)) Einrichtung

Revision [4744]

Edited on 2025-02-20 19:27:04 by WojciechLisiewicz
Additions:
%%(perl)
Deletions:
%%(php)

Revision [4743]

Edited on 2025-02-20 19:26:42 by WojciechLisiewicz
Additions:
%%(php)
Deletions:
%%(perl)

Revision [4742]

Edited on 2025-02-20 19:26:32 by WojciechLisiewicz
Additions:
%%(perl)
Deletions:
%%(bash)

Revision [4741]

Edited on 2025-02-20 19:26:22 by WojciechLisiewicz
Additions:
%%(bash)
Deletions:
%%(ini)

Revision [4740]

Edited on 2025-02-20 19:26:05 by WojciechLisiewicz
Additions:
((2)) Aufteilung des Netzwerkverkehrs bei einem Ceph-Cluster
Lokale! Ganz simpel - sonst sind sie zu langsam!
Eine Möglichkeit ist ein leistungsfähiger Router mit Zeitserver (bei uns: OPNsense) - aber Vorsicht bei dessen Virtualisierung - da wir das vorhaben, muss dann wohl ein dedizierter, sparsamer Zeitserver her (Raspi?)
((2)) Einrichtung des ##chronyd##
Einfach die Datei ##/etc/chrony/chrony.conf## bearbeiten und die Server wie folgt eintragen:
%%(ini)
server 10.1.0.1 iburst prefer
server 0.pool.ntp.org iburst
server 1.pool.ntp.org iburst
server 2.pool.ntp.org iburst
server 3.pool.ntp.org iburst
# Use Debian vendor zone. => auskommentieren!
# pool 2.debian.pool.ntp.org iburst%%
((1)) Ceph selbst
Deletions:
((2)) Aufteilung des Netzwerkverlehrs bei einem Ceph-Cluster
((2)) Einrichtung des ##cronyd##

Revision [4739]

Edited on 2025-02-20 15:43:40 by WojciechLisiewicz
Additions:
((1)) Zeitsynchronisation
Es müssen effiziente und gut funktionierende Zeitserver eingestellt werden, sonst ist die Zeit im Cluster nicht synchron und dies führt zu gravierenden Problemen.
((2)) Welche Zeitserver nehmen?
((2)) Einrichtung des ##cronyd##
Deletions:
-

Revision [4738]

Edited on 2025-02-19 22:55:22 by WojciechLisiewicz
Additions:
Damit ging es schon, zwischen den Nodes über ##vmbr1## zu kommunizieren. Sollte auch noch VLAN 11 im Switch korrekt konfiguriert werden, dann ist wichtig, dass die Ports, die TX Tagging bekommen (TAG 11, Ports an die ##eno1## angeschlossen ist, bekommen dort Haken gesetzt) nicht auf ##Forbidden## oder ##Normal## stehen, sondern auf ##Fixed##

Revision [4737]

Edited on 2025-02-19 22:50:30 by WojciechLisiewicz
Additions:
Zyxel XGS1930 leitete Pakete vom oben genannten VLAN (##vmbr1##) nicht weiter. Lange suche, inkl. switch-reset brachte eine simple Lösung (da war KI zumindest mittelbar hilfreich) - siehe im Zyxel WebUI:
- Advanced Application => VLAN => VLAN Configuration => VLAN Port Setup
- für die Ports, an die die ##eno1## angeschlossen ist, bei **VLAN Trunking** Haken setzen!
((3)) tbc
Deletions:
Zyxel XGS1930 führte Pakete vom oben genannten VLAN (##vmbr1##)

Revision [4736]

Edited on 2025-02-19 22:46:56 by WojciechLisiewicz
Additions:
((2)) Schritt für Schritt
Folgende Schritte waren notwendig:
((3)) Netzwerkvorbereitung für cluster
Plan: corosync auf zwei NICs zu verteilen:
(1) NIC 1 onboard
Da hier auch schon Management und Internet für die //nodes// läuft, sollte diese Schnittstelle über VLAN laufen. Also:
- VLAN auf ##eno1## als ##eno1.11## erstellen (ohne IP oder Gateway)
- auf dem VLAN ##eno1.11## die Bridge ##vmbr1## einrichten
- ##vmbr1## bekommt IP ##10.99.1.node##
-

(2) NIC 1 auf PCIe Netzwerkkarte
Hier wird nur eine normale Bridge erstellt - direkt auf dem NIC:
- auf ##ens1## wird ##vmbr2## erstellt
- sie bekommt IP ##10.99.2.node##
((3)) VLAN Problem auf dem Switch
Zyxel XGS1930 führte Pakete vom oben genannten VLAN (##vmbr1##)
Deletions:
((2))

Revision [4730]

Edited on 2025-02-08 20:24:05 by WojciechLisiewicz
Additions:
Sobald ein //VNet// definiert wurde (unter "datacenter" => "SDN"), dann ist es in jedem //node// lokal sichtbar - als eine normale //Linux bridge// und jede VM oder jeder Container kann an diese angebunden werden.
Deletions:
Sobald ein //VNet// definiert wurde (unter "datacenter" => "SDN"), dann ist es unter administration interface, it is available as a common Linux bridge, locally on each node, to be assigned to VMs and Containers.

Revision [4729]

Edited on 2025-02-08 20:10:45 by WojciechLisiewicz
Additions:
- Zone = Bestimmung der Möglichkeiten / Techniken für Netzwerke. Getrennter Bereich für Netzwerke
- VNet = virtuelles Netzwerk in einer //zone//
- Subnet = IP range, also wie immer
Sobald ein //VNet// definiert wurde (unter "datacenter" => "SDN"), dann ist es unter administration interface, it is available as a common Linux bridge, locally on each node, to be assigned to VMs and Containers.
Deletions:
Zone = Bestimmung der Möglichkeiten / Techniken für Netzwerke. Getrennter Bereich für Netzwerke
VNet = virtuelles Netzwerk in einer //zone//
Subnet = IP range, also wie immer

Revision [4728]

Edited on 2025-02-08 20:02:29 by WojciechLisiewicz
Additions:
""zone <==== vnet <==== subnet""
Deletions:
zone <==== vnet <==== subnet

Revision [4727]

Edited on 2025-02-08 20:02:07 by WojciechLisiewicz
Additions:
((2)) Aufteilung des Netzwerkverlehrs bei einem Ceph-Cluster
Ein Cluster hängt maßgeblich vom Netzwerk ab. Wir brauchen bei CEPH - gem. Doku von Proxmox - im Zweifel folgende, parallele Netzwerke in der Konfiguration:
- sehr schnelles Netzwerk (25+ Gbps) => //Ceph INTERNAL//
- schnelles Netzwerk (10+ Gpbs) => //Ceph PUBLIC//
- mit //Ceph PUBLIC// kann auch verbunden werden //virtual guest traffic// und //VM live-migration traffic//
=> aber mit alternativer Lösung auch getrennt sinnvoll?
- normales Netzwerk (1 Gbps) **exklusiv** für //corosync// (Kommunikation im Cluster);
((3)) Ceph INTERNAL

((3)) Ceph PUBLIC

((3)) virtual guest traffic

((3)) VM live-migration traffic

((3)) corosync traffic
Neben **exklusiv** und **niedrige Latenz** ist hier die Besonderheit, dass dieses über mehrere Netzwerke laufen kann! Also kann es so funktionieren:
- Netzwerk corosync 1 = 10.10.1.0/24 über einen separaten Switch (keinerlei Verbindung mit anderen Netzwerken); immer über ersten NIC der __gesteckten__ Netzwerkkarte
- Netzwerk corosync 2 = 10.10.2.0/24 über den normalen Switch für ganzes Netzwerk auf anderem VLAN (?) als Management aber auf der Netzwerkkarte mit Management (Karte __onboard__)

((2)) Konfiguration des SDN
Software Defined Network ist in Proxmox ab V.8.1 standardmäßig aktiv. Es müsste die Konfiguration der Netzwerke wohl erleichtern. Hier werden die essenziellen Informationen gesammelt.

((3)) Struktur
Kurz in etwa so zu verstehen:

zone <==== vnet <==== subnet

Zone = Bestimmung der Möglichkeiten / Techniken für Netzwerke. Getrennter Bereich für Netzwerke
VNet = virtuelles Netzwerk in einer //zone//
Subnet = IP range, also wie immer
((2))
Deletions:
Ein Cluster hängt maßgeblich vom Netzwerk ab. Wir brauchen - gem. Doku von Proxmox - im Zweifel folgende, parallele Netzwerke in der Konfiguration:
- sehr schnelles Netzwerk (25+ Gbps) => //Ceph INTERNAL//
- schnelles Netzwerk (10+ Gpbs) => //Ceph PUBLIC//
- mit //Ceph PUBLIC// kann auch verbunden werden //virtual guest traffic// und //VM live-migration traffic//
=> aber mit alternativer Lösung auch getrennt sinnvoll?
- normales Netzwerk (1 Gbps) **exklusiv** für //corosync// (Kommunikation im Cluster);
((2)) Ceph INTERNAL
((2)) Ceph PUBLIC
((2)) virtual guest traffic
((2)) VM live-migration traffic
((2)) corosync traffic
Neben **exklusiv** und **niedrige Latenz** ist hier die Besonderheit, dass dieses über mehrere Netzwerke laufen kann! Also kann es so funktionieren:
- Netzwerk corosync 1 = 10.10.1.0/24 über einen separaten Switch (keinerlei Verbindung mit anderen Netzwerken); immer über ersten NIC der __gesteckten__ Netzwerkkarte
- Netzwerk corosync 2 = 10.10.2.0/24 über den normalen Switch für ganzes Netzwerk auf anderem VLAN (?) als Management aber auf der Netzwerkkarte mit Management (Karte __onboard__)

Revision [4726]

Edited on 2025-02-08 19:44:08 by WojciechLisiewicz
Deletions:

Revision [4725]

Edited on 2025-02-08 19:43:55 by WojciechLisiewicz
Additions:
((1)) Netzwerk-Config
Ein Cluster hängt maßgeblich vom Netzwerk ab. Wir brauchen - gem. Doku von Proxmox - im Zweifel folgende, parallele Netzwerke in der Konfiguration:
- sehr schnelles Netzwerk (25+ Gbps) => //Ceph INTERNAL//
- schnelles Netzwerk (10+ Gpbs) => //Ceph PUBLIC//
- mit //Ceph PUBLIC// kann auch verbunden werden //virtual guest traffic// und //VM live-migration traffic//
=> aber mit alternativer Lösung auch getrennt sinnvoll?
- normales Netzwerk (1 Gbps) **exklusiv** für //corosync// (Kommunikation im Cluster);

((2)) Ceph INTERNAL

((2)) Ceph PUBLIC

((2)) virtual guest traffic

((2)) VM live-migration traffic

((2)) corosync traffic
Neben **exklusiv** und **niedrige Latenz** ist hier die Besonderheit, dass dieses über mehrere Netzwerke laufen kann! Also kann es so funktionieren:

- Netzwerk corosync 1 = 10.10.1.0/24 über einen separaten Switch (keinerlei Verbindung mit anderen Netzwerken); immer über ersten NIC der __gesteckten__ Netzwerkkarte
- Netzwerk corosync 2 = 10.10.2.0/24 über den normalen Switch für ganzes Netzwerk auf anderem VLAN (?) als Management aber auf der Netzwerkkarte mit Management (Karte __onboard__)




Revision [4718]

The oldest known version of this page was created on 2025-02-04 22:41:34 by WojciechLisiewicz
Valid XHTML  |  Valid CSS  |  Powered by WikkaWiki