Jalankan SAP Hana di Azure (Instans Besar)

Arsitektur referensi ini menunjukkan serangkaian praktik yang telah terbukti untuk menjalankan SAP HANA di Azure (Instans Besar) dengan ketersediaan tinggi (HA) dan pemulihan bencana (DR). Disebut Instans Besar HANA (HLI), penawaran ini digunakan di server fisik di wilayah Azure. Solusi ini menggambarkan skenario peningkatan skala sederhana untuk menunjukkan konsep inti dalam penyebaran dan pengoperasian sistem SAP Hana di Azure. Untuk opsi, lihat skenario instalasi lain untuk Instans Besar HANA.

Sistem

Unduh file Visio arsitektur ini.

Alur kerja

Arsitektur ini terdiri dari komponen infrastruktur berikut.

• Jaringan virtual. Layanan Azure Virtual Network (VNet) dengan aman menghubungkan sumber daya Azure satu sama lain dan dibagi menjadi subnet terpisah untuk setiap lapisan. Lapisan aplikasi SAP disebarkan pada Microsoft Azure Virtual Machines (VM) untuk terhubung ke lapisan database HANA yang berada pada instans besar.

• Jaringan HLI Revisi 4.5. Pada Juli 2021, revisi HLI Rev 4 yang diperbarui tersedia. Implementasi yang diperbarui [rev4.5] ini mencakup banyak peningkatan dalam infrastruktur, seperti jaringan 100Gb/dtk untuk penyimpanan NFS dan redundansi jaringan server DB yang lebih baik. Dalam desain ini, server HLI disebarkan di pusat data Azure dalam jarak fisik yang dekat dengan Azure VM tempat server aplikasi SAP berjalan. Ketika digunakan bersama dengan konfigurasi [ExpressRoute FastPath][fastpath], Rev 4.5 meningkatkan performa aplikasi. Fitur jaringan ini juga mendukung penyebaran Rev 3 dan Rev 4.

• Mesin virtual (VM). VM digunakan dalam lapisan aplikasi SAP dan lapisan layanan bersama. Yang terakhir termasuk jump box yang digunakan oleh administrator untuk mengatur Instans Besar HANA dan untuk menyediakan akses ke VM lainnya. Untuk mendekatkan warna server aplikasi SAP di pusat data yang sama dengan unit Instans Besar HANA, gunakan grup penempatan kedekatan.

• HANA Large Instance. Server fisik ini disertifikasi untuk memenuhi standar SAP HANA Tailored Datacenter Integration (TDI) untuk menjalankan SAP HANA. Arsitektur ini menggunakan dua HANA Large Instance: unit komputasi primer dan sekunder. Ketersediaan tinggi pada lapisan data disediakan melalui HANA System Replication (HSR).

• Pasangan Ketersediaan Tinggi. Sekelompok bilah Instans Besar HANA dikelola bersama untuk menyediakan redundansi dan keandalan database.

• Microsoft Enterprise Edge (MSEE). MSEE adalah titik koneksi dari penyedia konektivitas atau tepi jaringan Anda melalui sirkuit ExpressRoute.

• Kartu antarmuka jaringan (NIC). Untuk mengaktifkan komunikasi, server HANA Large Instance menyediakan empat NIC virtual secara default. Arsitektur ini membutuhkan satu NIC untuk komunikasi klien, NIC kedua untuk konektivitas node-to-node yang diperlukan oleh HSR, NIC ketiga untuk penyimpanan HANA Large Instance, dan keempat untuk iSCSI yang digunakan dalam kluster ketersediaan tinggi.

• Penyimpanan Network File System (NFS). Server NFS mendukung berbagi file jaringan yang menyediakan kegigihan data yang aman untuk Instans Besar HANA.

• ExpressRoute. ExpressRoute adalah layanan jaringan Azure yang direkomendasikan untuk membuat koneksi pribadi antara jaringan lokal dan Azure VNets yang tidak melalui internet publik. Azure VM terhubung ke HANA Large Instance menggunakan koneksi ExpressRoute lainnya. Koneksi ExpressRoute antara Azure VNet dan Instans Besar HANA disiapkan sebagai bagian dari penawaran Microsoft.

• Gateway. Gateway ExpressRoute digunakan untuk menghubungkan Azure VNet yang digunakan untuk lapisan aplikasi SAP ke jaringan Instans Besar Hana. Gunakan SKU Kinerja Tinggi atau Kinerja Ultra.

• Pemulihan bencana (DR). Opsi untuk DR termasuk HANA System Replication (HSR), backup dan restore file HANA, atau replikasi penyimpanan. Berdasarkan permintaan, tim Manajemen Layanan Microsoft dapat mengonfigurasi server dan volume penyimpanan. Anda bertanggung jawab untuk menjadwalkan snapshot penyimpanan, menguji sistem, dan membiasakan diri dengan proses pemulihan. Pertimbangan lain berlaku untuk tingkat aplikasi untuk SAP NetWeaver dan SAP S/4HANA di Azure.

Rekomendasi

Persyaratan dapat bervariasi, jadi gunakan rekomendasi ini sebagai titik awal.

Komputasi Instans Besar HANA

Instans Besar HANA adalah server fisik berdasarkan arsitektur CPU Intel Broadwell dan Cascade Lake dan dikonfigurasi dalam stempel instans besar—yaitu satu set server atau bilah tertentu. Unit komputasi sama dengan satu server atau blade, dan stempel terdiri dari beberapa server atau bilah. Dalam stempel instans besar, server tidak dibagikan dan didedikasikan untuk menjalankan penyebaran SAP Hana oleh satu pelanggan.

Berbagai SKU tersedia untuk Instans Besar HANA, mendukung memori instans tunggal hingga 24 TB (skala 120 TB) untuk BW/4HANA atau beban kerja SAP HANA lainnya.

Pilih SKU yang memenuhi persyaratan ukuran yang Anda tentukan dalam arsitektur dan sesi desain Anda. Selalu pastikan ukuran Anda berlaku untuk SKU yang benar. Kemampuan dan persyaratan penerapan bervariasi menurut jenis, dan ketersediaan bervariasi menurut wilayah. Anda juga dapat melangkah dari satu SKU ke SKU yang lebih besar.

Microsoft membantu menetapkan penyiapan instans besar, tetapi Anda bertanggung jawab untuk memverifikasi pengaturan konfigurasi sistem operasi. Pastikan untuk meninjau SAP Notes terbaru untuk rilis Linux Anda yang tepat.

Penyimpanan

Tata letak penyimpanan diimplementasikan sesuai dengan rekomendasi TDI untuk SAP HANA. Instans Besar HANA dilengkapi dengan konfigurasi penyimpanan tertentu untuk spesifikasi TDI standar. Namun, Anda dapat membeli penyimpanan tambahan dengan kenaikan 1 TB.

Untuk mendukung persyaratan lingkungan yang penting untuk misi termasuk pemulihan cepat, NFS digunakan dan bukan penyimpanan yang terpasang langsung. Server penyimpanan NFS untuk Instans Besar HANA dihosting di lingkungan multipenyewa, yang mana penyewa dipisahkan dan diamankan menggunakan isolasi komputasi, jaringan, dan penyimpanan.

Untuk mendukung ketersediaan tinggi di situs utama, gunakan tata letak penyimpanan yang berbeda. Misalnya, dalam skala multihost, penyimpanan dibagikan. Opsi ketersediaan tinggi lainnya adalah replikasi berbasis aplikasi, seperti HSR. Namun, untuk DR, replikasi penyimpanan berbasis rekam jepret digunakan.

Jaringan

Arsitektur ini menggunakan jaringan virtual dan fisik. Jaringan virtual adalah bagian dari infrastruktur Azure sebagai layanan (IaaS) dan terhubung ke jaringan fisik Instans Besar HANA diskrit melalui sirkuit ExpressRoute. Gateway lintas tempat menghubungkan beban kerja Anda di Azure VNet ke situs lokal Anda.

Semua penerapan Instans Besar Hana sejak Juli 2019 menggunakan stempel Rev 4, yang digunakan di dekat host Azure VM yang digunakan untuk server aplikasi SAP. Akibatnya, penyebaran Rev 4 meminimalkan latensi jaringan antara lapisan aplikasi dan database.

Jaringan Instans Besar HANA diisolasi satu sama lain untuk keamanan. Instans yang berada di wilayah yang berbeda tidak berkomunikasi satu sama lain, kecuali untuk replikasi penyimpanan khusus. Namun, untuk menggunakan HSR, diperlukan komunikasi antar wilayah. [Azure Global Reach] [globalreach], tabel perutean IP, atau proxy dapat digunakan untuk mengaktifkan HSR lintas wilayah.

Semua Azure VNet yang terhubung ke Instans Besar HANA di satu wilayah dapat terhubung silang melalui ExpressRoute ke Instans Besar HANA di wilayah sekunder.

Rangkaian ExpressRoute untuk Instans Besar HANA disertakan secara default selama penyediaan. Untuk penyiapan, tata letak jaringan tertentu diperlukan, termasuk rentang alamat Classless Inter-Domain Routing (CIDR) yang diperlukan dan perutean domain. Untuk detailnya, lihat Infrastruktur dan konektivitas SAP HANA (instans besar) di Azure.

Untuk menurunkan latensi jaringan dan meningkatkan kinerja, pertimbangkan untuk mengaktifkan FastPath (juga disebut sebagai MSEE v2). Konfigurasi jaringan ini memungkinkan lalu lintas dari lokal ke Azure VNet, dan dari VNet ke Instans Besar HANA, untuk melewati gateway Azure.

Pertimbangan

Skalabilitas

Untuk meningkatkan atau menurunkan skala, Anda dapat memilih dari berbagai ukuran server yang tersedia untuk HANA Large Instances. Semua dikategorikan sebagai Tipe I dan Tipe II dan disesuaikan untuk beban kerja yang berbeda. Pilih ukuran yang dapat bertambah dengan beban kerja Anda selama tiga tahun ke depan. Komitmen satu tahun juga tersedia.

Penyebaran peluasan skala multi-host umumnya digunakan untuk penyebaran BW/4HANA sebagai jenis dari strategi partisi database. Pada tulisan ini, BW/4HANA pada Instans Besar HANA dapat ditingkatkan menjadi 120 TB. Untuk meluaskan skala, rencanakan penempatan tabel HANA sebelum penginstalan. Dari sudut pandang infrastruktur, beberapa host terhubung ke volume penyimpanan bersama, memungkinkan pengambilalihan dengan cepat oleh host siaga jika salah satu node pekerja komputasi dalam sistem HANA gagal.

S/4HANA dan SAP Business Suite pada HANA pada satu bilah dapat menskalakan hingga 24 TB dengan simpul instans tunggal. Instans Besar HANA dan infrastruktur penyimpanan Azure juga mendukung penyebaran skala S/4HANA dan BW/4HANA. Untuk SKU khusus yang disertifikasi untuk scale-out, silakan berkonsultasi dengan [direktori perangkat keras bersertifikat SAP][direktori].

Persyaratan memori untuk HANA meningkat seiring dengan pertumbuhan volume data. Gunakan konsumsi memori sistem Anda saat ini sebagai dasar untuk memprediksi konsumsi di masa depan, lalu petakan permintaan Anda ke salah satu Instans Besar Hana.

Jika Anda telah memiliki penyebaran SAP, SAP memberikan laporan yang dapat Anda gunakan untuk memeriksa data yang digunakan oleh sistem yang ada serta menghitung persyaratan memori untuk instans HANA. Misalnya, lihat Catatan SAP berikut (akses memerlukan akun SAP Service Marketplace):

• Catatan SAP 1793345 - Pengukuran Ukuran untuk SAP Suite di HANA
• Catatan SAP 1872170 - Laporan pengukuran ukuran Suite di HANA dan S/4 HANA
• Catatan SAP 2121330 - FAQ: SAP BW di Laporan Pengukuran HANA
• Catatan SAP 1736976 - Laporan Pengukuran untuk BW di HANA
• Catatan SAP 2296290 - Laporan Pengukuran Baru untuk BW di HANA

Ketersediaan

Redundansi sumber daya adalah tema umum dalam solusi infrastruktur dengan ketersediaan tinggi. Bekerja dengan SAP, integrator sistem Anda, atau Microsoftuntuk merancang dan menerapkan strategi ketersediaan tinggi dan pemulihan bencana. Arsitektur ini mengikuti perjanjian tingkat layanan Azure (SLA) untuk HANA di Azure (Instans Besar). Untuk menilai persyaratan ketersediaan Anda, pertimbangkan satu titik kegagalan, tingkat waktu aktif yang diinginkan untuk layanan, dan metrik umum ini:

• Recovery Time Objective (RTO) berarti durasi waktu di mana server Instans Besar HANA tidak tersedia.

• Recovery Point Objective (RPO) berarti periode maksimum yang dapat ditoleransi di mana data pelanggan mungkin hilang karena kegagalan.

