NAS für 3Ds Max Renderfarm (3-4 Renderclients) ?

[tryharder]

im Moment sind meine Texture-Libraries, etc. auf jedem Renderserver lokal installiert ... das läuft sehr gut hat aber den entscheidenden Nachteil, dass ich permanent alle Server auf dem gleichen Stand halten muss.

Meine Frage:

Kann ich auf einem NAS System alle Daten zentral speichern und können die Renderserver dann auch darauf zurückgreifen ... natürlich ohne Performance-Verlust ... und bei welcher Größenordnung Server funktioniert das ?

ich habe den Qnap TS-469 Pro Intel gegoogelt ... wäre das eine Lösung oder gibt es da einen ganz anderen Ansatz

Danke schon mal

Klaus

 

[Backbone]

Was für Plattensysteme sind denn da jetzt in den Servern und hast du mal geschaut was die so verdauen müssen?

Die allermeisten NAS sind nur über Gigabit angebunden. Gut möglich, dass das bei dir zu wenig Durchsatz ist.

Backbone

 

[fdsonne]

Auch stellt sich die Frage, ob es überhaupt so möglich ist... Sprich ob eine ausgelagerte Lib auf ein Networkshare überhaupt funktioniert.
Wenn ja, könnte man sicher was aufbauen.

Die größte Unbekannte ist aktuell nur die Performanceanforderung. Wenn 3-4 Clients gleichzeitig auf die Lib zugreifen, hast du je nach Art und Weise der Zugriffe schon Random Access auf die Files.
Diese "günstig" NAS Kübel fressen oftmals nur SATA Platten. Heist also keine Performanten 10/15k Platten. Alternativ wären bestenfalls noch SSDs interessant.
Dazu kommt aber die hohe Latenz über LAN bzw. SMB/CIFS beispielsweise.


Eventuell lässt sich sowas einfach mal simpel testen, wenn einer der 3-4 Clients einfach mal seine Lib via Freigabe an die anderen Clients bereit stellt und du mal die Performance austestest bei exessiver Nutzung. Je nach Ausbau der aktuell internen HDDs im jeweiligen Client könnte man davon schonmal halbwegs brauchbar ableiten, wie sich die Performance mit so nem NAS geben würde.

 

[tryharder]

... danke für euren Input ... ich hatte sowas schon fast vermutet ... das Performance-Problem ... kann mir eigentlich auch nicht vorstellen, dass so eine 700 Euro Lösung das bringen kann ... aber ...

die Idee mit dem antesten ... das probier ich aus !!!

wie würde denn eine einfache professionelle Lösung so ausehen ... wie fdsonne fileserver ? Kosten grob? ... taucht der im Netzwerk ganz normal als Computer (z.B. mein Computer / Laufwerk D ...) auf, dann kann man die Textures/Maps ja zuordnen ...

danke an Backbone und fdsonne

 

[fdsonne]

Neja, es hängt ja nicht "nur" an den Kosten für den NAS-Würfel. Essentiell wichtig sind die Platten für die Performance.
Dazu wäre es wie angesprochen gut, wenn du rausbekommst, was aktuell intern in den Clients für Platten drin stecken bzw. wie diese konfiguriert sind (Raid!?).

Shared Storage hat immer das Performanceproblem. Selbst wenn du aus vier Clients mit je einer Platte auf ein NAS mit vier Platten in Summe gehst, kann dir ein einziger Zugriff schon die Performance massiv in den Keller drücken und die anderen potentiellen Clients haben das nachsehen. -> da hilft nur Erfahrungswerte auftreiben, oder selbst austesten

PS: auch ein Fileserver für mehrere tausend Euro hat im übrigen potentiell das "Bandbreitenproblem" via GBit LAN. Und im Grunde ist so ein NAS Würfel auch nur ein Fileserver (+ paar extra Funktionen).

EDIT:
wie schaut es denn überhaupt preislich aus? Sprich was darf/kann ausgegeben werden?
Und hast du aktuell Performanceprobleme?

 

[numerobis]

