Nedir bu Sanallaştırma? - OpenStack Yazı Dizisi - #1
sanallaştırma

Nedir bu Sanallaştırma? - OpenStack Yazı Dizisi - #1

Öncelikle bir özür borçluyum. 19 Temmuz'da yayınladığım alttaki anketin içeriği için bir kaç gün içinde yayınların başlayacağını söylemiştim. Malumunuz iş yoğunluğu ve önceliklerin değişmesi sebebiyle biraz ötelenmişti. Bu başlık ile "Sanallaştırma, Bulut Bilişim ve OpenStack" konularında güzel bir yazı dizisi başlamış olacak. Mümkün mertebe bildiklerimi, deneyimlerimi ve önemli bilgileri aktarmaya çalışacağım.

Hepimiz insanız, hatalı veya eksik olduğum noktalar olabileceğini düşünüyorum. Lütfen bu noktada yanlışlarımı düzeltmekten çekinmeyin:)


Sanallaştırma Nedir?

Bildiğiniz üzere hayatımıza bir süre önce bulut, sanal makine, sanallaştırma gibi kavramlar girdi. Esasen bu kelimeler ve dolayısıyla ilgili teknolojiler; mevcut ihtiyaçları karşılayamadığımızdan ziyade enerji verimliliği, trafik ve kaynak optimizasyonu ve maliyet-etkin kullanım gibi sebeplerden ötürü geliştirilmiş oldu.

Sanallaştırma öncesi, fiziksel sunucular tek başına kullanılırdı. Farklı servisler(uygulama, veritabanı, kuyruk, izleme vb.) ya aynı sunucuya kurulur yada farklı sunuculara kurularak kullanılırdı. Ancak yukarda saydığım 1-2 nedenden ötürü, zaten yıllar önce başlamış olan sanallaştırma teknolojileri son kullanıcıya kadar ulaşmış oldu.

- Geleneksel Altyapı

Yukarda yer alan şemadan görebileceğiniz gibi "Geleneksel Mimari" olarak adlandırdığımız yapıda temel anlamda sırasıyla,
"Donanım ->İşletim Sistemi -> Uygulama" katmanları yer almaktadır. Uygulamanızı, donanım üzerine kurduğunuz işletim sistemi üzerinde ayağa kaldırırsınız. Kısa vadede geleneksel mimari işimizi çözse de, bir takım performans ve optimizasyon problemlerini beraberinde getirmektedir.

Uygulama sayınız arttıkça ve uygulamaya bağlı servislerin(veritabanı, önbellekleme, 3. parti servisler vb.) çoğalmasıyla birlikte, ya aynı fiziksel sunucuda servisleri konumlandırmak ya da ekstra fiziksel makine yatırımı yapmak zorundasınız.

- Sanallaştırılmış Altyapı

Sanallaştırılmış altyapı ile sırasıyla "Donanım -> Hipervizör(*) -> İşletim Sistemleri(Sanal Makineler) -> Uygulamalar" katmanları yer almaktadır.

(*) Hipervizör: Sanallaştırma birimlerinde donanım kaynaklarını ayrıştıran çekirdek(yazılım) birimdir.

Birbirinden izole edilmiş bir yapıda sayısız(donanım limitleri ile sınırlı) sanal makine açabilmekte özgürüz. Bu sanal makineler kaynaklar(CPU, Memory, Disk, Network vb.) özelinde birbirinden ayrılmış ve gerçek bir işletim sistemi kurgusu ile çalışmaktadır.

Sanallaştırılmış altyapı aşağıdaki süreçleri genel olarak kapsamış oluyor.

  • Donanım kaynaklarının sanallaştırılması.
    (CPU, Memory, Network, Storage)
  • Sanallaştırılan kaynakların yeni sanal alt-sistemlere bölümlendirilmesi.
    (Virtual-Machine)
  • Sanal sistemlerin yönetilmesi için gerekli arabirimlerin sağlanması.(VNC/Spice Console, API, Watchdog vb.)
  • Sanallaştırma katmanında iyileştirme yaparak maksimum performansın sağlanması.
    (CPU Pinning, Over-Commit Memory, Over-Commit CPU, NUMA)
  • Sanallaştırma katmanında veri ve iletişim optimizasyonlarının yapılması.
    (Clustered Filesystems, Bridge, WAN/LAN Optimization)
  • Yazılım tanımlı sanal sistemlerin yönetimi.
    (SDS-Software-defined storage, SDN-Software-defined networking)

Sanallaştırma Kavramları

Sanallaştırma dünyasında karşımıza çıkacak başlıca birkaç terim var. Aslında bu liste çok kabarık, ama yazı dizisi devam ettikçe anlatmak istiyorum. Kafalar karışmasın :)

Hipervizör(Hypervisor)

  • Donanım kaynaklarını sanallaştıran yazılım birimidir. (XEN, KVM, ESXi, Hyper-V vb.)
  • Sanallaştırılan kaynaklar belirli formatlarla(XML, JSON) tutulur ve arabirimlere iletilir.
    Örnek senaryo(Pseudocode);
<machine>
    <name>machine01</name>
    <cpu_count>1</cpu_count>
    <memory>1024</memory>
    <disk>machine01.img</disk>
    <network>eth0</network>
</machine>

Konuk Sistem veya Sanal Makine(Virtual-Machine)
Hipervizör üzerinde sanallaştırılan her bir sanal sisteme verilen isimdir. Fiziksel makine gibi tüm kaynakları tanımlı bir işletim sistemini barındırır. Ancak her sanal makine kendisine tanımlı limitler ile çalışabilmektedir.
Bir önceki örnek senaryo kodunda yer alan sistem limitleri, sanal makine için gerçek kaynaklar olarak karşımıza çıkmaktadır. ISO yardımıyla yeni bir işletim sistemi kurabilir veya hazır bir Cloud imajı kullanabilirsiniz.

- Birbirinden bağımsız olarak açılmış 3 sanal makinenin ekran görüntüsü.


Sanalllaştırma Arabirimi
Sanallaştırılan kaynakların(CPU, Memory, Disk, Network) ve sanal makinelerin yönetimi için kullanılır. (OpenStack Horizon, Virt-Manager, VMware vSphere, XenCenter vb.)
İlgili uygulamalar kişisel bilgisayarınıza kurarak kullanabileceğiniz bir masaüstü uygulaması veya sunucuda çalışan bir web uygulaması olabilmektedir.
Sanallaştırma yazılımı geliştiren firmalar ve açık kaynak projeleri, çoklu platformda destek vermek yerine artık web uygulamaları geliştirmeye yönelmiş durumdalar.

- Linux dağıtımlarında, Linux-KVM yönetmek için kullanılan virt-manager uygulaması.

Sanallaştırma Tipleri

Sanallaştırmayı bu aşamaya kadar çok basit anlattığımı düşünüyorum. Ancak bu aşamadan sonra işler biraz karışıyor. Çünkü işletim sistemleri çoğaldıkça, donanım üreticileri farklı cihazlar çıkardıkça ihtiyaçlar ve performans gereksinimleri de değişkenlik gösteriyor. Sanallaştırma tiplerini tam olarak anladığımızda, canlı ortamda(production) hangi sanallaştırma teknolojilerini kullanmamız gerektiğine karar verebileceğiz. Ancak sanallaştırma tiplerine geçmeden önce söylememiz gereken birkaç cümle daha bulunuyor.

