Für den
Betrieb einer SharePoint Farm ist ein funktionierender Microsoft SQL Server
unabdingbar. Ohne geht es nicht. Deshalb bin ich der Meinung, dass es für uns
Administratoren wichtig ist sich mit den Grundlagen des SQL Server vertraut zu
machen. Wer einen DBA im Haus hat, der ihm die Arbeit abnimmt, ist an dieser Stelle fein raus ;)
Der folgende Beitrag richtet sich daher vor allem an SharePoint
Administratoren, die keinen SQL Speziallisten zur Hand haben.
Über die
Installation und Konfiguration des Servers gibt es ausreichende Informationen.
Sei es auf den TechNet Seiten, in Blogs, Zeitschriften oder Bücher. Eine Situation die ich aber häufiger einmal antreffe ist, dass das Thema Performance der SharePoint Farm viel zu spät oder gar nicht betrachtet wird. Da bei einer SharePoint Farm die Leistungsfähigkeit des SQL Clusters, im besonderen die der Festplatten, maßgeblich
die Leistungsfähigkeit der SharePoint Farm beeinflusst, lohn es sich in jedem
Fall hier zu Überprüfen ob alles so ist wie es sein soll.
Natürlich gibt es bei einer SharePoint Farm noch eine ganze Reihe weiterer Stellschrauben um die Performance zu verbessern. Ziel in diesem Beitrag soll es aber
sein, die IO Leistung der Festplatten im SQL Server zu ermitteln. Dazu muss auf den Servern ein Last-Test durchführen und die durchschnittlichen Lese-
und Schreibegeschwindigkeit, die IOPS Leistung und Latenz erfasst werden.
Überwachung der Leistungswerte
Warum ist es
aber für den späteren Betrieb wichtig diese Werte im Vorfeld zu erfassen und zu
dokumentieren? Bei der Überwachung eines Servers kann die Überwachung in zwei
Kategorien unterteilt werden:
- Reaktiv
- Progressiv
Bei der
reaktiven Überwachung wird auf die Änderung eines Indikators reagiert und z.B.
eine Benachrichtigung versendet. Icinga ist so eine Lösung. Dabei werden in
festgelegten Intervallen ein oder mehrere Dienste überwacht. Wenn sich dieser
dann außerhalb der vordefinierten Parameter bewegt, wird Alarm ausgelöst.
Auf der
anderen Seite haben wir die progressive Überwachung. Progressiv bedeutet in
diesem Fall nicht, dass die Werte in der Überwachung immer weiter steigen,
sondern der Begriff bezieht sich auf den zeitlichen Verlauf der Überwachung,
also der fortlaufenden Überwachung. Dabei werden verschiedene Leistungswerte
eines Servers langfristig protokolliert. Dies wird gemacht um langfristige
Trends des Servers erfassen zu können. Die Windows Leistung Sammelungssätze
sind ein sehr gutes Beispiel hierfür. Erst durch die Langzeiterfassung können
wir erkennen potenzielle Probleme erkennen, dass z.B. die Netzwerkschnittstelle
über Monate hinweg immer mehr und mehr Daten transportieren muss und bald die
Kapazitätsgrenze erreicht ist.
Nun ist die Leistungsgrenze einer Netzwerkkarte verhältnismäßig einfach zu
ermitteln, da sich diese errechnen lässt. Eine 1Gbit/s Karte wird im Schnitt
nicht mehr als 100MB/s transportieren können. Wie sieht es aber bei den
Laufwerken aus. Auch hier könnten wir anhand der Datenblätter des Herstellers
des SAN bzw. der Platten ungefähr ausrechnen was unser System leisten kann. Bei
einem Festplattenspeicher spielen aber noch viel mehr Faktoren eine Rolle, welche sich
auf die Leistungsfähigkeit auswirken können. Es ist daher einfacher das System
aufzubauen und dann die Gesamtleistung, im Rahmen eines Lasttests, zu erfassen.
Diese Leistungsgrenze wird im Englischen auch als “Baseline” bezeichnet. Mit
Hilfe der Baseline können wir also in Zukunft, bei der progressiven Überwachung
der Server, feststellen ob unser System an seine Leistungsgrenze kommt.
Festlegen der Indikatoren
Um die
Baseline erfassen zu können, müssen wir überhaupt erst einmal festlegen, welche
Leistungswerte in Zukunft aussagekräftige Informationen über die Leistung
unseres Servers bereitstellen. Die Werte ermitteln wir mit Hilfe des Windows
Leistungsindikatoren. Wer noch nicht mit den Leistungsindikatoren gearbeitet
hat, dem empfehle ich die Artikel zur Einrichtung im TechNet vorher
durchzuarbeiten.
Erste
Schritte mit der Leistungsüberwachung (http://technet.microsoft.com/de-de/library/dd744567(v=ws.10).aspx)
IOPS
Die
Abkürzung IOPS steht für den englischen Begriff “Input/Output Operations” per
Second. Diese Angabe beschreibt die Fähigkeit des Datenbusses
Kommunikationsbefehle zwischen dem Betriebssystem und dem Speichermedium zu
transportieren. Die Angabe für sich alleine ist noch nicht sehr aussagekräftig,
denn es gibt viele verschiedene Faktoren die berücksichtigt werden müssen. Ein
wesentlicher Faktor ist die Größe der übermittelten Datenblöcke, welche bei
einer I/O Operation transportiert wird. Um z.B. 100 MB in 16 kB Blöcken zu
übertragen, muss das System doppelt so viele IOPS ausführen als wenn 32 kB
Blöcke verwendet werden.
| Indikator | Beschreibung |
| Durchschnittl. Warteschlangenlängenlänge des Datenträgers-Lesend | Die durchschnittliche Anzahl der Leseanforderungen, die für den gewählten Datenträger während des Abtastintervalls in der Warteschlange aufgenommen wurden. |
| Durchschnittl. Warteschlangenlängenlänge des Datenträgers-Schreibend | Die durchschnittliche Anzahl der Schreibanforderungen, die für den gewählten Datenträger während des Abtastintervalls in der Warteschlange aufgenommen wurden. |
| Lesevorgänge/s | Die Rate von Lesevorgängen auf dem Datenträger. |
| Schreibvorgänge/s | Die Rate von Schreibvorgängen auf dem Datenträger. |
Transportleistung
Mit der Transportleistung wird die Fähigkeit beschrieben eine Anzahl an Daten in einem Zeitraum zu transportieren. Diese Werte werden für gewöhnlich mit Bytes oder Megabyte pro Sekunde angegeben.
| Indikator | Beschreibung |
| Bytes gelesen/s | Die Rate, mit der Bytes während Lesevorgängen vom Datenträger übertragen werden. |
| Bytes geschrieben/s | Die Rate, mit der Bytes während Schreibvorgängen auf den Datenträger übertragen werden. |
| Mittlere Bytes/Lesevorgang | Die durchschnittliche Anzahl der Bytes, die während Lesevorgängen vom Datenträger übertragen wurden. |
| Mittlere Bytes/Schreibvorgang | Die durchschnittliche Anzahl der Bytes, die während Schreibvorgängen auf den Datenträger übertragen wurden. |
| Mittlere Sec./Lesevorgang | Die durchschnittliche Zeitdauer in Sekunden für das Lesen von Daten auf dem Datenträger. |
| Mittlere Sec./Schreibvorgang | Die durchschnittliche Zeitdauer in Sekunden für das Schreiben von Daten auf den Datenträger. |
| Teil-E/A/s | Gibt die Teilungsrate der E/As auf dem Datenträger an. Ein E/A kann geteilt werden, wenn Daten angefordert werden, die zu groß für einen einzelnen E/A sind oder wenn der Datenträger fragmentiert ist. |
Andere relevante Messwerte
Zusätzlich
zu den Indikatoren die sich mit dem Speicher System beschäftigen, ist es
ratsam auch die Indikatoren der CPU und ggf. der Netzwerkkarte zu
Protokollieren. Bei der CPU interessieren uns vor allem die Prozessorzeit (%),
die Menge der Interrupts/s und DPC in Warteschlange/s je Core. Bei intensiver
Last der Speichermedien sollte die Prozessorzeit nicht sonderlich ansteigen.
Dies könnte zum Beispiel beim Einsatz von iSCSI passieren, wenn der HBA kein
TCP Off-Load unterstützt. Dann nämlich muss die CPU den zusätzlichen TCP/IP
Overhead bearbeiten. Wenn iSCSI verwendet wird kann man die Netzwerkkarte, die
mit dem Target verbunden ist, mit in die Überwachung aufnehmen.
SQLIO
Nachdem
jetzt festgelegt wurde welche Werte wir ermitteln wollen, müssen wir uns noch
Gedanken machen wie wir Last auf das System bringen. Microsoft bietet uns hierfür
ein eigenes Tool an, welches auf den Downloadseiten kostenfrei heruntergeladen
werden kann.
Nachdem man
SQLIO installiert hat, befindet sich im Programme-Verzeichnis ein neuer Ordner
mit den Dateien. Da SQLIO von der Befehlszeile aus gestartet wird, öffnet man
am besten eine neue Eingabeaufforderung und navigiert in das entsprechende
Verzeichnis.
Parameter
Damit SQLIO
funktionieren kann, müssen noch einige Parameter konfiguriert bzw. bei Start
mitgegeben werden. Alle notwendigen Informationen, damit man brauchbare
Ergebnisse erzielen kann, sind in der Datei readme.txt nachzulesen.
Da SQLIO
immer nur ein Test zurzeit durchführen kann, muss man wenn unterschiedliche
Parameter getestet werden sollen, den Vorgang mit einer Batchdatei automatisieren.
Hierfür legt man am besten im Verzeichnis von SQLIO eine neue .bat Datei an und
öffnet diese zum Bearbeiten. In jeder Zeile schreibt man dann die Parameter mit
der man sein Test ausführen möchte. Beim Schreiben des Logs sollte man darauf
achten, dass diese unterschiedliche Namen erhalten. SQLIO überschreibt die
vorhandene Logdatei anstatt sie anzuhängen.
Beim festlegen der Größe der Testdatei, sollte man außerdem darauf achten, dass diese größer ist als der
im SAN eingesetzte Cache. Grade beim sequenziellen Lesen der Data können sonst
die Ergebnisse verfälscht werden.
...und Los
Sobald die Windows
Leistungsindikatoren konfiguriert sind und die Berichte aufgezeichnet werden, kann der SQLIO Batch gestartet werden. Das Ergebnis der Protokollierung kann zu kontrollzwecken ggf. ein zweites Mal gestartet werden. In jedem Fall sollte man die Leistungsdaten aufheben und in der Dokumentation des Servers protokollieren.
Fazit
Bevor eine
neue SharePoint Farm in Betrieb genommen wird, sollte die Ermittlung der gesamten
Leistungsfähigkeit des Datenspeichersystems erfolgen. Bei der
Problemverfolgung, können diese Informationen dem Administrator helfen, zu
verstehen wo ggf. ein Engpass vorliegt. Die Ermittlung der Leistungsfähigkeit
kann mittels SQLIO, einem Tool von Microsoft, kostenfrei erfolgen.
Zusätzlich
bietet der Einsatz von SQLIO die Möglichkeit, beim Server ein Burn-In Test durchzuführen. Dies sollte erfolgen, bevor Produktionsdaten eingespielt werden. Somit wird das Risiko gesenkt,
fehlerhafte Festplatten zu verwenden.
Weitere interessante Artikel zum lesen:
- Benchmarking SQL Server IO with SQLIO
- SAN Performance Tuning with SQLIO
- THE SQL Server Blog Spot on the Web
- Disk Subsystem Performance Analysis for Windows
