Aracılığıyla paylaş

Azure Event Hubs'da güvenilirlik

Bu makalede Azure Event Hubs'dakullanılabilirlik alanları ve çok bölgeli dağıtımlar aracılığıyla bölgesel dayanıklılık konularını kapsayan güvenilirlik desteği açıklanmaktadır.

Azure'ı kullandığınızda güvenilirlik paylaşılan bir sorumluluktır. Microsoft, dayanıklılık ve kurtarmayı desteklemek için çeşitli özellikler sunar. Bu özelliklerin kullandığınız tüm hizmetler içinde nasıl çalıştığını anlamak ve iş hedeflerinize ve çalışma süresi hedeflerinize ulaşmak için ihtiyacınız olan özellikleri seçmek sizin sorumluluğunuzdadır.

Event Hubs, herhangi bir kaynaktan herhangi bir hedefe düşük gecikme süresiyle saniyede milyonlarca olay akışı sağlayan yerel bir bulut hizmetidir. Akış verilerini almak ve depolamak için Event Hubs'ı kullanın ve Apache Kafka için oluşturulan istemci uygulamalarıyla veya Event Hubs istemci SDK'larını kullanan uygulamalarla tümleştirin.

Üretim dağıtımı önerileri

Çözümünüzün güvenilirlik gereksinimlerini desteklemek için Event Hubs'ı dağıtmayı öğrenmek ve güvenilirliğin mimarinizin diğer yönlerini nasıl etkilediğini anlamak için bkz. Azure Well-Architected Framework'te Event Hubs için en iyi mimari yöntemleri.

Güvenilirlik mimarisine genel bakış

Bu bölümde, Event Hubs'ın güvenilirlik açısından nasıl çalıştığıyla ilgili önemli konular açıklanmaktadır. Dağıttığınız ve kullandığınız kaynakları ve özellikleri içeren mantıksal mimariyi tanıtır. Ayrıca, hizmetin işlemleri dahili olarak nasıl yönettiği hakkında ayrıntılı bilgi sağlayan fiziksel mimariyi de açıklar.

Mantıksal mimari

Event Hubs ad alanı , bir veya daha fazla olay hub'ı için yönetim kapsayıcısı görevi görür. Akış kapasitesini ayırma, ağ güvenliğini yapılandırma ve coğrafi dayanıklılık ile coğrafi olağanüstü durum kurtarmayı etkinleştirme gibi hizmeti ad alanı düzeyinde yapılandırabilirsiniz.

Bir ad alanı içinde olayları bir olay hub'ına düzenleyebilirsiniz. Apache® Kafka ekosistemi bu tür bir varlığı konu olarak ifade eder. Olay hub'ı veya konu başlığı, olaylarınızın yalnızca ekli dağıtılmış günlüğüdür.

Her olay hub'ı, sıralı olayların günlükleri olan bir veya daha fazla bölüm içerir. Bir etkinlik hub'ı, paralel işlem ve yatay ölçekleme gerçekleştirmek için birden çok bölüm kullanabilir. Event Hubs yalnızca tek bir bölüm içinde sıralamayı garanti eder. Bölümleme, uygulamanızın güvenilirlik tasarımında önemli bir rol oynar. Uygulamanızı tasarlarken kullanılabilirlik ve tutarlılığı en üst düzeye çıkarmak arasında bir denge oluşturun. Çoğu uygulamanın çalışma süresini en üst düzeye çıkarmak için, bölümleri doğrudan istemci uygulamalarınızdan ele almaktan kaçının. Daha fazla bilgi için bkz. Event Hubs'ta kullanılabilirlik ve tutarlılık.

Olay hub'ından okuyan tüketiciler, aldıkları son olayı tanımlayan kendi denetim noktalarını koruyarak olaylarını sırayla okuyabilir.

Event Hubs'daki bölümler ve diğer temel kavramlar hakkında daha fazla bilgi için bkz. Event Hubs'ta özellikler ve terminoloji.

Fiziksel mimari

Fiziksel mimaride Event Hubs ad alanı bir küme içinde çalışır. Küme, temel alınan işlem ve depolama kaynaklarını sağlar. Çoğu ad alanı, diğer Azure müşterilerinin paylaştığı kümelerde çalışır. Premium katmanını kullandığınızda, ad alanı paylaşılan bir küme içinde adanmış kaynaklarla tahsis edilir. Ayrılmış katmanını kullandığınızda, bir küme ad alanlarınıza ayrılmıştır. Ayrılmış kümeler hakkında daha fazla bilgi için bkz. Event Hubs Ayrılmış katmanına genel bakış. Katman ve küme türü ne olursa olsun, Microsoft kümeleri ve bunların temel sanal makinelerini ve depolama alanını yönetir.

Yedeklilik sağlamak için her kümenin okuma ve yazma isteklerini işleyen birden çok kopyası vardır. Yüksek kullanılabilirlik ve performans iyileştirmesi için tüm veriler üç depolama çoğaltması üzerinde depolanır. Ad alanınızın işlem kaynaklarını ölçeklendirmek için katmana bağlı olarak aktarım hızı birimleri (TU), işleme birimleri (RU) veya kapasite birimleri (RU) dağıtın. Daha fazla bilgi için bkz. Event Hubs ile ölçeklendirme.

Kümeler, birden çok fiziksel sunucu ve sunucu rafına yayılır, bu da ad alanınızı etkileyen yıkıcı hata riskini azaltır. Kullanılabilirlik alanları olan bölgelerde, kümeler ayrı fiziksel veri merkezlerine yayılır. Daha fazla bilgi için bkz . Kullanılabilirlik alanı desteği.

Geçici hatalar

Geçici hatalar, bileşenlerde kısa ve aralıklı hatalardır. Bunlar genellikle bulut gibi dağıtılmış bir ortamda gerçekleşir ve işlemlerin normal bir parçasıdır. Geçici hatalar kısa bir süre sonra kendilerini düzeltmektedir. Uygulamalarınızın genellikle etkilenen istekleri yeniden deneyerek geçici hataları işleyebileceği önemlidir.

Bulutta barındırılan tüm uygulamalar, bulutta barındırılan API'ler, veritabanları ve diğer bileşenlerle iletişim kurarken Azure geçici hata işleme yönergelerini izlemelidir. Daha fazla bilgi için bkz Geçici hataları ele alma önerileri.

Event Hubs saydam hata algılama ve yük devretme mekanizmaları uygular, böylece hizmet genellikle hatalar oluştuğunda fark edilebilir kesintiler olmadan garantili hizmet düzeylerinde çalışmaya devam eder.

İstemci uygulamalarını Event Hubs ile çalışacak şekilde tasarlarken şu kılavuzu izleyin:

  • Yerleşik yeniden deneme ilkelerini kullanın. Event Hubs ve Apache Kafka SDK'ları yeniden denenebilir hatalar için ağ zaman aşımları, kısıtlama yanıtları veya sunucu meşgul olduğunda işlemleri otomatik olarak yeniden dener. Hizmetin gereksiz yere aşırı yüklenmesini önlemek için varsayılan olarak üstel geri alma uygular.

  • Uygulama gereksinimlerinize göre uygun zaman aşımı değerlerini yapılandırın. Varsayılan zaman aşımı genellikle 60 saniyedir, ancak senaryonuza göre ayarlayabilirsiniz.

  • Olay işlemcinizde kontrol noktası uygulaması gerçekleştirin; bu, ilerlemeyi takip etmenize ve geçici hatalardan sonra son işlenen konumdan kurtarma yapmanıza olanak tanır.

  • Aktarım hızını artırmak ve geçici ağ sorunlarının tek tek iletiler üzerindeki etkisini azaltmak için gönderme işlemleri için toplu işlem kullanın.

  • Kafka protokolüyle çalışıyorsanız Apache Kafka SDK'larını kullanın. Kafka SDK'ları, geçici hataları işlemeye yardımcı olan yeniden deneme ilkelerini ve diğer en iyi yöntemleri de uygular.

Kullanılabilirlik alanı desteği

Kullanılabilirlik alanları , bir Azure bölgesi içindeki veri merkezlerinin fiziksel olarak ayrı gruplarıdır. Bir bölge başarısız olduğunda hizmetler kalan bölgelerden birine devredebilir.

Event Hubs, tüm hizmet katmanlarında alanlar arası yedekli dağıtımları destekler. Desteklenen bir bölgede Event Hubs ad alanı oluşturduğunuzda, alanlar arası yedeklilik otomatik olarak ek ücret ödemeden etkinleştirilir. Ancak Ayrılmış katmanda kullanılabilirlik alanları yalnızca en az üç RU ile desteklenir. Alanlar arası yedekli dağıtım modeli Capture, Schema Registry ve Kafka protokol desteği dahil olmak üzere tüm Event Hubs özellikleri için geçerlidir.

Event Hubs, yapılandırmanızı, meta verilerinizi ve olay verilerinizi bölgedeki üç kullanılabilirlik alanında saydam bir şekilde çoğaltır. Bölge yedekliliği, sizin herhangi bir müdahaleniz gerekmeden otomatik yük devretme sağlar. İşlem, ağ ve depolama dahil olmak üzere tüm Event Hubs bileşenleri bölgeler arasında çoğaltılır. Event Hubs, bir bölgenin tam kaybını anında işlemek için yeterli kapasite yedeğine sahiptir. Kullanılabilirlik bölgesinin tamamı kullanılamaz duruma gelse bile Event Hubs, akış uygulamalarında veri kaybı veya kesinti olmadan çalışmaya devam eder.

Alanlar arası yedekli Event Hubs ad alanını gösteren diyagram.

Bölge desteği

Alanlar arası yedekli Event Hubs ad alanları kullanılabilirlik alanlarını destekleyen herhangi bir Azure bölgesine dağıtılabilir.

Gereksinimler

  • Standart ve Premium katmanlar, ek yapılandırma gerektirmeden kullanılabilirlik alanlarını destekler.

  • Ayrılmış katman için kullanılabilirlik alanları en az üç CU gerektirir.

Maliyet

Event Hubs'da alanlar arası yedeklilik ek maliyet eklemez.

Kullanılabilirlik alanı desteğini yapılandırma

Event Hubs ad alanları , desteklenen bölgelerde dağıtıldığında bölge yedekliliğini otomatik olarak destekler. Başka bir yapılandırma gerekmez.

Normal işlemler

Event Hubs ad alanları alanlar arası yedeklilik kullandığında ve tüm kullanılabilirlik alanları normal çalıştığında aşağıdaki davranışı bekleyebilirsiniz:

  • Bölgeler arasında trafik yönlendirme: Event Hubs, üç kullanılabilirlik alanındaki altyapının gelen olayları aynı anda işlediği etkin-etkin bir modelde çalışır.

  • Bölgeler arasında veri çoğaltma: Event Hubs, kullanılabilirlik alanları arasında zaman uyumlu çoğaltma kullanır. Olay üreticisi bir olay gönderdiğinde, Event Hubs bunu birden fazla bölgede bulunan kopyalara yazar ve daha sonra yazma işleminin tamamlandığını istemciye bildirir. Bu yaklaşım, bölgenin tamamı kullanılamaz duruma gelse bile sıfır veri kaybı sağlar. Zaman uyumlu çoğaltma yaklaşımı, iyileştirilmiş çoğaltma protokolleri aracılığıyla düşük gecikme süresini korurken güçlü tutarlılık garantileri sağlar.

Bölge küçültme deneyimi

Event Hubs ad alanları alanlar arası yedeklilik kullandığında ve kullanılabilirlik alanı kesintisi oluştuğunda aşağıdaki davranışı bekleyebilirsiniz:

  • Algılama ve yanıt: Event Hubs, bir kullanılabilirlik alanındaki bir hatayı otomatik olarak algılamaktan sorumludur. Bölge yük devretmesi başlatmanız gerekmez.

  • Bildirim: Event Hubs, bir bölge kapatıldığında sizi bilgilendirmez. Ancak Bölge hataları dahil olmak üzere Event Hubs hizmetinin genel durumunu anlamak için Azure Hizmet Durumu'nı kullanabilirsiniz.

    Bölge düzeyindeki sorunların bildirimlerini almak için uyarılar ayarlayın. Daha fazla bilgi için bkz. Azure portalında Hizmet Durumu uyarıları oluşturma.

  • Etkin istekler: Bölge hatası sırasında Event Hubs etkin istekleri bırakabilir. İstemcileriniz kısa bir süre sonra yeniden deneyerek geçici hataları uygun şekilde işlerse, genellikle önemli bir etki yaratmasının önüne geçerler.

  • Beklenen veri kaybı: Event Hubs bildirimden önce olayları bölgeler arasında zaman uyumlu bir şekilde çoğalttığı için bölge hatası sırasında veri kaybı olmaz.

  • Beklenen kapalı kalma süresi: Bölge hatası birkaç saniyelik kapalı kalma süresine neden olabilir. İstemcileriniz kısa bir süre sonra yeniden deneyerek geçici hataları uygun şekilde işlerse, genellikle önemli bir etki yaratmasının önüne geçerler.

  • Trafik yeniden yönlendirme: Event Hubs, bölgenin kaybını algılar ve yeni istekleri otomatik olarak sağlam kullanılabilirlik bölgelerinden birinde başka bir çoğaltmaya yönlendirir.

    Event Hubs istemci SDK'ları genellikle bağlantı yönetimini ve yeniden deneme mantığını saydam bir şekilde işler.

Bölge kurtarma

Kullanılabilirlik alanı kurtarıldığında, Event Hubs bölgeyi otomatik olarak etkin hizmet topolojisine yeniden ekler. Kurtarılan bölge, diğer bölgelerin yanı sıra yeni bağlantıları kabul edip olayları işlemeye başlar. Kesinti sırasında kalan bölgelere çoğaltılan veriler değişmeden kalır ve normal zaman uyumlu çoğaltma tüm bölgeler arasında sürdürülür. Bölge kurtarma ve yeniden bütünleştirme için işlem yapmanız gerekmez.

Bölge arızaları için test yapma

Event Hubs, bölge hataları için trafik yönlendirmeyi, yük devretmeyi ve bölge kurtarmayı yönetir, bu nedenle kullanılabilirlik alanı hata işlemlerini doğrulamanız veya daha fazla giriş sağlamanız gerekmez.

Çok bölgeli destek

Event Hubs iki tür çok bölgeli destek sağlar:

  • Coğrafi çoğaltma (Premium ve Ayrılmış katmanlar), birincil bölge ile bir veya daha fazla ikincil bölge arasında hem meta verileri hem de olay verilerini aktif-aktif olarak çoğaltır. Bölge kesintilerine dayanıklı kalması gereken ve olay veri kaybına karşı düşük toleransa sahip çoğu uygulama için coğrafi çoğaltmayı kullanın.

  • Meta veri coğrafi olağanüstü durum kurtarma (Standart katman ve üzeri), birincil ve ikincil bölge arasında yapılandırma ve meta verilerin etkin-pasif çoğaltmasını sağlar, ancak olay verilerini çoğaltmaz. Olağanüstü durum senaryosu sırasında bazı olay veri kaybına dayanabilen ve başka bir bölgedeki işlemleri hızla sürdürmesi gereken uygulamalar için coğrafi olağanüstü durum kurtarmayı kullanın.

Hem coğrafi çoğaltma hem de meta veri coğrafi olağanüstü durum kurtarma, ikincil bir bölgenin yeni birincil bölge olması için manuel olarak yük devretme veya terfi işlemini başlatmanızı gerektirir. Birincil bölgeniz çalışmıyor olsa bile Microsoft otomatik olarak yük devretme veya yükseltme gerçekleştirmez.

Coğrafi çoğaltma

Premium ve Özel katmanlar coğrafi çoğaltmayı destekler. Bu özellik ad alanı için hem meta verileri (varlıklar, yapılandırma ve özellikler gibi) hem de verileri (olay yükleri gibi) çoğaltır. Ad alanınızın yapılandırması ve olay verileri için çoğaltma yaklaşımını yapılandırabilirsiniz. Bu özellik, olaylarınızın başka bir bölgede kullanılabilir kalmasını sağlar ve gerektiğinde ikincil bölgeye geçmenizi sağlar. Şema kayıt defteri meta verilerini ve diğer verilerini de çoğaltır.

Bölge kesintilerine dayanıklılık gerektiren ve olay veri kaybına karşı düşük toleransa sahip senaryolar için coğrafi çoğaltmayı kullanın.

Ad alanı temel olarak bölgelere yayılır. Bir bölge birincil, diğer bölgeler ise ikincil olarak görev görür. Coğrafi çoğaltma için yapılandırdığınız ikincil bölge sayısını fark etmez, Azure aboneliğiniz tek bir ad alanı gösterir.

Coğrafi çoğaltma için yapılandırılmış bir Event Hubs ad alanını gösteren diyagram.

İstediğiniz zaman ikincil bölgeyi birincil bölgeye yükseltebilirsiniz . İkincil bölgeyi terfi ettirdiğinizde, Event Hubs ad alanının tam etki alanı adını (FQDN) seçili ikincil bölgeye yönlendirir ve önceki birincil bölgeyi ikincil bölgeye dönüştürür. Planlı yükseltme mi yapmanız gerektiğine karar verirsiniz, yani veri çoğaltmanın tamamlanmasını mı bekleyeceğiniz yoksa veri kaybına neden olabilecek bir zorlamalı yükseltme mi?

Uyarı

Event Hubs coğrafi çoğaltması , ikincil bölgeyi birincil bölgeye yükseltme (ve daha sonra birincil bölgeyi ikincil bölgeye indirgeme) işlemini en iyi şekilde temsil ettiğinden yükseltme terimini kullanır. Genel süreci açıklarken kullanılan yük devretme terimini de görebilirsiniz.

Bu bölüm, coğrafi çoğaltmanın önemli yönlerini özetler. Tam olarak nasıl çalıştığını anlamak için tüm belgeleri gözden geçirin. Daha fazla bilgi için Event Hubs Coğrafi Çoğaltma'ya bakın.

Bölge desteği

Birincil bölgeniz veya ikincil bölgeleriniz olarak Event Hubs'ı destekleyen herhangi bir Azure bölgesini seçebilirsiniz. Azure eşleştirilmiş bölgelerini kullanmanız gerekmez, bu nedenle gecikme süresi, uyumluluk veya veri yerleşimi gereksinimlerinize göre ikincil bölgeler seçebilirsiniz.

Gereksinimler

Coğrafi çoğaltmayı etkinleştirmek için ad alanınızın Premium veya Ayrılmış katmanı kullanması gerekir.

Değerlendirmeler

Coğrafi çoğaltmayı etkinleştirdiğinizde aşağıdaki faktörleri göz önünde bulundurun:

  • Denetim noktası biçimi: Denetim noktalarının biçimi değişir. Daha fazla bilgi için bkz: Coğrafi çoğaltma: Veri kullanma.

  • Özel uç noktalar: Ad alanınıza bağlanmak için özel uç noktalar kullanıyorsanız, birincil ve ikincil bölgelerinizde de ağ yapılandırmanız gerekir. Daha fazla bilgi için bkz . Özel uç noktalar.

Maliyet

Coğrafi çoğaltma için fiyatlandırmanın nasıl çalıştığını anlamak için bkz . Fiyatlandırma.

Çok bölgeli desteği yapılandırma

Normal işlemler

Bu bölümde, bir Event Hubs ad alanı coğrafi çoğaltma için yapılandırıldığında ve birincil bölge çalışır durumda olduğunda neler bekleyebileceğiniz açıklanmaktadır.

  • Bölgeler arasında trafik yönlendirme: İstemci uygulamaları, ad alanınızın FQDN'sini ve bunların trafik yollarını birincil bölgeye bağlar.

    Yalnızca birincil bölge normal işlemler sırasında istemcilerden gelen olayları etkin bir şekilde işler. İkincil bölge çoğaltılmış olayları alır, ancak aksi takdirde bekleme modunda pasif kalır.

  • Bölgeler arasında veri çoğaltma: Birincil ve ikincil bölgeler arasındaki veri çoğaltma davranışı, çoğaltma eşleştirmenizi zaman uyumlu veya zaman uyumsuz çoğaltma kullanacak şekilde yapılandırmanıza bağlıdır.

    • Eşzamanlı: Olaylar, yazma işlemi tamamlanmadan önce ikincil bölgeye çoğaltılır.

      Bu mod, olay verilerinizin birincil ve ikincil bölgede işlenmesi gerektiğinden güvenli olduğuna dair en büyük güvenceyi sağlar. Ancak zaman uyumlu çoğaltma, gelen olaylar için yazma gecikme süresini önemli ölçüde artırır. Ayrıca, ikincil bölgenin yazma işlemini kabul etmek için kullanılabilir olmasını gerektirir, bu nedenle herhangi bir ikincil bölgedeki kesinti yazma işleminin başarısız olmasına neden olur.

      • Eşzamansız: Olaylar birincil bölgeye yazılır ve ardından yazma işlemi tamamlar. Kısa bir süre sonra olayları ikincil bölgeye çoğaltır.

      Bu mod, yazma işlemleri sırasında bölgeler arası çoğaltma gecikme süresi olmadığından zaman uyumlu çoğaltmaya göre daha yüksek bir yazma aktarım hızı sağlar. Ayrıca, zaman uyumsuz çoğaltma modu birincil bölgede yazma işlemlerine izin verirken ikincil bölgenin kaybını da tolere edebilir. Ancak birincil bölgede bir kesinti varsa, ikincil bölgeye henüz çoğaltılmamış tüm veriler kullanılamayabilir veya kaybolabilir.

      Zaman uyumsuz çoğaltmayı yapılandırırken, çoğaltmanın kabul edilebilir en uzun gecikme süresini yapılandırmış olursunuz. İstediğiniz zaman Azure İzleyici ölçümlerini kullanarak geçerli çoğaltma gecikmesini doğrulayabilirsiniz.

      Birincil bölge, zaman uyumsuz çoğaltma gecikmesi belirttiğiniz üst sınırı aşıyorsa, replikasyonun yetişebilmesi için gelen istekleri kontrol etmeye başlar. Bu durumu önlemek için coğrafi olarak çok uzak olmayan ikincil bölgeleri seçmek ve kapasitenizin aktarım hızı için yeterli olduğundan emin olmak önemlidir.

      Daha fazla bilgi için bkz . Çoğaltma modları.

Bölge azaltma deneyimi

Bu bölümde, bir Event Hubs ad alanı coğrafi çoğaltma için yapılandırıldığında ve birincil veya ikincil bölgede kesinti olduğunda neler bekleyebileceğiniz açıklanmaktadır.

Ad alanınızın ikincil bölgesini yeni birincil bölge olacak şekilde ne zaman yükselteceklerine karar vermek sizin sorumluluğunuzdadır. Bölge kesintisi olsa bile Microsoft bu kararı vermez veya işlemi sizin için başlatmaz. İkincil bölgeyi yeni birincil bölgeye yükseltme hakkında daha fazla bilgi için bkz. İkincili yükseltme.

İkincil bir bölgeyi yükseltirken , planlı yükseltme mi yoksa zorunlu yükseltme mi gerçekleştirmeyi seçin. Planlanan tanıtım, yeni trafiği kabul etmeden önce ikincil bölgenin tamamlanmasını bekler. Bu yaklaşım veri kaybını ortadan kaldırır ancak kapalı kalma süresine neden olur.

Birincil bölgedeki bir kesinti sırasında genellikle zorlamalı yükseltme gerçekleştirmeniz gerekir. Birincil bölge kullanılabilir durumdaysa ve başka bir nedenle bir yükseltme tetiklerseniz, planlı bir yükseltme seçebilirsiniz.

  • Bildirim: Event Hubs, bir bölge kapatıldığında sizi bilgilendirmez. Ancak, bölge hataları dahil olmak üzere Event Hubs'ın genel durumunu anlamak için Hizmet Durumu'nı kullanabilirsiniz. İkincil bölgeyi birincil bölgeye ne zaman yükselteceğine karar vermek için bu bilgileri ve diğer ölçümleri kullanın.

    Bölge düzeyindeki sorunlar hakkında bildirim almak için uyarılar ayarlayın. Daha fazla bilgi için bkz. Azure portalında Hizmet Durumu uyarıları oluşturma.

  • Etkin istekler: Davranış, bölge kesintisinin birincil bölgede mi yoksa ikincil bölgede mi oluştuğuna bağlıdır:

    • Birincil bölge kesintisi: Birincil bölge kullanılamıyorsa, tüm etkin istekler sonlandırılır. yükseltme tamamlandıktan sonra istemci uygulamaları işlemleri yeniden denemelidir.

    • İkincil bölge kesintisi: İkincil bölgedeki bir kesinti, aşağıdaki durumlarda etkin istekler için sorunlara neden olabilir:

      • Zaman uyumlu çoğaltma modunu kullanırsanız, herhangi bir ikincil bölge kullanılamıyorsa birincil bölge yazma işlemlerini tamamlayamaz.

      • Zaman uyumsuz çoğaltma modunu kullanırsanız, ad alanınız kısıtlar ve çoğaltma gecikmesi yapılandırdığınız üst sınıra ulaştıktan sonra yeni olayları kabul etmez.

      Birincil bölgedeki ad alanını kullanmaya devam etmek için ikincil ad alanını coğrafi çoğaltma yapılandırmanızdan kaldırın.

  • Beklenen veri kaybı: Veri kaybı miktarı, gerçekleştirdiğiniz yükseltme türüne (planlı veya zorlamalı) ve çoğaltma moduna (zaman uyumlu veya zaman uyumsuz) bağlıdır:

    • Planlı yükseltme: Veri kaybı beklenmez. Ancak bölge kesintisi sırasında, tüm birincil ve ikincil bölgelerin kullanılabilir olmasını gerektirdiğinden planlı yükseltme mümkün olmayabilir.

    • Zorlamalı yükseltme, zaman uyumlu çoğaltma: Veri kaybı beklenmez.

    • Zorunlu yükseltme, zaman uyumsuz çoğaltma: İkincil bölgeye çoğaltılmamış son olaylar nedeniyle veri kaybıyla karşılaşabilirsiniz. Tutar çoğaltma gecikmesine bağlıdır. Geçerli çoğaltma gecikmesini doğrulamak için Azure İzleyici metriklerini kullanın.

    Zorlamalı yükseltme gerçekleştirirseniz, birincil bölge kullanılabilir duruma geldikten sonra bile kayıp verileri kurtaramazsınız.

  • Beklenen kapalı kalma süresi: Beklenen kapalı kalma süresi, planlı veya zorunlu yükseltme gerçekleştirip gerçekleştirmediğinize bağlıdır:

    • Planlı yükseltme: Planlı yükseltmenin ilk adımı verileri ikincil bölgeye çoğaltır. Bu işlem genellikle hızlı bir şekilde tamamlanabilir, ancak bazı durumlarda çoğaltma gecikme süresi kadar sürebilir. Çoğaltma tamamlandıktan sonra yükseltme işlemi genellikle yaklaşık 5-10 dakika sürer. Etki Alanı Adı Sistemi (DNS) sunucularının girdileri güncelleştirmeleri ve kayıtlarını istemcilere tam olarak çoğaltmaları bazen daha uzun sürebilir.

      Birincil bölge, terfi işlemi süresince yazma işlemlerini kabul etmez.

      Tüm birincil ve ikincil bölgelerin kullanılabilir olmasını gerektirdiği için bölge kesintisi sırasında bu seçenek mümkün olmayabilir.

    • Zorunlu yükseltme: Zorunlu yükseltme sırasında Event Hubs, veri çoğaltmanın tamamlanmasını beklemez ve yükseltmeyi hemen başlatır. Yükseltme işlemi genellikle yaklaşık 5-10 dakika sürer. DNS girişlerinin istemciler arasında tamamen çoğaltılması ve güncelleştirilmesi bazen daha uzun sürebilir.

      Birincil bölge, terfi işlemi süresince yazma işlemlerini kabul etmez.

  • Trafik yeniden yönlendirme: Yükseltme tamamlandıktan sonra ad alanının FQDN'i yeni birincil bölgeyi gösterir. Ancak bu yeniden yönlendirme, dns sunucularının ad alanı DNS kayıtlarının yaşam süresine (TTL) uygun olması da dahil olmak üzere istemcilerin DNS kayıtlarının ne kadar hızlı güncelleştirildiklerine bağlıdır.

    Bazı durumlarda, bölge yükseltmesi gerçekleştikten sonra tüketici uygulamalarını tutarlı bir şekilde davranacak şekilde yapılandırmanız gerekir. Daha fazla bilgi için bkz: Coğrafi çoğaltma: Veri kullanma.

Bölge geri kazanımı

Özgün birincil bölge kurtarıldıktan sonra, ad alanını özgün birincil bölgesine döndürmek istiyorsanız aynı bölge yükseltme işlemini izleyin.

Bölge kesintisi sırasında zorunlu yükseltme gerçekleştirdiyseniz, birincil bölge kullanılabilir duruma geldikten sonra bile kayıp verileri kurtaramazsınız.

Bölge hatalarını test etme

Coğrafi çoğaltmayı test etmek için ikincil bölgeyi geçici olarak birincil bölgeye yükseltin ve istemci uygulamalarınızın bölgeler arasında en az kesintiyle geçiş yapabileceklerini doğrulayın.

Promosyon süresini izleyin ve runbook'larınız ile otomasyon süreçlerinizin doğru çalıştığını doğrulayın. Test ettikten sonra özgün yapılandırmaya geri dönebilirsiniz.

Terfi süreci sırasında ve sonrasında karşılaşabileceğiniz olası kesinti sürelerini ve veri kaybını anlayın. Üretim ad alanınızın yapılandırmasını yansıtan üretim dışı bir ortamda coğrafi çoğaltmayı test edin.

Meta veri coğrafi olağanüstü durum kurtarma

Standart düzey ve daha yüksek düzeyler coğrafi olağanüstü durum kurtarma için meta veri desteği sağlar. Bu özellik, bir bölgenin yıkıcı kaybı da dahil olmak üzere olağanüstü durum senaryolarından kurtarmayı iyileştirir. Coğrafi olağanüstü durum kurtarma yalnızca ad alanınızın yapılandırmasını ve meta verilerini çoğaltır. Ancak olay verilerini çoğaltmaz. Olağanüstü durum kurtarmayı desteklemek için bu özellik, başka bir bölgedeki bir ad alanının önceden yapılandırılmış ve istemcilerden gelen olayları hemen kabul etmeye hazır olmasını sağlar. Coğrafi olağanüstü durum kurtarma, tek yönlü bir kurtarma çözümü işlevi görür ve önceki birincil bölgeye yeniden çalışma özelliğini desteklemez.

Meta veri coğrafi olağanüstü durum kurtarma, her olayı sürdürmesi gerekmeyen ve olağanüstü durum senaryosu sırasında bazı veri kaybına dayanabilen uygulamalar için en iyi şekilde çalışır. Örneğin, olaylarınız daha sonra topladığınız algılayıcı okumalarını temsil ediyorsa, başka bir bölgedeki yeni olayları işlemeye hızlı bir şekilde devam edebilirseniz başarısız bir bölgeden bazı olayları kaybetmeyi göze alabilirsiniz.

Önemli

Coğrafi olağanüstü durum kurtarma, aynı yapılandırmaya sahip olan ancak olay verilerini çoğaltmayan işlemlerin sürekliliğini sağlar. Olay verilerini çoğaltmanız gerekiyorsa coğrafi çoğaltmayı kullanmayı göz önünde bulundurun.

Meta veri coğrafi olağanüstü durum kurtarmayı yapılandırdığınızda, istemci uygulamalarının bağlanacağı bir takma ad oluşturursunuz. Diğer ad, varsayılan olarak tüm trafiği birincil ad alanına yönlendiren bir FQDN'dir.

Meta veri coğrafi olağanüstü durum kurtarma için yapılandırılmış iki Event Hubs ad alanını gösteren diyagram.

Birincil bölge başarısız olursa veya başka bir olağanüstü durum oluşursa, tek seferlik, tek yönlü bir yük devretme taşıma işlemini istediğiniz zaman birincil bölgeden ikincil bölgeye el ile başlatabilirsiniz. Yük devretme neredeyse anında tamamlanır. Yük devretme işlemi sırasında coğrafi felaket kurtarma takma adı ikincil ad alanına yönlendirilir ve eşleştirme kaldırılır.

Bu bölüm, jeo-felaket kurtarımının önemli yönlerini özetlemektedir. Tam olarak nasıl çalıştığını anlamak için tüm belgeleri gözden geçirin. Daha fazla bilgi için Event Hubs Coğrafi Olağanüstü Durum Kurtarma konusuna bakın.

Bölge desteği

Birincil veya ikincil ad alanınız olarak Event Hubs'ı destekleyen herhangi bir Azure bölgesini seçebilirsiniz. Azure eşleştirilmiş bölgelerini kullanmanız gerekmez, bu nedenle gecikme süresi, uyumluluk veya veri yerleşimi gereksinimlerinize göre ikincil bölgeler seçebilirsiniz.

Gereksinimler

  • Birincil ad alanı katmanı: Meta veri coğrafi olağanüstü durum kurtarma özelliğini kullanabilmek için birincil ad alanınızın Standart katmanda veya daha yüksek bir katmanda olması gerekir.

  • İkincil ad alanı katmanı: Meta veri coğrafi olağanüstü durum kurtarma, birincil ve ikincil ad alanları için belirli katman bileşimlerini destekler. Daha fazla bilgi için bkz . Desteklenen ad alanı çiftleri.

Değerlendirmeler

  • Rol atamaları: Birincil ad alanında varlıklara microsoft Entra rol tabanlı erişim denetimi (RBAC) atamaları ikincil ad alanına çoğaltılamaz. Bunlara erişimin güvenliğini sağlamak için ikincil ad alanında el ile rol atamaları oluşturun.

  • Şema kayıt defteri: Meta veri coğrafi olağanüstü durum kurtarma kullandığınızda, şema kayıt defteri meta verileri çoğaltılır; ancak şema kayıt defterine kaydedilen şemalar çoğaltılmaz.

  • Uygulama tasarımı: Coğrafi olağanüstü durum kurtarma, istemci uygulamalarınızı tasarlarken dikkat edilmesi gereken belirli noktalar gerektirir. Daha fazla bilgi için bkz. Önemli Noktalar.

  • Özel uç noktalar: Ad alanınıza bağlanmak için özel uç noktalar kullanıyorsanız, ağı hem birincil hem de ikincil bölgenizde yapılandırın. Daha fazla bilgi için bkz . Özel uç noktalar.

Maliyet

Meta veri coğrafi olağanüstü durum kurtarmayı etkinleştirdiğinizde hem birincil hem de ikincil ad alanları için ödeme yaparsınız.

Çok bölgeli desteği yapılandırma

  • Meta veri coğrafi felaket kurtarma eşleştirmesi oluştur. Birincil ve ikincil ad alanları arasında olağanüstü durum kurtarmayı yapılandırmak için bkz. Kurulum ve yük devretme akışı.

  • Meta veri coğrafi olağanüstü durum kurtarmayı devre dışı bırakın. Ad alanları arasındaki eşleştirmeyi kesmek için bkz. Kurulum ve yük devretme akışı.

Kapasite planlaması ve yönetimi

Çok bölgeli dağıtımları planlarken, bir bölge başarısız olursa her iki bölgenin de tam yükü işlemek için yeterli kapasiteye sahip olduğundan emin olun. İkincil bölge normal işlemler sırasında pasif kalır, ancak yük devretmeden sonra trafiği hemen yönetmesi gerekir. üretim trafiğini gecikmeden alabilmesi için ikincil ad alanı kapasitesinin nasıl ölçeklendirilebileceğini planlayın. Yük devretme işlemi sırasında ek kapalı kalma süresini tolere edebilirseniz, yük devretme sırasında veya sonrasında ikincil ad alanı kapasitesini ölçeklendirmeyi seçebilirsiniz. Kapalı kalma süresini azaltmak için, üretim yükünü almaya hazır kalması için ikincil ad alanında kapasiteyi önceden sağlayın.

Normal işlemler

Bu bölümde, bir Event Hubs ad alanı coğrafi olağanüstü durum kurtarma için yapılandırıldığında ve birincil bölge çalışır durumda olduğunda neler bekleyebileceğiniz açıklanmaktadır.

  • Bölgeler arasında trafik yönlendirme: İstemci uygulamaları, ad alanınızın coğrafi felaket kurtarma takma adı üzerinden bağlanır ve trafik, birincil bölgedeki birincil ad alanına yönlendirilir.

    Yalnızca birincil ad alanı normal işlemler sırasında istemcilerden gelen olayları etkin bir şekilde işler. İkincil ad alanı bekleme modunda pasif kalır ve verilere erişim istekleri başarısız olur.

  • Bölgeler arasında veri çoğaltma: Yalnızca yapılandırma meta verileri ad alanları arasında çoğaltılır. Yapılandırma çoğaltması sürekli ve zaman uyumsuz olarak gerçekleşir.

    Tüm olay verileri yalnızca birincil ad alanında kalır ve ikincil ad alanına çoğaltılamaz.

Bölge azaltma deneyimi

Bu bölümde, bir Event Hubs ad alanı coğrafi olağanüstü durum kurtarma için yapılandırıldığında ve birincil bölgede kesinti olduğunda neler bekleyebileceğiniz açıklanmaktadır.

  • Algılama ve yanıt: Bölge sağlığını izlemek ve yedeklemeyi el ile başlatmaktan siz sorumlusunuz. Birincil bölgeniz çalışmıyor olsa bile Microsoft yük devretme gerçekleştirmez veya ikincil bölgeyi otomatik olarak yükseltmez.

    Yük devretmeyi başlatma hakkında daha fazla bilgi için bkz. El ile yük devretme.

    Yük devretme tek yönlü bir işlemdir, bu nedenle coğrafi felaket kurtarma ilişkilendirmesini daha sonra yeniden kurmanız gerekir. Daha fazla bilgi için Bölge kurtarma bölümüne bakınız.

  • Bildirim: Event Hubs, bir bölge kapatıldığında sizi bilgilendirmez. Ancak, bölge hataları dahil olmak üzere Event Hubs'ın genel durumunu anlamak için Hizmet Durumu'nı kullanabilirsiniz. Yük devretmeyi ne zaman başlatacağınızı belirlemek için bu bilgileri ve diğer ölçümleri kullanın.

    Bölge düzeyindeki sorunlar hakkında bildirim almak için uyarılar ayarlayın. Daha fazla bilgi için bkz. Azure portalında Hizmet Durumu uyarıları oluşturma.

  • Etkin istekler: Devam eden etkin istekler, yedekleme geçişi başladığında sonlanır. yük devretme tamamlandıktan sonra istemci uygulamaları işlemleri yeniden denemelidir.

  • Beklenen veri kaybı:

    • Meta veriler: Yapılandırma ve meta veriler genellikle ikincil ad alanına çoğaltılır. Ancak meta veri çoğaltması zaman uyumsuz olarak gerçekleşir, bu nedenle son değişiklikler, özellikle karmaşık değişiklikler yinelenmeyebilir. İstemciler erişmeden önce ikincil ad alanınızın yapılandırmasını doğrulayın.

    • Olay verileri: Olay verileri bölgeler arasında çoğaltılmıyor. Birincil bölge çökerse, birincil ad alanınızdaki olaylar kullanılamaz duruma gelir.

      Bir felaket birincil bölgenin tamamen kaybına neden olmadığı sürece olaylar kalıcı olarak kaybolmaz. Bölge kurtarılırsa, olayları daha sonra birincil ad alanından alabilirsiniz.

  • Beklenen kapalı kalma süresi: Yük devretme genellikle 5-10 dakika içinde gerçekleşir. İstemcilerin DNS girdilerini tam olarak çoğaltması ve güncelleştirmesi daha uzun sürebilir.

  • Trafik yeniden yönlendirme: Coğrafi olağanüstü durum kurtarma diğer adını kullanarak ad alanına bağlanan istemciler, hata geçişi sonrasında otomatik olarak ikincil ad alanına yönlendirilir. Ancak bu yeniden yönlendirme, ad alanı DNS kayıtlarının TTL'sini kabul eden DNS sunucularına ve bu güncelleştirilmiş DNS kayıtlarını alan istemcilere bağlıdır.

Bölge geri kazanımı

Özgün birincil bölge kurtarıldıktan sonra eşleştirmeyi el ile yeniden oluşturmanız ve isteğe bağlı olarak geri döndürme işlemini gerçekleştirmeniz gerekir. Kurtarılan bölgeyi ikincil olarak kullanarak yeni bir coğrafi felaket kurtarma çifti oluşturarak özgün bölgeye geri dönmek istiyorsanız başka bir yük devretme işlemi gerçekleştirin. Bu işlem, geçici birincile gönderilen olayların olası veri kaybına neden olabilir.

Olağanüstü durum birincil bölgedeki tüm bölgelerin kaybolmasına neden olursa verileriniz kurtarılamaz olabilir. Failover sonrasında, diğer senaryolarda olay verileriniz birincil ad alanında kalır ve geri yüklenebilir. Erişimi geri yükledikten sonra eski birincil ad alanından geçmiş olayları alabilirsiniz. Uygulamalarınızı bu olayları alacak ve işecek şekilde yapılandırmak sizin sorumluluğunuzdadır. Microsoft bunları ikincil bölgenize otomatik olarak geri yüklemez.

Bölge hatalarını test etme

Yanıt ve olağanüstü durum kurtarma proseslerinizi test etmek için bakım sürecinde planlı yük devretme gerçekleştirin. Birincil ad alanınızdan ikincil ad alanınıza yük devretme başlatın ve uygulamalarınızın yeni birincil ad alanına bağlanıp olayları işleyebildiğini doğrulayın.

Yük devretme süresini izleyin ve runbook'larınızın ve otomasyonunuzun doğru çalıştığını doğrulayın. Test ettikten sonra özgün yapılandırmaya geri dönebilirsiniz.

Yük devretme işlemi sırasında ve sonrasında karşılaşabileceğiniz olası kapalı kalma süresini ve veri kaybını anlayın. Üretim ad alanınızın yapılandırmasını yansıtan üretim dışı bir ortamda coğrafi çoğaltmayı test edin.

Alternatif çok bölgeli yaklaşımlar

Coğrafi çoğaltma ve meta veri coğrafi olağanüstü durum kurtarma, bölge kesintilerine ve diğer sorunlara dayanıklılık sağlar ve çoğu iş yükünü destekler. Bazı Event Hubs katmanları bu özellikleri desteklemez veya özel çoğaltma gerektirebilir veya aynı anda birden çok etkin bölgeyi korumanız gerekebilir.

Çeşitli tasarım desenleri Event Hubs'da farklı türde çok bölgeli destek elde edebilir. Desenlerin çoğu birden çok ad alanı dağıtmayı ve olayları aralarında çoğaltmak için Azure İşlevleri gibi hizmetleri kullanmayı gerektirir. Daha fazla bilgi için bkz . Çok siteli ve çok bölgeli federasyon.

Yedeklemeler

Event Hubs, verileriniz için uzun vadeli bir depolama konumu olarak tasarlanmamıştır. Genellikle, verileri kısa bir süre için bir olay hub'ında depolar ve sonra verileri işler veya başka bir veri depolama sisteminde kalıcı hale yüklersiniz. Olay hub'ınız için veri saklama süresini gereksinimlerinize ve ad alanınızın kullandığı katmana göre yapılandırabilirsiniz. Daha fazla bilgi için bkz . Olay saklama.

Olaylarınızın bir kopyasını tutmanız gerekiyorsa, olayların kopyalarını bir Azure Blob Depolama hesabına kaydeden Event Hubs Capture'ı kullanmayı göz önünde bulundurun.

Hizmet düzeyi sözleşmesi

Azure hizmetleri için hizmet düzeyi sözleşmesi (SLA), her hizmetin beklenen kullanılabilirliğini ve bu kullanılabilirlik beklentisini elde etmek için çözümünüzün karşılaması gereken koşulları açıklar. Daha fazla bilgi için çevrimiçi hizmetler için SLA'lar sayfasına bakın.

Premium veya Özel katmanları kullandığında ad alanı için kullanılabilirlik SLA'sı daha yüksektir.

İlgili içerik

  • Last updated on