• Guide, Sistemi Operativi
• 26 Febbraio 2021

Il Remote Desktop Connection Broker  è il server che nell’infrastruttura di Remote Desktop Services di Windows Server si occupa di gestire le connessioni verso i Session Host e verso le RemoteApp. Il ruolo di RD Connection Broker è un ruolo vitale della vostra infrastruttura e rappresenta il cervello che si occupa di distribuire le nuove connessioni oppure effettuare le riconnessioni in caso di perdita di connettività.

Abbiamo già visto nella guida Configurare l’alta disponibilità dei Remote Desktop Services in Windows Server 2016 e Windows Server 2019 – ICT Power che l’alta disponibilità dei Remote Desktop Services in Windows Server viene stabilita attraverso la duplicazione di ognuno dei ruoli di infrastruttura Desktop remoto.

In questa guida mostrerò come mettere in alta disponibilità il ruolo di Remote Desktop Connection Broker di una Farm RDS pensata per il Session-based deployment. Utilizzerò Windows Server 2019, ma le stesse operazioni sono valide anche per Windows Server 2016.

In particolar modo il ruolo RD Connection Broker utilizzerà un database reso altamente disponibile grazie ai SQL Server Always On Availability Groups.

Nella figura sotto sono mostrati i nomi dei server che utilizzerò per il mio deployment.

Figura 1: Schema di funzionamento dell’infraastruttura

Questa guida esula dalla creazione di un RDS Session-based deployment. Nell’articolo Configurare le RemoteApp con i Remote Desktop Services di Windows Server 2016 e Windows Server 2019 – ICT Power potete trovare tutti gli steps per mettere in piedi un RDS Session-based deployment e come configurare le RemoteApp.

Ho provveduto a creare un gruppo di computer in Active Directory nel quale ho inserito le due macchine su cui installerò il ruolo di RD Connection Broker. questo gruppo mi servirà più avanti per poter accedere al database condiviso che verrà utilizzato dai due . Ho chiamato il gruppo RDS_Broker e ho aggiunto le due macchine NIC-RDCB3 e NIC-RDCB3

Figura 2: Gruppo RDS_Broker con le due macchine che hanno il ruolo di Connection Broker

Nel DNS ho anche creato il nome NIC-RDS che risolve in Round Robin i nomi dei due RD Connection Broker. Il nome verrà utilizzato più tardi quando metterò in alta disponibilità il ruolo di Connection Broker.

Figura 3: Creazione nel DNS dei record per la risoluzione degli indirizzi IP dei due Connection Broker

Creazione del SQL Server Always On Availability Group

La funzionalità Always On di SQL Server è una soluzione di disponibilità elevata e recupero di emergenza che supporta fino a 9 repliche del database senza che sia necessario avere dei dischi condivisi tra i diversi database server. La funzionalità è disponibile sia in SQL Standard (con la limitazione ad un unico database) che in SQL Enterprise.

In questa guida utilizzerò SQL Server 2019, installato su due database server chiamati NIC-SQL1 e NIC-SQL2. IN realtà è possibile utilizzare anche SQL Server 2016 / 2017.

Dopo aver installato SQL Server 2019 su entrambi i server è necessario abilitare la funzionalità di Windows Failover Cluster per poter successivamente abilitare l’Always On Availability Group.

Aggiungete la funzionalità di Failover Clustering a tutti i SQL Server utilizzando il Server Manager oppure utilizzando PowerShell:

Prima di iniziare a configurare il cluster, verificate i prerequisiti seguenti:

• Assicuratevi che tutti i server da aggiungere come nodi del cluster eseguano la stessa versione di Windows Server.
• Esaminate i requisiti hardware per assicurarvi che la configurazione in uso sia supportata. Per altre informazioni seguite la guida Requisiti hardware per il clustering di failover e opzioni di archiviazione.
• Assicuratevi che tutti i server da aggiungere come nodi del cluster siano aggiunti allo stesso dominio Active Directory.
• Assicuratevi che l’account da usare per la creazione del cluster sia un utente di dominio che dispone di diritti di amministratore su tutti i server da aggiungere come nodi del cluster.

Figura 4: Installazione della funzionalità di Failover Cluster sul primo server SQL

Figura 5: Installazione della funzionalità di Failover Cluster sul secondo server SQL

La creazione di un Failover Cluster richiede l’esecuzione delle seguenti attività:

• Verificare i prerequisiti
• Installare la funzionalità Clustering di failover in tutti i server da aggiungere come nodi del cluster
• Eseguire la convalida guidata del cluster per la verifica della configurazione
• Eseguire la Creazione guidata cluster per creare il cluster di failover

Terminata l’installazione della funzionalità, utilizzate la console del Failover Cluster Manager per testare la configurazione dei due nodi e per creare il nuovo cluster. Vi consiglio di verificare i prerequisiti elencati alla pagina Creare un cluster di failover

Lanciate quindi il wizard per la validazione del cluster, in modo tale da essere sicuri che tutti i prerequisiti siano stati rispettati.

Figura 6: Wizard di validazione dei nodi del cluster. Scelta dei nodi

Figura 7: Esecuzione di oltre 120 controlli durante il wizard di validazione dei nodi del cluster

Terminata la validazione potete creare il nuovo cluster. Cliccate su Create the cluster now using the validates nodes e seguite il wizard di creazione. Indicate il nome del cluster (nel mio caso NIC-SQLCluster) e l’indirizzo IP da assegnargli, come mostrato nelle figure sotto.

Figura 8: Indicazione del nome e dell’indirizzo IP del cluster

Figura 9: Creazione del cluster in corso

Figura 10: Creazione del cluster completata con successo

Poiché si tratta di un cluster a due nodi ho deciso di modificare la modalità di quorum, che di default è Node Majority. Cliccando col tasto destro sul nome del cluster, scegliete More Actions > Configure Cluster Quorum Settings… e decidete di utilizzare una cartella condivisa in rete, come mostrato nelle figure sotto:

Figura 11: Modifica della modalità di quorum del Cluster SQL

Figura 12: Selezione del witness

Figura 13: Scelta del file share witness

Figura 14: File share da utilizzare per conservare i dati del quorum witness

Figura 15: Modifica della modalità di quorum completata con successo

Figura 16: Il cluster è configurato per utilizzare un File Share Witness

Abilitazione della funzionalità di SQL Server Always On Availability Group

Per abilitare la funzionalità di SQL Server Always On Availability Group è necessario configurare tutte le istanze di SQL server che saranno configurate come repliche nell’Availability Group. Su ognuno dei nodi SQL, dal SQL Server Configuration Manager cliccate due volte sul servizio SQL Server (MSSQLSERVER) e dalla scheda Always On Availability Groups mettete il segno di spunta per abilitare la funzionalità di Always On Availability Groups, come mostrato nella figura sotto.

Figura 17: Abilitazione della funzionalità di Always On Availability Groups

Confermate con OK e provvedete al riavvio del servizio SQL Server (MSSQLSERVER), come richiesto.

Figura 18: Riavvio del servizio SQL Server (MSSQLSERVER)

Creazione del database che verrà utilizzato dall’RD Connection Broker

È necessario che i diversi RD Connection Broker scrivano in un database SQL condiviso, che potrebbe essere un SQL Server locale oppure un database SQL di Azure.

Come prima operazione create sul primo server SQL, dal SQL Management Studio, una nuova login e aggiungete il gruppo degli RDS-Broker che avete creato in precedenza in Active Directory. Nella figura sotto sono mostrati tutti i passaggi necessari. Grazie a questa login i due RD Connection Broker saranno capaci di gestire il database dove verranno conservate tutte le informazioni e le configurazioni.

Figura 19: Creazione della login per l’accesso del gruppo degli RD Connection Broker

Assegnate alla login che state creando il ruolo di dbcreator

Figura 20: Assegnazione del ruolo di dbcreator alla login che permetterà l’accesso dei due RD Connection Broker

Procedete quindi alla creazione di un nuovo database, lasciando le configurazioni di default. Io l’ho chiamato RDSHA.

Figura 21: Creazione di un nuovo database

Dopo aver creato il database, modificate le proprietà della login che avete creato in precedenza e dal nodo User Mapping, selezionate il segno di spunta vicino al database creato (nel mio caso RDSHA) e selezionate la casella db owner, come mostrato nella figura sotto:

Figura 22: Assegnazione del ruolo di db owner alla login utilizzata dai due RD Connection Broker

Creazione e configurazione del SQL Server Always On Availability Group

Per creare un SQL Server Always On Availability Group aprite il SQL Server Management Studio e collegatevi all’istanza SQL Server dove avete creato il database. Espandete il nodo Always On High Availability e cliccando col tasto destro sulla cartella Availability Groups fate partire il wizard New Availability Group Wizard…

Figura 23: New Availability Group Wizard…

Figura 24: Avvio del New Availability Group Wizard…

Figura 25: Inserimento del nome dell’Availability Group

Nella schermata di scelta del database mettete un segno di spunta accanto al dataBase da aggiungere all’Availability Group. Nel mio caso ho ricevuto un errore: non era stato ancora effettuato un full backup del DB.

Figura 26: Errore riferito al database selezionato: è necessario effettuare prima un full backup

Per effettuare il Full Backup del database potete Cliccare col tasto destro sul DB e scegliere Tasks > Back Up…

Figura 27: Task di Backup del database

Figura 28: Scelta delle impostazioni e della destinazione del backup del database

Ritornando nel wizard per la creazione del nuovo Availability Group basterà cliccare su Refresh per verificare che adesso il database soddisfa tutti i prerequisiti. Mettete un segno di spunta accanto al nome del database e proseguite nel wizard.

Figura 29: Il database soddisfa tutti i prerequisiti. Adesso può essere scelto

Nella schermata Specify Replicas aggiungete il secondo nodo SQL del vostro cluster. Fate clic su Add Replica… e loggatevi al server con credenziali amministrative.

Figura 30: aggiunta del SQL Server di replica

Figura 31: Connessione al SQL Server di replica

Selezionate i due SQL Server e abilitate l’Automatic Failover mettendo i segni di spunta accanto ai due server.

Figura 32: Abilitazione dell’Automatic Failover

Nella Scheda Endpoints assicuratevi che il Port Number sia 5022.

Figura 33: Endpoint esposti dai due server SQL

Nella scheda Listener create un nuovo Availability Group Listener e mettete il nome DNS, che verrà registrato nella vostra zona di dominio, la porta 1433 e l’indirizzo IP da assegnare al Listener. Questa parte è molto importante perché viene creato un componente che permetterà alle applicazioni di potersi connettere al database senza dover conoscere quale istanza di SQL Server sta ospitando la replica primaria. Ogni Availability Group avrà il proprio Listener . Verrà creato un nuovo computer in Active directory e verrà registrato il nome all’interno della zona DNS.

Figura 34: Creazione del Listener utilizzato dall’Availability Group

Scegliete a questo punto nella pagina Select Initial Data Synchronization di effettuare una sincronizzazione di tipo Full. Indicate anche una cartella condivisa in rete all’interno della quale verrà messo il file del database e il file di log.

Figura 35: Sincronizzazione Full del database

Figura 36:Validazione delle scelte effettuate

Figura 37: Schermata di riepilogo del wizard

Figura 38: Abilitazione dell’Availability Group completata

Nel SQL Management Studio potrete vedere l’ Availability Group che avete creato e potrete verificare che il database è stato correttamente replicato sul secondo SQL Server, come mostrato nella figura sotto:

Figura 39: Il database è stato correttamente replicato sul secondo SQL Server

Figura 40: In Active Directory stato creato un oggetto per il Listener dell’Availability Group creato

Installazione del client SQL sui server RD Connection Broker

Installate il SQL Server Native Client 11 sui vostri RD Connection Broker. Su ognuno di loro procedete a scaricare il client partendo dall’indirizzo https://go.microsoft.com/fwlink/?linkid=866658

Scegliete Download Media e dopo aver estratto i file accedete alla cartella \SQLEXPR_x64_ENU\1033_ENU_LP\x64\Setup\x64 all’interno della quale troverete il file SQLNCLI.msi

Figura 41: Download dei tools di SQL Server

Figura 42: Scelta della lingua dell’installer di SQL Server

Figura 43: Installazione del SQL Server Native Client 11 in tutti e due i Connection Broker

NOTA: Assicuratevi di installare almeno la versione 11.4.7462.6 di SQL Server Native Client 11 sui vostri RD Connection Broker ,altrimenti potreste avere problemi di connessione al server SQL 2019.

Configurazione dell’alta disponibilità del ruolo RD Connection Broker

Possiamo quindi ora tornare nel Server Manager e dal Deployment Overview cliccare col tasto destro sul’icona RD Connection Broker e scegliere la voce Configure High Availability.

Figura 44: Configurazione High Availability dell’RD Connection

Figura 45: Wizard di configurazione High Availability dell’RD Connection Broker

Figura 46: Scelta del tipo di database server da utilizzare

Inserite a questo punto il nome del cluster di RD Connection Broker (vi ricordate il record NIC-RDS che abbiamo creato poco fa nel DNS?) e la stringa di connessione al database, nella forma DRIVER=SQL Server Native Client 11.0;SERVER=<nome del Listener creato per l’Availability Group>;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=<nome del database>. Nel mio caso la stringa di connessione è:

DRIVER=SQL Server Native Client 11.0;SERVER=NIC-SQLAG;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=RDSHA

Figura 47: Inserimento del nome del cluster RD Connection Broker e stringa di connessione al database

Se non ci saranno problemi, procederete col wizard. In caso contrario vi apparirà una schermata di errore e dovrete investigare sui permessi di accesso al database, sulle regole del firewall dei server SQL e dei server RDCB, sulla correttezza della stringa di connessione e sulla versione del SQL Server Native client 11. Insomma tutto quello che potrebbe impedire agli RD Connection Broker di potersi collegare al database che avete precedentemente creato.

Figura 48: Connessione al database SQL avvenuta correttamente

Figura 49: Configurazione dell’alta disponibilità completata

Una volta completata la configurazione dell’alta disponibilità degli R the connection broker , nel Server Manager sarà evidenziato che il primo RD Connection Broker (nel mio caso NIC-RDCB3) è stato configurato per l’alta disponibilità.

Figura 50: Il primo RD Connection Broker (nel mio caso NIC-RDCB1) è stato configurato per l’alta disponibilità

Procedette quindi ad aggiungere il secondo RD Connection Broker cliccando con il tasto destro sull’icona RD Connection Broker e scegliendo Add RD Connection Broker Server, come mostrato nella figura sotto:

Figura 51: Aggiunta del secondo RD Connection Broker al nostro deployment

Figura 52: Prerequisiti necessari ad aggiungere il secondo RD Connection Broker

Figura 53: Scelta del secondo RD Connection Broker

Figura 54: Conferma della selezione dl secondo server

Figura 55: Wizard completato con successo

Adesso i vostri due RD Connection Broker sono stati resi altamente disponibili utilizzando un database ospitato su un SQL Server Always On Availability Group.

Conclusioni

Per assicurare l’alta disponibilità della nostra infrastruttura di Remote Desktop Services è necessario almeno raddoppiare tutti gli elementi che compongono l’infrastruttura. Sicuramente l’operazione non è banale e richiede l’utilizzo di molte risorse. Se volete sapere come mettere in alta disponibilità gli altri ruoli dei Remote Desktop Services di Windows Server, vi invito alla lettura della mia guida Configurare l’alta disponibilità dei Remote Desktop Services in Windows Server 2016 e Windows Server 2019 – ICT Power