Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Mantenimiento de un Outpost
Según el modelo de responsabilidad compartida
aviso
Los datos de los volúmenes del almacén de instancias se pierden si la unidad de disco subyacente falla o si la instancia se detiene, hiberna o finaliza. Para evitar la pérdida de datos, le recomendamos que guarde copias de seguridad de los datos a largo plazo de los volúmenes del almacén de instancias en un almacenamiento persistente, como un bucket de Amazon S3, un volumen de Amazon EBS o un dispositivo de almacenamiento en red de su red en las instalaciones.
Contenido
Mantenimiento del hardware
Si AWS detecta un problema irreparable con el hardware que aloja las instancias de Amazon EC2 que se ejecutan en su Outpost, notificaremos al propietario del Outpost y al propietario de las instancias que está previsto retirar las instancias afectadas. Para obtener más información, consulte Retirada de instancia en la Guía del usuario de Amazon EC2.
El propietario de Outpost y el propietario de la instancia pueden trabajar juntos para resolver el problema. El propietario de la instancia puede detener e iniciar una instancia afectada para migrarla a la capacidad disponible. Los propietarios de las instancias pueden detener e iniciar las instancias afectadas en el momento que les resulte más conveniente. De lo contrario, AWS detiene e inicia las instancias afectadas en la fecha de retirada de la instancia. Si no hay capacidad adicional en el Outpost, la instancia permanece detenida. A fin de poder completar la migración, el propietario del Outpost puede intentar liberar la capacidad utilizada o solicitar capacidad adicional para el Outpost.
Si es necesario realizar tareas de mantenimiento en el hardware, AWS se pondrá en contacto con el administrador del sitio de Outpost para confirmar la fecha y la hora de la visita del equipo de AWS instalación. Las visitas se pueden programar en un plazo máximo de dos días laborables a partir del momento en que el administrador del sitio hable con el equipo de AWS .
Cuando el equipo de AWS instalación llegue a las instalaciones, sustituirá los hosts, conmutadores o elementos del rack que no estén funcionando correctamente y pondrá en funcionamiento la nueva capacidad. El equipo no realizará ningún diagnóstico ni reparación del hardware in situ. Si sustituye un host, quitará y destruirá la clave de seguridad física conforme con la norma NIST, y destruirá cualquier dato que pudiera permanecer en el hardware. Esto garantiza que ningún dato salga de su sitio. Si el equipo sustituye un dispositivo de red de Outpost, es posible que la información de configuración de la red esté presente en el dispositivo cuando se elimine del sitio. Esta información puede incluir las direcciones IP y las ASN que se utilizan para establecer interfaces virtuales, a fin de configurar la ruta a la red local o de regreso a la región.
Actualizaciones de firmware
La actualización del firmware de Outpost no suele afectar a las instancias de su Outpost. En el raro caso de que necesitemos reiniciar el equipo de Outpost para instalar una actualización, recibirá un aviso de retirada de todas las instancias que se ejecuten en esa capacidad.
Mantenimiento del equipo de red
El mantenimiento de los dispositivos de red de Outpost (OND) se realiza sin afectar las operaciones y el tráfico habituales del Outpost. Si es necesario realizar tareas de mantenimiento, el tráfico se aleja del OND. Es posible que observe cambios temporales en los anuncios de BGP, como el AS-Path Prepending y los correspondientes cambios en los patrones de tráfico en los enlaces ascendentes del Outpost. Con las actualizaciones de firmware de OND, es posible que note que el BGP sufre interrupciones.
Le recomendamos que configure el equipo de red del cliente para recibir anuncios de BGP de Outposts sin cambiar los atributos de BGP y que habilite el equilibrador de multiruta y de carga del BGP para lograr flujos de tráfico entrante óptimos. La técnica AS-Path Prepending se utiliza para los prefijos de las puertas de enlace locales a fin de desviar el tráfico de los OND en caso de que sea necesario realizar tareas de mantenimiento. La red de clientes debería preferir las rutas de Outposts con una longitud de AS-Path de 1 a las rutas con una longitud de AS-Path de 4.
La red de clientes debe anunciar prefijos BGP iguales con los mismos atributos en todos los OND. El equilibrador de carga de red de Outpost equilibra el tráfico saliente entre todos los enlaces ascendentes de forma predeterminada. Las políticas de enrutamiento se utilizan en el Outpost para desviar el tráfico de un OND si es necesario realizar tareas de mantenimiento. Este cambio de tráfico requiere la misma cantidad de prefijos de BGP por parte del cliente en todos los OND. Si es necesario realizar tareas de mantenimiento en la red del cliente, le recomendamos que utilice AS-Path para desplazar temporalmente la matriz de tráfico desde enlaces ascendentes específicos.
Mejores prácticas para eventos AWS Outposts de energía y red
Como se indica en los Términos de AWS servicio
Eventos de alimentación
En caso de cortes de energía totales, existe el riesgo inherente de que un AWS Outposts recurso no vuelva a funcionar automáticamente. Además de desplegar soluciones de alimentación redundante y de respaldo, le recomendamos que haga lo siguiente con antelación para mitigar el impacto de algunos de los peores escenarios posibles:
-
Retire sus servicios y aplicaciones de los equipos de Outposts de forma controlada mediante cambios en el equilibrador de carga basados en DNS o fuera del bastidor.
-
Detenga los contenedores, las instancias y las bases de datos de forma ordenada e incremental, y utilice el orden inverso al restaurarlos.
-
Pruebe los planes para el traslado o la detención controlados de los servicios.
-
Realice copias de seguridad de los datos y configuraciones de relevancia y guárdelos fuera de los Outposts.
-
Mantenga los tiempos de inactividad del suministro de alimentación al mínimo.
-
Evite cambiar repetidamente las fuentes de alimentación (off-on-off-on) durante el mantenimiento.
-
Prevea tiempo adicional dentro del período de mantenimiento para hacer frente a cualquier imprevisto.
-
Gestione las expectativas de sus usuarios y clientes comunicando un plazo de mantenimiento más amplio del que normalmente necesitaría.
Eventos de conectividad de red
La conexión de enlace de servicio entre tu Outpost y la AWS región o región de origen de Outposts normalmente se recuperará automáticamente de las interrupciones o problemas de red que puedan producirse en los dispositivos de la red corporativa principal o en la red de cualquier proveedor de conectividad externo una vez que se complete el mantenimiento de la red. Durante el tiempo en que la conexión del enlace de servicio esté inactiva, sus operaciones de Outposts se limitarán a las actividades de la red local.
Para obtener más información, consulte la pregunta: ¿qué ocurre cuando se interrumpe la conexión de red de mis instalaciones? en la página de Preguntas frecuentes sobre bastidores de AWS Outposts
Si el enlace de servicio no funciona debido a un problema de energía in situ o a una pérdida de conectividad de red, AWS Health Dashboard envía una notificación a la cuenta propietaria de los Outposts. Ni tú ni tú AWS podéis suprimir la notificación de una interrupción del enlace de servicio, incluso si la interrupción es esperada. Para obtener más información, consulte Introducción a su AWS Health Dashboard en la Guía del usuario de AWS Health .
En el caso de un mantenimiento planificado del servicio que afecte a la conectividad de la red, tome las siguientes medidas proactivas para limitar el impacto de posibles escenarios problemáticos:
-
Si tu rack de Outposts se conecta a la AWS región principal a través de Internet o Direct Connect público, captura una ruta de rastreo antes del mantenimiento planificado. Disponer de una ruta de red que funcione (pre-network-maintenance) y una ruta de red problemática (post-network-maintenance) para identificar las diferencias ayudaría a solucionar el problema. Si planteas un problema posterior al mantenimiento AWS o a tu ISP, puedes incluir esta información.
Capture una ruta de rastreo entre:
-
Las direcciones IP públicas de la ubicación de Outposts y la dirección IP devuelta por los
outposts.. Sustituyaregion.amazonaws.comla regiónpor el nombre de la región principal. AWS -
Cualquier instancia en la región principal con conectividad pública a Internet y las direcciones IP públicas en la ubicación de Outposts.
-
-
Si tiene el control del mantenimiento de la red, limite la duración del tiempo de inactividad del enlace de servicio. Incluya un paso en el proceso de mantenimiento que verifique que la red se haya recuperado.
-
Si no tiene el control del mantenimiento de la red, supervise el tiempo de inactividad del enlace de servicio con respecto al período de mantenimiento anunciado e infórmele cuanto antes a la parte encargada del mantenimiento planificado de la red si el enlace de servicio no vuelve a funcionar al final del período de mantenimiento anunciado.
Recursos
A continuación, se detallan algunos recursos relacionados con la supervisión que pueden garantizar que los Outposts estén funcionando normalmente después de un evento de alimentación o red planificado o no planificado:
-
El AWS blog Monitoring best practices for AWS Outposts
cubre las mejores prácticas de observabilidad y gestión de eventos específicas de Outposts. -
En el AWS blog Herramienta de depuración para conectividad de red de Amazon VPC se explica la herramienta de VPC AWSSupport
-SetupIP. MonitoringFrom Esta herramienta es un documento de AWS Systems Manager (documento SSM) que crea una instancia de supervisión de Amazon EC2 en una subred especificada por usted, y supervisa las direcciones IP de destino. El documento ejecuta pruebas de diagnóstico de ruta de rastreo de ping, MTR, TCP y ruta de rastreo y almacena los resultados en Amazon CloudWatch Logs, que se pueden visualizar en un CloudWatch panel de control (por ejemplo, latencia o pérdida de paquetes). Para el monitoreo de Outposts, la instancia de monitoreo debe estar en una subred de la AWS región principal y estar configurada para monitorear una o más de tus instancias de Outpost utilizando sus IP privadas; esto proporcionará gráficos de pérdida de paquetes y latencia entre AWS Outposts la región principal y la región principal. AWS -
El AWS blog Cómo implementar un CloudWatch panel automatizado de Amazon para su AWS Outposts uso AWS CDK
describe los pasos necesarios para implementar un panel automatizado. -
Si tiene preguntas o necesita más información, consulte Creating a support case en la Guía del usuario de AWS Support.
