Azure SQL Veritabanı kullanarak genel olarak kullanılabilir hizmetler tasarlama

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

Azure SQL Veritabanı ile bulut hizmetleri oluştururken ve dağıtırken, bölgesel kesintilere ve yıkıcı hatalara dayanıklılık sağlamak için etkin coğrafi çoğaltma veya yük devretme gruplarını kullanırsınız. Aynı özellik, verilere yerel erişim için iyileştirilmiş genel olarak dağıtılmış uygulamalar oluşturmanıza olanak tanır. Bu makalede, her bir seçeneğin avantajları ve avantajları da dahil olmak üzere yaygın uygulama desenleri ele alınmaktadır.

Dekont

Premium veya İş Açısından Kritik veritabanlarını ve elastik havuzları kullanıyorsanız, bunları alanlar arası yedekli dağıtım yapılandırmasına dönüştürerek bölgesel kesintilere dayanıklı hale getirebilirsiniz. Bkz . Alanlar arası yedekli veritabanları.

Senaryo 1: İş sürekliliği için en az kapalı kalma süresiyle iki Azure bölgesi kullanma

Bu senaryoda, uygulamalar aşağıdaki özelliklere sahiptir:

• Uygulama tek bir Azure bölgesinde etkin
• Tüm veritabanı oturumlarında verilere okuma ve yazma erişimi (RW) gerekir
• Gecikme süresini ve trafik maliyetini azaltmak için web katmanı ve veri katmanı birlikte bulunmalıdır
• Temel olarak, kapalı kalma süresi bu uygulamalar için veri kaybından daha yüksek bir iş riskidir

Bu durumda, tüm uygulama bileşenlerinin birlikte yük devretmesi gerektiğinde bölgesel olağanüstü durumların işlenmesi için uygulama dağıtım topolojisi iyileştirilmiştir. Aşağıdaki diyagramda bu topoloji gösterilmektedir. Coğrafi yedeklilik için uygulamanın kaynakları A ve B Bölgesine dağıtılır. Ancak, Bölge B'deki kaynaklar A Bölgesi başarısız olana kadar kullanılmaz. İki bölge arasında veritabanı bağlantısını, çoğaltmayı ve yük devretmeyi yönetmek için bir yük devretme grubu yapılandırılır. Her iki bölgede de web hizmeti, okuma-yazma dinleyicisi <failover-group-name.database.windows.net> (1) aracılığıyla veritabanına erişecek şekilde yapılandırılır. Azure Traffic Manager, öncelik yönlendirme yöntemini (2) kullanacak şekilde ayarlanır.  

Dekont

Azure Traffic Manager , bu makalenin genelinde yalnızca çizim amacıyla kullanılır. Öncelik yönlendirme yöntemini destekleyen herhangi bir yük dengeleme çözümünü kullanabilirsiniz.

Aşağıdaki diyagramda kesintiden önce bu yapılandırma gösterilmektedir:

Birincil bölgede bir kesintiden sonra, SQL Veritabanı birincil veritabanının erişilebilir olmadığını algılar ve otomatik yük devretme ilkesinin (1) parametrelerine göre ikincil bölgeye yük devretmeyi tetikler. Uygulama SLA'nıza bağlı olarak, kesintinin algılanmasıyla yük devretmenin kendisi arasındaki süreyi denetleyebilen bir yetkisiz kullanım süresi yapılandırabilirsiniz. Yük devretme grubu veritabanının yük devretmesini tetiklemeden önce Azure Traffic Manager'ın uç nokta yük devretmesini başlatması mümkündür. Bu durumda web uygulaması veritabanına hemen yeniden bağlanamaz. Ancak veritabanı yük devretmesi tamamlanır tamamlanmaz yeniden bağlantılar otomatik olarak başarılı olur. Başarısız olan bölge geri yüklenip yeniden çevrimiçi olduğunda, eski birincil otomatik olarak yeni bir ikincil olarak yeniden bağlanır. Aşağıdaki diyagramda yük devretme sonrasındaki yapılandırma gösterilmektedir.

Dekont

Yük devretmeden sonra işlenen tüm işlemler yeniden bağlanma sırasında kaybolur. Yük devretme tamamlandıktan sonra, B bölgesindeki uygulama kullanıcı isteklerini işlemeye yeniden bağlanabilir ve yeniden başlatabilir. Hem web uygulaması hem de birincil veritabanı artık B bölgesindedir ve birlikte konumlandırılır.

