Azure Event Hubs - Coğrafi olağanüstü durum kurtarma
Veri işleme kaynaklarının felaketlere karşı dayanıklılık, birçok kuruluş için ve hatta bazı durumlarda sektör düzenlemeleri için gerekli olan bir gereksinimdir.
Azure Event Hubs, tek tek makinelerin ve hatta tam rafların olağanüstü hata riskini zaten bir veri merkezindeki birden çok hata etki alanına yayılan kümelere yayar. Saydam hata algılama ve yük devretme mekanizmaları uygular, böylece hizmet garantili hizmet düzeylerinde ve genellikle bu tür hatalarda fark edilebilir kesintiler olmadan çalışmaya devam eder. Kullanılabilirlik alanları etkinleştirilmiş bir Event Hubs ad alanı oluşturursanız kesinti riskini daha da azaltır ve yüksek kullanılabilirliği etkinleştirirsiniz. Kullanılabilirlik alanlarıyla, kesinti riski fiziksel olarak ayrılmış üç tesise daha da yayılır ve hizmet, tüm tesisin tam ve yıkıcı kaybıyla anında başa çıkmak için yeterli kapasite rezervine sahiptir.
Kullanılabilirlik alanı desteğine sahip tüm etkin Azure Event Hubs küme modeli, önemli donanım hatalarına ve hatta veri merkezi tesislerinin tamamında yıkıcı kayıplara karşı dayanıklılık sağlar. Yine de, bu önlemlerin bile yeterince savunma yapamayacağı yaygın fiziksel yıkımla ilgili ciddi durumlar olabilir.
Event Hubs Coğrafi olağanüstü durum kurtarma özelliği, bu büyüklükteki bir olağanüstü durumdan kurtarmayı ve başarısız bir Azure bölgesini temelli olarak ve uygulama yapılandırmalarınızı değiştirmek zorunda kalmadan bırakmanızı kolaylaştıracak şekilde tasarlanmıştır. Bir Azure bölgesini terk etmek genellikle çeşitli hizmetleri içerir ve bu özellik öncelikli olarak bileşik uygulama yapılandırmasının bütünlüğünün korunmasına yardımcı olmayı amaçlar.
Coğrafi Olağanüstü Durum kurtarma özelliği, bir ad alanının (Event Hubs, Tüketici Grupları ve ayarları) tüm yapılandırmasının eşlendiğinde birincil ad alanından ikincil ad alanına sürekli olarak çoğaltılmasını sağlar ve istediğiniz zaman birincil ad alanından ikincil ad alanına yalnızca bir kez yük devretme işlemi başlatmanızı sağlar. Yük devretme taşıma işlemi, ad alanı için seçilen diğer ad adını ikincil ad alanına yeniden işaret eder ve eşleştirmeyi bozar. Yük devretme işlemi başlatıldıktan hemen sonra gerçekleşir.
Önemli
- Bu özellik, aynı yapılandırmaya sahip işlemlerin anlık sürekliliğini sağlar, ancak olay verilerini çoğaltmaz. Olağanüstü durum tüm bölgelerin kaybına neden olmadığı sürece, yük devretme sonrasında birincil Olay Hub'ında korunan olay verileri kurtarılabilir ve erişim geri yüklendikten sonra geçmiş olaylar oradan alınabilir. Kesintiler ve olağanüstü durumlarla başa çıkmak için olay verilerini çoğaltmak ve ilgili ad alanlarını etkin/etkin yapılandırmalarda çalıştırmak için bu Coğrafi olağanüstü durum kurtarma özellik kümesine dayanmayın, ancak çoğaltma yönergelerini izleyin.
- Birincil ad alanı içindeki 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.
Kesintiler ve olağanüstü durumlar
"Kesintiler" ile "olağanüstü durumlar" arasındaki ayrımı not etmek önemlidir. Kesinti, Azure Event Hubs'ın geçici olarak kullanılamamasıdır ve mesajlaşma deposu ve hatta veri merkezinin tamamı gibi hizmetin bazı bileşenlerini etkileyebilir. Ancak sorun düzeltildikten sonra Event Hubs yeniden kullanılabilir hale gelir. Genellikle, bir kesinti iletilerin veya diğer verilerin kaybına neden olmaz. Bu tür bir kesintiye örnek olarak veri merkezinde güç kesintisi yaşanabilir. Bazı kesintiler geçici veya ağ sorunları nedeniyle yalnızca kısa bağlantı kayıplarıdır.
Olağanüstü durum , Event Hubs kümesinin, Azure bölgesinin veya veri merkezinin kalıcı veya uzun süreli kaybı olarak tanımlanır. Bölge veya veri merkezi yeniden kullanılabilir hale gelebilir veya kullanılamayabilir ya da saatler veya günler boyunca çalışmayabilir. Bu tür afetlere örnek olarak yangın, sel veya deprem verilebilir. Kalıcı hale gelen olağanüstü durum bazı iletilerin, olayların veya diğer verilerin kaybolmasına neden olabilir. Ancak çoğu durumda veri kaybı olmaması gerekir ve veri merkezi yedeklendiğinde iletiler kurtarılabilir.
Azure Event Hubs'ın Coğrafi olağanüstü durum kurtarma özelliği bir olağanüstü durum kurtarma çözümüdür. Bu makalede açıklanan kavramlar ve iş akışı geçici veya geçici kesintiler için değil olağanüstü durum senaryoları için geçerlidir. Microsoft Azure'da olağanüstü durum kurtarma hakkında ayrıntılı bilgi için bu makaleye bakın.
Temel kavramlar ve terimler
Olağanüstü durum kurtarma özelliği meta veri olağanüstü durum kurtarma uygular ve birincil ve ikincil olağanüstü durum kurtarma ad alanlarını kullanır.
Coğrafi olağanüstü durum kurtarma özelliği yalnızca standart, premium ve ayrılmış SKU'lar için kullanılabilir. Bağlantı diğer ad aracılığıyla yapıldığından bağlantı dizesi değişiklik yapmanız gerekmez.
Bu makalede aşağıdaki terimler kullanılmıştır:
Diğer ad: Ayarladığınız olağanüstü durum kurtarma yapılandırmasının adı. Diğer ad, tek bir kararlı Tam Etki Alanı Adı (FQDN) bağlantı dizesi sağlar. Uygulamalar bir ad alanına bağlanmak için bu diğer ad bağlantı dizesi kullanır.
Birincil/ikincil ad alanı: Diğer ad alanına karşılık gelen ad alanları. Birincil ad alanı "etkin" olur ve iletileri alır (mevcut veya yeni bir ad alanı olabilir). İkincil ad alanı "pasif" şeklindedir ve ileti almaz. Her ikisi arasındaki meta veriler eşitlenir, bu nedenle her ikisi de herhangi bir uygulama kodu veya bağlantı dizesi değişiklik olmadan iletileri sorunsuz bir şekilde kabul edebilir. Yalnızca etkin ad alanının iletileri aldığından emin olmak için diğer adı kullanmanız gerekir.
Meta veriler: Olay hub'ları ve tüketici grupları gibi varlıklar ve bunların ad alanıyla ilişkili hizmetin özellikleri. Yalnızca varlıklar ve ayarları otomatik olarak çoğaltılır. İletiler ve olaylar çoğaltılamaz.
Yük devretme: İkincil ad alanını etkinleştirme işlemi.
Desteklenen ad alanı çiftleri
Birincil ve ikincil ad alanlarının aşağıdaki birleşimleri desteklenir:
| Birincil ad alanı katmanı | İzin verilen ikincil ad alanı katmanı |
|---|---|
| Standart | Standart, Ayrılmış |
| Premium | Premium |
| Ayrılmış | Ayrılmış |
Dekont
Aynı ayrılmış kümedeki ad alanlarını eşleştiremezsiniz. Ayrı kümelerdeki ad alanlarını eşleştirebilirsiniz.
Kurulum ve yük devretme akışı
Aşağıdaki bölümde yük devretme işlemine genel bir bakış sağlanır ve ilk yük devretmenin nasıl ayarlanacağı açıklanır.
Kurulum
Önce mevcut bir birincil ad alanını ve yeni bir ikincil ad alanını oluşturur veya kullanırsınız, ardından ikisini eşleştirebilirsiniz. Bu eşleştirme, bağlanmak için kullanabileceğiniz bir diğer ad sağlar. Diğer ad kullandığınızdan, bağlantı dizesi değiştirmeniz gerekmez. Yük devretme eşleştirmenize yalnızca yeni ad alanları eklenebilir.
Birincil ad alanını oluşturun.
İkincil ad alanını farklı bir bölgede oluşturun. Bu adım isteğe bağlıdır. Bir sonraki adımda eşleştirmeyi oluştururken ikincil ad alanını oluşturabilirsiniz.
Azure portalında birincil ad alanınıza gidin.
Soldaki menüden Coğrafi kurtarma'yı seçin ve araç çubuğunda Eşleştirmeyi başlat'ı seçin.
Eşleştirmeyi başlat sayfasında şu adımları izleyin:
- Mevcut ikincil ad alanını seçin veya farklı bir bölgede bir ad alanı oluşturun. Bu örnekte, mevcut bir ad alanı seçilidir.
- Diğer Ad için, geo-dr eşleştirmesi için bir diğer ad girin.
- Ardından Oluştur’u seçin.
Geo-DR Diğer Adı sayfasını görmeniz gerekir. Ayrıca, soldaki menüden Coğrafi kurtarma'ya tıklayarak birincil ad alanından bu sayfaya gidebilirsiniz.
Diğer adın birincil bağlantı dizesi erişmek için Geo-DR Diğer Adı sayfasında soldaki menüde Paylaşılan erişim ilkeleri'ni seçin. Birincil/ikincil ad alanına doğrudan bağlantı dizesi kullanmak yerine bu bağlantı dizesi kullanın.
Bu Genel Bakış sayfasında aşağıdaki eylemleri gerçekleştirebilirsiniz:
Birincil ve ikincil ad alanları arasındaki eşleştirmeyi kesme. Araç çubuğunda Eşleştirmeyi kes'i seçin.
İkincil ad alanına el ile yük devretme. Araç çubuğunda Yük Devretme'yi seçin.
Uyarı
Yük devretme, ikincil ad alanını etkinleştirir ve birincil ad alanını Coğrafi Olağanüstü Durum Kurtarma eşleştirmesinden kaldırır. Yeni bir coğrafi olağanüstü durum kurtarma çiftine sahip olmak için başka bir ad alanı oluşturun.
Son olarak, yük devretme gerekip gerekmediğini algılamak için biraz izleme eklemeniz gerekir. Çoğu durumda, hizmet büyük bir ekosistemin bir parçasıdır, bu nedenle otomatik yük devretmeler nadiren mümkündür, genellikle yük devretmelerin kalan alt sistem veya altyapıyla eşitlenmiş olarak gerçekleştirilmesi gerekir.
Örnek
Bu senaryonun bir örneğinde, iletileri veya olayları yayan bir Satış Noktası (POS) çözümünü göz önünde bulundurun. Event Hubs bu olayları bir eşleme veya yeniden biçimlendirme çözümüne geçirir ve ardından eşlenen verileri daha fazla işlem için başka bir sisteme iletir. Bu noktada, bu sistemlerin tümü aynı Azure bölgesinde barındırılabilir. Yük devretme işleminin ne zaman ve hangi bölümde yapılıp yapılamaması, altyapınızdaki veri akışına bağlıdır.
İzleme sistemleriyle veya özel olarak oluşturulmuş izleme çözümleriyle yük devretmeyi otomatikleştirebilirsiniz. Ancak, bu tür otomasyon, bu makalenin kapsamı dışında olan ek planlama ve çalışma gerektirir.
Yük devretme akışı
Yük devretmeyi başlatırsanız iki adım gerekir:
Başka bir kesinti oluşursa yeniden yük devretme yapabilmek istiyorsunuz. Bu nedenle, başka bir pasif ad alanı ayarlayın ve eşleştirmeyi güncelleştirin.
Yeniden kullanılabilir duruma geldikten sonra eski birincil ad alanından iletileri çekin. Bundan sonra, bu ad alanını coğrafi kurtarma kurulumunuzun dışında normal mesajlaşma için kullanın veya eski birincil ad alanını silin.
Dekont
Yalnızca başarısız iletme semantiği desteklenir. Bu senaryoda yük devretme işlemi yapıp yeni bir ad alanıyla yeniden eşleştirin. Yeniden başarısız olunması desteklenmez; örneğin, bir SQL kümesinde.
El ile yük devretme
Bu bölümde Azure portalı, CLI, PowerShell, C# vb. kullanarak el ile yük devretme gerçekleştirme işlemi gösterilmektedir.
Azure portalında birincil ad alanınıza gidin.
Soldaki menüden Coğrafi kurtarma'ya tıklayın.
İkincil ad alanına el ile yük devretme. Araç çubuğunda Yük Devretme'yi seçin.
Uyarı
Yük devretme, ikincil ad alanını etkinleştirir ve birincil ad alanını Coğrafi Olağanüstü Durum Kurtarma eşleştirmesinden kaldırır. Yeni bir coğrafi olağanüstü durum kurtarma çiftine sahip olmak için başka bir ad alanı oluşturun.
Yönetim
Eğer bir hata yaptıysanız; örneğin, ilk kurulum sırasında yanlış bölgeleri eşleştirdiyseniz, istediğiniz zaman iki ad alanının eşleştirmesini kesebilirsiniz. Eşleştirilmiş ad alanlarını normal ad alanları olarak kullanmak istiyorsanız diğer adı silin.
Dikkat edilmesi gerekenler
Dikkat edilmesi gereken aşağıdaki noktalara dikkat edin:
Tasarım gereği Event Hubs coğrafi olağanüstü durum kurtarma verileri çoğaltmaz ve bu nedenle birincil olay hub'ınızın eski uzaklık değerini ikincil olay hub'ınızda yeniden kullanamazsınız. Olay alıcınızı aşağıdaki yöntemlerden biriyle yeniden başlatmanızı öneririz:
- EventPosition.FromStart() - İkincil olay hub'ınızdaki tüm verileri okumak istiyorsanız.
- EventPosition.FromEnd() - İkincil olay hub'ınıza bağlantı zamanından itibaren tüm yeni verileri okumak istiyorsanız.
- EventPosition.FromEnqueuedTime(dateTime) - Belirli bir tarih ve saatten başlayarak ikincil olay hub'ınıza alınan tüm verileri okumak istiyorsanız.
Yük devretme planlamanızda zaman faktörünü de dikkate almanız gerekir. Örneğin, bağlantıyı 15-20 dakikadan uzun süre kaybederseniz, yük devretmeyi başlatmaya karar vekleyebilirsiniz.
Hiçbir verinin çoğaltılmış olmaması, geçerli etkin oturumların çoğaltılması anlamına gelir. Ayrıca yinelenen algılama ve zamanlanmış iletiler çalışmayabilir. Yeni oturumlar, zamanlanmış iletiler ve yeni yinelemeler çalışır.
Karmaşık bir dağıtılmış altyapının yük devretmesi en az bir kez prova edilmelidir.
Varlıkların eşitlenmesi biraz zaman alabilir ve dakikada yaklaşık 50-100 varlık olabilir.
Coğrafi kurtarma eşleştirmesi etkinken ikincil ad alanının yönetim düzleminin bazı yönleri salt okunur hale gelir.
Coğrafi kurtarma eşleştirme etkinken ikincil ad alanının veri düzlemi salt okunur olacaktır. İkincil ad alanının veri düzlemi, istemci bağlantısı ve erişim denetimlerinin doğrulanmasına olanak tanımak için GET isteklerini kabul eder.
Kullanılabilirlik Alanları
Event Hubs Kullanılabilirlik Alanları destekler ve Azure bölgesinde hatadan yalıtılmış konumlar sağlar. Kullanılabilirlik Alanları desteği yalnızca kullanılabilirlik alanları olan Azure bölgelerinde kullanılabilir. Hem meta veriler hem de veriler (olaylar) kullanılabilirlik alanındaki veri merkezleri arasında çoğaltılır.
Ad alanı oluştururken, kullanılabilirlik alanları olan bir bölge seçtiğinizde aşağıdaki vurgulanmış iletiyi görürsünüz.
Dekont
Azure portalını kullandığınızda, kullanılabilirlik alanları için destek yoluyla alanlar arası yedeklilik otomatik olarak etkinleştirilir. Portalda devre dışı bırakamazsınız. Azure CLI komutunu az eventhubs namespace ile --zone-redundant=false kullanabilir veya ile PowerShell komutunu New-AzEventHubNamespace-ZoneRedundant=false kullanarak alanlar arası yedeklilik devre dışı bırakılmış bir ad alanı oluşturabilirsiniz.
Özel uç noktalar
Bu bölümde, özel uç noktaları kullanan ad alanlarıyla Coğrafi olağanüstü durum kurtarma kullanılırken dikkat edilmesi gerekenler açıklanmıştır. Genel olarak Event Hubs ile özel uç noktaları kullanma hakkında bilgi edinmek için bkz . Özel uç noktaları yapılandırma.
Yeni eşleştirmeler
Özel uç nokta içeren birincil ad alanı ile özel uç nokta içermeyen ikincil ad alanı arasında bir eşleştirme oluşturmaya çalışırsanız, eşleştirme başarısız olur. Eşleştirme yalnızca hem birincil hem de ikincil ad alanlarının özel uç noktaları varsa başarılı olur. Birincil ve ikincil ad alanları ve özel uç noktaların oluşturulduğu sanal ağlarda aynı yapılandırmaları kullanmanızı öneririz.
Dekont
Birincil ad alanını özel uç nokta ve ikincil bir ad alanıyla eşleştirmeye çalıştığınızda, doğrulama işlemi yalnızca ikincil ad alanında özel bir uç nokta olup olmadığını denetler. Uç noktanın çalışıp çalışmadığını veya yük devretmeden sonra çalışıp çalışmayacağını denetlemez. Yük devretme sonrasında özel uç nokta içeren ikincil ad alanının beklendiği gibi çalıştığından emin olmak sizin sorumluluğunuzdadır.
Özel uç nokta yapılandırmalarının birincil ve ikincil ad alanları üzerinde aynı olup olmadığını test etmek için, sanal ağın dışından ikincil ad alanına bir okuma isteği (örneğin: Olay Hub'ı Alma) gönderin ve hizmetten bir hata iletisi aldığınızı doğrulayın.
Mevcut eşleştirmeler
Birincil ve ikincil ad alanı arasında eşleştirme zaten varsa, birincil ad alanında özel uç nokta oluşturma başarısız olur. Sorunu çözmek için önce ikincil ad alanında özel bir uç nokta oluşturun ve ardından birincil ad alanı için bir uç nokta oluşturun.
Dekont
İkincil ad alanına salt okunur erişim izni verilse de özel uç nokta yapılandırmalarında güncelleştirmelere izin verilir.
Önerilen yapılandırma
Uygulamanız ve Event Hubs ad alanları için olağanüstü durum kurtarma yapılandırması oluştururken, uygulamanızın hem birincil hem de ikincil örneklerini barındıran sanal ağlara karşı hem birincil hem de ikincil Event Hubs ad alanları için özel uç noktalar oluşturmanız gerekir.
İki sanal ağınız olduğunu varsayalım: VNET-1, VNET-2 ve şu birincil ve ikincil ad alanları: EventHubs-Namespace1-Primary, EventHubs-Namespace2-Secondary. Aşağıdaki adımları uygulamanız gerekir:
- EventHubs-Namespace1-Primary'da VNET-1 ve VNET-2 alt ağlarını kullanan iki özel uç nokta oluşturun
- EventHubs-Namespace2-Secondary'de, VNET-1 ve VNET-2'den aynı alt ağları kullanan iki özel uç nokta oluşturun
Bu yaklaşımın avantajı, yük devretmenin Event Hubs ad alanından bağımsız olarak uygulama katmanında gerçekleşebilir olmasıdır. Aşağıdaki senaryoları göz önünde bulundurun:
Yalnızca uygulama yük devretmesi: Burada, uygulama VNET-1'de mevcut değildir, ancak VNET-2'ye taşınacaktır. Her iki özel uç nokta da hem birincil hem de ikincil ad alanları için hem VNET-1 hem de VNET-2'de yapılandırıldığından, uygulama yalnızca çalışır.
Event Hubs yalnızca ad alanı yük devretmesi: Burada da, her iki özel uç nokta da hem birincil hem de ikincil ad alanları için her iki sanal ağda yapılandırıldığından, uygulama yalnızca çalışır.
Dekont
Sanal ağın coğrafi olağanüstü durum kurtarma yönergeleri için bkz. Sanal Ağ - İş Sürekliliği.
Rol tabanlı erişim denetimi
Birincil ad alanı içindeki 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.
Sonraki adımlar
Aşağıdaki örnekleri veya başvuru belgelerini gözden geçirin.