Broadcom’un Kasım 2023’te VMware’i satın almasının ardından, VMware lisanslamasıyla ilgili önemli ve ani değişiklikler yapıldı. Özellikle yüksek abonelik ücretlerinin getirilmesi ve ücretsiz sürümlere desteğin çekilmesi gibi değişiklikler, birçok işletme için önemli zorluklar oluşturuyor. Bu nedenle, pek çok şirket VMware’in artan maliyet yükünden kaçınmak için alternatif çözümleri araştırıyor.

Ancak, VMware’in sebep olabileceği maliyet unsurlarından kaçarken, şirketler yüksek maliyetli ve kullanılmayan ürünlere yönelebilirler.

Son aylarda, lisans ücreti olmaması, tedarikçi kilitlenmesini(Vendor Lock-in) ortadan kaldırması ve geniş bir topluluk desteğinden yararlanılması gibi nedenlerle, açık kaynaklı ürünlerle oluşturulan sanallaştırma sistemlerine yönelik önemli bir ilgi var.

VMware ile İlgili Zorlukları Anlamak 

VMware ile ilk karşılaşmam 2002 yılında oldu, o zamanlar sadece Tip 2 hipervizörleri vardı (Virtualbox gibi). Sanallaştırılmış sunucu ile kendi masaüstünüz arasında sorunsuz bir şekilde geçiş yapılabiliyordu, dönemi için inanılmaz özelliklerdi bunlar. Daha sonra sunucu ürünlerini piyasaya sürdüler ve hikaye başladı. Lisanslı ürünleriyle, işletmeler için oldukça uygun olan sabit (soket)CPU başına maliyet talep ediyorlardı. Yaygınlıkları çok olduğu için, Destek ve bakım hizmetleri de sorunsuz verilebiliyordu.

Ancak Broadcom’un satın almasının ardından, VMware ani bir dizi stratejik değişiklik yaptı. En önemlileri, sabit yazılım maliyetlerinden abonelik modeline geçiş ve önceki süresiz teklifler için destek ve abonelik yenilemelerinin artık mevcut olmamasıydı.

Bu esasen şu anlama geliyordu:

Abonelik modeline geçiş, dünya genelinde birçok firma için %100-700 oranında fiyat artışına neden oldu ve çoğunun bütçesini aştı. Önceki maliyet, CPU başına hesaplanırken, şimdi çekirdek başına hesaplanıyor. Şirket çekirdek başına fiyatı düşürdüğünü iddia etse de, bu çok gerçekçi değil. Bu durum büyük müşterilerin lehine, küçük müşterilerin aleyhine bir durum oluşturuyor. Abonelik sistemiyle, birçok şirketin ihtiyaç duymadığı ürünleri içeren paketleri zorunlu olarak satın alınması gerekiyor. Şirket, önceki sürekli satış anlaşmaları için artık destek sağlamayacak ve bu tür anlaşmalara sahip olanlar abonelik sistemine geçirilmeyecek. Bu koşullar, dünya genelindeki VMware kullanıcılarını anlaşılır bir şekilde öfkelendirdi. İlk anketler, CIO’ların ve yöneticilerin, VMware’in getirdiği yeni sistemi ve sunabileceği tüm yenilikleri, desteği ve hizmetleri reddetme eğiliminde olduğunu gösteriyor. Bu kararlarla beraber binlerce işletme, kısa ve uzun vadeli hedeflerine ciddi darbe aldı.

Yukarıda belirtilen nedenlerden dolayı, son haftalarda açık kaynaklı sanallaştırma sistemlerine olan ilgi önemli ölçüde arttı. 

Bu makale, sunucu sanallaştırması tip 1 için açık kaynaklı sanallaştırma alternatifleri hakkında bilgi sağlamayı amaçlamaktadır.

Tip 1 Sanallaştırma: Genel Bakış 

