NAS 구성 및 NFS 스토리지 대상 문제 해결

아티클
02/21/2024

이 문서에서는 Azure HPC Cache에서 NFS 스토리지 시스템을 스토리지 대상으로 추가할 수 없도록 하는 몇 가지 일반적인 구성 오류 및 기타 문제에 대한 솔루션을 제공합니다.

이 문서에는 포트를 확인하는 방법과 NAS 시스템에 필요한 액세스를 사용하도록 설정하는 방법에 대한 세부 정보가 포함되어 있습니다. 또한 NFS 스토리지 대상을 만들 수 없도록 하는 일반적이지 않은 문제에 대한 자세한 정보도 제공합니다.

팁

이 가이드를 사용하기 전에 NFS 스토리지 대상의 필수 구성 요소를 읽어 보세요.

문제에 대한 솔루션이 여기에 포함되지 않은 경우 Microsoft 서비스 및 지원에서 사용자와 협력하여 문제를 조사하고 해결할 수 있도록 지원 티켓을 여세요.

충분한 연결 스레드 제공

대형 HPC Cache 시스템은 스토리지 대상에 대해 여러 번 연결을 요청합니다. 예를 들어, 스토리지 대상이 Ubuntu Linux nfs-kernel-server 모듈을 사용하는 경우 기본 NFS 디먼 스레드 수는 최저 8개일 수 있습니다. 스레드 수를 128개 또는 256개로 늘립니다. 이는 중형 또는 대형 HPC Cache를 지원하는 데 더 적합한 수입니다.

/etc/init.d/nfs-kernel-server의 RPCNFSDCOUNT 값을 사용하여 Ubuntu에서 스레드 수를 확인하거나 설정할 수 있습니다.

포트 설정 확인

Azure HPC Cache에는 백 엔드 NAS 스토리지 시스템의 여러 UDP/TCP 포트에 대한 읽기/쓰기 권한이 필요합니다. NAS 시스템에서 이러한 포트에 액세스할 수 있는지 확인하고 스토리지 시스템과 캐시 서브넷 사이의 방화벽을 통해 이러한 포트에 대한 트래픽이 허용되는지도 확인합니다. 데이터 센터에서 이 구성을 확인하려면 방화벽 및 네트워크 관리자와 협력해야 할 수 있습니다.

포트는 스토리지 시스템의 공급업체에 따라 달라지므로 스토리지 대상을 설정할 때 시스템의 요구 사항을 확인해야 합니다.

일반적으로 캐시는 다음 포트에 액세스해야 합니다.

프로토콜	포트	서비스
TCP/UDP	111	rpcbind
TCP/UDP	2049	NFS
TCP/UDP	4045	nlockmgr
TCP/UDP	4046	mountd
TCP/UDP	4047	status

시스템에 필요한 특정 포트를 알아보려면 다음 rpcinfo 명령을 사용하세요. 아래 명령은 포트를 나열하고 관련 결과를 테이블 형식으로 지정합니다. <storage_IP> 용어 대신 시스템의 IP 주소를 사용하세요.

NFS 인프라가 설치된 모든 Linux 클라이언트에서 이 명령을 실행할 수 있습니다. 클러스터 서브넷 내에서 클라이언트를 사용하는 경우 서브넷과 스토리지 시스템 간의 연결을 확인하는 데도 도움이 될 수 있습니다.

rpcinfo -p <storage_IP> |egrep "100000\s+4\s+tcp|100005\s+3\s+tcp|100003\s+3\s+tcp|100024\s+1\s+tcp|100021\s+4\s+tcp"| awk '{print $4 "/" $3 " " $5}'|column -t

rpcinfo 쿼리에서 반환된 모든 포트가 Azure HPC Cache의 서브넷에서 무제한 트래픽을 허용하는지 확인합니다.

이러한 설정은 NAS 자체에서 확인하고 스토리지 시스템과 캐시 서브넷 사이의 방화벽에서도 확인합니다.

루트 Squash 설정 확인

루트 Squash 설정이 잘못 구성된 경우 파일 액세스를 방해할 수 있습니다. 각 스토리지 내보내기 및 일치하는 HPC Cache 클라이언트 액세스 정책에 대한 설정이 적절한지 확인해야 합니다.

루트 Squash는 클라이언트의 로컬 슈퍼 사용자 루트가 보낸 요청이 루트로 백 엔드 스토리지 시스템에 전송되지 않도록 합니다. 루트에서 'nobody'와 같은 권한이 없는 사용자 ID(UID)로 요청을 다시 할당합니다.

팁

이전 버전의 Azure HPC Cache는 HPC Cache에서 루트 액세스를 허용하기 위해 NAS 스토리지 시스템이 필요했습니다. 이제 HPC Cache 클라이언트가 내보내기에 대한 루트 액세스 권한을 가지지 않는 한 스토리지 대상 내보내기에 대한 루트 액세스를 허용할 필요가 없습니다.

다음 위치에서 HPC Cache 시스템의 루트 Squash를 구성할 수 있습니다.

Azure HPC Cache에서 - 클라이언트 액세스 정책을 사용하여 특정 필터 규칙과 일치하는 클라이언트에 대한 루트 Squash를 구성합니다. 클라이언트 액세스 정책은 각 NFS 스토리지 대상 네임스페이스 경로의 일부입니다.

기본 클라이언트 액세스 정책은 루트 Squash를 구성하지 않습니다.
스토리지 내보내기에서 - 루트에서 들어오는 요청을 권한이 없는 사용자 ID(UID)로 다시 할당하도록 스토리지 시스템을 구성할 수 있습니다.

스토리지 시스템이 루트 Squash를 내보내는 경우 해당 스토리지 대상에 대한 HPC Cache 클라이언트 액세스 규칙을 루트 Squash에도 업데이트해야 합니다. 그렇지 않은 경우 HPC Cache를 통해 백 엔드 스토리지 시스템을 읽거나 쓰려고 할 때 액세스 문제가 발생할 수 있습니다.

이 표는 클라이언트 요청이 UID 0(루트)으로 전송될 때 다양한 루트 Squash 시나리오에 대한 동작을 보여 줍니다. *로 표시된 시나리오는 액세스 문제를 일으킬 수 있으므로 권장되지 않습니다.

설정	클라이언트에서 전송된 UID	HPC Cache에서 전송된 UID	백 엔드 스토리지의 유효 UID
루트 스쿼시 없음	0(루트)	0(루트)	0(루트)
HPC Cache에서만 루트 Squash	0(루트)	65534(대상 없음)	65534(대상 없음)
*NAS 스토리지에서만 루트 Squash	0(루트)	0(루트)	65534(대상 없음)
HPC Cache 및 NAS에 루트 Squash	0(루트)	65534(대상 없음)	65534(대상 없음)

(UID 65534는 예입니다. 클라이언트 액세스 정책에서 루트 Squash를 켜면 UID를 사용자 지정할 수 있습니다.)

디렉터리 경로에 대한 액세스 확인

계층적 디렉터리를 내보내는 NAS 시스템의 경우 Azure HPC Cache에 사용 중인 파일 경로의 각 내보내기 수준에 대한 적절한 액세스 권한이 있는지 확인합니다.

예를 들어 시스템에 다음과 같은 세 가지 내보내기가 표시될 수 있습니다.

/ifs
/ifs/accounting
/ifs/accounting/payroll

내보내기 /ifs/accounting/payroll은 /ifs/accounting의 자식이고, /ifs/accounting 자체는 /ifs의 자식입니다.

payroll 내보내기를 HPC Cache 스토리지 대상으로 추가하면 캐시는 실제로 /ifs/를 탑재하고 여기에서 급여 디렉터리에 액세스합니다. 따라서 Azure HPC Cache는 /ifs/accounting/payroll 내보내기에 액세스하기 위해 /ifs에 대한 충분한 액세스 권한이 필요합니다.

이 요구 사항은 스토리지 시스템에서 제공하는 파일 핸들을 사용하여 캐시에서 파일을 인덱싱하고 파일 충돌을 방지하는 방법과 관련이 있습니다.

계층적 내보내기를 사용하는 NAS 시스템은 파일이 다른 내보내기에서 검색되는 경우 동일한 파일에 대해 서로 다른 파일 핸들을 제공할 수 있습니다. 예를 들어 한 클라이언트는 /ifs/accounting을 탑재하고 payroll/2011.txt 파일에 액세스할 수 있습니다. 다른 클라이언트는 /ifs/accounting/payroll을 탑재하고 2011.txt 파일에 액세스합니다. 스토리지 시스템에서 파일 핸들을 할당하는 방법에 따라 두 클라이언트는 서로 다른 파일 핸들(각각 <mount2>/payroll/2011.txt 및 <mount3>/2011.txt에 대한 파일 핸들)을 사용하는 동일한 파일을 받을 수 있습니다.

백 엔드 스토리지 시스템은 파일 핸들에 대한 내부 별칭을 유지하지만 Azure HPC Cache는 동일한 항목을 참조하는 인덱스의 파일 핸들을 구분할 수 없습니다. 따라서 캐시는 동일한 파일에 대해 서로 다른 쓰기를 캐시할 수 있으며, 해당 파일이 동일하다는 점을 알 수 없기 때문에 변경 내용을 잘못 적용할 수 있습니다.

여러 내보내기의 파일에서 발생할 수 있는 파일 충돌을 방지하기 위해 Azure HPC Cache는 가장 단순한 내보내기를 경로(예제의 /ifs)에 자동으로 탑재하고 해당 내보내기에서 제공된 파일 핸들을 사용합니다. 여러 내보내기에서 동일한 기본 경로를 사용하는 경우 Azure HPC Cache는 해당 경로에 액세스해야 합니다.

VPN 패킷 크기 제한 조정

캐시와 NAS 디바이스 사이에 VPN이 있는 경우 VPN은 전체 크기의 1500바이트 이더넷 패킷을 차단할 수 있습니다. NAS와 Azure HPC Cache 인스턴스 간의 대량 교환이 완료되지 않았는데 더 작은 업데이트가 예상대로 작동하는 경우 이 문제가 발생할 수 있습니다.

VPN 구성의 세부 정보를 알 수 없는 경우 시스템에 이 문제가 있는지 여부를 알 수 있는 간단한 방법이 없습니다. 다음은 이 문제를 확인하는 데 도움이 될 수 있는 몇 가지 방법입니다.

VPN의 양쪽에서 패킷 스니퍼를 사용하여 성공적으로 전송되는 패킷을 검색합니다.
VPN에서 ping 명령을 허용하는 경우 전체 크기의 패킷 보내기를 테스트할 수 있습니다.

다음 옵션을 사용하여 VPN을 통해 NAS에 대해 ping 명령을 실행합니다. <storage_IP> 값 대신 스토리지 시스템의 IP 주소를 사용합니다.
```
ping -M do -s 1472 -c 1 <storage_IP>
```
명령의 옵션은 다음과 같습니다.
- -M do - 조각화하지 않습니다.
- -c 1 - 패킷을 하나만 보냅니다.
- -s 1472 - 페이로드의 크기를 1472바이트로 설정합니다. 이더넷 오버헤드를 고려한 후 1500바이트 패킷의 최대 크기 페이로드입니다.
성공적인 응답은 다음과 같습니다.
```
PING 10.54.54.11 (10.54.54.11) 1472(1500) bytes of data.
1480 bytes from 10.54.54.11: icmp_seq=1 ttl=64 time=2.06 ms
```
ping이 1472바이트로 실패하는 경우 패킷 크기 문제가 있을 수 있습니다.

문제를 해결하려면 VPN에서 MSS 제한을 구성하여 원격 시스템이 최대 프레임 크기를 제대로 검색하도록 해야 합니다. 자세히 알아보려면 VPN Gateway IPsec/IKE 매개 변수 설명서를 읽어 보세요.

경우에 따라 Azure HPC Cache의 MTU 설정을 1400으로 변경하면 도움이 될 수 있습니다. 그러나 캐시에서 MTU를 제한하는 경우 캐시와 상호 작용하는 백 엔드 스토리지 시스템 및 클라이언트에 대한 MTU 설정도 제한해야 합니다. 자세한 내용은 추가 Azure HPC Cache 설정 구성을 참조하세요.

ACL 보안 스타일 확인

일부 NAS 시스템은 기존 POSIX 또는 UNIX 보안과 ACL(액세스 제어 목록)을 결합하는 하이브리드 보안 스타일을 사용합니다.

시스템에서 “ACL” 머리글자어를 포함하지 않고 UNIX 또는 POSIX로 해당 보안 스타일을 보고하는 경우 이 문제는 영향을 주지 않습니다.

ACL을 사용하는 시스템인 경우 Azure HPC Cache에서 파일 액세스를 제어하려면 사용자 관련 값을 추가로 추적해야 합니다. 이렇게 하려면 액세스 캐시를 사용하도록 설정합니다. 액세스 캐시를 설정할 수 있도록 사용자에게 표시되는 컨트롤은 없지만, 지원 티켓을 열어 캐시 시스템에서 영향을 받는 스토리지 대상에 대해 액세스 캐시 사용을 설정하도록 요청할 수 있습니다.

다음 단계

이 문서에서 해결되지 않은 문제가 있는 경우 고객 지원팀에 문의하여 전문가의 도움을 받으세요.

다음을 통해 공유