[Sammelthread] ZFS Stammtisch

[gea]

Frage an gea: Ich bin die Tage von 0.9e1 auf 0.9f1 gegangen (free), triviale ACLs sind jetzt nicht mehr setzbar. Ist das ein Feature?

ACL können in napp-it free jederzeit über /usr/bin/chmod oder als root per Windows gesetzt werden.
Die ACL extension bietet das in der free Version nicht mehr. Dafür gibt es jetzt günstige Home Lizenzen.

 

[Bzzz]

Erst Kontaktdaten angeben, bevor man überhaupt eine Preis-Größenordnung erfährt, find ich immer abschreckend, muss ich dir ganz klar sagen Betrifft sowohl private Späße, als auch geschäftliche Einkäufe, als auch alles, was ich universitär besorgen soll. Hat immer so den Geschmack von "wir stehen nicht im Wettbewerb mit anderen", teils auch "eigentlich wollen wir gar nix verkaufen und machen es deshalb so schwer wie möglich". Aber ist natürlich deine Entscheidung...du wirst da deine Gründe haben.

Glaub da werd ich kein Kunde werden, zeitbegrenzte Lizenzen kommen für mich nicht in Frage, zwei Keys brauch ich auch nicht, im Prinzip würden mir triviale ACL schon reichen (das neue Monitoring wäre nett, hab ich aber noch nicht testen können). Über die Uni könnte nur das nehmen, was ich tatsächlich brauche, kommt dann aber auch nicht wirklich billiger Heißt dann wohl Downgrade auf 9e1 und dort festnageln. Ist auch nicht weiter schwierig, die Kiste ist eh stets offline...

 

[ron2105]

Das Ergebnis von
echo "::arc" |pfexec mdb -k
wäre hilfreicher.

cu

... stimmt natürlich.
Auszug:
.
.
.
p = 3839 MB
C = 4095 MB
c_min = 4095 MB
c_max = 64 MB
size = 4393 MB
.
.
arc_meta_used = 4393 MB
arc_meta_max = 4418 MB
.
Wenn ich das jetzt richtig interpretiere, werden 4 GB RAM als ARC genutzt.

 

[TCM]

Glaub da werd ich kein Kunde werden, zeitbegrenzte Lizenzen kommen für mich nicht in Frage, zwei Keys brauch ich auch nicht, im Prinzip würden mir triviale ACL schon reichen (das neue Monitoring wäre nett, hab ich aber noch nicht testen können). Über die Uni könnte nur das nehmen, was ich tatsächlich brauche, kommt dann aber auch nicht wirklich billiger Heißt dann wohl Downgrade auf 9e1 und dort festnageln. Ist auch nicht weiter schwierig, die Kiste ist eh stets offline...

Andererseits liegt ja der Source komplett vor dir...

 

[ludwinator]

... stimmt natürlich.
Auszug:
.
.
.
p = 3839 MB
C = 4095 MB
c_min = 4095 MB
c_max = 64 MB
size = 4393 MB
.
.
arc_meta_used = 4393 MB
arc_meta_max = 4418 MB
.
Wenn ich das jetzt richtig interpretiere, werden 4 GB RAM als ARC genutzt.

128GB Ram in der Kiste und arc_meta_max = 4418 MB ?
Was ist mit arc_meta_limit?
Im Illumos Source ist das normalerweise 1/4 des verfügbaren Speichers, sollte hier also irgendwas um die 32GB sein.
Irgendwas ist da faul, hast du was in /etc/system drinstehen?


cu

 

[gea]

Erst Kontaktdaten angeben, bevor man überhaupt eine Preis-Größenordnung erfährt, find ich immer abschreckend, muss ich dir ganz klar sagen

wo ist das Problem?
Preise stehen hier: napp-it // webbased ZFS NAS/SAN appliance for OmniOS, OpenIndiana, Solaris and Linux : Extensions
Ansonsten ist ACL setzen (zumindest allow Regeln) über Windows wirklich sehr einfach, dafür brauchts die Extension nicht.

Kontaktdaten werden auch nur für Angebot/ Bestellung abgefragt.

 

[Bzzz]

Andererseits liegt ja der Source komplett vor dir...

Äh...ja. Klar, ich kann jetzt Zeit investieren, geas Lizenzsystem auszuhöhlen und mein (wie gesagt Offline-) System dann illegal auf Pro zu betreiben. Vielleicht soll ich gea auch noch fragen, wo genau das steht und wo es überall reinverwurschtelt ist, spart die lästige Sucherei im vielen Code

wo ist das Problem?

Dass ich das bisher nicht gefunden habe. Über die Hauptseite ists nicht direkt links anklickbar, dort steht vor allem immer wieder das Wort "Angebot". Selbst bei den Editionen, da steht ein Preis und drunter "Angebot anfordern". Als wär das kein echter Preis, sondern muss erst von irgendner Verkaufsabteilung im großen gea-Konzern ausgewürfelt werden, welchen echten Preis man mir machen kann, basierend auf Bestellmenge, Bonität und ob meine Nase krumm ist. Von den Homelizenzen steht da gar nichts, und wenn, dann sind die ja für mich interessant.
Auf der Extensions-Seite ist wieder nur "Angebot" verlinkt, die Preisseite ist genau die, die standardmäßig mit diesem Frameset geöffnet wird. Über nen Menüpunkt links kommt man da auch wieder nicht zurück. Der Anfang liest sich so, als wärs halt ein allgemeiner Überblick, aber dass weiter unten Preise im Fließtext stehen (man bemerke auch den zweiten Satz: "Wollen Sie Extensions bestellen, so fordern Sie bitte ein Angebot an.")...ja, kann man sehen, wenn man sich Sachen durchlesen möchte, die man eh schon weiß. Einen Link "Hier steht, was es kostet" suche ich auf der ganzen Seite vergeblich. Obwohl das eigentlich machbar wäre, denn offenbar stehts ja da, nur an einer etwas versteckten Stelle. Mach doch nen Anker in den Text rein und linke darauf, dann passt das schon.

Ansonsten ist ACL setzen (zumindest allow Regeln) über Windows wirklich sehr einfach, dafür brauchts die Extension nicht.

Hab ich aber nicht. Nur ne immer offene Konsole, mit der ich mich zum Unlocken des verschlüsselten ZFS ohnehin per SSH einlogge

 

[gea]

Einen Link "Hier steht, was es kostet" suche ich auf der ganzen Seite vergeblich. Obwohl das eigentlich machbar wäre, denn offenbar stehts ja da, nur an einer etwas versteckten Stelle. Mach doch nen Anker in den Text rein und linke darauf, dann passt das schon.

Anregung umgesetzt und am Seitenanfang als Link/Anker verlinkt.
napp-it // webbased ZFS NAS/SAN appliance for OmniOS, OpenIndiana, Solaris and Linux : Extensions

 

[ron2105]

128GB Ram in der Kiste und arc_meta_max = 4418 MB ?
Was ist mit arc_meta_limit?
Im Illumos Source ist das normalerweise 1/4 des verfügbaren Speichers, sollte hier also irgendwas um die 32GB sein.
Irgendwas ist da faul, hast du was in /etc/system drinstehen?


cu

arc_meta_limit = 16 MB

sehr eigenartig! Ist aber wie gesagt das LiveSystem (boot von der CD), also keine Änderung in den Systemeinstellungen.
Ich würde natürlich gerne über 100 GB als ARC verwenden.

 

[ludwinator]

arc_meta_limit = 16 MB

sehr eigenartig! Ist aber wie gesagt das LiveSystem (boot von der CD), also keine Änderung in den Systemeinstellungen.
Ich würde natürlich gerne über 100 GB als ARC verwenden.

16GB würd ja noch gehen, aber 16MB?
Wenn du nix anderes booten kannst, dann musst du das Limit eben zur Laufzeit erhöhen. Siehe ZFS Evil Tuning Guide - Siwiki

cu

 

[TCM]

Äh...ja. Klar, ich kann jetzt Zeit investieren, geas Lizenzsystem auszuhöhlen und mein (wie gesagt Offline-) System dann illegal auf Pro zu betreiben. Vielleicht soll ich gea auch noch fragen, wo genau das steht und wo es überall reinverwurschtelt ist, spart die lästige Sucherei im vielen Code

Du willst nicht dafür zahlen, dass es ein Anderer macht und du willst dir auch nicht selbst helfen. Also was willst du dann eigentlich?

 

[GrafikTreiber]

Hat er doch schon gesagt.

Ich will MA-O-AM!!

https://www.youtube.com/watch?v=lNgRBpclz3Q

Spaß beiseite. So ist das eben nun mal. Wenn du mehr Funktionen haben willst und nicht zahlen willst, wechsle halt zu FreeNAS oder passe die Sourcen von napp-it an. Oder lerne die Konsole zu benutzen, dann brauchst du auch kein Webinterface mehr.

 

[ron2105]

16GB würd ja noch gehen, aber 16MB?
Wenn du nix anderes booten kannst, dann musst du das Limit eben zur Laufzeit erhöhen. Siehe ZFS Evil Tuning Guide - Siwiki

cu

Tja, ein beherztes

echo swapfs_minfree/W0t2621 | mdb -kw

hat den Zustand / die Ausgabe von

echo "::arc" |pfexec mdb -k

und damit die Geschwindigkeit auch nicht nennenswert verbessert.

 

[ludwinator]

Ja toll, was soll das für ein Parameter sein?
Du hättest dich einfach nur mit dem ARC befassen sollen: ZFS Evil Tuning Guide - Siwiki
Also:

Dynamic change via mdb

You can only change the ARC maximum size dynamically by using the mdb command.

For example, to the set the ARC parameters to small values, such as arc_c_max to 512MB, and complying with the formula above (arc.c_max to 512MB, and arc.p to 256MB), on Current Solaris Releases, use the following syntax:
# mdb -kw
> arc_stats:rint -a arcstat_p.value.ui64 arcstat_c.value.ui64 arcstat_c_max.value.ui64
ffffffffc00df578 arcstat_p.value.ui64 = 0xb75e46ff
ffffffffc00df5a8 arcstat_c.value.ui64 = 0x11f51f570
ffffffffc00df608 arcstat_c_max.value.ui64 = 0x3bb708000

> ffffffffc00df578/Z 0x10000000
arc_stats+0x500:0xb75e46ff = 0x10000000
> ffffffffc00df5a8/Z 0x20000000
arc_stats+0x530:0x11f51f570 = 0x20000000
> ffffffffc00df608/Z 0x20000000
arc_stats+0x590: 0x11f51f570 = 0x20000000


You should verify the values have been set correctly by examining them again in mdb (using the same print command in the example). You can also monitor the actual size of the ARC to ensure it has not exceeded. For example, to display the current ARC size in decimal:
# echo "arc_stats:rint -d arcstat_size.value.ui64" | mdb -k
arcstat_size.value.ui64 = 0t239910912

 

[ron2105]

Ja toll, was soll das für ein Parameter sein?
Du hättest dich einfach nur mit dem ARC befassen sollen: ZFS Evil Tuning Guide - Siwiki
Also:

Dynamic change via mdb

You can only change the ARC maximum size dynamically by using the mdb command.

For example, to the set the ARC parameters to small values, such as arc_c_max to 512MB, and complying with the formula above (arc.c_max to 512MB, and arc.p to 256MB), on Current Solaris Releases, use the following syntax:
# mdb -kw
> arc_stats:rint -a arcstat_p.value.ui64 arcstat_c.value.ui64 arcstat_c_max.value.ui64
ffffffffc00df578 arcstat_p.value.ui64 = 0xb75e46ff
ffffffffc00df5a8 arcstat_c.value.ui64 = 0x11f51f570
ffffffffc00df608 arcstat_c_max.value.ui64 = 0x3bb708000

> ffffffffc00df578/Z 0x10000000
arc_stats+0x500:0xb75e46ff = 0x10000000
> ffffffffc00df5a8/Z 0x20000000
arc_stats+0x530:0x11f51f570 = 0x20000000
> ffffffffc00df608/Z 0x20000000
arc_stats+0x590: 0x11f51f570 = 0x20000000


You should verify the values have been set correctly by examining them again in mdb (using the same print command in the example). You can also monitor the actual size of the ARC to ensure it has not exceeded. For example, to display the current ARC size in decimal:
# echo "arc_stats:rint -d arcstat_size.value.ui64" | mdb -k
arcstat_size.value.ui64 = 0t239910912

DAS war genau mein erster Zug, gefolgt von einem Absturz mit automatischem Reboot.
Danach habe ich das Livesystem nochmals gestartet und es nochmals ohne Erfolg versucht, der von mir dann ausprobierte Parameter soll die max. RAM-Reservierung für den Swap verringern, damit mehr für ARC übrigbleibt.
Da jetzt sowieso ein Reboot erfolgt ist, habe ich gleich eine Systemplatte mit eingesteckt und OI installiert, damit ist dann hoffentlich das Thema erschlagen.
Vielen Dank für die Hilfe.

 

[VLB]

Hallo,

ich hab mich nun auch mal an das Thema ZFS gewagt und einen Microserver mit OmniOS installiert.
Dabei möchte ich grundsätzlich erstmal die Administration über die Konsole machen, also auf napp-it o.Ä. verzichten.

Ich habe das Problem, dass die CIFS-Performance egal ob lesend oder schreibend nur etwa 30-40 MB/sec beträgt.
Mein Pool besteht aus 4 * 2 TB Platten als raidz1.

dd direkt auf dem Pool bzw. dem Filesystem ist mit 200 MB/sec schreibend performant genug, wie bekomme ich mein Gigabit LAN mit CIFS ausgelastet? Ich greife per Windows 7 Client darauf zu.

Edit: Der HP Microserver verfügt über 32 GB RAM.

 

[gea]

Hallo,

ich hab mich nun auch mal an das Thema ZFS gewagt und einen Microserver mit OmniOS installiert.
Dabei möchte ich grundsätzlich erstmal die Administration über die Konsole machen, also auf napp-it o.Ä. verzichten.

Ich habe das Problem, dass die CIFS-Performance egal ob lesend oder schreibend nur etwa 30-40 MB/sec beträgt.
Mein Pool besteht aus 4 * 2 TB Platten als raidz1.

