Netwerk voor videobewerking

[dfr0st]

Ik loop momenteel stage bij een klein productie bedrijf waar video wordt bewerkt. Momenteel wordt er nog op externe HD's gewerkt van Lacie via firewire.
Nu hebben ze een server een server met wat TB's opslag voor de backup van projecten. Nu kwam het tersprake dat ze er naartoe willen dat je stacks vanaf de server ruimte krijgt om vanuit een netwerk share gaat videobewerken. Er ligt al een gigabit netwerk.

Omdat een netwerk met pakketjes werkt dacht ik dus dat gaat nooit goed. Omdat er niet een constant stroom van data is. Vooral als alle 6 de edit suits in bezet zijn (en stracks mischien meer).

Ik heb hiervoor een project bij de RVU gedaan en daar hadden ze fibrejet in combinatie met glasvezel voor de videobewerking.
http://www.commandsoft.com/software_fibrejet_using.jsp

Voordeel is ook zodra de mac opstart dat je "HD's" worden gemount en ze zijn net zo snel als je interne HD. En omdat ze meteen aanwezig zijn ook behoorlijk fool proof.

Probleem is dat zover ik kan zien is fibrejet alleen beschikbaar voor de MAC en niet PC en de helft van de edit suits zijn PC's.

Nu vraag ik me af zal de oplossing die ze in gedachte hadden (share's over het gigabit netwerk) voldoende zijn of moet er toch even verder gekeken worden naar een glasvezel oplossing. Desnoods fibrejet + pc vervanger app.

-edit-
andere fibre netwerkapp gevonden http://www.imagesan.com/applications.cfm

[ Voor 3% gewijzigd door dfr0st op 09-11-2006 18:07 ]

[Question Mark]

Kun je dit niet gewoon gaan testen?

Het Gbit netwerk ligt er al, en de server die de storage host draait ook al. Kun je dan niet gewoon eerst één user laten werken vanaf die fileserver en eens kijken hoe dit gaat?

[technopeuter]

Je idee dat het netwerk met pakketjes werkt en het daarom niet zou werken is onjuist. als de pakketten maar snel genoeg gaan merk je niks. (waarom werk Youtube dan??)
Ook een fibrechannel werkt met pakketering.

1Gbit is netto ca. 400Megabit dus even snel als Firewire. Je moet zeker 4 stream moeten kunnen bewerken tegelijk. ik kan je maar 1 advies geven en dat is:testen!

[JackBol]

Video gaat heel goed over IP. Misschien is het wel verstandig om QoS te gaan doen als je veel ander traffic op je netwerk hebt. Als je dat niet hebt, is het eigenlijk niet noodzakelijk.

Verder is jumboframes misschien een hulp. Doordat de frames groter zijn, is er per MB aan data minder aan TCP/IP stack activiteit.

[djluc]

Je server met glas aan een goede gigabit switch hangen zal zeker een werkbare configuratie opleveren. Er vanuit gaande dat je server deze dat snel genoeg aan kan leveren. Als je server met gigabit aan de switch hangt en je werkt met 6 mensen tegenlijk zal je snelheid nooit erg hoog worden omdat je dan alsnog 1 gigabit verbinding moet delen.

[JackBol]

djluc schreef op vrijdag 10 november 2006 @ 15:06:
Je server met glas aan een goede gigabit switch hangen zal zeker een werkbare configuratie opleveren. Er vanuit gaande dat je server deze dat snel genoeg aan kan leveren. Als je server met gigabit aan de switch hangt en je werkt met 6 mensen tegenlijk zal je snelheid nooit erg hoog worden omdat je dan alsnog 1 gigabit verbinding moet delen.

Waarom glas? Glas heeft alleen toegevoegde waarde over lange afstand. Op korte stukken heeft het zelfs het nadeel dat je een licht-naar-electisch en vv. omzetting moet doen, wat delay veroorzaakt... Gewoon GigE over Cat6 is meer aan te raden.

[Asteroid9]

Inderdaad...
Gigabit is gigabit, over glas wordt het weinig sneller.

[djluc]

Ok, dacht dat glas op dit moment een van de snelste mogelijkheden was. In elk geval dus een snellere verbinding tussen de server en de switch. Dat is het punt wat ik wil maken.

[leon1e]

Er zijn wel switches (ook al "standaard") die een 10Gbit interface standaard aan boord hebben, je zou eens kijken of je server deze performance kan leveren (wat ik betwijfel) en deze als uplink kunnen gebruiken. Zo zou je theoretisch 10 werkplekken op 1Gbit kunnen bedienen. Maar de beste manier is natuurlijk om het gewoon uit te proberen in de huidige situatie, je kunt dan heel simpel zien waar de bottleneck zit en deze oplossen in je toekomstige situatie.

[Verwijderd]

Ik denk dat je eerder problemen aan de doorvoer aan de server kant krijgt dan aan de netwerk kant. Aan de fileserver kant moet je snelle disken en voldoende aansluitpunten op de switch hebben

[TD-er]

Persoonlijk zou ik niet gaan werken vanaf de fileserver, maar vanaf de lokale schijf/schijven.
Je hebt dan namelijk vrijwel gratis een vorm van backup voor de projecten, doordat je de projecten na afloop of na elke dag wegschrijft op het netwerkstation. De lokale schijfruimte is er nu al en is ook in de toekomst vrij goedkoop.
Wanneer je project om wat voor reden dan ook corrupt raakt, kun je altijd nog terug vallen op de versie die op het netwerk staat.

Nu zal het meeste werk waarschijnlijk nog gewoon op SD-video zijn, dus relatief weinig data per sec innemen, maar als je binnen niet al te lange tijd over stapt op HD-formaten, dan zal de datastroom toenemen. Wanneer je dan nu gaat testen op je netwerk of het lekker werkt en dat dus als werkwijze doorvoert binnen het bedrijf, zal je mogelijk een vrij grote investering moeten doen als je op HD overgaat.

Nog een ander punt om niet over te gaan op een centrale server om daar actief op te gaan monteren... Je maakt dat een single point-of-failure. Als de server eruit ligt kan niemand meer werken. Met lokale schijfjes kan dat wel.

[dfr0st]

bedankt voor de reacties,

ik zal de kennis meenemen in de gesprekken

[JackBol]

TD-er schreef op maandag 13 november 2006 @ 15:15:
Nog een ander punt om niet over te gaan op een centrale server om daar actief op te gaan monteren... Je maakt dat een single point-of-failure. Als de server eruit ligt kan niemand meer werken. Met lokale schijfjes kan dat wel.

Wat is het punt met mensen die allemaal bang zijn voor SPOFs? Pas wanneer je hoge availability nastreeft en een volledig rendundant netwerk implementeert moet je je zorgen gaan maken om het opsporen van SPOFs. In een netwerkje dat door een paar mensen word gebruikt, waar veel meer zaken dan alleen de server enkelvoudig zijn uitgevoerd (netwerk infra, stroomvoorziening, locatie, management) heeft het helemaal geen zin om je druk te maken om SPOFs.

[TD-er]

Ik kan me voorstellen dat wanneer je de fileserver puur als backup gebruikt, dat je dan veel meer dingen uitsluit als SPoF.
Namelijk netwerk en ongetwijfeld dingen die ik nu even niet kan bedenken.
Wanneer je wel de server als main editing punt gebruikt, ligt alles plat als die plat ligt en ik kan me vergissen, maar het overzetten van tape naar disk etc kost dan extra tijd, dus kost het meer dan x medewerkers die niet verder kunnen gedurende de storing.
Als het niet hoeft, wat is dan het probleem om dit als SPoF aan te merken?

[CyBeR]

Dat FibreJet gebeuren is dan inderdaad wel alleen voor Mac, maar je gaat mij niet vertellen dat een dergelijke oplossing niet voor windows bestaat. FibreJet (en Apple's XSan) zijn beiden stukken SAN-software (clustering filesystems, in essentie) die hun werk doen met drives (RAID arrays) die aangesloten zijn fibrechannel. En dat hoeft overigens niet persee op glas, tenzij je meer dan een meter of zo moet overbruggen. Fibrechannel werkt op 2gbit.