FIM-Optimierung und beste Praktiken für die Leistung

Befolgen Sie zunächst die bewährten Verfahren Ihrer Virtualisierungsplattform. Best Practices führen im Allgemeinen zu einer besseren Leistung und Stabilität. Die folgenden Links führen Sie zu Empfehlungen für bewährte Verfahren:

• Performance-Best Practices für VMware vSphere™ 5.5 (Performance-Best Practices für VMware vSphere 5.5)
• Performance-Best Practices für VMware vSphere™ 5.0 (Performance-Best Practices für VMware vSphere™ 5.0)
• Windows Server 2012 Hyper-V Best Practices (in Form einer einfachen Checkliste) (Windows Server 2012 Hyper-V Best Practices)

• Integrationsdienste sollten auf jedem VM-Gast installiert werden
• Die Integrationsdienste sollten die richtige Version für den Hypervisor haben.

• Die Überbelegung von virtuellen Prozessoren (Zuweisung von mehr Prozessorkernen an den Gast, als aufgrund der Nutzung durch andere Prozesse durchgängig verfügbar sind) kann zu Verzögerungen bei der Erfüllung von Anforderungen in Hochleistungssystemen führen. Zum Beispiel vier (4) virtuelle Maschinen mit vier (4) Prozessoren, wenn nur acht (8) Kerne zur Verfügung stehen.

Wenn Sie die Prozessoren überlasten müssen, lesen Sie bitte den nächsten Punkt (CPU-Bereitschaftszeit), um zu erfahren, wie Sie einen festgefahrenen Zustand erkennen können.

• Überprüfung der CPU-Bereitschaftszeit (VMWare) oder Virtueller Prozessor\CPU Wartezeit pro Auftrag (Hyper-V) regelmäßig zu überprüfen, um sicherzustellen, dass die Lösung nicht auf Prozessorzeit wartet
  • In diesem Beitrag finden Sie die folgenden Hinweise zur Bedeutung des Zählers für die CPU-Bereitschaftszeit:

• • Das Hyper-V-Äquivalent zur CPU-Bereitschaftszeit von VMware (Kehayias, Hyper-V Equivalent to VMware CPU Ready Time, 2013

• Die folgenden Artikel bieten zusätzliche Informationen zu diesem Thema und sind sehr lesenswert:
  • CPU-Überbelastung und ihre Auswirkungen auf die SQL Server-Leistung unter VMware (Klee, 2012)
  • SQL SERVER - vCPUs - Wie viele sind zu viele CPUs für die SQL Server-Virtualisierung? - Notizen aus der Praxis #003 (SQL SERVER - vCPUs - Wie viele sind zu viele CPUs für die SQL Server-Virtualisierung? - Hinweise aus der Praxis #003)

• Die Überbelegung von Arbeitsspeicher ist eine nützliche Virtualisierungsfunktion, wenn sie richtig eingesetzt wird. Overcommitting sollte in Situationen vermieden werden, in denen VM-Gäste routinemäßig längere Zeiträume haben, in denen sie den RAM für Anwendungszwecke benötigen. SQL Server ist jedoch eine Anwendung, die wahrscheinlich über längere Zeiträume Arbeitsspeicher benötigt und bei der es zu Leistungseinbußen aufgrund von Swapping kommen kann.

Die richtige Konfiguration des Antiviren-Clients kann die Zeit, in der Ressourcen während der Echtzeitüberprüfung gesperrt sind, drastisch reduzieren. Verwenden Sie die folgenden Konfigurationsinformationen, um die Leistung zu verbessern, indem Sie die Wartezeiten für gesperrte Ressourcen reduzieren:

Die folgenden Empfehlungen zur Konfiguration des Antiviren-Clients für die Hyper-V-Rolle stammen aus WINDOWS ANTIVIRUS EXCLUSION RECOMMENDATIONS ( Helmick, 2014).

• Vmms.exe
• Vmwp.exe

• AlleVHD,VHDX,AVHD,VSV und ISO-Dateien
  • *.vhd
  • *.vhdx
  • *.avhd
  • *.vsv
  • *.iso

• Standardverzeichnis für die Konfiguration der virtuellen Maschine: C:\ProgramData\Microsoft\Windows\Hyper-V
• Benutzerdefinierte Konfigurationsverzeichnisse für virtuelle Maschinen
• Standardverzeichnis für virtuelle Festplatten: C:\Benutzer\Publikum\Dokumente\Hyper-V\Virtuelle Festplatten
• Benutzerdefinierte Verzeichnisse für virtuelle Festplatten
• Benutzerdefinierte Replikationsdatenverzeichnisse, wenn Sie Hyper-V Replica verwenden
• Schnappschuss-Verzeichnisse
• C:\Clusterstorage und alle Unterverzeichnisse (bei Verwendung von Live Migration zusammen mit Cluster Shared Volumes)

Hinweis: Die unten angegebenen Pfade sind Standardpfade und können bei Ihrer Installation geändert worden sein.

Die folgenden Empfehlungen für die Konfiguration des Antivirus-Clients für die SQL-Anwendung stammen aus EMPFEHLUNGEN ZUM AUSSCHLUSS VON WINDOWS-VIRENSCHUTZ (Helmick, 2014).

• %ProgramFiles%\Microsoft SQL Server\MSSQL11.<Instance Name>\MSSQL\Binn\SQLServr.exe

• %ProgramFiles%\Microsoft SQL Server\MSRS11.<Instance Name>\Reporting Services\ReportServer\Bin\ReportingServicesService.exe

• %ProgramFiles%\Microsoft SQL Server\MSAS11.<Instance Name>\OLAP\Bin\MSMDSrv.exe

Wenn Sie einen Windows-Cluster verwenden, sollten Sie die folgenden bewährten Verfahren anwenden (Antivirus software , das nicht Cluster-fähig ist, kann Probleme mit Cluster Services, 2012, verursachen)

• Antivirus software muss clusterfähig sein
• Ausgeschlossen sind die folgenden Orte:
  • Q:\ (Quorum-Laufwerk)
  • C:\Windows\Cluster
  • Temp-Verzeichnis des Dienstkontos des SQL-Clusters

• SQL-Server-Datendateien
  • *.mdf
  • *.ldf
  • *.ndf

• SQL Server-Sicherungsdateien
  • *.bak
  • *.trn

• Speicherorte der Volltextkatalogdateien: (Dateispeicherorte für Standard- und benannte Instanzen vonSQL Server)
  • Standard-Instanz: Programmdateien\Microsoft SQL Server\MSSQL\FTDATA
  • Benannte Instanz: Programmdateien\Microsoft SQL Server\MSSQL$instancename\FTDATA

• Trace-Dateien
  • *.trc - diese Dateien können entweder erzeugt werden, wenn Sie die Profiler-Verfolgung manuell konfigurieren oder wenn Sie die C2-Überwachung für den Server aktivieren.

• SQL-Audit-Dateien (fürSQL Server 2008 oder spätere Versionen)
  • *.sqlaudit

• SQL-Abfragedateien
  • *.sql

• Daten der Analysedienste
  • Standardspeicherort ist C:\Programme\Microsoft SQL Server\MSSQL.X\OLAP\Data.

• Temporäre Dateien der Analysis Services
  • Standardspeicherort ist C:\Programme\Microsoft SQL Server\MSSQL.X\OLAP\Data.

• Analysis Services-Sicherungsdateien
  • Standardspeicherort ist C:\Programme\Microsoft SQL Server\MSSQL.X\OLAP\Backup

• Analysis Services-Protokolldateien
  • Standardspeicherort ist C:\Programme\Microsoft SQL Server\MSSQL.X\OLAP\Log

• Filestream-Datendateien (SQL 2008 und spätere Versionen)
• Remote Blob Storage-Dateien (SQL 2008 und spätere Versionen)
• Reporting Services temporäre Dateien und Protokolle (RSTempFiles und LogFiles)

Hinweis: Die oben angegebenen Pfade sind Standardpfade und können bei Ihrer Installation geändert worden sein.

Die folgenden Empfehlungen für die Konfiguration des Antivirus-Clients für die IIS-Rolle stammen aus EMPFEHLUNGEN ZUM AUSSCHLUSS VON WINDOWS-VIRENSCHUTZ (Helmick, 2014).

• %systemroot%\system32\inetsrv\w3wp.exe
• %systemroot%\SysWOW64\inetsrv\w3wp.exe

• IIS-Komprimierungsverzeichnis: %SystemDrive%\inetpub\temp\IIS Temporary Compressed Files

Die folgenden Empfehlungen für die Konfiguration des Antivirus-Clients für die SharePoint-Anwendung stammen aus EMPFEHLUNGEN ZUM AUSSCHLUSS VON WINDOWS-VIRENSCHUTZ (Helmick, 2014).

• Laufwerk:\Programmdateien\Gemeinsame Dateien\Microsoft Shared\Web Server Extensions
• Wenn Sie nicht den gesamten Ordner "Webserver-Erweiterungen" von der Antiviren-Überprüfung ausschließen möchten, können Sie nur die folgenden zwei Ordner ausschließen:
  • * Laufwerk:\Programmdateien\Gemeinsame Dateien\Microsoft Shared\Web Server Extensions\15\Logs
  • * Laufwerk:\Programmdateien\Gemeinsame Dateien\Microsoft Shared\Web Server Extensions\15\Daten\Anwendungen

• Hinweis: Wenn Sie ein bestimmtes Konto fürSharePoint-Dienste oder Anwendungspool-Identitäten verwenden, müssen Sie möglicherweise auch die folgenden Ordner ausschließen:
  • * Laufwerk:\Benutzer\ServiceAccount\AppData\Local\Temp
  • * Laufwerk:\Benutzer\Standard\AppData\Local\Temp

Die folgenden Verzeichnisausschlüsse können verwendet werden, um das Scannen von Lösungsdateien während der Verarbeitung durch FIM zu minimieren:

• Schließen Sie die FIM-Binärdateien aus: C:\Programmdateien\Microsoft Forefront Identity Manager\2010\Synchronisierungsdienst\
• Schließen Sie alle Kunden aus, die für Verwaltungsagenten benötigt werden:
  • Notizen Client: E:\Noten
  • Oracle Binaries: E:\Oracle

• Schließen Sie die FIM-Binärdateien aus: C:\Programmdateien\Microsoft Forefront Identity Manager\2010\Service

Die richtige Konfiguration und Optimierung des SQL-Servers ist entscheidend für die bestmögliche Leistung von FIM. Wenn Leistungsprobleme auftreten, würde ich zuerst die SQL-Konfiguration überprüfen. Die unten aufgeführten Punkte sind nicht in einer bestimmten Prioritätsreihenfolge aufgeführt. Jeder Punkt sollte bei der Validierung der SQL-Serverkonfiguration berücksichtigt werden.

• Befolgen Sie die bewährten Verfahren, die in der Einstellung des Antiviren-Clients des SQL-Servers im vorherigen Abschnitt aufgeführt sind.

• Alle Festplattenpartitionen sollten vor der Durchführung von Installationen auf Probleme mit der Festplattenausrichtung überprüft werden. Dies gilt insbesondere für alle Partitionen, die von einem Windows-Betriebssystem vor Windows 2008 erstellt wurden. Disk Partition Alignment Best Practices for SQL Server (May & Lee, 2009) bietet eine Anleitung zur Erkennung und Behebung dieses Problems. Auch wenn diese Anleitung für SQL 2008 geschrieben wurde, gilt sie auch für neuere SQL-Versionen.
• Unterhalb der logischen Festplattenpartitionen befinden sich leistungsbeeinflussende Elemente wie die RAID-Blockgröße und die physische Festplattensektorgröße. Je nach RAID-Anbieter und Festplattenhersteller gibt es unterschiedliche Anleitungen. Erkundigen Sie sich bei den entsprechenden Anbietern, um sicherzustellen, dass die physische Implementierung Ihres logischen Speicherplatzes optimiert ist.

• Festplatten-E/A pro Sekunde (IOPs) sollten sorgfältig durchdacht und richtig geplant werden. Gehen Sie nicht davon aus, dass das SAN unbegrenzte E/A bietet oder dass die SAN-Konfiguration ideal für die Anforderungen des Designs ist.
• Das zugrunde liegende Festplattensubsystem und die RAID-Levels sind für die Optimierung der Festplattenleistung äußerst wichtig. Diese Aussage gilt insbesondere bei der Verwendung von physischen Servern mit lokal angeschlossenem Speicher. SAN-Anbieter bieten in der Regel Tuning-Anleitungen für die SAN-Konfiguration, um Anwendungen wie SQL Server optimal zu unterstützen.
• Ein SQL-Server hat unterschiedliche IO-Nutzungsmuster. Diese Nutzungsmuster können von der Verwendung unterschiedlicher Leistungsstufen von Festplatten profitieren. SQL SERVER - Virtualized SQL Server Performance and Storage System - Notes from the Field #013 schlägt vor, die SQL-Komponenten auf verschiedene virtuelle Festplatten mit unterschiedlichen Speichereigenschaften aufzuteilen. (z. B. benötigt die SQL-Datenbank eine schnelle Festplatte, während das SQL-Backup keine schnelle Festplatte, aber viel Speicherplatz benötigt).
• Die folgenden Zähler sind nützlich, um diskIO-Probleme zu erkennen:
  • Logische Festplatte - Avg. Disk Queue Length > 1 weist auf einen anhaltenden Rückstau von IO-Anforderungen hin
  • Logische Festplatte - Split I/O - nützlich bei der Erkennung von Fragmentierung
  • Logische Festplatte - %Disk Time >= 80%

• Defragmentieren Sie sowohl die Festplatten des virtuellen Hosts als auch die des virtuellen Gastes, um die Fragmentierung zu verringern.
• Verwenden Sie ein kommerzielles Festplatten-Defragmentierungsprogramm, das große Dateien defragmentieren kann. Die Standard-Defragmentierung des Betriebssystems software ist nicht in der Lage, große Dateien (> 64 MB) zu defragmentieren, wodurch große Dateien, wie z. B. eine Datenbank, über nicht zusammenhängenden Speicherplatz verteilt bleiben können.
• Physische Festplatte (virtueller Host)
  • Physische Festplatten können fragmentiert werden, wenn große Dateien wie virtuelle Festplatten (VHDs) erweitert werden.
  • Stellen Sie die Größe der virtuellen Festplattendateien auf die vorgesehene Größe ein. Lassen Sie die VHDs nicht automatisch wachsen.
  • Defragmentieren Sie die physischen Volumes, wenn die Größe der virtuellen Festplatten geändert wird, um eine zusammenhängende Festplattennutzung zu gewährleisten.
  • Legen Sie keine virtuellen Festplatten auf Systempartitionen ab

• Virtuelle Festplatte
  • Planen Sie die Defragmentierung in den Zeiten, in denen keine Backups durchgeführt werden.
  • Begrenzen Sie die Anzahl der virtuellen Festplatten für die gleichzeitige Defragmentierung, um die IO-Belastung des Festplatten-Subsystems zu reduzieren.
  • Defragmentieren Sie die Volumes vor der Installation, nach der Installation und nach der Vorab-Größe der Datenbank
  • Vermeiden Sie die Defragmentierung von VM-Gästen, die einen Snapshot haben. Die Defragmentierung kann den Snapshot wachsen lassen.
  • Auslagerungsdateien sollten auf eine eigene virtuelle Festplatte gelegt werden, um die Fragmentierung der Systempartition zu verringern.

• Fragmentierung der Datenbankdatei
  • Bei Datenbankdateien handelt es sich in der Regel um größere Dateien, die auf physischen oder logischen Laufwerken gespeichert sind und mit den Defragmentierungswerkzeugen des Betriebssystems nicht einfach defragmentiert werden können. Wenn diese Dateien wachsen, ist es möglich, dass die Datenbanken selbst in nicht zusammenhängenden Speicherplatz aufgeteilt werden, was die Leistung verlangsamt. Ist dies der Fall, wird empfohlen, ein kommerzielles Defragmentierungsprogramm software zu verwenden, um die Fragmentierung zu verringern. Weitere Informationen zur Verringerung der durch das Datenbankwachstum verursachten Fragmentierung finden Sie unter "Vorab-Größenbestimmung der Datenbanken".

• Geben Sie die Größe der FIM-Datenbanken mit der Anfangsgröße aus der Laborumgebung vor. Die Vorab-Größe der Datenbank auf die erwartete Größe reduziert die zukünftige Fragmentierung der Festplatte, wenn andere Dateien auf demselben Volume vorhanden sind. Wenn sich beispielsweise zwei Datenbanken auf demselben Datenträger befinden und eine Datenbank wächst, muss sie möglicherweise nicht zusammenhängenden Speicherplatz für das Wachstum nutzen. Durch die Vorab-Größenanpassung können die Datenbanken ihre vorgesehene Größe erreichen, ohne dass sie in nicht zusammenhängenden Speicherplatz expandieren müssen.
• Im Idealfall sollte eine Datenbank mit vorgegebener Größe nicht wachsen, aber oft treten Ereignisse ein, die uns daran hindern, innerhalb der bei der anfänglichen Größenbestimmung festgelegten Grenzen zu bleiben. Es wird empfohlen, dass der DBA das Wachstum in größeren Blöcken (500 MB) zulässt, um ein ständiges Wachstum der Datenbank während der Verarbeitungszyklen zu vermeiden. Diese Praxis trägt auch dazu bei, die Fragmentierung der Festplatte zu verringern.
• Die folgenden Befehle können verwendet werden, um die Größe der Datenbanken und Protokolldateien zu erweitern und die Wachstumsmuster zu ändern:

• Sprechen Sie mit dem DBA über die angemessene Größe und Anzahl der Temp-DB-Dateien, die der Lösung hinzugefügt werden sollten. Als Faustregel gilt eine Temp-DB pro Prozessorkern, vorausgesetzt, das Plattensubsystem kann die IO-Anforderungen mehrerer Dateien effizient unterstützen. Die Idee ist, den Durchsatz zur Temp-DB zu maximieren, um die Leistung der Anwendung zu steigern.
• Die Temp-DBs sollten auf einer schnellen Festplatte gespeichert werden, da sie vom FIM-Dienst stark genutzt werden.
• Passen Sie die Größe der Standard-Temp-DB an die Größe der zusätzlichen Temp-DBs an, die erstellt werden sollen. Denken Sie daran, die Größe entsprechend den typischen Größen- und Wachstumsmustern zu bestimmen.

• Fügen Sie zusätzliche Temp-DBs gemäß der Empfehlung des DBAs hinzu.

• In einem SQL-Cluster lokale Festplatten für Temp-DBs verwenden (neue Funktion in SQL 2012)

Von SQL-Fragmentierung spricht man, wenn Indizes und Kataloge stark fragmentiert sind. SQL nutzt dies, um die Leistung von Abfragen zu steigern. Um die optimale Leistung von SQL aufrechtzuerhalten, ist es eine gute Praxis, Indizes und Volltextkataloge regelmäßig neu zu erstellen.

• Fragmentierung des Index
  • Erstellen Sie einen wöchentlichen Wartungsplan, um Indizes neu zu erstellen und Statistiken für alle Benutzerdatenbanken zu aktualisieren.

• Volltext Katalogfragmentierung
  • Planen Sie die Reorganisation des Volltextkatalogs für Zeiten außerhalb der Spitzenzeiten. Der folgende Artikel enthält eine Anleitung, wie Sie dies einrichten können: Wie man den Neuaufbau von FIM-Volltextindizes automatisiert (Bradley, 2014)
  • Der folgende Artikel beschreibt, wie Sie den Fragmentierungsgrad der Volltextkataloge bestimmen können: Volltextfragmentierung (iFTS)

• Stellen Sie sicher, dass alle FIM-Komponenten in der gesamten Lösung die gleichen Versionsstände aufweisen. (FIM-Synchronisierungs-Engine, FIM-Service, FIM-Client usw.)

• Installieren Sie den FIM Best Practice Analyzer und führen Sie ihn aus (FIM Best Practice Analyzer für FIM 2010 R2, n.d.)

• Stellen Sie sicher, dass alle Attribute, die in "Joins" oder Metaverse-Suchen verwendet werden, in der Metaverse-Konfiguration für das Attribut korrekt indiziert sind.
• Entfernen Sie die Indizierung von allen Metaverse-Attributen, die nicht aktiv sind, indem Sie dies in Joins oder Metaverse-Suchen verwenden.
• Bewertung der "Out-of-Band"-Codierungsaktivitäten. Aufrufe an Systeme innerhalb des FIM-Bereitstellungscodes an externe Ressourcen (AD, SQL-Datenbank) sind mit hohen Latenzzeiten verbunden. Selbst kleine Verzögerungen (10 Millisekunden) summieren sich, wenn sie bei Tausenden von Objekten auftreten. Setzen Sie Aktivitäten außerhalb der Bandbreite sinnvoll ein. Ziehen Sie die Verwendung von benutzerdefinierten Workflows in Betracht, um die in der Out-of-Band-Aktivität erstellten Funktionen bereitzustellen.
• Wenn externe Ressourcen (z.B. SQL-Datenbank) während einer "out of band"-Codierungsaktivität aufgerufen werden müssen, dann muss der Auf- und Abbau von Verbindungen zu diesen externen Ressourcen in den "Initialize"- und "Terminate"-Methoden für die Erweiterung erfolgen, und nicht in den "Provision"- oder "Flow"-Methoden. Für Code, der nicht thread-sicher ist, sollte Pooling oder Caching implementiert werden.
• Bewerten Sie die Leistung der "inbound"-Logik. Schlecht abgestimmter .NET-Code (auch wenn er den Prozesskontext der Sync-Engine nie verlässt) hat große Auswirkungen. Selbst einfache Dinge wie die Verwendung von String-Flags ("Y"/"N") im Vergleich zu booleschen Werten können einen großen Unterschied in der zugrundeliegenden Leistung ausmachen.
• Wenn es eine große Anzahl gültiger Trenner gibt, verwenden Sie die Filterfunktion Deklariert (Importfilter) anstelle der Filterfunktion Deklariert. Dies kann die Synchronisierungszeiten drastisch verkürzen, da die Objekte nicht während des Zyklus verarbeitet werden müssen. Weitere Informationen zu diesem Thema finden Sie hier (Drewes, 2012).

• SharePoint Foundation Search-Dienst entfernen
• Aktivieren Sie nur die für die Lösung benötigten MPRs. Deaktivieren Sie MPRs, die für die Lösung nicht benötigt werden, wie z. B. ein "All Powerful MPR", das möglicherweise zur Behebung eines Problems mit FIM-Berechtigungen erstellt wurde, da diese MPRs für jede Transaktion mehrere Anfragen erstellen.
• Entfernen Sie alle unnötigen Sets aus der Lösung
• Stellen Sie sicher, dass es keine zirkulären MPR gibt, indem Sie sicherstellen, dass die MPR-Filter so eng wie möglich definiert sind, um Überschneidungen zu vermeiden, die zu einer zirkulären Schleife führen könnten.
• Stellen Sie sicher, dass Client-Aktualisierungsanforderungen nur Attribute aktualisieren, die sich tatsächlich ändern. Wenn Sie beispielsweise ein Attribut auf den Wert setzen, den es bereits hat, werden MPRs ausgelöst, die wahrscheinlich nicht ausgeführt werden müssen.
• Sicherstellen, dass die Mindestanzahl von Anfragen, die zur Lösung des Geschäftsproblems erforderlich sind, verwendet wird (mehrere Attributaktualisierungen für dasselbe Objekt in einer einzigen Anfrage zusammenfassen).
• Kombinieren Sie mehrere Attributaktualisierungen in einer einzigen Anfrage. Dies bedeutet, dass der eingebaute Funktionsauswerter vermieden werden sollte, wenn mehrere Attribute desselben Objekts aktualisiert werden. Verwenden Sie stattdessen den WAL, eine andere Aktivität eines Drittanbieters oder schreiben Sie Ihre eigene.
• Erwägen Sie die Verwendung von FIM-Dienst-Partitionen, um die Anfragelast auf mehrere Instanzen des FIM-Dienstes zu verteilen.
• Für Massenoperationen sollten Sie die Verwendung eines Webservice-Clients in Betracht ziehen, um direkt mit dem FIM-Dienst zu kommunizieren, anstatt die PowerShell-Cmdlets zu verwenden

• In einigen Fällen ist es sinnvoll, die Datenbanken der Synchronisations-Engine und des FIM-Dienstes auf getrennten Servern zu betreiben. Dabei ist zu beachten, dass Daten aus einer Datenbank in die andere Datenbank einfließen bzw. diese verlassen. Wenn in einer Datenbank Ressourcenbeschränkungen auftreten, führt dies zu Leistungsproblemen in der anderen Datenbank.
• SCSM-Datenbanken sollten idealerweise auf einem anderen SQL-Server als die FIM-Dienst-Datenbank platziert werden, da es zu Problemen mit der Ressourcenbeschränkung kommen kann, wie oben in der Diskussion über die FIM-Sync/FIM-Dienst-Datenbank erwähnt.
• Bei der Virtualisierung der Server müssen Sie besonders auf die zugrunde liegende hardware achten. Wenn Sie beispielsweise drei separate SQL-Server auf demselben physischen Host oder auf denselben Festplatten betreiben, kann es sein, dass Sie aufgrund von Ressourcenbeschränkungen nicht die erwartete Leistung erhalten.

Antivirus software , das nicht Cluster-fähig ist, kann Probleme mit Cluster-Diensten verursachen. (2012, 17. August). Abgerufen von https://support.microsoft.com/kb/250355

Bradley, B. (2014, Jan 1). Wie man den Neuaufbau von FIM-Volltextindizes automatisiert. Abgerufen von https://social.technet.microsoft.com/wiki/contents/articles/5701.how-to-automate-the-rebuilding-of-fim-full-text-indexes.aspx

Drewes, F. (2012, Jan 8). Vor-Import-Filterung von AD-Objekten in FIM 2010 R2. Abgerufen von https://social.technet.microsoft.com/wiki/contents/articles/6600.pre-import-filtering-of-ad-objects-in-fim-2010-r2.aspx.

Dateispeicherorte für Standard- und benannte Instanzen von SQL Server. (n.d.). Abgerufen von https://msdn.microsoft.com/en-us/library/ms143547%28v=sql.110%29.aspx

FIM Best Practice Analyzer für FIM 2010 R2. (n.d.). Abgerufen von https://technet.microsoft.com/en-us/library/jj203402%28v=ws.10%29.aspx

Helmick, B. (2014, Januar 16). Umfassendes AV-Ausschlussdokument. Abgerufen von https://sdrv.ms/LES7gB

Kehayias, J. (2012, November 29). CPU-Bereitschaftszeit in VMware und wie man ihre wahre Bedeutung interpretiert. Abgerufen von https://www.sqlskills.com/blogs/jonathan/cpu-ready-time-in-vmware-and-how-to-interpret-its-real-meaning/.

Kehayias, J. (2013, November 13). Hyper-V-Äquivalent zu VMware CPU-Bereitschaftszeit. Abgerufen von https://www.sqlskills.com/blogs/jonathan/hyper-v-equivalent-to-vmware-cpu-ready-time/

Klee, D. (2012, Dezember 12 17). CPU Overcommitment und seine Auswirkungen auf die SQL Server-Performance unter VMware. Abgerufen von https://www.davidklee.net/2012/12/17/cpu-overcommitment-and-its-impact-on-sql-server-performance-on-vmware/.

May, J., & Lee, D. (2009, Mai). Best Practices für die Ausrichtung von Festplattenpartitionen für SQL Server. Abgerufen von https://msdn.microsoft.com/en-us/library/dd758814.aspx.

Performance Best Practices für VMware vSphere 5.5. (n.d.). Abgerufen von https://www.vmware.com/pdf/Perf_Best_Practices_vSphere5.5.pdf.

Performance Best Practices für VMware vSphere™ 5.0. (n.d.). Abgerufen von https://www.vmware.com/pdf/Perf_Best_Practices_vSphere5.0.pdf

Pinal, D. (2014, Januar). SQL SERVER - Virtualisiertes SQL Server Leistungs- und Speichersystem - Notizen aus der Praxis #013. Abgerufen von https://blog.sqlauthority.com/2014/01/30/sql-server-virtualized-sql-server-performance-and-storage-system-notes-from-the-field-013/

SQL SERVER - vCPUs - Wie viele sind zu viele CPUs für SQL Server Virtualisierung? - Anmerkungen aus der Praxis #003. (n.d.). Abgerufen von https://blog.sqlauthority.com/2013/11/21/sql-server-vcpus-how-many-are-too-many-cpu-for-sql-server-virtualization-notes-from-the-field-003/

Windows Server 2012 Hyper-V Best Practices. (n.d.). Abgerufen von https://blogs.technet.com/b/askpfeplat/archive/2013/03/10/windows-server-2012-hyper-v-best-practices-in-easy-checklist-form.aspx

SQL SERVER - Virtualisierte SQL Server-Leistung und Speichersystem - Anmerkungen aus der Praxis #013 (Pinal, 2014)

Vielen Dank an Rex Wheeler und Sami Van Vliet für ihre Unterstützung bei der Erstellung dieses Leitfadens.