dd direkt auf dem Pool bzw. dem Filesystem ist mit 200 MB/sec schreibend performant genug, wie bekomme ich mein Gigabit LAN mit CIFS ausgelastet? Ich greife per Windows 7 Client darauf zu.

Edit: Der HP Microserver verfügt über 32 GB RAM.

Ich nehme an, es ist ein Microserver G8 mit BroadCom:
Auf Serverseite ist zwar die BroadCom für Solaris nicht ganz optimal und nicht so empfehlenswert wie eine Intel Netzwerkkarte, es sollte aber etwas mehr möglich sein (wobei die 200 MB/s local bei 3 Datenplatten darauf schließen lassen, dass es nicht die schnellsten sind da das auch wenigen als 70 MB/s pro Platte sind).


Ich würde mich zuerst auf die Win7 Maschine konzentrieren. Probleme dort sind meistens:
- Copy Tools z.B. Teracopy (deinstallieren)
- Realtek Netzwerkkarten bzw nicht ganz aktuelle Realtek Treiber (wenn möglich eine Intel vergleichen)

Eventuell noch Verkabelung/ Netz testen

 

[VLB]

Es ist ein G7 Microserver N40L mit nur 16 GB RAM (hab mich vertan). Die Platten sind nicht die schnellsten, WD20EURS, die hatte ich zum Testen noch herumliegen.

Mittlerweile hab ich auch auf der Windows 7-Seite etwas herumprobiert, da ist ein RTL8168C(P)/8111C(P) als Netzwerkchip in Verwendung.
Der Switch ist ein HP ProCurve 1810G-24.

Auf einen W2012R2 Server schreibt dieser Rechner mit etwa 80 MB/sec.
Wenn ich mit OmniOS auf diesen Wert kommen würde... das wäre klasse!

- - - Updated - - -

So, ich hab an Windows 7 den neuesten Treiber installiert, der rein gar nichts am Problem geändert hat. So langsam gehen mir die Ideen aus.

- - - Updated - - -

Es wird auch nicht viel besser, wenn ich den Pool als reines Stripeset aufsetze.

 

[GrafikTreiber]

Falls wir hier mal wieder Hirnies haben die Häufigkeit von Silent Data Corruption anzweifeln habe ich hier mal was Schönes:

Over 41 months, 400K+ instances of silent data corruption on 1.53 million disk drives

Money-Quote:

The paper “An Analysis of Data Corruption in the Storage Stack” from the University of Wisconsin (based on NetApp data) [3] shows that “nearline” disks (IE any disks I can afford) have an incidence of checksum errors (occasions when the disk returns bad data but claims it to be good) of about 0.42%

 

[VLB]

Mein Problem habe ich lösen können - am Client.

Hauptsächlich lag es an Directory Opus, welches angeblich die Routinen des Windows-Explorers verwendet, aber trotzdem viel langsamer als dieser ist.

Der Windows-Explorer schreibt mit > 100 MB/s auf das CIFS-Share. Nachdem ich in Directory Opus den copybuffer auf 512KB rauf gesetzt habe, erreicht DOpus > 80 MB/s. Das ist ein Wert, mit dem ich vorerst leben kann. Ich werde diesbezüglich aber den Support von DOpus kontaktieren.

 

[Fischje]

Hallo, ich hoffe ich bin hier richtig in diesem Thread.

Ich suche eine möglichkeit einen kleinen backup-server zu basteln. darauf soll einmal die woche all mein datenbestand gesichert werden (am besten inkrementell).

dafür zur verfügung habe ich noch einen AMD Athlon X4 640 und ein MSI 890GXM-G65 - AM3+ Mainboard. Ich benötige noch Arbeitsspeicher und möchte gerne alle noch gut erhaltenen und herumliegenden Platten per SATA an das Board anschliessen und durch ZFS einen BackupSpace , einmal die Woche, für meinen Server bereitstellen.

Dazu überlege ich einmal was ich noch an Ram benötige. Habe vor 6 Platten unterschiedlicher Größe, von 160GB bis 3 TB anzuschliessen und bei bedarf größere einzubinden, je nachdem was mal abfällt und ich haben kann. Daten werden ungefähr 3-4 TB anfallen. Eine Verschlüsselung habe ich nicht geplant, da alles nur intern im Netzwerk passieren soll.

Zweitens überlege ich welches OS ich nutzen könnte/sollte für mein ZFS-Storage. Ich bin eigentlich nicht sehr versiert. Habe mir jetzt mal FreeNAS angeschaut, ich glaube das wäre einfacher von der Bedienung für meine Zwecke, habe aber auch ein Auge auf napp-it geworfen. Da bekäm ich die installation mit OmniOS auch hin glaube ich. Die Frage ist halt, ob ich mit FreeNAS nicht auch auskomme...

Auf das Backup zugreifen müsste eigentlich nur eine XPEnology VM. Wie wiess ich nocht nicht. Vielleicht rsync, oder einfach nur als FTP. Der Server soll halt nur einmal die Woche an und dann soll darauf das Backup und dann soll der wieder aus Halt einfach ein Backup.

VG Fischje

 

[Bzzz]

Falls wir hier mal wieder Hirnies haben die Häufigkeit von Silent Data Corruption anzweifeln habe ich hier mal was Schönes:

Over 41 months, 400K+ instances of silent data corruption on 1.53 million disk drives

Geht wahrscheinlich weit ins OT, wenn man die dortigen Quellen mal durchgeht...ich schneids mal an, ggf. können wir ja auslagern.

[3] The ADvanced Systems Laboratory (ADSL): Abstract

Datensatz von 2004 (Januar + 41 Monate), also uralt. Weiterhin schade, dass die Plattenfamilien, -hersteller, -größen anonymisiert sind, aber das ist wohl Teil des Deals, an solche Daten zu kommen. Drittens ist da SATA grade erst so losgeschwommen, während die ersten Fibrechannelsachen wohl seit 1997 zu haben sind, also zur Zeit der Datennahme keine allzu garstigen Kinderkrankheiten mehr hatten. Das macht zwar auf Platterebene keinen Unterschied, wohl aber bei der Interface-Elektronik und den Kabeln. Siehe nächste Studie.
Interessante Häppchen:

Observation 5 There is no clear indication that workload affects the probability of developing checksum mismatches.

Anzahl der Datenblöcke mit unpassender Checksumme hintendran ist also unabhängig von der (Schreib-)Last des Laufwerks. Die Platter stört intensive Nutzung also nicht, wenn ein Laufwerk durch sowas kaputtgeht, dann eher durch Mechanikdefekte und Abrieb, der zu mechanischen Platterschäden führt.

Observation 2 The probability of developing checksum mismatches varies significantly across different disk models within the same disk class.

Observation 3 Age affects different disk models differently with respect to the probability of developing checksum mismatches.

Observation 6 The number of checksum mismatches per corrupt disk varies greatly across disks. Most corrupt disks develop only a few mismatches each. However, a few disks develop a large number of mismatches.

Auf Deutsch: Der eine Hersteller kann das gut, versagt aber in der anderen Disziplin, beim nächsten Hersteller ists genau andersrum, und beim Generationswechsel wird neu gewürfelt. Ah, und jedes Werk produziert natürlich Kram mit eigenen Stärken und Schwächen, also kann man einfach blind einkaufen.

Observation 7 On average, corrupt enterprise class disks develop many more checksum mismatches than corrupt nearline disks.

Enterpriselaufwerke machen seltener Probleme, aber wenn, dann gleich richtig.

Observation 16 Data scrubbing discovers a large percentage of the checksum mismatches for many of the disk models.

GrafikTreibers eigentliche Moneyquote...

Observation 17 RAID reconstruction encounters a non-negligible number of checksum mismatches.

• A significant number (8% on average) of corruptions are detected during RAID reconstruction, creating the possibility of data loss. In this case, protection against double disk failures [1, 4, 5, 9, 10, 12] is necessary to prevent data loss.

Das hieße ja, dass es mit den Minikapazitäten von 2004 und den wohl eine Größenordnung schlechteren Bitfehlerraten schon jedes zwölfte RAID5 beim Rebuild (also durch Doppelfehler) zersägt hätte? Na ich weiß ja nicht.

• Some block numbers are much more likely to be affected by corruption than others, potentially due to hardware or firmware bugs that affect specific sets of block numbers. RAID system designers might be well advised to use staggered stripes such that the blocks that form the stripe are not stored at the same or nearby block number.

Echter Spiegel mit 1:1 abgelegten Datenblöcken: Saudumme Idee, weil in den besonders gefährdeten Arealen auch noch genau die gleichen Daten liegen?

[11]: CiteSeerX — Are Disks the Dominant Contributor for Storage Failures? A Comprehensive Study of Storage Subsystem Failure Characteristics
Basiert auf nem sehr ähnlichen Datensatz, große Überschneidungen zum obigen Paper.

Table 1, Ausfallzahlen
Near-Line: 520776 Disks, 10105x Disk Fail, 4888x Interconnect, 1819x Protokoll, 1080x Performance
Low-End: 264983 Disks, 3230x Disk Fail, 4388x Interconnect, 1021x Protokoll, 1235x Performance
Mid-Range: 578980 Disks, 8989x Disk Fail, 7949x Interconnect (teils Dual-Path), 2298x Protokoll, 2060x Performance
High-End: 454684 Disks, 8240x Disk Fail, 7395x Interconnect (teils Dual-Path), 1576x Protokoll, 153x Performance

Runtergerechnet auf 100k Disks sind das:
Near-Line: 1940 / 939 / 349 / 207, Summe 3435
Low-End: 1219 / 1637 / 385 / 466, Summe 3707
Mid-Range: 1553 / 1373 / 397 / 356, Summe 3679
High-End: 1840 / 1626 / 347 / 34, Summe 3847

Irre! Da wüsst ich auch gern mal die Preis- und Performancesteigerung zwischen diesen vier Gruppen...

Finding (2): For disks, near-line storage systems show higher (1.9%) AFR than low-end storage systems (0.9%). But for the whole storage subsystem, near-line storage systems show lower (3.4%) AFR than low-end storage systems (4.6%).
Implications: Disk failure rate is not indicative of the storage subsystem failure rate.

Oder: Was Enterpriselaufwerke durch höhere Zuverlässigkeit gewinnen, verlieren sie durch höhere Komplexität an fetten Controllern, Backplanes, diesem ganzen FC-Gedöns inklusive redundanter Verkabelung, ... - unterm Strich fallen alle Systeme gleich häufig aus, die Preisleistung ist nur jeweils ne andere.

Finding (7): Storage subsystems configured with network redundancy mechanisms experience much lower (30-40% lower) AFR than other systems. AFR for physical interconnects is reduced by 50-60%.
Implications: Network redundancy mechanisms such as multipathing can greatly improve the reliability of storage subsystems.
[...]
However, the observation also tells us that there is still further potential in network redundancy mechanism designs. For example, given that the probability for one network to fail is about 2%, the idealized probability for two networks to both fail should be a few magnitudes lower (about 0.04%). But the AFR we observe is far from the ideal number.

Kann ich nicht aus der obigen Tabelle rauslesen, denn selbst wenn die gemischt ist, müssten die besser angebundenen Laufwerke ja was rausreißen. Und überhaupt, mal auf die heutige Situation mit Dualport-SAS bezogen: Ist ja toll, wenn man eine Festplatte doppelt anbinden kann, aber um damit wirklich was zu gewinnen, muss man das hard- und softwaretechnisch richtig machen. Wird als Finding (9) verkauft...

 

[dapc]

Hallo Zusammen,

ich habe jetzt schon seit gut einem Jahr einen kleinen ZFS-Backup-Server bei mir rumstehen. Mein Hauptserver mit Hyper-V läuft aktuell noch komplett ohne pooling oder der gleichen. Bin also gerade am überlegen, ob ich das ändern will und auch zusätzlich hier auf zfs umsteigen will.
Da ich aber aktuell Hyper-V nütze und behalten will (bitte hier nicht die vor und Nachteile diskutieren), würde mich mal interessieren, was dagegen spricht, ein BSD (z.B. NAS4Free) auf eine VM zu installieren und die Platten einzeln durchreiche. Ich weiß, dass dies nur über die Treiber geschieht und ich habe auch gelesen, dass man dies nicht mit ZFS kombinieren soll. Mich würde interessieren, wieso dies so ist. Oder bin ich da komplett auf den Holzweg?

Danke schon mal

 

[gea]

Ich vermute mal, das Hauptproblem ist, dass es da nicht soviel Erfahrungswerte gibt.
Meine Einschätzung:

In den BSD Foren wird von Storage-Virtualisierung mit BSD abgeraten.
Ich sehe da aber kein grundsätzliches Problem.

Storage Virtualisierung unter Solaris/OmniOS etc ist gang und gäbe
ich mache das seit Jahren. Patrick von servethehome.com hat eine Installaion
von Hyper-V mit OmniOS als ZFS Storage und hat keine Probleme.

Es ist nicht ganz optimal, da Hyper-V die Platten nicht direkt durchreicht sondern
nur als "virtual disk"

Die Alternative1 wäre ReFS. Das ist ZFS light (hat CopyOnWrite und Prüfsummen;
deutlich langsamer, nicht soviel Features, nicht so ausgereift)

Die Alternative 2 wäre: ZFS Storage und iSCSI


Insgesamt würde ich sagen: Probieren - Gute Chance dass es gut geht.

 

[dapc]

Ok, ich werde das ganze dann doch mal probieren, wenn ich das WE Zeit finde.
Wie meinst du das mit virtual disk? Ich kann ja im Host die Platten abmelden und dann durchreichen. Das ist zwar nur per Treiber, aber dafür komplett, also ohne virtual disk. Oder reden wir jetzt beieinander vorbei?
ReFS will ich nicht, da zu langsam, und extra SSDs will ich auch nicht kaufen.
Ein externen ZFS-Storage will ich nicht, dann habe ich noch einen Server rumstehen.

Also läuft OmniOs unter Hyper-V? Dann sollte auch dein napp-it laufen, oder?

 

[LichtiF]

