MacPro 3,1 und ESXi

[D€NNIS]

Moin euch,

eigentlich wollte ich bei dem doch recht preiswerten Dell T20 einsteigen und diesen als kleinen ESXi Server in unser Büro stellen.
Eine VM auf dem Server sollte dabei den Job übernehmen verschiedene SAN Volumes für Backupzwecke zu kopieren während eine pfSense VM unsere bestehende FortiGate 60C
ersetzen soll.

Da unsere SAN Volumes HFS+ formatiert sind wäre es natürlich ideal wenn die Backup VM auf MacOS basiert, was soweit ich informiert bin mit ESXi "out-of-the-box" (abseits der rechtlichen Frage natürlich) nur auf einem Mac Host möglich ist. Da wir ohnehin noch diverse ausrangierte MacPro 3,1 im Büro stehen haben, dachte ich mir, warum den T20 holen wenn es doch prinzipiell auch mit dem MacPro 3,1 möglich wäre, eben mit dem Vorteil auch MacOS als Gastsystem laufen lassen zu können.

Ich hab allerdings keine Erfahrungswerte und möchte auch nicht das die ganze Sache ne zu starke "homebrew" Note hat.
Möglicherweeise hat aber jemand von euch Erfahrungswerte damit und kann mir vielleicht ein paar Hinweise/Tipps geben.
Die größte Unsicherheit ist momentan, ob ich überhaupt dazu in der Lage wäre USB Controller (für die Nutzung des Dongles einer SAN Software die wir verwende) und FC-HBA in eine VM durchzureichen.
Soweit ich weiß wird VT-d erst ab den Chipsätzen der Nehalem Architektur unterstützt aber da bin ich mir nicht ganz sicher.

 

[Opticum]

ein Mac Pro 3,1 ist völlige Stromverschwendung, die Teile sind "uralt backstein"

VT-D muss nicht nur von der CPU sondern auch vom Chipsatz unterstützt werden, hat aber mit dem durchreichen von USB unter ESX auch nichts zu tun. Das geht auch ohne VT-D und könnte notfalls mit Hilfe eines Donglesserver (auch über VPN von der Firma) gelöst werden. Sehr gute Erfahrung z.B. mit diesem Produkt gemacht: myUTN-80

MacOS als Gastsystem ist ein Notbehelf, es gibt keine hardwarebeschleunigten Grafiktreiber, Yosemite hat das ganze noch einmal verschärft. Wenn du irgendetwas auf OSX machen willst was über das bloße Testen von kleinen Apps hinausgeht, nimm einen echten Mac und keine Virtualisierung. Alles andere wird nicht zufriedenstellend laufen.

zum Thema pfsense VM: nimm eine seperate Hardware wenn ihr das in einem "produktiven" Umfeld machen wollt. Ich habe mich nicht zu viel mit der pfSense beschäftigt, würde eher zu Sophos oder einem Hardwarerouter von Lancom raten.

Kurzum: nimm echten Mac, echte Firewall Hardware/Hardware Router, verkauft die alten MacPro 3,1 (ich nehme einen! )

 

[D€NNIS]

Danke für deine Antwort.

VT-D muss nicht nur von der CPU sondern auch vom Chipsatz unterstützt werden, hat aber mit dem durchreichen von USB unter ESX auch nichts zu tun. Das geht auch ohne VT-D und könnte notfalls mit Hilfe eines Donglesserver (auch über VPN von der Firma) gelöst werden. Sehr gute Erfahrung z.B. mit diesem Produkt gemacht: myUTN-80

Eigentlich ist VT-D rein chipsatz spezifisch solang die CPU eben VT unterstützt.

MacOS als Gastsystem ist ein Notbehelf, es gibt keine hardwarebeschleunigten Grafiktreiber, Yosemite hat das ganze noch einmal verschärft. Wenn du irgendetwas auf OSX machen willst was über das bloße Testen von kleinen Apps hinausgeht, nimm einen echten Mac und keine Virtualisierung. Alles andere wird nicht zufriedenstellend laufen.

Die Art Feedback hab ich gesucht, ich war mir ohnehin unsicher ob das ein gangbarer Weg sein kann aber ich denke ich werd dann von der Idee Abstand nehmen auch wenn ich keine hardwarebschleunigung innerhalb der MacOS VM benötigen würde.

zum Thema pfsense VM: nimm eine seperate Hardware wenn ihr das in einem "produktiven" Umfeld machen wollt. Ich habe mich nicht zu viel mit der pfSense beschäftigt, würde eher zu Sophos oder einem Hardwarerouter von Lancom raten.

Ich werde definitiv bei pfSense bleiben, auch wenn Sophos sicherlich im UTM Bereich Features hat, die pfSense als perimeter Firewall zumindest standardmäßig nicht bietet.
Die Firewall kann aus meiner Erfahrung guten Gewissens virtualisiert laufen, solang man da vor ESXi nochmal ne kleine SPI Firewall laufen hat seh ich da kein großes Sicherheitsmanko, wohl aber einen erheblichen Vorteil darin, das der T20 natürlich in den Anschaffungskosten deutlich geringer ausfällt als diverse firewall Appliances die eben nicht diese Flexibilität bieten. Wir sind ein kleines Büro und solche Kompromisse müssen eben gemacht werden.

Kurzum: nimm echten Mac, echte Firewall Hardware/Hardware Router, verkauft die alten MacPro 3,1 (ich nehme einen! )

Haha, i see. Nun gut wenn Du auf "uratl Backstein" der noch dazu Strom verschwendet abfährst mach mir ein Angebot und man kann drüber reden, das aber dann lieber per PN

 

[gea]

Es gibt meiner Ansicht nach eher gute und eher problematische Ideen

eher gute Ideen
- Server virtualisieren (ja, auch eine Firewall, ich werde mein Pfsense auch virtualisieren)
- eine Backup ESXi haben damit beim Ausfall nicht alles steht
- ESXi mit shared Storage/ NAS/ SAN nutzen, das macht alles einfacher/ schneller
- ein Backup NAS/ SAN damit beim Ausfall nicht alles steht
- OSX on Hardware

eher problematische Ideen
- ein alter MacPro als ESXi Server
- ein SAN auf Basis von HFS+ (vermutlich alt, langsam und unsicher)
- ich habe OSX virtuell am Laufen - selbst für einfache Sachen ist Grafik zu langsam
trotz neuester ESXi tools.

Ich muss gestehen, ich habe mich selber früher mal für eine Apple SAN interessert (als Apple noch Computer im Namen trug) bin dann dank Apple zu ZFS gekommen und dabeigeblieben. Leider hat Apple dann professionelle Computer samt ZFS aufgegeben und stattdessen i-Gedöns gebaut.

Mein Tipp: Einen Server wie den Dell als ESXi und SAN auf ZFS wechseln. Es gibt zwar ZFS wieder für OSX, ist aber noch nicht konkurrenzfähig. Mein Tipp als OSX SAN Ersatz wäre momentan Oracle Solaris (11.3) oder NexentaStor. Die haben SMB2.1 und sind damit auf Macs so schnell wie AFP (EoL, Apple wechselt gerade zu SMB als default Protokoll)

 

[D€NNIS]

Mein Tipp: Einen Server wie den Dell als ESXi und SAN auf ZFS wechseln. Es gibt zwar ZFS wieder für OSX, ist aber noch nicht konkurrenzfähig. Mein Tipp als OSX SAN Ersatz wäre momentan Oracle Solaris (11.3) oder NexentaStor. Die haben SMB2.1 und sind damit auf Macs so schnell wie AFP (EoL, Apple wechselt gerade zu SMB als default Protokoll)

Danke fürs Feedback.

Soweit ich weiß unterstützt die Fibre Channel Implementierung "COMSTAR" in OpenSolaris (unsere Produktionsraids bestehen aus einer 8Gb Dual Channel FC Raid Appliance 24bay + 24bay JBOD Expander) nur einen FC-HBA von qlogic und meinst Du wirklich die Performance wäre dann besser über SMB 2.1 als über den direkten Blockzugriff von der Mac Workstation auf die HFS formatierten RAIDs?
Oder reden wir grad aneinander vorbei und Du redest von XSan, das verwenden wir nämlich nicht, sollte hier grad der Eindruck enstanden sein. ^^

Das letzte mal das ich mich mit Nexenta beschäftigt habe, ist schon ne ganze Weile her.
Wie sieht denn dort die Fibre Channel Unterstützung aus und vor allem wären mal aktuelle Preise interessant.

 

[gea]

Ich habe angesichts der MacPro und FC tatsächlich an XSAN von Apple gedacht.

Irritiert hat mich auch etwas die Aussage "HFS formatierte Raids".
Fahrt Ihr wirklich HFS auf dem SAN und macht darüber Blockdevices (also HFS -> FC Blockdevice -> HFS) oder ist HFS nur auf den Targets?

Wie auch immer, Blockdevices per FC oder iSCSI sind natürlich sehr schnell. Die Targets sind aber exklusive einem Rechner zugeordnet und werden da wie eine lokale Festplatte verwaltet. Ohne ein Cluster-System kann man das nur mit Funktionen auf dem SAN selber backuppen. Als Alternative kann nur der Mac, der das Target gemountet hat, dieses per TimeMachine sichern. Ein paralleller Zugriff von einem anderen Mac aus darf nicht sein.

Wenn man Blockdevices nutzt, weil man Programme fährt, die nur mit lokalen Festplatten arbeiten, dann ist FC/ iSCSI das Mittel der Wahl. Man kann dann Backups auf dem SAN machen. Diese SAN Backups sind meist Snapshots. Die sind bei HFS nur dann konsistent, wenn das Volume offline ist, also am Besten nachts wenn alle Macs aus sind. Die Alternative ist TimeMachine von jedem einzelnen Mac aus der ein FC Target hat. Dabei werden die geänderten Daten auf ein HFS/AFP Backupvolume gesichert (= kopiert, langsam).

Es bleibt das Problem, dass HFS nicht ganz auf der Höhe der Zeit ist und weder als besonders sicher noch schnell gilt.
Neuere Dateisysteme sind crashresistent mit CopyOnWrite, haben Snapshots und Echtzeit Prüfsummen sowie ausgefeilte Caches zur Beschleunigung .


Die Alternative zu individuellen FC/iSCSI Blockdevices ist Shared Storage mit Zugriff über AFP, NFS oder SMB über 10 GbE statt FC.
Bisher war es auf dem Mac so, dass AFP am Schnellsten war (durchaus ähnlich FC), dann kam NFS und am Langsamsten war SMB.
Apple ist zwischenzeitlich von AFP auf SMB als Standardprotokoll gewechselt. Die Apple eigene SMB Entwicklung benötigt aber SMB 2+ um schnell zu sein. Macs mit SMB1 sind grausam langsam.

Backups bei Shared Storage ist viel einfacher. Normalerweise geht das auch über das SAN und Snapshots. Korrupte Dateisysteme sind nicht zu erwarten, allenfalls korrupte Dateien wenn die gerade geöffnet sind. Da mehrere Rechner/ Personen gleichzeitig auf die Daten zugreifen kännen, ist das allgemeine Handlich eh viel unkomplizierter. FC/ iSCSI auf dem Mac würde ich heute daher vermeiden wo es nur geht.

Für unsere eigenen Mac Pros (Videoschnitt) haben wir zwar auich ein mitgeliefertes Avid Storage (per 2 x 1 GbE). Unser üblicher Zugriff erfolgt aber über 10 GbE (Sanlink2 10 GbE Adapter angeschlossen an Thunderbolt2) sowie normales Filesharing auf unsere OmniOS ZFS Filer. AFP nutzen wir nicht, da netatalk zuviel Probleme bereitet. Bisher ist NFS unser Protokoll der Wahl. Liegt daran dass der Solaris CIFS Server bisher nur SMB1 unterstützte und auf SAMBA wollten wir nicht wechseln.

Jetzt zu OpenSolaris
OpenSolaris ist tot. Aktuell gibt es Oracle Solaris (kommerziell ca 1000 Euro/Jahr, freier Download für Demo und Entwicklung) sowie Illumos, den freien Fork von Solaris. Darauf aufbauend Distributionen wir OmniOS (auch kommerziell frei nutzbar) und NexentaStor (kostet je nach Kapazität, Community Edition ist frei bis 18GB aber nicht kommerziell nutzbar). Aktuell hat Solaris (ab 11.3) und NexentaStor SMB 2.1 eingebaut. OmniOS ist (noch) auf SMB1.

Solaris/ Illumos unterstützt mit Comstar FC/iSCSI umfassend (Adapter Kompatibilität beachten). Ich würde aber als Ziel eher 1/10 Gb Ethernet und als Protokoll SMB sehen, dazu als Dateisystem auf dem SAN/NAS dann ZFS. Dazu regelmäßige Snaps auf dem SAN (viel eleganter als Timemachine da ohne Zeitverzug) und Backups per ZFS Replikation auf ein zweites SAN. Sowas gibts z.B. mit einem HP G8 Microserver fast umsonst. Für inkrementelle Replikationen reicht da 1 Gb/s.

 

[D€NNIS]

Irritiert hat mich auch etwas die Aussage "HFS formatierte Raids".

Unser Axus RAID + JBOD Expander (mittlerweile ist Axus leider insolvent ) mit jeweils 24bays hängen an der FC fabric und von dort aus eben am HBA eines MacPro 5,1.
Dies ist auch die einzige Workstation in unserer Postproduktion.
Die RAIDs sind mit insgesamt 48 Platten à 3TB bestückt, daraus wurden insgesamt 4xR6 Volumes konfiguriert ( = 30TB nutzbare Speicherkapazität pro Raid Volume)
Die 4 LUNs bilden 2 Paare, wobei jedes Produktionsvolume ein Backupvolume als Gegenstück hat. (z.B PROD1 + BACKUP1 / PROD2 + BACKUP2)
Formatiert sind diese Volumes dann wie bereits angedeutet mit HFS+, weil es unter MacOS bis auf ExFAT eigentlich alternativlos ist. (zumindest bei blockbasiertem Zugriff)
Zusätzlich hängt noch eine Tandberg T24 LTO5 Library mit an der FC fabric. (Zoning an der FC fabric, da es sonst Probleme mit der SC LTO Library an einem DC HBA gäbe)
Da - wie Du selbst schon richtig gesagt hast - bei blockbasierten Zugriffen immer ein Client Exklusivzugriff auf eine der LUNs haben muss, damit es nicht zu Konflikten kommt, setzen wir SANmp ein, prinzipiell ist es zwar nicht mehr notwendig, da wir sowieso nur eine Workstation in der Post fürs Editing verwenden aber es erleichtert den Backup Workflow etwas. (SANmp oder alternativ metaSAN kennst Du sicherlich)
SANmp ist dabei nicht direkt als ClusterFS zu verstehen, sondern erlaubt schlichtweg einem Client exklusives RW Recht auf ein SANmp Volume wohingegen andere Clients, dieses bereits in Verwendung befindliche Volume zumindest noch read-only mounten können.

Die AVID Storages sind natürlich für echtes kollaboratives Arbeiten sehr komfortabel allerdings auch schweineteuer ^^ und wir haben uns nach der Änderung des Lizenzmodels von AVID Anfang des Jahres auch davon getrennt.
Editing läuft bei uns jetzt fast ausschließlich über Adobe CC und teilweise eben auch DaVinci Resolve (vor allem das Grading natürlich)

Die Idee ist also nun via SANmp innerhalb einer MacOS Umgebung oder alternativ in einer Windows VM, in der ich den FC-HBA durchreichen kann, die Produktionsvolumes auf ihre entsprechenden "Backup Counterparts" zu sichern. Da HFS+ von Windows nicht nativ unterstützt wird müsste ich mir in einem solchen Fall z.B mit dem HFS Filesystem Driver von Paragon behelfen, der recht stabil sein soll, wie mir zugetragen wurde.
Da ich mit SANmp wie oben geschildert die Produktionsvolumes immer noch RO mounten kann, selbst wenn diese durch unsere Editing Workstation in Verwendung sind hätte ich somit die Möglichkeit auf die Backup Volumes zu sichern.

 

[gea]

Wenn ich das jetzt richtig verstehe, gibt es ein Axus SAN System mit 48 Platten das 4 Targets (jeweils 12 Platten Raid-6) à 30 TB bereitstellt. Diese 4 Targets sind per FC an einen MacPro quasi als lokale HFS+ Platten angeschlossen, der zwei der Targets als Schnittablage benutzt. Die beiden anderen sind jeweils Backup. Weitere Rechner nutzen das SAN nicht oder allenfalls read only.

In dem Fall würde ich einfach per Timemachine auf der Workstation abends die Daten von den beiden Produktionsvolumes auf die Backupvolumes sichern. Insgesamt ist das aber kein Backup. Ein Fehler, Blitzschlag oder was es sonst noch gibt und die Daten sind weg. Die Alternative mit LTO ist da eher Backup. Meine Erfahrung mit Bändern ist aber eher schlecht. Alles furchtbar langsam und im Fall der Fälle ist das Band nicht lesbar.


Ich mache das bei mir so
Wir haben ein primäres ZFS Storage. Das ist ein normaler Intel/ SuperMicro Storageserver auf Basis des freien OmniOS z.B. mit 24 Platten und einem ZFS Pool. Darauf werden Dateisysteme angelegt und per AFP, NFS oder SMB freigegeben. Möglich ist auch FC/iSCSI. Für besonder Performance am Mac nehme ich aktuell NFS für alles andere SMB. Mit SMB2 werde ich wohl künftig auch auf den Macs SMB für alles nehmen.

Auf dieses Storage kann jeder Client (OSX oder Windows) gleichzeitig schreibend oder lesend mit 1 oder 10 GbE Ethernet zugreifen (Natürlich nicht auf offene Dateien). Auf dem Storage wird dann stündlich für den Tag, täglich für die Woche und wöchentlich für den Monat Snapshots erstellt. Dank ZFS geht das ohne anfänglichen Platzverbrauch oder Zeitverzug. Bei Problemen kann man dann auf diese Snapshots zugreifen. Ich mache das per Windows und "vorherige Version".

Daneben habe ich zwei externe Backup Systeme. Das sind auch OmniOS ZFS Systeme. Eines steht im Serverraum, das andere in einem anderen Brandabschnitt. Darauf werden täglich im Wechsel die Dateisysteme per ZFS send repliziert. Das basiert auch auf Snapshots und hält Dateisysteme identisch. Bei jedem Lauf werden nur Änderungen kopiert. Bänder habe ich gar nicht mehr, nur noch Plattenstorage.

Daneben wird einmal pro Monat der Storage und das Backup auf Fehler geprüft und eventuell repariert. Bei ZFS heißt das Scrubbing und läuft im Hintergrund. Ein Unmount ist nicht erforderlich.

Von den Kosten her ist das erschwinglich. Für ein kleines System tuts ein HP G8 Microserver mit 4 Disk Bays und 1Gb/s ab 180 Euro ohne Platten. Für ein 24 Bay System mit 10 GbE und 64 GB RAM sind ab ca 2000 Euro fällig. OS gibts kommerziell mit Support oder mit OmniOS auch umsonst. Für das Management habe ich eine Web-Gui entwickelt. Vielleicht ist das eine künftige Option.

 

[D€NNIS]

Wenn ich das jetzt richtig verstehe, gibt es ein Axus SAN System mit 48 Platten das 4 Targets (jeweils 12 Platten Raid-6) à 30 TB bereitstellt. Diese 4 Targets sind per FC an einen MacPro quasi als lokale HFS+ Platten angeschlossen, der zwei der Targets als Schnittablage benutzt. Die beiden anderen sind jeweils Backup. Weitere Rechner nutzen das SAN nicht oder allenfalls read only.

Korrekt.

In dem Fall würde ich einfach per Timemachine auf der Workstation abends die Daten von den beiden Produktionsvolumes auf die Backupvolumes sichern. Insgesamt ist das aber kein Backup. Ein Fehler, Blitzschlag oder was es sonst noch gibt und die Daten sind weg. Die Alternative mit LTO ist da eher Backup. Meine Erfahrung mit Bändern ist aber eher schlecht. Alles furchtbar langsam und im Fall der Fälle ist das Band nicht lesbar.

Machen wir in der Post schon seit Jahren mit CCC, mit TimeMachine habe ich persönlich keine guten Erfahrungen gemacht.
Es ist per Definition schon unser Backup, leider nur ohne den "SPoF" völlig umgehen zu können, das ist allerdings der nüchternen Realität geschuldet das Investitionen momentan schwer möglich sind und wir mit dem arbeiten müssen was derzeitig vorhanden ist, bis die Hardware abgeschrieben ist und wieder finanzielle Mittel zur Verfügung stehen. (auch jetzt durch den 4K Umbruch gibt es eben auch vieles andere, das angeschafft werden muss und viel Geld kostet)
Meine Erfahrung mit LTO Tapes ist eigentlich nicht so negativ. Natürlich kann mal ein Tape unlesbar sein aber es ist auch lediglich die letzte Instanz unserer Datensicherung.
Für kleinere abgeschlossene Projekte die ins Archiv wandern um wieder Platz auf den Produktionsraids zu schaffen finde ich es akzeptabel. (adäquate Lagerung der Tapes natürlich vorausgesetzt)

Von den Kosten her ist das erschwinglich.

Naja, das ist natürlich relativ.
In unserem Falle würde ein Microserver von der Speicherkapazität die über 4bays realisierbar sind schon nicht ausreichen um ein Produktionsvolume zu sichern.
Für das 24bay System würde ich momentan keine Freigabe was die finanziellen Mittel angeht bekommen und wir haben auch nicht die Räumlichkeiten um das Backupsystem räumlich vom Produktionssystem zu trennen.
Will nur damit sagen, das eine perfekte Lösung immer erstrebenswert ist aber dann doch oft an verschiedenen Umständen scheitert und man als kleinere Firma doch immer zu etwas Improvisation gezwungen ist. (leider)

OS gibts kommerziell mit Support oder mit OmniOS auch umsonst. Für das Management habe ich eine Web-Gui entwickelt. Vielleicht ist das eine künftige Option.

Das könnte definitiv eine Option für die Zukunft werden. Es stehen halt in nächster Zeit so viele neue Investitionen an das ich befürchte, das sowas erstmal hinten anstehen muss aber im Auge hatte ich deine webUI schon desöfteren und ZFS ist natürlich sehr reizvoll.

 

[gea]

Timemachine ist mit 2 x 30 TB Platten sicher keine angenehme Lösung. Falls CCC CarbonCopyCloner meint, so ist das auch keine Top Lösung. Ich nehme das allenfalls zum Clonen einer Systemplatte, bevorzuge da aber auch Clonezilla auf dem USB Stick und Clone/Restore auf NFS/SMB. Was ich mir aber noch vorstelllen könnte, ist ein Sync Tool z.B. rsync um 2 Platten/ Ordner syncron zu halten - auch übers Netz , idealerweise mit Snaps auf dem Backup kombiniert.

Ein kompletter Wechsel von HFS local Storage auf ZFS shared Storage erfordert aber auch Vorbereitung und Erfahrung. Auch bietet die jetzige Lösung zwar keine Snaps, keine SAN Replikation und ist auch nicht besonders sicher dafür aber groß und relativ schnell.

Ich würde in Stufen vorgehen. Da aktuell ein ESXi Server geplant ist, würde ich da schauen, dass genügend ECC-RAM reingeht, dass vt-d funktioniert, ein SAS-HBA 4i/4e vorsehen, eventuell mit 10 GbE Kupfer. Da dann ESXi drauf. Eine VM kann eine Storage VM mit ZFS und pass-through auf den HBA sein. Mit den 4 internen Platten kann man anfangen ein Testsystem aufzubauen und Erfahrung zu sammeln. Wenn das alles funktioniert, kann man das vorhandenee externe SAS Expander Gehäuse daran extern anschließen. Es sollte funktionieren (auch wenn ich von Sata Disks an SAS Expandern wenig halte). 2 x 30 TB bleiben dann lokal, 2 x 30 TB als Backup unter ZFS.

Optional einen ESXi Server in einem 24 Bay Supermicro Case alternativ was günstiges (Norco, Intertech) und ein SuperMicro Mainboard. Das wäre dann auch eine Basis für Storage.

Stufe 2 wäre dann ein neues ZFS Produktionssytem mit 10 Gbase-T und viel RAM, erst als Ergänzung dann als Ersatz für das Axus. Storage und Backup sollten aber immer wenigstens 2 getrennte Maschinen sein. Den HP Microserver sehe ich dann durchaus als Archivoption zum Wegschließen und als schnelle Bandalternative mit 12-18 TB Platz (Raid z1 bzw z2 und 4 x 6TB Platten) und direktem Zugriff. Auch für die jetzige Lösung.

 

[D€NNIS]

Falls CCC CarbonCopyCloner meint, so ist das auch keine Top Lösung. Ich nehme das allenfalls zum Clonen einer Systemplatte, bevorzuge da...
Was ich mir aber noch vorstelllen könnte, ist ein Sync Tool z.B. rsync um 2 Platten/ Ordner syncron zu halten - auch übers Netz , idealerweise mit Snaps auf dem Backup kombiniert.

CCC ist im Grunde genommen rsync in einer schicken GUI verpackt. Schnell ist CCC nicht (vgl. z.B Finder Direktkopie) aber es ist ein sicheres Tool imho.

Ein kompletter Wechsel von HFS local Storage auf ZFS shared Storage erfordert aber auch Vorbereitung und Erfahrung. Auch bietet die jetzige Lösung zwar keine Snaps, keine SAN Replikation und ist auch nicht besonders sicher dafür aber groß und relativ schnell.

Da hats Du sicherlich recht und die Erfahrung mit ZFS müsste ich mir auch erst aneigenen insofern....

Ich würde in Stufen vorgehen. Da aktuell ein ESXi Server geplant ist, würde ich da schauen, dass genügend ECC-RAM reingeht, dass vt-d funktioniert, ein SAS-HBA 4i/4e vorsehen, eventuell mit 10 GbE Kupfer. Da dann ESXi drauf. Eine VM kann eine Storage VM mit ZFS und pass-through auf den HBA sein. Mit den 4 internen Platten kann man anfangen ein Testsystem aufzubauen und Erfahrung zu sammeln. Wenn das alles funktioniert, kann man das vorhandenee externe SAS Expander Gehäuse daran extern anschließen. Es sollte funktionieren (auch wenn ich von Sata Disks an SAS Expandern wenig halte). 2 x 30 TB bleiben dann lokal, 2 x 30 TB als Backup unter ZFS.

...ist der stufenweise Vorschlag eigentlich auch die Variante die ich im Hinterkopf hatte.
Langfristig werden wir die Axus Raids ohnehin ausrangieren müssen und mit einer Übergangslösung kann man dann schonmal evaluieren ob ZFS in unserer Post auch Sinn ergibt.
Grad für 4K Footage brauch ich doch schon recht hohe R/W Petrformance auf den Storages und performantes ZFS erfordert neben einiger Expertise auch ordentlich Hardwarepower soweit ich da informiert bin.

Wegschließen und als schnelle Bandalternative mit 12-18 TB Platz (Raid z1 bzw z2 und 4 x 6TB Platten) und direktem Zugriff. Auch für die jetzige Lösung.

Da wird mir der kleine Microserver, so sehr ich die Lösung schätze leider nicht viel helfen. Die Archivierung unserer alten Projekte erfolgt immer recht langfristig und da sind 18TB bedauerlicherweise viel zu wenig.
Hinzu kommt, das LTO5 Tapes natürlich sehr günstig in der Anschaffung sind. Die Performance ist nicht optimal (Mit unserer Lib über FC angebunden ca 120/MBs) aber für die archivierten Projekte ist das in der Regel ohnehin nie zeitkritisch. Als Archivstorage müsste ich da schon andere Kaliber auffahren um das Ding nicht bereits nach einer Woche vollgepackt zu haben.

 

[gea]

Grad für 4K Footage brauch ich doch schon recht hohe R/W Petrformance auf den Storages und performantes ZFS erfordert neben einiger Expertise auch ordentlich Hardwarepower soweit ich da informiert bin.

Ist alles relativ und kommt darauf an wie verwöhnt man ist.

Die Axus hat meines Wissens relativ wenig RAM und zieht ihre Performance damit allein aus dem Hardware Raid. Das ist bei sequentiellen Read/Writes maximal n x eine einzelne Daten-Platte (10 Datenplatten). Die wichtigere iops sind aber nur 1 x eine einzelne Platte, da bei Raid-6 alle Platten positioniert werden müssen um etwas zu lesen oder zu schreiben. Cache Beschleunigung durch RAM oder Raid Controller ist vernachlässigbar.

ZFS ist Software Raid. Das setzt eine vernünftige CPU vorraus. Jeder beliebige i3 aufwärts ist aber grundsätzlich geeignet. Ein Quadcore Xeon reicht für High-Performance Storage. Die Performance kommt hauptsächlich aus dem RAM der als ReadCache genutzt wird. Daneben kommt es auf das Pool Layout an, also SSD only Pools für High-Performance, Multi Raid-10 für mittlere Ansprüche und single Raid-Z2 (wie Raid-6) für einfachere Sachen. Die jetzige Raid-6 Performance dürfte also kein Problem sein.