Sunucuyu Buluta Taşıma: Fiziksel Sunucudan Cloud Sunucuya Geçiş Rehberi

Sunucuyu buluta taşıma kararı çoğu kurumda donanımın üretici destek süresinin dolması, kabin ve enerji maliyetlerinin artması ya da kapasite ihtiyacının hızla değişmesiyle gündeme gelir. Buluta geçiş doğru planlandığında iş yükleri daha esnek, yedeklemesi ve izlenmesi daha kolay bir altyapıya taşınır. Plansız yapıldığında ise uygulama kesintileri, performans sorunları ve beklenmeyen maliyetler ortaya çıkar.

Bu rehberin amacı, fiziksel veya şirket içi sanal sunuculardan cloud sunucuya geçişin hangi adımlarla yapılacağını sade biçimde anlatmaktır. İşletmelerin beklentisi; verinin eksiksiz taşınması, kesintinin planlanan pencereyle sınırlı kalması ve sorun çıkarsa geri dönülebilmesidir. Yazıda yöntem seçimi, envanter çalışması, veri aktarımı, test ve geçiş günü ayrı başlıklarla ele alınıyor.

Sunucuyu Buluta Taşıma Nedir, Hangi Durumlarda Gerekir?

Sunucuyu buluta taşıma; şirket içinde veya bir kabinde çalışan sunucuların işletim sistemi, uygulama ve verisiyle birlikte bir bulut altyapısına aktarılmasıdır. NIST’in SP 800-145 bulut bilişim tanımı, bulutu paylaşılan ve yapılandırılabilir kaynaklara ağ üzerinden, ihtiyaç anında ve asgari yönetim çabasıyla erişim sağlayan bir model olarak tanımlar. Cloud sunucu, bu modelin altyapı hizmeti (IaaS) katmanında yer alır.

Bulut göçü (cloud migration) her iş yükü için aynı aciliyette değildir. Kurumların bu kararı genellikle şu durumlarda verdiği görülür:

• Donanım ömrünün dolması: Yenileme yatırımı yerine kapasitenin hizmet olarak alınması.
• Değişken kapasite ihtiyacı: Dönemsel yük artışlarında CPU, RAM ve disk kaynağının hızla artırılması.
• Yedekleme ve felaket kurtarma eksikliği: Tek lokasyonda duran sunucuların riskinin azaltılması.
• Operasyon yükü: Donanım arızası, enerji ve soğutma gibi konuların iç ekipten alınması.
• Dağınık altyapı: Farklı şubelerdeki sunucuların tek bir yönetilebilir ortamda toplanması.

Fiziksel Sunucudan Cloud Sunucuya Geçiş: Hangi Yöntemler Var?

Her uygulama aynı yöntemle taşınmaz. Yöntem seçimi, uygulamanın yaşına, lisans yapısına ve kurumun ne kadar değişikliğe hazır olduğuna bağlıdır. Sektörde yaygın kullanılan yaklaşımlar üç ana başlıkta toplanır.

Olduğu gibi taşıma (rehost / lift-and-shift): Sunucu, işletim sistemi ve uygulamasıyla birlikte değiştirilmeden sanal makine olarak buluta aktarılır. En hızlı yöntemdir ve fiziksel sunucudan cloud sunucuya geçişte en sık tercih edilen yoldur. Platform uyarlaması (replatform): Uygulama korunur, ancak işletim sistemi sürümü, veritabanı veya depolama katmanı güncellenir. Yeniden tasarım (refactor): Uygulama bulut yeteneklerinden tam yararlanacak şekilde yeniden kurgulanır; en fazla kazanç ve en fazla eforu bu yöntem getirir.

Pratikte çoğu kurum önce olduğu gibi taşıma ile başlar, iş yükleri bulutta dengelendikten sonra seçili uygulamaları uyarlar. Bu sıra, sunucuyu buluta taşıma sürecinde riski ve kesintiyi en aza indirir.

Taşıma Öncesi Envanter ve Bağımlılık Analizi

