NAS icm Windows 2003 Storage Server tactiek

[Grolsch]

Hallo Mensen,

Ik hoop bij jullie wat praktische tips tegen te komen.

ik zal kort de huidige situatie uitleggen.

Bedrijf met zo'n 80 ge-automatiseerde werkplekken.

Windows 2000 Domein met windows 2000 clients.

Men gebruikt de volgende software diensten

1. Exchange 2000
2. ERP software
3. Standaard netwerk schijven / Office 2000 omgeving.

Momenteel heb ik de volgende server omgeving

2 x citrix server (NT4.0TSE) (alleen voor ERP pakket)
Oude machientjes, maar werken goed met dual Xeon en 2GB ram P/S, en RAID 1

1 x DB server speciaal voor ERP pakket met RAID5 kabinet(wordt vervangen)

1 x Exchange server (DELL / Xeon Processor / 1GB RAM / RAID 5 Kabinet]

1 x Fujitsu Siemens server welke DC is, File en print server, SQL server

Het probleem wat we hadden was schijfruimte gebrek. Zowel op de file server, als op de email server.
Ook valt de performance van de DB server voor het ERP pakket tegen.

Vervolgens heb ik het volgende aangeschaft:

Fujitsu Siemens FibreCAT N40-i Xeon 3.0 Ghz / 1Gb DDR2 OS = Windows Storage Server
Er zitten 2 SCSI schijven in voor het OS (RAID 1)


Voor de storage zelf heb ik een FibreCAT SX30 Storage system aangeschaft met 10 x HDD U320 10K 146Gb hot plug 1" M schijven. de 10 Schijven zijn geconfigged als een RAID 10 (gemirrorde stripe set)

http://extranet.fujitsu-s.../i26448/i27863/i27870.pdf

De N40-i is met de fibreCAT SX30 verbonden dmv 2 x RAID Ctrl U320 1-ch LP 64MB BBU LSI controllers.

Er zit de volgende software bij:
Win Target Advanced 2.0
WSS 2003 Feature Pack MS Exchange Server 2003 (werkt ook voor exchange 2000)

Dus ik kan op de NAS via iSCSI virtual schijven aanmaken, welke ik aan andere servers koppel.

Wat ik dus wil is ALLE data op de nieuwe NAS zetten., dus MAIL + FILE's + DATABASE's.

Nu heb ik de volgende concrete vragen

1. Moet ik de 2 GBit Controllers in m'n N40-i laten "teamen", of moet ik ze allebei een IP adres geven. Wat zijn de concrete voor/nadelen

2. Moet ik netwerk mappings (dus gewoon bestanden) laten mappen naar de NAS server, of moet ik een virtual Disk koppelen aan m'n huidige Data server, en het verkeer van de clients dus via de oude data server laten lopen ?

3. Moet ik de SQL database's zelf op een iSCSI drive gaan zetten, of weer via het netwerk gaan doen.

Zoals je kunt lezen is dit de 1e keer dat ik met bovenstaande config werk.

Alvast bedankt voor jullie reactie's.

[ Voor 3% gewijzigd door Grolsch op 07-02-2006 17:11 ]

[Verwijderd]

1) hangt een beetje van je vraaag naar bandbreedte af. Door ze te "teamen" krijg je feitelijk een enkele 2gbit verbinding. Echter als je het dataverkeer tussen segmenten gescheiden wilt houden, kun je ze beter loshouden. Minder maximale bandbreedte maar wel een dual homing systeem. In jou geval lijkt mij teaming de beste oplossing aangezien (volgens mij) alles in hetzelfde IP bereik zit.

2) Als de network mappings via de bestaande server lopen en die server geeft de geest heb je een probleem. Tegelijkertijd hem je een probleem als je nieuwe hardware sterft. Ga je rechtstreeks naar de nieuwe hardware elimineer je een mogelijk problematisch punt zonder dat je iets inlevert. Rechtstreeks lijkt mij dus de logische keuze. (Mits je N40i server sterk genoeg is om de vraag aan te kunnen)

3) Wat is sneller? Ik zou zeggen iSCSI, maar dit is meer een hardware zaak.

Daarnaast vraag ik me af waarom je alle nieuwe schijven als Raid 10 geconfigureerd hebt. Ja, het is sneller maar ik vraag me af of die snelheid voor een fileserver interessant is. Een gedeelte in Raid 5 lijkt mij logischer.

[Grolsch]

Verwijderd schreef op woensdag 08 februari 2006 @ 01:57:
1) hangt een beetje van je vraaag naar bandbreedte af. Door ze te "teamen" krijg je feitelijk een enkele 2gbit verbinding. Echter als je het dataverkeer tussen segmenten gescheiden wilt houden, kun je ze beter loshouden. Minder maximale bandbreedte maar wel een dual homing systeem. In jou geval lijkt mij teaming de beste oplossing aangezien (volgens mij) alles in hetzelfde IP bereik zit.

We gebruiker inderdaad 1 /24 netwerk.

Ik had misschien het idee om het hele iSCSI verhaal via 1 Gbit verbinding te laten lopen, en 1 Gbit verbinding te gebruiken voor clients request

2) Als de network mappings via de bestaande server lopen en die server geeft de geest heb je een probleem. Tegelijkertijd hem je een probleem als je nieuwe hardware sterft. Ga je rechtstreeks naar de nieuwe hardware elimineer je een mogelijk problematisch punt zonder dat je iets inlevert. Rechtstreeks lijkt mij dus de logische keuze. (Mits je N40i server sterk genoeg is om de vraag aan te kunnen)

Een groot voordeel naar mijn idee om gebruik te gaan maken van de N40i, is dat deze server op win2k3 draait, en we dus gebruik kunnen maken van nieuwe functionaliteiten zoals VSC.

3) Wat is sneller? Ik zou zeggen iSCSI, maar dit is meer een hardware zaak.

OK, ik zal hier mee gaan testen.

Daarnaast vraag ik me af waarom je alle nieuwe schijven als Raid 10 geconfigureerd hebt. Ja, het is sneller maar ik vraag me af of die snelheid voor een fileserver interessant is. Een gedeelte in Raid 5 lijkt mij logischer.

Omdat er dus SQL database's + Exchange Database + ERP database op komt te staan, leek mij RAID 10 een snelle en veilige keuze.

Bedankt in ieder geval voor je input !

Ik ga dus de netwerk mappings op de NAS zetten, en de clients daar ook heen laten verwijzen.

Is het nu slim om voor de netwerk bestanden (+- 150GB) een iSCSI schijf aan te maken, of gewoon mappen maken op de hele grote NAS, en die te delen

[Question Mark]

Grolsch schreef op woensdag 08 februari 2006 @ 08:32:
Omdat er dus SQL database's + Exchange Database + ERP database op komt te staan, leek mij RAID 10 een snelle en veilige keuze.

Veelal worden databases op Raid 5 geplaatst, en de (transactional) Log files van de databases op Raid 1. Ik weet niet of het nu een handige keuze is om alles op Raid 10 te plaatsen.

Persoonlijk had ik hier iets meer aandacht aan besteed. Je zou bv. als alternatief ook nog kunnen kiezen om de databases op aparte Raid-set's te plaatsen (je hebt toch 10 disken). Ook Log files zou je op een aparte Raid-set kunnen plaatsen.

De preciese (optimale) indeling is uiteraard ook afhankelijk van de verwachte belasting, bovenstaand is natuurlijk puur theoretisch. Heb je ook base-lines van je huidige disk-config's?

[Grolsch]

Question Mark schreef op woensdag 08 februari 2006 @ 08:44:
[...]

Veelal worden databases op Raid 5 geplaatst, en de (transactional) Log files van de databases op Raid 1. Ik weet niet of het nu een handige keuze is om alles op Raid 10 te plaatsen.

Persoonlijk had ik hier iets meer aandacht aan besteed. Je zou bv. als alternatief ook nog kunnen kiezen om de databases op aparte Raid-set's te plaatsen (je hebt toch 10 disken). Ook Log files zou je op een aparte Raid-set kunnen plaatsen.

Het enige voordeel van RAID 5 tov RAID 10 is dat je meer netto schijfruimte hebt.
Maar RAID 5 is toch beduidend langzamer als RAID10.
Ik vind dat je in de tijd waarin de schijven bijna niks meer kosten beter kunt kiezen voor performance, dan een paar 100 € te besparen

De preciese (optimale) indeling is uiteraard ook afhankelijk van de verwachte belasting, bovenstaand is natuurlijk puur theoretisch. Heb je ook base-lines van je huidige disk-config's?

Ik heb zo geen base-line, toevallig nog leuke tooltjes voor

[Question Mark]

De paar 100 euro is inderdaad de moeite niet... 'Probleem' is wel dat je 3 databases (SQL, Exchange en je ERP-pakket) + Transactional Log files op één en dezelfde Raid-set parkeerd.

Stel dat er nu een grote query losgelaten wordt op je SQL database, welke enorm veel Disk I/O genereerd. dan lijden je Exchange en je ERP-pakket hier nu onder...

Let wel, nog steeds theoretisch... Mocht uit je base-line blijken dat je disken nauwelijks belast worden, dan is het geen enkel probleem.

Baselines creëer ik altijd met plain old Perfmon. Kwestie van een nieuwe counter-log aanmaken en laat maar een paar dagen lopen...

In je TS meld je ook nog dat de performance van de huidige SQL server tegenvalt. Enig idee wat de bottleneck op het systeem is?

[Grolsch]

Question Mark schreef op woensdag 08 februari 2006 @ 09:13:
De paar 100 euro is inderdaad de moeite niet... 'Probleem' is wel dat je 3 databases (SQL, Exchange en je ERP-pakket) + Transactional Log files op één en dezelfde Raid-set parkeerd.

Stel dat er nu een grote query losgelaten wordt op je SQL database, welke enorm veel Disk I/O genereerd. dan lijden je Exchange en je ERP-pakket hier nu onder...

Let wel, nog steeds theoretisch... Mocht uit je base-line blijken dat je disken nauwelijks belast worden, dan is het geen enkel probleem.

Baselines creëer ik altijd met plain old Perfmon. Kwestie van een nieuwe counter-log aanmaken en laat maar een paar dagen lopen...

Misschien een beetje dullig van mij, maar welke "physical disk counters" zet jij aan in perfmon om een goed beeld te krijgen ?

In je TS meld je ook nog dat de performance van de huidige SQL server tegenvalt. Enig idee wat de bottleneck op het systeem is?

De SQL performance valt nog wel mee, maar de database van ons ERP systeem is af en toe traag.
Dit draait nog op een Btrieve database, en dat ligt waarschijnlijk aan de oude server waar nog een RAID 5 kabinet (van 5 jaar oud) in zit.
Ik heb voor deze server een nieuwe server besteld (RX100) met 2 gemirrorde SATA schijven.
En ik wil een iSCSI schijf aan gaan maken voor de data.

Bovenstaande is niet alleen gedaan voor performance, maar ook omdat er voor de oude server 0,0 reserve onderdelen meer te vinden zijn, wat ons laatst al op-brak toen 1 schijf van het kabinet van ons was heen gegaan naar de eeuwige data velden

[Question Mark]

Disk Subsystem Performance Analysis for Windows is een white paper die eigenlijk alles behandeld.

This paper examines the performance of storage subsystems used by computers running the Microsoft® Windows® 2000, Windows XP, or Windows Server™ 2003 family of operating systems.

This paper considers performance from both the hardware and software perspectives. In addition, it discusses tools for storage subsystem analysis and design and provides rules of thumb and guidelines for system design and to solve the performance bottlenecks in specific configurations.

De White Paper gaat vrij diep, maar er is compleet hoofdstuk gewijd aan Perfmon counters... Ik moet overigens ook eerlijk zeggen dat ik (ook op de MS-site) al Exchange implementaties ben tegengekomen met de database-files op Raid 10. Het apart plaatsen van transaction logs wordt echter nog wel aangeraden

bv op:Optimizing Storage for Exchange Server 2003

[Grolsch]

ok, tnx ga ik lezen.

Dan rest mij deze vraag nog:

Ik ga dus de netwerk mappings op de NAS zetten, en de clients daar ook heen laten verwijzen.

Is het nu slim om voor de netwerk bestanden (+- 150GB) een iSCSI schijf aan te maken, of gewoon mappen maken op de hele grote NAS, en die te delen

[edit]

weer mega overdreven van MS hé

C:\ - System volume, operating system, Exchange system files - RAID-1 (direct-attached storage, not SAN)

2 schijven

• D:\ - Page file - RAID-1 (direct-attached storage, not SAN)

2 schijven

• E:\ - SMTP and MTA queues - RAID-1+0 (SAN)

4 schijven

• F:\ - Log files from storage group 1 - RAID-1 (SAN)

2 schijven

• G:\ - Databases from storage group 1 - RAID-1+0 (SAN)

4 schijven

dus totaal 2 + 2 + 4 + 2 + 4 = 14 schijven voor een exchange server

zal wel niet over een server gaan met 80 mailboxes

[ Voor 55% gewijzigd door Grolsch op 08-02-2006 12:11 ]

[Question Mark]

Grolsch schreef op woensdag 08 februari 2006 @ 12:03:
...

Jij was toch degene van de quote: "Ik vind dat je in de tijd waarin de schijven bijna niks meer kosten beter kunt kiezen voor performance, dan een paar 100 € te besparen"?

't is idd een beetje overkill...

[Femme]

Question Mark schreef op woensdag 08 februari 2006 @ 08:44:
[...]

Veelal worden databases op Raid 5 geplaatst, en de (transactional) Log files van de databases op Raid 1. Ik weet niet of het nu een handige keuze is om alles op Raid 10 te plaatsen.

Logfiles stellen qua belasting geen drol voor zolang de RAID-controller over een efficiënt werkende write-back cache beschikt. Het schrijven van logfiles is over het algemeen sequentieel werk en kan dus uitstekend versneld worden dmv delayed en combined writing, wat een write-back cache zou moeten doen. Alle andere activiteit op het array hoeft daar niet al te veel hinder van te ondervinden. De verhalen dat aparte arrays voor logfiles zijn komen volgens mij uit een tijd dat een (battery backed) write-back cache nog niet gebruikelijk was.

Het zal mij niet verbazen dat bijv. een array van zes schijven voor data en logs een betere algehele performance zal bieden dan gescheiden arrays van vier schijven voor data en twee voor logs, zolang je maar een fatsoenlijke controller met write-back cache gebruikt. Fujitsu gebruikt volgens mij adapters van LSI Logic dus dat zou wel snor moeten zitten.

Ter illustratie het verschil in I/O performance bij het wegschrijven van logfiles op een Areca ARC-1120 met 128MB cache en vier Raptor WD740GD's in RAID 5 en RAID 10:

Tweakers.net BenchDB - MySQL - Log drive
RAID	Controller	Cache modus	Score (IOps)
RAID 10	Areca ARC-1120	Write-back	16.667
RAID 5	Areca ARC-1120	Write-back	16.667
RAID 10	Areca ARC-1120	Write-through	1.053
RAID 5	Areca ARC-1120	Write-through	775

[Brahiewahiewa]

Je maakt wel de klassieke automatiseerders fout, hè? Eerst de hardware aanschaffen en je daarna gaan afvragen wat je eigenlijk nodig hebt

Maar ik moet ? gelijk geven: met alle schijven in één RAID10 ga je performance problemen creëren. Op het moment dat iemand de jaarcijfers uit het ERP systeem gaat genereren, zitten er 79 mensen zonder mail. 't Zelfde geldt voor het geval dat er iemand een stukje data mining gaat zitten doen in SQL of besluit dat de file share maar weer eens op virussen gescanned moet worden.

Ik zou voor vier RAID5 setjes van elk 3 schijven gaan. Gemiddeld geeft zo'n RAID5 setje ruim voldoende performance en je hebt het voordeel dat piekbelasting geen invloed heeft op de andere applikaties.

[Grolsch]

Brahiewahiewa schreef op woensdag 08 februari 2006 @ 13:00:
Je maakt wel de klassieke automatiseerders fout, hè? Eerst de hardware aanschaffen en je daarna gaan afvragen wat je eigenlijk nodig hebt

Ben ik niet met je eens ik ben er van overtuigd dat ik de juiste hardware heb aangeschaft, ik ben nu alleen aan het filosoferen over hoe ik het in ga richten.
Het is allemaal nog niet live, dus ik kan nog alle kanten op.

Maar ik moet ? gelijk geven: met alle schijven in één RAID10 ga je performance problemen creëren. Op het moment dat iemand de jaarcijfers uit het ERP systeem gaat genereren, zitten er 79 mensen zonder mail. 't Zelfde geldt voor het geval dat er iemand een stukje data mining gaat zitten doen in SQL of besluit dat de file share maar weer eens op virussen gescanned moet worden.

Ik zou voor vier RAID5 setjes van elk 3 schijven gaan. Gemiddeld geeft zo'n RAID5 setje ruim voldoende performance en je hebt het voordeel dat piekbelasting geen invloed heeft op de andere applikaties.

Als je dat doet gaat dat weer ten koste van de schaalbaarheid.
Hup, hier een paar GB'tjes over, die schuif ik daar heen, etc. etc. dat zit er dan niet meer in.
Dus dan moet je van te voren heel goed weten waar je je schijfruimte hen wilt schuiven.

[Question Mark]

Even afgezien van eventuele performance, vergeet je 'recoverability' niet.

Als er bij een Raid 10 twee disken uitvallen, kan het voorkomen dat mijn data weg is (afhankelijk van welke disken uitvallen). Nu is het risico dat twee disken tegelijk uitvallen erg klein, maar niet verwaarloosbaar. Dit is ook de reden dat Raid 6 / ADG uitgevonden is. Met de steeds groter wordende schijfen worden de rebuild-tijden ook steeds langer. Mocht tijdens het rebuilden nog een disk omvallen (niet onwaarschijnlijk want het aantal draai-uren zal gelijk zijn), dan ben je het haasje.

Dat betekend in de praktijk dat dus zowel database-files, als log files weg zijn... Het enige wat dan nog rest is het terugplaatsen van je laatste backup, de data tussen backup en het moment van crashen is echter verloren.

Heb ik daarentegen mijn logfiles op een aparte Raid-set, dan kunnen logfiles ge-replayed worden en de database is uo-to-date. Uit de Exchange storage guide:

For optimal recoverability, it is recommended that you place the transaction logs and databases for a given storage group on to different LUN's (logical unit numbers); configured as RAID-1/RAID-1+0. Also, It is recommended that the separate LUNs hosting the logs and database files for the same storage group do not share physical disks within the array. This is to increase the level of recoverability, allowing you to recover from multiple disk failure scenarios with minimal data loss (either the disks backing the logs or the disks backing the databases are lost; but not both). If you lose the log LUN, you still have a nearly up-to-date database; if you lose the database LUN, you can restore from backup and play the logs forward to bring the database up-to-date. If you place both logs and databases from the same storage group on the same LUN, or different LUNs that share the same physical disks, you have the potential to lose both the logs and database during a multiple disk failure scenario. This will cause you to lose all changes since the last successful backup.

[Grolsch]

Question Mark schreef op woensdag 08 februari 2006 @ 13:19:
Even afgezien van eventuele performance, vergeet je 'recoverability' niet.

Als er bij een Raid 10 twee disken uitvallen, kan het voorkomen dat mijn data weg is (afhankelijk van welke disken uitvallen). Nu is het risico dat twee disken tegelijk uitvallen erg klein, maar niet verwaarloosbaar. Dit is ook de reden dat Raid 6 / ADG uitgevonden is. Met de steeds groter wordende schijfen worden de rebuild-tijden ook steeds langer. Mocht tijdens het rebuilden nog een disk omvallen (niet onwaarschijnlijk want het aantal draai-uren zal gelijk zijn), dan ben je het haasje.

Ik was eigenlijk niet eens bekend met RAID-6, maar ik heb de FAQ gelezen.
Het komt er op neer dat het principe raid-5 is, maar dat er 2 schijven uit kunnen vallen ipv 1.
Maar ik lees ook dat vooral schrijven errug traag is (ivm parity), en dat het bijna niet wordt gebruikt, omdat je eigenlijk net zo goed een RAID5 kunt gebruiken icm een hotspare

bron: RAID FAQ

Dat betekend in de praktijk dat dus zowel database-files, als log files weg zijn... Het enige wat dan nog rest is het terugplaatsen van je laatste backup, de data tussen backup en het moment van crashen is echter verloren.

Heb ik daarentegen mijn logfiles op een aparte Raid-set, dan kunnen logfiles ge-replayed worden en de database is uo-to-date. Uit de Exchange storage guide:
[...]

als je het zo gaat bedenken, kun je het zover doordraven als je wil, en wordt het voor onze firma veelste prijzig om alles compleet rendunant uit te voeren.

je argumenten zijn an sich OK, maar vergeet niet dat we het hier over een MKB bedrijf hebben waarvan ICT niet de core business is.
We zijn geen COLO of ISP oid.

[ Voor 6% gewijzigd door Grolsch op 08-02-2006 13:50 ]

[Question Mark]

Grolsch schreef op woensdag 08 februari 2006 @ 13:50:
[...]
Maar ik lees ook dat vooral schrijven errug traag is (ivm parity), en dat het bijna niet wordt gebruikt, omdat je eigenlijk net zo goed een RAID5 kunt gebruiken icm een hotspare

't is Raid 5 met twee disken voor parity. Het grote voordeel ten opzichte van Raid 5 met hotspare is, dat er tijdens het rebuilden van een defecte disk, er nog één uit mag vallen.

Heb ik daarentegen een Raid5 met hotspare. Dan wordt tijdens het uitvallen van een disk automatisch de hotspare gepakt voor het rebuilden. Totdat de rebuild klaar is, mag er geen disk meer uitvallen!

[Grolsch]

Question Mark schreef op woensdag 08 februari 2006 @ 14:11:
[...]
't is Raid 5 met twee disken voor parity. Het grote voordeel ten opzichte van Raid 5 met hotspare is, dat er tijdens het rebuilden van een defecte disk, er nog één uit mag vallen.

Heb ik daarentegen een Raid5 met hotspare. Dan wordt tijdens het uitvallen van een disk automatisch de hotspare gepakt voor het rebuilden. Totdat de rebuild klaar is, mag er geen disk meer uitvallen!

ik snap het, het is puur een risico overweging. Het is langzamer dan RAID5 ivm de extra parity schijf.

Hoeveel groot is de kans dat er 2 schijven binnen %X uur sterven, en hoe groot is de kans dat er 3 schijven binnen %X uur sterven, en wat is het verschil daar tussen.

[Question Mark]

De risico's zijn klein en respectievelijk nog kleiner. Vliegen is statistisch gezien veiliger dan autorijden, toch gebeuren er sporadisch vliegtuigongelukken.

Het is de vraag hoe erg de core-business van je organisatie geraakt wordt tijdens uitval. Je meld dat ICT niet de core-business van je organisatie is, maar geloof mij maar dat er weinig uitgevoerd wordt met Exchange, ERP, SQL en je file-services plat.

Wijs in ieder geval het management op het evt. risico. Mocht men het risico acceptabel vinden en de boel gaat een keer plat, dan heb je het management gewezen op het risico en is het niet jouw verantwoordelijkheid. Klinkt misschien lullig en overbodig, maar regel dit wel.

Persoonlijk zou ik vier extra disken bestellen en gaan voor 4x Raid5 (3 databases + File-services) en één mirror voor alle Transaction Logs. Dit is in wezen het voorstel van Brahiewahiewa.

[ Voor 5% gewijzigd door Question Mark op 08-02-2006 15:09 ]

[2cents]

Om terug te komen op het teamen van je GBit NICs: Ik zou dat zeker doen in het kader van redundantie.
Zeker als je alle data op die Storage Server zet...