[Server 2003] Harddisk indeling MSSQL, IIS, 3 type disken

[Verwijderd]

Ik wil een Windows Server 2003 installatie gaan doen om te kijken wat logisch is qua gebruik met services en hardeschijf indeling.

Ik kan 3 raidsets aanmaken, 1 voor het OS, 1 voor MSSQL en 1 voor DATA, Sharepoint enzo.

Ik heb alleen het probleem dat de disken qua grootte en snelheid niet ideaal zijn, ik vraag hierom dus een objectieve mening van anderen.

Ik heb de volgende disks:

2x 18GB 15K
2x 36GB 10K
2x 72GB 10K.

Opzich zou de 18GB ideaal zijn voor het OS qua grootte, dit is alleen wat zonde van de snelheid en zal dus meer geschikt zijn voor MSSQL.

Of zal bij de applicaties die ik wil installeren een snelle schijf voor het OS ook wel handig kunnen zijn ?

Ik heb volgens mij nog wel ergens wat 9GB HD's liggen welke ook 10K en 15K zijn, met 9GB voor het OS zou ik het ook moeten kunnen redden, alleen vind ik het wat krapjes al ik eerlijk mag zijn.

Uiteraard spelen schrijf- en lees-acties een grote rol in welke schijf geschikt is voor welke applicatie, maar toch ben ik hier niet helemaal over uit.

Ik wil een beetje onderzoeken, stel je zou een webapplicatie met MSSQL draaien of deze databases echt snel groeien en 18GB wel voldoende is. Dit hangt natuurlijk ook van de applicatie af en hoeveel er gebruik van wordt gemaakt.

Wat zouden jullie doen met deze HD's en indeling ? Eventueel de 9GB's met 15K meegenomen in het idee voor snelheid op het OS.

Ik kan namelijk maar 6 HD's kwijt

[Question Mark]

Verwijderd schreef op donderdag 21 juni 2007 @ 18:30:
Wat zouden jullie doen met deze HD's en indeling ?

Ligt er een beetje aan wat de requirements zijn in het geval van een Disk/Raidset failure.

Als er absoluut geen data mag ontbreken uit je database na een crash, dan ben je al verplicht om je SQL database files en Transactional Log files op verschillende Raid Sets neer te zetten.

Stel dat de databases en logfiles op dezelfde Raid-set staan, en deze Raid-set valt uit (om wat voor reden dan ook). Dan kun je de laatste backup terugzetten and that's it. Alle data die na de backup ingevoerd is, ben je kwijt.

Stel dat je nu de database en logfile op aparte Raid-sets plaatst:

• Situatie 1: de Raidset met logfiles valt uit --> niets aan de hand want mijn database is nog volledig intact en alle data is nog aanwezig
• Situatie 2: de Raidset met de database valt uit --> Restore van de database, replay van de nog aanwezige logfiles (staan immers op een andere Raidset) en mijn database is weer up-to-date. Alle data is nog aanwezig.

Kies je voor de meest redundante oplossing, dan kom je al gauw uit op een onderstaande onderverdeling:

1. OS
2. Databasefiles / Sharepoint
3. Logfiles

Voor de rest zul je gewoon moeten kijken je benodigde I/O's voor je verschillende disken. En vergeet ook niet dat een toerental voor een disk niet 100 procent zaligmakend is.

[Verwijderd]

Ja dit is een goed idee.

De 72GB zijn trouwens ook 15K schijven, ok snelheid is niet alles maar toch.

10K zou dus snel zat moeten zijn voor MSSQL ? Ik zou dit juist op een snellere schijf willen zetten.

Het OS, kan dat nog steeds op 9GB drives of zal ik toch echt 18GB's moeten gebruiken voor OS only ? 9GB is wat aan de krappe kant als je het mij vraagt.

[Verwijderd]

OK, Ik ben er uit:

18GB 15K voor het OS
72GB 15K voor UserData

En ik denk er over:

36GB 10K voor MSSQL data

Ik zet de logfiles gewoon op de OS schijf, of op de userdata schijf.

MSSQL kan wel eens een probleem opleveren denk ik als ik van driveletter of partitie wil ga wisselen, dus D of E als vaste driveletter lijkt me handig.

D of E maakt weinig uit natuurlijk, waar op de controller ook niet.

en nu fijn slapen

[DoleBole]

uit oogpunt van snelheid zou ik altijd voor twee verschillende disksets voor SQL gaan (data en logs scheiden) en een aparte diskset voor het OS

wel opletten bij het aanmaken of restoren van de databases, anders komt alles weer gewoon op 1 schijf terecht

Zorg er ook voor, dat je voldoende geheugen in de machine stopt en dit ook dedicated toewijst aan SQL

succes