SQL Veritabanı etkin coğrafi çoğaltma kullanarak bulut uygulamalarının sıralı yükseltmelerini yönetme

Şunlar için geçerlidir:Azure SQL Veritabanı

Bulut uygulamanızın sıralı yükseltmelerini etkinleştirmek için Azure SQL Veritabanı'da etkin coğrafi çoğaltmayı kullanmayı öğrenin. Yükseltmeler kesintiye neden olan işlemler olduğundan, iş sürekliliği planlama ve tasarımınızın bir parçası olmalıdır. Bu makalede, yükseltme işlemini düzenlemenin iki farklı yöntemine göz atacağız ve her seçeneğin avantajlarını ve dezavantajlarını tartışacağız. Bu makalenin amaçları doğrultusunda, veri katmanı olarak tek bir veritabanına bağlı bir web sitesinden oluşan bir uygulamaya başvuruyoruz. Hedefimiz, kullanıcı deneyimini önemli ölçüde etkilemeden uygulamanın sürüm 1'ini (V1) sürüm 2'ye (V2) yükseltmektir.

Yükseltme seçeneklerini değerlendirirken şu faktörleri göz önünde bulundurun:

  • Uygulama işlevlerinin ne kadar süreyle sınırlı olabileceği veya düzeyi düşürülebileceği gibi yükseltmeler sırasında uygulama kullanılabilirliği üzerindeki etki.
  • Yükseltme başarısız olursa geri alma özelliği.
  • Yükseltme sırasında ilgili olmayan, yıkıcı bir hata oluşursa uygulamanın güvenlik açığı.
  • Toplam dolar maliyeti. Bu faktör, yükseltme işlemi tarafından kullanılan geçici bileşenlerin ek veritabanı yedekliliğini ve artımlı maliyetlerini içerir.

Olağanüstü durum kurtarma için veritabanı yedeklerini kullanan uygulamaları yükseltme

Uygulamanız otomatik veritabanı yedeklemelerini kullanıyorsa ve olağanüstü durum kurtarma için coğrafi geri yükleme kullanıyorsa, tek bir Azure bölgesine dağıtılır. Kullanıcı kesintisini en aza indirmek için, yükseltmeye dahil olan tüm uygulama bileşenleriyle bu bölgede bir hazırlama ortamı oluşturun. İlk diyagramda, yükseltme işleminden önceki işlem ortamı gösterilmektedir. Uç nokta contoso.azurewebsites.net , web uygulamasının üretim ortamını temsil eder. Yükseltmeyi geri alabilmeniz için, veritabanının tam olarak eşitlenmiş bir kopyasıyla bir hazırlama ortamı oluşturmanız gerekir. Yükseltme için bir hazırlama ortamı oluşturmak için şu adımları izleyin:

  1. Aynı Azure bölgesinde ikincil bir veritabanı oluşturun. Çekirdek oluşturma işleminin tamam olup olmadığını görmek için ikincil öğeyi izleyin (1).
  2. Web uygulamanız için yeni bir ortam oluşturun ve 'Hazırlama' olarak adlandırabilirsiniz. Url contoso-staging.azurewebsites.net (2) ile Azure DNS'ye kaydedilir.

Dekont

Bu hazırlık adımları, tam erişim modunda çalışabilen üretim ortamını etkilemez.

Diagram shows the SQL Database geo-replication configuration for cloud disaster recovery.

Hazırlık adımları tamamlandığında, uygulama gerçek yükseltme için hazırdır. Sonraki diyagramda yükseltme işlemine dahil olan adımlar gösterilmektedir:

  1. Birincil veritabanını salt okunur moda (3) ayarlayın. Bu mod, yükseltme sırasında web uygulamasının (V1) üretim ortamının salt okunur kalmasını garanti eder ve böylece V1 ile V2 veritabanı örnekleri arasında veri ayrışmasını önler.
  2. Planlı sonlandırma modunu (4) kullanarak ikincil veritabanının bağlantısını kesin. Bu eylem, birincil veritabanının tam olarak eşitlenmiş, bağımsız bir kopyasını oluşturur. Bu veritabanı yükseltilecek.
  3. İkincil veritabanını okuma-yazma moduna geçirin ve yükseltme betiğini (5) çalıştırın.

Diagram shows SQL Database geo-replication configuration for cloud disaster recovery that runs the upgrade script.

Yükseltme başarıyla tamamlanırsa, artık kullanıcıları yükseltilen uygulama kopyasına geçmeye hazırsınız ve bu da üretim ortamına dönüşür. Geçiş, sonraki diyagramda gösterildiği gibi birkaç adım daha içerir:

  1. Web uygulamasının üretim ve hazırlama ortamları arasında değiştirme işlemini etkinleştirin (6). Bu işlem iki ortamın URL'lerini değiştirir. Şimdi contoso.azurewebsites.net web sitesinin ve veritabanının (üretim ortamı) V2 sürümüne işaret edin.
  2. Değiştirme işleminden sonra hazırlama kopyası haline gelen V1 sürümüne artık ihtiyacınız yoksa, hazırlama ortamının yetkisini alabilirsiniz (7).

SQL Database geo-replication configuration for cloud disaster recovery.

Yükseltme işlemi başarısız olursa (örneğin, yükseltme betiğindeki bir hata nedeniyle), hazırlama ortamının güvenliğinin aşıldığını düşünün. Uygulamayı yükseltme öncesi durumuna geri almak için üretim ortamındaki uygulamayı tam erişime geri alın. Sonraki diyagramda geri çevirme adımları gösterilmektedir:

  1. Veritabanı kopyasını okuma-yazma moduna (8) ayarlayın. Bu eylem, üretim kopyasının tam V1 işlevselliğini geri yükler.
  2. Kök neden analizini gerçekleştirin ve hazırlama ortamının yetkisini alın (9).

Bu noktada uygulama tamamen işlevseldir ve yükseltme adımlarını yineleyebilirsiniz.

Dekont

Henüz değiştirme işlemi gerçekleştirmediğiniz için geri alma işlemi DNS değişiklikleri gerektirmez.

Diagram shows SQL Database geo-replication configuration for cloud disaster recovery with the staging environment decommissioned.

Bu seçeneğin temel avantajı, bir dizi basit adımı izleyerek tek bir bölgedeki bir uygulamayı yükseltebilmenizdir. Yükseltmenin dolar maliyeti nispeten düşüktür.

Ana denge, yükseltme sırasında yıkıcı bir hata oluşursa, yükseltme öncesi duruma kurtarmanın uygulamanın farklı bir bölgede yeniden dağıtılmasını ve coğrafi geri yükleme kullanarak veritabanını yedekten geri yüklemeyi içermesidir. Bu işlem önemli bir kapalı kalma süresine neden olur.

Olağanüstü durum kurtarma için veritabanı coğrafi çoğaltma kullanan uygulamaları yükseltme

Uygulamanız iş sürekliliği için etkin coğrafi çoğaltma veya yük devretme grupları kullanıyorsa, en az iki farklı bölgeye dağıtılır. Birincil bölgede etkin, birincil bir veritabanı ve yedekleme bölgesinde salt okunur, ikincil bir veritabanı vardır. Bu makalenin başında belirtilen faktörlerin yanı sıra, yükseltme işleminin şunları da garanti etmesi gerekir:

  • Uygulama, yükseltme işlemi sırasında her zaman yıkıcı hatalardan korunmaya devam eder.
  • Uygulamanın coğrafi olarak yedekli bileşenleri etkin bileşenlere paralel olarak yükseltilir.

Bu hedeflere ulaşmak için, Web Apps ortamlarını kullanmanın yanı sıra, bir etkin uç nokta ve bir yedekleme uç noktası ile bir yük devretme profili kullanarak Azure Traffic Manager'dan yararlanacaksınız. Sonraki diyagramda, yükseltme işleminden önceki işletimsel ortam gösterilmektedir. Web siteleri contoso-1.azurewebsites.net ve contoso-dr.azurewebsites.net tam coğrafi yedeklilik ile uygulamanın bir üretim ortamını temsil. Üretim ortamı aşağıdaki bileşenleri içerir:

  • Birincil bölgedeki web uygulamasının contoso-1.azurewebsites.net üretim ortamı (1)
  • Birincil bölgedeki birincil veritabanı (2)
  • Yedekleme bölgesindeki web uygulamasının beklemedeki örneği (3)
  • Yedekleme bölgesindeki coğrafi olarak çoğaltılan ikincil veritabanı (4)
  • Adlı çevrimiçi uç nokta ve adlı contoso-1.azurewebsites.net çevrimdışı uç nokta içeren traffic manager performans profili contoso-dr.azurewebsites.net

Yükseltmeyi geri almayı mümkün kılmak için, uygulamanın tam olarak eşitlenmiş bir kopyasıyla bir hazırlama ortamı oluşturmanız gerekir. Yükseltme işlemi sırasında yıkıcı bir hata oluşması durumunda uygulamanın hızla kurtarılabilmesini sağlamanız gerektiğinden, hazırlama ortamının da coğrafi olarak yedekli olması gerekir. Yükseltme için bir hazırlama ortamı oluşturmak için aşağıdaki adımlar gereklidir:

  1. Web uygulamasının hazırlama ortamını birincil bölgeye (6) dağıtın.
  2. Birincil Azure bölgesinde (7) ikincil veritabanı oluşturun. Web uygulamasının hazırlama ortamını buna bağlanmak için yapılandırın.
  3. İkincil veritabanını birincil bölgede çoğaltarak yedekleme bölgesinde coğrafi olarak yedekli, ikincil başka bir veritabanı oluşturun. (Bu yöntem zincirli coğrafi çoğaltma olarak adlandırılır.) (8).
  4. Web uygulaması örneğinin hazırlama ortamını yedekleme bölgesine (9) dağıtın ve (8) konumunda oluşturulan coğrafi olarak yedekli ikincil veritabanına bağlanacak şekilde yapılandırın.

Dekont

Bu hazırlık adımları üretim ortamındaki uygulamayı etkilemez. Okuma-yazma modunda tamamen işlevsel kalır.

Diagram shows SQL Database geo-replication configuration for cloud disaster recovery with a fully synchronized copy of the application.

Hazırlık adımları tamamlandığında, hazırlama ortamı yükseltme için hazırdır. Sonraki diyagramda şu yükseltme adımları gösterilmektedir:

  1. Üretim ortamındaki birincil veritabanını salt okunur moda (10) ayarlayın. Bu mod, üretim veritabanının (V1) yükseltme sırasında değişmemesini garanti eder ve böylece V1 ile V2 veritabanı örnekleri arasındaki veri ayrışmasını önler.
-- Set the production database to read-only mode
ALTER DATABASE [<Prod_DB>]
SET READ_ONLY
  1. İkincil (11) bağlantısını keserek coğrafi çoğaltmayı sonlandırın. Bu eylem, üretim veritabanının bağımsız ancak tam olarak eşitlenmiş bir kopyasını oluşturur. Bu veritabanı yükseltilecek. Aşağıdaki örnek Transact-SQL kullanır ancak PowerShell de kullanılabilir.
-- Disconnect the secondary, terminating geo-replication
ALTER DATABASE [<Prod_DB>]
REMOVE SECONDARY ON SERVER [<Partner-Server>]
  1. yükseltme betiğini , contoso-dr-staging.azurewebsites.netve hazırlama birincil veritabanına (12) karşı contoso-1-staging.azurewebsites.netçalıştırın. Veritabanı değişiklikleri otomatik olarak hazırlama ikinciline çoğaltılır.

Diagram shows SQL Database geo-replication configuration for cloud disaster recovery with database changes replicated to staging.

Yükseltme başarıyla tamamlanırsa artık kullanıcıları uygulamanın V2 sürümüne geçmeye hazırsınız demektir. Sonraki diyagramda ilgili adımlar gösterilmektedir:

  1. Birincil bölgede (13) ve yedekleme bölgesinde (14) web uygulamasının üretim ve hazırlama ortamları arasında değiştirme işlemini etkinleştirin. Uygulamanın V2'si artık yedekleme bölgesinde yedekli bir kopyası olan bir üretim ortamına dönüşür.
  2. V1 uygulamasına (15 ve 16) artık ihtiyacınız yoksa hazırlama ortamının yetkisini alabilirsiniz.

Diagram shows SQL Database geo-replication configuration for cloud disaster recovery with optional decommissioning of the staging environment.

Yükseltme işlemi başarısız olursa (örneğin, yükseltme betiğindeki bir hata nedeniyle), hazırlama ortamını tutarsız bir durumda olarak düşünün. Uygulamayı yükseltme öncesi durumuna geri almak için üretim ortamında uygulamanın V1'ini kullanmaya geri dönün. Gerekli adımlar bir sonraki diyagramda gösterilir:

  1. Üretim ortamındaki birincil veritabanı kopyasını okuma-yazma moduna (17) ayarlayın. Bu eylem, üretim ortamındaki tam V1 işlevselliğini geri yükler.
  2. Kök neden analizini gerçekleştirin ve hazırlama ortamını (18 ve 19) onarın veya kaldırın.

Bu noktada uygulama tamamen işlevseldir ve yükseltme adımlarını yineleyebilirsiniz.

Dekont

Değiştirme işlemi gerçekleştirmediğiniz için geri alma işlemi DNS değişiklikleri gerektirmez.

Diagram shows SQL Database geo-replication configuration for cloud disaster recovery with the upgrade process rolled back.

Bu seçeneğin temel avantajı, yükseltme sırasında iş sürekliliğinizden ödün vermeden hem uygulamayı hem de coğrafi olarak yedekli kopyasını paralel olarak yükseltebilmenizdir.

Ana denge, her uygulama bileşeninin çift yedekli olmasını gerektirmesi ve bu nedenle daha yüksek dolar maliyetine neden olmasıdır. Ayrıca daha karmaşık bir iş akışı içerir.

Özet

Makalede açıklanan iki yükseltme yöntemi karmaşıklık ve dolar maliyeti açısından farklılık gösterir, ancak her ikisi de kullanıcının salt okunur işlemlerle ne kadar süreyle sınırlı olduğunu en aza indirmeye odaklanır. Bu süre doğrudan yükseltme betiğinin süresiyle tanımlanır. Veritabanı boyutuna, seçtiğiniz hizmet katmanına, web sitesi yapılandırmasına veya kolayca denetleyebileceğiniz diğer faktörlere bağlı değildir. Tüm hazırlık adımları yükseltme adımlarından ayrılmıştır ve üretim uygulamasını etkilemez. Yükseltme betiğinin verimliliği, yükseltmeler sırasında kullanıcı deneyimini belirleyen önemli bir faktördür. Bu nedenle, bu deneyimi geliştirmenin en iyi yolu, yükseltme betiğini mümkün olduğunca verimli hale getirmek için çabalarınızı odaklamanızdır.