Azure VM 'lerinde Apache Cassandra çalıştırma
Bu makalede, Azure sanal makinelerinde Apache Cassandra çalıştırmaya yönelik performans konuları açıklanmaktadır.
Bu öneriler, GitHubbulabileceğiniz performans testlerinin sonuçlarına göre yapılır. Bu önerileri temel olarak kullanmalı ve sonra kendi iş yükünüze göre test etmelisiniz.
Apache Cassandra için Azure yönetilen örneği
Azure sanal makinelerinde Apache Cassandra çalıştırmaya yönelik daha otomatik bir hizmet arıyorsanız Apache Cassandra Için Azure yönetilen örneğinikullanmayı düşünün. Bu hizmet, bir Apache Cassandra kümesi içindeki dağıtım, Yönetim (düzeltme eki uygulama ve düğüm durumu) ve düğümlerin ölçeğini otomatik hale getirir. Ayrıca karma kümeleriçin özellik sağlar; bu nedenle Azure 'Da dağıtılan Apache Cassandra veri merkezleri var olan bir şirket içi veya üçüncü taraf barındırılan Cassandra halkasını katabilir. Hizmet, Azure sanal makine ölçek kümelerikullanı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 'daki Cassandra iş yükleri genellikle Standard_DS14_v2 ya da Standard_DS13_v2 sanal makineler kullanır. Cassandra iş yükleri VM 'de daha fazla bellek bulundurmaktan yararlanır, bu nedenle Standard_DS14_v2 gibi bellek için iyileştirilmiş sanal makine boyutlarını veya Standard_L16s_v2 gibi yerel depolama için iyileştirilmiş boyutları düşünün.
Dayanıklılık için, veri ve kayıt günlükleri genellikle iki ile 4 1 TB 'lik Premium yönetilen disk (P30) türünde bir dizili küme üzerinde depolanır.
Cassandra düğümleri çok fazla veri yoğun olmamalıdır. Her VM için en fazla 1 – 2 TB veri ve sıkıştırma için yeterli boş alan olmasını öneririz. Premium yönetilen diskleri kullanarak en yüksek olası Birleşik aktarım hızına ve ıOPS 'ye ulaşmak için, tek bir 2 TB veya 4 TB disk kullanmak yerine birkaç 1 TB 'lik diskten bir şerit kümesi oluşturmanızı öneririz. Örneğin, bir DS14_v2 VM 'de, 4 1 TB 'lik diskler, tek 4 TB 'lik bir disk için en fazla 4 × 5000 = 20 K ve 7,5 K olmalıdır.
Azure Ultra diskler bölgeler arasında daha yaygın kullanıma açık hale geldiğinde, bunları daha küçük disk kapasitesine Ihtiyaç duyulan Cassandra iş yükleri için değerlendirin. Bunlar, Standard_D32s_v3 ve Standard_D16s_v3gibi VM boyutlarında daha yüksek IOPS/aktarım hızı ve daha düşük gecikme sağlar.
Sürekli depolama gerektirmeyen Cassandra iş yükleri için (diğer bir deyişle, verilerin başka bir depolama ortamında kolayca yeniden yapılandırılması) Standard_L32s_v2 veya Standard_L16s_v2 VM 'leri kullanmayı düşünün. Bu VM boyutları, büyük ve hızlı yerel geçici NVMe disklerine sahiptir.
Daha fazla bilgi için bkz. Azure yerel/kısa ömürlü ile bağlı/kalıcı disklerin performansını karşılaştırma (GitHub).
Hızlandırılmış Ağ
Cassandra düğümleri, istemci VM 'sinden veri göndermek ve almak ve çoğaltma için düğümler arasında iletişim kurmak için ağın yoğun bir şekilde kullanılmasını sağlar. En iyi performans için, Cassandra VM 'Leri yüksek aktarım hızı ve düşük gecikmeli ağdan yararlanır.
Cassandra düğümünün NIC 'inde ve Cassandra 'ye erişen istemci uygulamaları çalıştıran VM 'lerde hızlandırılmış ağ etkinleştirmeyi öneririz.
Hızlandırılmış ağ, en son sürücülerle ilgili, sent OS 7.5 + veya Ubuntu 16. x/18. x gibi 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ği
Cassandra okuma iş yükleri, Rastgele erişimli disk gecikmesi azaldığında en iyi şekilde gerçekleştirilir. ReadOnly önbelleğe alma özelliği etkinken Azure yönetilen diskleri kullanmanızı öneririz. ReadOnly önbelleğe alma daha düşük ortalama gecikme süresi sağlar çünkü veriler, arka uç depolama alanına gitmek yerine konaktaki önbellekten okunur.
Önbelleğe alınmış mod, önbelleğe alınmamış moddan daha düşük aktarım hızı sınırlarına sahip olsa bile, daha düşük okuma gecikmesi olan Cassandra avantajı gibi okuma ağır, rastgele okuma iş yükleri. (Örneğin, DS14_v2 sanal makineler en fazla 512 MB/sn 'lik önbelleğe alınmış aktarım hızına ve 768 MB/sn 'ye karşılık
Salt okunur önbellek, Cassandra zaman serisi ve çalışma veri kümesinin konak önbelleğinde bulunduğu diğer iş yükleri ve verilerin sürekli olarak üzerine yazılmaması için yararlıdır. Örneğin DS14_v2 , 512 GB bir önbellek boyutu sağlar. Bu, bir Cassandra düğümünden, 1-2 TB veri yoğunluğu olan verilerin %50 ' e varan bir depolama alanı sağlar.
ReadOnly önbelleğe alma etkinleştirildiğinde önbellekte önemli bir performans cezası yoktur, bu nedenle en fazla yazma ağır iş yükü hariç olmak üzere önbelleğe alınmış mod önerilir.
Daha fazla bilgi için bkz. Azure VM veri diski önbelleğe alma yapılandırmasını karşılaştırma (GitHub).
Linux okuma-ileri
Azure Marketi 'ndeki çoğu Linux dağıtımında, varsayılan cihaz okuma/dağıtım ayarı 4096 KB 'tır. Cassandra 'ın Read IOs genellikle rastgele ve görece küçüktür. Bu nedenle, gerekli olmayan dosyaların parçalarını okuyarak büyük bir okuma öncesi boşa harcar iş hızına sahip olma.
Gereksiz ilermayı en aza indirmek için, Linux blok cihazı okuma öncesi ayarını 8 KB olarak ayarlayın. (DataStax belgelerindeki Önerilen üretim ayarlarına bakın.)
Dizili küme içindeki ve dizi cihazın kendisinde (örneğin,) tüm blok cihazlar için 8 KB okuma 'yı yapılandırın /dev/md0 .
Daha fazla bilgi için bkz. disk okuma öncesi ayarlarının etkisini karşılaştırma (GitHub).
Disk dizisi mdaddm öbek boyutu
Azure 'da Cassandra çalıştırırken, genel disk aktarım hızını ve ıOPS 'yi VM sınırlarına yaklaştırmak için birden fazla veri diskinin mdaddm Stripe kümesi (RAID 0) oluşturmak yaygındır. En iyi disk Stripe boyutu uygulamaya özgü bir ayardır. örneğin, SQL Server OLTP iş yükleri için öneri 64 KB 'dir. Veri ambarı iş yükleri için öneri 256 KB 'dir.
Testlerimiz, Cassandra okuma iş yükleri için 64K, 128k ve 256k öbek boyutları arasında önemli bir farklılık bulamadı. 128k öbek boyutunun küçük ve biraz fark edilebilir olması gibi görünüyor. Bu nedenle, şunları öneririz:
Zaten 64 K veya 256 K öbek boyutunu kullanıyorsanız, bu, disk dizisinin 128 K boyutunu kullanmak için yeniden derlenmesini sağlamaz.
Yeni bir yapılandırma için, baştan başlayarak 128 K 'yi kullanmaya yönelik bir yapılandırma sağlar.
Daha fazla bilgi için bkz. Cassandra performansı (GitHub) üzerinde mdaddm öbek boyutlarının etkilerini ölçme .
Günlük FileSystem 'ı Yürüt
Cassandra yazmaları, işleme günlüklerinin yüksek aktarım hızı ve düşük gecikme süresine sahip disklerde en iyi şekilde gerçekleştirilir. Varsayılan yapılandırmada, Cassandra 3. x bellekten verileri her saniyede kayıt günlük dosyasına boşaltır ve her yazma için diske dokunmaz. Bu yapılandırmada, yazma performansı neredeyse özdeş olur çünkü tamamlama günlüğü Premium ekli disklerde yerel/geçici disklere karşı.
Yeniden başlatılan bir düğümün, temizlenen kayıt günlüklerinden henüz veri dosyalarında olmayan verileri yeniden oluşturabilmesi için, kayıt günlüklerinin dayanıklı olması gerekir. Daha iyi dayanıklılık sağlamak için, kayıt günlüklerini, yerel depolama üzerinde değil, Premium yönetilen disklerde depolayın ve VM başka bir konağa geçirildiğinde kaybolabilir.
Testlerimizi temel alarak, kımtos 7. x üzerindeki Cassandra, kayıt günlükleri XFS ve ext4 FileSystem üzerinde olduğunda daha düşük yazma performansına sahip olabilir. Kayıt günlüğü sıkıştırmasını açmak, XFS performansını ext4 ile birlikte getirir. Sıkıştırılmış XFS, sınamalarımızda sıkıştırılmış ve sıkıştırılmamış ext4 gerçekleştirir.
Daha fazla bilgi için bkz. ext4 ve XFS dosya sistemlerindeki gözlemler ve sıkıştırılmış kayıt günlükleri (GitHub).
Temel VM performansını ölçme
Cassandra halkası için VM 'Leri dağıttıktan sonra, temel ağ ve disk performansı oluşturmak için birkaç yapay test çalıştırın. Performansın, VM boyutunabağlı olarak beklentilerle aynı olduğunu doğrulamak için bu testleri kullanın.
Daha sonra, gerçek iş yükünü çalıştırdığınız zaman, performans temelini bilmek olası performans sorunlarını araştırmayı kolaylaştırır. Örneğin, VM 'deki ağ çıkışı için taban çizgisi performansının bilinmesi, ağın performans sorunu olarak kurala yardımcı olabilir.
Performans testlerini çalıştırma hakkında daha fazla bilgi için bkz. temel Azure VM performansını doğrulama (GitHub).
Belge boyutu
Cassandra okuma ve yazma performansı belge boyutuna bağlıdır. Daha büyük belgelerle okurken veya yazarken daha yüksek gecikme süresi ve daha düşük işlem/saniye görmeyi bekleyebilir.
Daha fazla bilgi için bkz. çeşitli Cassandra belge boyutlarının göreli performansını karşılaştırma (GitHub).
Çoğaltma faktörü
Çoğu Cassandra iş yükleri, ekli Premium diskler kullanılırken 3 ' ün bir çoğaltma faktörü (RF) ve geçici/kısa ömürlü yerel diskler kullanırken 5 ' i kullanır. Cassandra halkasının içindeki düğüm sayısı, çoğaltma faktörünün katı olmalıdır. Örneğin, RF 3, 3, 6, 9 veya 12 düğümün bir halkasını, ancak RF 5 ' in 5, 10, 15 veya 20 düğümüne sahip olmasını gerektirir. 1 ' den büyük 1 ' den büyük bir LOCAL_QUORUM tutarlılık düzeyi kullanılırken, okuma ve yazma performansının, RF 1 ile çalışan aynı iş yüküyle daha düşük olması normaldir.
Daha fazla bilgi için bkz. çeşitli çoğaltma faktörlerinin göreli performansını karşılaştırma (GitHub).
Linux sayfa önbelleğe alma
Veri dosyalarını okurken Cassandra 'nın Java kodu, Linux sayfa önbelleklemesi ile normal dosya g/ç ve avantajlarını kullanır. Dosyanın parçaları bir kez okunduktan sonra, okuma içeriği işletim sistemi sayfa önbelleğinde depolanır. Aynı verilere sonraki okuma erişimi çok daha hızlıdır.
Bu nedenle, aynı verilere karşı okuma performans testlerini yürütürken ikinci ve sonraki okumalar asıl okuduğundan çok daha hızlı, uzak veri diskine veya ReadOnly etkinleştirildiğinde konak önbelleğinden veriye erişmek için gerekli olacaktır. Sonraki çalışmalarda benzer performans ölçümleri almak için Linux sayfa önbelleğini temizleyip Cassandra hizmetini yeniden başlatarak iç belleğini temizleyin. ReadOnly önbelleğe alma etkinleştirildiğinde, veriler konak önbelleğinde olabilir ve işletim sistemi sayfa önbelleğini temizleyip Cassandra hizmetini yeniden başlattıktan sonra da sonraki okumalar daha hızlı olur.
Daha fazla bilgi için bkz. Linux sayfa önbelleğe alma (GitHub) Için Cassandra kullanımıyla Ilgili gözlemler .
Çoklu veri merkezi çoğaltması
Cassandra yerel olarak birden çok veri merkezi kavramını destekler, böylece birden fazla Azure bölgesinde veya bir bölgedeki kullanılabilirlik bölgelerinde tek bir Cassandra halkası yapılandırmayı kolaylaştırır.
Bir çok bölgeli dağıtımı için, farklı bölgelerdeki sanal ağları bağlamak üzere Azure genel VNet eşleme kullanın. VM 'Ler aynı bölgede, ancak ayrı kullanılabilirlik bölgelerinde dağıtıldığında, sanal makineler aynı sanal ağ içinde olabilir.
Bölgeler arasındaki taban çizgisi gidiş dönüş gecikmesini ölçmek önemlidir. Bölgeler arasındaki ağ gecikme süresi, bir bölgedeki gecikme süresinden 10-100 kat daha yüksek olabilir. Yazma tutarlılığı kullanılırken ikinci bölgede görünen veriler arasında gecikme LOCAL_QUORUM veya veri tutarlılığı kullanılırken yazma performansını önemli ölçüde EACH_QUORUM.
Apache Cassandra'yı büyük ölçekte ve özellikle de çoklu DC ortamında çalıştırarak düğüm onarımı zor hale gelir. Reaper gibi araçlar, onarımları büyük ölçekte koordine etmeye yardımcı olabilir (örneğin, kümenin tamam üzerindeki yükü sınırlamak için bir veri merkezinde, tek bir veri merkezinde bulunan tüm düğümlerde). Ancak, büyük kümeler için düğüm onarımı henüz tam olarak çözülmüş bir sorun değildir ve şirket içinde veya bulutta tüm ortamlarda geçerlidir.
Düğümler ikincil bölgeye eklenmiştir, bazı bant genişliği ve CPU/disk kaynakları bölgeler arasında çoğaltma trafiğini almak ve göndermek için harcanmalarına neden olduğundan performans doğrusal olarak ölçeklendirlanmaz.
Daha fazla bilgi için bkz. Çoklu dc bölgeler arası çoğaltmanın etkisini ölçme (GitHub).
İpucu-teslim yapılandırması
Çok bölgeli cassandra kademesinde, tutarlılık düzeyi yüksek olan LOCAL_QUORUM iş yükleri ikincil bölgedeki verileri kaybedebilir. Varsayılan olarak Cassandra ima edilen aktarım hızı, görece düşük maksimum aktarım hızına ve üç saatlik ipucu yaşam süresine kısıtlandı. Yoğun yazmalar olan iş yükleri için, ipuçları çoğaltılana kadar bırakılırken bırakılırken emin olmak için, imtiyazlı teslim azaltma ve ipucu penceresi sürelerinin artırılmasını öneririz.
Daha fazla bilgi için bkz. Bölgeler arası çoğaltmada ipuçlarıyla ilgili gözlemler (GitHub.
Sonraki adımlar
Bu performans sonuçları hakkında daha fazla bilgi için bkz. Azure VM'lerinde Cassandra Performans Denemeleri.
Azure'a özgü değil genel Cassandra ayarları hakkında bilgi için bkz:
Aşağıdaki başvuru mimarisi, Cassandra'yı n katmanlı yapılandırmanın bir parçası olarak dağıtır: