마이그레이션을 위해 Azure VMware Solution 노드의 크기를 조정하는 방법

점점 더 많은 고객이 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 노드 평가에 도움이 되기를 바랍니다. 이 작업이 완료되면 네트워크 토론 및 전체 마이그레이션 계획을 빠르게 시작할 수 있습니다.즐거운 학습 되세요!