Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Keandalan
Definisi
Keandalan mengacu pada kemampuan layanan atau sistem untuk melakukan fungsi yang diharapkan bila diperlukan. Keandalan suatu sistem dapat diukur dengan tingkat kualitas operasionalnya dalam jangka waktu tertentu. Bandingkan ini dengan ketahanan, yang mengacu pada kemampuan sistem untuk pulih dari gangguan infrastruktur atau layanan, secara dinamis dan andal.
Untuk detail lebih lanjut tentang bagaimana ketersediaan dan ketahanan digunakan untuk mengukur keandalan, lihat Pilar Keandalan Kerangka Well-Architected AWS .
Pertanyaan kunci
Ketersediaan
Ketersediaan adalah persentase waktu ketika beban kerja tersedia untuk digunakan. Target umum termasuk 99% (3.65 hari downtime diperbolehkan per tahun), 99,9% (8,77 jam), dan 99,99% (52,6 menit), dengan singkatan dari jumlah sembilan dalam persentase (“dua sembilan” untuk 99%, “tiga sembilan” untuk 99,9%, dan seterusnya). Ketersediaan solusi jaringan antara AWS dan pusat data lokal mungkin berbeda dari solusi keseluruhan atau ketersediaan aplikasi.
Pertanyaan kunci untuk ketersediaan solusi jaringan meliputi:
-
Dapatkah AWS sumber daya saya terus beroperasi jika sumber daya tidak dapat berkomunikasi dengan sumber daya lokal saya? Begitu juga sebaliknya?
-
Haruskah saya mempertimbangkan waktu henti terjadwal untuk pemeliharaan terencana sebagai disertakan atau dikecualikan dari metrik ketersediaan?
-
Bagaimana saya mengukur ketersediaan lapisan jaringan, terpisah dari kesehatan aplikasi secara keseluruhan?
Bagian Ketersediaan dari Pilar Keandalan Kerangka Well-Architected memiliki saran dan rumus untuk ketersediaan perhitungan.
Ketahanan
Ketahanan adalah kemampuan beban kerja untuk pulih dari gangguan infrastruktur atau layanan, secara dinamis memperoleh sumber daya komputasi untuk memenuhi permintaan, dan memitigasi gangguan, seperti kesalahan konfigurasi atau masalah jaringan sementara. Jika komponen jaringan yang berlebihan (tautan, perangkat jaringan, dan sebagainya) tidak memiliki ketersediaan yang cukup untuk menyediakan fungsi yang diharapkan sendiri, maka ia memiliki ketahanan yang rendah terhadap kegagalan. Konsekuensinya adalah pengalaman pengguna yang buruk dan terdegradasi.
Pertanyaan kunci untuk ketahanan solusi jaringan meliputi:
-
Berapa banyak kegagalan simultan dan diskrit yang harus saya izinkan?
-
Bagaimana saya bisa mengurangi satu titik kegagalan dengan solusi konektivitas dan jaringan internal saya?
-
Apa kerentanan saya terhadap peristiwa penolakan layanan (DDoS) terdistribusi?
Solusi teknis
Pertama, penting untuk dicatat bahwa tidak setiap solusi konektivitas jaringan hybrid memerlukan tingkat keandalan yang tinggi, dan bahwa peningkatan tingkat keandalan memiliki peningkatan biaya yang sesuai. Dalam beberapa skenario, situs utama mungkin memerlukan koneksi yang andal (berlebihan dan tangguh) karena downtime memiliki dampak yang lebih tinggi pada bisnis, sementara situs regional, mungkin tidak memerlukan tingkat keandalan yang sama karena dampak yang lebih rendah pada bisnis jika terjadi peristiwa kegagalan. Disarankan untuk merujuk pada Rekomendasi AWS Direct Connect Ketahanan
Untuk mencapai solusi konektivitas jaringan hybrid yang andal dalam konteks ketahanan, desain perlu mempertimbangkan aspek-aspek berikut:
-
Redundansi: Bertujuan untuk menghilangkan satu titik kegagalan dalam jalur konektivitas jaringan hybrid, termasuk namun tidak terbatas pada koneksi jaringan, perangkat jaringan tepi, redundansi di seluruh Availability Zones, dan lokasi DX Wilayah AWS, dan sumber daya perangkat, jalur serat, dan sistem operasi. Untuk tujuan dan ruang lingkup whitepaper ini, redundansi berfokus pada koneksi jaringan, perangkat tepi (misalnya, perangkat gateway pelanggan), lokasi AWS DX, dan Wilayah AWS (untuk arsitektur Multi-wilayah).
-
Komponen failover yang andal: Dalam beberapa skenario, sistem mungkin berfungsi, tetapi tidak menjalankan fungsinya pada tingkat yang diperlukan. Situasi seperti itu biasa terjadi selama peristiwa kegagalan tunggal di mana ditemukan bahwa komponen redundan yang direncanakan beroperasi secara non-redundan - beban jaringan mereka tidak memiliki tempat lain untuk dituju karena penggunaan, yang mengakibatkan kapasitas yang tidak mencukupi untuk seluruh solusi.
-
Failover time: Failover time adalah waktu yang dibutuhkan komponen sekunder untuk sepenuhnya mengambil alih peran komponen utama. Failover time memiliki beberapa faktor — berapa lama waktu yang dibutuhkan untuk mendeteksi kegagalan, berapa lama untuk mengaktifkan konektivitas sekunder, dan berapa lama untuk memberi tahu sisa jaringan tentang perubahan. Deteksi kegagalan dapat ditingkatkan menggunakan Dead Peer Detection (DPD) untuk VPN tautan, dan Deteksi Penerusan Dua Arah () untuk tautan. BFD AWS Direct Connect Waktu untuk mengaktifkan konektivitas sekunder bisa sangat rendah (jika koneksi ini selalu aktif), mungkin jendela waktu yang singkat (jika VPN koneksi pra-konfigurasi perlu diaktifkan), atau lebih lama (jika sumber daya fisik perlu dipindahkan atau sumber daya baru dikonfigurasi). Memberitahu sisa jaringan biasanya terjadi melalui protokol routing di dalam jaringan pelanggan, yang masing-masing memiliki waktu konvergensi yang berbeda dan pilihan untuk konfigurasi — konfigurasi ini berada di luar lingkup whitepaper ini.
-
Rekayasa Lalu Lintas: Rekayasa lalu lintas dalam konteks desain konektivitas jaringan hibrida yang tangguh bertujuan untuk mengatasi bagaimana lalu lintas harus mengalir melalui beberapa koneksi yang tersedia dalam skenario normal dan kegagalan. Disarankan untuk mengikuti konsep desain untuk kegagalan, di mana Anda perlu melihat bagaimana solusi akan beroperasi dalam skenario kegagalan yang berbeda dan apakah itu akan dapat diterima oleh bisnis atau tidak. Bagian ini membahas beberapa kasus penggunaan teknik lalu lintas umum yang bertujuan untuk meningkatkan tingkat ketahanan keseluruhan dari solusi konektivitas jaringan hibrida. AWS Direct Connect Bagian tentang routing dan BGP berbicara tentang beberapa opsi rekayasa lalu lintas untuk mempengaruhi arus lalu lintas (komunitas, preferensi BGP lokal, AS Path length). Untuk merancang solusi rekayasa lalu lintas yang efektif, Anda harus memiliki pemahaman yang baik tentang bagaimana masing-masing komponen AWS jaringan menangani perutean IP dalam hal evaluasi dan pemilihan rute, serta mekanisme yang mungkin untuk mempengaruhi pemilihan rute. Rinciannya berada di luar cakupan dokumen ini. Untuk informasi selengkapnya, lihat Urutan Evaluasi Rute Transit Gateway, Prioritas Site-to-Site VPN Rute, dan Perutean dan BGP dokumentasi Direct Connect sesuai kebutuhan.
catatan
Dalam tabel VPC rute, Anda dapat mereferensikan daftar awalan yang memiliki aturan pemilihan rute tambahan. Untuk informasi selengkapnya tentang kasus penggunaan ini, lihat prioritas rute untuk daftar awalan. AWS Transit Gateway tabel rute juga mendukung daftar awalan, tetapi setelah diterapkan mereka diperluas ke entri rute tertentu.
Site-to-SiteVPNKoneksi ganda dengan contoh rute yang lebih spesifik
Skenario ini didasarkan pada situs lokal kecil yang terhubung ke satu Wilayah AWS melalui VPN koneksi redundan melalui internet ke. AWS Transit Gateway Desain teknik lalu lintas yang digambarkan pada Gambar 10 menunjukkan bahwa dengan rekayasa lalu lintas Anda dapat memengaruhi pemilihan jalur yang meningkatkan keandalan solusi konektivitas hibrida dengan:
-
Konektivitas hybrid tangguh: VPN Koneksi redundan masing-masing memberikan kapasitas kinerja yang sama, mendukung failover otomatis dengan menggunakan protokol perutean dinamis (BGP), dan mempercepat deteksi kegagalan koneksi dengan menggunakan deteksi rekan mati. VPN
-
Efisiensi kinerja: Mengkonfigurasi ECMP di kedua VPN koneksi untuk AWS Transit Gateway membantu memaksimalkan bandwidth VPN koneksi secara keseluruhan. Atau, dengan mengiklankan rute yang berbeda, lebih spesifik, bersama dengan rute ringkasan situs, beban dapat dikelola secara independen di dua koneksi VPN
Gambar 10 — Site-to-Site VPN Koneksi ganda dengan contoh rute yang lebih spesifik
Situs lokal ganda dengan beberapa contoh koneksi DX
Skenario yang diilustrasikan pada Gambar 11 menunjukkan dua situs pusat data lokal yang terletak di Wilayah geografis yang berbeda, dan terhubung AWS menggunakan model konektivitas Ketahanan Maksimum (dijelaskan dalam Rekomendasi AWS Direct Connect Ketahanan
Dengan mengaitkan atribut BGP Komunitas dengan rute yang diiklankan AWS DXGW, Anda dapat memengaruhi pemilihan jalur keluar dari samping. AWS DXGW Atribut komunitas ini mengontrol AWS atribut Preferensi BGP Lokal yang ditetapkan ke rute yang diiklankan. Untuk informasi selengkapnya, lihat kebijakan dan AWS BGP komunitas DX Routing.
Untuk memaksimalkan keandalan konektivitas pada Wilayah AWS tingkat tersebut, setiap pasangan koneksi AWS DX mengkonfigurasi ECMP sehingga keduanya dapat digunakan pada saat yang sama untuk transfer data antara setiap situs lokal dan. AWS
Gambar 11 — Situs lokal ganda dengan beberapa contoh koneksi DX
Dengan desain ini, arus lalu lintas yang ditujukan ke jaringan lokal (dengan panjang awalan dan BGP komunitas yang diiklankan yang sama) akan didistribusikan di seluruh koneksi DX ganda per situs yang digunakan. ECMP Namun, jika tidak ECMP diperlukan di seluruh koneksi DX, konsep yang sama dibahas sebelumnya dan dijelaskan dalam kebijakan Routing dan dokumentasi BGP komunitas dapat digunakan untuk lebih merekayasa pemilihan jalur pada tingkat koneksi DX.
Catatan: Jika ada perangkat keamanan di jalur dalam pusat data lokal, perangkat ini perlu dikonfigurasi untuk memungkinkan arus lalu lintas meninggalkan satu tautan DX dan berasal dari tautan DX lain (kedua tautan digunakanECMP) dalam situs pusat data yang sama.
VPNkoneksi sebagai cadangan ke contoh koneksi AWS DX
VPNdapat dipilih untuk menyediakan koneksi jaringan cadangan ke AWS Direct Connect koneksi. Biasanya, model konektivitas jenis ini didorong oleh biaya, karena memberikan tingkat keandalan yang lebih rendah untuk solusi konektivitas hybrid secara keseluruhan karena kinerja indeterministik melalui internet, dan tidak ada SLA yang dapat diperoleh untuk koneksi melalui internet publik. Ini adalah model konektivitas yang valid dan hemat biaya, dan harus digunakan ketika biaya adalah pertimbangan prioritas utama dan ada anggaran terbatas, atau mungkin sebagai solusi sementara sampai DX sekunder dapat disediakan. Gambar 12 menggambarkan desain model konektivitas ini. Salah satu pertimbangan utama dengan desain ini, di mana koneksi VPN dan DX berakhir di AWS Transit Gateway, adalah bahwa VPN koneksi dapat mengiklankan jumlah rute yang lebih tinggi dibandingkan dengan yang dapat diiklankan melalui koneksi DX yang terhubung ke. AWS Transit Gateway Hal ini dapat menyebabkan situasi routing suboptimal. Opsi untuk mengatasi masalah ini adalah mengonfigurasi pemfilteran rute di perangkat gateway pelanggan (CGW) untuk rute yang diterima dari VPN koneksi, yang memungkinkan hanya rute ringkasan yang akan diterima.
Catatan: Untuk membuat rute ringkasan pada AWS Transit Gateway, Anda perlu menentukan rute statis ke lampiran arbitrer dalam tabel AWS Transit Gateway rute sehingga ringkasan dikirim sepanjang rute yang lebih spesifik.
Dari sudut pandang tabel AWS Transit Gateway perutean, rute untuk awalan lokal diterima baik dari koneksi AWS DX (viaDXGW) maupun dariVPN, dengan panjang awalan yang sama. Mengikuti logika prioritas r oute AWS Transit Gateway, rute yang diterima melalui Direct Connect memiliki preferensi yang lebih tinggi daripada yang diterima Site-to-SiteVPN, dan dengan demikian jalur di atas AWS Direct Connect akan lebih disukai untuk menjangkau jaringan lokal.
Gambar 12 — VPN koneksi sebagai cadangan ke contoh koneksi AWS DX
Pohon keputusan berikut memandu Anda membuat keputusan yang diinginkan untuk mencapai konektivitas jaringan hybrid yang tangguh (yang akan menghasilkan konektivitas jaringan hybrid yang andal). Untuk informasi lebih lanjut, lihat AWS Direct Connect Resiliency Toolkit.
Gambar 13 — Pohon keputusan keandalan
