Azure SQL Veritabanı elastik havuzları kullanan uygulamalar için olağanüstü durum kurtarma stratejileri

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

Azure SQL Veritabanı, yıkıcı olaylar oluştuğunda uygulamanızın iş sürekliliğini sağlamak için çeşitli özellikler sağlar. Elastik havuzlar ve tek veritabanları aynı tür olağanüstü durum kurtarma (DR) özelliklerini destekler. Bu makalede, bu Azure SQL Veritabanı iş sürekliliği özelliklerinden yararlanan elastik havuzlar için çeşitli DR stratejileri açıklanmaktadır.

Bu makalede aşağıdaki kurallı SaaS ISV uygulama deseni kullanılır:

Modern bir bulut tabanlı web uygulaması, her son kullanıcı için bir veritabanı sağlar. ISV'nin birçok müşterisi vardır ve bu nedenle kiracı veritabanları olarak bilinen birçok veritabanı kullanır. Kiracı veritabanları genellikle öngörülemeyen etkinlik desenlerine sahip olduğundan, ISV uzun süreler boyunca veritabanı maliyetini çok tahmin edilebilir hale getirmek için bir elastik havuz kullanır. Elastik havuz, kullanıcı etkinliği ani artışlar olduğunda performans yönetimini de basitleştirir. Kiracı veritabanlarına ek olarak, uygulama kullanıcı profillerini yönetmek, güvenlik sağlamak, kullanım desenlerini toplamak vb. için çeşitli veritabanları da kullanır. Tek tek kiracıların kullanılabilirliği, uygulamanın kullanılabilirliğini tüm olarak etkilemez. Ancak, yönetim veritabanlarının kullanılabilirliği ve performansı uygulamanın işlevi için kritik öneme sahiptir ve yönetim veritabanları çevrimdışıysa tüm uygulama çevrimdışıdır.

Bu makalede, maliyete duyarlı başlangıç uygulamalarından sıkı kullanılabilirlik gereksinimleri olan uygulamalara kadar çeşitli senaryoları kapsayan DR stratejileri ele alınmaktadır.

1\. Senaryo Maliyete duyarlı başlangıç

Ben bir startup işletmesiyim ve son derece maliyete duyarlıyım. Uygulamanın dağıtımını ve yönetimini basitleştirmek istiyorum ve tek tek müşteriler için sınırlı bir SLA'ya sahip olabilirim. Ama bir bütün olarak uygulamanın hiçbir zaman çevrimdışı olmamasını istiyorum.

Basitlik gereksinimini karşılamak için tüm kiracı veritabanlarını seçtiğiniz Azure bölgesinde tek bir elastik havuza dağıtın ve yönetim veritabanlarını coğrafi olarak çoğaltılmış tek veritabanları olarak dağıtın. Kiracıların olağanüstü durum kurtarması için, ek ücret ödemeden gelen coğrafi geri yüklemeyi kullanın. Yönetim veritabanlarının kullanılabilirliğini sağlamak için, yük devretme grubu kullanarak bunları başka bir bölgeye coğrafi olarak çoğaltın (1. adım). Bu senaryoda olağanüstü durum kurtarma yapılandırmasının devam eden maliyeti, ikincil veritabanlarının toplam maliyetine eşittir. Bu yapılandırma bir sonraki diyagramda gösterilmiştir.

Birincil bölgede bir kesinti oluşursa, uygulamanızı çevrimiçine taşımaya yönelik kurtarma adımları sonraki diyagramda gösterilir.

• Yük devretme grubu, yönetim veritabanının DR bölgesine otomatik yük devretmesini başlatır. Uygulama otomatik olarak yeni birincil sunucuya yeniden bağlanır ve tüm yeni hesaplar ve kiracı veritabanları DR bölgesinde oluşturulur. Mevcut müşteriler verilerinin geçici olarak kullanılamadiğini görür.
• Elastik havuzu özgün havuzla (2) aynı yapılandırmayla oluşturun.
• Kiracı veritabanlarının (3) kopyalarını oluşturmak için coğrafi geri yükleme kullanın. Tek tek geri yüklemeleri son kullanıcı bağlantıları tarafından tetikleyebilir veya uygulamaya özgü başka bir öncelik şeması kullanabilirsiniz.

Bu noktada uygulamanız DR bölgesinde yeniden çevrimiçi olur, ancak bazı müşteriler verilerine erişirken gecikme yaşar.

Kesinti geçiciyse, dr bölgesinde tüm veritabanı geri yüklemeleri tamamlanmadan önce birincil bölgenin Azure tarafından kurtarılmış olması mümkündür. Bu durumda, uygulamayı birincil bölgeye geri taşımayı düzenler. İşlem, sonraki diyagramda gösterilen adımları uygular.

• Tüm bekleyen coğrafi geri yükleme isteklerini iptal edin.
• Yönetim veritabanlarının yükünü birincil bölgeye (5) devredin. Bölgenin kurtarılmasından sonra, eski birinciller otomatik olarak ikincil hale gelir. Artık roller arasında yeniden geçiş yapıyorlar.
• Uygulamanın bağlantı dizesi birincil bölgeye geri dönecek şekilde değiştirin. Artık tüm yeni hesaplar ve kiracı veritabanları birincil bölgede oluşturulur. Mevcut bazı müşteriler verilerinin geçici olarak kullanılamadiğini görür.
• DR bölgesindeki tüm veritabanlarını salt okunur olarak ayarlayarak DR bölgesinde değiştirilemeyeceklerinden emin olun (6).
• Kurtarmadan bu yana değişen DR havuzundaki her veritabanı için, birincil havuzdaki ilgili veritabanlarını yeniden adlandırın veya silin (7).
• Güncelleştirilmiş veritabanlarını DR havuzundan birincil havuza (8) kopyalayın.
• DR havuzunu silme (9)

Bu noktada uygulamanız birincil bölgede çevrimiçidir ve birincil havuzda tüm kiracı veritabanları kullanılabilir.

Avantaj

Bu stratejinin temel avantajı, veri katmanı yedekliliği için düşük sürekli maliyettir. Azure SQL Veritabanı hiçbir uygulama yeniden yazma olmadan ek ücret ödemeden veritabanlarını otomatik olarak yedekler. Maliyet yalnızca elastik veritabanları geri yüklendiğinde tahakkuk eder.

Denge

Denge, tüm kiracı veritabanlarının tamamen kurtarılmasının önemli ölçüde zaman almasıdır. Süre, DR bölgesinde başlattığınız toplam geri yükleme sayısına ve kiracı veritabanlarının genel boyutuna bağlıdır. Bazı kiracıların geri yüklemelerine diğerlerine göre öncelik verseniz bile, mevcut müşterilerin veritabanları üzerindeki genel etkiyi en aza indirmek için hizmet tarafından rastgele yapılan ve azaltılan aynı bölgede başlatılan diğer tüm geri yüklemelerle rekabet ediyor olursunuz. Ayrıca, DR bölgesindeki yeni elastik havuz oluşturulmadan kiracı veritabanlarının kurtarılması başlatılamaz.

2\. Senaryo Katmanlı hizmetle olgun uygulama

Deneme müşterileri ve ödeme yapan müşteriler için katmanlı hizmet tekliflerine ve farklı SLA'lara sahip olgun bir SaaS uygulamasıyım. Deneme müşterileri için maliyeti mümkün olduğunca azaltmam gerekiyor. Deneme müşterileri kapalı kalma süresi alabilir ancak olasılığını azaltmak istiyorum. Ödeme yapan müşteriler için kapalı kalma süreleri uçuş riski taşır. Bu nedenle, ödeme yapan müşterilerin verilerine her zaman erişebildiğinden emin olmak istiyorum.

Bu senaryoyu desteklemek için, deneme kiracılarını ayrı elastik havuzlara yerleştirerek ücretli kiracılardan ayırın. Deneme müşterileri kiracı başına daha düşük eDTU veya sanal çekirdeklere ve daha uzun kurtarma süresiyle daha düşük SLA'ya sahiptir. Ödeme yapan müşteriler, kiracı başına daha yüksek eDTU veya sanal çekirdek ve daha yüksek bir SLA içeren bir havuzdadır. En düşük kurtarma süresini garanti etmek için, ödeme yapan müşterilerin kiracı veritabanları coğrafi olarak çoğaltılır. Bu yapılandırma bir sonraki diyagramda gösterilmiştir.

İlk senaryoda olduğu gibi yönetim veritabanları oldukça etkindir, bu nedenle bunun için coğrafi olarak çoğaltılmış tek bir veritabanı kullanırsınız (1). Bu, yeni müşteri abonelikleri, profil güncelleştirmeleri ve diğer yönetim işlemleri için öngörülebilir performans sağlar. Yönetim veritabanlarının birincillerinin bulunduğu bölge birincil bölge, yönetim veritabanlarının ikincillerinin bulunduğu bölge ise DR bölgesidir.

Ödeme yapan müşterilerin kiracı veritabanları, birincil bölgede sağlanan ücretli havuzda etkin veritabanlarına sahiptir. DR bölgesinde aynı ada sahip ikincil bir havuz sağlayın. Her kiracı ikincil havuza coğrafi olarak çoğaltılır (2). Bu, yük devretme kullanarak tüm kiracı veritabanlarının hızlı kurtarılmasını sağlar.

Birincil bölgede bir kesinti oluşursa, uygulamanızı çevrimiçine getirme kurtarma adımları sonraki diyagramda gösterilmiştir:

• Yönetim veritabanlarının yükünü hemen DR bölgesine (3) devredin.
• Uygulamanın bağlantı dizesi DR bölgesine işaret etmek için değiştirin. Artık tüm yeni hesaplar ve kiracı veritabanları DR bölgesinde oluşturulur. Mevcut deneme müşterileri verilerinin geçici olarak kullanılamadiğini görür.
• Ücretli kiracı veritabanlarının kullanılabilirliğini hemen geri yüklemek için DR bölgesindeki havuza yük devretme (4). Yük devretme hızlı bir meta veri düzeyi değişikliği olduğundan, tek tek yük devretmelerin son kullanıcı bağlantıları tarafından isteğe bağlı olarak tetiklendiği bir iyileştirmeyi göz önünde bulundurun.
• İkincil havuz eDTU boyutunuz veya sanal çekirdek değeriniz birincilden düşükse çünkü ikincil veritabanları yalnızca ikincil oldukları sırada değişiklik günlüklerini işlemek için kapasite gerektiriyorsa, tüm kiracıların (5) tam iş yükünü barındırmak için havuz kapasitesini hemen artırın.
• Deneme müşterilerinin veritabanları için DR bölgesinde aynı ada ve aynı yapılandırmaya sahip yeni elastik havuzu oluşturun (6).
• Deneme müşterilerinin havuzu oluşturulduktan sonra, tek tek deneme kiracısı veritabanlarını yeni havuza (7) geri yüklemek için coğrafi geri yüklemeyi kullanın. Son kullanıcı bağlantıları tarafından tek tek geri yüklemeleri tetikleme veya uygulamaya özgü başka bir öncelik düzeni kullanmayı göz önünde bulundurun.

Bu noktada uygulamanız DR bölgesinde yeniden çevrimiçidir. Tüm ücretli müşteriler verilerine erişebilirken, deneme müşterileri verilerine erişirken gecikme yaşar.

Uygulamayı DR bölgesine geri yükledikten sonra birincil bölge Azure tarafından kurtarıldığında, uygulamayı o bölgede çalıştırmaya devam edebilir veya birincil bölgeye yeniden çalışmaya karar vekleyebilirsiniz. Yük devretme işlemi tamamlanmadan önce birincil bölge kurtarılırsa, hemen yeniden başarısız olun. Yeniden çalışma, sonraki diyagramda gösterilen adımları uygular:

• Tüm bekleyen coğrafi geri yükleme isteklerini iptal edin.
• Yönetim veritabanlarında yük devretme (8). Bölge kurtarıldıktan sonra, eski birincil otomatik olarak ikincil olur. Şimdi tekrar birincil haline geliyor.
• Ücretli kiracı veritabanlarında yük devretme (9). Benzer şekilde, bölgenin kurtarılmasından sonra eski birinciller otomatik olarak ikincil hale gelir. Şimdi tekrar birinciller haline gelirler.
• DR bölgesinde değiştirilmiş geri yüklenen deneme veritabanlarını salt okunur (10) olarak ayarlayın.
• Kurtarmadan sonra değişen deneme müşterileri DR havuzundaki her veritabanı için, deneme müşterileri birincil havuzundaki ilgili veritabanını yeniden adlandırın veya silin (11).
• Güncelleştirilmiş veritabanlarını DR havuzundan birincil havuza (12) kopyalayın.
• DR havuzunu silin (13).

Avantaj

Bu stratejinin temel avantajı, ödeme yapan müşteriler için en yüksek SLA'yı sağlamasıdır. Ayrıca, deneme DR havuzu oluşturulur oluşturulmaz yeni denemelerin engelinin kaldırıldığını garanti eder.

Denge

Bunun dezavantajı, bu kurulumun kiracı veritabanlarının toplam maliyetini ücretli müşteriler için ikincil DR havuzunun maliyetine göre artırmasıdır. Ayrıca, ikincil havuzun boyutu farklıysa, dr bölgesindeki havuz yükseltmesi tamamlanana kadar yük devretme sonrasında ödeme yapan müşteriler daha düşük performansla karşılaşır.

Senaryo 3. Katmanlı hizmet ile coğrafi olarak dağıtılmış uygulama

Katmanlı hizmet tekliflerine sahip olgun bir SaaS uygulamam var. Ücretli müşterilerime çok agresif bir SLA sunmak ve kesintiler oluştuğunda etki riskini en aza indirmek istiyorum çünkü kısa bir kesinti bile müşterinin memnuniyetsiz olmasına neden olabilir. Ödeme yapan müşterilerin verilerine her zaman erişebilmesi kritik önem taşır. Denemeler ücretsizdir ve deneme süresi boyunca SLA sunulmaz.

Bu senaryoya destek olmak için üç ayrı elastik havuz kullanın. Ücretli müşterilerin kiracı veritabanlarını içerecek şekilde iki farklı bölgede veritabanı başına yüksek eDTU veya sanal çekirdek içeren iki eşit boyutlu havuz sağlayın. Deneme kiracılarını içeren üçüncü havuz, veritabanı başına daha düşük eDTU'lara veya sanal çekirdeklere sahip olabilir ve iki bölgeden birinde sağlanabilir.

Kesintiler sırasında en düşük kurtarma süresini garanti etmek için, ödeme yapan müşterilerin kiracı veritabanları iki bölgenin her birinde birincil veritabanlarının %50'siyle coğrafi olarak çoğaltılır. Benzer şekilde, her bölge ikincil veritabanlarının %50'sine sahiptir. Bu şekilde, bir bölge çevrimdışıysa, ücretli müşterilerin veritabanlarının yalnızca %50'sini etkiler ve yük devretme yapmak zorunda olur. Diğer veritabanları olduğu gibi kalır. Bu yapılandırma aşağıdaki diyagramda gösterilmiştir:

Önceki senaryolarda olduğu gibi, yönetim veritabanları oldukça etkindir, bu nedenle bunları tek coğrafi olarak çoğaltılmış veritabanları (1) olarak yapılandırın. Bu, yeni müşteri aboneliklerinin, profil güncelleştirmelerinin ve diğer yönetim işlemlerinin öngörülebilir performansını sağlar. Bölge A, yönetim veritabanlarının birincil bölgesidir ve B bölgesi yönetim veritabanlarının kurtarılması için kullanılır.

Ödeme yapan müşterilerin kiracı veritabanları da coğrafi olarak çoğaltılır, ancak birinciller ve ikinciller A bölgesi ile B bölgesi (2) arasında bölünür. Bu şekilde, kesintiden etkilenen kiracı birincil veritabanları diğer bölgeye yük devredebilir ve kullanılabilir hale gelebilir. Kiracı veritabanlarının diğer yarısı hiç etkilenmez.

Sonraki diyagramda, A bölgesinde bir kesinti oluşursa atılması gereken kurtarma adımları gösterilmektedir.

• Yönetim veritabanlarının B bölgesine (3) hemen yük devretmesi.
• B bölgesindeki yönetim veritabanlarına işaret etmek için uygulamanın bağlantı dizesi değiştirin. Yeni hesapların ve kiracı veritabanlarının B bölgesinde oluşturulduğundan ve mevcut kiracı veritabanlarının da orada bulunduğundan emin olmak için yönetim veritabanlarını değiştirin. Mevcut deneme müşterileri verilerinin geçici olarak kullanılamadiğini görür.
• Ücretli kiracı veritabanlarının kullanılabilirliğini hemen geri yüklemek için B bölgesindeki havuz 2'ye yük devretme (4). Yük devretme hızlı bir meta veri düzeyi değişikliği olduğundan, tek tek yük devretmelerin son kullanıcı bağlantıları tarafından isteğe bağlı olarak tetiklendiği bir iyileştirmeyi düşünebilirsiniz.
• Artık havuz 2 yalnızca birincil veritabanları içerdiğinden havuzdaki toplam iş yükü artar ve eDTU boyutunu (5) veya sanal çekirdek sayısını hemen artırabilir.
• Deneme müşterilerinin veritabanları için B bölgesinde aynı ada ve aynı yapılandırmaya sahip yeni elastik havuzu oluşturun (6).
• Havuz oluşturulduktan sonra, tek tek deneme kiracı veritabanını havuza geri yüklemek için coğrafi geri yükleme kullanın (7). Tek tek geri yüklemeleri son kullanıcı bağlantıları tarafından tetikleyebilir veya uygulamaya özgü başka bir öncelik şeması kullanabilirsiniz.

Bu noktada uygulamanız B bölgesinde yeniden çevrimiçidir. Tüm ücretli müşteriler verilerine erişebilirken, deneme müşterileri verilerine erişirken gecikme yaşar.

A bölgesi kurtarıldığında, deneme müşterileri için B bölgesini mi kullanmak yoksa A bölgesindeki deneme müşterileri havuzunu kullanmak için yeniden çalışma mı istediğinize karar vermeniz gerekir. Ölçütlerden biri, kurtarmadan bu yana değiştirilen deneme kiracısı veritabanlarının yüzdesi olabilir. Bu karardan bağımsız olarak, ücretli kiracıları iki havuz arasında yeniden dengelemeniz gerekir. Sonraki diyagramda, deneme kiracısı veritabanlarının A bölgesine geri dönme işlemi gösterilmektedir.

• Deneme DR havuzuna tüm bekleyen coğrafi geri yükleme isteklerini iptal edin.
• Yönetim veritabanının yük devretmesi (8). Bölgenin kurtarılmasından sonra, eski birincil otomatik olarak ikincil olur. Şimdi tekrar birincil haline geliyor.
• Hangi ücretli kiracı veritabanlarının havuz 1'e geri yük devredeceklerini seçin ve ikincillerine yük devretme (9) başlatın. Bölgenin kurtarılmasından sonra havuz 1'deki tüm veritabanları otomatik olarak ikincil hale geldi. Şimdi bunların %50'si tekrar birincil olacak.
• Havuz 2'nin boyutunu özgün eDTU'ya (10) veya sanal çekirdek sayısına küçültün.
• B bölgesindeki tüm geri yüklenen deneme veritabanlarını salt okunur (11) olarak ayarlayın.
• Kurtarmadan sonra değişen deneme DR havuzundaki her veritabanı için, deneme birincil havuzundaki ilgili veritabanını yeniden adlandırın veya silin (12).
• Güncelleştirilmiş veritabanlarını DR havuzundan birincil havuza (13) kopyalayın.
• DR havuzunu silin (14).

Avantaj

Bu stratejinin temel avantajları şunlardır:

• Kiracı veritabanlarının %50'sinden fazlasını etkileyemeyen bir kesinti olduğundan, ödeme yapan müşteriler için en agresif SLA'yı destekler.
• Kurtarma sırasında iz DR havuzu oluşturulur oluşturulmaz yeni denemelerin engelinin kaldırılmasını garanti eder.
• Havuz 1 ve havuz 2'deki ikincil veritabanlarının %50'sinin birincil veritabanlarından daha az etkin olacağı garanti olduğundan havuz kapasitesinin daha verimli kullanılmasına olanak tanır.

Dengelemeler

Başlıca dengeler şunlardır:

• Yönetim veritabanlarına yönelik CRUD işlemleri, A bölgesine bağlı son kullanıcılar için, yönetim veritabanlarının birincil veritabanında yürütülürken B bölgesine bağlı son kullanıcılardan daha düşük gecikme süresine sahiptir.
• Yönetim veritabanının daha karmaşık bir tasarımını gerektirir. Örneğin, her kiracı kaydının yük devretme ve yeniden çalışma sırasında değiştirilmesi gereken bir konum etiketi vardır.
• Ödeme yapan müşteriler, B bölgesindeki havuz yükseltmesi tamamlanana kadar normalden daha düşük performansla karşılaşabilir.

Özet

Bu makalede, SaaS ISV çok kiracılı bir uygulama tarafından kullanılan veritabanı katmanı için olağanüstü durum kurtarma stratejilerine odaklanılır. Seçtiğiniz strateji, iş modeli, müşterilerinize sunmak istediğiniz SLA, bütçe kısıtlaması vb. gibi uygulamanın gereksinimlerini temel alır. Açıklanan her strateji, bilinçli bir karar alabilmeniz için avantajları ve takası özetler. Ayrıca, belirli uygulamanız büyük olasılıkla diğer Azure bileşenlerini de içerir. Bu nedenle, iş sürekliliği kılavuzlarını gözden geçirir ve veritabanı katmanının kurtarılmasını onlarla birlikte düzenlersiniz. Azure'da veritabanı uygulamalarının kurtarılmasını yönetme hakkında daha fazla bilgi edinmek için bkz . Olağanüstü durum kurtarma için bulut çözümleri tasarlama.

Sonraki adımlar

• Azure SQL Veritabanı otomatik yedeklemeler hakkında bilgi edinmek için bkz. otomatik yedeklemeleri Azure SQL Veritabanı.
• İş sürekliliğine genel bakış ve senaryolar için bkz . İş sürekliliğine genel bakış.
• Kurtarma için otomatik yedeklemeleri kullanma hakkında bilgi edinmek için bkz . Hizmet tarafından başlatılan yedeklemelerden veritabanını geri yükleme.
• Daha hızlı kurtarma seçenekleri hakkında bilgi edinmek için bkz . Etkin coğrafi çoğaltma ve Yük Devretme grupları.
• Arşivleme için otomatik yedeklemeleri kullanma hakkında bilgi edinmek için bkz . veritabanı kopyası.