Citrix Virtual Apps and Desktops

Database

Un sito Citrix Virtual Apps o Citrix Virtual Desktops™ utilizza tre database SQL Server:

  • Sito: (noto anche come configurazione del sito) memorizza la configurazione del sito in esecuzione, oltre allo stato della sessione corrente e le informazioni di connessione.
  • Registrazione della configurazione: (nota anche come registrazione) memorizza le informazioni sulle modifiche alla configurazione del sito e sulle attività amministrative. Questo database viene utilizzato quando la funzionalità di registrazione della configurazione è abilitata (impostazione predefinita = abilitata).
  • Monitoraggio: memorizza i dati utilizzati da Director, come le informazioni sulla sessione e sulla connessione.

Ogni Delivery Controller comunica con il database del sito. L’autenticazione di Windows è richiesta tra il Controller e i database. Un Controller può essere scollegato o spento senza influire sugli altri Controller del sito. Ciò significa, tuttavia, che il database del sito costituisce un singolo punto di errore. Se il server di database si guasta, le connessioni esistenti continuano a funzionare finché un utente non si disconnette o non si scollega. Per informazioni sul comportamento della connessione quando il database del sito diventa non disponibile, vedere Cache host locale.

Citrix consiglia di eseguire regolarmente il backup dei database in modo da poterli ripristinare dal backup in caso di guasto del server di database. La strategia di backup per ciascun database può variare. Per istruzioni, vedere CTX135207.

Se il sito contiene più di una zona, assicurarsi che la zona primaria contenga sempre il database del sito. I Controller in ogni zona comunicano con tale database.

Alta disponibilità

Esistono diverse soluzioni di alta disponibilità da considerare per garantire il failover automatico:

  • Gruppi di disponibilità AlwaysOn (inclusi i gruppi di disponibilità di base): questa soluzione di alta disponibilità e ripristino di emergenza a livello aziendale, introdotta in SQL Server 2012, consente di massimizzare la disponibilità per uno o più database. I gruppi di disponibilità AlwaysOn richiedono che le istanze di SQL Server risiedano su nodi di Windows Server Failover Clustering (WSFC). Per ulteriori informazioni, vedere Windows Server Failover Clustering with SQL Server.
  • Mirroring del database SQL Server: il mirroring del database garantisce che, in caso di perdita del server di database attivo, si verifichi un processo di failover automatico in pochi secondi, in modo che gli utenti non ne risentano. Questo metodo è più costoso di altre soluzioni perché sono necessarie licenze complete di SQL Server su ogni server di database. Non è possibile utilizzare l’edizione SQL Server Express in un ambiente con mirroring.
  • Clustering SQL: la tecnologia di clustering SQL di Microsoft può essere utilizzata per consentire automaticamente a un server di assumere i compiti e le responsabilità di un altro server che si è guastato. Tuttavia, la configurazione di questa soluzione è più complessa e il processo di failover automatico è in genere più lento rispetto ad alternative come il mirroring SQL.
  • Utilizzo delle funzionalità di alta disponibilità dell’hypervisor: con questo metodo, si distribuisce il database come macchina virtuale e si utilizzano le funzionalità di alta disponibilità dell’hypervisor. Questa soluzione è meno costosa del mirroring perché utilizza il software hypervisor esistente ed è possibile utilizzare anche l’edizione SQL Server Express. Tuttavia, il processo di failover automatico è più lento, poiché l’avvio di una nuova macchina per il database può richiedere tempo, il che potrebbe interrompere il servizio agli utenti.

La funzionalità Cache host locale integra le best practice di alta disponibilità di SQL Server. La Cache host locale consente agli utenti di connettersi e riconnettersi ad applicazioni e desktop anche quando il database del sito non è disponibile. Per ulteriori informazioni, vedere Cache host locale.

Se tutti i Controller di un sito si guastano, è possibile configurare i VDA per operare in modalità alta disponibilità, il che consente agli utenti di continuare ad accedere ai propri desktop e applicazioni. In modalità alta disponibilità, il VDA accetta connessioni ICA dirette dagli utenti, anziché connessioni mediate dal Controller. Utilizzare questa funzionalità solo nella rara occasione in cui la comunicazione con tutti i Controller fallisce. La funzionalità non è un’alternativa ad altre soluzioni di alta disponibilità. Per ulteriori informazioni, vedere CTX 127564.

L’installazione di un Controller su un nodo in un’installazione di clustering SQL o mirroring SQL non è supportata.

Installare il software del database

Per impostazione predefinita, l’edizione SQL Server Express viene installata quando si installa il primo Delivery Controller™ se non viene rilevata un’altra istanza di SQL Server su tale server. Questa azione predefinita è solitamente sufficiente per prove di concetto o distribuzioni pilota. Tuttavia, SQL Server Express non supporta le funzionalità di alta disponibilità di Microsoft.

L’installazione predefinita utilizza gli account di servizio e le autorizzazioni predefinite di Windows. Vedere la documentazione Microsoft per i dettagli su queste impostazioni predefinite, inclusa l’aggiunta di account di servizio Windows al ruolo sysadmin. Il Controller utilizza l’account Servizio di rete in questa configurazione. Il Controller non richiede ruoli o autorizzazioni aggiuntivi di SQL Server.

Se necessario, è possibile selezionare Nascondi istanza per l’istanza del database. Quando si configura l’indirizzo del database in Studio, immettere il numero di porta statico dell’istanza, anziché il suo nome. Vedere la documentazione Microsoft per i dettagli su come nascondere un’istanza di SQL Server Database Engine.

Per la maggior parte delle distribuzioni di produzione e per qualsiasi distribuzione che utilizzi le funzionalità di alta disponibilità di Microsoft, si consiglia di utilizzare solo edizioni di SQL Server non Express supportate. Installare SQL Server su macchine diverse dal server in cui è installato il primo Controller. Requisiti di sistema elenca le versioni di SQL Server supportate. I database possono risiedere su una o più macchine.

Assicurarsi che il software SQL Server sia installato prima di creare un sito. Non è necessario creare il database, ma se lo si fa, deve essere vuoto. Si consiglia anche di configurare le tecnologie di alta disponibilità di Microsoft.

Utilizzare Windows Update per mantenere SQL Server aggiornato.

Configurare i database dalla procedura guidata di creazione del sito

Specificare i nomi e gli indirizzi (posizione) dei database nella pagina Database della procedura guidata di creazione del sito. (Vedere Formati degli indirizzi di database). Per evitare potenziali errori quando Director interroga il servizio Monitor, non utilizzare spazi nel nome del database di monitoraggio.

La pagina Database offre due opzioni per la configurazione dei database: automatica e tramite script. In genere, è possibile utilizzare l’opzione automatica se Lei (l’utente di Studio e l’amministratore Citrix®) dispone dei privilegi di database richiesti. (Vedere Autorizzazioni richieste per la configurazione dei database).

È possibile modificare la posizione del database di registrazione della configurazione e di monitoraggio in seguito, dopo aver creato il sito. Vedere Modificare le posizioni dei database.

Per configurare un sito in modo che utilizzi un database mirror, completare quanto segue e quindi procedere con le procedure di configurazione automatica o tramite script.

  1. Installare il software SQL Server su due server, A e B.
  2. Sul server A, creare il database destinato a essere utilizzato come principale. Eseguire il backup del database sul server A e quindi copiarlo sul server B.
  3. Sul server B, ripristinare il file di backup.
  4. Avviare il mirroring sul server A.

Per verificare il mirroring dopo la creazione del sito, eseguire il cmdlet PowerShell get-configdbconnection per assicurarsi che il Failover Partner sia stato impostato nella stringa di connessione al mirror.

Se in seguito si aggiunge, sposta o rimuove un Delivery Controller in un ambiente di database con mirroring, vedere Delivery Controllers.

Configurazione automatica

Se si dispone dei privilegi di database richiesti, selezionare Crea e configura database da Studio nella pagina Database della procedura guidata di creazione del sito. Quindi fornire i nomi e gli indirizzi dei database principali.

Se un database esiste all’indirizzo specificato, deve essere vuoto. Se i database non esistono all’indirizzo specificato, Le verrà comunicato che un database non è stato trovato e Le verrà chiesto se desidera che il database venga creato. Quando si conferma tale azione, Studio crea automaticamente i database e quindi applica gli script di inizializzazione per i database principali e di replica.

Configurazione tramite script

Se non si dispone dei diritti di database richiesti, richiedere assistenza a chi li possiede, ad esempio un amministratore di database. Ecco la sequenza:

  1. Nella pagina Database della procedura guidata di creazione del sito, selezionare Genera script per la configurazione manuale. Questa azione genera i seguenti tre tipi di script per ciascuno dei seguenti database principali e di replica: database del sito, di monitoraggio e di registrazione.

    • Script contenente “SysAdmin” nel nome. Uno script che crea i database e l’accesso del Delivery Controller. Queste attività richiedono i diritti di securityadmin.
    • Script contenente “DbOwner” nel nome. Uno script che crea i ruoli utente nel database, aggiunge gli accessi e quindi crea gli schemi del database. Queste attività richiedono i diritti di db_owner.
    • Script contenente “Mixed” nel nome. Tutte le attività in un unico script, indipendentemente dai diritti richiesti.

    È possibile indicare dove archiviare gli script.

    Nota:

    Negli ambienti aziendali, la configurazione del database include script che potrebbero essere gestiti da team diversi con ruoli (diritti) diversi: securityadmin o db_owner. Se applicabile, si eseguono prima gli script “SysAdmin” da parte di amministratori con il ruolo securityadmin e poi gli script “DbOwner” da parte di amministratori con i diritti db_owner. Per generare tali script, è possibile utilizzare anche PowerShell. Per i dettagli, vedere Script dei diritti di database preferiti.

  2. Consegnare tali script all’amministratore del database. La procedura guidata di creazione del sito si interrompe automaticamente a questo punto. Le verrà richiesto di tornare in seguito per continuare la creazione del sito.

L’amministratore del database crea quindi i database. Ogni database deve avere le seguenti caratteristiche:

  • Utilizzare una combinazione di caratteri che termina con _CI_AS_KS. Si consiglia di utilizzare una combinazione di caratteri che termina con _100_CI_AS_KS.
  • Per prestazioni ottimali, abilitare lo snapshot Read-Committed di SQL Server. Per i dettagli, vedere CTX 137161.
  • Funzionalità di alta disponibilità configurate, se applicabile.
  • Per configurare il mirroring, impostare prima il database in modo che utilizzi il modello di recupero completo (il modello semplice è l’impostazione predefinita). Eseguire il backup del database principale in un file e copiarlo sul server mirror. Quindi, ripristinare il file di backup sul server mirror. Infine, avviare il mirroring sul server principale.

L’amministratore del database utilizza l’utilità da riga di comando SQLCMD o SQL Server Management Studio in modalità SQLCMD per:

  • Eseguire ciascuno degli script xxx_Replica.sql sulle istanze di database SQL Server ad alta disponibilità (se l’alta disponibilità è configurata)
  • Eseguire ciascuno degli script xxx\_Principal.sql sulle istanze di database SQL Server principali.

Vedere la documentazione Microsoft per i dettagli su SQLCMD.

Quando tutti gli script vengono completati con successo, l’amministratore del database fornisce all’amministratore Citrix i tre indirizzi del database principale.

Studio Le chiederà di continuare la creazione del sito. Verrà reindirizzato alla pagina Database. Immettere gli indirizzi. Se non è possibile contattare nessuno dei server che ospitano un database, viene visualizzato un messaggio di errore.

Autorizzazioni richieste per la configurazione dei database

È necessario essere un amministratore locale e un utente di dominio per creare e inizializzare i database (o modificare la posizione del database). È inoltre necessario disporre di determinate autorizzazioni di SQL Server. Le seguenti autorizzazioni possono essere configurate esplicitamente o acquisite tramite l’appartenenza a un gruppo di Active Directory. Se le credenziali dell’utente di Studio non includono queste autorizzazioni, Le verranno richieste le credenziali dell’utente di SQL Server.

Operazione Scopo Ruolo server Ruolo database
Creare un database Creare un database vuoto adatto dbcreator  
Creare uno schema Creare tutti gli schemi specifici del servizio e aggiungere il primo Controller al sito securityadmin* db_owner
Aggiungere un Controller Aggiungere un Controller (diverso dal primo) al sito securityadmin* db_owner
Aggiungere un Controller (server mirror) Aggiungere un accesso Controller al server di database attualmente nel ruolo mirror di un database con mirroring securityadmin*  
Rimuovere Controller Rimuovere il Controller dal sito ** db_owner
Aggiornare uno schema Applicare aggiornamenti dello schema o hotfix   db_owner

* Sebbene tecnicamente più restrittivo, in pratica, è possibile trattare il ruolo server securityadmin come equivalente al ruolo server sysadmin.

** Quando un Controller viene rimosso da un sito, tramite Studio o utilizzando script generati da Studio o SDK, l’accesso del Controller al server di database non viene rimosso. Questo per evitare di rimuovere potenzialmente un accesso utilizzato da servizi diversi da questo prodotto Citrix sulla stessa macchina. L’accesso deve essere rimosso manualmente se non è più necessario. Questa azione richiede l’appartenenza al ruolo server securityadmin.

Quando si utilizza Studio per eseguire queste operazioni, l’utente di Studio deve avere un account del server di database che sia esplicitamente membro dei ruoli server appropriati, oppure essere in grado di fornire le credenziali di un account che lo sia.

Script dei diritti di database preferiti

Negli ambienti aziendali, la configurazione del database include script che devono essere gestiti da team diversi con ruoli (diritti) diversi: securityadmin o db_owner.

Utilizzando PowerShell, è possibile specificare i diritti di database preferiti. La specifica di un valore non predefinito comporta la creazione di script separati. Uno script contiene attività che richiedono il ruolo securityadmin. L’altro script richiede solo i diritti db_owner e può essere eseguito da un amministratore Citrix, senza dover contattare un amministratore di database.

Nei cmdlet get-*DBSchema, l’opzione -DatabaseRights ha i seguenti valori validi:

  • SA: Genera uno script che crea i database e l’accesso del Delivery Controller. Queste attività richiedono i diritti securityadmin.
  • DBO: Genera uno script che crea i ruoli utente nel database, aggiunge gli accessi e quindi crea gli schemi del database. Queste attività richiedono i diritti db_owner.
  • Mixed: (Predefinito) Tutte le attività in un unico script, indipendentemente dai diritti richiesti.

Per ulteriori informazioni, vedere la guida del cmdlet.

Formati degli indirizzi di database

È possibile specificare un indirizzo di database in una delle seguenti forme:

  • ServerName
  • ServerName\InstanceName
  • ServerName,PortNumber

Per un gruppo di disponibilità AlwaysOn, specificare il listener del gruppo nel campo della posizione.

Modificare le posizioni dei database

Dopo aver creato un sito, è possibile modificare la posizione dei database di registrazione della configurazione e di monitoraggio. (Non è possibile modificare la posizione del database del sito). Quando si modifica la posizione di un database:

  • I dati del database precedente non vengono importati nel nuovo database.
  • I log non possono essere aggregati da entrambi i database durante il recupero dei log.
  • La prima voce di log nel nuovo database indica che si è verificata una modifica del database, ma non identifica il database precedente.

Non è possibile modificare la posizione del database di registrazione della configurazione quando la registrazione obbligatoria è abilitata.

Per modificare la posizione di un database:

  1. Assicurarsi che una versione supportata di Microsoft SQL Server sia installata sul server in cui si desidera che risieda il database. Configurare le funzionalità di alta disponibilità secondo necessità.
  2. Selezionare Configurazione nel riquadro di navigazione di Studio.
  3. Selezionare il database per il quale si desidera specificare una nuova posizione e quindi selezionare Modifica database nel riquadro Azioni.
  4. Specificare la nuova posizione e il nome del database.
  5. Se si desidera che Studio crei il database e si dispone delle autorizzazioni appropriate, fare clic su OK. Quando richiesto, fare clic su OK, quindi Studio crea automaticamente il database. Studio tenta di accedere al database utilizzando le Sue credenziali. Se l’operazione fallisce, Le verranno richieste le credenziali dell’utente del database. Studio carica quindi lo schema del database nel database. Le credenziali vengono mantenute solo per il periodo di tempo di creazione del database.
  6. Se non si desidera che Studio crei il database, o non si dispone di autorizzazioni sufficienti, fare clic su Genera script. Gli script generati includono istruzioni per la creazione manuale del database e di un database mirror, se necessario. Prima di caricare lo schema, assicurarsi che il database sia vuoto e che almeno un utente abbia l’autorizzazione ad accedere e modificare il database.

Ulteriori informazioni

Database