RAID5 Status Fehler (Nicht aktiv), Wiederherstellung bringt "unbekannten Fehler"

  • Hallo Zusammen,


    leider habe ich wieder einmal massive Probleme mit dem TS-1635, diesmal auf dem DataVol2, mit frischen (ca. 1 Monat) alten Seagate-Festplatten, welche alle mit Status "gut" angezeigt werden.

    Firmware Version:* 4.3.3.0262


    Festplatten Modell und Kapazität: Seagate ST4000VN008-2DR166 (SATA)
    RAID-Konfiguration: RAID-5


    Hier einmal der Inhalt des Tickets, welches ich heute an den QNAP-Support geschrieben habe:

    Vielleicht kann einer Euch helfen?


    Vielen Dank und Grüße
    Oli


    P.S. noch eine Anmerkung: Bereits im Vorfeld ist das NAS bei defekt einer (!) Festplatte im RAID komplett stehen geblieben. Das kann doch nicht Sinn und Zeck eines RAIDs sein. Solches Verhalten kenne ich bei keinem anderen mir bekannten Servern/Betriebssystemen (ESX, Hyper-V, Windows native). Dadurch ist das Vertrauen iin die QNAP-NAS natürlich massiv gesunken...


    P.S. II Anmerkung: Bei der Einrichtung von DataVol2 konnte kein Speicherpool sonder "nur" ein statisches Volume (datVol2) angelegt werden. Beim Speicherpool kamm es auch immer zu einem unbekannten Fehler. Das NAS meldet am Display auch jetzt "Fehler Speicherpool"...

    Einmal editiert, zuletzt von HaugeO ()

  • Ich habe das gleiche Problem. RAID inaktiv, Wiederherstellung unbekannter Fehler.


    Vorher war aber einer vom Qnap Support drauf und hat da was gemacht.


    Allerdings habe ich noch keine Antwort erhalten, damit er dies wieder behebt. (Ist fast eine Woche her, meine Nachricht an den Support)


    Aber vielleicht kann uns ja auch einer von euch helfen.

  • gestern hat sich der Support bei uns via TeamViewer aufgeschaltet und nach ca 1,5 h war das RAID wieder aktiv und der Neuaufbau des RAID begann. Ich konnte zwischenzeitlich auf die Freigaben zugreifen. Nach dem Rebuild des Volumens (hat ca. 8 h für 1 x 4 GB Festplatte gedauert, der Rebuild einer defekten HD in unserem Dell R720 Server war nach ca. 30 Minuten durch!) sollte ich auf Empfehlung des Support auf jeden Fall das Dateisystem der Datenträger prüfen. Dieser Job wurde ohne Fehler ausgeführt. Da der VMWareserver (ESX 6.5) die Freigabe nicht mehr mounten konnte habe ich heute morgen erst das NAS über die Weboberfläche/Menüpunkt Neustart neu gestartet. Bis das NAS wieder erreichbar war vergingen ca. 20 - 30 Minuten. Beim permanenten Ping während des Neustarts war das NAS nach ca. 5 Minuten für 10 Pings da bevor es wieder einige Minuten gedauert hat bis es komplett wieder hochgefahren war


    Folgende Meldungen erschienen:


    => Warnung 31.07.2017 00:55:09 System 127.0.0.1 localhost The system was not shut down properly last time.
    => Fehler 02.08.2017 09:06:40 System 127.0.0.1 localhost RAID Group 3 is inactive.
    => die Speichernutzung stieg auf ca. 80% (von 4 GB), Prozessorlast 70%, kein Zugriff auf Freigaben möglich!
    => Ticket an Support (ein neues, und das alte wieder aktiviert), bis jetzt keine Reaktion des Supports, das urspüngliche Ticket hat aber wieder den Status "Critical"!
    => kurze Zeit später hing auch die Weboberfläche
    => NAS musste wieder über den Powerknopf aus- und wieder eingeschaltet werden, Zugriff vom ESX auf DataVol1 ok, DataVol2 inaktiv, keine Chance zur Reaktivierung, zum Glück laufen die wichtigsten VMWare-Guests wieder
    => außer dem Zugriff via NFS vom ESX und via FileStation kein Zugriff auf die Freigaben möglich!


    All dies lässt mich zu dem Schluss kommen, dass die QNAP-NAS (oder ggf. auch nur das TS-1635) im produktiven Betrieb eigentlich nur als Backupmedium in Frage kommt. Bereits bei der Ersteinrichtung hatte ich massive Probleme das Teil ans rennen zu bekommen. Für die langsame Raidperformance war damals der von uns verbaute OEM-Speicher verantwortlich (siehe mein entsprechende Post), aber auch dort hat es unendlich lange gedauert bis die Lösung gefunden wurde.


    Ursache für die ganzen Probleme ist dabei (vermutlich) weniger die verbaute Hardware (in Kombination mit dem 10GB-Netzwerkadapter waren fantastische Übertragungsraten zu erzielen) als vielmehr das verbuggte Betriebsystem/Firmware.


    Bin mittlerweile richtig angefressen und enttäuscht, aber weiterhin für jeden Tipp/Empfehlung dankbar.



    Bis dann
    Oli

  • Bei mir ist es nach Firmware Update und Neustart schon mal soweit das er das RAID findet.


    Allerdings auch nach einem Filesystemcheck, die Meldung bringt QTS Volumen not found.


    Also noch kein Zugriff auf die Daten oder APP Aktualisierung bspw. Qnap Certificate möglich.


    Hab vom Support nen Befehl für das Volume bekommen denn ich noch probiere.


    So ganz Happy bin ich derzeit auch nicht über Qnap bzw. über meine Modelle.

  • seit heute ist keinerlei Zugriff über Windows-Rechner (diverse Windows-Server wie W2K8R2, W2K12R2, W2K16 sowie Windows-Clinets wie Win XP, Win 7, W10 Enterprise etc.) auf die Freigaben auf dem TS-1635 mehr möglich.
    Es gelingt lediglich über NFS-Share eines VMWare ESX 6.5 sowie über QStation.


    Jegliche Änderungen mit/ohne ACL, mit/ohne erweiterte Rechte ändert absolut überhaupt nichts, ein Vergleich mit den problemlos funktionierendem TS-669L oder TS-231P zeigt keine Unterschied!


    WTF?


    Vielleicht hat einer noch einer Idee, gute Nacht und bis demnächst...


    Oli

  • Bei mir hat der Support Befehl: mount /dev/md3 -t ext4 /share/MD0_DATA


    Dazu geführt das ich die QTS Cert APP uodaten konnte ohne QTS Volumen not found.


    Aber kein Zugriff auf die Daten des Volumen und nach nem Reboot war der Mount auch wieder weg.

  • Besteht ein Backup der Daten und der Einstellungen.
    In so verfahrenen Situationen lohnt immer ein Blick auf das komplette Neuaufsetzen.


    Grds. kann ich jedoch von unserer EC1279U-RP behapten, dass diese seit Jahren problemlos läuft.

  • Selbstverständlich haben wir ein komplettes Backup aller Daten u.a. auf einem zweiten QNAP im zweiten Brandabschnitt, zusätzlich auf einer externer USB-Platte und die wichtigsten Daten auch auf einem über RTRR verbundenen weiteren QNAP-NAS. Von den 20 TB Nutzdaten sind z.Z. ca. 8 TB belegt. Da kann man sich vorstellen wie lange die komplette Rücksicherung und die damit verbundene Downtime wichtiger Server sein wird, ginge so etwas nur über das Wochenende, wird aber als letzte Option nicht ausgeschlossen.



    Und übrigens: Immer noch keine Reaktion vom Support. Weiß einer ob man Premiumsupport als Kaufoption buchen kann. In dringenden Fällen muss man sofort Zugriff auf den Support haben und nicht mehrere Tage im Regen stehen...


    VG Oli

  • Hallo Zusammen,


    folgender Zwischenstatus (war ein paar Tage unterwegs): Habe Donnerstag morgens die kostenpflichtige Hotline vom Handy für 2,49 € je Minute angerufen (über unseren SipTrunk-Anbieter ist die 0900'er Nummer nicht möglich):
    * es gibt zur Zeit keine Möglichkeit die Bearbeitung des Tickets zu beschleunigen (auch nicht gegen einen monetären Ausgleich)
    * QNAP hat zur Zeit sehr viele Supportanfragen
    * zukünftig ist es geplant einen professionellen Support als Dienstleistung anzubieten, wann das ist konnte er nicht sagen
    * das es Probleme beim aktuellen FW-Release mit Freigaberechten gibt wurde ebenfalls nicht bestätigt.


    Am späten Nachmittag hat sich dann der ursprüngliche Supporter von QNAP doch noch gemeldet und laut meinem Kollegen die Sache mit den Fragerechten und dem RAID-Status wieder hochgezogen und einen weiteren Supporttermin via TeamViewer auf Freitag 10:00 Uhr vereinbart. Ich habe dann, soweit es in dem Zeitfenster möglich war, wichtige Daten herunterkopiert. Freitag dann der Supporttermin, bei diesem wurde dann ein System- und Volumecheck und angestoßen, der fast über das gesamte Wochenende lief. Während dieser Zeit kein Zugriff/Nutzung des NAS möglich.


    Heute dann eine erneute TeamViewersitzung mit dem Ergebniss, dass beide Datenspeicher wieder online sind (Dateisystem muss noch geprüft werden) und darauf zugegriffen werden kann. Allerdings wird bei DataVol1 eine Belegung von 99% angezeigt (von 10,88 TB Kapazität, belegt 99%, verfügbar 21,90 TB = kein Schreibfehler und leider auch kein Witz). Der Supporter konnte sich das nicht erklären, hat den Fall an die Entwicklungsabteilung weitergegeben und empfiehlt uns das NAS bis zur Klärung nicht einzusetzen!


    Auf meine Frage, wann den mit einer Antwort der Entwicklungsabteilung zu rechnen wäre:
    Das kann dauern, Tage, Wochen oder auch Monate, die würde sehr langsam reagieren...
    Der Supporter vermutet, dass es an der verbauten CPU Annapurna Labs Alpine AL514 liegen würde (der übrigens u.a. im Synology DiskStation DS2015xs verbaut wird. Er meinte, dass in den Bibliotheken des QTS oft der Prozessortyp abgefragt würde und empfiehlt deshalb Modelle mit einem Intel- oder AMD-Prozessor. . Lange Rede, wenig Sinn: Das Ticket wird jetzt auf sein Anraten eskaliert , bin mal gespannt wann der Vorgesetzte sich meldet.


    Fragen: Gibt es von QNAP ein Modell mit Intel- oder AMD-Prozessor, 16 Schächte, 2 x 10 GBit-Netzwerkanschlüssen, ggf. SSD-Cache (obwohl der ja wohl eh nichts bringt)?
    Wäre es dann möglich die Konfig vom TS-1635 zu sichern, die Platten in derselben Reihenfolge in das neue NAS (anderes Modell) zustecken, Konfig rücksichern, und alles würde wieder laufen?


    Danke und Gruß
    Oli


    P.S. Habe gerade einmal Dateisystem prüfen angestoßen => Ergebnis: DataVol1 entladen und kann nicht mehr geladen werden, auf dem Display steht: Speicherpool voll :X

  • TS-1685 oder RM TS-EC1680U, die spielen aber auch preislich in einer anderen Liga.
    Aus Erfahrung (meiner) kann ich sagen, dass die x86 (Intel+AMD) bisher am stabilsten laufen. Bei einem Kunden habe ich zwei TSX831U im Einsatz, die beide schon merkwürdige Verhaltensweisen an den Tag gelegt haben.

  • kleines Update: Ergebnis der Eskalation ist, dass der Chef des Ticketbearbeiters sich die Sache selber mal angesehen hat und nach wenigen Sekunden erst einmal die Überprüfung des Filesystems des DataVol1 mit e2fsck angestoßen hat.
    Die läuft nun schon seit ca. 15:15 Uhr und wird bei 11 TB sicherlich noch etwas dauern. Anschließend muss dann vermutlich DataVol2 mit ebenfalls 11 TB geprüft werden.


    Ich glaube, dass sie dasselbe bereits letzte Woche, während ich weg war, schon einmal gemacht hatten. So verschafft man sich jedenfalls erst einmal Luft um (im besten Fall) intern weiter nach dem Problem suchen zu können :handbuch: .


    => seit 1,5 Wochen kein Produktivbetrieb mit dem NAS möglich. Wenn das bei einem unserer Kunden passiert wäre hätten wir einen weniger...


    CU Oli

  • Ich will QNAP nicht in Schutz nehmen, aber klassischer SPOF einer system(Betriebs-?)kritischen Komponente...

  • Na ja, ganz so ist es nicht. Immerhin sind alle wichtigen Daten auf internen Speicher der ESXe, andere NAS kopiert worden und es kann wieder gearbeitet werden. Hätte ich aber gewusst, dass die Reaktion/Reparatur so lange dauert so hätte ich direkt eine Rücksicherung aus dem Backup gemacht. In der Zeit in der jetzt das Dateisystem überprüft wird (läuft immer noch) hätte man auch das System komplett neu aufsetzen können.


    Und wie bereits gesagt: Das ganze ist (anscheinend) ohne Hardwaredefekt passiert, das NAS ist (vermutlich) bei Nutzung der QNAP-eigenen Programme sowie im Vorfeld beim Ausfall einer (!) HD im RAID komplett stehen geblieben und musste ausgeschaltet werden.


    Alles in Allem reift in mir die Erkenntnis, dass man mit diesem QNAP-NAS nicht preiswert seine Serverspeicherkapazitäten (anstelle eines SAN, internen Platten) für produktive Umgebungen erweitern kann (obwohl genau das in der Werbung/Beschreibung suggeriert wird) und nur zur reinen Datensicherung ist es dann eigentlich doch zu teuer...


    Seit gestern läuft nun das Tool zum Prüfen des Dateisystem (e2fsck) mit 25% CPU-Last, seit 12 h ohne jegliche weitere Bildschirmausgabe.


    Hat einer von euch Erfahrung wie lange das bei einem 11 TB Datenvolume dauern kann bzw. wo man erkennen kann wie weit der Prozess fortgeschritten ist? Der Supporter sprach von bis zu mehreren Tagen mit ungewissen Ausgang. Ohne die saubere Beendigung kann der Support auch nicht weitermachen...


    Grüße
    Oli


    P.S: hab gerade noch mal ein paar SAS-HDs für den Dell-Server bestellt

  • Nachtrag:


    e2fsck läuft mit 25% CPU-Auslastung seit 26 h und keine einzige HD-Lampe blinkt. Normal?

  • Hört sich seltsam an, vielleicht kennt ja @dr_mike einen Befehl/Möglichkeit zu prüfen, ob sich da noch etwas tut.


    Die Werbung von QNAP (und auch einigen anderen) ist halt oft Marketinggeblubber :(
    Hilft Dir jetzt nicht wirklich, aber ich habe einige QNAP als Backupsysteme (SMB, AFP, iSCSI und RTRR) draußen bei Kunden relativ problemlos im Einsatz...wobei ich auch fast ausschließlich Intel-Systeme oder AMD-Systeme einsetze.

  • Hallo ich bin nicht sicher ob das hiermit zu tun hat oder nicht, da reicht wohl mein Englisch nicht für,
    aber habe das gerade im Plexforum gelesen.
    Ich kopiere den Text eines Plexentwicklers mal 1:1 hier rein.
    Dem ist beim Test der neuen PMS Version sein Qnap abgeschmiert.
    Falls es nichts damit zu tun bitte ignorieren.