Bu sanallaştırma yöntemi, temelde bir fiziksel makine içinde birden fazla makine çalıştırılmasını ifade eder. Bunlara sanal makineler veya sanal sunucular diyoruz. Üzerinde bulundukları fiziksel bilgisayar/makine/sunucu, sanal makineler için bir abstract(soyut) katmanı yaratır ve her sanal makine bir fiziksel makineymiş gibi davranır.

Tip.1 sanallaştırmanın kendi içinde 2 ayrı yöntemi vardır, Light ve Normal. (Light) Hafif sanallaştırma, çoğunlukla sunucusuz hizmetlerde (serverless) kullanılır ve daha kısa çalışma süresi ve daha kısa başlangıç süresi olan yeni bir teknolojidir. AWS’in sunucusuz çözümleri, Fargate gibi, bu tür hipervizörlere dayanır.

Popüler iki (light hypervisor) hafif sanallaştırma seçeneği “Cloud hipervizör” ve “Firecracker”dır. Firecracker, KVM tabanlıdır ve önyükleme için çok az cihaz kullanır (ağ, hesaplama, I/O…), yalnızca gerekli cihazları sanallaştırır, bu da yaklaşık 100-200 ms’lik bir başlangıç süresi sağlar.

Önemli hatırlatma: Konteyner Teknolojisi Sanallaştırma Değildir!

İnternette, Docker ve Kubernetes gibi Konteyner teknolojilerini sanallaştırma teknolojileri olarak içeren birçok yanlış hipervizör karşılaştırma tabloları mevcuttur, bunlar %100 yanlıştır.

Konteynerler bir sanallaştırma teknolojisi değildir. Konteynerler yeniden başlatılmak üzere tasarlanmıştır, sanal sunucular ise kesintisiz çalışmak üzerine disayn edilmişlerdir. Konteynerler, tasarım gereği, tip.1 sanallaştırmanın ilk gereksinimi olan “izolasyon katmanını” sağlamazlar.

Açık Kaynaklı Sanallaştırma Sistemlerini Keşfetmek 

İncelemeden önce, genel bir ilkeyi vurgulamak isterim ki zaten biliyorsunuzdur. Altyapınız sorunsuz çalışıyor ve lisanslama sorununuz yoksa, önerim “sistemlerinizi olduğu gibi çalıştırmaya devam etmeniz” olurdu. Unutmayın, “en iyi sistem, ayrıntılarını bildiğiniz sistemdir.” Kısacası, sistemlerinizi güvenli ve basit tutun; bu bir seçenekse, kesinlikle VMware çalıştırmaya devam edin.

“Çalışıyorsa dokunma”
                        _ eski bir programcı

VMware  Alternatifleri Nelerdir? 

Kullanabileceğiniz birden fazla hipervizör dağıtımı mevcut, peki sizin kullanmanız için hangisi daha doğru bir seçim ?

Burada hipervizörler ve Uzak Bulut sistemleri arasında tercih yapmak gerekiyor. Özet olarak küçük bir altyapınız varsa bir hipervizor orkestrasyon çözümü işinizi görebilir. Bu durumda XCP-ng, Proxmox ve Nutanix, VMware’e alternatif çözümler olarak ortaya çıkıyor.

Hipervizörler ve Orkestrasyon Araçları 

Bu bölüm altında, küçük ölçekli kurulumlar için uygun VMware alternatiflerini anlatıyoruz. Küçük ölçekli kurulumlar, yöneticinin tüm sunucu IP adreslerini kolayca hatırlayabileceği kurulumlardır. Genellikle KOBİ’ler ve orta ölçekli şirketler bu guruba girer. Bu, 3 Sunuculu bir kurulumdan 8-10 sunuculu kurulumlara kadar olan ortamlar için geçerlidir.

Bu ölçekte, hipervizörlerinizde bir yönetim aracı çalıştırmanız gerekir. Bazı Hipervizör çözümleri 3-10 sunuculu ortamlar için mükemmel çözümler sunar.

