Saran dan Komentar Edit

Menjalankan SAP HANA untuk mesin virtual Linux dalam arsitektur peningkatan skala di Azure

Azure
Komputer Virtual
Linux Virtual Machines

Arsitektur referensi ini menunjukkan serangkaian praktik yang terbukti untuk menjalankan SAP Hana di lingkungan yang sangat tersedia dan ditingkatkan skalanya yang mendukung pemulihan bencana di Azure. Implementasi ini hanya berfokus pada lapisan database.

Arsitektur

Arsitektur referensi ini menjelaskan sistem produksi umum. Anda dapat memilih ukuran mesin virtual untuk mengakomodasi kebutuhan organisasi Anda. Konfigurasi ini juga dapat dikurangi menjadi satu komputer virtual, tergantung pada persyaratan bisnis.

Diagram pertama menunjukkan arsitektur referensi untuk SAP Hana di Azure, yang menggunakan set ketersediaan.

Reference architecture for SAP HANA ScaleUpGambar - Arsitektur lingkungan HANA produksi, di Azure dengan set ketersediaan.

Diagram kedua menunjukkan arsitektur referensi untuk SAP Hana di Azure, yang menggunakan zona ketersediaan.

Reference architecture for SAP HANA ScaleUpGambar - Arsitektur lingkungan HANA produksi, di Azure dengan zona ketersediaan.

Unduh file Visio arsitektur ini, yang berisi semua versi termasuk pemulihan bencana.

Catatan

Untuk menyebarkan arsitektur referensi ini, Anda memerlukan lisensi produk SAP yang sesuai dan teknologi non-Microsoft lainnya.

Alur kerja

Arsitektur referensi ini menjelaskan database SAP Hana khas yang berjalan di Azure, dalam penyebaran yang sangat tersedia untuk memaksimalkan ketersediaan sistem. Arsitektur dan komponennya dapat disesuaikan berdasarkan persyaratan bisnis (RTO, RPO, harapan waktu aktif, peran sistem) dan berpotensi dikurangi menjadi satu VM. Tata letak jaringan disederhanakan untuk menunjukkan prinsip arsitektur lingkungan SAP tersebut dan tidak dimaksudkan untuk menggambarkan jaringan perusahaan penuh.

Jaringan

Jaringan virtual (vnet) Layanan Azure Virtual Network menghubungkan sumber daya Azure satu sama lain dengan keamanan yang ditingkatkan. Dalam arsitektur ini, jaringan virtual terhubung ke lingkungan lokal melalui gateway jaringan privat maya (VPN) yang disebarkan di hub topologi hub-spoke. SAP Hana database terkandung dalam jaringan virtual spoke sendiri. Jaringan virtual spoke berisi satu subnet untuk komputer virtual database (VM).

Jika aplikasi yang terhubung ke SAP Hana berjalan pada VM, VM aplikasi harus terletak di vnet yang sama tetapi dalam subnet aplikasi khusus. Atau, jika koneksi SAP Hana bukan database utama, VM aplikasi dapat ditemukan di vnet lain. Memisahkan ke subnet berdasarkan beban kerja memungkinkan pengaktifan grup keamanan jaringan (NSG) yang lebih mudah untuk menetapkan aturan keamanan yang berlaku hanya untuk SAP Hana VM.

Gateway zona-redundan Gateway menyambungkan jaringan yang berbeda, memperluas jaringan lokal Anda ke jaringan virtual Azure. Kami menyarankan agar Anda menggunakan ExpressRoute untuk membuat koneksi privat yang tidak melalui internet publik. Anda juga dapat menggunakan koneksi situs-ke-situs . Azure ExpressRoute atau gateway VPN dapat disebarkan di seluruh zona untuk menjaga dari kegagalan zona. Lihat Gateway jaringan virtual zona-redundan untuk memahami perbedaan antara penyebaran zona dan penyebaran zona-redundan. Alamat IP yang digunakan harus dari SKU Standar untuk penyebaran zona gateway.

