Panduan ini memberikan ringkasan opsi pemulihan dari bencana untuk sistem SAP HANA yang di-deploy di Google Cloud.
Panduan ini tidak dimaksudkan untuk menggantikan dokumentasi SAP standar.
Persiapan untuk pemulihan dari bencana
Untuk bersiap menghadapi bencana, Anda dapat menggunakan replikasi sistem SAP HANA ke sistem SAP HANA sekunder, mengambil cadangan SAP HANA untuk mengaktifkan pemulihan, atau menggunakan keduanya.
Untuk workload sangat penting yang memerlukan waktu pemulihan cepat, gunakan replikasi sistem HANA untuk meminimalkan periode nonaktif. Penggunaan cadangan untuk memulihkan sistem memerlukan biaya lebih murah, tetapi memakan waktu lebih lama. Dalam situasi tersebut, sistem baru harus dibuat, lalu cadangan dipulihkan ke dalamnya agar dipulihkan ke waktu yang diinginkan.
Dalam kedua kasus tersebut, Anda harus menggunakan pengalihan berbasis jaringan untuk mengalihkan aplikasi klien yang menggunakan sistem SAP HANA ke alamat IP sistem pengganti setelah tersedia. Untuk informasi selengkapnya, lihat Panduan Administrasi SAP HANA.
Dimulai dengan SAP HANA SPS09, Anda dapat menggunakan API berbasis Python yang disertakan dengan SAP HANA untuk membuat penyedia ketersediaan tinggi/pemulihan dari bencana (HA/DR) Anda sendiri dan mengintegrasikannya dengan proses pengambilalihan Replikasi Sistem SAP HANA untuk mengotomatiskan tugas seperti mengalihkan koneksi klien database dari sistem utama ke sistem sekunder setelah pengambilalihan. Untuk informasi selengkapnya, lihat Menerapkan Penyedia HA/DR.
Perlu diperhatikan bahwa batasan apa pun yang ditentukan oleh SAP, termasuk batasan jarak untuk replikasi sinkron, juga berlaku di Google Cloud.
Sebagai alternatif opsi pemulihan dari bencana native, untuk pemulihan dari bencana (DR) aktif-pasif lintas region, Anda dapat menggunakan Replikasi Asinkron Persistent Disk (Replikasi Asink PD). Replikasi Asinkron PD menyediakan replikasi data asinkron antara dua region Google Cloud.
Pemulihan dari bencana menggunakan Replikasi Sistem SAP HANA
Untuk memaksimalkan penggunaan resource infrastruktur dan mengoptimalkan biaya solusi DR, Anda dapat menggunakan sistem sekunder untuk kasus penggunaan non-produksi, seperti untuk sistem pengembangan atau QA. Dalam hal ini, sistem sekunder tidak dipramuat dengan data, sehingga waktu failover lebih lama daripada sistem sekunder memuat data sebelumnya dan tetap sinkron dengan sistem utama.
HANA 2 SPS00 mencakup dukungan untuk mode konfigurasi Aktif/Aktif (baca diaktifkan), yang memungkinkan replikasi sistem SAP HANA mendukung akses baca pada sistem sekunder. Untuk informasi selengkapnya, lihat Aktif/Aktif (Baca Diaktifkan).
Replikasi sinkron dan asinkron didukung saat menggunakan replikasi sistem SAP HANA dengan Google Cloud.
Jika memungkinkan, sebaiknya gunakan replikasi sinkron, dengan transaksi SQL tidak di-commit pada instance database utama hingga di-commit di instance standby. Hal ini akan menjaga instance standby tetap sinkron dan memastikan objektif titik pemulihan nol. Replikasi sinkron dapat digunakan untuk instance yang berada di zona mana pun dalam region yang sama.
Jika sistem standby berada di region yang berbeda dengan sistem utama, gunakan replikasi asinkron, tanpa menunggu instance standby untuk mengonfirmasi data sebelum di-commit pada instance utama. Dalam skenario ini, Anda mungkin kehilangan sejumlah kecil data jika terjadi bencana. Konsekuensinya, replikasi asinkron memberi Anda objektif poin pemulihan yang lebih besar dari nol.
Untuk semua skenario replikasi, Anda harus melakukan pengambilalihan secara manual pada sistem standby untuk memulai pemulihan dari bencana. Anda juga perlu mengalihkan secara manual aplikasi apa pun yang menggunakan database SAP HANA untuk menargetkan instance yang gagal di dalam sistem standby.
Pilih opsi Replikasi Sistem HANA yang paling sesuai dengan kebutuhan bisnis Anda, seperti batas waktu pemulihan (RTO), dan batas titik pemulihan (RPO). Untuk mengetahui informasi selengkapnya, lihat Mode Replikasi untuk Replikasi Sistem SAP HANA.
Replikasi Sistem SAP HANA dengan pramuat
Dalam skenario ini, sistem SAP HANA Anda direplikasi ke sistem standby khusus. Database SAP HANA direplikasi ke VM Compute Engine yang memiliki nama host unik dan persistent disk-nya sendiri yang terpasang. Semua data SAP HANA dimuat ke dalam memori di sistem standby. Jika Anda harus melakukan failover, waktu failover hanya memerlukan waktu sekitar 90 detik karena semua data telah dimuat sebelumnya.
Untuk mengetahui informasi selengkapnya tentang Replikasi Sistem SAP HANA dengan pramuat, lihat bagian Replikasi Sistem di SAP HANA – Ketersediaan Tinggi.
Replikasi Sistem SAP HANA tanpa pramuat
Dalam skenario ini, sistem SAP HANA Anda direplikasi ke sistem standby khusus. Database SAP HANA direplikasi ke VM Compute Engine yang memiliki nama host unik dan persistent disk-nya sendiri yang terpasang. Data SAP HANA tidak dimuat ke dalam memori pada sistem standby. Jika Anda harus melakukan failover, waktu failover dapat memerlukan waktu dari beberapa menit hingga jam, bergantung pada ukuran set data Anda.
Jika Anda tidak melakukan pramuat data, persyaratan memori untuk VM Compute Engine yang menghosting database SAP HANA jauh lebih kecil. Untuk panduan pengaturan ukuran terbaru, lihat catatan SAP 1999880 - FAQ: Replikasi Sistem SAP HANA di bagian "Aturan mana yang berlaku untuk penggunaan memori pada situs replikasi sistem sekunder?".
Anda bisa mendapatkan informasi tentang jejak memori rowstore dengan menjalankan kueri berikut:
SELECT round (sum(USED_FIXED_PART_SIZE + USED_VARIABLE_PART_SIZE)/1024/1024) AS "Row Tables MB" FROM M_RS_TABLES;
Pengurangan persyaratan memori memberi Anda opsi hemat biaya saat memilih jenis mesin Compute Engine.
Anda dapat menggunakan jenis mesin yang memiliki spesifikasi memori rendah untuk menghosting database SAP HANA dalam sistem standby guna menurunkan biaya pengoperasian Anda. VM dengan memori rendah tidak didukung untuk SAP HANA di sistem produksi, tetapi Anda dapat menggunakan VM berbiaya lebih rendah ini untuk melakukan pengambilalihan dalam skenario pemulihan dari bencana, lalu Anda dapat memodifikasi VM setelahnya untuk mengubah jenis mesin menjadi satu dengan jumlah memori yang didukung. Untuk melakukannya, Anda harus menghentikan VM agar melakukan upgrade, sehingga akan ada periode nonaktif tambahan sebelum sistem SAP HANA tersedia.
Anda dapat menggunakan jenis mesin bermemori tinggi untuk menghosting database SAP HANA dalam sistem standby, dan dapat membagikannya dengan sistem pengembangan atau pengujian untuk meningkatkan laba atas investasi Anda. Anda dapat menetapkan batas alokasi global untuk database SAP HANA menjadi 64 GB dengan mengikuti petunjuk di Mengubah Batas Alokasi Memori Global, sehingga menyisakan sisa memori untuk sistem lain untuk digunakan. Saat sistem standby diperlukan, matikan operasi pengembangan dan pengujian, lakukan pengambilalihan, lalu hapus batas alokasi global.
Anda dapat menggunakan replikasi sinkron dan asinkron tanpa pramuat. Namun, replikasi sinkron mengharuskan instance sumber dan target berada di region Google Cloud yang sama.
Anda dapat menggunakan penyedia HA/DR untuk mengatasi masalah seperti menonaktifkan sistem pengembangan dan/atau pengujian di host sekunder.
Memicu pengambilalihan
Untuk memanggil pemulihan dari bencana, picu prosedur Pengambilalihan Replikasi Sistem SAP HANA di sistem standby Anda. Catatan SAP 2063657 menyediakan panduan untuk membantu Anda memutuskan apakah pengambilalihan adalah opsi terbaik.
Untuk memicu pengambilalihan, ikuti proses pengambilalihan SAP HANA standar. Untuk mengetahui informasi detail selengkapnya tentang prosedur ini, lihat Cara Melakukan Replikasi Sistem untuk SAP HANA 2.0.
Jika terjadi masalah data atau kegagalan software, mungkin tidak ada notifikasi otomatis sehingga Anda dapat melakukan pengambilalihan. Pertimbangkan untuk membuat solusi khusus guna mengirim pemberitahuan menggunakan alat pemantauan Cloud Monitoring atau HANA.
Pemulihan dari bencana menggunakan pencadangan SAP HANA
Jika batas waktu pemulihan yang lebih lama dapat diterima dan batas titik pemulihan Anda lebih dari 15 menit, Anda dapat melakukan pemulihan dari bencana dengan melakukan pemulihan dari cadangan. Untuk memastikan keberhasilan pemulihan saat menggunakan cadangan, buat salinan file cadangan secara rutin, terutama cadangan log, ke bucket Cloud Storage, atau lokasi penyimpanan jangka panjang lainnya yang ada di luar region tempat sistem SAP HANA Anda berjalan. Sebaiknya dokumentasikan infrastruktur sistem utama Anda dan buat skrip yang memungkinkan Anda membuat sistem pengganti dengan cepat untuk memulihkan cadangan Anda.
Untuk informasi selengkapnya, lihat panduan operasi SAP HANA.
Pemulihan dari bencana menggunakan Replikasi Asinkron PD
Untuk workload SAP yang berjalan di Google Cloud, Replikasi Asinkron PD memungkinkan pemulihan dari bencana dengan mereplikasi data antara dua region Google Cloud. Replikasi Asinkron PD menyediakan replikasi asinkron block storage batas titik pemulihan (RPO) rendah dan batas waktu pemulihan (RTO) rendah untuk pemulihan dari bencana pasif aktif lintas region. Jika terjadi pemadaman layanan regional, Replikasi Asinkron PD memungkinkan Anda melakukan failover data SAP ke region sekunder dan memulai ulang workload SAP di region tersebut.
Anda dapat menggunakan Replikasi Asinkron PD guna mengelola replikasi untuk workload SAP berbasis Compute Engine di tingkat infrastruktur, bukan tingkat workload SAP seperti Replikasi Sistem SAP HANA.
Replikasi Asinkron PD mereplikasi data SAP dari disk utama yang terpasang pada workload yang sedang berjalan ke disk kosong sekunder yang terletak di region lain. Untuk mengetahui informasi selengkapnya, lihat Tentang Replikasi Asinkron Persistent Disk.
Batasan Replikasi Asinkron PD
Untuk Replikasi Asinkron PD, Anda hanya dapat menggunakan
persistent disk seimbang (pd-balanced) dan persistent disk performa (SSD) (pd-ssd) dalam pasangan region yang didukung.
Untuk mengetahui informasi
selengkapnya, lihat Batasan.
Pantau dan evaluasi laju perubahan pada workload Anda terhadap kemampuan Replikasi Asinkron PD dengan meninjau metrik pemantauan untuk pasangan perangkat Anda, seperti yang dijelaskan dalam Meninjau performa Replikasi Asinkron Persistent Disk.
Metrik async_replication/sent_bytes_count diperkirakan tidak akan menampilkan peningkatan jumlah data yang ditransfer secara konstan karena metrik ini mewakili delta jumlah byte yang dikirim melalui jaringan lintas region.