Hey Leute!

Ich würde gerne auf meinem MacPro ein Xsan zum laufen bringen, so dass ich mit meinem FCPX-Clients auf die zentral gehosteten Daten zugreifen kann. Die FC-Karte von Apple kostet 999€ und ist mir etwas zu teuer. Gibt es da eine günstige Alternative? Bei Apple ist das ja mit den Treibern nicht so einfach.

Und dann noch die zweite Frage: muss der Client eigentlich auch per FC angeschlossen sein? Im Switch treffen sich ja die Daten und SAN-Locations (im aktuellen Fall via nfs) kann ich im FCPX auch ohne FC hinzufügen.

Vielen Dank und beste Grüße,
Cromb

Die günstigste, die ich kenne, ist die da: (Promise SANLink 2 http://geizhals.at/de/promise-sanlink2-f29sanl220m0001-a1045523.html -- schon komplett für den MacPro optimiert)

SCNR

Bei der Art und Weise wie Du Deine Fragen stellst (keine Angabe zur FC-Geschwindigkeit, Durcheinanderschmeißen von SAN/NAS, "Switch" -- was für Switch? FC- oder Ethernet? Falls sich da irgendwas "trifft", meinst Du ggf. gar nicht FC sondern iSCSI?), kann man Dir eigentlich nur wärmstens raten, Dich einem auf professionelle Postproduktion spezialisierten Dienstleister anzuvertrauen...

Hast Du schon mal in der Bucht geschaut? Ich hab vor kurzem 2 Karten für 140 Euro gekauft,
neu und original Verpackt..(also 70 Euro je Stück). Hab gerade geschaut der Dealer hat noch 3 Stück… gib mal bei Ebay "NEW Apple PCI-X xServe Fibre Channel card" ein dann landest du dort.

Brillianter Plan, nachdem kein einziger MacPro (und auch schon der letzte G5 nicht mehr) PCI-X sondern nur PCI Express hatte. Davon abgesehen ist FC mit 2 GBit/sek anno 2014 auch irgendwie nur... äh... komisch?

Die Apple-Karte, die Du meinst, ist in Wirklichkeit eine LSI 7404EP.

Es ist richtig, dass man gebrauchte Fibre-Channel-Karten günstig über eBay bekommen kann, aber man muss, wie von Thomas Kaiser schon angedeutet, sehr sorgfältig darauf achten, die PCI-Express-Karten für den Mac Pro nicht mit PCI- und PCI-X-Karten für PowerMacs zu verwechseln.

Und ebenso höre ich auch aus der Frage heraus, dass Du nicht wirklich weißt, wie XSAN arbeitet. In der Standardkonfiguration ist ein XSAN-Client mit 2 Ethernet- und 1 Fibre-Channel-Verbindung angeschlossen. Vereinfacht gesagt läuft auf dem ersten Ethernet das "normale Hausnetz", auf dem zweiten die Datei-Metadaten und auf dem Fibre Channel die Nutzdaten.

Ja sorry hatte ich in diesem Fall übersehen

Hey!

Danke für die Rückmeldungen!
Ich kenne den Unterschied zwischen NAS und SAN. Ein komplettes SAN werde ich hier nicht aufbauen können, da ein Teil der iMacs hier kein Thunderbolt hat und somit FC nicht durchgängig möglich ist.

Letztlich geht es mir auch nicht um ein separates Netz nur für die Daten. Mein GB-Ethernet reicht ja auch aus. Ich möchte bloß Xsan anstelle von NFS nutzen. Und da frage ich mich, ob es dem Server.app reicht, wenn es eine FC-Karte findet. Hat das schon mal jemand ausprobiert? Sprich: kann ich FC nur einer Seite des Switches haben (zwischen Server und Switch) und auf der anderen Seite (zwischen iMac und Switch) Ethernet? Ziel ist es, dass ich in FCPx die neuen Libraries auch auf einem zentralen Server hosten kann, so wie ich es gerade per Ethernet/NFS mache. Da habe ich im Internet noch nichts drüber gefunden.

Und selbst wenn es kein SAN wird, sonder NFS über Ethernet bleibt: welche FC-PCIe-Karte (außer die von Apple) ist kompatibel zu Mavericks?

Danke!

Du kannst generell auch Atto-Karten nehmen, die laufen bei und und bei unseren Kunden problemlos.

Kannst Du ggf. mal aufmalen, was Du erreichen willst? Also welche Hardware vorhanden ist.

Sonst schick mal eine PN - wir SIND so ein komischer Dienstleister mit Ahnung von FC und v.a. der Nutzung in gemischten Netzwerken (FC und Ethernet bzw. auch Windows und Mac). Nicht alles, was geht, funktioniert auch relevant in FinalCut!

Hey meltingmind!

Ich hab's mal versucht zu illustrieren. Macht das Sinn? Würde es funktionieren?
Die Atto-Karten, die ich gefunden habe, sind leider kaum günstiger als die Apple. Ich dachte mehr an solche Preisregionen:
Ich brauche (zur Zeit) noch kein 10GBase. Im Moment nutze ich zwei GB-Ethernet-Ports im Bond. Wäre schön wenn das mit SFP wieder so gehen würde.

Wenn am Ende FCPx das Xsan nicht anerkennt, weil der iMac über Ethernet angeschlossen ist, macht das Ganze natürlich keinen Sinn mehr...

Vielen Dank!

ich hab noch zwei von den apple karten liegen - bist du telefonische oder per mail erreichbar

Weder noch.

XSan ist grob gesagt "Daten per Fibrechannel und Metadaten über Ethernet". Du hast einen Gbit-Ethernet-Switch, der paar SFP/GBIC-Slots hat, über die Du Gbit-Ethernet per SFP (optische Strippe) machen könntest. Das hat nichts mit Fibrechannel zu tun, die Dir vorschwebende günstige HP-10GBit-Ethernetkarte auch nicht. Und die und den Switch sinnvoll zu kombinieren, geht erst recht nicht (weil SFP+ mit 10 GBit/sek an SFP mit 1 GBit/sek halt nunmal völlig sinnfrei ist).

FC ist teuer. Punkt. 10 GBit Ethernet ist günstiger, evtl./potentiell schneller und man kann damit über entsprechende Protokolle (iSCSI, FCoE oder FCoIP) auch SAN spielen. Für 10 GbE fehlt Dir ein passender Switch, für FC das entsprechende SAN-Device nebst drumherum. Das ist hinten und vorne falsch gedacht ("konzipiert" würd ich's jetzt nicht wirklich nennen wollen )

Da liegt offenbar ein größeres technisches Missverständnis vor.

Das Bild kann man zwar kaum lesen, aber ich glaube jetzt zu erahnen, dass Du darüber nachdenkst, einen Mac per Fibre-Channel-Karte mit einem glasfaserfähigen Ethernet-Switch zu verbinden.

Auch wenn beides über optische Kabel läuft, sind das zwei Netzwerktechniken, die vollkommen verschieden arbeiten und auf diese Weise nicht miteinander kompatibel sind. Mit SAN und XSAN hat das zunächst mal gar nichts zu tun.

Du bräuchtest in diesem Fall eine Glasfaser-Ethernet-Karte für den Mac Pro, keine Fibre-Channel-Karte. An der grundsätzlichen Arbeitsweise, dass der Mac Pro als NFS-Server läuft, würde sich dabei aber auch nichts ändern.

Aber damit hätte er fast nichts gewonnen (wenn's beim bislang eingesetzten Switch bleibt, denn der kann halt nunmal nur 1 GBit/sek, egal ob per Kupfer oder via SFP -- evtl. könnte man das Bonding auf dem MacPro noch mehr "in die Breite" gehen lassen aber auch das ist nur bedingt sinnvoll).

(X)SAN erscheint mir in der Miniatur-Konstellation deutlich zu aufwändig u.v.a. zu teuer, 10 GbE geht sinnvoll nur mit neuem Switch (und da werden aktuell grad mal die 10GBase-T-Varianten bezahlbar, bspw. der XS712T , den wir grad bei 'nem Kunden verbaut haben) und wirklich sinnvoll würde das auch nur dann, wenn die Clients ebenfalls noch "breiter" angebunden werden (wobei auf Client-Seite Bonding/Trunking relativ sinnfrei ist, weil mehr als Single-Link-Speed in der Konstellation nicht erreicht wird).

Und wenn man die Clients mit 10 GbE aufrüsten wollte, bräuchten die Thunderbolt + TB-PCIe-Enclosure und dann die jeweils günstigste ATTO-Single-Port 10 GbE-NIC drin (weil Karte ohne Support für OS X ist auch wieder nur sinnfrei).

Teurer Spaß für überschaubaren Nutzen...

Ja natürlich. Das Wort "brauchen" war auch in diesem Fall nicht ernst gemeint, sondern sollte nur heißen "um das hinzubasteln, was man auf der Skizze sieht".

Mir geht es primär um folgendes: NFS läuft bei mir nicht 100%ig stabil. Warum weiß ich nicht. Die Logs spucken nichts aus. Daher wollte ich Xsan probieren. Xsan lässt sich nicht via Server.app starten, so lange keine FC-Karte vorhanden ist. Daher die Frage: Lässt sich die Server.app überlisten, oder nicht?

10GbE sind nett, brauche ich aber nicht. Der Bond von zwei mal GbE reicht bisher aus. Daher würde auch noch meine Switch reichen, auch wenn die Karte dann nur auf 10% läuft.

Mehr als ein GBit kommt bei meinen Macs eh nicht an, da sie kein Thunderbolt haben und entsprechend nicht erweiterbar sind. Wenn die Macs über die Zeit ausgetauscht werden und über TB vorhanden ist, werde ich auch auf die SANLinks zurückgreifen und 100%iges SAN hier hinstellen. Wenn es nur das SAN wäre, dann würde ich die Investition nicht scheuen, aber mit Macs ist es zu teuer.

Aber wenn es eh nicht zu konfigurieren ist, dann lasse ich das Thema halt. Danach fragte ich ich ja auch schon im Eröffnungsthread: Wird es dann überhaupt funktionieren? Und wenn ich eure Antworten richtig interpretiere, wird es eben nicht funktionieren. Schade eigentlich.

Irgendwie wird die sich schon überlisten lassen.

Du weißt, was Du da in Server.app dann maximal machen kannst? Du kannst den Mac Pro als primären oder sekundären Metadata Controller definieren oder als XSan Client. Du wirst aber durch Herumgeklicke in Server.appt kein physisches SAN (FC-basierter Block-Storage, auf den die XSAN-Clients anschl. zugreifen könnten, wären sie in der Lage, Fibre-Channel-HBAs zu nutzen) herbeizaubern können. Hardware entsteht nicht per Mausklick sondern muß gekauft werden.

Die sinnigere Herangehensweise dürfte wohl die Behebung der NFS-Probleme sein.

Versuch macht kluch

Danke für den Hinweiß!

Ich schließe mal gerade noch ne Frage an: Wäre es denn möglich einen Client direkt - sprich ohne Switch - mit dem Server zu verbinden, wenn der Server eine PCIe-Karte und der Client wie SANlink über FC verfügen?
Und wenn das geht, könnte man das mit einer Quad-Channel-Karte auch mit mehr als einem Client schaffen?

Danke!

FC-AL kann man machen, aber fällt in einem FC-AL ein Gerät aus steht alles. FC ist ohne Switch bzw. converged Switch ist ziemlich sinnlos.

Eine dämliche Frage weshalb wird für Mac Clients NFS statt AFP verwendet?

Soweit ich weiß, ist Final Cut Pro darauf angewiesen, sein Videomaterial aus Performance-Gründen möglichst auf echten Festplatten zu halten, nicht auf File Servern.

Wenn man nun aber trotzdem das Material in einem Netzwerk bearbeiten möchte, gibt es zwei Alternativen: Ein SAN, das ja vereinfacht gesagt eine per Netzwerktechnik angeschlossene Superplatte darstellt, oder NFS, ein File Server-Protokoll, das darauf ausgelegt ist, sich möglichst wie eine externe Festplatte zu verhalten und nicht wie eine Peer-to-Peer-Server-Verbindung.

NFS ist außerdem das "native" Protokoll von OS X und wird zum großen Teil im Kernel abgehandelt. AFP ist dagegen eine "aufgepropfte" Technik, die Apple ab 1997 in die Vorgänger von OS X integriert hat.

Der historischen Bedeutung von NFS auf NeXT Hardware ist mir bewußt. Nur hat Apple sich dagegen entschieden es als Standardprotokoll für das Filesharing unter OSX einzusetzen, was leider in einem etwas stiefmütterlichen Pflege des Paketes endete. Wenn man schon Geld in die Hand nehmen will, sollte man das NFS direkt lösen, in dem dafür besser geeignete Hardware und Software anschafft.

hey!

Eine Punkt zu Punkt-Verbindung für jeden einzelnen Client geht nicht? Die Clients müssen einander nicht sehen. Es wird auch nicht auf die gleichen Daten zeitgleich zugegriffen.

Danke!

Wenn man ohne Switch arbeitet, muß man einem FC-AL aufbauen. FibreChannel Arbitrated Loop heißt nicht ohne Grund so. Point-to-Point ist dann ein Loop mir nur zwei Knoten, d.h. es werden trotzdem zwei Kabel zwischen den Computern benötigt. Man kann natürlich alle Computer in einem Loop integrieren, aber damit das dann funktioniert müssen alle Computer immer in Betrieb sein! Das ist so ziemlich sinnfrei bei Desktops.

FC-AL sähe bei Dir dann so aus:
MacPro iMac iMac MBP MacPro
Alle Geräte brauchen nur eine DualPort Karte/Adapter und im gesamten Netz wird mit derselben Geschwindigkeit kommuniziert.

Alternativ müßtest Du drei FC-ALs parallel betreiben, also im MP bräuchtest Du 6 FC Ports!

Der einzig sinnvolle Weg mit FC wäre eine Lösung mit FC Switch, aber mir sind nur FC Switche fürs Rack bekannt, und die will man nicht am Arbeitsplatz haben. Es gibt zwar kleine spezielle Racks fürs Büro, die schallisoliert sind, aber das kostet alles extra.

Der HP SN6000 kostet in der 12 Port Variante ab 3.5k EUR. Die FC Switche der üblichen Verdächtigen Cisco, Brocade, QLogic … sind meistens deutlich teurer.

Bei den Preisen für einen FC Switch, bist Du besser beraten etwas anderes zu machen. Aber das setzt voraus, daß Du Dich mit einer Linux Box anfreunden kannst, entweder selbst verwaltet oder per Dienstleister. Alternativ könntest Du eine professionelle NAS Appliance mit NFS Support kaufen, die dürfte leichter administrierbar sein.

Danke für die Antwort, dass hat mir sehr geholfen!

Die Macs werden eh successief eingetauscht. Daher könnte ich mit dem ersten Mac und FC-AL starten und wenn der zwei hinzukommt den Switch dazunehmen. Oder vielleicht noch übergangsweise beide im FC-AL (zwei Arbeitsplätze stehen vis-à-vis). Spätestens mit dem dritten Mac gehts dann nicht mehr ohne Switch.
Lautstärke wäre nicht das Problem, der Switch wäre von den Arbeitsplätzen deutlich entfernt.

Vielen Dank für die Unterstützung!

Schon einmal einen Rack Switch oder Server zum Konfigurieren am Arbeitsplatz gehabt?

Vergiss FC. iSCSI over Ethernet mit der Passenden Software* scheint für deinen Zweck besser zu passen. Ist dann auch transparent erweiterbar, z.B. via Ethernet-Link Bonding oder 10GBit Hardware Upgrade.

* Xtarget, SANmp & iSCSI initiator

Grad Bonding bringt bei iSCSI genau gar nix, wenn dann Multipathing/MPIO. Und dann würde ich der Fairness halber auch gleich drauf hinweisen, dass die günstige Variante bei 10 GbE auf Kupfer basiert (weil der Anfrager den Eindruck macht, total auf optische Strippe also LWL fixiert zu sein).

Und eigentlich würde ich erstmal prüfen, ob es den ganzen Zirkus überhaupt braucht, wenn angeblich eh kein konkurrierender Zugriff verschiedener Clients auf identische Daten erfolgen muß (dann kann man sich den ganzen Kram nämlich mit komplett lokalen Daten und irgendeiner Art von Sync vom zentralen MacPro hinbasteln, was auch der Performance zugute kommen dürfte).

Und in die Zukunft gedacht, wenn denn alle neuen Maschinen eh TB2 haben werden und das ganze Setup so mickrig ist, würde ich weder über FC, noch über 10 GbE sondern in der Topologie mit einem Server und 3 Clients selbstverständlich nur über "IP over Thunderbolt" nachdenken. Außer man will sinnlos Geld verbrennen oder das Ganze künstlich ausbremsen.

Geschwindigkeit ist nicht mein Problem: FCPX möchte seine Libraries nur auf NFS- oder SAN-Platten ablegen. Das ist mein Problem.

Lokale Sicherung kommt nicht in Frage, da zwar nicht mehrere Editoren zeitgleich auf die gleiche Library zugreifen, aber nacheinander. Weiterhin sollen, falls FCPX es irgendwann unterstützt, mehrere Editoren auch auf das gleiche Material zugreifen. Zudem läuft das Netzwerkrenden schneller, wenn der Server die Library hostet. Der Arbeitsplatz darf auch aus dispositorischer Sicht nicht entscheidend sein.

IP over Thunderbolt kommt erst dann in Fragen, wenn die Kabellänge deutlich steigt. Ausserdem müsste ich einen anderen Server haben, da ich meinen RAID-Controller nicht in den neuen MacPro einbauen und keine TB2 an meinen alten MacPro anstecken kann.

Aber die kurz erdachte "schnelle Lösung" mit Xsan hat ja nicht geklappt, daher ist das Thema eh erst mal aus der Welt. Und wer weiß, was FCPX in der nächsten Version für Überraschungen bereithält.

So denn,
danke an alle Hilfeleistenden.

Optische TB-Kabel sind verfügbar. Für die werden hierzulande teils noch totale Phantasiepreise abgerufen aber der Trend geht so langsam aber sicher in Richtung "realistisch", siehe die 10m-Strippe von Corning:

Wenn Du Dir anschaust, was FC- oder 10 GbE-Transceiver kosten (die Du an jedem Ende eines LWL brauchst, solltest Du weiterhin so auf optische Strippen fixiert sein ), dann ist das beinahe ein Schnäppchen.

Klar, ohne neuen "Server", konkret einem MacPro mit seinen 6 TB2-Ports wäre das "IP over Thunderbolt"-Szenarium komplett daneben. Das Ganze funktioniert in "Meshing"-Situationen (wenn mehrere Macs in so einer Art "Daisy Chaining" per "IP over Thunderbolt" vernetzt würden) zwar prinzipiell aber das ganze Bridging von Daten geschieht nicht auf dem TB-Layer sondern drüber in Software, was a) die Last auf beteiligten Macs drastisch nach oben schraubt und b) die übers Netz erzielbaren Transferraten ziemlich ausbremst in der Konstellation ein ziemlicher Quatsch, leider.

Mit anderen Worten: Das Ganze würde nur ansatzweise sinnvoll in einer Stern-Topologie mit einem frischen MacPro in der Mitte, an dem der Storage hängt, umsetzbar sein (ob/wie es FCPX dann erlaubt, dass dieser MacPro selbst auch mitrendert, weiß ich aber nicht). Und auch nur, wenn die Zahl anderer "Clients" sehr klein ist, so dass jede Kiste eine Direktverbindung mit dem "Server"-MacPro herstellen kann.

Aber so ein Setup mit kleinem Team und einem MacPro als NFS-Server per "IP over Thunderbolt" sollte bei einem Bruchteil der Kosten entsprechende FC- oder 10 GbE-Lösungen alt aussehen lassen. Vorausgesetzt, man tuned die Parameter in der /etc/auto_shares auf den Clients passend zum Server, etc. pp. (wir sehen es immer wieder, dass bei Kunden massig in Hardware investiert wird und dann aufgrund Fehlkonfiguration nur ein Bruchteil der Leistung am Ende bei den Usern/Maschinen ankommt)

Das ist immer noch viel zu teuer. Für diese Preise gibt es fertig konfektionierte optische QSFP 40GbE oder IB Kabel, die fertigen optischen 10GbE SFP+ Kabel sind billiger. SFP+ Kupfer ist nochmals deutlich billiger, wobei hier der Preis mit der Länge korreliert. Bei Glas ist der Preis nahezu unabhängig von der Länge.
Transceiver nimmt man nur dann, wenn die Kabel schon fertig verlegt wurden. Also nur für Raum-Raum-Koppelung oder die Außenanbindung, im Serverraum reichen die fertigen SFP+ bzw. QSFP Kabel aus.
Und man hat immer noch die gleichen NFS Probleme, weil man immer noch OSX als NFS Server nutzt. Sinnvoller ist es einen Linux NFS Server (oder NAS Appliance) mit 10GbE Karte, passenden Switch mit 10GbE Uplink zu nehmen und die Macs ganz normal über GbE anzuschließen.

Aha, und welche ominösen NFS-Probleme sollen das denn sein, wenn ausgerechnet OS X mit OS X Server per NFS reden soll?

Ich kenn aus eigener Erfahrung Geschissel mit Linux als NFS-Server, wenn OS X Clients am Start sind (Symptome IIRC ähnlich wie hier ) aber zwischen OS X und OS X (und wenn man nicht im Finder per "nfs://" herumspielt sondern das Ganze richtig, d.h. per automount macht) wär mir da erstmal nix bekannt. Wobei ich gerne zugebe, dass ich nur seltenst am Mac mit NFS zu tun habe, da AFP im Regelfall die viel sinnigere Variante ist.

Wenn Apple FCPX entsprechend anpasst, bin ich auch vom FC wieder weg. Aber zur Zeit geht es eben nicht, Libraries über AFP oder SMB anzusprechen.

Lassen wir einfach etwas Zeit vergehen.

Was ist jetzt schon wieder FC?

Ja, mag sein. Die Aussage bzgl. AFP war nur ein Disclaimer meinerseits, dass ich selten mit NFS am Mac zu tun habe. Da NFS wohl als einziges NAS-Protocol abseits echter SAN-Topologien seitens FCPX akzeptiert wird, hat's vermutlich was mit den Semantiken des Dateisystems und allerhöchstwahrscheinlich Locking zu tun. Schon mal probiert, in /etc/nfs.conf


einzutragen? Aber letztlich wurscht, Deine NFS-Probleme scheinen es ja nicht wert zu sein, eingregrenzt zu werden. Lieber bissi mit SAN-Gedankenspielchen die Pferde scheu machen...

Diese Frage stellst Du an den falschen.
Deine Empfehlung der Problemlösung ist fast deckungsgleich mit den Lösungsansätzen für Linux. Wo bitte ist da der große Unterschied?