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

  • Makale
  • Okumak için 9 dakika

Ş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şı bunları bölgesel olarak yedekli dağıtım yapılandırmasına dönüştürerek bunları esnek hale 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:

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

Birincil bölgedeki bir kesintiden sonra SQL Veritabanı birincil veritabanının erişilebilir olmadığını algılar ve otomatik yük devretme ilkesi parametrelerine göre ikincil bölgeye yük devretmeyi tetikler (1). 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ğlantı 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 devretme sonrasında 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.

1. Senaryo 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 azalttı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 kesintiler göstermektedir:

1. Senaryo İ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 idealdir:

  • 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 boyunca "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:

2. Senaryo 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 diyagramda kurtarma işleminin iki aşaması göstermektedir.

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.

2. Senaryo 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:

2. Senaryo İ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ğlana bir şekilde 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 saatleri içinde gerçekleşirse, kullanıcıların çoğu için en iyi performansın çoğu zaman garantisini veabilirsiniz. Aşağıdaki diyagram bu topolojiyi gösterir.

Uygulamanın kaynakları, önemli miktarda kullanım talebine sahip olduğunuz her coğrafyada dağıtılacaktır. Örneğin, uygulamanız Birleşik Devletler, Avrupa Birliği ve Güney Doğu Asya etkin bir şekilde kullanılıyorsa uygulamanın tüm bu coğrafyalara dağıtılması gerekir. Birincil veritabanı, çalışma saatlerinin sonunda dinamik olarak bir coğrafyadan bir sonrakine geç olmalıdır. Bu yöntem "güneşi takip et" olarak çağrılır. OLTP iş yükü veritabanına her zaman okuma-yazma dinleyicisi yük devretme < grubu-adı > .database.windows.net (1) aracılığıyla bağlanır. Salt okunur iş yükü, .database.windows.net (2) veritabanları sunucu uç noktası < sunucu adını kullanarak yerel > veritabanına doğrudan bağlanır. Traffic Manager, performans yönlendirme yöntemiyle yapılandırılır. Son kullanıcının cihazın en yakın bölgedeki web hizmetine bağlı olduğundan emin olur. Traffic Manager uç nokta izleme özelliği her bir web hizmeti uç noktası (3) için etkinleştirildiğinde ayarilmelidir.

Not

Yük devretme grubu yapılandırması, yük devretme için kullanılan bölgeyi tanımlar. Yeni birincil farklı bir coğrafyada olduğundan yük devretme, hem OLTP hem de salt okunur iş yükleri için etki alanı yeniden çevrimiçi olana kadar daha uzun gecikme süresine neden olur.

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

Günün sonunda, örneğin yerel saatle 23:00'da etkin veritabanlarının bir sonraki bölgeye (yerel saatle) Kuzey Avrupa. Bu görev, Azure Logic Apps kullanılarak tamamen otomatik hale Azure Logic Apps. Görev aşağıdaki adımları içerir:

  • Kolay yük devretme kullanarak yük devretme grubunda birincil Kuzey Avrupa sunucuya geçiş (1)
  • Yük devretme grubunu Doğu ABD arasında Kuzey Avrupa
  • Aynı adla ancak Kuzey Avrupa ile Doğu Asya (2) arasında yeni bir yük devretme grubu oluşturun.
  • Bu yük devretme grubuna Kuzey Avrupa ikincil Doğu Asya (3) ekleyin.

Aşağıdaki diyagramda, planlanan yük devretme sonrasındaki yeni yapılandırmalar göstermektedir:

Senaryo 3. Birincilin geçişini Kuzey Avrupa.

Örneğin, Kuzey Avrupa bir kesinti yaşanıyorsa, otomatik veritabanı yük devretmesi yük devretme grubu tarafından başlatılır ve bu da uygulamayı zamanlamadan önce bir sonraki bölgeye taşımaya (1) neden olur. Bu durumda, ABD Doğu yeniden çevrimiçi olana kadar kalan Kuzey Avrupa bölgedir. Kalan iki bölge, rolleri değiştirerek üç coğrafyada da müşterilere hizmet eder. Azure Logic Apps uygun şekilde ayarlanması gerek. Kalan bölgeler Avrupa'dan ek kullanıcı trafiğine sahip olduğundan, uygulamanın performansı yalnızca ek gecikme süresinden değil, aynı zamanda son kullanıcı bağlantılarının sayısının artmasından da etkilemektedir. Bu durumda kesinti azaltıldıktan Kuzey Avrupa, ikincil veritabanı mevcut birincil veritabanıyla hemen eşitlenir. Aşağıdaki diyagramda, Kuzey Avrupa:

Senaryo 3. Kuzey Avrupa.

Not

Son kullanıcının Avrupa'daki deneyiminin uzun gecikme süresine göre düşürülme süresini azaltabilirsiniz. Bunu yapmak için bir uygulama kopyasını proaktif olarak dağıtmanız ve ikincil veritabanını başka bir yerel bölgede (Batı Avrupa) çevrimdışı uygulama örneğinin yerine Kuzey Avrupa. İkinci seçenek yeniden çevrimiçi olduğunda, uygulamanın Batı Avrupa kullanmaya devam edip Batı Avrupa uygulamanın kopyasını kaldırmaya ve Kuzey Avrupa.

Bu tasarımın temel avantajları:

  • Salt okunur uygulama iş yükü, bölgedeki verilere her zaman erişmektedir.
  • Okuma-yazma uygulaması iş yükü, her coğrafyadaki en yüksek etkinlik döneminde en yakın bölgedeki verilere erişmektedir
  • Uygulama birden çok bölgeye dağıtıldığından, önemli bir kapalı kalma süresi olmadan bölgelerden birini kaybetmeye devam eder.

Ancak bazı tradeoff'lar vardır:

  • Bölgesel bir kesinti, coğrafyanın daha uzun gecikme süresinden etkilenmesini sağlar. Hem okuma yazma hem de salt okunur iş yükleri uygulama tarafından farklı bir coğrafyada sunulmaktadır.
  • Salt okunur iş yüklerinin her bölgede farklı bir uç noktaya bağlanması gerekir.

İş 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, bu tasarım desenlerini birleştirebilir veya uygulamanın ihtiyaçlarını en iyi şekilde karşılayacak şekilde 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ıyor. Karar verme sürecinize yardımcı olmak için aşağıdaki tabloda, kurtarma noktası hedefine (RPO) ve tahmini kurtarma süresine (ERT) göre seçenekler karşılaştırıldı.

Desen RPO ERT
Birlikte bulunan veritabanı erişimiyle olağanüstü durum kurtarma için aktif-pasif dağıtım Okuma/yazma erişimi < 5 sn Hata algılama süresi + DNS TTL
Uygulama yük dengeleme için etkin-etkin dağıtım Okuma/yazma erişimi < 5 sn Hata algılama süresi + DNS TTL
Verilerin korunması için aktif-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 = Veri kaybıyla hata algılama süresi + yetkisiz kullanım süresi

Sonraki adımlar