Azure Managed Lustre 파일 시스템 필수 구성 요소
이 문서에서는 Azure Managed Lustre 파일 시스템을 만들기 전에 구성해야 하는 필수 구성 요소를 설명합니다.
- 네트워크 필수 구성 요소
- Blob 통합 필수 구성 요소(선택 사항)
네트워크 필수 구성 요소
Azure Managed Lustre 파일 시스템은 가상 네트워크 서브넷에 있습니다. 서브넷은 MGS(Lustre Management Service)를 포함하며 가상 Lustre 클러스터와의 모든 클라이언트 상호 작용을 처리합니다.
파일 시스템을 만든 후에는 한 네트워크 또는 서브넷에서 다른 네트워크로 파일 시스템을 이동할 수 없습니다.
Azure Managed Lustre는 IPv4 주소만 허용합니다. IPv6는 지원되지 않습니다.
네트워크 크기 요구 사항
필요한 서브넷의 크기는 만든 파일 시스템의 크기에 따라 달라집니다. 다음 표에서는 다양한 크기의 Azure Managed Lustre 파일 시스템에 대한 최소 서브넷 크기를 대략적인 예측값으로 제공합니다.
| 스토리지 용량 | 권장 CIDR 접두사 값 |
|---|---|
| 4TiB ~16TiB | /27 이상 |
| 20TiB ~40TiB | /26 이상 |
| 44TiB ~92TiB | /25 이상 |
| 96TiB ~196TiB | /24 이상 |
| 200TiB~400TiB | /23 이상 |
기타 네트워크 크기 고려 사항
가상 네트워크 및 서브넷을 계획할 때 Azure Managed Lustre 서브넷 또는 가상 네트워크 내에서 찾으려는 다른 서비스에 대한 요구 사항을 고려합니다.
Azure Managed Lustre 파일 시스템과 함께 AKS(Azure Kubernetes Service) 클러스터를 사용하는 경우 파일 시스템과 동일한 서브넷에서 AKS 클러스터를 찾을 수 있습니다. 이 경우 Lustre 파일 시스템의 주소 공간 외에도 AKS 노드 및 Pod에 충분한 IP 주소를 제공해야 합니다. 가상 네트워크 내에서 둘 이상의 AKS 클러스터를 사용하는 경우 가상 네트워크에 모든 클러스터의 모든 리소스에 충분한 용량이 있는지 확인합니다. Azure Managed Lustre 및 AKS에 대한 네트워크 전략에 대한 자세한 내용은 AKS 서브넷 액세스를 참조 하세요.
다른 리소스를 사용하여 동일한 가상 네트워크에서 컴퓨팅 VM을 호스트하려는 경우 Azure Managed Lustre 시스템에 대한 가상 네트워크 및 서브넷을 만들기 전에 해당 프로세스에 대한 요구 사항을 확인합니다. 동일한 서브넷 내에서 여러 클러스터를 계획할 때는 모든 클러스터에 대한 전체 요구 사항을 수용할 수 있을 만큼 큰 주소 공간을 사용해야 합니다.
서브넷 액세스 및 권한
기본적으로 Azure Managed Lustre를 사용하도록 설정하기 위해 특별히 변경할 필요가 없습니다. 사용자 환경에 제한된 네트워크 또는 보안 정책이 포함된 경우 다음 지침을 고려해야 합니다.
| 액세스 형식 | 필수 네트워크 설정 |
|---|---|
| DNS 액세스 | 기본 Azure 기반 DNS 서버를 사용합니다. |
| 호스트 간 액세스 | Azure Managed Lustre 서브넷 내의 호스트 간에 인바운드 및 아웃바운드 액세스를 허용합니다. 예를 들어 클러스터 배포에는 TCP 포트 22(SSH)에 대한 액세스가 필요합니다. |
| Azure 클라우드 서비스 액세스 | Azure Managed Lustre 파일 시스템이 파일 시스템 서브넷 내에서 Azure 클라우드 서비스에 액세스할 수 있도록 네트워크 보안 그룹을 구성합니다. 다음 속성을 사용하여 아웃바운드 보안 규칙을 추가합니다. - 포트: Any - 프로토콜: Any - 원본: Virtual Network - 대상: "AzureCloud" 서비스 태그 - 작업: 허용 참고: Azure 클라우드 서비스를 구성하면 Azure Queue 서비스의 필요한 구성도 가능합니다. 자세한 내용은 가상 네트워크 서비스 태그를 참조하세요. |
| Lustre 네트워크 포트 액세스 | 네트워크 보안 그룹은 포트 988 및 포트 1019-1023에서 인바운드 및 아웃바운드 액세스를 허용해야 합니다. 다른 서비스는 Lustre 클라이언트에서 이러한 포트를 예약하거나 사용할 수 없습니다. 기본 규칙 65000 AllowVnetInBound 이며 65000 AllowVnetOutBound 이 요구 사항을 충족합니다. |
Azure Managed Lustre 파일 시스템에 대한 네트워크 보안 그룹을 구성하는 방법에 대한 자세한 지침은 네트워크 보안 그룹 만들기 및 구성을 참조하세요.
알려진 제한 사항
Azure Managed Lustre 파일 시스템의 가상 네트워크 설정에는 다음과 같은 알려진 제한 사항이 적용됩니다.
- Azure Managed Lustre 및 Azure NetApp Files 리소스는 서브넷을 공유할 수 없습니다. Azure NetApp Files 서비스를 사용하는 경우 별도의 서브넷에 Azure Managed Lustre 파일 시스템을 만들어야 합니다. Azure NetApp Files 리소스가 현재 포함되었거나 이전에 포함된 서브넷에서 Azure Managed Lustre 파일 시스템을 만들려고 하면 배포가 실패합니다.
- 클라이언트에서
ypbind디먼을 사용하여 NIS(네트워크 정보 서비스) 바인딩 정보를 유지 관리하는 경우 포트 988을ypbind예약하지 않는지 확인해야 합니다. 예약된ypbind포트를 수동으로 조정하거나, 시작하기 전에 시스템 시작 인프라가 Lustre 클라이언트 탑재를 시작하는ypbind지 확인할 수 있습니다.
참고 항목
Azure Managed Lustre 파일 시스템을 만든 후 파일 시스템의 리소스 그룹에 몇 가지 새로운 네트워크 인터페이스가 표시됩니다. 그들의 이름은 amlfs로 시작하고 -snic로 끝납니다. 이러한 인터페이스의 설정을 변경하지 마세요. 특히 가속 네트워킹 설정에 대해 기본값을 사용하도록 설정된 상태로 둡니다. 이러한 네트워크 인터페이스에서 가속화된 네트워킹을 사용하지 않도록 설정하면 파일 시스템의 성능이 저하됩니다.
Blob 통합 필수 구성 요소(선택 사항)
Azure Managed Lustre 파일 시스템을 Azure Blob Storage와 통합하려는 경우 파일 시스템을 만들기 전에 다음 필수 조건을 완료합니다.
Blob 통합에 대한 자세한 내용은 Azure Managed Lustre 파일 시스템에서 Azure Blob Storage 사용을 참조 하세요.
Azure Managed Lustre는 계층 구조 네임스페이스가 활성화된 스토리지 계정 및 비 계층적 또는 플랫 네임스페이스가 있는 스토리지 계정에서 작동합니다. 다음과 같은 사소한 차이점이 적용됩니다.
- 계층 구조 네임스페이스를 사용하도록 설정된 스토리지 계정의 경우 Azure Managed Lustre는 Blob 헤더에서 POSIX 특성을 읽습니다.
- 계층 구조 네임스페이 스를 사용하도록 설정하지 않은 스토리지 계정의 경우 Azure Managed Lustre는 Blob 메타데이터에서 POSIX 특성을 읽습니다. 메타데이터를 보관하기 위해 Blob 컨테이너 콘텐츠와 이름이 같은 별도의 빈 파일이 만들어집니다. 이 파일은 Azure Managed Lustre 파일 시스템의 실제 데이터 디렉터리에 대한 형제입니다.
Azure Blob Storage를 Azure Managed Lustre 파일 시스템과 통합하려면 파일 시스템을 만들기 전에 다음 리소스를 만들거나 구성해야 합니다.
스토리지 계정
스토리지 계정을 만들거나 기존 계정을 사용해야 합니다. 스토리지 계정에는 다음 설정이 있어야 합니다.
- 계정 유형 - 호환되는 스토리지 계정 유형입니다. 자세한 내용은 지원되는 스토리지 계정 유형을 참조 하세요.
- 액세스 역할 - Azure Managed Lustre 시스템에서 데이터를 수정할 수 있도록 허용하는 역할 할당입니다. 자세한 내용은 필수 액세스 역할을 참조 하세요.
- 액세스 키 - 스토리지 계정에 스토리지 계정 키 액세스 설정이 Enabled로 설정되어 있어야 합니다.
지원되는 스토리지 계정 형식
Azure Managed Lustre 파일 시스템에서 사용할 수 있는 스토리지 계정 유형은 다음과 같습니다.
| Storage 계정 유형 | 중복 |
|---|---|
| Standard | LRS(로컬 중복 스토리지), GRS(지역 중복 스토리지) ZRS(영역 중복 스토리지), RAGRS(읽기 액세스 지역 중복 스토리지), GZRS(지역 영역 중복 스토리지), RA-GZRS(읽기 액세스 지역 영역 중복 스토리지) |
| 프리미엄 - 블록 Blob | LRS, ZRS |
스토리지 계정 유형에 대한 자세한 내용은 스토리지 계정 유형을 참조 하세요.
Blob 통합을 위한 액세스 역할
스토리지 계정에 액세스하려면 Azure Managed Lustre에 대한 권한 부여가 필요합니다. Azure RBAC(Azure 역할 기반 액세스 제어)를 사용하여 파일 시스템에 Blob Storage에 대한 액세스 권한을 부여합니다.
스토리지 계정 소유자는 파일 시스템을 만들기 전에 다음 역할을 추가해야 합니다.
Important
Azure Managed Lustre 파일 시스템을 만들기 전에 이러한 역할을 추가해야 합니다. 파일 시스템에서 Blob 컨테이너에 액세스할 수 없는 경우 파일 시스템 만들기가 실패합니다. 파일 시스템을 만들기 전에 수행된 유효성 검사는 컨테이너 액세스 권한 문제를 검색할 수 없습니다. 역할 설정이 Azure 환경을 통해 전파되는 데 최대 5분이 걸릴 수 있습니다.
서비스 주체 HPC Cache 리소스 공급자에 대한 역할을 추가하려면 다음 단계를 수행합니다.
- 스토리지 계정을 탐색하고 왼쪽 탐색 창에서 액세스 제어(IAM)를 선택합니다.
- 추가>역할 할당 추가를 선택하여 역할 할당 추가 페이지를 엽니다.
- 역할을 할당합니다.
- 해당 역할에 HPC Cache 리소스 공급자를 추가합니다.
팁
HPC 캐시 리소스 공급자를 찾을 수 없는 경우 대신 스토리지 캐시를 검색합니다. storagecache 리소스 공급자 는 제품의 일반 공급 이전의 서비스 주체 이름이었습니다.
- 3단계와 4단계를 반복하여 각 역할을 추가합니다.
세부 단계에 대해서는 Azure Portal을 사용하여 Azure 역할 할당을 참조하세요.
Blob 컨테이너
동일한 스토리지 계정에 다음 용도로 사용되는 두 개의 개별 Blob 컨테이너가 있어야 합니다.
- 데이터 컨테이너: Azure Managed Lustre 파일 시스템에서 사용하려는 파일이 포함된 스토리지 계정의 Blob 컨테이너입니다.
- 로깅 컨테이너: 스토리지 계정의 로그 가져오기/내보내기용 두 번째 컨테이너입니다. 데이터 컨테이너와 다른 컨테이너에 로그를 저장해야 합니다.
참고 항목
나중에 클라이언트에서 파일 시스템에 파일을 추가할 수 있습니다. 그러나 가져오기 작업을 만들지 않는 한 파일 시스템을 만든 후 원래 Blob 컨테이너에 추가된 파일은 Azure Managed Lustre 파일 시스템으로 가져오지 않습니다.
프라이빗 엔드포인트(선택 사항)
Blob 설정과 함께 프라이빗 엔드포인트를 사용하는 경우 Azure Managed Lustre가 SA 이름을 확인할 수 있도록 하려면 새 엔드포인트를 만드는 동안 프라이빗 엔드포인트 설정을 프라이빗 DNS 영역 과 통합하도록 설정해야 합니다.
- 프라이빗 DNS 영역과 통합: 예로 설정해야 합니다.
