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.
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 vos données à long terme sur les volumes de stockage d'instance sur un stockage persistant, tel qu'un compartiment Amazon S3, un EBS volume Amazon ou un périphérique de stockage réseau 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 Support Centre
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'EC2instances Amazon exécutées sur votre rack Outposts, nous informerons le propriétaire de l'Outpost et le propriétaire des instances que les instances concernées sont censées être retirées. Pour plus d'informations, consultez la section Retrait d'instance dans le guide de EC2 l'utilisateur Amazon.
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é physique NIST conforme, 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 des adresses IP et être ASNs utilisées pour établir des interfaces virtuelles afin de configurer le chemin d'accès à votre réseau local ou de retour vers 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 périphériques réseau de l'avant-poste (OND) est effectuée sans affecter les opérations et le trafic réguliers de l'avant-poste. Si une maintenance est requise, le trafic est éloigné duOND. Vous remarquerez peut-être des modifications temporaires dans les BGP publicités, telles que le préfixe AS-Path, et des modifications correspondantes des modèles de trafic sur les liaisons montantes d'Outpost. Lors des mises à jour du OND microprogramme, vous remarquerez peut-être des BGP claquements.
Nous vous recommandons de configurer l'équipement réseau des clients pour recevoir les BGP publicités des Outposts sans modifier les BGP attributs, et d'activer l'équilibrage BGP multipath/charge pour optimiser les flux de trafic entrant. Le préfixe AS-Path est utilisé pour les préfixes de passerelle locale afin de détourner le trafic ONDs si une maintenance est requise. Le réseau du client doit privilégier les routes en partance d’Outposts d’une longueur AS-Path de 1 plutôt que les routes d’une longueur AS-Path de 4.
Le réseau de clients doit annoncer des BGP préfixes identiques avec les mêmes attributs à tousONDs. Par défaut, le réseau Outpost équilibre la charge du trafic sortant entre toutes les liaisons ascendantes. Les politiques de routage sont utilisées du côté de l'avant-poste pour détourner le trafic et OND si une maintenance est requise. Ce transfert de trafic nécessite des BGP préfixes identiques de la part du client pour tousONDs. Si une maintenance est nécessaire sur le réseau du client, nous vous recommandons d’utiliser l’ajout en préfixe de AS-Path pour détourner temporairement le trafic de certaines liaisons ascendantes.
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 hors des équipements des Outposts de manière contrôlée, en utilisant des modifications d'équilibrage de charge DNS basées ou non sur le rack.
-
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.
-
Sauvegardez les données et les configurations critiques et stockez-les en dehors des Outposts.
-
Limitez les coupures de courant au minimum.
-
Évitez de changer plusieurs fois les alimentations (off-on-off-on) pendant la 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 Support centre
pour demander à vérifier que AWS Outposts 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.
Pour plus d'informations, consultez la question Que se passe-t-il lorsque la connexion réseau de mon établissement est interrompue ? sur la FAQs page du AWS Outposts rack
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 AWS Health Dashboard 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 AWS Health Dashboard 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 (post-network-maintenance) et d'un chemin réseau problématique () pour identifier les différences faciliterait le dépannage. pre-network-maintenance Si vous signalez un problème post-maintenance à AWS ou à votreISP, 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.goskope.comregionavec 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, l'outil de débogage pour la connectivité réseau d'Amazon
, VPC explique l'outil AWSSupport-S etupIPMonitoring FromVPC. Cet outil est un AWS Systems Manager document (SSMdocument) qui crée une instance Amazon EC2 Monitor 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 pingMTR, 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.
