Condividi tramite

Passaggi per l'applicazione di patch senza tempo di inattività di SharePoint Server

  • Articolo

SI APPLICA A:no-img-132013 yes-img-162016 yes-img-192019 yes-img-seSubscription Edition no-img-sopSharePoint in Microsoft 365

L'applicazione di patch zero in tempo di inattività (ZDP) è disponibile in SharePoint Server 2016, SharePoint Server 2019 e SharePoint Server Subscription Edition. Consentire agli utenti di continuare a lavorare, salvare e cercare documenti durante la patch della farm di SharePoint Server.

L'applicazione di patch senza tempi di inattività è un metodo di applicazione di patch e aggiornamento sviluppato in SharePoint in Microsoft 365. Ha lo scopo di consentire agli amministratori di applicare patch al servizio durante l'utilizzo delle sottoscrizioni da parte degli utenti. In altre parole, questo metodo sottoposto a test è progettato per consentire l'applicazione di patch mentre gli utenti lavorano attivamente su file ed eseguono ricerche per indicizzazione, e per consentire il rendering dei risultati nella farm di SharePoint Server. Questo è ciò che si intende per ''zero tempi di inattività''.

È necessario tenere presente alcuni elementi quando si parla di ZDP, che verranno illustrati più avanti in questo articolo.

È importante ricordare che l'obiettivo di ZDP è il tempo di attività per gli utenti, pertanto, in questo articolo, tutte le decisioni relative all'applicazione di patch e il riavvio della farm saranno prese tenendo presente tale disposizione.

Importante

Anche se tutti i server della farm di SharePoint Server sono stati configurati per l'uso del ruolo "Personalizzato", è comunque possibile configurare manualmente una farm a disponibilità elevata. Sono disponibili articoli che consentono di costruire farm a disponibilità elevata e i principi di tolleranza di errore (con hardware ridondante) e disponibilità elevata (con sistemi e software in atto per supportare il failover e la continuazione del tempo di attività) sono gli stessi. Tenere presente che nelle farm altamente disponibili o personalizzate più complesse, è necessario prestare particolare attenzione per applicare patch ai server di ricerca in modo che sia supporta la disponibilità elevata, ad esempio, applicando patch a una replica dell’indice alla volta e mai applicando patch o aggiornando le repliche dell’indice dalla stessa partizione nello stesso momento.

Processo ZDP

Questo esempio usa ZDP per una configurazione della farm di SharePoint Server usando MinRole. L'ambiente di esempio è analogo al seguente:

The environment for this article has 8 servers: 4 required server roles in column 1 (SPWeb01, SPApp01, SPDch01, SPSrch01) and 4 redundant server roles in column 2 (SPWeb02, SPApp02, SPDch02, SPSrch02).

Per suddividere questa struttura, due front-end Web (WFE) (SPWeb01 e 02) sono connessi a un servizio di bilanciamento del carico, entrambi stanno eseguendo richieste di campo a questo punto. Sono disponibili due server applicazioni (SPApp01 e 02), due server cache distribuita (SPDCH01 e 02) e due server di ricerca (SPSRCH01 e 02). Dietro questa struttura, ma non inclusa direttamente nel processo ZDP, c'è un cluster di SQL Server, ad esempio SQL Server Always-On.

Idealmente, è possibile disegnare una linea in mezzo alla farm in questo diagramma, dall'alto verso il basso. Su un lato della linea vi sono tutti i server che terminano con "01" (colonna 1), mentre i server ridondanti che terminano con "02" si trovano sull'altro lato (colonna 2). Questa costruzione doppia verrà utilizzata per mantenere attiva la farm per gli utenti durante l'applicazione di patch.

Nella maggior parte dei casi, tutte le operazioni eseguite su un lato della linea (per i server 01) vengono ripetute esattamente per 02. Di tutti i passaggi relativi al processo ZDP in due fasi, relativamente semplice, quelli creati con WFE (SPWeb01 e 02) sono i più complessi. Verranno analizzati per primi questi passaggi.

Nota

Informazioni generali sugli aggiornamenti software per SharePoint Server sono disponibili qui. Si noti che l'articolo è collegato alla documentazione sulle impostazioni delle autorizzazioni per SharePoint Server. Rivedere gli articoli in base alle esigenze e tenere presente che parte del processo di applicazione di patch riguarda gli aggiornamenti del database. Se le autorizzazioni di SharePoint per gli account SQL Server sono state modificate dopo l'installazione, ad esempio, sarà necessario leggere questi articoli.

Assicurarsi di aver riavviato e testato i WFE prima di eliminare il bilanciamento del carico, per evitare situazioni in cui il WFE, cui applicare patch per primo, venga rimosso dalla rotazione e altri WFE non gestiscano il carico di lavoro risultante. Tutti i server della farm dovrebbero essere aggiornati da un riavvio e integri prima dell'applicazione di patch. Considerare, inoltre, di interrompere le ricerche per indicizzazione e le importazioni profilo durante la finestra di aggiornamento o patch.

Importante

L'esecuzione affiancata assicura che tutti i WFE della farm forniscano lo stesso contenuto statico durante l'aggiornamento, anche se i file statici di un determinato WFE vengono aggiornati o deprecati. Side-by-side è integrato in PSCONFIG, ma deve essere abilitato. Questa funzionalità verifica che gli utenti abbiano la stessa esperienza dei siti durante l'esplorazione di SharePoint e l'uso dei propri file, anche se i file del file system vengono modificati e aggiornati.

Per abilitare la funzionalità side-by-side, eseguire lo script di PowerShell seguente una volta usando l'URL per una delle applicazioni Web di contenuto:

$webapp = Get-SPWebApplication <webappURL>
$webapp.WebService.EnableSideBySide = $true
$webapp.WebService.update()

A partire da KB3178672 (aggiornamento di marzo 2017) per SharePoint Server 2016 e versioni successive, PSCONFIG copia automaticamente tutti i file di .js, .css e .htm all'interno della 16-HIVE\TEMPLATE\LAYOUTS cartella nella cartella16-HIVE\TEMPLATE\LAYOUTS\<NEW BUILD NUMBER>, per poter passare ai nuovi file dell'interfaccia utente e completare il processo side-by-side come descritto più avanti in questo argomento in Fase 2 - Aggiornamento PSCONFIG (4).

Fase 1 - Installazione delle patch

La prima fase consiste nell’ottenere i file binari delle patch e installarli nei server.

  1. Step 1 in the ZDP process is show in a graphic.

    Eliminare il primo WFE (SPWeb01) dal bilanciamento del carico e applicarvi la patch con i pacchetti 'STS' e 'WSS'.
    Riavviare il server al termine dell'applicazione della patch.
    Restituire il server per la rotazione nel bilanciamento del carico.

  2. Step 2 in ZDP process.

    Eliminare il secondo WFE (SPWeb02) dal bilanciamento del carico e applicarvi la patch con i pacchetti 'STS' e 'WSS'.
    Riavviare il server al termine dell'applicazione della patch.
    Lasciare il server all'esterno della rotazione nel bilanciamento del carico fino al completamento dell'intero aggiornamento.

    Nota

    [!NOTA] Se non si esegue l'aggiornamento in una finestra di manutenzione e la farm ha un carico eccessivo, è possibile restituire il WFE al bilanciamento del carico di rete finché non si è pronti per eseguire PSCONFIG.

  3. Step 3 in the ZDP process is shown in a graphic.

    Per ogni SPApp SPDCH e SPSRCH nella colonna 1, applicare la patch con pacchetti STS' e 'WSS''.
    Riavviarli al termine dell'operazione. (Il lavoro proveniente da SPWeb01 sarà compreso nei server della colonna 2).

  4. Step 4 in the ZDP process is shown in this graphic.

    A questo punto, ripetere l'operazione di 'applicazione patch e riavvio' per la colonna 2. Per ogni SPApp02, SPDCH02 e SPSRCH02 nella colonna 2, applicare la patch con pacchetti STS' e 'WSS''.
    Riavviarli al termine dell'operazione. (Come mostrato in figura, il lavoro proveniente da SPWeb01, a questo punto, sarà compreso nei server della colonna 1).

Fase 2 - Aggiornamento PSCONFIG

In ogni nodo della farm di SharePoint Server sono installate le patch e tutte sono state riavviate. È ora possibile eseguire l'aggiornamento da build a build.

Nota

[!NOTA] Durante il processo ZDP, è possibile eseguire Upgrade-SPContentdatabase per ridurre il tempo complessivo necessario per completare l'esecuzione di PSCONFIG. Aspetto da considerare se si dispone di un numero elevato di database o si selezionano database di grandi dimensioni.

  1. Il passaggio 5 del processo ZDP viene visualizzato in un grafico.

    Tornare a WFE che non ha una rotazione con carico bilanciato (SPWeb02), aprire SharePoint Management Shell ed eseguire questo comando PSCONFIG:

    PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install

    Al termine, il comando restituisce questo WFE (SPWeb02) al bilanciamento del carico. Al server è stata applicata la patch ed è completamente aggiornato.

    Consiglio

    L'ultima fase del processo PSCONFIG assicura che gli aggiornamenti all'interfaccia utente (UI) vengano copiati dalla cartella /layouts in una cartella specifica della versione. Questo fa parte dell’aggiornamento dell'interfaccia utente affiancato che consente agli utenti che esplorano la farm di utilizzare l'interfaccia utente finché non viene completato l'aggiornamento ed è possibile passare alla nuova interfaccia.
    Per essere certi che la copia affiancata sia stata completata, controllare il logfile associato. Per impostazione predefinita, si trova in:
    C:\programmi\file comuni\Microsoft shared\web server extensions\16\logs. (La lettera di unità radice può variare).
    Se, per qualche motivo, PSCONFIG non ha copiato correttamente i file dell'interfaccia utente, eseguire questo comando per copiarli manualmente Copy-SidebySideFiles.

  2. Step 6 in the ZDP process is shown in this graphic.

    Rimuovere SPWeb01 dal bilanciamento del carico. > Aprire SharePoint Management Shell ed eseguire lo stesso comando PSCONFIG:

    PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install

    Restituire il WEF (SPWeb01) al bilanciamento del carico. A questo punto, è stata applicata la patch ed è completamente aggiornato.

    A entrambi i WFE sono state applicate le patch e sono aggiornati. Passare al resto della farm, verificando che i comandi necessari di Microsoft PowerShell vengano eseguiti su un server alla volta e non parallelamente. Ciò significa che, per tutta la colonna 1, si eseguiranno i comandi su un server alla volta. Quindi questi verranno eseguiti, su un server alla volta, per i server nella colonna 2 senza sovrapposizioni. L'obiettivo finale è il preservamento del tempo di attività. L'esecuzione dei comandi PSCONFIG in serie è il mezzo più prevedibile e più sicuro per completare il processo ZDP, pertanto è quello che verrà utilizzato.

  3. Step 7 in the ZDP process is shown in this graphic.

    Per tutti i server rimanenti nella colonna 1 (SPApp01, SPDCH01, SPSRCH01), eseguire lo stesso comando PSCONFIG in SharePoint Management Shell. Eseguire questa operazione su ogni server, uno alla volta, finché non vengono aggiornati tutti i server della colonna 1.

    Importante

    [!IMPORTANTE] Ricordarsi di rimuovere la cache distribuita prima di eseguire PSCONFIG e di aggiungerla nuovamente al server al completamento dell'operazione.

    PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install

  4. Step 8 in the ZDP process is shown in this graphic.

    Per tutti i server rimanenti nella colonna 2 (SPApp02, SPDCH02, SPSRCH02), eseguire lo stesso comando PSCONFIG in SharePoint Management Shell. Eseguire questa operazione su ogni server, uno alla volta, finché non vengono aggiornati tutti i server della colonna 2.

    Importante

    [!IMPORTANTE] Ricordarsi di rimuovere la cache distribuita prima di eseguire PSCONFIG e di aggiungerla nuovamente al server al completamento dell'operazione.

    PSCONFIG.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures -cmd secureresources -cmd services -install

    Importante

    Dopo che tutti i server hanno eseguito correttamente PSCONFIG, ricordare di eseguire il comando SharePoint Management Shell seguente per passare ai nuovi file dell'interfaccia utente e completare il processo side-by-side:
    $webapp = Get-SPWebApplication <webappURL> $webapp.WebService.SideBySideToken = <current build number in quotes, ex: "16.0.4338.1000">
    $webapp.WebService.update()

A questo punto l'operazione è finita e la farm è stata aggiornata completamente mentre è in uso e senza tempi di inattività.

Perché MinRole può essere utile?

Quando si parla di ZDP si dovrebbe parlare anche del concetto di MinRole. MinRole è un'opzione nell'installazione di SharePoint Server 2016, SharePoint Server 2019 e SharePoint Server Subscription Edition. Suddivide la configurazione di una farm in ruoli come Front-End (WFE), Server applicazioni (App), Cache distribuita (DCache), Ricerca o Personalizzata (per i prodotti di terze parti o di codici personalizzati). Questa configurazione fornirà di media quattro server (due WFE, due server App, due server DCache e due server di ricerca).

Per impostazione predefinita, vengono modificati i WFE per bassa latenza e i server App per alta velocità. Analogamente, vengono aggregati i componenti di ricerca, in modo che le chiamate non debbano lasciare la casella in cui sono state create, consentendo ai server di ricerca di lavorare in modo più efficiente. Uno dei principali vantaggi di MinRole consiste nella tolleranza di errore generata.

Perché è necessario disporre di disponibilità elevata?

La disponibilità elevata è un argomento ampiamente trattato in SharePoint. Sono disponibili interi white paper e articoli online, ad esempio questa documentazione. Per semplificare il concetto, almeno per questo articolo, tenere presente che ZDP (e anche MinRole) ha avuto origine in SharePoint in Microsoft 365. In SharePoint in Microsoft 365 i server virtualizzati dispongono di ridondanze predefinite, in modo che due dello stesso ruolo del server della stessa farm di SharePoint non risiederanno nello stesso host o rack. In questo modo SharePoint è più a tolleranza di errore. È possibile ottenere la stessa situazione, disponendo di due elementi di ciascun ruolo di SharePoint Server su host separati su diversi rack nel proprio datacenter, con un router condiviso o collegando i rack per una comunicazione più veloce. È inoltre sufficiente che due server fisici per ogni ruolo di SharePoint Server siano configurati in un ambiente di testing (scegliendo barre di alimentazione separate per ciascuna metà della farm e assicurandosi che il routing tra il set di server sia veloce e, se possibile, che consenta di ignorare il traffico di rete più ampio per una minore latenza).

In questa fase, gli obiettivi sono alta disponibilità e tolleranza di errore. Questo significa che le attività più importanti sono separare i ruoli in rack o server, assicurandosi di avere due elementi di ogni ruolo, di facilitare il traffico di rete veloce tra questi due livelli e assicurandosi che la configurazione disponga di sistemi sul posto per il monitoraggio e l'esecuzione automatica del server di database di failover. In termini di servizi di installazione manuale in SharePoint (come quando si sceglie il ruolo personalizzato), è importante che i servizi abbiano ridondanza nella farm. Ad esempio, la cache distribuita è raggruppata, la farm dispone di più WFE, vengono configurati i server di ricerca e dell'applicazione in coppie. In questo modo, nel caso in cui un server presenti un problema grave, l'altro può gestire il carico dell'utente.

Negli esempi qui utilizzati, l'argomento server fisici è stato ampiamente trattato per semplificare i concetti. Quando arriva il momento di pianificare ZDP, è necessario disegnare il proprio ambiente, ovunque si trovi (completo di nomi/numeri di rack e nomi di server in cui è possibile trovare ogni ruolo di SharePoint Server). Si tratta di uno dei modi più rapidi per individuare eventuali violazioni degli obiettivi di tolleranza di errore e ridondanza dei ruoli che potrebbero essersi introdotti nella configurazione, a prescindere dalla sua dimensione.

Video dimostrativo su Zero Downtime Patching in SharePoint Server 2016