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 kez teslim garantileri ve başarısız ileti işlemeyi yönetmek 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 çeşitli 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ındaki 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 anlamak ve güvenilir bir App Service çözümüne katkıda bulunmak için bkz. Azure Well-Architected Framework'te Azure Service Bus için mimari 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çeklendirme gerçekleştirmek 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ştirirsiniz. Temel ve Standart katman ad alanları için, varlıkta ve isteğe bağlı olarak ileti gönderirken bölümleri yapılandırabilirsiniz.

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 . Mesajlaşma deposunun üç kopyası vardır: bir birincil ve iki ikincil. 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, ikincil kopyalardan biri algılanan kapalı kalma süresi olmadan birincil kopyaya yükseltilir.

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ın eşitlenmesini sağlar.

Premium katman ad alanları için Service Bus, her birinin ayrılmış CPU ve bellek kaynaklarına sahip ayrılmış mesajlaşma birimleri sağlar. Premium katman ad alanları, iş yükü taleplerine göre otomatik olarak ölçeklendirilebilir. Daha fazla bilgi için bkz. Azure Service Bus ad alanının mesajlaşma birimlerini 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üzeyleri içinde ve bu tür hatalar oluştuğunda genellikle 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.

Azure Service Bus SDK'sı, ağ zaman aşımları veya geçici hizmet kullanılamaması 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 ile geçici bağlantı kesilmeleriyle 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 Azure 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 herhangi bir müdahaleniz gerekmeden otomatik yük devretme sağlar. İş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 Service Bus, mesajlaşma uygulamalarında veri kaybı veya kesinti olmadan çalışmaya devam eder.

Gereksinimler

• Bölge desteği: Alanlar arası yedekli Service Bus ad alanları kullanılabilirlik alanları desteğiyle Azure bölgelerine dağıtılabilir. 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 davranış değişti ve zoneRedundant özellik kullanım dışı bırakılıyor. Bölge yedekliliği etkinleştirildiğinde bile bu özellik yine de gösterilebilir false . Kullanılabilirlik alanları olan bölgelerdeki tüm ad alanları alanlar arası 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ğıtıldığında 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önlendirmesi. Service Bus, etkin-etkin bir model kullanarak iletilerin birden çok kullanılabilirlik alanına dağıtılmasını sağlar. İ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ı, normal işlemler sırasında bölgeler genelinde veri tutarlılığını sağlamak için yazma işlemlerini tamamlanmış saymadan önce onaylamalıdır.

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: Bir bölge kapatıldığında Microsoft 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 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 yönlendirme: Service Bus, bölgenin kaybını algılar ve yeni istekleri otomatik olarak sağlıklı kullanılabilirlik bölgelerinden birindeki başka bir replikaya 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 yeni bağlantıları kabul eder ve iletileri diğer bölgelerle birlikte 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 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 karşı dayanıklı kalması gereken ve ileti veri kaybına karşı düşük toleransa sahip ç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.

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 çalışmıyor olsa bile Microsoft otomatik olarak yük devretme veya yükseltme gerçekleştirmez.

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 aşağıdaki Dayanıklılık için özel çok bölgeli çözümler bölümüne bakın.

Geo-Replication

Premium katmanı 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 (kuyruklarınızdaki ve konu başlıklarınızdaki iletiler ile ileti özellikleri ve durum gibi) ç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.

İ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, yani veri çoğaltmanın tamamlanmasını mı bekleyeceğiniz yoksa veri kaybına neden olabilecek bir zorlamalı yükseltme mi?

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. Genel süreci açıklarken kullanılan yük devretme terimini de görebilirsiniz.

Bu bölüm, Geo-Replication'ı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, bkz. Service Bus Geo-Replication.

Gereksinimler

• Bölge desteği: Birincil bölge 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ölgeler seçebilirsiniz.

• 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 vardı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 Azure Event Hubs belgelerindeki Özel uç noktalar bölümüne bakın.

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

• Yeni bir ad alanında Geo-Replication etkinleştirin. Bir ad alanı oluşturma sırasında Geo-Replication'ı etkinleştirmek için Çoğaltma modunu değiştirme bölümüne bakın.

• Meta veriden Coğrafi Afet Kurtarma'dan Coğrafi Çoğaltma'ya geçiş yapın.Meta veriye dayalı Coğrafi Afet Kurtarma kullanımından Coğrafi Çoğaltma kullanımına geçebilirsiniz..

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

• Coğrafi Çoğaltmayı devre dışı bırakın. İkincil bölgeye Geo-Replication devre dışı bırakmak için bkz. İkincil bölgeyi silme.

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

Bu bölümde, Bir Service Bus 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 iletileri etkin bir şekilde işler. İkincil bölge çoğaltılmış iletileri alır, ancak diğer durumlarda bekleme modunda pasif kalır.

• Bölgeler arasında veri çoğaltma: Birincil ve ikincil bölge 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ı: İletiler, yazma işlemi tamamlanmadan önce ikincil bölgeye çoğaltılır.

    Bu mod, birincil ve ikincil bölgede işlenmesi gerektiğinden ileti verilerinizin güvenli olduğuna dair en büyük güvenceyi sağlar. Ancak zaman uyumlu çoğaltma, gelen iletiler 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 ikincil bölgedeki bir kesinti yazma işleminin başarısız olmasına neden olur.

    • Eşzamansız: İletiler birincil bölgeye yazılır ve yazma işlemi 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 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.

    Zaman uyumsuz çoğaltma modunu seçseniz 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ınması gereken önerilen ö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 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: Bir bölge kapatıldığında Microsoft sizi otomatik olarak bilgilendirmez. 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ı, 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 terfi, zaman uyumsuz çoğaltma: İkincil bölgeye çoğaltılmamış son iletiler ve henüz çoğaltılmamış durum değişiklikleri için 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: 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, 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.

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ı 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ı, afet durumunda coğrafi yedekleme için meta verileri 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 konfigürasyonunu ve meta verilerini kopyalar. Ancak 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, iletileriniz daha sonra küçük resimlere dönüştürdüğünüz büyük resimleri temsil ediyorsa, başka bir bölgede yeni iletileri hızlı bir şekilde işlemeye devam edebilir ve iletileri daha sonra yakalamak için yeniden yapılandırabiliyorsanız, başarısız bir bölgedeki bazı iletileri kaybetmeyi göze alabilirsiniz.

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

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. Bölge kesintisi sırasında bu seçenek kullanılamasa da, ikincilye geçmeden önce çoğaltmaların tamamlanmasını bekleyen güvenli bir yük devretme gerçekleştirmeyi seçebilirsiniz. Yük devretme başladıktan sonra neredeyse anında tamamlanır. 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. Tam olarak nasıl çalıştığını anlamak 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ı 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ölgeler seçebilirsiniz.

• 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 vardı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. Bunlara 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.

• Standarttan premiuma geçirilen ad alanları: Ad alanınız daha önce Standart katmandaysa ve Premium katmanına geçirdiyseniz 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-Felaket Kurtarma Meta Verisi Eşleşmesi 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ışı.

• Geo-Disaster Recovery meta verilerini 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.

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 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 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 devretme gerçekleştirmez 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 devretme başlattığınızda güvenli bir yük devretme mi yoksa standart mı (zorunlu veya el ile yük devretme) gerçekleştirileceğini 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 gerçekleştirmeniz 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 Coğrafi Felaket 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: Bir bölge kapatıldığında Microsoft sizi otomatik olarak bilgilendirmez. 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. 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.

  • İ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 geri döndürme işlemini gerçekleştirmeniz gerekir. Kurtarılan bölgeyi ikincil olarak yeni bir Geo-Disaster Recovery eşleştirmesi oluşturun ve orijinal bölgeye geri dönmek isterseniz başka bir yük devretme işlemi yapın. Bu işlem, geçici birincil öğeye 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 devretme gerçekleşmeden önce ileti verileriniz birincil ad alanında kalır ve kurtarılabilir durumda olur. 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 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 iletileri 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. Ancak, 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 elde etmek için çeşitli tasarım desenleri vardır. Desenlerin çoğu birden çok ad alanı dağıtmayı ve uygulamanızı ad alanlarını uygun şekilde kullanacak şekilde yapılandırmayı gerektirir. Daha fazla bilgi edinmek için aşağıdaki makalelere bakın:

• Uygulamaları Service Bus kesintilerine ve olağanüstü durumlarına karşı yalıtmak için birden çok ad alanı kullanın
• İleti çoğaltma ve bölgeler arası federasyon.

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

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

Daha fazla bilgi için bkz. Azure Service Bus için Azure bakım olaylarıyla ilgili yönergeler.

Yedekleme ve geri yükleme

Service Bus, verileriniz için uzun vadeli bir depolama konumu olarak tasarlanmamıştır. Genellikle veriler kısa bir süre için bir konu veya kuyrukta depolanır ve daha sonra başka bir veri depolama sisteminde işlenir veya kalıcı hale getirilir ve bu noktada silinir. Bu tasarım nedeniyle Service Bus, ileti verilerinin çoğaltmalarını otomatik olarak korur, ancak ileti verileri için yedekleme ve geri yükleme özellikleri 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çütlerin tümünü 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 belgeleri
• Azure Service Bus Coğrafi Olağanüstü Durum Kurtarma
• Azure Service Bus Coğrafi Çoğaltma