Ana içeriğe geç
BULUT MİMARİSİ

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.

  1. 1Keşif ve bağımlılık
  2. 2Pilot taşıma
  3. 3Son delta ve cutover
  4. 4Kabul / rollback
Taşımanın başarısını hedefteki gerçek iş işlemiyle kanıtlayın.

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.

KonuGoogle CloudAmazon Web Services (AWS)Microsoft Azure
Keşif / değerlendirmeMigration CenterAWS migration assessment araçları; kapsamı doğrulayın.Azure Migrate
VM taşımaMigrate to Virtual MachinesAWS Transform MGN (eski adı Application Migration Service)Azure Migrate VM migration seçenekleri
Veritabanı taşımaDatabase 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 ServiceAWS DataSyncAzure 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

BelirtiOlası neden / ayrımDoğrulama
Replication tamam, uygulama açılmıyorKimlik, 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 hedefteDNS 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

  1. Taşımanın başarısını hedefteki gerçek iş işlemiyle kanıtlayın.
  2. Kaynak/hedef destek matrisini doğrulayın.
  3. İlk kopya ve son delta sürelerini ayrı ölçün.
  4. Tek yetkili yazıcıyı cutoverda koruyun.
  5. DNS ve sabit hedef kullanan istemcileri test edin.
  6. 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.

Kurumsal IT Ürün Satışı, Lisanslama ve Kurulum
Kurumsal IT Proje & Çözüm Senaryoları
Tüm ilgili içerikleri görüntüleyin
WhatsApp'tan Yazın
Kopyalandı!