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

논리 인터페이스

기여자 kaminis85
PDF

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

이 섹션에서는 SAN 전용 환경에 최적화된 ASA r2 시스템의 주요 LIF 설계 원칙에 대한 개요를 제공합니다. 보다 자세한 내용은 다음을 참조하십시오. "ONTAP 네트워크 관리 설명서". 데이터베이스 아키텍처의 다른 측면과 마찬가지로 스토리지 가상 머신(SVM, CLI에서는 vserver로 알려짐) 및 논리 인터페이스(LIF) 설계에 대한 최적의 옵션은 확장성 요구 사항과 비즈니스 요구 사항에 크게 좌우됩니다.

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

  • 성능. 오라클 워크로드에 필요한 네트워크 대역폭이 충분한가요?

  • * 복구. * 설계에 단일 장애 지점이 있습니까?

  • * 관리 효율성. * 네트워크를 중단 없이 확장할 수 있습니까?

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

LIF 유형

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

  • * 클러스터 및 노드 관리 LIF. * 스토리지 클러스터 관리에 사용되는 LIF.

  • * SVM 관리 LIF. * 스냅샷 생성 또는 볼륨 리사이징 같은 기능을 위해 REST API 또는 ONTAPI(ZAPI라고도 함)를 통해 SVM에 대한 액세스를 허용하는 인터페이스. SMO(SnapManager for Oracle)와 같은 제품은 SVM 관리 LIF에 대한 액세스 권한을 가지고 있어야 합니다.

  • 데이터 LIF. SAN 프로토콜 전용 인터페이스: FC, iSCSI, NVMe/FC, NVMe/TCP. NAS 프로토콜(NFS, SMB/CIFS)은 ASA r2 시스템에서 지원되지 않습니다.

참고 iSCSI(또는 NVMe/TCP) 트래픽과 관리 트래픽 모두 IP 프로토콜을 사용함에도 불구하고, 두 트래픽 모두에 대해 인터페이스를 구성하는 것은 불가능합니다. iSCSI 또는 NVMe/TCP 환경에서는 별도의 관리용 LIF가 필요합니다. 복원력과 성능을 위해 프로토콜별, 노드별로 여러 개의 SAN 데이터 LIF를 구성하고 이를 서로 다른 물리적 포트 및 패브릭에 분산하십시오. AFF/ FAS 시스템과 달리 ASA r2는 NFS 또는 SMB 트래픽을 허용하지 않으므로 NAS 데이터 LIF를 관리용으로 재활용할 수 있는 옵션이 없습니다.

SAN LIF 설계

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

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

성능

SAN 환경에서 LIF 성능을 고려할 때 가장 중요한 요소는 대역폭입니다. 예를 들어, 노드당 32Gb FC 포트가 두 개 있는 2노드 ASA r2 클러스터는 각 노드 간 최대 64Gb의 대역폭을 허용합니다. 마찬가지로 NVMe/TCP 또는 iSCSI의 경우 Oracle 워크로드에 필요한 25GbE 또는 100GbE 연결이 충분히 확보되어야 합니다.

복원력

SAN LIF는 NAS LIF와 같은 방식으로 페일오버되지 않습니다. ASA r2 시스템은 복원력을 위해 호스트 멀티패싱(MPIO/ALUA)에 의존합니다. 컨트롤러 페일오버로 인해 SAN LIF를 사용할 수 없게 되면 클라이언트의 멀티패싱 소프트웨어는 경로 손실을 감지하고 I/O를 대체 경로로 리디렉션합니다. ASA r2는 전체 경로 가용성을 복원하기 위해 짧은 지연 후 LIF 재배치를 수행할 수 있지만, 파트너 노드에 이미 활성 경로가 존재하므로 이로 인해 I/O가 중단되지는 않습니다. 장애 조치 프로세스는 정의된 모든 포트에서 호스트 액세스를 복원하기 위해 수행됩니다.

관리 효율성

SAN 환경에서 HA 쌍 내에서 볼륨이 재배치될 경우 LIF를 마이그레이션할 필요가 없습니다. 이는 볼륨 이동이 완료된 후 ONTAP SAN에 경로 변경에 대한 알림을 보내고 SAN 클라이언트가 자동으로 재최적화되기 때문입니다. SAN을 이용한 LIF 마이그레이션은 주로 주요 물리적 하드웨어 변경과 관련이 있습니다. 예를 들어, 컨트롤러의 중단 없는 업그레이드가 필요한 경우 SAN LIF를 새 하드웨어로 마이그레이션합니다. FC 포트에 결함이 있는 것으로 확인되면 LIF를 사용되지 않는 포트로 마이그레이션할 수 있습니다.

설계 권장 사항

NetApp ASA r2 SAN 환경에 대해 다음과 같은 권장 사항을 제시합니다.

  • 필요한 수보다 많은 경로를 생성하지 마십시오. 경로 수가 너무 많으면 전체적인 관리가 더 복잡해지며 일부 호스트에서 경로 페일오버 문제가 야기될 수 있습니다. 또한, 호스트에 SAN 부팅 같은 구성과 관련하여 예기치 않은 경로 한계가 있을 수도 있습니다.

  • 극소수의 구성에서는 LUN에 대한 경로가 4개 이상 필요합니다. LUN과 그 HA 파트너가 속한 노드에 장애가 발생하는 경우 LUN을 호스팅하는 애그리게이트에 액세스할 수 없기 때문에 LUN에 3개 이상의 노드 보급 경로를 소유했을 때의 가치는 크지 않습니다. 이 상황에서 1차 HA 쌍 외에 노드에 대한 경로를 생성하는 것은 도움이 되지 않습니다.

  • FC 존에 어떤 포트를 포함할 것인지 선택하여 가시적인 LUN 경로의 수를 관리할 수 있긴 하나 일반적으로 FC 존의 모든 잠재적 타겟 지점을 포함하고 ONTAP 수준에서 LUN 가시성을 제어하는 것이 더 간편합니다.

  • 기본적으로 활성화되어 있는 선택적 LUN 매핑(SLM) 기능을 사용하십시오. SLM을 사용하면 새 LUN이 추가될 때마다 기본 애그리게이트를 소유한 노드와 해당 노드의 HA 파트너에서 자동으로 알림이 전송됩니다. 이러한 구성 방식은 포트 세트를 생성하거나 포트 접근성을 제한하기 위해 영역 설정을 구성할 필요성을 없애줍니다. 각 LUN은 최적의 성능과 복원력을 위해 필요한 최소 노드 수에서 사용할 수 있습니다.

  • LUN을 두 컨트롤러 외부로 마이그레이션해야 하는 경우, 추가 노드는 다음을 통해 추가할 수 있습니다. lun mapping add-reporting-nodes LUN이 새 노드에 광고되도록 하는 명령입니다. 이렇게 하면 LUN 마이그레이션을 위한 LUN에 대한 추가 SAN 경로가 생성됩니다. 하지만 호스트는 새로운 경로를 사용하기 위해 검색 작업을 수행해야 합니다.

  • 간접 트래픽을 너무 신경 쓰지 마십시오. 매우 I/O 집약적인 환경에서는 간접 트래픽을 피하는 것이 가장 좋으며 1마이크로초의 지연 시간도 중요하지만 일반적 워크로드의 성능에 미치는 가시적 영향은 미미합니다.