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, her iş yükünün gereksinimlerine bağlı olarak yapılandırmaların geçersiz kılınmasına olanak tanır ve gerektiğinde maksimum esneklik ve denetim sağlar.

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

Kurtarma noktası hedefi ve kurtarma süresi hedefi

Aşağıdaki öğelere sahip olduğunuz sürece kurtarma noktası hedefi (RPO) ve kurtarma süresi hedefi (RTO) genellikle düşük, sıfıra yakın olur:

• Bölgeler arası çoğaltma ve çoğaltma faktörü 3 olan birden çok bölge dağıtımı.
• Kullanılabilirlik alanları etkinleştirildi. Azure portalında veya AzureCLI kullanarak küme oluşturduğunuzda bu seçeneği yapılandırın.
• İstemci sürücüsünde yük dengeleme politikası kullanılarak uygulama düzeyinde yük devretme veya Azure Traffic Manager ya da Azure Front Door kullanılarak yük dengeleme düzeyi yük devretme yapılandırıldı.

RTO, kesinti sürenizi gösterir. Küme hem bölgeler hem de bölgeler arasında dayanıklı olduğundan düşük. Ayrıca Apache Cassandra, tüm düğümlerin varsayılan olarak yazabildiği yüksek oranda hataya dayanıklı, eşler arası bir sistemdir.

RPO, kesintide ne kadar veri kaybedebileceğinizdir. Veriler tüm düğümler ve veri merkezleri arasında eşitlendiğinden, performans düşük olur. Kesintide veri kaybı en düşük düzeyde olabilir.

Not

CAP teoreminde hem RTO=0 hem de RPO=0 elde etmek mümkün değildir. Tutarlılık ile kullanılabilirlik veya en uygun performans arasındaki dengeyi değerlendirin.

Bu bakiye 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 daha iyi olabilir ve bu da tutarlılığı tercih eder. Uygulama, sıkı gecikme süresi gereksinimlerine sahip yazma odaklı bir yapıya sahipse, büyük bir bölgesel kesinti sırasında en son yazmaların bazılarını kaybetme riski kabul edilebilir olabilir ve bu da kullanılabilirliği artırmayı tercih eder.

Kullanılabilirlik alanları

Cassandra'nın eşler arası mimarisi sıfırdan hataya dayanıklılık getirir. Apache Cassandra için Azure Yönetilen Örneği, seçili bölgelerdeki kullanılabilirlik alanları için destek sağlar. Bu destek, altyapı düzeyinde dayanıklılığı artırır. 3 çoğaltma faktörü için kullanılabilirlik alanı desteği, her çoğaltmanın farklı bir kullanılabilirlik alanında olmasını sağlar. Bu yaklaşım, bölgesel bir kesintinin veritabanınızı veya 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 hataya dayanıklılık ve dayanıklılık düzeyi sunar. Ayrıca, uygulamalarınız için bölgesel kesintilerin etkisini de göz önünde bulundurun. Bölge düzeyinde kesintilere karşı koruma sağlamak için birden çok bölge kümesi dağıtmanızı kesinlikle öneririz. Nadir olsalar da, olası etki ciddidir.

İş sürekliliği için birden çok bölge veritabanı kullanmak yeterli değildir. Uygulamanızın diğer bölümlerinin de dağıtılması veya yük devretme mekanizmalarına sahip olması gerekir. Kullanıcılarınız birçok coğrafi konuma yayılmışsa, veritabanınız için birden çok bölge veri merkezi dağıtımı gecikme süresini azaltmanın ek avantajına sahiptir. Küme genelindeki tüm veri merkezlerindeki tüm düğümler, kendilerine en yakın bölgeden hem okuma hem de yazma işlemleri yapabilir.

Uygulama etkin-etkin olacak şekilde yapılandırılmışsa, çoğaltmalar (düğümler) arasındaki verilerinizin tutarlılığına CAP teoreminin nasıl uygulandığını ve yüksek kullanılabilirlik sağlamak için gereken dengeyi göz önünde bulundurun.

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

• Yazma işlemleri için aktif-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 QUORUM iyi bir uzlaşmadır. Bölgesel bir kesinti varsa, LOCAL_QUORUM'da bazı yazma işlemleri kaybolabilir.

• Bir uygulama paralel çalışıyorsa, çoğu durumda iki veri merkezi arasında tutarlılık sağlamak için QUORUM_EACH yazma işlemlerini tercih edin.

• Amacınız gecikme süresi veya kullanılabilirlik yerine tutarlılığı tercih etmek veya RPO'yu azaltmak veya RTO'yu düşürmekse tutarlılık ayarlarınız ve çoğaltma faktörünüzün bu hedefi yansıtması gerekir.

  Genel 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 dağıtılır. bölge, ilk veri merkezini dağıttığınızda seçilen bölgedir. 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ğinden, bu sorun hizmetin kullanılabilirlik SLA'sını etkilemez. Bu süre boyunca, Azure portalından veya kaynak sağlayıcısı araçlarından veritabanı yapılandırmasında değişiklik yapmak mümkün olmayabilir.

Çoğaltma

Zaman zaman keyspaces ve onların çoğaltma ayarlarını denetlemeyi, veri merkezleri arasında gerekli çoğaltmanın yapılandırıldığından emin olmak için öneririz. Geliştirmenin ilk aşamalarında kullanarak cqlshbasit testler yapmanızı öneririz. Örneğin, bir veri merkezine bağlıyken bir değer ekleyin ve diğerinden okuyun.

Özellikle, mevcut bir veri merkezinin zaten veriye sahip olduğu ikinci bir veri merkezi ayarladığınızda, tüm verileri çoğalttığınızı ve sistemin hazır olduğunu belirleyin. 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. Cassandra'nın dağıtılmış doğası nedeniyle büyük veri boyutlarında bu yaklaşımın yalnızca kabaca bir tahmin sunabileceğini unutmayın.

Olağanüstü durum kurtarma maliyetini dengeleme

Uygulamanız etkin-pasifse, genellikle her bölgeye aynı kapasiteyi dağıtmanızı öneririz. Bu yaklaşım, uygulamanızın ikincil bölgedeki etkin bekleme veri merkezine anında yük devretme gerçekleştirmesine yardımcı olur. Bölgesel bir kesinti oluşursa, bu yaklaşım 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 anlamına geldiğini varsayar, bu nedenle yük dengeleyici düzeyinde yük devretme gerçekleşmelidir.

İkinci 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. Kesinti oluştuğunda, anahtar teslimi dikey ve yatay ölçeklendirme , Apache Cassandra için Azure Yönetilen Örneği'nde ölçeklendirmeyi kolaylaştırır. Uygulamalarınız ikincil bölgenize geçerken, ikincil veri merkezinizdeki düğümleri manuel genişletebilir ve arttırabilirsiniz. İkincil veri merkeziniz daha düşük maliyetli ve sıcak bir bekleme işlevi görür. Bir kesinti oluşursa, bu yaklaşımın sisteminizi tam kapasiteye geri yüklemek için gereken süreyle dengelenmesi gerekir. 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 bu gerçeği göz önünde bulundurun.

Yedekleme zamanlamaları

Apache Cassandra için Azure Yönetilen Örneği'nde yedeklemeler otomatik olarak gerçekleştirilir. 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. bunlar 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. Öyle olsalar bile, veritabanını yedeklemelerden kurtarmak 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 birden çok bölge dağıtımı öneririz. Bu yaklaşım, başarısız bölgenin kurtarılamadığı nadir senaryolarda özellikle önemlidir. Çok bölgeli çoğaltma olmadan tüm veriler kaybolabilir.

Sonraki adım

Azure Portal kullanarak küme oluşturma