> For the complete documentation index, see [llms.txt](https://docs.devolutions.net/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.devolutions.net/powershell-universal/it/config/hosting/high-availability.md).

# Alta disponibilità

PowerShell Universal può essere configurato per l'alta disponibilità ("HA") utilizzando una combinazione di persistenza su SQL Server e un bilanciatore di carico per garantire che sia gli strumenti front-end, come le dashboard, siano accessibili, sia gli strumenti back-end, come i job, continuino a funzionare.

![](/files/TKbV36lDMrzPmo3MnKXN)

## Configurazione della persistenza

Le consigliamo di sfruttare la [persistenza SQL](/powershell-universal/it/config/persistence.md#sql) (o PostgreSQL) per garantire che tutti i nodi del cluster condividano gli stessi dati per quanto riguarda le code di job, i token app e le identità all'interno del sistema. Ogni nodo dovrebbe essere configurato con la stessa stringa di connessione a SQL Server.

Man mano che i job vengono eseguiti, gli utenti effettuano l'accesso e vengono creati i token app, SQL Server verrà utilizzato per memorizzare queste informazioni, che saranno condivise tra i nodi.

## Configurazione del controllo del codice sorgente

Le consigliamo di utilizzare la [sincronizzazione git](/powershell-universal/it/config/git.md) per archiviare e controllare le versioni degli script di configurazione PowerShell utilizzati per gestire i nodi di PowerShell Universal. Può essere preferibile la sincronizzazione git unidirezionale, poiché i nodi saranno in sola lettura ed estrarranno le configurazioni dopo che sono state unite nel suo ramo di produzione. Ogni nodo estrae i file di configurazione a un intervallo configurabile (per impostazione predefinita 1 minuto). È preferibile memorizzare le impostazioni di configurazione git nel database, in quanto richiede meno configurazione per nodo.

## Bilanciamento del carico

PowerShell Universal supporta l'uso di bilanciatori di carico come F5 e nginx. Ci sono alcuni requisiti che devono essere soddisfatti quando si utilizzano i bilanciatori di carico.

* Le sessioni persistenti (sticky) sono richieste dalla console di amministrazione e dalle app
* Il supporto dei web socket è richiesto dalla console di amministrazione e dalle app

Per facilitare il bilanciamento del carico, può utilizzare l'endpoint `/api/v1/status` per i suoi nodi. L'endpoint restituirà codici di stato basati sullo stato corrente del nodo. `200` significa che il nodo è online e pronto a ricevere richieste. I server in esecuzione in modalità di manutenzione restituiranno `503`. I server che non sono riusciti ad avviarsi a causa di un errore di configurazione restituiranno `500`. Anche i server con app che non sono riuscite ad avviarsi restituiranno `500`.

## API di stato

### `/api/v1/status`

Può impostare i suoi nodi in modalità di manutenzione facendo clic su Piattaforma \ Computer e selezionando l'opzione modalità di manutenzione. Una volta abilitata la modalità di manutenzione, l'endpoint `/api/v1/status` inizierà a restituire `503`. Questo dovrebbe essere configurato per disabilitare l'instradamento del traffico verso il nodo mentre viene eseguita la manutenzione. Questo endpoint restituirà anche 5xx se quanto segue è vero:

* Il computer è in uno stato di errore di avvio
* Il computer è in modalità di manutenzione
* Un'app critica è in stato di avvio non riuscito
* Gli endpoint API sono configurati ma non funzionano correttamente

### `/api/v2/status`

L'API di stato v2 restituirà un `503` per motivi aggiuntivi. Tra questi:

* Un computer qualsiasi del cluster è offline ma non in modalità di manutenzione
* La sincronizzazione git non riesce a estrarre le modifiche su un nodo qualsiasi
* Gli endpoint API sono configurati ma non funzionano correttamente

## Limitazioni

Attualmente esistono alcune limitazioni per i cluster PowerShell Universal ad alta disponibilità.

### Caching multi-nodo

La memorizzazione nella cache eseguita tramite `$Cache` è limitata a un singolo processo su un singolo nodo. Ad esempio, ogni app in esecuzione al di fuori dell'ambiente integrato avrà la propria cache.

`Set-PSUCache` non condividerà i dati tra i nodi se `-Persist` non è specificato. Per garantire che tutti i nodi abbiano gli stessi dati, includa questo switch.

### Broadcast delle app multi-nodo

I messaggi di broadcast delle app multi-nodo non sono attualmente supportati. L'utilizzo di cmdlet come `Show-UDToast -Broadcast` farà sì che un modale toast venga mostrato a tutti gli utenti connessi del nodo corrente, ma non verrà trasmesso alle app su tutti i nodi.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.devolutions.net/powershell-universal/it/config/hosting/high-availability.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
