Die häufigsten Fehler beim Kauf von Hardware für SQL Server

Der Kauf und die Konfiguration eines neuen SQL-Server-Systems können tückisch sein. Der SQL Server ist ein Produkt, das die darunterliegende Hardware intensiv nutzt, und seine Leistung ist davon abhängig, wie Sie Ihren Server konfigurieren – und vor allem davon, wie und auf welcher Hardware Sie die Storage-Subsysteme des Servers konfigurieren. In diesem Sinne stellen wir Ihnen hier einige der Top-Fehler vor, die beim Kauf von SQL-Server-Hardware häufig gemacht werden und die Sie unbedingt vermeiden sollten:

• Do-it-Yourself Server in Eigenbau: Bauen Sie Ihren eigenen SQL Server nicht aus Standard-Komponenten zusammen. Es sei denn, der Server ist nur als Maschine für die nicht-produktive Entwicklung vorgesehen. Server im Allgemeinen und SQL Server im Besonderen sind auf eng aufeinander abgestimmte Hardware-Komponenten angewiesen, wie Prozessoren, Chipsätze, Speicher-Controller-Karten und dergleichen. Für ein brauchbares System benötigen Sie deshalb auch spezielle Komponenten, die beispielsweise großer Hitze standhalten. Solche Komponenten wurden entwickelt, um mit spezifischen anderen Komponenten zusammen zu arbeiten. Das heißt nicht, dass es unmöglich ist, einen eigenen Server zu bauen. Aber es ist viel einfacher, einen bereits voll integrierten Server zu kaufen, der auch vom Hersteller unterstützt wird.
• Keine Leistungserwartungen haben: Sie können kein gutes SQL-Server-System bauen, wenn Sie nicht wissen, welche Last dieser Server zu bewältigen hat. Nein, das ist nicht ganz richtig. Natürlich können Sie das – aber Sie werden ihn immer entweder zu stark oder zu schwach bauen. Und beides ist zu teuer. Wenn Sie ihn zu schwach bauen, werden sie ihn so konfigurieren, dass er nicht genug Power für die Zukunft hat. Das bedeutet, das Sie gezwungen werden, Geld für Upgrades auszugeben (und abhängig von der Server-Erstkonfiguration ist ein Upgrade möglicherweise gar nicht möglich). Wenn Sie ihn zu stark bauen, geben Sie mehr aus als Sie tatsächlich benötigen. Nutzen Sie deshalb vorhandene Datenbanken, Anwendungen oder Anbieter-Benchmarks, um ein Gefühl dafür zu bekommen, wie viele Transaktionen pro Sekunde Sie erwarten können. Das ist die Basis, um die Hardware-Anforderungen einschätzen und die Größe der Hardware in etwa berechnen zu können.
• Kaufen Sie Festplattengröße, nicht Festplattenleistung: Es ist richtig, SQL Server brauchen oft viel Speicherplatz. Aber massenweise Storage ist nutzlos, wenn die Festplatten im Schneckentempo arbeiten. Wenn Sie eine Handvoll Laufwerke in ein RAID-5-Array einbinden, können Sie damit den Speicherplatz und die Redundanz bekommen, die Sie wollen. Aber wenn dieses Array die Bits nicht schnell genug von den Platten lesen und darauf schreiben, wird das zu einem zentralen Leistungsengpass für das ganze System werden. Wenn Sie keine schnellen Festplatten in der Größe, die Sie brauchen, verwenden, dann können Sie auch keinen SQL Server anbieten.
  Im Idealfall sollten die Datenbankdateien und die Transaktionsprotokolle auf verschiedenen Festplatten (oder Arrays) liegen, und der SQL Server sollte auf diese über verschiedene Kanäle zugreifen, wie über Festplatten-Controller-Karten oder Storage Area Network (SAN). Die tempdb-Systemdatenbank kann eine eigene Festplatte oder einen Array benötigen – besonders wenn sie stark ausgelastet ist.
• Die falsche RAID-Option wählen: RAID 5 ist beim Schreiben von Daten auf die Festplatte recht langsam. Die meisten RAID-Controller versuchen deshalb, dieses Problem durch die Zwischenspeicherung von Daten in den On-Controller-Memory zu überwinden (der in der Regel aus Sicherheitsgründen batteriegestützt arbeitet). Aber eine vielbeschäftigte SQL Server-Datenbank kann diesen Cache leicht füllen – was dann zu einem sicheren Engpass führt. In diesem Fall ist RAID 10 die Lösung. Es ist teurer als RAID 5, aber es verbindet Disk-Mirroring mit Data-Striping – und es bietet höhere Redundanz und schnelleres Lesen und Schreiben.
• Zu wenige Laufwerke kaufen: Wenn Sie X Gigabyte oder Terabyte an Speicherplatz brauchen, möchten Sie diesen normalerweise in möglichst vielen physikalischen Festplatten geliefert bekommen. Nur so können Sie sicher sein, den schnellsten Durchsatz zu bekommen. Der Grund ist: Mehr Festplatten im Server zur Verfügung zu haben – egal ob kapazitätsmäßg klein oder groß – ist besser als nur wenige zu haben, die dafür größer sind. Mit Striping (das sowohl von RAID 5 als auch RAID 10 unterstützt wird) verbessert jede zusätzliche Festplatte die Performance des SQL Server nur minimal. Möchten Sie zum Beispiel fünf 1-TB- oder zwanzig 250-GB-Laufwerke kaufen, werden die zwanzig Platten fast immer die fünf übertreffen (vorausgesetzt, sie werdem in einem Stripe-Array konfiguriert und die Laufwerke haben die gleiche Geschwindigkeits- und Übertragungsrate).
• Festplatten-Controller ohne Batterien verwenden: Wenn Sie auf Festplatten-Controller angewiesen sind, um Schreibanweisungen zu cachen – zum Beispiel in einem RAID 5-Array – sollten Sie sich vergewissern, dass er batteriebetrieben arbeitet. Kontrollieren Sie von Zeit zu Zeit den Server-Power-On Self-Test (POST) -Monitor des Servers, um sicherzustellen, dass diese Batterien (meist Lithium-Uhrenbatterien) noch genügend lange halten.
• Dem SAN blind vertrauen: Ein SAN ist auf die Storage-Frage nicht immer die perfekte Antwort. Sie müssen sicherstellen, dass es für einen schnellen Durchsatz konstruiert ist, und dass es der SQL Server nicht mit vielen anderen Servern und Anwendungen teilt, so dass sie alle um Bandbreite und Durchsatz konkurrieren müssen. Ein SQL Server braucht einen schnellen Speicherzugriff – das ist der größte Flaschenhals bei den meisten SQL Servern. Achten Sie auch darauf, dass Sie die Konfiguration Ihres SANs kennen (zum Beispiel RAID 5 im Vergleich zu RAID 10 – und vergessen Sie dabei nicht die oben genannten Fehler). Ebenso sollten Sie über den Durchsatz, den Direct-attached Storage (DAS) und andere Details gut informiert sein.
• Mit 32-Bit Software arbeiten: Dieses Problem gilt nicht so sehr für die Hardware, die heutzutage meistens als 64-Bit Hardware vorliegt, sondern vor allem für die Software. Auf einer 32-Bit-Version von Windows ist es für SQL Server schwieriger, mehr als drei GB Speicher zu addressieren. Der Server muss in diesem Fall einige Paging-Erweiterungen verwenden, die nicht so effizient sind wie der rohe Zugriff auf massenweise Memory. Wenn Sie 64-Bit-Hardware haben, sollten Sie auch ein 64-Bit-Betriebssystem darauf laufen lassen. Abgesehen davon, dass Windows Server 2008 R2 – und alle späteren Windows-Versionen – ohnehin nur mehr in 64-Bit-Versionen erhältlich sind.

Viele werden jetzt sagen, dass der Großteil dieser Probleme mit Storage zu tun hat. Dies ist in der Tat so. Storage ist derjenige Bereich bei SQL Servern, bei dem Administratoren sich tendenziell zu sehr auf die Größe konzentrieren. 

Dabei sind andere Faktoren mindestens ebenso wichtig, wie beispielsweise der Durchsatz. Dies gilt gerade für SANs, bei denen der Speicher so etwas wie „ein Service einer Private Cloud“ ist, der wie eine große magische Box am Himmel erscheint, wo die Daten leben.

Natürlich gäbe es zur SQL-Server-Leistung noch mehr zu schreiben als nur das Thema Storage, wie zum Beispiel Prozessor-Architektur und Server Memory. Hier kommt es auf die Details an, und die erzielte Leistung. 

In jedem Fall sollten Sie die genannten Fehler beim Kauf von SQL-Server-Hardware vermeiden – nur so erhalten Sie eine „gesündere“, „glücklichere“ – und vor allem schnellere – Maschine.

Über den Autor:
Don Jones ist Mitbegründer der Firma Concentrated Technology, Autor von mehr als 30 IT-Büchern und Referent auf zahlreichen weltweiten Konferenzen. Sie können Jones über seine Firmen-Website kontaktieren.

Folgen Sie SearchEnterpriseSoftware.de auch auf Twitter, Google+ und Facebook!