728x90

🔍 개요

Azure OpenAI 서비스와 API Management를 함께 사용하면 프롬프트와 응답에 대한 상세한 로깅과 모니터링이 가능합니다.
2025년 5월 업데이트로 스트리밍 지원을 포함한 포괄적인 LLM 로깅 기능이 가능하게 되었습니다.

📖 참고: Azure API Management에서 Azure OpenAI에 대한 LLM 로깅 지원 - 5월 업데이트

가이드 범위 및 목표

본 가이드에서는 프롬프트와 응답에 대한 로깅에 초점을 맞춰 작성되었습니다.

API Management를 이용한 고급 정책 설정, 캐싱 전략, 멀티 리전 배포 등의 추가 기능은 추후 다뤄볼 예정입니다.

1. 아키텍처 구성

기본 아키텍처

2. 시나리오 전체 흐름

이 가이드에서 구현할 전체 과정을 미리 확인하여 체계적으로 작업을 진행하겠습니다.

작업 전 참고사항

 

각 단계는 순차적으로 진행되며, 이전 단계가 완료되어야 다음 단계로 진행할 수 있습니다. 예상 소요 시간은 약 45-60분입니다.

 

사전 준비사항

 

  • Azure 구독 및 소유자 권한
  • Azure CLI
  • Python 3.11+
구현 단계별 가이드
Copy
📋 1단계: Azure OpenAI 리소스 및 모델 배포 (10분)
   - OpenAI 서비스 생성
   - GPT 모델 배포 (예: gpt-4o-deployment)
 
📋 2단계: API Management 서비스 생성 (15분)
   - APIM 인스턴스 구성
   - Azure OpenAI API 템플릿으로 API 생성
 
📋 3단계: Managed Identity 권한 설정 확인 (5분)
   - 시스템 할당 관리 ID 확인
   - Azure OpenAI 리소스 IAM 역할 부여 확인
 
📋 4단계: LLM 로깅 활성화 (20분: Log Analytics 초기 테이블 생성 시간 필요)
   - 진단 설정으로 Log Analytics 연결
   - API별 LLM 로깅 활성화
 
📋 5단계: 연결 및 기능 테스트 (5분)
   - 테스트 기능으로 APIM ↔ OpenAI 연결 확인
   - Log Analytics에서 로그 생성 확인
 
📋 6단계: 외부 애플리케이션 테스트 (10분)
   - Python 클라이언트로 APIM 경유 호출
   - 토큰 사용량 및 로그 추적 분석
 
📋 7단계: 보안 정책 검증 (10분)
   - IP 제한 정책 구현 및 테스트
   - 차단 로그 분석 및 검증

3. Azure OpenAI 리소스 생성

리소스 생성

  • 리소스 그룹은 기존 리소스 그룹을 사용하거나 신규로 생성해도 무방합니다.
  • Azure OpenAI는 한국에서 가까운 "japaneast"로 생성
    최근 Korea Central도 지원되니 원하는 모델과 배포 유형의 지역 지원 여부를 확인하세요
Azure PortalAzure CLI
Copy
1. Azure Portal에서 '리소스 만들기' 선택
2. 'Azure OpenAI' 검색 후 선택
3. 기본 설정:
   - 구독: 본인의 구독 선택
   - 리소스 그룹: 새로 만들거나 기존 선택
   - 지역: East US, West Europe 등 OpenAI 지원 지역
   - 이름: 고유한 리소스 이름 (예: myopenai-resource)
   - 가격 책정 계층: Standard (S0)
4. '검토 + 만들기' → '만들기'

모델 배포

  • Azure OpenAI 리소스가 생성되면 사용할 모델을 배포해야 합니다.
Azure PortalAzure CLI
Copy
1. 생성된 Azure OpenAI 리소스로 이동
2. 상단에 'Go to Azure AI Foundry portal' 클릭
3. 왼쪽 블레이드 메뉴에서 '배포' - ' + 모델 배포' 클릭
4. 모델 설정:
   - 모델: gpt-4o
   - 모델 버전: 최신 버전 (예: 2024-11-20)
   - 배포 이름: gpt-4o-deployment (기억하기 쉬운 이름)
   - 배포 유형: 표준
5. '만들기' 클릭
배포 유형 선택 가이드
  • Standard: 일반적인 용도, 예측 가능한 워크로드
  • GlobalStandard: 글로벌 배포, 높은 가용성 필요시
  • ProvisionedManaged: 대용량 처리, 일정한 성능 보장 필요시

4. API Management 리소스 생성

리소스 생성

Azure PortalAzure CLI
Copy
1. Azure Portal에서 '리소스 만들기' 선택
2. 'API Management' 검색 후 선택
3. 기본 설정:
   - 구독: 본인의 구독 선택
   - 리소스 그룹: 새로 만들거나 기존 선택
   - 지역: Korea Central
   - 조직 이름: 회사명 입력
   - 관리자 이메일: 본인 이메일
   - 가격 책정 계층: Developer (개발/테스트용)
4. '검토 + 만들기' → '만들기'

⏱️ 배포 시간: 약 30분 소요
운영 환경 SKU 선택

Developer SKU는 개발/테스트 전용입니다. 운영 환경에서는 SLA가 보장되는 Basic 이상의 SKU를 사용하세요.

📖 SKU 상세 비교: Azure API Management v2 service tiers overview

5. Azure OpenAI와 API Management 연결

템플릿을 활용하여 Azure OpenAI API 생성

API Management에서 Azure OpenAI API를 생성하는 방식은 2가지가 있습니다:

  1. OpenAPI 사양 직접 가져오기: 복잡하고 수동 설정 필요
  2. Azure OpenAI 템플릿 사용: 자동 설정으로 구성이 간단

본 가이드에서는 구성이 비교적 간단한 템플릿 방식으로 진행합니다.

Portal에서 Azure OpenAI API 생성
Copy
1. API Management 인스턴스 → 'APIs' 메뉴 선택
2. '+ Add API' 클릭
3. **'Azure OpenAI'** 템플릿 선택 (Microsoft에서 제공하는 공식 템플릿)

1단계: API 템플릿 선택

2단계: OpenAI 인스턴스 및 설정 구성

3단계: 기본 설정 확인 후 생성

템플릿 사용의 장점

Azure OpenAI 템플릿을 사용하면 자동으로 Managed Identity 인증이 구성되고, 모든 필요한 엔드포인트와 파라미터가 정확하게 설정됩니다.

Managed Identity 권한 설정 및 IAM 확인

Azure OpenAI API 템플릿을 사용하면 자동으로 시스템 할당 관리 ID가 생성되고 권한이 설정됩니다. 이를 확인해보겠습니다.

1. API Management의 관리ID 활성화 상태 확인

2. Backend 권한 방식 확인

3. Azure OpenAI IAM 확인

Azure OpenAI 리소스 권한 확인
Copy
1. Azure OpenAI 리소스 → 'Access control (IAM)' 메뉴
2. 'Role assignments' 탭 확인
3. API Management의 Managed Identity가 다음 역할을 가지고 있는지 확인:
   - **Cognitive Services OpenAI User** 

권한 누락 시 수동 설정

만약 권한이 자동으로 설정되지 않았다면, Azure OpenAI 리소스에서 수동으로 API Management의 Managed Identity에 Cognitive Services OpenAI User 역할을 할당하세요.

인증 구조 이해

위에서 확인한 Managed Identity와 권한 설정은 APIM과 Azure OpenAI 간의 자동 인증을 위한 것입니다.
실제 클라이언트와의 통신 구조는 아래와 같습니다.

중앙 관리의 장점

클라이언트는 Azure OpenAI의 실제 API 키를 알 필요가 없고, APIM 구독키만 사용합니다.
모든 Azure OpenAI 접근은 APIM에서 중앙 관리되며, 키 로테이션, 사용량 모니터링, 정책 적용이 한 곳에서 처리됩니다.

6. LLM 로깅 활성화

진단 설정 구성

먼저 API Management 전체 레벨에서 진단 로그를 Log Analytics Workspace로 전송하도록 설정합니다.

진단 설정 구성
Copy
1. API Management 인스턴스 → '모니터링' → '진단 설정'
2. '+ 진단 설정 추가' 클릭
3. 설정 구성:
   - 진단 설정 이름: openai-logging
   - 로그 섹션에서 다음 선택:
     ☑️ Logs related to ApiManagement Gateway
     ☑️ Logs related to Websocket Connections  
     ☑️ **Logs related to generative AI gateway** (가장 중요!)
   - 대상 세부 정보:
     ☑️ Log Analytics 작업 영역에 보내기
     - 구독: 본인 구독
     - Log Analytics workspace: 새로 만들기 또는 기존 선택
     - Destination table: **리소스별** 선택
4. 'Save' 클릭

로그 생성 대기시간

진단 설정 완료 후 ApiManagementGatewayLlmLogs 테이블이 생성되고 로그가 적재되기까지 15-20분 정도 소요될 수 있습니다.

비용 관련 주의사항

Log Analytics Workspace는 데이터 수집량과 보존 기간에 따라 비용이 발생합니다.

  • Pay-as-you-go: GB당 $2.76 (변동 가능성 있음)
  • 기본 보존 기간: 30일 (추가 보존 시 별도 요금)
  • OpenAI 로그 특성: API 호출량이 많을 경우 상당한 로그 생성

권장 사항:

  • 테스트/개발 환경에서는 짧은 보존 기간 설정 (7일)
  • 프로덕션에서는 필수 로그만 수집 고려
  • 일일 사용량 제한 설정으로 예상치 못한 요금 발생 방지 (Log Analytics Workspace → '사용량 및 예상 비용' → '일일 상한')
  • 정확한 가격은 Azure 가격 계산기로 확인

API 설정에서 LLM 로그 활성화

먼저 생성한 Azure OpenAI API에서 LLM 로깅을 활성화해야 합니다.

API별 LLM 로깅 활성화
Copy
1. API Management → 'APIs' → 생성한 'Azure OpenAI Service' 선택
2. 'Settings' 탭 클릭
3. 'Diagnostics Logs' - 'Azure Monitor' 섹션에서:
   - Override global: ✅ 체크
   - Log LLM Message: ✅ 체크 (중요!)
4. 'Save' 클릭
 
⚠️ 주의사항:
진단 설정 직후에는 'Override global' 활성화 옵션이 보이지 않을 수 있습니다.
이 경우 약 10~15분 정도 기다린 후 페이지를 새로고침하여 다시 확인하세요.

LLM 로깅 추가 정보

새로운 기능: 2025년 5월 업데이트가 된 LLM 로깅 기능은 스트리밍 시나리오를 포함하여 최대 2MB까지의 프롬프트와 응답을 32KB 청크 단위로 로깅할 수 있습니다.

참고 문서: API 로깅 설정에 대한 더 자세한 내용은 Microsoft 공식 문서를 참고하세요
 API Management 모니터링 - API 로깅 설정 수정

7. 연결 테스트 및 로그 확인

APIM 기본 테스트

API Management Portal에서 제공하는 테스트 기능을 사용하여 Azure OpenAI와의 연결을 확인합니다.

테스트 진행
Copy
1. API Management → 'APIs' → 위에서 생성한 'Azure OpenAI Service' 선택
2. 'Test' 탭 클릭
3. 'Creates a completion for the chat message' 선택
4. 필수 파라미터 입력:
   - deployment-id: 배포한 모델명 (예: gpt-4o-deployment)
   - api-version: 2025-01-01-preview
5. Request body 예제:
   {
     "messages": [
       {"role": "user", "content": "안녕하세요, 테스트입니다."}
     ],
     "max_tokens": 100
   }
6. 'Send' 클릭

테스트 완료 화면

배포 모델명 확인 방법

만약 deployment-id와 api-version을 모를 경우 Azure OpenAI 배포모델 메뉴에서 확인하시면 됩니다.

Log Analytics 로그 확인

API Management 진단 로그를 저장한 Log Analytics에서 ApiManagementGatewayLlmLog 테이블 선택 후 실행

프롬프트/응답 메시지 확인

로그 확인 시 주의사항
  • 최초 로그가 나타나기까지 15-20분 소요
  • ApiManagementGatewayLlmLog 테이블이 없다면 더 기다리거나 진단 설정 재확인 필요
  • 로그가 보이지 않으면 API 설정에서 'LLM logging' 체크 상태 확인

일일 토큰 사용량 분석

프롬프트 로그 외에도 Kusto 쿼리를 통해 다양한 사용량 분석이 가능합니다. 아래는 일일 토큰 사용량을 집계하는 쿼리입니다.

일일 토큰 사용량 집계 쿼리
Copy
ApiManagementGatewayLlmLog
| where TimeGenerated >= ago(1d)
| where coalesce(SequenceNumber, 0) == 0
| where tolong(TotalTokens) > 0
| summarize
  TotalRequests   = count(),
  PromptTokensSum = sum(tolong(PromptTokens)),
  CompletionTokensSum = sum(tolong(CompletionTokens)),
  TotalTokensSum  = sum(tolong(TotalTokens)),
  AvgTokensPerReq = avg(tolong(TotalTokens))

8. 외부 애플리케이션 연동 테스트

Python 클라이언트 구성 및 실행

이제 외부 애플리케이션에서 APIM을 통해 Azure OpenAI를 호출하는 테스트를 진행합니다.

Python 클라이언트 코드
Copy
import requests
import json
import os

def call_azure_openai_via_apim():
  """
  API Management를 통해 Azure OpenAI를 호출하는 함수
  """
  
  # APIM 및 Azure OpenAI 설정
  apim_url = "https://your-apim-instance.azure-api.net/openai"  # APIM Gateway URL 경로
  deployment_name = "gpt-4o-deployment"                         # 실제 배포 모델명
  api_version = "2025-01-01-preview"                            # LLM 로깅 지원 버전
  subscription_key = "your-apim-subscription-key"               # APIM 구독 키
  
  # 완전한 API 엔드포인트 URL 구성
  url = f"{apim_url}/deployments/{deployment_name}/chat/completions?api-version={api_version}"
  
  # 요청 헤더 설정
  headers = {
      "Content-Type": "application/json",
      "api-key": subscription_key  # APIM에서 구성한 인증 헤더
  }
  
  # 요청 본문 데이터
  payload = {
      "messages": [
          {
              "role": "system",
              "content": "You are an AI assistant that helps people find information."
          },
          {
              "role": "user", 
              "content": "APIM을 거쳐 Azure OpenAI를 호출하는 구조를 간결하게 설명해 주세요."
          }
      ],
      "temperature": 0.7,      # 응답의 창의성 수준 (0.0-2.0)
      "top_p": 0.95,          # 어휘 다양성 제어 (0.0-1.0)
      "max_tokens": 800       # 응답 최대 길이 제한
  }
  
  try:
      # Azure OpenAI API 호출
      response = requests.post(url, headers=headers, json=payload, timeout=30)
      
      if response.status_code == 200:
          result = response.json()
          print("성공적으로 응답을 받았습니다.")
          print("응답 내용:")
          print(result['choices'][0]['message']['content'])
          
          # 토큰 사용량 정보 출력
          print("\n토큰 사용량:")
          usage = result.get('usage', {})
          print(f"  프롬프트 토큰: {usage.get('prompt_tokens', 'N/A')}")
          print(f"  완성 토큰: {usage.get('completion_tokens', 'N/A')}")
          print(f"  총 토큰: {usage.get('total_tokens', 'N/A')}")
          
          return result
          
      else:
          # HTTP 오류 상태 코드 처리
          print(f"HTTP 오류: {response.status_code}")
          print(f"오류 응답: {response.text}")
          return None
          
  except requests.exceptions.Timeout:
      print("요청 시간 초과 오류가 발생했습니다.")
      return None
  except requests.exceptions.RequestException as e:
      print(f"요청 중 오류가 발생했습니다: {e}")
      return None
  except json.JSONDecodeError:
      print("응답을 JSON으로 파싱하는 중 오류가 발생했습니다.")
      return None

# 메인 실행 부분
if __name__ == "__main__":
  print("APIM을 통한 Azure OpenAI 연결 테스트")
  print("=" * 60)
  
  # 기본 테스트
  print("\n기본 테스트:")
  result = call_azure_openai_via_apim()
  
  if result:
      print("\n테스트 완료! Log Analytics에서 로그를 확인하세요.")
  
  print("=" * 60)
APIM 설정 정보 확인

1. APIM Gateway URL 확인:

  • API Management → 'API' → 'Settings' → Base URL 복사

2. 구독키 확인:

  • API Management → '구독' → 'Built-in all-access subscription'
  • Primary key 또는 Secondary key 복사하여 코드에 사용

APIM Gateway URL 확인 화면

구독키 확인 화면

Python 스크립트 실행 결과 및 성공 응답

로그 확인

Python 애플리케이션 실행 후 Log Analytics에서 로그를 확인할 수 있습니다.

9. 보안 정책 테스트

Azure API Management는 위에서 다룬 로깅 기능 외에도 다양한 고급 기능을 제공합니다:

  • 보안 정책: IP 필터링, 인증/권한 부여, CORS 정책
  • 트래픽 관리: 속도 제한, 할당량 관리, 백엔드 라우팅
  • 데이터 변환: 요청/응답 수정, 헤더 조작, JSON-XML 변환
  • 캐싱: 응답 캐싱을 통한 성능 향상 및 비용 절감

본 섹션에서는 보안 정책 중 하나인 IP 필터링을 통해 Azure OpenAI 서비스 접근을 제한하는 방법을 실습해보겠습니다.

IP 제한 정책 구현

API Management에서 특정 IP 대역만 허용하는 보안 정책을 설정하고 테스트해보겠습니다.

IP 제한 정책 설정
Copy
1. API Management → 'APIs' → 'Azure OpenAI Service' 선택
2. 'Design' 탭 → 'Inbound processing' → '</> Code view' 클릭  
3. 정책 편집기에서 IP 필터 추가

IP 제한 정책
Copy
<policies>
  <inbound>
      <base />
      <!-- 허용 IP만 통과 -->
      <!-- 허용할 IP 대역 설정 -->
      <ip-filter action="allow">
          <address-range from="YOUR_OFFICE_IP_START" to="YOUR_OFFICE_IP_END" />
          <address-range from="YOUR_INTERNAL_NETWORK_START" to="YOUR_INTERNAL_NETWORK_END" />
          <!-- 예시: <address-range from="192.168.1.1" to="192.168.1.254" /> -->
          <!-- 예시: <address-range from="10.0.0.1" to="10.255.255.254" /> -->
      </ip-filter>
      <set-backend-service backend-id="YOUR_OPENAI_BACKEND_ID" />
  </inbound>

  <backend>
      <base />
  </backend>

  <outbound>
      <base />
  </outbound>

  <on-error>
      <base />
      <choose>
          <when condition="@(context.Response.StatusCode == 403)">
              <return-response>
                  <set-status code="403" reason="Forbidden" />
                  <set-header name="Content-Type" exists-action="override">
                      <value>application/json</value>
                  </set-header>
                  <set-body>@{
                      return Newtonsoft.Json.JsonConvert.SerializeObject(new {
                          error = new {
                              code = "IP_BLOCKED",
                              message = "Access denied: Your IP address is not allowed"
                          }
                      });
                  }</set-body>
              </return-response>
          </when>
          <when condition="@(context.LastError != null && context.LastError.Source.Equals("ip-filter"))">
              <return-response>
                  <set-status code="403" reason="Forbidden" />
                  <set-header name="Content-Type" exists-action="override">
                      <value>application/json</value>
                  </set-header>
                  <set-body>@{
                      return Newtonsoft.Json.JsonConvert.SerializeObject(new {
                          error = new {
                              code = "IP_BLOCKED",
                              message = "Access denied: Your IP address is not allowed",
                              source = context.LastError.Source,
                              reason = context.LastError.Reason
                          }
                      });
                  }</set-body>
              </return-response>
          </when>
      </choose>
  </on-error>
</policies>

정책 적용 예시 화면

접근 제한 테스트 및 차단 로그 분석

정책 적용 후 허용되지 않은 IP에서 접근을 시도하여 차단 기능을 테스트합니다.

허용 IP대역에서 접근했을 경우

허용 대역이 아닌 IP에서 접근했을 경우

Log Analytics에서 차단 로그 확인

차단 로그 확인을 위한 kusto 쿼리
Copy
ApiManagementGatewayLogs
| where TimeGenerated > ago(1h)
| where ResponseCode == 403
| project 
  TimeGenerated,
  CallerIpAddress,
  RequestUrl = Url,
  ResponseCode,
  ResponseSize,
  RequestHeaders,
  OperationName

IP 제한 정책 검증 완료
  • ✅ 허용되지 않은 IP에서 403 Forbidden 응답 확인
  • ✅ 사용자 정의 차단 메시지 정상 표시
  • ✅ Log Analytics에서 차단 이벤트 정확히 기록
정책 적용 시 주의사항
  • 개발자 IP 확인: 자신의 현재 IP가 허용 목록에 포함되어 있는지 확인
  • 프로덕션 준비: 운영 환경 적용 전 충분한 테스트 필요
  • Azure 서비스 대역 허용 여부: Azure Portal의 API Management 테스트 기능도 Azure 서비스 IP 대역에서 실행

✨ 결론

Azure API Management를 통한 Azure OpenAI 프롬프트 로깅은 다음과 같은 핵심 이점을 제공합니다:

  • 완전한 투명성: 모든 프롬프트와 응답의 상세 로깅
  • 스트리밍 지원: 2025년 업데이트로 실시간 스트리밍 로깅 지원
  • 사용량 추적: 구독키별 토큰 사용량 및 비용 분석
  • 보안 강화: IP 제한, 구독 관리, 사용량 제한
  • 확장성: 대용량 로그(최대 2MB)의 청크 단위 처리
운영 환경 권장사항

프로덕션 환경에서는 비용 최적화를 위해 로그 보존 정책을 설정하고, 알람 규칙을 구성하여 이상 사용량을 모니터링하는 것을 권장합니다.

이 포스트는 2025년 8월 기준 최신 Azure 공식 문서를 바탕으로 작성되었습니다. 최신 정보는 Microsoft Learn - Azure API Management Azure OpenAI 문서에서 확인하실 수 있습니다.

