Redis için Azure Cache'de yük devretme ve yama uygulama

  • Makale

Dayanıklı ve başarılı istemci uygulamaları oluşturmak için Redis için Azure Cache hizmetinde yük devretmeyi anlamak kritik önem taşır. Yük devretme planlı yönetim işlemlerinin bir parçası olabilir veya planlanmamış donanım veya ağ hatalarından kaynaklanıyor olabilir. Yönetim hizmeti Redis için Azure Cache ikili dosyalarına düzeltme eki uygulandığında önbellek yük devretmesinin yaygın bir kullanımı gelir.

Bu makalede şu bilgileri bulabilirsiniz:

  • Yük devretme nedir?
  • Düzeltme eki uygulama sırasında yük devretmenin nasıl gerçekleştiği.
  • Dayanıklı bir istemci uygulaması oluşturma.

Yük devretme nedir?

Redis için Azure Cache için yük devretmeye genel bir bakışla başlayalım.

Önbellek mimarisinin hızlı bir özeti

Önbellek, ayrı ve özel IP adreslerine sahip birden çok sanal makineden oluşturulur. Düğüm olarak da bilinen her sanal makine, tek bir sanal IP adresiyle paylaşılan bir yük dengeleyiciye bağlanır. Her düğüm Redis sunucu işlemini çalıştırır ve ana bilgisayar adı ve Redis bağlantı noktaları kullanılarak erişilebilir. Her düğüm birincil veya çoğaltma düğümü olarak kabul edilir. bir istemci uygulaması önbelleğe bağlandığında, trafiği bu yük dengeleyiciden geçer ve otomatik olarak birincil düğüme yönlendirilir.

Temel önbellekte tek düğüm her zaman birincil düğümdür. Standart veya Premium önbellekte iki düğüm vardır: biri birincil, diğeri çoğaltma olarak seçilir. Standart ve Premium önbellekler birden çok düğüme sahip olduğundan, diğer düğüm istekleri işlemeye devam ederken bir düğüm kullanılamayabilir. Kümelenmiş önbellekler, her biri ayrı birincil ve çoğaltma düğümlerine sahip birçok parçadan oluşur. Bir parça, diğerleri kullanılabilir durumdayken çalışmıyor olabilir.

Not

Temel önbelleğin birden çok düğümü yoktur ve kullanılabilirliği için hizmet düzeyi sözleşmesi (SLA) sunmaz. Temel önbellekler yalnızca geliştirme ve test amacıyla önerilir. Kullanılabilirliği artırmak için çok düğümlü dağıtım için Standart veya Premium önbellek kullanın.

Yük devretmenin açıklaması

Bir çoğaltma düğümü kendisini birincil düğüme yükselttiğinde ve eski birincil düğüm mevcut bağlantıları kapattığında yük devretme gerçekleşir. Birincil düğüm geri geldikten sonra rollerdeki değişikliği fark eder ve kendisini bir çoğaltma olacak şekilde indirger. Ardından yeni birincil birincile bağlanır ve verileri eşitler. Yük devretme planlanmış veya planlanmamış olabilir.

Planlı yük devretme iki farklı zaman içinde gerçekleşir:

  • Redis düzeltme eki uygulama veya işletim sistemi yükseltmeleri gibi sistem güncelleştirmeleri.
  • Ölçeklendirme ve yeniden başlatma gibi yönetim işlemleri.

Düğümler güncelleştirmeyle ilgili önceden bildirim aldığından, rolleri işbirliğiyle değiştirebilir ve değişikliğin yük dengeleyicisini hızla güncelleştirebilir. Planlı yük devretme genellikle 1 saniyeden kısa sürede tamamlar.

Birincil düğümde donanım hatası, ağ hatası veya diğer beklenmeyen kesintiler nedeniyle planlanmamış bir yük devretme gerçekleşebilir. Çoğaltma düğümü kendisini birincil düğüme yükseltse de işlem daha uzun sürer. Çoğaltma düğümlerinin yük devretme işlemini başlatabilmesi için önce birincil düğümünü algılaması gerekir. Çoğaltma düğümü, gereksiz bir yük devretmeyi önlemek için bu planlanmamış hatanın geçici veya yerel olmadığını da doğrulamalıdır. Algılamadaki bu gecikme, planlanmamış yük devretme işleminin genellikle 10-15 saniye içinde tamamlandığı anlamına gelir.

Düzeltme eki uygulama nasıl gerçekleşir?

Redis için Azure Cache hizmeti, önbelleğinizi en son platform özellikleri ve düzeltmeleriyle düzenli olarak güncelleştirir. Bir önbelleğe düzeltme eki uygulamak için hizmet şu adımları izler:

  1. Hizmet önce çoğaltma düğümüne düzeltme eki uygular.
  2. Yama yapılan çoğaltma işbirliğiyle kendisini birincil çoğaltmaya yükseltmektedir. Bu yükseltme planlı yük devretme olarak kabul edilir.
  3. Eski birincil düğüm, yeni değişiklikleri almak için yeniden başlatılır ve çoğaltma düğümü olarak geri gelir.
  4. Çoğaltma düğümü birincil düğüme bağlanır ve verileri eşitler.
  5. Veri eşitleme tamamlandığında, kalan düğümler için düzeltme eki uygulama işlemi yinelenir.

Düzeltme eki uygulama planlı bir yük devretme olduğundan, çoğaltma düğümü kendisini hızla birincil olacak şekilde yükselter. Ardından düğüm, hizmet isteklerine ve yeni bağlantılara başlar. Temel önbelleklerin çoğaltma düğümü yoktur ve güncelleştirme tamamlanana kadar kullanılamaz. Kümelenmiş önbelleğin her parçası ayrı olarak düzeltme eki uygulanır ve başka bir parçayla bağlantıları kapatmaz.

Önemli

Veri kaybını önlemek için düğümlere birer birer düzeltme eki uygulanır. Temel önbelleklerde veri kaybı olacaktır. Kümelenmiş önbelleklere her seferinde bir parça düzeltme eki uygulanır.

Aynı kaynak grubu ve bölgedeki birden çok önbelleğe de birer birer düzeltme eki uygulanır. Farklı kaynak gruplarında veya farklı bölgelerde bulunan önbelleklere aynı anda düzeltme eki uygulanabilir.

İşlem tekrarlanmadan önce tam veri eşitlemesi gerçekleştiğinden, Standart veya Premium önbellek kullandığınızda veri kaybı oluşma olasılığı düşüktür. Verileri dışarı aktararak ve kalıcılığı etkinleştirerek veri kaybına karşı daha fazla koruma sağlayabilirsiniz.

Ek önbellek yükü

Her yük devretme gerçekleştiğinde Standart ve Premium önbelleklerin verileri bir düğümden diğerine çoğaltması gerekir. Bu çoğaltma hem sunucu belleğinde hem de CPU'da biraz yük artışına neden olur. Önbellek örneği zaten yoğun bir şekilde yüklüyse istemci uygulamaları daha fazla gecikme süresiyle karşılaşabilir. Aşırı durumlarda istemci uygulamaları zaman aşımı özel durumları alabilir. Daha fazla yükün etkisini azaltmaya yardımcı olmak için önbelleğin maxmemory-reserved ayarını yapılandırın.

Yük devretme istemci uygulamamı nasıl etkiler?

İstemci uygulamaları Redis için Azure Cache'ten bazı hatalar alabilir. İstemci uygulaması tarafından görülen hata sayısı, yük devretme sırasında bu bağlantıda bekleyen işlem sayısına bağlıdır. Bağlantılarını kapatan düğüm üzerinden yönlendirilen tüm bağlantılar hatalar görür.

Birçok istemci kitaplığı, bağlantılar kesildiğinde aşağıdakiler dahil olmak üzere farklı türde hatalar oluşturabilir:

  • Zaman aşımı özel durumları
  • Bağlan ion özel durumları
  • Yuva özel durumları

Özel durumların sayısı ve türü, önbellek bağlantılarını kapattığında isteğin kod yolundaki konumuna bağlıdır. Örneğin, istek gönderen ancak yük devretme gerçekleştiğinde yanıt almayan bir işlem zaman aşımı özel durumuyla karşılanabilir. Kapatılan bağlantı nesnesinde yeni istekler, yeniden bağlantı başarıyla gerçekleşene kadar bağlantı özel durumları alır.

Çoğu istemci kitaplığı, bunu yapacak şekilde yapılandırılmışsa önbelleğe yeniden bağlanmayı dener. Ancak, öngörülemeyen hatalar bazen kitaplık nesnelerini kurtarılamaz bir duruma yerleştirebilir. Hatalar önceden yapılandırılmış bir süreden daha uzun süre devam ederse, bağlantı nesnesi yeniden oluşturulmalıdır. Microsoft.NET ve diğer nesne odaklı dillerde, uygulamayı yeniden başlatmadan bağlantıyı yeniden oluşturmak ForceReconnect deseni kullanılarak gerçekleştirilebilir.

Bakımdan önce bana bildirilebilir mi?

Redis için Azure Cache adlı AzureRedisEventsbir yayımlama/abone olma (pub/sub) kanalında çalışma zamanı bakım bildirimleri yayımlar. Birçok popüler Redis istemci kitaplığı pub/sub kanallarına abone olunma desteği sağlar. Kanaldan AzureRedisEvents bildirim almak genellikle istemci uygulamanıza basit bir eklemedir. Bakım olayları hakkında daha fazla bilgi için bkz . AzureRedisEvents.

Not

Kanal AzureRedisEvents , size gün veya saat önceden bildirimde bulunabilecek bir mekanizma değildir. Kanal, sunucu kullanılabilirliğini etkileyebilecek yaklaşan sunucu bakım olaylarını istemcilere bildirebilir. AzureRedisEvents yalnızca Temel, Standart ve Premium katmanlarında kullanılabilir.

Bakım kapsamındaki güncelleştirmeler nelerdir?

Bakım şu güncelleştirmeleri içerir:

  • Redis Server güncelleştirmeleri: Redis sunucusu ikili dosyalarının tüm güncelleştirmeleri veya düzeltme ekleri.
  • Sanal makine (VM) güncelleştirmeleri: Redis hizmetini barındıran sanal makinenin tüm güncelleştirmeleri. VM güncelleştirmeleri, ağ bileşenlerini yükseltmek veya yetkisini almak için barındırma ortamındaki yazılım bileşenlerine düzeltme eki uygulama içerir.

Bakım, bir düzeltme eki öncesinde Azure portalındaki hizmet durumu'nda görünüyor mu?

Hayır, bakım portalda veya başka bir yerde hizmet durumu altında hiçbir yerde görünmez.

Planlı bakımdan önce bildirimi ne kadar süreyle alabilirim?

Kanalı kullanırken AzureRedisEvents bakımdan 15 dakika önce size bildirilir.

İstemci ağ yapılandırması değişiklikleri

Bazı istemci tarafı ağ yapılandırma değişiklikleri Kullanılabilir bağlantı yok hatalarını tetikleyebilir. Bu tür değişiklikler şunları içerebilir:

  • Bir istemci uygulamasının sanal IP adresini hazırlama ve üretim yuvaları arasında değiştirme.
  • Uygulamanızın örneklerinin boyutunu veya sayısını ölçeklendirme.

Bu tür değişiklikler genellikle bir dakikadan kısa süren bir bağlantı sorununa neden olabilir. İstemci uygulamanız büyük olasılıkla diğer dış ağ kaynaklarıyla değil, aynı zamanda Redis için Azure Cache hizmetiyle de bağlantısını kaybeder.

Dayanıklılık içinde derleme

Yük devretmeleri tamamen önleyemezsiniz. Bunun yerine, istemci uygulamalarınızı bağlantı sonlarına ve başarısız isteklere dayanıklı olacak şekilde yazın. çoğu istemci kitaplığı önbellek uç noktasına otomatik olarak yeniden bağlanır, ancak bazıları başarısız istekleri yeniden denemeyi dener. Uygulama senaryosuna bağlı olarak geri alma ile yeniden deneme mantığını kullanmak mantıklı olabilir.

Uygulamamı dayanıklı hale Nasıl yaparım??

Dayanıklı istemciler, özellikle de devre kesici ve yeniden deneme desenleri oluşturmak için bu tasarım desenlerine bakın:

İstemci uygulamasının dayanıklılığını test etmek için bağlantı sonları için el ile tetikleyici olarak yeniden başlatma kullanın.

Ayrıca, belirli haftalık pencereler sırasında Redis çalışma zamanı düzeltme eklerini uygulamak üzere önbelleğiniz için bir güncelleştirme kanalı ve bakım penceresi seçmek üzere zamanlanmış güncelleştirmeler kullanmanızı öneririz. Bu pencereler, olası olayları önlemek için genellikle istemci uygulama trafiğinin düşük olduğu dönemlerdir. Daha fazla bilgi için bkz . Kanalı güncelleştirme ve Güncelleştirmeleri zamanlama.

Daha fazla bilgi için bkz. Bağlan dayanıklılık.

İlgili içerik