Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Konfiguration des VPC-Zugriffs für serverlose EMR-Anwendungen zur Verbindung mit Daten
Sie können serverlose EMR-Anwendungen so konfigurieren, dass sie eine Verbindung zu Ihren Datenspeichern in Ihrer VPC herstellen, z. B. Amazon Redshift Redshift-Cluster, Amazon RDS-Datenbanken oder Amazon S3 S3-Buckets mit VPC-Endpunkten. Ihre EMR Serverless-Anwendung verfügt über ausgehende Konnektivität zu den Datenspeichern in Ihrer VPC. Standardmäßig blockiert EMR Serverless den eingehenden Zugriff auf Ihre Anwendungen, um die Sicherheit zu verbessern.
Anmerkung
Sie müssen den VPC-Zugriff konfigurieren, wenn Sie eine externe Hive-Metastore-Datenbank für Ihre Anwendung verwenden möchten. Informationen zur Konfiguration eines externen Hive-Metastores finden Sie unter Metastore-Konfiguration.
Anwendung erstellen
Auf der Seite Anwendung erstellen können Sie benutzerdefinierte Einstellungen auswählen und die VPC, Subnetze und Sicherheitsgruppen angeben, die EMR Serverless-Anwendungen verwenden können.
VPCs
Wählen Sie den Namen der Virtual Private Cloud (VPC), die Ihre Datenspeicher enthält. Auf der Seite „Anwendung erstellen“ werden alle VPCs für Sie ausgewählten AWS-Region Anwendungen aufgeführt.
Subnetze
Wählen Sie die Subnetze innerhalb der VPC aus, die Ihren Datenspeicher enthält. Auf der Seite Anwendung erstellen werden alle Subnetze für die Datenspeicher in Ihrer VPC aufgeführt. Sowohl öffentliche als auch private Subnetze werden unterstützt. Sie können entweder private oder öffentliche Subnetze an Ihre Anwendungen übergeben. Bei der Entscheidung, ob ein öffentliches oder ein privates Subnetz eingerichtet werden soll, sind einige Überlegungen zu beachten.
Für private Subnetze:
Die zugehörigen Routing-Tabellen dürfen keine Internet-Gateways haben.
Für ausgehende Verbindungen zum Internet konfigurieren Sie bei Bedarf ausgehende Routen mithilfe eines NAT-Gateways. Informationen zur Konfiguration eines NAT-Gateways finden Sie unter NAT-Gateways.
Für Amazon S3 S3-Konnektivität konfigurieren Sie entweder ein NAT-Gateway oder einen VPC-Endpunkt. Informationen zur Konfiguration eines S3-VPC-Endpunkts finden Sie unter Gateway-Endpunkt erstellen.
Wenn Sie einen S3-VPC-Endpunkt konfigurieren und eine Endpunktrichtlinie zur Zugriffskontrolle anhängen, müssen Sie die Anweisungen unter Logging for EMR Serverless with managed storage befolgen, um EMR Serverless Berechtigungen zum Speichern und Bereitstellen von Anwendungsprotokollen zu erteilen.
Für Konnektivität zu anderen Geräten AWS-Services außerhalb der VPC, z. B. zu Amazon DynamoDB, konfigurieren Sie entweder VPC-Endpunkte oder ein NAT-Gateway. Informationen zur Konfiguration von VPC-Endpunkten finden Sie unter Arbeiten mit VPC-Endpunkten. AWS-Services
Anmerkung
Wenn Sie eine Amazon EMR Serverless-Anwendung in einem privaten Subnetz einrichten, empfehlen wir, dass Sie auch VPC-Endpunkte für Amazon S3 einrichten. Wenn sich Ihre serverlose EMR-Anwendung in einem privaten Subnetz ohne VPC-Endpunkte für Amazon S3 befindet, können zusätzliche NAT-Gateway-Gebühren anfallen, die mit dem S3-Verkehr verbunden sind. Dies liegt daran, dass der Datenverkehr zwischen Ihrer EMR-Anwendung und Amazon S3 nicht innerhalb Ihrer VPC verbleibt, wenn VPC-Endpunkte nicht konfiguriert sind.
Für öffentliche Subnetze:
Diese haben eine Route zu einem Internet Gateway.
Sie müssen sicherstellen, dass die Sicherheitsgruppen ordnungsgemäß konfiguriert sind, um den ausgehenden Verkehr zu kontrollieren.
Mitarbeiter können über ausgehenden Datenverkehr eine Verbindung zu den Datenspeichern in Ihrer VPC herstellen. Standardmäßig blockiert EMR Serverless den eingehenden Zugriff für Mitarbeiter. Dies dient der Verbesserung der Sicherheit.
Wenn Sie es verwenden AWS Config, erstellt EMR Serverless einen elastic network interface Interface-Elementdatensatz für jeden Worker. Um Kosten im Zusammenhang mit dieser Ressource zu vermeiden, sollten Sie die Option deaktivierenAWS::EC2::NetworkInterface. AWS Config
Anmerkung
Wir empfehlen, dass Sie mehrere Subnetze in mehreren Availability Zones auswählen. Dies liegt daran, dass die von Ihnen ausgewählten Subnetze die Availability Zones bestimmen, die für den Start einer EMR Serverless-Anwendung verfügbar sind. Jeder Worker verwendet eine IP-Adresse in dem Subnetz, in dem er gestartet wird. Bitte stellen Sie sicher, dass die angegebenen Subnetze über ausreichend IP-Adressen für die Anzahl der Worker verfügen, die Sie starten möchten. Weitere Informationen zur Subnetzplanung finden Sie unter. Bewährte Methoden für die Subnetzplanung
Überlegungen und Einschränkungen für Subnetze
EMR Serverless mit öffentlichen Subnetzen unterstützt AWS Lake Formation nicht.
Eingehender Datenverkehr wird für öffentliche Subnetze nicht unterstützt.
Sicherheitsgruppen
Wählen Sie eine oder mehrere Sicherheitsgruppen aus, die mit Ihren Datenspeichern kommunizieren können. Auf der Seite Anwendung erstellen werden alle Sicherheitsgruppen in Ihrer VPC aufgeführt. EMR Serverless verknüpft diese Sicherheitsgruppen mit elastischen Netzwerkschnittstellen, die an Ihre VPC-Subnetze angeschlossen sind.
Anmerkung
Wir empfehlen, dass Sie eine separate Sicherheitsgruppe für EMR Serverless-Anwendungen erstellen. Mit EMR Serverless können Sie keine Anwendung erstellen/aktualisieren/starten, wenn Sicherheitsgruppen Ports für das öffentliche Internet im Bereich 0.0.0.0/0 oder: :/0 haben. Dies bietet mehr Sicherheit und Isolierung und macht die Verwaltung von Netzwerkregeln effizienter. Dadurch wird beispielsweise unerwarteter Datenverkehr an Mitarbeiter mit öffentlichen IP-Adressen blockiert. Um beispielsweise mit Amazon Redshift Redshift-Clustern zu kommunizieren, können Sie die Verkehrsregeln zwischen Redshift- und EMR-Serverless-Sicherheitsgruppen definieren, wie im folgenden Beispiel gezeigt.
Beispiel — Kommunikation mit Amazon Redshift Redshift-Clustern
-
Fügen Sie der Amazon Redshift Redshift-Sicherheitsgruppe eine Regel für eingehenden Datenverkehr aus einer der serverlosen EMR-Sicherheitsgruppen hinzu.
Typ Protocol (Protokoll) Port-Bereich Quelle Alle TCP
TCP
5439
emr-serverless-security-group -
Fügen Sie eine Regel für ausgehenden Datenverkehr von einer der EMR Serverless Security Groups hinzu. Dafür stehen Ihnen zwei Optionen zur Verfügung: Zunächst können Sie ausgehenden Datenverkehr zu allen Ports öffnen.
Typ Protocol (Protokoll) Port-Bereich Bestimmungsort Gesamter Datenverkehr
TCP
ALL
0.0.0.0/0
Alternativ können Sie den ausgehenden Datenverkehr auf Amazon Redshift Redshift-Cluster beschränken. Dies ist nur nützlich, wenn die Anwendung mit Amazon Redshift Redshift-Clustern kommunizieren muss und sonst nichts.
Typ Protocol (Protokoll) Port-Bereich Quelle Alle TCP
TCP
5439
redshift-security-group
Anwendung konfigurieren
Sie können die Netzwerkkonfiguration für eine bestehende EMR Serverless-Anwendung auf der Seite Anwendung konfigurieren ändern.
Details zur Auftragsausführung anzeigen
Auf der Detailseite der Auftragsausführung können Sie das Subnetz anzeigen, das von Ihrem Job für einen bestimmten Lauf verwendet wurde. Beachten Sie, dass ein Job nur in einem Subnetz ausgeführt wird, das aus den angegebenen Subnetzen ausgewählt wurde.
Bewährte Methoden für die Subnetzplanung
AWS Ressourcen werden in einem Subnetz erstellt, das eine Teilmenge der verfügbaren IP-Adressen in einer Amazon VPC darstellt. Beispielsweise verfügt eine VPC mit einer /16-Netzmaske über bis zu 65.536 verfügbare IP-Adressen, die mithilfe von Subnetzmasken in mehrere kleinere Netzwerke aufgeteilt werden können. Sie können diesen Bereich beispielsweise in zwei Subnetze aufteilen, von denen jedes die /17-Maske und 32.768 verfügbare IP-Adressen verwendet. Ein Subnetz befindet sich in einer Availability Zone und kann sich nicht zonenübergreifend erstrecken.
Die Subnetze sollten unter Berücksichtigung Ihrer Skalierungsgrenzen für serverlose EMR-Anwendungen entworfen werden. Wenn Sie beispielsweise eine Anwendung haben, die 4 vCPU-Worker anfordert und auf bis zu 4.000 vCPUs skaliert werden kann, benötigt Ihre Anwendung maximal 1.000 Worker für insgesamt 1.000 Netzwerkschnittstellen. Wir empfehlen, Subnetze für mehrere Availability Zones zu erstellen. Auf diese Weise kann EMR Serverless in einem unwahrscheinlichen Fall, wenn eine Availability Zone ausfällt, Ihren Job erneut versuchen oder vorinitialisierte Kapazität in einer anderen Availability Zone bereitstellen. Daher sollte jedes Subnetz in mindestens zwei Availability Zones über mehr als 1.000 verfügbare IP-Adressen verfügen.
Sie benötigen Subnetze mit einer Maskengröße von weniger als oder gleich 22, um 1.000 Netzwerkschnittstellen bereitzustellen. Jede Maske, die größer als 22 ist, erfüllt die Anforderung nicht. Eine Subnetzmaske von /23 bietet beispielsweise 512 IP-Adressen, während eine Maske von /22 1024 und eine Maske von /21 2048 IP-Adressen bereitstellt. Im Folgenden finden Sie ein Beispiel für 4 Subnetze mit /22-Maske in einer VPC mit /16-Netzmaske, die verschiedenen Availability Zones zugewiesen werden können. Es gibt einen Unterschied von fünf zwischen verfügbaren und verwendbaren IP-Adressen, da die ersten vier IP-Adressen und die letzte IP-Adresse in jedem Subnetz von reserviert sind. AWS
| Subnetz-ID | Subnetz-Adresse | Subnetzmaske | IP-Adressbereiche | Verfügbare IP-Adressen | Verwendbare IP-Adressen |
|---|---|---|---|---|---|
|
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,8,0 - 10,0,11,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 |
Sie sollten abwägen, ob Ihr Workload am besten für größere Mitarbeiter geeignet ist. Für die Verwendung größerer Mitarbeiter sind weniger Netzwerkschnittstellen erforderlich. Wenn Sie beispielsweise 16 vCPU-Worker mit einem Anwendungsskalierungslimit von 4.000 vCPUs verwenden, sind maximal 250 Mitarbeiter für insgesamt 250 verfügbare IP-Adressen für die Bereitstellung von Netzwerkschnittstellen erforderlich. Sie benötigen Subnetze in mehreren Availability Zones mit einer Maskengröße von weniger als oder gleich 24, um 250 Netzwerkschnittstellen bereitzustellen. Jede Maskengröße von mehr als 24 bietet weniger als 250 IP-Adressen.
Wenn Sie Subnetze für mehrere Anwendungen gemeinsam nutzen, sollte jedes Subnetz so konzipiert werden, dass die kollektiven Skalierungsgrenzen all Ihrer Anwendungen berücksichtigt werden. Wenn Sie beispielsweise 3 Anwendungen haben, die 4 vCPU-Worker anfordern, und jede Anwendung kann auf bis zu 4000 vCPUs mit einem dienstbasierten Kontingent von 12.000 vCPUs skaliert werden, benötigt jedes Subnetz 3000 verfügbare IP-Adressen. Wenn die VPC, die Sie verwenden möchten, nicht über eine ausreichende Anzahl von IP-Adressen verfügt, versuchen Sie, die Anzahl der verfügbaren IP-Adressen zu erhöhen. Das ist möglich, indem Sie zusätzliche CIDR-Blöcke (Classless Inter-Domain Routing) mit Ihrer VPC verbinden. Weitere Informationen finden Sie unter Zusätzliche IPv4 CIDR-Blöcke mit Ihrer VPC verknüpfen im Amazon VPC-Benutzerhandbuch.
Sie können eines der vielen online verfügbaren Tools verwenden, um schnell Subnetzdefinitionen zu generieren und den verfügbaren IP-Adressbereich zu überprüfen.
