Werken vanaf een netwerk met zware bestanden

[Kapotlood]

Beste Tweakers

We werken hier (grafisch ontwerpbureau) op ‘t moment allemaal (±15 man) lokaal in een Mac-only netwerk. Maar omdat we steeds vaker bestanden uitwisselen en de boel een beetje makkelijker willen maken, willen we graag op ‘t netwerk werken. Nu zitten er hier voornamelijk MacBook Pro’s en iMacs, met 2 Mac Mini’s als bestands- en backupserver, waarvan de backupserver verbonden is met een Promise Pegasus Raid.

Ik kan me nog herinneren dat ik bij m’n vorige werk op een netwerk werkte, waarbij:
– Je altijd inlogt op een netwerk account
– Er een bestandsserver was waar alle bestanden ten alle tijde op stonden
– Je dus ook áltijd direct vanaf het netwerk werkte
– En er dus nooit iets lokaal staat, en je dus ook nooit bestanden hoeft uit te wisselen.

Maar dat was vroeger, met een xServe. Die dingen verkopen ze niet meer, dus vandaar de vraag of en hoe dit nu de dag werkt. Is dit ook te doen met een enkel Gigabit netwerk?

Ik ben benieuwd naar jullie ervaringen en oplossingen!

[z1rconium]

Dit heet netwerk-design, wat een vak op zich is.
Het ligt er aan hoe groot het is en hoe scalable je het wilt hebben.

Als er een paar mensen tegelijk werken dan kom je wel weg met een gigabit switch(es), als het groter word dan zul je andere paden moeten gaan volgen met access en distribution layers/switches.

Hoe groot zijn de bestanden en hoeveel denk je dat er nodig is qua bandbreedte ? En hoe word er op dit moment gewerkt ?

[Paul]

Hoe hebben jullie het versiebeheer op de grafische ontwerpen geregeld? En wat beveelt jullie systeembeheerder aan?

Met versiebeheer-software kun je vaak al regelen dat je lokaal werkt in het "huidige" bestand en als je commit wordt het pas naar het netwerk geschreven, wat de belasting op je fileserver een stuk lager maakt. Mits je fileserver voldoende snel is (want anders wordt dat de bottleneck) is gigabit voldoende. Grafische ontwerpen kunnen flink groot worden (RAW foto's, PSD's, laten we het nog maar niet hebben over video) maar vaak wordt het pas in de laatste fase opgeknipt in alle kleine bestandjes voor in de webpagina (als dat het doel van het ontwerp is). Een beetje NAS haalt makkelijk (minimaal) 50 MB/sec, dus bij het uitchecken van een bestand zit je misschien even te wachten tot het bestand lokaal is gezet maar daarna heb je geen "last" meer van het netwerk totdat je commit.

Het design hiervan kun je mijns inziens echter beter uitbesteden dan dat je het op een forum vraagt, als het mis gaat (omdat wij niet de juiste vragen stellen of het antwoord verkeerd interpreteren) dan heeft het hele bedrijf er last van, terwijl zo'n gespecialiseerd bedrijf er echt de tijd voor neemt, metingen komt doen etc.

[it0]

z1rconium schreef op maandag 21 december 2015 @ 10:58:
Dit heet netwerk-design, wat een vak op zich is.

Inderdaad, naast gigabit netwerk, is het meest belangrijke het aantal IOPS dat er per gebruiker plaatsvindt.

Als je dat in kaart brengt, grootte van bestanden + IOPS, dan zie je veel beter wat de behoeften zijn.

Een goede switch is ook belangrijk, zorg dat hij niet teveel is oversubscribed, dus dat hij ook meerdere gigabit connecties sustained kan doen.

Mijn voorstel zou zijn om zelf een server te bouwen met een grote SSD als caching om de IOPS op te vangen. De server zelf via channel bonding met 2+ NICS aan het netwerk hangen.

[Kapotlood]

@z1iconium:
Bedankt alvast! Hier de antwoorden op je vragen:
- Het netwerk is in ieder geval voor de 10 ontwerpers/DTP'ers, met een uitgroei naar 13 inclusief (tijdelijke) freelancers
- De bestanden variëren van 1MB tot 500MB, gemiddeld genomen.

Op dit moment werken we allemaal lokaal, en daar blijft het over het algemeen ook staan totdat ik mensen er aan herinner dat afgeronde projecten geärchiveerd moeten worden. Kortom: er wordt niet echt goed gewerkt.

@Paul:
Versiebeheer hebben we niet, en dat werkt ook bijzonder vervelend met de hoeveelheid bestanden waar we wekelijks aan werken (heb het vroeger wel eens gezien via Adobe, wat geen pretje was). Onze systeembeheerder geeft aan dat werken op 't netwerk niet mogelijk is... wat ik aan de ene kant begrijp, maar aan de andere kant, bij m'n vorige werk hadden we een dual-Gigabit netwerk, en daar zat echt iedereen 100% op 't netwerk te werken, zonder enige vertraging. Zelfs over-the-air systeemupdates van de systeembeheerder daar werkten niet vertragend.

Ik wilde hier de vraag eigenlijk stellen om een beetje een idee te hebben waar ik (mogelijk) rekening mee moet gaan houden, en om eventuele ideeën met de systeembeheerder te kunnen overleggen.

@it0:
Qua hardware komen we er hier wel uit. Het is een Mac-only netwerk, dus zelf een server bouwen zal niet echt een optie zijn. Misschien dat het technisch wel mogelijk is, maar we willen het Mac-only houden omdat het qua onderhoud, beheer en gebruik voor ons (en onze systeembeheerder) de voorkeur heeft.

