VMware VMFS5 ve LUN boyutlandırma - birden çok küçük veri deposu mu, yoksa 1 büyük veri deposu mu?

VMFS5 artık bir VMFS birimi için 2 TB sınırına sahip olmadığında, hangi senaryonun genel olarak daha yararlı olacağını düşünüyorum: -

• Daha büyük boyutlu daha az LUN veya
• Daha küçük boyutlu daha fazla LUN.

Benim durumumda, 600GB disklere sahip yeni bir 24 disk depolama dizim var. RAID10'u kullanacağım, kabaca 7.2 TB ve 1 büyük 7 TB veri deposu veya her biri 1 TB'lık birden fazla mağaza ile gidip gitmemeye karar vermeye çalışacağım.

Her yaklaşımın artıları ve eksileri nelerdir?

Güncelleme : Tabii ki, hesaplamalara sıcak yedekler eklemeyi ihmal ettim, bu yüzden 7,2 TB'ın biraz altında olacak, ancak genel fikir aynı. :-)

Güncelleme 2 : 60 VM ve 3 ana bilgisayar var. Hiçbir VM'm özellikle G / Ç yoğun değildir. Çoğu web / uygulama sunucusu ve izleme (munin / nagios), minimum yüke sahip 2 Windows DC gibi şeylerdir. DB sunucuları ÇOK düşük G / Ç gereksinimlerine sahip olmadıkça nadiren sanallaştırılır. Şu anda sahip olduğumuz tek sanal DB sunucusunun bir MSSQL kutusu olduğunu ve bu kutudaki DB'nin <1GB olduğunu düşünüyorum.

Güncelleme 3 : Dizi ve FC bağlantısı hakkında daha fazla bilgi. Dizi bir IBM DS3524, her biri 2 GB önbellekli 2 denetleyicidir. Denetleyici başına 4x 8Gbit FC bağlantı noktası. Her ESXi ana bilgisayarında 2x 4Gbit FC HBA bulunur.

Kaç tane VM'ye sahip olduğunuzu veya ne yapacaklarını belirtmediniz. Bu bilgi olmasa bile, blok boyutu / performans, çekişme ve esneklik nedenleriyle büyük bir LUN yapmaktan kaçınırım.

Masaüstü bilgisayarları değil sunucuları sanallaştıracağınızı varsayacağım, tamam mı? Sonra, depolama alanınıza erişmek ve vCenter Server tarafından yönetilmesini sağlamak için birkaç ESX / ESXi sunucusu kullanacağınızı varsayacağım.

LUN boyutuna ve VMFS sayısına karar verirken, birkaç faktörü dengelersiniz: performans, yapılandırma esnekliği ve kaynak kullanımı, altyapınızın desteklenen maksimum yapılandırması ile sınırlıdır.

