Başlangıç > Storage, VMware > 188: mClock ve IOPS Limit

188: mClock ve IOPS Limit

Bir önceki yazıda, “noisy neighbour” konusuna kısaca değinmiştik (buradan erişebilirsiniz). VMware, vSphere 4.1 versiyonu ile birlikte SIOC (Storage I/O Control) modülünü devreye aldı ve sanal sunucuların disk trafiklerini kontrol altında tutabilmek adına ilk adımlarını attı. Ancak ilk versiyonun en büyük eksikliği, sadece aynı ESXi sunucusu üzerinde olan VM’ler arasında trafik önceliklendirmesi yapabiliyordu. vSphere 5.0 versiyonunda, block storage desteğinin yanında NFS desteği de geldi ve share değerleri artık küme seviyesinde tanımlanabilir hale getirildi. Bunun üzerine oturtulan storage DRS ile de otomatik olarak sanal sunucuların konumlandırılması veya taşınması sağlandı.

Disk kaynaklarını bir kenara bırakıp, kısa bir süreliğine CPU ve bellek kaynaklarının önceliklendirilmesine bakalım. VMware çok uzun bir süredir, compute kaynaklarının önceliklendirilmesi konusunda üç farklı parametrenin etkin bir bileşkesini kullanıyor; reservation, share ve limit değerleri.

  • Reservation değeri, bir VM’e minimumda garanti edilen bellek (MB cinsinden) veya CPU (MHz cinsinden) kaynağını tanımlar.
  • Limit değeri, bir VM’in maksimum kullanabileceği kaynak miktarını belirler.
  • Share değeri, darboğaz yaşandığı durumlarda VM’lerin, kaynak havuzundan hangi oranlar ile kaynak alabileceğini belirler.

Bu üç parametre, bir arada gayet verimli bir şekilde, sıkışma yaşandığı durumlarda önceliklendirme yapabilmektedir. Burada, disk kaynaklarına oranla bir avantaj söz konusu çünkü compute kaynaklarında üst sınırınız bellidir, ESXi sunucunuzun veya kümenizin CPU ve bellek kapasitesi kadardır, oranlama bu üst değer üzerinden yapılır ve her bir VM sisteme girdiğinde veya çıktığında hesaplamalar yenilenir. Ancak disk kaynaklarında, SAN platformunun size her hangi bir zaman diliminde ne kadar IOPS verebileceği sabit değildir, dalgalanmalar gösterir. İşte bu durum, VMware mühendislerini vSphere 5.5 versiyonunda tamamen yine bir I/O scheduler algoritması (mClock) geliştirmeye itmiştir.

Bu yeni algoritma beraberinde pek yeni özellikler getirmiş olsa da, daha önceden yapılabilen bazı konfigürasyonları da kompleks hale getirmiştir. Bugün IOPS limitleme ile ilgili değişimden bahsedeceğim.

Öncelikle bahsetmeliyim ki, IOPS limitleme SIOC tarafından gerçekleştirilen bir yetenek değildir, tamamen vmkernel üzerinde gerçekleşir. Yani SIOC açık olmak zorunda değildir ilgili datastore üzerinde. Aynı zamanda, SIOC’da olduğu gibi, tanımlanan değerlerin geçerli olması için belirlenmiş threshold’ların aşılmasına da gerek yok, siz değeri verdiğiniz anda aktif olacaktır.

vSphere 5.5 için konuşursak, sanal sunucunun, farklı VMDK’ler üzerinden aynı datastore’lara tanımlı toplam IOPS limitleri üzerinden hesaplama yapılır. Bir örnek ile açıklamak daha uygun olacaktır, aşağıdaki gibi bir VM hayal edelim ve belirtildiği şekilde IOPS limitleri tanımlanmış olsun.

IOPSLimit

VMDK değil, datastore seviyesinde düşündüğümüzden, DS1 isimli datastore’a toplamda 2000 IOPS gerçekleştirilebilecek. Ancak DS2’de bir adet disk 100 IOPS ile limitli olmasına rağmen, VMDK5 unlimited olarak tanımlı olduğundan dolayı, bu VM DS2 datastore’una sınırsız IOPS yapabilecektir. Bu konu ile ilgili VMware makalesine de buradan erişebilirsiniz.

Not: Yaptığım testlerde, yukarıdaki mantığın vSphere 5.5 için geçerli olduğunu ancak vSphere 6 için geçerli olmadığını gördüm. “Her VMDK kendi bacağından asılır” mantığı işliyor. Aşağıdaki grafikte detaylarını görebilirsiniz. Bunun ile ilgili resmi bir makale de bulamadım.

Limitleme konusunda en önemli değişiklik ise aslında IO kavramına getirildi. Bir IO çok farklı boyutlarda gerçekleşebileceğinden dolayı, disk sistemi ve latency üzerinde etkileri de farklı olacaktır. Bunu baz alarak da VMware, I/O’ya ortalama bir değer biçerek (32KB) IOPS hesaplamalarını bu değer üzerinden yapmaya başladı (64 KB=2 IOPS gibi). Bu değer sadece hesaplamalarda kullanılan bir değer, gerçekten I/O’yu 32’lik boyutlarda parçalamıyor. Hesaplama açısından da ilgili Excel formülünü verebiliriz: ROUNDUP((IO Size/32);0).