Untuk ketersediaan tinggi, sebarkan lebih dari satu instans dalam pasangan HA dan gunakan HSR dalam mode sinkron untuk meminimalkan kehilangan data dan waktu henti. Selain pengaturan ketersediaan tinggi lokal, dua-simpul, HSR mendukung replikasi multi-tier, di mana simpul ketiga dalam wilayah Azure yang terpisah mendaftar ke replika sekunder dari pasangan HSR yang dikelompokkan sebagai target replikasi. Ini membentuk replikasi rantai daisy.

Failover ke simpul DR adalah proses manual tanpa pengelompokan Linux. Untuk deteksi kesalahan otomatis dan failover, Anda dapat mengkonfigurasi Pacemaker untuk lebih menurunkan waktu henti yang disebabkan oleh kegagalan perangkat lunak atau perangkat keras. Dimulai dengan HANA 2.0 SPS 04, HSR juga mendukung replikasi multi-target. Alih-alih rantai daisy, bentuk replikasi ini memiliki satu pelanggan primer dan beberapa pelanggan sekunder.

Saat menyiapkan HSR Instans Besar HANA dengan failover otomatis, Anda dapat meminta tim Microsoft Service Management untuk menyiapkan perangkat STONITH untuk server Instans Besar HANA Anda.

Pemulihan dari bencana

Arsitektur ini mendukung pemulihan bencana antara Instans Besar HANA di berbagai wilayah Azure. Ada dua cara untuk mendukung DR dengan Instans Besar HANA:

• Replikasi Azure Storage. Konten penyimpanan utama terus-menerus direplikasi ke sistem penyimpanan DR jarak jauh yang tersedia di server Instans Besar DR HANA yang ditunjuk. Dalam replikasi penyimpanan, database HANA tidak dimuat ke dalam memori. Opsi DR ini lebih sederhana dari perspektif administrasi. Untuk menentukan apakah ini adalah strategi yang sesuai, pertimbangkan waktu pemuatan database terhadap ketersediaan SLA. Replikasi penyimpanan juga memungkinkan Anda untuk melakukan pemulihan sewaktu-waktu. Jika DR multiguna (dioptimalkan biaya) disiapkan, Anda harus membeli penyimpanan tambahan dengan ukuran yang sama di lokasi DR. Microsoft menyediakan salinan bayangan penyimpanan layanan mandiri dan skrip failover untuk failover HANA sebagai bagian dari penawaran Instans Besar HANA.

• Multi-tier atau multi-target HSR dengan replika ketiga di wilayah DR (di mana database HANA dimuat ke memori). Opsi ini mendukung waktu pemulihan yang lebih cepat tetapi tidak mendukung pemulihan sewaktu-waktu. HSR membutuhkan sistem sekunder. Lalu lintas replikasi sistem HANA yang ditujukan untuk situs DR dapat dialihkan melalui proxy seperti nginx atau tabel IP. Atau, Global Reach dapat digunakan untuk menghubungkan sirkuit ExpressRoute bersama-sama, memungkinkan pengguna yang diizinkan untuk terhubung ke unit Instans Besar HANA secara langsung.

Pengoptimalan biaya

Gunakan kalkulator harga Azure untuk memperkirakan biaya.

Untuk informasi selengkapnya, lihat bagian biaya di Microsoft Azure Well-Architected Framework.

SKU dapat memengaruhi model penagihan. Berikut adalah beberapa pertimbangan biaya.

Mesin virtual

Dalam arsitektur referensi ini, mesin virtual digunakan untuk menghosting aplikasi SAP, layanan SAP, dan layanan bersama seperti kotak lompatan manajemen. Ada SKU bersertifikat tertentu dari Instans Besar HANA. Konfigurasi tergantung pada beban kerja, sumber daya CPU, memori yang diinginkan, dan anggaran.

SKU Instance Besar HANA tersedia sebagai instans VM yang dipesan. Azure Reservations dapat menurunkan biaya Anda jika Anda dapat berkomitmen untuk jangka waktu satu tahun atau tiga tahun. Reservasi VM dapat mengurangi biaya hingga 72 persen saat dibandingkan dengan harga prabayar. Anda mendapatkan infrastruktur SAP HANA yang dibuat khusus dengan komputasi, penyimpanan, dan jaringan. Instans Besar HANA digabungkan dengan penyimpanan dan jaringan NFS dan menyediakan dukungan bawaan untuk pencadangan melalui snapshot penyimpanan, ketersediaan tinggi dan pemulihan bencana serta konfigurasi scale-out. Jika beban kerja tidak memiliki waktu penyelesaian atau konsumsi sumber daya yang dapat diprediksi, pertimbangkan opsi prabayar.

Gunakan gambaran umum paket penghematan Azure dan gabungkan dengan Reservasi Azure. Paket penghematan Azure adalah paket hemat biaya fleksibel yang menghasilkan penghematan harga bayar sesuai penggunaan yang signifikan. Anda menyetujui kontrak satu tahun atau tiga tahun dan menerima diskon untuk layanan komputasi yang memenuhi syarat. Penghematan berlaku untuk layanan komputasi ini terlepas dari wilayah, ukuran instans, atau sistem operasi. Untuk informasi selengkapnya, lihat Dokumentasi paket penghematan Azure.

Gunakan VM Azure Spot untuk menjalankan beban kerja yang dapat diinterupsi dan tidak memerlukan penyelesaian dalam jangka waktu atau SLA yang telah ditentukan sebelumnya.

Untuk informasi selengkapnya, lihat bagian "SAP HANA di Instans Besar Azure" di HLI untuk Harga Mesin Virtual SAP HANA.

Azure ExpressRoute

Untuk arsitektur ini, Azure ExpressRoute digunakan sebagai layanan jaringan untuk membuat koneksi privat antara jaringan lokal dan jaringan virtual Azure. Azure VM terhubung ke Instans Besar HANA menggunakan koneksi ExpressRoute lain dan Gateway ExpressRoute. High Performance atau Ultra Performance adalah SKU yang direkomendasikan.

Semua transfer data masuk gratis. Semua transfer data keluar dikenakan biaya berdasarkan tarif yang telah ditentukan. Untuk informasi selengkapnya, lihat Harga Azure ExpressRoute.

Cadangan

Berdasarkan kebutuhan bisnis Anda, pilih dari beberapa opsi yang tersedia.

Untuk detail tentang pendekatan do-it-yourself untuk mencadangkan dan lebih banyak opsi yang disediakan dengan Instans Besar HANA, lihat artikel [Pencadangan dan pemulihan][backup-restore].

Keterkelolaan

Pantau sumber daya Instans Besar HANA—seperti CPU, memori, bandwidth jaringan, dan ruang penyimpanan—menggunakan SAP HANA Studio, SAP HANA Cockpit, SAP Solution Manager, dan alat Linux asli lainnya. SKU Tipe I Instans Besar HANA tidak dilengkapi dengan alat pemantauan bawaan. SKU Tipe II menawarkan alat diagnostik bawaan untuk pencatatan aktivitas sistem dan pemecahan masalah.

Microsoft menawarkan alat dan sumber daya dasar untuk membantu Anda memantau Instans Besar HANA di Azure. Tim dukungan Microsoft juga dapat membantu Anda dalam memecahkan masalah teknis.

Keamanan

• Sejak akhir 2018, penyimpanan Instans Besar HANA dienkripsi secara default.

• Data yang transit antara Instans Besar HANA dan VM tidak dienkripsi. Untuk mengenkripsi transfer data, aktifkan enkripsi khusus aplikasi. Lihat Catatan SAP 2159014 - FAQ: Keamanan SAP HANA.

• Isolasi memberikan keamanan antara penyewa di lingkungan multi-penyewa Instans Besar Hana. Penyewa diisolasi menggunakan VLAN mereka sendiri.

• Praktik terbaik keamanan jaringan Azure memberikan panduan yang bermanfaat.

• Seperti halnya penyebaran apa pun, pengerasan sistem operasi dianjurkan, termasuk pengerasan gambar SUSE Linux untuk SAP di Azure.

• Untuk keamanan fisik, akses ke pusat data Azure hanya terbatas pada personel yang berwenang. Tidak ada pelanggan yang dapat mengakses server fisik.

Untuk informasi selengkapnya, lihat Keamanan SAP HANA—Ringkasan. (Diperlukan akun SAP Service Marketplace untuk mengaksesnya.)

Komunitas

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

• Menjalankan Aplikasi SAP di Blog Platform Microsoft
• SAP Stack Overflow

Kontributor

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

Penulis utama:

• Ben Trinh | Arsitek Utama

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

Sumber daya terkait

Anda mungkin ingin meninjau skenario contoh Azure berikut yang menunjukkan solusi tertentu menggunakan beberapa teknologi yang sama:

• Menjalankan beban kerja produksi SAP menggunakan Oracle Database di Azure