SQL 2012 Reporting Services in einer SharePoint 2013 Multi-Server Farm
Mit dem SQL Server 2012 SP1 und SharePoint Server 2013 sind auch die SQL Server 2012 SP1 Reporting Services erschienen. Aus Architektursicht gibt es vorallem eine entscheidende Änderung gegenüber der Version 2008 R2; neu ist der Reporting Service vollständig als Service in SharePoint integriert. Das sieht nun wie folgt aus:
In meinem Beispiel beschreibe ich eine Multi-Server Farm mit SQL Server 2012 SP1 und SharePoint Server 2013, in welcher ein Web Front-end, ein Application resp. Report Scale-out Server sowie ein Datenbank Server vorhanden sind. Dieses Szenario kann beliebig skaliert werden, mit mehreren Web Front-end Servern, mehreren Application Servern oder auch in Form eines Single Servers.
Bevor ich mit der Installationsanleitung beginne, erscheint es mir wichtig, den Unterschied zwischen den Reporting Services - SharePoint mode und dem SQL Server Report Add-in for SharePoint zu erklären:
Reporting Services - SharePoint mode
Die Reporting Services waren bisher eine separate Instanz auf dem SQL. Neu sind diese in SharePoint in Form eines Services mit einer Service Application integriert. Es handelt sich hierbei um den Kern der Reporting Services, hier werden die Reports verarbeitet. Diese Komponente wird auf jedem SharePoint Application resp. Report Scale-out Server installiert, auf dem der Service laufen soll und somit Reports verarbeitet werden sollen.
SQL Server 2012 SP1 Reporting Services Add-in for SharePoint
Das Add-in stellt die Verbindung vom SharePoint Server zu den SQL Server Reporting Services her. Das Add-in muss auf jedem SharePoint Web Front-end Server in der Farm installiert werden. Falls die SharePoint Rollen in der Farm gemischt sind - also Web Front-end und Application Role - ist das Add-in ebenfalls auf den SharePoint Application Servern zu installieren. Allgemein lautet meine Empfehlung, das Reporting Services Add-in immer auf allen SharePoint Server zu installieren. Dies spiegelt sich auch in der untenstehenden Anleitung wider.
Voraussetzungen
Windows Server 2008 R2 SP1 x64 Standard, Enterprise oder Datacenter oder Windows Server 2012 x64 Standard oder Datacenter
SQL Server 2012 SP1 in der BI oder Enterprise Edition
SharePoint Server 2013 oder SharePoint Foundation 2013
SQL Server 2012 SP1 Reporting Services Add-in for SharePoint
SharePoint Application Server / Report Scale-out Server
Diese Installationsschritte sind auf jedem SharePoint Application resp. Report Scale-out Server durchzuführen, auf denen die SQL Server 2012 Reporting Services zum Verarbeiten von Reports genutzt werden sollen.
Führen Sie die setup.exe des SQL Server 2012 SP1 Installationsmediums als Administrator aus.
Wählen Sie das Tab Installation und klicken Sie auf New installation or add features to exisiting installation.
Die Setup Support Rules werden überprüft. Hierbei sollten keine Fehler auftreten. Klicken Sie OK respektive Next.
Geben Sie den Product Key ein und klicken Sie Next.
Akzeptieren Sie die Lizenzvereinbarung und klicken Sie Next.
SQL Server Feature Installation wählen und Next klicken.
In den Shared Features Reporting Services - SharePoint und Reporting Services Add-in for SharePoint Products auswählen und weiter mit Next.
Auf Next klicken.
Unter Reporting Services SharePoint Integrated Mode wählen Sie Install only. Weiter mit Next.
Auf Next klicken.
Auf Next klicken.
Auf Install klicken.
Wurde die Installation erfolgreich durchgeführt, dann klicken Sie auf Close um das SQL Server Setup zu schliessen.
An dieser Stelle sollte unter Start > Control Panel > Programs and Features kurz überprüft werden, ob das Microsoft SQL Server 2012 RS Add-in for SharePoint mind. in der Version 11.1.3000.0 installiert wurde. Grund: Ältere SQL Server 2012 SP1 ISO Files können eine veraltete Version des Add-ins enthalten. Sollte die installierte Version tiefer sein, als die oben angegebene, dann kann hier das richtige Add-in heruntergeladen und über das bestehende installiert werden: Microsoft SQL Server 2012 SP1 Reporting Services Add-in for Microsoft SharePoint.
Öffnen Sie nun die SharePoint 2013 Management Shell mit administrativen Rechten und führen Sie nachstehende PowerShell Befehle aus, um die Reporting Services zu installieren:
Install-SPRSService
Install-SPRSServiceProxy
Get-SPServiceInstance -all |where {$_.TypeName -like "SQL Server Reporting*"} | Start-SPServiceInstance
Get-SPServiceInstance -all |where {$_.TypeName -like "SQL Server Reporting*"}
Navigieren Sie in der SharePoint 2013 Central Administration zu System Settings > Manage Services on Server. Wählen Sie unter Server den Report Scale-out Server aus. Idealerweise sollten auf diesem Server nebst dem SQL Server Reporting Services Service möglichst wenig andere Services gestartet sein.
Navigieren Sie in der SharePoint 2013 Central Administration zu Application Management > Manage service applications. Klicken Sie im Ribbon auf Next und wählen Sie die SQL Server Reporting Services Service Application aus.
Die Service Application kann entweder in einem bereits bestehenden Application Pool laufen oder in einem eigenen.
Idealerweise sollte für Reporting Services ein separater Managed Account verwendet werden.
Geben Sie den Database server (am Besten in Form eines SQL Alias an; Anleitung zum Erstellen eines SQL Alias) und vergeben Sie einen aussagekräftigen Database name.
Als Database Authentication sollte Windows authentication gewählt werden.
Wählen Sie abschliessend die Web Application aus, mit welcher die Reporting Services assoziiert werden sollen.
Klicken Sie nach erfolgreicher Erstellung der Service Application auf OK, um den Wizard zu schliessen.
SharePoint Web Front-end Server
Diese Installationsschritte sind auf jedem SharePoint Web Front-end Server in der SharePoint Farm durchzuführen. Hinweis: Das Reporting Servcies Add-in sollte erst installiert werden, nachdem die SQL Server Reporting Services Service Applcation in der Farm konfiguriert wurde.
Laden Sie das Microsoft SQL Server 2012 SP1 Reporting Services Add-in for Microsoft SharePoint herunter oder führen Sie dieses direkt von Ihrem Installationsmedium unter <Drive>:\1033_ENU_LP\x64\Setup\rsSharePoint.msi (mind. Version 11.1.3000.0) aus.
Akzeptieren Sie die Lizenzvereinbarung und klicken Sie auf Next.
Auf Install klicken.
Auf Finish klicken, um den Installationswizard zu beenden.
SQL Server 2012 Best Practices für SharePoint Server 2013
Dieser Artikel ist gültig für Installationen mit SQL Server 2008 R2 und SQL Server 2012, Windows Server 2008 R2 und Windows Server 2012 sowie SharePoint Server 2010 und SharePoint Server 2013.
Im Web gibt bereits viele Artikel zu diesem Thema. Allerdings hat sich kaum einer die Mühe gemacht, zu erklären, wo und wie die besagten Einstellungen vorgenommen werden müssen. Deshalb habe ich mich entschieden, dies mit diesem Post möglichst ausführlich nachzuholen.
Auf dem SQL Server werden fast alle Daten von SharePoint abgelegt. Da erstaunt es wenig, dass die Performance des SQL Server direkten Einfluss auf die Geschwindigkeit von SharePoint hat. Trotzdem wird dieser Faktor sehr oft ausser Acht gelassen, nicht zuletzt, weil hinter einer Optimierung oftmals grosse Kosten vermutet werden. Natürlich braucht es auch hardwareseitig ein gewisses Minimum an Leistung. Nachstehend einige Tipps um die Performance ohne zusätzliche Kosten spürbar zu verbessern.
Windows Server Performance Options
Standardmässig ist Let Windows choose what's best for my computer eingestellt. In den meisten Fällen wird der Server für eine schöne Darstellung optimiert, was allerdings bei einem Server ziemlich unwichtig ist. Der Wert kann hier auf Adjust for best performance gesetzt werden:
Rechtsklick auf Computer > Properties > Advanced system settings > Performance > Settings > Visual Effects
Page File Grösse festlegen
Das Page File wird standardmässig durch Windows verwaltet. In den meisten Fällen ist es sinnvoll, die Grösse und den Speicherort selbst zu bestimmen.
Computer > Properties > Advanced system settings > Performance > Settings > Advanced > Virtual Memory > Settings
Die Grösse des Pagefiles sollte dem Faktor 1.5 der zugewiesenen RAM des Servers entsprechen. Beispiel: 8192 MB RAM x 1.5 = 12288 MB Pagefile
Power Plan anpassen
Standardmässig ist der Balanced Mode aktiviert. Für den Serverbetrieb sollte allerdings High Performance genutzt werden, da dieser einen bis zu 15% höheren Durchsatz zulässt.
Navigieren Sie zu Start > Control Panel > Power Options und stellen Sie dort auf High Performance um.
Sollte die Option High Performance deaktiviert sein, dann klicken Sie auf Change settings that are currently unavailable. Anschliessend kann die Änderung vorgenommen werden.
Allocation Unit Size optimieren
Die NTFS allocation Unit Size sollte auf 64K angepasst werden. Die aktuellen Einstellungen können Sie sich anzeigen lassen, indem Sie das Command Line Tool (cmd) mit administrativen Rechten öffnen und folgenden Befehl eingeben:
chkdsk D: (D: entspricht der gewünschten Partition)
Im untersten Abschnitt der Ausgabe finden Sie die gewünschte Information.
Um die NTFS allocation Unit Size für die Partition D: auf 64K zu ändern, setzen Sie folgenden Befehl im Command Line Tool (cmd) ab:
D: /Q /FS:NTFS /A:64K /V:Data /Y
Vorsicht: Mit diesem Befehl wird das Laufwerk formatiert!
Erläuterung
D: = Laufwerksbuchstabe der gewünschten Partition (in diesem Beispiel D:)
/Q = Quick Format
/FS = File System (in diesem Beispiel NTFS)
/A = Allocation Unit Size (in diesem Beispiel 64K)
/V = Volume Label (in diesem Beispiel heisst das Volume "Data")
/Y = Bestätigt die Abfrage zum Formatieren der Disk
Windows Firewall
Konfiguration der Windows Firewall gemäss https://www.techtask.com/sharepoint2010/windows-firewall-fur-den-sql-server-zugriff-konfigurieren/
Datenbank Volumes
Die Datenbank Volumes sollten in separate LUNs (Logical Unit Numbers) aufgeteilt werden, idealerweise bestehend aus eigenständigen physikalischen Disks.
Priorisierung der Daten bei unterschiedlich schnellen Disks (in absteigender Reihenfolge)
- 1. TempDB Data Files und Transaction Logs
- 2. Content Datenbank Transaction Logs
- 3. Search Datenbanken
- 4. Content Datenbank Data Files
Werden in der Farm vorallem Daten gelesen und weniger geschrieben, dann sind die Positionen 2 und 4 gegeneinander auszutauschen.
Weiter sollten die Transaction Logs der Search Datenbank von den Transaction Logs der Content Datenbanken getrennt werden.
- SharePoint sollte immer auf einem dedizierten SQL Server oder mind. einer dedizierten SQL Instanz betrieben werden.
- Verwenden einer Named SQL Instanz.
- Als Authentifizierungsmethode für die SQL Istanz sollte Windows Authentication gewählt werden.
- Für grössere Suchanwendungen ist eine separate SQL Instanz für die Suche zu verwenden.
- Verwendung des aktuellsten Service Packs und den aktuellsten Patches bei der SQL Server Installation.
- Die SQL Collation für SharePoint ist Latin1_General_CI_AS_KS_WS.
- Erstellung der SQL Datenbanken mit PowerShell, um GUIDs in den Datenbanknamen zu vermeiden.
- Der SQL Service Account benötigt die Rechte Lock Pages in Memory (siehe http://support.microsoft.com/kb/918483/en-us) und Perform Volume Maintenance Tasks (gpedit.msc > Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignments > Perform volume maintenance tasks)
- Auto Create Statistics und Auto Update Statistics auf False belassen
Setzen des minimalen und maximalen Server Memory
Microsoft SQL Server Management Studio > Object Explorer > Rechtsklick auf servername\instanz > Properties > Memory
Setzen des Minimum server memory und des Maximum server memory Wertes in MB. Achtung: Beim Setzen des miximalen Server Memory sollten ca. 3 GB für den Betireb Betriebssystems abgezogen werden.
Fill Factor und Backup Compression
Microsoft SQL Server Management Studio > Object Explorer > Right click on servername\instace > Properties > Database Settings
Ändern Sie den Wert des Default index fill factor auf 80 und setzen Sie ein Häkchen bei Compress Backup, um die Backupkompression zu aktiveren.
Max Degree of Parallelism
Diese Einstellung legt die Anzahl Prozessoren fest, welche für die Verarbeitung einer Abfrage (Query) eingesetzt werden.
Ein hoher MAXDOP Wert wird in der Regel eingesetzt, wenn die Anzahl gleichzeitig zu verarbeitender Abfragen eher gering ist. Ist die Anzahl gleichzeitig zu verarbeitender Abfragen eher hoch, wird in der Regel ein tiefer MAXDOP Wert gesetzt.
Da SharePoint hat eine sehr hohe Anzahl an gleichzeitig zu verarbeitenden Abfragen aufweist, ist ein möglichst tiefer Wert zu setzen, deshalb ist der optimale Wert für eine SharePoint Umgebung 1.
Ist der Wert auf 0 gesetzt, kann der SQL Server alle verfügbaren Prozessoren einsetzen, um eine einzelne Abfrage zu verarbeiten.
Microsoft SQL Server Management Studio > Object Explorer > Right click on servername\instanz > Properties > Advanced
Setzen Sie den Wert Max Degree of Parallelism auf 1
Trace Flag 1117
Durch das Setzen des Traceflags 1117 wird das gleichmässige Wachstum aller Data Files gewährleistet.
Navigieren Sie zu Start > Microsoft SQL Server 2008 R2 > Configuration Tools > SQL Server Configuration Manager > SQL Server Configuration Manager (local) > SQL Server Services > SQL Server (Instance name) > Properties > Advanced > Startup Parameters > und fügen Sie am Ende ;-T1117 an.
Datenbankanpassungen allgemein
Pregrow
Vergrössern der Content Datenbank auf die erwartete Grösse um die Fragmentierung zu minimieren.
Autogrowth
Sollte aktiviert blieben. Bei kleineren Datenbankgrössen sollte der Autogrowth Wert auf 256 MB oder 512 MB eingestellt werden. Bei grösseren Datenbanken, ab ca. 5 GB, ist 10% ein angemessener Wert.
Anzahl Data Files
Die Anzahl der Data Files sollte der Anzahl Processor Cores entsprechen (Minimum 4/Maximum 8)
Recovery Model
In den meisten Fällen kann das Recovery Model Simple verwendet werden. Full sollte vorallem dann eingesetzt werden, wenn eine Backupstrategie mit regelmässigen Backups der Transaction Logs geplant ist oder eine High Availability Konfiguration mit Log Shipping oder Database Mirroring vorgesehen ist.
ModelDB anpassen
- Die Initial Size des MDF Files sollte auf einen sinnvollen Schätzwert angepasst werden.
- Die Initial Size des LDF Files sollte auf 25% der festgelegten MDF Initial Size konfiguriert werden. Dabei sollte darauf geachtet werden, dass der LDF-Wert durch acht aus dem MDF-Wert geteilt werden kann.
- Um optimale Wachstumsgrössen zu erreichen, sollte die Autogrowth-Einstellung sinnvoll gesetzt werden. Dieser Wert beträgt in der Regel 25-50% der Initial File Size.
TempDB anpassen
- Die Inital Size sollte ca. auf 25% der Grösse der grössten Content DB festgelegt werden.
- Aufteilung in mehrere Data Files. Die Anzahl der Data Files sollte der Anzahl Processor Cores entsprechen (Minimum 4/Maximum 8)
- Die Data File Size aller Data Files müssen alle die gleiche Grösse haben.
- Der Autogrowth Wert auf 10% der vergebenen TempDB Grösse setzen, jedoch als fixen Wert in MB.
Maintenance Plan
Daily Full Backup der Content Datenbanken inkl. Consistency Check
Transaction Log Backups alle 30 Minuten
Wöchentliches Backup der System Datenbanken
Die SQL Server Data, Transaction Log und Backup Verzeichnisse sind vom Virenscanner auszuschliessen.
- Content Datenbanken sollten nicht grösser als 200 GB sein, da Backups/Restores ansonsten sehr lange dauern können.
- Nicht mehr als 5'000 Site Collections pro Content Datenbank.
- Setzen von Quotas auf SharePoint Web Application Level.
SQL Alias
Auf allen SharePoint Servern sollte anstelle des tatsächlichen SQL Server- und Instanznamen ein SQL Alias hinterlegt werden. Dies ermöglicht zu einem späteren Zeitpunkt auf einfache Art und Weise eine Migration des SQL Servers.
Das Erstellen eines SQL Alias wird hier beschrieben: https://www.techtask.com/sharepoint2010/sql-alias-fur-sharepoint-web-applikationen-erstellen/
Benutzer in eine andere SharePoint Gruppe kopieren
Im besten Fall werden AD-Gruppen in den SharePoint Gruppen berechtigt und keine einzelnen Benutzer. Leider ist das nicht immer so umgesetzt und so hatte ich die Anforderung knapp 200 Benutzer von einer SharePoint Gruppe in eine andere zu verschieben. Der erste Gedanke war natürlich PowerShell. Jedoch müsste dazu ein etwas ausführlicheres PowerShell Script geschreiben werden, welches diese Aufgabe erledigt. Da der Aufwand zur Erstellung eines solchen Scripts in keinem Verhältnis zu den 200 zu verschiebenden Benutzern steht, habe ich mich entschieden, dies mit einem kleinen Trick im SharePoint GUI zu erledigen.
Benutzer von einer SharePoint Gruppe in eine andere SharePoint Gruppe kopieren
Dieses Vorgehen ist gültig für SharePoint 2007, SharePoint 2010 und SharePoint 2013.
- Navigieren Sie in der betreffenden Sharepoint Site zu Site Actions > Site Permissions und wählen Sie die Gruppe aus, von der die Benutzer kopiert werden sollen.
- Bei einer grösseren Anzahl an zu kopierenden Benutzern erweitern Sie die Anzahl Objekte pro Seite auf 65. So viele Benutzer können pro Aktion maximal für den E-Mail-Versand ausgewählt werden. Eine Kurzanleitung dazu finden Sie etwas weiter unten im Abschnitt Ansicht anpassen.
- Markieren Sie alle Benutzer auf der aktuellen Seite und klicken Sie unter Actions auf E-Mail Users.
- Danach öffnet sich ein neues Fenster im Standard E-Mail-Programm (z.B. Microsoft Outlook) mit allen E-Mail-Adressen der ausgewählten Benutzer.
- Kopieren Sie die E-Mail-Adressen und navigieren Sie zur neuen SharePoint Gruppe, in welcher Sie die Benutzer berechtigen wollen und klicken Sie auf New.
- Fügen Sie die kopierten E-Mail-Adressen in das Feld Users/Groups ein und klicken Sie zur Validierung auf das Check Names Symbol und bestätigen Sie mit OK.
Ansicht anpassen
- In der SharePoint Gruppe, von welcher Sie die Benutzer kopieren wollen, klicken Sie auf Settings > List Settings
- Anschliessend klicken Sie auf der neu geöffneten Seite unter Views auf den Namen der Ansicht, welche Sie anpassen wollen.
- Scrollen Sie zum Abschnitt Item Limit und tragen Sie im Feld Number of items to display: 65 ein.
- Klicken Sie auf OK und kehren Sie zur SharePoint Gruppe zurück.
- Wählen Sie dort rechts oben den Namen der Ansicht aus, welche Sie gerade angepasst haben.
