깡민쓰~IT Story

• 시나리오 : 최근의 업무에서 고객 중 한 명이 IT 자산의 패치 및 규정 준수 보고를 관리하는 데 따르는 어려움을 설명했습니다. 하이브리드 설정이었고 Azure를 포함한 여러 클라우드에 인프라가 분산되어 있었습니다. Windows가 있었지만 많은 부분이 SUSE 및 RedHat Linux 서버에 있었습니다. 고객은 중앙에서 패치 및 보고를 자동화하기를 원했습니다.
• 해결책 : 제목에서 알 수 있듯이 저희는 그들에게 Azure Update Manager를 도입하라고 요청했습니다. 온프레미스와 멀티 클라우드 에스테이트에 모두 적용되었습니다. 고객은 Azure Monitor를 사용하여 만든 규정 준수 대시보드를 가지고 있으며, 이는 요구 사항에 따라 사용자 지정되었습니다.

Azure 업데이트 관리자란 무엇입니까?

Azure Update Manager는 온프레미스 서버와 GCP, AWS, OCI, Azure와 같은 클라우드 공급자에 호스팅된 서버에 대한 패치를 예약하는 데 사용되는 클라우드 기반 솔루션입니다. Azure Update Manager 자체는 클라우드 서비스이므로 어플라이언스로 설치할 수 없습니다. 이 서비스는 추가 비용 없이 Azure에서 기본적으로 활성화됩니다. 따라서 요새나 방화벽처럼 이 서비스를 배포할 필요가 없습니다. 모든 서버는 확장 기능을 통해 AUM 서비스에 보고합니다. 따라서 기본적으로 후드 아래에는 Azure VM 또는 Azure Arc 지원 VM에 설치된 확장 기능입니다. 맞습니다. Azure Arc 지원 VM입니다. Azure 외부에 호스팅된 VM이 있고 Azure Update Manager를 사용하려면 먼저 해당 서버에서 Arc를 활성화해야 합니다. 그런 다음 AUM을 확장 기능으로 활성화할 수 있습니다.

서버가 AUM에 온보딩되면 AUM 서비스에 규정 준수 상태를 보고하고 Azure Portal에 있는 AUM 콘솔에서 패치를 예약할 수 있습니다. Azure Update Manager의 주요 작업은 다양한 구성에 따라 서버에 패치를 다운로드하도록 지시하는 것입니다. 머신에 패치를 다운로드할 위치를 지시하지 않습니다. 예를 들어 리포지토리 서버를 제공하지 않습니다. VM/서버가 AUM에서 패치를 다운로드하라는 지침을 받으면 머신의 로컬 구성에 따라 패치를 획득합니다. WSUS(Windows Server Update Server)와 같거나 인터넷을 통해 직접 또는 프록시 서버를 통해 패치를 획득합니다. 서버는 패치를 다운로드하기 위해 연결하고 완료되면 최신 규정 준수 상태를 AUM에 보고합니다.

Arc란 무엇입니까?

AUM에 대해 논의하고 심층적으로 살펴보기 전에 Arc에 대해 간략하게 살펴보겠습니다. Arc는 단일 창, 즉 Azure에서 모든 워크로드를 보고 중앙에서 관리할 수 있는 플랫폼을 제공합니다. Azure Monitor, Azure Update Manager, Defender 및 기타 여러 솔루션과 같은 Azure 서비스를 온프레미스 서버에 배포하는 데 도움이 됩니다. 이는 먼저 모든 서버에 Azure 연결된 머신 에이전트를 설치하여 수행됩니다. CMA가 설치되면 머신은 Arc 지원 서버가 됩니다. 여기에서 확장을 통해 원하는 Azure 솔루션을 활성화할 수 있습니다.

Arc-Enabled VM에 배포할 수 있는 확장 프로그램이 많이 있습니다. 아래 링크에 설명되어 있습니다.

https://learn.microsoft.com/en-us/azure/azure-arc/servers/manage-vm-extensions#windows-extensions

Arc Key Vault 확장을 사용하여 온프레미스 서버의 인증서 갱신에 대한 블로그 게시물을 작성했습니다. 아래에서 블로그를 찾을 수 있습니다.

https://www.azuredoctor.com/posts/arc-keyvault/

Windows 서버에서 AUM이 작동하는 방식:

이전에 언급했듯이 AUM은 서버가 패치 업데이트를 수신하고 연결할 리포지토리 서버를 제공하지 않고, 대신 오케스트레이터 역할을 하여 지정한 일정에 따라 서버에 패치를 다운로드하도록 알립니다. 예를 들어, 매월 마지막 날, 패치 화요일 이틀 후, 주간 또는 월간 타임라인 등입니다. 서버가 지침을 받으면 WSUS 리포지토리 또는 Microsoft 업데이트에 연결합니다. 이는 머신에 설정된 구성에 따라 달라집니다.

저는 고객이 데이터센터에 로컬로 WSUS 서버를 두고, Azure와 다른 클라우드 공급자에 WSUS를 두고, Windows 서버가 인터넷을 통해 Microsoft Update에서 직접 패치를 다운로드하지 않고 WSUS를 로컬 저장소로 사용하는 것을 보았습니다. 하지만 WSUS에 의존하고 싶지 않다면 프록시나 방화벽을 통해 Windows 업데이트 URL을 직접 허용 목록에 추가하면 서버가 그에 따라 최신 업데이트를 다운로드합니다.

Linux에서 AUM이 작동하는 방식:

리눅스에서 AUM의 동작은 윈도우 서버와 거의 같습니다. AUM은 리눅스 저장소를 제공하지 않지만 시스템이 구성된 저장소에서 업데이트를 받도록 합니다. AUM의 역할은 일정에 따라 업데이트를 트리거하는 것입니다.

Linux를 사용하는 AUM에는 여러 옵션이 있습니다. Linux 서버가 호스팅되는 위치에 따라 다릅니다.

온프레미스:

Linux 서버가 온프레미스에 호스팅된 경우 로컬 개인 저장소 또는 공개 저장소를 사용하여 OEM에서 최신 업데이트를 다운로드해야 합니다. SUSE 또는 RedHat 서버가 있고 SUSE Manager 또는 RedHat 위성 서버에 대한 라이선스가 있는 경우 이러한 서버는 저장소 역할을 하고 AUM은 규정 준수 확인, 패치 업데이트 일정 및 보고를 위한 오케스트레이터 역할을 합니다. SUSE Manager와 RedHat Satellite는 패치에 사용되며 유료 버전입니다. 신뢰할 수 있고 저렴하다고 생각되는 모든 저장소 서버 타사(3P)를 사용할 수 있습니다.

클라우드의 Linux:

Linux 서버가 Azure, GCP 또는 AWS에 호스팅된 경우. 특히 RedHat 및 SUSE와 같은 공급업체이고 Marketplace에서 라이선스를 구매했거나 Marketplace 이미지에서 배포한 경우 이러한 공급업체는 서버가 최신 업데이트를 다운로드할 수 있는 해당 지역에 로컬로 퍼블릭 클라우드 업데이트 인프라를 제공합니다. VNET 또는 VPC 외부이지만 동일한 지역 내의 퍼블릭 연결이 됩니다.

아래는 각 배포판의 링크와 업데이트 인프라를 제공하는 방식에 대한 설명입니다.

https://www.suse.com/c/accessing-suse-updates-in-aws-when-do-you-need-a-private-repository/

https://www.suse.com/c/accessing-the-public-cloud-update-infrastructure-via-a-proxy/

https://www.suse.com/c/azure-public-cloud-update-infrastructure-101/

https://www.suse.com/c/accessing-the-public-cloud-update-infrastructure-via-a-proxy/

https://learn.microsoft.com/en-us/azure/virtual-machines/workloads/redhat/redhat-rhui?tabs=rhel7

https://access.redhat.com/products/red-hat-update-infrastructure

아래 아키텍처는 Azure Arc와 Public 엔드포인트 및 Azure Private 엔드포인트의 연결을 보여줍니다. Private 엔드포인트를 배치할 위치도 보여줍니다.

아래 아키텍처는 WSUS와 Linux Repo 서버의 배치를 보여줍니다. 멀티 클라우드 설정을 보여줍니다.

이 아키텍처의 Visio 파일 다운로드

Azure Update Manager 비용:

서비스 비용에 대해 논의해 보겠습니다. AUM은 클라우드 서비스입니다. 어플라이언스가 없고 어플라이언스 고가용성 등에 비용을 지불할 필요가 없습니다. 이 모든 것이 서비스에 내장되어 있으므로 이 모든 것을 처리할 필요가 없습니다. Azure Servers용 AUM은 무료입니다. 바로 AUM을 활용할 수 있습니다. Azure Stack HCI 온프레미스에서 호스팅되는 서버가 있는 경우 AUM은 무료입니다. 온프레미스에서 호스팅되는 서버에는 요금이 부과됩니다. 서버당 월 5달러가 청구됩니다. Arc 지원 서버의 AUM은 세 가지 조건에서 무료입니다.

