Jenis Microsoft Azure Storage untuk beban kerja SAP
Azure memiliki banyak jenis penyimpanan yang sangat berbeda dalam kemampuan, throughput, latensi, dan harga. Beberapa jenis penyimpanan tidak, atau dapat digunakan terbatas untuk skenario SAP. Sementara itu, beberapa jenis penyimpanan Azure sangat cocok atau dioptimalkan untuk skenario beban kerja SAP tertentu. Khusus untuk SAP Hana, beberapa jenis penyimpanan Azure mendapat sertifikasi untuk digunakan dengan SAP Hana. Dalam dokumen ini, kita akan melalui berbagai jenis penyimpanan dan menjelaskan kemampuan dan kegunaannya dengan beban kerja SAP dan komponen SAP.
Komentari tentang unit digunakan di seluruh artikel ini. Banyak vendor cloud publik beralih menggunakan GiB (Gibibyte) atau TiB (Tebibyte) sebagai unit ukuran, bukan Gigabyte atau Terabyte. Oleh karena itu, semua dokumentasi dan harga Azure menggunakan unit tersebut. Di seluruh dokumen, kami merujuk unit ukuran unit MiB, GiB, dan TiB ini secara eksklusif. Anda mungkin perlu perencanaan dengan MB, GB, dan TB. Jadi, perhatikan beberapa perbedaan kecil dalam penghitungan jika Anda harus mengukur untuk throughput 400 MiB/detik, bukan throughput 250 MiB/detik.
Ketahanan Microsoft Azure Storage
Penyimpanan Microsoft Azure dari HDD Standar, SSD Standar, penyimpanan premium Azure, SSD Premium v2, dan disk Ultra menyimpan disk data dasar VHD (dengan OS) dan VM yang terpasang atau VHD (Virtual Hard Disk) dalam tiga salinan pada tiga node penyimpanan yang berbeda. Mengalihkan ke replika lain dan penyemaian replika baru jika ada kegagalan simpul penyimpanan, bersifat transparan. Sebagai hasil dari redundansi ini, TIDAK diharuskan untuk menggunakan jenis lapisan redundansi penyimpanan apa pun di beberapa disk Azure. Fakta ini disebut Penyimpanan Redundan Lokal (LRS). LRS adalah penyimpanan default untuk jenis penyimpanan ini di Azure. Azure NetApp Files menyediakan redundansi yang memadai untuk mencapai SLA (Perjanjian Tingkat Layanan) yang sama dengan penyimpanan Azure asli lainnya.
Ada beberapa metode redundansi lainnya, yang semuanya dijelaskan dalam artikel replikasi Azure Storage yang berlaku untuk beberapa jenis penyimpanan yang berbeda yang ditawarkan Azure.
Catatan
Menggunakan penyimpanan Azure untuk menyimpan data database dan mengulangi file log, LRS adalah satu-satunya tingkat ketahanan yang didukung pada saat ini
Perlu diingat juga bahwa berbagai jenis penyimpanan Azure memengaruhi SLA ketersediaan VM tunggal seperti yang dirilis dalam SLA untuk Virtual Machines.
Disk terkelola Azure
Disk terkelola adalah jenis sumber daya di Azure Resource Manager yang dapat digunakan sebagai pengganti VHD yang disimpan di Akun Azure Storage. Disk Terkelola secara otomatis selaras dengan [set ketersediaan][virtual-machines-manage-availability] komputer virtual yang dilampirkan. Dengan keselarasan seperti itu, Anda mengalami peningkatan ketersediaan komputer virtual Anda dan layanan yang berjalan di komputer virtual. Untuk informasi selengkapnya, baca artikel ringkasan.
Catatan
Kami mengharuskan penyebaran VM baru yang menggunakan penyimpanan blok Azure untuk disk mereka (semua penyimpanan Azure kecuali Azure NetApp Files dan Azure Files) perlu menggunakan disk terkelola Azure untuk disk VHD/OS dasar dan disk data yang menyimpan file database SAP. Terlepas dari apakah Anda menyebarkan VM melalui set ketersediaan, di seluruh Zona Ketersediaan atau bergantung pada set dan zona. Disk yang digunakan untuk tujuan menyimpan cadangan tidak selalu harus berupa disk terkelola.
Skenario penyimpanan dengan beban kerja SAP
Penyimpanan tetap diperlukan dalam beban kerja SAP di berbagai komponen tumpukan yang Anda sebarkan di Azure. Skenario ini mencantumkan minimal seperti:
- Persisten VHD dasar dari VM Anda yang mempertahankan sistem operasi dan perangkat lain yang Anda pasang dalam disk tersebut. Disk/VHD ini adalah akar dari VM Anda. Setiap perubahan yang dilakukan padanya, harus dipertahankan. Jadi, lain kali Anda menghentikan dan memulai ulang VM, semua perubahan yang dilakukan sebelumnya masih ada. Terutama dalam kasus di mana VM semakin banyak disebarkan oleh Azure ke host lain daripada yang dijalankan di awal
- Disk data permanen. Disk ini adalah VHD yang Anda sematkan untuk menyimpan data aplikasi. Data aplikasi ini dapat berupa data dan file log/redo dari database, file cadangan, atau penginstalan perangkat lunak. Berarti setiap disk di luar VHD dasar Anda memiliki sistem operasi
- Berbagi file atau disk bersama yang berisi direktori transportasi global Anda untuk NetWeaver atau S/4HANA. Konten yang dibagikan tersebut digunakan oleh perangkat lunak yang berjalan di beberapa VM atau digunakan untuk membuat skenario kluster failover ketersediaan tinggi
- Direktori /sapmnt atau berbagi file umum untuk proses EDI (Pertukaran Data Elektronik) atau yang serupa. Konten yang dibagikan tersebut digunakan oleh perangkat lunak yang berjalan di beberapa VM atau digunakan untuk membuat skenario kluster failover ketersediaan tinggi
Di beberapa bagian berikutnya, berbagai jenis penyimpanan Azure dan kegunaannya untuk empat skenario beban kerja SAP akan dibahas. Kategorisasi umum tentang bagaimana jenis penyimpanan Azure yang berbeda harus digunakan didokumentasikan dalam artikel Jenis disk apa yang tersedia di Azure?. Rekomendasi untuk menggunakan berbagai jenis penyimpanan Azure untuk beban kerja SAP tidak akan sangat berbeda.
Untuk pembatasan dukungan pada jenis penyimpanan Azure untuk lapisan SAP NetWeaver/aplikasi S/4HANA, baca catatan dukungan SAP 2015553. Untuk jenis penyimpanan Azure bersertifikat dan didukung SAP Hana, baca artikel Konfigurasi penyimpanan komputer virtual Azure SAP Hana.
Bagian yang menjelaskan berbagai jenis penyimpanan Azure akan memberi Anda lebih banyak latar belakang tentang pembatasan dan kemungkinan menggunakan penyimpanan yang didukung SAP.
Pilihan penyimpanan saat menggunakan replikasi DBMS
Arsitektur referensi kami memperkirakan penggunaan fungsionalitas DBMS (Sistem Manajemen Database) seperti SQL Server Always On, Hana System Replication, Db2 HADR, atau Oracle Data Guard. Jika Anda menggunakan teknologi ini antara dua atau beberapa komputer virtual Azure, jenis penyimpanan yang dipilih untuk setiap VM harus sama. Berarti konfigurasi penyimpanan antara simpul aktif dan simpul replika dalam konfigurasi DBMS HA harus sama.
Rekomendasi penyimpanan untuk skenario penyimpanan SAP
Sebelum masuk ke detail, kami menyajikan ringkasan dan rekomendasi yang sudah ada di awal dokumen. Sedangkan detail untuk jenis penyimpanan Azure tertentu disajikan setelah bagian dokumen ini. Saat kami meringkas rekomendasi penyimpanan untuk skenario penyimpanan SAP dalam tabel, sepertinya:
Skenario penggunaan | HDD Standar | SSD Standar | Penyimpanan Premium | SSD v2 Premium | Ultra disk | File Azure NetApp | Azure Premium Files |
---|---|---|---|---|---|---|---|
Disk OS | Tidak cocok | Cocok terbatas (non-prod) | Direkomendasikan | Tidak mungkin | Tidak mungkin | Tidak mungkin | Tidak mungkin |
Direktori transportasi global | Tidak didukung | Tidak didukung | Direkomendasikan | Direkomendasikan | Direkomendasikan | Direkomendasikan | Sangat Direkomendasikan |
/sapmnt | Tidak cocok | Cocok terbatas (non-prod) | Direkomendasikan | Direkomendasikan | Direkomendasikan | Direkomendasikan | Sangat Direkomendasikan |
Keluarga VM SAP Hana M/Mv2 volume Data DBMS | Tidak didukung | Tidak didukung | Direkomendasikan | Direkomendasikan | Direkomendasikan | Direkomendasikan | Tidak didukung |
Keluarga VM SAP Hana M/Mv2 volume log DBMS | Tidak didukung | Tidak didukung | Direkomendasikan1 | Direkomendasikan | Direkomendasikan | Direkomendasikan | Tidak didukung |
Keluarga VM SAP Hana Esv3/Edsv4 volume Data DBMS | Tidak didukung | Tidak didukung | Direkomendasikan | Direkomendasikan | Direkomendasikan | Direkomendasikan | Tidak didukung |
Keluarga VM SAP Hana Esv3/Edsv4 volume log DBMS | Tidak didukung | Tidak didukung | Tidak didukung | Direkomendasikan | Direkomendasikan | Direkomendasikan | Tidak didukung |
Volume bersama HANA | Tidak didukung | Tidak didukung | Direkomendasikan | Direkomendasikan | Direkomendasikan | Direkomendasikan | Direkomendasikan |
Volume Data DBMS non-HANA | Tidak didukung | Cocok terbatas (non-prod) | Direkomendasikan | Direkomendasikan | Direkomendasikan | Hanya untuk rilisan Oracle tertentu di Oracle Linux, Db2 dan SAP ASE di Linux SLES/RHEL | Tidak didukung |
Keluarga VM non-HANA M/Mv2 volume log DBMS | Tidak didukung | Cocok terbatas (non-prod) | Direkomendasikan1 | Direkomendasikan | Direkomendasikan | Hanya untuk rilisan Oracle tertentu di Oracle Linux, Db2 dan SAP ASE di Linux SLES/RHEL | Tidak didukung |
Keluarga VM non-HANA non-M/Mv2 volume log DBMS | Tidak didukung | cocok terbatas (non-prod) | Cocok untuk hingga beban kerja menengah | Direkomendasikan | Direkomendasikan | Hanya untuk rilisan Oracle tertentu di Oracle Linux, Db2 dan SAP ASE di Linux SLES/RHEL | Tidak didukung |
1 Dengan penggunaan Azure Write Accelerator untuk keluarga VM M/Mv2 VM untuk volume log/log fase pengulangan
Karakteristik yang dapat Anda harapkan dari daftar berbagai jenis penyimpanan seperti:
Skenario penggunaan | HDD Standar | SSD Standar | Penyimpanan Premium | SSD v2 Premium | Ultra disk | File Azure NetApp | Azure Premium Files |
---|---|---|---|---|---|---|---|
Throughput/ IOPS SLA | Tidak | No | Ya | Ya | Ya | Ya | Ya |
Latensi Baca | Sangat Penting | Menengah hingga tinggi | Kurang Penting | submillisecond | submillisecond | submillisecond | rendah |
Penulisan Latensi | Sangat Penting | Menengah hingga tinggi | Rendah (submillisecond1) | submillisecond | submillisecond | submillisecond | rendah |
didukung HANA | Tidak | Tidak | ya1 | Ya | Ya | Ya | Tidak |
Rekam jepret disk dimungkinkan | Ya | Ya | Ya | Ya3 | No2 | Ya | Tidak |
Alokasi disk dalam kluster penyimpanan yang berbeda saat menggunakan set ketersediaan | Melalui disk terkelola | Melalui disk terkelola | Melalui disk terkelola | Jenis disk tidak didukung dengan VM yang disebarkan melalui set ketersediaan | Jenis disk tidak didukung dengan VM yang disebarkan melalui set ketersediaan | No3 | No |
Selaras dengan Zona Ketersediaan | Ya | Ya | Ya | Ya | Ya | Dalam pratinjau publik | No |
Redundansi Zona sinkron | Tidak untuk disk terkelola | Tidak untuk disk terkelola | Tidak didukung untuk DBMS | Tidak | No | No | Ya |
Redundansi Zonal Asinkron | Tidak untuk disk terkelola | Tidak untuk disk terkelola | Tidak didukung untuk DBMS | Tidak | Tidak | Dalam pratinjau | No |
Redundansi geografis | Tidak untuk disk terkelola | Tidak untuk disk terkelola | Tidak | No | Tidak | Mungkin | No |
1 Dengan penggunaan Azure Write Accelerator untuk keluarga VM M/Mv2 VM untuk volume log/log fase pengulangan
2 Pembuatan kumpulan kapasitas Azure NetApp Files yang berbeda tidak menjamin penyebaran kumpulan kapasitas ke unit penyimpanan yang berbeda
3 (Inkremental) Rekam jepret SSD Premium v2 atau disk Ultra tidak dapat digunakan segera setelah dibuat. Salinan latar belakang harus selesai sebelum Anda dapat membuat disk dari rekam jepret
Penting
Lihat bagian Azure NetApp Files dari dokumen ini untuk menemukan detail sekeliling penempatan kedekatan volume NFS dan VM ketika latensi kurang dari 1 milidetik diperlukan.
Penyimpanan premium Azure
Penyimpanan SSD premium Azure diperkenalkan dengan tujuan untuk menyediakan:
- Latensi I/O rendah
- SLA untuk IOPS dan throughput
- Lebih sedikit variabilitas dalam latensi I/O
Jenis penyimpanan ini menargetkan beban kerja DBMS, lalu lintas penyimpanan yang membutuhkan latensi milidetik digit tunggal rendah, dan SLA pada IOPS dan throughput. Dasar biaya untuk penyimpanan premium Azure bukanlah volume data aktual yang disimpan dalam disk tersebut, tetapi kategori ukuran disk tersebut, terlepas dari jumlah data yang disimpan dalam disk. Anda juga dapat membuat disk pada penyimpanan premium yang tidak langsung dipetakan ke dalam kategori ukuran yang ditunjukkan dalam artikel SSD Premium. Kesimpulan dari artikel ini adalah:
- Penyimpanan diatur dalam rentang. Misalnya, disk dalam rentang 513 GiB hingga kapasitas 1.024 GiB memiliki kemampuan yang sama dan biaya bulanan yang sama
- IOPS per GiB tidak melacak linier di seluruh kategori ukuran. Disk yang lebih kecil di bawah 32 GiB memiliki tingkat IOPS yang lebih tinggi per GiB. Untuk disk di luar 32 GiB hingga 1.024 GiB, tingkat IOPS per GiB adalah antara 4-5 IOPS per GiB. Untuk disk yang lebih besar hingga 32.767 GiB, tingkat IOPS per GiB di bawah 1
- Throughput I/O untuk penyimpanan ini tidak linier dengan ukuran kategori disk. Untuk disk yang lebih kecil, seperti kategori antara kapasitas 65 GiB dan 128 GiB, throughputnya sekitar 780 KB per GiB. Sedangkan untuk disk besar ekstrem seperti disk 32.767 GiB, throughputnya sekitar 28 KB per GiB
- IOPS dan throughput SLA tidak dapat diubah tanpa mengubah kapasitas disk
Matriks kemampuan untuk beban kerja SAP terlihat seperti:
Kemampuan | Komentar | Catatan/Tautan |
---|---|---|
VHD berbasis OS | Cocok | Semua sistem |
Disk data | Cocok | Semua sistem - Khususnya untuk SAP HANA |
Direktori transportasi global SAP | Ya | Didukung |
SAP sapmnt | Cocok | Semua sistem |
Penyimpanan cadangan | Cocok | Untuk penyimpanan cadangan jangka pendek |
Berbagi/disk bersama | Tidak tersedia | Memerlukan Azure Premium Files atau pihak ketiga |
Ketahanan | LRS | Tidak ada GRS atau ZRS yang tersedia untuk disk |
Latensi | Rendah hingga sedang | - |
SLA IOPS | Ya | - |
IOPS linier ke kapasitas | semi linier dalam tanda kurung | Harga Disk Terkelola |
IOPS maksimum per disk | 20.000 bergantung pada ukuran disk | Pertimbangkan juga batas VM |
SLA throughput | Ya | - |
Throughput linier ke kapasitas | Semi linier dalam tanda kurung | Harga Disk Terkelola |
Bersertifikat HANA | Ya | khusus untuk SAP Hana |
Dukungan Azure Write Accelerator | No | - |
Disk bursting | Ya | - |
Rekam jepret disk dimungkinkan | Ya | - |
Rekam jepret VM Azure Backup dimungkinkan | Ya | - |
Biaya | Medium | - |
Penyimpanan premium Azure tidak memenuhi KPI latensi penyimpanan SAP Hana dengan jenis penembolokan umum yang ditawarkan dengan penyimpanan premium Azure. Untuk memenuhi KPI latensi penyimpanan untuk penulisan log SAP Hana, Anda perlu menggunakan penembolokan Azure Write Accelerator seperti yang dijelaskan dalam artikel Mengaktifkan Write Accelerator. Azure Write Accelerator mengambil manfaat dari semua sistem DBMS lainnya untuk penulisan log transaksi dan penulisan log fase pengulangannya. Oleh karena itu, disarankan untuk menggunakannya di semua penyebaran SAP DBMS. Untuk SAP Hana, penggunaan Azure Write Accelerator untuk /hana/log dengan penyimpanan premium Azure adalah wajib.
Ringkasan: Penyimpanan premium Azure adalah salah satu jenis penyimpanan Azure yang direkomendasikan untuk beban kerja SAP. Rekomendasi ini berlaku untuk sistem nonproduksi dan produksi. Penyimpanan premium Azure cocok untuk menangani beban kerja database. Penggunaan Azure Write Accelerator akan meningkatkan latensi penulisan terhadap disk premium Azure secara substansial. Namun, untuk sistem DBMS dengan tingkat IOPS dan throughput tinggi, Anda perlu menyediakan kapasitas penyimpanan yang berlebihan. Atau Anda perlu menggunakan fungsionalitas seperti Ruang Penyimpanan Windows atau manajer volume logis di Linux untuk membangun set stripe yang memberi Anda kapasitas yang diinginkan di satu sisi. Tetapi juga IOPS atau throughput yang diperlukan dengan efisiensi biaya terbaik.
Fungsionalitas burst Azure untuk penyimpanan premium
Untuk disk penyimpanan premium Azure yang berkapasitas lebih kecil atau sama dengan 512 GiB, fungsi burst ledakan ditawarkan. Cara kerja bursting disk dijelaskan dalam artikel Bursting disk. Saat membaca artikel, Anda akan memahami konsep penjumlahan IOPS dan throughput saat beban kerja I/O Anda di bawah IOPS dan throughput nominal disk (untuk detail tentang throughput nominal, lihat Mengelola Harga Disk). Anda akan mengumpulkan delta IOPS dan throughput antara penggunaan Anda saat ini dan nilai nominal disk. Burst dibatasi hingga maksimum 30 menit.
Kasus-kasus ideal di mana fungsi burst ini dapat direncanakan kemungkinan adalah volume atau disk yang berisi file data untuk DBMS yang berbeda. Beban kerja I/O yang diharapkan terhadap volume tersebut, terutama dengan sistem kecil hingga menengah diharapkan terlihat seperti:
- Beban kerja baca rendah hingga sedang karena data idealnya di-cache dalam memori. Atau seperti dengan SAP Hana harus benar-benar dalam memori
- Burst tulisan yang dipicu oleh titik pemeriksaan atau titik simpan database yang diterbitkan secara teratur
- Beban kerja cadangan yang membaca dalam aliran berkelanjutan jika pencadangan tidak dieksekusi melalui snapshot penyimpanan
- Untuk SAP HANA, muat data ke dalam memori setelah mulai ulang instans
Khususnya pada sistem DBMS yang lebih kecil di mana beban kerja Anda hanya menangani beberapa ratus transaksi per detik, fungsi burst seperti itu juga masih masuk akal untuk disk atau volume yang menyimpan transaksi atau log fase pengulangan. Beban kerja yang diharapkan terhadap disk atau volume tersebut terlihat seperti:
- Tulisan reguler ke disk yang bergantung pada beban kerja dan sifat beban kerja karena setiap penerapan yang diterbitkan oleh aplikasi kemungkinan memicu operasi I/O
- Beban kerja yang lebih tinggi dalam throughput untuk kasus tugas operasional, seperti membuat atau membangun ulang indeks
- Baca burst saat melakukan log transaksi atau mengulangi pencadangan log
Azure Premium SSD v2
Penyimpanan Azure Premium SSD v2 adalah versi baru penyimpanan premium yang diperkenalkan dengan tujuan untuk menyediakan:
- Latensi I/O Submillisecond untuk ukuran I/O baca dan tulis yang lebih kecil
- SLA untuk IOPS dan throughput
- Kapasitas bayar berdasarkan GB yang disediakan
- Menyediakan sekumpulan IOPS dan throughput penyimpanan default per disk
- Berikan kemungkinan untuk menambahkan lebih banyak IOPS dan throughput ke setiap disk dan membayar secara terpisah untuk sumber daya tambahan yang disediakan ini
- Lulus sertifikasi SAP Hana tanpa bantuan fungsionalitas lain seperti Azure Write Accelerator atau cache lainnya
Jenis penyimpanan ini menargetkan beban kerja DBMS, lalu lintas penyimpanan yang memerlukan latensi submillisecond, dan SLA pada IOPS dan throughput. Disk Premium SSD v2 dikirimkan dengan set default 3.000 IOPS dan throughput 125 MBps. Dan kemungkinan untuk menambahkan lebih banyak IOPS dan throughput ke disk individual. Harga penyimpanan disusun dengan cara yang menambahkan lebih banyak throughput atau IOPS tidak memengaruhi harga sebagian besar. Namun demikian, kami menyerahkannya kepada Anda untuk memutuskan bagaimana konfigurasi penyimpanan Anda untuk Premium SSD v2 akan terlihat seperti. Untuk memulai dasar, baca konfigurasi penyimpanan SAP Hana Azure virtual machine Premium SSD v2.
Untuk wilayah aktual, jenis penyimpanan blok baru ini tersedia dan pembatasan aktual membaca dokumen Premium SSD v2.
Matriks kemampuan untuk beban kerja SAP terlihat seperti:
Kemampuan | Komentar | Catatan/Tautan |
---|---|---|
VHD berbasis OS | Tidak didukung | Tidak ada sistem |
Disk data | Cocok | Semua sistem |
Direktori transportasi global SAP | Ya | Semua sistem |
SAP sapmnt | Cocok | Semua sistem |
Penyimpanan cadangan | Cocok | Untuk penyimpanan cadangan jangka pendek |
Berbagi/disk bersama | Tidak tersedia | Membutuhkan Azure Premium Files atau Azure NetApp Files |
Ketahanan | LRS | Tidak ada GRS atau ZRS yang tersedia untuk disk |
Latensi | submillisecond | - |
SLA IOPS | Ya | - |
IOPS linier ke kapasitas | semi linier | Harga Disk Terkelola |
IOPS maksimum per disk | 80.000 tergantung pada ukuran disk | Pertimbangkan juga batas VM |
SLA throughput | Ya | - |
Throughput linier ke kapasitas | Semi linear | Harga Disk Terkelola |
Bersertifikat HANA | Ya | - |
Dukungan Azure Write Accelerator | No | - |
Disk bursting | No | - |
Rekam jepret disk dimungkinkan | Ya1 | - |
Rekam jepret VM Azure Backup dimungkinkan | Ya | - |
Biaya | Medium | - |
1 (Inkremental) Rekam jepret SSD Premium v2 atau disk Ultra tidak dapat digunakan segera setelah dibuat. Salinan latar belakang harus selesai sebelum Anda dapat membuat disk dari rekam jepret
Berlawanan dengan penyimpanan premium Azure, Azure Premium SSD v2 memenuhi KPI latensi penyimpanan SAP Hana. Akibatnya, Anda tidak perlu menggunakan penembolokan Azure Write Accelerator seperti yang dijelaskan dalam artikel Aktifkan Akselerator Tulis.
Ringkasan: Azure Premium SSD v2 adalah penyimpanan blok yang sesuai dengan rasio harga/performa terbaik untuk beban kerja SAP. Azure Premium SSD v2 cocok untuk menangani beban kerja database. Latensi submillisecond adalah penyimpanan yang ideal untuk beban kerja DBMS yang menuntut. Meskipun ini adalah jenis penyimpanan yang lebih baru yang dirilis pada November 2022. Oleh karena itu, mungkin masih ada beberapa batasan yang akan hilang selama beberapa bulan ke depan.
Disk Azure Ultra
Disk ultra Azure memberikan throughput tinggi, IOPS tinggi, dan penyimpanan disk latensi rendah yang konsisten untuk Azure IaaS VM. Beberapa manfaat disk ultra termasuk kemampuan untuk mengubah IOPS dan throughput disk secara dinamis, bersama dengan beban kerja Anda, tanpa perlu menghidupkan ulang komputer virtual (VM) Anda. Disk ultra cocok untuk beban kerja padat data seperti beban kerja SAP DBMS. Disk ultra hanya dapat digunakan sebagai disk data dan tidak dapat digunakan sebagai disk VHD dasar yang menyimpan sistem operasi. Sebaiknya gunakan penyimpanan premium Azure sebagai disk VHD dasar.
Saat membuat disk ultra, Anda memiliki tiga dimensi yang dapat ditentukan:
- Kapasitas disk. Rentang dari 4 GiB hingga 65.536 GiB
- IOPS yang diprovisikan untuk disk. Nilai maksimum yang berbeda berlaku untuk kapasitas disk. Untuk detail selengkapnya, baca artikel Disk ultra
- Bandwidth penyimpanan yang diprovisikan. Bandwidth maksimum yang berbeda berlaku bergantung pada kapasitas disk. Untuk detail selengkapnya, baca artikel Disk ultra
Biaya disk tunggal ditentukan oleh tiga dimensi yang dapat ditentukan untuk disk tertentu secara terpisah.
Matriks kemampuan untuk beban kerja SAP terlihat seperti:
Kemampuan | Komentar | Catatan/Tautan |
---|---|---|
VHD berbasis OS | Tidak berfungsi | - |
Disk data | Cocok | Semua sistem |
Direktori transportasi global SAP | Ya | Didukung |
SAP sapmnt | Cocok | Semua sistem |
Penyimpanan cadangan | Cocok | Untuk penyimpanan cadangan jangka pendek |
Berbagi/disk bersama | Tidak tersedia | Memerlukan pihak ketiga |
Ketahanan | LRS | Tidak ada GRS atau ZRS yang tersedia untuk disk |
Latensi | Sangat rendah | - |
SLA IOPS | Ya | - |
IOPS linier ke kapasitas | Semi linier dalam tanda kurung | Harga Disk Terkelola |
IOPS maksimum per disk | 1.200 hingga 160.000 | tergantung pada kapasitas disk |
SLA throughput | Ya | - |
Throughput linier ke kapasitas | Semi linier dalam tanda kurung | Harga Disk Terkelola |
Bersertifikat HANA | Ya | - |
Dukungan Azure Write Accelerator | No | - |
Disk bursting | Ya | - |
Rekam jepret disk dimungkinkan | Ya1 | - |
Rekam jepret VM Azure Backup dimungkinkan | Ya | - |
Biaya | Lebih tinggi daripada penyimpanan Premium | - |
1 (Inkremental) Rekam jepret SSD Premium v2 atau disk Ultra tidak dapat digunakan segera setelah dibuat. Salinan latar belakang harus selesai sebelum Anda dapat membuat disk dari rekam jepret
Ringkasan: Disk ultra Azure adalah penyimpanan yang sesuai dengan latensi submillisecond rendah untuk semua jenis beban kerja SAP. Sejauh ini, disk Ultra hanya dapat digunakan dalam kombinasi dengan VM yang telah digunakan melalui Availability Zone (penerapan zona). Berlawanan dengan semua penyimpanan lainnya, disk Ultra tidak dapat digunakan untuk disk VHD dasar. Disk Ultra sangat cocok untuk kasus di mana beban kerja I/O banyak berfluktuasi dan Anda ingin menyesuaikan throughput penyimpanan yang diterapkan atau IOPS dengan pola beban kerja penyimpanan, daripada menentukan ukuran untuk penggunaan maksimum bandwidth dan IOPS.
File Azure NetApp
Azure NetApp Files adalah layanan penyimpanan file asli Azure, pihak pertama, kelas perusahaan, berkinerja tinggi yang disertifikasi untuk digunakan dengan SAP Hana. Ini menyediakan Volume sebagai layanan tempat Anda membuat akun NetApp, kumpulan kapasitas, dan volume. Dengan Azure NetApp Files, Anda memilih tingkat layanan dan performa dan mengelola perlindungan data untuk membuat dan mengelola berbagi file berperforma tinggi, sangat tersedia, dan dapat diskalakan dengan menggunakan protokol dan alat yang sama dengan yang Anda kenal dan andalkan secara lokal.
Jenis beban kerja SAP berikut didukung pada volume Azure NetApp Files:
- Beban kerja SAP DBMS
- Berbagi SAPMNT
- Direktori transportasi global
Azure NetApp Files tersedia dalam tiga tingkat layanan, masing-masing dengan throughput dan spesifikasi harganya sendiri. Mana yang tepat untuk penyebaran Anda tergantung pada ukuran penyebaran. Rekomendasi ukuran yang disesuaikan tersedia di SAP di Estimator TCO Azure NetApp Files.
Untuk informasi tentang tingkat layanan, lihat Tingkat layanan untuk Azure NetApp Files.
Menyebarkan volume
Untuk hasil yang optimal, gunakan Grup volume aplikasi untuk SAP Hana untuk menyebarkan volume. Grup volume aplikasi menempatkan volume di lokasi optimal dalam infrastruktur Azure menggunakan aturan afinitas dan anti-afinitas untuk mengurangi pertikaian dan untuk memungkinkan throughput terbaik dan latensi terendah.
Catatan
Kumpulan kapasitas adalah unit provisi dasar untuk Azure NetApp Files. Kumpulan kapasitas ditawarkan mulai dari ukuran 1 TiB; Anda dapat memperluas kumpulan kapasitas dalam kenaikan 1-TiB. Kumpulan kapasitas adalah unit induk untuk volume. Untuk informasi ukuran, lihat Batas sumber daya Azure NetApp Files. Untuk harga, lihat Harga Azure NetApp Files.
Azure NetApp Files didukung untuk beberapa skenario beban kerja SAP:
- Penyebaran SAP Hana menggunakan berbagi NFS untuk volume /hana/data dan /hana/log untuk volume /hana/shared seperti yang didokumentasikan dalam konfigurasi penyimpanan komputer virtual Azure SAP Hana
- Menyediakan berbagi SMB atau NFS untuk direktori transportasi global SAP
- Sapmnt berbagi dalam skenario ketersediaan tinggi seperti yang didokumenkan dalam:
- Ketersediaan tinggi untuk SAP NetWeaver pada komputer virtual Azure di Windows dengan Azure NetApp Files (SMB) untuk aplikasi SAP
- Ketersediaan tinggi untuk SAP NetWeaver pada komputer virtual Azure di SUSE Linux Enterprise Server dengan Azure NetApp Files untuk aplikasi SAP
- Ketersediaan tinggi Azure Virtual Machines untuk SAP NetWeaver di Red Hat Enterprise Linux dengan Azure NetApp Files untuk aplikasi SAP
- IBM Db2 di Azure VM berbasis Suse atau Red Hat Linux
- Penyebaran SAP di Oracle di OS tamu Oracle Linux menggunakan dNFS untuk data Oracle dan volume log pengulangan. Beberapa detail lainnya dapat ditemukan dalam artikel Penyebaran Azure Virtual Machines Oracle DBMS untuk beban kerja SAP
- SAP di ASE di OS tamu Suse atau Red Hat Linux
- AP di MAXDB di OS tamu Suse atau Red Hat Linux
- SAP di Microsoft SQL Server dengan volume SMB
Catatan
Untuk beban kerja DBMS di Linux, gunakan volume berbasis NFS di Azure NetApp Files.
Memisahkan throughput dari ukuran volume
Penyimpanan untuk aplikasi database biasanya memiliki persyaratan throughput yang tidak diskalakan secara linier dengan ukuran volume, yaitu volume log berukuran relatif kecil tetapi memerlukan tingkat throughput yang tinggi.
Azure NetApp Files memungkinkan Anda mengalokasikan throughput volume secara independen dari ukuran volume saat menggunakan kumpulan kapasitas jenis QoS manual.
Berikut contohnya:
- Volume untuk file database memerlukan throughput 500 MiB/dtk dan kapasitas 39 TiB
- Volume untuk file log memerlukan throughput 2000 MiB/dtk dan kapasitas 1 TiB
Anda dapat membuat kumpulan kapasitas QoS manual untuk skenario ini dan mengalokasikan throughput secara independen dari ukuran volume. Total kapasitas yang diperlukan adalah 40 TiB, dan total anggaran throughput adalah 2500 MiB/dtk. Kumpulan kapasitas di tingkat layanan Premium (64 MiB/dtk per TiB yang dialokasikan) mengakomodasi persyaratan performa dan kapasitas (40 MiB * 64 iB/dtk/TiB = 2560 MiB).
Penskalaan performa linier akan memerlukan provisi volume log yang cukup besar untuk mencapai persyaratan throughput. Untuk mencapai throughput 2000 MiB/dtk untuk volume log, Anda harus menyebarkan kumpulan kapasitas di tingkat Ultra (128 MiB/dtk per TiB yang dialokasikan) sebesar 16 TiB, sehingga menghasilkan provisi berlebih dan oleh karena itu kapasitas yang terbuang sebesar 15 TiB.
Gunakan Kalkulator Performa Azure NetApp Files untuk mendapatkan perkiraan skenario Anda.
Matriks kemampuan untuk beban kerja SAP di Azure NetApp Files terlihat seperti:
Kemampuan | Komentar | Catatan/Tautan |
---|---|---|
VHD berbasis OS | Gunakan disk terkelola | - |
Disk data | Cocok | SAP Hana, Oracle di Oracle Linux, Db2 dan SAP ASE di SLES/RHEL, MAXDB, SQL Server |
Direktori transportasi global SAP | Ya | SMB (khusus Windows) dan NFS (khusus Linux) |
SAP sapmnt | Cocok | SMB (hanya Windows) atau NFS (khusus Linux) |
Penyimpanan cadangan | Cocok | Gunakan rekam jepret dan/atau cadangan Azure NetApp Files; pencadangan log untuk HANA juga dapat digunakan sebagai tujuan pencadangan berbasis file |
Berbagi/disk bersama | Ya | SMB/NFS |
Ketahanan | LRS dan GRS | GRS dengan replikasi lintas wilayah; ZRS dengan replikasi lintas zona |
Latensi | Sangat rendah | Biasanya kurang dari 1 mdtk |
SLA IOPS | Ya | - |
IOPS linier ke kapasitas | Linear dengan QoS otomatis; dapat dikonfigurasi secara independen dengan QoS Manual | Tiga tingkat layanan tersedia |
SLA throughput | Ya | Rekomendasi ukuran tersedia di SAP pada Estimator TCO Azure NetApp Files |
Throughput linier ke kapasitas | Linear dengan QoS otomatis; dapat dikonfigurasi secara independen dengan QoS Manual | Tiga tingkat layanan tersedia |
Bersertifikat HANA | Ya | - |
Rekam jepret disk dimungkinkan | Ya | Lihat Cara kerja rekam jepret Azure NetApp Files |
Rekam jepret dan orkestrasi cadangan yang konsisten untuk aplikasi | No | Menggunakan AzAcSnap atau SnapCenter |
Biaya | Menggunakan alat estimasi TCO | Gunakan SAP di Estimator TCO Azure NetApp Files dan masukkan ukuran lanskap |
Fungsionalitas bawaan penyimpanan Azure NetApp Files lainnya:
- Kemampuan untuk melakukan rekam jepret volume yang konsisten dengan aplikasi menggunakan AzAcSnap
- Kloning volume Azure NetApp Files dari rekam jepret untuk pengujian dan pengembangan
- Memulihkan volume dari rekam jepret (snap-revert) untuk pemulihan cepat dari kerusakan dan kesalahan
Penting
Khusus untuk penyebaran database, Anda ingin mencapai latensi rendah untuk setidaknya log pengulangan Anda. Khusus untuk SAP Hana, SAP membutuhkan latensi kurang dari 1 milidetik untuk penulisan log pengulangan HANA dengan ukuran yang lebih kecil. Untuk mendapatkan latensi seperti itu, lihat kemungkinan di bawah ini.
Penting
Saat menyebarkan volume Azure NetApp Files perhatikan zona tempat komputer virtual berada atau akan disebarkan. Pastikan Anda memilih zona yang sama. Fungsionalitas ini didokumentasikan dalam artikel Mengelola penempatan volume zona ketersediaan untuk Azure NetApp Files. Grup volume aplikasi untuk SAP Hana menggunakan fungsionalitas yang sama untuk menyebarkan volume dalam kemungkinan terdekat dengan VM aplikasi.
Motivasi untuk memiliki jenis penyelarasan Zona Ketersediaan ini adalah pengurangan permukaan risiko dengan memiliki berbagi NFS di zona ketersediaan yang sama dengan VM aplikasi.
- Sebarkan volume Azure NetApp Files untuk penyebaran SAP Hana Anda menggunakan grup volume aplikasi untuk SAP Hana. Keuntungan dari Grup Volume Aplikasi adalah volume data disebarkan melalui beberapa titik akhir penyimpanan, mengurangi pertikaian jaringan dan meningkatkan performa.
Ringkasan: Azure NetApp Files adalah solusi penyimpanan latensi rendah bersertifikat untuk SAP Hana. Layanan ini menyediakan volume yang diukir dari satu atau beberapa kumpulan kapasitas. Kumpulan kapasitas tersedia dalam tiga tingkat layanan yang menentukan total kapasitas dan throughput yang dialokasikan. Volume dapat diubah ukurannya, dan throughput yang dialokasikan dapat disesuaikan tanpa gangguan layanan untuk memenuhi persyaratan yang berubah dan untuk mengontrol biaya. Layanan ini menyediakan fungsionalitas untuk mereplikasi volume ke wilayah atau zona lain untuk pemulihan bencana dan tujuan kelangsungan bisnis.
Azure Premium Files
Azure Premium Files adalah penyimpanan bersama yang menawarkan SMB dan NFS dengan harga sedang dan latensi yang cukup untuk menangani berbagi lapisan aplikasi SAP. Di atasnya, Azure premium Files menawarkan replikasi zona yang sinkron dari berbagi dengan otomatisisme yang jika satu replika gagal, replika lain di zona lain dapat mengambil alih. Berlawanan dengan Azure NetApp Files, tidak ada tingkat performa. Anda juga tidak perlu menggunakan kumpulan kapasitas. Pengisian daya didasarkan pada kapasitas nyata yang disediakan dari berbagai berbagi. Azure Premium Files belum diuji sebagai penyimpanan DBMS untuk beban kerja SAP sama sekali. Tetapi sebaliknya skenario penggunaan untuk beban kerja SAP berfokus pada semua jenis berbagi SMB dan NFS saat digunakan pada lapisan aplikasi SAP. Azure Premium Files juga cocok untuk penggunaan untuk /hana/shared.
Catatan
Sejauh ini tidak ada beban kerja SAP DBMS yang didukung pada volume bersama berdasarkan Azure Premium Files.
Skenario SAP yang didukung pada daftar Azure Premium Files seperti:
- Menyediakan berbagi SMB atau NFS untuk direktori transportasi global SAP
- Penggunaan sebagai berbagi untuk antarmuka ke sistem SAP dan proses EDI
- Sapmnt berbagi dalam skenario ketersediaan tinggi seperti yang didokumenkan dalam:
- Ketersediaan tinggi untuk SAP NetWeaver di Azure VM di SUSE Linux Enterprise Server dengan NFS di Azure Files
- Ketersediaan tinggi untuk SAP NetWeaver di Azure VM di Red Hat Enterprise Linux dengan NFS di Azure Files
- Ketersediaan tinggi untuk SAP NetWeaver di Azure VM di Windows dengan Azure Files Premium SMB untuk aplikasi SAP
- Ketersediaan tinggi untuk sistem peluasan skala SAP Hana dengan HSR di SUSE Linux Enterprise Server
Azure Premium Files dimulai dengan jumlah IOPS yang lebih besar pada ukuran berbagi minimum 100 GB dibandingkan dengan Azure NetApp Files. Bilah IOPS yang lebih tinggi ini dapat menghindari provisi berlebih kapasitas untuk mencapai nilai IOPS dan throughput tertentu. Untuk IOPS dan throughput penyimpanan, baca bagian Target skala berbagi file Azure di skalabilitas Azure Files dan target performa.
Catatan
Karena arsitektur berjenjang Azure Premium Files, latensi mengakses metadata file yang disimpan dalam berbagi secara signifikan lebih tinggi daripada dengan Azure NetApp Files. Latensi yang lebih tinggi ini dapat berdampak untuk pembuatan massal instans dan penghapusan file. Tetapi juga dapat berdampak nyata pada waktu yang diperlukan untuk mencantumkan konten direktori besar, yang berisi ratusan ribu file. Kasus penggunaan utama yang kita lihat latensi metadata yang lebih tinggi ini mempengaruhi adalah penggunaan sebagai berbagi antarmuka di mana pelanggan dapat menemukan ratusan ribu atau bahkan jutaan pembuatan file dan penghapusan massal setiap hari. Oleh karena itu, Anda harus menguji skenario berbagi antarmuka dengan rajin. Untuk menentukan apakah beban kerja Anda berat metadata, periksa Metadata atau beban kerja berat namespace
Matriks kemampuan untuk beban kerja SAP terlihat seperti:
Kemampuan | Komentar | Catatan/Tautan |
---|---|---|
VHD berbasis OS | Tidak berfungsi | - |
Disk data | Tidak didukung untuk beban kerja SAP | - |
Direktori transportasi global SAP | Ya | SMB dan NFS |
SAP sapmnt | Cocok | Semua sistem SMB (khusus Windows) atau NFS (khusus Linux) |
Penyimpanan cadangan | Cocok | - |
Berbagi/disk bersama | Ya | SMB 3.0, NFS v4.1 |
Ketahanan | LRS dan ZRS | Tidak ada GRS yang tersedia untuk Azure Premium Files |
Latensi | rendah | - |
SLA IOPS | Ya | - |
IOPS linier ke kapasitas | sangat linier | - |
SLA throughput | Ya | - |
Throughput linier ke kapasitas | sangat linier | - |
Bersertifikat HANA | No | - |
Rekam jepret disk dimungkinkan | Ya | - |
Rekam jepret VM Azure Backup dimungkinkan | No | - |
Biaya | rendah | - |
Ringkasan: Azure Premium Files adalah penyimpanan latensi rendah yang memungkinkan untuk menyebarkan volume atau berbagi NFS dan SMB. Azure Premium Files memberikan rasio harga/performa yang sangat baik untuk berbagi lapisan aplikasi SAP. Ini juga menyediakan replikasi zona sinkron untuk berbagi ini. Sejauh ini, kami tidak mendukung jenis penyimpanan ini untuk beban kerja SAP DBMS. Meskipun dapat digunakan untuk volume /hana/shared .
Penyimpanan SSD standar Azure
Dibandingkan dengan penyimpanan HDD standar Azure, penyimpanan SSD standar Azure memberikan ketersediaan, konsistensi, keandalan, dan latensi yang lebih baik. Ini dioptimalkan untuk beban kerja yang membutuhkan performa konsisten pada tingkat IOPS yang lebih rendah. Penyimpanan ini adalah penyimpanan minimum yang digunakan untuk sistem SAP nonproduksi yang memiliki Tuntutan IOPS dan throughput rendah. Matriks kemampuan untuk beban kerja SAP terlihat seperti:
Kemampuan | Komentar | Catatan/Tautan |
---|---|---|
VHD berbasis OS | Cocok terbatas | Sistem nonproduksi |
Disk data | Cocok terbatas | Beberapa sistem nonproduksi dengan Tuntutan IOPS dan latensi rendah |
Direktori transportasi global SAP | No | Tidak didukung |
SAP sapmnt | Cocok terbatas | Sistem nonproduksi |
Penyimpanan cadangan | Cocok | - |
Berbagi/disk bersama | Tidak tersedia | Memerlukan pihak ketiga |
Ketahanan | LRS, GRS | Tidak ada ZRS yang tersedia untuk disk |
Latensi | tinggi | Terlalu tinggi untuk direktori Transportasi Global SAP, atau sistem produksi |
SLA IOPS | No | - |
IOPS maksimum per disk | 500 | Tidak bergantung pada ukuran disk |
SLA throughput | No | - |
Bersertifikat HANA | No | - |
Rekam jepret disk dimungkinkan | Ya | - |
Rekam jepret VM Azure Backup dimungkinkan | Ya | - |
Biaya | Rendah | - |
Ringkasan: Penyimpanan SSD standar Azure adalah rekomendasi minimum untuk VM nonproduksi untuk VHD dasar, penyebaran DBMS akhirnya dengan ketidakpekaan latensi relatif dan/atau IOPS rendah dan tingkat throughput. Jenis penyimpanan Azure ini tidak didukung lagi untuk menghosting Direktori Transportasi Global SAP.
Penyimpanan HDD standar Azure
Penyimpanan HDD Standar Azure adalah satu-satunya jenis penyimpanan saat infrastruktur Azure disertifikasi untuk beban kerja SAP NetWeaver pada tahun 2014. Pada tahun 2014, throughput penyimpanan komputer virtual Azure kecil dan rendah. Oleh karena itu, jenis penyimpanan ini memenuhi permintaan. Penyimpanan ini cocok untuk beban kerja latensi yang tidak sensitif, yang hampir tidak Anda alami di ruang SAP. Dengan meningkatnya throughput Azure VM dan peningkatan beban kerja yang dihasilkan VM ini, jenis penyimpanan ini tidak dipertimbangkan untuk penggunaan dengan skenario SAP lagi. Matriks kemampuan untuk beban kerja SAP terlihat seperti:
Kemampuan | Komentar | Catatan/Tautan |
---|---|---|
VHD berbasis OS | Tidak cocok | - |
Disk data | Tidak cocok | - |
Direktori transportasi global SAP | No | Tidak didukung |
SAP sapmnt | TIDAK | Tidak didukung |
Penyimpanan cadangan | Cocok | - |
Berbagi/disk bersama | Tidak tersedia | Memerlukan Azure Files atau pihak ketiga |
Ketahanan | LRS, GRS | Tidak ada ZRS yang tersedia untuk disk |
Latensi | tinggi | Terlalu tinggi untuk penggunaan DBMS, direktori Transportasi Global SAP, atau sapmnt/saploc |
SLA IOPS | No | - |
IOPS maksimum per disk | 500 | Tidak bergantung pada ukuran disk |
SLA throughput | No | - |
Bersertifikat HANA | No | - |
Rekam jepret disk dimungkinkan | Ya | - |
Rekam jepret VM Azure Backup dimungkinkan | Ya | - |
Biaya | Kurang Penting | - |
Ringkasan: HDD standar adalah jenis penyimpanan Azure yang hanya akan digunakan untuk menyimpan cadangan SAP. Ini hanya akan digunakan sebagai VHD dasar untuk sistem yang agak tidak aktif, seperti sistem yang tidak digunakan lagi untuk mencari data di mana saja. Tetapi, pengembangan aktif, QA, atau VM produksi tidak boleh didasarkan pada penyimpanan tersebut. File database juga tidak boleh dihosting di penyimpanan tersebut
Batas Azure VM dalam lalu lintas penyimpanan
Berlawanan dengan skenario lokal, jenis VM individual yang Anda pilih, memainkan peran penting dalam bandwidth penyimpanan yang dapat Anda capai. Untuk berbagai jenis penyimpanan, Anda perlu mempertimbangkan:
Jenis penyimpanan | Linux | Windows | Komentar |
---|---|---|---|
HDD Standar | Ukuran untuk VM Linux di Azure | Ukuran untuk VM Windows di Azure | Kemungkinan sulit mencapai batas penyimpanan VM sedang atau besar |
SSD Standar | Ukuran untuk VM Linux di Azure | Ukuran untuk VM Windows di Azure | Kemungkinan sulit mencapai batas penyimpanan VM sedang atau besar |
Penyimpanan Premium | Ukuran untuk VM Linux di Azure | Ukuran untuk VM Windows di Azure | Mudah mencapai batas VM throughput penyimpanan atau IOPS dengan konfigurasi penyimpanan |
SSD v2 Premium | Ukuran untuk VM Linux di Azure | Ukuran untuk VM Windows di Azure | Mudah mencapai batas VM throughput penyimpanan atau IOPS dengan konfigurasi penyimpanan |
Penyimpanan disk Ultra | Ukuran untuk VM Linux di Azure | Ukuran untuk VM Windows di Azure | Mudah mencapai batas VM throughput penyimpanan atau IOPS dengan konfigurasi penyimpanan |
File Azure NetApp | Ukuran untuk VM Linux di Azure | Ukuran untuk VM Windows di Azure | Lalu lintas penyimpanan menggunakan bandwidth throughput jaringan dan bukan bandwidth penyimpanan! |
Azure Premium Files | Ukuran untuk VM Linux di Azure | Ukuran untuk VM Windows di Azure | Lalu lintas penyimpanan menggunakan bandwidth throughput jaringan dan bukan bandwidth penyimpanan! |
Sebagai batasan, Anda perlu mencatat bahwa:
- Semakin kecil VM, semakin sedikit disk yang dapat Anda pasang. Pembatasan ini tidak berlaku untuk Azure NetApp Files. Karena berbagi NFS atau SMB dipasang, Anda tidak akan menemukan batas jumlah volume bersama yang akan dipasang
- VM memiliki batas throughput I/O dan IOPS yang dapat dilampaui secara mu8dah dengan disk penyimpanan premium dan disk Ultra
- Dengan Azure NetApp Files dan Azure Premium Files, lalu lintas ke volume bersama menggunakan bandwidth jaringan VM dan bukan bandwidth penyimpanan
- Dengan volume NFS besar di ruang kapasitas TiB dua digit, throughput yang mengakses volume tersebut dari satu VM akan tetap stabil berdasarkan batas Linux untuk satu sesi yang berinteraksi dengan volume bersama.
Saat meningkatkan Azure VM dalam siklus hidup sistem SAP, Anda harus mengevaluasi batas throughput IOPS dan penyimpanan dari jenis VM baru dan lebih besar. Dalam beberapa kasus, Anda juga dapat menyesuaikan konfigurasi penyimpanan dengan kemampuan baru Azure VM.
Striping atau non-striping
Membuat stripe yang ditetapkan dari beberapa disk Azure ke dalam satu volume yang lebih besar memungkinkan Anda untuk mengakumulasi IOPS dan throughput masing-masing disk ke dalam satu volume. Ini hanya digunakan untuk penyimpanan standar Azure dan penyimpanan premium Azure. Disk Azure Ultra tempat Anda dapat mengonfigurasi throughput dan IOPS yang terlepas dari kapasitas disk tidak memerlukan penggunaan set stripe. Volume bersama berdasarkan NFS atau SMB tidak dapat di-stripe. Karena sifat non-linier throughput dan IOPS penyimpanan premium Azure, Anda dapat memprovisikan kapasitas yang lebih kecil dengan IOPS dan throughput yang sama daripada disk penyimpanan premium Azure tunggal besar. Itu adalah metode untuk mencapai throughput atau IOPS yang lebih tinggi dengan biaya lebih rendah menggunakan penyimpanan premium Azure. Misalnya, pemberian garis di dua disk penyimpanan premium P15 akan menghasilkan throughput:
- 250 MiB/detik. Volume tersebut akan memiliki kapasitas 512 GiB. Jika ingin memiliki satu disk yang memberi Anda throughput 250 MiB per detik, Anda harus memilih disk P40 dengan kapasitas 2 TiB.
- 400 MiB/detik dengan menggarisi empat disk penyimpanan premium P10 dengan kapasitas keseluruhan 512 GiB dengan garis. Jika Anda ingin memiliki satu disk dengan throughput minimum 500 MiB per detik, Anda harus memilih disk penyimpanan premium P60 dengan 8 TiB. Karena biaya penyimpanan premium mendekati linear dengan kapasitas, Anda dapat merasakan penghematan biaya dengan menggunakan garis.
Beberapa aturan perlu diikuti saat pembuatan garis:
- Tidak ada redundansi penyimpanan yang dikonfigurasi dalam VM yang harus digunakan karena penyimpanan Azure membuat disk data tetap redundan sudah di backend penyimpanan Azure
- Disk yang diterapkan pada set stripe harus memiliki ukuran yang sama
- Dengan disk Premium SSD v2 dan Ultra, kapasitas, IOPS yang disediakan dan throughput yang disediakan harus sama
Striping di beberapa disk yang lebih kecil adalah cara terbaik untuk mencapai rasio harga/performa yang baik menggunakan penyimpanan premium Azure. Dipahami bahwa striping dapat memiliki beberapa penyebaran tambahan dan overhead manajemen.
Untuk rekomendasi ukuran garis tertentu, baca dokumentasi untuk DBMS yang berbeda, seperti Konfigurasi penyimpanan komputer virtual Azure SAP Hana.
Langkah berikutnya
Baca artikel: