Veri Merkezi Taşıma Nasıl Yapılır? Sistem Odasından Colocation’a Geçiş Rehberi

Veri Merkezi Taşıma Nedir?

Veri merkezi taşıma, bir kurumun sunucu, depolama, ağ, güvenlik ve uygulama altyapısını mevcut lokasyondan yeni bir çalışma ortamına kontrollü olarak aktarma projesidir. Fiziksel cihazların taşınmasını içerebilir; ancak yeni donanıma veri aktarımı veya sanal iş yüklerinin replikasyonla geçirilmesi de aynı projenin parçası olabilir.

Colocation modelinde kurum, kendi ekipmanını profesyonel bir tesisin güç, soğutma, fiziksel güvenlik ve bağlantı ortamında barındırır. İşletim sistemi, uygulama, veri tabanı ve yedekleme yönetiminin otomatik olarak tesis işletmecisine geçtiği varsayılmamalıdır. Yönetilen hizmet kapsamı ayrıca belirlenir.

Bu ayrım, proje toplantılarında aynı kelimenin farklı anlamlarda kullanılmasını önler. Nakliye firmasının “teslim tamamlandı” kaydı ile iş biriminin “hizmet kullanılabilir” onayı aynı kilometre taşı değildir.

Kurumlar Sistem Odasından Colocation’a Neden Geçer?

Taşıma kararını yalnızca raf alanına bağlamayın. Güç ve soğutma kapasitesi, fiziksel güvenlik, bakım sorumluluğu, bağlantı seçenekleri, büyüme ihtiyacı ve ofisin geleceği birlikte değerlendirilmelidir. Tek UPS’e veya tek bağlantı güzergâhına bağımlılık, yenilenecek bina, konsolidasyon kararı ve işletim yükü bu değerlendirmeyi başlatan nedenler olabilir.

GPU ve yüksek yoğunluklu iş yükleri için yalnızca boş kabinet bulunması yeterli bir kabul kriteri değildir. Hedefte sağlanacak sürekli güç, soğutma yöntemi, kabinet ağırlığı ve ekipman uyumluluğu yazılı olarak netleştirilmelidir. Aynı şekilde iki operatör seçeneğinin bulunması, bağlantıların fiziksel olarak birbirinden bağımsız olduğunu tek başına göstermez.

Karar dosyanıza mevcut durumun sorununu ve hedeflenen iyileştirmeyi ayrı ayrı yazın: “alan yetersiz” yerine ihtiyaç duyulan büyüme kapasitesini; “ağ yavaş” yerine etkilenen uygulamayı ve ölçülecek performansı belirtin. Başlangıç ölçümü olmadan taşımanın beklenen faydayı sağlayıp sağlamadığını değerlendirmek güçleşir.

Henüz barındırma modeline karar vermediyseniz On-Premise, Colocation ve Private Cloud karşılaştırmasını inceleyin. Bu rehber, model seçiminden sonraki uygulama ve geçiş kararlarına odaklanır.

Hangi Veri Merkezi Taşıma Modelleri Vardır?

Taşıma yöntemi cihazın değil, hizmetin gereksinimlerinden başlayarak seçilmelidir. Kesinti toleransı, veri hacmi, uygulama desteği, donanımın durumu, lisanslar ve geri dönüş imkânı birlikte değerlendirilir. Aynı projede farklı yöntemler kullanılabilir.

Fiziksel taşıma ile bulut terminolojisindeki rehost/lift-and-shift ifadesini eş anlamlı kullanmamak gerekir. Rehost, uygulamanın büyük bir değişiklik yapılmadan başka bir çalışma ortamına alınmasını anlatır; fiziksel sunucunun araçla taşınmasını zorunlu kılmaz. Buluta geçiş de her durumda uygulamanın yeniden mimarilenmesi anlamına gelmez.

Eski bir cihazı sırf taşıma maliyeti düşük göründüğü için korumayın; yeni donanımı da otomatik olarak risksiz kabul etmeyin. Her seçenek için kurulum, test ve destek ihtiyacını hesaplayın. Kritik bir uygulama için replikasyon uygun olabilir, fakat bu karar uygulamanın desteklediği yöntemle doğrulanmalıdır.

Kesinti Bütçesi, RPO ve RTO Nasıl Belirlenir?

Taşıma tarihinden önce iş birimleriyle neyin başarı sayılacağını kararlaştırın. İş sürekliliği planlamasında önceliklerin ve kurtarma gereksinimlerinin belirlenmesi, teknik adımların önünde gelir. NIST’in acil durum ve süreklilik planlama çerçevesi de sistemlerin işlevleriyle önceliklerini birlikte değerlendirmeye dayanır.^[1]

Planlı bakım penceresi, RTO ve RPO aynı kavram değildir. RTO, kesinti sonrasında hizmetin geri kazanılması için belirlenen süre hedefiyle; RPO ise verinin geri getirilebilmesi gereken zaman noktasıyla ilgilidir. Taşıma projesindeki kabul koşullarını bu hedeflerle ilişkilendirin, fakat takvimde ayrılan bakım süresini otomatik olarak RTO diye adlandırmayın.^[2][3]

