Yerel Bir Sunucuyu AWS'ye Taşıma (Basit Çalışma Kitabı)

Giriş

On-prem'den AWS'ye geçişler, hesaplama nedeniyle değil, daha çok planlama eksiklikleri nedeniyle daha az başarısız olur: belirsiz geçiş hedefleri, gözden kaçan bağımlılıklar ve aceleci testler. Bu kılavuz, süreci takip etmesi kolay tutarken operasyonel kalmayı sağlar. Başarının neye benzediğini tanımlayacak, minimal bir iniş alanı hazırlayacak, AWS MGN test başlatmalarını gerçekleştirecek, güvenle geçiş yapacak ve ardından yükü canlı hale geldikten sonra optimize edeceksiniz.

Taşımadan Önce Ne Karar Vermelisiniz?

Bu sunucuya hangi göç stratejisi uygundur (AWS "7 Rs")?

Zaman kaybetmenin en hızlı yolu yanlış şeyi taşımaktır. Herhangi bir ajanı yüklemeden önce, sunucunun hangi göç stratejisini hak ettiğine karar verin, böylece emekliye ayrılması veya değiştirilmesi gereken bir şeyi taşımamış olursunuz. Pratikte, birçok ekip hız için yeniden barındırma ile başlar, ardından iş yükü AWS'de istikrara kavuştuğunda optimize eder.

Ancak, bu yalnızca sunucu iyi bir "olduğu gibi" aday olduğunda ve geçişten hemen sonra pahalı teknik borç yaratmayacaksa işe yarar. Pratik karar kısayolları:

• Yeniden barındırma: zaman kısıtlı olduğunda minimum değişiklikle hızlı hareket et.
• Yeniden platforma geçiş: uygulamayı koruyun ama AWS uyumlu küçük ayarlamalar yapın.
• Yeniden yapılandır: iş açısından kritik farklılaştırıcılara çaba ayırın.
• Yeniden satın alma: değiştirin ile SaaS sunucuyu taşımak yerine.
• Emekli/Devam ettir: kullanılmayan sistemleri kaldırın veya kısıtlı iş yüklerini yerel olarak tutun.

Kullanışlı bir iç kontrol noktası, iş yükünün "bulut geleceği" olup olmadığını sormaktır. Sunucu daha sonra yönetilen hizmetlere veya konteynerleştirilmiş hizmetlere ayrılacaksa, bunu şimdi belgeleyin ve yeniden barındırmayı kalıcı bir tasarım yerine geçici bir adım olarak değerlendirin.

RTO/RPO, Kesinti Süresi Penceresi ve Geri Alma Tetikleyicileri Nedir?

Kesintiler, başarı ölçülebilir olduğunda başarılı olur. Kabul edilebilir kesinti süresini ve veri kaybı toleransını tanımlayın, ardından geri dönüşü zorunlu kılan koşulları yazın. Bu, göç hedefini korur ve ekiplerin kesinti penceresi sırasında doğaçlama yapmasını engeller. Ayrıca, iş paydaşlarının onay vermesine yardımcı olur çünkü kabul edilen riskin tam olarak ne olduğunu görebilirler.

Tanımlayın ve belgeleyin:

• RTO: maksimum kabul edilebilir kesinti süresi.
• RPO: maksimum kabul edilebilir veri kaybı.
• Kesinti penceresi: üretim trafiğini değiştirmeye izin verildiğinde.
• Geri alma tetikleyicileri: belirli arıza koşulları (kimlik doğrulama kesintisi, başarısız işlemler, veri uyumsuzluğu).
• Kesme mekanizması: DNS değişimi, yük dengeleyici anahtarı, yönlendirme/duvar değişiklikleri.

Geri alma planını gerçekçi tutmak için, geçiş sırasında her eylemin kimin sorumluluğunda olduğunu belirtin. Örneğin, bir kişi DNS değişikliklerinden, bir kişi uygulama doğrulamasından ve bir kişi yukarıdaki tetikleyicilere dayanarak "geri alma kararından" sorumludur.

AWS ve Yerel Ortamda Öncelikle Hazır Olması Gerekenler Nedir?

Yinelenme için bağlantı ve güvenlik duvarı temelleri

Replikasyon yalnızca kaynak ortam AWS'ye sürekli olarak ulaşabiliyorsa çalışır. En yaygın engeller, çıkış kontrolünün sıkı olması, proxy'ler ve dışa çıkan HTTPS trafiğini etkileyen TLS denetimidir. Bağlantıyı erken doğrulayın ve ilk replikasyon ve test başlatmaları sırasında ağ yolunu kararlı tutun. Birçok ortamda, replikasyon doğrudan "engellenmez"; bunun yerine, ara sıra kesintiler veya paket denetimi, daha sonra teşhis edilmesi zor olan dengesiz davranışlara neden olur.

