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

ŞUNUN İÇİN GEÇERLİDİR: Azure SQL Database

Azure SQL Veritabanı ile bulut hizmetleri oluşturma ve dağıtma sırasında, bölgesel kesintilere ve yıkıcı hatalara karşı daha fazla destek sağlamak için etkin coğrafi çoğaltma veya otomatik 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 sağlar. Bu makalede, her seçeneğin avantajları ve avantajları dahil olmak üzere yaygın uygulama desenleri ele almaktadır.

Not

Premium veya İş Açısından Kritik veritabanlarını ve elastik havuzları kullanıyorsanız, bölgesel kesintilere karşı esnek hale dönüştürerek bunları bölgesel olarak yedekli dağıtım yapılandırmasına dönüştürebilirsiniz. Bkz. Alan yedekli veritabanları.

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

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

  • Uygulama bir Azure bölgesinde etkin
  • Tüm veritabanı oturumları için verilere okuma ve yazma erişimi (RW) gerekir
  • Gecikme süresini ve trafik maliyetini azaltmak için web katmanı ve veri katmanı birlikte bulunduruldu
  • Temelde 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 gereken 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österilmiştir. Coğrafi yedeklilik için uygulamanın kaynakları A ve B Bölgesi'ne dağıtılır. Ancak A Bölgesi başarısız olana kadar B Bölgesi'nde kaynaklar kullanılır. Veritabanı bağlantısını, çoğaltmayı ve yük devretmeyi yönetmek için iki bölge arasında bir yük devretme grubu yapılandırılır. Her iki bölgede de web hizmeti, .database.windows.net (1) okuma-yazma dinleyicisi yük devretme grubu < adı aracılığıyla > veritabanına erişacak şekilde yapılandırılmıştır. Azure Traffic Manager yönlendirme yöntemini (2) kullanmak üzere ayarlanır.

Not

Azure Traffic Manager makale boyunca yalnızca çizim amacıyla kullanılır. Öncelikli yönlendirme yöntemini destekleyen herhangi bir yük dengeleme çözümünü kullanabilirsiniz.

Aşağıdaki diyagramda, kesinti öncesinde bu yapılandırmayı gösterir:

Senaryo 1. Kesintiden önce yapılandırma.

Birincil bölgedeki bir kesintinin ardından SQL Veritabanı, birincil veritabanının erişilebilir olmadığını algılar ve otomatik yük devretme ilkesi (1) parametrelerine göre ikincil bölgeye yük devretmeyi tetikler. Uygulama SLA'nıza bağlı olarak, kesintinin algılanması ile yük devretmenin kendisi arasındaki zamanı kontrol eden bir yetkisiz kullanım süresi yapılandırabilirsiniz. Yük devretme Azure Traffic Manager veritabanının yük devretmeyi tetiklemeden önce uç nokta yük devretmeyi başlatması mümkündür. Bu durumda web uygulaması veritabanına hemen yeniden bağlanamaz. Ancak veritabanı yük devretmesi tamamlandıktan hemen sonra yeniden bağlanmalar otomatik olarak başarılı olur. Başarısız olan bölge geri yüklenir ve 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österilmiştir.

Not

Yeniden bağlantı sırasında yük devretmeden sonra işlenen tüm işlemler kaybolur. Yük devretme tamamlandıktan sonra B bölgesinde yer alan uygulama, kullanıcı isteklerini işlemeye yeniden bağlanıp yeniden başlatabilirsiniz. Hem web uygulaması hem de birincil veritabanı artık B bölgesindedir ve birlikte bulunur.

Senaryo 1. Yük devretmeden sonra yapılandırma

B bölgesinde bir kesinti olursa, birincil veritabanı ile 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 bozuk olduğunu 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ı açığa çıkar ve bu nedenle A bölgesi artarak başarısız olursa veri kaybı riski daha yüksek olur.

Not

Olağanüstü durum kurtarma için, iki bölgeyle sınırlı uygulama dağıtımıyla yapılandırmayı öneririz. Bunun nedeni, Azure coğrafyalarının çoğunun yalnızca iki bölgesi vardır. Bu yapılandırma, her iki bölgede de aynı anda yıkıcı hatalara karşı uygulamalarınızı korumaz. Böyle bir hatanın olası bir durumunda, coğrafi geri yükleme işlemi kullanarak üçüncü bir bölgedeki veritabanlarınızı kurtarabilirsiniz.

Kesinti azaltıldıktan sonra ikincil veritabanı birincil veritabanıyla otomatik olarak yeniden eşitlenir. Eşitleme sırasında birincilin performansı etki olabilir. Bu etki, yük devretmeden sonra yeni birincilin elde edilen veri miktarına bağlıdır.

Not

Kesinti azaltıldıktan sonra, Traffic Manager bölge A'daki uygulamaya daha yüksek öncelikli bir uç nokta olarak bağlantıları yönlendirmeye başlar. Birincil bölgeyi B bölgesinde bir süre tutmak için Trafic Manager profilinde öncelik tabloyu uygun şekilde değiştirebilirsiniz.

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

Senaryo 1. İkincil bölgede bir kesintiden sonra yapılandırma.

Bu tasarım deseninin temel avantajları:

  • 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ğu için uygulama performansı yük devretmeden etkilenmez.

Burada önemli olan, B Bölgesi'nde uygulama kaynaklarının çoğu zaman az kullanılan kaynaklar olduğudı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 kaynaklansa son çare olarak kullanılabilir.
  • Uygulama, işlemlerin salt okunur ve okuma-yazma modlarını destekler ve bir süre "salt okunur modda" çalışır.

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

Aşağıdaki diyagramda bir kesinti öncesinde bu yapılandırmanın nasıl olduğu göstermektedir:

Senaryo 2. Kesintiden önce yapılandırma.

A Traffic Manager bağlantı hatası algılayan kullanıcılar, kullanıcı trafiğini otomatik olarak B bölgesinde uygulama örneğine iletir. Bu düzende, veri kaybıyla birlikte yetkisiz kullanım süresi değerini yeterince yüksek bir değere (örneğin 24 saat) ayarlamanız önemlidir. Kesinti bu süre içinde azaltıldı ise veri kaybının önlenmesini sağlar. B bölgesinde 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. Kesintinin nedeni yıkıcı bir hata ise, büyük olasılıkla yetkisiz kullanım süresi içinde azaltılamayr. Süresi dolduğunda yük devretme grubu yük devretmeyi tetikler. Bundan sonra okuma-yazma dinleyicisi kullanılabilir duruma gelir ve bu dinleyiciye bağlantılar başarısız olur (2). Aşağıdaki diyagram, kurtarma işleminin iki aşamalarını gösterir.

Not

Birincil bölgedeki kesinti yetkisiz kullanım süresi içinde azaltıldısa Traffic Manager birincil bölgedeki bağlantının geri yüklemesi algılanabilir ve kullanıcı trafiği A bölgesinde uygulama örneğine geri döner. Bu uygulama örneği, önceki diyagramda gösterildiği gibi A bölgesinde birincil veritabanını kullanarak okuma-yazma modunda devam eder ve çalışır.

Senaryo 2. Olağanüstü durum kurtarma aşamaları.

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üş olduğunu (1) işaretler. Bu sırada yük devretme grubu salt okunur dinleyiciyi A (2) bölgesi olarak değiştirmiştir. Bu kesinti son kullanıcı deneyimini etkilemez ancak kesinti sırasında birincil veritabanı ortaya çıkar. Aşağıdaki diyagramda ikincil bölgedeki bir hata gösterildiği gibi:

Senaryo 2. İkincil bölgede kesinti.

Kesinti azaltıldığında ikincil veritabanı birincil veritabanıyla hemen eşitlenir ve salt okunur dinleyici B bölgesinde ikincil veritabanına geri döner. Eşitlenmesi gereken veri miktarına bağlı olarak birincilin eşitleme performansı biraz etkilenecektir.

Bu tasarım deseninin çeşitli avantajları vardır:

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

Bu, uygulamanın salt okunur modda çalışabilecek olmasıdır.

Senaryo 3: Uygulamanın veri kaybı olmadan ve kapalı kalma süresi sıfıra yakın bir şekilde farklı bir coğrafyaya yeniden konumlandırması

Bu senaryoda uygulama aşağıdaki özelliklere sahiptir:

  • Son kullanıcılar uygulamaya farklı coğrafyalardan erişiyor
  • Uygulama, en son güncelleştirmelerle tam eşitlemeye bağımlı olmayan salt okunur iş yükleri içerir
  • Kullanıcıların çoğu için aynı coğrafyada verilere yazma erişimi desteklendir
  • Okuma gecikmesi son kullanıcı deneyimi için kritik öneme sahiptir

Bu gereksinimleri karşılamak için kullanıcı aygıtının her zaman aynı coğrafyada dağıtılmış olan uygulamaya (örneğin, göz atma verileri, analizler vb.) bağlanacaklarını garanti altına alamanız gerekir. OLTP işlemleri çoğu zaman aynı coğrafyada işlenir. Örneğin, gün boyunca OLTP işlemleri aynı coğrafyada işlenir, ancak çalışma saatleri içinde farklı bir coğrafyada işlenebilir. Son Kullanıcı etkinliği çoğunlukla çalışma saatlerinde gerçekleşdiğinde, çoğu kullanıcının çoğu için en iyi performansı garanti edebilirsiniz. Aşağıdaki diyagramda bu topoloji gösterilmektedir.

Uygulamanın kaynakları, önemli kullanım talebi olan her bir Coğrafya üzerinde dağıtılmalıdır. Örneğin, uygulamanız Birleşik Devletler etkin olarak kullanılıyorsa, Avrupa Birliği ve Güney Doğu Asya, uygulamanın tüm bu coğrafi ormallara dağıtılması gerekir. Birincil veritabanı, çalışma saatlerinin sonunda bir Coğrafya 'dan bir sonrakine dinamik olarak yerleştirilmelidir. Bu yöntem "Güneş izle" olarak adlandırılır. OLTP iş yükü, her zaman okuma-yazma dinleyicisi < yük devretmesi-grup-adı > . Database.Windows.net (1) yoluyla veritabanına bağlanır. Salt okuma iş yükü, veritabanı sunucusu uç nokta < sunucusu-adı > . Database.Windows.net (2) kullanarak doğrudan yerel veritabanına bağlanır. Traffic Manager, performans yönlendirme yöntemiyleyapılandırılır. Son Kullanıcı cihazının en yakın bölgede Web hizmetine bağlı olmasını sağlar. Traffic Manager her Web hizmeti uç noktası (3) için uç nokta izleme etkinleştirilmiş olarak ayarlanmalıdır.

Not

Yük devretme grubu yapılandırması, yük devretme için hangi bölgenin kullanıldığını tanımlar. Yeni birincil konum farklı bir Coğrafya içinde olduğundan, etkilenen bölge yeniden çevrimiçi olana kadar hem OLTP hem de salt okuma iş yükleri için yük devretme sonuçları daha uzun gecikme süresine sahiptir.

Senaryo 3. Doğu ABD birincil ile yapılandırma.

Günün sonunda, örneğin 11 PM yerel saatinde, etkin veritabanlarının bir sonraki bölgeye (Kuzey Avrupa) geçiş yapılmalıdır. Bu görev, Azure Logic Appskullanılarak tamamen otomatikleştirilebilir. Görev aşağıdaki adımları içerir:

  • Kolay yük devretme (1) kullanarak Kuzey Avrupa yük devretme grubundaki birincil sunucuyu değiştirin
  • Doğu ABD ve Kuzey Avrupa arasında yük devretme grubunu kaldırma
  • Aynı ada sahip ancak Kuzey Avrupa ve Doğu Asya (2) arasında yeni bir yük devretme grubu oluşturun.
  • Bu yük devretme grubuna (3) Doğu Asya Kuzey Avrupa birincili ve ikincil öğesine ekleyin.

Aşağıdaki diyagramda, planlı yük devretmenin ardından yeni yapılandırma gösterilmektedir:

Senaryo 3. Birincil Kuzey Avrupa geçişi yapılıyor.

Örneğin Kuzey Avrupa bir kesinti olursa, otomatik veritabanı yük devretmesi yük devretme grubu tarafından başlatılır ve bu, uygulamayı zamanlamanın (1) bir sonraki bölgesine taşımaya etkili bir şekilde neden olur. Bu durumda, Kuzey Avrupa yeniden çevrimiçi olana kadar ABD Doğu kalan tek ikincil bölgedir. Kalan iki bölge, roller arasında geçiş yaparak müşterileri üç coğrafi bölgede sunar. Azure Logic Apps uygun şekilde ayarlanmalıdır. Kalan bölgelerde Avrupa 'dan ek Kullanıcı trafiği alındığından, uygulamanın performansı yalnızca ek gecikme süresi ve ayrıca daha fazla sayıda Son Kullanıcı bağlantısı tarafından etkilenmez. Kesinti Kuzey Avrupa bir kez azaltıldıktan sonra, ikincil veritabanı geçerli birincil ile hemen eşitlenir. Aşağıdaki diyagramda Kuzey Avrupa bir kesinti gösterilmektedir:

Senaryo 3. Kuzey Avrupa kesinti.

Not

Son kullanıcının Avrupa 'daki deneyiminin uzun gecikme süresine göre düştüğü süreyi azaltabilirsiniz. Bunu yapmak için, bir uygulama kopyasını önceden dağıtmanız ve ikincil veritabanlarını başka bir yerel bölgede (Batı Avrupa) oluşturmanız gerekir ve Kuzey Avrupa çevrimdışı uygulama örneğinin yerini alır. İkincisi yeniden çevrimiçi olduğunda, Batı Avrupa kullanmaya devam edilip edilmeyeceğini ya da uygulamanın kopyasını kaldırıp Kuzey Avrupa kullanmaya geri dönmek için karar verebilirsiniz.

Bu tasarımın başlıca avantajları şunlardır:

  • Salt okuma uygulama iş yükü, verileri her zaman ve alt kümeler bölgesinde erişir.
  • Okuma-yazma uygulaması iş yükü, her Coğrafya 'daki en yüksek Etkinliğin süresi boyunca en yakın bölgedeki verilere erişir
  • Uygulama birden çok bölgeye dağıtıldığından, önemli kapalı kalma süresi olmadan bölgelerden birinin kaybedilmesi devam edebilir.

Ancak bazı dengeler vardır:

  • Bölgesel bir kesinti, Coğrafya 'nın daha uzun bir gecikmeyle etkilenmesine neden olur. Okuma-yazma ve salt okuma iş yükleri, uygulama tarafından farklı bir Coğrafya içinde sunulur.
  • Salt okuma iş yükleri her bölgede farklı bir uç noktasına bağlanmalıdır.

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

Özel bulut olağanüstü durum kurtarma stratejiniz, uygulamanızın ihtiyaçlarını en iyi şekilde karşılayacak şekilde bu tasarım düzenlerini birleştirebilir veya genişletebilir. Daha önce belirtildiği gibi, seçtiğiniz strateji müşterilerinize ve uygulama dağıtım topolojisine sunmak istediğiniz SLA 'yı temel alır. Kararmanıza yardımcı olmak için aşağıdaki tabloda, kurtarma noktası hedefi (RPO) ve tahmini kurtarma süresi (ERT) temelinde seçimler karşılaştırılmaktadır.

Desen RPO 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 zamanı + DNS TTL
Uygulama yük dengelemesi için etkin-etkin dağıtım Okuma-yazma erişimi < 5 sn Hata algılama zamanı + DNS TTL
Etkin-Pasif dağıtım veri koruma Salt okuma erişimi < 5 sn Salt okuma erişimi = 0
Okuma-yazma erişimi = sıfır Okuma-yazma erişimi = hata algılama süresi + yetkisiz kullanım süresi veri kaybı

Sonraki adımlar