Edit

Bagikan melalui

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

Azure
Azure Virtual Machines

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

Sistem

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 berikut menunjukkan arsitektur referensi untuk SAP Hana di Azure:

Diagram yang memperlihatkan arsitektur penyebaran regional.

Unduh file Visio yang berisi diagram dalam artikel ini.

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. 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 ExpressRoute yang disebarkan di hub topologi hub-spoke. Database SAP Hana 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 jaringan virtual yang sama tetapi dalam subnet aplikasi khusus. Atau, jika koneksi SAP Hana bukan database utama, VM aplikasi dapat ditemukan di jaringan virtual lainnya. Memisahkan menjadi subnet berdasarkan beban kerja memungkinkan pengaktifan grup keamanan jaringan (NSG) yang lebih mudah untuk menetapkan aturan keamanan yang berlaku hanya untuk VM SAP Hana.

Gateway zona redundan. Gateway menghubungkan jaringan yang berbeda, memperluas jaringan lokal Anda ke jaringan virtual Azure. Sebaiknya Anda menggunakan ExpressRoute untuk membuat koneksi privat yang tidak melalui internet publik, tetapi Anda juga dapat menggunakan koneksi site-to-site. Gunakan azure ExpressRoute atau gateway VPN zona-redundan untuk melindungi dari kegagalan zona. Lihat Gateway jaringan virtual zona-redundan untuk memahami perbedaan antara penyebaran zona dan penyebaran zona-redundan. Perlu disebutkan di sini bahwa 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 kelompok 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 terperindeks di dalam NSG Anda berdasarkan beban kerja yang berpusat pada aplikasi, gunakan grup keamanan aplikasi alih-alih alamat IP eksplisit. Mereka memungkinkan Anda mengelompokkan antarmuka jaringan VM berdasarkan nama dan membantu Anda mengamankan aplikasi dengan memfilter lalu lintas dari segmen tepercaya jaringan Anda.

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

Di Azure, tidak perlu menggunakan beberapa NIC karena alasan performa. Beberapa NIC berbagi batas throughput jaringan yang sama dari VM. 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.

Mesin virtual

Arsitektur ini menggunakan komputer virtual (VM). Azure menawarkan skala node tunggal hingga 23,5 Tebibyte (TiB) memori pada komputer virtual. 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 atau Edsv5 dengan RAM 160 GiB atau lebih. Untuk mendukung ukuran memori SAP Hana terbesar pada komputer virtual, sebanyak 30 TiB, Anda dapat menggunakan komputer virtual seri Mv3.

Komputer virtual Generasi 2 (Gen2). Saat menyebarkan VM, Anda dapat menggunakan VM generasi 1 atau generasi 2. VM Generasi 2 mendukung fitur utama yang tidak tersedia untuk VM generasi 1. Untuk SAP Hana, ini sangat penting karena beberapa keluarga VM, seperti Mv2 dan Mdsv2, hanya 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, kami sarankan Anda menyebarkan semua VM SAP hanya sebagai Gen2. Ini berlaku juga untuk VM dengan persyaratan memori rendah. Bahkan VM SAP Hana terkecil dapat berjalan sebagai VM Gen2 dan dapat, ketika dibatalkan alokasinya, diubah ukurannya menjadi VM terbesar yang tersedia di wilayah Anda.

Grup Penempatan Kedekatan (PPG). Ketika komputer virtual disebarkan di zona ketersediaan, latensi dalam zona biasanya ideal untuk hampir semua penggunaan SAP Hana. Untuk mengoptimalkan latensi jaringan lebih lanjut, Anda dapat menggunakan grup penempatan kedekatan. Ini 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 yang menciutkan SAP Hana dengan VM tingkat aplikasi. Karena potensi pembatasan dengan PPG, menambahkan database AvSet ke PPG sistem SAP harus dilakukan secara jarang dan hanya jika 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 mencakup beberapa zona ketersediaan.

Komponen

Pertimbangan

Bagian ini menjelaskan pertimbangan utama untuk menjalankan SAP Hana di Azure.

Skalabilitas

Arsitektur ini menjalankan SAP Hana pada komputer virtual yang dapat menskalakan hingga 30 TiB dalam satu instans.

Jika beban kerja Anda melebihi ukuran komputer virtual maksimum, kami sarankan Anda menggunakan konfigurasi HANA multi-simpul. Untuk aplikasi pemrosesan transaksi online (OLTP), total kapasitas memori peluasan skala dapat setingkat 4 x 30 TiB. Untuk aplikasi pemrosesan analitik online (OLAP), kapasitas memori peluasan skala dapat setingkat 16 x 15,2 TiB. 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, volume NFS Azure NetApp Files 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 penting dalam mencapai performa IO yang diperlukan.

