Distributed Cache i SharePoint Server
Hukommelsen til Distributed Cache, hvordan den ændres uden at ødelægge cacheklyngen, stop, start og reparation — og fejlen efter januar 2023-opdateringen.
Distributed Cache er den tjeneste i SharePoint Server, der holder logon-tokens, feeds, view state, sikkerhedstrimning og en række andre ting i hukommelsen, så de ikke skal hentes igen for hver side. Den findes i SharePoint Server 2013, 2016, 2019 og Subscription Edition og kører oven på Windows Server AppFabric, undtagen i Subscription Edition, hvor Microsoft har bygget AppFabric ind i SharePoint. I SharePoint Online er der intet at konfigurere.
Tjenesten er skrøbelig. Microsoft skriver selv, at den kan ende i en tilstand, der ikke kan genoprettes, hvis procedurerne ikke følges, og at det i værste fald betyder, at farmen skal bygges om. Derfor er det her skrevet ned.
Hukommelsen#
Ved installationen får tjenesten 10 % af serverens hukommelse. Halvdelen bruges til data (cachestørrelsen), resten til administration af hukommelsen. Den procentdel regnes ikke om, når der sættes mere hukommelse i serveren.
På en server, der kun kører Distributed Cache:
(Serverens RAM - 2 GB) / 2 = cachestørrelse
| RAM | Cachestørrelse |
|---|---|
| 16 GB | 7 GB = 7168 MB |
| 24 GB | 11 GB = 11264 MB |
| 32 GB | 15 GB = 15360 MB |
| 34 GB og mere | 16 GB = 16384 MB (loftet) |
Cachestørrelsen må højst være 16 GB pr. cachevært. Over det kan serveren ifølge Microsoft holde op med at svare i mere end 10 sekunder ad gangen. Er der brug for mere, er svaret flere cacheværter, ikke en større. Alle værter i klyngen skal have samme størrelse.
Den nuværende størrelse på en server, i SharePoint Server 2013, 2016 og 2019:
1Use-CacheCluster
2Get-AFCacheHostConfiguration -ComputerName $env:COMPUTERNAME -CachePort 22233
I Subscription Edition har AppFabric-cmdlets fået SP i navnet:
1Use-SPCacheCluster
2Get-SPCacheHostConfig -HostName $env:COMPUTERNAME
Ændr størrelsen#
Rækkefølgen er det vigtige: tjenesten stoppes på alle cacheværter, størrelsen ændres én gang på én af dem, og tjenesten startes igen på alle.
Stop på hver vært (SharePoint Server 2013, 2016 og 2019):
1$instanceName = "SPDistributedCacheService Name=AppFabricCachingService"
2$serviceInstance = Get-SPServiceInstance | ? {($_.service.tostring()) -eq $instanceName -and ($_.server.name) -eq $env:computername}
3$serviceInstance.Unprovision()
Ny størrelse, én gang, på én vært:
1Update-SPDistributedCacheSize -CacheSizeInMB 11264
Start på hver vært:
1$instanceName = "SPDistributedCacheService Name=AppFabricCachingService"
2$serviceInstance = Get-SPServiceInstance | ? {($_.service.tostring()) -eq $instanceName -and ($_.server.name) -eq $env:computername}
3$serviceInstance.Provision()
På en farm med én cachevært er det de tre blokke efter hinanden på samme server. I Subscription Edition hedder instansen SPDistributedCacheService Name=SPCache. Stop og start kan også gøres under Services on Server i Central Administration.
Stop uden at miste data#
Unprovision() er et almindeligt stop. Det, der ligger i cachen på den server, forsvinder. Det meste bygges op igen, men tags og dokumentaktiviteter findes kun i feed-cachen og gemmes ikke i indholdsdatabaserne, så de er væk.
Skal en server opdateres, mens resten af klyngen kører, flyttes indholdet først til de andre værter. I Subscription Edition:
1Stop-SPDistributedCacheServiceInstance -Graceful
I SharePoint Server 2013, 2016 og 2019 med Microsofts script, som venter, til værten er nede (op til 15 minutter):
1$startTime = Get-Date
2$currentTime = $startTime
3$elapsedTime = $currentTime - $startTime
4$timeOut = 900
5Use-CacheCluster
6try
7{
8 Write-Host "Shutting down distributed cache host."
9 $hostInfo = Stop-CacheHost -Graceful -CachePort 22233 -ComputerName <server>.<domæne>
10 while($elapsedTime.TotalSeconds -le $timeOut -and $hostInfo.Status -ne 'Down')
11 {
12 Write-Host "Host Status : [$($hostInfo.Status)]"
13 Start-Sleep(5)
14 $currentTime = Get-Date
15 $elapsedTime = $currentTime - $startTime
16 $hostInfo = Get-CacheHost -HostName <server>.<domæne> -CachePort 22233
17 }
18 Write-Host "Stopping distributed cache host was successful. Updating Service status in SharePoint."
19 Stop-SPDistributedCacheServiceInstance
20 Write-Host "To start service, please use Central Administration site."
21}
22catch [System.Exception]
23{
24 Write-Host "Unable to stop cache host within 15 minutes."
25}
Microsoft skriver, at scriptet skal gemmes som ANSI-kodet .ps1.
Tilføj, fjern og reparér en vært#
Kommandoerne køres på den server, det gælder:
1Add-SPDistributedCacheServiceInstance
1Remove-SPDistributedCacheServiceInstance
En vært, der ikke virker — Health Analyzer melder fejl, nyhedsfeedet fejler, eller cmdlets svarer “cacheHostInfo is null” — repareres med Remove-SPDistributedCacheServiceInstance efterfulgt af Add-SPDistributedCacheServiceInstance. Fejler fjernelsen, slettes instansen i hånden, og så køres Add igen:
1$instanceName = "SPDistributedCacheService Name=AppFabricCachingService"
2$serviceInstance = Get-SPServiceInstance | ? {($_.service.tostring()) -eq $instanceName -and ($_.server.name) -eq $env:computername}
3If($serviceInstance -ne $null)
4{
5 $serviceInstance.Delete()
6}
Status for alle værter i klyngen:
1Use-CacheCluster
2Get-CacheHost
Alle værter skal stå som UP.
Flere værter#
Værterne taler sammen på TCP 22233, 22234, 22235 og 22236, og den første vært i klyngen skal tillade indgående ICMP (ICMPv4) gennem firewallen. Forbindelsen kan tjekkes fra en anden vært:
1Test-NetConnection -ComputerName <cachevært> -Port 22233
2Test-NetConnection -ComputerName <cachevært> -Port 22234
Microsoft anbefaler dedikerede cacheservere, og ikke at køre Distributed Cache på samme server som søgning, SQL Server eller Project Server. Over 10.000 brugere vil Microsoft have en dedikeret server, og i en stor farm mindst to værter.
Efter januar 2023-opdateringen#
Den kumulative opdatering fra januar 2023 strammede sikkerheden på forbindelsen mellem SharePoint og cacheklyngen i SharePoint Server 2016, 2019 og Subscription Edition. Hos nogle blev ændringen ikke lagt rigtigt på, og forbindelsen til cachen fejlede med “Failed to connect to hosts in the cluster” og “There is a temporary failure. Please retry later” i ULS-loggen. Stefan Goßners rettelse (februar 2023) var at sætte klyngens sikkerhed igen:
1Stop-CacheCluster
2Set-CacheClusterSecurity -SecurityMode Transport -ProtectionLevel EncryptAndSign
3Start-CacheCluster
I Subscription Edition med Stop-SPCacheCluster, Set-SPCacheClusterSecurity og Start-SPCacheCluster. Dertil en registreringsnøgle til en custom provider på servere uden Distributed Cache, og læseadgang for gruppen WSS_WPG til HKLM\SYSTEM\CurrentControlSet\Control\SecurePipeServers\winreg. Detaljerne står i hans indlæg “Trending issue: Distributed Cache problems after applying January 2023 CU”. Fejlen er rettet i opdateringen fra maj 2023, så på en farm, der er opdateret siden, er det historie.
Overvågning#
De tællere, Microsoft nævner som nyttige: CPU brugt af cachetjenesten, tid brugt i garbage collection, Total cache misses/sec, Total object count, Total client reqs/sec, Total Evicted Objects og Total failure exceptions/sec. Smider værten hele tiden objekter ud for at få plads (Total Evicted Objects), mangler den hukommelse.
Det der driller#
- Aldrig via Services eller AppFabric-værktøjerne. AppFabric Caching Service må ikke startes eller stoppes i Windows’ tjenester, og programmerne under AppFabric for Windows Server i startmenuen må ikke bruges. Kun SharePoints egne cmdlets og Central Administration.
- Størrelsen ændres én gang for hele klyngen, ikke server for server. Microsofts procedure stopper tjenesten på alle værter først. At ændre og genstarte én server ad gangen, mens de andre kører, er ikke den procedure.
Unprovision()er ikke et pænt stop. Det pæne stop er-Gracefuleller Microsofts script.- Tjenestekonti med
$i navnet må ikke bruges. - Subscription Edition har andre navne. Instansen hedder
SPCache, og cmdlets hedderUse-SPCacheCluster,Get-SPCacheHostosv.