[SQL 2005] Beste raid config.

[Verwijderd]

Beste tweakers,

Ik zit met het volgende, op dit moment hebben we 2 sql 2005 servers. Beide servers staan in verschillende data-centers en deze worden nu beide in hetzelfde data-center geplaatst. Ik wil deze servers nu gelijk gaan clusteren omdat de performance toch al verre van goed is.

Wat heb ik reeds in bezit voor het bouwen van het cluster.
2 servers met:
Intel Xeon 5130 2GHZ
8 GB FBD667 ECC
4 * 147GB SCSI 10k U320
LSI Logic Megaraid 320-2x + 2x
Windows 2003 Standard Edition 64bit
SQL server 2005 Standard Edition 64bit

1 Dell Powervault 1000
tot 15 schijven
PERC 5/E supports RAID levels 0, 1, 5, 10 and 50

Nu wil ik een cluster maken zoveel mogelijk met de huidige middelen en met de aanschaf van zo min mogelijk dure hard- en software. Zelf zat ik te denken aan de volgende config:

2 keer SQL 2005 server met:
Windows 2003 Enterprise Edition 64bit
Server server 2005 Standard Edition 64bit
2 * 147GB SCSI 10k U320 in raid 1

1 keer Dell DAS
10 * 147GB SCSI 10k U320 verdeeld over 4 raids
PRIMARY DATA - RAID 10 (4 x 147GB)
DATABASE LOG - RAID 1 (2 x 147GB)
ARCHIVE DATA - RAID 0 (2 x 147GB)
TEMP DATABASE - RAID 10 (2 x 147GB)

Aan te schaffen:
2 * Windows 2003 Enterprise Edition 64bit
6 * 147GB SCSI 10k U320

Is dit een config die de juiste is of zijn er betere en/of goedkopere oplossingen?

ps. dit is de eerste keer dat ik een sql cluster ga opzetten en ik ben tot deze (mogelijke) config gekomen door het lezen van verschillende forums.

[_Arthur]

Als je support van Microsoft wilt behouden bij je SQL2k5 cluster, zou ik even langs de website: http://www.windowsservercatalog.com/ browsen en kijken of je cluster-oplossing wel certified is. Zoniet, kan je fluiten naar support indien je dat nodig hebt.

Maakt bovenstaande je niets uit, lijkt me de setup ok.

Hier heb je nog een korte beschrijving: http://www.sql-server-per...er_infrastructure_p1.aspx

[roberth]

RAID 10 zal je de beste performance geven. Daarnaast is één RAID set waarschijnlijk sneller omdat je dan de IO's spreid over meerdere disks. In een test van HP is dit naar voren gekomen, en wanneer je weinig schijven hebt is dit waarschijnlijk de beste keuze (http://h71028.www7.hp.com...P_final%20120105_Rev2.pdf)

Waarom wil je eigenlijk een cluster? Je schrijft dat je dat wilt omdat de performance verre van goed is, maar een cluster geeft je niet meer performance. Clustering is een High Availability oplossing. Het scheelt in ieder geval Enterprise licenties voor Windows 2003. En HA kan in SQL server ook met andere oplossingen, zoals Mirroring, Log Shipping etc.

[Verwijderd]

roberth schreef op vrijdag 01 februari 2008 @ 21:12:
RAID 10 zal je de beste performance geven. Daarnaast is één RAID set waarschijnlijk sneller omdat je dan de IO's spreid over meerdere disks. In een test van HP is dit naar voren gekomen, en wanneer je weinig schijven hebt is dit waarschijnlijk de beste keuze (http://h71028.www7.hp.com...P_final%20120105_Rev2.pdf)

Waarom wil je eigenlijk een cluster? Je schrijft dat je dat wilt omdat de performance verre van goed is, maar een cluster geeft je niet meer performance. Clustering is een High Availability oplossing. Het scheelt in ieder geval Enterprise licenties voor Windows 2003. En HA kan in SQL server ook met andere oplossingen, zoals Mirroring, Log Shipping etc.

Het gaat om een omgeving waar meerdere (druk bezochte) sites gebruik van maken vandaar dat ik ook gelijk kijk naar een High Availability oplossing. Clustering leek mij daar ideaal voor de andere mogelijkheden lijken mij minder ideale oplossingen omdat ik dan een hoop performance van m'n 2 severs onbenut laat.

Het is volgens jou dus niet de beste oplossing om met 10+ schijven voor een raid 10 verdeeld over meerdere raids te kiezen. Mij leek het zonde om minder kritieke logs en archive data op de raid 10 te zetten omdat dat duurder is dan om dat op bv. een raid 1 en 0 te zetten vandaar dat ik tot de meerdere raids oplossing gekomen was.

[FragFrog]

De vraag is of je alle sets evenveel gaat gebruiken. Je database log array zal bijvoorbeeld veel minder leesacties hoeven te doen dan je primary data array. Als je deze zou combineren kun je in theorie snelheidswinst zien doordat waar nu van maximaal 4 schijven gelezen kan worden je dan van 6 schijven kan lezen. Als je dit doortrekt wordt het eigenlijk ook wel logisch: 10 disks in raid 1+0 zijn doorgaans sneller dan 4 disks in dezelfde config.

Aan de andere kant is het wel een grotere array om te rebuilden in geval van een goede crash waardoor je downtime als er iets misgaat ook groter wordt, heb je kans dat je database leesrequests zitten te wachten op de logschrijf requests - al hangt dat ook af van je controller, diskcaches, etc.

Uiteindelijk blijft het natuurlijk een beetje giswerk, benchmark anders de verschillende config's, zowel met array bench tools als met applicatie benchers, dan zie je ook direct waar de bottlenecks liggen

[ Voor 12% gewijzigd door FragFrog op 04-02-2008 00:47 ]

[GoeGie]

Even een opmerking...
Ik zie dat je een cluster wilt maken van 2 servers.
Ben je van plan dit cluster binnen 2-3 jaar uit te breiden naar meer dan 2 servers?

Zo ja, neem SQL 2005 Enterprise Edition
Zo nee, én je hebt geen behoefte aan de Enterprise features (partitionering o.a.) kan kun je volstaan met SQL 2005 Standard Edition.

Wat betreft Cluster configuratie.. check idd de site of je optie ondersteunt wordt.
Voro de Diskconfiguratie, moet je kijken wat voor soort applicaties erop draaien.
Als je applicaties heb met veel lees en weinig schrijg, dan kun je voor je data volume volstaan met een Raid 5/6 config. Neem voor de logfiles een RAID 0+1 zodat je daar geen problemen in I/O zult hebben. Daarnaast zou ik ook nog een aparte set aanmaken voor de TEMP Databases. Of dit op een Raid 1 of Raid 0+1 set moet zijn, is afhankelijk van je database gebruik.

[ Voor 44% gewijzigd door GoeGie op 04-02-2008 11:31 ]

[BCC]

roberth schreef op vrijdag 01 februari 2008 @ 21:12:
Waarom wil je eigenlijk een cluster? Je schrijft dat je dat wilt omdat de performance verre van goed is, maar een cluster geeft je niet meer performance. Clustering is een High Availability oplossing. Het scheelt in ieder geval Enterprise licenties voor Windows 2003. En HA kan in SQL server ook met andere oplossingen, zoals Mirroring, Log Shipping etc.

Inderdaad. Meestal is er veel meer te halen door indexen op je database, caching, slow query analysing etc. Clustering doe je alleen voor availablitiy of bijvoorbeeld bij een data-aggregatie database en een reporting database. Maar we drijven af .

In basis heeft je raid eigenlijk te maken met de opzet van je applicatie. Heb je veel reads of heb je veel writes? En: moet het vooral veilig of vooral snel? Als je een replicator hebt zodat die alle selects kan doorrammelen zou ik puur voor snelheid gaan. Wil je graag high availablity, dan niet

[ Voor 18% gewijzigd door BCC op 04-02-2008 11:55 ]

[Verwijderd]

BCC schreef op maandag 04 februari 2008 @ 11:45:
[...]

Inderdaad. Meestal is er veel meer te halen door indexen op je database, caching, slow query analysing etc. Clustering doe je alleen voor availablitiy of bijvoorbeeld bij een data-aggregatie database en een reporting database. Maar we drijven af .

In basis heeft je raid eigenlijk te maken met de opzet van je applicatie. Heb je veel reads of heb je veel writes? En: moet het vooral veilig of vooral snel? Als je een replicator hebt zodat die alle selects kan doorrammelen zou ik puur voor snelheid gaan. Wil je graag high availablity, dan niet

De database optimalisatie is al gedaan dus daar valt geen winst meer te behalen op een beetje caching na alleen daarvoor moeten de programmeurs aan het werk gezet worden.

Het probleem wat de applicaties betreft is dat er meerdere databases op draaien waar de een wel veel schrijf bewerkingen uitvoert en de ander niet. Ik zou hierdoor wel moeten kiezen voor een raid 10 ik twijfel nu alleen nog om voor een grote raid 10 te gaan of verschillende raids voor de verschillende data.

Ik lees hier ook veel verschillende berichten over, de een zegt dat een raid 10 met bv. 10 schijven veel sneller werkt als er een met 4 schijven. Ik heb ook gelezen dat alles sneller werkt op het moment dat je de tempdb op andere fysieke schijven zet dan de log ed. Maar levert dit meer snelheid winst op dan de hogere snelheid van een raid 10 met 10 schijven ipv 4

[WimB]

Ik weet niet of het binnen het budget past, maar lees het laatste deel van deze review eens door: http://www.ssdisk.eu/benchmark_pc_extreme_raid.php

Gaat over MTRON SSD schijven in een MYSQL-server bij PCextreme B.V.

[BCC]

WimB schreef op dinsdag 05 februari 2008 @ 08:46:
Ik weet niet of het binnen het budget past, maar lees het laatste deel van deze review eens door: http://www.ssdisk.eu/benchmark_pc_extreme_raid.php

Gaat over MTRON SSD schijven in een MYSQL-server bij PCextreme B.V.

Klinkt veel belovend, maar ik zou het nu nog absoluut niet in durven zetten voor een productieomgeving.

[Verwijderd]

BCC schreef op dinsdag 05 februari 2008 @ 19:30:
[...]

Klinkt veel belovend, maar ik zou het nu nog absoluut niet in durven zetten voor een productieomgeving.

Komt nog eens bij dat de kosten zo bijna niet te doen zijn, maar veel belovend is het zeker. Hier op de zaak zijn we wel aan het kijken naar laptops met SSD en hier durf ik het wel mee aan, feit blijft wel dat je nu het volle pond betaald.

[Verwijderd]

Na het een en ander uitzoeken ben ik tot de conclusie gekomen dat het in onze situatie het best is om 2 servers standalone te draaien.

De DB's van deze 2 SQL 2005 servers mirror ik dan naar een derde backup server mocht een van de 2 servers uitvallen dan neemt deze backup server de DB's over van de uitgevallen server.

Ik vraag me nu alleen af of het mogelijk is om de databases van een 64 bit machine te mirroren naar een 32 bit machine?

Ik heb hier op GOT en google gezocht maar geen info hierover gevonden.