Başarılı bir buluta geçişin önemli kısmı, taşıma başlamadan yapılan envanter çalışmasında belirlenir. Hangi sunucunun hangi uygulamayı çalıştırdığı, hangi veritabanına bağlandığı ve hangi portlarla konuştuğu bilinmeden yapılan taşıma, geçiş gecesi sürprizlere yol açar. Envanterde en az şu bilgiler toplanmalıdır:

1. Sunucu profili: İşletim sistemi ve sürümü, CPU, RAM, disk boyutu ve gerçek kullanım oranları.
2. Uygulama ve servisler: Çalışan yazılımlar, lisans türleri ve lisansın donanıma bağlı olup olmadığı.
3. Bağımlılıklar: Veritabanı, Active Directory, dosya paylaşımı, e-posta ve dış API bağlantıları.
4. Ağ yapısı: IP adresleri, DNS kayıtları, firewall kuralları, VPN ve şube bağlantıları.
5. Kesinti toleransı: Her uygulama için kabul edilebilir kesinti süresi ve veri kaybı toleransı.

Microsoft’un Cloud Adoption Framework göç planlama rehberi de doğrudan bağımlı bileşenlerin birlikte taşınmasını ve bağımlılık kritikliğinden emin olunamayan durumlarda bileşenlerin aynı grupta tutulmasını önerir. Bu yaklaşım üreticiden bağımsız olarak her bulut göçü projesine uygulanabilir.

Sunucu Taşıma Planı: 7 Adımda Buluta Geçiş

Envanter tamamlandıktan sonra sunucu taşıma planı yazıya dökülür. Plan; sıralamayı, zaman çizelgesini, sorumluları ve geri dönüş koşullarını içermelidir. Kurumsal projelerde genel kabul gören akış şöyledir:

1. Hedef mimari: Cloud sunucu boyutları, ağ segmentleri, firewall kuralları ve yedekleme politikası belirlenir.
2. Dalga planı: Sunucular bağımlılık gruplarına ayrılır; düşük riskli ve test ortamları ilk dalgada yer alır.
3. İlk veri kopyası: Veri, üretim çalışırken hedef ortama aktarılır ve değişiklikler replikasyonla eşitlenir.
4. Test: Uygulama bulutta izole bir ağda açılır; fonksiyon, performans ve entegrasyon testleri yapılır.
5. Geçiş penceresi: Son delta aktarılır, kaynak sunucu durdurulur, DNS ve IP yönlendirmeleri güncellenir.
6. Doğrulama: Kullanıcı kabul testi yapılır, izleme ve yedekleme işlerinin çalıştığı kontrol edilir.
7. Kaynağın kapatılması: Belirlenen gözlem süresinden sonra eski sunucu güvenli biçimde devreden çıkarılır.

Her adımın sonunda bir “devam / dur” kontrol noktası bulunmalıdır. Sunucuyu buluta taşıma projelerinde en pahalı hata, test aşaması atlanarak doğrudan geçiş penceresine girilmesidir.

Kesintili mi, Kesintisiz mi? Veri Aktarım Yöntemleri

Taşıma yöntemi kadar verinin nasıl aktarılacağı da kesinti süresini belirler. Kritik olmayan sistemler planlı bir bakım penceresinde taşınabilirken, müşteriye dönük uygulamalar için sürekli replikasyonla neredeyse kesintisiz geçiş tercih edilir.

Aktarım süresini tahmin etmek için veri boyutu ile bağlantı kapasitesi birlikte hesaplanır. Yüksek hacimli veride ilk kopyanın günler öncesinden başlatılması, geçiş gecesinde yalnızca son değişikliklerin aktarılmasını sağlar. Aktarım sırasında trafiğin şifreli bir tünel üzerinden taşınması ve kaynak ile hedef arasındaki bütünlük kontrolü de planın parçası olmalıdır.

Hangi yöntemin seçileceği, envanterde belirlenen kesinti toleransına göre her sunucu için ayrı ayrı kararlaştırılır. Veeam tabanlı replikasyon, sanal ve fiziksel iş yüklerinin hedef ortama sürekli eşitlenmesini sağlayan yaygın yöntemlerden biridir.

Genel Uygulama ve Doğru Yaklaşım

Birçok kurumda genel uygulama, fiziksel sunucunun kaynak değerlerini birebir kopyalayıp bulutta aynı boyutta bir sanal makine açmaktır. Oysa şirket içi sunucular çoğu zaman gerçek ihtiyacın çok üzerinde kaynakla satın alınmıştır. Doğru yaklaşım, gerçek kullanım verisine göre boyutlandırma yapmak ve kaynağı ihtiyaç arttıkça büyütmektir.

Sunucuyu buluta taşıma sonrasında da aynı mantık geçerlidir. Taşıma bitti diye proje kapanmaz; ilk haftalardaki performans ve maliyet verisiyle kaynaklar yeniden ayarlanır, yedekleme ve izleme politikaları bulut ortamına göre güncellenir. Genel uygulamada yedekleme “sonra bakılır” diye bırakılırken, doğru yaklaşımda ilk günden devrededir. Taşınan iş yükleri için boyutlandırma seçenekleri cloud sunucu kiralama sayfasında yer alıyor.

Türkiye Lokasyonu, KVKK ve Veri Yerleşimi

Türkiye’de faaliyet gösteren işletmeler için buluta geçiş kararında verinin nerede duracağı teknik bir detay değil, uyum konusudur. 6698 sayılı Kişisel Verilerin Korunması Kanunu, kişisel verilerin yurt dışına aktarımını belirli şartlara bağlar. Türkiye lokasyonlu bir bulut altyapısı tercih edildiğinde, yurt dışı aktarım kaynaklı yükümlülüklerin önemli kısmı gündeme gelmez.

MAV Cloud altyapısı İstanbul’daki Equinix veri merkezinde, VMware sanallaştırma katmanı üzerinde çalışır. Bu yapı, şirket içinde VMware kullanan kurumların sanal makinelerini tanıdık bir platforma taşımasını da kolaylaştırır. Bu bölümdeki bilgiler genel niteliktedir ve hukuki danışmanlık yerine geçmez; kuruma özel değerlendirme için hukuk danışmanıyla çalışılmalıdır.

Sık Yapılan Hatalar ve Doğru Yöntem

Bulut göçü projelerindeki sorunların çoğu teknolojiden değil, eksik hazırlıktan kaynaklanır. Sahada en sık karşılaşılan hatalar ve doğru yöntemler şunlardır:

• Bağımlılıkları atlamak: Uygulama taşınır ama bağlandığı lisans sunucusu veya paylaşım klasörü unutulur. Doğru yöntem, taşıma öncesi bağımlılık haritasıdır.
• Geri dönüş planı yazmamak: Sorun çıktığında kaynağa nasıl dönüleceği belirsiz kalır. Geri dönüş koşulları ve adımları önceden yazılmalı ve test edilmelidir.
• Bant genişliğini hesaplamamak: Terabaytlarca verinin aktarım süresi tahmin edilmeden geçiş tarihi verilir. İlk kopya önceden alınmalı, geçişte yalnızca fark aktarılmalıdır.
• DNS TTL değerlerini düşürmemek: Kayıt değişikliği saatlerce yayılmaz. TTL, geçişten önce kısaltılmalıdır.
• Lisansları kontrol etmemek: Donanıma bağlı lisanslar yeni ortamda çalışmayabilir. Üretici koşulları taşıma öncesi doğrulanmalıdır.
• Taşıma sonrası güvenliği ertelemek: Firewall kuralları, yedekleme ve izleme ilk günden devrede olmalıdır.

Bir diğer sık hata, taşıma sonrası performans karşılaştırmasının yapılmamasıdır. Geçiş öncesinde uygulamanın yanıt süreleri ve kaynak kullanımı ölçülürse, bulutta ortaya çıkan farklar somut veriyle değerlendirilebilir ve kaynak ayarı tahmine değil ölçüme dayanır.

Bu hataların ortak çözümü, sunucuyu buluta taşıma işini tek seferlik bir kopyalama değil, planlı bir proje olarak yönetmektir.

Güvenilir Bir Bulut Göçü İçin Aranacak Standartlar

