Installieren von SharePoint 2010 auf SQL Server 2012 – So klappt’s

Immer mehr Unternehmen setzen Microsoft SQL Server 2012 ein und fragen sich ob es möglich ist, diesen als Datenbank Server für Microsoft SharePoint 2010 einzusetzen.

Wer das ohne vorher nachzulesen ausprobiert, wird beim Konfigurieren der Farm auf Probleme stossen: Der Farm Configuration Wizard läuft nämlich nicht sauber durch. Er bricht mit einem Fehler ab: Stored Procedure sp_dboption kann nicht gefunden werden.

Was kann man nun tun?

  1. SharePoint 2010 Service Pack 1 installieren
  2. Farm Configuration Wizard erneut ausführen

Sobald der Service Pack für SharePoint installiert ist, läuft der Farm Configuration Wizard fehlerfrei durch.

Gokan Ozcifci hat auf seinem Blog „SharePoint Pirate“ eine sehr detaillierte Anleitung für die Installation von SharePoint 2010 auf SQL Server 2012 in englischer Sprache veröffentlicht. Das von ihm vorgeschlagene Vorgehen ist praktisch, wenn man bereits auf die oben genannten Probleme beim Ausführen des Farm Configuration Wizards gestossen ist.
http://www.gokanozcifci.be/subsite/how-to-install-sql-server-2012-for-sharepoint-2010.html

Ebenfalls brauchbar ist das Vorgehen für die Installation von sehr kleinen Serverfarmen. Für mittlere und grosse SharePoint Farmen halte ich das Vorgehen für weniger geeignet. Mit der steigenden Anzahl Server steigt auch der zusätzliche Zeitaufwand für das separate Installieren von SharePoint 2010 und des Service Packs. In diesem Fall würde ich ein Slipstreaming von SP1 ins SharePoint 2010 Setup vorziehen.

Eine gute Anleitung für das Slipstreaming von SharePoint 2010 SP1 findet ihr auf dem MSDN-Blog: http://blogs.msdn.com/b/ronalg/archive/2011/07/11/slipstream-sharepoint-2010-sp1-and-language-packs-w-sp1-into-rtm.aspx

Sobald der SharePoint Service Pack ins Setup integriert ist, entfällt der Zusatzaufwand zum Installieren des Service Packs und das Vorgehen zum Installieren der Farm ist wieder analog zu SharePoint 2010 auf SQL Server 2008.

SharePoint Server 2010 und SQL Server 2008 R2

Der SQL Server ist die Grundlage für SharePoint. Ohne eine saubere SQL Server Implementation und Konfiguration ist eine Sharepoint Plattform nicht performant betreibbar. Nachfolgend sollen neue Feature aber auch Best Practices Ansätze für SharePoint 2010 mit SQL Server 2008 R2 aufgezeigt und erklärt werden.

High Availability
Der SharePoint Server 2010 mit Anbindung an SQL Server 2008 R2 bietet viele neue Möglichkeiten um die SharePoint 2010 Plattform noch effizienter zu betreiben. Dazu zählen bei Failover Szenarien das Log-Shipping und Mirroring Konzepte, welche von SharePoint Server 2010 komplett unterstützt werden. Bei Mirroring werden die beiden Varianten synchron und asynchron unterstützt, das letztere aber nur mit einer Enterprise Edition möglich ist. Unter Log-Shipping versteht man einen automatischen Backup der SQL Datenbank sowie der Transaktions-Logdateien, die auf einem Failover-Server gesichert werden. Bei Mirroring hingegen werden Einträge aus dem Transaktionsprotokoll einer SQL Datenbank direkt von einem SQL Server zu einem anderen Server „gespiegelt“ und bei einem Failover auf diesem Server automatisch umgeschaltet.

Der SQL Server 2008 R2 bietet im Zusammenhang mit SharePoint Server 2010 einige neue Features, wobei ich das „Backup Compression“ und Remote BLOB Storage RBS nachfolgend erläutern möchte:

Backup Compression
Beim „Backup Compression“ handelt sich um ein Feature das auch im SQL Server 2008 R2 Standard Edition vorhanden ist. Dabei können Daten schneller komprimiert gesichert werden. Bei einem Test mit ca. 370’000 Dokumenten in einer Content Datenbank wurde die Backup Zeit um ca. 50% gesenkt. Der Vorteil dabei; weniger HDD Zugriff, weniger Arbeitsspeicher Verbrauch. Der SQL Server fungiert hier als Kanal für den Zugriff auf die Daten und ist verantwortlich für das transparente Zugreifen (Lesen und Schreiben) der Daten.

Remote BLOB Storage RBS
Darüber hinaus unterstützt SharePoint 2010 mit SQL Server 2008 die Nutzung von Remote BLOB Storage (RBS). Mit RBS können grosse Dateien auf externe Medien gespeichert werden… was den Vorteil hat, die angebundene Datenbank deutlich zu entlasten.

Richtwerte
SharePoint 2010 bietet folgende elementare Richtwerte, die beim Sizing einer SharePoint Architektur beachtet werden müssen:
• 8 WFR pro SQL Server Instanz
• 50’000 Site Collections pro Content DB
• 100GB Daten pro Content DB
(aber: getestet bis 350GB ohne Performanceimpact)
• Latenz zwischen DB-Server und WFE / Applikationsservern max. 1ms

Memory
• Beim Arbeitsspeicher empfiehlt es sich 4GB Memory pro CPU Core zu setzen, um eine optimale Serverauslastung zu gewährleisten.
Prozessoren
Bei den Prozessoren müssen folgende Werte berücksichtigt werden:
• x64 einzige Option für SharePoint 2010
• x64 empfohlen für MOSS 2007
• 1 Prozessorkern für SQL Server pro 20’000 Nutzer (minimum 8 Kerne)
• Bei mehr als 8 Prozessoren: Scale Out (weitere Server)

Konfiguration

Die meisten Einstellungen auf dem SQL Server 2008 sind bereits für optimale Leistung gesetzt. Mittels der Prozedur sp_configure können aber weitere Einstellungen an der Memory und CPU eingestellt werden:
Der Wert für ‚max server memory‘ kann folgendermassen berechnet werden=
TotalServerRAM
– (OS-Bedarf)
– (weiterer App-Bedarf)
– (Reserve für SQL Server-Memory ausserhalb Buffer Pool, min. 512MB,
berechnet: (1GB*CEILING(#Cores/4)) + (#Threads * ThreadStackSize).
ThreadStackSize = 2MB auf x64)

Bei CPU Einstellungen können nach Best Practices folgende Werte mittels der Prozedur sp_configure gesetzt werden:
• ‚max degree of parallelism‘ auf 1 setzen
• Processor Affinity nur bei Betrieb mehrerer SQL Server-Instanzen oder anderer Applikationen auf dem gleichen Server oder bei lizenztechnischer Beschränkung setzen

Fazit
SharePoint Server 2010 in Kombination mit SQL Server 2008 R2 bietet viele neue Möglichkeiten in der Konfiguration und Setup einer SharePoint Plattform. Zudem lassen sich mit der neuen SharePoint Version bessere ausfallsichere Applikationen bauen, die für viele Anforderungen gerecht werden.
Die oben genannten Konfigurationen und deren Möglichkeiten sollen nur einen kleinen Überblick verschaffen, was es alles zu beachten gilt, um eine SharePoint Farm optimal aufzusetzen.

Veröffentlicht unter SQL

Speicherung von grossen Datenmengen in SharePoint

Ein Artikel von Andreas Glaser und Michael Pertek, Namics AG, St. Gallen

Die Speicherung von grossen Datenmengen ist zu einem zentralen Entscheidungskriterium bei der Auswahl einer strategischen Plattform für businessrelevante IT Applikationen geworden. Wo liegen meine Daten, wie können diese regelmässig und einfach gesichert (Backup) und im Bedarfsfall wieder hergestellt (Recovery) werden? Am Beispiel eines Patientendossiers für ein Krankenhaus erläutern Andreas Glaser und Michael Pertek wie Speichermechanismen für grosse Datenmengen mit SharePoint interagieren. In dem Artikel werden verschiedene Varianten vorgestellt, wie unstrukturierte Daten gespeichert werden können. Als konkrete Beispiel und Variationen werden angerissen:

* VARBINARY (MAX)-Datentyp
* Filestream
* External BLOB Storages (=EBS)
* Remote BLOB Storages (=RBS)

Anhand von konkreten Anleitungen und Codebeispielen zeigen die Autoren die Anwendungsmöglichkeiten mit den jeweiligen Vor- und Nachteilen und geben eine Ausblick auf herstellerseitige Lösungsansätze, die hoffentlich mit SharePoint 2010 zumindest teilweise realisiert werden.

Der ganze Artikel unter: http://www.namics.com/wissen/hart-am-datenlimit
das passende Whitepaper unter: http://www.namics.com/download/Whitepaper_SharePoint_23Sep08.pdf