Software unter Solaris installiert man am Einfachsten, indem man
ein Repository (Softwareverzeichnis zum Download, z.B. OpenIndiana-sfe)
angibt und das Programm dann mit "pkg install programmname" installiert.
OpenIndiana sfe ist aber
- schlecht gewarted
- sollte/könnte mit OmniOS nicht sauber funktionieren da auf OI ausgelegt
Man müsste also entweder
- schauen ob es ein OmniOS Software-Verzeichnis gibt das obige Sachen enthält (eher unwahrscheinlich)
- oder das universelle Joyent pkgsrc Software-Verzeichnis für Illumos (damit für OmniOS und OpenIndiana) nimmt
pkgsrc
Index of /packages/illumos/
Für speziellere Sachen ist letzere Option die sinnvollste.
Zuletzt bearbeitet:
ludwinator
Enthusiast
- Mitglied seit
- 28.12.2006
- Beiträge
- 532
Joyent benutzt ein anderes Installations-Verfahren (pkgin) als Solaris mit pkg (IPS)
Anleitung
3. Installing software and package management - OpenIndiana - OpenIndiana Wiki
Zuletzt bearbeitet:
GrafikTreiber
Enthusiast
- Mitglied seit
- 25.12.2005
- Beiträge
- 1.531
Musst du ja auch erstmal installieren...
Installing pkgin - SmartOS Documentation - SmartOS Wiki
Natürlich die aktuellen Files verwenden und nicht die im Tutorial verlinkten veralteten.
Installing pkgin - SmartOS Documentation - SmartOS Wiki
Natürlich die aktuellen Files verwenden und nicht die im Tutorial verlinkten veralteten.
Zuletzt bearbeitet:
Mglw ist das Verzeichnis /opt/local/bin nicht in Deinem PATH. Versuch mal
/opt/local/bin/pkgin -y install ffmpeg
Wenns klappt sollte meine Vermutung richtig sein, wenn nicht ist pkgin nicht (richtig) installiert.
gibt es zfs nicht auch in benutzerfreundlich? Ich habe irgendwie nicht die Zeit dafür das ganze erst zu studieren. Im Grunde komme ich mir da vor wie in den 80er
Gibt es nicht 2 Befehle die man eintippt und dann läuft es?
Bei Windows gibt es diese ganzen dependencies auch nicht. Da kann man einfach nen setup starten, wieso geht das bei Omnios nicht?
Zuletzt bearbeitet:
Was hat das mit ZFS zu tun, wenn man etwas installieren möchte, das nicht vorhanden ist.
Läuft denn ein Windows Installer wenn man den Installer nicht hat oder ein 64 Bit Installer auf einem 32Bit Windows?
Problem ist eher, dass es eben nicht soviel Programme außerhalb des "klassischen Serverbereichs" gibt.
Apache, PHP oder mySQL ist unter Linux/ Unix eher einfacher zu (de)installieren als unter Windows.
Da tut es ein apt-get/ pgin oder pkg install Apache (je nachdem welches Packetformat)
Einen Medienserver mit allen Abhängigkeiten - da muss jemand einen Installer schreiben und pflegen.
(siehe Mediatomb installer für OmniOS). Das ist aufwändig, bedarf ständiger Pflege da es Abhängigkite gibt und die Bestandteile von verschiedenen Quellen geladen werden müssen - und es gibt eben nicht soviel Nutzer. Da heißt es manchmal warten bis der Installer upgedated wird wenn es irgendwo ein Update gibt. Viele nutzen ohnehin dafür Windows oder ein Fertignas wie Synology das genau da Vorteile hat und verzichten dafür auf Highend Storage Features.
Alternativen wären jetzt
- Sich mit Unix beschäftigen
- Nur ein NAS und ein Mediaclient der nur ein SMB Share braucht
- Windows und kein ZFS
- Virtualisieren (und OSX oder Windows als Medienserver)
Zuletzt bearbeitet:
1 scheidet aus. Ich find es ja nicht schlecht nur eben viel zu wenig benutzerfreundlich. Ich habe einfach nicht die Zeit mich damit zu beschäftigen. OmniOS als NAS mit SMB Shares is ja fix eingerichtet aber alles was net drin ist braucht einfach zuviel Ressourcen in Form von Zeit. Glaube bin auch nicht der einzige der das nicht aufbringen kann und will.
Glaube ich werde eher virtualisieren und dann für alle Dienste ein OS benutzen was benutzerfreundlicher aufgebaut ist.
Mediatomb geht ja aktuell auch nicht mehr mit dem Script. Wenn sich nochmal jemand dransetzt sollte man Mediatomb durch Serviio ersetzen IMO da die Entwicklung bei Mediatomb schon lange aufgehört hat.
Ich glaube dennoch dass man beim Thema Benutzerfreundlichkeit nicht wirklich diskutieren muss dass Windows hier Meilenweit vorne liegt.
Zuletzt bearbeitet:
Sehe ich prinzipiell genauso wobei nicht Windows sondern eher OSX das Maß ist.
Es ist aber auch so, dass Unix mit CLI wie auch Windows Server (CLI Version) keine
Systeme für normale Endbenutzer sind sondern etwas für professionelle Nutzer mit
Fokus auf Stabilität und spezielle Serverdienste.
würde mich auch mal interessieren. Ich weiss nur dass sie beide als ZFS Basis illumos benutzen. Illumos wird ja weiter entwickelt. Würde mich interessieren ob Nexenta und omnios immer ALLE erneuerungen von illumos integrieren oder ob es da auch unterschiede gibt. Ausserhalb von ZFS gibt es zB den Unterschied das Nexenta ein neueren SMB Kernel benutzt.
Ich versuche mal eine Antwort - auch wenn ich nicht nicht ganz unvoreingenommern bin:
Vor ca 5-6 Jahren entwickelte SUN eine neue Version von Solaris. Wohl um Marktanteile gegen Linux/ Windows NT zu gewinnen, veröffentlichten Sie das zu 90% als OpenSource. Es enthielt damals (und heute immer noch) revolutionäre Entwicklungen wie ZFS, dtrace, Comstar, Crossbow oder den kernelbasierenden CIFS Server - und das alles aus einer Hand als OpenSolaris. Es sollte die Basis des nächsten kommerziellen Solaris werden.
Mehrere Firmen haben darauf aufbauend eigene Produkte entwickelt und Ihre Firmen darauf ausgerichtet.
Als Oracle dann Sun übernahm wurde das freie OpenSolaris eingestellt und es wurde daraus Solaris 11 als closed source. Firmen wie Delphix, Joyent oder Nexenta initierten dann einen freien Fork von OpenSolaris. Die Closed Source Bestandteile von OpenSolaris wurden wo nötig neu entwickelt. Das alles geschah im Projekt Illumos, der gemeinsamen Basis der drei (und anderer kleinerer Firmen). Ziel ist keine fertige Distribution, sonern die gemeinsame Weiterentwicklung des Kernsystems und der Basistools. Viele ZFS Entwickler von Sun wechselten zu diesen Firmen.
Die erste verfügbare Distribution, noch ganz im Sinne von OpenSolaris (auch als Desktopversion) war OpenIndiana als reines Opensoure und Community Projekt ohne kommerziellen Background. Eine weitere war SmartOS (Focus als Cloud-OS mit KVM) und OmniOS als general use Server-OS mit kommerziellem Background. Auch Nexenta hat seinen Storageserver von OpenSolaris auf Illumos umgestellt.
Soviel zur Geschichte
Insgesamt sieht es so aus, dass Firmen wie Joyent, Nexenta oder OmniOS aber auch OpenIndiana Illumos als Basis nehmen, aber eine eigene Distribution daraus ableiten, nicht alles sofort übernehmen und nicht alle eigenen Entwicklungen immer oder automatisch zurück in Illumos integrieren. SMB2 oder VAII von Nexenta ist da ein Beispiel. Nexenta hat das zwar frei veröffentlicht, es aber nicht selber in Illumos integriert. Man muss also darauf warten bis es ein anderer macht. (Ist ja auch nicht unbedingt im Interesse von Nexenta).
Zum Unterschied Nexenta vs Solaris/OI/OmniOS
Nexenta ist eîne reine Storagefirma mit dem Produkt NexentaStor. Es wird in der Regel zusammen mit zertifizierter Hardware und Support über authorisierte Händler vertrieben. Der Preis richtet sich nach Supportlevel und Kapazität. Andere Anwendungen sind möglich und führen zum Verlust des Supports. Es gibt davon eine Community Edition. Die ist auf 18 GB RAW beschränkt und darf nicht kommerziell genutzt werden.
Die Alternative ist Oracle Solaris (auch nicht kommerziell frei nutzbar), OmniOS und OpenIndiana (letztere auch kommerziell frei nutzbar). Auf Basis dieser Systeme gibt es auch napp-it, entweder als GUI add-on oder als Komplettdistributione mit OmniOS (napp-it to-go oder napp-in-on als VM). Hauptzielgruppe von napp-it ist SoHo, Edu und high-capacity für Firmen mit eigener IT. Napp-it ist bei weitem nicht so groß wie Nexenta und bietet auch keinen Support mit SLA - ist dafür aber auch kostenlos bzw als Pro Version viel günstiger.
Vor ca 5-6 Jahren entwickelte SUN eine neue Version von Solaris. Wohl um Marktanteile gegen Linux/ Windows NT zu gewinnen, veröffentlichten Sie das zu 90% als OpenSource. Es enthielt damals (und heute immer noch) revolutionäre Entwicklungen wie ZFS, dtrace, Comstar, Crossbow oder den kernelbasierenden CIFS Server - und das alles aus einer Hand als OpenSolaris. Es sollte die Basis des nächsten kommerziellen Solaris werden.
Mehrere Firmen haben darauf aufbauend eigene Produkte entwickelt und Ihre Firmen darauf ausgerichtet.
Als Oracle dann Sun übernahm wurde das freie OpenSolaris eingestellt und es wurde daraus Solaris 11 als closed source. Firmen wie Delphix, Joyent oder Nexenta initierten dann einen freien Fork von OpenSolaris. Die Closed Source Bestandteile von OpenSolaris wurden wo nötig neu entwickelt. Das alles geschah im Projekt Illumos, der gemeinsamen Basis der drei (und anderer kleinerer Firmen). Ziel ist keine fertige Distribution, sonern die gemeinsame Weiterentwicklung des Kernsystems und der Basistools. Viele ZFS Entwickler von Sun wechselten zu diesen Firmen.
Die erste verfügbare Distribution, noch ganz im Sinne von OpenSolaris (auch als Desktopversion) war OpenIndiana als reines Opensoure und Community Projekt ohne kommerziellen Background. Eine weitere war SmartOS (Focus als Cloud-OS mit KVM) und OmniOS als general use Server-OS mit kommerziellem Background. Auch Nexenta hat seinen Storageserver von OpenSolaris auf Illumos umgestellt.
Soviel zur Geschichte
Insgesamt sieht es so aus, dass Firmen wie Joyent, Nexenta oder OmniOS aber auch OpenIndiana Illumos als Basis nehmen, aber eine eigene Distribution daraus ableiten, nicht alles sofort übernehmen und nicht alle eigenen Entwicklungen immer oder automatisch zurück in Illumos integrieren. SMB2 oder VAII von Nexenta ist da ein Beispiel. Nexenta hat das zwar frei veröffentlicht, es aber nicht selber in Illumos integriert. Man muss also darauf warten bis es ein anderer macht. (Ist ja auch nicht unbedingt im Interesse von Nexenta).
Zum Unterschied Nexenta vs Solaris/OI/OmniOS
Nexenta ist eîne reine Storagefirma mit dem Produkt NexentaStor. Es wird in der Regel zusammen mit zertifizierter Hardware und Support über authorisierte Händler vertrieben. Der Preis richtet sich nach Supportlevel und Kapazität. Andere Anwendungen sind möglich und führen zum Verlust des Supports. Es gibt davon eine Community Edition. Die ist auf 18 GB RAW beschränkt und darf nicht kommerziell genutzt werden.
Die Alternative ist Oracle Solaris (auch nicht kommerziell frei nutzbar), OmniOS und OpenIndiana (letztere auch kommerziell frei nutzbar). Auf Basis dieser Systeme gibt es auch napp-it, entweder als GUI add-on oder als Komplettdistributione mit OmniOS (napp-it to-go oder napp-in-on als VM). Hauptzielgruppe von napp-it ist SoHo, Edu und high-capacity für Firmen mit eigener IT. Napp-it ist bei weitem nicht so groß wie Nexenta und bietet auch keinen Support mit SLA - ist dafür aber auch kostenlos bzw als Pro Version viel günstiger.
Hey alle zusammen,
habe jetzt auf meinen Hyper-V Server Ubuntu und ZOL am laufen. Funktioniert alles perfekt. (aktuell mit 2*500GB Testplatten, die ich noch hatte).
Will mir jetzt produktiv-Platten kaufen. Habe vor, ein RAIDz1 aufzubauen. Mir stellt sich aber aktuell die Frage, ob es intelligenter ist, 4*2TB oder 3*3TB laufen zu lassen. Nutzkapazität ist ja die Gleiche. Von der Ausfallsicherheit sollte ja die 3*3TB besser sein, wobei ich denke, dass das fast nicht ins Gewicht fällt.
Mich würde die Performance interessieren, da auf dem Volumen auch noch VM's laufen soll. Könnt ihr mir da ungefähre Vergleichswerte nennen? System ist ein Intel Xeon 1230V2 (8 Threats und 8GB Ram für die VM). Und ist es möglich, eine SSD als schreib/lese-Catch nachher noch zusätzlich anzufügen?
habe jetzt auf meinen Hyper-V Server Ubuntu und ZOL am laufen. Funktioniert alles perfekt. (aktuell mit 2*500GB Testplatten, die ich noch hatte).
Will mir jetzt produktiv-Platten kaufen. Habe vor, ein RAIDz1 aufzubauen. Mir stellt sich aber aktuell die Frage, ob es intelligenter ist, 4*2TB oder 3*3TB laufen zu lassen. Nutzkapazität ist ja die Gleiche. Von der Ausfallsicherheit sollte ja die 3*3TB besser sein, wobei ich denke, dass das fast nicht ins Gewicht fällt.
Mich würde die Performance interessieren, da auf dem Volumen auch noch VM's laufen soll. Könnt ihr mir da ungefähre Vergleichswerte nennen? System ist ein Intel Xeon 1230V2 (8 Threats und 8GB Ram für die VM). Und ist es möglich, eine SSD als schreib/lese-Catch nachher noch zusätzlich anzufügen?
Bzzz
Enthusiast
Bei 4x2 ist auch ein gestripter Mirror möglich, der schneller ist als ein RAIDZ. Allerdings noch weniger Nutzkapazität, und Platten sind halt auch nur Platten und keine SSDs. Andererseits sind die 3TBs momentan in Sachen €/GB günstiger (sogar insgesamt am günstigsten), und das wird sich auch nicht mehr umkehren. Ausfallsicherheit ist bei weniger Platten besser, dafür ist der Rebuild und auch Scrub bei mehr Platten schneller. Für ein Z1 sind 4 Laufwerke nicht optimal, da das nicht 2^x Datenplatten plus Parity sind. Bei ZIL und L2ARC muss man schauen, ob sich das beim gegebenen Workload überhaupt rechnet.
Kurze Frage in eigener Sache, sogar daran anschließend: Wenn ich einzelne ZFS per send/receive von nem RAIDZ2 auf einen Stripe kopiere (repliziere), und dann unterschiedliche "used"-Werte angezeigt bekomme, ist das ein Effekt des ungünstigen Z2s-Aufbaus mit total 8 Platten? Effekte von Compression und Dedup schließe ich mal aus, da die ZFS je ab Start entweder compression=on oder off hatten, und Dedup gar nicht mehr verwendet wird. Und bei den richtigen send/receive-Optionen werden ja alle Einstellungen bei der Erstellung des Ziel-ZFS übernommen. Snapshots werden ja auch mitgenommen. Einzig die Poolversionen scheinen mir unterschiedlich, da das aktuelle Solaris gleich 35er anlegt, der Quellpool aber noch ein 34er ist.
Kurze Frage in eigener Sache, sogar daran anschließend: Wenn ich einzelne ZFS per send/receive von nem RAIDZ2 auf einen Stripe kopiere (repliziere), und dann unterschiedliche "used"-Werte angezeigt bekomme, ist das ein Effekt des ungünstigen Z2s-Aufbaus mit total 8 Platten? Effekte von Compression und Dedup schließe ich mal aus, da die ZFS je ab Start entweder compression=on oder off hatten, und Dedup gar nicht mehr verwendet wird. Und bei den richtigen send/receive-Optionen werden ja alle Einstellungen bei der Erstellung des Ziel-ZFS übernommen. Snapshots werden ja auch mitgenommen. Einzig die Poolversionen scheinen mir unterschiedlich, da das aktuelle Solaris gleich 35er anlegt, der Quellpool aber noch ein 34er ist.
Die sequentielle Performance eines Raid-Z skaliert mit der Anzahl der Datenplatten. Die Option mit 4 Platten ist da schneller. Die für eine VM wichtigere IO Performance für wahlfreies Lesen/Schreiben ist aber gleich und entspricht einer Platte da bei jeden Zugriff alle Platten positioniert werden müssen.
Da ist ein Raid-10 aus 4 Platten doppelt so schnell. Ich würde deshalb ein Raid-10 machen. Ansonst immer möglichst wenige und große Platten nehmen und da wo Performance wichtig ist gleich auf SSD Pools gehen.
Eine Lese-Cache SSD (L2ARC) kann man jederzeit hinzufügen/entfernen.
Eine Schreib-Cache SSD gibt es nicht. Es gibt aber eine SSD als ZIL/Logedevice. Die wird aber nur im Falle eines Crash beim Schreiben ausgelesen um beim nächsten Neustart die letzte Schreibaktion zu vollenden. Auch die kann man jederzeit hinzufügen/ entfernen.
- - - Updated - - -
Es gibt den Effekt, dass 4k Platten einen größeren "Verschnitt" haben als 512B Platten - insbesondere bei nicht optimaler Anzahl von Datenplatten je vdev (2,4,8,16,..). Ansonsten werden nicht alle Pooleigenschaften per default oder überhaupt übernommen. Das gilt für Compress aber auch für Zwischensnaps. Auch da kann der Unterschied herkommen.
Bzzz
Enthusiast
Oh f..., daran hatt ich nicht gedacht. Ja, der große Pool ist 4K mit entsprechendem ashift, der Stripe besteht aus zwei echten 512B-Platten. Na, mir solls recht sein, passt mehr aufs Backup.
Die Formulierung impliziert, dass Dedup mal eingeschaltet war. Wenn man Dedup ausschaltet bedeutet das ja nicht, dass alle Daten dann sofort wieder dupliziert werden (also wieder im Original gespeichert werden), sondern nur alle zukünftig gespeicherten. Selbst die Ausgabe des Dedupratios von 1,00 heißt ja nicht, dass die weiteren Dezimalstellen Null sind.
Bzzz
Enthusiast
Ich hatte bis vor drei Wochen zwei Filesysteme auf meinem Datenpool, ein sehr großes mit compression und dedup=off, und ein kleines mit beiden =on. Naturgemäß ist das ne recht grobe Aufteilung der Daten, sodass ich das auf ein paar mehr ZFS aufgeteilt, d.h. per Hand umkopiert habe. Für alle fraglichen Gruppen hab ich die Kompressions- und Dedupratio an den realen Daten (in nem Test-Filesystem) ermittelt, dann das finale ZFS mit den richtigen Parametern dafür angelegt, und schließlich die Daten verschoben. Kompression gabs bei allen ab 1.05x (waren aber alle weit näher an 1.1x oder mehr), für Dedup (1.2x++) waren nur ein paar VM-Ordner (und Ordnerteile, die ich anderweitig zusammengeführt habe) interessant, die nach Performancetests und den mickrigen absoluten Einsparungen dann aber doch nur auf compression=on gesetzt wurden. Die beiden Ursprungs-ZFS wurden dann samt ihrer Snapshots gelöscht. Also geh ich davon aus, dass keine Deduptables mehr geführt werden, denn es existieren keine deduplizierten Daten mehr.
woran kann es liegen dass der Server (OmniOS/Nappit) die SMB/CIFS Passwörter nicht mehr nimmt. Habe einen Pool importiert weil ich den Server neu aufgesetzt habe. Hab dann User neu angelegt mit Passwörtern doch die Passwörter werden nicht angenommen wenn man auf die Freigabe zugreifen will über Windows7/8
Das ist auch nicht anders als wenn man Windows neu aufsetzt und dann auf eine alte Datenplatte zugreifen möchte oder unter Windows irgendeine eine fremde Platte anschließt auf der Sicherheitseinschränkungen gesetzt sind. Das Ergebnis ist ist immer access denied.
Unter Solaris geht das wie unter Windows: Rechte zurücksetzen bzw. neu setzen.
ps
Wenn man neue User mit der gleichen UID anlegt, könnte es funktionieren - habe es noch nicht getestet. Das Gute/Problem bei Solaris ist dass Windows SID benutzt werden und nicht nur Unix UID wie z.B. bei SAMBA.
Zuletzt bearbeitet:
Werden die dann einfach überschrieben wenn ich Freigabe aus und wieder an mache? Oder muss ich da mit irgendnem Befehl das ganze manuell machen. Geht das über reset ACLs ?
Folder ACL und Share ACL stehen wieder auf default, wie bei ner frischen Installation. Da hatte ich was angepasst mit der alten Installation. Hatte 2 Guest Freigaben die hat er aber direkt erkannt und übernommen da musste ich netmal was einstellen nach dem Import
Zuletzt bearbeitet:
Die file and folder ACL Einstellungen gelten nur für neue Dateien/ Ordner.
Vorhandene ACL bleiben natürlich erhalten und müssen recursiv zurückgestellt werden, entweder per
- napp-it ACL extension (eventuell evalkey nutzen)
- CLI und /usr/bin/chmod
- Von Windows aus wenn man sich als root am Share anmeldet
Elmario
Urgestein
- Mitglied seit
- 21.01.2006
- Beiträge
- 5.267
Hallo, Stammtischler!
Über ZFS liest man ja die wildesten Gerüchte.. wie z.B 1GB Ram pro TB HD-Kapazität..
Also:
Brauche ich wirklich 32GB RAM wenn ich ein Raid-Z3 aus 8 * 4TB Platten bauen möchte?
Ich will keine SuperDuper-Ultra Performance (eigentlich ist mir diese sogar ziemlich wurscht, ich will nur Datensicherheit!)
Über ZFS liest man ja die wildesten Gerüchte.. wie z.B 1GB Ram pro TB HD-Kapazität..
Also:
Brauche ich wirklich 32GB RAM wenn ich ein Raid-Z3 aus 8 * 4TB Platten bauen möchte?
Ich will keine SuperDuper-Ultra Performance (eigentlich ist mir diese sogar ziemlich wurscht, ich will nur Datensicherheit!)
Bzzz
Enthusiast
Eher 5GB/TB, wenn du Dedup benutzen willst. WENN.
Ansonsten ist mehr RAM zwar immer besser, aber solange das System installiert und geladen werden kann (1-2GB), ist erstmal alles dufte. Du siehst dann schon, wenn zuwenig Speicher ein Bottleneck wird. Bei den heutigen Preisen ists aber eh schwer, einem solchen Rechner für 1000€ Festplatten zu spendieren, und ihn dann an zu wenig RAM krepieren zu lassen.
Multiuserbetrieb haben viele hier ja gar nicht vor, manche lassen die Kiste auch nur bei Bedarf laufen, sodass ein Lesecache im RAM gar nicht voll zur Geltung kommt. Ist halt wie so oft fallspezifisch, 8x4TB sagt noch sehr wenig aus. Übrigens sind 8 Platten im Z3 keine Idealkonfiguration, denk mal über 7 oder 11 nach. Solarisinternals spricht auch von 9, das kann ich mir aber nicht per Rechnung erklären.
Ist Quatsch, die Regel gilt nur wenn du Deduplikation verwenden möchtest, da die Dedup-Tabelle, optimalerweise, in den RAM passen sollte.
Die Größe der DDT errechnet sich aus die Anzahl der einzigartigen Blöcke * 320 Byte. Als grobe Richtung sagt man deshalb 1GB RAM, pro 1TB eindeutige Daten (je nach Blockgröße)
How To Size Main Memory for ZFS Deduplication
So richtig wohl fühlt sich ZFS ab 4GB RAM, es funktioniert aber auch mit weniger.
Ein RAIDZ3 sollte aus 5, 7 oder 11 Platten bestehen. (2, 4, 8 + 3)