1 VM ila 1 LUN / VMFS eşleştirmesi ile en iyi performansı elde edebilirsiniz. Aynı VMFS'deki makineler arasında rekabet yoktur, kilitleme çekişmesi yoktur, her yük ayrılır ve hepsi iyi olur. Sorun, ungodly miktarda LUN'ları yöneteceğiniz, desteklenen maksimum sınırlara vurabileceğiniz, VMFS yeniden boyutlandırma ve taşıma ile baş ağrıları yaşayabileceğiniz, yetersiz kaynaklara sahip olmanız (VMFS'deki bu tek yüzde nokta boş alan eklenir) ve genellikle yönetmek iyi değil.

Diğer uç nokta ise her şeyi barındırmak için tasarlanmış büyük bir VMFS. Bu şekilde en iyi kaynak kullanımını elde edersiniz, VMFS Y boştayken VMFS X'in nerede ve sorunların etkin nokta olduğu yerlerde neyin dağıtılacağına karar vermede sorun olmaz. Maliyet toplu performans olacaktır. Neden? Kilitleme yüzünden. Bir ESX belirli bir VMFS'ye yazarken, diğeri IO'yu tamamlamak ve yeniden denemek zorunda kaldığı süre boyunca kilitlenir. Bu performansa mal olur. Oyun alanı / test ve geliştirme ortamlarının dışında depolama yapılandırmasına yanlış bir yaklaşım vardır.

Kabul edilen uygulama, bir dizi sanal makineyi barındıracak kadar büyük veri depoları oluşturmak ve kullanılabilir depolama alanını uygun boyutta parçalara bölmektir. VM'lerin sayısı VM'lere bağlıdır. Bir VMFS üzerinde bir veya birkaç kritik üretim veri tabanı isteyebilirsiniz, ancak aynı veri deposuna üç veya dört düzine test ve geliştirme makinesine izin verebilirsiniz. Veri deposu başına VM sayısı ayrıca donanımınıza (disk boyutu, rpm, denetleyici önbelleği, vb.) Ve erişim kalıplarına da bağlıdır (belirli bir performans düzeyi için aynı VMFS'de posta sunucularından çok daha fazla web sunucusu barındırabilirsiniz).

Daha küçük veri depolarının da bir avantajı daha vardır: veri deposu başına fiziksel olarak çok fazla sanal makineyi tıkanmasını önlerler. Hiçbir yönetim baskısı, yarım terabaytlık bir depoya ekstra terabayt sanal disk sığmayacaktır (en azından ince provizyon ve veri tekilleştirme hakkında bilgi duyana kadar).

Bir şey daha var: Bu veri depolarını oluştururken tek bir blok boyutunda standartlaşın. Veri depolarında bir şeyler yapmak ve çirkin "uyumlu olmayan" hataları görmek istediğinizde, daha sonra birçok şeyi basitleştirir.

Güncelleme : DS3k aktif / pasif kontrolörlere sahip olacaktır (yani herhangi bir LUN, A veya B kontrolörü tarafından sunulabilir, sahip olmayan kontrolörden LUN'a erişim performansı cezasına neden olur), bu nedenle çift sayıda LUN'a sahip olmak için ödeme yapar kontrolörler arasında eşit olarak dağıtılır.

20 VM / LUN ile başlayarak 20 ya da daha fazla alana sahip olabileceğini hayal edebiliyorum.

Sorunuzun kısa cevabı şudur: Her şey IO modellerinizin ne olduğuna bağlıdır ve bu ortamınıza özgü olacaktır.

Buraya bir göz atmanızı öneririm http://www.yellow-bricks.com/2011/07/29/vmfs-5-lun-sizing/, çünkü bu beklenen IOPS'nizi ve kaç LUN'un uygun olabileceğini düşünmenize yardımcı olabilir. Bununla birlikte, eğer dikkatli olursanız, bazı insanlar çok sayıda LUN'a sahip olmanızı önerir (Önceki bir cevaba düzeltmem onaylanırsa, dizi tarafında LUN IO kuyruklarına bakın). Kabul etme eğilimindeyim, ancak daha sonra bunları tek / birkaç VMFS birimine genişletmeye devam edeceğim (FUD'nin uzantılar ve diğer VMFS sınırlarına inanma http://virtualgeek.typepad.com/virtual_geek/2009/03 /vmfs-best-practices-and-counter-fud.html). Bu, vSphere içindeki tek / birkaç veri deposunu yönetme avantajına sahip olacak ve vSphere, VM'leri her kapsamın ilk bloğundan başlayarak kullanılabilir uzantılar üzerinde otomatik olarak dengelediğinden, performans avantajı IO'nuzu birden çok LUN'a yayıyor.

Dikkate alınacak başka bir şey ... Hiçbir VM'nin özellikle IO yoğun olmadığını söylüyorsunuz. Bu göz önüne alındığında, her iki dünyanın (alan ve hız) en iyisini elde etmek için RAID5 ve RAID10'un bir kombinasyonunu düşünebilirsiniz.

Ayrıca, sanal makinelerinizi birden çok VMDK ile yapılandırdıysanız, işletim sistemi ve uygulama IO kalıpları bu sanal disklere (örn. İşletim sistemi, web, DB, günlükler vb. Her biri ayrı bir VMDK'da) yayılmışsa, her VMDK'yı fiziksel LUN'un IO yeteneklerine uygun farklı bir veri deposu (ör. RAID5 üzerinde işletim sistemi, RAID10 üzerinde günlükler). Her şey, temel bir disklerin mekanik davranışından yararlanmak için benzer IO kalıplarını bir arada tutmakla ilgilidir, örneğin, bir VM'deki günlük yazma işlemleri, başka bir VM'deki web okuma oranlarınızı etkilemez.

Bilginize ... Eğer yapabilirsiniz başarıyla DB sunucularında Sanallaştırma, sadece IO desenleri ve IOPS oranları ve IO olduğunu uygun bir LUN'a hedef analiz etmek gerekir; LUN'un halihazırda yaptığı IO modellerinin ve IOPS'un farkında olarak. Birçok yöneticinin fakir DB performansı için virtualiseation suçlarlar neden çünkü This is ... onlar dikkatle IO / IOPS hesaplamak etmedi zaman birden çok sunucu oluşturmak olacağını onlar paylaşılan LUN'daki koydu (yani. O yöneticilerimizin hatası değil, sanallaştırma hatası ).

Her birimin (LUN) kendi kuyruk derinliği vardır, bu nedenle IO çekişmesini önlemek için birçok uygulama daha küçük LUN kullanır. Bununla birlikte, bir veri deposu span LUN'larını kolayca yapabilirsiniz. Daha büyük (ve daha az) VMWare veri depolarının dezavantajı, bildiğim kadarıyla, eşzamanlı olarak açılabilecek VM'lerin sayısı üzerinde bazı sınırlarla karşılaşabilmenizdir.

Diğer bir husus denetleyici performansıdır. Özellikle SAN'ınızı bilmiyorum, ancak çoğu SAN'lar bir LUN'un aynı anda tek bir denetleyiciye ait olmasını gerektirmiyorsa. Denetleyiciler arasındaki iş yükünüzü dengeleyebilmeniz için sistemde yeterli LUN'a sahip olmak istiyorsunuz.

Örneğin, yalnızca bir LUN'niz varsa, aynı anda yalnızca bir etkin denetleyici kullanırsınız. Diğeri, yapacak hiçbir şeyi olmadığı için boşta otururdu.

İki LUN'unuz vardı, ancak biri diğerinden daha yoğun olsaydı, her iki denetleyiciyi de kullanırdınız, ancak eşit olarak kullanmazsınız. Daha fazla LUN ekledikçe denetleyiciler iş yükünü daha eşit bir şekilde paylaşır.

Sizin için özel tavsiyeler:

VM'leriniz performans gereksinimleri açısından nispeten aynıdır. Denetleyici başına bir tane olmak üzere iki LUN yaratırım. VM'leri ilk LUN'a koymaya başlayın ve VM'ler yerleştikçe zaman içinde G / Ç gecikmesini ve kuyruk derinliğini ölçün. İkinci LUN'u henüz kullanmayın. LUN'u doldurmaya devam edin 1. LUN'un dolu olduğu performans göstergelerini görmeye başladığınız bir noktaya ulaşacaksınız ya da VM'lerinizin yarısını o LUN'a geçirmiş olacaksınız ve yine de performansı koruyacaksınız.

Performans sorunları görürseniz, VM'lerin% 30'unu LUN 1'den kaldırıp LUN 2'ye taşıyacağım. Sonra LUN 2'yi aynı şekilde doldurmaya başlayacağım. Gerekirse LUN 3'e gidin ... bu mantıklı mı? Fikir, şekerleme odası için kabaca% 30 ek yük ile birlikte belirli bir LUN'da maksimum VM yoğunluğu elde etmektir.

Ayrıca, ağır vuran VM'ler için bir çift "yüksek performanslı" LUN yaparım. Yine, iş yükünü paylaşmak için denetleyici başına bir tane.

Yukarıdaki açıklamalarınıza dayanarak, 1 veri deposu ile iyi olmalısınız. 60 vm 3 üzerinden ev sahibi o kadar da kötü değil (20: 1). Bununla birlikte, fiber anahtarınızın en az 8Gb anahtarı olması koşuluyla, finansal olarak mümkünse HBA'ları 8Gb'ye yükseltmenizi öneririm.

Olduğu söyleniyor, ben dizi 3 veritasları değilse en az 2 yapmak istiyorum. Her sunucu vMotion için diğerlerine erişerek, sunucu başına 1 veri deposu. IBM dizisi hakkında fazla bir şey bilmiyorum; EMC ile her veri deposu için 3 LUN içeren tek bir RAID10 grubu oluşturacağım. Bu kurulumla, 8 Gb HBA'lara sahip ana bilgisayar, yüksek G / Ç sistemleriniz için harika olurdu.

1 veri deposu / sunucu yapabilirsiniz ve bunu kendim yapmak bazı örnekler vardır, ama bunu sadece özel sunucularda SAN çoğaltma ile yapıyorum. VMotion için 9 sunucu üzerinde 87 farklı veri deposunu yönetmek, kurulumu yaptığınızda kafa karıştırıcı olur! Vm'lerin çoğu, ihtiyaç duydukları alana bağlı olarak 5-10 sunuculu paylaşılan veri depolarında.

Son bir not. Yük devretme çiftinde / kümesinde veya yük dengelemesinde herhangi bir sunucunuz varsa, bunları farklı veri depolarında isteyeceksiniz. Veri deposunun başarısız olmasını istemezsiniz ve sonra sunucunuz olmadan bırakılırsınız. Kuşkusuz, diziyi kaybederseniz, her şeyi kaybettiniz, ancak bu yüzden yedekliyoruz, değil mi?