Red Hat Summit3.4. 네트워크 리소스
네트워크 가용성은 클라우드 배포의 하이퍼바이저에 중요합니다. 예를 들어 하이퍼바이저가 각 노드에 대해 몇 개의 VM(가상 머신)만 지원하고 애플리케이션에 고속 네트워킹이 필요하지 않은 경우 하나 또는 두 개의 1GB 이더넷 링크를 사용할 수 있습니다. 그러나 애플리케이션에 고속 네트워킹 또는 하이퍼바이저가 각 노드에 대해 여러 VM을 지원하는 경우 하나 또는 두 개의 10GB 이더넷 링크가 권장됩니다.
일반적인 클라우드 배포에서는 일반적으로 필요한 기존 코어 네트워크 토폴로지보다 피어 투 피어 통신을 더 많이 사용합니다. VM은 클러스터 전체에서 무작위로 프로비저닝되지만 이러한 VM은 동일한 네트워크에 있는 것처럼 서로 통신해야 합니다. 이 요구 사항은 에지와 네트워크 코어 간 연결을 과도하게 구독하여 네트워크를 저하시키고 기존 핵심 네트워크 토폴로지에서 패킷 손실을 유발할 수 있습니다.
3.4.1. 서비스 분리
OpenStack 클라우드에는 일반적으로 여러 네트워크 세그먼트가 있습니다. 각 세그먼트는 클라우드의 리소스에 대한 액세스를 운영자 및 테넌트에 제공합니다. 네트워크 서비스에는 다른 네트워크와 분리된 네트워크 통신 경로도 필요합니다. 서비스를 분리하여 별도의 네트워크를 분리하면 민감한 데이터를 보호하고 서비스에 대한 무단 액세스로부터 보호할 수 있습니다.
최소 권장 분리에는 다음과 같은 네트워크 세그먼트가 포함됩니다.
- 테넌트 및 운영자가 클라우드 REST API에 액세스하는 데 사용하는 공용 네트워크 세그먼트입니다. 일반적으로 이 네트워크 세그먼트에 연결하려면 일반적으로 컨트롤러 노드와 클라우드의 swift 프록시만 필요합니다. 경우에 따라 이 네트워크 세그먼트가 하드웨어 로드 밸런서 및 기타 네트워크 장치에 의해 서비스될 수도 있습니다.
클라우드 관리자가 하드웨어 리소스를 관리하고 구성 관리 툴을 통해 새 하드웨어에 소프트웨어 및 서비스를 배포하는 데 사용하는 관리 네트워크 세그먼트입니다. 경우에 따라 이 네트워크 세그먼트가 메시지 버스 및 서로 통신해야 하는 데이터베이스 서비스를 포함하여 내부 서비스에도 사용될 수 있습니다.
이 네트워크 세그먼트의 보안 요구 사항으로 인해 이 네트워크를 무단 액세스로부터 보호하는 것이 좋습니다. 이 네트워크 세그먼트는 일반적으로 클라우드의 모든 하드웨어 노드와 통신해야 합니다.
애플리케이션 및 소비자가 물리적 네트워크에 대한 액세스를 제공하고 사용자가 클라우드에서 실행되는 애플리케이션에 액세스하는 데 사용하는 애플리케이션 네트워크 세그먼트입니다. 이 네트워크는 공용 네트워크 세그먼트와 분리되어야 하며 클라우드의 하드웨어 리소스와 직접 통신해서는 안 됩니다.
이 네트워크 세그먼트는 애플리케이션 데이터를 클라우드 외부의 물리적 네트워크로 전송하는 컴퓨팅 리소스 노드 및 네트워크 게이트웨이 서비스에서 통신에 사용할 수 있습니다.
3.4.2. 네트워크 유형 선택
선택한 네트워크 유형은 클라우드 네트워크 아키텍처 설계에 중요한 역할을 합니다.
- OpenStack Networking(neutron)은 OpenStack 미래 지향 로드맵의 핵심 소프트웨어 정의 네트워킹(SDN) 구성 요소이며 현재 개발 중입니다.
- 컴퓨팅 네트워킹(nova-network)은 OpenStack 기술 로드맵에서 더 이상 사용되지 않지만 현재도 사용할 수 있습니다.
컴퓨팅 네트워킹과 OpenStack 네트워킹 사이에는 마이그레이션 경로가 없습니다. 따라서 Compute 네트워킹을 배포하려는 경우 OpenStack Networking으로 업그레이드할 수 없으며 네트워크 유형 간 마이그레이션을 수동으로 수행해야 하며 네트워크 중단이 필요합니다.
3.4.2.1. OpenStack Networking(neutron)을 선택해야 하는 시기
다음 기능이 필요한 경우 OpenStack Networking을 선택합니다.
오버레이 네트워크 솔루션. OpenStack Networking에서는 가상 머신 트래픽 격리를 위해 GRE 및 VXLAN 터널링을 지원합니다. GRE 또는 VXLAN은 네트워크 패브릭에 VLAN 구성이 필요하지 않으며, 노드 간에 IP 연결을 제공하기 위해 물리적 네트워크만 있으면 됩니다.
VXLAN 또는 GRE를 사용하면 802.1q VLAN의 4094 고유 ID 제한과 비교하여 이론적으로 16만 개의 고유 ID 제한을 사용할 수 있습니다. 컴퓨팅 네트워킹은 802.1q VLAN에서 네트워크를 분리하고 GRE 또는 VXLAN을 사용한 터널링을 지원하지 않습니다.
테넌트 간 IP 주소 중복 OpenStack Networking에서는 Linux 커널의 네트워크 네임스페이스 기능을 사용하므로 서로 다른 테넌트가 겹치거나 손상될 위험이 없는 동일한 컴퓨팅 노드에서 동일한 서브넷 범위(예: 192.168.100/24)를 사용할 수 있습니다. 이 기능은 대규모 멀티 테넌시 배포에 적합합니다.
비교하면 Compute 네트워킹은 모든 테넌트에서 사용하는 서브넷을 계속 알아야 하는 플랫 토폴로지만 제공합니다.
Red Hat 인증 타사 OpenStack Networking 플러그인. 기본적으로 Red Hat OpenStack Platform은 OVS(Open vSwitch) 메커니즘 드라이버와 함께 오픈 소스 ML2 코어 플러그인을 사용합니다. OpenStack Networking의 모듈식 구조를 사용하면 물리적 네트워크 패브릭 및 기타 네트워크 요구 사항을 기반으로 기본 ML2/Open vSwitch 드라이버 대신 타사 OpenStack Networking 플러그인을 배포할 수 있습니다.
Red Hat은 파트너 인증 프로그램을 확장하여 Red Hat OpenStack Platform의 OpenStack Networking 플러그인을 추가로 인증하고 있습니다. 인증 프로그램에 대해 자세히 알아보고 http://marketplace.redhat.com에서 인증된 OpenStack Networking 플러그인 목록을 볼 수 있습니다.
- VPN-as-a-service(VPNaaS), Firewall-as-a-service(FWaaS) 또는 LBaaS(Load-Balancing-as-a-service)입니다. 이러한 네트워크 서비스는 OpenStack Networking에서만 사용할 수 있으며 Compute 네트워킹에서는 사용할 수 없습니다. 대시보드를 사용하면 테넌트가 관리자 개입 없이 이러한 서비스를 관리할 수 있습니다.
3.4.2.2. Compute Networking(nova-network)을 선택하는 시기
Compute 네트워킹(nova-network) 서비스는 주로 두 가지 모드로 작동하는 계층 2 네트워킹 서비스입니다. 이러한 모드는 VLAN 사용량에 따라 다릅니다.
- 플랫 네트워크 모드. 클라우드의 모든 네트워크 하드웨어 노드 및 장치는 애플리케이션 데이터에 대한 액세스를 제공하는 단일 계층 2 네트워크 세그먼트에 연결됩니다.
- VLAN 분할 모드. 클라우드의 네트워크 장치가 VLAN의 분할을 지원하는 경우 클라우드의 각 테넌트에 물리적 네트워크의 VLAN에 매핑된 네트워크 서브넷이 할당됩니다. 클라우드 설계에서 여러 테넌트를 지원해야 하고 Compute 네트워킹을 사용하려면 이 모드를 사용해야 합니다.
컴퓨팅 네트워킹은 클라우드 운영자만 관리합니다. 테넌트는 네트워크 리소스를 제어할 수 없습니다. 테넌트가 네트워크 세그먼트 및 서브넷과 같은 네트워크 리소스를 관리하고 생성해야 하는 경우 인스턴스에 대한 네트워크 액세스를 제공하기 위해 OpenStack Networking 서비스를 설치해야 합니다.
다음 경우 Compute Networking을 선택합니다.
- 배포에 태그되지 않은 네트워킹 또는 VLAN 802.1q 네트워킹이 필요한 경우 네트워킹 토폴로지는 이론적인 규모를 4094 VLAN ID로 제한하고 물리적 스위치는 일반적으로 훨씬 더 적은 수를 지원합니다. 이 네트워크는 관리 및 프로비저닝 제한도 줄입니다. 노드 간에 필요한 VLAN 세트를 트렁크하도록 네트워크를 수동으로 구성해야 합니다.
- 배포에 테넌트 간에 겹치는 IP 주소가 필요하지 않은 경우 일반적으로 소규모 프라이빗 배포에만 적합합니다.
- 소프트웨어 정의 네트워킹(SDN) 솔루션 또는 물리적 네트워크 패브릭과 상호 작용할 수 있는 기능이 필요하지 않은 경우입니다.
- 셀프 서비스 VPN, 방화벽 또는 Load-Balancing 서비스가 필요하지 않은 경우
3.4.3. 일반 고려 사항
- 보안
네트워크 서비스를 분리하고 불필요한 위치를 통과하지 않고 트래픽이 올바른 대상으로 이동해야 합니다.
다음 예제 요인을 고려하십시오.
- 방화벽
- 분리된 테넌트 네트워크에 결합하기 위한 오버레이 상호 연결
- 특정 네트워크를 통한 라우팅 또는 방지
네트워크가 하이퍼바이저에 연결하는 방식은 보안 취약점을 노출할 수 있습니다. 하이퍼바이저 중단을 악용하지 않도록 완화하기 위해 다른 시스템과 별도의 네트워크를 분리하고 네트워크에 대한 인스턴스를 전용 컴퓨팅 노드로 예약합니다. 이러한 분리를 통해 공격자는 손상된 인스턴스에서 네트워크에 액세스할 수 없습니다.
- 용량 계획
- 클라우드 네트워크에는 용량 및 성장 관리가 필요합니다. 용량 계획에는 몇 달 또는 몇 년 동안 측정 가능한 리드 타임이 있는 네트워크 회로 및 하드웨어 구매가 포함될 수 있습니다.
- 복잡성
- 복잡한 네트워크 설계는 유지 관리하고 해결하기 어려울 수 있습니다. 장치 수준 구성을 사용하면 유지 관리 문제를 완화할 수 있으며 자동화된 툴은 오버레이 네트워크를 처리할 수 있지만, 기능 및 특수 하드웨어 간의 기존 상호 연결을 방지하거나 문서화하여 중단을 방지합니다.
- 구성 오류
- 잘못된 IP 주소, VLAN 또는 라우터를 구성하면 네트워크 영역 또는 전체 클라우드 인프라에서도 중단될 수 있습니다. 네트워크 구성을 자동화하여 네트워크 가용성을 저하시킬 수 있는 Operator 오류를 최소화합니다.
- 비표준 기능
벤더별 기능을 활용하도록 클라우드 네트워크를 구성하면 추가 위험이 발생할 수 있습니다.
예를 들어 MLAG(Multi-link aggregation)를 사용하여 네트워크의 수집기 전환 수준에서 중복성을 제공할 수 있습니다. MLAG는 표준 집계 형식이 아니며 각 공급 업체는 기능의 독점 플레이버를 구현합니다. MLAG 아키텍처는 전환 벤더 간에 상호 운용이 이루어지지 않으므로 벤더에 종속되어 네트워크 구성 요소를 업그레이드할 때 지연이나 문제가 발생할 수 있습니다.
- 단일 실패 지점
- 하나의 업스트림 링크 또는 하나의 전원 공급 장치만으로 인해 SPOF(Single Point of Failure)가 있는 경우 오류가 발생할 경우 네트워크 중단이 발생할 수 있습니다.
- tuning
- 링크 손실, 패킷 손실, 패킷 유예, 브로드캐스트 유림 및 루프를 최소화하도록 클라우드 네트워크를 구성합니다.
3.4.4. 네트워킹 하드웨어
모든 구현에 적용할 수 있는 OpenStack 클라우드를 지원하는 네트워킹 하드웨어를 위한 단일 모범 사례 아키텍처는 없습니다. 네트워킹 하드웨어 선택의 주요 고려 사항은 다음과 같습니다.
- 가용성
중단되지 않는 클라우드 노드 액세스를 보장하기 위해 네트워크 아키텍처에서 단일 장애 지점을 식별하고 적절한 중복성 또는 내결함성을 제공해야 합니다.
- 네트워크 중복은 중복 전원 공급 장치 또는 페어링된 스위치를 추가하여 수행할 수 있습니다.
- 네트워크 인프라의 경우 LACP, VRRP 또는 이와 유사한 네트워킹 프로토콜을 사용하여 고가용성 네트워크 연결을 얻을 수 있습니다.
- 클라우드의 OpenStack API 및 기타 서비스가 가용성이 높은지 확인하려면 네트워크 아키텍처 내에서 부하 분산 솔루션을 설계해야 합니다.
- 연결
- OpenStack 클라우드 내의 모든 노드에는 네트워크 연결이 필요합니다. 경우에 따라 노드에는 여러 네트워크 세그먼트에 액세스해야 하는 경우가 있습니다. 설계에는 클라우드의 모든 north-south 및 east-west 트래픽에 충분한 리소스가 있는지 확인하기 위해 충분한 네트워크 용량 및 대역폭이 포함되어야 합니다.
- 포트
모든 설계에는 필요한 포트가 있는 네트워킹 하드웨어가 필요합니다.
- 포트를 제공하는 데 필요한 물리적 공간이 있는지 확인합니다. 컴퓨팅 또는 스토리지 구성 요소에 더 많은 랙 공간이 유지되므로 포트 밀도가 더 높습니다. 적절한 포트 가용성은 결함 도메인을 방지하고 전원 밀도를 지원합니다. 더 높은 밀도 스위치는 더 많은 비용이 들며, 필요하지 않은 경우 네트워크를 과도하게 설계하지 않는 것이 중요하므로 고려해야 합니다.
- 네트워킹 하드웨어는 제안된 네트워크 속도를 지원해야 합니다. 예: 1GbE, 10GbE 또는 40GbE(또는 100GbE).
- power
- 물리적 데이터 센터가 선택한 네트워크 하드웨어에 필요한 전원을 제공하는지 확인합니다. 예를 들어 리프 앤 스페인 패브릭 또는 행 종료(EoR) 스위치의 회전 스위치는 충분한 전력을 제공하지 않을 수 있습니다.
- 확장성
- 네트워크 설계에는 확장 가능한 물리적 및 논리적 네트워크 설계가 포함되어야 합니다. 네트워크 하드웨어는 하드웨어 노드에 필요한 인터페이스 및 속도를 제공해야 합니다.
