Azure Managed Lustre와 함께 Azure Blob Storage 사용

아티클
11/11/2024

Azure Managed Lustre는 Azure Blob Storage와 통합하여 Blob 컨테이너에서 파일 시스템으로 데이터를 가져오는 프로세스를 간소화합니다. 장기 스토리지를 위해 파일 시스템에서 Blob 컨테이너로 데이터를 내보낼 수도 있습니다. 이 문서에서는 Azure Managed Lustre 파일 시스템과 Blob 통합을 사용하기 위한 개념을 설명합니다.

호환되는 Blob 컨테이너에 필요한 요구 사항 및 구성을 이해하려면 Blob 통합 필수 구성 요소를 참조 하세요.

Blob 통합 개요

클러스터를 만드는 동안 Blob 통합을 구성할 수 있으며 클러스터를 만든 후 언제든지 가져오기 작업을 만들 수 있습니다. 데이터를 가져오면 다른 파일 시스템 데이터와 마찬가지로 데이터로 작업할 수 있습니다. 새 파일이 만들어지거나 파일 시스템에서 기존 파일이 수정되면 클라이언트에서 Lustre CLI 명령을 실행하거나 내보내기 작업을 사용하여 데이터를 내보내 이러한 파일을 스토리지 계정으로 다시 내보낼 수 있습니다.

Blob 컨테이너에서 Azure Managed Lustre 파일 시스템으로 데이터를 가져오는 경우 파일 이름(네임스페이스) 및 메타데이터만 Lustre 네임스페이스로 가져옵니다. Blob의 실제 콘텐츠는 클라이언트에서 처음 액세스할 때 가져옵니다. Lustre HSM(Hierarchical Storage Management) 기능이 Blob 콘텐츠를 파일 시스템의 해당 파일로 끌어오는 동안 데이터에 처음 액세스할 때 약간의 지연이 발생합니다.

sudo 기능이 있는 탑재된 클라이언트에서 Lustre의 명령을 사용하여 Blob의 lfs hsm_restore 콘텐츠를 프리페치할 수 있습니다. 자세한 내용은 Blob Storage에서 데이터 복원을 참조 하세요.

Azure Managed Lustre는 계층 구조 네임스페이스가 활성화된 스토리지 계정 및 비 계층적 또는 플랫 네임스페이스가 있는 스토리지 계정에서 작동합니다. 다음과 같은 사소한 차이점이 적용됩니다.

계층 구조 네임스페이스를 사용하도록 설정된 스토리지 계정의 경우 Azure Managed Lustre는 Blob 헤더에서 POSIX 특성을 읽습니다.
계층 구조 네임스페이 스를 사용하도록 설정하지 않은 스토리지 계정의 경우 Azure Managed Lustre는 Blob 메타데이터에서 POSIX 특성을 읽습니다. 메타데이터를 보관하기 위해 Blob 컨테이너 콘텐츠와 이름이 같은 별도의 빈 파일이 만들어집니다. 이 파일은 Azure Managed Lustre 파일 시스템의 실제 데이터 디렉터리에 대한 형제입니다.

Blob Storage에서 가져오기

클러스터를 만드는 동안 Blob Storage와의 통합을 구성할 수 있으며 클러스터를 만든 후 언제든지 가져오기 작업을 만들 수 있습니다.

Blob 컨테이너 요구 사항

클러스터를 만드는 동안 Blob 통합을 구성할 때는 가져올 컨테이너와 로깅 컨테이너라는 두 개의 개별 Blob 컨테이너를 식별해야 합니다. 가져올 컨테이너에는 Azure Managed Lustre 파일 시스템으로 가져오려는 데이터가 포함됩니다. 로깅 컨테이너는 가져오기 작업에 대한 로그를 저장하는 데 사용됩니다. 이러한 두 컨테이너는 동일한 스토리지 계정에 있어야 합니다. Blob 컨테이너에 대한 요구 사항에 대한 자세한 내용은 Blob 통합 필수 구성 요소를 참조 하세요.

가져오기 접두사

Blob 컨테이너에서 데이터를 가져올 때 선택적으로 하나 이상의 접두사를 지정하여 Azure Managed Lustre 파일 시스템으로 가져온 데이터를 필터링할 수 있습니다. 접두사 중 하나와 일치하는 Blob 컨테이너의 파일 이름은 파일 시스템의 메타데이터 레코드에 추가됩니다. 클라이언트가 파일에 처음 액세스하면 해당 콘텐츠가 Blob 컨테이너에서 검색되고 파일 시스템에 저장됩니다.

