Aracılığıyla paylaş


Azure Cache for Redis için yük devretme ve düzeltme eki uygulamaları

Önemli

Redis için Azure Cache, tüm SKU'lar için kullanımdan kaldırma zaman çizelgesini duyurdu. Mevcut Redis için Azure Cache örneklerinizi en kısa sürede Azure Yönetilen Redis'e taşımanızı öneririz.

Kullanımdan kaldırma hakkında daha fazla bilgi için:

Dayanıklı ve başarılı istemci uygulamaları oluşturmak için Redis için Azure Cache hizmetinde yük devretmeyi anlamak önemlidir. Yük devretme planlı yönetim işlemlerinin bir parçası olabilir veya planlanmamış donanım veya ağ hatalarından kaynaklanıyor olabilir. Azure Cache for Redis ikili dosyalarına yönetim hizmeti tarafından yama uygulandığında, önbellek yük devretmesi yaygın olarak kullanılır.

Bu makalede şu bilgileri bulabilirsiniz:

  • Yük devretme nedir?
  • Yama uygulaması sırasında yük devretme nasıl gerçekleşir.
  • Dayanıklı bir istemci uygulaması oluşturma.

Yük devretme nedir?

Azure Cache for Redis için yük devretme konusuna genel bir bakış yapalı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 kopya olarak seçilir. Çünkü Standart ve Premium cache'ler birden çok düğüme sahiptir, bir düğüm kullanılamayabilirken diğer düğüm istekleri işlemeye devam edebilir. Kümelenmiş önbellekler, her biri ayrı birincil ve çoğaltma düğümlerine sahip birçok parçadan oluşur. Bir parça, diğerleri erişilebilir durumdayken çalışmıyor olabilir.

Uyarı

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 birincile bağlanır ve verileri senkronize eder. Yük devretme planlanmış veya planlanmamış olabilir.

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

  • Redis yamaları veya işletim sistemi yükseltmeleri gibi sistem güncellemeleri.
  • Ö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 tamamlanır.

Birincil düğümde donanım hatası, ağ hatası veya diğer beklenmeyen kesintiler nedeniyle planlanmamış bir yük devretme gerçekleşebilir. Replika düğümü, kendisini birincil olarak yükseltir ancak bu işlem daha uzun sürer. Yedekleme düğümü, yük devretme işlemini başlatabilmek için önce birincil düğümünün kullanım dışı olduğunu algılamalıdır. Replika düğüm, gereksiz bir yük devretmeyi önlemek için bu planlanmamış hatanın geçici veya yerel olup olmadığını doğrulamalıdır. Algılamadaki bu gecikme, planlanmamış yük devretme işleminin genellikle 10-15 saniye içinde tamamlandığı anlamına gelir.

Yama uygulaması 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ıktan sonra, kalan düğümler için düzeltmeler yinelenir.

Düzeltme eki uygulama planlı bir yük devretme olduğundan, yedek düğüm kendisini hızla birincil hale getirir. 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çacığı ayrı ayrı yama uygulanır ve diğer parçalarla 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çada yama 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 yama 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 hata geçişi 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 ayarını maxmemory-reserved.

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

İstemci uygulamaları, Azure Cache for Redis'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ı istisnaları
  • Bağlantı istisnaları
  • Soket istisnaları

Ö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, yük devretme gerçekleştiğinde yanıt almayan bir istek gönderen bir işlem, zaman aşımı hatası alabilir. 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?

Azure Cache for Redis, AzureRedisEvents adlı bir yayınlama/abone (pub/sub) kanalında çalışma zamanı bakım bildirimlerini 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.

Uyarı

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üncellemeleri 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, barındırma ortamındaki yazılım bileşenlerine düzeltme eki uygulamayı, ağ bileşenlerini yükseltmeyi veya devre dışı bırakmayı 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, bakım başlamadan 15 dakika önce size bildirim gönderilir.

İ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ına olan bağlantısını, aynı zamanda Redis için Azure Cache hizmetini de kaybeder.

Dayanıklılığı entegre edin

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ığı otomatik olarak önbellek uç noktasına yeniden bağlanır, ancak çok azı 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ı nasıl dayanıklı hale getiririm?

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, Redis çalışma zamanı düzeltme eklerini belirli haftalık zaman aralıkları içinde uygulamak için önbelleğinizde bir güncelleme kanalı ve bakım zaman dilimi seçmek üzere planlanmış güncellemeleri 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 Güncelleme Kanalı ve Güncellemeleri Zamanlama.

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