ludwinator
Enthusiast
- Mitglied seit
- 28.12.2006
- Beiträge
- 532
Alle, die mit der aktuellen NVMe Performance unter Illumos/OI/etc nicht so ganz zufrieden sind, sollten hierauf mal ein Auge werfen:
Feature #11827: Increase concurrency through blkdev - illumos gate - illumos
cu
Feature #11827: Increase concurrency through blkdev - illumos gate - illumos
cu
Bei einer Optane oder anderen Highend NVMe wird es vermutlich nicht ganz so wichtig sein, wenn man man nur eine Queue hat zum Abarbeiten. Ich vermute aber mal dass viele günstigere NVMe sehr stark davon profitieren werden. Neben NVMe hotplug das auch gerade in Illumos landet, sicher ein wichtiger NVMe Fortschritt. Falls @snipor keine Probleme mit seiner Intel-Serie unter ESXi feststellen kann und das an OmniOS rückmeldet, wird es auch unter ESXi 6 insgesamt weniger weniger Probleme mit manchen NVMe geben (ESXi 5 wird dann halt nicht mehr unterstützt).
Insgesamt landen in Illumos (NexentaStor,OmniOS,OpenIndiana,SmartOS) eh gerade so viele neue Features auf Einmal wie seit langem nicht mehr. Das nächste OmniOS 151032 stable wird ein echtes Hammer-Release.
Der Solarish SMB Server, der immer schon besondere Performance, Windows SID und ntfs artige ACL, Windows SMB Gruppen und problemlose Unterstützung für ZFS Snaps=Windows vorherige Version bietet, kommt jetzt SMB 3.02 dazu, sowie persistent handles im Failover Cluster, Feature #11031: SMB3 persistent handles - illumos gate - illumos
Dazu kommen all die Nettigkeiten die aktuell in Open-ZFS landen wie ZFS Verschlüssellung, Allocation Classes mit speziellen vdev, sequentielles Resilvering oder Trim für SSDs um einige nach ihrer Wichtigkeit für mich aufzulisten.
Insgesamt landen in Illumos (NexentaStor,OmniOS,OpenIndiana,SmartOS) eh gerade so viele neue Features auf Einmal wie seit langem nicht mehr. Das nächste OmniOS 151032 stable wird ein echtes Hammer-Release.
Der Solarish SMB Server, der immer schon besondere Performance, Windows SID und ntfs artige ACL, Windows SMB Gruppen und problemlose Unterstützung für ZFS Snaps=Windows vorherige Version bietet, kommt jetzt SMB 3.02 dazu, sowie persistent handles im Failover Cluster, Feature #11031: SMB3 persistent handles - illumos gate - illumos
Dazu kommen all die Nettigkeiten die aktuell in Open-ZFS landen wie ZFS Verschlüssellung, Allocation Classes mit speziellen vdev, sequentielles Resilvering oder Trim für SSDs um einige nach ihrer Wichtigkeit für mich aufzulisten.
Habe meinen Server erweitern wollen
HBA (DELL H310) IT Mode eingebaut und durchgereicht (ESXI 6.7 U3)
die angeschlossenen Platten tauchen einfach nicht bei Napp It auf.
Ein zwetes Napp It nur mit deisem Controller erstelt und siehe da alles paletti.
Welche Schritte muss ich vollziehen das dieser Conti in der Orginal Version seine Platten anzeigt ?
HBA (DELL H310) IT Mode eingebaut und durchgereicht (ESXI 6.7 U3)
die angeschlossenen Platten tauchen einfach nicht bei Napp It auf.
Ein zwetes Napp It nur mit deisem Controller erstelt und siehe da alles paletti.
Welche Schritte muss ich vollziehen das dieser Conti in der Orginal Version seine Platten anzeigt ?
Luckysh0t
Enthusiast
Danke gea, hat wunderbar geklappt.
Mit all den neuen Features in OmniOS bin ich echt am überlegen ob ich von Solaris wechseln soll - hing bisher primär an der Verschlüsselung per Filesystem.
Mit all den neuen Features in OmniOS bin ich echt am überlegen ob ich von Solaris wechseln soll - hing bisher primär an der Verschlüsselung per Filesystem.
Performancemäßig war Solaris bisher immer etwas besser. Und hatte ZFS Verschlüssellung, SMB3, NFS 4.1, vdev remove aich für Raid-Z und sequentielles Resilvering. Dazu für kommerzielle Kunden Support-Garantie bis 2035+.
Für private Nutzung sehe ich Illumos langsam als praktisch gleichwertig, in manchen Dingen sogar voraus (Replikation verschlüsselter Dateisysteme oder LX/Bhyve Zonen). Auch für kommerzielle Nutzung ist OmniOS LTS bis auf den Ultra Langzeitsupport eine echt gute Alternative.
Für private Nutzung sehe ich Illumos langsam als praktisch gleichwertig, in manchen Dingen sogar voraus (Replikation verschlüsselter Dateisysteme oder LX/Bhyve Zonen). Auch für kommerzielle Nutzung ist OmniOS LTS bis auf den Ultra Langzeitsupport eine echt gute Alternative.
Hi
Hatte auf meinem napp-it SSD NFS Store nur noch 90GB frei, oder so. Also habe ich eine 230GB VM (thick) verschoben, und die ursprüngliche VM auf der SSD gelöscht. Habe jetzt immer noch nur 100GB frei. Muss ich da noch was bereinigen auf dem ZFS? Nach mir müsste da jetzt noch mehr Platz frei sein nach der Löschaktion.
- - - Updated - - -
Ah, Idiot, hatte da noch Schnappschüsse drauf
*/erledigt
Hatte auf meinem napp-it SSD NFS Store nur noch 90GB frei, oder so. Also habe ich eine 230GB VM (thick) verschoben, und die ursprüngliche VM auf der SSD gelöscht. Habe jetzt immer noch nur 100GB frei. Muss ich da noch was bereinigen auf dem ZFS? Nach mir müsste da jetzt noch mehr Platz frei sein nach der Löschaktion.
- - - Updated - - -
Ah, Idiot, hatte da noch Schnappschüsse drauf
*/erledigt
Trambahner
Urgestein
Yo, die Snaps vergisst man gerne mal. Auch weil sie halt so schön einfach zu erzeugen sind.Der Vollständigkeit halber, falls jemand ZoL nutzt
panic when removing vdev from pool with different-ashift special/dedup vdev · Issue #9363 · zfsonlinux/zfs · GitHub
besterino
Legende
Habe mit Schrecken gesehen, dass die vmwaretools für Solaris nicht mehr weiterentwickelt werden. Damit dürften dann Solaris-Gäste wohl insgesamt bei ESXi immer schlechter supported werden, vermute ich mal? Vor allem leider für das „echte“ Solaris, da Oracle wohl eher kein Interesse hat, für ESXi eigene Treiber zu bauen... 
Der Trend geht ja ganz allgemein zu den open-vm-tools.
open-vm-tools/open-vm-tools/modules/solaris at master · vmware/open-vm-tools · GitHub
Ansonsten.
Solaris 11.4 war bisher immer der schnellste ZFS Server, hatte bei weitem die meisten Killer-Features und bietet Support Garantie bis 2037+ für zahlende Kunden. Für private Nutzung ändert sich aber gerade vieles. Bis auf den Performanceaspekt sieht es so aus
Für nichtkommerzielle Nutzung ist OmniOS/OI/SmartOS neuerdings deutlich attraktiver.
open-vm-tools/open-vm-tools/modules/solaris at master · vmware/open-vm-tools · GitHub
Ansonsten.
Solaris 11.4 war bisher immer der schnellste ZFS Server, hatte bei weitem die meisten Killer-Features und bietet Support Garantie bis 2037+ für zahlende Kunden. Für private Nutzung ändert sich aber gerade vieles. Bis auf den Performanceaspekt sieht es so aus
Code:
Solaris 11.4 OmniOS 151032 (Solaris Fork, vorraussichtlich, November 2019)
SMB kernelb. Server v 3.1 v 3.02
Client v 2.1 v 3.02
NFS Server v 4.1 v 4.0
ZFS Verschlüssellung ja ja
zfs send encr. nein ja
spezielle vdev nein ja
sequ. Resilvering ja ja
vdev remove ja (alle) ja (nur mirror und basic)
LX/Linux Zonen nein ja
Byhve Virtualisierer nein ja
Opensource nein ja
Support (kommerziell) ja ja
Bugfixed (free) nein jaFür nichtkommerzielle Nutzung ist OmniOS/OI/SmartOS neuerdings deutlich attraktiver.
Zuletzt bearbeitet:
Featuremäßig (inkl. Bug bei vdev remove von special/dedup vdev) sind Illumos und ZoL gleichauf. Die Replikation zwischen beiden sollte also nicht daran scheitern. Ich habe das aber noch nicht versucht.
Ich würde als erstes ein Ziel angeben, dass noch nicht existiert. Als Alternativoption raw send (-w) versuchen. Damit wird das verschlüsselte Dateisystem direkt übertragen und kann auf dem Zielsystem mit dem ursprünglichen Schlüssel entsperrt werden.
Ich würde als erstes ein Ziel angeben, dass noch nicht existiert. Als Alternativoption raw send (-w) versuchen. Damit wird das verschlüsselte Dateisystem direkt übertragen und kann auf dem Zielsystem mit dem ursprünglichen Schlüssel entsperrt werden.
Hallo,
dürfte ich um Hilfe bei einem Problem bitten? Wir betreiben einen OmniOS v11 r151014 Server, welcher neben NFS und CIFS auch 5 iSCSI Targets hostet. Die LUNs sind sowohl volumen- als auch dateibasiert. Alles funktioniert gut, bis der scrub startet. Denn nach einer Weile verlieren die iSCSI Initiators ihre Verbindung zu den LUNs bis man einen Rescan in der Datenträgerverwaltung durchführt. Nachdem ich das Problem erstmal bemerkt habe, hab ich versucht über das ZFS/Scrub Tuning den Scrub zu verlangsamen (z.b. zfs_scan_idle erhöht). Allerdings ist in der Beschreibung die Rede von "user I/O". Ich vermute, dass der comstar dienst eher als system betrachtet wird, womit dieses Tuning zwecklos wäre.
TL;DR: Mein Scrub wirkt sich negativ auf den iSCSI Target Dienst aus, worauf hin Clients die Verbindung verlieren. Bin ich damit hier richtig? Hat jemand einen Tip für mich, oder dieses Problem selbst schon einmal gehabt?
MfG, Nico
dürfte ich um Hilfe bei einem Problem bitten? Wir betreiben einen OmniOS v11 r151014 Server, welcher neben NFS und CIFS auch 5 iSCSI Targets hostet. Die LUNs sind sowohl volumen- als auch dateibasiert. Alles funktioniert gut, bis der scrub startet. Denn nach einer Weile verlieren die iSCSI Initiators ihre Verbindung zu den LUNs bis man einen Rescan in der Datenträgerverwaltung durchführt. Nachdem ich das Problem erstmal bemerkt habe, hab ich versucht über das ZFS/Scrub Tuning den Scrub zu verlangsamen (z.b. zfs_scan_idle erhöht). Allerdings ist in der Beschreibung die Rede von "user I/O". Ich vermute, dass der comstar dienst eher als system betrachtet wird, womit dieses Tuning zwecklos wäre.
TL;DR: Mein Scrub wirkt sich negativ auf den iSCSI Target Dienst aus, worauf hin Clients die Verbindung verlieren. Bin ich damit hier richtig? Hat jemand einen Tip für mich, oder dieses Problem selbst schon einmal gehabt?
MfG, Nico
martingo
Experte
- Mitglied seit
- 17.01.2017
- Beiträge
- 1.300
Hi,
auf die kluge Idee bin ich zwischenzeitlich auch schon gekommen und habe deshalb meine Frage gelöscht. War mir nicht klar, dass schon jemand darauf antwortet, üblicherweise mache ich das nicht. Die Frage war nur einfach Käse
Vielen Dank trotzdem und Grüße
Martin
- - - Updated - - -
Komme ich eigentlich von 151033 zurück auf 151032? War mir beim Upgrade nicht klar, dass bloody schon 151033 ist.
Oder muss ich die VM neu anlegen?
Ich würde zwei Dinge versuchen
- Begrenzen des Arc Caches z.B. auf 60-70% RAM via set zfs:zfs_arc_max =
Tuning the Oracle Solaris Kernel - Oracle Solaris Tunable Parameters Reference Manual
ZFS weist den RAM zwar dynamisch zu, es kann aber manchmal durchaus hilfreich sein, RAM freizulassen
- neueres OmniOS
151014 ist schon recht alt. Ich würde aber vermutlich auf 151032 warten, da damit sequentielles Resilvering kommt.
- - - Updated - - -
Seit dieser Woche ist die Bloody bereits 151033. Die bisherige 151031 bloody geht gerade in 151032 stable über. Ob das Downgrade auf 151032 stable klappt, muss man probieren. Aktuell stehen die Chance gut da es sich ja eigentlich noch um das gleiche OS handelt. Wenn nicht, dann ein früheres BE starten und das upgraden.
- Begrenzen des Arc Caches z.B. auf 60-70% RAM via set zfs:zfs_arc_max =
Tuning the Oracle Solaris Kernel - Oracle Solaris Tunable Parameters Reference Manual
ZFS weist den RAM zwar dynamisch zu, es kann aber manchmal durchaus hilfreich sein, RAM freizulassen
- neueres OmniOS
151014 ist schon recht alt. Ich würde aber vermutlich auf 151032 warten, da damit sequentielles Resilvering kommt.
- - - Updated - - -
Seit dieser Woche ist die Bloody bereits 151033. Die bisherige 151031 bloody geht gerade in 151032 stable über. Ob das Downgrade auf 151032 stable klappt, muss man probieren. Aktuell stehen die Chance gut da es sich ja eigentlich noch um das gleiche OS handelt. Wenn nicht, dann ein früheres BE starten und das upgraden.
Hi,
bezüglich des obigen feature Vergleich Solaris 11.4 vs OmniOS habe ich mal ˋne Frage bezüglich des Verschlüsselung eines ZFS filesystems unter Solaris 11.4.
- Müssen für einen replication job via napp-it beide ZFS filesysteme unlocked sein, damit dies funktioniert? Sprich Quelle und Ziel, wenn beide mit encryption angelegt wurden? Das zfs send/receive unverschlüsselt übers Netzwerk läuft ist mir sowei klar. Oder reicht es auch, wenn nur das Quell filesystem unlocked ist? Auch nach blicken in die Oracle Doku ist mir das Ganze, trotz der Beispiele, irgendwie noch nicht 100% richtig klar.
Hintergrund der Frage, es soll regelmässig auf ein Backupsystem repliziert werden und das System nur für den Zweck kurzzeitig eingeschaltet und danach wieder zeitnah runtergefahren werden. Wäre natürlich klasse das dortige fs nicht jedesmal wieder händisch unlocken zu müssen.
bezüglich des obigen feature Vergleich Solaris 11.4 vs OmniOS habe ich mal ˋne Frage bezüglich des Verschlüsselung eines ZFS filesystems unter Solaris 11.4.
- Müssen für einen replication job via napp-it beide ZFS filesysteme unlocked sein, damit dies funktioniert? Sprich Quelle und Ziel, wenn beide mit encryption angelegt wurden? Das zfs send/receive unverschlüsselt übers Netzwerk läuft ist mir sowei klar. Oder reicht es auch, wenn nur das Quell filesystem unlocked ist? Auch nach blicken in die Oracle Doku ist mir das Ganze, trotz der Beispiele, irgendwie noch nicht 100% richtig klar.
Hintergrund der Frage, es soll regelmässig auf ein Backupsystem repliziert werden und das System nur für den Zweck kurzzeitig eingeschaltet und danach wieder zeitnah runtergefahren werden. Wäre natürlich klasse das dortige fs nicht jedesmal wieder händisch unlocken zu müssen.
Zuletzt bearbeitet:
Ich müsste das jetzt selbst ausprobieren. Es sollte aber unter Solaris wohl so sein:
Beide Dateisysteme müssen unlocked sein, da die Übertragung unverschlüsselt erfolgt.
Das Zieldateisystem (unter einem unlocked parent) erhält dann den Parent Key
https://docs.oracle.com/cd/E37838_01/html/E61017/gkkih.html#SVZFSgkkof
Unter OmniOS kann die Übertragung verschlüsselt erfolgen und das Zieldateisystem ist verschlüsselt.
Unlock dann mit dem Key für das Quelldateisystem
Beide Dateisysteme müssen unlocked sein, da die Übertragung unverschlüsselt erfolgt.
Das Zieldateisystem (unter einem unlocked parent) erhält dann den Parent Key
https://docs.oracle.com/cd/E37838_01/html/E61017/gkkih.html#SVZFSgkkof
Unter OmniOS kann die Übertragung verschlüsselt erfolgen und das Zieldateisystem ist verschlüsselt.
Unlock dann mit dem Key für das Quelldateisystem
Das hatte ich mir fast schon gedacht, gibt wohl mit sru12 oder so ein feature, dass nun zumindestens von einem unencrypted fs auf ein bereits mit encryption versehenes fs repliziert werden kann. Aber das ist ja hier nicht relevant.
Wäre es theoretisch realisierbar als keysource neben prompt, password auch noch auf ein keyfile zu referenzieren, welches auf dem Quell fs liegt und bspws. per smb freigegen und unlocked ist, so dass das Backuo System beim boot das Ziel fs automatisch unlocked? Vorausgesetzt natürlich das das durchlaufende Quellsystem vorher bereits einmal händisch unlocked wurde? Ich hoffe man versteht worauf ich hinaus will.
Wäre es theoretisch realisierbar als keysource neben prompt, password auch noch auf ein keyfile zu referenzieren, welches auf dem Quell fs liegt und bspws. per smb freigegen und unlocked ist, so dass das Backuo System beim boot das Ziel fs automatisch unlocked? Vorausgesetzt natürlich das das durchlaufende Quellsystem vorher bereits einmal händisch unlocked wurde? Ich hoffe man versteht worauf ich hinaus will.
martingo
Experte
- Mitglied seit
- 17.01.2017
- Beiträge
- 1.300
Über die nappit GUI wahrscheinlich nicht. Per eigenem Skript auf jeden Fall. Ist theoretisch nur ein Einzeiler.
Verzeichnis mit Keyfile per NFS in der fstab (bzw. vfstab) verbinden. Dann in der rc.local Keyfile laden und Pool importieren.
-----------
Leider gibt es kein Quick-and-Dirty Bootscriptfile in Solaris wie rc.local.
So müsstest Du Dir ein existierendes Service File als Vorlage nehmen. Optional auch hier beim Start NFS mounten, Pool mit Keyfile importieren.
Beim Stop dann Pool exportieren und NFS umounten.
Verzeichnis mit Keyfile per NFS in der fstab (bzw. vfstab) verbinden. Dann in der rc.local Keyfile laden und Pool importieren.
-----------
Leider gibt es kein Quick-and-Dirty Bootscriptfile in Solaris wie rc.local.
So müsstest Du Dir ein existierendes Service File als Vorlage nehmen. Optional auch hier beim Start NFS mounten, Pool mit Keyfile importieren.
Beim Stop dann Pool exportieren und NFS umounten.
Ich nehme an, es geht darum dass eine Replikation ein Quell (oder Zieldatesystem) automatisch aufschließen kann.
Mit napp-it 19.dev könnte man dazu die Pre/Post Funktionalität nutzen. Wenn man da ein Script "/var/web-gui/_log/jobs/jobid.pre" anlegt (jobid= jobid des replikationsjobs) so wird dieses Script vor einer Replikation aufgerufen (also vor zfs receive oder zfs send).
Das Script könnte dann den Key bereitstellen, egal mit welchem Verfahren. Bei "prompt" müsste man Expect nutzen um den interaktiv bereitzustellen. Ein Perl Script dazu könnte so aussehen:
Ein zusätzliches script jobid.post könnte dann die Dateisysteme wieder abschließen
Den Schlüssel sollte man dann aber nicht lokal bereitstellen sondern wenigstens von einem USB Stick, besser einen iSCSI target oder per wget von einem Webserver beziehen.
Mit napp-it 19.dev könnte man dazu die Pre/Post Funktionalität nutzen. Wenn man da ein Script "/var/web-gui/_log/jobs/jobid.pre" anlegt (jobid= jobid des replikationsjobs) so wird dieses Script vor einer Replikation aufgerufen (also vor zfs receive oder zfs send).
Das Script könnte dann den Key bereitstellen, egal mit welchem Verfahren. Bei "prompt" müsste man Expect nutzen um den interaktiv bereitzustellen. Ein Perl Script dazu könnte so aussehen:
Code:
use Expect;
my $exp; #->raw_pty(1);
$exp = Expect->spawn("sudo /sbin/zfs key -l -r dateisystem") or die "Couldn't mount: $!\n";
$exp->expect(1,
[ 'Enter' =>
sub {
$exp->send("prompt\r");
exp_continue;
}
]
);
$exp->soft_close();Ein zusätzliches script jobid.post könnte dann die Dateisysteme wieder abschließen
Den Schlüssel sollte man dann aber nicht lokal bereitstellen sondern wenigstens von einem USB Stick, besser einen iSCSI target oder per wget von einem Webserver beziehen.
martingo
Experte
- Mitglied seit
- 17.01.2017
- Beiträge
- 1.300
Hi Günther,
ich spiele gerade mit den Appliance Maps herum und mir sind zwei Probleme für meinen Server aufgefallen:
- bei 3v gibt es in der Cols Anzahl nur ...,5,8,... - ich würde für den ML350p 6 Stück benötigen. Das konnte ich per Workaround lösen (im Browser Quelltext untersuchen und einen Wert auf 6 ändern).
- die Variante 2h gibt es bisher nicht, obwohl diese zumindest bei HP Server auch recht gebräuchlich ist. Per Workaround kann ich diesen Wert zwar auch einstellen, aber hierfür gibt es noch keine grafische Darstellung.
Wäre es eine Option, die beiden Dinge im nächten Dev Release zu berücksichtigen?
Viele Grüße
Martin
ich spiele gerade mit den Appliance Maps herum und mir sind zwei Probleme für meinen Server aufgefallen:
- bei 3v gibt es in der Cols Anzahl nur ...,5,8,... - ich würde für den ML350p 6 Stück benötigen. Das konnte ich per Workaround lösen (im Browser Quelltext untersuchen und einen Wert auf 6 ändern).
- die Variante 2h gibt es bisher nicht, obwohl diese zumindest bei HP Server auch recht gebräuchlich ist. Per Workaround kann ich diesen Wert zwar auch einstellen, aber hierfür gibt es noch keine grafische Darstellung.
Wäre es eine Option, die beiden Dinge im nächten Dev Release zu berücksichtigen?
Viele Grüße
Martin
Die Col-Anzahl läßt sich einfach in der "/var/web-gui/data/napp-it/zfsos/05_Disks and controller/12_Appliance_Maps=-lin/00_create_maps/action.pl" anpassen (Line 140: 1,2,4,6,8,..)
Die Bereitstellung von 2h (2,5" horizontal) ist aufwändiger da dann auch die ganzen Textplatzierungen angepasst werden müssen. Als Workaround für die Darstellung 3h nehmen. Ich setze das mal unverbindlich auf die Wish List. Aktuell komme ich aber nicht dazu, vor allem wegen der neuen Features in Illumos. Da ist erstmal ein Keyserver mit unlock via SMB in der Mache.
Die Bereitstellung von 2h (2,5" horizontal) ist aufwändiger da dann auch die ganzen Textplatzierungen angepasst werden müssen. Als Workaround für die Darstellung 3h nehmen. Ich setze das mal unverbindlich auf die Wish List. Aktuell komme ich aber nicht dazu, vor allem wegen der neuen Features in Illumos. Da ist erstmal ein Keyserver mit unlock via SMB in der Mache.
Danke für die Rückmeldungen, die Annahmen gehen in die richtige Richtung, idealerweise sollte das Ganze aber sogar unabhängig vom Replikationsjob sein.
Die Prämissen wären:
- Quellserver läuft immer und Quell fs ist immer unlocked
- Zielserver läuft nur sporadisch (bspws. 1x die Woche, bootet und unlocked das Ziel fs automatisch während des Starts, zu einem definierten Zeitpunkt fährt das System wieder herunter, bis zum nächsten mal.
- Replikationsjob läuft regelmässig während eines slots wo das Zielsystem verfügbar ist.
Muss mir das mit den pre und post Skripten mal näher ansehen, komme im Moment aber auch nicht richtig dazu, mir Zeit dafür zu nehmen.
Die Prämissen wären:
- Quellserver läuft immer und Quell fs ist immer unlocked
- Zielserver läuft nur sporadisch (bspws. 1x die Woche, bootet und unlocked das Ziel fs automatisch während des Starts, zu einem definierten Zeitpunkt fährt das System wieder herunter, bis zum nächsten mal.
- Replikationsjob läuft regelmässig während eines slots wo das Zielsystem verfügbar ist.
Muss mir das mit den pre und post Skripten mal näher ansehen, komme im Moment aber auch nicht richtig dazu, mir Zeit dafür zu nehmen.
andrer250282
Experte
- Mitglied seit
- 05.10.2015
- Beiträge
- 342
Hallo,
mal eine Frage... ich hab einen nappit Server als SMB Filer, läuft einwandfrei. Snaps sind aktiviert und funktionieren auch.
Unter Windows werden auf dem verbundenen Netzlaufwerk allerdings keine "Vorgängerversion wiederherstellen" sichtbar.
Eine Domäne hab ich nicht.
Hab ich eine Einstellung übersehen?
mal eine Frage... ich hab einen nappit Server als SMB Filer, läuft einwandfrei. Snaps sind aktiviert und funktionieren auch.
Unter Windows werden auf dem verbundenen Netzlaufwerk allerdings keine "Vorgängerversion wiederherstellen" sichtbar.
Eine Domäne hab ich nicht.
Hab ich eine Einstellung übersehen?
martingo
Experte
- Mitglied seit
- 17.01.2017
- Beiträge
- 1.300
nappit ist kein Server, sondern eine WebGUI (+x) für unterschiedliche Betriebssysteme und Services.
Insofern:
welches OS? Linux? Oracle Solaris? OmniOS? ...?
welcher SMB Dienst? Kernelfunktion von Solaris? Samba?
Im Idealfall sogar jeweils noch mit Versionen? Und sogar Config?
Insofern:
welches OS? Linux? Oracle Solaris? OmniOS? ...?
welcher SMB Dienst? Kernelfunktion von Solaris? Samba?
Im Idealfall sogar jeweils noch mit Versionen? Und sogar Config?
andrer250282
Experte
- Mitglied seit
- 05.10.2015
- Beiträge
- 342
Kein Problem,
die normale nappit OVA von nappit.org, durchgereichter B140i (Server ist ein ML30Gen9). 3x4TB als RAIDZ1, 1x 4TB Spare
config:
Noch mehr Infos benötigt?
die normale nappit OVA von nappit.org, durchgereichter B140i (Server ist ein ML30Gen9). 3x4TB als RAIDZ1, 1x 4TB Spare
config:
Code:
pool: tank
state: ONLINE
scan: scrub repaired 0 in 2h2m with 0 errors on Mon Oct 21 05:02:07 2019
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
c3t1d0 ONLINE 0 0 0
c3t2d0 ONLINE 0 0 0
c3t3d0 ONLINE 0 0 0
spares
c3t0d0 AVAIL
errors: No known data errors
Pool details zdb -C tank
MOS Configuration:
version: 5000
name: 'tank'
state: 0
txg: 3852022
pool_guid: 4952639535510411834
hostid: 1253576321
hostname: 'napp-it028'
com.delphix:has_per_vdev_zaps
vdev_children: 1
vdev_tree:
type: 'root'
id: 0
guid: 4952639535510411834
create_txg: 4
children[0]:
type: 'raidz'
id: 0
guid: 16858915214322509009
nparity: 1
metaslab_array: 39
metaslab_shift: 36
ashift: 9
asize: 12002320711680
is_log: 0
create_txg: 4
com.delphix:vdev_zap_top: 35
children[0]:
type: 'disk'
id: 0
guid: 4495926704472793605
path: '/dev/dsk/c3t1d0s0'
devid: 'id1,sd@SATA_____MB4000GVYZK_________________ZC16ZV2D/a'
phys_path: '/pci@0,0/pci15ad,7a0@16/pci103c,8165@0/disk@1,0:a'
whole_disk: 1
DTL: 159
create_txg: 4
com.delphix:vdev_zap_leaf: 36
children[1]:
type: 'disk'
id: 1
guid: 10476160904033746973
path: '/dev/dsk/c3t2d0s0'
devid: 'id1,sd@SATA_____MB4000GVYZK_________________ZC17027A/a'
phys_path: '/pci@0,0/pci15ad,7a0@16/pci103c,8165@0/disk@2,0:a'
whole_disk: 1
DTL: 158
create_txg: 4
com.delphix:vdev_zap_leaf: 37
children[2]:
type: 'disk'
id: 2
guid: 12772962802606645982
path: '/dev/dsk/c3t3d0s0'
devid: 'id1,sd@SATA_____MB4000GVYZK_________________ZC16ZA4L/a'
phys_path: '/pci@0,0/pci15ad,7a0@16/pci103c,8165@0/disk@3,0:a'
whole_disk: 1
DTL: 157
create_txg: 4
Code:
OmniOS 5.11 omnios-r151028-3aeadc46d9 March 2019
Zuletzt bearbeitet:
Dumme Frage: Hast Du überhaupt snapshots angelegt? Ohne snapshots keine Vorgängerversionen.
Happy Hepo
Experte
- Mitglied seit
- 16.01.2017
- Beiträge
- 225
Und nicht nur Snapshots angelegt, sondern die Dateien auch anschließend geändert? Sonst werden keine Vorgängerversionen angezeigt.
