Déploiements à l'échelle mondiale

Les déploiements à grande échelle de GO-Global vont souvent bien au-delà des hôtes et des gestionnaires de ferme. Dans les environnements d'entreprise, ils fonctionnent généralement avec de nombreux systèmes de soutien conçus pour améliorer les performances, la fiabilité et la sécurité. Ces systèmes - y compris les pare-feu, les équilibreurs de charge, les pare-feu d'application web (WAF), les proxys inversés et les outils de surveillance - garantissent que les applications GO-Global restent accessibles, résilientes et conformes aux normes de l'organisation.

Cet article fournit des conseils détaillés sur la configuration de GO-Global pour fonctionner efficacement au sein d'infrastructures informatiques complexes qui incluent de tels composants. Il explique comment GO-Global interagit avec chaque système, souligne les meilleures pratiques de configuration, et met en évidence les considérations clés pour les administrateurs qui gèrent des déploiements à grande échelle ou basés sur le cloud.

‍

Pare-feu périphérique

Lorsqu'un déploiement de GO-Global est accessible depuis l'internet, un pare-feu périmétrique est généralement la première ligne de défense contre les intrusions. Les pare-feu périmétriques sont généralement configurés pour autoriser les connexions entrantes sur le port TCP 443, qui est le port standard pour le trafic HTTPS/TLS sécurisé.

Puisque le port 443 est le port standard pour le trafic sécurisé, et puisque c'est le port qui est ouvert sur la plupart des pare-feu d'entreprise (client), les clients de GO-Global qui se connectent sur Internet sont généralement configurés pour se connecter au port 443 au lieu du port standard de GO-Global, 491. Cela se fait soit en ajoutant le port dans l'URL (par exemple, &port=443) ou en spécifiant le port dans la page logon.html de GO-Global.

Pare-feu pour applications web (WAF)

Un pare-feu d'application web (WAF) analyse les requêtes HTTP entrantes afin d'identifier et de bloquer les requêtes malveillantes. Les WAF peuvent également acheminer le trafic vers différents serveurs dorsaux sur la base des informations contenues dans les requêtes HTTP, mais ce n'est pas leur fonction première. Leur fonction première est d'assurer la sécurité et la protection contre les attaques telles que les attaques par déni de service distribué (DDoS).

Parmi les exemples de WAF, citons Cloudflare WAF, AWS WAF (Amazon Web Services), Azure Web Application Firewall, F5 Advanced WAF, Imperva WAF, Akamai Kona Site Defender, Fortinet FortiWeb, Barracuda WAF et Radware WAF.

Pour analyser le trafic HTTPS, les WAFs doivent terminer le TLS afin de pouvoir décrypter les requêtes. Lorsque TLS est terminé par un WAF, le paramètretls de GO-Global doit être ajouté à l'URL du client ou doit être spécifié dans la page logon.html de GO-Global.

Une autre considération pour le trafic de GO-Global est que les WAFs ne peuvent pas analyser le protocole RXP propriétaire de GO-Global. Par conséquent, lorsque la communication entre un client et un hôte de GO-Global passe par un WAF, elle doit être enveloppée dans des requêtes HTTP en configurant GO-Global pour qu'il utilise une Websocket, ou les fonctions d'analyse de données du WAF doivent être désactivées pour le trafic de GO-Global.  

Tous les clients GO-Global version 6.3.3 et ultérieures supportent les WebSockets. Dans les versions 6.3.2 et antérieures de GO-Global, cependant, seule l'application Web de GO-Global supporte les WebSockets. AppController, le client natif de GO-Global, ne supporte pas les WebSockets dans les versions 6.3.2 et antérieures.

Si AppController version 6.3.2 ou antérieure est utilisé avec un WAF, l'environnement doit être configuré pour que le WAF n'inspecte pas le trafic d'AppController. Cela peut être fait, par exemple, en fournissant un autre point de terminaison (adresse publique) pour les connexions d'AppController qui n'utilisent pas le WAF, ou en configurant AppController pour se connecter sur un port différent et en configurant le WAF pour passer le trafic sur ce port sans l'inspecter.

Proxy inversé

Comme les WAF, les reverse proxies analysent les requêtes HTTP entrantes. Les proxys inversés disposent de certaines fonctions de sécurité, mais contrairement aux WAF, leur fonction principale est la gestion du trafic, et non la sécurité. Par exemple, les serveurs mandataires inversés sont souvent utilisés lorsque plusieurs applications et services web sont fournis à partir du même point d'accès public. Ils acheminent les demandes entrantes pour différentes applications vers leurs serveurs d'application respectifs. Ils peuvent également être utilisés comme équilibreur de charge pour les hôtes de la ferme GO-Global.

