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

논리 인터페이스

11/20/2024 기여자

Oracle 데이터베이스는 스토리지에 액세스해야 합니다. 논리 인터페이스(LIF)는 SVM(스토리지 가상 머신)을 네트워크에 연결하고 데이터베이스에 연결하는 네트워크 사업부입니다. 각 데이터베이스 워크로드에 충분한 대역폭을 보장하기 위해 올바른 LIF 설계가 필요하며, 페일오버로 인해 스토리지 서비스가 손실되지 않습니다.

이 섹션은 LIF 설계의 주요 원칙에 대해 간략하게 설명합니다. 보다 포괄적인 설명서는 를 참조하십시오 "ONTAP 네트워크 관리 설명서". 데이터베이스 아키텍처의 다른 측면과 마찬가지로, 스토리지 가상 머신(SVM, CLI의 SVM) 및 논리 인터페이스(LIF) 설계를 위한 최고의 옵션은 확장 요구사항과 비즈니스 요구사항에 크게 의존합니다.

LIF 전략을 구축할 때는 다음 주요 주제를 고려해야 합니다.

* 성능. * 네트워크 대역폭은 충분한가?
* 복구. * 설계에 단일 장애 지점이 있습니까?
* 관리 효율성. * 네트워크를 중단 없이 확장할 수 있습니까?

이러한 주제는 호스트부터 스위치, 스토리지 시스템에 이르기까지 엔드 투 엔드 솔루션에 적용됩니다.

LIF 유형

LIF 유형에는 여러 가지가 있습니다. "LIF 유형에 대한 ONTAP 설명서" 이 주제에 대한 전체 정보를 제공하지만 기능적 관점에서 LIF를 다음 그룹으로 나눌 수 있습니다.

* 클러스터 및 노드 관리 LIF. * 스토리지 클러스터 관리에 사용되는 LIF.
* SVM 관리 LIF. * 스냅샷 생성 또는 볼륨 리사이징 같은 기능을 위해 REST API 또는 ONTAPI(ZAPI라고도 함)를 통해 SVM에 대한 액세스를 허용하는 인터페이스. SMO(SnapManager for Oracle)와 같은 제품은 SVM 관리 LIF에 대한 액세스 권한을 가지고 있어야 합니다.
* Data LIF. * FC, iSCSI, NVMe/FC, NVMe/TCP, NFS용 인터페이스 또는 SMB/CIFS 데이터를 생성할 수 있습니다.

NFS 트래픽에 사용되는 데이터 LIF는 의 방화벽 정책을 에서 변경하여 관리에 사용할 수도 있습니다 data 를 선택합니다 mgmt 또는 HTTP, HTTPS 또는 SSH를 허용하는 또 다른 정책입니다. 이렇게 변경할 때는 NFS 데이터 LIF와 별도의 관리 LIF 둘 다에 대한 액세스를 위해 각 호스트를 구성할 필요가 없기 때문에 네트워크 구성을 단순화할 수 있습니다. 둘 다 IP 프로토콜을 사용함에도 불구하고 iSCSI와 관리 트래픽 모두를 위한 인터페이스를 구성하는 것은 불가능하며 iSCSI 환경에는 별도의 관리 LIF가 필요합니다.

SAN LIF 설계

SAN 환경에서 LIF 설계는 상대적으로 단순합니다. 바로 다중 경로를 사용할 수 있기 때문입니다. 모든 최신 SAN 구현에서는 클라이언트가 다중 독립형 네트워크 경로를 통해 데이터에 액세스하고 액세스를 위한 최상의 경로를 선택할 수 있습니다. 그 결과, SAN 클라이언트가 최상의 경로를 통과하여 자동으로 로드 밸런싱을 수행하기 때문에 LIF 설계에서 성능을 더 간단하게 해결할 수 있습니다.

