프로젝트는 단일 NSX 배포의 테넌트 간에 네트워킹 및 보안 구성을 분리하는 데 도움이 됩니다.
사전 요구 사항
엔터프라이즈 관리자 역할이 할당되어야 합니다.
프로시저
- 브라우저의 https://nsx-manager-ip-address에서 NSX Manager에 로그인합니다.
- 기본값 및 관리를 차례로 클릭합니다.
- 프로젝트 추가를 클릭합니다.
- (필수 사항) 프로젝트의 이름을 입력합니다.
- 이 프로젝트의 워크로드는 NSX 외부의 물리적 네트워크와의 북-남 연결에 사용할 수 있는 Tier-0 또는 Tier-0 VRF 게이트웨이를 선택합니다.
필요한 경우 여러 게이트웨이를 선택할 수 있습니다. 게이트웨이를 선택하지 않으면 프로젝트의 워크로드에 North-South 연결이 없습니다.
참고: 기본적으로 프로젝트는 시스템의 기본 오버레이 전송 영역에 생성됩니다. 따라서 기본 전송 영역과 연결된 Tier-0/VRF 게이트웨이가 드롭다운 메뉴에 표시됩니다.Tier-0 또는 Tier-0 VRF 게이트웨이를 여러 프로젝트에 할당할 수 있습니다. 즉, Tier-0/VRF 게이트웨이를 하나의 프로젝트(예: 프로젝트 1)에 할당해도 다른 프로젝트(예: 프로젝트 2 및 프로젝트 3)에 할당하는 것이 방지되지 않습니다.
- 이 프로젝트와 연결할 Edge 클러스터를 선택합니다.
선택한 Edge 클러스터는 나중에 프로젝트 내에서 사용할 수 있습니다. 예를 들어, Edge 클러스터는 프로젝트 내 Tier-1 게이트웨이에 구성한 NAT, 게이트웨이 방화벽, DHCP 등과 같은 중앙 집중식 서비스 실행에 사용할 수 있습니다. 프로젝트에서 NSX VPC를 추가하면 VPC의 워크로드에 중앙 집중식 서비스를 제공하기 위해 동일한 Edge 클러스터가 사용됩니다.
프로젝트는 프로젝트에 할당된 Tier-0/Tier-0 VRF 게이트웨이에서 사용되는 동일한 Edge 클러스터와 연결될 수 있습니다. 필요한 경우 별도의 Edge 클러스터를 프로젝트 및 Tier-0/Tier-0 VRF 게이트웨이에 연결할 수 있습니다. Edge 클러스터를 여러 프로젝트에 할당할 수 있습니다. 즉, Edge 클러스터를 하나의 프로젝트(예: 프로젝트 1)에 할당해도 다른 프로젝트(예: 프로젝트 2 및 프로젝트 3)에 할당하는 것이 방지되지 않습니다.
참고: 기본 오버레이 전송 영역과 연결된 Edge 클러스터가 드롭다운 메뉴에 표시됩니다. - 외부 IPv4 블록 필드에서 하나 이상의 기존 IPv4 블록을 선택합니다.
선택한 IPv4 블록은 프로젝트 내의 NSX VPC에 공용 서브넷을 추가할 때 사용할 수 있게 됩니다. 시스템은 이러한 외부 IPv4 블록에서 NSX VPC의 공용 서브넷에 CIDR 블록을 할당합니다. VPC 사용자는 NSX VPC에서 NAT 규칙을 추가하기 위한 외부 IP 블록도 사용할 수 있습니다.
선택할 수 있는 IPv4 블록이 없으면
를 클릭한 다음, 새로 생성을 클릭하여 IP 주소 블록을 추가합니다.외부 IPv4 블록은 프로젝트 내에서 서로 겹치지 않아야 하며 동일한 Tier-0 게이트웨이에서 겹치지 않아야 합니다.
예를 들어 프로젝트 A가 Tier-0 게이트웨이 A에 연결되어 있고 프로젝트 B가 Tier-0 게이트웨이 B에 연결되어 있고 이러한 이 두 프로젝트의 Tier-0 게이트웨이가 격리되어 있다고 가정해 보겠습니다. 이 경우 프로젝트 A와 B는 별도의 Tier-0 게이트웨이에 연결되어 있으므로 동일하거나 겹치는 외부 IP 블록을 사용할 수 있습니다.
- 짧은 로그 식별자 텍스트 상자에 시스템이 이 프로젝트의 컨텍스트에서 생성된 로그를 식별하는 데 사용할 수 있는 문자열을 입력합니다.
짧은 로그 식별자가 보안 로그 및 감사 로그에 적용됩니다.
project API에서 dedicated_resources 매개 변수를 구성하여 Tier-0/VRF 게이트웨이를 프로젝트에 전용으로 지정한 경우 Tier-0/VRF 게이트웨이에서 실행되는 중앙 집중식 서비스의 Edge syslog에서 생성된 로그 메시지에 짧은 로그 식별자가 추가됩니다. 자세한 내용은 NSX Edge Syslog에서 프로젝트 컨텍스트 사용 항목을 참조하십시오.
이 식별자는 NSX 환경의 모든 프로젝트에서 고유해야 합니다.
이 식별자는 영숫자 8자를 초과할 수 없습니다. 이 식별자를 지정하지 않으면 프로젝트를 저장할 때 시스템에서 자동으로 생성됩니다. 식별자가 설정된 후에는 수정할 수 없습니다.
- 기본 분산 방화벽 규칙 활성화 토글을 사용하여 이 프로젝트에 대한 기본 분산 방화벽 규칙을 설정하거나 해제합니다.
기본 DFW 규칙은 DHCP 서버와의 통신을 포함하여 프로젝트 내 워크로드 VM 간의 통신을 허용합니다. 다른 모든 통신이 차단됩니다.
이 토글은 시스템에 분산 방화벽 보안 기능에 대한 사용 권한을 부여하는 적절한 보안 라이센스를 NSX 배포에 적용하는 경우에만 편집할 수 있습니다. 이 설정은 프로젝트에 대한 기본 분산 방화벽 규칙만 켜고 끕니다. 프로젝트의 분산 방화벽은 끄지 않습니다.
예를 들어 분산 방화벽 서비스가 NSX 플랫폼에서 활성화된 경우에도 프로젝트의 기본 방화벽 규칙을 비활성화할 수 있습니다. 이 경우 기본 공간에 구성된 시스템 전체 기본 분산 방화벽 규칙이 프로젝트에 적용됩니다.
다음 표에서는 다양한 시나리오에서 프로젝트의 기본 분산 방화벽 규칙 활성화 토글의 기본 상태에 대해 설명합니다. 이 표에서 사용되는 "기본 라이센스"라는 용어는 다음 두 라이센스 중 하나를 의미합니다.
- VMware Cloud Foundation에 대한 NSX 네트워킹
- VCF에 대한 솔루션 라이센스
시나리오 번호 시나리오 토글의 기본 상태 참고 1
새 NSX 고객이며 시스템에 NSX 네트워킹 기능에 대한 사용 권한을 부여하는 기본 라이센스를 적용했습니다.
꺼짐
현재 적용된 라이센스가 분산 방화벽 보안 규칙의 구성을 지원하지 않기 때문에 이 토글을 편집할 수 없습니다.
시스템에서 적절한 보안 라이센스를 적용한 다음, 이 토글을 켜서 프로젝트의 기본 분산 방화벽 규칙을 활성화해야 합니다.
2
새 NSX 고객입니다. 0일 차에 시스템에 네트워킹 기능을 NSX에 대한 사용 권한을 부여하는 기본 라이센스를 적용했습니다. 시스템에 분산 방화벽 보안에 대한 사용 권한을 부여하는 적절한 보안 라이센스도 적용했습니다.
켜짐
프로젝트에 대해 기본 분산 방화벽 규칙이 활성화됩니다.
필요한 경우 프로젝트에서 이 기능을 해제할 수 있습니다.
3
새 NSX 고객입니다. 0일 차에 시스템에 NSX 네트워킹 기능에 대해서만 사용 권한을 부여하는 기본 라이센스만 적용했습니다. 시스템에 일부 프로젝트를 추가했습니다. 프로젝트 A 및 B라고 지칭해 보겠습니다.
나중에 2일 차 작업 중에 시스템에 분산 방화벽 보안에 대한 사용 권한을 부여하는 적절한 보안 라이센스를 적용했습니다.
이제 기존 프로젝트 A 및 B에 사용자 정의 분산 방화벽 규칙을 추가하고 시스템에서 새 프로젝트를 생성했습니다. 프로젝트 C 및 D를 가정해 보겠습니다.
꺼짐: 시스템의 기존 프로젝트
켜짐: 시스템의 새 프로젝트
이 시나리오에서 "기존 프로젝트"라는 용어는 보안 라이센스가 2일 차에 적용되기 전에 시스템에 있던 프로젝트를 나타냅니다. 이 시나리오에서는 프로젝트 A 및 B를 나타냅니다. "새 프로젝트"라는 용어는 2일 차에 보안 라이센스가 적용된 후 시스템에 추가된 프로젝트를 나타냅니다. 이 시나리오에서는 프로젝트 C 및 D를 나타냅니다.
기존 프로젝트 A 및 B의 경우 시스템 동작은 다음과 같습니다.
이 토글은 기본적으로 꺼진 상태가 됩니다. 사용자 정의 DFW 규칙은 프로젝트 A 및 B에서 유효합니다. 이러한 프로젝트에서 기본 분산 방화벽 규칙을 활성화하려면 편집 모드에서 이러한 프로젝트를 열고 이 토글을 수동으로 켭니다. 그러나 이 토글을 켜면 프로젝트 A 및 B의 East-West 트래픽 동작에 영향을 미칠 수 있습니다.
새 프로젝트 C 및 D의 경우 시스템 동작은 다음과 같습니다.
이 토글은 기본적으로 켜진 상태가 됩니다. 즉, 프로젝트 C 및 D의 경우 기본 분산 방화벽 규칙이 기본적으로 활성화됩니다. 필요한 경우 사용자 정의 분산 방화벽 규칙만 이러한 프로젝트에서 적용되도록 이 토글을 해제할 수 있습니다.
4
시스템에 전체 DFW 액세스 권한을 부여하는 레거시 NSX 라이센스가 있는 기존 NSX 고객입니다.
레거시 라이센스가 만료된 후 시스템에 NSX 네트워킹 기능에 대해 사용 권한을 부여하는 기본 라이센스를 적용하고 분산 방화벽 보안에 대한 사용 권한을 부여하는 보안 라이센스도 적용했습니다.
켜짐
기본 분산 방화벽 규칙 및 사용자 정의 분산 방화벽 규칙은 새 라이센스로 변경하기 전에 생성한 기존 프로젝트에서 계속 실행됩니다. 시스템 동작은 변경되지 않습니다.
라이센스를 변경한 후 추가하는 모든 새 프로젝트에 대해 이 토글은 기본적으로 켜져 있습니다. 필요한 경우 선택적으로 해제할 수 있습니다.
5
시스템에 전체 DFW 액세스 권한을 부여하는 레거시 NSX 라이센스가 있는 기존 NSX 고객입니다. 시스템에 두 개의 프로젝트를 추가했습니다. 프로젝트 A와 B라고 지칭해 보겠습니다.
현재 레거시 라이센스가 만료된 후 시스템에 NSX 네트워킹 기능에 대해서만 사용 권한을 부여하는 기본 라이센스를 적용했습니다. 보안 라이센스가 적용되지 않습니다.
이제 시스템에서 두 개의 새 프로젝트를 생성했습니다. 프로젝트 C와 D라고 지칭해 보겠습니다.
켜짐: 기존 프로젝트
꺼짐: 새 프로젝트
이 시나리오에서 "기존 프로젝트"라는 용어는 레거시 NSX 라이센스가 유효할 때 시스템에 추가된 프로젝트를 나타냅니다. 이 시나리오에서는 프로젝트 A 및 B를 나타냅니다. "새 프로젝트"라는 용어는 기본 라이센스가 적용된 후 시스템에 추가된 프로젝트를 나타냅니다. 이 시나리오에서는 프로젝트 C 및 D를 나타냅니다.
기존 프로젝트 A 및 B의 경우 시스템 동작은 다음과 같습니다.
이 토글은 기본적으로 켜진 상태입니다. 필요한 경우 해제할 수 있습니다. 그러나 이 작업은 되돌릴 수 없습니다. 즉, 프로젝트 A 및 B에서 기본 E-W 방화벽 규칙을 다시 활성화할 수 없습니다.
기본 분산 방화벽 규칙 및 사용자 정의 분산 방화벽 규칙은 프로젝트 A 및 B에서 계속 실행됩니다. 하지만 이러한 규칙은 편집할 수 없습니다. 새 분산 방화벽 규칙을 추가할 수도 없습니다. 하지만 기존 사용자 정의 방화벽 규칙을 삭제할 수 있습니다.
분산 방화벽 규칙에 대한 전체 액세스 권한을 가지려면 적절한 보안 라이센스를 적용해야 합니다.
새 프로젝트 C 및 D의 경우 시스템 동작은 다음과 같습니다.
이 토글은 기본적으로 꺼진 상태입니다. 현재 적용된 라이센스가 시스템에 분산 방화벽 기능에 대한 사용 권한을 부여하지 않으므로 이 기능을 켤 수 없습니다.
6 새 NSX 고객이고 시스템이 60일 동안 유효한 평가 모드로 전환되었습니다.
꺼짐
새 NSX 배포의 평가 기간 동안 시스템은 네트워킹 기능만 사용할 수 있습니다. 보안 기능은 사용할 수 없습니다.
- 선택 사항으로 프로젝트에 대한 설명을 입력합니다.
- 저장을 클릭합니다.
