- AWS Outposts

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.

Esto se aplica al AWS Outposts igual que a una AWS región. Por ejemplo, AWS administra los parches de seguridad, actualiza el firmware y mantiene el equipo de Outpost. AWS también supervisa el rendimiento, el estado y las métricas de su rack Outposts y determina si es necesario realizar algún tipo de mantenimiento.

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, te recomendamos que guardes 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 EBS volumen de Amazon o un dispositivo de almacenamiento en red de tu red local.

Actualiza los datos de contacto

Si el propietario de Outpost cambia, comunícate con AWS Support Center con el nombre y la información de contacto del nuevo propietario.

Mantenimiento del hardware

Si AWS detecta un problema irreparable con el hardware durante el proceso de aprovisionamiento del servidor o al alojar EC2 instancias de Amazon que se ejecutan en su rack de Outposts, notificaremos al propietario de Outpost y al propietario de las instancias que las instancias afectadas están programadas para su retirada. Para obtener más información, consulte Retirada de instancias en la Guía del EC2 usuario de Amazon.

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 AWS equipo.

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 NIST de seguridad física compatible, destruyendo de forma efectiva cualquier dato que pueda 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 direcciones IP y ASNs usarse para establecer interfaces virtuales para 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 a las operaciones y el tráfico habituales de Outpost. Si es necesario realizar tareas de mantenimiento, el tráfico se desplaza fuera del. OND Es posible que observe cambios temporales en los BGP anuncios, como la anteponía de AS-Path y los correspondientes cambios en los patrones de tráfico en los enlaces ascendentes de Outpost. Con las actualizaciones de OND firmware, es posible que notes fluctuaciones. BGP

Le recomendamos que configure el equipo de red del cliente para recibir BGP anuncios de Outposts sin cambiar los BGP atributos y que habilite el equilibrio de BGP multiruta/carga para lograr flujos de tráfico entrante óptimos. El prefijo AS-Path se utiliza para desviar el tráfico de los prefijos de las puertas de enlace locales si es necesario realizar tareas de mantenimiento. ONDs 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 BGP prefijos iguales con los mismos atributos para todos. ONDs 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 lado de Outpost para desviar el tráfico de un lugar a otro OND si es necesario realizar tareas de mantenimiento. Este cambio de tráfico requiere la misma cantidad de BGP prefijos por parte del cliente en todos los casos. ONDs 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 de alimentación y red de

Como se indica en los Términos de AWS servicio para AWS Outposts los clientes, la instalación donde se encuentra el equipo de Outposts debe cumplir con los requisitos mínimos de energía y red para respaldar la instalación, el mantenimiento y el uso del equipo de Outposts. Un rack de Outposts solo puede funcionar correctamente cuando la conectividad eléctrica y de red es ininterrumpida.

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:

  • Saque sus servicios y aplicaciones del equipo de Outposts de forma controlada, mediante cambios de equilibrio de carga DNS basados 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.

  • 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.

  • Cuando se restablezca la alimentación, cree una caja en el AWS Support Centro 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 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, consulta la pregunta ¿Qué ocurre cuando se interrumpe la conexión de red de mi centro? en la AWS Outposts FAQspágina principal.

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 traslada un problema posterior al mantenimiento a AWS o a su personaISP, puede 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. Reemplazar region con 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.

  • El AWS blog Debugging tool for network connectivity de Amazon VPC explica la herramienta AWSSupport-S etupIPMonitoring FromVPC. Esta herramienta es un AWS Systems Manager documento (SSMdocumento) que crea una instancia de Amazon EC2 Monitor en una subred especificada por usted y monitorea las direcciones IP de destino. El documento ejecuta pruebas de diagnóstico de pingMTR, TCP trace-route y trace-path 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.