Şirket içinde barındırma daha doğrudan fiziksel kontrol sunarken, veri merkezi hizmeti tesis ve barındırma sorumluluklarının bir bölümünü dışarı taşır. Uygulama bağımlılıkları, bağlantı ihtiyacı, yönetim kapsamı ve toplam maliyet birlikte karşılaştırılmalıdır.
Bir sunucuyu veri merkezine taşımak, elektriği ve soğutmayı başka bir ortamda sağlamakla başlayabilir; fakat uygulamanın erişim, performans ve yönetim ihtiyaçlarını ortadan kaldırmaz. Şirket içinde tutmak da otomatik olarak daha hızlı, daha ucuz veya daha güvenli bir sonuç vermez. Karar, iş yükünün bağımlılıklarını ve hata senaryolarını karşılaştırarak verilmelidir.
Üretim hattındaki yerel cihazlarla çalışan bir uygulama, çok şubeli bir ERP ve dış müşterilere açık bir portal aynı yerleşim kararını gerektirmeyebilir. Bu nedenle önce uygulamaları gruplandırın; ardından her grup için bağlantı, veri, erişilebilirlik ve işletim modelini değerlendirin.
1. Şirket içi, colocation ve sanal kaynak kiralama
Şirket içinde barındırmada fiziksel ortam ve donanım doğrudan işletmenin sorumluluğundadır; teknik işletim yine dış hizmetle yürütülebilir. Colocation modelinde işletmenin donanımı veri merkezinde barındırılır. Kabin, enerji ve bağlantı hizmeti alınması, donanım arızası veya işletim sistemi yönetiminin de otomatik olarak devredildiği anlamına gelmez.
Sanal kaynak kiralamada fiziksel altyapının bir bölümü sağlayıcı tarafından yönetilir. Müşteri işletim sistemi, uygulama ve veri yönetimini kendisi yapabilir veya ek yönetim hizmeti alabilir. Bu sınırlar teknoloji adına bakılarak tahmin edilmemelidir. Teklifte sanal makine, fiziksel sunucu ve yönetilen uygulama seçeneklerinin sorumluluk tablosu ayrı olmalıdır.
| Katman | Şirket içinde | Veri merkezi hizmetinde sorulacak soru |
|---|---|---|
| Fiziksel ortam | Enerji, soğutma ve fiziksel erişim işletmede | Hangi tesis ve enerji hizmeti kapsamda? |
| Donanım | Satın alma, bakım ve yedek parça planı | Donanım kime ait, arızayı kim gideriyor? |
| İşletim sistemi | İç ekip veya sağlayıcı yönetebilir | Yama ve izleme ayrıca sunuluyor mu? |
| Uygulama ve veri | Uygulama sahibinin sorumluluğu tanımlanır | Veritabanı, yedek ve uygulama kabulü kimde? |
Tablonun tamamı için yana kaydırabilirsiniz.
2. Gecikme ve bağlantı bağımlılığını ölçün
Bant genişliği, aynı anda taşınabilecek veri miktarını; gecikme ise bir iletişimin ne kadar sürede gerçekleştiğini etkiler. Küçük ama birbirini bekleyen çok sayıda veri isteği yapan bir uygulama, bağlantı hızı yüksek olsa da uzak yerleşimde yavaşlayabilir. Sunucuyu taşımadan önce gerçek kullanıcı işlemlerinin yanıt süresini farklı bağlantı koşullarında ölçmek gerekir.
Bir işlem 300 ardışık ağ turunu bekliyorsa ve her turda 20 milisaniye ek gecikme oluşuyorsa teorik ek bekleme 6 saniyedir. Bu bir ürün performans ölçümü değildir; isteklerin paralel çalışması, önbellek ve uygulama tasarımı sonucu değiştirir. Örnek, yalnız Mbps değerinin neden yeterli olmadığını gösterir.
Uzak yerleşimde şube veya fabrikanın interneti kesilirse uygulamaya erişimin nasıl süreceği belirlenmelidir. Alternatif operatör, farklı fiziksel güzergâh ve devralma davranışı birlikte değerlendirilir. Aynı kablo girişini paylaşan iki bağlantı, o girişin hasarına karşı bağımsız koruma sağlamayabilir. Yerel üretim sistemlerinin dış bağlantı olmadan ne yapabildiği ayrıca test edilir.
3. Kaynak ihtiyacını ortalamadan değil yük profilinden çıkarın
İşlemci ve RAM miktarı, uygulama performansının yalnız bir bölümüdür. Disk gecikmesi, rastgele okuma/yazma oranı, veri değişim hızı ve eş zamanlı kullanıcı davranışı da ölçülmelidir. Gece yedekleme, ay sonu raporu ve üretim başlangıcı gibi yoğun dönemler normal gün ortalamasının arkasında kaybolabilir.
Teklifte depolama için yalnız toplam kapasiteyi karşılaştırmak yeterli olmaz. Beklenen IOPS, aktarım hızı ve gecikmenin hangi iş yükünde sağlandığı önemlidir. Paylaşılan ortamlarda kaynak tahsis modeli, performans sınırları ve kapasite artırma süreci sorulmalıdır. Bir test, aynı veri seti ve aynı iş senaryosuyla yapıldığında daha anlamlıdır.
HA ihtiyacı varsa arıza sonrasındaki kapasite ayrı hesaplanır. Örneğin üç düğümden biri kaybedildiğinde kalan iki düğüm kritik uygulamaları taşıyabilmelidir. Yeniden eşitleme ve yedekleme yükü de bu döneme denk gelebilir. İyi çalışan normal gün performansı, arıza anı için tek başına yeterli kanıt değildir.
4. Fiziksel yedeklilik ile uygulama devamlılığını ayırın
Bir veri merkezinin enerji ve soğutma tasarımı, orada çalışan uygulamanın veritabanı veya kimlik servisinin yedekli olduğunu göstermez. Aynı şekilde yüksek erişilebilir sanallaştırma, hatalı veri silmeye karşı geçmişe dönülebilir kopya sağlamaz. Tesis, sunucu, uygulama ve veri katmanları için farklı arızalar tarif edilmelidir.
Veri merkezi teklifinin taahhüt ettiği erişilebilirlik hangi bileşene aittir? Enerji, ağ, sanal kaynak veya uygulama erişimi farklı kapsamlar olabilir. Ölçüm dönemi, hariç tutulan koşullar ve olayın başlangıç noktası okunmalıdır. İşletme açısından önemli ölçüm, kullanıcının kritik işini yapabilmesidir; bu sonuç birden fazla hizmetin birlikte çalışmasına bağlıdır.
5. Yönetim, güvenlik ve çıkış planını aynı dosyaya koyun
Yönetim erişimi, günlük toplama, yama, veritabanı bakımı ve yedekleme için görev dağılımı yazılmalıdır. Yedeklerin ana ortamla aynı yönetici hesaplarına ve aynı lokasyon riskine bağımlı olup olmadığı değerlendirilir. Ayrı bir kopyanın varlığı kadar geri yükleme için gerekli anahtarların ve yetkilerin bulunması da önemlidir.
Taşınacak verinin sınıfı ve kurumun sözleşmesel gereksinimleri, yerleşim kararının girdisidir. Gerçek veri konumu, alt hizmet sağlayıcılar ve erişim modeli sağlayıcıdan öğrenilmelidir. “Bulut” kelimesi tek başına belirli bir ülkeyi, güvenlik seviyesini veya mevzuat uyumunu garanti etmez; gereksinimler somut hizmet özellikleriyle eşleştirilir.
Çıkış planında veri dışa aktarma biçimi, ağ üzerinden aktarım kapasitesi, ek ücretler ve hizmet sonlandırma sırası bulunur. Büyük veriyi içeri almak kolayken dışarı taşımanın ne kadar süreceği gözden kaçabilir. Bir gün platform değiştirildiğinde uygulamaların hangi sırayla ve hangi tutarlılık kontrolleriyle taşınacağı baştan düşünülmelidir.
6. Toplam maliyet ve karma yerleşim kararı
Karşılaştırmayı aynı süre ve aynı kapsamla yapın. Şirket içi modelde yatırım, enerji, soğutma, bağlantı, lisans, bakım, personel ve yenileme ihtiyacı birlikte ele alınır. Hizmet modelinde abonelik, ek kaynak, trafik, yedekleme, yönetim ve çıkış maliyetleri eklenir. Varsayımlar açık olmadığında düşük görünen ilk bedel uzun vadeli kararı yanlış yönlendirebilir.
Örnek bir karma yerleşimde üretim hattıyla yakın iletişim gereken sistemler yerelde kalırken merkezi iş uygulamaları veri merkezinde çalışabilir. Bu iki ortam arasındaki kimlik, ağ ve veri akışı yine birlikte yönetilir. Red Hat’in hibrit bulut açıklaması da farklı ortamların birlikte işletilmesini temel alır.
Karar dosyasının çıktısı tek kelimelik “bulut” veya “yerel” tercihi olmamalıdır. Her iş yükü için yerleşim, bağlantı bağımlılığı, hedef performans, yönetim sorumluluğu ve geri dönüş yöntemi belirlenmelidir. Bu çalışma, daha sonra yapılacak kapasite ve süreklilik yatırımının da teknik temelini oluşturur.
Sık sorulan sorular
Bütün sunucuları aynı anda taşımak gerekir mi?
Gerekmez. Bağımlılıklar ve çalışma düzenine göre aşamalı bir geçiş değerlendirilebilir.
Barındırma hizmeti yedeklemeyi içerir mi?
Her pakette aynı değildir. Kapsam, saklama, kopya lokasyonu ve geri yükleme sorumluluğu ayrıca okunmalıdır.