Sanal veritabanı fiziksele göre yavaş mı çalışır?

Herkese Merhaba

Her kurum veya firma veritabanını sanal sunucuya taşımayı düşündüğünde bu soruyla karşı karşıya kalıyor. Doğal olarak hiç bir sistem yöneticisi en kritik iş yükünün yavaşlamasını veya kararsız çalışmasını istemez.

Fakat işin temeline inmeye başladığımızda bu korkuların kaynağının genelde yazılım ekibi olduğunu görüyoruz.

Bu yazımda Türkiye’nin Büyükşehir Belediyelerinden birinin Oracle veritabanını sanal sunucuya taşırken karşımıza gelen argümanları ve bu argümanlara Oracle Corporation’ın resmi cevaplarıyla birlikte şahsi tecrübelerimi bulacaksınız.

Veritabanı sanal sunucuları için yapılması gereken en iyi ayarları daha önce yazmış olduğum linkteki yazımda bulabilirsiniz.

red-skull-a-soul-of-a-soul-thanos-u-xenonjay54-endgame-55642560

Açıkçası “sanalda sıkıntı çıkarır” sözünü duyduğumda yazılım ekibine ben de aynı şekilde davranmak istiyorum ama tabi karşımızdakine doyurucu yanıtlar vermek gerekiyor. Bu yüzden genel olarak yazılım ekiplerinin sunduğu argümanlara yanıt vermekle başlayalım.

Varsayım 1: Oracle Vmware ortamlarındaki sistemlere destek vermiyor!

Eylül 2019’a kadar bu durum kısmen doğruydu. Oracle teknik ekibi sorunun üstesinden gelemediğinde “şu veritabanınızı bir de fiziksel sunucuya çevirip orada deneyelim” diyip elinizi kolunuzu bağlayabiliyordu.

Fakat Oracle, Eylül 2019’da VMware ile yaptığı anlaşma sonrasında, ister cloud’da ister kendi veri merkezinizdeki VMware üstündeki Oracle ürünlerine koşulsuz destek vereceğini taahhüt etti.

https://www.oracle.com/corporate/pressrelease/oow19-oracle-and-vmware-091619.html

Neden taahhüt etti? Çünkü iş yüklerinin buluta kaydığı, sanallaştırma ile çok daha efektif yönetilebildiği bir ortamda kimse Oracle’ın nazını çekmek istemiyor! Müşteriler Oracle Exadata, Oracle VM, Oracle Cloud kullanmak zorunda değil. Intel işlemci kullanıyorsanız sanallaştırma mimarisi Intel’in! Bunun üzerindeki hypervisor VMware olmuş, Oracle VM olmuş açıkçası mimari olarak fark etmiyor. Altında koşan teknoloji Intel’in VT-x ve VT-d!

Bu gelişmeler nedeniyle Oracle teknik desteği satın almışsanız bu konuda başınızın ağrımayacağına emin olabilirsiniz.

Varsayım 2: Oracle veritabanı sanal sunucuda yavaş çalışıyor!

Oracle, yaptığı testlerde bazı iş yüklerinde sanal sunucunun daha hızlı çalıştığını, bazılarında ise yavaş çalıştığını gözlemlemiş. (Oracle VM üzerinde)

https://www.oracle.com/us/technologies/virtualization/oracle-vm-for-oracle-database-2155841.pdf

Alttaki karşılaştırma grafiğinden de görebileceğiniz gibi bazı işlemlerde sanal veritabanında %80’e varan hız artışı gözlemlenirken bazı işlemlerde ise %30’a varan düşüşler söz konusu. Kısacası yazılımcıların abarttığı kadar kötü bir durum yok. En azından Oracle onlar gibi düşünmüyor.

Resim2
Peki performans farkı gerçekte de böyle mi?

Oracle veritabanını sanal sunucuya çektiğimiz büyükşehir belediyesinde 176 Milyon kayıt bulunmaktaydı.

Fiziksel veritabanında 41 Milyon kayıtta yapılan sorgu 31 saniye sürerken
Veritabanını sanala çektikten sonra 176 Milyon kayıtta yapılan sorgu sadece 6 saniye sürdü.

Eskiden fiziksel sunucu üzerinde SSD disklerde çalışıyordu şimdi ise Allflash bir depolama ünitesine taşındı. Mutlaka yeni depolama ünitesinin cache gibi etmenleri de bu sonucun alınmasında faydalı oldu ama sanal sunucuda sistemin yavaşlayacağı düşünülürken tam tersine hızlandı.

Fiziksel veritabanı HyperThreading dahil tüm çekirdekleri kullanırken sanala taşıyınca HyperThreading ile gelen fazladan x2 adet çekirdeği sanal sunucuya atamadık. Amacım cluster içerisindeki core sayısı düşük diğer ESXi host’larda acil bir durumda çalışabilmesiydi. Bu yüzden core sayısını da sanala çektiğimde düşürmüş oldum.

Kısacası depolama ünitesi hızlı olursa, CPU/Memory konusunda sanal sunucuyu boğmadığınız sürece Oracle veritabanının işlerinizi etkileyecek kadar yavaş çalışma ihtimali bence yok. Farz edelim ki fizikselde hızlı çalışsın… Ortaya çıkan fark açıkçası sanallaştırmanın getirdiği avantajları elinizin tersiyle itmenizi gerektirecek kadar fazla değil.

Şuanda müşterimiz CPU/Memory darboğazı yaşadığı anda cluster’a yeni jenerasyon bir sunucu ekleyip yazılım ekibinin müdahalesine gerek kalmadan, açık bir şekilde sistemini taşıyabilir. Eskiden bunun için 30 yere bilgi vermek, kesinti planlamak gerekiyordu. Dolayısıyla böyle bir esneklik her kurum/firma için önemlidir diye düşünüyorum.

free-disappointment-597956a41d1bc-design

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 )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.