Best Practices Fileserver

[basset]

Weet iemand of er een best practices is voor het opzetten van een FIleserver met win2003 in een Raid 5 met 2 TByte aan ruimte (uitbereidbaar naar meer)

Wij willen een Fileserver neerzetten met ongeveer 2 TB aan storage in een Dynamic Volume.

Nu weet ik alleen niet of er in win2003 adviezen zijn, van hoe groot die volumes maximaal mogen zijn, of wat je het beste kunt aanhouden voor performance en onderhoud, door meerdere volumes aan te maken.

We lopen nu met win2000 en 500G bijvoorbeeld tegen problemen dat chkdsk eeuwig duurt. Maar goed, dat is win2000. Wie weet is dat anders in 2003.

[The Eagle]

Qua best practises: ik denk persoonlijk dat dat ook ligt aan de data die je er op op wilt slaan. Voor een fileserver die vnl grote bestanden te verwerken krijg (Autocad, Adobe, etc) wil je denk ik een andere opslagvorm dan een fileserver die meest Word-bestanden te verwerken krijgt. Net zoals je voor een muziekserver ook een andere config zult willen - da's vnl eenmalig opzetten en veel uitlezen

Maar wat had je zelf per ongeluk al gezocht / gevonden Stond er niks op MS Technet ofzo

[basset]

The Eagle schreef op maandag 16 oktober 2006 @ 14:40:
Qua best practises: ik denk persoonlijk dat dat ook ligt aan de data die je er op op wilt slaan. Voor een fileserver die vnl grote bestanden te verwerken krijg (Autocad, Adobe, etc) wil je denk ik een andere opslagvorm dan een fileserver die meest Word-bestanden te verwerken krijgt. Net zoals je voor een muziekserver ook een andere config zult willen - da's vnl eenmalig opzetten en veel uitlezen

Maar wat had je zelf per ongeluk al gezocht / gevonden Stond er niks op MS Technet ofzo

Ik zit te zoeken in de user groups, maar daar wordt niet veel gezegt...tot nu toe Bovendien is de MS site tergent traag en zitten hier misschien ook mensen die eea weten . Alle kanalen moeten geprobeerd worden nietwaar?

Heb wel een best practices voor het gebruik van dynamic disks gevonden bijvoorbeeld. Maar is niet genoeg op dit moment.

[The Eagle]

Geen idee waar je nou precies gezocht hebt, maar Google op "Best practices for fileservers" levert slechts 667 resultaten - wellicht dat daar wat tussen zit. Interessante lectuur is het zeker

Verder: post even wat voor bestanden er op die fileserver komen te staan, m.a.w. wat het doel is van die server. Dan kunnen we er iig makkelijker ons licht op laten schijnen

[basset]

The Eagle schreef op maandag 16 oktober 2006 @ 15:09:
Geen idee waar je nou precies gezocht hebt, maar Google op "Best practices for fileservers" levert slechts 667 resultaten - wellicht dat daar wat tussen zit. Interessante lectuur is het zeker

Verder: post even wat voor bestanden er op die fileserver komen te staan, m.a.w. wat het doel is van die server. Dan kunnen we er iig makkelijker ons licht op laten schijnen

Pff ik zit nu op technet van MS (eindelijk) maar ik krijg het idee dat het een studie op zich is, die niet erg makkelijk te beantwoorden wordt. Ik heb ieder geval genoeg lekker leesvoer hier

In principe zit de fileserver bij ons het probleem niet in de type files: Voornamelijk Word doc's pdf's en installatiefiles, maar meer in de enorme hoeveelheid folders en files.

Als voorbeeld, kan win2000 maar paden weegeven van ik meen 256 characters. Kom je daarboven ga je problemen krijgen met het copieren en deleten van hoofdfolders. Dat probleem komen wij dus wel eens tegen. En nee, daar is niets tegen te doen, zo is het gewoon gegroeid. Win2003 heeft misschien al dit probleem niet.

Checkdisk duurt een eeuwigheid doordat er zoveel files op een groot volume staan, vandaar dat we kijken of er een betere indeling van dynamische volumes is.

Ik denk idd dat een antwoord dus niet 123 te vinden is en zal ik beetje bij beetje de informatie moeten vinden.

[sariel]

