1. OCI에서의 네트워크 배포에 대해 알아보기
  2. 네트워크 설계에 대해 알아보기

네트워크 디자인에 대해 알아보기

기본 매개변수를 사용하여 적절한 계획을 수립하지 않고 구축된 OCI 네트워크 인프라 구성요소(예: VCN, 서브넷 및 게이트웨이)는 배포 후 문제가 발생하여 해결하기 어려울 수 있습니다. 잘 계획된 네트워크 설계는 성공적인 구현을 설정하고 팀과 조직이 쉽게 사용할 수 있도록 도와줍니다.

네트워크 설계를 조기에 수행

배포 전에 네트워크를 완전히 설계하면 문제를 조기에 파악하고 성공적인 배포에 대한 장벽을 제거할 수 있습니다. 일부 OCI 네트워크 설계 요소는 나중에 변경할 수 있지만 상당한 노력이 필요할 수 있으며 비즈니스 흐름을 일시적으로 방해할 수 있습니다.

Oracle은 OCI 네트워크 설계에 다음 사항을 권장합니다.

  1. 적절한 시간을 계획하고 프로젝트 계획에 충분한 리소스를 할당하여 OCI 네트워크를 적절하게 설계하십시오.
  2. 레이아웃, 토폴로지, VCN 및 서브넷의 크기 조정, DNS(Domain Name Service) 및 온프레미스 또는 기타 CSP에 대한 외부 네트워크 연결을 최소로 포함합니다.
  3. Oracle 계정 팀과 협력하여 Oracle이 OCI 네트워킹 전문가가 귀하를 지원할 수 있는지 확인해 보십시오.

다음은 네트워크 설계 다이어그램의 예입니다.


다음은 vcn-network-design-example.png에 대한 설명입니다.
그림 vcn-network-design-example.png에 대한 설명

참고:

시작점으로 사용할 특정 배치에 대한 관련 참조 구조를 검색합니다. For example, Oracle has many reference architectures for common Oracle OCI deployments such as Oracle E-Business Suite, Siebel, and ExaCS on the Oracle Architecture Center.

허브 앤 스포크 VCN 설계 고려

대부분의 OCI 배포에 대한 Oracle의 모범 사례 및 권장 사항은 연결을 위해 DRG를 활용하는 허브-스포크 토폴로지에서 다중 VCN 설계를 사용하는 것입니다.

다음은 DRG를 사용한 다중 VCN 허브 앤 스포크 설계의 이점입니다.

  • 서로 다른 환경을 격리하고 세분화합니다.
  • 허브 VCN 내에 로그 서버, DNS, 파일 공유 등 모든 스포크 VCN이 공유할 수 있는 공통 서비스를 제공합니다.
  • DRG를 통해 최대 300개의 VCN을 연결할 수 있으므로 네트워킹을 쉽게 확장할 수 있습니다. 허브-스포크 VCN이 설계되면 추가 VCN을 쉽게 추가할 수 있습니다.
  • 허브 VCN에 방화벽과 같은 네트워크 보안 어플라이언스를 배치하여 스포크 VCN으로 이동되거나 소싱된 트래픽을 검사합니다.

다음 다이어그램은 허브-스포크 네트워크 아키텍처를 사용하는 예를 보여줍니다.


다음은 hub-and-spoke-topology.png에 대한 설명입니다.
그림 hub-and-spoke-topology.png에 대한 설명

Oracle은 다음 사항을 권장합니다.

  • 서로 다른 네트워크 환경을 세그먼트화하는 방법과 위치를 결정하고 각각을 자체 VCN에 넣는 것을 고려합니다. 다음은 환경에 별도의 VCN을 사용하는 일반적인 고객 예입니다.
    • 운용 및 비운용 환경
    • 내부 또는 외부 고객
  • POC(Proof of Concept)와 같이 매우 간단하거나 작은 OCI 배포를 사용하고 여기에 설명된 이점이 필요하지 않은 경우 단일 VCN을 사용하는 것이 좋습니다. 단일 VCN을 사용하는 경우에도 향후 다른 VCN에 환경을 배치하여 이러한 권장사항을 활용할 수 있습니다.

표준 OCI 이름 지정 규칙 사용

CN, 서브넷, 보안 목록 및 DRG(동적 경로 지정 게이트웨이)와 같은 OCI에서 필요한 네트워크 리소스를 프로비전할 때 리소스 이름을 입력하라는 메시지가 표시됩니다. OCI 리소스에 대해 표준 이름 지정 규칙을 사용하면 사용자와 다른 OCI 사용자가 리소스의 목적과 위치를 이해하고 리소스가 다른 사용자와 어떻게 차별화되는지 알 수 있습니다.

이러한 리소스 이름 중 일부는 나중에 변경할 수 있지만 일부는 DNS 레이블과 같이 변경할 수 없습니다. VCN과 같은 다른 이름은 CLI(명령줄 인터페이스)를 사용하여 변경해야 합니다.

Oracle은 다음 사항을 권장합니다.

  1. 이름의 어딘가에 설명적인 약어를 사용하여 리소스의 목적을 설명합니다. 예:
    • vcn VCN 이름의 어딘가(VCN 이름: vcn-prod-ashburn)
    • drg DRG 이름의 어딘가(DRG 이름: drg-ashburn)
    • sl 보안 목록 이름 어딘가(보안 목록 이름: web-sn-sl)
  2. OCI 네트워크 리소스 이름 지정 규칙이 전체 OCI 리소스 이름 지정 규칙의 일부인지 확인합니다.
  3. 태그를 사용하여 리소스에 메타데이터 정보를 추가하는 것이 좋습니다.

OCI 프라이빗 DNS를 사용하여 하이브리드 DNS 설계

OCI의 기본 동작은 oraclevcn.com를 기본 도메인으로 사용하여 VCN에 대한 내부 DNS 확인을 수행하도록 제한됩니다. 이로 인해 다른 VCN 또는 온프레미스 환경의 리소스에 대한 DNS 이름을 확인할 수 없으므로 나중에 연결 문제가 발생할 수 있습니다.

OCI 프라이빗 DNS 서비스는 OCI와 온프레미스 인프라 간 DNS를 원활하게 해결할 수 있는 기능을 제공합니다.

  • VCN 내에서 커스터마이징 DNS 도메인 및 레코드를 생성하고 유지 관리합니다(예: oci.customer.com).
  • 온프레미스 DNS 및 CSP 또는 신뢰할 수 있는 파트너 DNS와 같은 기타 환경과 함께 VCN 간 DNS 확인을 통합합니다.

Oracle은 다음 사항을 권장합니다.

  • 초기 네트워크 설계의 일부로 DNS를 포함하고 DNS 관리자를 참여시킵니다.
  • 온프레미스 환경, OCI VCN, 기타 CSP 등에 대한 원활한 DNS 이름 확인을 원하는 모든 환경을 고려하고 OCI 전용 DNS를 사용하여 하이브리드 DNS 솔루션을 활성화하십시오.
  • 조기에 주의 사항을 고려하고 진행할 방향을 결정합니다. 기본 oraclevcn.com 도메인 이름 또는 사용자정의 도메인 이름을 사용할지 여부를 결정합니다.

다음 다이어그램은 사용자정의 도메인 이름이 있는 로컬 내부 리소스를 확인하기 위해 전용 DNS 분석기를 사용하는 사용자정의 도메인 이름이 있는 예제 아키텍처를 보여줍니다.

다음은 architecture-deploy-private-dns.png에 대한 설명입니다.
그림 architecture-deploy-private-dns.png에 대한 설명

참고:

사용자정의 OCI 도메인 이름을 사용하는 경우 사용자정의 영역 및 레코드 관리는 수동으로 수행됩니다. 기본 oraclevcn.com는 자동으로 설정됩니다.

프로비전 전 서브넷 유형 결정

리소스를 구성하려면 VCN CIDR을 하나 이상의 서브넷으로 분할해야 합니다. 서브넷은 지역별 또는 AD(가용성 도메인)별 서브넷일 수 있으며 공용 또는 전용 서브넷일 수도 있습니다.

지역별 서브넷과 AD별 서브넷에 대한 결정은 나중에 변경할 수 없습니다. 이후 단계에서 중단 및 복잡성을 최소화하기 위해 처음에 프로비저닝할 때 올바른지 확인합니다.

Oracle은 다음 사항을 권장합니다.

  • 공용 또는 전용 서브넷을 생성하기 전에 해당 서브넷이 필요한지 확인합니다. 잠재적인 트래픽 흐름과 트래픽이 소싱되거나 전송되는 위치를 고려합니다.
  • 인바운드 인터넷 연결에 대한 특정 요구 사항이 있는 리소스를 공용 서브넷 및 기타 모든 리소스를 전용 서브넷에 배치합니다.
  • AD 특정 서브넷을 사용해야 하는 특정 요구 사항이 없는 경우 지역별 서브넷을 프로비저닝합니다.

참고:

나중에 변경하려면 서브넷을 종료한 다음 다시 프로비저닝해야 합니다. 서브넷에 배포된 리소스를 종료한 다음 새 서브넷에서 리소스를 다시 프로비저닝해야 합니다.

서브넷 설계 및 크기 조정

현재 및 미래의 요구 사항을 모두 충족하도록 서브넷을 설계하고 크기를 조정합니다. 설계 중에 VCN 및 서브넷의 크기를 적절하게 조정하면 다음과 같은 이점을 얻을 수 있습니다.

  • 미래의 성장과 확장을 위한 준비
  • 요약 가능한 연속 IP 주소 지정 공간을 사용하여 IP 할당 간소화

Oracle은 다음 사항을 권장합니다.

  • VCN을 생성하기 전에 VCN에 배치할 리소스 및 서브넷 수를 기준으로 필요한 CIDR 블록 수와 각 블록의 크기를 결정합니다.
  • 서브넷 및 VCN 내에서 향후 어느 정도의 성장을 허용해야 합니다.
  • 너무 작은 것보다 더 큰 CIDR을 만드는 것이 좋습니다.
  • VCN에 CIDR을 5개까지 추가할 수 있지만, 성장을 수용하기 위해 나중에 더 추가하면 IP 주소 할당에 따라 연속되지 않는 CIDR이 발생할 수 있습니다.
    • 예를 들어, 작업 로드 테스트를 시작하기 위해 VCN에 10.0.0.0/24을 할당했습니다. 테스트를 성공한 후 워크로드를 더 많은 VM으로 확장하려면 더 많은 IP와 서브넷이 필요합니다. 그러나 다른 목적으로 IP 주소 도구에 다음 IP 블록 10.0.1.0/24이 할당되었습니다. 따라서 연속되지 않는 CIDR을 VCN에 추가해야 합니다.
  • 가능한 경우 표준 RFC 1918 전용 IP 주소 공간 내에 있는 CIDR 블록을 사용합니다.
  • 169.254.0.0/16 IP 주소 공간을 사용하지 마십시오. Oracle을 비롯한 많은 공급자는 네트워크에서 동일한 IP 공간을 사용하므로 문제가 발생할 수 있습니다.
  • 다른 네트워크(OCI, 온프레미스 데이터 센터 또는 다른 CSP)와 겹치지 않는 고유한 CIDR 블록을 선택합니다.
  • 서브넷을 설계할 때 트래픽 흐름 및 보안 요구 사항을 고려합니다. 특정 계층 또는 역할 내의 모든 리소스를 동일한 서브넷에 연결합니다.

각 서브넷에 대한 사용자정의 경로 테이블 및 보안 목록 사용

서브넷을 프로비저닝할 때 각 서브넷에 사용할 VCN 라우트 테이블과 보안 목록을 선택하라는 메시지가 표시됩니다.

OCI는 기본 경로 테이블 및 기본 보안 목록을 제공합니다. 이 목록은 사용될 경우 연관된 모든 서브넷과 공유됩니다. 이러한 옵션에 대한 기본 옵션은 간단한 배치에 사용하거나 시작하기에는 좋지만 여러 서브넷을 포함하는 운용 설계에는 권장되지 않습니다. 각 서브넷과 관련된 VCN 라우트 테이블 및 보안 목록을 사용하면 이러한 리소스를 공유하는 대신 개별 서브넷에 대한 세부적인 라우팅 및 보안 제어를 유지할 수 있습니다.

예:

  • 전용 서브넷에 NAT 게이트웨이에 대한 기본 경로가 있고 공용 서브넷에 인터넷 게이트웨이에 대한 기본 경로가 있어 별도의 VCN 경로 테이블이 필요할 수 있습니다.
  • 특정 트래픽 플로우를 한 서브넷으로 허용할 수도 있지만 별도의 보안 목록을 사용해야 하는 다른 서브넷은 허용하지 않을 수 있습니다.

Oracle은 다음 사항을 권장합니다.

  • 각 서브넷에 대해 고유한 VCN 라우트 테이블 생성 및 연결
  • 각 서브넷에 대해 고유한 보안 목록 생성 및 연결

참고:

서브넷을 프로비저닝하면 나중에 기본 라우팅 테이블과 보안 목록을 변경하기가 더 어려워지므로 고유한 VCN 라우팅 테이블과 보안 목록을 생성하여 연결합니다.