SQL Server 2k8R2 - Anforderungen an Netz und Server (mehrere hundert Zugriffe)

Hallo zusammen,

im Moment stehe ich vor einer echt guten Frage und Entscheidung, welche Anforderungen brauche ich?

Es geht um eine Kundeninstallation, eingesetzt werden soll SQL Server 2008R2 auf einem Windows Server 2008 R2.

Auf dem SQL wird eine Datenbank mit 3 Publikationen sein, es werden sich ca. 80 Clients mit dem Verleger synchronisieren (im schlimmsten Fall gleichzeitig - ich gehe aber höchstens von 40-50 gleichzeitigen aus), hinzu kommen noch 120 Clients die direkt (ohne Synchronisation) auf der Datenbank arbeiten.

Das arbeiten auf der Datenbank geschieht über eine seperate Software (keine Entwickler).

Nun halte ich mich an ein paar Fakten fest, was mir wichtig scheint:
- ausreichendes Netzwerk (min 1000mbit/s), was ist noch zu beachten damit das Netz nicht einbricht bei so vielen Zugriffen?

- SQL Server, macht der Server überhaupt so viele Verbindungen mit, oder gibt es hier eine Grenze wo er sagt - Ende?

- Platten im Server sollten hohe Schreibgeschwindigkeit haben

- Wie spielt der RAM hier mit?

- Was arbeiten die Prozessoren bei solchen Zugriffen?

Ich wäre super dankbar wenn ihr mir hier etwas helfen könnt, im Moment ist es für mich extrem schwer die Situation richtig einzuschätzen, bzw. in welchem Faktor die wachsende Anzahl eine Rolle spielt.

Grüße

normatel schrieb:

H
Nun halte ich mich an ein paar Fakten fest, was mir wichtig scheint:
- ausreichendes Netzwerk (min 1000mbit/s), was ist noch zu beachten damit das Netz nicht einbricht bei so vielen Zugriffen?

- SQL Server, macht der Server überhaupt so viele Verbindungen mit, oder gibt es hier eine Grenze wo er sagt - Ende?

- Platten im Server sollten hohe Schreibgeschwindigkeit haben

- Wie spielt der RAM hier mit?

- Was arbeiten die Prozessoren bei solchen Zugriffen?

Ich wäre super dankbar wenn ihr mir hier etwas helfen könnt, im Moment ist es für mich extrem schwer die Situation richtig einzuschätzen, bzw. in welchem Faktor die wachsende Anzahl eine Rolle spielt.

Grüße

Zum Vergrößern anklicken....

- naja 1gbit anbindung sollte dicke reichen...soviele zugriffe sind dass nun auch nicht
-> kannst aber zum spass die wan anfragen an ner anderen nic ankommen lassen als die lan anfragen...bringt nur selten was aber manchmal (bei deiner größe bezweifel ich das)
- sicher macht das der sql server mit, die anzahl ist ja...nicht so besonders hoch
- wieso sollten die platten eine hohe schreibgeschwindigkeit haben? Wie ist die wan bandbreite beim sync mit den verlegern (wenn ich das richtig verstanden hab)? Ist das system bei deinem kunden führend oder das beim verleger? Wenn deins, dann sollte die lesegeschwindigkeit eine größere rolle spielen als die schreibgeschwindigkeit
- wie meinst du wie der ram mitspielt? Viel hilft bei sql viel um die erklärung kurz zu halten...wie groß ist denn die datenbank, wie hoch die wachstumsrate, eher oltp oder olap?
- bei welchen zugriffen? Das kommt ganz auf die art der abfragen an und die gehen aus deinem post nicht heraus.

mal ein paar generelle tipps
- seperate platten/raids für je datendatei (mdf), logdatei (ldf), temp db (mdf) und temp db log (ldf), wenn möglich sollten auf diesen platten keinerlei andere daten liegen (KEINE)
-> natürlich immer eine kosten/resourcenfrage. Die log dateien (ldf) kann man am ehesten auf eine gemeinsame platte legen. Bevor man tempdb udn datendatei zusammenlegt sollte man lieber die log zur datendatei legen. Ist aber abhängig von dem was da so läuft.
- Definiere die Datenbankdateien und Logdateien ausreichend groß, so dass sie wärend des betriebs nicht erweitert werden müssen, das kostet nur zeit, perfomance und fragmentiert die dateien je nach konfig nur unnötig. Die automatische erweiterung die der sql server macht würde ich nur als notnagel sehen und als nichts anderes!
-> Sicher regelmässig damit die log nicht immer weiter wächst
- raid konfig sehr komprimiert widergegeben (top down auswahl nach perfomance)
raid 10
raid 0+1
raid 5
raid 6
raid 0
raid 1
-> wenn du viele lesezugriffe auf die datendatei hast kann trotzdem raid 5 besser als raid 10 geeignet sein. Für die TempDB ist aber in jedemfall eine hohe schreibgeschwindigkeit wichtig (die kann bei raid 1 besser sein wie bei raid 5 oder 6), bei den logs auch. Auflistung bezieht sich auf die brutto nutzbaren platten!
- ssd ist gold wert
- speicher, viel hilft viel...mehr als die db größe brauchst aber nie...i.d.R. reicht 1/3 dicke (1/5 ist oft auch genug)....3/4 sind nahe dem optimum aber nur in wenigen fällen wirklich gerechtfertigt.
- auf den platten auf denen die daten und logfiles liegen ntfs mit 64kb blöcken formatieren
-> bei der raid konfig sind 16, 32 ode 64 kb blöcke ideal (wenn unsicher nimm einfach 32kb, soviel kannste da net verliern)...das kommt aber auf das raid, die anzahl der platten und den controller drauf an -> muss man im zweifel testen.
- ist die maschine ein standalone db oder macht die noch was?
- werden ssis, ssas, ssrs auf der gleichen maschine genutzt?

Was wichtig ist zu wissen:
Wie sehn die abfragen aus? Sind das berechnungen (prozessorlast) oder sind dass einfach nur dumme "select *" (eher io last)?
Wie groß ist die db?
Wieviel platten stehn zur verfügung?
und teils die anderen fragen die ich oben gestellt hab.

Ansonsten kann man dir grad net soviel mehr sagen...die informationen sind dürftig und n sql server pflanzt man bei entsprechendem anspruch nicht einfach in die landschaft sondern plant und schaut was die anwendungen die drauf laufen sollen da so anstellen....

Andere frage, willst du das niemand machen lassen der sich damit n bisschen auskennt?