Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Jaringan
Penyebaran Outpost bergantung pada koneksi yang tangguh ke jangkar AZ agar manajemen, pemantauan, dan operasi layanan berfungsi dengan baik. Anda harus menyediakan jaringan lokal Anda untuk menyediakan koneksi jaringan redundan untuk setiap rak Outpost dan konektivitas yang andal kembali ke titik jangkar di cloud. AWS Pertimbangkan juga jalur jaringan antara beban kerja aplikasi yang berjalan di Outpost dan sistem lokal dan cloud lainnya yang berkomunikasi dengan mereka — bagaimana Anda akan merutekan lalu lintas ini di jaringan Anda?
**Topics**
+ [Lampiran jaringan](network-attachment.md)
+ [Konektivitas jangkar](anchor-connectivity.md)
+ [Perutean aplikasi/beban kerja](applicationworkload-routing.md)
# Lampiran jaringan
Setiap AWS Outposts rak dikonfigurasi dengan top-of-rack sakelar redundan yang disebut Outpost Networking Devices (). ONDs Server komputasi dan penyimpanan di setiap rak terhubung ke keduanya ONDs. Anda harus menghubungkan setiap OND ke sakelar terpisah yang disebut Customer Networking Device (CND) di pusat data Anda untuk menyediakan beragam jalur fisik dan logis untuk setiap rak Outpost. ONDs terhubung ke Anda CNDs dengan satu atau lebih koneksi fisik menggunakan kabel serat optik dan transceiver optik. [Koneksi fisik](https://docs.aws.amazon.com/outposts/latest/userguide/local-network-connectivity.html#physical-connectivity) dikonfigurasi dalam tautan [grup agregasi tautan logis (LAG)](https://docs.aws.amazon.com/outposts/latest/userguide/local-network-connectivity.html#link-aggregation).
![\[Diagram yang menunjukkan Pos Luar Multi-rak dengan lampiran jaringan yang berlebihan\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/aws-outposts-high-availability-design/images/multi-rack-outpost.png)
Tautan OND ke CND selalu dikonfigurasi dalam LAG - bahkan jika koneksi fisiknya adalah kabel serat optik tunggal. Mengkonfigurasi tautan sebagai grup LAG memungkinkan Anda meningkatkan bandwidth tautan dengan menambahkan koneksi fisik tambahan ke grup logis. Tautan LAG dikonfigurasi sebagai batang Ethernet IEEE 802.1q untuk mengaktifkan jaringan terpisah antara Outpost dan jaringan lokal.
Setiap Outpost memiliki setidaknya dua jaringan terpisah secara logis yang perlu berkomunikasi dengan atau di seluruh jaringan pelanggan:
+ **Jaringan tautan layanan** - mengalokasikan alamat IP tautan layanan ke server Outpost dan memfasilitasi komunikasi dengan jaringan lokal untuk memungkinkan server terhubung kembali ke titik jangkar Outpost di Wilayah. Ketika Anda memiliki beberapa implementasi rak dalam satu Outposts logis, Anda perlu menetapkan Service Link /26 CIDR untuk setiap Rack.
+ **Jaringan Local Gateway** — memungkinkan komunikasi antara subnet VPC di Outpost dan jaringan lokal melalui Outpost Local Gateway (LGW).
Jaringan terpisah ini dilampirkan ke jaringan lokal dengan satu set [koneksi point-to-point IP](https://docs.aws.amazon.com/outposts/latest/userguide/local-network-connectivity.html#network-layer-connectivity) melalui tautan LAG. Setiap tautan OND ke CND LAG dikonfigurasi dengan VLAN IDs, point-to-point (/30 atau/31) subnet IP, dan peering eBGP untuk setiap jaringan terpisah (tautan layanan dan LGW). Anda harus mempertimbangkan tautan LAG, dengan subnetnya point-to-point VLANs dan, sebagai koneksi lapisan-2 tersegmentasi dan dirutekan layer-3. Koneksi IP yang dirutekan menyediakan jalur logis redundan yang memfasilitasi komunikasi antara jaringan terpisah di Outpost dan jaringan lokal.
![\[Diagram yang menunjukkan layanan link peering\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/aws-outposts-high-availability-design/images/service-link-peering.png)
![\[Diagram yang menunjukkan peering Gerbang Lokal\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/aws-outposts-high-availability-design/images/page-20-local-gateway-peering.png)
Anda harus menghentikan tautan LAG lapisan-2 (dan mereka VLANs) pada sakelar CND yang terpasang langsung dan mengonfigurasi antarmuka IP dan mengintip BGP pada sakelar CND. Anda tidak boleh menjembatani LAG VLANs antara sakelar pusat data Anda. Untuk informasi selengkapnya, lihat [Konektivitas lapisan jaringan](https://docs.aws.amazon.com/outposts/latest/userguide/local-network-connectivity.html#network-layer-connectivity) di *Panduan AWS Outposts Pengguna*.
Di dalam Outpost multi-rak yang logis, saling berhubungan ONDs secara berlebihan untuk menyediakan konektivitas jaringan yang sangat tersedia antara rak dan beban kerja yang berjalan di server. AWS bertanggung jawab atas ketersediaan jaringan di dalam Outpost.
## Praktik yang direkomendasikan untuk lampiran jaringan yang sangat tersedia tanpa ACE
+ Hubungkan setiap Outpost Networking Device (OND) di rak Outpost ke Customer Networking Device (CND) terpisah di pusat data.
+ Hentikan tautan lapisan-2, subnet IP lapisan-3 VLANs, dan pengintipan BGP pada sakelar Customer Networking Device (CND) yang terpasang langsung. Jangan menjembatani OND ke CND VLANs antara CNDs atau di seluruh jaringan lokal.
+ Tambahkan tautan ke Grup Agregasi Tautan (LAGs) untuk meningkatkan bandwidth yang tersedia antara Outpost dan pusat data. Jangan mengandalkan bandwidth agregat dari beragam jalur melalui keduanya ONDs.
+ Gunakan beragam jalur melalui redundan ONDs untuk menyediakan konektivitas tangguh antara jaringan Outpost dan jaringan lokal.
+ Untuk mencapai redundansi yang optimal dan memungkinkan pemeliharaan OND yang tidak mengganggu, kami menyarankan agar pelanggan mengonfigurasi iklan dan kebijakan BGP sebagai berikut:
+ Peralatan jaringan pelanggan harus menerima iklan BGP dari Outpost tanpa mengubah atribut BGP dan untuk mengaktifkan multipath/load-balancing to achieve optimal inbound traffic flows (from customer towards Outpost). AS-Path prepending is used for Outpost BGP prefixes to shift traffic away from a particular OND/uplink BGP jika pemeliharaan diperlukan. Jaringan pelanggan harus memilih rute dari Outpost dengan panjang AS-path 1 daripada rute dengan panjang AS-path 4, yaitu bereaksi terhadap as-Path prepending.
+ Jaringan pelanggan harus mengiklankan awalan BGP yang sama dengan atribut yang sama terhadap semua di Outpost. ONDs Secara default, beban jaringan Outpost menyeimbangkan lalu lintas keluar (menuju pelanggan) di antara semua uplink. Kebijakan perutean digunakan di sisi Outpost untuk mengalihkan lalu lintas dari OND tertentu jika pemeliharaan diperlukan. Awalan BGP yang sama dari sisi pelanggan pada semua ONDs diperlukan untuk melakukan pergeseran lalu lintas ini, dan melakukan pemeliharaan dengan cara yang tidak mengganggu. Ketika pemeliharaan diperlukan pada jaringan pelanggan, kami sarankan menggunakan AS-Path prepending untuk sementara mengalihkan lalu lintas dari uplink atau perangkat tertentu.
## Praktik yang direkomendasikan untuk lampiran jaringan yang sangat tersedia dengan ACE
Untuk penyebaran multi-rak dengan empat atau lebih rak komputasi, Anda harus menggunakan rak Agregation, Core, Edge (ACE), yang akan bertindak sebagai titik agregasi jaringan untuk mengurangi jumlah tautan serat ke perangkat jaringan lokal Anda. Rak ACE menyediakan konektivitas ke setiap rak Outposts, sehingga AWS akan memiliki alokasi antarmuka VLAN dan konfigurasi antara ONDs dan perangkat jaringan ACE. ONDs
Lapisan jaringan terisolasi untuk jaringan Service Link dan Local Gateway masih diperlukan terlepas dari apakah rak ACE digunakan atau tidak, yang bertujuan untuk memiliki subnet IP VLAN point-to-point (/30 atau /31), dan konfigurasi peering eBGP untuk setiap jaringan terpisah. Arsitektur yang diusulkan harus mengikuti salah satu dari dua arsitektur sebagai berikut:
![\[Perangkat jaringan dua pelanggan\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/aws-outposts-high-availability-design/images/page-22-two-customer-networking-devices.png)
+ Dengan arsitektur ini, pelanggan harus memiliki dua perangkat jaringan (CND) untuk menghubungkan perangkat jaringan ACE, memberikan redundansi.
+ Untuk setiap koneksi fisik, Anda harus mengaktifkan LAG (untuk meningkatkan bandwidth yang tersedia antara Outpost dan pusat data), bahkan jika itu adalah port fisik tunggal, dan itu akan membawa dua segmen jaringan, memiliki 2 point-to-point VLANs (/30 atau/31), dan konfigurasi eBGP antara dan. ACEs CNDs
+ Dalam keadaan stabil, lalu lintas seimbang dengan beban mengikuti keseimbangan pola multipath Equal-cost (ECMP) diaktifkan, dan mengumumkan awalan pelanggan dengan to/from the customer network from the ACE layer, 25% traffic distribution across the ACE to customer. In order to allow this behavior, the eBGP peering’s between ACEs and CNDs must have BGP multipath/load metrik BGP yang sama pada 4 koneksi peering eBGP.
+ Untuk mencapai redundansi optimal dan memungkinkan pemeliharaan OND yang tidak mengganggu, kami menyarankan pelanggan untuk mengikuti rekomendasi ini:
+ Perangkat jaringan pelanggan harus mengiklankan awalan BGP yang sama dengan atribut yang sama terhadap semua di Outpost. ONDs
+ Perangkat jaringan pelanggan harus menerima iklan BGP dari Outpost tanpa mengubah atribut BGP dan mengaktifkan BGP multipath/load-balancing.
![\[Perangkat jaringan empat pelanggan\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/aws-outposts-high-availability-design/images/page-23-four-customer-networking-devices.png)
Dengan arsitektur ini, pelanggan akan memiliki empat perangkat jaringan (CND) untuk menghubungkan perangkat jaringan ACE, memberikan redundansi dan logika jaringan yang sama, termasuk VLANs, eBGP, dan ECMP yang berlaku untuk arsitektur 2 CND.
# Konektivitas jangkar
[Tautan layanan Outpost](https://docs.aws.amazon.com/outposts/latest/userguide/region-connectivity.html) terhubung ke jangkar publik atau pribadi (bukan keduanya) di Availability Zone (AZ) tertentu di Wilayah induk Outpost. Server Outpost memulai koneksi VPN tautan layanan keluar dari alamat IP tautan layanan mereka ke titik jangkar di jangkar AZ. Koneksi ini menggunakan UDP dan TCP port 443. AWS bertanggung jawab atas ketersediaan titik jangkar di Wilayah.
Anda harus memastikan alamat IP tautan layanan Outpost dapat terhubung melalui jaringan Anda ke titik jangkar di jangkar AZ. Alamat IP link layanan tidak perlu berkomunikasi dengan host lain di jaringan lokal Anda.
Titik jangkar publik berada di [rentang IP publik](https://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html) Wilayah (dalam blok CIDR EC2 layanan) dan dapat diakses melalui internet atau [AWS Direct Connect](https://aws.amazon.com/directconnect/)(DX) antarmuka virtual publik (). VIFs Penggunaan titik jangkar publik memungkinkan pemilihan jalur yang lebih fleksibel karena lalu lintas tautan layanan dapat diarahkan ke jalur yang tersedia yang berhasil mencapai titik jangkar di internet publik.
Poin jangkar pribadi memungkinkan Anda menggunakan rentang alamat IP Anda untuk konektivitas jangkar. Poin jangkar pribadi dibuat dalam [subnet pribadi dalam VPC khusus menggunakan alamat IP yang](https://docs.aws.amazon.com/outposts/latest/userguide/region-connectivity.html#private-connectivity) ditetapkan pelanggan. VPC dibuat di Akun AWS yang memiliki sumber daya Outpost dan Anda bertanggung jawab untuk memastikan VPC tersedia dan dikonfigurasi dengan benar. [Gunakan Security Control Policy (SCP) di AWSOrigamiServiceGateway Organizations untuk mencegah pengguna menghapus Virtual Private Cloud (VPC) tersebut. Titik jangkar pribadi harus diakses menggunakan Direct Connect private. VIFs](https://aws.amazon.com/blogs/networking-and-content-delivery/introducing-aws-outposts-private-connectivity/)
Anda harus menyediakan jalur jaringan redundan antara Outpost dan anchor point di Region dengan koneksi yang berakhir pada perangkat terpisah di lebih dari satu lokasi. Perutean dinamis harus dikonfigurasi untuk secara otomatis mengalihkan lalu lintas ke jalur alternatif ketika koneksi atau perangkat jaringan gagal. Anda harus menyediakan kapasitas jaringan yang cukup untuk memastikan bahwa kegagalan satu jalur WAN tidak membanjiri jalur yang tersisa.
Diagram berikut menunjukkan tiga Outposts dengan jalur jaringan redundan ke jangkar mereka AZs menggunakan AWS Direct Connect serta konektivitas internet publik. Pos Terdepan A dan Pos Terdepan B ditambatkan ke Zona Ketersediaan yang berbeda di Wilayah yang sama. Pos Terdepan A terhubung ke titik jangkar pribadi di AZ 1 dari wilayah 1. Outpost B terhubung ke titik jangkar publik di AZ 2 wilayah 1. Outpost C terhubung ke jangkar publik di AZ 1 wilayah 2.
![\[Diagram menunjukkan konektivitas jangkar yang sangat tersedia dengan AWS Direct Connect dan akses internet publik\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/aws-outposts-high-availability-design/images/highly-available-anchor-connectivity.png)
Outpost A memiliki tiga jalur jaringan redundan untuk mencapai titik jangkar pribadinya. Dua jalur tersedia melalui sirkuit Direct Connect redundan di satu lokasi Direct Connect. Jalur ketiga tersedia melalui sirkuit Direct Connect di lokasi Direct Connect kedua. Desain ini menjaga lalu lintas tautan layanan Outpost A di jaringan pribadi dan menyediakan redundansi jalur yang memungkinkan kegagalan salah satu sirkuit Direct Connect atau kegagalan seluruh lokasi Direct Connect.
Outpost B memiliki empat jalur jaringan redundan untuk mencapai titik jangkar publiknya. Tiga jalur tersedia melalui VIFs penyediaan publik di sirkuit Direct Connect dan lokasi yang digunakan oleh Outpost A. Jalur keempat tersedia melalui WAN pelanggan dan internet publik. Lalu lintas tautan layanan Outpost B dapat diarahkan melalui jalur yang tersedia yang dapat berhasil mencapai titik jangkar di internet publik. Menggunakan jalur Direct Connect dapat memberikan latensi yang lebih konsisten dan ketersediaan bandwidth yang lebih tinggi, sedangkan jalur internet publik dapat digunakan untuk Disaster Recovery (DR) atau skenario augmentasi bandwidth.
Outpost C memiliki dua jalur jaringan redundan untuk mencapai titik jangkar publiknya. Outpost C ditempatkan di pusat data yang berbeda dari pusat data Outposts A dan B. Outpost C tidak memiliki sirkuit khusus yang terhubung ke WAN pelanggan. Sebaliknya, pusat data memiliki koneksi internet redundan yang disediakan oleh dua Penyedia Layanan Internet yang berbeda ()ISPs. Lalu lintas tautan layanan Outpost C dapat diarahkan melalui salah satu jaringan ISP untuk mencapai titik jangkar di internet publik. Desain ini memungkinkan fleksibilitas untuk mengarahkan lalu lintas tautan layanan melalui koneksi internet publik yang tersedia. Namun, end-to-end jalur tergantung pada jaringan pihak ketiga publik di mana ketersediaan bandwidth dan latensi jaringan berfluktuasi.
Jalur jaringan antara Outpost dan titik jangkar tautan layanannya harus memenuhi spesifikasi bandwidth berikut:
+ 500 Mbps - 1 Gbps bandwidth yang tersedia per rak Outpost (misalnya, 3 rak: 1,5 - 3 Gbps bandwidth yang tersedia)
## Praktik yang direkomendasikan untuk konektivitas jangkar yang sangat tersedia
+ Menyediakan jalur jaringan yang berlebihan antara setiap Pos Luar dan titik jangkar di Wilayah.
+ Gunakan jalur Direct Connect (DX) untuk mengontrol latensi dan ketersediaan bandwidth.
+ Pastikan bahwa port TCP dan UDP 443 terbuka (keluar) dari blok CIDR Outpost Service Link ke rentang [alamat EC2 IP di Wilayah induk](https://docs.aws.amazon.com/general/latest/gr/aws-ip-ranges.html). Pastikan port terbuka di semua jalur jaringan.
+ Lacak rentang alamat EC2 IP Amazon di firewall Anda jika Anda menggunakan subset rentang CIDR untuk Wilayah tersebut.
+ Pastikan setiap jalur memenuhi ketersediaan bandwidth dan persyaratan latensi.
+ Gunakan perutean dinamis untuk mengotomatiskan pengalihan lalu lintas di sekitar kegagalan jaringan.
+ Uji perutean lalu lintas tautan layanan di setiap jalur jaringan yang direncanakan untuk memastikan jalur berfungsi seperti yang diharapkan.
# Perutean aplikasi/beban kerja
Ada dua jalur keluar dari Outpost untuk beban kerja aplikasi:
+ Jalur tautan layanan: Pertimbangkan bahwa lalu lintas aplikasi akan bersaing dengan Outposts mengontrol lalu lintas pesawat, selain membatasi [MTU hingga](https://docs.aws.amazon.com/outposts/latest/userguide/region-connectivity.html#service-links) 1300 byte.
+ Jalur gateway lokal (LGW): Pertimbangkan bahwa jaringan lokal pelanggan memungkinkan akses ke kedua aplikasi yang ada di tempat dan juga di. Wilayah AWS
Anda mengonfigurasi tabel rute subnet Outpost untuk mengontrol jalur mana yang harus diambil untuk mencapai jaringan tujuan. Rute yang diarahkan ke LGW akan mengarahkan lalu lintas keluar dari Gateway Lokal dan ke jaringan lokal. Rute yang menunjuk ke layanan dan sumber daya di Wilayah, seperti Internet Gateway, NAT Gateway, Virtual Private Gateway, dan TGW, akan menggunakan [tautan layanan](https://docs.aws.amazon.com/outposts/latest/userguide/region-connectivity.html) untuk mencapai target ini. Jika Anda memiliki koneksi peering VPC dengan beberapa VPCs di Pos Luar yang sama, lalu lintas antara VPCs sisa-sisa di Pos Luar dan tidak menggunakan tautan layanan kembali ke Wilayah. *Untuk informasi tentang peering VPC, lihat Connect [menggunakan peering VPCs VPC di Panduan Pengguna](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-peering.html) Amazon VPC.*
![\[Diagram yang menunjukkan visualisasi tautan layanan Outpost dan jalur jaringan LGW\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/aws-outposts-high-availability-design/images/outpost-service-link-and-lgw-network-paths.png)
Anda harus berhati-hati saat merencanakan perutean aplikasi untuk mempertimbangkan operasi normal dan perutean terbatas dan ketersediaan layanan selama kegagalan jaringan. Jalur Tautan Layanan tidak tersedia saat Pos Luar terputus dari Wilayah.
Anda harus menyediakan beragam jalur dan mengonfigurasi perutean dinamis antara Outpost LGW dan aplikasi, sistem, dan pengguna lokal penting Anda. Jalur jaringan redundan memungkinkan jaringan untuk merutekan lalu lintas di sekitar kegagalan dan memastikan bahwa sumber daya lokal akan dapat berkomunikasi dengan beban kerja yang berjalan di Outpost selama kegagalan jaringan sebagian.
Konfigurasi rute VPC pos terdepan bersifat statis. Anda mengonfigurasi tabel perutean subnet melalui alat, Konsol Manajemen AWS CLI, APIs, dan Infrastructure as Code (IAc) lainnya; Namun, Anda tidak akan dapat memodifikasi tabel perutean subnet selama peristiwa pemutusan. Anda harus membangun kembali konektivitas antara Outpost dan Region untuk memperbarui tabel rute. Gunakan rute yang sama untuk operasi normal seperti yang Anda rencanakan untuk digunakan selama peristiwa pemutusan sambungan.
Sumber daya di Outpost dapat menjangkau internet melalui tautan layanan dan Internet Gateway (IGW) di Wilayah atau melalui jalur Local Gateway (LGW). Merutekan lalu lintas internet melalui jalur LGW dan jaringan lokal memungkinkan Anda menggunakan titik masuk/keluar internet lokal yang ada dan dapat memberikan latensi yang lebih rendah, biaya keluar AWS data yang lebih tinggi MTUs, dan berkurang jika dibandingkan dengan menggunakan jalur tautan layanan ke IGW di Wilayah.
Jika aplikasi Anda harus berjalan di tempat dan harus dapat diakses dari internet publik, Anda harus merutekan lalu lintas aplikasi melalui koneksi internet lokal Anda ke LGW untuk menjangkau sumber daya di Pos Luar.
Meskipun Anda dapat mengonfigurasi subnet di Outpost seperti subnet publik di Wilayah, ini mungkin merupakan praktik yang tidak diinginkan untuk sebagian besar kasus penggunaan. Lalu lintas internet masuk akan masuk melalui Wilayah AWS dan diarahkan melalui tautan layanan ke sumber daya yang berjalan di Outpost.
Lalu lintas respons pada gilirannya akan diarahkan melalui tautan layanan dan kembali keluar melalui koneksi internet. Wilayah AWS Pola lalu lintas ini dapat menambah latensi dan akan menimbulkan biaya keluar data karena lalu lintas meninggalkan Wilayah dalam perjalanan ke Pos Terdepan dan ketika lalu lintas kembali kembali melalui Wilayah dan keluar ke internet. Jika aplikasi Anda dapat berjalan di Wilayah, Wilayah adalah tempat terbaik untuk menjalankannya.
Lalu lintas antara sumber daya VPC (dalam VPC yang sama) akan selalu mengikuti rute CIDR VPC lokal dan dirutekan antar subnet oleh router VPC implisit.
Misalnya, lalu lintas antara EC2 instans yang berjalan di Outpost dan Titik Akhir VPC di Wilayah akan selalu diarahkan melalui tautan layanan.
![\[Diagram yang menunjukkan perutean VPC lokal melalui router implisit\]](http://docs.aws.amazon.com/id_id/whitepapers/latest/aws-outposts-high-availability-design/images/local-vpc-routing-through-implicit-routers.png)
## Praktik yang direkomendasikan untuk perutean aplikasi/beban kerja
+ Gunakan jalur Local Gateway (LGW) alih-alih jalur tautan layanan jika memungkinkan.
+ Rutekan lalu lintas internet melalui jalur LGW.
+ Konfigurasikan tabel perutean subnet Outpost dengan serangkaian rute standar - mereka akan digunakan untuk operasi normal dan selama peristiwa pemutusan sambungan.
+ Menyediakan jalur jaringan redundan antara Outpost LGW dan sumber daya aplikasi lokal yang penting. Gunakan perutean dinamis untuk mengotomatiskan pengalihan lalu lintas di sekitar kegagalan jaringan lokal.