Beiträge von HaugeO

Hallo Zusammen,

habe gestern den QVPN Service Version 1.0.17213 mit OpenVPN in Betrieb genommen und bin schnell auf das Problem gestoßen, dass ich nicht den gesamten Netzwerkverkehr über das Remotegateway leiten möchte, d.h. nur den Traffic ins Firmennetz über den VPN -Tunnel leiten möchte.

Die Lösung des Problems brachte ein neuer Eintrag in die Konfigurationsdatei (openvpn.ovpn) des OpenVPN-Clients :

route 192.168.5.0 255.255.255.0

d.h. alles ins Class-C-Netz 192.168.5.x geht über den Tunnel, der Rest über das lokale Default-Gateway des Clients.

Hilft vielleicht dem Einen oder Anderen etwas Suche im Internet zu ersparen...

Grüsse
Oli

Hallo Zusammen,

der QVPN Service ist installiert und funktioniert auch zuverlässig (TS-669L, auf TS-1635 lässt es sich nicht installieren, Ticket an QNAP ist offen und wartet auf Beantwortung durch Entwicklungsteam).

Leider gelingt bei den Privilegieneinstellungen nicht das Hinzufügen von Domänenbenutzern, hier werden im Auswahldialog nur kryptische Zeichen dargestellt (egal mit welchem Browser Firefox, IE, Chrome).

Hat einer eine Idee wie dies zu lösen ist?

Danke und Gruß
Oli

Ich habe auch ein Ticket beim QNAP-Support aufgemacht. Vielleicht können die ja eine belastbare Aussage machen...

Von den eigentlichen Daten habe ich Sicherungen. Allerdings liegen auf dem NAS auch Veeam-Backups unserer Server/Clients-PC, welche ich ungern verlieren möchte.

Die Volumes liegen auf Unterschiedlichen RAIDS!

Ursache für die Dateisystemfehler:

TS-1635: Absturz des NAS bei Aufbau der Medienbibliothek, damals war nur noch hartes Ausschalten möglich (siehe andere Beiträge von mir), seit dem selbst mit mehreren Stunden direktem Support von QNAP DataVol1 nie wieder 100% sauber, deshalb ja jetzt auch der Wunsch/Notwendigkeit das System neu aufzusetzen, allerdings ohne die Daten auf DataVol2 und DataVol3 zu verlieren.

TS-669L: Einbau eines 1 GB Hauptspeicherbausteins aus einem TS-451 erwies sich als nicht kompatibel (obwohl auch original QNAP-RAM), NAS ging zwar ohne Fehlermeldung/Boot Beep an , allerdings kein Zugriff möglich, musste deshalb ebenfalls hard ausgeschaltet werden.

Anscheinend ist das System-Dateisystem da sehr empfindlich, auch wenn eigentlich zum Zeitpunkt des Ausschaltens kein Festplattenzugriff zu erkennen war. Deshalb ja jetzt der Wunsch das Systemvolumen relativ klein zu machen um dann bei einer notwendigen Dateisystemüberprüfung nicht wieder Tage warten zu müssen.

Und was hat mein geplantes Vorgehen mit mit Basteln zu tun?

Anyway: Bitte Frage beantworten ob die Daten auf den anderen Volumen nach Neuaufsetzen des Systemvolumens erhalten bleiben - Danke.

Hallo Zusammen,

regelmäßig nach einem Neustart der NAS (sowohl beim TS-1635 als auch beim TS-669L) kommt die Meldung "file system not clean" mit der Empfehlung das Dateisystem zu überprüfen. Das kann aber, gerade bei großen Volumens furchtbar lange dauern.
Da (fast) immer nur das SystemVolumen mit einer Größe von 10,5 TB betroffen und ein Verkleinern ja nicht möglich ist habe ich folgenden Plan (alle Daten sind redundant vorhanden):

* Kopieren aller noch benötigten Daten von DataVol1 (System) auf DataVol2 (ebenfalls 10 TB)

* Sicherung der Konfiguration des NAS

* Löschen DataVol1 mit Systemdaten