Burada can alıcı nokta, siz diskinize 1000 IOPS verdiğinizi düşünebilirsiniz ancak uygulama tarafında büyük boyutlu IO gerçekleştiriliyorsa, efektif limitiniz bunun çok çok aşağısında olabilir ve darboğaz yaşayabilirsiniz. Bu yüzden vSphere 5.5 ve sonrasında IOPS limit tanımlarken son derece dikkatli yapmanız gerekmektedir.

Bir öneri, eğer IOPS reservasyon kullanma niyetiniz yoksa yada 5.1 ile yapabildikleriniz size yetiyor ise, ESXi üzerinde advanced bir parametre ile mClock algoritmasını kapatabilirsiniz ve daha kolay ve anlaşılır bir şekilde limit tanımlayabilirsiniz. Bunun için Disk.ScheduleWithReservation değerini 0 yapabilirsiniz.

mclock

Burada bahsettiklerimizi pratikte de görmekte fayda var deyip, demo ortamında test ettim. Ortamda iki adet vSphere 6 Update 1 sunucu bulunuyor. Bu ESXi sunucularından biri normal iken (ESX01 diyelim) diğerinde mClock algoritmasını kapatıp, normal scheduler ‘ı aktif hale getirdim (bu da ESX02 olsun). Bu küme üzerine konumlandırdığım bir VM içerisinde de IOMeter ile yük oluştururken, sanal sunucuyu hostlar arasında gezintiye çıkardım. Elde ettiğim değerler aşağıdaki gibi;

mclock2

Alan 1: VM ESX01 üzerinde ve her hangi bir limit uygulanmıyor. Kullanılan IOMeter parametreleri; 5 Outstanding IO, 16 KB IO Size, %67 Read, %100 Random. Sonuç olarak toplamda 6000-7000 IOPS elde ettim.

Alan 2: VM ESX01 üzerinde ve diske 2000 IOPS limit uyguladım. Kullanılan IOMeter parametreleri; 5 Outstanding IO, 16 KB IO Size, %67 Read, %100 Random. Sonuç olarak read ve write requestlerin toplamının 2000 civarlarına limitlendiğini gördüm.

Alan 3: Aynı konfigürasyonda ama sadece 16 KB’lık IO boyutunu 128’e çıkarttım ve beklendiği gibi IO limitim 2000 olmasına rağmen gerçek yapabildiğim 500 mertebelerine düştü.

Alan 4: 128 KB’lık yük devam ederken, sunucuyu ESX02 sunucusuna taşıdım ve mClock artık devrede olmadığından IO değerlerim yine 2000 mertebelerine çıktı.

Alan 5: IO boyutunu 16 KB’a indirdim ve ESX02 sunucusu üzerinde hiçbir etkisi olmadığını gördüm.

Alan 6: VM’i ESX01 üzerine taşıdım ve yeni bir VMDK ekledim (unlimited) ve bunun ilk sanal diskin gerçekleştirebildiği efektif IO limitini değiştirmediğini gördüm. Daha sonraki denemelerimde de sadece ve sadece ilgili diskin limitini değiştirdiğimde efektif olduğunu gözlemledim. vSphere 5.5’de ise, VMware makalesinde belirtildiği şekilde gerçekleştiğini gördüm.

Umarim, çok kolay görünüp arka planda beklenmedik problemlere sebebiyet verebilecek bir konu olan IOPS limitasyon konusunda fikir verebilmişimdir.

Kategoriler:Storage, VMware Etiketler:
  1. tayfundeger
    29.02.2016, 20:54

    Çok güzel ve değerli bir yazı. Ufak bir bilgi vermek istiyorum. SIOC’un tanımlanması durumunda, virtual machine’ler IO talep ettiği halde IO alamayacağı için hypervisor bunu latency olarak algılayacaktır. Bu durum vROPS kullanılan ortamlarda risk olarak gözükmektedir. Ayrıca SIOC’un enable edildiği ortamlarda yoğun IO taleperlerini durduramadığını buna bağlı olarakda ESXi host’un not responding duruma girdiğini gördüğüm case’ler oldu. Hatta bazı forumlarda SIOC’un kernel command latency’i arttırıp ESXi host’un performansını düşürdüğünü bile okumuştum. En son bölümde belirttiğin gibi beklenmedik problemlere sebebiyet olabilecek bir feature. Eline sağlık.

    • 01.03.2016, 11:19

      Doğrudur, vmkernel’ın üzerine ekstra yük bindirecektir. Yoğun yük altında vSphere 6’nın verdiği tepkiyi de bir ara test edeyim :)

  1. 06.03.2016, 18:29

Bir Cevap Yazın

Aşağıya bilgilerinizi girin veya oturum açmak için bir simgeye tıklayın:

WordPress.com Logosu

WordPress.com hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Google+ fotoğrafı

Google+ hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Twitter resmi

Twitter hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

Facebook fotoğrafı

Facebook hesabınızı kullanarak yorum yapıyorsunuz. Çıkış  Yap /  Değiştir )

w

Connecting to %s

%d blogcu bunu beğendi: