Zones

Les zones vous permettent de contrôler le placement des fragments. Les zones sont des regroupements de serveurs physiques, définis par l'utilisateur. Exemples des différents types de zones : serveurs lames différents, châssis de serveurs lames, étages d'un bâtiment, bâtiments ou différents emplacements géographiques dans un environnement à plusieurs centres de données. Un environnement virtualisé dans lequel un grand nombre d'instances de serveur, ayant une adresse IP unique, s'exécutent sur un même serveur physique est un autre cas d'utilisation.

Zones définies entre les centres de données

L'exemple de cas d'utilisation classique des zones implique aux moins deux centres de données qui se trouvent dans des lieux géographiques différents. Les centres de données dispersés étendent la grille de données à différents emplacements pour la reprise d'un centre de données défaillant. Par exemple, vous souhaitez vous assurer que vous disposez d'un ensemble complet de fragments de réplique asynchrones pour votre grille de données dans un centre de données distant. Avec cette stratégie, vous pouvez restaurer le centre de données local détaillant en toute transparence, sans perte de données. Les centres de données eux-mêmes utilisent des réseaux haut débit à faible latence. Toutefois, la communication entre un centre de données et un autre a une latence plus élevée. Les répliques synchrones sont utilisées dans chaque centre de données où la faible latence minimise l'impact de la réplication sur les temps de réponse. L'utilisation de la réplication asynchrone réduit l'impact sur les temps de réponse. La distance géographique maintient la disponibilité en cas de défaillance du centre de données local.

Dans l'exemple suivant, les fragments primaires pour la zone de Chicago ont des répliques dans la zone London. Les fragments primaires de la zone London ont des répliques dans la zone de Chicago.

Figure 1. Segments principaux et répliques dans les zones
Segments principaux et répliques dans les zones

Trois paramètres de configuration dans eXtreme Scale contrôlent le placement des fragments :

  • Définition du fichier de déploiement
  • Regroupement de conteneurs
  • Définition de règles

Les sections suivantes expliquent les différentes options, de la moins complexe à la plus complexe.

Désactivation du mode de développement

Dans le fichier XML de déploiement définissez developmentMode="false".

Cette étape simple active la règle de placement de fragment eXtreme Scale pour la première fois.

Pour plus d'informations sur les fichiers XML, voir Fichier XML du descripteur de la règle de déploiement.

Règle 1 : les fragments de la même partition sont placés dans des serveurs physiques distincts.

Prenons un exemple simple d'une grille de données avec un fragment de réplique. Avec cette stratégie, les fragments primaires et de réplique de chaque partition se trouvent sur différents serveurs physiques. Si un serveur physique unique tombe en panne, aucune donnée n'est perdue. Le fragment primaire ou le fragment de réplique de chaque partition se trouve sur différents serveurs physiques qui n'ont pas connu d'incident ou les deux se trouvent sur un autre serveur physique qui n'a pas connu d'incident.

La haute disponibilité et la grande simplicité de cette règle constituent la configuration la plus efficace pour tous les environnements de production. Dans la plupart des cas, l'application de cette règle est la seule étape requise pour contrôler efficacement le placement des fragments dans votre environnement.

En appliquant cette stratégie, un serveur physique est défini par une adresse IP. Les fragments sont placés dans des serveurs de conteneur. Les serveurs de conteneur ont une adresse IP, par exemple, le paramètre -listenerHost dans le script startOgServer. Plusieurs serveurs de conteneur peuvent avoir la même adresse IP.

Etant donné qu'un serveur physique possède plusieurs adresses IP, envisagez l'étape suivante pour renforcer la surveillance de votre environnement.

Définition de zones pour regrouper les serveurs de conteneur

Les serveurs de conteneur sont affectés à des zones avec le paramètre -zone sur le script startOgServer. Dans un environnement WebSphere Application Server, les zones sont définies via des groupes de noeuds avec un format de nom spécifique : ReplicationZone<Zone>. De cette façon, vous choisissez le nom et les membres de vos zones. Pour plus d'informations, voir Définition des zones des serveurs de conteneur.

Règle 2 : les fragments de la même partition sont placés dans des zones distinctes

Envisagez d'étendre l'exemple d'une grille de données avec un fragment de réplique en le déployant dans deux centres de données. Définissez chaque centre de données sous la forme d'une zone indépendante. Utilisez un nom de zone DC1 pour les serveurs de conteneur dans le premier centre de données pour la première fois, et DC2 pour les serveurs de conteneur dans le second centre de données. Avec cette stratégie, les fragments primaires et de réplique de chaque partition se trouvent dans des centres de données différents. Si un centre de données est défaillant les données sont perdues. Pour chaque partition, son fragment primaire ou de réplique se trouve dans l'autres centre de données.

Dans cette stratégie, vous pouvez contrôler le placement des fragments en définissant des zones. Vous choisissez votre limite logique ou physique ou regroupement d'intérêt. Ensuite, sélectionnez un nom de zone unique pour chaque groupe et démarrez les serveurs de conteneur dans chacune des zones avec le nom de la zone approprié. Ainsi, eXtreme Scale place les fragments pour que les fragments d'une même partition soient placés dans des zones distinctes.

Définition de règles de zone

Le meilleur niveau de contrôle sur le placement de fragment est obtenu à l'aide des règles de zone. Les règles de zone sont définies dans l'élément zoneMetadata du code XML du descripteur de stratégie de déploiement eXtreme Scale. Une règle de zone définit un ensemble de zones dans lesquels les fragments sont placés. Un élément shardMapping affecte un fragment à une règle de zone. L'attribut de fragment de l'élément shardMapping définit le type de fragment :
  • P spécifie le fragment primaire
  • S spécifie des fragments de réplique synchrones
  • A spécifie des fragments de réplique asynchrones.
Si plusieurs répliques synchrones ou asynchrones existent, vous devez fournir des éléments shardMapping correspondant au type de fragment approprié. L'attribut exclusivePlacement de l'élément zoneRule détermine le placement des fragments dans la même partition dans les zones. Les valeurs de l'attribut exclusivePlacement sont :
  • true (un fragment ne peut pas être placé dans la même zone qu'un autre fragment de la même partition).

    A faire : Dans le cas " true ", vous devez disposer au minimum d'autant de zones dans la règle que de fragments qui l'utilisent. Dans ce cas, chaque fragment se trouve dans sa propre zone.

  • false (les fragments d'une même partition peuvent être placés dans la même zone).
Le paramètre par défaut est true.

Pour plus d'informations, voir Exemple : Définitions de zone dans le fichier XML de descripteur de stratégie de déploiement.

Cas d'utilisation étendu

Voici différents cas d'utilisation pour les stratégies de placement des fragments :

Mise à niveau cycliques

Supposons que vous voulez appliquer des mises à niveau cycliques aux serveurs physiques, y compris la maintenance qui implique de redémarrer le déploiement. Dans cet exemple, nous supposons que vous disposez d'une grille de données répartie sur 20 serveurs physiques, définie avec une réplique synchrone. Vous voulez arrêtez 10 des serveurs physiques simultanément pour la maintenance.

Lorsque vous arrêtez des groupes de 10 serveurs physiques, aucune partition n'a ses fragments primaire et de réplique sur les serveurs que vous arrêtez. Autrement, vous perdez les données de la partition.

La solution la plus simple consiste à définir une troisième zone. Au lieu d'utiliser deux zones contenant chacune 10 serveurs physiques, utilisez-en trois, deux avec sept serveurs physiques et une avec six serveurs. En répartissant les données dans plusieurs zones vous améliorez la reprise en ligne pour la disponibilité.

Au lieu de définir une autre zone, l'autre approche consiste à ajouter une réplique.

Mise à niveau d'eXtreme Scale

Lorsque vous mettez à niveau le logiciel eXtreme Scale de manière cyclique avec des grilles de données qui contiennent des données actives, tenez comptes des points suivants. La version du logiciel de service de catalogue doit être supérieure ou égale à la version du logiciel serveur de conteneur. Mettez à niveau tous les serveurs de catalogue pour la première fois à l'aide d'une stratégie cyclique. Voir la rubrique Mise à jour des serveurs eXtreme Scale pour en savoir plus sur la mise à niveau du déploiement.

Modification du modèle de données

Une question connexe est la manière de modifier le modèle de données ou le schéma des objets qui sont stockés dans la grille de données sans entraîner d'indisponibilité. La modification du modèle de données en arrêtant la grille de données et en redémarrant avec les classes de modèles de données mises à jour dans le chemin d'accès aux classes du serveur de conteneur et en rechargeant la grille de données constituerait une gêne. Une autre solution consiste à lancer une nouvelle grille de données avec le nouveau schéma, copier les données de l'ancienne grille de données vers la nouvelle et fermer l'ancienne grille de données.

Chacun de ces processus génère des perturbations et entraîne un arrêt. Pour modifier le modèle de données sans interruption, stockez l'objet dans l'un des formats suivants :
  • Utilisation de XML comme valeur.
  • Utilisation d'un objet BLOB créé avec Google protobuf
  • Utilisation de JSON (JavaScript Object Notation)
Ecrivez des sérialiseurs pour remplacer un objet Java (POJO) par l'un des ces formats aisément sur le client. Les modifications de schéma deviennent plus simples.

Virtualisation

L'informatique en nuage et la virtualisation sont des technologies émergentes qui connaissent un succès croissant. Par défaut, eXtreme Scale garantit que deux fragments de la même partition ne sont jamais placés à la même adresse IP comme indiqué dans la règle 1. Lorsque vous déployez sur des images virtuelles, telles que VMware, la plupart des instances de serveur, ayant chacune une adresse IP unique, peuvent être exécutées sur le même serveur physique. Pour que les répliques puissent être placées uniquement sur des serveurs physiques distincts, vous pouvez utiliser des zones pour résoudre le problème. Regroupez les serveurs physiques dans des zones et utilisez des règles de placement de zone pour maintenir les fragments primaire et de réplique dans des zones distinctes.

Zones pour les réseaux WAN (wide-area networks)

Vous voudrez peut-être déployer une grille de données eXtreme Scale unique dans des bâtiments ou centres de données avec des connexions réseau lentes. La lenteur accrue des connexions réseau entraîne la réduction de la bande passante et l'augmentation des temps d'attente pour les connexions. Dans ce mode, des partitions réseau sont plus susceptibles de se produire en raison de la congestion du réseau et d'autres facteurs.

Pour faire face à ces risques, le service de catalogue eXtreme Scale organise les serveurs de conteneur dans des groupes centraux qui échangent des signaux de présence pour détecter leur défaillance éventuelle. Ces principaux groupes ne couvrent pas les zones. Un responsable dans chaque groupe principal envoie les informations d'appartenance au service de catalogue. Le service de catalogue vérifie les défaillances signalées avant de répondre à des informations d'appartenance en envoyant un signal de présence au serveur de conteneur concerné. Si le service de catalogue identifie une fausse détection de défaillance, le service de catalogue n'effectue aucune action. La partition du groupe principal se rétablit rapidement. Le service de catalogue envoie également un signal de présence aux responsables de groupe principal régulièrement à une fréquence lente pour traiter le cas de l'isolement de groupe principal.