* Reboot NAS

* Neuanlage Volumen System (auch Volumennamen nun System und nicht mehr DataVol1) mit 500 GB Größe (dort sollen dann alle QNAP-Systemdateien, Apps etc. liegen)

* Neuanlage DataVol1 mit "nur" noch 10 TB Größe

* Rücksicherung Konfiguration NAS (ggf. Kopieren der Daten aus Sicherung)

Fragen:

* Sind nach Neuaufsetzen des System, der Systempartition die Daten auf den anderen (alten) Volumen noch vorhanden und kann darauf zugegriffen werden (DataVol2 10 TB, DataVol3 1 TB)?

* reihenfolge richtig?

* Wie sonst wäre mein Vorhaben zu lösen?

Vielen Dank und Euch allen ein schönes Wochenende
Oli

P.S. Antworten werden heute noch gerne angenommen, man könnte dann das WE für Kopiervorgänge etc. nutzen...

Hallo Jörg,

auch wenn Dein Post schon etwas älter ist: Konntet Ihr das Problem lösen, wenn ja wie?

Danke und Gruß
Oli

geht leider auch nicht. Die testweise Installation einer anderen App (Connect to Cloud Drive) klappt jedoch.

QVPN war früher mal installiert und wieder deinstalliert worden, vielleicht hängt noch irgendwo Datenmüll rum den man manuell löschen muss. Weiß einer wo ich danach suchen müsste?

Danke und Gruß

Hallo Zusammen,

die Installation des QVPN Service schlägt immer mit folgender Meldung fehl:

Fehler 12.09.2017 12:45:53 System 127.0.0.1 localhost QVPN 1.0.17213 installation failed. Data file error.

Auch Abbruch der Installation und Versuch auf ein anderes Volume zu installieren klappt nicht.

Hat einer von Euch eine Idee?

Auch ja: TS-1635 mit FW 4.3.3.02999 (Fehler war aber auch schon bei der vorherigen FW aufgetreten)

Danke und Gruß
Oli

Hallo Zusammen,

der Titel sagt eigentlich alles. Kann einer das beobachtete Verhalten bestätigen oder bin ich zu blöd die alten (aktiven) Aufträge zu finden?

Danke und Gruß
Oli

Empfehlung vom Teamleiter Support: NAS neu aufsetzen, Zugriff aus dem ESX via iSCSI, Empfehlung vom Ticketbearbeiter: Das produktive NAS nur mit Freigaben verwenden, keine zusätzlichen Apps benutzen.

In diesem Sinne: Hoch die Hände, Wochenende!

@Barry Ricoh Danke, hört sich genau wie bei mir an, hänge das mal an mein Ticket ran...

Nachtrag:

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

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

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 .

=> 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

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

Hatte ähnliche Probleme:
- Cache ausschalten und testen

Und noch was: hast Du zusätzlichen Speicher (ggf. kein original QNAP) verbaut?

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

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

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

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.

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

Zitat

Sehr geehrte Damen und Herren,

reproduzierbare kompletter Systemstillstand vermutlich aufgrund/während Aufbau den Medienbibliothek (diesmal Musik/MP3), System konnte selbst durch langes Drücken des Powerknopfes teilweise nicht mehr sauber heruntergefahren sondern musste das Stromkabel gezogen werden. Nach Neustart kam mehrfach die Meldung, dass DataVol1 bereinigt und DataVol2 wiederhergestellt werden muss. Gestern Abend dann nach einiger Zeit (wenige Stunden) wieder kompletter Stillstand des Systems. Musste heute durch langes Drücken des Powerknopfes heruntergefahren werden. Nach Neustart nun DataVol1 wieder bereit (allerdings Meldung "Dateisystem prüfen), DataVol2 hat allerdings Staus/Fehler (Nicht aktiv), Wiederherstellung schlägt mit unbekanntem Fehler fehl.

Bitte dringend und kurzfristig um Hilfe da für Produktivbetrieb benötigte ESX-Daten auf dem Volume liegen!

Alles anzeigen

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"...