Citrix Virtual Apps and Desktops

Database

Nota:

È possibile gestire la distribuzione di Citrix Virtual Apps and Desktops™ utilizzando due console di gestione: Web Studio (basata sul Web) e Citrix Studio (basata su Windows). Questo articolo tratta solo Web Studio. Per informazioni su Citrix Studio, consultare l’articolo equivalente in Citrix Virtual Apps and Desktops 7 2212 o versioni precedenti.

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: (nota anche come Registrazione configurazione) 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. È richiesta l’autenticazione Windows tra il Controller e i database. Un Controller può essere scollegato o spento senza influire sugli altri Controller nel 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 si scollega. Per informazioni sul comportamento della connessione quando il database del sito diventa non disponibile, consultare Cache host locale.

Citrix consiglia quanto segue per quanto riguarda i database:

  • Eseguire backup regolarmente. Eseguire il backup dei database regolarmente in modo da poterli ripristinare dal backup in caso di guasto del server di database. La strategia di backup per ciascun database può differire. Per maggiori informazioni, consultare CTX135207; si noti, tuttavia, che si riferisce a CitrixXenDesktopDB, che non è più supportato o disponibile per i clienti.

  • Eseguire regolarmente il backup e il ripristino dei database SQL Server di Sito, Monitoraggio e Registrazione. Per informazioni specifiche sui database SQL Server, consultare Creazione di backup completi e differenziali di un database SQL Server.

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 maggiori informazioni, consultare 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 siano generalmente interessati. Questo metodo è più costoso di altre soluzioni perché sono richieste 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 ha avuto un guasto. Tuttavia, la configurazione di questa soluzione è più complessa e il processo di failover automatico è tipicamente 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 maggiori informazioni, consultare Cache host locale.

Se tutti i Controller in 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 maggiori informazioni, consultare 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. Consultare 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 SQL Server aggiuntivi.

Se necessario, è possibile selezionare Nascondi istanza per l’istanza del database. Quando si configura l’indirizzo del database in Web Studio, immettere il numero di porta statico dell’istanza, anziché il suo nome. Consultare 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) del database nella pagina Database della procedura guidata di creazione del sito. (Vedere Formati degli indirizzi del 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 generale, è possibile utilizzare l’opzione automatica se Lei (l’utente di Web 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, consultare Delivery Controller.

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, si viene informati che un database non può essere trovato e quindi viene chiesto se si desidera che il database venga creato. Quando si conferma tale azione, Web 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 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 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 diritti db_owner. Per generare tali script, è possibile utilizzare anche PowerShell. Per i dettagli, consultare Script per i 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. Verrà richiesto di continuare la creazione del sito quando si tornerà in seguito.

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

  • Utilizzare una regole di confronto che termina con _CI_AS_KS. Si consiglia di utilizzare una regole di confronto che termina con _100_CI_AS_KS.
  • Per prestazioni ottimali, abilitare lo snapshot Read-Committed di SQL Server. Per i dettagli, consultare 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 del database SQL Server ad alta disponibilità (se l’alta disponibilità è configurata)
  • Eseguire ciascuno degli script xxx\_Principal.sql sulle istanze del database SQL Server principali.

Consultare 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.

Web Studio Le chiederà di continuare la creazione del sito. Verrà reindirizzato alla pagina Database. Inserire 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 SQL Server. Le seguenti autorizzazioni possono essere configurate esplicitamente o acquisite tramite l’appartenenza a un gruppo di Active Directory. Se le credenziali utente di Web Studio non includono queste autorizzazioni, Le verranno richieste le credenziali 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, 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ù richiesto. Questa azione richiede l’appartenenza al ruolo server securityadmin.

Quando si utilizza Web Studio per eseguire queste operazioni, l’utente di Web 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 per i 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 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 diritti db_owner.
  • Mixed: (Predefinito) Tutte le attività in un unico script, indipendentemente dai diritti richiesti.

Per maggiori informazioni, consultare la guida del cmdlet.

Formati degli indirizzi del 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 nel 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. Accedere a Web Studio e quindi selezionare Impostazioni nel riquadro sinistro.
  3. Individuare il riquadro Database e selezionare Modifica.
  4. Nella pagina Gestisci database, selezionare il database per il quale si desidera specificare una nuova posizione e quindi selezionare Cambia database nella barra delle azioni.
  5. Specificare la nuova posizione e il nome del database.
  6. Se si desidera che Web Studio crei il database e si dispone delle autorizzazioni appropriate, fare clic su Fine. Quando richiesto, fare clic su Fine, quindi Web Studio crea automaticamente il database. Web Studio tenta di accedere al database utilizzando le Sue credenziali. Se ciò fallisce, Le verranno richieste le credenziali dell’utente del database. Web Studio carica quindi lo schema del database nel database. Le credenziali vengono mantenute solo per il periodo di creazione del database.
  7. Se non si desidera che Web Studio crei il database, o non si dispone di autorizzazioni sufficienti, fare clic su Genera script database. 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 per accedere e modificare il database.

Ulteriori informazioni

Database