Comprendre la haute disponibilité et la reprise après sinistre pour DNS Services
La haute disponibilitéLa capacité d'un service ou d'une charge de travail à résister aux défaillances et à continuer à fournir une capacité de traitement selon un niveau de service prédéfini. Pour les services, la disponibilité est définie dans l'accord de niveau de service. La disponibilité comprend à la fois les événements planifiés et non planifiés, tels que la maintenance, les pannes et les catastrophes. (HA) est la capacité d'un service à rester opérationnel et accessible en cas de défaillance inattendue. L'objectif principal de la haute disponibilité est d'éliminer les points de défaillance potentiels au sein d'une infrastructure informatique. La reprise après sinistreCapacité d'un service ou d'une charge de travail à se remettre d'incidents rares, majeurs et de défaillances à grande échelle, tels que l'interruption d'un service. Il peut s'agir d'un désastre physique qui affecte une région entière, de la corruption d'une base de données ou de la perte d'un service contribuant à une charge de travail. L'impact dépasse la capacité de la conception de la haute disponibilité à le gérer. est le processus de rétablissement de l'instance de service dans un état opérationnel. Il comprend des procédures pour copier et stocker les données essentielles d'un système installé dans un endroit sûr, et pour récupérer ces données afin de rétablir le fonctionnement normal.
DNS Services est conçu pour atteindre les objectifs de niveau de service(SLO) avec le plan standard. DNS Services est un service mondial hautement disponible, architecturé avec des domaines de défaillance distincts pour améliorer la résilience. Le plan de contrôle résiste aux pannes zonales et régionales, et sa défaillance n'affecte pas le plan de données. Le plan de données résiste au moins aux défaillances zonales, et sa défaillance n'affecte pas le plan de contrôle.
Pour plus d'informations sur les régions de déploiement et les emplacements des centres de données pour DNS Services, voir Disponibilité des services et de l'infrastructure par emplacement.
Architecture à haute disponibilité
Plan de contrôle
IBM Cloud® DNS Services est un service disponible au niveau mondial (GA). Ses points d'extrémité API publics pour la configuration DNS sont disponibles via un équilibreur de charge global déployé dans deux régions multizonesUne région répartie sur des sites physiques dans plusieurs zones afin d'accroître la tolérance aux pannes. (MZR) de IBM Cloud, garantissant une haute disponibilité. Ces régions sont Dallas et Washington, DC. Si une région subit une panne, l'équilibreur de charge global achemine automatiquement le trafic API vers l'autre région. Par exemple, si la région de Dallas n'est pas disponible, les demandes sont redirigées vers d'autres régions géographiques disponibles, en l'occurrence Washington, DC.
En cas de défaillance globale, le plan de contrôle est restauré en s'efforçant de réduire la perte de données pour les ressources. C'est pourquoi les clients doivent également planifier la reprise après sinistre.
Un plan de contrôle traite les demandes de configuration DNS initiées par l'utilisateur, tandis qu'un plan de données traite les demandes de résolution de noms provenant du nuage privé virtuel (VPC).
Plan de données Serveurs DNS
Les serveurs DNS sont répartis globalement sur plusieurs MZR et utilisent des adresses IP anycast pour optimiser la latence et assurer une haute disponibilité. Si une zone de disponibilité ou une région entière subit une panne, les requêtes DNS sont automatiquement acheminées vers la zone de disponibilité ou la région la plus proche. Les données DNS sont répliquées dans les régions suivantes afin d'optimiser la latence et la haute disponibilité :
- Dallas (us-south)
- Washington, D.C. (us-east)
- Londres (eu-gb)
- Madrid (eu-es)
- Francfort (eu-de)
- Osaka (jp-osa)
- Tokyo (jp-tok)
- Toronto (ca-tor)
- Sydney (au-syd)
- Sao Paulo (br-sao)
Résolveurs personnalisés du plan de données
Un résolveur personnalisé est un objet régional composé d'objets zonaux (emplacements de résolveurs personnalisés) configurés sur des sous-réseaux à travers des zones. Il est recommandé de déployer des programmes de résolution personnalisés sur plusieurs sous-réseaux afin de garantir la haute disponibilité. Il est recommandé de déployer dans les trois zones de disponibilité.
En cas de défaillance régionale, cet aspect du plan de données est rétabli en fonction de l'état des ressources tel qu'il est représenté et conservé dans le plan de contrôle.
Fonctionnalités de haute disponibilité
DNS Services prend en charge les fonctions de haute disponibilité suivantes :
| Fonction | Description | Élément à prendre en compte |
|---|---|---|
| Emplacements personnalisés du résolveur | Gérez l'endroit où votre résolveur personnalisé est déployé. | Il ne fait qu'ajouter de la résistance aux défaillances des zones. |
Vous pouvez atteindre la haute disponibilité à différents niveaux de votre infrastructure informatique et entre les différents composants de votre cluster DNS. Le niveau de disponibilité qui vous convient dépend de plusieurs facteurs, notamment des exigences de votre entreprise, des accords de niveau de service (SLA) que vous avez conclus avec vos clients et des ressources que vous êtes prêt à dépenser.
Le niveau de disponibilité que vous mettez en place pour votre cluster a un impact sur votre couverture dans le cadre des conditions SLA de haute disponibilité de IBM Cloud.
Les objectifs de niveau de service (SLO) définissent les points de conception que les services IBM Cloud doivent respecter. IBM Cloud® DNS Services est conçu pour atteindre l'objectif de disponibilité suivant.
| Objectif de disponibilité | Valeur cible |
|---|---|
| % de disponibilité | 99.999% |
Le SLO n'est pas une garantie et IBM ne délivrera pas de crédits en cas de non-respect d'un objectif. Reportez-vous aux accords de niveau de service pour connaître les engagements et les crédits accordés en cas de non-respect d'un accord de niveau de service. Pour un résumé de tous les SLO, consultez les objectifs de niveau de service IBM Cloud.
Pour plus d'informations sur la disponibilité des services dans les régions et les centres de données, voir Disponibilité des services et de l'infrastructure par emplacement.
Voir Comment IBM Cloud assure la haute disponibilité et la reprise après sinistre pour en savoir plus sur les normes de haute disponibilité et de reprise après sinistre dans IBM Cloud.
Architecture de reprise après sinistre
La conservation d'un enregistrement externe de votre configuration DNS est importante pour la récupération de DNS Services en cas de sinistre. Les processus de sauvegarde et de restauration peuvent être automatisés à l'aide de scripts et des processus d'exportation et d'importation figurant dans le tableau des fonctionnalités de reprise après sinistre. DNS Services prend en charge Terraform et peut être utilisé pour définir des charges de travail avec des emplacements et des performances paramétrés. Les clients peuvent utiliser IBM Cloud Schematics pour créer et gérer des scripts Terraform, qui peuvent à leur tour être utilisés pour récupérer des ressources dans un emplacement disponible en cas de sinistre.
Fonctionnalités de reprise après sinistre
IBM Cloud® DNS Services prend en charge les fonctions de reprise après sinistre suivantes :
| Fonction | Description | Élément à prendre en compte |
|---|---|---|
| Exporter des enregistrements de ressources DNS | Exporter les enregistrements DNS d'une zone vers un fichier texte via le tableau de bord. | N'exporte que les enregistrements DNS d'une seule zone à la fois. N'exporte pas les données relatives à l'équilibreur de charge ou d'autres données non liées aux enregistrements DNS. |
| Importer des enregistrements de ressources DNS | Importer les enregistrements DNS d'un fichier texte dans une zone via le tableau de bord. | Il faut recréer la zone avant d'importer les enregistrements DNS. |
| Source externe de vérité | Zones DNS, réseaux autorisés, enregistrements de ressources DNS, résolveurs personnalisés, règles de transfert de résolveur personnalisées, etc. capturés dans des fichiers de configuration gérés par le client, tels que des scripts Terraform, des scripts shell ou des programmes. | Le client doit créer le script ou le programme et conserver la configuration à un endroit où elle peut être utilisée en cas de sinistre. |
| Sauvegarde et restauration | Sauvegarde d'une instance de service à l'aide d'un script écrit par le client. | Le client doit créer le script et conserver la copie de sauvegarde à un endroit où elle pourra être utilisée lors de la récupération. |
Planification du désamorçage
En tant que client, vous êtes responsable de la récupération des données de configuration de votre serveur DNS en cas de sinistre. Vous devez veiller à élaborer un plan de reprise après sinistre et à envisager les scénarios de défaillance et les solutions suivantes :
| Echec | Résolution |
|---|---|
| Défaillance zonale | Atténué pour les résolveurs personnalisés en les déployant sur plusieurs sites Atténué pour les serveurs DNS en répondant aux requêtes par la zone de disponibilité la plus proche. |
| Défaillance régionale | Interruption des résolveurs personnalisés jusqu'à ce qu'une zone de disponibilité soit rétablie. Atténué pour les serveurs DNS par des requêtes auxquelles répond la région disponible la plus proche. |
| Altération de données | Restaurer les configurations de service à partir d'une source externe de vérité. |
Vos responsabilités en matière d'HA et de DR
Il est de votre responsabilité de tester en permanence votre plan d'HA et de DR.
Des interruptions de la connectivité du réseau et de courtes périodes d'indisponibilité d'un service peuvent se produire. Il est de votre responsabilité de vous assurer que le code source de l'application inclut une logique de relance de la disponibilité du client afin de maintenir la haute disponibilité de l'application.
Utilisez les listes de contrôle suivantes associées à chaque caractéristique pour vous aider à créer et à mettre en pratique votre plan.
- Programme de résolution personnalisé
Pour plus d'informations sur la répartition des responsabilités entre vous et IBM Cloud pour IBM Cloud DNS Services, voir Comprendre vos responsabilités lors de l'utilisation de IBM Cloud DNS Services.
Gestion des modifications
La gestion des modifications comprend des tâches telles que les changements de configuration et la suppression.
Accorder aux utilisateurs et aux processus les rôles et les actions Identity and Access Management (IAM) avec le minimum de privilèges requis pour leur travail. Pour plus d'informations, voir Comment empêcher la suppression accidentelle de services?
Les meilleures pratiques en matière de gestion du changement comprennent également :
- Planifiez et documentez les changements en tenant un journal des changements pour toutes les modifications apportées à votre configuration DNS Services.
- Créez une sauvegarde des configurations critiques avant d'effectuer des changements majeurs.
- Programmer les changements à fort impact pendant les périodes de faible trafic et en informer les équipes concernées.
- Surveillez la santé et les paramètres de votre site DNS Services pour vous assurer que tout fonctionne comme prévu.
Comment IBM aide à assurer la reprise après sinistre
IBM® prend des mesures de récupération spécifiques pour IBM Cloud® DNS Services, en cas de sinistre.
Comment IBM se remet des échecs régionaux
IBM Cloud dispose de plans de continuité des activitésPossibilité pour une entreprise de prendre en charge les pannes et d'exécuter ses services critiques normalement et sans interruption, conformément à des accords de niveau de service prédéfinis. permettant de rétablir les services en quelques heures en cas de catastrophe. Vous êtes responsable de la sauvegarde des données et de la récupération de votre contenu.
DNS Services fournir des mécanismes pour protéger vos données et rétablir les fonctions du service. Des plans de continuité des activités sont en place pour atteindre les objectifs de point de récupérationDans la planification de la reprise après sinistre, le délai de restauration des données est mesuré en temps (secondes, minutes, heures) à partir de l'instance récupérée et jusqu'au point du sinistre. (RPO) et de temps de récupérationDans le cadre de la planification de la reprise après sinistre, le temps nécessaire à la restauration d'un processus d'entreprise après un sinistre. (RTO) pour le service. Le tableau suivant présente les objectifs pour DNS Services.
| Élément de service | RPO | RTO |
|---|---|---|
| Plan de contrôle | 0 | < 60 secondes |
| Plan de données | 0 | < 60 secondes |
| Programme de résolution personnalisé | 0 | < 60 secondes |
| Restauration de la base de données | 24 h | 8 heures |
Si IBM ne peut pas restaurer l'instance de service, vous devez restaurer le service comme décrit dans l'architecture de reprise après sinistre.
Pour plus d'informations sur la disponibilité des services dans les régions et les centres de données, voir Disponibilité des services et de l'infrastructure par emplacement.
Comment IBM maintient les services
Toutes les mises à niveau suivent les meilleures pratiques du service IBM, y compris les plans de reprise et les processus de retour en arrière. La maintenance régulière peut entraîner de brèves interruptions, atténuées par la logique de relance de la disponibilité du client. Les modifications sont déployées de manière séquentielle, région par région, et zone par zone à l'intérieur d'une région. IBM annule les mises à jour au premier signe de défaut.
IBM fournit un préavis pour toutes les activités de maintenance planifiées. Si un changement est susceptible d'affecter votre charge de travail, IBM vous en informera par le biais de notifications officielles. Pour vous tenir au courant des opérations de maintenance, des annonces de service et d'autres mises à jour, consultez la page Notifications et état de la surveillance.