Bulut Geçişi: Google Cloud, AWS ve Azure Migration Planı
Keşif, bağımlılık analizi, servis seçimi, veri eşitleme, cutover ve rollback adımlarıyla kontrollü bulut geçişi.
İçerik güncellemesi:
Mimari ve çalışma modeli
Bulut geçişi VMin başka yerde açılmasından daha geniştir. Uygulama lisansı, kimlik, DNS, veri, sertifika, zaman ve dış sistem bağlantıları birlikte taşınır veya yeniden tasarlanır. Rehost mevcut yapıyı büyük ölçüde korur; replatform işletim modelini değiştirir; refactor uygulama kodunu ve veri akışını etkileyebilir. Geçiş tercihi iş değerine ve kabul edilmiş riske göre yapılır.
Google Cloud, AWS ve Azure keşif veya taşıma araçları sunar; araç uygunluğu kaynak hypervisor, OS, disk, veritabanı ve hedef servis desteğine bağlıdır. Replikasyon jobunun tamamlanması uygulama tutarlılığı ve kesintisiz geçiş garantisi değildir. Veritabanında snapshot, log veya CDC yönteminin transaction sınırını nasıl koruduğu ayrıca incelenir.
Cutover öncesi son veri farkının alınması, yazmanın durdurulması veya tek yazıcıya yönlendirilmesi planlanır. DNS TTL düşürmek tüm istemcilerin anında yeni hedefe geçmesini sağlamaz; sabit IP, cache ve connection pool davranışı test edilir. Eski ve yeni sistem aynı anda yazıyorsa veri ayrışması oluşabilir.
Rollback için bir son karar noktası ve veri stratejisi gerekir. Hedefte yeni işlem kabul edildikten sonra eski sistemi açmak tek başına güvenli geri dönüş değildir. Değişen verinin taşınması, transaction uyumu ve tekrar yönlendirme yöntemi önceden sınanır. Eski ortam kabul tamamlanana kadar tanımlı süre ve erişimle tutulur.
- 1Keşif ve bağımlılık
- 2Pilot taşıma
- 3Son delta ve cutover
- 4Kabul / rollback
Tasarım parametreleri
- Bağımlılık grubu
- Birlikte değişmesi gereken uygulama, veri ve dış bağlantıları çıkarın.
- Veri değişim hızı
- İlk kopya süresiyle son delta süresini ayırın; link kapasitesini gerçek ölçün.
- Kabul sınırı
- Hata oranı, kayıt doğruluğu, gecikme ve maksimum geçiş kesintisini yazın.
- Geri dönüş verisi
- Hedefte oluşan işlemler için aktarım ve tek-yazıcı yöntemini belirleyin.
Platformlardaki uygulama karşılıkları
Servis adları teknik karşılıklardır. Kapsam, varsayılanlar, bölge kullanılabilirliği ve işletim koşulları farklıdır; birebir aynı garanti anlamına gelmez.
| Konu | Google Cloud | Amazon Web Services (AWS) | Microsoft Azure |
|---|---|---|---|
| Keşif / değerlendirme | Migration Center | AWS migration assessment araçları; kapsamı doğrulayın. | Azure Migrate |
| VM taşıma | Migrate to Virtual Machines | AWS Transform MGN (eski adı Application Migration Service) | Azure Migrate VM migration seçenekleri |
| Veritabanı taşıma | Database Migration Service; engine desteğini doğrulayın. | AWS Database Migration Service; kaynak/hedef ve CDC desteğini doğrulayın. | Azure Database Migration Service ve engine-specific yöntemler |
| Toplu veri aktarımı | Storage Transfer Service | AWS DataSync | Azure Storage transfer araçları; veri türüne göre seçin. |
Hesap ve uygulama örneği
Örnek 500 GB ilk veri 80 Mbps kullanılabilir hatta ideal olarak yaklaşık 13 saat 53 dakikada taşınır: 500 × 8 × 1000 / 80 saniye. Protokol, metadata, kayıp ve yeniden deneme bu süreyi uzatır. Başlangıç kopyasını geçiş penceresinde başlatmak yerine önceden alın; son farkın büyüklüğünü pilotta ölçün.
Planlı pencerede yazmayı kontrollü durdurun, son senkronizasyonu doğrulayın ve hedefte kritik işlemi çalıştırın. Satır sayısı tek başına doğruluk değildir; seçili iş kayıtları, ilişkiler ve yeni transaction sonucu kontrol edilir. Rollback kararını tanımlı kabul sınırına göre verin; iki tarafta aynı anda yazmayı önleyin.
Hata teşhisi
| Belirti | Olası neden / ayrım | Doğrulama |
|---|---|---|
| Replication tamam, uygulama açılmıyor | Kimlik, lisans veya dış bağlantı eksik olabilir. | Bağımlılık listesini hedefte gerçek uygulama işlemiyle doğrulayın. |
| Bazı kullanıcılar eski hedefte | DNS cache, sabit IP veya connection pool kalmış olabilir. | İstemci çözümlemesi, bağlantı hedefi ve yeni yazma yerini kontrol edin. |
| Geri dönüşte kayıtlar farklı | Hedefteki yeni işlemler geri taşınmamış olabilir. | Son ortak transaction noktasını ve delta yöntemini inceleyin. |
Kabul ve doğrulama kontrolleri
- Taşımanın başarısını hedefteki gerçek iş işlemiyle kanıtlayın.
- Kaynak/hedef destek matrisini doğrulayın.
- İlk kopya ve son delta sürelerini ayrı ölçün.
- Tek yetkili yazıcıyı cutoverda koruyun.
- DNS ve sabit hedef kullanan istemcileri test edin.
- Yeni işlem sonrası rollback veri yolunu tatbik edin.
İlgili kavramlar
Bağımlılık ve geri açılış sırası
Bir hizmet çoğu zaman kimlik, DNS, zaman, ağ, veritabanı ve lisans servislerine bağlıdır. Bağımlılıkları yalnız cihaz listesi olarak değil, hangi hizmetin hangi koşulla çalışabildiğini gösteren bir grafik olarak kaydedin. Geri açılış sırası buna göre belirlenir; bazı döngüsel bağımlılıklar özel acil erişim gerektirir. Çalışan altyapı bileşenleri ile işin yeniden başlayabildiği anı ayırın. Her bağımlılığa sorumlu, doğrulama yöntemi ve alternatif erişim yolu atayın. Uçtan uca testte bir bileşeni bilerek erişilemez hale getirerek varsayımları sınayın.
Bant genişliği ve gerçek aktarım
Hat kapasitesi ile uygulamanın taşıdığı yararlı veri miktarı farklıdır. Protokol başlıkları, şifreleme, yeniden iletim, küçük dosyalar ve disk beklemeleri net hızı azaltır. Bit ile byte birimini karıştırmayın: 1 Gbit/s teorik olarak 125 MB/s seviyesindedir; bu bir uygulama performans garantisi değildir. Aktarım süresini veri miktarı / ölçülen net hız şeklinde hesaplayın. Ölçümü aynı anda ağ, kaynak okuması ve hedef yazması üzerinden yaparak sınırlayıcı bileşeni bulun. Ortalama hız kadar kısa süreli düşüşleri ve diğer işlerin rekabetini de değerlendirin.
Uygulama tutarlılığı
Bir kopyanın açılabilir olması, uygulama verisinin tutarlı olduğunu kanıtlamaz. İşletim sistemi önbelleği, veritabanı günlükleri ve birden fazla disk veya servis arasındaki işlem sırası sonucu etkiler. Crash-consistent kopya beklenmedik kapanma sonrasındaki duruma benzer; application-consistent kopya uygulamanın desteklediği hazırlık ve yazma düzenini dikkate alır. Geri dönüşte yalnız dosya sayısını değil, işlem bütünlüğünü, kayıt ilişkilerini ve uygulama testini kontrol edin. Yedek ürününün desteklediği entegrasyonu, uygulama sürümünü ve hata çıktısını doğrulamadan tutarlılık varsaymayın.
RTO ve uçtan uca kurtarma süresi
RTO, bir hizmetin olaydan sonra ne kadar sürede kullanılabilir hale gelmesi gerektiğini ifade eder. Yedek dosyasının indirilmesi veya sanal makinenin açılması bu sürenin yalnız bir bölümüdür. Olayı tanıma, onay, altyapı hazırlığı, veri aktarımı, uygulama açılışı ve iş biriminin doğrulaması ayrı zaman kalemleri olarak kaydedilmelidir. Bir testin kronometresini hangi olayda başlatıp bitirdiğinizi açıkça yazın. Aynı teknik geri dönüş süresi, bağımlılık veya erişim beklenmesi nedeniyle farklı iş süreçlerinde farklı kesinti süresine dönüşebilir.
Sürüm ve destek yaşam döngüsü
Bir ürünün kurulabilir olması üretim için desteklendiğini kanıtlamaz. İşletim sistemi, uygulama, sürücü, eklenti ve yönetim aracının uyumluluk zincirini birlikte kontrol edin. Güncelleme planında paket sürümü, destek bitişi, yeniden başlatma gereksinimi ve geri alma yöntemi bulunmalıdır. Test ortamı üretimdeki bağımlılıkları temsil etmezse sonuç yanıltıcı olabilir. Değişiklik sonrası yalnız sürüm numarasını değil, hizmet sağlığını ve önceki iş akışlarını doğrulayın. Bir sürümü sabitlemenin gelecekteki güvenlik düzeltmelerini engelleyebileceğini de dikkate alın.
Yüksek erişilebilirlik ile kurtarma ayrımı
Yüksek erişilebilirlik, belirli arızalarda hizmetin kısa kesintiyle sürmesini hedefler; yedekleme, kaybolan veya bozulan veriyi önceki bir noktadan geri getirir. Bir küme yanlış silinen kaydı diğer düğüme de aktarabilir. Bu nedenle HA ve backup birbirinin yerine geçmez. Hizmetin DNS, kimlik, ağ, depolama ve enerji bağımlılıklarını birlikte düşünün. Başarılı düğüm geçişi tek başına yeterli değildir: kullanıcı oturumunun, uygulama yazmasının ve dış entegrasyonların geçiş sonrası davranışı da ölçülmelidir.
Birincil teknik dokümantasyon
İçeriğin hazırlanması
Doz Teknoloji Teknik Ekibi. Açıklamalar ilgili sağlayıcıların teknik dokümantasyonu, ortak mimari ilkeler ve açık varsayımlı örneklerle hazırlanmıştır. Hesap ve senaryolar açıklama amaçlıdır; müşteri ortamında yapılmış test veya sonuç iddiası taşımaz. Uygulamada sürüm, bölge, servis kapsamı ve destek koşulları yeniden doğrulanmalıdır.
İlgili bulut rehberleri
Google Cloud, AWS ve Azure: Bulut Platformu Nasıl Seçilir?
İş yükü, servis modeli, veri yerleşimi, güvenlik, kurtarma ve toplam maliyet üzerinden Google Cloud, AWS ve Azure değerlendirmesi.
Bulut Kimlik ve Yetki Yönetimi: Google Cloud, AWS, Azure
İnsan ve uygulama kimlikleri, kısa ömürlü erişim, en az yetki, kaynak sınırları ve erişim doğrulaması için üç platformlu teknik rehber.
Bulut Ağ Tasarımı: Google Cloud VPC, AWS VPC ve Azure VNet
Adres planı, platform sınırları, routing, private erişim, firewall ve hibrit bağlantıların tasarımı ve hata teşhisi.
Bulut Maliyeti ve FinOps: Google Cloud, AWS, Azure
Compute, storage, veri çıkışı, log ve lisans maliyetini; bütçe, rightsizing ve taahhütlerle birlikte yönetin.
Bulut Yedekleme ve Disaster Recovery: Google Cloud, AWS, Azure
Backup, replication ve HA ayrımı; bağımsız kurtarma erişimi, RPO/RTO, region kaybı ve failback testleri.
Bulut kurulum, işletim ve destek hizmetleri
Platform seçimini mevcut ürünleriniz, iş yükünüz ve işletim ihtiyaçlarınızla birlikte değerlendiriyoruz.