Hier in der kleinen Schweiz gibt es auch Unternehmen, die 100‘000 oder mehr Mitarbeiter haben. Diese Mitarbeiter sind zwar nicht alle hier in der Schweiz beheimatet, trotzdem ist der Unternehmenssitz in der Schweiz. Eine clevere MySite Lösung drängt sich hier im Zusammenhang mit SharePoint auf.
Die Frage, die mich in zwei aktuellen Projekten beschäftigt, ist: Wie skaliert man eigentlich MySites. Wir haben bereits über die Grenzen der Enterprise Skalierung geschrieben, basierend auf dem TechNet Artikel „Plan for software boundaries“. In diesen Artikel hat es einige Zahlen, die nicht eindeutig sind und auch verwechselt werden können.
Die Limits, die ich für meine Projektarbeit benutzt habe, sind die Folgenden:
- 100 GB maximale Grösse für die Content Database (DB)
- 50,000 Site Collections pro Content DB
Als erstes wird man also mehrere Content DBs für die MySite Web Applikation benützten müssen. Um den TechNet-Richtlinien zu folgen, benötigt man also zwei Content Datenbanken um 100‘000 MySites zu betreiben.
Im gleichen TechNet-Artikel ist eine Grafik abgebildet, die den Datendurchsatz im Zusammenhang mit der Anzahl der SiteCollections zeigt. Der stärkste Knick hat der Graph, sobald die Content Datenbank über 50‘000 Site Collections angewachsen ist.
Wenn man diese Grafik genauer betrachtet, sieht man folgende drei Dinge:
- Bei 10‘000 Site Collections pro Datenbank sind die Requests per Secons (RPS) immer noch über 100
- Von ungefähr 14‘000 bis 16‘000 Site Collections fällt der Durchsatz rapide
- bei über 16‘000 Site Collections erreicht der Durchsatz ungefähr 50 rps und bleibt dann auf diesem Wert
Man würde also sagen, das 10‘000 Site Collections pro Content DB ein optimaler Wert sind! Würde man lediglich 50% mehr Site Collections hinzufügen, würde das den Durchsatz mehr als halbieren. Was in meinem Projekt, in dem mehr als 300‘000 MySites erstellt werden sollen, eine astronomische Anzahl von Content DBs und Web Applikationen mit sich bringen würde.
Diese Zahlen mögen für „normale“ Site Collections stimmen. Stimmen sie aber auch für MySites? MySites haben ein deutlich anderes Muster der Benutzung. In der Regel haben MySites kleine Disk Quotas und wenig „concurrent traffic“, also gleichzeitige Benutzung von vielen Benutzern. In der MySite legen die Benutzer ja wie gesagt persönliche Dinge ab, die entweder gesichert oder für andere publiziert werden. Man könnte also davon ausgehen das 50 rps ausreichend sein könnten. Ich zu meinem Teil habe hier diese 50 rps akzeptiert und kann somit 50‘000 MySites pro Content DB unterbringen.
Die nächsten Bedenken treten bei der Limitation von 100 GB pro Content Datenbank auf. Diese 100Gb werden im TechNet-Artikel al Maximum angegeben. Nun – aus den 50‘000 MySites pro DB mit einer 100GB Limitation und der geplanten Disk Quota kann man nun das Excel bemühen und sich die optimale Anzahl von Datenbanken berechnen. Ebenso lässt sich nun berechnen, wie viele Web Applications gebraucht werden. Denn unter SharePoint ist es möglich, mehrere Web Applications für das Hosting der MySite zu konfigurieren. Diese Konfiguration wird oft verwendet, wenn das Unternehmen geografisch verteilt ist. In diesem Fall werden Regionen als „Audiences“ verwendet und die Benutzer einer MySite-Application zugeweisen.
(Die Excel-Datei für die Berechnungen kann man unter diesen Link herunterladen)
Das Backend
Um die SharePoint-Performance beim Betrieb von vielen Content Datenbanken sicherzustellen, gibt es zusätzlich einiges im Backend zu klären. Der DB-Admin sollte sicherstellen, dass die Datenbanken auf unterschiedlichen Laufwerken (Spindles) liegen. Ebenso wird die UserProfile DB bei so grossen MySites gross. Wenn die MySites intensiv genutzt werden, lohnt es sich, diese Datenbank auf ein separates Laufwerk zu verschieben, oder je nach Benutzungsmuster der MySites sogar eine eigene SQL-Instanz für die User Profle DB aufzusetzten. Zu diesem Thema gibt es ebenfalls auf TechNet ein Whitepaper. Das Whitepaper „SharePoint database performance recommendations“ gibt Anleitungen, wie die Performance von Datenbanken im Zusammenspiel mit SharePoint optimiert werden kann.
Wie man es dreht und wendet: es passt ja eigentlich nie exakt, entweder für die eigene Firma oder aber für die Architektur an der man arbeitet. Was ich zur Lösung meines MySites-Problems gemacht habe ist, dass ich ein System aufgebaut habe, in dem ich alle Benutzer nach der Tätigkeit auf der MySite und dem Platzbedarf (Disk Quota) kategorisiert habe. Das hat erstaunlich gut funktioniert. Aber erst nachdem ich bei der bereits bestehenden SharePoint-Lösung die bestehenden MySites analysiert habe. Diese ist zwar nicht für alle Mitarbeiter verfügbar, aber immerhin gab es einen Anhaltspunkt, wie MySites benutzt werden. Anhand dieser Klassifikation haben sich drei unterschiedliche Typen von MySite-Anforderungen ergeben, die ich dann jeweils mit der Excel-Tabelle berechnet habe. Diese drei MySite-Typen habe ich dann separat geplant und in unterschiedlich spezifizierten Content DBs untergebracht. Das drängte sich auf, da die SQL-Leistung und die Verteilung der Drives einen Teil der Kosten verursachen, die von der DB-Abteilung ans Business verrechnet werden.