Ancak, yaygın bir hatayı not etmek önemlidir. Dağıtımınızda 8-10’dan fazla hipervizörünüz varsa, örneğin Lokasyon 1’de 8 Sunucu, Lokasyon 2’de 9 sunucu gibi. Bu durumda 17 sunucunuz olduğunu düşünebilirsiniz fakat bulacağınız çözümler için bu yanlış bir varsayım olabilir. Dolayısıyla, hemen daha büyük ölçekli çözümlere yönelmekten kaçının. Bu tür durumlarda danışmanlık almanızı şiddetle tavsiye ederim, çünkü her çözümün kendi bağımlılıkları ve kısıtlamaları vardır. Durumunuz düşündüğünüzden daha karmaşık olabilir.

Alternatif Teknolojiler 

Hyper-V: Lisans ücretleri ve tedarikçi kilitlenmesi dışında, Hyper-v de gerçekçi bir alternatiftir. Microsoft sanallaştırma teknolojisi, Microsoft tarafından satın alınan “Connectix, VirtualPC”den gelmektedir. En belirgin VirtualPC teknolojisi, vhd disk teknolojisidir. Sunucularınızın çoğu Microsoft tabanlı ise mutlaka bu seçeneği düşünmelisiniz. En ciddi handikapı Orkestrasyon çözümleri ve Hyperconverged (Bütünleşik disk çözümü) içermiyor olması.

KVM Hipervizörü: Tüm linux dağıtımları KVM (Kernel Sanallaştırma Modülü) çözümünü içeriri. En basit ve en az karmaşık tip1 hipervizör çözümüdür. Ancak, her şeyi kurmak için Linux işletim sistemi bilgisine ihtiyaç duyar. Çok esnek bir ortam yaratabilirsiniz, isterseniz kendi Bulut altyapınızı sıfırdan dizayn edebilirsiniz. Tek başına kullanmak için Linux üzerinde geniş bilgi ve deneyim gerektirir. Piyasadaki çoğu Bulut ve Hipervizör çözümü, varsayılan hipervizör olarak KVM kullanır. Google Cloud, OVH, Hetzner… KVM kullanır.

XCP-ng: Açık kaynak XCP projesinin (reboot) yeniden oluşturulması ile çıkmıştır. XEN hipervizörü kullanmaktadır. Citrix 2018 senesinde Xenserver lisanslama modelini sınırlamalarından hemen sonra, Vates şirketi tarafından, Xen-Orchestra’nın arkasındaki aynı grup tarafından başlatıldı. XCP-ng ciddi bir ilgi çekmedi, ancak proje devam etti ve çözümleri etrafında niş bir topluluk oluşturdular. AWS gibi bazı bulut platformları hala XEN Hipervizörleri kullanıyor olmasına rağmen, kişisel olarak bu çözümü tavsiye etmem. XCP-ng çözümü kullanan şirketler çözümden memnunlar ayrıca artık bir HCI entegre alternatifi (Linbit, DRBD) de sunuyorlar. Genel olarak, dikkate değer bir alternatiftir. Son 15 yılda birçok kritik ortamımızda (SAP, Oracle DB, HA cluster, MSSQL sunucuları..) Xenserver ve XCP-ng kullandık. 

15 yılda, XEN hipervizörü ilgili kesinti = 2 dakikadan az sürede çözüldü.

Ancak, XCP-ng’nin dikkate alınması gereken bazı zayıf yönleri vardır:

• CentOS 7: Artık güncellenmiyor
• Xen: Yama sorunlarıyla karşı karşıya
• Ağ çözümü: Oldukça sınırlı, Linux özelliklerini uygulamak zor.
• Entegre Depolama: Beta seviyesinde çözüm, güçlü tedarikçiler yok

Proxmox: Küçük ölçekli dağıtımlar için en umut verici alternatif Proxmox’tur. 8-10 sunucu’ya kadar olan dağıtımlar için tavsiye ederim. Ceph ve yedekleme çözümlerini anahtar teslim çözüm olarak çıkar, kullanmaya başlamak için bir lisansa ihtiyaç duymaz.

