Pemulihan bencana - Praktik Terbaik untuk Menerapkan Amazon 2.0 AppStream

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Pemulihan bencana

Amazon AppStream 2.0 telah membangun redundansi di hingga tiga zona ketersediaan. Ini berarti bahwa jika pengguna memiliki sesi aktif di zona ketersediaan yang menjadi terdegradasi, mereka dapat dengan mudah memutuskan dan menyambung kembali yang akan memesan sesi mereka di zona ketersediaan yang sehat dengan asumsi Anda memiliki kapasitas. Meskipun ini memberikan ketersediaan tinggi di Wilayah, itu tidak memberikan solusi pemulihan bencana jika layanan mengalami masalah di tingkat regional.

Untuk menyediakan rencana pemulihan bencana bagi pengguna AppStream 2.0 Anda, Anda harus terlebih dahulu membangun lingkungan AppStream 2.0 di Wilayah sekunder Anda. Dari perspektif desain, lingkungan ini harus memiliki koneksi berlebihan ke lingkungan lokal Anda, jika berlaku, dan seharusnya tidak memiliki ketergantungan pada Wilayah utama. Misalnya, jika armada AppStream 2.0 Anda bergabung dengan domain, Anda harus memiliki pengontrol domain tambahan di Wilayah sekunder dengan Situs dan Layanan yang dikonfigurasi. Dari perspektif AppStream 2.0, lingkungan ini harus terdiri dari pengaturan armada dan tumpukan yang sama dengan yang Anda miliki di Wilayah utama Anda. Armada itu sendiri harus menjalankan gambar dasar Anda yang sama, yang dapat disalin ke Wilayah sekunder Anda melalui konsol atau secara terprogram. Jika aplikasi yang berjalan dalam sesi AppStream 2.0 Anda memiliki ketergantungan backend yang terkait dengan Wilayah utama Anda, itu juga harus memiliki redundansi regional untuk memastikan pengguna masih dapat mengakses backend aplikasi jika Wilayah utama turun. Batas tingkat layanan Anda di Wilayah tujuan Anda harus sesuai dengan Wilayah utama Anda.

Perutean identitas

Ada dua metode berbeda untuk menyediakan akses ke aplikasi dalam skenario DR. Pada tingkat tinggi, kedua metode berbeda dengan bagaimana pengguna diarahkan ke Wilayah failover. Metode pertama dilakukan dengan konfigurasi aplikasi AppStream 2.0 tunggal di iDP Anda dan metode kedua memiliki dua konfigurasi aplikasi terpisah.

Metode 1: Mengubah status relai aplikasi Anda

Saat pengguna masuk ke AppStream 2.0 dari Penyedia Identitas (iDP), setelah otentikasi mereka, mereka diteruskan ke URL tertentu yang sejajar dengan Wilayah dan tumpukan yang dimaksudkan untuk diakses. Untuk informasi selengkapnya seputar URL Status Relay, lihat Panduan Administrasi Amazon AppStream 2.0. Administrator dapat mengonfigurasi tumpukan Lintas wilayah yang dibangun pada gambar AppStream 2.0 yang sama dengan Wilayah utama bagi pengguna untuk failover. Administrator dapat mengontrol failover ini hanya dengan memperbarui URL Relay State untuk menunjuk ke tumpukan failover. Agar metode ini dapat beroperasi dengan benar, kebijakan IAM terkait perlu mencerminkan akses ke kedua tumpukan; primer dan failover. Untuk detail selengkapnya tentang bagaimana kebijakan IAM ini harus dikonfigurasi, lihat contoh kebijakan berikut.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "VisualEditor0", "Effect": "Allow", "Action": "appstream:Stream", "Resource": [ "arn:aws:appstream:PrimaryRegion:190836837966:stack/StackName", "arn:aws:appstream:FailoverRegion:190836837966:stack/StackName" ], "Condition": { "StringEquals": { "appstream:userId": "${saml:sub}" } } } ] }

Metode 2: Mengkonfigurasi dua aplikasi AppStream 2.0 dalam IDP Anda

Metode ini mengharuskan administrator untuk membangun dua aplikasi terpisah untuk AppStream 2.0 dalam iDP. Mereka kemudian dapat menyajikan kedua aplikasi dan membiarkan pengguna memilih ke mana harus pergi, atau mereka mengunci/menyembunyikan aplikasi sampai tiba waktunya untuk failover. Metode ini lebih selaras dengan kasus penggunaan memiliki pengguna global yang sering berpindah-pindah. Pengguna tersebut harus melakukan streaming dari titik akhir terdekat, oleh karena itu memiliki kedua aplikasi yang ditetapkan memberi mereka opsi untuk memilih aplikasi yang dikonfigurasi untuk Wilayah terdekat mereka. Ini juga dapat diotomatisasi, untuk informasi lebih lanjut lihat posting blog ini.

Ketekunan penyimpanan

Saat memanfaatkan fitur persistensi data AppStream 2.0 yang disertakan, seperti Persistensi Aplikasi dan Sinkronisasi Folder Rumah, Anda perlu mereplikasi data tersebut ke wilayah failover Anda. Fitur-fitur ini menyimpan data persisten dalam bucket Amazon S3 di wilayah AppStream 2.0 yang diberikan. Agar data tetap ada lintas wilayah, Anda harus mereplikasi semua perubahan pada bucket sumber ke bucket failover region AppStream 2.0. Ini dapat dilakukan dengan fitur Amazon S3 asli, seperti replikasi lintas wilayah Amazon S3. Setiap pengguna data persisten akan berada di bawah folder nama pengguna yang di-hash mereka. Karena nama pengguna akan di-hash lintas wilayah yang sama, cukup mereplikasi data akan memberikan persistensi data di wilayah sekunder Anda. Untuk informasi lebih lanjut tentang bucket Amazon S3 yang digunakan oleh AppStream 2.0, lihat panduan ini.