Tsja, waarom 1 filesystem van 2 tera?
Als je het toch via het net deelt, maak dan meerdere filesystems aan (1 fs per 2 disks, raid 1) en maak een aantal extra shares aan. Het is een stuk sneller te scannen en als er iets mis gaat vangt de 2e schijf de eerste op.

\\server\users$\username
\\server\administratie
\\server\documenten
\\server\bestanden
\\server\etcetera

en stap af van raid5. het is een te cheape oplossing om raid redundancy te doen.

scenario:
raid5:
d0 - operating system
d1+2+3+4+5 - filedata
d6 - stript

raak 2 schijven kwijt (d1 en d6) en je bent alles kwijt.

raid1:
d0+1: operating system
d2+3: filedata1
d4+5: filedata2
d6+7: filedata3

minder ruimte, maar als nu d1 en d6 er uit knallen draait alles door, en merkt niemand iets.
alleen als d0 en d1 toevallig beide kapot gaan ben je alleen dat deel kwijt (backups, anyone?)

voor echte snelheid en redundancy, maak dan een raid10 aan.

[basset]

sariel schreef op maandag 16 oktober 2006 @ 15:57:
Tsja, waarom 1 filesystem van 2 tera?
Als je het toch via het net deelt, maak dan meerdere filesystems aan (1 fs per 2 disks, raid 1) en maak een aantal extra shares aan. Het is een stuk sneller te scannen en als er iets mis gaat vangt de 2e schijf de eerste op.

\\server\users$\username
\\server\administratie
\\server\documenten
\\server\bestanden
\\server\etcetera

en stap af van raid5. het is een te cheape oplossing om raid redundancy te doen.

scenario:
raid5:
d0 - operating system
d1+2+3+4+5 - filedata
d6 - stript

raak 2 schijven kwijt (d1 en d6) en je bent alles kwijt.

raid1:
d0+1: operating system
d2+3: filedata1
d4+5: filedata2
d6+7: filedata3

minder ruimte, maar als nu d1 en d6 er uit knallen draait alles door, en merkt niemand iets.
alleen als d0 en d1 toevallig beide kapot gaan ben je alleen dat deel kwijt (backups, anyone?)

voor echte snelheid en redundancy, maak dan een raid10 aan.

Dan moet je wel een cabinet hebben die meerdere Raid1's ondersteunt.

Bovendien is er besloten om raid5 te gebruiken en daar zal ik niet iets in kunnen veranderen denk ik.
Tenzij er een hele goede reden is. We hebben een backup en 24 uur verlies is acceptabel. Bovendien voeren we nog een fileserver uit die remote als replica komt te staan.

[Jazzy]

Kies voor een GPT partitie.

[LeNNy]

Wat is het precieze voordeel daarmee dan?

[Jazzy]

LeNNy schreef op maandag 16 oktober 2006 @ 20:38:
Wat is het precieze voordeel daarmee dan?

Het belangrijkste verschil is dat je over de 2 TB grens heen kunt, in tegenstelling tot het aloude MBR. Veel over te vinden met Google trouwens.

[basset]

Jazzy schreef op maandag 16 oktober 2006 @ 20:43:
[...]
Het belangrijkste verschil is dat je over de 2 TB grens heen kunt, in tegenstelling tot het aloude MBR. Veel over te vinden met Google trouwens.

En de nadelen?
Misschien sla ik de plank hier volledig mis, maar virusscanners kunnen meen ik ook het MBR scannen. Werkt dit ook zo bij GPT? Of is deze tot op heden onaangeroerd?

[ Voor 22% gewijzigd door basset op 17-10-2006 15:35 ]

[Question Mark]

Misschien offtopic, maar is er al na gedacht over hoe je die 2TB wilt gaan backuppen? (mbt. SLA's enzo)

[MAX3400]

Question Mark schreef op dinsdag 17 oktober 2006 @ 19:34:
Misschien offtopic, maar is er al na gedacht over hoe je die 2TB wilt gaan backuppen? (mbt. SLA's enzo)

Ach, een beetje tape-drive draait er op een rustige tijd een paar 100MB/min doorheen dus voor een full backup ben je niet al te lang bezig. Misschien wel met een incremental dat de tijd voor het scannen van de changes groter is dan het daadwerkelijk wegschrijven. Je bent dus wel aangewezen op een zo breed mogelijk back-end (hoge transfers op je controllers, NIC's, kabels, switches etc) als je je backup niet in het apparaat/apparaten zelf regelt.

Dan terugkomend op de vraag; ik zou zelf opteren om eerst de data te splitsen. 2TB aan data lijkt me erg veel voor alleen maar "documentjes" en dus zou je data beter kunnen gaan splitsen naar type of naar grootte. Dingen als AutoCAD (hierboven ook al genoemd door iemand) het liefst op een aparte schijvenset wegzetten en ook mogelijke profielen/centrale apps op een aparte set.

Verder lijkt het me raadzaam om te denken aan een oplossing die niet bestaat uit 4 schijven van elk 500GB maar een klein (en liefst redundant) SAN. Hiermee kan je met de verschillende interfaces verschillende schijvensets/volumes bekend maken aan je gebruikers.

*hint: geen iSCSI neerzetten; ik vind zelf de performance hiervan nog steeds onderdoen voor de wat duurdere SCSI-320 SAN's.*

[ Voor 6% gewijzigd door MAX3400 op 17-10-2006 19:41 ]

[alt-92]

Question Mark schreef op dinsdag 17 oktober 2006 @ 19:34:
Misschien offtopic, maar is er al na gedacht over hoe je die 2TB wilt gaan backuppen? (mbt. SLA's enzo)

Lijkt me een mooie optie voor een DPM implementatie
backup to disk to tape, mooie ervan is dat files & folders op korte termijn vanaf DPM restored kunnen worden en je je backup window naar tape ongelimiteerd over de dag kan houden.

Maar goed, da's een ander verhaal en een ander kostenplaatje

[Question Mark]

MAX3400 schreef op dinsdag 17 oktober 2006 @ 19:40:
[...]
Ach, een beetje tape-drive draait er op een rustige tijd een paar 100MB/min doorheen dus voor een full backup ben je niet al te lang bezig

Klopt, als je het echter hebt over 2 TB aan data ben je zelfs met LTO3 al (uitgaande van maximale compressie) 3 tapes nodig. Dat betekend dat je (om de backup volledig automatisch te kunnen laten lopen) al iets van een autoloader nodig bent.

Als ik de TS goed begrijp gaat hij nu van 500 GB storage naar 2 TB toe. Ik vermoed dus dat hij iets dergelijks niet heeft liggen.

BackSlash32 schreef op dinsdag 17 oktober 2006 @ 19:58:
[...]
Maar goed, da's een ander verhaal en een ander kostenplaatje

True, maar een goed backupdesign is wel iets wat beter in een keer meegenomen zou moeten worden.

[ Voor 17% gewijzigd door Question Mark op 17-10-2006 20:02 ]

[Tomsworld]

Volgens mij is het beste een logische structuur in DFS, je maakt alles logisch aan wordt iets te groot move je het naar een andere server, je kan alles dubbel zetten via replication en dit schaalt toch al een groot eindje. Ik weet setups draaien met een paar Terra online zo waar alles minstens 2 keer staat.

[TheBrain]

sariel schreef op maandag 16 oktober 2006 @ 15:57:
en stap af van raid5. het is een te cheape oplossing om raid redundancy te doen.

Daarom is het ook verstandig om met hotspares te werken.

De kans dat er twee schijven zo vlak na elkaar overlijden dat je hotspare het niet heeft over kunnen nemen is te verwaarlozen. En daar heb je dan je backups nog voor.

[basset]

Backup is op zich geen issue.

We backuppen eerst naar disk, en dat zal niet 2TB zijn. Er is ook data die niet kritiek is en makkelijk is terug te halen. Bovendien gebruiken we nog geen 2TB, we willen alleen de ruimte.

Momenteel hebben we LTO3 welke 400G ongecomprimeerd weg kan zetten, ik denk dat we de 600G daar wel mee moeten halen. Doen we Backup to disc en daarna naar Tape dan hebben we genoeg tijd om een volledige backup te draaien. En anders een 2e tapeunit is ook nog een optie.....

Maar backup is een ander "probleem"

Het inrichten van de fileserver is prio 1

Op technet staat een hoop informatie gelukkig, maar het blijft lastig IMO.
Misschien denk ik er gewoon te moeilijk over en moeten we het gewoon simpel houden.

Momenteel heeft de fileserver een Dynamic Simple Volume van ongeveer 500GB en is de schijf een Dynamic Disc.

[ Voor 6% gewijzigd door basset op 19-10-2006 10:29 ]

[basset]

Overigens is het wel leuk dat je over die 2TB grens heeb kunt, maar probee maar eens een checkdisk te draaien als dat nodig is (met de /F optie)

In windows 2000 is die dan daaaagen bezig als je veel files op de schijf hebt staan. Niet echt een optie voor een file server. Heeft MS daar al iets aan gedaan?

[Rolfie]

en stap af van raid5. het is een te cheape oplossing om raid redundancy te doen.

voor echte snelheid en redundancy, maak dan een raid10 aan.

Raid 5 is inderdaad niet het snelste, maar wel stabiel.

RAID6 is nog beter. Hiermee kunnen er 2 schijven uit klappen zonder data verlies :-)

Een groot nadeel van Raid 10 is dat je veel verlies hebt, immers je verliest 50% van je schijven. Voor een fileserver is dit niet echt geschikt, en die snelheid is niet echt van toepassing bij een fileserver. Een goede array controller met een goede write cache is meer dan voldoende.
Bij een RAID10 is de kans is kleiner dat als er 2 disken crashen je systeem onderuit gaat. Maar hij is er nog steeds. Voor een bedrijfkritische server is dit een niet acceptabele oplossing. RAID6 bied hiervoor een goede garantie tegen een goede prijs.
Bij RAID6 mogen er er altijd 2 disken crashen, je server zal altijd door draaien

De kans dat er twee schijven zo vlak na elkaar overlijden dat je hotspare het niet heeft over kunnen nemen is te verwaarlozen. En daar heb je dan je backups nog voor.

Hou er wel rekening mee dat bij een rebuild van de hotspare er een hoop I/O moet plaats vinden. hierdoor is het risico groter. Daarna als je de defecte harddisk vervangen hebt, dat je die schijf daarna ook weer gerebuild moet worden, zodat de hotspare wer een hotspare wordt.

Maar backup is een ander "probleem"
Het inrichten van de fileserver is prio 1

Totdat het een keer mis gaat. Kwestie van prioriteiten stellen.

Murphy komt nog wel eens langs.

Ik zou ook nooit en schijf van 2T nemen. We gaan bij ons nooit groter dan 200Gb. Dit is goed en snel te recoveren. Zelfs een chkdsk van 200Gb met word docuementen kost al een hoop tijd.

Onze fileserver bestaat uit 3,5T momenteel. Dit is verdeeld via mountpoint en DFS. Hierdoor kunnen we gemakkelijk een failed en of corrupted disk recoveren

[ Voor 31% gewijzigd door Rolfie op 20-10-2006 10:16 ]

[TheBrain]

Rolfie schreef op vrijdag 20 oktober 2006 @ 10:06:
[...]

Hou er wel rekening mee dat bij een rebuild van de hotspare er een hoop I/O moet plaats vinden. hierdoor is het risico groter. Daarna als je de defecte harddisk vervangen hebt, dat je die schijf daarna ook weer gerebuild moet worden, zodat de hotspare wer een hotspare wordt.

De hotspare laten wij gewoon doordraaien en we definieren een nieuwe hotspare (de nieuw vervangen schijf). Verder valt het me mee hoe lang het rebuilden van een array duurt (HP MSA1000) dus voor ons is het risico nog steeds acceptabel.

We stappen binnenkort wel over op een EMC Clariion CX3-40 en daarmee moet het helemaal koekie zijn (4Gbit SAN met FC disks )

[basset]

Rolfie schreef op vrijdag 20 oktober 2006 @ 10:06:
[...]
knip


[...]

Totdat het een keer mis gaat. Kwestie van prioriteiten stellen.

Murphy komt nog wel eens langs.

Ik zou ook nooit en schijf van 2T nemen. We gaan bij ons nooit groter dan 200Gb. Dit is goed en snel te recoveren. Zelfs een chkdsk van 200Gb met word docuementen kost al een hoop tijd.

Onze fileserver bestaat uit 3,5T momenteel. Dit is verdeeld via mountpoint en DFS. Hierdoor kunnen we gemakkelijk een failed en of corrupted disk recoveren

Wat ik met prio 1 bedoel, is dat we eerst een strategie voor de fileserver moeten hebben. Daarna zoeken we de backup uit.

We gaan een backup to disc doen en backuppen dan naar tape om het backupwindow ruim te houden.

Maar daar wordt al over nagedacht. Dat is gewoon een ander vraagstuk naast de fileserver. We gaan niet online zonder dat er een backup gemaakt is en getest.


200GB is al te weinig voor alleen de projectfolder. Ik denk niet dat we 1 groot volume gaan maken idd, maar meerder "kleine dynamische" zodat we wel kunnen uitbereiden.
Kun je ook meerdere kleine volumes maken en deze mounten naar 1 share? Zodat de gebruikers het idee hebben dat er maar 1 share is? En ik weet niet of we dit met DFS willen doen. Het maakt het wel nodeloos ingewikkeld heb ik het idee, maar goed, daar kennen we DFS eigenlijk niet goed genoeg voor.

Nu lees ik dat win2003 een stuk sneller is met chkdsk dan 2000 en dat er een vrfydsk
functie is toegevoegd die "live" kan draaien. Dat is al een hele verbetering. Mocht je daarna toch een chkdsk doen dan kunnen we dat op een hopelijk goede manier inplannen

[Rolfie]

200GB is al te weinig voor alleen de projectfolder. Ik denk niet dat we 1 groot volume gaan maken idd, maar meerder "kleine dynamische" zodat we wel kunnen uitbereiden.
Kun je ook meerdere kleine volumes maken en deze mounten naar 1 share? Zodat de gebruikers het idee hebben dat er maar 1 share is? En ik weet niet of we dit met DFS willen doen. Het maakt het wel nodeloos ingewikkeld heb ik het idee, maar goed, daar kennen we DFS eigenlijk niet goed genoeg voor.

Daar kan je inderdaad meedere mountpoints voor nemen. We zijn nu een file server aan het opbouwen met 3T aan opslag. We gebruiken mountpoints tussen de 25 en 200Gb. Deze plaatsen we in de root van een drive en koppelen we aan elkaar via DFS. Hierdoor ziet de gebruiker 1 doorlopende strucktuur. Een andere optie is mountpoint in mountpoint. Dit werkt ook goed.
Werk alleen wel je backups goed uit, anders backup je of dubbel of niet....

Nu lees ik dat win2003 een stuk sneller is met chkdsk dan 2000 en dat er een vrfydsk
functie is toegevoegd die "live" kan draaien. Dat is al een hele verbetering. Mocht je daarna toch een chkdsk doen dan kunnen we dat op een hopelijk goede manier inplannen

Murphy "Anything that can go wrong, will"

[basset]

Rolfie schreef op zaterdag 21 oktober 2006 @ 13:18:
[...]

Daar kan je inderdaad meedere mountpoints voor nemen. We zijn nu een file server aan het opbouwen met 3T aan opslag. We gebruiken mountpoints tussen de 25 en 200Gb. Deze plaatsen we in de root van een drive en koppelen we aan elkaar via DFS. Hierdoor ziet de gebruiker 1 doorlopende strucktuur. Een andere optie is mountpoint in mountpoint. Dit werkt ook goed.
Werk alleen wel je backups goed uit, anders backup je of dubbel of niet....


[...]
Murphy "Anything that can go wrong, will"

Het nadeel van DFS is volgens mij dat je verplicht wordt om met je PC in het domein te zitten.

Nu kun je computers die niet in het domein zitten nog met je domein login en PW verbinden met een share. Bij DFS lukt dat niet meer en moet je de exactre locatie op de server weten. Dat wordt lastig voor testsystemen die wij niet in het domein laten komen.

[Rolfie]

basset schreef op maandag 23 oktober 2006 @ 09:13:
[...]


Het nadeel van DFS is volgens mij dat je verplicht wordt om met je PC in het domein te zitten.

Nu kun je computers die niet in het domein zitten nog met je domein login en PW verbinden met een share. Bij DFS lukt dat niet meer en moet je de exactre locatie op de server weten. Dat wordt lastig voor testsystemen die wij niet in het domein laten komen.

Volgens klopt dit inderdaad. Dan moet je toch met mountpoints aan de slag gaan. Werkt op zich ook goed en zonder problemen.

[technopeuter]

je kunt ook een standalone dfs-root maken die is helaas dan niet (de root) te repliceren.