Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!

vmk_invalid_metadata

Moderatoren: irix, Dayworker

Member
Beiträge: 10
Registriert: 13.04.2015, 10:04

vmk_invalid_metadata

Beitragvon nqnh » 10.01.2017, 09:19

Moin moin,

ich habe zur Zeit folgendes Problem in meiner VM-Umgebung.
Vorab einige Hintergrundinformationen:

Zur Umgebung:
- 3x ESXi 5.5 Hosts
- 1x VCSA 6.0
- 1x QNAP TVS 871U-RP
- 1x DLINK Gbit Switch
- ~90 VMs

Zur Konfiguration:

- Alle Hosts und die QNAP werden über das vCenter gemanaged
- QNAP = 8x 7,2k 4TB im RAID5, über iSCSI an die Umgebung angebunden + 2x 128 SSD Cache im Raid1
- VMFS5.60 Dateiformat

Zum Umstand:
- der Datastore war ursprünglich über NFS angebunden
- nach einiger Zeit wurde die Performance der Umgebung extrem schlecht
- alle VMs wurden temporär auf eine DataDomain verschoben
- die QNAP wurde auf die aktuellste Firmware geupdated, neu konfiguriert und eine LUN und ein iSCSI Target erstellt
- alle VMs wurden zurückverschoben
- Performance war um einiges besser
- Ein Host wurde ausgetauscht
- iSCSI Software Adapter Konfiguration sind auf allen Hosts gleich
- die anderen zwei Hosts haben die QNAP weiterhin über iSCSI eingebunden

Zum Vorfall:
- Aus dem RAID5 Verbund ist eine HDD ausgefallen
- die HDD wurde aus der QNAP entfernt
- das RAID hat sich automatisch die Spare HDD genommen und das RAID neu aufgebaut
- die Spare HDD hatte auch einen Blockfehler
- die Fehlermeldung ist nicht mehr aufgetreten

Zum Problem:
- Der neue Host erkennt die QNAP als Device, jedoch nicht den Datastore (device und path usw werden alle jedoch korrekt angezeigt)
- folgende Umstände treten alle nach dem oben genannten Vorfall auf
- einige VMs (vorwiegend Windows 2012 R2 und Windows 7) melden Fehler beim Ausführen von Anwendungen (corrupted DLLs usw.)
- VMs lassen sich nicht mehr verschieben und zT nicht starten
- folgende Fehlermeldungen werden im vCenter bei Startvorgängen bzw. Storagemovevorgängen angezeigt:

1.) Beim Start einer VM
Failed to power on VM
Could not power on VM : msg.vmk.status.VMK_INVALID_METADATA.
Current swap file size is 0 KB
Failed to extend swap file from 0 KB to ... KB

2.) Beim Verschieben einer VM
A specified parameter was not correct.
name too long or wrong filetype

3.) Beim Konsolidieren einer VM
An error occured while consolidating disks: 5 (Input/output error).

4.) chckdsk von Windows VMs
Bleiben bei 5% hängen

Meine Vermutung
- Ist es möglich, dass das VMFS Volume bzw dessen Metadaten korrupt ist bzw. sind und somit die oben genannten Fehler auftreten?
- Kann es sein, dass ein VMFS Volume durch ein kurzzeitig fehlerhaftes RAID beschädigt wird?
- Kann es sein, dass die QNAP durch den Rebuild des RAIDs und das permanente Beschreiben (12 TB innerhalb von zwei Wochen) das VMFS Volume
in irgendeiner Art beeinträchtigt hat?
- Gibt es sowas wie ein CHKDSK für das VMFS Volume? Ich habe gelesen, dass man durch VOMA das Volume analysieren/überprüfen lassen kann.
- Jedoch beinhaltet VOMA keine Repairfunktion o.ä.

Ich hoffe mir kann hier weitergeholfen werden.
Besten Dank im Vorraus!

Grüße

NQNH

King of the Hill
Beiträge: 13560
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Re: vmk_invalid_metadata

Beitragvon Dayworker » 10.01.2017, 13:43

