Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
Di bawah model tanggung jawab bersama model
Awas
Data pada volume penyimpanan instance hilang jika drive disk yang mendasarinya gagal, atau jika instance berhenti, hibernasi, atau berakhir. Untuk mencegah kehilangan data, sebaiknya Anda mencadangkan data jangka panjang pada volume penyimpanan instans ke penyimpanan persisten, seperti bucket Amazon S3, EBS volume Amazon, atau perangkat penyimpanan jaringan di jaringan lokal.
Daftar Isi
Perbarui detail kontak
Jika pemilik Outpost berubah, hubungi AWS Support Pusat
Pemeliharaan perangkat keras
Jika AWS mendeteksi masalah perangkat keras yang tidak dapat diperbaiki selama proses penyediaan server atau saat menghosting instans Amazon yang EC2 berjalan di rak Outposts Anda, kami akan memberi tahu pemilik Outpost dan pemilik instans bahwa instans yang terpengaruh dijadwalkan untuk pensiun. Untuk informasi selengkapnya, lihat Pensiun instans di Panduan EC2 Pengguna Amazon.
Pemilik Outpost dan pemilik instans dapat bekerja sama untuk menyelesaikan masalah. Pemilik instans dapat menghentikan dan memulai instance yang terpengaruh untuk memigrasikannya ke kapasitas yang tersedia. Pemilik instans dapat menghentikan dan memulai instance yang terpengaruh pada waktu yang nyaman bagi mereka. Jika tidak, AWS hentikan dan mulai instance yang terpengaruh pada tanggal pensiun instans. Jika tidak ada kapasitas tambahan di Outpost, instance tetap dalam keadaan berhenti. Pemilik Pos Luar dapat mencoba membebaskan kapasitas bekas atau meminta kapasitas tambahan untuk Pos Luar sehingga migrasi dapat selesai.
Jika pemeliharaan perangkat keras diperlukan, AWS akan menghubungi pemilik Outpost untuk mengonfirmasi tanggal dan waktu bagi tim AWS instalasi untuk berkunjung. Kunjungan dapat dijadwalkan segera setelah dua hari kerja sejak pemilik Pos Luar berbicara dengan AWS tim.
Ketika tim AWS instalasi tiba di lokasi, mereka akan mengganti host, switch, atau elemen rak yang tidak sehat dan membawa kapasitas baru secara online. Mereka tidak akan melakukan diagnosa atau perbaikan perangkat keras apa pun di lokasi. Jika mereka mengganti host, mereka akan menghapus dan menghancurkan kunci keamanan fisik yang NIST sesuai, secara efektif merobek-robek data apa pun yang mungkin tertinggal di perangkat keras. Ini memastikan bahwa tidak ada data yang meninggalkan situs Anda. Jika mereka mengganti perangkat jaringan Outpost, informasi konfigurasi jaringan mungkin ada di perangkat saat dihapus dari situs. Informasi ini mungkin termasuk alamat IP dan ASNs digunakan untuk membuat antarmuka virtual untuk mengonfigurasi jalur ke jaringan lokal Anda atau kembali ke Wilayah.
Pembaruan firmware
Memperbarui firmware Outpost biasanya tidak memengaruhi instance di Outpost Anda. Dalam kasus yang jarang terjadi bahwa kita perlu me-reboot peralatan Outpost untuk menginstal pembaruan, Anda akan menerima pemberitahuan pensiun instance untuk setiap instance yang berjalan pada kapasitas itu.
Pemeliharaan peralatan jaringan
Pemeliharaan Outpost Networking Devices (OND) dilakukan tanpa mempengaruhi operasi Outpost reguler dan lalu lintas. Jika pemeliharaan diperlukan lalu lintas bergeser menjauh dari. OND Anda mungkin melihat perubahan sementara dalam BGP iklan, seperti prepending AS-path, dan perubahan pola lalu lintas yang sesuai pada uplink Outpost. Dengan pembaruan OND firmware, Anda mungkin melihat BGP mengepak.
Kami menyarankan Anda mengonfigurasi peralatan jaringan pelanggan untuk menerima BGP iklan dari Outposts tanpa mengubah BGP atribut, dan BGP mengaktifkan multipath/load balancing untuk mencapai arus lalu lintas masuk yang optimal. As-path prepending digunakan untuk awalan gateway lokal untuk mengalihkan lalu lintas dari ONDs jika pemeliharaan diperlukan. Jaringan pelanggan harus memilih rute dari Outposts dengan panjang AS-path 1 daripada rute dengan panjang AS-path 4.
Jaringan pelanggan harus mengiklankan BGP awalan yang sama dengan atribut yang sama untuk semua. ONDs Beban jaringan Outpost menyeimbangkan lalu lintas keluar antara semua uplink secara default. Kebijakan perutean digunakan di sisi Outpost untuk mengalihkan lalu lintas dari OND jika pemeliharaan diperlukan. Pergeseran lalu lintas ini membutuhkan BGP awalan yang sama dari sisi pelanggan. ONDs Jika pemeliharaan diperlukan pada jaringan pelanggan, kami sarankan Anda menggunakan AS-path prepending untuk sementara mengalihkan array lalu lintas dari uplink tertentu.
Praktik terbaik untuk acara listrik dan jaringan
Sebagaimana dinyatakan dalam Ketentuan AWS Layanan
Peristiwa kekuasaan
Dengan pemadaman listrik total, ada risiko yang melekat bahwa AWS Outposts sumber daya mungkin tidak kembali ke layanan secara otomatis. Selain menerapkan daya redundan dan solusi daya cadangan, kami menyarankan Anda melakukan hal berikut terlebih dahulu untuk mengurangi dampak dari beberapa skenario terburuk:
-
Pindahkan layanan dan aplikasi Anda dari peralatan Outposts dengan cara yang terkontrol, menggunakan perubahan load-balancing DNS berbasis atau off-rack.
-
Hentikan kontainer, instance, database secara bertahap dan gunakan urutan terbalik saat memulihkannya.
-
Uji rencana untuk pemindahan atau penghentian layanan yang terkontrol.
-
Buat cadangan data dan konfigurasi penting dan simpan di luar Outposts.
-
Pertahankan waktu henti daya seminimal mungkin.
-
Hindari pengalihan berulang dari umpan daya (off-on-off-on) selama pemeliharaan.
-
Berikan waktu ekstra dalam jendela pemeliharaan untuk menangani hal yang tidak terduga.
-
Kelola harapan pengguna dan pelanggan Anda dengan mengkomunikasikan kerangka waktu jendela pemeliharaan yang lebih luas daripada yang biasanya Anda butuhkan.
-
Setelah daya dipulihkan, buat case di AWS Support Center
untuk meminta verifikasi bahwa AWS Outposts dan layanan terkait sedang berjalan.
Acara konektivitas jaringan
Koneksi tautan layanan antara Outpost Anda dan AWS Wilayah atau Outposts home Region biasanya akan secara otomatis pulih dari gangguan jaringan atau masalah yang mungkin terjadi di perangkat jaringan perusahaan hulu Anda atau di jaringan penyedia konektivitas pihak ketiga mana pun setelah pemeliharaan jaringan selesai. Selama koneksi tautan layanan tidak aktif, operasi Outposts Anda terbatas pada aktivitas jaringan lokal.
Untuk informasi selengkapnya, lihat pertanyaan Apa yang terjadi ketika koneksi jaringan fasilitas saya mati? di FAQs halaman AWS Outposts rak
Jika tautan layanan tidak aktif karena masalah daya di tempat atau hilangnya konektivitas jaringan, maka akan AWS Health Dashboard mengirimkan pemberitahuan ke akun yang memiliki Outposts. Baik Anda maupun tidak AWS dapat menekan pemberitahuan gangguan tautan layanan, bahkan jika gangguan diharapkan. Untuk informasi selengkapnya, lihat Memulai dengan Anda AWS Health Dashboard di Panduan AWS Health Pengguna.
Dalam hal pemeliharaan layanan terencana yang akan memengaruhi konektivitas jaringan, ambil langkah-langkah proaktif berikut untuk membatasi dampak skenario bermasalah potensial:
-
Jika rak Outposts Anda terhubung ke AWS Wilayah induk melalui Internet atau Direct Connect publik, maka sebelum pemeliharaan yang direncanakan, tangkap rute jejak. Memiliki jalur jaringan (pre-network-maintenance) yang berfungsi dan jalur jaringan (post-network-maintenance) yang bermasalah untuk mengidentifikasi perbedaan akan membantu dalam pemecahan masalah. Jika Anda meningkatkan masalah pasca-pemeliharaan ke AWS atau masalah AndaISP, Anda dapat menyertakan informasi ini.
Tangkap rute jejak antara:
-
Alamat IP publik di lokasi Outposts dan alamat IP yang dikembalikan oleh.
outposts.Gantiregion.amazonaws.com.rproxy.goskope.comregiondengan nama AWS Wilayah induk. -
Setiap contoh di Wilayah induk dengan konektivitas Internet publik dan alamat IP publik di lokasi Outposts.
-
-
Jika Anda mengendalikan pemeliharaan jaringan, batasi durasi downtime untuk tautan layanan. Sertakan langkah dalam proses pemeliharaan Anda yang memverifikasi bahwa jaringan telah pulih.
-
Jika Anda tidak mengendalikan pemeliharaan jaringan, pantau downtime tautan layanan sehubungan dengan jendela pemeliharaan yang diumumkan dan eskalasi lebih awal kepada pihak yang bertanggung jawab atas pemeliharaan jaringan yang direncanakan jika tautan layanan tidak dicadangkan pada akhir jendela pemeliharaan yang diumumkan.
Sumber daya
Berikut adalah beberapa sumber daya terkait pemantauan yang dapat memberikan jaminan bahwa Outposts beroperasi secara normal setelah peristiwa listrik atau jaringan yang direncanakan atau tidak direncanakan:
-
AWS Blog Pemantauan praktik terbaik untuk AWS Outposts
mencakup observabilitas dan praktik terbaik manajemen acara khusus untuk Outposts. -
Alat debugging AWS blog untuk konektivitas jaringan dari Amazon VPC
menjelaskan alat AWSSupport-S etupIPMonitoring From VPC. Alat ini adalah AWS Systems Manager dokumen (SSMdokumen) yang membuat Instans EC2 Monitor Amazon di subnet yang ditentukan oleh Anda dan memantau alamat IP target. Dokumen menjalankan tes diagnostik ping,MTR, TCP trace-route dan trace-path dan menyimpan hasilnya di Amazon CloudWatch Logs yang dapat divisualisasikan di CloudWatch dasbor (misalnya latensi, kehilangan paket). Untuk pemantauan Outposts, Instans Monitor harus berada di satu subnet dari AWS Wilayah induk dan dikonfigurasi untuk memantau satu atau lebih instance Outpost Anda menggunakan IP pribadinya - ini akan memberikan grafik kehilangan paket dan latensi antara dan Wilayah induk. AWS Outposts AWS -
AWS Blog Menyebarkan CloudWatch dasbor Amazon otomatis untuk AWS Outposts digunakan AWS CDK
menjelaskan langkah-langkah yang terlibat dalam menerapkan dasbor otomatis. -
Jika Anda memiliki pertanyaan atau memerlukan informasi selengkapnya, lihat Membuat kasus AWS dukungan di Panduan Pengguna Support.
