마이그레이션을 위한 Azure VMware 솔루션 노드 크기 조정 방법

점점 더 많은 고객이 마이그레이션 대상으로 Azure VMware Solution을 탐색하기를 요청하고 있으므로 많은 아키텍트와 사전 판매 담당자의 가장 흔하고 첫 번째 문제 중 하나를 해결하는 것에 대해 생각해 보았습니다. Azure VMware Solution 노드의 크기를 조정하는 방법은 무엇입니까? AVS 설계에 관련된 네트워크 설계 및 구성 요소를 살펴보기 전에. 대부분의 경우 고객은 온프레미스 워크로드에 맞는 노드 수와 해당 노드의 비용을 결정해야 합니다.

이 블로그 전체에서 vCPU, 메모리, 스토리지에 집중하는 이유는 무엇일까요? AVS 노드는 특정 크기로 제공되기 때문입니다. 예를 들어, AV36p의 한 노드는 36개의 물리적 코어, 768GB 메모리, 19.20TB NVMe 스토리지를 갖습니다. 배포에 필요한 노드 수를 알아내야 합니다. 그리고 그에 따라 노드를 계속 추가하게 됩니다.

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

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

• Manual Method  : 이 방법은 주로 사용 중인 vCPU 수, 메모리 및 스토리지에 따라 AVS 노드 크기를 조정하는 것을 포함합니다. 따라서 기본적으로 VMware 클러스터의 현재 크기에 따라 AVS 노드 크기를 조정하게 됩니다. 이는 예산 크기 조정일 수도 있는데, VM에 vCPU가 16개 있지만 4개만 사용하는 경우 AVS 노드의 전체 크기 조정에서 여전히 16개의 vCPU를 고려하고 실제 사용률은 고려하지 않기 때문입니다.
• Azure Migrate Method : 이 방법에서는 Azure Migrate와 같은 도구를 사용하여 평균 또는 최대 부하를 기준으로 VM 사용률을 계산하고 이를 기준으로 AVS 노드 크기를 정확하게 조정하는 데 도움이 됩니다. 이는 VM에 대해 16개의 vCPU를 구성했지만 4개만 사용하더라도 4개의 vCPU만 고려하기 때문에 적절한 크기입니다. 따라서 크기가 정확하고 적절합니다. 사용 가능한 또 다른 방법은 RVTools 가져오기 기반 평가입니다. 이는 수동 방법에서 달성하는 것과 마찬가지로 있는 그대로의 크기입니다. 다만 UI 중심적이며 수동 계산이 포함되지 않습니다.

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

수동 방법을 사용하여 있는 그대로 크기를 조정하고 VMware 환경에서 모든 VM의 vCPU, 메모리 및 스토리지 사용률을 파악하는 데 RVTools는 이상적인 도구로 돋보입니다.

Manual Method

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

• CPU: VM과 연결된 vCPU를 보여줍니다.
• 메모리: 여기에는 할당된 메모리가 포함됩니다.
• 사용 중 MiB: 현재 사용된 저장소 용량을 보여줍니다.
• 프로비저닝된 MiB: 여기에는 할당된 스토리지가 포함됩니다. 스토리지는 외부 스토리지의 도움으로 요구 사항에 따라 확장될 수 있으므로 이 열은 고려하지 않을 것입니다. 따라서 In-use-MiB만 고려합니다.

AVS 노드 크기:

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

이제 rvtools 크기에 따라 필요한 총 vCPU, 메모리 및 스토리지를 파악하고 요구 사항에 맞게 AVS 노드 수를 조정할 수 있습니다.

저장 크기:

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

1. VM 스토리지 정책을 생성할 때 선택하는 RAID(RAID 1, 5 또는 6)
2. 저장 정책 중 선택한 FTT(FTT 1, 2, 3)
3. Slack 공간 사용 가능(SLA를 얻으려면 최소 25%의 여유 공간이 필요함)
4. 체크섬(평균 5%)
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의 메모리를 맞추려면 노드가 하나 더 필요하므로 총 5개의 AV36p 노드가 필요합니다. 4개의 노드를 선택하는 데 메모리가 병목 현상이 되기 때문입니다. 5개의 AVS 노드를 사용하면 최대 77.6TB의 사용 가능한 스토리지만 받게 되므로 ANF 또는 ESAN에서 추가 스토리지를 얻을 수 있습니다. 따라서 외부 스토리지는 크기 조정에 12.37TB가 필요합니다. 여기 있습니다. 전체 마이그레이션에 필요한 5개의 AV36p 노드입니다.

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

Azure Migrate based sizing

위의 크기 조정은 수동 방법을 사용하여 수행했습니다. Azure Migrate를 사용하면 더 자동화된 방식으로 크기를 조정할 수 있습니다. Azure Migrate를 통해 수행하더라도 저장소 크기 조정 및 CPU 오버커밋에 대한 메트릭과 매개변수는 동일하게 유지됩니다. Azure Migrate를 사용하여 수행할 수 있는 두 가지 주요 AVS 크기 조정 유형이 있습니다.

1. 어플라이언스 기반: Azure Migrate 어플라이언스 설치 및 성능 평가 또는 있는 그대로에 따라 크기 조정 내보내기
2. 가져오기 기반: rvtools export를 사용하면 Excel 파일을 Azure Migrate 프로젝트로 가져올 수도 있으며, 이를 통해 있는 그대로의 크기 조정이 가능합니다.

Appliance Based

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

Azure Migrate 기반 어플라이언스를 사용하여 모든 서버를 발견했다고 가정하고 평가를 만드는 방법으로 넘어가겠습니다.

AVS 평가 선택.

검색 소스가 Azure Migrate Appliance로 선택되어 있는지 확인합니다.

출력이 이러한 선택에 따라 결정되므로 올바른 매개변수 집합을 선택했는지 확인하세요.

평가할 서버를 선택하세요.

AVS 평가가 생성되면 보고서의 출력입니다. 여기에는 필요한 노드 수와 스토리지도 표시됩니다.

Import Based

이는 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 노드 평가에 도움이 되기를 바랍니다. 이 작업이 완료되면 네트워크 논의와 전반적인 마이그레이션 계획을 빠르게 시작할 수 있습니다.

즐거운 학습이 되세요!