Azure VM'lerinde Apache Cassandra çalıştırma

Dikkat

Bu makale, destek sonuna ulaşmış bir Linux dağıtımı olan CentOS'a başvurur. Kullanımınızı göz önünde bulundurun ve buna göre planlayın. Daha fazla bilgi için bkz. CentOS destek sonu kılavuzu.

Bu makalede, Azure Sanal Makineler'de Apache Cassandra'nın çalıştırılmasıyla ilgili performans konuları açıklanmaktadır.

Bu öneriler, iç performans testlerinin sonuçlarını temel alır. Bu önerileri temel olarak kullanın ve ardından kendi iş yükünüzle test edin.

Apache Cassandra için Azure Yönetilen Örnek

Azure Sanal Makineleri'nde Apache Cassandra çalıştırmak için daha otomatik bir hizmet arıyorsanız, Azure Yönetilen Örneği'nin Apache Cassandra için kullanmayı düşünebilirsiniz. Bu hizmet, Apache Cassandra kümesi içindeki düğümlerin dağıtımını, yönetimini (düzeltme eki uygulama ve düğüm durumu) ve ölçeklendirmesini otomatikleştirir. Ayrıca karma kümeler için de özellik sağlar, böylece Azure'da dağıtılan Apache Cassandra veri merkezleri mevcut şirket içi veya üçüncü taraf barındırılan Cassandra halkalarına katılabilir. Hizmet, Azure Sanal Makine Ölçek Kümeleri kullanılarak dağıtılır. Bu hizmetin geliştirilmesi sırasında aşağıdaki öneriler benimsenmiştir.

Azure VM boyutları ve disk türleri

Azure'da Cassandra iş yükleri genellikle Standard_DS14_v2, Standard_DS13_v2, Standard_D16s_v5 veya Standard_E16s_v5 sanal makineleri kullanır. Cassandra iş yükleri VM'de daha fazla belleğe sahip olmanın avantajından yararlandığından, Standard_DS14_v2 veya Standard_E16s_v5 gibi bellek için iyileştirilmiş sanal makine boyutlarını ya da Standard_L16s_v3 gibi yerel depolama için iyileştirilmiş boyutları göz önünde bulundurun.

Dayanıklılık için veri ve işleme günlükleri genellikle iki ile dört adet 1 TB Premium SSD (P30) arasında bir şerit kümesinde depolanır.

Cassandra düğümleri çok fazla veri içermemelidir. VM başına en fazla 1 ila 2 TB veriye ve sıkıştırma için yeterli boş alana sahip olmasını öneririz. Premium SSD'leri kullanarak mümkün olan en yüksek birleşik aktarım hızını ve IOPS'yi elde etmek için, tek bir 2 TB veya 4 TB disk kullanmak yerine birkaç 1 TB diskten şerit kümesi oluşturmanızı öneririz. Örneğin, bir DS14_v2 VM'de, dört 1 TB disk en fazla 4 × 5000 = 20 K IOPS'ye ve tek bir 4 TB disk için 7,5 K'ye sahiptir.

Daha küçük disk kapasitesine ihtiyaç duyan Cassandra iş yükleri için Azure Ultra Diskleri değerlendirin. Standard_E16s_v5 ve Standard_D16s_v5 gibi VM boyutlarında daha yüksek IOPS/aktarım hızı ve daha düşük gecikme süresi sağlayabilir.

Dayanıklı depolama gereksinimi olmayan cassandra iş yükleri için (başka bir depolama alanından kolayca verilerin yeniden oluşturulabileceği), Standard_L16s_v3 veya Standard_L16s_v2 VM'leri kullanmayı göz önünde bulundurun. Bu VM boyutlarının büyük ve hızlı yerel geçici NVM Express (NVMe) diskleri vardır.

Hızlandırılmış Ağ

Cassandra düğümleri, istemci VM'den veri gönderip almak ve çoğaltma için düğümler arasında iletişim kurmak için ağı yoğun bir şekilde kullanır. En iyi performans için Cassandra VM'leri yüksek aktarım hızı ve düşük gecikme süresine sahip ağdan yararlanır.

Cassandra düğümünün NIC'sinde ve Cassandra'ya erişen istemci uygulamalarını çalıştıran VM'lerde Hızlandırılmış Ağ'ı etkinleştirmenizi öneririz.

Hızlandırılmış Ağ, Cent OS 7.5+ veya Ubuntu 16.x/18.x gibi en son sürücülerle modern bir Linux dağıtımı gerektirir. Daha fazla bilgi için bkz . Hızlandırılmış Ağ ile Linux sanal makinesi oluşturma.

Azure VM veri diski önbelleğe alma

Cassandra okuma iş yükleri, rastgele erişimli disk gecikme süresi düşük olduğunda en iyi performansı gösterir. Azure yönetilen diskleri ReadOnly önbelleğe alma etkinken kullanmanızı öneririz. Veriler arka uç depolama alanına gitmek yerine konak üzerindeki önbellekten okunduğu için ReadOnly önbelleğe alma daha düşük ortalama gecikme süresi sağlar.

