[Sammelthread] ZFS Stammtisch

Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Das die "RAW performance" bei vier normalen 2TByte SATA HDDs im Raid10 mit 430MByte/sec lesend geschönt ist. ist dir aber schon bewusst?

Hallo bluesunset

Das kommt darauf an, was Du mit "geschönt" meinst.
Die genannten Performance-Werte für den dd-Test habe ich schon erwartet. Eine Platte, die standalone 150 GB/s seq. read liefert, sollte in der mirror-Konfiguration, in der von allen 4 Platten parallel gelesen werden kann, schon bei 400GB/s rauskommen. In diesem Sinne ist das Ergebnis nicht "geschönt".
Dass eine Praxis-Last ein anderes Profil hat und deutlich schlechtere raw performance liefert (z.B. 4k etc) ist mir bewusst. Allerdings habe ich unter Windows in der VM seq. read-Test (Crystal Disk Mark) verglichen mit dem dd-Test in OI. Dachte, dass ich dabei nicht "Äpfel mit Birnen" vergleiche (auch wenn die Filesize unterschiedlich sein kann).

Aber zurück zu meiner Fragestellung:
Ich versuche keine künstliche Benchmark-Orgie zu starten, sondern möchte verstehen, ob ich den vmxnet3-Treiber für die all-in-one-Lösung zum Laufen bekomme oder auf den E1000-Treiber wechseln muss.
In letzterem Fall möchte ich verstehen, ob meine Performance-Erwartungen (>1Gbit seq. Read & Write) unrealistisch sind, oder was ich ändern muss, um mein Setup zu optimieren.
Von einem ZFS-Spiegel mit 4 schnellen Platten erwarte ich bei seq. Lesen INNERHALB von ESXI sicherlich mehr als 100MB/s, auch wenn ich weiss, dass der Overhead durch Virtualisierung und NFS entsprechend Performance kosten wird.
Die Zahlen, die ich genannt habe, helfen vielleicht mögliche Fehler zu finden ... und da fallen mir neben der Leserate insbesondere die seq. Write-Werte negativ auf.
 
vmxnet3
Der vmxnet3 Treiber aus den vmwaretools die ESXi mitliefert,
läuft meist ganz gut wenn als Typ der VM Solaris 10-64 bit gewählt wurde.
Es gibt aber durchaus Berichte über Probleme mit vmxnet3 bei mancher Hardware

E1000 ist dann die übliche Alternative. Er erzeugt aber eine höhere CPU Last und ist damit
nicht ganz so schnell. Im ESXi internen Datentransfer sind damit aber durchaus mehrere Gb/s drin
(Es gibt ja kein physikalisches 1 Gb Medium, daher gehen auch mit E1000 mehr als 1 Gb/s)

Ich würde aber (eventuell probehalber) auf Jumbo Frames verzichten.
Bringt etwas Performance und eventuell Probleme


NFS
Normalerweise würde ich bei den genannten Problemen auf ein Rechteproblem tippen
(Das NFS share muss entweder die Zugriffsrechte evenyone@=modify mit Vererbung haben-
vor dem Anlegen der VM-, oder man muss die Rechte recursiv zurücksetzen) oder mit der
root-option freigegeben werden. Wenn es allerdings mit e1000 geht, scheint es das nicht zu sein.

Die schlechte Schreibperformance auf die VM (auf dem ESXi NFS share) liegt aber sicher daran,
dass ESXi beim Schreiben auf NFS sicherheitshalber syncron schreiben möchte (bei der jede
Schreibaktion sofort von der Platte bestätigt werden muss). Dadurch leidet die Performance
enorm solange kein schnelles ZIL device benutzt wird.

Einfach mal probehalber in napp-it sync für den NFS folder auf disabled setzen.
Wenn es dann besser ist, entweder aus lassen (kann kein korruptes ZFS Dateisystem als Folge haben,
aber eine korrupte VM -> UPS, Backup und Snaps verwenden) oder ein ZIL einsetzen - Wobei lediglich
die DRAM basierten ZIL Laufwerke die Performance halten können.


Leseperformance
Platten haben heutzutage in den inneren Spuren ca 150 MB/s und in den äußeren Spuren ca 70 MB/s.
Die genannten Werte bei ZFS Raid-10 entsprechen dem sehr gut. (Lesen= 4 fache Performance, Schreiben = Zweifach)
 
Hallo gea
Danke für die ausführliche Antwort.

HW Parameter:
Ich werde die Solaris 10 VM-Konfiguration ausprobieren, obwohl ich auch mit diesem Parameter schonmal gespielt habe.
Jumbo Frames werde ich ebenfalls abestellen.
Ich würde gerne verstehen, ob jemand in letzter Zeit mit der Kombination ESXI5, vmxnet3, OI151a3 oder a5 und Napp-it 8k bei der All In One-Konfiguration mit NFS vmstore Erfolg hatte, oder ob ich einem spezifischen Problem hinterherlaufe. (Wenn dies so wäre würde ich auf ein HW Problem tippen, da ich das System nackt gemäss tutorial aufgesetzt habe)
Aus Deiner Antwort entnehme ich, dass Dir das Problem mit derr VM-Einrichtung auf dem vmstore bisher noch nicht über den Weg gelaufen ist.
Werde über das Wochenende alternativ mal ISCSI statt NFS mit vmxnet3 versuchen, obwohl ich dabei die Eleganz der NFS-Lösung verlieren werde.

Rechtevergabe:
Das Rechte-Thema habe ich eigentlich ausgeschlossen, da das Exportieren des gleichen Folders mit e1000 geht, nicht jedoch mit vmxnet3.
Zur Sicherheit: Ich habe auf dem leeren Pool mit napp-it einen Folder erzeigt mit
- SMB share = on
- alles andere off
Anschliessend habe ich
- NFS auf on gesetzt und
- geprüft, dass e=modify gesetzt ist und 777 als Rechte vergeben sind.
Inherit steht glaube ich auf "file, dir". Korrekt?
Keine lcoal user, nur root und everyone.


E1000:
Ich bin mir nicht sicher, ob ich Dich richtig verstehe.
In der Konfiguration E1000, NFS vmstore, ESXI intern, Windows VM sagst Du:
- Hört sich realistisch an, dass bei synchronem Schreiben von den >200MB/s (Raw) nur noch 30MB/s über NFS verbleiben
- Bei der Read-Performance würdest Du mehr als 100MB/s bei einem zugrunde liegenden ZFS Raid10 erwarten
Werde bzgl. Writes mal asynchron versuchen und ggf. mit der Intel SSD als ZIL testen (auch wenn ich verstehe, dass nur DRAM basierte Caches wirklich helfen).
 
Ich würde gerne verstehen, ob jemand in letzter Zeit mit der Kombination ESXI5, vmxnet3, OI151a3 oder a5 und Napp-it 8k bei der All In One-Konfiguration mit NFS vmstore Erfolg hatte

Habe die Konfiguration so laufen (ESXI5U1, zuerst einige Monate auf Basis von OI151a, jetzt Solaris 11) und über NFS (Ubuntu 64 bit client) habe ich 70-90 MB/s read/write seq., CIFS von Windows 7 client ~110 MB/s read, ~90 MB/s write. Das Ganze mit e1000 und vmxnet3, ohne ZIL oder zusätzlichem L2ARC, sync writes aktiviert.
Host-intern (von Solaris zu Windows Server 2008 R2 + Windows Server 2012 RTM via CIFS share) ~110 MB/s lesen/schreiben seq. vmxnet3 Treiber in den Windows vms, e1000/vmxnet3 im Solaris, VMCI aktiviert.

Storage pool striped mirror aus 4xSAS Constellation ES.2


Ob sich die vmware tools unter Solaris 11 installieren lassen, wenn man Solaris 10 64bit als OS angibt, werde ich mal ausprobieren.
 
Zuletzt bearbeitet:
Habe die Konfiguration so laufen (ESXI5U1, zuerst einige Monate auf Basis von OI151a, jetzt Solaris 11) und über NFS (Ubuntu 64 bit client) habe ich 70-90 MB/s read/write seq., CIFS von Windows 7 client ~110 MB/s read, ~90 MB/s write. Das Ganze mit e1000 und vmxnet3, ohne ZIL oder zusätzlichem L2ARC, sync writes aktiviert.
Host-intern (von Solaris zu Windows Server 2008 R2 + Windows Server 2012 RTM via CIFS share) ~110 MB/s lesen/schreiben seq. vmxnet3 Treiber in den Windows vms, e1000/vmxnet3 im Solaris, VMCI aktiviert.

Storage pool striped mirror aus 4xSAS Constellation ES.2

Ob sich die vmware tools unter Solaris 11 installieren lassen, wenn man Solaris 10 64bit als OS angibt, werde ich mal ausprobieren.

Danke, antilope114.
Das ist doch mal ein Startpunkt, auch wenn es bedeutet, dass ich ein sehr spezifisches Problem vor mir habe.

vmxnet3:
OK. Dann werde ich mich noch einmal durch die Solaris Installation kämpfen.
Ich nehme an, Du nutzt Sol11/11 ohne SRUs/ Patches.
- Hast Du ESXIU1 auf den aktuellen Patch-Stand gebracht (April, Mai, Juni, Juli-Patches)?
- Hast Du Solaris als Solaris 11 (64Bit) in ESXI eingerichtet?
- Nutzt Du napp-it, wenn ja welcher Version?
- Wie konntest Du die vmware tools in Solaris 11 installieren. Bei mir ist die Installation abgebrochen - lediglich der vmxnet3 Treiber wurde bei mir installiert. VMs lassen sich jedoch nicht aus ESXI runterfahren?

Performance NFS:
Wenn ich Dich richtig verstehe, dann macht e1000 oder vmxnet3 keinen Unterschied in der vm-Performance, wobei weder bei Lesen noch Schreiben mit mehr als 110MB/s zu rechnen ist.
Ehrlich gesagt, dann ist man ja ESXI intern nicht (wesentlich) schneller als über die NICs nach aussen und hat nur noch den Latenzvorteil.
Das heisst lediglich meine Schreibperformance ist zu schwach, allerdings kann ich diese auch nicht verbessern, da Du in Deiner Konfiguration ebenfalls auf die langsameren sync writes setzt.
 
Ich nehme an, Du nutzt Sol11/11 ohne SRUs/ Patches.
korrekt

- Hast Du ESXIU1 auf den aktuellen Patch-Stand gebracht (April, Mai, Juni, Juli-Patches)?
VMkernel 5.0.0 #1 SMP Release build-623860 nutze ich, keine Extra-Patches

- Hast Du Solaris als Solaris 11 (64Bit) in ESXI eingerichtet?
Ja.

- Nutzt Du napp-it, wenn ja welcher Version?
Nein, mache alles über die console - nichts gegen Dich, gea ;)

- Wie konntest Du die vmware tools in Solaris 11 installieren. Bei mir ist die Installation abgebrochen - lediglich der vmxnet3 Treiber wurde bei mir installiert. VMs lassen sich jedoch nicht aus ESXI runterfahren?
Lassen sich nicht installiere bzw. führt zu kernel-panic. Allerdings habe ich wie gesagt noch nicht getestet, OI oder Solaris als Solaris 10 zu deklarieren.
Daher lässt sich die vm nicht von ESXi aus herunterfahren, korrekt. Allerdings funktioniert der Rest und (bis auf den Spam in der /var/adm/messages) habe ich bei der Netzwerkperformance keine adverse effects feststellen können. Bin jetzt trotzdem zurück zu e1000 gewechselt, weil wie gesagt im syslog alles andere (womöglich Wichtige) untergeht und es bzgl. der Performance so gut wie keinen (zumindest keinen statistisch signifikanten) Unterschied macht.

Wenn ich Dich richtig verstehe, dann macht e1000 oder vmxnet3 keinen Unterschied in der vm-Performance, wobei weder bei Lesen noch Schreiben mit mehr als 110MB/s zu rechnen ist.
Theoretisch sollte mein SAS Pool über CIFS an die Windows Server vm etwa 200 MB/s seq. read schaffen, warum es auf den genannten Wert limitiert ist kann ich daher nicht genau sagen. Die Frage, ob es prinzipiell möglich ist oder nicht, ist für mich eher theoretischer Natur, da der host-interne Traffic für mich mehr oder weniger irrelevant ist und extern mein GbE der limitierende Faktor ist.

edit/ ich sollte vielleicht noch erwähnen, dass meine Windows Server vms auf einer Intel 520 SSD laufen, die sollte aber definitiv nicht der Engpaß sein.

Gruß
 
Zuletzt bearbeitet:
hoffentlich nicht komplett ohne

Was ich meinte ohne zusätzliches Log device, war mißverständlich ausgedrückt.
Im Übrigen habe ich festgestellt, dass sich mit einer normalen SSD als Log (SF-2281 Controller) die Schreibperformance sogar (mitunter deutlich) verschlechtert.
 
Ergänzung (disk replace im gleichen Slot, ohne reboot auf die saubere Art)

z.B.
- erst disk offline stellen: zpool offline tank c1t3d0
- dann unconfigure: cfgadm -c unconfigure sata1/3
- tauschen
- configure: cfgadm -c configure sata1/3
- disk online: zpool online tank c1t3d0
- replace: zpool replace tank c1t3d0

Irgendwie will das bei mir nicht so klappen.
Für zpool hab ich "format" genommen um den richtigen String zu bekommen, für cfgadm wars "cfgadm -al"
Code:
# zpool offline archepool c1t5000C50009AAAE26d0
# cfgadm -c unconfigure c4::w5000c50009aaae26,0
# cfgadm -c configure c4::w5000cca36ad1780c,0
# zpool online archepool c1t5000CCA36AD1780Cd0
cannot online c1t5000CCA36AD1780Cd0: no such device in pool
Ich hab dann napp-it/disks/replace genutzt um das resilver anzustoßen.

Was ist jetzt schon wieder bei mir falsch gelaufen?

Noch eine Frage:
Ich hab noch freie Slots in meinem Norco RPC-4224 kann aber keine weitere LSI Karte mehr stecken. Die SATA Steckplätze sind noch frei.
Kann ich das Fan-out Kabel SFF-8087 auf SATA "verkehrt herum" auch benutzen? Also SATA auf Motherboard und SFF-8087 an Backplane.
 
zu cfgadm:
die device id scheint mir fehlerhaft (id sollte auf d0 enden).
was gibt denn napp-it unter "id"_device im Menü disk - diskinfo aus?

Onboard Sata -> Backplane: geht mit speziellem reverse 8087 Kabel, nicht mit dem normalen Kabel
(beim Bestellen auf "reverse" achten)
 
Mal eine Verständnisfrage

Wenn ich auf einer ZFS Storage ein Volume via ISCSI einem Linux oder Windows Server bereitstelle, dass dann wiederumg mit xfs, ext4 oder ntfs formatiere, wie sieht es dann mit der Konsistenz des zweiten Dateisystems aus?
Sagen wir mal der Windows Server geht hops, oder der verbaute Netzwerk- oder Infiniband Controller produziert fehler. Ist dann mein ntfs Dateisystem dennoch Konsistent?
Theoretisch sollten Daten im ntfs Dateisystem den gleichen schutz haben wie Daten, die direkt in ein zfs Dateisystem gelegt werden. Wenn ich also in einem Windows Server Daten speichere, der Übertragungsweg zum iscsi target einen fehler verursacht, dann speichter zfs die Blöcke theretisch nicht (schreibe alles oder nichts) Prüfsummen stimmen nicht etc. Ich sollte dann vom Windows Server eine Fehlermeldung erhalten (kein Spreichen möglich) oder die Kiste schmiert ab. Aber das NTFS dürfte keinen schaden erlangen.
Ist das soweit richtig?

Danke an alle!
 
zu cfgadm:
die device id scheint mir fehlerhaft (id sollte auf d0 enden).
was gibt denn napp-it unter "id"_device im Menü disk - diskinfo aus?

Onboard Sata -> Backplane: geht mit speziellem reverse 8087 Kabel, nicht mit dem normalen Kabel
(beim Bestellen auf "reverse" achten)

@Gea, ich hab mal in der Anlage die komplette Diskinfo mit geschickt.
1. es gibt keine id_device
2. "cfgadm -al" hat mir in der Tat die ID mit xxx,0 ausgegeben, übrigens so stehts auch in der Diskinfo
3. Was mich stutzig macht ist, sind diese Strings
Code:
 c17::w5000cca369ca262b,0 connected configured unknown Client Device: /dev/dsk/c1t5000CCA369CA262Bd0s0(sd8) disk-path n /devices/pci@0,0/pci15ad,7a0@15,1/pci1000,3020@0/iport@8:scsi::w5000cca369ca262b,0
Fällt dir noch was ungewöhnliches auf?

Meinst du dann dieses Kabel? LSI Internal Multi-Lane Cables - All Cables
 

Anhänge

  • diskinfo.txt
    22,3 KB · Aufrufe: 142
Zuletzt bearbeitet:
Mal eine Verständnisfrage

Wenn ich auf einer ZFS Storage ein Volume via ISCSI einem Linux oder Windows Server bereitstelle, dass dann wiederumg mit xfs, ext4 oder ntfs formatiere, wie sieht es dann mit der Konsistenz des zweiten Dateisystems aus?
Sagen wir mal der Windows Server geht hops, oder der verbaute Netzwerk- oder Infiniband Controller produziert fehler. Ist dann mein ntfs Dateisystem dennoch Konsistent?
Theoretisch sollten Daten im ntfs Dateisystem den gleichen schutz haben wie Daten, die direkt in ein zfs Dateisystem gelegt werden. Wenn ich also in einem Windows Server Daten speichere, der Übertragungsweg zum iscsi target einen fehler verursacht, dann speichter zfs die Blöcke theretisch nicht (schreibe alles oder nichts) Prüfsummen stimmen nicht etc. Ich sollte dann vom Windows Server eine Fehlermeldung erhalten (kein Spreichen möglich) oder die Kiste schmiert ab. Aber das NTFS dürfte keinen schaden erlangen.
Ist das soweit richtig?

