Blog > Mai 2010
Im vierten Teil der Serie geht es um die Basiskonfiguration der Farm und erstes Troubleshooting.
Veröffentlicht am 12.05.2010 21:25:39 von Reiner Ganser mit 2 Kommentar(en)
Nach erfolgreicher Installation der Farm in Teil 03 benötigt die Konfiguration der großen SharePoint 2010 Farm unsere Aufmerksamkeit. Dazu gehört neben den Einstellungen für Mail insbesondere die Konfiguration des Loggings und der Diagnose . Outgoing Mail Settings
Der Versand von E-Mail ist die Basis von vielen Diensten, in denen der Anwender über Änderungen und Aktualisierungen benachrichtigt wird. Auch Farm und Site Administratoren können so automatisch über den Status oder Probleme informiert werden, z.B. wenn Site Quotas überschritten werden. Dafür muss ein SMTP Server auf Farmebene konfiguriert werden. Es besteht auch die Möglichkeit, pro Web Application einen separaten SMTP Server zu definieren. In meinem Szenario bleibe ich aber vorerst bei der Farmeinstellung. In der Zentral Administration navigiert man über:
System Settings > Configure outgoing e-mail settings
um den SMTP Server zu konfigurieren. Im Dialog stellt man seinen SMTP Server ein. Leider kann man an dieser Stelle keine Authentifizierungsmehtode wählen. Das bedeutet, dass der Mail Server so eingestellt wird, dass er anonymes Mail empfangen und weiterleiten muss (Mail-Relay). Aus Gründen der Sicherheit wird der Mail Server daher meist so konfiguriert, dass er anonymen Mails nur von den besagten SharePoint 2010 Server akzeptiert und nicht von jedem x-beliebigen System im Netz. Wichtig für das Change Management ist, dass neue Server in der Farm, z.B. bei einem Scale-Out durch einen weiteren WFE beim SMTP Server berücksichtigt werden.
Alle SharePoint 2010 Server schreiben unterschiedliche Daten lokal in Logdateien. Da die Logging-Konfiguration nur für die gesamte Farm definiert werden kann, sollte man darauf achten, dass auf allen SharePoint 2010 Server dieselbe Verzeichnisstruktur für die Logdateien existiert. Die Logdateien werden in dem ULS Log Format erstellt. Glücklicherweise kann über Log-Level und Log-Kategorien gezielt definiert werden, welche Ereignisse zu protokollieren sind. Ein Event-Throtteling Mechanismus für das Event Log (nicht für das Trace Log) verhindert darüber hinaus das “Fluten” des Logs, z.B. mit immer denselben Fehlerinformationen.
In einer großen Farm sind die Services auf unterschiedlichen Servern verteilt und der Aufruf einer Seite durch den Endanwender auf einem WFE für zu weitern Aktionen wie z.B. Datenbankzugriffen, Zugriff auf den Metadatenservice, etc., etc auf weiteren SharePoint Servern. Um diese Zugriffe, die bei entsprechender Konfiguration auf dem jeweiligen Server lokal protokolliert werden, dieser initalen Benutzeraktionen zuordnen zu können, erstellt und verwendet SharePoint 2010 für jeden Request eine CorrelationID. In einer großen Farm mit redundanten Service Applications hat man dann auf verschiedenen SharePoint 2010 Server Logeinträge in den Logdateien, die dieselbe CorrelationID verwenden. Tritt nun ein Fehler auf, dann erhält man eine SharePoint Fehlermeldung, in der auch die Correlation ID zu finden ist. Um die eigentliche Fehlerursache zu identifizieren, muss nun in allen Log Files nach dieser ID gesucht werden.
Zum Lesen und Interpretieren der ULS Logs verwendet man Notepad, Excel oder gleich den ULS Viewer (für SharePoint 2007 und 2010 unter http://code.msdn.microsoft.com/ULSViewer. Trotzdem wäre es sehr mühsam manuell über alle Server einer Farm alle Einträge in den ULS Logdateien für eine Benutzeraktion über die CorrelationID zu identifizieren. Deshalb gibt es neben dem PowerShell Befehl Merge-SPLogFile, der aus allen Logfiles auf allen Servern eine einzige Log-Datei erstellt, die Möglichkeit, die ULS Log Einträge und Event Log Einträge in eine zentrale Logging Datenbank durch einer Timer Job kopieren zu lassen.
Unter Diagnostic Logging bietet SharePoint 2010 zum einen die Möglichkeit zu bestimmen, für welche Kategorien Informationen in das Trace Log geschrieben werden. Für alle Kategorien bzw. pro Kategorie kann der Log Level für das Event Log (Windows) und das Trace Log (SharePoint) separat bestimmt werden. Will man unterschiedliche Log Level für unterschiedliche Kategorien haben, muss man die Kategorien auswählen, den Log Level setzen und mit OK speichern. Dann wiederholt man den Prozess für andere Kategorien und einem anderen Log Level. Der Standardwert für alle Kategorien ist Event Level = Information und Trace Level = Medium. In der Zentral Administration navigiert man über:
Monitoring > Configure diagnostic logging
um das Trace Log zu konfigurieren: Business Data wurden auf Error und Medium eingestellt. Performance Point Service wird hier auf Warning und High eingestellt. Zum Schutz des Windows Event Logs sollte die Flood Protection gesetzt: Trace Log: Für die große SharePoint 2010 Farm muss der Pfad noch angepasst werden. Für die Testumgebung reichen 7 Tage Aufbewahrungsfrist und 2GB Storage für das Trace Log aus: Der Account “LOCAL SERVICE” sollte das Recht haben, die Trace Logs zu schreiben und zu lesen. Er ist auch Owner der Trace Log Dateien.
Für einen Entwickler auf seiner Single Server Farm kann übermäßiges Logging der Performance hinderlich sein. Im Gegensatz zur Vorgängerversion kann man aber nicht einfach den Pfad zum Logverzeichnis löschen sondern muss den Log Level für alle Kategorien entsprechend einstellen (“None”).
Neben dem klassischen Trace Logging unterstützt SharePoint ein Usage Data Collection.Die gesammelten Daten dienen als Grundlage für weitere Analysen und Reports. In der Zentral Administration navigiert man über:
Monitoring > Configure usage and health data collection
um das Usage Data Collection zu konfigurieren:
Im Gegensatz zum Trace Logging kann man das Usage Data Collection einfach ein- und ausschalten: Das sind die Health Jobs: Logging – Collection to Database
Neben dem klassischen Trace Logging unterstützt SharePoint ein Usage Data Collection. Daten werden gemäß den konfigurierten Eventkategorien über alle Server der SharePoint 2010 Farm gesammelt und dienen als Grundlage für weitere Analysen und Reports. In der Zentral Administration navigiert man über:
um das Usage Data Collection zu konfigurieren: Es werden anscheinend nur die Usage Data in die Datenbank alle 30 Minuten kopiert. Auch wenn kein Usage Data Collection aktiviert ist, läuft der Timer Job “Microsoft SharePoint Foundation Usage Data Import” alle 30 Minten. Ist Usage Data Collection aktiviert läift zusätzlich ein täglicher Time Job “Microsoft SharePoint Foundation Usage Data Processing”: Wenn Auch wenn das Usage Logging und das Health Loggin nicht aktiviert wird, aber man dennoch im Dialog OK klickt, wird die Logging Datenbank erstellt. Ein Blick in die Datenbank deckt auf, welceh Informationen tatsächlich in die Datenbank kopiert werden. Es werden tatsächlich die ULS Log von allen Server in die Datenbank kopiert – und sogar die SharePoint relevanten Event Log Einträge. Endlich eine zentrale Stelle für alle Logs, erreichbar über das Netzwerk sowie mit Bordmitteln von SQL und Office analysierbar. dbo.BlockingQueries_Partition## dbo.Confíguration dbo.ExportUsage_Partition## dbo.FeatureUsage_Partition## dbo.ImportUsage_Partition## dbo.MonthlyPartitions dbo.NTEventLog_Partition## dbo.PerformanceCounters_Partition## dbo.RequestUsage_Partition## dbo.SiteInvewntory_Partition## dbo.SQLMemoryQueries_Partition## dbo.TimeJobUsage_Partition## dbo.ULSTraceLog_Partition## dbo.Versions Da die Daten über Partitionen verteilt werden, bringt die Datenbank einige Views (UINION ALL) mit:
dbo.BlockingQueries dbo.ExportUsage dbo.FeatureUsage dbo.ImportUsage dbo.NTEventLog dbo.PerformanceCounters dbo.RequestUsage dbo.SiteInvewntory dbo.SQLMemoryQueries dbo.TimeJobUsage dbo.ULSTraceLog
Für einen Entwickler mit einer Single Server Farm oder Stand alone System, ist das exzessives Logging hinderlich. Dann sollte das Logging entweder ganz abgeschaltet oder auf ein Minimum reduziert werden.