Nginx, Apache HTTP Server, HAProxy, Traefik et Cloudflare sont des exemples de mandataires inverses. L'Application Load Balancer d'AWS et l'Azure Application Gateway ont diverses fonctions, dont l'une est de servir de proxy inverse.

Comme les WAFs, les reverse proxies doivent terminer le TLS afin de pouvoir analyser les requêtes HTTP entrantes. Comme pour les WAFs, lorsque TLS est terminé par un proxy inverse, le paramètretls de GO-Global doit être ajouté à l'URL du client ou doit être spécifié dans la page logon.html de GO-Global.

Comme les WAFs, les reverse proxies ne peuvent pas analyser le RapidX Protocol (RXP), propriété de GO-Global. Par conséquent, comme avec un WAF, lorsque la communication entre un client et un hôte de GO-Global passe par un proxy inverse, elle doit être soit enveloppée dans des requêtes HTTP en configurant GO-Global pour utiliser une WebSocket, soit les fonctions d'analyse de données du proxy inverse doivent être désactivées pour le trafic de GO-Global.  

Et comme avec un WAF, si AppController version 6.3.2 ou antérieure est utilisé avec un reverse proxy, l'environnement doit être configuré pour que le WAF n'inspecte pas le trafic d'AppController. Cela peut être fait, par exemple, en fournissant un autre point de terminaison (adresse publique) pour les connexions d'AppController qui n'utilisent pas le proxy inverse, ou en configurant AppController pour se connecter sur un port différent et en configurant le proxy inverse pour passer le trafic sur ce port sans l'inspecter.

Serveur Web

Les hôtes de GO-Global ont un serveur web intégré qui peut héberger l'application web de GO-Global et ses fichiers HTML et JavaScript. Lorsque le serveur web intégré de GO-Global est utilisé, les requêtes HTTP pour les fichiers web de GO-Global sont transmises aux hôtes de la ferme GO-Global sur le réseau interne.

Dans les déploiements Internet, cependant, l'hébergement des fichiers web de GO-Global sur un serveur web tiers situé dans la zone démilitarisée présente des avantages en termes de sécurité. Parmi les exemples de serveurs web tiers, on peut citer Apache HTTP Server, Nginx et Microsoft IIS (Internet Information Services).

Lorsqu'un serveur web tiers est utilisé, l'application Web de GO-Global et les fichiers associés doivent être installés sur le serveur web, soit via le programme d'installation de Host, soit en copiant le contenu du répertoire Web de GO-Global sur le serveur web.

Alors que la plupart des serveurs web tiers ont une fonctionnalité pour gérer les connexions WebSocket, les connexions WebSocket sont généralement gérées par un équilibreur de charge dédié ou un proxy inverse. Les administrateurs peuvent configurer les WAF et les proxy inversés pour acheminer les requêtes HTTP de GO-Global vers un serveur web et pour acheminer les connexions WebSocket vers les hôtes de la ferme GO-Global ou vers un équilibreur de charge.

Alternativement, lorsqu'un WAF ou un proxy inverse n'est pas utilisé, les administrateurs peuvent créer un point de terminaison différent (adresse ou port) pour les connexions WebSocket de GO-Global et spécifier ce point de terminaison via les paramètres d'hôte et/ou de port dans l'URL du client ou la page logon.html de GO-Global.

Équilibreur de charge du réseau

Lorsque plus d'un hôte de la ferme est nécessaire, un équilibreur de charge est requis pour distribuer les connexions des utilisateurs entre les hôtes. L'équilibreur de charge peut être un proxy inverse ou un équilibreur de charge réseau.

Dans les environnements où plusieurs applications sont accessibles via un seul point d'extrémité Internet, le pare-feu périmétrique transmet généralement les connexions à un proxy inverse (éventuellement via un WAF). Le proxy inverse peut alors soit transmettre les connexions directement aux hôtes de la ferme (en équilibrant la charge), soit les transmettre indirectement aux hôtes par l'intermédiaire d'un équilibreur de charge réseau.  

Alternativement, dans les environnements où GO-Global est la seule application accessible via le point d'extrémité Internet, le pare-feu du périmètre peut transmettre les connexions sur le port 443 directement à un équilibreur de charge du réseau. De là, l'équilibreur de charge sélectionne un hôte de la ferme et transmet la connexion à l'hôte de la ferme sur le port spécifié dans la console d'administration.

Contrairement aux proxys inversés, les équilibreurs de charge réseau n'inspectent pas le trafic et ne l'acheminent pas en fonction du contenu des données. Ils acheminent généralement le trafic en fonction de variables telles que le port de destination et l'adresse IP source. HAProxy, Azure load balancer et AWS Network Load Balancer sont des exemples d'équilibreurs de charge qui peuvent fonctionner au niveau 4 et acheminer les connexions TCP (TLS est terminé sur les hôtes de GO-Global).

Certains équilibreurs de charge de réseau peuvent terminer TLS à l'équilibreur de charge. Si l'équilibreur de charge est configuré pour terminer TLS, le paramètretls de GO-Global doit être ajouté à l'URL du client, ou il doit être spécifié dans la page logon.html de GO-Global.

Lorsqu'un équilibreur de charge met fin au protocole TLS, il peut éventuellement recrypter les données qu'il transmet aux hôtes de la ferme. Si les hôtes de la ferme sont configurés pour utiliser le protocole TLS, l'équilibreur de charge doit être configuré pour recrypter les données qu'il envoie aux hôtes de la ferme. Inversement, si l'équilibreur de charge ne recrypte pas les données, le protocole de GO-Global doit être réglé sur TCP et le cryptage doit être réglé sur Aucun.

Lorsqu'un équilibreur de charge réseau ne met pas fin au protocole TLS, il transmet les données aux hôtes de la ferme sans les décrypter et les recrypter. Dans cette configuration, le protocole TLS doit être activé sur les hôtes de la ferme et le paramètretls ne doit pas être spécifié dans l'URL du client ou dans la page logon.html.  

Pare-feu dorsal

Un pare-feu dorsal peut être utilisé pour limiter l'accès aux hôtes de la ferme à des systèmes frontaux spécifiques. Par exemple, si des proxys inversés sont utilisés pour acheminer les connexions vers les serveurs de la ferme, un pare-feu dorsal peut être configuré pour n'autoriser que les proxys inversés à se connecter aux serveurs de la ferme. Dans cet exemple, le pare-feu dorsal doit être configuré pour autoriser les serveurs mandataires inversés à se connecter aux serveurs de la ferme sur le port spécifié dans la console d'administration sous Outils | Options de l'hôte | Sécurité | Port (491, par défaut), et le trafic doit être autorisé dans les deux sens.

Si les applications exécutées sur les hôtes de la ferme doivent accéder à l'internet, le pare-feu du back-end doit être configuré de manière à autoriser cet accès.

Les hôtes de ferme de GO-Global n'ont pas besoin d'un accès à l'internet. Si, cependant, GO-Global est activé en utilisant une licence cloud, l'APS sur les Farm Managers doit être capable de se connecter à portal.graphon.com et cloud.graphon.com sur le port 443.

Contrôleur de domaine

Dans la majorité des déploiements, les hôtes de la ferme sont membres d'un domaine Microsoft Active Directory (AD). Dans cet environnement, il est essentiel que les hôtes de la ferme maintiennent la communication avec leurs contrôleurs de domaine. Cette connectivité leur permet d'authentifier les comptes, de récupérer les informations et les paramètres des utilisateurs, de charger les profils d'itinérance et d'appliquer les stratégies de groupe. Dans les déploiements d'OpenID Connect, les clients doivent souvent configurer la délégation restreinte sur les objets informatiques AD des hôtes de la ferme.  

Administration Pare-feu

Un pare-feu d'administration peut être utilisé pour limiter la capacité des utilisateurs à accéder aux systèmes d'administration tels que les contrôleurs de domaine et les gestionnaires de ferme à partir des hôtes de ferme. Par exemple, un pare-feu d'administration peut être utilisé pour empêcher les utilisateurs qui exécutent des applications sur les hôtes de la ferme de tenter de se connecter aux contrôleurs de domaine et aux gestionnaires de ferme à l'aide de Remote Desktop.

Si un pare-feu administratif existe entre les hôtes de la ferme et les gestionnaires de la ferme, le pare-feu doit permettre aux hôtes de la ferme de se connecter aux gestionnaires de la ferme sur le port spécifié dans la console d'administration sous Outils | Options de l'hôte | Sécurité | Port (491, par défaut), et le trafic doit être autorisé dans les deux sens.

Si un pare-feu d'administration existe entre les hôtes de la ferme et les contrôleurs de domaine, le pare-feu doit être configuré pour toutes les communications sur les ports que Windows utilise pour communiquer entre les contrôleurs de domaine et les membres du domaine. Reportez-vous à la documentation de Microsoft pour obtenir ces informations.

Fournisseur d'identité

Lorsque l'authentification OpenID Connect est utilisée, les hôtes de la ferme doivent être en mesure d'ouvrir des connexions au fournisseur d'identité via l'URL du jeton spécifiée dans la console d'administration sous Outils | Options de l'hôte | Authentification | Configurer les paramètres OpenID Connect | URL du jeton.

Infrastructure de mise à l'échelle automatique

Les fournisseurs de services en nuage (CSP) tels que Amazon Web Services (AWS), Microsoft Azure, Oracle Cloud et Google Cloud (GCP) proposent des fonctions qui peuvent être utilisées pour démarrer et arrêter automatiquement les hôtes de la ferme en fonction de l'augmentation et de la diminution de la charge. Lorsqu'ils utilisent ces fonctions, les administrateurs créent généralement une image de base ("gold") d'un hôte de la ferme qui peut être répliquée selon les besoins pour prendre en charge les utilisateurs qui se connectent au système.

Les images des hôtes de la ferme ont GO-Global installé et configuré, ainsi que toutes les applications que les utilisateurs exécuteront sur les hôtes de la ferme. Les administrateurs automatisent généralement la construction de ces images en utilisant une combinaison de scripts PowerShell et de code d'infrastructure développé à l'aide d'un outil Infrastructure as Code (IaC) tel que Terraform.

Voir Automatiser la configuration de GO-Global pour savoir comment GO-Global peut être installé et configuré par programme.

Les images des hôtes de la ferme contiennent généralement les adresses de leur gestionnaire de ferme et de leur gestionnaire de ferme de basculement. Cela facilite la mise à l'échelle (l'ajout d'hôtes à une ferme). Lorsque de nouvelles instances d'hôtes sont démarrées, elles se connectent automatiquement au gestionnaire de ferme, et la fonction de mise à l'échelle automatique du CSP se charge généralement d'ajouter la nouvelle instance au groupe cible de l'équilibreur de charge.

Les hôtes de ferme obtiennent des licences auprès de leurs gestionnaires de ferme, de sorte qu'aucune configuration de licence n'est requise au démarrage d'une nouvelle instance d'hôte de ferme. Lorsque des sessions démarrent sur un hôte de ferme, ce dernier récupère des licences auprès du gestionnaire de ferme. En général, un siège est consommé pour chaque session simultanée.

La mise à l'échelle (suppression des hôtes d'une ferme) est généralement un peu plus compliquée que la mise à l'échelle. En effet, il est généralement souhaitable d'attendre que toutes les sessions s'exécutant sur une instance d'hôte de ferme aient été fermées avant de l'arrêter. La section Déconnexion d'un hôte de ferme décrit comment procéder.

Lorsqu'un hôte de la ferme s'arrête, la connexion de l'hôte au gestionnaire de la ferme est interrompue. Lorsque cela se produit, le gestionnaire de ferme libère automatiquement tous les sièges qui étaient utilisés sur l'hôte. Il n'y a donc aucun risque que des sièges soient consommés par des hôtes qui n'existent plus. Il n'y a rien à faire pour effacer les hôtes qui ont été arrêtés ; cela se fait automatiquement.

Avec GO-Global, la meilleure métrique pour contrôler l'auto-scaling est généralement le nombre de sessions en cours. Le nombre de sessions en cours d'exécution sur un hôte ou une ferme peut être obtenu, respectivement à partir d'un hôte de ferme ou d'un gestionnaire de ferme via les compteurs de performance de GO-Global ou via la fonction PowerShell Get-GGSessions de GO-Global.

Zones de disponibilité et régions

Pour assurer une haute disponibilité, les fournisseurs de services en nuage (CSP) prennent en charge les déploiements multi-centres de données par le biais de zones de disponibilité et de régions. Les zones de disponibilité sont constituées d'un ou de plusieurs centres de données situés dans la même région géographique. Les régions CSP sont des zones géographiques contenant une ou plusieurs zones de disponibilité. Les domaines de défaillance CSP, également connus sous le nom de groupes de disponibilité, sont des ressources à tolérance de panne situées dans des parties physiquement séparées d'un seul centre de données.

GO-Global prend en charge les déploiements dans plusieurs zones de disponibilité. Les zones de disponibilité dans lesquelles GO-Global est déployé peuvent être situées dans la même région CSP ou dans des régions CSP différentes.

Au sein d'une région CSP, GO-Global est généralement déployé sur au moins deux zones de disponibilité, avec le gestionnaire de ferme primaire fonctionnant dans une zone de disponibilité, et le gestionnaire de ferme de basculement fonctionnant dans une zone de disponibilité différente. Les hôtes de la ferme peuvent fonctionner dans n'importe quel nombre de zones de disponibilité au sein de la région, mais ils doivent être en mesure de se connecter à la fois au gestionnaire de ferme principal et au gestionnaire de ferme de basculement.

Lorsqu'une haute disponibilité entre les régions du CSP est nécessaire, ou lorsque les utilisateurs sont situés dans le monde entier, GO-Global peut être déployé dans plusieurs régions du CSP avec un équilibreur de charge DNS tel que Route 53 d'AWS qui achemine les connexions des clients à travers les régions. L'équilibreur de charge DNS peut alors être configuré pour prendre en charge le basculement actif-actif ou actif-passif, selon les besoins.

Outils de surveillance et d'observabilité

Les outils de surveillance et d'observabilité sont utilisés pour surveiller la santé des déploiements de GO-Global et lancer des alertes lorsque des problèmes surviennent. GO-Global fournit plusieurs caractéristiques que ces outils peuvent utiliser pour surveiller GO-Global.

La plupart des outils d'observabilité disposent de fonctions permettant d'ingérer des fichiers journaux. Les fichiers journaux de GO-Global sont au format HTML, par défaut, ce que la plupart des outils d'observabilité ne supportent pas. Par conséquent, GO-Global doit généralement être configuré pour enregistrer ses fichiers journaux au format texte lorsque ses journaux seront ingérés par un outil d'observabilité.

En plus de ses fichiers journaux, GO-Global enregistre des événements dans le journal de l'application Windows. Les événements que GO-Global enregistre dans le journal de l'application Windows comprennent les démarrages et les arrêts de session, les ouvertures de session des utilisateurs et les démarrages et arrêts d'application.

Pour prendre en charge la surveillance des hôtes de ferme et des gestionnaires de ferme, GO-Global fournit une requête healthCheck. La requête healthCheck peut être utilisée pour déterminer si le service de publication d'applications est en cours d'exécution sur un hôte de ferme ou un gestionnaire de ferme et, en option, si le système est en mesure de créer une session. Les équilibreurs de charge, par exemple, peuvent utiliser la requête healthCheck pour vérifier l'état de santé des hôtes de ferme de leur groupe cible.
‍

Les systèmes qui envoient des demandes de HealthCheck doivent être enregistrés auprès de chaque hôte de ferme ou gestionnaire de ferme cible. Plus précisément, l'adresse IP du système qui envoie la requête doit être répertoriée au format CIDR dans la propriété APIWhiteList du fichier HostProperties.xml du système cible.

En plus de ces outils, l'API PowerShell de GO-Global peut être utilisée pour obtenir des informations détaillées sur l'exécution à partir des hôtes et des gestionnaires de ferme. Par exemple, la fonction Get-GGSessions renvoie des informations sur les sessions en cours d'exécution sur un hôte ou un gestionnaire de ferme.

Conclusion

Le déploiement de GO-Global dans un environnement à grande échelle ou intégré dans le nuage nécessite une coordination minutieuse entre plusieurs composants d'infrastructure. En configurant correctement des éléments tels que les pare-feu, les équilibreurs de charge, les proxies inversés et les systèmes de surveillance, les administrateurs peuvent obtenir un environnement GO-Global sécurisé, évolutif et performant qui offre une expérience utilisateur transparente.

Qu'il soit mis en œuvre sur site, dans le nuage ou dans des architectures hybrides, les principes décrits dans cet article garantissent que GO-Global fonctionne efficacement au sein des réseaux d'entreprise modernes - en maintenant la fiabilité, la flexibilité et le contrôle à chaque niveau de déploiement.

Êtes-vous un ISV qui explore la livraison d'applications basées sur le nuage ? Contactez-nous pour savoir comment GO-Global peut vous aider à rationaliser l'accès aux logiciels pour vos utilisateurs finaux. Ou téléchargez un essai gratuit pour le tester vous-même.