Taşımayı bir hizmet sağlayıcıyla yürütmek, iç ekibin günlük operasyonu sürdürürken projeyi ayrıca taşımasını önler. Ancak sağlayıcı seçilirken altyapının yanı sıra süreç, sertifika ve destek modeli de değerlendirilmelidir.

MAV Cloud; ISO/IEC 27001, ISO/IEC 27701, ISO 22301, ISO 9001 ve ISO/IEC 20000 sertifikalarıyla çalışır. Altyapı Türkiye lokasyonlu Equinix veri merkezinde, VMware ve Veeam teknolojileri üzerinde kuruludur. SLA kapsamında bulut sunucular için aylık %99,9 erişilebilirlik hedefi tanımlıdır ve 7/24 uzman destek sunulur.

Bir teklifi değerlendirirken şu sorular yol gösterir: Envanter ve bağımlılık analizini kim yapıyor, test ortamı sağlanıyor mu, geçiş penceresinde kim nöbette, geri dönüş koşulları yazılı mı? Taşıma sürecinin adım adım nasıl yürütüldüğü bulut taşıma hizmetleri sayfasında ayrıntılı olarak anlatılıyor.

Sıkça Sorulan Sorular

Sunucuyu buluta taşıma ne kadar sürer?

Süre; sunucu sayısına, veri boyutuna, bağlantı kapasitesine ve uygulama bağımlılıklarına göre değişir. Envanter ve test aşamaları planlandıktan sonra, sürekli replikasyonla asıl geçiş penceresi kısa tutulabilir.

Buluta geçiş sırasında kesinti yaşanır mı?

Kritik uygulamalar sürekli replikasyonla taşındığında kesinti, son farkın aktarıldığı ve yönlendirmenin değiştiği kısa bir pencereyle sınırlı kalır. Kritik olmayan sistemler ise planlı bakım penceresinde taşınabilir.

Fiziksel sunucudan cloud sunucuya geçişte veriler kaybolur mu?

Doğru planlanmış bir taşımada taşıma öncesi tam yedek alınır, veri replikasyonla eşitlenir ve geçiş sonrası doğrulama yapılır. Kaynak sunucu, gözlem süresi bitene kadar kapatılmaz.

Lift-and-shift nedir?

Lift-and-shift (rehost), sunucunun işletim sistemi ve uygulamasıyla birlikte değiştirilmeden buluta sanal makine olarak aktarılmasıdır. En hızlı ve en düşük riskli bulut göçü yöntemidir.

Sunucu taşıma planında neler yer almalı?

Plan; sunucu envanterini, bağımlılık gruplarını, taşıma sırasını, veri aktarım yöntemini, test adımlarını, geçiş penceresini, sorumluları ve geri dönüş koşullarını içermelidir.

Mevcut lisanslar bulutta kullanılabilir mi?

Lisans koşulları üreticiye ve lisans türüne göre değişir. Bazı lisanslar donanıma bağlıdır ve yeni ortamda yeniden etkinleştirme gerektirir; taşıma öncesi üretici koşulları kontrol edilmelidir.

Veriler Türkiye’de mi kalır?

MAV Cloud altyapısı İstanbul’daki Equinix veri merkezinde bulunur; taşınan sunucular ve veriler Türkiye lokasyonunda barındırılır. Bu durum KVKK kapsamındaki yurt dışı aktarım değerlendirmelerini sadeleştirir.

Taşıma sonrası sunucuların yönetimini kim yapar?

Kurum tercih ederse yönetimi kendi ekibiyle sürdürür; tercih ederse işletim sistemi, yedekleme ve izleme görevleri yönetilen hizmet kapsamında sağlayıcıya devredilebilir.

Konuyu yeni araştıran BT yöneticileri için ilk adım, mevcut sunucuların ve üzerlerinde çalışan uygulamaların basit bir listesini çıkarmaktır. Hangi yöntemin seçileceğine karar veremeyen kurumlar, önce test ve geliştirme sunucularıyla küçük bir pilot taşıma yapabilir. Harekete geçmeye hazır ekipler ise ücretsiz ön analizle sunucuyu buluta taşıma projesinin kapsamını ve sırasını netleştirebilir.