SharePoint Configuration Best Practices - Request Management Service

  • Article

SharePoint Adventskalender - 17. Türchen

Performance Tuning - Performance Monitoring - Best-Practices für SP-SQL-Konfigurationen - BLOB Management - Backup & Recovery

-------------------------------------------------------------

Bei dem heutigen Thema schauen wir uns einen weniger bekannten Service an, der jedoch sehr interessante Funktionen für uns bereit hält. Die Rede ist vom Request Management Service. Dies ist eine Art Load Balancer hinter dem Load Balancer. Damit kann SharePoint selber bei ankommenden Anfragen entscheiden, ob wirklich der vom Load Balancer zugewiesene WFE die Anfrage bearbeitet, oder ob noch einmal zu einem anderen WFE geroutet wird.

Ein Load Blanacer, wie der F5, arbeitet für ein Netzwerk-Load-Balancing während das Request Management (RM) auf Application-Eben die Last verteilt. Dazu können Throttling Regeln zum „bremsen“ und Routing Regeln zum priorisieren verwendet werden. Der Service ist standardmäßig ausgeschaltet, aber kann pro Web Application über PowerShell konfiguriert werden.

Funktionsweise:
Jedem Server kann über PowerShell ein statischer „Health“-Wert gesetzt werden. Zusätzlich prüft SharePoint alle 5 Sekunden die dynamische „Health“ jedes WFE Servers. Die Skala geht von 0 („am gesündesten“) bis 10. Bekommt ein Server drei mal hintereinander den Wert 10 (z.B. weniger als 20 MB RAM verfügbar), drosselt das RM die Anfragen auf diesem Server. Damit kann verhindert werden, dass ein Routing vom Load Balancer zu einem hängenden Server keine Fehlermeldung beim Endnutzer generiert. Stattdessen wird die Anfrage neu geroutet. Der Request Service fungiert praktisch als Proxy und erstellt eine neue Anfrage, die der alten zwar gleicht, jedoch zu einem neuen WFE geht.

Ablauf:

Zunächst kommt eine Abfrage vom Endnutzer oder vom Load Balancer am SharePoint an.

  1. Dieser evaluiert den Request anhand definierter Regeln. Diese können Eigenschaften (Url, UrlReferrer, UserAgent, Host, IP, HttpMethod, SoapAction, CustomHeader) oder Methoden (StartsWith, EndsWith, Equals, RegEx) überprüfen.
  2. Mögliche Server werden anhand der Regelkriterien und/oder der Server-Gesundheit identifiziert (siehe Bild unten)
  3. Nach Identifizierung des Servers wird der Request dorthin geroutet (bzw. gebremst, bei Throttling Regel).

Regeln werden innerhalb von drei Gruppen (Execution Groups 0 bis 2) zusammengefasst und entsprechend priorisiert. Diese Gruppen repräsentieren Servergruppen, zu denen geroutet werden soll.

  1. Gruppe 0 wird als erste geprüft.
  2. Gibt es keinen Match, werden die Regeln von Gruppe 1 geprüft.
  3. Gibt es ein Match, werden alle Regeln einer niedrigeren Priorität (Execution Group 2) verworfen und der Request direkt bearbeitet.

Gäbe es auch in Gruppe 2 keinen Match, dann wird der Request zu irgendeinem Server geleitet – aber nur dann, wenn ich mindestens in die letzte Gruppe auch eine Art „Catch-All“ Regel definiere, die alle nicht geregelten Anfragen abarbeitet (sollten keine weiteren „freien“ WFE außerhalb der Execution Gruppen existieren).

Vorteile:

  • Ablehnen gefährlicher Anfragen (z.B. von bestimmten Quellen)
  • Priorisieren von Anfragen basierend auf Server-Health und Regeln (z. B OneNote Verkehr immer über Server1; Search Crawler immer auf Server4; neuere Server mit mehr Resourcen können mehr Anfragen übernehmen, etc.)
  • Anfragen können „umgeschrieben“ werden mit beispielsweise sogar einem anderen Port
  • Traffic Isolierung zur Fehleranalyse (z.B. von einer bestimmten Site Collection zu einem bestimmten Server)
  • Regeln kann man auch ein Ablaufdatum mitgeben, sodass spezielle Routings automatisch enden

Nachteile:

  • Zusätzliche Last auf den WFE-Servern durch den RM Service
    Oder besser: Den RM Service auf einem dedizierten Server laufen lassen, z.B. gemeinsam mit einem Distributed Cache Service

Beispiele:

Erstellen einer Routing Regel, um alle Anfragen für Word Dokumente für Web Application https://intranet.contoso.com zum WFE „Server1“ zu leiten.

  1. Request Manager Service auf den WFEs aktivieren:
    1. Central Administration im Browser öffnen
    2. Zu Manage Services navigieren
    3. Request Management Service starten
  2. Scope der Web Application referenzieren
  3. RM Service auf die Web Application referenzieren
    • $RM = $WebApp | Get-SPRequestManagementSettings
  4. Erstellen eines neuen Filter-Kriteriumsmit der “Url” Eigenschaft und RegEx für alle Dokumente vom Typ DOCX
    • $Krit = New-SPRequestManagementRuleCriteria -Property Url -Value ".*\.docx" -MatchType Regex
  5. Sollte dies die erste Regel sein, die wir erstellt haben, müssen wir auch einen Server-Pool erstellen, zu dem diese Anfragen geroutet werden sollen.
    • $Pool = Add-SPRoutingMachinePool -RequestManagementSettings $RM -Name AdventsPool -MachineTargets ($RM | Get-SPRoutingMachineInfo -Name Server1)
  6. Nun kann die Routing-Regel mit obigen Server-Pool und Filter-Kriterium angelegt werden
    • $RM | Add-SPRoutingRule -Name "DOCX Regel" -Criteria $Krit -MachinePool $Pool
  7. Fertig und testen! (ULSViewer is your friend…)

Erstellen einer Throttling Regel, um Anfragen von OneNote auf die Web Application https://intranet.contoso.com zu bremsen, wenn der Health-Wert 8 ist.

  1. Scope der Web Application referenzieren
  2. RM Service auf die Web Application referenzieren
    • $RM = $WebApp | Get-SPRequestManagementSettings
  3. Hinzufügen eines neuen Kriteriums für OneNote 2010 Anfragen. Dies kann über den UserAgent im Request realisiert werden.
    • $Krit = New-SPRequestManagementRuleCriteria -Property UserAgent -Value ".*Microsoft Office OneNote 2010*" -MatchType Regex
  4. Nun fügen wir die Throttling Regel für die Server-Health 8 hinzu.
    *Hinweis: Throttling Regeln gelten im Gegensatz zu Routing Regeln für die gesamte Farm und nicht für einzelne Server(-Pools). Daher müssen wir hier keinen Server-Pool mit angeben.
    • $RM | Add-SPThrottlingRule -Name "OneNote Throttle Rule" -Criteria $Krit –Threshold 8

Viel Spaß beim „SharePointen“

-------------------------------------------------------------

Weitere Türchen: