Halaman ini diterjemahkan oleh Cloud Translation API.

Ketahanan untuk deployment SAP di Google Cloud

Dokumen ini menjelaskan pertimbangan desain yang membantu Anda menjalankan sistem SAP yang tangguh dan andal di Google Cloud.

Infrastruktur dan software dapat mengalami kegagalan. Penyebab dan cakupan kegagalan tersebut memerlukan deployment sistem SAP untuk mengikuti prinsip-prinsip tertentu guna mendapatkan manfaat terbaik dari infrastruktur Google Cloud . Menggabungkan opsi infrastruktur dengan arsitektur deployment software SAP yang tangguh akan memastikan integritas data dan perlindungan terhadap kehilangan data atau ketersediaan sistem.

Opsi ketahanan dan keandalan

Anda dapat men-deploy sistem yang tangguh dan andal dengan memanfaatkan kemampuan di lapisan infrastruktur dan aplikasi untuk menyerap kegagalan, atau memungkinkan pemulihan dari kegagalan. Untuk memastikan ketahanan dan keandalan deployment sistem SAP di Google Cloud, sebaiknya pertimbangkan opsi berikut:

Ketahanan platform: Google Cloud layanan dan produk dirancang dengan mempertimbangkan ketahanan dan memiliki redundansi bawaan untuk mencapai Perjanjian Tingkat Layanan yang kami publikasikan. Saat Anda men-deploy sistem SAP sesuai dengan Google Cloud pedoman dan praktik terbaik, mekanisme platform yang mendasarinya akan meningkatkan ketahanan sistem SAP Anda. Hal ini memungkinkan Anda melanjutkan operasi bisnis jika terjadi kegagalan atau bencana.
Ketersediaan tinggi (HA): Dengan menggunakan konfigurasi infrastruktur dan software yang mendukung HA, Anda dapat mengaktifkan pemulihan sistem otomatis dengan gangguan minimal. Penggunaan ini juga memastikan bahwa intervensi minimum diperlukan dari Anda jika terjadi kegagalan di bagian infrastruktur mendasari atau software aplikasi. HA dimaksudkan untuk melindungi sistem Anda dari kegagalan atau degradasi komponen tunggal dengan menyediakan redundansi untuk komponen sistem Anda.
Pemulihan dari Bencana (DR): DR memungkinkan pemulihan operasi bisnis jika terjadi kegagalan yang disebabkan oleh bencana. DR melibatkan pemindahan layanan dan aplikasi ke lokasi sekunder yang terisolasi secara fisik, tempat operasi dapat dilanjutkan. Sistem DR meluas di luar kegagalan satu komponen atau layanan untuk memitigasi peristiwa yang lebih jarang terjadi, tetapi lebih berdampak. Hal ini dapat mencakup peristiwa regional seperti bencana alam, pemadaman listrik, dan peristiwa lokal seperti kebakaran atau kesalahan manusia. Ketentuan DR mencakup hal berikut:
- Replikasi data: Anda dapat menggunakan replikasi tingkat software atau penyimpanan untuk memastikan bahwa data Anda ditransfer ke lokasi sekunder dengan potensi kehilangan data minimal.
- Cadangan: Anda dapat memulihkan sistem atau database menggunakan cadangan yang disimpan secara terpisah dari penyimpanan data utama Anda. Hal ini dapat mencakup penggunaan snapshot atau cadangan yang diupload di Cloud Storage, asalkan snapshot atau cadangan disimpan di region selain tempat sistem di-deploy.

Karena opsi ini saling melengkapi, Anda dapat menggabungkan aspek dari setiap opsi untuk meningkatkan ketahanan dalam deployment SAP. Opsi yang Anda pilih memengaruhi batas waktu pemulihan (RTO) dan toleransi durasi kehilangan data (RPO) penempatan Anda. Oleh karena itu, Anda juga perlu mengevaluasi biaya opsi ini terhadap dampaknya terhadap ketahanan sistem dan kelangsungan bisnis. Sebaiknya pertimbangkan dengan cermat semua opsi yang tersedia dan terapkan sesuai dengan tujuan disaster recovery Anda.