Kelompok keamanan jaringan (NSG) Untuk membatasi lalu lintas jaringan masuk dan keluar dari jaringan virtual, buat grup keamanan jaringan yang pada gilirannya ditetapkan ke subnet tertentu. DB dan subnet aplikasi diamankan dengan NSG khusus beban kerja.

Kelompok keamanan aplikasi (ASG) Untuk menentukan kebijakan keamanan jaringan mendetail di dalam NSG Anda berdasarkan beban kerja yang berpusat pada aplikasi, gunakan grup keamanan aplikasi alih-alih alamat IP eksplisit. Kelompok keamanan aplikasi memungkinkan Anda mengelompokkan mesin virtual berdasarkan nama dan membantu Anda mengamankan aplikasi dengan memfilter lalu lintas dari segmen tepercaya dari jaringan.

Kartu antarmuka jaringan (NIC) Kartu antarmuka jaringan memungkinkan semua komunikasi di antara komputer virtual pada jaringan virtual. Penyebaran SAP lokal tradisional menerapkan beberapa NIC per komputer untuk memisahkan lalu lintas administratif dari lalu lintas bisnis.

Di Azure, jaringan virtual adalah jaringan yang ditentukan perangkat lunak yang mengirimkan semua lalu lintas melalui struktur jaringan yang sama. Jadi tidak perlu menggunakan banyak NIC untuk alasan performa. Tetapi jika organisasi Anda perlu memisahkan lalu lintas, Anda dapat menyebarkan beberapa NIC per mesin virtual dan menghubungkan setiap NIC ke subnet yang berbeda. Anda kemudian dapat menggunakan grup keamanan jaringan untuk menerapkan kebijakan kontrol akses yang berbeda pada setiap subnet.

Azure NIC mendukung banyak IP. Dukungan ini sesuai dengan praktik yang disarankan SAP dalam menggunakan nama host virtual untuk penginstalan. Untuk ringkasan lengkap, lihat Catatan SAP 962955. (Untuk mengakses catatan SAP, Anda memerlukan akun SAP Service Marketplace.)

Catatan

Seperti yang ditentukan dalam Catatan SAP 2731110, jangan tempatkan alat virtual jaringan (NVA) apa pun di antara aplikasi dan lapisan database untuk tumpukan aplikasi SAP apa pun. Melakukan hal itu menyebabkan waktu pemrosesan paket data yang signifikan dan memperlambat performa aplikasi secara tidak wajar.

Komputer Virtual

Arsitektur ini menggunakan komputer virtual (VM). Azure menawarkan skala simpul tunggal hingga 11,5 memori Tebibyte (TiB) pada komputer virtual dan skala simpul tunggal hingga 24 TB pada Instans Besar Azure. Direktori Perangkat Keras SAP HANA Bersertifikat dan Didukung SAP mencantumkan mesin virtual yang disertifikasi untuk database SAP HANA. Untuk detail tentang dukungan SAP untuk jenis komputer virtual dan metrik throughput (SAPS), lihat Catatan SAP 1928533 - Aplikasi SAP di Microsoft Azure: Produk yang Didukung dan jenis Azure VM. (Untuk mengakses ini dan catatan SAP lainnya, akun SAP Service Marketplace diperlukan.)

Microsoft dan SAP bersama-sama mengesahkan berbagai ukuran mesin virtual untuk beban kerja SAP HANA. Misalnya, penyebaran yang lebih kecil dapat berjalan pada komputer virtual Edsv4 dan E(d)sv5 yang dimulai dengan RAM 160 GiB. Untuk mendukung ukuran memori SAP HANA terbesar pada mesin virtual—hingga 11,5 TB—Anda dapat menggunakan mesin virtual Azure M-series v2 (Mv2). Jenis mesin virtual M208 mencapai sekitar 260.000 SAPS, dan jenis mesin virtual M416 mencapai sekitar 488.000 SAPS.

Komputer virtual Generasi 2 (Gen2) Azure menawarkan pilihan saat menyebarkan VM jika harus generasi 1 atau 2. VM Generasi 2 mendukung fitur utama yang tidak tersedia untuk VM generasi 1. Terutama untuk SAP Hana ini penting karena beberapa keluarga VM seperti Mv2 atau Mdsv2hanya didukung sebagai VM Gen2. Demikian pula, sertifikasi SAP di Azure untuk beberapa VM yang lebih baru mungkin mengharuskannya hanya Gen2 untuk dukungan penuh, bahkan jika Azure mengizinkan keduanya. Lihat detail di SAP Note 1928533 - Aplikasi SAP di Microsoft Azure: Produk yang Didukung dan jenis Azure VM.

Karena semua VM lain yang mendukung SAP Hana memungkinkan pilihan Gen2 saja atau Gen1+2 secara selektif, disarankan untuk menyebarkan semua VM SAP hanya sebagai Gen2. Ini juga berlaku untuk VM dengan persyaratan memori yang rendah. Bahkan 160 GiB terkecil SAP Hana VM dapat berjalan sebagai VM Gen2 dan dapat, ketika dibatalkan alokasinya, diubah ukurannya menjadi VM terbesar yang tersedia di wilayah dan langganan Anda.

Grup Penempatan Kedekatan (PPG) Untuk mengoptimalkan latensi jaringan, Anda dapat menggunakan grup penempatan kedekatan, yang mendukung kolokasi, yang berarti bahwa komputer virtual berada di pusat data yang sama untuk meminimalkan latensi antara SAP Hana dan menghubungkan VM aplikasi. Untuk arsitektur SAP Hana itu sendiri, tidak ada PPG yang diperlukan, mereka hanya merupakan opsi untuk menempatkan SAP Hana dengan VM tingkat aplikasi. Karena potensi pembatasan dengan PPG, menambahkan database AvSet ke PPG sistem SAP harus dilakukan secara jarang dan hanya ketika diperlukan untuk latensi antara aplikasi SAP dan lalu lintas database. Untuk informasi selengkapnya tentang skenario penggunaan PPG, lihat dokumentasi tertaut. Karena PPG membatasi beban kerja ke satu pusat data, PPG tidak dapat menjangkau beberapa zona ketersediaan.

Komponen

Pertimbangan

Skalabilitas

Arsitektur ini berjalan SAP Hana pada komputer virtual yang dapat menskalakan hingga 11,5 TiB dalam satu instans.

Jika beban kerja Anda melebihi ukuran mesin virtual maksimum, Microsoft menawarkan Azure Large Instances untuk SAP HANA. Rev. 4 dari server fisik ini terletak di pusat data Azure. Saat ini, versi ini menyediakan kapasitas memori hingga 24 TB untuk satu instans.

Konfigurasi multi-node juga bisa dilakukan. Untuk aplikasi pemrosesan transaksi online (OLTP) memiliki total kapasitas memori hingga 48 TB. Dengan aplikasi pemrosesan analitik daring (OLAP), kapasitas memorinya adalah 96 TB. Misalnya, Anda dapat menyebarkan SAP HANA dalam konfigurasi peluasan skala dengan siaga di mesin virtual—menjalankan Red Hat Enterprise Linux atau SUSE Linux Enterprise Server—menggunakan Azure NetApp Files untuk volume penyimpanan bersama.

Penyimpanan

Arsitektur ini menggunakan disk terkelola Azure untuk penyimpanan pada komputer virtual atau Azure NetApp Files. Panduan untuk penyebaran penyimpanan dengan disk terkelola secara rinci dalam dokumen konfigurasi penyimpanan komputer virtual Azure SAP Hana. Atau untuk disk terkelola, Azure NetApp Files volume NFS dapat digunakan sebagai solusi penyimpanan untuk SAP Hana.

Untuk mencapai operasi input/output tinggi per detik (IOPS) dan throughput penyimpanan disk, praktik umum dalam pengoptimalan performa volume penyimpanan juga berlaku untuk tata letak penyimpanan Azure. Misalnya, menggabungkan beberapa disk bersama dengan LVM untuk membuat volume disk bergaris meningkatkan performa IO. Penembolokan disk Azure juga memainkan peran besar dalam mencapai performa IO yang diperlukan. Untuk disk log SAP Hana, disk yang dipercepat penulisan (pada VM seri M) atau ultra-disk (pada VM seri M/E) atau Azure NetApp Files (pada VM seri M/E) diperlukan untuk area yang menyimpan /hana/log untuk penggunaan produksi, untuk secara konsisten mencapai latensi penyimpanan kurang dari 1 ms.

Untuk detail tentang persyaratan performa SAP Hana, lihat Catatan SAP 1943937 - Alat Pemeriksaan Konfigurasi Perangkat Keras.

  • Desain penyimpanan sadar biaya untuk sistem non-produktif SAP Hana lingkungan, yang tidak memerlukan performa penyimpanan maksimum dalam semua situasi, dapat menggunakan arsitektur penyimpanan yang lebih dioptimalkan berdasarkan biaya. Ini dapat berlaku untuk sistem produksi yang sedikit digunakan atau beberapa lingkungan SAP Hana yang tidak produktif. Penyimpanan yang dioptimalkan biaya menggunakan kombinasi SSD Standar alih-alih semua Premium atau Ultra SSD yang digunakan untuk produksi, dan juga menggabungkan sistem file /hana/data dan /hana/log ke set disk yang sama. Pedoman dan praktik terbaik untuk sebagian besar ukuran VM tersedia. Jika menggunakan Azure NetApp Files untuk SAP Hana, volume berkurang ukuran dapat digunakan untuk mencapai tujuan yang sama.
  • Mengubah ukuran penyimpanan saat meningkatkan skala Saat mengubah ukuran komputer virtual karena permintaan bisnis yang berubah, atau karena ukuran database yang berkembang, konfigurasi penyimpanan dapat berubah. Azure mendukung ekspansi disk online, tanpa gangguan pada layanan. Dengan penyiapan disk bergaris, seperti yang digunakan untuk SAP Hana, operasi pengubahan ukuran harus dilakukan secara merata ke semua disk dalam grup volume. Penambahan lebih banyak disk ke grup volume berpotensi tidak seimbang dengan data bergaris. Jika menambahkan lebih banyak disk ke konfigurasi penyimpanan, jauh lebih disukai untuk membuat volume penyimpanan baru pada disk baru. Selanjutnya salin konten selama waktu henti dan ubah titik pemasangan. Terakhir, buang grup volume lama yang tidak lagi diperlukan dan disk yang mendasar.
  • Grup volume aplikasi NetApp (pratinjau) Untuk penyebaran dengan file SAP Hana yang terdapat pada volume NFS Azure NetApp Files, grup volume aplikasi memungkinkan Anda untuk menyebarkan semua volume sesuai dengan praktik terbaik. Proses ini juga memastikan performa optimal untuk database SAP Hana Anda. Detail tersedia tentang cara melanjutkan proses ini karena memerlukan intervensi manual memungkinkan beberapa waktu untuk pembuatan.

Ketersediaan Tinggi

Arsitektur di atas menggambarkan penyebaran yang sangat tersedia, dengan SAP Hana terkandung pada 2 komputer virtual atau lebih. Komponen berikut digunakan.

Load BalancerAzure Load Balancer digunakan untuk mendistribusikan lalu lintas ke komputer virtual SAP Hana. Saat Anda menggabungkan Azure Load Balancer dalam penyebaran zona SAP, pastikan Anda memilih load balancer SKU Standar karena penyeimbang SKU Dasar tidak dilengkapi dengan redundansi zona. Load Balancer dalam arsitektur ini bertindak sebagai alamat IP virtual untuk SAP Hana dan lalu lintas jaringan dikirim ke VM aktif tempat instans database utama berjalan. SAP Hana arsitektur aktif/berkemampuan baca tersedia (SLESRHEL/) di mana IP virtual kedua yang ditujukan pada load balancer digunakan untuk mengarahkan lalu lintas jaringan ke instans SAP Hana sekunder pada VM lain untuk beban kerja baca intens.

Standard Load Balancer aman secara default, dan tidak ada mesin virtual di belakang Standard Load Balancer yang memiliki konektivitas internet keluar. Untuk mengaktifkan internet keluar di mesin virtual, Anda harus mempertimbangkan konfigurasi Standard Load Balancer.

Untuk kluster database SAP HANA, Anda harus mengaktifkan Direct Server Return (DSR), juga dikenal sebagai Floating IP. Fitur ini memungkinkan server untuk merespons alamat IP front end load balancer. Koneksi langsung ini menjaga load balancer agar tidak menjadi hambatan di jalur transmisi data.

Set ketersediaan Set ketersediaan mendistribusikan server melalui infrastruktur fisik Azure, untuk menyebarkannya melalui kegagalan yang berbeda dan memperbarui domain untuk meningkatkan ketersediaan layanan. Untuk memenuhi perjanjian tingkat layanan (SLA), masukkan mesin virtual yang menjalankan peran yang sama ke dalam kumpulan ketersediaan. Melakukannya membantu melindungi dari waktu henti yang direncanakan dan tidak direncanakan oleh pemeliharaan infrastruktur Azure atau disebabkan oleh kesalahan perangkat keras. Untuk mendapatkan SLA yang lebih tinggi, Anda harus memiliki 2 atau lebih komputer virtual per set ketersediaan.

Semua komputer virtual dalam satu set harus melakukan peran yang sama. Jangan mencampur server dengan peran yang berbeda dalam set ketersediaan yang sama.

Anda dapat menyebarkan kumpulan ketersediaan Azure di Zona Ketersediaan Azure saat menggunakan grup penempatan kedekatan.

Zona ketersediaan Zona ketersediaan adalah lokasi yang dipisahkan secara fisik dalam wilayah Azure tertentu. Tujuan mereka adalah untuk lebih meningkatkan ketersediaan layanan. Karena potensi penempatan geografis dan jaringan, administrator memerlukan profil latensi jaringan yang jelas antara semua zona wilayah target sebelum mereka dapat menentukan penempatan sumber daya dengan latensi antar-zona minimum. Untuk membuat profil ini, sebarkan mesin virtual kecil di setiap zona untuk pengujian. Alat yang disarankan untuk pengujian ini meliputi PsPing dan Iperf. Saat pengujian selesai, hapus mesin virtual yang Anda gunakan untuk pengujian. Sebagai alternatif, ada juga alat pemeriksaan latensi antar zona Azure yang tersedia untuk kenyamanan Anda.

Pertimbangkan faktor keputusan saat menyebarkan VM di antara zona ketersediaan untuk SAP.

SAP Hana Untuk ketersediaan tinggi, SAP Hana berjalan pada dua atau beberapa komputer virtual Linux. SAP HANA System Replication (HSR) digunakan untuk mereplikasi data antara sistem SAP HANA primer dan sekunder (replika). HSR juga digunakan untuk pemulihan bencana lintas wilayah atau lintas zona. Bergantung pada latensi dalam komunikasi antara komputer virtual Anda, replikasi sinkron dapat digunakan dalam suatu wilayah. HSR antar wilayah untuk pemulihan bencana dalam banyak kasus akan berjalan secara asinkron.

Untuk kluster Linux Pacemaker, diperlukan pilihan mekanisme anggar kluster mana yang digunakan. Anggar kluster adalah proses mengisolasi VM yang gagal dari kluster dan memulai ulang. Untuk RedHat Enterprise Linux (RHEL), satu-satunya mekanisme pagar yang didukung untuk Pacemaker di Azure adalah agen pagar Azure. Untuk SUSE Linux Enterprise Server (SLES), baik agen pagar Azure atau perangkat blok STONITH (SBD) dapat digunakan. Bandingkan waktu failover untuk setiap solusi dan pilih berdasarkan persyaratan bisnis Anda untuk tujuan waktu pemulihan (RTO) jika ada perbedaan yang nyata.

Agen pagar Azure Metode pagar ini bergantung pada Azure ARM API, dengan Pacemaker mengkueri API ARM tentang status kedua VM SAP Hana dalam kluster. Jika satu VM gagal, misalnya OS tidak responsif atau VM crash, manajer kluster menggunakan lagi API ARM untuk menghidupkan ulang VM dan jika diperlukan gagal database SAP Hana ke node aktif lainnya. Untuk tujuan ini, perwakilan nama layanan (SPN) dengan peran kustom untuk mengkueri dan menghidupkan ulang VM digunakan untuk mengotorisasi terhadap api ARM. Tidak diperlukan infrastruktur lain, VM SBD dalam gambar arsitektur tidak disebarkan jika agen pagar Azure digunakan.

SBD SBD menggunakan disk yang diakses sebagai perangkat blok (mentah, tanpa sistem file) oleh manajer kluster. Disk ini, atau disk jika beberapa, bertindak sebagai pemungutan suara. Masing-masing dari dua node kluster yang berjalan SAP Hana mengakses disk SDB dan membaca/menulis secara berkala kepada mereka bit kecil informasi tentang status. Dengan demikian setiap node kluster tahu status tentang yang lain tanpa hanya bergantung pada jaringan antara VM.

Sebaiknya tiga VM kecil disebarkan dalam set ketersediaan atau penyiapan zona ketersediaan. Setiap VM mengekspor bagian kecil disk sebagai perangkat blok yang diakses oleh dua node kluster SAP Hana. Tiga VM SBD memastikan anggota pemungutan suara yang memadai tersedia jika terjadi waktu henti yang direncanakan atau tidak direncanakan untuk salah satu VM SBD.

Atau untuk menggunakan VM SBD, disk bersama Azure dapat digunakan sebagai gantinya. Simpul kluster SAP Hana kemudian mengakses disk bersama tunggal. Disk bersama dapat bersifat lokal (LRS) atau zonally (ZRS) redundan, jika ZRS tersedia di wilayah Azure Anda.

Pemulihan bencana

Reference architecture for SAP HANA ScaleUpGambar - Arsitektur lingkungan HANA produksi, di Azure dengan zona ketersediaan, dengan pemulihan bencana.

Dalam arsitektur ini, HSR digunakan untuk replikasi database ke instans database di wilayah sekunder. Ini opsional untuk menggunakan kluster di wilayah sekunder, tetapi hal itu dapat meningkatkan ketersediaan SAP HANA setelah failover pemulihan bencana.

Selain implementasi ketersediaan tinggi dua node lokal, HSR mendukung replikasi multi-tingkat dan multitarget . Dengan demikian, HSR memungkinkan replikasi antar-zona dan antar-wilayah. Replikasi multitarget tersedia untuk SAP HANA 2.0 Microsoft SharePoint Server 03 dan yang lebih baru.

Memicu failover pemulihan bencana adalah proses manual. Namun Anda dapat menggunakan rencana pemulihan dengan skrip penyebaran yang disesuaikan untuk mengotomatiskan banyak langkah failover.

Azure Site Recovery Anda dapat menggunakan Azure Site Recovery untuk mereplikasi konfigurasi produksi Anda secara otomatis di lokasi sekunder. Meskipun ini tidak akan menjadi VM database Anda karena dilindungi oleh HSR, VM lain dari tingkat aplikasi Anda dapat ditangani oleh Azure Site Recovery. Untuk memperluas rencana pemulihan, Anda dapat menggunakan skrip penyebaran yang disesuaikan. Contoh skrip Runbook Site Recovery Automation kustom tersedia di GitHub.

Pastikan untuk memverifikasi kapasitas sumber daya wilayah target Anda.

Azure NetApp Files Sebagai opsi, Azure NetApp Files dapat digunakan untuk menyediakan solusi penyimpanan yang dapat diskalakan dan berkinerja tinggi untuk data SAP Hana dan file log. Azure NetApp Files mendukung snapshot untuk pencadangan cepat, pemulihan, dan replikasi lokal. Untuk replikasi konten lintas wilayah, Azure NetApp Files Replikasi Lintas Wilayah dapat digunakan untuk mereplikasi data rekam jepret antara dua wilayah. Detail tentang replikasi lintas wilayah dan laporan resmi yang menjelaskan semua aspek untuk pemulihan bencana dengan Azure NetApp Files tersedia.

Cadangan

Data SAP HANA dapat dicadangkan dengan berbagai cara. Setelah bermigrasi ke Azure, Anda dapat terus menggunakan solusi pencadangan mitra yang sudah ada. Azure menyediakan dua pendekatan asli: pencadangan tingkat file SAP HANA dan Azure Backup untuk SAP HANA melalui antarmuka Backint.

Untuk pencadangan tingkat file SAP HANA, Anda dapat menggunakan alat pilihan Anda, seperti hdbsql atau SAP HANA Studio, dan menyimpan file cadangan pada volume disk lokal. Titik pemasangan umum untuk volume cadangan ini adalah /hana/cadangan. Kebijakan pencadangan Anda akan menentukan periode retensi data pada volume. Segera setelah cadangan diambil, tugas terjadwal harus menyalin file cadangan ke penyimpanan Azure Blob untuk diamankan. File cadangan lokal disimpan untuk pemulihan yang tepat.

Azure Backup menawarkan solusi kelas perusahaan yang sederhana untuk beban kerja yang berjalan di mesin virtual. Azure Backup untuk SAP HANA menyediakan integrasi penuh dengan katalog cadangan SAP HANA dan menjamin pemulihan database yang konsisten, penuh, atau tepat waktu. Azure Backup bersertifikasi BackInt oleh SAP. Lihat juga FAQ Azure Backup dan matriks dukungan.

Azure NetApp Files menghadirkan dukungan untuk pencadangan berbasis rekam jepret. Mengintegrasikan dengan SAP Hana untuk rekam jepret yang konsisten dengan aplikasi adalah melalui alat Azure Application Consistent Snapshot (AzAcSnap). Rekam jepret yang dibuat dapat digunakan untuk memulihkan ke volume baru untuk pemulihan sistem atau menyalin database SAP Hana. Rekam jepret yang dibuat dapat digunakan untuk pemulihan bencana, di mana ia bertindak sebagai titik pemulihan dengan log SAP Hana disimpan pada volume NFS yang berbeda.

Pemantauan

Untuk memantau beban kerja Anda di Azure, Azure Monitor memungkinkan Anda mengumpulkan, menganalisis, dan bertindak secara komprehensif berdasarkan telemetri dari lingkungan cloud dan lokal Anda.

Untuk menyediakan pemantauan berbasis SAP atas infrastruktur dan database Azure yang didukung, Azure Monitor untuk SAP Solutions (pratinjau) sedang digunakan. Azure Monitor untuk SAP Solutions memberikan pengalaman penyiapan yang sederhana. Pelanggan dapat mengumpulkan data telemetri dari sumber daya Azure. Mereka kemudian dapat menghubungkan data ke berbagai KPI pemantauan dan menggunakan data untuk membantu pemecahan masalah.

Untuk menyediakan pemantauan berbasis SAP atas sumber daya dan performa layanan infrastruktur SAP, Ekstensi Azure SAP Enhanced Monitoring digunakan. Ekstensi ini memasukkan statistik pemantauan Azure ke dalam aplikasi SAP untuk pemantauan sistem operasi dan fungsi DBA Cockpit. Pemantauan yang ditingkatkan SAP adalah prasyarat wajib untuk menjalankan SAP di Azure. Untuk mengetahui detailnya, lihat SAP Note 2191498, "SAP di Linux dengan Azure: Enhanced Monitoring."

Keamanan

Banyak langkah keamanan yang digunakan untuk melindungi kerahasiaan, integritas, dan ketersediaan lanskap SAP. Untuk mengamankan akses pengguna, misalnya, SAP memiliki User Management Engine (UME) sendiri untuk mengontrol akses dan otorisasi berbasis peran dalam aplikasi dan database SAP. Untuk informasi selengkapnya, lihat Keamanan SAP HANA—Ringkasan.

Untuk data tidak aktif, fungsionalitas enkripsi yang berbeda memberikan keamanan sebagai berikut:

  • Bersama dengan teknologi enkripsi asli SAP HANA, pertimbangkan untuk menggunakan solusi enkripsi dari mitra yang mendukung kunci yang dikelola pelanggan.

  • Untuk mengenkripsi disk komputer virtual, Anda dapat menggunakan fungsionalitas yang dijelaskan dalam Gambaran Umum Enkripsi Disk.

  • Server Database SAP: Menggunakan Enkripsi Data Transparan yang ditawarkan oleh penyedia DBMS (misalnya, teknologi enkripsi asli SAP HANA) untuk mengamankan data dan file log Anda dan untuk memastikan cadangan juga dienkripsi.

  • Data dalam penyimpanan fisik Azure (Enkripsi Sisi Server) secara otomatis dienkripsi saat tidak aktif dengan kunci yang dikelola Azure. Anda juga dapat memilih kunci yang dikelola pelanggan (CMK) alih-alih kunci yang dikelola Azure.

  • Untuk dukungan Azure Disk Encryption pada distro/versi/gambar Linux tertentu, periksa Azure Disk Encryption untuk VM Linux.

Catatan

Jangan gabungkan SAP Hana teknologi enkripsi asli dengan Azure Disk Encryption atau Enkripsi Berbasis Host pada volume penyimpanan yang sama. Selain itu, disk boot sistem operasi untuk komputer virtual Linux tidak mendukung Azure Disk Encryption. Sebaliknya saat menggunakan enkripsi asli SAP Hana menggabungkannya dengan enkripsi Server-Side yang diaktifkan secara otomatis. Ketahuilah bahwa penggunaan kunci yang dikelola pelanggan dapat memengaruhi throughput penyimpanan.

Untuk keamanan jaringan, gunakan grup keamanan jaringan (NSG) dan Azure Firewall atau alat virtual jaringan sebagai berikut:

  • Gunakan NSG untuk melindungi dan mengontrol lalu lintas antara subnet dan lapisan aplikasi/database. Hanya terapkan NSG ke subnet. NSG yang diterapkan pada NIC dan subnet sangat sering menyebabkan masalah selama pemecahan masalah dan harus jarang digunakan jika pernah.

  • Gunakan Azure Firewall atau alat virtual jaringan Azure untuk memeriksa dan mengontrol perutean lalu lintas dari jaringan virtual hub ke jaringan virtual spoke tempat aplikasi SAP Anda berada, dan juga untuk mengontrol konektivitas internet keluar Anda.

Untuk Pengguna dan Otorisasi, terapkan kontrol akses berbasis peran (RBAC) dan kunci sumber daya sebagai berikut:

  • Ikuti prinsip hak istimewa terkecil, menggunakan RBAC untuk menetapkan hak administratif pada sumber daya tingkat IaaS yang menghosting solusi SAP Anda di Azure. Pada dasarnya, tujuan utama RBAC adalah pemisahan dan kontrol tugas untuk pengguna/grup Anda. RBAC dirancang untuk memberikan hanya sejumlah akses ke sumber daya yang diperlukan pengguna untuk melakukan pekerjaan mereka.

  • Gunakan kunci sumber daya untuk menghindari risiko yang tidak disengaja atau yang mungkin disebabkan oleh niat jahat. Kunci sumber daya mencegah skenario di mana administrator dapat menghapus atau mengubah sumber daya penting Azure di mana solusi SAP Anda berada.

Rekomendasi keamanan lainnya dapat ditemukan di artikel Microsoft dan SAP ini.

Komunitas

Komunitas dapat menjawab pertanyaan dan membantu Anda menyiapkan penyebaran yang berhasil. Pertimbangkan komunitas berikut:

Langkah berikutnya

Pelajari selengkapnya tentang teknologi komponen:

Jelajahi arsitektur terkait: