Bagikan melalui

Pertimbangan untuk penyebaran Azure Virtual Machines DBMS untuk beban kerja SAP

  • Artikel

Panduan ini merupakan bagian dari dokumentasi tentang cara menerapkan dan menyebarkan perangkat lunak SAP di Microsoft Azure. Sebelum Anda membaca panduan ini, baca Panduan perencanaan dan implementasi serta artikel yang ditunjukkan panduan perencanaan. Dokumen ini mencakup aspek penyebaran generik sistem DBMS terkait SAP pada komputer virtual (VM) Microsoft Azure dengan menggunakan kemampuan infrastruktur sebagai layanan (IaaS) Azure.

Makalah ini melengkapi dokumentasi penginstalan SAP dan Catatan SAP, yang mewakili sumber daya utama untuk penginstalan dan penyebaran perangkat lunak SAP pada platform tertentu.

Dalam dokumen ini, pertimbangan untuk menjalankan sistem DBMS terkait SAP di Azure VM diperkenalkan. Ada beberapa referensi untuk sistem DBMS tertentu dalam dokumen ini. Sebaliknya, sistem DBMS tertentu ditangani dalam dokumen khusus sistem database lainnya.

Sumber

Ada artikel lain yang tersedia tentang beban kerja SAP di Microsoft Azure. Mulai dengan Beban kerja SAP di Microsoft Azure: Mulai lalu pilih area minat.

Catatan SAP berikut ini terkait dengan SAP di Microsoft Azure sehubungan dengan area yang tercakup dalam dokumen ini.

Nomor catatan Judul
1928533 Aplikasi SAP di Azure: Jenis produk dan Azure VM yang didukung
2015553 SAP di Microsoft Azure: Prasyarat dukungan
1999351 Pemecahan masalah meningkatkan pemantauan Azure untuk SAP
2178632 Metrik pemantauan utama untuk SAP di Microsoft Azure
1409604 Virtualisasi di Windows: Pemantauan yang ditingkatkan
2191498 SAP di Linux dengan Azure: Pemantauan yang ditingkatkan
2039619 Aplikasi SAP di Microsoft Azure menggunakan database Oracle: Produk dan versi yang didukung
2233094 DB6: Aplikasi SAP di Microsoft Azure menggunakan IBM DB2 untuk Linux, UNIX, dan Windows: Informasi tambahan
2243692 Linux di Microsoft Azure (IaaS) VM: Masalah lisensi SAP
2578899 SUSE Linux Enterprise Server 15: Catatan Penginstalan
1984787 SUSE LINUX Enterprise Server 12: Catatan pemasangan
2772999 Red Hat Enterprise Linux 8.x: Penginstalan dan Konfigurasi
2002167 Red Hat Enterprise Linux 7.x: Penginstalan dan peningkatan
2069760 Penginstalan dan peningkatan Oracle Linux 7.x SAP
1597355 Rekomendasi swap-space untuk Linux
2799900 Catatan Teknis Pusat untuk Oracle Database 19c
2171857 Oracle Database 12c: Dukungan sistem file di Linux
1114181 Oracle Database 11g: Dukungan sistem file di Linux
2969063 Validasi Kode Mikro Gagal di HCMT di Azure
3246210 Azure - HCMT Gagal Selama Beberapa Pengujian Performa Disk

Untuk informasi tentang semua Catatan SAP bagi Linux, lihat wiki komunitas SAP.

Anda memerlukan pengetahuan tentang arsitektur Microsoft Azure serta bagaimana komputer virtual Microsoft Azure diterapkan dan dioperasikan. Untuk informasi selengkapnya, lihat dokumentasi Microsoft Azure.

Secara umum, penginstalan serta konfigurasi Windows, Linux, dan DBMS pada dasarnya sama dengan komputer virtual atau mesin bare metal yang diinstal di tempat. Ada beberapa arsitektur dan keputusan penerapan pengelolaan sistem yang berbeda ketika Anda menggunakan Microsoft Azure IaaS. Dokumen ini menjelaskan perbedaan arsitektur dan pengelolaan sistem yang spesifik yang akan disiapkan saat Anda menggunakan Microsoft Azure IaaS.

Struktur penyimpanan VM untuk penyebaran RDBMS

Untuk mengikuti bab ini, baca dan pahami informasi yang disajikan dalam:

Untuk penyimpanan blok Azure, penggunaan disk terkelola Azure adalah wajib. Untuk detail tentang disk yang dikelola Azure, baca artikel Pengenalan disk terkelola untuk Azure VM.

