Troubleshooting Distributed Cache

Wenn es mal klemmt mit dem Distributed Cache gibt es ein paar Mittel die helfen können. Die generelle Funktionsweise hab ich schon mal in einem Artikel erläutert.

“Use-CacheCluster” liefert Fehler

Bevor man ja etwas am Distributed Cache machen kann, muss man immer das obligatorische “Use-CacheCluster” auf der PowerShell ausführen. Ich hatte schon mal einen Fall, da war das nicht mehr fehlerfrei möglich und folgende Fehlermeldung wurde angezeigt:
Use-CacheCluster : ErrorCode<ERRPS001>:SubStatus<ES0001>:Error in reading provider and connection string values.
CacheCluster
In meinem Fall ist dieser Fehler nach einer Desaster Wiederherstellung von SharePoint aufgetreten. Mir sind noch weitere Symptome aufgefallen:

  • Windows Dienst “AppFabric Caching Service” lief nicht, obwohl er auf automatisch gestartet war. Auch nicht nach einem Neustart des Servers. Als Erinnerung, man soll nicht die Boardmittel verwenden um den AppFabric direkt zu kontrollieren – das ist Aufgabe von SharePoint. Aber gucken ist erlaubt.
  • SharePoint Health Analyzer hat entsprechen Fehler gebracht, der Caching Service steht nicht zur Verfügung
  • Social Features in SharePoint standen nicht zur Verfügung, z.B. auf der MySite oder die Site Feeds
  • In einer Multi-Server Farm – auf dem falschen Server verbunden

Cache Host aus dem Cache Cluster entfernen:
Remove-SPDistributedCacheServiceInstance
Damit wird auch der Windows Dienst deaktiviert. SharePoint entfernt die Konfiguration der AppFabric
Add-SPDistributedCacheServiceInstance
Damit aktiviert fügt SharePoint einen Cache Host dem Cache Cluster hinzu. Die Konfiguration der AppFabric wird neu geschrieben und der Windows Dienst gestartet.

Cache Hosts anzeigen

Der Status der einzelnen Cache-Hosts kann folgendermaßen angezeigt werden:

Use-CacheCluster
Get-CacheHost

Über die Spalte “Service Status” kann man schon mal einen Hinweis darauf bekommen, wenn ein einzelner Host fehlerhaft ist:

image

Cache Host neu einrichten

 

    1. Cache Dienst auf dem jeweiligen Host stoppen. Damit der Cache immer verfügbar ist, sollte mindestens ein Host laufen. Der Parameter “Graceful” stellt sicher, dass alle Daten im Cache zuvor auf einen anderen Server übertragen werden. Das ist wichtig damit immer ein konsistenter Zustand gewährleistet wird.
      Stop-SPDistributedCacheServiceInstance –Graceful

 

    1. Server entfernen
      Remove-SPDistributedCacheServiceInstance

 

    1. Server hinzufügen
      Add-SPDistributedCacheServiceInstance

 

  1. Status überprüfen
    Use-CacheCluster
    Get-CacheHost

 

Distributed Cache Dienst neu einrichten

Einen Schritt weiter geht dieser Schritt. Damit richten wir den Distributed Cache Dienst am SharePoint neu ein. Dazu gibt es zwei Wege, über die Central Admin oder über PowerShell

Central Admin

 

    • System Settings

 

    • Mange Service on Server

 

    • Distributed Cache Service

 

  • Start / Stop

image

PowerShell

$instanceName = "SPDistributedCacheService Name=AppFabricCachingService"
$serviceInstance = Get-SPServiceInstance | where { ($_.service.tostring()) -eq $instanceName -and ($_.server.name) -eq $env:computername}
#Start: $serviceInstance.Provision()
#Stop: 
$serviceInstance.Unprovision()

 

Cache Host löschen

Zu guter Letzt die harte Variante, die Service Instanz zu löschen und anschließend neu hinzuzufügen:

$instanceName = "SPDistributedCacheService Name=AppFabricCachingService"
$serviceInstance = Get-SPServiceInstance | where { ($_.service.tostring()) -eq $instanceName -and ($_.server.name) -eq $env:computername}
$serviceInstance.delete()
Add-SPDistributedCacheServiceInstance

 