Netzwerkprotokolle haben ihre eigene Sicherungsschicht. Es werden also keine fehlerhaften Pakete einfach so akzeptiert.
ZFS stellt nur sicher das die geschriebenen Blöcke nur verwendet werden wenn die Prüfsumme dafür übereinstimmt. Sofern die Prüfsummen dafür auch aktiviert sind.
Ob in einem Container dann ein NTFS, XFS oder sonst ein Dateisystem korrupt ist weil der Client sich sein Dateisystem zerstört kann kein OS verhindern, auch nicht Solaris.
Wenn du einen höheren Schutz willst, verwende NFS bzw. SMB. Beides zeitgleich soll anscheinend nicht vernünftig tun unter Solaris...?
 
Wenn du einen höheren Schutz willst, verwende NFS bzw. SMB. Beides zeitgleich soll anscheinend nicht vernünftig tun unter Solaris...?

Sagt wer? :)

@ahuser) Das Thema Block-devices und zfs checksums haben wir auch schon an andere Stelle hier im Thread ausführlicher behandelt, einfach mal die Suchfunktion nutzen falls du mehr Infos brauchst.
 
afaik meinte gea dazu etwas, hatte wohl vor allem mit den Berechtigungen zu tun.
SMB wär für Windows Ideal und NFS für Linux/BSD und andere Unix-Systeme - sofern man kein Windows Prof. hat.
 
SMB wär für Windows Ideal und NFS für Linux/BSD und andere Unix-Systeme

Ja ist ja auch so. Berechtigungen kann man ja protokollübergreifend mit ACLs regeln, was natürlich voraussetzt, dass entsprechende user-mappings zw. Windows + Unix existieren.
 
@Gea, ich hab mal in der Anlage die komplette Diskinfo mit geschickt.
1. es gibt keine id_device
2. "cfgadm -al" hat mir in der Tat die ID mit xxx,0 ausgegeben, übrigens so stehts auch in der Diskinfo
3. Was mich stutzig macht ist, sind diese Strings
Code:
 c17::w5000cca369ca262b,0 connected configured unknown Client Device: /dev/dsk/c1t5000CCA369CA262Bd0s0(sd8) disk-path n /devices/pci@0,0/pci15ad,7a0@15,1/pci1000,3020@0/iport@8:scsi::w5000cca369ca262b,0
Fällt dir noch was ungewöhnliches auf?

Meinst du dann dieses Kabel? LSI Internal Multi-Lane Cables - All Cables

zu 1.
für "id" die Plattenid einsetzen, z.B.
c1t5000CCA369CBF60Cd0_device -> c12::w5000cca369cbf60c,0

zu 2.
bei meinen Expandern sieht die device-id auch so aus

zum Kabel
Ja, das Kabel is ok

---------- Post added at 17:46 ---------- Previous post was at 17:35 ----------

Wenn du einen höheren Schutz willst, verwende NFS bzw. SMB. Beides zeitgleich soll anscheinend nicht vernünftig tun unter Solaris...?


Das Problem ist kein Solaris Problem sondern liegt an NFS3:
NFS3 kennt keine Userrechte, sondern regelt den Zugriff über die Rechner-ip.
Entweder muss man dann über die Freigabeeinstellung einem Rechner Zugriff geben oder es über jeder bzw nobody erlauben

NFS und CIFS arbeiten dagegen mit Windows kompatiblen NFS4-ACL bei denen alles auf angemeldete Benutzer und Gruppen abgebildet wird.

Man benötigt dann auch kein idmapping, da ein lokaler OI user für NFS4 sowie Windows und CIFS der gleiche ist (lediglich das CIFS Passwort hat ein anderes Format und muss separat gespeichert werden)

idmapping wird nur bei Verzeichnisdiensten (AD, ldap) und für Gruppen benötigt.


Ansonsten ist ein iSCSI target auf ZFS für das Gastsystem z.B. Windows (ntfs) oder Linux (ext3) so etwas wie eine Festplatte die fehlerfrei arbeitet. Ob Windows oder eine defekte Hardware Unsinn darauf schreiben kann ist eine andere Frage.
 
Zuletzt bearbeitet:
zu 1.
für "id" die Plattenid einsetzen, z.B.
c1t5000CCA369CBF60Cd0_device -> c12::w5000cca369cbf60c,0

