Bir sunucuyu yerel sanallaştırma ortamından buluta taşımak teknik olarak birkaç komuttan ibaret görünebilir. Gerçek hayatta ise geçiş gecesi en çok baş ağrıtan sorun işlemci veya bellek yetersizliği değildir. Çoğu zaman kodun içine elle yazılmış bir yerel IP adresi, eski bir dosya paylaşımı veya unutulmuş bir Active Directory sorgusu işi durdurur. Sunucuyu taşımadan önce envanteri çıkarmak ve bağımlılıkları haritalamak bu yüzden ilk adımdır.
Bu yazı bulut sunucu altyapı sayfasını destekler. Satış veya paket listesi sunmaz. Yerel sanal makine ile bulut mimarisi arasındaki ayrımı sanal sunucu ile bulut sunucu farkları yazısında bulabilirsiniz.
Hızlı Özet
Taşıma planı yaparken sanal makine listesi tek başına bir envanter sayılmaz. Gerçek envanter sunucunun konuştuğu veritabanlarını, kullandığı ağ portlarını, kimlik doğrulama kaynaklarını ve harici servisleri kapsar. Bağımlılık haritası çıkarılmadan taşınan bir uygulama, yerel ağda kalan veritabanına her işlemde uzak ağ üzerinden erişmeye çalışır ve ciddi gecikme üretir.
İşletim sistemi katmanındaki sorumluluk sınırları için IaaS sorumluluk paylaşım modeli yazısını inceleyebilirsiniz. Leon-X altyapı sahibi değildir. Geçiş öncesi analiz, bağımlılık keşfi ve mimari planlama adımlarını yürütür.
İçindekiler
- Statik Envanter ile Dinamik Bağımlılık Ayrımı
- Görünmeyen ve Sessiz Bağımlılıklar
- Ağ ve Port Seviyesinde Trafik Analizi
- Geçiş Dalgalarını Gruplama Mantığı
- Yaygın Hatalar
- Kontrol Listesi
- Leon-X ile Sonraki Adım
- Sık Sorulan Sorular
- Sonuç
- Kaynaklar
Kaynak Pexels, bilgisayar başında çalışan ekip.
Statik Envanter ile Dinamik Bağımlılık Ayrımı
Birçok IT ekibi buluta geçiş hazırlığına sanallaştırma konsolunu açıp sanal makinelerin işlemci, bellek ve disk miktarlarını bir tabloya yazarak başlar. Bu liste statik envanterdir. Donanım boyutlandırması için fikir verir ancak geçiş anında uygulamanın çalışıp çalışmayacağını söylemez.
Dinamik bağımlılık ise o makinenin canlı ortamda kiminle konuştuğunu gösterir. Web sunucusu hangi veritabanı kümesine bağlanıyor, arka plandaki fatura servisi hangi yerel dosya sunucusundan veri okuyor veya kimlik doğrulaması için hangi etki alanı denetleyicisine gidiyor sorularının yanıtı dinamik haritada yer alır. Bu bağlantıları bilmeden yapılan taşıma işlemi, parçalanmış ve çalışmayan bir sistem bırakır.
Görünmeyen ve Sessiz Bağımlılıklar
Kurumsal ortamlarda sistemler yıllar içinde katman katman büyür. Dokümantasyonda yazmayan pek çok gizli bağ canlı sistemin içinde sessizce çalışır.
İlk sessiz bağ kod içine veya yapılandırma dosyalarına elle yazılmış sabit IP adresleridir. İsim çözme servisi yerine IP ile konuşan bileşenler, buluta taşındığında yeni bir IP bloğuna geçer ve bağlantı anında kopar.
İkinci kritik bağ yerel dosya paylaşımları ve zamanlanmış görevlerdir. Gece yarısı çalışan bir veri aktarım betiği, yerel ağdaki bir klasörü arayıp bulamadığında sessizce başarısız olabilir.
Üçüncü grup ise lisanslama ve çevre birimi bağımlılıklarıdır. Fiziksel donanımın seri numarasına veya yerel bir USB anahtarına kilitli çalışan lisanslar sanallaştırma katmanı değiştiğinde geçersiz kalır.
Ağ ve Port Seviyesinde Trafik Analizi
Bağımlılıkları yalnızca uygulama sahiplerinin hafızasına güvenerek çıkarmak her zaman risk taşır. En güvenilir yöntem ağ seviyesinde aktif soketleri ve trafiği dinlemektir.
Sunucu üzerindeki aktif TCP bağlantılarını inceleyerek gelen ve giden portlar listelenir. Örneğin bir uygulama sunucusunun yerel ağdaki bir muhasebe veritabanına yüzlerce anlık sorgu attığı bu analizde görülür. Ağ gecikmesine duyarlı olan bu iki sistem aynı anda taşınmazsa kullanıcılar sistemin aşırı yavaşladığından şikayet etmeye başlar.
Altyapıyı operasyonel olarak nasıl okumanız gerektiğini IaaS modelini operasyon gözüyle anlamak yazısında ayrıca ele aldık.
Geçiş Dalgalarını Gruplama Mantığı
Tüm sunucuları aynı hafta sonu buluta taşımaya çalışmak başarısızlık ihtimalini artırır. Doğru yaklaşım bağımlılık haritasına bakarak geçiş dalgaları oluşturmaktır.
İlk dalgaya dış dünya ile bağı az olan, gecikmeye toleranslı ve yedekli çalışan sistemler yerleştirilir. Test ortamları veya izole web sunucuları bu aşama için uygundur.
İkinci dalgada birbirine sıkı sıkıya bağlı olan uygulama ve veritabanı çiftleri tek bir grup olarak ele alınır. Bu iki katman buluta aynı bakım penceresinde taşınarak aradaki ağ gecikmesi sıfırlanır.
Üçüncü dalgaya ise merkezi kimlik, ortak depolama ve en kritik kurumsal iş yükleri bırakılır. Bu aşamaya gelindiğinde geçiş prosedürü ilk dalgalarda doğrulanmış olur.
Yaygın Hatalar
Envanter ve bağımlılık çıkarmadan buluta geçmeye çalışan ekiplerin sık düştüğü hatalar şunlardır.
Yalnızca sanal makine kaynaklarına bakıp uygulama ilişkilerini göz ardı etmek ilk büyük hatadır.
Veritabanını yerelde bırakıp uygulama sunucusunu buluta taşımak ve ağ gecikmesinin fark edilmeyeceğini düşünmek ikinci hatadır.
Yedekleme ajanlarının, izleme yazılımlarının ve antivirüs bağlantılarının bulut ağında nasıl çalışacağını planlamamak operasyonu aksatır.
Taşıma gecesinde test edilecek işlev listesini önceden yazmamak ve doğrulamayı rastgele yapmak hataların geç fark edilmesine yol açar.
Kontrol Listesi
- Tüm sunucuların donanım ve işletim sistemi özellikleri listelendi.
- Sunucuların konuştuğu veritabanı ve harici servis portları çıkarıldı.
- Kod veya konfigürasyon dosyalarındaki sabit yerel IP adresleri temizlendi.
- Yerel dosya paylaşımları ve zamanlanmış aktarım görevleri haritaya eklendi.
- Kimlik doğrulama ve etki alanı denetleyicisi bağımlılıkları belirlendi.
- Birlikte taşınması gereken sunucular geçiş dalgalarına ayrıldı.
- Altyapı gereksinimleri netleştikten sonra bulut sunucu mimari planı başlatıldı.
Leon-X ile Sonraki Adım
Leon-X geçiş öncesinde mevcut envanterinizi ve sistem bağımlılıklarınızı analiz eder. İş yüklerinizin kesintiye uğramadan buluta aktarılması için dalga planını ve risk matrisini hazırlar. Yönetilen IT hizmetleri kapsamında geçiş sonrasındaki bakım, güvenlik ve izleme operasyonlarını da koordine eder. Altyapı sahibi değildir, doğru çözümü seçip yönetir. Başlamak için iletişime geçin.
Sık Sorulan Sorular
Bağımlılık haritası çıkarmak ne kadar sürer?
Sistem sayısına ve ortamın karmaşıklığına göre değişir. Küçük ve derli toplu yapılarda birkaç gün içinde tamamlanabilirken, çok katmanlı kurumsal ortamlarda trafik dinleme ve analiz süreci birkaç hafta sürebilir.
Mevcut sanal makineler doğrudan kopyalanabilir mi?
Teknik olarak kopyalanabilir ancak bağımlılıklar kontrol edilmeden taşınan makineler yeni ağ düzeninde erişim hataları verir.
Veritabanı ile uygulama sunucusu ayrı ayrı taşınabilir mi?
Aralarındaki sorgu trafiği çok az ise taşınabilir. Fakat yoğun veri alışverişi yapan sistemler farklı ağlarda kaldığında gecikme performansı olumsuz etkiler.
Envanter analizi bulut faturasını etkiler mi?
Doğrudan etkiler. Kullanılmayan veya gereksiz çalışan sistemler bu analiz sırasında tespit edilip elenir ve boş yere kaynak kiralanmasının önüne geçilir.
Sonuç
Buluta geçiş bir donanım kiralama işleminden çok daha fazlasıdır. Başarılı bir geçiş, mevcut altyapının kılcal damarlarını bilmekten geçer. Envanterini eksiksiz çıkaran ve bağımlılıklarını doğru haritalayan kurumlar öngörülebilir ve güvenli bir bulut geçişi yaşar. Altyapı değerlendirmesi için bulut sunucu sayfasını inceleyebilirsiniz.