B bölgesinde bir kesinti oluşursa, birincil ve ikincil veritabanı arasındaki çoğaltma işlemi askıya alınır, ancak ikisi arasındaki bağlantı değişmeden kalır (1). Traffic Manager, B Bölgesi bağlantısının kesildiğini algılar ve uç nokta web uygulaması 2'yi Düzeyi Düşürülmüş (2) olarak işaretler. Bu durumda uygulamanın performansı etkilenmez, ancak veritabanı kullanıma sunulur ve bu nedenle A bölgesinin ardı ardına başarısız olması durumunda veri kaybı riski daha yüksek olur.

Dekont

Olağanüstü durum kurtarma için, uygulama dağıtımının iki bölgeyle sınırlı olduğu yapılandırmayı öneririz. Bunun nedeni Azure coğrafyalarının çoğunun yalnızca iki bölgeye sahip olmasıdır. Bu yapılandırma, uygulamanızı her iki bölgenin de aynı anda yıkıcı bir hataya karşı korumaz. Böyle bir hatayla ilgili olası olmayan bir durumda, coğrafi geri yükleme işlemini kullanarak üçüncü bir bölgedeki veritabanlarınızı kurtarabilirsiniz. Daha fazla bilgi için bkz. Azure SQL Veritabanı olağanüstü durum kurtarma kılavuzu.

Kesinti azaltıldıktan sonra ikincil veritabanı otomatik olarak birincil veritabanıyla yeniden eşitler. Eşitleme sırasında birincilin performansı etkilenebilir. Belirli bir etki, yeni birincil sunucunun yük devretmeden sonra aldığı veri miktarına bağlıdır.

Dekont

Kesinti azaltıldıktan sonra Traffic Manager, A Bölgesi'ndeki uygulamaya bağlantıları daha yüksek öncelikli bir uç nokta olarak yönlendirmeye başlar. Birincil değeri B Bölgesinde bir süre tutmak istiyorsanız Traffic Manager profilindeki öncelik tablosunu buna göre değiştirmeniz gerekir.

Aşağıdaki diyagramda ikincil bölgedeki bir kesinti gösterilmektedir:

Bu tasarım deseninin temel avantajları şunlardır:

• Aynı web uygulaması bölgeye özgü yapılandırma olmadan her iki bölgeye de dağıtılır ve yük devretmeyi yönetmek için ek mantık gerektirmez.
• Web uygulaması ve veritabanı her zaman birlikte bulunduğundan uygulama performansı yük devretmeden etkilenmez.

Temel dezavantaj , B Bölgesi'ndeki uygulama kaynaklarının çoğu zaman az kullanılıyor olmasıdır.

Senaryo 2: maksimum veri koruma ile iş sürekliliği için Azure bölgeleri

Bu seçenek, aşağıdaki özelliklere sahip uygulamalar için en uygun seçenektir:

• Herhangi bir veri kaybı yüksek iş riskidir. Veritabanı yük devretmesi yalnızca kesintinin yıkıcı bir hatadan kaynaklanması durumunda son çare olarak kullanılabilir.
• Uygulama, işlemlerin salt okunur ve okuma-yazma modlarını destekler ve bir süre için "salt okunur modda" çalışabilir.

Bu düzende, okuma-yazma bağlantıları zaman aşımı hataları almaya başladığında uygulama salt okunur moda geçer. Web uygulaması her iki bölgeye de dağıtılır ve okuma-yazma dinleyicisi uç noktasına bir bağlantı ve salt okunur dinleyici uç noktasına (1) farklı bir bağlantı içerir. Traffic Manager profili öncelik yönlendirmeyi kullanmalıdır. Her bölgedeki (2) uygulama uç noktası için uç nokta izleme etkinleştirilmelidir.

Aşağıdaki diyagramda kesintiden önce bu yapılandırma gösterilmektedir:

Traffic Manager, A bölgesine bağlantı hatası algıladığında, kullanıcı trafiğini otomatik olarak B bölgesindeki uygulama örneğine değiştirir. Bu düzende, veri kaybı olan yetkisiz kullanım süresini, örneğin 24 saat gibi yeterince yüksek bir değere ayarlamanız önemlidir. Bu süre içinde kesintinin azaltılması durumunda veri kaybının önlenmesini sağlar. B bölgesindeki web uygulaması etkinleştirildiğinde okuma-yazma işlemleri başarısız olur. Bu noktada salt okunur moda (1) geçmelidir. Bu modda istekler otomatik olarak ikincil veritabanına yönlendirilir. Kesinti yıkıcı bir hatadan kaynaklanıyorsa, büyük olasılıkla yetkisiz kullanım süresi içinde azaltılamaz. Süresi dolduğunda yük devretme grubu yük devretmeyi tetikler. Bundan sonra okuma-yazma dinleyicisi kullanılabilir duruma gelir ve bağlantı başarısız olur (2). Aşağıdaki diyagramda kurtarma işleminin iki aşaması gösterilmektedir.

Dekont

Birincil bölgedeki kesinti yetkisiz kullanım süresi içinde azaltılırsa Traffic Manager birincil bölgedeki bağlantının geri yüklenmesini algılar ve kullanıcı trafiğini A bölgesindeki uygulama örneğine geri götürür. Bu uygulama örneği, önceki diyagramda gösterildiği gibi A bölgesindeki birincil veritabanını kullanarak devam eder ve okuma-yazma modunda çalışır.

B bölgesinde bir kesinti olursa Traffic Manager, B bölgesinde web-app-2 uç noktasının başarısız olduğunu algılar ve düzeyi düşürülmüş (1) olarak işaretler. Bu arada yük devretme grubu salt okunur dinleyiciyi A bölgesine (2) değiştirir. Bu kesinti son kullanıcı deneyimini etkilemez, ancak birincil veritabanı kesinti sırasında kullanıma sunulur. Aşağıdaki diyagramda ikincil bölgedeki bir hata gösterilmektedir:

Kesinti giderildikten sonra, ikincil veritabanı birincil veritabanıyla hemen eşitlenir ve salt okunur dinleyici B bölgesindeki ikincil veritabanına geri döner. Eşitleme sırasında, eşitlenmesi gereken veri miktarına bağlı olarak birincil eşitleme performansı biraz etkilenebilir.

Bu tasarım düzeninin çeşitli avantajları vardır:

• Geçici kesintiler sırasında veri kaybını önler.
• Kapalı kalma süresi yalnızca Traffic Manager'ın yapılandırılabilir bağlantı hatasını ne kadar hızlı algıladığına bağlıdır.

Bunun dezavantajı , uygulamanın salt okunur modda çalışabilmesi gerektiğidir.

İş sürekliliği planlaması: Bulut olağanüstü durum kurtarma için bir uygulama tasarımı seçin

Özel bulut olağanüstü durum kurtarma stratejiniz, uygulamanızın gereksinimlerini en iyi şekilde karşılamak için bu tasarım desenlerini birleştirebilir veya genişletebilir. Daha önce belirtildiği gibi, seçtiğiniz strateji müşterilerinize sunmak istediğiniz SLA'yı ve uygulama dağıtımı topolojisini temel alır. Aşağıdaki tabloda, kararınızı yönlendirmeye yardımcı olmak için kurtarma noktası hedefine (RPO) ve tahmini kurtarma süresine (ERT) göre seçenekler karşılaştırılmaktadır.

Desen	KNH	ERT
Birlikte bulunan veritabanı erişimiyle olağanüstü durum kurtarma için etkin-pasif dağıtım	Okuma-yazma erişimi < 5 sn	Hata algılama süresi + DNS TTL
Uygulama yük dengelemesi için etkin-etkin dağıtım	Okuma-yazma erişimi < 5 sn	Hata algılama süresi + DNS TTL
Veri koruma için etkin-pasif dağıtım	Salt okunur erişim < 5 sn	Salt okunur erişim = 0
	Okuma-yazma erişimi = sıfır	Okuma-yazma erişimi = Hata algılama süresi + veri kaybıyla yetkisiz kullanım süresi

Sonraki adımlar

• İş sürekliliğine genel bakış ve senaryolar için bkz. İş sürekliliğine genel bakış
• Etkin coğrafi çoğaltma hakkında bilgi edinmek için bkz . Etkin coğrafi çoğaltma.
• Yük devretme grupları hakkında bilgi edinmek için bkz . Yük devretme grupları.
• Elastik havuzlarla etkin coğrafi çoğaltma hakkında bilgi için bkz . Elastik havuz olağanüstü durum kurtarma stratejileri.