Wenn die Spare-HDD ebenfalls einen Blockfehler hatte, wurde jetzt zwar unverständlicherweise die Raidkonsistenz wieder hergestellt, aber der Blockfehler hat deine Lage eher verschlimmert. In meinen Augen hat QNAP absoluten Bockmist gebaut und hätte die Spare-HDD nach dem Blockfehler überhaupt nicht mehr anfassen dürfen, sondern das Raid im degraded Zustand belassen müssen. Durch das fehlerhafte Rebuild sind Datenstrukturen jedenfalls unwiderruflich beschädigt worden und das läßt sich jetzt auch nicht mehr ändern. Sicher soweit noch möglich alle wichtigen Daten in allen VMs und bau das Storage komplett neu auf. Falls du wichtige Daten nicht sichern kannst oder allgemein Hilfe brauchst, kontaktiere unseren VMFS-Guru "continuum" aka Ulli über Skype unter "sanbarrow". Vielleicht kann er noch etwas retten.

In jedem Fall sage ich mal Hut ab vor dem Mut, bei 40TB noch auf Raid5 zu setzen. Allerdings frage ich mich gerade, wie du in das ein "QNAP TVS 871U-RP" mit 8 Bays deine 10 Platten unterbringen willst? Selbst wenn du mit "nur" 6 Datenplatten plus Parity plus Spare und in Summe 24TB operieren solltest, würde ich dafür kein Raid5 mehr einsetzen. Beim Raid5-Rebuild entsteht allein aufgrund des internen Aufbaus eines Raid5 durch das Read-Modify-Write auch ohne zusätzliche, externe IOPS soviel Last auf den Platten, daß während des Rebuild gerne eine weitere Platte ausfällt und dann bist du sowieso auf ein fehlerfreies, möglichst aktuelles Backup angewiesen. Bei den Datenmengen wäre mindestens ein Raid6 die bessere Wahl gewesen.

Member
Beiträge: 10
Registriert: 13.04.2015, 10:04

Re: vmk_invalid_metadata

Beitragvon nqnh » 10.01.2017, 14:52

Moin,

vorab vielen Dank für die ausführliche Antwort!
Es handelt sich tatsächlich um ein Raid5 mit 8x HDDs, eine davon ist die SpareHDD.
Die QNAP hat nur 10 Slots, von denen 2 Slots von SSDs als Cache konfiguriert sind.

Ich habe bereits ein zweites Storages konfiguriert und in die Umgebung eingebunden und fange an VMs zu "retten".

Gibt es zusätzlich zum Raid6 weitere Empfehlungen ,die die "Stabilität" des Storagesystems erhöhen könnten?

Sollte man vielleicht doch vom iSCSI Protokoll zurück auf NFS wechseln, um die vmfs-Problematik zu umgehen?

Gruß

NQNH

Experte
Beiträge: 1337
Registriert: 25.04.2009, 11:17
Wohnort: Thüringen

Re: vmk_invalid_metadata

Beitragvon Supi » 10.01.2017, 15:10

nqnh hat geschrieben:.

Gibt es zusätzlich zum Raid6 weitere Empfehlungen ,die die "Stabilität" des Storagesystems erhöhen könnten?

Sollte man vielleicht doch vom iSCSI Protokoll zurück auf NFS wechseln, um die vmfs-Problematik zu umgehen?

Gruß

NQNH

Moin,

da ich aktuell auch in der neues Storage-Planung bin, mein Tipp:

Bei 3 Host und 90VMs würde ich ich über eine richtige SAN und nicht ein NAS nachdenken. Ich habe hier 2 Dell R610 mit 20VM's, für die VM's eine MD3220i ISCSI.
Supi hat geschrieben:Zu der NAS gesagt: die QNAP kann die SSD's nur für Read Cache nutzen, das bringt dir bei deinem 7 Platten Raid-5 nix beim schreiben.

Edit:
Da lag ich falsch, die SSD werden doch auch beim schreiben genutzt.
https://www.qnap.com/de-de/tutorial/con ... ne&cid=172

Der Ausfall/Fehler wird sicher durch die QNAP Software hervorgerufen sein. Aber auch so, ein Rebuild von 4TB SATA Platten dauert.
Software 4.2 ist auf der QNAP?
http://www.vmware.com/resources/compati ... tOrder=Asc

Aber noch mal, was machen die 90VM's, wenn ich die nur einem NAS anvertraue?
Dann lieber ne Oepn-E Variante:
https://www.storitback.de/angebot/angeb ... e_dss.html
oder besser noch richtige SAN mit Dual Controller ala EMC VNXe1600, Dell MD3, SCv2020, HP 1040 /2040, Fujitsu Eternus... um mal nur ein Paaar der Einstiegs-SAN zu nennen.

Member
Beiträge: 10
Registriert: 13.04.2015, 10:04

Re: vmk_invalid_metadata

Beitragvon nqnh » 10.01.2017, 16:17

Moin,

auch Ihnen vielen Dank für Ihre Rückmeldung und Ihre Hardwareempfehlungen.
Bei der Virtualisierungsumgebung handelt es sich um eine Umgebung in der Änderungen, Tests und Updates an VMs getestet werden sollen,
die aus dem Backup der Produktivumgebung wiederhergestellt wurden.

Daher ist hier das Budget stark begrenzt, da es sich "nur" um eine Testumgebung handelt.
Zu Beginn war tatsächlich eine Eternus DX60 im Einsatz, die mittlerweile anderweitig eingesetzt wird.
Diese wurde quasi von der QNAP abgelöst.

Den Einsatz einer SAN würde natürlich Sinn ergeben, jedoch ist das Budget wie gesagt stark begrenzt,
Zudem ist die QNAP an sich auch "VMWare-zertifiziert" und die VMs liefen vor dem Vorfall auch performant.

Die aktuellste 4.2.2 von Mitte Dezember ist auf der QNAP vorhanden.

Gruß

NQNH

Experte
Beiträge: 1337
Registriert: 25.04.2009, 11:17
Wohnort: Thüringen

Re: vmk_invalid_metadata

Beitragvon Supi » 10.01.2017, 18:17

Hallo noch mal und danke für das mehr an Details.

..dann ist die QNAP nachvollziehbar bzgl. des Budget.


Vorab, ggf. habe ich ja das wesentliche des Problems überlesen: Treten die Probleme denn nur auf dem neuen Host auf?

....

Zur HW selbst noch folgendes:
Wird denn auch wirklich der ganze Platz gebraucht? Ein Wechsel auf Raid-10 über alle 8 Platten würde performance-seitig Sinn machen.
http://www.storagereview.com/qnap_tvs871_nas_review

Grundsätzlich dürfte hier ISCSI die bessere Wahl sein, da NFS ja immer Thin ist und bei 90 VMs sicher auch viel Fragmentierung auf dem EXT4 der QNAP auftritt.
Aber das ganze Raid ist eine große LUN a ca. 22TB? (sprich nur 1 ISCSI Target)?
Das wäre alleine schon aus Performancegründen schlecht.
Wiele VMKernel Ports sind denn für ISCSI angelegt? bzw. über wieviele Ports ist das NAS angebunden?

https://www.qnap.com/en/tutorial/con_sh ... one&cid=64
  • Create each iSCSI target with only one LUN
  • Choose “instant allocation” when creating an iSCSI LUN for higher read/write performance in an I/O intensive environment
  • For normal datastore, limit the number of VMs per datastore to 10 > Stichwort SCSI Reservation

Auch würde ich dem Channelbonding des QNAPs nicht trauen, das macht der ESXi schon selber wenn es mehrere Pfade gibt. Dazu wäre wohl fixed/prefered Path und nicht Round Robin zu wählen beim ISCSI target.

Vorschlag1 : Mehrere ISCSI LUNs anlegen und damit die Ausfall-gefahr verteilen.

Vorschlag2: 2-3 ISCSI LUNS anlegen, wo die aktiven VM's liegen, die IOPS brauchen. Der Rest schlummert auf einer NFS Freigabe. Kann die Kiste ja parallel. Vorteil damit: Wenn die VM's "Thin" angelegt sind, werden diese beim dort hin verschieben auf die Nutzkapazität verkleinert, ggf. vorher noch ein sdelete nötig.

Member
Beiträge: 10
Registriert: 13.04.2015, 10:04

Re: vmk_invalid_metadata

Beitragvon nqnh » 10.01.2017, 19:24

Moin,

klar doch, ich habe hier für die zeitnahen Antworten zu danken!

die Probleme tauchen auf den alten Hosts auf.
Der neue Host erkennt die QNAP zwar als Device, kann jedoch den Datastore nicht einbinden.
(Nach einem Reboot des Hosts sieht man die QNAP unter Datastore, grau und kursiv und verschwindet nach einigen Sekunden, nach mehreren Refreshs und Scans taucht die nicht mehr auf). Da vermute ich einfach, dass der neue Host den Datastore nicht richtig auslesen kann, während die alten Hosts die benötigten Daten bereits gecached haben.

