Kurumsal ve Kurumsal Flash katmanları için en iyi yöntemler nelerdir?
Redis için Azure Cache Kurumsal ve Kurumsal Flash katmanlarını kullanırken en iyi yöntemler aşağıdadır.
Alanlar Arası Yedeklilik
Yeni önbellekleri alanlar arası yedekli bir yapılandırmaya dağıtmanızı kesinlikle öneririz. Alanlar arası yedeklilik, Redis Enterprise düğümlerinin üç kullanılabilirlik alanına yayılmasını sağlayarak veri merkezi düzeyindeki kesintilerden kaynaklanan yedekliliği artırır. Alanlar arası yedeklilik kullanılması kullanılabilirliği artırır. Daha fazla bilgi için bkz . Çevrimiçi Hizmetler için Hizmet Düzeyi Sözleşmeleri (SLA).
Önbellek örneğiniz her zaman en az üç düğüm kullandığından, Kurumsal katmanda alanlar arası yedeklilik önemlidir. İki düğüm, verilerinizi tutan veri düğümleri ve bir çekirdek düğümü vardır. Kapasitenin artırılması, veri düğümlerinin sayısını çift sayı artışlarıyla ölçeklendirir.
Çekirdek düğümü adlı başka bir düğüm de vardır. Bu düğüm veri düğümlerini izler ve yük devretme varsa yeni birincil düğümü otomatik olarak seçer. Alanlar arası yedeklilik, düğümlerin üç kullanılabilirlik alanına eşit dağıtılmasını sağlayarak çekirdek kaybı olasılığını en aza indirir. Müşteriler çekirdek düğümü için ücretlendirilmiyor ve bölge içi bant genişliği ücretlerinin ötesinde alanlar arası yedeklilik kullanmak için başka bir ücret alınmaz.
Ölçeklendirme
Redis için Azure Cache Kurumsal ve Kurumsal Flash katmanlarında ölçeği genişletmeye göre artırmaya önceliklendirmenizi öneririz. Kurumsal katmanlar daha büyük VM'lerde daha fazla CPU çekirdeği kullanabilen Redis Enterprise üzerinde oluşturulduğundan ölçeği artırmaya öncelik verme.
Buna karşılık, açık kaynak Redis üzerinde oluşturulan Temel, Standart ve Premium katmanları için tam tersi bir öneri geçerlidir. Bu katmanlarda çoğu durumda ölçeği artırmaya göre ölçeği genişletmeyi önceliklendirmek önerilir.
Parçalama ve CPU kullanımı
Redis için Azure Cache Temel, Standart ve Premium katmanlarında kullanılan sanal CPU'ların (vCPU) sayısını belirlemek basittir. Her Redis düğümü ayrılmış bir sanal makinede (VM) çalışır. Redis sunucu işlemi tek iş parçacıklı olup her birincil ve her çoğaltma düğümünde bir vCPU kullanılır. VM'de bulunan diğer vCPU'lar, farklı görevler için iş akışı koordinasyonu, sistem durumu izleme ve TLS yükü gibi diğer etkinliklerde de kullanılır.
Kümeleme kullandığınızda, bunun etkisi verileri düğüm başına bir parça ile daha fazla düğüme yaymaktır. Parça sayısını artırarak, kümedeki parça sayısına göre kullandığınız vCPU sayısını doğrusal olarak artırırsınız.
Öte yandan Redis Enterprise, Redis örneğinin kendisi için birden çok vCPU kullanabilir. Başka bir deyişle, Redis için Azure Cache tüm katmanları arka plan ve izleme görevleri için birden çok vCPU kullanabilir, ancak yalnızca Kurumsal ve Kurumsal Flash katmanları Redis parçaları için VM başına birden çok vCPU kullanabilir. Tabloda, her SKU ve kapasite (yani ölçeği genişletme) yapılandırması için kullanılan etkin vCPU sayısı gösterilir.
Tablolar, çoğaltma parçaları için değil birincil parçalar için kullanılan vCPU sayısını gösterir. Parçalar vCPU sayısıyla bire bir eşleşmez. Tablolarda parçalar değil yalnızca vCPU'lar gösterilmektedir. Bazı yapılandırmalar, bazı kullanım senaryolarında performansı artırmak için kullanılabilir vCPU'lardan daha fazla parça kullanır.
E1
| Kapasite | Etkili vCPU'lar |
|---|---|
| 2 | 1 (serileştirilebilir) |
E5
| Kapasite | Etkili vCPU'lar |
|---|---|
| 2 | 1 |
| 4 | 2 |
| 6 | 6 |
E10
| Kapasite | Etkili vCPU'lar |
|---|---|
| 2 | 2 |
| 4 | 6 |
| 6 | 6 |
| 8 | 16 |
| 10 | 20 |
E20
| Kapasite | Etkili vCPU'lar |
|---|---|
| 2 | 2 |
| 4 | 6 |
| 6 | 6 |
| 8 | 16 |
| 10 | 20 |
E50
| Kapasite | Etkili vCPU'lar |
|---|---|
| 2 | 6 |
| 4 | 6 |
| 6 | 6 |
| 8 | 30 |
| 10 | 30 |
E100
| Kapasite | Etkili vCPU'lar |
|---|---|
| 2 | 6 |
| 4 | 30 |
| 6 | 30 |
| 8 | 30 |
| 10 | 30 |
E200
| Kapasite | Etkili vCPU'lar |
|---|---|
| 2 | 30 |
| 4 | 60 |
| 6 | 60 |
| 8 | 120 |
| 10 | 120 |
E400
| Kapasite | Etkili vCPU'lar |
|---|---|
| 2 | 60 |
| 4 | 120 |
| 6 | 120 |
| 8 | 240 |
| 10 | 240 |
F300
| Kapasite | Etkili vCPU'lar |
|---|---|
| 3 | 6 |
| 9 | 30 |
F700
| Kapasite | Etkili vCPU'lar |
|---|---|
| 3 | 30 |
| 9 | 30 |
F1500
| Kapasite | Etkili vCPU'lar |
|---|---|
| 3 | 30 |
| 9 | 90 |
Enterprise'da Kümeleme
Kurumsal ve Kurumsal Flash katmanları, Temel, Standart ve Premium katmanlarının aksine doğal olarak kümelenir. Uygulama, seçilen kümeleme ilkesine bağlıdır. Kurumsal katmanlar Kümeleme İlkesi için iki seçenek sunar: OSS ve Enterprise. Ç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, açık kaynak Redis ile aynı Redis Kümesi API'sini uygular. Redis Kümesi API'si, Redis istemcisinin her Redis düğümüne doğrudan bağlanmasını sağlayarak gecikme süresini en aza indirir ve ağ aktarım hızını en iyi duruma getirir. Sonuç olarak, kümenin ölçeği daha fazla düğümle genişletilirken neredeyse doğrusal ölçeklenebilirlik elde edilir. OSS kümeleme ilkesi genellikle en iyi gecikme süresi ve aktarım hızı performansını sağlar, ancak istemci kitaplığınızın Redis Kümelemini desteklemesini gerektirir. OSS kümeleme ilkesi, RediSearch modülüyle de kullanılamaz.
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ı, Redis istemci kitaplıklarının birden çok düğümden yararlanmak için Redis Kümelemini desteklemesi gerekmeyecek olmasıdır. Bunun dezavantajı, tek düğüm proxy'sinin işlem kullanımında veya ağ aktarım hızında bir performans sorunu olmasıdır. RediSearch modülüyle kullanılabilen tek ilke Kurumsal kümeleme ilkesidir.
Çok tuşlu komutlar
Kurumsal katmanlar kümelenmiş yapılandırma kullandığından, birden çok anahtar üzerinde çalışan komutlarda özel durumlar görebilirsiniz CROSSSLOT . Davranış, kullanılan kümeleme ilkesine bağlı olarak değişir. OSS kümeleme ilkesini kullanırsanız, çok anahtarlı komutlar tüm anahtarların aynı karma yuvaya eşlenmesi gerekir.
Kurumsal kümeleme ilkesiyle ilgili hatalar da görebilirsiniz CROSSSLOT . Kurumsal kümeleme ile yuvalar arasında yalnızca aşağıdaki çok anahtarlı komutlara izin verilir: DEL, MSET, MGET, EXISTS, , UNLINKve TOUCH.
Active-Active veritabanlarında, çok anahtarlı yazma komutları (DEL, MSET, UNLINK) yalnızca aynı yuvadaki anahtarlarda çalıştırılabilir. Ancak, Active-Active veritabanlarındaki yuvalar arasında aşağıdaki çok tuşlu komutlara izin verilir: MGET, EXISTSve TOUCH. Daha fazla bilgi için bkz . Veritabanı kümeleme.
Kurumsal Flash En İyi Yöntemleri
Enterprise Flash katmanı hem NVMe Flash depolamayı hem de RAM'i kullanır. Flash depolama daha düşük maliyetli olduğundan Enterprise Flash katmanını kullanmak, fiyat verimliliği için bazı performanstan ödün vermenizi sağlar.
Enterprise Flash örneklerinde ö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 sık erişimli 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.
Kurumsal Flash katmanı için uygun iş yükleri
Kurumsal Flash 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 performans sorununa neden olabilir.)
Kurumsal Flash katmanı için uygun olmayan iş yükleri
Bazı iş yükleri, Flash katmanının tasarımı için daha az iyileştirilmiş erişim özelliklerine sahiptir:
- Yoğun iş yükleri yazma.
- Veri kümesinin çoğunda rastgele veya tekdüzen veri erişim desenleri.
- Nispeten küçük değer boyutlarına sahip uzun anahtar adları.
Etkin Coğrafi Çoğaltma ile Bölge Aşağı Senaryolarını İşleme
Etkin coğrafi çoğaltma, Redis için Azure Cache Kurumsal katmanlarını kullanırken kullanılabilirliği önemli ölçüde artırmaya yönelik güçlü bir özelliktir. Ancak bölgesel bir kesinti olduğunda önbelleklerinizi hazırlamak için adımlar atmalısınız.
Örneğin, şu ipuçlarını göz önünde bulundurun:
- Bir bölge kapanırsa coğrafi çoğaltma grubundaki diğer hangi önbelleğe geçebileceğinizi önceden belirleyin.
- Tüm uygulamaların ve istemcilerin tanımlanan yedekleme önbelleğine erişebilmesi için güvenlik duvarlarının ayarlandığından emin olun.
- Coğrafi çoğaltma grubundaki her önbelleğin kendi erişim anahtarı vardır. Yedekleme önbelleğini hedeflerken uygulamanın farklı erişim anahtarlarına nasıl geçiş yapılacağını belirleyin.
- Coğrafi çoğaltma grubundaki bir önbellek devre dışı kalırsa, coğrafi çoğaltma grubundaki tüm önbelleklerde meta veriler birikmeye başlar. Yazma işlemleri tüm önbelleklerle yeniden eşitleninceye kadar meta veriler atılamaz. Meta verilerin birikmesini engellemek için, devre dışı olan önbelleğin bağlantısını zorla kaldırabilirsiniz. Önbellekteki kullanılabilir belleği izlemeyi ve özellikle yoğun yazma iş yükleri için bellek baskısı varsa bağlantıyı kaldırmayı göz önünde bulundurun.
Devre kesici deseni de kullanılabilir. Bölge kesintisi yaşayan bir önbellekten trafiği otomatik olarak ve aynı coğrafi çoğaltma grubundaki bir yedekleme önbelleğine yönlendirmek için deseni kullanın. Yeniden yönlendirmeyi etkinleştirmek için Azure Traffic Manager veya Azure Load Balancer gibi Azure hizmetlerini kullanın.
Veri Kalıcılığı ve Veri Yedekleme karşılaştırması
Kurumsal ve Kurumsal Flash katmanlarında veri kalıcılığı özelliği, önbellek kapandığında veriler için otomatik olarak hızlı bir kurtarma noktası sağlayacak şekilde tasarlanmıştır. Hızlı kurtarma, RDB veya AOF dosyasını önbellek örneğine bağlı bir yönetilen diskte depolayarak mümkün hale getirilir. Disk üzerindeki kalıcılık dosyalarına kullanıcılar erişemez.
Birçok müşteri, önbelleklerindeki verilerin düzenli aralıklarla yedeklerini almak için kalıcılığı kullanmak ister. Veri kalıcılığını bu şekilde kullanmanızı önermeyiz. Bunun yerine içeri/dışarı aktarma özelliğini kullanın. Önbellek verilerinin kopyalarını RDB biçiminde doğrudan seçtiğiniz depolama hesabına aktarabilir ve veri dışarı aktarma işlemini istediğiniz sıklıkta tetikleyebilirsiniz. Dışarı aktarma işlemi portaldan veya CLI, PowerShell veya SDK araçları kullanılarak tetiklenebilir.
E1 SKU Sınırlamaları
E1 SKU'su öncelikli olarak geliştirme/test senaryolarına yöneliktir. E1, daha küçük serileştirilebilir VM'lerde çalışır. Hızla artırılabilir VM'ler, tüketilen CPU miktarına göre değişken performans sunar. Diğer Kurumsal SKU tekliflerinden farklı olarak E1 SKU'sunun ölçeğini genişletemezsiniz ancak ölçeği daha büyük bir SKU'ya genişletmek mümkündür. E1 SKU'su etkin coğrafi çoğaltmayı da desteklemez.