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.
Outposts bastidor mantenimiento
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
Actualización de los datos de contacto
Si el propietario de Outpost cambia, comuníquese con AWS Support Center
Mantenimiento del hardware
Si AWS detecta un problema irreparable con el hardware durante el proceso de aprovisionamiento del servidor o mientras aloja las instancias de Amazon EC2 que se ejecutan en su servidor de Outposts, notificaremos al propietario de las instancias de 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 se requiere mantenimiento del hardware, se AWS pondrá en contacto con el propietario 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 propietario del Outpost 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 sustituyen un host, quitarán y destruirán la clave de seguridad NIST-compliant física, destruyendo de forma efectiva 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 notes cambios temporales en los anuncios de BGP, como la presencia AS-Path previa y los correspondientes cambios en los patrones de tráfico de los enlaces ascendentes de 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 equilibrio de BGP para lograr multipath/load flujos de tráfico entrante óptimos. AS-Path Los prefijos de las pasarelas de enlace locales se utilizan antes para 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 desde Outposts con una AS-Path longitud de 1 a las rutas con una AS-Path longitud 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 la función de AS-Path prefijo para cambiar temporalmente la matriz de tráfico desde enlaces ascendentes específicos.
Mejores prácticas para eventos de alimentación y red de
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:
-
Mueva sus servicios y aplicaciones fuera del equipo de Outposts de forma controlada, mediante cambios de equilibrio de carga DNS-based o fuera del rack.
-
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.
-
Back-up datos y configuraciones críticos y guárdalos fuera de los Outposts.
-
Mantenga los tiempos de inactividad del suministro de alimentación al mínimo.
-
Evite conmutar repetidamente las fuentes de alimentación (apagado - encendido - apagado- encendido) 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.
-
Cuando se restablezca la energía, cree una caja en AWS SupportCenter
para solicitar la verificación de que los servicios relacionados AWS Outposts y los servicios relacionados están funcionando.
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 la 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.
Las instancias de Amazon EC2, la puerta de enlace local y los volúmenes de Amazon EBS de los Outposts seguirán funcionando con normalidad y se podrá acceder a ellos de forma local a través de la red local. Del mismo modo, los recursos de AWS servicio, como los nodos de trabajo de Amazon ECS, siguen ejecutándose localmente. Sin embargo, la disponibilidad de la API disminuirá. Por ejemplo, es posible que las API de ejecución, inicio, detención y finalización no funcionen. Las métricas y los registros de las instancias seguirán almacenándose en caché local durante un máximo de 7 días y se transferirán a la AWS región cuando se restablezca la conectividad. Si se desconecta durante más de 7 días, es posible que se pierdan las métricas y los registros.
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, Panel de estado 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 Panel de estado 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. Contar con una ruta de red que funcione (premantenimiento de la red) y una ruta de red problemática (posmantenimiento de la red) 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..region.amazonaws.com.rproxy.govskope.usregionSustitúyala por 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 AWSSupport-SetupIPMonitoringFromVPCla herramienta. 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.
