SQL Server - Hardware spez. Raid Substytem

[substyle 20]

Hallo Leute,

 

ich stehe erstmals vor der Aufgabe einen SQL Server für mehr als 5 Instanzen

zu Planen. Es muss leider eine Maschiene bleiben - daran führt kein Weg vorbei.

 

Hinein soll das "übliche" also:

 

Dual Xeon

Min. 4-8 GB RAM

Controller mit min. 128MB RAM & Akku

15k u/Min SCSI Platten in 64k (8 * 8k pages) auf NTFS

 

Trotzdem stelle ich mir die Frage nach dem Raid-Subsystem:

 

Ich hatte für die Datenbanken einen RAID 10 im Blick.

Beim OS (W2k3) wohl ehr einen RAID 1 (Mirroring)

 

Das sind schon 6 HDDs ! :D

 

Die Datenbanken wollte ich am liebsten noch von den Transaction Logs trennen

(wegen der random bzw. sequenziellen I/O der Datentypen Datenbank / Logs)

 

Und genau hier stellt sich mir die Frage nach dem optimalen RAID für die Logs.

 

Kann mir vielleicht jemand aushelfen der schon Erfahrung auf diesem Gebiet sammeln

konnte ? Für jeden Tipp wäre ich sehr dankbar.

 

Grüße

 

subby

[phoenixcp 10]

Da würde sich ein RAID 10 auch am besten machen. Also nochmal 4 Platten dazu, macht dann 10. :)

 

Was spricht gegen eine Aufteilung der 5 Instanzen auf mehrere Server?

Wie groß sind denn die DB's und was ist die zu erwartende Last auf den einzelnen DB's? Evtl. wird bei dir der RAM oder die vorhandene Prozessorleitung ein Problem werden.

[substyle 20]

Die Last ist immo noch das Problem. Sie lässt sich nur schwer vorraussagen.

(Hängt mit Firmeninternen Entscheidungen zusammen - die wars***einlich mal

wieder am 24.12. um 17.15 Uhr kommen)

 

Der Server wird jetzt in der allgemeinen "In diesem Jahr noch Geldaugeben"

Panik angeschafft werden müssen. :rolleyes:

 

Ich würde vom reinen Design auch vorschlagen mehrere Server zu nehmen,

das Unternehmen jedoch argumentiert mit Platzmangel im Serverraum.

Was ich auch, nach einer Besichtigung des ganzen, gut verstehen konnte.

 

Umbauten sind wohl erst mitte bis ende kommenden Jahres geplant (neue Räumlichkeiten)

 

Zu den DBs, da haben wir Lohn & Gehaltssachen (werden ehr wenig gebracuth) dafür aber

monatlich sehr hat beansprucht , zwecks Auswertungen etc.

Dann WaWi , die leider sehr unsauber programmiert ist und den Server ziemlich beansprucht.

Zusätzlich eine Dokumentation Software - dort machen vor allem Statistische Auswertunge

in Datensätzen zu 10000den "Sorgen" die recht oft gefahren werden.

Eine saubere Indexierung wird hier noch viel Arbeit fordern ..

 

Es ist alles auch Zeitlich schwer zu erklären - nur soviel - es treten heftige belastungen auf,

diese jedoch zeitlich sequentiell versetzt. Also gleichezitiges arbeiten auf vielen Instanzen

wird sehr selten der Fall sein.

 

Daher hatten ich auch an eine Dual Lösung gedacht, mit Medium Speicheraussattung.

Mann muss hier auch bedenken das so ein mittelständisches Unternehmen nicht endlos

für Server zu zahlen in der Lage ist (Preisdruck)

 

Bleibt die Frage, welcher Hersteller hat da jetzt ein gutes Angebot, 10 Platten sind ja

immerhin ein enormer Kostenfaktor !

 

subby

[phoenixcp 10]

Fraglich ist aber vorallem die Größe der DB's. Wenn du ne halbwegs akzeptable Performance haben willst, dann sollte der Server in der Lage sein, alle DB's gleichzeitig im Hauptspeicher zu halten. So bald er anfängt zu swappen, geht der Durchsatz massiv nach unten.

 

Allerdings habe ich nach deinen Ausführungen noch nicht ganz verstanden, warum du 5 Instanzen fahren willst. Reicht nicht eine Instanz mit den 5 DB's dann auch aus? Ansonsten wird die Locking-Problematik zwischen den Instanzen auf die DB's und die Logs auch noch zum Problem.

 

Was hast du für ne Backupstrategie angedacht? Wie soll der Sicherungsmodus der DB's aussehen? Simple? Dann werden die Logs nicht sehr groß. Full? Dann wird die Loggröße extrem zunehmen....

 

Alles Problemstellungen, die man schon vor der Anschaffung und Implementierung des Servers durchdenken sollte.

 

BTW: Was mir grade noch einfällt: Wenn das Geld eh grade raus muss, warum dann nicht gleich vernünftig investieren und nen Active-Active-Cluster bauen, dann kannst du die Last auf zwei Maschinen verteilen.

[substyle 20]

Arg, schrub ich da 5 Instanzen ?

Ich meinte 5 Datenbanken .. :o allerdings auf 2 Instanzen

wegen der SQL Versionen. 3x SQL 2k - 2x SQL 7

 

Locking ist mir ein Begriff, aber bei 2000 sollte der deadlock fall doch eigentlich

nicht mehr vorkommen. Muss aber gestehen das ich da ehr aus der theorie spreche.

 

Die Backupstrategie - gutes Theam für morgen .. :eek:

Die drei 2k SQL haben ca. ein Größe von 3,6 bis 5,9 GB hier kann ich problemlos full sichern.

Die SQL 7er sind ziemlich groß, müssen aber auch nicht so häufig gesichert werden, da die

Updates nur wöchentlich passieren.

Ich werde wie gesagt morgen mal schauen was ich mir da ausdenken kann. Kommenden

Montag habe ich die Server dann das erste mal unter den Fingern und kann mal genaueres

auswerten, um zu schauen wohin es geht.

 

Thema Active-Active Cluster:

 

Schöne Idee - wenn ich das vorschlage - dann kommen lange Gesichter :p

Ich müsste das mal durchrechnen - wie gesagt gut Idee, nur mal schauen wie der

Kostenrahmen gestrickt ist, ich muss halt zwei alternativen planen und vorlegen.

 

subby

[dippas 10]

Hallo Subby,

 

schau doch mal bei Thomas Krenn nach.

 

Da würde ich mir enen 4 oder 5 HE Intel-Server konfigurieren.

 

Ich habe das mal mit deinen Angaben gemacht und komme auf knapp 8500 Euronen

 

Dual Xeon 3.2, 4 GB, 10 x 73 SCA 15k, separater Raidcontroller, ohne OS, AIT4

 

Unser Exchange läuft auf einem solchen System und - naja, was soll ich sagen - das Ding spielt sich an den ...... rum ;)

 

Wir haben auch einen DB-Server (Oracle, 5 Datenbanken) mit 4 GB, allerdings "nur" 6 Platten, Dual Xeon 2.4 HT -> hat auch Langeweile

 

Ja und dann haben wir noch einen SQL 2000 auf einer 2 x 2,4 Liter Xeon HT Kiste, 4 GB, 5 x SCA Platten -> auch da eher Ruhe im Schacht.

 

Sicherlich muss man bedenken, dass wir nun nicht gleich mit 1000 Leuten darauf arbeiten und auch nicht Hammerauswertungen mit zig Datensätzen fahren ;)

 

Vielleicht hilft Dir das ja als "Orientierung".

 

Ich persönlich würde vermutlich bei 4 GB bleiben -> dann reicht auch W2k3-Sandart ;) und das Plattensubsystem optimieren.

 

Will meinen: Raid 1 Spiegel-Paare für die einzelnen Laufwerke (c, d, e etc.) und die einzelnen "Komponenten" (Datenbank, Logs etc.) auf die Spiegel verteilen. Wenn die Datenmenge es zulässt, könnte ich mir vorstellen, dass 36er Platten (komplett oder in Teilen) prima sind -> macht die sache preislich günstiger ;)

 

Bei den Plattenzugriffen ist es ja nach Adam Riese und Eva Zwerg so, dass ein Zugriff auf eine Platte mit 2 Partitionen (beisp. Logs und Datenbank) langsame ist, als auf 2 physikalisch einzelnen Platten. Da könnte ein Gewinn bei rausspringen.

 

grüße

 

dippas

[phoenixcp 10]

Moment: jetzt muss ich nochmal intervenieren!

 

Du willst SQL Server 2000 und SQL-Server 7 parallel betreiben? Auf einer Maschine?

Mal ganz abgesehen davon das ich das auf keinen Fall tun würde, aber bist du sicher das das geht?

 

Wo liegt das Problem, die 7er DB's nach 2k zu migrieren?

 

6 GB haben alleine die 3 drei 2k-DB's, dann schreibst du das die beiden 7er sehr groß sind. Ich veranschlage da mal grob 8 GB pro DB (berichtige mich, falls du korrekte Zahlen hast).

 

Damit wäre wir bei 22 GB nur für die DB's. Wenn du ne entsprechende Performance haben willst, dann sollte der Server alle DB's im Hauptspeicher halten können. Sprich 22 GB Hauptspeicher für die Datenbanken, etwa 10 GB Reserve für "Blähungen" der DB's in Extremsituationen und dann noch 1 bis 2 GB für Windows. Damit wären wir bei sage und schreibe 33-34 GB RAM, die da als Anforderung stehen. Oder willst du, das der Server sich zu tode swappt? Glaub mir, das macht keinen Spaß, das seh ich hier grade bei mir im Testnetz.

[dippas 10]

Damit wäre wir bei 22 GB nur für die DB's. Wenn du ne entsprechende Performance haben willst, dann sollte der Server alle DB's im Hauptspeicher halten können. Sprich 22 GB Hauptspeicher für die Datenbanken, etwa 10 GB Reserve für "Blähungen" der DB's in Extremsituationen und dann noch 1 bis 2 GB für Windows. Damit wären wir bei sage und schreibe 33-34 GB RAM, die da als Anforderung stehen. Oder willst du, das der Server sich zu tode swappt? Glaub mir, das macht keinen Spaß, das seh ich hier grade bei mir im Testnetz.

 

Naja, bleiben wir mal ein wenig realistisch ;)

 

Die Größe der Datenbank muss nicht zwangsläufig mit dem Speicherbedarf korrespondieren. Du hast zwar Recht, dass eine Datenbank im Hauptspeicher die Performance enorm nach oben schraubt, aber es ist ja nun auch so, dass die nicht benötigten Daten einer Datenbank auch nicht geladen werden, bzw. die nicht mehr benötigten wieder rausgeworfen werden.

 

Interessant wäre hier die Antwort auf die Frage:

 

Wie ist denn die momentane Speicherauslastung bei der vorhandenen SQL-Installation?

 

grüße

 

dippas