Azure Event Hubs - 지리적 재해 복구Azure Event Hubs - Geo-disaster recovery

데이터 처리 리소스의 치명적인 가동 중단에 대 한 복원 력을 많은 기업에서 요구 하는 것 이며, 경우에 따라 업계 규정에도 필요 합니다.Resilience against disastrous outages of data processing resources is a requirement for many enterprises and in some cases even required by industry regulations.

Azure Event Hubs는 이미 개별 컴퓨터의 치명적인 오류에 대 한 위험을 분산 하거나 데이터 센터 내에서 여러 오류 도메인에 걸쳐 있는 클러스터 전체에 대해 완전 한 랙을 분산 하 고 있으며, 서비스가 계속 해 서 보장 되는 서비스 수준 내에서 작업을 계속 수행 하 고 이러한 오류가 발생할 경우 중단 없이 계속 작동 하도록 투명 한 오류 감지 및 장애 조치 메커니즘을 구현 합니다.Azure Event Hubs already spreads the risk of catastrophic failures of individual machines or even complete racks across clusters that span multiple failure domains within a datacenter and it implements transparent failure detection and failover mechanisms such that the service will continue to operate within the assured service-levels and typically without noticeable interruptions in the event of such failures. 가용성 영역에 대해 enabled 옵션을 사용 하 여 Event Hubs 네임 스페이스를 만든 경우 중단 위험은 실제로 분리 된 세 가지 기능에 추가로 분산 되며 서비스에는 전체 기능의 완전 한 치명적인 손실을 신속 하 게 처리할 수 있는 충분 한 용량 예약이 있습니다.If an Event Hubs namespace has been created with the enabled option for availability zones, the outage risk is further spread across three physically separated facilities, and the service has enough capacity reserves to instantly cope with the complete, catastrophic loss of the entire facility.

가용성 영역을 지 원하는 모든 활성 Azure Event Hubs 클러스터 모델은 억음 하드웨어 오류에 대 한 복원 력 및 전체 데이터 센터 시설의 심각한 손실을 제공 합니다.The all-active Azure Event Hubs cluster model with availability zone support provides resiliency against grave hardware failures and even catastrophic loss of entire datacenter facilities. 그러나 이러한 측정값이 충분히 방어 될 수 없는 광범위 한 물리적 소멸이 있는 경우에도 매우 많은 상황이 발생할 수 있습니다.Still, there might be grave situations with widespread physical destruction that even those measures cannot sufficiently defend against.

Event Hubs 지역 재해 복구 기능은 이러한 크기의 재해 로부터 쉽게 복구 하 고, 응용 프로그램 구성을 변경 하지 않고도 실패 한 Azure 지역을 중단 하는 데 사용할 수 있도록 설계 되었습니다.The Event Hubs Geo-disaster recovery feature is designed to make it easier to recover from a disaster of this magnitude and abandon a failed Azure region for good and without having to change your application configurations. Azure 지역을 포기 하는 것은 일반적으로 여러 서비스를 포함 하며이 기능은 주로 복합 응용 프로그램 구성의 무결성 유지를 목표로 합니다.Abandoning an Azure region will typically involve several services and this feature primarily aims at helping to preserve the integrity of the composite application configuration.

Geo-Disaster 복구 기능을 사용 하면 네임 스페이스 (Event Hubs, 소비자 그룹 및 설정)의 전체 구성이 쌍을 이루는 경우 주 네임 스페이스에서 보조 네임 스페이스로 지속적으로 복제 되 고, 언제 든 지 주 데이터베이스에서 보조 데이터베이스로의 한 번만 장애 조치 (failover)를 시작할 수 있습니다.The Geo-Disaster recovery feature ensures that the entire configuration of a namespace (Event Hubs, Consumer Groups and settings) is continuously replicated from a primary namespace to a secondary namespace when paired, and it allows you to initiate a once-only failover move from the primary to the secondary at any time. 장애 조치 (failover) 이동은 네임 스페이스에 대해 선택한 별칭 이름을 보조 네임 스페이스로 다시 가리키고 페어링을 중단 합니다.The failover move will re-point the chosen alias name for the namespace to the secondary namespace and then break the pairing. 장애 조치 (failover)가 시작 된 후에는 거의 즉시 이루어집니다.The failover is nearly instantaneous once initiated.

중요

이 기능을 사용 하면 동일한 구성을 사용 하 여 작업을 즉시 연속성 하지만 이벤트 데이터를 복제 하지 않습니다.The feature enables instantaneous continuity of operations with the same configuration, but does not replicate the event data. 재해가 발생 한 경우를 제외 하 고 장애 조치 (failover) 후 주 이벤트 허브에 유지 되는 이벤트 데이터를 복구할 수 있으며, 액세스를 복원 하면 해당 이벤트에서 기록 이벤트를 가져올 수 있습니다.Unless the disaster caused the loss of all zones, the event data that is preserved in the primary Event Hub after failover will be recoverable and the historic events can be obtained from there once access is restored. 이벤트 데이터를 복제 하 고 능동/능동 구성에서 해당 네임 스페이스를 운영 하 여 중단 및 재해를 처리할 수 있도록 이러한 지역 재해 복구 기능 집합에 대해서는 설명 하지 말고 복제 지침을 따르세요.For replicating event data and operating corresponding namespaces in active/active configurations to cope with outages and disasters, don't lean on this Geo-disaster recovery feature set, but follow the replication guidance.

중단 및 재해Outages and disasters

"중단" 및 "재해" 간의 차이점을 참고하는 것이 중요합니다.It's important to note the distinction between "outages" and "disasters." 중단 은 Azure Event Hubs를 일시적으로 사용할 수 없는 것으로, 메시징 저장소와 같은 서비스의 일부 구성 요소나 전체 데이터 센터에 영향을 줄 수 있습니다.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. 그렇지만 문제가 해결되면 Event Hubs를 다시 사용할 수 있게 됩니다.However, after the problem is fixed, Event Hubs becomes available again. 일반적으로 중단으로 인해 메시지나 기타 데이터가 손실되지는 않습니다.Typically, an outage doesn't cause the loss of messages or other data. 이러한 중단의 예로 데이터 센터의 전원 장애를 들 수 있습니다.An example of such an outage might be a power failure in the datacenter. 일부 가동 중단은 일시적인 네트워크 문제로 인해 짧은 연결 오류가 발생합니다.Some outages are only short connection losses because of transient or network issues.

재해 는 Event Hubs 클러스터, Azure 지역 또는 데이터 센터의 영구적이거나 장기적인 손실을 의미합니다.A disaster is defined as the permanent, or longer-term loss of an Event Hubs cluster, Azure region, or datacenter. 지역 또는 데이터 센터는 다시 사용할 수 있게 될 수도, 그렇지 않을 수도 있고 몇 시간 또는 며칠 동안 중지될 수도 있습니다.The region or datacenter may or may not become available again, or may be down for hours or days. 재해의 예로는 화재, 홍수 또는 지진이 있습니다.Examples of such disasters are fire, flooding, or earthquake. 영구적 재해는 일부 메시지, 이벤트 또는 기타 데이터의 손실을 발생시킬 수 있습니다.A disaster that becomes permanent might cause the loss of some messages, events, or other data. 그러나 대부분의 경우에는 데이터 손실이 없으며 메시지는 데이터 센터를 백업하면 복구할 수 있습니다.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의 지역 재해 복구 기능은 재해 복구 솔루션입니다.The Geo-disaster recovery feature of Azure Event Hubs is a disaster recovery solution. 이 문서에 설명된 개념 및 워크플로는 재해 시나리오에 적용되며 일시적이거나 임시적인 중단이 아닙니다.The concepts and workflow described in this article apply to disaster scenarios, and not to transient, or temporary outages. Microsoft Azure의 재해 복구에 대해 자세히 알아보려면 이 문서를 참조하세요.For a detailed discussion of disaster recovery in Microsoft Azure, see this article.

기본 개념 및 용어Basic concepts and terms

재해 복구 기능은 메타데이터 재해 복구를 구현하며 주 및 보조 재해 복구 네임스페이스를 사용합니다.The disaster recovery feature implements metadata disaster recovery, and relies on primary and secondary disaster recovery namespaces.

지리적 재해 복구 기능은 표준 및 전용 SKU에만 사용할 수 있습니다.The Geo-disaster recovery feature is available for the standard and dedicated SKUs only. 별칭을 통해 연결이 수행되므로 연결 문자열을 변경할 필요가 없습니다.You don't need to make any connection string changes, as the connection is made via an alias.

이 문서에서는 다음 용어가 사용됩니다.The following terms are used in this article:

  • 별칭: 설정하는 재해 복구 구성의 이름입니다.Alias: The name for a disaster recovery configuration that you set up. 별칭은 하나의 안정적인 FQDN(정규화된 도메인 이름) 연결 문자열을 제공합니다.The alias provides a single stable Fully Qualified Domain Name (FQDN) connection string. 애플리케이션은 이 별칭 연결 문자열을 사용하여 네임스페이스에 연결합니다.Applications use this alias connection string to connect to a namespace.

  • 주/보조 네임스페이스: 별칭에 해당하는 네임스페이스입니다.Primary/secondary namespace: The namespaces that correspond to the alias. 기본 네임스페이스는 “활성”이며 메시지를 수신합니다(기존 또는 새 네임스페이스일 수 있음).The primary namespace is "active" and receives messages (can be an existing or new namespace). 보조 네임스페이스는 “수동”이며 메시지를 수신하지 않습니다.The secondary namespace is "passive" and doesn't receive messages. 둘 간의 메타데이터가 동기화되므로 둘 다 애플리케이션 코드 또는 연결 문자열을 변경하지 않고 메시지를 원활하게 수락할 수 있습니다.The metadata between both is in sync, so both can seamlessly accept messages without any application code or connection string changes. 활성 네임스페이스만 메시지를 수신하는지 확인하려면 별칭을 사용해야 합니다.To ensure that only the active namespace receives messages, you must use the alias.

  • 메타데이터: Event Hubs 및 소비자 그룹과 같은 엔터티 및 네임스페이스와 연결된 서비스의 해당 속성입니다.Metadata: Entities such as event hubs and consumer groups; and their properties of the service that are associated with the namespace. 엔터티 및 해당 설정만이 자동으로 복제됩니다.Only entities and their settings are replicated automatically. 메시지 및 이벤트는 복제되지 않습니다.Messages and events aren't replicated.

  • 장애 조치(Failover) : 보조 네임스페이스를 활성화하는 프로세스입니다.Failover: The process of activating the secondary namespace.

지원되는 네임스페이스 쌍Supported namespace pairs

기본 및 보조 네임스페이스의 다음과 같은 조합이 지원됩니다.The following combinations of primary and secondary namespaces are supported:

기본 네임스페이스Primary namespace 보조 네임스페이스Secondary namespace 지원됨Supported
StandardStandard StandardStandard Yes
StandardStandard 전용Dedicated Yes
전용Dedicated 전용Dedicated Yes
전용Dedicated StandardStandard No

참고

동일한 전용 클러스터에 있는 네임스페이스는 쌍으로 연결할 수 없습니다.You can't pair namespaces that are in the same dedicated cluster. 별도의 클러스터에 있는 네임스페이스는 쌍으로 연결할 수 있습니다.You can pair namespaces that are in separate clusters.

흐름 설정 및 장애 조치Setup and failover flow

다음 섹션은 장애 조치 프로세스의 개요이며 초기 장애 조치를 설정하는 방법을 설명합니다.The following section is an overview of the failover process, and explains how to set up the initial failover.

1

설치 프로그램Setup

먼저 기존의 기본 네임스페이스 및 새로운 보조 네임스페이스를 만들거나 사용한 다음 둘을 쌍으로 연결합니다.You first create or use an existing primary namespace, and a new secondary namespace, then pair the two. 이 페어링은 연결하는 데 사용할 수 있는 별칭을 제공합니다.This pairing gives you an alias that you can use to connect. 별칭을 사용하므로 연결 문자열을 변경할 필요가 없습니다.Because you use an alias, you don't have to change connection strings. 새 네임스페이스에만 장애 조치(Failover) 페어링에 추가할 수 있습니다.Only new namespaces can be added to your failover pairing.

  1. 기본 네임 스페이스를 만듭니다.Create the primary namespace.

  2. 다른 지역에 보조 네임 스페이스를 만듭니다.Create the secondary namespace in a different region. 이 단계는 선택 사항입니다.This step is optional. 다음 단계에서 페어링을 만드는 동안 보조 네임 스페이스를 만들 수 있습니다.You can create the secondary namespace while creating the pairing in the next step.

  3. Azure Portal에서 주 네임 스페이스로 이동 합니다.In the Azure portal, navigate to your primary namespace.

  4. 왼쪽 메뉴에서 지역에서 복구 를 선택 하 고 도구 모음에서 페어링 시작 을 선택 합니다.Select Geo-recovery on the left menu, and select Initiate pairing on the toolbar.

    기본 네임 스페이스에서 페어링 시작

  5. 페어링 시작 페이지에서 다음 단계를 수행 합니다.On the Initiate pairing page, follow these steps:

    1. 기존 보조 네임 스페이스를 선택 하거나 다른 지역에서 하나를 만듭니다.Select an existing secondary namespace or create one in a different region. 이 예제에서는 기존 네임 스페이스를 선택 합니다.In this example, an existing namespace is selected.
    2. 별칭 에 대해 지역 dr 쌍의 별칭을 입력 합니다.For Alias, enter an alias for the geo-dr pairing.
    3. 그런 다음 만들기 를 선택합니다.Then, select Create.

    보조 네임 스페이스 선택

  6. 지리적 DR 별칭 페이지가 표시 되어야 합니다.You should see the Geo-DR Alias page. 왼쪽 메뉴에서 지역에서 복구 를 선택 하 여 기본 네임 스페이스에서이 페이지로 이동할 수도 있습니다.You can also navigate to this page from the primary namespace by selecting Geo-recovery on the left menu.

    지리적 DR 별칭 페이지

  7. 지리적 DR 별칭 페이지의 왼쪽 메뉴에서 공유 액세스 정책 을 선택 하 여 별칭의 기본 연결 문자열에 액세스 합니다.On the Geo-DR Alias page, select Shared access policies on the left menu to access the primary connection string for the alias. 기본/보조 네임 스페이스에 대 한 연결 문자열을 직접 사용 하는 대신이 연결 문자열을 사용 합니다.Use this connection string instead of using the connection string to the primary/secondary namespace directly.

  8. 개요 페이지에서 다음 작업을 수행할 수 있습니다.On this Overview page, you can do the following actions:

    1. 기본 네임 스페이스와 보조 네임 스페이스 간의 페어링을 해제 합니다.Break the pairing between primary and secondary namespaces. 도구 모음에서 연결 끊기 를 선택 합니다.Select Break pairing on the toolbar.

    2. 보조 네임 스페이스로 수동으로 장애 조치 (failover) 합니다.Manually failover to the secondary namespace. 도구 모음에서 장애 조치 (Failover) 를 선택 합니다.Select Failover on the toolbar.

      경고

      장애 조치 (failover)는 보조 네임 스페이스를 활성화 하 고 Geo-Disaster Recovery 페어링에서 기본 네임 스페이스를 제거 합니다.Failing over will activate the secondary namespace and remove the primary namespace from the Geo-Disaster Recovery pairing. 새 지역 재해 복구 쌍을 포함 하는 다른 네임 스페이스를 만듭니다.Create another namespace to have a new geo-disaster recovery pair.

마지막으로 장애 조치가 필요한 경우 감지할 몇 가지 모니터링을 추가해야 합니다.Finally, you should add some monitoring to detect if a failover is necessary. 대부분의 경우 서비스는 대규모 에코시스템의 일부입니다. 따라서 장애 조치가 주로 나머지 하위 시스템 또는 인프라와 동기화되어 수행되어야 할 때가 많으므로 자동 장애 조치는 거의 불가능합니다.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.

예제Example

이 시나리오의 예로 메시지 또는 이벤트를 내보내는 POS(Point of Sale) 솔루션을 고려합니다.In one example of this scenario, consider a Point of Sale (POS) solution that emits either messages or events. Event Hubs는 일부 매핑 또는 다시 포맷 솔루션에 해당 이벤트를 전달합니다. 그런 다음 추가 처리를 위해 다른 시스템에 매핑된 데이터를 전달합니다.Event Hubs passes those events to some mapping or reformatting solution, which then forwards mapped data to another system for further processing. 해당 시점에 이러한 시스템은 모두 같은 Azure 지역에서 호스팅될 수 있습니다.At that point, all of these systems might be hosted in the same Azure region. 장애 조치 (failover)를 수행할 시기 및 파트에 대 한 결정은 인프라의 데이터 흐름에 따라 결정 됩니다.The decision of when and what part to fail over depends on the flow of data in your infrastructure.

모니터링 시스템 또는 사용자 빌드 모니터링 솔루션을 사용하여 장애 조치를 자동화할 수 있습니다.You can automate failover either with monitoring systems, or with custom-built monitoring solutions. 그러나 이러한 자동화에는 추가 계획 및 작업이 필요합니다. 이 부분은 이 문서에서 다루지 않습니다.However, such automation takes extra planning and work, which is out of the scope of this article.

흐름 장애 조치(Failover)Failover flow

장애 조치를 시작하는 경우 다음과 같은 두 단계가 필요합니다.If you initiate the failover, two steps are required:

  1. 작동 중단이 발생하면 다시 장애 조치(Failover)할 수 있어야 합니다.If another outage occurs, you want to be able to fail over again. 따라서 다른 수동 네임스페이스를 설정하고 페어링을 업데이트합니다.Therefore, set up another passive namespace and update the pairing.

  2. 사용할 수 있으면 이전 기본 네임스페이스에서 메시지를 끌어옵니다.Pull messages from the former primary namespace once it's available again. 그 후에 지역 복구 설정의 외부에서 일반 메시징에 해당 네임스페이스를 사용하거나 이전 기본 네임스페이스를 삭제합니다.After that, use that namespace for regular messaging outside of your geo-recovery setup, or delete the old primary namespace.

참고

실패 전달 의미 체계만이 지원됩니다.Only fail forward semantics are supported. 이 시나리오에서는 새 네임스페이스를 사용하여 장애 조치하고 다시 페어링합니다.In this scenario, you fail over and then re-pair with a new namespace. 예를 들어 SQL 클러스터에서 장애 복구는 지원되지 않습니다.Failing back is not supported; for example, in a SQL cluster.

2

관리Management

예를 들어 초기 설정 작업 중에 잘못된 지역을 페어링하는 실수가 발생한 경우 언제든지 두 네임스페이스의 페어링을 해제할 수 있습니다.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. 일반 네임스페이스와 페어링된 네임스페이스를 사용하려는 경우 별칭을 삭제합니다.If you want to use the paired namespaces as regular namespaces, delete the alias.

샘플Samples

GitHub의 샘플에서는 장애 조치를 설정하고 시작하는 방법을 보여줍니다.The sample on GitHub shows how to set up and initiate a failover. 이 샘플은 다음과 같은 개념을 보여줍니다.This sample demonstrates the following concepts:

  • Event Hubs에서 Azure Resource Manager를 사용하는 데 필요한 Azure Active Directory의 설정Settings required in Azure Active Directory to use Azure Resource Manager with Event Hubs.
  • 샘플 코드를 실행하는 데 필요한 단계Steps required to execute the sample code.
  • 현재 기본 네임스페이스에서 전달 및 수신Send and receive from the current primary namespace.

고려 사항Considerations

다음 고려 사항에 유의 하세요.Note the following considerations to keep in mind:

  1. 기본적으로 Event Hubs 지리적 재해 복구는 데이터를 복제하지 않으므로 보조 이벤트 허브에서 기본 이벤트 허브의 이전 오프셋 값을 다시 사용할 수 없습니다.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. 다음 방법 중 하나를 사용하여 이벤트 수신기를 다시 시작하는 것이 좋습니다.We recommend restarting your event receiver with one of the following methods:

    • EventPosition.FromStart() - 보조 이벤트 허브의 모든 데이터를 읽으려는 경우EventPosition.FromStart() - If you wish read all data on your secondary event hub.
    • EventPosition.FromEnd() - 보조 이벤트 허브에 연결된 시간부터 모든 새 데이터를 읽으려는 경우EventPosition.FromEnd() - If you wish to read all new data from the time of connection to your secondary event hub.
    • EventPosition.FromEnqueuedTime(dateTime) - 지정된 날짜 및 시간에서 시작하여 보조 이벤트 허브에서 받은 모든 데이터를 읽으려는 경우EventPosition.FromEnqueuedTime(dateTime) - If you wish to read all data received in your secondary event hub starting from a given date and time.
  2. 장애 조치 계획에서 시간 요소를 고려해야 합니다.In your failover planning, you should also consider the time factor. 예를 들어 15~20분이 넘게 연결이 손실된 경우 장애 조치를 시작하기로 결정할 수 있습니다.For example, if you lose connectivity for longer than 15 to 20 minutes, you might decide to initiate the failover.

  3. 데이터가 복제 되지 않는다는 사실은 현재 활성 세션이 복제 되지 않음을 의미 합니다.The fact that no data is replicated means that current active sessions aren't replicated. 또한 중복 검색 및 예약된 메시지가 작동하지 않을 수 있습니다.Additionally, duplicate detection and scheduled messages may not work. 새 세션, 예약된 메시지 및 새 중복이 작동합니다.New sessions, scheduled messages, and new duplicates will work.

  4. 복잡한 분산 인프라를 장애 조치하려면 한 번 이상 예행 연습을 수행해야 합니다.Failing over a complex distributed infrastructure should be rehearsed at least once.

  5. 엔터티를 동기화하는 데 분당 약 50~100개의 엔터티를 처리하므로 다소 시간이 걸릴 수 있습니다.Synchronizing entities can take some time, approximately 50-100 entities per minute.

가용성 영역Availability Zones

Event Hubs 표준 SKU는 Azure 지역 내에서 오류가 없는 위치를 제공하는 가용성 영역을 지원합니다.The Event Hubs Standard SKU supports Availability Zones, providing fault-isolated locations within an Azure region.

참고

Azure Event Hubs 표준에 대한 가용성 영역 지원은 가용성 영역이 있는 Azure 지역에서만 사용할 수 있습니다.The Availability Zones support for Azure Event Hubs Standard is only available in Azure regions where availability zones are present.

Azure Portal을 사용하여 새로운 네임스페이스에서만 가용성 영역을 사용하도록 설정할 수 있습니다.You can enable Availability Zones on new namespaces only, using the Azure portal. Event Hubs에서는 기존 네임스페이스의 마이그레이션을 지원하지 않습니다.Event Hubs doesn't support migration of existing namespaces. 네임스페이스를 사용하도록 설정한 후에는 영역 중복성을 사용하지 않도록 설정할 수 없습니다.You can't disable zone redundancy after enabling it on your namespace.

가용성 영역을 사용 하는 경우 메타 데이터와 데이터 (이벤트)가 모두 가용성 영역의 데이터 센터에 복제 됩니다.When you use availability zones, both metadata and data (events) are replicated across data centers in the availability zone.

3

프라이빗 엔드포인트Private endpoints

이 섹션에서는 개인 끝점을 사용 하는 네임 스페이스에서 지역 재해 복구를 사용할 때 추가로 고려해 야 할 사항에 대해 설명 합니다.This section provides more considerations when using Geo-disaster recovery with namespaces that use private endpoints. 일반적인 Event Hubs에서 전용 엔드포인트를 사용하는 방법에 대한 자세한 내용은 프라이빗 엔드포인트 구성을 참조하세요.To learn about using private endpoints with Event Hubs in general, see Configure private endpoints.

새 페어링New pairings

프라이빗 엔드포인트가 없는 보조 네임스페이스와 프라이빗 엔드포인트가 있는 기본 네임스페이스 간에 페어링을 만들려고 시도하면 페어링이 실패합니다.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. 기본 및 보조 네임스페이스에 모두 프라이빗 엔드포인트가 있는 경우에만 페어링이 성공합니다.The pairing will succeed only if both primary and secondary namespaces have private endpoints. 기본 및 보조 네임스페이스와 프라이빗 엔드포인트가 생성되는 가상 네트워크에서 동일한 구성을 사용하는 것이 좋습니다.We recommend that you use same configurations on the primary and secondary namespaces and on virtual networks in which private endpoints are created.

참고

프라이빗 엔드포인트가 있는 기본 네임스페이스를 보조 네임스페이스와 페어링하려고 시도하면 유효성 검사 프로세스에서는 보조 네임스페이스에 프라이빗 엔드포인트가 있는지만 검사합니다.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. 엔드포인트가 장애 조치(failover) 후 작동하는지 또는 작동할지는 검사하지 않습니다.It doesn't check whether the endpoint works or will work after failover. 장애 조치 후 프라이빗 엔드포인트가 있는 보조 네임스페이스가 예상대로 작동하는지 검사하는 것은 사용자의 책임입니다.It's your responsibility to ensure that the secondary namespace with private endpoint will work as expected after failover.

기본 및 보조 네임스페이스에서 프라이빗 엔드포인트 구성이 동일한지 테스트하려면 요청(예: Event Hub 가져오기)을 가상 네트워크 외부에서 보조 네임스페이스로 전송하고 서비스에서 오류 메시지가 수신되는지 확인합니다.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.

기존 페어링Existing pairings

기본 네임스페이스와 보조 네임스페이스 간의 페어링이 이미 있는 경우에는 기본 네임스페이스에서 프라이빗 엔드포인트 만들기가 실패합니다.If pairing between primary and secondary namespace already exists, private endpoint creation on the primary namespace will fail. 이 문제를 해결하려면 먼저 보조 네임스페이스에 프라이빗 엔드포인트를 만든 다음, 기본 네임스페이스에 프라이빗 엔드포인트를 만듭니다.To resolve, create a private endpoint on the secondary namespace first and then create one for the primary namespace.

참고

보조 네임스페이스에는 읽기 전용 액세스가 허용되며 프라이빗 엔드포인트 구성에 대한 업데이트가 허용됩니다.While we allow read-only access to the secondary namespace, updates to the private endpoint configurations are permitted.

애플리케이션 및 Event Hubs 네임스페이스에 대한 재해 복구 구성을 만들 때 애플리케이션의 기본 및 보조 인스턴스를 모두 호스트하는 가상 네트워크에 대하여 기본 및 보조 Event Hubs 네임스페이스 둘 다에 대한 프라이빗 엔드포인트를 만들어야 합니다.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.

두 개의 가상 네트워크인 VNET-1, VNET-2 및 기본 및 보조 네임스페이스인 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. 다음 단계를 수행해야 합니다.You need to do the following steps:

  • EventHubs-Namespace1-Primary에서 VNET-1과 VNET-2의 서브넷을 사용하는 두 개의 프라이빗 엔드포인트를 만듭니다.On EventHubs-Namespace1-Primary, create two private endpoints that use subnets from VNET-1 and VNET-2
  • EventHubs-Namespace2-Secondary에서 VNET-1과 VNET-2의 동일한 서브넷을 사용하는 두 개의 프라이빗 엔드포인트를 만듭니다.On EventHubs-Namespace2-Secondary, create two private endpoints that use the same subnets from VNET-1 and VNET-2

프라이빗 엔드포인트 및 가상 네트워크

이 방법의 장점은 장애 조치(failover)가 Event Hubs 네임스페이스와 무관한 애플리케이션 계층에서 발생할 수 있다는 것입니다.Advantage of this approach is that failover can happen at the application layer independent of Event Hubs namespace. 다음과 같은 시나리오를 고려해 보세요.Consider the following scenarios:

애플리케이션 전용 장애 조치: 여기서 애플리케이션은 VNET-1에는 없지만 VNET-2로 이동합니다.Application-only failover: Here, the application won't exist in VNET-1 but will move to VNET-2. 두 프라이빗 엔드포인트 모두 기본 및 보조 네임스페이스에 대해 VNET-1과 VNET-2 모두에 구성되어 있으므로 애플리케이션은 작동합니다.As both private endpoints are configured on both VNET-1 and VNET-2 for both primary and secondary namespaces, the application will just work.

Event Hubs 네임스페이스 전용 장애 조치: 여기서도 역시 두 프라이빗 엔드포인트는 기본 및 보조 네임스페이스에 대해 두 가상 네트워크 모두에서 구성되므로 애플리케이션은 작동합니다.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.

참고

가상 네트워크의 지리적 재해 복구에 대한 지침은 Virtual Network - 비즈니스 연속성을 참조하세요.For guidance on geo-disaster recovery of a virtual network, see Virtual Network - Business Continuity.

다음 단계Next steps

  • GitHub의 샘플은 지리적 페어링을 만들고 재해 복구 시나리오에 대한 장애 조치(Failover)를 시작하는 간단한 워크플로를 진행합니다.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 참조에서는 지리적 재해 복구 구성을 수행하기 위한 API에 대해 설명합니다.The REST API reference describes APIs for performing the Geo-disaster recovery configuration.

Event Hubs에 대한 자세한 내용은 다음 링크를 방문하세요.For more information about Event Hubs, visit the following links: