Gambaran umum pemulihan bencana dan pedoman infrastruktur untuk beban kerja SAP

  • Artikel

Banyak organisasi yang menjalankan aplikasi bisnis penting di Azure menyiapkan strategi Ketersediaan Tinggi (HA) dan Pemulihan Bencana (DR). Tujuan ketersediaan tinggi adalah untuk meningkatkan SLA sistem bisnis dengan menghilangkan satu titik kegagalan dalam infrastruktur sistem yang mendasar. Teknologi Ketersediaan Tinggi mengurangi efek kegagalan infrastruktur yang tidak direncanakan dan membantu pemeliharaan terencana. Pemulihan Bencana didefinisikan sebagai kebijakan, alat, dan prosedur untuk memungkinkan pemulihan atau kelanjutan infrastruktur dan sistem teknologi vital setelah bencana alam atau yang diinduksi manusia secara geografis.

Untuk mencapai ketersediaan tinggi untuk beban kerja SAP di Azure, komputer virtual biasanya disebarkan dalam set ketersediaan, zona ketersediaan, atau dalam skala fleksibel yang diatur untuk melindungi aplikasi dari pemeliharaan infrastruktur atau kegagalan dalam wilayah. Tetapi penyebaran tidak melindungi aplikasi dari bencana yang meluas di dalam wilayah. Jadi untuk melindungi aplikasi dari bencana regional, strategi pemulihan bencana untuk aplikasi harus diberlakukan. Pemulihan bencana adalah pendekatan terdokumentasi dan terstruktur yang dirancang untuk membantu organisasi dalam menjalankan proses pemulihan sebagai respons terhadap bencana, dan untuk melindungi atau meminimalkan gangguan layanan TI dan mempromosikan pemulihan.

Dokumen ini menyediakan detail tentang melindungi beban kerja SAP dari bencana skala besar dengan menerapkan pendekatan DR terstruktur. Detail dalam dokumen ini disajikan pada tingkat abstrak, berdasarkan layanan Azure dan komponen SAP yang berbeda. Strategi DR yang tepat dan urutan pemulihan untuk beban kerja SAP Anda harus diuji, didokumentasikan, dan disempurnakan secara teratur. Selain itu, dokumen berfokus pada strategi Dr Azure-ke-Azure untuk beban kerja SAP.

Pertimbangan rencana pemulihan bencana umum

Beban kerja SAP di Azure berjalan pada komputer virtual dalam kombinasi dengan layanan Azure yang berbeda untuk menyebarkan lapisan yang berbeda (layanan pusat, server aplikasi, server database) dari aplikasi SAP NetWeaver yang khas. Secara umum, strategi DR harus direncanakan untuk seluruh lanskap IT yang berjalan di Azure, yang berarti juga mempertimbangkan aplikasi non-SAP. Solusi bisnis yang berjalan dalam sistem SAP mungkin tidak berjalan secara keseluruhan, jika layanan atau aset dependen tidak dipulihkan di situs DR. Jadi Anda perlu membuat rencana DR komprehensif yang terdefinisi dengan baik dengan mempertimbangkan semua komponen dan sistem.

Untuk DR di Azure, organisasi harus mempertimbangkan skenario berbeda yang dapat memicu failover.

  • Ketersediaan aplikasi SAP atau proses bisnis.
  • Layanan Azure (seperti komputer virtual, penyimpanan, penyeimbang muatan, dll.) tidak tersedia dalam suatu wilayah karena kegagalan yang meluas.
  • Potensi ancaman dan kerentanan terhadap aplikasi (misalnya, serangan DDoS lapisan aplikasi)
  • Kepatuhan bisnis memerlukan tugas operasional untuk menguji strategi DR (misalnya, latihan kegagalan DR yang akan dilakukan setiap tahun sesuai kepatuhan).

Untuk mencapai tujuan pemulihan untuk skenario yang berbeda, organisasi harus menguraikan Tujuan Waktu Pemulihan (RTO) dan Tujuan Titik Pemulihan (RPO) untuk beban kerja mereka berdasarkan persyaratan bisnis. RTO menjelaskan jumlah aplikasi waktu dapat diturunkan, biasanya diukur dalam jam, menit, atau detik. Sedangkan RPO menjelaskan jumlah data transaksional yang dapat diterima oleh bisnis untuk hilang agar operasi normal dapat dilanjutkan. Mengidentifikasi RTO dan RPO bisnis Anda sangat penting, karena akan membantu Anda merancang strategi DR Anda secara optimal. Komponen (komputasi, penyimpanan, database, dll.) yang terlibat dalam beban kerja SAP direplikasi ke wilayah DR menggunakan teknik yang berbeda (layanan asli Azure, teknologi replikasi DB asli, skrip kustom). Setiap teknik menyediakan RPO yang berbeda, yang harus diperhitungkan saat merancang strategi DR. Di Azure, Anda dapat menggunakan beberapa layanan asli Azure seperti Azure Site Recovery, Azure Backup yang dapat membantu Anda memenuhi RTO dan RPO beban kerja SAP Anda. Lihat SLA Azure Site Recovery dan Azure Backup agar selaras secara optimal dengan RTO dan RPO Anda.

Pertimbangan desain untuk pemulihan bencana di Azure

Ada berbagai elemen yang perlu dipertimbangkan saat merancang solusi pemulihan bencana di Azure. Prinsip dan konsep yang dianggap merancang solusi pemulihan bencana lokal juga berlaku untuk Azure. Tetapi di Azure, pemilihan wilayah adalah bagian penting dalam strategi desain untuk pemulihan bencana. Jadi, ingatlah poin-poin berikut saat memilih wilayah DR di Azure.

  • Persyaratan kepatuhan bisnis atau peraturan dapat menentukan persyaratan jarak antara situs pemulihan primer dan bencana. Persyaratan jarak membantu memberikan ketersediaan jika bencana alam terjadi dalam geografi yang lebih luas. Dalam kasus seperti itu, organisasi dapat memilih wilayah Azure lain sebagai situs pemulihan bencana mereka. Wilayah Azure sering dipisahkan oleh jarak besar yang mungkin ratusan atau bahkan ribuan kilometer seperti di Amerika Serikat. Karena jaraknya, latensi pulang pergi jaringan akan lebih tinggi, yang dapat mengakibatkan RPO yang lebih tinggi.

  • Pelanggan yang ingin meniru strategi DR metro lokal mereka di Azure dapat menggunakan zona ketersediaan untuk pemulihan bencana. Tetapi strategi DR zona-ke-zona mungkin kekurangan persyaratan ketahanan jika ada bencana alam yang meluas secara geografis.

  • Di Azure, setiap wilayah dipasangkan dengan wilayah lain dalam geografi yang sama (kecuali Brasil Selatan). Pendekatan ini memungkinkan platform menyediakan replikasi sumber daya di seluruh wilayah. Manfaat memilih wilayah berpasangan dapat ditemukan dalam dokumen pasangan wilayah. Saat organisasi memilih untuk menggunakan wilayah berpasangan Azure, beberapa poin tambahan untuk beban kerja SAP perlu dipertimbangkan:

    • Tidak semua layanan Azure menawarkan replikasi lintas regional di wilayah berpasangan.

    • Layanan dan fitur Azure di wilayah Azure yang dipasangkan mungkin tidak simetris. Misalnya, Azure NetApp Files, SKU VM seperti Seri M yang tersedia di wilayah Utama mungkin tidak tersedia di wilayah yang dipasangkan. Untuk memeriksa apakah produk atau layanan Azure tersedia di suatu wilayah, lihat Produk Azure menurut Wilayah.

    • Opsi GRS tersedia untuk akun penyimpanan dengan jenis penyimpanan standar yang mereplikasi data ke wilayah yang dipasangkan. Tetapi penyimpanan standar tidak cocok untuk SAP DBMS atau disk data virtual.

    • Layanan pencadangan Azure yang digunakan untuk mencadangkan solusi yang didukung hanya dapat mereplikasi cadangan antar wilayah yang dipasangkan. Untuk semua data Anda yang lain, jalankan replikasi Anda sendiri dengan fitur DBMS asli seperti SQL Server Always On, Replikasi Sistem SAP Hana, dan layanan lainnya. Gunakan kombinasi Azure Site Recovery, rsync atau robocopy, dan perangkat lunak pihak ketiga lainnya untuk lapisan aplikasi SAP.

Mereferensikan penyebaran beban kerja SAP

Setelah mengidentifikasi wilayah DR, penting bahwa luasnya layanan inti Azure (seperti jaringan, komputasi, penyimpanan) yang telah Anda konfigurasi di wilayah utama tersedia dan dapat dikonfigurasi di wilayah DR. Organisasi harus mengembangkan pola penyebaran DR untuk beban kerja SAP. Pola penyebaran bervariasi dan harus selaras dengan kebutuhan organisasi.

  • Sebarkan beban kerja SAP produksi ke wilayah utama dan beban kerja non-produksi Anda ke wilayah pemulihan bencana.
  • Sebarkan semua beban kerja SAP (produksi dan non-produksi) ke wilayah utama Anda. Wilayah pemulihan bencana hanya digunakan jika ada failover.

Arsitektur referensi berikut menunjukkan sistem SAP NetWeaver khas yang berjalan di Azure bersama dengan ketersediaan tinggi di wilayah utama. Situs sekunder yang ditunjukkan di bawah ini adalah situs pemulihan bencana tempat sistem SAP akan dipulihkan setelah peristiwa bencana. Wilayah pemulihan primer dan bencana adalah bagian dari langganan yang sama. Untuk mencapai beban kerja DR untuk SAP, Anda perlu mengidentifikasi strategi pemulihan untuk setiap lapisan SAP bersama dengan berbagai layanan Azure yang digunakan aplikasi.

Organisasi harus merencanakan dan merancang strategi DR untuk seluruh lanskap IT mereka. Biasanya sistem SAP yang berjalan di lingkungan produksi terintegrasi dengan layanan dan antarmuka yang berbeda seperti Direktori aktif, DNS, aplikasi pihak ketiga, dan sebagainya. Jadi Anda harus menyertakan sistem non-SAP dan layanan lain dalam perencanaan pemulihan bencana Anda juga. Dokumen ini berfokus pada perencanaan pemulihan untuk aplikasi SAP. Tetapi Anda dapat memperluas ukuran dan cakupan perencanaan DR untuk komponen dependen agar sesuai dengan kebutuhan Anda.

Disaster Recovery reference architecture for SAP workload

Komponen infrastruktur solusi DR untuk beban kerja SAP

Beban kerja SAP yang berjalan di Azure menggunakan komponen infrastruktur yang berbeda untuk menjalankan solusi bisnis. Untuk merencanakan DR untuk solusi tersebut, sangat penting bahwa semua komponen infrastruktur yang dikonfigurasi di wilayah utama juga tersedia, dan dapat dikonfigurasi di wilayah DR. Komponen infrastruktur berikut harus diperhitungkan saat merancang solusi DR untuk beban kerja SAP di Azure.

  • Jaringan
  • Compute
  • Penyimpanan

Jaringan

  • ExpressRoute memperluas jaringan lokal Anda ke cloud Microsoft melalui koneksi privat dengan bantuan penyedia konektivitas. Pada merancang arsitektur pemulihan bencana, seseorang harus memperhitungkan pembangunan konektivitas jaringan backend yang kuat menggunakan sirkuit ExpressRoute geo-redundan. Disarankan untuk menyiapkan setidaknya satu sirkuit ExpressRoute dari lokal ke wilayah utama. Dan yang lain harus terhubung ke wilayah pemulihan bencana. Lihat artikel Merancang Azure ExpressRoute untuk pemulihan bencana, yang menjelaskan berbagai skenario untuk merancang pemulihan bencana untuk ExpressRoute.

    Catatan

    Pertimbangkan untuk menyiapkan VPN situs-ke-situs (S2S) sebagai cadangan Azure ExpressRoute. Untuk informasi selengkapnya, lihat Menggunakan S2S VPN sebagai cadangan untuk Azure ExpressRoute Private Peering.

  • Jaringan virtual dan subnet mencakup semua zona ketersediaan di suatu wilayah. Untuk DR di dua wilayah, Anda perlu mengonfigurasi jaringan virtual dan subnet terpisah di wilayah pemulihan bencana. Lihat Tentang jaringan di pemulihan bencana Azure VM untuk mempelajari selengkapnya tentang penyiapan jaringan di wilayah DR.

  • Azure Standard Load Balancer menyediakan elemen jaringan untuk desain ketersediaan tinggi sistem SAP Anda. Untuk sistem berkluster, Standard Load Balancer menyediakan alamat IP virtual untuk layanan kluster, seperti instans ASCS/SCS dan database yang berjalan di VM. Untuk menjalankan sistem SAP yang sangat tersedia di situs DR, load balancer terpisah harus dibuat dan konfigurasi kluster harus disesuaikan.

  • Azure Application Gateway adalah load-balancer lalu lintas web. Dengan fungsionalitas Web Application Firewall-nya, layanannya sangat cocok untuk mengekspos aplikasi web ke internet dengan keamanan yang ditingkatkan. Azure Application Gateway dapat melayani klien publik (internet) atau privat, atau keduanya, tergantung pada konfigurasinya. Setelah failover, untuk menerima lalu lintas HTTP masuk serupa di wilayah DR, Azure Application Gateway terpisah harus dikonfigurasi di wilayah DR.

  • Karena komponen jaringan (seperti jaringan virtual, firewall, dll.) dibuat secara terpisah di wilayah DR, Anda perlu memastikan bahwa beban kerja SAP di wilayah DR disesuaikan dengan perubahan jaringan seperti pembaruan DNS, firewall, dll.

  • Jaringan virtual di kedua wilayah bersifat independen dan untuk membangun komunikasi antara keduanya, Anda perlu mengaktifkan peering jaringan virtual antara kedua wilayah.

Mesin virtual

  • Di Azure, berbagai komponen sistem SAP tunggal berjalan pada komputer virtual dengan jenis SKU yang berbeda. Untuk DR, perlindungan aplikasi (SAP NetWeaver dan non-SAP) yang berjalan di Azure VM dapat diaktifkan dengan mereplikasi komponen menggunakan Azure Site Recovery ke wilayah atau zona Azure lainnya. Dengan Azure Site Recovery, Azure VM direplikasi terus menerus dari situs pemulihan primer ke bencana. Bergantung pada wilayah Azure DR yang dipilih, jenis SKU VM mungkin tidak tersedia di situs DR. Anda perlu memastikan bahwa jenis SKU VM yang diperlukan juga tersedia di Azure DRregion. Periksa Produk Azure menurut Wilayah untuk melihat apakah jenis SKU keluarga VM yang diperlukan tersedia atau tidak.

    Penting

    Jika sistem SAP dikonfigurasi dengan set skala fleksibel dengan FD=1, maka Anda perlu menggunakan PowerShell untuk menyiapkan Azure Site Recovery untuk pemulihan bencana. Saat ini, ini adalah satu-satunya metode yang tersedia untuk mengonfigurasi pemulihan bencana untuk VM yang disebarkan dalam set skala.

  • Untuk database yang berjalan di komputer virtual Azure, disarankan untuk menggunakan teknologi replikasi database asli untuk menyinkronkan data ke situs pemulihan bencana. VM besar tempat database berjalan mungkin tidak tersedia di semua wilayah. Jika Anda menggunakan zona ketersediaan untuk pemulihan bencana, Anda harus memeriksa bahwa masing-masing SKU VM tersedia di zona situs pemulihan bencana Anda.

    Catatan

    Tidak disarankan menggunakan Azure Site Recovery untuk database, karena tidak menjamin konsistensi DB dan memiliki batasan churn data.

  • Dengan aplikasi produksi yang berjalan di wilayah utama setiap saat, instans cadangan biasanya digunakan untuk menghemat biaya Azure. Jika menggunakan instans cadangan, Anda perlu mendaftar untuk komitmen jangka waktu 1 tahun atau 3 tahun yang mungkin tidak hemat biaya untuk situs DR. Juga menyiapkan Azure Site Recovery tidak menjamin kapasitas SKU VM yang diperlukan selama failover Anda. Untuk memastikan bahwa kapasitas SKU VM tersedia, Anda dapat mempertimbangkan opsi untuk mengaktifkan reservasi kapasitas sesuai permintaan. Ini mencadangkan kapasitas komputasi di wilayah Azure atau zona ketersediaan Azure selama durasi waktu apa pun tanpa komitmen. Azure Site Recovery terintegrasi dengan reservasi kapasitas sesuai permintaan. Dengan integrasi ini, Anda dapat menggunakan kekuatan reservasi kapasitas dengan Azure Site Recovery untuk memesan kapasitas komputasi di situs DR dan menjamin failover Anda. Untuk informasi selengkapnya, baca batasan dan pembatasan reservasi kapasitas sesuai permintaan.

  • Langganan Azure memiliki kuota untuk keluarga VM (misalnya, keluarga Mv2) dan sumber daya lainnya. Terkadang organisasi ingin menggunakan langganan Azure yang berbeda untuk DR. Setiap langganan (primer dan DR) mungkin memiliki kuota yang berbeda yang ditetapkan untuk setiap keluarga VM. Pastikan langganan yang digunakan untuk situs DR memiliki cukup kuota komputasi yang tersedia.

Penyimpanan

  • Pada mengaktifkan Azure Site Recovery untuk VM guna menyiapkan DR, OS dan disk data lokal yang dilampirkan ke VM direplikasi ke situs DR. Selama replikasi, VM disk tulis dikirim ke akun penyimpanan cache di wilayah sumber. Data dikirim dari sana ke wilayah target, dan titik pemulihan dihasilkan dari data. Ketika Anda melakukan failover pada VM selama DR, titik pemulihan digunakan untuk memulihkan VM di wilayah target. Tetapi Azure Site Recovery tidak mendukung semua jenis penyimpanan yang tersedia di Azure. Untuk informasi selengkapnya, lihat matriks dukungan Azure Site Recovery untuk penyimpanan.

  • Selain disk data terkelola Azure yang terpasang pada VM, solusi penyimpanan asli Azure yang berbeda digunakan untuk menjalankan aplikasi SAP di Azure. Pendekatan DR untuk setiap solusi penyimpanan Azure mungkin berbeda, karena tidak semua layanan penyimpanan yang tersedia di Azure didukung dengan Azure Site Recovery. Di bawah ini adalah daftar jenis penyimpanan yang biasanya digunakan untuk beban kerja SAP.

    Jenis penyimpanan Rekomendasi strategi DR
    Disk yang dikelola Azure Site Recovery
    NFS pada file Azure (LRS atau ZRS) Skrip kustom untuk mereplikasi data di antara dua situs (misalnya, rsync)
    NFS di Azure NetApp Files Menggunakan replikasi lintas wilayah volume Azure NetApp Files
    Disk bersama Azure (LRS atau ZRS) Solusi kustom untuk mereplikasi data di antara dua situs
    SMB pada file Azure (LRS atau ZRS) Gunakan RoboCopy untuk menyalin file di antara dua situs
    SMB di Azure NetApp Files Menggunakan replikasi lintas wilayah volume Azure NetApp Files

  • Untuk solusi penyimpanan kustom yang dibuat seperti kluster NFS, Anda perlu memastikan strategi DR yang sesuai sudah ada.

  • Layanan penyimpanan Azure asli yang berbeda (seperti Azure Files, Azure NetApp Files, Azure Shared Disk) mungkin tidak tersedia di semua wilayah. Jadi untuk memiliki pengaturan SAP serupa di wilayah DR setelah failover, pastikan layanan penyimpanan masing-masing ditawarkan di situs DR. Untuk informasi selengkapnya, periksa Produk Azure menurut Wilayah.

  • Jika menggunakan zona ketersediaan untuk pemulihan bencana, ingatlah poin-poin berikut:

    • Fitur Azure NetApp Files belum mengenali zona. Saat ini fitur Azure NetApp Files tidak digunakan di semua zona Ketersediaan di wilayah Azure. Jadi mungkin terjadi bahwa layanan Azure NetApp Files tidak tersedia di zona ketersediaan yang dipilih untuk strategi DR Anda.
    • Replikasi lintas wilayah volume Azure NetApp File hanya tersedia di pasangan wilayah tetap, bukan di seluruh zona.

  • Jika Anda telah mengonfigurasi penyimpanan dengan integrasi Direktori Aktif, penyiapan serupa juga harus dilakukan pada akun penyimpanan situs DR.

  • Disk bersama Azure memerlukan perangkat lunak kluster seperti Windows Server Failover Cluster (WSFC) yang menangani komunikasi node kluster dan penguncian tulis. Jadi untuk memiliki strategi DR untuk disk bersama Azure, Anda harus memiliki disk bersama yang dikelola oleh perangkat lunak kluster di situs DR juga. Anda kemudian dapat menggunakan skrip untuk menyalin data dari disk bersama yang dilampirkan ke kluster di wilayah utama ke disk bersama yang dilampirkan ke kluster lain di wilayah DR.

Langkah berikutnya