Anda dapat menggunakan Google Cloud untuk menghosting solusi pemulihan dari bencana untuk sistem SAP yang berjalan di Google Cloud, secara lokal, atau di penyedia cloud lainnya.
Definisi pemulihan dari bencana
Pemulihan dari bencana (DR) dan ketersediaan tinggi (HA) adalah dua elemen yang berbeda dalam konsep keberlangsungan bisnis yang lebih besar. Panduan ini berfokus pada pemulihan dari bencana.
Solusi DR dirancang untuk memulihkan pemrosesan aplikasi setelah terjadi bencana alam atau bencana buatan atau kegagalan infrastruktur menyebabkan pemadaman berskala besar. Pemadaman layanan tersebut tidak hanya menonaktifkan sistem pemrosesan aplikasi utama, tetapi juga semua sistem standby yang melindungi dari kegagalan sistem berskala kecil atau infrastruktur lokal.
Karakteristik lain dari solusi DR yang membedakannya dari solusi ketersediaan tinggi meliputi:
- Sistem pemulihan dalam solusi DR biasanya bukan sistem hot-standby.
- Prosedur pemulihan dari bencana biasanya memerlukan intervensi manual untuk memulihkan atau mengembalikan pemrosesan aplikasi dari cadangan atau replikasi data, sistem, dan infrastruktur.
- Solusi ini mencakup situs pemulihan yang berada di lokasi geografis yang berbeda dengan sistem utama.
- Batas waktu pemulihan (RTO) untuk solusi pemulihan dari bencana biasanya diukur dalam jam, bahkan hari.
Contoh arsitektur berikut menunjukkan sistem SAP yang menyertakan solusi HA dan solusi DR. Situs DR, tempat sistem akan dipulihkan setelah terjadi bencana, berada di sebelah kanan di Region 2. Sistem utama berada di sebelah kiri pada Region 1 dan dikonfigurasi untuk ketersediaan tinggi dengan cluster failover yang mencakup dua zona. Fungsi pencadangan solusi DR direpresentasikan oleh garis putus-putus yang mencakup kedua region. Untuk penyimpanan, sistem menggunakan bucket Cloud Storage multiregional, yang ditunjukkan di bagian bawah diagram.
Contoh tersebut juga menunjukkan sebuah database. Meskipun pemulihan aplikasi bergantung pada pemulihan data, prosedur DR untuk sistem database tidak dibahas dalam panduan ini. Lihat dokumentasi database dan catatan SAP yang berlaku. Panduan ini secara khusus berfokus pada sistem SAP NetWeaver (SAP ASCS/ERS) dan server aplikasi (SAP AAS).
Untuk mengetahui informasi tentang cara menerapkan sistem SAP ketersediaan tinggi di Google Cloud, lihat Panduan perencanaan ketersediaan tinggi untuk SAP NetWeaver di Google Cloud.
Untuk informasi tentang ketersediaan tinggi dan pemulihan dari bencana untuk SAP HANA di Google Cloud, lihat Panduan perencanaan ketersediaan tinggi SAP HANA dan Panduan perencanaan pemulihan dari bencana SAP HANA.
Untuk mendapatkan informasi umum tentang DR di Google Cloud, lihat Panduan perencanaan pemulihan dari bencana.
Pendekatan desain DR untuk sistem SAP yang tidak berjalan di Google Cloud
Jika sistem SAP utama Anda tidak berjalan di Google Cloud, Anda dapat melakukan pendekatan lift-and-shift ke solusi DR, dengan arsitektur dan software sistem DR di Google Cloud sama dengan sistem utama. Atau, Anda dapat memilih pendekatan berbasis cloud, yang sebagai bagian dari desain solusi DR, Anda dapat mengoptimalkan sistem yang dipulihkan untuk cloud, yang didukung oleh Google Cloud atau produk atau layanan partner Google Cloud.
Jika menggunakan pendekatan lift-and-shift, Anda harus mengonfirmasi bahwa arsitektur sistem utama Anda sepenuhnya didukung di Google Cloud. Untuk kedua pendekatan tersebut, Anda harus memastikan bahwa semua software yang Anda gunakan memiliki lisensi yang benar untuk digunakan di Google Cloud.
Untuk mengetahui informasi selengkapnya tentang pemberian lisensi, lihat Persyaratan Layanan Google Cloud Platform.
Mendesain elemen solusi DR untuk SAP NetWeaver di Google Cloud
Elemen desain solusi DR untuk SAP NetWeaver di Google Cloud dapat mencakup:
- Lokasi situs DR
- Networking
- Keamanan
- Pertimbangan mesin virtual (VM)
- Opsi backup
- Penyimpanan
Untuk menerapkan setiap elemen desain ini, Anda memiliki sejumlah opsi untuk memenuhi tujuan pemulihan dan biaya.
Lokasi situs DR
Saat memilih region Google Cloud untuk situs DR, Anda perlu mempertimbangkan:
- Area potensi dampak bencana apa pun yang mungkin terjadi di situs utama Anda
- Lokasi pengguna sistem SAP NetWeaver Anda
- Apakah resource dan fitur Google Cloud yang digunakan sistem SAP Anda tersedia di region dan zona yang Anda pilih
Pilih region Google Cloud untuk situs DR yang cukup jauh dari situs utama Anda sehingga situs DR tidak akan terpengaruh oleh bencana yang mungkin terjadi di situs utama. Jarak 100 mil atau lebih biasanya dianggap cukup, tetapi peraturan atau pedoman organisasi mungkin memerlukan jarak minimum yang berbeda.
Jika sistem SAP utama Anda berjalan di Google Cloud, tempatkan situs DR Anda di region Google Cloud mana pun yang dekat dengan pengguna Anda, selain region tempat sistem utama Anda berjalan. Region Google Cloud berada cukup jauh dari satu sama lain sehingga tidak ada dua region Google Cloud yang kemungkinan akan terpengaruh oleh bencana yang sama.
Jika sistem SAP utama Anda berjalan di luar Google Cloud, tempatkan situs DR Anda di region yang sedekat mungkin dengan pengguna tanpa berada di zona dampak potensial dari bencana yang mungkin terjadi di situs utama.
Di region DR, tempatkan sistem DR Anda di zona yang mendukung jenis instance VM dan infrastruktur lain yang dibutuhkan sistem SAP dan database Anda.
Setelah memilih region untuk situs DR, Anda mungkin perlu meningkatkan kuota resource agar region tersebut menyediakan resource yang cukup untuk sistem DR sebelum peristiwa.
Untuk mengetahui lokasi semua region Google Cloud, lihat Region dan zona.
Untuk melihat fitur yang tersedia di setiap region, lihat Region & zona yang tersedia.
Untuk meninjau resource Google Cloud mana yang bersifat global, regional, dan zona, lihat Resource Global, Regional, dan Zonal.
Networking
Di Google Cloud, Virtual Private Cloud (VPC) menyediakan fungsionalitas jaringan yang dapat diperluas ke seluruh dunia.
Anda perlu membuat jaringan VPC untuk situs DR Anda jika belum ada. Anda juga harus membuat subnetwork dan rentang IP untuk situs DR.
Jika sistem utama Anda berada di Google Cloud, konfigurasi jaringan akan lebih mudah dilakukan jika situs utama dan DR berada dalam jaringan VPC yang sama. Namun, jika perlu, Anda dapat menempatkan situs utama dan DR di berbagai jaringan VPC atau bahkan project yang berbeda.
Saat mendesain solusi DR, Anda perlu mempertimbangkan jalur komunikasi berikut:
- Koneksi antara situs utama dan situs pemulihan di Google Cloud
- Komunikasi internal antara aplikasi, database, dan server yang membentuk sistem SAP Anda
- Hubungan antara pengguna dan sistem SAP
Untuk koneksi dari situs eksternal ke Google Cloud, Google Cloud menyediakan berbagai produk jaringan untuk mendukung setiap titik koneksi ini.
Menghubungkan situs utama ke situs DR
Koneksi antara situs utama dan situs DR diperlukan untuk menyimpan cadangan atau menyediakan jalur replikasi antara dua sistem sehingga resource pemulihan segera tersedia jika terjadi bencana dan untuk pengujian prosedur bencana Anda.
Jika sistem utama Anda berjalan di Google Cloud, menyediakan cadangan di situs DR hampir otomatis. Snapshot Compute Engine dapat ditetapkan sebagai multiregional. Cadangan lainnya dapat disimpan langsung dari sistem utama ke dalam bucket Cloud Storage multiregional untuk ketersediaan instan di situs DR.
Jika sistem utama Anda tidak berjalan di Google Cloud, Anda dapat menghubungkan situs utama Anda ke situs DR di Google Cloud menggunakan Cloud Interconnect atau Cloud VPN.
Untuk contoh topologi Cloud Interconnect yang sangat tersedia, yang dengan beberapa perubahan dapat diadaptasi dengan skenario DR, lihat Menetapkan 99,99% Ketersediaan untuk Dedicated Interconnect.
Untuk beberapa contoh topologi gateway VPN multiregion yang sangat tersedia, yang juga dapat disesuaikan dengan skenario DR, lihat Topologi Cloud VPN.
Pertimbangan utama saat menyiapkan koneksi ke Google Cloud dari situs di luar platform adalah bandwidth. Koneksi harus mendukung transfer data dan cadangan reguler secara memadai ke Google Cloud.
Untuk mengetahui informasi selengkapnya mengenai opsi yang tersedia untuk terhubung ke Google Cloud dari situs di luar platform, lihat Produk konektivitas hybrid.
Konektivitas antara aplikasi SAP, database, dan server
Jika sistem utama Anda berjalan di Google Cloud, mempertahankan konektivitas antara aplikasi SAP, database, dan server di situs DR adalah masalah yang relatif sederhana dalam pemodelan nama host, subnet, firewall, dan seterusnya di situs utama.
Jika sistem utama Anda tidak berjalan di Google Cloud, upaya lebih mungkin diperlukan dalam fase desain untuk menerjemahkan arsitektur jaringan situs utama ke situs DR di Google Cloud.
Menguji prosedur DR Anda sangatlah penting untuk mengidentifikasi dan mengatasi masalah konektivitas sebelum bisnis Anda harus bergantung pada sistem yang dipulihkan.
Menghubungkan pengguna ke situs DR
Dalam pemulihan, setelah sistem SAP dipulihkan ke situs DR, traffic dari pengguna Anda harus dialihkan ke sistem yang dipulihkan. Biasanya, Anda melakukannya dengan memperbarui alias jaringan dalam entri DNS ke alamat IP baru yang bersifat regional.
Jika arsitektur jaringan Anda menggunakan rute VPC, Anda perlu memperbarui rute selama pemulihan.
Di Google Cloud, Anda dapat menggunakan Cloud DNS, atau Anda dapat menggunakan solusi DNS lainnya.
Resource jaringan regional
Jika sistem utama Anda berjalan di Google Cloud dan Anda menggunakan resource jaringan regional seperti Cloud NAT atau Cloud Load Balancing regional, Anda memerlukan instance resource di setiap region.
Untuk informasi selengkapnya:
Kontrol akses jaringan
Pastikan port yang sama terbuka di situs DR seperti yang terbuka di situs utama.
Anda dapat menentukan aturan firewall di jaringan VPC untuk mengontrol traffic ke dan dari VM Anda.
Jika memiliki layanan Active Directory di Windows Server, Anda perlu menyiapkannya sebelum pemulihan dan terus menyinkronkannya dengan instance Active Directory di situs utama.
Keamanan
Anda harus menerapkan izin dan kontrol keamanan yang sama dengan yang Anda miliki di situs utama di situs DR Anda. Peraturan kepatuhan yang sama juga berlaku untuk lingkungan yang dipulihkan.
Setiap pengguna atau peran yang memerlukan akses di situs utama juga memerlukan akses di situs DR.
Untuk informasi umum tentang mendesain keamanan untuk solusi DR di Google Cloud, lihat Menerapkan kontrol keamanan dan kepatuhan.
Pertimbangan VM
Anda dapat mempercepat deployment virtual machine (VM) Compute Engine dan menghindari error konfigurasi di situs DR menggunakan konfigurasi Terraform yang disediakan oleh Google Cloud, produk, dan fitur seperti Cloud Deployment Manager, template instance, dan image kustom.
Mengonfigurasi dan men-deploy mesin virtual Anda
Google Cloud menyediakan file konfigurasi Terraform dan template Deployment Manager untuk SAP di Google Cloud yang dapat Anda gunakan untuk melakukan pradefinisi dan men-deploy sistem SAP di DR situs Anda. Penggunaan file Terraform atau Deployment Manager akan mempercepat deployment, mengurangi error konfigurasi, dan memastikan sistem SAP Anda memenuhi persyaratan dukungan SAP.
Opsi lain untuk mengonfigurasi VM Anda terlebih dahulu adalah dengan template instance Compute Engine. Menggunakan template instance adalah cara untuk mempercepat deployment dan mengurangi konfigurasi manual VM Anda selama pemulihan. Namun, karena memerlukan beberapa konfigurasi ulang untuk situs DR, memulihkan VM Anda dari disk boot pemulihan seperti yang dijelaskan di bagian berikutnya mungkin lebih mudah.
Untuk mengetahui informasi selengkapnya tentang template instance, baca artikel Template instance.
Anda juga dapat menggunakan alat orkestrasi deployment, seperti Terraform, untuk mengelola deployment infrastruktur di Google Cloud.
Bergantung pada RTO, Anda dapat men-deploy instance Compute Engine terlebih dahulu atau men-deploy VM pada saat pemulihan karena men-deploy VM hanya memerlukan waktu beberapa menit.
Jika Anda melakukan pradeployment VM, Anda dapat menghentikannya untuk menghemat biaya atau menggunakannya untuk tujuan tidak penting lainnya hingga VM tersebut diperlukan untuk pemulihan.
Anda juga dapat meminimalkan biaya dengan mengonsolidasikan sistem terdistribusi pada lebih sedikit VM di situs pemulihan. Misalnya, jika server aplikasi di situs utama berada di host khusus di situs utama, di situs DR, Anda dapat menempatkan server aplikasi di host yang sama dengan Layanan Pusat SAP. Namun, Anda harus mempertimbangkan penghematan biaya terhadap meningkatnya kompleksitas karena memiliki konfigurasi yang berbeda di setiap situs.
Boot disk pemulihan
Anda dapat membuat image kustom dari boot disk host di sistem utama Anda, lalu menggunakan image kustom tersebut untuk membuat instance pemulihan di situs DR.
Jika sistem Anda berjalan di Google Cloud, buat image kustom jika Anda membuat dan memodifikasi persistent boot disk Compute Engine untuk sistem utama Anda. Jika menggunakan image publik Google Cloud yang tidak dimodifikasi, Anda juga dapat menggunakan image publik Google Cloud di situs pemulihan. Untuk mengetahui informasi selengkapnya, lihat Membuat, menghapus, dan menghentikan image kustom.
Jika sistem Anda tidak berjalan di Google Cloud, Anda dapat mengimpor image boot disk ke Google Cloud dari lingkungan lokal Anda, atau mengimpor disk virtual dari VM yang berjalan di workstation lokal Anda atau di platform cloud lainnya.
Opsi backup
Google Cloud menyediakan berbagai opsi pencadangan yang dapat Anda pilih saat mendesain solusi DR:
- Image kustom Compute Engine
- Snapshot persistent disk Compute Engine
- Replikasi
Image kustom Compute Engine
Untuk mencadangkan boot disk sistem utama untuk digunakan dalam pemulihan, Anda dapat menyimpannya di Google Cloud sebagai image kustom Compute Engine. Untuk informasi selengkapnya, lihat Boot disk pemulihan.
Snapshot persistent disk Compute Engine
Untuk mencadangkan SAP atau sistem file lainnya yang ada di persistent disk Compute Engine, Anda dapat menggunakan snapshot persistent disk.
Anda juga dapat menentukan jadwal snapshot untuk mengambil snapshot secara otomatis secara berkala. Lihat Membuat snapshot terjadwal untuk persistent disk.
Snapshot hanya memberikan konsistensi tingkat blok. Untuk memastikan konsistensi tingkat file, Anda mungkin perlu mengimplementasikan mekanisme untuk menangguhkan aktivitas tulis pada sistem file target selama snapshot ini.
Replikasi
Bergantung pada solusi penyimpanan bersama dan tujuan titik pemulihan, Anda dapat mereplikasi sistem file Anda. Replikasi dapat digunakan untuk database, penyimpanan tingkat blok, atau file.
Mendesain solusi DR yang menggunakan replikasi sangat cocok untuk aplikasi penting bisnis yang memiliki toleransi sangat rendah terhadap kehilangan data.
Jika sistem utama Anda berjalan di Google Cloud, bucket multiregion dan snapshot multiregion akan direplikasi untuk Anda di antara region yang dipilih.
Untuk replikasi penyimpanan tingkat blok, Anda dapat menggunakan Replikasi Asinkron PD. Replikasi Asinkron PD memberikan tujuan titik pemulihan (RPO) yang rendah dan replikasi asinkron objektif batas waktu pemulihan (RTO) yang rendah untuk pemulihan dari bencana aktif pasif lintas region.
Anda juga dapat menggunakan replikasi yang disediakan oleh solusi penyimpanan pihak ketiga.
Penyimpanan
Saat mendesain solusi DR di Google Cloud, Anda mungkin menggunakan beberapa jenis penyimpanan, bergantung pada tempat sistem utama Anda berjalan dan data apa yang Anda simpan.
Bucket Cloud Storage untuk file pencadangan
Untuk cadangan selain snapshot disk, seperti file yang Anda upload dari sistem SAP yang tidak berjalan di Google Cloud, buat bucket di Cloud Storage yang dapat Anda akses baik dari situs primer maupun situs DR. Saat membuat bucket, Anda memilih kelas penyimpanan dan lokasi default.
Pilih kelas penyimpanan default berdasarkan perjanjian tingkat layanan (SLA) yang Anda butuhkan, perkiraan penggunaan penyimpanan, dan batasan biaya Anda. Untuk DR, kelas penyimpanan coldline sering kali menjadi pilihan yang baik.
Untuk lokasi bucket, pilih lokasi yang menyertakan region situs DR dan, jika sistem utama Anda berjalan di Google Cloud, region situs utama Anda.
Jika sistem utama Anda berada di Google Cloud, pilih lokasi multiregion yang menyertakan region situs utama dan DR, sehingga Anda dapat mengakses bucket dari kedua situs.
Jika sistem utama Anda tidak ada di Google Cloud, untuk menghemat biaya, Anda dapat memilih lokasi satu region di region yang mencakup situs DR Anda.
Jika sistem utama Anda berada di Google Cloud dan Anda menggunakan solusi pihak ketiga untuk penyimpanan bersama, opsi penyimpanan Anda mungkin akan ditentukan oleh solusi tersebut. Lihat dokumentasi solusi atau perwakilan Cloud Customer Care Anda.
Untuk mengetahui informasi tentang harga, lihat Harga Cloud Storage.
Penyimpanan untuk snapshot persistent disk Compute Engine
Saat membuat snapshot, Anda dapat menentukan lokasi penyimpanan. Lokasi snapshot memengaruhi ketersediaannya dan dapat menimbulkan biaya jaringan saat Anda membuat snapshot atau memulihkannya ke disk baru.
Snapshot dapat disimpan dalam salah satu Lokasi multiregional Cloud Storage, misalnya asia, atau satu
Lokasi regional Cloud Storage,
seperti asia-south1.
Lokasi penyimpanan multiregional memberikan ketersediaan yang lebih tinggi dan dapat mengurangi biaya jaringan saat membuat atau memulihkan snapshot. Lokasi penyimpanan regional memberi Anda lebih banyak kontrol terhadap lokasi fisik data Anda.
Terlepas dari opsi lokasi yang Anda pilih, snapshot harus disimpan di lokasi yang dapat diakses dari situs DR Anda.
Untuk mengetahui informasi selengkapnya tentang lokasi snapshot, lihat Memilih lokasi penyimpanan untuk snapshot.
Untuk mengetahui informasi harga penyimpanan snapshot, lihat Harga persistent disk.
Penyimpanan untuk gambar kustom
Setelah Anda menambahkan file image kustom ke daftar image kustom, Compute Engine akan mengelola penyimpanan untuk image tersebut. Image dalam daftar image kustom merupakan resource global, sehingga tersedia di region mana pun.
Untuk mengetahui informasi tentang harga penyimpanan image, lihat Penyimpanan image.
Menguji rencana DR Anda
Setelah rencana DR Anda selesai, uji secara teratur, dengan memperhatikan masalah yang muncul dan sesuaikan rencana Anda.
Pastikan untuk menguji semua aspek rencana DR Anda, termasuk hal-hal seperti:
- Pencadangan dan jadwal pencadangan
- Transfer data dari situs di luar platform
- Pemulihan dari cadangan yang disimpan
- Kontrol keamanan dan akses sistem
- Pemilihan rute jaringan
Saat Anda menguji sistem DR, sistem utama Anda akan terus berjalan. Untuk mencegah konflik atau skenario otak terpisah, Anda harus mengisolasi sistem pengujian dari sistem utama dan penggunanya.
Untuk mengetahui informasi umum tentang pengujian DR di Google Cloud, lihat Panduan perencanaan pemulihan dari bencana.
Mendesain solusi DR untuk memenuhi RPO dan RTO Anda
Produk, fungsi, dan layanan Google Cloud tertentu merupakan kunci untuk merancang solusi DR yang memenuhi RPO dan RTO Anda.
Mendesain untuk RPO
Saat mendesain solusi DR di Google Cloud untuk memenuhi RPO tertentu, ada dua variabel yang mengontrol titik waktu yang dapat Anda pulihkan:
- Frekuensi pencadangan
- Retensi cadangan
Frekuensi pencadangan
Frekuensi pencadangan menentukan jumlah waktu maksimum yang dapat berlalu antara pencadangan terakhir dan bencana. Jika membuat cadangan DR setiap 24 jam, Anda berpotensi kehilangan update data selama hampir 24 jam jika terjadi bencana selama 23 jam 59 menit setelah pencadangan terakhir diambil.
Replikasi dapat mengurangi jumlah maksimum waktu berlalu sejak cadangan terakhir Anda mendekati nol; namun, replikasi itu mahal, jadi Anda mungkin hanya menggunakannya untuk database dan file aplikasi bisnis penting.
Dalam solusi DR, salinan atau snapshot titik waktu tertentu biasanya digunakan untuk mencadangkan sistem file aplikasi SAP yang diperlukan untuk pemulihan.
Di Google Cloud, Anda dapat mengotomatiskan snapshot persistent disk Compute Engine dengan membuat jadwal snapshot per jam, harian, atau mingguan. Namun, karena snapshot Compute Engine mengontrol konsistensi hanya pada tingkat blok, pertimbangkan untuk menangguhkan aktivitas tulis pada sistem file target selama snapshot guna memastikan konsistensi tingkat file.
Biaya utama yang perlu dipertimbangkan ketika memilih frekuensi pencadangan adalah biaya transfer data. Biaya penyimpanan juga menjadi pertimbangan, tetapi kebijakan retensi cadangan Anda mungkin berdampak lebih besar pada biaya penyimpanan dibandingkan frekuensi pencadangan.
Untuk mengetahui informasi selengkapnya tentang jadwal snapshot, lihat Membuat snapshot terjadwal untuk persistent disk.
Retensi cadangan
Retensi cadangan menentukan rentang waktu ke belakang saat Anda dapat memindahkan titik pemulihan. Menyimpan salinan cadangan membantu melindungi dari error logis dengan memungkinkan Anda untuk pulih ke titik waktu sebelum terjadi error logis.
Anda dapat menetapkan kebijakan retensi untuk snapshot Compute Engine dan bucket Cloud Storage yang otomatis menghapus file cadangan Anda setelah jangka waktu tertentu.
Biaya utama yang perlu dipertimbangkan saat memilih kebijakan retensi adalah biaya penyimpanan. Snapshot Compute Engine mengurangi jumlah penyimpanan yang diperlukan untuk beberapa snapshot dengan hanya menyimpan perubahan tingkat blok inkremental setelah snapshot lengkap pertama disimpan.
Untuk mengetahui informasi selengkapnya tentang cara menentukan kebijakan retensi untuk snapshot, lihat Kebijakan retensi snapshot.
Untuk mengetahui informasi tentang cara menetapkan kebijakan retensi pada bucket Cloud Storage, lihat Kebijakan retensi menggunakan Kunci Bucket.
Mendesain untuk RTO
Saat mendesain solusi Google Cloud DR agar memenuhi RTO tertentu, kesiapan infrastruktur, software, sistem file, dan data di situs DR adalah variabel pengontrol utama.
Misalnya, untuk mencapai RTO yang sangat rendah, Anda dapat mempertahankan sistem hot standby di situs DR, dengan infrastruktur yang di-deploy sebelumnya, sistem SAP aktif, dan data replika. Namun, RTO yang rendah memerlukan biaya yang lebih tinggi.
Anda dapat menyeimbangkan biaya dan waktu pemulihan dengan menyiapkan infrastruktur rendah atau gratis terlebih dahulu, serta menunda beberapa langkah penyiapan ke waktu pemulihan.
Misalnya, Anda dapat mengonfigurasi dan men-deploy VM terlebih dahulu, tetapi kemudian menghentikan VM tersebut. Resource yang terpasang ke VM, seperti IP statis eksternal atau persistent disk, mungkin masih dikenai biaya, tetapi VM yang dihentikan itu sendiri tidak dikenai biaya.
Karena Anda dapat mengonfigurasi dan men-deploy VM Compute Engine di Google Cloud dengan relatif cepat, Anda mungkin dapat melakukannya pada saat pemulihan dan tetap memenuhi RTO, terutama jika menggunakan Terraform atau Deployment Manager untuk men-deploy sistem DR Anda atau membuat VM dari template dan image kustom yang Anda buat sebelumnya.
Pertimbangan kuota dan resource untuk solusi DR RTO tinggi
Jika Anda tidak melakukan pradeployment infrastruktur dan sistem, periksa kuota resource di region situs DR secara berkala untuk memastikan bahwa kuotanya cukup untuk men-deploy sistem DR.
Melakukan pradeployment infrastruktur dan sistem DR sebanyak mungkin sesuai anggaran dapat membantu memastikan sistem DR sesuai dengan kuota, dan bahwa resource Google Cloud yang dibutuhkan sistem tersedia saat sistem membutuhkannya.
Contoh arsitektur untuk berbagai tujuan
Diagram arsitektur berikut menunjukkan contoh desain DR untuk RTO yang berbeda.
Setiap diagram menunjukkan opsi pencadangan multiregion di sebelah kiri dan konfigurasi SAP yang disederhanakan dan sesuai di situs DR di sebelah kanan.
Setiap contoh menunjukkan satu kemungkinan kombinasi elemen desain DR. Untuk menyesuaikan desain DR dengan tujuan dan keadaan, Anda dapat menggabungkan elemen dari salah satu atau semua contoh.
Arsitektur DR contoh RTO rendah
Diagram arsitektur berikut menunjukkan contoh desain DR RTO rendah.
Dalam desain ini, Anda memelihara sistem SAP yang hampir berfungsi di situs DR. VM di-deploy dan aktif. Server aplikasi SAP dan server database aktif, tetapi layanan aplikasi dihentikan.
Opsi cadangan yang mungkin Anda gunakan dalam skenario ini mencakup image OS yang disimpan dan snapshot persistent disk yang disimpan di Compute Engine, serta replikasi data antara situs utama dan DR. Untuk replikasi data, Anda dapat menggunakan Replikasi Asinkron PD.
Karena replikasi data digunakan, risiko kehilangan data terbatas pada sinkronisasi database terakhir.
Untuk memperpanjang RPO ke masa lalu, Anda dapat menambahkan cadangan data ke Cloud Storage, yang tidak ditampilkan dalam diagram. Untuk snapshot persistent disk, Anda dapat menggunakan snapshot terjadwal dan menyesuaikan kebijakan retensi dengan RPO Anda.
Tindakan yang perlu Anda lakukan untuk memulihkan sistem dengan RTO rendah seperti ini meliputi:
- Jika diperlukan, lakukan sinkronisasi akhir file atau pulihkan file dari snapshot persistent disk.
- Mengalihkan database utama ke situs DR.
- Memulai permohonan di situs DR.
Dari tiga contoh arsitektur yang ditampilkan, contoh RTO rendah adalah yang paling mahal.
Arsitektur DR contoh RTO medium
Contoh arsitektur DR berikut memiliki RTO yang lebih tinggi daripada contoh sebelumnya, tetapi biayanya lebih rendah.
Dalam desain ini, server database aktif untuk mendukung replikasi dari situs utama. VM untuk server aplikasi tidak aktif.
Opsi cadangan yang mungkin Anda gunakan dalam skenario ini mencakup image OS dan snapshot persistent disk yang disimpan di Compute Engine, serta replikasi data antara situs utama dan DR. Untuk replikasi data, Anda dapat menggunakan Replikasi Asinkron PD.
Karena replikasi data digunakan, risiko kehilangan data terbatas pada sinkronisasi database terakhir.
Untuk memperpanjang RPO ke masa lalu, Anda dapat menyimpan cadangan data di bucket Cloud Storage, yang tidak ditampilkan dalam diagram. Untuk snapshot persistent disk, Anda dapat menggunakan snapshot terjadwal dan menyesuaikan kebijakan retensi dengan RPO Anda.
Bergantung pada persyaratan sistem database, Anda mungkin dapat men-deploy database di VM yang lebih kecil di situs DR daripada yang diperlukan di situs utama. Hal ini dapat membantu mengurangi biaya hingga sistem DR diaktifkan. Dalam hal ini, Anda perlu mengubah ukuran VM ke ukuran yang diperlukan selama pemulihan.
Tindakan yang perlu Anda lakukan untuk memulihkan sistem seperti ini meliputi:
- Jika perlu, deploy instance VM untuk SAP NetWeaver dan server aplikasi dari snapshot atau image persistent disk.
- Menyinkronkan sistem file dari snapshot persistent disk atau penyimpanan lainnya.
- Jika perlu, ubah ukuran instance VM database.
- Mengalihkan database utama ke situs DR.
- Memulai layanan aplikasi di situs DR.
Arsitektur DR contoh RTO tinggi
Diagram arsitektur berikut memiliki RTO tertinggi dari contoh yang ditampilkan dan merupakan opsi berbiaya terendah.
Dalam desain ini, Anda dapat melakukan pradeployment server, lalu menghentikannya agar tidak menimbulkan biaya untuk VM atau, untuk menghindari biaya yang terkait dengan persistent disk dan resource terkait VM lainnya, Anda dapat men-deploy VM sebagai bagian dari proses pemulihan Anda.
Opsi cadangan yang mungkin Anda gunakan dalam skenario ini mencakup image OS yang disimpan dan snapshot persistent disk yang disimpan di Compute Engine, serta cadangan data yang disimpan di Cloud Storage.
Untuk memenuhi RPO tersebut, Anda dapat menyesuaikan frekuensi pencadangan dan kebijakan retensi jadwal snapshot serta cadangan di bucket Cloud Storage.
Tindakan yang perlu Anda lakukan untuk memulihkan sistem seperti ini meliputi:
- Jika perlu, deploy instance VM untuk SAP NetWeaver, server aplikasi, dan server database dari image atau snapshot persistent disk multiregional yang disimpan di Compute Engine.
- Menyinkronkan sistem file dari snapshot persistent disk atau penyimpanan lainnya.
- Memulihkan database dari file cadangan di bucket Cloud Storage multiregional atau di tempat lain.
- Mengalihkan database utama ke situs DR.
- Memulai layanan aplikasi di situs DR.
Partner dan produk solusi DR untuk SAP di Google Cloud
Anda dapat menemukan partner untuk mendapatkan bantuan terkait solusi DR di Direktori Partner Google Cloud.
Anda juga dapat menemukan berbagai produk dan partner untuk mendukung solusi DR Anda di Google Cloud Marketplace.