네트워크 구성
변경 제안
PDF
ONTAP를 실행하는 시스템에서 vSphere를 사용할 때 네트워크 설정을 구성하는 것은 다른 네트워크 구성과 매우 간단하며 비슷합니다.
다음은 고려해야 할 몇 가지 사항입니다.
-
스토리지 네트워크 트래픽을 다른 네트워크와 분리합니다. 전용 VLAN 또는 스토리지에 개별 스위치를 사용하면 별도의 네트워크를 구축할 수 있습니다. 스토리지 네트워크가 업링크와 같은 물리적 경로를 공유하는 경우 충분한 대역폭을 확보하기 위해 QoS 또는 추가 업링크 포트가 필요할 수 있습니다. 솔루션 가이드에서 특별히 요구하지 않는 한 호스트를 스토리지에 직접 연결하지 마십시오. 스위치를 사용하여 중복 경로를 확보하고 VMware HA가 개입 없이 작동할 수 있습니다.
-
네트워크에서 지원하는 경우 점보 프레임을 사용해야 합니다. 사용하는 경우 스토리지와 ESXi 호스트 간 경로에서 모든 네트워크 디바이스, VLAN 등에 동일하게 구성되었는지 확인합니다. 그렇지 않으면 성능 또는 연결 문제가 나타날 수 있습니다. MTU는 ESXi 가상 스위치, VMkernel 포트 및 각 ONTAP 노드의 물리적 포트 또는 인터페이스 그룹에서도 동일하게 설정되어야 합니다.
-
NetApp은 ONTAP 클러스터 내 클러스터 인터커넥트 포트에서 네트워크 흐름 제어를 사용하지 않도록 설정하는 것만 권장합니다. NetApp는 데이터 트래픽에 사용되는 나머지 네트워크 포트의 흐름 제어와 관련된 모범 사례에 대한 다른 권장 사항은 없습니다. 필요에 따라 활성화 또는 비활성화해야 합니다. 흐름 제어에 대한 자세한 내용은 을 "TR-4182 를 참조하십시오" 참조하십시오.
-
ESXi 및 ONTAP 스토리지 어레이가 이더넷 스토리지 네트워크에 연결되어 있는 경우, 이러한 시스템이 RSTP(Rapid Spanning Tree Protocol) 에지 포트로 연결되거나 Cisco PortFast 기능을 사용하여 연결되는 이더넷 포트를 구성하는 것이 좋습니다. Cisco PortFast 기능을 사용하고 ESXi 서버 또는 ONTAP 스토리지 어레이에 802.1Q VLAN 트렁킹을 사용하는 환경에서는 스패닝 트리 포트패스트 트렁크 기능을 활성화하는 것이 좋습니다.
-
Link Aggregation에 대해 다음 모범 사례를 따르는 것이 좋습니다.
-
Cisco vPC(Virtual PortChannel)와 같은 다중 섀시 링크 통합 그룹 접근 방식을 사용하여 두 개의 별도 스위치 섀시에 있는 포트의 링크 집계를 지원하는 스위치를 사용합니다.
-
LACP가 구성된 dvSwitch 5.1 이상을 사용하지 않는 한 ESXi에 연결된 스위치 포트에 대해 LACP를 사용하지 않도록 설정합니다.
-
LACP를 사용하여 IP 해시를 사용하는 동적 멀티모드 인터페이스 그룹을 통해 ONTAP 스토리지 시스템에 대한 링크 애그리게이트를 생성합니다.
-
ESXi에서 IP 해시 팀 구성 정책을 사용합니다.
-
다음 표에는 네트워크 구성 항목에 대한 요약과 설정이 적용되는 위치가 나와 있습니다.
| 항목 | ESXi | 스위치 | 노드 | SVM |
|---|---|---|---|---|
IP 주소입니다 |
VMkernel |
아니요** |
아니요** |
예 |
Link Aggregation |
가상 스위치 |
예 |
예 |
아니요 * |
VLAN |
VMkernel 및 VM 포트 그룹 |
예 |
예 |
아니요 * |
흐름 제어 |
NIC |
예 |
예 |
아니요 * |
스패닝 트리 |
아니요 |
예 |
아니요 |
아니요 |
MTU(점보 프레임의 경우) |
가상 스위치 및 VMkernel 포트(9000) |
예(최대로 설정) |
예(9000) |
아니요 * |
페일오버 그룹 |
아니요 |
아니요 |
예(생성) |
예(선택) |
-
SVM LIF는 VLAN, MTU 및 기타 설정이 있는 포트, 인터페이스 그룹 또는 VLAN 인터페이스에 연결됩니다. 하지만 SVM 레벨에서 설정을 관리하지 않습니다.
-
이러한 디바이스에는 자체 관리 IP 주소가 있지만 이러한 주소는 ESXi 스토리지 네트워킹의 맥락에서 사용되지 않습니다.
-
SAN(FC, NVMe/FC, iSCSI, NVMe/TCP), RDM
ONTAP은 기존 iSCSI 및 파이버 채널 프로토콜(FCP)을 사용하는 VMware vSphere용 엔터프라이즈급 블록 스토리지와 매우 효율적이고 성능이 우수한 차세대 블록 프로토콜, NVMe-oF(NVMe over Fabrics)를 제공하며 NVMe/FC 및 NVMe/TCP를 모두 지원합니다.
vSphere 및 ONTAP를 사용하여 VM 스토리지에 블록 프로토콜을 구현하는 Best Practice는 를 참조하십시오 "데이터 저장소 및 프로토콜 - SAN"
NFS 를 참조하십시오
vSphere를 사용하면 엔터프라이즈급 NFS 스토리지를 사용하여 ESXi 클러스터의 모든 노드에 대한 데이터 저장소에 대한 동시 액세스를 제공할 수 있습니다. 섹션에서 언급한 것처럼 "데이터 저장소"vSphere와 함께 NFS를 사용할 경우 사용 편의성 및 스토리지 효율성 가시성의 이점을 얻을 수 있습니다.
권장되는 모범 사례는 를 참조하십시오 "데이터 저장소 및 프로토콜 - NFS"
직접 연결 네트워킹
스토리지 관리자는 구성에서 네트워크 스위치를 제거하여 인프라를 단순화하기를 원할 수도 있습니다. 일부 시나리오에서는 이 기능이 지원될 수 있습니다. 하지만 몇 가지 제한 사항과 주의사항이 있습니다.
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를 19로 구성할 수 있습니다 2.168.1.2 및 은 192.168.1.50을 통해 실패한 주소와 통신할 수 있지만, 로컬 라우팅 테이블은 기본적으로 192.168.1.0/24 서브넷과 통신하는 데 하나의 * 및 하나의 * 주소만 사용합니다. sysadmin은 실패한 네트워크 연결을 감지하고 로컬 라우팅 테이블을 변경하거나 인터페이스를 가동 및 중지시키는 스크립팅 프레임워크를 생성할 수 있습니다. 정확한 절차는 사용 중인 운영 체제에 따라 다릅니다.
실제로 NetApp 고객은 직접 연결 NFS를 가지고 있지만 일반적으로 페일오버 중에 IO가 일시 중지되는 워크로드에만 해당됩니다. 하드 마운트를 사용하는 경우 이러한 일시 중지 중에는 입출력 오류가 발생하지 않아야 합니다. 호스트의 NIC 간에 IP 주소를 이동하기 위해 페일백이나 수동 작업으로 인해 서비스가 복구될 때까지 입출력이 중지되어야 합니다.
FC 직접 연결
호스트를 FC 프로토콜을 사용하여 ONTAP 스토리지 시스템에 직접 연결할 수는 없습니다. NPIV를 사용하기 때문입니다. FC 네트워크에 대한 ONTAP FC 포트를 식별하는 WWN은 NPIV라는 가상화 유형을 사용합니다. ONTAP 시스템에 연결된 모든 디바이스가 NPIV WWN을 인식할 수 있어야 합니다. 현재 NPIV 타겟을 지원할 수 있는 호스트에 설치할 수 있는 HBA를 제공하는 HBA 공급업체는 없습니다.