합병 및 인수는 흔하지만, 저는 아키텍트, 영업 및 계정 팀이 두 조직이 모두 Azure를 사용할 때 Azure 구독의 이동이 어떻게 이루어지는지에 대한 질문을 받을 때 어려움을 겪는 것을 보았습니다. 이는 동일한 Azure AD 테넌트 내에서 또는 Azure AD 테넌트 이동 간에 발생할 수 있습니다. 왜냐하면 구독이 이미 적용된 후에 우리 중 몇몇이 때때로 관련되기 때문입니다.
다양한 유형의 마이그레이션을 살펴보기 전에 Microsoft Enterprise Agreement 계층 구조를 간략히 살펴보겠습니다.
조직이 EA를 구매하면 구독을 만들고 Azure 리소스 배포를 시작할 수 있습니다. 고객은 파트너를 통해 CSP를 구매할 수 있는데, 이는 고객과 파트너 간의 관계이며 CSP가 리소스를 제어하고 배포 및 모든 기술적 문제에 대해 지원합니다. CSP 파트너는 고객을 대신하여 티켓을 만듭니다.
아래 계층 구조는 Enterprise Agreement입니다. 첫 번째 수준은 등록이고, 그 아래에서 고객은 배포를 분리하기 위해 여러 부서를 만들 수 있습니다. 부서는 하나일 수도 있고 여러 개일 수도 있습니다. 부서 아래에서 계정을 만듭니다. 계정은 모든 구독이 생성되는 컨테이너입니다. 기본적으로 계정 생성 프로세스에서 이메일 주소를 지정할 수 있습니다. 이 사람이 계정을 소유합니다. 계정을 만들 때마다 고유한 이메일 주소를 제공해야 합니다. 동일한 소유자가 있는 두 개의 EA 계정을 가질 수 없습니다.
모범 사례는 Microsoft 계정보다는 직장 및 학교 계정을 제공하는 것입니다. 사람이 조직을 떠날 때를 생각해보세요.😊
아래의 모든 시나리오를 고려해 볼 때, 마이그레이션은 두 가지 주요 유형으로 분류될 수 있습니다.
- 비기술적 마이그레이션 : 구독에 있는 리소스에 영향을 주지 않고 백엔드에서 발생하며 다운타임이 발생하지 않습니다.
- 기술적 마이그레이션 : 구독에 있는 전체 리소스를 평가하고 리소스를 다른 구독으로 이동하는 것이 가능한지 확인하는 작업이 포함됩니다. 각 리소스를 개별적으로 평가하고 한 리소스의 다른 리소스에 대한 종속성을 확인합니다.
시나리오:
아래에 언급된 마이그레이션 유형 개요:
- 두 개의 다른 EA 등록
1a 사이를 이동합니다. 첫 번째 단계
1b. 두 번째 단계 - 동일한 EA 등록 내 EA 계정 간 구독 이동
- 한 테넌트에서 다른 테넌트로 Azure 구독 이동
3a. 접근 방식 1(디렉토리 변경
) 3b. 접근 방식 2(다시 만들기)
3c. 접근 방식 3(ASR) - CSP에서 EA로 구독 이동
- PAYG 구독을 EA로 이동
- MCA-Enterprise 구독을 EA로 이동
1. 두 개의 다른 EA 등록 간 이동:
이 시나리오에서 고객은 활성 EA 등록을 보유하고 있으며, 이 고객은 활성 EA 등록이 있는 Azure에 있는 다른 엔터티 B를 인수했습니다. 둘 다 Azure에 있으므로 고객 A는 엔터티 B의 Azure 배포를 인수하고 싶어할 것입니다. 고객은 Microsoft에 단일 파트너를 통해서만 지불하고 싶어할 것입니다. 따라서 이러한 이동 필요성이 발생합니다. 또한 두 번째 필요성은 여러 Azure AD 테넌트와 리소스가 단일 Azure AD 테넌트로 병합되어 고객이 단일 랜딩 존을 통해 리소스를 관리할 수 있기 때문일 수 있습니다.
제 생각에는 합병을 두 단계로 나누는 것이 좋습니다. 첫 번째는 구독(청구 전용)의 이동이고 두 번째 단계는 테넌트의 리소스 합병입니다.
1a. 첫 번째 단계 :
(유형: 비기술적 마이그레이션) 한 등록에서 다른 등록으로 구독을 이동하는 것은 백엔드에서 발생할 수 있습니다. 이 백엔드 이동은 구독 리소스에 다운타임을 발생시키지 않습니다. 소스 구독이 이동할 대상 EA 계정을 손쉽게 사용할 수 있어야 합니다. 고객은 MS 구독 관리 팀에 지원 사례를 제기하고 이메일을 통해 필요한 승인을 제공해야 합니다. 테넌트가 동일하게 유지될 것이라고 지원 엔지니어에게 알려야 합니다.
참고: 계정 소유자에 사용되는 이메일 주소는 구독이 연결된 테넌트였습니다. 예를 들어, 이메일이 Aquib.qureshi@contoso.com인 경우 이 계정에서 생성되는 모든 구독은 contoso.com Azure AD 테넌트에 매핑됩니다.
따라서 대상 Azure AD 테넌트에서 리소스를 이동하지 않으려는 경우 지원 팀에 알려야 합니다. 이는 중요한 이유인데, 구독의 Azure AD 테넌트가 RBAC를 변경하면 구독의 Azure AD 앱 등록 및 많은 Azure AD 종속 서비스가 영향을 받을 수 있기 때문입니다.
하나의 Azure EA Enrollment에 두 개 이상의 Azure AD 테넌트가 있을 수 있다고 생각하십니까? 답은 '예'입니다. Enrollment에는 테넌트와 관련된 제한이 없습니다. 하나의 Enrollment에 여러 EA 계정이 있을 수 있으며 각 계정에는 자체 Azure AD 테넌트가 있을 수 있습니다. (다만 여러 디렉터리를 관리하기 쉽지 않으므로 선호되지는 않습니다.) 우리 시나리오에서 Entity B에는 자체 Azure AD 테넌트가 있고 Company A에도 Azure AD 테넌트가 있으며 이동 후 둘 다 단일 Azure AD Enrollment에 있습니다.
테넌트 외에 염두에 두어야 할 또 다른 사항은 소스 등록에서 구매한 예약 인스턴스입니다. 통화 A를 사용하는 RI가 있는 구독을 이전하고 대상 EA 등록이 다른 통화 B로 구매된 경우 대상 EA 등록은 동시에 여러 통화로 청구될 수 없으므로 RI가 자동으로 취소됩니다.
1b. 두 번째 단계 :
(유형:technicalMigration) 단일 Azure AD 테넌트에서 리소스 병합. 이 단계는 청구가 마이그레이션되면 실행됩니다. 언급했듯이, 이것은 각 리소스를 평가해야 하는 기술적 마이그레이션입니다. 테넌트 변경은 여러 가지 다른 방법으로 처리할 수 있습니다. 3번 항목에서 자세히 설명하겠습니다.
2. 동일한 EA 등록 내 EA 계정 간 구독 이동:
(유형: 비기술 마이그레이션) 이 시나리오는 한 EA 계정 소유자가 사임하고 모든 구독을 인수하여 다른 EA 계정으로 이동하려는 경우 발생할 수 있습니다. 이 단계는 쉽고 Azure Portal을 통해 수행할 수 있으며 MS에 지원 사례를 제기할 필요가 없습니다.
포털에 표시되는 대상 Azure AD 테넌트 확인 표시와 동일하며, 대상 Azure AD로 구독을 전송하지 않으려면 해당 표시를 선택 취소할 수 있습니다.
3. 한 테넌트에서 다른 테넌트로 Azure 구독 이동:
(유형:TechnicalMigration) 테넌트를 변경해야 하는 이유는 여러 가지가 있는데, 첫째, 고객이 방화벽, WAF 및 네트워크 연결과 함께 랜딩 존을 배포했고, 고객 A Azure 배포에서 BU를 다른 관리 그룹으로 분리하여 Azure Policy를 구성했기 때문입니다. 엔터티 B가 병합됨에 따라 고객 A의 IT 팀은 현재 Azure 배포를 관리하는 것과 비슷한 방식으로 엔터티의 Azure 리소스를 관리하고자 합니다. 하지만 리소스를 단일 Azure AD 테넌트로 바로 병합해서는 안 됩니다. 테넌트를 공존시키고 더 나은 운영을 활용할 수 있는 여러 가지 방법이 있기 때문입니다. 아래에서 몇 가지 방법을 강조하겠습니다.
- Azure AD 테넌트가 두 개 있다는 것은 두 개의 다른 사용자 리포지토리를 의미합니다. 고객 A 사용자가 엔터티 B의 Azure 구독을 관리하고자 할 때마다 사용자를 게스트로 초대한 다음 해당 게스트 사용자를 기여자 또는 관련 역할로 제공하여 Azure 리소스를 관리할 수 있습니다. 최근에 두 Azure AD 테넌트 간의 사용자 동기화가 출시되어 사용자를 수동으로 초대할 필요가 없고 이를 자동화할 수 있습니다.
- Azure Lighthouse를 사용하면 두 개의 다른 Azure Tenant에서 Azure 배포를 운영적으로 관리할 수 있습니다. 이 주제에 대한 블로그를 작성했습니다.
- 엔티티 B가 허브 앤 스포크 배포 모델을 사용하는 경우 vnet 피어링을 수행하고 방화벽, WAF 등이 있는 고객 A의 허브 네트워크를 활용할 수 있습니다.
Azure AD 테넌트를 병합하고 테넌트와 리소스를 공존시키지 말아야 하는 몇 가지 이유는 다음과 같습니다. 모든 서비스가 멀티 테넌트를 지원하지는 않지만 Entity B의 Azure 배포 환경과 Azure에서 사용하는 서비스에 따라 달라지며 테넌트를 병합해야 할 필요가 있는 경우 계속 진행할 수 있습니다.
한 테넌트에서 다른 테넌트로 리소스를 이동하기로 결정했다고 가정해 보겠습니다.
이전에 언급했듯이 이 단계는 여러 가지 방법으로 실행할 수 있습니다. 리소스의 중요도에 따라 어떤 것을 선택할지 결정하게 하겠습니다.
3a. 접근 방식 1(디렉토리 변경) :
구독을 클릭한 다음 "디렉토리 변경"을 클릭할 수 있습니다. 이전에 언급한 대로 실행하기 전에 RBAC가 재설정되고 관리 ID 지원이 있는 리소스가 영향을 받으며 앱 등록에 Azure AD를 사용하는 서비스가 영향을 받습니다. 따라서 이 단계를 수행하기 전에 모든 유형의 리소스를 하나씩 평가한 다음 실행하세요. 실행하기 전에 영향을 받는 모든 리소스에 대한 솔루션이 있어야 합니다.
아래 Microsoft 문서에서는 영향을 받는 몇 가지 리소스를 간략하게 설명하지만 모든 리소스를 다루고 있지는 않습니다.
모든 구독 유형에서 이 디렉토리 변경 버튼이 활성화되어 있는 것은 아닙니다. CSP 구독을 사용하는 경우 이 옵션은 회색으로 표시됩니다.
고객이 가상 구독을 만든 다음 테스트하려는 리소스 유형을 배포한 다음 디렉터리 변경을 클릭하여 리소스가 작동하는지 또는 실패하는지 확인하는 것을 본 적이 있습니다.
3b. 접근 방식 2(재생성) :
이 옵션은 고객이 가동 중지 시간을 제어하고자 할 때 사용됩니다. 이전 방식과 마찬가지로 더미 구독에서 리소스를 평가하고 때로는 만들어야 하지만 여전히 확신이 부족하고 마이그레이션 중에 문제가 발생하는 경우가 많으며 이동 중에 문제 해결이 필요합니다. 따라서 이러한 상황을 피하기 위해 대상 Azure AD 테넌트에 바인딩된 대상 구독에서 리소스를 병렬로 다시 만든 다음 DR을 수행하는 것처럼 장애 조치를 수행할 수 있습니다. 장애 복구를 수행할 가능성이 높습니다.
3c. 접근 방식 3(ASR) :
이 접근 방식은 많은 사람이 이 방법을 알지 못하기 때문에 덜 채택되고 있으며, 많은 수의 VM 워크로드가 있는 경우에만 사용할 수 있습니다. ASR은 두 개의 다른 테넌트 간에 복제하는 데 사용할 수 있습니다. 소스 구독을 물리적 서버 배포로 간주하고 VNET에 어플라이언스를 배포한 다음 Entity B의 구독에 호스팅된 VM에 에이전트를 푸시합니다. VM을 고객 A의 구독으로 복제할 수 있습니다. 이는 Azure 대 Azure 시나리오의 ASR과 동일하지 않지만 해결 방법입니다.
4. CSP에서 EA로 구독 이동:
(유형:TechnicalMigration) MS 지원은 백엔드에서 구독을 옮길 수 없습니다. 일반적으로 CSP 구독은 CSP 파트너가 만든 다른 테넌트에 있으며 CSP에서 테넌트를 변경할 수 없으므로 유일한 옵션은 리소스를 다시 만들어서 이동하거나 ASR 방식 3을 사용하는 것입니다.
5. PAYG 구독을 EA로 이동:
(유형: 비기술적 마이그레이션) 고객이 신용 카드로 구매한 PAYG 구독. 이 구독은 다운타임 없이 백엔드의 EA 청구에서 가져올 수 있습니다. 하지만 테넌트를 변경하려면 이전 섹션에 언급된 단계를 따라야 합니다.
6. MCA-Enterprise 구독을 EA로 이동:
(유형: 비기술 마이그레이션) MCA가 미래이기 때문에 이 접근 방식은 흔하지 않습니다. 하지만 MS 거버넌스 팀에 요청을 제기하면 MCA-Enterprise에서 EA 등록으로 이동할 수 있습니다. MS 거버넌스 팀에 연결하려면 계정 팀에 연락해야 합니다. 거버넌스 지원 팀에 정당성을 제공해야 하며 그러면 이 이동을 실행할 수 있습니다. 이것은 다운타임 없이 완전히 백엔드 이동입니다.
이것들은 주요 구독 유형이며, 인도에서 흔한 대부분의 유형을 다루었습니다. 위의 내용이 유용하고 원활한 마이그레이션에 도움이 되기를 바랍니다.
동료들이 알려준 유용한 링크 몇 가지를 소개합니다.
- Elan Shudnow : 아래 링크는 같은 테넌트 내에서 한 구독에서 다른 구독으로 리소스를 이동하는 경우 도움이 될 수 있습니다. 리소스 그룹이나 리소스 무버에서 Move 작업을 사용할 수 있습니다. 하지만 리소스가 move 작업을 지원하는지 확인하려면 PowerShell 스크립트 https://github.com/ElanShudnow/AzureCode/tree/main/PowerShell/AzResourceMoveSupport 를 실행하여 확인할 수 있습니다.
- Neha Tiwari : 아래 링크는 기술적 마이그레이션을 수행할 때 도움이 될 것입니다. 리소스 무버나 리소스 그룹에서 이동 작업을 사용하여 기술적 마이그레이션을 수행할 때 실행 중에 명심해야 할 모든 사항은 아래 블로그에 잘 설명되어 있습니다. https://techcommunity.microsoft.com/t5/azure-infrastructure-blog/detailed-csp-to-ea-migration-guidance-and-crucial-considerations/ba-p/3919364
즐거운 학습이 되세요!
'IT이야기 > Azure' 카테고리의 다른 글
| Azure 기본 VM 아웃바운드 액세스 중단: 전환 방법 (0) | 2024.12.31 |
|---|---|
| Traffic Manager와 App Gateway를 사용하여 multiple SAP 앱에 액세스하세요. (1) | 2024.12.31 |
| Azure Private Endpoint 배포를 위한 온프레미스 DNS 변경 (2) | 2024.12.31 |
| Azure VMware 솔루션의 스토리지 유형에 대한 비밀 해제 (0) | 2024.12.31 |
| Azure Firewall을 사용하여 Azure VMware 솔루션 배포 (0) | 2024.12.31 |