Kesinti bütçesine yalnızca nakliyeyi koymayın. İşlem kabulünün durdurulması, son veri eşitlemesi, kontrollü kapatma, söküm, güvenlik girişleri, kurulum, bağımlılıkların açılışı, uygulama testleri ve iş birimi onayı da bu bütçede yer almalıdır.

Planlama hesabı: En geç geri dönüş kararı = bakım penceresinin bitişi − doğrulanmış geri dönüş süresi − güvenlik payı. Bu hesap, geri dönüş yönteminin o aşamada hâlâ uygulanabilir olduğu varsayımıyla kullanılabilir. Hedefte yeni veri oluşmuşsa ek mutabakat ve eşitleme süreleri gerekir.

Hedeflerin belirlenmesi için RPO ve RTO rehberini kullanabilirsiniz. Planlı geçişte son onaylı işlemlerin eksiksiz taşınmasını hedeflemek, tüm arıza senaryolarında sıfır veri kaybı garantisi vermek değildir.

Veri Merkezi Taşıma Yedi Aşamada Nasıl Planlanır?

Aşağıdaki yedi aşama, hazırlık işlerini taşıma gününden ayıran bir uygulama çerçevesidir. Her aşamanın çıktısı, sorumlusu ve kabul koşulu olmalıdır. Bir kontrolün “planlandı” olması ile tamamlanıp kanıtlanması aynı değildir.

1. Hedef Lokasyonu ve Hizmet Kapsamını Değerlendirin

Hedef tesisi yalnızca tanıtım dokümanıyla değil, kendi yük profilinizle değerlendirin. Kabinet başına kullanılabilir güç, soğutma, ekipman boyutları, erişim prosedürleri, bağlantı teslimleri ve büyüme imkânları birlikte doğrulanmalıdır.

Carrier-neutral veri merkezi yaklaşımı, bağlantı seçeneklerini değerlendirirken önemlidir. Ancak kullanılacak operatör, port, güzergâh ve teslim koşulları ayrıca kararlaştırılmalıdır. Tier sınıflandırmasını incelerken de sunulan belgenin kapsamını ve tesisle ilişkisini kontrol edin; bir sınıflandırmayı uygulamanız için koşulsuz kesintisizlik taahhüdü olarak yorumlamayın.

2. Fiziksel Envanteri ve Uygulama Bağımlılıklarını Çıkarın

Fiziksel envanterde cihaz modeli, seri numarası, kaynak ve hedef kabinet konumu, portlar, güç bağlantıları, destek durumu ve sorumlu kişi bulunmalıdır. Fotoğrafları, etiketleri ve kablolama kayıtlarını aynı cihaz kimliğiyle ilişkilendirin. Yönetim erişim bilgilerini açık envanter dosyalarında değil, yetkili erişimi olan güvenli bir kasada tutun.

Uygulama envanterine servis sahibi, kullanıcılar, veri tabanları, lisans sunucuları, kimlik/DNS/zaman servisleri, API bağlantıları, dosya paylaşımları, zamanlanmış işler ve dış tarafları ekleyin. Gündüz gözlenen trafik tek başına yeterli olmayabilir; ay sonu raporları, gece işleri ve yalnızca kurtarmada kullanılan akışları uygulama sahipleriyle doğrulayın.

Bağımlılık haritası yalnızca bir çizim değildir. Her bağlantı için sahiplik, gerekli erişim ve geçişte hangi ortamın kullanılacağı kayıt altına alınmalıdır. Bağımlı sistemler farklı dalgalara ayrılacaksa iki lokasyon arasındaki gecikme ve erişim koşulları test edilmelidir.

3. Taşıma Yöntemini, Dalgaları ve Provaları Belirleyin

Önce düşük iş etkisine sahip, fakat gerçek ağ ve işletim koşullarını temsil eden bir pilot seçin. Pilotun amacı yalnızca dosya kopyalamayı değil; erişimi, izlemeyi, test akışını ve ekip koordinasyonunu sınamaktır. Başarı kriterleri karşılanmadan aynı yöntemi kritik hizmetlere yaymayın.

“En kritik sistemler her zaman en son taşınır” şeklinde değişmez bir kural yoktur. Ortak kimlik, ağ veya depolama servisleri diğer dalgalar için önceden hazırlanmak zorunda olabilir. Sıralamayı hizmet bağımlılıkları, iş takvimi, paralel çalışma imkânı ve geri dönüş kabiliyeti belirlemelidir.

Her dalga için kapsam, yöntem, pencere, iş birimi temsilcisi, test listesi ve durdurma koşulları tanımlayın. Taşıma sırasında uygulama sürümü, ağ mimarisi ve donanım platformunu aynı anda değiştirmek zorundaysanız bu değişiklikleri ayrı test edin; aksi halde sorun çıktığında nedenini ayırmak zorlaşır.

4. Hedef Ortamı Cihazlar Gelmeden Hazırlayın

Raf, güç dağıtım birimleri, kablolama, ağ cihazları, güvenlik duvarları, yönetim erişimi ve yedekleme hedefleri önceden hazırlanmalıdır. Hat siparişinin açılması yeterli değildir; teslim edilmiş bağlantı üzerinden hedef hizmetlere erişim denenmelidir.

A ve B beslemelerini sadece etiket olarak kontrol etmeyin. Gerçek yük dağılımını ve tek besleme kaybında kalan yolun kapasitesini tesisin yetkili teknik ekibiyle değerlendirin. Tek güç girişli cihazların nasıl besleneceğini ayrıca kararlaştırın. Elektrik bağlantıları ve testleri ilgili tesis prosedürlerine göre yetkili personelce yapılmalıdır.

Üretim ağı sorun yaşadığında kullanılacak bağımsız yönetim erişimini de planlayın. Kurtarma hesabı, çok faktörlü doğrulama, erişim kayıtları ve eskalasyon yöntemi taşınan tek bir sunucuya bağımlı kalmamalıdır. Bunları taşıma öncesi prova sırasında deneyin.

5. Ağ ve Trafik Geçişini Ayrı Bir İş Paketi Olarak Tasarlayın

Kaynak ve hedef adresler, yönlendirme, DNS kayıtları, güvenlik kuralları, VPN’ler ve dış taraf onayları için ayrı bir geçiş matrisi oluşturun. Her değişikliğin uygulayıcısı, doğrulayıcısı ve geri alma adımı belli olsun. Ağ planının ayrıntıları IP, BGP ve DNS geçişi bölümünde yer alıyor.

Aynı gün hem tesis taşıması hem de zorunlu olmayan DNS sağlayıcısı değişikliği yapmak kapsamı büyütür. Birlikte yapılacak değişiklikleri açıkça kaydedin; bağımsız yürütülebilecek işleri farklı pencerelere ayırmayı değerlendirin.

6. Taşıma Gününü Onaylı Operasyon Planıyla Yönetin

Operasyon planı, yani runbook, yalnızca görev listesi değildir. Başlangıç önkoşulu, beklenen süre, sorumlu, doğrulama kanıtı ve durdurma kriteri içermelidir. Tüm ekiplerin erişebildiği tek bir plan sürümü ve karar kaydı kullanın; aynı işi farklı kişilerin çelişen talimatlarla yürütmesini önleyin.

Genel bağımlılık mantığı şudur: tüketen uygulamalar kontrollü durdurulur; ihtiyaç duydukları temel servisler gerekli işlemler tamamlandıktan sonra kapatılır. Açılışta ise önce temel bağımlılıklar, ardından bunları kullanan uygulamalar hazır hale getirilir. Microsoft’un üç katmanlı uygulama örneğinde de veri tabanı, ara katman ve web katmanı bu sırayla başlatılır. Gerçek sıra ürünlerin ve mimarinin gereksinimine göre uyarlanmalıdır.^[4]

Örneğin ağ ve depolama hazır olmadan sanallaştırma platformunu; veri tabanı ve kimlik servisleri doğrulanmadan ERP’yi kullanılabilir saymayın. Sadece sanal makinenin “açık” olması, bağımlılığın uygulama için hazır olduğu anlamına gelmez. Kümeler ve bütünleşik sistemlerde üreticinin onaylı kapatma/açma prosedürünü esas alın.

Fiziksel taşımada seri numarası, cihaz ve port etiketi, teslim alan kişi ve ambalaj kontrolü kayıt altına alınmalıdır. Paketleme, taşıma koşulları ve tekrar devreye alma için ekipmana özgü üretici talimatlarını kullanın. Güçlü bir nakliye planı; güvenli güzergâhı, tesis giriş saatlerini, uygun taşıma ekipmanını ve sigorta kapsamını birlikte ele alır.

7. Doğrulayın, Stabilize Edin ve Eski Ortamı Kontrollü Kapatın

Teknik açılış, hizmet kabulü ve proje kapanışını ayrı kararlar olarak yönetin. Uygulama sahibi ve iş birimi, önceden kararlaştırılan işlemleri test etmelidir. İzleme, yedekleme ve kurtarma bağlantıları doğrulanmadan işletime devir tamamlanmış sayılmamalıdır.

Stabilizasyon süresini rastgele bir gün sayısıyla değil, iş döngülerinizle belirleyin. Gece işi, dönemsel rapor veya dış entegrasyon ancak belirli saatlerde çalışıyorsa bu işlemler için ek doğrulama planlayın. Geçici erişim yetkilerini, bakım sırasında susturulan alarmları ve geçici ağ kurallarını gözden geçirin.

Eski ortamın kapatılması; iş birimi kabulü, geri dönüş ihtiyacının kapanması, yedek/kurtarma doğrulaması ve saklama yükümlülükleriyle ilişkilendirilmelidir. Taşınan cihazların eski lokasyonda artık bulunmadığı fiziksel taşıma senaryosunda, yalnızca eski odanın açık tutulması çalışan bir yedek ortam sağlamaz.

Ağ Geçişi Nasıl Planlanır? IP, BGP, DNS ve Bağlantılar

Fiziksel olarak çalışan bir sunucu, doğru ağ erişimi olmadan kullanılabilir bir hizmet değildir. Ağ geçişini taşıma gecesinde yapılacak birkaç DNS değişikliği olarak değil; iç erişim, dış erişim, çıkış adresleri ve karşı taraf bağımlılıklarını kapsayan ayrı bir proje bileşeni olarak yönetin.

IP Adresleri Korunacak mı, Değişecek mi?

Özel ağ adresleri ile genel internet adreslerini ayrı değerlendirin. İç IP’lerin korunması, mevcut alt ağın yeni lokasyonda aynı şekilde çalışacağını garanti etmez. Ağ geçitleri, VLAN/VRF yapıları, yönlendirme ve iki ortam arasındaki adres çakışmaları incelenmelidir. IP korumak için iki lokasyona yayılmış bir ağ kurulacaksa bunun hata alanı ve işletim etkileri de değerlendirilmelidir.

Sağlayıcıdan tahsis edilmiş genel IP adreslerinin başka bir lokasyonda kullanılabileceğini varsaymayın. Adres kullanım koşulları, mevcut sağlayıcının desteği ve yeni ortamın yönlendirme tasarımı birlikte doğrulanmalıdır. IP değişikliği yalnızca gelen trafiği değil, kurumdan dışarı çıkan trafiğin kimliğini de etkileyebilir.

Bağımsız IP, ASN ve BGP Neyi Değiştirir?

Taşınabilir adres kaynakları ve uygun yönlendirme düzeni, sağlayıcı veya lokasyon değişirken genel IP adreslerini korumaya yardımcı olabilir. Ancak kurumun bir IP bloğu ve ASN’si bulunması tek başına yeterli değildir. Yeni operatörün kabul ettiği önekler, duyuru yetkisi, rota filtreleri, gerekli kayıtlar ve geçiş sırası önceden kararlaştırılmalıdır. Her kurumun kendi ASN’siyle BGP işletmesi de zorunlu değildir; mimari sağlayıcıyla birlikte seçilir.^[5]

RPKI kullanılan bir adres bloğunda ROA, hangi otonom sistemin hangi önekleri duyurmaya yetkili olduğunu tanımlar. Duyuruyu başlatan ASN veya önek uzunluğu değişiyorsa yetkilendirmenin yeni durumla uyumu kontrol edilmelidir. Bu kontrolü geçiş anına bırakmayın.^[6]

Eski ve yeni lokasyondan eş zamanlı duyuru yapılacaksa trafiğin hangi tarafta sonlanacağı, dönüş yolunun nasıl oluşacağı ve durum bilgisi tutan güvenlik cihazlarının davranışı test edilmelidir. “BGP açıldı” kaydı yerine farklı dış ağlardan erişim ve gerçek işlem sonuçlarını kabul kanıtı olarak kullanın.

DNS ve TTL Nasıl Yönetilir?

TTL, DNS yanıtlarının önbellekte kullanılma süresini etkiler. Geçişten hemen önce TTL’yi düşürmek, daha önce eski ve uzun TTL ile önbelleğe alınmış yanıtları geriye dönük değiştirmez. Bu nedenle düşürme işlemini önceden planlayın ve önceki TTL’nin etkisinin sona ermesi için yeterli süre bırakın. AWS’nin DNS geçiş rehberi de TTL düşürme ile eski TTL’nin dolmasını beklemeyi ayrı adımlar olarak ele alır.^[7]

Örneğin önceki TTL 86.400 saniyeyse, bunu geçişten beş dakika önce 300 saniyeye indirmek tüm istemcilerin beş dakika içinde yeni hedefe geçeceği anlamına gelmez. Bu sayılar yalnızca önbellek mantığını açıklayan örnektir; uygun değer, DNS hizmeti ve uygulama gereksinimlerine göre belirlenir.

TTL ayrıca kesin bir küresel geçiş zamanlayıcısı değildir. Yetkili DNS sunucularına erişilemediğinde bazı çözümleyiciler, dayanıklılık amacıyla süresi geçmiş yanıtları belirli koşullarda sunabilir. Bu davranış RFC 8767’de açıklanır.^[8] Bu nedenle eski ve yeni hedefleri, erişim kayıtlarını ve istemci davranışını izleyin; uzun yaşayan uygulama bağlantıları için ayrı geçiş davranışı tanımlayın.

DNS sağlayıcısı veya alan adı yetkilendirmesi de değişecekse NS, delegasyon ve DNSSEC işlemlerini ayrı bir değişiklik planıyla yürütün. Sadece uygulamanın A/AAAA kaydını değiştirmekle aynı işlem değildir. Stabilizasyondan sonra TTL’yi normal işletim politikasına göre yeniden değerlendirin.

Paralel Hat ve Operatör Çeşitliliği Nasıl Kullanılır?

Eski ve yeni lokasyonu geçici olarak bağlamak, dalgalar halinde geçişi destekleyebilir. Bu bağlantının bant genişliğini yalnızca ilk veri kopyası için değil, günlük değişiklikler ve geçici uygulama trafiği için de ölçün. Sürekli artan bir aktarım kuyruğu varsa son eşitleme süresi planlanan kesinti penceresine sığmayabilir.

İki hat için operatör isimlerini değil; bina girişini, güzergâhı, ortak altyapıyı ve sonlandırma noktalarını sorgulayın. Sipariş, fiziksel teslim, cross-connect ve hizmet kabulü tarihlerini ayrı takip edin. Gerçek teslim süresini sağlayıcıdan teyit edin; bütün projeler için sabit bir hafta sayısı varsaymayın.

Internet Exchange ve peering ile Direct Cloud Access farklı bağlantı ihtiyaçlarına karşılık gelir. Bir değişim noktasına erişimi, bütün bulut hizmetlerine otomatik ve hazır özel bağlantı varmış gibi değerlendirmeyin; kullanılacak hizmetin kapsamını ayrıca doğrulayın.

Taşıma Sırasında Veri ve Süreklilik Nasıl Korunur?

Taşıma planlı bir çalışma olsa da veri kaybı, ekipman arızası veya başarısız geçiş ihtimalini ortadan kaldırmaz. Koruma planını, “yedek alındı” kaydıyla değil; yedekten geri dönüş, alternatif çalışma ortamı ve uygulama tutarlılığı kanıtlarıyla oluşturun.

Yedek, Replikasyon ve Son Eşitleme Ayrılmalıdır

Taşıma öncesi yedeğin hangi hizmetleri, yapılandırmaları ve veri zamanını kapsadığını kaydedin. Bir dosyanın geri yüklenmesi bütün ERP’nin çalışır halde kurtarılabildiğini göstermez. Kritik hizmetler için uygun kapsamda geri yükleme ve uygulama testi planlayın.

Üretim cihazları ile tek kurtarma kopyasını aynı taşıma riskine maruz bırakmayın. Yedeklerin, şifre çözme anahtarlarının ve kurtarma erişimlerinin ihtiyaç anında kullanılabilir olduğunu doğrulayın. Replikasyonun yedeklemeyle aynı korumayı sağladığını varsaymayın; hatalı değişikliklerin de hedefe aktarılabileceğini dikkate alın. Temel ayrımlar için yedekleme türleri ve stratejileri rehberini inceleyebilirsiniz.

Değişiklik dondurma ile veri yazımını durdurma farklı işlemlerdir. Yapılandırma değişikliklerini kısıtlamak, kullanıcıların veya entegrasyonların veri üretmesini durdurmaz. Son eşitleme için uygulamanın desteklediği yöntemle yazım, kuyruklar, zamanlanmış işler ve entegrasyonlar kontrol altına alınmalıdır.

Kaynak ve hedefin kontrolsüz biçimde aynı anda üretim verisi kabul etmesini önleyin. Geçiş kaydında “son onaylı işlem”, “eşitleme tamamlandı”, “kaynakta yazım engellendi” ve “hedef üretime açıldı” noktalarını ayrı ayrı tutun. Böylece sorun halinde hangi verinin korunması gerektiği belirginleşir.

Fiziksel Taşıma ile Replikasyonun Geri Dönüş Planı Neden Farklıdır?

Yeni ortamda işlenen siparişler varken yalnızca DNS’yi eski ortama çevirmek güvenli bir geri dönüş planı değildir. Yeni kayıtların nasıl taşınacağı, dış sistemlerde tamamlanan işlemlerin nasıl mutabık hale getirileceği ve karar yetkisi önceden yazılmalıdır. Geri dönüş ile hedefte sorunu gidererek ilerleme seçeneklerini aynı karar dosyasında değerlendirin.

Fiziksel taşımada geri dönüş için cihazların yeniden taşınması gerekiyorsa nakliye, tesis erişimi, raflama ve açılış da süreye dahildir. Bu toplam pencereye sığmıyorsa “eskiye döneriz” yerine test edilmiş bir alternatif kapasite gerekir. DRaaS ve kurtarma mimarisi bu değerlendirmeyi tamamlayabilir; ancak kapasite ve erişimin gerçekten hazır olduğu doğrulanmalıdır.

KVKK, Fiziksel Güvenlik ve Eski Ortamın Kapatılması

Kişisel verilerin korunmasına ilişkin sorumluluk, cihazın farklı bir tesise taşınmasıyla kendiliğinden ortadan kalkmaz. KVKK’nın açıklaması, risklere uygun teknik ve idari tedbirleri ve gerekli denetimleri vurgular.^[10] Projede taşıma ve erişim kayıtları, şifreleme, anahtar yönetimi, hizmet sağlayıcı rolleri ve sözleşme kapsamı hukuk ve bilgi güvenliği ekipleriyle değerlendirilmelidir. Bu rehber hukuki görüş yerine geçmez.

Eski ortamın boşaltılması, bütün verilerin hemen silinmesi anlamına gelmemelidir. Önce saklama gereksinimlerini, devam eden incelemeleri ve geri dönüş ihtiyacını değerlendirin. Kişisel verilerin silinmesi, yok edilmesi veya anonimleştirilmesi koşulları ayrı bir hukuki çerçeveye tabidir.^[11]

Kullanım dışı bırakılacak ortamlarda veri hassasiyetine ve ortam türüne uygun temizleme veya imha yöntemi seçilmelidir. NIST SP 800-88 Rev. 2, medya temizleme programının bu doğrultuda kurulmasına yönelik bir çerçeve sunar.^[9] Proje kayıtlarında cihaz/medya kimliğini, uygulanan yöntemi, doğrulama sonucunu ve yetkili onayını tutun. Eski hat, erişim hesabı, VPN, izleme kaydı ve lisans bağlantılarının kapatılmasını da unutmayın.

Örnek Senaryo: ERP’nin Sistem Odasından Colocation’a Geçişi

Aşağıdaki senaryo, hedefte altyapısı önceden hazırlanmış ve replikasyonu denenmiş kurgusal bir ERP hizmeti için oluşturulmuştur. Mevcut cihazların aynı gece fiziksel olarak taşındığı bir lojistik plan değildir. Süreler sektör ortalaması veya Ixpanse taahhüdü değildir; karar noktalarının nasıl kurulabileceğini göstermek için kullanılmıştır.

Örnekte bakım penceresi 22.00–01.00, yeni üretim verisi oluşmadan önceki doğrulanmış geri dönüş süresi 30 dakika, ayrılan güvenlik payı 15 dakikadır. Buna göre bu geri dönüş yöntemine ilişkin son karar zamanı 00.15’tir. Ancak hedef daha erken yeni işlem kabul ederse eski geri dönüş varsayımı o anda geçerliliğini kaybeder; failback planı devreye girer.

Hizmet 23.40’ta kullanılabilir kabul edilirse, bu örnekte ölçülen kesinti 100 dakikadır. Sanal makinelerin daha erken açılması, kesintiyi o anda sona ermiş saymak için yeterli değildir. Test sırasında gerçek dış işlemler oluşuyorsa bunları da üretim verisi sayın; “henüz kullanıcılara açmadık” gerekçesiyle geri dönüş hesabından çıkarmayın.

Kabul listesinde kullanıcı girişi, örnek sipariş, stok veya finans hareketi, dış entegrasyon, gecikme/hata karşılaştırması, izleme ve yedekleme bulunmalıdır. Tam yedekleme ya da dönemsel bir iş bakım penceresinden uzun sürüyorsa hizmetin açılmasıyla bu kontrolün tamamlanmasını ayrı kilometre taşları olarak kaydedin. Eksik kontrolü tamamlanmış göstermeyin; proje kapanışını gerçek doğrulamaya bağlayın.

Taşıma Projesinde Kim, Hangi İşten Sorumludur?

Colocation sözleşmesi, nakliye, uygulama taşıması ve 7/24 sistem yönetiminin tamamını kendiliğinden kapsamaz. İşe başlamadan önce aşağıdaki örnek rol dağılımını gerçek kişi ve hizmet kapsamlarıyla doldurun. Her işin uygulayıcısı kadar kabul yetkilisi de belirli olsun.

Remote hands gibi yerinde hizmetleri değerlendirirken fiziksel müdahale, yapılandırma değişikliği ve uygulama yönetimini ayırın. Çalışma saatlerini, onay gereksinimini, müdahale kapsamını ve ek ücretleri önceden netleştirin.

Veri Merkezi Taşıma Maliyeti Nasıl Hesaplanır?

Taşıma maliyeti, nakliye bedeli ile aylık kabinet ücretinin toplamından ibaret değildir. Proje bütçesinde tek seferlik geçiş giderleri, geçici çift ortam ve yeni işletim giderleri ayrı gösterilmelidir. Teklifleri karşılaştırırken aynı hizmet kapsamını ve değerlendirme dönemini kullanın.

Karşılaştırmayı yalnızca yeni faturaya bakarak yapmayın. Mevcut sistem odasında gerçekten ortadan kalkacak giderleri, devam edecek personel ve lisans giderlerinden ayırın. Colocation’ın her kurumda otomatik olarak daha ucuz olduğu sonucuna varmayın; büyüme, dayanıklılık ve işletim sorumluluğunu da kararın parçası yapın.

Kesinti riskini değerlendirmek için tek bir genel “saatlik kayıp” rakamı kullanmak yerine, etkilenen iş sürecini ve işlem hacmini iş birimiyle çalışın. Taşıma projesi sırasında donanım yenileme de yapılacaksa bu yatırımın hangi kısmının taşınmadan bağımsız olarak gerekli olduğunu ayrıca gösterin.

Veri Merkezi Taşımada En Sık Hangi Hatalardan Kaçınılmalı?

Aşağıdaki tablo, planı gözden geçirmek için bir risk kontrolüdür; hataların görülme sıklığına ilişkin bir istatistik değildir. Her satırın karşısına kurumunuzdaki kanıtı ve sorumluyu ekleyin.

Taşıma Öncesi Kontrol Listesi

Aşağıdaki maddeler yalnızca işaretlenecek kutular değildir. Her biri için sorumlu kişi, kanıtın bulunduğu yer ve tamamlanma tarihi tutulmalıdır. Kritik bir madde açık kaldığında devam kararını, tanımlanmış risk kabul süreciyle verin.

Veri Merkezi Taşıma Hakkında Sıkça Sorulan Sorular

Veri merkezi taşıma ne kadar sürer?

Tek bir standart süre yoktur. Toplam proje süresi ile hizmet kesintisi ayrı ölçülmelidir. Envanter, donanım ve hat teslimi, uygulama testleri, dış taraf onayları ve iş takvimi süreyi belirler. Bir gecelik geçiş planı, bütün projenin bir gecede hazırlanıp tamamlanacağı anlamına gelmez.

Taşıma sırasında kesinti kaçınılmaz mı?

Fiziksel olarak taşınan cihaz kapatılır; fakat hizmetin kesilip kesilmeyeceği alternatif çalışan kapasiteye ve uygulama mimarisine bağlıdır. Tek kopya üzerinde çalışan bir hizmette fiziksel taşıma kesinti yaratır. Replikasyon veya paralel çalışma kesintiyi azaltabilir; sıfır kesinti ise yöntem, bağımlılıklar ve kabul testleriyle doğrulanmadan vaat edilmemelidir.

Mevcut cihazları taşımak mı, yeni donanım almak mı daha mantıklıdır?

Kararı cihaz bazında değil, hizmetin toplam gereksinimiyle verin. Destek durumu, arıza riski, kapasite, tedarik süresi, lisans ve test maliyeti birlikte değerlendirilmelidir. Hedefte yeni kapasite kurmak paralel test imkânı sağlayabilir; ancak yeni platformun uyumluluğunun ayrıca doğrulanması gerekir.

IP adresleri taşımadan sonra değişir mi?

Adreslerin kullanım koşullarına ve yeni bağlantı mimarisine bağlıdır. Sağlayıcıya bağlı genel IP’ler değişebilir. Taşınabilir kaynaklar olsa bile duyuru yetkisi, rota filtreleri ve operatör kabulü kontrol edilmelidir. İç IP’lerin korunması da ağ geçidi, yönlendirme ve güvenlik kurallarının değişmeyeceği anlamına gelmez.

DNS TTL’yi düşürmek hızlı geçiş için yeterli midir?

Hayır. Daha önce uzun TTL ile önbelleğe alınmış kayıtlar, yeni değer girildiğinde geriye dönük güncellenmez. Düşürme işlemi önceden planlanmalı, önceki TTL dikkate alınmalı ve gerçek erişim izlenmelidir. DNS değişikliği açık uygulama oturumlarını veya bütün istemci davranışlarını tek başına yönetmez.^[7]

RPO hedefi sıfır olan bir uygulama nasıl taşınmalıdır?

Önce “hangi işlemler kaybedilemez?” sorusunun cevabı ve doğrulama yöntemi belirlenmelidir. Son onaylı işlemlerin hedefte bulunması, uygulamanın desteklediği eşitleme yöntemi ve kontrollü yazım geçişiyle kanıtlanmalıdır. Hedefte yeni işlemler başladıktan sonraki geri dönüş ayrıca tasarlanmalıdır. Bir ürün seçmek tek başına sıfır veri kaybını kanıtlamaz.

Colocation’a geçince donanımın sahibi ve yöneticisi kim olur?

Kurumun kendi donanımıyla aldığı colocation hizmetinde mülkiyet kurumda kalır; kiralama veya başka ticari modeller farklıdır. Tesis altyapısı ile işletim sistemi, ağ, uygulama ve veri yönetimi ayrılmalıdır. Sağlayıcının üstleneceği yönetim işleri sözleşmede açıkça tanımlanmalıdır.

Colocation’a taşınmak buluta geçmekle aynı şey midir?

Hayır. Colocation, ekipmanın barındırıldığı tesis ve altyapı modelidir. Buluta geçişte kaynak tüketimi, hizmetler ve işletim modeli de değişebilir. Aynı projede bazı hizmetler buluta, bazıları colocation’a alınabilir; her grup için bağımlılık, bağlantı ve sorumluluk planı hazırlanmalıdır.

Taşıma sonrası yedekleme ve felaket kurtarma nasıl etkilenir?

Birincil ortamın yeri, bağlantılar, erişim izinleri ve replikasyon yönleri değişebilir. Yeni ortamda yedekleme işini ve geri yüklemeyi doğrulayın; kurtarma planındaki adresleri, sıralamayı ve kapasiteyi güncelleyin. Geçici hedefin yeni üretim ortamı olması, o ortamın ayrıca korunması ihtiyacını ortadan kaldırmaz.

Kritik sistemler her zaman en son mu taşınmalıdır?

Hayır. Düşük riskli bir pilotla başlamak yararlı bir proje yaklaşımıdır; fakat dalga sırasını bağımlılıklar ve iş gereksinimleri belirler. Kimlik veya ağ gibi ortak servislerin önceden hazır olması gerekebilir. Önemli olan kritik hizmetin hangi aşamada yeterince test edilmiş ve geri döndürülebilir olduğudur.

Veri merkezi taşıma KVKK açısından nasıl değerlendirilmelidir?

Veri güvenliği, yetkili erişim, hizmet sağlayıcı rolleri, sözleşmeler ve saklama koşulları birlikte değerlendirilmelidir. Colocation seçimi tek başına otomatik uyumluluk sağlamaz. Kuruma ve veri türüne uygun teknik/idari tedbirler hukuk ve bilgi güvenliği ekipleriyle belirlenmelidir.^[10]

Taşıma projesi ne zaman tamamlanmış sayılır?