Also ich weiß ja nicht, mit was für Datenmengen pro Szene Du so hantierst... Ich kann nur sagen, das ich einen alten core2duo auf nem P5W64 WS Pro als Fileserver nutze, runtergetaktet auf 2,2GHz mit zwei 7200er SATA-Platten am Onboard-RAID1 (Gbit-LAN). Mittlerweile hängen da 9 Renderclients dran (Workstation + 8 Nodes) und ich konnte bisher keine wirklichen Performanceeinbrüche feststellen (hab mal mit 3 Rechnern angefangen und mich dann langsam hochgearbeitet). Vielleicht könnte man die Übertragungsleistung noch erhöhen durch nen schnelleren Server, aber mir kam es da eher auch auf einen möglichst sparsamen Betrieb an (mit den Teilen die ich schon da hatte). Datenaufkommen pro Szene (Maxwell Render) hatte ich maximal so 2GB denk ich (Szene+Texturen etc.). Ich denke, der Flaschenhals ist hier eher das Gbit-Lan.

Vielleicht rüste ich aber demnächst mal auf nen Haswell-Dualcore auf... der C2D zieht schon noch ganz schön viel - vielleicht bringt das ja dann doch nochmal nen Schub...

 

[pajaa]

Normalerweise cacht der Renderclient die Texturen sowieso, da er damit rechnen muss, d.h. legt sie sich lokal ab. Die Storageperformance war immer vollkommen egal. Das Distributed Bucket Rendering läuft ja auch über 100MBit anständig.

 

[numerobis]

Wenn man erst cacht, dauert es länger bis zum Start. Direkt laden geht schneller bei mir.
Ich meinte auch die Übertragungsperformance, bzw. die Zeit bis zum Starten und das Zurückkopieren der MXI bei Maxwell, nicht die Renderperformance. Die ist eh nicht von der Übertragungsrate abhängig, da alles komplett in den RAM geladen wird.

 

[tryharder]

... danke für die wertvollen infos ... hatte gehofft, dass ich hier Anregungen für das weitere Vorgehen bekommen könnte und bin nicht enttäuscht worden :=)

also ich versuchs jetzt auch mal mit einem alten Rechner ... ist bei mir ja auch so, dass ich immer, wenn ich was neues kaufe den Vorgänger als Renderclient verwende

wenn das mit 3-9 Rechnern funktioniert ... Architekturvisualisierung ... dann würde das voll ausreichen ... werde jetzt mal eine dicke Szene analysieren ... Datenmenge ... Textures ... Vray-Meshes... mehr als 2 GB sollten das auch nicht sein

Das ganze muss sich ja auch irgendwie rechnen ... aber bei 3 Rechnern ist es schon nervig immer alle auf dem neuesten Stand zu halten ... gerade dann wenn man während des Jobs noch eigene Maps/Textues anlegt

Danke nochmal an ALLE !

 

[numerobis]

... aber bei 3 Rechnern ist es schon nervig immer alle auf dem neuesten Stand zu halten ... gerade dann wenn man während des Jobs noch eigene Maps/Textues anlegt

Ja eben, das ist doch eigentlich gar nicht anders machbar. Also zumindest bei mir ändert sich ständig was an der Bibliothek. Wenn das nicht zentral gespeichert würde, wär das Chaos perfekt...

 

[fdsonne]

Wie gesagt, es muss ja nichtmal ein alter PC sein. Nimm einfach irgend einen der 3-4 Clients und mach dort ne simple Freigabe auf die Lib.
Und du kannst die Performance analysieren.

Kommt dazu noch mindestens Windows Vista/2008 Server non R2 zum Einsatz, so bietet dir der Spaß auch noch den massiven Vorteil, das die Daten direkt und nahezu immer durch einen Cache geschleift werden. Klingt komisch, macht aber bei sowas viel aus. Nämlich müssen die Daten nur quasi einmal von der HDD gelesen werden, landen dann für unbestimmte Zeit im RAM des PCs. Ist genügend RAM vorhanden, könnte sogar das gesamte Material dort drin Platz finden -> nahezu keine HDD Zugriffe mehr nötig -> pfeilschneller Zugriff mit mehreren GB/sec je nach RAM und Auslastung des RAM Controllers.
Flaschenhals wäre hier in der Tat nur das GBit LAN Interface.


Wenn sogar noch ein zusätzliches Caching auf dem Renderclient selbst geht, wäre auch das ggf. ne Möglichkeit, die Performance weiter zu steigern.
Bei ~2GB Daten und anständigem Netzwerk dauert die Übertragung vllt 20-30 Sekunden. Durch die gecachten Daten im freigebenden PC kann man die HDD Performance fast schon vernachlässigen bzw. ist diese nur für den ersten Zugriff ausschlaggebend. Alle anderen Renderclients bedienen sich aus dem RAM Cache.
Geht der Job nun sagen wir mal ne Stunde, dürften diese 20-30 Sekunden Caching am Anfang nicht ins Gewicht fallen.


Also einfach mal machen und probieren, wie sich die Performance verhält, das geht schon

PS: so ein kleiner NAS Würfel kann ggf. kein RAM Caching. Je nach Art und Modell.

 

[gea]

RAM Caching der Daten ist der eigentliche Schlüssel. Damit wird in einem Szenario wo mehrere User die gleichen Daten vom Storage lesen ein erheblicher Geschwindigkeitsvorteil erzielt - auch im Vergleich zum lokalen Rechner, auch bei langsamen Platten oder einer kleineren CPU.

Prinzipiell nutzen alle neueren Systeme vermehrt Caching. In besonderem Maße gilt das für ZFS bei dem (zumindest unter Solaris) praktisch der gesamte verfügbare RAM jenseits 1GB als Datenblock-Cache genutzt wird. Ergänzen kann man das um eine Cache SSD. Damit wird das bei erneutem Lesen beliebig schnell je nach RAM.

Eine ZFS Storage appliance die per Web-UI bedient wird (FreeNAS/ Nexenta/ napp-it) wäre sicher eine ideale Losung - und bis auf Nexenta auch kommerziell kostenlos . Unix Kenntnisse sind nicht unbedingt nötig um sowas einzurichten. Die Datensicherheit ist zudem erheblich besser als lokaler Storage, dazu gibt es Snapshots (Windows vorherige Version).

Probieren kann man das mit einem alten Rechner oder als günstigste Neu-Option mit einem HP Microserver und 8 GB RAM.
Dafür (und einige SM Boards) habe ich sogar einen vorinstallierten USB Stick mit napp-it Web-UI zum Download vorbereitet (Einstecken, booten, arbeiten).

 

[numerobis]

Kommt dazu noch mindestens Windows Vista/2008 Server non R2 zum Einsatz, so bietet dir der Spaß auch noch den massiven Vorteil, das die Daten direkt und nahezu immer durch einen Cache geschleift werden. Klingt komisch, macht aber bei sowas viel aus. Nämlich müssen die Daten nur quasi einmal von der HDD gelesen werden, landen dann für unbestimmte Zeit im RAM des PCs. Ist genügend RAM vorhanden, könnte sogar das gesamte Material dort drin Platz finden -> nahezu keine HDD Zugriffe mehr nötig -> pfeilschneller Zugriff mit mehreren GB/sec je nach RAM und Auslastung des RAM Controllers.
Flaschenhals wäre hier in der Tat nur das GBit LAN Interface.

Ah, das ist interessant, war mir so nicht bewusst... also unter Win7 ist das dann auch automatisch aktiv? Dann würde sich eine Investition in etwas mehr RAM für den Server ja vielleicht doch mal lohnen... der läuft momentan mit 3GB (1 Riegel war defekt und mußte raus )

Bei ~2GB Daten und anständigem Netzwerk dauert die Übertragung vllt 20-30 Sekunden. Durch die gecachten Daten im freigebenden PC kann man die HDD Performance fast schon vernachlässigen bzw. ist diese nur für den ersten Zugriff ausschlaggebend. Alle anderen Renderclients bedienen sich aus dem RAM Cache.
Geht der Job nun sagen wir mal ne Stunde, dürften diese 20-30 Sekunden Caching am Anfang nicht ins Gewicht fallen.

Die meisten Renderjobs sind auch deutlich kleiner, je nach Texturen so im Bereich 400-600MB. das mit 1,5-2GB war echt mal ein Extremfall. Da merkt man die Ladezeiten dann natürlich schon. Aber wie Du gesagt hast, auf die Renderzeit gerechnet ist das absolut vernachlässigbar.

 

[fdsonne]

Jupp bei Win7 gibts den Cache auch...
Schau in den Taskmanager. Dort findet sich im Leistungstab der "Eintrag", wie viele Daten aktuell gecacht werden. Es lässt sich zwar nicht ohne weiteres rausbekommen, was genau da drin steht an Daten.
Aber man kann ganz simpel den Test fahren. Einfach mal eine Datenmenge von A nach B kopieren und Zeit messen. Dann das gleiche nochmal machen und wieder Zeit messen. Letzteres wird deutlich! schneller sein. Zumindest wenn der RAM nicht durch andere Sachen genutzt wird.

Extra RAM anschaffen würde ich dafür aber erstmal nicht. Mach erstmal deine Tests... Wobei RAM nie schaden kann
In meiner Workstation sich von den 16GB RAM idR so um die 8-10GB für Cache. Bei größeren Programmen auch mal was weniger...

 

[tryharder]

... also das wird ja immer besser hier ... da hab ich einiges zum antesten ... alles wird guuuut

 

[numerobis]

Aber man kann ganz simpel den Test fahren. Einfach mal eine Datenmenge von A nach B kopieren und Zeit messen. Dann das gleiche nochmal machen und wieder Zeit messen. Letzteres wird deutlich! schneller sein. Zumindest wenn der RAM nicht durch andere Sachen genutzt wird.

werd ich mal testen...

 

[tryharder]

... OK ... beim ersten Rendering muss der Server die Textures alle laden und rüber schaufeln --- 1GB =100% ... aber beim zweiten Mal (z.B. Region-Render) scheint sich der Server wirklich aus dem Cache/RAM zu bedienen ... muss ich noch weiter beobachten

bis jetzt sieht also alles gut aus !

teste jetzt mal weiter mit richtig schweren Scenes ...

 

[Morpheus2200]

Die libs werden normalerweise einmal geladen und dann im speicher gehalten, wenn davon genügend da ist.
Aber warum gleichst du die lokalen Verzeichnisse nicht einfach mit rsync an?
Dann patchst du nur noch einen rechner und ziehst beim Systemstart oder alle x stunden/tage oder auf kommando ein update vom lib verzeichnis und gut ist.
Dann hast du die daten lokal und absolut keine performance probleme was das Storage angeht.

Ein anderer Ansatz wäre ein read-only iscsi target, dass man zentral pflegt und auf allen Rechnern einhängt. Ein gutes Betriebssystem sollte die meisten lesenden zugriffe cachen können. Habe ich selbst noch nicht gemacht, würde mich aber mal interessieren wie gut das funktioniert. Ein Filesystem ohne Rechteverwaltung würde ich dabei einsetzen.
Für die paar Rechner sehe ich GBit LAN nicht gerade als performance-problem, zumindest solange man keine extrem inefizienten Protokolle einsetzt.

 

[fdsonne]

iSCSI mit NTFS unter Windows dürfte aber problematisch werden... Ggf. könnte das lesend für alle Clients funktionieren. Schreibend geht das aber meine ich nicht... Nur von einem Client aus. Da NTFs meine ich exklusiven Zugriff auf das Volume benötigt

 

[Morpheus2200]

Wenn es sich vermeiden lässt würde ich da auch kein NTFS einsetzen. Gäbe möglicherweise chaos mit den Zugriffsrechten, wenn die Rechner alle nur lokale Benutzer kennen.
Der Zugriff wäre eben read only. Read/write zugriff von mehreren clients wäre mit iSCSI ohne weiteres nicht möglich.
Reine read-only filesysteme ohne Benutzerrechte kann man halt super cachen, das macht bei parallelem Zugriff eine Menge aus. CIFS ist zwar super wenn man komplexe berechtigungen vergeben möchte, aber wenn man sich um performance sorgt ist Komplexität eher hinderlich.