Konfigurasi dan operasi infrastruktur SAP Hana di Azure
Dokumen ini memberikan panduan untuk mengonfigurasi infrastruktur Azure dan mengoperasikan sistem SAP Hana yang disebarkan pada komputer virtual (VM) asli Azure. Dokumen tersebut juga mencakup informasi konfigurasi untuk peluasan skala SAP Hana untuk SKU VM M128s. Dokumen ini tidak dimaksudkan untuk menggantikan dokumentasi SAP standar, yang mencakup konten berikut:
Prasyarat
Untuk menggunakan panduan ini, Anda memerlukan pengetahuan dasar tentang komponen Azure berikut:
Untuk mempelajari lebih lanjut tentang SAP NetWeaver dan komponen SAP lainnya di Azure, lihat bagian SAP di Azure dari dokumentasi Azure.
Pertimbangan persiapan dasar
Bagian berikut menjelaskan pertimbangan persiapan dasar untuk menyebarkan sistem SAP Hana pada VM Azure.
Menyambungkan ke komputer virtual Azure
Seperti yang didokumentasikan dalam panduan perencanaan komputer virtual Azure, ada dua metode dasar untuk menyambungkan ke VM Azure:
- Tersambung melalui internet dan titik akhir publik di VM Jump atau di VM yang menjalankan SAP Hana.
- Tersambung melalui VPN atau Azure ExpressRoute.
Konektivitas situs-ke-situs melalui VPN atau ExpressRoute diperlukan untuk skenario produksi. Jenis koneksi ini juga diperlukan untuk skenario non-produksi yang dimasukkan ke dalam skenario produksi tempat perangkat lunak SAP digunakan. Gambar berikut menunjukkan contoh konektivitas lintas situs:
Pilih jenis VM Azure
SAP mencantumkan jenis VM Azure yang dapat Anda gunakan untuk skenario produksi. Untuk skenario non-produksi, tersedia lebih banyak variasi jenis VM Azure asli.
Catatan
Untuk skenario non-produksi, gunakan jenis VM yang dicantumkan di catatan SAP #1928533. Untuk penggunaan VM Azure untuk skenario produksi, periksa VM bersertifikat SAP Hana di daftar Platform IaaS Bersertifikat yang diterbitkan SAP.
Sebarkan VM di Azure dengan menggunakan:
- Portal Microsoft Azure.
- cmdlet Azure PowerShell.
- Azure CLI.
Penting
Untuk menggunakan Mesin Virtual M208xx_v2, Anda harus berhati-hati saat memilih gambar Linux. Untuk detail selengkapnya, lihat Ukuran mesin virtual yang dioptimalkan memori.
Konfigurasi penyimpanan untuk SAP Hana
Untuk konfigurasi penyimpanan dan jenis penyimpanan yang akan digunakan dengan SAP Hana di Azure, baca dokumen Konfigurasi penyimpanan komputer virtual Azure SAP Hana
Menyiapkan jaringan virtual Azure
Saat memiliki konektivitas situs-ke-situs ke Azure melalui VPN atau ExpressRoute, Anda harus memiliki setidaknya satu jaringan virtual Azure yang tersambung melalui Gateway Virtual ke sirkuit VPN atau ExpressRoute. Dalam penyebaran sederhana, Gateway Virtual dapat disebarkan di subnet jaringan virtual Azure (VNet) yang juga menghosting instans SAP Hana. Untuk memasang SAP Hana, Anda membuat dua subnet tambahan dalam jaringan virtual Azure. Satu subnet menghosting VM untuk menjalankan instans SAP Hana. Subnet lainnya menjalankan Jumpbox atau VM Manajemen untuk menghosting Studio SAP Hana, perangkat lunak manajemen lainnya, atau perangkat lunak aplikasi Anda.
Penting
Di luar fungsionalitas, tetapi lebih penting karena alasan performa, tidak didukung untuk mengonfigurasi Appliance Virtual Jaringan Azure di jalur komunikasi antara aplikasi SAP dan lapisan DBMS dari SAP NetWeaver, Hybris, atau S/4HANA berbasis sistem SAP. Komunikasi antara lapisan aplikasi SAP dan lapisan DBMS harus bersifat langsung. Pembatasan tidak termasuk aturan ASG dan NSG Azure selama aturan ASG dan NSG tersebut memungkinkan komunikasi langsung. Skenario lebih lanjut di mana NVA tidak didukung berada di jalur komunikasi antara VM Azure yang mewakili node kluster Linux Pacemaker dan perangkat SBD seperti yang dijelaskan dalam Ketersediaan tinggi untuk SAP NetWeaver pada VM Azure di Server SUSE Linux Enterprise untuk aplikasi SAP. Atau dalam jalur komunikasi antara VM Azure dan SOFS Windows Server yang disiapkan seperti yang dijelaskan dalam Mengelompokkan instans SAP ASCS/SCS pada kluster failover Windows dengan menggunakan berbagi di Azure. NVA di jalur komunikasi dapat dengan mudah menggandakan latensi jaringan antara dua mitra komunikasi, dapat membatasi throughput di jalur kritis antara lapisan aplikasi SAP dan lapisan DBMS. Dalam beberapa skenario yang diamati dengan pelanggan, NVA dapat menyebabkan kluster Linux Pacemaker gagal dalam kasus di mana komunikasi antara node kluster Linux Pacemaker perlu berkomunikasi ke perangkat SBD melalui NVA.
Penting
Desain lain yang TIDAK didukung adalah pemisahan lapisan aplikasi SAP dan lapisan DBMS ke dalam jaringan virtual Azure yang berbeda yang tidak dikata sandingkan satu sama lain. Disarankan untuk memisahkan lapisan aplikasi SAP dan lapisan DBMS menggunakan subnet dalam jaringan virtual Azure daripada menggunakan jaringan virtual Azure yang berbeda. Jika Anda memutuskan untuk tidak mengikuti rekomendasi tersebut, dan malah memisahkan kedua lapisan tersebut ke dalam jaringan virtual yang berbeda, kedua jaringan virtual tersebut harus dikata sandinhkan. Ketahuilah bahwa lalu lintas antara dua jaringan virtual Azure yang dikata sandingkan dikenakan biaya transfer. Dengan volume data yang sangat besar dalam banyak Terabyte yang dipertukarkan antara lapisan aplikasi SAP dan lapisan DBMS, biaya besar dapat diakumulasikan jika lapisan aplikasi SAP dan lapisan DBMS dipisahkan antara dua jaringan virtual Azure yang di-peering.
Jika Anda menyebarkan Jumpbox atau VM manajemen di subnet terpisah, Anda dapat menentukan beberapa kartu antarmuka jaringan virtual (vNIC) untuk VM HANA, dengan setiap vNIC ditetapkan ke subnet yang berbeda. Dengan kemampuan untuk memiliki beberapa vNIC, Anda dapat mengatur pemisahan lalu lintas jaringan, jika perlu. Misalnya, lalu lintas klien dapat dirutekan melalui vNIC utama dan lalu lintas admin dirutekan melalui vNIC kedua.
Anda juga menetapkan alamat IP privat statis yang disebarkan untuk kedua NIC virtual.
Catatan
Anda harus menetapkan alamat IP statik melalui sarana Azure untuk masing-masing vNIC. Anda tidak boleh menetapkan alamat IP statik dalam OS tamu ke vNIC. Beberapa layanan Azure seperti Layanan Azure Backup bergantung pada fakta bahwa setidaknya vNIC utama diatur ke DHCP dan bukan ke alamat IP statik. Lihat juga dokumen Memecahkan masalah pencadangan mesin virtual Azure. Jika Anda perlu menetapkan beberapa alamat IP statik ke VM, Anda perlu menetapkan beberapa vNIC ke VM.
Namun, untuk penyebaran yang bertahan lama, Anda perlu membuat arsitektur jaringan pusat data virtual di Azure. Arsitektur ini menyarankan pemisahan VNet Gateway Azure yang tersambung ke lokal menjadi VNet Azure terpisah. VNet terpisah ini harus menghosting semua lalu lintas yang keluar baik ke lokal atau ke internet. Pendekatan ini memungkinkan Anda untuk menyebarkan perangkat lunak untuk audit dan pengelogan lalu lintas yang memasuki pusat data virtual di Azure di VNet hub yang terpisah ini. Jadi, Anda memiliki satu VNet yang menghosting semua perangkat lunak dan konfigurasi yang terkait dengan lalu lintas masuk dan keluar ke penyebaran Azure.
Artikel Pusat Data Virtual Azure: Perspektif Jaringan dan Pusat Data Virtual Azure serta Sarana Kontrol Perusahaan memberikan informasi lebih lanjut tentang pendekatan pusat data virtual dan desain VNet Azure terkait.
Catatan
Lalu lintas yang mengalir antara VNet hub dan VNet spoke menggunakan penyandingan VNet Azure dikenakan biaya tambahan. Berdasarkan biaya tersebut, Anda mungkin perlu mempertimbangkan untuk membuat kompromi antara menjalankan desain jaringan hub dan spoke yang ketat dan menjalankan beberapa Gateway Azure ExpressRoute yang Anda sambungkan ke 'spoke' untuk menghindari penyandingan VNet. Namun, Gateway Azure ExpressRoute juga menimbulkan biaya tambahan. Anda juga mungkin mengalami biaya tambahan untuk perangkat lunak pihak ketiga yang Anda gunakan untuk pengelogan lalu lintas, audit, dan pemantauan. Bergantung pada biaya pertukaran data melalui penyandingan VNet di satu sisi dan biaya yang ditimbulkan oleh Gateway Azure ExpressRoute tambahan dan lisensi perangkat lunak tambahan, Anda dapat memutuskan untuk segmentasi mikro dalam satu VNet dengan menggunakan subnet sebagai unit isolasi daripada VNet.
Untuk gambaran umum tentang berbagai metode untuk menetapkan alamat IP, lihat Jenis alamat IP dan metode alokasi di Azure.
Untuk VM yang menjalankan SAP Hana, Anda harus bekerja dengan alamat IP statik yang ditetapkan. Alasannya adalah bahwa beberapa atribut konfigurasi untuk alamat IP referensi HANA.
Kelompok Keamanan Jaringan Azure (NSGs) digunakan untuk mengarahkan lalu lintas yang dirutekan ke instans SAP Hana atau jumpbox. NSG dan akhirnya Kelompok Keamanan Aplikasi dikaitkan dengan subnet SAP Hana dan subnet Manajemen.
Untuk menyebarkan SAP Hana di Azure tanpa sambungan situs-ke-situs, Anda harus melindungi instans SAP Hana dari internet publik dan menyembunyikannya di balik proksi penerusan. Dalam skenario dasar ini, penyebaran bergantung pada layanan DNS bawaan Azure untuk menyelesaikan nama host. Dalam penyebaran yang lebih kompleks di mana alamat IP yang menghadap publik digunakan, layanan DNS bawaan Azure sangat penting. Gunakan NSG Azure dan NVA Azure untuk mengontrol, memantau perutean dari internet ke arsitektur VNet Azure Anda di Azure. Gambar berikut menunjukkan skema kasar untuk menyebarkan SAP Hana tanpa sambungan situs-ke-situs di arsitektur VNet hub dan spoke:
Deskripsi lain tentang cara menggunakan NVA Azure untuk mengontrol dan memantau akses dari internet tanpa arsitektur VNet hub and spoke dapat ditemukan di artikel Menyebarkan appliance virtual jaringan yang sangat tersedia.
Opsi sumber jam di Azure VM
SAP Hana membutuhkan informasi waktu yang andal dan akurat untuk berkinerja optimal. Secara tradisional Azure VM yang berjalan di hypervisor Azure hanya menggunakan halaman Hyper-V TSC sebagai sumber jam default. Kemajuan teknologi dalam perangkat keras, OS host, dan kernel OS tamu Linux memungkinkan untuk menyediakan "TSC Invarian" sebagai opsi sumber jam pada beberapa SKU Azure VM.
Halaman Hyper-V TSC (hyperv_clocksource_tsc_page
) didukung di semua Azure VM sebagai sumber jam.
Jika perangkat keras, hypervisor, dan kernel linux OS tamu mendukung TSC Invarian, tsc
akan ditawarkan sebagai sumber jam yang tersedia dan didukung di OS tamu di Azure VM.
Mengonfigurasi infrastruktur Azure untuk peluasan skala SAP Hana
Untuk mengetahui jenis VM Azure yang disertifikasi untuk peluasan skala OLAP atau peluasan skala S/4HANA, periksa direktori perangkat keras SAP Hana. Tanda centang di kolom 'Pengklusteran' menunjukkan dukungan peluasan skala. Jenis aplikasi menunjukkan apakah peluasan skala OLAP atau peluasan skala S/4HANA didukung. Untuk detail tentang simpul yang disertifikasi dalam peluasan skala, tinjau entri untuk SKU VM tertentu yang tercantum dalam direktori perangkat keras SAP Hana.
Rilis OS minimum untuk menyebarkan konfigurasi peluasan skala di VM Azure, periksa detail entri di SKU VM tertentu yang tercantum di direktori perangkat keras SAP Hana. Dari konfigurasi peluasan skala OLAP n-simpul, satu simpul berfungsi sebagai simpul utama. Simpul lain hingga batas sertifikasi bertindak sebagai simpul pekerja. Simpul siaga tambahan tidak dihitung dalam jumlah simpul bersertifikat
Catatan
Penyebaran peluasan skala VM Azure dari SAP Hana dengan simpul siaga hanya dimungkinkan menggunakan penyimpanan Azure NetApp Files. Tidak ada penyimpanan Azure bersertifikat SAP Hana lainnya yang memungkinkan konfigurasi simpul siaga SAP Hana
Untuk /hana/shared, kami merekomendasikan penggunaan Azure NetApp Files atau Azure Files.
Desain dasar yang khas untuk satu simpul dalam konfigurasi peluasan skala, dengan /hana/shared
disebarkan di Azure NetApp Files, terlihat seperti:
Konfigurasi dasar simpul VM untuk peluasan skala SAP Hana terlihat seperti:
- Untuk /hana/shared, Anda menggunakan layanan NFS asli yang disediakan melalui Azure NetApp Files atau Azure Files.
- Semua volume disk lainnya tidak dibagi di antara simpul yang berbeda dan tidak didasarkan pada NFS. Konfigurasi pengpasangan dan langkah-langkah untuk peluasan skala pengpasangan HANA dengan /hana/data dan /hana/log bukan berbagi disediakan lebih lanjut nanti dalam dokumen ini. Untuk penyimpanan bersertifikat HANA yang dapat digunakan, lihat artikel Konfigurasi penyimpanan komputer virtual Azure SAP Hana.
Mengukur volume atau disk, Anda perlu memeriksa dokumen Persyaratan Penyimpanan TDI SAP Hana, untuk ukuran yang diperlukan tergantung pada jumlah simpul pekerja. Dokumen merilis rumus yang perlu Anda terapkan untuk mendapatkan kapasitas volume yang diperlukan
Kriteria desain lain yang ditampilkan dalam grafik konfigurasi simpul tunggal untuk peluasan skala VM SAP Hana adalah VNet, atau konfigurasi subnet yang lebih baik. SAP sangat menyarankan pemisahan klien/aplikasi yang menghadap lalu lintas dari komunikasi antara simpul HANA. Seperti yang ditunjukkan pada grafik, tujuan ini dicapai dengan memiliki dua vNIC berbeda yang dilampirkan ke VM. Kedua vNIC berada di subnet yang berbeda, memiliki dua alamat IP yang berbeda. Anda kemudian mengontrol alur lalu lintas dengan aturan perutean menggunakan NSG atau rute yang ditentukan pengguna.
Khususnya di Azure, tidak ada cara dan metode untuk menerapkan kualitas layanan dan kuota pada vNIC tertentu. Akibatnya, pemisahan tampilan klien/aplikasi dan komunikasi intra-simpul tidak membuka peluang untuk memprioritaskan satu aliran lalu lintas di atas yang lain. Sebaliknya pemisahan tetap menjadi ukuran keamanan dalam melindungi komunikasi intra-simpul dari konfigurasi peluasan skala.
Catatan
SAP menyarankan untuk memisahkan lalu lintas ke sisi klien/aplikasi dan lalu lintas intra-simpul seperti yang dijelaskan dalam dokumen ini. Oleh karena itu menempatkan arsitektur pada tempatnya seperti yang ditunjukkan di grafik terakhir disarankan. Konsultasikan juga dengan tim keamanan dan kepatuhan Anda untuk persyaratan yang menyimpang dari rekomendasi
Dari sudut pandang jaringan, arsitektur jaringan minimum yang diperlukan akan terlihat seperti:
Memasang peluasan skala SAP Hana di Azure
Pasang konfigurasi SAP peluasan skala, Anda perlu melakukan langkah-langkah kasar:
- Menyebarkan yang baru atau mengadaptasi infrastruktur VNet Azure yang ada
- Menyebarkan VM baru menggunakan Penyimpanan Premium Terkelola Azure, volume disk Ultra, dan/atau volume NFS berdasarkan ANF
-
- Sesuaikan perutean jaringan untuk memastikan bahwa, misalnya, komunikasi intra-simpul antara VM tidak dirutekan melalui NVA.
- Pasang simpul utama SAP HANA.
- Sesuaikan parameter konfigurasi simpul utama SAP HANA
- Lanjutkan dengan pengpasangan simpul pekerja SAP Hana
Pengpasangan SAP Hana dalam konfigurasi peluasan skala
Saat infrastruktur VM Azure Anda disebarkan, dan semua persiapan lainnya telah selesai, Anda perlu memasang konfigurasi peluasan skala SAP Hana dalam langkah-langkah berikut:
- Pasang simpul utama SAP HANA sesuai dengan dokumentasi SAP
- Saat menggunakan Penyimpanan Premium Azure atau penyimpanan disk Ultra dengan disk tidak bersama dari
/hana/data
dan/hana/log
, tambahkan parameterbasepath_shared = no
keglobal.ini
file. Parameter ini memungkinkan SAP HANA berjalan dalam peluasan skala tanpa volume/hana/data
dan/hana/log
berbagi di antara simpul. Detail didokumentasikan dalam Catatan SAP #2080991. Jika Anda menggunakan volume NFS berdasarkan ANF untuk /hana/data dan /hana/log, Anda tidak perlu melakukan perubahan ini - Setelah perubahan pada parameter global.ini, hidupkan ulang instans SAP Hana
- Tambahkan lebih banyak node pekerja. Untuk informasi selengkapnya, lihat Menambahkan Host Menggunakan Antarmuka Command-Line. Tentukan jaringan internal untuk komunikasi antar-simpul SAP Hana selama pengpasangan atau setelahnya menggunakan, misalnya, hdblcm lokal. Untuk dokumentasi yang lebih detail, lihat Catatan SAP #2183363.
Untuk menyiapkan sistem peluasan skala SAP HANA dengan simpul siaga, lihat instruksi penyebaran SUSE Linux atau instruksi penyebaran Red Hat.
Tingkatan Dinamis SAP Hana 2.0 untuk komputer virtual Azure
Selain sertifikasi SAP Hana pada VM seri-M Azure, Tingkatan Dinamis SAP HANA 2.0 juga didukung di Microsoft Azure. Untuk informasi selengkapnya, lihat Tautan ke dokumentasi DT 2.0. Tidak ada perbedaan dalam menginstal atau mengoperasikan produk. Misalnya, Anda dapat menginstal Kokpit SAP HANA di dalam Azure VM. Namun, ada beberapa persyaratan wajib, seperti yang dijelaskan di bagian berikut, untuk dukungan resmi di Azure. Sepanjang artikel, singkatan "DT 2.0" akan digunakan sebagai ganti nama lengkap Tingkatan Dinamis 2.0.
SAP Hana Dynamic Tiering 2.0 tidak didukung oleh SAP Business Warehouse atau S4HANA. Kasus penggunaan utama saat ini adalah aplikasi HANA asli.
Gambaran Umum
Gambar di bawah ini memberikan gambaran umum tentang dukungan DT 2.0 pada Microsoft Azure. Ada serangkaian persyaratan wajib, yang harus diikuti untuk mematuhi sertifikasi resmi:
- DT 2.0 harus diinstal pada VM Azure khusus. Ini mungkin tidak berjalan pada VM yang sama di mana SAP Hana berjalan
- VM SAP Hana dan DT 2.0 harus digunakan dalam Azure Vnet yang sama
- VM SAP Hana dan DT 2.0 harus digunakan dengan jaringan akselerasi Azure diaktifkan
- Jenis penyimpanan untuk DT 2.0 VM harus Penyimpanan Premium Azure
- Beberapa disk Azure harus dilampirkan ke DT 2.0 VM
- Diperlukan untuk membuat serangan perangkat lunak / volume bergaris (baik melalui lvm atau mdadm) menggunakan striping di seluruh disk Azure
Lebih jelasnya akan dijelaskan pada bagian berikut.
VM Azure khusus untuk DT SAP Hana 2.0
Di IaaS Azure, DT 2.0 hanya didukung pada VM khusus. Tidak diperbolehkan menjalankan DT 2.0 pada VM Azure yang sama dengan tempat instans HANA dijalankan. Awalnya dua jenis VM dapat digunakan untuk menjalankan DT SAP Hana 2.0:
- M64-32ms
- E32sv3
Untuk informasi selengkapnya tentang deskripsi jenis VM, lihat Ukuran Azure VM - Memori
Mengingat ide dasar DT 2.0, yaitu tentang membongkar data "hangat" untuk menghemat biaya, masuk akal untuk menggunakan ukuran VM yang sesuai. Tidak ada aturan ketat mengenai kemungkinan kombinasi. Hal ini tergantung pada beban kerja pelanggan tertentu.
Konfigurasi yang disarankan adalah:
Tipe SAP Hana VM | Tipe DT 2.0 VM |
---|---|
M128ms | M64-32ms |
M128ms | M64-32ms |
M64ms | E32sv3 |
M64s | E32sv3 |
Semua kombinasi VM seri-M bersertifikasi SAP Hana dengan VM DT 2.0 yang didukung (M64-32ms dan E32sv3) dimungkinkan.
Jaringan Azure dan DT SAP Hana 2.0
Menginstal DT 2.0 pada VM khusus membutuhkan throughput jaringan antara DT 2.0 VM dan SAP Hana VM minimum 10 Gb. Oleh karena itu, wajib untuk menempatkan semua VM dalam Vnet Azure yang sama dan mengaktifkan jaringan akselerasi Azure.
Lihat informasi tambahan tentang jaringan akselerasi Azure Membuat Azure VM dengan Accelerated Networking menggunakan Azure CLI
Penyimpanan VM untuk DT SAP Hana 2.0
Menurut panduan praktik terbaik DT 2.0, throughput IO disk harus minimal 50 MB/detik per inti fisik.
Melihat spesifikasi untuk dua jenis VM Azure, yang didukung untuk DT 2.0, batas throughput IO disk maksimum untuk VM terlihat seperti:
- E32sv3: 768 MB/dtk (tidak disimpan) yang berarti rasio 48 MB/dtk per inti fisik
- M64-32ms : 1000 MB/dtk (tidak disimpan) yang berarti rasio 62,5 MB/dtk per inti fisik
Diperlukan untuk melampirkan beberapa disk Azure ke VM DT 2.0 dan membuat serangan perangkat lunak (striping) pada tingkat OS untuk mencapai batas maksimum throughput disk per VM. Disk Azure tunggal tidak dapat menyediakan throughput untuk mencapai batas VM maksimum dalam hal ini. Penyimpanan Premium Azure wajib untuk menjalankan DT 2.0.
- Detail tentang tipe disk Azure yang tersedia dapat ditemukan pada halaman Memilih tipe disk Azure IaaS VM - disk yang dikelola
- Detail mengenai membuat perangkat lunak raid melalui mdadm dapat ditemukan di halaman Mengonfigurasi perangkat lunak RAID pada Linux VM
- Rincian tentang mengonfigurasi LVM untuk membuat volume bergaris untuk throughput maksimum dapat ditemukan pada halaman Konfigurasi LVM pada mesin virtual yang menjalankan Linux
Bergantung pada persyaratan ukuran, ada berbagai opsi untuk mencapai throughput maksimum VM. Berikut adalah kemungkinan konfigurasi disk volume data untuk setiap jenis VM DT 2.0 untuk mencapai batas throughput VM atas. E32sv3 VM harus dianggap sebagai tingkat entri untuk beban kerja yang lebih kecil. Jika ternyata tidak cukup cepat, mungkin perlu mengubah ukuran VM ke M64-32ms. Karena VM M64-32ms memiliki banyak memori, beban IO mungkin tidak mencapai batas terutama untuk beban kerja intensif baca. Oleh karena itu lebih sedikit disk dalam set stripe mungkin cukup tergantung pada beban kerja spesifik pelanggan. Tetapi untuk amannya, konfigurasi disk di bawah ini dipilih untuk menjamin throughput maksimum:
VM SKU | Konfigurasi Cakram 1 | Konfigurasi Cakram 2 | Konfigurasi Cakram 3 | Konfigurasi Cakram 4 | Konfigurasi Cakram 5 |
---|---|---|---|---|---|
M64-32ms | 4 x P50 -> 16 TB | 4 x P40 -> 8 TB | 5 x P30 -> 5 TB | 7 x P20 -> 3,5 TB | 8 x P15 -> 2 TB |
E32sv3 | 3 x P50 -> 12 TB | 3 x P40 -> 6 TB | 4 x P30 -> 4 TB | 5 x P20 -> 2,5 TB | 6 x P15 -> 1,5 TB |
Terutama dalam kasus beban kerja baca-intensif dapat meningkatkan performa IO untuk mengaktifkan cache host Azure "baca-saja" seperti yang disarankan untuk volume data perangkat lunak database. Sedangkan untuk log transaksi cache disk host Azure harus “tidak ada”.
Mengenai ukuran volume log, titik awal yang disarankan adalah heuristik 15% dari ukuran data. Pembuatan volume log dapat dilakukan dengan menggunakan jenis disk Azure yang berbeda tergantung pada persyaratan biaya dan throughput. Untuk volume log, throughput I/O yang tinggi diperlukan.
Jika menggunakan jenis VM M64-32ms, wajib mengaktifkan Akselerator Tulis. Akselerator Tulis Azure menyediakan latensi penulisan disk yang optimal untuk log transaksi (hanya tersedia untuk seri-M). Ada beberapa item yang perlu dipertimbangkan seperti jumlah maksimum disk per jenis VM. Detail mengenai Tulis Akselerator dapat ditemukan di halaman Azure Write Accelerator
Berikut adalah beberapa contoh tentang ukuran volume log:
ukuran volume data dan jenis disk | volume log dan konfigurasi jenis disk 1 | volume log dan konfigurasi jenis disk 2 |
---|---|---|
4 x P50 -> 16 TB | 5 x P20 -> 2,5 TB | 3 x P30 -> 3 TB |
6 x P15 -> 1,5 TB | 4 x P6 -> 256 GB | 1 x P15 -> 256 GB |
Seperti untuk peluasan skala SAP Hana, direktori /hana/berbagi harus dibagi antara VM SAP Hana dan VM DT 2.0. Arsitektur yang sama seperti untuk peluasan skala SAP Hana menggunakan VM khusus, yang bertindak sebagai server NFS yang sangat tersedia disarankan. Untuk menyediakan volume cadangan berbagi, desain yang sama dapat digunakan. Tetapi terserah kepada pelanggan apakah ketersediaan tinggi akan diperlukan atau apakah cukup untuk hanya menggunakan VM khusus dengan kapasitas penyimpanan yang cukup untuk bertindak sebagai server cadangan.
Menautkan ke dokumentasi DT 2.0
- Panduan pengpasangan dan pembaruan Tingkatan Dinamis SAP HANA
- Tutorial dan sumber daya Tingkatan Dinamis SAP Hana
- PoC Tingkatan Dinamis SAP Hana
- Peningkatan tingkatan dinamis SAP Hana 2.0 SPS 02
Operasi untuk menyebarkan SAP Hana di VM Azure
Bagian berikut menjelaskan beberapa operasi yang terkait dengan penyebaran sistem SAP Hana di VM Azure.
Mencadangkan dan memulihkan operasi di VM Azure
Dokumen berikut menjelaskan cara mencadangkan dan memulihkan penyebaran SAP Hana Anda:
- Gamabran umum pencadangan SAP Hana
- Pencadangan tingkat file SAP Hana
- Tolok ukur rekam jepret penyimpanan SAP Hana
Memulai dan menghidupkan ulang VM yang berisi SAP Hana
Fitur menonjol dari cloud publik Azure adalah Anda hanya dikenakan biaya untuk menit komputasi. Misalnya, saat mematikan VM yang menjalankan SAP Hana, Anda hanya ditagih untuk biaya penyimpanan selama waktu tersebut. Fitur lain tersedia saat Anda menentukan alamat IP statik untuk VM dalam penyebaran awal. Saat Anda menghidupkan ulang VM yang memiliki SAP Hana, VM dihidupkan ulang dengan alamat IP sebelumnya.
Gunakan SAProuter untuk dukungan jarak jauh SAP
Jika memiliki sambungan situs-ke-situs antara lokasi lokal dan Azure, dan Anda menjalankan komponen SAP, maka Anda mungkin sudah menjalankan SAProuter. Dalam kasus ini, selesaikan item berikut untuk dukungan jarak jauh:
- Pertahankan alamat IP privat dan statik dari VM yang menghosting SAP Hana dalam konfigurasi SAProuter.
- Konfigurasikan NSG subnet yang menghosting VM HANA untuk mengizinkan lalu lintas melalui port TCP/IP 3299.
Jika tersambung ke Azure melalui internet, dan tidak memiliki router SAP untuk VM dengan SAP Hana, maka Anda perlu memasang komponen. Pasang SAProuter di VM terpisah di subnet Manajemen. Gambar berikut menunjukkan skema kasar untuk menyebarkan SAP Hana tanpa sambungan situs-ke-situs dan dengan SAProuter:
Pastikan untuk memasang SAProuter di VM terpisah dan bukan di VM Jumpbox Anda. VM terpisah harus memiliki alamat IP statik. Untuk menyambungkan SAProuter Anda ke SAProuter yang dihosting oleh SAP, hubungi SAP untuk mendapatkan alamat IP. (SAProuter yang dihosting oleh SAP adalah mitra dari instans SAProuter yang Anda pasang pada VM.) Gunakan alamat IP dari SAP untuk mengonfigurasi instans SAProuter Anda. Dalam pengaturan konfigurasi, satu-satunya port yang diperlukan adalah port TCP 3299.
Untuk informasi selengkapnya tentang cara menyiapkan dan memelihara sambungan dukungan jarak jauh melalui SAProuter, lihat dokumentasi SAP.
Ketersediaan tinggi dengan SAP Hana pada VM asli Azure
Jika Anda menjalankan Server SUSE Linux Enterprise atau Red Hat, Anda dapat membuat kluster Pacemaker dengan perangkat STONITH. Anda dapat menggunakan perangkat untuk menyiapkan konfigurasi SAP Hana yang menggunakan replikasi sinkron dengan Replikasi Sistem HANA dan failover otomatis. Untuk informasi lebih lanjut tercantum di bagian 'langkah selanjutnya'.
Langkah berikutnya
Kenali artikel-artikel seperti yang tercantum
- Konfigurasi penyimpanan komputer virtual Azure SAP Hana
- Menyebarkan sistem peluasan skala SAP Hana dengan simpul siaga di VM Azure dengan menggunakan Azure NetApp Files di Server SUSE Linux Enterprise
- Menyebarkan sistem peluasan skala SAP Hana dengan simpul siaga di VM Azure menggunakan Azure NetApp Files di Linux Red Hat Enterprise
- Menyebarkan sistem peluasan skala SAP Hana dengan HSR dan Pacemaker di Azure VM di SUSE Linux Enterprise Server
- Menyebarkan sistem peluasan skala SAP Hana dengan HSR dan PAcemaker di Azure VM di Red Hat Enterprise Linux
- Ketersediaan tinggi SAP Hana pada komputer virtual Azure di SUSE Linux Enterprise Server
- Ketersediaan tinggi SAP Hana pada komputer virtual Azure di Red Hat Enterprise Linux