Überlegungen zum Entwurf von SQL Server

Wichtig

Diese Version von Operations Manager hat das Supportende erreicht. Sie sollten ein Upgrade auf Operations Manager 2022 durchführen.

System Center Operations Manager erfordert Zugriff auf eine Serverinstanz, auf der Microsoft SQL Server ausgeführt wird, um die Betriebsdatenbank, die Data Warehouse-Datenbank und die ACS-Überwachungsdatenbank zu unterstützen. Die Betriebsdatenbank und die Data Warehouse-Datenbank sind erforderlich und werden erstellt, wenn Sie den ersten Verwaltungsserver in Ihrer Verwaltungsgruppe bereitstellen. Die ACS-Datenbank wird erstellt, wenn Sie eine ACS-Sammlung in Ihrer Verwaltungsgruppe bereitstellen.

In einer Laborumgebung oder einer kleinen Operations Manager-Bereitstellung kann SQL Server zusammen mit anderen Komponenten auf dem ersten Verwaltungsserver in der Verwaltungsgruppe installiert werden.

In einer verteilten mittelgroßen oder sehr großen Bereitstellung sollte die SQL Server-Instanz auf einem dedizierten eigenständigen Server oder in einer SQL Server-Hochverfügbarkeitskonfiguration installiert werden. In beiden Fällen muss die SQL Server-Instanz bereits vorhanden und verfügbar sein, bevor Sie mit der Installation des ersten Verwaltungsservers oder der ersten ACS-Sammlung beginnen.

Operations Manager-Datenbanken aus einer SQL-Instanz, die über andere Anwendungsdatenbanken verfügt, sollten nicht verwendet werden. Dadurch sollen potenzielle Probleme mit Einschränkungen von E/A- und anderen Hardwareressourcen vermieden werden.

SQL Server-Anforderungen

Die folgenden Versionen der SQL Server Enterprise und SQL Server Standard Edition werden für eine vorhandene Installation der System Center Operations Manager-Version zum Hosten des Berichtsservers, der Betriebsdatenbank, von Data Warehouse und der ACS-Datenbank unterstützt:

  • SQL Server 2019 mit dem kumulativen Update 8 (CU8) oder höher, wie hier beschrieben

    Hinweis

    • Operations Manager 2019 unterstützt SQL 2019 mit CU8 oder höher. SQL 2019 RTM wird jedoch nicht unterstützt.
    • Verwenden Sie ODBC 17.3 bis 17.9 und MSOLEDBSQL 18.2 bis 18.6.3.
  • SQL Server 2022, wie ausführlich [hier]

  • SQL Server 2019 mit dem kumulativen Update 8 (CU8) oder höher, wie hier beschrieben

    Hinweis

    • Operations Manager 2022 unterstützt SQL 2019 mit CU8 oder höher. SQL 2019 RTM wird jedoch nicht unterstützt.
    • Verwenden Sie ODBC 17.3 bis 17.9 und MSOLEDBSQL 18.2 bis 18.6.3.
  • SQL Server 2017 und kumulative Updates, wie hier beschrieben
  • SQL Server 2016 und Service Packs wie hier angegeben
  • SQL Server 2017 und kumulative Updates, wie hier beschrieben

Die folgenden Versionen der SQL Server Enterprise und SQL Server Standard Edition werden für eine vorhandene Installation der System Center Operations Manager-Version zum Hosten des Berichtsservers, der Betriebsdatenbank, von Data Warehouse und der ACS-Datenbank unterstützt:

  • SQL Server 2017 und kumulative Updates, wie hier beschrieben
  • SQL Server 2016 und Service Packs wie hier angegeben

Lesen Sie vor Durchführung eines SQL Server-Upgrades die Upgradeinformationen für SQL 2017 und die Upgradeinformationen für SQL 2019.

Lesen Sie vor dem Upgrade auf SQL Server 2017 die Upgradeinformationen für 2017.

Die folgenden Versionen der SQL Server Enterprise und SQL Server Standard Edition werden für eine neue oder vorhandene Installation von System Center Operations Manager, Version 1801, zum Hosten des Berichtsservers, der Betriebsdatenbank, von Data Warehouse und der ACS-Datenbank unterstützt:

  • SQL Server 2016 und Service Packs wie hier angegeben

Die folgenden Versionen der SQL Server Enterprise und SQL Server Standard Edition werden für eine neue oder vorhandene Installation von System Center 2016 Operations Manager zum Hosten des Berichtsservers, der Betriebsdatenbank, von Data Warehouse und der ACS-Datenbank unterstützt:

  • SQL Server 2016 und Service Packs wie hier angegeben
  • SQL Server 2014 und Service Packs wie hier angegeben
  • SQL Server 2012 und Service Packs wie hier angegeben

Hinweis

  • Alle folgenden SQL Server Komponenten, die eine SCOM-Infrastruktur unterstützen, müssen dieselbe SQL Server-Hauptversion aufweisen:
    • Instanzen der SQL Server-Datenbank-Engine, die eine der SCOM-Datenbanken hosten (z. B. OperationManager, OperationManagerDW und SSRS-Datenbanken ReportServer&ReportServerTempDB).
    • SQL Server Reporting Services-Instanz (SSRS)
  • Die SQL Server-Sortierungseinstellung muss einen der unterstützten Typen aufweisen, wie im Abschnitt Einstellung für die SQL Server-Sortierung unten beschrieben.
  • Die SQL Server-Volltextsuche ist für alle Instanzen der SQL Server-Datenbank-Engine erforderlich, die eine der SCOM-Datenbanken hosten.
  • Die Installationsoptionen von Windows Server 2016 (Server Core, Server mit Desktopdarstellung und Nano Server), die von Operations Manager-Datenbankkomponenten unterstützt werden, basieren darauf, welche Installationsoptionen von Windows Server von SQL Server unterstützt werden.

Hinweis

Die Berichterstellung von System Center Operations Manager kann nicht parallel zu einer früheren Version der Berichterstellungsrolle installiert werden und muss im einheitlichen Modus installiert werden (der integrierte SharePoint-Modus wird nicht unterstützt).

In Ihrer Entwurfsplanung müssen noch einige weitere Aspekte hinsichtlich der Hardware und Software berücksichtigt werden:

  • Es wird empfohlen, SQL Server auf Computern mit dem NTFS-Dateiformat auszuführen.
  • Für die Betriebsdatenbank und die Data Warehouse-Datenbank müssen mindestens 1024 MB freier Speicherplatz verfügbar sein. Dies wird bereits bei der Datenbankerstellung erzwungen, und nach der Einrichtung ist ein signifikantes Wachstum des Speicherplatzbedarfs zu erwarten.
  • .NET Framework 4 ist erforderlich.
  • .NET Framework 4.8 wird ab Operations Manager 2022 unterstützt.
  • Reporting-Server wird unter Windows Server Core nicht unterstützt.

Weitere Informationen finden Sie in den Hardware- und Softwareanforderungen für die Installation von SQL Server 2014 oder 2016.

Hinweis

Verwenden Sie während der ersten Installation der Betriebsdatenbank auf dem SQL Server, auf dem die Operations Manager-Betriebsdatenbank gehostet wird, nur die Windows-Authentifizierung. Verwenden Sie nicht den gemischten Modus (Windows-Authentifizierung und SQL Server-Authentifizierung). Durch den SQL Server-Authentifizierungsmodus können bei der Erstinstallation Probleme verursacht werden. Das Aktivieren des gemischten Modus auf dem SQL Server, auf dem die Operations Manager-Betriebsdatenbank gehostet wird, ist zwar möglich, wird aber nicht unterstützt, da alle Verbindungen mit der Datenbank nur mithilfe von Windows-Konten hergestellt werden.

Einstellung für die SQL Server-Sortierung

Die folgenden SQL Server- und Windows-Sortierungen werden von System Center Operations Manager unterstützt.

Hinweis

Es wird empfohlen, dieselbe Sortierung für die SQL- und Operations Manager-Datenbank zu verwenden, um Kompatibilitätsprobleme beim Vergleichen oder Kopieren von Vorgängen zu vermeiden.

SQL Server-Sortierung

  • SQL_Latin1_General_CP1_CI_AS

Windows-Sortierung

  • Latin1_General_100_CI_AS
  • French_CI_AS
  • French_100_CI_AS
  • Cyrillic_General_CI_AS
  • Chinese_PRC_CI_AS
  • Chinese_Simplified_Pinyin_100_CI_AS
  • Chinese_Traditional_Stroke_Count_100_CI_AS
  • Japanese_CI_AS
  • Japanese_XJIS_100_CI_AS
  • Traditional_Spanish_CI_AS
  • Modern_Spanish_100_CI_AS
  • Latin1_General_CI_AS
  • Cyrillic_General_100_CI_AS
  • Korean_100_CI_AS
  • Czech_100_CI_AS
  • Hungarian_100_CI_AS
  • Polish_100_CI_AS
  • Finnish_Swedish_100_CI_AS

Die Ausführung eines neuen Operations Manager-Setups ist nicht möglich, wenn Ihre SQL Server-Instanz nicht mit einer der zuvor aufgeführten unterstützten Sortierungen konfiguriert ist. Allerdings kann ein direktes Upgrade erfolgreich abgeschlossen werden.

Firewallkonfiguration

Operations Manager benötigt SQL Server zum Hosten der Datenbanken und einer Berichtsplattform, um operative Verlaufsdaten zu analysieren und darzustellen. Die Rollen für Verwaltungsserver, Betrieb und Webkonsole müssen erfolgreich mit SQL Server kommunizieren können, und es ist wichtig, die Kommunikationspfade und -ports zu kennen, damit die Umgebung ordnungsgemäß konfiguriert wird.

Wenn Sie eine verteilte Bereitstellung entwerfen, die SQL Always On-Verfügbarkeitsgruppen benötigt, um Failoverfunktionen für die Operations Manager-Datenbanken bereitzustellen, müssen Sie in Ihrer Firewallsicherheitsstrategie einige weitere Firewallkonfigurationseinstellungen berücksichtigen.

In der folgenden Tabelle finden Sie die Firewallports, die für SQL Server mindestens zugelassen werden müssen, damit die Serverrollen in Ihrer Operations Manager-Verwaltungsgruppe erfolgreich kommunizieren können.

Szenario Port Richtung Operations Manager-Rolle
SQL Server-Instanz, auf der Operations Manager-Datenbanken gehostet werden TCP 1433 * Eingehende Verbindungen Verwaltungsserver und Webkonsole (für Application Advisor und Anwendungsdiagnose)
SQL Server-Browserdienst UDP 1434 Eingehende Verbindungen -Verwaltungsserver
Dedizierte SQL Server-Verwaltungsverbindung TCP 1434 Eingehende Verbindungen -Verwaltungsserver
Zusätzliche von SQL Server verwendete Ports
– Microsoft Remoteprozeduraufrufe (MS RPC)
– Windows-Verwaltungsinstrumentation (WMI)
– Microsoft Distributed Transaction Coordinator (MS DTC)
TCP 135 Eingehende Verbindungen -Verwaltungsserver
Listener für SQL Server-Always On-Verfügbarkeitsgruppen Vom Administrator konfigurierter Port Eingehende Verbindungen -Verwaltungsserver
SQL Server Reporting Services, die den Operations Manager-Berichtsserver hosten TCP 80 (Standard)/443 (SSL) Eingehende Verbindungen Verwaltungsserver und Betriebskonsole

* TCP 1433 ist der Standardport für die Standardinstanz der Datenbank-Engine. Wenn Sie jedoch eine benannte Instanz auf einer eigenständigen SQL Server-Instanz erstellen oder eine SQL Always On-Verfügbarkeitsgruppe bereitgestellt haben, wird ein benutzerdefinierter Port festgelegt. Dieser sollte zur Referenz dokumentiert sein, sodass Sie Ihre Firewalls ordnungsgemäß konfigurieren und diese Informationen während des Setups eingeben können.

Eine detailliertere Übersicht über die Firewallanforderungen für SQL Server finden Sie unter Konfigurieren der Windows Firewallanforderungen für das Zulassen von SQL Server-Zugriff.

Überlegungen zu Kapazität und Speicher

Operations Manager-Datenbank

Die Operations Manager-Datenbank ist eine SQL Server-Datenbank, die alle Daten enthält, die Operations Manager für die tägliche Überwachung benötigt. Die richtige Dimensionierung und Konfiguration des Datenbankservers ist entscheidend für die Gesamtleistung der Verwaltungsgruppe. Die wichtigste Ressource, die von der Operations Manager-Datenbank genutzt wird, ist das Speichersubsystem. CPU und RAM sind jedoch ebenfalls von großer Bedeutung.

Folgende Faktoren beeinflussen die Auslastung auf der Operations Manager-Datenbank:

  • Sammlungsrate für operative Daten. Bei operativen Daten handelt es sich um all die Ereignisse, Warnungen, Zustandsänderungen und Leistungsdaten, die von Agents gesammelt werden. Die meisten Ressourcen, die von der Operations Manager-Datenbank verwendet werden, dienen dazu, diese Daten auf Datenträger zu schreiben, sobald sie in das System gelangen. Die Rate, mit der operative Daten gesammelt werden, steigt üblicherweise, wenn weitere Management Packs importiert und weitere Agents hinzugefügt werden. Auch der von einem Agent überwachte Computertyp ist ein wichtiger Faktor, der bei der Bestimmung der Gesamtrate der Sammlung von operativen Daten berücksichtigt werden muss. Ein Agent, der einen geschäftskritischen Desktopcomputer überwacht, wird z.B. wahrscheinlich weniger Daten sammeln als ein Agent, der einen Server überwacht, auf dem eine SQL Server-Instanz mit einer großen Zahl von Datenbanken ausgeführt wird.
  • Rate der Änderungen am Instanzspeicherplatz. Die Aktualisierung dieser Daten in der Operations Manager-Datenbank ist teuer im Vergleich zum Schreiben neuer operativer Daten. Wenn sich Daten im Instanzspeicherplatz ändern, führen die Verwaltungsserver zusätzliche Abfragen in der Operations Manager-Datenbank aus, um Konfigurations- und Gruppenänderungen zu berechnen. Die Rate der Änderungen im Instanzspeicherplatz steigt, wenn Sie weitere Management Packs in eine Verwaltungsgruppe importieren. Durch Hinzufügen neuer Agents zu einer Verwaltungsgruppe steigt die Änderungsrate im Instanzspeicherplatz vorübergehend ebenfalls.
  • Die Anzahl von Betriebskonsolen und anderen gleichzeitig ausgeführten SDK-Verbindungen. Jede Betriebskonsole liest Daten aus der Operations Manager-Datenbank. Die Abfrage dieser Daten kann große Mengen an E/A-Speicherressourcen, CPU-Zeit und RAM verbrauchen. Betriebskonsolen, die große Mengen an operativen Daten in der Ereignisansicht, der Statusansicht, der Warnungsansicht und der Leistungsdatenansicht anzeigen, verursachen tendenziell die größte Auslastung auf der Datenbank.

Die Operations Manager-Datenbank ist ein Single Point of Failure (SPOF) für die Verwaltungsgruppe und kann daher mithilfe unterstützter Failoverkonfigurationen hoch verfügbar gemacht werden, z.B. mit SQL Server-Always On-Verfügbarkeitsgruppen oder Failoverclusterinstanzen.

Sie können Operations Manager-Datenbanken mit einem vorhandenen SQL Always-On-Setup einrichten und aktualisieren, ohne Änderungen nach der Konfiguration vornehmen zu müssen.

Aktivieren des SQL-Brokers für die Operations Manager-Datenbank

System Center Operations Manager verwendet den SQL Server Service Broker für die Implementierung aller Aufgabenvorgänge. Wenn der SQL Server Service Broker deaktiviert ist, sind davon sämtliche Aufgabenvorgänge betroffen. Das resultierende Verhalten kann je nach initiierter Aufgabe variieren. Daher sollte unbedingt der Zustand des SQL Server Service Brokers überprüft werden, wenn im Bereich einer Aufgabe in System Center Operations Manager ein unerwartetes Verhalten festgestellt wird.

Führen Sie folgende Schritte aus, um den SQL Server Service Broker zu aktivieren:

  1. Führen Sie die folgende SQL-Abfrage aus:

    SELECT is_broker_enabled FROM sys.databases WHERE name='OperationsManager'
    
  2. Überspringen Sie diesen Schritt, wenn der im Feld is_broker_enabled angezeigte Wert is_broker_enabled lautet. Andernfalls führen Sie die folgenden SQL-Abfragen aus:

    ALTER DATABASE OperationsManager SET SINGLE_USER WITH ROLLBACK IMMEDIATE
    ALTER DATABASE OperationsManager SET ENABLE_BROKER
    ALTER DATABASE OperationsManager SET MULTI_USER
    

Operations Manager-Data Warehouse-Datenbank

System Center – Operations Manager fügt Daten nahezu in Echtzeit in das Reporting-Data Warehouse ein. Daher ist es wichtig, dass auf diesem Server, der das Schreiben aller im Reporting-Data Warehouse gesammelten Daten unterstützt, ausreichend Kapazität zur Verfügung steht. Genau wie bei der Operations Manager-Datenbank ist das E/A-Speichersubsystem die wichtigste Ressource im Reporting-Data Warehouse. In den meisten Systemen ähneln die Auslastungen im Reporting-Data Warehouse denen in der Operations Manager-Datenbank, sie können jedoch variieren. Außerdem unterscheidet sich die Arbeitsauslastung, die durch die Berichterstellung im Reporting-Data Warehouse entsteht, von der Auslastung, die durch die Nutzung der Betriebskonsole in der Operations Manager-Datenbank entsteht.

Folgende Faktoren beeinflussen die Auslastung im Reporting-Data Warehouse:

  • Sammlungsrate für operative Daten. Um eine effizientere Berichterstellung zu ermöglichen, berechnet und speichert das Reporting-Data Warehouse aggregierte Daten sowie eine begrenzte Menge an Rohdaten. Durch diesen zusätzlichen Aufwand kann die Sammlung operativer Daten im Reporting-Data Warehouse etwas teurer sein als in der Operations Manager-Datenbank. Diese zusätzlichen Kosten werden im Allgemeinen dadurch ausgeglichen, dass für die Verarbeitung von Ermittlungsdaten im Reporting-Data Warehouse geringere Kosten anfallen als in der Operations Manager-Datenbank.
  • Die Anzahl von gleichzeitigen Berichterstellungsbenutzern oder die geplante Generierung von Berichten. Da Berichte häufig große Datenmengen zusammenfassen, kann jeder Berichterstellungsbenutzer dem System eine erhebliche Auslastung hinzufügen. Die Anzahl von gleichzeitig ausgeführten Berichten und die Berichtstypen wirken sich auf den gesamten Kapazitätsbedarf aus. Allgemein gilt: Berichte, die sehr große Datumsbereiche oder große Mengen an Objekten abfragen, erfordern zusätzliche Systemressourcen.

Basierend auf diesen Faktoren gibt es mehrere empfohlene Methoden, die berücksichtigt werden sollten, um das Reporting-Data Warehouse richtig zu dimensionieren:

  • Wählen Sie ein geeignetes Speichersubsystem. Das Reporting-Data Warehouse ist ein integraler Bestandteil des gesamten Datenflusses durch die Verwaltungsgruppe. Daher ist die Auswahl eines geeigneten Speichersubsystems für das Reporting-Data Warehouse von großer Bedeutung. Ebenso wie bei der Operations Manager-Datenbank ist RAID 0 + 1 oft die beste Wahl. Im Allgemeinen sollte das Speichersubsystem für das Reporting-Data Warehouse das gleiche sein wie für die Operations Manager-Datenbank, und die Informationen und Anleitungen, die für die Operations Manager-Datenbank gelten, gelten auch für das Reporting-Data Warehouse.
  • Planen Sie die geeigneten Speicherorte für die Datenprotokolle und Transaktionsprotokolle. Ebenso wie bei der Operations Manager-Datenbank empfiehlt es sich häufig, die SQL-Datenprotokolle und die Transaktionsprotokolle zu trennen, wenn Sie die Anzahl von Agents erhöhen. Wenn sich die Operations Manager-Datenbank und das Reporting-Data Warehouse auf dem gleichen Server befinden und Sie die Daten- und Transaktionsprotokolle trennen möchten, müssen Sie die Transaktionsprotokolle für die Operations Manager-Datenbank und das Reporting-Data Warehouse auf separaten physischen Volumes und Datenträgerspindeln speichern, um einen Vorteil zu erzielen. Die Datendateien für die Operations Manager-Datenbank und das Reporting-Data Warehouse können sich auf dem gleichen physischen Volume befinden, sofern dieses ausreichend Kapazität bietet und die Datenträger-E/A-Leistung die Überwachungs- und Berichterstellungsfunktionalität nicht beeinträchtigt.
  • Ziehen Sie in Betracht, das Reporting-Data Warehouse auf einem anderen Server zu installieren als die Operations Manager-Datenbank. In kleineren Bereitstellungen können Operations Manager-Datenbank und Reporting-Data Warehouse häufig auf dem gleichen Server konsolidiert werden. Wenn Sie jedoch die Anzahl von Agents hochskalieren und die Menge an eingehenden operativen Daten steigt, ist es vorteilhaft, Datenbank und Data Warehouse zu trennen. Wenn sich Reporting-Data Warehouse und der Berichtsserver auf einem anderen Server befinden als die Operations Manager-Datenbank, lassen sich bei der Berichterstellung bessere Leistungsergebnisse erzielen.

Die Data Warehouse-Datenbank von Operations Manager ist ein Single Point of Failure (SPOF) für die Verwaltungsgruppe und kann daher mithilfe unterstützter Failoverkonfigurationen hoch verfügbar gemacht werden, z.B. mit SQL Server-Always On-Verfügbarkeitsgruppen oder Failoverclusterinstanzen.

SQL Server Always On

SQL Server Always On-Verfügbarkeitsgruppen unterstützen Failoverumgebungen für eine gesonderte Gruppe von Benutzerdatenbanken (Verfügbarkeitsdatenbanken). Jede Gruppe von Verfügbarkeitsdatenbanken wird durch ein Verfügbarkeitsreplikat gehostet.

Bei System Center 2016 – Operations Manager (und höher) ist SQL Always On gegenüber dem Failoverclustering zu bevorzugen, wenn es um die Bereitstellung von Hochverfügbarkeit von Datenbanken geht. Alle Datenbanken können in einer Always On-Verfügbarkeitsgruppe gehostet werden – außer in der Reporting Services-Installation im einheitlichen Modus, bei der zwei Datenbanken verwendet werden, um den permanenten Datenspeicher von temporären Speicheranforderungen zu trennen.

Zum Einrichten einer Verfügbarkeitsgruppe müssen Sie einen WSFC-Cluster (Windows Server Failover Clustering) zum Hosten des Verfügbarkeitsreplikats bereitstellen und Always On auf den Clusterknoten aktivieren. Anschließend können Sie die SQL Server-Datenbank von Operations Manager als Verfügbarkeitsdatenbank hinzufügen.

SQL Server Always On

SQL Server Always On-Verfügbarkeitsgruppen unterstützen Failoverumgebungen für eine gesonderte Gruppe von Benutzerdatenbanken (Verfügbarkeitsdatenbanken). Jede Gruppe von Verfügbarkeitsdatenbanken wird durch ein Verfügbarkeitsreplikat gehostet.

Bei System Center 2016 – Operations Manager (und höher) ist SQL Always On gegenüber dem Failoverclustering zu bevorzugen, wenn es um die Bereitstellung von Hochverfügbarkeit von Datenbanken geht. Alle Datenbanken können in einer Always On-Verfügbarkeitsgruppe gehostet werden – außer in der Reporting Services-Installation im einheitlichen Modus, bei der zwei Datenbanken verwendet werden, um den permanenten Datenspeicher von temporären Speicheranforderungen zu trennen.

Bei Operations Manager 2022 können Sie Operations Manager-Datenbanken mit einem vorhandenen SQL Always-On-Setup einrichten und aktualisieren, ohne Änderungen nach der Konfiguration vornehmen zu müssen.

Zum Einrichten einer Verfügbarkeitsgruppe müssen Sie einen WSFC-Cluster (Windows Server Failover Clustering) zum Hosten des Verfügbarkeitsreplikats bereitstellen und Always On auf den Clusterknoten aktivieren. Anschließend können Sie die SQL Server-Datenbank von Operations Manager als Verfügbarkeitsdatenbank hinzufügen.

Hinweis

Nachdem Sie Operations Manager auf den SQL Server-Knoten bereitgestellt haben, die in SQL Always On integriert sind, um CLR Strict Security zu aktivieren, führen Sie das SQL-Skript für jede Operations Manager-Datenbank aus.

Zeichenfolge mit mehreren Subnetzen

Operations Manager unterstützt die Schlüsselwörter der Verbindungszeichenfolge nicht (MultiSubnetFailover=True). Da eine Verfügbarkeitsgruppe einen Listenernamen hat (der sogenannte Netzwerkname oder Clientzugriffspunkt im WSFC-Cluster-Manager), der von mehreren IP-Adressen aus unterschiedlichen Subnetzen abhängt, z.B. bei der Bereitstellung einer standortübergreifenden Failoverkonfiguration, erreichen Clientverbindungsanforderungen von den Verwaltungsservern an den Listener der Verfügbarkeitsgruppe ein Verbindungstimeout.

Bei bereitgestellten Serverknoten in der Verfügbarkeitsgruppe in einer Umgebung mit mehreren Subnetzen wird zu dieser Einschränkung die folgende Problemumgehung empfohlen:

  1. Legen Sie den Netzwerknamen des Verfügbarkeitsgruppenlisteners so fest, dass nur einzelne aktive IP-Adressen in DNS registriert werden.
  2. Konfigurieren Sie den Cluster so, dass ein niedriger TTL-Wert für den registrierten DNS-Eintrag verwendet wird.

Diese Einstellungen ermöglichen bei einem Failover auf einen Knoten in einem anderen Subnetz eine schnellere Wiederherstellung und die Auflösung des Clusternamens mit der neuen IP-Adresse.

Führen Sie die folgende PowerShell-Abfrage auf einem der SQL-Knoten aus, um seine Einstellungen zu ändern.

  Import-Module FailoverClusters
  Get-ClusterResource "Cluster Name"|Set-ClusterParameter RegisterAllProvidersIP 0
  Get-ClusterResource "Cluster Name"|Set-ClusterParameter HostRecordTTL 300
  Stop-ClusterResource "Cluster Name"
  Start-ClusterResource "Cluster Name"

Wenn Sie Always On mit einem Listenernamen verwenden, sollten Sie diese Konfigurationsänderungen auch auf dem Listener vornehmen.

Führen Sie die folgende PowerShell-Abfrage auf dem SQL-Knoten aus, der derzeit den Listener hostet, um die Einstellungen des Knotens zu ändern.

  Import-Module FailoverClusters
  Get-ClusterResource <Listener Cluster Resource name> | Set-ClusterParameter RegisterAllProvidersIP 0
  Get-ClusterResource <Listener Cluster Resource name> | Set-ClusterParameter HostRecordTTL 300
  Stop-ClusterResource <Listener Cluster Resource name>
  Start-ClusterResource <Listener Cluster Resource name>

Wenn eine gruppierte oder Always On-SQL-Instanz für hohe Verfügbarkeit verwendet wird, sollten Sie die automatische Wiederherstellungsfunktion auf Ihren Verwaltungsservern aktivieren, um den Neustart des Operations Manager-Datenzugriffsdiensts bei jedem Auftreten eines Failovers zwischen Knoten zu vermeiden. Informationen zur entsprechenden Konfiguration finden Sie im KB-Artikel Der System Center-Verwaltungsdienst reagiert nicht mehr, nachdem eine SQL Server-Instanz offline gegangen ist.

Optimieren von SQL Server

Die Erfahrung in der Bereitstellung für Kunden lehrt, dass Leistungsprobleme in der Regel nicht durch hohe Ressourcenauslastung (z.B. Prozessor oder Arbeitsspeicher) bei SQL Server selbst verursacht werden. Diese hängen viel mehr direkt mit der Konfiguration des Speichersubsystems zusammen. Leistungsengpässe sind häufig darauf zurückzuführen, dass beim Bereitstellen des Speichers für die SQL Server-Datenbankinstanz die empfohlenen Konfigurationsrichtlinien nicht eingehalten werden. Einige Beispiele:

  • Unzureichende Zuweisung von Spindeln für die LUNs, um die E/A-Anforderungen von Operations Manager zu unterstützen.
  • Hosten von Transaktionsprotokollen und Datenbankdateien auf dem gleichen Volume. Diese beiden Workloads verfügen über unterschiedliche E/A- und Latenzmerkmale.
  • Falsche Konfiguration von „tempdb“ im Hinblick auf Platzierung, Dimensionierung usw.
  • Falsche Zuordnung der Datenträgerpartitionen auf den Volumes, auf denen die Datenbanktransaktionsprotokolle, die Datenbankdateien und die tempdb-Datenbank gehostet werden.
  • Ignorieren von grundlegenden SQL Server-Konfigurationsanforderungen, beispielsweise die Verwendung von AUTOGROW für Datenbank- und Transaktionsprotokolldateien, die MAXDOP-Einstellung für Abfrageparallelität, das Erstellen mehrerer tempdb-Datendateien pro CPU-Kern usw.

Die Speicherkonfiguration ist eine der wichtigsten Komponenten einer SQL Server-Bereitstellung für Operations Manager. Datenbankserver sind aufgrund der hohen Lese- und Schreibaktivitäten und Transaktionsprotokollverarbeitung der Datenbank häufig sehr stark auf E/A-Aktivitäten ausgerichtet. Das E/A-Verhaltensmuster von Operations Manager umfasst typischerweise 80% Schreibvorgänge und 20% Lesevorgänge. Eine fehlerhafte Konfiguration von E/A-Subsystemen kann daher zu einer unzureichenden Leistung von SQL Server-Systemen führen und macht sich in Operations Manager bemerkbar.

Es ist wichtig, den SQL Server-Entwurf zu überprüfen, indem Sie vor der Bereitstellung einen Durchsatztest des E/A-Subsystems durchführen. Stellen Sie sicher, dass diese Tests Ihre E/A-Anforderungen mit einer akzeptablen Latenzzeit erfüllen können. Verwenden Sie Diskspd Utility (das Diskspd-Hilfsprogramm), um die E/A-Kapazitäten des Speichersubsystems auszuwerten, das SQL Server unterstützt. Dieser Blogartikel, der von einem Mitglied des für Dateiserver zuständigen Teams in der Produktgruppe geschrieben wurde, bietet sehr detaillierte Anleitungen und Empfehlungen dazu, wie Sie mit diesem Tool und PowerShell-Code Belastungstests durchführen und die Ergebnisse mit PerfMon erfassen. Eine erste Anleitung finden Sie auch im Tool zur Dimensionierung von Operations Manager.

Größe der NTFS-Zuordnungseinheit

Die Volumeausrichtung, häufig auch als Sektorausrichtung bezeichnet, sollte auf dem Dateisystem (NTFS) immer dann durchgeführt werden, wenn ein Volume auf einem RAID-Gerät erstellt wird. Das Auslassen dieses Schritts kann zu erheblichen Leistungseinbußen führen, da diese zumeist durch eine fehlerhafte Ausrichtung der Partitionen an den Grenzen der Stripeeinheiten verursacht werden. Dies kann auch zu einer fehlerhaften Ausrichtung des Hardwarecaches und damit zu einer ineffizienten Nutzung des Arraycaches führen. Bei der Formatierung der Partition, die für SQL Server-Datendateien verwendet wird, empfiehlt es sich, 64 KB (also 65.536 Bytes) große Zuordnungseinheiten für Daten, Protokolle und „tempdb“ zu verwenden. Beachten Sie jedoch, dass Zuordnungseinheiten mit einer Größe von mehr als 4 KB dazu führen, dass auf dem Volume die NTFS-Komprimierung verwendet werden kann. SQL Server unterstützt zwar schreibgeschützte Daten auf komprimierten Volumes, dies wird jedoch nicht empfohlen.

Reservieren von Arbeitsspeicher

Hinweis

Ein Großteil der Informationen in diesem Abschnitt stammen von Jonathan Kehayias aus seinem Blogbeitrag How much memory does my SQL Server actually need? (sqlskills.com).

Es ist nicht immer einfach, die richtige Menge an physischem Arbeitsspeicher und Prozessoren zu ermitteln, die für SQL Server zur Unterstützung von System Center Operations Manager (oder für andere Workloads außerhalb dieses Produkts) zugeordnet werden müssen. Der von der Produktgruppe bereitgestellte Größenrechner bietet Anleitungen basierend auf der Workloadskalierung. Die Empfehlungen basieren jedoch auf Tests, die in einer Lab-Umgebung durchgeführt werden und möglicherweise nicht mit Ihrer tatsächlichen Workload und Konfiguration übereinstimmen.

SQL Server ermöglicht die Konfiguration der Minimal- und Maximalwerte für den Arbeitsspeicher, der für diesen Prozess reserviert wird und von diesem verwendet wird. Standardmäßig kann SQL Server den Arbeitsspeicherbedarf je nach verfügbaren Systemressourcen dynamisch anpassen. Die Standardeinstellung für Min. Serverarbeitsspeicher ist 0, die für Max. Serverarbeitsspeicher 2.147.483.647 MB.

Leistungs- und speicherbezogene Probleme können auftreten, wenn Sie keinen geeigneten Wert für Max. Serverarbeitsspeicher festlegen. Viele Faktoren beeinflussen, wie viel Arbeitsspeicher Sie SQL Server zuordnen müssen, um sicherzustellen, dass das Betriebssystem andere Prozesse unterstützen kann, die auf diesem System ausgeführt werden, z. B. die HBA-Karte, Verwaltungs-Agents und Virenscans in Echtzeit. Wenn nicht genügend Arbeitsspeicher festgelegt wird, werden das Betriebssystem und SQL auf Datenträger ausgelagert. Dies kann dazu führen, dass die Datenträger-E/A zunimmt, die Leistung weiter abnimmt und so ein „Welleneffekt“ entsteht, der dann auch in Operations Manager sichtbar wird.

Es wird empfohlen, mindestens 4 GB RAM für den min. Serverarbeitsspeicher anzugeben. Dieser Wert muss für jeden SQL-Knoten angegeben werden, der eine der Operations Manager-Datenbanken (Betriebsdatenbank, Data Warehouse-Datenbank, ACS-Datenbank) hostet.

Für den maximalen Serverspeicher empfiehlt es sich, zunächst insgesamt folgende Werte zu reservieren:

  • 1 GB RAM für das Betriebssystem
  • 1 GB RAM pro installierten 4 GB RAM (bis zu 16 GB RAM)
  • 1 GB RAM pro installierten 8 GB RAM (über 16 GB RAM)

Überwachen Sie nach Festlegen dieser Werte den Leistungsindikator Memory\Available MBytes in Windows, um zu ermitteln, ob Sie den für SQL Server verfügbaren Arbeitsspeicher erhöhen können. Windows signalisiert, dass der verfügbare physischer Speicher bei 96 MB niedrig ist. Der Leistungsindikator sollte im Idealfall nicht niedriger als 200 bis 300 MB sein, um sicherzustellen, dass ein Puffer vorhanden ist. Für Server mit 256 GB RAM oder höher sollten Sie sicherstellen, dass die Leistung nicht unter 1 GB fällt.

Beachten Sie, dass bei diesen Berechnungen davon ausgegangen wird, dass SQL Server den gesamten verfügbaren Arbeitsspeicher nutzen soll, es sei denn, Sie ändern diesen Wert, um andere Anwendungen zu berücksichtigen. Berücksichtigen Sie die spezifischen Arbeitsspeicheranforderungen für Ihr Betriebssystem, für andere Anwendungen, den SQL Server-Threadstapel und weitere mehrseitige Zuweisungen. Eine typische Formel wäre ((total system memory) – (memory for thread stack) – (OS memory requirements) – (memory for other applications) – (memory for multipage allocators)), wobei der Arbeitsspeicher für den Threadstapel ((max worker threads) (stack size)) beträgt. Die Stapelgröße beträgt 512 KB für x86-Systeme, 2 MB für x64-Systeme und 4 MB für IA64-Systeme. Sie finden den Wert für die max. Anzahl von Arbeitsthreads in der „max_worker_count“-Spalte von sys.dm_os_sys_info.

Diese Überlegungen gelten auch für die Arbeitsspeicheranforderungen für die SQL Server-Instanz, die auf einem virtuellen Computer ausgeführt werden soll. Da SQL Server für das Zwischenspeichern von Daten im Pufferpool konzipiert ist und in der Regel so viel Arbeitsspeicher wie möglich verwendet, kann es schwierig sein, die ideale Menge an RAM zu bestimmen. Wenn Sie den Arbeitsspeicher reduzieren, der einer SQL Server-Instanz zugeordnet ist, erreichen Sie schließlich einen Punkt, an dem eine niedrigere Speicherzuweisung für einen höheren Datenträger-E/A-Zugriff erreicht wird.

Wenn Sie SQL Server-Arbeitsspeicher in einer Umgebung konfigurieren möchten, die übermäßig bereitgestellt wurde, beginnen Sie, indem Sie die Umgebung sowie die aktuellen Leistungsmetriken überwachen, einschließlich der Seitenlebenserwartung des Puffer-Mangers von SQL Server sowie der Werte page reads/sec und disk reads/sec des physischen Datenträgers. Wenn die Umgebung einen Überschuss an Arbeitsspeicher aufweist, erhöht sich die Seitenlebenserwartung aufgrund der Zwischenspeicherung um einen Wert von eins pro Sekunde, ohne dass die Arbeitsauslastung abnimmt. Der Wert page reads/sec des Puffer-Managers von SQL Server ist nach dem Anstieg des Caches niedrig, und der Wert disk reads/sec des physischen Datenträgers bleibt ebenfalls niedrig.

Sobald Sie die Umgebungsbaseline verstanden haben, können Sie den maximalen Serverarbeitsspeicher um 1 GB reduzieren und dann beobachten, wie sich dies auf Ihre Leistungsindikatoren auswirkt (nach allen anfänglichen Cacheleerungen). Wenn die Metriken akzeptabel bleiben, verringern Sie sie um weitere 1 GB, überwachen Sie sie dann weiterhin, und wiederholen Sie den Vorgang nach Bedarf, bis eine ideale Konfiguration bestimmt werden kann.

Weitere Informationen finden Sie unter Konfigurationsoptionen für den Serverarbeitsspeicher.

Weitere Informationen finden Sie unter Konfigurationsoptionen für den Serverarbeitsspeicher.

Optimieren von tempdb

Größe und physische Platzierung der tempdb-datenbank-Datenbank können sich auf die Leistung von Operations Manager auswirken. Wenn für „tempdb“ eine zu geringe Größe definiert ist, wird beim Neustarten der SQL Server-Instanz ein Teil der Systemverarbeitungslast möglicherweise dafür verbraucht, „tempdb“ automatisch auf die Größe zu erweitern, die zur Unterstützung der Arbeitsauslastung erforderlich ist. Um eine optimale tempdb-Leistung zu erzielen, empfiehlt sich die folgende tempdb-Konfiguration in einer Produktionsumgebung:

  • Legen Sie das Wiederherstellungsmodell von tempdb auf „SIMPLE“ fest. Dieses Modell fordert automatisch Protokollspeicherplatz zurück, um den Speicherplatzbedarf so gering wie möglich zu halten.
  • Weisen Sie vorab Speicherplatz für alle tempdb-Dateien zu, indem Sie die Dateigröße auf einen Wert festlegen, der groß genug ist, um die typische Arbeitsauslastung in der Umgebung zu verarbeiten. Dies verhindert, dass „tempdb“ zu häufig erweitert wird, was die Leistung beeinträchtigen kann. Die tempdb-Datenbank kann auf die automatische Vergrößerung festgelegt werden, diese Einstellung sollte aber verwendet werden, um den Datenträgerspeicherplatz bei Ausnahmen zu erweitern.
  • Erstellen Sie so viele Dateien, wie benötigt werden, um die Datenträgerbandbreite zu maximieren. Die Verwendung mehrerer Dateien reduziert Speicherkonflikte in „tempdb“ und bietet eine bessere Skalierbarkeit. Erstellen Sie jedoch nicht zu viele Dateien, da dies wiederum die Leistung beeinträchtigen und den Verwaltungsaufwand erhöhen kann. Als allgemeine Richtlinie sollten Sie eine Datendatei für jeden logischen Prozessor auf dem Server erstellen (unter Berücksichtigung eventueller Affinitätsmaskeneinstellungen) und die Anzahl von Dateien dann bei Bedarf nach oben oder unten anpassen. Folgende Faustregel gilt: Wenn die Anzahl von logischen Prozessoren kleiner oder gleich acht ist, verwenden Sie genauso viele Datendateien wie logische Prozessoren. Wenn die Anzahl von logischen Prozessoren größer als acht ist, verwenden Sie acht Datendateien, und erhöhen Sie im Fall andauernder Speicherkonflikte die Anzahl von Datendateien so lange um ein Vielfaches von 4 (bis zur Anzahl von logischen Prozessoren), bis die Konflikte auf ein akzeptables Maß reduziert sind. Alternativ dazu können Sie auch Änderungen an Arbeitsauslastung oder Code vornehmen. Wenn sich die Speicherkonflikte nicht reduzieren lassen, müssen Sie möglicherweise die Anzahl von Dateien weiter erhöhen.
  • Legen Sie alle Dateien auf die gleiche Größe fest – dies ermöglicht ein optimales proportionales Füllen. Die gleiche Größe ist sehr wichtig, da der Algorithmus für das proportionale Füllen auf der Dateigröße basiert. Wenn die Datendateien mit verschiedenen Dateigrößen erstellt werden, versucht der Algorithmus für das proportionale Füllen, die größte Datei häufiger für GAM-Zuordnungen zu verwenden, anstatt die Zuordnungen gleichmäßig auf alle Dateien zu verteilen. Damit wäre die Erstellung mehrerer Dateien sinnlos.
  • Stellen Sie die tempdb-Datenbank auf einem schnellen E/A-Subsystem bereit, und verwenden Sie Solid-State-Laufwerke, um eine optimale Leistung zu erzielen. Verwenden Sie Datenträgerstriping, wenn das System viele direkt angeschlossene Datenträger umfasst.
  • Stellen Sie die tempdb-Datenbank auf anderen als den Datenträgern bereit, die von Benutzerdatenbanken verwendet werden.

Zum Konfigurieren von „tempdb“ können Sie die folgende Abfrage verwenden oder ihre Eigenschaften in Management Studio bearbeiten.

  USE [tempdb]
  GO
  DBCC SHRINKFILE (N'tempdev' , 8)
  GO
  USE [master]
  GO
  ALTER DATABASE [tempdb] MODIFY FILE ( NAME = N'tempdev', NEWNAME = N'tempdb', SIZE = 2097152KB , FILEGROWTH = 512MB )
  GO
  ALTER DATABASE [tempdb] ADD FILE ( NAME = N'tempdb2', FILENAME = N'C:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\DATA\tempdb2.mdf' , SIZE = 2097152KB , FILEGROWTH = 512MB )
  GO

Führen Sie die T-SQL-Abfrage „SELECT *“aus „sys.sysprocesses“ aus, um Seitenbelegungskonflikte in der tempdb-Datenbank zu erkennen. In der Systemtabellenausgabe wird die Warteressource möglicherweise als „2:1:1“ (PFS-Seite) oder „2:1:3“ (SGAM-Seite [Shared Global Allocation Map]) angezeigt. Je nach Konfliktgrad kann dies auch dazu führen, dass SQL Server kurze Zeit nicht reagiert. Ein anderer Ansatz ist die Untersuchung der dynamischen Verwaltungssichten „sys.dm_exec_request“ oder „sys.dm_os_waiting_tasks“ (Dynamic Management Views, DMVs). Die Ergebnisse zeigen, dass diese Anforderungen oder Tasks auf tempdb-Ressourcen warten und ähnliche Werte aufweisen wie die bei Ausführung der sys.sysprocesses-Abfrage angezeigten.

Wenn die bisherigen Empfehlungen die Belegungskonflikte nicht erheblich reduzieren und die Konflikte auf SGAM-Seiten stattfinden, implementieren Sie das Ablaufverfolgungsflag „-T1118“ in die Startparameter für SQL Server, sodass das Ablaufverfolgungsflag auch nach dem Herunterfahren und Neustarten von SQL Server gültig bleibt. Mit diesem Ablaufverfolgungsflag ordnet SQL Server jedem Datenbankobjekt vollständige Blöcke zu und behebt so die Konflikte auf SGAM-Seiten. Beachten Sie, dass dieses Flag sich auf jede Datenbank auf dieser SQL Server-Instanz auswirkt.

Maximaler Grad an Parallelität

Die Standardkonfiguration von SQL Server für kleine bis mittelgroße Bereitstellungen von Operations Manager ist für die meisten Zwecke ausreichend. Wenn die Arbeitsauslastung der Verwaltungsgruppe in ein Szenario der Unternehmensklasse hochskaliert wird (typischerweise mehr als 2.000 mit Agents verwaltete Systeme und eine erweiterte Überwachungskonfiguration einschließlich Überwachung auf Dienstebene mit erweiterten synthetischen Transaktionen, Netzwerkgeräteüberwachung, plattformübergreifender Überwachung usw.), muss die SQL Server-Konfiguration optimiert werden. Diese Optimierung wird im folgenden Abschnitt beschrieben. Eine Konfigurationsoption wurde bisher noch nicht besprochen: MAXDOP.

Die Microsoft SQL Server-Konfigurationsoption MAXDOP (Max. Degree Of Parallelism, maximaler Grad an Parallelität) steuert die Anzahl von Prozessoren, die für die Ausführung einer Abfrage in einem parallelen Plan verwendet werden. Diese Option bestimmt die Computing- und Threadressourcen, die für die parallel arbeitenden Abfrageplanoperatoren verwendet werden. Sie müssen die MAXDOP-Option passend für Ihr Szenario richtig konfigurieren, je nachdem ob SQL Server auf einem SMP-Computer (Symmetric Multiprocessing, symmetrisches Multiprocessing), einem NUMA-Computer (Non-Uniform Memory Access, nicht einheitlicher Speicherzugriff) oder mit hyperthreadingfähigen Prozessoren eingerichtet ist.

Wenn SQL Server auf einem Computer mit mehreren Mikroprozessoren oder CPUs ausgeführt wird, wird für jede Ausführung paralleler Pläne der beste Grad an Parallelität ermittelt, also die Anzahl von Prozessoren, die zum Ausführen einer einzelnen Anweisung verwendet werden. Der Standardwert für diese Option lautet 0, sodass SQL Server den maximalen Grad an Parallelität bestimmen kann.

Die im Zusammenhang mit der Betriebsdatenbank, der Data Warehouse-Datenbank und auch der Überwachungsdatenbank in Operations Manager vordefinierten gespeicherten Prozeduren und Abfragen enthalten die MAXDOP-Option nicht. Dies liegt daran, dass es nicht möglich ist, während der Installation dynamisch abzufragen, wie viele Prozessoren dem Betriebssystem angezeigt werden. Es wird auch nicht versucht, einen hartcodierten Wert für diese Einstellung festzulegen, da dies bei Ausführung der Abfrage negative Auswirkungen hätte.

Hinweis

Die MAXDOP-Konfigurationsoption begrenzt nicht die Anzahl von Prozessoren, die von SQL Server verwendet werden. Um die Anzahl der von SQL Server verwendeten Prozessoren zu konfigurieren, verwenden Sie die Konfigurationsoption „Affinitätsmaske“.

  • Bei Servern, die mehr als acht Prozessoren verwenden, legen Sie die Konfiguration folgendermaßen fest: MAXDOP=8
  • Bei Servern, die acht Prozessoren oder weniger verwenden, legen Sie die Konfiguration folgendermaßen fest: MAXDOP = 0 to N Hinweis: In dieser Konfiguration steht N für die Anzahl von Prozessoren.
  • Für Server mit konfigurierter NUMA-Option sollte MAXDOP die Anzahl von CPUs nicht überschreiten, die jedem NUMA-Knoten zugewiesen sind.
  • Bei Servern mit aktiviertem Hyperthreading sollte der MAXDOP-Wert die Anzahl physischer Prozessoren nicht überschreiten.
  • Bei Servern mit konfigurierter NUMA-Option und aktiviertem Hyperthreading sollte der MAXDOP-Wert die Anzahl physischer Prozessoren pro NUMA-Knoten nicht überschreiten.

Sie können die Anzahl paralleler Worker überwachen, indem Sie „sys.dm_os_tasks“ abfragen.
Die Hardwarekonfiguration dieses Servers bestand aus einem HP Blade G6 mit 24 Kernprozessoren und 196GB Arbeitsspeicher. Die Instanz, auf der die Datenbank „OperationsManager“ gehostet wurde, hatte eine MAXMEM-Einstellung von 64 GB. Nach dem Ausführen der in diesem Abschnitt vorgeschlagenen Optimierungen verbesserte sich die Leistung. Ein Engpass bei parallelen Abfragen bestand jedoch weiterhin. Nach dem Testen verschiedener Werte, wurde die optimale Leistung mit der Einstellung „MAXDOP=4“ gefunden.

Anfängliche Dimensionierung der Datenbank

Es nicht einfach, das zukünftige Wachstum von Operations Manager-Datenbanken innerhalb der ersten Monate nach der Bereitstellung zu prognostizieren – das gilt insbesondere für die Betriebs- und Data Warehouse-Datenbanken. Das Tool für die Dimensionierung von Operations Manager ist sehr hilfreich für die Einschätzung des zukünftigen Wachstums, basierend auf der Formel, die von der Produktgruppe aus den Testergebnissen im Labor abgeleitet wurde. Allerdings werden dabei verschiedene Faktoren nicht berücksichtigt, die sich auf die kurzfristige und langfristige Entwicklung auswirken.

Die anfängliche Datenbankgröße, wie vom Tool für die Dimensionierung vorgeschlagen, sollte an eine prognostizierte Größe angepasst werden, um die Fragmentierung und den damit zusammenhängenden Mehraufwand zu verringern. Diese Werte können während der Einrichtung der Betriebs- und Data Warehouse-Datenbanken angegeben werden. Wenn während des Setups nicht genügend Speicherplatz verfügbar ist, können die Datenbanken später mithilfe von SQL Management Studio erweitert werden. Anschließend können die Datenbanken neu indiziert werden, um sie entsprechend zu defragmentieren und zu optimieren. Diese Empfehlung gilt auch für die ACS-Datenbank.

Die proaktive Überwachung des Wachstums der Betriebs- und Data Warehouse-Datenbanken sollte in einem täglichen oder wöchentlichen Zyklus ausgeführt werden. Dies ist notwendig, um unerwartete und erhebliche Wachstumssprünge zu identifizieren. Danach muss mit der Problembehandlung begonnen werden, um zu ermitteln, ob diese Sprünge durch einen Fehler in einem Management Pack-Workflow (d.h. durch eine Ermittlungsregel, eine Leistungs- oder Ereignissammlungsregel oder eine Monitor- oder Warnungsregel) oder ein anderes Management Pack-Symptom verursacht werden, das während der Test- und Qualitätssicherungsphase des Release Management-Prozesses nicht identifiziert wurde.

Automatische Vergrößerung der Datenbank

Wenn die auf dem Datenträger reservierte Dateigröße der Datenbanken zur Neige geht, kann SQL Server die Datenbanken automatisch vergrößern, entweder um einen Prozentsatz oder um einen festen Betrag. Darüber hinaus kann eine maximale Datenbankgröße konfiguriert werden, um zu verhindern, dass der gesamte auf dem Datenträger verfügbare Speicherplatz belegt wird. Standardmäßig ist die automatische Vergrößerung nicht für die Operations Manager-Datenbank, sondern nur für die Data Warehouse- und ACS-Datenbanken aktiviert.

Nutzen Sie die automatische Vergrößerung nur als Notfalllösung für unerwartetes Wachstum. Die automatische Vergrößerung führt zu Leistungseinbußen, die bei transaktionalen Datenbanken berücksichtigt werden müssen. Folgende Einbußen müssen unter Umständen einkalkuliert werden:

  • Fragmentierung der Protokolldatei oder Datenbank, wenn Sie kein geeignetes Inkrement für das Wachstum angeben.
  • Wenn Sie eine Transaktion ausführen, die mehr als den verfügbaren Protokollspeicherplatz erfordert, und die automatische Vergrößerungsoption für das Transaktionsprotokoll dieser Datenbank aktiviert haben, umfasst der Zeitraum für das Abschließen der Transaktion auch den Zeitraum, den das Transaktionsprotokoll für die Vergrößerung auf die konfigurierte Menge benötigt.
  • Wenn Sie eine große Transaktion ausführen, die eine Vergrößerung des Protokolls erfordert, müssen auch andere Transaktionen, die in das Transaktionsprotokoll schreiben müssen, so lange warten, bis der Vergrößerungsvorgang abgeschlossen ist.

Wenn Sie die Optionen für die automatische Vergrößerung und die automatische Verkleinerung kombinieren, verursachen Sie möglicherweise unnötigen Aufwand. Stellen Sie sicher, dass die Schwellenwerte, die Vergrößerungs- und Verkleinerungsvorgänge auslösen, nicht zu häufigen Änderungen der Datenbankgröße nach oben oder unten führen. Ein Beispiel: Sie führen eine Transaktion aus, durch die das Transaktionsprotokoll zum Zeitpunkt des Commits um 100 MB wächst. Einige Zeit später startet der Vorgang zu automatischen Verkleinerung und verkleinert das Transaktionsprotokoll um 100 MB. Danach führen Sie die gleiche Transaktion erneut aus, und diese vergrößert das Transaktionsprotokoll wieder um 100 MB. In diesem Beispiel wird unnötiger Aufwand sowie möglicherweise eine Fragmentierung der Protokolldatei verursacht. Beides kann sich negativ auf die Leistung auswirken.

Es empfiehlt sich, diese beiden Einstellungen sorgfältig zu konfigurieren. Die genaue Konfiguration richtet sich nach Ihrer Umgebung. Im Allgemeinen empfiehlt es sich, die Datenbankgröße um einen festen Betrag zu erhöhen, um die Datenträgerfragmentierung zu minimieren. In der folgenden Abbildung sehen Sie ein Beispiel: Die Datenbank ist so konfiguriert, dass sie jedes Mal um 1024MB wächst, wenn eine automatische Vergrößerung erforderlich ist.

Richtlinie für Clusterfailover

Windows Server Failover Clustering ist eine Hochverfügbarkeitsplattform, die ständig die Netzwerkverbindungen und die Integrität der Knoten in einem Cluster überwacht. Wenn ein Knoten über das Netzwerk nicht erreichbar ist, wird eine Wiederherstellungsaktion ausgeführt, um die Anwendungen und Dienste auf einem anderen Knoten im Cluster wieder online zu schalten. Die Standardeinstellungen sind für Fehlersituationen optimiert, in denen ein Server vollständig ausfällt. Eine Wiederherstellung ist nicht möglich, wenn es sich um nicht redundante Hardware oder Stromversorgungskomponenten handelt. In diesen Situationen wird der Server als verloren betrachtet, und das Ziel für Failover Clustering ist es, den Verlust schnell zu erkennen und die notwendige Funktionalität auf einem anderen Server im Cluster wiederherzustellen. Um eine solche sehr schnelle Wiederherstellung nach schwerwiegenden Ausfällen zu erreichen, sind die Standardeinstellungen für die Überwachung der Clusterintegrität ziemlich aggressiv. Sie lassen sich aber vollständig konfigurieren und bieten somit Flexibilität für eine Vielzahl von Szenarien.

Diese Standardeinstellungen bieten das optimale Verhalten für die meisten Kunden. Da die Knoten in einem Cluster aber mehrere Kilometer auseinander liegen können, kann der Cluster durch zusätzliche und potenziell unzuverlässige Netzwerkkomponenten zwischen den Knoten gefährdet sein. Ein weiterer Faktor ist, dass die Qualität von Basisservern immer besser wird und dass redundante Komponenten (zwei Netzteile, NIC-Teamvorgänge und Multipfad-E/A) für eine mehr Stabilität der Systeme sorgen. Daher treten Ausfälle nicht redundanter Hardwarekomponenten eher selten auf. Da schwerwiegende Fehler seltener auftreten, möchten einige Kunden den Cluster für vorübergehende Fehler optimieren, um mehr Stabilität bei kurzen Netzwerkausfällen zwischen den Knoten zu erzielen. Indem Sie die Standardschwellenwerte für Fehler erhöhen, können Sie die Anfälligkeit bei kurzen Netzwerkausfällen reduzieren.

Es gibt kein Patentrezept für diese Einstellungen. Welche Einstellungen für Ihr Unternehmen optimal sind, hängt von Ihren spezifischen Geschäftsanforderungen und SLAs ab.

Virtualisieren von SQL Server

In virtuellen Umgebungen empfiehlt es sich aus Leistungsgründen, die Betriebsdatenbank und die Data Warehouse-Datenbank auf einem direkt angeschlossenen Datenträger zu speichern, nicht auf einem virtuellen Datenträger. Verwenden Sie immer das Tool zur Dimensionierung von Operations Manager, um die erforderlichen IOPS einzuschätzen, und führen Sie Belastungstests auf Ihren Datenträgern aus, um die Einstellungen zu überprüfen. Sie können das SQLIO-Tool für diese Aufgabe verwenden. Weitere Informationen zu virtualisierten Operations Manager-Umgebungen finden Sie unter Virtualisierungsunterstützung in Operations Manager.

Always On-Design und Wiederherstellungsmodell

Ein wichtiger Aspekt bei Always On-Verfügbarkeitsgruppen ist die Tatsache, dass für dieses Feature die Datenbanken entwurfsbedingt auf das Wiederherstellungsmodell „Vollständig“ festgelegt werden müssen. Das heißt, dass Transaktionsprotokolle erst verworfen werden, wenn entweder eine vollständige Sicherung oder nur eine Sicherung des Transaktionsprotokolls ausgeführt wurde. Aus diesem Grund ist eine Sicherungsstrategie kein optionaler, sondern ein erforderlicher Bestandteil des Always On-Designs für Operations Manager-Datenbanken. Andernfalls belegen die Transaktionsprotokolle im Laufe der Zeit immer mehr Speicherplatz auf den zugehörigen Datenträgern.

Bei einer Sicherungsstrategie müssen die Details Ihrer Umgebung berücksichtigt werden. In der folgenden Tabelle finden Sie einen typischen Sicherungszeitplan.

Art der Sicherung Zeitplan
Nur Transaktionsprotokoll Jede Stunde
Vollständig Wöchentlich, Sonntag um 3:00 Uhr

Optimieren der SQL Server Reporting Services

Die Reporting Services-Instanz fungiert als Proxy für den Zugriff auf Daten in der Data Warehouse-Datenbank. Die Instanz generiert und zeigt Berichte basierend auf Vorlagen, die in Management Packs gespeichert sind.

Hinter den Kulissen gibt es eine SQL Server-Datenbank-Instanz, die die Datenbanken ReportServer und ReportServerTempDB hostet. Es gelten allgemeine Empfehlungen bezüglich der Leistungsoptimierung dieser Instanz.

Hinweis

Ab SQL Server Reporting Services (SSRS) 2017, Version 14.0.600.1274 und höher, lassen die Standardsicherheitseinstellungen keine Uploads von Ressourcenerweiterungen mehr zu. Dies führt bei der Bereitstellung von Berichterstellungskomponenten zu ResourceFileFormatNotAllowedException-Ausnahmen in Operations Manager.

Um dieses Problem zu beheben, öffnen Sie SQL Management Studio, stellen Sie eine Verbindung mit Ihrer Reporting Services-Instanz her, öffnen Sie EigenschaftenErweitert, und fügen Sie *.* zur Liste für AllowedResourceExtensionsForUpload hinzu. Alternativ dazu können Sie auch die vollständige Liste der Operations Manager-Erweiterungen für die Berichterstellung zur Zulassungsliste in SSRS hinzufügen.

Nächste Schritte

Erfahren Sie, wie Sie das Hosting von Reporting-Data Warehouse hinter einer Firewall konfigurieren können unter Connect Reporting Data Warehouse Across a Firewall (Verbinden von Reporting-Data Warehouse durch eine Firewall).