ONTAP 의 pNFS는 FlexVol 볼륨과 FlexGroup 볼륨 모두에서 작동하지만, 가장 좋은 전반적인 결과를 얻으려면 FlexGroup 볼륨을 사용하세요.

FlexGroup 볼륨은 다음을 제공합니다.

"FlexGroup 볼륨 관리에 대해 알아보세요"

모든 NFS 클라이언트가 pNFS를 지원하는 것은 아니지만, 대부분의 최신 클라이언트는 pNFS를 지원합니다. RHEL 6.4와 Fedora 17이 최초로 pNFS를 지원한 클라이언트(대략 2014년)였으므로, 지난 몇 년 동안 출시된 클라이언트 버전은 이 기능을 완벽하게 지원한다고 추정하는 것이 타당합니다. ONTAP의 NFS 지원 입장은 "클라이언트가 해당 기능을 지원하고 RFC를 준수하며, 당사가 해당 기능을 지원하는 경우 해당 조합은 지원됩니다."입니다. 하지만 클라이언트 OS 공급업체가 pNFS를 지원하는지 확인하는 것이 가장 좋습니다.

ONTAP 동일한 클러스터 내의 노드나 집계 간에 볼륨을 중단 없이 이동할 수 있는 기능을 제공하여 용량과 성능 균형을 유연하게 조절할 수 있습니다. ONTAP 에서 볼륨 이동이 발생하면 pNFS 장치 매핑이 자동으로 업데이트되어 필요한 경우 클라이언트에게 새로운 볼륨-인터페이스 관계를 사용하도록 알립니다.

"볼륨 이동에 대해 알아보세요"

ONTAP 동일한 클러스터 내의 노드 간에 네트워크 인터페이스를 이동하여 성능 균형과 유지 관리 유연성을 제공하는 기능을 제공합니다. 볼륨 이동과 마찬가지로 ONTAP 에서 네트워크 인터페이스 마이그레이션이 발생하면 pNFS 장치 매핑이 자동으로 업데이트되어 필요한 경우 클라이언트에게 새로운 볼륨-인터페이스 관계를 사용하도록 알립니다.

그러나 NFSv4.1은 상태 저장 프로토콜이므로 네트워크 인터페이스 마이그레이션은 NFS 마운트를 적극적으로 사용하는 클라이언트에 방해가 될 수 있습니다. 유지 관리 창에서 네트워크 인터페이스 마이그레이션을 수행하고 잠재적인 네트워크 중단에 대해 클라이언트에게 알리는 것이 가장 좋습니다.

pNFS는 NFSv4.1과 동일한 저장소 장애 조치 고려 사항을 따릅니다. 이것들은 다음에서 자세히 다루어집니다. "NetApp 기술 보고서 4067: NFS 모범 사례 및 구축 가이드"일반적으로 pNFS와 관련된 모든 저장소 장애 조치/환불은 프로토콜의 상태성으로 인해 잠재적인 저장소 중단이 예상되므로 유지 관리 창에서 수행해야 합니다.

메타데이터 작업은 크기가 작지만 작업 부하에 따라 숫자가 많아질 수 있습니다(대량의 파일을 만들고 있습니까? "찾기" 명령을 실행하고 있나요? 그리고 총 파일 개수. 결과적으로 메타데이터 호출이 많은 작업 부하는 NFS 서버의 CPU에 부담을 주고 단일 연결에서 병목 현상이 발생할 가능성이 있습니다. pNFS(및 일반적으로 NFSv4.x)는 프로토콜 버전의 상태 저장, 잠금 메커니즘 및 일부 보안 기능이 CPU 사용률과 지연 시간에 부정적인 영향을 미칠 수 있으므로 성능에 따라 달라지는 높은 메타데이터 작업 부하는 적합하지 않습니다. 이러한 작업 유형(높은 GETATTR 또는 SETATTR 등)은 일반적으로 NFSv3에서 더 나은 성능을 보입니다.

pNFS의 메타데이터 서버는 NFS 내보내기의 초기 마운트 시 설정됩니다. 마운트 지점이 설정되면 다시 마운트되거나 데이터 인터페이스가 이동될 때까지 그 자리에 유지됩니다. 이러한 이유로 동일한 볼륨에 액세스하는 여러 클라이언트가 SVM 전반에서 서로 다른 노드와 데이터 인터페이스에 마운트되도록 하는 것이 가장 좋습니다. 이 접근 방식은 클러스터의 네트워크 인터페이스를 극대화하는 동시에 노드와 CPU 리소스 전반에 걸쳐 메타데이터 서버의 부하를 분산합니다. 이를 달성하는 한 가지 방법은 라운드 로빈 DNS 설정을 설정하는 것입니다. "NetApp 기술 보고서 ​​4523: ONTAP 의 DNS 부하 분산".

NFSv4.x는 여러 가지 방법으로 보안 기능을 제공합니다(자세한 내용은 다음에서 다룹니다. "NetApp 기술 보고서 4067: NFS 모범 사례 및 구축 가이드"). NFSv4.x ID 도메인은 NFS 내보내기에서 사용자와 그룹을 인증하려고 할 때 클라이언트와 서버가 ID 도메인에 동의해야 하는 방법 중 하나입니다. ID 도메인 불일치의 부작용 중 하나는 원치 않는 액세스를 방지하기 위해 사용자 또는 그룹이 익명화된 사용자(기본적으로 압축됨)로 표시되는 것입니다. NFSv4.x(및 pNFS)를 사용하는 경우 클라이언트와 서버에서 NFSv4.x ID 도메인이 일치하는지 확인하는 것이 가장 좋습니다.

앞서 언급했듯이 ONTAP 의 nconnect는 일부 작업 부하에서 성능을 개선하는 데 도움이 될 수 있습니다. pNFS를 사용하는 경우 nconnect가 스토리지 시스템에 대한 총 TCP 연결 수를 크게 늘려 성능을 향상시킬 수 있지만, 많은 클라이언트가 마운트 옵션을 활용할 경우 스토리지의 TCP 연결에 과부하가 걸려 문제가 발생할 수도 있다는 점을 이해하는 것이 중요합니다. NetApp Hardware Universe 노드당 TCP 연결 제한을 다룹니다.

노드의 TCP 연결 제한을 초과하면 기존 연결이 해제될 때까지 새로운 TCP 연결이 허용되지 않습니다. 이는 폭풍우가 잦은 환경에서는 복잡한 문제를 야기할 수 있습니다.

다음 표는 nconnect를 사용한 pNFS가 TCP 연결 제한을 초과할 수 있는 방식을 보여줍니다.

¹ 대부분의 ONTAP 단일 노드 TCP 연결 제한을 초과합니다.

ONTAP 의 세션 트렁킹을 사용하면 NFSv4.x 마운트에 대한 처리량과 경로 복원력을 높일 수 있습니다. pNFS와 함께 사용하면 클러스터의 각 노드가 세션 트렁크를 설정할 수 있습니다. 그러나 세션 트렁크는 노드당 최소 두 개의 인터페이스가 필요하고, pNFS는 의도한 대로 작동하려면 노드당 최소 하나의 인터페이스가 필요합니다. 또한 SVM의 모든 인터페이스는 NFS 클라이언트로 라우팅될 수 있어야 합니다. nconnect를 활용할 경우 세션 트렁킹과 pNFS가 제대로 작동하지 않습니다. nconnect와 세션 트렁킹은 상호 배타적인 기능으로 간주하세요.

"NFS 트렁킹에 대해 알아보세요"

pNFS가 제대로 작동하려면 클러스터의 각 노드에 라우팅 가능한 네트워크 인터페이스가 필요합니다. pNFS를 호스팅하는 NFS 서버와 동일한 SVM에 NFS 클라이언트로 라우팅할 수 없는 다른 네트워크 인터페이스가 있는 경우 ONTAP 여전히 ​​클라이언트에 대한 장치 매핑에서 해당 인터페이스를 광고합니다. NFS 클라이언트가 다른 서브넷의 인터페이스를 통해 데이터에 액세스하려고 하면 연결할 수 없게 되어 서비스 중단이 발생합니다. pNFS를 사용할 때 클라이언트가 액세스할 수 있는 SVM의 네트워크 인터페이스만 허용하는 것이 가장 좋습니다.

NFSv4.0은 NFSv4.1과 함께 ONTAP NFS 서버에서 활성화할 수 있는 옵션입니다. 하지만 pNFS는 NFSv4.0에서는 작동하지 않습니다. NFS 서버에서 NFSv4.0이 활성화된 경우 클라이언트가 자신도 모르게 해당 프로토콜 버전을 마운트할 가능성이 있으며 pNFS를 활용할 수 없습니다. 따라서 pNFS를 사용할 때 NFSv4.0을 명시적으로 비활성화하는 것이 가장 좋습니다. NFSv4.1은 여전히 ​​활성화되어 있어야 하며 NFSv4.0과 독립적으로 작동할 수 있습니다.

NFSv4.1 참조는 볼륨을 소유한 노드의 네트워크 인터페이스로의 클라이언트에서 마운트 경로를 지역화합니다. pNFS는 데이터 경로를 지역화하고, 마운트 경로는 메타데이터 서버가 됩니다.

두 기능을 함께 사용할 수는 있지만, pNFS와 함께 NFSv4.1 참조를 사용하면 동일한 노드에 여러 메타데이터 서버를 쌓아 여러 클러스터 노드에 메타데이터 서버를 분산하는 기능이 저하되는 바람직하지 않은 효과가 발생할 수 있습니다. pNFS를 사용할 때 메타데이터 서버가 클러스터 전체에 고르게 분산되지 않으면 단일 노드의 CPU가 메타데이터 요청으로 과부하가 걸려 성능 병목 현상이 발생할 수 있습니다.

따라서 pNFS를 사용할 때 NFSv4.1 참조를 사용하지 않는 것이 가장 좋습니다. 대신, 클러스터의 여러 네트워크 인터페이스와 노드에 마운트 포인트를 분산하세요.

"NFSv4 참조 활성화 또는 비활성화에 대해 알아보세요."

NFS Kerberos를 사용하면 krb5를 사용하여 인증을 암호화하고 krb5i 및 krb5p를 사용하여 데이터 패킷을 추가로 암호화할 수 있습니다. 이는 SVM에서 네트워크 인터페이스별로 활성화되며 자세한 내용은 다음에서 다룹니다. "NetApp 기술 보고서 4616: ONTAP에서 Microsoft Active Directory와 NFS Kerberos".

pNFS는 SVM의 노드와 네트워크 인터페이스 전반에 걸쳐 데이터 트래픽을 리디렉션할 수 있으므로 SVM의 각 네트워크 인터페이스에서 NFS Kerberos를 활성화하고 작동시켜야 합니다. SVM의 네트워크 인터페이스 중 Kerberos가 활성화되어 있지 않으면 pNFS가 해당 인터페이스의 데이터 볼륨에 액세스하려고 할 때 제대로 작동하지 않습니다.

예를 들어, 두 개의 네트워크 인터페이스(Kerberos에 대해 하나만 활성화됨)가 있는 pNFS 지원 SVM에서 병렬 dd를 사용하여 읽기 테스트를 실행할 때, Kerberos 지원 인터페이스에 있는 파일은 잘 수행되었지만, Kerberos가 활성화되지 않은 인터페이스가 있는 노드의 파일은 읽기를 완료하지 못했습니다. 두 인터페이스 모두에서 Kerberos가 활성화되었을 때 모든 파일이 예상대로 작동했습니다.

SVM의 모든 네트워크 인터페이스에서 NFS Kerberos가 활성화된 경우 pNFS와 함께 NFS Kerberos를 사용할 수 있습니다. NFS Kerberos는 패킷 암호화/복호화로 인해 성능 저하가 발생할 수 있으므로 워크로드에 NFS Kerberos를 적용하여 pNFS를 철저히 테스트하여 성능 저하가 워크로드에 지나치게 큰 영향을 미치지 않는지 확인하는 것이 가장 좋습니다.

아래는 RHEL 9.5 클라이언트에서 pNFS와 함께 krb5(인증) 및 krb5p(종단 간 암호화)를 사용할 때의 병렬 읽기 성능에 대한 예입니다. 이 테스트에서 Krb5p는 70%의 성능 저하를 보였습니다.

"강력한 보안을 위해 NFS를 사용한 Kerberos에 대해 알아보세요"

NFSv4.2는 ONTAP 9.8에 추가되었으며 사용 가능한 최신 NFSv4.x 버전입니다(RFC-7862). NFSv4.2에는 이를 활성화/비활성화하는 명시적인 옵션이 없습니다. 대신 NFSv4.1과 함께 활성화/비활성화됩니다. (-4.1 enabled). 클라이언트가 NFSv4.2를 지원하는 경우 별도로 지정하지 않으면 mount 명령 중에 지원되는 가장 높은 NFS 버전을 협상합니다. minorversion=2 마운트 옵션.

ONTAP 의 NFSv4.2는 다음 기능을 지원합니다.

pNFS는 NFSv4.1에서 처음 도입되었지만 NFSv4.2에서도 지원되며 관련 기능도 제공됩니다.

"NFSv4.2에 대한 ONTAP 지원에 대해 알아보세요"