Azure Portal에서 클러스터를 만드는 동안 고급 탭의 가져오기 접두사 필드를 사용하여 Blob 컨테이너에서 가져올 데이터를 지정합니다. 이러한 필드는 초기 가져오기 작업에만 적용됩니다. 클러스터를 만든 후에는 가져오기 접두사를 변경할 수 없습니다.

가져오기 작업의 경우 작업을 만들 때 가져오기 접두사를 지정할 수 있습니다. Azure Portal에서 가져오기 접두사 필드에 가져오기 접두사를 지정할 수 있습니다. REST API를 사용하여 가져오기 작업을 만들 때 가져오기 접두사를 지정할 수도 있습니다.

가져오기 접두사를 지정할 때는 다음 사항을 고려해야 합니다.

기본 가져오기 접두사는 .입니다 /. 이 기본 동작은 전체 Blob 컨테이너의 콘텐츠를 가져옵니다.
여러 접두사를 지정하는 경우 접두사는 겹치지 않아야 합니다. 예를 들어 지정 /data 하면 /data2접두사 겹치기 때문에 가져오기 작업이 실패합니다.
Blob 컨테이너가 계층 구조 네임스페이스를 사용하도록 설정된 스토리지 계정에 있는 경우 접두사를 파일 경로로 간주할 수 있습니다. 경로 아래의 항목은 Azure Managed Lustre 파일 시스템에 포함됩니다.
Blob 컨테이너가 비 계층적(또는 플랫) 네임스페이스가 있는 스토리지 계정에 있는 경우 가져오기 접두사를 Blob 이름의 시작 부분과 비교되는 검색 문자열로 간주할 수 있습니다. 컨테이너의 Blob 이름이 가져오기 접두사로 지정한 문자열로 시작하는 경우 파일 시스템에서 해당 파일에 액세스할 수 있습니다. Lustre는 계층적 파일 시스템이며 / Blob 이름의 문자는 Lustre에 저장될 때 디렉터리 구분 기호가 됩니다.

충돌 해결 모드

Blob 컨테이너에서 데이터를 가져올 때 Blob 컨테이너와 파일 시스템 간의 충돌을 처리하는 방법을 지정할 수 있습니다. 이 옵션은 기존 클러스터에 대해 실행되는 가져오기 작업에만 적용됩니다. 다음 표에서는 사용 가능한 충돌 해결 모드 및 해당 설명을 보여 줍니다.

모드	설명
`fail`	충돌이 감지되면 가져오기 작업이 즉시 실패하고 오류가 발생합니다.
`skip`	충돌이 감지되면 가져오기 작업이 파일을 건너뜁니다.
`overwrite-dirty`	가져오기 작업은 충돌하는 경로를 평가하여 삭제하고 다시 가져와야 하는지 확인합니다. 자세한 내용은 덮어쓰기-더티 모드를 참조하세요.
`overwrite-always`	가져오기 작업은 충돌하는 경로를 평가하고, 더티인 경우 항상 삭제/다시 가져오거나, 정리된 경우 해제합니다. 자세한 내용은 덮어쓰기-항상 모드를 참조하세요.

덮어쓰기-더티 모드

모드는 overwrite-dirty 충돌하는 경로를 평가하여 삭제하고 다시 만들어야 하는지 확인합니다. 높은 수준에서 모드는 overwrite-dirty HSM 상태를 확인합니다. HSM 상태가 Clean 및 Archived인 경우 데이터가 Lustre에서 알 수 있는 한 Blob 컨테이너와 동기화된 경우 필요한 경우 특성만 업데이트됩니다. 그렇지 않으면 파일이 삭제되고 Blob 컨테이너에서 다시 가져옵니다.

HSM 상태를 확인해도 Lustre의 파일이 Blob 컨테이너의 파일과 일치한다고 보장할 수 없습니다. Lustre의 파일이 Blob 컨테이너의 파일과 가능한 한 가깝게 일치하는지 확인해야 하는 경우 모드를 overwrite-always 사용합니다.

덮어쓰기-항상 모드

이 모드는 overwrite-always 충돌하는 경로를 평가하고, 더티인 경우 항상 삭제/다시 가져오거나, 깨끗한 경우 해제합니다. 이 모드는 파일 시스템이 항상 Blob 컨테이너와 동기화되도록 하려는 경우에 유용합니다. 또한 이전에 복원된 모든 파일이 첫 번째 액세스 시 해제 또는 삭제/다시 가져오기되기 때문에 가장 비용이 많이 드는 옵션이기도 합니다.

오류 허용 오차

Blob 컨테이너에서 데이터를 가져올 때 오류 허용 오차를 지정할 수 있습니다. 오류 허용 오차 수준은 가져오기 작업에서 가져오기 프로세스 중에 발생하는 일시적인 오류(예: 운영 체제 오류 또는 네트워크 중단)를 처리하는 방법을 결정합니다. 이 컨텍스트의 오류는 충돌 해결 모드에서 처리하는 파일 충돌을 참조하지 않는다는 점에 유의해야 합니다.

가져오기 작업에 사용할 수 있는 오류 허용 오차 옵션은 다음과 같습니다.

오류 허용 안 함(기본값): 가져오기 중에 오류가 발생하면 가져오기 작업이 즉시 실패합니다. 이 옵션은 기본 동작입니다.
오류 허용: 오류가 발생하고 오류가 기록되면 가져오기 작업이 계속됩니다. 가져오기 작업이 완료되면 로깅 컨테이너에서 오류를 볼 수 있습니다.

Blob 가져오기 작업에 대한 고려 사항

Blob 컨테이너에서 데이터를 가져올 때 고려해야 할 항목은 다음과 같습니다.

한 번에 하나의 가져오기 또는 내보내기 작업만 실행할 수 있습니다. 예를 들어 가져오기 작업이 진행 중인 경우 다른 가져오기 작업을 시작하려고 하면 오류가 반환됩니다.
가져오기 작업을 취소할 수 있습니다. 기존 클러스터에서 시작된 가져오기 작업 또는 클러스터를 만드는 동안 시작된 가져오기 작업을 취소할 수 있습니다.
클러스터 배포는 해당 가져오기 작업이 완료되기 전에 성공적으로 반환할 수 있습니다. 가져오기 작업은 백그라운드에서 계속 실행됩니다. 다음과 같은 방법으로 가져오기 작업의 진행률을 모니터링할 수 있습니다.
- Azure Portal: Azure Portal은 가져오기 작업의 상태를 표시합니다. 파일 시스템으로 이동하고 Blob 통합을 선택하여 가져오기 작업 상태를 확인합니다.
- 루트 디렉터리의 Lustre 파일: 가져오는 동안 Lustre 루트 디렉터리에 비슷한 /lustre/IMPORT_<state>.<timestamp_start> 이름의 파일이 만들어집니다. <state> 가져오기가 진행됨에 따라 자리 표시자가 변경됩니다. 가져오기 작업이 성공적으로 완료되면 파일이 삭제됩니다.
완료된 가져오기 작업에 대한 세부 정보를 보려면 로깅 컨테이너를 확인할 수 있습니다. 로깅 컨테이너에는 가져오기 중에 발생한 오류 또는 충돌을 포함하여 가져오기 작업에 대한 로그가 포함됩니다.
어떤 이유로든 가져오기 작업이 실패하는 경우 가져온 파일 수 또는 충돌 횟수와 같은 가져오기 작업에 대한 전체 통계가 없을 수 있습니다.

Blob Storage에서 데이터 복원

기본적으로 Blob의 콘텐츠는 클라이언트에서 해당 파일에 처음 액세스할 때 파일 시스템으로 가져옵니다. 특정 워크로드 및 시나리오의 경우 먼저 액세스하기 전에 Blob 컨테이너에서 데이터를 복원하는 것이 좋습니다. 가져오기 후 처음으로 Blob에 액세스할 때 초기 지연을 방지하기 위해 Blob의 콘텐츠를 프리페치하도록 선택할 수 있습니다. Blob의 콘텐츠를 프리페치하려면 탑재된 클라이언트의 Lustre lfs hsm_restore 명령을 sudo 기능과 함께 사용할 수 있습니다. 다음 명령은 Blob의 내용을 파일 시스템에 프리페치합니다.

nohup find local/directory -type f -print0 | xargs -0 -n 1 sudo lfs hsm_restore &

이 명령은 메타데이터 서버에 복원 요청을 비동기적으로 처리하도록 지시합니다. 명령줄은 복원이 완료될 때까지 기다리지 않습니다. 즉, 명령줄은 메타데이터 서버에서 복원을 위해 많은 수의 항목을 큐에 대기할 수 있습니다. 이 방법은 메타데이터 서버에 과부하가 가해지고 복원 성능이 저하할 수 있습니다.

이 잠재적인 성능 문제를 방지하려면 경로를 안내하고 지정된 크기의 일괄 처리로 복원 요청을 발급하는 기본 스크립트를 만들 수 있습니다. 합리적인 성능을 달성하고 메타데이터 서버를 압도하지 않도록 하려면 1,000개에서 5,000개의 요청까지 배치 크기를 사용하는 것이 좋습니다.

예: 일괄 처리 복원 스크립트 만들기

다음 예제에서는 일괄 처리로 Blob 컨테이너에서 데이터를 복원하는 스크립트를 만드는 방법을 보여줍니다. 다음과 같은 내용으로 file_restorer.bash라는 파일을 만듭니다.

#!/bin/bash
set -feu
set -o pipefail
main()
{
    if [ $# -lt 2 ]; then
        echo "$0 <path_to_fully_restore> <max_restores_at_a_time>"
        echo "Missing parameters"
        exit 1
    fi
    local RESTORE_PATH=$1
    local MAX_RESTORES=$2
    local FILES_LIST="/tmp/files_to_restore"
    find "$RESTORE_PATH" -type f > "$FILES_LIST"
    local TOTAL_FILES
    TOTAL_FILES=$(wc -l "$FILES_LIST")
    local RESTORE_TOTAL=0
    local RESTORE_COUNT=0
    while IFS="" read -r p || [ -n "$p" ]; do
        printf '%s\n' "$p"
        lfs hsm_restore "$p"
        ((RESTORE_COUNT++)) || true
        ((RESTORE_TOTAL++)) || true
        if (( RESTORE_COUNT >= MAX_RESTORES )); then
            while true; do
                local STATE
                STATE=$(lfs hsm_state "$p")
                RELEASED=') released exists archived'
                if ! [[ $STATE =~ $RELEASED ]]; then
                    echo "Restored $RESTORE_TOTAL / $TOTAL_FILES"
                    break
                fi
                sleep 0.2
            done
            RESTORE_COUNT=0
        fi
    done < "$FILES_LIST"
}
main "$@"

다음 예제에서는 샘플 출력과 함께 스크립트를 실행하는 방법을 보여줍니다.

root@vm:~# time ~azureuser/file_restorer.bash /lustre/client/ 5000
Finding all files to restore beneath: /lustre/client/
Found 78100 to restore
Initiating restores in batches of 5000...
Restored 5000 / 78100
Restored 10000 / 78100
Restored 15000 / 78100
Restored 20000 / 78100
Restored 25000 / 78100
Restored 30000 / 78100
Restored 35000 / 78100
Restored 40000 / 78100
Restored 45000 / 78100
Restored 50000 / 78100
Restored 55000 / 78100
Restored 60000 / 78100
Restored 65000 / 78100
Restored 70000 / 78100
Restored 75000 / 78100
Restored 78100 / 78100
real	6m59.633s
user	1m20.273s
sys	0m37.960s

참고 항목

현재 Azure Managed Lustre는 Blob Storage의 데이터를 최대 처리량 속도 ~7.5GiB/초로 복원합니다.

내보내기 작업을 사용하여 Blob Storage로 데이터 내보내기

내보내기 작업을 만들어 Azure Managed Lustre 파일 시스템에서 Azure Blob Storage의 장기 스토리지로 데이터를 복사할 수 있습니다.

내보내기 작업 중에 내보내는 파일은 무엇인가요?

Azure Managed Lustre 시스템에서 파일을 내보낼 때 파일 시스템을 만들 때 지정한 Blob 컨테이너에 모든 파일이 복사되는 것은 아닙니다. 내보내기 작업에는 다음 규칙이 적용됩니다.

내보내기 작업은 새 파일이나 콘텐츠가 수정된 파일만 복사합니다. 파일 시스템을 만드는 동안 Blob 컨테이너에서 가져온 파일이 변경되지 않은 경우 내보내기 작업은 파일을 내보내지 않습니다.
메타데이터가 변경된 파일은 내보내지지 않습니다. 메타데이터 변경 내용에는 소유자, 사용 권한, 확장 특성 및 이름 변경(이름 변경)이 포함됩니다.
Azure Managed Lustre 파일 시스템에서 삭제된 파일은 내보내기 작업 중에 원래 Blob 컨테이너에서 삭제되지 않습니다. 내보내기 작업은 Blob 컨테이너의 파일을 삭제하지 않습니다.

활성 파일 시스템에서 내보내기 작업 실행

활성 파일 시스템에서 내보내기 작업 중에 파일을 변경하면 실패 상태가 발생할 수 있습니다. 이 오류 상태를 사용하면 파일 시스템의 모든 데이터를 Blob Storage로 내보낼 수 없다는 것을 알 수 있습니다. 이 경우 새 내보내기 작업을 만들어 내보내기를 다시 시도할 수 있습니다. 새 작업은 이전 작업에서 복사되지 않은 파일만 복사합니다.

작업이 많은 파일 시스템에서는 파일이 자주 변경되므로 재시도는 여러 번 실패할 수 있습니다. 파일이 Blob Storage로 성공적으로 내보내졌는지 확인하려면 해당 Blob에서 타임스탬프를 확인합니다. 작업이 완료되면 배포 시 구성된 로깅 컨테이너를 보고 내보내기 작업에 대한 자세한 정보를 볼 수도 있습니다. 로깅 컨테이너는 실패한 파일 및 실패한 이유에 대한 진단 정보를 제공합니다.

클러스터의 서비스 해제를 준비하고 Blob Storage로 최종 내보내기를 수행하려는 경우 내보내기 작업을 시작하기 전에 모든 I/O 작업이 중지되었는지 확인해야 합니다. 이 방법을 사용하면 파일 시스템 활동으로 인한 오류를 방지하여 모든 데이터를 내보낼 수 있습니다.

내보낸 파일에 대한 메타데이터

Azure Managed Lustre 파일 시스템에서 Blob 컨테이너로 파일을 내보낼 때 파일 시스템에 콘텐츠를 다시 가져오기를 간소화하기 위해 추가 메타데이터가 저장됩니다.

다음 표에서는 Blob 메타데이터에 키-값 쌍으로 저장되는 Lustre 파일 시스템의 POSIX 특성을 나열합니다.

POSIX 특성	Type
`owner`	int
`group`	int
`permissions`	octal 또는 rwxrwxrwx 형식; 스티커 비트가 지원됩니다.

디렉터리 특성은 빈 Blob에 저장됩니다. 이 Blob은 디렉터리 경로와 동일한 이름을 가지며 Blob 메타데이터 hdi_isfolder : true에 다음 키-값 쌍을 포함합니다.

컨테이너를 사용하여 새 Lustre 클러스터를 수화하기 전에 POSIX 특성을 수동으로 수정할 수 있습니다. 앞에서 설명한 키-값 쌍을 사용하여 Blob 메타데이터를 편집하거나 추가합니다.

내보내기 작업에 대한 고려 사항

내보내기 작업으로 데이터를 내보낼 때 고려해야 할 항목은 다음과 같습니다.

한 번에 하나의 가져오기 또는 내보내기 작업만 실행할 수 있습니다. 예를 들어 내보내기 작업이 진행 중인 경우 다른 내보내기 작업을 시작하려고 하면 오류가 반환됩니다.

AzCopy 또는 Storage Explorer를 사용하여 Lustre Blob 컨테이너 복사

AzCopy 또는 Storage Explorer를 사용하여 Lustre에서 사용하는 Blob 컨테이너를 이동하거나 복사할 수 있습니다.

AzCopy의 경우 다음 플래그를 추가하여 디렉터리 특성을 포함할 수 있습니다.

--include-directory-stub

이 플래그를 포함하면 전송 중에 디렉터리 POSIX 특성(예: owner, group및 permissions)이 유지됩니다. 이 플래그가 없거나 플래그가 설정된 false스토리지 컨테이너에서 사용하는 azcopy 경우 데이터 및 디렉터리도 전송에 포함되지만 디렉터리에는 POSIX 특성이 유지되지 않습니다.

Storage Explorer에서 전송을 선택하고 디렉터리 스텁 포함 확인란을 선택하여 설정에서 이 플래그를 사용하도록 설정할 수 있습니다.

다음을 통해 공유