Azure Yönetilen Redis mimarisi

Azure Yönetilen Redis, Redis'in topluluk sürümüne göre önemli avantajlar sunan Redis Enterprise yığını üzerinde çalışır. Aşağıdaki bilgiler, Azure Yönetilen Redis'in mimarisinin nasıl tasarlandığı hakkında daha fazla ayrıntı sağlar ve bu bilgiler ileri düzey kullanıcılar için yararlı olabilir.

Redis için Azure Cache ile karşılaştırma

Redis için Azure Cache Temel, Standart ve Premium katmanları Redis'in topluluk sürümü üzerine kurulmuştur. Redis'in bu topluluk sürümünde tek iş parçacıklı olmak da dahil olmak üzere çeşitli önemli sınırlamalar vardır. Bu, hizmet tarafından tam olarak kullanılmayan vCPU sayısı arttıkça performansı önemli ölçüde azaltır ve ölçeklendirmeyi daha az verimli hale getirir. Tipik bir Redis için Azure Cache örneği aşağıdaki gibi bir mimari kullanır:

birincil ve yedek olmak üzere iki VM kullanıldığına dikkat edin. Bu VM'ler "düğümler" olarak da adlandırılır. Birincil düğüm ana Redis işlemini tutar ve tüm yazma işlemlerini kabul eder. Çoğaltma, bakım, ölçeklendirme veya beklenmeyen hata sırasında yedek kopya sağlamak için çoğaltma düğümüne zaman uyumsuz olarak yürütülür. Topluluk sürümü Redis'in tek iş parçacıklı tasarımı nedeniyle her düğüm yalnızca tek bir Redis sunucu işlemi çalıştırabilir.

Azure Yönetilen Redis'in Mimari Geliştirmeleri

Azure Yönetilen Redis aşağıdakine benzer daha gelişmiş bir mimari kullanır:

Çeşitli farklar vardır:

• 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.

Bu mimari hem daha yüksek performansa hem de etkin coğrafi çoğaltma gibi gelişmiş özelliklere olanak tanır

Kümeleme

Her Azure Yönetilen Redis örneği, tüm katmanlarda ve SKU'larda kümeleme kullanacak şekilde dahili olarak yapılandırılır. Azure Yönetilen Redis, düğüm başına birden çok parça kullanabilen Redis Enterprise'ı temel alır. Bu, yalnızca tek bir kırıntı kullanmak üzere ayarlanmış küçük örnek birimleri içerir. Kümeleme, Redis örneğindeki verileri "parçalama" olarak da adlandırılan birden çok Redis işlemi arasında bölmenin bir yoludur. Azure Yönetilen Redis, önbellek örneğine bağlanmak için Redis istemcilerinin kullanabileceği protokolü belirleyen üç küme ilkesi sunar.

Küme ilkeleri

Azure Managed Redis üç kümeleme ilkesi sunar: İşletim Sistemi, Kurumsal ve Kümelenmemiş (önizleme). Çoğu uygulama için işletim sistemi kümesi ilkesi önerilir çünkü daha yüksek aktarım hızını destekler, ancak her sürümde avantajlar ve dezavantajlar vardır.

OSS kümeleme ilkesi, Redis için Azure Cache katmanlarıyla aynı Redis Kümesi API'sini uygular. Redis Kümesi API'si, Redis istemcisinin her Redis düğümündeki parçalara doğrudan bağlanmasına olanak tanıyarak gecikme süresini en aza indirir ve ağ aktarım hızını en iyi duruma getirerek parça ve vCPU sayısı arttıkça aktarım hızının neredeyse doğrusal olarak ölçeklendirilmesine olanak tanır. OSS kümeleme ilkesi genellikle en iyi gecikme süresini ve aktarım hızı performansını sağlar. Ancak OSS küme ilkesi, istemci kitaplığınızın Redis Kümesi API'sini desteklemesini gerektirir. Bugün, neredeyse tüm Redis istemcileri Redis Kümesi API'sini destekler, ancak uyumluluk eski istemci sürümleri veya özel kitaplıklar için bir sorun olabilir.

OSS kümeleme ilkesi RediSearch modülüyle kullanılamaz.