최상의 경로를 사용할 수 없게 되면 클라이언트는 자동으로 다른 경로를 선택합니다. 이러한 설계 단순성 덕분에 일반적으로 SAN LIF의 관리가 더 용이해집니다. 그렇다고 SAN 환경의 관리가 항상 더 쉬운 것은 아닙니다. SAN 스토리지의 여러 다른 측면은 NFS보다 훨씬 더 복잡하며 SAN LIF는 설계만 더 쉽습니다.

성능

SAN 환경의 LIF 성능과 관련하여 가장 중요한 고려사항은 대역폭입니다. 예를 들어, 노드당 16Gb FC 포트가 2개인 2노드 ONTAP AFF 클러스터는 각 노드에서 최대 32Gb의 대역폭을 허용합니다.

복원력

SAN LIF는 AFF 스토리지 시스템에서 페일오버되지 않습니다. 컨트롤러 페일오버로 SAN LIF에서 장애가 발생하면 클라이언트의 다중 경로 소프트웨어가 경로 손실을 탐지하고 I/O를 다른 LIF로 리디렉션합니다. ASA 스토리지 시스템을 사용할 경우 짧은 지연 후 LIF가 페일오버되지만, 다른 컨트롤러에 이미 활성 경로가 있으므로 IO가 중단되지 않습니다. 페일오버 프로세스는 정의된 모든 포트에서 호스트 액세스를 복구하기 위해 수행됩니다.

관리 효율성

LIF 마이그레이션은 클러스터 주변의 볼륨 재배치와 관련된 경우가 많기 때문에 NFS 환경에서 일반적으로 수행됩니다. SAN 환경에서는 HA 쌍 내에 볼륨을 재배치할 때 LIF를 마이그레이션할 필요가 없습니다. 볼륨 이동이 완료된 후에 경로가 변경되면 ONTAP가 SAN에 알림을 전송하고 SAN 클라이언트가 자동으로 다시 최적화하기 때문입니다. SAN의 LIF 마이그레이션은 기본적으로 주요 물리적 하드웨어 변경과 관련되어 있습니다. 예를 들어, 컨트롤러의 무중단 업그레이드가 필요한 경우 SAN LIF는 새로운 하드웨어로 마이그레이션됩니다. FC 포트에서 오류가 발견되면 LIF를 미사용 포트로 마이그레이션할 수 있습니다.

설계 권장 사항

NetApp는 다음과 같은 권장 사항을 제공합니다.

필요한 수보다 많은 경로를 생성하지 마십시오. 경로 수가 너무 많으면 전체적인 관리가 더 복잡해지며 일부 호스트에서 경로 페일오버 문제가 야기될 수 있습니다. 또한, 호스트에 SAN 부팅 같은 구성과 관련하여 예기치 않은 경로 한계가 있을 수도 있습니다.
극소수의 구성에서는 LUN에 대한 경로가 4개 이상 필요합니다. LUN과 그 HA 파트너가 속한 노드에 장애가 발생하는 경우 LUN을 호스팅하는 애그리게이트에 액세스할 수 없기 때문에 LUN에 3개 이상의 노드 보급 경로를 소유했을 때의 가치는 크지 않습니다. 이 상황에서 1차 HA 쌍 외에 노드에 대한 경로를 생성하는 것은 도움이 되지 않습니다.
FC 존에 어떤 포트를 포함할 것인지 선택하여 가시적인 LUN 경로의 수를 관리할 수 있긴 하나 일반적으로 FC 존의 모든 잠재적 타겟 지점을 포함하고 ONTAP 수준에서 LUN 가시성을 제어하는 것이 더 간편합니다.
ONTAP 8.3 이후 버전에서 선택적 LUN 매핑(SLM: Selective LUN Mapping) 기능은 기본값입니다. SLM 기능을 통해 새로운 LUN은 기본 애그리게이트와 노드의 HA 파트너가 속한 노드에서 자동으로 보급됩니다. 이러한 방식에서는 포트 세트를 생성하거나 포트 접근성을 제한하기 위해 조닝을 구성할 필요가 없습니다. 각 LUN은 최적의 성능과 복원력을 위해 필요한 최소 개수의 노드에서 동작합니다.
LUN을 2개의 컨트롤러 외부로 마이그레이션해야 하는 경우 를 사용하여 노드를 추가할 수 있습니다 lun mapping add-reporting-nodes 명령을 사용하여 LUN을 새 노드에서 보급합니다. 이렇게 하면 LUN 마이그레이션을 위해 LUN에 대한 추가 SAN 경로를 생성할 수 있습니다. 그러나 호스트는 새로운 경로를 사용하기 위한 검색 작업을 수행해야 합니다.
간접 트래픽을 너무 신경 쓰지 마십시오. 매우 I/O 집약적인 환경에서는 간접 트래픽을 피하는 것이 가장 좋으며 1마이크로초의 지연 시간도 중요하지만 일반적 워크로드의 성능에 미치는 가시적 영향은 미미합니다.