Also ich habe schon öfters gelesen das Leute unter Hyper-V Linux + ZFS benutzen das soll wohl auch ganz gut funktionieren.

Ubuntu 14.04 geht sogar als Gen 2 VM

 

[gea]

Ok, ich werde das ganze dann doch mal probieren, wenn ich das WE Zeit finde.
Wie meinst du das mit virtual disk? Ich kann ja im Host die Platten abmelden und dann durchreichen. Das ist zwar nur per Treiber, aber dafür komplett, also ohne virtual disk. Oder reden wir jetzt beieinander vorbei?
ReFS will ich nicht, da zu langsam, und extra SSDs will ich auch nicht kaufen.
Ein externen ZFS-Storage will ich nicht, dann habe ich noch einen Server rumstehen.

Also läuft OmniOs unter Hyper-V? Dann sollte auch dein napp-it laufen, oder?

Hyper-V kennt kein echtes Hardware-Passthrough wie ESXi, die Platten laufen daher immer über den Windows-Treiber.
Die Platte sollten aber als Pass-through Disk und nicht als VHD virtual Disk konfiguriert werden.
Dann erwarte ich keine (Performance-)probleme mit OmniOS (Auch wenn ich das selber noch nicht probiert habe).

 

[AG1M]

Hat sich jemand schon einmal NexentaStor 4.0.2 Community Edition probiert? Habe es aktuell zum testen auf meiner ESXi VM schaut garnicht schlecht aus auf den ersten Blick. Würde es theoretisch klappen wenn ich meinen OmniOS ZFS Pool exportiere und den dann bei NexentaStor importiere? Sind ja beide auf illumos Basis die Pools oder?

 

[GrafikTreiber]

Weil ein Kunde gerne ein "Webinterface fürs Storagele" (Originalzitat des Kunden) haben wollte habe ich habe nun mal napp-it for Linux auf einem Debian Fileserver (Kernel Linux 3.13-0.bpo.1-amd64 3.13.7-1~bpo70+1 (2014-03-29) x86_64) ausprobiert, ein Apache lief bereits darauf, daran scheiterte der Installer dann auch mehr oder weniger , der mini-httpd wurde dann zwar auf Port 3000 gestartet, bis auf initialize websocket connection, please wait" kam dann aber nichts. Auch mehrmaliges Ausführen des Installers half nicht.
Darauf hin habe ich den Port in der /etc/mini-httpd.conf auf 3000 geändert und napp-it manuell gestoppt und dann neugestartet, danach konnte ich mich einloggen.

1 root@server ~ # /etc/init.d/napp-it start
Starting web server: bind: Address already in use
mini-httpd.
/usr/sbin/mini-httpd: started as root without requesting chroot(), warning only
perl /var/web-gui/data/napp-it/zfsos/_lib/scripts/agent-bootinit.pl                                                                                                                                                                                                           
root@server ~ # Undefined subroutine &Carp::shortmess_heavy called at /var/web-gui/data/napp-it/CGI/Carp.pm line 182.

1 root@server ~ # rm: cannot remove `/tmp/nappit/*.htm': No such file or directory                                                                                                                                                                                       :(
rm: cannot remove `/tmp/nappit/socket-basic-stat_minute.*': No such file or directory
/var/web-gui/data/napp-it/zfsos/_lib/scripts/taskserver.sh: line 17: 14000 Killed                  nice /usr/bin/perl /var/web-gui/data/napp-it/zfsos/_lib/scripts/taskexec.pl $F
/var/web-gui/data/napp-it/zfsos/_lib/scripts/taskserver.sh: line 17: 14102 Killed                  nice /usr/bin/perl /var/web-gui/data/napp-it/zfsos/_lib/scripts/taskexec.pl $F
/var/web-gui/data/napp-it/zfsos/_lib/scripts/taskserver.sh: line 17: 14331 Killed                  nice /usr/bin/perl /var/web-gui/data/napp-it/zfsos/_lib/scripts/taskexec.pl $F
/var/web-gui/data/napp-it/zfsos/_lib/scripts/taskserver.sh: line 17: 14461 Killed                  nice /usr/bin/perl /var/web-gui/data/napp-it/zfsos/_lib/scripts/taskexec.pl $F
/var/web-gui/data/napp-it/zfsos/_lib/scripts/taskserver.sh: line 17: 14582 Killed                  nice /usr/bin/perl /var/web-gui/data/napp-it/zfsos/_lib/scripts/taskexec.pl $F
/var/web-gui/data/napp-it/zfsos/_lib/scripts/taskserver.sh: line 17: 14654 Killed                  nice /usr/bin/perl /var/web-gui/data/napp-it/zfsos/_lib/scripts/taskexec.pl $F
/var/web-gui/data/napp-it/zfsos/_lib/scripts/taskserver.sh: line 17: 14851 Killed                  nice /usr/bin/perl /var/web-gui/data/napp-it/zfsos/_lib/scripts/taskexec.pl $F
rm: cannot remove `/tmp/nappit/*.htm': No such file or directory
rm: cannot remove `/tmp/nappit/socket-basic-stat_minute.*': No such file or directory

1 root@server ~ # /var/web-gui/data/napp-it/zfsos/_lib/scripts/taskserver.sh: line 17: 17426 Killed                  nice /usr/bin/perl /var/web-gui/data/napp-it/zfsos/_lib/scripts/taskexec.pl $F                                                                      :(
/var/web-gui/data/napp-it/zfsos/_lib/scripts/taskserver.sh: line 17: 17671 Killed                  nice /usr/bin/perl /var/web-gui/data/napp-it/zfsos/_lib/scripts/taskexec.pl $F
/var/web-gui/data/napp-it/zfsos/_lib/scripts/taskserver.sh: line 17: 17756 Killed                  nice /usr/bin/perl /var/web-gui/data/napp-it/zfsos/_lib/scripts/taskexec.pl $F
/var/web-gui/data/napp-it/zfsos/_lib/scripts/taskserver.sh: line 17: 17918 Killed                  nice /usr/bin/perl /var/web-gui/data/napp-it/zfsos/_lib/scripts/taskexec.pl $F
/var/web-gui/data/napp-it/zfsos/_lib/scripts/taskserver.sh: line 17: 18081 Killed                  nice /usr/bin/perl /var/web-gui/data/napp-it/zfsos/_lib/scripts/taskexec.pl $F
/var/web-gui/data/napp-it/zfsos/_lib/scripts/taskserver.sh: line 17: 18206 Killed                  nice /usr/bin/perl /var/web-gui/data/napp-it/zfsos/_lib/scripts/taskexec.pl $F
/var/web-gui/data/napp-it/zfsos/_lib/scripts/taskserver.sh: line 17: 18472 Killed                  nice /usr/bin/perl /var/web-gui/data/napp-it/zfsos/_lib/scripts/taskexec.pl $F
rm: cannot remove `/tmp/nappit/*.htm': No such file or directory

"/usr/sbin/mini-httpd: started as root without requesting chroot(), warning only" ist ziemlich unschön.
Restliche Ausgaben mal zum Debugging.

Dann Webmenü zeigt mir "websocket server: missing", habe mal etwas rumgeklickt aber nichts konkret ausprobiert aufgrund der zahlreichen unschönen Meldungen.

Hab den Service jetzt erst mal wieder deaktiviert, mag meine Konsole nicht alle paar Minuten vollgespammt zu bekommen.

Falls du noch irgendwelche Infos brauchst, sag mir Bescheid. Ich sage dem Kunden erst mal "ist noch nicht fertig".

 

[gea]

1 root@server ~ # /etc/init.d/napp-it start

/usr/sbin/mini-httpd: started as root without requesting chroot(), warning only

Das ist die normale Startmeldung wenn minihttpd durch root gestartet wird
mini-httpd läuft dann unter dem napp-it account auf port 81

Das passiert beim Booten per init script.
Manuell stop/start ist aber ok - aber den Port auf 81 lassen


Insgesamt sieht es unter Linux folgendermassen aus.
Napp-it besteht aus drei Modulen

1. Basisfunktionalität (Web-GUI über minhttpd als CGI Anwendung, Start mit http://ip:81)
Das bedeutet ZFS-, Share, Snap- und Raidmanagement, Jobs wie autosnap und Replikation

Port 81 darf nicht z.B. von Apache belegt sein
Napp-it läuft dann unter Linux bis auf Solaris spezifische Sachen wie Comstar


2. Hintergrunddienste wie GUI Beschleunigung oder Echtzeit IO Monitoring
Das ist nur telweise von Solaris zu Linux umgesetzt.


3. Websocket Echtzeitfunktionen
Dazu läuft der Mojolicious html5 Websocketserver auf Port 3000. Er wird nur
für die Echtzeit-Funktionen benutzt - nicht für die Web-GUI
Das ist nur telweise von Solaris zu Linux umgesetzt. Es wird zudem Perl ab 5.10.1
benötigt. Das scheint nicht der Fall zu sein, daher die Carp Fehlermeldung.


Insgesamt laufen Hintergrunddienste als root, das napp-it ZFS Management auch
per sudo. Alle Meldungen landen damit auf der Root Console. Die meisten
unterdrücke ich, aber nicht alle damit ich den Ablauf besser kontrollieren kann.


Wann ich dazu komme 2. und 3. weiter auf Linux umzusetzen/ anzupassen kann ich
nicht sagen, ist halt zeitinsentiv. Meine eigene Installation ist Solaris/ OmniOS,
Linux Anpassungen sind deshalb eher auf die Grundfunktionalität beschränkt.