Microsoft SQL Server 2008 R2 im Design

Transkript

1 The power to do more Lösungsübersicht Microsoft SQL Server 2008 R2 im Design Neuheiten bei SQL Server 2008 R2 Hyper-V mit Live- Migration durch Cluster Shared Volumes erhöht die Anwendungsverfügbarkeit und -flexibilität in vielen Wartungsszenarien. Argumente für eine Virtualisierung von Microsoft SQL Server 2008 R2 auf Hyper-V Die Virtualisierung ermöglicht Einsparungen beim Stromverbrauch, einen flexibleren Betrieb und eine höhere Anwendungsverfügbarkeit. Einige der wichtigen Hyper-V Funktionen umfassen eine erweiterte Auslastung der Serverhardwareressourcen durch einen dynamischen Arbeitsspeicher und eine erhöhte Verfügbarkeit der virtualisierten Rechenzentren durch Verbesserungen wie die Live-Migration. Richtlinien und Planungsüberlegungen zur Dimensionierung von SQL Servern Wie viel Arbeitsspeicher wird benötigt? Wie sollen die Festplatten konfiguriert werden? Microsoft SQL Server 2008 R2 Microsoft SQL Server 2008 R2 ist eine vollständige Suite einsatzbereiter Technologien und Tools für Unternehmen, die Mitarbeiter dabei unterstützen, Informationen bei niedrigsten Gesamtbetriebskosten optimal zu nutzen. Neuheiten bei SQL Server 2008 R2 Hyper-V mit Live-Migration durch Cluster Shared Volumes erhöht die Anwendungsverfügbarkeit und -flexibilität in vielen Wartungsszenarien. Das neue SQL Server Steuerpunkt-Dashboard gibt einen Überblick über die Auslastung und Verstöße gegen die Richtlinien. SQL Server 2008 R2 unterstützt Datenbankadministratoren bei der Automatisierung und Vereinfachung gängiger Aufgaben mit der neuen Datenebenenanwendung, einem Element, das alle von einer Anwendung verwendeten Datenbank- und Instanzobjekte enthält. Neue Datenanalysefunktionen für Self-Service-BI, wie das PowerPivot Add-In für Microsoft Excel und Microsoft SharePoint Server 2010, ermöglichen Benutzern die Erstellung von interaktiven Berichten und das gemeinsame Arbeiten an diesen sowie die Analyse von großen Datenmengen in Excel. SQL Server 2008 R2 bietet eine sofortige Self-Service- Berichterstellung mit dem verbesserten Report Builder 3.0. Argumente für eine Virtualisierung von Microsoft SQL Server 2008 R2 Komplexe Datenbankrechenlasten können mithilfe der Virtualisierung einfacher konsolidiert werden. Welche Produkte auch dafür verwendet werden, die Virtualisierung ermöglicht einen niedrigeren Stromverbrauch, einen flexibleren Betrieb und eine höhere Anwendungsverfügbarkeit.

2 Die Virtualisierung von Microsoft SQL Server 2008 R2 bietet einige zusätzliche Vorteile. An erster Stelle ermöglicht SQL Server zusätzlich zum Host-Clustering die Einrichtung eines Gast-Clustering. Dadurch steht eine zusätzliche Hochverfügbarkeitsebene neben dem Host-Clustering bereit. Mit der Virtualisierung von SQL ist die notwendige Flexibilität verfügbar, um virtuelle Maschinen entsprechend der sich ändernden Geschäftsanforderungen auf verschiedene physische Maschinen zu verschieben. Argumente für eine Virtualisierung von Microsoft SQL Server 2008 R2 auf Hyper-V Integrierte Virtualisierung und niedrigere Gesamtbetriebskosten: Die integrierte Architektur von Windows Server 2008 R2 SP1 mit Hyper-V macht die Investition in zusätzliche Hypervisoren überflüssig. Einige der wichtigen Hyper-V Funktionen umfassen eine erweiterte Auslastung der Serverhardwareressourcen durch einen dynamischen Arbeitsspeicher und eine erhöhte Verfügbarkeit der virtualisierten Rechenzentren durch Verbesserungen wie die Live-Migration. Signifikante Leistungssteigerung mit Hyper-V: Das Forschungsunternehmen für Drittanbieter, ESG, prüfte Hyper-V mit Microsoft SQL Server 2008 R2 und fand heraus, dass SQL Server auf 88 % der physischen Server der Leistung einer einzigen virtuellen Maschine entsprachen und auf OLTP-Transaktionen pro Sekunde skaliert werden konnten. Durch Konsolidierung der SQL Server Anwendungsrechenlasten auf einem physischen Server erhöhte sich die Leistung bei geringen Reaktionszeiten. durch die Verschiebung auf eine virtuelle Maschine zu verstehen. Datenbankspiegelung: Auf mehreren SQL Servern befinden sich Kopien eigener Datenbanken sowie replizierte Kopien der Datenbanken von anderen Servern. Bei einem Serverausfall übernehmen die Server, auf denen sich die passiven Kopien befinden, die Rechenlast, bis die Ressource wieder online geschaltet wird. Für diese Methode ist eine Host-zu-Host-Replikation und kein gemeinsam genutzter Massenspeicher erforderlich. Zwar gibt es Kostenvorteile, aber es müssen mehr als doppelt so viele Festplatten für eine ausreichende Verfügbarkeit erworben werden, da bei jeder Transaktion mehrere Kopien von jeder Datenbank mindestens zweimal geschrieben werden müssen. Dieses Modell entspricht dem von Exchange DAG weitestgehend. SQL Server Clustering Bei diesem Modell wird gemeinsam genutzter Massenspeicher implementiert, es muss aber nur eine Datenbank-Kopie vorhanden sein. Die Verfügbarkeit wird dadurch erzielt, dass die Server in der Gruppe auf die Datenbank zugreifen können. Wird ein Knoten unterbrochen, können die anderen aktiven Knoten die Rechenlast übernehmen oder ein dedizierter passiver Knoten wird erweitert, dessen Aufgabe die Übernahme der Rechenlasten bei möglichen Ausfällen ist. Da diese Hardware nur erworben wird, um die Leistung bei einem Ausfall aufrecht zu erhalten, wird sie häufig lange Zeit nicht genutzt. SQL (aktiv) Durchgängige Verwaltung mit System Center: Mit System Center Server Management Suites (beispielsweise ECI, SMSE oder SMSD) erhalten Unternehmen eine durchgängige Verwaltungslösung für die Bereitstellung eines SQL Servers in einer gemischten physischen und virtuellen Umgebung für ultimative Flexibilität. SQL (aktiv) BS BS SQL (passiv) BS SQL Server Bereitstellung Die Migration eines SQL Servers von einer physischen auf eine virtuelle Maschine wird ähnlich wie eine Migration von Exchange durchgeführt. Es müssen Betriebssystem, Protokolle und einige Datenbanken migriert werden. Das Verfügbarkeitsmodell für SQL Server unterscheidet sich jedoch, da es einen gängigeren Backend-Cluster und/ oder Modelle zur Datenbankspiegelung nutzt. In diesem Abschnitt werden einige Aspekte der Verschiebung von SQL Maschinen von physischen auf virtuelle Maschinen erläutert. SQL bietet zwei Hauptmethoden der integrierten Verfügbarkeit: Clustering und Datenbankspiegelung. Dieses Vorwissen ist wichtig, um die Veränderungen Herkömmlicher SQL Cluster Was ändert sich bei der Umsetzung der Virtualisierung? Im Folgenden soll die Umsetzung der Hochverfügbarkeit in virtuellen Umgebungen erläutert werden und es werden einige Ressourcen für die Dimensionierung von SQL beschrieben, für den Fall, dass Ressourcen im Voraus erarbeitet werden müssen.

3 Hochverfügbarkeit von SQL auf einem Hypervisor Da bereits ein Cluster auf Hypervisor-Ebene verwendet wird, ist es die beste Entscheidung, das SQL Spiegelungsmodell abzuschaffen und die Clusterfunktionalität optimal zu nutzen. Es gibt zwei grundsätzliche Möglichkeiten, vorzugehen: 1. Der Hyper-Cluster übernimmt die Arbeit: Wenn bei einem Ausfall einige Minuten bis zum Neustart der virtuellen SQL Maschine auf einem wartenden Host überbrückt werden können, müssen Sie die virtuelle Maschine nur als hochverfügbar festlegen und der zugrunde liegende Hypervisor-Cluster übernimmt die Hochverfügbarkeit. Dies ist das einfachste Modell, und bei einem RTO-Fenster von einigen Minuten bis einigen Stunden funktioniert es einwandfrei. Wenn SQL zu fast 100 % verfügbar sein muss, wird die zweite Möglichkeit empfohlen: 2. Cluster-im-Cluster: Diese Idee ist etwas komplizierter, das Gast-Clustering ist jedoch genau das, wonach es klingt. Bei zwei oder mehr virtuellen Maschinen wird ein separates gemeinsam genutztes Volume auf dem SAN- Speichersystem nur für ihre Daten freigegeben und ein übergeordneter Cluster, der sich auf dem bereits vom Hypervisor erzeugten Cluster befindet, erzeugt. Vielleicht gehen Sie davon aus, dass das virtuelle Netzwerk bereits vom vorhandenen Hypervisor in einem Cluster zusammengeführt wurde. Dieser Vorgang umfasst jedoch nur die Betriebssysteme, die auf den zugehörigen Maschinen ausgeführt werden, und nicht die damit gespeicherten Daten. Daher sind die Daten bei einem Ausfall möglicherweise nicht vollständig durch einen sofortigen Cut-over oder einen anderen automatischen Sicherungsprozess geschützt. Durch die Kombination des vorhandenen Hypervisors und dem Cluster der virtuellen Maschinen selbst können Unternehmen von den Vorteilen beider Möglichkeiten profitieren: Failover auf Betriebssystemebene und Cutover auf Datenebene. Geclusterte virtuelle Maschinen (VMs) BS BS BS BS BS BS HyperVisor HyperVisor Planung virtueller Maschinen auf SQL Servern Die Dimensionierung des Platzbedarfs einer virtuellen SQL Maschine scheint eine leichte Aufgabe zu sein, aber da der SQL Server üblicherweise den höchsten Ressourcenverbrauch in der Organisation hat, kann die Kapazitätsplanung schwierig werden, insbesondere bezüglich Hochverfügbarkeits- und verteilter Rechenlastszenarien. Genau wie bei Exchange beginnt die Planung mit dem DPACK, um zu verstehen, welche Ressourcen für den SQL Server notwendig sind. Das DPACK ist besonders hilfreich für SQL und Exchange, weil es nicht nur E/ A- und CPU-Leistungsanforderungen sondern auch Failoverszenarien berücksichtigt. So wird sichergestellt, dass für die Maschine, auf der der SQL Server ausgeführt wird, ausreichend Platz an anderer Stelle des Clusters verfügbar ist, um die Ressource zu übernehmen und so das Risiko einer reduzierten Leistung während Ausfallzeiten zu minimieren. Dimensionierung von Microsoft SQL im Design Wie viel Arbeitsspeicher wird benötigt? So viel Arbeitsspeicher wie sich das Unternehmen leisten kann. Das Abrufen von Daten aus einem Arbeitsspeicher ist deutlich schneller ( mal schneller) als von einer Festplatte. Der Speicher mit wahlfreiem Zugriff (RAM) reduziert die Abhängigkeit von Festplatten und so die E/A-Anforderungen. Die allgemeine Empfehlung lautet 2 GB für das Betriebssystem und 1 GB zusätzlich je Abfragen/Sekunde. Unternehmen sollten sicherstellen, dass die 64-Bit Edition von SQL verwendet wird, um von diesem hohen RAM zu profitieren. Wie sollen die Festplatten konfiguriert werden? Festplatten stellen üblicherweise einen Engpass in einer größeren Datenbank dar. Unternehmen sollten die Festplatten mit den höchstmöglichen Drehzahlen erwerben (derzeit maximal /min verfügbar). Raid 5 und Raid 6 sind zu vernachlässigen, außer der Prozentsatz der Datenbank-Lesevorgänge liegt bei weit über 90 %. Die meisten OLTP-Datenbanken liefern die beste Leistung auf Raid 10. Gast-Clustering

4 Es sollte, falls möglich, SSD für temporäre Datenbanken genutzt werden. RAID ist für eine temporäre Datenbank nicht notwendig, da sie bei jedem Neustart des Services entfernt wird und ohne großen Speicherbedarf erneut erzeugt werden kann. Die Leistung kann entscheidend gesteigert werden, indem verschiedene Teile der Datenbank auf separaten physischen Festplatten getrennt gespeichert werden. Folgende Elemente sollten getrennt werden: Datendateien Protokolldateien (eine Protokolldatei pro Volume) Temporäre Datenbanken Betriebssysteme Wie groß soll die CPU sein? Transaktionen pro Sekunde (TPS) erhöhen die CPU-Auslastung. Es wird ein CPU-Kern je 500 Transaktionen pro Sekunde (TPS) empfohlen. Kunden sollten Prozessoren mit so vielen Kernen wie möglich erwerben, um vom Lizenzierungsmodell zu profitieren. Im Allgemeinen gilt eine CPU-Auslastung von 30 % bis 50 % als empfehlenswert. SQL 2008 R2 Hyper-V Ressourcenzuweisungen CSV für virtuelle Festplatte der virtuellen Maschine bei 600 GB auf EqualLogic PS6000XV Jede virtuelle Festplatte umfasst etwa 100 GB EqualLogic PS6000XV (16) 300-GB-SAS-Festplatten mit /min 15 SAS-R10-Festplatten mit einem Hot-Spare = 2 TB nutzbar Drei SQL 2008 R2 Standard-Gast-Cluster mit zwei Knoten (bis zu zwei virtuelle Maschinen pro aktivem/ passivem SQL Cluster-Knoten): aktive/passive VM- Konfiguration mit zwei Knoten Virtuelle Quorum-Festplatte mit 1 GB, die dem Knoten 1 und 2 direkt über eine SCSI-Festplatte und ein iscsi-initiator zugewiesen ist Virtuelle Protokollfestplatte mit 40 GB, die dem Knoten 1 und 2 direkt über eine SCSI-Festplatte und ein iscsi-initiator zugewiesen ist Virtuelle Datenbankfestplatte mit 150 GB, die dem Knoten 1 und 2 direkt über eine SCSI-Festplatte und ein iscsi-initiator zugewiesen ist Optionale Trennung von temporären Datenbanken (die Größe der Datei- und der virtuellen Festplatte sollte durch den Dateiwachstums-Prozentsatz bestimmt werden) Optionale Trennung der Indizierung für die Dateiwiederherstellung 15 GB Arbeitsspeicher pro virtueller Maschine = Abfragen pro SQL Instanz x 3. Windows 2008 R2 Hyper-V mit drei Knoten: virtuelle Cluster-Konfiguration mit aktivem/passivem SQL 2008 R2 Gast-Cluster NIC 1 und 2 für redundante übergeordnete VLANs für isci-datenverkehr (auch für VM-Gast-Cluster konfiguriert) NIC 3 für Live-Migration NIC 4 für Cluster-Verwaltung/private Cluster- Kommunikation mit übergeordneten VLANs NIC 5 und 6 für VLANs für isci-datenverkehr (konfiguriert für VM-Gast-Cluster) NIC 7 und 8 für private, öffentliche und externe VLANs für Datenverkehr (auch für VM-Gast-Cluster konfiguriert) Quorum liegt bei 1 GB auf EqualLogic PS6000XV

5 4 Gbit/s Massenspeicher 600 GB CSV1 1 GB Quorum 1 1 GB Quorum 2 1 GB Quorum 3 1 GB Quorum 4 40 GB Log1 40 GB Log2 40 GB Log3 150 GB Daten1 150 GB Daten2 150 GB Daten3 20 GB TempDB1 20 GB TempDB2 20 GB TempDB Richtlinien für SQL 2008 R2 Hyper-V Die redundanten Konfigurationen sind unbegrenzt in der Dell Konfiguration. Max. Anzahl virtueller CPUs pro virtueller Maschine =4 In diesem Beispiel liegen drei aktive/passive SQL 2008 R2 Gast-Cluster vor. Arbeitsspeicher der virtuellen Maschine: Die allgemeine Empfehlung lautet 2 GB plus 1 GB zusätzlich je Abfragen pro Sekunde. Jede aktive virtuelle SQL Maschine unterstützt andere SQL Instanzen, die alle eine ausgewogene Rechenlast verarbeiten. Jede Instanz verarbeitet durchschnittlich Abfragen pro Sekunde. Dadurch kann ein passiver Server ohne Leistungseinbußen darauf warten, dass der primäre Server ausfällt. Diese Lösung ist vollständig redundant und hochverfügbar. Für den passiven Knoten für SQL 2008 R2 ist keine Lizenz erforderlich, solange er nur für Failover verwendet wird. Minimale Dimensionierung = (virtuelle Festplatte des VM-Betriebssystems) Größe der virtuellen Festplatte + Arbeitsspeichergröße der virtuellen Maschine + (virtuelle iscsi-scsi-festplatten) Datendateien + Protokolldateien + andere temporäre Datenbanken Verwendung virtueller Festplatten auf allen virtuellen Maschinen, die mit einem virtuellen SCSIController verbunden sind Verwendung von Pass-Through-Festplatten oder einer virtuellen Festplatte mit festgelegter Größe für virtuelle Gastmaschinen Virtuelle Maschinen mit virtuellen Festplatten können einfacher verschoben werden als PassThrough-Festplatten. Ein physisches Betriebssystem benötigt zusätzlich zu virtuellen Hostmaschinen 2 GB Arbeitsspeicher.

6 Zusätzliche Hinweise zu Microsoft SQL Es gibt eine 32-Bit- und eine 64-Bit-Edition von SQL Server Aufgrund der höheren Leistung wird die 64-Bit- Edition empfohlen. Für Anwendungen ist die Edition üblicherweise unwichtig. Lizenzierung Pro Prozessor Server/CAL Ungefähre Gewinnschwelle bei einem Server und zwei physischen Prozessoren. Standard Edition: ca. 80 Benutzer Enterprise Edition: ca. 350 Benutzer einer Wartung oder einem Failover virtuelle Maschinen aus. In einem ausreichend großen Cluster kann dies als "Reserverad" angesehen werden, und es vermeidet das Rätselraten bei der Dimensionierung einer Umgebung. F: Wie sehen die Unterschiede in der Lizenzierung für virtuelle Maschinen aus? A: Die Antwort auf diese Frage umfasst so viele verschiedene Variablen und Modelle, dass Interessenten zuerst die folgenden häufig gestellten Fragen lesen und anschließend einen Dell Experten für die Lizenzierung kontaktieren sollten: download/2/7/0/270b6380-8b ad0- F480A139AB19/SQL2008R2_LicensingQuickReferenceupdated.pdf oder EqualLogic SQL Server auf EqualLogic: com/partnerships/default.aspx?id=6479 Häufig gestellte Fragen zu SQL 2008 R2 Hier finden Sie Antworten zu einigen Fragen, die sich bei der Dimensionierung eines virtuellen Clusters für SQL stellen: F: Wie groß muss der Puffer sein? A: Wenn virtuelle SQL Maschine von Host zu Host migriert werden, entweder aufgrund geplanter oder ungeplanter Ausfälle, ist es wichtig, dass ausreichend Festplattenspeicher und CPUs auf einem Failoverknoten verfügbar sind. Es gibt zwei verschiedene Ansätze für die Dimensionierung des Puffers. 1. Es muss ausreichend Kapazität auf allen Hosts hinzugefügt werden, sodass beim Ausfall eines Hosts einige der virtuellen Maschinen vom Host auf den freien Platz auf den verschiedenen Hosts migriert werden können. 2. Es muss ein flexibler Host eingerichtet werden, der normalerweise keine Rechenlasten von virtuellen Maschinen ausführt. Dieser Host befindet sich im Leerlauf und führt nur bei