경량 Azure InfiniBand 클러스터 설정
클라우드의 HPC에 대한 주요 비판 중 하나는 온프레미스 클러스터와 비교할 때 노드 간 상호 연결 속도가 상대적으로 느리다는 것입니다. 많은 틈새 공급자가 이러한 격차를 해소하기 위해 InfiniBand 연결을 제공하는 반면, Microsoft는 새로운 기술을 통해 이러한 유형의 고대역폭, 저지연 상호 연결을 제공하는 최초의 주요 공급자입니다. 빅 컴퓨트 해결책. 대규모 데이터 센터를 관리하는 데 필요한 리소스를 보유하고 기업이 워크로드를 클라우드로 이전하는 데 필요한 보안 규정 준수 문제와 인증을 처리하는 회사가 상대적으로 적기 때문에 이는 흥미로운 소식입니다. 공정하든 아니든, Microsoft, Amazon 또는 Google의 지원을 받는 것은 기업 IT 동의를 얻는 데 큰 차이를 만들 수 있습니다.
에 따르면 명세서, 새로운 A8 및 A9 인스턴스 크기는 RDMA를 통한 InfiniBand 연결을 제공합니다. 이 마지막 부분은 특히 중요합니다. 이 블로그 게시물 InfiniBand만으로는 충분하지 않다는 점을 올바르게 지적했습니다. 사용되는 전송은 중요한 차이를 만들어내며 TCP 성능은 매우 저하됩니다. Big Compute 인스턴스는 Microsoft에 따라 거의 베어 메탈 성능을 제공하는 가상화된 RDMA를 지원합니다. 이번 발표는 클라우드에서 긴밀하게 결합된 시뮬레이션을 실행하려는 사용자에게 도움이 될 것입니다. 이러한 유형의 "수다스러운" MPI 애플리케이션은 기본 네트워크의 대기 시간에 매우 민감합니다. 그러나 플랫폼을 시험해 본 후에 현재 구현에는 몇 가지 진입 장벽이 있다고 생각합니다.
첫째, RDMA 기능은 현재 MS-MPI(Microsoft의 MPI 구현)에서만 지원되는 Network Direct라는 인터페이스를 통해 노출됩니다. 이러한 라이브러리에 대해 애플리케이션을 다시 컴파일해야 합니다. MPI는 잘 정의된 표준이고 MS-MPI는 널리 지원되는 MPICH를 기반으로 하기 때문에 이는 그리 큰 장애물이 아닙니다. 그러나 더 큰 문제는 Windows에서 실행하려면 애플리케이션을 작성해야 한다는 것입니다. 다행히도 오늘날 사용되는 인기 있는 엔지니어링 응용 프로그램 중 다수에는 이미 MS-MPI를 지원하는 Windows 버전이 있습니다. 적어도 일화적으로는 애플리케이션을 다음과 같이 다시 컴파일할 수 있는 것 같습니다. 적은 노력.
둘째, Windows 세계에서는 MPI 클러스터를 구성하는 것이 Linux와 매우 다릅니다. Windows는 확실히 인상적인 성능을 발휘할 수 있지만 MPI 벤치마크 숫자에 따르면, HPC 실무자의 대다수는 현재 Linux에서 실행되고 있습니다. Linux용 클라우드에서 MPI 클러스터를 구성하는 작업은 일반적으로 다음과 같이 요약됩니다. "인스턴스를 시작하고, 패키지 관리자를 사용하여 선택한 MPI 버전을 설치하고, 클러스터의 모든 노드에 비밀번호 없는 SSH를 설정하고, 머신 파일을 생성합니다." Windows에서 권장되는 접근 방식은 Windows Server 상자(온프레미스 또는 클라우드)에 HPC 팩을 설치하고 구성하는 것입니다. 이는 Linux에 익숙하고 Windows 서버 관리의 미묘한 차이를 잘 모르는 사람에게는 어려울 수 있습니다. HPC Pack 솔루션은 강력하고 모든 기능을 갖추고 있지만 몇 가지 벤치마크나 간단한 일회성 시뮬레이션만 실행하려는 경우 약간 무겁게 느껴집니다. 좋은 것은 다음과 같은 도구입니다. 스타클러스터 Active Directory를 구성하거나, SQL Server를 설치하거나, Powershell 및 REST API를 알아낼 필요 없이 사람들이 가능한 한 빨리 시작하고 실행할 수 있도록 합니다.
HPC Pack 없이 Azure에 MS-MPI를 설치할 수 있는 것으로 밝혀졌지만 이를 수행하는 방법에 대한 지침은 많지 않은 것 같습니다. 또한 Windows로 이식된 SSH 서버와 UNIX 유틸리티가 많이 있습니다. 우리는 별도의 HPC 팩 인스턴스를 설치, 구성 및 관리할 필요 없이 Windows에서 MPI 클러스터를 시작하는 더 쉬운 방법을 원했습니다. 우리가 실험한 결과는 PaaS 제품을 사용하여 각 노드에서 다음 작업을 수행하는 시작 작업 세트가 포함된 클라우드 서비스를 배포하는 것이었습니다.
- MS-MPI 설치(독립 실행형 설치 프로그램 사용 가능) 여기에서 지금 확인해 보세요.)
- SMPD 실행
- OpenSSH 서버 및 표준 UNIX 명령줄 유틸리티 세트 설치 및 구성
각 클라우드 서비스에는 단일 가상 IP(VIP)가 할당되어 있습니다. 이 문제를 해결하기 위해 우리는 인스턴스 내부 엔드포인트를 사용하여 사용자가 다른 포트를 사용하여 개별 노드에 SSH로 접속할 수 있도록 했습니다. 각 역할 인스턴스가 다른 역할 인스턴스에서 실행되는 SMPD 데몬에 연결할 수 있도록 내부 끝점이 열립니다. 이 모든 것의 최종 결과는 배포하기 쉬운 .cspkg 파일과 함께 제공되는 구성 xml입니다. 사용자는 SSH를 통해 역할 인스턴스에 접속하고 자신이 알고 익숙한 UNIX 명령을 사용할 수 있습니다.
우리는 2개의 A9 인스턴스에 대해 몇 가지 지연 시간 및 대역폭 벤치마크를 실행하고 싶었습니다. 먼저 MS-MPI에 대해 OSU Microbenchmark 라이브러리의 osu_latency 및 osu_bibw 벤치마크를 다시 컴파일했습니다. 그런 다음 위의 클라우드 서비스를 배포하고 벤치마크 실행 파일을 SCP가 있는 각 시스템에 복사했습니다(SCP는 이동해야 하는 대용량 파일이 있는 경우 실행 가능한 솔루션이 아니지만 이러한 벤치마크 실행 파일과 같은 작은 파일에는 잘 작동합니다). . 마지막으로 노드 중 하나에 SSH를 연결하고 실행 파일을 시작했습니다.
벤치마크 결과는 아래와 같습니다. 보시다시피, 0바이트 대기 시간 수치는 ~3us이고 더 큰 메시지 크기에 대한 양방향 대역폭 테스트에서 ~7.5GB/s가 전송되는 것을 볼 수 있습니다. 이는 완전 포화에 매우 가깝습니다.
# OSU MPI Latency Test
# Size Latency (us)
0 3.28
1 3.69
2 3.70
4 3.67
8 3.69
16 4.11
32 4.53
64 5.35
128 6.60
256 2.85
512 3.06
1024 3.44
2048 4.19
4096 5.96
8192 7.60
16384 10.64
32768 15.31
65536 23.32
131072 53.65
262144 85.02
524288 156.81
1048576 299.23
2097152 567.89
4194304 1098.55
# OSU MPI Bi-Directional Bandwidth Test
# Size Bi-Bandwidth (MB/s)
1 0.43
2 0.87
4 1.69
8 3.35
16 6.82
32 13.69
64 18.64
128 29.12
256 486.75
512 1174.69
1024 2170.21
2048 3844.66
4096 5982.22
8192 2873.87
16384 7078.87
32768 6669.85
65536 4926.26
131072 4878.30
262144 5853.30
524288 6674.26
1048576 7066.08
2097152 7344.74
4194304 7479.30
이는 매우 인상적인 성능 수치입니다. 그러나 빅 컴퓨팅 사용의 실제 전환점은 Microsoft가 IaaS 솔루션을 통해 Linux VM에 대한 지원을 추가하는 시점이 될 것으로 생각됩니다. 온라인에서 제공되는 문서에서는 현재 이에 대한 타임라인이 무엇인지 명확하지 않습니다(Windows Server에 대한 IaaS 지원이 최근에 추가되었습니다). 2014년에 새로운 저지연 상호 연결 전쟁이 어떻게 전개될지 지켜보는 것은 흥미로울 것입니다. 항상 그렇듯이 Rescale은 공급자에 대해 불가지론을 유지하고 고객에게 최고의 하드웨어를 제공할 계획입니다.
