Sharepoint 2010 mischt die Karten neu, Teil 2
8. April 2010
Dan Holme hat schon in ersten Teil dieses Beitrags einige der wichtigsten Neuerungen bei Sharepoint 2010 vorgestellt und dabei gezeigt, wie sie dem IT-Profi in der Praxis nützen können. In diesem zweiten Teil geht er nun auf die Bereiche Überwachung und Kontrolle dieser Collaboration-Plattform ein und erläutert außerdem, wie es um die Skalierbarkeit dieses neuen Servers bestellt ist.
Auch in den Bereichen Überwachung und Kontrolle stellt diese Sharepoint-Version eine ganze Reihe von Neuerungen zur Verfügung. Microsoft fasst diese Überwachungsfunktionen unter dem Begriff „deep operational insight“ zusammen. Dem Systembetreuer steht in der Zentraladministration des Servers eine Kategorie Überwachung zur Verfügung. Hier kann er dann den Unterpunkt „Probleme und Lösungen überprüfen“ (Bild 1) finden, um eventuell auftretende Probleme zu identifizieren.
Die Seite zeigt die Ergebnisse und Resultate an, die durch ein Set von Regeln erzeugt wird, das regelmäßig und automatisch vom neuen „Best Practice Analyser“ abgearbeitet wird. Jeder Eintrag in dieser „Problemliste“ beinhaltet dann eine Beschreibung des Problems und Anleitungen zu seiner Beseitigung. Die mitgelieferten Grundregeln können von den IT-Fachleuten bearbeitet und verändert werden, wobei sie auch Regeln definieren können, die automatisch ein Problem beseitigen. Diese Regeldefinitionen sind zudem erweiterbar, so dass auch Drittanbieter in der Lage sind, entsprechende Ergänzungen zur Verfügung zu stellen.
Der Administrator möchte aber noch mehr über einen Server wissen und nicht nur sehen, ob dieser in Ordnung ist oder gar ein Problem hat. So ist es für den praktischen Einsatz sehr wichtig, wie die Sharepoint-Farm ausgelastet ist: Welche Sites oder Webseiten aufgerufen werden und welche Seiten und Prozesse die Systemressourcen belasten. Zu diesem Zweck hat Microsoft bei dieser Version eine neue Datenbank eingeführt, die Reporting und Überwachung (Logging) beinhaltet.
Diese Datenbank sammelt alle Aktivitäten, die unter Sharepoint stattfinden: Vom Einsatz individueller Features bis hin zu der Zeit, die es braucht, um eine Webseite zu laden. Einige nützliche Berichte zur Analyse werden bereits mitgeliefert, wie beispielsweise Reports, mit deren Hilfe die langsamsten Webseiten oder die „Top-User“ gefunden werden können. Zudem kann der Administrator seine eigenen Berichte hinzufügen, da das Datenbankschema von Microsoft vollständig dokumentiert wurde. Diese spezielle Datenbank ist erweiterbar, so dass es sowohl für die eigenen IT-Fachleute als auch für Drittanbieter möglich ist, entsprechende Ereignisse zu protokollieren und individuelle Berichte zu erstellen.
Alles im Griff behalten: Kontrolle statt ungezügelter Anpassung
Gerade wenn es um individuellen Programmiercode geht, besteht immer die Gefahr, dass dieser andere Prozesse und Systemressourcen in der Sharepoint-Farm auch negativ beeinflussen kann. Um diese Effekte besser überwachen zu können, existiert das sogenannte „Developer Dashboard“, mit dessen Hilfe Administratoren und Entwickler die Auswirkungen von individuellen Anpassungen überwachen können.
Dieses Dashboard kann auf einer Webseite angezeigt werden, um so Performance- und Debugging-Informationen darzustellen. So bekommt der Administrator zwar schnell einen Zugriff auf die entsprechenden Informationen, aber eine richtige und vollständige Kontrolle kann er erst durch den Einsatz von Sandbox-Lösungen erreichen. Diese „Sandkästen“ können als Sharepoint Solution Packages (.wsp) ausgerollt werden, die dann nur ein eingeschränktes Set von APIs zur Verfügung haben. Auf diese Weise gelingt es, veränderten oder angepassten Programmcode davon abzuhalten, andere Prozesse in der Farm zu beeinflussen. Zudem kann der Administrator so den Ressourcenverbrauch des entsprechenden Codes genau kontrollieren.
Der Systemverwalter kann auf diese Art auch die Aufgabe an Site-Administratoren delegieren, die dann den entsprechenden individuellen Anwender-Code hochladen können. Dabei muss er somit nicht befürchten, dass eventuell auftretende Probleme andere Anwendungen in der Farm beeinflussen könnten.
Aber diese Sharepoint-Version gibt dem Administrator nicht nur die Möglichkeit, individuellen Programmcode zu kontrollieren, sondern erhöht auch die Kontrolle über weitere Veränderungen an den Sharepoint-Seiten. Dazu gehört auch die Möglichkeit, Änderungen am Aussehen und dem Look-and-Feel, wie sie beispielsweise durch Themes oder Veränderungen mittels des Sharepoint Designers 2010 (Bild 2) durchgeführt werden können, zu kontrollieren.
Leider können die Vorteile, die beim Einsatz von Visual Studio 2010 oder Sharepoint Designer 2010 zur Verfügung stehen, nur dann auch eingesetzt werden, wenn die entsprechenden Anwendungen auf einer Sharepoint-2010-Site laufen. Wer für Sharepoint 2007 Code anpassen und entwickeln will, ist sogar gezwungen die älteren Versionen von Visual Studio und Sharepoint Designer einzusetzen. Wer in seinen SharePoint-Farmen also eine gemischte Umgebung mit den verschiedenen Versionen von Sharepoint betreibt, muss auch diese verschiedenen Versionen der Werkzeuge pflegen und verwalten. Ein weiterer Punkt, der Administratoren sicher darüber nachdenken lassen wird, möglichst schnell die komplette Sharepoint-Infrastruktur auf die neue Version umzustellen.
Alle Office-2010-Anwendungen stellen Administratoren und Anwendern zusätzlich Funktionalitäten zur Verfügung, wenn sie in Zusammenarbeit mit Sharepoint 2010 zum Einsatz kommen. Während es in vielen Firmen bereits üblich sein dürfte, Word, PowerPoint, Excel, Outlook oder auch Onenote, Project und Access in diesem Zusammenhang mit Sharepoint einzusetzen, werden mit dieser Version sicher weitere Anwendungen in die Firmen einziehen, die vielfach noch nicht Gebrauch sind.
Dazu zählen neben dem bereits erwähnten Sharepoint Designer (Bild 2) auch solche Anwendungen wie die Sharepoint Workspaces (Bild 3), die früher einmal unter dem Namen „Groove“ bekannt waren, und dann noch Infopath.
Die Erfahrungen des Autors zeigen, dass die Anwender diese Möglichkeiten und Fähigkeiten sehr schnell zu schätzen wissen, wenn sie diese Programme erst einmal kennenlernen konnten. War es unter Sharepoint 2007 nur möglich, die Client-Integration komplett mit einem Schalter ein- oder auszuschalten, stellt die neue Sharepoint-Version den Administratoren hier ein weitaus feinere Abstufung zur Verfügung: So kann er einzelne Integrationsfeatures der Office-Clients auf dem Level der Listen oder Bibliotheken entsprechend ein- oder ausschalten.
Unter Sharepoint war es bisher in gewisser Weise sehr einfach für die Administratoren, wenn es um die einzusetzenden Browser auf den Clients-Systemen ging: Die Anwender konnten nur und ausschließlich mittels des Internet Explorers auf die jeweiligen Sharepoint-Seiten zugreifen. Diese Einschränkung war für einige Administratoren auch willkommener Anlass, in ihren Netzen den Einsatz anderer Browser grundsätzlich zu untersagen. Diese Einschränkung besteht nun nicht mehr, denn Sharepoint 2010 unterstützt nun auch Firefox, Google Chrome, den Safari-Browser und andere Clients.
Skalierbarkeit an allen Enden: Listen, Bibliotheken und die Farm
Die Möglichkeiten der Listen und Bibliotheken wurden von den Entwicklern mit diesem Release deutlich erweitert: So werden vom Programm nun sowohl Listen als auch Bibliotheken unterstützt, die Millionen von Einträgen besitzen können. Dabei wurden sowohl im Backend – durch erweiterte SQL-Server Queries – als auch im Front-End – hier durch die Art und Weise, wie Web-Frontend-Server den Inhalt von Listen und Bibliotheken abarbeiten und anzeigen – weitreichende Änderungen vorgenommen. Durch diese Änderungen wurde besonders die Balance zwischen dem Komfort für den Endanwender bei der Abarbeitung dieser Listen und Bibliotheken und der Belastung für die Server-Infrastruktur durch eine solche Bearbeitung erheblich verbessert.
So kann der Administrator auf der Server-Seite die Einstellungen in den Web-Anwendungen verändern, mit denen die maximale Anzahl der Ergebnisse kontrolliert werden, die bei einer Anfrage durch eine Listen- oder Bibliotheksansicht generiert werden. Als Standardwert ist hier 5000 vorgegeben, wobei der Systemverwalter an dieser Stelle beispielsweise auch unterschiedliche Limits für administrative tägige und „normale“ Anwender setzen kann. Wenn die Anfrage eine Anzahl von Ergebnisse generiert, die das gesetzte Limit überschreitet, wird am Anfang der Liste eine entsprechende Warnung eingeblendet.
Die Einstellungen bei den Webanwendungen erlauben es dem Systemverwalter aber zusätzlich, einen Wert einzustellen der auch als „Happy Hour Window“ bezeichnet wird: Ein Zeitspanne an jedem Tag, in der diese Einschränkungen nicht gelten. Dabei kann der Systembetreuer allerdings nur den Start zu einer bestimmten Tageszeit an sieben Tagen in der Woche für jeweils eine gewisse Anzahl von Stunden festlegen. Nicht nur der Name sondern auch die fehlende Möglichkeit, diese Zeiten feiner und genauer einzustellen, lassen dieses Feature aber insgesamt etwas unfertig und für die Praxis wenig geeignet erscheinen.
Wenn nicht gerade die „Happy Hour“ aktiv ist, wird Sharepoint dem Anwender nicht mehr als die im Limit festgelegte Anzahl an Einträgen anzeigen. Aber es ist unter Sharepoint 2010 für die Anwender sehr leicht möglich, die Anzahl der Resultate besser einzuschränken. Dazu können dann Metadaten eingesetzt werden. Mit ihrer Hilfe können eine Navigations-Hierarchie und entsprechenden Inhaltsfilter angelegt werden. Als Resultat steht den Anwendern eine Tag-basierte Verzeichnishierarchie zur Verfügung, die unter Einsatz von Schlüsselwörter und der Metadaten die Anzahl der Resultate deutlich genauer filtern kann.
In dieser Version des Sharepoint-Systems wird das bisherige Modell des Shared Service Providers (SSP) durch die Service Applications (Dienste-Anwendungen) abgelöst. Administratoren sollten deshalb versuchen alles zu vergessen, was sie über SSP wissen, denn das neue Modell ist nicht nur radikal anders sondern auch besser und einfacher geworden.
Sharepoint 2010 stellt verschiedene eingebaute Dienste zur Verfügung. Dazu gehören unter anderem Business Data Connectivity, die grafischen Dienste für Visio, die Excel-Dienste, die Office-Web-Anwendungen, die Suche, Anwenderprofile und Web Analytics. Ganz neu ist in diesem Zusammenhang der Managed Metadata Dienst.
Er erstellt einen zentralen Speicher für die Taxonomie und die verschiedenen Inhaltstypen. Jeder dieser Dienst läuft dabei als eine Anwendung, die als ein Windows Communication Foundation (WCF) Dienst sichtbar ist, auf einem oder mehreren der Server der Sharepoint-Farm. Nutzer dieser Dienste sind etwa Web-Parts, die typischerweise auf Web-Frontends aktiv sind. Um diesen Nutzer mit dem entsprechenden Dienst zu verbinden, besitzt jede Dienstanwendung einen Proxy, der die Verbindung zum Dienst herstellen kann.
Eine solche Architektur bietet verschiedene Vorteile: So ist sie beispielsweise für Drittanbieter problemlos erweiterbar. Zudem kann ein solcher Dienst anderen Farmen zur Verfügung gestellt werden, indem der Dienstanwendungs-Proxy in dieser anderen Farm installiert wird. Er verweist dann auf den URI (Uniform Resource Identifier), der von der Zentraladministration zu dem Zeitpunkt zur Verfügung gestellt wird, zu dem der Administrator die Anwendung veröffentlicht. Auf diese Weise werden Farmen in die Lage versetzt, Dienstanwendungen zu teilen und so einheitliche Dienste für Funktionen wie Suche, Taxonomie, Daten-Aggregation und Analyse bereit zu stellen.
Weiterhin können Webanwendungen so konfiguriert werden, dass sie eine oder mehrere Instanzen eines Dienstes einsetzen. So könnte beispielsweise eine Webanwendung, die spezielle für die Buchhaltung entworfen wurde, einen Taxonomie-Dienst verwenden (Managed Metadata Dienst), der eine spezielle Taxonomie für den Finanzbereich zur Verfügung stellt. Zudem könnte sie aber auch einen weiteren Dienst einsetzen, der dann eine spezielle Taxonomie auf Unternehmensebene zur Verfügung stellt.
Der dritte große Vorteil dieser Architektur besteht darin, dass die Dienste in Zeiten hoher Anforderung entsprechend skaliert werden können: Stellt der Systembetreuer zum Beispiel fest, dass ein ganz bestimmter Dienst sehr stark verwendet wird, so kann er die Dienstanwendung auf zusätzlichen Anwendungsservern einsetzen. Fragt der Service-Proxy nach dem Standort des WFC-Dienstes, so wird ihm die Dienst-Architektur die Instanz des Dienstes im Round-Robin-Verfahren anbieten, wobei dabei natürlich der neue Anwendungsserver mit eingeschlossen wird.
Schließlich muss noch die sogenannte Multi-Tenacy-Fähigkeit der Dienste-Anwendungen erwähnt werden. Damit wird in der Regel die Fähigkeit beschrieben, mehrere Mandanten einer Software auf einem gemeinsamen System zu betreiben. Hier wird sie dazu eingesetzt, einen Dienst so aufzuteilen, dass er eine Teilmenge der Daten zurückgeben kann. Klassischerweise kommt diese Vorgehensweise bei Hosted Sharepoint Servern zum Einsatz, wenn beispielsweise ein einzelner Suchdienst dazu verwendet wird, mehrere Kunden zu bedienen. Dabei ist es selbstverständlich extrem wichtig, dass die Suchergebnisse auf die Daten jedes einzelnen Kunden beschränkt bleiben.
Eine derartige Sicherheit wird dadurch erreicht, dass Multi-Tenancy eingeführt wird. Diese Technik ergänzt jede Datenreihe im Suchdienst durch eine eindeutige User-ID. So kann eine für einen Anwender mit einer bestimmten User-ID spezifische Datensammlung nur die Resultate von einem Dienst zurückgeben, der die übereinstimmende ID besitzt. Auch und gerade im Unternehmensumfeld und innerhalb eines Intranets wird es genügend derartige Szenarien geben, bei denen die Daten, die von einer einzigen Dienstanwendung geliefert werden, bei der Ausgabe entsprechend aufgeteilt und zugewiesen werden sollen.
