Patchlørdag med Distributed Cache

Opdatering af en SharePoint 2013-farm. SharePoint Server 2013 var gået ud af support den 11. april, og det var ved at haste. Farmen var fire servere: en webfrontend, en applikationsserver, en søgeserver og en SQL Server.

Cachen først#

Samme mandag skrev jeg regnestykket for Distributed Cache ned. Ved installationen får tjenesten 10 % af serverens hukommelse, og den procentdel regnes ikke om, når serveren får mere. På en server, der mest skal være cache, er størrelsen (RAM − 2 GB) / 2. For en server med 24 GB giver det 11 GB, eller 11264 MB.

Lørdag morgen kørte jeg dette på de tre SharePoint-servere:

 1# Stop
 2$instanceName = "SPDistributedCacheService Name=AppFabricCachingService"
 3$serviceInstance = Get-SPServiceInstance | ? {($_.service.tostring()) -eq $instanceName -and ($_.server.name) -eq $env:computername}
 4$serviceInstance.Unprovision()
 5
 6# Ny størrelse
 7Update-SPDistributedCacheSize -CacheSizeInMB 11264
 8
 9# Start
10$instanceName = "SPDistributedCacheService Name=AppFabricCachingService"
11$serviceInstance = Get-SPServiceInstance | ? {($_.service.tostring()) -eq $instanceName -and ($_.server.name) -eq $env:computername}
12$serviceInstance.Provision()
13Get-AFCacheHostConfiguration -ComputerName $env:computername -CachePort "22233"

Resten af dagen#

Opdateringerne tog det meste af dagen. Efter første genstart fandt webfrontenden én opdatering mere, søgeserveren ni og SQL-serveren to, og på applikationsserveren fejlede én og blev installeret igen. først på eftermiddagen var jeg klar til at køre konfigurationen af farmen på webfrontenden:

PSConfig.exe -cmd upgrade -inplace b2b -force -cmd applicationcontent -install -cmd installfeatures

Den fejlede på display templates, der ikke var installeret. Jeg tog portalens indholdsdatabase af farmen, kørte PSConfig på de tre servere én ad gangen, og satte så databasen på igen og opgraderede den:

1Dismount-SPContentDatabase "<indholdsdatabase>" -Confirm:$false
2Mount-SPContentDatabase "<indholdsdatabase>" -DatabaseServer "<sql-server>" -WebApplication <webapplikation>
3Upgrade-SPContentDatabase "<indholdsdatabase>" -Confirm:$false

Kl. 15.42 kørte den løbende crawl igen, og loggen fra dagen nævner ingen fejl i cachen.

Hvad Microsofts procedure siger#

Læst efter Microsofts dokumentation gjorde jeg to ting anderledes end beskrevet.

Størrelsen ændres én gang for hele klyngen. Proceduren er at stoppe tjenesten på alle cacheværter, køre Update-SPDistributedCacheSize én gang på én af dem og starte tjenesten igen på alle. Min blok gjorde det hele på hver server for sig.

Cachen skal være stoppet, når serveren genstartes. Microsofts vejledning til softwareopdateringer siger, at Distributed Cache skal stoppes, før en server genstartes efter en opdatering eller Configuration Wizard, for at undgå “unallocated cache fractions”. Min blok startede tjenesten igen med det samme, så cachen kørte, da opdateringerne genstartede serverne. I SharePoint 2013, 2016 og 2019 er det pæne stop Microsofts script med Stop-CacheHost -Graceful, ikke Stop-SPDistributedCacheServiceInstance -Graceful, som i de versioner lukker ned, før cachen er flyttet til en anden vært.

Den anden farm#

Samme forår opdaterede jeg hver måned en anden farm. Der var en nulstilling af cachen et fast trin efter PSConfig, og cacheklyngen blev genstartet, når checkpoints var lagt sammen. Scriptet med det navn i mine vedligeholdelsesscripts fjerner tjenesten og lægger den på igen, stopper den, sætter størrelsen, starter den og hæver timeout for feed-cachen, så den kan nå at hente alle profiler bagefter. Størrelsen i scriptet er 23552 MB. Det er over loftet på 16 GB pr. cachevært, som Microsoft sætter, fordi en større cache kan få serveren til at stå stille i mere end 10 sekunder ad gangen.

Formlen, Microsofts rækkefølge for ny størrelse, stop uden datatab, reparation af en vært og fejlen efter januar 2023-opdateringen står i noten Distributed Cache i SharePoint Server.