Skip to main content
Enterprise applications
본 한국어 번역은 사용자 편의를 위해 제공되는 기계 번역입니다. 영어 버전과 한국어 버전이 서로 어긋나는 경우에는 언제나 영어 버전이 우선합니다.

직접 연결 네트워킹

기여자 jfsinmsp

시스템 관리자는 구성에서 네트워크 스위치를 제거하여 인프라를 단순화하는 것을 선호하는 경우가 있습니다. 이렇게 하면 구성 요소 수를 줄이고 랙 공간을 절약하여 보다 독립적인 솔루션을 구축할 수 있습니다. 하지만 사용 중인 프로토콜에 따라 몇 가지 중요한 제약 사항이 있습니다.

파이버 채널

ONTAP 9.19.1부터 일부 스토리지 시스템 FC 어댑터를 사용하면 기존 FC-SAN(SCSI) 및 NVMe/FC 모두에서 직접 연결 FC가 지원됩니다. HBA는 표준 지점 간 FC 연결을 설정합니다.

ONTAP 9.19.1 이전 버전에서는 ONTAP 스토리지 시스템에 NPIV가 필요합니다. 즉, 스토리지 시스템이 NPIV를 지원하는 FC 스위치에 연결되어 있어야 합니다.

iSCSI 및 NVMe/TCP

iSCSI 또는 NVMe/TCP를 사용하는 호스트는 스토리지 시스템에 직접 연결하여 정상적으로 작동할 수 있습니다. 그 이유는 경로 지정입니다. 두 개의 서로 다른 스토리지 컨트롤러에 직접 연결되므로 데이터 흐름을 위한 두 개의 독립적 경로가 됩니다. 경로, 포트 또는 컨트롤러가 손실되어도 다른 경로가 사용되지 않습니다.

NFS 를 참조하십시오

직접 연결 NFS 스토리지를 사용할 수 있지만 중대한 제한 사항이 있는 경우 스크립팅의 상당한 노력 없이는 페일오버가 수행되지 않으며 고객의 책임입니다.

직접 연결 NFS 스토리지에서 무중단 페일오버가 복잡해지는 이유는 로컬 OS에서 발생하는 라우팅입니다. 예를 들어, 호스트의 IP 주소가 192.168.1.1/24이고 IP 주소가 192.168.1.50/24인 ONTAP 컨트롤러에 직접 연결되어 있다고 가정합니다. 장애 조치 중에 192.168.1.50 주소는 다른 컨트롤러로 장애 조치될 수 있으며 호스트에서 사용할 수 있지만 호스트는 어떻게 그 존재를 감지합니까? 원래 192.168.1.1 주소는 더 이상 운영 체제에 연결되지 않는 호스트 NIC에 계속 존재합니다. 192.168.1.50으로 향하는 트래픽은 작동하지 않는 네트워크 포트로 계속 전송됩니다.

두 번째 OS NIC는 192.168.1.2로 구성될 수 있으며, 장애 조치된 192.168.1.50 주소와 통신할 수 있지만, 로컬 라우팅 테이블은 기본적으로 192.168.1.0/24 서브넷과 통신하기 위해 단 하나의 주소만 사용하도록 설정됩니다. 시스템 관리자는 네트워크 연결 실패를 감지하고 로컬 라우팅 테이블을 수정하거나 인터페이스를 활성화/비활성화하는 스크립팅 프레임워크를 만들 수 있습니다. 정확한 절차는 사용 중인 운영 체제에 따라 달라집니다.

실제로 NetApp 고객은 직접 연결 NFS를 가지고 있지만 일반적으로 페일오버 중에 IO가 일시 중지되는 워크로드에만 해당됩니다. 하드 마운트를 사용하는 경우 이러한 일시 중지 중에는 입출력 오류가 발생하지 않아야 합니다. 호스트의 NIC 간에 IP 주소를 이동하는 장애 복구 또는 수동 작업으로 인해 서비스가 복구될 때까지 입출력이 중단되어야 합니다.