zu 2.
bei meinen Expandern sieht die device-id auch so aus

zum Kabel
Ja, das Kabel is ok


Danke für deine schnelle Antwort.
zu 3. ist da alles in Ordnung?
Weil, das "connected configured unknown Client Device" macht mich stutzig.

Warum hat dann meine Vorgehensweise nicht funktioniert?
 
Danke für deine schnelle Antwort.
zu 3. ist da alles in Ordnung?
Weil, das "connected configured unknown Client Device" macht mich stutzig.

Warum hat dann meine Vorgehensweise nicht funktioniert?


- connected, configured ist entscheidend, unknown bei Condition ist normal
- bei portbasierten id's (z.B. c1t1d0) führt ein unconfigure, tausch und configure dieser id automatisch zum resilver

WWN sind jedoch plattenspezifische Angaben. d.h.

cfgadm -c unconfigure c4::w5000c50009aaae26,0
-diese Platte (Poolmitglied) ist abgemeldet und kann entfernt werden

cfgadm -c configure c4::w5000cca36ad1780c,0
- diese neue Platte (kein Poolmitglied) kann verwendet werden

Dem Pool fehlt jetzt erstere Platte und er ist degraded
Jetzt einfach ein disk-replace alte -> neue Platte und es sollte funktionieren
 
- connected, configured ist entscheidend, unknown bei Condition ist normal
- bei portbasierten id's (z.B. c1t1d0) führt ein unconfigure, tausch und configure dieser id automatisch zum resilver

WWN sind jedoch plattenspezifische Angaben. d.h.

cfgadm -c unconfigure c4::w5000c50009aaae26,0
-diese Platte (Poolmitglied) ist abgemeldet und kann entfernt werden

cfgadm -c configure c4::w5000cca36ad1780c,0
- diese neue Platte (kein Poolmitglied) kann verwendet werden

Dem Pool fehlt jetzt erstere Platte und er ist degraded
Jetzt einfach ein disk-replace alte -> neue Platte und es sollte funktionieren

Ich habs ja schlußendlich mit deinem napp-it hinbekommen.
Du hattest aber hier die Vorgehensweise beschrieben:
Ergänzung (disk replace im gleichen Slot, ohne reboot auf die saubere Art)

z.B.
- erst disk offline stellen: zpool offline tank c1t3d0
- dann unconfigure: cfgadm -c unconfigure sata1/3
- tauschen
- configure: cfgadm -c configure sata1/3
- disk online: zpool online tank c1t3d0
- replace: zpool replace tank c1t3d0

Ich werde das noch in napp-it so ändern (Option: offline stellen)
und da funzte das replace auf der CLI Ebene nicht.
Müsste es nicht
replace: zpool replace tank alteHD neueHD oder
replace: zpool replace tank neueHD alteHD
heißen?
 
Zuletzt bearbeitet:
Falls die Disk nicht im gleichen Controller Port esetzt wird geht es mit
zpool replace tank alteHD neueHD z.B.
zpool replace tank c1t1d0 c2t0d0

Falls die Disk im gleichen Controller Port esetzt wird geht es mit
zpool replace tank c1t1d0


mit den platteneigenen SAS2 WWN Nummern geht es aber nur mit der Angabe beider Nummern z.B.
zpool replace tank c3t600039300001EA56d0 c4t600036700401EA61d0


http://docs.oracle.com/cd/E19253-01/819-5461/gbcet/index.html
 
Hallo Freunde,

Betreibe seit einiger Zeit einen All-in-One Server (ESXi+OI 154a5+Napp-it) und bin wirklich sehr zufrieden damit !!!
Als HBA habe ich ein Intel SASUCI8I im IT-Mode im Einsatz mit 6 1TB Platten + 2 500 GB und absolut keine Probleme.
Da ich aber in absehbarer Zeit die Platten austauschen möchte, habe ich mir eine IBM m1015 (muss noch IT-Mode geflasht werden) zugelegt um die SASUCI8I zu ersetzen.
Frage: Kann ich einfach die Karten austauschen oder muss ich eine bestimmte Prozedur einhalten?

Ich dachte an folgende Vorgehensweise:
- m1015 in den Server einbauen
- Karte an OI durchreichen
- Server runterfahren und SASUCI8I ausbauen, Festplatten an die m1015 hängen und neu starten.

Wäre das so korrekt?
 
Hallo GuNa,

ich habe das gerade durch: Pool exportieren, ESX runterfahren und Karte tauschen, neue Karte durchreichen, Pool importieren
 
vmxnet3
Ich würde aber (eventuell probehalber) auf Jumbo Frames verzichten.
Bringt etwas Performance und eventuell Probleme

Nachdem ich Jumboframes in ESXI und Solaris/ OI abgestellt, habe funktioniert das All-in-One-Konzept ohne Probleme.
Ich kann jetzt VMs in ESXI auf dem per NFS exportierten datastore einrichten - auch mit vmxnet3-Treiber.
Danke für den Tipp!

Ich muss am Wochenende noch ein paar Tests machen, um mich zu entscheiden, ob ich die VMs auf NFS datastore or ISCSI datastore einrichte.
Meine ersten Tests haben signifikante Performance-Unterschiede (bei seq. reads) gezeigt. Muss das aber nochmals mit IOmeter nachmessen, da ich CrystalDiskMark nicht (mehr) traue (die Varianzen der messungen sind zu gross).
@antiplope: Ich habe keine Idee, wie Du in Deinem Setup bei seq. Writes auf 100 MB/s ohne zusätzliche ZIL SSD (und bei aktivierten synchronen writes) kommst. In meinem Fall ist nicht mehr als 26MB/s drin. Mit der Intel 320 als ZIL verbessert sich die Situation, ohne sind es aber sehr mau aus.

Abschliessend noch ein paar Fragen und eine Beobachtung bszgl. Comstar/iscsi mit napp-it 8k:
1) Das iscsi-LUN liegt ja in einem ZFS Folder: Ich nehme an, ich muss in diesem Fall write-sync auf "standard" (d.h. keine asynchronen Writes) stellen. Was wären die Konsequenzen, wenn ich das nicht tue?
2) Den Write-Back Cache des LUNs habe ich "enabled" (safe but slow) gestellt: Was sind die Konsequenzen, wenn ich das nicht tue?
3) Ich bin nicht in der Lage mit napp-it ein CHAP user/pwd einzurichten. Wenn ich es über das Comstar-Menü (Edit Target) eingebe, ist es anschliessend in der Target-Übersicht als "unset" deklariert. Mein Eindruck ist, dass napp-it ein "+"-Symbol an den entsprechenden CLI-Befehl anhängt und der Befehl daher nicht ausgeführt wird.
Per Kommandozeile kann ich den Befehl ausführen. Leider habe ich es auch anschliessend nicht geschafft, das ISCSI LUN unter Windows 7 mit CHAP-Authentifizierung einzubinden. Das target wird discovered. Wenn ich unter "advanced settings" im initiator CHAP username und Passwort (12 Zeichen) eingebe, erhalte ich immer einen "Authentification Error". Ohne Chap kein Problem.
Muss ich weitere Services unter napp-it aktivieren?
 
@antiplope: Ich habe keine Idee, wie Du in Deinem Setup bei seq. Writes auf 100 MB/s ohne zusätzliche ZIL SSD (und bei aktivierten synchronen writes) kommst. In meinem Fall ist nicht mehr als 26MB/s drin. Mit der Intel 320 als ZIL verbessert sich die Situation, ohne sind es aber sehr mau aus.

Eigentlich sollte das zusätzliche Log device bei großen sequential writes genau 0 Unterschied machen, v.a. bei CIFS. Das dürften bei dir also zufällige Schwankungen sein.

Selbst bei random writes schaffe ich teilweise >50 MB/s. Es hängt dann vielleicht an deinen Festplatten (ich nehme an du nutzt SATA-Laufwerke?) bzw. der Poolarchitektur (was auch immer du aufgesetzt hast)

Ich habe übrigens Jumboframs aktiviert.

Grüße
 
Nachdem ich Jumboframes in ESXI und Solaris/ OI abgestellt, habe funktioniert das All-in-One-Konzept ohne Probleme.
Ich kann jetzt VMs in ESXI auf dem per NFS exportierten datastore einrichten - auch mit vmxnet3-Treiber.
Danke für den Tipp!

Ich muss am Wochenende noch ein paar Tests machen, um mich zu entscheiden, ob ich die VMs auf NFS datastore or ISCSI datastore einrichte.
Meine ersten Tests haben signifikante Performance-Unterschiede (bei seq. reads) gezeigt. Muss das aber nochmals mit IOmeter nachmessen, da ich CrystalDiskMark nicht (mehr) traue (die Varianzen der messungen sind zu gross).
@antiplope: Ich habe keine Idee, wie Du in Deinem Setup bei seq. Writes auf 100 MB/s ohne zusätzliche ZIL SSD (und bei aktivierten synchronen writes) kommst. In meinem Fall ist nicht mehr als 26MB/s drin. Mit der Intel 320 als ZIL verbessert sich die Situation, ohne sind es aber sehr mau aus.

