Veri Merkezi Taşıma: Kabinetin Yeni ISP Tesisine Geçişi

Bu projeyi Sistem Kuşu kurulmadan önce, kurumun BT ekibinde çalıştığım dönemde ben yürüttüm.

ISP sözleşmesinin yeni bir operatöre geçmesiyle birlikte, kurumun tüm sistem altyapısını eski ISP’nin veri merkezinden yeni ISP’nin veri merkezine fiziksel olarak taşıdık.

Sorun

Türkiye’de kurumsal veri merkezlerinin büyük kısmı, barındığı ISP’nin kendi tesislerinde konumlanır. Kurumun ISP’sini değiştirme kararı bu yüzden sadece bir ağ değişikliği değildi: sunucu, storage, switch ve firewall’un bulunduğu tüm kabinetin fiziksel olarak yeni bir veri merkezine taşınması gerekiyordu.

Kesinti, kurumun hiçbir personelini etkilemeyecek şekilde planlanmak zorundaydı.

Neden bu yol?

Kesintiyi kısaltmanın yolu, taşınacak parça sayısını azaltmaktan geçmiyordu; taşınmayacak parçayı önceden hazırlamaktan geçiyordu. Bu yüzden riski ikiye böldük.

Firewall’u taşımak yerine yenisini önceden yeni kabinete kurup tüm kurallarıyla yapılandırdık ve yeni operatörün WAN bacağına bağladık. Böylece geçiş gecesinde firewall bir taşıma kalemi değil, hazır bekleyen bir bileşen oldu. Eski cihazı da atmadık: olası bir sorunda anında devreye alınmak üzere araçta yedek olarak taşındı.

Aynı mantığın ikinci ayağı sunucu tarafındaydı. Hipervizör ISO’sunun her zaman anahtarlıkta taşınan bir USB bellekte hazır durması, taşıma gecesine özel alınmış bir önlem değildi; sonradan tam da o gece işe yaradı.

Nasıl kurduk?

Taşımadan önce eski ISP tarafında birkaç kez port mapping testi yaparak yeni ortamda her bağlantının sorunsuz çalışacağından emin olduk. Kesintiyi bir Cumartesi gecesi 00:00-04:00 saatlerine aldık; bu çalışmayı haftalar öncesinden tüm kuruma duyurduğumuz için kimsenin mesaisi o saate kalmadı.

Taşıma gecesi şu adımları izledik:

• Sunucu, storage ve switch’i kapatıp araçla yeni veri merkezine taşıdık, yerinde yeniden kurduk.
• Firewall tarafında geçiş, önceden hazırlanmış yeni cihazla yapıldı; yedek cihaza ihtiyaç duyulmadı.
• Sanal makineler storage üzerinde durduğu için sunucu tarafı ayağa kalkar kalkmaz erişilebilir hale geldi.

Tek sorun sunucu tarafında çıktı: hipervizör taşıma sırasında bozuldu. Muhtemel sebebi, hipervizörün yıllar önce sunucunun dahili SD kartına kurulmuş olmasıydı; SD kartlar sınırlı yazma ömrüne sahiptir ve üretici bültenlerinde de belgelendiği gibi, uzun kullanım sonrası özellikle bir kapatma-açma döngüsünde önyükleme bölümü bozulabilir. USB’deki ISO ile sıfırdan kurulum yapıldı ve sanal makineler veri kaybı olmadan yeniden erişilebilir hale geldi. Taşıma, planlanan 4 saatlik pencerede tamamlandı.

Devreye alındıktan sonra

Taşıma planlanan pencerede tamamlandı ve veri kaybı yaşanmadı. Kurumun personeli Pazartesi sabahı, sistemlerin gece başka bir şehre taşındığını fark etmeden çalışmaya başladı.

Bu olay aynı zamanda mimarinin neden böyle kurulduğunu gösteriyor: sunucu (compute) ile storage katmanları kasıtlı olarak ayrı tutuluyor. Sanal makineler sunucunun kendi diskinde değil ayrı bir storage üzerinde yaşadığı için, sunucu tarafındaki bir arıza veriye hiç dokunmadı; sunucuyu yeniden kurup storage’a bağlamak yeterli oldu. Bu ayrım bir tercih değil, felaket kurtarmanın temel taşlarından biridir: sunucu her an değiştirilebilir, kaybolan veri değil.

Aynı disiplinin bir adım ötesi, yedeklerin bulutta da ayrı bir kopyasının tutulmasıdır; storage’ın kendisi bir felakette zarar görseydi, kurumun elinde coğrafi olarak ayrı bir kopya olurdu. Tek bir katman hiçbir zaman yeterli değildir.

Aynı kurumda birkaç ay önce tamamladığımız MPLS ve ISP geçişi projesini ayrı bir vaka çalışmasında anlatıyoruz; bu taşıma o dönüşümün son adımıydı. Firewall’un neden ve nasıl yükseltildiğini firewall donanım yükseltmesi vaka çalışmasında, veri merkezi migrasyon süreçleri hakkında daha fazla bilgi için veri merkezi migration rehberimize göz atabilirsiniz. Aynı işi kendi kurumunuz için planlıyorsanız kapsam ve süreç sunucu ve kabinet taşıma sayfasında yazılı.