Sanallaştırma; işletim sistemi, uygulamalar, işlem gücü(CPU-Memory), depolama veya ağın altında yatan donanım veya yazılımın soyutlaştırılmasından başka bir şey değildir. İşletim sistemlerinin izolasyonu için fiziksel donanımların yanılsaması oluşturulur. Son 10 yılda veri merkezleri sunucu, depolama üniteleri ve ağ anahtarları(switch-router) tarafından işgal edildi. Veri merkezlerinin enerji ve kullanım fazlası maliyetlerini düşürmek için sanıyorum ki daha fazla enerji sarf edilmiştir. Bu dönemde bir çok firma donanımların simülasyonu/emülasyonu üzerine ar-ge yapıyordu. Sorunlardan ortaya çıkan çözümler bizi günümüzdeki Container teknolojilerine kadar getirdi.

Konumuza dönecek olursak sanallaştırma tiplerinde çok fazla alt kırılım olduğunu söyleyebilirim. Ancak konumuzun şu aşamada "Sunucu Sanallaştırma" kısmını kapsadığını söylemek istiyorum.

Sunucu sanallaştırma tiplerini şöyle bir ağaç yapısı ile sıralayabiliriz; [1]

  • Emülasyon / Tam Sanallaştırma
    • Yazılım Destekli Tam Sanallaştırma ( Software Assisted - Binary Translation )
    • Donanım Destekli Tam Sanallaştırma ( Hardware-assisted / Virtualization Technology )
      • Native ( Bare-Metal )
      • Hosted
  • Kısmi Sanallaştırma ( Paravirtualization )
  • Hibrit Kısmi Sanallaştırma ( Hybrid Paravirtualization )
  • İşletim Sistemi Seviyesinde Sanallaştırma ( OS Level Virtualization )

Karmaşık geldiğinin farkındayım. Ancak hepsini sırasıyla açıklayacağım ve örnekler vereceğim. Şu aşamada hepsinin güncel BT dünyasında kullanıldığını unutmayın.

Önce şu aralar en bilindik olanından başlamak istiyorum. Tahmin edeceğiniz üzere, son yıllarda BT dünyasını kasıp kavuran bir sanallaştırma türü kendisi.

İşletim Sistemi Seviyesinde Sanallaştırma ( OS Level Virtualization )


İşletim sistemi seviyesinde sanallaştırma şu aralar yaygın olarak kullanılmakta. Siz bunu "Container" olarak biliyorsunuz. Sanallaştırma yapmak için kullandığınız işletim sistemi(host-machine), cgroups adını verdiğimiz bir yazılım ile birden çok kullanıcı alanı(user-space) tanımlamanıza izin verir. Bu kullanıcı alanlarında oluşturulan geçici disk birimleri ve işletim sistemi süreçleri(process) dolayısıyla işlem gücü(CPU) ve önbellek(Memory) kullanılır.

Bu sanallaştırma türü, diğer sanallaştırma tiplerinden biraz farklıdır. Sanallaştırılan alt sistemler(Container), çalıştırdıkları uygulamalar için, işletim sistemi çekirdeğine çok az(bazen hiç) yük bindirirler. Temel sebebi aslında, Container sadece süreçleri dolayısıyla uygulamaları ayağa kaldırırır. Mevcut sistem çağrıları(syscall) altta bulunan çekirdeğe iletilir.

- Container birimlerinin Kernel'e nasıl ulaştığını gösteren şema. Kaynak: [2]

Alt sistemler, mevcut işletim sistemi çekirdeğinin sistem çağrılarını(syscall) ve sürücülerini(device drivers) kullandıkları için birbirinden farklı işletim sisteminde kullanılamazlar.
Örnek vermek gerekirse, Microsoft Windows 10 işletim sistemi üzerinde doğrudan Docker veya LXC çalıştıramazsınız. Çünkü Windows işletim sistemi "Windows NT Kernel", Docker/LXC ise "Linux Kernel" kullanmaktadır.
"Ama Docker'ı Windows'a kurup çalıştırdık!" dediğinizi duyar gibiyim. Hemen cevabını vereyim. Docker'ı Windows'a kurarken yükleyici(installer) ekranlarında "Install a Virtualbox" veya "Boot2Docker" seçimini fark etmişsinizdir. Bunun manası şudur, Docker size Virtualbox adını verdiğimiz(sonraki aşamalarda bahsedeceğim) sanallaştırma aracında, geçici bir Linux işletim sistemi açar. Sizin açmak istediğiniz "Container" alt birimleri dolaylı olarak VirtualBox içindeki Boot2Docker linux işletim sistemi içinde çalıştırılır. Windows'ta yönettiğinizi zannettiğiniz şey(?) aslında linux içinde çalıştırılmaktadır.
Bu sanallaştırma tipine örnek olarak şu teknolojileri sıralayabiliriz;

Yazılım Destekli Tam Sanallaştırma ( Software Assisted - Binary Translation )

- Uygulamadan sanal makineye, sanal makineden hipervizöre CPU süreçlerinin iletişimi.

Yazılım destekli tam sanallaştırma tipinde, sanal makineler işlemci gücünü kullanırken CPU'ya doğrudan erişemez. Kafa karışıklığına sebep olmadan şöyle açıklayayım; Örnek vermek gerekirse sanal makine içinde CPU kullanan(doğal olarak) bir uygulamanız var. Bu uygulama CPU'ya doğrudan iş gönderemediği için, işi ikili sistemde önce hipervizöre iletir. Hipervizöre iletilen ikili kodu donanımsal işlemciye iletilir. Yine işlenen veri, aynı yol üzerinden sanal makineye döner. Ancak tahmin edeceğiniz üzere performans kayıpları yaşanabilmektedir. Çünkü sanal makine üzerinde gerçekleştirdiğiniz her işlemci ilişkili süreç(process), yine kendi süreçleri için işlemciyi kullanan hipervizör ile birlikte donanımsal işlemciye ekstra yük getirmektedir. Bu sanallaştırma tipinde mevcut işlemci performansının %80-%95 civarı kullanılabilmektedir.
Bu sanallaştırma tipine örnek olarak şu teknolojileri sıralayabiliriz;

Donanım Destekli Tam Sanallaştırma ( Hardware-assisted / Virtualization Technology )

- Sanal makine hipervizör ile konuşurken, aynı anda doğrudan CPU ile konuşur.

Donanım destekli sanallaştırma, bir önceki sanallaştırma tipinde bahsettiğimiz "Binary Translation" sürecine gerek kalmadan doğrudan fiziksel işlemciye erişerek gerçekleştirilen sanallaştırma tipidir. 2005 yılı itibariyle x86(64-bit) işlemcilerde sanallaştırmanın donanımsal olarak desteklenmesi(Hardware Acceleration) için eklentiler(CPU Extension) geliştirildi. Bu eklentiler işlemcinizde hazır olarak gelmektedir. Sanal makinenin CPU istekleri(interrupt) ve talimatları(instruction), hipervizörün tanımladığı CPU üzerindeki belli alanlarda yapılır. Bu sebeple yazılım destekli tam sanallaştırmaya göre daha performanslıdır ve daha çok tercih edilmektedir.

Bu sanallaştırma tipi de kendi içinde 2 farklı tipte(Bare-Metal, Hosted) ayrışmaktadır. Kullanılan uygulamalardan da anlayacağınız üzere, birinci tip doğrudan sunucuda kullanılmak üzere tüm sanallaştırma süreçlerinin hipervizör çekirdeği üzerinde gerçekleştiği, ikinci tip ise masaüstü vb. ortamlarda mevcut işletim sistemi üzerinde sanallaştırma yapabilmek için kullanılmaktadır.

Bilgisayarınızda veya sunucunuzda yer alan BIOS yazılımında Intel VT-x veya AMD-V özelliği açık değilse doğrudan yazılım destekli tam sanallaştırma kullanılır. Bu özellik açıldığında donanım destekli tam sanallaştırma kullanabilmektedir.

Bare-Metal ve Hosted'ın tam türkçe karşılığını bulamadığım için doğrudan aktardım.

Bare-Metal

- Sanal makineler, doğrudan hipervizör çekirdeği ve işletim sistemi üzerinden sunulur.

Bare-Metal yapıda bir sanallaştırma kurgulamak istiyorsanız sunucuya doğrudan hipervizör olarak çalışan veya hipervizör özelliği bulunan bir çekirdeğe sahip işletim sistemi yüklemeniz gerekiyor. Bu işletim sistemi sadece hipervizörü yönetmek için kullanılmaktadır.
Bu sanallaştırma alt grubuna genellikle kurumsal ve büyük projelerde kullanılan aşağıdaki hipervizörleri örnek verebiliriz;

Hosted

- Sanal makineler, genelde masaüstü işletim sistemi olarak kullanılan birime yüklenen hipervizör yazılımı üzerinden sunulur.

Hosted yapıda bir sanallaştırma kurgulamak istiyorsanız, yapmanız gereken tek şey destekleyen hipervizör yazılımlarından birini masaüstü-kişisel bilgisayarınıza kurmak.
Bu sanallaştırma alt grubuna örnek olarak aşağıdaki hipervizörleri örnek verebiliriz;

Kısmi Sanallaştırma ( Paravirtualization )

Kısmi sanallaştırma, tam sanallaştırmadan biraz farklı çalışır. Sanal makineler için donanımı simüle etmenize gerek yoktur. Hipervizör yine fiziksel sunucuya kurulur, sanal makineler de yine bu hipervizör üzerinde konumlandırılır. Ancak bu sanallaştırma tipinde, sanal makineler -tam sanallaştırmanın aksine- sanallaştırıldığını doğrudan bilmektedir. Bunun amacı altta çalışan hipervizör aynı zamanda bir mikro-çekirdek çalıştırmaktadır. Bu nedenle donanımsal istekler(cpu, memory, network vb.) API vasıtasıyla hipervizör üzerindeki mikro-çekirdeğe oradan da donanımlara iletilir. İşletim sistemi seviyesinde sanallaştırmaya çok benzemekle birlikte, sanal makineler özelleştirilmiş çekirdek(kernel) sayesinde çalışabilmektedir. Diğer bir deyişle linux çekirdeği üzerindeki kısmi sanallaştırmada Windows NT tabanlı bir işletim sistemi kullanamazsınız.

- XEN hipervizör, hem tam sanallaştırma hem de kısmi sanallaştırma yapabilmektedir.

Yukardaki şema XEN hipervizörünün hem tam sanallaştırma, hem de kısmi sanallaştırmayı nasıl desteklediğini anlamanıza yardımcı olacaktır. Windows ve Linux çekirdek seviyesinde mimari farklılığı nedeniyle, sanal makinede windows için kısmi sanallaştırma yapılamaz. Linux için ise çekirdek(kernel) üzerinde değişiklik sonrası, kısmi sanallaştırma yapılabilmektedir. VMware ESXi ise hiç bir işletim sistemi(linux, windows vb.) için kısmi sanallaştırma yapamamaktadır.
Bu sanallaştırma tipine örnek olarak şu teknolojileri sıralayabiliriz;

Hibrit Kısmi Sanallaştırma ( Hybrid Paravirtualization )

Donanım destekli tam sanallaştırmada, daha önce de belirttiğim gibi sanal makineler üzerinde bir değişiklik yapılmasına gerek yoktur. Dolayısıyla fiziksel makinenin doğrudan(tanımlanan limitler ile) simülasyonu söz konusudur. Ancak bu durumda tüm bu yük hipervizör üzerinde kalmaktadır. Her ne kadar en performanslı sanallaştırma tipi donanım destekli tam sanallaştırma gibi gözükse de uzun vadede hibrit bir yapı gereksinimi ortaya çıkmıştır. Günümüzde bir çok donanım üreticisi bu hibrit yapı için doğrudan API desteği sunmaktadır. Aslında söz konusu hibrit yapı, tam sanallaştırma ile kısmi sanallaştırmanın ortak kullanımını özetlemektedir. Temel işlevler için için tam sanallaştırmayı, darboğaz yaşanabilecek işlevler için(özellikle I/O ve memory) kısmi sanallaştırmayı dolayısıyla üreticilerin sürücülerini ve API'lerini kullanırlar.

- VMware ESXi hibrit kısmi sanallaştırmayı desteklemektedir.

Yukardaki şema VMware ESXi hipervizörünün hem tam sanallaştırmayı hem de hibrit sanallaştırmayı nasıl desteklediğini anlamanıza yardımcı olacaktır.
Şemanın sol tarafında "Sockets API" görüyoruz. Tam sanallaştırma yapıldığında işletim sistemi kendisine tahsis edilmiş donanım kaynakları üzerinden ağ iletişimi(Sockets, TCP, IPv4, IPv6, Network Device) sağlıyor. Bu ağ iletişimi hipervizör üzerinde(linux-bridge veya software-switch) sonlanıp, sonrasında donanıma iletiliyor. Ancak bu durum hem sanal makine çekirdeği hem de yazılımsal olarak hipervizör üzerinde çalışan ToE(TCP-Offload-Engine) dolayısıyla fiziksel makinedeki işlemci için ekstra yük getiriyor. Her bir ağ hesaplaması CPU üzerinden geçerek gereksiz maliyetlere sebep olabiliyor.
Şemanın sağ tarafında kalan "RDMA Verbs API" kısmı incelersek, tam bu noktada bazı ağ kartı üreticileri ToE'yi ağ kartı üzerinde harici bir işlemcide çalıştırıyor. Sanal makine bu ağ kartına ulaşmak için kısmi sanallaştırmanın sağladığı(aslında üreticinin sağladığı API ile) sanal makinenin çekirdeğini atlayarak(kernel by-pass) doğrudan kart üzerindeki ToE birimine ulaşıyor. Hatta bir çok üretici kartı da sanallaştırmak üzere(SR-IOV, NPAR) bazı teknolojiler geliştirmiş durumda. Kartın fiziksel olarak diğer fiziksel cihazlarla sağlayabildiği trafik kapasitesinin(10GbE Throughput) yanında, sanal makinelerin kendi aralarında haberleşmesi için alt birimler(64x VMDq - Virtual Machine Device queue) oluşturabiliyor.[3]

Biraz kafalar karışmış olabilir, aşağıdaki video RDMA, ToE vb. süreçleri çok güzel anlatıyor.

Bu sanallaştırma tipine örnek olarak şu teknolojileri sıralayabiliriz;

Biraz bilgi karmaşası yaşamış olabileceğinizi düşünüyorum :) Merak ettiğiniz soru varsa bu başlık altında cevaplayacağım. Ayrıca yazı dizisinin devamından ve/veya genel olarak yazdıklarımdan haberdar olmak isterseniz, sitenin sağ tarafında bulunan "Newsletter"a e-posta adresinizi bırakabilirsiniz. Söz veriyorum istenmeyen e-posta almayacaksınız. :)

Bir sonraki yazımızda görüşmek dileğiyle.

Kaynaklar:
[1]: http://www.unixarena.com/2017/12/para-virtualization-full-virtualization-hardware-assisted-virtualization.html/
[2]: https://rhelblog.redhat.com/2015/07/29/architecting-containers-part-1-user-space-vs-kernel-space/
[3]: https://events.static.linuxfound.org/sites/events/files/slides/20160715_LinuxCon_sriov_final.pdf ( Sayfa 8, VMDq)

Photo Credits:
Hürjet  - Türk Havacılık Uzay Sanayii

0 Comments 0 Comments
0 Comments 0 Comments