Azure Event Hubs-coğrafi olağanüstü durum kurtarmaAzure Event Hubs - Geo-disaster recovery

Tüm Azure bölgelerinin veya veri merkezlerinin (hiçbir kullanılabilirlik alanı kullanılmıyorsa) çalışma süresi kapalı olursa, veri işlemenin farklı bir bölgede veya veri merkezinde çalışmaya devam etmesi kritik öneme sahiptir.When entire Azure regions or datacenters (if no availability zones are used) experience downtime, it's critical for data processing to continue to operate in a different region or datacenter. Bu nedenle, coğrafi olağanüstü durum kurtarma ve coğrafi çoğaltma , herhangi bir kuruluş için önemli özelliklerdir.As such, Geo-disaster recovery and Geo-replication are important features for any enterprise. Azure Event Hubs, ad alanı düzeyinde hem coğrafi olağanüstü durum kurtarmayı hem de Coğrafi çoğaltmayı destekler.Azure Event Hubs supports both geo-disaster recovery and geo-replication, at the namespace level. 

Not

Coğrafi olağanüstü durum kurtarma özelliği yalnızca Standart ve adanmış SKU 'lariçin kullanılabilir.The Geo-disaster recovery feature is only available for the standard and dedicated SKUs.

Kesintiler ve olağanüstü durumlarOutages and disasters

"Kesintiler" ve "olağanüstü durumlar" arasındaki ayrımı dikkate almak önemlidir.It's important to note the distinction between "outages" and "disasters." Kesinti , Azure Event Hubs geçici olarak kullanılamaz ve hizmetin bir mesajlaşma deposu veya hatta tüm veri merkezinin bazı bileşenlerini etkileyebilir.An outage is the temporary unavailability of Azure Event Hubs, and can affect some components of the service, such as a messaging store, or even the entire datacenter. Ancak, sorun giderildikten sonra Event Hubs yeniden kullanılabilir hale gelir.However, after the problem is fixed, Event Hubs becomes available again. Genellikle kesinti, ileti veya diğer verilerin kaybedilmesine neden olmaz.Typically, an outage doesn't cause the loss of messages or other data. Bu tür bir kesinti, veri merkezinde bir güç hatası olabilir.An example of such an outage might be a power failure in the datacenter. Bazı kesintiler, geçici veya ağ sorunları nedeniyle yalnızca kısa bağlantı kayıplarıdır.Some outages are only short connection losses because of transient or network issues.

Olağanüstü durum , Event Hubs kümesi, Azure bölgesi veya veri merkezi 'nin kalıcı veya uzun süreli kaybı olarak tanımlanır.A disaster is defined as the permanent, or longer-term loss of an Event Hubs cluster, Azure region, or datacenter. Bölge veya veri merkezi bir kez daha kullanılamayabilir veya kullanılabilir olmayabilir ya da saat veya günler için kapatılmış olabilir.The region or datacenter may or may not become available again, or may be down for hours or days. Bu tür felate örnek olarak Fire, taşmasını veya deprem verilebilir.Examples of such disasters are fire, flooding, or earthquake. Kalıcı hale gelen bir olağanüstü durum, bazı ileti, olay veya diğer verilerin kaybedilmesine neden olabilir.A disaster that becomes permanent might cause the loss of some messages, events, or other data. Ancak çoğu durumda, veri merkezi yedeklendikten sonra veri kaybı olmaması ve iletiler kurtarılabilir.However, in most cases there should be no data loss and messages can be recovered once the data center is back up.

Azure Event Hubs coğrafi olağanüstü durum kurtarma özelliği bir olağanüstü durum kurtarma çözümüdür.The Geo-disaster recovery feature of Azure Event Hubs is a disaster recovery solution. Bu makalede açıklanan kavramlar ve iş akışı, geçici veya geçici kesintilere değil olağanüstü durum senaryoları için geçerlidir.The concepts and workflow described in this article apply to disaster scenarios, and not to transient, or temporary outages. Microsoft Azure ' de olağanüstü durum kurtarma hakkında ayrıntılı bir tartışma için Bu makaleyebakın.For a detailed discussion of disaster recovery in Microsoft Azure, see this article.

Temel kavramlar ve terimlerBasic concepts and terms

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.The disaster recovery feature implements metadata disaster recovery, and relies on primary and secondary disaster recovery namespaces.

Coğrafi olağanüstü durum kurtarma özelliği yalnızca Standart ve adanmış SKU 'lar için kullanılabilir.The Geo-disaster recovery feature is available for the standard and dedicated SKUs only. Bağlantı bir diğer ad aracılığıyla yapıldığından herhangi bir bağlantı dizesi değişikliği yapmanız gerekmez.You don't need to make any connection string changes, as the connection is made via an alias.

Bu makalede aşağıdaki terimler kullanılmaktadır:The following terms are used in this article:

  • Diğer ad: ayarladığınız bir olağanüstü durum kurtarma yapılandırması adı.Alias: The name for a disaster recovery configuration that you set up. Diğer ad, tek bir tutarlı tam etki alanı adı (FQDN) bağlantı dizesi sağlar.The alias provides a single stable Fully Qualified Domain Name (FQDN) connection string. Uygulamalar, bir ad alanına bağlanmak için bu diğer ad bağlantı dizesini kullanır.Applications use this alias connection string to connect to a namespace.

  • Birincil/ikincil ad alanı: diğer ada karşılık gelen ad alanları.Primary/secondary namespace: The namespaces that correspond to the alias. Birincil ad alanı "etkin" ve iletileri alır (var olan veya yeni bir ad alanı olabilir).The primary namespace is "active" and receives messages (can be an existing or new namespace). İkincil ad alanı "pasif" ve ileti almaz.The secondary namespace is "passive" and doesn't receive messages. Her ikisi arasındaki meta veriler eşitlenmiş olduğundan, her ikisi de herhangi bir uygulama kodu veya bağlantı dizesi değişikliği olmadan iletileri sorunsuzca kabul edebilir.The metadata between both is in sync, so both can seamlessly accept messages without any application code or connection string changes. Yalnızca etkin ad alanının iletileri aldığından emin olmak için diğer adı kullanmanız gerekir.To ensure that only the active namespace receives messages, you must use the alias.

  • Meta veri: Olay Hub 'ları ve tüketici grupları gibi varlıklar; ve ad alanıyla ilişkili hizmetin özellikleri.Metadata: Entities such as event hubs and consumer groups; and their properties of the service that are associated with the namespace. Yalnızca varlıklar ve ayarları otomatik olarak çoğaltılır.Only entities and their settings are replicated automatically. İletiler ve olaylar çoğaltılmaz.Messages and events aren't replicated.

  • Yük devretme: ikincil ad alanını etkinleştirme işlemi.Failover: The process of activating the secondary namespace.

Desteklenen ad alanı çiftleriSupported namespace pairs

Aşağıdaki birincil ve ikincil ad alanları birleşimleri desteklenir:The following combinations of primary and secondary namespaces are supported:

Birincil ad alanıPrimary namespace İkincil ad alanıSecondary namespace DestekleniyorSupported
StandartStandard StandartStandard EvetYes
StandartStandard AyrılmışDedicated EvetYes
AyrılmışDedicated AyrılmışDedicated EvetYes
AyrılmışDedicated StandartStandard HayırNo

Not

Aynı adanmış kümede bulunan ad alanlarını eşleştiriyorsunuz.You can't pair namespaces that are in the same dedicated cluster. Ayrı kümelerdeki ad alanlarını eşleştirde ayırabilirsiniz.You can pair namespaces that are in separate clusters.

Kurulum ve yük devretme akışıSetup and failover flow

Aşağıdaki bölüm, yük devretme işlemine genel bakış ve ilk yük devretmeyi ayarlamayı açıklar.The following section is an overview of the failover process, and explains how to set up the initial failover.

1

KurulumSetup

Önce mevcut bir birincil ad alanını ve yeni bir ikincil ad alanını oluşturun veya kullanın, ardından ikisini eşleştirin.You first create or use an existing primary namespace, and a new secondary namespace, then pair the two. Bu eşleştirme size bağlanmak için kullanabileceğiniz bir diğer ad sağlar.This pairing gives you an alias that you can use to connect. Bir diğer ad kullandığınız için bağlantı dizelerini değiştirmeniz gerekmez.Because you use an alias, you don't have to change connection strings. Yalnızca yeni ad alanları, yük devretme eşleştirmeye eklenebilir.Only new namespaces can be added to your failover pairing. Son olarak, bir yük devretmenin gerekli olup olmadığını algılamak için bazı izleme eklemelisiniz.Finally, you should add some monitoring to detect if a failover is necessary. Çoğu durumda, hizmet büyük bir ekosisteminin bir parçasıdır. bu nedenle, yük devretme işlemleri genellikle geri kalan alt sistem veya altyapıyla eşitlenmelidir.In most cases, the service is one part of a large ecosystem, thus automatic failovers are rarely possible, as often failovers must be performed in sync with the remaining subsystem or infrastructure.

ÖrnekExample

Bu senaryonun bir örneğinde, ileti ya da olay gösteren bir satış noktası (POS) çözümü düşünün.In one example of this scenario, consider a Point of Sale (POS) solution that emits either messages or events. Event Hubs, bu olayları bazı eşleme veya yeniden biçimlendirme çözümüne geçirir ve daha sonra daha fazla işlenmek üzere eşlenen verileri başka bir sisteme iletir.Event Hubs passes those events to some mapping or reformatting solution, which then forwards mapped data to another system for further processing. Bu noktada, tüm bu sistemler aynı Azure bölgesinde barındırılıyor olabilir.At that point, all of these systems might be hosted in the same Azure region. Ne zaman ve hangi parçanın yük devretme kararı, altyapınızdaki verilerin akışına bağlıdır.The decision on when and what part to fail over depends on the flow of data in your infrastructure.

Yük devretmeyi, izleme sistemleriyle veya özel olarak oluşturulmuş izleme çözümleriyle otomatik hale getirebilirsiniz.You can automate failover either with monitoring systems, or with custom-built monitoring solutions. Ancak, bu tür otomasyon, bu makalenin kapsamı dışında daha fazla planlama ve iş alır.However, such automation takes extra planning and work, which is out of the scope of this article.

Yük devretme akışıFailover flow

Yük devretmeyi başlatırsanız iki adım gereklidir:If you initiate the failover, two steps are required:

  1. Başka bir kesinti oluşursa, yeniden yük devredebilmek istersiniz.If another outage occurs, you want to be able to fail over again. Bu nedenle, başka bir pasif ad alanı ayarlayın ve eşlemeyi güncelleştirin.Therefore, set up another passive namespace and update the pairing.

  2. Yeniden kullanılabilir olduktan sonra eski birincil ad alanından ileti çekin.Pull messages from the former primary namespace once it's available again. Bundan sonra, coğrafi kurtarma kurulumunuzu dışında düzenli mesajlaşma için bu ad alanını kullanın veya eski birincil ad alanını silin.After that, use that namespace for regular messaging outside of your geo-recovery setup, or delete the old primary namespace.

Not

Yalnızca başarısız iletme semantiği desteklenir.Only fail forward semantics are supported. Bu senaryoda yük devreder ve sonra yeni bir ad alanı ile yeniden eşleştirin.In this scenario, you fail over and then re-pair with a new namespace. Yeniden başarısız olma desteklenmez; Örneğin, bir SQL kümesinde.Failing back is not supported; for example, in a SQL cluster.

2

YönetimManagement

Bir hata yaptıysanız, Örneğin, ilk kurulum sırasında yanlış bölgeleri eşleştirdikten sonra, iki ad alanının eşleştirmesini dilediğiniz zaman kesebilirsiniz.If you made a mistake; for example, you paired the wrong regions during the initial setup, you can break the pairing of the two namespaces at any time. Eşleştirilmiş ad alanlarını normal ad alanları olarak kullanmak istiyorsanız, diğer adı silin.If you want to use the paired namespaces as regular namespaces, delete the alias.

ÖrneklerSamples

GitHub 'daki örnek , bir yük devretme ayarlamayı ve başlatmayı gösterir.The sample on GitHub shows how to set up and initiate a failover. Bu örnek aşağıdaki kavramları göstermektedir:This sample demonstrates the following concepts:

  • Event Hubs ile Azure Resource Manager kullanmak için Azure Active Directory gereken ayarlar.Settings required in Azure Active Directory to use Azure Resource Manager with Event Hubs.
  • Örnek kodu yürütmek için gereken adımlar.Steps required to execute the sample code.
  • Geçerli birincil ad alanından gönderin ve alın.Send and receive from the current primary namespace.

Önemli noktalarConsiderations

Bu sürümü göz önünde bulundurmanız için aşağıdaki noktalara dikkat edin:Note the following considerations to keep in mind with this release:

  1. Tasarım, coğrafi olağanüstü durum kurtarma Event Hubs verileri çoğaltmaz ve bu nedenle ikincil Olay Hub 'ınızdaki birincil olay hub 'ınızın eski değer değerini yeniden kullanamazsınız.By design, Event Hubs geo-disaster recovery does not replicate data, and therefore you cannot reuse the old offset value of your primary event hub on your secondary event hub. Aşağıdaki yöntemlerden birini kullanarak olay alıcılarınızı yeniden başlatmanız önerilir:We recommend restarting your event receiver with one of the following methods:
  • Eventposition. FromStart () -ikincil Olay Hub 'ınızdaki tüm verileri okumak istiyorsanız.EventPosition.FromStart() - If you wish read all data on your secondary event hub.
  • Eventposition. FromEnd () -ikincil Olay Hub 'ınıza bağlantı sırasında tüm yeni verileri okumak istiyorsanız.EventPosition.FromEnd() - If you wish to read all new data from the time of connection to your secondary event hub.
  • Eventposition. FromEnqueuedTime (DateTime) -belirli bir tarih ve saatten itibaren ikincil Olay Hub 'ınızdaki alınan tüm verileri okumak istiyorsanız.EventPosition.FromEnqueuedTime(dateTime) - If you wish to read all data received in your secondary event hub starting from a given date and time.
  1. Yük devretme planlamadaki zaman etmenini de göz önünde bulundurmanız gerekir.In your failover planning, you should also consider the time factor. Örneğin, 15 ila 20 dakikaya kadar olan bağlantıyı kaybederseniz, yük devretmeyi başlatmaya karar verebilirsiniz.For example, if you lose connectivity for longer than 15 to 20 minutes, you might decide to initiate the failover.

  2. Hiçbir veri çoğaltılmaması, etkin olan oturumların çoğaltılmadığı anlamına gelir.The fact that no data is replicated means that currently active sessions aren't replicated. Ayrıca, yinelenen algılama ve zamanlanan iletiler çalışmayabilir.Additionally, duplicate detection and scheduled messages may not work. Yeni oturumlar, zamanlanan mesajlar ve yeni yinelemeler çalışacaktır.New sessions, scheduled messages, and new duplicates will work.

  3. Karmaşık bir dağıtılmış altyapının yük devretmesi en az bir kez prova edilmelidir.Failing over a complex distributed infrastructure should be rehearsed at least once.

  4. Varlıkların eşitlenmesi birkaç dakika sürebilir ve dakikada yaklaşık 50-100 varlık olabilir.Synchronizing entities can take some time, approximately 50-100 entities per minute.

Kullanılabilirlik AlanlarıAvailability Zones

Event Hubs standart SKU, bir Azure bölgesi içinde hataya yalıtılmış konumlar sağlayarak kullanılabilirlik alanlarıdestekler.The Event Hubs Standard SKU supports Availability Zones, providing fault-isolated locations within an Azure region.

Not

Azure Event Hubs Standard için Kullanılabilirlik Alanları desteği yalnızca kullanılabilirlik bölgelerinin bulunduğu Azure bölgelerinde kullanılabilir.The Availability Zones support for Azure Event Hubs Standard is only available in Azure regions where availability zones are present.

Azure portal kullanarak yalnızca yeni ad alanlarında Kullanılabilirlik Alanları etkinleştirebilirsiniz.You can enable Availability Zones on new namespaces only, using the Azure portal. Event Hubs var olan ad alanlarının geçişini desteklemez.Event Hubs doesn't support migration of existing namespaces. Ad alanınız üzerinde etkinleştirildikten sonra bölge yedekliliği devre dışı bırakılamıyor.You can't disable zone redundancy after enabling it on your namespace.

3

Özel uç noktalarPrivate endpoints

Bu bölümde, Özel uç noktaları kullanan ad alanları ile coğrafi olağanüstü durum kurtarma kullanılırken ek konular sunulmaktadır.This section provides additional considerations when using Geo-disaster recovery with namespaces that use private endpoints. Genel olarak Event Hubs özel uç noktaları kullanma hakkında bilgi edinmek için bkz. Özel uç noktaları yapılandırma.To learn about using private endpoints with Event Hubs in general, see Configure private endpoints.

Yeni eşleştirmelerininNew pairings

Özel bir uç nokta ve ikincil ad alanı olan bir birincil ad alanı arasında özel bir uç nokta olmadan bir eşleştirme oluşturmaya çalışırsanız, eşleştirme başarısız olur.If you try to create a pairing between a primary namespace with a private endpoint and a secondary namespace without a private endpoint, the pairing will fail. Eşleştirme yalnızca birincil ve ikincil ad alanlarının özel uç noktaları varsa başarılı olur.The pairing will succeed only if both primary and secondary namespaces have private endpoints. Birincil ve ikincil ad alanlarında ve özel uç noktaların oluşturulduğu sanal ağlarda aynı konfigürasyonları kullanmanızı öneririz.We recommend that you use same configurations on the primary and secondary namespaces and on virtual networks in which private endpoints are created.

Not

Birincil ad alanını özel uç nokta ve ikincil ad alanıyla eşleştirmeye çalıştığınızda, doğrulama işlemi yalnızca ikincil ad alanında özel bir uç noktanın bulunup bulunmadığını denetler.When you try to pair the primary namespace with private endpoint and a secondary namespace, the validation process only checks whether a private endpoint exists on the secondary namespace. Uç noktanın çalışıp çalışmadığını denetlemez veya yük devretmeden sonra çalışır.It doesn't check whether the endpoint works or will work after failover. Özel uç nokta olan ikincil ad alanının Yük devretme sonrasında beklendiği gibi çalışmasını sağlamak sizin sorumluluğunuzdadır.It's your responsibility to ensure that the secondary namespace with private endpoint will work as expected after failover.

Özel uç nokta yapılandırmalarının birincil ve ikincil ad alanlarında aynı olduğunu sınamak için, sanal ağın dışından ikincil ad alanına bir okuma isteği (örneğin: Olay Hub 'ı al) gönderin ve hizmetten bir hata iletisi alduğunuzu doğrulayın.To test that the private endpoint configurations are same on primary and secondary namespaces, send a read request (for example: Get Event Hub) to the secondary namespace from outside the virtual network, and verify that you receive an error message from the service.

Mevcut eşleştirmelerininExisting pairings

Birincil ve ikincil ad alanı arasında eşleştirme zaten varsa, birincil ad alanı üzerinde özel uç nokta oluşturma başarısız olur.If pairing between primary and secondary namespace already exists, private endpoint creation on the primary namespace will fail. Çözümlemek için, önce ikincil ad alanında özel bir uç nokta oluşturun ve ardından birincil ad alanı için bir tane oluşturun.To resolve, create a private endpoint on the secondary namespace first and then create one for the primary namespace.

Not

İkincil ad alanına salt okuma erişimine izin verdiğimiz için, Özel uç nokta yapılandırmalarına yönelik güncelleştirmelere izin verilir.While we allow read-only access to the secondary namespace, updates to the private endpoint configurations are permitted.

Uygulamanız için bir olağanüstü durum kurtarma yapılandırması oluştururken ve ad alanları Event Hubs, hem birincil hem de ikincil Event Hubs ad alanları için, uygulamanızın birincil ve ikincil örneklerini barındıran sanal ağlara karşı özel uç noktalar oluşturmanız gerekir.When creating a disaster recovery configuration for your application and Event Hubs namespaces, you must create private endpoints for both primary and secondary Event Hubs namespaces against virtual networks hosting both primary and secondary instances of your application.

İki sanal ağınız olduğunu varsayalım: VNET-1, VNET-2 ve bu birincil ve ikincil ad alanları: EventHubs-Namespace1-PRIMARY, EventHubs-Namespace2-Secondary.Let's say you have two virtual networks: VNET-1, VNET-2 and these primary and secondary namespaces: EventHubs-Namespace1-Primary, EventHubs-Namespace2-Secondary. Aşağıdaki adımları gerçekleştirmeniz gerekir:You need to do the following steps:

  • EventHubs-Namespace1-Primary üzerinde, VNET-1 ve VNET-2 alt ağlarını kullanan iki özel uç nokta oluşturunOn EventHubs-Namespace1-Primary, create two private endpoints that use subnets from VNET-1 and VNET-2
  • EventHubs-Namespace2-Secondary üzerinde, VNET-1 ve VNET-2 ' d a aynı alt ağları kullanan iki özel uç nokta oluşturunOn EventHubs-Namespace2-Secondary, create two private endpoints that use the same subnets from VNET-1 and VNET-2

Özel uç noktalar ve sanal ağlar

Bu yaklaşımın avantajı, yük devretmenin uygulama katmanında Event Hubs ad alanından bağımsız olmasını sağlayabilmektedir.Advantage of this approach is that failover can happen at the application layer independent of Event Hubs namespace. Aşağıdaki senaryoları göz önünde bulundurun:Consider the following scenarios:

Yalnızca uygulama yük devretmesi: Burada uygulama VNET-1 ' de mevcut olmayacaktır, ancak VNET-2 ' ye geçmeyecektir.Application-only failover: Here, the application won't exist in VNET-1 but will move to VNET-2. Hem birincil hem de ikincil ad alanları için hem VNET-1 hem de VNET-2 üzerinde hem özel uç noktalar yapılandırıldığından, uygulama çalışacaktır.As both private endpoints are configured on both VNET-1 and VNET-2 for both primary and secondary namespaces, the application will just work.

Yalnızca ad alanı yük devretme Event Hubs: her iki özel uç nokta hem birincil hem de ikincil ad alanları için her iki sanal ağda de yapılandırıldığı için, uygulama çalışacaktır.Event Hubs namespace-only failover: Here again, since both private endpoints are configured on both virtual networks for both primary and secondary namespaces, the application will just work.

Not

Bir sanal ağın coğrafi olağanüstü durum kurtarma hakkında yönergeler için bkz. sanal ağ-Iş sürekliliği.For guidance on geo-disaster recovery of a virtual network, see Virtual Network - Business Continuity.

Sonraki adımlarNext steps

  • GitHub 'daki örnek , coğrafi eşleme oluşturan ve olağanüstü durum kurtarma senaryosu için yük devretme Başlatan basit bir iş akışında gösterilmektedir.The sample on GitHub walks through a simple workflow that creates a geo-pairing and initiates a failover for a disaster recovery scenario.
  • REST API başvurusu , coğrafi olağanüstü durum kurtarma yapılandırmasını gerçekleştirmek Için API 'leri açıklar.The REST API reference describes APIs for performing the Geo-disaster recovery configuration.

Event Hubs hakkında daha fazla bilgi için şu bağlantıları ziyaret edin:For more information about Event Hubs, visit the following links: