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.
# Prácticas recomendadas
## Prácticas recomendadas de Amazon EC2
Siga las prácticas recomendadas de EC2 y garantice una disponibilidad suficiente de almacenamiento de datos.
[https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-best-practices.html](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-best-practices.html)
## Programador de Linux
El programador de Linux puede reordenar los paquetes en los sockets UDP si los procesos correspondientes no están anclados a un núcleo específico. Cualquier subproceso que envíe o reciba datos UDP debe fijarse a un núcleo específico durante la transmisión de datos.
## AWS Ground Station lista de prefijos gestionada
Se recomienda utilizar la lista de prefijos gestionada por AWS `com.amazonaws.global.groundstation` al especificar las reglas de red para permitir la comunicación desde la antena. Para obtener más información sobre las listas de prefijos administradas por AWS, consulte [Trabajar con listas de prefijos administradas por AWS](https://docs.aws.amazon.com/vpc/latest/userguide/working-with-aws-managed-prefix-lists.html)
## Limitación de contacto único
El agente de AWS Ground Station admite varias transmisiones por contacto, pero solo admite un contacto a la vez. Para evitar problemas de programación, no comparta una instancia entre varios grupos de puntos de conexión de flujos de datos. Si la configuración de un solo agente está asociada a varios DFEG diferentes ARNs, no se registrará.
## Ejecutar servicios y procesos junto con el agente AWS Ground Station
Al lanzar servicios y procesos en la misma instancia EC2 que el AWS Ground Station agente, es importante vincularlos a una v que CPUs no esté siendo utilizada por el AWS Ground Station agente y el núcleo de Linux, ya que esto puede provocar cuellos de botella e incluso la pérdida de datos durante los contactos. Este concepto de unión a un v específico CPUs se conoce como afinidad.
Núcleos que se deben evitar:
+ `agentCpuCores` de [Archivo de configuración del agente](configuring-agent.md#agent-config-file)
+ `interrupt_core_list` de [Ajuste las interrupciones del hardware y las colas de recepción, lo que repercute en la CPU y la red](ec2-instance-performance-tuning.md#tune-hardware-interrupts).
+ Los valores predeterminados se pueden encontrar en [Apéndice: Parámetros recomendados para interrupt/RPS la puesta a punto](ec2-instance-performance-tuning.md#recommended-parameters)
### Como ejemplo, usar una `c5.24xlarge` instancia
Si especificó
`"agentCpuCores": [24,25,26,27,72,73,74,75]"`
y corrió
`echo "@reboot sudo /opt/aws/groundstation/bin/set_irq_affinity.sh '0,1,48,49' 'ffffffff,ffffffff,ffffffff' >> /var/log/user-data.log 2>&1" >>/var/spool/cron/root`
luego evita los siguientes núcleos:
`0,1,24,25,26,27,48,49,72,73,74,75`
### Servicios de afinización (systemd)
Los servicios recién lanzados se afinizarán automáticamente con los mencionados anteriormente. `interrupt_core_list` Si el caso de uso de sus servicios lanzados requiere núcleos adicionales o necesita núcleos menos congestionados, siga esta sección.
Compruebe la afinidad con la que está configurado su servicio actualmente con el comando:
```
systemctl show --property CPUAffinity
```
Si ves un valor vacío`CPUAffinity=`, por ejemplo, significa que probablemente usará los núcleos predeterminados del comando anterior `...bin/set_irq_affinity.sh ...`
Para anular y establecer una afinidad específica, busca la ubicación del archivo de servicio ejecutando:
```
systemctl show -p FragmentPath
```
Abra y modifique el archivo (usando `vi``nano`, etc.) y colóquelo `CPUAffinity=` en la `[Service]` sección de la siguiente manera:
```
[Unit]
...
[Service]
...
CPUAffinity=2,3
[Install]
...
```
Guarde el archivo y reinicie el servicio para aplicar la afinidad con:
```
systemctl daemon-reload
systemctl restart
# Additionally confirm by re-running
systemctl show --property CPUAffinity
```
Para obtener más información, visite: [Red Hat Enterprise Linux 8: Administración, supervisión y actualización del núcleo, capítulo 27. Configuración de las políticas NUMA y de afinidad de la CPU mediante systemd](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/managing_monitoring_and_updating_the_kernel/assembly_configuring-cpu-affinity-and-numa-policies-using-systemd_managing-monitoring-and-updating-the-kernel).
### Procesos de afinización (scripts)
Se recomienda encarecidamente afinizar manualmente los scripts y procesos recién lanzados, ya que el comportamiento predeterminado de Linux les permitirá utilizar cualquier núcleo de la máquina.
Para evitar conflictos fundamentales en cualquier proceso en ejecución (como python, scripts bash, etc.), inicie el proceso con:
```
taskset -c
# Example: taskset -c 8 ./bashScript.sh
```
Si el proceso ya se está ejecutando, utilice comandos como `pidof``top`, o `ps` busque el ID de proceso (PID) del proceso específico. Con el PID puede ver la afinidad actual con:
```
taskset -p
```
y puede modificarla con:
```
taskset -p
# Example: taskset -p c 32392 (which sets it to cores 0xc -> 0b1100 -> cores 2,3)
```
Para obtener más información sobre el conjunto de tareas, consulte la página de manual de [taskset: Linux](https://linux.die.net/man/1/taskset)