Veri Merkezi Migration: Taşıma Planı ve Kesinti Penceresi

Veri merkezi migration, bir kurumun sunucu, storage ve ağ altyapısının bulunduğu yerden başka bir yere taşınmasıdır: başka bir veri merkezine, başka bir donanıma ya da buluta. İşin zor kısmı taşımanın kendisi değildir. Kamyon, kablo ve raf birkaç saatlik bir iştir. Zor olan, o birkaç saatin planlanan birkaç saat olarak kalmasını sağlamaktır.

Bunu düşünmenin en doğal yolu ev taşımaktır, ve bu makale boyunca aynı taşınmanın içinde kalacağız. Herkes taşınmıştır ve herkes aynı şeyi bilir: taşınma günü yaşananların çoğu, o gün alınan kararlardan değil, önceki haftalarda alınan ya da alınmayan kararlardan doğar. Kutuları etiketlemediyseniz yeni evde hangi kutuda ne olduğunu bilemezsiniz. Eski evin elektriğini erken kapattıysanız, unuttuğunuz bir şeyi almaya gittiğinizde karanlıkta ararsınız. Ve buzdolabını boşaltmadan kamyona koyduysanız, bunu yolda öğrenirsiniz.

Aşağıda önce taşımanın ne zaman ve neden gündeme geldiğini göreceğiz, sonra keşif ve envanterin neden en pahalı aşama olduğunu konuşacağız. Ardından kesinti penceresini, her adımın geri dönüşünü planlamayı, taşıma gecesinin sırasını ve mimarinin işi nasıl kolaylaştırdığını ele alıp buluta geçişin nerede farklılaştığıyla kapatacağız.

Anlatılan sıra teorik değil: 4 saatlik planlı bir gece kesintisiyle tamamlanan veri merkezi taşıma vaka çalışmamızda fiilen izlenen sıradır. Bu makale BT sistem yönetimi hizmetimizin altyapı taşıma koluna karşılık gelir. Taşımayı sizin için nasıl planlayıp yürüttüğümüzü veri merkezi ve kabinet taşıma sayfamızda anlattık.

Veri Merkezi Migration Ne Zaman Gündeme Gelir?

Taşıma kararı çoğu zaman BT’nin kendi isteğiyle değil, dışarıdan gelen bir değişiklikle başlar. Kurumların altyapılarını keyfi olarak taşıdığı pek görülmez; taşınmayı tetikleyen belirli sebepler vardır ve her biri farklı bir aciliyet taşır.

• Servis sağlayıcı değişikliği. Türkiye’de kurumsal veri merkezlerinin önemli bir kısmı, hizmet aldığı operatörün kendi tesisinde barınır. Bu durumda operatör değiştirmek yalnızca bir sözleşme kararı değildir: kabinetin fiziksel olarak yeni sağlayıcının tesisine taşınması gerekir. Kendi vakamızda taşımayı doğuran sebep tam olarak buydu.
• Sözleşme veya kira bitişi. Barındırma sözleşmesinin yenilenmemesi, tarihi baştan belli bir taşıma demektir. Bu, planlaması en rahat senaryodur ve tam da bu yüzden en çok ertelenendir.
• Donanım yaşam döngüsü. Sunucu ve storage üreticinin destek kapsamından çıktığında taşınan şey mekan değil, iş yükleridir.
• Konsolidasyon. Birden fazla lokasyondaki dağınık sunucuların tek bir sanallaştırma platformunda birleştirilmesi. Burada taşıma bir yer değiştirme değil, bir mimari değişikliğidir.
• Buluta geçiş. İş yüklerinin kısmen ya da tamamen bulut sağlayıcıya taşınması. Kamyon yoktur ama plan disiplini aynıdır.

Bu ayrımın pratik değeri şurada: taşımanın sebebi, hangi riskin baskın olduğunu da söyler. Sözleşme bitişinden doğan bir taşımada tarih pazarlığa kapalıdır, dolayısıyla asıl risk zamandır. Donanım yaşlanmasından doğan bir taşımada asıl risk, taşınan donanımın yolda ya da açılışta arıza vermesidir. Konsolidasyonda ise risk teknik değil kapasitedir: yeni platform gerçekten yetiyor mu?