728x90
728x90

클라우드 컴퓨팅 요구 사항에 가장 적합한 옵션을 선택하는 데 도움이 되는 가이드

 

소개

 

클라우드 컴퓨팅은 애플리케이션과 서비스를 실행하는 강력하고 유연한 방법이지만, 지출을 최적화하는 방법을 모르면 혼란스럽고 비용이 많이 들 수 있습니다. Azure는 사용 패턴과 요구 사항에 따라 Azure 비용을 절감할 수 있는 다양한 옵션을 제공합니다. 이 글에서는 이러한 두 가지 옵션, 즉 컴퓨팅과 예약을 위한 Azure 절감 플랜을 비교하고 대조해 보겠습니다. 또한, 이러한 옵션을 결합하여 절감 효과와 유연성을 극대화하는 방법도 설명합니다. 이 글을 끝까지 읽으면 이러한 옵션을 활용하여 클라우드 컴퓨팅 비용을 절감하고 비즈니스 목표를 달성하는 방법을 더 잘 이해하게 될 것입니다.

 

Azure 컴퓨팅 비용 절감 플랜이란 무엇인가요? 

 

Azure 컴퓨팅 절약 플랜을 사용하면 1년 또는 3년 동안 고정 시간당 지출 약정을 하는 대가로 적격 컴퓨팅 리소스 사용량을 최대 65%까지 절약할 수 있습니다 [1] . 절약 플랜 혜택은 Azure Virtual Machines, Azure App Service, Azure Functions 프리미엄 플랜을 포함한 다양한 컴퓨팅 서비스에 제공됩니다. 여러 컴퓨팅 서비스에서 일관된 지출이 발생하는 경우 절약 플랜을 구매하면 전체 비용을 줄이는 데 도움이 될 수 있습니다. 

 

저축 플랜 할인은 컴퓨팅 인프라 요금(예: CPU, RAM, 스토리지)에 적용되며 컴퓨팅 서비스와 리전의 조합에 따라 달라집니다. 할인 규모는 시간당 약정이 아닌 약정 기간에 따라 결정됩니다. 저축 플랜은 할인을 제공하지만 리소스의 런타임 상태에는 영향을 미치지 않습니다. 저축 플랜 할인은 소프트웨어 라이선스 비용(예: Windows, Windows Server 또는 SQL Server)에는 적용되지 않습니다. Azure Hybrid Benefit을 통해 이러한 라이선스 비용을 절감할 수 있습니다 [2] .  

 

절약 플랜 모델에 따라 Azure는 적격 절약 플랜 적용 가능 사용량에 절약 플랜 할인을 적용합니다. 즉, 절약 플랜 할인율이 가장 높은 리소스의 사용량부터 할인됩니다. 할인된 금액은 시간당 약정에서 차감됩니다. 시간당 약정이 소진되면 남은 사용량은 종량제 요금으로 청구됩니다.

 

이것은 시간 단위 약정이므로, 한 시간 동안 약정을 완전히 소모할 만큼 적격 사용량이 충분하지 않더라도 해당 시간 전체 약정에 대한 요금이 청구됩니다. 

 

그림 1 Azure 절약 계획: 절약을 위한 글로벌하고 유연하며 자동화된 경로

 

Azure 절약 계획 - 자동으로 유연하게 적용 

 

저축 플랜은 서비스나 지역에 관계없이 가장 큰 혜택을 볼 수 있는 사용량에 자동으로 약정을 적용합니다 [3] . 저축 플랜 할인율이 가장 높은 리소스의 사용량이 항상 우선적으로 적용되므로 약정을 적극적으로 관리할 필요가 없습니다. 저축 플랜은 사용자의 사용 패턴에 따라 자동으로 조정됩니다. 

 

절약 플랜은 특정 Azure 지역이나 컴퓨팅 서비스에 국한되지 않습니다. 절약 플랜은 Azure Virtual Machines 및 Azure App Service를 포함한 6개 이상의 컴퓨팅 서비스에 대한 비용 절감 혜택을 제공할 수 있습니다. 포함된 모든 컴퓨팅 서비스 목록을 보거나 Azure 가격 계산기 , Azure 가격 페이지 또는 Azure 가격표를 다운로드 하여 절약 플랜 가격을 확인하세요  

 

저축 플랜은 전체 EA 청구 계정(등록) 또는 MCA 청구 프로필, 또는 특정 관리 그룹, 구독 또는 리소스 그룹 [4] 에 할인 혜택을 제공하도록 구성할 수 있습니다 . 언제든지 저축 플랜의 범위를 변경할 수 있습니다. 

 

저축 플랜의 혜택 범위는 변경할 수 있지만, 시간당 약정이나 기간은 변경할 수 없습니다. 또한, 저축 플랜은 사용하는 컴퓨팅 서비스 변경에 따라 본질적으로 조정 가능하므로, 저축 플랜을 취소하거나 변경할 수 없습니다.  

 

그림 2 하나의 계획, 모든 위치: 저축 계획의 글로벌 힘

 

Azure 예약이란 무엇인가요? 

 

Azure 예약을 사용하면 1년, 3년 또는 5년 사용 약정을 하는 대가로 특정 Azure 리소스 사용량을 최대 72%까지 절약할 수 있습니다 [5] . 예약은 하루 종일 지속적으로 실행되고 하나의 Azure 지역에서 운영되며 향후 1년, 3년 또는 5년 동안 인프라 요구 사항을 실질적으로 변경할 것으로 예상되지 않는 워크로드에 이상적입니다. Azure 예약은 Azure Virtual Machines, Azure SQL 데이터베이스, Azure Cosmos DB를 포함한 다양한 Azure 서비스에 사용할 수 있습니다. 특정 지역에서 특정 Azure 제품을 일관되고 지속적으로 사용하는 경우 해당 제품에 대한 예약을 구매하면 전체 비용을 줄이는 데 도움이 될 수 있습니다.

 

예약 할인은 인프라 요금(예: CPU, RAM, 스토리지)에 적용되며 Azure 제품 및 지역에 따라 다릅니다. 할인 플랜과 마찬가지로 예약의 약정 기간에 따라 할인율이 결정됩니다. 예약은 할인을 제공하지만 리소스의 런타임 상태에는 영향을 미치지 않습니다. 예약 할인은 소프트웨어 라이선스 비용(예: Windows, Windows Server, SQL Server)에는 적용되지 않습니다. 그러나 Azure Hybrid Benefit을 통해 이러한 라이선스 비용을 절감할 수 있습니다. 

 

예약을 구매하면 선불로 결제하고 특정 지역에서 특정 Azure 제품을 사용하도록 약정하게 됩니다. 매 시간마다 종량제 사용량이 평가되지만, 종량제 요금 대신 선불 예약 혜택이 일치하는 리소스에 자동으로 적용됩니다. 일치하는 예약이 모두 소진되면 남은 사용량은 절약 플랜 모델(사용 가능한 경우) 또는 종량제 요금으로 청구됩니다. 예약은 시간 단위 약정이므로, 한 시간 동안 예약을 완전히 소진할 만큼 적격 사용량이 충분하지 않더라도 매 시간 예약 요금이 발생합니다.

 

예약 제품은 동일한 유형의 예약인 경우 서로 호환됩니다. 예를 들어 Azure Dedicated Host, Azure VMware Solution, Azure Virtual Machines를 포함한 여러 컴퓨팅 예약을 한 번에 서로 교환할 수 있습니다 [6] . 또한 SQL Managed Instance 및 Elastic Pool을 포함한 여러 SQL Database 예약 유형을 서로 교환할 수 있습니다. 하지만 서로 다른 유형의 예약은 교환할 수 없습니다. 예를 들어 Azure Cosmos DB 예약을 SQL Database로 교환할 수 없습니다.

 

다른 지역의 유사한 유형의 예약을 교환하여 구매할 수도 있습니다. 예를 들어, 미국 서부 2 지역의 예약을 서유럽 지역의 예약으로 교환할 수 있습니다. 

 

Azure Reservations – 예측 가능한 모든 워크로드에 대한 엄청난 할인 

 

Azure 예약은 안정적이고 지속적으로 실행되는 워크로드에 가장 비용 절감 효과가 큰 옵션입니다. 예약 기간 동안 인프라 요구 사항이 변경되지 않을 것으로 예상되는 워크로드는 안정적인 것으로 간주됩니다. 하루 종일 실행되는 워크로드는 예약에 적합한 후보일 가능성이 높습니다. Azure 예약은 컴퓨팅, 데이터베이스, 분석을 포함한 여러 Azure 제품에 사용할 수 있습니다.  

 

VM 예약은 가상 머신 예약 인스턴스(VM RI)라고도 합니다. 이러한 예약은 큰 할인과 함께 인스턴스 크기 유연성 [7] 을 통해 더 큰 유연성을 제공합니다 . 이 기능을 사용하면 예약 할인을 동일한 VM 크기 그룹의 다른 VM에 적용할 수 있습니다. 예를 들어 Standard_DS3_v2 VM 예약을 구매하는 경우 DSv2 시리즈의 다른 VM 크기(예: Standard_DS1_v2, Standard_DS2_v2, Standard_DS3_v2 또는 Standard_DS4_v2)에 예약을 적용하도록 선택할 수 있습니다.  인스턴스 크기 유연성에 대해 자세히 알아보려면  이 문서를 검토하세요.

 

앞으로  VM의 인스턴스 크기 유연성은  유지되지만, Azure Virtual Machine, Azure Dedicated Host 및 Azure App Service 예약에 대한 인스턴스 시리즈 또는 지역 교환은 더 이상 지원되지 않습니다. 자세한 내용은 이 문서를 참조하세요.

 

지원되는 모든 서비스 목록을 보거나 Azure 가격 계산기 , Azure 가격 페이지 또는 Azure 가격 목록을 다운로드 하여 예약 가격을 확인하세요  

 

저축 플랜과 마찬가지로, 예약은 전체 EA 청구 계정 또는 MCA 청구 프로필, 또는 특정 관리 그룹, 구독 또는 리소스 그룹에 할인 혜택을 적용하도록 구성할 수 있습니다. 예약 범위는 언제든지 변경할 수 있습니다. 

 

저축 계획과 예약을 비교하는 방법은? 

 

이제 저축 계획과 예약이 무엇인지 설명했으니, 이 둘을 비교하고 대조하여 어떤 점이 다른지, 그리고 클라우드 컴퓨팅 지출을 최적화하는 데 어떻게 도움이 될 수 있는지 알아보겠습니다. 

 

사용 패턴과 요구 사항에 따라 절약 플랜과 예약은 인프라 비용 절감에 도움이 되는 두 가지 옵션입니다 [8] . 두 옵션 모두 Azure Hybrid Benefit과 결합하여 Windows Server 및 SQL Server 라이선스 비용을 절감할 수 있습니다. 하지만 두 옵션 중 하나를 선택하기 전에 고려해야 할 주요 차이점도 있습니다. 

 



전세  저축 계획 
목표  계획된 변경 없이 동일한 지역에서 지속적으로 실행되는 작업 부하  다양한 지역에서 실행되는 동적/진화하는 워크로드 
선불제 대비 절감 효과  최대 72%까지 절약하세요  최대 65%까지 절약하세요 
약속  특정 지역에서 특정 제품 사용(예: 일본 동부의 D2v4 VM)  시간당 금액(예: $5/시간) 
혜택 명령  먼저 적용됨  적용된  
용어  1년, 3년 또는 5년  1년 또는 3년 
결제 옵션  선불 또는 월별  선불 또는 월별 
수정 사항 
  • 교환 예약 1 
  • VM, 전용 호스트 또는 앱 서비스 예약을 할인 플랜으로 교환하세요 
  • 예약 취소 2 
취소 불가 

1 예약 교환 정책의 향후 변경 사항에 따라 

2 회전 12개월 기간 동안 50,000달러 USD에 적용됨 

 

예시 

 

이 섹션에서는 다양한 시나리오와 가정을 기반으로 Azure 예약과 Savings Plan for Compute를 비교하는 두 가지 예를 제시합니다. 이 예는 각 옵션의 잠재적인 절감 효과와 장단점, 그리고 결정에 영향을 미치는 요소를 보여주기 위한 것입니다. 두 예 모두 워크로드가 하루 24시간 운영된다고 가정합니다. 다음 예에 사용된 가격은 2024년 5월 기준 Azure 가격 계산기에서 가져온 것입니다.

 

예 1: 예약 

 

이 예시에서는 워크로드가 미국 동부와 미국 서부, 두 지역에 분산되어 있습니다. 워크로드는 각 지역에 있는 가상 머신 인스턴스 2개와 Azure SQL 데이터베이스 2개로 구동되며, 이러한 리소스에는 계획된 변경 사항이 없습니다. 3년 기간으로 예약을 구매하면 가장 큰 절감 효과를 얻을 수 있습니다. 

 

예약 예상          
서비스 유형 지역 설명 PAYG 월 비용
3년 할인
월별 비용 월별 저축
가상 머신 미국 동부 4 D2 v3(2개 vCPU, 8GB RAM)(3년 예약), Windows(라이선스 포함), OS 전용; 0개 관리 디스크 - S4; 지역 간 전송 유형, 미국 동부에서 미국 서부로의 5GB 아웃바운드 데이터 전송 548.96달러 31% 376.18달러 172.78달러
가상 머신 미국 서부 4 D2 v3(2개 vCPU, 8GB RAM)(3년 예약), Windows(라이선스 포함), OS 전용; 0개 관리 디스크 - S4; 지역 간 전송 유형, 미국 서부에서 미국 동부로의 5GB 아웃바운드 데이터 전송 610.28달러 34% 416.86달러 193.42달러
Azure SQL 데이터베이스 미국 동부 단일 데이터베이스, vCore, 일반 용도, 프로비저닝됨, 표준 시리즈(Gen 5), 로컬 중복, 2-2 vCore 인스턴스, 3년 예약, 32GB 스토리지, RA-GRS 백업 스토리지 중복성, 0GB 시점 복원, 0 x 5GB 장기 보존 745.94달러 35% 501.46달러 244.48달러
Azure SQL 데이터베이스 미국 서부 단일 데이터베이스, vCore, 일반 용도, 프로비저닝됨, 표준 시리즈(Gen 5), 로컬 중복, 2-2 vCore 인스턴스, 3년 예약, 32GB 스토리지, RA-GRS 백업 스토리지 중복성, 0GB 시점 복원, 0 x 5GB 장기 보존 792.30달러 35% 523.38달러 268.93달러
    2,697.49달러   1,817.88달러 879.61달러
             
부인 성명            
표시된 모든 가격은 미국 달러(USD)로 표시됩니다. 이는 견적이 아닌 추정치입니다. 최신 가격 정보는 https://azure.microsoft.com/pricing/calculator 에서 확인하세요 .
이 추정치는 2024년 5월 21일 오전 8시 52분 39초 UTC에 작성되었습니다.

 

예약은 단일 리전에만 적용되고, 두 개의 서로 다른 리전에 컴퓨팅 및 데이터베이스 서비스가 있으므로 총 4개의 예약이 필요합니다. 4개의 예약을 통해 월 $879.61의 비용을 절감할 수 있으며, 이는 3년 동안 $31,665.96의 비용 절감으로 이어집니다.  

 

예 2: 컴퓨팅을 위한 절약 계획 

 

이 시나리오에서 저희 고객사인 Fabrikam은 미국 서부, 서유럽, 동아시아의 세 개 주요 지역에 운영 시스템을 구축했습니다. 각 지역은 핵심 워크로드를 전담하는 리소스를 보유하고 있어 지속적인 운영을 보장합니다.

 

각 지역에서 현지 업무 시간을 기준으로 8시간 동안 운영되도록 설계된 워크로드를 통해 Fabrikam은 각 지역의 비수기 시간대에 따른 비용 절감 효과를 누릴 수 있습니다. 이러한 접근 방식은 리소스 활용도를 최적화할 뿐만 아니라 "태양을 따라가는" 모델에 부합하여 전 세계 고객에게 원활한 서비스를 제공합니다.

 

Fabrikam은 컴퓨팅 절감 플랜을 도입함으로써 1년 또는 3년 동안 일정한 양의 컴퓨팅 사용량(시간당 $ 단위)을 확보합니다. 그 대가로 종량제 요금제 대비 상당한 할인 혜택을 받습니다. 다음 예시는 Fabrikam이 미국 서부, 서유럽, 동아시아에서 운영되는 앱 서비스를 포괄하는 컴퓨팅 절감 플랜을 어떻게 활용하는지 보여줍니다.

 

저축 계획 추정          
서비스 유형 지역 설명 8시간/일 급여 3년 할인 월 비용 8시간/일 월별 저축 시간당 약속
앱 서비스 미국 서부 프리미엄 V3 티어; 1 P3V3(8코어, 32GB RAM, 250GB 스토리지); 3년 절약 플랜; Windows OS; 0 SNI SSL 연결; 0 IP SSL 연결; 0 사용자 정의 도메인; 0 표준 SLL 인증서; 0 와일드카드 SSL 인증서 42.88달러 24% 32.80달러 10.08달러 1.025달러
앱 서비스 서유럽 프리미엄 V3 티어; 1 P3V3(8코어, 32GB RAM, 250GB 스토리지); 3년 절약 플랜; Windows OS; 0 SNI SSL 연결; 0 IP SSL 연결; 0 사용자 정의 도메인; 0 표준 SLL 인증서; 0 와일드카드 SSL 인증서 43.26달러 24% 33.02달러 10.24달러 1.032달러
앱 서비스 동아시아 프리미엄 V3 티어; 1 P3V3(8코어, 32GB RAM, 250GB 스토리지); 3년 절약 플랜; Windows OS; 0 SNI SSL 연결; 0 IP SSL 연결; 0 사용자 정의 도메인; 0 표준 SLL 인증서; 0 와일드카드 SSL 인증서 48.26달러 26% 35.74달러 12.51달러 1.117달러
    3,066.00달러   2,317.01달러 32.83달러 1.025달러
               
부인 성명              
표시된 모든 가격은 미국 달러(USD)로 표시됩니다. 이는 견적이 아닌 추정치입니다. 최신 가격 정보는 https://azure.microsoft.com/pricing/calculator에서 확인하세요.
이 추정치는 2024년 6월 19일 오후 12시 22분 34초 UTC에 작성되었습니다.

 

예시에서는 종량제 요금과 지역별 할인율이 약간씩 다르다는 것을 보여줍니다. 미국 서부 지역은 일반적으로 앱 서비스 요금이 가장 낮은 반면, 동아시아 지역은 26%로 다른 지역보다 할인율이 높습니다(24%). 저희 워크로드는 지역별로 8시간 동안 운영되며, 지역 간 전환 시 할인 혜택을 순환적으로 적용합니다. 사용량 부족을 방지하려면 최소 시간당 약정이 적용되는 단일 할인 플랜을 선택하는 것이 가장 좋습니다. 따라서 Compute Savings Plan에 시간당 $1.205의 요금을 선택하게 됩니다. 수동 계산은 필요하지 않습니다. Azure Advisor가 사용자의 요구 사항에 맞는 적절한 기준을 추천해 드리며, 구매 시 과거 데이터를 기반으로 시간당 약정 제안이 표시됩니다.

 

이 사례는 전략적 계획과 컴퓨팅 절감 계획(Savings Plans for Compute)을 활용하여 달성할 수 있는 재정적 이점과 운영 효율성을 보여줍니다. "태양 추적(Follow the Sun)" 모델을 효과적으로 구현하여 지속적인 글로벌 운영을 유지하면서 절감 효과를 극대화하는 방법을 보여줍니다.

저축 계획과 예약을 모두 활용하는 방법 

  • 다음 순서대로 Azure Advisor 권장 사항을 활용하세요. 
  • 적절한 크기/종료 VM 
  • 이전에 구매한 미활용 예약을 교환하세요.  
  • VM, 전용 호스트 및 앱 서비스 예약을 절약 플랜으로 교환하세요 
  • 추천에 따라 구매 예약 
  • 추천에 따른 구매 저축 계획 

 

Microsoft Azure Consumption Commitment(MACC) 할인을 고려하는 방법은 무엇인가요?

 

많은 기업 고객은 기존 Microsoft Azure Consumption Commitment(MACC) 할인 [9] 을 받았을 수 있습니다 . 이는 일반적으로 1년 또는 3년 동안 Azure 서비스에 특정 금액을 지출하겠다는 약정에 따라 적용되는 할인입니다. MACC 할인은 적격 Azure 서비스의 종량제 요금에 적용되며 약정 수준 및 계약 조건에 따라 달라질 수 있습니다. 그러나 MACC 할인은 저축 플랜 또는 예약 할인과 중복 적용되지 않습니다. 즉, 저축 플랜이나 예약을 구매하는 경우 저축 플랜 또는 예약 할인에 MACC 할인이 추가되지 않습니다. 대신 두 할인 중 더 높은 할인이 적용됩니다.

 

요약

 

이 글에서는 Azure 비용 절감에 도움이 되는 두 가지 옵션인 컴퓨팅 및 예약에 대한 Azure 절감 플랜을 비교하고 대조해 보았습니다. 주요 내용은 다음과 같습니다.

 

  • 저축 플랜은 컴퓨팅 서비스의 인프라 비용을 절감할 수 있는 유연하고 포괄적인 방법을 제공합니다. 적격 컴퓨팅 서비스, 인스턴스 유형 또는 리전에 자동으로 적용되며, 요구 사항에 따라 변경할 수 있습니다. 전체 청구 범위에 걸쳐 저축 플랜을 공유하고 언제든지 범위를 변경할 수 있습니다. 약정 금액은 언제든지 늘릴 수 있지만, 약정 기간 종료 전에는 약정 금액을 줄이거나 취소할 수 없습니다. 저축 플랜은 최대 65%까지 절감할 수 있으며, Azure 하이브리드 혜택과 결합하여 라이선스 비용을 추가로 절감할 수 있습니다.
  • 예약은 서비스 인프라 비용을 절감할 수 있는 예측 가능하고 안정적인 방법입니다. 선불 비용을 지불하면 특정 서비스, 인스턴스 유형 및 지역을 예약할 수 있습니다. 예약은 언제든지 취소하거나 변경할 수 있으며, 12개월 롤링 윈도우당 미화 50,000달러의 한도가 적용됩니다. 또한, 동일한 패밀리 내에서 인스턴스 크기를 변경하거나 동일한 지리적 영역 내에서 지역을 변경하여 예약을 수정할 수도 있습니다. 단, 컴퓨팅 서비스가 아닌 서비스로 예약을 변경하는 것은 특정 조건에서만 가능합니다. 예약을 사용하면 최대 72%까지 비용을 절감할 수 있으며, Azure 하이브리드 혜택과 결합하여 라이선스 비용을 추가로 절감할 수 있습니다.
  • 예약은 컴퓨팅 외에도 더 많은 서비스를 포괄하지만, 특정 서비스, 인스턴스 유형 및 리전에 종속되기 때문에 절약 플랜보다 유연성이 떨어집니다. 예약은 안정적이고 예측 가능하며 계획된 변경 사항이 없는 워크로드에 적합합니다.
  • 예약 인스턴스는 가상 머신을 대상으로 하는 예약 유형입니다. 특정 VM 크기와 지역을 예약하고 VM 비용 할인을 받을 수 있습니다. 예약 인스턴스는 웹 서버, 데이터베이스 또는 일괄 처리와 같이 지속적으로 또는 장기간 실행되는 워크로드에 적합합니다.
  • 절약 플랜과 예약을 결합하여 절약 효과와 유연성을 극대화할 수 있습니다. 예약은 안정적이고 예측 가능한 워크로드에 사용할 수 있으며, 절약 플랜은 동적이고 변화하는 워크로드에 적합합니다. Azure는 예약 할인을 먼저 적용한 후, 절약 플랜 약정이 완전히 소진될 때까지 남은 사용량에 대해 절약 플랜 할인을 자동으로 적용합니다. 두 옵션 모두 적용되지 않는 사용량은 종량제 요금으로 청구됩니다. 사용하는 서비스, 인스턴스 유형 및 지역에 따라 다양한 유형의 예약 및 절약 플랜을 조합하여 사용할 수 있습니다.
  • Microsoft Azure Consumption Commitment(MACC) 할인이 있다면, 할인 플랜이나 예약 옵션을 비교할 때 함께 고려해 보세요. MACC 할인은 적격 Azure 서비스의 종량제 요금에 적용되며, 약정 수준 및 계약 조건에 따라 달라질 수 있습니다. 단, MACC 할인은 Savings Plan이나 예약 할인과 중복 적용되지 않습니다. Savings Plan이나 예약 중 하나를 구매하는 경우, 두 할인 중 더 높은 할인을 받게 됩니다.

 

이 글이 Azure 컴퓨팅 및 예약 절감 플랜을 선택하는 방법과 이를 결합하여 클라우드 컴퓨팅 지출을 최적화하는 방법을 이해하는 데 도움이 되었기를 바랍니다. 질문, 의견 또는 공유하고 싶은 경험이 있으시면 아래에 댓글을 남겨주세요. 여러분의 의견을 기다립니다.

 

참고문헌

 

[1] Azure 컴퓨팅 절감 계획이란 무엇입니까? - Microsoft Cost Management | Microsoft Learn

[2] Windows Server용 Azure Hybrid Benefit | Microsoft Learn

[3] Azure 절약 계획 할인이 적용되는 방식 - Microsoft Cost Management | Microsoft Learn

[4] 저축 계획 범위 - Microsoft Cost Management | Microsoft Learn

[5] Azure 예약이란 무엇입니까? - Microsoft Cost Management | Microsoft Learn

[6] Azure Reservations에 대한 셀프 서비스 교환 및 환불 - Microsoft Cost Management | Microsoft Learn

[7] 가상 머신 크기 유연성 -Azure Reserved VM Instances - Azure Virtual Machines | Microsoft Learn

[8] 저축 계획과 예약 중에서 결정 - Microsoft Cost Management | Microsoft Learn

[9] Microsoft Azure 사용 약정(MACC) 추적 - Microsoft 비용 관리 | Microsoft Learn

728x90
728x90

인수 합병은 일반적이지만 설계자, 영업 및 계정 팀이 두 조직 모두 Azure를 사용할 때 Azure 구독의 이동이 어떻게 발생하는지에 대한 질문을 받을 때 때때로 어려움을 겪는 것을 보았습니다. 이는 동일한 Azure AD 테넌트 내에서 또는 Azure AD 테넌트 이동 간에 있을 수 있습니다. 우리 중 몇 명은 때때로 구독이 이미 시행된 후에 참여하기 때문입니다.

 

다양한 유형의 마이그레이션을 살펴보기 전에 Microsoft 기업계약 계층 구조를 간략하게 요약해 보겠습니다.

 

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

 

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

 

가장 좋은 방법은 Microsoft 계정이 아닌 회사 및 학교 계정을 제공하는 것입니다. 사람이 언제 조직을 떠날 때를 생각해 보십시오. 😊

 

 

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

   비기술적 마이그레이션: 다운타임 없이 구독에 있는 리소스에 영향을 주지 않고 백 엔드에서 발생합니다.

   기술 마이그레이션: 여기에는 구독에 있는 전체 리소스를 평가하고 리소스를 다른 구독으로 이동할 수 있는지 여부를 확인하는 작업이 포함됩니다. 각 자원은 개별적으로 평가되며 한 자원이 다른 자원에 대한 종속성을 확인합니다.

 

시나리오:

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

  서로 다른 두 EA 등록 간 이동

   1a. 첫 번째 단계

   1b. 두 번째 단계

   동일한 EA 등록 내의 EA 계정 간에 구독 이동

   한 테넌트에서 다른 테넌트로 Azure 구독 이동

    3a. 방법 1(디렉터리 변경

    3b. 방법 2(다시 만들기)

    3c. 방법

    3(ASR)

     CSP에서 EA로 구독 이동

     PAYG 구독을 EA로 이동

     MCA-Enterprise 구독을 EA로 이동

 

1. 서로 다른 두 EA 등록 간에 이동합니다.

이 시나리오에서 고객은 활성 EA 등록을 가지고 있으며 이 고객은 활성 EA 등록이 있는 Azure에도 있는 다른 엔터티 B를 획득했습니다. 둘 다 Azure에 있으므로 고객 A는 엔터티 B Azure 배포를 인수하려고 합니다. 고객은 단일 파트너를 통해서만 Microsoft에 지불하려고 합니다. 따라서 이러한 이동 필요성이 발생합니다. 또한 두 번째 요구 사항은 고객이 단일 랜딩 존을 통해 리소스를 관리할 수 있도록 여러 Azure AD 테넌트 및 단일 Azure AD 테넌트로 리소스를 병합하기 때문일 수 있습니다.

제 생각에는 합병을 두 단계로 나누는 것이 좋습니다. 첫 번째는 구독 이동(청구 전용)이고 두 번째 단계는 테넌트의 리소스 병합입니다.

 

1a. 첫 번째 단계:

(유형:NontechnicalMigration) 한 등록에서 다른 등록으로 구독 이동은 백 엔드에서 발생할 수 있습니다. 이 백 엔드 이동에는 구독 리소스에 대한 가동 중지 시간이 발생하지 않습니다. 원본 구독이 이동할 대상 EA 계정이 있어야 합니다. 고객은 MS 구독 관리 팀에 지원 사례를 제기하고 이메일을 통해 필요한 승인을 제공해야 합니다. 테넌트가 동일하게 유지된다는 것을 지원 엔지니어에게 알려야 합니다.

 

참고: 계정 소유자에게 사용되는 이메일 주소는 구독이 연결될 테넌트였습니다. 예를 들어 전자 메일이 Aquib.qureshi@contoso.com 경우 이 계정으로 만들어지는 모든 구독이 Azure AD 테넌트 contoso.com 매핑됩니다.

 

따라서 대상 Azure AD 테넌트에서 리소스를 이동하지 않으려는 것을 지원 팀에 알려야 합니다. 구독의 Azure AD 테넌트가 RBAC를 변경하면 Azure AD 앱 등록 및 구독의 많은 Azure AD 종속 서비스가 영향을 받을 수 있기 때문에 중요합니다.

 

하나의 Azure EA 등록에 둘 이상의 Azure AD 테넌트가 있을 수 있다고 생각하시나요? 대답은 예, 등록에는 임차인에 대한 제한이 없습니다. 하나의 등록에는 여러 EA 계정이 있을 수 있으며 각 계정에는 고유한 Azure AD 테넌트가 있을 수 있습니다. (여러 디렉토리를 관리하는 것이 쉽지 않기 때문에 선호되지 않습니다) 이 시나리오에서 엔터티 B에는 자체 Azure AD 테넌트가 있고 회사 A에는 이동 후 단일 Azure AD 등록에 상주하는 Azure AD 테넌트도 있습니다.

 

테넌트 외에도 명심해야 할 다른 사항은 원본 등록에서 구입한 예약 인스턴스입니다. 통화 A의 RI가 있는 구독을 이전하고 대상 EA 등록이 다른 통화 B로 구매된 경우 대상 EA 등록을 동시에 여러 통화로 청구할 수 없으므로 RI가 자동으로 취소됩니다.

 

 

1b. 두 번째 단계:

(유형:technicalMigration) 단일 Azure AD 테넌트에서 리소스 병합. 이 단계는 청구가 마이그레이션되면 실행됩니다. 앞서 언급했듯이 이는 각 리소스를 평가해야 하는 기술 마이그레이션입니다. 임차인 변경은 다양한 방법으로 처리할 수 있습니다. 3번 항목에서 자세히 설명하겠습니다.

 

 

2. 동일한 EA 등록 내의 EA 계정 간에 구독을 이동합니다.

(유형:NonTechnicalMigration) 이 시나리오는 한 명의 EA 계정 소유자가 사임하고 모든 구독을 인수하고 다른 EA 계정으로 이동하려는 경우에 발생할 수 있습니다. 이 단계는 쉽고 Azure Portal을 통해 수행할 수 있으며 MS에 지원 사례를 제기할 필요가 없습니다.

 

포털에 표시되는 동일한 대상 Azure AD 테넌트 확인 표시이며, 구독을 대상 Azure AD로 전송하지 않으려면 선택을 취소할 수 있습니다.

 

3. 한 테넌트에서 다른 테넌트로 Azure 구독 이동:

(유형:TechnicalMigration) 테넌트를 변경해야 하는 필요성은 여러 가지 이유로 발생하며, 첫 번째는 고객이 방화벽, WAF 및 네트워크 연결을 사용하여 배포된 랜딩 존을 가지고 있으며, Azure Policy는 고객 A Azure 배포의 다른 관리 그룹에 있는 BU 분리와 함께 구성되었습니다. 엔터티 B가 병합됨에 따라 고객 A의 IT 팀은 현재 Azure 배포를 관리하는 것과 유사한 방식으로 엔터티의 Azure 리소스를 관리하려고 합니다. 테넌트를 공존시키면서 더 나은 작업을 활용할 수 있는 여러 가지 방법이 있으므로 리소스를 단일 Azure AD 테넌트에 직접 병합하는 것으로 넘어서는 안 됩니다. 아래에서 몇 가지 방법을 강조하고 있습니다.

 

두 개의 Azure AD 테넌트가 있다는 것은 두 개의 서로 다른 사용자 리포지토리를 의미합니다. 고객 A 사용자가 엔터티 B의 Azure 구독을 관리하려고 할 때마다 사용자를 게스트로 초대한 다음 해당 게스트 사용자를 참가자 또는 관련 역할로 제공하여 Azure 리소스를 관리할 수 있도록 할 수 있습니다. 최근에는 두 Azure AD 테넌트 간의 사용자 동기화가 릴리스되어 사용자를 수동으로 초대할 필요가 없으며 자동화할 수 있습니다.Azure Lighthouse를 사용하여 서로 다른 두 Azure 테넌트에서 Azure 배포를 운영적으로 관리할 수 있습니다. 나는 이 주제에 대한 블로그를 썼습니다.엔터티 B가 허브 및 스포크 배포 모델을 사용하는 경우 vnet 피어링을 수행하고 방화벽, WAF 등이 있는 고객 A의 허브 네트워크를 활용할 수 있습니다.

 

Azure AD 테넌트 병합으로 이동하지 말고 테넌트와 리소스를 공존시켜야 하는 몇 가지 이유는 다음과 같습니다. 모든 서비스가 다중 테넌트를 지원하는 것은 아니지만 엔터티 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을 수행하는 방법과 같이 장애 조치(failover)할 수 있습니다. 장애 복구를 수행할 가능성이 높습니다.

 

 

3c. 접근 방식 3(ASR):이 방법은 많은 사람들이 이 방법을 알지 못하기 때문에 덜 채택되고 VM 워크로드가 많은 경우에만 사용할 수 있습니다. ASR을 사용하여 서로 다른 두 테넌트 간에 복제할 수 있습니다. 원본 구독을 물리적 서버 배포로 간주하고 VNET에 어플라이언스를 배포한 다음 엔터티 B의 구독에서 호스트되는 VM에 에이전트를 푸시합니다. VM을 고객 A의 구독에 복제할 수 있습니다. 이는 Azure에서 Azure로의 ASR 시나리오와 동일하지 않지만 해결 방법입니다.

 

 

4. CSP에서 EA로 구독 이동:

(유형:TechnicalMigration) MS 지원은 백 엔드에서 구독을 이동할 수 없으며, 일반적으로 CSP 구독은 CSP 파트너가 만든 다른 테넌트에 상주하며 CSP에서 테넌트 변경이 불가능하므로 유일한 옵션은 리소스를 다시 만들어 이동하거나 ASR 접근 방식 3을 사용하는 것입니다.

 

 

5. PAYG 구독을 EA로 이동:

(유형:NonTechnicalMigration) 고객이 신용 카드를 통해 구매한 PAYG 구독. 이 구독은 다운타임 없이 백엔드의 EA 청구로 가져올 수 있습니다. 테넌트를 변경하려면 이전 섹션에서 언급한 단계를 따라야 합니다.

 

 

6. MCA-Enterprise 구독을 EA로 이동합니다.

(유형:NonTechnicalMigration) MCA는 미래이기 때문에 이는 흔하지 않은 접근 방식입니다. 그러나 MS 거버넌스 팀에 요청을 제기하여 MCA-Enterprise에서 EA 등록으로 이동할 수 있습니다. MS 거버넌스 팀과 연결하려면 계정 팀에 문의해야 합니다. 거버넌스 지원 팀에 정당성을 제공해야 해당 팀이 이 이동을 실행할 수 있습니다. 이것은 다운타임 없이 완전히 백엔드 이동입니다.

 

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

 

다음은 동료 동료의 몇 가지 유용한 링크입니다.

   Elan Shudnow: 아래 링크는 동일한 테넌트 내에서 한 구독에서 다른 구독으로 리소스를 이동하는 경우 도움이 될 수 있습니다.

   리소스 그룹 또는 리소스 이동기에서 이동 작업을 사용할 수 있습니다. 그러나 리소스가 이동 작업을 지원하는지 여부를 확인하려

   면 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

 

 

즐거운 학습 되세요!

 

 

 

 

 

 

 

 

 

 

728x90
728x90

점점 더 많은 고객이 Azure VMware Solution을 마이그레이션 대상으로 탐색하도록 요청하고 있으므로 많은 설계자와 사전 영업 담당자의 가장 일반적이고 첫 번째 문제 중 하나를 해결하는 것에 대해 생각했습니다. Azure VMware Solution 노드의 크기를 조정하는 방법은 무엇인가요? AVS 설계와 관련된 네트워크 설계 및 구성 요소에 대해 알아보기 전에. 대부분의 경우 고객은 온프레미스 워크로드에 맞는 데 필요한 노드 수와 해당 노드의 비용을 결정해야 합니다.이 블로그 전체에서 vCPU, 메모리 및 스토리지에 초점을 맞추는 이유는 무엇입니까? 예를 들어 AV36p의 한 노드에는 36개의 물리적 코어, 768GB 메모리 및 19.20TB NVMe 스토리지가 있습니다. 배포에 필요한 노드 수를 확인해야 합니다. 그리고 이를 기반으로 노드를 계속 추가할 것입니다.

 

여러 노드 유형의 사양은 여기에 언급되어 있습니다 https://learn.microsoft.com/en-us/azure/azure-vmware/introduction#hosts-clusters-and-private-cloudsAVS 

 

노드의 크기를 조정하려면 두 가지 주요 방법이 있습니다.

  수동 방법: 이 방법은 주로 사용 중인 vCPU, 메모리 및 스토리지 수를 기준으로 AVS 노드의 크기를 조정하는 것입니다. 따라서 

  기본적으로 VMware 클러스터의 현재 크기에 따라 AVS 노드의 크기를 조정합니다. VM에 16개의 vCPU가 있지만 4개만 활용하

  는 경우 실제 사용률이 아닌 AVS 노드의 전체 크기 조정에서 여전히 16개의 vCPU를 고려하기 때문에 예산 크기 조정이 될 수도

  있습니다.

  Azure Migrate 방법: 이 방법에서는 Azure Migrate와 같은 도구를 사용하여 평균 또는 최대 부하를 기반으로 VM의 사용률을 

  계산하고 이를 기반으로 AVS 노드의 크기를 정확하게 조정하는 데 도움이 됩니다. VM에 대해 16개의 vCPU를 구성했지만 4개만

  활용하더라도 4개의 vCPU만 고려하기 때문에 이 크기는 적절한 크기입니다. 따라서 사이즈는 정확하고 올바른 사이즈입니다.

  사용 가능한 또 다른 방법은 RVTools 가져오기 기반 평가입니다. 이것은 수동 방법으로 달성하는 것과 마찬가지로 있는 그대로의    크기 조정입니다. 이것은 UI 중심이며 수동 계산이 포함되지 않습니다.

 

어플라이언스 기반 방법과 관련된 단점은 일정 기간 동안 도구를 실행하고 성능 메트릭을 캡처하는 데 시간이 필요하다는 것입니다. AVS 노드의 즉각적인 크기 조정을 원하거나 예산 견적이 필요한 경우 있는 그대로의 크기 조정을 사용할 수 있습니다.

 

수동 방법을 사용하여 있는 그대로 크기를 조정하고 VMware 환경에 있는 모든 VM의 vCPU, 메모리 및 스토리지 사용률을 캡처하려면 RVTools가 이상적인 도구로 눈에 띕니다.

 

수동 방법

대부분의 VMware 관리자는 RVTools를 통해 VMware 클러스터를 내보내는 방법을 알고 있으며, 그렇지 않은 경우 웹 사이트에서 도구를 다운로드할 수 있습니다 https://www.robware.net/home 필요한 세부 정보가 포함된 'vminfo'를 포함하여 여러 탭을 찾을 수 있습니다. 이 탭에서 관련 숫자를 합산합니다.

 

CPU: VM과 연결된 vCPU를 표시합니다.

메모리: 할당된 메모리가 포함됩니다.

In-use-MiB: 현재 사용된 스토리지를 보여줍니다.

프로비저닝된 MiB: 할당된 스토리지가 포함됩니다. 외부 스토리지의 도움으로 요구 사항에 따라 스토리지를 확장할 수 있으므로 이 열은 고려하지 않으므로 In-use-MiB만 고려합니다.

 

AVS 노드 크기 조정:

총 vCPU, 메모리 및 사용 중인 스토리지를 얻으면 이를 Azure 노드가 제공할 수 있는 것과 비교해야 합니다. 예를 들어 보겠습니다. AVS 노드의 3개 노드(최소)는 아래 크기를 제공합니다. CPU 및 메모리 요구 사항에 따라 그에 따라 배포 크기를 조정해야 합니다. 스토리지 고려 사항은 약간 다르며 다음 섹션에서 노드에서 사용 가능한 공간을 계산하는 방법에 대해 자세히 살펴보겠습니다. 그러나 노드 크기를 조정하는 동안 주로 vCPU 및 메모리를 고려해야 하는데, 그 이유는 Azure NetApp 파일 또는 Azure Elastic SAN과 같은 원격 스토리지 옵션을 사용하여 스토리지를 확장할 수 있기 때문입니다. 이 시나리오에서는 스토리지 요구 사항에 맞게 노드 수를 확장할 필요가 없습니다.

 

이제 rvtools 크기에 따라 필요한 총 vCPU, 메모리 및 스토리지를 얻은 다음 요구 사항에 따라 AVS 노드 수의 크기를 조정할 수 있습니다.

 

 

스토리지 크기 조정:

AVS 노드에서 RAW 스토리지를 가져오며 사용 가능한 공간은 아래에 언급된 여러 요인에 따라 달라집니다.

  VM 스토리지 정책을 생성하는 동안 선택하는 RAID(RAID 1, 5 또는 6)

  스토리지 정책 중에 선택한 FTT(FTT 1, 2 및 3)

  사용 가능한 Slack 공간(SLA를 받으려면 최소 25%의 여유 공간이 필요함)

  체크섬(평균 5%)

  공간 효율성 비율(평균적으로 1.50이지만 저장되는 데이터와 얻을 수 있는 공간 효율성에 따라 다릅니다. 증가할 수도 있습니다)

  AVS의 스토리지 및 고려 사항에 대해 더 알고 싶다면 이 주제에 대한 이전 블로그를 참조할 수 있습니다.

https://www.azuredoctor.com/posts/Demystifying-Storage-types-in-AVS/

 

위에서 언급한 요인으로 인해 사용 가능한 공간이 달라집니다. 빠른 계산을 위해 가장 유용한 스토리지를 제공하는 AV36P에 대한 RAID 크기 조정을 아래에 캡처했습니다. FTT를 2에서 3으로 늘리려면 사용 가능한 스토리지는 줄어들지만 복원력은 더 높습니다. AVS의 SLA에 따라 노드가 6개 이상인 경우 최소 FTT 2를 선택해야 합니다.

고려 사항:-

체크섬: 5%

여유 공간: 25%

공간 효율 비율: 1.50

 

크기 조정의 예

AVS 노드 수를 얻는 방법에 대한 한 가지 예를 들어 보겠습니다. rvtool 후 500개의 vCPU와 3.5TB 메모리가 필요하며 90TB의 사용 가능한 스토리지가 필요하다는 것을 알게 되었습니다. AVS 크기 조정을 위해 AV36p SKU를 고려합니다. 이와 함께 1:4의 CPU 오버커밋을 고려할 것입니다. 따라서 1:4 오버커밋으로 500개의 vCPU를 맞으려면 4개의 노드, 36 x 4 = 144개의 물리적 코어, 144 x 4 = 576개의 vCPU가 필요합니다. 그러나 AVS AV36p의 4개 노드를 사용하면 768 x 4 = 3072GB의 메모리만 얻을 수 있습니다. 따라서 3.5TB의 메모리에 맞는 추가 노드가 하나 필요하므로 메모리가 4개의 노드를 선택할 때 병목 현상이 발생하기 때문에 총 5개의 AV36p 노드가 필요합니다. 5개의 AVS 노드를 사용하면 최대 77.6TB의 사용 가능한 스토리지만 제공되므로 ANF 또는 ESAN에서 추가 스토리지를 얻을 수 있습니다. 따라서 크기를 고려해야 하는 외부 저장소는 12.37TB입니다. 여기 있어. 전체 마이그레이션에 필요한 5개의 AV36p 노드입니다.

그러나 이는 크기가 있는 그대로이고 CPU 세대 및 NVMe 스토리지에 따라 실제 요구 사항이 감소할 수 있습니다. 기본적으로 배포 중에 3노드의 최소 클러스터 배포로 시작하여 VM을 마이그레이션하고 더 많은 메모리와 vCPU가 필요할 때 노드 수를 늘리기 시작합니다.

 

Azure Migrate 기반 크기 조정

수동 방법을 사용하여 수행한 위의 크기 조정은 Azure Migrate를 사용하여 보다 자동화된 방식으로 크기를 조정할 수 있습니다. Azure Migrate를 통해 수행하는 경우에도 스토리지 크기 조정 및 CPU 오버 커밋에 대한 메트릭 및 매개 변수는 동일하게 유지됩니다. 

Azure Migrate를 사용하여 수행할 수 있는 AVS 크기 조정에는 두 가지 주요 유형이 있습니다.

어플라이언스 기반: Azure Migrate 어플라이언스를 설치하고 성능 평가 또는 있는 그대로 크기 조정 내보내기

가져오기 기반: rvtools 내보내기가 있는 경우 있는 그대로의 크기 조정을 제공하는 Azure Migrate 프로젝트에서 Excel 파일을 가져올 수도 있습니다.

 

 

어플라이언스 기반

첫 번째 옵션에 대해 이야기해 보겠습니다., 이는 대상이 Azure VM일 때 사용된 프로세스와 매우 유사합니다.

즉, Azure Migrate 어플라이언스를 설치하고, vCenter Server 세부 정보를 추가하고, VM의 성능 기록을 수집하도록 합니다. 여기서 유일한 변경 사항은 Azure VM 기반 평가 보고서를 만드는 대신 AVS 평가를 선택한 다음 크기 조정을 위한 매개 변수를 제공해야 한다는 것입니다. 여기에서 vCPU, VM의 메모리 성능을 확인한 다음 AVS 노드에 대한 권장 사항을 제공하는 성능 기반 평가를 수행할 수 있습니다. 있는 그대로 원하는 경우 이를 수행하고 현재 vCPU 및 VM의 메모리를 기반으로 AVS 노드 수를 제공할 수도 있습니다.

 

Azure Migrate 기반 어플라이언스를 사용하여 모든 서버를 검색했다고 가정하면 평가를 만드는 방법으로 이동합니다.

AVS 평가를 선택합니다.

검색 원본이 Azure Migrate Appliance로 선택되어 있는지 확인합니다.

 

출력이 이러한 선택을 기반으로 하므로 올바른 매개변수 세트를 선택했는지 확인합니다.

 

평가할 서버를 선택합니다.

 

AVS 평가가 생성된 후 보고서의 출력입니다. 그러면 필요한 노드 수와 스토리지도 표시됩니다.

 

 

가져오기 기반

이는 RVTools 가져오기 방법을 기반으로 하는 그대로의 크기입니다. 스토리지 및 노드에 필요한 수동 계산은 없습니다. 

Azure Migrate 프로젝트에서 가져와야 하는 rvtool 내보내기 데이터가 필요하며 필요한 AVS 노드 크기 조정 및 스토리지를 제공하기 위해 계산을 수행합니다. Azure Migrate를 통해 이루어지지만 이 방법에는 어플라이언스 설치가 필요하지 않습니다. 현재 미리 보기로 제공됩니다.

평가를 생성하기 전에 이러한 모든 서버가 검색된 서버 아래에 표시되도록 RVtools를 가져와야 합니다.

 

RVTools의 미리보기 옵션 선택

 

검색된 서버가 rvtools 데이터로 채워져 있음을 알 수 있습니다.

 

이제 다시 한 번 평가를 만들지만 이번에는 Azure Migrate 어플라이언스 대신 가져온 서버를 선택합니다.

 

 

서버 선택.

 

평가 만들기.

 

이제 평가 화면의 출력에 AVS 평가 수가 1로 표시됩니다.

 

이 화면에는 생성된 총 평가 수가 표시됩니다.

 

평가를 열면 스토리지와 함께 필요한 AVS 노드의 전체 크기가 표시됩니다.

 

 

Azure 가격 계산기를 사용하여 AVS 비용 계산

이 섹션에서는 Azure 가격 계산기를 통해 샘플 AVS 크기 조정을 수행해 보겠습니다. 

여기에 Express Route Gateway, Azure Route 서버 또는 방화벽과 같은 네트워킹 구성 요소를 추가하지 않고 랜딩 존이 구성되고 준비되기를 바라며 AVS 비용 자체를 추정하고 있습니다.

 

 

 

https://azure.com/e/e39866f1330f4aa1b7b84e582940fb88이 블로그가 AVS 노드 평가에 도움이 되기를 바랍니다. 이 작업이 완료되면 네트워크 토론 및 전체 마이그레이션 계획을 빠르게 시작할 수 있습니다.즐거운 학습 되세요!

 

 

 

 

 

 

 

 

 

 

 

 

 

 

728x90
728x90

VMware HCX를 사용하여 Azure VMware 솔루션으로 워크로드 마이그레이션: 실용 가이드

VMware HCX를 직접 사용해 본 경험을 바탕으로, 최근 금융 서비스 회사와의 프로젝트 계획의 일환으로 Azure VMware Solution(AVS)에 대해 몇 주 동안 조사했습니다. 해당 고객은 여러 클러스터에 걸쳐 500개의 VM이 있는 온프레미스 VMware 환경을 AVS로 마이그레이션하고자 합니다. 핵심 애플리케이션 리팩토링 없이 데이터 센터를 대피시키려는 목표 때문입니다. 이 블로그 게시물 "VMware HCX를 사용하여 Azure VMware Solution으로 워크로드 마이그레이션: 실무 가이드" 에서는 제가 조사한 내용을 바탕으로 실용적이고 구체적인 계획을 제시하고 이러한 유형의 마이그레이션에 대한 접근 방식을 제시합니다. 자세한 설명은 생략하고, 전략, 아키텍처, 도구, 연구를 통해 얻은 교훈, 그리고 피해야 할 함정에 대해 중점적으로 설명하겠습니다. 이 글은 VMware HCX를 사용하여 온프레미스 환경에서 Azure VMware Solution으로 워크로드를 마이그레이션하려는 모든 분들을 위해 작성되었습니다.

마이그레이션 계획의 토대를 마련하기 위해 AVS와 HCX의 기본 사항을 먼저 살펴보겠습니다.

Azure VMware 솔루션 및 VMware HCX 이해

마이그레이션 계획을 논의하기 전에 AVS와 HCX가 제공하는 서비스를 명확하게 이해하는 것이 중요합니다. 많은 전문가들이 관련된 세부적인 사항들을 과소평가하여 마이그레이션 계획 과정에서 오해와 실수를 저지르게 됩니다.

AVS는 Azure에 호스팅되는 전용 VMware 소프트웨어 정의 데이터 센터(SDDC) 환경을 제공하는 Microsoft 관리 서비스입니다. 컴퓨팅을 위한 vSphere, 스토리지를 위한 vSAN, 네트워크 가상화를 위한 NSX-T 등 익숙한 구성 요소를 포함합니다. 이 환경은 베어 메탈 서버에 호스팅되며 Azure SQL 또는 Azure AD와 같은 네이티브 Azure 서비스와 통합할 수 있습니다. AVS는 온프레미스 VMware 환경을 미러링하므로 고객이 워크로드를 재설계하지 않고도 데이터 센터를 확장하거나 이전할 수 있는 잠재적인 옵션입니다.

VMware HCX는 마이그레이션의 엔진입니다. 대량 VM 이동, 라이브 마이그레이션, 재해 복구 및 네트워크 확장을 위한 도구를 제공하며, 대역폭 사용량을 줄이기 위한 WAN 최적화(압축 및 중복 제거)와 같은 기능도 제공합니다. HCX는 IP 주소를 변경하거나 복잡한 종속성을 재구성하지 않고도 워크로드를 이동할 수 있으므로 AVS(애플리케이션 보안 시스템) 프로젝트에 특히 유용합니다. 제가 사용할 주요 HCX 마이그레이션 방법은 다음과 같습니다.

  • vMotion : 가동 중인 VM을 다운타임 없이 라이브 마이그레이션합니다. 대역폭에 민감하므로 신중한 계획이 필요합니다.
  • 대량 마이그레이션 : 최소 컷오버 다운타임(~분)으로 예약된 복제를 수행합니다. 대용량 작업에 적합합니다.
  • 복제 지원 vMotion(RAV) : 사전 시딩과 vMotion을 결합하여 데이터베이스와 같은 대규모의 높은 변경률의 VM을 지원합니다.
  • 콜드 마이그레이션 : 마이그레이션 전에 전원을 끌 수 있는 VM의 경우 레거시 또는 테스트 워크로드에 자주 사용됩니다.
  • OS 지원 마이그레이션(OSAM) : 물리적 서버나 Hyper-V 워크로드를 vSphere로 마이그레이션하는 데 사용됩니다.

올바른 마이그레이션 유형을 선택하는 것이 중요합니다. 중요한 워크로드에는 vMotion을, 일반 VM에는 Bulk를, 그리고 vSphere가 아닌 환경처럼 필요한 경우에만 OSAM을 혼합하여 사용하는 것을 권장합니다. 참고로, 아래 비교표를 참고해 보세요.

이러한 기술을 미리 이해하면 불필요한 위험과 다운타임을 방지하는 데 도움이 됩니다. 이는 복잡한 프로젝트를 시작하기 전에 도구를 미리 아는 것과 같습니다. 성공으로 가는 지름길입니다. 이러한 기반을 마련한 후, 다음 단계는 고객 환경을 면밀히 평가하여 마이그레이션 준비 상태를 확인하는 것입니다.

이주 전 평가

적절한 탐색 단계는 모든 성공적인 AVS 마이그레이션의 기반입니다. 제 연구에 따르면 이 단계를 건너뛰거나 서두르면 심각한 문제가 발생할 수 있으므로, VMware 네이티브 도구와 Azure 네이티브 도구를 함께 사용하여 고객 환경을 분석하는 데 충분한 시간을 할애하여 준비 상태를 유지하는 것이 좋습니다.

저는 다음과 같은 방식으로 평가에 접근하기를 제안합니다.

  • VM 인벤토리 및 크기 조정 : RVTools 또는 vRealize Operations를 사용하여 CPU, RAM, 디스크 및 스냅샷 정보를 수집합니다. Azure Migrate는 크기 권장 사항을 생성하고 레거시 OS 버전과 같이 지원되지 않는 구성을 플래그로 지정할 수 있습니다.
  • 애플리케이션 종속성 매핑 : Azure Migrate의 종속성 시각화를 활용하여 최소 30일 동안 실행하여 트래픽 흐름을 파악합니다. 이를 통해 문서화되지 않은 MSSQL 인스턴스에 백엔드 호출을 수행하는 레거시 웹 서버와 같은 숨겨진 종속성을 파악할 수 있습니다.
  • 호환성 검사 : vSphere 버전(6.5 이상), 가상 하드웨어 호환성, OS 지원 및 네트워크 토폴로지를 확인하세요. 검증을 위해 VMware 상호 운용성 매트릭스 및 HCX 설명서를 활용하세요.
  • 워크로드 분류 : 미션 크리티컬, 프로덕션, 개발, 보관 등의 범주로 워크로드를 분류합니다. 이를 통해 단계별 마이그레이션 및 롤백 옵션을 계획하는 데 도움이 됩니다.
  • 특수 워크로드 : 원시 장치 매핑(RDM), PCI 패스스루 장치 또는 HCX 복제 제한(일반적으로 8TB)을 초과하는 대용량 디스크 등 추가 계획이 필요한 VM을 파악합니다. 문제 발생을 방지하기 위해 RDM을 VMDK로 변환하는 것을 계획합니다.
  • 규정 준수 평가 : 규정 준수를 보장하기 위해 GDPR이나 HIPAA와 같은 요구 사항을 Azure 정책에 매핑합니다.

철저한 마이그레이션 전 평가는 마치 집을 짓기 위한 기초를 다지는 것과 같습니다. 이 부분이 제대로 된다면 나머지 마이그레이션은 훨씬 더 수월해집니다. 중요한 것은 잠재적인 장애물을 조기에 파악하는 것입니다. 평가가 계획되었으니, 이제 HCX 통합을 위한 온프레미스 환경을 준비하는 단계로 넘어가겠습니다.

온프레미스 환경 준비

발견 단계가 완료되면 다음 단계는 HCX 통합을 위해 고객의 온프레미스 인프라를 준비하는 것입니다. 이 단계는 대부분 기술적인 내용이지만, 지연으로 인해 일정이 지연되는 것을 방지하기 위해 네트워크 및 방화벽 팀과 조기에 협력하는 것이 좋습니다.

제가 제안하는 준비 계획은 다음과 같습니다.

  • HCX 커넥터 배포 : vSphere 환경에 HCX 커넥터 OVA를 배포합니다. vCenter 및 NSX Manager에 등록하고, 서비스 메시 설정을 진행하기 전에 등록이 완료되었는지 확인합니다.
  • 네트워크 구성 및 준비 :
    • 온프레미스 사이트와 AVS 환경 간의 레이어 3 연결을 검증합니다.
    • 모든 HCX 어플라이언스 간에 필수 포트(TCP 443, UDP 4500)를 엽니다.
    • vCenter, HCX 및 NSX 구성 요소에 대한 DNS 확인을 양방향으로 보장합니다.
    • 인증이나 복제에 영향을 미치는 시간 편차 문제를 방지하려면 NTP 설정을 동기화하세요.
  • 워크로드 그룹화 : 애플리케이션, 종속성 및 비즈니스 기간을 기준으로 논리적 마이그레이션 그룹을 생성합니다. 이를 통해 웹 서버와 데이터베이스를 그룹화하는 등 마이그레이션 계획 수립 및 테스트가 간소화됩니다.

온프레미스 환경을 철저히 준비하는 것이 전체 마이그레이션의 토대를 마련합니다. 시간 동기화 문제와 같은 사소한 실수가 문제 해결에 몇 시간씩 소요될 수 있으므로, 세부 사항에 대한 주의가 매우 중요합니다. 이제 환경이 준비되었으니, 마이그레이션 아키텍처를 설계할 전략적 계획 단계로 넘어가겠습니다.

VMware에서 AVS로의 마이그레이션을 위한 전략적 계획

전략적 계획은 마이그레이션이 구체화되는 단계입니다. 이 단계에서는 네트워킹, 리소스 크기 조정, HCX 구성, AVS 설정 등을 신중하게 고려해야 합니다. 성공적인 마이그레이션을 위해 이 단계를 핵심 영역으로 나누어 설명하겠습니다.

네트워킹 고려 사항

이는 아키텍처에서 가장 복잡한 부분입니다. HCX와 AVS의 네트워킹은 강력하지만 잘못 구성하면 심각한 문제를 야기할 수 있습니다. 따라서 고객의 잠재적 요구 사항에 맞춰 세부적으로 살펴보겠습니다.

  • ExpressRoute : 낮은 지연 시간과 높은 대역폭이 필요한 프로덕션 워크로드(예: 실시간 데이터를 사용하는 금융 앱)에 권장됩니다. 프라이빗 피어링을 사용하고 HCX 성능을 위해 MTU 설정이 1600바이트를 지원하는지 확인하십시오. 대규모 배포 또는 다중 사이트 연결이 필요한 고객에게 적합합니다.
  • 사이트 간 VPN은 지연 시간 허용 범위가 높은 소규모 또는 테스트 환경에 비용 효율적인 대안입니다. 고객의 초기 마이그레이션이 파일럿 단계 또는 중요하지 않은 워크로드로 제한되는 경우에 이상적입니다.
  • 결정 매트릭스 : 100개 이상의 VM이나 고성능 요구 사항에는 ExpressRoute를 사용하고, 50개 미만의 VM이나 초기 테스트에는 VPN을 사용합니다.
  • 글로벌 도달 범위 : ExpressRoute 회선이 여러 Azure 지역에 걸쳐 있는 경우(예: 고객이 미국 동부 및 서부 지역에서 운영하는 경우) 필요합니다. 허브와 AVS 프라이빗 클라우드 간 라우팅을 지원합니다. 고객이 다중 지역 전략을 사용하는 경우 이 기능을 고려하십시오.
  • 2계층 네트워크 확장 : HCX NE를 사용하면 VM이 IP 주소를 유지할 수 있습니다. 각 어플라이언스는 최대 8개의 VLAN을 지원하므로, 고객이 더 많은 네트워크를 확장해야 할 경우 추가 어플라이언스를 계획하십시오.
  • 모빌리티 최적화 네트워킹(MON) : Azure를 통해 최적화된 송신을 활성화하여 비대칭 라우팅을 해결합니다. 특히 고객이 확장된 네트워크를 사용하는 경우, 반환 트래픽에 대한 방화벽 규칙을 구성하세요.
  • 허브-스포크 토폴로지 : 공유 서비스(DNS, ID, 모니터링)를 사용하는 허브에 연결된 스포크 VNet에 AVS를 배치합니다. 고객은 보안 및 관리를 중앙에서 관리하는 것이 좋습니다.
  • Azure vNet 통합 : Azure 서비스를 사용한 하이브리드 시나리오에서 허브 VNet과 AVS VNet을 연동하여 고객이 Azure 기본 도구를 활용할 수 있도록 보장합니다.

네트워크 설정 다이어그램은 다음과 같습니다.

 
1
2
3
 
<a href="https://www.provirtualzone.com/wp-content/uploads/2025/05/HCX-to-AVS-04.png"><img class="alignnone wp-image-20885" src="https://www.provirtualzone.com/wp-content/uploads/2025/05/HCX-to-AVS-04.png" alt="Migrating Workloads to Azure VMware Solution with VMware HCX: A Practical Guide" width="850" height="670" /></a>
 

AVS 구성

AVS 환경 구성은 고객의 요구를 충족하는 데 매우 중요합니다. 여기에는 온프레미스 환경 및 마이그레이션 목표에 맞춰 SDDC를 설정하는 것이 포함됩니다.

  • 노드 크기 조정 : 최소 3개 노드 클러스터에서 AV36개 노드(36코어, 576GB RAM, 15.36TB NVMe)로 시작하세요. 고객의 VM 수(예: VM 500개에는 6~8개 노드가 필요할 수 있음)와 성능 요구 사항에 따라 확장하세요.
  • vSAN 구성 : 중복성을 위해 Fault Tolerance(FTT=1, RAID-1)를 활성화합니다. 스토리지 최적화를 위해 중복 제거 및 압축을 계획하되, 복제 트래픽 및 스냅샷으로 인한 잠재적 오버헤드를 모니터링합니다.
  • NSX-T 설정 : 고객의 온프레미스 네트워크 토폴로지에 맞게 NSX-T 세그먼트를 구성합니다. L2 확장 통합을 계획하고 보안 정책(예: 분산 방화벽 규칙)을 정의합니다.
  • Azure 통합 : Azure vNet 피어링을 설정하고 공유 서비스(예: DNS, Azure AD)를 위한 허브 VNet과 통합합니다. 고객의 기존 Azure 구독과의 호환성을 보장합니다.
  • 리소스 할당 : Azure Migrate 크기 권장 사항에 따라 CPU, RAM 및 스토리지를 할당하고 성장에 대비해 20~30% 여유 공간을 추가합니다.

AVS를 사용한 HCX에 대한 네트워크 설계 고려 사항

VMware HCX를 사용하여 온프레미스 환경에서 Azure VMware Solution으로 워크로드를 마이그레이션할 때 네트워크 설계는 아키텍처에서 가장 중요한 부분 중 하나가 됩니다. HCX가 모빌리티 및 네트워크 확장의 복잡성을 상당 부분 처리하지만, 부적절한 라우팅, 세분화 및 어플라이언스 배치 계획은 심각한 중단이나 마이그레이션 실패를 초래할 수 있습니다.

이 섹션의 개념을 뒷받침하기 위해 HCX를 AVS로 마이그레이션할 때 가장 중요한 네트워크 설계 고려 사항을 요약한 아래 이미지를 만들었습니다.

허브 앤 스포크 토폴로지

다이어그램의 왼쪽 상단 사분면은 허브-스포크 네트워크 아키텍처를 보여줍니다 . 이는 Azure에서 권장되는 디자인 패턴입니다. AVS 프라이빗 클라우드는 스포크 가상 네트워크(VNet)로 배포되는 반면, 허브에는 DNS, Active Directory, NVA 방화벽, 모니터링, ExpressRoute 게이트웨이와 같은 중앙 집중식 서비스가 포함됩니다. 각 스포크는 VNet 피어링을 통해 허브에 연결되어 공유 서비스를 통한 트래픽 흐름을 허용하는 동시에 스포크 간 수평 이동을 격리합니다.

이러한 설계는 라우팅을 간소화하고, 중앙 지점에서 보안 정책을 시행하며, 여러 지역이나 환경 전반에서 일관성을 보장합니다.

NSX-T 세그먼트 계획

AVS는 네트워크 가상화에 NSX-T를 사용하고 , HCX는 온프레미스 환경에서 AVS로 레이어 2 네트워크를 확장할 수 있습니다. 하지만 모든 네트워크를 확장할 수 있거나 확장해야 하는 것은 아닙니다.

이미지의 오른쪽 상단 사분면은 일반적인 문제인 서브넷 중복을 보여줍니다 . 기존 세그먼트와 동일한 IP 범위를 사용하는 AVS로 네트워크를 확장하면 라우팅 충돌과 예측할 수 없는 동작이 발생합니다. 이미지는 서브넷을 복제할 때 192.168.12.0/24여러 소스에서 확장되거나 두 번 이상 사용될 경우 문제가 발생할 수 있음을 보여줍니다.

네트워크 확장을 배포하기 전에 항상 서브넷을 신중하게 문서화하고 계획하세요.

서비스 메시 범위

왼쪽 하단 사분면에서는 HCX 서비스 메시 고려 사항을 다룹니다. 이는 HCX 연결의 핵심으로, 온프레미스 환경과 AVS 환경 간의 경로를 정의합니다. 각 서비스 메시에는 양쪽에 구축된 인터커넥트 및 네트워크 확장과 같은 어플라이언스가 포함됩니다.

주요 고려 사항:

  • 각 NE 어플라이언스는 최대 8개의 확장 네트워크를 지원합니다.
  • 처리량 제한 과 예상 마이그레이션 동시성을 고려해야 합니다.
  • 서비스 메시는 클러스터별로 신중하게 범위를 지정해야 합니다.

이 다이어그램은 NE 어플라이언스가 확장 한계에 도달할 수 있음을 보여줍니다. 8개 이상의 네트워크를 확장하는 경우, 추가 어플라이언스를 구축하거나 여러 메시에 걸쳐 마이그레이션을 분할하십시오.

모빌리티 최적화 네트워킹(MON)

이는 레이어 2 네트워크 확장을 사용할 때 가장 간과되지만 중요한 기능 중 하나입니다. 이미지 중앙에 표시된 것처럼, 모빌리티 최적화 네트워킹(MON)을 사용하면 마이그레이션된 VM이 원래 온프레미스 IP 주소를 유지하더라도 AVS의 로컬 라우팅을 사용할 수 있습니다.

MON이 없으면 인터넷이나 Azure 서비스에서 반환되는 트래픽이 온프레미스 게이트웨이를 통해 다시 라우팅되어 비대칭 라우팅 및 트래픽 손실이 발생할 수 있습니다. 다이어그램은 두 가지 가능한 흐름을 보여줍니다.

  • VM이 Azure 게이트웨이를 직접 사용하는 파선 HCX MON 경로
  • 라우팅 문제를 야기하는 최적화되지 않은 경로인 비대칭 경로로 표시된 곡선 경로

MON을 활성화하려면 다음이 필요합니다.

  • AVS 세그먼트에 NSX-T 게이트웨이 지원이 있는지 확인하십시오.
  • 로컬 이탈을 허용하기 위한 올바른 방화벽 규칙
  • 라우팅 변경 및 테스트 검증에 대한 인식

MON은 특히 Azure 네이티브 서비스나 인터넷 엔드포인트에 액세스하는 애플리케이션의 경우 많은 마이그레이션 이후 문제를 해결합니다.

방화벽 및 라우팅

오른쪽 상단 사분면에 표시된 또 다른 핵심 사항은 방화벽과 라우팅 인식 의 중요성입니다 . HCX는 모든 어플라이언스 간에 여러 포트(예: TCP 443 및 UDP 4500)를 양방향으로 개방해야 합니다. 특히 MON이 활성화된 경우 리턴 라우팅은 예측 가능하고 대칭적이어야 합니다 .

Azure 또는 온프레미스에서 네트워크 가상 어플라이언스(NVA)를 사용하는 경우, 해당 어플라이언스가 NAT를 수행하거나 HCX가 사용하는 트래픽을 차단하지 않는지 확인하세요. 연결 문제가 발생하는 경우, 방화벽이나 라우팅 구성 오류로 인해 발생하는 경우가 많습니다.

ExpressRoute 및 MTU 고려 사항

마지막으로, 오른쪽 하단 사분면은 많은 팀이 검증 과정에서 간과하는 MTU 크기와 ExpressRoute 구성을 강조합니다 . HCX Interconnect 트래픽은 단편화에 민감합니다. AVS 환경에는 최소 1500의 MTU가 필요하며 , 특히 대량 또는 RAV 마이그레이션 방식을 사용할 때 성능과 안정성을 위해 점보 프레임(1600바이트 이상)을 활성화하는 것이 좋습니다.

프로덕션 마이그레이션을 시작하기 전에 항상 MTU 경로를 종단 간 테스트하세요.

클러스터 및 리소스 계획

AVS 프라이빗 클라우드는 단순히 온프레미스 호스트 수만이 아니라 고객의 실제 사용 데이터를 기반으로 해야 합니다. AVS 노드는 일관된 성능을 제공하지만, 통합에는 신중한 계획이 필요합니다.

  • 용량 계획 : CPU, RAM 및 스토리지 사용량 보고서에는 Azure Migrate 또는 vRealize Operations를 사용하세요. 용량 증가 및 급증에 대비하여 20~30%의 여유 용량을 추가하세요.
  • 클러스터 크기 조정 : 최소 3개 노드 클러스터로 시작하여 500개 VM 부하에 따라 점진적으로 확장합니다.
  • 스토리지 고려 사항 : 중복성을 위해 FTT=1, RAID-1로 vSAN을 구성하십시오. 스토리지 사용량을 관리하기 위해 중복 제거/압축을 모니터링하십시오.

HCX 서비스 메시 및 마이그레이션 방법

HCX 서비스 메시는 마이그레이션 트래픽 흐름 방식을 정의하여 마이그레이션 인프라의 초석을 제공합니다. 이 부분의 구성 오류는 프로젝트를 방해할 수 있습니다.

  • 서비스 메시 배포 : 온프레미스 HCX 커넥터를 AVS HCX 클라우드 매니저와 연결합니다. 정확한 라우팅을 위해 컴퓨팅 및 네트워크 프로필을 정의합니다.
  • HCX Interconnect : 안전하고 암호화된 마이그레이션 트래픽을 처리합니다. 적절한 대역폭을 확보하세요.
  • 네트워크 확장(NE) : L2 스트레칭에 필요함. 용량 계획(어플라이언스당 8개 VLAN)
  • 모빌리티 최적화 네트워킹(MON) : 마이그레이션 후 비대칭 라우팅을 방지합니다.
  • 마이그레이션 방법 :
    • vMotion: 중요한 앱(예: 웹 서버).
    • 대량: 개발/테스트 VM.
    • RAV: 데이터베이스(예: SQL Server).
    • 추위: 레거시 시스템.
    • OSAM: 물리적 Linux 서버.

서비스 메시 레이아웃은 다음과 같습니다.

계획 단계에서 네트워킹, AVS 구성, 크기 조정 및 HCX 구성을 정확하게 설정하는 것은 매우 중요합니다. 마치 튼튼한 집의 기초를 쌓는 것과 같습니다. 서브넷 겹침과 같은 작은 실수도 심각한 지연을 초래할 수 있습니다. 아키텍처 설계를 완료했으니, 이제 마이그레이션 실행 계획 단계로 넘어가 보겠습니다.

마이그레이션 실행 및 운영

마이그레이션을 효과적으로 실행하려면 신중한 계획과 엄격한 검증이 필요합니다. 바로 이 부분에서 준비가 빛을 발하며, 성공을 위한 체계적인 접근 방식을 간략하게 설명하겠습니다.

제가 제안하는 실행 계획은 다음과 같습니다.

  • HCX 설정 : HCX Manager를 사용하여 온프레미스 vCenter와 AVS vCenter를 페어링합니다. 컴퓨팅/네트워크 프로필을 사용하여 서비스 메시를 배포합니다.
  • 네트워크 확장 : HCX NE를 통해 VLAN을 확장하고, ping 테스트로 검증하여 문제를 조기에 포착합니다.
  • 파일럿 웨이브 : 대량 마이그레이션을 사용하여 프로세스를 테스트하기 위해 5~10개의 비중요 VM으로 시작합니다.
  • 예약된 웨이브 : 비즈니스 윈도우에 맞춰 조정하세요. 중요한 VM에는 vMotion/RAV를 사용하여 다운타임을 최소화하세요.
  • 롤백 전략 : 검증될 때까지 전원이 꺼진 소스 VM을 보관합니다.
  • 모니터링 및 로깅 : HCX 대시보드를 사용하고 추적을 위해 VM에 태그를 지정하여 가시성을 유지합니다.

마이그레이션 워크플로는 다음과 같습니다.

성공의 핵심은 각 단계마다 엄격한 검증을 거치는 단계적 접근 방식입니다. 파일럿 웨이브는 실제 운영 환경으로의 마이그레이션 전에 문제를 파악하고 해결하는 데 도움이 될 것입니다. 워크로드가 AVS에 배치되면 다음 단계는 최적화 및 완료를 위한 계획 수립입니다.

마이그레이션 후 최적화 및 마무리

마이그레이션 후 최적화는 간과되는 경우가 많지만, AVS로 워크로드를 이전하여 얻을 수 있는 이점을 최대한 활용하는 데 매우 중요합니다. 이 단계는 최적의 성능, 리소스 효율성 및 비용 관리를 보장합니다.

제가 추천하는 최적화 계획은 다음과 같습니다.

  • 성능 검증 : Azure Monitor와 vRealize Operations를 사용하여 CPU, 메모리, 디스크 지연 시간 및 네트워크 처리량을 확인합니다.
  • 검증 체크리스트 :
    • 앱 기능.
    • DNS 확인.
    • 네트워크 연결성.
  • 워크로드 적정 크기 조정 : VM 크기가 너무 크면 리소스가 낭비됩니다. Azure 권장 사항을 활용하여 가능한 경우 VM 크기를 줄이세요.
  • 네트워크 확장 해제 : NSX-T 세그먼트로 전환한 후 사용하지 않는 L2 확장을 제거합니다.
  • 비용 관리 : Azure Cost Management를 사용하여 예산과 알림을 설정하고, 업무 시간 외에는 프로덕션 환경이 아닌 VM의 종료를 예약할 수 있습니다.
  • 거버넌스 :
    • Azure Automation으로 패치합니다.
    • Azure Policy 준수 여부를 감사합니다.

마이그레이션 후 최적화는 AVS에 대한 투자를 극대화하고 장기적인 안정성을 보장합니다. 단순히 클라우드에 접속하는 것만이 아니라, 클라우드에 접속한 후 효율적으로 운영하는 것이 중요합니다. 최적화된 환경을 바탕으로 보안, 규정 준수 및 거버넌스의 핵심 측면을 살펴보겠습니다.

보안, 규정 준수 및 거버넌스

워크로드를 AVS로 마이그레이션하려면 인프라를 Azure의 거버넌스 및 보안 모델과 통합해야 합니다. 워크로드를 보호하고 신뢰를 유지하려면 조직의 표준을 AVS 환경으로 원활하게 확장하는 것이 필수적입니다.

제가 제안하는 보안 및 거버넌스 계획은 다음과 같습니다.

  • ID 및 액세스 관리(IAM) : 역할 기반 액세스 제어(RBAC)를 위해 Azure Active Directory(Azure AD)를 통합합니다. vCenter 접근 권한을 필수 인력으로 제한합니다.
  • 보안 통합 : Azure Firewall, Defender for Cloud, Azure Sentinel을 사용하여 위협을 탐지하고 대응합니다.
  • 규정 준수 관리 : Azure Policy를 활용하여 PCI-DSS, GDPR 또는 ISO 27001과 같은 표준을 시행합니다. Azure Security Center를 통해 정기 감사를 수행합니다.
  • 중앙 집중식 로깅 및 모니터링 : 가시성을 높이기 위해 Azure Monitor 또는 Sentinel로 로그를 스트리밍합니다.

강력한 보안, 규정 준수 및 거버넌스 조치는 워크로드를 보호하고 비즈니스 연속성을 보장하는 데 필수적이며, 특히 금융과 같이 규제가 엄격한 산업의 경우 더욱 그렇습니다. 마이그레이션 계획에 대한 최종적인 생각과 의견을 공유해 보겠습니다.

마지막 생각

VMware HCX를 사용하여 AVS로 마이그레이션을 계획하는 것은 전략적이고 세부적인 작업으로, 신중한 준비와 VMware에 대한 심층적인 전문 지식이 필요합니다. 제 연구에 따르면 성공적인 마이그레이션은 정확한 평가, 세부적인 준비, 견고한 네트워킹 구성, 적절한 AVS 설정, 그리고 철저한 마이그레이션 후 최적화에 달려 있습니다. 고객의 500개 VM을 이전하는 이 계획은 최소한의 중단으로 원활하게 전환하기 위한 체계적인 접근 방식을 제시합니다.

HCX와 AVS를 통해 제공되는 기술과 도구 덕분에 프로세스 관리가 더욱 수월해졌지만, 명확한 소통, 상세한 문서화, 그리고 모든 단계에서 엄격한 검증의 중요성을 절대 과소평가해서는 안 된다는 것을 깨달았습니다. 마이그레이션 기간을 비즈니스 요구 사항에 맞추고 팀 간의 원활한 협업을 보장하는 것은 기술 설정만큼이나 중요합니다. 사전 계획 및 테스트에 상당한 노력을 투자하는 것을 강력히 권장합니다. 위험을 줄일 수 있고, 원활한 전환을 보장하여 마이그레이션을 단순한 기술적 성과가 아닌 비즈니스 성공으로 만들어 줍니다.

제 연구 결과와 이 계획이 AVS 마이그레이션 여정에 도움이 되기를 바랍니다. 궁금한 점이나 공유하고 싶은 경험이 있으시면 언제든지 댓글을 남겨주시거나 직접 연락해 주세요. 앞으로 더 많은 논의를 기대하겠습니다.

자주 묻는 질문

제가 자주 접하는 질문에 대한 답변은 다음과 같습니다.

  • 예상 다운타임은 얼마나 되나요? vMotion은 다운타임이 없고, 대량 마이그레이션은 몇 분 정도 걸리며, 콜드 마이그레이션은 다운타임이 더 길어집니다.
  • AVS 라이선스는 어떻게 적용되나요? Azure Hybrid Benefit을 사용하면 Windows Server 및 SQL Server 라이선스 비용을 절감할 수 있습니다.
  • 문제가 발생하면 어떻게 되나요? 안전한 롤백을 위해 마이그레이션된 워크로드가 완전히 검증될 때까지 소스 VM을 보관하세요.

추가 자료 및 공식 참조

공식 문서를 살펴보거나 HCX 및 Azure VMware Solution의 특정 영역을 더 자세히 알아보고 싶은 독자를 위해 다음과 같은 권장 리소스를 소개합니다.

워크로드 검색 및 평가에 대한 Azure Migrate 설명서를 검토할 수도 있습니다 .

 

728x90
728x90

VMware HCX란 무엇이며 어떻게 작동합니까?

이 VMware HCX란 무엇이며, 어떻게 작동하나요 ? 에서는 HCX에 대한 간단한 설명과 마이그레이션 시나리오 유형, 그리고 HCX가 워크로드 마이그레이션에 어떻게 도움이 될 수 있는지에 대해 알려드리겠습니다.

VMware HCX(이전 명칭: Hybrid Cloud Extension 및 NSX Hybrid Connect)는 대규모 확장이 가능한 하이퍼바이저 기반 슈퍼컴퓨팅 플랫폼으로, 온디맨드 셀프 서비스 클라우드 형태로 제공되어 고객이 수십 개의 VMware ESXi 호스트에서 복잡한 실시간 애플리케이션과 고성능 분석을 몇 초 만에 실행할 수 있도록 지원합니다. 사전 하드웨어 구매는 필요하지 않습니다.

HCX란 무엇인가요?

VMware HCX는 데이터센터와 클라우드 전반에서 간소화된 애플리케이션 마이그레이션, 워크로드 리밸런싱, 비즈니스 연속성을 지원하는 애플리케이션 모빌리티 플랫폼입니다. 무제한 모빌리티, 안전한 대규모 마이그레이션, 하이브리드 네트워킹 등의 기능을 제공합니다. 또한, HCX는 VMware vSphere Replication 프로토콜을 활용하여 사전 정의된 일정에 따라 가상 머신을 병렬로 이동하는 대량 마이그레이션 옵션을 제공합니다. HCX는 환경 및 사용 사례에 따라 소스(HCX 커넥터) 또는 대상(HCX 클라우드)으로 구축할 수 있습니다.

HCX 데이터 마이그레이션 프로세스

HCX 데이터 마이그레이션 프로세스는 간단합니다. HCX를 사용하면 단 몇 분 만에 한 위치에서 다른 위치로 데이터를 마이그레이션할 수 있습니다. 소스 위치와 대상 위치를 선택하고 마이그레이션할 데이터 양을 지정하기만 하면 됩니다. 그러면 HCX가 두 위치 간에 데이터를 자동으로 전송합니다.

HCX 데이터 마이그레이션 프로세스는 수행되는 마이그레이션 유형에 따라 다릅니다. 일반적으로 HCX를 사용하는 마이그레이션에는 vMotion과 대량 마이그레이션, 두 가지 유형이 있습니다.

vMotion에서는 VM이 ​​다운타임이나 중단 없이 한 ESXi 호스트에서 다른 ESXi 호스트로 이동합니다. vMotion 작업은 VM의 섀도 복사본을 해당 상호 연결 어플라이언스(IX)로 전송하며, 이 어플라이언스에는 마이그레이션된 VM의 임시 가상 머신 디스크(VMDK)도 저장됩니다. 섀도 복사본이 완료되면 소스 VM이 정지되고 메모리 상태가 IX로 전송됩니다. 그런 다음 IX가 VM의 정지를 해제하여 대상 ESXi 호스트에서 VM을 실행할 수 있도록 합니다.

반면, 대량 마이그레이션은 호스트 기반 복제를 사용하여 HCX 데이터 센터 간에 가상 머신을 재배치합니다. 대량 마이그레이션에서는 소스 VM이 먼저 VMware vSphere Replication 프로토콜을 사용하여 대상 HCX 데이터 센터에 복제됩니다. 다운타임을 줄이기 위해 복제 중에는 소스 VM이 온라인 상태를 유지하고 복제 완료 후에는 대상 ESX 호스트에 부트스트랩됩니다. 복제가 완료되면 대상 사이트의 VM이 켜지고 테스트되며, 소스 사이트의 원본 VM은 삭제됩니다.

두 가지 마이그레이션 유형 모두 서로 다른 환경 간에 워크로드를 이동하는 데 있어 원활하고 효율적인 마이그레이션 환경을 제공하여 수동 개입의 필요성을 없애고 비즈니스 운영의 중단을 최소화합니다.

성공적인 HCX 마이그레이션 수행

성공적인 HCX 마이그레이션을 수행하려면 다음과 같은 주요 단계를 따라야 합니다.

  1. 마이그레이션 계획 및 준비: 마이그레이션 프로세스를 시작하기 전에 이에 따른 계획과 준비가 필수적입니다. 여기에는 마이그레이션할 가상 머신과 애플리케이션을 파악하고, 마이그레이션 방식(vMotion 또는 대량 마이그레이션)을 결정하고, 원본 환경과 대상 환경 간의 네트워크 연결을 평가하는 것이 포함됩니다.
  2. HCX 구성 요소 구성: 다음 단계는 마이그레이션 요구 사항에 따라 HCX 커넥터 및 HCX 클라우드를 포함한 HCX 구성 요소를 구성하는 것입니다. 여기에는 상호 연결 네트워크 설정, 사이트 쌍 생성, 필요한 경우 복제 활성화가 포함됩니다.
  3. 마이그레이션 설정 테스트: HCX 구성 요소를 구성한 후에는 마이그레이션 설정이 제대로 작동하는지 확인하기 위해 마이그레이션 설정 테스트가 매우 중요합니다. 여기에는 네트워크 연결 테스트, 복제 설정 검증, 가상 머신의 성공적인 마이그레이션 가능 여부 확인이 포함됩니다.
  4. 마이그레이션 수행: 마이그레이션 설정 테스트 및 검증이 완료된 후 마이그레이션 프로세스를 시작할 수 있습니다. 마이그레이션이 문제 없이 원활하게 진행되도록 주의 깊게 모니터링하는 것이 중요합니다.
  5. 마이그레이션 확인: 마이그레이션이 완료되면 가상 머신과 애플리케이션이 새 환경에서 제대로 작동하는지 확인하는 것이 필수적입니다. 여기에는 애플리케이션 성능 테스트, 네트워크 연결 확인, 데이터 무결성 검증이 포함됩니다.

위의 단계를 따르면 조직은 원활하고 성공적인 HCX 마이그레이션을 보장하여 비즈니스 운영의 중단과 가동 중지 시간을 최소화할 수 있습니다.

HCX 마이그레이션의 두 가지 시나리오:

레거시 환경, vSphere 또는 레거시 KVM/Hyper-V에서 VMware Cloud Foundation(VCF) 환경으로 마이그레이션합니다.

VCF용 HCX

샘플 고객 시나리오

  • 프라이빗 클라우드 구축
  • 레거시 DC에서 VCF로 변환
  • 여러 DC 지역 통합
  • VCF에서 VCF 버전으로 업그레이드
  • vSphere 7 업그레이드

HCX의 장점

  • 대규모 이주 추진
  • 자동 vSphere 업그레이드
  • 사업에 영향 없음
  • vSphere가 아닌 워크로드 마이그레이션
  • 기존 IP/네트워크를 새 SDDC에 매핑
  • 몇 달/몇 주 만에 변환 가속화
  • 고객이 직접 하는 셀프 서비스

기존 환경(vSphere)에서 AWS 환경의 VMware Cloud(VMC)로 마이그레이션하고 DR 사이트로 보호합니다.

AWS의 VMC용 HCX

샘플 고객 시나리오

  • 온프레미스 VMC 마이그레이션
  • VMC 지역 간 재조정
  • VMC에서 기존 DR 측으로 보호

HCX의 장점

  • 라이브 대규모 마이그레이션
  • DR 사이트 보호를 위한 DRaaS + HCX
  • 지역 간 이주
  • 보안 마이그레이션 및 DR 트래픽
  • 네트워크 및 IP 보존
  • 대규모 L2 확장성

위의 예에서는 HCX가 워크로드(레거시 또는 신규 버전)를 물리적 데이터 센터나 하이퍼스칼라로 마이그레이션하고 해당 환경을 재해 복구 사이트로 복제하는 방법을 보여줍니다.

VMware HCX 마이그레이션 요약

요약하자면, VMware HCX는 데이터 센터와 클라우드 전반의 워크로드 마이그레이션, 리밸런싱 및 비즈니스 연속성을 간소화하는 애플리케이션 모빌리티 플랫폼입니다. HCX는 vMotion과 대량 마이그레이션, 두 가지 유형의 마이그레이션을 제공합니다. vMotion은 실시간 가상 머신 마이그레이션에 선호되는 방법이며, 대량 마이그레이션은 대량 워크로드 전송에 사용됩니다.

성공적인 HCX 마이그레이션을 보장하려면 조직에서 HCX 구성 요소를 계획, 준비 및 구성하고, 마이그레이션 설정을 테스트하고, 마이그레이션을 수행하고, 마이그레이션을 검증하여 가상 머신과 애플리케이션이 예상대로 작동하는지 확인해야 합니다.

전반적으로 HCX는 서로 다른 환경 간에 워크로드를 이동하는 데 있어 원활하고 효율적인 마이그레이션 환경을 제공하여 비즈니스 운영의 중단을 최소화하고 수동 개입의 필요성을 제거합니다.

결론:

VMware HCX는 기업이 비즈니스 운영 중단을 최소화하면서 데이터 센터와 클라우드 간에 워크로드를 마이그레이션할 수 있도록 지원하는 강력한 도구입니다. 무제한 모빌리티, 안전한 대규모 마이그레이션, 하이브리드 네트워킹 등의 기능을 통해 워크로드 마이그레이션과 비즈니스 연속성을 간소화하려는 기업에 이상적인 선택입니다.

이 대화에서 앞서 언급한 주요 단계를 따르면 IT 팀은 조직의 요구에 맞는 성공적인 HCX 마이그레이션을 보장할 수 있습니다. vMotion을 통한 가상 머신 마이그레이션이든 대량 마이그레이션이든, HCX는 서로 다른 환경 간에 워크로드를 원활하게 이동할 수 있는 효율적인 환경을 제공합니다.

HCX에 대한 내 비디오를 확인하세요

728x90
728x90
 

HCX – 서비스 메시를 생성하고 사이트를 연결하는 방법

오늘은 HCX 시리즈로 돌아가서 앞으로 몇 주 동안 HCX 시리즈를 완성해 보려고 합니다. 이번 세 번째 HCX - HCX 시리즈 관련 서비스 메시 생성 및 사이트 연결 방법 블로그 게시물에서는 HCX 서비스 메시를 생성하고 사이트를 연결하는 방법을 설명하겠습니다.

이전 HCX 블로그 게시물 "HCX - 네트워크 및 컴퓨팅 프로필 생성 방법" 에서 HCX 네트워크 프로필과 컴퓨팅 프로필을 생성했습니다. 즉, 두 사이트와 인프라(컴퓨팅 프로필)가 연결되어 HCX에서 볼 수 있게 되었습니다. 이제 서비스 메시를 생성하고 사이트를 연결하여 두 사이트 간에 VM을 마이그레이션해야 합니다.

HCX 서비스 메시란 무엇인가요?

HCX 서비스 메시는 서비스 메시 프로필, 소스 사이트 컴퓨팅 프로필, 대상 사이트 컴퓨팅 프로필의 세 가지 구성 요소로 구성됩니다. 서비스 메시 프로필은 소스 및 대상 위치와 관련 설정을 정의합니다. 또한 액세스 제어 목록(ACL), 방화벽 규칙, 암호화 설정과 같은 보안 요구 사항도 포함합니다. 컴퓨팅 프로필은 환경 내에서 할당하고 관리할 수 있는 리소스(CPU, 메모리, 스토리지)를 정의합니다.

서비스 메시가 생성되면 두 사이트 간의 연결을 정의하여 애플리케이션과 데이터의 안전하고 일관된 전송을 가능하게 합니다. 또한 방화벽 설정, ACL 구성, 암호화 적용 등 사이트 전반의 네트워크 및 보안 설정을 직관적으로 관리할 수 있는 기능을 제공합니다. 서비스 메시는 HCX 중앙 대시보드에서 모니터링 및 관리할 수 있으므로 두 사이트 간 서비스의 상태와 성능을 확인할 수 있습니다.

HCX 서비스 메시는 소스 사이트와 대상 사이트 간의 엔드투엔드 서비스를 효과적으로 구성하여 클라우드 또는 온프레미스 인프라 전반에서 애플리케이션, 데이터 및 워크로드를 안전하고 효율적으로 이동할 수 있는 방법을 제공합니다. 이 블로그 게시물에서는 HCX 서비스 메시를 생성하고 두 사이트(온프레미스 vCenter)를 연결하는 방법을 살펴보겠습니다.

HCX 서비스 메시 설치 방법

HCX 커넥터에서 '상호 연결' 옵션으로 이동한 후 '서비스 메시' 탭에서 '서비스 메시 생성'을 클릭하세요 . 그러면 서비스 메시 프로세스가 시작됩니다.

다음 옵션은 소스 사이트(HCX 커넥터)와 대상 사이트(HCX 클라우드)를 선택하는 것입니다. 사이트를 선택하고 " 계속"을 클릭하세요 .

다음으로, HCX 시리즈에서 이전 블로그 게시물에서 생성한 컴퓨팅 프로필을 선택하고 계속을 클릭합니다 .

이전 블로그 게시물에서도 살펴보았듯이, 네트워크 프로필을 생성할 때는 해당 서비스 메시에서 활성화할 서비스를 선택해야 합니다. 각 서비스는 소스 및 대상 vCenter에 저장된 HCX 어플라이언스를 생성합니다.

이 경우에는 모든 기능을 활성화하겠습니다. 단, 라이선스 제한으로 인해 사용할 수 없는 기능은 제외합니다(이전 블로그 게시물에서 설명했습니다).

활성화하려는 서비스를 선택하고 계속을 클릭합니다.

참고: 언제든지 서비스 메시로 돌아가서 옵션에서 서비스 메시에 더 많은 서비스를 추가할 수 있습니다.

이 옵션에서는 Service Mesh가 네트워크 확장 어플라이언스에 사용하는 이전 HCX 블로그 게시물에서 생성한 vCenter 네트워크를 선택합니다.

참고: 이미지에 나와 있듯이 이 옵션은 NSX-T가 대상에서 HCX와 함께 작동하는 경우 사용되며, NSX-T 오버레이 전송 영역을 사용하려면 필수(지원)입니다. 저는 NSX-T에 구성되어 대상 vCenter에서 사용 가능한 전송 영역 오버레이를 사용했습니다.

다음으로, 이전 HCX 블로그 게시물에서 생성한 네트워크 프로필을 사용합니다. 소스 및 대상 네트워크(vCenter에 있는 네트워크)에서 선택해야 하는 네트워크를 확인하세요.

이 섹션에서는 HCX 네트워크, 업링크, 관리, 복제 및 vMotion을 설정해야 합니다. 이 네트워크들은 Service Mesh가 Service Mesh 어플라이언스 간 연결에 사용할 네트워크와 VM 마이그레이션에 사용할 네트워크입니다.

마지막은 WAN입니다. 필수는 아니지만(이전 서비스인 Mesh에서 선택했습니다), 저대역폭 네트워크를 사용하거나 클라우드 환경으로 마이그레이션하는 경우 필수적입니다.

HCX 서비스 메시 네트워크 토폴로지에서 볼 수 있듯이 모든 네트워크는 소스에서 목적지까지 생성되고 연결됩니다.

서비스 메시의 이름을 지정하여 마무리합니다. 요약을 클릭하면 모든 네트워크를 확인할 수 있습니다. "마침"을 클릭하면 서비스 메시가 생성되고 모든 서비스 메시 어플라이언스가 생성됩니다.

HCX Service Mesh를 배포할 때 오류가 발생할 수 있으며 Service Mesh Appliance가 배포되지 않습니다.

어떤 문제는 쉽게 해결하고 계속 진행할 수 있지만, 어떤 문제는 문제를 파악하기 위해 더 많은 문제 해결이 필요합니다(가장 흔한 문제는 네트워크 문제입니다).

모든 오류가 수정되면 HCX 서비스 메시 배포를 계속할 수 있습니다.

다음 이미지에서는 대상 및 소스에 배포될 모든 HCX 서비스 메시 어플라이언스를 볼 수 있습니다. 즉, 두 사이트 간에 HCX 네트워크 연결이 존재합니다.

소스에서는 HCX가 새로운 "더미 ESXi 호스트"를 생성합니다. 이를 Mobility Agent라고 합니다. Mobility Agent는 HCX Interconnect에 의해 배포되는 가상 호스트입니다.

HCX 모빌리티 에이전트는 vMotion, Cold, RAV(Replication Assisted vMotion) 등 대상 사이트로의 마이그레이션을 수행하는 데 사용됩니다. 소스 사이트의 가상 머신에서 실행되며, 대상 환경으로 빠르고 안전하게 마이그레이션할 수 있도록 지원합니다. 이 소프트웨어는 HCX 솔루션에 포함되어 있으며 성공적인 마이그레이션을 위해 필수적입니다.

HCX 모빌리티 에이전트는 네트워크를 통해 VM과 관련 데이터를 안전하게 전송하여 서로 다른 환경 간에 워크로드를 원활하게 마이그레이션할 수 있도록 합니다.

모든 서비스 메시 어플라이언스가 배포되면 모든 어플라이언스가 정상 작동하고 정상적으로 작동하는지 다시 한번 확인할 수 있습니다. 또한 각 어플라이언스에 대한 정보(서비스, IP 주소 등)도 확인할 수 있습니다.

마지막 작업으로 HCX Service Mesh 배포를 마쳤으며, 이제 두 사이트가 연결되어 마이그레이션 작업을 시작할 준비가 되었습니다.

다음 HCX 시리즈 블로그 게시물에서는 두 사이트 간 VM 마이그레이션을 시작하겠습니다.

HCX 시리즈:

오류:

728x90
728x90

HCX – 네트워크 및 컴퓨팅 프로필을 만드는 방법

HCX 시리즈에 대한 두 번째 HCX - 네트워크 및 컴퓨팅 프로필 생성 방법 블로그 게시물에서는 네트워크 프로필에 대해 알아보겠습니다. 네트워크 프로필을 생성하는 방법, 그리고 모범 사례와 요구 사항은 무엇인지 살펴보겠습니다.

이전 HCX 블로그 게시물 " HCX Manager와 Connector 설치 및 페어링 방법" 에서 HCX Cloud Manager와 HCX Connector Appliance를 설치하고 페어링했습니다. 이제 두 사이트 모두 서로를 인식할 수 있습니다. 하지만 관리, vMotion, 복제, 업링크(사이트 간 연결), 네트워크 확장 등의 통신을 설정할 네트워크를 구축해야 합니다.

먼저, HCX에서 네트워크 프로필을 구현하는 데 필요한 요구 사항이 무엇인지 알아보겠습니다.

  • vCenter 또는 NSX-t의 가상 스위치
    • 하나의 기본 vSphere 포트 그룹(VSS 또는 VDS) 또는 NSX 기반 네트워크.
  • IP 주소 정보:
    • 게이트웨이 IP, 네트워크 접두사 및 MTU, DNS
    • HCX는 Service Mesh 배포 중에 IP 주소 풀을 예약하여 사용할 수 있습니다 .

네트워크 프로필 구성은 서비스 메시 배포(IX, NE 및 OSAM 어플라이언스에 할당된 IP 주소) 중에만 사용됩니다 . HCX 컴퓨팅 프로필은 항상 하나 이상의 네트워크 프로필을 사용하여 인프라에 연결합니다.

네트워크 프로필 유형:

관리 및 업링크는 관리 연결에 사용되고, vMotion, 복제 및 게스트 네트워크 네트워크 프로필은 마이그레이션 작업에 사용됩니다.

  • HCX 관리
    Service Mesh 구성 요소가 HCX Manager, vCenter Server, NTP 및 DNS에 연결하는 데 사용됩니다.
  • HCX 업링크
    는 Service Mesh 구성 요소가 피어 어플라이언스에 도달하는 데 사용됩니다.

중요:
목적지 HCX 시스템에 인터넷을 통해 접속해야 하는 경우, 업링크 네트워크 프로필을 사용하여 공용 IP 주소를 할당하십시오. 목적지 NAT 구성은 지원되지 않습니다.
소스 HCX 시스템은 공용 IP 주소가 필요하지 않으며 기존 SNAT를 사용하여 구성할 수 있습니다.

  • HCX vMotion
    Service Mesh 구성 요소가 ESXi 클러스터에 연결하여 vMotion 기반 서비스를 제공하는 데 사용됩니다.
  • HCX 복제는
    Service Mesh 구성 요소가 복제 기반 서비스를 위해 ESXi 클러스터에 연결하는 데 사용됩니다.

참고:
이 네트워크 프로필 유형은 ESXi vSphere Replication VMkernel 트래픽과 호환되지만 vSphere Replication NFC VMkernel 트래픽에는 사용할 수 없습니다. vSphere Replication NFC VMkernel 트래픽은 항상 관리 네트워크를 사용합니다.


  • OSAM 배포에서 Service Mesh Sentinel Gateway가 Sentinel 에이전트에 연결하는 데 사용되는 HCX 게스트 네트워크 입니다.

Mesh Applications Services가 배포되고 Compute Profile과 함께 사용되는 경우 네트워크 프로필이 사용됩니다.

  • HCX-IX(마이그레이션, DR)
  • HCX-NE(네트워크 확장)
  • HCX-WO(WAN 최적화)
  • HCX-Sentinel 게이트웨이(OSAM)
  • HCX-Sentinel 데이터 수신기

HCX 서비스 가전제품 예시:

Mesh를 구축할 때 HCX 어플라이언스에 대해 더 자세히 설명하겠습니다.

참고: 제 HCX 인프라 랩에서는 IX, NE, WO 서비스만 사용합니다. HCX-Sentinel Gateway와 HCX-Sentinel Data Receive에는 Enterprise 라이선스가 필요하고, 저는 NSX-T에서 제공하는 Advanced 라이선스를 사용하고 있으므로 이 세 가지 서비스만 활성화했습니다.

HCX 네트워크 프로필을 만들기 전에 네트워크 프로필의 배포 유형이 5가지 있습니다.

  • HCX 네트워크 구성 2 – 전용 복제 네트워크
  • HCX 네트워크 구성 4 – 게스트 네트워크를 사용한 OS 지원 마이그레이션
  • HCX 네트워크 구성 5 - 관리 네트워크를 사용한 OS 지원 마이그레이션

이 HCX 랩에서는 다양한 배포 유형을 사용합니다. 관리 및 업링크에는 공유 네트워킹을 사용하고, vMotion 및 복제에는 2개의 vNIC가 있는 격리된 네트워크를 사용합니다.

내 구성:

vCenter 소스:

vCenter 관리 포트 그룹:

  • HCX 매니지먼트 포르투그룹
  • HCX 업링크 포르투그룹

2개의 전용 vNIC가 있는 vCenter 새 vDS

  • HCX v모션
  • HCX 복제

vCenter Targer VCF:

vCenter 관리 포트 그룹:

  • HCX 매니지먼트 포르투그룹
  • CX 업링크 포르투그룹

2개의 전용 vNIC가 있는 vCenter 새 vDS

  • HCX v모션
  • HCX 복제

이 구성에서는 관리 및 업링크를 ESXi 관리의 vNIC와 공유합니다. vMotion 및 복제에서는 트래픽을 위해 두 개의 전용 물리적 인터페이스를 공유합니다.

HCX 네트워크 프로필 토폴로지의 예입니다.

다양한 유형의 네트워크 프로필과 디자인에 대한 자세한 내용은 여기에서 확인할 수 있습니다 .

HCX 네트워크 프로필을 만드는 방법

사이트 페어링이 완료되면(이전 HCX 블로그 게시물 에서 설명 ) 이제 네트워크 프로필을 만들 수 있습니다.

참고: HCX 커넥터 소스 의 예를 보여드리겠습니다. 이 예를 사용하여 HCX Cloud Manager 대상에서 네트워크 프로필을 생성하세요.

HCX 커넥터에 로그인하고 상호 연결 옵션으로 이동한 후 네트워크 프로필 탭을 선택 하고 네트워크 프로필 만들기를 클릭합니다 .

네트워크 프로필 생성을 시작하세요. 먼저 관리 네트워크 프로필을 생성하겠습니다 .

먼저 , 이 네트워크 프로필에 사용할 vSwitch, vDS 또는 NSX 네트워크(HCX 커넥터의 경우 필수 아님)를 선택하세요. 이 경우에는 vDS입니다.

둘째 , HCX 관리를 위해 만든 포트 그룹을 선택합니다.

셋째 , 관리용 IP 풀 주소를 추가합니다. 어플라이언스당 IP 주소가 하나씩 필요합니다. IP 주소를 하나만 배포하므로 IP 주소가 하나 더 필요합니다. 하지만 여기에 전체 IP 풀 범위를 추가할 수 있습니다. HCX는 필요한 IP 주소를 사용하며, 저는 여기에 두 개를 추가하겠습니다.

나머지 정보(마스크, 게이트웨이, DNS, DNS 접미사)를 입력하세요. 관리에는 1500 MTU, vMotion 및 복제에는 9000 MTU를 사용하겠습니다. 네트워크에 맞는 MTU 크기를 사용하세요.

MTU 크기, 대역폭 및 대기 시간 요구 사항은 다음과 같습니다.

네트워크 언더레이 최소 요구 사항에 대한 모든 정보는 여기에서 확인하세요 .

넷째 , 더 나은 네트워크 카탈로그를 위해 관리 트래픽 유형을 선택합니다(필수는 아니며, 메시 프로필을 생성할 때 각 네트워크 유형을 식별하기 위한 것일 뿐입니다). 그리고 생성을 클릭하여 마무리합니다 .

이제 관리 네트워크 프로필이 생성되었습니다. 관리 네트워크 프로필을 생성한 후 복제 네트워크 프로필을 생성해 보겠습니다. 위에서 설명한 옵션과 동일하지만, 복제에는 MTU 9000을 사용합니다.

마지막으로 Uplink와 vMotion을 생성해 보겠습니다.

관리, 업링크, vMotion, 복제 네트워크 프로필을 생성했습니다.

마지막 작업은 HCX Connect 소스에서 HCX 네트워크 프로필 생성을 완료하는 것입니다. 이후 HCX Manager Target 측에서 프로필을 생성하거나 HCX Connect의 다음 단계인 "컴퓨트 프로필 생성"으로 이동할 수 있습니다.

HCX 컴퓨팅 프로필을 만드는 방법

HCX의 컴퓨팅 프로필이란 무엇인가요?

컴퓨팅 프로필은 서비스 메시가 추가될 때 HCX가 소스 또는 대상 사이트에서 Interconnect 전용 가상 어플라이언스를 배포하는 데 사용하는 컴퓨팅, 스토리지 및 네트워크 설정을 포함하는 HCX Connect 인프라입니다.

Mesh는 소스의 컴퓨팅 프로파일을 타겟의 컴퓨팅 프로파일에 연결합니다. 이는 마이그레이션을 위해 두 인프라를 연결할 뿐만 아니라, Mesh가 Interconnect 전용 가상 어플라이언스 서비스를 배포하여 HCX 인프라 연결을 구축할 수 있도록 하기 위함입니다.

HCX 커넥터에 로그인하고 상호 연결 옵션으로 이동한 후 컴퓨팅 프로필 탭을 선택 하고 컴퓨팅 프로필 만들기를 클릭합니다 .

먼저, 컴퓨트 프로필에 이름을 지정합니다(저는 항상 위치를 추적하기 위해 사이트 이름으로 컴퓨트를 식별합니다)

다음으로, HCX 인터커넥트 어플라이언스에 필요한 서비스를 선택하세요. 간단한 구성에는 하이브리드 인터커넥트 , 크로스 클라우드 vMotion 마이그레이션, 대량 마이그레이션, 이렇게 세 가지 서비스만 필요합니다. 더욱 고급 HCX 구현을 위해 다음과 같은 추가 서비스가 제공됩니다.

  • WAN 최적화  데이터 중복 제거 및 회선 조정과 같은 WAN 최적화 기술. 저대역폭 인프라 또는 인터넷 멀티 클라우드 마이그레이션에 적합합니다.
  • 네트워크 확장  통합 근접 라우팅을 갖춘 고처리량 네트워크 확장 서비스는 IP/MAC 주소가 유지되는 사이트 전체에서 원활한 모빌리티와 간단한 재해 복구 계획을 가능하게 합니다.
  • 재해 복구  재해 복구 서비스는 앱 수준 재해부터 사이트 전체 재해까지 워크로드를 보호하는 비즈니스 연속성 솔루션입니다.

HCX Enterprise 라이선스를 사용하면:

  • 복제 지원 vMotion 마이그레이션  VMware HCX 복제 지원 vMotion(RAV)은 VMware HCX 대량 마이그레이션(병렬 작업, 복원력 및 스케줄링)과 VMware HCX vMotion(가동 중단 없는 가상 머신 상태 마이그레이션)의 장점을 결합합니다.
  • SRM 통합  VMware Site Recovery Manager에서 DR을 구성하는 기능을 제공합니다. HCX는 VM 복제를 위한 SRM 확장 기능으로 사용할 수 있습니다.
  • OS 지원 마이그레이션  OS 지원 마이그레이션 서비스는 OpenStack 워크로드를 vSphere 환경으로 가져오는 데 사용할 수 있으며 레거시 시스템이나 KVM 또는 Hyper-V와 같은 다른 하이퍼바이저에서 VM을 마이그레이션하는 데에도 사용할 수 있습니다.

다음에 보여드리는 것처럼 이 HCX 랩에서는 모든 HCX 고급 서비스를 활성화하겠습니다.

다음으로, 컴퓨팅 프로필에 사용할 데이터 센터 또는 클러스터를 선택합니다.

다음 섹션에서는 클러스터, 데이터 저장소, VM 폴더(선택 사항)를 선택합니다.

참고: 이 선택 사항은 HCX 어플라이언스가 배포될 위치라는 점을 잊지 마세요. 또한 이 어플라이언스를 실행하기 위해 vCPU와 vMemory를 예약할 수 있습니다. 프로덕션 환경인 경우, 모든 서비스가 리소스 부족 없이 정상적으로 실행될 수 있도록 100%(사용 가능한 경우)를 예약하는 것이 좋습니다.

다음으로, 이전에 생성한 네트워크 프로필을 선택하겠습니다. 먼저 관리 네트워크 프로필을 선택하세요.

다음으로, 업링크 네트워크 프로필을 선택합니다.

참고: 네트워크 프로필 유형 확인란을 사용하는 경우 HCX는 이것이 Uplink에 대해 생성한 네트워크 프로필이라는 것을 녹색 아이콘(다음 이미지에서 볼 수 있음)으로 강조 표시합니다.

다음은 vMotion 네트워크 프로필입니다. 역시 HCX에서 권장하는 프로필을 사용하세요.

보시다시피, 네트워크 프로필을 선택할 때마다 HCX가 디자인에 맞게 네트워크를 만들기 시작합니다.

마지막으로 선택할 것은 복제 네트워크입니다.

네트워크 확장 서비스를 선택했으므로 이 네트워크에는 네트워크 프로필이 아닌 네트워크를 사용해야 합니다. 이 경우, 이 서비스용으로 생성된 NSX-T 오버레이 포트 그룹을 사용하겠습니다.

중요 참고 사항: 소스 또는 대상(필수)에서 NSX-T를 사용하는 경우 vSwith 또는 vDS 포트 그룹이 아닌 NSX-T 오버레이 네트워크를 사용해야 합니다.

작업이 완료되면 모든 설정을 다시 한 번 확인하고 '마침'을 클릭하세요.

다음 이미지에서 볼 수 있듯이, HCX 네트워크 프로필을 사용하여 컴퓨팅 리소스와 함께 어플라이언스 서비스에 대한 컴퓨팅 프로필이 생성됩니다.

마무리로, 네트워크 프로필을 생성한 후 타겟에 컴퓨팅 프로필도 생성했습니다. 메시가 생성되면 HCX 인프라가 HCX 인터커넥트 어플라이언스와 연결할 준비가 되었습니다.

HCX Cloud Manager 대상에서 HCX 네트워크 프로필과 HCX 컴퓨팅 프로필을 구성하여 이 섹션을 마무리합니다. 다음으로, 모든 HCX Interconnect 서비스 어플라이언스를 배포할 HCX 메시를 생성한 후 두 위치 간 VM 마이그레이션을 시작합니다.

블로그 게시물이 좀 길었다면 죄송하지만, HCX를 사용한 적이 없는 사람도 배포 방법과 작동 방식을 이해할 수 있도록 각 부분을 자세히 설명하고 싶습니다.

다음 HCX 시리즈 블로그 게시물에서는 HCX 메시를 만드는 방법을 설명하겠습니다.

HCX 시리즈:

  • HCX Manager와 Connector를 페어링하여 설치하는 방법
  • HCX – 네트워크 및 컴퓨팅 프로필을 만드는 방법(이것)
  • 서비스 메시를 생성하고 사이트를 연결하는 방법(곧 제공)
  • 네트워크 확장을 생성하고 VM을 마이그레이션하는 방법(곧 제공)
  • … 그리고 더 많은 것

오류:

728x90
728x90
 

HCX Manager와 Connector를 페어링하여 설치하는 방법

한동안 HCX( Hybrid Cloud Extension 의 약자)를 사용하지 않았습니다 . 적어도 인프라 설치는 하지 않았습니다. 최근에는 일부 VM과 앱 마이그레이션에만 사용했습니다. 그래서 HCX 인프라 랩을 구축할 때가 되었고, 이 HCX Manager와 Connector 설치 및 페어링 방법에서 그 방법을 설명하겠습니다.

HCX 관련 글을 몇 개 작성하고 다양한 HCX 구현 및 마이그레이션에 대해 설명하겠습니다. 이 첫 번째 블로그 게시물에서는 HCX Manager OVA와 HCX Connector OVA만 설치하고 사이트 페어링을 진행하겠습니다.

이 초기 HCX 배포를 위한 환경은 다음과 같습니다.

대상: VCF v4.2(vCenter 7.0 및 NSX-T v3.2 포함)
소스: vCenter 7.0(NSX-T 없음)

대상 HCX 관리자: v4.4.0-build 20427536
소스 HCX 커넥터: v4.4.2-build-20502808

라이선스: HCX Advanced 라이선스를 제공하는 NSX-T 라이선스를 사용하겠습니다. 이 실습에서는 이 라이선스로 충분합니다.

HCX Manager OVA 설치는 간단한 OVA 어플라이언스 배포이므로 자세한 내용은 다루지 않겠습니다.

먼저, VMware 계정에서 HCX Manager를 다운로드해야 합니다(AWS, Azure 등에 배포하는 경우 클라우드 서비스에서 OVA를 배포할 수 있습니다).

HCX Manager Appliance를 대상(이 경우 VCF vCenter)에 배포했지만, 이는 필수 사항은 아닙니다. vCenter와 Cloud Director, NSX OVA 등과 마찬가지로, 어떤 vCenter에든 배포한 후 적절한 vCenter/SSO에 연결할 수 있습니다.

위에서 볼 수 있듯이, 이는 비밀번호, IP 주소, 게이트웨이, DNS 등을 설정하는 표준 OVA 배포일 뿐입니다.

참고: 이전 블로그 게시물 에서 설명했듯이 DNS 항목을 두 개 이상 추가하면 어플라이언스가 DNS에 저장되지 않는 버그가 있습니다. 따라서 DNS는 하나만 추가하세요. 어플라이언스 배포 후에 추가 DNS 항목을 추가할 수 있습니다.

HCX Manager가 배포된 후 OVA 배포 시 설정된 관리자 사용자 이름과 비밀번호를 사용하여 https://ip-fqdn:9443을 통해 관리자 VAMI에 연결합니다 .

다음으로, HCX Manager Appliance를 구성해 보겠습니다.

이 섹션에서는 라이선스를 활성화해야 합니다. 위에서 말씀드렸듯이 NSX-T Enterprise 라이선스를 사용할 수 있습니다. 이 경우 복제 지원 vMotion 마이그레이션 , SRM 통합 또는 OS 지원 마이그레이션과 같은 HCX 서비스를 사용하지 않는 한 추가 HCX 라이선스가 필요하지 않습니다. 이러한 서비스에는 HCX Enterprise 라이선스가 필요합니다.

HCX 라이선스에 대한 자세한 내용은 여기에서 확인할 수 있습니다 .

참고: 기본 라이센스 서버 https://connect.hcx.vmware.com을 변경하지 마세요.

라이선스가 활성화되면 HCX가 HCX를 업데이트하고 HCX 서비스를 활성화합니다.

인터넷 연결 상태와 최신 업데이트에 따라 몇 분이 걸릴 수 있습니다.

HCX 관리자가 최신 상태로 업데이트되면 해당 HCX 관리자의 위치를 ​​설정해야 합니다. 온프레미스 배포의 경우 이는 정보일 뿐입니다. 클라우드 배포는 인근 데이터 센터를 사용하는 클라우드 서비스를 위한 것이며 자동으로 수행됩니다.

다음으로, 이 HCX 관리자 시스템의 이름을 지정하세요. 다시 한번 말씀드리지만, 이는 참조용입니다.

다음으로, HCX Manager인 vSphere(VCF이지만 vSphere에 연결될 예정)를 연결합니다. VMware Cloud Director 인프라에도 연결할 수 있습니다.

다음으로, HCX Manager를 대상 vCenter와 NSX-T에 연결합니다. 두 HCX 배포 모두에서 동일한 NSX-T 라이선스를 사용해야 합니다. 대상에서는 NSX-T를 사용하는 것이 필수이지만, 소스에서는 필수가 아닙니다.

다음으로, HCX Manager를 SSO/PSC에 연결합니다. 외부 PSC는 더 이상 지원되지 않으므로 vCenter를 연결해야 합니다.

클라우드 마이그레이션이나 내부적으로 연결되지 않은 사이트에 HCX Manager를 배포하는 경우, 인터넷을 통해 해당 사이트에 연결할 수 있도록 공개 URL을 제공해야 합니다. 내부 HCX 배포이므로 HCX Manager FQDN을 사용할 수 있습니다.

HCX 관리자 초기 구성을 완료했습니다. 설정을 다시 확인하고 '다시 시작'을 클릭하세요.

HCX Manager를 재부팅하면 이제 HCX Manager에 로그인할 수 있습니다. SSO에 연결했으므로 SSO 관리자(또는 관리자 권한이 있는 사용자) 자격 증명을 사용해야 합니다. HCX에서 사용하기 위한 사용자 권한 요구 사항은 여기에서 확인하세요.

참고: 특정 SSO 도메인 이름이 있고 기본값( vsphere.local )을 사용하지 않는 경우, HCX 역할 매핑에서 변경하지 않으면 로그인이 실패합니다. SSO 그룹을 적절한 도메인으로 변경하지 않으면 로그인이 실패하는 문제에 대한 제 블로그 게시물을 참조하세요.

이제 HCX 관리자 대시보드에 연결되었습니다.

사이트 페어링을 시작하기 전에 소스 HCX를 배포해야 합니다. 여기서부터 소스에 HCX 커넥터 배포를 시작합니다.

먼저 시스템 업데이트 로 이동한 다음 업데이트 확인을 클릭합니다 . 그러면 " 다운로드 링크 요청" 링크가 표시됩니다 . 링크를 클릭하면 HCX 커넥터를 다운로드하거나, 링크를 복사하여 브라우저에 붙여넣어 소스 사이트에서 다운로드하는 두 가지 옵션이 있습니다. 저는 링크를 복사하여 소스 사이트 브라우저에 붙여넣고 HCX 커넥터 OVA를 다운로드했습니다.

HCX 커넥터 OVA를 만든 후 소스 vCenter(또는 기타)에 배포합니다. 제 경우에는 소스 vCenter입니다.

배포 및 구성 설정은 위에서 설명한 것과 동일하므로 여기에 다시 표시할 필요가 없습니다.

유일한 차이점은 HCX 커넥터 VAMI에 NSX Manager와 Public Access URL 옵션이 없다는 것입니다. HCX Manager 구성에서는 VM이 ​​마이그레이션될 인프라가 Compute이므로 커넥터에 없는 Compute 옵션이 있습니다.

HCX 커넥터를 소스 vCenter에 배포하고 구성한 후 소스 HCX를 대상 HCX에 연결하여 사이트 페어링을 시작할 수 있습니다.

페어링, 메시 생성 등 모든 작업은 항상 소스 HCX 커넥터에서 HCX 관리자로, 즉 소스에서 목적지로 진행되어야 합니다.

소스 사이트에서 소스 vCenter 관리자 자격 증명으로 HCX 커넥터를 열고(SSO 기본 도메인을 사용하지 않는 경우 역할 매핑을 변경하는 것을 잊지 마세요) 사이트 페어링 옵션으로 이동합니다.

사이트 페어링이 완료되면 이제 목적지와 소스를 확인할 수 있습니다. 소스 HCX 커넥터와 목적지, HCX 관리자를 다시 한번 확인하세요. 사이트가 페어링되었고 모든 연결이 녹색으로 표시되면 확인할 수 있습니다.

사이트 페어링이 모두 녹색(소스 및 대상)이면 두 사이트가 연결되었으며 VM 마이그레이션을 위한 HCX 인프라를 구성하기 위해 상호 연결 구성을 시작할 수 있습니다.

Interconnect 구성 및 설정에 대한 자세한 내용은 다른 블로그 게시물에서 설명하겠습니다.

HCX 시리즈:

  • HCX Manager와 Connector를 페어링하여 설치하는 방법(이것)
  • HCX – 네트워크 및 컴퓨팅 프로필을 만드는 방법
  • 서비스 메시를 생성하고 사이트를 연결하는 방법(곧 제공)
  • 네트워크 확장을 생성하고 VM을 마이그레이션하는 방법(곧 제공)
  • … 그리고 더 많은 것

오류:
HCX 관리자 및 HCX 커넥터 DNS가 HCX 배포 후 작동하지 않습니다.
기본 SSO 관리자를 사용하여 HCX 로그인 오류 액세스가 거부되었습니다.

728x90
728x90

VMware HCX를 사용하여 Azure VMware 솔루션으로 워크로드 마이그레이션: 실용 가이드

VMware HCX를 직접 사용해 본 경험을 바탕으로, 최근 금융 서비스 회사와의 프로젝트 계획의 일환으로 Azure VMware Solution(AVS)에 대해 몇 주 동안 조사했습니다. 해당 고객은 여러 클러스터에 걸쳐 500개의 VM이 있는 온프레미스 VMware 환경을 AVS로 마이그레이션하고자 합니다. 핵심 애플리케이션 리팩토링 없이 데이터 센터를 대피시키려는 목표 때문입니다. 이 블로그 게시물 "VMware HCX를 사용하여 Azure VMware Solution으로 워크로드 마이그레이션: 실무 가이드" 에서는 제가 조사한 내용을 바탕으로 실용적이고 구체적인 계획을 제시하고 이러한 유형의 마이그레이션에 대한 접근 방식을 제시합니다. 자세한 설명은 생략하고, 전략, 아키텍처, 도구, 연구를 통해 얻은 교훈, 그리고 피해야 할 함정에 대해 중점적으로 설명하겠습니다. 이 글은 VMware HCX를 사용하여 온프레미스 환경에서 Azure VMware Solution으로 워크로드를 마이그레이션하려는 모든 분들을 위해 작성되었습니다.

마이그레이션 계획의 토대를 마련하기 위해 AVS와 HCX의 기본 사항을 먼저 살펴보겠습니다.

Azure VMware 솔루션 및 VMware HCX 이해

마이그레이션 계획을 논의하기 전에 AVS와 HCX가 제공하는 서비스를 명확하게 이해하는 것이 중요합니다. 많은 전문가들이 관련된 세부적인 사항들을 과소평가하여 마이그레이션 계획 과정에서 오해와 실수를 저지르게 됩니다.

AVS는 Azure에 호스팅되는 전용 VMware 소프트웨어 정의 데이터 센터(SDDC) 환경을 제공하는 Microsoft 관리 서비스입니다. 컴퓨팅을 위한 vSphere, 스토리지를 위한 vSAN, 네트워크 가상화를 위한 NSX-T 등 익숙한 구성 요소를 포함합니다. 이 환경은 베어 메탈 서버에 호스팅되며 Azure SQL 또는 Azure AD와 같은 네이티브 Azure 서비스와 통합할 수 있습니다. AVS는 온프레미스 VMware 환경을 미러링하므로 고객이 워크로드를 재설계하지 않고도 데이터 센터를 확장하거나 이전할 수 있는 잠재적인 옵션입니다.

VMware HCX는 마이그레이션의 엔진입니다. 대량 VM 이동, 라이브 마이그레이션, 재해 복구 및 네트워크 확장을 위한 도구를 제공하며, 대역폭 사용량을 줄이기 위한 WAN 최적화(압축 및 중복 제거)와 같은 기능도 제공합니다. HCX는 IP 주소를 변경하거나 복잡한 종속성을 재구성하지 않고도 워크로드를 이동할 수 있으므로 AVS(애플리케이션 보안 시스템) 프로젝트에 특히 유용합니다. 제가 사용할 주요 HCX 마이그레이션 방법은 다음과 같습니다.

  • vMotion : 가동 중인 VM을 다운타임 없이 라이브 마이그레이션합니다. 대역폭에 민감하므로 신중한 계획이 필요합니다.
  • 대량 마이그레이션 : 최소 컷오버 다운타임(~분)으로 예약된 복제를 수행합니다. 대용량 작업에 적합합니다.
  • 복제 지원 vMotion(RAV) : 사전 시딩과 vMotion을 결합하여 데이터베이스와 같은 대규모의 높은 변경률의 VM을 지원합니다.
  • 콜드 마이그레이션 : 마이그레이션 전에 전원을 끌 수 있는 VM의 경우 레거시 또는 테스트 워크로드에 자주 사용됩니다.
  • OS 지원 마이그레이션(OSAM) : 물리적 서버나 Hyper-V 워크로드를 vSphere로 마이그레이션하는 데 사용됩니다.

올바른 마이그레이션 유형을 선택하는 것이 중요합니다. 중요한 워크로드에는 vMotion을, 일반 VM에는 Bulk를, 그리고 vSphere가 아닌 환경처럼 필요한 경우에만 OSAM을 혼합하여 사용하는 것을 권장합니다. 참고로, 아래 비교표를 참고해 보세요.

이러한 기술을 미리 이해하면 불필요한 위험과 다운타임을 방지하는 데 도움이 됩니다. 이는 복잡한 프로젝트를 시작하기 전에 도구를 미리 아는 것과 같습니다. 성공으로 가는 지름길입니다. 이러한 기반을 마련한 후, 다음 단계는 고객 환경을 면밀히 평가하여 마이그레이션 준비 상태를 확인하는 것입니다.

이주 전 평가

적절한 탐색 단계는 모든 성공적인 AVS 마이그레이션의 기반입니다. 제 연구에 따르면 이 단계를 건너뛰거나 서두르면 심각한 문제가 발생할 수 있으므로, VMware 네이티브 도구와 Azure 네이티브 도구를 함께 사용하여 고객 환경을 분석하는 데 충분한 시간을 할애하여 준비 상태를 유지하는 것이 좋습니다.

저는 다음과 같은 방식으로 평가에 접근하기를 제안합니다.

  • VM 인벤토리 및 크기 조정 : RVTools 또는 vRealize Operations를 사용하여 CPU, RAM, 디스크 및 스냅샷 정보를 수집합니다. Azure Migrate는 크기 권장 사항을 생성하고 레거시 OS 버전과 같이 지원되지 않는 구성을 플래그로 지정할 수 있습니다.
  • 애플리케이션 종속성 매핑 : Azure Migrate의 종속성 시각화를 활용하여 최소 30일 동안 실행하여 트래픽 흐름을 파악합니다. 이를 통해 문서화되지 않은 MSSQL 인스턴스에 백엔드 호출을 수행하는 레거시 웹 서버와 같은 숨겨진 종속성을 파악할 수 있습니다.
  • 호환성 검사 : vSphere 버전(6.5 이상), 가상 하드웨어 호환성, OS 지원 및 네트워크 토폴로지를 확인하세요. 검증을 위해 VMware 상호 운용성 매트릭스 및 HCX 설명서를 활용하세요.
  • 워크로드 분류 : 미션 크리티컬, 프로덕션, 개발, 보관 등의 범주로 워크로드를 분류합니다. 이를 통해 단계별 마이그레이션 및 롤백 옵션을 계획하는 데 도움이 됩니다.
  • 특수 워크로드 : 원시 장치 매핑(RDM), PCI 패스스루 장치 또는 HCX 복제 제한(일반적으로 8TB)을 초과하는 대용량 디스크 등 추가 계획이 필요한 VM을 파악합니다. 문제 발생을 방지하기 위해 RDM을 VMDK로 변환하는 것을 계획합니다.
  • 규정 준수 평가 : 규정 준수를 보장하기 위해 GDPR이나 HIPAA와 같은 요구 사항을 Azure 정책에 매핑합니다.

철저한 마이그레이션 전 평가는 마치 집을 짓기 위한 기초를 다지는 것과 같습니다. 이 부분이 제대로 된다면 나머지 마이그레이션은 훨씬 더 수월해집니다. 중요한 것은 잠재적인 장애물을 조기에 파악하는 것입니다. 평가가 계획되었으니, 이제 HCX 통합을 위한 온프레미스 환경을 준비하는 단계로 넘어가겠습니다.

온프레미스 환경 준비

발견 단계가 완료되면 다음 단계는 HCX 통합을 위해 고객의 온프레미스 인프라를 준비하는 것입니다. 이 단계는 대부분 기술적인 내용이지만, 지연으로 인해 일정이 지연되는 것을 방지하기 위해 네트워크 및 방화벽 팀과 조기에 협력하는 것이 좋습니다.

제가 제안하는 준비 계획은 다음과 같습니다.

  • HCX 커넥터 배포 : vSphere 환경에 HCX 커넥터 OVA를 배포합니다. vCenter 및 NSX Manager에 등록하고, 서비스 메시 설정을 진행하기 전에 등록이 완료되었는지 확인합니다.
  • 네트워크 구성 및 준비 :
    • 온프레미스 사이트와 AVS 환경 간의 레이어 3 연결을 검증합니다.
    • 모든 HCX 어플라이언스 간에 필수 포트(TCP 443, UDP 4500)를 엽니다.
    • vCenter, HCX 및 NSX 구성 요소에 대한 DNS 확인을 양방향으로 보장합니다.
    • 인증이나 복제에 영향을 미치는 시간 편차 문제를 방지하려면 NTP 설정을 동기화하세요.
  • 워크로드 그룹화 : 애플리케이션, 종속성 및 비즈니스 기간을 기준으로 논리적 마이그레이션 그룹을 생성합니다. 이를 통해 웹 서버와 데이터베이스를 그룹화하는 등 마이그레이션 계획 수립 및 테스트가 간소화됩니다.

온프레미스 환경을 철저히 준비하는 것이 전체 마이그레이션의 토대를 마련합니다. 시간 동기화 문제와 같은 사소한 실수가 문제 해결에 몇 시간씩 소요될 수 있으므로, 세부 사항에 대한 주의가 매우 중요합니다. 이제 환경이 준비되었으니, 마이그레이션 아키텍처를 설계할 전략적 계획 단계로 넘어가겠습니다.

VMware에서 AVS로의 마이그레이션을 위한 전략적 계획

전략적 계획은 마이그레이션이 구체화되는 단계입니다. 이 단계에서는 네트워킹, 리소스 크기 조정, HCX 구성, AVS 설정 등을 신중하게 고려해야 합니다. 성공적인 마이그레이션을 위해 이 단계를 핵심 영역으로 나누어 설명하겠습니다.

네트워킹 고려 사항

이는 아키텍처에서 가장 복잡한 부분입니다. HCX와 AVS의 네트워킹은 강력하지만 잘못 구성하면 심각한 문제를 야기할 수 있습니다. 따라서 고객의 잠재적 요구 사항에 맞춰 세부적으로 살펴보겠습니다.

  • ExpressRoute : 낮은 지연 시간과 높은 대역폭이 필요한 프로덕션 워크로드(예: 실시간 데이터를 사용하는 금융 앱)에 권장됩니다. 프라이빗 피어링을 사용하고 HCX 성능을 위해 MTU 설정이 1600바이트를 지원하는지 확인하십시오. 대규모 배포 또는 다중 사이트 연결이 필요한 고객에게 적합합니다.
  • 사이트 간 VPN은 지연 시간 허용 범위가 높은 소규모 또는 테스트 환경에 비용 효율적인 대안입니다. 고객의 초기 마이그레이션이 파일럿 단계 또는 중요하지 않은 워크로드로 제한되는 경우에 이상적입니다.
  • 결정 매트릭스 : 100개 이상의 VM이나 고성능 요구 사항에는 ExpressRoute를 사용하고, 50개 미만의 VM이나 초기 테스트에는 VPN을 사용합니다.
  • 글로벌 도달 범위 : ExpressRoute 회선이 여러 Azure 지역에 걸쳐 있는 경우(예: 고객이 미국 동부 및 서부 지역에서 운영하는 경우) 필요합니다. 허브와 AVS 프라이빗 클라우드 간 라우팅을 지원합니다. 고객이 다중 지역 전략을 사용하는 경우 이 기능을 고려하십시오.
  • 2계층 네트워크 확장 : HCX NE를 사용하면 VM이 IP 주소를 유지할 수 있습니다. 각 어플라이언스는 최대 8개의 VLAN을 지원하므로, 고객이 더 많은 네트워크를 확장해야 할 경우 추가 어플라이언스를 계획하십시오.
  • 모빌리티 최적화 네트워킹(MON) : Azure를 통해 최적화된 송신을 활성화하여 비대칭 라우팅을 해결합니다. 특히 고객이 확장된 네트워크를 사용하는 경우, 반환 트래픽에 대한 방화벽 규칙을 구성하세요.
  • 허브-스포크 토폴로지 : 공유 서비스(DNS, ID, 모니터링)를 사용하는 허브에 연결된 스포크 VNet에 AVS를 배치합니다. 고객은 보안 및 관리를 중앙에서 관리하는 것이 좋습니다.
  • Azure vNet 통합 : Azure 서비스를 사용한 하이브리드 시나리오에서 허브 VNet과 AVS VNet을 연동하여 고객이 Azure 기본 도구를 활용할 수 있도록 보장합니다.

네트워크 설정 다이어그램은 다음과 같습니다.

 
1
2
3
 
<a href="https://www.provirtualzone.com/wp-content/uploads/2025/05/HCX-to-AVS-04.png"><img class="alignnone wp-image-20885" src="https://www.provirtualzone.com/wp-content/uploads/2025/05/HCX-to-AVS-04.png" alt="Migrating Workloads to Azure VMware Solution with VMware HCX: A Practical Guide" width="850" height="670" /></a>
 

AVS 구성

AVS 환경 구성은 고객의 요구를 충족하는 데 매우 중요합니다. 여기에는 온프레미스 환경 및 마이그레이션 목표에 맞춰 SDDC를 설정하는 것이 포함됩니다.

  • 노드 크기 조정 : 최소 3개 노드 클러스터에서 AV36개 노드(36코어, 576GB RAM, 15.36TB NVMe)로 시작하세요. 고객의 VM 수(예: VM 500개에는 6~8개 노드가 필요할 수 있음)와 성능 요구 사항에 따라 확장하세요.
  • vSAN 구성 : 중복성을 위해 Fault Tolerance(FTT=1, RAID-1)를 활성화합니다. 스토리지 최적화를 위해 중복 제거 및 압축을 계획하되, 복제 트래픽 및 스냅샷으로 인한 잠재적 오버헤드를 모니터링합니다.
  • NSX-T 설정 : 고객의 온프레미스 네트워크 토폴로지에 맞게 NSX-T 세그먼트를 구성합니다. L2 확장 통합을 계획하고 보안 정책(예: 분산 방화벽 규칙)을 정의합니다.
  • Azure 통합 : Azure vNet 피어링을 설정하고 공유 서비스(예: DNS, Azure AD)를 위한 허브 VNet과 통합합니다. 고객의 기존 Azure 구독과의 호환성을 보장합니다.
  • 리소스 할당 : Azure Migrate 크기 권장 사항에 따라 CPU, RAM 및 스토리지를 할당하고 성장에 대비해 20~30% 여유 공간을 추가합니다.

AVS를 사용한 HCX에 대한 네트워크 설계 고려 사항

VMware HCX를 사용하여 온프레미스 환경에서 Azure VMware Solution으로 워크로드를 마이그레이션할 때 네트워크 설계는 아키텍처에서 가장 중요한 부분 중 하나가 됩니다. HCX가 모빌리티 및 네트워크 확장의 복잡성을 상당 부분 처리하지만, 부적절한 라우팅, 세분화 및 어플라이언스 배치 계획은 심각한 중단이나 마이그레이션 실패를 초래할 수 있습니다.

이 섹션의 개념을 뒷받침하기 위해 HCX를 AVS로 마이그레이션할 때 가장 중요한 네트워크 설계 고려 사항을 요약한 아래 이미지를 만들었습니다.

허브 앤 스포크 토폴로지

다이어그램의 왼쪽 상단 사분면은 허브-스포크 네트워크 아키텍처를 보여줍니다 . 이는 Azure에서 권장되는 디자인 패턴입니다. AVS 프라이빗 클라우드는 스포크 가상 네트워크(VNet)로 배포되는 반면, 허브에는 DNS, Active Directory, NVA 방화벽, 모니터링, ExpressRoute 게이트웨이와 같은 중앙 집중식 서비스가 포함됩니다. 각 스포크는 VNet 피어링을 통해 허브에 연결되어 공유 서비스를 통한 트래픽 흐름을 허용하는 동시에 스포크 간 수평 이동을 격리합니다.

이러한 설계는 라우팅을 간소화하고, 중앙 지점에서 보안 정책을 시행하며, 여러 지역이나 환경 전반에서 일관성을 보장합니다.

NSX-T 세그먼트 계획

AVS는 네트워크 가상화에 NSX-T를 사용하고 , HCX는 온프레미스 환경에서 AVS로 레이어 2 네트워크를 확장할 수 있습니다. 하지만 모든 네트워크를 확장할 수 있거나 확장해야 하는 것은 아닙니다.

이미지의 오른쪽 상단 사분면은 일반적인 문제인 서브넷 중복을 보여줍니다 . 기존 세그먼트와 동일한 IP 범위를 사용하는 AVS로 네트워크를 확장하면 라우팅 충돌과 예측할 수 없는 동작이 발생합니다. 이미지는 서브넷을 복제할 때 192.168.12.0/24여러 소스에서 확장되거나 두 번 이상 사용될 경우 문제가 발생할 수 있음을 보여줍니다.

네트워크 확장을 배포하기 전에 항상 서브넷을 신중하게 문서화하고 계획하세요.

서비스 메시 범위

왼쪽 하단 사분면에서는 HCX 서비스 메시 고려 사항을 다룹니다. 이는 HCX 연결의 핵심으로, 온프레미스 환경과 AVS 환경 간의 경로를 정의합니다. 각 서비스 메시에는 양쪽에 구축된 인터커넥트 및 네트워크 확장과 같은 어플라이언스가 포함됩니다.

주요 고려 사항:

  • 각 NE 어플라이언스는 최대 8개의 확장 네트워크를 지원합니다.
  • 처리량 제한 과 예상 마이그레이션 동시성을 고려해야 합니다.
  • 서비스 메시는 클러스터별로 신중하게 범위를 지정해야 합니다.

이 다이어그램은 NE 어플라이언스가 확장 한계에 도달할 수 있음을 보여줍니다. 8개 이상의 네트워크를 확장하는 경우, 추가 어플라이언스를 구축하거나 여러 메시에 걸쳐 마이그레이션을 분할하십시오.

모빌리티 최적화 네트워킹(MON)

이는 레이어 2 네트워크 확장을 사용할 때 가장 간과되지만 중요한 기능 중 하나입니다. 이미지 중앙에 표시된 것처럼, 모빌리티 최적화 네트워킹(MON)을 사용하면 마이그레이션된 VM이 원래 온프레미스 IP 주소를 유지하더라도 AVS의 로컬 라우팅을 사용할 수 있습니다.

MON이 없으면 인터넷이나 Azure 서비스에서 반환되는 트래픽이 온프레미스 게이트웨이를 통해 다시 라우팅되어 비대칭 라우팅 및 트래픽 손실이 발생할 수 있습니다. 다이어그램은 두 가지 가능한 흐름을 보여줍니다.

  • VM이 Azure 게이트웨이를 직접 사용하는 파선 HCX MON 경로
  • 라우팅 문제를 야기하는 최적화되지 않은 경로인 비대칭 경로로 표시된 곡선 경로

MON을 활성화하려면 다음이 필요합니다.

  • AVS 세그먼트에 NSX-T 게이트웨이 지원이 있는지 확인하십시오.
  • 로컬 이탈을 허용하기 위한 올바른 방화벽 규칙
  • 라우팅 변경 및 테스트 검증에 대한 인식

MON은 특히 Azure 네이티브 서비스나 인터넷 엔드포인트에 액세스하는 애플리케이션의 경우 많은 마이그레이션 이후 문제를 해결합니다.

방화벽 및 라우팅

오른쪽 상단 사분면에 표시된 또 다른 핵심 사항은 방화벽과 라우팅 인식 의 중요성입니다 . HCX는 모든 어플라이언스 간에 여러 포트(예: TCP 443 및 UDP 4500)를 양방향으로 개방해야 합니다. 특히 MON이 활성화된 경우 리턴 라우팅은 예측 가능하고 대칭적이어야 합니다 .

Azure 또는 온프레미스에서 네트워크 가상 어플라이언스(NVA)를 사용하는 경우, 해당 어플라이언스가 NAT를 수행하거나 HCX가 사용하는 트래픽을 차단하지 않는지 확인하세요. 연결 문제가 발생하는 경우, 방화벽이나 라우팅 구성 오류로 인해 발생하는 경우가 많습니다.

ExpressRoute 및 MTU 고려 사항

마지막으로, 오른쪽 하단 사분면은 많은 팀이 검증 과정에서 간과하는 MTU 크기와 ExpressRoute 구성을 강조합니다 . HCX Interconnect 트래픽은 단편화에 민감합니다. AVS 환경에는 최소 1500의 MTU가 필요하며 , 특히 대량 또는 RAV 마이그레이션 방식을 사용할 때 성능과 안정성을 위해 점보 프레임(1600바이트 이상)을 활성화하는 것이 좋습니다.

프로덕션 마이그레이션을 시작하기 전에 항상 MTU 경로를 종단 간 테스트하세요.

클러스터 및 리소스 계획

AVS 프라이빗 클라우드는 단순히 온프레미스 호스트 수만이 아니라 고객의 실제 사용 데이터를 기반으로 해야 합니다. AVS 노드는 일관된 성능을 제공하지만, 통합에는 신중한 계획이 필요합니다.

  • 용량 계획 : CPU, RAM 및 스토리지 사용량 보고서에는 Azure Migrate 또는 vRealize Operations를 사용하세요. 용량 증가 및 급증에 대비하여 20~30%의 여유 용량을 추가하세요.
  • 클러스터 크기 조정 : 최소 3개 노드 클러스터로 시작하여 500개 VM 부하에 따라 점진적으로 확장합니다.
  • 스토리지 고려 사항 : 중복성을 위해 FTT=1, RAID-1로 vSAN을 구성하십시오. 스토리지 사용량을 관리하기 위해 중복 제거/압축을 모니터링하십시오.

HCX 서비스 메시 및 마이그레이션 방법

HCX 서비스 메시는 마이그레이션 트래픽 흐름 방식을 정의하여 마이그레이션 인프라의 초석을 제공합니다. 이 부분의 구성 오류는 프로젝트를 방해할 수 있습니다.

  • 서비스 메시 배포 : 온프레미스 HCX 커넥터를 AVS HCX Cloud Manager와 연결합니다. 정확한 라우팅을 위해 컴퓨팅 및 네트워크 프로필을 정의합니다.
  • HCX Interconnect : 안전하고 암호화된 마이그레이션 트래픽을 처리합니다. 적절한 대역폭을 확보하세요.
  • 네트워크 확장(NE) : L2 확장에 필요함. 용량(어플라이언스당 8개 VLAN)을 계획합니다.
  • 모빌리티 최적화 네트워킹(MON) : 마이그레이션 후 비대칭 라우팅을 방지합니다.
  • 마이그레이션 방법 :
    • vMotion: 중요한 앱(예: 웹 서버).
    • 대량: 개발/테스트 VM.
    • RAV: 데이터베이스(예: SQL Server).
    • 추위: 레거시 시스템.
    • OSAM: 물리적 Linux 서버.

서비스 메시 레이아웃은 다음과 같습니다.

계획 단계에서 네트워킹, AVS 구성, 크기 조정 및 HCX 구성을 정확하게 설정하는 것은 매우 중요합니다. 마치 튼튼한 집의 기초를 쌓는 것과 같습니다. 서브넷 겹침과 같은 작은 실수도 심각한 지연을 초래할 수 있습니다. 아키텍처 설계를 완료했으니, 이제 마이그레이션 실행 계획 단계로 넘어가 보겠습니다.

마이그레이션 실행 및 운영

마이그레이션을 효과적으로 실행하려면 신중한 계획과 엄격한 검증이 필요합니다. 바로 이 부분에서 준비가 빛을 발하며, 성공을 위한 체계적인 접근 방식을 간략하게 설명하겠습니다.

제가 제안하는 실행 계획은 다음과 같습니다.

  • HCX 설정 : HCX Manager를 사용하여 온프레미스 vCenter와 AVS vCenter를 페어링합니다. 컴퓨팅/네트워크 프로필을 사용하여 서비스 메시를 배포합니다.
  • 네트워크 확장 : HCX NE를 통해 VLAN을 확장하고, ping 테스트로 검증하여 문제를 조기에 포착합니다.
  • 파일럿 웨이브 : 대량 마이그레이션을 사용하여 프로세스를 테스트하기 위해 5~10개의 비중요 VM으로 시작합니다.
  • 예약된 웨이브 : 비즈니스 윈도우에 맞춰 조정하세요. 중요한 VM에는 vMotion/RAV를 사용하여 다운타임을 최소화하세요.
  • 롤백 전략 : 검증될 때까지 전원이 꺼진 소스 VM을 보관합니다.
  • 모니터링 및 로깅 : HCX 대시보드를 사용하고 추적을 위해 VM에 태그를 지정하여 가시성을 유지합니다.

마이그레이션 워크플로는 다음과 같습니다.

성공의 핵심은 각 단계마다 엄격한 검증을 거치는 단계적 접근 방식입니다. 파일럿 웨이브는 실제 운영 환경으로의 마이그레이션 전에 문제를 파악하고 해결하는 데 도움이 될 것입니다. 워크로드가 AVS에 배치되면 다음 단계는 최적화 및 완료를 위한 계획 수립입니다.

마이그레이션 후 최적화 및 마무리

마이그레이션 후 최적화는 간과되는 경우가 많지만, AVS로 워크로드를 이전하여 얻을 수 있는 이점을 최대한 활용하는 데 매우 중요합니다. 이 단계는 최적의 성능, 리소스 효율성 및 비용 관리를 보장합니다.

제가 추천하는 최적화 계획은 다음과 같습니다.

  • 성능 검증 : Azure Monitor와 vRealize Operations를 사용하여 CPU, 메모리, 디스크 지연 시간 및 네트워크 처리량을 확인합니다.
  • 검증 체크리스트 :
    • 앱 기능.
    • DNS 확인.
    • 네트워크 연결성.
  • 워크로드 적정 크기 조정 : VM 크기가 너무 크면 리소스가 낭비됩니다. Azure 권장 사항을 활용하여 가능한 경우 VM 크기를 줄이세요.
  • 네트워크 확장 해제 : NSX-T 세그먼트로 전환한 후 사용하지 않는 L2 확장을 제거합니다.
  • 비용 관리 : Azure Cost Management를 사용하여 예산과 알림을 설정하고, 업무 시간 외에는 프로덕션 환경이 아닌 VM의 종료를 예약할 수 있습니다.
  • 거버넌스 :
    • Azure Automation으로 패치합니다.
    • Azure Policy 준수 여부를 감사합니다.

마이그레이션 후 최적화는 AVS에 대한 투자를 극대화하고 장기적인 안정성을 보장합니다. 단순히 클라우드에 접속하는 것만이 아니라, 클라우드에 접속한 후 효율적으로 운영하는 것이 중요합니다. 최적화된 환경을 바탕으로 보안, 규정 준수 및 거버넌스의 핵심 측면을 살펴보겠습니다.

보안, 규정 준수 및 거버넌스

워크로드를 AVS로 마이그레이션하려면 인프라를 Azure의 거버넌스 및 보안 모델과 통합해야 합니다. 워크로드를 보호하고 신뢰를 유지하려면 조직의 표준을 AVS 환경으로 원활하게 확장하는 것이 필수적입니다.

제가 제안하는 보안 및 거버넌스 계획은 다음과 같습니다.

  • ID 및 액세스 관리(IAM) : 역할 기반 액세스 제어(RBAC)를 위해 Azure Active Directory(Azure AD)를 통합합니다. vCenter 접근 권한을 필수 인력으로 제한합니다.
  • 보안 통합 : Azure Firewall, Defender for Cloud, Azure Sentinel을 사용하여 위협을 탐지하고 대응합니다.
  • 규정 준수 관리 : Azure Policy를 활용하여 PCI-DSS, GDPR 또는 ISO 27001과 같은 표준을 시행합니다. Azure Security Center를 통해 정기 감사를 수행합니다.
  • 중앙 집중식 로깅 및 모니터링 : 가시성을 높이기 위해 Azure Monitor 또는 Sentinel로 로그를 스트리밍합니다.

강력한 보안, 규정 준수 및 거버넌스 조치는 워크로드를 보호하고 비즈니스 연속성을 보장하는 데 필수적이며, 특히 금융과 같이 규제가 엄격한 산업의 경우 더욱 그렇습니다. 마이그레이션 계획에 대한 최종적인 생각과 의견을 공유해 보겠습니다.

마지막 생각

VMware HCX를 사용하여 AVS로 마이그레이션을 계획하는 것은 전략적이고 세부적인 작업으로, 신중한 준비와 VMware에 대한 심층적인 전문 지식이 필요합니다. 제 연구에 따르면 성공적인 마이그레이션은 정확한 평가, 세부적인 준비, 견고한 네트워킹 구성, 적절한 AVS 설정, 그리고 철저한 마이그레이션 후 최적화에 달려 있습니다. 고객의 500개 VM을 이전하는 이 계획은 최소한의 중단으로 원활하게 전환하기 위한 체계적인 접근 방식을 제시합니다.

HCX와 AVS를 통해 제공되는 기술과 도구 덕분에 프로세스 관리가 더욱 수월해졌지만, 명확한 소통, 상세한 문서화, 그리고 모든 단계에서 엄격한 검증의 중요성을 절대 과소평가해서는 안 된다는 것을 깨달았습니다. 마이그레이션 기간을 비즈니스 요구 사항에 맞추고 팀 간의 원활한 협업을 보장하는 것은 기술 설정만큼이나 중요합니다. 사전 계획 및 테스트에 상당한 노력을 투자하는 것을 강력히 권장합니다. 위험을 줄일 수 있고, 원활한 전환을 보장하여 마이그레이션을 단순한 기술적 성과가 아닌 비즈니스 성공으로 만들어 줍니다.

제 연구 결과와 이 계획이 AVS 마이그레이션 여정에 도움이 되기를 바랍니다. 궁금한 점이나 공유하고 싶은 경험이 있으시면 언제든지 댓글을 남겨주시거나 직접 연락해 주세요. 앞으로 더 많은 논의를 기대하겠습니다.

자주 묻는 질문

제가 자주 접하는 질문에 대한 답변은 다음과 같습니다.

  • 예상 다운타임은 얼마나 되나요? vMotion은 다운타임이 없고, 대량 마이그레이션은 몇 분 정도 걸리며, 콜드 마이그레이션은 다운타임이 더 길어집니다.
  • AVS 라이선스는 어떻게 적용되나요? Azure Hybrid Benefit을 사용하면 Windows Server 및 SQL Server 라이선스 비용을 절감할 수 있습니다.
  • 문제가 발생하면 어떻게 되나요? 안전한 롤백을 위해 마이그레이션된 워크로드의 유효성이 완전히 검증될 때까지 소스 VM을 보관하세요.

추가 자료 및 공식 참조

공식 문서를 살펴보거나 HCX 및 Azure VMware Solution의 특정 영역을 더 자세히 알아보고 싶은 독자를 위해 다음과 같은 권장 리소스를 소개합니다.

워크로드 검색 및 평가에 대한 Azure Migrate 설명서를 검토할 수도 있습니다 .

VMware HCX를 사용하여 Azure VMware 솔루션으로 워크로드 마이그레이션: 실용 가이드

728x90

+ Recent posts