Haute disponibilité (HA)

IBM® watsonx.data utilise des régions multizones (MZR) sur les sites IBM Cloud et AWS pour assurer une haute disponibilité. Les différents composants de watsonx.data sont déployés en configuration Active-Active et Active-Only afin de garantir une disponibilité et une résilience élevées.

Active-active

Dans une configuration active-active, plusieurs instances d'un composant s'exécutent simultanément dans différentes zones de disponibilité (AZ). Ces instances sont équilibrées en termes de charge et peuvent traiter des demandes en parallèle.

Caractéristiques principales:

• Redondance - En cas de défaillance d'une instance ou d'un AZ, les autres continuent à servir le trafic sans interruption.
• Répartition de la charge - Le trafic est réparti entre toutes les instances actives, ce qui améliore les performances et réduit la latence.
• Basculement automatique - Aucune intervention manuelle n'est nécessaire; le système réachemine le trafic automatiquement.

Avantages:

• Haute tolérance aux pannes.
• Expérience transparente pour l'utilisateur en cas de défaillance d'une zone.
• Meilleure utilisation des ressources.

Sur watsonx.data, la plupart des composants sont déployés dans une configuration Active-Active avec des répliques dans plusieurs zones afin d'assurer une disponibilité continue. Par exemple, Metadata Services (MDS) dans le plan Entreprise.

Actif uniquement

Dans une configuration Active-Only, un composant ne fonctionne que dans une seule zone de disponibilité à la fois. En cas de défaillance de cette zone, le composant doit être redémarré ou redéployé dans une autre zone.

Caractéristiques principales:

• Une seule instance active par composant.
• Redémarrage automatique dans une nouvelle zone en cas d'échec.
• Léger retard lors du basculement en raison du temps de redémarrage.

Avantages:

• Une architecture plus simple.
• Réduction de la consommation de ressources.
• Résilience avec un bref temps d'arrêt pendant le basculement.

Dans watsonx.data, les composants à locataire unique sont déployés dans une configuration Active-Only. Ces composants à locataire unique, qui comprennent le moteur Presto et les composants du métastore, sont répartis stratégiquement sur trois AZ pour assurer la capacité et le basculement. Ces composants redémarrent dans une nouvelle zone en cas d'échec. Par exemple, les services de métadonnées (MDS) dans le plan Lite.

Dans les régions multizones (MZR), Presto et MDS sont répartis dans différentes zones.

Lorsqu'une seule zone de disponibilité tombe en panne dans une région MZR ou qu'une panne matérielle se produit dans une région, les charges de travail échouent automatiquement et redémarrent dans d'autres zones de cette région. Chaque instance watsonx.data est fournie avec un compartiment de métadonnées interrégional par défaut et un compartiment d'essai facultatif (10 Go). Les deux buckets sont activés avec IBM Cloud® Object Storage Versioning. Les données sont sauvegardées en activant la réplication vers un compte IBM Cloud Object Storage distinct. Cependant, pour tout godet externe que le client apporte dans l'instance watsonx.data, le client est responsable de ces sauvegardes.

Dans une catastrophe régionale, vous recevez un courrier électronique qui inclut toutes les étapes que vous devez suivre. Voir les responsabilités pour watsonx.data. Les composants à service exclusif fonctionnent sur un modèle "Actif uniquement", assurant un redémarrage immédiat sur les nouveaux noeuds qui fournissent le même service en cas de défaillance.

Les composants à service exclusif sont répartis de manière stratégique sur 3 zones de service afin d'améliorer la fiabilité. En cas de défaillance d'une zone de disponibilité, une capacité suffisante est garantie pour initier les services requis sur les zones de disponibilité disponibles. Cela réduit l'impact causé par une indisponibilité de la zone de disponibilité.

Responsabilités

Haute disponibilité au niveau de l'application

Les applications qui communiquent par le biais de réseaux et de services cloud sont sujettes à des pannes de connexion transitoires. Concevez vos applications pour relancer les connexions lorsqu'une perte temporaire de connectivité à votre déploiement ou à IBM Cloudprovoque des erreurs. Comme watsonx.data est un service géré, des mises à jour et une maintenance régulières sont effectuées dans le cadre des opérations normales. Une telle maintenance entraîne parfois une interruption temporaire du service.

Vos applications doivent être conçues pour gérer les interruptions temporaires de service, implémenter le traitement des erreurs en cas d'échec de commandes et appliquer une logique de relance pour récupération suite à une interruption temporaire.

Les codes d'erreur suivants peuvent être attendus lors des interruptions de service temporaires:

Si un noeud coordinateur Presto redémarre, que ce soit à des fins de maintenance ou en raison d'une défaillance du système, les applications doivent rétablir leur connexion avec le moteur Presto.

Une indisponibilité de plusieurs minutes ou des interruptions de connexion ne sont pas à prévoir. Ouvrez un ticket d'assistance avec des détails si vous avez des périodes de plus d'une minute sans connectivité afin que les interruptions soient examinées.

Stratégie de reprise après incident

L'objectif de temps de récupération (RTO) fait référence à la durée maximale acceptable pendant laquelle un système ou un service peut être indisponible après une panne. Il définit la rapidité avec laquelle le système doit être rétabli pour éviter une perturbation importante des opérations. Le RTO sur watsonx.data dépend des aspects suivants :

• Le point de sauvegarde le plus récent.
• État de l'archivage des journaux.
• Les étapes manuelles nécessaires à la restauration des métadonnées.

L'objectif de point de récupération (RPO) fait référence à la quantité maximale acceptable de perte de données en cas de défaillance. Il indique jusqu'où le système peut récupérer les données, sur la base de la sauvegarde ou de l'instantané le plus récent. La récupération est basée sur la dernière sauvegarde des métadonnées et la dernière archive des journaux. Il peut y avoir un délai entre la défaillance et le rétablissement de l'état.

Pour renforcer la résilience des données et minimiser les pertes potentielles, la fréquence de sauvegarde du service Milvus dans l'environnement SaaS a été augmentée. Cette modification réduit l'objectif de point de récupération (RPO) à seulement 2 heures, ce qui garantit que les données peuvent être restaurées à partir d'un point beaucoup plus récent en cas de défaillance.

Emplacements