1. Arc를 통해 확장 보안 업데이트를 활성화한 경우
2. Defender for Servers Plan 2를 사용하는 경우
3. Azure Arc가 제공하는 Windows Server Management를 사용하면 활성 소프트웨어 보증이 있는 Windows Server 라이선스나 활성 구독 라이선스인 Windows Server 라이선스를 사용하는 고객은 AUM을 무료로 얻을 수 있습니다.

위 시나리오에 대한 자세한 내용은 아래 링크에서 확인하세요. https://learn.microsoft.com/en-us/azure/update-manager/update-manager-faq#are-there-scenarios-in-which-arc-enabled-server-isnt-charged-for-azure-update-manager

https://techcommunity.microsoft.com/blog/azurearcblog/announce-general-availability-windows-server-management-enabled-by-azure-arc/4303854

이 블로그가 여러분이 AUM을 더 빠르게 배포하고 올바른 아키텍처 패턴을 따르는 데 도움이 되기를 바랍니다.

즐거운 학습이 되세요!

이 블로그는 아직 Azure ESAN 저장소를 탐색하지 않았지만 ESAN과 그 기본 사항에 대해 들어봤지만 워크로드에 어떤 가치를 제공하는지 모르는 사람들을 위한 것입니다. 이 블로그를 읽으면 다음 질문에 답할 수 있는 통찰력을 얻을 수 있습니다.

1. ESAN을 사용해야 하는 이유는 무엇인가요? 디스크 관리 대신 이 서비스를 선택하면 가격상 이점이 있나요? 그리고 얼마나 비용을 절감할 수 있나요?
2. 프로덕션 워크로드에 ESAN을 고려할 수 있나요?
3. 내 워크로드에 ESAN을 배포하기 전에 고려해야 할 제한 사항은 무엇입니까?

ESAN 볼륨을 단계별로 생성하고 VM에 연결하는 방법은 다루지 않습니다. 이는 Microsoft 학습 문서에서 자세히 다룹니다.

기본 정보

시작해 보겠습니다. Azure Elastic SAN(ESAN)은 2022년 10월에 출시되었습니다. ESAN은 VM, AKS 및 AVS를 마운트하는 데 사용할 수 있는 iSCSI LUN을 제공합니다. 2022년 이후로 Elastic SAN에 많은 개선이 있었고 현재 대부분의 Azure 지역에서 이 서비스를 지원합니다.

Elastic SAN이 IOPS와 스토리지를 계산하는 방법 - ESAN을 만들고 기본 단위를 기반으로 1TiB씩 증가하는 총 IOPS와 처리량을 얻습니다. 1TiB의 기본 단위는 5000 IOPS와 200MBps 처리량을 제공합니다. 저렴한 스토리지만 원하는 경우 IOPS/처리량은 제공하지 않고 추가 스토리지만 제공하는 추가 용량 단위를 추가할 수 있습니다.

Elastic SAN의 한 가지 중요한 측면은 Elastic SAN을 생성할 때마다 ESAN의 전체 IOPS와 처리량이 여러 볼륨에서 공유된다는 것입니다.예를 들어, ESAN 20TiB를 생성하면 총 100,000 IOPS와 4000MBps 처리량을 얻게 됩니다.각각 200Gb의 볼륨 두 개를 생성하면 개별적으로 최대 80K IOPS와 1280MBps 처리량까지 확장할 수 있습니다.그러나 Elastic SAN의 부모 Base 단위에서 제공하는 총 IOPS와 처리량을 공유합니다.한 VM이 60K IOPS를 얻고 동시에 두 번째 VM에 50K IOPS가 필요한 경우 두 번째 VM은 40K IOPS만 얻게 되는데, 이는 ESAN의 20TiB에 대한 최대 한도가 100K IOPS이기 때문입니다.
최대 80K IOPS를 얻는 데 필요한 최소 볼륨은 106GiB이고 최대 1280GB/s를 얻으려면 최소 21GiB가 필요합니다.

이제 여러 애플리케이션에 대한 스토리지 요구 사항을 결합하여 단일 Elastic SAN에 넣을 수 있습니다. 비용과 통합 스토리지 이점을 얻을 수 있습니다.
기억해야 할 한 가지는 IOPS와 처리량이 동시에 필요한 모든 중요한 프로덕션 애플리케이션을 단일 ESAN에 넣을 수 없다는 것입니다. 따라서 여러 ESAN 인스턴스에 균등하게 분산해야 합니다. 이는 모든 앱이 동시에 필요한 경우 IOPS/처리량 때문에 ESAN을 해당 한계까지 확장해야 하거나 그렇지 않으면 ESAN이 조절을 시작하기 때문입니다.
200개의 볼륨 그룹을 가질 수 있으며, 하나의 볼륨 그룹은 최대 1000개의 볼륨을 가질 수 있습니다. 따라서 단일 ESAN에 많은 애플리케이션 세트를 모을 수 있습니다.

ESAN 볼륨 데이터는 네트워크를 통해 전송됩니다.

Azure 관리자라면 모든 VM에 디스크 및 네트워크 제한이 할당되어 있다는 사실을 이미 알고 계실 것입니다.VM SKU를 낮추면 제한도 낮아집니다.D4s_v5 크기의 VM에 4TB 프리미엄 SSD 디스크를 연결하는 경우 디스크 IOPS가 7500 IOPS이더라도 이 정도의 IOPS를 사용할 수 없습니다.VM 자체가 최대 6400 IOPS를 지원하기 때문입니다.더 높은 CPU와 메모리가 필요하지 않더라도 VM 크기를 변경하고 더 높은 SKU를 선택해야 합니다.Azure Elastic SAN은 네트워크를 사용하여 저장소에 연결하므로 VM 디스크 제한 제한은 적용되지 않습니다.하지만 이 경우에도 VM 네트워크 제한은 계속 적용됩니다.그러나 VM 네트워크 처리량은 항상 더 높은 편입니다.ESAN에 대한 iSCSI 기반 연결을 실행하는 것과 함께 워크로드에 충분한 네트워크 처리량이 남아 있는지 확인해야 합니다.

아래에서는 IOPS와 처리량을 충족하기 위해 다음으로 사용 가능한 SKU로 이동하는 위와 같은 문제에 직면했다면 관리형 디스크에서 Elastic SAN Volumes로 디스크를 이동하면 얼마나 많은 비용을 절감할 수 있는지 예를 들어 설명하겠습니다.

이제 ESAN이 디스크 스토리지와 비교했을 때 어떻게 배치되는지 비교해 보겠습니다. 또한 지금은 4TiB의 디스크 하나만 고려하겠습니다. ESAN을 고려할 때 일반적으로 더 큰 스토리지 크기의 조합인 Base Unit을 배포하면 모든 볼륨에서 사용할 수 있는 훨씬 더 높은 처리량을 얻을 수 있습니다. 이는 단일 디스크에서는 불가능합니다. 단일 VM에만 연결되어 있고 IOPS를 다른 VM과 공유할 수 없기 때문입니다.
참고: 더 높은 IOPS와 처리량을 제공하는 Performance Plus의 미리보기 기능은 고려하지 않았습니다. 자세한 내용은 아래 링크에서 확인하세요.

https://learn.microsoft.com/en-us/azure/virtual-machines/disks-enable-performance?tabs=azure-powershell

ESAN 대 프리미엄 SSD

Azure Premium SSD인 프로덕션 등급 디스크로 시작하겠습니다. 프로덕션 워크로드에 가장 많이 사용되는 디스크 중 하나입니다.
보시다시피 7500 IOPS와 250MB/s 처리량을 제공하는 4TB 디스크가 있었습니다. 이를 충족하기 위해 Elastic SAN의 2TiB 기본 단위와 용량 단위의 나머지 2TiB를 가져와야 했습니다.
디스크 하나만 있으면 월 266.40달러를 절약할 수 있습니다.

ESAN 대 표준 SSD

제 경험상, 고객은 종종 비생산적 작업 부하에 표준 SSD를 사용합니다. 처리량과 IOPS가 꽤 낮지만, 비생산적 작업 부하에 대한 저렴한 대안이 될 수 있으며, 여기서는 성능을 희생하여 비용을 절감할 수 있습니다.
그러나 이제 표준 SSD를 프리미엄인 Elastic SAN과 비교하면 아래 표에서 볼 수 있듯이 훨씬 더 높은 IOPS와 처리량을 얻을 수 있고 여전히 비용을 절감할 수 있습니다.
ESAN을 사용하면 5K IOPS를 얻고 표준 SSD는 4TiB의 작업 부하에서 500 IOPS를 제공합니다.
여전히 이러한 성능 향상으로 월 약 29.28달러의 비용을 절감할 수 있습니다.

ESAN 대 프리미엄 SSD v2

위의 프리미엄 v1 디스크 예를 살펴보면, 왜 프리미엄 SSD v2와 비교하지 않는지 궁금할 수 있습니다. 프리미엄 SSD v2는 훨씬 더 나은 성능을 제공하고 프리미엄 SSD v1 디스크보다 비용이 저렴합니다. 그럼, 여기 있습니다. 프리미엄 SSD v2의 기본 가격으로 3000 IOPS와 125MB/s 처리량을 얻을 수 있습니다. 이것을 ESAN과 비교하면 ESAN의 기본 단위 1개와 용량 단위 3TiB를 얻을 수 있으며, 한 달에 약 70.90달러를 절약할 수 있습니다. 이 시나리오에는 몇 가지 고려 사항이 있습니다.

