Yüksek kullanılabilirlik ve olağanüstü durum kurtarma için en iyi yöntemler

Apache Cassandra için Azure Yönetilen Örneği, saf açık kaynak Apache Cassandra kümeleri için tam olarak yönetilen bir hizmettir. Hizmet ayrıca her iş yükünün belirli gereksinimlerine bağlı olarak yapılandırmaların geçersiz kılınmasına olanak tanıyarak gerektiğinde maksimum esneklik ve denetim sağlar.

Apache Cassandra, dağıtılmış yapısı ve ustalığı olmayan mimarisi nedeniyle yüksek oranda dayanıklı uygulamalar oluşturmak için harika bir seçimdir. Veritabanındaki tüm düğümler, cassandra'nın sağlamlığına ve dayanıklılığına katkıda bulunan diğer düğümlerle tam olarak aynı işlevselliği sağlayabilir. Bu makalede, yüksek kullanılabilirliği iyileştirme ve olağanüstü durum kurtarma yaklaşımı hakkında ipuçları sağlanır.

RPO ve RTO

RPO (kurtarma noktası hedefi) ve RTO (kurtarma süresi hedefi), sahip olduğunuz sürece Apache Cassandra için genellikle düşük (sıfıra yakın) olacaktır:

• Bölgeler arası çoğaltma ve çoğaltma faktörü 3 olan çok bölgeli dağıtım.
• Etkin kullanılabilirlik alanları (portalda veya Azure CLI aracılığıyla küme oluştururken seçeneği belirleyin).
• İstemci sürücüsünde yük dengeleme ilkesi ve/veya traffic manager/Azure front door kullanılarak yük dengeleme düzeyi yük devretme kullanılarak uygulama düzeyinde yük devretme yapılandırıldı.

Küme hem bölgeler hem de bölgeler arasında dayanıklı olacağı ve Apache Cassandra'nın kendisi yüksek oranda hataya dayanıklı, ana sistem (tüm düğümler yazabilir) olduğundan RTO ("kesintide ne kadar süre kesintide kaldınız") düşük olacaktır. RPO ("kesintide ne kadar veri kaybedebilirsiniz") düşük olacaktır çünkü veriler tüm düğümler ve veri merkezleri arasında eşitlenir, bu nedenle kesintide veri kaybı en düşük düzeyde olur.

Not

Cap Teoreminde hem RTO=0 hem de RPO=0 elde etmek teorik olarak mümkün değildir. Tutarlılık ile kullanılabilirlik/en iyi performans arasındaki dengeyi değerlendirmeniz gerekir; bu her uygulama için farklı görünür. Örneğin, uygulamanız yoğun okunursa, veri kaybını önlemek için bölgeler arası yazmaların gecikme süresini artırmak (tutarlılığı tercih etmek) daha iyi olabilir. Uygulama yoğun yazılıyorsa ve sıkı bir gecikme süresi bütçesi söz konusuysa, büyük bir bölgesel kesintide en son yazmalardan bazılarını kaybetme riski kabul edilebilir olabilir (kullanılabilirliği artırma).

Kullanılabilirlik alanları

Cassandra'nın masterless mimarisi hataya dayanıklılık getirir ve Apache Cassandra için Azure Yönetilen Örneği, altyapı düzeyinde dayanıklılığı artırmak için seçilen bölgelerdeki kullanılabilirlik alanları için destek sağlar. Çoğaltma faktörü 3 olduğunda, kullanılabilirlik alanı desteği her çoğaltmanın farklı bir kullanılabilirlik alanında olmasını sağlar ve böylece bölgesel kesintinin veritabanınızı/uygulamanızı etkilemesini önler. Mümkün olduğunda kullanılabilirlik alanlarını etkinleştirmenizi öneririz.

Çok bölgeli yedeklilik

Cassandra'nın mimarisi, Azure kullanılabilirlik alanları desteğiyle birlikte size bir miktar hataya dayanıklılık ve dayanıklılık sağlar. Ancak, bölgesel kesintilerin uygulamalarınız için etkisini göz önünde bulundurmanız önemlidir. Bölge düzeyinde kesintilere karşı koruma sağlamak için çok bölgeli kümeler dağıtmanızı kesinlikle öneririz. Nadir olsalar da, olası etki ciddidir.

