11
QNAP NAS als iSCSI-Storage für Hyper-V Cluster in einer Testumgebung
Hallo zusammen,
ich habe hier eine kleine Testumgebung die seit 3 Tagen aus absolut unerklärlichen Gründen Probleme macht. Der Aufbau sieht wie folgt aus:
2x Server mit Win 2012 R2 mit je einem 1 GBit-Interface für iSCSI
1x QNAP TS-569Pro (FW 4.1.1 vom 03.10) mit 2 Interfaces als Trunk (RR) und einem Raid 1 mit jeweils 2TB HDD.
Die zwei Server greifen via iSCSI auf das NAS zu und nutzen dieses als Cluster Shared Volume für einen kleinen Hyper-V Cluster. Auf dem Cluster laufen 5 Server mit Windows 2012 R2 die alle nicht viel zu tun haben. Einer davon ist ein Exchange 2013 mit 5 Postfächern.
Seit drei Tagen nun stürzt regelmäßig das CSV zusammen, sobald etwas last entsteht. Verschiebe ich z.B. eine Maschine, dann ist sofort das Storage vom Quellhost nicht mehr erreichbar. Ne Minute später kann er dann wieder zugreifen. Der andere Host bekommt das nicht mit, der greift weiterhin Problemlos zu.
Das Backup (Veeam Backup), welches von den Platten ließt, funktioniert komischerweise einwandfrei.
Es kam zwar schon hin und wieder mal vor, dass das Storage kurz nicht erreichbar war (1-2 mal im Monat vielleicht), aber in dem Ausmaß habe ich das Problem erst seit vorgestern.
Ist das ein Problem was durch die neue Firmware entstanden ist oder was stimmt hier nicht?
Ich hoffe auf schnelle Hilfe. Vielen Dank!
Grüße
ich habe hier eine kleine Testumgebung die seit 3 Tagen aus absolut unerklärlichen Gründen Probleme macht. Der Aufbau sieht wie folgt aus:
2x Server mit Win 2012 R2 mit je einem 1 GBit-Interface für iSCSI
1x QNAP TS-569Pro (FW 4.1.1 vom 03.10) mit 2 Interfaces als Trunk (RR) und einem Raid 1 mit jeweils 2TB HDD.
Die zwei Server greifen via iSCSI auf das NAS zu und nutzen dieses als Cluster Shared Volume für einen kleinen Hyper-V Cluster. Auf dem Cluster laufen 5 Server mit Windows 2012 R2 die alle nicht viel zu tun haben. Einer davon ist ein Exchange 2013 mit 5 Postfächern.
Seit drei Tagen nun stürzt regelmäßig das CSV zusammen, sobald etwas last entsteht. Verschiebe ich z.B. eine Maschine, dann ist sofort das Storage vom Quellhost nicht mehr erreichbar. Ne Minute später kann er dann wieder zugreifen. Der andere Host bekommt das nicht mit, der greift weiterhin Problemlos zu.
Das Backup (Veeam Backup), welches von den Platten ließt, funktioniert komischerweise einwandfrei.
Es kam zwar schon hin und wieder mal vor, dass das Storage kurz nicht erreichbar war (1-2 mal im Monat vielleicht), aber in dem Ausmaß habe ich das Problem erst seit vorgestern.
Ist das ein Problem was durch die neue Firmware entstanden ist oder was stimmt hier nicht?
Ich hoffe auf schnelle Hilfe. Vielen Dank!
Grüße
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 252435
Url: https://administrator.de/contentid/252435
Printed on: April 27, 2024 at 01:04 o'clock
11 Comments
Latest comment
Ich tippe auf Connection Lost, Was sagt die Ereignis Anzeige? Monitor den Switch mal
Im Eventlog taucht folgende Meldung mehrfach auf:
Das freigegebene Clustervolume "Volume1" ("Clusterdatenträger 2") befindet sich aufgrund von "(c0000010)" in einem angehaltenen Zustand. Alle E/A-Aktivitäten werden vorübergehend in eine Warteschlange aufgenommen, bis wieder ein Pfad zum Volume eingerichtet ist.
Ein zweites Volume, welches auf dem gleichen QNAP läuft, funktioniert weiterhin. Ich habe mittlerweile den Verdacht, dass es an der QNAP liegt. Ein Firmware-Downgrade hat jedoch leider auch nichts geholfen.
Lesen kann man von dem Storage ohne Probleme, nur beim schreiben von vielen Daten entsteht dieses Problem.
Das freigegebene Clustervolume "Volume1" ("Clusterdatenträger 2") befindet sich aufgrund von "(c0000010)" in einem angehaltenen Zustand. Alle E/A-Aktivitäten werden vorübergehend in eine Warteschlange aufgenommen, bis wieder ein Pfad zum Volume eingerichtet ist.
Ein zweites Volume, welches auf dem gleichen QNAP läuft, funktioniert weiterhin. Ich habe mittlerweile den Verdacht, dass es an der QNAP liegt. Ein Firmware-Downgrade hat jedoch leider auch nichts geholfen.
Lesen kann man von dem Storage ohne Probleme, nur beim schreiben von vielen Daten entsteht dieses Problem.
Dann würde ich wohl auch dein ISCSI Adapter überprüfen / testweise tauschen
Den Verdacht hatte ich bereits auch schon und habe deshalb den Adapter gewechselt, allerdings wäre der Zufall auch extrem groß wenn dad Problem an zwei Servern gleichzeitig auftaucht.
Stimmt, dann würde ich aber auf Treiber tippen. Zufällig andere Zur Hand?
hab das nun noch mit ner anderen Karte (Intel Dual Server Adapter) getestet, hat jedoch den gleichen Effekt.
Oh ich wird zum Hirsch!
Oh ich wird zum Hirsch!
Kabel? Switch? Port?
Alles durchgecheckt und gewechselt.
Hallo
Ich denke das mit sehr hoher Wahrscheinlichkeit die Konfiguration des iSCSI nicht richtig ist. Bei der Fehlermeldung die Du beschreibst sieht es für mich so aus, als wenn beide Hosts gleichzeitig auf die NAS zugreifen. Das darf natürlich in einem Dateisystem egal welcher Art nicht passieren. Es muss immer ein Hosts die primären Lese und Schreibrechte haben.Über ihn der primäre Host verwaltet die Lesung schreibe recht. Nur so kann ein Cluster auch funktionieren.
Schau mal im Festplattenmanager nach, ob bei dem einen Host die Festplatte im Vollzugriff ist und auf dem anderen Hosts als "reserviert" gekennzeichnet ist.So muss es auf jeden Fall sein Wenn Du von beiden Systemen gleichzeitig auf das NAS Laufwerk zugreifen kannst, stimmt mit der Konfiguration was nicht.Und dann musst Du genau hier ansetzen. Ich würde auf alle Fälle die VMs mal Weg sichern und dann über den FailOver Clustermanager mal den Cluster überprüfen lassen. Ich denke das Du im Bericht nach der Auswertung einige rote Fehler haben wirst. Dort wird dann auch irgendwo sicherlich beschrieben sein, dass es mit Zugriffsproblemen E/A Fehler Probleme gibt.
Viel Glück
Ich denke das mit sehr hoher Wahrscheinlichkeit die Konfiguration des iSCSI nicht richtig ist. Bei der Fehlermeldung die Du beschreibst sieht es für mich so aus, als wenn beide Hosts gleichzeitig auf die NAS zugreifen. Das darf natürlich in einem Dateisystem egal welcher Art nicht passieren. Es muss immer ein Hosts die primären Lese und Schreibrechte haben.Über ihn der primäre Host verwaltet die Lesung schreibe recht. Nur so kann ein Cluster auch funktionieren.
Schau mal im Festplattenmanager nach, ob bei dem einen Host die Festplatte im Vollzugriff ist und auf dem anderen Hosts als "reserviert" gekennzeichnet ist.So muss es auf jeden Fall sein Wenn Du von beiden Systemen gleichzeitig auf das NAS Laufwerk zugreifen kannst, stimmt mit der Konfiguration was nicht.Und dann musst Du genau hier ansetzen. Ich würde auf alle Fälle die VMs mal Weg sichern und dann über den FailOver Clustermanager mal den Cluster überprüfen lassen. Ich denke das Du im Bericht nach der Auswertung einige rote Fehler haben wirst. Dort wird dann auch irgendwo sicherlich beschrieben sein, dass es mit Zugriffsproblemen E/A Fehler Probleme gibt.
Viel Glück
Hallo,
das passt schon, ist als Cluster Shared Volume angelegt und hat ja davor völlig problemlos funktioniert.
Ich habe mich auch an den Support von QNAP gewendet, dieser hat zurückgeschrieben, dass das ein Problem der Version 4.1 sei. Witzig (oder eben auch nicht), da dass das eigentlich die Highlights dieser Version sein sollten. Als Empfehlung kam vom Support lediglich, dass man auf die Nutzung von iSCSI verzichten soll und das erst in der Version 4.2 behoben wird die frühestens 2015 (dann wohl eher, 2016!!!!!) erscheinen wird.
Zwischenzeitlich ist die Version 4.1.2 erschienen. Im Changelog steht auch drin, dass zwei Bugs bzgl. der iSCSI-Performance bei hoher IO-Last beseitigt wurden, allerdings sind die Probleme geblieben!
Also was QNAP da zur Zeit abzieht ist echt traurig! Bekannte Probleme sollten doch eigentlich sofort beseitigt werden und nicht irgendwann. Schade eigentlich, bisher war ich von den Geräten echt begeistert!
das passt schon, ist als Cluster Shared Volume angelegt und hat ja davor völlig problemlos funktioniert.
Ich habe mich auch an den Support von QNAP gewendet, dieser hat zurückgeschrieben, dass das ein Problem der Version 4.1 sei. Witzig (oder eben auch nicht), da dass das eigentlich die Highlights dieser Version sein sollten. Als Empfehlung kam vom Support lediglich, dass man auf die Nutzung von iSCSI verzichten soll und das erst in der Version 4.2 behoben wird die frühestens 2015 (dann wohl eher, 2016!!!!!) erscheinen wird.
Zwischenzeitlich ist die Version 4.1.2 erschienen. Im Changelog steht auch drin, dass zwei Bugs bzgl. der iSCSI-Performance bei hoher IO-Last beseitigt wurden, allerdings sind die Probleme geblieben!
Also was QNAP da zur Zeit abzieht ist echt traurig! Bekannte Probleme sollten doch eigentlich sofort beseitigt werden und nicht irgendwann. Schade eigentlich, bisher war ich von den Geräten echt begeistert!
Mittlerweile habe ich auch bei anderen Kunden ähnliche Probleme mit der QNAP. Auffällig ist das die Komplettabstürze der QNAP meistens bei Schreibvorgängen passieren. Die QNAP startet dann neu und alles dann wieder o. k. Ich habe mittlerweile fast keine iSCSI Laufwerke mehr. Da ich die QNAP überwiegend nur für die Datensicherung verwende habe ich die Laufwerke per SMB angebunden. Das gibt zwar auch zwischenzeitlich den einen oder anderen Absturz aber der Server findet viel schneller wieder seinen Sicherungspfad bzw. sein UNC Pfad wieder. Den Gegensatz zu einem iSCSI Laufwerk ist hier die Verbindung wesentlich schneller wieder hergestellt. Dabei allen von mir eingesetzten QNAP identische Vorkommnisse sind, führe ich das auch auf einen Fehler in der Firmware zurück. Man kann nur hoffen, dass QNAP dieses Problem so schnell wie möglichst gelöst bekommt. Ich habe nur bei einem Kunden eine Cluster auf eine QNAP laufen. Aber seit dem Problemen, habe ich den Cluster kein update mehr verpasst und diese QNAP läuft stabil.