Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Ich habe kurzerhand chrony installiert und das funktionierte sofort ohne Probleme. Ist glücklicherweise im OmniOS Repository drin und in Sekunden installiert.
Chrony steht wohl im Verdacht insbesondere in Virtualisierungsumgebungen zuverlässiger zu funktionieren als ntp. Was ich für meinen Anwendungsfall (OmniOS/nappit auf Proxmox) bestätigen kann.
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ich kann leider nichts erkennen. Das Log ist immer das Gleiche. Ob ich den Befehl jetzt ausführe oder die Seite neu lade. Ich bekomme keine verwertbaren Informationen zwischen dem Klick auf SetProperties und dem Neuladen der Seite.
Meine Schritte:
Klick "UNLOCK"
-> Passphrase eingeben
-> Pop-Up nach unten schieben
-> Klick EDIT/Log -> Monitor Extension Pop-Up erscheint zusätzlich (gelber Hintergrund)
-> Klick "SET PROPERTY" im UNLOCK-Pop-Up
-> Monitor Extension Pop-Up verschwindet und bringt beim Neuaufrufen das Gleiche, wie beim Reload der Seite ZFS-Filesystem
Contribute to omniosorg/lx-images development by creating an account on GitHub.
github.com
Wäre es möglich diese Images aufzunehmen, die Liste von Joyent die Nappit wohl benutzt erhält kaum noch updates
Das "neuste" Debian dort ist beispielsweise Version. Mittlerweile sind wir afaik sogar schon bei 11, wenn auch noch recht neu. In dem zweiten Link gibt es aber zumindest die 10er Version
1. ESXi
Das ist meine bevorzugte Lösung und arbeitet unterhalb aller VMs
Vorteil
Marktführer
beste Trennung der VMs inkl. Storage VM und schnellste Wiederherstellung im Crashfall
geringster Resourcenverbrauch für Virtualisierung
beste Performance auch für Nicht-Linux, z.B. Windows
Zugriff über iSCSI, NFS oder SMB (ZFS Snaps als Windows vorherige Version)
Nachteil
Zugriff auf ZFS über Netzwerkdateisystem NFS (etwas langsamer als Direktzugriff)
2. Linux LX Container
Vorteil:
sehr geringer Resourcenverbrauch je VM
direkter Zugriff auf ZFS Dateisysteme
Nachteil:
Man braucht immer angepasste Container. Ich habe den Eindruck dass Joyent/SmartOS (Alternative zu ESXi/Proxmox) weg geht von LX und Bhyve bevorzugt
Hab nen Gen10p. Da kann man leider den onboard Sata Contoller nicht durchreichen. Habe ich vorhin mal ausprobiert. Er bietet mir nur die Netzwerkkarten an und die M.2 die im PCIe Slot sitzt, der Rest ist ausgegraut.
Daher kommt nur Option 2 und 4 in Frage. Mit 2 habe ich mich aber schonmal beschäftigt. 4 noch nicht.
Was würdest Du für napp-it empfehlen, um regelmässig verschlüsselte (!) Backups auf entfernte Verzeichnisse vorzunehmen? Gibt es in Deinem Tool eine Funktion, die Cloud Backup kann? Oder ...
Ich habe eine Hetzner Storagebox und folgende Protokolle stehen mir zur Verfügung: FTP/FTPS/SAMBA/CIFS/SFTP/SCP/SSH/rsync/BorgBackup/WebDAV.
Um meine Frage zu beantworten. Ich nutze jetzt DUPLICATI. Läuft in meiner Home-Services-VM als Docker-Stack und sichert die relevanten Daten per WebDAV verschlüsselt und nach Zeitplan in die Cloud.
Wäre es möglich diese Images aufzunehmen, die Liste von Joyent die Nappit wohl benutzt erhält kaum noch updates
Das "neuste" Debian dort ist beispielsweise Version. Mittlerweile sind wir afaik sogar schon bei 11, wenn auch noch recht neu. In dem zweiten Link gibt es aber zumindest die 10er Version
Ich habe mir die OmniOS Images angeschaut. Es wäre prinzipiell möglich, die zu integrieren. OmniOS hat aber neuerdings mit zadm ein neues und sehr komfortables Tool um VMs zu installieren und zu verwalten.
Installation mit pkg install zadm ->
/opt/ooce/zadm/bin/zadm
Wechselfestplatte initialisiert. Pool backupa darauf angelegt und darauf wiederum ein verschlüsseltes Dateisystem backup. SMB Share = "off" (brauche ich nicht) / Status = "unlocked".
Replikation von /nas/syncthing (unverschlüsselt) auf /backupa/backup via Job: Quelle und Ziel eingegeben, Rest so belassen, wie es ist.
Ergebnis:
Ausgangssituation
/backupa/backup steht auf "UNLOCKED"
/backupa/backup/syncthing steht auf "AUTO". Datastore wurde bei erster Replikation automatisch angelegt.
Dateien sind auf Konsole sichtbar.
LOCK
In der Übersicht erscheinen /backupa/backup/ "LOCKED" und /extern/backup/syncthing weiterhin "AUTO"
Ordner /backupa/backup ist auf der Konsole leer. Also auch das Verzeichnis /backupa/backup/syncthing ist nicht sichtbar
UNLOCK
In der Übersicht erscheinen /backupa/backup/ "UNLOCKED" und /extern/backup/syncthing weiterhin "AUTO"
Verzeichnis /backupa/backup/syncthing wird auf Konsole angezeigt. Hat aber keinen sichtbaren Inhalt.
Mir ist gerade mal eingefallen, dass ich die Tage eine Replication vom rpool gemacht hatte, die habe ich gerade zurück gespielt und diese gestartet.
Die Meldungen bleiben, sonst ist nichts auffällig, in den Logs. Es ist aber leider nicht nur die Geschwätzigkeit von mdns, er scheint irgendwie nicht richtig zu funktionieren auf dem Host selber...
Problem "gelöst" da war was bei einem anderen Daemon nicht richtig konfiguriert warum es nicht ging. Keine Ahnung warum das vorher ging bzw. nie aufgefallen war. Jedenfalls ist die Ursache jetzt ausgemacht und gefixed.
Die "Geschwätzigkeit" von mdns kommt von diesen beiden Einträgen in den Bonjour Settings die gesetzt werden:
/usr/bin/dns-sd -R "fileserver" _adisk._tcp local 445 'sys=waMa=0,adVF=0x100' &
/usr/bin/dns-sd -R "fileserver" _adisk._tcp local 445 'dk0=adVN=Time Capsul,adVF=0x82' &
Darüber "beschwert" sich mdns, könnte man die beiden Records nicht ein einem Kommando übergeben?
/usr/bin/dns-sd -R "fileserver" _adisk._tcp local 445 'sys=waMa=0,adVF=0x100' 'dk0=adVN=Time Capsul,adVF=0x82' &
Weiss allerdings nicht ob das funktioniert, würde aber das "Gemecker" abstellen.
High Performance SAS Storage (2 x 12G SAS Multipath)
High performance, high capacity, viele Platten und hotplug capability sind typische Anforderungen für Storage. Für high performance ist der erste Gedanke NVMe. Wenn es dann um die Anzahl (Dutzende oder Hunderte) oder um Hotplug geht, überlegt man schnell 2x12G Multipath SAS oder 24G SAS in Zukunft
Übliche Kandidaten für SAS sind die bezahlbaren Samsung 1643, die WD SS 530 (die bisher beste SAS SSD, aber EoL mit der neueren SS540 die kaum zu kriegen ist)und der Seagate Nytro 3732 als Alternative.
Ich habe aktuell, wenn ich viel auf meinem Filer(Omnios r151038, nappit 21.06a) kopiere, das Problem, dass nappit abstürzt und nicht mehr erreichbar ist. In der Konsole werden dann folgende Fehlermeldungen geloggt:
Code:
Oct 8 13:39:42 Nappit syslogd: malloc failed: dropping message: Resource temporarily unavailable
Oct 8 13:39:22 Nappit vmxnet3s: [ID 780383 kern.warning] WARNING: vmxnet3s0: ddi_dma_mem_alloc() failed
Oct 8 13:39:22 Nappit last message repeated 110 times
Oct 8 13:39:25 Nappit appl-mhttpd[28262]: [ID 496990 daemon.crit] fork - Not enough space
Oct 8 13:39:25 Nappit tmpfs: [ID 518458 kern.warning] WARNING: /etc/svc/volatile: File system full, swap space limit exceeded
Oct 8 13:39:25 Nappit last message repeated 1 time
Oct 8 13:39:29 Nappit vmxnet3s: [ID 780383 kern.warning] WARNING: vmxnet3s0: ddi_dma_mem_alloc() failed
Oct 8 13:39:29 Nappit last message repeated 98 times
Oct 8 13:39:29 Nappit vmxnet3s: [ID 201569 kern.warning] WARNING: vmxnet3s0: ddi_dma_alloc_handle() failed: -1
Oct 8 13:39:29 Nappit last message repeated 1 time
Oct 8 13:39:30 Nappit vmxnet3s: [ID 780383 kern.warning] WARNING: vmxnet3s0: ddi_dma_mem_alloc() failed
Oct 8 13:39:30 Nappit last message repeated 4 times
Oct 8 13:39:30 Nappit vmxnet3s: [ID 201569 kern.warning] WARNING: vmxnet3s0: ddi_dma_alloc_handle() failed: -1
Die vmxnet Meldungen wiederholen sich dann munter einige Sekunden, und nach kurzer Zeit (bis ich per ESX-Webkonsole auf dem Filer bin) kann ich nappit per /etc/init.d/nappit start wieder starten.
Was kann ich dagegen tun? Mehr RAM geht aktuell nicht.
Das scheint doch eher ein Problem der vmxnet3 und nicht napp-it. Mal den Typ der vnic auf e1000 ändern? Ansonsten besser bug Report bei OmniOS machen / über Gitter oder Illumos E-Mail Liste nachfragen.
Pool VER RAW SIZE/ USABLE ALLOC RES FRES AVAIL zfs [df -h/df -H] DEDUP FAILM EXP REPL Alt GUID HEALTH Autotrim SYNC ENCRYPT ACTION ATIME PriCache SecCache ACLinherit ACLmode CP Rdonly
rpool 5000 9.50G/ 9.2G 2.16G - - 7.05G [7.1G /7.6G] 1.00x wait off off - 14615979958786191192 ONLINE off standard off clear errors off all all restricted discard no no
Ich interpretiere das so, das da noch 7GB frei sind, oder liege ich da falsch?
Laut df -H betrifft ja das FS unter /etc/svc/volatile, das ist ein swapfs:
Code:
Filesystem Size Used Available Capacity Mounted on
rpool/ROOT/r151038 18.89G 874.70M 16.73G 5% /
...
swap 460.82M 340K 460.49M 1% /etc/svc/volatile
(ich hatte gesehe, dass die Plttenerweiterung nicht den Pool erweitert hatte, autoexpand hatte direkt gezogen zwischen den beiden Ausgaben)
wieviel RAM?
Eventuell ist das swap Volume zu klein. (1/4 RAM). 460 M swap reicht nichtmal ganz für 2GB RAM. Wenn es ein Crash Dump Volume gibt, sollte das 1/2 RAM groß sein. 7G freier Platz ist da schnell nichts. 9GB Plattengröße für rpool ist schlicht zuwenig. Ich sehe eher 30 GB als Minimum damit man vorherige Systemstände/Bootenvironments halten kann. Auch ein Update auf ein neueres OmniOS Release wird Probleme machen.
Bei 12G RAM siehts bei meinem Testserver so aus
Code:
NAME used avail refer
rpool/dump 1.50G 14.1G 1.50G none standard off off off 1.50G 128K - -
rpool/swap 1.03G 14.9G 215M none standard off lz4 off 1G 8K - -
This book is for anyone responsible for administering one or more systems that run the Oracle Solaris 11 release. The book covers a range of Oracle Solaris system administration topics related to managing removable media, disks and devices and file systems.Topics are described for both SPARC...
Problem "gelöst" da war was bei einem anderen Daemon nicht richtig konfiguriert warum es nicht ging. Keine Ahnung warum das vorher ging bzw. nie aufgefallen war. Jedenfalls ist die Ursache jetzt ausgemacht und gefixed.
Die "Geschwätzigkeit" von mdns kommt von diesen beiden Einträgen in den Bonjour Settings die gesetzt werden:
/usr/bin/dns-sd -R "fileserver" _adisk._tcp local 445 'sys=waMa=0,adVF=0x100' &
/usr/bin/dns-sd -R "fileserver" _adisk._tcp local 445 'dk0=adVN=Time Capsul,adVF=0x82' &
Darüber "beschwert" sich mdns, könnte man die beiden Records nicht ein einem Kommando übergeben?
/usr/bin/dns-sd -R "fileserver" _adisk._tcp local 445 'sys=waMa=0,adVF=0x100' 'dk0=adVN=Time Capsul,adVF=0x82' &
Weiss allerdings nicht ob das funktioniert, würde aber das "Gemecker" abstellen.
Danke!
Im aktuellen napp-it sind beide Befehle jetzt zu einem Befehl zusammengefasst.
Wer einen Mac hat und TimeMachine über SMB nutzen möchte, OmniOS als "Time Capsule" einbinden möchte oder mit einem chicken Xserve Icon anzeigen möchte, kann das ja mal testen. (Menü Service > Bonjour)
mir ist im napp-it esxi hot snapp ein möglicher Fehler begegnet.
Nach einem Umzug auf eine größere SSD für die VMs, inkl. re import im ESXi haben die hot snaps nicht mehr funktioniert. Habe den Snap sowie den pre job neu eingerichtet inkl Verbindung zum ESXi.
Er hat aber dennoch keine ESXi Snapshots ausgeführt.
Es hat sich herausgestellt, dass sich die vmids geändert haben, aber napp it hat im "esxivms.log" die Einträge nicht geändert/aktualisiert. Erst als ich die Liste manuell geleert habe und die VMs erneut über napp-it eingelesen habe, ging es.
Filer ist Solaris 11.4
Napp-it ist Free 21.06a4
ESXi ist 7u3.
Das hatte ich mehrfach gemacht - dadurch bin ich ja auf die vmid gekommen, weil die da dann ja aufgelistet werden.Ich hatte wie geschrieben, alle Schritte neu durch exerziert, sogar mehrfach.Half nur eben nicht.
Würde ich schon so sehen(Zumindest bin ich davon ausgegangen).VMs die dann davon ausgenommen werden sollen, kann man ja im nächsten Schritt wieder löschen.So habe ich das gemacht.
Oder die Liste einfach erweitern würde - weil das hat ja bei mir auch nicht geklappt (Wenn das aktuell so funktionieren sollte).Was nicht da ist, kann ja nicht ausgeführt werden.
wieviel RAM?
Eventuell ist das swap Volume zu klein. (1/4 RAM). 460 M swap reicht nichtmal ganz für 2GB RAM. Wenn es ein Crash Dump Volume gibt, sollte das 1/2 RAM groß sein. 7G freier Platz ist da schnell nichts. 9GB Plattengröße für rpool ist schlicht zuwenig. Ich sehe eher 30 GB als Minimum damit man vorherige Systemstände/Bootenvironments halten kann. Auch ein Update auf ein neueres OmniOS Release wird Probleme machen.
Aktuell habe ich 16 GB zugewiesen, und von r151026 an (abgesehen vom obigen) ohne Probleme mit 10GB Bootdisk geupdated. Nicht optimal, ich hatte vor einigen Montaten auch die vDisk vergrößert, aber auto-expand (bis gestern) vergessen.
swap -l sagt mir, ich hätte gar keine Swap devices konfiguriert, df -h sagt mir allerdings, ich hätte noch zwei weitere swaps (/tmp; /var/run) gemounted. Wie kann das sein? Woher kommt der Swap, wenn nichts konfiguriert war?
Ich habe jetzt ein 4G Swap volume eingebunden, allerdings bekomme ich dabei die Meldung, dass das dump device nicht groß genug ist. Ich würde vermuten, da kein Swap eingrichtet war, dass auch kein dump volume eingerichtet ist (dumpadm bestätigt das). swap -l gibt das Swap volume passend an.
Soweit ich das sehen, habe ich abgesehen von der Möglichkeit, den Crash zu untersuchen/Bugreport/..., keine weiteren Vorteile durch ein dump volume(Nachteile wenn fehlend)?
Ich werde es jetzt weiter beobachten, und hoffe, dass das Problem dadurch gelöst ist. Danke schonmal!
Habe 12x 4TB Festplatten + 1x 4TB Hot Spare. Aktuell läuft da ein Mirrored + Striped vdev aka. RAID 10. Das ganze bringt jedoch nicht die Performance die ich erwartet habe. Was denkt ihr eigentlich ist auch Redundanzsicht sinvoller? In diesem System ist z.B. im Falle eines Ausfalls die Redundanz relativ schnell wiederhergestellt, da Daten nur kopiert werden müssten. Bei einem RAID-Z muss ja der gesamte Verbund "umgeschrieben" werden. Jedoch bietet bspw. ein RAID-Z3 aus Redundanz und Speichernutzung natürlich auch eine gute Option. Oder vielleicht was ganz anderes, in Richtung RAID 60? Habt ihr eventuell eine Idee wie ihr die insgesamt 13x 4TB Platten nutzen würdet?
Verkaufen und neue große Platten kaufen ... Weniger Lärm Platzbedarf und Strom. Neue Garantie. Künftige Ausbaufähigkeit. Ggfs. mehr RAM und danach evtl 2x SSD als mirrored Special vdev für Metadaten und kleine Dateien.
Habe 12x 4TB Festplatten + 1x 4TB Hot Spare. Aktuell läuft da ein Mirrored + Striped vdev aka. RAID 10. Das ganze bringt jedoch nicht die Performance die ich erwartet habe. Was denkt ihr eigentlich ist auch Redundanzsicht sinvoller? In diesem System ist z.B. im Falle eines Ausfalls die Redundanz relativ schnell wiederhergestellt, da Daten nur kopiert werden müssten. Bei einem RAID-Z muss ja der gesamte Verbund "umgeschrieben" werden. Jedoch bietet bspw. ein RAID-Z3 aus Redundanz und Speichernutzung natürlich auch eine gute Option. Oder vielleicht was ganz anderes, in Richtung RAID 60? Habt ihr eventuell eine Idee wie ihr die insgesamt 13x 4TB Platten nutzen würdet?
Die Frage ist eher was brauchst du, oder gehts nur darum bestehende Platten irgendwie in ein Raid zu packen? Bei 4TB Platten und wenn man die Performance aus einem Array mit 12 Platten nicht benötigt würde ich eher dazu tendieren größere Platten zu kaufen.
Also welchen Platz brauchst du und welche Performance brauchst du wäre erstmal zu klären.
Will man Performance macht es eventuell Sinn je nach Kapazität die man braucht einfach 2 SSDs im Mirror herzunehmen und "manuelle Datentrennung" vorzunehmen
