Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Outposts rack maintenance
Dans le cadre du modèle
Avertissement
Si le lecteur de disque sous-jacent rencontre une défaillance ou si l’instance s’arrête, se met en veille prolongée ou est résiliée, les données stockées sur les volumes de stockage d’instances sont perdues. Pour éviter toute perte de données, nous vous recommandons de sauvegarder les données à long terme stockées sur des volumes de stockage d’instances sur un système de stockage persistant, tel qu’un compartiment Amazon S3, un volume Amazon EBS ou un dispositif de stockage de votre réseau sur site.
Table des matières
Mettre à jour les coordonnées
Si le propriétaire de l'Outpost change, contactez le AWS SupportCentre
Maintenance matérielle
Si un problème matériel irréparable est AWS détecté pendant le processus de mise en service du serveur ou lors de l'hébergement d'instances Amazon EC2 exécutées sur votre rack Outposts, nous informerons le propriétaire des instances que le retrait des instances concernées est prévu. Pour plus d’informations, consultez Retrait d’instances dans le Guide de l’utilisateur Amazon EC2.
Le propriétaire de l’Outpost et le propriétaire des instances peuvent tâcher de résoudre le travail conjointement. Le propriétaire des instances peut arrêter et démarrer une instance affectée pour la migrer vers de la capacité disponible. Les propriétaires d’instances peuvent arrêter et démarrer les instances concernées à leur convenance. Sinon, AWS arrête et redémarre les instances concernées à la date de mise hors service de l'instance. S’il n’y a pas de capacité supplémentaire sur l’Outpost, l’instance reste à l’état arrêté. Le propriétaire de l’Outpost peut essayer de libérer de la capacité utilisée ou de demander de la capacité supplémentaire pour l’Outpost de façon à mener à bien la migration.
Si une maintenance du matériel est requise, AWS contactera le propriétaire de l'Outpost pour confirmer la date et l'heure de la visite de AWS l'équipe d'installation. Les visites peuvent être planifiées dans un délai de deux jours ouvrables à compter du moment où le propriétaire de l'avant-poste a parlé à l'AWSéquipe.
Lorsque l'équipe AWS d'installation arrive sur place, elle remplace les hôtes, les commutateurs ou les éléments de rack défectueux et met en service la nouvelle capacité. Sur place, elle n’effectue aucun diagnostic ni aucune réparation sur le matériel. S'ils remplacent un hôte, ils retirent et détruisent la clé de sécurité NIST-compliant physique, détruisant ainsi toutes les données susceptibles de rester sur le matériel. Vous avez ainsi l’assurance qu’aucune donnée ne quitte votre site. En cas de remplacement d’un appareil réseau Outpost, il est possible que des informations de configuration réseau soient présentes sur l’appareil au moment où il est retiré du site. Ces informations peuvent inclure les adresses IP et les numéros ASN utilisés pour établir des interfaces virtuelles en vue de configurer le chemin menant à votre réseau local ou retournant à la région.
Mises à jour du microprogramme
Normalement, la mise à jour du microprogramme Outpost n’affecte pas les instances de votre Outpost. Dans les rares cas où nous devrons redémarrer l’équipement Outpost pour installer une mise à jour, vous recevrez un avis de retrait pour les instances utilisant cette capacité.
Maintenance de l’équipement réseau
La maintenance des appareils réseau Outpost (OND) n’affecte pas les opérations et le trafic réguliers de l’Outpost. Si une maintenance est nécessaire, le trafic est détourné des appareils OND. Il se peut que vous remarquiez des modifications temporaires dans les publicités BGP, telles que la AS-Path prépublication, et des modifications correspondantes des modèles de trafic sur les liaisons montantes d'Outpost. Lors des mises à jour du microprogramme des appareils OND, il est possible que vous constatiez une instabilité du protocole BGP.
Nous vous recommandons de configurer l'équipement réseau du client pour recevoir les publicités BGP des Outposts sans modifier les attributs BGP, et d'activer l'équilibrage BGP pour obtenir des multipath/load flux de trafic entrant optimaux. AS-Path le préattachement est utilisé pour les préfixes de passerelle locale afin de détourner le trafic des ONS si une maintenance est requise. Le réseau client doit préférer les itinéraires depuis les Outposts d'une AS-Path longueur de 1 aux itinéraires d'une AS-Path longueur de 4.
Le réseau du client doit annoncer à tous les appareils OND les mêmes préfixes BGP avec les mêmes attributs. Par défaut, le réseau Outpost équilibre la charge du trafic sortant entre toutes les liaisons ascendantes. Si une maintenance est nécessaire, les politiques de routage sont utilisées côté Outpost pour détourner le trafic d’un appareil OND. Ce détournement de trafic nécessite des préfixes BGP identiques côté client sur tous les appareils OND. Si une maintenance est requise sur le réseau du client, nous vous recommandons d'utiliser la AS-Path préattente pour déplacer temporairement le réseau de trafic depuis des liaisons montantes spécifiques.
Bonnes pratiques concernant les événements liés à l’alimentation et au réseau
Comme indiqué dans les conditions de AWS service destinées
Événements liés à l’alimentation
En cas de panne de courant complète, il existe un risque inhérent qu'une AWS Outposts ressource ne soit pas remise en service automatiquement. Outre le déploiement de solutions d’alimentation redondante et d’alimentation de secours, nous vous recommandons de prendre les mesures suivantes pour vous préparer aux pires scénarios :
-
Déplacez vos services et applications depuis les équipements des Outposts de manière contrôlée, en utilisant DNS-based ou non les modifications apportées à l'équilibrage de charge.
-
Arrêtez les conteneurs, les instances et les bases de données de manière incrémentielle et ordonnée et restaurez-les dans l’ordre inverse.
-
Testez des solutions permettant de déplacer ou d’arrêter les services de manière contrôlée.
-
Back-up données et configurations critiques et stockez-les en dehors des Outposts.
-
Limitez les coupures de courant au minimum.
-
Évitez les mises hors tension et sous tension répétées des sources d’alimentation pendant les opérations de maintenance.
-
Prévoyez du temps supplémentaire dans la fenêtre de maintenance pour faire face aux imprévus.
-
Gérez les attentes de vos utilisateurs et de vos clients en leur communiquant une fenêtre de maintenance plus grande que le temps dont vous auriez normalement besoin.
-
Une fois l'alimentation rétablie, créez un dossier au AWS Supportcentre
pour demander à vérifier que les services associés sont en cours d'exécution AWS Outposts et que les services associés sont en cours d'exécution.
Événements liés à la connectivité réseau
La liaison de service entre votre Outpost et la AWS région ou la région d'origine de l'Outpost se rétablit généralement automatiquement en cas d'interruption du réseau ou de problèmes susceptibles de survenir sur les appareils réseau de votre entreprise en amont ou sur le réseau de tout fournisseur de connectivité tiers une fois la maintenance du réseau terminée. Pendant que la connexion de la liaison de service est hors service, vos opérations Outposts sont limitées aux activités du réseau local.
Les instances Amazon EC2, la passerelle locale et les volumes Amazon EBS des Outposts continueront de fonctionner normalement et seront accessibles localement via le réseau local. De même, les ressources de AWS service telles que les nœuds de travail Amazon ECS continuent de s'exécuter localement. Cependant, la disponibilité des API sera dégradée. Par exemple, les API d'exécution, de démarrage, d'arrêt et de fin peuvent ne pas fonctionner. Les statistiques et les journaux des instances continueront d'être mis en cache localement pendant 7 jours au maximum et seront transmis à la AWS région lorsque la connectivité sera rétablie. Une déconnexion au-delà de 7 jours peut entraîner la perte de statistiques et de journaux.
Pour plus d’informations, consultez Que se passe-t-il en cas d’interruption de la connexion réseau de mon installation ? sur la page FAQ sur le rack AWS Outposts
Si la liaison de service est interrompue en raison d'un problème d'alimentation sur site ou d'une perte de connectivité réseau, le service Tableau de bord Health envoie une notification au compte propriétaire des Outposts. Ni vous ni ne AWS pouvez supprimer la notification d'une interruption de liaison de service, même si l'interruption est prévue. Pour plus d’informations, consultez Premiers pas avec le Tableau de bord Health dans le Guide de l’utilisateur AWS Health.
Dans le cas d’une maintenance de service planifiée qui va perturber la connectivité réseau, prenez les mesures proactives suivantes pour limiter l’impact de scénarios potentiellement problématiques :
-
Si votre rack Outposts se connecte à la AWS région parent via Internet ou une connexion directe publique, enregistrez un trace-itinéraire avant toute maintenance planifiée. Le fait de disposer d’un chemin réseau fonctionnel (antérieur à la maintenance réseau) et d’un chemin réseau problématique (postérieur à la maintenance réseau) pour identifier les différences aide la résolution des problèmes. Si vous signalez un problème post-maintenance à AWS ou à votre fournisseur de services Internet, vous pouvez inclure ces informations.
Capturez un trace-route entre :
-
Les adresses IP publiques de l’emplacement Outposts et l’adresse IP renvoyée par
outposts.. Remplacezregion.amazonaws.com.rproxy.govskope.usregionpar le nom de la AWS région parent. -
Toute instance présente dans la région parente dotée d’une connexion Internet publique et les adresses IP publiques à l’emplacement Outposts.
-
-
Si vous êtes responsable de la maintenance réseau, limitez la durée du temps d’arrêt de la liaison de service. Prévoyez une étape supplémentaire dans votre processus de maintenance pour vérifier que le réseau a été rétabli.
-
Si vous n’êtes pas responsable de la maintenance réseau, surveillez le temps d’arrêt de la liaison de service par rapport à la fenêtre de maintenance annoncée et faites rapidement remonter l’information à la personne en charge de la maintenance réseau planifiée si la liaison de service n’est pas rétablie à la fin de la fenêtre de maintenance annoncée.
Ressources
Voici quelques ressources se rapportant à la surveillance qui peuvent vous rassurer quant au fonctionnement normal des Outposts après un événement lié à l’alimentation ou au réseau, qu’il soit planifié ou non :
-
Le AWS blog Monitoring best practices for AWS Outposts couvre les
meilleures pratiques en matière d'observabilité et de gestion des événements spécifiques aux Outposts. -
Le AWS blog sur l'outil de débogage pour la connectivité réseau d'Amazon VPC
explique AWSSupport-SetupIPMonitoringFromVPCcet outil. Cet outil est un document AWS Systems Manager (SSM) qui crée une instance de surveillance Amazon EC2 dans un sous-réseau que vous avez spécifié et qui surveille les adresses IP cibles. Le document exécute des tests de diagnostic ping, MTR, TCP trace-route et trace-path et stocke les résultats dans Amazon CloudWatch Logs qui peuvent être visualisés dans un CloudWatch tableau de bord (latence, perte de paquets, par exemple). Pour la surveillance des Outposts, l'instance de surveillance doit se trouver dans un sous-réseau de la AWS région parent et être configurée pour surveiller une ou plusieurs de vos instances Outpost à l'aide de ses adresses IP privées. Cela fournira des graphiques de perte de paquets et de latence entre AWS Outposts et la région parent. AWS -
Le AWS blog Déploiement d'un CloudWatch tableau de bord Amazon automatisé AWS Outposts à utiliser AWS CDK
décrit les étapes du déploiement d'un tableau de bord automatisé. -
Si vous avez des questions ou si vous souhaitez obtenir des informations supplémentaires, consultez Création d’un dossier de support dans le Guide de l’utilisateur AWS Support.
