Merencanakan volume pada Azure Stack HCI dan kluster Windows Server
Berlaku untuk: Azure Stack HCI, versi 22H2 dan 21H2; Windows Server 2022, Windows Server 2019
Artikel ini memberikan panduan tentang cara merencanakan volume kluster untuk memenuhi kebutuhan performa dan kapasitas beban kerja Anda, termasuk memilih sistem file, jenis ketahanan, dan ukurannya.
Catatan
Ruang Penyimpanan Langsung tidak mendukung server file untuk penggunaan umum. Jika Anda perlu menjalankan server file atau layanan generik lainnya di Storage Space Direct, konfigurasikan di komputer virtual.
Ulasan: Apa itu volume
Volume adalah tempat meletakkan file yang dibutuhkan beban kerja Anda, seperti file VHD atau VHDX untuk mesin virtual Hyper-V. Volume menggabungkan drive pada kumpulan penyimpanan guna memperkenalkan toleransi terhadap kegagalan, skalabilitas, serta keuntungan performa dari Storage Spaces Direct, teknologi penyimpanan berbasis perangkat lunak di balik Azure Stack HCI dan Windows Server.
Catatan
Kami menggunakan istilah "volume" untuk merujuk baik ke volume maupun disk virtual di bawahnya, termasuk fungsionalitas yang disediakan oleh fitur Windows bawaan lainnya seperti Cluster Shared Volumes (CSV) dan ReFS. Memahami perbedaan tingkat implementasi ini tidak diperlukan untuk merencanakan dan menyebarkan Storage Spaces Direct dengan sukses.
Semua volume dapat diakses oleh semua server di kluster pada saat yang bersamaan. Setelah dibuat, mereka muncul di C:\ClusterStorage\ di semua server.
Memilih berapa banyak volume yang akan dibuat
Sebaiknya, buat jumlah volume dalam kelipatan dari jumlah server di kluster Anda. Misalnya, jika Anda memiliki 4 server, Anda akan mengalami performa yang lebih konsisten dengan total 4 volume daripada dengan 3 atau 5. Hal ini memungkinkan kluster untuk mendistribusikan volume "kepemilikan" (satu server menangani orkestrasi metadata untuk setiap volume) secara merata di antara server.
Sebaiknya batasi total jumlah volume hingga 64 volume per kluster.
Memilih sistem file
Sebaiknya gunakan Resilient File System (ReFS) baru untuk Storage Spaces Direct. ReFS adalah sistem file utama yang dibuat khusus untuk virtualisasi dan menawarkan banyak keuntungan, termasuk akselerasi performa dramatis dan perlindungan bawaan terhadap kerusakan data. Ini mendukung hampir semua fitur utama NTFS, termasuk Deduplikasi Data pada Windows Server versi 1709 dan yang lebih baru. Lihat tabel perbandingan fitur ReFS untuk detailnya.
Jika beban kerja Anda memerlukan fitur yang belum didukung oleh ReFS, Anda dapat menggunakan NTFS sebagai gantinya.
Tip
Volume dengan sistem file yang berbeda dapat hidup berdampingan dalam kluster yang sama.
Memilih jenis ketahanan
Volume di Storage Spaces Direct memberikan ketahanan agar terlindung dari masalah perangkat keras, seperti kegagalan drive atau server, dan untuk mengaktifkan ketersediaan berkelanjutan selama pemeliharaan server, seperti pembaruan perangkat lunak.
Catatan
Jenis ketahanan yang dapat Anda pilih tidak tergantung pada jenis drive yang Anda miliki.
Dengan dua server
Dengan dua server di kluster, Anda dapat menggunakan mirroring dua arah atau Anda dapat menggunakan ketahanan berlapis.
Mirroring dua arah menyimpan dua salinan dari semua data, satu salinan dalam drive di setiap server. Efisiensi penyimpanannya adalah 50 persen; untuk menulis 1 TB data, Anda membutuhkan setidaknya 2 TB kapasitas penyimpanan fisik di kumpulan penyimpanan. Mirroring dua arah dapat dengan aman menoleransi satu kegagalan perangkat keras pada satu waktu (satu server atau drive).
Ketahanan berlapis memberikan ketahanan data antara server dengan mirroring dua arah, lalu menambahkan ketahanan dalam server dengan mirroring dua arah atau paritas mirror-accelerated. Nesting menyediakan ketahanan data bahkan ketika satu server sedang menghidupkan ulang atau tidak tersedia. Efisiensi penyimpanannya adalah 25 persen dengan mirroring dua arah berlapis dan sekitar 35-40 persen untuk paritas mirror-accelerated berlapis. Ketahanan berlapis dapat dengan aman menoleransi dua kegagalan perangkat keras pada satu waktu (dua drive, atau server dan drive pada server yang tersisa). Karena ketahanan data tambahan ini, kami sarankan penggunaan ketahanan berlapis pada penyebaran produksi kluster dua server. Untuk info selengkapnya, lihat Ketahanan berlapis.
Dengan tiga server
Dengan tiga server, Anda harus menggunakan mirroring tiga arah untuk toleransi kegagalan dan performa yang lebih baik. Mirroring tiga arah menyimpan tiga salinan dari semua data, satu salinan dalam drive di setiap server. Efisiensi penyimpanannya adalah 33,3 persen – untuk menulis 1 TB data, Anda membutuhkan setidaknya 3 TB kapasitas penyimpanan fisik di kumpulan penyimpanan. Mirroring tiga arah dapat dengan aman menoleransi setidaknya dua masalah perangkat keras (drive atau server) dalam satu waktu. Jika 2 simpul menjadi tidak tersedia, kumpulan penyimpanan kehilangan kuorum, karena 2/3 disk tidak tersedia, dan disk virtual tidak dapat diakses. Namun, simpul dapat tidak berfungsi dan satu atau beberapa disk pada simpul lain dapat gagal dan disk virtual tetap online. Misalnya, jika Anda melakukan reboot pada satu server ketika drive atau server lain tiba-tiba gagal, semua data tetap aman dan dapat diakses terus-menerus.
Dengan empat server atau lebih
Dengan empat server atau lebih, untuk setiap volume Anda dapat memilih apakah akan menggunakan mirroring tiga arah, paritas ganda (sering disebut "pengodean penghapusan"), atau mencampur keduanya dengan paritas mirror-accelerated.
Paritas ganda memberikan toleransi kesalahan yang sama dengan mirroring tiga arah tetapi dengan efisiensi penyimpanan yang lebih baik. Dengan empat server, efisiensi penyimpanannya adalah 50,0 persen; untuk menyimpan 2 TB data, Anda membutuhkan 4 TB kapasitas penyimpanan fisik di kumpulan penyimpanan. Ini meningkatkan efisiensi penyimpanan 66,7 persen dengan tujuh server, dan terus meningkat hingga efisiensi penyimpanan 80,0 persen. Konsekuensinya adalah pengodean paritas lebih komputasi-intensif, yang dapat membatasi performanya.
Jenis ketahanan mana yang akan digunakan tergantung pada persyaratan performa dan kapasitas untuk lingkungan Anda. Berikut adalah tabel yang meringkas performa dan efisiensi penyimpanan setiap jenis ketahanan.
| Jenis ketahanan | Efisiensi kapasitas | Kecepatan |
|---|---|---|
| Cermin |  Cermin tiga arah: 33% Cermin dua arah: 50% |
 Performa tertinggi |
| Paritas mirror-accelerated |  Tergantung pada proporsi cermin dan paritas |
 Jauh lebih lambat daripada cermin, tetapi hingga dua kali lebih cepat dari paritas ganda Ideal untuk baca dan tulis berurutan ukuran besar |
| Paritas ganda |  4 server: 50% 16 server: hingga 80% |
 Latensi I/O tertinggi & penggunaan CPU pada penulisan Ideal untuk baca dan tulis berurutan ukuran besar |
Ketika performa paling penting
Beban kerja yang memiliki persyaratan latensi ketat atau yang memerlukan banyak IOPS acak campuran, seperti database SQL Server atau mesin virtual Hyper-V yang sensitif terhadap performa, harus berjalan pada volume yang menggunakan mirroring untuk memaksimalkan performa.
Tip
Mirroring lebih cepat daripada jenis ketahanan lainnya. Kami menggunakan mirroring untuk hampir semua contoh performa kami.
Ketika kapasitas paling penting
Beban kerja yang menulis tak terlalu sering, seperti gudang data atau penyimpanan "dingin", harus berjalan pada volume yang menggunakan paritas ganda untuk memaksimalkan efisiensi penyimpanan. Beban kerja tertentu lainnya, seperti Scale-Out File Server (SoFS), infrastruktur desktop virtual (VDI), atau lainnya yang tidak menciptakan banyak lalu lintas IO acak yang melintas cepat dan/atau tidak memerlukan performa terbaik juga dapat menggunakan paritas ganda, sesuai keputusan Anda. Paritas pasti meningkatkan pemanfaatan CPU dan latensi IO, terutama pada penulisan, jika dibandingkan dengan mirroring.
Ketika data ditulis dalam jumlah besar
Beban kerja yang menulis dalam operan besar dan berurutan, seperti target arsip atau cadangan, memiliki opsi lain: satu volume dapat mencampur mirroring dan paritas ganda. Menulis sampai terlebih dahulu di bagian mirror dan secara bertahap dipindahkan ke bagian paritas. Ini mempercepat penyerapan dan mengurangi pemanfaatan sumber daya saat penulisan besar tiba dengan memungkinkan pengodean paritas komputasi-intensif terjadi dalam waktu yang lebih lama. Saat mengukur bagian-bagiannya, pertimbangkan bahwa jumlah penulisan yang terjadi sekaligus (seperti satu cadangan harian) harus dimuat dengan baik di bagian mirror. Misalnya, jika Anda menghabiskan 100 GB sekali sehari, pertimbangkan untuk menggunakan mirroring 150 GB hingga 200 GB, dan paritas ganda untuk sisanya.
Efisiensi penyimpanan yang dihasilkan tergantung pada proporsi yang Anda pilih.
Tip
Jika Anda melihat penurunan mendadak dalam performa tulis di tengah penyerapan data, itu menunjukkan bahwa bagian mirror tidak cukup besar atau bahwa paritas mirror-accelerated tidak cocok untuk kasus penggunaan Anda. Misalnya, jika performa tulis menurun dari 400 MB/s menjadi 40 MB/s, pertimbangkan untuk memperluas bagian mirror atau beralih ke mirroring tiga arah.
Tentang penyebaran dengan NVMe, SSD, dan HDD
Dalam penyebaran dengan dua jenis drive, drive yang lebih cepat menyediakan penembolokan sementara drive yang lebih lambat menyediakan kapasitas. Ini terjadi secara otomatis – untuk informasi selengkapnya, lihat Memahami cache di Storage Spaces Direct. Dalam penyebaran tersebut, semua volume pada akhirnya berada pada jenis drive yang sama – drive kapasitas.
Dalam penyebaran dengan ketiga jenis drive, hanya drive tercepat (NVMe) yang menyediakan penembolokan, sehingga tinggal dua jenis drive (SSD dan HDD) yang menyediakan kapasitas. Untuk setiap volume, Anda dapat memilih apakah itu sepenuhnya berada di tingkat SSD, sepenuhnya pada tingkat HDD, atau apakah itu mencakup keduanya.
Penting
Sebaiknya gunakan tingkat SSD untuk menempatkan beban kerja Anda yang paling sensitif terhadap kinerja pada all-flash.
Memilih ukuran volume
Kami merekomendasikan untuk membatasi ukuran setiap volume hingga 64 TB di Azure Stack HCI.
Tip
Jika Anda menggunakan solusi cadangan yang bergantung pada layanan Volume Shadow Copy (VSS) dan penyedia perangkat lunak Volsnap—seperti lazimnya beban kerja server file—pembatasan ukuran volume hingga 10 TB akan meningkatkan performa dan keandalan. Solusi cadangan yang menggunakan API RCT Hyper-V yang lebih baru dan/atau kloning blok ReFS dan/atau API SQL cadangan asli berperforma baik hingga 32 TB dan seterusnya.
Footprint
Ukuran volume mengacu pada kapasitas yang dapat digunakan, yaitu jumlah data yang dapat disimpannya. Ini disediakan oleh parameter -Size dari cmdlet New-Volume dan kemudian muncul di properti Ukuran saat Anda menjalankan cmdlet Get-Volume.
Ukuran berbeda dari footprint volume, total kapasitas penyimpanan fisik yang ditempatinya di kumpulan penyimpanan. Footprint tergantung pada jenis ketahanannya. Misalnya, volume yang menggunakan mirroring tiga arah memiliki footprint tiga kali ukurannya.
Footprint volume Anda harus dapat dimuat di kumpulan penyimpanan.
Kapasitas cadangan
Menyisakan sejumlah kapasitas di kumpulan penyimpanan yang tidak terisi memberi ruang volume untuk memperbaiki "di tempat" setelah drive gagal, sehingga meningkatkan keamanan dan performa data. Jika ada kapasitas yang memadai, perbaikan paralel segera di tempat dapat memulihkan volume ketahanan penuh bahkan sebelum drive yang gagal diganti. Hal ini terjadi secara otomatis.
Anda sebaiknya menyediakan kapasitas yang setara dengan satu drive kapasitas per server, hingga 4 drive. Anda dapat memesan lebih banyak sesuai kebijaksanaan Anda, tetapi rekomendasi minimum ini menjamin perbaikan paralel langsung di tempat untuk berhasil setelah kegagalan drive apa pun.
Misalnya, jika Anda memiliki 2 server dan Anda menggunakan drive kapasitas 1 TB, sisihkan 2 x 1 = 2 TB kumpulan sebagai cadangan. Jika Anda memiliki 3 server dan drive berkapasitas 1 TB, sisihkan 3 x 1 = 3 TB sebagai cadangan. Jika Anda memiliki 4 server atau lebih dan drive kapasitas 1 TB, sisihkan 4 x 1 = 4 TB sebagai cadangan.
Catatan
Dalam kluster dengan drive dari ketiga jenis (NVMe + SSD + HDD), Anda sebaiknya memesan kapasitas yang setara dengan satu SSD ditambah satu HDD per server, masing-masing hingga 4 drive.
Contoh: Perencanaan kapasitas
Pertimbangkan satu kluster empat server. Setiap server memiliki beberapa drive cache ditambah enam belas drive 2 TB untuk kapasitas.
4 servers x 16 drives each x 2 TB each = 128 TB
Dari 128 TB ini di kumpulan penyimpanan, kami menyisihkan empat drive, atau 8 TB, sehingga perbaikan di tempat dapat terjadi tanpa terburu-buru untuk mengganti drive setelah gagal. Ini menyisakan 120 TB kapasitas penyimpanan fisik di kumpulan, yang dapat digunakan untuk membuat volume.
128 TB – (4 x 2 TB) = 120 TB
Misalkan kita perlu penyebaran untuk meng-hosting beberapa mesin virtual Hyper-V yang sangat aktif, tetapi kita juga memiliki banyak penyimpanan dingin – yaitu file lama dan file cadangan yang perlu kita pertahankan. Karena kita memiliki empat server, mari buat empat volume.
Mari tempatkan mesin virtual pada dua volume pertama, Volume1 dan Volume2. Kami memilih ReFS sebagai sistem file (untuk pembuatan dan titik pemeriksaan yang lebih cepat) dan mirroring tiga arah untuk ketahanan guna memaksimalkan performa. Mari kita letakkan penyimpanan dingin pada dua volume lainnya, yaitu Volume 3 dan Volume 4. Kami memilih NTFS sebagai sistem file (untuk Deduplikasi Data) dan paritas ganda untuk ketahanan guna memaksimalkan kapasitas.
Kita tidak diharuskan membuat semua volume dengan ukuran yang sama, tetapi untuk kesederhanaan, kita dapat membuat semuanya berukuran 12 TB.
Volume1 dan Volume2 masing-masing menempati efisiensi 12 TB x 33,3 persen = 36 TB kapasitas penyimpanan fisik.
Volume3 dan Volume4 masing-masing menempati efisiensi 12 TB x 50,0 persen = 24 TB kapasitas penyimpanan fisik.
36 TB + 36 TB + 24 TB + 24 TB = 120 TB
Keempat volume dapat dimuat dengan tepat pada kapasitas penyimpanan fisik yang tersedia di kumpulan kami. Sempurna!
Tip
Anda tidak perlu serta-merta membuat semua volume. Anda selalu dapat memperbesar volume atau membuat volume baru nanti.
Untuk kesederhanaan, contoh ini selalu menggunakan unit desimal (basis-10), yang berarti 1 TB = 1.000.000.000.000 byte. Namun, jumlah penyimpanan dalam Windows muncul dalam unit biner (basis-2). Misalnya, setiap drive 2 TB akan muncul sebagai 1,82 TiB di Windows. Demikian juga, kumpulan penyimpanan 128 TB akan muncul sebagai 116,41 TiB. Sesuai harapan.
Penggunaan
Lihat Membuat volume di Azure Stack HCI.
Langkah berikutnya
Untuk informasi selengkapnya, lihat juga: