Sunucu taşıma planı; envanter, uygulama bağımlılıkları, hedef ortam hazırlığı, deneme, geçiş ve kabul kontrollerinden oluşur. Bakım zamanı ve geri dönüş kararı uygulamanın ihtiyacına göre önceden belirlenmelidir.
Sunucunun yeni ortamda açılması, taşımanın tamamlandığını göstermez. Kullanıcı doğru veriye erişebilmeli, entegrasyonlar tek kez çalışmalı ve yeni ortam düzenli olarak yedeklenmelidir. Teknik taşıma planı bu nedenle veri kopyalamanın yanında bağımlılıkları, erişim yönlendirmesini, iş kabulünü ve geri dönüş kararını kapsar.
Buradaki adımlar bir uygulama taşımasının planlama çerçevesidir. Ürün, işletim sistemi ve veritabanı sürümü için desteklenen yöntem ayrıca seçilir. Aynı anda hem sürüm yükseltmek, hem ağ adreslerini değiştirmek hem de yeni platforma geçmek, sorunun hangi değişiklikten kaynaklandığını ayırmayı zorlaştırabilir.
1. Envanterden bağımlılık grafiğine geçin
Uygulamanın kullandığı veritabanı, dosya deposu, kimlik sistemi, DNS, zaman servisi ve dış entegrasyonlar listelenir. Sabit IP kullanan istemciler, IP izin listeleri, sertifikalar, servis hesapları ve zamanlanmış görevler de bu envantere girer. Yalnız etkileşimli kullanıcı girişi test edilirse geceleri çalışan bir veri aktarımı gözden kaçabilir.
Her bağımlılık için yön, protokol, kimlik doğrulama yöntemi ve sahibi kaydedilir. Uygulama A’nın B’ye erişmesi gerektiğini bilmek yetmez; bu erişimin yeni ağdan nasıl kurulacağı belirlenir. Lisansın donanıma, makine kimliğine veya belirli bir sunucu adına bağlı olup olmadığı üreticiyle doğrulanır.
2. Kopyalama yöntemini veri tutarlılığına göre seçin
Çalışan bir sanal makinenin görüntüsünü almak, uygulamanın bütün işlemlerini tutarlı bir noktada yakaladığını garanti etmez. Crash-consistent kopya, beklenmedik kapanma sonrası toparlanmaya benzer bir durumu temsil edebilir. Application-consistent yöntem ise desteklenen uygulama ve veritabanı mekanizmalarıyla tutarlı veri noktası oluşturmaya çalışır. Kullanılan yöntemin gerçekten hangi uygulamayı desteklediği kontrol edilir.
Veritabanı replikasyonu veya günlük aktarımı kullanılıyorsa başlangıç kopyasıyla sonraki değişikliklerin birbirini tamamlaması gerekir. PostgreSQL’in PITR dokümantasyonu, temel yedek ile gereken WAL kayıtlarının birlikte bulunmasının önemini açıklar. Uygulamanın dosya deposu ayrıysa veritabanıyla dosyaların hangi veri noktasında eşleştirileceği de belirlenmelidir.
| Yöntem | Planlama avantajı | Kritik kontrol |
|---|---|---|
| Kapatarak kopyalama | Yazım durdurularak daha açık bir geçiş noktası | Kopyalama ve doğrulama süresinin bakım penceresine sığması |
| Ön eşitleme + son geçiş | İlk büyük aktarımın kesinti öncesinde yapılması | Son değişikliklerin tamamlanması ve yazımın tek tarafta kalması |
| Uygulama/veritabanı geçişi | Ürünün desteklediği veri aktarım mekanizması | Sürüm, eklenti, dosya ve entegrasyon uyumu |
Tablonun tamamı için yana kaydırabilirsiniz.
3. Aktarım süresini ve değişim hızını hesaplayın
İlk veri kopyasının aktarım süresi, taşınacak veri miktarı ile etkin aktarım hızı üzerinden tahmin edilir. Fiziksel hat hızı; protokol yükü, disk performansı, şifreleme ve diğer trafik nedeniyle gerçek veri hızından yüksek olabilir. Tahmin, küçük bir pilot kopyayla ölçülmeli ve yoğun saat koşulları ayrıca değerlendirilmelidir.
Ondalık birimlerle 1 TB verinin 100 Mbit/s bağlantıda teorik aktarımı yaklaşık 22,2 saattir. Bu alt sınır hesabı ek yükleri içermez. Kaynak saniyede 20 MB yeni veri üretirken bağlantı teorik olarak ancak 12,5 MB/s taşıyabiliyorsa, sıkıştırma gibi etkenler hesaba katılmadan bu hatla sürekli eşitlemenin yetişmesi beklenemez.
Bakım penceresine ilk kopyanın tamamı değil, seçilen yönteme göre son değişiklik aktarımı, servislerin başlatılması ve kabul kontrolleri sığmalıdır. “Son kopya küçük olur” varsayımı ölçümle doğrulanır. Kaynak veri değişimi yükseldiğinde veya hedef depolama yavaşladığında son eşitleme süresi uzayabilir.
4. Deneme ortamında teknik ve iş kabulünü ayırın
Teknik kontrolde servisler, port erişimi, sertifikalar, saat ve DNS davranışı doğrulanır. İş kabulünde yetkili kullanıcı temel işlemi yapar: sipariş görüntüler, stok hareketini denetler veya bir raporu karşılaştırır. Uygun test verisi kullanılır; ödeme, e-belge, e-posta ve kargo gibi dış sistemlere istenmeyen gerçek işlem gönderilmesi engellenir.
Taşınan kopyanın zamanlanmış görevleri ve entegrasyon kuyrukları özellikle kontrol edilmelidir. Eski ve yeni ortam aynı anda çalışırken aynı faturanın gönderilmesi veya aynı işin iki kez işlenmesi riski oluşabilir. Test ortamının dış bağlantı politikası ve kullanılacak kimlik bilgileri bu yüzden canlıdan ayrılır.
5. Geçiş anında tek yazan ortamı koruyun
Geçiş öncesinde kullanıcı ve entegrasyon yazımları kararlaştırılmış sırayla durdurulur. Son eşitlemenin tamamlandığı uygulamaya uygun yöntemlerle doğrulanır. Ardından hedef servisler açılır ve erişim yönlendirilir. Eski ortamın yanlışlıkla yeniden yazım kabul etmesini önleyen kontroller uygulanır.
DNS kaydı değiştiğinde bütün istemcilerin aynı anda yeni adrese geçeceği varsayılmamalıdır. Önbellekler, uygulamanın DNS davranışı ve mevcut bağlantılar farklı sürelerde yenilenebilir. TTL ayarının önceden planlanması yardımcı olur; fakat oturumları ve sabit adres kullanan bileşenleri tek başına çözmez. Erişim testi ofis, şube, uzaktan kullanıcı ve dış entegrasyon için ayrı yapılır.
| Kontrol | Beklenen kanıt |
|---|---|
| Yazım dondurma | Kullanıcı ve otomatik işlerin durumu |
| Son eşitleme | Veri noktası, gecikme ve uygulama tutarlılığı |
| Hedefi açma | Teknik sağlık ve iş birimi doğrulaması |
| Erişimi yönlendirme | Farklı istemci ve entegrasyon yollarından başarılı test |
Tablonun tamamı için yana kaydırabilirsiniz.
6. Geri dönüş, yeni veriyi nasıl koruyacağını açıklamalı
Yeni ortam henüz yazım kabul etmediyse eskiye dönüş görece daha basit olabilir. Yeni siparişler veya stok hareketleri oluştuğunda eski sunucuyu açmak yeterli değildir; yeni verinin ne yapılacağı kararlaştırılmalıdır. Veri noktalarının ayrışması, kullanıcıların farklı ortamlara yazması ve entegrasyonların tekrar çalışması engellenmelidir.
Geri dönüş planında karar yetkilisi, son karar zamanı, dönüşü tetikleyen ölçüt ve verinin taşınma ya da mutabakat yöntemi bulunur. “İşler yavaşsa döneriz” yerine hangi iş senaryosunun hangi kabul sınırını aştığı yazılır. Geri dönüşün kendisinin de süre ve veri riski olduğu bakım planına dâhil edilir.
7. Yeni ortamı işletime alın, eskiyi hemen silmeyin
Kabul sonrasında yedekleme, izleme, log toplama, güvenlik politikaları ve kapasite alarmları yeni ortam için doğrulanır. Yeni adresler envantere işlenir; sorumlular ve bakım belgeleri güncellenir. İlk yoğun iş dönemi sırasında uygulama performansı eski ölçümlerle karşılaştırılır.
Eski ortamın saklama ve kapatma tarihi önceden belirlenir. Bu süre içinde erişim kontrollü tutulur ve yanlışlıkla canlı hizmet vermesi önlenir. Veri mutabakatı, iş birimi kabulü ve geri dönüş ihtiyacı tamamlanmadan kalıcı silme veya lisans sonlandırma yapılmaz. Taşımanın son çıktısı çalışan bir sunucudan daha fazlasıdır: doğrulanmış veri, çalışan iş akışı ve yönetilebilir yeni ortam.
Sık sorulan sorular
Kesintisiz taşıma her uygulamada mümkün mü?
Hayır. Uygulamanın ve kullanılan geçiş yönteminin yeteneklerine bağlıdır. Kesinti beklentisi değerlendirme sonrasında netleştirilmelidir.
Yedek varsa geri dönüş planına gerek var mı?
Vardır. Hangi veriye, hangi ortamda, hangi sırayla dönüleceği ve işin nasıl doğrulanacağı ayrıca belirlenmelidir.