Abschliessend noch ein paar Fragen und eine Beobachtung bszgl. Comstar/iscsi mit napp-it 8k:
1) Das iscsi-LUN liegt ja in einem ZFS Folder: Ich nehme an, ich muss in diesem Fall write-sync auf "standard" (d.h. keine asynchronen Writes) stellen. Was wären die Konsequenzen, wenn ich das nicht tue?
2) Den Write-Back Cache des LUNs habe ich "enabled" (safe but slow) gestellt: Was sind die Konsequenzen, wenn ich das nicht tue?
3) Ich bin nicht in der Lage mit napp-it ein CHAP user/pwd einzurichten. Wenn ich es über das Comstar-Menü (Edit Target) eingebe, ist es anschliessend in der Target-Übersicht als "unset" deklariert. Mein Eindruck ist, dass napp-it ein "+"-Symbol an den entsprechenden CLI-Befehl anhängt und der Befehl daher nicht ausgeführt wird.
Per Kommandozeile kann ich den Befehl ausführen. Leider habe ich es auch anschliessend nicht geschafft, das ISCSI LUN unter Windows 7 mit CHAP-Authentifizierung einzubinden. Das target wird discovered. Wenn ich unter "advanced settings" im initiator CHAP username und Passwort (12 Zeichen) eingebe, erhalte ich immer einen "Authentification Error". Ohne Chap kein Problem.
Muss ich weitere Services unter napp-it aktivieren?


sync=default=auto -> ZFS beachtet den Wunsch der schreibenden Anwendung
wenn man sync nicht möchte, dann sync=off

Bei 1 und 2 geht es um das gleiche. Wenn der Strom ausfällt, sind eventuell die letzten 5s Schreiben verloren.
Wenn man das nicht möchte, muss man sync aktiviert lassen (via default=auto).
Es kann bei kleinen Dateien dann aber erheblich lansamer sein als mit sync=off

Wenn es schnell sein soll und sicher, dann braucht man ein Log-device.
Wenn es praktisch gleich schnell sein soll dann ein DRAM Logdevice.

Wobei bei einem all-in-one meist eine kleine USV eine bessere Investition ist als ein teures Log-device.


zu 3.
Da ich complett auf NFS umgestellt habe, müsste ich mr iSCSI + chap erst mal wieder anschauen
Bei Bedarf einfach das Script für edit target anschauen:
"/var/web-gui/data/napp-it/zfsos/09_comstar iscsi/03_targets/03_edit iscsi targets/action.pl"


mit
&print_var($variable);
kann man das script anhalten und den Inhalt von $variable ausgeben.
Das Passwort steht in: /var/web-gui/data/napp-it/_log/passwd.txt

---------- Post added at 20:54 ---------- Previous post was at 20:48 ----------

Eigentlich sollte das zusätzliche Log device bei großen sequential writes genau 0 Unterschied machen, v.a. bei CIFS. Das dürften bei dir also zufällige Schwankungen sein.

Grüße

Sync write wird nur benutzt, wenn die schreibende Anwendung das anfordert (egal ob bei großen und kleinen Dateien) Die Größe des Log device muss aber lediglich so groß sein um max 10s Daten zu puffern (10 Gb/s=1GB/s x 10 = 10 GB)
Selbst bei 10 Gbe reicht also ein 8GB ZIL so wie es bei einem ZeusRAM der Fall ist.

CIFS benutzt das nicht und da ist es egal.
 
Hallo,
ich weiss zwar nicht ob schonmal jemand gefragt hat aber....

Ist es möglich einen zfs Pool der unter Linux (ZFS on Linux) erstellt wurde in Opensloaris/Indiana zu importieren?
 
Zuletzt bearbeitet:
Hallo,
ich weiss zwar nicht ob schonmal jemand gefragt hat aber....

Ist es möglich einen zfs Pool der unter Linux (ZFS on Linux) erstellt wurde in Opensloaris/Indiana zu importieren?

Von der ZFS Version (V.28) gibt es kein Problem.

Probleme kann eventuell die Partitionierung machen.
Von FreeBSD können z.B. keine Pools importierte werden, deren Platten GPT formatiert sind
sondern nur solche die Geom formatiert sind. Ob es mit Linux ähnliche Probleme gibt, kann ich nicht sagen.

Einfach mal probieren und Ergebnis posten.
 
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