Bagian berikut menjelaskan contoh deployment SAP dan dampak yang dapat Anda harapkan dari berbagai konfigurasi HA dan DR terhadap ketahanan dan keandalannya.

Contoh skenario

Pertimbangkan deployment SAP S/4HANA peningkatan skala di Google Cloud. Tabel berikut menampilkan contoh konfigurasi HA dan DR yang dapat diterapkan ke deployment ini dan dampak yang diharapkan pada dimensi ketahanan dan keandalan sistem seperti ketersediaan, RTO, dan RPO.

Konfigurasi HA atau DR	Dimensi ketahanan atau keandalan	Ekspektasi
Konfigurasi HA. Pertimbangkan hal berikut: `us-central1` adalah region utama. Instance X4 di-deploy di dua zona yang berbeda, seperti `us-central1-a` dan `us-central1-b`.	Ketersediaan	99,99% atau lebih tinggi untuk seluruh sistem. 99,9% atau lebih tinggi untuk setiap instance.
Konfigurasi DR yang menggunakan replikasi sistem SAP HANA asinkron ke sistem DR yang sepenuhnya berada di memori. Pertimbangkan hal berikut: `us-central1` adalah lokasi utama. `us-east4` adalah lokasi DR, dan menjalankan instance X4 yang ukurannya sama dengan lokasi utama. Data dimuat sebelumnya di instance X4 yang menjalankan SAP HANA di lokasi DR. Di lokasi DR, server aplikasi disediakan atau Anda telah membeli reservasi untuknya. ^{Catatan 1}	Waktu pemulihan	Beberapa jam, yang mungkin mencakup waktu yang diperlukan untuk penyebaran DNS ke sistem klien.
	Titik pemulihan	Menit, sehubungan dengan replikasi asinkron terakhir.
Konfigurasi DR yang menggunakan pencadangan dengan infrastruktur yang telah disediakan sebelumnya ^{Catatan 1}. Pertimbangkan sistem yang menggunakan pencadangan dan pemulihan berbasis Backint.	Waktu pemulihan	Waktu untuk memulihkan database dari cadangan ^{Catatan 2}.
	Titik pemulihan	Ke titik waktu terakhir dalam cadangan log atau snapshot SAP HANA.
Konfigurasi DR yang menggunakan pencadangan tanpa infrastruktur yang disediakan sebelumnya ^{Catatan 3}. Pertimbangkan sistem yang menggunakan pencadangan dan pemulihan berbasis Backint.	Waktu pemulihan	Beberapa hari untuk menyediakan infrastruktur ^{Catatan 4} dan memulihkan data dari cadangan ^{Catatan 3}.
	Titik pemulihan	Ke titik waktu terakhir dalam cadangan log atau snapshot SAP HANA.

Catatan tabel:

Anda dapat men-deploy solusi DR tanpa menyediakan infrastruktur yang diperlukan terlebih dahulu dengan memesan resource yang diperlukan terlebih dahulu. Ini adalah cara untuk memastikan ketersediaan resource yang diperlukan saat Anda perlu mengaktifkan solusi DR karena bencana di lokasi utama. Untuk mengetahui informasi selengkapnya, lihat Pemesanan resource zona Compute Engine.

Waktu eksekusi operasi pemulihan sangat bergantung pada solusi pencadangan yang digunakan dan ukuran file cadangan. Untuk menentukan perkiraan waktu yang tepat untuk ukuran database dan rasio perubahan, Anda perlu mengevaluasi kecepatan pemulihan untuk solusi pencadangan yang Anda gunakan, seperti Backint atau snapshot disk.

Men-deploy solusi DR tanpa melakukan pra-penyediaan atau pemesanan resource yang diperlukan dapat menyebabkan situasi saat resource yang diperlukan tidak tersedia. Hal ini dapat meningkatkan waktu pemulihan deployment, yang pada akhirnya memengaruhi operasi bisnis Anda.

Untuk jenis mesin seperti X4, yang tidak tersedia sesuai permintaan dan perlu dipesan, waktu tunggu beberapa minggu mungkin diperlukan tanpa reservasi kapasitas sebelumnya.

Pertimbangkan informasi yang disajikan dalam tabel sebelumnya sebagai tambahan untuk desain dan rencana pemulihan dari bencana yang ada yang Anda dapatkan dari panduan industri. Untuk informasi tambahan, lihat referensi berikut:

Rekomendasi untuk deployment yang tangguh

Bagian berikut memberikan ringkasan konfigurasi HA dan DR yang kami rekomendasikan untuk men-deploy workload SAP yang andal dan tangguh di Google Cloud.

Meskipun kami sangat merekomendasikan agar Anda menerapkan rekomendasi ini untuk beban kerja SAP yang menghosting operasi produksi yang penting bagi bisnis, Anda juga dapat menerapkannya untuk sistem SAP non-produksi yang pemadaman layanannya yang berkepanjangan dapat berdampak buruk pada operasi bisnis Anda.

Untuk mengetahui informasi tentang rekomendasi, lihat bagian berikut:

Rekomendasi ketersediaan tinggi
Rekomendasi pemulihan dari bencana
Rekomendasi lainnya

Rekomendasi ketersediaan tinggi

Gunakan minimal dua zona yang berbeda dalam region yang sama untuk men-deploy instance.
Menghilangkan titik tunggal kegagalan. Anda dapat melakukannya dengan menambahkan resource tambahan yang memberikan ketahanan dan redundansi ke layanan atau komponen aplikasi yang rusak jika terjadi kegagalan.
Gunakan layanan regional yang memiliki redundansi bawaan. Misalnya, gunakan Filestore Enterprise untuk menghosting file bersama, dan load balancer yang disediakan oleh Cloud Load Balancing.
Gunakan otomatisasi untuk failover. Otomatisasi membatasi kebutuhan intervensi manual jika terjadi kegagalan dan mengurangi dampaknya terhadap operasi bisnis. Misalnya, Anda dapat menggunakan pengelola cluster Linux seperti Pacemaker.
Gunakan jalur jaringan redundan. Pastikan Anda memiliki konektivitas redundan ke region utama. Bergantung pada persyaratan konektivitas Anda, berbagai opsi tersedia. Untuk informasi selengkapnya, lihat konektivitasGoogle Cloud .

Untuk mencapai ketersediaan 99,99% untuk koneksi ke region Google Cloud, sebaiknya konfigurasikan beberapa koneksi. Untuk informasi selengkapnya, lihat Menetapkan ketersediaan 99,99% untuk Dedicated Interconnect.
Aktifkan kebijakan migrasi langsung dan mulai ulang otomatis di resource Compute Engine:
- Agar instance komputasi tetap online selama peristiwa pemeliharaan yang dimulai Google, Anda dapat menggunakan migrasi langsung dengan menetapkan properti onHostMaintenance dengan opsi MIGRATE (Default). Untuk instance komputasi yang tidak mendukung migrasi langsung, tetapkan properti automaticRestart ke true (Default). Hal ini memungkinkan Google memulai ulang instance yang menjadi tidak responsif. Untuk mengetahui informasi selengkapnya, lihat Tentang peristiwa host.
- Untuk instance komputasi yang tidak mendukung migrasi langsung atau pemeliharaan terencana, kontrol pemeliharaan lanjutan tersedia. Untuk mengetahui informasi selengkapnya, lihat Mengaktifkan kontrol pemeliharaan lanjutan untuk node tenant tunggal.
Sebelum peluncuran, uji failover di lingkungan Anda.
- Untuk memastikan konfigurasi HA Anda disiapkan dengan benar dan berfungsi seperti yang diharapkan, pastikan untuk menguji skenario kegagalan yang memicu penghentian satu atau beberapa komponen. Untuk informasi selengkapnya, lihat Menguji cluster HA di Google Cloud.
- Untuk mengevaluasi konfigurasi HA, Anda dapat menggunakan Workload Manager. Untuk mengetahui informasi selengkapnya, lihat Tentang evaluasi Workload Manager. Untuk mengetahui informasi tentang evaluasi yang didukung Workload Manager untuk workload SAP, lihat Praktik terbaik Workload Manager untuk SAP.

Rekomendasi pemulihan dari bencana

Menghosting solusi DR di lokasi selain lokasi utama. Untuk menghindari solusi DR Anda terpengaruh oleh peristiwa yang sama dengan sistem utama, pastikan keduanya dihosting di lokasi yang berbeda.

Idealnya, lokasi DR Anda harus berada di wilayah yang berbeda. Namun, jika menggunakan wilayah kedua bukan opsi yang baik karena masalah kebangsaan atau residensi data, hubungi Google Cloud Penjualan untuk membahas opsi lain yang tersedia.

Diagram berikut menunjukkan arsitektur tingkat tinggi untuk deployment SAP HANA di Google Cloud dengan penyediaan HA dan DR berikut:
- Untuk mencapai HA, sistem utama memiliki dua node yang di-deploy di zona yang berbeda dalam region yang sama.
- Untuk mengaktifkan ketahanan, sistem utama dan DR dihosting di region yang berbeda, dengan replikasi asinkron.
Pastikan kapasitas yang memadai di lokasi DR.
- Tentukan apakah sistem DR Anda perlu berjalan dengan kapasitas yang sama dengan sistem utama atau dengan kapasitas yang berkurang. Untuk database seperti SAP HANA, lokasi DR Anda harus memiliki resource yang cukup untuk mengoperasikan beban kerja SAP secara produktif.
- Selain itu, periksa terlebih dahulu apakah resource yang diperlukan tersedia di lokasi DR Anda. Untuk memastikan ketersediaan resource, Anda dapat menyediakannya di lokasi DR atau membeli reservasi terlebih dahulu. Membeli reservasi membantu Anda menghindari skenario saat setelah kegagalan, resource tidak tersedia karena dialokasikan ke pelanggan Google Cloud lain. Hal ini sangat penting untuk jenis instance komputasi yang lebih besar seperti M2 atau X4. Untuk informasi tentang reservasi, lihat Pemesanan resource zona Compute Engine.
Untuk mencapai efisiensi biaya yang lebih besar, infrastruktur di lokasi DR Anda dapat digunakan untuk workload non-produksi, dan dialihkan untuk menayangkan workload produksi selama peristiwa DR. Namun, hal ini akan meningkatkan waktu pemulihan.
Validasi konektivitas ke lokasi DR Anda. Seperti jalur jaringan redundan ke lokasi utama Anda, pertimbangkan untuk menambahkan opsi penggantian tambahan seperti Cloud VPN.
Identifikasi sinyal yang dapat digunakan untuk mengidentifikasi bencana. Sinyal ini membantu dalam membuat keputusan tentang kapan harus memicu solusi DR Anda. Berikut adalah contoh beberapa sinyal tersebut:
- Informasi tentang kondisi Google Cloud layanan dari Google Cloud kondisi layanan.
- Kehilangan total ketersediaan instance seperti yang dilaporkan oleh Cloud Monitoring, seperti yang dikonfigurasi untuk project Google Cloud Anda.
- Komunikasi dari Layanan Pelanggan Google Cloud atau perwakilan akunGoogle Cloud Anda, yang memberikan saran tentang pemadaman layanan dan kemungkinan waktu penyelesaian.
- Kerusakan logis pada database yang ditentukan oleh pengguna atau administrator sistem SAP Anda, yang tidak dapat diatasi oleh mekanisme HA.
Uji solusi DR Anda secara rutin. Pastikan solusi Anda berfungsi jika terjadi bencana. Hal ini dapat memengaruhi operasi sehari-hari Anda. Jika operasi Anda memungkinkan, pertimbangkan untuk beroperasi secara simetris di lokasi utama dan sekunder, lalu rotasilah operasi di antara keduanya setiap 3 hingga 6 bulan.
Gunakan replikasi untuk mencapai titik pemulihan terbaik. Replikasi memberikan versi situs utama Anda yang hampir real-time di situs DR. Opsi replika berikut tersedia, bergantung pada cara workload SAP Anda dirancang:
- Replikasi tingkat database dengan memanfaatkan mekanisme seperti replikasi sistem SAP HANA, yang mereplikasi pada tingkat logis antara situs utama dan DR.
- Replikasi tingkat penyimpanan dengan memanfaatkan mekanisme seperti Replikasi Asinkron PD, yang mereplikasi pada tingkat penyimpanan blok. Bergantung pada opsi penyimpanan yang digunakan oleh workload SAP Anda, opsi replikasi tingkat penyimpanan yang tersedia akan berbeda.
Pastikan untuk memantau replikasi menggunakan alat yang sesuai, seperti SAP HANA Cockpit. Hal ini membantu memverifikasi bahwa beban kerja SAP Anda telah direplikasi sepenuhnya sebelum solusi DR dipicu jika terjadi peristiwa DR.
Gunakan pencadangan data untuk menyediakan pemulihan point-in-time.
- Untuk membuat redundansi, gunakan beberapa lokasi penyimpanan untuk menyimpan cadangan Anda. Contoh:
  - Saat membuat cadangan menggunakan fitur Backint dari AgenGoogle Clouduntuk SAP, gunakan lokasi bucket dual-region atau multi-region. Untuk mengetahui informasi selengkapnya, lihat Membuat bucket Cloud Storage.
  - Saat membuat cadangan menggunakan fitur snapshot disk agen, gunakan Cloud Storage multi-region atau dual-region. Untuk mengetahui informasi tentang lokasi bucket Cloud Storage, lihat Lokasi bucket.
- Gunakan pencadangan tambahan atau diferensial, yang dapat mencakup penyimpanan snapshot di Google Cloud.
- Pantau pencadangan Anda untuk memastikan pencadangan dibuat dengan benar sesuai dengan strategi pencadangan Anda. Untuk solusi perlindungan data lengkap, pertimbangkan untuk menggunakan Backup and DR Service Google Cloud.
- Uji pencadangan Anda secara berkala untuk memastikan bahwa pencadangan tersebut dapat dipulihkan jika terjadi bencana dan tinjau berapa lama waktu yang diperlukan untuk memulihkan sistem atau database Anda. Sebaiknya uji pemulihan sekali setiap siklus pencadangan, yang biasanya berlangsung selama 28 hari.
- Lindungi cadangan Anda seperti yang Anda lakukan pada sistem utama, misalnya, dengan menggunakan setelan retensi penyimpanan dan kunci enkripsi.

Rekomendasi lainnya

Evaluasi biaya konfigurasi HA dan DR berdasarkan dampak yang dimilikinya terhadap aspek bisnis Anda berikut:
- Potensi periode nonaktif dalam operasi dan transaksi bisnis.
- Potensi kebocoran data yang mengakibatkan hilangnya kepercayaan penjualan, pelanggan, atau vendor, atau kegagalan kepatuhan.
Setiap bisnis memiliki pertimbangan yang unik. Jika situasi tertentu Anda memerlukan solusi yang lebih disesuaikan, jangan ragu untuk menghubungi Google Cloud Penjualan.