OSS kümeleme protokolü, istemcinin doğru parça bağlantılarını yapmasını gerektirir. İlk bağlantı 10000 numaralı bağlantı noktası üzerinden yapılır. Tek tek düğümlere bağlanma işlemi 85XX aralığındaki bağlantı noktaları kullanılarak yapılır. 85xx bağlantı noktaları zaman içinde değişebilir ve uygulamanıza sabit kodlanmış olmamalıdır. Kümelemesi destekleyen Redis istemcileri, birincil ve çoğaltma parçaları için kullanılan tam bağlantı noktalarını belirlemek ve parça bağlantılarını sizin için yapmak için CLUSTER NODE komutunu kullanır.

Kurumsal kümeleme ilkesi, tüm istemci bağlantıları için tek bir uç nokta kullanan daha basit bir yapılandırmadır. Kurumsal kümeleme ilkesinin kullanılması, tüm istekleri daha sonra proxy olarak kullanılan tek bir Redis düğümüne yönlendirir ve istekleri dahili olarak kümedeki doğru düğüme yönlendirir. Bu yaklaşımın avantajı, kullanıcılara Azure Yönetilen Redis'in kümelenmemiş gibi görünmesidir. Bu, Redis istemci kitaplıklarının Redis Enterprise'ın bazı performans avantajlarından yararlanmak için Redis Kümelemeye destek olması gerek olmadığı anlamına gelir. Tek bir uç nokta kullanmak geriye dönük uyumluluğu artırır ve bağlantıyı kolaylaştırır. Bunun dezavantajı, tek düğüm proxy'sinin hesaplama kullanımı veya ağ aktarım hızı açısından bir tıkanıklık noktası olabilmesidir.

RediSearch modülüyle kullanılabilen tek ilke Kurumsal kümeleme ilkesidir. Kurumsal küme ilkesi bir Azure Yönetilen Redis örneğinin kullanıcılara kümelenmemiş gibi görünmesini sağlarken, multi-key komutlarıyla ilgili bazı sınırlamaları vardır.

Kümelenmemiş (önizleme) kümeleme ilkesi verileri parçalama olmadan her düğümde depolar. Yalnızca 25 GB ve daha küçük boyutlu önbellekler için geçerlidir. Kümelenmemiş (önizleme) kümeleme ilkesini kullanma senaryoları şunlardır:

• Parçalanmamış bir Redis ortamından geçiş yaparken. Örneğin, Redis için Azure Cache'in Temel, Standart ve Premium SKU'larının parçalanmamış topolojileri.
• Çapraz yuva komutlarını yoğun bir şekilde çalıştırırken ve verileri parçalara bölerken hatalara neden olabilir. Örneğin, MULTI komutları.
• Redis'i ileti aracı olarak kullanırken ve parçalama gerekmiyorsa.

Kümelenmemiş (Önizleme) ilkesini kullanma konusunda dikkat edilmesi gerekenler şunlardır:

• Bu yalnızca 25 GB'tan küçük veya buna eşit Azure Yönetilen Redis katmanları için geçerlidir.
• CPU'lar yalnızca önbellek parçalandığında Redis Enterprise yazılımıyla çoklu iş parçacıklı çalışabileceğinden, diğer kümeleme politikaları kadar performanslı değildir.
• Azure Yönetilen Redis önbelleğinizin ölçeğini genişletmek istiyorsanız, önce küme ilkesini değiştirmeniz gerekir.
• Temel, Standart veya Premium kümelenmemiş topolojiden geçiyorsanız performansı artırmak için OSS kümelerini kullanmayı göz önünde bulundurun. Kümelenmemiş yapılandırmalar yalnızca uygulama OSS veya Kurumsal topolojileri destekleyemiyorsa kullanılmalıdır.

Ölçeği genişletme veya düğüm ekleme

Çekirdek Redis Enterprise yazılımı, ölçeği artırıp (daha büyük VM'leri kullanarak) veya ölçeği genişletebilir (daha fazla düğüm/VM ekleyerek). Sonuç olarak, ölçeklendirme eylemi aynı şeyi gerçekleştirir; daha fazla bellek, daha fazla vCPU ve daha fazla parça ekler. Bu yedeklilik nedeniyle Azure Yönetilen Redis, her yapılandırmada kullanılan belirli düğüm sayısını denetleme olanağı sunmaz. Bu uygulama ayrıntıları kullanıcının karışıklığı, karmaşıklığı ve en iyi olmayan yapılandırmaları önlemesi için özetlenmiştir. Bunun yerine her SKU, vCPU'ları ve belleği en üst düzeye çıkarmak için bir düğüm yapılandırmasıyla tasarlanmıştır. Azure Yönetilen Redis'in bazı SKU'ları yalnızca iki düğüm kullanırken bazıları daha fazlasını kullanır.

Çoklu tuş komutları

Azure Yönetilen Redis örnekleri kümelenmiş bir yapılandırmayla tasarlandığından, birden çok anahtar üzerinde çalışan komutlarda özel durumlar görebilirsiniz CROSSSLOT . Davranış, kullanılan kümeleme ilkesine bağlı olarak değişiklik gösterir. OSS kümeleme ilkesini kullanıyorsanız, çok anahtarlı komutlar tüm anahtarların aynı karma yuvaya eşlenmesini gerektirir.

Enterprise kümelenme politikası ile CROSSSLOT hatalarını da görebilirsiniz. Enterprise kümeleme ile yuvalar arasında yalnızca şu çoklu tuş komutlarına izin verilir: DEL, MSET, MGET, EXISTS, UNLINK, ve TOUCH.

Active-Active veritabanlarında, çoklu tuş yazma komutları (DEL, MSET, UNLINK) yalnızca aynı yuvadaki tuşlar üzerinde çalıştırılabilir. Ancak, Active-Active veritabanlarındaki yuvalar arasında aşağıdaki çoklu tuş komutlarına izin verilir: MGET, EXISTS, ve TOUCH. Daha fazla bilgi için bkz. Veritabanı kümeleme.

Parçalama yapılandırması

Azure Yönetilen Redis'in her SKU'su, belirli sayıda Redis sunucu işlemini, parçaları paralel olarak çalıştıracak şekilde yapılandırılır. Aktarım hızı performansı, parça sayısı ve her örnekte kullanılabilen vCPU sayısı arasındaki ilişki karmaşıktır. Redis işlemleri paralel olarak çalıştırılabildiği için parça eklemek genellikle performansı artırır. Ancak, komutları yürütmek için kullanılabilir vCPU olmadığından parçalar komutları çalıştıramıyorsa performans gerçekten düşebilir. Aşağıdaki tabloda her Azure Yönetilen Redis SKU'su için parçalama yapılandırması gösterilmektedir. Bu parçalar, her bir vCPU'nun kullanımını iyileştirmek için eşlenir ve performansı da etkileyen Redis Enterprise ara sunucusu, yönetim aracısı ve işletim sistemi görevleri için vCPU döngüleri rezerve edilmiştir.

Uyarı

Azure Yönetilen Redis, her SKU'da kullanılan parça ve vCPU sayısını değiştirerek zaman içinde performansı iyileştirir.

Önemli

Bellek için İyileştirilmiş M150 ve üzeri dahil olmak üzere 120 GB'ın üzerinde depolama alanı kullanan tüm bellek içi katmanlar Genel Önizleme aşamasındadır; Dengeli B150 ve üzeri; ve İşlem için İyileştirilmiş X150 ve üzeri. Tüm bu katmanlar ve üzeri Genel Önizleme aşamasındadır.

Flash için İyileştirilmiş tüm katmanlar herkese açık önizleme aşamasındadır.

Seviyeler	Flash Optimizasyonlu (önizleme)	Bellek Optimizasyonu Yapılmış	Dengeli	Hesaplama için İyileştirilmiş
Boyut (GB)	vCPU'lar/birincil parçalar	vCPU'lar/birincil parçalar	vCPU'lar/birincil parçalar	vCPU'lar/birincil parçalar
0,5	-	-	2/1	-
1	-	-	2/1	-
3	-	-	2/2	4/2
6	-	-	2/2	4/2
12	-	2/2	4/2	8/6
yirmi dört	-	4/2	8/6	16 Aralık
60	-	8/6	16 Aralık	32/24
120	-	16 Aralık	32/24	64/48
180 *	-	Tam zamanlı 24 saat hizmet	48/48	96/96
240 *	8/6	32/24	64/48	128/96
360 *	-	48/48	96/96	192/192
480 *	16 Aralık	64/48	128/96	256/192
720 *	Tam zamanlı 24 saat hizmet	96/96	192/192	384/384
960 *	32/24	128/192	256/192	-
1440 *	48/48	192/192	-	-
1920 *	64/48	256/192	-	-
4500 *	144/96	-	-	-

* Bu katmanlar Genel Önizleme aşamasındadır.

Yüksek kullanılabilirlik modu etkin olmadan çalıştırma

Yüksek kullanılabilirlik (HA) modu etkinleştirilmeden çalıştırabilirsiniz. Bu, Redis örneğinizde çoğaltmanın etkinleştirilmediği ve kullanılabilirlik SLA'sına erişimi olmadığı anlamına gelir. Geliştirme/test senaryoları dışında HA olmayan modda çalıştırmanızı önermeyiz. Önceden oluşturulmuş bir örnekte yüksek kullanılabilirliği devre dışı bırakamazsınız. Ancak, buna sahip olmayan bir örnekte yüksek kullanılabilirliği etkinleştirebilirsiniz. Yüksek kullanılabilirlik olmadan çalışan bir örnek daha az VM/düğüm kullandığından, vCPU'lar verimli bir şekilde kullanılamaz, bu nedenle performans daha düşük olabilir.

Ayrılmış bellek

Her Azure Yönetilen Redis Örneğinde, yük devretme sırasında çoğaltma ve etkin coğrafi çoğaltma arabelleği gibi önbellek dışı işlemler için kullanılabilir belleğin yaklaşık %20'si arabellek olarak ayrılır. Bu arabellek, önbellek performansını iyileştirmeye ve bellek yetersizliğini önlemeye yardımcı olur.

Ölçek küçültme

Ölçeği azaltma şu anda Azure Yönetilen redis'te desteklenmiyor. Daha fazla bilgi için bkz. Azure Yönetilen Redis'i ölçeklendirme sınırlamaları.

Flash için İyileştirilmiş katman

Flash için İyileştirilmiş katman hem NVMe Flash depolamayı hem de RAM'i kullanır. Flash depolama daha düşük maliyetli olduğundan, Flash İyileştirilmiş katmanını kullanmak, fiyat verimliliği için bazı performanstan ödün vermenizi sağlar.

Flash için İyileştirilmiş örneklerde önbellek alanının %20'sini RAM kullanırken, diğer %80'i Flash depolamayı kullanır. Tüm anahtarlar RAM'de depolanırken, değerler Flash depolama alanında veya RAM'de depolanabilir. Redis yazılımı, değerlerin konumunu akıllı bir şekilde belirler. Sık erişilen değerler RAM'de depolanırken daha az kullanılan Soğuk değerler Flash'ta tutulur. Veriler okunmadan veya yazılmadan önce RAM'e taşınarak Sık Erişimli veri haline gelmesi gerekir.

Redis en iyi performans için iyileştirdiğinden, örnek Flash depolamaya öğe eklemeden önce kullanılabilir RAM'i doldurur. ÖNCE RAM'i doldurmanın performans açısından birkaç etkisi vardır:

• Düşük bellek kullanımıyla test yaparken daha iyi performans ve daha düşük gecikme süresi oluşabilir. Tam önbellek örneğiyle test etme, düşük bellek kullanımı test aşamasında yalnızca RAM kullanıldığından daha düşük performans sağlayabilir.
• Önbelleğe daha fazla veri yazarken, RAM'deki verilerin Flash depolamaya kıyasla oranı azalır ve genellikle gecikme süresi ve aktarım hızı performansının da düşmesine neden olur.

Flash'a Optimize Edilmiş Katman İçin Uygun İş Yükleri

Flash için İyileştirilmiş katmanında iyi çalışma olasılığı olan iş yükleri genellikle aşağıdaki özelliklere sahiptir:

• Okuma komutlarının yazma komutlarına oranı yüksek olan yoğun okuma.
• Access, veri kümesinin geri kalanından çok daha sık kullanılan anahtarların bir alt kümesine odaklanır.
• Anahtar adlarıyla karşılaştırıldığında görece büyük değerler. (Anahtar adları her zaman RAM'de depolandığından, büyük değerler bellek büyümesi için bir tıkanıklığa neden olabilir.)

Flash İyileştirilmiş katmanı için uygun olmayan iş yükleri

Bazı iş yükleri, Flash için İyileştirilmiş katmanın tasarımı için daha az iyileştirilmiş erişim özelliklerine sahiptir:

• Yoğun iş yükleri oluşturma.
• Veri kümesinin çoğunda rastgele veya tekdüzen veri erişim desenleri.
• Nispeten küçük değer boyutlarına sahip uzun anahtar adları.

İlgili içerik

• Azure Yönetilen Redis örneğini ölçeklendirme