728x90

RVTools is a free tool widely known in the VMware community and is a great resource for VMware administrators. With RVTools, you can manage ESX servers, virtual machines, and vCenter servers. It is also very easy to use and gives specific health check information about the environment, making it an essential VMware utility.

Installing RVTools: A Step-by-step Guide

Installing RVTools on your Windows machine is a straightforward process. Simply download the latest version from the official RVTools website, located here:

Run the installer, and follow the on-screen instructions. Remember, RVTools interacts directly with the VMware vSphere Management SDK. It means you must have VMware Tools installed on your virtual machines.

Navigating RVTools: A Closer Look at the Tabs

RVTools displays information through several tabs, each offering insight into different aspects of your VMware infrastructure. Some of the tabs VIAdmins reference most often include:

  • vInfo tab: Displays general information about your virtual machines.
  • vDisk tab: Provides detailed information about the disk properties of your virtual machines.
  • vHealth tab: Conducts health checks and points out potential issues in your vSphere environment, including hosts, virtual machine

Unleashing the Power of RVTools for VMware Health Checks

RVTools isn’t just a tool for display information. It’s a great utility for conducting health checks within your vSphere environment. The vHealth tab is a “go-to” source of information for vSphere health checks. It checks for things like:

  • VMware tools not installed or out of date
  • Zombie VMDKs
  • CD Drives connected
  • Inconsistent folder names
  • Overprovisioned hosts
  • Other Best practices

These health checks are a great way to make sure your VMware environment runs smoothly. RVTools makes these checks easier by providing specific information and alerts on potential issues.

Leveraging RVTools for VMware Resource Management

RVTools is also an excellent tool for managing resources within your VMware environment. It provides insights into resource pools, memory, disks, partitions, network configurations, and more. You can monitor CPU usage, memory allocation, and even the status of your distributed switches and distributed ports.

RVTools Tabs and Features

The vInfo Tab

The vInfo tab in RVTools provides a comprehensive overview of your virtual machines, including their current power state, connection state, VMware Tools installed status, and ESX host data. Notably, the tab displays whether VMware Tools is installed, ensuring your VMs are running the latest version of this crucial software.

The vDisk Tab

The vDisk tab offers detailed information about your virtual machines’ disks. It provides specific information about each VM’s disks, memory, partitions, and network configurations. It also shows whether CD drives and USB devices are connected, proving useful when troubleshooting hardware issues.

The vHealth Tab

The vHealth tab takes health checks in your vSphere environment to a whole new level. It flags potential inconsistencies, such as outdated VMware Tools or inconsistent folder names, and helps you maintain the overall health of your ESX server and the VMs it hosts.

Efficiently Working with vCenter Server

RVTools interfaces smoothly with vCenter Server, providing administrators with a comprehensive overview of their vSphere environment.

This includes detailed information about ESX hosts, distributed switches, distributed ports, service consoles, VM kernels, and even license info. This data is invaluable when managing complex virtual environments.

Creating a Single XLSX Report

One of RVTools’ useful features is its ability to generate a single XLSX file report containing all the data it collects. Using an XLSX merge utility (included with RVTools), you can consolidate data from multiple vSphere environments into one comprehensive report. This feature saves time and simplifies data analysis, proving invaluable for VMware administrators.

RVToolsMergeExcelFiles.exe -input C:\myfiles\vcsa-site1-vHealth.xlsx;C:\myfiles\vcsa-site2-vHealth.xlsx -output C:\myfiles\allvcenters-vHealth.xlsxCopyCopy

SRM Placeholder and Other Advanced Features

RVTools also includes support for SRM Placeholder VMs used in disaster recovery scenarios. This feature and multipath info for iSCSI, FC, and NFS datastores make RVTools a versatile and powerful tool for managing VMware environments.

Referer. Learn how to configure autostart of virtual machine on VMware.

RVTools FAQs

1. What is RVTools and why is it beneficial for VMware environments? RVTools is a free utility that connects to your vSphere environment and collects detailed information about your ESX hosts, virtual machines, and other components. This tool is beneficial as it helps VMware administrators perform health checks, manage resources, and generate detailed reports efficiently.

2. How does RVTools interface with vCenter Server? RVTools interfaces smoothly with vCenter Server, providing a comprehensive overview of your vSphere environment. This includes details about ESX hosts, distributed switches, distributed ports, service consoles, and VM kernels, aiding in effectively managing your VMware environment.

