Con l’avvicinarsi dell’estate, e conseguentemente delle ferie dei dipendenti delle aziende, si presenta un buon momento per prendersi cura delle proprie SharePoint Farm, pianificando attività di aggiornamento sulle infrastrutture di produzione, cercando di minimizzare il disagio verso gli utenti.
Come molti sapranno, durante il processo di aggiornamento (sia che si tratti di Service Pack che di Cumulative Updates) i siti SharePoint non sono raggiungibili. Creando conseguentemente un disservizio verso gli utenti.
Una buona prassi è quella di cercare di stimare i tempi di disservizio, valutando i tempi di aggiornamento di altre infrastrutture (es. la Farm di test/collaudo), applicando eventuali ragionamenti peggiorativi/migliorativi sui tempi di elaborazione, in relazione ad un diverso numero di server nella Farm ed alle diverse risorse hardware a disposizione e del differente volume dei dati (rammento che durante gli aggiornamenti avviene anche l’update dello schema dei DB, con conseguente impatto sui tempi in funzione della dimensione e della quantità dei DB).
Chi ha eseguito già aggiornamenti per SharePoint 2013 si sarà accorto di tempi mediamente più lunghi, rispetto alle precedenti esperienze di aggiornamento di infrastrutture SharePoint 2007 o 2010.
Già dal passato io ho l’abitudine di disabilitare gli eventuali antivirus presenti sui server, evitando spiacevoli rallentamenti dovuti ad essi.
Ma aggiornare una Farm SharePoint 2013 potrebbe davvero diventare un’esperienza lenta… parlo di 4-5 ore per attività che in passato duravano 30 minuti… quindi non parlo di tempi trascurabili. Tempi che inesorabilmente andranno ad incrementare il disservizio verso gli utenti.
Una delle ragioni è legata alla presenza di componenti di servizio, che in passato non erano presenti, come App Fabric ed il nuovo Search (con gli elementi “Node runner”).
Disservizio per disservizio, una delle tecniche che io ed i colleghi di Green Team stiamo seguendo ultimamente per gli aggiornamenti delle farm è quella di disattivare un certo numero di servizi e componenti sui server, avviando così gli updates in un contesto “normale”, con piene risorse a disposizione.
Sostanzialmente, come ben descritto anche su questo post di Russ Maxwell, si procede così:
- Disable the IISAdmin and SPTimerV4 service
- Shut down IIS Admin and Timer Services if they are running
- Give you the option to Pause the Search Service Application (see search notes below)
- Stop Search Services (see search notes below)
- Install the patch in passive mode (No user interaction required but will witness the patch install in the UI)
Note: Power Shell should remain open in the background while patch is running - Upon completion of the patch, the Power Shell script, services in step 1 are set to Automatic
- Starts up IIS Admin and Timer Services
- Starts up Search Services
- Resume the Search Service Application if it was paused
- Finally, the script will display the Start Time and End Time for patch install
Per semplificare le cose, Russ ha preparato uno script Powershell disponibile sulla pagina del post (molto utile, ma suggerisco di eseguirlo con attenzione e intelligenza su farm composte da più server).
Infine, non mi stancherò mai di raccomandare la massima prudenza prima di procedere con gli aggiornamenti della farm. Assicuratevi di disporre di un “restore point” affidabile, eseguendo un full backup di tutti i DB della Farm e creando uno snapshot di tutte le VM, in modo da essere certi di poter ritornare al punto di ripristino (RPO) in maniera sicura e veloce (RTO).