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 bisa gagal. Penyebab dan cakupan kegagalan tersebut mengharuskan deployment sistem SAP untuk mengikuti prinsip tertentu agar dapat memanfaatkan infrastruktur Google Cloud sebaik mungkin. Menggabungkan opsi infrastruktur dengan arsitektur deployment software SAP yang tangguh memastikan integritas dan perlindungan data terhadap kehilangan data atau ketidaktersediaan sistem.

Opsi ketahanan dan keandalan

Anda dapat men-deploy sistem yang tangguh dan tangguh 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 Anda mempertimbangkan opsi berikut:

  • Ketahanan platform: Layanan dan produk Google Cloud dirancang dengan mempertimbangkan ketahanan dan memiliki redundansi bawaan untuk mencapai Perjanjian Tingkat Layanan yang telah kami publikasikan. Saat Anda men-deploy sistem SAP sesuai dengan pedoman dan praktik terbaik Google Cloud, mekanisme platform yang mendasarinya meningkatkan ketahanan sistem SAP Anda. Dengan demikian, Anda dapat 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 intervensi minimal diperlukan dari Anda jika terjadi kegagalan di bagian software aplikasi atau infrastruktur yang mendasarinya. HA dimaksudkan untuk melindungi sistem Anda dari kegagalan atau degradasi komponen tunggal dengan memberikan redundansi untuk komponen sistem Anda.
  • Disaster Recovery (DR): DR memungkinkan pemulihan operasi bisnis jika kegagalan yang disebabkan oleh bencana. DR melibatkan pemindahan layanan dan aplikasi ke lokasi sekunder yang terisolasi secara fisik dari tempat operasi dapat dilanjutkan. Sistem DR mencakup di luar kegagalan layanan atau komponen tunggal untuk memitigasi peristiwa yang lebih jarang tetapi lebih berdampak. Hal ini dapat mencakup peristiwa regional seperti bencana alam, hilangnya jaringan listrik, dan peristiwa yang dilokalkan seperti kebakaran atau kesalahan manusia. Ketentuan DR mencakup hal berikut:
    • Replikasi data: Anda dapat menggunakan replikasi tingkat software atau penyimpanan untuk memastikan data ditransfer ke lokasi sekunder dengan potensi kehilangan data minimal.
    • Cadangan: Anda dapat memulihkan sistem atau database menggunakan cadangan yang disimpan terpisah dari penyimpanan data utama Anda. Hal ini dapat mencakup penggunaan snapshot atau cadangan yang diupload di Cloud Storage, asalkan snapshot atau cadangan tersebut disimpan di region selain tempat sistem di-deploy.

Karena opsi ini bersifat komplementer, Anda dapat menggabungkan aspek dari setiap opsi untuk meningkatkan ketahanan dalam deployment SAP. Opsi yang Anda pilih akan memengaruhi batas waktu pemulihan (RTO) dan batas titik pemulihan (RPO) deployment Anda. Oleh karena itu, Anda juga perlu mengevaluasi biaya opsi tersebut terhadap dampaknya terhadap ketahanan sistem dan kelangsungan bisnis. Sebaiknya pertimbangkan dengan cermat semua opsi yang tersedia dan terapkan agar sesuai dengan tujuan pemulihan dari bencana (disaster recovery) Anda.

Bagian berikut menjelaskan contoh deployment SAP beserta dampak yang bisa Anda harapkan dari konfigurasi HA dan DR yang berbeda-beda terhadap ketahanan dan keandalannya.

Contoh skenario

Pertimbangkan untuk meningkatkan skala deployment SAP S/4HANA di Google Cloud. Tabel berikut menyajikan contoh konfigurasi HA dan DR yang dapat diterapkan ke deployment ini dan dampaknya yang diharapkan terhadap 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, misalnya 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 Resident DR memori penuh. Pertimbangkan hal berikut:
  • us-central1 adalah lokasi utamanya.
  • us-east4 adalah lokasi DR, dan menjalankan instance X4 yang berukuran sama dengan lokasi utama.
  • Data telah dimuat sebelumnya di instance X4 yang menjalankan SAP HANA di lokasi DR.
  • Di lokasi DR, server aplikasi disediakan atau Anda telah membeli reservasi untuk server aplikasi tersebut. Catatan 1
 Waktu pemulihan Beberapa jam, yang mungkin termasuk waktu yang diperlukan untuk penerapan DNS ke sistem klien.
Poin pemulihan Menit, sehubungan dengan replikasi asinkron terakhir.
Konfigurasi DR yang menggunakan cadangan dengan infrastruktur yang telah disediakan Catatan 1. Pertimbangkan sistem yang menggunakan pencadangan dan pemulihan berbasis Backint. Waktu pemulihan Saatnya memulihkan database dari cadangan Catatan 2.
Poin pemulihan Sampai waktu terakhir dalam pencadangan atau snapshot log SAP HANA.
Konfigurasi DR yang menggunakan cadangan tanpa infrastruktur yang telah disediakan Catatan 3. Pertimbangkan sistem yang menggunakan pencadangan dan pemulihan berbasis Backint. Waktu pemulihan Beberapa hari untuk menyediakan infrastruktur Note 4 dan memulihkan data dari cadangan Note 3.
Poin pemulihan Sampai waktu terakhir dalam pencadangan atau snapshot log SAP HANA.

Catatan tabel:

  1. Anda dapat men-deploy solusi DR tanpa melakukan pra-penyediaan terhadap infrastruktur yang diperlukan dengan memesan resource yang diperlukan terlebih dahulu. Ini adalah cara untuk memastikan ketersediaan resource yang diperlukan saat Anda perlu mengaktifkan solusi DR akibat bencana di lokasi utama. Untuk mengetahui informasi selengkapnya, lihat Reservasi resource zona Compute Engine.

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

  3. Men-deploy solusi DR tanpa pra-penyediaan atau menyimpan resource yang diperlukan dapat menimbulkan situasi saat resource yang diperlukan tidak tersedia. Hal ini dapat memperpanjang waktu pemulihan deployment Anda, yang pada akhirnya akan memengaruhi operasi bisnis Anda.

  4. Untuk jenis mesin seperti X4, yang tidak tersedia secara on demand dan perlu dipesan, lama pengerjaan 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 sudah ada yang Anda peroleh berdasarkan pedoman industri. Untuk informasi tambahan, lihat referensi berikut:

Rekomendasi deployment yang tangguh

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

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

Untuk informasi tentang rekomendasi, lihat bagian berikut:

Rekomendasi ketersediaan tinggi

  • Gunakan minimal dua zona yang berbeda dalam region yang sama untuk men-deploy instance.
  • Hapus titik tunggal kegagalan. Anda dapat mencapai hal ini dengan menambahkan resource tambahan yang memberikan ketahanan dan redundansi ke layanan atau komponen aplikasi yang salah 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 atas 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 mengetahui informasi selengkapnya, lihat konektivitas Google Cloud.

    Guna mencapai ketersediaan 99,99% untuk koneksi Anda ke region Google Cloud, sebaiknya konfigurasi beberapa koneksi. Untuk mengetahui 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 apa pun yang menjadi tidak responsif. Untuk 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 melakukan live streaming, 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 mengetahui informasi selengkapnya, baca artikel Menguji cluster HA di Google Cloud.
    • Untuk mengevaluasi konfigurasi HA, Anda dapat menggunakan Workload Manager. Untuk mengetahui informasi lebih lanjut, lihat artikel 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

  • Hosting solusi DR di lokasi selain lokasi utama. Agar solusi DR tidak terpengaruh oleh peristiwa yang sama dengan sistem utama, pastikan keduanya dihosting di lokasi yang berbeda.

    Idealnya, lokasi DR Anda harus berada di region yang berbeda. Namun, jika penggunaan region kedua bukan merupakan opsi yang tepat karena masalah residensi data atau kedaulatan data, hubungi Tim Penjualan Google Cloud untuk mendiskusikan opsi lain yang tersedia.

    Diagram berikut menunjukkan arsitektur tingkat tinggi untuk deployment SAP HANA di Google Cloud dengan ketentuan HA dan DR berikut:

    • Untuk mencapai HA, sistem utama memiliki dua node yang di-deploy di zona berbeda dalam region yang sama.
    • Untuk mewujudkan ketahanan, sistem primer dan DR dihosting di berbagai region, dengan replikasi asinkron.

    Diagram arsitektur tingkat tinggi untuk SAP HANA di Google Cloud dengan ketersediaan tinggi dan pemulihan dari bencana.

  • Pastikan kapasitas yang memadai di lokasi DR.

    • Tentukan apakah sistem DR Anda perlu dijalankan dengan kapasitas yang sama dengan sistem utama atau pada kapasitas yang berkurang. Untuk database seperti SAP HANA, lokasi DR Anda harus memiliki resource yang cukup untuk mengoperasikan workload SAP secara produktif.
    • Selanjutnya, 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. Pembelian reservasi membantu Anda menghindari skenario ketika setelah kegagalan, resource tidak tersedia karena dialokasikan ke pelanggan Google Cloud lainnya. Hal ini sangat penting untuk jenis instance komputasi yang lebih besar, seperti M2 atau X4. Untuk mengetahui informasi tentang reservasi, lihat Reservasi 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 melayani beban kerja produksi Anda selama peristiwa DR. Namun, cara ini membutuhkan waktu pemulihan yang lebih lama.

  • Validasi konektivitas ke lokasi DR Anda. Seperti pada jalur jaringan redundan ke lokasi utama Anda, pertimbangkan untuk menambahkan opsi cadangan tambahan seperti Cloud VPN.

  • Identifikasi sinyal yang dapat digunakan untuk mengidentifikasi bencana. Sinyal ini membantu mengambil keputusan tentang kapan harus memicu solusi DR Anda. Berikut adalah contoh dari beberapa sinyal tersebut:

    • Informasi tentang kondisi layanan Google Cloud dari kondisi layanan Google Cloud.
    • Hilangnya total ketersediaan instance seperti yang dilaporkan oleh Cloud Monitoring, seperti yang dikonfigurasi untuk project Google Cloud Anda.
    • Komunikasi dari Google Cloud Customer Care atau perwakilan akun Google Cloud Anda, yang memberikan saran terkait pemadaman layanan dan kemungkinan waktu penyelesaiannya.
    • Kerusakan logis pada database yang ditentukan oleh pengguna atau administrator sistem SAP Anda, yang tidak dapat diselesaikan dengan mekanisme HA.

  • Uji solusi DR Anda secara rutin. Pastikan solusi Anda berfungsi jika terjadi bencana. Hal ini dapat memengaruhi operasi Anda sehari-hari. Jika operasi Anda memungkinkan, pertimbangkan untuk beroperasi secara simetris di lokasi primer dan sekunder, dan rotasikan operasi di antara keduanya setiap 3 hingga 6 bulan.

  • Gunakan replikasi untuk mencapai titik pemulihan terbaik. Replikasi memberikan versi yang mendekati real-time dari situs utama Anda di situs DR. Opsi replikasi berikut tersedia, bergantung pada cara workload SAP Anda dirancang:

    • Replikasi tingkat database dengan memanfaatkan mekanisme seperti replikasi sistem SAP HANA, yang mereplikasi di tingkat logis antara situs utama dan DR.
    • Replikasi tingkat penyimpanan dengan memanfaatkan mekanisme seperti Replikasi Asinkron PD yang berreplikasi pada tingkat block storage. 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 workload SAP Anda telah sepenuhnya direplikasi sebelum solusi DR Anda dipicu jika terjadi peristiwa DR.

  • Gunakan cadangan data untuk memberikan kemampuan pemulihan point-in-time.

    • Untuk membuat redundansi, gunakan beberapa lokasi penyimpanan untuk menyimpan cadangan Anda. Contoh:
      • Saat membuat cadangan berbasis Backint menggunakan Agen Google Cloud untuk SAP, gunakan lokasi bucket dual-region atau multi-region. Untuk mengetahui informasi selengkapnya, lihat Membuat bucket Cloud Storage.
      • Saat membuat pencadangan berbasis snapshot disk, gunakan Cloud Storage multi-region atau dual-region. Untuk mengetahui informasi tentang lokasi bucket Cloud Storage, lihat Lokasi bucket.
    • Gunakan pencadangan inkremental atau diferensial, yang dapat mencakup penyimpanan snapshot di Google Cloud.
    • Pantau cadangan Anda untuk memastikan bahwa cadangan tersebut dibuat dengan benar sesuai dengan strategi pencadangan Anda. Untuk solusi perlindungan data lengkap, pertimbangkan untuk menggunakan Layanan Pencadangan dan DR Google Cloud.
    • Uji cadangan Anda secara berkala untuk memastikan cadangan 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.
    • Amankan cadangan Anda seperti halnya sistem utama, misalnya, dengan menggunakan setelan retensi penyimpanan dan kunci enkripsi.

Rekomendasi lainnya

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

Langkah selanjutnya