İş sürekliliği için veritabanını yalnızca çoklu bölge yapmak yeterli değildir. Uygulamanızın diğer bölümlerinin de dağıtılarak veya yük devretme için yeterli mekanizmalarla aynı şekilde dağıtılması gerekir. Kullanıcılarınız birçok coğrafi konuma yayılmışsa, kümedeki tüm veri merkezlerindeki tüm düğümler kendilerine en yakın bölgeden hem okuma hem de yazma işlemlerine hizmet ettiğinden, veritabanınız için çok bölgeli bir veri merkezi dağıtımı gecikme süresini azaltma avantajına sahiptir. Ancak, uygulama "etkin-etkin" olarak yapılandırılmışsa, CAP teoreminin çoğaltmalar (düğümler) arasındaki verilerinizin tutarlılığı ve yüksek kullanılabilirlik sağlamak için gereken dengeler için nasıl uygulandığını göz önünde bulundurmanız önemlidir.

CAP teoreminde Cassandra varsayılan olarak yüksek oranda ayarlanabilir tutarlılığa sahip bir AP (Kullanılabilir Bölüme dayanıklı) veritabanı sistemidir. Çoğu kullanım örneğinde, okumalar için local_quorum kullanmanızı öneririz.

• Yazma işlemleri için etkin-pasif olarak güvenilirlik ve performans arasında bir denge vardır: güvenilirlik için QUORUM_EACH öneririz, ancak çoğu kullanıcı için LOCAL_QUORUM veya ÇEKIRDEK iyi bir risktir. Ancak bölgesel bir kesinti söz konusu olduğunda bazı yazma işlemleri LOCAL_QUORUM kaybolabilir.
• Bir uygulamanın paralel QUORUM_EACH çalıştırılması durumunda yazma işlemleri, iki veri merkezi arasında tutarlılık sağlamak amacıyla çoğu durumda tercih edilir.
• Amacınız gecikme süresi veya kullanılabilirlik (daha düşük RTO) yerine tutarlılığı (daha düşük RPO) tercih etmekse, bu tutarlılık ayarlarınıza ve çoğaltma faktörünüze yansıtılmalıdır. Temel kural olarak, okuma için gereken çekirdek düğümlerinin sayısı ve yazma için gereken çekirdek düğümlerinin sayısı çoğaltma faktöründen büyük olmalıdır. Örneğin, 3 çoğaltma faktörüne sahipseniz ve okumalarda (bir düğüm) quorum_one, yazma işlemlerinde (üç düğüm) quorum_all yapmanız gerekir; böylece toplam 4 sayısı 3 çoğaltma faktöründen büyük olur.

Not

Apache Cassandra için Azure Yönetilen Örneği'nin denetim düzlemi operatörü yalnızca tek bir bölgede (ilk veri merkezi dağıtılırken seçilen bölge) dağıtılır. Olası bir toplam bölge kesintisi durumunda, denetim düzlemini başka bir bölgeye devretmek için 3 saatlik kurtarma süresi taahhüt ediyoruz. Veri merkezlerinin çalışmaya devam etmesi gerektiği için bu durum hizmetin kullanılabilirlik SLA'sını etkilemez. Ancak bu süre boyunca portaldan veya kaynak sağlayıcısı araçlarından veritabanı yapılandırmasında değişiklik yapmak mümkün olmayabilir.

Çoğaltma

Veri merkezleri arasında gerekli çoğaltmanın yapılandırıldığından emin olmak için zaman zaman denetim keyspaces ve çoğaltma ayarlarını öneririz. Geliştirmenin ilk aşamalarında, kullanarak cqlshbasit testler yaparak her şeyin beklendiği gibi çalıştığını test etmenizi öneririz. Örneğin, bir veri merkezine bağlıyken değer ekleme ve diğerinden okuma.

Özellikle, mevcut bir veri merkezinin zaten veri içerdiği ikinci bir veri merkezi ayarlarken, tüm verilerin çoğaltıldığını ve sistemin hazır olduğunu belirlemek önemlidir. ile nodetool netstatsDBA komutlarımız aracılığıyla çoğaltma ilerleme durumunu izlemenizi öneririz. Alternatif bir yaklaşım, her tablodaki satırları saymaktır, ancak Cassandra'nın dağıtılmış yapısı nedeniyle büyük veri boyutlarıyla bunun yalnızca kabaca bir tahminde bulunabileceğini unutmayın.

Olağanüstü durum kurtarma maliyetini dengeleme

Uygulamanız "etkin-pasif" ise, uygulamanızın ikincil bölgedeki "etkin bekleme" veri merkezine anında yük devredebilmesi için her bölgeye aynı kapasiteyi dağıtmanızı öneririz. Bu, bölgesel bir kesinti durumunda performans düşüşü olmamasını sağlar. Cassandra istemci sürücülerinin çoğu, uygulama düzeyinde yük devretmeyi başlatmak için seçenekler sağlar. Varsayılan olarak, bölgesel kesintinin uygulamanın da devre dışı olduğu ve bu durumda yük dengeleyici düzeyinde yük devretmenin gerçekleşmesi gerektiği anlamına geldiğini varsayarlar.

Ancak ikinci bir veri merkezi sağlama maliyetini azaltmak için ikincil bölgenizde daha küçük bir SKU ve daha az düğüm dağıtmayı tercih edebilirsiniz. Bir kesinti oluştuğunda, apache Cassandra için Azure Yönetilen Örneği'nde anahtar teslimi dikey ve yatay ölçeklendirme ile ölçeklendirme daha kolay hale gelir. Uygulamalarınız ikincil bölgenize yük devretme yaparken, ikincil veri merkezinizdeki düğümlerin ölçeğini el ile genişletebilir ve ölçeği artırabilirsiniz . Bu durumda, ikincil veri merkeziniz daha düşük maliyetli ve sıcak bekleme işlevi görür. Bu yaklaşımı benimsemek, kesinti durumunda sisteminizi tam kapasiteye geri yüklemek için gereken zamana karşı dengelenmelidir. Bölge kaybolduğunda ne olacağını test etmek ve uygulamak önemlidir.

Not

Düğümlerin ölçeğini artırmak, ölçeği genişletmeye kıyasla çok daha hızlıdır. Dikey ve yatay ölçek arasındaki dengeyi ve kümenizde dağıtılacak düğüm sayısını göz önünde bulundurarak bunu göz önünde bulundurun.

Yedekleme zamanlamaları

Apache Cassandra için Azure Yönetilen Örneği'nde yedeklemeler otomatiktir, ancak günlük yedeklemeler için kendi zamanlamanızı seçebilirsiniz. Daha az yüke sahip saatleri seçmenizi öneririz. Yedeklemeler yalnızca boşta CPU kullanacak şekilde yapılandırılmış olsa da, bazı durumlarda Cassandra'da sıkıştırmaları tetikleyebilir ve bu da CPU kullanımında artışa neden olabilir. Sıkıştırmalar Cassandra ile her zaman gerçekleşebilir ve iş yüküne ve seçilen sıkıştırma stratejisine bağlıdır.

Önemli

Yedeklemelerin amacı yalnızca yanlışlıkla veri kaybını veya veri bozulmasını azaltmaktır. Yedeklemeleri olağanüstü durum kurtarma stratejisi olarak önermeyiz. Yedeklemeler coğrafi olarak yedekli değildir ve yedekli olsalar bile veritabanını yedeklemelerden kurtarmak çok uzun sürebilir. Bu nedenle, mümkün olduğunda kullanılabilirlik alanlarını etkinleştirme, olağanüstü durum senaryolarına karşı azaltma ve bunlardan etkili bir şekilde kurtarma olanağı sağlama ile birlikte çok bölgeli dağıtımları kesinlikle öneririz. Bu, çok bölgeli çoğaltma olmadan tüm verilerin kaybedilebileceği başarısız bölgenin ele alınamadığı nadir senaryolarda özellikle önemlidir.

Sonraki adımlar

Bu makalede Cassandra ile dayanıklı uygulamalar oluşturmaya yönelik bazı en iyi yöntemleri ortaya koyduk.

Azure Portal kullanarak küme oluşturma