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.
HTTP Error 503. The service is unavailable.
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:
il parametro GACDeployment serve solo nel caso la solution contiene delle DLL da caricare in GAC
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:Farm bilanciata (configurazione minima)Il bilanciatore di carico può essere ad esempio:
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:Farm con il traffico su un solo nodo e l'altro off-linea questo punto tutto il traffico è sul nodo 2, quindi possiamo aggiornare il nodo 1.
La messa off-line di un nodo, in base al tipo di bilanciatore usato e al carico della farm, può richiedere un tempo più o meno lungo.
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.
Per poter richiamare la web application dalla macchina locale è necessario registrare la url nel file c:\windows\system32\drivers\etc\host associato all'IP locale
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.
