Super für snapshot backup jobs...kaputt gehen kann es besser, aber man hat ja die snapshots Ich hab mal ne Frage 
Ich hab in einen Server (Supermicro X9SCM-F) gerade einen LSI-9208-8i (IT-FW) für künftige ZFS Nutzung eingebaut. Daran hängen 6 1TB SAS 2 Platten (Seagate Constellation ES 3,5" 7.2k), eingebaut in 2 Vierer-Backplanes (Chenbro 84h210710-089). Diese wollte ich nun mit DBAN ein mal komplett nullen. Beim ersten Versuch hab ich gleich nach dem Start bemerkt, dass 3 Platten mit ~120-140MB/Sek gelöscht werden, die anderen drei dümpelten aber nur bei 16-20MB/Sek rum. Ich habe dann ein paar Einzeltests durchgeführt und einzelne Platten auch in unterschiedliche Plätzen der beiden Backplanes gesteckt und jeweils mit DBAN eine zeitlang "nullen" lassen. Hierbei lief eigentlich jede Platte mit FullSpeed (~140MB/Sek.). Ich habe dann wieder alle Platten zurück gesteckt an ihre ursprünglichen Plätze und DBAN erneut gestartet. Jetzt liefen zuerst alle mit FullSpeed. Nach ~10 Minuten ging eine zurück auf ~20MB, nach weiteren 10 Minuten ging eine weitere zurück auf ~20MB und kurze Zeit später eine Dritte. Komischweise dieses mal aber an deren Steckplätzen wie beim ersten mal. Zwischendurch gingen die drei langsamen auch mal wider kurzzeitig hoch auf die normale Geschwindigkeit, sackten dann aber wieder ab. Die drei schnellen hingegen gingen nie zurück. Aktuell sind die drei schnellen bei 74%, eine auf 11%, eine auf 14% und eine auf 25%.
Ich denk ja mal das solche Schwankungen nicht normal sind. Hat jemand eine Idee wie dieses Phänomen Zustande kommt?
Ich hab in einen Server (Supermicro X9SCM-F) gerade einen LSI-9208-8i (IT-FW) für künftige ZFS Nutzung eingebaut. Daran hängen 6 1TB SAS 2 Platten (Seagate Constellation ES 3,5" 7.2k), eingebaut in 2 Vierer-Backplanes (Chenbro 84h210710-089). Diese wollte ich nun mit DBAN ein mal komplett nullen. Beim ersten Versuch hab ich gleich nach dem Start bemerkt, dass 3 Platten mit ~120-140MB/Sek gelöscht werden, die anderen drei dümpelten aber nur bei 16-20MB/Sek rum. Ich habe dann ein paar Einzeltests durchgeführt und einzelne Platten auch in unterschiedliche Plätzen der beiden Backplanes gesteckt und jeweils mit DBAN eine zeitlang "nullen" lassen. Hierbei lief eigentlich jede Platte mit FullSpeed (~140MB/Sek.). Ich habe dann wieder alle Platten zurück gesteckt an ihre ursprünglichen Plätze und DBAN erneut gestartet. Jetzt liefen zuerst alle mit FullSpeed. Nach ~10 Minuten ging eine zurück auf ~20MB, nach weiteren 10 Minuten ging eine weitere zurück auf ~20MB und kurze Zeit später eine Dritte. Komischweise dieses mal aber an deren Steckplätzen wie beim ersten mal. Zwischendurch gingen die drei langsamen auch mal wider kurzzeitig hoch auf die normale Geschwindigkeit, sackten dann aber wieder ab. Die drei schnellen hingegen gingen nie zurück. Aktuell sind die drei schnellen bei 74%, eine auf 11%, eine auf 14% und eine auf 25%.
Ich denk ja mal das solche Schwankungen nicht normal sind. Hat jemand eine Idee wie dieses Phänomen Zustande kommt?
Fusseltuch
Enthusiast
https://www.phoronix.com/scan.php?page=news_item&px=Oracle-Solaris-Demise-Rumors
Was könnte das konkret bedeuten? Nichts genaues weiß man nicht.
Was könnte das konkret bedeuten? Nichts genaues weiß man nicht.
Dazu gibt es weitere Quellen, die ähnliches verlauten lassen.
Oracle ist eine Datenbankfirma.
Die haben mit Storage und Betriebssystemen nicht wirklich was am Hut. Vor ein paar Jahren war Solaris mit vielen Features noch himmelweit sicherer, schneller oder einfacher als andere X Alternativen oder Windows und in der Integration der Features eher wie Apple oder Windows, eben alles aus einer Hand. Solaris und die Sun Storagehardware waren da für Oracle wohl eine sinnvolle Ergänzung. Vielleicht wollten die auch nur verhindern, dass jemand anderes Sun kauft.
In der Zwischenzeit sind die Vorteile bis auf die bessere Integration nicht mehr so groß zumal es mit OpenZFS ja ZFS für alle gibt. Für Oracle lohnt sich eine eigene Storagehardware mit Solaris wohl immer weniger, zumal deren Engagement in diesem Bereich sagen wir mal sehr überschaubar ist. Die einzig wichtige Neuerung bei Solaris in der Zeit bei Oracle war denn auch SMB 2.1, sequentielles Resilvering und LZ4 Komprimierung sowie ein optimierteres Dedup. Dies war bei Illumos, dem freien Solaris Fork teils schneller oder genausoschnell dabei. Fehlendes wie ZFS Verschlüssellung oder sequentielles Resilvering wird bei OpenZFS gerade entwickelt. Im Moment ist Solaris aber noch etwas schneller mit ZFS als alle anderen.
Wenn Oracle Solaris einstellt, sehe ich
- mit einer hohen Wahrscheinlichkeit verkauft Oracle Solaris, Dann kann es nur besser werden sofern die neue Firma was mit Servern und Storage zu tun hat. Dass es wie bei Adobe läuft, dass Konkurrenten gekauft und eingestampft werden ist eher unwahrscheinlich. Eventuell gibt es ja wieder eine Zusammenarbeit zwischen Solaris und dem freien Fork Illumos. ZFS würde davon sehr profitieren. Teure Doppelentwicklungen wie derzeit wären dann auch nicht mehr nötig.
- eventuell gehen die verbliebenen Solaris und ZFS Entwickler zu OpenZFS/ Illumos. Da sind ja schon sehr viele bei der Übernahme von Sun gelandet.
Für OpenZFS/ Illumos hätte das eigentlich nur imagemäßig Relevanz. Von der technischen Entwicklung gab es eh keinerlei Unterstützung von Oracle für OpenZFS oder das freie Solaris/ Illumos seit OpenSolaris geschlossen wurde. Beide entwickeln sich ohne Oracle prächtig. Lediglich in der Dokumentation müsste sich da was verbessern. Bisher war die Oracle/ Sun Dokumentation um Klassen besser wie alles andere.
Ich sehe das auch bei meinem Napp-it, Nur ganz wenige (meist aus dem öffentlichen Bereich in USA oder im Edu Bereich) nutzen das mit Oracle Solaris.
Oracle ist eine Datenbankfirma.
Die haben mit Storage und Betriebssystemen nicht wirklich was am Hut. Vor ein paar Jahren war Solaris mit vielen Features noch himmelweit sicherer, schneller oder einfacher als andere X Alternativen oder Windows und in der Integration der Features eher wie Apple oder Windows, eben alles aus einer Hand. Solaris und die Sun Storagehardware waren da für Oracle wohl eine sinnvolle Ergänzung. Vielleicht wollten die auch nur verhindern, dass jemand anderes Sun kauft.
In der Zwischenzeit sind die Vorteile bis auf die bessere Integration nicht mehr so groß zumal es mit OpenZFS ja ZFS für alle gibt. Für Oracle lohnt sich eine eigene Storagehardware mit Solaris wohl immer weniger, zumal deren Engagement in diesem Bereich sagen wir mal sehr überschaubar ist. Die einzig wichtige Neuerung bei Solaris in der Zeit bei Oracle war denn auch SMB 2.1, sequentielles Resilvering und LZ4 Komprimierung sowie ein optimierteres Dedup. Dies war bei Illumos, dem freien Solaris Fork teils schneller oder genausoschnell dabei. Fehlendes wie ZFS Verschlüssellung oder sequentielles Resilvering wird bei OpenZFS gerade entwickelt. Im Moment ist Solaris aber noch etwas schneller mit ZFS als alle anderen.
Wenn Oracle Solaris einstellt, sehe ich
- mit einer hohen Wahrscheinlichkeit verkauft Oracle Solaris, Dann kann es nur besser werden sofern die neue Firma was mit Servern und Storage zu tun hat. Dass es wie bei Adobe läuft, dass Konkurrenten gekauft und eingestampft werden ist eher unwahrscheinlich. Eventuell gibt es ja wieder eine Zusammenarbeit zwischen Solaris und dem freien Fork Illumos. ZFS würde davon sehr profitieren. Teure Doppelentwicklungen wie derzeit wären dann auch nicht mehr nötig.
- eventuell gehen die verbliebenen Solaris und ZFS Entwickler zu OpenZFS/ Illumos. Da sind ja schon sehr viele bei der Übernahme von Sun gelandet.
Für OpenZFS/ Illumos hätte das eigentlich nur imagemäßig Relevanz. Von der technischen Entwicklung gab es eh keinerlei Unterstützung von Oracle für OpenZFS oder das freie Solaris/ Illumos seit OpenSolaris geschlossen wurde. Beide entwickeln sich ohne Oracle prächtig. Lediglich in der Dokumentation müsste sich da was verbessern. Bisher war die Oracle/ Sun Dokumentation um Klassen besser wie alles andere.
Ich sehe das auch bei meinem Napp-it, Nur ganz wenige (meist aus dem öffentlichen Bereich in USA oder im Edu Bereich) nutzen das mit Oracle Solaris.
Zuletzt bearbeitet:
@Fusseltuch @Gea
Hier findet man wohl einige Kommentare von Mitarbeitern und es scheint sich zu bestätigen, dass Oracle da mächtig etwas verändern wird. Falls Oracle Solaris einstampft, bleibt die Frage was mit Ihren Produkten wie Oracle ZFS Backup Appliance und Oracle ZFS Storage Appliance geschieht. Vielleicht wird Solaris beendet, sodass Oracle sich mehr auf die Storage Appliance konzentrieren kann. Falls ja, wird Oracle ihren Quellcode bestimmt nicht offen legen, was natürlich für die OpenZFS-Community eine Bereicherung wäre.
Hier findet man wohl einige Kommentare von Mitarbeitern und es scheint sich zu bestätigen, dass Oracle da mächtig etwas verändern wird. Falls Oracle Solaris einstampft, bleibt die Frage was mit Ihren Produkten wie Oracle ZFS Backup Appliance und Oracle ZFS Storage Appliance geschieht. Vielleicht wird Solaris beendet, sodass Oracle sich mehr auf die Storage Appliance konzentrieren kann. Falls ja, wird Oracle ihren Quellcode bestimmt nicht offen legen, was natürlich für die OpenZFS-Community eine Bereicherung wäre.
Zuletzt bearbeitet:
Eine interne Aussage des verantwortlichen VPs von Oracle hat bestätigt, dass einige Umstrukturierungen kommen werden. Eine Einstellung von Solaris sei aber Quatsch.
Bib
Enthusiast
- Mitglied seit
- 20.12.2006
- Beiträge
- 714
Geht es eigentlich mittlerweile, dass man seine Platten mit ZFS von einem FreeNAS 9.10 in einen OMV-Server importiert?
Da gabs doch bisher ein Problem, weil ZFS unter Linux irgend ein Feature nicht unterstützte, welches unter FreeNAS 9.10 bereits enthalten war.
Kann da jemand mehr dazu sagen? Gilt das immer? Also selbst dann, wenn man dieses spezielle ZFS-Feature überhaupt nicht nutzt?
Wenn das nicht in Kürze möglich ist, dann bleibt mir eigentlich nur, Voll-Backup und unter OMV neu einlesen, oder? Was ginge mir in so einem Fall eigentlich alles verloren gegenüber dem Import der kompletten ZFS-HDD? Rechteverwaltung? Oder muss ich das sowieso neu anlegen und es ist lediglich die Zeit fürs zurück kopieren der Daten, welche den Mehraufwand ausmachen?
Da gabs doch bisher ein Problem, weil ZFS unter Linux irgend ein Feature nicht unterstützte, welches unter FreeNAS 9.10 bereits enthalten war.
Kann da jemand mehr dazu sagen? Gilt das immer? Also selbst dann, wenn man dieses spezielle ZFS-Feature überhaupt nicht nutzt?
Wenn das nicht in Kürze möglich ist, dann bleibt mir eigentlich nur, Voll-Backup und unter OMV neu einlesen, oder? Was ginge mir in so einem Fall eigentlich alles verloren gegenüber dem Import der kompletten ZFS-HDD? Rechteverwaltung? Oder muss ich das sowieso neu anlegen und es ist lediglich die Zeit fürs zurück kopieren der Daten, welche den Mehraufwand ausmachen?
Von der ZFS Version und den Features sollte der Pool Import zwischen Open-ZFS Plattformen (BSD, Illumos, Linux, OSX) keine Probleme bereiten. Von BSD nach Linux sollten auch die Rechte passen da beidesmal SAMBA genutzt wird sofern man beidesmal gleiche User (UID/GID) hat. Von Illumos kommend verliert man mit dem Solarish SMB Server eventuell die Windows ntfs artigen ACL mit Rechte-Vererbung.
Was teilweise Probleme macht sind Platten-Partitionen von BSD wenn man da nicht die komplette Platte für ZFS nutzt.
Was teilweise Probleme macht sind Platten-Partitionen von BSD wenn man da nicht die komplette Platte für ZFS nutzt.
Bib
Enthusiast
- Mitglied seit
- 20.12.2006
- Beiträge
- 714
Im omv Forum stand aber, das würde seit FreeNAS 9.3 oder 9.10 nicht mehr gehen? Weiß aber nicht, ob omv mittlerweile ein Update bekommen hat bzw wie aktuell das war.
gesendet von meinem Samsung Galaxy Note 4
Digi-Quick
Urgestein
- Mitglied seit
- 02.09.2009
- Beiträge
- 7.082
@gea
Wie Riskant ist es bei einem ZFS Mirror aus 2 SSDs ohne ZIL den Sync (Sync Write) abzuschalten.
Dieser ZFS Mirror (Pool) ist via NFS als VM-Datastore in ESXi "zurückverbunden".
Da iSCSI ja nicht automatisch als Datastore verbunden wird nachdem die NAS-VM gestartet ist, musste ich leider auf NFS gehen.
Grundsätzlich funktioniert zwar alles, aber die Schreibleistung innerhalb der VMs auf das jeweilge "Systemlaufwerk" war mit 6,5 MB/s (sequentiell Laut Crystal Diskmark) schlichtweg unterirdisch und führte zu diversen komischen Seiteneffekten.
Nachdem ich jetzt Sync abgeschaltetet habe, sind es gut 500 MB/s - also um den Faktor 100 besserer Werte.
Das System wird mit einer USV betrieben, somit wäre ein ordnungsgemässes Herunterfahren im Falle eines Stromausfalles gewährleistet
Nach allem was ich gelesen habe wird bei NFS auf ZFS dringend empfohlen ein ZIL aus gespiegelten SSDs zu nutzen, wenn man Sync abschaltet - Allerdings gehen diese Setups davon aus, daß der eigentliche Pool aus HDDs besteht.
Die NAS-VM (NAS4Free) beherbergt 4 ZFS Pools aus jeweils einem SSD-Mirror.
1. VM-Datastore via NFS an ESXi
2. Exchange-Data via iSCSi an Exchange-VM
2. Exchange-Log via iSCSi an Exchange-VM
4. Nutzdaten via SMB für Alle VMs
Wie Riskant ist es bei einem ZFS Mirror aus 2 SSDs ohne ZIL den Sync (Sync Write) abzuschalten.
Dieser ZFS Mirror (Pool) ist via NFS als VM-Datastore in ESXi "zurückverbunden".
Da iSCSI ja nicht automatisch als Datastore verbunden wird nachdem die NAS-VM gestartet ist, musste ich leider auf NFS gehen.
Grundsätzlich funktioniert zwar alles, aber die Schreibleistung innerhalb der VMs auf das jeweilge "Systemlaufwerk" war mit 6,5 MB/s (sequentiell Laut Crystal Diskmark) schlichtweg unterirdisch und führte zu diversen komischen Seiteneffekten.
Nachdem ich jetzt Sync abgeschaltetet habe, sind es gut 500 MB/s - also um den Faktor 100 besserer Werte.
Das System wird mit einer USV betrieben, somit wäre ein ordnungsgemässes Herunterfahren im Falle eines Stromausfalles gewährleistet
Nach allem was ich gelesen habe wird bei NFS auf ZFS dringend empfohlen ein ZIL aus gespiegelten SSDs zu nutzen, wenn man Sync abschaltet - Allerdings gehen diese Setups davon aus, daß der eigentliche Pool aus HDDs besteht.
Die NAS-VM (NAS4Free) beherbergt 4 ZFS Pools aus jeweils einem SSD-Mirror.
1. VM-Datastore via NFS an ESXi
2. Exchange-Data via iSCSi an Exchange-VM
2. Exchange-Log via iSCSi an Exchange-VM
4. Nutzdaten via SMB für Alle VMs
ZFS nutzt beim Schreiben immer und grundsätzlich einen rambasierten Schreibcache der mehrere Sekunden puffert, Das gibt ordentlich Performance da dadurch aus kleinen langsamen Random Writes ein schnelles sequentielles Write wird.
Gibt es einen Crash oder Stromausfall beim Schreiben, sind eventuell Daten der letzten Sekunden verloren obwohl es dafür einen Commit an das schreibende Programm gab. Für ZFS ist das kein echtes Problem. Dank CopyOnWrite bleibt das Dateisystem konsistent, Daten sind aber dennoch verloren oder Dateien kaputt.
Für VM Umgebungen bei denen man "alte" Datreisysteme auf dem Storage hat, kann das tödlich sein. Denn da kann das zu einem korrupten Dateisystem führen. Auch sind Transaktionen nicht mehr sicher. Eine Aktion wie Hole Geld vom Konto, warte bis das bestätigt wird, schreibe das einem anderen Konto gut und bestätige alles im Log könnte nur teilweise ausgeführt werden ohne das das auffällt. Es könnte sein , dass jede Aktion ein Commit hat (ja ist auf Platte und alle Transaktionen erfolgreich) wogegen nur die Abbuchung tatsächlich vor dem Crash erfolgt ist.
Dazu gibt es dann bei ZFS "sicheres syncrones Schreiben". Dabei wird jede bestätigte Schreibaktion protokolliert. Bei einem Crash werden ansonst verlorene Schreibaktionen beim nächsten Reboot nachgeholt. Dateien können dann immer noch kaputt sein, es gibt aber niemals den Fall dass ein bestätigter Schreibvorgang verloren geht. Ist quasi wie die Batterie mit Cache bei Hardwareraid.
Sicheres Schreiben auf NFS oder SMB erhält man wenn man sync aktiviert. Bei iSCSI heisst die identische Funktion "Writeback Cache disabled. Man kann für iSCSI auch sync=always stellen.
Wenn man sicheres Schreiben aktiviert, werden die bestätigten Writes aus dem Schreibcache auf dem Pool in einem ZIL Device protokolliert. Wem das nicht schnell genug geht, kann ein Slog nehmen, alse ein extra Laufwerk das schneller ist. Das sollte wirklich schnell sein und muss Powerloss Protection können.
Für "Production Use" ist also sicheres Schreiben ein absolutes Muss und ein Slog wegen der besseren Performance enorm wichtig sofern man nicht einen guten Enterprise SSD Pool mit powerloss protection hat.. Gespiegelt muss das Slog nicht sein. Bei Ausfall benutzt ZFS dann das langsamere ZIL. Datenverlust des Ramcache Inhalts gibts nur wenn bei einem Crash das Slog mit kaputtgeht. Man spiegelt das dennoch dann wenn man das ausschliessen möchte und vor allem den Performanceverlust beim Ausfall vermeiden möchte. Notwendig ist das aber nicht unbedingt. Selbst ein Pool Import ist mit fehlendem Slog möglich.
Gibt es einen Crash oder Stromausfall beim Schreiben, sind eventuell Daten der letzten Sekunden verloren obwohl es dafür einen Commit an das schreibende Programm gab. Für ZFS ist das kein echtes Problem. Dank CopyOnWrite bleibt das Dateisystem konsistent, Daten sind aber dennoch verloren oder Dateien kaputt.
Für VM Umgebungen bei denen man "alte" Datreisysteme auf dem Storage hat, kann das tödlich sein. Denn da kann das zu einem korrupten Dateisystem führen. Auch sind Transaktionen nicht mehr sicher. Eine Aktion wie Hole Geld vom Konto, warte bis das bestätigt wird, schreibe das einem anderen Konto gut und bestätige alles im Log könnte nur teilweise ausgeführt werden ohne das das auffällt. Es könnte sein , dass jede Aktion ein Commit hat (ja ist auf Platte und alle Transaktionen erfolgreich) wogegen nur die Abbuchung tatsächlich vor dem Crash erfolgt ist.
Dazu gibt es dann bei ZFS "sicheres syncrones Schreiben". Dabei wird jede bestätigte Schreibaktion protokolliert. Bei einem Crash werden ansonst verlorene Schreibaktionen beim nächsten Reboot nachgeholt. Dateien können dann immer noch kaputt sein, es gibt aber niemals den Fall dass ein bestätigter Schreibvorgang verloren geht. Ist quasi wie die Batterie mit Cache bei Hardwareraid.
Sicheres Schreiben auf NFS oder SMB erhält man wenn man sync aktiviert. Bei iSCSI heisst die identische Funktion "Writeback Cache disabled. Man kann für iSCSI auch sync=always stellen.
Wenn man sicheres Schreiben aktiviert, werden die bestätigten Writes aus dem Schreibcache auf dem Pool in einem ZIL Device protokolliert. Wem das nicht schnell genug geht, kann ein Slog nehmen, alse ein extra Laufwerk das schneller ist. Das sollte wirklich schnell sein und muss Powerloss Protection können.
Für "Production Use" ist also sicheres Schreiben ein absolutes Muss und ein Slog wegen der besseren Performance enorm wichtig sofern man nicht einen guten Enterprise SSD Pool mit powerloss protection hat.. Gespiegelt muss das Slog nicht sein. Bei Ausfall benutzt ZFS dann das langsamere ZIL. Datenverlust des Ramcache Inhalts gibts nur wenn bei einem Crash das Slog mit kaputtgeht. Man spiegelt das dennoch dann wenn man das ausschliessen möchte und vor allem den Performanceverlust beim Ausfall vermeiden möchte. Notwendig ist das aber nicht unbedingt. Selbst ein Pool Import ist mit fehlendem Slog möglich.
Zuletzt bearbeitet:
Digi-Quick
Urgestein
- Mitglied seit
- 02.09.2009
- Beiträge
- 7.082
Genau so verstehe ich das auch. So Lange alles Ordnungsgemäß läuft, passiert nichts, nur im absoluten Crashfall hat man die A-Karte, die hat man dann sowieso.
Ich kann auch nicht so ganz die Logik verstehen:
1 SSD Mirror ist bei Sync-Write extrem langsam, wie soll da eine weitere SSD (oder besser ein weiterer Mirror) als ZIL beschleunigen - der Schreibvorgang auf den ZIL wird ja auch nicht gecached, ist also genauso langsam.
Wenn ich also dafür Sorge, daß ich die VMs immer Ordnungsgemäss herunterfahre - einschliesslich der Storage VM und von den VMs (VMDKs) eine funktionierende lauffähige / startbare Datensicherung esxistiert, ist die Gefahr nicht allzu Groß.
Die Nutzdaten liegen ja eigentlich nur auf dem CIFS/SMB Share und den iSCSi Targets und werden natürlich ebenfalls gesichert - teilweise im 5 Minuten Rythmus.
Die einzige Ausnahme ist eine Debian/MySQL-VM, da hier die DB selbst mit in der VM liegt, das hätte man Besser lösen können bzw. habe ich noch als Optimierungsbedarf auf der ToDo Liste.
Wobei auch täglich ein Datenbankdump gesichert wird und im 2 Stunden-Rythmus zusätzlich eine bestimmte Tabelle gedumpt wird.
P.S. Wieso ist eigentlich die Schreibrate bei NFS so unterirdisch - gerade bei einem SSD Mirror?
Da ist ja jeder 5€ USB2-Stick schneller
Edit: habe es gerade nochmal getestet (Nachdem ich den NFS Server in NAS4Free auf v4 umgestellt habe):
Sync=Standard
über 1000 MB/s Read aber nur 6,8 MB/s Write
Sync=Disabled
über 1000 MB/s Read und 540 MB/s Write
Ich kann auch nicht so ganz die Logik verstehen:
1 SSD Mirror ist bei Sync-Write extrem langsam, wie soll da eine weitere SSD (oder besser ein weiterer Mirror) als ZIL beschleunigen - der Schreibvorgang auf den ZIL wird ja auch nicht gecached, ist also genauso langsam.
Wenn ich also dafür Sorge, daß ich die VMs immer Ordnungsgemäss herunterfahre - einschliesslich der Storage VM und von den VMs (VMDKs) eine funktionierende lauffähige / startbare Datensicherung esxistiert, ist die Gefahr nicht allzu Groß.
Die Nutzdaten liegen ja eigentlich nur auf dem CIFS/SMB Share und den iSCSi Targets und werden natürlich ebenfalls gesichert - teilweise im 5 Minuten Rythmus.
Die einzige Ausnahme ist eine Debian/MySQL-VM, da hier die DB selbst mit in der VM liegt, das hätte man Besser lösen können bzw. habe ich noch als Optimierungsbedarf auf der ToDo Liste.
Wobei auch täglich ein Datenbankdump gesichert wird und im 2 Stunden-Rythmus zusätzlich eine bestimmte Tabelle gedumpt wird.
P.S. Wieso ist eigentlich die Schreibrate bei NFS so unterirdisch - gerade bei einem SSD Mirror?
Da ist ja jeder 5€ USB2-Stick schneller
Edit: habe es gerade nochmal getestet (Nachdem ich den NFS Server in NAS4Free auf v4 umgestellt habe):
Sync=Standard
über 1000 MB/s Read aber nur 6,8 MB/s Write
Sync=Disabled
über 1000 MB/s Read und 540 MB/s Write
Zuletzt bearbeitet:
Sync Write bedeutet bei ZFS ja Protokollieren aller bestätigten Schreibzugriffe im Schreibcache damit man die im Crashfall nachholen kann. Da der Schreibcache z.B. die letzten 5s Daten sammelt, reden wir also bei einem 1G Netzwerk von ca 5s x 100MB also von 500 MB, bei 10G von 5GB die man innerhalb von 5s schreiben muss, allerdings immer mit sehr sehr kleinen Datenpacketen.
Das Problem dabei sieht man schön bei Atto Benchmarks wenn man sich die Werte unterhalb von 4k anschaut. Ich hatte dazu mal ein paar Benchmarks gemacht bei der ich Sync=always gegen sync=disabled mit verschiedenen Platten getestet habe. Mit Transfers ab ca 64KB ist die "normale" Performance erreicht. Bei syncwrite muss man sich aber performancemäßig eher bei den kleineren Werten orientieren und dabei bricht das enorm ein und es zählt nur die pure iops Performance. Das hat auch mit NFS, SMB oder iSCSI nichts zu tun. Wenn man überall sync=always vs sync=disabled setzt erhält man das gleiche Ergebnis. Mit sync=standard wird allerdings bei NFS/ESXi sync verwendet, bei SMB oder iSCSI per default nicht.
Man sieht auch, dass sync write selbst mit den besten Slogs viel langsamer ist als gepuffertes Schreiben (sync=disabled). Ebenfalls sieht man, dass eine langsame SSD als Slog gar nichts bringt, ganz im Gegenteil. Da ist es manchmal besser, ohne Slog zu arbeiten und die Protokolle auf dem Pool selber zu schreiben (ZIL). Da dabei verteilt auf dem Pool geschrieben wird ist das dann manchmal sogar schneller. Nutzt man einen SSD only Pool z.B. mit Enterprise SSDs (Intel DC, Samsung SM Serie) die sehr hohe iops Schreibwerte bei kleinen Blockgrößen und Powerloss Protection haben, erhält man hier ohne Slog bei Nutzung des Pool-ZIL bessere Ergebnisse als mit einem langsameren Pool und einem extrem teuren ZeusRAM als Slog. 6,8MB/s mit sync write auf einem langsamen Pool der mit sync=disabled 1GB/s kann sind nicht ungewöhnlich. Eine langsame Desktop SSD als Slog verändert das Ergebnis nicht wesentlich.
vgl http://napp-it.org/doc/manuals/benchmarks.pdf
Backup ist kein echte Hilfe. Wenn man ZFS Snaps als Basis nimmt, hat man ja den Stand wie bei einem plätzlichen Stromausfall. Ist das dann valide und wann hat sich ein Problem ins Backup eingeschlichen/ welches Backup war noch ok, das von gestern oder das vom letztem Monat? Mann muss schon im offline Modus backuppen oder wie bei ESXi mit Anhalten der VM über extra ESXi Snaps (ESXi Backupsoftware oder ZFS/ESXi combined Snap). Backup wird dadurch kompliziert oder langsam.
Das größte Vorurteil ist, dass viele meinen ein Slog würde die Performance verbessern so wie ein SSD readcache. Richtig ist dass die besten Slogs (ZeusRAM, NVME P3700, Intel S3700) den Performanceeinbruch von sicherem Schreiben erträglich halten. Zielperformance ist dabei dass die Datenmenge die pro Sekunde übers Netz kommt verarbeitet wird, also bei einem 1Gb/s Netz ca 100 MB/s und bei 10G ca 1GB/s - bei sehr kleinen Transferraten eine echte Herausforderung.
Da sync write eine Eigenschaft eines Dateisystems ist, kann man das aber flexibel halten. Bei einem Filer, egal ob iSCSI, NFS oder SMB braucht man das nicht (ein Word Dokument ist bei einem Crash während des Schreibens immer kaputt, dazu hält Word ja ein lokales Backup). Bei SMB ist default daher ja auch kein sync.
Bei VM Storage oder Datenbanken führt aber kein Weg an sicherem Schreiben vorbei. Diese Systeme verdauen einen Crash meist sehr gut. Ist aber ein Schreibvorgang aber bestätigt, MUSS er auf sicherem Storage sein oder man hebelt alle Sicherheitsmassnahmen der Betriebssysteme oder Datenbankprogramme aus.
Schnelles und dennoch transaktionssicheres Schreiben ist ein Highend Feature. Bei Hardwareraid brauchts dazu einen Controller mit Cache und eine Batterie als Puffer. ZFS Sync Write macht ähnliches und kann im Vergleich dazu deutlich schneller sein, braucht aber ebenfalls spezielle Hardware.
Das Problem dabei sieht man schön bei Atto Benchmarks wenn man sich die Werte unterhalb von 4k anschaut. Ich hatte dazu mal ein paar Benchmarks gemacht bei der ich Sync=always gegen sync=disabled mit verschiedenen Platten getestet habe. Mit Transfers ab ca 64KB ist die "normale" Performance erreicht. Bei syncwrite muss man sich aber performancemäßig eher bei den kleineren Werten orientieren und dabei bricht das enorm ein und es zählt nur die pure iops Performance. Das hat auch mit NFS, SMB oder iSCSI nichts zu tun. Wenn man überall sync=always vs sync=disabled setzt erhält man das gleiche Ergebnis. Mit sync=standard wird allerdings bei NFS/ESXi sync verwendet, bei SMB oder iSCSI per default nicht.
Man sieht auch, dass sync write selbst mit den besten Slogs viel langsamer ist als gepuffertes Schreiben (sync=disabled). Ebenfalls sieht man, dass eine langsame SSD als Slog gar nichts bringt, ganz im Gegenteil. Da ist es manchmal besser, ohne Slog zu arbeiten und die Protokolle auf dem Pool selber zu schreiben (ZIL). Da dabei verteilt auf dem Pool geschrieben wird ist das dann manchmal sogar schneller. Nutzt man einen SSD only Pool z.B. mit Enterprise SSDs (Intel DC, Samsung SM Serie) die sehr hohe iops Schreibwerte bei kleinen Blockgrößen und Powerloss Protection haben, erhält man hier ohne Slog bei Nutzung des Pool-ZIL bessere Ergebnisse als mit einem langsameren Pool und einem extrem teuren ZeusRAM als Slog. 6,8MB/s mit sync write auf einem langsamen Pool der mit sync=disabled 1GB/s kann sind nicht ungewöhnlich. Eine langsame Desktop SSD als Slog verändert das Ergebnis nicht wesentlich.
vgl http://napp-it.org/doc/manuals/benchmarks.pdf
Backup ist kein echte Hilfe. Wenn man ZFS Snaps als Basis nimmt, hat man ja den Stand wie bei einem plätzlichen Stromausfall. Ist das dann valide und wann hat sich ein Problem ins Backup eingeschlichen/ welches Backup war noch ok, das von gestern oder das vom letztem Monat? Mann muss schon im offline Modus backuppen oder wie bei ESXi mit Anhalten der VM über extra ESXi Snaps (ESXi Backupsoftware oder ZFS/ESXi combined Snap). Backup wird dadurch kompliziert oder langsam.
Das größte Vorurteil ist, dass viele meinen ein Slog würde die Performance verbessern so wie ein SSD readcache. Richtig ist dass die besten Slogs (ZeusRAM, NVME P3700, Intel S3700) den Performanceeinbruch von sicherem Schreiben erträglich halten. Zielperformance ist dabei dass die Datenmenge die pro Sekunde übers Netz kommt verarbeitet wird, also bei einem 1Gb/s Netz ca 100 MB/s und bei 10G ca 1GB/s - bei sehr kleinen Transferraten eine echte Herausforderung.
Da sync write eine Eigenschaft eines Dateisystems ist, kann man das aber flexibel halten. Bei einem Filer, egal ob iSCSI, NFS oder SMB braucht man das nicht (ein Word Dokument ist bei einem Crash während des Schreibens immer kaputt, dazu hält Word ja ein lokales Backup). Bei SMB ist default daher ja auch kein sync.
Bei VM Storage oder Datenbanken führt aber kein Weg an sicherem Schreiben vorbei. Diese Systeme verdauen einen Crash meist sehr gut. Ist aber ein Schreibvorgang aber bestätigt, MUSS er auf sicherem Storage sein oder man hebelt alle Sicherheitsmassnahmen der Betriebssysteme oder Datenbankprogramme aus.
Schnelles und dennoch transaktionssicheres Schreiben ist ein Highend Feature. Bei Hardwareraid brauchts dazu einen Controller mit Cache und eine Batterie als Puffer. ZFS Sync Write macht ähnliches und kann im Vergleich dazu deutlich schneller sein, braucht aber ebenfalls spezielle Hardware.
Zuletzt bearbeitet:
Hallo,
ich habe 2 kurze Fragen:
1. Ich kann meine SSD nicht zum Host durchreichen aber diese als RAW-Disk anlegen und dort als L2ARC nutzen. Irgendwelche Widersprüche dazu?
2. Wie sind die Erfahrungen OmniOS unter KVM? Stabil?
ich habe 2 kurze Fragen:
1. Ich kann meine SSD nicht zum Host durchreichen aber diese als RAW-Disk anlegen und dort als L2ARC nutzen. Irgendwelche Widersprüche dazu?
2. Wie sind die Erfahrungen OmniOS unter KVM? Stabil?
1.
kann man machen (mehr RAM und kein L2Arc wäre besser)
2.
Erfahrung mit KVM und OmniOS habe ich nicht.
Als Applikationsserver sollte es aber gut gehen. Bei einem Storageserver (egal welches OS) sollte man aber nur das Storage-OS und nicht die Storagehardware (Controller, Platten) virtualisieren sondern die direkt vom Storage-OS verwalten lassen (pass-through)
kann man machen (mehr RAM und kein L2Arc wäre besser)
2.
Erfahrung mit KVM und OmniOS habe ich nicht.
Als Applikationsserver sollte es aber gut gehen. Bei einem Storageserver (egal welches OS) sollte man aber nur das Storage-OS und nicht die Storagehardware (Controller, Platten) virtualisieren sondern die direkt vom Storage-OS verwalten lassen (pass-through)
zu. 1. Klar, max. kann meine CPU/MoBo nur 32GB, davon geht schon für andere VMs etwas drauf und ich wollte der Storage VM so 18GB geben (2GB für das OS)
zu 2. Wie kann man denn Storage-Hardware virtualisieren? Den Pass-through hatte ich sowieso vor. Mir kam nur die Idee meine SSD für L2ARC im Gehäuse zu haben anstatt vorne per Hot-Plug. Denn damit könnte ich dann das Gehäuse mit vollen 8xHDDs bestücken und diese komplett über den H310 ins Storage-OS weiterreichen. (Ja ein ziemliches Luxusproblem^^) Da man keine einzelnen Sata-Ports in eine VM weiterreichen kann mit KVM nutze ich eben eine RAW-Disk als Art "Trick 17"
zu 2. Wie kann man denn Storage-Hardware virtualisieren? Den Pass-through hatte ich sowieso vor. Mir kam nur die Idee meine SSD für L2ARC im Gehäuse zu haben anstatt vorne per Hot-Plug. Denn damit könnte ich dann das Gehäuse mit vollen 8xHDDs bestücken und diese komplett über den H310 ins Storage-OS weiterreichen. (Ja ein ziemliches Luxusproblem^^) Da man keine einzelnen Sata-Ports in eine VM weiterreichen kann mit KVM nutze ich eben eine RAW-Disk als Art "Trick 17"
besterino
Legende
Hier ist doch auch der ein oder andere Solarish-Experte. Ich versuche gerade einem Solaris 11.3 System beizubringen, per dhcp request als Client die MTU vom DHCP-Server (FreeBSD / pfSense) zu ziehen. Habe dazu die /etc/default/dhcpagent editiert und zu der PARAM_REQUEST_LIST=...24,25,26,27 hinzugefügt. Nutzt aber nix.
Laut der /etc/dhcp/inittab kann der dämliche Client doch auch die Option 26?
dladm show-linkprop -p mtu zeigt zu der NIC:
Also _SOLLTE_ die MTU doch möglich sein.
Komischerweise zeigt ipadm show-ifprop -p mtu aber irgendwie etwas anderes:
Was mache ich falsch oder übersehe ich?
Habe schon versucht, den dhcpagent im debug modus für weitere Analyse zu starten, das klappt aber irgendwie nicht...
Aber: mit einem Linux-Client im gleichen Netz klappt es.
Laut der /etc/dhcp/inittab kann der dämliche Client doch auch die Option 26?
dladm show-linkprop -p mtu zeigt zu der NIC:
Code:
LINK PROPERTY PERM VALUE EFFECTIVE DEFAULT POSSIBLE
net1 mtu rw 1500 1500 1500 1500-16366Also _SOLLTE_ die MTU doch möglich sein.
Komischerweise zeigt ipadm show-ifprop -p mtu aber irgendwie etwas anderes:
Code:
IFNAME PROPERTY PROTO PERM CURRENT PERSISTENT DEFAULT POSSIBLE
net1 mtu ipv4 rw 1500 -- 1500 68-1500
net1 mtu ipv6 rw 1500 -- 1500 1280-1500Was mache ich falsch oder übersehe ich?
Habe schon versucht, den dhcpagent im debug modus für weitere Analyse zu starten, das klappt aber irgendwie nicht...
Aber: mit einem Linux-Client im gleichen Netz klappt es.
Zuletzt bearbeitet:
Das ist der Normalfall wenn man kein Pass-through nutzt bei dem ein Gast mit eigenen Treibern auf echte Hardware zugreift. Die Virtualisierungsumgebung stellt üblicherweise virtualisierte Hardware bereit wie virtualisierte Storage/ iSCSI Controller und virtualisierte Platten.
layerbreak
Enthusiast
- Mitglied seit
- 30.12.2010
- Beiträge
- 590
Ich hab hier OmniOS mit napp-it pro am Laufen.
Täglich läuft mind. ein Replicate-Job.
Nun hab ich auf dem Quellsystem immer nur 3 repli-Snaps, auf dem Zielsystem aber über 250 repli-Snaps - und das pro FS bzw. Repli-Job.
Kann ich die 250 Stück einfach so löschen ohne dass dann meine Backup-Daten futsch sind? Wie erhalte ich mein Backup?
Täglich läuft mind. ein Replicate-Job.
Nun hab ich auf dem Quellsystem immer nur 3 repli-Snaps, auf dem Zielsystem aber über 250 repli-Snaps - und das pro FS bzw. Repli-Job.
Kann ich die 250 Stück einfach so löschen ohne dass dann meine Backup-Daten futsch sind? Wie erhalte ich mein Backup?
fdiskc2000
Enthusiast
- Mitglied seit
- 30.05.2007
- Beiträge
- 2.230
Ich kann dir zwar nicht helfen, aber versuche das gleiche Zu erreichen wie du. Also auf dem Ziel mehr Snaps als auf der Quelle. Könntest du mir mal die Einstellungen deiner task als Screen zeigen?
Gesendet von iPhone mit Tapatalk
Für eine laufende Replikation wird auf dem Sender und dem Empfänger/Backupsystem nur der Snapshot der letzten erfolgreichen Replikation benötigt, das ist pro Dateisystem der mit der gleichen/höchsten Nummer. Dieser muss auf beiden Seiten den identischen Datenstand darstellen.
Da ZFS Replikation wie Musikaufnahmen beim Radiohören funktioniert, kann immer etwas schiefgehen. Ich halte daher zusätzlich auf beiden Seiten die beiden vorherigen Snaps. Damit kann man auf dem Zielsystem den letzten Snap manuell löschen und es wird automatisch der Vorsnap benutzt. Die aktuelle napp-it Version macht das bei Problemen mit dem jeweils letzten Snap automatisch.
Möchte man auf dem Quellsystem weitere Snaps, gibts dafür Autosnaps.
Möchte man auf dem Zielsystem mehr Snaps, kann man das mit Autosnaps nicht realisieren da bei der Replikation das Zielsystem auf den letzten Snap zurückgesetzt wird und darauf folgende Autosnaps gelöscht würden.
Im Replikationsjob kann man aber per keep und hold die Anzahl der Snaps auf dem Backupsystem je Dateisystem einstellen, z.B.
hold=8 bedeutet, lösche bei der nächsten Replikation Snaps dieses Jobs älter als 8 Tage
hold=8s bedeutet, lösche bei der nächsten Replikation Snaps dieses Jobs bis auf die letzten 8
keep=100 bedeutet dass jeder hunderste Snap umbenannt wird und dauerhaft aufgehoben wird
Löschen kann man alle Replikationssnaps bis auf den jeweils letzten, z.B. mit Snaps > mass delete
Da kann man Snaps nach dem Mindest/Höchstalter und einem String wie der jobid auswählen. Man kann auch Replikationssnaps da generell ausschliessen. Es gibt auch die Option jeden Tag/Woche/Monat mindestens einen Snap zu behalten, also z.B.
Lösche für einen Replikationsjob alle Snaps älter als 30 Tage, behalte aber mindestens einen pro Monat.
Die Daten auf dem Backupsystem sind ja in einem ZFS Dateisystem. Die Snaps braucht man für Versionierung (z.B. Windows > Vorherige Version) und als Basis für eine weiterlaufende inkrementelle Replikation. Das ist Vorraussetzung um zwei Dateisysteme unabhängig von der Größe oder der Anzahl der Dateien bei minimaler Last bis in den Minutenbereich übers Netz syncron zu halten.
Löscht man den letzten gemeinsamen Replikationssnap sind alle Daten noch im Ziel-Dateisystem. Eine Replikation erfordert dann aber eine komplette Neuübertragung aller Daten (nach Löschen oder Umbennennen des alten Ziel Dateisystems)
Da ZFS Replikation wie Musikaufnahmen beim Radiohören funktioniert, kann immer etwas schiefgehen. Ich halte daher zusätzlich auf beiden Seiten die beiden vorherigen Snaps. Damit kann man auf dem Zielsystem den letzten Snap manuell löschen und es wird automatisch der Vorsnap benutzt. Die aktuelle napp-it Version macht das bei Problemen mit dem jeweils letzten Snap automatisch.
Möchte man auf dem Quellsystem weitere Snaps, gibts dafür Autosnaps.
Möchte man auf dem Zielsystem mehr Snaps, kann man das mit Autosnaps nicht realisieren da bei der Replikation das Zielsystem auf den letzten Snap zurückgesetzt wird und darauf folgende Autosnaps gelöscht würden.
Im Replikationsjob kann man aber per keep und hold die Anzahl der Snaps auf dem Backupsystem je Dateisystem einstellen, z.B.
hold=8 bedeutet, lösche bei der nächsten Replikation Snaps dieses Jobs älter als 8 Tage
hold=8s bedeutet, lösche bei der nächsten Replikation Snaps dieses Jobs bis auf die letzten 8
keep=100 bedeutet dass jeder hunderste Snap umbenannt wird und dauerhaft aufgehoben wird
Löschen kann man alle Replikationssnaps bis auf den jeweils letzten, z.B. mit Snaps > mass delete
Da kann man Snaps nach dem Mindest/Höchstalter und einem String wie der jobid auswählen. Man kann auch Replikationssnaps da generell ausschliessen. Es gibt auch die Option jeden Tag/Woche/Monat mindestens einen Snap zu behalten, also z.B.
Lösche für einen Replikationsjob alle Snaps älter als 30 Tage, behalte aber mindestens einen pro Monat.
Die Daten auf dem Backupsystem sind ja in einem ZFS Dateisystem. Die Snaps braucht man für Versionierung (z.B. Windows > Vorherige Version) und als Basis für eine weiterlaufende inkrementelle Replikation. Das ist Vorraussetzung um zwei Dateisysteme unabhängig von der Größe oder der Anzahl der Dateien bei minimaler Last bis in den Minutenbereich übers Netz syncron zu halten.
Löscht man den letzten gemeinsamen Replikationssnap sind alle Daten noch im Ziel-Dateisystem. Eine Replikation erfordert dann aber eine komplette Neuübertragung aller Daten (nach Löschen oder Umbennennen des alten Ziel Dateisystems)
Zuletzt bearbeitet:
fdiskc2000
Enthusiast
- Mitglied seit
- 30.05.2007
- Beiträge
- 2.230
Oha, manchmal sollte man Dinge einfach nicht mehr abends machen. Natürlich bleiben auf der Quelle durch Deine Replikations-Erweiterung nur die letzten 3 stehen. Ich fürchte ich habe da die Snaps auf dem Backup-Server angesehen 
.
Also manchmal ..... Danke @gea
Die Autosnap Einteilung aus dem Handbuch habe ich für das normale Daten-ZFS eingesetzt (Snaps bis zu 2 Jahre zurück)
Wie geht Ihr denn bei den ZFS vor, die für ESXI und die VM´s zur Verfügung gestellt werden? Gerade weil das ja prinzipiell auch eher SSD sind und dort der Platz nicht ganz so üppig ist wie auf normalen HDD?
Aktuell mache ich auf der SSD selber alle 10 min einen Snap und halte die 3 Tage
zusätzlich mache stündlich eine Replikation SSD -> HDD Pool und halte da 6 Replikationen
Ausserdem wandert einmal am Tag alles auf den Backup-Server wo die letzten 30 Tage liegen.
Das ganze ist rein privater Gebrauch.
Wie verwendet ihr das sonst bei Euch?
.Also manchmal ..... Danke @gea
Die Autosnap Einteilung aus dem Handbuch habe ich für das normale Daten-ZFS eingesetzt (Snaps bis zu 2 Jahre zurück)
Wie geht Ihr denn bei den ZFS vor, die für ESXI und die VM´s zur Verfügung gestellt werden? Gerade weil das ja prinzipiell auch eher SSD sind und dort der Platz nicht ganz so üppig ist wie auf normalen HDD?
Aktuell mache ich auf der SSD selber alle 10 min einen Snap und halte die 3 Tage
zusätzlich mache stündlich eine Replikation SSD -> HDD Pool und halte da 6 Replikationen
Ausserdem wandert einmal am Tag alles auf den Backup-Server wo die letzten 30 Tage liegen.
Das ganze ist rein privater Gebrauch.
Wie verwendet ihr das sonst bei Euch?
besterino
Legende
Backup von VMs ist für mich @home eher ein Bequemlichkeitsfaktor. Kann man zur Not recht flott neu aufsetzen, solange eben die Daten darunter eben noch da sind. Die VMs liegen bei mir auf einem 4er SSD-ZFSRaid0 und werden 1x die Woche auf einen langsamen HDD-RaidZ Pool per "same-Host, anderer Pool Replikation" gesichert. Die Daten selbst (mit denen die VMs dann arbeiten) liegen deutlich "sicherer" auf einem separaten HDD-RaidZ Pool mit granularerer Replikation auf einen zweiten Host.
Schmiert also das SSD-Raid ab, muss ich nicht bei 0 anfangen und selbst im Backup-Pool darf noch eine HDD sterben.
Schmiert also das SSD-Raid ab, muss ich nicht bei 0 anfangen und selbst im Backup-Pool darf noch eine HDD sterben.
layerbreak
Enthusiast
- Mitglied seit
- 30.12.2010
- Beiträge
- 590
Bitte sehr.
Achtung napp-it ist 0.9f von August 2015.
Nach dem Motto: Never change a running system.
Autosnap von meinem AIO
Replicate-Job
dazu gehörende Snaps
- - - Updated - - -
Sorry das unterstrichene versteh ich jetzt nicht, was du damit meinst.
Geht das - 8s - bei meiner 0,9f Version auch schon?
An den obigen Bildern ist zu sehen, dass ich keep=30 eingegeben habe, in der Realität hab ich aber auf dem Zielsystem 180 Snaps mit der ID.
Das mit keep=100 und umbenannt versteh ich nicht, denn auf AIO mach ich auto-snaps mit keep=60 bei mir werden die Snaps aber nicht umgenannt, sondern immer nur die 60 Jüngsten behalten.
Kann ich nachträglich es so editieren indem ich auf die ID klicke und dann unter hold =10s eingebe. Wenn dann dieser Repli-Job das nächste Mal um 22:02 ausgeführt wird, löscht er mir ALLe repli-Snaps bis auf die letzten 10?
Wenn ich eine Repli-ID in Zeichen eingebe, kommt als Ergebnis 0, wenn ich aber zusätzlich "delete Repli-Snaps" aktiviere, dann funktioniert es.
Das hab ich soweit verstanden.
Kann ich von meiner 0.9f direkt auf die aktuelle Version updaten?
About/Update zeigt mir nur 16.01f und 16.01p zum download an.
Achso es läuft auf allen Servern OmniOS r151012 und napp-it pro.
Danke.
- - - Updated - - -
Hast du mir mal einen Link zu dem Handbuch bitte?
Autosnap Job
Damit kann man Snapshots eines Dateisystems anlegen lassen.
Einstellungen:
keep=Anzahl Snaps
hold=Mindestalter Tage
Snaps werden gelöscht, wenn beide Regeln diese erlauben (Sowohl als auch/und)
Keep=10 und hold=10 bedeutet also dass Snaps gelöscht werden die älter als 10 Tage sind. Es werden aber in jedem Fall mindestens 10 behalten.
Replikations Job:
Damit werden zwei Dateisysteme über Snapshots syncronisiert.
Einstellungen siehe oben (keep and hold)
Auf dem Backupsystem wird zu Beginn einer Replikation das Dateisystem per Rollback auf den Stand des letzten gemeinsamen Snaps gebracht. Wurden da Daten seit der letzten Replikation geändert oder weitere Snaps angelegt (manuell oder per Autosnap-Job) so werden diese gelöscht. Extra Snaps auf dem Backupsystem kann man daher nicht mit einem AutoSnap Job anlegen lassen sondern nur über den Replikationsjob selber.
Anzahl der Replikationssnaps konnte man mit napp-it 0.9 noch nicht einstellen.
Das Update auf die aktuelle Version geht über 16.01 -> 16.11. Dabei wird sicherheitshalber eine Bootumgebung/ BE angelegt.
OmniOS sollte man eventuell auch mal updaten. Aktuell ist 151020 stable.
151012 wird nicht mit Updates versorgt
Handbücher und Manuals, siehe
http://napp-it.org/manuals
Damit kann man Snapshots eines Dateisystems anlegen lassen.
Einstellungen:
keep=Anzahl Snaps
hold=Mindestalter Tage
Snaps werden gelöscht, wenn beide Regeln diese erlauben (Sowohl als auch/und)
Keep=10 und hold=10 bedeutet also dass Snaps gelöscht werden die älter als 10 Tage sind. Es werden aber in jedem Fall mindestens 10 behalten.
Replikations Job:
Damit werden zwei Dateisysteme über Snapshots syncronisiert.
Einstellungen siehe oben (keep and hold)
Auf dem Backupsystem wird zu Beginn einer Replikation das Dateisystem per Rollback auf den Stand des letzten gemeinsamen Snaps gebracht. Wurden da Daten seit der letzten Replikation geändert oder weitere Snaps angelegt (manuell oder per Autosnap-Job) so werden diese gelöscht. Extra Snaps auf dem Backupsystem kann man daher nicht mit einem AutoSnap Job anlegen lassen sondern nur über den Replikationsjob selber.
Anzahl der Replikationssnaps konnte man mit napp-it 0.9 noch nicht einstellen.
Das Update auf die aktuelle Version geht über 16.01 -> 16.11. Dabei wird sicherheitshalber eine Bootumgebung/ BE angelegt.
OmniOS sollte man eventuell auch mal updaten. Aktuell ist 151020 stable.
151012 wird nicht mit Updates versorgt
Handbücher und Manuals, siehe
http://napp-it.org/manuals
layerbreak
Enthusiast
- Mitglied seit
- 30.12.2010
- Beiträge
- 590
Danke @gea für die Erklärungen.
Gibts Stolperfallen oder Dinge die besonders beachten oder ändern muss?
Lese ich es richtig, dass ich von 12 erst auf 14 updaten muss und dann auf 20 direkt gehen kann?
Einfach auf 16.01. updaten, dann auf 16.11?
Gibts Stolperfallen oder Dinge die besonders beachten oder ändern muss?
Ich weis, du hast ja recht ich sollte updaten.
Lese ich es richtig, dass ich von 12 erst auf 14 updaten muss und dann auf 20 direkt gehen kann?
napp-it updates sollte keine Probleme machen
und wenn, kann man downgraden, ansonst gibts bootenvironments
OmniOS updates geht auch in zwei Schritten
erst auf 014 (oder 18)
https://omnios.omniti.com/wiki.php/Upgrade_to_r151014
dann auf 020
Da erst OpenSSH updaten, dann OmniOS
https://omnios.omniti.com/wiki.php/Upgrade_to_r151020
und wenn, kann man downgraden, ansonst gibts bootenvironments
OmniOS updates geht auch in zwei Schritten
erst auf 014 (oder 18)
https://omnios.omniti.com/wiki.php/Upgrade_to_r151014
dann auf 020
Da erst OpenSSH updaten, dann OmniOS
https://omnios.omniti.com/wiki.php/Upgrade_to_r151020
layerbreak
Enthusiast
- Mitglied seit
- 30.12.2010
- Beiträge
- 590
@gea, ich sehe dass in r151014 die open-vm-tools aufgenommen wurden.
Wie verhält es sich beim AIO, denn damals hatte ich die VMWare Tools händisch installiert. Was ist mit dem vmxnet3 Treiber, wird der übernommen oder muss es wieder von Hand nachträglich installiert werden?
Ich suche noch eine Möglichkeit meine Backups zu beschleunigen und denke da an ein Netzwerk >= 10GbE
Die Intel x540 ist mir zu teuer, für meinen Nutzen.
Hier gibts was von Mellanox für kleines Geld:
SET 2x long Mellanox MNPA19-XTR 10GbE +3m Kabel 10Gbps Ethernet Bundle 10G 10Gb | eBay
alternativ könnte ich eine Intel 10GbE XF mit LWL Kabel mir vorstellen.
Beide stehen in der IllumOS-HCL.
Wie ist da deine Meinung dazu?
Wie verhält es sich beim AIO, denn damals hatte ich die VMWare Tools händisch installiert. Was ist mit dem vmxnet3 Treiber, wird der übernommen oder muss es wieder von Hand nachträglich installiert werden?
Ich suche noch eine Möglichkeit meine Backups zu beschleunigen und denke da an ein Netzwerk >= 10GbE
Die Intel x540 ist mir zu teuer, für meinen Nutzen.
Hier gibts was von Mellanox für kleines Geld:
SET 2x long Mellanox MNPA19-XTR 10GbE +3m Kabel 10Gbps Ethernet Bundle 10G 10Gb | eBay
alternativ könnte ich eine Intel 10GbE XF mit LWL Kabel mir vorstellen.
Beide stehen in der IllumOS-HCL.
Wie ist da deine Meinung dazu?
Der korrekte Weg wäre wohl
- Vmware Tools per Perl deinstaller manuell deinstallieren
- Updaten
- open-vm-tools und vmxnet3s aus dem OmniOS Repository per pkg install installieren
Bei den Nics würde ich nach gebrauchten Intel X520 samt DAC Kabel schauen
- Vmware Tools per Perl deinstaller manuell deinstallieren
- Updaten
- open-vm-tools und vmxnet3s aus dem OmniOS Repository per pkg install installieren
Bei den Nics würde ich nach gebrauchten Intel X520 samt DAC Kabel schauen
