Veri Merkezi Seçimi İçin 10 Kritik Kriter Rehberi

Veri merkezi kararını verirken nereden başlamalı?

Canlı sistemleri taşıyacağınız bir tesis seçeceğiniz zaman, iş sadece fiyat teklifi toplamakla bitmez. Veri merkezi seçimi, SLA seviyesinden felaket kurtarma senaryonuza kadar tüm mimariyi etkiler. Yanlış karar, saatlerce süren kesintiler, veri kaybı ve uyku kaçıran gece bakım pencereleri demektir. Doğru karar ise öngörülebilir uptime, stabil bir network altyapısı ve ölçeklenebilir bir platform anlamına gelir.

Bir sistem yöneticisi olarak ilk baktığım şey, tesisin kağıt üzerindeki özelliklerinden çok operasyonel olgunluğu ve geçmiş performansıdır. Tier seviyesi, enerji altyapısı, bağlantı seçenekleri, izleme sistemleri ve destek ekibinin tecrübesi bu resmin önemli parçalarıdır. Bunları netleştirmeden imza atmak, üretim ortamını kumar masasına koymakla aynı şey.

İhtiyaç analizi: Hangi yükü nereye koyuyorsunuz?

Detaylara girmeden önce, hangi iş yükünü bu veri merkezine taşıyacağınızı netleştirmek gerekir. Yük tipi, seçeceğiniz yapıyı doğrudan belirler:

• Kritik kurumsal uygulamalar (ERP, core banking, ödeme sistemleri)
• Yüksek trafikli web uygulamaları ve API hizmetleri
• Yoğun IO tüketen veritabanları
• Yedekleme, arşivleme ve log depolama yükleri

Örneğin, gecikmeye çok duyarlı bir finansal uygulama ile sadece yedek depolayan bir ortamın gereksinimleri aynı değildir. İlkinde düşük latency, yüksek uptime ve yedekli network altyapısı kritik olurken, ikincisinde daha çok depolama kapasitesi ve maliyet öne çıkar.

Biz canlı sistem taşırken genellikle önce küçük bir pilot iş yüküyle tesisi deneriz: Birkaç VPS veya VDS sunucu açar, gerçek kullanıcı trafiğine benzer yükler altında latency, IO performansı ve paket kaybını günlerce izleriz. Teklif dokümanında yazan hiçbir şey bu pratik gözlemin yerini tutmaz.

Veri merkezi seçimi için 10 kritik kriter

1. Lokasyon, gecikme ve afet riski

Adres sadece posta için önemli değil. Lokasyon; gecikme sürelerini, afet riskini ve fiziksel erişim imkanınızı belirler. Özellikle Türkiye içi kullanıcıya hizmet veriyorsanız, yurtdışındaki bir tesise giden rotanın uygulamanız için kabul edilebilir olup olmadığını ölçmeden karar vermeyin. Sadece ülke veya şehir bilgisi yeterli değildir.

Değerlendirirken şu noktalara bakın:

• Son kullanıcıya ve sizin ofisinize olan fiziksel mesafe
• Deprem, sel, yangın gibi afet riskleri ve bölgesel koşullar
• Şehre ve ana ulaşım akslarına olan yakınlık (acil durumda erişim için)

Pratik bir adım olarak, tesise yakın farklı ISP noktalarından gecikme ve rota analizi yapın. mtr veya benzeri araçlarla rotanın kaç hop üzerinden geçtiğini, nerelerde jitter oluştuğunu görün. Ara hoplarda görülen paket kaybının hedefte de tekrarlanıp tekrarlanmadığını ayrıca kontrol edin; bazı router’lar ICMP paketlerini düşük öncelikli işler. Kağıt üzerinde iyi görünen bir lokasyon, pratikte sorunlu bir güzergaha sahip olabilir.

2. Tier seviyesi ve tasarım standartları

İkinci kritik başlık, tesisin tasarım standardı. Burada genellikle Uptime Institute’un Tier I, II, III ve IV sınıflandırmaları kullanılır. Kurumsal üretim yükleri için en azından Tier III veri merkezi seviyesini hedeflemek mantıklı bir eşiktir; fakat Tier seviyesi tek başına işletme kalitesini veya belirli bir uptime garantisini kanıtlamaz.

Tier III tasarımının temel özelliği, bakım için kritik kapasitenin kapatılmasına gerek bırakmayan concurrently maintainable yapıdır. Bu, her bileşenin mutlaka 2N olduğu anlamına gelmez. Yedekliliğin hangi alt sistemlerde nasıl uygulandığını ayrıca sormak gerekir.

Tier III veri merkezi değerlendirmesinde şu noktaları arayın:

• Bakım sırasında kritik yükün çalışmaya devam edebilmesi
• Elektrik ve mekanik altyapıda tanımlı yedeklilik düzeni
• Planlı bakım prosedürlerinin ve test kayıtlarının bulunması

Elbette sadece “biz Tier III seviyesindeyiz” demeleri yetmez. Uptime Institute sertifikasının kapsamını ve geçerliliğini, tasarım ile tesis altyapısının hangi aşamalarının belgelendirildiğini isteyin. Sertifika yoksa, en azından tasarımın Tier III prensiplerine ne kadar uyduğunu sorgulayın. Bir harfin arkasına saklanan pazarlama söylemi yerine, teknik gerçekleri görmek gerekir.

3. Uptime, SLA ve bakım pencereleri

Kağıt üzerinde yazan uptime yüzdesi, işin sadece görünen yüzü. %99,982 ile %99,9 arasında bile aylık ve yıllık hesapta ciddi kesinti farkı çıkar. Bu oranların hangi hizmet bileşeni için ve hangi ölçüm yöntemiyle hesaplandığına bakmadan birbirleriyle karşılaştırmayın.

Özellikle şu soruların cevabını isteyin:

• SLA hesaplamasında hangi bileşenler dahil? Sadece backbone mu, yoksa sanal makineye veya sunucuya kadar mı?
• Planlı bakım kesintileri uptime hesabına nasıl yansıtılıyor?
• Hedefler tutturulamazsa hangi hizmet kredisi veya tazmin mekanizması uygulanıyor?
• Olağanüstü durumlar için tanımlanan istisnalar ne kadar geniş?

Gerçekçi olmak gerekirse hiçbir tesis %100 verilebilirlik garantisini pratikte sağlayamaz. Ancak iyi tasarlanmış bir Tier III veri merkezi, ölçümü açık bir SLA ile desteklendiğinde iş yüklerinizi uzun vadede daha öngörülebilir hale getirir. Ayrıca bakım planlarının önceden duyurulma şekli ve sıklığı da kritiktir. Gece 03:00 bakım penceresinin sizin uygulamanız için aslında pik saat olması kimsenin işine yaramaz.

4. Network altyapısı ve bağlantı çeşitliliği

Birçok kesinti senaryosunda sorun sunucularda değil, ağ katmanında çıkar. Bu yüzden network altyapısı, veri merkezi seçiminin kritik parametrelerinden biridir. Ana omurganın tasarımı, kullanılan donanım, yedeklilik seviyesi ve operatör çeşitliliği mutlaka sorgulanmalıdır.

Sorulması gereken temel başlıklar:

• Kaç farklı telekom operatörüyle fiziksel bağlantı mevcut?
• Border router ve core switch mimarisi nasıl tasarlanmış? Tek bir cihaz veya tek bir noktaya bağımlılık var mı?
• DDoS koruması hangi katmanda, hangi kapasite ve müdahale prosedürüyle sağlanıyor?
• Peering politikaları ve internet değişim noktalarına olan bağlantılar nasıl?

Yeni bir tesis test ederken mutlaka uzun süreli latency ve paket kaybı ölçeriz. Bir keresinde farklı ISP hatlarından aldığım mtr çıktısında ara hoplardan birinde görünen yüzde 20 kayıp ilk bakışta alarm gibi duruyordu; hedefte kayıp olmadığı için bunun ICMP önceliklendirmesi olduğunu ayırabildim. Bu yüzden tek bir çıktıya değil, farklı kaynaklardan ve farklı zamanlarda toplanan verilere bakıyorum. Örneğin VPS.TC üzerindeki bir bulut sunucu ile 24-48 saatlik ping ve mtr sonuçlarını toplamak, ağ kalitesi hakkında gerçeğe çok daha yakın bir fikir verir.

5. Güç altyapısı, jeneratör ve enerji sürekliliği

Sunucu odasında her şey iyi görünebilir, ama güç hattında tek bir zayıf halka varsa tüm yatırımınız bir anda karanlıkta kalır. Sağlam bir güç altyapısı olmadan yüksek uptime hedeflemek gerçekçi değildir.

İncelenmesi gereken noktalar:

• Şebeke beslemesi: Kaç bağımsız hat var, hangi trafolardan besleniyor?
• UPS mimarisi: N+1 mi, 2N mi, modüler mi?
• Jeneratör kapasitesi: Tam yük altında ne kadar süre çalışabilecek yakıt rezervi var?
• Yakıt tedarik anlaşmaları ve test periyotları nasıl?

Gerçek bir örnek: Bazı tesisler jeneratör testlerini tam yükte değil, kısmi yükte yapar. Bu da gerçek bir kesinti anında hiç denenmemiş bir senaryoyla karşılaşmanız anlamına gelir. Test prosedürlerini, kayıtlarını ve arıza geçmişlerini talep etmekten çekinmeyin. UPS’in batarya testlerinin yalnızca yazılım raporuna değil, planlı fiziksel doğrulamalara da dayanıp dayanmadığını sorun.

6. Fiziksel güvenlik ve erişim kontrolleri

Siber güvenlik kadar fiziksel güvenlik de önemlidir. Veri merkezinde yetkisiz biri sunucu odasına girdiyse en iyi firewall bile sizi koruyamaz. Bu nedenle erişim kontrolü, izleme ve kayıt politikaları mutlaka masaya yatırılmalı.

Kontrol etmeniz gereken başlıklar:

• Giriş kontrol sistemleri (kart, biyometrik, çok faktörlü erişim)
• 24/7 güvenlik personeli ve kamera izleme
• Ziyaretçi kayıt ve eskort politikaları
• Raf seviyesinde kilitleme ve bölümlendirme imkanları

Özellikle üretim ortamınızda disk sök-tak gibi fiziksel müdahaleler gerekiyorsa bu operasyonların nasıl kaydedildiğini sorgulayın. Her erişimin loglanması, kim tarafından ne zaman ne yapıldığının izlenebilir olması gerekir. Aksi halde bir olay yaşandığında geriye dönük inceleme yapmak imkansız hale gelir.

7. Yangın algılama, iklimlendirme ve ortam izleme

Birçok kişi veri merkezi seçerken sadece Tier seviyesi ve fiyatla ilgilenir, ancak tesis içi iklimlendirme ve yangın koruma sistemleri göz ardı edilir. Oysa bu katmandaki zayıflıklar donanım arızalarını ve beklenmeyen kesintileri artırabilir.

Sorulması gereken sorular şunlar:

• Hangi tip yangın algılama ve söndürme sistemi kullanılıyor? (VESDA, gazlı söndürme vb.)
• Soğutma mimarisi nasıl? Sıcak-soğuk koridor, free cooling, yedeklilik seviyesi nedir?
• Ortam izleme sensörleri hangi metrikleri takip ediyor? (sıcaklık, nem, sızıntı, duman vb.)
• Alarm eşik değerleri ve müdahale prosedürleri nasıl tanımlı?

Stabil çalışmayan bir iklimlendirme sistemi, özellikle disk ve PSU arızalarını artırır. Sensörlerin yalnızca değer toplaması yetmez; alarmın kime, hangi kanaldan ve ne kadar sürede ulaştığını da test edin.

8. Sertifikasyonlar, mevzuat ve uyumluluk

Özellikle finans, sağlık ve e-ticaret gibi sektörlerde çalışıyorsanız sadece teknik özellikler değil, uyumluluk gereksinimleri de önemlidir. İyi bir tesisin sahip olduğunu beyan ettiği standartların güncel kapsamını inceleyin:

• ISO/IEC 27001 (Bilgi güvenliği yönetim sistemi)
• ISO/IEC 20000-1:2018 veya kuruluşun kullandığı güncel hizmet yönetimi standardı
• PCI DSS v4.0.1 (Ödeme verisi işleyenler için, kapsam dahilindeyse)

Sertifikaların güncelliğini, kapsamını, geçerli olduğu lokasyonu ve denetim periyotlarını mutlaka sorgulayın. Bir sertifikanın bulunması, sizin uygulamanızın otomatik olarak uyumlu olduğu anlamına gelmez; sorumluluk paylaşımını yazılı hale getirin. Ayrıca KVKK ve ilgili diğer yerel mevzuata uyum konusunda nasıl bir hukuki çerçeve sunduklarını netleştirin. Uyumsuz bir veri merkezi ile çalışmak, olası bir denetimde doğrudan sizin başınızı ağrıtabilir.

