Browsing all articles in IT-Pro

Wie schon gebloggt kann man so einige SharePoint-Authentifizierungs-Szenarien mit Claims lösen. Wo Sonne ist, ist aber auch Schatten. In einem Projekt kam die Frage auf ob man alle Benutzer nur über Claims innerhalb SharePoint 2010 einbinden kann. Sprich keinen „User Profile Sync“ gegen ein Directory.  Und so machte ich machte mich auf die Suche nach den Limitationen. Hier meine Liste die vermutlich im Laufe der Zeit immer länger wird:

Audiences
OOTB funktionieren die „Benutzer basierten“-Audiences nicht. Also das Szenario „Mitglieder dieser Gruppe können das sehen“ funktioniert ohne „Custome Code“ nicht.
„Property-based“-Audiences funktionieren. Details dazu in diesem TechNet Blogpost: http://blogs.technet.com/b/speschka/archive/2010/06/12/using-audiences-with-claims-auth-sites-in-sharepoint-2010.aspx

Excel Services
Die Excel Services benutzen normalerweise C2WTS (Claims to Windows Token Service). Es wird aber nichts andere konvertiert das nicht entweder „Windows Classic“ oder „Windows Tokens“ zu einer „Windows Identity“ gewandelt wird. Aus diesem Grund müssen externe Datenzugriffe oder  „unattended data refresh” über den Secure Store Service durchgeführt.

Performance Point
Performance Point muss die „ Unattended Service Account”-Option im Zusammenhang mit “Secure Store Services” und Claims benutzen.

SQL Server 2008 R2 Reporting Services Integration
Die SQL Reporting Services benötigen zwingend Windows Authentication. Es besteht keine Möglichkeit den C2WTS (Claims to Windows Token Service) zu benutzen.

Visio Services
„Secure Store Service“ kann nur für das Darstellen von Objekten benutzt werden dessen Connection über ein ODC-File spezifiziert wurden.

Project Server
Claims werden prinzipiell unterstützt. Jedoch benötigt die Migration mehr als nur „MigrateUser“ da der Project Server eine eigene Datenbank für die „User Logon Information“ unterhält.