Keşif ve Envanter: Neyin Var Olduğunu Bilmek

Taşımanın en pahalı aşaması keşiftir ve pahalı olmasının sebebi süresi değil, atlandığında bedelinin taşıma gecesi ödenmesidir. Çıkarılması gereken şey bir cihaz listesi değil, bir bağımlılık haritasıdır.

Ev taşımasında da mesele eşyanın kendisi değildir. Kaç koltuğunuz olduğunu zaten biliyorsunuz. Bilmediğiniz şey, çamaşır makinesinin bağlantı hortumunun yeni evdeki musluğa uyup uymadığıdır. Sürpriz her zaman eşyada değil, bağlantı noktasındadır.

Keşifte çıkarılması gerekenler:

1. Fiziksel envanter. Kabinetteki her cihaz, marka bağımsız olarak: kaç ünite yer kaplıyor, kaç güç kaynağı var, hangi kabloyla nereye bağlı. Kabinetin taşınmadan önce fotoğraflanması, sonradan hatırlanmaya çalışılan onlarca ayrıntıyı kurtarır.
2. Servis envanteri. Hangi sunucuda hangi uygulama çalışıyor ve o uygulamayı kim kullanıyor. Yıllar içinde kurulup unutulmuş servisler bu aşamada ortaya çıkar; bazıları hâlâ kullanılmaktadır.
3. Bağımlılık haritası. Hangi servis hangisine bağımlı. Bu, taşıma sırasını belirleyen tek girdidir: kimlik ve isim çözümleme katmanı ayağa kalkmadan üzerine oturan hiçbir uygulama çalışmaz.
4. Ağ ve güvenlik yapılandırması. Yönlendirme kuralları, güvenlik duvarı kuralları, port yönlendirmeleri ve dışarıya açılan servisler. Bu kalem neredeyse her zaman belgelenenden büyüktür.
5. Dışa bağlı taahhütler. Sabit IP adresine bağlı entegrasyonlar, üçüncü tarafların whitelist’leri, alan adı kayıtları ve donanıma bağlanmış lisanslar.

Son madde en sinsi olanıdır. Bir uygulamanın lisansı sunucunun donanım kimliğine bağlanmışsa, o sunucu sanal makineye çevrildiğinde ya da anakartı değiştiğinde lisans geçersiz olur. Bunu taşıma gecesi öğrenmek, o gece çözülebilecek bir sorun değildir; üreticinin mesai saatini beklersiniz.

Burada ev taşıma benzetmesi kopuyor ve nerede koptuğunu söylemek gerekiyor: taşındığınız evden unuttuğunuz bir şeyi almak için hafta sonu geri dönebilirsiniz. Veri merkezinde dönemezsiniz. Kabinet boşaltıldığı ve sözleşme kapandığı anda o alan başkasına verilir, bağlantı düşer. Envanterin eksiksiz olması “iyi olurdu” değil, tek şansınız olduğu için zorunludur.

Kesinti Penceresi: Ne Zaman, Ne Kadar ve Kime Duyurulur?

Kesinti penceresi, hizmetin planlı olarak durduğu ve taşımanın yapıldığı zaman aralığıdır. Doğru seçilmiş bir pencere, aynı kesintiyi bir krizden rutin bir bakıma dönüştürür.

Pencereyi belirleyen üç soru sırayla cevaplanır:

1. Kurumun en az etkilendiği saat hangisi? Bu, sektöre göre değişir ve tahmin edilmez, ölçülür. Çok lokasyonlu bir kurumda hafta sonu gecesi doğru cevaptır; sürekli üretim yapan bir tesiste böyle bir saat hiç olmayabilir.
2. İşin gerçekçi süresi ne kadar? Buraya taşıma süresi değil, taşıma artı doğrulama artı olası bir geri dönüş süresi yazılır. Pencere yalnızca iyimser senaryoya göre kurulursa, ilk aksaklıkta pencere aşılır.
3. Geri dönüş kararı saat kaçta verilecek? Bu, en sık atlanan ve en çok işe yarayan maddedir. Pencerenin içinde, “bu saate kadar bitmediyse eski duruma dönüyoruz” diyen bir saat olmalıdır.

Kendi taşımamızda pencere bir cumartesi gecesi 00:00-04:00 olarak belirlendi ve iş bu dört saatlik pencerede tamamlandı. Ama asıl işi yapan şey pencerenin kendisi değildi: çalışma haftalar öncesinden tüm kuruma duyurulmuştu. Bunun sonucu şuydu, kimsenin mesaisi o saate kalmadı ve taşıma gecesi hiç kimse “sistem neden kapalı” diye aramadı.

Duyurunun erken yapılması teknik bir adım gibi görünmez ama işin yarısıdır. Taşınacağınızı komşuya ve apartman yönetimine önceden söylemekle söylememek arasındaki fark, asansörün o saatte boş olup olmamasıdır.

Riski Dağıtmak: Her Adımın Bir Geri Dönüşü Olmalı

Bu makalenin taşıyıcı fikri burada: iyi bir taşıma planı taşımayı planlamaz, arızayı planlar. Taşıma zaten olacaktır. Planın kalitesi, bir şey ters gittiğinde kaybedilenin saatler mi yoksa dakikalar mı olduğuyla ölçülür.

İki somut örnek, ikisi de kendi taşımamızdan.

Birincisi güvenlik duvarı tarafındaydı ve risk baştan ikiye bölündü. Yeni cihaz, taşımadan önce hedef kabinete kurulmuş, tüm kurallarıyla yapılandırılmış ve yeni sağlayıcının hattına bağlanmıştı. Yani geçiş gecesinde yapılacak iş “yeni cihazı kurmak” değil, sadece devreye almaktı. Bununla da yetinilmedi: eski cihaz da araçta yedek olarak taşındı, bir sorun çıkarsa anında geri dönülebilsin diye. Geçiş sorunsuz tamamlandı ve yedeğe hiç ihtiyaç duyulmadı. Yedeğin kullanılmamış olması onu gereksiz yapmaz; o yedek, o gece alınan kararların rahat alınabilmesinin sebebiydi.

İkincisi bir USB bellekti. Sunucunun hipervizör kurulum dosyası, anahtarlıkta taşınan bir bellekte hazır bekliyordu. Bu, taşıma gecesi işe yaradı ve aşağıdaki bölümün konusu.

Buradan çıkan planlama kalıbı şudur:

Tablodaki her satırın ortak yanı, hazırlığın taşımadan önce yapılmış olmasıdır. Taşıma gecesinde yapılabilecek tek şey, önceden hazırlanmış bir seçeneği kullanmaktır.

Taşıma Gecesi: Sıra, Sürpriz ve Doğrulama

Taşıma gecesinin akışı bağımlılık haritasının tersten okunmasıdır: en alttaki katman ilk kurulur, en üstteki uygulama en son doğrulanır. Ağ ayağa kalkmadan storage görünmez, storage görünmeden sanal makineler açılmaz, kimlik katmanı çalışmadan kullanıcı oturum açamaz.

Ve bir sürpriz çıkar. Bizim taşımamızda sürpriz sunucu tarafında çıktı: hipervizör taşıma sırasında bozuldu. Sebebi bir hata değildi, donanımın bilinen bir davranışıydı. Hipervizör yıllar önce sunucunun dahili hafıza kartına kurulmuştu; bu tür ortamların yazma ömrü sınırlıdır ve üreticilerin kendi teknik bültenlerinde de belgelendiği gibi, uzun süre çalıştıktan sonra özellikle bir kapatma-açma döngüsünde önyükleme bölümü bozulabilir. Yıllardır kesintisiz çalışan bir sunucu, ilk kez kapatılıp açıldığında bunu gösterir.

Burada iki ders var ve ikisi de taşımaya özgü değil, taşımada görünür hale geliyor:

• Yıllardır kapatılmamış donanım, kapatıldığında test edilmiş sayılmaz. Çalışıyor olması, yeniden açılacağının kanıtı değildir. Taşımadan önce planlı bir kapatma-açma denemesi yapmak, sürprizi taşıma gecesinden alıp normal bir mesai gününe taşır.
• Önyükleme ortamı bir yedekleme kalemidir. Verinizi yedeklersiniz de, sistemi ayağa kaldıran kurulum ortamını yedeklemek çoğu zaman kimsenin aklına gelmez.

O gece çözüm anahtarlıktaki USB bellekti: hipervizör doğrudan oradan yeniden kuruldu. Kaybedilen süre saatler değil dakikalar oldu, çünkü çözüm zaten cepteydi.

Doğrulama tarafında ise tek bir kural yeterli: “açıldı” ile “çalışıyor” aynı şey değildir. Bir sanal makinenin açılmış olması uygulamanın hizmet verdiğini göstermez. Doğrulama listesi taşımadan önce yazılır ve her madde bir kişi tarafından fiilen denenir: kullanıcı oturum açabiliyor mu, dosyaya erişilebiliyor mu, dışarıdan gelen entegrasyon çalışıyor mu, yedekleme işi başlıyor mu? Bu liste yoksa ekip sistemleri “çalışıyor” sayar ve eksik olan şey pazartesi sabahı kullanıcı tarafından bulunur.

Mimari Taşımayı Nasıl Kolaylaştırır? Compute ve Storage Ayrımı

Yukarıdaki arıza bir felakete dönüşmedi ve sebebi o geceki refleksler değil, yıllar önce verilmiş bir mimari karardı. Sanal makineler sunucunun kendi diskinde değil, ayrı bir storage ünitesinde tutuluyordu. Bu yüzden hipervizör tamamen gittiğinde bile veri hiç etkilenmedi: hipervizör yeniden kurulup storage’a bağlandığı anda bütün sanal makineler olduğu gibi geri geldi.

Ev taşımasında bunun karşılığı, kıymetli eşyayı mobilyanın içinde taşımamaktır. Dolap yolda çizilebilir, hatta kırılabilir; bu can sıkıcıdır ama telafi edilebilir. İçindeki evrak kırılan dolapla birlikte gitmişse durum başkadır. Bu yüzden değerli olan şey, taşıyan şeyden ayrı seyahat eder.

Ayrımın teknik karşılığı nettir: sunucu değiştirilebilir bir bileşendir, veri değildir. Sunucu tarafında yaşanan bir donanım ya da yazılım arızası veriye dokunmaz; sunucuyu değiştirip storage’a yeniden bağlamak yeterli olur. Bu yalnızca taşımada değil, günlük arızalarda da işe yarar ve felaket kurtarmanın temel taşlarından biridir.

Ama tek katman hiçbir zaman yeterli değildir. Compute ve storage ayrımı sunucu tarafındaki arızalara karşı korur; storage’ın kendisi bir yangında, hırsızlıkta ya da bir taşıma kazasında zarar görürse o ayrım işe yaramaz. İkinci katman, yedeğin coğrafi olarak ayrı bir yerde de durmasıdır. Katmanların nasıl kurgulandığını veri yedekleme ve felaket kurtarma rehberimizde ele alıyoruz.

Konsolidasyon ve P2V: Yer Değil Mimari Değiştiren Taşıma

Her taşıma bir yer değiştirme değildir. Bazılarında donanım hiç kıpırdamaz; değişen şey iş yüklerinin nerede ve nasıl çalıştığıdır. Konsolidasyon ve P2V bu gruba girer ve kendi riskleri vardır.

Ev taşımasındaki karşılığı, taşınmadan yapılan tadilattır. Kamyon yoktur, adres aynıdır, ama duvar kalkar ve iki oda birleşir. Kimse eşyayı sokağa çıkarmaz; buna rağmen bir hafta boyunca evde yaşamak zorlaşır.

Konsolidasyon: Yirmi Sunucuyu Kaça İndirmek

Konsolidasyon, dağınık duran fiziksel sunucuların tek bir sanallaştırma platformunda birleştirilmesidir. Kazancı nettir: daha az donanım, daha az bakım sözleşmesi, daha az elektrik ve soğutma, daha az raf alanı.

Ama işin zor kısmı teknik değil kapasite hesabıdır ve burada yapılan hata pahalıya patlar. Yirmi sunucunun özelliklerini toplayıp aynı kapasitede tek bir platform almak, ilk bakışta doğru görünür ve yanlıştır. İki sebeple:

• Toplama yanlış sayıyı toplar. Sunucuların kağıt üstündeki özellikleri değil, ölçülmüş gerçek kullanımları toplanır. Yüzde on beş doluluk ile çalışan yirmi sunucunun gerçek yükü, yirmi sunucu kapasitesi değildir.
• Tepe yükler aynı ana denk gelmez, ama bazıları gelir. Ay sonu raporu ile bordro işlemi aynı akşam çalışıyorsa, o iki iş yükü aynı platformda birbirini bekler. Ortalamalar toplanmaz, zirveler çakışır.

Buna bir de yukarıda konuştuğumuz risk yoğunlaşması eklenir: yirmi ayrı arıza noktası tek platforma indiğinde, o platformun arızası artık yirmi sistemi birden durdurur. Bu yüzden konsolidasyon kararının ayrılmaz parçası, bir sunucu kaybedildiğinde kalanların yükü kaldıracağı bir kapasite planıdır. Hesabın nasıl yapıldığını hypervisor ve sanallaştırma rehberimizde ele alıyoruz.

P2V: Fiziksel Makineyi Sanala Çevirmek

P2V (Physical to Virtual), çalışan bir fiziksel sunucunun diskini olduğu gibi bir sanal makineye kopyalamaktır. Cazibesi açık: uygulamaları yeniden kurmanız, yapılandırmayı yeniden yapmanız gerekmez.

Mekanizması şöyle işler. Fiziksel makineye bir ajan kurulur ve makine çalışmaya devam ederken diski blok blok hedef sanal makineye kopyalanır. Kopyalama sürerken kaynak makinede değişen bloklar işaretlenir. Sonunda kısa bir kesinti alınır, değişen son bloklar aktarılır ve sanal makine açılır. Böylece uzun kopyalama süresi kesinti penceresinin dışında kalır.

İşin sürprizi açılışta çıkar, çünkü işletim sistemi bambaşka bir donanımda uyanır. Disk denetleyicisi, ağ kartı ve anakart artık başka bir şeydir. Bunun doğurduğu tipik sorunlar:

1. Makine açılmaz. İşletim sisteminde yeni sanal disk denetleyicisinin sürücüsü yoksa önyükleme diski bulunamaz. Bu, P2V’nin bir numaralı arızasıdır ve önceden sürücü hazırlığıyla önlenir.
2. Lisanslar yeniden etkinleştirme ister. Donanım kimliğine bağlı lisanslar makineyi yeni bir cihaz sayar.
3. Ağ yapılandırması kaybolur. Yeni ağ kartı yeni bir donanım adresiyle gelir; adres rezervasyonuna ya da donanım adresine bağlanmış her şey kopar.
4. Eski donanımın kalıntıları taşınır. Fiziksel sunucunun disk denetleyicisi yönetim yazılımı, sensör ajanları ve üretici araçları sanal makinede işe yaramaz, ama açılışta hâlâ çalışmayı dener ve hata üretir.

Buradan çıkan dürüst tavsiye, çoğu danışmanın söylemediği tavsiyedir: mümkünse P2V yapmayın, temiz kurun. Bir sunucuyu sıfırdan kurup üzerindeki rolü ve veriyi taşımak, çoğu durumda P2V’den daha uzun sürer ama arkasında yıllarca birikmiş yapılandırma kalıntısı bırakmaz. P2V, kaynak kodu ya da kurulum bilgisi kaybolmuş, üreticisi ortada olmayan eski uygulamalar için doğru araçtır; hâlâ kurulabilen bir sistem için ise kolay yolun bedeli sonradan ödenir. P2V ve V2V geçişini bir proje olarak nasıl yürüttüğümüzü sanallaştırma geçişi sayfamızda yazdık.

Buluta Geçiş: Aynı Disiplin, Farklı Sınırlar

Buluta geçişte kamyon yoktur, ama plan disiplini aynen geçerlidir; değişen şey risklerin nereye kaydığıdır. Fiziksel taşımada risk donanımda ve zamandaydı; bulut geçişinde risk bant genişliği, maliyet ve bağımlılıklardadır.

Farklılaşan noktalar şunlardır:

• Veri hacmi bir zaman sorunudur. Terabaytlarca veriyi hat üzerinden taşımak günler alabilir ve bu süre kesinti penceresine sığmaz. Bu yüzden bulut geçişleri genellikle önce çoğaltma, sonra kısa bir son senkronizasyon şeklinde kurgulanır.
• Maliyet modeli tersine döner. Şirket içi altyapıda maliyet önden ödenir ve sonrası nispeten sabittir; bulutta maliyet kullanım süresince akar. Özellikle veriyi dışarı çıkarmanın ayrıca ücretlendirildiği kalem, hesaba baştan katılmazsa sonradan sürpriz olur.
• Her iş yükü gitmez. Donanıma bağlı lisanslar, özel donanım gerektiren sistemler ve çok katı gecikme toleransı olan uygulamalar şirket içinde kalır. Doğru soru “buluta geçelim mi?” değil, “hangi iş yükü nereye?” olmalıdır.
• Kimlik katmanı önce gider. Kullanıcıların ve yetkilerin nasıl yönetileceği çözülmeden üzerine taşınan her uygulama, ikinci bir kimlik adası üretir.

Sahadaki dürüst değerlendirme şu: KOBİ ölçeğinde tam bulut geçişi çoğu zaman en ucuz seçenek değildir ve maliyet gerekçesiyle savunulduğunda genellikle yanlış hesaplanmıştır. Bulutun gerçek kazancı maliyet değil esnekliktir: kapasiteyi hızla artırıp azaltabilmek, ikinci bir lokasyona ihtiyaç duymadan coğrafi yedeklilik kurabilmek ve donanım yaşam döngüsü yönetiminden çıkmak. Bu kazançlar gerçek ve değerlidir; ama “sunucuya para vermeyelim” cümlesinden farklı bir cümledir.

Sonuç: Taşınmayı Değil Arızayı Planlamak

Veri merkezi taşıma, iyi yapıldığında sıkıcı bir gecedir. Bu makalede taşımayı neyin tetiklediğini, keşfin neden en pahalı aşama olduğunu, kesinti penceresinin üç sorusunu, her adıma bir geri dönüş koymayı, taşıma gecesinin sırasını ve mimarinin işi nasıl kurtardığını ele aldık.

Geriye tek bir cümle kalacaksa şu olsun: taşıma gecesini kısaltan şey o gece yapılanlar değil, önceki haftalarda yapılanlardır. Dört saatlik bir pencerede biten bir taşımanın arkasında, haftalar önce yapılmış testler, önceden kurulmuş bir güvenlik duvarı, yazılı bir bağımlılık sırası ve anahtarlıkta taşınan bir USB bellek vardır.

Sahada gördüğüm başarısız taşımaların ortak yanı da bu: hiçbiri taşıma gecesinde başarısız olmadı, hepsi hazırlık aşamasında başarısız olmuştu; yalnızca bunu taşıma gecesinde öğrendiler. Envanteri eksik çıkarılmış bir altyapı, kamyona bindiğinde eksikliğini haber vermez. Bu hazırlığı bir taşıma projesinde kalem kalem nasıl yürüttüğümüzü sunucu ve kabinet taşıma sayfamızda anlattık.

Yazan İlker Pehlivan

BT Danışmanı | Ağ, Sistem ve Güvenlik Yönetimi

İlker Pehlivan, karmaşık BT altyapılarını ölçeklenebilir ve güvenli sistemlere dönüştürür. Buradaki rehberleri kendi laboratuvarında kurup ölçerek yazar.

LinkedIn