Beban kerja SAP pada skenario yang didukung komputer virtual Azure

  • Artikel

Merancang arsitektur sistem SAP NetWeaver, Business one, Hybris atau S/4HANA di Azure membuka berbagai peluang berbeda untuk berbagai arsitektur dan alat yang akan digunakan untuk mencapai penyebaran yang dapat diskalakan, efisien, dan sangat tersedia. Meskipun tergantung pada sistem operasi atau DBMS yang digunakan, pembatasan tetap ada. Selain itu, tidak semua skenario yang didukung secara lokal didukung dengan cara yang sama di Azure. Dokumen ini akan memandu konfigurasi non-ketersediaan tinggi yang didukung dan konfigurasi serta arsitektur ketersediaan tinggi menggunakan komputer virtual Azure secara eksklusif.

Catatan

Layanan Instans Besar HANA dalam mode matahari terbenam dan tidak menerima pelanggan baru lagi. Menyediakan unit untuk pelanggan Instans Besar HANA yang ada masih dimungkinkan. Untuk alternatif, periksa penawaran Azure VM bersertifikat HANA di Direktori Perangkat Keras HANA. Untuk skenario yang dan masih didukung untuk pelanggan Instans Besar HANA yang ada dengan Instans Besar HANA, periksa artikel Skenario yang didukung untuk Instans Besar HANA.

Pembatasan platform umum

Azure memiliki berbagai platform selain itu disebut Azure VM asli yang ditawarkan sebagai layanan pihak pertama. Instans Besar HANA, yang dalam mode matahari terbenam adalah salah satu platform tersebut. Azure VMware Services adalah layanan pihak pertama lainnya. Azure VMware Services secara umum tidak didukung oleh SAP untuk menghosting beban kerja SAP. Lihat catatan dukungan SAP #2138865 - Aplikasi SAP di VMware Cloud: Produk yang Didukung dan konfigurasi VM untuk detail selengkapnya tentang dukungan VMware pada platform yang berbeda.

Selain Active Directory lokal, Azure menawarkan layanan SaaS Direktori Aktif terkelola dengan Microsoft Entra Domain Services (AD tradisional yang dikelola oleh Microsoft), dan ID Microsoft Entra. Komponen SAP yang dihosting di OS Windows sering mengandalkan penggunaan Windows Active Directory. Dalam hal ini Active Directory tradisional karena dihosting secara lokal oleh Anda, atau Microsoft Entra Domain Services (masih dalam pengujian). Tetapi komponen SAP ini tidak dapat berfungsi dengan ID Microsoft Entra asli. Alasannya adalah bahwa masih ada celah yang lebih besar dalam fungsionalitas antara Direktori Aktif dalam bentuk lokalnya atau bentuk SaaS-nya (Microsoft Entra Domain Services) dan ID Microsoft Entra asli. Dependensi ini adalah alasan mengapa akun Microsoft Entra tidak didukung untuk aplikasi berdasarkan SAP NetWeaver dan S/4 HANA di OS Windows. Akun Active Directory tradisional perlu digunakan dalam skenario seperti itu.

Layanan AD Aplikasi yang didukung berdasarkan SAP NetWeaver dan S/4 HANA pada OS Windows
Windows Active Directory lokal Didukung
Microsoft Entra Domain Services Didukung
Microsoft Entra ID Tidak didukung

Hal di atas tidak memengaruhi penggunaan akun Microsoft Entra untuk skenario akses menyeluruh (SSO) dengan aplikasi SAP.

Konfigurasi 2 Tingkat

Konfigurasi SAP 2 Tingkat dianggap dibangun dari lapisan gabungan DBMS SAP dan lapisan aplikasi yang berjalan pada server atau unit komputer virtual yang sama. Tingkat kedua dianggap sebagai lapisan antarmuka pengguna. Untuk konfigurasi 2 Tingkat, lapisan aplikasi DBMS, dan SAP berbagi sumber daya Azure VM. Akibatnya, Anda perlu mengonfigurasi komponen yang berbeda dengan cara yang tidak melibatkan sumber daya. Anda juga harus berhati-hati untuk tidak terlalu banyak berlangganan sumber daya komputer virtual. Konfigurasi semacam itu tidak memberikan ketersediaan tinggi, di luar perjanjian Tingkat Layanan Azure dari berbagai komponen Azure yang terlibat.

Representasi grafis dari konfigurasi semacam itu dapat terlihat seperti:

Simple 2-Tier configuration

Konfigurasi tersebut didukung pada Windows, Red Hat, SUSE, dan Oracle Linux untuk sistem DBMS dari SQL Server, Oracle, Db2, maxDB, dan SAP ASE untuk kasus produksi dan non-produksi. Untuk SAP Hana sebagai DBMS, SAP mendukung skenario seperti yang dinyatakan dalam catatan SAP #1953429. Sejauh ini, tidak ada distro Linux yang menyediakan dokumentasi HA yang memadai untuk menyiapkan dan mengoperasikan kluster Pacemaker dalam konfigurasi seperti itu. Akibatnya, jenis konfigurasi tersebut didukung di Azure hanya untuk kasus non-produksi yang tidak memerlukan kluster failover ketersediaan tinggi.

Untuk semua kombinasi OS/DBMS yang didukung di Azure, jenis konfigurasi ini didukung. Namun, Anda wajib mengatur konfigurasi DBMS dan komponen SAP dengan cara komponen DBMS dan SAP tidak bersaing untuk memori dan sumber daya CPU dan dengan itu melebihi sumber daya fisik yang tersedia. Ini perlu dilakukan dengan membatasi memori yang diizinkan untuk dialokasikan oleh DBMS. Anda juga perlu membatasi SAP Extended Memory pada instans aplikasi. Anda juga perlu memantau konsumsi CPU VM secara keseluruhan untuk memastikan bahwa komponen tidak memaksimalkan sumber daya CPU.

Catatan

Untuk sistem SAP produksi, kami merekomendasikan ketersediaan tinggi tambahan dan konfigurasi pemulihan bencana akhir seperti yang dijelaskan nanti dalam dokumen ini

Konfigurasi 3 Tingkat

Dalam konfigurasi tersebut, Anda memisahkan lapisan aplikasi SAP dan lapisan DBMS ke dalam komputer virtual yang berbeda. Anda biasanya melakukannya untuk sistem yang lebih besar dan karena alasan fleksibilitas pada sumber daya lapisan aplikasi SAP. Dalam penyiapan yang paling sederhana, Tidak ada ketersediaan tinggi di luar perjanjian Tingkat Layanan Azure dari berbagai komponen Azure yang terlibat.

Representasi grafis terlihat seperti:

Diagram that shows a simple 3-Tier configuration.

Jenis konfigurasi ini didukung di Windows, Red Hat, SUSE, dan Oracle Linux untuk sistem DBMS dari SQL Server, Oracle, Db2, SAP Hana, maxDB, dan SAP ASE untuk kasus produksi dan non-produksi. Untuk penyederhanaan, kami tidak membedakan antara SAP Central Services dan instans dialog SAP di lapisan aplikasi SAP. Dalam konfigurasi 3 Tingkat sederhana ini, tidak akan ada perlindungan ketersediaan tinggi untuk Layanan Pusat SAP.

Catatan

Untuk sistem SAP produksi, kami merekomendasikan ketersediaan tinggi tambahan dan konfigurasi pemulihan bencana akhir seperti yang dijelaskan nanti dalam dokumen ini

Beberapa instans DBMS per VM

Dalam jenis konfigurasi ini, Anda menghosting beberapa instans DBMS per Azure VM. Motivasinya adalah memiliki lebih sedikit sistem operasi untuk dipertahankan dan dengan biaya yang berkurang. Motivasi lainnya adalah memiliki lebih banyak fleksibilitas dan efisiensi dengan berbagi sumber daya unit VM atau Instans Besar HANA yang lebih besar di antara beberapa instans DBMS. Sejauh ini, konfigurasi ini muncul sebagian besar untuk sistem non-produksi.

Konfigurasi seperti itu bisa terlihat seperti:

Multiple DBMS instances in one unit

Jenis penyebaran DBMS ini didukung untuk:

Menjalankan beberapa instans database pada satu host, Anda perlu memastikan bahwa instans yang berbeda tidak bersaing untuk sumber daya dan dengan demikian melebihi batas sumber daya fisik VM. Hal ini terutama berlaku untuk memori tempat Anda perlu menutup memori siapa pun dari instans yang dapat dialokasikan oleh komputer virtual berbagi. Itu mungkin juga berlaku untuk sumber daya CPU yang dapat digunakan oleh instans database yang berbeda. Semua sistem database yang disebutkan memiliki konfigurasi yang memungkinkan pembatasan alokasi memori dan sumber daya CPU pada tingkat instans. Untuk memiliki dukungan untuk konfigurasi seperti itu untuk Azure VM, diharapkan disk atau volume yang digunakan untuk data dan file log log log/pengulangan database yang dikelola oleh instans yang berbeda terpisah. Atau dengan kata lain data atau file log log log yang dikelola oleh instans DBMS yang berbeda tidak seharusnya berbagi disk atau volume yang sama.

Catatan

Untuk sistem SAP produksi, kami merekomendasikan ketersediaan tinggi tambahan dan konfigurasi pemulihan bencana akhir seperti yang dijelaskan nanti dalam dokumen ini. VM dengan beberapa instans DBMS tidak didukung dengan konfigurasi ketersediaan tinggi yang dijelaskan nanti dalam dokumen ini.

Beberapa instans Dialog SAP dalam satu komputer virtual

Dalam berbagai kasus, beberapa instans dialog disebarkan di server bare metal atau bahkan di komputer virtual yang berjalan di cloud privat. Alasan untuk konfigurasi tersebut adalah untuk menyesuaikan instans dialog SAP tertentu dengan beban kerja, fungsionalitas bisnis, atau jenis beban kerja tertentu. Alasan untuk tidak mengisolasi instans tersebut ke dalam komputer virtual terpisah adalah upaya pemeliharaan dan operasi sistem operasi. Atau dalam banyak kasus biaya jika hoster atau operator komputer virtual meminta biaya bulanan per komputer virtual yang dioperasikan dan yang dikelola. Di Azure, skenario hosting beberapa instans dialog SAP dalam satu komputer virtual didukung untuk tujuan produksi dan non-produksi pada sistem operasi Windows, Red Hat, SUSE, dan Oracle Linux. Parameter kernel SAP PHYS_MEMSIZE, tersedia di kernel Windows dan Linux modern, harus diatur jika beberapa instans SAP Application Server berjalan pada satu VM. disarankan juga untuk membatasi perluasan SAP Extended Memory pada sistem operasi, seperti Windows di mana pertumbuhan otomatis Memori yang diperluas SAP diterapkan. Ini dapat dilakukan dengan parameter profil SAP em/max_size_MB.

Pada konfigurasi 3 Tingkat ketika beberapa instans dialog SAP dijalankan dalam komputer virtual Azure dapat terlihat seperti:

Diagram that shows a 3-Tier configuration where multiple SAP dialog instances are run within Azure VMs.

Untuk penyederhanaan, kami tidak membedakan antara SAP Central Services dan instans dialog SAP di lapisan aplikasi SAP. Dalam konfigurasi 3 Tingkat sederhana ini, tidak akan ada perlindungan ketersediaan tinggi untuk Layanan Pusat SAP. Untuk sistem produksi, tidak disarankan untuk membiarkan Layanan Pusat SAP tidak terlindungi. Untuk detail tentang konfigurasi multi-SID yang disebutkan di sekitar Instans Pusat SAP dan ketersediaan tinggi konfigurasi multi-SID tersebut, lihat bagian selanjutnya dari dokumen ini.

Perlindungan Ketersediaan Tinggi untuk lapisan DBMS SAP

Ketika Anda ingin menyebarkan sistem produksi SAP, Anda perlu mempertimbangkan jenis siaga aktif dari konfigurasi ketersediaan tinggi. Terutama dengan SAP Hana, di mana data perlu dimuat ke dalam memori sebelum dapat mendapatkan performa penuh dan skalabilitas kembali, penyembuhan layanan Azure bukanlah ukuran yang ideal untuk ketersediaan tinggi.

Secara umum, Microsoft hanya mendukung konfigurasi ketersediaan tinggi dan paket perangkat lunak yang dijelaskan skenario beban kerja SAP. Anda dapat membaca pernyataan yang sama dalam catatan SAP #1928533. Microsoft tidak akan memberikan dukungan untuk kerangka kerja perangkat lunak pihak ketiga ketersediaan tinggi lainnya yang tidak didokumenkan oleh Microsoft dengan beban kerja SAP. Dalam kasus seperti itu, pemasok pihak ketiga untuk kerangka kerja dengan ketersediaan tinggi adalah pihak pendukung untuk konfigurasi ketersediaan tinggi yang perlu dilibatkan oleh Anda sebagai pelanggan ke dalam proses dukungan. Pengecualian akan disebutkan dalam artikel ini.

Secara umum, Microsoft mendukung serangkaian konfigurasi ketersediaan tinggi terbatas pada azure VM atau unit Instans Besar HANA.

Untuk komputer virtual Azure, konfigurasi ketersediaan tinggi berikut ini didukung pada tingkat DBMS:

Penting

Jika tidak ada dalam skenario yang dijelaskan di atas, kami mendukung konfigurasi beberapa instans DBMS dalam satu komputer virtual. Berarti dalam setiap kasus, hanya satu instans database yang dapat digunakan per komputer virtual dan dilindungi dengan metode ketersediaan tinggi yang dijelaskan. Melindungi beberapa instans DBMS di bawah kluster failover Windows atau Pacemaker yang sama saat ini TIDAK didukung. Oracle Data Guard juga didukung hanya untuk instans tunggal per kasus penyebaran komputer virtual.

Berbagai sistem database memungkinkan untuk hosting beberapa database di bawah satu instans DBMS. Seperti halnya SAP Hana, beberapa database dapat dihosting dalam beberapa kontainer database (MDC). Untuk kasus ketika konfigurasi multi-database ini bekerja dalam satu sumber daya kluster failover, konfigurasi ini didukung. Konfigurasi yang tidak didukung adalah kasus di mana beberapa sumber daya kluster akan diperlukan. Seperti konfigurasi ketika Anda akan menentukan beberapa Grup Ketersediaan SQL Server, di bawah satu instans SQL Server.

DBMS HA configuration

Tergantung pada DBMS dan/atau sistem operasi, komponen seperti penyeimbang muatan Azure mungkin atau mungkin tidak diperlukan sebagai bagian dari arsitektur solusi.

Khusus untuk maxDB, konfigurasi penyimpanannya harus berbeda. Dengan maxDB, data dan file log harus terletak di penyimpanan bersama untuk konfigurasi ketersediaan tinggi. Hanya untuk maxDB, penyimpanan bersama didukung untuk ketersediaan tinggi. Untuk semua tumpukan penyimpanan terpisah DBMS lain per node adalah satu-satunya konfigurasi disk yang didukung.

Kerangka kerja ketersediaan tinggi lainnya diketahui ada dan juga diketahui berjalan di Microsoft Azure. Namun, Microsoft tidak menguji kerangka kerja tersebut. Jika Anda ingin membangun konfigurasi ketersediaan tinggi dengan kerangka kerja tersebut, Anda perlu bekerja sama dengan penyedia perangkat lunak tersebut untuk:

  • Mengembangkan arsitektur penyebaran
  • Penyebaran arsitektur
  • Dukungan arsitektur

Penting

Microsoft Azure Marketplace menawarkan berbagai appliance lunak yang menyediakan solusi penyimpanan di atas penyimpanan asli Azure. Appliance lunak ini juga dapat digunakan untuk membuat berbagi NFS yang secara teoritis dapat digunakan dalam penyebaran perluasan skala SAP Hana ketika node siaga diperlukan. Karena berbagai alasan, appliance lunak penyimpanan ini tidak didukung untuk salah satu penyebaran DBMS oleh Microsoft dan SAP di Azure. Penyebaran DBMS pada berbagi SMB tidak didukung sama sekali pada saat ini. Penyebaran DBMS di berbagi NFS terbatas pada berbagi NFS 4.1 pada Azure NetApp Files.

Ketersediaan Tinggi untuk Layanan Pusat SAP

Layanan Pusat SAP adalah titik kegagalan tunggal kedua konfigurasi SAP Anda. Akibatnya, Anda juga harus melindungi proses Layanan Pusat ini. Penawaran yang didukung dan didokumentasikan untuk beban kerja SAP berbunyi seperti:

Dari solusi yang tercantum, Anda memerlukan hubungan dukungan dengan SIOS untuk mendukung Datakeeper produk dan terlibat dengan SIOS secara langsung jika masalah dihadapi. Tergantung pada cara Anda melisensikan OS Windows, Red Hat, dan/atau SUSE, Anda juga dapat diminta untuk memiliki kontrak dukungan dengan penyedia OS Anda untuk memiliki dukungan penuh dari konfigurasi ketersediaan tinggi yang terdaftar.

Konfigurasi juga dapat ditampilkan seperti:

DBMS and ASCS HA configuration

Di sebelah kanan grafik, Layanan Pusat SAP yang sangat tersedia ditampilkan. Selain memiliki layanan SAP Central yang dilindungi dengan kerangka kerja kluster failover yang dapat gagal dalam skenario kegagalan. Ada kebutuhan untuk berbagi NFS atau SMB yang sangat tersedia, atau disk bersama Windows untuk memastikan direktori transportasi sapmnt dan global tersedia terlepas dari keberadaan satu VM. Beberapa solusi tambahan, seperti Windows Failover Cluster Server dan Pacemaker akan memerlukan load balancer Azure untuk mengarahkan atau mengalihkan lalu lintas ke simpul yang sehat.

Dalam daftar yang ditampilkan, Tidak ada yang menyebutkan sistem operasi Oracle Linux. Oracle Linux tidak mendukung Pacemaker sebagai kerangka kerja kluster. Jika Anda ingin menyebarkan sistem SAP Anda di Oracle Linux dan Anda memerlukan kerangka kerja ketersediaan tinggi untuk Oracle Linux, Anda harus bekerja dengan pemasok pihak ketiga. Salah satu pemasok adalah SIOS dengan Protection Suite for Linux mereka yang didukung oleh SAP di Azure. Untuk informasi selengkapnya, baca catatan SAP #1662610 - Detail dukungan untuk SIOS Protection Suite for Linux untuk detail selengkapnya.

Penyimpanan yang didukung dengan skenario Layanan Pusat SAP yang tercantum di atas

Karena hanya subnet jenis penyimpanan Azure yang menyediakan berbagi NFS atau SMB yang sangat tersedia sehingga kualitas untuk penggunaan di kluster Layanan Pusat SAP kami menguraikan daftar jenis penyimpanan yang didukung

  • Server Kluster Failover Windows dengan Server File Perluasan Skala Windows dapat disebarkan di semua jenis penyimpanan Azure asli, kecuali Azure NetApp Files. Namun, rekomendasinya adalah menggunakan Penyimpanan Premium karena perjanjian tingkat layanan unggul dalam throughput dan IOPS.
  • Server Kluster Failover Windows dengan SMB pada File Azure NetApp didukung pada Azure NetApp Files. Berbagi SMB yang dihosting di layanan Azure Premium File juga didukung untuk skenario ini. Azure Standard Files tidak didukung
  • Server Kluster Failover Windows dengan disk bersama windows berdasarkan SIOS Datakeeper dapat disebarkan di semua jenis penyimpanan Azure asli, kecuali Azure NetApp Files. Namun, rekomendasinya adalah menggunakan Penyimpanan Premium karena perjanjian tingkat layanan unggul dalam throughput dan IOPS.
  • SUSE atau Red Hat Pacemaker yang menggunakan berbagi NFS di Azure NetApp Files didukung.
  • SUSE atau Red Hat Pacemaker menggunakan berbagi NFS di Azure Premium Files menggunakan LRS atau ZRS s yang didukung. Azure Standard Files tidak didukung
  • SUSE Pacemaker yang menggunakan konfigurasi drdb antara dua komputer virtual didukung menggunakan jenis penyimpanan Azure asli, kecuali Azure NetApp Files. Namun, sebaiknya gunakan salah satu layanan pihak pertama dengan Azure Premium Files atau Azure NetApp Files.
  • Red Hat Pacemaker yang menggunakan glusterfs untuk menyediakan berbagi NFS didukung menggunakan jenis penyimpanan Azure asli, kecuali Azure NetApp Files. Namun, sebaiknya gunakan salah satu layanan pihak pertama dengan Azure Premium Files atau Azure NetApp Files.

Penting

Microsoft Azure Marketplace menawarkan berbagai appliance lunak yang menyediakan solusi penyimpanan di atas penyimpanan asli Azure. Appliance lunak penyimpanan ini dapat digunakan untuk membuat berbagi NFS atau SMB juga yang secara teoritis dapat digunakan dalam Layanan Pusat SAP terkluster failover juga. Solusi ini tidak didukung secara langsung untuk beban kerja SAP oleh Microsoft. Jika Anda memutuskan untuk menggunakan solusi seperti itu untuk membuat berbagi NFS atau SMB Anda, dukungan untuk konfigurasi Layanan Pusat SAP perlu disediakan oleh pihak ketiga yang memiliki perangkat lunak di appliance lunak penyimpanan.

Kluster failover Layanan Pusat SAP Multi-SID

Untuk mengurangi jumlah komputer virtual yang diperlukan dalam lanskap SAP yang besar, SAP memungkinkan untuk menjalankan instans Layanan Pusat SAP dari beberapa sistem SAP yang berbeda dalam konfigurasi kluster failover. Bayangkan kasus di mana Anda memiliki 30 atau lebih sistem produksi NetWeaver atau S/4HANA. Tanpa pengklusteran multi-SID, konfigurasi ini akan memerlukan 60 komputer virtual atau lebih dalam 30 atau lebih konfigurasi kluster failover Windows atau Pacemaker. Menyebarkan beberapa layanan pusat SAP di dua node dalam konfigurasi kluster failover dapat mengurangi jumlah komputer virtual secara signifikan. Namun, menyebarkan beberapa instans layanan Pusat SAP pada dua konfigurasi klaster node tunggal juga memiliki beberapa kelemahan. Masalah seputar komputer virtual tunggal dalam konfigurasi kluster berlaku untuk beberapa sistem SAP. Pemeliharaan pada OS tamu yang berjalan dalam konfigurasi kluster memerlukan lebih banyak koordinasi karena beberapa sistem SAP produksi terpengaruh. Alat seperti SAP LaMa tidak mendukung pengklusteran multi-SID dalam proses kloning sistem mereka.

Di Azure, konfigurasi kluster multi-SID didukung untuk sistem operasi Windows dengan ENSA1 dan ENSA2. Rekomendasi bukan untuk menggabungkan arsitektur Enqueue Replication Service (ENSA1) yang lebih lama dengan arsitektur baru (ENSA2) pada satu kluster multi-SID. Detail tentang arsitektur tersebut didokumentasikan dalam artikel

Untuk SUSE, kluster multi-SID berdasarkan Pacemaker juga didukung. Sejauh ini konfigurasi didukung untuk:

  • Maksimal lima instans SAP ASCS/SCS
  • Arsitektur enqueue replication server ice architecture (ENSA1) lama
  • Dua konfigurasi kluster Pacemaker node

Konfigurasi didokumentasikan dalam panduan Ketersediaan tinggi untuk SAP NetWeaver pada komputer virtual Azure di SUSE Linux Enterprise Server untuk aplikasi SAP multi-SID

Kluster multi-SID dengan server Enqueue Replication secara skematis terlihat seperti

Diagram that shows a multi-SID cluster with Enqueue Replication server.

Skenario perluasan skala SAP Hana

Skenario perluasan skala SAP Hana didukung untuk subset komputer virtual Azure bersertifikat HANA seperti yang tercantum dalam direktori perangkat keras SAP Hana. Semua komputer virtual yang ditandai dengan 'Yes' di kolom 'Clustering' dapat digunakan untuk perluasan skala OLAP atau S/4HANA. Konfigurasi tanpa siaga didukung pada jenis Azure Storage:

Konfigurasi perluasan skala SAP Hana untuk OLAP atau S/4HANA dengan node siaga didukung secara eksklusif dengan berbagi NFS yang dihost di Azure NetApp Files.

Untuk informasi selengkapnya tentang konfigurasi penyimpanan yang tepat dengan atau tanpa node siaga, periksa artikel:

Skenario Pemulihan Bencana

Ada berbagai skenario pemulihan bencana yang didukung. Kita mendefinisikan arsitektur Bencana sebagai arsitektur, yang harus mengimbangi wilayah Azure lengkap yang keluar dari kisi. Artinya kita memerlukan target pemulihan bencana untuk menjadi wilayah Azure yang berbeda sebagai target untuk menjalankan lanskap SAP Anda. Kita memisahkan metode dan konfigurasi dalam lapisan DBMS dan lapisan non-DBMS.

Lapisan DBMS

Untuk lapisan DBMS, konfigurasi yang menggunakan mekanisme replikasi asli DBMS, seperti Always On, Oracle Data Guard, Db2 HADR, SAP ASE Always-On, atau HANA System Replication didukung. adalah wajib bahwa aliran replikasi dalam kasus seperti itu tidak sinkron, alih-alih sinkron seperti dalam skenario ketersediaan tinggi umum yang disebarkan dalam satu wilayah Azure. Contoh umum konfigurasi pemulihan bencana DBMS yang didukung seperti itu dijelaskan dalam artikel ketersediaan SAP Hana di seluruh wilayah Azure. Grafik kedua dalam bagian tersebut menjelaskan skenario dengan HANA sebagai contoh. Database utama yang didukung untuk aplikasi SAP semuanya dapat disebarkan dalam skenario tersebut.

didukung untuk menggunakan VM yang lebih kecil sebagai instans target di wilayah pemulihan bencana karena VM tidak mengalami lalu lintas beban kerja penuh. Dengan demikian, Anda perlu mengingat pertimbangan berikut:

  • Jenis VM yang lebih kecil tidak memungkinkan banyak disk yang terpasang daripada VM yang lebih kecil
  • Komputer virtual yang lebih kecil memiliki lebih sedikit throughput jaringan dan penyimpanan
  • Mengubah ukuran di seluruh keluarga VM dapat menjadi masalah ketika VM yang berbeda dikumpulkan dalam satu Set Ketersediaan Azure atau ketika pengubahan ukuran harus terjadi antara keluarga M-Series dan keluarga VM Mv2
  • Konsumsi CPU dan memori untuk instans database yang dapat menerima aliran perubahan dengan penundaan minimal dan sumber daya CPU serta memori yang cukup untuk menerapkan perubahan ini dengan penundaan minimal pada data

Detail lebih banyak tentang pembatasan ukuran VM yang berbeda dapat ditemukan di halaman ukuran VM

Metode lain yang didukung untuk menyebarkan target DR adalah menginstal instans DBMS kedua pada komputer virtual yang menjalankan instans DBMS non-produksi dari instans SAP non-produksi. Metode ini bisa sedikit lebih menantang karena Anda perlu mencari tahu apa yang diperlukan di memori, sumber daya CPU, bandwidth jaringan, dan bandwidth penyimpanan untuk instans target tertentu yang harus berfungsi sebagai instans utama dalam skenario DR. Terutama di HANA sangat disarankan agar Anda mengonfigurasi instans yang berfungsi sebagai target DR pada host bersama sehingga data tidak dimuat sebelumnya ke dalam instans target DR.

Catatan

Penggunaan Azure Site Recovery belum diuji untuk penyebaran DBMS di bawah beban kerja SAP. Akibatnya tidak didukung untuk lapisan DBMS sistem SAP pada saat ini. Metode replikasi lain oleh Microsoft dan SAP yang tidak tercantum tidak didukung. Menggunakan perangkat lunak pihak ketiga untuk mereplikasi lapisan DBMS sistem SAP di antara Wilayah Azure yang berbeda, perlu didukung oleh vendor perangkat lunak dan tidak akan didukung melalui saluran dukungan Microsoft dan SAP.

Lapisan non-DBMS

Untuk lapisan aplikasi SAP dan pembagian akhir atau lokasi penyimpanan yang diperlukan, dua skenario utama digunakan oleh pelanggan:

  • Target pemulihan bencana di wilayah Azure kedua tidak digunakan untuk tujuan produksi atau non-produksi apa pun. Dalam skenario ini, komputer virtual yang berfungsi sebagai target pemulihan bencana idealnya tidak disebarkan dan gambar serta perubahan pada gambar lapisan aplikasi SAP produksi direplikasi ke wilayah pemulihan bencana. Fungsionalitas yang dapat melakukan tugas seperti itu adalah Azure Site Recovery. Azure Site Recovery mendukung skenario replikasi Azure ke Azure seperti ini.
  • Target pemulihan bencana adalah komputer virtual yang benar-benar digunakan oleh sistem non-produksi. Seluruh lanskap SAP disebar di dua wilayah Azure yang berbeda dengan sistem produksi biasanya di satu wilayah dan sistem non-produksi di wilayah lain. Dalam berbagai penyebaran pelanggan, pelanggan memiliki sistem non-produksi yang setara dengan sistem produksi. Pelanggan memiliki instans aplikasi produksi yang sudah diinstal sebelumnya pada sistem non-produksi lapisan aplikasi. Dalam peristiwa failover, instans non-produksi akan dimatikan, nama virtual VM produksi dipindahkan ke VM non-produksi (setelah menetapkan alamat IP baru di DNS), dan instans produksi yang telah diinstal sebelumnya memulai

Klaster Layanan Pusat SAP

Kluster Layanan Pusat SAP yang menggunakan disk bersama (Windows), berbagi SMB (Windows), atau berbagi NFS sedikit lebih sulit untuk direplikasi. Di sisi Windows, Windows Storage Replication adalah solusi yang mungkin. Di Linux, rsync adalah solusi yang layak. Juga replikasi lintas wilayah Azure NetApp Files adalah solusi yang layak.

Skenario yang tidak didukung

Ada daftar skenario, yang tidak didukung untuk beban kerja SAP pada arsitektur Azure. Tidak didukung berarti SAP dan Microsoft tidak dapat memberikan dukungan untuk konfigurasi ini dan perlu menunggak pihak ketiga yang terlibat akhirnya yang menyediakan perangkat lunak untuk membuat arsitektur tersebut. Dua dari kategori tersebut adalah:

  • Peralatan lunak penyimpanan: Ada berbagai peralatan lunak penyimpanan di pasar. Beberapa vendor menawarkan dokumentasi sendiri tentang cara menggunakan peralatan lunak penyimpanan mereka di Azure yang terkait dengan perangkat lunak SAP. Dukungan konfigurasi atau penyebaran yang melibatkan peralatan lunak penyimpanan tersebut perlu disediakan oleh vendor appliance lunak penyimpanan. Fakta ini juga dijelaskan dalam catatan dukungan SAP #2015553
  • Kerangka kerja Ketersediaan Tinggi: Hanya Pacemaker dan Windows Server Failover Cluster yang didukung kerangka kerja ketersediaan tinggi untuk beban kerja SAP di Azure. Seperti disebutkan sebelumnya, solusi SIOS Datakeeper dijelaskan dan didokumentasikan oleh Microsoft. Namun demikian, komponen SIOS Datakeeper perlu didukung melalui SIOS sebagai vendor yang menyediakan komponen tersebut. SAP juga mencantumkan kerangka kerja ketersediaan tinggi tersertifikasi lainnya dalam berbagai catatan SAP. Beberapa kerangka kerja tersebut juga disertifikasi oleh vendor pihak ketiga untuk Azure. Namun demikian, dukungan untuk konfigurasi yang menggunakan produk tersebut perlu disediakan oleh vendor produk. Vendor yang berbeda memiliki integrasi yang berbeda ke dalam proses dukungan SAP. Anda harus mengklarifikasi proses dukungan apa yang paling sesuai untuk vendor tertentu sebelum memutuskan untuk menggunakan produk dengan konfigurasi SAP yang disebarkan di Azure.
  • Kluster disk bersama tempat file database berada di disk bersama tidak didukung, kecuali untuk maxDB. Untuk semua database lainnya, solusi yang didukung adalah memiliki lokasi penyimpanan terpisah bukan berbagi SMB atau NFS atau pun disk bersama untuk mengonfigurasi skenario ketersediaan tinggi

Skenario lain, yang tidak didukung adalah skenario seperti:

  • Skenario penyebaran yang memperkenalkan latensi jaringan yang lebih besar antara tingkat aplikasi SAP dan tingkat SAP DBMS seperti di NetWeaver, S/4HANA dan misalnya Hybris. Ini termasuk:
    • Menyebarkan salah satu tingkat secara lokal, sementara tingkat lainnya disebarkan di Azure
    • Menyebarkan tingkat aplikasi SAP dari sistem di wilayah Azure yang berbeda dari tingkat DBMS
    • Menyebarkan satu tingkat di pusat data yang terletak bersama ke Azure dan tingkat lainnya di Azure, kecuali jika pola arsitektur tersebut disediakan oleh layanan asli Azure
    • Menyebarkan appliance virtual jaringan antara tingkat aplikasi SAP dan lapisan DBMS
    • Menggunakan penyimpanan yang dihosting di pusat data yang terletak bersama ke pusat data Azure untuk tingkat SAP DBMS atau direktori transportasi global SAP
    • Menyebarkan dua lapisan dengan dua vendor cloud yang berbeda. Misalnya, menyebarkan tingkat DBMS di Oracle Cloud Infrastructure dan tingkat aplikasi di Azure
  • Konfigurasi kluster Pacemaker HANA Multi-Instans
  • Konfigurasi Kluster Windows dengan disk bersama melalui SOFS atau SMB pada ANF untuk database SAP yang didukung pada Windows. Sebagai gantinya, kami merekomendasikan penggunaan replikasi ketersediaan asli dari database tertentu dan menggunakan tumpukan penyimpanan terpisah
  • Penyebaran database SAP yang didukung di Linux dengan file database yang terletak di berbagi NFS di atas ANF kecuali untuk SAP Hana, Oracle di Oracle Linux, dan Db2 di Suse dan Red Hat
  • Penyebaran Oracle DBMS pada OS tamu lain selain Windows dan Oracle Linux. Lihat juga catatan dukungan SAP #2039619

Skenario yang tidak kami uji dan oleh karena itu tidak memiliki pengalaman dengan daftar seperti:

  • Azure Site Recovery yang mereplikasi komputer virtual lapisan DBMS. Akibatnya, sebaiknya gunakan fungsionalitas replikasi asinkron asli database untuk potensi konfigurasi pemulihan bencana

Langkah berikutnya

Baca langkah-langkah berikutnya dalam perencanaan dan implementasi Azure Virtual Machines untuk SAP NetWeaver