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:
Update-SPSolution -Identity MiaSolution.wsp -LiteralPath "$pwd\MiaSolution.wsp" -GACDeployment
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:
- 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:
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:
Update-SPSolution -Identity MiaSolution.wsp -LiteralPath "$pwd\MiaSolution.wsp" -GACDeployment -Local
Attenzione il paramentro -Local è indispensabile
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.
La procedura va fatta su ogni macchina 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.