Onderwerp: Vraag over SAN in combinatie met MS SQL server 2005

Beste allen,

Ik heb het volgende idee voor een webfarm opzet.
In de webfarm komen in iedergeval deze 2 onderdelen:

- Een SAN (met eventueel een 4GPbs switch)
- Een MS SQL 2005 server.

Normaal (zonder SAN) zou ik de SQL server in een RAID 1 + RAID 5 configuratie zetten (5 disks total). RAID 1 voor OS en transition logs en RAID 5 voor de dbases.

Maar nu had ik het idee om beide (transL en dbases) op de SAN wegte schrijven, zodat op de SQL server alleen nog het OS op de local disks staat.
Op die manier heb ik niet veel disk nodig in de sql server en heb ik een veel schalbardere oplossing qua data middels de SAN.

Echter weet ik niet of de speed toereikend is, aanfgezien de SAN waar ik naar kijk, 7200RPM SATA II disks heeft.

Vraag 1:
Wat denken jullie; verlies ik juist snelheid tov de 15000 rpm SCSI disk in een normale local disk opzet, of is de 4Mbps + 7200 RPM SATAII SAN toereikend voor dit soort dataverkeer?

Vraag 2:
Stel dat dit toereikend is. Zou het dan verstandig / mogelijk zijn om doormiddel van de SAN Switch nog andere servers op de SAN aan te sluiten (bijvoorbeeld logfiles van een stats server of grote data directories van een Webserver?


Ik hoop dat jullie me kunnen helpen!

Alvast bedankt.

Mvgrt,

Sennia

Ook al gebruik je veel 7200 schijven de "trage" seek time niet veel afnemen. Deze is bij databases wel belangrijk dus of je moet de SAN inrichten met snellere schijven of het is geen goed plan.

Een grote cache kan natuurlijk ook helpen, alleen moet je dan niet vergeten een stevige backup batterij er bij de plaatsen.

Oorspronkelijk geplaatst door gjtje

Ook al gebruik je veel 7200 schijven de "trage" seek time niet veel afnemen. Deze is bij databases wel belangrijk dus of je moet de SAN inrichten met snellere schijven of het is geen goed plan.

Een grote cache kan natuurlijk ook helpen, alleen moet je dan niet vergeten een stevige backup batterij er bij de plaatsen.

Hoe zie je die grotere cache precies? Kunnen je dat iets meer uitleggen?
Dank

Je hebt tegenwoordig een nieuwe serie schijven met het dubbele cache onboard,

Vraag 1:

15k SCSI lokaal is stukken sneller dan je SAN opstelling. Je kan ze bijna niet vergelijken. Verwacht je echt zoveeel db's?

Ik weet niet waarvoor je de DB nodig hebt maar als je DB niet al te groot is dan kan hij met de juiste instellingen misschien wel volledig in het geheugen worden geladen en maakt de manier van opslag niet meer zoveel uit.

Hij had het over een webfarm, dus vraag me af of het wel allemaal in geheugen past.

Oorspronkelijk geplaatst door HY5

Vraag 1:

15k SCSI lokaal is stukken sneller dan je SAN opstelling. Je kan ze bijna niet vergelijken. Verwacht je echt zoveeel db's?

De vraag is natuurlijk, is lokale storage wel gewenst? Misschien dat hij op deze manier makkelijker backups wil maken?

Oorspronkelijk geplaatst door Wido

De vraag is natuurlijk, is lokale storage wel gewenst? Misschien dat hij op deze manier makkelijker backups wil maken?

Dat is inderdaad ook een goeie. Ik wil backups maken, en het liefst centraal.
De vraag is of dat qua performace echt nodig is.
Is het een zware last op de SQL server als je deze rechtstreeks backupt?
Od kun je beter de Array of SAN Backuppen? Od maakt het niet uit?

Voordeel aan een SAN vind ik is dat je de backups op de SAN regelt waardoor je client er totaal niets van merkt. Ook kan je daardoor je backups transparanter terug zetten en eventueel je hele SAN vervangen en daar die backup op terug zetten.

Natuurlijk kan dat ook met een losse server, maar nu ik een tijdje met een SAN/NAS werk wil ik echt niets meer anders.

Ik ben een stuk flexibeler met mijn storage, backups en uitbreiding dan ik voorheen was.

O, mijn front-end server is kapot? Nou dan start ik die service toch ergens anders? Dat is ook een voordeel dat je krijgt uit je SAN.

Wat voor SAN had je in gedachten? En hoe configureer je die vervolgens?
Het is een beetje appels met peren vergelijken op deze manier...

Het is mij nog niet helemaal duidelijk waarom je een SAN wilt gebruiken. Zeker gezien de kosten van een knappe SAN (met redundante paden, dubbele HBAs, et cetera).