Microsoft Cloud tidak takut dengan keadaan darurat di ruang komputer: gunakan Pemulihan Azure Site untuk membina rancangan latihan pemulihan bencana yang sangat tersedia
Dalam lingkaran IT, ada konsensus industri yang membuat orang berfikir dengan teliti: "Hanya ada dua jenis pelayan di dunia, satu sudah mati, dan yang lain sedang mati."
Sama ada hujan lebat secara tiba-tiba di bilik komputer tempatan, pemadaman elektrik fizikal yang dahsyat, atau cuaca ekstrem yang jarang berlaku di kawasan tertentu di awan, setelah sistem perniagaan teras ditutup selama beberapa jam, kerugian ekonomi langsung dan krisis kepercayaan jenama yang dibawa kepada perusahaan sering menjadi bencana. bencana. Pada masa lalu, untuk membina persekitaran "tempat yang berbeza" atau "pemulihan bencana panas" di seluruh ruang komputer, bukan sahaja perlu menghabiskan berjuta-juta untuk membeli perkakasan berganda dan menyewa talian khusus, tetapi juga dilengkapi dengan pasukan pakar yang besar untuk penyelenggaraan harian.
Tetapi pada era awan asli, Microsoft Cloud menyediakan artifak pemulihan bencana yang disebut "pengurangan dimensi" --
Azure Site Recovery (disebut sebagai ASR)
。 Ia dapat membantu anda meletakkan mesin fizikal tempatan, mesin maya VMware/Hyper-V, dan juga pelayan di awan awam yang lain,
Salin ke awan Azure dalam beberapa saat dengan kos yang sangat rendah
。 Tutorial mendalam hari ini tidak membicarakan maya. Tangan akan membawa anda untuk membina struktur pemulihan bencana AVS/tempatan hingga Azure standard, dan mengajar anda cara melakukannya.
Latihan pemulihan bencana peluru hidup dengan gangguan perniagaan sifar
。
1. Konsep teras: Apakah ASR? Bagaimana mengira RPO dan RTO?
Sebelum konfigurasi langsung, mana-mana perancang rancangan pemulihan bencana mesti terlebih dahulu memegang dua petunjuk tegar. Ini juga merupakan dua masalah yang paling dibimbangkan oleh bos:
RPO (Recovery Point Target, Recovery Point Objective): Ringkasnya, ini adalah berapa banyak masa data yang dibenarkan untuk hilang. Sekiranya ASR anda menyegerakkan data setiap 5 minit, anda mungkin kehilangan 5 minit data pesanan terkini dalam kes terburuk.
RTO (Recovery Time Objective): Ringkasnya, setelah ruang komputer teras digantung, berapa lama masa yang diperlukan untuk menghidupkan mesin sandaran di Azure. Adakah satu minit, sepuluh minit atau setengah hari?
Kekuatan Pemulihan Site Azure adalah bahawa ia menggunakan
Teknologi replikasi berterusan ringan
。 Pada waktu biasa, ia hanya menyulitkan dan memindahkan blok data cakera yang diubah secara bertahap oleh nod utama ke akaun simpanan Azure (pada masa ini, awan tidak membuka mesin maya, tetapi hanya menerima data cakera, jadi
Biasanya tidak memerlukan banyak wang
)。 Setelah malapetaka berlaku, ia akan memasang cakera ini ke mesin maya baru di awan dengan serta-merta, mengambil alih perniagaan dari tanah, dan menyedari
RPO berada di tahap minit, RTO berada dalam sepuluh minit
Prestasi utama peringkat perusahaan.
2. Reka bentuk seni bina teras: "troika" untuk pemulihan bencana
Pelan latihan pemulihan bencana ASR yang lengkap perlu terdiri daripada tiga bahagian teras berikut:
Sumber Alam Sekitar: Anda kini menjalankan perniagaan teras anda
Tempat (boleh menjadi persekitaran VMware tempatan, mesin fizikal, atau kawasan Azure yang lain).
Pemulihan Perkhidmatan Pemulihan: Pangkalan awan Azure. Ia bertanggung jawab untuk menguruskan semua strategi penyalinan, menyimpan data cakera yang dienkripsi, dan mengeluarkan "perintah boot" ketika bencana semakin hampir.
Rangkaian latihan bebas (Test VNet): Banyak orang paling takut dengan "drama palsu dan tindakan sebenar" ketika melakukan latihan pemulihan bencana. Akibatnya, IP persekitaran pengeluaran bertentangan. Kita perlu merancang rangkaian ujian di Azure yang benar-benar terpencil dari dunia tetapi mempunyai segmen rangkaian intranet dan persekitaran pengeluaran yang sama, untuk latihan.
3. Tahap pertama: memulakan kem pangkalan pemulihan bencana di Azure
Pertama, log masuk ke portal Azure (Portal Azure) dan masukkan di bar carian di atas
"Simpan Perkhidmatan Pemulihan"
(Pemulihan Perkhidmatan Vaults), klik Buat.
1. Buat peti besi
Kumpulan sumber: Sebaiknya buat kumpulan sumber pemulihan bencana khusus, seperti DR-Framework-RG.
Nama: Beri nama yang kuat, seperti Primary-to-Azure-Vault.
Kawasan: Sangat kritikal! Anda mesti memilih kawasan Azure dengan lokasi geografi yang berbeza dari bilik sumber anda. Sebagai contoh, perniagaan anda berada di Hong Kong, dan kem pangkalan pemulihan bencana boleh dipilih di Singapura.
2. Konfigurasi penyediaan infrastruktur (ambil contoh menyalin mesin maya Azure atau persekitaran tempatan)
Masukkan peti besi yang dibina dan cari di menu kiri
"Site Recovery"
-> Klik
"Sediakan infrastruktur (Prepare infrastructure)"
。
Di manakah mesin anda terletak? Pilih sumber anda (seperti Azure atau VMware).
Di manakah anda akan menyalin? Pilih "Untuk Azure".
Gunakan perisian konfigurasi (untuk persekitaran tempatan): Sekiranya ia adalah migrasi bilik komputer tempatan, ASR akan meminta anda memuat turun peranti salinan ASR (templat OVA) dan menyebarkannya secara tempatan. Ia seperti "ketua pasukan bergerak", yang bertanggungjawab untuk menyulitkan, memampatkan dan menyensitkannya data cakera tempatan dan menyerahkannya ke Azure dengan selamat.
4. Tahap kedua: mulakan "salinan gila" objek yang dilindungi
Setelah infrastruktur dibuka, kita akan memilih mesin maya teras mana yang perlu memakai "perisai badan" ini.
Klik "Salin" di repositori.
Pilih mesin maya sumber: Tandakan pelayan web teras atau pelayan pangkalan data anda (seperti Prod-DB-01).
Konfigurasi sasaran: Kumpulan sumber sasaran: Di manakah mesin awan dibina sekiranya berlaku bencana? Pilih kumpulan sumber yang telah anda sediakan terlebih dahulu. Rangkaian Sasaran (VNet): Pilih pengeluaran awan
Rangkaian (digunakan untuk mengambil alih apabila bencana sebenar). Rangkaian Ujian (Test VNet): (Fokus!) Pilih rangkaian ujian terpencil yang kami nyatakan sebelumnya.
Dasar replikasi: * Tetapkan masa pengekalan titik pemulihan konsistensi kemalangan dan titik pemulihan konsistensi aplikasi (biasanya tetap lalai selama 24 jam). Konsistensi Aplikasi: ASR akan menggunakan teknologi VSS Windows atau skrip gantung Linux untuk memastikan bahawa data dalam memori selamat sebelum disalin, yang sangat penting untuk pangkalan data seperti SQL Server/Oracle.
Klik "Dayakan Salin". Seterusnya, sistem akan melakukan "penyegerakan inisialisasi penuh" pertama (memakan masa bergantung pada lebar jalur tempatan dan ukuran cakera anda). Apabila anda melihat status dalam senarai menjadi
"Dilindungi (Protected)"
, Dan dengan hubungan kesihatan hijau, kem pangkalan pemulihan bencana selesai secara rasmi.
5. Tahap ketiga: latihan pertempuran sebenar-"latihan ketenteraan" dengan gangguan sifar
Satu set rancangan pemulihan bencana tanpa latihan sama dengan membeli insurans dan tidak mengetahui nombor telefon untuk tuntutan. Penemuan ASR yang paling hebat adalah untuk menyokong
"Ujian Failover (Ujian Failover)"
。 Ia dapat mensimulasikan pengambilalihan bilik komputer yang lengkap di awan tanpa menjejaskan operasi normal persekitaran pengeluaran tempatan dan tidak mengganggu akses pelanggan dalam talian.
Aliran operasi gerudi:
Masukkan senarai mesin maya AVS / ASR dan pilih mesin maya pangkalan data yang anda lindungi.
Klik "Uji Failover" di bahagian atas.
Pilih titik pemulihan: pilih titik "Pemprosesan Terkini" atau "Konsistensi Aplikasi Terkini".
Rangkaian ujian: VNet ujian terpencil mesti dipilih.
Klik OK. Pada ketika ini, ASR akan menunjukkan kekuatannya: ia secara senyap-senyap menyalin salinan cermin cakera di akaun simpanan anda di awan, dan kemudian dalam beberapa minit, ia membuat mesin maya yang sama dari udara tipis.
Hasil pengesahan: Log masuk ke mesin maya ujian ini yang baru saja "dibangkitkan" di awan, periksa sama ada perkhidmatan pangkalan data bermula seperti biasa, dan periksa sama ada data masih utuh.
Pembersihan satu klik: Selepas latihan, klik "Kosongkan failover ujian". Tuliskan log latihan anda (seperti "Latihan berjaya, RTO 8 minit"),Azure akan memusnahkan semua mesin maya sementara dan cakera yang dihasilkan oleh latihan sebentar tadi, dan tidak akan membiarkan anda menghabiskan lebih banyak wang.
Enam, panduan pelepasan utama dan penalaan pengeluaran
Semasa mendorong ASR ke persekitaran pengeluaran, arkitek kanan akan memperhatikan perincian berikut:
Pemecahan cakera dinamik: ASR mempunyai had atas jumlah penulisan sesaat (throughput) data untuk satu cakera. Sekiranya pangkalan data anda adalah raksasa throughput gergasi serentak yang sangat tinggi, disarankan untuk meletakkan pangkalan data
Cakera log sementara (seperti temppdb SQL Server) dikecualikan dari senarai salinan dan hanya cakera data teras yang disalin. Ini bukan sahaja dapat mencegah had throughput ASR terlampaui, tetapi juga menjimatkan sejumlah besar caj lalu lintas rangkaian.
Susunan Pelan Pemulihan: Perniagaan sebenar sering merangkumi banyak mesin (front-end, back-end, pangkalan data). Anda tidak boleh boot secara membuta tuli ketika waktu henti sangat teruk. Dengan menggunakan fungsi "Rancangan Pemulihan" ASR, anda dapat menulis skrip: Langkah 1 adalah membuka pangkalan data yang mendasari terlebih dahulu, langkah 2 adalah menunggu 3 minit untuk lulus pemeriksaan kesihatan pangkalan data, dan langkah 3 adalah membuka mesin web front-end. Dengan cara ini, satu set sistem satu kunci automatik sepenuhnya dapat dihidupkan semula.
Ringkasan
Sebelum pengkomputeran awan, pemulihan bencana adalah "kemewahan" yang hanya mampu dimiliki oleh syarikat gergasi kewangan terkemuka dan syarikat multinasional. Kemunculan Pemulihan Site Azure telah membawa teknologi yang tidak dapat dicapai ini ke tahap awam.
Biasanya, anda hanya perlu membayar simpanan cakera yang sangat murah dan yuran pelesenan asas; dan dalam menghadapi bencana mendadak seperti kebakaran sebenar di bilik komputer, pemadaman elektrik atau pemerasan penggodam, anda boleh mengatur rancangan pemulihan terlebih dahulu dalam masa sepuluh minit, Biarkan aset IT seluruh syarikat dilahirkan semula dengan selamat di awan. Ini adalah "rasa aman" yang paling sukar yang diberikan oleh seni bina awan moden kepada setiap syarikat.
