[Sammelthread] ZFS Stammtisch

Wie kann ich es manuell konfigurieren? Hab schon gesucht, aber nix gefunden...

in napp-it:
Im Menü Network Eth auf DHCP klickem und auf static umsschalten

Auf der Console, Anleitung siehe

oder

oder Oracle Solaris 11.2 System Handbuch
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Danke gea.

Ich habe noch eine Frage zum Verständnis.

Die Routing-Tabelle sieht nun genauso so aus:

Bildschirmfoto 2020-02-20 um 21.06.32.png

Ich bin nicht der Netzwerk-Überflieger, aber die default Route 0.0.0.0 über in meinem Fall den GW 172.22.70.250 sollte doch alles, was nicht über andere Routings geregelt ist, darüber senden. Auch die Antworten von der 172.22.1.115 an die 172.22.10.usw, von der ich aufrufe.

Oder sind die Layer-2 Switche da schon am Ende?

EDIT: Müsste wahrscheinlich noch nen dritten NIC etablieren mit dem VLAN10, wenn ich denn vom Client Zugriff haben möchte. Denn dann würde er die Rückroute kennen. So, wie es sich verhält, ist die default Route auch nur /24. :(

Aber dann dürfte OmniOS dennoch nicht drei! default Gateways setzen. :d
 
Zuletzt bearbeitet:
Es gibt nur eine default route hier.
Die Default route erhält alle Packete die nicht anderweitig bekannt sind wie die Subnets die den vnics zugeordnet sind. Den Rückweg vom default Gateway muss allerdings dieses kennen, sonst routed das ja auf sein default Gateway.

ps
Wenn man eine Netzmaske /16 haben möchte, muss man bei netmask bei den vnics 255.255.0.0 angeben.
 
Zwei Default Gateways braucht man nur wenn man 2 Internet Anbindungen

Unter Linux kann man eine Defaultroute je Netzwerkinterface definieren (iproute2). Dies sorgt dafür, dass z.B. der Traffic, der aus einem anderen VLAN über ein Interface zu einem Server kommt auch über dasselbe Interface beantwortet wird.

Ich mache das bei meinem TVHeadend Server (2 Interfaces, eins im Server-VLAN 80 und eins im Media-VLAN 30). Nun habe ich neben den Media Clients im VLAN 30 auch einen PC im VLAN 50, der auf die IP des TVHeadends im VLAN30 zugreift. Würde nun die Defaultroute auf das Gateway im VLAN80 routen, dann würde die Verbindung nicht funktionieren, da die Antwort von einer anderen IP käme.
Daher hat jedes Interface eine eigene Routing Tabelle mit eigenem Default Gateway. Wie das funktioniert ist HIER ganz gut beschrieben.
 
Mal ne kurze Frage in den Raum geworfen...

Als (ProxMox) VM-Datastore, bei 4 SSD(nicht Enterprise) besser zwei Mirror-Pairs oder eine RaidZ2?

Gruß
 
Ich habe die Infos zur Installation und Setup von minIO (S3 kompatibler Cloud Backup-Server für Duplicati, rclone oder Veeam ) unter OmniOS ergänzt. Ist wirklich easy.

 
Wie ist eigentlich der aktuellste Stand im Feature-Vergleich - gucke ich bei https://napp-it.org/compare.html heißt es bei OmniOS immer noch, dass es ZFS-Verschlüsselung nur bei Solaris selber gäbe.

Dachte das sei bei OpenZFS vor einer Weile eingeführt worden - oder mische ich da was in der Erinnerung falsch zusammen?
 
Das aktuelle OmniOS 151032 stable hat seit letztem Herbst neueste Open-ZFS Features wie ZFS Verschlüssellung, spezielle vdev, trim, force ashift etc.

Ich habe noch nicht alle napp-it Manuals aktualisiert. Unterstützung für Verschlüssellung ist ab napp-it 19.12 enthalten. 20.01 Pro kommt dann mit einem Keyserver um Keys zentral (optional gesplittet) zu speichern.

 
Da OmniOS ja gut weiterentwickelt wird, gibt es Vergleichsleistungswerte zu SMB Multichannel zwischen OmniOS und Solaris?

Würde alles zwar nur privat mit meinen Napp-it Pro-Lizenzen nutzen, aber selbst als fachfremden Laien stößt mir Oracles Verhalten auf, so dass ich eigentlich nichts von denen verwenden möchte.

Leider bin ich auch ein Geschwindigkeitsfetischist und erfreue mich an 40 GbE-Karten (derzeit nur Direktverbindungen). Meine Dual-QSFP+-Karten können auf (1 x 40 GbE QSFP+/4 x 10 GbE SFP+) konfiguriert werden.

Wenn SMB Multichannel ordentlich funktionieren sollte (Windows-Klienten), könnte ich mir mit diesem Switch ein deutlich flexibleres Netzwerk aufbauen, ohne auf extrem hochpreisige Switche ausweichen zu müssen.

 
Zuletzt bearbeitet:
Ich habe vor einigen Tagen omnios-r151030 frisch installiert. Aus irgendeinem Grund schaffe ich es jetzt nicht, SSH über napp-it (Version 18.12w4) zu aktivieren. Ich versuche wie bisher auch Services >> SSH >> allow root und erhalte nur "ssh status: disabled".

Was könnte hier der Fehler sein?

Edit: Hat sich erledigt, man muss zuerst auf die Menüebene darüber klicken, um den Service zu starten. War vermutlich schon immer so, ich habs einfach nicht mehr gewusst. :-)
 
Zuletzt bearbeitet:
Das aktuelle OmniOS 151032 stable hat seit letztem Herbst neueste Open-ZFS Features wie ZFS Verschlüssellung, spezielle vdev, trim, force ashift etc.

Ich habe noch nicht alle napp-it Manuals aktualisiert. Unterstützung für Verschlüssellung ist ab napp-it 19.12 enthalten. 20.01 Pro kommt dann mit einem Keyserver um Keys zentral (optional gesplittet) zu speichern.

Gibts den Keyserver Support dann auch für Solaris ?
 
Der Keyserver in der Preversion von 20.01 unterstützt OI, OmniOS und Oracle Solaris, genauso wie die Clientfunktionalität bei der man beim Anlegen eines verschlüsselten Dateisystems den Key direkt auf den oder die (Keysplit) Keyserver legen kann. Unter anderen Systemen (Free-BSD, ZoL) wäre der Keyserver via Script nutzbar (anlegen, lock, unlock). Die nötigen Scripte werde ich da noch dokumentieren.
 
Selbst wenn es irgendwann geht würde ich das aber erstmal nicht produktiv nutzen. Bei Samba gab (gibt?) es da auch Probleme welche zu korrupten Daten führen konnten.
 
@gea

Hast Du zufällig aktuelle Erfahrungen was den Stand von SMB Multichannel bei OmniOS angeht?

Solaris hat das, Illumos derzeit nicht (jeweils kernelbasierter SMB Server). Ich habe auch keine Ankündigung gesehen. Ich würde aber auch eher einen Windows Server eventuell mit ZFS Storage via iSCSI einsetzen wenn das Pflicht ist.
 
Ich würde aber auch eher einen Windows Server eventuell mit ZFS Storage via iSCSI einsetzen wenn das Pflicht ist.

Könnte man mit dieser Lösung ZFS-Snapshots als "Schattenkopien" umbiegen, so dass Windows-Klienten die Snapshots trotz Windows Server dazwischen sauber nutzen können?

Oder ist dies nicht möglich/Unsinn?

Nur als Inspiration, zu Unraid wollte ich nicht wechseln, nur falls möglich, Oracle Solaris vermeiden:

 
Nein.
ZFS als Shadow Copies geht unter Solarish absolut problemfrei bei SMB Shares. Bei iSCSI kann man nur das ganze Lun snapshotten und per rollback wiederherstellen (oder Clone aus Snap erstellen). Windows kann auf dem Lun zwar Shadow Copies anlegen, die sind aber nicht sicher (Ransomware kann die löschen)
 
Hi

Habe da ein nappit aio ESXi mit einer SSD für VMs und einer "Backup Platte" per durchgereichtem PERC H310. vSphere, nappit und alle anderen Management Sachen habe ich netzwerktechnisch aufwändig in ein separates vLAN verfrachtet letzthin.

Nun hätte ich gerne noch bisschen NAS Dienste für Backup. Weil wenn mir im Moment irgendeine Platte hopps gehen würde, wär das Geschrei gross dann. Ich würde also gerne 2x 8TB WD RED dazu stecken, um da mal alles bisschen zu sichern. Das wär per Samba im normalen LAN gedacht, und halt somit nicht im Management Netz wo das nappit hängt.

Kann ich das irgendwie auf dem durchgereichten H310 erreichen, oder muss ich da einen separaten Filer mit eigenem HBA aufsetzen? Nen H200 hätte ich noch rum liegen, wär mir aber lieber, wenn beide Filer an einem Controller hängen.
 
Den Controller kannst Du nur an eine VM durchreichen. Zusätzliche Filer-VM bedeutet zusätzlichen HBA. RDM mal außen vor.

Die Frage ist: Wieso willst Du das überhaupt tun? Gegen physikalischen Totalausfall (Raub, Brand, Wasser, Überspannung) hilft die zweite VM auch nicht. Gegen alles andere (Ransomware, Diskfailure, versehentliches Löschen etc.) würde es deutlich mehr bringen, die beiden Zusatzplatten ebenfalls für die Verwendung in nappit zu konfigurieren.
Noch besser wäre natürlich ein externes Backup auf mindestens zwei wechselnden Datenträgern.
 
Schön wärs, ich hätte das Kleingeld für noch zusätzlich paar USB Platten. Hier siehts aber so aus, dass ich schon mal froh bin, wenn ich all den Stuff mal bisschen weg sichern kann irgendwie. Also nicht nur die Daten vom ESXi, sondern allgemein Daten. Diese sollen halt im LAN verfügbar sein, und nicht an dem Management vLAN. Na klar, ich könnte nappit eine zweite NIC zuweisen, aber ich habe das wie gesagt extra aufwändig getrennt per vLAN.
 
So ganz verstehe ich das Problem nicht. Ein File-Server hat doch per-se erstmal wenig mit dem Management VLAN zu tun. Das sind für mich SSH und solche Dinge.
Wenn Du die VMs per NFS bereitstellst, könntest Du auf dem ESXer noch ein separates Storage VLAN anlegen (so stelle ich z.B. meine VMs an ESXi und Proxmox bereit), das nicht im Client-Netzwerk verfügbar ist. Backups haben eigentlich eh nichts auf Freigaben verloren (außer es ist Veam o.ä., dann halt auch den Client ins Storage VLAN).
SMB Freigaben für die klassische NAS Funktionalität dann über das Client-VLAN.
 
Ja eben, das NFS Storage mit den VMs ist per durchgereichtem PERC in einem separatem vLAN, mit vSphere Kernel, IPMI, Firewall und so. NFS war der Grund, wieso ich das angelegt habe. Damit NFS eben nicht im LAN ist. Weil NFS 3.0 ist ja dann ohne Passwort im Netzwerk erreichbar, das wollte ich irgendwie nicht. Wie machst Du das denn mit nappit und NFS?
 
Wenn Du ein getrenntes VLAN hast, dann hast Du zwischen VLANs doch sicher eine Firewall. Das wäre der richtige Ort, um NFS Zugriff auf nappit zu unterbinden, wenn das aus dem Client Netzwerk nicht sein soll.
Außerdem kannst Du auch in NFS3 auf IP Adresse berechtigen. Die theoretische Möglichkeit des IP Spoofings aus einem anderen Netz fängst Du wieder an der Firewall ab.
 
Die OmniOS Firewall wäre eine Option, den Zugriff zu steuern. Für allerhöchste Sicherheitsanforedrungen wäre tatsächlich eine eigene Storage VM für NFS/ VMs die beste Option. Dabei eine Nic ins Management Netz von ESXi. Der allgemeine Filer hat dann neben LAN eine zweite nic ins Management Netz damit man da Backups machen kann.

Mit einem SAS HBA Controller kann man auch einzelne Platten (SAS aber auch Sata) direkt an VMs durchreichen (in ESXi: Disks > Add raw Disks). Bringt keine wesentlichen Einschränkungen mit sich.
 
Mit einem SAS HBA Controller kann man auch einzelne Platten (SAS aber auch Sata) direkt an VMs durchreichen (in ESXi: Disks > Add raw Disks). Bringt keine wesentlichen Einschränkungen mit sich.

Geht das nur mit HBA ?
 
Habe ich nicht getestet.
Mit dem Sata Controller geht es jedoch nicht direkt. Da ist Fummeln angesagt. Nur mit SAS Platten wird zudem der Hersteller und Typ angezeigt. Mit einem SAS Raid Controller könnte direktes RDM/Raw Disk Mapping auch funktionieren. Mit ZFS wäre das aber kontraproduktiv. Man würde die Selbstheilungsfunktion im ZFS Raid verlieren..
 
Solaris hat das, Illumos derzeit nicht (jeweils kernelbasierter SMB Server). Ich habe auch keine Ankündigung gesehen. Ich würde aber auch eher einen Windows Server eventuell mit ZFS Storage via iSCSI einsetzen wenn das Pflicht ist.

Gibt es eigentlich eine nachvollziehbare Begründung, weshalb nur "original" Oracle/Solaris (und natürlich MS selber) sonst niemand auch nach gut acht Jahren "stabil" SMB Multichannel anbietet?

Habe es zum ersten Mal mit 1 GbE-Komponenten getestet und fand's super, hätte gedacht, dass es mehr Unterstützung für etwas gäbe, was "einfach so" die Geschwindigkeit auch bei einem einzelnem Dateitransfer mit vorhandener Hardware vervielfacht (viele Mainboards haben ja mehrere NICs onboard).
 
Ich halte SMB Multichannel für einen Exoten, den kaum jemand wirklich braucht. Ich sehe das im Enterprise Umfeld nirgends im Einsatz, obwohl es relativ leicht ginge.
Wenn mehr Bandbreite gewünscht wird, gibts jede Menge andere Möglichkeiten, die unabhänging von Betriebsystem und Protokoll sind. Viel wichtiger ist der Support von 10, 40 und 100G sowie Zwischenschritte über alle möglichen Medien.
Ob dann SMB, iSCSI oder NFS zum Einsatz kommt, spielt keine Rolle.

cu
 
Nunja SMB Multichannel ermöglicht es aber auch von Wifi auf Ethernet zu wechseln während der Verbindung. Dies geht bislang nicht heißt du startest einen Transfer per Wifi, steckst Kabel ein dann wird er weiterhin über Wifi weitergeführt.
Das finde ich schon praktisch.
 
...und funzt in der Regel dann doch gerne nicht so richtig. Im Gegenteil: WLAN und Kabel gleichzeitig stört bisweilen sogar. Darum deaktivieren wir in der Firma z.B. die WLAN-Adapter standardmäßig/automatisch, wenn Laptops in der per LAN angebundenen Dockingstation stecken.
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh