Azure Web PubSub Hizmeti'nde dayanıklılık ve olağanüstü durum kurtarma

Makale
10/26/2023

Dayanıklılık ve olağanüstü durum kurtarma, çevrimiçi sistemler için yaygın bir gereksinimdir. Azure Web PubSub Hizmeti zaten %99,9 kullanılabilirlik garantisi sağlar, ancak yine de bölgesel bir hizmettir. Bölge genelinde bir kesinti olduğunda, hizmetin gerçek zamanlı iletileri farklı bir bölgede işlemeye devam etmesi kritik önem taşır.

Bölgesel olağanüstü durum kurtarma için aşağıdaki iki yaklaşımı öneririz:

Coğrafi Çoğaltmayı Etkinleştir (Kolay yol). Bu özellik bölgesel yük devretmeyi sizin için otomatik olarak işler. Etkinleştirildiğinde yalnızca bir Azure SignalR örneği kalır ve kod değişikliği yapılmaz. Ayrıntılar için coğrafi çoğaltmayı denetleyin.
Birden çok uç nokta kullanma. Bunu nasıl yapacağınızı bu belgede öğreneceksiniz

Web PubSub hizmeti için yüksek kullanılabilir mimari

Web PubSub hizmetini kullanan iki tipik desen vardır:

Bunlardan biri, istemcilerin sunucuya olay gönderdiği ve sunucunun istemcilere ileti gönderdiği istemci-sunucu düzenidir.
Bir diğeri, Web PubSub hizmeti aracılığıyla diğer istemcilere pub/alt iletilerin istemci tarafından gönderilen istemci-istemci düzenidir.

Aşağıdaki bölümlerde, bu iki desenin olağanüstü durum kurtarma gerçekleştirmenin farklı yolları açıklanmaktadır

İstemci-sunucu deseni için yüksek kullanılabilir mimari

Web PubSub hizmetinin bölgeler arası dayanıklılığını sağlamak için farklı bölgelerde birden çok hizmet örneği ayarlamanız gerekir. Bu nedenle, bir bölge kapatıldığında diğerleri yedekleme olarak kullanılabilir.

Bölgeler arası senaryo için tipik kurulumlardan biri, iki (veya daha fazla) çift Web PubSub hizmet örneği ve uygulama sunucusuna sahip olmaktır.

Her çift uygulama sunucusunun içinde ve Web PubSub hizmeti aynı bölgede bulunur ve Web PubSub hizmeti olay işleyicisini aynı bölgedeki uygulama sunucusuna yukarı akış olarak ayarlar.

Mimariyi daha iyi göstermek için Web PubSub hizmetini aynı çiftteki uygulama sunucusuna birincil hizmet olarak adlandırıyoruz. Ayrıca Web PubSub hizmetlerini diğer çiftlerde uygulama sunucusuna ikincil hizmetler olarak adlandırıyoruz.

Uygulama sunucusu, birincil ve ikincil hizmetlerinin iyi durumda olup olmadığını algılamak için hizmet durumu denetimi API'sini kullanabilir. Örneğin, adlı demobir Web PubSub hizmeti için hizmet iyi durumda olduğunda uç nokta https://demo.webpubsub.azure.com/api/health 200 döndürür. Uygulama sunucusu belirli aralıklarla uç noktaları çağırabilir veya uç noktaların iyi durumda olup olmadığını denetlemek için isteğe bağlı olarak uç noktaları çağırabilir. WebSocket istemcileri genellikle Web PubSub hizmetine bağlanan URL'yi almak için önce uygulama sunucusuyla anlaşma gerçekleştirir ve uygulama istemcileri diğer iyi durumdaki ikincil hizmetlere devretmek için bu anlaşma adımını kullanır. Aşağıdaki ayrıntılı adımlar:

Bir istemci uygulama sunucusuyla anlaşma yaparken, uygulama sunucusu yalnızca birincil Web PubSub hizmet uç noktalarını döndürmelidir, bu nedenle normal durumda istemciler yalnızca birincil uç noktalara bağlanır.
Birincil örnek devre dışı olduğunda, istemcinin hala bağlantı kurabilmesi ve istemcinin ikincil uç noktaya bağlanması için iyi durumda bir ikincil uç nokta döndürmesi gerekir.
Birincil örnek çalışır durumdayken, istemcilerin artık birincil uç noktaya bağlanabilmesi için iyi durumdaki birincil uç noktayı döndürmesi gerekir
Uygulama sunucusu iletileri yayınladığında, iletileri hem birincil hem de ikincil dahil olmak üzere tüm iyi durumdaki uç noktalara yayınlaması GEREKIR.
Uygulama sunucusu, istemcilerin iyi durumdaki birincil uç noktaya yeniden bağlanmasını zorlamak için ikincil uç noktalara bağlı bağlantıları kapatabilir.

Bu topolojiyle, tüm uygulama sunucuları ve Web PubSub hizmet örnekleri birbirine bağlı olduğundan, bir sunucudan gelen ileti yine tüm istemcilere teslim edilebilir.

Henüz stratejiyi SDK ile tümleştiremedik, bu nedenle şimdilik uygulamanın bu stratejiyi tek başına uygulaması gerekiyor.

Özetle, uygulama tarafının uygulaması gerekenler:

Sistem durumu denetimi. Uygulama, hizmet durumu denetimi API'sini arka planda düzenli aralıklarla veya her anlaşma çağrısı için isteğe bağlı olarak kullanarak hizmetin iyi durumda olup olmadığını denetleyebilir.
Mantık anlaşması yapma. Uygulama, varsayılan olarak iyi durumdaki birincil uç noktayı döndürür. Birincil uç nokta devre dışı olduğunda, uygulama iyi durumdaki ikincil uç noktayı döndürür.
Yayın mantığı. İletiler birden çok istemciye gönderildiğinde, uygulamanın iletileri tüm iyi durumdaki uç noktalara yayınladığından emin olması gerekir.

Aşağıda bu tür topolojiyi gösteren bir diyagram yer almaktadır:

Diagram shows two regions each with an app server and a Web PubSub service, where each server is associated with the Web PubSub service in its region as primary and with the service in the other region as secondary.

Yük devretme sırası ve en iyi yöntem

Artık doğru sistem topolojisi kurulumuna sahipsiniz. Bir Web PubSub hizmet örneği her kapatılırken, çevrimiçi trafik diğer örneklere yönlendirilir. Birincil örnek devre dışı bırakıldığında (ve bir süre sonra kurtarıldığında) şunlar olur:

Birincil hizmet örneği çalışmıyor, bu örneğe bağlı tüm istemciler bırakılacak.
Yeni istemciler veya yeniden bağlantı istemcisi uygulama sunucusuyla anlaşma
Uygulama sunucusu birincil hizmet örneğinin devre dışı olduğunu algılar ve anlaşma bu uç noktayı döndürmeyi durdurur ve iyi durumda bir ikincil uç nokta döndürmeye başlar.
İstemciler ikincil örneğe bağlanır.
Artık ikincil örnek tüm çevrimiçi trafiği alır. İkincil tüm uygulama sunucularına bağlı olduğundan sunucudan istemcilere tüm iletiler teslim edilebilir. Ancak istemciden sunucuya olay iletileri yalnızca aynı bölgedeki yukarı akış uygulama sunucusuna gönderilir.
Birincil örnek kurtarılıp yeniden çevrimiçi olduktan sonra, uygulama sunucusu birincil örneğin iyi durumda olduğunu algılar. Anlaşma artık birincil uç noktayı yeniden döndürecek ve böylece yeni istemciler birincile geri bağlanacak. Ancak mevcut istemciler bırakılmaz ve kendi bağlantılarını kesene kadar ikincil istemcilere bağlanmaya devam eder.

Aşağıdaki diyagramlarda yük devretmenin nasıl yapıldığı gösterilmektedir:

Şekil.1 Yük devretmeden önce Before Failover

Şekil.2 Yük devretmeden sonra After Failover

Şekil.3 Birincil iyileşmeden kısa süre sonra Short time after primary recovers

Normal durumda yalnızca birincil uygulama sunucusu ve Web PubSub hizmetinde çevrimiçi trafik (mavi) olduğunu görebilirsiniz.

Yük devretmeden sonra ikincil uygulama sunucusu ve Web PubSub hizmeti de etkin hale gelir. Birincil Web PubSub hizmeti yeniden çevrimiçi olduktan sonra, yeni istemciler birincil Web PubSub'a bağlanır. Ancak mevcut istemciler ikincil sunucuya bağlanmaya devam eder ve böylece her iki örnekte de trafik olur.

Mevcut tüm istemcilerin bağlantısı kesildikten sonra sisteminiz normale döner (Şekil.1).

Bölgeler arası yüksek kullanılabilir mimari uygulamak için iki ana desen vardır:

İlki, tüm çevrimiçi trafiği alan bir çift uygulama sunucusu ve Web PubSub hizmet örneğine sahip olmak ve yedek olarak başka bir çifte sahip olmaktır (şekil 1'de gösterilen etkin/pasif olarak adlandırılır).
Diğeri ise iki (veya daha fazla) uygulama sunucusu çiftine ve Web PubSub hizmet örneğine sahip olmaktır. Her biri çevrimiçi trafiğin bir parçası olur ve diğer çiftler için yedekleme görevi görür (Şekil.3'e benzer etkin/etkin olarak adlandırılır).

Web PubSub hizmeti her iki deseni de destekleyebilir. Temel fark, uygulama sunucularını uygulama şeklinizdir. Uygulama sunucuları etkin/pasifse, Web PubSub hizmeti de etkin/pasif olur (birincil uygulama sunucusu yalnızca birincil Web PubSub hizmet örneğini döndürdüğünden). Uygulama sunucuları etkin/etkinse, Web PubSub hizmeti de etkin/etkin olur (tüm uygulama sunucuları kendi birincil Web PubSub örneklerini döndüreceğinden, hepsi trafik alabilir).

Hangi desenleri kullanmayı seçerseniz seçin, her Web PubSub hizmeti örneğini birincil rol olarak bir uygulama sunucusuna bağlamanız gerekir.

Ayrıca WebSocket bağlantısının doğası gereği (uzun bir bağlantıdır), istemciler olağanüstü durum olduğunda ve yük devretme gerçekleştiğinde bağlantı bırakmalarla karşılaşır. Bu tür durumları son müşterileriniz için şeffaf hale getirmek için istemci tarafında işlemeniz gerekir. Örneğin, bir bağlantı kapatıldıktan sonra yeniden bağlayın.

İstemci-istemci deseni için yüksek kullanılabilir mimari

İstemci-istemci düzeni için, şu anda birden çok örnek kullanarak sıfır aşağı doğru olağanüstü durum kurtarmayı desteklemek henüz mümkün değildir. Yüksek kullanılabilirlik gereksinimleriniz varsa lütfen coğrafi çoğaltmayı kullanmayı göz önünde bulundurun.

Yük devretmeyi test etme

Yük devretmeyi tetikleme adımlarını izleyin:

Portaldaki birincil kaynağın Ağ sekmesinde genel ağ erişimini devre dışı bırakın . Kaynağın etkinleştirilmiş özel ağı varsa, tüm trafiği reddetmek için erişim denetimi kurallarını kullanın.
Birincil kaynağı yeniden başlatın .