Azure Service Bus'ta güvenilirlik

Azure Service Bus, uygulamaları ve hizmetleri ayırmaya yönelik güvenilir zaman uyumsuz mesajlaşma özellikleri sağlayan, tam olarak yönetilen bir kurumsal ileti aracısı hizmetidir. Service Bus, noktadan noktaya iletişim için kuyrukları ve yayımlama-abone olma mesajlaşma düzenleri için aboneliklerle ilgili konuları destekler. Hizmet, mesaj dayanıklılığı, en az bir teslimat garantisi ve başarısız ileti işlemlerini ele almak için ölü harf kuyrukları gibi yerleşik güvenilirlik özellikleri sağlar.

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.

Bu makalede, Service Bus'ın geçici hatalar, kullanılabilirlik alanı kesintileri ve bölge kesintileri gibi farklı olası kesintilere ve sorunlara karşı nasıl dayanıklı hale getirilmeye başlandığı açıklanmaktadır. Ayrıca Service Bus hizmet düzeyi sözleşmesi (SLA) hakkında bazı önemli bilgileri de vurgular.

Üretim dağıtımı önerileri

Azure Well-Architected Framework güvenilirlik, performans, güvenlik, maliyet ve operasyonlar hakkında öneriler sağlar. Bu alanların birbirini nasıl etkilediğini öğrenmek ve güvenilir bir Azure Service Bus çözümüne katkıda bulunmak için bkz. Service Bus için mimarinin en iyi yöntemleri.

Güvenilirlik mimarisine genel bakış

Bu bölümde, hizmetin nasıl çalıştığına ilişkin güvenilirlik açısından en uygun olan bazı önemli yönler açıklanmaktadır. bölümünde dağıttığınız ve kullandığınız bazı kaynak ve özellikleri içeren mantıksal mimari tanıtılır. Ayrıca, hizmetin kapaklar altında nasıl çalıştığına ilişkin ayrıntılar sağlayan fiziksel mimariyi de ele alır.

Mantıksal mimari

Ad alanı Service Bus için yönetim kapsayıcısı görevi görür ve Temel, Standart veya Premium katmanını kullanacak şekilde yapılandırılabilir. Kapasite ayırarak, ağ güvenliğini yapılandırarak ve Geo-Replication ve Geo-Disaster Kurtarma'yı etkinleştirerek hizmeti ad alanı düzeyinde yapılandırabilirsiniz.

Bir ad alanı içinde, farklı semantiklere sahip mesajlaşma varlıkları olan kuyrukları ve konuları dağıtırsınız. Daha fazla bilgi için bkz. Service Bus kuyrukları, konuları ve abonelikleri.

İsteğe bağlı olarak, kuyrukları ve konuları birden çok ileti aracısı ve mesajlaşma deposuna yayan ad alanınızdaki bölümleri yapılandırabilirsiniz. Bir ad alanı, paralel işleme ve yatay ölçeklendirmeyi işlemek için birden çok bölüm kullanabilir. Service Bus 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. Premium katmanı için ad alanında bölümlemeyi etkinleştirin. Temel ve Standart katman ad alanları için, varlık üzerinde ve isteğe bağlı olarak, mesaj gönderirken bölümleri yapılandırın.

Uygulamalarınızın kullanılabilirliğini artırmak için Service Bus ve zaman uyumsuz tasarım yaklaşımlarını kullanabilirsiniz. Daha fazla bilgi için bkz. Zaman uyumsuz mesajlaşma düzenleri ve yüksek kullanılabilirlik.

Fiziksel mimari

Service Bus, temel alınan işlem ve depolama kaynaklarını sağlar. Her ad alanı için, iletileri birden çok ileti aracısı işler ve birden çok mesajlaşma deposu iletileri depolar . Her mesajlaşma deposu üç kopyaya sahiptir: bir birincil kopya ve iki ikincil kopya. Service Bus, veri ve yönetim işlemleri için üç kopyanın da eşitlenmiş durumda kalmasını sağlar. Birincil kopya başarısız olursa, Service Bus, müşteriler için kesinti olmadan ikincil bir kopyayı birincil kopyaya yükseltir.

Temel veya Standart katmanını kullanan ad alanları için Service Bus, kullanılabilirlik alanları arasında iletileri otomatik olarak çoğaltan paylaşılan çok kiracılı bir altyapı aracılığıyla yedeklilik sağlar. Hizmet birden çok mesajlaşma deposu tutar ve hem veri hem de yönetim işlemleri için tüm kopyaları eşitlenmiş olarak tutar.

Premium katman ad alanları için Service Bus, her birinin ayrılmış CPU ve bellek kaynaklarına sahip ayrılmış mesajlaşma birimleri (MU) sağlar. Premium katman ad alanları, iş yükü taleplerine göre otomatik olarak ölçeklendirilebilir. Daha fazla bilgi için bkz. Service Bus ad alanının MU'larını otomatik olarak güncelleştirme.

Service Bus altyapısı, hata etki alanlarına yayılan birden çok fiziksel makineye ve rafa yayılır ve bu da ad alanınızı etkileyen yıkıcı hata riskini azaltır. Kullanılabilirlik alanları olan bölgelerde altyapı , ayrı fiziksel veri merkezleri arasında genişler. Hizmet, garantili hizmet düzeylerinde ve genellikle bu hatalar oluştuğunda fark edilebilir kesintiler olmadan çalışmaya devam etmesi için saydam hata algılama ve yük devretme mekanizmaları uygular.

Geçici hatalara dayanıklılık

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.

Service Bus SDK'sı, ağ zaman aşımları veya geçici hizmetin kullanım dışı olması gibi geçici koşullar nedeniyle başarısız olan işlemler için üstel geri alma ile otomatik yeniden deneme mantığı içerir. Uygulamalar Service Bus bağlantısının geçici olarak kesilmesiyle karşılaştığında SDK, yapılandırılmış yeniden deneme ilkesini kullanarak otomatik olarak yeniden bağlanmayı dener.

Uygulamalarınızda geçici hata işlemeyi iyileştirmek için en güncel yeniden deneme mantığını ve bağlantı yönetimi özelliklerini içeren en son Service Bus SDK'sını kullanın. Daha fazla bilgi için bkz. .NET için Service Bus istemci kitaplığı.

Kullanılabilirlik alanı hatalarına dayanıklılık

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 devredilebilir.

Service Bus, tüm hizmet katmanlarında alanlar arası yedekli dağıtımları destekler. Desteklenen bir bölgede Service Bus ad alanı oluşturduğunuzda, alanlar arası yedeklilik ek ücret ödemeden otomatik olarak etkinleştirilir. Alanlar arası yedekli dağıtım modeli, bölümleme ve oturumlar dahil olmak üzere tüm Service Bus özellikleri için geçerlidir.

Service Bus yapılandırmanızı, meta verilerinizi ve ileti verilerinizi bölgedeki birden çok kullanılabilirlik alanında saydam olarak çoğaltır. Bölge yedekliliği, sizin müdahaleniz gerekmeksizin otomatik olarak sistem devrini gerçekleştirir. İşlem, ağ ve depolama dahil olmak üzere tüm Service Bus bileşenleri bölgeler arasında çoğaltılır. Service Bus, 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 mesajlaşma uygulamalarında veri kaybı veya kesinti olmadan çalışmaya devam eder.

Alanlar arası yedekli Service Bus ad alanını gösteren diyagram. Soldan sağa sıralanmış üç kullanılabilirlik alanına yayılmıştır.

Gereksinimler

• Bölge desteği: Alanlar arası yedekli Service Bus ad alanlarını kullanılabilirlik alanlarını destekleyen Azure bölgelerine dağıtabilirsiniz. Service Bus, desteklenen bir bölgede ek yapılandırma gerektirmeden bir ad alanı oluşturduğunuzda kullanılabilirlik alanı desteğini otomatik olarak etkinleştirir.

• Katman: Tüm Service Bus katmanları (Temel, Standart ve Premium) ek gereksinimler olmadan kullanılabilirlik alanlarını destekler.

Değerlendirmeler

Service Bus ad alanları bir zoneRedundant özellik içerir. Daha önce, kullanılabilirlik alanlarını etkinleştirmek için bu özellik gerekiyordu, ancak bu gereksinim değişti ve zoneRedundant özellik kullanım dışı bırakıldı. Bu özellik, bölge yedekliliği etkinleştirildiğinde bile false olarak görünebilir. Bölgelerinde kullanılabilirlik alanları bulunan tüm ad alanları, belirli bir bölgede yedeklidir.

Maliyet

Service Bus'ta alanlar arası yedeklilik ek maliyet eklemez.

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

Service Bus ad alanları, desteklenen bölgelerde dağıttığınızda bölge yedekliliğini otomatik olarak destekler. Başka bir yapılandırma gerekmez.

Tüm bölgeler sağlıklı olduğunda davranış

Bu bölümde, Service Bus ad alanları alanlar arası yedeklilik için yapılandırıldığında ve tüm kullanılabilirlik alanları çalışır durumda olduğunda neler bekleyebileceğiniz açıklanmaktadır.

• Bölgeler arasında trafik yönlendirme: Service Bus, iletilerin birden çok kullanılabilirlik alanına dağıtıldığı etkin-etkin bir model kullanır. İstemci bağlantıları bölgeler arasında otomatik olarak yük dengelemesi yapılır ve hizmet, bölgelere bakılmaksızın işlemleri kullanılabilir mesajlaşma altyapısına yönlendirir.

• Bölgeler arasında veri çoğaltma: Service Bus, meta veriler ve ileti verileri dahil olmak üzere kullanılabilirlik alanları arasında zaman uyumlu çoğaltma kullanır. Mesajlaşma deposunun birden çok kopyası, hizmetin bunları tamamlanmış kabul edebilmesi için yazma işlemlerini kabul etmelidir ve bu, normal işlemler sırasında bölgeler arası veri tutarlılığını garanti eder.

Bölge hatası sırasındaki davranış

Bu bölümde, Service Bus ad alanları alanlar arası yedeklilik için yapılandırıldığında ve kullanılabilirlik alanı kesintisi olduğunda neler bekleyebileceğiniz açıklanmaktadır.

• Algılama ve yanıt: Microsoft, bölge hatalarını otomatik olarak algılar ve iyi durumdaki bölgelere yük devretme başlatır. Bölge düzeyinde yük devretme için müşteri eylemi gerekmez.

• Bildirim: Microsoft, bir bölge kapatıldığında sizi otomatik olarak bilgilendirmez. Bununla birlikte, bölge hataları dahil olmak üzere hizmetin genel durumunu anlamak için Azure Hizmet Durumu'nı kullanabilir ve sorunları size bildirmek için Hizmet Durumu uyarıları ayarlayabilirsiniz.

• Etkin istekler: Bölge hatası sırasında Service Bus 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ı: Service Bus bildirimden önce iletileri bölgeler arasında zaman uyumlu olarak ç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: Service Bus, bir bölgenin kaybını algılar ve yeni istekleri otomatik olarak iyi durumdaki kullanılabilirlik bölgelerinden birindeki başka bir çoğaltmaya yönlendirir.

  Service Bus SDK'sı genellikle bağlantı yönetimini ve yeniden deneme mantığını saydam bir şekilde işler.

Bölge kurtarma

Kullanılabilirlik alanı kurtarıldığında, Service Bus bölgeyi otomatik olarak etkin hizmet topolojisine yeniden ekler. Kurtarılan bölge daha sonra yeni bağlantıları kabul eder ve iletileri diğer bölgelerin yanı sıra işler. Kesinti sırasında hayatta kalan bölgelere çoğaltılan veriler değişmeden kalır ve normal zaman uyumlu çoğaltma tüm bölgelerde sürdürülür. Bölge kurtarma veya yeniden bütünleştirme için işlem yapmanız gerekmez.

Bölge hataları için test

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

Bölge genelindeki hatalara dayanıklılık

Service Bus, her ikisi de Premium katman ad alanları gerektiren iki tür çok bölgeli destek sağlar:

• Coğrafi Çoğaltma , hem meta verilerin hem de ileti verilerinin birincil bölge ile ikincil bölge arasında etkin-pasif çoğaltması sağlar. Bölge kesintilerine dayanıklı kalması ve ileti veri kaybına karşı düşük toleransa sahip olması gereken çoğu uygulama için Geo-Replication kullanın.

• Meta Veriler Coğrafi Felaket Kurtarma, birincil ve ikincil bölge arasında yapılandırma ve meta verilerin etkin-pasif çoğaltmasını sağlar, ancak mesaj verilerini çoğaltmaz. Kendi veri çoğaltmasını işleyen veya veri çoğaltması gerektirmeyen uygulamalar için Geo-Disaster Recovery kullanmayı göz önünde bulundurun.

Aşağıdaki tabloda iki özellik arasındaki temel farklar özetlenmiştir:

Kapasite	Geo-Replication	Coğrafi Olağanüstü Durum Kurtarma
Çoğaltılanlar Nelerdir?	Meta veriler ve veriler (iletiler, ileti durumları, özellik değişiklikleri)	Yalnızca meta veriler (varlıklar, yapılandırma, özellikler)
Yük devretmede veri kaybı	Planlı yükseltme ile veri kaybı olmaz; zorlamalı yükseltme ile olası veri kaybı	İletiler çoğaltılamaz; eski birincil ad alanından manuel olarak kurtarılmaları gerekir.
Yük devretme davranışı	İkincil'i birincile yükselter; eski birincil ikincil olur	Tek seferlik yük devretme; eşleştirme yük devretmeden sonra bozulur
Geri dönüş özelliği	Evet, bir orijinal birincile geri yükseltilebilir	Hayır, yeni eşleştirme ayarlanmalıdır
Çoğaltma modları	Eşzamanlı veya eşzamsız	Uygulanamaz (yalnızca meta veriler)

Olağanüstü durum kurtarma senaryolarının çoğunda, tam veri koruması sağladığından Geo-Replication önerilir. Geo-Disaster Kurtarma'yı yalnızca meta veri replikasyonu gerektiğinde göz önünde bulundurun.

Hem Geo-Replication hem de metadata için geo-felaketten kurtarma, ikincil bölgenin yeni birincil bölge olması için yük devretme veya yükseltme işlemlerini el ile başlatmanızı gerektirir. Birincil bölgeniz devre dışı kalsa bile, Microsoft otomatik olarak yük devretme veya terfi başlatmaz.

Temel ve Standart katmanlardaki ad alanları yerel çok bölgeli özellikler içermez, ancak bölgeler arasında birden çok ad alanı kullanarak uygulama düzeyinde çoğaltma desenleri uygulayabilirsiniz. Daha fazla bilgi için bkz. Dayanıklılık için özel çok bölgeli çözümler.

Geo-Replication

Premium katmanı Coğrafi Çoğaltmayı destekler. Bu özellik, ad alanı için varlıklar, yapılandırma ve özellikler gibi meta verileri çoğaltır. Ayrıca kuyruklarınızdaki iletiler ve konular gibi verileri, ileti özellikleri ve durumuyla birlikte çoğaltır. Ad alanınızın yapılandırması ve verileri için çoğaltma yaklaşımını yapılandırabilirsiniz. Bu özellik, iletilerinizin başka bir bölgede kullanılabilir durumda kalmasını sağlar ve gerektiğinde ikincil bölgeye geçmenizi sağlar.

Bölge kesintilerine dayanıklılık gerektiren ve ileti veri kaybına karşı düşük toleransa sahip senaryolar için Geo-Replication 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. Azure aboneliğiniz tek bir ad alanı gösterir.

İki bölgeye yayılan Geo-Replication için yapılandırılmış bir Service Bus ad alanını gösteren diyagram. En üstte, bir istemci uygulaması ad alanı FQDN'sine bağlanır. Aşağıda yatay düzende iki bölge vardır: soldaki birincil bölge ve sağda ikincil bölge. Her bölge, meta veriler ve ileti verileri bölümleri içeren bir Service Bus ad alanı içerir. Bölgeler arasındaki çift yönlü ok, hem yapılandırma meta verilerinin hem de ileti verilerinin çoğaltılması olduğunu gösterir. Ad alanı FQDN normal işlemler sırasında birincil bölgeye yönlendirir. Yükseltme sırasında FQDN, yeni birincil olan ikincil bölgeye, önceki birincil ise ikincil bölgeye yönlendirilir.

İstediğiniz zaman ikincil bölgeyi birincil bölgeye yükseltebilirsiniz . İkincil bölgeyi yükselttiğiniz zaman Service Bus, 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 indirger. Planlı yükseltme mi yapmanız gerektiğine karar verirsiniz; bu da veri çoğaltmanın tamamlanmasını beklemeniz veya veri kaybına neden olabilecek zorlamalı yükseltmedir.

Uyarı

Service Bus Geo-Replication , 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. Bu genel işlemi açıklamak için yük devretme terimi de kullanılır.

Bu bölüm, Geo-Replication'ın önemli yönlerini özetlemektedir. Nasıl çalıştığını öğrenmek için tüm belgeleri gözden geçirin. Daha fazla bilgi için, bkz. Service Bus Geo-Replication.

Gereksinimler

• Bölge desteği: Birincil veya ikincil bölge olarak Service Bus'ı 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ölgeleri seçin.

• Katmanı: Coğrafi Çoğaltmayı etkinleştirmek için ad alanınızın Premium katmanını kullanması gerekir.

• Meta Veriler Geo-Disaster Recovery: Ad alanını hem Geo-Replication hem de Geo-Disaster Recovery kullanacak şekilde yapılandıramazsınız.

Değerlendirmeler

• Özellik sınırlamaları: Coğrafi Çoğaltma'yı etkinleştirdiğinizde bazı kısıtlamalar uygulanır. Daha fazla bilgi için, bkz. Service Bus Geo-Replication.

• Ö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ı öğrenmek için bkz. Fiyatlandırma.

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

• Yeni bir ad alanında Geo-Replication etkinleştirin. Oluşturma sırasında bir ad alanında Geo-Replication etkinleştirmek için bkz. Coğrafi Çoğaltmayı Ayarlama.

• Meta veri Geo-Disaster Kurtarma'dan Coğrafi Çoğaltma'ya geçiş.Meta veri Geo-Disaster Kurtarma kullanmaktan Coğrafi Çoğaltma'ya geçin.

• Çoğaltma yaklaşımını değiştirin. Zaman uyumlu ve zaman uyumsuz çoğaltma modları arasında geçiş yapmak için bkz. Çoğaltma modunu değiştirme.

• Coğrafi Çoğaltmayı kapatın. İkincil bölge için Geo-Replication kapatmak için bkz. İkincil bölgeyi silme.

Tüm bölgeler iyi durumda olduğunda davranış

Bu bölümde, service bus ad alanı Geo-Replication 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 iletileri etkin bir şekilde işler. İkincil bölge çoğaltılan iletileri alır, ancak aksi takdirde bekleme modunda kalır.

• Bölgeler arasında veri çoğaltma: Birincil ve ikincil bölge arasındaki veri çoğaltma davranışı, çoğaltma eşleştirmenizin zaman uyumlu veya zaman uyumsuz çoğaltma kullanıp kullanmadığına bağlıdır.

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

    Bu mod, ileti verilerinizin hem birincil hem de 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 iletiler için yazma gecikmesini ö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 ikincil bölgedeki bir kesinti yazma işleminin başarısız olmasına neden olur.

  • Asenkron: Hizmet iletileri birincil bölgeye yazar ve ardından yazma işlemini tamamlar. Kısa bir süre sonra, mesajları ikincil bölgeye kopyalar.

    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 yazma aktarım hızı sağlar. Ayrıca birincil bölgede yazma işlemlerine izin verirken ikincil bölgenin kaybını da tolere edebilir. Ancak birincil bölgede bir kesinti oluşursa, ikincil bölgeye çoğaltılmayan tüm veriler kullanılamayabilir veya kaybolabilir.

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

    Asenkron çoğaltma gecikmesi, belirttiğiniz üst sınırı aşıyorsa, birincil bölge, çoğaltmanın yetişmesi için gelen istekleri kısıtlamaya başlar. Bu durumu önlemek için coğrafi olarak çok uzak olmayan ikincil bölgeleri seçin ve kapasitenizin aktarım hızı için yeterli olduğundan emin olun.

    Zaman uyumsuz çoğaltma modunu seçtiğinizde bile bazı meta veri türleri zaman uyumlu olarak çoğaltılır.

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

Bölge kesintisi sırasındaki davranış

Bu bölümde, service bus ad alanı Geo-Replication için yapılandırıldığında ve birincil veya ikincil bölgede bir kesinti olduğunda neler bekleyebileceğiniz açıklanmaktadır.

• Algılama ve yanıt: 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. Yük devretmenin yapılıp yapılmayacağını belirlerken dikkate alınacak ölçütler için bkz. Yükseltmeyi tetikleyen önerilen senaryolar.

  İkincil bir bölgeyi yeni birincil bölge olarak terfi ettirmek hakkında daha fazla bilgi için Yükseltme akışı bölümüne bakın.

  İkincil bir bölgeyi yükseltirken , planlı yükseltme veya zorlamalı yükseltme arasında seçim yapın. Planlı bir tanıtım, yeni trafiği kabul etmeden önce ikincil bölgenin yetişmesini bekler. Bu yaklaşım veri kaybını önler ancak kapalı kalma süresiyle sonuçlenir.

  Birincil bölgedeki bir kesinti sırasında genellikle zorunlu yükseltme yapmanız gerekir. Birincil bölge kullanılabilir durumdaysa ve başka bir nedenle bir yükseltme tetiklerseniz, bunun yerine planlı bir promosyon seçebilirsiniz.

• Bildirim: Microsoft, bir bölge kapatıldığında size otomatik olarak bildirim vermez. Bununla birlikte, tüm bölge hataları dahil olmak üzere hizmetin genel durumunu anlamak için Azure Hizmet Durumu'nı kullanabilir ve sorunları size bildirmek için Hizmet Durumu uyarıları ayarlayabilirsiniz.

• Etkin istekler: Bu davranış, bölge kesintisinin birincil bölgede mi yoksa ikincil bölgede mi gerçekleştiğine 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, çoğaltma gecikmesi yapılandırdığınız üst sınıra ulaştıktan sonra ad alanınız kısıtlar ve yeni iletileri kabul etmez.

    Birincil bölgedeki ad alanını kullanmaya devam etmek için, ikincil ad alanını Geo-Replication yapılandırmanızdan kaldırın.

• Beklenen veri kaybı: Veri kaybı miktarı, planlanmış veya zorlamalı yükseltme yapmanıza ve çoğaltma modunun zaman uyumlu veya zaman uyumsuz olmasına 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.

  • Zorlamalı yükseltme, zaman uyumsuz çoğaltma: İkincil bölgeye çoğaltılmayan son iletiler ve çoğaltılmamış durum değişiklikleri için veri kaybı yaşayabilirsiniz. Tutar çoğaltma gecikmesine bağlıdır. Geçerli çoğaltma gecikmesini doğrulamak için Azure İzleyici metriklerini kullanın.

  Zorunlu yükseltme yaparsanız, 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 yapmanıza 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: Zorlamalı yükseltme sırasında Service Bus, 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, istemcilerin DNS kayıtlarının ne kadar hızlı güncellendiğine ve özellikle de DNS sunucularının ad alanı DNS kayıtlarının yaşam süresine (TTL) uygun davranıp davranmadığına bağlıdır.

Bölge geri kazanımı

Orijinal birincil bölge kurtarıldıktan sonra, ad alanını bu bölgeye geri döndürmek istiyorsanız aynı bölge terfi sürecini izleyin.

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

Bölge hataları testi

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 Geo-Replication'ı test edin.

Meta Veri Coğrafi Felaket Kurtarma

Premium katmanı, coğrafi afet kurtarma için meta verilerini destekler. Bu özellik, bir bölgenin yıkıcı kaybı da dahil olmak üzere olağanüstü durum senaryolarından kurtarmayı iyileştirir. Geo-Disaster Recovery yalnızca ad alanınızın yapılandırmasını ve meta verilerini çoğaltır ve ileti 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 iletileri hemen kabul etmeye hazır olmasını sağlar. Geo-Disaster Recovery, tek yönlü bir kurtarma çözümü işlevi görür ve önceki birincil bölgeye yeniden çalışma işlemini desteklemez.

Meta Veriler için Coğrafi Felaket Kurtarma, tüm mesajları sıkı bir şekilde koruması gerekmeyen ve bir felaket senaryosu sırasında veri kaybını tolere edebilen uygulamalar için en iyi şekilde çalışır. Meta Data Geo-Disaster Kurtarma, verileri kendisi çoğaltan veya hiç veri çoğaltmasına ihtiyaç duymayan uygulamalar için de uygun olabilir. Örneğin, iletiler daha sonra küçük resimlere dönüştürdüğünüz büyük görüntüler içerdiğinde, başka bir bölgedeki yeni iletileri işlemeye hızlı bir şekilde devam edip kayıp iletileri daha sonra yeniden yapılandırabiliyorsanız, başarısız bir bölgeden bazı iletilerin kaybolması kabul edilebilir.

Önemli

Geo-Disaster Recovery, aynı yapılandırmaya sahip olan ancak ileti verilerini çoğaltmayan işlemlerin sürekliliğini sağlar. İleti verilerini çoğaltmanız gerekiyorsa Coğrafi Çoğaltma'yı kullanmayı göz önünde bulundurun.

Meta verileri Geo-Disaster Kurtarma 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.

Üstte bir istemci uygulamasının bir diğer adla bağlantılı olduğunu gösteren diyagram. Aşağıda yatay olarak düzenlenmiş iki bölge yer almaktadır. Soldaki birincil bölge, meta veriler ve ileti verileri bölümleri içeren bir birincil ad alanı içerir. Sağdaki ikincil bölge, meta veri bölümü içeren ikincil bir ad alanı içerir. Zaman uyumsuz çoğaltma meta verileri etiketli noktalı ok yalnızca birincil ad alanının meta veriler bölümünden ikincil ad alanının meta veri bölümüne işaret eder. Takma ad, normal işlemler sırasında istemci trafiğini birincil ad alanına yönlendirir ve yük devretme sırasında ikincil ad alanına yönlendirir.

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. Çoğaltmanın ikincil sisteme geçmeden önce tamamlanmasını bekleyen güvenli bir yük devretme yapabilirsiniz. Bölge kesintisi sırasında bu seçenek kullanılamayabilir. Yük devretme başladıktan sonra neredeyse anında tamamlar. Yük devretme işlemi sırasında, Coğrafi Afet Kurtarma diğer adı ikincil ad alanına yönlendirilir ve eşleştirme kaldırılır.

Bu bölümde Jeo-Afet Kurtarma'nın önemli yönleri özetlenmiştir. Nasıl çalıştığını öğrenmek için tüm belgeleri gözden geçirin. Daha fazla bilgi için bkz. Service Bus Geo-Disaster Recovery.

Gereksinimler

• Bölge desteği: Birincil veya ikincil ad alanınız olarak Service Bus'ı 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ölgeleri seçin.

• Katmanı: Coğrafi Felaket Kurtarma için meta verileri etkinleştirmek amacıyla, her iki ad alanının da Premium katmanını kullanması gerekir.

• Bölümleme: Bölümlenmiş bir ad alanını bölümlenmemiş bir ad alanıyla eşleştirmek mümkün değildir.

• Meta Veriler Geo-Disaster Recovery: Ad alanını hem Geo-Replication hem de Geo-Disaster Recovery kullanacak şekilde yapılandıramazsınız.

Değerlendirmeler

• Özellik sınırlamaları: Geo-Disaster Recovery'yi etkinleştirdiğinizde bazı kısıtlamalar uygulanır. Daha fazla bilgi için bkz . Dikkate alınacak önemli noktalar ve Önemli Noktalar.

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

• Uygulama tasarımı: Geo-Disaster Recovery, 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.

• Standart'tan Premium'a geçirilen ad alanları: Ad alanınız Standart katmandaysa ve Premium katmanına geçirirseniz diğer adı farklı şekilde işlemeniz gerekir. Daha fazla bilgi için bkz. Service Bus Standard to Premium.

Maliyet

Geo-Felaket Kurtarma meta verilerini etkinleştirdiğinizde hem birincil hem de ikincil ad alanları için ödeme yaparsınız.

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

• Geo-Disaster Kurtarma meta veri eşleştirmesi oluşturun. Birincil ve ikincil ad alanları arasında olağanüstü durum kurtarmayı yapılandırmak için bkz. Kurulum ve yük devretme akışı.

• Coğrafi Felaket Kurtarma meta verilerini kapatı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 fazladan kesinti süresini tolere edebilirseniz, yük devretme sırasında veya sonrasında ikincil ad alanı kapasitesini ölçeklendirebilirsiniz. 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.

Tüm bölgeler iyi durumda olduğunda davranış

Bu bölümde, bir Service Bus ad alanı Geo-Disaster Recovery 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 iletileri etkin bir şekilde işler. İkincil ad alanı bekleme modunda 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 ileti verileri yalnızca birincil ad alanında kalır ve ikincil ad alanına çoğaltılamaz.

Bölge kesintisi sırasındaki davranış

Bu bölümde, bir Service Bus ad alanı Geo-Disaster Recovery için yapılandırıldığında ve birincil bölgede bir 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 devretmeyi başlatmaz veya ikincil bölgeyi otomatik olarak yükseltmez.

  Yük devretmeyi başlatma hakkında daha fazla bilgi almak için Yük devretme akışı'na bakın.

  Yük devretmeyi başlattığınızda , güvenli bir yük devretme mi yoksa zorunlu veya el ile yük devretme gibi standart bir yük devretme mi yapacağınızı seçin. Güvenli bir yük devretme, yük devretme başlamadan önce çoğaltmanın ikincil bölgeye tamamlanmasını bekler. Bu yaklaşım meta veri kaybını azaltır ancak kapalı kalma süresine neden olur. Güvenli yük devretme, ad alanlarının aynı Azure aboneliğinde olmasını gerektirir.

  Birincil bölgedeki bir kesinti sırasında genellikle zorunlu yük devretme yapmanız gerekir. Birincil bölge kullanılabilir durumdaysa ve başka bir nedenle yük devretme tetiklerseniz, planlı bir yük devretme seçebilirsiniz.

  Yük devretme tek yönlü bir işlemdir, bu nedenle Geo-Disaster Kurtarma eşleştirmesini daha sonra yeniden kurmanız gerekir. Daha fazla bilgi için Bölge kurtarma bölümüne bakınız.

• Bildirim: Microsoft, bir bölge kapatıldığında size otomatik olarak bildirim vermez. Bununla birlikte, tüm bölge hataları dahil olmak üzere hizmetin genel durumunu anlamak için Azure Hizmet Durumu'nı kullanabilir ve sorunları size bildirmek için Hizmet Durumu uyarıları ayarlayabilirsiniz.

• 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. Meta veri çoğaltma zaman uyumsuz olarak gerçekleşir, bu nedenle son değişiklikler özellikle karmaşık değişiklikler olmak üzere çoğaltılamayabilir. İstemciler erişmeden önce ikincil ad alanınızın yapılandırmasını doğrulayın.

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

    Olağanüstü bir felaket birincil bölgenin tamamının kaybına neden olmadığı sürece iletiler kalıcı olarak kaybolmaz. Bölge kurtarıldığı takdirde, iletileri birincil ad alanından daha sonra 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: Ad alanına bağlanmak için Geo-Felaket Kurtarma takma adını kullanan istemciler, hata kurtarmadan sonra 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 yeniden çalışmanız gerekir. Kurtarılan bölgeyi ikincil olarak kullanarak yeni bir Geo-Disaster Recovery eşleştirmesi oluşturun ve asıl bölgeye geri dönmek istiyorsanız başka bir yük devretme işlemi gerçekleştirin. Bu işlem, geçici birincil ad alanına gönderilen iletilerin olası veri kaybını içerir.

Olağanüstü durum birincil bölgedeki tüm bölgelerin kaybolmasına neden olursa verileriniz kurtarılamaz olabilir. Diğer senaryolarda, yük devretmeden önce birincil ad alanında kalan ileti verileri kurtarılabilir. Erişimi geri yükledikten sonra eski birincil ad alanından geçmiş iletileri alabilirsiniz. Uygulamalarınızı bu iletileri 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ı testi

Yanıt ve olağanüstü durum kurtarma işlemlerinizi test etmek için bakım aralığında planlı bir yük devri 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ından iletilere bağlanıp 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ı yansıtan üretim dışı bir ortamda Geo-Felaket Kurtarma meta verilerini test edin.

Dayanıklılık için özel çok bölgeli çözümler

Geo-Replication ve meta veri Geo-Disaster Recovery, bölge kesintileri ve diğer sorunlar için dayanıklılık sağlar ve çoğu iş yükü için uygundur. Bu özellikler aşağıdaki durumlarda gereksinimlerinize uygun olmayabilir:

• Özel çoğaltma veya aynı anda birden çok etkin bölgeyi korumak için gereksinimleriniz vardır.

• Bu özellikleri desteklemeyen bir Service Bus katmanı kullanırsınız.

Service Bus'ta farklı türde çok bölgeli destek sağlayan çeşitli tasarım desenleri vardır. Bu desenlerin çoğu birden çok ad alanı dağıtmanızı ve uygulamanızı bunları uygun şekilde kullanacak şekilde yapılandırmanızı gerektirir. Daha fazla bilgi için aşağıdaki kaynaklara bakın:

• Service Bus uygulamalarını kesintilere ve olağanüstü durumlara karşı yalıtma
• İleti çoğaltma ve bölgeler arası federasyon

Hizmet bakımına dayanıklılık

Service Bus düzenli bakım yapar. Planlı bakım sırasında ad alanları, en son güncelleştirmeleri içeren yedekli bir düğüme taşınır. Taşıma sırasında istemci SDK'sı bağlantıyı keser ve ad alanına otomatik olarak yeniden bağlanır. Yükseltmeler genellikle 30 saniye içinde tamamlar. Uygulamalarınızın bakım dönemlerinde oluşabilecek geçici ağ bağlantı kesilmelerine karşı hazırlıklı olması önemlidir.

Daha fazla bilgi için bkz. Service Bus için Azure bakım olayları.

Yedekleme ve geri yükleme

Service Bus, uzun süreli veri depolama için tasarlanmamıştır. Veriler genellikle yalnızca kısa bir süre için bir konu başlığında veya kuyrukta depolanır. Daha sonra başka bir veri depolama sisteminde işlenir veya kalıcı hale getirilip silinir. Bu tasarım nedeniyle Service Bus, ileti verilerinin çoğaltmalarını otomatik olarak korur ancak bu veriler için herhangi bir yedekleme ve geri yükleme özelliği sağlamaz.

Uzun süreli ileti saklama gerektiren senaryolar için Azure Depolama'ya veya diğer dayanıklı depolama hizmetlerine uygulama düzeyinde arşivleme uygulamayı 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.

Service Bus tüm ad alanları için bir SLA sağlar. Ad alanınız aşağıdaki ölçütleri karşıladığında kullanılabilirlik SLA'sı daha yüksektir:

• Premium katmanını kullanır.
• Kullanılabilirlik alanları olan bir bölgede bulunur.
• Bölümleme kullanır.

İlgili içerik

• Service Bus'a giriş
• Service Bus Coğrafi Felaket Kurtarma
• Service Bus Coğrafi Çoğaltma