Chaque système informatique a un objectif. Pour atteindre cet objectif, il doit être disponible. Certains systèmes informatiques sont essentiels pour une entreprise et, par conséquent, doivent être hautement disponibles, c’est-à-dire tolérer un niveau minimal (voire aucun niveau) d’indisponibilité partielle ou totale. D’autres systèmes, moins cruciaux, autorisent un certain nombre de temps d’arrêt programmés ou non programmés. Les utilisateurs peuvent se rabattre sur d’autres processus ou simplement attendre que le système soit à nouveau disponible. De nombreux systèmes se situent quelque part entre ces deux extrêmes.
La haute disponibilité (HA) est une approche de conception qui permet à un système de répondre à un niveau prédéterminé de performance opérationnelle sur une période spécifique. Un système hautement disponible offre aux clients une technologie et un environnement d’une grande fiabilité. Il permet de répondre ou de dépasser leurs exigences commerciales en matière de prestation de services et de fonctionner au niveau de qualité attendu.
Bien qu’elle soit liée à la récupération d’urgence (DR), la haute disponibilité est un concept distinct. En général, la haute disponibilité vise à éviter les temps d’arrêt imprévus pour la prestation de services, alors que la récupération d’urgence se concentre sur la conservation des données et des ressources nécessaires pour restaurer un système à un état acceptable après un sinistre. Lorsque des plans de récupération d’urgence sont mis en œuvre, il est courant que la prestation de services soit interrompue jusqu’à ce que le système soit rétabli. Pour plus d’informations, voir Sauvegardes et récupération d’urgence.
La redondance géographique est un autre terme communément employé dans ce domaine. L’objectif du point de vue conceptuel est d’avoir une application ou un système capable de survivre à une panne complète du centre de données, en disposant de systèmes supplémentaires ou d’un système de sauvegarde à un autre emplacement géographique. Cette approche permet de se protéger contre les catastrophes naturelles, les pannes de courant ou tout autre événement susceptible de nuire à la disponibilité du centre de données.
De nombreux architectes utilisent un ensemble commun de termes pour désigner et décrire en détail une approche de la haute disponibilité au niveau du système ou des composants. Les termes les plus couramment utilisés dans ce domaine sont les suivants :
L’une des mesures permettant d’évaluer la disponibilité est le temps de fonctionnement, qui correspond généralement au pourcentage de temps pendant lequel un système a été « disponible » sur une certaine période. La notion de disponibilité reste subjective et doit être établie dès le début du processus de conception du système afin de trouver un consensus sur cet objectif. Un niveau de disponibilité souhaité est souvent défini comme un temps de fonctionnement visé, souvent exprimé sous forme d’une série de 9. Par exemple :
Les objectifs de disponibilité peuvent être formalisés sous la forme d’un contrat de niveau de service (SLA) entre les utilisateurs d’un système et l’organisation qui exploite ce système. Souvent, les SLA incluent d’autres indicateurs liés aux performances au-delà des objectifs de disponibilité purs (temps de réponse attendus, par exemple) et peuvent prévoir des pénalités pour atteindre ces objectifs s’il existe une relation fournisseur-client. Les SLA internes sont tout aussi importants, bien qu’ils n’incluent généralement pas les critères de pénalité et de création de rapport d’un SLA destiné aux clients.
Une autre approche adoptée par les organisations en matière de disponibilité consiste à établir des niveaux de criticité pour les systèmes dont elles ont la charge. Ces niveaux de criticité peuvent aller du niveau non essentiel au niveau fondamental, en fonction de l’impact qu’une panne peut avoir sur une organisation. L’expérience utilisateur, les finances, la réputation et l’impact réglementaire peuvent être pris en considération. Chaque niveau de criticité peut avoir une définition de SLA cible différente. Certaines organisations peuvent faire référence à un certain système comme étant de « niveau 1 » ou « critique pour l’entreprise », tandis que d’autres systèmes sont considérés comme étant de « niveau 2 » ou moins critiques pour l’entreprise, ce qui suppose moins de contraintes ou des configurations différentes.
La conception et la création d’un système pour répondre à un niveau de disponibilité prédéfini nécessitent une approche holistique qui prend en compte de nombreux aspects ou domaines différents :
La mise en place d’un système capable de répondre à des exigences de disponibilité plus élevées nécessite généralement un investissement initial et continu important en temps et en ressources, par rapport à un système de base qui ne répond qu’à un niveau standard de disponibilité. Cependant, la haute disponibilité n’est pas une question de tout ou rien. Il est souvent utile de se demander s’il existe des sous-systèmes pour lesquels les objectifs de disponibilité peuvent être assouplis sans affecter, de manière significative, la valeur commerciale d’un système informatique.
Lorsque vous concevez un système hautement disponible, vous partez rarement d’une page blanche. Dans la plupart des cas, l’infrastructure informatique actuelle, les politiques, l’expertise et les préférences d’une organisation détermineront le cadre global qu’un système SIG d’entreprise doit prendre en charge. Il en va de même pour les attentes en matière de temps de fonctionnement ou de disponibilité des systèmes auxiliaires et les composants informatiques permettant d’atteindre un niveau élevé de disponibilité. Chaque décision en matière de conception peut donner lieu à une autre décision. Le processus de conception peut être considéré, au final, comme un ensemble de contraintes de conception qui permettent d’atteindre le compromis idéal : le système répond aux exigences globales, respecte les normes déjà définies par l’organisation et garantit l’équilibre entre les coûts, la facilité de gestion et différents autres facteurs.
Souvent, les contraintes de conception entrent dans les catégories suivantes :
De même, les services informatiques peuvent fortement limiter l’éventail des choix en matière d’infrastructure (marques et modèles spécifiques pour les équipements, les couches de virtualisation, les systèmes de stockage, les équilibreurs de charge, les proxys inverses, etc.).
L’exploitation d’une infrastructure commerciale en tant que service (IaaS) basée sur le Cloud, qu’il s’agisse de machines virtuelles ou de clusters Kubernetes, limite également vos options.
En ce qui concerne ArcGIS Enterprise, la haute disponibilité fait référence aux mesures qui accroissent la disponibilité d’un seul déploiement d’ArcGIS Enterprise. Les déploiements répliqués, normalement répartis géographiquement dans un autre centre de données ou dans une autre région du stockage Cloud, offrent une fonction de récupération d’urgence. Pour plus d’informations, voir Haute disponibilité dans ArcGIS Enterprise.
ArcGIS Enterprise offre des niveaux de disponibilité plus élevés en associant plusieurs machines dans différentes configurations. Les composants d’ArcGIS Enterprise utilisent différentes approches pour atteindre la haute disponibilité :
Un site de portail à haute disponibilité (HA) se compose de deux serveurs qui sont regroupés pour créer le site HA. Chaque serveur est entièrement redondant, mais le système conserve une machine en tant que nœud principal et l’autre machine en tant que nœud de secours. En cas de défaillance de la machine principale, la machine de secours détecte le dysfonctionnement et assume le rôle de machine principale.
Au niveau du serveur Web, le système est actif-actif, car chaque nœud de portail est capable de traiter les requêtes entrantes et les index de recherche sont synchronisés sur les deux systèmes. Cependant, un seul nœud gère les changements d’état. Les mises à jour, les invitations de membres et les configurations sont enregistrées dans la base de données du portail, de sorte que le système global est considéré comme actif-passif.
Un portail à haute disponibilité nécessite également un équilibreur de charge pour répartir les requêtes entre les deux nœuds, généralement de manière circulaire (mode tourniquet ou round robin). Le nœud principal et le nœud de secours partagent leur état grâce à la communication entre les machines via les ports et la synchronisation de base de données. Ils se basent également sur le stockage de fichiers partagé pour le répertoire de contenu du portail, qui peut être un partage de fichiers NFS, un partage de fichiers UNC ou un stockage d’objets natif du Cloud.
Découvrez-en davantage sur la configuration d’un déploiement Portal for ArcGIS à haute disponibilité.
Un site de serveur SIG hautement disponible se compose d’au moins deux machines entièrement redondantes. Celles-ci sont regroupées dans un « site » ArcGIS Server où les charges de travail sont équilibrées en charge sur tous les nœuds, ce qui correspond à une configuration de type actif-actif. Un serveur SIG hautement disponible nécessite également un équilibreur de charge pour transférer les requêtes vers les machines membres. , en suivant généralement une approche circulaire (round robin), bien que le trafic Web puisse également être acheminé en appliquant le modèle principal-secours.
Les machines d’un site partagent leur état principalement par le biais d’un emplacement de stockage partagé pour les répertoires du serveur et le magasin de configuration (généralement un partage de fichiers de type NFS ou UNC). Dans le cas des systèmes Cloud, des options Cloud natives sont également disponibles pour le magasin de configuration, telles que le stockage DynamoDB et S3 dans AWS ou le stockage Azure Files dans Microsoft Azure.
note « Remarque » Il convient de noter que certains rôles de serveur SIG spécialisés, tels que GeoEvent Server, ne peuvent pas être configurés pour s’exécuter dans un site à plusieurs machines. Par conséquent, des considérations particulières s’appliquent pour atteindre des niveaux de disponibilité plus élevés pour ces rôles de serveur SIG.
Pour savoir comment effectuer un déploiement à haute disponibilité d’ArcGIS Server, voir Configurer des sites ArcGIS Server à plusieurs machines. Vous trouverez également des informations utiles dans la section Déploiement sur une seule machine haute disponibilité (actif-actif).
L’adaptateur Web Adaptor peut être déployé de manière redondante sur deux machines ou plus, chaque instance étant entièrement redondante dans une configuration de type actif-actif. Cette configuration nécessite un équilibreur de charge front-end (vers lequel sont adressées les requêtes des clients) qui répartit les requêtes sur les deux hôtes de l’adaptateur Web Adaptor. D’autres ressources sont disponibles dans la documentation.
Data store relationnel : un data store relationnel à haute disponibilité est constitué d’exactement deux instances entièrement redondantes dans une configuration d’agrégat actif-actif. En cas de défaillance de la machine de data store principale, la machine de secours détecte le dysfonctionnement et assume le rôle de machine principale, ce qui permet aux clients de continuer à utiliser les services d’entités hébergés sans interruption.
Graph data store : un graph data store à haute disponibilité est constitué d’exactement trois instances entièrement redondantes dans une configuration d’agrégat actif-actif.
Object store : la haute disponibilité de l’object store est prise en charge en mode cluster. Cette architecture nécessite au moins trois machines. En mode cluster, les données sont répliquées sur les trois machines afin que le Data store reste disponible en cas de panne d’une seule machine.
Spatiotemporal Big Data Store : ce type de Data store prend également en charge le mode cluster. Les clusters doivent contenir un nombre impair de machines (ce qui est nécessaire pour trouver entre les membres) ainsi qu’un minimum de trois machines. Ces configurations sont toutes des configurations de haute disponibilité de type actif-actif.
La rubrique de la documentation Configurer des data stores gérés à haute disponibilité fournit des conseils, des étapes et des recommandations supplémentaires.
La disponibilité des ressources de base de données est un domaine spécialisé de l’architecture. Chaque offre de base de données donne accès à de nombreuses options spécifiques au fournisseur, y compris des modèles de configuration actif-actif et actif-passif. En général, ArcGIS peut se connecter à ces configurations lorsque le processus d’inscription des données (par l’intermédiaire duquel les services sont consultés ou publiés) utilise un alias DNS ou une adresse IP flexible. Ceux-ci sont toujours accessibles à partir d’ArcGIS, mais peuvent pointer vers une autre base de données back-end en cas de panne du système principal. Dans ce scénario, les composants ArcGIS ne sont pas conscients de la modification de la base de données back-end et continuent de fonctionner comme prévu, en supposant que les mêmes informations d’identification, schéma et lignes sont disponibles.
Pour faire des choix éclairés et efficaces en matière de haute disponibilité, tenez compte des recommandations de conception suivantes :