Cassandra gibi okuma ağırlıklı, rastgele okuma yapılan iş yükleri, önbelleğe alınmış modun işlem hacmi limitleri, önbelleğe alınmamış moda göre daha düşük olsa da, daha düşük okuma gecikmesi süresinden faydalanır. (Örneğin, DS14_v2 sanal makinelerin, önbelleğe alınmış aktarım hızı maksimum 512 MB/sn iken, önbelleğe alınmamış 768 MB/sn'dir.)

ReadOnly önbelleğe alma, Cassandra zaman serisi ve çalışma veri kümesinin sunucu önbelleğine sığdığı ve verilerin sürekli olarak üzerine yazılmadığı diğer iş yükleri için özellikle yararlıdır. Örneğin, DS14_v2 512 GB önbellek boyutu sağlar ve bu boyut 1-2 TB veri yoğunluğuna sahip cassandra düğümündeki verilerin %50'sine kadar depolanabilir.

ReadOnly önbelleğe alma aktif olduğunda önbellek kaçmalarından önemli bir performans kaybı yaşanmaz, bu nedenle en yoğun yazma gerektiren iş yükleri dışında önbelleğe alınmış mod önerilir.

Linux önceden okuma

Microsoft Market'te Azure için kullanılabilen çoğu Linux dağıtımında varsayılan blok cihazı okuma ayarı 4096 KB'tır. Cassandra'nın okuma G/Ç'leri genellikle rastgele ve nispeten küçüktür. Bu nedenle, büyük bir önceden okuma özelliğine sahip olmak, dosyaların gerekli olmayan bölümlerini okuyarak aktarım hızını boşa harcar.

Gereksiz ön okumayı en aza indirmek için Linux blok cihazı okuma önbelleğini 8 KB olarak ayarlayın. (Bkz. DataStax belgelerinde önerilen üretim ayarları .)

Şerit kümesindeki ve dizi cihazının kendisindeki tüm blok cihazları için 8 KB önceden okuma özelliğini yapılandırın (örneğin, /dev/md0).

Disk dizisi mdadm parça boyutu

Azure'da Cassandra'yı çalıştırırken genel disk aktarım hızını ve IOPS'yi VM sınırlarına yakın bir şekilde artırmak için birden çok veri diskinden oluşan bir mdadm şerit kümesi (RAID 0) oluşturmak yaygın bir durumdur. En uygun disk şerit boyutu, uygulamaya özgü bir ayardır. Örneğin, SQL Server OLTP iş yükleri için öneri 64 KB'tır. Veri ambarı iş yükleri için öneri 256 KB'tır.

Testlerimiz Cassandra okuma iş yükleri için 64k, 128k ve 256k öbek boyutları arasında önemli bir fark bulamadı. 128k veri parçası boyutuna göre küçük ama biraz fark edilebilir bir avantaj var gibi görünüyor. Bu nedenle aşağıdaki yaklaşımları öneririz:

  • Zaten 64 K veya 256 K öbek boyutu kullanıyorsanız, disk dizisini 128-K boyutu kullanacak şekilde yeniden oluşturmak mantıklı değildir.

  • Yeni bir yapılandırma için en baştan 128 K kullanmak mantıklıdır.

Günlük dosya sistemini işleme

Cassandra yazma işlemleri, işleme günlükleri yüksek aktarım hızına ve düşük gecikme süresine sahip disklerde olduğunda en iyi performansı gösterir. Varsayılan yapılandırmada Cassandra 3.x verileri bellekten işleme günlük dosyasına yaklaşık 10 saniyede bir temizler ve her yazma işlemi için diske dokunmaz. Bu yapılandırmada yazma performansı, işleme günlüğünün premium ekli disklerde olmasıyla yerel/kısa ömürlü diskler arasındaki neredeyse aynıdır.

Yeniden başlatılan bir düğümün boşaltılan işleme günlüklerindeki veri dosyalarında henüz bulunmayan verileri yeniden oluşturabilmesi için işleme günlüklerinin dayanıklı olması gerekir. Daha iyi dayanıklılık için işleme günlüklerini yerel depolamada değil Premium SSD'lerde depolayın. Bu, VM başka bir konağa geçirilirse kaybolabilir.

Testlerimize bağlı olarak, yürütme günlükleri xfs'de ve ext4 dosya sisteminde olduğunda CentOS 7.x üzerindeki Cassandra daha düşük yazma performansına sahip olabilir. İşleme günlüğü sıkıştırmayı açmak xfs performansını ext4 ile uyumlu hale getirir. Sıkıştırılmış xfs, testlerimizde sıkıştırılmış ve sıkıştırılmamış ext4'e ek olarak performans gösterir.

Temel VM performansını ölçme

Cassandra halkası için VM'leri dağıttığınızda temel ağ ve disk performansı oluşturmak için birkaç yapay test çalıştırın. Performansın VM boyutuna göre beklentilere uygun olduğunu doğrulamak için bu testleri kullanın.

Daha sonra gerçek iş yükünü çalıştırdığınızda performans temelini bilmek olası performans sorunlarını araştırmayı kolaylaştırır. Örneğin, VM'de ağ çıkışının temel performansını bilmek, ağı darboğaz olarak elenebilmesine yardımcı olabilir.

Belge boyutu

Cassandra okuma ve yazma performansı belge boyutuna bağlıdır. Daha büyük belgeler okurken veya yazarken daha yüksek gecikme süresi ve daha düşük işlem/saniye görmeyi bekleyebilirsiniz.

Replikasyon faktörü

Cassandra iş yüklerinin çoğu, ekli premium diskler kullanırken 3 çoğaltma faktörü (RF) ve geçici/kısa ömürlü yerel diskler kullandıklarında bile 5 kullanır. Cassandra kademesindeki düğüm sayısı çoğaltma faktörünün bir katı olmalıdır. Örneğin, RF 3 3, 3, 6, 9 veya 12 düğümlerin halkasını ifade ederken, RF 5'in 5, 10, 15 veya 20 düğümü olur. 1'den büyük RF ve tutarlılık düzeyi LOCAL_QUORUM kullandığınızda, okuma ve yazma performansının RF 1 ile çalışan aynı iş yükünden daha düşük olması normaldir.

Linux sayfası önbelleğe alma

Cassandra'nın Java kodu veri dosyalarını okuduğunda, normal dosya G/Ç kullanır ve Linux sayfa önbelleğinden yararlanır. Dosyanın bölümleri bir kez okunduktan sonra, okuma içeriği işletim sistemi sayfası önbelleğinde depolanır. Aynı verilere daha sonra okuma erişimi çok daha hızlıdır.

Bu nedenle, aynı verilerde okuma performansı testleri yürütürken, ikinci ve sonraki okumalar, uzak veri diskinde veya ReadOnly etkinleştirildiğinde konak önbelleğindeki verilere erişmek için gereken özgün okumadan çok daha hızlı görünür. Sonraki çalıştırmalarda benzer performans ölçümleri almak için Linux sayfa önbelleğini temizleyin ve iç belleğini temizlemek için Cassandra hizmetini yeniden başlatın. ReadOnly önbelleğe alma etkinleştirildiğinde, veriler konak önbelleğinde olabilir ve işletim sistemi sayfa önbelleği temizlenip Cassandra hizmeti yeniden başlatıldıktan sonra bile sonraki okumalar daha hızlı olur.

Çoklu veri merkezi replikasyonu

Cassandra, birden çok veri merkezi kavramını yerel olarak desteklediğinden, birden çok Azure bölgesinde veya bir bölgedeki kullanılabilirlik alanlarında bir Cassandra halkası yapılandırmayı kolaylaştırır.

Çok bölgeli dağıtım için Azure Genel Sanal Ağ eşlemesini kullanarak farklı bölgelerdeki sanal ağları bağlayın. VM'ler aynı bölgede ama ayrı kullanılabilirlik alanlarında dağıtıldığında, VM'ler aynı sanal ağda olabilir.

Bölgeler arasındaki temel gidiş dönüş gecikme süresini ölçmek önemlidir. Bölgeler arasındaki ağ gecikme süresi, bir bölge içindeki gecikme süresinden 10-100 kat daha yüksek olabilir. LOCAL_QUORUM yazma tutarlılığını kullandığınızda veya EACH_QUORUM kullandığınızda ikinci bölgede görünen veriler arasında bir gecikme bekleyin ya da yazma performansının önemli ölçüde düştüğünü gözlemleyin.

Apache Cassandra'yı büyük ölçekte ve özellikle çok DC'lik bir ortamda çalıştırdığınızda düğüm onarımı zorlaşır. Reaper gibi araçlar, onarımları büyük ölçekte koordine etmeye yardımcı olabilir; örneğin, kümenin tamamındaki yükü sınırlamak için her seferinde bir veri merkezi olacak şekilde bir veri merkezindeki tüm düğümler arasında. Ancak, büyük kümeler için düğüm onarımı çözümlenmemiş bir zorluk olmaya devam eder ve şirket içinde veya bulutta tüm ortamlarda geçerlidir.

İkincil bölgeye düğümler eklendiğinde, bölgeler arası çoğaltma trafiğini almak ve göndermek için bazı bant genişliği ve CPU/disk kaynakları harcandığından, performans doğrusal olarak ölçeklenmez.

İpucuyla iletim yapılandırması

Çok bölgeli Cassandra kümesinde, tutarlılık düzeyi LOCAL_QUORUM olan yazma iş yükleri, ikincil bölgedeki verileri kaybedebilir. Varsayılan olarak, Cassandra ipucu iletimi görece düşük bir maksimum aktarım hızı ve üç saatlik bir ipucu ömrü ile sınırlandırılır. Yoğun yazma işlemlerine sahip iş yüklerinde, ipuçlarının çoğaltılmadan önce kaybolmadığından emin olmak için ipucu aktarma sınırını ve ipucu penceresi süresini artırmamızı öneriyoruz.

Katkıda Bulunanlar

Microsoft bu makaleyi korur. Bu makaleyi aşağıdaki katkıda bulunanlar yazdı.

Asıl yazar:

Diğer katkıda bulunan:

Herkese açık olmayan LinkedIn profillerini görmek için LinkedIn'e oturum açın.

Sonraki adımlar

Azure'a özgü olmayan genel Cassandra ayarları hakkında daha fazla bilgi için bkz:

  • Last updated on