Sunucu Sanallaştırma ve Konsolidasyon: Maliyeti Yarıya İndiren Yaklaşım

Birçok şirkette sunucu odası yıllar içinde katmanlanarak büyür: her yeni uygulama için bir fiziksel sunucu alınır, eskisi 'ihtiyaç olur' diye kapatılmaz. Sonuçta ortalama işlemci kullanımı yüzde 10-15 bandında kalırken elektrik, klima, bakım ve lisans giderleri katlanır. Sanallaştırma bu tabloyu tersine çevirir: aynı iş yükü daha az fiziksel donanımda, daha yüksek erişilebilirlikle çalışır.

1. Konsolidasyon oranını gerçek veriye dayandırın

Projeye başlamadan önce en az dört hafta boyunca CPU, RAM, disk IOPS ve ağ trafiği ölçülmelidir. Ay sonu kapanışı, bordro günü veya sezonluk kampanya gibi tepe noktaları bu pencereye dâhil edilmelidir; aksi hâlde ortalamaya göre boyutlandırılmış bir küme kritik günde tıkanır. Tipik bir KOBİ ortamında 12-16 fiziksel sunucu, 2-3 düğümlü bir kümede rahatlıkla toplanabilir. Mevcut durumun tarafsız fotoğrafını çekmek için ücretsiz BT denetimi sürecimizden yararlanabilirsiniz.

2. Hipervizör seçimi: teknik değil, toplam maliyet kararı

Bugün piyasadaki hipervizörlerin çekirdek yetenekleri birbirine oldukça yakındır. Farkı yaratan üç kalem vardır: çekirdek başına lisans modeli, yedekleme yazılımınızın entegrasyon derinliği ve ekibinizin operasyon alışkanlığı. Lisans modeli son yıllarda hızla değiştiği için beş yıllık toplam sahip olma maliyetini tabloya dökmeden karar vermeyin. Lisans tarafındaki tuzakları yazılım ve lisans yönetimi sayfamızda ayrıntılı ele alıyoruz.

3. Depolama mimarisi darboğazın kaynağıdır

Sanallaştırma projelerinde performans şikâyetlerinin büyük çoğunluğu işlemciden değil depolamadan gelir. Veritabanı sunucuları için gecikme (latency) hedefini milisaniye cinsinden yazılı olarak belirleyin, tüm sanal makineleri aynı disk havuzuna yığmayın. All-flash havuzlar artık maliyet olarak erişilebilir; hibrit yapılarda ise sıcak veri ayrımı doğru kurgulanmalıdır.

4. Yedeklilik: tek düğüm tek risk demektir

Konsolidasyonun görünmeyen yan etkisi risk yoğunlaşmasıdır: on fiziksel sunucuyu iki düğüme taşıdığınızda bir düğüm arızası artık on servisi birden etkiler. Bu nedenle N+1 düğüm planı, çoklu güç hattı ve otomatik yük devretme (failover) opsiyonel değil zorunludur. Kesintinin şirketinize saatlik maliyetini kesinti maliyeti hesaplayıcısı ile hesaplayıp bu yatırımı yönetime gerekçelendirebilirsiniz.

5. Göç planı: sessiz hafta sonu yerine kademeli geçiş

• Düşük kritiklikteki test ve dosya sunucularıyla başlayın; ekip aracı gerçek ortamda öğrensin.
• Her göç öncesi tam yedek alın ve geri dönüş (rollback) adımlarını yazılı hâle getirin.
• Uygulama sahiplerinden göç sonrası kabul testi imzası isteyin.
• Eski fiziksel sunucuyu hemen imha etmeyin; iki hafta kapalı ama hazır bekletin.
• Kapanan donanımları yeşil BT ve enerji verimliliği ilkelerine uygun şekilde imha edin veya yeniden değerlendirin.

6. Sanallaştırma mı, bulut mu?

Sabit ve öngörülebilir iş yükleri için şirket içi sanallaştırma çoğu zaman daha ucuzdur; dalgalı, mevsimsel veya hızlı büyüyen yükler bulutta daha verimlidir. Çoğu kurum için doğru cevap ikisinin karışımıdır. Karar öncesi rakamları görmek için bulut geçişi maliyet analizi yazımızı okuyun, kendi senaryonuz için ROI hesaplayıcısını çalıştırın.

Sanallaştırma bir kerelik proje değil, kapasite yönetimi disiplininin başlangıcıdır. Kaynak kullanımını üç ayda bir gözden geçirmeyen kurumlar birkaç yıl içinde aynı israfı sanal ortamda yeniden üretir. Kurumunuza özel konsolidasyon planı ve bütçesi için teklif sihirbazını kullanabilir, kapsamı hizmetler sayfasından inceleyebilirsiniz.