Konfigurasi dan operasi infrastruktur SAP Hana di Azure

  • Artikel

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:

Cross-site connectivity

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.

Anda juga dapat menyebarkan platform SAP Hana yang dipasang lengkap pada layanan VM Azure melalui platform Cloud SAP. Proses penginstalan dijelaskan dalam Menyebarkan SAP S/4HANA atau BW/4HANA di Azure.

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:

Rough deployment schema for SAP HANA without a site-to-site connection

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.

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:

Diagram that shows a typical basic design for a single node in a scale-out configuration.

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:

Scale-out basics of a single node

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 parameter basepath_shared = no ke global.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.

SAP HANA DT 2.0 Architecture Overview

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.

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.

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:

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:

Rough deployment schema for SAP HANA without a site-to-site connection and 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