ryzion
Urgestein
- Mitglied seit
- 05.03.2005
- Beiträge
- 4.895
Hallo auch von mir. Ich versuche gerade einen smb container aufzusetzen. Angebunden ist er zunächst via 10gbe. Mittels async io und jumbo frames komme ich auf 1GB/s write. Auf Containerseite ist der smb storage auf ein zfs subvol gelegt. Der ARC hat 64GB RAM. Jedoch kann ich nur ca 5GB mit voller Geschwindigkeit schreiben, dann habe ich nur noch die 200 MB/s, die mir mein zpool tatsächlich liefert. Ich würde aber gerne mehr RAM als write cache benutzen. Hat jemand eine Idee?
martingo
Experte
- Mitglied seit
- 17.01.2017
- Beiträge
- 1.300
Und welches Betriebssystem hat der Container? Wurde der ZFS Pool vom Container (LXC?) erzeugt oder durch Proxmox und Du reichst ein Volume per Mountpoint an den LXC durch? Bzw. kann LXC ohnehin kein ZFS meines Wissens. Insofern bleibt nur, dass Du ZFS auf dem Proxmox nutzt und das Volume durchreichst.
Standardmäßig nutzt Proxmox meines Wissens maximal 8GB als ZFS Cache, das lässt sich aber anpassen.
Edit: Falsch, angeblich ist es die Hälfte des RAMs die standardmäßig maximal genutzt wird (falls die VMs und Container nichts brauchen). Das wären bei Dir 32GB, das passt nicht recht zu den genannten 5GB. RAM war aber noch frei? Hier steht, wie sich das anpassen lässt: ZFS on Linux - Proxmox VE
Standardmäßig nutzt Proxmox meines Wissens maximal 8GB als ZFS Cache, das lässt sich aber anpassen.
Edit: Falsch, angeblich ist es die Hälfte des RAMs die standardmäßig maximal genutzt wird (falls die VMs und Container nichts brauchen). Das wären bei Dir 32GB, das passt nicht recht zu den genannten 5GB. RAM war aber noch frei? Hier steht, wie sich das anpassen lässt: ZFS on Linux - Proxmox VE
Zuletzt bearbeitet:
ryzion
Urgestein
- Mitglied seit
- 05.03.2005
- Beiträge
- 4.895
Der Container wird als mountpoint durchgereicht. Er benutzt ca 5gb vom ram als write cache (~120GB frei, 64GB ARC). Ich find absolut nichts dazu wie der write cache verwendet wird, oder konfiguriert wird. Im proxmox forum meinte einer vom Staff dass es am ARC hängen würde, ein andere meint das Gegenteil.
In Open-ZFS wird 10% des zur Verfügung stehenden RAM's per default als Schreibcache genutzt. Der Großteil des restlichen RAM wird als Arc Lesecache genutzt. Der RAM-Schreibcache dient vor allem dazu, viele kleine random write zu sammeln und als ein großes schneller sequentielles Write zu schreiben. Bei kleinen Schreibblöcken würde ansonst die Performance massiv einbrechen (wie es ja auch bei sync qwrite passiert, da wird jeder kleine Schreib-Commit direkt auf Platte (ZIL or Slog) geschrieben.
Prinzipiell ist die Schreibcache Größe einstellbar. Macht man den aber größer, so hat man weniger RAM für Lesecache, außerdem gehen ja alle writes zunächst in den Schreibcache, werden dort gesammelt und im Hintergrund geschrieben. Eine Vergrößerung des Cache erlaubt allenfalls einen größeren Schreibburst zu Beginn. Nach kurzer Zeit hat man dennoch nur die sequentielle Pool-Performance. Der default-10% RAM Wert ist ein dabei sehr guter Kompromiss. Ich würde den nicht ohne starke Gründe ändern.
Das ist auch unabhängig von der Frage wie man den Pool nutzt oder darauf zugreift.
Tuning the OpenZFS write throttle | Delphix
Bei einem Virtualisierungsserver kommt dazu, dass man den RAM für das OS (hier Debian), ZFS und alle VMs teilen muss. Insbesondere ZFS muss man da zügeln, damit es nicht alles nimmt. ZFS gibt den RAM zwar dynamisch frei wenn andere RAM wollen, bei High Perfornance Anwendungen kann das aber bremsen. Besser man macht nicht alles dynamisch.
Prinzipiell ist die Schreibcache Größe einstellbar. Macht man den aber größer, so hat man weniger RAM für Lesecache, außerdem gehen ja alle writes zunächst in den Schreibcache, werden dort gesammelt und im Hintergrund geschrieben. Eine Vergrößerung des Cache erlaubt allenfalls einen größeren Schreibburst zu Beginn. Nach kurzer Zeit hat man dennoch nur die sequentielle Pool-Performance. Der default-10% RAM Wert ist ein dabei sehr guter Kompromiss. Ich würde den nicht ohne starke Gründe ändern.
Das ist auch unabhängig von der Frage wie man den Pool nutzt oder darauf zugreift.
Tuning the OpenZFS write throttle | Delphix
Bei einem Virtualisierungsserver kommt dazu, dass man den RAM für das OS (hier Debian), ZFS und alle VMs teilen muss. Insbesondere ZFS muss man da zügeln, damit es nicht alles nimmt. ZFS gibt den RAM zwar dynamisch frei wenn andere RAM wollen, bei High Perfornance Anwendungen kann das aber bremsen. Besser man macht nicht alles dynamisch.
Kurze Frage zur Replikation. Ich habe einen bestehenden Pool (nennen wir ihn pool1) mit diversen ZFS Dateisystemen. Auf dem Pool sind automatische Snapshot vorhanden (stündliche/tägliche/monatliche Snapshots). Die Snapshots gehen mehrere Monate zurück.
Desweiteren habe ich einen neuen, leeren Pool (lokal, nennen wir ihn pool2). Dorthin möchte ich sämtliche Daten von pool1 nach pool2 migrieren, inkl. sämtlicher Snapshots. Der pool2 soll pool1 vollstndig ersetzeb. Was ist der richtige Weg? Ich werde aus den Beschreibungen von zfs send -I / zfs send -R nicht recht schlau...
Desweiteren habe ich einen neuen, leeren Pool (lokal, nennen wir ihn pool2). Dorthin möchte ich sämtliche Daten von pool1 nach pool2 migrieren, inkl. sämtlicher Snapshots. Der pool2 soll pool1 vollstndig ersetzeb. Was ist der richtige Weg? Ich werde aus den Beschreibungen von zfs send -I / zfs send -R nicht recht schlau...
Moinsen!
Nach dem resilvern bleibt mein Pool degraded - wie bekomm ich das wieder weg?
Ich habe ein RAIDZ, bestehend aus 4x3TB Platten. Eine dieser Platten hat sich mit current pending sectors und dann offline uncorrectable sectors gemeldet. Also Platte identifiziert, defekte Platte im ausgeschalteten Zustand raus, neue Platte rein.
Ich nutze NAS4FREE, und habe dann über die GUI ein resilvering angestoßen. Der Pfad war Disks-ZFS-Tools, dann replace - habe die alte durch die neue ersetzt, und das resilvering ist gestartet und auch beendet worden.
Folgendermaßen sieht mein Log aus:
Um die Dateien ist es mir egal - ich will den Pool wieder sauber online bekommen, denn die drei verbliebenen "alten" Platten sollen auch zeitnah ersetzt werden.
Nach dem resilvern bleibt mein Pool degraded - wie bekomm ich das wieder weg?
Ich habe ein RAIDZ, bestehend aus 4x3TB Platten. Eine dieser Platten hat sich mit current pending sectors und dann offline uncorrectable sectors gemeldet. Also Platte identifiziert, defekte Platte im ausgeschalteten Zustand raus, neue Platte rein.
Ich nutze NAS4FREE, und habe dann über die GUI ein resilvering angestoßen. Der Pfad war Disks-ZFS-Tools, dann replace - habe die alte durch die neue ersetzt, und das resilvering ist gestartet und auch beendet worden.
Folgendermaßen sieht mein Log aus:
Code:
pool: Datenpool
state: DEGRADED
status: One or more devices has experienced an error resulting in data
corruption. Applications may be affected.
action: Restore the file in question if possible. Otherwise restore the
entire pool from backup.
see: http://illumos.org/msg/ZFS-8000-8A
scan: resilvered 1.42T in 7h11m with 6 errors on Sat May 18 15:25:51 2019
config:
NAME STATE READ WRITE CKSUM
Datenpool DEGRADED 0 0 6
raidz1-0 DEGRADED 0 0 12
ada0.nop ONLINE 3 0 0
ada1.nop ONLINE 2 0 0
ada2.nop ONLINE 0 0 0
replacing-3 DEGRADED 0 0 0
2555947039075341036 UNAVAIL 0 0 0 was /dev/ada3.nop/old
ada3.nop ONLINE 0 0 0
errors: Permanent errors have been detected in the following files:
/mnt/Datenpool/file1
/mnt/Datenpool/file2
/mnt/Datenpool/file3
/mnt/Datenpool/file4Um die Dateien ist es mir egal - ich will den Pool wieder sauber online bekommen, denn die drei verbliebenen "alten" Platten sollen auch zeitnah ersetzt werden.
zfs send -I erwartet zwei snapshots als Parameter.
Die Replikation überträgt dann das Dateisystem mit allen snaps zwischen den beiden.
zfs send -R erwartet einen snapshot als Parameter und überträgt alle darunterliegenden Dateisysteme und Snaps mit.
Sending and Receiving Complex ZFS Snapshot Streams (Solaris ZFS Administration Guide)
- - - Updated - - -
ich würde es mit einem zpool detach 2555947039075341036 Datenpool versuchen
Philipp Beatdown
Experte
Guten morgen,
Ich habe mir jetzt einen HP DL60 Gen9 Gekauft
E5-2603v3
64GB DDR4 ECC
B140i Raid ABER im ahci Modus wegen SMART & CO
Darauf habe ich Server 2016 Installiert und mir freenas Virtualisiert. (4Cores und 48gb ram) die Festplatten sind durchgereicht worden.
ich habe mir aus 3x2tb WD RED ein RaidZ angelegt.
jetzt finde ich , das mein SMB share ziemlich langsam ist (Lesen ca 95MB/S schreiben ca 75MB/s (im windows explorer) da ist ja mein urlalter adaptec noch schneller.
ich bin leider absouluter neuling habt ihr evtl nen tipp ?
Ich habe mir jetzt einen HP DL60 Gen9 Gekauft
E5-2603v3
64GB DDR4 ECC
B140i Raid ABER im ahci Modus wegen SMART & CO
Darauf habe ich Server 2016 Installiert und mir freenas Virtualisiert. (4Cores und 48gb ram) die Festplatten sind durchgereicht worden.
ich habe mir aus 3x2tb WD RED ein RaidZ angelegt.
jetzt finde ich , das mein SMB share ziemlich langsam ist (Lesen ca 95MB/S schreiben ca 75MB/s (im windows explorer) da ist ja mein urlalter adaptec noch schneller.
ich bin leider absouluter neuling habt ihr evtl nen tipp ?
Ich würde nicht davon ausgehen, dass Virtualisieren von Unix (Free-BSD oder Solarish) unter Windows besonders schnell ist. Auch ist ZFS kein maximal schnelles sondern maximal sicheres Dateisystem. Hinzu kommt dass FreeNAS als die speicherhungrigste Option gilt. Auch gilt SAMBA als meist langsamer als ein Windows oder Solarish SMB Server.
Die Datenraten sind ansonst nicht top aber auch nicht gerade wirklich schlecht.
Schneller wäre vermutlich ESXi als Basis und eine kompaktere NAS Distrubution wie XigmaNAS wenn es auf Free-BSD aufbauen soll. Windows wäre dann auch eine weitere VM. Noch schneller mit ZFS ist meist Oracle Solaris mit original ZFS oder ein ein freier Solaris Fork wie OmniOS. Da gibt es zudem den kernelbasierten (in OS und ZFS integriert) multithreaded SMB Server. Der bringt meist auch noch etwas.
Ideal wäre da auch nicht das Durchreichen von einzelnen Platten über den Virtualisierer sondern das komplette Durchreichen des Kontrollers damit die Storage VM mit eigenen Treibern zugreifen kann.
Die Datenraten sind ansonst nicht top aber auch nicht gerade wirklich schlecht.
Schneller wäre vermutlich ESXi als Basis und eine kompaktere NAS Distrubution wie XigmaNAS wenn es auf Free-BSD aufbauen soll. Windows wäre dann auch eine weitere VM. Noch schneller mit ZFS ist meist Oracle Solaris mit original ZFS oder ein ein freier Solaris Fork wie OmniOS. Da gibt es zudem den kernelbasierten (in OS und ZFS integriert) multithreaded SMB Server. Der bringt meist auch noch etwas.
Ideal wäre da auch nicht das Durchreichen von einzelnen Platten über den Virtualisierer sondern das komplette Durchreichen des Kontrollers damit die Storage VM mit eigenen Treibern zugreifen kann.
Philipp Beatdown
Experte
Im endeffekt wenn ich das so lies , wäre ich mit einem hardwarecontroller dann doch wieder am besten , damit ich meine 125MB/s via lan erreiche ?
Das Thema ist nicht Hard- vs Softwareraid (Softwareraid ist heutzutage immer schneller) sondern die neuen Dateisysteme wie ZFS (oder ReFS) vs FAT32/ntfs/ext4
Bei einem konventionellen Raid/Dateisystem kann ein Absturz beim Schreiben zu einem defekten Dateisystem oder Raid führen, nennt sich Write hole Problem, "Write hole" phenomenon in RAID5, RAID6, RAID1, and other arrays.
Hinzu kommt dass ein konventionelles Dateisystem keine Prüfmöglichkeit hat um festzustellen ob Daten verändert wurden (Silent Data Error/ Datenrost, Fehler durch Treiber, Kabel, Controller etc).
ZFS löst beide Probleme durch CopyOnWrite (immer konsistentes Dateisystem und Raid) und Prüfsummen auf Daten und Metadaten. Diese Sicherheit kostet aber Performance. Ausgeglichen wird das durch die herausragenden Cache Optionen von ZFS. Damit sind auch Datenraten via iSCSI, NFS und SMB jenseits von 10G möglich.
Eine Festplatte erreicht >100 MB/s ohnehin nur bei sequentiellem io, meist nur bei leeren Platten auf den äußeren Spuren. Kommen kleine Datenblöcke oder Multiuser Access bricht eine Platte gerne mal auf 30 MB/s ein. Ohne massives Caching kann man das nicht verhindern und genau da punktet ZFS mit seine rambasierten Schreib-Lesecaches. Cache Hit Raten beim Lesen > 80% sind möglich und werden aus dem RAM bedient.
Bei Virtualisierung kommt hinzu, dass ein Absturz beim Schreiben ein Gast Dateisystem beschädigen kann. Hardwareraid mit BBU kann das Problem verringern, ZFS mit Slog kann das beseitigen (Schutz des Schreibcaches vor Datenverlust).
Bei einem konventionellen Raid/Dateisystem kann ein Absturz beim Schreiben zu einem defekten Dateisystem oder Raid führen, nennt sich Write hole Problem, "Write hole" phenomenon in RAID5, RAID6, RAID1, and other arrays.
Hinzu kommt dass ein konventionelles Dateisystem keine Prüfmöglichkeit hat um festzustellen ob Daten verändert wurden (Silent Data Error/ Datenrost, Fehler durch Treiber, Kabel, Controller etc).
ZFS löst beide Probleme durch CopyOnWrite (immer konsistentes Dateisystem und Raid) und Prüfsummen auf Daten und Metadaten. Diese Sicherheit kostet aber Performance. Ausgeglichen wird das durch die herausragenden Cache Optionen von ZFS. Damit sind auch Datenraten via iSCSI, NFS und SMB jenseits von 10G möglich.
Eine Festplatte erreicht >100 MB/s ohnehin nur bei sequentiellem io, meist nur bei leeren Platten auf den äußeren Spuren. Kommen kleine Datenblöcke oder Multiuser Access bricht eine Platte gerne mal auf 30 MB/s ein. Ohne massives Caching kann man das nicht verhindern und genau da punktet ZFS mit seine rambasierten Schreib-Lesecaches. Cache Hit Raten beim Lesen > 80% sind möglich und werden aus dem RAM bedient.
Bei Virtualisierung kommt hinzu, dass ein Absturz beim Schreiben ein Gast Dateisystem beschädigen kann. Hardwareraid mit BBU kann das Problem verringern, ZFS mit Slog kann das beseitigen (Schutz des Schreibcaches vor Datenverlust).
Zuletzt bearbeitet:
Gen8 Runner
Experte
- Mitglied seit
- 12.08.2015
- Beiträge
- 1.148
Ich habe FreeNAS aus einem ESXI 6.7 virtualisiert und die Festplatten mit vt-d von meinem M1015 Controller (IT-Mode) durchgereicht. Also FreeNAS wird eine Standalone-Installation vorgetäuscht. Nur zwei Kerne zugewiesen, 16GB Arbeitsspeicher derzeit, eine standard Intel QuadPort-Netzwerkkarte und komme bei großen Dateien auf die vollen 110-125MB/s.
Ist bei mir also eine stinknormale Kombination ohne große Extras (USB LAN Adapter an meinem Lenovo X380 Laptop, günstiger Zyxel Switch, Standard LAN Kabel und Basis Konfiguration aller Systeme). Ist also kein Hexenwerk. Entweder nochmal deine Einstellungen ein wenig abändern oder eventuell überlegen auf ESXI umzusteigen, wenn dir Geschwindigkeit sehr wichtig ist.
Philipp Beatdown
Experte
HI,
magst du mir deine genauere vorgehensweise beschreiben?
ich meine damit sie sachen mit dem datenspeicher.
mein esxi ist jetzt auf der sd karte installiert, muss allerdings nun ne extra hdd für die freenas installation einbauen, da ich die anderen 3x2 tb ja als datenspeicher brauche...
magst du mir deine genauere vorgehensweise beschreiben?
ich meine damit sie sachen mit dem datenspeicher.
mein esxi ist jetzt auf der sd karte installiert, muss allerdings nun ne extra hdd für die freenas installation einbauen, da ich die anderen 3x2 tb ja als datenspeicher brauche...
Gen8 Runner
Experte
- Mitglied seit
- 12.08.2015
- Beiträge
- 1.148
In Kurzform:
1. ESXI auf Speicherkarte / USB Stick installieren
2. Festplattencontroller durchreichen (Host -> Verwalten -> Hardware -> Controller auswählen -> Passthrough aktivieren -> Host muss neu gestartet werden
3. SSD / Festplatte / USB Stick (sollte für den Anfang und zum Testen auch gehen) initialisieren (hierfür USB Stick anstecken -> Speicher -> Neuer Datenspeicher -> USB Stick auswählen und formatieren lassen )
3. VM mit FreeNAS installieren (VM erstellen, Hardware auswählen, Festplattencontroller / PCI Gerät auch FreeNAS zuweisen, welches du in Schritt zwei durchgereicht hast)
4. Installieren
5. FreeNAS einrichten und deinen Pool importieren / neu erstellen (falls eh noch keine Daten drauf sind)
So die grobe Form. Ich schätze, dass du VM's auch auf einem USB Stick installieren kannst - sollte dir ESXI dann zusagen, würde ich natürlich nochmal eine SSD / Festplatte besorgen, auf der du all deine VM's ablegst (da eine SSD / HDD natürlich i.d.R. robuster und schneller ist als ein Stick).
Edit:
ESXI scheint nicht zuzulassen, dass VM's aus einem USB Stick installiert werden. Also hoffentlich noch eine alte Fesplatte / SSD herumliegen haben (die entscheidet NICHT über Geschwindigkeit des Kopierens von Daten in FreeNAS, sondern ist nur Kriegsentscheidend, wie schnell FreeNAS hochgefahren wird).
Zuletzt bearbeitet:
Philipp Beatdown
Experte
Hallo,
vielen lieben dank für deinen post !
ich habe das eben mal durchgespielt, und musste zum einen feststellen , das mein Controller (b140i) im AHCI mode nicht durchgereicht werden kann . :/
und zum zweiten , das man keine VM auf einem stick ( wie du bereits gesagt hast ) installieren kann .
ich glaube ich muss das projekt "freenas" aufgeben, da ich mit meinen beiden server das nicht so hinbekomme wie ich will.. :/
-dl380 ist wegen dem P420i so laut
-und der dl60 gen 9 läuft mit dem freenas (standalone / esxi / windows vm) einfach nur sch...e .... probier schon den ganzen tag rum :/
vielen lieben dank für deinen post !
ich habe das eben mal durchgespielt, und musste zum einen feststellen , das mein Controller (b140i) im AHCI mode nicht durchgereicht werden kann . :/
und zum zweiten , das man keine VM auf einem stick ( wie du bereits gesagt hast ) installieren kann .
ich glaube ich muss das projekt "freenas" aufgeben, da ich mit meinen beiden server das nicht so hinbekomme wie ich will.. :/
-dl380 ist wegen dem P420i so laut
-und der dl60 gen 9 läuft mit dem freenas (standalone / esxi / windows vm) einfach nur sch...e .... probier schon den ganzen tag rum :/
Zuletzt bearbeitet:
Gen8 Runner
Experte
- Mitglied seit
- 12.08.2015
- Beiträge
- 1.148
Kein Problem.
Das ist in der Tat blöd, vt-d ist aber aktiviert im BIOS? Das muss sein zum Durchreichen.
Ich stehe vollkommen hinter FreeNAS, wenn das erstmal läuft, ist es einfach nur super stabil und bei mir auch sehr flott (und nutzt Gbit komplett aus). Und die Features werden auch mehr und mehr ausgebaut.
Aber eventuell gibt es ja noch andere Betriebssysteme, die bei dir in Frage kommen oder Festplatten können direkt durchgereicht werden, da bin ich aber in ESXI zu wenig drin, um da konkret etwas zu sagen zu können.
Durchreichen von einem M1015 ist mit das einfachste Szenario im Fall der Virtualisierung.
Das ist in der Tat blöd, vt-d ist aber aktiviert im BIOS? Das muss sein zum Durchreichen.
Ich stehe vollkommen hinter FreeNAS, wenn das erstmal läuft, ist es einfach nur super stabil und bei mir auch sehr flott (und nutzt Gbit komplett aus). Und die Features werden auch mehr und mehr ausgebaut.
Aber eventuell gibt es ja noch andere Betriebssysteme, die bei dir in Frage kommen oder Festplatten können direkt durchgereicht werden, da bin ich aber in ESXI zu wenig drin, um da konkret etwas zu sagen zu können.
Durchreichen von einem M1015 ist mit das einfachste Szenario im Fall der Virtualisierung.
Das hat leider nichts gebracht :/
Ich hab auch versucht, die neue Disk mal auf online zu setzen, mit der Folge, dass wieder resilvered wurde. Auch ein reboot hat zum erneuten resilvern geführt.
Hätte ich evtl die kaputte Platte erst manuell offline setzen sollen, bevor ich die neue an deren Stelle eingesetzt habe? Oder ist das egal?
Wenn ich die neue Platte jetzt offline nehme, und dann wieder online - bleiben die Daten im Pool doch trotzdem erhalten, oder? Alternativ würde ich ja auch einfach das Ergebnis des resilverns akzeptieren, und den Pool wieder auf online gesetzt bekommen...
125 MB/s sind halt auch das Maximum im Idealfall. Realistisch solltest Du vermutlich eher 110 MB/s anpeilen. Es kommt auch stark auf die Gegenstelle an - mein Thinkpad T470 liest zB langsamer (eher ca. 100 MB/s) als er schreibt (110 MB/s) vom RAIDZ1-SSD-Pool, mein Thinkstation E32 liest und schreibt mit 110-115 MB/s. Jumbo-Frames überall aktiviert.
Hat sich geklärt - hab die vier Files erst manuell gelöscht, in der Hoffnung, das Problem so zu beheben - hat aber nix gebracht. Letztendlich hat es ein schnöder scrub gelöst
Luckysh0t
Enthusiast
martingo
Experte
- Mitglied seit
- 17.01.2017
- Beiträge
- 1.300
Auch schon gelesen. Mal sehen, wie Proxmox das löst. 0.7 ist ja schon in PVE5 (Stretch) enthalten obwohl das originale Stretch auf 0.6 steht. Buster ist noch freezed und hat nur 0.7 im Bauch, das wird sich wohl auch erst mit Debian 11 ändern.
Ich schätze, dass man auf Release von Buster warten wird, dann PVE 6 kommt und hoffentlich zol backported wird.
Ich schätze, dass man auf Release von Buster warten wird, dann PVE 6 kommt und hoffentlich zol backported wird.
martingo
Experte
- Mitglied seit
- 17.01.2017
- Beiträge
- 1.300
Luckysh0t
Enthusiast
Hallo zusammen,
bin gerade am überlegen ob ich wichtige Daten über ein mobiles ZFS RAID sichern soll (lofiadm).
Da kamen mir nun folgende Fragen auf.
Welcher Weg der Speicherung im HiDrive(Strato, mit Protokollpaket) ist sinnvoller.
Die Dateien mittels rsync/ssh übertragen/aktualisieren.
oder
HiDrive mittels WebDav/https (kann das Solaris überhaupt?) einbinden, die Dateien übertragen und dann vom gemappten WebDav Laufwerk als Pool/Dateisystem
einbinden (wenn das überhaupt geht).
oder
über smb/cifs liese sich die HiDrive auch mounten - dann aber unverschlüsselt.Ansonsten der gleiche Weg wie bei Webdav.
(Wobei man wohl das HiDrive auch über Openvpn anbinden kann..und dann weiter über smb/cifs)
----
Bei dem zweiten Weg würde man sich halt den Syncjob etc. sparen, da ja die Daten schon "oben" sind.
Gruß
Lucky
bin gerade am überlegen ob ich wichtige Daten über ein mobiles ZFS RAID sichern soll (lofiadm).
Da kamen mir nun folgende Fragen auf.
Welcher Weg der Speicherung im HiDrive(Strato, mit Protokollpaket) ist sinnvoller.
Die Dateien mittels rsync/ssh übertragen/aktualisieren.
oder
HiDrive mittels WebDav/https (kann das Solaris überhaupt?) einbinden, die Dateien übertragen und dann vom gemappten WebDav Laufwerk als Pool/Dateisystem
einbinden (wenn das überhaupt geht).
oder
über smb/cifs liese sich die HiDrive auch mounten - dann aber unverschlüsselt.Ansonsten der gleiche Weg wie bei Webdav.
(Wobei man wohl das HiDrive auch über Openvpn anbinden kann..und dann weiter über smb/cifs)
----
Bei dem zweiten Weg würde man sich halt den Syncjob etc. sparen, da ja die Daten schon "oben" sind.
Gruß
Lucky
Zuletzt bearbeitet:
