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.
# Computación
Si bien EC2 la capacidad de Amazon Regiones de AWS es aparentemente infinita, la capacidad de Outposts es finita. El usuario es responsable de planificar y administrar la capacidad informática de las implementaciones de Outposts.
**Topics**
+ [Planificación de la capacidad](capacity-planning.md)
+ [Administración de la capacidad](capacity-management.md)
+ [Ubicación de instancias](instance-placement.md)
# Planificación de la capacidad
Si bien la EC2 capacidad de Amazon Regiones de AWS es aparentemente infinita, la capacidad de Outposts es finita, limitada por el volumen total de capacidad de cómputo solicitada. El usuario es responsable de planificar y administrar la capacidad informática de las implementaciones de Outposts. El usuario debe solicitar una capacidad informática suficiente para admitir un modelo de disponibilidad N\$1M, en el que N es la capacidad requerida y M es el número de servidores de reserva aprovisionados para adaptarse a los errores de los servidores. N\$11 y N\$12 son los niveles de disponibilidad más comunes.
Cada host (`C5`,`M5`,`R5`, etc.) admite una sola familia de EC2 instancias. Antes de lanzar instancias en servidores de EC2 procesamiento, debe proporcionar diseños de ranuras que especifiquen los [tamaños de EC2 instancia](https://aws.amazon.com/ec2/instance-types/) que desea que proporcione cada servidor. AWS configura cada servidor con el diseño de ranuras solicitado.
Los hosts pueden tener ranuras homogéneas cuando todas las ranuras tienen el mismo tamaño de instancia (por ejemplo, 48 `m5.large` ranuras) o heterogéneamente con una mezcla de tipos de instancias (por ejemplo, 4, 4`m5.large`, 3 `m5.xlarge` `m5.2xlarge``m5.4xlarge`, 1 y 1`m5.8xlarge`). Consulte las tres figuras siguientes para ver una visualización de estas configuraciones de asignación de ranuras.
![\[Diagrama m5.24xlarge que muestra los recursos informáticos del host\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/aws-outposts-high-availability-design/images/m5-24xlarge-server-resources.png)
![\[Diagrama que muestra el m5.24xlarge host distribuido homogéneamente en ranuras de 48 m.\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/aws-outposts-high-availability-design/images/m5-24xlarge-slotted-into-48-m5-large-slots.png)
![\[Diagrama que muestra el m5.24xlarge host distribuido de forma heterogénea en 4m5.large, 4, 3 m5.xlargem5.2xlarge, 1 y 1 ranuras m5.4xlarge m5.8xlarge\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/aws-outposts-high-availability-design/images/m5-24xlarge-slotted-into-different-x5-slots.png)
No es necesario asignar toda la capacidad del host. Se pueden agregar ranuras a un host que tenga capacidad disponible sin asignar. Puede modificar un diseño de ranuras mediante la administración de capacidad APIs o UIs creando una nueva tarea de capacidad. AWS Outposts Para obtener más información, consulte [Gestión de la capacidad AWS Outposts](https://docs.aws.amazon.com/outposts/latest/userguide/outposts-capacity.html) en la *guía del AWS Outposts usuario de racks*. Es posible que deba cerrar o reiniciar determinadas instancias para completar una nueva tarea de capacidad si el nuevo diseño de ranuras no se puede aplicar mientras determinadas ranuras estén ocupadas por instancias en ejecución. La `CreateCapacityTask` API te permite expresar el número del tamaño de cada instancia que debe estar presente en el ID de Outpost indicado y, en el caso de que una tarea no se pueda completar debido a la ejecución de instancias, devuelve las instancias que deben detenerse para satisfacer la solicitud. En este punto, si lo desea, puede indicar si desea ver «N» opciones adicionales en caso de que prefiera no detener una de las instancias devueltas, y también puede indicar un ID de EC2 instancia, una etiqueta de EC2 instancia, una cuenta o un servicio que no deba sugerirse como instancia para cerrar para satisfacer la solicitud de tarea de capacidad. Tras seleccionar la opción que prefiera, le recomendamos que utilice el parámetro Dry Run para validar los cambios propuestos y comprender el impacto potencial antes de implementarlos.
Todos los hosts aportan las ranuras aprovisionadas a los grupos de EC2 capacidad del Outpost, y todas las ranuras de un tipo y tamaño de instancia determinados se administran como un único grupo de EC2 capacidad. Por ejemplo, el host anterior distribuido de forma heterogénea con ranuras`m5.large`,, `m5.xlarge` `m5.2xlarge``m5.4xlarge`, y distribuiría estas `m5.8xlarge` ranuras para formar cinco grupos de EC2 capacidad, uno para cada tipo y tamaño de instancia. Estos grupos pueden estar repartidos en varios hosts, por lo que se debe tener en cuenta la ubicación de las instancias para lograr una alta disponibilidad de la carga de trabajo.
Es importante tener en cuenta la distribución de los hosts y los grupos de EC2 capacidad al planificar la capacidad sobrante para la disponibilidad de los hosts de N\$1M. AWS detecta cuando un host falla o se degrada y programa una visita al sitio para reemplazar el host defectuoso. Debe diseñar sus grupos de EC2 capacidades de manera que toleren el fallo de al menos un servidor de cada familia de instancias (N\$11) en un Outpost. Con este nivel mínimo de disponibilidad de hosts, cuando un host falla o es necesario dejarlo fuera de servicio, puede reiniciar las instancias defectuosas o degradadas en las ranuras libres de los hosts restantes de la misma familia.
Planificar la disponibilidad de N\$1M es sencillo cuando se dispone de hosts con ranuras homogéneas o grupos de hosts con ranuras heterogéneas con diseños de ranuras idénticos. Solo tiene que calcular la cantidad de hosts (N) que necesita para ejecutar todas sus cargas de trabajo y, a continuación, añadir (M) hosts adicionales para cumplir con los requisitos de disponibilidad del servidor en caso de averías o de mantenimiento.
Las siguientes configuraciones de asignación de ranuras no se pueden utilizar debido a los límites de NUMA:
+ 3 `m5.8xlarge`
+ 1 `m5.16xlarge` y 1 `m5.8xlarge`
Consulte a su Cuenta de AWS equipo para validar la configuración de ranuras de AWS Outposts estanterías planificada.
En la siguiente figura, cuatro `m5.24xlarge` hosts tienen ranuras heterogéneas con un diseño de ranuras idéntico. Los cuatro hosts crean cinco grupos de capacidad. EC2 Cada grupo se ejecuta con un uso máximo (75%) para mantener una disponibilidad de N\$11 para las instancias que se ejecutan en estos cuatro hosts. Si algún host falla, hay espacio suficiente para reiniciar las instancias fallidas en los hosts restantes.
![\[Diagrama que muestra la visualización de las ranuras de EC2 host, las instancias en ejecución y los grupos de ranuras\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/aws-outposts-high-availability-design/images/ec2-server-slots-and-pools.png)
Para diseños de ranuras más complejos, en los que los hosts no tienen la misma distribución, tendrá que calcular la disponibilidad de N\$1M para cada grupo de capacidad. EC2 Puede usar la siguiente fórmula para calcular cuántos hosts (que aportan espacios a un grupo de EC2 capacidad determinado) pueden fallar y, aun así, permitir que los hosts restantes alojen las instancias en ejecución:
![\[Ecuación M = (ranuras de grupo disponibles/cantidad máxima de ranuras de host)\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/aws-outposts-high-availability-design/images/equation.png)
Donde:
+ **PoolSlots available** es la cantidad de ranuras disponibles en un grupo de EC2 capacidad determinado (el número total de ranuras del grupo menos el número de instancias en ejecución)
+ **ServerSlots max** es la cantidad máxima de ranuras que cualquier host aporta a la reserva de capacidad determinada EC2
+ **M** es la cantidad de hosts que pueden fallar y, aun así, permitir que los hosts restantes alojen las instancias en ejecución
***Ejemplo:*** un Outpost tiene tres hosts que aportan espacios a un grupo `m5.2xlarge` de capacidad. El primero aporta 4 plazas, el segundo aporta 3 plazas y el tercer anfitrión aporta 2 plazas. El grupo de `m5.2xlarge` instancias del Outpost tiene una capacidad total de 9 ranuras (4 \$1 3 \$1 2). El Outpost tiene 4 instancias en ejecución`m5.2xlarge`. ¿Cuántos hosts pueden fallar y seguir permitiendo que los hosts restantes alojen las instancias en ejecución?
![\[Tres ecuaciones\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/aws-outposts-high-availability-design/images/equations.png)
***Respuesta:*** Puede perder cualquiera de los hosts y seguir manteniendo las instancias en ejecución en los hosts restantes.
## Prácticas recomendadas para la planificación de la capacidad de cómputo
+ Dimensione su capacidad de cómputo para proporcionar una redundancia N\$1M para cada grupo de EC2 capacidad de un Outpost.
+ Implemente servidores N\$1M para servidores con configuraciones homogéneas de slots, o bien heterogéneas e idénticas.
+ Calcule la disponibilidad de N\$1M para cada grupo de EC2 capacidad y asegúrese de que cada grupo cumpla con sus requisitos de disponibilidad.
# Administración de la capacidad
Puede supervisar el uso del grupo de EC2 instancias de Outpost en las CloudWatch métricas de Amazon Consola de administración de AWS y a través de ellas. Póngase en contacto con Enterprise Support para recuperar o cambiar los diseños de slots de las implementaciones de Outposts.
Utiliza los mismos mecanismos de [recuperación automática de instancias](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-recover.html) y [EC2 Auto Scaling](https://aws.amazon.com/ec2/autoscaling/) para recuperar o reemplazar las instancias afectadas por fallas del servidor y eventos de mantenimiento. Se debe supervisar y administrar la capacidad de Outposts para garantizar que siempre haya suficiente capacidad de reserva disponible para adaptarse a los errores del servidor. La publicación [https://aws.amazon.com/blogs/compute/managing-your-aws-outposts-capacity-using-amazon-cloudwatch-and-aws-lambda/](https://aws.amazon.com/blogs/compute/managing-your-aws-outposts-capacity-using-amazon-cloudwatch-and-aws-lambda/) blog contiene un tutorial práctico en el que se muestra cómo combinar AWS CloudWatch y gestionar la capacidad de Outpost AWS Lambda para mantener la disponibilidad de las instancias.
![\[Diagrama que muestra la gestión AWS Outposts de la capacidad con Amazon CloudWatch y AWS Lambda\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/aws-outposts-high-availability-design/images/managing-outposts-capacity.png)
Las reservas de capacidad se pueden utilizar en un entorno de varias cuentas para controlar la cantidad de la capacidad informática de Outpost que utiliza una sola cuenta o una unidad AWS organizativa (OU) que contiene varias cuentas. Puedes crear una reserva de capacidad para Amazon EC2 en Outposts, así como para Outposts compatibles, como Amazon Elastic Kubernetes Service (EKS), Amazon Elastic Container Service (ECS) y Amazon Elastic Map Reduce (EMR). Servicios de AWS Las reservas de capacidad se crean y comparten en las cuentas a través de AWS Resource Access Manager (AWS RAM) en la cuenta del propietario de Outpost. La sección [Cómo crear cuotas informáticas en AWS Outposts rack con el uso compartido de reservas de EC2 capacidad](https://aws.amazon.com/blogs/compute/creating-computing-quotas-on-aws-outposts-rack-with-ec2-capacity-reservation-sharing/) ofrece un tutorial práctico y orientación adicional para implementar las reservas de capacidad con su Outpost con el fin de gestionar la capacidad.
![\[Diagrama que muestra los pasos 1 a 4 del proceso de reserva de capacidad compartida\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/aws-outposts-high-availability-design/images/page-36-capacity-reservation-sharing-process-steps-1-4.png)
![\[Diagrama que muestra los pasos 5 y 6 del proceso de capacidad compartida de reservas\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/aws-outposts-high-availability-design/images/page-37-capacity-reservation-sharing-process-steps-5-6.png)
## Prácticas recomendadas para la administración de la capacidad de cómputo
+ Configura tus EC2 instancias en grupos de Auto Scaling o usa la recuperación automática de instancias para reiniciar las instancias fallidas.
+ Automatice la supervisión de la capacidad de las implementaciones de Outposts y configure las notificaciones y (opcionalmente) las respuestas automatizadas para las alarmas de capacidad.
+ Utilice las reservas de capacidad para tener un control pormenorizado sobre la cantidad de capacidad informática que se comparte con otras cuentas de su AWS organización.
# Ubicación de instancias
Los Outposts tienen un número finito de hosts de cómputo. Si tu aplicación despliega varias instancias relacionadas en Outposts, sin configuración adicional, las instancias se pueden implementar en los mismos hosts o en hosts del mismo rack. En la actualidad, existen tres mecanismos para distribuir las instancias a fin de mitigar el riesgo de ejecutar instancias relacionadas en la misma infraestructura:
**Implementación de varias instancias de Outposts**: de forma similar a una estrategia con múltiples zonas de disponibilidad en la región, se pueden implementar varias instancias de Outposts en centros de datos independientes, así como recursos de aplicaciones para instancias específicas de Outposts. Esto permite ejecutar instancias en la implementación de Outposts deseada (un conjunto lógico de bastidores). [La comunicación dentro de la VPC](https://aws.amazon.com/about-aws/whats-new/2023/08/aws-outposts-rack-intra-vpc-communication-multiple-outposts/) entre varios Outposts con enrutamiento directo de VPC es otra estrategia que se puede utilizar para distribuir las cargas de trabajo entre varios Outposts dentro de la misma VPC mediante las puertas de enlace locales (LGW) de Outpost para crear rutas entre las subredes de los Outposts. Se puede emplear una estrategia de Outpost múltiple para protegerse contra los modos de falla del rack y del centro de datos y, si los Outposts están anclados a regiones AZs o regiones separadas, también pueden brindar protección contra los modos de falla AZ o regional. Para obtener más información acerca de las arquitecturas con múltiples implementaciones de Outposts, consulte la publicación [Modos de error más extensos](larger-failure-modes.md).
**Grupos de EC2 ubicación de Amazon en Outposts** (ubicación de una sola instancia de Outpost con varios estantes): puedes crear [grupos de ubicación en Outposts](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups-outpost.html) que hayas creado en tu cuenta. Esto le permite distribuir instancias en el equipo subyacente en un Outpost en su sitio. Cuando crea un grupo de ubicación con una estrategia de distribución en Outpost, puede elegir que el grupo de ubicación distribuya instancias entre hosts o bastidores.
Un grupo de ubicación distribuida proporciona una forma sencilla de distribuir las instancias individuales entre racks o hosts para reducir la posibilidad de que se produzcan errores correlacionados. Solo puede implementar en el grupo tantas instancias como hosts tenga en su Outpost.
![\[Diagrama que muestra un grupo de ubicaciones EC2 dispersas en un Outpost con tres estantes\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/aws-outposts-high-availability-design/images/ec2-spread-placement-group.png)
También se pueden distribuir las instancias en varios bastidores con grupos con ubicación en particiones. La distribución automática se utiliza para distribuir las instancias entre las particiones del grupo o implementar las instancias en las particiones de destino seleccionadas. La implementación de instancias en las particiones de destino permite implementar los recursos seleccionados en el mismo bastidor y, al mismo tiempo, distribuir otros recursos entre todos los bastidores. Por ejemplo, si el usuario dispone de una instancia lógica de Outposts con tres bastidores, crear un grupo con ubicación en particiones con tres particiones le va a permitir distribuir los recursos entre los bastidores.
![\[Diagrama que muestra los grupos de ubicación de EC2 particiones en un puesto avanzado con tres estantes\]](http://docs.aws.amazon.com/es_es/whitepapers/latest/aws-outposts-high-availability-design/images/ec2-partition-placement-groups.png)
**Configuración creativa de slots para servidores**: si el usuario cuenta con una implementación de Outposts de un solo bastidor o si el servicio que utiliza en Outposts no admite grupos de ubicación, es posible que pueda utilizar una configuración de slots creativa para que las instancias no se implementen en el mismo servidor físico. Si las instancias relacionadas tienen el mismo tamaño de EC2 instancia, es posible que pueda colocar ranuras en sus servidores para limitar la cantidad de ranuras de ese tamaño configuradas en cada servidor, distribuyendo las ranuras entre los servidores. La configuración de slots de los servidores limitará el número de instancias (de ese tamaño) que se pueden ejecutar en un único servidor.
Un ejemplo es el diseño de configuración de slots que se ha mostrado anteriormente en la figura 13. Si su aplicación necesitara implementar tres `m5.4xlarge` instancias en el Outpost configurado con este diseño de ranuras, EC2 colocaría cada instancia en un servidor independiente y no habría posibilidad de que estas instancias se ejecutaran en el mismo servidor, siempre que la configuración de asignación de ranuras no cambie para abrir `m5.4xlarge` ranuras adicionales en los servidores.
## Prácticas recomendadas para la colocación de instancias de cómputo
+ Usa [los grupos de EC2 ubicación de Amazon en Outposts](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/placement-groups-outpost.html) para controlar la ubicación de las instancias en los racks dentro de un único Outpost lógico.
+ En lugar de pedir un Outpost con un único rack de Outpost de tamaño mediano o grande, considere dividir la capacidad en dos racks pequeños o medianos para aprovechar la capacidad de los grupos de EC2 ubicación para distribuir las instancias entre los racks.
+ [El grupo Amazon EC2 Placement en Outposts se puede utilizar para influir en la ubicación de los grupos de nodos de EKS, los nodos del plano de control para el clúster local de EKS y la tarea de ECS.](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-placement-strategies.html)
+ Usa la comunicación dentro de la VPC para distribuir las cargas de trabajo entre varios Outposts dentro de la misma VPC.