Aktuell wird der verfügbare Speicherplatz nicht komplett benötigt.
Es ist jedoch nicht sicher wie sehr sich diese Testumgebung mittelfristig vergrößern wird.
Ein RAID10 wird meines Erachtens auch in einem Best Practise von QNAP empfohlen,
jedoch hätte die Umgebung "nur" noch 3 TB Puffer, welche man mit 2-3 Datenbankservern schnell ausreizen könnte.
Da würde ich schon eher zum RAID6 tendieren wollen.

Genau, aktuell wird das ganze RAID über eine große LUN bereitgestellt.
Die Kapazität entspricht etwa 22 TB.
Für iSCSI ist pro Host ein VMKernel Port angelegt.
Die NAS ist auch über ein Port angebunden, überlege aber die NAS über zwei Ports an den GBit Switch anzubinden.

Vielen Dank für die hilfreichen Vorschläge, die werde ich auf jedenfall bei der Neukonfiguration der QNAP berücksichtigen.

Gruß

NQNH

Experte
Beiträge: 1337
Registriert: 25.04.2009, 11:17
Wohnort: Thüringen

Re: vmk_invalid_metadata

Beitragvon Supi » 10.01.2017, 20:51

Hallo noch mal,

nun, wenn 2-3 DB's schon 3TB voll hauen... dann sollte theoretisch noch ein wenig Geld da sein für ein weiteres NAS. Mal von der Performance einer solchen großen DB auf einem solchem NAS abgesehen.
Also defintiv lieber Raid-10 und noch ein billiges 4-Disk NAS dazu mit 4 Platten im Raid-5 als "Ablage", auf die du per NFS oder auch ISCSI zugreifst.
Es werden ja nicht alle 90Vm's zu jeder Zeit gebraucht, oder?
http://geizhals.de/lenovoemc-storcenter ... at&hloc=de

Hat auch 2 LAN Ports, 1x könnte man dediziert für ISCSI nutzen.
Alternativen gibts natürlich auch von Qnap: http://geizhals.de/qnap-turbo-station-t ... at&hloc=de
Nur nen 100€ teurer.
Habe selbst seit 2 Jahren den größeren Bruder als NAS laufen, PX6-300D. 1x lan NW CIFS/NFS, 1xlan ISCSI. Ausgesprochen Problemlos.


Ich fasse dann deine Worte noch mal zusammen:
Jeder Host nur mit 1 Leitung zum Switch.
Die NAS nur mit einem Kabel am Switch. (die hat doch 4 Lan Ports?)

Also geht der Traffic von 3 Host über eine 1Gbit Leitung, sprich max 100MB/s seq. Datenrate für alle.
Alles sehr ungünstig.

Idealweise solltest du pro Host wenigstens 2 NW-Leitungen für ISCSI definieren, ebenso bei der NAS. Gerne 3 Kabel vom NAS zum Switch, 1x Management im normalen Lan Segment und 2x für ISCSI in einem anderen IP Bereich.
Noch besser: die 3 Host und das NAS teilen sich für den ISCSI Traffic einen separaten Switch. Kann der Dlink auch Flow Control?

http://rickardnobel.se/esxi-and-flow-control/

Tipps zur Config:
viewtopic.php?t=30043 Besser wie hier im Thread für die ISCSI Ports verteilen
iSCSI01 mit 10.55.2.x (255.255.255.0)
iSCSI02 mit 10.56.2.x (255.255.255.0) (IP's als Beispiel und nicht als Vorgabe zu sehen)

https://www.viktorious.nl/2013/11/20/qnap-vsphere55/

Member
Beiträge: 10
Registriert: 13.04.2015, 10:04

Re: vmk_invalid_metadata

Beitragvon nqnh » 11.01.2017, 09:42

Moin,

sagen wir ein Großteil der Maschinen bzw. 70 VMs werden zeitgleich betrieben, da zB getrennte Umgebungen mit eigenem fdc, exchange, dbs usw betrieben werden.

Jeder Host hat mehrere Leitungen zum Switch, aber in Hinsicht auf das Storagenetz ist jeder Host nur mit einem Kabel an dem Switch angebunden, korrekt. Die Hosts haben aber alle genug Kapazitäten, um das Storagenetz doppelt an den Switch anzubinden.

Dazu werde ich wohl einen zweiten Gbit Switch in das Konstrukt einbauen, worüber NUR storage-Netzwerk läuft.
D.h. am Ende soll die NAS zweifach an dem Storageswitch angeschlossen sein und die Hosts jeweils auch zweifach.
Management-Traffic läuft über den bereits vorhanden Switch.

Ich habe noch eine Frage zur Aussage bzw. zu Ihrem Vorschlag "Mehrere iSCSI LUNs anlegen, um die Ausfallgefahr zu verteilen":
Wenn durch ein RAID-Rebuild die große LUN beschädigt werden konnte (die ja auf dem kompletten RAID verteilt ist),
wie sieht das denn mit mehreren LUNs aus? Denn auch wenn man mehrere LUNs hat, bedienen die sich ja alle aus dem selben Storagepool, sprich, ein Fehler im RAID würde ja dann auch alle LUNs betreffen oder nicht? Oder habe ich hier einen Verständnisfehler.

Gruß

NQNH

Experte
Beiträge: 1337
Registriert: 25.04.2009, 11:17
Wohnort: Thüringen

Re: vmk_invalid_metadata

Beitragvon Supi » 11.01.2017, 15:52

nqnh hat geschrieben:
Dazu werde ich wohl einen zweiten Gbit Switch in das Konstrukt einbauen, worüber NUR storage-Netzwerk läuft.
D.h. am Ende soll die NAS zweifach an dem Storageswitch angeschlossen sein und die Hosts jeweils auch zweifach.
Management-Traffic läuft über den bereits vorhanden Switch.
NQNH

Gute Idee. Hier aber gleich nen etwas besseren Switch nehmen. (HP1620/1820 ?)
nqnh hat geschrieben:Ich habe noch eine Frage zur Aussage bzw. zu .......sprich ein Fehler im RAID würde ja dann auch alle LUNs betreffen oder nicht?
NQNH

Hier im Forum darf gerne gedutzt werden. Nur deinem/Ihren Namen kennen wir noch nicht.
Zum Raid: Richtig, ein Raid-5 defekt ( 2 Platten gleichzeitiger Ausfall), alle LUNS auf dem NAS betroffen.
Der Hinweis war nur, dass so die Last verteilt wird und nicht alle Host mit einem Target reden. Das erhöht die SCSI Reservations.

So richtig 100% war ja noch nicht klar ob der "eigentliche" Fehler durch das QNAP kommt oder ggf. ja doch durch das VMFS. Je nach Lust/Laune und Support könntest du einen Supportfall beim VMWARE eröffnen oder halt nicht.
Wenn der Fehler durch das VMFS kommt (ggf. bedingt durch die vielen parallelen VM's und 3 Host, die nur auf eine Lun zugegriffen haben), würde das aufteilen auf mehere LUNS helfen, das der Fehler beim nächsten Mal zumindest nur 1 LUN betreffen würde. (so wirklich noch mal auftretend)
Damit wären die VM's auf den anderne Luns noch funktionabel. Das als ein Hintergedanke bzgl. der Aufteilung. Dazu dann halt auch der mögliche Performancevorteil durch bessere Last-Verteilung.

King of the Hill
Beiträge: 13560
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Re: vmk_invalid_metadata

Beitragvon Dayworker » 11.01.2017, 17:26

Ich glaube nicht, daß es etwas mit dem VMFS bzw nur indirekt damit zu tun hat. Der Fehler war schon gewesen, daß ein Blockfehler auf dem Spare trotzdem zu einem vollständigen Rebuild und keiner Ablehnung des Spares bzw Abbruch des Rebuild geführt hat. Irgendwo meine ich in einem Supportforum zu einem mir entfallenen NAS-Anbieter und ihrem Produkt gelesen zu haben, daß der Anbieter nicht weiß, was er da tut und im Grunde auch nur im Nebel stochert.


Mein Vorschlag wäre daher sämtliche Logs, Screenshots usw zu sichern und sie dem QNAP-Support trotzdem vor die Füsse zu kippen. Weil wenn eine auch noch für VMware zertifizierte NAS-Box nicht mal ein popeliges Raid5-Rebuild gebacken bekommt, läßt mich das ganz stark an deren Eignung zweifeln. Dann könnte man genauso gut auch einen Rechner hinstellen oder eine Appliance nehmen, ein Raid5 per SW abbilden und den Speicherplatz per iSCSI oder NFS an die ESXi-Farm zurückgeben. Oder verstehen NAS-Anbieter ein Raid darin, bei Plattenausfall alle Daten zu sichern, defekten Datenträger austauschen, Raid neu aufzusetzen und Backup einspielen?
Das VMware-Zertifikat gibt im Grunde auch kaum Sicherheit und ist wie das Feature-Set der VMware-Workstation zu verstehen. Ohne das vom Hersteller zu bezahlende Pickerl verkauft sich das Produkt entweder einfach nicht oder der Hersteller will die Abwanderung des Kunden zu einem Fremdprodukt verhindern. Das erklärt dann auch das idiotische Feature-Set der WS oder einiger NAS-Anbieter mit ihrem ganzen bunten Klimbim wie Email, HTTP, Torrent usw. Vor dem Hintergrund wäre jeder Kunde besser beraten, sich seine Produkte ohne irgendwelchen Firlefanz und rein für die angedachte Aufgabe auszusuchen.

Guru
Beiträge: 3081
Registriert: 27.12.2004, 22:17

Re: vmk_invalid_metadata

Beitragvon rprengel » 12.01.2017, 08:11

Dayworker hat geschrieben:Das VMware-Zertifikat gibt im Grunde auch kaum Sicherheit und ist wie das Feature-Set der VMware-Workstation zu verstehen. Ohne das vom Hersteller zu bezahlende Pickerl verkauft sich das Produkt entweder einfach nicht oder der Hersteller will die Abwanderung des Kunden zu einem Fremdprodukt verhindern. Das erklärt dann auch das idiotische Feature-Set der WS oder einiger NAS-Anbieter mit ihrem ganzen bunten Klimbim wie Email, HTTP, Torrent usw. Vor dem Hintergrund wäre jeder Kunde besser beraten, sich seine Produkte ohne irgendwelchen Firlefanz und rein für die angedachte Aufgabe auszusuchen.
#

Schön formuliert.
Nebenbei:
wir hatten eine Qnap 859 die sich mehrfach das Raid zerhauen hat und nicht in der Lage war es neu aufzubauen.
Neben offensichtlicher Schwächen der Software war auch noch ein Designfeler im Spiel da die Qnap nur 2 GM Ram hatte und bei 8 * 4 TB Platten die notwenigen Tools abschmierten wenn man nicht einen zusätzlichen USB Stick als swap per Hand eingebunden hat.
Seit der Nummer ist Qnap bei mir für wichtige Umgebungen durch, zumal der Support defacto nicht existent war.

Gruss

Member
Beiträge: 10
Registriert: 13.04.2015, 10:04

Re: vmk_invalid_metadata

Beitragvon nqnh » 12.01.2017, 09:50

Moin,

alles klar, dann fange ich mal mit Du an :lol: .
Nochmals Danke für die vielen ausführlichen Antworten.

Der QNAP Support weicht leider bei sämtlichen Fragen in Bezug auf VMWare aus und verweist auf den VMWareSupport..
Aber, dass die LUN bei einem RAID Rebuild beschädigt werden kann "kann mal vorkommen", wobei ich dann wieder den Sinn hinter einem RAID hinterfrage..

Letzendlich würde ich sagen, dass die Ursache der ganzen Problematik der Ausfall des RAIDs bzw. die mehr oder weniger defekte Spareplatte gewesen ist. Denn das war die einzige "Änderung am System".

Ich habe bereits angefangen die noch funktionierenden VMs zu Verschieben und werde die QNAP / RAID / LUN komplett neukonfigurieren und auch die Netzwerkanbindung des Storages und der Hosts überarbeiten.

Für das RAID entnehme ich aus euren Beiträgen, dass bei der Größe von einem RAID5 abgeraten und eher auf ein RAID6 oder RAID10 gesetzt wird, wobei zweiteres bei mir auf Grund der geringeren Gesamtkapazität nicht in Frage kommen würde.
Eine zweite NAS, welches über NFS als "Park"storage angebunden wird, kommt auch nicht in Frage, da das Budget begrenzt ist.

Wenn ich die NAS quasi in 2x RAID5 aufteilen würde (ohne Spare, um die Gesamtkapazität beizubehalten),
wäre eine LUN a ~11 TB pro RAID-Gruppe immernoch zu groß? oder lieber 2x RAID5 (oder 1x RAID6) und dann zwei oder vier LUNs erstellen?

Laut der WebUi ist die QNAP während des ganzen Einsatzes weder CPU technisch oder RAM technisch an ihre Grenzen gekommen.

Gruß

King of the Hill
Beiträge: 13560
Registriert: 01.10.2008, 12:54
Wohnort: laut USV-Log am Ende der Welt...

Re: vmk_invalid_metadata

Beitragvon Dayworker » 12.01.2017, 16:46

Das QNAP ausweicht und auf den VMware-Support verweist, wäre für mich ein Grund genau die Laufzeiten aller Platten inklu Spare (Plattenmechanik altert auch ohne Zugriffe) zu checken und dann im direkten Kontakt zu QNAP denen sämtliches Material in Kopie vor die Füsse zu kippen. QNAP weiß sehr genau, was die Zertifizierung beinhaltet. Sie besagt im Umkehrschluß für VMware nur, daß VMware das Produkt in Betrieb genommen hatte und dabei keine groben Fehler festgestellt wurden. Für den Supportfall jedoch ist die Zertifizierung für VMware doch wieder sehr wichtig, da VMware unzertifizierte HW vom Support ausschließt. Nur mit Zertifikat erhält man als Nutzer überhaupt die Möglichkeit, daß sich beide Hersteller damit überhaupt beschäftigen müssen.


Der Platzverlust durch Verschnitt bei Raid10 ist mit 50% natürlich gewaltig, aber die Fragen, die du dir hier vielleicht stellen solltest, sind zwei andere.
Wieviel Zeitstunden und Manpower mußte jetzt durch diesen völlig unverständlichen Fehler aufgewendet werden, um wieder ein vollfunktionales System zu erhalten? Wieviel kostet ein Backup-NAS?

Selbst wenn dein NAS die Aufteilung in 2x Raid5 mit 4 Platten unterstützen sollte, sind 4 Platten für ein Raid5 keine optimale Plattenanzahl und mit noch weiteren Performanceverlusten beim Schreiben verbunden. Optimal nutzt man die Performance eines Raid5 mit 2, 4 oder 8 Datenplatten plus 1 Parityplatte aus und damit ergeben sich 3, 5 oder 9 Raidmitglieder. Für ein Raid6 dagegen braucht man wie beim Raid10 mindestens 4 Platten.

Bezüglich der Auslastung von CPU und RAM der QNAP würde ich sagen, daß das normal ist und mit dem internen Aufbau eines Raid5 zusammenhängt. Ein limitierender Faktor sind deine Datenträger (Spindeln), die aufgrund ihrer geringen IOPS immer zu langsam sind (SSDs bieten mehr IOPS, kämpfen aber auch mit der Schreiblatenz, bis Daten wirklich in den Flash geschrieben wurden) und der andere Faktor ist dein nicht optimal ausgestattetes Raid5 mit 8 Spindeln (6 Daten, 1 Parity, 1 Spare).



Du kannst natürlich auch eins machen und läßt das Rebuild samt Spare gleich ganz sein. Mit zweimal Raid5 aus 3 und 5 Platten nutzt du dein NAS sowohl steckplatz- als auch performancetechnisch optimal aus und im Fehlerfall zieht man ein Backup, tauscht den fehlerhaften Datenträger aus, legt das degraded Raid wieder an und spielt das Backup zurück. Um ein Backup kommt man ja gerade wegen Raid nicht herum, es soll ja nur die Funktion auch bei Fehlern sicherstellen und die Reaktionszeit zur Fehlerbehebung verlängern. Das ich sowas nicht mal privat machen würde, muß ich ja nicht weiter betonen...

Member
Beiträge: 10
Registriert: 13.04.2015, 10:04

Re: vmk_invalid_metadata

Beitragvon nqnh » 19.01.2017, 13:35

Moin,

die QNAP wird nun doch mit einem RAID10 betrieben.
Einfach aus den genannten Ausfallsicherheits- und Performanceaspekten.
Die Umgebung läuft soweit auch schnell und stabil.
Zudem wird diskutiert, ob für die QNAP eine Erweiterung angeschafft werden soll, eben um Kapazitäten für Backups zu schaffen.

An dieser Stelle nochmal besten Dank für die vielen ausführlichen Antworten / Ratschläge / Vorschläge.

Für mich kann dieses Thema geschlossen werden.

Gruß

nqnh


Zurück zu „vSphere 5.5 / ESXi 5.5“

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 5 Gäste