SharePoint Designer
Der „External Content Type Designer“ in SharePoint Designer 2010 kann keine „Claims aware WDSL endpoints“ ansprechen (http://support.microsoft.com/default.aspx?scid=kb;EN-US;982268).

PowerPivot
Das Darstellen von Workbooks“ in PowerPivot arbeitet eigentlich wie erwartet, trotzdem unterstützt PowerPivot nur klassische Web Apps. Dies aus folgenden zwei Gründen:
Um Daten von einer externen DB zu aktualisieren, benutzte Power Pivot die User Credentials die im Secure Store Service gespeichert sind. In einer claims-based Web App kann das “SharePoint binary API” mit einem “Windows Token” nicht angesprochen werden.
Eingehende „Connection Request“ werden von den SharePoint Front End Servern nicht akzeptiert. Dies scheint ein Bug zu sein.

Dies ist meine aktuelle Sammlung. Gute Ausgangspunkte um nach Lösungen und Ideen zu suchen sind folgende Blogs:
Share-n-dipity: http://blogs.technet.com/b/speschka/
SharePoint Security: http://www.sharepointsecurity.com/category/sharepoint/claims-based-authentication//
Microsoft Whitepaper: http://technet.microsoft.com/de-de/library/hh487289.aspx

Michael Greth und ich haben uns im letzten AlpenPodcast über das vergangene Jahr unterhalten. Ein Kollege sprach mich nun darauf an: was ist dann mit der Aussicht auf 2012. Nun, wir alle wissen das solche Aussagen immer ganz heikel sind. Retrospektive Zusammenfassungen sind ja einfach. Trotzdem versuche ich mal die Portal Trends, die ich persönlich wahrnehme, für das nächste Jahr auszubreiten.
Generell lässt sich sagen das Microsoft das Thema „Private Cloud“ bei ihren Kunden weiter sehr stark positionieren wird. Das bedingt, dass wir von der SharePoint Architektur Lösungen oder zumindest Aussagen bereithalten sollten. Ein guter Anlaufpunkt ist: http://sharepointintheprivatecloud.wordpress.com/.

Was immer wir im nächsten Jahr planen: Flexibler und elastischer muss es werden.

Das Thema Mobile wird uns weiter beschäftigen. Schon heute sind wir mit diesen Anforderungen konfrontiert. Mit dem Erscheinen der Galaxy Tabletts wird der Druck vermutlich noch grösser. Immer mehr Firmenkunden lassen ihren Anwender die Corporate Informationen auf diesen Geräten empfangen. (Mehr zu diesem Thema ein bisschen weiter unten im Abschnitt Portal Design Trends.)
Enterprise 2.0. Social Media ist ein ewiges Thema das bei fast allen Firmen immer wieder hochkommt. Bisher waren aber alle dann irgendwie doch noch nicht so richtig bereit. Im Zusammenhang mit der weiteren Ausbreitung von Mobilen Geräten in den Firmen wird dieses Thema nun erneut angegangen. Wichtig ist es zu erkennen, dass dieses Enterprise 2.0 kein IT-Thema ist, sondern ein Thema für die Corporate Communication Abteilung. Nur weil man ein Facebook und ein  Twitter Account hat ist man noch kein Social Media Spezialist.

Portal Design
Ebenso wie das Thema „Private Cloud“ wird Microsoft im nächsten Jahr SharePoint als WCM-Plattform positionieren. Das gibt uns Dienstleistern neue Aufträge und das ist gut so. Allerdings ist unsere Konkurrenz in diesem Bereich sehr, sehr stark. Diese Lösungen reagieren sehr viel schneller als Microsoft auf aktuelle Trends.
Das Konzept der mobilen Apps hat gezeigt das fokussierte Software Probleme oft dynamischer lösen als monolithische Feature starke Lösungen. Diese Erkenntnis schlägt sich direkt auf Portallösungen durch. Die Kunden werden mehr Fokus auf Themen wie „User Experience“, „Interaction Design“ und Informations-Architektur legen. Themen wie der reine Betrieb der Lösung werden langsam verschwinden weil sie im Zusammenhang mit der oben genannten „Private Cloud“ als „commodity“ wahrgenommen werden.
Was bedeutet das konkret? Das was gemeinhin als „Responsive Web Design“ bezeichnet wird, wird im nächsten Jahr aus den Kinderschuhen herauswachsen und umgesetzt. Die Unterschiede der Vielzahl der mobilen Geräte werden uns dazu zwingen. Statt Portale mit fixen Werten zu entwickeln, müssen wir dynamische Layouts schreiben die mit einer Vielzahl von unterschiedlichen Stylesheets auf unterschiedlichen Geräten angezeigt werden können. Das Web ist voll mit Hilfsmittel zu diesem Thema. Wie etwa tiny fluid grid.

Im Gegensatz zu dem weiter unten erwähnten „Fixed-Position Navigation„ zeigt sich in den reinen Portalen, die mit sehr viel Information umgehen müssen einen Trend zu Multi-Column Menus. Der Grund liegt darin, dass wenn zu viele Navigationslink vorhanden sind, Teile davon in die Seitennavigation (Quick Nav) verschoben werden. User Experience Tests haben aber gezeigt, dass eine Zersplitterung der Navigation von den Benutzern nicht immer richtig verstanden wird. Aus diesem Grund empfiehlt es sich alles in der Top Navigation zu behalten. Um dieses Problem zu lösen haben sich die erwähnten „Multi-Column Menus“ entwickelt. Ein gutes Beispiel ist etwa Best Made Company:

Aber auch einfachere Lösungen wirken immer noch sehr elegant und aufgeräumt (http://neuarmy.com/)

Ein anderer Weg um dieses Problem zu lösen sind „Footer Navigation“. Immer mehr Portale lassen den Footer mit sehr vielen Links konstant stehen und geben dem Benutzer so zwei Navigationselemente (oben und unten). Dies ist für die Benutzer deutlich logischer als die SharePoint typische Verteilung in Top- und Quick Navigation.



Allgemeine Site Design Trends


Fixed-Position Navigation
: Im letzten Jahr kam dieser Trend auf und der wird sich nächstes Jahr weitersetzten. Die Idee ist, dass man auf Seiten die wenige Navigation benötigen, die Navigation nicht versteckt sondern als zentrales Element stehen lässt. Dieses Vorgehen kann neben dem Design Effekt die Website Performance dramatisch verbessern. Mittels jQuery kann hier sehr schnelle Lösungen bauchen. Aber auch ohne aktivierten JavaScript kann mit ganz kreativen CSS Code Lösungen solche Effekte erreicht werden. Ein gutes Beispiel für diesen Effekt ist die Site von Simon Wuyts.

Grosse visuelle Elemente: Ein weiterer Trend, der im Zusammenhang mit Enterprise 2.0 steht, ist das man übergrosse Maskottchen auf die Site platziert. Die Idee dahinter ist es, dem Inhalt eine Identität zu geben (Maskottchen) welches sich dann positiv auf die Akzeptanz überträgt. Die Qualität dieser „Vector Arts“ wurde auch immer besser und gibt den Seiten definitiv einen „fröhlichen“ Anstrich. Zwei Beispiele hier: Firefox und MailChimp.

 

Natürlich gibt es weitere Trends wie etwa HTML 5/jQuerry/CSS Animationen oder „web save fonts“. Auch sieht man immer mehr Infografiken im Intranet. Bitte schreibt doch als Feedback welche Trends Ihr seht oder welche ich vergessen habe.

Wie an den Collaboration Days 2011 von letzter Woche angesprochen, hier die Anleitung wie man in einer Testumgebung mit Claims Based Identity „spielen“ kann ohne das man sich einen „Issuer“ installiert und konfiguriert. Diese Anleitung benutzt den LDAP Membership und Role Provider der mit SPS Server 2010 mitgeliefert wird und benutzt den Active Directory Domain Services um die Benutzer und Gruppen zu autorisieren.

Um dieser „Schritt um Schritt“ Anleitung zu folgen werden neben dem SharePoint Server 2010  folgende Annahmen getroffen. Sie haben einen Domain Controller mit dem Domänen Root „contoso.com“ und Benutzer im „userContainer“. Selbstredend müssen die entsprechenden Anpassungen an den Konfiguration für:

  • Server und userContainer Atribute für den Role Provider
  • Server und groupContainer für den Memebership Provider

entsprechend Ihrer Umgebung gemacht werden gemacht werden.

Eine neue Web Application mit Claimes based Authentication anlegen
1: In Central Administration -> Application Management -> Manage web applications im Ribbon auf “New” klicken um eine neue Web Application zu erstellen.

2: In der „Create New Web Application” Seite, im Authentication Abschnitt auf Claims Based Authentication klicken.


3: Im IIS Web Site Abschnitt eine neue IIS Web Seite erstellen lassen und einen Namen, sowie den Port, dafür eingeben. Zusätzlich hier noch die URL in der Host Header Box definieren etwa „claims.contoso.com“.

4: In der Security Configuration SSL aktivieren oder deaktivieren. Allow Anonymous auf „No“ setzten.

5: In der Identity Providers Sektion, “Enable Windows Authentication” aktivieren und im drop-down menu “NTLM” auswählen.

6: Um “forms-based authentication” zu aktivieren, klickt man auf “Enable Forms Based Authentication (FBA)”. Danach die „ASP.NET Membership provider und Role Manager“-Namen eintragen. Diese sind:

  • LdapMembershipProvider
  • LdapRoleProvider

7: In der “Sign In Page URL” Sektion die “Default Page” auswählen.

8: In der Public URL Sektion die URL eintragen: http:// claims.contoso.com/

9: Danach einen neuen Application Pool erstellen

10: Im „Service Application Connections“ alles auf “default” belassen.

11: “Customer Experience Improvement Program” auf “No” oder “Yes” setzten und mit OK die neue Web App erstellen.

Form-based Authentication Unterstützung konfigurieren
1: Im Windows Explorer zum “root directory” der Central Administration navigieren und die Datei “web.config” in einem Text Editor öffnen.
2: Das folgende XML gleich nach dem <system.web> Element hineinkopieren:

<membership>
<providers>
<add name=“LdapMembershipProvider“
type=“Microsoft.Office.Server.Security.LdapMembershipProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c“
server=“contoso.com“
port=“389″
useSSL=“false“
userDNAttribute=“distinguishedName“
userNameAttribute=“sAMAccountName“
userContainer=“CN=Users,DC=contoso,DC=com“
userObjectClass=“person“
userFilter=“(ObjectClass=person)“
scope=“Subtree“
otherRequiredUserAttributes=“sn,givenname,cn“ />
</providers>
</membership>
<roleManager enabled=“true“ defaultProvider=“AspNetWindowsTokenRoleProvider“>
<providers>
<add name=“LdapRoleProvider“
type=“Microsoft.Office.Server.Security.LdapRoleProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c“
server=“contoso.com“
port=“389″
useSSL=“false“
groupContainer=“CN=Users,DC=contoso,DC=com“
groupNameAttribute=“cn“
groupNameAlternateSearchAttribute=“samAccountName“
groupMemberAttribute=“member“
userNameAttribute=“sAMAccountName“
dnAttribute=“distinguishedName“
groupFilter=“(ObjectClass=group)“
userFilter=“(ObjectClass=person)“
scope=“Subtree“ />
</providers>
</roleManager>

3: Speichern und Schliessen

Security Token Service für Form Based Authentication konfigurieren
1: In den „Administrative Tools“ des Servers den „Internet Information Services (IIS) Manager“ starten. Dort den „Server node“ und danach den „Site node“ erweitern.

2: Dort den „SharePoint Web Services node” erweitern und dann auf „SecurityTokenServiceApplication“ klicken. In der Action pane (rechts) auf den Link „explore“ klicken. Dort das „web.config“ file suchen und in einem Text Editor öffnen.

3: Folgenden XML Konfiguration gleich nach dem </system.net> Element hineinkopieren:

<membership>
<providers>
<add name=“LdapMembershipProvider“
type=“Microsoft.Office.Server.Security.LdapMembershipProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c“
server=“contoso.com“
port=“389″
useSSL=“false“
userDNAttribute=“distinguishedName“
userNameAttribute=“sAMAccountName“
userContainer=“CN=Users,DC=contoso,DC=com“
userObjectClass=“person“
userFilter=“(ObjectClass=person)“
scope=“Subtree“
otherRequiredUserAttributes=“sn,givenname,cn“ />
</providers>
</membership>
<roleManager enabled=“true“>
<providers>
<add name=“LdapRoleProvider“
type=“Microsoft.Office.Server.Security.LdapRoleProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c“
server=“contoso.com“
port=“389″
useSSL=“false“
groupContainer=“CN=Users,DC=contoso,DC=com“
groupNameAttribute=“cn“
groupNameAlternateSearchAttribute=“samAccountName“
groupMemberAttribute=“member“
userNameAttribute=“sAMAccountName“
dnAttribute=“distinguishedName“
groupFilter=“(ObjectClass=group)“
userFilter=“(ObjectClass=person)“
scope=“Subtree“ />
</providers>
</roleManager>
4: Speichern und Schliessen

Die neue Web Application für Form Based Authentication konfigurieren
1: Im Windows Explorer zum “root directory” der Central Administration navigieren und die Datei “web.config” in einem Text Editor öffnen.

2: Das folgende XML gleich nach

<roleManager>
<provider>
hineinkopieren:
<add name=“LdapRoleProvider“
type=“Microsoft.Office.Server.Security.LdapRoleProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c“
server=“contoso.com“
port=“389″
useSSL=“false“
groupContainer=“CN=Users,DC=contoso,DC=com“
groupNameAttribute=“cn“
groupNameAlternateSearchAttribute=“samAccountName“
groupMemberAttribute=“member“
userNameAttribute=“sAMAccountName“
dnAttribute=“distinguishedName“
groupFilter=“(ObjectClass=group)“
userFilter=“(ObjectClass=person)“
scope=“Subtree“ />
3: Weiter folgendes XML gleich nach
<membership>
<provider>
hineinkopieren:
<add name=“LdapMembershipProvider“
type=“Microsoft.Office.Server.Security.LdapMembershipProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c“
server=“contoso.com“
port=“389″
useSSL=“false“
userDNAttribute=“distinguishedName“
userNameAttribute=“sAMAccountName“
userContainer=“CN=Users,DC=contoso,DC=com“
userObjectClass=“person“
userFilter=“(ObjectClass=person)“
scope=“Subtree“
otherRequiredUserAttributes=“sn,givenname,cn“ />

4: Speichern und Schliessen

Neue User Policy erstellen
1: In Central Administration zu -> Application Management -> Manage web applications navigieren. Die Web Application „claims.contoso.com“ auswählen und im Ribbon auf “User Policy” klicken.
2: Im Fenster „Policy for Web Application“ auf „Add User“ klicken
3: Die „Default Zone“ auswählen und dann das Adressbuch auswählen. Jetzt sieht man schon den neuen „Claims-based People Picker“

4: Die entsprechenden Benutzer auswählen

5: Speichern und zur gewählten URL navigieren. Dort kann man nun den Identity Provider auswählen.

Hinter dem Türchen im SharePoint Adventskalender verbirgt sich heute eine Kostprobe des SharePointPodcasts, dem auditiven Update für den engagierten SharePoint-Anwender mit Themen, Trends, Tipps, Tricks und Talk. Ich produziere den SharePointPodcast seit fast 7 Jahren in mittlerweile 197 Ausgaben, in denen ich aktuelle News, Tools, Veranstaltungstipps und mehr aus dem SharePoint-Land vorstelle.

Ein wesentlicher Bestandteil dces SharePointPodcasts sind auch die Gespräche und Interviews, die ich mit Menschen wie du und ich aus dem SharePoint-Land führe.

Mit Chris Müller haben ich eine kleine Reihe begonnen, in der wir unter dem Stichwort AlpenPodcast uns über SharePoint und die Welt unterhalten.

Hier ein Auschnitt aus unserem Talk auf den CollaborationDays 2011 in Luzern, die vollständige Episode könnt ihr im SharePointPodcast 197 hören.

 

Sehr oft wird SharePoint eingesetzt, ohne dass durchwegs bekannt wäre, welche Komponenten alle berücksichtigt werden müssen. Mit dem Begriff „SharePoint“ wird dann vor Allem eine Office ähnliche Software gemeint, mit welcher man zusammenarbeiten kann.

Nicht weniger oft wird dann SharePoint mit weiter, weiter, Fertigstellen installiert, und damit hat sich’s dann. Best Practices werden zwar im Bereich AD, Windows Server usw. bereits vielerorts angewandt, aber SharePoint ist oft ein Buch mit sieben Siegeln. Auch dafür gibt es ganz viele Grundlagen, die man berücksichtigen muss. Auf eine dieser Grundlagen will ich heute eingehen.

Es gibt eine ganz einfache Grundregel im Bereich Performance und die heisst SQL Server langsam = SharePoint langsam. SharePoint ist eine Webapplikation und von dieser erwartet der Enduser eine Klick and Run Experience. Wenn er diese nicht erhäldt, dann wird sofort auf SharePoint geschimpft, obwohl das Problem in den meisten Fällen an einem anderen Ort liegt. Ein Frontend kann 15 bis 20’000 User bedienen mit einer 10% Concurrency. Heisst, alle Kleinen und mittleren Unternehmen könnten mit einem starken Frontend auskommen. Das zweite Frontend wird meist nur für die Ausfallsicherheit eingesetzt.

Wo liegt also oft das Problem? Primär an zwei Orten:

  1. Dem SQL Server
  2. Dem Disksubsystem

Es gibt Regeln, wie eien SQL Server aufgesetzt werdne sollte, um die Performance zu erhöhen. Auch gibt es Regeln, wie ein Disksubsystem sein sollte, wenn man SharePoint Datenbanken darauf hosten will.

Der SQL Server

Hier ein paar Grundregeln, wie der SQL server konfiguriert werden muss:

Beginnen wir einmal bei der Aufteilung der Datenbanken. Wir unterscheiden High und Low Traffic Datenbanken, verschiedene Zugriffsmuster und die Logfiles.

 

 Die Suchdatenbank ist grundsätzlich die User DB mit dem grössten Traffic Read und Write. In grösseren Umgebungen macht es sinn, diese komplett in eine eigene Instanz auszulagern, um die restliche SharePoint Installation nicht zu gefährden. In kleinen bis mittleren Farmen kann diese auch in die normale SharePoint Instanz integriert sein. Grundsätzlich sollte aber in einer SharePoint Instanz nichts anderes laufen als SharePoint.

Stellen Sie sicher, dass Transaction Log, User DBs und die Temp DB auf eigenen LUNs in ihrem SAN liegen, d diese ein komplett untershcieldiches Zugriffsmuster haben. T-Log ist Sequential Write, User DBs sind verschieden: Content DBs sind Moderate Read und die Search ist Heavy Read/Write. Die Temp DB ist die schlimmste und ist Heavy Read/Write. Wenn nicht zumindest die Aufteilung wie oben erwähnt gemacht wird, werden sich die vershciedenen Daten ausbremsen.

Kommen wir zu den Einstellungen auf dem SQL Server:

Multiple Datafiles

Stellen Sie sicher, dass alle Datnebanken auf mehrere Datenfiles aufgeteilt sind. Dies erhöht die Performance erheblich. Erstellen Sie die DBs per Script und nicht per „Create New Content DB“ Button. Details dazu in meinem nächsten Post später im Advent.

 

Fill Factor auf 70% setzen

Diese Einstellung stellt sicher, dass Ihr Index weniger schnell fragmentiert. Wenn neue Datensätze eingefügt werden müssen, so werden diese in die leeren 30% eingefügt. Normalerweise ist der Fillfactor auf 100% und somit fragmentiert der Index beim ersten Insert. Jede Fragmentierung verlangsamt den SQL Server

 

T-Log Backup alle 15min bis max. 24h

Dies ist weniger ein Performance Issuer als ein Platzfresser. SharePoint Datenbanken sind per Standard auf Fullrecovery Mode eingestellt. Wenn Sie keine Log Backups machen, wird Ihnen das Logfile unter Unständen immer weiter wachsen. Ein Logbackup stellt sicher, dass alles in die DB geschrieben wurde und gibt das Log frei zum überschreiben. Zudem haben Sie eine zusätzliche Sicherheit zu Ihren Backups im Desasterfall.

 

Disable Boost SQL Server Priority

Diese Einstellung verleitet oft zum einschalten, ist aber im SharePoint Umfeld aufgrund der speziellen Konstellation von SharePoint eher hinderlich.

 

Max Degree of Parallelism 1 (für SharePoint only Instanzen)

Hier wird geregelt, wie viele Threads gleichzeitig für eine Query auf die Prozessoren verteilt werdne. Normalerweise ist die Einstellung auf 0, und der SQL entscheidet. Für SharePoint ist es besser, wenn eine Query immer nur auf eine Thread läuft, dies hat sich in Tests gezeigt.

 

Min und Max Memory konfigurieren

Stellen Sie sicher, dass der SQL Server genügend Memory bekommt, dass das Betriebssystem aber nicht zu leiden beginnt. Faustregel ist Memory Installed – 3GB = Max Memory. Wenn man die automatische Einstellung lässt, nimmt sich SQL was er bekommt. Wenn das Betriebssystem anfängt zu schreien, gibt er nach und nach frei, doch dann ist es meist bereits zu spät.

 

Temp DB auf 10GB und 4 Files verteilen, Autogrowth 1GB

Die Temp DB ist die meist belastete DB bei SharePoint, da jede Liste die in irgendeiner Art gruppiert oder sortiert ist, zuerst durch die Temp DB läuft. Machen Sie diese genur gross und verteilen Sie die DB auf mehrere Datenfiles. So wird die DB beim Start immer 10GB sein und wird somit durch die Wachserei und dadurch die Fragmentierung nicht langsam.

 

Lock Pages in Memory (für SQL Std. –T845) und Perform Volume Maintennance Tasks für SQL Account setzen

Lock Pages in Memory erlaubt dem SQL Server direkt Memory zu allozieren. Perform Volume Maintennance Tasks gibt SQL das Recht, beim Erstellen der DB Start und Endpunkt auf der Disk zu setzen, die Erstellung wird dadurch erheblich schneller. wird der Diskspeicher mit lauter Nullen aufgefüllt.

 

Traceflag 1117 (-T1117) für gleichmässigen Filegrowth

Dies ist ein Undocumented Flag und wird in den Startup Parametern der SQL Instanz gesetzt. Es garantiert den gleichzeitigen Growth mehrerer Datenfiles. Warum man mehrere Datenfiles machen sollte und wie, dazu später im Adventsblog. Wird dieses Flag nicht gesetzt, so füllt SQL alle Files gleichzeitig, wenn alle voll sind wächst File 1 und wird zuerst wieder gefüllt dann wächst File 2 etc… Das ist gerade nicht der Effekt, den man sich von mehreren Datenfiles erhofft.

 

Backupcompression einschalten

Das Backup wird schneller und kleiner. Was will man mehr? Dies geht zu Lasten der CPU, doch das ist vernachlässigbar.

 

Index Maintennance <=30% Reorganisation, sonst Rebuild

Der Index trägt nachhaltig zur Geschwindigkeit der Datenbanken bei. Man sollte darauf achten, dass periodisch die Indizes geprüft werden. Unter 30% Fragmentierung ist eine Reorganisation möglich, sonst muss der Index rebuildet werden.

Für den Indexrebuild empfhiehlt es sich, Max Degree of Parallelism wieder auf 0 zu stellen, da die Reorganisation bzw. der Rebuild schneller über die Bühne geht. Danach wieder zurück auf 1.

 

Update Statistics täglich, DBCC Checkdb vor Fullbackup

Mit Update Statistics wird der Einstiegspunkt festgelegt, damit nicht immer ein Fulltablescan gemacht werden muss. DBCC Checkdb verifiziert die Datenbanken auf ihre Konsistenz. ACHTUNG Repair with Dataloss ist im SharePoint nicht supportet!

 

To BLOB or not to BLOB

Zu guter letzt sollte man sich auch Gedanken über RBS machen. Wie in einem früheren Post erwähnt, entlastet der BLOB Store den SQL Server. Es gab eine Studie, wonach Files < 1MB schneller vom SQL und >1 MB schneller vom Filesystem gestreamt werden. Auch kann der RBS auf günstigeren Disks liegen, was die Gesamtkosten der Infrastruktur senkt. Bitte aber genau prüfen, bevor man da einsteigt. Die Backup Restore Szenarien verkomplizieren sich nämlich durch RBS ;-)

 

Und noch was zum Schluss: Never Virtualize an SQL Server (meine persönliche Meinung, die ein paar Cracks der Microsoft Consulting Services mit mir teilen…)

 

Das Disksubsystem

Disk Alignement

Auch auf dem Disksubsystem gibt es einiges zu beachten. Wenn nämlich mal der SQL mal sauber aufgesetzt und konfiguriert ist, kommt noch das Disksubsystem, auf welchem die Daten liegen. Of wird dies als „Grosser Kübel“ hingestellt und gut ist. Dass sich aber Threads gegenseitig ausbremsen, daran denkt niemand. Beginnen wir mal ganz unten, nämlich beim Disk Alignement. Wurde das Disk Alignement falsch gemacht, verursachen sie dem Disksubsystem Schmerzen, da es defakto die selbe Info zweimal schrieben muss. Einmal auf die Partition und dann noch auf die physische Disk. Stellen Sie sicher, dass die Partitionierung mit einer Blockgrösse von 64KB gemacht wurde. Ältere Systeme haben eine Blockgrösse von 4KB was denkbar schlecht ist.

Hier die Performanceunterschiede mit Aligned und Unaligned Disks:

DiskPartitionAlignmentFig1.jpg

Microsoft hat ein Whitepaper zum Disk Alignement und SQL Server 2008 bereitgestellt, welches exakt zeigt, wie man es einstellt, prüft und korrigiert. Auch werden die Auswirkungen detailiert aufgezeigt.
Hier der Link: http://download.microsoft.com/download/C/E/7/CE7DA506-CEDF-43DB-8179-D73DA13668C5/DiskPartitionAlignment.docx

 

Performance, IOPS und Anzahl Disks

Es gibt ganz viele Hersteller, die behautpen, das beste Disksubsystem für SharePoint zu haben. Ich sage dazu nur eines: Kein RAID10, kein gutes Disksubsystem für SharePoint. Grundsätzlich geht es um Performance, und da ist RAID10 nicht zu überbieten, auch wenn es notabene das verschwenderischste ist, da die zwei Platten welche zusammen mehr performance ergeben und zusätzlich noch gespiegelt werden. Man kann also genau 50% des eingekauften Speicherplatzes effektiv nutzen, was eigentlich eine schlechte Ausbeute ist.

Wir wollen aber Performance und daher wird auch von Microsoft dringend RAID10 empfohlen. Dann können Sie auch als Grundregel nehem, was unter 140 MB/s Throughput hat ist zu langsam. Diese Rechenmethode hat ihre Grenzen, denn sie sagt alleine nicht viel aus.

Sicherer ist mit IPOS zu rechnen. Hier ist die Faustregel 2 IOPS pro GB Daten. Da wird schnell klar, dass wir schnell mal ein paar IOPS auf unserem Disksubsystem brauchen.

Wichtige Grundregel beim Disksubsystem ist auch die Anzahl Disks, nicht nur der benötigte Platz sonder die Anzahl Spindeln, welche den IO verarbeiten sind hier die wichtigen Faktoren.

Es empfiehlt sich, einige Tests mit SQLIO zu machen.
Zum Tool:  http://www.microsoft.com/download/en/details.aspx?id=20163
zur Beschreibung: http://technet.microsoft.com/en-us/library/cc966412.aspx

 

So, nun habe ich erstmal genug losgelassen, ich lass euch das ganze erst mal verdauen.

So long, Samuel

 

Fabian hat im vorangegangen Artikel 10 Performance Tipps genannt. Aber wie viel Performance kann ich hierdurch wirklich gewinnen? Ich picke mir einfach den Blob Cache heraus und stelle Ihn auf den Prüfstand. Vertrauen ist gut, Kontrolle ist besser clip_image001

Testumgebung

Zum Testen nutze ich einen Visual Studio 2010 Load Test. Meine Testumgebung läuft bei Cloudshare und sieht folgendermaßen aus:

clip_image002

Der WFE hat 6GB RAM und 2 CPUs und der SQL Server 2GB und 2 CPUs (ich weiß, ich weiß, ist etwas dünn). Der Last Test läuft 5 Minuten mit jeweils 100 parallel Zugriffen (Threads).

Die Testseite (Publishing Page)

clip_image003

Der Load Test

Der Load Test besteht nur aus einem einzigen Web Test der einen HTTP-Request auf die folgende Seite ausführt. Sehr einfach aber ausreichend um die effizienz des Blob Caches zu validieren. Load Tests können auch wesentlich komplexer sein!

[youtube http://www.youtube.com/watch?v=pvA-82FVXBo&hl=en&hd=1]
Einfachen Lasttest Erstellen

Der Test wird einmal ohne Blob-Caching und einmal mit Blob-Caching ausgeführt. Der Blob-Cache kann wie hier beschrieben konfiguriert werden:

http://blogs.msdn.com/b/sharepointalps/archive/2011/09/30/blob-cache-im-sharepoint-2010-umfeld.aspx

 

Das Ergebnis

Baseline ist der Test ohne BLOB Cache und der Comparsion Run ist mit aktiviertem Blob Cache.

clip_image004

Der Test mit aktiviertem BLOB Cache ist 11 % schneller.

clip_image005

Wenig erstaunlich ist, dass die Prozessoren des SQL Server insgesamt um 31% weniger ausgelastet sind. Sehr stark entlastet werden auch die Netzwerkarten und somit auch das Netzwerk. Auf dem SQL Server haben wir 81% und auf WFE 76% weniger Traffic. Nur sehr leicht angestiegen (2%) ist die Festplattenaktivität auf dem WFE da die Bilder, CSS und Skripte jetzt aus dem Cache geladen werden. Interessant ist auch das der IIS Worker Process 34% weniger belastet ist. Das könnte daran liegen, dass die die Dateien jetzt direkt auf der Platte liegen und nicht erst die Binärdaten des SQL Server verarbeiten werden müssen.

Fazit

Der Blob Cache bringt wirklich etwas und entlastet deutlich SQL Server, Netzwerk und WFEs!
@Fabi: recht gehabt clip_image006

 

Hinweis zum Kommentar

Zum Kommentieren der Beiträge (und damit zur Teilnahme am Gewinnspiel) bitte auf die Zahl in der Bubble neben dem Titel des Blogeintrags klicken, dies öffnet das Kommentarformular!

Sponsored by

Subscribe

Über

Der SharePoint Advent

Ein Gemeinschaftsprojekt der deutschsprachigen SharePoint MVP's

Rubriken

Impressum

(c) 2011 SharePointCommunity