Dalam konfigurasi dasar, kami biasanya merekomendasikan struktur penyebaran di mana sistem operasi, DBMS, dan biner SAP terpisah dari file database. Sebaiknya anda memiliki disk Azure terpisah untuk:

  • Sistem operasi (dasar VHD atau OS VHD)
  • Eksekusi sistem manajemen database
  • Eksekusi SAP seperti /usr/sap
  • File data DBMS
  • File log pengulangan DBMS

Konfigurasi yang memisahkan komponen ini menjadi lima volume yang berbeda dapat mengakibatkan ketahanan yang lebih tinggi karena penggunaan yang berlebihan pada satu volume tidak selalu mengganggu penggunaan volume lain selama kuota dan batas penyimpanan VM tidak terlampaui.

File log data dan transaksi/pengulangan DBMS disimpan di penyimpanan blok yang didukung Microsoft Azure atau Azure NetApp Files. Azure Files atau Azure Premium Files tidak didukung sebagai penyimpanan untuk data DBSM dan/atau mengulangi file log dengan beban kerja SAP. File tersebut disimpan dalam disk terpisah dan dipasang sebagai disk logis ke VM citra sistem operasi Azure asli. Untuk penyebaran Linux, rekomendasi yang berbeda didokumentasikan. Baca artikel Jenis Microsoft Azure Storage untuk beban kerja SAP untuk kemampuan dan dukungan berbagai jenis penyimpanan bagi skenario Anda. Khusus untuk SAP Hana dimulai dengan artikel konfigurasi penyimpanan komputer virtual Azure SAP Hana.

Saat Anda merencanakan tata letak disk, temukan keseimbangan terbaik di antara item berikut:

  • Jumlah file data.
  • Jumlah diska yang memuat berkas tersebut.
  • Kuota IOPS dari satu disk atau pembagian NFS.
  • Throughput data per disk atau pembagian NFS.
  • Jumlah disk data tambahan mungkin per ukuran VM.
  • Keseluruhan penyimpanan atau throughput jaringan yang dapat disediakan VM.
  • Latensi yang dapat disediakan berbagai Microsoft Azure Storage yang berbeda.
  • IOPS penyimpanan VM dan kuota throughput.
  • Kuota jaringan VM jika Anda menggunakan NFS - lalu lintas ke berbagi NFS dihitung terhadap kuota jaringan VM dan BUKAN kuota penyimpanan.
  • SLA VM.

Azure memberlakukan kuota IOPS per disk data atau pembagian NFS. Kuota ini berbeda untuk disk yang dihosting di berbagai solusi atau pembagian penyimpanan blok Azure. Latensi I/O juga berbeda antara berbagai jenis penyimpanan ini.

Setiap jenis VM memiliki jumlah disk data terbatas yang dapat Anda sambungkan. Pembatasan lainnya adalah hanya jenis VM tertentu yang dapat menggunakan, misalnya, penyimpanan premium. Biasanya, Anda memutuskan untuk menggunakan tipe VM tertentu berdasarkan persyaratan CPU dan memori. Anda juga perlu mempertimbangkan persyaratan IOPS, latensi, dan throughput disk yang biasanya diskalakan dengan jumlah disk atau jenis disk penyimpanan premium v1. Jumlah IOPS dan throughput yang akan dicapai oleh setiap disk mungkin menentukan ukuran disk, terutama dengan penyimpanan premium v1. Dengan penyimpanan premium v2 atau disk Ultra, Anda dapat memilih IOPS dan throughput yang disediakan terlepas dari kapasitas disk.

Catatan

Untuk penyebaran DBMS, kami sangat merekomendasikan penyimpanan premium Azure (v1 dan v2), disk Ultra atau berbagi NFS berbasis Azure NetApp Files untuk data, log transaksi, atau file pengulangan apa pun. Tidak masalah jika Anda ingin menyebarkan sistem produksi atau nonproduksi. Latensi HDD standar Azure atau SSD tidak dapat diterima untuk semua jenis sistem produksi.

Catatan

Untuk memaksimalkan SLA VM tunggal Azure, semua disk yang terpasang harus penyimpanan premium Azure (v1 atau v2) atau jenis disk Azure Ultra, yang mencakup VHD dasar (penyimpanan premium Azure).

Catatan