İş hizmetleri kabul edildiğinde, veri tutarlılığı ve erişim doğrulandığında, izleme/yedekleme/kurtarma görevleri yeni ortamda çalıştığında ve işletim sorumlulukları devredildiğinde kapanış değerlendirilebilir. Eski ortamın kapatılması ve varsa medya temizleme kayıtları da tamamlanmalıdır. Cihaz teslimi veya başarılı açılış tek başına proje kapanışı değildir.

Ixpanse ile Sistem Odasından Colocation’a Geçiş

Ixpanse’in Ankara’daki carrier-neutral veri merkezi yaklaşımı ve colocation hizmetleri, kurumların barındırma ve bağlantı ihtiyaçlarını birlikte değerlendirmesine yönelik bir temel sunar. Ankara IX kapsamındaki bağlantı seçenekleri de lokasyonlar ve bulut ortamları arasındaki gereksinimlerle birlikte ele alınabilir.

Geçiş sonrasında veri koruma ve yönetilen altyapı hizmetleri ihtiyaçlarını ayrıca değerlendirin. Kabinet/güç kapasitesi, bağlantı teslimi, yerinde müdahale, nakliye, uygulama geçişi ve işletim görevleri aynı kapsam gibi varsayılmamalı; projeye özel teklif ve sorumluluk matrisiyle netleştirilmelidir.

Sistem odanızdan colocation’a geçişi; kapasite, bağlantı, kesinti hedefleri ve operasyon sorumluluklarıyla birlikte değerlendirmek için Ixpanse uzman ekibiyle projenizi görüşün. Görüşmeye mevcut cihaz/uygulama listesi, büyüme beklentisi, bağlantı ihtiyaçları ve kabul edilebilir kesinti bilgisiyle başlamak kapsamın belirlenmesini kolaylaştırır.

Sonuç: Cihazları Değil, Çalışan Hizmeti Taşıyın

Başarılı veri merkezi taşıma, ekipmanların yeni kabinete ulaşmasıyla değil; iş hizmetlerinin doğrulanmış biçimde yeni ortamda çalışmasıyla ölçülür. Envanter, bağımlılıklar, hedef kapasite, ağ geçişi, veri tutarlılığı ve geri dönüş aynı planın parçalarıdır.

Taşıma yöntemini hizmet bazında seçin. Planlı kesinti penceresini hazırlık süresinden ve kurtarma hedeflerinden ayırın. Her karar kapısını kanıta bağlayın; yeni üretim verisi oluştuktan sonra geri dönüş varsayımlarının değiştiğini unutmayın. İşletime devir ve eski ortamın kontrollü kapanışı tamamlanmadan projeyi bitmiş saymayın.

Başlangıç sorusu “Cihazları hangi gece taşıyalım?” değil, “Hangi hizmet hangi bağımlılıklara sahip, hangi koşullarda kullanılabilir sayılacak ve plan çalışmazsa işimizi nasıl sürdüreceğiz?” olmalıdır.

İlgili Ixpanse Rehberleri

Karar aşamasında altyapı modellerini karşılaştırın; bağlantı tasarımında carrier-neutral veri merkezlerini; süreklilik hedeflerinde RPO ve RTO’yu; koruma planında yedekleme stratejilerini ve DRaaS yaklaşımını birlikte inceleyin.

Teknik Kaynaklar

Aşağıdaki kaynaklar, ilgili bölümlerdeki kavram ve teknik ayrımları destekler. Runbook, sorumluluk, maliyet ve kontrol tabloları bu rehber için hazırlanmış örnek çerçevelerdir; bir standardın zorunlu şablonu veya belirli bir kurumun gerçek proje kaydı değildir.

1. NIST SP 800-34 Rev. 1 — Contingency Planning Guide for Federal Information Systems. Süreklilik planlama yaklaşımı.
2. NIST CSRC Glossary — Recovery Time Objective. RTO kavramı.
3. NIST CSRC Glossary — Recovery Point Objective. RPO kavramı.
4. Microsoft Learn — About Recovery Plans. Uygulama bağımlılıkları ve başlatma sırası.
5. IETF RFC 7454 — BGP Operations and Security. BGP işletimi ve yönlendirme filtreleri.
6. IETF RFC 9582 — A Profile for Route Origin Authorizations. Önek ve origin-AS yetkilendirmesi.
7. AWS Route 53 — Making Route 53 the DNS Service for a Domain That’s in Use. TTL düşürme ve eski TTL’nin etkisini bekleme. Bu rehberin DNS ilkesi için kullanılmıştır; colocation geçişinde DNS sağlayıcısının değiştirilmesi zorunlu değildir.
8. IETF RFC 8767 — Serving Stale Data to Improve DNS Resiliency. İstisnai durumlarda süresi geçmiş DNS verisinin sunulması.
9. NIST SP 800-88 Rev. 2 — Guidelines for Media Sanitization. Medya temizleme programı ve veri hassasiyeti.
10. Kişisel Verileri Koruma Kurumu — Veri Güvenliğine İlişkin Yükümlülükler. Risklere uygun teknik/idari tedbirler ve denetim.
11. Kişisel Verileri Koruma Kurumu — Kişisel Verilerin Silinmesi, Yok Edilmesi veya Anonim Hale Getirilmesi. Veri saklama ve imha değerlendirmesi.