Op 't moment hebben we 2 Mac Mini's (1x fileserver, 1x backupserver). De fileserver heeft een SSD, 16GB ram. De backupserver heeft een HD, 16GB ram, en is verbonden met een Pegasus Raid. Het netwerk is nu verdeeld via een 24-poorts switch (TP-Link TL-SG1048). Mócht 't mogelijk zijn, dan willen we 't wel met deze 2 Mac Mini's blijven doen.

[Paul]

joramoudenaarde schreef op maandag 21 december 2015 @ 11:28:
Versiebeheer hebben we niet, en dat werkt ook bijzonder vervelend met de hoeveelheid bestanden waar we wekelijks aan werken (heb het vroeger wel eens gezien via Adobe, wat geen pretje was).

Hoe voorkom je dan dat 2 ontwerpers aan hetzelfde bestand bezig zijn? Hoe ga je terug naar een vorige versie als je iets fout hebt gedaan of de klant het nieuwe design niet accordeert?

Waarschijnlijk doe je daar nu ook 'iets' voor, al was het maar bestandjes kopiëren en de mapnaam hernoemen of zo. Dat is ook versiebeheer. Het klinkt vooral alsof het systeem dat je vroeger gezien hebt gewoon geen goed systeem was Met een goed systeem is het zo simpel als in een centrale repository zeggen "Ik ga nu hier aan werken" waarna het systeem zegt: "Alstublieft" (of "Nee, Klaasje is daar al in aan het werk"), en als je klaar bent zeg je "Zo, klaar..." waarna het systeem ervoor zorgt dat de nieuwe bestanden correct worden opgeborgen.

Ik heb totaal geen ervaring met het systeem, ik pleur gewoon even wat zoektermen in Google, maar kijk eens naar https://www.pixelapse.com/ ? Dat is een online dienst dus waarschijnlijk niet bruikbaar, maar zo simpel kan het dus zijn

Ik weet niet welke versie van Adobe Cue je gebruikt hebt, als ik daar even op Google dan lijkt het ook vrij simpel. In plaats van "File -> Open" in Photoshop gebruik je "Tools -> Version Cue ->" en in plaats van "File -> Save" gebruik je "File -> Check in..."

[z1rconium]

Je loopt snel tegen de limieten aan, de macmini heeft een SSD, laten we zeggen dat deze 300MB/s kan verplaatsen, maar dat moet dus over de 1Gbit NIC (= theoretisch 125MB/s max), daar heb je 1 bottleneck al te pakken.

Stel dat er 3 mensen tegelijk naar die server gaan om een bestand op te halen, dan moet dat allemaal over 1 kabel die naar de macmini gaat, dan zit er iemand te wachten ergens in het pad.

Dit maakt het niet flexibel/robuust.

Een server met een dual NIC en channel-bonding voorkomt zo'n verstopping en frustratie.
Het is mogelijk met wat je al hebt, maar echt vrolijk zal niemand er van worden.

[Kapotlood]

Paul schreef op maandag 21 december 2015 @ 12:48:
[...]
Hoe voorkom je dan dat 2 ontwerpers aan hetzelfde bestand bezig zijn? Hoe ga je terug naar een vorige versie als je iets fout hebt gedaan of de klant het nieuwe design niet accordeert?

Door dus vanaf de server te werken, werk je altijd aan het laatst bewerkte bestand. En als ontwerper werk je sowieso in versies door "oude" concepten ergens apart neer te zetten. Op die manier doen we inderdaad aan versiebeheer. Maar wel "zelf", en niet via een programma.

@z1rconium:
Bedoel je met "dual NIC", 2 Gigabit aansluitingen?
Een Mac Mini heeft inderdaad maar 1 Gigabiet aansluiting, maar via USB3 of Thunderbolt kun je ook een adapter kopen, waardoor je alsnog 2 Gigabit aansluitingen hebt. Zoals deze van Apple. Dan heb je een theoretische maximum snelheid van ±250MB/s, wat dan hetzelfde zou zijn als op m'n vorige werk (waar we een Mac Pro met dual-Gigabit netwerk hadden waarop iedereen tegelijkertijd werkte).

Ik zou het dan wel zo in willen delen dat alle Projectmanagers een eigen server hebben (met een fysieke eigen HD/SSD), en alle ontwerpers ook (inclusief eigen HD/SSD). De Projectmanagers zullen niet echt veel vragen van het netwerk met hun Wordbestandjes en PDF's, maar de ontwerpers wel. En zo houdt je het dan ook netjes gescheiden.

[Quakie]

Ik begrijp dat je het graag mac only wilt houden maar ergens hoeft dat niet helemaal.

Nergens in je verhaal komt lokale opslag problemen voor, dus ik ga er vanuit dat die er niet zijn.
Als die er niet zijn, waarom overweeg je niet een NAS? Die dingen zijn juist hiervoor gebouwd.
Ze doen prima aan syncen.. dus iedereen werkt lokaal en synct wijzigingen met je NAS die het vervolgens weer zorgt dat het bij iedereen terugkomt.. Op de achtergrond worden versies bijgehouden..
Desnoods sync je nas weer met een andere nas als je load wilt beperken... waarschijnlijk kan je ook je minis dan specifieke taken geven... Je speelt voor je eigen cloud dus..

[Kapotlood]

Ah, nu je dat zo zegt zie ik dat ik niet alle informatie heb gegeven zoals het nu bij ons werkt

Even een kleine correctie van mijn kant! Dit is zoals het nu bij ons werkt

• Iedereen werkt nu lokaal, en slaat deze bestanden ook altijd lokaal op.
• Elke 2 uur wordt er een sync gedaan door Retrospect, die élk account van elke computer, synchroniseert met de backupserver. In geval van nood (bij een kapotte computer bijvoorbeeld), kan dus het hele account zo terug gezet worden met de laatste bestanden.
• Als een DTP'er of ontwerper, een project van een collega over neemt, worden deze bestanden verzamelt en overgezet via een aparte transport server. Deze serverschijf wordt niet gebackupt, omdat het een rommelmap is.
• We hebben een archiefserver waar ik alle afgeronde projecten op zet. Deze archiefserver, tesamen met het backup-deel van alle accounts, staat op een Promise Pegasus Raid.
• [i]We hebben 2 losse backup schijven die we dagelijks wisselen, die een extra backup maken van de fileserver.[/i]
• Het probleem wat we hebben is tweeledig: enerzijds bij het overdragen waarbij je als je niet op let, 2 dezelfde projecten op 2 computers hebt staan. Anderzijds het feit dát je moet overdragen

Juist omdat we al een Mac Mini als backupserver hebben, die aangesloten is op een Promise Pegasus RAID, en een Mac Mini als fileserver, én een 48-poorts Gigabit switch, zou ik 't zonde vinden om óók nog eens een NAS aan te schaffen. We hebben al zo'n berg met schijven en een OSX Server, dat zo'n NAS voor ons niet de voorkeur heeft. Wat zo'n NAS doet, kan OSX Server ook namelijk. Voor ons is het puur dat we willen weten (of beter, dat ik het wil weten) of we via de Mac Mini (i.c.m. een dubbele Gigabit aansluiting), goed en snel met dergelijke bestanden via het netwerk kunnen werken

[z1rconium]

Ik vraag me dan toch af wat die "fileserver" op dit moment voor functie uitvoert ? Men kan toch die files direct van de fileserver openen en er mee werken/opslaan ?

[Paul]

joramoudenaarde schreef op maandag 21 december 2015 @ 13:36:
Het probleem wat we hebben is tweeledig: enerzijds bij het overdragen waarbij je als je niet op let, 2 dezelfde projecten op 2 computers hebt staan. Anderzijds het feit dát je moet overdragen

Dat zijn beide zaken die een goed versiebeheer voor je oplossen Maar ik zal ophouden daarover.

Welke switch heb je? ALs deze LACP ondersteunt kun je een Thunderbolt- of USB3 gigabit netwerkadapter open en twee netwerkkaarten combineren, dan heb je 2x 1 gigabit (één gebruiker heeft maximaal 1 gbit, maar zodra het er meer zijn wordt het netjes verdeeld, al speelt de wet der grote getalen hier ook mee, met 3 gebruikers kan het alsnog zo zijn dat de twee grootverbruikers over hetzelfde touwtje gaan).

De SSD trekt het verder wel. Het zal wel wat langzamer zijn dan lokaal werken, ik weet ook niet hoe vaak de programma's die je gebruikt het origineel aanspreken ipv een scratchpad of zo maar het is ook weer niet zo dat zo'n programma in een loopje de hele tijd dat bestand van voor tot achter aan het lezen is.

Ik weet dat bijvoorbeeld Lightroom het niet pikt als je je catalog op een netwerkshare hebt staan en je zult moeten testen wat er gebeurt als Jantje en Pietje beiden tegelijk project X openen. Je kunt sowieso beginnen met één netwerkadapter voordat je er een tweede bij aanschaft.

Al met al verwacht ik dat het op zich wel gaat werken (quirks als zo'n catalog dan mogelijk uitgesloten) maar dat je het beter gewoon kunt testen Maak een share, zet er een project op en ga er mee werken Als dat goed werkt vraag je een collega om ook een project op de Mini te zetten en er mee te gaan werken net als jij, en zo schaal je op. Op die manier kun je het mijns inziens met minimale impact bekijken / implementeren.

[maratropa]

Ik ken ze ook die gewoon alles in dropbox hebben zitten (en lokaal netwerk sync aan hebben staan in dropbox.) Je upload is dan wel soms een issue, maar ik ken meerdere kleine bedrijfjes die het zo doen en daardoor 0 netwerk gedoe hebben..

[Kapotlood]

@z1rconium:
De fileserver bevat nu: projectserver, transportserver en presentatieserver (waar we de PDF's bewaren van gehouden presentaties).
De backupserver bevat: backups van de accounts en het archief. Deze worden op de Promise Pegasus Raid gezet door de backupserver.

@Paul:
Versiebeheer zorgt ervoor dat je nooit de verkeerde bestanden pakt, en als er iets fout is gegaan, dat je altijd terug kan naar een vorig bestand. Het lost, zolang we lokaal werken, niet het probleem op dat mensen hun bestanden niet goed overdragen, of het probleem van de dubbele bestanden op. Misschien dat als we direct via het netwerk werken, echt versiebeheer naderhand ook wel een wens gaat worden. Maar vooralsnog willen we ons meer focussen op hoe we het werken op 't netwerk het best kunnen realiseren... liefst met zoveel mogelijk van de hardware die we al hebben: 2x Mac Mini, 48-poorts switch van TP-Link (TL-SG1048) en Pegasus Raid.

@maratropa:
Ik heb inderdaad ook wel eens gehoord van mensen dat ze zo werken. Maar die Dropbox-"servers" zijn gewoon van Amazon Cloud: schijven die fysiek in Amerika staan. Buiten dat ik niet zo happig ben op het stallen van bedrijfsdata op schijven in Amerika, ben je met de cloud wel érg afhankelijk van internet. Met een eigen bestandsserver (al dan niet via 't netwerk werkend) ben je minder afhankelijk van invloeden van buitenaf

[koentjuh1987]

misschien dat tortoise svn iets voor jullie is. Ergens op een server al je bestanden zetten en bij wijzigingen committent en op de server zetten. Heb je ook gelijk je versiebeheer geregeld. En kun je verder lokaal werken (na en update elke dag van die map).

Of zijn het dermate grote bestanden dat je hier niet lokaal mee zou kunnen werken?

[MrMonkE]

Ja, check jij even een 40Gb PSD in na wijzigingen.
SVN 3 dagen bezig de changes te vinden

[The Eagle]

Je kunt nog zoveel dingen bedenken, maar uiteindelijk kost een snel netwerk geld, en niet zo weinig ook.
Aangezien jullie 10 man in dienst hebben (freelancers tel ik bewust niet mee, hun data is hun probleem imho) verwacht ik niet dat jullie een vaste systeembeheerder hebben. En als je dan investeringen over 10 man moet verdelen, praat je al gauw over forse bedragen. Terwijl het hudige gewoon werkt en relatief niks kost, zij het niet dat het niet 100% efficient is, wat meer risico's heeft, en zeker beter kan
Kortom: je kunt best een verbetervoorstel doen, maar uiteindelijk kost het je baas geld en ik verwacht dat ie zo weinig mogelijk zal willen veranderen. Als systeembeheer al zegt dat het met het huidige netwerk net mogelijk is, wie ben jij dan om daar aan te twijfelen?
Pas als je baas het te erg vind worden heb je een businesscase. Want met 10 man moet je wel verdomd veel winst weten te behalen uit je investering willen de baten opwegen tegen de kosten

[Xudonax]

Wat ik enige tijd geleden op verzoek van een vriend gebouwd heb is een ZFS NAS waar ze alle bestanden op hebben, en deze kopieëren ze dan naar hun lokale Mac Pro om de dingen te bewerken. Zodra ze klaar zijn gaat het weer terug omdat die dingen niet genoeg opslag hebben om meer dan ~5 projecten tegelijk te draaien. Als je zoiets zou combineren met OwnCloud dan heb je de synchronisatie ook gedaan lijkt me. Niet iets dat extern ondersteund zal worden, maar als jullie twee man hebben die dit denken te kunnen onderhouden kun je al een eind komen. Zeker als je daarnaast een CrashPlan oid hebt lopen welke iedere nacht een backup naar een NAS bij iemand thuis stuurt zodat jullie ook een ramp kunnen overleven.

Ik geloof dat die bak (hey, het is ~2 jaar geleden) 3x 4TB schijven had, caching SSDs voor als er iets echt over het netwerk geopend moest worden en 32GB aan RAM. Ja, het is zwaar overkill voor hun, maar zij zitten momenteel dan ook met slechts 4 man. Met 10 man zou zoiets al een stuk meer gebruikt worden denk ik. Maar dit is vooral het NAS gedeelte, en niet zo zeer het stuk netwerk.

Een andere, dure, oplossing is om alle Mac's te voorzien van Fibre Channel en vervolgens XSan uit te rollen. Dan heb je één centrale server waarop iedereen werkt, en voor je Mac en alle applicaties is het een lokale schijf. Maar Fibre Channel is niet goedkoop zodra je switches in gaat zetten. Theoretisch werkt dit trouwens ook over iSCSI, maar dit is niet supported AFAIK.

[Kapotlood]

@The Eagle:
Wat we nu doen werkt op zich wel, maar er gaat "te vaak" iets mis. Bestanden die niet goed verzameld worden, niet goed overgedragen worden, of die ergens dubbel eindigen op meerdere computers. Dat is, zeker gezien de hoeveelheid werk die we doen, vragen om problemen waar de klant én wijzelf niet blij van zouden worden.

We werken met 15 man in 't bedrijf, maar 10 man daarvan werken daadwerkelijk met zware bestanden. Vandaar dat ik 't over 10 man had... excuses als ik daar niet duidelijk in was Maar we hebben wel degelijk een systeembeheerder. Ik heb zelf een (klein) handje gehad in hoe onze huidige opstelling is, d.w.z. 2 Mac Mini's, een Pegasus Raid e.d. Maar hij beheert en doet verder advies over updates etc. Ik weet wel wát, maar lang niet zoveel als hijzelf.

Ik heb ondertussen ook weer wat meer informatie opgedaan, en kwam er achter dat een Mac Mini ook voorzien kan worden van dual Gigabit netwerk, met behulp van een Thunderbolt-naar-Ethernet adapter. Deze kun je dan linken/koppelen met de interne Ethernet aansluiting, en zo een dual Gigabit netwerk creëren. In feite hebben we dan hetzelfde als wat ik op m'n vorige werk had qua netwerksnelheid. En daar werkten we alle 15 op 't netwerk, en ook met updates "over the air" van onze systeembeheerder werkte dat eigenlijk perfect.

[SquareOne]

joramoudenaarde schreef op maandag 21 december 2015 @ 11:28:
@z1iconium:
Bedankt alvast! Hier de antwoorden op je vragen:
- Het netwerk is in ieder geval voor de 10 ontwerpers/DTP'ers, met een uitgroei naar 13 inclusief (tijdelijke) freelancers
- De bestanden variëren van 1MB tot 500MB, gemiddeld genomen.

Op dit moment werken we allemaal lokaal, en daar blijft het over het algemeen ook staan totdat ik mensen er aan herinner dat afgeronde projecten geärchiveerd moeten worden. Kortom: er wordt niet echt goed gewerkt.

@Paul:
Versiebeheer hebben we niet, en dat werkt ook bijzonder vervelend met de hoeveelheid bestanden waar we wekelijks aan werken (heb het vroeger wel eens gezien via Adobe, wat geen pretje was). Onze systeembeheerder geeft aan dat werken op 't netwerk niet mogelijk is... wat ik aan de ene kant begrijp, maar aan de andere kant, bij m'n vorige werk hadden we een dual-Gigabit netwerk, en daar zat echt iedereen 100% op 't netwerk te werken, zonder enige vertraging. Zelfs over-the-air systeemupdates van de systeembeheerder daar werkten niet vertragend.

Ik wilde hier de vraag eigenlijk stellen om een beetje een idee te hebben waar ik (mogelijk) rekening mee moet gaan houden, en om eventuele ideeën met de systeembeheerder te kunnen overleggen.

@it0:
Qua hardware komen we er hier wel uit. Het is een Mac-only netwerk, dus zelf een server bouwen zal niet echt een optie zijn. Misschien dat het technisch wel mogelijk is, maar we willen het Mac-only houden omdat het qua onderhoud, beheer en gebruik voor ons (en onze systeembeheerder) de voorkeur heeft.

Op 't moment hebben we 2 Mac Mini's (1x fileserver, 1x backupserver). De fileserver heeft een SSD, 16GB ram. De backupserver heeft een HD, 16GB ram, en is verbonden met een Pegasus Raid. Het netwerk is nu verdeeld via een 24-poorts switch (TP-Link TL-SG1048). Mócht 't mogelijk zijn, dan willen we 't wel met deze 2 Mac Mini's blijven doen.

Zelf doe ik ook systeembeheer van een Mac Only netwerk. Ik ga volgende week overstappen van een Mac Mini server naar Synology. De server software van Apple wordt met het jaar minder en ik heb ook niet de indruk dat ze daar in de toekomst nog veel aandacht aan willen besteden. Resultaat is dat je alsnog allerlei third party software op de Mac Mini's gaat installeren, dan kun je denk ik net zo goed naar andere server oplossingen kijken. Verder heb ik gemerkt dat er vaak toch dingen fout gaat met rechten naar de server en dergelijke wat weer veel tijd kost om te herstellen.

[Paul]

joramoudenaarde schreef op maandag 21 december 2015 @ 14:21:
@Paul:
Versiebeheer zorgt ervoor dat je nooit de verkeerde bestanden pakt, en als er iets fout is gegaan, dat je altijd terug kan naar een vorig bestand.

Dat is maar de helft van wat het doet

Het lost, zolang we lokaal werken, niet het probleem op dat mensen hun bestanden niet goed overdragen, of het probleem van de dubbele bestanden op.

...want dat lost het ook op Bij een check out haal je het lokaal en zet je een vlag op het netwerk dat je er mee bezig bent. Hiermee voorkom je dat er (onbewust, je kunt het wel forceren) dubbele bestanden, en zodra je het commit (wat ongeveer net zoveel werk is als saven) is het overgedragen

In plaats van Dropbox kun je ook Owncloud gebruiken, dat doet hetzelfde maar dan met een fileserver van jezelf. Dan staat je data niet in de USA, het hoeft niet over je internetlijn en als het internet down is kun je nog steeds werken.

[Kapotlood]

@SquareOne:
Je gaat hélemaal over van OSX Server naar Synology? Mag ik je dan vragen hoe je:

• de backup regelt (wat voorheen, gok ik, met Retrospect geregeld wordt)
• de snelheid regelt van datatransfer? Synology's professionele NAS'en zijn snel, maar bieden die ook de instel-mogelijkheden zoals OSX dat doet?

En werk je dan ook volledig vanaf het netwerk, of toch lokaal?

@Paul:
Owncloud "ken" ik... vind het een ontzettend mooi open source project, maar ik kon uiteindelijk niet echt een reden verzinnen waarvoor het voor ons ook écht de voorkeur zou krijgen. Ownloud werkt ook met Synology... ik moet er toch eens induiken denk ik!

[SquareOne]

joramoudenaarde schreef op dinsdag 22 december 2015 @ 11:03:
@SquareOne:
Je gaat hélemaal over van OSX Server naar Synology? Mag ik je dan vragen hoe je:

• de backup regelt (wat voorheen, gok ik, met Retrospect geregeld wordt)
• de snelheid regelt van datatransfer? Synology's professionele NAS'en zijn snel, maar bieden die ook de instel-mogelijkheden zoals OSX dat doet?

En werk je dan ook volledig vanaf het netwerk, of toch lokaal?

Allereerst even een kanttekening. Ik heb het over een klein kantoor aan huis. 3 iMacs, 3 MacBooks.

Backup van alle clients was voorheen geregeld via de time-machine functie in OS X Server (naar externe schijf aan de Mac Mini). Van de server zelf werd 1) een time-machine back-up gemaakt op een andere externe schijf, 2) via crashplan gebackupt naar een externe locatie. Met de Synology ga ik 1 schijf in de Synology gebruiken voor enkel time-machine back-ups van de clients. De andere schijf komt alle data op de staan. Op een externe schijf aan de Synology wil ik vervolgens back-ups maken van de dataschijf met versiebeheer (of intern op een andere schijf als het een 4-bay Synology wordt). Extern wil ik vervolgens nog een simpele synology neerzetten die ook de dataschijf back-upt.

Verder werd eigenlijk alleen de filesharing functie gebruikt van de Mac Mini. De clients maken verbinding via AFP. Nu vond ik dat geregeld onbetrouwbaar en af en toe traag.

De Synology heeft twee Gigabit netwerkpoorten, beide worden aangesloten op een gigabit switch die vervolgens weer verbonden zijn met de clients (de Macbooks meestal draadloos). Naar mijn idee zijn de instel-mogelijkheden van een Synology vele malen groter dan die van OS X Server. Ik vond het de laatste tijd maar beperkt worden.

[Kapotlood]

Ooow, dat dempt de verwachting een beetje

Time Machine backups zijn ontzéttende "data hogs", vergeleken met de incrementele backups en archiveringen die o.a. Retrospect kunnen doen. We hebben hier niet eens bijzonder veel data dénk ik, maar toch al zeker genoeg voor ongeveer 7-8TB, waarvan de dagelijks heen-en-weer gestuurde data rond de 5-20GB hangt.

Ik denk dat Synology op sommige vlakken zeker een hoop biedt vergeleken met OSX Server. Ik heb thuis ook een Synology en zou niet anders meer willen. Maar netwerkaccounts e.d., dat is niet iets wat Synology kan delegeren. Daar heb je echt een OSX Server voor nodig. Ik denk dat wat wij doen qua archivering, backups en (OSX) accountbeheer, dat we voldoende hebben aan OSX Server.

Maar jammer dat OSX Server steeds meer een consumenten-dingetje lijkt te worden is het zeker.

[SquareOne]

joramoudenaarde schreef op dinsdag 22 december 2015 @ 19:47:
Ooow, dat dempt de verwachting een beetje

Time Machine backups zijn ontzéttende "data hogs", vergeleken met de incrementele backups en archiveringen die o.a. Retrospect kunnen doen. We hebben hier niet eens bijzonder veel data dénk ik, maar toch al zeker genoeg voor ongeveer 7-8TB, waarvan de dagelijks heen-en-weer gestuurde data rond de 5-20GB hangt.

Ik denk dat Synology op sommige vlakken zeker een hoop biedt vergeleken met OSX Server. Ik heb thuis ook een Synology en zou niet anders meer willen. Maar netwerkaccounts e.d., dat is niet iets wat Synology kan delegeren. Daar heb je echt een OSX Server voor nodig. Ik denk dat wat wij doen qua archivering, backups en (OSX) accountbeheer, dat we voldoende hebben aan OSX Server.

Maar jammer dat OSX Server steeds meer een consumenten-dingetje lijkt te worden is het zeker.

Time Machine valt wel mee toch? Zijn ook incremental backups. De eerste keer een volledige back-up kost wat tijd en betreft veel data maar daarna zijn het alleen de wijzigingen die worden gebackupt.

Wat bedoel je met het delegeren van netwerkaccounts ? Jullie werken lokaal toch en loggen niet in op accounts op de server toch?

[xelnaha]

Ik heb zelf eenzelfde setup als Xudonax gebouwd,

centrale NAS met zfs, waar alle bestanden op staan met caching SSD voor de niet lineare bestanden. Als backup wordt er ieder uur een snapshot gemaakt van de file systems en als backup worden deze weg gestuurd via rsync (of zfs sync als je dat wilt).

voor offsite backup gebruik ik crashplan, wat mij tot nu toe al heel erg veel hart verzakkingen heeft gescheeld (zowel zakelijk maar voornamelijk prive).

Als je al een 48port Gbit switch hebt, zul je genoeg backbone capaciteit hebben op die switch. Wat andere mensen ook al aangeven, wellicht is een mac mini niet bepaald de juiste keuze voor een file server, maar kun je beter of een NAS van bv synology nemen, of een server kopen die voorzien kan worden van de jusite software (denk linux etc).

uiteraard is het probleem ook dat iemand het moet gaan onderhouden, en dat kost ook weer geld.

[Kapotlood]

Ik heb zojuist even met onze systeembeheerder om de tafel gezeten, en daar kwam het volgende uit:
- 1 Mac Mini + Promise Pegasus als fileserver
- 1 Qnap NAS die als backup geldt voor de Promise Pegasus
- Externe schijven voor de dagelijkse backup, als extra backup in het geval van ongevallen e.d.

Voordelen:
- Alle afgeronde projecten die ontwerpers nu "her-en-der" laten slingeren, staan dan centraal opgeslagen. Je raakt bestanden niet meer zomaar kwijt.
- Als een ontwerper niet aanwezig is en z'n laptop bij zich heeft, zijn bestanden ook direct voor anderen beschikbaar.

Nadelen:
- mensen moeten omschakelen en "verprofessionaliseren". Dus het moet niet meer zo zijn dat iedereen lekker volgens z'n eigen manier blijft werken, maar dat we allemaal op grofweg dezelfde manier gaan werken. Dat vereist wat discipline, maar dat mag ook verwacht worden als je met meerder mensen samen werkt aan dezelfde producten/bestanden.
- Er kán inderdaad wat per ongeluk weggegooid worden, waardoor je dan direct(er) afhankelijk bent van de backups.

@xelhana:
Er zal inderdaad een "aangewezen persoon" moeten komen die er zorg voor draagt dat alles netjes bijgehouden wordt. Enerzijds zal onze systeembeheerder wat makkelijker werk hebben omdat laptops minder vol staan, alle data meer georganiseerd op de backup en server staat. Anderzijds zullen de ontwerpers en werktekenaars echt moeten opletten dat ze gewoon fatsoenlijk werken. Je kan dan wel, in tegenstelling tot zoals het nu gaat, veel duidelijker zien wíé er een zooitje van maakt en deze mensen daar ook directer op aan spreken.

Maar het "probleem" dat iemand dit moet gaan onderhouden valt op zich wel mee. Het is nu meer een warboel vergeleken met het op de server werken En we splitsen de boel dan zo op dat niemand behalve de werktekenaars bij de werkteken-bestanden kan komen. De rest heeft hooguit lees-rechten. Dat voorkomt problemen dat de meest belangrijke bestanden per ongeluk weggegooid kunnen worden.

@SquareOne:
Het delegeren van netwerkaccounts is iets wat waarschijnlijk dan ook gaat gebeuren, om te voorkomen dat ontwerpers tóch stiekem telkens weer offline gaan werken. Beetje bot gezegd, ontwerpers zijn meestal niet de meest opgeruimde of georganiseerde werkers

Ik heb thuis een poosje TimeMachine backups gedraaid, en draai nu Chronosync, en dat scheelt veel data terwijl ik daar netjes incrementele backups mee maak. TimeMachine maakt ze veel te vaak en heeft te weinig instel-opties naar mijn smaak.

[SquareOne]

joramoudenaarde schreef op woensdag 23 december 2015 @ 14:17:

@SquareOne:
Het delegeren van netwerkaccounts is iets wat waarschijnlijk dan ook gaat gebeuren, om te voorkomen dat ontwerpers tóch stiekem telkens weer offline gaan werken. Beetje bot gezegd, ontwerpers zijn meestal niet de meest opgeruimde of georganiseerde werkers

Ik heb thuis een poosje TimeMachine backups gedraaid, en draai nu Chronosync, en dat scheelt veel data terwijl ik daar netjes incrementele backups mee maak. TimeMachine maakt ze veel te vaak en heeft te weinig instel-opties naar mijn smaak.

Dat zou inderdaad kunnen. Ik zou wel even aan het testen gaan met netwerkaccounts, ik heb dat wel eens geprobeerd maar vond daarvan de snelheid tegen vallen.

[Kapotlood]

Oh, we gaan (toch maar wel) zeker even testen! Onze systeembeheerder was ook (positief) verbaasd dat we iemand vonden via Google die grofweg dezelfde setup had qua netwerk (Mac Mini, Pegasus Raid e.d.), en die daar de interne ethernet aansluiting had gecombineerd met een Thunderbolt-naar-ethernet adapter, om zo een dual-Gigabit netwerk te maken. Ik ben benieuwd in ieder geval! Het is naast een stukje "verprofessionalisering" ook een leuk project om mee bezig te zijn

[supersnathan94]

Netwerk accounts als in LDAP gok ik?
@SquareOne. Dit houd in dat iedere gebruiker ongeacht welke computer kan inloggen op zijn account binnen het domein. Hetzelfde idee als scholen gebruiken bijvoorbeeld.

Momenteel ben ik dit ook aan het opzetten en ik moet zeggen dat het behoorlijk makkelijk werkt. Iedereen kan lekker werken op zn eigen mac, maar alle gegevens staan op de server en worden automatisch heen en weer gesynced. Dit zorgt er ook voor dat je geen bsckups van de clients hoeft te maken (er wordt immers niets lokaal opgeslagen als er geen externe schijven worden gebruikte) en met apple remote desktop kan je zo je software uitrollen via scripts (auto install dus kost ook nul tijd om door venstertjes heen te klikken). Feitelijk gezien ben ik dus hetzelfde scenario aan het uitwerken als jullie, inclusief databeheer en syncing. Ik denk dat de makkelijkste manier om goed met projecten te kunnen werken alleen wel een vorm van versiebeheer nodig gaat hebben als je met meerdere mensen aan 1 project gaat werken. De shares die ik ga gebruiken zijn namelijk read only (films, muziek en fotos) en kunnen maar door 1 gebruiker gewijzigd worden (en door admin). Backups gaan verzorgd worden door een firewire 800 enclosure met raid 1. Usb 2.0 is toch een stuk trager.

Wat ook zou kunnen (om te voorkomen dat bestanden door meerder mensen worden geopend op hetzelfde moment) is kijken of er een manier te verzinnen is waarbij mapnamen worden aangepast handmatig als je aan een project gaat werken.

[Tsurany]

Hebben jullie al serieus naar een SVN oplossing gekeken? Wordt vaak bij software ontwikkeling gebruikt maar ik zou niet weten waarom dat hier ook niet zou kunnen werken. Dan staat al je data op een server opgeslagen en check je bestanden uit (downloaden naar je eigen pc) om er verder aan te werken. Elke keer als je klaar bent commit je de nieuwe bestanden naar de server toe.

Je hebt dan direct versiebeheer aangezien elke commit apart opgeslagen wordt en je kan directories locken om aan te geven dat je er mee bezig bent. Je hebt alle voordelen van lokaal werken qua performance tezamen met de voordelen van een centrale opslag en een gestandaardiseerde manier van werken.

Hang hier een snelle fileserver achter, liefst met deduplicatie, en je hebt een zeer vlotte omgeving. Je netwerk wordt minder belast aangezien niet elke save direct over het netwerk gaat. Daarnaast kan je alle backups gewoon weer centraal regelen. Je moet alleen zorgen dat iedere designer op tijd een commit uitvoert om de data op te slaan.

Werkt iemand offsite kan hij gewoon lokaal verder werken en is hij niet afhankelijk van een traag netwerk. Valt de server uit kan je alsnog verder werken want iedereen heeft z'n tijdelijke werk lokaal staan.

Voordeel is ook dat je nooit over elkaars werk heen kan opslaan en iedereen een vorige versie kan recoveren mocht dat nodig zijn. Doordat elke versie bewaart blijft kan niemand permanent files verwijderen.

[ Voor 7% gewijzigd door Tsurany op 05-01-2016 18:33 ]

[Kapotlood]

@supersnathan94:
Wat jij omschrijft klinkt als 2 druppels water als wat wij willen gaan doen Het is inderdaad het idee dat met netwerk accounts gaan werken, waar in theorie iedereen achter willekeurig elke (lokale) computer moet kunnen zitten en alleen maar hoeft in te loggen om te kunnen werken. Zei het met als kanttekening dat we wel voornamelijk achter dezelfde computer blijven zitten, en het dus in ons geval vooral om het beschikbaar(der) maken van de bestanden gaat.

@Tsurany:

Werkt iemand offsite kan hij gewoon lokaal verder werken en is hij niet afhankelijk van een traag netwerk. Valt de server uit kan je alsnog verder werken want iedereen heeft z'n tijdelijke werk lokaal staan.

Dat is nu eigenlijk wat we/ik permanent wil gaan voorkomen, omdat we nu te vaak tegen problemen aanlopen als er o.a. iets uitgewisseld moet worden. Het klinkt ook alsof met deze variant van versiebeheer er enorm veel data bewaard wordt: iets wat met onze projecten van 5GB of meer (met veel correctierondes in zowel design als DTP-fase) meer ruimte op slokt dan wat we nu kunnen gebruiken Maar ik hou 'm sowieso even in de gaten... misschien weet onze systeembeheerder hier goeds uit te halen als @Supersnathan94's uitleg (met LDAP-accounts e.d.), wat we hier in de eerste instantie willen uitproberen, niet goed uit pakt voor ons.

Als het goed is hebben we volgende week even een ronde-tafel gesprekje met de baas en de systeembeheerder (en ikzelf). Ik had al even een klein babbeltje, maar de baas wil er ook meer van weten voor we alles gaan testen. Plus het wordt ook een beetje een peil-momentje om te zien of er animo is om alle collega's "op te leiden" om meer uniform te laten werken.

[Tsurany]

joramoudenaarde schreef op dinsdag 05 januari 2016 @ 20:49:
@Tsurany:

[...]
Dat is nu eigenlijk wat we/ik permanent wil gaan voorkomen, omdat we nu te vaak tegen problemen aanlopen als er o.a. iets uitgewisseld moet worden. Het klinkt ook alsof met deze variant van versiebeheer er enorm veel data bewaard wordt: iets wat met onze projecten van 5GB of meer (met veel correctierondes in zowel design als DTP-fase) meer ruimte op slokt dan wat we nu kunnen gebruiken Maar ik hou 'm sowieso even in de gaten... misschien weet onze systeembeheerder hier goeds uit te halen als @Supersnathan94's uitleg (met LDAP-accounts e.d.), wat we hier in de eerste instantie willen uitproberen, niet goed uit pakt voor ons.

Hoe wil je aan versiebeheer doen zonder oude versies te bewaren? Je kan nog altijd oude versies verwijderen als het echt moet maar het idee achter versiebeheer is dat je alle versies ook bewaart.

Let wel op dat met grote projecten vanaf een netwerkschijf werken vertraging oplevert dus zorg dat je performance ruim afdoende is.

[Kapotlood]

Vooralsnog door niet aan versiebeheer te doen, op een dubbele (of driedubbele) backup na. We bewaren op 't moment, ook omdat dat nodig is in ons vak, oude projecten tot ±10 jaar terug. Waarschijnlijk nog wel een stuk langer, maar we bestaan "pas" 10 jaar, dus meer archief dan dat hebben we niet Maar dat alles bij elkaar neemt nu ca. 20TB in beslag, 60TB als je alle backups mee telt, en misschien nog meer als ik bedenk hoeveel data er niet gearchiveerd is door de ontwerpers.

Dat zijn alle projecten in dat geval, zowel op het archief als op de (op dit moment) dubbele backup voor zover ik weet. Een hoop projecten die we doen hebben alles bij elkaar ook gemiddeld zo'n 3-7 correctierondes per project. Dat is behoorlijk veel data voor een bedrijf van 16 man wat 10 jaar bestaat. Als, naast de projecten zelf, al die correctierondes ook als versie bewaard moeten worden, dan weet ik niet eens hoe ontzettend veel data we dan zouden verstoken.

Bij m'n vorige werk zaten we met ongeveer net zoveel mensen, en met ongeveer dezelfde grootte bestanden. We werkten daar allemaal tegelijk op een dual-gigabit netwerk, en zelfs als de systeembeheerder updates over het netwerk naar iedere computer stuurde, merkten we amper vertraging. Die manier van werken/netwerk hoop ik hier ook te kunnen opzetten: dan kan er een stuk meer geautomatiseerd worden (backups), zijn de projecten en bestanden een stuk uniformer opgezet (scheelt me veel tijd aan archiveerwerk), en wordt het overdragen van projecten ook een stuk minder foutgevoelig.

(wetende dat we dan wel een omslag moeten maken hier in de manier waarop we werken. Dat zal tijd en moeite kosten, maar dat is het meer dan waard denk ik)