Sanallaştırma (Hypervisor ve Container & Docker)
Hypervisor ve Container Tabirleri Üzerine
Last updated
Was this helpful?
Hypervisor ve Container Tabirleri Üzerine
Last updated
Was this helpful?
Uygulamanı yükle ve kullandığın CPU time ve memory kadar para öde prensibiyle ilerleyen mimari yapı.
Serverless != Microservices
Konu mimariyle alakalı değil. Deployment metodudur. Ama zamanla yapınızı microservice çevirmeniz gerekecektir.
Bu konularda bir çok kaynak Türkçe olarak da bulunmaktadır. Bu yazımız da bu yazılara atıfta bulunup biraz daha karşılaştırma, performans temelli bakış gerçekleştireceğim. Karmaşıkça anlatılan ana mimariyi basitçe ifade etmeye çalışacağım.
Type-1 ve Type-2 diye hypervisor çeşitleri vardır. Bunları bir çok yerde resmedildiğini de görebilirsiniz. En bilinen ve populer olanlardan bahsetmeye çalışacağım.
Type-1' e örnek olarak (Hyper-V, Vmware EXSi Bare Metal Hypervisor, Xen/RT-Xen, JailHouse) verilebilinirken Type-2' e örnek olarak (Vmware Workstation, VMware Fusion (for MAC users), Oracle VirtualBox, Parallels (for MAC users)) örnek gösterilebilir.
Tabii daha ayrıntılara girmeden ara bir başlıkta bu yazılımların dayandığı temel donanımsal teknolojiden bahsederek işlemci ve anakart üreticilerinin ve bu teknolojileri kullanarak sanallaştırılabilir çevre birim üreticilerinin de hakkını teslim etmek gerekir. İşlemci içerisinde VT-x (AMD firması AMD-SVM) teknoloji ve anakart chipsetlerindeki VT-d teknolojileri (AMD firması AMD-V olarak adlandırır) bu işin bel kemiğini oluşturan teknolojilerdir. Bir de SR-IOV (single root input/output virtualization) teknolojisi bulunmaktadır.
Bahsedeceklerimiz arasındakilerden bir tanesi VMware ESXi bir diğeri de Microsoft Hyper-V mimarisi olacak. VMware tam olarak donanım üzerinde koşar. Kendine ait scheduler vardır. Ve üzerindeki Virtual Machine (VMs) lere donanımsal kaynakları kendi algoritmalarına göre paylaştırır. Arayüzlerinden kullanabileceği maksimum RAM miktarı, CPU miktarı, disk miktarı gibi ayarlamalar yapılır. Bunların hepsini yaparken de kendisini direkt olarak bir CPU üzerinde koşturur ve sınırlı bir miktarda da RAM tüketir. Bir donanıma önce VMware kurulur sonra üzerlerine VMs oluşturularak Guest OS ler kurulur.
Hyper-V ise mimari olarak çalışma olarak daha farklıdır. Hyper-V destekleyen bir Microsoft Windows işletim sistemi öncelikli olarak donanım üzerine kurulur ve Hyper-V özelliği aktifleştirilir. Bu aktifleştirme sonucu Hyper-V, kurulduğu ve Host işletim sistemi (Parent OS) olarak anılan OS altına yerleşir. Hyper-V CPU ve bellek birimlerini OS arasında paylaştırarak direkt erişim sağlarken Guest OS' ler memory temelli veri aktarımı sağlayan VMBUS aracılığıyla Parent OS de driverlarının ve yönetiminin bulunduğu diğer donanımlara erişim sağlarlar. Yani Guest OS (Child OS) hala host işletim sisteminin kaynaklarına bağımlı olarak çalışır. Parent deki bir dar boğaz diğer VMs lerin performansını etkileyecektir. Örneğin, arkaplan da çalışan processlerin ihtiyaçlarına göre guest OS ihtiyaçlarını erteledeği durumlar görülebilir. Hyper-V scheduler' ı 3 farklı algoritmada çalışabilmektedir. Bunlar classic, core ve root metotlarıdır. Classic fair bir şekilde kaynakların paylaşımını sağlarken, core scheduler Scheduling Multithreading (SMT) desteği de sunmaktadır. Yani CPU üzerinde koşan threadler instructionların akışlarına göre CPU zaman domeninde boşluksuz kalacak şekilde çalışması için daha verimli hale getirir. Root Scheduling de hyper-V tarafından schedling yapılması yerine Host OS tarafından yapılmasına izin veren metotdur.
VMware ESXi ise tüm Guest OS eşit mesafededir. Scheduler desteğinin yanı sıra kaynak paylaşımlarını kendi yönetir. Donanımların driver desteğini ve paylaşımlı erişimini kendi sağlar. Kendisinin kullanıcı düzeyinde yönetilmesi için de araçlar sunar.
Kendi gözlemlerim kapsamında Hyper-V çalışan uygulamayı vCPU lar arasında gezindirerek çalıştırırken, VMware ESXI da belirli bir işlemci üzerinde %100 çalışma şeklinde kolayca zorlanabilmektedir.
Kısacası hangi hypervisor ile çalışılacağı scheduler performanslarının yanı sıra sunabildiği imkanlara da bakılarak karar verilmesi gerekir.
Bu konuda türkçe Gökhan Şengün güzel açıklayıcı bir videolar ve yazılar sunuyor.
İncelemenizi tavsiye edebileceğim diğer Türkçe kaynaklar
Portainer kurulumunu anlatan güzel bir yazı
Ozan Teoman Dayanan da video paylaşım serisinde açıklayıcı bilgiler bulabilirsiniz.
Docker-Swarm günümüz versiyonlarında auto scaling desteklememektedir. Yani ihtiyaca göre servislerimizin sayısını arttırıp azaltamamaktadır. Bunu kendi servislerimiz için bizim yapmamız ya da hazır yapan servisler araştırmamız gerekiyor. Kubernetes bu konuda hazır çözümle geldiği bilmekte fayda var. Aşağıdaki linklerde bu konulara değinilmiş. İncelemeniz faydalı olabilir.
Sorulan soruya verilen cevapda Cadvisor ve Node-exporter containers karışımın kullandığını belirtiyor. Bu servisler ile sistemden metrik toplayıp performansları izleyerek nerede yeni replikalar oluşturması gerektiğine karar veriyor.
Prometheus, Grafana, cAdvisor, NodeExporter and AlertManager kullanarak geliştirilmiş bir örneğe işaret eden bir mimari sunuyor.
Prometheus (metrics database)
Prometheus-Pushgateway (push acceptor for ephemeral and batch jobs)
AlertManager (alerts management)
Grafana (visualize metrics)
NodeExporter (host metrics collector)
cAdvisor (containers metrics collector)
Caddy (reverse proxy and basic auth provider for prometheus and alertmanager)
cAdvisor (Container Advisor) provides container users an understanding of the resource usage and performance characteristics of their running containers.
Node-exporter exposes additional metrics.
Dockerd Exporter exposes Docker swarm metrics
Prometheus server now to make the collector agent and service part complete.
Tabii Kubernetes' in yeni bir container ayağa kaldırma performansının ve kolay kurulumunun Swarm göre düşük olduğunu belirten yazılar da bulabilirsiniz. Tabii Kubernetes kolay kurulum ve performans sunmasa da sizin Operation kısmıyla çok ilgilenmemenizi sizin için ben düşünürüm yaklaşımıyla geliştirildiği düşünmek bir tercih sebebi olabilir. Tasarlayacağınız sistemin ihtiyaçlarıyla alakalı bir durum olsa gerek. Tabii servisiniz hazırda çalışmayı bekleyen replikaları da varsa yeni bir container ın ayağa kaldırılması vs gibi sürecin uzunluğu sizi çok etkilemese olsa gerek.
Şurada da karşılaştırıcı yazılar bulabilirsiniz
Katılımcıları üzerinde yapılan araştırmaya göre hangi teknolojiler tercih ediliyor araştırmasının 2019 raporu
The use of Docker containers continues to grow, with adoption increasing to 57 percent from 49 percent in 2018.
Kubernetes, a container orchestration tool that leverages Docker, achieved faster growth, increasing from 27 percent to 48 percent adoption.