9. Operasyon ekibi, süreçler ve destek kalitesi

Bizim işte teknoloji kadar insan faktörü de belirleyicidir. 03:00’te kritik bir arıza yaşadığınızda karşınızda prosedür ezberleyen biri mi olacak, yoksa problemi gerçekten anlayan kıdemli bir mühendis mi? Bu fark, kesinti süresini saatlerden dakikalara indirebilir.

Şu başlıkları netleştirin:

• Destek ekibi 7/24 yerinde mi, yoksa uzaktan çağrı mı alınıyor?
• Olay yönetimi, değişiklik yönetimi ve kök neden analizi süreçleri nasıl işliyor?
• Destek talepleri için SLA seviyeleri (yanıt süresi, çözüm süresi) nedir?
• Out-of-band erişim, KVM, uzaktan el-ayak (remote hands) hizmetleri nasıl sunuluyor?

Mümkünse referans müşterilerle konuşun, gerçek arıza senaryolarında nasıl bir performans sergilendiğini öğrenin. Teklif toplantısındaki sunumların etkileyiciliğinden çok, gerçek hayatta yaşanan vakalar size yol gösterir. Kök neden analizinin yalnızca “kullanıcı hatası” gibi genel ifadelerden oluşmadığını da kontrol edin.

10. Felaket kurtarma, yedek veri merkezi ve ölçeklenebilirlik

Hiçbir veri merkezi sonsuza kadar sorunsuz çalışmayacak. Önemli olan, büyük bir afet veya uzun süreli kesinti durumunda iş sürekliliğinizi nasıl koruyacağınız. Bu nedenle felaket kurtarma ve ölçeklenebilirlik, veri merkezi seçiminin son ama en kritik kriterlerinden biridir.

Dikkat edilmesi gerekenler:

• Coğrafi olarak ayrık yedek tesis imkanı var mı?
• Replikasyon, yedekleme ve geri dönüş testleri için hangi imkanlar sunuluyor?
• Ani kapasite artışlarını karşılayacak donanım ve enerji rezervi mevcut mu?
• Network tarafında farklı tesise otomatik veya kontrollü failover senaryoları destekleniyor mu?

Biz genellikle üretim yüklerini kademeli olarak taşır ve öncesinde felaket kurtarma senaryolarını test ortamında deneriz. Örneğin bir kısım işi sanal veri merkezi altyapısında çalıştırıp diğer kısmı farklı bir bölgede tutarak gerçeğe yakın tatbikatlar yaparız. Tatbikat sırasında yalnızca sunucunun açılmasını değil, DNS değişikliğini, erişim yetkilerini, gizli bilgileri ve geri dönüş süresini de ölçeriz. Kağıt üzerindeki planların uygulanabilirliği ancak böyle ortaya çıkar.

SLA, sözleşme ve denetim haklarını netleştirmek

Teknik kriterler kadar sözleşme metni ve operasyonel çerçeve de önemlidir. Birçok problem teknik değil, sözleşmesel belirsizliklerden çıkar. Bu yüzden veri merkezi seçimi sürecinde hukuk ekibinizi erken aşamada devreye alın.

Sözleşmede özellikle dikkat etmeniz gereken noktalar:

• Hizmet tanımının yeterince net ve ölçülebilir olması
• Kesinti, veri kaybı ve güvenlik ihlali gibi durumlarda yükümlülükler
• Denetim hakkı ve raporlama sıklığı (loglar, raporlar, denetim sonuçları)
• Sözleşme fesih koşulları ve veri taşıma (data portability) detayları

Ayrıca düzenli denetim ve raporlama mekanizmaları talep edin. Örneğin aylık kesinti raporları, kapasite kullanım raporları ve güvenlik olay özetleri, tesisin gerçek performansını uzun vadede izlemenize yardımcı olur. Veri silme prosedürü, çıkış süresi ve verinin hangi formatta teslim edileceği de sözleşmede açıkça yer almalı.

VPS.TC altyapısıyla uyumlu veri merkezi stratejisi

Bugün pek çok işletme fiziksel sunucu, sanal sunucu ve konteyner altyapılarını hibrit şekilde kullanıyor. VPS.TC üzerinde çalıştırdığınız VPS, LXC konteyner, bulut sunucu veya dedicated sunucu gibi bileşenler, doğru veri merkezi seçimi ile birlikte daha öngörülebilir hale gelir.

Stratejinizi oluştururken şu yaklaşım işinizi kolaylaştırır:

• Kritik çekirdek servisleri, yüksek uptime hedefi olan, iyi tasarlanmış bir Tier III veri merkezi içinde konumlandırın.
• Test, staging ve kısa ömürlü ortamları daha esnek bulut kaynakları üzerinde, gerektiğinde hızlıca yeniden kurabileceğiniz şekilde tasarlayın.
• Yedekleme ve felaket kurtarma senaryolarında farklı bölgedeki bir veri merkezi veya bulut altyapısını devreye alın.

Böylece tek bir tesise bağımlı kalmadan hem maliyet hem de dayanıklılık açısından dengeli bir mimari kurabilirsiniz. Önemli olan tüm bu bileşenleri aynı teknik ve operasyonel standartlara göre yönetmek.

Doğru veri merkezi kararını hızlandırmak için sonraki adımlar

Teoriyi bir kenara bırakıp pratik bir yol haritası çizmek gerekirse önce mevcut iş yüklerinizi envanterleyin, sonra bu yazıda geçen 10 kriteri bir kontrol listesine dönüştürün. Her aday tesis için aynı soruları sorun, aynı metrikleri ölçün ve sonuçları objektif olarak karşılaştırın.

Sonraki aşamada küçük bir pilot ortam kurup gerçek kullanıcı trafiğine benzer bir yükle deneme yapın. Gecikme süreleri, hata oranları, destek yanıt süreleri ve beklenmedik davranışları birkaç hafta boyunca izleyin. Kağıt üzerindeki teklif ile sahadaki performansın uyumlu olup olmadığını bu sayede görebilirsiniz.

Son olarak felaket kurtarma senaryolarınızı güncelleyin ve seçtiğiniz tesisle birlikte uçtan uca test edin. Kabul edilebilir kesinti süresine gerçekten inebiliyor musunuz, yoksa planın bir yerinde manuel bir adıma mı takılıyorsunuz? Bu sorunun cevabını sözleşmeden önce almak, en ucuz teklifi seçmekten çok daha değerlidir.

Sık Sorulan Sorular

Veri merkezi seçimi yaparken ilk dikkat edilmesi gereken kriter nedir?

İlk adım, hangi iş yükünü bu tesise taşıyacağınızı netleştirmektir. Uygulamanın gecikme hassasiyeti, düzenleyici gereksinimleri ve süreklilik ihtiyacı belirlenmeden doğru veri merkezi seçimi yapmak mümkün değildir. Bu analiz sonrasında lokasyon, Tier seviyesi, uptime hedefi ve network altyapısı gibi teknik başlıkları değerlendirmeye başlamalısınız.

Tier III veri merkezi her senaryo için yeterli midir?

Çoğu kurumsal iş yükü için Tier III seviyesi pratikte yeterli bir tasarım hedefidir; çünkü bakım sırasında kritik kapasitenin çalışmaya devam etmesi amaçlanır. Ancak çok kritik finansal sistemler veya sıfıra yakın kesinti toleransı olan uygulamalarda coğrafi yedeklilik, yedek veri merkezi ve düzenli felaket kurtarma testleriyle bu altyapının desteklenmesi gerekir.

Uptime değeri ile SLA arasındaki fark nedir?

Uptime değeri, hizmetin belirli bir dönemde ne kadar süre erişilebilir kaldığını ifade eden teknik bir metriktir. SLA ise bu hedefin hangi koşullarda ve nasıl ölçüleceğini, planlı bakımların nasıl ele alınacağını ve hedef tutmazsa hangi hizmet kredisi veya tazmin mekanizmasının devreye gireceğini tanımlayan sözleşmesel çerçevedir.

Network altyapısının kalitesini taşınmadan önce nasıl test edebilirim?

Farklı ISP’lerden tesise ve tesisten dış hedeflere uzun süreli ping ve mtr ölçümleri alın. Paket kaybını yalnızca ara hoplarda değil hedefte de kontrol edin; jitter, rota değişikliği ve yoğun saatlerdeki gecikme artışını ayrı değerlendirin. Küçük bir pilot VPS veya VDS üzerinde gerçek uygulama trafiğine yakın test yapmak, tek seferlik bir hız testinden daha anlamlıdır.