VMware VMFS5 dan LUN sizing - beberapa datastores yang lebih kecil, atau 1 datastore besar?

Dengan VMFS5 tidak lagi memiliki batas 2TB untuk volume VMFS, saya mempertimbangkan skenario mana yang akan lebih menguntungkan secara keseluruhan: -

• Kurang LUN dengan ukuran lebih besar, atau
• Lebih banyak LUN dengan ukuran lebih kecil.

Dalam kasus saya, saya memiliki array penyimpanan 24-disk baru dengan 600GB disk. Saya akan menggunakan RAID10, kira-kira 7.2TB, dan mencoba memutuskan apakah akan pergi dengan 1 datastore 7TB besar, atau beberapa toko masing-masing 1TB.

Apa pro dan kontra dari setiap pendekatan?

Pembaruan : Tentu saja, saya lalai memasukkan suku cadang panas ke dalam perhitungan saya, jadi itu hanya di bawah 7.2TB, tetapi ide umumnya sama. :-)

Pembaruan 2 : Ada 60 VM dan 3 host. Tidak satu pun dari VM kami yang intensif I / O. Kebanyakan dari mereka adalah server web / aplikasi, dan juga hal-hal seperti pemantauan (munin / nagios), 2 Windows DC dengan beban minimal, dan sebagainya. Server DB jarang tervirtualisasi kecuali mereka memiliki persyaratan I / O yang SANGAT rendah. Saat ini saya pikir satu-satunya server DB virtual yang kami miliki adalah kotak MSSQL dan DB pada kotak itu adalah <1GB.

Pembaruan 3 : Beberapa info lebih lanjut tentang array dan konektivitas FC. Array adalah IBM DS3524, 2 pengontrol dengan masing-masing 2GB cache. 4x8Gbit FC port per controller. Setiap host ESXi memiliki HBA FC 2 x 4Gbit.

Anda tidak menentukan berapa banyak VM yang Anda miliki atau apa yang akan mereka lakukan. Bahkan tanpa informasi itu, saya akan menghindari satu membuat LUN besar untuk alasan pemblokiran / kinerja, pertengkaran dan fleksibilitas.

Saya akan menganggap Anda akan melakukan virtualisasi server, bukan desktop, oke? Selanjutnya saya akan berasumsi bahwa Anda akan menggunakan beberapa server ESX / ESXi untuk mengakses penyimpanan Anda dan mengaturnya dengan vCenter Server.

Ketika menentukan ukuran LUN dan jumlah VMFS Anda menyeimbangkan beberapa faktor: kinerja, fleksibilitas konfigurasi, dan pemanfaatan sumber daya, sementara terikat oleh konfigurasi maksimum yang didukung dari infrastruktur Anda.

Anda bisa mendapatkan kinerja terbaik dengan pemetaan 1 VM ke 1 LUN / VMFS. Tidak ada persaingan antara mesin pada VMFS yang sama, tidak ada pertikaian penguncian, setiap beban dipisahkan dan semuanya berjalan baik. Masalahnya adalah bahwa Anda akan mengelola jumlah LUN yang tidak saleh, dapat mencapai batas maksimum yang didukung, menghadapi sakit kepala dengan pengubahan ukuran dan migrasi VMFS, memiliki sumber daya yang kurang dimanfaatkan (jumlah poin tunggal tambahan ruang pada VMFS bertambah) dan umumnya menciptakan sesuatu yang tidak baik untuk dikelola.

Ekstrem lainnya adalah satu VMFS besar yang ditunjuk untuk menampung semuanya. Anda akan mendapatkan pemanfaatan sumber daya terbaik dengan cara itu, tidak akan ada masalah dengan memutuskan apa yang digunakan di mana dan masalah dengan VMFS X menjadi hot spot, sementara VMFS Y sedang menganggur. Biaya akan menjadi kinerja agregat. Mengapa? Karena terkunci. Ketika satu ESX menulis ke VMFS yang diberikan, yang lain dikunci untuk waktu yang diperlukan untuk menyelesaikan IO dan harus mencoba lagi. Ini membutuhkan kinerja. Di luar taman bermain / lingkungan uji dan pengembangan, pendekatan konfigurasi penyimpanan yang salah adalah pendekatan yang salah.

Praktik yang diterima adalah membuat datastore yang cukup besar untuk menampung sejumlah VM, dan membagi ruang penyimpanan yang tersedia menjadi potongan berukuran tepat. Berapa jumlah VM tergantung pada VM. Anda mungkin ingin satu atau beberapa basis data produksi kritis pada VMFS, tetapi memungkinkan tiga atau empat lusin mesin uji dan pengembangan ke datastore yang sama. Jumlah VMs per datastore juga tergantung pada perangkat keras Anda (ukuran disk, rpm, cache pengontrol, dll) dan pola akses (untuk tingkat kinerja tertentu Anda dapat meng-host lebih banyak server web pada VMFS yang sama dari server mail).

Datastore yang lebih kecil juga memiliki satu keuntungan lagi: mereka mencegah Anda secara fisik menjejalkan terlalu banyak mesin virtual per datastore. Tidak ada tekanan manajemen yang sesuai dengan disk virtual terabyte ekstra pada penyimpanan setengah terabyte (setidaknya sampai mereka mendengar tentang penyediaan dan deduplikasi yang tipis).

Satu hal lagi: Ketika membuat datastore tersebut distandarisasi pada ukuran blok tunggal. Ini menyederhanakan banyak hal di kemudian hari, ketika Anda ingin melakukan sesuatu di seluruh datastore dan melihat kesalahan "tidak kompatibel" yang jelek.

Pembaruan : DS3k akan memiliki pengontrol aktif / pasif (yaitu setiap LUN yang diberikan dapat dilayani baik oleh pengontrol A atau B, mengakses LUN melalui pengontrol yang tidak memiliki dikenakan penalti kinerja), sehingga akan terbayar untuk memiliki sejumlah LUN yang genap , didistribusikan secara merata di antara pengontrol.

Saya bisa membayangkan mulai dengan 15 VM / LUN dengan ruang tumbuh hingga 20 atau lebih.

Jawaban singkat untuk pertanyaan Anda adalah: itu semua tergantung pada apa pola IO Anda, dan ini akan unik untuk lingkungan Anda.

Saya sarankan Anda melihat di sini http://www.yellow-bricks.com/2011/07/29/vmfs-5-lun-sizing/ karena ini dapat membantu Anda mempertimbangkan IOPS yang Anda antisipasi dan berapa banyak LUNS yang mungkin cocok. Yang mengatakan, jika Anda berbuat salah di sisi hati-hati, beberapa orang akan menyarankan memiliki banyak LUNS (Jika koreksi saya untuk jawaban sebelumnya disetujui, lihat komentar saya LUN IO antrian di sisi array). Saya cenderung setuju, tetapi akan melangkah lebih jauh untuk kemudian membaginya menjadi satu / beberapa volume VMFS (tidak percaya FUD tentang luasan, dan batas VMFS lainnya http://virtualgeek.typepad.com/virtual_geek/2009/03 /vmfs-best-practices-and-counter-fud.html). Ini akan memiliki manfaat mengelola satu / beberapa datastore dalam vSphere dan, karena vSphere secara otomatis menyeimbangkan VMs dengan luasan yang tersedia dimulai dengan blok pertama dari setiap tingkat, manfaat kinerja menyebarkan IO Anda ke beberapa LUN.

Ada hal lain yang perlu dipertimbangkan ... Anda mengatakan tidak ada VM yang intensif IO. Dengan ini, Anda mungkin ingin mempertimbangkan kombinasi RAID5 dan RAID10, untuk mendapatkan yang terbaik dari kedua dunia (ruang dan kecepatan).

Lebih lanjut, jika Anda memiliki VM yang dikonfigurasi dengan banyak VMDK, dengan OS dan pola IO aplikasi tersebar di disk virtual tersebut (mis. OS, web, DB, log, dll. Masing-masing pada VMDK yang terpisah), Anda kemudian dapat menemukan setiap VMDK di datastore yang berbeda agar sesuai dengan kemampuan IO dari LUN fisik itu (mis. OS pada RAID5, Log on RAID10). Ini semua tentang menjaga pola IO yang sama bersama-sama untuk mengambil keuntungan dari perilaku mekanis disk yang mendasarinya sehingga, misalnya, log menulis dalam satu VM tidak memengaruhi kecepatan baca web Anda di VM lain.

FYI ... Anda dapat berhasil memvirtualisasi server DB, Anda hanya perlu menganalisis pola IO & tarif IOPS dan menargetkan IO ke LUN yang sesuai; sambil menyadari pola IO dan IOPS yang sudah dilakukan LUN. Inilah sebabnya mengapa banyak admin menyalahkan virtualisasi untuk kinerja DB yang buruk ... karena mereka tidak dengan hati-hati menghitung IO / IOPS yang akan dihasilkan beberapa server ketika mereka menempatkannya pada LUN bersama (mis. Itu kesalahan admin, bukan kesalahan virtualisasi ).

Setiap volume (LUN) memiliki kedalaman antrian sendiri, jadi untuk menghindari pertentangan IO, banyak implementasi menggunakan LUN yang lebih kecil. Yang mengatakan, Anda dapat membuat LUNs span datastore cukup mudah. Kerugian dari datastore VMWare yang lebih besar (dan lebih sedikit) adalah, sejauh yang saya tahu, bahwa Anda dapat mengalami beberapa batasan pada jumlah VM yang bisa aktif secara bersamaan.

Pertimbangan lain adalah kinerja pengontrol. Saya tidak tahu SAN Anda secara khusus, tetapi kebanyakan jika tidak semua SAN mengharuskan LUN dimiliki oleh pengontrol tunggal pada suatu waktu. Anda ingin memiliki cukup LUN pada sistem sehingga Anda dapat menyeimbangkan beban kerja Anda di antara pengontrol.

Misalnya, jika Anda hanya memiliki satu LUN, Anda hanya akan menggunakan satu kontroler aktif pada satu waktu. Yang lain akan duduk diam karena tidak ada hubungannya.

Jika Anda memiliki dua LUN, tetapi yang satu lebih sibuk dari yang lain, Anda akan menggunakan kedua pengontrol tetapi tidak sama. Saat Anda menambahkan lebih banyak LUN, pengontrol membagikan beban kerja secara lebih merata.

Saran khusus untuk Anda:

Semua VM Anda relatif sama dalam hal persyaratan kinerja. Saya akan membuat dua LUN, satu per controller. Mulailah menempatkan VM pada LUN pertama, dan ukur latensi I / O Anda dan kedalaman antrian dari waktu ke waktu saat VMs menetap. Jangan gunakan LUN kedua. Terus mengisi LUN 1. Anda akan mencapai titik di mana Anda mulai melihat indikator kinerja bahwa LUN sudah penuh, atau Anda akan memigrasi setengah dari VM Anda ke LUN itu, dan masih mempertahankan kinerja.

Jika Anda melihat masalah kinerja, saya akan menghapus 30% dari VM dari LUN 1 dan memindahkannya ke LUN 2. Kemudian mulai mengisi LUN 2 dengan cara yang sama. Pergi ke LUN 3 jika perlu ... apakah itu masuk akal? Idenya adalah untuk mencapai kepadatan VM maksimum pada LUN yang diberikan bersama dengan sekitar 30% overhead untuk ruang fudge.

Saya juga akan membuat sepasang LUN "kinerja tinggi" untuk VM berat yang memukul. Sekali lagi, satu per controller untuk berbagi beban kerja.

Berdasarkan penjelasan Anda di atas, Anda harus baik-baik saja dengan 1 datastore. 60 vm lebih dari 3 host tidak terlalu buruk (20: 1). Namun, saya sarankan Anda meningkatkan HBA ke 8Gb jika memungkinkan secara finansial pada setidaknya satu host asalkan fiber switch Anda minimal 8Gb.

Yang sedang berkata, saya akan membuat setidaknya 2 jika tidak 3 datastore pada array. 1 datastore per host, dengan semua server mengakses yang lain untuk vMotion. Saya tidak tahu banyak tentang susunan IBM; dengan EMC saya akan membuat grup RAID10 tunggal dengan 3 LUN untuk setiap datastore. Dengan pengaturan ini, host dengan HBA 8Gb akan bagus untuk sistem I / O Anda yang lebih tinggi.

Anda dapat melakukan 1 datastore / server, dan ada beberapa contoh saya melakukannya sendiri, tetapi saya hanya melakukannya dengan replikasi SAN pada server khusus. Mengelola 87 datastore berbeda di lebih dari 9 server untuk vMotion menjadi membingungkan ketika Anda mengaturnya! Mayoritas vm saya ada di datastore bersama dengan 5-10 server pada mereka tergantung pada seberapa banyak ruang yang mereka butuhkan.

Satu catatan terakhir. Jika Anda memiliki segala jenis server dalam pasangan failover / cluster atau memuat seimbang, Anda akan menginginkan mereka di datastore yang berbeda. Anda tidak ingin datastore gagal, dan kemudian dibiarkan tanpa server. Memang, jika Anda kehilangan array, Anda telah kehilangan segalanya, tapi ini sebabnya kami cadangan, kan?