Cybersécurité, Virtualisation & Intelligence Artificielle... VIRTU-DESK - Technologies de virtualisation et sécurisation de l'environnement utilisateurs.

XenApp 7.6 et la gestion de tolérance de panne

Par Le samedi, 03 janvier 2015 0

Dans Virtualisation d'applications

 

Ce billet fait référence à la gestion de la tolérance de panne sous XenApp & XenDesktop 7.6 décrite sur le site « Citrix eDocs ». Il présente les différentes solutions qui permettent d'améliorer le niveau de tolérance aux pannes dans un déploiement afin de garantir la disponibilité totale des bureaux et des applications stratégiques.

La tolérance de panne des bases de données

Toutes les informations sont stockées dans la base de données de configuration du site. Les Delivery Contrôleurs communiquent uniquement avec la base de données et non l'un avec l'autre. Il est possible de déconnecter un Contrôleur ou de le mettre hors tension sans affecter les autres Contrôleurs du site. Cela signifie cependant que la base de données de configuration du site présente un point de défaillance. Si le serveur de base de données n'est plus accéssible, les connexions existantes aux bureaux virtuels continueront de fonctionner jusqu'à que l'utilisateur ferme sa session ou se déconnecte. Si le serveur de la base de données est indisponible, aucune nouvelle connexion ne peut être établie.

Citrix recommande donc de sauvegarder régulièrement la base de données afin de pouvoir la restaurer en cas de défaillance du serveur SQL. En outre, il existe trois solutions de haute disponibilité à considérer pour garantir le basculement automatique :
  • Mise en miroir SQL : il s'agit de la solution recommandée. La mise en miroir de la base de données garantit qu'en cas d'indisponibilité soudaine du serveur de base de données actif, le processus de basculement automatique se produit au bout de quelques secondes seulement, évitant généralement toute gêne pour les utilisateurs. Cependant, cette méthode est plus coûteuse que d'autres solutions car les licences complètes de SQL Server sont requises sur chaque serveur de base de données. SQL Server édition Express n'est pas supporté pour un environnement de mise en miroir.
  • À l'aide des fonctionnalités de haute disponibilité de l'hyperviseur : avec cette méthode, vous déployez la base de données en tant que machine virtuelle et utilisez les fonctionnalités de haute disponibilité de l'hyperviseur. Cette solution est moins coûteuse que la mise en miroir du fait qu'elle utilise le logiciel d'hyperviseur et qu'il est également possible d'utiliser SQL Express. Cependant, le processus de basculement automatique est plus lent car il faut un certain temps pour qu'une nouvelle machine démarre pour la base de données, avec le risque d'interrompre le service fourni aux utilisateurs.
  • Mise en cluster SQL : la technologie de mise en cluster SQL de Microsoft peut être utilisée pour permettre à un serveur d'assurer automatiquement la reprise des tâches et des responsabilités d'un autre serveur en échec. Toutefois, cette solution est plus complexe à mettre en place et le basculement automatique est généralement plus lent qu'avec les autres méthodes, comme la mise en miroir SQL.
Les « Groupes de disponibilité AlwaysOn » est une solution à haute disponibilité et reprise après sinistre introduite dans SQL Server 2012. Elle permet d'optimiser la disponibilité pour une ou plusieurs bases de données utilisateur. Les Groupes de disponibilité AlwaysOn nécessitent que les instances SQL Server résident les nœuds WSFC (Windows Server Failover Clustering). Pour de plus amples informations, consultez les groupes de disponibilité AlwaysOn (SQL Server).

Configuration d'un site afin qu'il utilise une base de données mise en miroir

Le processus de configuration implique des tâches réalisées par un administrateur en utilisant les outils d'administration SQL Server avant de créer le site. Les tâches restantes se produisent lorsque l'administrateur exécute l'Assistant Création de site.Un environnement miroir nécessite au moins deux machines SQL Server (par exemple, SQL Server A et SQL Server B). SQL Server édition Express ne peut être utilisé comme un principe ou un miroir.

À l'aide des outils d'administration SQL Server de Microsoft, configurez les bases de données SQL Server :

  1. Installez le logiciel SQL Server sur SQL Server A et SQL Server B.
  2. Dans SQL Server A, créez la base de données destinée à être utilisée comme principe (par exemple, monMiroirDeBasededonnées).Dans SQL Server A, sauvegardez la base de données dans un fichier et copiez-le sur SQL Server B.
    • Assurez-vous que la base de données utilise le modèle de récupération complet et non le modèle simple. (Le modèle simple est configuré par défaut, mais empêche le journal des transactions d'être sauvegardé.)
    • Utilisez le paramètre d'assemblage suivant lors de la création de la base de données : Latin1_General_CI_AS_KS (où Latin1_General varie selon le pays ; par exemple Japanese_CI_AS_KS). Si ce paramètre d'assemblage n'est pas spécifié lors de la création de la base de données, la création suivante des schémas de service à l'intérieur de la base de données échouera, et une erreur similaire à « <service>: schema requires a case-insensitive database » s'affiche (<service> correspondant au nom du service dont le schéma est en cours de création).
    • Activez un instantané en lecture validée comme décrit dans l'article CTX137161. Il est important d'activer ceci avant mise en miroir de la base de données pour éviter les erreurs.
  3. Dans SQL Server B, restaurez le fichier de sauvegarde vers ce serveur (SQL Server B).
  4. Dans SQL Server A, démarrez la mise en miroir.

L'étape suivante dépend du fait que l'administrateur Citrix (c'est-à-dire, la personne exécutant l'Assistant Création de site) dispose des privilèges de base de données complets :

  • Si l'administrateur Citrix dispose des privilèges de base de données (la même personne est l'administrateur de base de données et l'administrateur Citrix), Studio réalise tout ce dont vous avez besoin :
    1. L'administrateur Citrix utilise Studio pour créer un site, indiquant l'adresse du de la base de données SQL Server créée précédemment et son nom (myDatabaseMirrorForXD).
    2. Les scripts de base de données sont automatiquement appliqués et les bases de données de principe et de mise en miroir sont définies.
  • Si l'administrateur Citrix ne dispose pas des privilèges de base de données, l'administrateur Citrix doit obtenir de l’aide à partir d'un administrateur de base de données :
    1. L'administrateur Citrix utilise Studio pour créer un site, indiquant l'adresse du SQL Server créé précédemment et son nom (myDatabaseMirrorForXD).
    2. Dans l'Assistant de création de site, le fait de sélectionner Générer le script génère un script miroir et un script principal. L'administrateur Citrix offre ces scripts à l'administrateur de base de données, qui applique les scripts (le script miroir doit être appliqué en premier). L'administrateur de base de données doit avertir l'administrateur Citrix lorsque cette tâche est terminée.
    3. De retour dans Studio, l'administrateur Citrix peut maintenant terminer l'assistant Créer un site. Les bases de données de principe et de mise en miroir sont définies.

Pour vérifier la mise en miroir après création du site, exécutez l'applet de commande PowerShell get-configdbconnection pour vous assurer que le partenaire de basculement a été défini dans la chaîne de connexion pour le miroir.Si vous ajoutez, déplacez ou supprimez un Delivery Controller dans un environnement de base de données mise en miroir ultérieurement, consultez Ajouter, supprimer ou déplacer des Controller, ou déplacer un VDA pour plus de considérations.

Assurez l'accès au bureau et à l'application si les Controllers échouent.

Si tous les Delivery Controllers d'un site échouent, vous pouvez configurer Virtual Delivery Agents pour fonctionner en mode haute disponibilité de sorte à ce que les utilisateurs puissent continuer à accéder à leurs bureaux et applications et les utiliser. En mode haute disponibilité, le VDA accepte des connexions ICA directes provenant des utilisateurs, plutôt que des connexions négociées par le Controller.

Cette fonctionnalité n'est à utiliser que lors de rares occasions lorsque les communications avec tous les contrôleurs échouent ; cela ne constitue pas une alternative aux autres solutions de haute disponibilité. Pour obtenir davantage d'informations, veuillez consulter la section CTX127564.

Lorsque la base de données n'est pas disponible

La fonctionnalité de location de connexion complète les meilleures pratiques de la haute disponibilité du serveur SQL Server en permettant aux utilisateurs de se connecter et de se reconnecter à leurs applications et bureaux les plus récemment utilisés, même lorsque la base de données du site n'est pas disponible. Pour plus d’informations, veuillez consulter la rubrique Location de connexions.

5 votes. Moyenne 5 sur 5.
Vous devez être connecté pour poster un commentaire