NFS LIF 설계

SAN 프로토콜과 대조적으로 NFS는 데이터에 대한 다중 경로를 정의하는 기능이 제한적입니다. NFSv4에 대한 병렬 NFS(pNFS) 확장이 이 한계를 해결해주긴 하나, 이더넷 속도가 100GB에 도달했기 때문에 추가 경로를 추가할 가치가 거의 없습니다.

성능 및 복원력

SAN LIF 성능을 측정할 때는 기본적으로 모든 1차 경로의 총 대역폭을 계산하는 것이 관건이지만 NFS LIF 성능을 결정하기 위해서는 정확한 네트워크 구성을 면밀히 살펴야 합니다. 예를 들어, 2개의 10Gb 포트를 원시 물리적 포트로 구성하거나 링크 통합 제어 프로토콜(LACP) 인터페이스 그룹으로 구성할 수 있습니다. 이를 인터페이스 그룹으로 구성하는 경우, 트래픽이 스위칭될 때와 라우팅될 때 각각 다르게 작동하는 다중 로드 밸런싱 정책을 사용할 수 있습니다. 마지막으로, Oracle dNFS(Direct NFS)는 현재 어떤 OS NFS 클라이언트에도 존재하지 않는 로드 밸런싱 구성을 제공합니다.

SAN 프로토콜과 달리 NFS 파일 시스템은 프로토콜 계층의 복원력이 필요합니다. 예를 들어, LUN은 항상 다중 경로가 활성화되어 구성되므로 스토리지 시스템에 다중 이중화 채널이 제공되고 각각 FC 프로토콜을 사용하게 됩니다. 반면, NFS 파일 시스템은 물리적 계층에서만 보호되는 단일 TCP/IP 채널의 가용성에 따라 달라집니다. 포트 페일오버와 LACP 포트 애그리게이션 같은 옵션은 이 방식 때문에 존재하는 것입니다.

NFS 환경에서는 네트워크 프로토콜 계층에서 성능과 복원력 둘 다 제공되기 때문에 두 주제가 긴밀히 연관되어 있으며 함께 논의되어야 합니다.

포트 그룹에 LIF를 바인딩합니다

LIF를 포트 그룹에 바인딩하려면 LIF IP 주소를 물리적 포트 그룹에 연계합니다. 물리적 포트를 함께 애그리게이팅하는 주된 방법은 LACP입니다. LACP의 내결함성 기능은 상당히 단순한데, LACP 그룹의 각 포트를 모니터링하고 오작동이 발생하면 포트 그룹에서 제거하는 것입니다. 그러나 LACP의 성능과 관련하여 다음과 같이 많은 오해가 있습니다.

LACP는 엔드포인트 매칭을 위해 스위치를 구성하지 않아도 됩니다. 예를 들어, ONTAP는 IP 기반 부하 분산을 사용하여 구성할 수 있고 스위치는 MAC 기반 부하 분산을 사용할 수 있습니다.
LACP 연결을 사용하는 각 엔드포인트는 패킷 전송 포트를 독립적으로 선택할 수 있지만 수신에 사용할 포트는 선택할 수 없습니다. 즉, ONTAP에서 특정 대상으로 가는 트래픽이 특정 포트에 연관되어 있고 반환 트래픽은 다른 인터페이스에 도착할 수 있습니다. 하지만 이로 인해 문제가 발생하지는 않습니다.
LACP가 트래픽을 언제나 균등하게 분산하지는 않습니다. 다수의 NFS 클라이언트가 있는 대규모 환경에서는 일반적으로 LACP 애그리게이션의 모든 포트가 균등하게 사용됩니다. 그러나 이 환경에서 모든 NFS 파일 시스템은 전체 애그리게이션이 아닌 단 1포트의 대역폭으로 제한됩니다.
ONTAP에서 라운드 로빈 LACP 정책을 사용할 수 있지만 이들 정책은 스위치에서 호스트로의 연결을 다루지 않습니다. 예를 들어, 한 호스트에 4포트 LACP 트렁크가 있고 ONTAP에 4포트 LACP 트렁크가 있는 구성에서는 단일 포트를 사용하여 파일 시스템을 읽을 수만 있습니다. ONTAP는 4포트 모두를 통해 데이터를 전송할 수 있지만 현재 4포트 모두를 통해 스위치에서 호스트로 전송하는 데 사용할 수 있는 스위치 기술은 없으며 하나만 사용됩니다.

여러 데이터베이스 호스트로 구성된 대규모 환경에서 가장 일반적인 접근 방식은 IP 로드 밸런싱을 사용하여 적절한 수의 10Gb(또는 더 빠른) 인터페이스 LACP 애그리게이트를 구축하는 것입니다. 이 접근 방식에서는 클라이언트 수가 충분하다면 ONTAP에서 모든 포트를 사용할 수 있습니다. 구성에 있는 클라이언트 수가 더 적을 때는 LACP 트렁킹이 로드를 동적으로 재분산하지 않으므로 로드 밸런싱이 중단됩니다.

연결이 확립되면 특정 방향의 트래픽이 하나의 포트에만 배치됩니다. 예를 들어, 4포트 LACP 트렁크로 연결된 NFS 파일 시스템에 대해 전체 테이블 스캔을 수행하는 데이터베이스는 네트워크 인터페이스 카드(NIC)가 하나에 불과하지만 데이터를 읽습니다. 이러한 환경에 단 3개의 데이터베이스 서버가 있는 경우 3개 서버 모두 같은 포트에서 데이터를 읽을 가능성도 있으며 다른 3개의 포트는 유휴 상태입니다.

LIF를 물리적 포트에 바인딩합니다

LIF를 물리적 포트에 바인딩하면 ONTAP 시스템의 특정 IP 주소가 한 번에 하나의 네트워크 포트에만 연계되기 때문에 네트워크 구성을 더 세부적으로 제어할 수 있습니다. 이렇게 하고 나면 페일오버 그룹 구성과 페일오버 정책을 통해 복원력을 실현할 수 있습니다.

페일오버 정책 및 페일오버 그룹

네트워크가 중단되었을 때 LIF의 동작은 페일오버 정책과 페일오버 그룹에 의해 제어됩니다. 구성 옵션은 ONTAP의 다른 버전에 따라 변경되었습니다. 을 참조하십시오 "페일오버 그룹 및 정책에 대한 ONTAP 네트워크 관리 설명서" 구축하고 있는 ONTAP 버전에 대한 세부 정보를 참조하십시오.

