Microsoft HPC 팩을 사용하여 Azure 노드의 대규모 배포 모범 사례

서비스 팩 1이 포함된 HPC Pack 2008 R2부터 Windows HPC 클러스터 관리자 및 개발자는 Azure에서 주문형 계산 리소스를 추가하여 온-프레미스 클러스터의 성능을 높일 수 있습니다. Azure 작업자 역할 인스턴스를 사용하는 이 HPC 클러스터 "버스트" 시나리오는 더 큰 HPC 워크로드를 가능하게 하며, 때로는 온-프레미스 클러스터 리소스 외에도 수천 개의 코어가 필요합니다. 이 항목에서는 온-프레미스 HPC 팩 클러스터에서 Azure 노드의 대규모 배포를 계획하고 구현하는 데 도움이 되는 지침 및 모범 사례 권장 사항을 제공합니다. 이러한 권장 모범 사례는 Azure 배포 시간 제한, 배포 실패 및 라이브 인스턴스 손실을 최소화하는 데 도움이 됩니다.

.NET용 HPC 팩 및 Azure SDK의 적용 가능한 버전

이러한 권장 사항은 일반적으로 HPC Pack 2012 R2 및 HPC Pack 2012를 기반으로 하지만 HPC Pack 2008 R2로 수행되는 대규모 배포에도 유용합니다.

다음 표에서는 HPC 팩의 버전과 이러한 지침이 적용되는 .NET용 Azure SDK의 관련 버전을 나열합니다.

Azure 노드의 대규모 배포에 대한 임계값

HPC 클러스터에 대한 Azure 노드 배포는 헤드 노드의 구성을 고려해야 할 때와 배포에서 단일 클라우드 서비스에서 사용할 수 있는 리소스의 Azure 클러스터의 상당 부분을 요구할 때 "큰"으로 간주됩니다. 배포가 클수록 배포 시간이 초과되고 라이브 인스턴스가 손실될 수 있습니다.

다음 표에서는 단일 클라우드 서비스에서 Azure 노드를 대규모로 배포하기 위해 일반적으로 사용되는 역할 인스턴스의 실제 임계값을 나열합니다. 임계값은 Azure 역할 인스턴스에 대해 선택된 가상 머신 크기(Azure에 미리 정의됨)에 따라 달라집니다.

각 크기에 대한 CPU 코어 및 메모리 수를 포함하여 각 가상 머신 크기에 대한 자세한 내용은 Cloud Services의 크기를 참조하세요.

안정성이 높은 한 서비스에 이러한 임계값 이상의 역할 인스턴스를 배포하려면 일반적으로 Azure 운영 팀의 수동 참여가 필요합니다. 이 작업을 시작하려면 Microsoft 영업 담당자, Microsoft 프리미어 지원 계정 관리자 또는 Microsoft 지원에 문의하세요. 지원 계획에 대한 자세한 내용은 Azure 지원을 참조하세요.

모든 Azure 노드 배포에 적용되는 하드 적용 가능한 제한은 없지만 클라우드 서비스당 1000개의 인스턴스는 실제 프로덕션 제한입니다.

대규모 배포에 Azure를 사용하는 모범 사례

다음은 HPC 클러스터에서 대규모 Azure 배포를 성공적으로 만들고 사용하기 위한 일반적인 지침입니다.

Azure 운영 팀에 초기 신호 제공

데이터 센터의 전용 Azure 클러스터에 배포하도록 준비하지 않은 한, 가장 중요한 권장 사항은 Azure 운영 팀(Microsoft 지원 채널을 통해)에게 미리 많은 용량에 대한 필요성을 전달하고 병목 현상으로 용량을 제거하기 위해 그에 따라 배포를 계획하는 것입니다. 또한 이 항목에 설명된 배포 전략 외에 배포 전략에 대한 추가 지침을 얻을 수 있는 기회이기도 합니다.

여러 클라우드 서비스에 배포 분산

다음과 같은 이유로 여러 클라우드 서비스를 사용하여 대규모 배포를 여러 소규모 배포로 분할하는 것이 좋습니다.

• 노드 그룹을 시작 및 중지하는 유연성을 허용합니다.

• 작업이 완료된 후 유휴 인스턴스를 중지할 수 있도록 합니다.

• 특히 초대형 인스턴스를 사용하는 경우 Azure 클러스터에서 사용 가능한 노드를 쉽게 찾을 수 있습니다.

• 재해 복구 또는 비즈니스 연속성 시나리오에 여러 Azure 데이터 센터를 사용하도록 설정합니다.

클라우드 서비스 크기에 대한 고정된 제한은 없지만 일반적인 지침은 500~700개의 가상 머신 인스턴스 또는 1,000개 미만의 코어입니다. 배포가 클수록 배포 시간 제한, 라이브 인스턴스 손실 및 가상 IP 주소 교환 문제가 발생할 수 있습니다.

전체 단일 HPC 클러스터에 대해 테스트된 최대 클라우드 서비스 수는 32개입니다.

위치에 유연하게 대처

다른 서비스 및 기타 지리적 요구 사항에 종속되는 것은 불가피할 수 있지만 Azure 배포가 특정 지역 또는 지역에 연결되지 않은 경우 도움이 될 수 있습니다. 그러나 해당 지역에 외부 종속성이 없거나 고가용성 및 재해 복구 요구 사항이 없는 한 여러 지리적 지역에 여러 배포를 배치하지 않는 것이 좋습니다.

가상 머신 크기에 유연하게 대처

특정 가상 머신 크기(예: 초대형)에 엄격한 종속성이 있으면 대규모 배포의 성공에 영향을 미칠 수 있습니다. 인스턴스 수와 코어의 균형을 맞추기 위해 가상 머신 크기를 조정하거나 혼합 및 일치시킬 수 있는 유연성이 있으면 도움이 될 수 있습니다.

노드 배포에 여러 Azure Storage 계정 사용

동시 대규모 Azure 노드 배포 및 사용자 지정 애플리케이션에 다른 Azure Storage 계정을 사용하는 것이 좋습니다. I/O로 제한되는 특정 애플리케이션의 경우 여러 스토리지 계정을 사용합니다. 또한 모범 사례로 Azure 노드 배포에 사용되는 스토리지 계정은 노드 프로비저닝 이외의 용도로 사용하면 안 됩니다. 예를 들어 Azure Storage를 사용하여 헤드 노드 간 또는 Azure 노드에서 작업 및 작업 데이터를 이동하려는 경우 해당 용도로 별도의 스토리지 계정을 구성합니다.

배포를 지원하도록 프록시 노드 인스턴스 수를 조정합니다.

프록시 노드는 온-프레미스 헤드 노드와 Azure 노드 간의 통신을 용이하게 하기 위해 HPC 클러스터에서 각 Azure 노드 배포에 자동으로 추가되는 Azure 작업자 역할 인스턴스입니다. 프록시 노드의 리소스에 대한 수요는 Azure에 배포된 노드 수와 해당 노드에서 실행되는 작업에 따라 달라집니다. 일반적으로 대규모 Azure 배포에서 프록시 노드 수를 늘려야 합니다.

HPC Pack 2012에는 각 Azure 노드 배포(클라우드 서비스)에서 프록시 노드 수를 구성할 수 있는 HPC 관리 도구가 도입되었습니다. (HPC Pack 2008 R2에서 숫자는 배포당 2개의 프록시 노드로 자동으로 설정됩니다.) 노드를 다시 배포하지 않고 Azure 관리 포털의 도구를 사용하여 프록시 노드에 대한 역할 인스턴스 수를 확장하거나 축소할 수도 있습니다. 단일 배포에 권장되는 최대 프록시 노드 수는 10개입니다.

더 크거나 많이 사용되는 배포에는 CPU 사용률이 50% 미만이고 대역폭이 할당량보다 작은 다음 표에 나열된 프록시 노드 수보다 더 많이 필요할 수 있습니다.

프록시 노드 구성 옵션에 대한 자세한 내용은 Azure 프록시 노드 수 설정을 참조하세요.

대규모 배포에 대한 헤드 노드를 구성하는 모범 사례

Azure 노드의 대규모 배포는 클러스터의 헤드 노드(또는 헤드 노드)에 상당한 요구를 할 수 있습니다. 헤드 노드는 배포를 지원하기 위해 여러 작업을 수행합니다.

• Azure 노드와의 통신을 용이하게 하기 위해 Azure 배포에서 만든 프록시 노드 인스턴스에 액세스합니다(이 항목에서는 배포를 지원하도록 프록시 노드 인스턴스 수 조정 참조).

• Blob(예: 런타임 패키지), 큐 및 테이블 데이터에 대한 Azure Storage 계정에 액세스합니다.

• 하트비트 간격 및 응답, 프록시 수(HPC 팩 2012부터), 배포 수 및 노드 수를 관리합니다.

Azure 배포의 크기와 처리량이 증가함에 따라 HPC 클러스터 헤드 노드에 대한 스트레스가 증가합니다. 일반적으로 헤드 노드에서 배포를 지원할 수 있도록 하는 데 필요한 주요 요소는 다음과 같습니다.

• 충분한 RAM

• 충분한 디스크 공간

• HPC 클러스터 데이터베이스에 적합한 크기, 잘 유지 관리되는 SQL Server 데이터베이스

헤드 노드에 대한 하드웨어 사양

다음은 대규모 Azure 배포를 지원하기 위한 헤드 노드에 대한 최소 사양입니다.

• CPU 코어 8개

• 2개의 디스크

• 16GB RAM

원격 SQL Server 데이터베이스 구성

대규모 배포의 경우 헤드 노드에 클러스터 데이터베이스를 설치하는 대신 Microsoft SQL Server를 실행하는 원격 서버에 클러스터 데이터베이스를 설치하는 것이 좋습니다. 클러스터용 SQL Server 버전을 선택하고 구성하는 일반적인 지침은 Microsoft HPC 팩에 대한 데이터베이스 용량 계획 및 튜닝을 참조하세요.

추가 클러스터 역할에 대한 헤드 노드 구성 안 함

대부분의 프로덕션 배포에 대한 일반적인 모범 사례로 헤드 노드는 추가 클러스터 역할(컴퓨팅 노드 역할 또는 WCF 브로커 노드 역할)으로 구성되지 않는 것이 좋습니다. 헤드 노드가 둘 이상의 용도로 제공되면 기본 관리 역할을 성공적으로 수행하지 못할 수 있습니다. 헤드 노드에서 수행하는 역할을 변경하려면 먼저 HPC 클러스터 관리자의 리소스 관리 (일부 버전의 HPC 팩에서 노드 관리 라고 함)의 작업을 사용하여 노드를 오프라인으로 전환합니다. 그런 다음 헤드 노드를 마우스 오른쪽 단추로 클릭하고 역할 변경을 클릭합니다.

또한 헤드 노드에서 클러스터 스토리지를 이동하면 헤드 노드의 공간이 부족하지 않고 효과적으로 작동합니다.

HPC 클라이언트 유틸리티를 사용하여 헤드 노드에 원격으로 연결

헤드 노드가 부하가 많은 상태에서 작동하는 경우 많은 사용자가 원격 데스크톱 연결에 연결하여 성능에 부정적인 영향을 미칠 수 있습니다. 사용자가 RDS(원격 데스크톱 서비스)를 사용하여 헤드 노드에 연결하도록 하는 대신 사용자와 관리자는 워크스테이션에 HPC 팩 클라이언트 유틸리티를 설치하고 이러한 원격 도구를 사용하여 클러스터에 액세스해야 합니다.

성능 카운터 수집 및 이벤트 전달 사용 안 함

대규모 배포의 경우 성능 카운터 수집 및 이벤트 전달은 HPC Management Service 및 SQL Server에 큰 부담을 줍니다. 이러한 배포의 경우 HPC 클러스터 관리 도구를 사용하여 이러한 기능을 사용하지 않도록 설정하는 것이 좋습니다. 예를 들어 Set-HpcClusterProperty HPC PowerShell cmdlet을 사용하여 CollectCounters 클러스터 속성을 false로 설정합니다. 향상된 성능과 발생하는 문제를 해결하는 데 도움이 될 수 있는 메트릭 수집 간에 장단점이 있을 수 있습니다.

불필요한 헤드 노드 서비스 사용 안 함

운영 체제에서 하드웨어 공간을 최소화하고 일반적인 HPC 클러스터 모범 사례로 사용하려면 HPC 클러스터 운영에 필요하지 않은 운영 체제 서비스를 사용하지 않도록 설정합니다. 특히 사용하도록 설정되었을 수 있는 데스크톱 기반 기능을 사용하지 않도록 설정하는 것이 좋습니다.

헤드 노드에서 NAT를 실행하지 마세요.

HPC 팩을 사용하면 헤드 노드에서 실행되는 RRAS(라우팅 및 원격 액세스 서비스)를 신속하게 구성하여 NAT(네트워크 주소 변환)를 제공하고 컴퓨팅 노드가 엔터프라이즈 네트워크에 연결할 수 있지만, 이로 인해 헤드 노드가 네트워크 대역폭에 상당한 병목 현상이 발생할 수 있으며 성능에도 영향을 줄 수 있습니다. 컴퓨팅 노드와 공용 네트워크 간에 트래픽이 많은 대규모 배포 또는 배포에 대한 일반적인 모범 사례로 다음 대안 중 하나를 사용하는 것이 좋습니다.

• 각 컴퓨팅 노드에 대한 직접 공용 네트워크 연결을 제공합니다.

• Windows Server 운영 체제를 실행하는 별도의 서버와 같은 전용 NAT 라우터를 제공하고 두 네트워크에서 이중 홈으로 RRAS를 실행합니다.

완료된 작업에 대해 적절한 스토리지 기간 보장

cluscfg 명령 및 Set-HpcClusterProperty HPC cmdlet의 TtlCompletedJobs 속성은 완료된 작업이 HPC 클러스터의 SQL Server 데이터베이스에 남아 있는 기간을 제어합니다. 이 속성에 대 한 큰 값을 설정 하면 작업 정보를 보고 목적에 대 한 바람직할 수 있는 오랜 시간 동안 시스템에서 유지 관리 됩니다. 그러나 데이터베이스(및 이에 대한 쿼리)가 일반적으로 더 커지므로 시스템에서 많은 수의 작업이 시스템의 스토리지 및 메모리 요구 사항을 증가합니다.

노드를 연결할 수 없게 표시하기 전에 적절한 수의 누락된 하트비트 구성

HPC 팩은 하트비트 신호를 사용하여 노드 가용성을 확인합니다. HPC 작업 스케줄러 서비스에서 이 정기적인 상태 프로브에 대한 컴퓨팅 노드의 응답이 부족하여 노드에 연결할 수 없는 것으로 표시될지 여부를 결정합니다. HPC 클러스터 관리자에서 작업 스케줄러 구성에서 하트비트 옵션을 구성하거나 cluscfg 명령 또는 Set-HpcClusterProperty HPC cmdlet을 사용하여 클러스터 관리자는 노드가 연결할 수 없는 것으로 표시되기 전에 하트비트(HeartbeatInterval)의 빈도 및 노드가 놓칠 수 있는 하트비트 수(InactivityCount)를 설정할 수 있습니다. 예를 들어 클러스터에 대규모 Azure 배포가 포함된 경우 기본 HeartbeatInterval 이 30초에서 2분으로 증가할 수 있습니다. 기본 InactivityCount 는 3으로 설정되어 일부 온-프레미스 배포에 적합하지만 Azure 노드를 배포할 때는 10 이상으로 늘려야 합니다.

헤드 노드 또는 WCF 브로커 노드가 장애 조치(failover) 클러스터의 고가용성을 위해 구성된 경우 장애 조치(failover) 클러스터 클러스터의 다른 컴퓨터(또는 컴퓨터)의 가용성을 모니터링하기 위해 각 장애 조치(failover) 클러스터 컴퓨터에서 사용하는 하트비트 신호도 고려해야 합니다. 기본적으로 컴퓨터가 초당 한 번씩 5개의 하트비트를 놓치면 해당 컴퓨터와의 통신이 실패한 것으로 간주됩니다. 장애 조치(failover) 클러스터 관리자를 사용하여 대규모 Azure 배포가 있는 클러스터에서 하트비트 빈도를 줄이거나 누락된 하트비트 수를 늘릴 수 있습니다.

Azure 노드에서 SOA(서비스 지향 아키텍처) 작업을 실행하는 경우 서비스 등록 파일에서 모니터링 시간 제한 설정을 조정하여 대규모 세션을 관리해야 할 수 있습니다. SOA 서비스 구성 파일에 대한 자세한 내용은 Windows HPC Server 2008 R2의 SOA 서비스 구성 파일을 참조하세요.

파일 준비 작업의 성능을 향상하도록 레지스트리 키 구성

HPC Pack 2008 R2 SP2부터 헤드 노드 컴퓨터에서 레지스트리 키를 설정하여 Azure 노드의 대규모 배포에서 진단 테스트, clusrun 작업 및 hpcfile 유틸리티의 성능을 향상시킬 수 있습니다. 이렇게 하려면 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\HPCFileStagingMaxConcurrentCalls라는 새 DWORD 값을 추가합니다. 배포하려는 Azure 노드 수의% 50~100개% 사이의 값을 구성하는 것이 좋습니다. 구성을 완료하려면 FileStagingMaxConcurrentCalls 값을 설정한 후 HPC 작업 스케줄러 서비스를 중지한 다음 다시 시작해야 합니다.

또한 참조하십시오

Microsoft HPC 팩을 사용하여 Azure 작업자 인스턴스로 버스트
Azure Cloud Services의 Large-Scale Services 디자인 모범 사례
Windows Azure 비즈니스 연속성 기술 지침