3. Can RVTools provide specific information about distributed switches and ports? RVTools offers detailed insights into distributed switches and ports in your vSphere environment. It provides information about HBAs, NICs, switches, ports, distributed switches, and service consoles. This network data is invaluable for troubleshooting and planning network expansions.

4. How does RVTools assist with resource management in a VMware environment? RVTools provides detailed data about resource pools, helping VMware administrators manage resources more efficiently. It shows the allocation and usage of CPU, memory, disks, and partitions, which assists in balancing workloads and optimizing resource utilization across your VMware environment.

5. How does RVTools help with reporting? RVTools has a feature to generate a single XLSX report containing all the data it collects. Using an XLSX merge utility, you can consolidate data from multiple vSphere environments into one comprehensive report, simplifying data analysis and saving time for VMware administrators.

728x90
저작자표시

'IT이야기 > Azure' 카테고리의 다른 글

Cross-Cloud Mobility with VMware HCX  (1) 2025.02.07
Azure Update Manager: 하이브리드 및 멀티 클라우드에서 작동하는 방식  (1) 2024.12.31
Azure Elastic SAN을 선택하는 이유? 비용 및 사용 사례 비교  (2) 2024.12.31
하나의 Enterprise Agreement에서 여러 테넌트를 관리하는 방법  (2) 2024.12.31
Azure 기본 VM 아웃바운드 액세스 중단: 전환 방법  (0) 2024.12.31
728x90

Update 10th September 2020: vSphere 7.0 (VDS 7.0) and NSX-T 3.0.1+ are supported since the HCX R143 release which has been made available on September 8, 2020

https://docs.vmware.com/en/VMware-HCX/services/rn/VMware-HCX-Release-Notes.html 

—

Most people think that VMware HCX is a only migration tool that helps you moving workloads to a vSphere based cloud like VMware Cloud on AWS, Azure VMware Solution or Google Cloud VMware Engine. But it can do so much more for you than only application or workload migrations. HCX is also designed for workload rebalancing and business continuity across data centers or VMware clouds. Why I say “across VMware clouds” and not only “clouds”?

A few years ago everyone thought or said that customers will move all their workloads to the public cloud and the majority of them don’t need local data centers anymore. But we all know that this perception has changed and that the future cloud operation is model hybrid.

A hybrid cloud environment leverages both the private and public clouds to operate. A multi-cloud environment includes two or more public cloud vendors which provide cloud-based services to a business that may or may not have a private cloud. A hybrid cloud environment might also be a multi-cloud environment.

We all know that the past perception was an illusion and we didn’t have a clue where the hyperscalers like AWS, Azure or GCP would be in the next 5 or 7 years. And I believe that even the AWS and Microsoft didn’t expect what is going to happen since we observed interesting shifts in the last few years.

Amazon Web Services (AWS) has been launched 14 years ago (2006) to provide web services from the cloud. At AWS re:Invent 2018 the CEO Andy Jassy announced AWS Outposts because their customers have been asking for an AWS option on-premises. In the end, Outpost is just an extension of an AWS region into the own data center, where you can launch EC2 instances or Amazon EBS volumes locally. AWS already had some hybrid services available (like Storage Gateway) but here we talk about infrastructure and making your own data center part of the AWS Global Infrastructure.

Microsoft Azure was released in 2010 and the first technical preview of Azure Stack has been announced in 2016. So, Microsoft also realized that the future cloud model is a hybrid approach “that provides consistency across private, hosted and public clouds”.

Google Cloud Platform (GCP) offers cloud computing services since 2008. Eleven years later (in 2019) Google introduced Anthos that you can “run an app anywhere –  simply, flexibly and securely”.

All the hyperscalers changed their cloud model to provide customers a consistent infrastructure with consistent operations and management as we understand now.

VMware is coming from the other end of this hybrid world and has the same overall goal or vision to make a hybrid or multi-cloud reality. But with one very important difference. VMware helps you to abstract the complexity of a hybrid environment and gives you the choice to run your workloads in any cloud infrastructure with a cloud-agnostic approach.

As organizations try to migrate their workloads to the public, they face multiple challenges and barriers:

  • How can I migrate my workload to the public cloud?
  • How long does it take to migrate?
  • What about application downtime?
  • Which migration options do I have?
  • Which cloud is the best destination for which workloads?
  • Do I need to refactor or develop some applications?
  • Can I do a lift and shift migration and modernize the application later?
  • How can I consistently deploy workloads and services for my multi-cloud?
  • How can I operate and monitor (visibility and observability) all the different clouds?
  • What if tomorrow one the public cloud provider is not strategic anymore? How can I move my workloads away?
  • How can I control costs over all clouds?
  • How can I maintain security?
  • What about the current tools and 3rd party software I am using now?
  • What if I want to migrate VMs back from the public cloud?
  • What if I want to move away/back somewhen from a specific cloud provider?

