17
Hyper-V-Host mit einem Storage betreiben
Guten Abend,
mal eine Frage zum Betrieb zweier Hyper-V-Hosts mit einem Storage.
Im Szenario liegen zwei Server vor, die jeweils einen Hyper-V-Host auf Basis Windows 2012 R2 ausführen.
Beide Server sind mittels einem SAS-Band an einen Storage angebunden und sehen den Datenträger in der Datenträgerverwaltung auch.
Der erste Server kann ganz normal auf den Datenträger zu greifen, Ordner anlegen und darin arbeiten.
Der zweite Server kann den Datenträger nur dann benutzen, wenn er diesen als "fremden Datenträger importieren" nutzt.
Er kann Ordner anlegen, und sieht alle Ordner, die zu dieser Zeit bereits angelegt waren.
Wechsel ich nun auf den ersten Host, sieht er aber die neuen Ordner nicht. Legt der erste Host Ordner an, sieht diese der zweite Host nicht.
Dachte erst an ein Rechteproblem und gab dem Datenträger das Recht des Domänenadministrator - dennoch, obwohl beide Hosts als Domänenadmin angemeldet sind,
sehen diese nicht was der andere Host gemacht hat.
Nach einem Neustart beider Hosts, musste der Datenträger wieder neu online gestellt werden - dann waren die aber zuvor angelegten Ordner des zweiten Hosts gänzlich weg (evtl. auch nur nicht mehr sichtbar).
Kopiere ich nun eine virtuelle Maschine vom zweiten Host auf den Storage, kann ich diese ganz normal ausführen. Also sind ja die Daten auf dem Storage vorhanden.
Müsste ich nicht eigentlich bei der Konstellation die Ordner die angelegt werden (bzw. auch die virtuellen Maschinen) sofort sehen oder hab ich da einen grundlegenden Denkfehler?
Grüße
Forseti
mal eine Frage zum Betrieb zweier Hyper-V-Hosts mit einem Storage.
Im Szenario liegen zwei Server vor, die jeweils einen Hyper-V-Host auf Basis Windows 2012 R2 ausführen.
Beide Server sind mittels einem SAS-Band an einen Storage angebunden und sehen den Datenträger in der Datenträgerverwaltung auch.
Der erste Server kann ganz normal auf den Datenträger zu greifen, Ordner anlegen und darin arbeiten.
Der zweite Server kann den Datenträger nur dann benutzen, wenn er diesen als "fremden Datenträger importieren" nutzt.
Er kann Ordner anlegen, und sieht alle Ordner, die zu dieser Zeit bereits angelegt waren.
Wechsel ich nun auf den ersten Host, sieht er aber die neuen Ordner nicht. Legt der erste Host Ordner an, sieht diese der zweite Host nicht.
Dachte erst an ein Rechteproblem und gab dem Datenträger das Recht des Domänenadministrator - dennoch, obwohl beide Hosts als Domänenadmin angemeldet sind,
sehen diese nicht was der andere Host gemacht hat.
Nach einem Neustart beider Hosts, musste der Datenträger wieder neu online gestellt werden - dann waren die aber zuvor angelegten Ordner des zweiten Hosts gänzlich weg (evtl. auch nur nicht mehr sichtbar).
Kopiere ich nun eine virtuelle Maschine vom zweiten Host auf den Storage, kann ich diese ganz normal ausführen. Also sind ja die Daten auf dem Storage vorhanden.
Müsste ich nicht eigentlich bei der Konstellation die Ordner die angelegt werden (bzw. auch die virtuellen Maschinen) sofort sehen oder hab ich da einen grundlegenden Denkfehler?
Grüße
Forseti
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 353333
Url: https://administrator.de/contentid/353333
Ausgedruckt am: 22.11.2024 um 09:11 Uhr
17 Kommentare
Neuester Kommentar
Schönen Guten Abend
So ganz grundlegend würde ich sagen, selbe Datei zur gleichen Zeit von zwei Seiten her bearbeitet -> Schlechte Idee
So ganz grundlegend würde ich sagen, selbe Datei zur gleichen Zeit von zwei Seiten her bearbeitet -> Schlechte Idee
Das keyword lautet: Active-passive Cluster...du scheinst das falsche Storage für dein Ziel zu haben...
Das ist ja nicht der Fall - wie oben geschrieben, in der ersten Versuchsreihe wurden ja nur Ordner angelegt. Dies von zwei verschiedenen Hosts. Der Zugriff auf eine Datei fällt dabei erstmal nicht ins Gewicht.
Zum Active/Active bzw. Active/Passiv-Cluster - ist damit nicht eher gemeint, das entweder zwei Hosts sich die Last teilen (a/a) oder nur im Failover anspringen (a/p)?
Zum Active/Active bzw. Active/Passiv-Cluster - ist damit nicht eher gemeint, das entweder zwei Hosts sich die Last teilen (a/a) oder nur im Failover anspringen (a/p)?
Wenn dein Storage so konfiguriert oder vorgesehen ist, kann es durchaus zu deinem Verhalten kommen, aber - wie immer - ist "ein Storage" nichts greifbares...
So far, schönen Feiertag.
So far, schönen Feiertag.
Zitat von @Forseti2003:
Zum Active/Active bzw. Active/Passiv-Cluster - ist damit nicht eher gemeint, das entweder zwei Hosts sich die Last teilen (a/a) oder nur im Failover anspringen (a/p)?
Zum Active/Active bzw. Active/Passiv-Cluster - ist damit nicht eher gemeint, das entweder zwei Hosts sich die Last teilen (a/a) oder nur im Failover anspringen (a/p)?
Kommt drauf an was du willst. Sollen beide Server auf die gleichen VMs zugreifen oder willst du auf beiden Systemen unterschiedliche VMs starten? So grundsaetzlich kann ein NTFS Volume nicht von beiden Servern gleichzeitig benutzt werden.
VG,
Thomas
Im Prinzip soll es nur einen gemeinsamen Storage zur Verfügung stellen, in dem VM's abgelegt werden. Die Hosts selbst "arbeiten" mit ihren jeweiligen VM's. Fällt ein Host aus, will ich einfach nur schnell die VM bei einem zweiten Host einbinden und dort starten lassen. Das Konzept mach ich bei vmware ohne Problem - nur hier im Hyper-V gibt es ein Problem.
Na dann, falsches Setting, die II. Trotzdem noch keine Nennung des Storage..
Ist ein DELL MD3200
The Dell PowerVault MD3200i storage system supports active/active controllers, with each
controller being able to simultaneous process I/O. The asymmetric design of the controllers means that
a virtual disk (logical unit number or LUN) is owned by a controller, and all I/O access to the virtual
disk is only possible through the owning controller. To take advantage of both the controllers for I/O
access, distribute virtual disks among the controllers and modify them to balance I/O access so as to
balance controller utilization.
Wo wir wieder beim Thema Datenblätter lesen sind.
controller being able to simultaneous process I/O. The asymmetric design of the controllers means that
a virtual disk (logical unit number or LUN) is owned by a controller, and all I/O access to the virtual
disk is only possible through the owning controller. To take advantage of both the controllers for I/O
access, distribute virtual disks among the controllers and modify them to balance I/O access so as to
balance controller utilization.
Wo wir wieder beim Thema Datenblätter lesen sind.
hm,...hab aber keinen MD3200i ....
Gut, funktioniert es bei dir anders?
Naja, es funktioniert zumindest nicht so, wie ich es gerne hätte - aber das will ja erstmal nichts heißen.
Zur Konfiguration: Vier Festplatten sind zusammengefasst als eine virtuelle Disk, diese hat einen Raid-Level 10.
Gemäß Übersicht ist die virtuelle Disk über LUN 0 erreichbar für den Zugriff der Host-Gruppe (darin enthalten alle beide Hosts und deren Port-Kennungen).
Sieht soweit unverdächtig aus. Bei den beiden Hyper-V-Hosts sind es Windows Server 2012 R2 - diese haben das Feature MPIO aktiv installiert und sehen über die Datenträgerverwaltung die virtuelle Disk. Also bis dahin alles normal.
Ist das Laufwerk nun bei beiden Servern online geschaltet, wird das Laufwerk auch richtig angezeigt, Daten die bereits vorhanden sind, können beide Hosts sehen. Legt aber nun ein Host einen Ordner (ohne Dateien) an, kann der andere Host diese nicht sehen.
Im Laufwerk selbst habe ich unter Sicherheit die beiden Hosts als Computerkonto direkt eingetragen und Rechte zum Lesen/Ändern/Schreiben gegeben.
Gemäß Technischem Datenblatt können über die Port-Konnektoren 4-8 Server (redudant/unredudant) angeschlossen werden und zwei RAID-Controller sind auch verbaut, die virtuelle Disk wird aber über Controller1 bevorzugt und aktuell genutzt.
Zur Konfiguration: Vier Festplatten sind zusammengefasst als eine virtuelle Disk, diese hat einen Raid-Level 10.
Gemäß Übersicht ist die virtuelle Disk über LUN 0 erreichbar für den Zugriff der Host-Gruppe (darin enthalten alle beide Hosts und deren Port-Kennungen).
Sieht soweit unverdächtig aus. Bei den beiden Hyper-V-Hosts sind es Windows Server 2012 R2 - diese haben das Feature MPIO aktiv installiert und sehen über die Datenträgerverwaltung die virtuelle Disk. Also bis dahin alles normal.
Ist das Laufwerk nun bei beiden Servern online geschaltet, wird das Laufwerk auch richtig angezeigt, Daten die bereits vorhanden sind, können beide Hosts sehen. Legt aber nun ein Host einen Ordner (ohne Dateien) an, kann der andere Host diese nicht sehen.
Im Laufwerk selbst habe ich unter Sicherheit die beiden Hosts als Computerkonto direkt eingetragen und Rechte zum Lesen/Ändern/Schreiben gegeben.
Gemäß Technischem Datenblatt können über die Port-Konnektoren 4-8 Server (redudant/unredudant) angeschlossen werden und zwei RAID-Controller sind auch verbaut, die virtuelle Disk wird aber über Controller1 bevorzugt und aktuell genutzt.
angeschlossen, ja..zugegriffen, nein, siehe auch oben.
nicht ganz, oben steht das nur ein Controller darauf zugreifen kann - und der I/O über diesen läuft, aber die Hosts sind ja an diesem Controller angeschlossen. Ich kann ja auch Daten von beiden Hosts auf der virtuellen Disk speichern und darauf zugreifen - die Einschränkung liegt ja nur darin, das nicht beide Hosts dabei alles sehen oder nutzen können, sondern nur die eigenen Vorgänge. Verhält sich eher, als wenn das Rechtesystem gerade rumzickt.
Das was du gerade versuchst funktioniert nicht. Wenn du mit zwei Hyper-V Hosts auf eine LUN zugreifen willst brauchst du einen Cluster. Stichwort Cluster Shared Volumes...
VG,
Thomas
So, ein wenig später aber durch Feiertage und ähnliche arbeitstechnische Hindernisse kann ich jetzt eine Rückmeldung dazu geben
Erstmal dicken Dank an tkr104 - der Hinweis mit dem Cluster in MS hat die Lösung ergeben.
Ich habe nun probehalber einen Raidverbund (Raid10) aufgebaut, dieser hatte eine Kapazität von 1 TB, die ich in jeweils 100 GB große Stücke geschnitten habe und diese dann jeweils beiden Hosts zugewiesen. Nach ein wenig Studieren der Technik im Hyper-V-Cluster klappt das nun weitgehend so wie ich mir das vorstelle, also die ursprüngliche Annahme der Storage könnte das Problem sein, ist damit erstmal vom Tisch.
Jedoch treten mir aktuell drei Kleinigkeiten auf, die mich noch ein wenig stören:
1) Livemigration - Diese ging gestern, heute bricht sie ständig ab mit dem Hinweis auf eine Reparatur im Netzwerk. Sehe aber nichts verdächtiges, was das erklären könnte. Die Adapter heißen auch auf beiden Hosts identsich (subnet04). Da die Livemigration jetzt nicht bei mir auf der obersten Priorität lebt, kann ich damit leben, würde aber schon gerne wissen, was den Fehler auslöst. Praktisch ist die Funktion ja schon
2) Wenn ich eine VM im Speicher verschieben will erhalte ich eine Fehlermeldung Allgemeiner "Zugriff verweigert"-Fehler 0x80070005 - Arbeite aber aktuell nur von einem Host aus und Host01 hat alle Laufwerke bei sich und kann darin auch schreiben, aber die Funktion über den Cluster mag nicht
3) Einziges Problem was mich ein wenig vorsichtig stimmt. Wenn ich die einzelnen Festplatten zwischen den Hosts verschiebe, klappt das nicht immer zu 100%. Manchmal sagt er, das die Festplatte nur auf Host02 geschoben werden kann, obwohl sich diese dort befindet und zu Host01 soll. Danach tritt ein plötzlicher Offline der Festplatten auf (auch wenn aktive VM's darauf sind). Dieser kann zwar sofort behoben werden und die VM wird auch sauber gestartet - aber für einen späteren Produktiveinsatz macht mich das gerade ein wenig nachdenklich.
Wenn dazu noch jemand eine Idee oder Tipps hat, Thema Cluster ist für mich halt noch ein großes Neuland, wäre ich sehr verbunden.
Erstmal dicken Dank an tkr104 - der Hinweis mit dem Cluster in MS hat die Lösung ergeben.
Ich habe nun probehalber einen Raidverbund (Raid10) aufgebaut, dieser hatte eine Kapazität von 1 TB, die ich in jeweils 100 GB große Stücke geschnitten habe und diese dann jeweils beiden Hosts zugewiesen. Nach ein wenig Studieren der Technik im Hyper-V-Cluster klappt das nun weitgehend so wie ich mir das vorstelle, also die ursprüngliche Annahme der Storage könnte das Problem sein, ist damit erstmal vom Tisch.
Jedoch treten mir aktuell drei Kleinigkeiten auf, die mich noch ein wenig stören:
1) Livemigration - Diese ging gestern, heute bricht sie ständig ab mit dem Hinweis auf eine Reparatur im Netzwerk. Sehe aber nichts verdächtiges, was das erklären könnte. Die Adapter heißen auch auf beiden Hosts identsich (subnet04). Da die Livemigration jetzt nicht bei mir auf der obersten Priorität lebt, kann ich damit leben, würde aber schon gerne wissen, was den Fehler auslöst. Praktisch ist die Funktion ja schon
2) Wenn ich eine VM im Speicher verschieben will erhalte ich eine Fehlermeldung Allgemeiner "Zugriff verweigert"-Fehler 0x80070005 - Arbeite aber aktuell nur von einem Host aus und Host01 hat alle Laufwerke bei sich und kann darin auch schreiben, aber die Funktion über den Cluster mag nicht
3) Einziges Problem was mich ein wenig vorsichtig stimmt. Wenn ich die einzelnen Festplatten zwischen den Hosts verschiebe, klappt das nicht immer zu 100%. Manchmal sagt er, das die Festplatte nur auf Host02 geschoben werden kann, obwohl sich diese dort befindet und zu Host01 soll. Danach tritt ein plötzlicher Offline der Festplatten auf (auch wenn aktive VM's darauf sind). Dieser kann zwar sofort behoben werden und die VM wird auch sauber gestartet - aber für einen späteren Produktiveinsatz macht mich das gerade ein wenig nachdenklich.
Wenn dazu noch jemand eine Idee oder Tipps hat, Thema Cluster ist für mich halt noch ein großes Neuland, wäre ich sehr verbunden.
Okay, Punkt 1) mit der Livemigration bitte schließen, wie doof, hatte in den virtuellen Switches die Bezeichnung nicht exakt 1:1 drin gehabt.
und Punkt 2) ist auch erledigt. Ich musste im Clustervolumen erst einen Unterordner anlegen, ins Root mag er wohl nicht
Damit bleibt nur noch Punkt 3) und den muss ich wohl jetzt noch die nächsten Tage ausgiebig testen und prüfen. Wäre peinlich wenn das im Livebetrieb passiert.
und Punkt 2) ist auch erledigt. Ich musste im Clustervolumen erst einen Unterordner anlegen, ins Root mag er wohl nicht
Damit bleibt nur noch Punkt 3) und den muss ich wohl jetzt noch die nächsten Tage ausgiebig testen und prüfen. Wäre peinlich wenn das im Livebetrieb passiert.
