Olağanüstü durum kurtarmayı işlemek için yüksek oranda kullanılabilir uygulamalar tasarlama
Azure’da depolama hesabınızı oluşturdunuz ve RA-GRS’yi etkinleştirmek için çoğaltma ayarlarını yapılandırdınız. Artık sağlık uygulamanızı RA-GRS depolama hesabını kullanacak şekilde tasarlamaya başlamak için hazırsınız. Bu yaklaşım, Birincil bölgede kesinti olsa bile uygulamanın sahada çalışan hekimler ve uzman doktorlar için yüksek kullanılabilirliğe sahip olmasına yardımcı olur.
Bu ünitede olağanüstü durum kurtarmayı ve yük devretmeyi işleyebilecek bir uygulama tasarlamayı ve yapılandırmayı gözden geçireceksiniz. Ayrıca, yüksek kullanılabilirlik için uygulama tasarlarken geçerli olan noktaları da keşfedeceksiniz.
Hesap yük devretmesi nasıl çalışır?
GRS veya RA-GRS için bir depolama hesabı yapılandırdığınızda, istemci verileri birincil uç noktaya veya bölgeye yazar. Ardından, aşağıdaki görüntüde gösterildiği gibi veriler ikincil bölgeye otomatik olarak çoğaltılır:
Coğrafi olarak yedekli depolamanızı barındıran birincil bölge kullanılamaz duruma gelirse ikincil bölgeye yük devredebilirsiniz.
Yük devretme gerçekleştiğinde, ikincil bölge yeni birincil bölgeniz olur ve bu yeni birincil bölgeden tüm verilere erişilebilir. Depolama hesabınızla ilgili tüm DNS kayıtlarının DNS uç noktaları, yeni birincil bölgeye işaret edecek şekilde güncelleştirilir. Bu yeniden yönlendirme işlemi için uygulama kodunuzda hiçbir değişiklik yapılması gerekmez.
Birincil bölgede oluşan bir hata aşağıdaki görüntüde gösterilmiştir:
Önemli
Yük devretme otomatik olarak gerçekleşir ve Microsoft tarafından denetlenir. Azure depolama hesabının el ile yük devretmesi, Azure bölgelerinin çoğunda mümkün değildir. Ancak Microsoft, aşağıdaki komutu kullanarak depolama hesabında el ile yük devretme gerçekleştirebileceğiniz Yeni bir özelliği WestUS2 ve CentralUS bölgelerinde kullanıma sunmmıştır:
az storage account failover --name "storageaccountname"
Depolama hesabı yük devretme işleminin etkileri
Depolama hesabında yük devretme gerçekleştiğinde verileri kaybedebilirsiniz. Geçerli birincil bölgedeki veriler, yük devretme sırasında ikincil bölgeye çoğaltılmayabilir. Veri kaybı olasılığı olup olmadığını belirlemek için Son Eşitleme Zamanı özelliğini denetleyebilirsiniz. Bu değeri bulma komutu, önceki alıştırmada depolama hesabı çoğaltma durumunu gözden geçirmek için kullanılmıştı.
Dayanıklı bir uygulama tasarlama
Uygulamanızı tasarlarken aşağıdaki faktörleri göz önünde bulundurun:
Dayanıklılık: Kapalı kalma süresini ve veri kaybını önlemek için bir hatadan kurtarma ve çalışmaya devam etme olanağı.
Yüksek kullanılabilirlik: Uygulamanın bir veya daha fazla bileşenini etkileyen bir donanım hatası, sunucu hatası veya ağ sorunları varsa iyi durumda çalışmaya devam etme özelliği.
Olağanüstü durum kurtarma: Büyük bir olay, veri merkezi kesintisi veya tam bölgesel kesinti gibi uygulamayı barındıran hizmetleri etkilerse kurtarma olanağı. Olağanüstü durum kurtarma, Azure Site Recovery’yi kullanarak uygulamanın yükünü el ile devretmeyi içerir. Azure Site Recovery ile, sunucuların yükünü Azure bölgeleri veya Azure yedeklemeleri arasında devredebilirsiniz. Ardından, veritabanını veya uygulamayı yedekten geri yükleyebilirsiniz.
Nihai tutarlılık: RA-GRS, verileri birincil uç noktadan ikincil uç noktaya çoğaltarak çalışır. Bölgeler arasında çoğaltılan veriler ikincil konumda hemen kullanılabilir duruma gelmez. Nihai tutarlılık, birincil bölgedeki tüm işlemlerin sonunda ikincil bölgede görünmesi anlamına gelir. Veriler kaybolmaz ancak biraz gecikme yaşanabilir.
Aşağıdaki tabloda sağlık sisteminde nihai tutarlılığın etkileri gösterilir. Yeni veya güncelleştirilmiş kayıtlar birincil bölgeye yazıldığında, en son kayıtlar birincil depolama konumunda hemen kullanılabilir duruma gelir. Bu güncelleştirmeler nihai olarak ikincil bölgelere yayılır ama yayılmanın gerçekleşmesinde gecikme olabilir. İkincil konumdan veri okuyan bir uygulama kısa bir süre için güncel olmayan verileri görebilir.
Zaman İşlem Çoğaltma Son eşitleme zamanı Sonuç T0 Hekim hasta kaydını ekler İşlem eklenir ama çoğaltılmaz T1 Kayıt çoğaltılır T1 Son Eşitleme Zamanı alanı güncelleştirilir T2 Uzman doktor hasta kaydını güncelleştirir T1 Kayıt birincil bölgede güncelleştirilir ama çoğaltılmaz T3 İkincil bölgeden kayıt oku Güncelleştirmeler henüz birincil bölgeden çoğaltılmadığı için ikincil bölgedeki veriler eski T4 Kayıt çoğaltılır T4 İkincil bölgedeki veriler artık güncelleştirildi; Son Eşitleme Zamanı alanı güncelleştirildi
RA-GRS kullanılan bulut tabanlı uygulamalar için en iyi yöntemler
Bulut için uygulama geliştirirken, sonraki bölümlerdeki yönergeleri göz önünde bulundurun.
Geçici hataları yeniden deneme
Birçok koşul bağlantısız bir veritabanından geçici hatalara, geçici ağ kaybına veya hizmetlerden yavaş yanıt sürelerine neden olan gecikme sorunlarına neden olabilir. Uygulamaların hataları algılaması ve bunların yalnızca hizmette bir düzensizlik mi yoksa daha ciddi bir kesinti mi olduğunu belirlemesi gerekir. Uygulama, hatanın geçici olabileceğine inanıyorsa durumu başarısız olarak listelemeden önce hizmeti yeniden deneyebilmelidir.
Başarısız yazma işlemlerini işleme
RA-GRS yazma işlemlerini konumlar arasında çoğaltır. Birincil konum başarısız olursa, okuma işlemlerini ikincil konuma yönlendirebilirsiniz. Öte yandan bu ikincil konum salt okunurdur. Birincil konumda uzun süren (birkaç saniyeden uzun) bir kesinti oluşursa uygulamanızın salt okunur modda çalıştırılması gerekir. Salt okunur moda çeşitli yollarla geçebilirsiniz:
- Yazma özelliği geri yüklenene kadar, geçici olarak tüm yazma işlemlerinden hata döndürün.
- Örneğin bir kuyruk kullanarak yazma işlemlerini arabelleğe alın ve daha sonra yazma konumu kullanılabilir duruma gelince bunları işleyin.
- Güncelleştirmeleri başka konumda yer alan farklı bir depolama hesabına yazın. Birincil konum kullanılabilir duruma geldiğinde bu değişiklikleri birincil konumdaki depolama hesabıyla birleştirin.
- Tüm yazma işlemlerini devre dışı bırakmak için uygulamayı tetikleyin ve kullanıcıya uygulamanın salt okunur modda çalıştığını bildirin. Uygulamayı yükseltmeniz ve yükseltme yapılırken birincil konumu kimsenin kullanmadığından emin olmanız gerekiyorsa da bu mekanizmayı kullanabilirsiniz.
Azure Depolama istemci kitaplığını kullanan bir uygulama, okuma isteğinin LocationMode özelliğini aşağıdaki değerlerden birine ayarlayabilir:
- PrimaryOnly: Birincil konum kullanılamıyorsa okuma isteği başarısız olur. Bu hata varsayılan davranıştır.
- PrimaryThenSecondary: Önce birincil konumu deneyin, ardından birincil konum kullanılamıyorsa ikincil konumu deneyin. İkincil konum da kullanılamıyorsa başarısız olur.
- secondaryOnly: Yalnızca ikincil konumu deneyin ve kullanılamıyorsa başarısız olun.
- SecondaryThenPrimary: önce ikincil konumu deneyin ve ardından birincil konumu deneyin.
Nihai tutarlılığı işleme
Eski veriler ikincil konumdan okunuyorsa, bunları işlemeye hazırlıklı olun. Verilerin bölgeler arasında çoğaltılması zaman alır ve verilerin birincil konuma yazıldığı ve her ikincil konuma çoğaltıldığı zaman arasında bir kesinti oluşabilir.
Devre Kesici düzenini kullanma
Dağıtılmış ortamlarda, yavaş ağ bağlantıları, kaynak zaman aşımları, kaynakların çevrimdışı olması veya aktarımdaki verilerin bozulmasına neden olan iletim sorunu nedeniyle uzak kaynaklar arasındaki iletişim başarısız olabilir. Bu sorunlar çoğu zaman geçicidir ve kendi kendine çözülür. Uygulama, aynı işlemi yeniden denerse çoğunlukla başarılı olur.
Ciddi bir kesintinin yaşandığı bazı durumlarda, uygulamanın işlemi yeniden denemeyi bırakması ve ikincil konuma yük devretmeye başlaması mantıklı olur.
Uygulamanın başarısız olan işlemleri yeniden denemeye devam etmesini önlemek için Devre Kesici düzenini uygulayabilirsiniz.
Devre Kesici düzeni, uygulamayı ikincil konuma yük devretmeye zorlayarak uygulamanın normal hizmetini sürdürmesini sağlar. Aynı zamanda, devre kesici birincil sitedeki kaynakların yeniden çevrimiçi olup olmadığını denetlemeye devam eder. Çevrimiçi olduklarında, uygulamanın birincil siteye yeniden bağlanmasına izin verir. Devre kesici bir ara sunucu işlevi görür. Hizmeti izler. Hizmette bir hata varsa, devre kesici uygulamanın bu uç noktayı yeniden denemesini engeller ve bunu alternatif bir uç noktaya gitmeye zorlar.
Devre Kesici düzeni ile Yeniden Deneme düzeni arasındaki fark, Yeniden Deneme düzeninin bir uygulamanın çevrimdışı olabilecek bir kaynakla bağlantıyı yeniden denemeye devam etmesine izin vermesidir. Devre Kesici düzeni bu davranışı engeller ve uygulamanın ikincil bağlantıya yük devretmesini sağlar.
Devre Kesici düzenini uygulamanın amacı, sistem hatadan kurtarılırken uygulamanızda kararlılığı sağlamaktır.
Uygulamanın başarısız olan kaynaklar bağlanmayı denemeye devam etmesini engellemek ve bunun yerine bağlantıyı çalışan kaynaklara yeniden yönlendirerek kesintiyi en aza indirmek için Devre Kesici düzenini kullanın. Devre kesiciler sisteme ek yük getirebildiğinden, yerel veya bellek içi veri yapılarına erişmek için Devre Kesici düzenini kullanmayın.
Devre Kesici düzenini uygularken okuma isteklerinin LocationMode özelliğini gerektiği gibi ayarlayın. Çoğu durumda bu modu PrimaryThenSecondary olarak ayarlamanız gerekir. Birincim konumdan okuma işlemi zaman aşımına uğrarsa ikincil konum kullanılır. Ancak, bu işlem sürekli tekrarlandığında uygulamayı yavaşlatabilir. Devre kesici birincil konumun kullanılamadığını algıladığında SecondaryOnly moduna geçmelidir. Bu geçiş sayesinde, okuma işlemleri ikincil konumu denemek için birincil konumda zaman aşımı olmasını beklemek zorunda kalmaz. Devre kesici birincil konumun onarıldığını tahmin ettiğinde PrimaryThenSecondary moduna geri dönebilir.
Daha fazla bilgi için Devre Kesici düzeni'ne bakın.