Red Hat Summit4.5. Network-Focused Architectures
4.5.1절. “Network-Focused Architecture Types”
4.5.3절. “Large-Scale Web-Application Architecture”
4.5.4절. “Network-Focused Architecture Considerations”
4.5.1. Network-Focused Architecture Types
모든 OpenStack 배포는 서비스 기반 특성 때문에 네트워크 통신에 따라 제대로 작동합니다. 그러나 경우에 따라 네트워크 구성이 더 중요하며 추가 설계 고려 사항이 필요합니다.
다음 표에서는 일반적인 네트워크 중심 아키텍처를 설명합니다. 이러한 아키텍처는 안정적인 네트워크 인프라 및 사용자 및 애플리케이션 요구 사항을 충족하는 서비스에 따라 달라집니다.
| 아키텍처 | 설명 |
|---|---|
| 빅 데이터 | 빅 데이터의 관리 및 수집에 사용되는 클라우드는 네트워크 리소스에 대한 상당한 수요를 생성합니다. 빅 데이터는 대규모 분산 클라우드에 대한 무결성을 유지하기 위해 데이터의 부분 복제본을 사용하는 경우가 많습니다. 많은 양의 네트워크 리소스가 필요한 빅 데이터 애플리케이션에는 Cryostat, Cryostat, NuoDB, Riak 또는 기타 NoSQL 및 분산 데이터베이스가 포함됩니다. |
| CDN(Content Delivery Network) | CDN은 비디오 스트리밍, 사진 보기, 웹 회의 호스트 또는 많은 수의 최종 사용자가 분산 클라우드 기반 데이터 리포지토리에 액세스하는 데 사용할 수 있습니다. 네트워크 구성은 인스턴스 대기 시간, 대역폭 및 배포에 영향을 미칩니다. 콘텐츠 제공 및 성능에 영향을 미치는 다른 요인으로는 백엔드 시스템, 리소스 위치, WAN 아키텍처 및 캐시 방법론의 네트워크 처리량이 있습니다. |
| HA(고가용성) | HA 환경은 사이트 간 데이터 복제를 유지보수하는 네트워크 크기 조정에 따라 달라집니다. 하나의 사이트를 사용할 수 없게 되면 원래 사이트가 서비스로 돌아올 때까지 추가 사이트에서 증가된 부하를 제공할 수 있습니다. 추가 로드를 처리하기 위해 네트워크 용량을 크기를 조정하는 것이 중요합니다. |
| 고성능 컴퓨팅(HPC) | HPC 환경에서는 클라우드 클러스터의 요구 사항을 해결하기 위해 트래픽 흐름 및 사용 패턴을 추가로 고려해야 합니다. HPC는 네트워크 내에서 분산 컴퓨팅에 대한 동서(east-west) 트래픽 패턴을 보유하고 있지만 애플리케이션에 따라 네트워크 내외에서 상당한 north-south 트래픽을 보유할 수도 있습니다. |
| 고속 또는 대용량 트랜잭션 시스템 | 이러한 애플리케이션 유형은 네트워크 지터 및 대기 시간에 민감합니다. 예제 환경에는 금융 시스템, 신용 카드 거래 애플리케이션 및 거래 시스템이 포함됩니다. 이러한 아키텍처는 데이터 전송 효율성을 극대화하기 위해 많은 양의 east-west 트래픽과 north-south 트래픽의 균형을 유지해야 합니다. 이러한 시스템 중 대부분은 대규모 고성능 데이터베이스 백엔드에 액세스해야 합니다. |
| 네트워크 관리 기능 | DNS, NTP 또는 SNMP와 같은 백엔드 네트워크 서비스 제공을 지원하는 환경입니다. 이러한 서비스를 내부 네트워크 관리에 사용할 수 있습니다. |
| 네트워크 서비스 제공 | 고객용 네트워크 도구를 실행하여 서비스를 지원하는 환경입니다. 예를 들면 VPN, MPLS 사설 네트워크 및 GRE 터널이 있습니다. |
| 가상 데스크탑 인프라(VDI) | VDI 시스템은 네트워크 혼잡, 대기 시간 및 지터에 민감합니다. VDI에는 업스트림 및 다운스트림 트래픽이 필요하며 캐싱에 의존하여 애플리케이션을 최종 사용자에게 제공할 수 없습니다. |
| voice over IP (VoIP) | Cryostat 시스템은 네트워크 혼잡, 대기 시간 및 지터에 민감합니다. #159 시스템에는 대칭 트래픽 패턴이 있으며 최상의 성능을 위해 네트워크 품질 서비스(QoS)가 필요합니다. 또한 활성 대기열 관리를 구현하여 음성 및 멀티미디어 콘텐츠를 제공할 수 있습니다. 사용자는 대기 시간 및 지터 변동에 민감하며 매우 낮은 수준에서 감지할 수 있습니다. |
| 동영상 또는 웹 컨퍼런스 | 회의 시스템은 네트워크 혼잡, 대기 시간 및 지터에 민감합니다. 비디오 회의 시스템에는 대칭 트래픽 패턴이 있지만, 네트워크가 MPLS 사설 네트워크에서 호스팅되지 않으면 시스템은 QoS (Network quality of Service)를 사용하여 성능을 향상시킬 수 없습니다. #159와 유사하게 이러한 시스템의 사용자는 낮은 수준에서도 네트워크 성능 문제를 알 수 있습니다. |
| 웹 포털 또는 서비스 | 웹 서버는 클라우드 서비스의 일반적인 애플리케이션이며 네트워크 요구 사항을 이해해야 합니다. 사용자 요구를 충족하고 최소 지연 시간으로 웹 페이지를 제공하려면 네트워크를 확장해야 합니다. 포털 아키텍처의 세부 정보에 따라 아키텍처를 계획할 때 내부 east-west 및 north-south 네트워크 대역폭을 고려해야 합니다. |
4.5.2. 클라우드 스토리지 및 백업 아키텍처
이 아키텍처는 파일 스토리지 및 파일 공유를 제공하는 클라우드용입니다. 이 경우 스토리지 중심 사용 사례를 고려할 수 있지만 네트워크 측 요구 사항으로 인해 네트워크 중심 사용 사례가 됩니다.
설치 및 배포 문서는 5장. 배포 정보 에서 참조하십시오.
4.5.2.1. 설계 정보
다음 cloud-backup 애플리케이션 워크로드에는 네트워크에 영향을 미치는 두 가지 특정 동작이 있습니다.
이 워크로드에는 외부 서비스 및 내부 복제 애플리케이션이 포함되어 있으므로 north-south 및 east-west 트래픽 고려 사항이 필요합니다.
- North-south 트래픽
North-south 트래픽은 클라우드에서 이동하거나 외부에서 이동하는 데이터로 구성됩니다. 사용자가 콘텐츠를 업로드하고 저장하면 해당 콘텐츠가 southbound를 OpenStack 환경으로 이동합니다. 사용자가 콘텐츠를 다운로드하면 해당 콘텐츠가 OpenStack 환경에서 northbound로 이동합니다.
이 서비스는 주로 백업 서비스로 작동하기 때문에 대부분의 트래픽은 southbound를 환경으로 이동합니다. 이 경우 OpenStack 환경에 들어오는 트래픽이 환경을 떠나는 트래픽보다 크므로 네트워크를 비대칭적으로 다운스트림으로 구성해야 합니다.
- East-west 트래픽
- 동서부 트래픽은 환경 내에서 이동하는 데이터로 구성됩니다. 복제는 모든 노드에서 시작되어 알고리즘적으로 여러 노드를 대상으로 할 수 있으므로 이 트래픽은 완전히 대칭일 수 있습니다. 그러나 이러한 트래픽은 북경 트래픽을 방해할 수 있습니다.
4.5.2.2. 아키텍처 구성 요소
| Component | 설명 |
|---|---|
| Compute | 컨트롤러에서 실행되는 컴퓨팅 관리 및 스케줄링 서비스. Compute 서비스는 각 컴퓨팅 노드에서도 실행됩니다. |
| 대시보드 | OpenStack 관리를 위한 웹 콘솔. |
| ID | 기본 인증 및 권한 부여 기능 |
| 이미지 | 인스턴스 부팅 및 스냅샷 관리에 사용할 이미지를 저장합니다. 이 서비스는 컨트롤러에서 실행되며 작은 이미지 세트를 제공합니다. |
| 네트워킹 | 네트워킹 서비스. OpenStack 네트워킹에 대한 자세한 내용은 2장. 네트워킹 In-Depth 을 참조하십시오. |
| 오브젝트 스토리지 | 백업 콘텐츠를 저장합니다. |
| telemetry | 기타 OpenStack 서비스에 대한 모니터링 및 보고. |
4.5.2.3. 설계 고려 사항
3장. 설계 에 설명된 기본 설계 고려 사항 외에도 4.5.4절. “Network-Focused Architecture Considerations” 에 설명된 고려 사항도 따라야 합니다.
4.5.3. Large-Scale Web-Application Architecture
이 아키텍처는 버스트에서 수평으로 확장되고 높은 인스턴스 수를 생성하는 대규모 웹 애플리케이션용입니다. 이 애플리케이션은 데이터를 보호하기 위해 SSL 연결이 필요하며 개별 서버에 대한 연결을 끊어서는 안 됩니다.
설치 및 배포 문서는 5장. 배포 정보 에서 참조하십시오.
4.5.3.1. 설계 정보
다음 다이어그램에서는 이 워크로드에 대한 예제 설계를 보여줍니다.
이 설계에는 다음과 같은 구성 요소 및 워크플로우가 포함됩니다.
- 하드웨어 로드 밸런서는 SSL 오프로드 기능을 제공하며 테넌트 네트워크에 연결하여 주소 사용을 줄입니다.
- 로드 밸런서는 애플리케이션의 가상 IP(VIP)를 서비스하는 동안 라우팅 아키텍처에 연결됩니다.
- 라우터 및 로드 밸런서는 애플리케이션 테넌트 네트워크의 GRE 터널 ID와 주소 풀 외부에 있지만 테넌트 서브넷에 있는 IP 주소를 사용합니다. 이 구성을 사용하면 공용 IP 주소를 사용하지 않고도 로드 밸런서가 애플리케이션 HTTP 서버와 통신할 수 있습니다.
4.5.3.2. 아키텍처 구성 요소
웹 서비스 아키텍처는 다양한 옵션과 선택적 구성 요소로 구성될 수 있습니다. 따라서 이 아키텍처는 여러 OpenStack 설계에서 사용할 수 있습니다. 그러나 대부분의 웹 스케일 워크로드를 처리하려면 일부 주요 구성 요소를 배포해야 합니다.
| Component | 설명 |
|---|---|
| Compute | 컨트롤러에서 실행되는 컴퓨팅 관리 및 스케줄링 서비스. Compute 서비스는 각 컴퓨팅 노드에서도 실행됩니다. |
| 대시보드 | OpenStack 관리를 위한 웹 콘솔. |
| ID | 기본 인증 및 권한 부여 기능 |
| 이미지 | 인스턴스 부팅 및 스냅샷 관리에 사용할 이미지를 저장합니다. 이 서비스는 컨트롤러에서 실행되며 작은 이미지 세트를 제공합니다. |
| 네트워킹 | 네트워킹 서비스. 분할 네트워크 구성은 개인 테넌트 네트워크에 있는 데이터베이스와 호환됩니다. 데이터베이스가 대량의 브로드캐스트 트래픽을 내보내지 않고 콘텐츠를 위해 다른 데이터베이스에 상호 연결해야 하므로 개인 테넌트 네트워크에 있는 데이터베이스와 호환됩니다. |
| 오케스트레이션 | 확장 시 및 트래픽 버스트 중에 사용할 인스턴스 템플릿을 관리합니다. |
| telemetry | 기타 OpenStack 서비스에 대한 모니터링 및 보고. 이 서비스를 사용하여 인스턴스 사용량을 모니터링하고 오케스트레이션 서비스에서 인스턴스 템플릿을 호출합니다. |
| 오브젝트 스토리지 | 백업 콘텐츠를 저장합니다. |
4.5.3.3. 설계 고려 사항
3장. 설계 에 설명된 기본 설계 고려 사항 외에도 4.5.4절. “Network-Focused Architecture Considerations” 에 설명된 고려 사항도 따라야 합니다.
4.5.4. Network-Focused Architecture Considerations
3장. 설계 에 설명된 기본 설계 고려 사항 및 2장. 네트워킹 In-Depth 에 설명된 네트워크 노드 설계 외에도 네트워크 집약적인 아키텍처에서는 다음 항목을 고려해야 합니다.
- 외부 종속 항목
다음 외부 네트워크 구성 요소를 사용하는 것이 좋습니다.
- 워크로드를 분산하거나 특정 기능을 오프로드하는 하드웨어 로드 밸런서
- 동적 라우팅을 구현하는 외부 장치
OpenStack Networking에서는 터널링 기능을 제공하지만 네트워킹 관리 리전으로 제한됩니다. OpenStack 리전을 초과하는 터널을 다른 지역 또는 외부 시스템으로 확장하려면 OpenStack 외부의 터널을 구현하거나 터널 관리 시스템을 사용하여 터널 또는 오버레이를 외부 터널에 매핑합니다.
- 최대 전송 단위(MTU)
일부 워크로드에서는 대규모 데이터 블록으로 인해 더 큰 MTU가 필요합니다. 비디오 스트리밍 또는 스토리지 복제와 같은 애플리케이션에 대한 네트워크 서비스를 제공할 때 OpenStack 하드웨어 노드 및 가능한 경우 점보 프레임에 대한 지원 네트워크 장치를 구성합니다. 이 구성은 사용 가능한 대역폭 사용량을 극대화합니다.
패킷이 통과하는 전체 경로에 점보 프레임을 구성합니다. 하나의 네트워크 구성 요소에서 점보 프레임을 처리할 수 없는 경우 전체 경로가 기본 MTU로 되돌아갑니다.
- NAT 사용
고정 공용 IP 대신 유동 IP가 필요한 경우 NAT를 사용해야 합니다. 예를 들어 DHCP 서버 IP에 매핑된 DHCP 릴레이를 사용합니다. 이 경우 새 인스턴스마다 기존 또는 외부 시스템을 재구성하는 대신 대상 IP를 새 인스턴스에 적용하기 위해 인프라를 자동화하는 것이 더 쉽습니다.
OpenStack Networking에서 관리하는 유동 IP의 NAT는 하이퍼바이저에 있습니다. 그러나 NAT의 다른 버전이 다른 위치에서 실행 중일 수 있습니다. IPv4 주소가 부족한 경우 다음 방법을 사용하여 OpenStack 외부에서 부족을 완화할 수 있습니다.
- OpenStack에서 인스턴스로 로드 밸런서를 실행하거나 외부로 서비스로 실행합니다. OpenStack Load-Balancer-as-a-Service(LBaaS)는 내부적으로 HAproxy와 같은 부하 분산 소프트웨어를 관리할 수 있습니다. 이 서비스는 HAproxy 인스턴스의 이중 홈 연결이 모든 콘텐츠 서버를 호스팅하는 테넌트 사설 네트워크와 공용 네트워크를 연결하는 동안 VIP(가상 IP) 주소를 관리합니다.
- 로드 밸런서를 사용하여 VIP를 제공하고 외부 방법 또는 개인 주소를 사용하여 테넌트 오버레이 네트워크에 연결합니다.
경우에 따라 인스턴스에서 IPv6 주소만 사용하고 인스턴스 또는 외부 서비스를 작동하여 NAT64 및 DNS64와 같은 NAT 기반 전환 기술을 제공하는 것이 좋습니다. 이 구성은 필요에 따라 IPv4 주소를 사용하는 동안 전역적으로 라우팅 가능한 IPv6 주소를 제공합니다.
- QoS(Quality of Service)
QoS는 네트워크 성능이 저하되어 우선 순위가 높은 패킷에 즉시 서비스를 제공하므로 네트워크 집약적인 워크로드에 영향을 미칩니다. VoIP(VoIP)와 같은 애플리케이션에서는 일반적으로 지속적인 작업을 위해 구분된 서비스 코드 포인트가 필요합니다.
또한 혼합 워크로드에 QoS를 사용하여 백업 서비스, 비디오 회의 또는 파일 공유와 같은 우선순위가 낮은 고 대역폭 애플리케이션이 다른 워크로드의 지속적인 작동에 필요한 대역폭을 차단하지 못하도록 할 수도 있습니다.
파일 스토리지 트래픽을 최상의 노력 또는 scavenger와 같은 더 낮은 클래스 트래픽으로 태그하여 우선순위가 높은 트래픽이 네트워크를 통과하도록 허용할 수 있습니다. 클라우드의 영역이 지리적으로 분산된 경우 WAN 최적화를 사용하여 대기 시간 또는 패킷 손실을 줄일 수도 있습니다.
- 워크로드
라우팅 및 전환 아키텍처는 네트워크 수준 중복성이 필요한 workdloads를 수용해야 합니다. 구성은 선택한 네트워크 하드웨어, 선택한 하드웨어 성능 및 네트워킹 모델에 따라 다릅니다. 예를 들면 LAG(Link Aggregation) 및 HSM(Hot Standby Router Protocol)이 있습니다.
워크로드는 오버레이 네트워크의 효과에도 영향을 미칩니다. 애플리케이션 네트워크 연결이 작고 짧은 라이브 또는 버스트인 경우 동적 오버레이를 실행하면 네트워크가 전송하는 패킷만큼 많은 대역폭을 생성할 수 있습니다. 오버레이를 사용하면 하이퍼바이저에 문제가 발생할 수 있는 대기 시간이 충분히 발생할 수 있으므로 패킷당 초당 성능 저하 및 연결당 초당 성능 저하가 발생할 수 있습니다.
기본적으로 오버레이에는 워크로드에 따라 달라지는 보조 full-mesh 옵션이 포함됩니다. 예를 들어 대부분의 웹 서비스 애플리케이션에는 전체 메시 오버레이 네트워크에 문제가 없으며 일부 네트워크 모니터링 도구 또는 스토리지 복제 워크로드에는 처리량 또는 과도한 브로드캐스트 트래픽과 관련된 성능 문제가 있습니다.
