Bir yazılım firması, dijital ajans veya kendi uygulamalarını yöneten işletme için sunucu sayısı arttıkça yalnızca toplam işlemci ve RAM ihtiyacı değil, bu kaynakların nasıl dağıtıldığı da önemli hale gelir. Her…
Bir yazılım firması, dijital ajans veya kendi uygulamalarını yöneten işletme için sunucu sayısı arttıkça yalnızca toplam işlemci ve RAM ihtiyacı değil, bu kaynakların nasıl dağıtıldığı da önemli hale gelir. Her proje için bağımsız bir sunucu kiralamak uygulanabilir bir yöntem olsa da çok sayıda ortam söz konusu olduğunda kaynakların ayrı paketler halinde takip edilmesi yönetimi zorlaştırabilir. Sanal veri merkezi modeli ise belirlenmiş işlemci, RAM ve depolama kaynaklarını ortak bir havuz mantığıyla yöneterek bu havuz içinde birden fazla sanal sunucu oluşturmayı mümkün kılar.
DeHost tarafından sunulan sanal veri merkezi hizmeti kapsamında kullanıcıya ayrılmış işlemci, RAM ve NVMe kaynakları özel panel üzerinden yönetilebiliyor. Kullanıcı, sahip olduğu toplam kaynak sınırları içerisinde ihtiyacına göre birden fazla VDS oluşturabiliyor. Böylece farklı uygulamalar, müşteriler veya çalışma ortamları için ayrı sanal sunucular oluşturulurken toplam altyapı tek bir kaynak bütçesi üzerinden planlanabiliyor.
Sanal veri merkezi, fiziksel altyapıdaki işlemci, bellek ve depolama kapasitesinin sanallaştırma teknolojileri aracılığıyla yönetilebilir bir kaynak havuzuna dönüştürülmesi üzerine kurulu bir modeldir. Kullanıcıya belirli bir kaynak kapasitesi ayrılır ve bu kapasite farklı sanal sunucular arasında planlanabilir.
Buradaki temel fark tek bir VDS edinmekten ziyade birden fazla VDS oluşturabilecek bir altyapının yönetilmesidir. Örneğin aynı şirketin kurumsal web uygulaması, test sistemi ve müşteriye özel bir yazılımı bulunuyorsa bu iş yüklerinin tamamını tek sunucuda toplamak yerine birbirinden ayrılmış sanal sunucular üzerinde çalıştırmak mümkün olur. Her sunucu kendi kullanım amacı doğrultusunda yapılandırılırken toplam kaynak ihtiyacı havuz seviyesinde ele alınabilir.
DeHost’un ilgili hizmet sayfasında bu yapı için Intel Xeon E5-2699 v4 işlemci altyapısı, NVMe depolama, Türkiye lokasyonu, DDoS koruması ve limitsiz trafik gibi ortak özellikler belirtiliyor. Hizmet ayrıca otomatik kurulum sistemi ve özel yönetim paneliyle sunuluyor.
Bağımsız VDS modelinde ihtiyaç duyulan her sanal sunucu ayrı bir hizmet olarak seçilir. Bir proje için daha fazla kaynak gerekirken başka bir proje düşük kaynakla çalışsa bile iki sunucunun paketleri birbirinden bağımsızdır. Kaynak havuzu yaklaşımında ise önce toplam kapasite belirlenir, ardından bu kapasite limitleri içinde farklı sanal sunucular oluşturulur.
| Kriter | Ayrı VDS modeli | Kaynak havuzu modeli |
|---|---|---|
| Kaynak planlama | Her sunucu için ayrı paket seçilir. | Toplam işlemci RAM ve depolama kapasitesi birlikte planlanır. |
| Sunucu oluşturma | Yeni ihtiyaç için ayrı bir VDS hizmeti gerekir. | Mevcut havuz sınırları içinde birden fazla VDS oluşturulabilir. |
| Yönetim yaklaşımı | Sunucular bağımsız hizmetler olarak takip edilir. | Kaynaklar ortak altyapı üzerinden yönetilir. |
| Kullanım yapısı | Az sayıda ve birbirinden bağımsız sistemlerde daha basit olabilir. | Birden fazla proje müşteri veya ortam yöneten yapılarda kullanışlıdır. |
| Kapasite takibi | Her VDS kendi ayrılmış kapasitesi üzerinden değerlendirilir. | Oluşturulan sanal sunucular toplam kaynak sınırı dikkate alınarak planlanır. |
Bu nedenle seçim yalnızca kaç sunucu gerektiğine göre yapılmamalıdır. İş yüklerinin birbirinden ayrılması gerekip gerekmediği, kaynak tüketimlerinin ne kadar değişken olduğu ve yeni sanal sunucu ihtiyacının ne sıklıkta ortaya çıktığı da değerlendirilmelidir.
Birden fazla web uygulaması veya yazılım ürünü geliştiren firmalarda her projenin aynı işletim sistemi, yazılım bileşeni ve kaynak gereksinimine sahip olması beklenmez. Proje başına ayrı VDS kullanılması uygulamaların birbirinden ayrılmasını sağlar. Bir projede gerçekleştirilen sistem yapılandırmasının diğer projenin çalışma ortamını doğrudan etkilememesi de operasyonel düzen açısından avantaj yaratır.
Kaynak havuzu burada özellikle çok sayıda orta veya küçük iş yükünün birlikte yönetildiği yapılarda anlam kazanır. Firma toplam kapasiteyi belirleyip bu sınırlar içinde farklı projeler için ayrı sanal makineler oluşturabilir. Yeni proje eklerken ise önce havuzdaki kullanılabilir işlemci, RAM ve depolama kapasitesinin yeterli olup olmadığı kontrol edilir.
Yazılım geliştirme süreçlerinde test ortamıyla gerçek kullanıcıların eriştiği canlı sistemin ayrılması sık kullanılan bir altyapı yaklaşımıdır. Test sırasında yapılan sürüm değişiklikleri, servis yapılandırmaları veya uygulama denemeleri ayrı bir sunucuda yürütüldüğünde canlı ortamın aynı işletim sistemi üzerinde yapılan değişikliklerden etkilenme ihtimali azaltılır.
Sanal veri merkezi modeli bu ayrımı birden fazla bağımsız VDS oluşturarak gerçekleştirmeye elverişlidir. Örneğin bir sanal sunucu geliştirme ve test süreçlerine, diğeri canlı uygulamaya ayrılabilir. Daha büyük ekiplerde veri tabanı veya belirli yardımcı servisler için ek makineler de oluşturulabilir. Buradaki sınır, satın alınan havuzun toplam kaynak kapasitesidir.
Ajanslar ve birden fazla kurumsal müşterinin uygulamasını yöneten yazılım şirketleri zaman zaman müşteri ortamlarını birbirinden ayırmayı tercih eder. Bu yaklaşım yapılandırma, işletim sistemi seçimi ve kaynak takibini müşteri bazında düzenlemeyi kolaylaştırabilir.
Örneğin üç farklı müşterinin uygulamalarını yöneten bir firma her müşteri için ayrı bir sanal sunucu oluşturabilir. Böyle bir yapıda kaynakların baştan rastgele dağıtılması yerine müşterilerin gerçek kullanım profilleri dikkate alınmalıdır. Yoğun veri tabanı işlemleri yapan bir uygulamanın ihtiyacıyla düşük trafikli bir kurumsal uygulamanın ihtiyacı aynı olmayabilir.
Kaynak havuzu kullanılacaksa ilk hesap yalnızca mevcut tüketim üzerinden yapılmamalıdır. İşlemci kullanımı, RAM tüketimi, depolama ihtiyacı ve ileride oluşturulması beklenen sanal sunucular birlikte değerlendirilmelidir. Toplam kapasitenin tamamını ilk günden sanal sunuculara dağıtmak yeni bir proje veya geçici test ortamı gerektiğinde hareket alanını daraltabilir.
DeHost’un modelinde işlemci, RAM ve NVMe kaynakları kullanıcıya ayrılıyor ve özel panel aracılığıyla yönetiliyor. Kaynak limitleri içerisinde birden fazla VDS oluşturulabilmesi, kapasite planlamasını tek tek bağımsız paketleri değerlendirmekten farklı hale getiriyor. Hizmetin aylık veya yıllık kiralama seçenekleri bulunuyor.
Bu tür bir altyapıda maliyeti değerlendirirken yalnızca oluşturulacak sanal sunucu sayısına bakmak yeterli değildir. Asıl belirleyici ihtiyaç duyulan toplam işlemci kapasitesi, RAM miktarı ve NVMe depolama alanıdır. Daha fazla uygulama barındırmak veya yüksek kaynak tüketen iş yüklerini birbirinden ayırmak isteyen bir işletmenin daha geniş bir kaynak havuzuna ihtiyacı olabilir.
Bu nedenle fiyat karşılaştırması yaparken önce kaç VDS oluşturulacağı değil, bu makinelerin birlikte ne kadar kaynak tüketeceği hesaplanmalıdır. Düşük kaynak tüketen çok sayıda sistem ile yüksek işlemci ve bellek ihtiyacı bulunan birkaç uygulama aynı kapasite ihtiyacını doğurmayabilir.
Birden fazla sunucunun aynı altyapı altında yönetilmesi yedekleme ihtiyacını ortadan kaldırmaz. DeHost’un hizmet sayfasında yedekleme hizmeti ayrıca alınmadığı sürece verilerin yedeklenmediği ve yedekleme sorumluluğunun kullanıcıya ait olduğu açıkça belirtiliyor. Bu nedenle firma kendi yedekleme politikasını kaynak planlamasından ayrı bir başlık olarak ele almalıdır.
Özellikle müşteri sistemleri, veri tabanları ve üretim ortamları yönetiliyorsa hangi verinin hangi sıklıkta korunacağı, yedeklerin nasıl kontrol edileceği ve geri yükleme süreçlerinin kim tarafından yürütüleceği önceden belirlenmelidir. Sanal sunucuların birbirinden ayrılması tek başına veri yedeği anlamına gelmez.
Kaynak havuzu yaklaşımı özellikle birden fazla sunucuyu sürekli yöneten yazılım firmaları, ajanslar ve farklı uygulama ortamları bulunan işletmeler için değerlendirilebilir. Tek bir küçük uygulama çalıştıran ve ikinci bir sunucu ihtiyacı öngörmeyen kullanıcı için bağımsız bir VDS daha sade bir yapı olabilir. Buna karşılık proje sayısı arttıkça ve test, canlı sistem veya müşteri ortamlarının ayrılması gerektiğinde ortak kaynak havuzu yönetimi daha işlevsel hale gelir.
Karar verirken temel soru kaç ayrı sunucu satın alınacağı değil, toplam altyapı kapasitesinin nasıl kullanılacağı olmalıdır. İşlemci, RAM ve NVMe kaynaklarının tek havuzdan yönetilmesi ve bu sınırlar içinde farklı VDS’lerin oluşturulabilmesi, çoklu sunucu mimarisini merkezi bir kapasite planına dönüştürür. Böylece firma her yeni iş yükünü bağımsız bir sunucu satın alma kararı olarak değil, mevcut kaynak bütçesinin nasıl bölüneceği sorusu üzerinden değerlendirebilir.
Yorum Yap