In summary, the challenges with a hybrid cloud are about costs, complexity, tooling and skills. Each public cloud added to your current on-premises infrastructure is in fact a new silo. If you have the extra money and time and don’t need consistent infrastructures and consistent operations and management, you’ll accept the fact that you have a heterogeneous environment with different technology formats, skill/tool sets, operational inconsistencies and security controls.

If you are interested in a more consistent platform then you should build a more unified hybrid cloud. Unified means that you provide consistent operations with the existing skills and tools (e.g. vCenter, vRealize Automation, vRealize Operations) and the same policies and security configuration over all clouds – your data center, public cloud or at the edge.

To provide such a cloud agnostic platform you need to abstract the technology format and infrastructure in the public cloud. This is why VMware built the VMware Cloud Foundation (VCF) platform that delivers a set of software-defined services for compute, storage, networking, security and cloud management for any cloud.

VMC on AWS, Azure VMware Solution, Google Cloud VMware Engine and all the other hybrid cloud offerings (IBM, Oracle, Alibaba Cloud, VCPP) are based on VMware Cloud Foundation. This is the underlying technology stack you would need if your goal is to be independent and to achieve workload mobility between clouds. With this important basic understanding we can take a closer look at VMware HCX.

VMware HCX Use Cases

HCX provides an any-to-any vSphere workload mobility service without requiring retrofit as we use the same technology stack in any cloud. 

HCX enables you to schedule application migrations of hundreds or thousands of vSphere VMs within your data centers and across public clouds without requiring a reboot or a downtime.

If you would like to change the current platform or have to modernize your current data center, HCX allows you to migrate workloads from vSphere 5.x and non-vSphere (Hyper-V and KVM) environments.

Workload rebalancing means providing a mobility platform across cloud regions and cloud providers to move applications and workloads at any time for any reason.

Workload mobility is cool and may be the future but is not possible today as the public cloud’s egress costs would be way too high at the moment. Let’s say you pay $0.05 per GB when you move data away from the public cloud to any external destination, this would generate costs of $2.50 for a 50GB virtual machine.

Not that much, right? If you move away 500 VMs, the bill would list $1’250 for egress costs. Evacuating VMs from one public cloud to another one is not so expensive if it happens three or four times a year. But if the rebalancing should happen at a higher cadence, the egress costs would get too high. But we can assume that this fact will change in the future as the public cloud computing prices will come down in the future. 

HCX Components and Services

HCX is available with an Advanced and Enterprise license. The Advanced license services are standard with HCX and are also included in the HCX Enterprise license. The Enterprise license is needed when you migrate non-vSphere workloads into a vSphere environment. This capability is called OS Assisted Migration (OSAM).

The HCX Advanced features are included in a NSX Data Center Enterprise Plus license. With a managed service like VMware Cloud on AWS or Azure VMware Solution HCX Advanced is already be included.

If you want to move workloads from a vSphere environment to a vSphere enabled public cloud, you don’t need the complete VMware Cloud Foundation stack at the source site:

  • On-premises vSphere version 5.5 and above
  • Minimum of 100 Mbps bandwidth between source and destination
  • Virtual switch based on vDS (vSphere Distributed Switch), Cisco Nexus 1000v or vSphere Standard Switch
  • Minimum of virtual machine hardware version 9
  • VMs with hard disks not larger than 2TB

Depending on the HCX license and services you need, you have to deploy some or all of the HCX components. HCX comprises components and appliances at the source and destination sites.

The HCX Connector services and appliances are deployed at the destination site first before you are going to deploy the virtual appliances at the source site (HCX Interconnect appliance).

After you deployed the appliances at the source site, you can create the site pairing.

As soon as you have installed HCX in both sites, you can manage and configure the services within the vSphere Client.

After a successful site pairing, you can start to create the HCX Service Mesh.

The Multi-Site Service mesh is used to create a secure optimized transport fabric between any two sites managed by HCX. When HCX Migration, Disaster recovery, Network Extension, and WAN Optimization services are enabled, HCX deploys Virtual Appliances in the source site and corresponding “peer” virtual appliances on the destination site. The Multi-Site Service Mesh enables the configuration, deployment, and serviceability of these Interconnect virtual appliance pairs.

In the HCX site-to-site architecture, there is notion of an HCX source and HCX destination environment. Depending on the environment, there is a specific HCX installer:

HCX Connector (previously HCX Enterprise) or HCX Cloud. HCX Connector is always deployed as the source. HCX Cloud is typically deployed as the destination, but it can be used as the source in cloud-to-cloud deployments. In HCX-enabled public clouds, the cloud provider deploys HCX Cloud. The public cloud tenant deploys HCX Connector on-premises.
The source and destination sites are paired together for HCX operations. 

In both the source and destination environments, HCX is deployed to the management zone, next to each site’s vCenter Server, which provides a single plane (HCX Manager) for administering VMware HCX. This HCX Manager provides a framework for deploying HCX service virtual machines across both the source and destination sites. VMware HCX administrators are authenticated, and each task authorized through the existing vSphere SSO identity sources. VMware HCX mobility, extension, protection actions can be initiated from the HCX User Interface or from within the vCenter Server Navigator screen’s context menus.

In the NSX Data Center Enterprise Plus (HCX for Private to Private deployments), the tenant deploys both source and destination HCX Managers.

The HCX-IX service appliance provides replication and vMotion-based migration capabilities over the Internet and private lines to the destination site whereas providing strong encryption, traffic engineering, and virtual machine mobility.

The VMware HCX WAN Optimization service appliance improves performance characteristics of the private lines or Internet paths by applying WAN optimization techniques like the data de-duplication and line conditioning. It makes performance closer to a LAN environment. It accelerates on-boarding to the destination site using Internet/VPN- without waiting for Direct Connect/MPLS circuits.

The VMware HCX Network Extension service appliance provides a late Performance (4–6 Gbps) Layer 2 extension capability. The extension service permits keeping the same IP and MAC addresses during a Virtual Machine migration. Network Extension with Proximity Routing provides the optimal ingress and egress connectivity for virtual machines at the destination site.

 

Using VMware HCX OS Assisted Migration (OSAM), you can migrate guest (non-vSphere) virtual machines from on-premise data centers to the cloud. The OSAM service has several components: the HCX Sentinel software that is installed on each virtual machine to be migrated, a Sentinel Gateway (SGW) appliance for connecting and forwarding guest workloads in the source environment, and a Sentinel Data Receiver (SDR) in the destination environment.

The HCX Sentinel Data Receiver (SDR) appliance works with the HCX Sentinel Gateway appliance to receive, manage, and monitor data replication operations at the destination environment.

HCX Migration Types

VMs can be moved from one HCX-enabled data center using different migration technologies or types.

HCX cold migration uses the VMware NFC (Network File Copy) protocol and is automatically selected when the source VM is powered off.

HCX vMotion

  • This option is designed for moving a single virtual machine at a time
  • There is no service interruption during the HCX vMotion migration
  • Encrypted vMotion between legacy source and SDDC target
  • Bi-directional (Cross-CPU family compatibility without cluster EVC)
  • In-flight Optimization (deduplication/compression)
  • Compatible from vSphere 5.5+ environments (VM HW v9)

HCX Bulk Migration

  • Bulk migration uses the host-based replication (HBR) to move a virtual machine between HCX data centers
  • This option is designed for moving virtual machines in parallel (migration in waves)
  • This migration type can set to complete on a predefined schedule
  • The virtual machine runs at the source site until the failover begins. The service interruption with the bulk migration is equivalent to a reboot
  • Encrypted Replication migration between legacy source and SDDC target
  • Bi-directional (Cross-CPU family compatibility)
  • WAN Optimized (deduplication/compression)
  • VMware Tools and VM Hardware can be upgraded to the latest at the target.

HCX Replication Assisted vMotion

VMware HCX Replication Assisted vMotion (RAV) combines advantages from VMware HCX Bulk Migration (parallel operations, resiliency, and scheduling) with VMware HCX vMotion (zero downtime virtual machine state migration).

HCX OS Assisted Migration

This migration method provides for the bulk migration of guest (non-vSphere) virtual machines using OS Assisted Migration to VMware vSphere on-premise or cloud-based data centers. Enabling this service requires additional HCX licensing.

 

  • Utilizes OS assisted replication to migrate (conceptually similar to vSphere replication)
  • Source VM remains online during replication
  • Quiesce the source VM for final sync before migration
  • Source VM is powered off and the migrated VM is powered on in target site, for low downtime switchover
  • VMware tools is installed on the migrated VM

Cross-Cloud Mobility

Most customers will probably start with one public cloud first, e.g. VMC on AWS, to evaluate the hybridity and mobility HCX delivers. Cross-cloud monility is maybe not a requirement today or tomorrow but gets more important when your company has a multi-cloud strategy which becomes reality very soon.

If you want to be able to move workloads seamlessly between clouds, extend networks and protect workloads the same way across any cloud, then you should consider a VMware platform and use HCX.

Let’s take network and security as an example. How would you configure and manage all the different network, security, firewall policies etc. in your different clouds with the different infrastructure and security management consoles?

If you abstract the hyperscaler’s global infrastructure and put VMware on top, you could in this case use NSX (software-defined networking) everywhere. And because all the different policies are tied to a virtual machine, it doesn’t matter anymore if you migrate a VM from host to host or from cloud to cloud.

This is what you would call consistent operations and management which is enabled by a consistent infrastructure (across any cloud).

And how would you migrate workloads in a very cost and time efficient way without a layer 2 stretch? You would have to take care of re-IPing workloads and this involves a lot of changes and dependencies. If you have hundreds of applications then the cloud migration would be a never ending project with costs you could not justify.

In the case you need to move workload back to your own on-premises data center, HCX also gives you this advantage.

You have the choice in which cloud you want to run your applications, at any time.

 

HCX and vSphere 7

At the time of writing HCX has no official support for vSphere 7.0 yet. I tested it in my home lab and ran into an error while creating the Service Mesh. At least one other colleague had the same issue with vSphere 7 using NSX-T 3.0 and VDS 7.0.

I would like to thank Danny Stettler for reviewing and contributing. 🙂 Big kudos to you, Danny! 🙂

I hope the article has helped you to get an overview what HCX and a hybrid cloud model really mean. Drop a comment and share your view and experience when it comes to cloud strategies and migrations.

728x90
저작자표시

'IT이야기 > Azure' 카테고리의 다른 글

RVTools: VMware Management Tool Download and Features  (0) 2025.02.10
Azure Update Manager: 하이브리드 및 멀티 클라우드에서 작동하는 방식  (1) 2024.12.31
Azure Elastic SAN을 선택하는 이유? 비용 및 사용 사례 비교  (2) 2024.12.31
하나의 Enterprise Agreement에서 여러 테넌트를 관리하는 방법  (2) 2024.12.31
Azure 기본 VM 아웃바운드 액세스 중단: 전환 방법  (0) 2024.12.31
728x90
  • 시나리오 : 최근의 업무에서 고객 중 한 명이 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을 더 빠르게 배포하고 올바른 아키텍처 패턴을 따르는 데 도움이 되기를 바랍니다.

즐거운 학습이 되세요!

728x90
저작자표시

'IT이야기 > Azure' 카테고리의 다른 글

RVTools: VMware Management Tool Download and Features  (0) 2025.02.10
Cross-Cloud Mobility with VMware HCX  (1) 2025.02.07
Azure Elastic SAN을 선택하는 이유? 비용 및 사용 사례 비교  (2) 2024.12.31
하나의 Enterprise Agreement에서 여러 테넌트를 관리하는 방법  (2) 2024.12.31
Azure 기본 VM 아웃바운드 액세스 중단: 전환 방법  (0) 2024.12.31
728x90

이 블로그는 아직 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이 귀하의 배포에 더 적합한지 확인하고 비용 절감을 달성하는 데 도움이 되기를 바랍니다.

즐거운 학습이 되세요!

728x90
저작자표시

'IT이야기 > Azure' 카테고리의 다른 글

Cross-Cloud Mobility with VMware HCX  (1) 2025.02.07
Azure Update Manager: 하이브리드 및 멀티 클라우드에서 작동하는 방식  (1) 2024.12.31
하나의 Enterprise Agreement에서 여러 테넌트를 관리하는 방법  (2) 2024.12.31
Azure 기본 VM 아웃바운드 액세스 중단: 전환 방법  (0) 2024.12.31
Traffic Manager와 App Gateway를 사용하여 multiple SAP 앱에 액세스하세요.  (1) 2024.12.31
728x90
  • 시나리오 : 고객이 하나의 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 에게 특별 감사드립니다 .

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

즐거운 학습이 되세요!

728x90
저작자표시

'IT이야기 > Azure' 카테고리의 다른 글

Azure Update Manager: 하이브리드 및 멀티 클라우드에서 작동하는 방식  (1) 2024.12.31
Azure Elastic SAN을 선택하는 이유? 비용 및 사용 사례 비교  (2) 2024.12.31
Azure 기본 VM 아웃바운드 액세스 중단: 전환 방법  (0) 2024.12.31
Traffic Manager와 App Gateway를 사용하여 multiple SAP 앱에 액세스하세요.  (1) 2024.12.31
Azure에서 합병, 인수 및 이동을 처리하는 방법  (0) 2024.12.31
728x90

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

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월 마감일 전에 필요한 조정을 수행하여 중단을 방지하는 데 도움이 되기를 바랍니다.

즐겁게 학습하세요!

728x90
저작자표시

'IT이야기 > Azure' 카테고리의 다른 글

Azure Elastic SAN을 선택하는 이유? 비용 및 사용 사례 비교  (2) 2024.12.31
하나의 Enterprise Agreement에서 여러 테넌트를 관리하는 방법  (2) 2024.12.31
Traffic Manager와 App Gateway를 사용하여 multiple SAP 앱에 액세스하세요.  (1) 2024.12.31
Azure에서 합병, 인수 및 이동을 처리하는 방법  (0) 2024.12.31
Azure Private Endpoint 배포를 위한 온프레미스 DNS 변경  (2) 2024.12.31
728x90

이 블로그에서는 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에게 감사드립니다.

즐거운 학습이 되세요!

728x90
저작자표시

'IT이야기 > Azure' 카테고리의 다른 글

하나의 Enterprise Agreement에서 여러 테넌트를 관리하는 방법  (2) 2024.12.31
Azure 기본 VM 아웃바운드 액세스 중단: 전환 방법  (0) 2024.12.31
Azure에서 합병, 인수 및 이동을 처리하는 방법  (0) 2024.12.31
Azure Private Endpoint 배포를 위한 온프레미스 DNS 변경  (2) 2024.12.31
Azure VMware 솔루션의 스토리지 유형에 대한 비밀 해제  (0) 2024.12.31
728x90

합병 및 인수는 흔하지만, 저는 아키텍트, 영업 및 계정 팀이 두 조직이 모두 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 거버넌스 팀에 연결하려면 계정 팀에 연락해야 합니다. 거버넌스 지원 팀에 정당성을 제공해야 하며 그러면 이 이동을 실행할 수 있습니다. 이것은 다운타임 없이 완전히 백엔드 이동입니다.

이것들은 주요 구독 유형이며, 인도에서 흔한 대부분의 유형을 다루었습니다. 위의 내용이 유용하고 원활한 마이그레이션에 도움이 되기를 바랍니다.

동료들이 알려준 유용한 링크 몇 가지를 소개합니다.

즐거운 학습이 되세요!

728x90
저작자표시

'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
728x90
  • 시나리오 : 고객이 온프레미스 네트워크에서 개인 엔드포인트에 연결하려는 개인 엔드포인트 시나리오에서 먼저 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 서버에서 모든 조건부 포워더를 삭제하고 다시 생성해야 합니다.

 
   

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

즐거운 학습이 되세요!

728x90
저작자표시

'IT이야기 > Azure' 카테고리의 다른 글

Traffic Manager와 App Gateway를 사용하여 multiple SAP 앱에 액세스하세요.  (1) 2024.12.31
Azure에서 합병, 인수 및 이동을 처리하는 방법  (0) 2024.12.31
Azure VMware 솔루션의 스토리지 유형에 대한 비밀 해제  (0) 2024.12.31
Azure Firewall을 사용하여 Azure VMware 솔루션 배포  (0) 2024.12.31
다양한 유형의 Azure Migrate 평가 탐색  (0) 2024.12.31
728x90

리프트 앤 시프트 마이그레이션을 수행할 때 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의 크기를 정하는 데 도움이 되기를 바랍니다.

즐거운 학습이 되세요!

728x90
저작자표시

'IT이야기 > Azure' 카테고리의 다른 글

Azure에서 합병, 인수 및 이동을 처리하는 방법  (0) 2024.12.31
Azure Private Endpoint 배포를 위한 온프레미스 DNS 변경  (2) 2024.12.31
Azure Firewall을 사용하여 Azure VMware 솔루션 배포  (0) 2024.12.31
다양한 유형의 Azure Migrate 평가 탐색  (0) 2024.12.31
Azure에서 도메인을 구매하고 공용 DNS를 구성하는 방법  (0) 2024.12.31

+ Recent posts

티스토리툴바