Concepts et déploiement XenApp et XenDesktop sur CloudPlatform. Concepts et déploiement XenApp et XenDesktop sur CloudPlatform

Transcription

1 Concepts et déploiement XenApp et XenDesktop sur CloudPlatform Concepts et déploiement XenApp et XenDesktop sur CloudPlatform Préparé par : Paul Howard Rédacteur : Jan Penovich Version : 1.0 Dernière mise à jour : 30 avril 2014

2 Table des matières Première partie : vue d'ensemble des concepts et infrastructure requise pour Citrix CloudPlatform... 4 Rôles nécessaires à la création d'un site sur le cloud... 4 Actifs et responsabilités... 4 IaaS et DaaS... 7 Clouds publics et privés... 7 Isolation régionale... 7 API CloudPlatform... 8 Synchronisation temporelle... 8 Groupes de sécurité... 8 Infrastructure requise... 8 Configurations d'infrastructure recommandées... 9 Paramètre de version XenTools...10 Offres de disque, service XenDesktop, réseau et modèles...11 Offres de disque personnalisées...11 Offres de service XenDesktop...13 Offres de réseau...13 Modèles Windows...13 Modèle de travailleur de volume...15 Créer un modèle de travailleur de volume...15 Mises à jour de sécurité...18 Cloud privé virtuel (VPC)...19 Location dédiée...19 Active Directory...20 Partie 2 : déploiement...22 Configuration requise...22 Version CloudPlatform...22 Prise en charge de l'hyperviseur...22 Lancer un Delivery Controller...22 Installer XenDesktop...23 Exemple : passez d'un CloudPlatform nu à un site XenDesktop...23 Page 2

3 Isolation de la préparation des images...25 Exemple : créer un simple site avec Studio Définir les paramètres de site de base...26 Décrire une connexion à l'infrastructure d'hébergement...27 Spécifiez l'emplacement de la machine virtuelle et du réseau Créer un catalogue de bureaux virtuels Créer un groupe de mise à disposition...29 Page 3

4 Première partie : vue d'ensemble des concepts et infrastructure requise pour Citrix CloudPlatform Ceci est une vue d'ensemble des concepts et de l'infrastructure requise que vous devriez connaître avant de configurer un site XenApp ou XenDesktop sur une infrastructure CloudPlatform. Pour de plus amples informations sur le déploiement de XenApp ou XenDesktop avec CloudPlatform, reportez-vous à la section Partie 2 : déploiement. Rôles nécessaires à la création d'un site sur le cloud Les personnes ou équipes doivent renseigner trois rôles distincts avant de créer un site XenApp ou XenDesktop sur le cloud : Ingénieur d'infrastructure : cette personne (ou l'équipe/organisation) héberge le matériel et sa présentation sous forme de cloud CloudPlatform. L'ingénieur d'infrastructure installe CloudPlatform et configure les hôtes, les pods, les clusters, les zones, le stockage et le réseau. L'ingénieur d'infrastructure fournit un cloud qui peut théoriquement être utilisé à toute fin (par exemple, Amazon peut être considéré comme ingénieur d'infrastructure pour leur cloud). Concepteur de service : cette personne (ou l'équipe) consomme l'infrastructure de cloud fixe définie par l'ingénieur d'infrastructure. Le concepteur de service utilise l'infrastructure cloud brute pour créer un service utile spécifique pour la mise à disposition ultime vers les utilisateurs. Remarque : dans ce document, le service spécifique est XenDesktop. Administrateur de site : cette personne (ou équipe) consomme le service de cloud XenDesktop et utilise Studio pour définir le site et les équipements de celui-ci. Le modèle d'administration déléguée propre de XenDesktop peut ensuite être utilisé pour déléguer des parties de cette gestion à d'autres administrateurs subalternes. Dans ce document, ils font partie du même rôle général. Dans le plus simple des cas, un seul individu agit dans les trois rôles en même temps. Dans le cas le plus complexe, chaque rôle peut être rempli par des équipes complètes ou d'autres organisations, et comporter encore plus de sous-divisions entre elles. Actifs et responsabilités L'ingénieur d'infrastructure est responsable de l'installation CloudPlatform et du matériel d'hébergement et de l'ensemble de l'organisation associés. Étant donné que l'infrastructure peut être entièrement indépendante de XenDesktop, il n'existe aucune activité spécifique à XenDesktop requise par l'ingénieur d'infrastructure. Le concepteur de service et l'administrateur de site sont responsables de toutes les activités spécifiques à XenDesktop. De ces deux, le concepteur de service est la personne/l'équipe qui Page 4

5 transforme l'infrastructure CloudPlatform brute en une charge de travail XenDesktop fonctionnelle. L'illustration ci-dessous montre la séparation des responsabilités et la manière dont les différents actifs circulent dans le système. De manière générale, le concepteur de service consomme l'infrastructure, qui est ensuite consommée par l'administrateur du site. Cela engendre le flux à trois niveaux affiché ci-dessous. En pratique, il est possible que la ou les même(s) organisation(s) ou individus partagent une responsabilité pour tout ou partie de ces étapes. Page 5

6 Page 6

7 IaaS et DaaS L'infrastructure en tant que service (IaaS) fait référence à la mise à disposition par l'ingénieur d'infrastructure de l'infrastructure de cloud. Les bureaux en tant que service (DaaS) font référence à la mise à disposition de bureaux et d'applications hébergés sur le cloud pour les utilisateurs finaux. Le concepteur de service consomme un cloud IaaS à partir de l'ingénieur d'infrastructure et met à disposition un service de cloud DaaS pour les utilisateurs finaux. Clouds publics et privés Dans un cloud public, l'ingénieur d'infrastructure met le cloud à disposition pour une utilisation générale (IaaS) et facture généralement les consommateurs (ou locataires), qui exécutent ensuite leurs propres services sur une infrastructure qui ne leur appartient pas. Dans un cloud public, il existe un degré élevé de séparation entre l'ingénieur d'infrastructure et le concepteur de service. Dans un cloud privé, la même organisation ou entité qui fournit le service de bureau virtuel est propriétaire de l'infrastructure. Cela implique qu'il existe un lien plus étroit entre l'ingénieur d'infrastructure et le concepteur de service. Ces termes reflètent l'exposition de l'infrastructure CloudPlatform uniquement, et non pas l'exposition du service XenDesktop. Par exemple, une entreprise peut utiliser CloudPlatform en interne dans leur centre de données pour créer une offre DaaS qui est ensuite exposée publiquement. Toutefois, bien que le service DaaS soit public, le cloud d'infrastructure lui-même est privé, par conséquent, ceci serait considéré comme un cloud privé. Isolation régionale Que le cloud soit privé ou public, il se peut que l'infrastructure soit composée de plusieurs régions. (Des infrastructures à régions multiples sont plus susceptibles d'être la propriété de clouds publics que privés. Les services de cloud publics opèrent généralement sur des échelles plus importantes et plus expansives géographiquement, ainsi l'isolation régionale est plus logique). Dans CloudPlatform, les isolations régionales fonctionnent de la même manière que sur Amazon Web Services (AWS) : c'est-à-dire, que ce sont des services isolés à 100%, sans permutation des ressources. Les régions de cloud sont effectivement, des clouds distincts proposant un service similaire. Les régions se connectent en toute simplicité : chaque région fournit une fonctionnalité de découverte des noms et des détails de connexion pour les autres régions ; sinon, elles sont complètement séparées. XenDesktop 7.5 possède une restriction d'une région par site. Tout site XenDesktop doit exister dans une région de cloud uniquement. Pour utiliser plusieurs régions, vous devez disposer de plusieurs sites XenDesktop, utilisant potentiellement StoreFront pour les regrouper. Page 7

8 API CloudPlatform Si le cloud est public, il est supposé exposer l'api REST de CloudPlatform directement ; c'est-àdire, la partie utilisateur de l'api documentée ici. Il se peut que certains clouds IaaS publics utilisent CloudPlatform en interne, mais exposent ensuite ses services à l'aide d'une API propriétaire. De telles offres de clouds publics ne sont pas compatibles avec XenDesktop 7.5, car XenDesktop a été intégré uniquement avec l'api de CloudPlatform. Synchronisation temporelle Il est important d'avoir une source de temps commune au travers du système. Ceci est particulièrement important lors de l'exécution d'une charge de travail XenDesktop, car les certificats SSL sont utilisés pour la sécurisation de certaines communications entre Delivery Controller et certains services virtualisés qui s'exécutent dans la zone du cloud. Un horaire mal synchronisé peut entraîner l'échec de l'authentification de ces canaux, ce qui rend impossible la réussite du provisioning des bureaux. Citrix recommande d'utiliser un serveur NTP (Network Time Protocol) dans le système. Configurez tous les hôtes dans toutes les zones de cloud pour obtenir leur signal horaire à partir de ce serveur central. De même, le domaine Active Directory Windows devrait utiliser la même source de temps. Vérifiez attentivement la synchronisation temporelle car les décalages temporaires sont une source d'erreur très courante au sein d'une session charge de travail XenDesktop. Groupes de sécurité CloudPlatform prend en charge l'utilisation de groupes de sécurité dans les zones de réseau de base uniquement. Citrix vous recommande de ne pas utiliser les groupes de sécurité dans les zones avancées lors de l'utilisation de charges de travail XenDesktop dans le cloud. (Les groupes de sécurité peuvent être utilisés dans des zones de base pour l'isolation, si nécessaire). Infrastructure requise Cette section décrit les actifs que l'ingénieur d'infrastructure doit mettre à disposition pour créer un cloud pour la prise en charge de la charge de travail XenDesktop : Au moins une région, exposant un point de terminaison pour l'api CloudStack utilisateur et la console Web. Au moins une zone avec stockage secondaire à l'échelle de la zone. Au moins un cluster, avec stockage principal au niveau du cluster. Page 8

9 Au moins un hôte, avec un stockage local haute performance. (La configuration requise du stockage local n'est pas réellement nécessaire, mais la recommandation pour XenDesktop pour les bureaux regroupés consiste à s'exécuter sur un stockage connecté à l'hôte. Tout type de bureau peut également s'exécuter sur un stockage partagé principal, probablement basé sur SAN). Réseau physique. En outre, l'ingénieur d'infrastructure devrait rendre les modèles de système d'exploitation disponibles. Tous ceux-ci doivent être étendus si nécessaire aux outils paravirtuels appropriés pour la plate-forme d'hyperviseur utilisée par l'infrastructure (par exemple, XenTools pour hôtes XenServer). Les modèles peuvent également être étendus avec des logiciels supplémentaires jugés appropriés par le fournisseur de cloud : ils peuvent être des outils spécifiques au fournisseur ou des éléments de personnalisation. Systèmes d'exploitation Windows Server 2008 R2 ou Windows Server 2012 R2 : les services XenDesktop tels que Delivery Controller, le serveur de base de données, le contrôleur de domaine et StoreFront requièrent ces systèmes. Ils sont également utilisés pour les travailleurs RDS et les bureaux VDI serveur. Windows 7 ou Windows 8.1 : un fournisseur de cloud public peut se voir empêcher de mettre ceux-ci à disposition en raison de problèmes de revente de licence. (Amazon Web Services, par exemple, n'est actuellement pas en mesure de fournir de tels modèles). Sans ces modèles, les services XenDesktop sont limités aux déploiements VDI serveur ou de type RDS. Les fournisseurs d'infrastructure peuvent également mettre des instances étendues à disposition, telles que Windows Server avec SQL Server pré-installé. XenDesktop ne nécessite pas de tels modèles, bien que le processus d'installation puisse être optimisé, s'ils sont disponibles. Les modèles doivent être correctement préparés avec Sysprep. Pour plus d'informations, consultez le chapitre 13 du Guide de l'administrateur de CloudPlatform 4.2 pour plus de détails sur l'utilisation de modèles Windows. Une fois l'infrastructure reçue par le concepteur de service, ce dernier exécute les étapes restantes. Configurations d'infrastructure recommandées CloudPlatform est fortement personnalisable pour autoriser des charges de travail différentes afin de faire le meilleur usage possible de l'infrastructure. Remarque : l'administrateur de l'infrastructure peut effectuer de nombreuses personnalisations en modifiant les différents paramètres globaux. Page 9

10 Le tableau suivant présente les recommandations pour certains des paramètres globaux spécifiques à réaliser. Pour plus d'informations sur les paramètres globaux, consultez le Guide de l'administrateur de CloudPlatform 4.2. Nom Description Valeur Remarques wait max.template.iso.size vmware.root.disk.controller vmware.create.full.clone Durée en secondes à attendre pour le retour des commandes de contrôle. La taille maximale autorisée pour un modèle ou ISO téléchargé (en Go). Définissez cette valeur sur osdefault pour les clouds VMware. La définition de cette valeur sur FALSE vous permet d'utiliser des clones légers, qui démarrent plus vite et utilisent moins d'espace disque Lorsque le serveur de stockage répond lentement, l'augmentation de cette valeur permet de patienter plus longtemps Ceci est utile si la taille du modèle est supérieure à 50 Go Si vous possédez une solution de stockage matérielle accélérée, ou que vous utilisez d'autres outils qui ne sont pas compatibles avec les clones légers, il se peut que vous ne souhaitiez pas désactiver ce paramètre. Paramètre de version XenTools Lors de l'utilisation d'une zone avec XenServer comme hyperviseur sous-jacent, vous devez vérifier la propriété XenServer Tools 6.1+ de tous les modèles Windows qui sont créés dans le cadre du déploiement. La console de gestion CloudPlatform n'autorise pas la réalisation de cette action lors de la création du modèle. Lorsque le modèle est prêt, modifiez les propriétés Page 10

11 du modèle pour activer les paramètres requis et sélectionnez la case à cocher XenServer Tools Offres de disque, service XenDesktop, réseau et modèles Les offres de disque fournissent un choix de taille de disque et de type de stockage. Les offres de service XenDesktop fournissent un choix de puissance de calcul et d'autres options. Les offres de réseau fournissent un ensemble de services réseau. Les modèles fournissent les images de base. Offres de disque personnalisées XenDesktop a besoin de créer des disques de taille arbitraire, nécessitant une offre de disque personnalisée. Si l'infrastructure ne fournit pas d'offre de disque personnalisée, le concepteur du service doit en créer une avec la console Web à l'aide de la procédure détaillée dans l'illustration ci-dessous. Notez que vous devez créer l'offre de disque personnalisée avec un type de stockage partagé, mais vous pouvez recevoir des offres personnalisées supplémentaires avec d'autres types de stockage. Il doit exister au moins une offre de disque personnalisée pour le stockage partagé ; sinon, XenDesktop n'est pas capable de provisionner des catalogues de machines. Page 11

12 Page 12

13 Offres de service XenDesktop CloudPlatform est fourni avec certaines offres de calcul de base par défaut : Small Instance Medium Instance Pour le déploiement XenDesktop, le concepteur de service crée des offres de service supplémentaires. Les offres de service devraient se voir octroyer une quantité de puissance de calcul et de performances réseau appropriée à une classe différente de machine de travail qui sera utilisée dans le déploiement. (Les travailleurs RDS, par exemple, ont besoin de plus de ressources que les bureaux mono-utilisateur). En outre, les bureaux regroupés sont conçus pour s'exécuter sur un stockage (local) connecté à l'hôte. Cela signifie que vous devez créer au moins une offre de service avec le type de stockage Local à l'aide de la console Web CloudPlatform. Offres de réseau Pour les charges de travail XenDesktop en cours d'exécution, les réseaux doivent prendre en charge le service de données utilisateur CloudPlatform. Lors de la création de réseaux à utiliser dans XenDesktop, assurez-vous toujours qu'ils sont dérivés d'une offre de réseau qui prend en charge ce service. Modèles Windows CloudPlatform ne fournit pas de modèles de système d'exploitation Microsoft Windows «out of the box». Les ingénieurs d'infrastructure doivent installer ceux-ci dans le système et s'assurer qu'ils contiennent les outils paravirtuels appropriés à la plateforme d'hébergement (par exemple, XenTools pour clouds XenServer). Vous pouvez importer des modèles en tant que disques durs virtuels depuis, par exemple, XenServer. Toutefois, la meilleure pratique pour que Windows s'exécute dans CloudPlatform est de commencer en effectuant l'installation à partir du support Windows comme un fichier image ISO. Les fichiers image ISO doivent d'abord être obtenus auprès de Microsoft, ou certains référentiels ISO d'entreprise appropriés. Ils doivent être disponibles au téléchargement à partir d'un service Web qui est visible par CloudStack. Un moyen simple d'effectuer ceci est d'activer les services Internet (IIS) sur une machine Windows existante et de publier les fichiers ISO à partir d'un répertoire Web sur celleci. Page 13

14 Un récapitulatif de la procédure est affiché dans cette image. Page 14

15 Sachez que l'abonnement ISO dans CloudPlatform peut sembler être un processus très rapide et votre fichier ISO est ajouté à la liste presque immédiatement. Cela ne signifie pas que le modèle est prêt. Le téléchargement des fichiers ISO Windows peut prendre plusieurs minutes depuis votre service Web local dans le stockage de zone. Pour vérifier le statut réel du modèle, sélectionnez-le pour afficher ses détails. Lors du téléchargement, les détails indiquent qu'il n'est pas encore prêt et le pourcentage du téléchargement progresse. Vous pouvez utiliser le fichier ISO uniquement lorsqu'il est entièrement téléchargé et installé, à ce moment-là le statut change pour indiquer que le modèle est prêt. Modèle de travailleur de volume Pour créer des machines dans CloudPlatform à l'aide de XenDesktop Machine Creation Services (MCS), le concepteur de service doit créer un modèle de travailleur de volume XenDesktop dans CloudPlatform qui réalise des opérations de provisioning pour le MCS sur le contrôleur XenDesktop. Lorsque le modèle est créé, il doit être copié sur toutes les zones que le concepteur de service doit utiliser. Créer un modèle de travailleur de volume Utilisez les procédures suivantes pour créer un modèle de travailleur de volume. Partie 1 : installer ISO CentOS Pour commencer le processus, vous devez disposer d'une installation CentOS 6.4 Linux. Effectuez cette opération en important un fichier ISO CentOS dans le système pratiquement de la même manière que les modèles Windows sont importés. 1. Créez une instance depuis le fichier ISO installé. 2. Sélectionnez la zone utilisée pour cette installation. 3. Utilisez une offre de service avec un faible encombrement mémoire. Par exemple, l'offre Small Instance intégrée. 4. Sélectionnez un réseau approprié. Remarque : cela peut être n'importe quel réseau disponible qui fournit l'accès à Internet. 5. Terminez le processus d'installation CentOS. Page 15

16 Partie 2 : activer la mise en réseau CentOS n'active pas la mise en réseau par défaut. Utilisez vi /etc/sysconfig/networkscripts/ifcfg-eth0 pour activer la mise en réseau. 1. Modifiez ONBOOT=no en ONBOOT=yes. 2. Supprimez l'entrée HWADDR (adresse MAC), si elle est présente dans le fichier. 3. Supprimez l'entrée UUID, si elle est présente dans le fichier. 4. Enregistrez le fichier. Partie 3 : activer l'interface et vérifier qu'elle a obtenu une adresse IP 1. Pour afficher l'interface réseau en ligne, exécutez la commande ifup eth0. 2. Pour vérifier que l'instance a obtenu une adresse IP, exécutez la commande ifconfig eth0. Partie 4 : connexions SSL 1. Pour accepter les connexions SSL entrantes, assurez-vous que le port 443 est ouvert dans le pare-feu (iptables) à l'aide de vi /etc/sysconfig/iptables pour apporter la modification suivante, puis enregistrez le fichier. Ajoutez la ligne -A INPUT -p tcp --dport 443 -j ACCEPT à la chaîne des règles d'entrée, au-dessus de la ligne -A INPUT -j REJECT --reject-with icmp-hostprohibited. 2. Appliquez les nouvelles règles avec service iptables restart. Partie 5 : copier le pack logiciel Citrix sur la machine 1. Si l'instance requiert la définition d'un proxy HTTP pour accéder à des sites externes, définissez-le avec export http_proxy= 2. Vérifiez que le système d'exploitation et les packs installés sont à jour avec yum update et appuyez sur Y pour accepter le téléchargement et l'installation. 3. À l'aide de WinSCP ( depuis le contrôleur XenDesktop, connectez-vous à l'adresse IP répertoriée par la commande ifconfig ci-dessus. 4. Naviguez vers le répertoire local à l'adresse C:\Program Files\Citrix\MachineCreation\Service\VolumeWorker. 5. Copiez le fichier ctxvwd i386.rpm dans l'instance centos distante. Page 16

17 Remarque : WinSCP ne constitue qu'une seule des méthodes de transfert du pack rpm pour l'instance du travailleur de volume. Utilisez toute méthode préférée telle que le montage de partages cif/nfs ou utilisez le curl pour l'obtenir à partir d'un serveur HTTP. 6. Installez le pack de travailleur de volume Citrix avec yum install ctxvwd i386.rpm et appuyez sur Y pour accepter les téléchargements et l'installation. 7. Configurez le service Citrix pour CloudPlatform avec /etc/ctxvwd/selectplatform CCP. 8. Supprimez le fichier /etc/udev/rules.d/70-persistent-net.rules si présent. 9. Supprimez le fichier /var/lib/dhclient/dhclient-eth0.leases si présent. 10. Démarrez le service avec service ctxvwd start. Ceci initialise les données du service, puis arrête la machine. Page 17

18 Partie 6 : créer un modèle à partir du volume de l'instance Lorsque CloudPlatform indique que l'instance s'est arrêtée, effectuez les opérations suivantes : 1. Sur la page Storage de la console CloudPlatform, sélectionnez le volume racine de l'instance créée au début de cette procédure. 2. Sélectionnez Create Template sur les boutons de la barre d'outils. 3. Fournissez un nom et une description, puis sélectionnez CentOS 6.0 (32 bits) en tant que type de système d'exploitation, puis cliquez sur OK. 4. Identifiez le modèle comme une instance de travailleur de volume Citrix pour permettre à XenDesktop de le localiser. 5. Ouvrez la page de détails pour le modèle. 6. Faites défiler vers le bas vers la section «tags». 7. Ajoutez une balise à l'aide de la clé Citrix.XenDesktop.Template.Role et la valeur VolumeServiceWorkerRole. Mises à jour de sécurité Une fois que vous avez créé un modèle, surveillez la disponibilité de correctifs de sécurité. Également, à mesure que de nouvelles versions de XenDesktop sont mises à disposition, il est important d'effectuer la mise à jour avec la version la plus récente du pack de travailleur du volume (ctxvwd). Pour appliquer une mise à jour de sécurité, créez un nouveau modèle contenant les mises à jour appropriées. Si XenDesktop détecte plusieurs modèles avec la même balise, il utilise Page 18

19 toujours le plus récent, il n'est pas nécessaire de supprimer les balises ou supprimer les anciens modèles. Cloud privé virtuel (VPC) Si l'infrastructure est utilisée comme service de cloud public, le concepteur de service doit créer un VPC dans chaque zone de disponibilité dans laquelle le service s'exécutera. Établissez des connexions VPN sur ce VPC. Location dédiée Si le cloud est privé et les zones utilisent une mise en réseau de base (à l'inverse de avancée), le concepteur de service doit créer un ensemble de groupes de sécurité appropriés, avec des ports appropriés ouverts pour les instances d'infrastructure et instances (VDA) de travailleur. Les clients peuvent appliquer leur propre configuration pour modifier les numéros de port utilisés par XenDesktop. Toutefois, en l'absence d'une telle configuration requise spéciale, les concepteurs de service devraient créer des groupes de sécurité avec les règles d'entrée suivantes : Port TCP 80 (pour HTTP/WCF) Port TCP 443 (pour SSL/HTTP(s)) Port TCP 2598 (pour ICA) Page 19

20 Active Directory Windows Active Directory fait partie du déploiement du concepteur de service. Les modèles pris en charge pour le déploiement Active Directory sont compris dans les catégories suivantes : Active Directory complètement dans les locaux : aucune partie d'active Directory n'est en cours d'exécution dans le cloud. Toutes les instances hébergées dans le cloud (par exemple, les contrôleurs et travailleurs XenDesktop) peuvent apercevoir le contrôleur de domaine à l'aide d'un réseau partagé. Cela signifie que la zone doit être soit une zone de base ou une zone avancée avec une offre de réseau partagée. Page 20

21 Active Directory dans les locaux, avec un contrôleur de domaine secondaire dans le cloud : le cloud est en cours d'exécution dans un réseau isolé, mais avec un VPN site à site établi. Active Directory complètement dans le cloud : en général, ce scénario est limité aux petits déploiements de validation ou de démonstration. Il existe deux problèmes clés logistiques entourant le déploiement Active Directory : Les adresses DHCP sont affectées par le cloud. Généralement, dans un domaine Windows, le contrôleur de domaine est à la fois un serveur DHCP et DNS. Dans CloudPlatform, DHCP ne peut pas provenir du domaine Windows, car il est géré par CloudPlatform en interne pour assurer que les affectations d'adresse IP suivent les restrictions de plage IP établies pour la zone. Cela signifie que DHCP doit être désactivé sur tout contrôleur de domaine Windows situé dans le cloud. Les contrôleurs de domaine nécessitent des adresses IP fixes. Tout contrôleur de domaine (qu'il soit principal ou secondaire) en cours d'exécution dans le cloud doit posséder une adresse IP fixe. Notez que fixe ne signifie pas statique. Toutes les instances de cloud possèdent des adresses DHCP attribuées par le routeur virtuel local, de sorte qu'elles ne soient pas statiques. Toutefois, il est possible de démarrer une instance de cloud de sorte qu'elle se voit toujours attribuer la même adresse connue, la rendant effectivement statique. (Des installations similaires sont disponibles dans Amazon Web Services). Gardez à l'esprit Page 21

22 que dans CloudPlatform, la console Web ne prend pas en charge la création d'instances avec des adresses IP prescrites (contrairement à la console Amazon Web Services). De telles affectations IP sont possibles uniquement par le biais de l'api REST. Les concepteurs de service doivent effectuer des appels API pour créer des contrôleurs de domaine (principaux ou secondaires) dans le cloud. Partie 2 : déploiement La partie 2 décrit ce dont vous avez besoin pour exécuter les sites XenDesktop à la fin de l'installation de CloudPlatform. Reportez-vous à Première partie : vue d'ensemble des concepts et infrastructure requise si vous avez besoin d'informations conceptuelles et CloudPlatform de base avant de démarrer les procédures. Un site XenDesktop minimal peut être exécuté sur une installation contenant un seul hôte dans une seule zone de disponibilité. Les zones peuvent utiliser soit une mise en réseau de base ou soit une mise en réseau avancée. Les clouds publics utilisent les options avancées de mise en réseau pour autoriser les locataires à utiliser les VPC et les réseaux isolés. Les clouds privés peuvent utiliser les deux modes. Configuration requise Vérifiez que vous utilisez les plates-formes prises en charge et que l'infrastructure pré-requise est configurée avant de déployer le site XenDesktop sur le CloudPlatform. Référez-vous à la section Infrastructure requise. Version CloudPlatform Pour les clouds publics et privés, les charges de travail XenDesktop peuvent s'exécuter uniquement sur l'infrastructure qui a entièrement adopté CloudPlatform version 4.2.1, ou une version ultérieure. N'utilisez pas de versions antérieures pour héberger des charges de travail XenDesktop. Pour que toutes les fonctionnalités de XenDesktop fonctionnent de manière fiable, appliquez toutes les corrections à chaud appropriées. Prise en charge de l'hyperviseur Pour les charges de travail XenServer, l'installation de CloudPlatform doit utiliser soit l'hyperviseur XenServer soit l'hyperviseur VMware. Si vous utilisez XenServer, vous devez appliquer toutes les corrections à chaud. Lancer un Delivery Controller L'ingénieur d'infrastructure a mis les modèles Windows Server (2008 ou 2012) appropriés à disposition, avec les outils de l'hyperviseur nécessaires installés. Pour lancer un Delivery Controller, créez une nouvelle instance à partir de ce modèle et rejoignez-le au domaine Active Directory approprié. Page 22

23 Si le réseau de zone prend en charge les groupes de sécurité, lancez le contrôleur avec le groupe de sécurité qui prend en charge XenDesktop. Installer XenDesktop Lorsque les instances Windows nécessaires sont en cours d'exécution et membres du domaine Active Directory approprié, installez XenDesktop à partir du support. La procédure est similaire à Amazon Web Services et sa complexité dépend du fait que le cloud est en cours d'exécution dans un réseau isolé ou non. Si vous utilisez un réseau partagé, vous pouvez utiliser une simple opération de copie de Windows pour importer le fichier image XenDesktop.ISO sur le contrôleur et l'agent Virtual Desktop (VDA). Dans le cas de Windows 8 ou Windows Server 2012, vous pouvez ensuite monter et installer le fichier ISO. Pour les systèmes d'exploitation plus anciens, vous avez besoin d'un outil tiers pour monter l'iso comme un CD-ROM. Comme sur Amazon Web Services, une installation comme MagicISO permet ceci. Lorsque le support XenDesktop est monté, vous n'avez plus besoin d'actions spéciales. Installez comme d'habitude. Pour l'installation de VDA, supposez un provisioning de style Machine Creation Services (MCS) et choisissez l'option de création d'une image principale. Lorsque l'on vous demande de localiser le Delivery Controller, sélectionnez l'option Let Machine Creation Services do it automatically. Exemple : passez d'un CloudPlatform nu à un site XenDesktop La séquence visuelle en trois étapes ci-dessous indique comment transformer l'infrastructure brute en un site XenDesktop actif. Supposez que le site est un site d'évaluation, et ainsi vraiment minimal. Depuis les images ISO d'origine pour Windows et Linux, ajoutez une instance de Delivery Controller unique, et un seul VDA. Après installation des composants de travail XenDesktop sur le VDA, arrêtez-le et créez un modèle. Le provisioning des machines s'effectue alors à partir de ce modèle. Page 23

24 Page 24

25 Isolation de la préparation des images Dans les zones de base Amazon Web Services et CloudPlatform, la VM de préparation d'image du catalogue Machine Creation Services (MCS) est incluse dans un groupe de sécurité pour l'isoler du réseau. Dans les zones avancées CloudPlatform, la VM de préparation d'image est créée sur un réseau isolé, car CloudPlatform ne prend pas en charge les groupes de sécurité dans les zones avancées. L'administrateur doit effectuer une configuration manuelle pour la prise en charge de la préparation d'image MCS dans les zones avancées : créer un réseau d'isolation sur le compte CloudPlatform utilisé par XenDesktop. Citrix vous recommande : o DefaultIsolatedNetworkOfferingWithSourceNatService appliquer une balise au réseau afin que XenDesktop puisse le trouver. Balises de respect de la casse : o o Balise : Citrix.XenDesktop.Network.Role Valeur : MachineIsolationRole Page 25