ONTAP 8.3 이상에서는 브로드캐스트 도메인 기반의 LIF 페일오버 관리를 허용합니다. 그러므로 관리자는 특정 서브넷에 대한 액세스 권한을 가진 모든 포트를 정의하여 ONTAP이 적절한 페일오버 LIF를 선택하도록 할 수 있습니다. 어떤 고객은 이 접근 방식을 사용할 수 있지만 예측 가능성이 부족하기 때문에 고속 스토리지 네트워크 환경에서는 한계가 있습니다. 예를 들어, 일반적인 파일 시스템 액세스를 위한 1Gb 포트와 데이터 파일 I/O를 위한 10Gb 포트 모두를 환경에 포함할 수 있습니다 두 유형의 포트가 같은 브로드캐스트 도메인에 존재하는 경우 LIF 페일오버는 데이터 파일 I/O를 10Gb 포트에서 1Gb 포트로 이동할 수 있습니다.

요약하자면, 다음과 같은 방식을 사용해 보십시오.

사용자 정의대로 페일오버 그룹을 구성합니다.
스토리지 페일오버 중에 LIF가 애그리게이트를 따르도록 스토리지 페일오버(SFO) 파트너 컨트롤러의 포트로 페일오버 그룹을 채웁니다. 그러면 간접 트래픽의 생성을 방지할 수 있습니다.
성능 특성이 원래의 LIF와 일치하는 페일오버 포트를 사용합니다. 예를 들어, 하나의 물리적 10Gb 포트에 있는 LIF에는 단일 10Gb 포트의 페일오버 그룹이 포함되어야 합니다. 4포트 LACP LIF는 다른 4포트 LACP LIF로 페일오버해야 합니다. 이들 포트는 브로드캐스트 도메인에서 정의된 포트의 하위 세트가 될 것입니다.
SFO 파트너에 관한 페일오버 정책을 수립합니다. 이렇게 하면 페일오버 중에 LIF가 애그리게이트를 따르도록 할 수 있습니다.

자동 되돌리기

를 설정합니다 auto-revert 원하는 대로 매개 변수입니다. 대부분의 고객은 이 매개 변수를 로 설정하는 것을 선호합니다 true LIF가 홈 포트로 되돌아갑니다. 그러나 경우에 따라 LIF를 홈 포트에 반환하기 전에 예기치 않은 페일오버를 조사할 수 있다는 사실이 이를 false로 설정한 경우도 있습니다.

LIF-볼륨 비율

일반적인 오해는 볼륨과 NFS LIF 사이에 1:1 관계가 있어야 한다는 것입니다. 이 구성은 인터커넥트 트래픽을 추가로 생성하지 않고 클러스터의 어느 곳으로든 볼륨을 이동하기 위해 필요하기는 하나 절대적인 요구사항은 아닙니다. 인터클러스터 트래픽을 고려해야 하지만 단순히 인터클러스터 트래픽이 존재하는 것만으로 문제가 발생하지는 않습니다. ONTAP를 위해 수립되고 발표된 대다수의 벤치마크에는 대개 간접 I/O가 포함되어 있습니다

예를 들어, 성능이 중요한 데이터베이스가 상대적으로 적게 포함된 데이터베이스 프로젝트에서 LIF 전략에 대한 1:1 볼륨을 보장하기 위해 총 40개의 볼륨만 필요하다면 IP 주소는 40개가 필요합니다. 어떤 볼륨이든 연계된 LIF와 함께 클러스터 내 어느 곳으로든 이동할 수 있으며 트래픽이 항상 직접적이기 때문에 마이크로초 수준에서도 지연 시간의 소스를 모두 최소화합니다.

반대의 예를 들어 보면, 대규모 호스팅 환경은 고객과 LIF 간 1:1 관계를 더 쉽게 관리할 수 있습니다. 시간이 경과하면 볼륨을 다른 노드로 마이그레이션해야 할 수 있으며 이로 인해 간접 트래픽이 발생할 수 있습니다. 하지만 인터커넥트 스위치의 네트워크 포트가 포화 상태가 되지 않는 한 성능 영향을 감지할 수 없습니다. 우려가 된다면 새로운 LIF를 추가 노드에 설정할 수 있으며 다음 유지보수 윈도우에 호스트를 업데이트하여 구성에서 간접 트래픽을 제거할 수 있습니다.