Share via

SharePoint Configuration Best Practices - Distributed Cache Service

  • Article

SharePoint Adventskalender - 16. Türchen

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

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

Heute wenden wir uns dem in SharePoint 2013 neu eingeführten Distributed Cache Service zu. Dieser basiert auf dem „AppFabric Distributed Caching“ Dienst, der unter der Windows Service Konsole läuft. Er wurde dazu konzipiert, unter anderem Authentifizierungs-Tokens vom Security Token Service (STS) für den „sozialen“ Teil der MySite zu speichern. Diese zwischengespeicherten Daten sind über alle Cache-Server verteilt.

Der Vorteil dieser Technologie ist, dass Daten schnell aus dem Cache geladen werden können. Die Nachteile:

  1. Die Daten sind leider genau so alt, wie die letzte „Cache-Fütterung“. Nämlich der Timer Job mit dem Namen “User Profile Service - Feed Cache Repopulation Job” ist dafür zuständig, den Cache mit aktuellen Feeds zu füttern. Unabnhängig davon wird dieser Vorgang auch immer dann getriggert, wenn auf entsprechende Seiten zugegriffen wird. Gehe ich also auf meine MySite, so wird diese schnell aus dem Cache gerendert. Aber im Hintergrund fragt SharePoint erneut an, ob denn nicht schon aktuellere Daten für die Feeds vorhanden sind. Ist dies der Fall, wird der Cache damit versorgt und bei einem Refresh, bzw. beim nächsten Aufruf der MySite, werden dann eben diese aktualisierten Cache-Daten gerendert. Hinweis: Der Feed-Cache Timer Job läuft zusätzlich alle 5 Minuten nach Standardeinstellung.
  2. Geht ein Cache Server vom Netz, fehlen die dort gespeicherten Daten und müssen erst erneut geladen werden. Den Nachladeprozess all dieser Daten kann man folgendermaßen beschleunigen:
  • Den User Profile Service - Feed Cache Repopulation Job manuell starten oder
  • Folgende PowerShell-Befehle verwenden:
    - Clear-SPDistributedCacheItem
    - Update-SPRepopulateMicroblogLMTCache
    - Update-SPRepopulateMicroblogFeedCache

Sollte einmal bewusst geplant sein, einen solchen Server vom Netz zu nehmen, kann man auch pro-aktiv die gespeicherten Daten auf die anderen Server verteilen:

  • Stop-SPDistributedCacheServiceInstance -Graceful

Infrastrukturplanung:
Zu jeder SharePoint Farm muss auch mindestens ein Cache Host existieren, also ein Server, der den Distributed Cache Service hosted. Der – bzw. in einer größeren Farm mindestens ein – Cache Service sollte auch auf dem gleichen Server laufen, wo die User Profile Application (UPA) läuft. Andernfalls kann es vorkommen, dass sich der oben erwähnte “User Profile Service - Feed Cache Repopulation Job” nicht mit der UPA verbinden kann.

Zudem sollten Sie bei Farmen mit mehr als vier Servern explizit den Distributed Cache Service auf einem oder mehr Servern stoppen. Eine Verteilung von Cache-Daten auf zu viele verschiedene Server würde nämlich im Endeffekt die Performance negativ beeinflussen.

Weiterhin gibt es zur Planung des Distributed Cache Service folgendes zu beachten. Jeder Cache Server benötigt etwa 50% seiner Leistung für einen sogenannten RAM-Speicher-Overhead. Also administrative Aufgaben, um die tatsächlich gecachten Informationen zu verwalten. Damit wird empfohlen, Server mit maximal 16 GB RAM als Cache Server zu hosten. Prinzipiell sind auch größere Speicher möglich, aber durch den Overhead würde es bei einem Cache-Flushing so wirken, als sei der Server „eingefroren“. Dies ist nicht optimal für die „Nutzererfahrung“.

Neben den max. 16 GB RAM sollten auch etwa 2 GB für das Betriebssystem reserviert werden. Als Grundlage haben wir somit 14 GB für den Cache, wovon die eine Hälfte (7 GB) tatsächlich für den Cache und die andere Häfte für den administrativen Overhead genutzt werden soll. Somit teilen wir die gesamte benötigte Cache-Kapazität durch 7 und erhalten die Anzahl für die benötigten Cache Server.

Cache Bedarf / 7 GB = Anzahl nötiger Cache Server

Den Cache Bedarf gibt Microsoft anhand der Nutzer pro Farm mit folgender Tabelle an:

Bereitstellungsgröße

Kleine Farm

Mittlere Farm

Große Farm

Gesamtzahl der Benutzer

< 10.000

< 100.000

< 500.000

Empfohlene Cachegröße für den verteilten Cachedienst

1 GB

2,5 GB

12 GB

Gesamtspeicherzuordnung für den verteilten Cachedienst (doppelter Wert der oben empfohlenen Cachegröße, plus Reserve von 2 GB für das Betriebssystem)

2 GB

5 GB

34 GB

Empfohlene Architekturkonfiguration

Dedizierter Server oder auf einem Front-End-Server

Dedizierter Server

Dedizierter Server

Mindestanzahl von Cachehosts pro Farm

1

1

2

Quelle: https://technet.microsoft.com/de-de/library/jj219572.aspx

Berechtigungen:
Weiterhin zu beachten ist die Berechtigung des Service Acconts, unter dem der Distributed Cache Service läuft. Ähnlich wie beim User Profile Service sind temporär erhöhte Berechtigungen (Local Admin) für das Einrichten erforderlich, um die Tokens vom STS ziehen zu können. Danach können diese Berechtigungen wieder genommen werden. Da es beispielsweise hin und wieder vorkommt, dass der Service neu gestartet werden muss oder andere administrative Eingriffe erforderlich sind, empfehle ich, die erhöhten Berechtigungen dauerhaft zu belassen. Dies widerspricht zwar dem „Least-Privilege“ Ansatz von Microsoft, erleichtert aber die Administration und Fehelerbehebung im Störungsfall.

Viel Spaß beim „SharePointen“

Hinweis:
- Die MySite wurde von Microsoft wieder abgekündigt und wird in O365 bereits durch Delve ersetzt.
- Weitere Informationen zum Distributed Cache Service finden Sie hier: https://technet.microsoft.com/de-de/library/jj219613.aspx?f=255&MSPPError=-2147217396

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

Weitere Türchen: