HPC Pack 2008 R2 SP1(서비스 팩 1)부터 HPC 팩에는 클러스터 관리자가 Azure "버스트" 시나리오에서 온-프레미스 클러스터에 조인된 Azure 노드에 애플리케이션(예: 실행 파일, SOA 서비스, XLL 파일 및 클러스터 사용 Microsoft Excel 통합 문서)을 배포하는 데 도움이 되는 기본 제공 유틸리티 및 메커니즘이 포함되어 있습니다. 기본적으로 Azure 노드는 온-프레미스 리소스 및 공유 폴더에 직접 액세스할 수 없으므로 Azure 노드에 애플리케이션을 배포하는 데 사용하는 방법은 온-프레미스에서 애플리케이션을 배포하는 데 사용하는 방법과 다릅니다. 또한 Windows HPC 클러스터에 추가된 Azure 노드는 동적으로 배포되고 다시 프로비전되므로 애플리케이션 배포에 권장되는 방법은 새 Azure 노드 인스턴스에서 애플리케이션을 자동으로 사용할 수 있도록 하는 데 도움이 됩니다.
Azure 버스트에 대한 HPC 애플리케이션 워크로드에 대한 고려 사항
Azure 노드에 애플리케이션을 배포하기 전에 기존 또는 계획된 HPC 워크로드가 Azure에서 효율적으로 실행되거나 확장되는지 평가합니다. Azure 버스트 시나리오에서 실행되는 HPC 애플리케이션에 대한 자세한 마이그레이션, 개발 및 디자인 고려 사항은 이 항목의 범위를 벗어냅니다. 또한 Azure 플랫폼의 기능은 지속적으로 진화하고 있습니다. 그러나 HPC 팩을 사용하여 Azure 워크로드에 성공적으로 버스트하는 현재 특성은 다음과 같습니다. 특히 Azure 노드의 대규모 배포의 경우 다음과 같습니다.
고도로 분산된 단일 노드 계산 여기에는 많은 매개 변수 스윕 및 특정 SOA(서비스 지향 아키텍처) 작업이 포함됩니다. MPI(메시지 전달 인터페이스) 작업을 비롯한 다른 작업 유형은 Azure 버스트 구성에서 실행할 수 있지만 Azure RDMA 네트워크를 지원하는 계산 집약적 인스턴스 크기를 선택해야 할 수 있습니다. HPC 작업 유형에 대한 일반적인 내용은 병렬 컴퓨팅 작업 이해를 참조하세요.
계산 시간이 데이터 이동 시간을 초과합니다. 특정 HPC 워크로드에서는 계산을 위해 Azure에 대량의 데이터를 업로드하거나 처리된 대량의 데이터를 반환해야 합니다. HPC 워크플로에서 데이터 이동이 병목 상태가 아닌지 확인합니다.
파일 기반 데이터 액세스 온-프레미스 데이터 파일에 액세스하는 기존 HPC 애플리케이션은 Azure Blob Storage에 업로드된 데이터 파일에 액세스하여 Azure에서 실행되도록 쉽게 마이그레이션할 수 있습니다. Azure의 다양한 스토리지 유형에 액세스하기 위해 새로운 HPC 애플리케이션을 개발할 수 있습니다. 그러나 데이터의 민감도, 법적 요구 사항, 비용 고려 사항 및 기타 요인에 따라 애플리케이션 데이터를 Azure에 저장하지 못할 수 있습니다.
"버스티" 워크로드 패턴 Azure 버스트 시나리오는 온-프레미스 클러스터의 고정 리소스를 사용하여 쉽게 완료되지 않는 리소스 집약적 워크로드에 적합합니다. 워크로드에는 불규칙한 계산 급증, 정기적으로 예약된 작업 또는 일회성 작업이 포함될 수 있습니다.
Azure 노드에서 애플리케이션을 실행하는 방법에 대한 자세한 내용은 Azure Nodes에서 HPC 애플리케이션을 실행하기 위한 지침을 참조하세요.
Azure 노드에 애플리케이션 및 데이터를 배포하는 방법 선택
애플리케이션 및 데이터를 Azure 노드에 배포하는 데 사용하는 방법은 다음 표에 설명된 대로 애플리케이션을 설치하는 데 필요한 항목에 따라 달라집니다.
| 설치 요구 사항 | 메서드 | 가용도 |
|---|---|---|
| 파일 및 DLL 또는 구성 파일과 같은 종속성을 노드에 복사하여 설치를 수행할 수 있습니다. | - 관리자 패키지 및 hpcpack 명령을 사용하여 Azure Storage에 파일을 단계별로 실행합니다. hpcpack 및 hpcsync 사용을 참조하세요. - 관리자가 Azure 노드를 배포합니다. 패키지는 새 Azure 노드 인스턴스에 자동으로 배포(복사 및 추출)되거나 노드가 이미 실행 중인 경우 관리자가 수동으로 배포할 수 있습니다. Microsoft HPC 팩을 사용하여 Azure 작업자 인스턴스로 버스트를 참조하세요. |
HPC Pack 2008 R2 with SP1 |
| 설치하려면 설치 관리자를 자동으로 실행해야 하거나 환경 변수 설정 또는 방화벽 예외 만들기와 같은 추가 구성 단계가 필요합니다. | - 관리자가 hpcpack 명령을 사용하여 파일 또는 설치 관리자를 Azure Storage에 패키지하고 단계별로 지정합니다. hpcpack 및 hpcsync 사용을 참조하세요. - 관리자는 Azure 노드 템플릿에서 환경을 구성하거나 설치 명령을 실행하는 시작 스크립트를 지정합니다. Azure Nodes에 대한 시작 스크립트 사용을 참조하세요. - 관리자가 Azure 노드를 배포합니다. 패키지는 새 Azure 노드 인스턴스에 자동으로 배포된 다음, 시작 스크립트는 프로비전 프로세스의 일부로 실행됩니다. Microsoft HPC 팩을 사용하여 Azure 작업자 인스턴스로 버스트를 참조하세요. |
HPC Pack 2008 R2 with SP2 |
| Azure 노드에 대한 설치 및 데이터 배포는 작업이 실행될 때 준비 작업 중에 발생할 수 있습니다. | - 관리자는 AzCopy 와 같은 Azure Storage 도구를 사용하여 Azure Blob Storage의 컨테이너에 설치 관리자 및 데이터 파일을 업로드합니다. - 관리자 패키지 및 hpcpack 명령을 사용하여 추가 파일 또는 설치 관리자를 Azure Storage에 단계별로 지정합니다. hpcpack 및 hpcsync 사용을 참조하세요. - 관리자는 Azure 노드 템플릿에서 환경을 구성하거나 설치 명령을 실행하는 시작 스크립트를 지정합니다. Azure Nodes에 대한 시작 스크립트 사용을 참조하세요. - 관리자가 Azure 노드를 배포합니다. 패키지는 새 Azure 노드 인스턴스에 자동으로 배포된 다음, 시작 스크립트는 프로비전 프로세스의 일부로 실행됩니다. Microsoft HPC 팩을 사용하여 Azure 작업자 인스턴스로 버스트를 참조하세요. - 관리자는 추가 설치 단계를 수행하거나 Azure Blob Storage 컨테이너에서 데이터를 다운로드하기 위해 노드 준비 태스크를 사용하여 작업을 만듭니다. 노드 준비 태스크 정의 - 작업 관리자를 참조하세요. |
HPC Pack 2008 R2 with SP1 |
| 설치하려면 쉽게 스크립트되지 않는 단계가 필요하며 Azure의 지속형 드라이브에서 애플리케이션 및 애플리케이션 데이터에 액세스할 수 있습니다. - |
- 관리자는 Windows 도구를 사용하여 VHD(가상 하드 디스크)를 만들고 VHD에 애플리케이션 및 필요한 애플리케이션 데이터를 설치합니다. - 관리자는 VHD를 분리하고 hpcpack 업로드 명령을 사용하여 Azure Storage에 페이지 Blob으로 VHD를 업로드합니다. hpcpack 및 hpcsync 사용을 참조하세요. - 관리자는 Azure 노드 템플릿을 구성할 때 Azure Storage에 있는 애플리케이션 VHD를 지정합니다. Azure 작업자 노드에서 애플리케이션 VHD 탑재를 참조하세요. - 필요에 따라 관리자는 추가 구성에 대한 시작 스크립트를 지정하거나 배포의 하나 이상의 노드에 공유 폴더를 설정합니다. Azure Nodes에 대한 시작 스크립트 사용을 참조하세요. - 관리자가 Azure 노드를 배포합니다. 애플리케이션 VHD를 탑재하는 Azure 노드 인스턴스가 생성되고, 스토리지의 모든 패키지가 노드에 자동으로 배포된 다음, 시작 스크립트가 프로비전 프로세스의 일부로 실행됩니다. Microsoft HPC 팩을 사용하여 Azure 작업자 인스턴스로 버스트를 참조하세요. |
HPC Pack 2012 |
hpcpack 및 hpcsync 사용
각 Azure 노드 배포는 노드 템플릿에 지정된 Azure Storage 계정과 연결됩니다. 클러스터 관리자는 hpcpack 명령을 사용하여 스토리지 계정에 파일(예: 애플리케이션, SOA 서비스, XLL, 클러스터 사용 Excel 통합 문서 및 유틸리티)을 준비할 수 있습니다. hpcpack create를 사용하여 Azure Storage에 업로드할 수 있는 압축된 형식(.zip)으로 파일 또는 폴더를 패키지할 수 있습니다. 각 애플리케이션, SOA 서비스 또는 XLL은 별도로 패키지해야 하며 패키지에는 DLL 또는 구성 파일과 같은 필수 종속성이 포함되어야 합니다. 그런 다음 hpcpack 업로드 를 사용하여 스토리지 계정에 패키지를 업로드할 수 있습니다. 헤드 노드 또는 HPC 클라이언트 유틸리티가 설치된 컴퓨터에서 hpcpack 명령을 실행할 수 있습니다.
스토리지 계정의 모든 패키지는 프로비전 프로세스 중에 새 Azure 노드 인스턴스에 자동으로 배포됩니다. 이는 HPC 관리 유틸리티를 사용하여 Azure 노드 집합을 배포하고 Windows Azure 시스템에서 노드 인스턴스를 자동으로 다시 프로비전하는 경우에 발생합니다. hpcsync 명령은 각 Azure 노드에서 실행되고 스토리지에서 노드로 모든 패키지를 복사한 다음 파일을 추출합니다. Azure 노드가 시작된 후 스토리지에 패키지를 업로드하는 경우 각 Azure 노드에서 hpcsync 명령을 수동으로 실행하여 패키지를 배포할 수 있습니다.
비고
동일한 스토리지 계정을 참조하는 여러 Azure 노드 템플릿을 만드는 경우 동일한 스테이징된 파일이 모든 Azure 노드 집합에 배포됩니다. 다른 노드 집합에 다른 파일을 배포하려면 각 Azure 노드 템플릿에 대해 별도의 Azure Storage 계정을 만듭니다.
다음 다이어그램에서는 Azure 노드에 애플리케이션을 복사하기 위한 기본 워크플로 및 메커니즘을 보여 줍니다.
기본적으로 hpcsync 는 CCP_PACKAGE_ROOT 환경 변수로 지정된 위치에 파일을 추출합니다. 이 변수는 프로비전 프로세스 중에 Azure 노드에서 설정됩니다. 추출된 파일은 다음과 같이 결정되는 폴더에 배치됩니다. %CCP_PACKAGE_ROOT%\<packageName>\<uploadTimeStamp>입니다. SOA 서비스, XLL 및 Excel 통합 문서의 예상 위치입니다. 그러나 클러스터 사용자가 명령줄에서 호출하는 애플리케이션에는 편리하지 않습니다. 실행 파일의 폴더 구조를 간소화하기 위해 스토리지에 업로드할 때 패키지의 상대 경로 속성을 설정할 수 있습니다.
hpcsync 는 파일을 추출할 때 상대 경로를 적용하므로 경로가 다음과 같이 결정됩니다. %CCP_PACKAGE_ROOT%\<relativePath>입니다. 그러면 사용자는 작업 제출 명령의 다음 예제와 같이 애플리케이션의 경로를 지정할 수 있습니다. job submit %CCP_PACKAGE_ROOT%\myRelativePath\myapp.exe
다음은 hpcsync 및 CCP_PACKAGE_ROOT 대한 중요한 고려 사항입니다.
Azure 작업자 노드에서 %CCP_PACKAGE_ROOT% 폴더는 10GB 디스크 파티션에 만들어집니다. 즉, 노드 인스턴스의 모든 애플리케이션 파일은 10GB를 초과할 수 없습니다. 애플리케이션에 상당한 입력 및 출력 파일이 있는 경우 시작 스크립트를 사용하여 사용자가 노드에서 사용 가능한 모든 스크래치 공간에 쓸 수 있도록 C:\ 드라이브에 대한 사용자 권한을 부여할 수 있습니다.
hpcsync를 수동으로 실행하는 경우 기본 위치(%CCP_PACKAGE_ROOT%)를 재정의할 수 있습니다. 예를 들어 각 Azure Node에 폴더를 만든 다음 , hpcsync를 실행할 때 해당 위치를 지정할 수 있습니다. 모든 패키지가 해당 폴더에 추출됩니다. 그러나 배포되거나 자동으로 다시 프로비전되는 새 노드 인스턴스에는 해당 폴더가 포함되지 않으며 패키지가 기본 위치에 자동으로 배포됩니다. 또한 클러스터 사용자는 %CCP_PACKAGE_ROOT%폴더에 대한 쓰기 권한만 있습니다. Azure 노드에서 폴더 권한을 수정하지 않는 한 관리자만 %CCP_PACKAGE_ROOT%외부에서 애플리케이션을 실행할 수 있습니다.
hpcsync가 패키지를 배포할 때 추출된 파일 중 어느 것도 전체 경로 길이가 256자보다 길지 않을 수 있습니다. 추출된 파일이 임시로 배치된 후 마지막으로 배치되는 루트 디렉터리에는 최대 136자가 소요될 수 있으며, 파일 이름, 하위 디렉터리(있는 경우) 및 relativePath(지정된 경우)에 대해 120자를 남겨 둘 수 있습니다. 추출된 파일의 경로가 256자를 초과하면 패키지 배포가 실패합니다.
hpcsync 메커니즘은 단순히 파일을 노드에 복사하여 설치할 수 있는 SOA 서비스, XLL 파일 및 애플리케이션을 배포하는 데 충분합니다. 설치 관리자를 실행하여 애플리케이션을 설치해야 하거나 애플리케이션에 환경 변수 설정, 방화벽 예외 추가, 폴더 권한 수정 또는 폴더 만들기와 같은 추가 구성 단계가 필요한 경우 노드 템플릿에 시작 스크립트를 포함할 수 있습니다. 이 스크립트는 hpcsync 를 실행한 후 프로비전 프로세스 중에 실행되며 노드를 구성하고 필요한 애플리케이션 설치 단계를 수행하는 데 사용할 수 있습니다.
Azure Storage에 애플리케이션 파일을 스테이징하는 방법
이 섹션에서는 hpcpack을 사용하여 애플리케이션을 패키징하고 Azure Storage에 스테이징하는 방법에 대한 정보를 제공합니다. 스테이징된 패키지는 프로비전하는 새 Azure 노드 인스턴스(또는 Azure 시스템에서 자동으로 다시 프로비전됨)에 자동으로 배포됩니다.
비고
Azure Storage에 파일을 스테이징하려면 클러스터 관리자이거나 Azure 구독 ID 및 스토리지 계정 키가 있어야 합니다.
요구 사항
SOA 서비스를 패키징하는 경우:
패키지의 이름은 SOA 서비스의 이름(즉, SOA 클라이언트가 SessionStartInfo 생성자에서 지정하는 서비스 이름)이어야 합니다. 예를 들어 serviceName.zip 또는 serviceName_serviceVersion.zip.
패키지에 서비스 DLL, 종속 DLL 및 서비스 구성 파일을 포함해야 합니다.
서비스 구성 파일도 헤드 노드에 배포해야 합니다. 모든 설정은 구성 파일의 온-프레미스 복사본에 의해 결정됩니다.
패키지를 업로드할 때 상대 경로를 지정하지 마세요. SOA 서비스는 기본 위치로 압축을 풉니다.
XLL 파일을 패키징하는 경우:
패키지의 이름은 XLL 파일의 이름이어야 합니다. 예를 들어 XLLName.zip.
XLL에 종속성이 있는 경우 XLL 및 지원 파일을 폴더에 배치하고 폴더를 패키징합니다. XLL은 하위 폴더가 아닌 폴더의 최상위 수준에 있어야 합니다.
패키지를 업로드할 때 상대 경로를 지정하지 마세요. XLL을 기본 위치로 압축 해제해야 합니다.
Excel 통합 문서를 패키징하는 경우:
패키지의 이름은 통합 문서의 이름이어야 합니다. 예를 들어 workbookName.zip.
통합 문서에 종속성이 있는 경우 통합 문서 및 지원 파일을 폴더에 배치하고 폴더를 패키징합니다. 통합 문서는 하위 폴더가 아닌 폴더의 최상위 수준에 있어야 합니다.
패키지를 업로드할 때 상대 경로를 지정하지 마세요. 통합 문서는 기본 위치로 압축을 풉니다.
실행 파일(예: MPI 애플리케이션), 애플리케이션 설치 관리자 또는 시작 스크립트에서 호출할 유틸리티를 패키징하는 경우:
패키지에 종속된 DLL 또는 파일을 포함해야 합니다.
패키지를 업로드할 때 상대 경로 속성을 지정합니다.
시작 스크립트를 패키징하는 경우:
패키지의 이름은 시작 스크립트의 이름이어야 합니다. 예를 들어 startup.bat.zip.
패키지를 업로드할 때 상대 경로를 지정하지 마세요. 시작 스크립트를 기본 위치로 압축 해제해야 합니다.
시작 스크립트가 설치 관리자 또는 유틸리티를 호출하는 경우 필요한 파일을 별도로 패키지하고 스테이징해야 합니다.
단계
예를 들어 다음 절차에서는 다양한 유형의 애플리케이션 파일을 Azure Storage에 스테이징하는 방법을 보여 줍니다.
비고
hpcpack 만들기를 실행하기 위해 관리자 권한 명령 프롬프트(관리자 권한으로 실행)가 필요하지 않습니다. 그러나 hpcpack 업로드 에는 상승이 필요합니다. 다음 절차를 수행하려면 관리자 권한 명령 프롬프트 창에서 명령을 실행합니다.
AZURE Storage에 SOA 서비스를 패키지하고 스테이징하려면
SOA 서비스가 아직 등록되어 온-프레미스 클러스터에 배포되지 않은 경우 서비스 구성 파일의 복사본을 헤드 노드의 서비스 등록 폴더에 배치하여 SOA 서비스를 등록합니다(일반적으로 \ServiceRegistration %CCP_HOME%). 자세한 내용은 서비스 구성 파일 배포 및 편집을 참조하세요.
서비스 구성 파일, 서비스 어셈블리 및 종속 DLL을 빈 폴더에 복사합니다. 예를 들어 C :\myFiles\myServiceFiles 폴더에 파일을 복사합니다.
관리자 권한 명령 프롬프트에서 hpcpack 만들기 를 실행하고 패키지 이름과 서비스 파일이 포함된 폴더를 지정합니다.
중요합니다
패키지 이름은 SOA 서비스의 이름(즉, SOA 클라이언트가 생성자에 지정하는
SessionStartInfo서비스 이름)이어야 합니다.예를 들어 C:\myFiles\myServiceFiles 의 콘텐츠를 myServiceName.zip 패키지하고 AzurePackages라는 폴더에 패키지를 저장합니다.
hpcpack create C:AzurePackagesmyServiceName.zip C:myFilesmyServiceFileshpcpack 업로드를 실행하여 다음 명령을 사용하여 Azure Storage에 패키지를 업로드합니다. 여기서 myHeadNode는 헤드 노드의 이름이고 myAzureTemplate은 Azure 노드를 배포하는 데 사용한 템플릿의 이름입니다. 다음은 그 예입니다.
hpcpack upload C:\AzurePackages\myServiceName.zip /nodetemplate:myAzureNodeTemplate /scheduler:myHeadNode
XLL 파일 또는 Excel 통합 문서를 Azure Storage로 패키지하고 스테이징하려면
XLL 또는 통합 문서에 DLL 또는 다른 파일에 대한 종속성이 있는 경우 XLL 또는 통합 문서와 해당 종속성을 c:\myFiles\myExcelFiles와 같은 폴더에 복사합니다.
관리자 권한 명령 프롬프트에서 hpcpack create 를 실행하여 XLL 또는 통합 문서를 패키지합니다. 패키지의 이름을 지정하고 XLL 또는 통합 문서를 지정합니다. 패키지의 이름은 XLL 파일 또는 Excel 통합 문서의 이름이어야 합니다.
예를 들어 XLL 또는 통합 문서에 종속성이 있는 경우 전체 폴더를 패키지하고 AzurePackages라는 폴더에 패키지를 저장합니다.
hpcpack create C:\AzurePackages\myXLL.zip C:\myFiles\myExcelFilesXLL 또는 통합 문서에 종속성이 없는 경우 직접 패키지할 수 있습니다. 예를 들어 C:\myFiles\myXLL.xll 을 myXLL.zip패키지하려면:
hpcpack create C:\AzurePackages\myXLL.zip C:\myFiles\myXLL.xllhpcpack 업로드를 실행하여 다음 명령을 사용하여 Azure Storage에 패키지를 업로드합니다. 여기서 myHeadNode는 헤드 노드의 이름이고 myAzureTemplate은 Azure 노드를 배포하는 데 사용한 템플릿의 이름입니다. 다음은 그 예입니다.
hpcpack upload C:\AzurePackages\myXLL.zip /nodetemplate:myAzureNodeTemplate /scheduler:myHeadNode
실행 파일을 Azure Storage에 패키지하고 스테이징하려면
실행 파일과 모든 종속성 또는 DLL을 C:\myFiles\myAppFiles와 같은 폴더에 복사합니다.
관리자 권한 명령 프롬프트에서 hpcpack create 를 실행하여 애플리케이션 파일을 패키지합니다. 패키지의 이름을 지정하고 애플리케이션 파일이 포함된 폴더를 지정합니다.
예를 들어 c:\myFiles\myAppFiles 의 콘텐츠를 myApp.zip 패키지하고 AzurePackages라는 폴더에 패키지를 저장합니다.
hpcpack create c:\AzurePackages\myApp.zip c:\myFiles\myAppFiles다음 명령을 사용하여 Azure Storage에 패키지를 업로드합니다. 여기서 myHeadNode 는 헤드 노드의 이름이고 myAzureTemplate 은 Azure 노드를 배포하는 데 사용한 템플릿의 이름입니다. 애플리케이션 파일의 상대 경로를 지정합니다. 다음은 그 예입니다.
hpcpack upload c:\AzurePackages\myApp.zip /scheduler:myHeadNode /nodetemplate:myAzureTemplate /relativepath:myApp
Azure 노드에 스테이징된 패키지를 배포하는 방법
Azure Storage에 준비되는 패키지는 새 노드 인스턴스에 자동으로 배포됩니다. 패키지를 수동으로 배포할 수 있습니다. 예를 들어 모든 새 노드에 배포를 자동화하기 전에 패키지에 필요한 모든 종속성이 있는지 확인하거나 이미 실행 중인 노드에 패키지를 배포할 수 있습니다. clusrun 및 hpcsync를 사용하여 Azure Storage 계정에서 Azure 노드로 파일을 배포할 수 있습니다.
다음은 그 예입니다.
clusrun /nodegroup:AzureWorkerNodes hpcsync
Azure 노드에 배포된 폴더 또는 파일 목록을 보려면 다음 명령을 실행할 수 있습니다.
clusrun /nodegroup:AzureWorkerNodes dir %CCP_PACKAGE_ROOT% /s
Azure 노드에서 파일 액세스
HPC 애플리케이션에 파일 액세스가 필요한 경우 Azure 노드에 배포된 애플리케이션에서 파일에 액세스하기 위한 옵션은 다음과 같습니다.
| 옵션 | 필수 조건 | 비고 |
|---|---|---|
| Azure 드라이브 | 관리자는 Azure 노드에서 애플리케이션 VHD를 구성하고 탑재합니다. Azure 작업자 노드에서 애플리케이션 VHD 탑재를 참조하세요. |
- 드라이브가 복사되고 각 노드에서 로컬로 캐시됩니다. - 드라이브는 한 번에 하나의 노드로만 작성할 수 있습니다. |
| Azure Virtual Machine의 파일 서버 | 관리자는 Azure 가상 머신 인스턴스를 구성하고, 데이터 디스크를 가상 머신에 연결하고, 파일 서버 역할을 사용하도록 설정하고, 파일 공유 폴더를 만듭니다. Azure Virtual Machine 파일 서버를 구성하고 Windows HPC Server 컴퓨팅 작업 내에서 사용하는 방법을 참조하세요. |
- 파일 서버 리소스에 대한 작업별 액세스에는 인증된 사용자 액세스가 필요합니다. - 기존 애플리케이션에 대한 SMB 호환성 제공 - 서버당 최대 16TB의 데이터를 제공합니다. - 대역폭을 800Mb/s로 제한합니다. |
| Azure Blob Storage에 로컬 파일 미러링 | 관리자는 AzCopy 와 같은 Azure Storage 도구를 사용하여 온-프레미스 파일을 Azure Blob Storage의 컨테이너로 미러링합니다. |
- 온-프레미스 환경에서 Azure로 데이터를 미러링하면 오버헤드가 추가됩니다. |
| Azure Blob Storage에 직접 액세스 | 애플리케이션은 Azure Blob에서 직접 데이터 액세스 작업을 수행하도록 설계되었습니다. | - 사용 가능한 옵션의 가장 높은 확장성을 제공합니다. |