RAM

Je nach Größenordnung der Umgebung muss entsprechend Arbeitsspeicher dem Distributed Cache zugewiesen werden. Tatsächlich verwendet er aber immer doppelt so viel wie konfiguriert. 50% Overhead entstehen durch die Verwaltung des Caches, z.B. ich stelle die Cache Size auf 1 GB ein, tatsächlich verwendet werden dann 2 GB.
Folgende Richtwerte für die Cache Size:

    • Kleine Farm < 10.000 Benutzer: 1 GB

 

    • Mittlere Farm < 100.000 Benutzer: 2,5 GB

 

  • Große Farm < 500.000 Benutzer: 12 GB

Mehr als 16 GB sollten nicht konfiguriert werden, da es sonst zu Instabilität führt. Der Arbeitsspeicher wird pro Host über PowerShell gesetzt. Auf allen Cache Hosts müssen der Wert identisch konfiguriert sein, z.B.:

Update-SPDistributedCacheSize –CacheSizeInMB 1024

Wenn kein Wert konfiguriert wird, wird übrigens 5% des physikalischen Arbeitsspeichers des Servers für den Distributed Cache verwendet.

Dynamic Memory

Dynamic Memory wird nicht unterstützt, daher sollte gerade bei virtuellen Maschinen diese Funktion abgeschaltet werden, und der Arbeitsspeicher statisch vergeben werden.

 

Firewall

Die folgenden Ports werden vom Distributed Cache verwendet (TCP – eingehend):

    • 22233 (Cache Port)

 

    • 22234 (Cluster Port)

 

    • 22235 (Arbitration Port)

 

  • 22236 (Replication Port)

 

Cache neu erstellen (Repopulate)

Für den Fall dass der Cache zwar funktioniert, aber Inhalte nicht stimmen oder veraltet sind, kann ein Repopulate helfen. Nötig kann das z.B. nach einer Wiederherstellung einer Content Datenbank sein, dann sind möglicherweise Inhalte im Cache nicht stimmig.

$ups = get-spserviceapplicationproxy | where { $_.TypeName -eq "User Profile Service Application Proxy"} 
Update-SPRepopulateMicroblogLMTCache -ProfileServiceApplicationProxy $ups
Für einen bestimmten Benutzer:
Update-SPRepopulateMicroblogFeedCache -ProfileServiceApplicationProxy $ups -AccountName Contosoadministrator

 

Monitoring

Der SharePoint Healtz Analyzer prüft stündlich ob der Zugriff auf den Distributed Cache geht (Central Admin – Monitoring – Review problems and solutions). Die Regel kann über “Monitoring – Review rule definitions” angepasst werden:

image

Unter “Monitoring” – “Check job status” – “Job History” kann man sich er Ergebnis der bereits ausgeführten Jobs ansehen. Wichtig für den Distributed Cache: “User Profile Service – Feed Cache Repopulation Job”:

image

Zu guter Letzt gibt es noch einen PowerShell Befehl. Ein Wert von “Healthy = 10.00” gilt als funktional (1 Server), 4,53 (2 Server), 3 (3 Server). Generell empfiehlt Microsoft die Anzahl der Cache Hosts ungerade zu halten, d.h. entweder 1 Server oder 3 Server wenn es um Ausfallsicherheit geht. Zwei Server ist problematisch:

Get-CacheClusterHealth
image

 

Referenz

 

 

0 0 vote
Article Rating
Teilen

Autor: Dennis Hobmaier

Dennis Hobmaier ist Consultant - Digital Workspace bei Insight Technology Solutions GmbH. Er hat über 15 Jahre Erfahrung in IT-Enterprise Umgebung aller Größenordnungen und bedient Kunden aus den unterschiedlichsten Branchen. Als MCSE SharePoint hat er tiefgreifende Kenntnisse in den Bereichen Microsoft Active Directory, Windows, Azure, SharePoint und Office 365. Gerne teilt er seine Projekterfahrung mit Ihnen.

Subscribe
Notify of
guest

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahren Sie mehr darüber, wie Ihre Kommentardaten verarbeitet werden .

1 Comment
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Ali Awwad
5 years ago

Thank you very much.