Azure NetApp Files에 대한 NFS FAQ
이 문서는 Azure NetApp Files의 NFS 프로토콜에 대한 FAQ(질문과 대답)입니다.
Azure VM을 시작하거나 다시 부팅할 때 볼륨이 자동으로 탑재되도록 하려고 합니다. 내 호스트를 영구 NFS 볼륨에 대해 구성하려면 어떻게 할까요?
VM 시작 또는 다시 부팅 시 NFS 볼륨이 자동으로 탑재되도록 하려면 항목을 호스트의 /etc/fstab 파일에 추가합니다.
자세한 내용은 Windows 또는 Linux 가상 머신에 대한 볼륨 탑재를 참조하세요.
Azure NetApp Files에서 지원하는 NFS 버전은 무엇인가요?
Azure NetApp Files는 NFSv3 및 NFSv4.1을 지원합니다. NFS 버전 중 하나를 사용하여 볼륨을 만들 수 있습니다.
Azure NetApp Files는 공식적으로 NFSv4.2를 지원하나요?
Azure NetApp Files는 NFSv4.2나 그 보조 기능(스파스 파일 작업, 확장 기능 및 보안 레이블 포함)을 지원하지 않습니다. NFSv4.2 프로토콜을 사용하여 Azure NetApp Files에 NFS4.1 볼륨을 탑재할 수 있지만 NFSv4.2 사용은 지원되지 않습니다.
Azure NetApp Files 볼륨은 다음 두 가지 방법 중 하나로 NFSv4.2 프로토콜을 사용하여 탑재할 수 있습니다.
- 탑재 옵션에서
vers=4.2,nfsvers=4.2,nfsvers=4,minorversion=2을 명시적으로 지정합니다. - 탑재 옵션에서 NFS 버전을 지정하지 않고 NFS 클라이언트가 허용되는 가장 높은 지원 대상 NFS 버전과 협상할 수 있도록 허용합니다. Linux 배포판에 따라 NFSv4.2가 사용 가능한 가장 높은 NFS 프로토콜로 사용될 수 있습니다.
많은 클라이언트에서 NFSv4.2 또는 NFSv4.2 확장 특성 기능을 완전히 지원하지 않는 경우 문제가 발생할 수 있습니다. NFSv4.2는 Azure NetApp Files에서 지원되지 않으므로 NFSv4.2와 관련된 모든 문제는 지원 범위를 벗어납니다. NFSv4.2를 탑재하는 클라이언트와 관련된 문제를 방지하고 지원 가능하게 준수하려면 NFSv4.1 버전이 탑재 옵션에 지정되어 있는지 또는 클라이언트의 NFS 클라이언트 구성이 NFSv4.1에서 NFS 버전을 제한하도록 설정되어 있는지 확인합니다.
자세한 내용은 Azure NetApp Files의 NAS 프로토콜 이해를 참조하세요.
루트 quash 병합을 사용하도록 설정하려면 어떻게 할까요?
볼륨의 내보내기 정책을 사용하여 루트 계정에서 볼륨에 액세스할 수 있는지 여부를 지정할 수 있습니다. 자세한 내용은 NFS 볼륨에 대한 내보내기 정책 구성을 참조하세요.
여러 볼륨에 동일한 파일 경로를 사용할 수 있나요?
다음과 같은 경우 동일한 파일 경로를 사용할 수 있습니다.
- 다양한 지역에 배포된 볼륨
- 동일한 지역 내의 다른 가용성 영역에 배포된 볼륨
사용하는 항목:
- 지역 볼륨(가용성 영역 없음) 또는
- 동일한 가용성 영역 내의 볼륨,
동일한 파일 경로를 사용할 수 있지만 파일 경로는 위임된 각 서브넷 내에서 고유하거나 위임된 다른 서브넷에 할당되어야 합니다.
자세한 내용은 Azure NetApp Files용 NFS 볼륨 만들기 또는 Azure NetApp Files용 이중 프로토콜 볼륨 만들기를 참조하세요.
Windows 클라이언트를 통해 NFS 볼륨에 액세스하려고 할 때 클라이언트에서 폴더 및 하위 폴더를 검색하는 데 오래 걸리는 이유는 무엇인가요?
Windows 클라이언트에서 CaseSensitiveLookup을 사용하도록 설정하여 폴더 및 하위 폴더의 조회 속도를 높일 수 있는지 확인합니다.
- 다음 PowerShell 명령을 사용하여 CaseSensitiveLookup을 사용하도록 설정합니다.
Set-NfsClientConfiguration -CaseSensitiveLookup 1 - 볼륨을 Windows 서버에 탑재합니다.
예시:
Mount -o rsize=1024 -o wsize=1024 -o mtype=hard \\10.x.x.x\testvol X:*
Azure NetApp Files에서 NFSv4.1 파일 잠금을 지원하려면 어떻게 해야 하나요?
NFSv4.1 클라이언트의 경우 Azure NetApp Files는 임대 기반 모델에서 모든 파일 잠금 상태를 유지 관리하는 NFSv4.1 파일 잠금 메커니즘을 지원합니다.
RFC 3530에 따라 Azure NetApp Files는 NFS 클라이언트에서 보유한 모든 상태에 대한 단일 임대 기간을 정의합니다. 클라이언트에서 정의된 기간 내에 임대를 갱신하지 않으면 서버에서 클라이언트의 임대와 관련된 모든 상태를 해제합니다.
예를 들어 볼륨을 탑재하는 클라이언트에서 응답하지 않거나 시간 제한을 초과하여 작동이 중단되면 잠금이 해제됩니다. 클라이언트는 파일 읽기 등의 작업을 수행하여 임대를 명시적 또는 암시적으로 갱신할 수 있습니다.
유예 기간은 클라이언트에서 서버 복구 중에 잠금 상태를 회수하려고 시도할 수 있는 특별한 처리 기간을 정의합니다. 기본 임대 시간 제한은 30초이며, 유예 기간은 45초입니다. 해당 시간이 지나면 클라이언트의 임대가 해제됩니다.
Azure NetApp Files는 파일 잠금을 해제하는 기능도 지원합니다.
Azure NetApp Files의 파일 잠금에 대한 자세한 내용은 파일 잠금을 참조하세요.
.snapshot 디렉터리가 NFSv4.1 볼륨에 표시되지 않지만 NFSv3 볼륨에 표시되는 이유는 무엇인가요?
의도적으로 .snapshot 디렉터리는 NFSv4.1 클라이언트에 표시되지 않습니다. 기본적으로 .snapshot 디렉터리는 NFSv3 클라이언트에 표시됩니다. NFSv3 클라이언트에서 .snapshot 디렉터리를 숨기려면 볼륨의 속성을 편집하여 스냅샷 경로를 숨깁니다.
Oracle dNFS
dNFS에 필요한 Oracle 패치가 있나요?
Important
Oracle 19c 이상을 사용 중인 고객은 Oracle 버그 32931941에 대한 패치가 적용되었는지 확인해야 합니다. 현재 Oracle 고객이 사용 중인 패치 번들의 대부분은 이 패치를 *포함하지 않습니다*. 이 패치는 최근 패치 번들의 일부에만 포함되어 있습니다.
데이터베이스가 이 버그에 노출되면 네트워크 중단으로 인해 파손된 블록 손상이 발생할 가능성이 높습니다. 네트워크 중단에는 스토리지 엔드포인트 재배치, 볼륨 재배치 및 스토리지 서비스 유지 관리 이벤트와 같은 이벤트가 포함됩니다. 손상이 즉시 감지되지 않을 수도 있습니다.
이러한 손상은 ONTAP 또는 Azure NetApp Files 서비스 자체의 버그가 아니라 Oracle dNFS 버그의 결과입니다. 특정 네트워킹 중단 또는 재구성 이벤트 중 NFS IO에 대한 응답이 잘못 처리됩니다. 데이터베이스는 작성될 때 업데이트되고 있었던 블록을 잘못 작성합니다. 경우에 따라 손상된 블록은 나중에 동일한 블록의 덮어쓰기를 통해 자동으로 수정됩니다. 그렇지 않은 경우 Oracle 데이터베이스 프로세스는 결국 이를 감지합니다. 경고 로그에 오류가 기록되어야 하며 Oracle 인스턴스가 종료될 가능성이 높습니다. 또한 dbv 및 RMAN 작업으로 손상을 감지할 수 있습니다.
Oracle은 권장 dNFS 패치로 지속적으로 업데이트되는 문서 1495104.1을 게시합니다. 데이터베이스에서 dNFS를 사용하는 경우 DBA 팀이 이 문서에서 업데이트를 확인하고 있는지 확인하세요.
Important
Azure NetApp Files 볼륨에서 NFSv4.1과 함께 Oracle dNFS를 사용하는 고객은 NFSv4.1에서 Oracle dNFS를 사용하는 데 필요한 패치가 있나요?에서 언급한 작업을 수행해야 합니다.
NFSv4.1에서 Oracle dNFS를 사용하는 데 필요한 패치가 있나요?
Important
데이터베이스가 NFSv4.1에서 Oracle dNFS를 사용 중인 경우 Oracle 버그 33132050 및 33676296에 대한 패치를 적용해야 합니다. 다른 버전의 Oracle에 대한 백포트를 요청해야 할 수 있습니다. 예를 들어, 작성 당시 이러한 패치는 19.11에 사용할 수 있지만 아직 19.3에는 사용할 수 없습니다. 지원 사례에 이러한 버그 번호를 포함하면 Oracle의 지원 엔지니어가 취할 조치를 파악하게 됩니다.
이 요구 사항은 일반적으로 온-프레미스 ONTAP 및 Azure NetApp Files를 모두 포함하는 ONTAP 기반 시스템 및 서비스에 적용됩니다.
이러한 패치가 적용되지 않은 경우 발생할 수 있는 문제의 예는 다음과 같습니다.
- 백 엔드 스토리지 엔드포인트 이동 시 데이터베이스가 중단됩니다.
- Azure NetApp Files 서비스 유지 관리 이벤트 시 데이터베이스가 중단됩니다.
- 정상 작동 중에 눈에 띄거나 눈에 띄지 않을 수 있는 간단한 Oracle이 중단됩니다.
- 느린 Oracle 종료: 종료 프로세스를 모니터링하는 경우 dNFS I/O가 시간 초과됨에 따라 최대 몇 분의 지연을 추가할 수 있는 일시 중지가 나타납니다.
- 데이터베이스를 중단시키는 읽기에 대한 잘못된 dNFS 회신 캐싱 동작입니다.
이 패치에는 dNFS 세션 관리 변경 및 이러한 문제를 해결하는 NFS 회신 캐싱이 포함됩니다.
이러한 두 버그에 대해 패치를 적용할 수 없는 경우 NFSv4.1에서 dNFS를 사용하면 안 됩니다. dNFS를 사용하지 않도록 설정하거나 NFSv3으로 전환할 수 있습니다.
Oracle dNFS 및 NFSv4.1에서 다중 경로를 사용할 수 있나요?
NFSv4.1을 사용하는 경우 dNFS는 여러 경로에서 작동하지 않습니다. 다중 경로가 필요한 경우 NFSv3을 사용해야 합니다. dNFS에서 NFSv4.1이 다중 경로로 작동하려면 클러스터 전체의 clientID 및 sessionID 트렁킹이 필요하며 이는 Azure NetApp Files에서 지원되지 않습니다. 따라서 dNFS를 시작하는 동안 중단이 발생합니다.