[Sammelthread] ZFS Stammtisch

Hi,

ich kenne diese Profile nicht. Hier sollen in den Anfangszeiten um die 5000 User auf ThinClients zugreifen.
Bei den Storages wäre es - IMHO - ganz festes IMHO - wichtig das man vielleicjht mit Profilen oder Autom. Tiering arbeiten kann. Bei 200 Usern mag es nicht ganz so tragisch sein. Aber lass die mal alle morgens die Kisten an machen und Outlook öffnen.
Typischerweise hat man uns mal 50-60IOPS pro Client angegeben im normalen Betrieb. Beim booten dann eben mehr.

- SAS/FC Disks? Ist in den mir bekannten Boxen an sich egal. FC sind die Anschlüsse nach außen (SAN) und SAS eben intern.
- reduntante Controller - unerläßlich IMHO in irgendeinerweise Redundanz zu schaffen. Ein ausgefallener Controller und 200 Leute können nicht mehr arbeiten wenn man es NICHT redundant hat. Jede LUN/Ldev (wie auch immer man es nnen mag) ist intern 2 pfadig am Subsystem und naxch draussen per SAN eben mind 2 pfadig.

Zum Rest kann ich so nichts sagen, sry.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Welches? Es gibt keinen Hersteller der "ein San" verkauft. Das San selber ist relativ egal. Du kannst ja auch 5000 user auf eine vom legen und 2x8gb FC nutzen. Ist auch ein"San"
 
Varianten anschaue:

Man nehme:
- SAS/Fibrechannelplatten
- x-fach redundante Controller
- PCIe-SSDs fürs Caching
- genügend ECC-RAM
- irgendeine Blackbox-Logik, die automatisch, basierend auf der benötigten IOP-Auslastung, die VMs zwischen den Platten verschiebt
- manch einer wirbt mit eigenen ASICs, die irgendetwas beschleunigen sollen.

Ich hatte noch keine so große VDI Lösung.
Rein gefühlsmäßig würde ich aber auf folgendes achten:

- Mehrere kleinere als die eine große Lösung die nie ausfallen darf.
Im Extrem ein Virtual SAN nehmen (mit ZFS je ein virtualisiertes SAN pro VM Server)
- HA oder near realtime Replikation auf ein Backupsystem von dem man VMs starten kann
- Hot/Cold-Reservesystem einplanen
- Wenn möglich SSD only Storage nehmen

Wenn SSD only zu teuer ist (geht nur bei Open-ZFS relativ billig):
- soviel RAM als Read-Cache einsetzen wie irgend möglich (bei ZFS würde ich bis 128 GB für das SAN nehmen)
- ergänzend eventuell SSD Read-Cache einsetzen (nicht so schnell wie RAM Cache)
aber nur nachdem eine Cache-Prüfung z.B. arcstat feststellt dass die Trefferquote im RAM nicht ausreichend ist

- automatisches Tiering würde ich vermeiden da die Gefahr besteht, dass Kurzzeit-Last-VMs durch das Tiering-Copy zusätzlich belastet werden. Im Zweifel belegen die dann High-Performance Storage wenn die Last schon wieder weg ist (Backup etc).

- Echtzeit Dedup unter ZFS würde ich noch vermeiden. Compress mit LZ4 wäre ok
Dedup Massnahmen auf VMware Ebene sind ok.

- Wegen der Snaps den Storage wenigstens doppelt so groß konzipieren wie aktuell mindestens benötigt.
Storage nicht über 80% belegen.
 
- automatisches Tiering würde ich vermeiden da die Gefahr besteht, dass Kurzzeit-Last-VMs durch das Tiering-Copy zusätzlich belastet werden. Im Zweifel belegen die dann High-Performance Storage wenn die Last schon wieder weg ist (Backup etc).
Kleien Randbemerkung. In der Hardware in der ich es kenne (ist ja beschränkt) ist genau das nicht so. Es gibt einen Short und einen Longwert. Wenn jetzt jeden Morgen Last kommt nimmt das der Shortwert mit und es geht auch ins Mittel. So entsteht ein Mittelwert ab dem Daten auf die shcnellen Platten gelegt werden. Also z.B. 500 IOPS/pro Page. Am Wochenende passiert nichts, der Mittelwert ist sinkt nur langsam und erreicht nicht den 500IOPS Meridian. Somit bleibt alles auf den schnellen Plattenbereichen. Selbstverständlich kann ich auf Zuruf auch Daten per hand auf SSD/FMD festnageln oder zwingen nur im Datengrab zu bleiben.
Ich kann natürlich nicht sagen welcher Anbietr, welche Software usw sowas bis zu welchem Storage macht (Entry level usw)
 
Kleien Randbemerkung. In der Hardware in der ich es kenne (ist ja beschränkt) ist genau das nicht so. Es gibt einen Short und einen Longwert. Wenn jetzt jeden Morgen Last kommt nimmt das der Shortwert mit und es geht auch ins Mittel. So entsteht ein Mittelwert ab dem Daten auf die shcnellen Platten gelegt werden. Also z.B. 500 IOPS/pro Page.

Es geht mir da zunächst ähnlich - nur von der anderen Seite her. Die großen Dinger kenne ich nur von Kollegen oder Präsentationen wie z.B. NetApp letzte Woche bei uns im Haus.

Bei den Lösungen mit denen ich arbeite (OpenSource/ ZFS) stellt sich die Frage aber auch garnicht. Da gibt es kein Tiering (Ich kenne auch keine LowCost/ Entry Level Lösung die Tiering anbietet). Da ist langsamer Storage immer ausschließlich Backupstorage oder normaler Filer mit bis zu 48 x 7200 U/m Sata Platten oder schneller Produktiv-Storage für VMs mit vielen 10k Platten + massiv Cache (RAM, SSD) oder wie bei mir eben gleich SSD Storage.

Es ist da aber nicht der Kostenaspekt.
Ein 24 x 2,5" Case SC 216 von SuperMicro mit aktuellem 6Kern Xeon, 2x10 GbE und 128 GB RAM sowie 20 x 800 GB Intel 3500 Enterprise SSD gibts deutlich unter 20k Euro mit ca 12 TB Nutzkapazität bei 2 x Raid-Z2 und sehr geringen Latenzen und mehreren Tausend IOPS.

Bei den Preisen stellt sich die Frage 10k SAS Platten oder langsame Sata Platten mit Tiering oder nur SSD Cache erst garnicht. Bei mir selber habe ich 6 ESXi Server jeweils mit eigenem ZFS vSAN und SSD Storage (je unter 2 TB im Einsatz, je ca 4500 Euro). Hot-Reservesysteme ohne Platten sind da kein Thema bei ca 2500 Euro ohne SSD. Da stört mich auch nicht dass es nur Hardwaresupport gibt (Wir bilden Fachinformatiker aus, die müssen auch was lernen).

Mein Einsatz ist aber F&L und eine kurze Ausfallzeit ist für mich kein Thema. Geringe Komplexität einer Lösung ist da mein erstes Ziel (also z.B. kein HA) wobei ich nach einem Totalausfall eines Systems innerhalb von 30min wieder online bin indem ich entweder die Platten in das Reservesystem schiebe oder zur Not die replizierten VMs vom Backupserver hochfahre.
 
Zuletzt bearbeitet:
Sowas kann dann so aussehen wie in dem Beispiel im Anhang. Selbstredend sind die wichtigstens Dinge raus genommen ;). Ein einfacher2-Tier-Pool der sich selbst verwaltet. So liegen Teile im Tier1 und Teile im Tier2 usw.. Verwaltung erfolgt in 42mb Pages pro Ldev/lun.

test.jpg
 
DataCore SANSymphony-V bietet auch Auto-Tiering an.

@sun-man, um was für ein Storage handelt es sich in deiner Abbildung?
 
Ein 24 x 2,5" Case SC 216 von SuperMicro mit aktuellem 6Kern Xeon, 2x10 GbE und 128 GB RAM sowie 20 x 800 GB Intel 3500 Enterprise SSD gibts deutlich unter 20k Euro mit ca 12 TB Nutzkapazität bei 2 x Raid-Z2 und sehr geringen Latenzen und mehreren Tausend IOPS.

Mein Einsatz ist aber F&L ...

Hallo gea,

wie sieht in diesem Fall die Raid-Z2 Konfiguration aus? Jeweils 10 SSDs oder hast Du auch Spares konfiguriert? Wie überwachst Du die SSDs (Ich meine die erros bei S H T)?

Was bedeutet F&L - Forschung und Lehre?
 
Hallo gea,

wie sieht in diesem Fall die Raid-Z2 Konfiguration aus? Jeweils 10 SSDs oder hast Du auch Spares konfiguriert? Wie überwachst Du die SSDs (Ich meine die erros bei S H T)?

SSD haben so viele IOPS dass ein oder mehrere Raid Z2 mit 6 oder 10 SSDs ökomomischer als Mirrors und eine gute Wahl sind. Hotspares nehme ich aber schon. Bei einem Pool aus einem vdev ist eher Raid-Z3 statt Hotfix eine Option.

Iostat Meldungen überwache ich nicht automatisch obwohl die manchmal ein Indiz für künftige Fehler sind.

Was bedeutet F&L - Forschung und Lehre?

ja
 
Hallo gea, vielen Dank für die schnelle Antwort. Ich möchte gerne so eine Maschine zum Test aufbauen. Auf Deiner Webseite unter Musterkonfigurationen (Hohe IOPS / NAIO) ist ja alles bestens beschrieben. Einzige Frage ist, welchen genauen Typ Du für die Inter Nic (10 GbE) einsetzt. Ich möchte die Maschine in erster Linie als performante ESXi Storage verwenden und dabei das Napp-in-One Konzept umsetzen.
 
Hallo gea, vielen Dank für die schnelle Antwort. Ich möchte gerne so eine Maschine zum Test aufbauen. Auf Deiner Webseite unter Musterkonfigurationen (Hohe IOPS / NAIO) ist ja alles bestens beschrieben. Einzige Frage ist, welchen genauen Typ Du für die Inter Nic (10 GbE) einsetzt. Ich möchte die Maschine in erster Linie als performante ESXi Storage verwenden und dabei das Napp-in-One Konzept umsetzen.

Für 10 GbE habe ich hauptsächlich SFP+ und CX4.
10 GBase-T ist aber stark im Kommen. Eine günstige Karte ist die Intel X 540-T1 (oder-T2).
Ein günstiger 10 G Switch dazu ist der Netgear XS708E
 
Warnung: ESXi 5.5U1 und NFS Server (z.B. Napp-In-One)



Beim Einsatz von NFS sollte ESXi nicht auf 5.5U1 upgedated werden.


Intermittent NFS APDs on ESXi 5.5 U1 (2076392)

Symptoms
When running ESXi 5.5 Update 1, the ESXi host frequently loses connectivity to NFS storage and APDs to NFS volumes are observed.
You experience these symptoms:

Intermittent APDs for NFS datastores are reported, with consequent potential blue screen errors for Windows virtual machine guests
and read-only filesystems in Linux virtual machines.


VMware KB: Intermittent NFS APDs on ESXi 5.5 U1
 
@gea,
hat es einen bestimmten Grund, dass du beim Anlegen eines iscsi-Target das Volume als "sparse volume" anlegst?
Es besteht doch so die Gefahr, dass das Volume größer wird als tatsächlich zur Verfügung steht. Was passiert dann?

Bei mir funzt es nicht richtig ein iscsi-target anzulegen, napp-it legt dafür eine target-group an.
 
Speicher überbuchen bringt Flexibilität - man muss halt mitdenken und aufpassen.

Zu iSCSI mit Comstar - das braucht 4 Schritte:
1. LU anlegen
2. Target anlegen
3. Target group anlegen mit Target als Member
4. ein View auf die Target Group setzen.

Etwas aufwändig, ist aber auch auf große Installationen ausgelegt.
Beim aktuellen napp-it habe ich daher wieder iSCSI als Eigenschaft eines Dateisystems umgesetzt.-
einfach unter ZFS Dateisystems als share ein/ ausschalten
 
Hallo,

Ich lese nun seit längerem mit und habe auch diverse andere Artikel zum Thema zfs gelesen und habe ein paar Fragen. Geplant ist der Einsatz von zfs unter Linux, da der Server noch ein paar andere Funktionen übernehmen soll und eine Virtualisierung nicht möglich ist.

Ich möchte zwei Platten (2TB) als mirror betreiben und dieses später durch ein oder zwei weitere mirror ergänzen (quasi ein RAID10), was soweit ja problemlos möglich ist. Kann ich zum ergänzen des bestehenden mirror auch größere Platten nehmen als im alten mirror vorhanden (z.b. 2x4TB)?

Brauche ich für den Einsatz von Checksummen auf einem mirror ein weiteres Device und müssen diese separat aktiviert werden?

Und die letzte Frage: ist in diesem Fälle eine SSD (crucial 128gb vorhanden) als ZIL+ Und L2ARC zweckmäßig? Im Server sind 8gb RAM verbaut, abzüglich System und Co. verbleiben ca. 4GB für das ZFS was spätestens bei der ersten Erweiterung knapp werden dürfte.

Grüße!
 
Unterschiedlich große vdevs sind kein Problem -
Wenn die kleinere vdev voll ist, singt die Performance halt von Raid-10 auf Raid-1 Niveau

Prüfsummen werden als Teil der Datei gespeichert.
Also kein extra Device und kein Problem beim Kopieren der Dateien

Boot + Zil + ARC ist möglich aber verpönt, da es die Konfiguration kompllziert macht.
Auf jeden Fall darauf achten, dass nicht die ganze SSD benutzt wird (underprovision).
denn ein langsames ZIL Logdevice ist schlechter als kein extra ZIL.

RAM ab 2 GB ist kein Problem, ausser man möchte Performance durch einen schnellen
LeseCache (wer möchte das nicht...)
 
Zuletzt bearbeitet:
Hallo gea,

Boot wäre über einen extra mirror (2x2,5" 500gb) so das die SSD nur für ZIL und L2ARC wäre... Wenn ich das nun richtig verstehe wäre es zweckmäßiger ZIL wegzulassen, die SSD als L2ARC zu nehmen und fertig?

Vielen Dank schonmal für die Antwort!
 
ARC und ZIL ist ja nichts wirklich wünschenswertes.
Man tut sich das nur an um aus unzuverlässigen und langsamen Platten sicheres Schreiben oder Performance herauszukitzeln.

Ein ZIL beispielsweise sorgt dafür, dass bei sicherem syncronen Schreiben die letzte Schreibaktion bei einem Stromausfall nicht verloren ist - ähnlich einer Batterie bei einem Hardware-Raid - nur viel sicherer. Wenn man kein sicheres Schreiben benötigt, schaltet man sync aus und Schreiben ist schneller als mit dem schnellsten verfügbaren ZIL (ZeusRAM) und sync=on.

Mit einer SSD als L2ARC ist es ähnlich. Es ergänzt schnellen RAM-Cache um langsamen SSD Cache. Das macht nur Sinn weil die Platten nochmal viel langsamer sind. Besser wäre mehr schneller RAM Cache.

Wenn das nicht geht, ist eine SSD als L2ARC halt die zweitbeste Lösung.
 
Das hatte ich dann wohl anders verstanden... Dann bleibts wohl beim normalen RAID 1 mit späterer Erweiterung ohne SSD.

Noch ne Frage zu den Prüfsummen: sind diese per default aktiviert oder müssen die extra aktiviert werden?
 
Es gibt ein schönes Tool namens arcstat mit dem man angezeigt bekommt, welcher Prozentsatz der Lesevorgänge aus dem RAM Cache (oder dem SSD Cache erfolgt). Damit kann man entscheiden ob eine SSD was bringt. Das kann sehr effektiv sein wenn mehr RAM nicht geht.

Prüfsummen auf Daten und Metadaten sind bei ZFS per default aktiviert .
 
Hallo Gea,

ich habe heute die VM von Dir napp-it_13b_vm_for_ESXi_5.0-5.5.zip auf die neue Version 0.9f1 updaten wollen.
Während des Updates über die Weboberfläche erhalte ich folgende Fehlermeldung

Code:
Can't locate UUID/Tiny.pm in @INC (@INC contains: /var/web-gui/data/napp-it/CGI /usr/perl5/site_perl/5.16.1/i86pc-solaris-thread-multi-64int /usr/perl5/site_perl/5.16.1 /usr/perl5/vendor_perl/5.16.1/i86pc-solaris-thread-multi-64int /usr/perl5/vendor_perl/5.16.1 /usr/perl5/5.16.1/lib/i86pc-solaris-thread-multi-64int /usr/perl5/5.16.1/lib .) at admin.pl line 707.
BEGIN failed--compilation aborted at admin.pl line 707.

anschließend geht die Weboberfläche nicht mehr. Ein Versuch einer Neuinstallation der Defaultversion per wget brachte keine Fehlermeldungen, die Weboberfläche ist aber weiterhin nicht mehr erreichbar.

Was könnte ich noch tun? Kann ich die Config über die Kommandozeile sichern (wegen der ganzen Jobs)? Dann würde ich eine neue VM erstellen mit Deiner fertigen VM, Config zurückspielen und alles wird gut? Ich repliziere zw. zwei Appliances und wenn ich die Jobs neu erstellen müsste, hätten die Jobs neue IDs und ich müsste alle Replikationen wegschmeißen.

Gruß Millenniumpilot
 
Einen Snapshot der VM hast du vorher vermutlich nicht angelegt? Hast du eventuell einen älteren, der auch hinreichend ist?
 
Hallo Gea,

ich habe heute die VM von Dir napp-it_13b_vm_for_ESXi_5.0-5.5.zip auf die neue Version 0.9f1 updaten wollen.
Während des Updates über die Weboberfläche erhalte ich folgende Fehlermeldung

Code:
Can't locate UUID/Tiny.pm in @INC (@INC contains: /var/web-gui/data/napp-it/CGI /usr/perl5/site_perl/5.16.1/i86pc-solaris-thread-multi-64int /usr/perl5/site_perl/5.16.1 /usr/perl5/vendor_perl/5.16.1/i86pc-solaris-thread-multi-64int /usr/perl5/vendor_perl/5.16.1 /usr/perl5/5.16.1/lib/i86pc-solaris-thread-multi-64int /usr/perl5/5.16.1/lib .) at admin.pl line 707.
BEGIN failed--compilation aborted at admin.pl line 707.

Tiny.pm ist ein Relikt von netatalk2 und wird nicht mehr benötigt, macht aber bei bestimmten Updatekonstellationen Probleme. Jetzt entweder das Update per wget wiederholen oder in der admin.pl in der Zeile 707 am Anfang der Zeile ein Kommentarzeichen # einfügen.
 
Hallo Gea,

habe zeile 707 ausgeremt, danach kommt die nächste Fehlermeldung:
Code:
Software error:
(lib-561 read_dir: /) Programmfehler: Es wurde kein Verzeichnis angegeben (ref 722) at /var/web-gui/data/wwwroot/cgi-bin/admin-lib.pl line 419.


For help, please send mail to this site's webmaster, giving this error message and the time and date of the error. 
[Sat May 3 20:08:58 2014] admin.pl: (lib-561 read_dir: /) Programmfehler: Es wurde kein Verzeichnis angegeben (ref 722) at /var/web-gui/data/wwwroot/cgi-bin/admin-lib.pl line 419.


edit: habe wohl die falsche admin.pl erwischt. Mit einer anderen geht's jetzt. Da soll einer durchsehen bei den vielen Ordnern ;-)
 
Zuletzt bearbeitet:
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