Proxmox, tüm özellikleri varsayılan olarak içerir, kullanıcıların LXC (konteyner) ve KVM (tam sanallaştırılmış) örnekler arasında seçim yapmasına olanak tanır. 8-10’dan az sunucunuz varsa, bu platform sizin için idealdir. Yaklaşık 10 yıldır çeşitli kritik ortamlarda Proxmox kullandık (SAP, Oracle DB, Windows..). Yıllar içinde çok az sorunla karşılaştık, tek sorunu cluster servislerinde yaşamıştık. Linux uzmanlığımız sayesinde tüm sorunlarımızı kolaylıkla çözebildik. Tip 1 hipervizör ve orkestrasyon platformu olarak şiddetle tavsiye ederim.

10 yılda, Proxmox hipervizörü ilgili kesinti =  60 dakikada çözüldü

Proxmox’un dikkate alınması gereken bazı zayıf yönleri vardır:

• Cluster servisleri (sqlite ve paylaşılan dosya sistemi)
• Ağ çözümü: Linux ile sınırlı, yeni SDN çözümleri umut vaad ediyor
• Büyük kurulumlar için ideal değil. Cloud çözümü olarak düşünülmemeli

Harvester(Beta): Harvester, hipervizör olarak KVM kullanır, kesin olarak Kubevirt. Örnekler konteynerler içinde oluşturulur, bu da karmaşıklığı artırır. Ancak, Harvester bir HCI yaklaşımı benimser, depolama ve ağ gibi gerekli tüm bileşenleri sunar. Test ortamlarımızda Harvester, sistemde herhangi bir örnek çalışmıyorken çok fazla CPU kaynağı tüketiyordu. Harvester umut verici bir çözüm ancak hala Beta aşamasındadır. Üretim ortamlarında kullanılamaz.

Kubevirt (uygulanabilir bir platform yok): Kubevirt’i yalnızca bir hipervizör yerine olarak kullanmak zorlayıcıdır. Openshift (Kubevirt içerir) veya Kubernetes konusunda uzmanlığı olanlar için, bir sanallaştırma olarak kullanılabilir. Gitops için hazırladığınız CI/CD pipeline üzerine sunucularınızı deploy etmeyi(örn, db sunucuları) ekleyebilirsiniz. Ancak, birçok test edilmemiş kullanım durumuyla karşılaşmaya hazır olun. Merak edenlerin runc ile ilgili github repo’larına bakmasını tavsiye ederim. 

RHEV (devam etmiyor): Başlangıçta RedHat tarafından, daha sonra IBM tarafından geliştirilen bu proje, Openshift’e taşındı. EOL 2026 için duyuruldu, güncellemeler 09/2024’te sona erecek.

Ovirt (devam etmiyor): Ovirt, açık kaynaklı bir RHEV olarak hala geliştiriliyor fakat malesef ölmekte olan bir proje. Kötü tasarım kararları (Gluster, NFS, Image mgmt, Network) yüzünden proje uygulanabilir değil.

Çok sayıda compute sunucusu (10’dan fazla), ayrıca yönetmeniz gereken depolama ve ağ altyapınız varsa, (Edge Cloud) Uzak Bulutu Alternatiflerini incelemelisiniz.

Piyasada dört umut verici çözüm var, bu seçeneklere bir göz atalım.

Edge Cloud (Uzak Bulut)

Edge Cloud, en önemlisi düşük gecikmeli örnekler olmak üzere, birçok fayda sunar. İşletme yerinizde GPU’ları kullanmanız gerekiyor ve verilerinizin çekim gücü kenar konumunuzdaysa, Yönetilen Uç Bulut çözümlerini düşünmek esastır.

Opennebula: Küçük ölçekli dağıtımlar için anahtar teslim çözüm sunar, ancak büyük ölçekli bir dağıtım için test etmeniz gerekir. İnternet üzerinde topluluk ve destek araştırması yaparsanız çok iyi bir çözüm olmadığını görürsünüz. Çok sınırlı bir topluluğu var(ispanya kökenli bir çözüm), bu çözümü kullanan çok kişi bulamazsınız. Büyük kurulumlar için gerçekten destek almanız gerekir. Kendileriyle iletişime geçtik fakat bize verdikleri bilgiler çok umut vaad etmiyor.

Cloudstack: 2010’larda sektörde cloud.com çözümünü açık kaynak yapması ile başlayan ciddi bir etki yarattılar. Çözümleri Cloudstack’ti. Malesef sektör içinde iki tane çok büyük oyuncu için yer yoktu ve Cloudstack çözümü önemini ve ilgisini yıllar içinde yitirdi. En büyük hataları Openstack ile benzer bir pazarı hedeflemeleri oldu. Endüstri (donanım sağlayıcılar) ve bazı açık kaynak oyuncuları bu çözümü desteklemedi. Çoğunluğuk neredeyse o tarafı tercih etmeniz gerekir. Kişisel olarak en beğendiğim bulut çözümü olmasına rağmen sektör bu çözümü kabullenmedi. Birden fazla hipervizörü desteklemeyen hibrit bir çözümdür. Dökümantasyonu ve bulabileceğiniz destek oldukça sınırlıdır. KVM hipervizörü ve CEPH Storage konularında tecrübeli bir ekibiniz var ise kesinlikle bu çözümü denemenizi öneririm. Oldukça hızlı bir şekilde kendi bulut ortamınızı oluşturabilirsiniz.

Virtuozzo: Açık kaynaklı Openstack çözümünün adapte edildiği kapalı bir çözümdür. Tecrübelerimizin çoğu Onapp ürünüyle (Virtuozzo tarafından satın alındı). HCI ile entegre bir çözümleri mevcuttur, ancak çözümü test etmedik. Çözümlerinin ayrıntıları hakkında hiçbir bilgi mevcut değil. Ciddi bir kullanıcı kitleleri var ve ana çözüm sağlayıcı kendileri. Anahtar teslim bir HCI sunduklarını iddia ediyorlar ancak dökümanlar içinde hangi teknolojileri kullandıkları belirtilmiyor. Ne yazık ki, dökümanlarının çoğu son kullanıcılar için pazarlama malzemesinden oluşuyor.

Platform9: Uzun bir süredir Uç Bulut ve Private Cloud pazarındalar, Openstack konusunda geniş bir deneyime sahipler. Son 10 yılda Openstack için birçok katkılarını gördüm. Platform9, hipervizör yığını olarak Kubevirt kullandıklarını belirtiyor, hiçbir çözümlerini test etmedim, ancak çözüm sağlayıcı olarak umut verici görünüyorlar. Virtuozzo gibi açık bir çözüm değiller ve ayrıntılı bilgi edinmek imkansız.

Openstack: Openstack, piyasadaki tek gerçek uç bulut çözümü olarak öne çıkıyor. Sağlam bir topluluğa sahipler, uç ağ yapıları da dahil olmak üzere her yerde dağıtılabilen temel bulut çözümüdür. Çok fazla ve karmaşık bileşenleri mevcuttur. Openstack’in esnekliği ve modülerliği, Uç birimlerde minimum hizmetlerin verimli bir şekilde çalıştırılmasını sağlarken, Fiziksel sunucu, konteyner teknolojileri ve sanal makineleri sağlam bir şekilde destekler. Genel olarak, Openstack’in altı tür dağıtım modeli vardır:

Donanım tedarikçisi tabanlı çözümler (Huawei, Fujitsu vb.): Bazı büyük teknoloji şirketleri, kendi donanım ve yazılım çözümleriyle Openstack’i paketler ve sunar. Huawei Flex Cloud çözümü gibi.

RedHat: Openstack projesine katkıları ve geniş kullanıcı tabanı ile bilinen RedHat, Openstack için kapsamlı dökümantasyon sağlar ve lisanslı dağıtımları için destek sunar. Enterprise çözümler için tedarikçi ile görüşmek gerekir fakat son yıllarda Openshift yüzünden üvey evlat muamelesi gören bir çözüm olmuştur.

Canonical: “Sunbeam” çözümüyle, Canonical MaaS (Metal as a Service) ve Juju gibi diğer araçları entegre eder. Ayrıca ücretli Pro sürümleriyle destek paketleri mevcut. Canonical ayrıca bir MicroCloud çözümüne sahip, ancak bu çözümü bir çözüm olarak kullanmadık ve detaylarını bilmiyoruz. LXD konteynerleri hipervizör değillerdir ve izolasyon sağlamazlar. Fakat LXD ile MicroCloud, qemu ile sanal sunucu kurarak bunları yönetiyorlar. Snapd teknolojisini sevmiyorsanız kesinlikle yaklaşmayın, ciddi anlamda kapalı bir ekosistemleri var. Bu çözümlerin hepsi Alpha çözümlerdir (2023 senesinde anons ettiler)

OpenStack – Açık Kaynak: OpenStack(kendisi), topluluklar veya şirketler tarafından desteklenen çeşitli dağıtımlara sahip bir açık kaynak bulut bilişim platformudur.

• Kubernetes dağıtımı (starlingX, Helm) – Biraz eski olarak ve güncelliğini yitirmiş bir proje olan StarlingX, Kubernetes’i OpenStack ile entegre eden bir proje olarak çalışır. StarlingX ilk anons edildiğinde sektörde Uç Bulut hizmeti sağlamak isteyen operatörler tarafından kullanıldı. Zaman içinde ilgisi yitirilmiş te olsa anahtar teslim bir çözüm olarak öne çıkar. Kullanacağınız tüm cihazları Kubernetes içerisine dahil edersiniz. Sonrasında Helm ile Openstack kubernetes üzerine yüklenir.
• Ansible dağıtımı (kolla-ansible): Kolla-ansible, OpenStack’i Ansible kullanarak dağıtmak için bir araçtır. OpenStack dağıtımlarını otomatikleştirir ve basitleştirir. Test ortamınızda kolaylıkla kurabilirsiniz. 

VMware’den OpenStack’e Geçiş

Başarılı bir geçiş için en kritik unsur planlamadır. Dikkatli planlama gerektiren üç ana bileşen vardır:

Compute

• Yalnızca VMware’mi olacak ?
• KVM + VMware beraber mi olacak ?

Network

• Leaf Spine Ağ yapısı kullanıyoruz ?
• L2 ağı kullanıyoruz
  • vLAN 3000-3999 Sunucu ağları
  • vLAN 2001 veri ağı
    
  • vLAN 2002 Storage Ağı
  • vLAN 2003 Yedekleme Ağı

Depolama

• Konvansiyonel Depolama Çözümü (HP, Netapp, EMC..)
• Hyperconverged
  • Vxrail
  • CEPH

Geçiş İşlemi

Kaynak ortam (mevcut VMware ortamı) ve Yeni ortam (OpenStack tabanlı altyapı) eş zamanlı olarak kurulu olmalıdır. Kaynak mimariden boşa çıkartılmış bileşenler(sunucu,disk,ağ ekipmanı), hedef mimariyi oluşturmak için kullanılacaktır. Yeni ağ tasarımına bağlı olarak, her iki mimari de geçiş süreci boyunca bir arada var olmalıdır.

Geçiş için proje içeriği şu şekilde olmalıdır:

• Yönetim Sponsorluğu (üst yönetim onayı)
• Uygun bir çözüm ortağı seçme.
• Kapsamlı bir proje planı oluşturma
• Gerekli kaynakların planlanması ve tahsisi.
• Ağ mimarisinin yeniden tasarlanması ve meslektaşlardan ve yönetimden(kesinti) onay alınması.
• İlk testlerin yapılması. Geçişin, örneğin Grup 1 örnekleriyle (20-100 gibi sanal sunucu) başlayarak aşamalı olarak gerçekleştirilmesi.

Kaynak: Kubedo