Tidak mendukung hosting file database utama, seperti file data dan log, database SAP pada perangkat keras penyimpanan yang terletak di pusat data pihak ketiga yang berbagi lokasi berdekatan dengan pusat data Microsoft Azure. Penyimpanan yang disediakan melalui peralatan perangkat lunak yang dihosting di Azure VM, juga tidak didukung untuk kasus penggunaan ini. Untuk beban kerja DBMS SAP, hanya penyimpanan yang diwakili sebagai layanan Microsoft Azure asli yang didukung untuk file data dan log transaksi database SAP secara umum. DBMS yang berbeda mungkin mendukung jenis penyimpanan Microsoft Azure yang berbeda. Untuk detail selengkapnya, periksa artikel Jenis Microsoft Azure Storage untuk beban kerja SAP

Penempatan file database serta file log dan pengulangan serta jenis Microsoft Azure Storage yang digunakan, ditentukan oleh persyaratan IOPS, latensi, dan throughput. Khusus untuk penyimpanan premium Azure v1, untuk mencapai IOPS yang cukup, Anda mungkin dipaksa untuk menggunakan beberapa disk atau menggunakan disk penyimpanan premium yang lebih besar. Jika Anda menggunakan beberapa disk, buat strip perangkat lunak di seluruh disk yang berisi file data atau file log dan pengulangan. Dalam kasus seperti itu, IOPS dan SLA throughput disk dari disk penyimpanan premium yang mendasarinya atau IOPS maksimum yang dapat dicapai dari disk penyimpanan standar akumulatif untuk set strip yang dihasilkan.

Jika persyaratan IOPS Anda melebihi apa yang dapat disediakan VHD tunggal, seimbangkan IOPS yang diperlukan untuk file database di sejumlah VHD. Cara termudah untuk mendistribusikan beban IOPS di seluruh disk adalah dengan membuat strip perangkat lunak melalui disk yang berbeda. Lalu tempatkan sejumlah file data DBMS SAO pada LUN yang dibuat dari strip perangkat lunak. Jumlah disk dalam strip didorong oleh tuntutan IOPS, tuntutan throughput disk, dan tuntutan volume.

Strip penyimpanan Windows Windows

Kami menyarankan agar Anda menggunakan Ruang Penyimpanan Windows untuk membuat set strip di beberapa VHD Azure. Gunakan setidaknya Windows Server 2012 R2 atau Windows Server 2016.

Strip penyimpanan Linux Linux

Hanya MDADM dan Logical Volume Manager (LVM) yang didukung untuk membuat RAID perangkat lunak di Linux. Untuk informasi selengkapnya, lihat:

Untuk penyimpanan premium Azure v2 dan disk Ultra, striping mungkin tidak diperlukan karena Anda dapat menentukan IOPS dan throughput disk terlepas dari ukuran disk.

Catatan

Karena Microsoft Azure Storage menyimpan tiga citra VHD, tidak masuk akal untuk mengonfigurasi redundansi saat Anda melakukan strip. Anda hanya perlu mengonfigurasi strip sehingga I/O didistribusikan melalui berbagai VHD.

Disk terkelola atau tidak terkelola

Akun penyimpanan Microsoft Azure adalah konstruksi administratif dan juga subjek pembatasan. Untuk informasi tentang kemampuan dan batasan, lihat Skalabilitas dan target performa Microsoft Azure Storage. Untuk penyimpanan standar, ingat bahwa ada batasan pada IOPS per akun penyimpanan. Lihat baris yang berisi Total Tingkat Permintaan dalam artikel Skalabilitas dan target performa Microsoft Azure Storage. Terdapat juga batas awal jumlah akun penyimpanan per langganan Microsoft Azure. Pada 2017, Azure memperkenalkan konsep Azure Managed Disks yang melegakan Anda untuk mengurus administrasi akun penyimpanan apa pun. Menggunakan disk terkelola Azure adalah default untuk menyebarkan beban kerja SAP di Azure.

Penting

Mengingat keunggulan Azure Managed Disks, Anda harus menggunakan Azure Managed Disks untuk penyebaran DBMS dan penyebaran SAP secara umum.

Jika Anda kebetulan memiliki beban kerja SAP yang belum menggunakan disk terkelola, untuk mengonversi dari disk yang tidak dikelola ke disk terkelola, lihat:

Penembolokan untuk VM dan disk data

Saat Anda memasang disk ke VM, Anda dapat memilih apakah lalu lintas I/O antara VM dan disk yang terletak di penyimpanan Azure di-cache.

Rekomendasi berikut mengasumsikan karakteristik I/O ini untuk DBMS standar:

  • Sebagian besar merupakan beban kerja pembacaan terhadap file data database. Bacaan ini sangat penting bagi sistem DBMS.
  • Penulisan terhadap file data terjadi dalam semburan berdasarkan pos pemeriksaan atau aliran konstan. Rata-rata selama sehari, ada lebih sedikit tulisan daripada bacaan. Berlawanan dengan bacaan dari file data, tulisan-tulisan ini tidak sinkron dan tidak menahan transaksi pengguna apa pun.
  • Hampir tidak ada bacaan dari file log transaksi atau ulangi. Pengecualian adalah I/Os besar ketika Anda melakukan pencadangan log transaksi.
  • Beban utama terhadap transaksi atau mengulangi file log adalah menulis. Tergantung pada sifat beban kerja, Anda dapat memiliki I / Os sekecil 4 KB atau, dalam kasus lain, ukuran I / O 1 MB atau lebih.
  • Semua tulisan harus di persisten pada disk dengan cara yang dapat diandalkan.

Untuk penyimpanan premium Azure v1, opsi penembolokan berikut ada:

  • Tidak
  • Read
  • Baca/tulis
  • None + Write Accelerator, yang hanya untuk Azure M-Series VMs
  • None + Write Accelerator, yang hanya untuk Azure M-Series VMs

Untuk penyimpanan premium v1, kami sarankan Anda menggunakan Penembolokan Baca untuk file data database SAP dan pilih Tidak ada penembolokan untuk disk file log.

Catatan

Dengan beberapa jenis VM M(b)v3 baru, penggunaan penyimpanan SSD v1 Premium yang di-cache dapat mengakibatkan tingkat dan throughput IOPS baca dan tulis yang lebih rendah daripada yang Akan Anda dapatkan jika Anda tidak menggunakan cache baca.

Untuk penyebaran Seri M, kami sarankan Anda menggunakan Azure Write Accelerator hanya untuk disk file log Anda. Untuk detail, pembatasan, dan penyebaran Akselerator Tulis Azure, lihat Aktifkan Akselerator Tulis.

Untuk penyimpanan premium v2, disk Ultra, dan Azure NetApp Files, tidak ada opsi penembolokan yang ditawarkan.

Disk nonpersisten Azure

Azure VM menawarkan disk nonpersisten setelah VM disebarkan. Jika VM di-boot ulang, semua konten pada drive tersebut dapat dihapuskan. Ini diberikan bahwa file data dan file log dan pengulangan database tidak boleh berada dalam keadaan apa pun yang terletak di drive nonpersissis tersebut. Mungkin terdapat pengecualian untuk beberapa database, di mana drive nonpersisten ini mungkin cocok untuk ruang tabel tempdb dan temp.

Untuk informasi selengkapnya, lihat Memahami drive sementara pada VM Windows di Azure.

Disk nonpersisten Windows Windows

Drive D dalam Azure VM adalah drive nonpersisten, yang didukung oleh beberapa disk lokal pada node komputasi Azure. Karena nonpersisten, setiap perubahan yang dilakukan pada isi drive D hilang ketika VM di-boot ulang. Perubahan mencakup file yang disimpan, direktori yang dibuat, dan aplikasi yang diinstal.

Disk nonpersisten Linux Linux

Azure VM Linux secara otomatis memasang drive di /mnt/resource yang merupakan drive nonpersisten yang didukung oleh disk lokal pada node komputasi Azure. Karena nonpersisten, setiap perubahan yang dilakukan pada isi /mnt/resource hilang ketika VM di-boot ulang. Perubahan mencakup file yang disimpan, direktori yang dibuat, dan aplikasi yang diinstal.

Ketahanan Microsoft Azure Storage

Microsoft Azure Storage menyimpan VHD dasar, dengan OS dan disk atau blob yang terpasang, pada setidaknya tiga node penyimpanan terpisah. Jenis penyimpanan ini disebut penyimpanan lokal berlebihan (LRS). LRS adalah default untuk semua jenis penyimpanan di Microsoft Azure.

Terdapat metode redundansi lainnya. Untuk informasi selengkapnya, lihat Replikasi Azure Storage.

Catatan

Penyimpanan premium Azure v1 dan v2, Disk Ultra dan Azure NetApp Files adalah jenis penyimpanan yang direkomendasikan untuk VM dan disk DBMS yang menyimpan database dan file log dan pengulangan. Dengan pengecualian penyimpanan premium v1, satu-satunya metode redundansi yang tersedia untuk jenis penyimpanan ini adalah LRS. Dengan demikian, Anda perlu mengonfigurasi metode database untuk memungkinkan replikasi data database ke wilayah atau zona ketersedian Azure lain. Metode database Mencakup SQL Server Always On, Oracle Data Guard, dan HANA System Replication.

Ketahanan node VM

Microsoft Azure menawarkan beberapa SLA berbeda untuk VM. Untuk informasi selengkapnya, lihat rilis terbaru SLA untuk Komputer Virtual. Karena lapisan DBMS sangat penting untuk ketersediaan dalam sistem SAP, Anda perlu memahami berbagai jenis penyebaran dan peristiwa pemeliharaan. Untuk informasi selengkapnya tentang konsep ini, lihat Mengelola ketersediaan komputer virtual di Azure.

Rekomendasi minimum untuk skenario DBMS produksi dengan beban kerja SAP adalah:

  • Sebarkan dua VM menggunakan jenis penyebaran yang dipilih di wilayah Azure yang sama.
  • Jalankan kedua VM ini dalam jaringan virtual Azure yang sama dan pasangkan NIC dari subnet yang sama.
  • Gunakan metode database untuk tetap siaga dengan VM kedua. Metode dapat merupakan SQL Server Always On, Oracle Data Guard, atau HANA System Replication.

Anda juga dapat menerapkan VM ketiga di wilayah Azure lainnya dan menggunakan metode database yang sama untuk menyediakan replika asinkron di wilayah Azure lainnya.

Pertimbangan jaringan Microsoft Azure

Dalam penyebaran SAP berskala besar, gunakan cetak biru Azure Virtual Datacenter. Gunakan untuk konfigurasi jaringan virtual Anda serta izin dan penetapan peran untuk berbagai bagian organisasi.

Praktik terbaik ini adalah hasil dari ribuan penyebaran pelanggan:

  • Jaringan virtual aplikasi SAP digunakan agar tidak memiliki akses ke internet.
  • VM database berjalan dalam jaringan virtual yang sama dengan lapisan aplikasi, dipisahkan dalam subnet yang berbeda dari lapisan aplikasi SAP.
  • VM dalam jaringan virtual memiliki alokasi statis alamat IP pribadi. Untuk informasi selengkapnya, lihat Jenis alamat IP dan metode alokasi di Azure.
  • Pembatasan perutean ke dan dari VM DBMS tidak diatur dengan firewall yang diinstal pada VM DBMS lokal. Sebaliknya, perutean lalu lintas didefinisikan dengan kelompok keamanan jaringan (NSG).
  • Untuk memisahkan dan mengisolasi lalu lintas ke DBMS VM, tetapkan NIC yang berbeda ke VM. Setiap NIC mendapatkan alamat IP yang berbeda, dan setiap NIC ditugaskan ke subnet jaringan virtual yang berbeda. Setiap subnet memiliki aturan NSG yang berbeda. Isolasi atau pemisahan lalu lintas jaringan adalah pengukuran untuk perutean. Tidak digunakan untuk menetapkan kuota bagi throughput jaringan.

Catatan

Menetapkan alamat IP statik melalui Azure berarti menetapkannya ke NIC virtual terpisah. Jangan tetapkan alamat IP statik dalam OS tamu ke NIC virtual. Beberapa layanan Azure seperti Azure Backup mengandalkan fakta bahwa setidaknya NIC virtual utama di OS tamu diatur ke DHCP dan bukan ke alamat IP statis. Untuk informasi selengkapnya, lihat Memecahkan masalah pencadangan komputer virtual Azure. Untuk menetapkan beberapa alamat IP statik ke VM, tetapkan beberapa NIC virtual ke VM.

Peringatan

Tidak mendukung konfigurasi peralatan virtual jaringan di jalur komunikasi antara aplikasi SAP dan lapisan DBMS sistem SAP berbasis SAP NetWeaver, Hybris, atau S/4HANA. Pembatasan ini untuk alasan fungsionalitas dan kinerja. Jalur komunikasi antara lapisan aplikasi SAP dan lapisan DBMS harus yang langsung. Pembatasan tidak mencakup aturan kelompok keamanan aplikasi (ASG) dan NSG jika aturan ASG dan NSG tersebut memungkinkan jalur komunikasi langsung. Ini juga termasuk lalu lintas ke berbagi NFS yang menghosting data DBMS dan mengulangi file log.

Skenario lain di mana peralatan virtual jaringan tidak didukung berada dalam:

Peralatan virtual jaringan dalam jalur komunikasi dapat dengan mudah menggandakan latensi jaringan antara dua mitra komunikasi. Peralatan tersebut juga dapat membatasi throughput dalam jalur penting antara lapisan aplikasi SAP dan lapisan DBMS. Dalam beberapa skenario pelanggan, peralatan virtual jaringan dapat menyebabkan kegagalan kluster Linux Pacemaker. Terdapat kasus di mana komunikasi antara node kluster Linux Pacemaker berkomunikasi ke perangkat SBD node tersebut melalui alat virtual jaringan.

Penting

Desain lain yang tidak didukung adalah pemisahan lapisan aplikasi SAP dan lapisan DBMS ke berbagai jaringan virtual Azure yang tidak di-peer dengan satu sama lain. Kami menyarankan agar Anda memisahkan lapisan aplikasi SAP dan lapisan DBMS dengan menggunakan subnet dalam jaringan virtual Azure ketimbang dengan menggunakan jaringan virtual Azure yang berbeda.

Jika Anda memutuskan untuk tidak mengikuti rekomendasi dan sebaliknya memisahkan dua lapisan ke jaringan virtual yang berbeda, kedua jaringan virtual harus di-peer.

Ketahuilah bahwa lalu lintas jaringan antara dua jaringan virtual Azure yang di-peer tunduk pada biaya transfer. Volume data besar yang terdiri dari banyak terabyte ditukar antara lapisan aplikasi SAP dan lapisan DBMS. Anda dapat mengakumulasi biaya besar jika lapisan aplikasi SAP dan lapisan DBMS dipisahkan antara dua jaringan virtual Azure yang di-peer.

Menggunakan Load Balancer Azure untuk mengalihkan lalu lintas

Penggunaan alamat IP virtual pribadi yang digunakan dalam fungsi seperti SQL Server Always On atau HANA System Replication memerlukan konfigurasi load balancer Azure. Load balancer menggunakan port probe untuk menentukan node DBMS aktif dan merutekan lalu lintas secara eksklusif ke node database aktif tersebut.

Jika ada kegagalan node database, tidak perlu mengonfigurasi ulang aplikasi SAP. Sebaliknya, arsitektur aplikasi SAP yang paling umum terhubung kembali terhadap alamat IP virtual pribadi. Sementara itu, load balancer bereaksi terhadap kegagalan node dengan mengalihkan lalu lintas terhadap alamat IP virtual pribadi ke node kedua.

Azure menawarkan dua SKU load balancer yang berbeda: SKU dasar dan SKU standar. Berdasarkan manfaat dalam pengaturan dan fungsi, Anda harus menggunakan SKU Standar load balancer Azure. Salah satu keuntungan besar dari versi Standar dari load balancer adalah bahwa lalu lintas data tidak dirutekan melalui load balancer itu sendiri.

Contoh bagaimana Anda dapat mengonfigurasi load balancer internal dapat ditemukan di artikel Tutorial: Mengonfigurasi grup ketersediaan SQL Server di Microsoft Azure Virtual Machines secara manual

Catatan

Terdapat perbedaan dalam perilaku SKU dasar dan standar terkait akses alamat IP publik. Cara kerja mengatasi pembatasan SKU Standar untuk mengakses alamat IP publik dijelaskan dalam dokumen Konektivitas titik akhir publik untuk Virtual Machines menggunakan Load Balancer Standar Azure dalam skenario ketersediaan tinggi SAP

Penyebaran pemantauan host

Untuk penggunaan produksi aplikasi SAP di komputer virtual Azure, SAP membutuhkan kemampuan untuk mendapatkan data pemantauan host dari host fisik yang menjalankan komputer virtual Azure. Tingkat patch SAP Host Agent tertentu diperlukan yang memungkinkan kemampuan ini di SAPOSCOL dan SAP Host Agent. Tingkat patch yang tepat didokumentasikan dalam Catatan SAP 1409604.

Untuk informasi selengkapnya tentang penyebaran komponen yang mengirimkan data host ke SAPOSCOL dan Agen Host SAP dan manajemen siklus hidup komponen tersebut, mulailah dengan artikel Menerapkan ekstensi Azure VM untuk solusi SAP.

Langkah berikutnya

Untuk informasi selengkapnya tentang DBMS tertentu, lihat: