Wiki source code of Comment remonter une infrastructure Citrix dans Flexible Engine
Last modified by Equipe Opération on 14 - 01 - 2019
Show last authors
| author | version | line-number | content |
|---|---|---|---|
| 1 | {{box cssClass="floatinginfobox" title="**Table des matières**" width="50%"}} | ||
| 2 | {{toc start=2 depth=6 numbered=true scope=page/}} | ||
| 3 | {{/box}} | ||
| 4 | |||
| 5 | == XenDesktop ou XenApp dans FE == | ||
| 6 | |||
| 7 | Le besoin est de reconstruire une infrastructure fournissant les services de bureau XenDesktop ou applicatifs XenApp Citrix dans Flexible Engine. | ||
| 8 | |||
| 9 | Or les mécanismes de provisionning standards fournis par Citrix PVS et MCS ne peuvent fonctionner nativement dans un Cloud public comme Flexible Engine. | ||
| 10 | |||
| 11 | === Cas de MCS === | ||
| 12 | |||
| 13 | MCS ne prends pas en charge les API de Flexible Engine et ne peut donc pas fonctionner pour la fourniture des applications Citrix. | ||
| 14 | |||
| 15 | === Cas de PVS === | ||
| 16 | |||
| 17 | Le mécanisme de création des images PVS demande de spécifier à l'avance les adresses MAC des interfaces des machines provisionnées, Flexible Engine ne permets pas de spécifier celle-ci. | ||
| 18 | |||
| 19 | Qui plus est, lors de la création du VDisk, le mécanisme de l'optimisation de l'image Citrix rends l'OS non-démarrable. | ||
| 20 | |||
| 21 | Si ce n'est pour ces deux parties, coté système d'exploitation le reste de mécanisme est fonctionnel : Boot Device Manager fonctionne correctement. | ||
| 22 | |||
| 23 | {{info}} | ||
| 24 | Il n'est donc pas possible d'utiliser les mécanismes natifs de Citrix pour la gestion du provisionning de machines dans Flexible Engine. | ||
| 25 | {{/info}} | ||
| 26 | |||
| 27 | == Méthode de fourniture du service par Nuabee == | ||
| 28 | |||
| 29 | === Généralités === | ||
| 30 | |||
| 31 | Du point de vue Citrix, les serveurs seront vu comme des machines physiques, dont Nuabee gerera le provisionnement sur Flexible Engine. | ||
| 32 | |||
| 33 | |||
| 34 | === Les mécanismes utilisés === | ||
| 35 | |||
| 36 | Lors de la définition d'un PRA, il est nécessaire de : | ||
| 37 | |||
| 38 | * (% style="background-color:null" %)Procéder à la création d'un nouveau catalogue de machines pour le PRA. | ||
| 39 | ** (% style="background-color:null" %)Cela résout la problématique de ne pas impacter la production Client en mettant en service un groupe de machines parallèle. | ||
| 40 | * Procéder à la création d'une image (ou de plusieurs images) de machine Citrix dédiée(s) au PRA. | ||
| 41 | ** Cette machine peut intégrer des applications de plusieurs catalogues d'Application différents existants. | ||
| 42 | * Définir un nombre de machines de ferme (instances remontées à partir de l'image PRA) et un nom pour chacune d'entre elle. | ||
| 43 | ** La génération d'un compte de machine dans une OU spécifique de l'AD et l'extraction de celui-ci sont à effectuer. | ||
| 44 | |||
| 45 | Afin de fournir le service de remontée de fermes Citrix et gérer le provisionning nécessaire, Nuabee doit disposer des éléments suivants : | ||
| 46 | |||
| 47 | * Un OS déjà prêt à tourner dans le cloud Flexible Eng(% style="background-color:null" %)ine sur lequel un processus de Sysprep est(%%) appliqué. | ||
| 48 | ** Nuabee met ainsi à disposition des images Windows Server 2008R2, 2012 et 2016 que le client personnalise en y installant les applications nécessaires à son PRA. | ||
| 49 | * Le BLOB (charge utile binaire) de jointure Hors Ligne au domaine du compte de machine pour chaque machine de ferme. | ||
| 50 | |||
| 51 | (% style="break-before: page;" %) | ||
| 52 | === Insertion de l'image Publique dans l'infrastructure in situ du Client === | ||
| 53 | |||
| 54 | Nuabee communique au client une note sécurisée incluant : | ||
| 55 | |||
| 56 | * Les urls de téléchargement des images Windows Server au format VMDK | ||
| 57 | * Les logins et mots de passe du compte Administrateur de ces images. | ||
| 58 | |||
| 59 | Ces disques virtuels sont à importer dans l'infrastructure du Client vous la forme de machines virtuelles | ||
| 60 | |||
| 61 | * Pour l'image Windows 2008-R2, penser à sélectionner le disque VMDK et utiliser une connexion IDE. | ||
| 62 | * Pour l'image Windows 2012-R2 et 2016, utiliser une connexion SCSI. | ||
| 63 | |||
| 64 | Cette machine virtuelle primaire jouera le rôle de "golden image" dans le cadre du PRA. | ||
| 65 | |||
| 66 | === Entretien de la machine source et transfert === | ||
| 67 | |||
| 68 | La procédure de gestion de l'image source coté client se décompose de la manière suivante pour chaque Golden Image : | ||
| 69 | |||
| 70 | 1. Personnaliser l'image | ||
| 71 | 1. Eteindre la machine virtuelle | ||
| 72 | 1. **Effectuer un snapshot** de la machine virtuelle afin de pouvoir revenir sur la machine une fois la procédure terminée. | ||
| 73 | 1. Rallumer la machine et effectuer le sysprep (la machine s'éteint automatiquement à la fin de celui-ci) | ||
| 74 | 1. Une fois la VM éteinte, exporter en tant qu'OVF | ||
| 75 | 1. Envoyer le résultat de l'export à Nuabee via une procédure sécurisée | ||
| 76 | 1. **Revenir sur le snapshot** avant Sysprep | ||
| 77 | |||
| 78 | |||
| 79 | (% class="box infomessage" %) | ||
| 80 | ((( | ||
| 81 | (% style="text-align: center;" %) | ||
| 82 | **Pour avoir la documentation détaillée et complète de la solution technique, | ||
| 83 | merci d'envoyer un mail à [[operation@nuabee.fr>>mailto:operation@nuabee.fr]]** | ||
| 84 | ))) | ||
| 85 | |||
| 86 |