1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Shared Storage zwei Cluster

Discussion in 'Deutsch' started by pixelpeter, Dec 7, 2017.

  1. pixelpeter

    pixelpeter Member
    Proxmox VE Subscriber

    Joined:
    Aug 5, 2015
    Messages:
    62
    Likes Received:
    0
    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
     
  2. Markus Thormann

    Proxmox VE Subscriber

    Joined:
    Oct 25, 2015
    Messages:
    150
    Likes Received:
    9
    Hier wäre eine Abfrage von proxmox sinnvoll. Ist mir schon öfters aufgefallen und wäre leicht zuscripten.
     
  3. fabian

    fabian Proxmox Staff Member
    Staff Member

    Joined:
    Jan 7, 2016
    Messages:
    2,521
    Likes Received:
    343
    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 / ...).
     
  4. pixelpeter

    pixelpeter Member
    Proxmox VE Subscriber

    Joined:
    Aug 5, 2015
    Messages:
    62
    Likes Received:
    0
    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
     
  5. LnxBil

    LnxBil Well-Known Member

    Joined:
    Feb 21, 2015
    Messages:
    2,166
    Likes Received:
    142
    ... 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.
     
  6. udo

    udo Well-Known Member
    Proxmox VE Subscriber

    Joined:
    Apr 22, 2009
    Messages:
    5,366
    Likes Received:
    100
    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.
     
  7. hec

    hec Member

    Joined:
    Jan 8, 2009
    Messages:
    179
    Likes Received:
    5
    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.
     
  8. udo

    udo Well-Known Member
    Proxmox VE Subscriber

    Joined:
    Apr 22, 2009
    Messages:
    5,366
    Likes Received:
    100
    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).
    Das macht für mich wiederum keinen Sinn...
    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.
    klar, dass ist dass Scenario bei Cluster-Upgrades. Nur für kurze Zeit, weil man genau wissen muss, was man macht.
    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.
    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
     
    #8 udo, Dec 9, 2017
    Last edited: Dec 9, 2017
  9. hec

    hec Member

    Joined:
    Jan 8, 2009
    Messages:
    179
    Likes Received:
    5
    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.
     

Share This Page