1. ESAN은 지역 또는 지역적으로 배포된 VM에서 사용할 수 있습니다. 그러나 Premium SSDv2는 VM이 ​​영역에 있어야 합니다.
2. VM이 가용성 집합에 있거나 지역적으로 배포된 경우 이 디스크를 사용할 수 없습니다.
3. ESAN은 특정 구역에 배포해야 하지만, VM은 지역 내의 모든 구역에서 연결할 수 있습니다. 더 나은 성능을 얻으려면 VM과 ESAN을 같은 구역에 두는 것이 좋습니다.

AVS 시나리오: ESAN 대 ANF 표준

ESAN은 iSCSI 프로토콜을 통해 VM에 연결된 블록 스토리지입니다. ANF는 NFS 또는 SMB 프로토콜을 통해 사용할 수 있는 NAS입니다.
ESAN은 Azure VMware 솔루션 시나리오에서도 사용할 수 있으므로 ESAN과 ANF를 비교하는 것이 좋습니다. ANF는 AVS 워크로드에도 지원되기 때문입니다.
일반적인 읽기/쓰기 I/O인 8KB IOPS를 고려해 보겠습니다. 데이터베이스가 있는 경우 더 높을 수 있으며 웹 또는 앱 서버인 경우 달성된 IOPS가 증가하거나 감소할 수 있는 기준에 따라 더 낮을 수도 있습니다.
표준 계층인 저렴한 ANF 계층을 고려해 보았습니다.
ESAN을 고려하면 월 271달러의 전반적인 절감 효과를 얻을 수 있습니다.

하지만 강조하고 싶은 몇 가지 고려사항이 있습니다.

1. ESAN과 함께 AVS를 사용하려면 ESAN에 대한 개인 엔드포인트를 배포해야 합니다. 개인 엔드포인트의 가격을 알고 있다면 GB당 인바운드 및 아웃바운드 데이터 전송에 약간의 요금이 부과됩니다. 이는 개인 엔드포인트 가격 페이지에서 확인할 수 있습니다. 따라서 매월 ESAN으로의 데이터 전송에 따라 대역폭 비용이 발생합니다. AVS와 함께 ANF를 배포할 때는 이런 일이 발생하지 않습니다. ANF는 VNET에 배포되므로 관련 데이터 전송 비용을 걱정할 필요가 없습니다.
2. ESAN은 현재 스토리지만 제공하지만 ANF는 AVS와 함께 스토리지 측면에서 성숙한 서비스입니다. ANF 데이터 저장소에 호스팅된 VM에 대한 클라우드 백업 확장을 제공합니다. https://learn.microsoft.com/en-us/azure/azure-vmware/install-cloud-backup-virtual-machines
3. ANF는 Azure의 SAP에서 지원되지만 ESAN은 아직 지원되지 않습니다.

제한 사항 및 고려 사항:

Elastic SAN은 불과 2년 된 서비스이므로 많은 개선 사항이 아직 로드맵에 있습니다. 워크로드에 ESAN을 배포하는 것을 고려하기 전에 아래 고려 사항을 염두에 두어야 합니다.

1. Azure 사이트 복구를 통해 VM을 다른 지역으로 복제하는 경우 VM에 연결된 ESAN 볼륨은 지원되지 않습니다.
2. Azure Backup을 통한 ESAN Volume 백업은 현재 GA가 아닙니다. 현재로서는 공개 미리보기에서 사용할 수 없습니다.
3. 백업은 미리보기에 있는 볼륨 스냅샷을 통해 사용할 수 있으며, 이는 ESAN 기능입니다. 이러한 백업 및 DR 기능은 Azure Marketplace 지원 어플라이언스를 통해 백업 도구를 사용하는 경우 타사를 통해 달성할 수 있습니다.
4. Azure VM의 SAP는 현재 ESAN에서 지원되지 않으며, Azure Managed Disk 및 ANF에서만 지원됩니다.
5. 일반 디스크의 스냅샷을 찍은 다음 이를 통해 ESAN 볼륨을 만들 수 있습니다. 이는 미리보기 상태이며 ESAN 볼륨으로 이동하는 데 사용할 수 있습니다.
6. DC 마이그레이션을 평가하고 크기를 조정하는 데 Azure Migrate를 사용하는 경우 해당 도구는 현재 마이그레이션뿐 아니라 평가 대상으로도 관리형 디스크만 지원합니다.
   https://learn.microsoft.com/en-us/azure/storage/elastic-san/elastic-san-snapshots?tabs=azure-portal#create-a-volume-from-a-managed-disk-snapshot

위의 비교와 설명이 ESAN이 귀하의 배포에 더 적합한지 확인하고 비용 절감을 달성하는 데 도움이 되기를 바랍니다.

즐거운 학습이 되세요!

• 시나리오 : 고객이 하나의 Enterprise 계약 등록을 했고, 그 등록 내에 두 개의 회사를 두고 싶어하는 시나리오를 여러 번 접했습니다. 이 회사들은 같은 모회사에 속해 있지만, IT 인프라와 정책이 다르기 때문에 별도의 Entra Tenants(Azure AD)를 원했습니다. 하지만 청구 파트너를 통해 서명된 단일 Enterprise 계약 등록을 공유하고 싶어했습니다.
• 해결책 : 청구 파트너를 통해 Enterprise Agreement(EA)에 서명하면 결코 단일 Entra 테넌트에 묶이지 않습니다. 하나의 EA는 여러 Entra 테넌트와 연결된 여러 Enrollment 계정을 가질 수 있습니다.

이 블로그는 합병, 인수 전환에 참여하는 사전 판매 담당자가 사용할 수 있습니다. 또한 여러 계약 유형 간에 구독을 이동하는 방법을 알고 싶다면 이전 블로그 게시물을 참조할 수 있습니다. https://www.azuredoctor.com/posts/mergers-and-acquisitions-on-azure/

우리는 한 회사가 IT 인프라를 별도로 관리하는 분사 법인에 대해 별도의 테넌트를 만들고 싶어하지만, 모회사와 Azure 청구를 공유하고 싶어하는 시나리오를 살펴볼 것입니다. 이는 두 번째 법인이 더 큰 회사 그룹의 일부이고 좋은 할인을 협상했으며 그것을 공유하고 싶어하기 때문일 수 있습니다.

주의하세요. 이는 임시 설정일 수도 있습니다. 분사된 법인이 청구 파트너와 새로운 Enterprise Agreement를 설정할 수 없는 시나리오를 가정해 보겠습니다. 분사된 법인이 청구 파트너에게 새로운 법인의 이름을 공개하고 싶지 않고 모든 분사 및 IT 인프라 작업을 비밀리에 수행하고 싶어하기 때문입니다.

그들은 새로운 Entra 테넌트에서 Azure 구독을 설정하고 IT 설정 작업을 할 수 있습니다. 나중에 공식 이름과 등록 작업이 완료되면 새로운 Enterprise Agreement를 구매하고 새로운 EA에서 구독을 새로운 Enterprise Enrollment로 옮길 수 있습니다. 이는 다운타임 없이 Azure 서비스를 재배포하지 않고 완전히 백엔드 이동이 될 수 있습니다. 구독 이동에 대한 자세한 내용은 위에 언급된 블로그를 참조하십시오.

Entra Tenant 생성

고객들 사이에서 제가 발견한 오해 중 하나는 Entra 테넌트는 파트너를 통해 계약을 체결한 후에만 생성될 수 있다는 것입니다. 하지만 실제로 고객은 여러 테넌트를 생성할 수 있습니다. 그리고 테넌트가 생성되면 사용자 ID를 사용하여 등록 계정을 생성할 수 있으므로 구독이 생성될 때마다 사용자 ID의 새 Entra 테넌트에 연결됩니다.

이것이 어떻게 달성될 수 있는지 살펴보겠습니다.

먼저 portal.azure.com을 탐색하고 Entra ID(이전 Azure Active Directory)를 검색합니다.

테넌트 관리를 클릭하면 아래 창이 열리고, 거기에 액세스 가능한 모든 디렉터리가 표시됩니다.

B2C가 아닌 Entra ID를 선택하세요.

이 단계에서는 새 조직의 이름과 새 Entra Tenant를 지정해야 합니다.

goto users로 가서 새로 만든 Entra Tenant에서 사용자 계정을 만듭니다. 이제 Entra Tenant와 사용자를 성공적으로 만들었으므로 다음 단계로 진행할 수 있습니다.

등록 계정 생성

엔터프라이즈 등록에서 여러 등록 계정을 만들 수 있습니다. 기본적으로 등록 계정에서 구독이 생성되면 등록 계정 소유자의 Entra ID와 연결됩니다.

계속해서 등록 계정을 만들어 보겠습니다. 등록 계정을 만들려면 등록에 대한 Enterprise 관리자 역할이 있어야 합니다.

Azure Portal에 로그인하고 Cost Management + Billing으로 이동합니다. 그리고 Enterprise 등록을 선택합니다.

계정을 클릭하면 모든 등록 계정이 열립니다.

참고 사항: 아래 단계를 실행하기 전에 엔터프라이즈 계약의 권한 수준을 직장 또는 학교 교차 테넌트로 변경해야 합니다.

https://learn.microsoft.com/en-us/azure/cost-management-billing/manage/direct-ea-administration#view-and-manage-enrollment-policies

추가를 클릭하고 계정 소유자 이메일을 지정하세요. 이것은 새로 만든 entra 테넌트에 있는 entra 사용자 ID입니다.

이제 두 개의 다른 Entra 테넌트에 두 개의 등록 계정이 있습니다. 등록 계정에서 구독을 생성할 때마다 해당 구독은 새 Entra 테넌트에 연결됩니다.

Enterprise Agreement는 곧 종료되고 고객은 MCA로 전환합니다. MCA에서 동일한 것을 달성하는 방법에 대한 블로그를 곧 쓸 것입니다. 그리고 네, MCA-E에서도 동일한 것이 가능하다는 것을 보았습니다.

콘텐츠 검증을 도와준 Darshit Shah 에게 특별 감사드립니다 .

이 블로그가 분사 시 적절한 기업 계약과 세입자 협회를 설계하는 데 도움이 되기를 바랍니다.

즐거운 학습이 되세요!

기본 인터넷 접속 서비스 종료에 대한 공지를 읽어보셨을 수도 있지만, 아직 읽어보지 않으셨다면 여기에서 읽어보시기 바랍니다.

https://azure.microsoft.com/en-us/updates/default-outbound-access-for-vms-in-azure-will-be-retired-transition-to-a-new-method-of-internet- 입장/

따라서 2025년 9월 30일 이후에는 새로 만든 Azure VM에서 기본 인터넷 액세스가 작동하지 않습니다. 영향을 알고 있는 고객은 이미 워크로드를 위해 인터넷에 접속하기 위해 명시적 아웃바운드 방식으로 전환하기 시작했습니다. 이 변경 사항의 내용, 영향 및 사용할 수 있는 솔루션에 대해 여전히 확신이 서지 않는다면 이 블로그가 도움이 될 것입니다.

• 시나리오 : VNET에서 실행되는 VM이 ​​여러 개 있습니다. 서브넷에 할당된 사용자 정의 경로가 없고 인터넷으로 0.0.0.0/0 트래픽을 보내는 경로도 없습니다. 이 시나리오에서 VM이 인터넷에 연결하려고 하면 여전히 가능합니다. (NSG에 인터넷 바운드 차단 규칙이 없는 경우) VM의 인터넷은 Azure에서 제공하는 동적 IP를 사용합니다. 이는 새로 만든 VM에 대해 2025년 9월 30일에 작동이 중단되며 기존 VM에는 영향을 미치지 않습니다.
• 저는 IP를 제어하지 않고 기본적으로 인터넷 아웃바운드를 하는 것은 어차피 위험한 시나리오라고 생각합니다. 따라서 아웃바운드 인터넷 연결에 대한 일관된 동작을 위해 아래 접근 방식을 사용하는 것이 좋습니다.
• 해결 방법 : Azure에서 제공하는 동적 공용 IP에 의존하는 대신 아래 옵션을 사용하여 명시적 아웃바운드 인터넷 통신으로 전환할 수 있습니다.
  • NAT 게이트웨이
  • Azure 방화벽 / NGFW
  • 인스턴스 레벨 공용 IP
  • 로드 밸런서 - 아웃바운드 규칙

Azure NAT 게이트웨이

이것은 Microsoft에서 가장 간단하고 권장하는 옵션입니다. 이 프로세스는 NAT 게이트웨이를 배포하는 것입니다. NAT GW에는 VNET이 필요하지 않습니다. 이를 최소한 하나의 서브넷에 연결하여 해당 서브넷의 아웃바운드 트래픽이 NAT 게이트웨이 서비스를 통해 이동하도록 해야 합니다. NAT 게이트웨이는 사용자가 제어하는 ​​정적 공용 IP 또는 정적 공용 IP 접두사를 갖습니다.

Azure 방화벽 / NGFW

또 다른 선호되는 옵션은 허브 앤 스포크 아키텍처 패턴을 사용하는 것입니다. 여기서 허브 네트워크에 Azure Firewall을 배포합니다. 그리고 모든 스포크는 스포크로 작동하는 워크로드 VNET이 됩니다. 워크로드 VNET에 사용자 정의 경로가 있어 인터넷 트래픽(0.0.0.0/0)을 Azure Firewall로 가리킵니다. 최적화된 비용을 위해 비용 효율성을 제공하는 Azure Firewall의 기본 SKU 또는 표준 SKU를 배포할 수 있습니다.

다음은 Microsoft 문서에서 발췌한 허브 앤 스포크 아키텍처의 예입니다.

마찬가지로 Palo Alto, Fotigate, checkpoint 등과 같은 타사 NGFW 장치를 Hub 가상 네트워크에 둘 수 있습니다. 이러한 장치는 방화벽을 수용하고 모든 인터넷 아웃바운드 트래픽을 방화벽으로 향하게 합니다.

인스턴스 수준 공용 IP 주소

VM에 직접 공용 IP 주소를 할당할 수 있습니다. 이 접근 방식은 인스턴스 수준 공용 IP 주소로 알려져 있으며, 명시적 인터넷 아웃바운드 연결을 제공합니다. 이는 주로 Azure에서 NVA 및 NGFW 배포에 사용됩니다. 또는 DMZ 워크로드에 사용할 수 있습니다. NIC로 이동한 다음 ipconfig, -> 공용 IP 주소 할당으로 이동합니다. 이 옵션은 가장 선호되지 않는 접근 방식이며 환경에 공용 IP가 너무 많으면 노출 위험이 증가하므로 일반 워크로드에는 권장되지 않습니다.

로드 밸런서 - 아웃바운드 규칙

이 상황을 처리하는 또 다른 방법은 표준 로드 밸런서를 만든 다음 아웃바운드 규칙을 만드는 것입니다. 아웃바운드 규칙 없이 인바운드 공용 IP로만 표준 로드 밸런서를 만들면 인터넷이 작동하지 않습니다. 아웃바운드 규칙을 명시적으로 만들고 인터넷 액세스가 작동하도록 프로토콜과 SNAT 포트 수를 지정해야 합니다.

모든 작업 부하에 로드 밸런서를 사용할 수는 없지만 표준 LB와 이미 연결된 DMZ에 웹 서버가 있는 경우 아웃바운드 규칙 방식을 사용할 수 있습니다.

위의 접근 방식이 Azure에서 네트워크 아키텍처에 대한 정보에 입각한 결정을 내리고 2025년 9월 마감일 전에 필요한 조정을 수행하여 중단을 방지하는 데 도움이 되기를 바랍니다.

즐겁게 학습하세요!

이 블로그에서는 Traffic Manager와 Application Gateway를 사용하여 단일 FQDN이지만 다른 포트를 사용하여 여러 SAP 애플리케이션에 액세스하는 방법을 보여드리겠습니다. 이는 프록시 역할을 하는 웹 디스패처 뒤에 여러 SAP 서버가 있는 SAP 고객에게 일반적인 시나리오입니다. Traffic Manager와 Application Gateway를 사용하면 SAP 애플리케이션에 대한 고가용성, 부하 분산 및 URL 라우팅을 달성할 수 있습니다. 또한 다른 포트에서 다른 SAP 애플리케이션에 액세스하는 데 동일한 FQDN을 사용하여 최종 사용자 경험을 간소화할 수 있습니다. 또한 재해나 DR Drill이 발생하는 경우 수동 개입 없이 사용자가 DR 지역으로 원활하게 리디렉션되어야 합니다.

이 시나리오를 설명하기 위해 Windows Server 2019와 IIS를 실행하는 Azure VM을 백엔드 서버로 사용하겠습니다(웹 디스패처라고 가정).한 VM은 포트 8443에서 S4 애플리케이션을 호스팅하고 동일한 VM은 포트 4443에서 EWM 애플리케이션을 호스팅합니다.두 웹사이트 모두 DNS에 등록된 동일한 호스트 이름 webdisp.azurequreshi.com에서 접속할 수 있습니다.또한 각 지역에 하나씩 두 개의 Application Gateway를 사용합니다.마지막으로 Traffic Manager 프로필을 사용하여 우선 순위 라우팅 방법에 따라 두 Application Gateway에 트래픽을 분산합니다.따라서 요청은 DC에만 도달합니다.DR Application Gateway에 대한 요청은 DC Application Gateway 상태 프로브가 다운된 후에만 전송됩니다.

따라서 이 시나리오에서 최종 사용자는 s4.azurequreshi.com:8443 또는 ewm.azurequreshi.com:4443과 같은 개별 URL을 사용하여 앱을 열지 않습니다. webdisp.azurequreshi.com:8443을 사용하면 S4 앱이 열립니다. 마찬가지로 webdisp.azurequreshi.com:4443을 사용하면 EWM 앱이 열립니다.

이 글에서는 위의 시나리오를 달성하는 데 도움이 되는 트래픽 관리자와 애플리케이션 게이트웨이의 설정을 공유하겠습니다. 저는 제 웹사이트를 호스팅한 더미 IIS 서버를 사용하고 있지만, 설정에서 이것을 SAP 웹 디스패처로 대체하고 애플리케이션 게이트웨이 뒤에 웹 디스패처를 호스팅할 수 있습니다.

다음 다이어그램은 아키텍처의 개요를 보여줍니다.

그럼, 웹사이트를 호스팅하는 실제 서버부터 시작해 봅시다. 아래는 IIS의 바인딩입니다. 이것은 단지 웹사이트의 데모 설정일 뿐입니다. 실제 SAP 앱은 다를 것입니다. 여기서의 의도는 s4.azurequreshi.com이라는 호스트 이름에서 4443에 호스팅된 웹사이트를 강조하는 것입니다.

마찬가지로, 아래 스크린샷은 다른 웹사이트를 보여줍니다. 동일한 것을 별도의 웹서버에 호스팅할 수도 있습니다.

애플리케이션 게이트웨이 설정:

애플리케이션 게이트웨이의 프런트엔드 IP를 확인해 보겠습니다.

이제 리스너 설정을 살펴보겠습니다.

두 웹사이트를 위한 애플리케이션 게이트웨이의 간단한 멀티 사이트 리스너. 두 리스너의 차이점은 포트입니다. 8443과 4443.

이제 백엔드 설정

유일한 변경 사항은 백엔드에서 내 웹사이트가 s4.azurequreshi.com에 호스팅되기 때문에 호스트 이름만 webdisp.azurequreshi.com 대신 s4.azurequreshi.com으로 변환한다는 것입니다.

2번째 http 설정에서도 동일한 설정을 볼 수 있습니다.

건강 탐침은 이렇게 생겼습니다.

이제 규칙 구성입니다. 아주 간단한 기본 규칙은 조정하지 않습니다.

그리고 백엔드 설정.

지금까지는 단일 IP만 유지했지만, 두 개의 다른 웹사이트에 대해 두 개의 백엔드 풀을 가질 수 있습니다. 하나는 S4용이고 다른 하나는 EWM용입니다. 또한, 애플리케이션 게이트웨이에서 백엔드 풀을 해당 규칙과 연결할 수 있습니다.

여기까지 따라왔다면, 애플리케이션 게이트웨이 URL로 웹사이트를 열 수 있고, 데스크톱에서 호스트 이름을 입력하면 해당 웹사이트로 리디렉션됩니다. 테스트를 위해 호스트 이름 webdisp.azurequreshi.com을 애플리케이션 게이트웨이 IP로 지정합니다.

남인도의 애플리케이션 게이트웨이 설정과 웹사이트 구성을 복제해야 합니다. 웹 서버를 종료하거나 Azure Site Recovery를 통해 복제할 수 있습니다.

위의 설정이 완료되면 Traffic Manager 구성을 진행할 수 있습니다.

트래픽 관리자

이는 능동/수동 DR이므로 트래픽 관리자에서 우선순위 기반 라우팅을 구성해야 합니다.

교통 관리자의 건강 상태를 살펴보세요.

이 설정으로 트래픽 관리자는 트래픽을 DC(인도 중부)로만 보냅니다. 엔드포인트가 저하되면 트래픽 관리자가 클라이언트에 DR IP 주소를 제공합니다.

마지막 단계는 URL의 CNAME을 트래픽 관리자로 설정하는 것입니다. nslookup을 실행하면 다음을 찾을 수 있습니다.

결과

웹사이트가 열리는 방식은 다음과 같습니다. 이는 SAP S4와 EWM의 구체적인 스크린샷은 아니지만 이 앱 게이트웨이와 트래픽 관리자 설정은 동일합니다.

작업을 검토하고 이 블로그 게시물을 쓰는 데 영감을 준 요구 사항을 공유해 주신 Nishant Roy에게 감사드립니다.

즐거운 학습이 되세요!

합병 및 인수는 흔하지만, 저는 아키텍트, 영업 및 계정 팀이 두 조직이 모두 Azure를 사용할 때 Azure 구독의 이동이 어떻게 이루어지는지에 대한 질문을 받을 때 어려움을 겪는 것을 보았습니다. 이는 동일한 Azure AD 테넌트 내에서 또는 Azure AD 테넌트 이동 간에 발생할 수 있습니다. 왜냐하면 구독이 이미 적용된 후에 우리 중 몇몇이 때때로 관련되기 때문입니다.

다양한 유형의 마이그레이션을 살펴보기 전에 Microsoft Enterprise Agreement 계층 구조를 간략히 살펴보겠습니다.

조직이 EA를 구매하면 구독을 만들고 Azure 리소스 배포를 시작할 수 있습니다. 고객은 파트너를 통해 CSP를 구매할 수 있는데, 이는 고객과 파트너 간의 관계이며 CSP가 리소스를 제어하고 배포 및 모든 기술적 문제에 대해 지원합니다. CSP 파트너는 고객을 대신하여 티켓을 만듭니다.

아래 계층 구조는 Enterprise Agreement입니다. 첫 번째 수준은 등록이고, 그 아래에서 고객은 배포를 분리하기 위해 여러 부서를 만들 수 있습니다. 부서는 하나일 수도 있고 여러 개일 수도 있습니다. 부서 아래에서 계정을 만듭니다. 계정은 모든 구독이 생성되는 컨테이너입니다. 기본적으로 계정 생성 프로세스에서 이메일 주소를 지정할 수 있습니다. 이 사람이 계정을 소유합니다. 계정을 만들 때마다 고유한 이메일 주소를 제공해야 합니다. 동일한 소유자가 있는 두 개의 EA 계정을 가질 수 없습니다.

모범 사례는 Microsoft 계정보다는 직장 및 학교 계정을 제공하는 것입니다. 사람이 조직을 떠날 때를 생각해보세요.😊

아래의 모든 시나리오를 고려해 볼 때, 마이그레이션은 두 가지 주요 유형으로 분류될 수 있습니다.

• 비기술적 마이그레이션 : 구독에 있는 리소스에 영향을 주지 않고 백엔드에서 발생하며 다운타임이 발생하지 않습니다.
• 기술적 마이그레이션 : 구독에 있는 전체 리소스를 평가하고 리소스를 다른 구독으로 이동하는 것이 가능한지 확인하는 작업이 포함됩니다. 각 리소스를 개별적으로 평가하고 한 리소스의 다른 리소스에 대한 종속성을 확인합니다.

시나리오:

아래에 언급된 마이그레이션 유형 개요:

1. 두 개의 다른 EA 등록
   1a 사이를 이동합니다. 첫 번째 단계
   1b. 두 번째 단계
2. 동일한 EA 등록 내 EA 계정 간 구독 이동
3. 한 테넌트에서 다른 테넌트로 Azure 구독 이동
   3a. 접근 방식 1(디렉토리 변경
   ) 3b. 접근 방식 2(다시 만들기)
   3c. 접근 방식 3(ASR)
4. CSP에서 EA로 구독 이동
5. PAYG 구독을 EA로 이동
6. 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 문서에서는 영향을 받는 몇 가지 리소스를 간략하게 설명하지만 모든 리소스를 다루고 있지는 않습니다.

https://learn.microsoft.com/en-us/azure/role-based-access-controltransfer-subscription#understand-the-impact-of-transferring-a-subscription

모든 구독 유형에서 이 디렉토리 변경 버튼이 활성화되어 있는 것은 아닙니다. 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

즐거운 학습이 되세요!

• 시나리오 : 고객이 온프레미스 네트워크에서 개인 엔드포인트에 연결하려는 개인 엔드포인트 시나리오에서 먼저 FQDN을 IP 주소로 확인해야 합니다. 일반적으로 구현 파트너가 PaaS 서비스의 FQDN으로 조건부 포워더를 만든 다음 Azure에 호스팅된 DNS 서버의 개인 IP 주소를 가리키는 것을 보았습니다. 그런 다음 다음 단계는 Azure에 호스팅된 DNS 서버에서 동일한 유형의 조건부 포워더가 개인 엔드포인트 IP를 확인하는 데 도움이 되는 Azure 와이어 서버 IP 168.63.129.16을 가리키는 것입니다.

조직에 2-3개의 DNS 서버가 있는 경우 쉽게 처리할 수 있습니다. 하지만 DNS 서버 수가 15-20개가 넘고 DNS 서버가 온프레미스와 멀티 클라우드의 클라우드에 배치된 기업을 고려하면 다음과 같은 과제에 직면하게 됩니다.

• 과제 : AD와 통합된 온프레미스 DNS 서버에서 고객은 DNS 포워더를 만들고 Azure에 호스팅된 DNS 서버를 가리킵니다. Windows Server Active Directory와 통합된 DNS 서버가 많으므로 고객은 "이 조건부 포워더를 Active Directory에 저장" 확인란을 선택합니다. 그러면 모든 DNS 서버에서 동일한 조건부 포워더를 수동으로 만들 필요가 없습니다. 이렇게 하면 작업이 더 쉬워집니다. 이렇게 하면 Azure의 DNS 서버에도 동일한 조건부 포워더가 생기고 와이어 서버 IP를 가리키는 다른 포워더는 작동하지 않게 됩니다.

• 해결책 : 이 충돌을 해결하는 데는 여러 가지 옵션이 있습니다. 아래에 언급된 대로. 고객이 개인 DNS 리졸버를 선택하는 경우, 이는 Microsoft에서 가장 편리한 접근 방식이며 권장하는 접근 방식입니다. 그러나 많은 사람이 개인 DNS 리졸버를 선택하지 않고 다른 옵션을 선택하여 비용을 절감할 수 있습니다. 다른 옵션에는 수동 활동이 포함됩니다.

1. Use Private DNS resolve:

이 충돌을 처리하는 한 가지 방법은 Azure DNS Private Resolver를 사용하거나 공유 서비스 VNET 또는 도메인 컨트롤러가 호스팅되는 ID VNET의 별도 서브넷에 DNS Private Resolver를 배포하는 것입니다. 인바운드 엔드포인트를 만들고, 프라이빗 엔드포인트에 대한 조건부 포워더를 만들고 ADPR(Azure DNS Private Resolver)을 가리킵니다. 조건부 포워더를 Active Directory에 저장하면 Azure 호스팅 DNS 서버 또는 온프레미스에 복제되더라도 DNS 이름 확인 흐름이 끊어지지 않습니다. 모든 확인 요청이 ADPR에 들어오고 프라이빗 IP를 확인합니다.

일부 우수한 아키텍처 및 흐름도는 이미 여기에 문서화되어 있습니다: https://learn.microsoft.com/en-us/azure/architecture/networking/architecture/azure-dns-private-resolver

장점: MS는 일반적으로 ADPR을 권장합니다. 서버를 관리할 필요가 없고, 가용성이 높고, 보안성이 뛰어나며, 관리형 서비스이기 때문입니다.

2. Create conditional forwarder without storing it in Active Directory

또 다른 접근 방식은 온프레미스 DNS 서버에서 조건부 포워더를 만들 때 Active Directory에 저장하지 않는 것입니다. 이로 인해 Azure의 DNS 서버에 동일한 내용이 복제되지 않습니다. 그러면 충돌이 방지됩니다.

그러나 이 접근 방식에는 함정이 있습니다. 통합 DNS가 있는 20개의 도메인 컨트롤러가 있는 경우 각 DNS 서버에서 조건부 포워더를 수동으로 만들어야 합니다. Powershell을 통해 이를 스크립팅할 수 있습니다. 이 작업은 새 유형의 개인 엔드포인트를 만들 때마다 수행해야 합니다. 예를 들어 BLOB 저장소를 사용하다가 SQL PaaS 데이터베이스를 사용하기 시작하면 새 FQDN이 생성됩니다. Powershell 스크립트를 통해 각 DNS 서버에서 다시 한 번 동일한 작업을 만들어야 합니다. 또는 조직에서 미리 모든 잘 알려진 개인 엔드포인트 FQDN을 한 번에 추가할 수 있도록 허용하는 경우 이를 수행할 수 있습니다.

PowerShell 스크립트의 경우 아래 링크를 사용할 수 있으며, 작성자는 실행하여 조건부 포워더를 빠르게 생성할 수 있는 스크립트를 만들었습니다.

https://blog.workinghardinit.work/2022/08/09/powershell-script-to-maintain-azure-public-dns-zone-conditional-forwarders/

3. 별도의 Active Directory 파티션을 만듭니다.(Create a separate active directory partition)

이 솔루션에서는 별도의 Active Directory 파티션을 만들어야 합니다. 해당 파티션에 조건부 포워더를 저장합니다. 해당 파티션에 온-프레미스 DNS 서버만 가입하면 됩니다. Azure에서 호스팅되는 DNS 서버는 제외합니다. 결국 Azure에서 호스팅되는 DNS 서버에 조건부 포워더를 복제하지 않으므로 충돌이 발생하지 않습니다.

주의하세요. 이미 조건부 포워더를 생성한 다음 이 솔루션을 사용하는 것을 고려하는 경우 Active Directory DNS에 버그가 있습니다. 온프레미스 DNS 서버에서 모든 조건부 포워더를 삭제하고 다시 생성해야 합니다.

위의 옵션이 여러분의 환경에 맞는 올바른 이름 확인 전략을 선택하는 데 도움이 되기를 바랍니다.

즐거운 학습이 되세요!

리프트 앤 시프트 마이그레이션을 수행할 때 Azure에서 다양한 유형의 대상을 접하게 됩니다. Azure의 대상 중 하나는 Azure VMware Solution(AVS)으로, Azure의 프라이빗 클라우드 오퍼링입니다. 기본적으로 전용 베어 메탈 서버의 vSphere 클러스터가 포함됩니다. AVS의 스토리지를 확장해야 하는 경우 Azure에는 여러 스토리지 옵션이 있습니다. 이 블로그에서는 퍼스트파티 오퍼링에 초점을 맞춥니다.

vSAN: 로컬 스토리지

이 유형의 스토리지는 베어 메탈 서버에 로컬로 연결된 디스크에서 제공됩니다. 이는 NVMe SSD로, 노드 자체에서 직접 제공되므로 가장 빠른 스토리지를 제공합니다.

저장소 크기는 클러스터에 배포하는 노드 수에 따라 달라집니다. 최소 3개에서 최대 16개의 노드를 단일 클러스터에 배포할 수 있습니다. 크기는 RAID 구성에 따라 달라집니다.

FTT는 클러스터가 실패를 견뎌내고 손실 없이 데이터를 유지할 수 있는 노드 수를 나타냅니다. FTT 속도가 높을수록 최소 호스트 요구 사항이 높아집니다.

RAID를 구성한 후 사용 가능한 공간이 무엇이든 vSAN에 여유 공간으로 25%를 유지해야 한다는 점을 명심하세요. 이는 호스트 장애, 업데이트 및 vSAN 정책 변경을 위한 것입니다. SLA 요구 사항을 충족하려면 25%의 여유 공간을 유지해야 합니다.

AVS 호스트에서 얻을 수 있는 사용 가능한 스토리지를 계산하려면 아래에 언급된 웹사이트를 사용할 수 있습니다. 이 예는 AV36P입니다. 여기에는 각각 3.2TB의 용량 디스크 3개가 있는 2개의 디스크 그룹이 있습니다.

관찰에 따르면 노드당 10~13TB의 사용 가능한 공간을 얻을 수 있습니다. AVS 노드가 있는 용량 디스크는 아래 스크린샷에서 찾을 수 있습니다.

이것은 두 개의 디스크 그룹으로 나뉩니다.

공간 요구 사항이 vSAN에서 얻을 수 있는 사용 가능한 공간보다 높으면 원격 스토리지를 선택하거나 추가 노드를 얻어서 vSAN을 확장해야 합니다. AVS의 노드는 연결된 스토리지와 함께 제공됩니다. 클러스터에서 노드를 추가하는 것은 비용이 많이 드는 옵션이므로 기본적으로 추가 노드를 추가하지 않고 스토리지를 확장하는 것을 의미하는 원격 스토리지 옵션을 확인할 수 있습니다.

AVS는 ANF나 Elastic SAN 등 자사에서 제공하는 다양한 형태를 지원하지만, Pure Storage와 같은 타사 스토리지도 지원합니다.

AVS를 사용한 Azure NetApp 파일

Azure NetApp Files는 VM 내부에서 NFS 공유를 마운트하는 데 사용할 수 있으며 vCenter에서 NFS 데이터 저장소로 사용할 수도 있습니다. AVS는 VNET이 아닌 별도의 베어 메탈 서버에 호스팅되므로 ANF 볼륨에 연결해야 하는 경우 AVS에 내장된 ExpressRoute를 통해 연결해야 합니다. ANF는 게이트웨이인 ExpressRoute 게이트웨이를 통해 ExpressRoute 회로에 연결된 별도의 VNET에 배포됩니다.

AVS와 ANF 간 데이터 전송은 내장된 ExpressRoute 연결을 통해 연결되므로 무료입니다.

아래 다이어그램은 연결 메커니즘을 보여줍니다.

AVS가 특정 구역에 배포되므로 데이터스토어에 대한 저지연 연결을 달성하기 위해 ANF도 동일한 구역에 배포해야 합니다. 이는 ANF를 특정 구역에 배치하는 가용성 구역 볼륨 그룹 배치 기능으로 달성할 수 있습니다.

AVS에서 ANF와의 연결은 데이터 저장소 트래픽을 처리하는 별도의 VMK를 통해 이루어지며 트래픽 격리를 제공합니다.

더 나은 처리량을 위해 고객은 FastPath 기능을 제공하는 Ultra VPN GW 또는 ErGw3Az SKU를 배포할 수 있습니다. FastPath가 활성화되면 게이트웨이를 우회하여 네트워크 트래픽을 AVS로 직접 전송합니다.

VM의 VMDK가 ANF에 배치된 경우, VM을 백업할 수 있는 클라우드 백업 플러그인을 활용할 수 있습니다. 이 도구는 현재 미리보기 상태이며 무료입니다.

AFS는 NFS 프로토콜도 제공하지만 현재는 데이터 저장소로 지원되지 않습니다.

AVS를 사용한 Azure Elastic SAN

ANF ​​외에도 Microsoft는 스토리지 요구 사항을 충족하는 퍼스트파티 솔루션인 Elastic SAN을 제공합니다. 이는 Azure NetApp Files보다 저렴하고 확장 가능합니다. Elastic SAN은 AVS에 데이터 저장소를 제공하는 데 사용할 수 있습니다. AVS에 매핑할 수 있는 iSCSI LUN을 얻고 해당 데이터 저장소에 VM을 만들 수 있습니다.

Elastic SAN은 VMFS 데이터 저장소로 노출됩니다.

기본적으로 Elastic SAN은 프리미엄 SKU로 제공됩니다. TB 단위로 기본 SKU를 구매하면 IOPS와 처리량이 증가합니다. 그러나 기본 SKU로 처리량과 IOPS 요구 사항이 충분한 경우 추가 스토리지를 추가할 수 있으며, 이는 더 저렴하고 IOPS와 처리량이 증가하지 않습니다.

위의 스크린샷에서 보듯이, 기본 크기는 IOPS와 처리량을 늘리는 반면, 더 저렴한 추가 용량은 IOPS/처리량에 영향을 미치지 않습니다.

Elastic SAN은 Azure Portal의 AVS 블레이드에 완전히 통합되어 있습니다. 동일한 블레이드에서 데이터스토어를 만들 수 있으므로 데이터스토어를 매핑하고 확장하기가 더 쉽습니다.

AVS 아키텍처의 스토리지 옵션을 다루었습니다. 이것이 새로운 기회에 맞춰 AVS의 크기를 정하는 데 도움이 되기를 바랍니다.

즐거운 학습이 되세요!

• 시나리오 : 최근 계약 중에 한 고객이 기존 랜딩 존에 Azure VMware 솔루션을 배포하고 싶어했습니다. 이 LZ는 이미 여러 Azure 구독에 배포된 여러 스포크 환경을 제공하기 위해 배포되었습니다. 우리가 마주친 과제 중 하나는 고객이 기존 허브 앤 스포크 모델을 사용하고 허브 VNET에서 Azure 방화벽을 사용하여 기본적으로 이 방화벽을 활용하여 아웃바운드 통신을 위해 인터넷에 도달하는 것이었습니다.허브에 있는 Azure Firewall을 사용하려면 직면하게 될 과제는 AVS에 대한 기본 경로를 광고하는 것입니다. (0.0.0.0/0). 이 블로그는 이 특정 사용 사례를 다룹니다.
• AVS를 배포하는 경우, 이탈/아웃바운드 트래픽을 위한 방화벽을 배포할 수 있는 방법은 여러 가지가 있습니다. 하나는 AVS 내부, 즉 타사 NGFW이거나, 다른 하나는 Azure LZ 외부입니다.
• 해결책 : AVS는 VNET에 호스팅되지 않고 Azure에 자체 네트워킹 구조가 있습니다. 서브넷에 연결할 때처럼 UDR을 연결할 수 없습니다.
  AVS에는 UDR 개념이 없으므로 인터넷 바운드 트래픽을 Azure Firewall로 강제할 수 없습니다.
  AVS는 BGP를 통해 모든 경로를 동적으로 학습하므로 이러한 경로를 다른 방식으로 AVS에 푸시해야 합니다.
• 해결책은 허브 VNET에 Azure Route 서버를 두고 ARS와 BGP 피어링을 할 수 있는 NVA를 배포한 다음 NVA가 Azure Firewall을 가리키는 기본 경로를 푸시하는 것입니다.
  이 NVA는 BGP가 가능한 모든 장치가 될 수 있습니다. Cisco, Palo Alto 또는 FortiGate 어플라이언스가 될 수 있습니다.
  고객에게 3P NVA 어플라이언스가 없는 경우 Azure의 Linux VM에 오픈 소스 FRR을 배포할 수 있습니다.

이 아키텍처의 Visio 파일 다운로드

AVS 네트워킹 옵션

타사(3P) NVA 옵션을 살펴보기 전에 AVS와 관련된 여러 네트워킹 시나리오가 문서화된 공식 문서를 공유하고 싶었습니다. 여기에는 Secure Hub를 사용한 vWAN 접근 방식, 기본적으로 Hub의 Azure Firewall이 포함되어 있습니다. 이것을 강조하는 이유는 배포가 그린필드이고 고객이 Azure Firewall로 진행하려는 경우 vWAN을 사용할 수 있고 BGP 피어를 수행하고 기본 경로를 푸시하기 위해 타사(3P) NVA 장치가 필요하지 않기 때문입니다. 이는 쉽게 수행할 수 있습니다.

아래 설명서는 네트워크 설계에 도움이 될 것입니다.
https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/scenarios/azure-vmware/network-hub-spoke

또한 아래 가이드는 전체 네트워크 설계에 도움이 됩니다.
https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/scenarios/azure-vmware/network-design-guide-intro

허브 VNET의 Azure Route Server

저는 먼저 ARS에 대해 설명하고 AVS를 계획할 때 허브에 ARS가 필요한 이유에 대해 설명하려고 했습니다.

Hub VNET에 ARS를 배포하는 데는 몇 가지 주요 이유가 있습니다.

• AVS를 배포하고 Hub VNET에 연결하려고 할 때 Hub VNET에 Express Route Gateway를 배포하고 AVS Dedicated ExR 회로에 연결합니다.
  AVS 내부에 있는 모든 네트워크 세그먼트를 Hub와 피어링된 모든 Spoke VNET에 광고하기 위해 ARS는 수동 개입 없이 동적으로 이를 수행합니다.
• ARS는 기존 방화벽을 활용할 수 있도록 기본 경로(0.0.0.0/0)를 AVS에 게시하는 데도 도움이 됩니다. 또한, AVS에서 스포크 VNET으로 가는 모든 통신을 NGFW를 통해 전달하려는 경우에도 이를 구현할 수 있습니다.
• Azure VPN Gateway를 사용하여 온-프레미스와 Azure 간에 VPN S2S IPSec 터널을 구축한 경우, 온-프레미스 경로를 AVS로 전파하고 AVS에 연결된 ExR Gateway와 VPN Gateway 간의 전송 연결을 활성화하려면 ARS가 필요합니다.

위의 모든 사항을 위해서는 허브 VNET에 Azure Route Server가 필요합니다.

참고: ARS를 배포할 때 배포가 완료될 때까지 잠시 다운타임이 발생하므로 이에 따라 계획하십시오.
ARS에는 Active-Active VPN Gateway가 필요합니다. 이 배포 방법이 없는 VPN이 있는 경우 ARS를 배포하기 전에 먼저 Active-Active 모드를 활성화해야 합니다.

Azure 방화벽을 갖춘 AVS

이제 AVS 네트워킹 시나리오를 공유하고 ARS가 필요한 이유를 설명하는 기초 작업이 완료되었으므로 Azure Firewall과 함께 AVS를 살펴보고 실제로 어떻게 작동하는지 자세히 알아보겠습니다.

언급했듯이 AVS에 UDR을 연결하여 인터넷 트래픽이 Azure Firewall을 통과하도록 강제할 수는 없습니다. AVS는 무료인 전용 Express 경로 회로와 함께 배포됩니다. AVS에서 제공하는 ExR 회로에 연결할 수 있는 Express Route 게이트웨이를 만들어야 합니다. 이 작업이 완료되면 HUB VNET에 연결되고 이제 BGP를 통해 Express Route 게이트웨이를 통해 AVS에 경로를 푸시할 수 있습니다. 이 경로는 기본 경로 0.0.0.0/0 또는 다른 경로가 될 수 있습니다.

ARS에 연결하고 기본 경로를 광고하려면 타사 NVA 장치가 필요하며, 그런 다음 AVS에 광고됩니다. 그런 다음 경로는 T0 및 T1 게이트웨이에서 수신됩니다.

Cisco 또는 Fortigate SDWAN과 같은 SD-WAN 장치가 있는 경우 이러한 장치는 ARS와 BGP 피어링을 수행할 수 있습니다. 그러나 3P 장치가 없는 기본 VNET 설계가 있는 경우 두 개의 Linux VM에 FRR과 같은 오픈 소스 NVA를 배포하여 고가용성을 제공할 수 있습니다. FRR이 설치되면 ARS와 BGP 피어링을 수행한 다음 BGP를 통해 AVS에 정적 경로를 게시할 수 있습니다.

아래 문서는 FRR을 설치하고 경로를 구성하는 데 도움이 됩니다.

https://github.com/Azure/Enterprise-Scale-for-AVS/tree/main/BrownField/Networking/Step-By-Step-Guides/Global Reach가 없는 AVS에 대한 Expressroute 연결#step-7—configure-routing-on-the-bgp-capable-nvas

이 NVA는 경로를 광고하는 데만 필요하며, NVA는 데이터 경로에 포함되지 않는다는 점을 명심하세요. AVS의 VM은 Express Route 게이트웨이를 통해 방화벽과 직접 통신합니다. 따라서 높은 CPU와 메모리를 가진 VM의 크기를 조정할 필요가 없습니다. AVS에 경로를 광고하는 데만 사용되기 때문입니다.

Azure Route Server는 또한 경로를 학습하고 광고하는 데에만 사용됩니다. 데이터 트래픽 흐름에는 어디에도 나오지 않습니다.

이 블로그가 여러분의 AVS 배포에 도움이 되기를 바랍니다.

즐거운 학습이 되세요!

VM 마이그레이션에 Azure Site Recovery를 사용했던 것을 기억하고, Azure Migrate가 나중에 Azure 고객을 위한 모든 마이그레이션 옵션을 제공하는 중앙 장소로 도입된 것을 기억합니다. 처음에는 에이전트 없는 마이그레이션과 네트워크 종속성 매핑이 포함되었습니다.

시간이 지남에 따라 Azure Migrate는 다양한 유형의 시나리오를 포괄하는 Azure 평가 및 마이그레이션을 위한 본격적인 도구로 발전했습니다. Azure Migrate 제품 팀은 이러한 시나리오 대부분을 중앙 집중화하기 위해 광범위하게 노력했습니다. 최근 Spring 애플리케이션 평가를 위해 도입된 새로운 Kubernetes 기반 Azure Migrate 어플라이언스는 이러한 노력의 예입니다.

검색, 평가 및 마이그레이션에 대한 다양한 시나리오가 있기 때문에 이 게시물을 통해 Azure Migrate 어플라이언스에서 Azure로의 평가 및 마이그레이션을 수행하는 데 현재 사용할 수 있는 옵션을 보여드리고자 합니다.

아래에 이미지가 나와 있습니다. 텍스트 기반 설명도 복사되어 사용할 수 있습니다.

평가 유형 : Azure VM Discovery.
설명 : 온프레미스 환경이나 다른 클라우드(AWS, GCP)에 구성된 Azure Migrate 어플라이언스는 VM을 검색합니다. 검색이 완료되면 평가를 만들어 Azure에서 VM을 실행하는 데 필요한 지원 가능성과 비용에 대한 출력을 제공할 수 있습니다.
Azure의 대상 서비스 이름 : Azure VM
Azure Migrate는 대상 서비스로의 마이그레이션을 지원합니까? : 예
링크 : VMWare VM Discovery , Hyper-V Discovery , Physical Discovery

평가 유형 : Azure SQL Discovery
설명 : Azure Migrate 어플라이언스가 SQL 서버에 액세스할 수 있고 SQL 서버 권한이 있는 필수 자격 증명이 입력되면 Azure Migrate는 SQL 데이터베이스도 검색합니다. 이를 기반으로 데이터베이스를 Azure SQL DB 또는 SQL Managed Instance로 마이그레이션할 수 있는지 여부를 보여주는 평가를 만들 수 있습니다.
Azure의 대상 서비스 이름 : Azure SQL DB, Azure VM의 SQL, Azure SQL MI
Azure Migrate는 대상 서비스로의 마이그레이션을 지원합니까? : 마이그레이션하려면 DMS 서비스를 사용해야 합니다.
링크 : Azure SQL Discovery

평가 유형 : Azure App Service 평가
설명 : Azure App Service로 마이그레이션할 온프레미스 웹 애플리케이션을 평가합니다. VM을 검색하는 동일한 어플라이언스가 해당 VM에서 실행되는 웹 앱도 검색할 수 있습니다. Azure Migrate를 사용하면 다음 유형의 웹 앱을 평가할 수 있습니다.
1) IIS 웹 서버에서 실행되는 ASP.NET 웹 앱
2) Tomcat 서버에서 실행되는 Java 웹 앱
Azure의 대상 서비스 이름 : Azure App Service, Azure App Service 컨테이너
Azure Migrate는 대상 서비스로의 마이그레이션을 지원합니까? : 예
링크 : 웹 앱 평가

평가 유형 : Spring Boot 애플리케이션
설명 : Azure Migrate 도구는 VM에 호스팅된 웹 앱을 검색합니다. 검색 결과에 따라 웹 앱에 대한 평가를 만들어 온프레미스의 Spring Boot 애플리케이션을 Azure Spring Apps로 마이그레이션할 수 있는지 확인할 수 있습니다. 이 평가는 새로운 Kubernetes 기반 Azure Migrate 어플라이언스에서 수행할 수 있습니다. 이 새로 도입된 어플라이언스는 향후 더 많은 유형의 평가를 지원할 예정입니다.
Azure의 대상 서비스 이름 : Azure Spring Apps
Azure Migrate는 대상 서비스로의 마이그레이션을 지원합니까? :
링크 없음 : Spring Boot 애플리케이션

평가 유형 : 웹앱에서 Azure Kubernetes Service(AKS)로
설명 : VM에 호스팅된 웹앱, 특히 ASP.NET 및 Java 웹앱은 Azure App Service 또는 AKS로 마이그레이션할 수 있습니다. 이 평가는 웹앱을 AKS로 마이그레이션할 수 있는지 여부를 판단하는 데 도움이 됩니다.
Azure의 대상 서비스 이름 : Azure Kubernetes Service(AKS)
Azure Migrate는 대상 서비스로의 마이그레이션을 지원합니까? : 예(Azure Migrate: 앱 컨테이너화 도구 사용)
링크 : 웹앱에서 AKS로

평가 유형 : Azure VMware 솔루션(AVS)
설명 : Azure VMware 솔루션(AVS)으로 마이그레이션하기 위해 온프레미스 VMware VM을 평가합니다. 이 평가는 Azure Migrate VMware 어플라이언스가 검색을 위해 온프레미스에 설치되면 만들 수 있습니다. Azure VM 관련 평가에 사용된 동일한 어플라이언스를 사용하여 해당 VM을 호스팅하는 데 필요한 AVS 노드 수를 확인할 수 있습니다. 이는 있는 그대로의 평가 또는 성능 기반 평가일 수 있으며, 스토리지 요구 사항을 충족하는 데 필요한 노드 수와 외부 스토리지(ANF/ESAN)를 제공합니다.
Azure의 대상 서비스 이름 : Azure VMware 서비스(AVS)
Azure Migrate는 대상 서비스로의 마이그레이션을 지원합니까? : HCX를 사용하여 서버를 AVS로 마이그레이션해야 합니다.
링크 : AVS 평가

평가 유형 : VMware 인벤토리(RVTools XLSX)
설명 : RVTools XLSX(미리 보기)를 사용하여 VMware 환경에서 실행 중인 서버를 검색합니다. Azure Migrate 어플라이언스를 설정할 필요가 없습니다. RVTools를 내보내고 Azure Migrate 프로젝트로 가져와서 AVS 크기를 가져옵니다. 이 옵션은 미리 보기 상태이며 주로 고객이 온프레미스에 어플라이언스를 설치하지 않고 인벤토리의 대략적인 크기를 빠르게 원하는 시나리오에서 사용됩니다.
Azure의 대상 서비스 이름 : Azure VMware 서비스(AVS)
Azure Migrate는 대상 서비스로의 마이그레이션을 지원합니까? : HCX를 사용하여 서버를 AVS로 마이그레이션해야 합니다.
링크 : RVTools 가져오기를 사용한 VMware 평가

평가 유형 : SAP 시스템(미리 보기)
설명 : 가져오기 옵션을 사용하여 온프레미스 SAP 시스템을 평가합니다. 이는 사전 정의된 템플릿에서 온프레미스 SAP 세부 정보를 제공해야 하는 XLS 가져오기 옵션입니다. 이 옵션은 미리 보기에 있습니다.
Azure의 대상 서비스 이름 : Azure VM(SAP 앱 및 HANA VM)
Azure Migrate는 대상 서비스로의 마이그레이션을 지원합니까? : 예, Azure Migrate를 사용하여 SAP 앱 서버를 마이그레이션할 수 있습니다. HANA의 경우 HSR을 사용하여 HANA DB를 호스팅하는 Azure VM으로 데이터베이스를 복제해야 합니다. SAP ASCS 및 앱 서버는 Azure Migrate를 사용하여 마이그레이션하는 대신 다시 만들어야 할 가능성이 높습니다.
링크 : SAP 시스템 평가

평가 유형 : Azure Stack HCI(미리 보기)
설명 : VMware/Hyper-V에서 Azure Stack HCI로의 평가는 없습니다. 그러나 Azure Migrate 어플라이언스를 사용하여 Azure Stack HCI로 마이그레이션할 수 있습니다. 이 옵션은 미리 보기에 있습니다.
Azure의 대상 서비스 이름 : Azure Stack HCI VM
Azure Migrate는 대상 서비스로의 마이그레이션을 지원합니까? : 예
링크 : Azure Stack HCI 마이그레이션 , Azure Portal용 미리 보기 링크 - HCIMigratePPVMW

Azure VM을 선택하는 것 외에 다른 서비스를 사용하고 평가를 수행할 때 위의 옵션이 도움이 되기를 바랍니다.

즐거운 학습이 되세요!