[Sammelthread] ZFS Stammtisch

@sun-man, wo denkst du könnte deiner Meinung nach das Problem liegen? Sicherlich braucht jeder Pool bzw. jedes Dataset etwas Speicher im System, sicherlich kommen auch weitere Prozesse hinzu. Weswegen mehrere Pools macht, kann von der Nutzung der Pools anghängig sein, dass hat gea schon gut beschrieben. Es macht keinen Sinn z.B. VMware VM's im gleichen Pool mit CIFS Shares zu legen. Während CIFS vielleicht noch gut mit RaidZ (asynchron) zurecht kommt, braucht VMware durch synchrone Schreiboperationen einen Mirrored Pool ggf. mit SSD ZIL Unterstützung.

Insgesamt ist die Frage, wie viel IO du überhaupt durch den Rechner bekommst. Ich denke bei so 5 - 8GB/s ist derzeit auf nahezu jedem System Schluss. Da stellt sich dann auch nicht mehr die Frage, ob noch mehr Pools oder noch mehr Platten etwas bringen. Muss da immer an die Firma denken die mit N beginnt und die ich nicht mag. Die schaffen es durch extremes Marketing jedem Kunden alte Hardware zu verkaufen und dafür utopische Preise zu verlangen. Das Ergebnis sind dann Systeme, die nicht mal schneller als ein gutes SOHO Raid laufen.

---------- Post added at 07:30 ---------- Previous post was at 07:29 ----------

@gea, nutzt du Nexenta?
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Könnte ich ein Danke verteilen würde es gerade gedrückt :)

Datensicherheit und Handlebarkeit sind durchaus ein markantes Thema dabei. Wenn wir, beispielweise für eine Datenbank, auf unseren Storagesystemen redos in SSD Pools legen (20TB pro System) und dann noch langsamen SAS-14+2 aus einem anderen Storagepool derselben Maschine müssen wir erstmal trennen und das geht bei ZFS nur auf Poolbasis. Also wir können nicht einen Pool bauen und dort sagen "das liegt auf LUN1 und das auf LUN2" Wir würden Storageseitig nochmal vermischen. Dazu kommt auch das unserer Dateisysteme durchaus wachsen. Habe ich jetzt einen 15TB Pools mit div. Mounts oder passiven Partitionen und will vergrößern hab ich IMHO unter Solaris nicht sooooooo die irren möglichkeiten. Ich kann weitere Luns dazulegen und so immer weiter machen - oder ich lege eine größere LUN rein und tauschen alte 200GB Lun gegen die 400GB LUN. Das dauert aber empfindlich lange IMHO.

Wir wachsen rein, das sind im Moment alles so ein paar Punkte die man bedenken muss. LUNs sind und werden mind 4x8gb FC angeschlossen. Aktuell läuft das alles unter Sol10+MPXIO+Metsets hervorragend und ist gut steuer- und handlebar.


@sun-man, wo denkst du könnte deiner Meinung nach das Problem liegen? Sicherlich braucht jeder Pool bzw. jedes Dataset etwas Speicher im System, sicherlich kommen auch weitere Prozesse hinzu. Weswegen mehrere Pools macht, kann von der Nutzung der Pools anghängig sein, dass hat gea schon gut beschrieben. Es macht keinen Sinn z.B. VMware VM's im gleichen Pool mit CIFS Shares zu legen. Während CIFS vielleicht noch gut mit RaidZ (asynchron) zurecht kommt, braucht VMware durch synchrone Schreiboperationen einen Mirrored Pool ggf. mit SSD ZIL Unterstützung.

Insgesamt ist die Frage, wie viel IO du überhaupt durch den Rechner bekommst. Ich denke bei so 5 - 8GB/s ist derzeit auf nahezu jedem System Schluss. Da stellt sich dann auch nicht mehr die Frage, ob noch mehr Pools oder noch mehr Platten etwas bringen. Muss da immer an die Firma denken die mit N beginnt und die ich nicht mag. Die schaffen es durch extremes Marketing jedem Kunden alte Hardware zu verkaufen und dafür utopische Preise zu verlangen. Das Ergebnis sind dann Systeme, die nicht mal schneller als ein gutes SOHO Raid laufen.


Ich informiere mich erstmal nur. Ich bin nicht dafür verantwortlich. Also im Grunde ein paar (nicht so gute) ZFS Testerfahrungen und Interesse. Kann auch nicht sp schlecht sein die Junsg der anderen Abteilung mal zu helfen :)
Aktuell nutzen wir Metasets mit Softpartitions und das funktioniert absolut hervorrangend. Problem: Mehr als 32 (eher 31) Metasets kann eine Installation nicht. Wir verwalten Datenbanken up to 20TB mit gerne mal 40 oder 60 Mountpunkten div. passiver Partitionen.
Baue ich jetzt 20 oder 30 ZFS Pools mit jeweils einer LUNs müssen die ja irgendwie verwaltet werden - hierfür kenne ich ZFS zu wenig. Constantin Ginzales hat mir auch geantwortet und sieht keine wirkliche Begrenzung der ZPool-Menge, zumindest scheint es keine Vorgaben zu geben.
 
Zuletzt bearbeitet:
Ich bin mir jetzt nicht ganz sicher, ob ich das Problem verstanden habe bzw auf welches Solaris sich die Erfahrungswerte beziehen.

Unter einem aktuellen Solaris11 (bzw. den freien Forks OI und OmniOS) geht iSCSI mit Comstar so:

- Man hat einen Datenpool
- Darauf lassen sich beliebig Logical Units anlegen (als Volume, File oder RAW disk)
- Es werden dann Targets und Target/Host groups definiert

- Nach anmelden eines Targets (max 256) erhält man Zugriff auf die Logical Units, die einen View auf die Targetgroup haben (Das sind die nutzbaren LUNs). Ein Target kann also mehrere Platten/LUNs enthalten.

Soll die LUN größer werden, so läßt sich das ganz einfach erreichen, indem die Logical Unit größer gemacht wird. Der Client sieht dann sofort die größere Partion. Bei Windows kann man dann ganz einfach im Plattenmanager die Partition vergrößern.

z.B. Optionen in napp-it

lu.png



@SchaubFD
Ich habe noch vier Lizenzen NexentaStor2,
bin aber komplett auf die freien Versionen (erst OI, jetzt OmniOS) umgestiegen
 
Hallo,

- Nach anmelden eines Targets (max 256) erhält man Zugriff auf die Logical Units, die einen View auf die Targetgroup haben (Das sind die nutzbaren LUNs). Ein Target kann also mehrere Platten/LUNs enthalten.

Sind diese Limits irgendwo dokumentiert?

1 Nic -> 4096 IP Aliase (insg. 4096)
1 IP Alias -> 1 target portal group (insg. 4096)
1 target portal group -> 1 target (insg. 4096)
1 target -> 1 targetgroup (insg. 4096)
1 targetgroup -> 1 view (insg. 4096) mit 1 lu (insg. 4096)

wird dann wohl nicht gehen? Wo würde das Limit liegen bei dem 1 zu 1 ... Mapping?
 
Ich informiere mich erstmal nur. Ich bin nicht dafür verantwortlich. Also im Grunde ein paar (nicht so gute) ZFS Testerfahrungen und Interesse. Kann auch nicht sp schlecht sein die Junsg der anderen Abteilung mal zu helfen :)
Aktuell nutzen wir Metasets mit Softpartitions und das funktioniert absolut hervorrangend. Problem: Mehr als 32 (eher 31) Metasets kann eine Installation nicht. Wir verwalten Datenbanken up to 20TB mit gerne mal 40 oder 60 Mountpunkten div. passiver Partitionen.
Baue ich jetzt 20 oder 30 ZFS Pools mit jeweils einer LUNs müssen die ja irgendwie verwaltet werden - hierfür kenne ich ZFS zu wenig. Constantin Ginzales hat mir auch geantwortet und sieht keine wirkliche Begrenzung der ZPool-Menge, zumindest scheint es keine Vorgaben zu geben.

Hallo,

ich habe längst nicht mit so großen Umgebungen zu tun, aber ich lege grundsätzlich nur 2 Pools an: 1x IO-optimiert (Mirrors) und 1x kapazitätsoptimiert (raidXz) und regele den Rest über die Dateisysteme. Das hat neben dem schon genannten auch den Vorteil, dass die Pools aufgrund der dadurch tendenziell hohen Spindelanzahl bzw. vdev-Anzahl eine ausgezeichnete "Schwupdizität" besitzen. Du wirst also mit 20-30 20TB-Datenbanken auf einem striped-mirror-Pool mit 100 bis 200 vdevs und deren in Summe extrem hohen IOPS sehr gut fahren.
 
Derzeit suche ich nach einem Linux was sich über ZFS auch booten lässt. Solaris und dessen Ableger unterstützen bei mir USB3 garnicht. Auch Audio/Video ist hier schlecht/garnicht unterstützt.
Welcher USB-Controller? Bei meinem Asmedia klappt das. Allerdings hab ich Solaris auf nen Stick installiert (Sandisk Cruzer Extreme), und muss den immer am gleichen Port einstecken, sonst Reboot-Loop ab kurz nach der GRUB-Auswahl.
Audio/Video scheint mir auf nem Solaris im typischen Solaris-Einsatzgebiet eher...nunja, zweitrangig in der Entwicklung :fresse:

Ein ZIL kann man spiegeln. Dann ist der extrem seltene Fall eines Absturzes mit gleichzeitigem Defekt des ZIL möglich ohne Daten zu verlieren. Ansonst bringt Spiegeln keine weiteren Vorteile.
Mir ist Solaris letzte Woche mal stehen geblieben. Keine Videoausgabe, Numlock-LED ohne Reaktion, SSH tot, Pings ohne Antwort. Aber, und da kam der :stupid: auf, der SMB war zwar auch unerreichbar, aber NFS lief weiterhin. Nach ner halben Stunde hab ich die Mühle dann resettet, Start dann als wär nie was gewesen.
 
Hallo Gea,

dank nappit habe ich es sogar als iSCSI-Neuling hinbekommen, einem Windowsserver ein paar LUNs unterzujubeln.
Gibt es eine gute Seite, wo man mal das Zusammenspiel von LUN, Target, Targetgroup und View und deren Abhängigkeiten nachlesen kann? Bisher habe ich immer nur Infos gefunden, mache das so und so, aber nie warum. Ich fühle mich da in frühe Jahre mit Linux LVM zurückversetzt ;-)
Da ich für meine Test einen mit Daten gefüllten Pool verwendet habe, habe ich sicherheitshalber ersteinmal nur Logical Units als File anlgelegt. Was passiert mit dem Pool und vorhandenen Daten bei LUNs als Volume oder RAW disk? Was bedeutet "LU could be created on a volume, a snapshot, or a clone." Bedeutet das, ich kann aus einem Snapshot/Clone einer bestehenden LUN ein neues LUN mit Daten gefüllt erzeugen?
Hat es perfomancemäßig oder administrativ Vorteile, den VMs ihre Daten-Platten nicht als vdmk auf einem NFS-Share, sondern als iSCSI-Device zur Verfügung zu stellen?
Oder dem ESXi den Datastore nicht über NFS sondern über iSCSI? Hier wohl eher nicht. Oder?!

Gruß millenniumpilot
 
Die beste Doku zu iSCSI und Comstar gibts wohl bei Oracle aber meist in Englisch. http://docs.oracle.com/cd/E37930_01/ Es ist aber relativ einfach.

iSCSI bedeutet Festplatten übers Netzwerk bereitzustellen. Dazu brauche ich einen Server der das leistet. Auf diesem Server muss sich etwas befinden, das sich wie eine (virtuelle) Festplatte verhält. Bei Solaris sind das die Logical Units (LU), also echte unbenutzte Festplatten (RAW), Dateien oder Volumes (ZFS Dateien die wie Platten angesprochen werden). Um diese Logical Units im Netz bereitzustellen, braucht es eine Target (englisch für Ziel)-Software.

Auf Seite des Arbeitsplatzes, der eine Festplatte übers Netz ansprechen möchte, braucht man eine Initiator (Ich möchte das gerne haben) - Software, die dem Arbeitsplatz dieses Target quasi als lokale Platte unterjubelt. Die nennt sich dann LUN (logical unit number). Bei Solaris kann ein Target mehrere LUNs (quasi virtuelle Festplatten übers Netz) beinhalten.

Der Rest wie target-groups, host-groups und views dient nur dazu, das im Unternehmensumfeld mit vielen Arbeitsplätzen und Logical Units zu verwalten oder zu strukturieren oder den Zugriff einzuschränken.

Bei ESXi ist iSCSI möglich, NFS aber viel einfacher im Handling und meist ähnlich schnell.
 
Zuletzt bearbeitet:
ZFS läuft nun auch scheinbar unter Sabayon "Daily" Build. Auch die Statistik stimmt wieder und bisher noch keine defekten Pools. Ich hoffe es bleibt so.
 

1 Jahr nach Auftreten mit dem neuen ESXi Update FINALLY behoben.

Solaris 11 virtual machines with VMXNET3 network adapter might write messages to the /var/adm/messages. The error message similar to the following might be displayed in the system log:
vmxnet3s: [ID 654879 kern.notice] vmxnet3s:1: getcapab(0x200000) -> no
This issue is repeated in every 30 seconds.
This issue is resolved in this release.
 
Ich werde hier gerade irre....

Folgende Config implentiere ich gerade:

HP NL40 mit 8GB ECC Ram
Nexenta 3.1.5 auf einer 30GB SSD
RaidZ2 mit 4x1,5TB sowie 128GB-Log-SSD und 128-Cache-SSD

das ganze ist über 4Gbit-FC an meine beiden ESXi-Träger angebunden. das RaidZ2 wird in Form von 2 LUNs zur Verfügung gestellt.

Aber irgendwie fährt das Nexenta scheinbar mit angezogener Handbremse ?!? Wenn ich von Lun1 nach Lun2 VMs per StorageVMotion verschiebe
habe ich transferraten von 1-15MB/s laut der Nexenta-Web-Oberfläche - das passt auch zur Realtität - 40GB-Transfers (STandardgröße der VMs) dauern Stunden je VM.....
Komprimierung&Dedub war mal an mal aus macht aber keinen echten Unterschied im Ergebnis.

Hat irgendwer eine Idee war zur Hölle das Problem ist ?!?

Im Anhang drei Screens welche ich vor einer Minute gemacht habe - aktiver Task: StorageVMotion einer VM von LUN1 auf LUN2...

Greetz Menig

Screen_Platten.JPG Screen_Status.JPG Screen_Config_RaidZ2.jpg
 
Zuletzt bearbeitet:
Dedup ist der Leistungskiller schlechthin. Mach nochmal Dedup aus (hast du auch mal einen Reboot gemacht danach testweise?), 8 GB Ram sind viel zu wenig, da hilft auch kein L2ARC, dann sollte das eigentlich richtig laufen. Was für Festplatten hast du verbaut? 512 Byte HDDs oder ältere AF 4096 Byte HDDs die noch nicht die Sektoren richtig melden, das der ZFS Pool auch korrekt auf ashift=12 läuft.
 
Zuletzt bearbeitet:
Hm... war die Faustregel nicht 1gb ram je Tb storage ? Sind ja nur 3tb drin ;-)

ohne dedup habe ich statt der 5-15mb so 8-20mb/s, dedup ist erst seit heute Mittag zum testen aktiviert ;-)

Hdds sind im screen gelistet, muss ich erst googeln bzgl. der sektorgrösse.


Gesendet von meinem HTC Sensation Z710e mit der Hardwareluxx App
 
oki, dedup ist nun aus - und bleibt auf bis ich den RAM auf 16GB erhöht habe - das sollte dann ja reichen um eine der beiden LUNs wieder mit dedub zu betreiben (die auf welcher Standardmässig die VMs liegen, die zweite als Datengrab macht für dedub eh wenig Sinn).

Aber: Wie in Post 3404 geschrieben bestand das Problem ja bereits vor dem aktivieren von dedup und besteht auch jetzt weiterhin. Irgendwelche Ideen warum ?
Was mir bei einem nackten Filetransfer aufgefallen ist: Copyjop startet mit einem "Burst" von ca. 60MB/s (immer noch wenig finde ich) und ist dann nach einigen Sekunden bei 0Byte/s angekommen. Geht dann wieder kurz hoch... dann wieder auf Null usw.
Irgendein Cache der da voll läuft ?!? Aber warum ? selbst die Cacheplatte hat ja 128GB und und die Testdateien mit denen ich arbeite max 1 GB Filesize.... Und die SSD ist eine Samsung 840 Pro - die sollte mehr schaffen - genauso wie das 4GB FC mehr als 60MB Burst schaffen sollte....

Irgendjemand hierfür noch eine Idee ?

Gruß Menig
 
oki, dedup ist nun aus - und bleibt auf bis ich den RAM auf 16GB erhöht habe - das sollte dann ja reichen um eine der beiden LUNs wieder mit dedub zu betreiben (die auf welcher Standardmässig die VMs liegen, die zweite als Datengrab macht für dedub eh wenig Sinn).

Aber: Wie in Post 3404 geschrieben bestand das Problem ja bereits vor dem aktivieren von dedup und besteht auch jetzt weiterhin. Irgendwelche Ideen warum ?
Was mir bei einem nackten Filetransfer aufgefallen ist: Copyjop startet mit einem "Burst" von ca. 60MB/s (immer noch wenig finde ich) und ist dann nach einigen Sekunden bei 0Byte/s angekommen. Geht dann wieder kurz hoch... dann wieder auf Null usw.
Irgendein Cache der da voll läuft ?!? Aber warum ? selbst die Cacheplatte hat ja 128GB und und die Testdateien mit denen ich arbeite max 1 GB Filesize.... Und die SSD ist eine Samsung 840 Pro - die sollte mehr schaffen - genauso wie das 4GB FC mehr als 60MB Burst schaffen sollte....

Irgendjemand hierfür noch eine Idee ?

Gruß Menig

Du hast anscheinend die Funktion der Caches total falsch verstanden, das ZIL (bzw. bei dir das slog) soll nur Schreibvorgänge, die in 5 Sekundenintervallen verstreut ablaufen, bündeln. Das bedeutet natürlich, dass deine SSD viel viel viel zu groß ist, da tut's bei 8GB RAM und 4GB FC auch eine 40GB SSD (4GB/s * 5s * 2), wobei das auch schon die absolute Obergrenze ist. Bei deinen Schreibversuchen nutzt dir aber das ZIL überhaupt nichts, da du Daten am Streifen schreibst. Die L2ARC-SSD nutzt dir nur etwas bei häufig wiederkehrenden Leseoperationen der gleichen Daten, braucht aber im ARC, also im RAM, auch zusätzlich noch Speicher, den du nicht hast.
Zu guter Letzt, sei noch gesagt, dass deine Schreibversuche mit 1 GB Daten wahrscheinlich sowieso komplett im RAM gecachet werden, und deshalb kein aussagekräftiges Resultat zu erwarten ist, du solltest also besser ein Vielfaches der RAM-Größe verwenden.
 
ZIL ist kein Schreibcache. Es wird im Normalfall nie aus dem ZIL gelesen.
 
@Menig

du verwendest vier steinalte (Erscheinungsjahr 2008) ECOGreen Platten im RAIDZ2 und erwartest Performance? Nicht dein Ernst oder? Da brauchst du dir über 16GB oder ZIL erstmal keine Sorgen zu machen, denn diese Platten werden nie das bringen, was du dir erhoffst. Diese Platten liefern keine 70 I/O pro Sekunde (siehe Benchmarks: Zugriffszeit und I/O-Performance - Vernünftige Riesen: Festplatten mit 1500 GB), das passt gut zu deinen Statistiken. Übrigens: ein RAIDZx Pool skaliert NICHT mit der Zahl der Spindeln! Wenn du diese Platten trotzdem weiterverwenden willst, dann mache wenigstens einen Stripe über zwei Mirrors draus, dann hast du doppelte Schreib und vierfache Leseperformance bei gleicher Kapazität.

cu
 
Hallo,

@TCM @ron2105
also: ich habe nicht gesagt das der ZIL volläuft - dessen Funktionalität ist mir schon klar - Trotzdem Danke für den Hinweis das der ZIL kein Schreibcache ist, vielleicht hilft das ja wem anders weiter ;)
Aufgrund des aprubten 60MB/s auf 0MB/s habe ich mich gefragt ob "irgendein" Cache da volläuft - sprich ob es noch irgein Cache gibt der mir nicht klar ist.

Diese SSDs gibt es halt erst ab 128GB Größe, das diese derzeit oversized ist ist mir bewußt, aber dafür ist die 840 Pro halt sehr lese/schreibstark und da ich das System kurzfristig auf 8Gbit-FC aufrüsten werden und
halt auch noch zwei weitere ESXi-Träger zur Testumgebung dazukommen werden im Sommer ist das halt quasi schon meine stille Reserve ;)

@Ludwinator
also, erstmal Danke für deine Antwort: Mein Ernst ist da ich auch von einer 2008er Platte nicht die Performance einer Barracuda erwarte - aber sicherlich mehr als 3MB/s erwarte.... ;)
Diese (wie ich Dir absolut recht gebe) langsamen Festplatten sind nur deshalb im Einsatz weil das NL40 vorher als reines Datengrab gedient hat - sprich Stromeffizienz und "Ruhe" waren wichtiger als "Leistung".
Die HDDs werden demnächst nach und nach durch "aktuelle leistungsfähige" HDDs ersetzt ;)

Die Empfehlung bzgl. 2xMirror im Stripe war auch meine ursprüngliche Überlegung - allerdings möchte ich das bei zwei HDD defekten die Daten erhalten bleiben - trifft es zwei HDDs im selben Mirror ist alles Futsch -daher nicht
passend für mich. Sobald ich im Mai oder Juni mir eine Backup-Spiegelung der 3TB auf einen externen 3TB-Mirror aktiv habe werde ich dieser Empfehlung allerdings folgen ;)

Nochmal zurück zu meiner Frage:
mir ist klar ich habe derzeit noch langsame Platten, mir ist klar das Aufgrund des RaidZ2 keine Festplattenleistungsskalierung vorliegt. Aber auch eine EcoGreen sollte doch mehr als 3-10 MB/s schaffen ?

Mich macht halt wie gesagt stutzig da die (auch bei 40GB-Copy-Job) die Schreibleistung je HDD 2-3MB/s beträgt. Das müßte doch deutlich mehr sein ?

Ich suche nach wie vor meinen Gedankenfehler :)
 
Dein Gedankenfehler ist, sequentielles Lesen mit Random zu verwechseln. Wenn du innerhalb des selben Pools Daten von einer LUN zur anderen schaufelst, müssen die Platten ständig neu positionieren, wenn dann dein Pool auch noch fragmentiert ist (ist er zwangsläufig) und Snapshots hat, dann hast du fast 100% Random I/O und da sind 2-3MB/s durchaus normal.
Noch etwas: du hattest dedup an und dann wieder aus, das bedeutet aber nicht automatisch, dass du keine deduplizierten Blöcke mehr hast, die schleppt das System so lange mit sich rum, bis die gelöscht werden. Du kannst dir das mit zpool status -D poolname ansehen.
Wenn du Angst hast vor einem double disk error hast und kein Platzproblem dann mach einen 3-Wege Mirror.
Ansonsten würde ich dir wärmstens ans Herz legen, die Kompression zu aktivieren, das spart nicht nur Platz, das bringt auch Performance. Optimal wäre LZ4, aber es sieht nicht so aus als hättest du die aktuelle Version von ZFS.
Ach ja und ein Output von
echo "::arc" |pfexec mdb -k
wäre auch nicht schlecht.
 
@Ludwinator
- recht hast Du (bzgl. Random I/O)
-Das mit dem Dedup ist war mir klar, bin seite Heute morgen dabei die LUNs frei zu schaufeln um den Pool dann entsprechend neu zu erstellen.
- Komprimierung bringt Performance ? Sollte das nicht Performance kosten ? Von wegen Dekompromieren ?
- Dreifachspiegelung wird bzgl. verfügbaren SATA-Slots leider etwas eng, deshalb ja das RaidZ2 hier wollte ich auf im Mai auf 6 HDDs a 3TB switchen und von den 18TB RAW dann 12 nutzen - bei einem Dreifachmirror wären nur 6TB verfügbar, 10 brauche ich aber ;(
- ich nutze ZFS28 unter Nexenta-Store 3.1.5, aber da ich die RaidZ eh neu aufbaue nutze ich das um Heute Abend dann auf 4.0 zu switchen.

Hm... ok, Post3405 hat mich da auf etwas aufmerksam gemacht.... ich habe ja noch diese "Fake-Platten" die ja 512 byte melden obwohl diese mit 4k laufen.....
Der Link auf digitaldl funktioniert leider nicht mehr... kann mir wer sagen wie ich sicherstelle das die HDDs ein 4k-Alignment bekommen (unter Nexenta) ?

Gruß Menig
 
Ich würde das Pool 'Sync' ausschalten und dann probieren.

Allerdings stellt sich mir die Frage:
Warum wird bei Vmotion das VM-Image real verschoben?
Jeder ESXi-Host hat ein FC-HBA und importiert eine LUN vom Storage. Beide LUN sind auf dem selben Storage. Jede importierte LUN wird vom ESXi Host letztlich wie eine normale lokale Festplatte behandelt.
Dein ESXi-Host hat also jetzt die Möglichkeit die VMs auf dieser 'nicht lokalen Platte' abzulegen.

Heisst der Vorgang wirklich 'Vmotion' oder vielleicht doch 'Storage Vmotion' ?

Wie auch immer das Verschieben der VM ist erstmal ein Vorgang der zwischen den ESXi-Hosts erledigt wird, das die Daten letztlich wieder auf dem selben Rechner landen davon wissen die ja nichts.
Vielleicht ist ja auch noch dein Klient(controllcenter für ESXI - weiss nicht wie das Ding heisst) in den Datenstrom eingebunden?

nexenta <-> fc <-> esxi <-> ethernet <-> dein KLient <-> ethernet <-> esxi <-> ethernet <-> fc <-> nexenta
über mehrere OSI Schichten auf 4(oder 5) Rechner
und diverser Datenverkehr für die Programm Logik kommt noch hinzu

Gibt es da kein 'multi pathing' um das reale Verschieben zu vermeiden?
 
@Startplus
natürlich geht es um eine StorageVMotion - das war wie Du richtig erkannt hast von mir etwas "unsauber" formuliert ;)
 
@Ludwinator
sind 4k-HDDs die 512Byte melden - habs gerade in den technischen Daten gegoogled.
Kompression schmeisse ich dann gleich wieder an - wobei ich 2x 1,5GHz jetzt nicht so schwach finde ^^ (ja, ich weiß, da geht deutlich mehr *gg*)
 
mein "Pool" heißt "NL40RaidZ2"
"zdb | egrep 'ashift| NL40RaidZ2'" bzw. "zdb | egrep ashift| NL40RaidZ2"
bringt allerdings keine meldung (als root direkt auf der Konsole ausgeführt)

"zdb -e NL40RaidZ2 | grep ashift" bringt mir als Ergebnis allerdings "ashift=9".... also nix 12 ;)


ABER: es sind 512Byte/Sektor.... also alles richtig... es war 3Gbit/1,5Gbit die man Jumpern konnte.... Dumm wenn einem die Erinnerung streiche spielt... :)
http://www.seagate.com/files/www-co...umentation/samsung/tech-specs/eco_greenf2.pdf

Naja, wie gesagt, räume die beiden LUNs jetzt leer... werde diese dann als gestrippte Mirror erneut einrichten und fertig..... dann darf halt nur eine HDD im Zweifelsfall kaputt gehen.

Greetz Menig
 
Zuletzt bearbeitet:
das Kommando oben kannst du genau so laufen lassen, es liefert dann einfach alle Pools ...

wie schaut denn der Output von echo "::arc" |pfexec mdb -k aus?
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh