Aggiornare una solution SharePoint senza disservizio

Normalmente in SharePoint 2010 e SharePoint 2013 quando si aggiorna una solution, al termine del processo di deploy si crea un disservizio nella farm e le chiamate ad una web application ritornano un errore http 503. Questo comportamento è veramente fastidioso soprattutto quando la farm ospita un sito pubblico, oppure una intranet utilizzata in più parti del mondo (più fusi orari) e quindi non esiste una finestra temporale per gli aggiornamenti.

In determinate condizioni è possibile evitare il disservizio.

Prima di tutto vediamo cosa avviene quando si aggiorna una solution (.wsp). Il comando PowerShell è il seguente:
Una volta lanciato, il comando termina quasi subito, e in background (asincrono), avvengono i seguenti macro passaggi:

• Il file di solution (MiaSolution.wsp) viene caricato nel database di configurazione
• viene creato un timer job su ogni macchina della farm che si occuperà di distribuire, in base al file manifest contenuto nel wsp, i file contenuti nelle corrette posizioni (15 hive / bin / gac / web.config)
• alla fine del processo di deploy vengono riavviati i worker process (Application Pool) di IIS

Ed è proprio questo ultimo passaggio che crea il disservizio. Questo disservizio è necessario affinché le modifiche apportate vengano recepite, come ad esempio:

• che le precedenti DLL vengano scaricate e vengano caricate le nuove
• che le eventuali modifiche cross farm, come ad esempio l'aggiunta di una nuova definizione di campo, vengano recepite
• oppure l'aggiunta di una web part, che necessita di essere registrata nel web.config come safe (le modifiche al web.config provocano un recycle dell'application pool)

Come dicevo prima in determinate condizioni è possibile evitare il disservizio. Le condizioni sono:

• avere una farm ridondata con almeno 2 Front End (FE)
• avere un bilanciatore di carico davanti ai FE
• usare il parametro -Local ed eseguire il comando PowerShell su ogni server della farm

Questa è la configurazione minima necessaria per eseguire un aggiornamento senza disservizio:Il bilanciatore di carico può essere ad esempio:

• Il Network Load Balancing (NLB) di Microsoft
• un cluster a 2 o più nodi (uno per ogni FE) dove le risorse in cluster sono 2 IP che vanno registrati nel DNS con lo stesso nome (Round robin)
• un apparato hardware esterno

Indipendentemente dalla soluzione scelta, l'importante è che si possa mettere off-line un nodo senza creare disservizio, altrimenti è tutto inutile.

Per eseguire un aggiornamento senza disservizio la prima cosa da fare è mettere off-line un nodo, ad esempio il nodo 1:a questo punto tutto il traffico è sul nodo 2, quindi possiamo aggiornare il nodo 1.Il comando per l'aggiornamento è sempre Update-SPSolution solo che va aggiunto il parametro Local:
In questo caso il processo di deploy è simile al precedente, con l'unica differenza che il timer job viene creato solo sulla macchina locale e il comando termina quando è completato tutto il processo di deploy (sincrono).
Una volta terminato, va aperto il browser per risvegliare le web application ed attendere tutta la web application riparta. Meglio navigare sulle pagine principali del sito per pre-caricarle ed evitare ritardi all'utente.Una volta che la/le web app rispondono, è possibile rimettere in linea il nodo 1, ed iniziare a mettere off-line il nodo 2. Va ripetuta la procedura anche per questo ed eventuali altri nodi/macchine della farm.In sintesi:

• Off-line nodo 1
• Attendere Off-line nodo 1
• Update con -Local sul nodo 1
• Risveglio web application sul nodo 1
• Messa in linea nodo 1
• Verifica online nodo 1
• Off-line nodo 2
• Attendere Off-line nodo 2
• Update con -Local sul nodo 2
• Risveglio web application sul nodo 2
• Messa in linea nodo 2
• Verifica online nodo 2

fine.