Configurar el VPC acceso para que las aplicaciones EMR sin servidor se conecten a los datos - Amazon EMR

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.

Configurar el VPC acceso para que las aplicaciones EMR sin servidor se conecten a los datos

Puede configurar las aplicaciones EMR sin servidor para que se conecten a sus almacenes de datosVPC, como los clústeres de Amazon Redshift, las bases de datos de Amazon o los VPC buckets de RDS Amazon S3 con puntos de enlace. Su aplicación EMR sin servidor tiene conectividad saliente con los almacenes de datos que contiene. VPC De forma predeterminada, EMR Serverless bloquea el acceso entrante a sus aplicaciones para mejorar la seguridad.

nota

Debe configurar el VPC acceso si quiere utilizar una base de datos externa de Hive metastore para su aplicación. Para obtener información sobre cómo configurar un metaalmacén de Hive externo, consulte Configuración de metaalmacén.

Crear aplicación

En la página Crear aplicación, puede elegir una configuración personalizada y especificar las subredes y los VPC grupos de seguridad que pueden usar las aplicaciones EMR sin servidor.

VPCs

Elija el nombre de la nube privada virtual (VPC) que contiene sus almacenes de datos. La página de creación de aplicaciones muestra todas VPCs las que haya elegido Región de AWS.

Subredes

Elija las subredes de la VPC que contiene el banco de datos. La página Crear aplicación muestra todas las subredes de los almacenes de datos de su. VPC Se admiten tanto las subredes públicas como las privadas. Puede transferir subredes públicas o privadas a sus aplicaciones. La elección de tener una subred pública o privada tiene algunas consideraciones asociadas que hay que tener en cuenta.

Para las subredes privadas:

nota

Al configurar una aplicación Amazon EMR Serverless en una subred privada, le recomendamos que también configure VPC puntos de enlace para Amazon S3. Si su aplicación EMR sin servidor se encuentra en una subred privada sin VPC puntos de enlace para Amazon S3, podría incurrir en cargos de NAT puerta de enlace adicionales asociados al tráfico de S3. Esto se debe a que el tráfico entre su EMR aplicación y Amazon S3 no permanecerá dentro de usted VPC si los VPC puntos de enlace no están configurados.

Para las subredes públicas:

  • Tienen una ruta a un Internet Gateway.

  • Debe garantizar la configuración adecuada de los grupos de seguridad para controlar el tráfico saliente.

Los trabajadores pueden conectarse a sus almacenes de datos VPC a través del tráfico saliente. De forma predeterminada, EMR Serverless bloquea el acceso entrante a los trabajadores. Esto es para mejorar la seguridad.

Cuando lo usa AWS Config, EMR Serverless crea un registro de elementos de la interfaz de red elástica para cada trabajador. Para evitar los costos relacionados con este recurso, considere la posibilidad de desactivarloAWS::EC2::NetworkInterface. AWS Config

nota

Recomendamos seleccionar varias subredes entre varias zonas de disponibilidad. Esto se debe a que las subredes que elija determinan las zonas de disponibilidad disponibles para el lanzamiento de una aplicación EMR sin servidor. Cada trabajador consume una dirección IP en la subred en la que se lanza. Asegúrese de que las subredes especificadas tengan direcciones IP suficientes para la cantidad de trabajadores que planea lanzar. Para obtener más información sobre la planificación de subredes, consulte Prácticas recomendadas para la planificación de subredes.

Consideraciones y limitaciones de las subredes

  • EMRLa tecnología Serverless con subredes públicas no es compatible con AWS Lake Formation.

  • El tráfico entrante no es compatible con las subredes públicas.

Grupos de seguridad

Elija uno o varios grupos de seguridad que puedan comunicarse con sus almacenes de datos. La página Crear aplicación muestra todos los grupos de seguridad de su. VPC EMR Serverless asocia estos grupos de seguridad a las interfaces de red elásticas que están conectadas a las VPC subredes.

nota

Se recomienda crear un grupo de seguridad independiente para las aplicaciones EMR sin servidor. EMR Serverless no le permitirá crear, actualizar o iniciar una aplicación si los grupos de seguridad tienen puertos abiertos a la Internet pública en 0.0.0.0/0 o en el rango: :/0. Esto proporciona seguridad y aislamiento mejorados y hace que la administración de las reglas de la red sea más eficiente. Por ejemplo, esto bloquea el tráfico inesperado que llega a los trabajadores con direcciones IP públicas. Para comunicarse con los clústeres de Amazon Redshift, por ejemplo, puede definir las reglas de tráfico entre los grupos de seguridad de Redshift y EMR Serverless, como se muestra en el siguiente ejemplo.

ejemplo Ejemplo: comunicación con clústeres de Amazon Redshift
  1. Agregue una regla para el tráfico entrante al grupo de seguridad de Amazon Redshift desde uno de EMR los grupos de seguridad sin servidor.

    Tipo Protocolo Intervalo de puertos Origen

    Todas las TCP

    TCP

    5439

    emr-serverless-security-group

  2. Agregue una regla para el tráfico saliente desde uno de los grupos de seguridad sin servidor. EMR Puede hacerlo de dos formas. En primer lugar, puede abrir el tráfico saliente a todos los puertos.

    Tipo Protocolo Rango de puerto Destino

    Todo el tráfico

    TCP

    ALL

    0.0.0.0/0

    Como alternativa, puede restringir el tráfico saliente a los clústeres de Amazon Redshift. Esto solo resulta útil cuando la aplicación debe comunicarse con los clústeres de Amazon Redshift y nada más.

    Tipo Protocolo Intervalo de puertos Origen

    Todas las TCP

    TCP

    5439

    redshift-security-group

Configurar aplicación

Puede cambiar la configuración de red de una aplicación EMR sin servidor existente desde la página Configurar la aplicación.

Ver los detalles de la ejecución del trabajo

En la página de Detalles de la ejecución del trabajo, puede ver la subred utilizada por el trabajo para una ejecución específica. Tenga en cuenta que un trabajo solo se ejecuta en una subred seleccionada desde las subredes especificadas.

Prácticas recomendadas para la planificación de subredes

AWS los recursos se crean en una subred que es un subconjunto de direcciones IP disponibles en Amazon. VPC Por ejemplo, una VPC con una máscara de red /16 tiene hasta 65.536 direcciones IP disponibles que se pueden dividir en varias redes más pequeñas mediante máscaras de subred. Por ejemplo, puede dividir este rango en dos subredes, con cada una de las cuales usando una máscara /17 y 32 768 direcciones IP disponibles. Una subred reside en una zona de disponibilidad y no puede abarcar otras zonas.

Las subredes deben diseñarse teniendo en cuenta los límites de escalado de las aplicaciones sin servidor. EMR Por ejemplo, si tiene una aplicación que solicita 4 vCpu trabajadores y puede ampliarse hasta 4000vCpu, su aplicación necesitará como máximo 1000 trabajadores para un total de 1000 interfaces de red. Recomendamos crear varias subredes entre varias zonas de disponibilidad. Esto permite a EMR Serverless volver a intentar su trabajo o aprovisionar la capacidad preinicializada en una zona de disponibilidad diferente en el improbable caso de que se produzca un error en una zona de disponibilidad. Por lo tanto, cada subred de al menos dos zonas de disponibilidad debe tener más de 1000 direcciones IP disponibles.

Necesita subredes con un tamaño de máscara inferior o igual a 22 para aprovisionar 1000 interfaces de red. Cualquier máscara superior a 22 no cumplirá el requisito. Por ejemplo, una máscara de subred de /23 proporciona 512 direcciones IP, mientras que una máscara de /22 proporciona 1024 y una máscara de /21 proporciona 2048 direcciones IP. A continuación, se muestra un ejemplo de 4 subredes con una máscara de /22 en una máscara de red VPC de /16 que se pueden asignar a distintas zonas de disponibilidad. Hay una diferencia de cinco entre las direcciones IP disponibles y utilizables porque las cuatro primeras direcciones IP y la última dirección IP de cada subred están reservadas por. AWS

ID de subred Dirección de subred Máscara de subred Rangos de direcciones IP Direcciones IP disponibles Direcciones IP utilizables

1

10.0.0.0

255.255.252.0/22

10.0.0.0-10.0.3.255

1 024

1.019

2

10.0.4.0

255.255.252.0/22

10.0.4.0-10.0.7.255

1 024

1.019

3

10.0.8.0

255.255.252.0/22

10.0.4.0-10.0.7.255

1 024

1.019

4

10.0.12.0

255.255.252.0/22

10.0.12.0-10.0.15.255

1 024

1.019

Debe evaluar si su carga de trabajo es la más adecuada para trabajadores de mayor tamaño. El uso de trabajadores de mayor tamaño requiere menos interfaces de red. Por ejemplo, el uso de 16 vCpu trabajadores con un límite de escalado de aplicaciones de 4000 vCpu requerirá como máximo 250 trabajadores para un total de 250 direcciones IP disponibles para aprovisionar las interfaces de red. Necesita subredes en varias zonas de disponibilidad con un tamaño de máscara inferior o igual a 24 para aprovisionar 250 interfaces de red. Cualquier tamaño de máscara superior a 24 ofrece menos de 250 direcciones IP.

Si comparte subredes entre varias aplicaciones, cada subred debe diseñarse teniendo en cuenta los límites de escalado colectivos de todas sus aplicaciones. Por ejemplo, si tiene 3 aplicaciones que solicitan 4 vCpu trabajadores y cada una puede ampliarse hasta 4000 vCpu con una cuota de 12 000 basada en el servicio a vCpu nivel de cuenta, cada subred necesitará 3000 direcciones IP disponibles. Si la VPC que desea utilizar no tiene un número suficiente de direcciones IP, intente aumentar el número de direcciones IP disponibles. Para ello, asocie bloques adicionales de enrutamiento entre dominios sin clase (CIDR) a su. VPC Para obtener más información, consulta Asociar IPv4 CIDR bloques adicionales a los tuyos VPC en la Guía del VPC usuario de Amazon.

Puede utilizar una de las numerosas herramientas disponibles en línea para generar rápidamente definiciones de subredes y revisar su rango disponible de direcciones IP.