Yaygın bağlantı desenleri:

• Kamu internet çıkışı (izin verildiğinde en basit)
• Site-to-site VPN (özel bağlantı için yaygın)
• Doğrudan Bağlantı (daha büyük ortamlar için daha öngörülebilir)

Uçuş öncesi kontroller:

• Kaynak ağdan dışa dönük HTTPS güvenilir bir şekilde çalışır.
• Proxy davranışı, göç akışı ile anlaşılıp test edilmiştir.
• Güvenlik ekipleri, geçiş penceresi için gerekli çıkışı onaylar.

Eğer ortamınız oldukça kısıtlıysa, dalga planınıza kısa bir "ağ kanıtlama" adımı ekleyin: bir pilot sunucudan uç noktaları doğrulayın, ardından bu tam kural setini dalganın geri kalanı için çoğaltın.

Minimal AWS iniş alanı kontrol listesi

Mükemmel bir iniş alanına ihtiyacınız yok, ancak dalga ortasında değişmeyecek tutarlı bir hedefe ihtiyacınız var. Yapıyı minimal ama kasıtlı tutun, böylece testler geçişin nasıl görüneceğini yansıtsın. Birçok göç sorunu, lansmandan sonra kimsenin yeniden inşa etmeye zamanı olmadığı için kalıcı hale gelen "geçici" ağ kısayollarından kaynaklanır.

Minimum iniş alanı unsurları:

• [A] Bir VPC ve alt ağlar örneklerin başlatılacağı yer (genellikle ayrı test ile üretim)
• Güvenlik grupları gerçek uygulama akışlarına uyumlu (şimdi aç, sonra düzeltmekten kaçının)
• IAM göç işlemleri ve ikinci gün erişimi ile araçlar için hazır
• Temel etiketleme sahiplik ve maliyet takibi geçişten sonra netleşir

Aynı zamanda yöneticilerin örneklere nasıl erişeceğini (bastion) erken karar vermelerine de yardımcı olur. VPN , SSM) ve dış internet erişiminin nasıl sağlanacağı (NAT geçidi, proxy). Bu seçimler, yamanın uygulanması, izleme ajanları ve ilk günde sorun giderme üzerinde etkilidir.

Kaynak sunucu hazır olma kontrol listesi

Temiz bir göç, temiz bir kaynağa bağlıdır. Seçtiğiniz yöntemle iş yükünün uyumlu olduğunu onaylayın, ardından AWS'de değişecek yerel varsayımlara bağlı olan her şeyi belirleyin. Bu, farklı bir sıralama gerektirebilecek "özel durum" sunucularını işaretlediğiniz yerdir. Örneğin, yoğun yazma etkinliği olan bir dosya sunucusu, daha sıkı bir geçiş penceresi ve açık dosyalar ile paylaşımlar için daha katı bir doğrulama gerektirebilir.

Sürprizleri önleyen hazırlık kontrolleri:

• Göç yaklaşımı ile OS/yük uyumluluğu
• Yeterli disk ve replikasyon yükü için sabit I/O
• Bağımlılıklar haritalandı: DNS , AD/LDAP iç, dahili PKI/sertifikaları veritabanları, paylaşımlar
• Gizli kırılganlık: sabit kodlanmış IP'ler, eski TLS, alışılmadık planlı görevler
• Özel durumlar erken işaretlendi: etki alanı denetleyicileri, kümeler, cihazlar, dongle lisanslama

Bu adımı terk etmeden önce, AWS başlatma ayarlarınızı ve geçiş sıralamanızı doğrudan etkileyen ana bilgisayar adı, IP adresi gereksinimleri veya sertifika bağlamaları gibi "aynı kalması gereken" öğeleri yakalayın.

AWS MGN ile bir sunucuyu AWS'ye nasıl taşırısınız?

MGN'i başlatın ve çoğaltma varsayımlarını ayarlayın

AWS MGN'i sunucunun çalışacağı bölgede başlatın, ardından dalga yürütmesinin tutarlı kalması için çoğaltma varsayılanlarını tanımlayın. Kararlı bir şablon, sunucu başına değişkenliği azaltır ve sorun gidermeyi tekrarlanabilir hale getirir. Bunu, sanallaştırılmış bir ortamda bir altın görüntüye benzer şekilde, çoğaltma için standart işletim prosedürünüz olarak düşünün.

Önceden çoğaltma varsayımlarını ayarlayın:

• Hedef alt ağ stratejisi ve ağ yerleşimi
• Başlatılan örnekler için güvenlik grubu temel düzeyi
• Depolama davranışı (hacim eşleştirme, şifreleme beklentiler)
• Üretim trafiğini korumak için çoğaltma kısıtlaması

Eğer üretimin testten farklı ayarlar gerektireceğini zaten biliyorsanız, bu farklılıkları açıkça tanımlayın. Bu şekilde, test başlatmaları, üretim ağlarını gereksiz yere açığa çıkarmadan temsilci kalır.

Ajanı yükleyin ve ilk senkronizasyonu tamamlayın

Kaynak sunucuda replikasyon ajanını kurun ve başarılı bir şekilde kaydolduğunu onaylayın. İlk senkronizasyon, istikrarsızlığın size en çok maliyet getirdiği yerdir, bu nedenle gereksiz değişikliklerden kaçının ve replikasyon sağlığını yakından izleyin. Bu, ekiplerin her dalgada aynı sorunları çözmek zorunda kalmamaları için "bilinen iyi" kurulum akışını belgelemekten faydalandığı yerdir.

Operasyonel rehberlik:

• Sunucu başlangıç çoğaltması sırasında stabil tutun (mümkünse yeniden başlatmalardan kaçının)
• Replicasyon durumunu izleyin ve hataları hemen giderin.
• Kurulum yöntemini belgeleyin, böylece gelecekteki dalgalar tutarlı olur.

Başlangıç senkronizasyonu sırasında, yalnızca göç konsolunu değil, aynı zamanda sunucu performansını da izleyin. Çoğaltma yükü, daha önce yerel ortamda gizlenmiş olan depolama darboğazlarını veya disk hatalarını ortaya çıkarabilir.

Test örneği başlatın ve doğrulayın

Bir test başlatması varsayımları kanıta dönüştürür. Test örneğini başlatın, ardından uygulama sağlığını uçtan uca doğrulayın, sadece önyükleme başarısını değil. Testlerin sunucular ve dalgalar arasında tekrarlanabilir olması için bir kontrol listesi kullanın. Eğer son kullanıcılar aracılığıyla bağlanacaksa TSplus Uzak Erişim Erişim yolu kontrolünü doğrulama sürecine dahil edin. Tutarlılık önemlidir çünkü bu, iş yükleri arasında sonuçları karşılaştırmanıza ve birden fazla sunucuyu etkileyen DNS çözümleme sorunları gibi kalıpları tespit etmenize olanak tanır.

Minimum doğrulama kontrol listesi:

• Önyükleme tamamlanır ve hizmetler temiz bir şekilde başlar
• Ana iş akışları için uygulama duman testleri geçiyor.
• Kimlik doğrulama çalışır (AD/LDAP/yerel)
• Veri yolları çalışır (DB bağlantıları, dosya paylaşımları, entegrasyonlar)
• Planlanmış işler ve arka plan hizmetleri beklendiği gibi çalışır.
• Günlükler ve izleme sinyalleri operasyon ekibinizin beklediği yerde görünün

Bir adım daha ekleyin ki ekipler genellikle atlar: kullanıcıların uygulamaya nasıl erişeceğini doğrulayın, dahili yönlendirme, güvenlik duvarı kuralları ve herhangi bir üst sistem dahil. Bir sunucu "sağlıklı" olabilir ama pratikte ulaşılamaz durumda olabilir.

Geçişi başlat ve tamamla

Kesim, kontrol edilen bir geçiştir, bir inanç sıçraması değildir. Mümkünse değişiklikleri dondurun, trafiği planlanan mekanizmayı kullanarak taşıyın, ardından aynı kontrol listesi ile doğrulayın. Geri alma sahipliğini açık tutun, böylece kararlar hızlı alınır. Bunu tekrarlanabilir bir oyun kitabı olarak değerlendirin: ne kadar az doğaçlama yaparsanız, risk o kadar düşük olur.

Kesim yürütme gereklilikleri:

• Değişiklik dondurma ve iletişim planını onayla
• Kesinti anında geçiş örneğini başlatın ve trafiği yönlendirin (DNS/LB/yönlendirme)
• Veri bütünlüğüne ekstra odaklanarak doğrulama kontrol listesini yeniden çalıştırın.
• Gerekirse geri alma tetikleyicilerini uygulayın ve trafiği temiz bir şekilde geri alın.
• Kesintiyi tamamlayın ve test kaynaklarını kaldırın veya sonlandırın.

Kesintiden hemen sonra, üretimde neyin değiştiğini (yeni IP'ler, yeni yollar, yeni güvenlik grubu kuralları) yakalayın ve belgeleyin. Bu, bir şeyin haftalar sonra bozulduğunda operasyon ekibinin ihtiyaç duyduğu bilgidir.

Genellikle Neler Bozulur ve Kesimden Sonra Hemen Ne Yapmalısınız?

Ağ çıkışı, DNS/AD bağımlılıkları ve "kaldır ve taşıma yapılmadı"

Çoğu hata bağımlılık hatalarıdır. Replikasyon, çıkış ve proxy kısıtlamalarında bozulma eğilimindeyken, uygulama davranışı kimlik, ad çözümü ve sertifikalarda bozulma eğilimindedir. Geçiş başarılı olsa bile, yeniden barındırma yalnızca ilk kilometre taşıdır, nihai durum değildir. İkinci bir aşama olmadan, genellikle daha pahalı ve işletmesi daha zor olan "bulut barındırılan miras" ile karşılaşırsınız.

En yaygın kırılma noktaları:

• Proxy tarafından engellenen veya değiştirilen çıkış HTTPS TLS denetimi
• DNS çözümleme değişiklikleri (bölünmüş ufuk sorunları, eksik çözücü kuralları)
• VPC'den AD/LDAP erişilebilirlik boşlukları
• Yeni ortamda iç PKI zincirleri eksik veya güvenilir değil.
• Sabit kodlanmış uç noktalar ve yerel ağ yolları hakkında eski varsayımlar

Basit bir önlem, kimlik ve DNS'i erken bir pilot lansman ile test etmektir. Bu temeller çalışıyorsa, uygulama doğrulamasının geri kalanı çok daha öngörülebilir hale gelir.

Geçiş sonrası istikrar: güvenlik, yedeklemeler, izleme, maliyet

Kesintiden sonraki ilk 48 saat, istikrar ve kontrol öncelikli olmalıdır. Yükün gözlemlenebilir, kurtarılabilir ve güvenli bir şekilde yönetildiğinden emin olun, daha derin optimizasyona zaman harcamadan önce. Bu, aynı zamanda göçünüzün uzun vadede başarılı olduğu yerdir, çünkü iyi ikinci gün operasyonları "bunu taşıdık ama kimse sahiplenmek istemiyor" sonuçlarını önler.

Açılış sonrası hemen yapılacak işlemler:

• Gözetim/uyarıların aktif ve sahipli olduğunu onaylayın
• Yedeklemelerin etkinleştirildiğinden emin olun ve bir geri yükleme doğrulaması tamamlayın.
• Güvenlik gruplarını sıkılaştırın ve en az ayrıcalık ilkesini uygulayın IAM
• Yamanlama yaklaşımını ve idari erişimi standartlaştırın (denetlenebilir yollar)
• Gerçek kullanım verilerini topladıktan sonra boyutlandırmaya başlayın
• Etiketlemeyi zorunlu kılın, "bilinmeyen sahip" maliyet kaymasını önleyin.

Stabilite kanıtlandıktan sonra, her bir taşınan sunucu için kısa bir optimizasyon incelemesi planlayın. Depolama türleri, örnek aile seçimi ve ayrılmış kapasite stratejisi üzerinde yapılacak hafif bir geçiş bile maliyeti önemli ölçüde azaltabilir.

TSplus AWS'ye Sunucuları Taşıdıktan Sonra Nereye Uygun?

Windows iş yükleri AWS üzerinde çalıştıktan sonra, birçok ekip hala kullanıcılar için ağır bir VDI yığını oluşturmadan Windows uygulamalarını ve masaüstlerini yayınlamanın basit bir yoluna ihtiyaç duymaktadır. TSplus Uzak Erişim Windows sunucuları için AWS, yerel veya hibrit ortamlarda uygulama yayınlama ve uzaktan masaüstü erişimi sağlar; SMB ve orta ölçekli işletmelere uygun, basit yönetim ve öngörülebilir lisanslama ile.

Sonuç

Bir yerel sunucunun AWS'ye taşınması, tekrarlanabilir bir çalışma kitabını takip ettiğinde en başarılı şekilde gerçekleşir: doğru göç stratejisini seçin, bağımlılıkları doğrulayın, güvenli bir şekilde çoğaltın, gerçekçi bir şekilde test edin ve net geri alma tetikleyicileri ile geçiş yapın. Üretim stabil hale geldikten sonra, ikinci gün operasyonlarına odaklanın: güvenlik güçlendirmesi, yedekleme doğrulaması, izleme ve boyutlandırma. Bu, bir "taşıma" işlemini güvenilir, maliyet kontrolü sağlanmış bir platforma dönüştürür.