Azure HDInsight yüksek oranda kullanılabilir çözüm mimarisi örnek olay incelemesi
Azure HDInsight'ın çoğaltma mekanizmaları yüksek oranda kullanılabilir bir çözüm mimarisiyle tümleştirilebilir. Bu makalede, olası yüksek kullanılabilirlik olağanüstü durum kurtarma yaklaşımlarını, maliyetle ilgili konuları ve bunlara karşılık gelen tasarımları açıklamak için Contoso Retail için kurgusal bir örnek olay incelemesi kullanılmıştır.
Yüksek kullanılabilirlik olağanüstü durum kurtarma önerileri birçok permütasyona ve bileşime sahip olabilir. Bu çözümler, her seçeneğin artılarını ve dezavantajlarını sınırladıktan sonra ulaşılacaktır. Bu makalede yalnızca bir olası çözüm ele alınmaktadır.
Müşteri mimarisi
Aşağıdaki görüntüde Contoso Perakende birincil mimarisi gösterilir. Mimari bir akış iş yükü, toplu iş yükü, hizmet katmanı, tüketim katmanı, depolama katmanı ve sürüm denetiminden oluşur.
Akış iş yükü
Cihazlar ve algılayıcılar, mesajlaşma çerçevesini oluşturan HDInsight Kafka'ya veri üretir. HDInsight Spark tüketicisi Kafka Konuları'ndan okur. Spark, gelen iletileri dönüştürür ve sunum katmanındaki bir HDInsight HBase kümesine yazar.
Batch iş yükü
Hive ve MapReduce çalıştıran bir HDInsight Hadoop kümesi, şirket içi işlem sistemlerinden veri alır. Hive ve MapReduce tarafından dönüştürülen ham veriler, Azure Data Lake Storage 2. Nesil tarafından desteklenen veri gölü mantıksal bir bölümünde Hive tablolarında depolanır. Hive tablolarında depolanan veriler, kullanıma sunulmak üzere seçilen verileri HBase'de depolamadan önce toplu dönüşümler yapan Spark SQL'de de kullanılabilir hale gelir.
Sunum katmanı
Apache Phoenix ile HDInsight HBase kümesi, web uygulamalarına ve görselleştirme panolarına veri sunmak için kullanılır. İç raporlama gereksinimlerini karşılamak için HDInsight LLAP kümesi kullanılır.
Tüketim katmanı
Azure API Apps ve API Management katmanı genel kullanıma yönelik bir web sayfasına geri döner. İç raporlama gereksinimleri Power BI tarafından karşılanır.
Depolama katmanı
Mantıksal olarak bölümlenmiş Azure Data Lake Storage 2. Nesil kurumsal veri gölü olarak kullanılır. HDInsight meta veri depoları Azure SQL DB tarafından desteklenir.
Sürüm denetim sistemi
Azure Pipelines ile tümleştirilmiş ve Azure dışında barındırılan bir sürüm denetim sistemi.
Müşteri iş sürekliliği gereksinimleri
Olağanüstü bir durum olduğunda ihtiyacınız olacak en düşük iş işlevselliğini belirlemek önemlidir.
Contoso Perakende'nin iş sürekliliği gereksinimleri
- Bölgesel bir hata veya bölgesel hizmet durumu sorununa karşı korunmalıyız.
- Müşterilerim hiçbir zaman 404 hatası görmemeli. Genel içerik her zaman sunulmalıdır. (RTO = 0)
- Yılın büyük bir bölümünde, 5 saat eski olan genel içeriği gösterebiliriz. (RPO = 5 saat)
- Tatil sezonu boyunca genel kullanıma yönelik içeriklerimizin her zaman güncel olması gerekir. (RPO = 0)
- İç raporlama gereksinimlerim iş sürekliliği açısından kritik olarak kabul edilmiyor.
- İş sürekliliği maliyetlerini iyileştirme.
Önerilen çözüm
Aşağıdaki görüntüde Contoso Retail'ın yüksek kullanılabilirlik olağanüstü durum kurtarma mimarisi gösterilmektedir.
Kafka, Kafka KonuLarını birincil bölgeden ikincil bölgeye yansıtmak için Etkin – Pasif çoğaltma kullanır. Kafka çoğaltmasının alternatifi, her iki bölgede de Kafka'ya üretmek olabilir.
Hive ve Spark normal zamanlarda Etkin Birincil – İsteğe Bağlı İkincil çoğaltma modellerini kullanır. Hive çoğaltma işlemi düzenli aralıklarla çalıştırılır ve Hive Azure SQL meta veri deposu ve Hive depolama hesabı çoğaltmaya eşlik eder. Spark depolama hesabı, ADF DistCP kullanılarak düzenli aralıklarla çoğaltılır. Bu kümelerin geçici yapısı maliyetleri iyileştirmeye yardımcı olur. Çoğaltmalar, beş saatlik gereksinim dahilinde iyi bir RPO'ya ulaşmak için 4 saatte bir zamanlanır.
HBase çoğaltması, bölgeden bağımsız olarak verilerin her zaman sunulduğundan ve RPO'nun çok düşük olduğundan emin olmak için normal zamanlarda Öncü – Takipçi modelini kullanır.
Birincil bölgede bölgesel bir hata varsa, web sayfası ve arka uç içeriği ikincil bölgeden 5 saat boyunca bir miktar eskime ile sunulur. Azure hizmet durumu panosu beş saatlik pencerede kurtarma ETA'sını göstermiyorsa Contoso Retail, ikincil bölgede Hive ve Spark dönüşüm katmanını oluşturur ve ardından tüm yukarı akış veri kaynaklarını ikincil bölgeye yönlendirir. İkincil bölgeyi yazılabilir hale getirmek, birincil bölgeye çoğaltmayı içeren bir yeniden çalışma işlemine neden olabilir.
Yoğun bir alışveriş sezonunda ikincil işlem hattının tamamı her zaman etkin ve çalışır durumdadır. Kafka üreticileri her iki bölgeye de üretir ve genel kullanıma yönelik içeriğin her zaman güncel olduğundan emin olmak için HBase çoğaltması Öncü-takipçiden Öncü-Öncüye değiştirilir.
İş sürekliliği açısından kritik olmadığından, iç raporlama için hiçbir yük devretme çözümünün tasarlanması gerekmez.
Sonraki adımlar
Bu makalede ele alınan öğeler hakkında daha fazla bilgi edinmek için bkz: