Azure SignalR Hizmeti'de dayanıklılık ve olağanüstü durum kurtarma

Dayanıklılık ve olağanüstü durum kurtarma, çevrimiçi sistemler için yaygın bir gereksinimdir. Azure SignalR Hizmeti zaten %99,9 kullanılabilirlik sağlar, ancak hala bölgesel bir hizmettir. Bölge genelinde bir kesinti olduğunda, hizmet örneğiniz her zaman bir bölgede çalıştığından başka bir bölgeye yük devretmez.

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 vardır ve kod değişikliği yapılmaz. Ayrıntılar için coğrafi çoğaltmayı denetleyin.
• Hizmet SDK'sında Birden Çok Uç Nokta Kullanma. Hizmet SDK'mız birden çok SignalR hizmet örneğini destekler ve bazıları kullanılamadığında otomatik olarak diğer örneklere geçer. Bu özellik sayesinde bir olağanüstü durum oluştuğunda kurtarabilirsiniz ancak doğru sistem topolojisini kendiniz ayarlamanız gerekir. Bunu nasıl yapacağınızı bu belgede öğreneceksiniz.

SignalR hizmeti için yüksek kullanılabilir mimari

SignalR 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. Uygulama sunucuları birden çok hizmet örneğine bağlandığında, birincil ve ikincil olmak üzere iki rol vardır. Birincil, çevrimiçi trafik almaktan sorumlu bir örnektir, ikincil ise tamamen işlevsel bir geri dönüş örneği olarak görev görür. SDK uygulamamızda anlaşma yalnızca birincil uç noktaları döndürür, böylece istemciler normal durumlarda yalnızca birincil uç noktalara bağlanır. Ancak birincil örnek devre dışı olduğunda, istemcinin hala bağlantı yapabilmesi için anlaşma ikincil uç noktaları döndürür. Birincil örnek ve uygulama sunucusu normal sunucu bağlantıları üzerinden bağlanır, ancak ikincil örnek ve uygulama sunucusu zayıf bağlantı adı verilen özel bir bağlantı türü aracılığıyla bağlanır. Zayıf bir bağlantının ayırt edici özelliklerinden biri, başka bir bölgedeki ikincil örneğin konumu nedeniyle istemci bağlantı yönlendirmesini kabul edememedir. İstemciyi başka bir bölgeye yönlendirmek en uygun seçenek değildir (gecikme süresini artırır).

Birden çok uygulama sunucusuna bağlanırken bir hizmet örneğinin farklı rolleri olabilir. Bölgeler arası senaryo için tipik kurulumlardan biri, iki veya daha fazla SignalR hizmet örneği ve uygulama sunucusu çiftine sahip olmaktır. Her çift uygulama sunucusunun içinde ve SignalR hizmeti aynı bölgede bulunur ve SignalR hizmeti uygulama sunucusuna birincil rol olarak bağlanır. Her çift arasında uygulama sunucusu ve SignalR hizmeti de bağlanır, ancak SignalR başka bir bölgedeki sunucuya bağlanırken ikincil bir sunucu olur.

Bu topolojiyle, tüm uygulama sunucuları ve SignalR hizmet örnekleri birbirine bağlı olduğundan, bir sunucudan gelen ileti yine tüm istemcilere teslim edilebilir. Ancak bir istemci bağlandığında, en iyi ağ gecikme süresini elde etmek için aynı bölgedeki uygulama sunucusuna yönlendirilir.

Aşağıdaki diyagramda bu tür topoloji gösterilmektedir:

Birden çok SignalR hizmet örneğini yapılandırma

Hem uygulama sunucularında hem de Azure İşlevleri birden çok SignalR hizmeti örneği desteklenir.

Her bölgede SignalR hizmeti ve uygulama sunucuları/Azure İşlevleri oluşturulduktan sonra uygulama sunucularınızı/Azure İşlevleri tüm SignalR hizmet örneklerine bağlanacak şekilde yapılandırabilirsiniz.

Uygulama sunucularında yapılandırma

Bunu yapmanın iki yolu vardır:

Yapılandırma aracılığıyla

SignalR hizmeti bağlantı dizesi ortam değişkenleri/uygulama ayarları/web.cofig aracılığıyla adlı Azure:SignalR:ConnectionStringbir yapılandırma girişinde nasıl ayarlayabileceğinizi zaten biliyor olmalısınız. Birden çok uç noktanız varsa, bunları her birini aşağıdaki biçimde birden çok yapılandırma girdisinde ayarlayabilirsiniz:

Azure:SignalR:ConnectionString:<name>:<role>

Bağlan ionString içinde uç <name> noktanın adıdır ve <role> rolüdür (birincil veya ikincil). Ad isteğe bağlıdır, ancak yönlendirme davranışını birden çok uç nokta arasında daha fazla özelleştirmek istiyorsanız kullanışlıdır.

Kod aracılığıyla

bağlantı dizesi başka bir yerde depolamayı tercih ediyorsanız, bunları kodunuzda okuyabilir ve çağırırken AddAzureSignalR() (ASP.NET Core'da) veya MapAzureSignalR() (ASP.NET) parametre olarak kullanabilirsiniz.

Örnek kod şu şekildedir:

ASP.NET Core:

services.AddSignalR()
        .AddAzureSignalR(options => options.Endpoints = new ServiceEndpoint[]
        {
            new ServiceEndpoint("<connection_string1>", EndpointType.Primary, "region1"),
            new ServiceEndpoint("<connection_string2>", EndpointType.Secondary, "region2"),
        });

ASP.NET:

app.MapAzureSignalR(GetType().FullName, hub,  options => options.Endpoints = new ServiceEndpoint[]
    {
        new ServiceEndpoint("<connection_string1>", EndpointType.Primary, "region1"),
        new ServiceEndpoint("<connection_string2>", EndpointType.Secondary, "region2"),
    };

Birden çok birincil veya ikincil örneği yapılandırabilirsiniz. Birden çok birincil ve/veya ikincil örnek varsa, anlaşma aşağıdaki sırayla bir uç nokta döndürür:

1. En az bir çevrimiçi birincil örnek varsa rastgele bir birincil çevrimiçi örnek döndür.
2. Tüm birincil örnekler çalışmıyorsa rastgele bir ikincil çevrimiçi örnek döndür.

Azure İşlevleri yapılandırma

Bu makaleye bakın.

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

Artık doğru sistem topolojisi kurulumuna sahipsiniz. Bir SignalR hizmet örneği her kapatılırken çevrimiçi trafik diğer örneklere yönlendirilir. Birincil örnek kapatıldığında (ve bir süre sonra kurtarıldığında) şunlar gerçekleşir:

1. Birincil hizmet örneği çalışmıyor, bu örnekteki tüm sunucu bağlantıları bırakılıyor.
2. Bu örneğe bağlı tüm sunucular çevrimdışı olarak işaretler ve anlaşma, bu uç noktayı döndürmeyi durdurur ve ikincil uç nokta döndürmeye başlar.
3. Bu örnekteki tüm istemci bağlantıları da kapatılır, istemciler yeniden bağlanır. Uygulama sunucuları artık ikincil uç nokta döndüreceğinden istemciler ikincil örneğe bağlanır.
4. 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 iletiler yalnızca aynı bölgedeki uygulama sunucusuna yönlendirilir.
5. Birincil örnek kurtarılıp yeniden çevrimiçi olduktan sonra, uygulama sunucusu bu örnekle bağlantıları yeniden kurar ve çevrimiçi olarak işaretler. Anlaşma artık birincil uç noktayı yeniden döndürerek yeni istemcilerin birincil sunucuya geri bağlanmasına neden olur. Ancak mevcut istemciler düşmez ve kendi bağlantılarını kesene kadar ikincil istemcilere yönlendirilir.

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

Şekil.1 Yük devretmeden önce

Şekil.2 Yük devretmeden sonra

Şekil.3 Birincil iyileşmeden kısa süre sonra

Normal durumda yalnızca birincil uygulama sunucusunda ve SignalR hizmetinde çevrimiçi trafik (mavi) olduğunu görebilirsiniz. Yük devretme sonrasında ikincil uygulama sunucusu ve SignalR hizmeti de etkin hale gelir. Birincil SignalR hizmeti yeniden çevrimiçi olduktan sonra, yeni istemciler birincil SignalR'ye 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:

1. İlki, tüm çevrimiçi trafiği alan bir çift uygulama sunucusu ve SignalR hizmet örneğine sahip olmak ve yedek olarak başka bir çifte sahip olmaktır (şekil 1'de gösterilen aktif/pasif olarak adlandırılır).
2. Diğeri ise iki (veya daha fazla) uygulama sunucusu çiftine ve SignalR 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).

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

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

Ayrıca SignalR bağlantısının yapısı nedeniyle (uzun bir bağlantıdır), istemciler olağanüstü durum ve yük devretme gerçekleştiğinde bağlantı bırakma deneyimi yaşar. 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.

Yük devretmeyi test etme

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

1. 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.
2. Birincil kaynağı yeniden başlatın .

Sonraki adımlar

Bu makalede, SignalR hizmeti için dayanıklılık elde etmek için uygulamanızı yapılandırmayı öğrendiniz. SignalR hizmetinde sunucu/istemci bağlantısı ve bağlantı yönlendirme hakkında daha fazla bilgi edinmek için SignalR hizmeti iç işlevleri için bu makaleyi okuyabilirsiniz.

Çok sayıda bağlantıyı işlemek için birden çok örneği birlikte kullanan parçalama gibi ölçeklendirme senaryoları için birden çok örneğin nasıl ölçeklendirildiğini okuyun.

Birden çok SignalR hizmeti örneğiyle Azure İşlevleri yapılandırma hakkında ayrıntılı bilgi için Azure İşlevleri'da birden çok Azure SignalR Hizmeti örneği desteğini okuyun.