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.
Beispiel für einen Anwendungsfall von Corp. Automotive
In diesem Abschnitt des Whitepapers wird gezeigt, wie die Überlegungen, Fragen zur Anforderungsdefinition und Entscheidungsbäume Ihnen bei der Entscheidung für das optimale Hybridnetzwerkdesign helfen. Das Identifizieren und Erfassen von Anforderungen ist wichtig, da sie als Grundlage für die Entscheidungsbäume verwendet werden. Durch die Erfassung von Anforderungen im Voraus werden weitere Entwurfsiterationen vermieden. Ein Projekt ganz zu unterbrechen, wenn der Entwurf überarbeitet werden muss und wertvolle Ressourcen zurückgehalten werden müssen, kann minimiert und idealerweise vermieden werden, wenn die Anforderungen im Voraus verstanden werden.
Das Beispiel Corp. Automotive wird in diesem Abschnitt zur Veranschaulichung des Kunden verwendet. Sie möchten zunächst ihr erstes Analyseprojekt am durchführen. AWS Das Analyseprojekt konzentriert sich auf die Analyse von Daten von vom Unternehmen hergestellten Autos und anderen Datensätzen, die bereits in den Rechenzentren des Unternehmens vorhanden sind. Zunächst ging die Architekturgruppe des Unternehmens davon ausAWS-Konto, dass sie eine Amazon-VPC und einige Subnetze benötigen, um Produktions- und Entwicklungsumgebungen zu hosten. Das Projektteam möchte unbedingt loslegen und hat so schnell wie möglich um Zugriff auf die Entwicklungsumgebung gebeten. Sie wollen in drei Monaten in Produktion gehen.
Beispiel Corp. Automotive plant außerdem, es in den AWS nächsten 6 Monaten AWS für mehrere zusätzliche Projekte zu nutzen, wie z. B. die Migration seiner ERP-Systeme, der virtuellen Desktop-Infrastruktur (VDI) und weiterer 20 Anwendungen von lokalen auf weitere Anwendungen. Einige Anforderungen für weitere Projekte werden noch definiert, aber es ist klar, dass ihre AWS Cloud Nutzung zunehmen wird.
Das Architekturteam entschied sich dafür, den in diesem Whitepaper beschriebenen Ansatz zu nutzen. Sie nutzten die im Rahmen der einzelnen Überlegungen dargelegten Fragen zur Anforderungsdefinition, um die Inputs für ihre Entwurfsentscheidungen zu erfassen.
Sie beginnen mit den Anforderungen an den Konnektivitätstyp, die in der folgenden Tabelle zusammengefasst sind.
Tabelle 4 — Beispiel für Angaben zur Zuverlässigkeit von Automotive Corp.
| Überlegungen zur Auswahl des Konnektivitätstyps | Fragen zur Definition von Anforderungen | Antworten |
|---|---|---|
| Zeit für die Bereitstellung | Was ist der erforderliche Zeitplan für die Bereitstellung? Stunden, Tage, Wochen oder Monate? |
|
| Sicherheit | Erlauben Ihre Sicherheitsanforderungen und -richtlinien die Verwendung verschlüsselter Verbindungen über das Internet, um eine Verbindung zu privaten Netzwerkverbindungen herzustellen, AWS oder schreiben Sie die Verwendung von privaten Netzwerkverbindungen vor? |
|
| Muss die Netzwerkschicht bei der Nutzung privater Netzwerkverbindungen für Verschlüsselung bei der Übertragung sorgen? | Nein, die Verschlüsselung auf Anwendungsebene wird verwendet. | |
| SLA | Ist ein SLA für Hybridkonnektivität mit Servicegutschriften erforderlich? |
|
| Was ist das Verfügbarkeitsziel? |
|
|
| Hält das gesamte Hybrid-Netzwerk das Verfügbarkeitsziel ein? |
|
|
| Leistung | Was ist der erforderliche Durchsatz? |
|
| Was ist die maximal akzeptable Latenz zwischen einem lokalen Netzwerk AWS und einem Netzwerk? |
|
|
| Was ist der maximal zulässige Netzwerk-Jitter? |
|
|
| Kosten | An wie viele Daten würden Sie AWS pro Monat senden? |
|
| Ab wie vielen Daten würden Sie AWS pro Monat versenden? |
|
|
| Ist diese Konnektivität dauerhaft? | Ja |
Auf der Grundlage der eingegangenen Anforderungen folgte das Architekturteam dem Entscheidungsbaum für den Konnektivitätstyp aus Abbildung 9. Auf diese Weise konnte das Architekturteam den Konnektivitätstyp für die Entwicklungs-, Test- und Produktionsumgebungen festlegen. Für die Produktionsumgebung berücksichtigten sie sowohl die unmittelbaren als auch die bevorstehenden Anforderungen. Für Entwicklungs- und Testzwecke wird Example Corp. Automotive ein site-to-site VPN über das Internet einrichten. Für die Produktion werden sie mit einem Dienstleister zusammenarbeiten, mit dem sie ihr Unternehmensnetzwerk verbinden können. AWS Direct Connect Example Corp. Automotive erwog zunächst die Verwendung einer gehosteten Direct Connect-Verbindung, entschied sich jedoch aufgrund der Anforderungen an ein AWSbereitgestelltes SLA
Nach der Entscheidung für den Konnektivitätstyp besteht der nächste Schritt darin, die Anforderungen zu erfassen, die sich auf die Auswahl des Konnektivitätsdesigns auswirken. Dies hängt mit dem logischen Design zusammen, z. B. mit der Art und Weise, wie die Verbindungen konfiguriert werden und welche AWS Dienste zur Erfüllung der geschäftlichen und technischen Anforderungen verwendet werden sollen.
Um die Anforderungen an Skalierbarkeit und Kommunikationsmodell zu erfassen, verwendete das Architekturteam die Fragen zur Anforderungsdefinition aus den entsprechenden Abschnitten dieses Whitepapers. Die Anforderungen im Zusammenhang mit diesen beiden Überlegungen sind in der folgenden Tabelle zusammengefasst.
Tabelle 5 — Fragen zur Definition von Anforderungen
| Überlegungen zur Auswahl des Konnektivitätsdesigns | Fragen zur Anforderungsdefinition | Antworten |
|---|---|---|
| Skalierbarkeit | Wie hoch ist die aktuelle oder erwartete Anzahl von VPCs, die Konnektivität zu lokalen Standorten benötigen? | anfänglich 2, innerhalb von 6 Monaten auf 30 angewachsen |
| Werden diese VPCs in einer AWS-Region oder mehreren Regionen eingesetzt? | Einzelne Region | |
| Mit wie vielen lokalen Standorten muss eine Verbindung hergestellt werden? AWS | 2 Rechenzentren | |
| Mit wie vielen Kunden-Gateway-Geräten pro Standort müssen Sie eine Verbindung herstellenAWS? | 2 Router pro Rechenzentrum | |
| Wie viele Routen werden voraussichtlich an AWS VPCs angekündigt, und wie viele Routen werden voraussichtlich von der Seite empfangen? AWS |
|
|
| Ist geplant, in naher future eine Erhöhung der Bandbreite der Verbindung AWS in Betracht zu ziehen? |
|
|
| Modelle für das Konnektivitätsdesign | Muss die Kommunikation zwischen VPC aktiviert sein (innerhalb einer Region und/oder zwischen Regionen)? | Ja, innerhalb eines AWS-Region |
| Ist es erforderlich, direkt vor Ort auf AWS öffentliche Endpunktdienste zuzugreifen? | Ja | |
| Ist der Zugriff auf AWS Dienste mithilfe von VPC-Endpunkten vor Ort erforderlich? | Nein |
Auf der Grundlage der Eingaben folgte das Architekturteam der Entscheidungsstruktur aus dem Abschnitt Konnektivitätsdesign. Nachdem das Architekturteam davon ausgegangen war, dass die Anzahl der VPCs in den nächsten 6 Monaten von 2 auf 30 steigen wird, entschied sich das Architekturteam für die Verwendung AWS Transit Gateway als Terminierungs-Gateway für die Verbindung und für das Routing zwischen VPC. Unabhängige AWS Transit Gateway Unternehmen werden die VPN-Verbindung beenden, die für Entwicklung und Tests sowie für die Produktionskonnektivität mit verwendet wurde. AWS Direct Connect Die Verwendung getrennter AWS Transit Gateway s vereinfacht das Änderungsmanagement und sorgt für eine klare Abgrenzung zwischen Entwicklungs- und Testumgebungen und Produktionsumgebungen. Für die Produktion ist ein AWS Direct Connect Gateway aus folgenden Gründen erforderlich. AWS Transit Gateway Eine öffentliche VIF wird für den Zugriff auf AWS öffentliche Endpunktdienste verwendet. Abbildung 14 zeigt den Pfad, der im Entscheidungsbaum auf der Grundlage der gesammelten Anforderungen eingeschlagen wurde.
Abbildung 14 — Beispiel für einen Entscheidungsbaum für das Verbindungsdesign von Corp. Automotive
Nachdem Sie sich für die Lösung entschieden haben, die die Anforderungen an Skalierbarkeit und Kommunikationsmodell erfüllt, besteht der nächste Schritt darin, die Anforderungen im Zusammenhang mit der Zuverlässigkeit zu erfassen. Dies hängt mit dem erforderlichen Maß an Verfügbarkeit und Belastbarkeit zusammen.
Um die Zuverlässigkeitsanforderungen zu erfassen, verwendete das Architekturteam die Fragen zur Anforderungsdefinition aus dem entsprechenden Abschnitt dieses Whitepapers. Die Anforderungen sind in der folgenden Tabelle zusammengefasst.
Tabelle 6 — Fragen zu den Zuverlässigkeitsanforderungen
| Überlegungen zur Auswahl des Konnektivitätsdesigns | Fragen zur Anforderungsdefinition | Antworten |
|---|---|---|
| Zuverlässigkeit | Wie groß sind die Auswirkungen auf das Unternehmen im Falle eines VerbindungsausfallsAWS? |
|
| AWSÜberwiegen aus geschäftlicher Sicht die Kosten für die Folgen eines Verbindungsausfalls die Kosten für die Implementierung eines äußerst zuverlässigen Konnektivitätsmodells fürAWS? |
|
Auf der Grundlage der eingegangenen Beiträge folgte das Architekturteam dem Entscheidungsbaum aus den Abschnitten zu den Zuverlässigkeitsüberlegungen, die zuvor in diesem Whitepaper behandelt wurden. Nach Berücksichtigung des angestrebten Verfügbarkeitsziels von 99,99% für die Produktionskonnektivität und der hohen Auswirkungen auf das Geschäft bei einer Betriebsunterbrechung entschied sich das Architekturteam für die Nutzung von 2 Direct Connect-Standorten und die Einrichtung von 2 Verbindungen von jedem lokalen Rechenzentrum zu jedem Direct Connect-Standort (insgesamt 4 Links). Die für Entwicklung und Tests verwendete VPN-Konnektivität wird außerdem zwei VPN-Verbindungen für zusätzliche Redundanz verwenden. Mithilfe von Techniken zur Routenplanung, die im Abschnitt Zuverlässigkeit erörtert wurden, wird die Konnektivität wie folgt konfiguriert:
-
Für Entwicklungs- und Testzwecke wird der Datenverkehr mithilfe von ECMP über die beiden Tunnel zum primären Rechenzentrum verteilt. Dies ermöglicht einen höheren Durchsatz. Die Tunnel, die zum sekundären Rechenzentrum führen, werden im Falle eines Ausfalls der primären Tunnel verwendet.
-
In der Produktion ist die Latenz zwischen den lokalen Standorten und AWS über einen der Direct Connect-Standorte sehr ähnlich. In diesem Fall wurde entschieden, für die lokalen Systeme, die im primären Rechenzentrum bereitgestellt werden, einen Lastenausgleich für den Datenverkehr zwischen AWS und vor Ort über die beiden Verbindungen zum primären Rechenzentrum durchzuführen. In ähnlicher Weise erfolgt bei lokalen Systemen, die im sekundären Rechenzentrum ausgeführt werden, ein Lastenausgleich zwischen den beiden Verbindungen zum sekundären Rechenzentrum. Im Falle eines Ausfalls der Verbindungen ermöglicht BGP einen automatisierten Failover.
Abbildung 15 zeigt den Weg, der in der Entscheidungsstruktur auf der Grundlage der gesammelten Anforderungen eingeschlagen wurde.
Abbildung 15 — Beispiel für einen Entscheidungsbaum zur Zuverlässigkeit von Corp. Automotive
