Shared Storage zwei Cluster

[pixelpeter]

Hallo,

Aktuell haben wir einen Produktiven- und einen Testcluster.
Mir ist folgendes aufgefallen:
Ich habe auf dem Testcluster eine VM angelegt welche den gleichen Storage wie unser Produktionscluster nutzt.
Die ID gab es schon im Prod. In dem Fall ID 105. Nicht darauf geachtet.
Zwei Platten angelegt und alles funktionierte sauber.
Nach dem Test löschten wir die VM 105 und bekamen umgehend eine Nachricht von Icinga2 das Server xyz Probleme hat. (ID 105 auf Prodcluster.)
Einloggen konnte man sich noch aber nichts mehr bedienen. Wir mussten diesen Stoppen.
Nach dem Start kam der Fehler das die Images nicht gefunden werden können.
Das löschen von VM 105 auf dem Testcluster hat alle Images im Ordner 105 gelöscht. Obwohl die VM mur zwei nutzte.

Eine Lösung wäre es dem Cluster zu sagen nur eine bestimmte ID Range zu nutzen.
Sicher sollte man die Storagevolumen sauber zwischen Prod und Test trennen.
In dem Fall war es aber so das wir unser superschnelle Netapp für diesen Test brauchten.

Peter

 

[Deleted member 34654]

Hier wäre eine Abfrage von proxmox sinnvoll. Ist mir schon öfters aufgefallen und wäre leicht zuscripten.

 

[fabian]

was für eine abfrage?

für shared storages werden cluster-weite locks verwendet, die logischerweise über clustergrenzen hinweg nicht funktionieren. daher -> verschiedene NFS exports/ceph pools/iSCSI targets/... für verschiedene PVE cluster, oder striktes namespacing der gast IDs falls eine trennung auf storage ebene nicht möglich ist (dann bleibt aber immer noch das risiko einer fehlbedienung / missachtung der doku / ...).

 

[pixelpeter]

Hallo Fabian,

Ja das ist alles klar, aber wäre es nicht möglich zumindest die unterste ID die ja scheinbar auf 100 steht pro Cluster zu konfigurieren?

Peter

 

[LnxBil]

Ja das ist alles klar, aber wäre es nicht möglich zumindest die unterste ID die ja scheinbar auf 100 steht pro Cluster zu konfigurieren?

... um dann ein Problem zu lösen, dass man nicht hat wenn man alles richtig macht? Halte ich nicht für sehr zielführend und wird wohl auch nicht implementiert werden wenn es keinen anderen sinnvollen Grund gibt - ich kann mir keinen Vorstellen.

 

[udo]

In dem Fall war es aber so das wir unser superschnelle Netapp für diesen Test brauchten.

Peter

Hallo Peter,
und die "superschnelle Netapp" kann nicht mehrere LUNs bedienen - cluster a bekommt lun-x und cluster b lun-y?
So macht man das gewöhnlich mit dem billigen Fibre-Channel-Kram.

Wenn man shared-storage über Cluster-grenzen nutzt, sollte man sehr genau wissen was man macht (ist. zB. in einer Migrationsphase sinnvoll).

BTW. wenn beim Löschen einer VM nicht alle dazugehörigen VM-Files gelöscht werden, wäre es ein Fehler - nicht anders rum ;-)
Es gibt Leute, die Unused-Disk Einträge aus der Konfig löschen und wenn HDD-Files bestehen bleiben und später von einer neuen VM genutzt werden können, wäre es vom Datenschutz her, sehr bedenklich.

Udo

Allerdings finde ich konfigurierbare Nummernkreise - am besten per Host - sehr interessant. Zur zeit sortiere ich händisch, damit man gleich sieht, welche VMs auf welche Node gehören.

 

[hec]

Eine NetApp kann ausreichend LUNs das ist sicher nicht das Problem.

Naja Nummernkreise pro Host halte ich nicht für sinnvoll - vor allem die Zuordnung wäre nicht sinnvoll möglich. Wenn ein HA Failover passiert würde die Zuordnung nicht mehr stimmen.

Aber Pro Cluster würde das schon einen Sinn ergeben.

Allerdings kenne ich durchaus die Anwendungsfälle um eine VM von Testing nach Prod zu moven. Leider hat man oft den Zeitdruck und da ist es das Einfachste beide Storages gemountet zu haben und die VM zu erstellen und Disk Image importieren. Danach kann man in Ruhe eine das Disk Image verschieben.

Gleiche Vorgangsweise mache ich bei einem Restore. Ich mounte einen FlexClone starte die VM und verschiebe dann das Disk Image. Damit dauert es nur 1min und die VM läuft. Bei großen VMs hat man einfach nicht die Zeit die VM herumzukopieren.

Durch die IDs muss man leider sehr genau aufpassen was man macht. Dies ist ja leider nur ein Integer und nicht eine zufällige ID. Dadurch bekommt man öfters zu einem Reuse der ID. Mir würde ein Hash aus Hostname und MAC sehr gut gefallen. Eventuell noch dazu Timestamp von der Erstellung.

Eventuell wäre es eine gute Idee ein Art Cluster Peering zu haben. Damit könnte man die VMs zwischen den Clustern verschieben.
Wobei natürlich die derzeitige ID Problematik bestehen bleiben würde.

 

[udo]

Naja Nummernkreise pro Host halte ich nicht für sinnvoll - vor allem die Zuordnung wäre nicht sinnvoll möglich. Wenn ein HA Failover passiert würde die Zuordnung nicht mehr stimmen.

Das kommt drauf an! Die Anwendungsscenarien sind halt unterschiedlich.
Wenn man z.B. HA mittels zwei VMs macht - zwei Mysql-Server spiegeln sich gegenseitig und eine Haupt-IP wird intern geschwenkt, dann möchte man auf gar keinen Fall, dass beide VMs gleichzeitig auf einem Host laufen. (das ist nebenbei auch echtes HA, weil funktioniert ohne Ausfall - nur kurzes Timeout bis der IP-Schwenk durch ist (zugegeben: laufende sql-Abfragen sind auch weg) - bei pve-ha wird die VM neu gestartet, alle alten Verbindungen müssen neu aufgebaut werden + ggf. DB-Recovery).
Für diesen Fall hilft eine Nummernzuordnung einfach den Überblick zu halten.
Anderer Fall: mehrere resourcenhungrige Webserver die von einem haproxy angesprochen werden. Auch diese VMs möchte man auf getrennten Hosts laufen lassen (wenn eine VM nicht läuft, kein Problem - das regelt der haproxy. Wenn zwei auf einem Host laufen, kann es sehr wohl ein Problem sein).

Aber Pro Cluster würde das schon einen Sinn ergeben.

Das macht für mich wiederum keinen Sinn...

Allerdings kenne ich durchaus die Anwendungsfälle um eine VM von Testing nach Prod zu moven. Leider hat man oft den Zeitdruck und da ist es das Einfachste beide Storages gemountet zu haben und die VM zu erstellen und Disk Image importieren. Danach kann man in Ruhe eine das Disk Image verschieben.

Sorry, ab das klingt für mich nach einem falschen Konzept. Ja, klar "schiebe" ich VMs von Testing zu Prod, aber das ist innerhalb eines Clusters - da sind halt ein, zwei Nodes für Testing...
Für mich hat auf einem Testing-Cluster keine VM was zu suchen, die jemals zu Prod geschoben wird, weil das Testing bezieht sich auf den Cluster und nicht auf die VM! Wie gesagt Testing auf VM-Basis wird innerhalb des Prod-Clusters geregelt.

Gleiche Vorgangsweise mache ich bei einem Restore. Ich mounte einen FlexClone starte die VM und verschiebe dann das Disk Image. Damit dauert es nur 1min und die VM läuft. Bei großen VMs hat man einfach nicht die Zeit die VM herumzukopieren.

Durch die IDs muss man leider sehr genau aufpassen was man macht.

klar, dass ist dass Scenario bei Cluster-Upgrades. Nur für kurze Zeit, weil man genau wissen muss, was man macht.

Dies ist ja leider nur ein Integer und nicht eine zufällige ID. Dadurch bekommt man öfters zu einem Reuse der ID. Mir würde ein Hash aus Hostname und MAC sehr gut gefallen. Eventuell noch dazu Timestamp von der Erstellung.

Hmm, weiss grad nicht, ob mich mit so einer Hash-ID anfreunden kann. Wäre auf jeden Fall für die Zuordnung VMs zu Node (siehe HA-Mysql-Pärchen) schwierig.
Dann müsste man eine zusätzliche Markierungsmöglichkeit haben, z.B. farbliche Marker - alle blauen VMs laufen auf Node X und alle roten auf Y und Gelb auf Z... damit wären beide Möglichkeiten erschlagen.

Eventuell wäre es eine gute Idee ein Art Cluster Peering zu haben. Damit könnte man die VMs zwischen den Clustern verschieben.
Wobei natürlich die derzeitige ID Problematik bestehen bleiben würde.

Zumindestens die Möglichkeit mehrere Cluster mit einer Oberfläche zu Verwalten kam schon öfters als Wunsch auf.
In wie weit in der Richtung schon etwas entwickelt wird, weiss ich nicht.

Udo

 

[hec]

Was du glaube ich meinst sind die Affinity Rules. Klar die gehören auf Node Basis. Auf sowas warte ich natürlich auch. Wäre sehr sinnvoll um von einem Datacenter auf das andere Umzuschalten ohne wirkliche Downtimes zu haben.

Ich dachte du meinst Nummernkreise für IDs.