Not
Bu sayfaya erişim yetkilendirme gerektiriyor. Oturum açmayı veya dizinleri değiştirmeyi deneyebilirsiniz.
Bu sayfaya erişim yetkilendirme gerektiriyor. Dizinleri değiştirmeyi deneyebilirsiniz.
Dayanıklı ve başarılı istemci uygulamaları oluşturmak için Azure Yönetilen Redis 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 Azure Yönetilen Redis ikili dosyalarına düzeltme eki uygulandığında önbellek yük devretmesinin yaygın bir kullanımıdır.
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?
Azure Yönetilen Redis 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. Her bir sanal makine (veya "düğüm"), paralel olarak birden fazla Redis sunucu işlemi (bunlar "parçalar" olarak adlandırılır) çalıştırır. Birden çok parça, her sanal makinede vCPU'ların daha verimli bir şekilde kullanılmasına ve daha yüksek performansa olanak sağlar. Birincil Redis parçalarının tümü aynı VM/düğümde değildir. Bunun yerine, birincil ve yedek parçalar her iki düğümde de dağıtılır. Birincil parçalar çoğaltma parçalarından daha fazla CPU kaynağı kullandığından, bu yaklaşım daha fazla birincil parçanın paralel olarak çalıştırılmasını sağlar. Her düğümde, parçaları yönetmek, bağlantıları yönetmek ve kendi kendini düzeltmeyi tetiklemek için yüksek performanslı bir ara sunucu işlemi vardır. Bir parça, diğerleri kullanılabilir durumdayken çalışmıyor olabilir.
Azure Yönetilen Redis Mimarisi'nin ayrıntılı ayrıntılarına buradan ulaşabilirsiniz.
Yük devretme açıklaması
Bir veya daha fazla çoğaltma parçası birincil parça haline geldiğinde ve eski birincil parçalar mevcut bağlantıları kapattığında yük devretme gerçekleşir. Hata durumunda devretme planlı veya plansız 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ğine dayalı bir şekilde 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.
Planlanmamış bir yük devretme, kümedeki bir veya daha fazla düğümde donanım hatası, ağ hatası veya diğer beklenmeyen kesintiler nedeniyle oluşabilir. Kalan düğümlerde çoğaltma parçaları, kullanılabilirliği korumak için kendilerini birincil parçalara yükseltir ancak işlem daha uzun sürer. Bir çoğaltma parçasının yük devretme işlemini başlatabilmesi için önce birincil parçasının kullanılabilir olmadığını algılaması gerekir. Çoğaltma parçası, 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?
Azure Yönetilen Redis 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:
- Hizmet, düzeltme eki uygulanmakta olan tüm VM'lerin yerini alacak yeni güncel VM'ler oluşturur.
- Ardından yeni VM'lerden birini küme lideri olarak yükselter.
- Tek tek, düzeltme eki uygulanmakta olan tüm düğümler kümeden kaldırılır. Bu VM'lerdeki tüm parçalar indirgenecek ve yeni VM'lerden birine geçirilecektir.
- Son olarak, değiştirilen tüm VM'ler silinir.
Kümelenmiş önbelleğin her parçası ayrı olarak düzeltme eki uygulanır ve başka bir parçayla bağlantıları kapatmaz.
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, önbelleğinizde 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ü
Yük devretme gerçekleştiğinde ö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 yüke sahipse istemci uygulamaları daha fazla gecikme süresiyle karşılaşabilir. Olağan dışı durumlarda istemci uygulamaları, zaman aşımı özel durumları alabilir.
Yük devretme istemci uygulamamı nasıl etkiler?
İstemci uygulamaları Azure Managed Redis örneğinden bazı hatalar alabilir. İstemci uygulamanın karşılaştığı hata sayısı, yük devretme sırasında söz konusu bağlantıda bekleyen işlemlerin sayısına bağlıdır. Bağlantılarını kapatan düğüm aracılığıyla yönlendirilen tüm bağlantılar hatalarla karşılaşı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ı ö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, bir istek gönderen ancak yük devretme gerçekleştiğinde yanıt almamış 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ığı, bu şekilde yapılandırılmışsa önbelleğe yeniden bağlanmayı dener. Bununla birlikte, öngörülemeyen hatalar bazen kitaplık nesnelerini kurtarılamaz bir duruma sokabilir. 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 ile mümkün olabilir.
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 görünmez.
İstemci ağ-yapılandırma 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 ile ü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 ve Azure Managed Redis hizmetiyle olan bağlantısını kaybediyordur.
Dayanıklılık odaklı tasarım
Yük devretmeleri tamamen önleyemezsiniz. Bunun yerine, istemci uygulamalarınızı bağlantı kesintilerine 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 denemeye çalışır. Uygulama senaryosuna bağlı olarak geri alma ile yeniden deneme mantığını kullanmak mantıklı olabilir.
Uygulamamı nasıl dayanıklı hale getirebilirim?
Özellikle devre kesici ve yeniden deneme desenleri oluşturmaya yönelik dayanıklı istemciler oluşturmak için şu tasarım desenlerine bakın:
- Güvenilirlik desenleri - Bulut Tasarım Desenleri
- Azure hizmetleri için yeniden deneme kılavuzu - Bulut uygulamaları için en iyi yöntemler
- Üstel geri alma ile yeniden denemeler uygulama