Azure HPC Cache에서 NFS 탑재 Blob 컨테이너를 사용할 수 있습니다. Blob Storage 설명서 사이트의 Azure Blob Storage에서 NFS 3.0 프로토콜 지원에 대해 자세히 알아보세요.
Azure HPC Cache는 ADLS-NFS 스토리지 대상 유형에서 NFS 지원 Blob Storage를 사용합니다. 이러한 스토리지 대상은 일반 NFS 스토리지 대상과 유사하지만 일반 Azure Blob 대상과 일부 겹치기도 합니다.
이 문서에서는 ADLS-NFS 스토리지 대상을 사용할 때 이해해야 하는 전략 및 제한 사항에 대해 설명합니다.
또한 호환되고 호환되지 않는 시나리오를 설명하는 NFS Blob 설명서, 특히 다음 섹션을 읽고 문제 해결 팁을 제공해야 합니다.
일관성 요구 사항 이해
HPC Cache에는 ADLS-NFS 스토리지 대상에 대한 강력한 일관성이 필요합니다. 기본적으로 NFS 사용 Blob Storage는 파일 메타데이터를 엄격하게 업데이트하지 않으므로 HPC Cache에서 파일 버전을 정확하게 비교할 수 없습니다.
이러한 차이를 해결하기 위해 Azure HPC Cache는 스토리지 대상으로 사용되는 NFS 사용 Blob 컨테이너에서 NFS 특성 캐싱을 자동으로 사용하지 않도록 설정합니다.
이 설정은 캐시에서 제거하더라도 컨테이너의 수명 동안 유지됩니다.
NFS 프로토콜을 사용하여 데이터 미리 로드
NFS 사용 Blob 컨테이너에서 파일을 만들 때 사용한 것과 동일한 프로토콜에서만 편집할 수 있습니다. 즉, Azure REST API를 사용하여 컨테이너를 채우는 경우 NFS를 사용하여 해당 파일을 업데이트할 수 없습니다. Azure HPC Cache는 NFS만 사용하므로 Azure REST API를 사용하여 만든 파일을 편집할 수 없습니다. ( Blob Storage API의 알려진 문제에 대해 자세히 알아보기)
컨테이너가 비어 있거나 NFS를 사용하여 파일을 만든 경우 캐시에 문제가 되지 않습니다.
컨테이너의 파일이 NFS 대신 Azure Blob REST API를 사용하여 만들어진 경우 Azure HPC Cache는 원래 파일에서 다음 작업으로 제한됩니다.
- 디렉터리에 파일을 나열합니다.
- 파일을 읽고 이후 읽기를 위해 캐시에 보관합니다.
- 파일을 삭제합니다.
- 파일을 비웁니다(0으로 자림).
- 파일의 복사본을 저장합니다. 복사본은 NFS에서 만든 파일로 표시되며 NFS를 사용하여 편집할 수 있습니다.
Azure HPC Cache는 REST를 사용하여 만든 파일의 내용을 편집할 수 없습니다. 즉, 캐시는 변경된 파일을 클라이언트에서 스토리지 대상으로 다시 저장할 수 없습니다.
NFS로 생성되지 않은 파일에서 읽기/쓰기 캐싱 사용 모델을 사용하는 경우 데이터 무결성 문제가 발생할 수 있으므로 이 제한을 이해하는 것이 중요합니다.
팁 (조언)
캐시 사용 모델 이해에서 읽기 및 쓰기 캐싱에 대해 자세히 알아봅니다.
캐싱 시나리오 작성
이러한 캐시 사용 모델에는 쓰기 캐싱이 포함됩니다.
- 15% 이상 쓰기
- 15% 이상의 쓰기, 백킹 서버에서 30초마다 변경 내용 확인
- 쓰기가 15%를 초과하는 경우, 백업 서버의 변경 사항을 60초마다 확인합니다
- 쓰기 작업이 15% 이상이면, 30초마다 서버에 다시 기록합니다
쓰기 캐싱 사용 모델은 NFS로 만든 파일에만 사용해야 합니다.
REST에서 만든 파일에 쓰기 캐싱을 사용하려고 하면 파일 변경 내용이 손실될 수 있습니다. 캐시가 파일 편집을 스토리지 컨테이너에 즉시 저장하려고 하지 않기 때문입니다.
REST에서 만든 파일에 쓰기를 캐시하려고 하면 데이터가 위험에 처하게 되는 방법은 다음과 같습니다.
캐시는 클라이언트의 편집을 수락하고 각 변경 내용에 대한 성공 메시지를 반환합니다.
캐시는 변경된 파일을 스토리지에 유지하고 추가 변경 내용을 기다립니다.
시간이 지나면 캐시는 변경된 파일을 백 엔드 컨테이너에 저장하려고 시도합니다. 이때 NFS를 사용하여 REST에서 만든 파일에 쓰려고 하므로 오류 메시지가 표시됩니다.
클라이언트 컴퓨터에 변경 내용이 수락되지 않았으며 캐시에서 원래 파일을 업데이트할 방법이 없다는 것을 알리기에는 너무 늦었습니다. 따라서 클라이언트의 변경 내용이 손실됩니다.
캐싱 시나리오 읽기
읽기 캐싱 시나리오는 NFS 또는 Azure Blob REST API를 사용하여 만든 파일에 적합합니다.
이러한 사용 모델은 읽기 캐싱만 사용합니다.
- 읽기 작업이 많고, 쓰기 작업은 드문 경우
- 클라이언트는 캐시를 우회하여 NFS 대상에 씁니다.
- 무거운 읽기, 3 시간마다 백업 서버를 확인
REST API 또는 NFS에서 만든 파일과 함께 이러한 사용 모델을 사용할 수 있습니다. 클라이언트에서 백 엔드 컨테이너로 전송된 NFS 쓰기는 여전히 실패하지만 즉시 실패하고 클라이언트에 오류 메시지를 반환합니다.
읽기 캐싱 워크플로는 캐시되지 않는 한 파일 변경 내용을 포함할 수 있습니다. 예를 들어 클라이언트는 컨테이너의 파일에 액세스하지만 변경 내용을 새 파일로 다시 쓰거나 수정된 파일을 다른 위치에 저장할 수 있습니다.
NLM(네트워크 잠금 관리자) 제한 사항 인식
NFS 사용 Blob 컨테이너는 충돌으로부터 파일을 보호하기 위해 일반적으로 사용되는 NFS 프로토콜인 NLM(네트워크 잠금 관리자)을 지원하지 않습니다.
NFS 워크플로가 원래 하드웨어 스토리지 시스템에 대해 작성된 경우 클라이언트 애플리케이션에 NLM 요청이 포함될 수 있습니다. 프로세스를 NFS 지원 Blob Storage로 이동할 때 이 제한을 해결하려면 클라이언트가 캐시를 탑재할 때 NLM을 사용하지 않도록 설정해야 합니다.
NLM을 사용하지 않도록 설정하려면 클라이언트의 -o nolock 명령에서 옵션을 mount 사용합니다. 이 옵션은 클라이언트가 NLM 잠금을 요청하고 응답에서 오류를 수신하지 못하도록 합니다. 이 nolock 옵션은 다른 운영 체제에서 다르게 구현됩니다. 자세한 내용은 클라이언트 OS 설명서(man 5 nfs)를 확인하세요.
HPC Cache를 사용하여 NFS 지원 컨테이너에 대한 쓰기 간소화
Azure HPC Cache는 ADLS-NFS 스토리지 대상에 대한 변경 내용을 작성하는 작업을 포함하는 워크로드의 성능을 개선하는 데 도움이 될 수 있습니다.
메모
Azure HPC Cache를 통해 파일을 수정하려면 NFS를 사용하여 ADLS-NFS 스토리지 컨테이너를 채워야 합니다.
NFS 지원 Blob 성능 고려 사항 문서에 설명된 제한 사항 중 하나는 ADLS-NFS 스토리지가 기존 파일을 덮어쓰는 데 매우 효율적이지 않다는 것입니다. NFS 탑재 Blob Storage에서 Azure HPC Cache를 사용하는 경우 클라이언트가 활성 파일을 수정할 때 캐시가 간헐적으로 다시 쓰기를 처리합니다. 백 엔드 컨테이너에 파일을 쓰는 대기 시간은 클라이언트에서 숨겨집니다.
NFS 프로토콜을 사용하여 데이터를 미리 로드할 때 위에서 설명한 제한 사항에 유의하세요.