Untuk disk log SAP Hana yang berjalan di Azure Premium SSD v1, gunakan salah satu teknologi berikut di lokasi yang menyimpan /hana/log untuk produksi:

Teknologi ini diperlukan untuk secara konsisten memenuhi latensi penyimpanan yang diperlukan kurang dari 1 mdtk.

Azure Premium SSD v2 dirancang untuk beban kerja kritis performa seperti SAP. Akselerator Tulis tidak diperlukan saat /hana/log berjalan pada SSD Premium v2. Untuk informasi tentang manfaat solusi penyimpanan ini dan batasan saat ini, lihat Menyebarkan SSD Premium v2.

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

  • Desain penyimpanan sadar biaya untuk sistem non-produksi. Untuk lingkungan SAP Hana yang tidak memerlukan performa penyimpanan maksimum dalam semua situasi, Anda dapat menggunakan arsitektur penyimpanan yang dioptimalkan untuk biaya. Pilihan pengoptimalan penyimpanan ini dapat berlaku untuk sistem produksi yang tidak banyak digunakan atau beberapa lingkungan SAP Hana non-produksi. Opsi penyimpanan yang dioptimalkan biaya menggunakan kombinasi SSD Standar alih-alih SSD Premium atau Ultra yang digunakan untuk lingkungan produksi. Ini juga menggabungkan sistem file /hana/data dan /hana/log ke satu set disk. Panduan dan praktik terbaik tersedia untuk sebagian besar ukuran VM. Jika Anda menggunakan Azure NetApp Files untuk SAP Hana, Anda dapat menggunakan volume berkurang ukuran untuk mencapai tujuan yang sama.

  • Mengubah ukuran penyimpanan saat meningkatkan skala. Saat Anda 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 Anda 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 dan disk yang mendasar.

  • Grup volume aplikasi Azure NetApp Files. Untuk penyebaran dengan file SAP Hana yang terdapat pada volume NFS Azure NetApp Files, grup volume aplikasi memungkinkan Anda 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. Ini membutuhkan intervensi manual. Izinkan beberapa waktu untuk pembuatan.

Ketersediaan tinggi

Arsitektur sebelumnya menggambarkan penyebaran yang sangat tersedia, dengan SAP Hana yang terkandung pada dua atau beberapa komputer virtual. Komponen berikut digunakan.

Load balancer. Azure 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. Penyeimbang SKU Dasar tidak mendukung redundansi zona dan tidak digunakan lagi. Dalam arsitektur ini, Load Balancer bertindak sebagai alamat IP virtual untuk SAP Hana. Lalu lintas jaringan dikirim ke VM aktif dengan instans database utama. Arsitektur aktif/baca-aktif SAP Hana tersedia secara opsional (SLES/RHEL) di mana IP virtual kedua yang ditujukan pada penyeimbang beban digunakan untuk mengarahkan lalu lintas jaringan ke instans SAP Hana sekunder pada VM lain untuk beban kerja baca-intens.

Load Balancer Standar menyediakan lapisan keamanan secara default. Komputer virtual yang berada di belakang Load Balancer Standar tidak memiliki konektivitas internet keluar. Untuk mengaktifkan internet keluar di komputer virtual ini, Anda perlu memperbarui konfigurasi Load Balancer Standar Anda. Selain itu, Anda juga dapat menggunakan Azure NAT Gateway untuk mendapatkan konektivitas keluar.

Untuk kluster database SAP Hana, Anda harus mengaktifkan Direct Server Return (DSR), juga dikenal sebagai IP mengambang. Fitur ini memungkinkan server merespons dengan alamat IP front end load balancer.

Opsi penyebaran. Di Azure, penyebaran beban kerja SAP dapat berupa regional atau zonal, tergantung pada persyaratan ketersediaan dan ketahanan aplikasi SAP. Azure menyediakan opsi penyebaran yang berbeda, seperti Virtual Machine Scale Sets dengan orkestrasi Fleksibel (FD=1), zona ketersediaan, dan set ketersediaan, untuk meningkatkan ketersediaan sumber daya. Untuk mendapatkan pemahaman komprehensif tentang opsi penyebaran yang tersedia dan penerapannya di berbagai wilayah Azure (termasuk di seluruh zona, dalam satu zona, atau di wilayah tanpa zona), lihat Arsitektur dan skenario ketersediaan tinggi untuk SAP NetWeaver.

SAP Hana. Untuk ketersediaan tinggi, SAP HANA berjalan pada dua atau beberapa mesin 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, Anda perlu memutuskan mekanisme anggar kluster mana yang akan 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), Anda dapat menggunakan agen pagar Azure atau Perangkat Blok STONITH (SBD). Bandingkan waktu failover untuk setiap solusi dan, jika ada perbedaan, pilih solusi berdasarkan persyaratan bisnis Anda untuk tujuan waktu pemulihan (RTO).

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

SBD. Perangkat blok STONITH (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 menjalankan SAP Hana mengakses disk SDB dan membaca/menulis secara berkala kepada mereka bit kecil informasi tentang status. Dengan demikian setiap node kluster mengetahui 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 cukup tersedia jika terjadi waktu henti yang direncanakan atau tidak direncanakan untuk 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 dari bencana

Arsitektur berikut menunjukkan lingkungan HANA produksi di Azure yang menyediakan pemulihan bencana. Arsitektur menggabungkan zona ketersediaan.

Diagram yang memperlihatkan arsitektur dengan pemulihan bencana.

Untuk strategi DR dan detail implementasi, lihat Gambaran umum pemulihan bencana dan panduan infrastruktur untuk beban kerja SAP dan Panduan pemulihan bencana untuk aplikasi SAP.

Catatan

Jika ada bencana regional yang menyebabkan peristiwa failover besar bagi banyak pelanggan Azure di satu wilayah, kapasitas sumber daya wilayah target tidak dijamin. Seperti semua layanan Azure, Azure Site Recovery terus menambahkan fitur dan kemampuan. Untuk informasi terbaru tentang replikasi Azure-ke-Azure, lihat matriks dukungan.

Selain implementasi ketersediaan tinggi dua node lokal, HSR mendukung replikasi multitier dan multitarget . Oleh karena itu, HSR mendukung replikasi antar-zona dan antar-wilayah. Replikasi multitarget tersedia untuk SAP HANA 2.0 Microsoft SharePoint Server 03 dan yang lebih baru.

Pastikan untuk memverifikasi kapasitas sumber daya wilayah target Anda.

Azure NetApp Files. Sebagai opsi, Azure NetApp Files dapat digunakan untuk menyediakan solusi penyimpanan yang skalabel dan berperforma 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, Replikasi Lintas Wilayah Azure NetApp Files 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/backup. 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 yang 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 aplikasi SAP yang berjalan di SAP Hana dan solusi database utama lainnya, lihat Azure Monitor untuk solusi SAP untuk mempelajari bagaimana Azure Monitor untuk SAP dapat membantu Anda mengelola ketersediaan dan performa layanan SAP.

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: Gunakan Enkripsi Data Transparan yang ditawarkan oleh penyedia DBMS (misalnya, teknologi enkripsi asli SAP Hana) untuk membantu mengamankan data dan file log Anda dan untuk memastikan cadangan juga dienkripsi.

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

  • Untuk informasi tentang dukungan Azure Disk Encryption pada distro, versi, dan gambar Linux tertentu, lihat Azure Disk Encryption untuk VM Linux.

Catatan

Jangan gabungkan teknologi enkripsi asli SAP Hana dengan Azure Disk Encryption atau Host Based Encryption pada volume penyimpanan yang sama. Selain itu, disk boot sistem operasi untuk komputer virtual Linux tidak mendukung Azure Disk Encryption. Sebagai gantinya, saat Anda menggunakan enkripsi asli SAP Hana, gabungkan dengan Enkripsi Sisi Server, 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 paling sedikit, menggunakan RBAC untuk menetapkan hak istimewa administratif di sumber daya tingkat IaaS yang menghosting solusi SAP Anda di Azure. Tujuan mendasar RBAC adalah pemisahan dan kontrol tugas untuk pengguna/grup Anda. RBAC dirancang untuk hanya memberikan jumlah akses ke sumber daya yang diperlukan untuk memungkinkan pengguna melakukan pekerjaan mereka.

  • Gunakan kunci sumber daya untuk membantu mencegah perubahan yang tidak disengaja atau berbahaya. Kunci sumber daya membantu mencegah administrator menghapus atau memodifikasi sumber daya Azure penting tempat 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:

Kontributor

Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.

Penulis utama:

Untuk melihat profil LinkedIn non-publik, masuk ke LinkedIn.

Langkah berikutnya

Pelajari selengkapnya tentang teknologi komponen:

Jelajahi arsitektur terkait: