아키텍처 가이드
제품, 구성 요소 및 아키텍처 예제 소개
초록
머리말
Red Hat OpenStack Platform은 Red Hat Enterprise Linux를 기반으로 프라이빗 또는 퍼블릭 IaaS(Infrastructure-as-a-Service) 클라우드를 구축할 수 있는 기반을 제공합니다. 클라우드 지원 워크로드 개발을 위해 확장성이 뛰어난 내결함성 플랫폼을 제공합니다.
Red Hat OpenStack Platform은 사용 가능한 물리적 하드웨어를 다음과 같은 프라이빗, 퍼블릭 또는 하이브리드 클라우드 플랫폼으로 전환할 수 있도록 패키징되어 있습니다.
- 완전 분산 오브젝트 스토리지
- 영구 블록 수준 스토리지
- 가상 머신 프로비저닝 엔진 및 이미지 스토리지
- 인증 및 권한 부여 메커니즘
- 통합된 네트워킹
- 사용자와 관리자가 액세스할 수 있는 웹 브라우저 기반 인터페이스
- 이 가이드에 언급된 구성 요소에 대한 참조 정보는 5장. 배포 정보 에서 참조하십시오.
- 전체 Red Hat OpenStack Platform 설명서 모음은 Red Hat OpenStack Platform 문서를 참조하십시오.
1장. components
Red Hat OpenStack Platform IaaS 클라우드는 컴퓨팅, 스토리지 및 네트워킹 리소스를 제어하는 상호 작용 서비스 컬렉션으로 구현됩니다. 관리자는 OpenStack 리소스를 제어, 프로비저닝 및 자동화할 수 있는 웹 기반 대시보드 또는 명령줄 클라이언트를 사용하여 클라우드를 관리할 수 있습니다. OpenStack에는 모든 클라우드 사용자가 사용할 수 있는 광범위한 API도 있습니다.
다음 다이어그램에서는 OpenStack 핵심 서비스 및 서로 간의 관계를 개괄적으로 설명합니다.
다음 표에서는 다이어그램에 표시된 각 구성 요소에 대해 설명하고 구성 요소 설명서 섹션에 대한 링크를 제공합니다.
Service | 코드 | 설명 | 위치 | |
---|---|---|---|---|
| 대시보드 | Horizon | OpenStack 서비스를 관리하는 데 사용하는 웹 브라우저 기반 대시보드입니다. | |
| ID | Keystone | OpenStack 서비스의 인증 및 권한 부여 및 사용자, 프로젝트, 역할 관리를 위한 중앙 집중식 서비스입니다. | |
| OpenStack Networking | Neutron | OpenStack 서비스의 인터페이스 간 연결을 제공합니다. | |
| 블록 스토리지 | cinder | 가상 머신의 영구 블록 스토리지 볼륨을 관리합니다. | |
| Compute | Nova | 하이퍼바이저 노드에서 실행되는 가상 머신을 관리하고 프로비저닝합니다. | |
| 이미지 | glance | 가상 머신 이미지 및 볼륨 스냅샷과 같은 리소스를 저장하는 데 사용하는 레지스트리 서비스입니다. | |
| 오브젝트 스토리지 | swift | 사용자가 파일 및 임의의 데이터를 저장하고 검색할 수 있습니다. | |
| telemetry | ceilometer | 클라우드 리소스의 측정을 제공합니다. | |
| 오케스트레이션 | Heat | 리소스 스택 자동 생성을 지원하는 템플릿 기반 오케스트레이션 엔진입니다. |
각 OpenStack 서비스에는 기능적인 Linux 서비스 및 기타 구성 요소 그룹이 포함되어 있습니다. 예를 들어, glance-api 및 glance-registry Linux 서비스는 MariaDB 데이터베이스와 함께 이미지 서비스를 구현합니다. OpenStack 서비스에 포함된 타사 구성 요소에 대한 자세한 내용은 1.6.1절. “타사 구성 요소” 을 참조하십시오.
추가 서비스는 다음과 같습니다.
- 1.3.2절. “OpenStack Bare Metal Provisioning(ironic)” - 사용자가 다양한 하드웨어 벤더를 통해 물리적 머신(베어 메탈)을 프로비저닝할 수 있습니다.
- 1.2.3절. “OpenStack Database-as-a-Service(trove)” - 사용자가 관계형 및 비관계형 데이터베이스 엔진을 배포하고 복잡한 데이터베이스 관리 작업을 처리할 수 있습니다.
- 1.3.5절. “OpenStack Data Processing(sahara)” - 사용자가 OpenStack에서 Cryostat 클러스터를 프로비저닝하고 관리할 수 있습니다.
1.1. 네트워킹
1.1.1. OpenStack Networking(neutron)
OpenStack Networking은 OpenStack 클라우드에서 가상 네트워킹 인프라의 생성 및 관리를 처리합니다. 인프라 요소에는 네트워크, 서브넷 및 라우터가 포함됩니다. 방화벽 또는 VPN(Virtual Private Network)과 같은 고급 서비스를 배포할 수도 있습니다.
OpenStack Networking에서는 클라우드 관리자가 어느 물리적 시스템에서 실행할 개별 서비스를 유연하게 결정할 수 있는 유연성을 제공합니다. 모든 서비스 데몬은 평가를 위해 단일 물리적 호스트에서 실행할 수 있습니다. 또는 각 서비스에 고유한 물리적 호스트가 있거나 여러 호스트에 복제되어 중복성을 제공할 수 있습니다.
OpenStack Networking은 소프트웨어 정의이므로 새로운 IP 주소 생성 및 할당과 같은 변화하는 네트워크 요구 사항에 실시간으로 대응할 수 있습니다.
OpenStack Networking의 장점은 다음과 같습니다.
- 사용자는 네트워크를 생성하고, 트래픽을 제어하고, 서버와 장치를 하나 이상의 네트워크에 연결할 수 있습니다.
- 유연한 네트워킹 모델은 네트워크 볼륨 및 테넌시에 맞게 조정할 수 있습니다.
- IP 주소는 동적 트래픽 재실행에 사용할 수 있는 전용 또는 유동 IP일 수 있습니다.
- VLAN 네트워킹을 사용하는 경우 최대 4094 VLAN(4094 네트워크)을 사용할 수 있습니다. 여기서 4094 = 2^12(사용할 수 없는 2개) 네트워크 주소는 12비트 헤더 제한에 의해 부과됩니다.
- VXLAN 터널 기반 네트워크를 사용하는 경우 VNI(Virtual Network Identifier)는 기본적으로 약 16만 개의 고유 주소/네트워크를 허용하는 24비트 헤더를 사용할 수 있습니다.
Component | 설명 |
---|---|
네트워크 에이전트 | 각 OpenStack 노드에서 실행되는 서비스는 노드 가상 머신 및 Open vSwitch와 같은 네트워킹 서비스에 대한 로컬 네트워킹 구성을 수행합니다. |
neutron-dhcp-agent | 테넌트 네트워크에 DHCP 서비스를 제공하는 에이전트입니다. |
neutron-ml2 | 네트워크 드라이버를 관리하고 Open vSwitch 또는 Ryu 네트워크와 같은 네트워킹 서비스에 대한 라우팅 및 전환 서비스를 제공하는 플러그인입니다. |
neutron-server | 사용자 요청을 관리하고 Networking API를 노출하는 Python 데몬입니다. 기본 서버 구성에서는 특정 네트워킹 메커니즘 세트와 함께 플러그인을 사용하여 Networking API를 구현합니다. openvswitch 및 linuxbridge 플러그인과 같은 특정 플러그인은 기본 Linux 네트워킹 메커니즘을 사용하는 반면 다른 플러그인은 외부 장치 또는 SDN 컨트롤러와 인터페이스합니다. |
Neutron | API에 액세스하는 명령줄 클라이언트입니다. |
OpenStack Networking 서비스 및 에이전트 배치는 네트워크 요구 사항에 따라 다릅니다. 다음 다이어그램에서는 컨트롤러가 없는 일반적인 배포 모델의 예를 보여줍니다. 이 모델은 전용 OpenStack Networking 노드 및 테넌트 네트워크를 활용합니다.
이 예제에서는 다음 네트워킹 서비스 구성을 보여줍니다.
두 개의 컴퓨팅 노드는 Open vSwitch(ovs-agent)를 실행하고 하나의 OpenStack Networking 노드는 다음 네트워크 기능을 수행합니다.
- L3 라우팅
- DHCP
- FWaaS 및 LBaaS와 같은 서비스를 포함하는 NAT
- 컴퓨팅 노드에는 각각 두 개의 물리적 네트워크 카드가 있습니다. 하나의 카드는 테넌트 트래픽을 처리하고 다른 카드는 연결을 관리합니다.
- OpenStack Networking 노드에는 공급자 트래픽 전용 세 번째 네트워크 카드가 있습니다.
1.2. 스토리지
1.2.1절. “OpenStack Block Storage(cinder)”
1.2.2절. “OpenStack Object Storage(swift)”
1.2.3절. “OpenStack Database-as-a-Service(trove)”
1.2.1. OpenStack Block Storage(cinder)
OpenStack 블록 스토리지는 가상 하드 드라이브를 위한 영구 블록 스토리지 관리를 제공합니다. 블록 스토리지를 사용하면 사용자가 블록 장치를 생성 및 삭제하고, 서버에 대한 블록 장치의 연결을 관리할 수 있습니다.
장치의 실제 연결 및 분리는 Compute 서비스와의 통합을 통해 처리됩니다. 지역 및 영역을 사용하여 분산 블록 스토리지 호스트를 처리할 수 있습니다.
데이터베이스 스토리지 또는 확장 가능한 파일 시스템과 같은 성능에 민감한 시나리오에서 Block Storage를 사용할 수 있습니다. 원시 블록 수준 스토리지에 액세스할 수 있는 서버로 사용할 수도 있습니다. 또한 볼륨 스냅샷을 사용하여 데이터를 복원하거나 새 블록 스토리지 볼륨을 생성할 수 있습니다. 스냅샷은 드라이버 지원에 따라 다릅니다.
OpenStack 블록 스토리지의 장점은 다음과 같습니다.
- 볼륨 및 스냅샷 생성, 나열 및 삭제.
- 실행 중인 가상 머신에 볼륨 연결 및 분리.
볼륨, 스케줄러, API와 같은 주요 블록 스토리지 서비스는 프로덕션 환경에 공동 배치될 수 있지만, 볼륨 서비스 인스턴스를 하나 이상의 API 및 스케줄러 서비스와 함께 배포하는 것이 더 일반적입니다.
Component | 설명 |
---|---|
openstack-cinder-api | 요청에 응답하고 메시지 큐에 배치합니다. 요청이 수신되면 API 서비스는 ID 요구 사항이 충족되었는지 확인하고 요청을 필요한 블록 스토리지 작업이 포함된 메시지로 변환합니다. 그런 다음 다른 블록 스토리지 서비스에서 처리하기 위해 메시지가 메시지 브로커로 전송됩니다. |
openstack-cinder-backup | 블록 스토리지 볼륨을 외부 스토리지 리포지토리에 백업합니다. 기본적으로 OpenStack에서는 Object Storage 서비스를 사용하여 백업을 저장합니다. Ceph 또는 NFS 백엔드를 백업용 스토리지 리포지토리로 사용할 수도 있습니다. |
openstack-cinder-scheduler | 작업을 큐에 할당하고 프로비저닝 볼륨 서버를 결정합니다. 스케줄러 서비스는 메시지 큐에서 요청을 읽고 요청된 작업을 수행할 블록 스토리지 호스트를 결정합니다. 그런 다음 스케줄러는 선택한 호스트에서 openstack-cinder-volume 서비스와 통신하여 요청을 처리합니다. |
openstack-cinder-volume | 가상 머신의 스토리지를 지정합니다. 볼륨 서비스는 block-storage 장치와의 상호 작용을 관리합니다. 요청이 스케줄러에서 도착하면 볼륨 서비스에서 볼륨을 생성, 수정 또는 제거할 수 있습니다. 볼륨 서비스에는 NFS, Red Hat Storage 또는 Dell EqualLogic과 같은 블록 스토리지 장치와 상호 작용하는 여러 드라이버가 포함되어 있습니다. |
cinder | 블록 스토리지 API에 액세스하는 명령줄 클라이언트입니다. |
다음 다이어그램에서는 블록 스토리지 API, 스케줄러, 볼륨 서비스 및 기타 OpenStack 구성 요소 간의 관계를 보여줍니다.
1.2.2. OpenStack Object Storage(swift)
오브젝트 스토리지는 비디오, 이미지, 이메일 메시지, 파일 또는 VM 이미지와 같은 정적 엔터티를 포함하여 대량의 데이터에 액세스할 수 있는 HTTP 액세스 가능한 스토리지 시스템을 제공합니다. 오브젝트는 각 파일의 확장 속성에 저장된 메타데이터와 함께 기본 파일 시스템의 바이너리로 저장됩니다.
Object Storage 분산 아키텍처는 수평 확장과 소프트웨어 기반 데이터 복제를 통한 페일오버 중복을 지원합니다. 서비스는 비동기 및 최종 일관성 복제를 지원하므로 여러 데이터 센터 배포에서 사용할 수 있습니다.
OpenStack Object Storage의 장점은 다음과 같습니다.
- 스토리지 복제본은 중단 시 오브젝트 상태를 유지합니다. 최소 3개의 복제본을 사용하는 것이 좋습니다.
- 스토리지 영역 호스트 복제본. 영역을 사용하면 지정된 오브젝트의 각 복제본을 별도로 저장할 수 있습니다. 영역은 개별 디스크 드라이브, 배열, 서버, 서버 랙 또는 전체 데이터 센터를 나타낼 수 있습니다.
- 스토리지 리전은 위치별로 영역을 그룹화할 수 있습니다. 지역에는 일반적으로 동일한 지역에 있는 서버 또는 서버 리전이 포함될 수 있습니다. 지역에는 각 Object Storage 서비스 설치에 대해 별도의 API 끝점이 있어 서비스를 분리할 수 있습니다.
오브젝트 스토리지에서는 데이터베이스 및 구성 파일로 사용되는 링 .gz
파일을 사용합니다. 이러한 파일에는 저장된 엔터티의 모든 스토리지 장치 및 각 파일의 물리적 위치에 대한 매핑이 포함되어 있습니다. 따라서 링 파일을 사용하여 특정 데이터의 위치를 결정할 수 있습니다. 각 오브젝트, 계정 및 컨테이너 서버에는 고유한 링 파일이 있습니다.
오브젝트 스토리지 서비스는 다른 OpenStack 서비스 및 구성 요소를 사용하여 작업을 수행합니다. 예를 들어 ID 서비스(keystone), rsync 데몬 및 로드 밸런서가 모두 필요합니다.
Component | 설명 |
---|---|
openstack-swift-account | 계정 데이터베이스를 사용하여 컨테이너 목록을 처리합니다. |
openstack-swift-container | 컨테이너 데이터베이스를 사용하여 특정 컨테이너에 포함된 오브젝트 목록을 처리합니다. |
openstack-swift-object | 오브젝트를 저장, 검색 및 삭제합니다. |
openstack-swift-proxy | 공용 API를 노출하고, 인증을 제공하며, 요청을 라우팅합니다. 오브젝트는 프록시 서버를 통해 스풀링 없이 사용자로 스트리밍됩니다. |
swift | 오브젝트 스토리지 API에 액세스하는 명령줄 클라이언트입니다. |
하우스키핑 | components | 설명 |
---|---|---|
감사 |
| Object Storage 계정, 컨테이너 및 오브젝트의 무결성을 확인하고 데이터 손상으로부터 보호하는 데 도움이 됩니다. |
복제 |
| 가비지 컬렉션을 포함하여 Object Storage 클러스터 전체에서 일관되고 사용 가능한 복제를 보장합니다. |
업데이트 |
| 실패한 업데이트를 식별하고 재시도합니다. |
다음 다이어그램에서는 오브젝트 스토리지에서 다른 OpenStack 서비스, 데이터베이스 및 브로커와 상호 작용하는 데 사용하는 주요 인터페이스를 보여줍니다.
1.2.3. OpenStack Database-as-a-Service(trove)
DEPRECATION NOTICE: Red Hat OpenStack Platform 10부터 OpenStack Trove 서비스는 더 이상 Red Hat OpenStack Platform 배포에 포함되지 않습니다. Red Hat은 신뢰할 수 있는 파트너와 협력하여 고객에게 프로덕션 준비 DBaaS 서비스를 제공하고 있습니다. 이 옵션에 대한 자세한 내용은 영업 계정 관리자에게 문의하십시오.
이 기능은 이번 릴리스에서 기술 프리뷰로 제공되므로 Red Hat에서 완전히 지원되지 않습니다. 테스트 용도로만 사용해야 하며 프로덕션 환경에 배포해서는 안 됩니다. 기술 프리뷰 기능에 대한 자세한 내용은 적용 범위 상세 정보를 참조하십시오.
OpenStack Database-as-a-Service를 사용하면 다양한 관계형 및 비관계형 데이터베이스를 선택, 프로비저닝 및 운영하고 더 복잡한 데이터베이스 관리 작업을 즉시 처리할 수 있습니다.
OpenStack Database-as-a-Service 이점은 다음과 같습니다.
- 사용자와 데이터베이스 관리자는 클라우드에서 여러 데이터베이스 인스턴스를 프로비저닝하고 관리할 수 있습니다.
- 배포, 구성, 패치 적용, 백업, 복원 및 모니터링과 같은 복잡한 관리 작업을 자동화하는 동안 고성능 리소스 격리.
Component | 설명 |
---|---|
openstack-trove-api | Database-as-a-Service 인스턴스를 프로비저닝하고 관리하기 위해 JSON 및 XML을 지원하는 RESTful API입니다. |
openstack-trove-conductor | 호스트에서 를 실행하여 호스트의 정보를 업데이트하는 요청이 있는 게스트 인스턴스에서 메시지를 받습니다. 요청에는 인스턴스 상태 또는 백업의 현재 상태가 포함될 수 있습니다. openstack-trove-conductor를 사용하면 게스트 인스턴스에 호스트 데이터베이스에 직접 연결할 필요가 없습니다. 서비스는 메시지 버스를 통해 RPC 메시지를 수신하고 요청된 작업을 수행합니다. |
openstack-trove-guestagent | 게스트 인스턴스에서 를 실행하여 호스트 데이터베이스에서 직접 작업을 관리하고 수행합니다. openstack-trove-guestagent는 메시지 버스를 통해 RPC 메시지를 수신하고 요청된 작업을 수행합니다. |
openstack-trove-taskmanager | 인스턴스 프로비저닝, 인스턴스 라이프사이클 관리, 데이터베이스 인스턴스의 작업 관리 등의 작업을 담당합니다. |
Trove | Database-as-a-Service API에 액세스하는 명령줄 클라이언트입니다. |
다음 다이어그램은 Database-as-a-Service와 기타 OpenStack 서비스 간의 관계를 보여줍니다.
- OpenStack Database-as-a-Service는 기본 OpenStack 채널에서 사용할 수 있지만 구성 요소를 수동으로 설치하고 구성해야 합니다.
1.3. 가상 머신, 이미지 및 템플릿
1.3.1절. “OpenStack Compute(nova)”
1.3.2절. “OpenStack Bare Metal Provisioning(ironic)”
1.3.3절. “OpenStack Image(glance)”
1.3.4절. “OpenStack Orchestration(heat)”
1.3.5절. “OpenStack Data Processing(sahara)”
1.3.1. OpenStack Compute(nova)
OpenStack Compute는 필요에 따라 가상 머신을 제공하여 OpenStack 클라우드의 핵심 역할을 합니다. 컴퓨팅은 기본 가상화 메커니즘과 상호 작용하는 드라이버를 정의하고 기능을 다른 OpenStack 구성 요소에 노출하여 일련의 노드에서 실행되도록 가상 머신을 예약합니다.
Compute는 KVM을 하이퍼바이저로 사용하는 libvirt 드라이버 libvirtd 를 지원합니다. 하이퍼바이저는 가상 머신을 생성하고 노드에서 노드로 실시간 마이그레이션할 수 있습니다. 베어 메탈 머신을 프로비저닝하려면 1.3.2절. “OpenStack Bare Metal Provisioning(ironic)” 을 사용할 수도 있습니다.
계산은 ID 서비스와 상호 작용하여 인스턴스 및 데이터베이스 액세스를 인증하고 이미지 서비스에 액세스하여 인스턴스를 시작하고 대시보드 서비스와 함께 사용자 및 관리 인터페이스를 제공합니다.
프로젝트 및 사용자별 이미지에 대한 액세스를 제한하고 단일 사용자가 생성할 수 있는 인스턴스 수와 같은 프로젝트 및 사용자 할당량을 지정할 수 있습니다.
Red Hat OpenStack Platform 클라우드를 배포할 때 다른 카테고리에 따라 클라우드를 중단할 수 있습니다.
- 리전
ID 서비스에서 카탈로그화된 각 서비스는 일반적으로 지리적 위치와 서비스 엔드포인트를 나타내는 서비스 리전에 의해 식별됩니다. 여러 컴퓨팅 노드가 있는 클라우드에서 리전을 사용하면 서비스를 분리할 수 있습니다.
또한 높은 수준의 장애 허용을 유지하면서 리전을 사용하여 Compute 설치 간에 인프라를 공유할 수도 있습니다.
- 셀 (기술 프리뷰)
컴퓨팅 호스트는 셀이라는 그룹으로 분할하여 대규모 배포 또는 지리적으로 별도의 설치를 처리할 수 있습니다. 셀은 API 셀이라는 최상위 셀에서 nova-api 서비스를 실행하지만 nova-compute 서비스가 실행되지 않는 트리로 구성됩니다.
트리의 각 하위 셀은 nova-api 서비스가 아닌 다른 모든 nova-* 서비스를 실행합니다. 각 셀에는 별도의 메시지 큐 및 데이터베이스 서비스가 있으며 API 셀과 하위 셀 간의 통신을 관리하는 nova-cells 서비스도 실행합니다.
셀의 장점은 다음과 같습니다.
- 단일 API 서버를 사용하여 여러 컴퓨팅 설치에 대한 액세스를 제어할 수 있습니다.
- 호스트 스케줄링과 달리 가상 시스템을 실행할 때 보다 높은 유연성과 제어 기능을 제공하는 셀 수준의 스케줄링을 추가로 사용할 수 있습니다.
이 기능은 이번 릴리스에서 기술 프리뷰로 제공되므로 Red Hat에서 완전히 지원되지 않습니다. 테스트 용도로만 사용해야 하며 프로덕션 환경에 배포해서는 안 됩니다. 기술 프리뷰 기능에 대한 자세한 내용은 적용 범위 상세 정보를 참조하십시오.
- 호스트 집계 및 가용 영역
단일 Compute 배포를 논리 그룹으로 분할할 수 있습니다. 스토리지 및 네트워크와 같은 공통 리소스 또는 신뢰할 수 있는 컴퓨팅 하드웨어와 같은 특수 속성을 공유하는 여러 호스트 그룹을 생성할 수 있습니다.
관리자에게 이 그룹은 할당된 컴퓨팅 노드 및 관련 메타데이터가 있는 호스트 집계로 제공됩니다. 호스트 집계 메타데이터는 일반적으로 특정 플레이버 또는 이미지를 호스트 서브 세트로 제한하는 등 openstack-nova-scheduler 작업에 대한 정보를 제공하는 데 사용됩니다.
사용자에게 그룹은 가용성 영역으로 표시됩니다. 사용자는 그룹 메타데이터를 보거나 영역의 호스트 목록을 볼 수 없습니다.
집계 또는 영역의 이점은 다음과 같습니다.
- 로드 밸런싱 및 인스턴스 배포.
- 별도의 전원 공급 장치 또는 네트워크 장비로 구현된 영역 간 물리적 격리와 중복성.
- 공통 속성이 있는 서버 그룹에 레이블을 지정합니다.
- 다양한 종류의 하드웨어 분리.
Component | 설명 |
---|---|
openstack-nova-api | 요청을 처리하고 인스턴스 부팅과 같은 Compute 서비스에 대한 액세스를 제공합니다. |
openstack-nova-cert | 인증서 관리자를 제공합니다. |
openstack-nova-compute | 각 노드에서 를 실행하여 가상 인스턴스를 생성하고 종료합니다. 계산 서비스는 하이퍼바이저와 상호 작용하여 새 인스턴스를 시작하고 Compute 데이터베이스에서 인스턴스 상태가 유지 관리되도록 합니다. |
openstack-nova-conductor | 보안 위험을 줄이기 위해 컴퓨팅 노드에 대한 데이터베이스 액세스 지원을 제공합니다. |
openstack-nova-consoleauth | 콘솔 인증을 처리합니다. |
openstack-nova-network | OpenStack Networking의 대안으로 사용될 수 있고 개인 및 공용 액세스를 위한 기본 네트워크 트래픽을 처리할 수 있는 네트워크 서비스입니다. OpenStack Networking 및 Compute Networking 비교는 2장. 네트워킹 In-Depth 에서 참조하십시오. |
openstack-nova-novncproxy | VNC 콘솔을 통해 가상 머신에 액세스할 수 있는 브라우저에 VNC 프록시를 제공합니다. |
openstack-nova-scheduler | 구성된 가중치 및 필터를 기반으로 새 가상 머신에 대한 요청을 올바른 노드에 디스패치합니다. |
Nova | Compute API에 액세스할 명령줄 클라이언트입니다. |
다음 다이어그램에서는 Compute 서비스와 기타 OpenStack 구성 요소 간의 관계를 보여줍니다.
1.3.2. OpenStack Bare Metal Provisioning(ironic)
OpenStack Bare Metal Provisioning을 사용하면 사용자가 하드웨어별 드라이버가 있는 다양한 하드웨어 벤더에 대해 물리적 또는 베어 메탈 시스템을 프로비저닝할 수 있습니다. 베어 메탈 프로비저닝은 컴퓨팅 서비스와 통합되어 가상 머신이 프로비저닝되는 것과 동일한 방식으로 베어 메탈 머신을 프로비저닝하고 베어 메탈-전문 테넌트 사용 사례에 대한 솔루션을 제공합니다.
OpenStack Baremetal 프로비저닝 이점은 다음과 같습니다.
- Cryostat 클러스터는 베어 메탈 머신에 배포할 수 있습니다.
- 하이퍼스케일 및 고성능 컴퓨팅(HPC) 클러스터를 배포할 수 있습니다.
- 가상 머신에 민감한 애플리케이션에 대한 데이터베이스 호스팅을 사용할 수 있습니다.
베어 메탈 프로비저닝은 예약 및 할당량 관리에 Compute 서비스를 사용하고 인증에 ID 서비스를 사용합니다. KVM 대신 베어 메탈 프로비저닝을 지원하도록 인스턴스 이미지를 구성해야 합니다.
다음 다이어그램에서는 물리 서버가 프로비저닝될 때 Ironic 및 기타 OpenStack 서비스가 상호 작용하는 방법을 보여줍니다.
Component | 설명 |
---|---|
openstack-ironic-api | 요청을 처리하고 베어 메탈 노드의 컴퓨팅 리소스에 대한 액세스를 제공합니다. |
openstack-ironic-conductor | 하드웨어 및 ironic 데이터베이스와 직접 상호 작용하고 요청 및 주기적인 작업을 처리합니다. 다양한 하드웨어 드라이버와 상호 작용하기 위해 여러 실행자를 생성할 수 있습니다. |
Ironic | 베어 메탈 프로비저닝 API에 액세스하는 명령줄 클라이언트입니다. |
Ironic API는 다음 다이어그램에 설명되어 있습니다.
1.3.3. OpenStack Image(glance)
OpenStack Image는 가상 디스크 이미지의 레지스트리 역할을 합니다. 사용자는 새 이미지를 추가하거나 기존 서버의 스냅샷을 생성하여 즉시 저장할 수 있습니다. 백업 또는 새 서버의 템플릿으로 스냅샷을 사용할 수 있습니다.
등록된 이미지는 Object Storage 서비스 또는 간단한 파일 시스템 또는 외부 웹 서버와 같은 다른 위치에 저장할 수 있습니다.
지원되는 이미지 디스크 형식은 다음과 같습니다.
- Aki/ami/ari(Amazon 커널, 램디스크 또는 머신 이미지)
- ISO (CD와 같은 광 디스크용 아카이브 형식)
- qcow2(Qemu/KVM, 쓰기 시 복사 지원)
- raw (정정되지 않은 형식)
- VHD (VMware, Cryostat, Microsoft 및 Cryostat와 같은 공급업체의 가상 머신 모니터에 공통되는 Hyper-V)
- VDI(Qemu/VirtualBox)
- vmdk (VMware)
컨테이너 형식은 이미지 서비스에서 등록할 수도 있습니다. 컨테이너 형식은 이미지에 저장할 가상 머신 메타데이터의 유형 및 세부 수준을 결정합니다.
지원되는 컨테이너 형식은 다음과 같습니다.
- bare (Metadata 없음)
- OVA(OVA tar 아카이브)
- OVF (OVF 형식)
- Aki/ami/ari(Amazon 커널, 램디스크 또는 머신 이미지)
Component | 설명 |
---|---|
openstack-glance-api | 스토리지 백엔드와 상호 작용하여 이미지 검색 및 스토리지에 대한 요청을 처리합니다. API는 openstack-glance-registry를 사용하여 이미지 정보를 검색합니다. 레지스트리 서비스에 직접 액세스해서는 안 됩니다. |
openstack-glance-registry | 각 이미지의 모든 메타데이터를 관리합니다. |
glance | 이미지 API에 액세스하는 명령줄 클라이언트입니다. |
다음 다이어그램은 이미지 서비스에서 이미지 데이터베이스에서 이미지를 등록하고 검색하는 데 사용하는 기본 인터페이스를 보여줍니다.
1.3.4. OpenStack Orchestration(heat)
OpenStack Orchestration에서는 스토리지, 네트워킹, 인스턴스 또는 애플리케이션과 같은 클라우드 리소스를 생성하고 관리하는 템플릿을 제공합니다. 템플릿은 리소스 컬렉션인 스택을 만드는 데 사용됩니다.
예를 들어 인스턴스, 유동 IP, 볼륨, 보안 그룹 또는 사용자에 대한 템플릿을 생성할 수 있습니다. 오케스트레이션은 단일 모듈식 템플릿과 자동 확장 및 기본 고가용성과 같은 기능을 통해 모든 OpenStack 핵심 서비스에 액세스할 수 있습니다.
OpenStack 오케스트레이션 이점은 다음과 같습니다.
- 단일 템플릿은 모든 기본 서비스 API에 대한 액세스를 제공합니다.
- 템플릿은 모듈식 및 리소스 지향입니다.
- 중첩된 스택과 같이 템플릿을 재귀적으로 정의하고 재사용할 수 있습니다. 그런 다음 클라우드 인프라를 모듈식으로 정의하고 재사용할 수 있습니다.
- 리소스 구현은 플러그 가능하므로 사용자 정의 리소스를 사용할 수 있습니다.
- 리소스는 자동으로 확장될 수 있으므로 사용법에 따라 클러스터에서 리소스를 추가하거나 제거할 수 있습니다.
- 기본 고가용성 기능을 사용할 수 있습니다.
Component | 설명 |
---|---|
openstack-heat-api | RPC를 통해 openstack-heat-engine 서비스로 요청을 전송하여 API 요청을 처리하는 openstack-native REST API. |
openstack-heat-api-cfn | RPC를 통해 openstack-heat-engine 서비스로 요청을 전송하여 API 요청을 처리하는 AWS CloudFormation과 호환되는 선택적 AWS-Query API입니다. |
openstack-heat-engine | 템플릿 시작을 오케스트레이션하고 API 소비자에 대한 이벤트를 생성합니다. |
openstack-heat-cfntools | 메타데이터 업데이트를 처리하고 사용자 정의 후크를 실행하는 cfn-hup과 같은 도우미 스크립트 패키지. |
Heat | AWS CloudFormation API를 실행하기 위해 오케스트레이션 API와 통신하는 명령줄 툴입니다. |
다음 다이어그램은 오케스트레이션 서비스에서 두 개의 새 인스턴스와 로컬 네트워크의 새 스택을 생성하는 데 사용하는 기본 인터페이스를 보여줍니다.
1.3.5. OpenStack Data Processing(sahara)
OpenStack Data Processing을 사용하면 OpenStack에서 Cryostat 클러스터를 프로비저닝하고 관리할 수 있습니다. HDFS는 클러스터에서 대량의 비정형 및 구조화된 데이터를 저장하고 분석합니다.
HDFS 클러스터는 HDFS(Distributed File System)를 실행하는 스토리지 서버, HDFS(MR) 프레임워크를 실행하는 컴퓨팅 서버 또는 둘 다로 작동할 수 있는 서버 그룹입니다.
HDFS 클러스터의 서버는 동일한 네트워크에 있어야 하지만 메모리 또는 디스크를 공유할 필요는 없습니다. 따라서 기존 서버의 호환성에 영향을 주지 않고 서버와 클러스터를 추가하거나 제거할 수 있습니다.
HDFS 컴퓨팅 및 스토리지 서버가 함께 배치되어 저장된 데이터를 고속으로 분석할 수 있습니다. 모든 작업은 서버 간에 분할되고 로컬 서버 리소스를 활용합니다.
OpenStack Data Processing 이점은 다음과 같습니다.
- ID 서비스는 사용자를 인증하고 HDFS 클러스터에서 사용자 보안을 제공할 수 있습니다.
- 컴퓨팅 서비스는 클러스터 인스턴스를 프로비저닝할 수 있습니다.
- 이미지 서비스는 각 인스턴스에 운영 체제 및 HDFS가 포함된 클러스터 인스턴스를 저장할 수 있습니다.
- Object Storage 서비스를 사용하여 Cryostat 작업에서 처리하는 데이터를 저장할 수 있습니다.
- 템플릿을 사용하여 클러스터를 생성하고 구성할 수 있습니다. 사용자는 사용자 지정 템플릿을 생성하거나 클러스터 생성 중에 매개변수를 재정의하여 구성 매개변수를 변경할 수 있습니다. 노드는 노드 그룹 템플릿을 사용하여 함께 그룹화되며 클러스터 템플릿은 노드 그룹을 결합합니다.
- jobs는 HDFS 클러스터에서 작업을 실행하는 데 사용할 수 있습니다. 작업 바이너리는 실행 가능한 코드를 저장하고 데이터 소스는 입력 또는 출력 위치와 필요한 인증 정보를 저장합니다.
데이터 처리는 Cloudera (CDH) 및 Hortonworks Data Platform (HDP) 배포뿐만 아니라 Apache Ambari와 같은 벤더별 관리 도구를 지원합니다. OpenStack 대시보드 또는 명령줄 툴을 사용하여 클러스터를 프로비저닝하고 관리할 수 있습니다.
Component | 설명 |
---|---|
openstack-sahara-all | API 및 엔진 서비스를 처리하는 기존 패키지입니다. |
openstack-sahara-api | API 요청을 처리하고 데이터 처리 서비스에 대한 액세스를 제공합니다. |
openstack-sahara-engine | 클러스터 요청 및 데이터 전달을 처리하는 프로비저닝 엔진입니다. |
Sahara | 데이터 처리 API에 액세스하는 명령줄 클라이언트입니다. |
다음 다이어그램에서는 Data Processing 서비스에서 HDFS 클러스터를 프로비저닝하고 관리하는 데 사용하는 주요 인터페이스를 보여줍니다.
1.4. IdM (Identity Management)
1.4.1. OpenStack Identity(keystone)
OpenStack Identity는 모든 OpenStack 구성 요소에 대한 사용자 인증 및 권한 부여를 제공합니다. ID는 사용자 이름 및 암호 자격 증명, 토큰 기반 시스템 및 AWS 스타일 로그를 포함한 여러 인증 메커니즘을 지원합니다.
기본적으로 ID 서비스는 토큰, 카탈로그, 정책 및 ID 정보에 MariaDB 백엔드를 사용합니다. 이 백엔드는 개발 환경 또는 소규모 사용자 세트를 인증하는 것이 좋습니다. LDAP 및 SQL과 같은 여러 ID 백엔드를 동시에 사용할 수도 있습니다. 토큰 지속성을 위해 memcache 또는 Redis를 사용할 수도 있습니다.
ID는 SAML을 사용한 페더레이션을 지원합니다. 페더레이션 ID는 ID 공급자(IdP)와 ID가 최종 사용자에게 제공하는 서비스 간에 신뢰를 설정합니다.
페더레이션 ID 및 동시 다중 백엔드에는 Eventlet 배포 대신 ID API v3 및 Apache HTTPD 배포가 필요합니다.
OpenStack ID의 장점은 다음과 같습니다.
- 이름 및 암호와 같은 관련 정보를 포함한 사용자 계정 관리 사용자 지정 사용자 외에도 각 카탈로그 서비스에 대해 사용자를 정의해야 합니다. 예를 들어 glance 사용자는 이미지 서비스에 대해 정의해야 합니다.
- 테넌트 또는 프로젝트, 관리. 테넌트는 사용자 그룹, 프로젝트 또는 조직일 수 있습니다.
- 역할 관리. 역할에 따라 사용자 권한이 결정됩니다. 예를 들어 역할은 영업 담당자의 권한과 관리자 권한 간에 다를 수 있습니다.
- 도메인 관리. 도메인은 ID 서비스 엔티티의 관리 경계를 결정하고, 도메인이 사용자, 그룹 및 테넌트의 그룹을 나타내는 다중 테넌시를 지원합니다. 도메인에는 두 개 이상의 테넌트가 있을 수 있으며 동시 ID 공급자를 여러 개 사용하는 경우 각 공급자에는 하나의 도메인이 있습니다.
Component | 설명 |
---|---|
openstack-keystone | 관리 및 공용 API와 함께 ID 서비스를 제공합니다. ID API v2 및 API v3 모두 지원됩니다. |
Keystone | ID API에 액세스하는 명령줄 클라이언트입니다. |
다음 다이어그램에서는 ID가 다른 OpenStack 구성 요소를 사용하여 사용자를 인증하는 데 사용하는 기본 인증 흐름을 보여줍니다.
1.5. 사용자 인터페이스
1.5.1절. “OpenStack Dashboard(horizon)”
1.5.2절. “OpenStack Telemetry(ceilometer)”
1.5.1. OpenStack Dashboard(horizon)
OpenStack 대시보드는 사용자 및 관리자가 인스턴스 생성 및 시작, 네트워킹 관리, 액세스 제어 설정 등의 작업을 수행할 수 있는 그래픽 사용자 인터페이스를 제공합니다.
대시보드 서비스는 프로젝트, 관리자 및 설정 기본 대시보드를 제공합니다. 모듈식 설계를 통해 대시보드는 청구, 모니터링 및 추가 관리 툴과 같은 다른 제품과 상호 작용할 수 있습니다.
다음 이미지는 관리 대시보드의 Compute 패널의 예를 보여줍니다.
대시보드에 로그인하는 사용자의 역할에 따라 사용 가능한 대시보드 및 패널이 결정됩니다.
Component | 설명 |
---|---|
openstack-dashboard | 모든 웹 브라우저에서 대시보드에 대한 액세스를 제공하는 Django 웹 애플리케이션입니다. |
Apache HTTP 서버(httpd 서비스) | 애플리케이션을 호스팅합니다. |
다음 다이어그램은 대시보드 아키텍처의 개요를 보여줍니다.
이 예제에서는 다음과 같은 상호 작용을 보여줍니다.
- OpenStack ID 서비스는 사용자를 인증하고 권한을 부여합니다.
- 세션 백엔드는 데이터베이스 서비스를 제공합니다.
- httpd 서비스는 API 호출을 위해 웹 애플리케이션 및 기타 모든 OpenStack 서비스를 호스팅합니다.
1.5.2. OpenStack Telemetry(ceilometer)
OpenStack Telemetry는 OpenStack 기반 클라우드에 대한 사용자 수준 사용 데이터를 제공합니다. 데이터는 고객 청구, 시스템 모니터링 또는 알림에 사용할 수 있습니다. Telemetry는 Compute 사용 이벤트와 같은 기존 OpenStack 구성 요소에서 전송한 알림에서 데이터를 수집하거나 libvirt와 같은 OpenStack 인프라 리소스를 폴링하여 데이터를 수집할 수 있습니다.
Telemetry에는 데이터를 수집하고 집계하기 위해 신뢰할 수 있는 메시징 시스템을 통해 인증된 에이전트와 통신하는 스토리지 데몬이 포함되어 있습니다. 또한 서비스는 새 모니터를 추가하는 데 사용할 수 있는 플러그인 시스템을 사용합니다. 다른 호스트에 API 서버, 중앙 에이전트, 데이터 저장소 서비스 및 수집기 에이전트를 배포할 수 있습니다.
서비스는 MongoDB 데이터베이스를 사용하여 수집된 데이터를 저장합니다. 수집기 에이전트와 API 서버만 데이터베이스에 액세스할 수 있습니다.
Component | 설명 |
---|---|
openstack-ceilometer-alarm-evaluator | 경보에서 상태 전환을 트리거합니다. |
openstack-ceilometer-alarm-notifier | 경고가 트리거되면 작업을 실행합니다. |
openstack-ceilometer-api | 하나 이상의 중앙 관리 서버에서 실행하여 데이터베이스의 데이터에 대한 액세스를 제공합니다. |
openstack-ceilometer-central | 중앙 관리 서버에서 를 실행하여 인스턴스 또는 컴퓨팅 노드와 독립적인 리소스에 대한 사용률 통계를 폴링합니다. 에이전트는 수평으로 확장할 수 없으므로 한 번에 이 서비스의 단일 인스턴스만 실행할 수 있습니다. |
openstack-ceilometer-collector | 하나 이상의 중앙 관리 서버에서 를 실행하여 메시지 큐를 모니터링합니다. 각 컬렉터는 알림 메시지를 처리하고 Telemetry 메시지로 변환하고 관련 주제를 사용하여 메시지를 메시지 버스로 다시 보냅니다. 원격 분석 메시지는 수정하지 않고 데이터 저장소에 작성됩니다. ceilometer-alarm-evaluator 서비스와 유사하게 모든 intra-agent 통신은 ceilometer-api 서비스에 대한 AMQP 또는 REST 호출을 기반으로 하므로 이러한 에이전트를 실행할 위치를 선택할 수 있습니다. |
openstack-ceilometer-compute | 각 컴퓨팅 노드에서 를 실행하여 리소스 사용률 통계를 폴링합니다. 각 nova-compute 노드에는 ceilometer-compute 에이전트가 배포되어 실행되고 있어야 합니다. |
openstack-ceilometer-notification | 다양한 OpenStack 서비스에서 수집기 서비스로 지표를 푸시합니다. |
ceilometer | Telemetry API에 액세스할 명령줄 클라이언트입니다. |
다음 다이어그램에서는 Telemetry 서비스에서 사용하는 인터페이스를 보여줍니다.
1.6. 타사 구성 요소
1.6.1. 타사 구성 요소
일부 Red Hat OpenStack Platform 구성 요소는 타사 데이터베이스, 서비스 및 툴을 사용합니다.
1.6.1.1. 데이터베이스
- MariaDB는 Red Hat Enterprise Linux와 함께 제공되는 기본 데이터베이스입니다. MariaDB를 통해 Red Hat은 커뮤니티에서 개발한 오픈 소스 소프트웨어를 완벽하게 지원할 수 있습니다. Telemetry를 제외한 각 OpenStack 구성 요소에는 실행 중인 MariaDB 서비스가 필요합니다. 따라서 전체 OpenStack 클라우드 서비스를 배포하기 전에 또는 독립 실행형 OpenStack 구성 요소를 설치하기 전에 MariaDB를 배포해야 합니다.
- Telemetry 서비스는 MongoDB 데이터베이스를 사용하여 수집기 에이전트에서 수집된 사용 데이터를 저장합니다. 수집기 에이전트와 API 서버만 데이터베이스에 액세스할 수 있습니다.
1.6.1.2. 메시징
RabbitMQ는 AMQP 표준을 기반으로 하는 강력한 오픈 소스 메시징 시스템입니다. RabbitMQ는 광범위한 상용 지원이 포함된 많은 엔터프라이즈 시스템에서 사용되는 고성능 메시지 브로커입니다. Red Hat OpenStack Platform에서 RabbitMQ는 기본 메시지 브로커이며 권장되는 메시지 브로커입니다.
RabbitMQ는 대기열, 배포, 보안, 관리, 클러스터링, 페더레이션 등 OpenStack 트랜잭션을 관리합니다. 또한 고가용성 및 클러스터링 시나리오에서 핵심 역할을 수행합니다.
1.6.1.3. 외부 캐싱
memcached 또는 Redis와 같은 캐싱을 위한 외부 애플리케이션은 지속성 및 공유 스토리지를 제공하고 데이터베이스 로드를 줄여 동적 웹 애플리케이션을 가속화합니다. 외부 캐싱은 다양한 OpenStack 구성 요소에서 사용됩니다. 예를 들면 다음과 같습니다.
- 오브젝트 스토리지 서비스는 memcached를 사용하여 각 클라이언트에 각 상호 작용을 다시 인증해야 하는 대신 인증된 클라이언트를 캐시합니다.
- 기본적으로 대시보드는 세션 스토리지에 memcached를 사용합니다.
- ID 서비스는 토큰 지속성을 위해 Redis 또는 memcached를 사용합니다.
2장. 네트워킹 In-Depth
2.1. 기본 네트워킹의 작동 방식
네트워킹은 한 컴퓨터에서 다른 컴퓨터로 정보를 이동하는 것으로 구성됩니다. 가장 기본적인 수준에서는 각각 NIC(네트워크 인터페이스 카드)가 설치된 두 시스템 간에 케이블을 실행하여 수행됩니다. OSI 네트워킹 모델을 검토한 적이 있다면 계층 1입니다.
대화에 두 개 이상의 컴퓨터를 포함하려면 스위치라는 장치를 추가하여 이 구성을 확장해야 합니다. 스위치는 추가 머신을 연결하는 여러 이더넷 포트가 있는 전용 장치입니다. 이러한 구성을 LAN(Local Area Network)이라고 합니다.
스위치는 OSI 모델을 계층 2로 이동하고 하위 계층 1보다 더 많은 지능을 적용합니다. 각 NIC에는 하드웨어에 할당된 고유한 MAC 주소가 있으며 이 번호를 사용하면 동일한 스위치에 연결된 머신을 서로 찾을 수 있습니다.
스위치는 어떤 포트에 연결된 MAC 주소 목록을 유지 관리하여 한 컴퓨터가 다른 컴퓨터에 데이터를 전송하려고 할 때 스위치는 각 NIC가 있는 위치를 알고 네트워크 트래픽을 올바른 대상으로 전달하도록 회로를 조정합니다.
2.1.1. 여러 LAN 연결
두 개의 개별 스위치에서 두 개의 LAN을 사용하는 경우 다음과 같은 방법으로 서로 정보를 공유하도록 연결할 수 있습니다.
- 트렁크 케이블
- 두 스위치를 트렁크 케이블이라고 하는 물리적 케이블과 직접 연결할 수 있습니다. 이 구성에서는 트렁크 케이블의 각 끝을 각 스위치의 포트에 연결한 다음 이러한 포트를 트렁크 포트로 정의합니다. 이제 두 스위치가 하나의 큰 논리 스위치 역할을 하며 연결된 컴퓨터가 서로를 성공적으로 찾을 수 있습니다. 이 옵션은 확장성이 높지 않으며 오버헤드가 더 많은 스위치가 직접 연결할 수 있는 문제가 됩니다.
- 라우터
라우터라는 장치를 사용하여 각 스위치에서 케이블을 연결할 수 있습니다. 결과적으로 라우터는 두 스위치 모두에 구성된 네트워크를 인식합니다. 라우터에 연결하는 각 스위치는 인터페이스가 되어 해당 네트워크의 기본 게이트웨이라고 하는 IP 주소가 할당됩니다. 기본 게이트웨이의 "기본"은 대상 컴퓨터가 데이터 전송 소스와 동일한 LAN에 있지 않은 경우 트래픽이 전송되는 대상임을 의미합니다.
각 컴퓨터에 이 기본 게이트웨이를 설정한 후에는 다른 네트워크의 다른 모든 컴퓨터를 인식하여 트래픽을 보낼 필요가 없습니다. 트래픽은 기본 게이트웨이로만 전송되고 라우터가 해당 게이트웨이를 처리합니다. 라우터는 어떤 네트워크가 어떤 인터페이스에 있는지 알고 있으므로 의도한 대상으로 패킷을 전송할 수 있습니다. 라우팅은 OSI 모델의 계층 3에서 작동하며 IP 주소 및 서브넷과 같은 친숙한 개념을 활용합니다.
이 개념은 인터넷 자체가 어떻게 작동하는지입니다. 서로 다른 조직에서 실행하는 많은 별도의 네트워크는 모두 스위치와 라우터를 사용하여 서로 연결되어 있습니다. 올바른 기본 게이트웨이를 계속 준수하면 트래픽이 결국 이동해야 하는 위치로 이동합니다.
2.1.2. VLAN
VLAN(Virtual Local Area Networks)을 사용하면 동일한 스위치에서 실행되는 컴퓨터에 대한 네트워크 트래픽을 분할할 수 있습니다. 다른 네트워크의 멤버로 포트를 구성하여 전환을 논리적으로 나눌 수 있습니다. 이 구성은 보안을 위해 트래픽을 분리할 수 있는 최소 LAN으로 포트를 설정합니다.
예를 들어 스위치에 포트가 24개인 경우 VLAN200에 속하도록 포트 1-6을 정의할 수 있으며 포트 7-18은 VLAN201에 속합니다. VLAN200에 연결된 컴퓨터는 VLAN201의 컴퓨터와 완전히 분리되어 더 이상 직접 통신할 수 없습니다. 두 VLAN 간의 모든 트래픽은 두 개의 물리적 스위치인 것처럼 라우터를 통과해야 합니다. 방화벽을 사용하여 보안을 강화하여 통신할 수 있는 VLAN을 결정할 수도 있습니다.
2.1.3. 방화벽
방화벽은 IP 라우팅과 동일한 OSI 계층에서 작동합니다. 라우터와 동일한 네트워크 세그먼트에 있으며 모든 네트워크 간의 트래픽을 제어하는 경우가 많습니다. 방화벽은 네트워크에 들어갈 수 있거나 사용할 수 없는 트래픽을 규정하는 사전 정의된 규칙 세트를 사용합니다. 이러한 규칙은 매우 세분화할 수 있습니다. 예를 들어 VLAN 200의 서버가 VLAN201의 컴퓨터와만 통신할 수 있는 규칙을 정의할 수 있으며 목요일에는 트래픽이 웹(HTTP)이고 한 방향으로만 이동하는 규칙을 정의할 수 있습니다.
이러한 규칙을 적용하는 데 도움이 되도록 일부 방화벽은 패킷 내용을 검사하여 패킷의 콘텐츠를 검사하는 SPI(Stateful Packet Inspection)도 수행합니다. 해커는 masquerades를 다른 것으로 전송하여 데이터를 추출하는 것으로 알려져 있으며, SPI는 이러한 위협을 완화하는 데 도움이 되는 한 가지 방법입니다.
2.1.4. 브리지
네트워크 브리지는 OSI 모델의 동일한 레벨 2에서 작동하는 스위치이지만 유일한 기능은 라우터와 유사하게 별도의 네트워크를 연결하는 것입니다.
2.2. OpenStack의 네트워킹
서비스와 구성에 의해 정의되는 경우를 제외하고 OpenStack 클라우드의 모든 기본 네트워킹 개념입니다. 이를 소프트웨어 정의 네트워킹(SDN)이라고 합니다. 가상 스위치(Open vSwitch) 및 라우터(l3-agent)를 사용하면 인스턴스가 서로 통신하고 물리적 네트워크를 사용하여 외부에서 통신할 수 있습니다. Open vSwitch 브리지는 인스턴스에 가상 포트를 할당하고 물리적 네트워크에 걸쳐 확장되어 들어오고 나가는 트래픽을 허용합니다.
2.3. 네트워크 백엔드 선택
Red Hat OpenStack Platform은 Nova 네트워킹(nova-network) 및 OpenStack Networking (neutron)이라는 두 가지 다른 네트워킹 백엔드를 제공합니다.
Nova 네트워킹은 OpenStack 기술 로드맵에서 더 이상 사용되지 않지만 계속 사용할 수 있습니다. OpenStack Networking은 OpenStack 향후 계획 로드맵의 핵심 소프트웨어 정의 네트워킹(SDN) 구성 요소로 간주되며 이를 적극적으로 개발하고 있습니다.
Nova 네트워킹과 OpenStack 네트워킹 사이에는 마이그레이션 경로가 없습니다. 따라서 나중에 Nova 네트워킹을 배포하고 OpenStack Networking으로 마이그레이션하려면 모든 네트워크 및 구성을 수동으로 마이그레이션해야 합니다. 이 마이그레이션으로 인해 네트워크가 중단될 수 있습니다.
2.3.1. OpenStack Networking(neutron)을 선택해야 하는 시기
- 오버레이 네트워크 솔루션이 필요한 경우 OpenStack Networking에서는 가상 머신 트래픽 격리를 위해 GRE 또는 VXLAN 터널링을 지원합니다. GRE 또는 VXLAN의 경우 네트워크 패브릭에는 VLAN 구성이 필요하지 않으며 물리적 네트워크의 유일한 요구 사항은 노드 간에 IP 연결을 제공하는 것입니다. 또한 VXLAN 또는 GRE를 사용하면 802.1q VLAN ID의 4094 제한보다 훨씬 큰 16 만 개의 고유 ID의 이론적인 규모 제한을 사용할 수 있습니다. Nova 네트워킹은 802.1q VLAN에서 네트워크를 분리하고 GRE 또는 VXLAN을 사용한 터널링을 지원하지 않습니다.
- 테넌트 간에 IP 주소가 중복되어야 하는 경우 OpenStack Networking에서는 Linux 커널의 네트워크 네임스페이스 기능을 사용하므로 서로 다른 테넌트가 중복되거나 중단될 위험이 없는 동일한 컴퓨팅 노드에서 동일한 서브넷 범위(예: 192.168.100/24)를 사용할 수 있습니다. 이는 대규모 멀티 테넌시 배포에 권장됩니다. Nova 네트워킹은 모든 테넌트에서 사용하는 서브넷을 염두에 두어야 하는 플랫 토폴로지만 지원합니다.
Red Hat 인증 타사 OpenStack Networking 플러그인이 필요한 경우 기본적으로 Red Hat Enterprise Linux OpenStack Platform 5 이상에서는 OVS(Open vSwitch) 메커니즘 드라이버와 함께 오픈 소스 ML2 코어 플러그인을 사용합니다. 물리적 네트워크 패브릭 및 기타 네트워크 요구 사항을 기반으로 기본 ML2/Open vSwitch 드라이버 대신 타사 OpenStack Networking 플러그인을 배포할 수 있습니다.
참고Red Hat은 Red Hat OpenStack Platform에 대해 더 많은 OpenStack Networking 플러그인을 인증하기 위해 파트너 인증 프로그램을 개선하기 위해 지속적으로 노력하고 있습니다. 인증 프로그램 및 인증된 OpenStack Networking 플러그인에 대한 자세한 내용은 http://marketplace.redhat.com에서 확인할 수 있습니다.
- VPN-as-a-service(VPNaaS), FWaaS( Firewall-as-a-service) 또는 LBaaS(Load-Balancing-as-a-service)가 필요한 경우. 이러한 네트워크 서비스는 OpenStack Networking에서만 사용할 수 있으며 Nova 네트워킹에서는 사용할 수 없습니다. 대시보드를 사용하면 테넌트가 관리자 개입 없이 이러한 서비스를 관리할 수 있습니다.
2.3.2. Nova 네트워킹 선택 시기(nova-network)
- 배포에 flat(태그되지 않음) 또는 VLAN(802.1q 태그) 네트워킹이 필요한 경우 이 유형의 배포에서는 4094 VLAN ID의 이론적인 규모 제한은 일반적으로 물리적 스위치 제한과 관리 및 프로비저닝 요구 사항보다 높기 때문에 스칼라빌리티 요구 사항을 의미합니다. 노드 간에 필요한 VLAN 세트를 트렁크하려면 물리적 네트워크에 특정 구성이 필요합니다.
- 배포에 테넌트 간에 겹치는 IP 주소가 필요하지 않은 경우 일반적으로 소규모 프라이빗 배포에만 권장됩니다.
- 소프트웨어 정의 네트워킹(SDN) 솔루션 또는 물리적 네트워크 패브릭과 상호 작용할 수 있는 기능이 필요하지 않은 경우입니다.
- 셀프 서비스 VPN, 방화벽 또는 로드 밸런싱 서비스가 필요하지 않은 경우
2.4. 고급 OpenStack Networking 개념
2.4.1. 계층 3 고가용성
OpenStack Networking은 가상 네트워킹 구성 요소 호스팅 전용인 물리적 서버인 중앙 집중식 네트워크 노드에서 가상 라우터를 호스팅합니다. 이러한 가상 라우터는 가상 머신 간 트래픽을 전달하며 환경을 지속적으로 연결하는 데 중요합니다. 여러 가지 이유로 인해 물리적 서버에 중단될 수 있으므로 네트워크 노드를 사용할 수 없게 되면 가상 머신이 중단될 수 있습니다.
OpenStack Networking은 계층 3 고가용성을 사용하여 이 취약점을 완화하고 업계 표준 VRRP를 구현하여 가상 라우터 및 유동 IP 주소를 보호합니다. 계층 3 고가용성을 사용하면 테넌트의 가상 라우터가 활성 라우터로 지정된 하나의 라우터와 대기 중인 라우터로 지정된 여러 물리적 네트워크 노드에 무작위로 분산되며, 활성 라우터를 호스팅하는 네트워크 노드가 중단되는 경우 다른 라우터를 사용할 수 있습니다.
"계층 3"은 이 기능이 작동하는 OSI 모델의 섹션을 나타내며 라우팅 및 IP 주소 지정을 보호할 수 있음을 의미합니다.
자세한 내용은 네트워킹 가이드의 "Layer 3 High Availability" 섹션을 참조하십시오.
2.4.2. LBaaS(Load Balancing-as-a-Service)
LBaaS(Load Balancing-as-a-Service)를 사용하면 OpenStack 네트워킹에서 들어오는 네트워크 요청을 지정된 인스턴스 간에 동일하게 배포할 수 있습니다. 이 배포를 통해 인스턴스 간에 워크로드를 공유할 수 있으며 시스템 리소스를 보다 효과적으로 사용할 수 있습니다. 들어오는 요청은 다음 로드 밸런싱 방법 중 하나를 사용하여 배포됩니다.
- 라운드 로빈
- 여러 인스턴스 간에 요청을 균등하게 순환합니다.
- 소스 IP
- 고유한 소스 IP 주소의 요청은 항상 동일한 인스턴스로 이동합니다.
- 최소 연결
- 활성 연결 수가 가장 적은 인스턴스에 요청을 할당합니다.
자세한 내용은 네트워킹 가이드의 "Load Balancing-as-a-Service 구성" 섹션을 참조하십시오.
2.4.3. IPv6
OpenStack Networking은 테넌트 네트워크에서 IPv6 주소를 지원하므로 가상 머신에 IPv6 주소를 동적으로 할당할 수 있습니다. OpenStack Networking은 가상 머신이 기존 DHCP 인프라에서 IPv6 주소를 수신할 수 있도록 물리적 라우터의 SLAAC와도 통합할 수 있습니다.
자세한 내용은 네트워킹 가이드의 "IPv6" 섹션을 참조하십시오.
3장. 설계
이 섹션에서는 Red Hat OpenStack Platform 배포를 설계할 때 수행할 기술 및 운영 고려 사항에 대해 설명합니다.
이 가이드의 모든 아키텍처 예에서는 KVM 하이퍼바이저를 사용하여 Red Hat Enterprise Linux 7.2에 OpenStack Platform을 배포한다고 가정합니다.
3.1. 계획 모델
Red Hat OpenStack Platform 배포를 설계할 때 프로젝트 기간은 배포의 구성 및 리소스 할당에 영향을 미칠 수 있습니다. 각 계획 모델은 다른 목표를 달성하는 것을 목표로 할 수 있으므로 다른 고려 사항이 필요합니다.
3.1.1. 단기 모델 (3 개월)
단기 용량 계획 및 예측을 수행하려면 다음 메트릭의 레코드를 캡처하는 것이 좋습니다.
- 총 vCPU 수
- 총 Cryostat 할당
- I/O 평균 대기 시간
- 네트워크 트래픽
- 컴퓨팅 로드
- 스토리지 할당
vCPU, Cryostat 및 대기 시간 메트릭은 용량 계획에서 가장 쉽게 액세스할 수 있습니다. 이러한 세부 사항을 사용하면 표준 두 번째 순서 회귀를 적용하고 다음 3 개월을 포괄하는 사용 가능한 용량 추정을 받을 수 있습니다. 이 추정치를 사용하여 추가 하드웨어를 배포해야 하는지 여부를 확인합니다.
3.1.2. 중간 기간 모델 (6 개월)
이 모델에는 검토 반복이 필요하며 예측 추세 및 실제 사용량의 차이를 추정해야 합니다. 이 정보는 표준 통계 도구 또는 Nash-Sutcliffe와 같은 특수 분석 모델을 사용하여 분석할 수 있습니다. 또한 추세는 두 번째 순서 회귀를 사용하여 계산할 수 있습니다.
vCPU 및 Cryostat 메트릭을 단일 메트릭으로 처리하면 여러 인스턴스 플레이버가 있는 배포에서 vCPU 및 vCPU 사용량의 상관 관계를 더 쉽게 연결할 수 있습니다.
3.1.3. 장기 모델 (1년)
총 리소스 사용량은 1년 동안 다를 수 있으며 편차는 일반적으로 원래의 장기 용량 추정에서 발생합니다. 따라서 두 번째 순서 회귀는 특히 사용량이 재활용되는 경우 용량 예측에 충분하지 않을 수 있습니다.
장기 배포를 계획할 때 1년 이상 걸쳐 있는 데이터를 기반으로 하는 용량 계획 모델은 최소한 첫 번째 파생 제품에 적합해야 합니다. 사용 패턴에 따라 빈도 분석이 필요할 수도 있습니다.
3.2. 컴퓨팅 리소스
컴퓨팅 리소스는 OpenStack 클라우드의 핵심입니다. 따라서 Red Hat OpenStack Platform 배포를 설계할 때 물리적 및 가상 리소스 할당, 배포, 페일오버 및 추가 장치를 고려하는 것이 좋습니다.
3.2.1. 일반 고려 사항
- 각 하이퍼바이저의 프로세서, 메모리 및 스토리지 수
프로세서 코어 및 스레드의 수는 컴퓨팅 노드에서 실행할 수 있는 작업자 스레드 수에 직접적인 영향을 미칩니다. 따라서 서비스를 기반으로 설계를 결정하고 모든 서비스에 대해 균형 있는 인프라를 기반으로 해야 합니다.
워크로드 프로필에 따라 나중에 클라우드에 추가 컴퓨팅 리소스 풀을 추가할 수 있습니다. 경우에 따라 특정 인스턴스 플레이버의 요구가 개별 하드웨어 설계를 무효화하지 않을 수 있으며, 대신 상품화된 시스템을 선호하는 경우가 있습니다.
두 경우 모두 공통 인스턴스 요청을 서비스할 수 있는 하드웨어 리소스를 할당하여 설계를 시작합니다. 전체 아키텍처에 하드웨어 설계를 추가하려는 경우 나중에 이 작업을 수행할 수 있습니다.
- 프로세서 유형
프로세서 선택은 특히 다른 프로세서의 기능과 성능 특성을 비교할 때 하드웨어 설계에서 매우 중요한 고려 사항입니다.
프로세서는 하드웨어 지원 가상화 및 메모리 페이징 또는 EPT 섀도우팅 기술과 같은 가상화된 컴퓨팅 호스트를 위한 특정 기능을 포함할 수 있습니다. 이러한 기능은 클라우드 VM의 성능에 큰 영향을 미칠 수 있습니다.
- 리소스 노드
- 클라우드의 하이퍼바이저가 아닌 리소스 노드의 Compute 요구 사항을 고려해야 합니다. 리소스 노드에는 Object Storage, Block Storage 및 Networking 서비스를 실행하는 컨트롤러 노드와 노드가 포함됩니다.
- 리소스 풀
필요에 따라 여러 리소스 풀을 할당하는 Compute 설계를 사용합니다. 이 설계는 클라우드에서 애플리케이션 리소스 사용량을 극대화합니다. 각 리소스 풀은 특정 인스턴스 플레이버 또는 플레이버 그룹을 서비스해야 합니다.
여러 리소스 풀을 설계하면 인스턴스가 컴퓨팅 하이퍼바이저에 예약될 때마다 사용 가능한 하드웨어 사용을 극대화하기 위해 각 노드 리소스 세트가 할당됩니다. 이를 일반적으로 binpack이라고 합니다.
리소스 풀의 노드 간에 일관된 하드웨어 설계를 사용하면 bin 패키징을 지원하는 데 도움이 됩니다. 컴퓨팅 리소스 풀에 대해 선택한 하드웨어 노드는 공통 프로세서, 메모리 및 스토리지 레이아웃을 공유해야 합니다. 일반적인 하드웨어 설계를 선택하면 배포, 지원 및 노드 라이프사이클 유지 관리가 쉬워집니다.
- 오버 커밋 비율
OpenStack을 사용하면 사용자가 컴퓨팅 노드에서 CPU 및 RAM을 오버 커밋할 수 있으므로 클라우드에서 실행되는 인스턴스 수를 늘리는 데 도움이 됩니다. 그러나 초과 커밋을 통해 인스턴스의 성능을 줄일 수 있습니다.
오버 커밋 비율은 사용 가능한 물리적 리소스와 비교하여 사용 가능한 가상 리소스의 비율입니다.
- 기본 CPU 할당 비율은 16:1이면 스케줄러는 모든 물리적 코어에 대해 최대 16개의 가상 코어를 할당합니다. 예를 들어 물리적 노드에 12개의 코어가 있는 경우 스케줄러는 최대 192개의 가상 코어를 할당할 수 있습니다. 인스턴스당 일반적인 플레이버 정의 4개의 가상 코어를 사용하면 이 비율은 물리적 노드에 48개의 인스턴스를 제공할 수 있습니다.
- 1.5:1의 기본 RAM 할당 비율은 인스턴스와 연결된 전체 RAM 양이 물리적 노드에서 사용 가능한 RAM보다 1.5배 미만인 경우 스케줄러에서 물리적 노드에 인스턴스를 할당하는 것을 의미합니다.
설계 단계에서 CPU 및 메모리에 대한 오버 커밋 비율을 조정하는 것은 컴퓨팅 노드의 하드웨어 레이아웃에 직접적인 영향을 미치기 때문에 중요합니다. 하드웨어 노드를 서비스 인스턴스에 대한 컴퓨팅 리소스 풀로 설계할 때 노드에서 사용 가능한 프로세서 코어 수와 전체 용량에서 실행되는 서비스 인스턴스에 필요한 디스크 및 메모리를 고려하십시오.
예를 들어, m1.overcloud 인스턴스는 1개의 vCPU, 20GB의 임시 스토리지, 2,048MB의 RAM을 사용합니다. 코어가 10개이고 CPU가 각각 2개인 서버의 경우 하이퍼 스레딩이 켜집니다.
- 기본 CPU 과다 할당 비율은 16:1인 경우 640(2 × 10 × 2 × 16) 총 m1.windows 인스턴스를 허용합니다.
- 1.5:1의 기본 메모리 오버 커밋 비율은 서버에 최소 853GB(640 × 2,048MB / 1.5)가 필요함을 의미합니다.
메모리의 노드 크기를 조정할 때 서비스 운영 체제 및 서비스 요구 사항에 필요한 추가 메모리도 고려해야 합니다.
3.2.2. 플레이버
생성된 각 인스턴스에는 인스턴스 크기와 용량을 결정하는 플레이버 또는 리소스 템플릿이 제공됩니다. 플레이버는 보조 임시 스토리지, 스왑 디스크, 사용을 제한하는 메타데이터 또는 특수 프로젝트 액세스를 지정할 수도 있습니다. 기본 플레이버에는 이러한 추가 속성이 정의되어 있지 않습니다. 인스턴스 플레이버를 사용하면 일반적인 사용 사례가 예측할 수 있고 크기가 조정되지 않기 때문에 용량 예측을 측정할 수 있습니다.
가상 머신을 물리적 호스트에 쉽게 패키징할 수 있도록 기본 플레이버 선택에서는 모든 측면에서 가장 큰 플레이버의 절반 크기를 두 번째로 큰 플레이버로 제공합니다. 플레이버에는 vCPU의 절반, half the Cryostat 및 임시 디스크 공간의 절반이 있습니다. 이후의 각 가장 큰 플레이버는 이전 플레이버의 절반 크기입니다.
다음 다이어그램은 일반적인 용도의 컴퓨팅 디자인과 CPU 최적화 팩된 서버의 플레이버 할당을 시각적으로 보여줍니다.
상용 서버 하드웨어의 일반적인 구성에 기본 플레이버를 사용하는 것이 좋습니다. 활용도를 극대화하려면 플레이버를 사용자 지정하거나 새 플레이버를 생성하여 사용 가능한 하드웨어에 인스턴스 크기를 조정해야 할 수 있습니다.
가능한 경우 플레이버를 각 플레이버에 대해 하나의 vCPU로 제한합니다. 유형 1 하이퍼바이저는 하나의 vCPU로 구성된 VM에 CPU 시간을 더 쉽게 예약할 수 있다는 점에 유의해야 합니다. 예를 들어 4개의 vCPU로 구성된 VM에 CPU 시간을 예약하는 하이퍼바이저는 vCPU 1개만 필요한 경우에도 4개의 물리적 코어를 사용할 수 있을 때까지 기다려야 합니다.
워크로드 특성은 특히 작업에서 CPU, RAM 또는 HDD 요구 사항의 다른 비율을 표시하는 경우 하드웨어 선택 및 플레이버 구성에 영향을 미칠 수 있습니다. 플레이버에 대한 자세한 내용은 인스턴스 및 이미지 관리를 참조하십시오.
3.2.3. vCPU-to-physical CPU 코어 비율
Red Hat OpenStack Platform의 기본 할당 비율은 물리적 또는 하이퍼스레딩 코어당 16 vCPU입니다.
다음 표에는 시스템에 예약된 4GB를 포함하여 사용 가능한 총 메모리를 기반으로 물리적 호스트에서 적절하게 실행할 수 있는 최대 VM 수가 나열되어 있습니다.
총 RAM | VMs | 총 vCPU |
---|---|---|
64GB | 14 | 56 |
96GB | 20 | 80 |
128GB | 29 | 116 |
예를 들어, 초기 그린필드를 60개 인스턴스로 계획하려면 3+1 컴퓨팅 노드가 필요합니다. 일반적으로 메모리 병목 현상이 CPU 병목 현상보다 더 일반적입니다. 그러나 필요한 경우 할당 비율을 물리적 코어당 8개의 vCPU로 줄일 수 있습니다.
3.2.4. 메모리 오버헤드
KVM 하이퍼바이저에는 공유할 수 없는 메모리를 포함하여 적은 양의 VM 메모리 오버헤드가 필요합니다. QEMU/KVM 시스템의 공유 가능한 메모리는 각 하이퍼바이저에 대해 200MB로 반올림할 수 있습니다.
vRAM | 물리적 메모리 사용량(상세) |
---|---|
256 | 310 |
512 | 610 |
1024 | 1080 |
2048 | 2120 |
4096 | 4180 |
일반적으로 VM당 100mb의 하이퍼바이저 오버헤드를 추정할 수 있습니다.
3.2.5. 초과 서브스크립션
메모리는 하이퍼바이저 배포의 제한 요소입니다. 각 물리적 호스트에서 실행할 수 있는 VM 수는 호스트에서 액세스할 수 있는 메모리 양에 따라 제한됩니다. 예를 들어 256GB의 RAM과 200 1GB 이상의 인스턴스를 사용하여 쿼드 코어 CPU를 배포하면 성능이 저하됩니다. 따라서 인스턴스에 배포할 CPU 코어 및 메모리의 최적 비율을 신중하게 결정해야 합니다.
3.2.6. 밀도
- 인스턴스 밀도
- 컴퓨팅 중심 아키텍처에서는 인스턴스 밀도가 낮기 때문에 CPU 및 RAM 초과 서브스크립션 비율도 낮습니다. 특히 설계에서 듀얼 소켓 하드웨어 설계를 사용하는 경우 인스턴스 밀도가 낮은 경우 예상되는 규모를 지원하기 위해 더 많은 호스트가 필요할 수 있습니다.
- 호스트 밀도
- 쿼드 소켓 플랫폼을 사용하여 듀얼 소켓 설계의 상위 호스트 수를 처리할 수 있습니다. 이 플랫폼은 호스트 밀도를 줄임으로써 랙 수를 늘립니다. 이 구성은 네트워크 요구 사항, 전원 연결 수에 영향을 미칠 수 있으며 충당 요구 사항에도 영향을 미칠 수 있습니다.
- 전원 및 혼합 밀도
- 전력 및 연쇄 밀도를 줄이는 것은 오래된 인프라를 사용하는 데이터 센터의 중요한 고려 사항입니다. 예를 들어, 2U, 3U 또는 4U 서버 설계에 대한 전력 및 단정밀도 요구 사항은 호스트 밀도가 낮기 때문에 블레이드, 슬라이 또는 1U 서버 설계보다 낮을 수 있습니다.
3.2.7. 컴퓨팅 하드웨어
- Blade 서버
- 대부분의 블레이드 서버는 듀얼 소켓, 멀티 코어 CPU를 지원할 수 있습니다. CPU 제한을 초과하지 않으려면 전체 대역폭 또는 전체 하이라이트 를 선택합니다. 이러한 블레이드 유형은 또한 서버 밀도를 줄일 수 있습니다. 예를 들어 HP BladeSystem 또는 Dell PowerEdge M1000e와 같은 고밀도 블레이드 서버는 10개의 랙 단위로만 16개의 서버를 지원합니다. half-height 블레이드는 전체 하이프 블레이드보다 두 배 더 밀도가 낮기 때문에 10 개의 랙 단위당 8 개의 서버 만 생성됩니다.
- 1U 서버
1U 랙 장치만 사용하는 랙 마운트된 서버는 블레이드 서버 솔루션보다 더 높은 서버 밀도를 제공할 수 있습니다. 하나의 랙에 있는 1U 서버의 40 단위를 사용하여 랙(ToR) 스위치의 상단 공간을 제공할 수 있습니다. 한 랙에서 32개의 전체 대역폭 블레이드 서버만 사용할 수 있습니다.
그러나 주요 벤더의 1U 서버에는 듀얼 소켓, 멀티 코어 CPU 구성만 있습니다. 1U 랙 마운트 폼패드에서 더 높은 CPU 구성을 지원하려면 원래 설계 제조업체( Cryostat) 또는 두 번째 계층 제조업체에서 시스템을 구입하십시오.
- 2U 서버
- 2U 랙 마운트된 서버는 쿼드 소켓, 멀티 코어 CPU 지원을 제공하지만 이에 해당하는 서버 밀도가 감소합니다. 2U 랙 마운트된 서버는 1U 랙 마운트 서버가 제공하는 밀도의 절반을 제공합니다.
- 대규모 서버
- 4U 서버와 같은 더 큰 랙으로 마운트된 서버는 더 많은 CPU 용량을 제공하고 일반적으로 4개 또는 8개의 CPU 소켓을 지원합니다. 이러한 서버는 확장성이 뛰어나지만 서버 밀도가 훨씬 낮기 때문에 더 많은 비용이 듭니다.
- 슬라이딩 서버
슬라이딩 서버는 단일 2U 또는 3U 인클로저에서 여러 독립 서버를 지원하는 랙으로 마운트된 서버입니다. 이러한 서버는 일반적인 1U 또는 2U 랙이 마운트된 서버보다 높은 밀도를 제공합니다.
예를 들어, 많은 슬라이딩 서버는 총 8개의 CPU 소켓에 대해 2U에 4개의 독립적인 듀얼 소켓 노드를 제공합니다. 그러나 개별 노드의 듀얼 소켓 제한으로 인해 추가 비용 및 구성 복잡성을 상쇄하기에 충분하지 않을 수 있습니다.
3.2.8. 추가 장치
컴퓨팅 노드에 대해 다음과 같은 추가 장치를 고려할 수 있습니다.
- 고성능 컴퓨팅 작업을 위한 그래픽 처리 단위(GPU).
-
암호화 루틴에 대한 엔트로피 부족을 방지하기 위해 하드웨어 기반 임의 번호 생성기입니다. 인스턴스 이미지 속성과 함께 를 사용하여 임의 번호 생성기 장치를 인스턴스에 추가할 수 있습니다.
/dev/random
은 기본 엔트로피 소스입니다. - 데이터베이스 관리 시스템의 읽기/쓰기 시간을 최대화하기 위한 임시 스토리지용 SSD입니다.
- 호스트 집계는 하드웨어와 같은 유사한 특성을 공유하는 호스트를 그룹화하여 작동합니다. 특수 하드웨어를 클라우드 배포에 추가하면 각 노드의 비용에 추가할 수 있으므로 모든 컴퓨팅 노드에 추가 사용자 지정이 필요한지 아니면 하위 집합에만 필요한지 여부를 고려하십시오.
3.3. 스토리지 리소스
클라우드를 설계할 때 선택한 스토리지 솔루션은 배포의 중요한 측면(예: 성능, 용량, 가용성, 상호 운용성)에 영향을 미칩니다.
스토리지 솔루션을 선택할 때 다음 요소를 고려하십시오.
3.3.1. 일반 고려 사항
- 애플리케이션
클라우드 스토리지 솔루션을 효과적으로 사용하려면 애플리케이션이 기본 스토리지 하위 시스템을 알고 있어야 합니다. 기본적으로 사용 가능한 복제를 사용할 수 없는 경우 운영 직원은 복제 서비스를 제공하도록 애플리케이션을 구성할 수 있어야 합니다.
기본 스토리지 시스템을 감지할 수 있는 애플리케이션은 다양한 인프라에서 작동할 수 있으며 기본 인프라의 차이점에 관계없이 동일한 기본 동작을 수행합니다.
- I/O
입력 출력 성능에 대한 벤치마크에서는 예상되는 성능 수준에 대한 기준을 제공합니다. 벤치마크 결과 데이터는 다양한 로드 하에서 동작을 모델링하는 데 도움이 될 수 있으며 적합한 아키텍처를 설계하는 데 도움이 될 수 있습니다.
아키텍처 라이프사이클 동안 스크립팅된 소형 벤치마크는 다른 시간에 시스템 상태를 기록하는 데 도움이 될 수 있습니다. 스크립팅된 벤치마크의 데이터는 범위를 지원하고 조직의 요구 사항을 보다 깊이 이해하는 데 도움이 될 수 있습니다.
- 상호 운용성
- 선택한 하드웨어 또는 스토리지 관리 플랫폼이 단기 인스턴스 스토리지에 사용할 수 있는지 여부에 영향을 주는 KVM 하이퍼바이저와 같은 OpenStack 구성 요소와 상호 운용할 수 있는지 확인합니다.
- 보안
- 데이터 보안 설계는 SLA, 법적 요구 사항, 업계 규정 및 시스템 또는 직원의 필수 인증에 따라 다양한 측면에 중점을 둘 수 있습니다. 데이터 유형에 따라 HIPPA, ISO9000 또는 SOX를 준수하는 것이 좋습니다. 특정 조직의 경우 액세스 제어 수준도 고려해야 합니다.
3.3.2. OpenStack Object Storage(swift)
- 가용성
오브젝트 데이터에 필요한 가용성 수준을 제공하도록 오브젝트 스토리지 리소스 풀을 설계합니다. 필요한 복제본 수를 수용하려면 랙 수준 및 영역 수준 설계를 고려하십시오. 복제본의 지연 수는 3입니다. 각 데이터 복제본은 특정 영역에 서비스를 제공하는 독립적인 전력, 혼잡 및 네트워크 리소스가 있는 별도의 가용성 영역에 있어야 합니다.
OpenStack Object Storage 서비스는 특정 수의 데이터 복제본을 리소스 노드에 오브젝트로 배치합니다. 이러한 복제본은 클러스터의 모든 노드에 존재하는 일관된 해시 링을 기반으로 클러스터에 배포됩니다. 또한 오브젝트 노드에 저장된 데이터에 대한 액세스를 제공하는 Object Storage 프록시 서버 풀은 각 가용성 영역을 서비스해야 합니다.
복제본 수에 필요한 최소 응답을 제공하기 위해 충분한 영역 수를 사용하여 Object Storage 시스템을 설계합니다. 예를 들어 Swift 클러스터에서 복제본 3개를 구성하는 경우 Object Storage 클러스터 내부에 구성할 권장 영역 수는 5개입니다.
영역 수가 적은 솔루션을 배포할 수 있지만 일부 데이터를 사용할 수 없으며 클러스터에 저장된 일부 오브젝트에 대한 API 요청이 실패할 수 있습니다. 따라서 Object Storage 클러스터의 영역 수를 고려해야 합니다.
각 리전의 오브젝트 프록시는 로컬 읽기 및 쓰기 선호도를 활용하여 가능한 경우 오브젝트에 대한 액세스를 용이하게 합니다. 프록시 서비스가 여러 영역에 분산되도록 업스트림 로드 밸런싱을 배포해야 합니다. 경우에 따라 서비스의 지리적 배포를 지원하기 위해 타사 솔루션이 필요할 수 있습니다.
Object Storage 클러스터 내의 영역은 논리 분할이며 단일 디스크, 노드, 노드 컬렉션, 여러 랙 또는 여러 DC로 구성할 수 있습니다. 사용 가능한 중복 스토리지 시스템을 제공하는 동안 Object Storage 클러스터를 확장할 수 있어야 합니다. 특정 영역의 스토리지 설계에 영향을 줄 수 있는 복제본, 보존 및 기타 요인에 대한 다양한 요구 사항으로 스토리지 정책을 구성해야 할 수 있습니다.
- 노드 스토리지
OpenStack Object Storage에 대한 하드웨어 리소스를 설계할 때 주요 목표는 각 리소스 노드의 스토리지 크기를 최대화하면서 테라바이트당 비용이 최소로 유지되도록 하는 것입니다. 이는 종종 많은 회전 디스크를 보유할 수 있는 서버를 활용하는 것과 관련이 있습니다. 연결된 스토리지와 함께 2U 서버 폼 인수를 사용하거나 더 많은 수의 드라이브를 보유하는 외부 섀시와 함께 사용할 수 있습니다.
OpenStack Object Storage의 일관성 및 파티션 허용 특성은 특수한 데이터 복제 장치를 사용하지 않고도 데이터가 최신 상태를 유지하고 하드웨어 결함을 유지할 수 있도록 합니다.
- 성능
- 오브젝트 스토리지 노드는 요청 수가 클러스터 성능을 방해하지 않도록 설계되어야 합니다. 오브젝트 스토리지 서비스는 채팅 프로토콜입니다. 따라서 코어 수가 높은 여러 프로세서를 사용하면 IO 요청이 서버에 영향을 미치지 않습니다.
- 가중치 및 비용
OpenStack Object Storage는 swift 링 내부의 가중치와 함께 드라이브를 혼합하고 일치시킬 수 있는 기능을 제공합니다. 신속한 스토리지 클러스터를 설계할 때 가장 비용 효율적인 스토리지 솔루션을 사용할 수 있습니다.
많은 서버 섀시는 랙 공간의 4U에 60개 이상의 드라이브를 저장할 수 있습니다. 따라서 테라바이트당 최상의 비용으로 각 랙 유닛의 스토리지 용량을 최대화할 수 있습니다. 그러나 오브젝트 스토리지 노드에서 RAID 컨트롤러를 사용하지 않는 것이 좋습니다.
- 스케일링
스토리지 솔루션을 설계할 때 Object Storage 서비스에 필요한 최대 파티션 전원을 확인한 다음 생성할 수 있는 최대 파티션 수를 결정해야 합니다. 오브젝트 스토리지는 전체 스토리지 클러스터에 데이터를 배포하지만 각 파티션은 두 개 이상의 디스크에 걸쳐 있을 수 없습니다. 따라서 최대 파티션 수는 디스크 수를 초과할 수 없습니다.
예를 들어 초기 단일 디스크가 있는 시스템과3의 파티션 전원이 8개(23 ) 파티션을 보유할 수 있습니다. 두 번째 디스크를 추가하면 각 디스크가 4개의 파티션을 유지할 수 있습니다. one-disk-per-partition 제한은 이 시스템에 디스크가 8개를 초과할 수 없고 확장성을 제한할 수 없음을 의미합니다. 그러나 초기 단일 디스크와 파티션 전원이10인 시스템은 최대 1024(210 ) 파티션을 가질 수 있습니다.
시스템 백엔드 스토리지 용량을 늘릴 때마다 파티션 맵은 스토리지 노드에서 데이터를 재배포합니다. 경우에 따라 이 복제는 매우 큰 데이터 세트로 구성됩니다. 이러한 경우 데이터에 대한 테넌트 액세스와 충돌하지 않는 백엔드 복제 링크를 사용해야 합니다.
더 많은 테넌트가 클러스터의 데이터에 액세스하고 데이터 세트가 증가하면 서비스 데이터 액세스 요청에 프런트 엔드 대역폭을 추가해야 합니다. Object Storage 클러스터에 프런트 엔드 대역폭을 추가하려면 테넌트가 프록시 계층을 확장할 수 있는 고가용성 솔루션과 함께 테넌트가 데이터에 액세스하는 데 사용할 수 있는 Object Storage 프록시를 설계해야 합니다.
테넌트와 소비자가 클러스터 내에 저장된 데이터에 액세스하기 위해 사용하는 프런트 엔드 로드 밸런싱 계층을 설계해야 합니다. 이 로드 밸런싱 계층은 영역, 지역 또는 지역에 분산될 수 있습니다.
프록시 서버와 스토리지 노드 간에 서비스 요청을 하는 네트워크 리소스에 대역폭과 용량을 추가해야 하는 경우도 있습니다. 따라서 스토리지 노드 및 프록시 서버에 대한 액세스를 제공하는 네트워크 아키텍처는 확장 가능해야 합니다.
3.3.3. OpenStack Block Storage(cinder)
- 가용성 및 중복
애플리케이션의 IOPS(초당 입출력) 수요는 RAID 컨트롤러를 사용해야 하는지 여부와 필요한 RAID 수준을 결정합니다. 중복성의 경우 RAID 5 또는 RAID 6과 같은 중복 RAID 구성을 사용해야 합니다. 블록 스토리지 볼륨의 자동화된 복제와 같은 일부 특수 기능에는 높은 수요를 처리하기 위해 타사 플러그인 또는 엔터프라이즈 블록 스토리지 솔루션이 필요할 수 있습니다.
블록 스토리지에 대한 극단적인 수요가 있는 환경에서는 여러 스토리지 풀을 사용해야 합니다. 각 장치 풀에는 해당 풀의 모든 하드웨어 노드에서 유사한 하드웨어 설계 및 디스크 구성이 있어야 합니다. 이러한 설계를 통해 애플리케이션은 다양한 중복성, 가용성 및 성능 특성을 갖춘 다양한 Block Storage 풀에 액세스할 수 있습니다.
네트워크 아키텍처는 인스턴스에서 사용 가능한 스토리지 리소스를 사용하는 데 필요한 동부 서부 대역폭의 양도 고려해야 합니다. 선택한 네트워크 장치는 대규모 데이터 블록을 전송하기 위해 점보 프레임을 지원해야 합니다. 네트워크 리소스에 대한 부하를 줄이기 위해 인스턴스 및 블록 스토리지 리소스 간 연결을 제공하기 위해 추가 전용 백엔드 스토리지 네트워크를 생성해야 하는 경우도 있습니다.
여러 스토리지 풀을 배포할 때 리소스 노드에 스토리지를 프로비저닝하는 Block Storage 스케줄러에 미치는 영향을 고려해야 합니다. 애플리케이션이 특정 네트워크, 전원 및 단조 인프라가 있는 여러 리전의 볼륨을 예약할 수 있도록 합니다. 이 설계를 통해 테넌트는 여러 가용성 영역에 분산된 내결함성 애플리케이션을 빌드할 수 있습니다.
블록 스토리지 리소스 노드 외에도 스토리지 노드를 프로비저닝하고 액세스를 제공하는 API 및 관련 서비스의 고가용성 및 중복을 설계하는 것이 중요합니다. 중단되지 않는 서비스를 제공하기 위해 REST API 서비스의 고가용성을 달성하려면 하드웨어 또는 소프트웨어 로드 밸런서 계층을 설계해야 합니다.
경우에 따라 블록 스토리지 볼륨의 상태를 서비스하고 저장하는 백엔드 데이터베이스 서비스에 대한 액세스를 제공하기 위해 추가 로드 밸런싱 계층을 배포해야 할 수 있습니다. MariaDB 및 Galera와 같은 Block Storage 데이터베이스를 저장하려면 고가용성 데이터베이스 솔루션을 설계해야 합니다.
- 연결된 스토리지
블록 스토리지 서비스는 하드웨어 벤더가 개발한 플러그인 드라이버를 사용하여 엔터프라이즈 스토리지 솔루션을 활용할 수 있습니다. OpenStack 블록 스토리지와 함께 기본적으로 제공되는 다수의 엔터프라이즈 플러그인과 타사 채널을 통해 다른 플러그인을 사용할 수 있습니다.
범용 클라우드는 일반적으로 대부분의 블록 스토리지 노드에서 직접 연결된 스토리지를 사용합니다. 따라서 테넌트에 추가 수준의 서비스를 제공해야 할 수 있습니다. 이러한 수준은 엔터프라이즈 스토리지 솔루션에서만 제공될 수 있습니다.
- 성능
- 높은 성능이 필요한 경우 고성능 RAID 볼륨을 사용할 수 있습니다. 극단적인 성능을 위해 고속 SSD(Solid-State Drive) 디스크를 사용할 수 있습니다.
- 풀
- 블록 스토리지 풀은 테넌트가 애플리케이션에 적합한 스토리지 솔루션을 선택할 수 있도록 허용해야 합니다. 다양한 유형의 스토리지 풀을 생성하고 블록 스토리지 서비스에 대한 고급 스토리지 스케줄러를 구성하면 테넌트에 다양한 성능 수준 및 중복성 옵션으로 대규모 스토리지 서비스 카탈로그를 제공할 수 있습니다.
- 스케일링
전체 블록 스토리지 서비스에 중단되지 않고 블록 스토리지 풀을 업그레이드하여 스토리지 용량을 추가할 수 있습니다. 적절한 하드웨어 및 소프트웨어를 설치하고 구성하여 풀에 노드를 추가합니다. 그런 다음 메시지 버스를 사용하여 적절한 스토리지 풀에 보고하도록 새 노드를 구성할 수 있습니다.
블록 스토리지 노드는 노드 가용성을 스케줄러 서비스에 보고하므로 새 노드가 온라인 상태이고 사용 가능한 경우 테넌트는 새 스토리지 리소스를 즉시 사용할 수 있습니다.
경우에 따라 인스턴스의 블록 스토리지에 대한 수요가 사용 가능한 네트워크 대역폭을 소모할 수 있습니다. 따라서 용량 및 대역폭을 원활하게 추가할 수 있도록 블록 스토리지 리소스를 서비스하도록 네트워크 인프라를 설계해야 합니다.
이는 종종 다운스트림 장치에 용량을 추가하기 위한 동적 라우팅 프로토콜 또는 고급 네트워킹 솔루션을 포함합니다. 프런트 엔드 및 백엔드 스토리지 네트워크 설계에는 용량 및 대역폭을 빠르고 쉽게 추가할 수 있는 기능이 포함되어야 합니다.
3.3.4. 스토리지 하드웨어
- 용량
노드 하드웨어는 클라우드 서비스에 충분한 스토리지를 지원해야 하며 배포 후 용량을 추가할 수 있도록 해야 합니다. 하드웨어 노드는 RAID 컨트롤러 카드에 의존하지 않고 다수의 저렴한 디스크를 지원해야 합니다.
하드웨어 노드는 또한 하드웨어 기반 스토리지 성능과 중복성을 제공하기 위해 고속 스토리지 솔루션과 RAID 컨트롤러 카드를 지원할 수 있어야 합니다. 손상된 배열을 자동으로 복구하는 하드웨어 RAID 컨트롤러를 선택하면 성능이 저하되거나 삭제된 스토리지 장치를 교체 및 복구하는 데 도움이 됩니다.
- 연결
- 스토리지 솔루션에서 이더넷이 아닌 스토리지 프로토콜을 사용하는 경우 하드웨어가 이러한 프로토콜을 처리할 수 있는지 확인합니다. 중앙 집중식 스토리지 어레이를 선택하는 경우 하이퍼바이저가 이미지 스토리지를 위해 해당 스토리지 어레이에 연결할 수 있는지 확인합니다.
- 비용
- 스토리지는 전체 시스템 비용의 중요한 부분이 될 수 있습니다. 벤더 지원이 필요한 경우 상용 스토리지 솔루션을 권장하지만 비용이 더 많이 듭니다. 초기 금융 투자를 최소화해야 하는 경우 상용 하드웨어를 기반으로 시스템을 설계할 수 있습니다. 그러나 초기 비용 절감으로 인해 실행 중인 지원 비용과 비호환성 위험이 증가할 수 있습니다.
- 직접 연결된 스토리지
- 직접 연결 스토리지(DAS)는 서버 하드웨어 선택에 영향을 미치며 호스트 밀도, 인스턴스 밀도, 전원 밀도, OS-하이퍼바이저 및 관리 도구에 영향을 미칩니다.
- 확장성
- 확장성은 모든 OpenStack 클라우드에서 주요 고려 사항입니다. 구현의 최종 의도된 크기를 예측하기가 어려울 수 있습니다. 성장 및 사용자 요구를 수용하기 위해 초기 배포를 확장하는 것이 좋습니다.
- 확장 가능성
확장성은 스토리지 솔루션의 주요 아키텍처 요소입니다. 50P로 확장되는 스토리지 솔루션은 10 PB로만 확장되는 솔루션보다 확장 가능한 스토리지 솔루션으로 간주됩니다. 이 메트릭은 워크로드가 증가함에 따라 솔루션의 성능을 측정하는 확장성과 다릅니다.
예를 들어 개발 플랫폼 클라우드를 위한 스토리지 아키텍처에는 상용 제품 클라우드와 동일한 확장 가능성 및 확장성이 필요하지 않을 수 있습니다.
- 내결함성
Object Storage 리소스 노드에는 하드웨어 내결함성 또는 RAID 컨트롤러가 필요하지 않습니다. Object Storage 서비스는 기본적으로 영역 간 복제를 제공하므로 Object Storage 하드웨어에서 내결함성을 계획할 필요가 없습니다.
블록 스토리지 노드, 컴퓨팅 노드 및 클라우드 컨트롤러에는 하드웨어 RAID 컨트롤러와 다양한 RAID 구성이 있는 하드웨어 수준에서 내결함성이 내장되어 있어야 합니다. RAID 수준은 클라우드의 성능 및 가용성 요구 사항과 일치해야 합니다.
- 위치
- 인스턴스 및 이미지 스토리지의 지리적 위치는 아키텍처 설계에 영향을 미칠 수 있습니다.
- 성능
Object Storage 서비스를 실행하는 디스크가 빠른 성능 디스크일 필요는 없습니다. 따라서 스토리지를 위해 테라바이트당 비용 효율성을 극대화할 수 있습니다. 그러나 블록 스토리지 서비스를 실행하는 디스크는 고성능 블록 스토리지 풀을 제공하기 위해 SSD 또는 플래시 스토리지가 필요할 수 있는 성능 향상 기능을 사용해야 합니다.
인스턴스에 사용하는 단기 디스크의 스토리지 성능도 고려해야 합니다. 컴퓨팅 풀에 단기 스토리지의 높은 사용률이 필요하거나 성능이 매우 높은 경우 Block Storage에 배포하는 솔루션을 유사한 하드웨어 솔루션을 배포해야 합니다.
- 서버 유형
- DAS를 포함하는 확장 가능한 스토리지 아키텍처는 서버 하드웨어 선택에 영향을 미칩니다. 이 아키텍처는 호스트 밀도, 인스턴스 밀도, 전원 밀도, OS-하이퍼바이저, 관리 툴 등에 영향을 미칠 수 있습니다.
3.3.5. Ceph Storage
Ceph를 외부 스토리지로 간주하는 경우 적절한 대기 시간으로 예상되는 동시 VM 수를 처리하도록 Ceph 클러스터 백엔드의 크기를 조정해야 합니다. 허용 가능한 서비스 수준은 쓰기 작업을 위해 20ms 미만의 I/O 작업 99 %를 유지 관리할 수 있으며 읽기 작업을 위해 10ms 미만으로 유지할 수 있습니다.
각 Rados Block Device(RBD)의 최대 대역폭을 구성하거나 최소 보장된 커밋을 설정하여 다른 VM과 I/O 급증을 분리할 수 있습니다.
3.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) 스위치의 회전 스위치는 충분한 전력을 제공하지 않을 수 있습니다.
- 확장성
- 네트워크 설계에는 확장 가능한 물리적 및 논리적 네트워크 설계가 포함되어야 합니다. 네트워크 하드웨어는 하드웨어 노드에 필요한 인터페이스 및 속도를 제공해야 합니다.
3.5. 성능
OpenStack 배포의 성능은 인프라 및 컨트롤러 서비스와 관련된 여러 요인에 따라 달라집니다. 사용자 요구 사항은 일반 네트워크 성능, 컴퓨팅 리소스 성능 및 스토리지 시스템 성능으로 나눌 수 있습니다.
이러한 시스템이 속도 저하 없이 일관되게 작동하는 경우에도 시스템의 기록 성능 기준선을 유지해야 합니다. 사용 가능한 기준 정보는 성능 문제가 발생하고 비교 목적으로 데이터가 필요할 때 유용한 참조입니다.
1.5.2절. “OpenStack Telemetry(ceilometer)” 외에도 외부 소프트웨어를 사용하여 성능을 추적할 수도 있습니다. Red Hat OpenStack Platform용 Operational Tools 리포지토리에는 다음과 같은 툴이 포함되어 있습니다.
3.5.1. 네트워크 성능
네트워크 요구 사항은 성능 기능을 결정하는 데 도움이 됩니다. 예를 들어 소규모 배포에서는 1GbE(Gigabit Ethernet) 네트워킹을 사용할 수 있으며 여러 부서를 제공하는 대규모 설치 또는 많은 사용자가 10GbE 네트워킹을 사용해야 할 수 있습니다.
실행 중인 인스턴스의 성능은 이러한 네트워크 속도로 제한될 수 있습니다. 네트워킹 기능을 혼합하여 실행하는 OpenStack 환경을 설계할 수 있습니다. OpenStack 환경의 사용자는 다양한 인터페이스 속도를 활용하여 목적에 맞는 네트워크를 선택할 수 있습니다.
예를 들어 웹 애플리케이션 인스턴스는 OpenStack Networking이 1GbE 기능이 있는 퍼블릭 네트워크에서 실행될 수 있으며, backend 데이터베이스는 10GbE 기능이 있는 OpenStack Networking 네트워크를 사용하여 데이터를 복제할 수 있습니다. 경우에 따라 설계에서 링크 집계를 통합하여 처리량을 높일 수 있습니다.
클라우드 API에 프런트 엔드 서비스를 제공하는 하드웨어 로드 밸런서를 구현하여 네트워크 성능을 향상시킬 수 있습니다. 필요한 경우 하드웨어 로드 밸런서도 SSL 종료를 수행할 수 있습니다. SSL 오프로드를 구현할 때 선택한 장치의 SSL 오프로드 기능을 확인하는 것이 중요합니다.
3.5.2. 컴퓨팅 노드 성능
CPU, 메모리, 디스크 유형을 포함하여 컴퓨팅 노드에 사용되는 하드웨어 사양은 인스턴스의 성능에 직접적인 영향을 미칩니다. OpenStack 서비스의 조정 가능한 매개 변수는 성능에 직접적인 영향을 미칠 수 있습니다.
예를 들어 OpenStack Compute의 기본 초과 커밋 비율은 CPU의 경우 16:1이고 메모리는 1.5입니다. 이러한 높은 비율은 "noisy-neighbor" 활동이 증가할 수 있습니다. 이 시나리오를 피하고 사용량이 증가할 때 환경을 모니터링하려면 컴퓨팅 환경의 크기를 신중하게 조정해야 합니다.
3.5.3. 블록 스토리지 호스트 성능
블록 스토리지는 NetApp 또는 EMC, Ceph와 같은 스케일 아웃 스토리지와 같은 엔터프라이즈 백엔드 시스템을 사용하거나 블록 스토리지 노드에서 직접 연결된 스토리지 기능을 사용할 수 있습니다.
블록 스토리지를 배포하여 프론트 측 API 트래픽 성능에 영향을 미치고 부정적인 영향을 받을 수 있는 호스트 네트워크를 통과하도록 트래픽을 배포할 수 있습니다. 따라서 컨트롤러 및 컴퓨팅 호스트에서 전용 인터페이스가 있는 전용 데이터 스토리지 네트워크를 사용하는 것이 좋습니다.
3.5.4. 오브젝트 스토리지 호스트 성능
사용자는 일반적으로 하드웨어 로드 밸런서에서 실행되는 프록시 서비스를 통해 오브젝트 스토리지에 액세스합니다. 기본적으로 복원력이 높은 스토리지 시스템은 전체 시스템 성능에 영향을 줄 수 있는 저장된 데이터를 복제합니다. 이 경우 스토리지 네트워크 아키텍처에서 10GbE 이상의 네트워킹 용량이 권장됩니다.
3.5.5. 컨트롤러 노드
컨트롤러 노드는 최종 사용자에게 관리 서비스를 제공하고 클라우드 작업을 위해 내부적으로 서비스를 제공합니다. 컨트롤러 인프라를 실행하는 데 사용되는 하드웨어를 신중하게 설계하는 것이 중요합니다.
컨트롤러는 서비스 간 시스템 메시징을 위해 메시지 대기열 서비스를 실행합니다. 메시징의 성능 문제로 인해 인스턴스 실행 및 삭제, 새 스토리지 볼륨 프로비저닝, 네트워크 리소스 관리와 같은 운영 기능이 지연될 수 있습니다. 이러한 지연은 특히 자동 확장 기능을 사용할 때 일부 조건에 반응하는 애플리케이션의 기능에 부정적인 영향을 미칠 수 있습니다.
또한 컨트롤러 노드에서 여러 동시 사용자의 워크로드를 처리할 수 있는지 확인해야 합니다. 고객의 서비스 신뢰성을 개선하기 위해 API 및 Horizon 서비스가 로드되었는지 확인합니다.
OpenStack ID 서비스(keystone)는 내부적으로 OpenStack 및 최종 사용자에게 모든 서비스에 대한 인증 및 권한 부여를 제공하는 것이 중요합니다. 이 서비스는 적절하게 크기가 지정되지 않은 경우 전체 성능이 저하될 수 있습니다.
모니터링에 매우 중요한 메트릭은 다음과 같습니다.
- 이미지 디스크 사용률
- Compute API에 대한 응답 시간
3.6. 유지 관리 및 지원
설치를 지원하고 유지 관리하려면 운영 직원이 아키텍처 설계를 파악해야 합니다. 운영 및 엔지니어링 직원 간의 기술 수준과 역할을 분리하는 것은 설치 크기와 목적에 따라 다릅니다.
- 대규모 클라우드 서비스 공급자 또는 communication 공급자는 특별히 교육된 전용 운영 조직에 의해 관리될 가능성이 높습니다.
- 소규모 구현에서는 엔지니어링, 설계 및 운영 기능을 결합해야 하는 지원 인력에 더 의존할 가능성이 큽니다.
설계에서 작업 오버헤드를 줄이는 기능을 통합하는 경우 일부 운영 기능을 자동화할 수 있습니다.
또한 설계는 SLA(서비스 수준 계약)의 영향을 직접적으로 받습니다. SLA는 서비스 가용성 수준을 정의하고 계약상의 의무를 충족하지 않는 경우 일반적으로 페널티를 포함합니다. 설계에 영향을 미치는 SLA 용어는 다음과 같습니다.
- API 가용성은 여러 인프라 서비스와 고가용성 로드 밸런서를 의미합니다.
- 네트워크 가동 시간은 스위치 설계에 영향을 미치며 중복 전환 및 전원이 필요할 수 있습니다.
- 네트워크 분리 또는 추가 보안 메커니즘을 나타내는 네트워크 보안 정책 요구 사항.
3.6.1. 백업
백업 및 복원 전략, 데이터 평가 또는 계층적 스토리지 관리, 보존 전략, 데이터 배치 및 워크플로우 자동화의 영향을 받을 수 있습니다.
3.6.2. 다운타임
효과적인 클라우드 아키텍처는 다음을 지원해야 합니다.
- 계획된 다운타임 (유지 관리)
- 계획되지 않은 다운타임 (시스템 오류)
예를 들어 컴퓨팅 호스트가 실패하는 경우 스냅샷에서 또는 인스턴스를 다시 요청하여 인스턴스를 복원할 수 있습니다. 그러나 고가용성을 위해 공유 스토리지와 같은 추가 지원 서비스를 배포하거나 안정적인 마이그레이션 경로를 설계해야 할 수 있습니다.
3.7. 가용성
두 개 이상의 서버를 사용하는 경우 OpenStack은 고가용성 배포를 제공할 수 있습니다. 서버는 RabbitMQ 메시지 큐잉 서비스 및 MariaDB 데이터베이스 서비스에서 모든 서비스를 실행할 수 있습니다.
클라우드에서 서비스를 확장할 때 백엔드 서비스도 확장해야 합니다. 서버 사용률 및 응답 시간을 모니터링하고 보고하고 시스템을 테스트하면 확장 결정을 결정하는 데 도움이 될 수 있습니다.
- 단일 장애 지점을 방지하려면 OpenStack 서비스를 여러 서버에 배포해야 합니다. API 가용성은 여러 OpenStack 서버가 멤버로 포함된 고가용성 로드 밸런서 뒤에 이러한 서비스를 배치하여 수행할 수 있습니다.
- 배포에 적절한 백업 기능이 있는지 확인합니다. 예를 들어 고가용성을 사용하는 두 개의 인프라 컨트롤러 노드가 있는 배포에서 하나의 컨트롤러가 손실되는 경우에도 다른 컨트롤러에서 클라우드 서비스를 실행할 수 있습니다.
- OpenStack 인프라는 서비스를 제공하는 데 통합되며 특히 SLA로 작동할 때 항상 사용할 수 있어야 합니다. 핵심 인프라에 필요한 스위치, 경로 및 Reundancies of power의 수와 고가용성 스위치 인프라에 다양한 경로를 제공하는 네트워크의 관련 본딩을 고려하십시오. 사용할 네트워킹 백엔드 유형에 특히 주의하십시오. 네트워킹 백엔드를 선택하는 방법에 대한 자세한 내용은 2장. 네트워킹 In-Depth 을 참조하십시오.
- 실시간 마이그레이션을 위해 컴퓨팅 호스트를 구성하지 않고 Compute 호스트가 실패하면 Compute 인스턴스 및 해당 인스턴스에 저장된 데이터가 손실될 수 있습니다. 컴퓨팅 호스트의 가동 시간을 보장하기 위해 엔터프라이즈 스토리지 또는 OpenStack 블록 스토리지에서 공유 파일 시스템을 사용할 수 있습니다.
외부 소프트웨어를 사용하여 서비스 가용성 또는 임계값 제한을 확인하고 적절한 알람을 설정할 수 있습니다. Red Hat OpenStack Platform용 Operational Tools 리포지터리에는 다음이 포함됩니다.
OpenStack에서 고가용성을 사용하는 참조 아키텍처의 경우 Ceph Storage를 사용하여 고가용성 Red Hat OpenStack Platform 6 배포 를참조하십시오.
3.8. 보안
보안 도메인에는 단일 시스템에서 공통 신뢰 요구 사항과 기대치를 공유하는 사용자, 애플리케이션, 서버 또는 네트워크가 포함됩니다. 보안 도메인은 일반적으로 동일한 인증 및 권한 부여 요구 사항과 사용자를 사용합니다.
일반적인 보안 도메인 범주는 공용, 게스트, 관리 및 데이터입니다. 도메인을 개별적으로 또는 결합하여 OpenStack 배포에 매핑할 수 있습니다. 예를 들어, 일부 배포 토폴로지는 게스트와 데이터 도메인을 하나의 물리적 네트워크에 결합하고, 다른 경우에는 네트워크가 물리적으로 분리되어 있습니다. 각 케이스를 사용하려면 클라우드 운영자가 관련 보안 문제를 알고 있어야 합니다.
보안 도메인은 특정 OpenStack 배포 토폴로지에 매핑되어야 합니다. 도메인 및 도메인 신뢰 요구 사항은 클라우드 인스턴스가 퍼블릭, 프라이빗 또는 하이브리드인지 여부에 따라 달라집니다.
- 퍼블릭 도메인
- 클라우드 인프라의 완전히 신뢰할 수 없는 영역입니다. 공용 도메인은 권한이 없는 전체 또는 네트워크로 인터넷을 참조할 수 있습니다. 이 도메인은 항상 신뢰할 수 없는 것으로 간주해야 합니다.
- 게스트 도메인
일반적으로 Compute(인스턴스 간) 트래픽에 사용되며, API 호출과 같은 클라우드 운영을 지원하는 서비스는 아니라 클라우드의 인스턴스에서 생성한 Compute 데이터를 처리합니다.
인스턴스 사용을 엄격하게 제어하거나 인스턴스에 대한 무제한 인터넷 액세스를 허용하는 퍼블릭 클라우드 공급자 및 프라이빗 클라우드 공급자는 이 도메인을 신뢰할 수 없는 것으로 간주해야 합니다. 프라이빗 클라우드 공급자는 이 네트워크를 내부적으로 간주할 수 있으므로 인스턴스 및 모든 클라우드 테넌트에 대한 신뢰를 제공하는 제어만 신뢰할 수 있습니다.
- 관리 도메인
- 서비스가 서로 상호 작용하는 도메인입니다. 이 도메인을 컨트롤 플레인 이라고 합니다. 이 도메인의 네트워크는 구성 매개 변수, 사용자 이름 및 암호와 같은 기밀 데이터를 전송합니다. 대부분의 배포에서 이 도메인은 신뢰할 수 있는 것으로 간주됩니다.
- 데이터 도메인
- 스토리지 서비스가 데이터를 전송하는 도메인입니다. 이 도메인을 교차하는 대부분의 데이터에는 높은 무결성 및 기밀성 요구 사항이 있으며 배포 유형에 따라 강력한 가용성 요구 사항이 있을 수 있습니다. 이 네트워크의 신뢰 수준은 다른 배포 결정에 따라 다릅니다.
엔터프라이즈에 OpenStack을 프라이빗 클라우드로 배포할 때 배포는 일반적으로 방화벽 뒤에 있으며 기존 시스템을 사용하는 신뢰할 수 있는 네트워크 내에 있습니다. 클라우드 사용자는 일반적으로 회사에서 정의한 보안 요구 사항에 종속된 직원입니다. 이 배포는 대부분의 보안 도메인을 신뢰할 수 있음을 의미합니다.
그러나 대중이 직면하는 역할에 OpenStack을 배포할 때 도메인의 신뢰 수준 및 공격 벡터에 대해서는 가정이 크게 증가할 수 있습니다. 예를 들어 API 엔드포인트와 기본 소프트웨어는 무단 액세스를 얻거나 서비스에 대한 액세스를 방지하려는 잘못된 행위자에 취약해질 수 있습니다. 이러한 공격으로 인해 데이터, 기능 및 의견이 손실될 수 있습니다. 이러한 서비스는 감사 및 적절한 필터링을 사용하여 보호해야 합니다.
퍼블릭 및 프라이빗 클라우드 모두에 대한 시스템 사용자를 관리하는 경우에도 주의해야 합니다. ID 서비스는 LDAP와 같은 외부 ID 백엔드를 사용할 수 있으므로 OpenStack 내에서 사용자 관리가 쉬워집니다. 사용자 인증 요청에는 사용자 이름, 암호 및 인증 토큰과 같은 중요한 정보가 포함되어 있으므로 SSL 종료를 수행하는 하드웨어에 API 서비스를 배치해야 합니다.
3.9. 추가 소프트웨어
일반적인 OpenStack 배포에는 OpenStack별 구성 요소 및 1.6.1절. “타사 구성 요소” 가 포함됩니다. 추가 소프트웨어에는 클러스터링, 로깅, 모니터링 및 경고용 소프트웨어가 포함될 수 있습니다. 따라서 배포 설계에서는 CPU, RAM, 스토리지 및 네트워크 대역폭과 같은 추가 리소스 사용을 고려해야 합니다.
클라우드를 설계할 때 다음과 같은 요소를 고려하십시오.
- 데이터베이스 및 메시징
기본 메시지 큐 공급자는 필요한 수의 컨트롤러 서비스와 복원력이 높은 데이터베이스 기능을 제공하는 기술에 영향을 미칠 수 있습니다. 예를 들어 Galera와 함께 MariaDB를 사용하는 경우 서비스 복제는 쿼럼에 의존합니다. 따라서 기본 데이터베이스는 실패한 Galera 노드 복구를 위해 3개 이상의 노드로 구성되어야 합니다.
소프트웨어 기능을 지원하는 노드 수를 늘리면 랙 공간 및 스위치 포트 밀도를 둘 다 고려하십시오.
- 외부 캐싱
Memcached는 분산 메모리 오브젝트 캐싱 시스템이며 Redis는 키-값 저장소입니다. 두 시스템 모두 클라우드에 배포하여 ID 서비스의 부하를 줄일 수 있습니다. 예를 들어 memcached 서비스는 토큰을 캐시하고 분산 캐싱 시스템을 사용하여 기본 인증 시스템에서 일부 병목 현상을 줄이는 데 도움이 됩니다.
이러한 서비스는 일반적으로 OpenStack 서비스를 제공하는 인프라 노드에 배포되므로 memcached 또는 Redis를 사용하면 아키텍처의 전체 설계에 영향을 미치지 않습니다.
- 로드 밸런싱
많은 일반 용도의 배포가 하드웨어 로드 밸런서를 사용하여 고가용성 API 액세스 및 SSL 종료를 제공하지만 HAProxy와 같은 소프트웨어 솔루션도 고려할 수 있습니다. 소프트웨어 정의 로드 밸런싱 구현도 고가용성인지 확인해야 합니다.
Corosync를 사용하여 Keepalived 또는 Pacemaker와 같은 솔루션을 사용하여 소프트웨어 정의 고가용성을 구성할 수 있습니다. Pacemaker 및 Corosync는 OpenStack 환경의 특정 서비스에 따라 active-active 또는 active-passive 고가용성 구성을 제공할 수 있습니다.
이러한 애플리케이션은 컨트롤러 노드 중 하나가 대기 모드에서 서비스를 실행할 수 있는 두 개 이상의 노드가 있는 배포가 필요하기 때문에 설계에 영향을 미칠 수 있습니다.
- 로깅 및 모니터링
로그를 중앙 집중식 위치에 저장해야 분석을 더 쉽게 수행할 수 있습니다. 또한 로그 데이터 분석 엔진은 일반적인 문제를 경고하고 해결하기 위한 메커니즘에 자동화 및 알림을 제공할 수 있습니다.
아키텍처 설계의 기존 소프트웨어 및 하드웨어를 지원하는 경우 기본 OpenStack 로그 외에 외부 로깅 또는 모니터링 소프트웨어를 사용할 수 있습니다. Red Hat OpenStack Platform용 Operational Tools 리포지토리에는 다음과 같은 툴이 포함되어 있습니다.
3.10. 계획 도구
클라우드 리소스 계산기 툴을 사용하면 용량 요구 사항을 계산할 수 있습니다.
이 도구를 사용하려면 하드웨어 세부 정보를 시트에 입력합니다. 그런 다음 이 툴은 플레이버 변형을 포함하여 사용 가능한 인스턴스 수의 계산된 추정치를 표시합니다.
이 도구는 귀하의 편의를 위해서만 제공됩니다. Red Hat은 공식적으로 지원하지 않습니다.
4장. 아키텍처 예
이 장에서는 Red Hat OpenStack Platform 배포의 아키텍처 예에 대해 설명합니다.
이 가이드의 모든 아키텍처 예에서는 KVM 하이퍼바이저를 사용하여 Red Hat Enterprise Linux 7.2에 OpenStack Platform을 배포한다고 가정합니다.
4.1. 개요
일반적으로 배포는 성능 또는 기능을 기반으로 합니다. 배포는 배포된 인프라를 기반으로 할 수도 있습니다.
예 | 설명 |
---|---|
특정 기술 또는 환경 요구 사항이 확실하지 않은 경우 사용할 수 있는 일반적인 고가용성 클라우드입니다. 이 아키텍처 유형은 유연하며 단일 OpenStack 구성 요소를 강조하지 않으며 특정 환경에 국한되지 않습니다. | |
컴퓨팅 집약적인 워크로드를 지원하는 컴퓨팅 중심 클라우드. 컴퓨팅 집약적 워크로드는 중요한 데이터 계산, 암호화 또는 암호 해독과 같은 CPU 집약적임을 의미할 수 있습니다. 또한 메모리 내 캐싱 또는 데이터베이스 서버와 같은 RAM 집약적이거나 CPU 집약적이고 RAM 집약적임을 의미할 수도 있습니다. 일반적으로 스토리지 집약적이거나 네트워크 집약적인 것을 의미하지 않습니다. 고성능 컴퓨팅 리소스가 필요한 경우 이 아키텍처 유형을 선택할 수 있습니다. | |
HDFS 클러스터와 같은 대규모 데이터 세트의 관리 및 분석을 위해 설계된 성능 중심 스토리지 시스템입니다. 이 아키텍처 유형에서 OpenStack은 Cryostat와 통합되어, Ceph와 함께 DVR 클러스터를 스토리지 백엔드로 관리합니다. | |
데이터베이스 IO 요구 사항을 증가시키고 SSD(Solid-State Drive)를 사용하여 데이터를 처리하는 고성능 스토리지 시스템입니다. 기존 스토리지 환경에 이 아키텍처 유형을 사용할 수 있습니다. | |
일반적으로 OpenStack 배포에서 사용되는 클라우드 기반 파일 스토리지 및 공유 서비스입니다. 이 아키텍처 유형은 클라우드 트래픽에 들어오는 데이터가 발신 데이터보다 높은 클라우드 백업 애플리케이션을 사용합니다. | |
대규모 웹 애플리케이션을 위한 하드웨어 기반 로드 밸런싱 클러스터입니다. 이 아키텍처 유형은 SSL 오프로드 기능을 제공하며 테넌트 네트워크에 연결하여 주소 사용을 줄이고 웹 애플리케이션을 수평으로 확장합니다. |
4.2. General-Purpose 아키텍처
특정 기술 또는 환경 요구 사항이 확실하지 않은 경우 일반적인 고가용성 클라우드를 배포할 수 있습니다. 이러한 유연한 아키텍처 유형은 단일 OpenStack 구성 요소를 강조하지 않으며 특정 환경에 국한되지 않습니다.
이 아키텍처 유형은 다음을 포함하여 잠재적인 사용 사례의 80%를 다룹니다.
- 간단한 데이터베이스
- 웹 애플리케이션 런타임 환경
- 공유 애플리케이션 개발 환경
- 테스트 환경
- 스케일 업 추가 대신 스케일 아웃 추가 환경
이 아키텍처 유형은 보안이 필요한 클라우드 도메인에는 권장되지 않습니다.
설치 및 배포 문서는 5장. 배포 정보 에서 참조하십시오.
4.2.1. 사용 사례 예
온라인으로 분류된 광고 회사는 Apache Tomcat, Nginx 및 MariaDB를 프라이빗 클라우드에서 포함하는 웹 애플리케이션을 실행하려고 합니다. 정책 요구 사항을 충족하기 위해 클라우드 인프라는 회사 데이터 센터 내에서 실행됩니다.
이 회사는 예측 가능한 로드 요구 사항이 있지만 야간에 대응하기 위해 확장이 필요합니다. 현재 환경은 오픈 소스 API 환경 실행의 회사 목표에 맞게 유연하게 대응할 수 없습니다.
현재 환경은 다음 구성 요소로 구성됩니다.
- Nginx와 Tomcat의 120에서 140 사이의 설치, 각각 2개의 vCPU 및 4GB RAM
- 3-노드 MariaDB 및 Galera 클러스터, 각각 4개의 vCPU 및 8GB RAM이 있습니다. Pacemaker는 Galera 노드를 관리하는 데 사용됩니다.
이 회사는 웹 사이트를 제공하는 하드웨어 로드 밸런서 및 여러 웹 애플리케이션을 실행합니다. 환경 오케스트레이션에서는 스크립트와 Puppet의 조합을 사용합니다. 웹 사이트는 매일 많은 양의 로그 데이터를 생성하므로 보관해야 합니다.
4.2.2. 설계 정보
이 예제의 아키텍처에는 컨트롤러 노드 3개와 컴퓨팅 노드가 8개 이상 포함됩니다. 정적 오브젝트에 OpenStack Object Storage를 사용하고 다른 모든 스토리지 요구 사항에 OpenStack 블록 스토리지를 사용합니다.
OpenStack 인프라 구성 요소가 고가용성을 보장하기 위해 노드는 HAProxy와 함께 Red Hat Enterprise Linux에 Pacemaker 애드온을 사용합니다.
아키텍처에는 다음 구성 요소가 포함됩니다.
- 공용 네트워크 연결에 대한 방화벽, 스위치 및 하드웨어 로드 밸런서입니다.
- 지원 서비스 MariaDB 및 RabbitMQ와 결합된 이미지, ID 및 네트워킹을 실행하는 OpenStack 컨트롤러 서비스. 이러한 서비스는 3개 이상의 컨트롤러 노드에서 고가용성을 위해 구성됩니다.
- 클라우드 노드는 Red Hat Enterprise Linux용 Pacemaker 애드온을 사용하여 고가용성을 위해 구성됩니다.
- 컴퓨팅 노드는 영구 스토리지가 필요한 인스턴스에 OpenStack Block Storage를 사용합니다.
- 이미지와 같은 정적 오브젝트를 제공하는 OpenStack Object Storage.
4.2.3. 아키텍처 구성 요소
Component | 설명 |
---|---|
블록 스토리지 | 인스턴스용 영구 스토리지입니다. |
컴퓨팅 컨트롤러 서비스 | 컨트롤러에서 실행되는 컴퓨팅 관리 및 스케줄링 서비스. |
대시보드 | OpenStack 관리를 위한 웹 콘솔. |
ID | 사용자와 테넌트에 대한 기본 인증 및 권한 부여. |
이미지 | 인스턴스 부팅 및 스냅샷 관리에 사용할 이미지를 저장합니다. |
MariaDB | 모든 OpenStack 구성 요소에 대한 데이터베이스입니다. MariaDB 서버 인스턴스는 NetApp 또는 Solidfire와 같은 공유 엔터프라이즈 스토리지에 데이터를 저장합니다. MariaDB 인스턴스가 실패하면 스토리지를 다른 인스턴스에 다시 연결하고 Galera 클러스터에 다시 가입해야 합니다. |
네트워킹 | 플러그인 및 네트워킹 API를 사용하여 하드웨어 로드 밸런서를 제어합니다. OpenStack Object Storage를 늘리는 경우 네트워크 대역폭 요구 사항을 고려해야 합니다. 10GbE 이상의 네트워크 연결에서 OpenStack Object Storage를 실행하는 것이 좋습니다. |
오브젝트 스토리지 | 웹 애플리케이션 서버의 로그를 처리하고 아카이브합니다. 오브젝트 스토리지를 사용하여 OpenStack Object Storage 컨테이너에서 정적 웹 콘텐츠를 이동하거나 OpenStack Image에서 관리하는 이미지를 백업할 수도 있습니다. |
telemetry | 기타 OpenStack 서비스에 대한 모니터링 및 보고. |
4.2.4. 컴퓨팅 노드 요구 사항
Compute 서비스는 각 컴퓨팅 노드에 설치됩니다.
이 범용 아키텍처는 최대 140개의 웹 인스턴스를 실행할 수 있으며 적은 수의 MariaDB 인스턴스에는 292 vCPU 및 584GB RAM이 필요합니다. 하이퍼 스레딩이 있는 듀얼 소켓 16코어 Intel CPU가 있는 일반적인 1U 서버에서 2:1 CPU 오버 커밋 비율을 가정하면 이 아키텍처에는 8개의 컴퓨팅 노드가 필요합니다.
웹 애플리케이션 인스턴스는 각 컴퓨팅 노드의 로컬 스토리지에서 실행됩니다. 웹 애플리케이션 인스턴스는 상태 비저장이므로 인스턴스 중 하나가 실패하면 애플리케이션을 계속 실행할 수 있습니다.
4.2.5. 스토리지 요구 사항
스토리지의 경우 서버에 직접 연결된 스토리지가 포함된 확장 가능한 솔루션을 사용합니다. 예를 들어 그리드 컴퓨팅 솔루션과 유사한 방식으로 Compute 호스트에 스토리지를 채우거나 블록 스토리지를 독점적으로 제공하는 전용 호스트에서는 스토리지를 채울 수 있습니다.
Compute 호스트에 스토리지를 배포하는 경우 하드웨어가 스토리지 및 컴퓨팅 서비스를 처리할 수 있는지 확인합니다.
4.3. Compute-Focused Architecture
이 릴리스에서 셀은 기술 프리뷰로 사용할 수 있으므로 Red Hat에서 완전히 지원하지 않습니다. 테스트용으로만 사용해야 하며 프로덕션 환경에 배포해서는 안 됩니다. 기술 프리뷰 기능에 대한 자세한 내용은 적용 범위 상세 정보를 참조하십시오.
컴퓨팅 중심 클라우드는 데이터 계산 또는 암호화 및 암호 해독, 메모리 내 캐싱 또는 데이터베이스 서버와 같은 RAM 집약적 워크로드 또는 둘 다와 같은 CPU 집약적인 워크로드를 지원합니다. 이 아키텍처 유형은 일반적으로 스토리지 집약적이거나 네트워크 집약적이지 않으며 컴퓨팅 리소스의 성능이 필요한 고객에게 서비스를 제공합니다.
컴퓨팅 중심 워크로드에는 다음과 같은 사용 사례가 포함됩니다.
- 고성능 컴퓨팅(HPC)
- HDFS 또는 기타 분산 데이터 저장소를 사용한 빅 데이터 분석
- 연속 통합 또는 연속 배포(CI/CD)
- Platform-as-a-Service(Platform-as-a-Service)
- NFV(네트워크 기능 가상화)에 대한 신호 처리
컴퓨팅 중심 OpenStack 클라우드는 일반적으로 클라우드가 영구 블록 스토리지가 필요한 애플리케이션을 호스팅하지 않기 때문에 원시 블록 스토리지 서비스를 사용하지 않습니다. 워크로드가 필요에 따라 사용 가능한 리소스를 많이 사용할 수 있도록 인프라 구성 요소가 공유되지 않습니다. 인프라 구성 요소도 고가용성이어야 합니다. 이 설계에서는 로드 밸런서를 사용합니다. HAProxy를 사용할 수도 있습니다.
설치 및 배포 문서는 5장. 배포 정보 에서 참조하십시오.
4.3.1. 사용 사례 예
조직은 연구 프로젝트에 HPC를 제공하며 유럽의 두 개의 기존 컴퓨팅 센터에 세 번째 컴퓨팅 센터를 추가해야 합니다.
다음 표에는 추가할 각 컴퓨팅 센터의 요구 사항이 나열되어 있습니다.
데이터 센터 | 대략적인 용량 |
---|---|
Geneva, Switzerland |
|
Budapest, 헝가리 |
|
4.3.2. 설계 정보
이 아키텍처는 셀을 사용하여 컴퓨팅 리소스를 분리하고 서로 다른 데이터 센터 간의 투명한 확장을 위해 사용합니다. 이 결정은 보안 그룹 및 실시간 마이그레이션 지원에 영향을 미칩니다. 또한 셀 간에 플레이버와 같은 일부 구성 요소를 수동으로 복제해야 합니다. 그러나 셀은 단일 공용 API 끝점을 사용자에게 노출하는 동안 필요한 스케일링을 제공합니다.
클라우드는 두 개의 원래 데이터 센터 각각에 대해 컴퓨팅 셀을 사용하고 새 데이터 센터를 추가할 때마다 새 컴퓨팅 셀을 생성합니다. 각 셀에는 컴퓨팅 리소스를 추가로 분리하기 위한 3개의 가용성 영역과 고가용성을 위해 미러링된 큐로 클러스터링을 위해 구성된 3개 이상의 RabbitMQ 메시지 브로커가 포함되어 있습니다.
HAProxy 로드 밸런서 뒤에 있는 API 셀은 스위스의 데이터 센터에 있습니다. API 셀은 셀 스케줄러의 사용자 지정 변형을 사용하여 API 호출을 컴퓨팅 셀로 보냅니다. 사용자 지정을 사용하면 특정 워크로드가 특정 데이터 센터 또는 셀 RAM 가용성에 따라 모든 데이터 센터로 라우팅할 수 있습니다.
필터를 사용하여 셀의 배치를 처리하는 Compute 스케줄러를 사용자 지정할 수도 있습니다. 예를 들어 ImagePropertiesFilter 는 게스트가 실행하는 운영 체제(예: Linux 또는 Windows)를 기반으로 특수한 처리를 제공합니다.
중앙 데이터베이스 팀은 NetApp 스토리지 백엔드를 사용하여 활성/수동 구성으로 각 셀에서 SQL 데이터베이스 서버를 관리합니다. 백업은 6시간마다 실행됩니다.
4.3.3. 아키텍처 구성 요소
Component | 설명 |
---|---|
Compute | 컨트롤러에서 실행되는 컴퓨팅 관리 및 스케줄링 서비스. Compute 서비스는 각 컴퓨팅 노드에서도 실행됩니다. |
대시보드 서비스 | OpenStack 관리를 위한 GUI. |
ID 서비스 | 기본 인증 및 권한 부여 기능 |
이미지 서비스 | API 셀에서 실행되며 오케스트레이션 툴에서 애플리케이션을 배치할 수 있는 작은 Linux 이미지 세트를 유지 관리합니다. |
네트워킹 | 네트워킹 서비스. OpenStack 네트워킹에 대한 자세한 내용은 2장. 네트워킹 In-Depth 을 참조하십시오. |
모니터링 | 원격 분석 서비스는 미터링을 수행하여 분할되고 복제된 MongoDB 백엔드로 프로젝트 할당량을 조정합니다. API 로드를 분산하려면 Telemetry에서 쿼리할 수 있는 하위 셀에 openstack-nova-api 서비스의 인스턴스를 배포해야 합니다. 이 배포에는 하위 셀에서 ID 및 Image와 같은 지원 서비스 구성도 필요합니다. 캡처하기 위한 특정 중요한 메트릭에는 이미지 디스크 사용률 및 Compute API에 대한 응답 시간이 포함됩니다. |
오케스트레이션 서비스 | 새 인스턴스를 자동으로 배포 및 테스트합니다. |
Telemetry 서비스 | 오케스트레이션 자동 확장 기능을 지원합니다. |
오브젝트 스토리지 | 3 PB Ceph 클러스터로 오브젝트를 저장합니다. |
4.3.4. 설계 고려 사항
3장. 설계 에 설명된 기본 설계 고려 사항 및 3.2절. “컴퓨팅 리소스” 에 설명된 컴퓨팅 노드 설계 고려 사항 외에 컴퓨팅 집약적 아키텍처에서는 다음 항목을 고려해야 합니다.
- 워크로드
수명이 짧은 워크로드에는 일련의 컴퓨팅 집약적 작업을 수행하기 위해 다수의 컴퓨팅 인스턴스를 동시에 생성하는 CI-CD(연속 통합 및 연속 배포) 작업이 포함될 수 있습니다. 그러면 환경이 인스턴스를 종료하기 전에 각 인스턴스의 결과 또는 아티팩트를 장기 스토리지로 복사합니다.
Cryostat 클러스터 또는 HPC 클러스터와 같은 장기 워크로드는 일반적으로 대규모 데이터 세트를 수신하고 해당 데이터 세트에서 컴퓨팅 작업을 수행한 다음 결과를 장기 스토리지로 푸시합니다. 계산 작업이 종료되면 다른 작업을 수신할 때까지 인스턴스가 유휴 상태가 됩니다. 장기 워크로드의 환경은 더 크고 복잡한 경우가 많지만 작업 간에 활성 상태를 유지하여 이러한 환경 구축 비용을 상쇄할 수 있습니다.
컴퓨팅 중심 OpenStack 클라우드의 워크로드는 HDFS에서 일부 HDFS 사용을 제외하고 일반적으로 영구 블록 스토리지가 필요하지 않습니다. 공유 파일 시스템 또는 개체 저장소는 초기 데이터 세트를 유지 관리하고 계산 결과를 저장하는 대상 역할을 합니다. IIO(입력 출력) 오버헤드를 방지하면 워크로드 성능을 크게 향상시킬 수 있습니다. 데이터 세트의 크기에 따라 오브젝트 저장소 또는 공유 파일 시스템을 확장해야 할 수 있습니다.
- 확장 계획
클라우드 사용자는 필요에 따라 새 리소스에 즉시 액세스할 수 있습니다. 따라서 일반적인 사용법과 리소스 수요의 갑작스러운 급증을 계획해야합니다. 너무 보수적으로 계획하면 예기치 않은 초과 구독이 발생할 수 있습니다. 너무 공격적으로 계획하면 예기치 않은 클라우드 사용 불필요한 운영 및 유지 관리 비용이 발생할 수 있습니다.
확장 계획의 핵심 요소는 시간이 지남에 따라 클라우드 사용량의 추세를 분석하는 것입니다. 클라우드의 평균 속도 또는 용량 대신 서비스를 제공하는 일관성을 측정합니다. 이 정보는 용량 성능을 모델링하고 클라우드의 현재 및 향후 용량을 결정하는 데 도움이 될 수 있습니다.
모니터링 소프트웨어에 대한 자세한 내용은 3.9절. “추가 소프트웨어” 을 참조하십시오.
- CPU 및 RAM
현재 일반적인 서버 제품에는 최대 12개의 코어가 있는 CPU가 포함되어 있습니다. 또한 일부 Intel CPU는 코어 용량을 두 배로 늘리는 HTT(Hyper-Threading Technology)를 지원합니다. 따라서 HTT가 있는 여러 CPU를 지원하는 서버는 사용 가능한 코어 수를 곱합니다. HTT는 Intel CPU의 병렬 처리를 개선하는 데 사용되는 Intel 독점 멀티 스레딩 구현입니다. 다중 스레드 애플리케이션의 성능을 개선하려면 HTT를 활성화하는 것이 좋습니다.
CPU에서 HTT를 활성화하기로 결정하는 것은 사용 사례에 따라 다릅니다. 예를 들어 HTT를 비활성화하면 강력한 컴퓨팅 환경에 도움이 될 수 있습니다. HTT를 사용하거나 사용하지 않고 로컬 워크로드의 성능 테스트를 실행하면 특정 사례에 더 적합한 옵션을 결정하는 데 도움이 될 수 있습니다.
- 용량 계획
다음 전략 중 하나 이상을 사용하여 컴퓨팅 환경에 용량을 추가할 수 있습니다.
클라우드에 용량을 추가하여 수평으로 확장합니다. 라이브 마이그레이션 기능을 중단할 가능성을 줄이기 위해 추가 노드에서 동일한 CPU 또는 유사한 CPU를 사용해야 합니다. 하이퍼바이저 호스트를 확장하면 네트워크 및 기타 데이터 센터 리소스에도 영향을 미칩니다. 랙 용량에 도달하거나 추가 네트워크 스위치가 필요한 경우 이러한 증가를 고려하십시오.
참고노드를 적절한 가용성 영역 및 호스트 집계에 배치하는 데 필요한 추가 작업을 유의하십시오.
- 사용량을 지원하기 위해 내부 컴퓨팅 호스트 구성 요소의 용량을 늘려 수직으로 확장합니다. 예를 들어 CPU를 CPU로 더 많은 코어로 교체하거나 서버의 RAM을 늘릴 수 있습니다.
평균 워크로드를 평가하고 필요한 경우 초과 커밋 비율을 조정하여 컴퓨팅 환경에서 실행할 수 있는 인스턴스 수를 늘립니다.
중요컴퓨팅 중심 OpenStack 설계 아키텍처에서는 CPU 오버 커밋 비율을 늘리지 마십시오. CPU 초과 커밋 비율을 변경하면 CPU 리소스가 필요한 다른 노드와 충돌할 수 있습니다.
- 컴퓨팅 하드웨어
컴퓨팅 중심 OpenStack 클라우드는 프로세서 및 메모리 리소스에 대해 매우 까다로운 작업을 수행합니다. 따라서 더 많은 CPU 소켓, 더 많은 CPU 코어 및 RAM을 제공할 수 있는 서버 하드웨어에 우선순위를 지정해야 합니다.
네트워크 연결 및 스토리지 용량은 이 아키텍처에서 덜 중요합니다. 하드웨어는 최소 사용자 요구 사항을 충족하기에 충분한 네트워크 연결 및 스토리지 용량을 제공해야 하지만 스토리지 및 네트워킹 구성 요소는 주로 컴퓨팅 클러스터에 데이터 세트를 로드하고 일관된 성능이 필요하지 않습니다.
- 스토리지 하드웨어
오픈 소스 소프트웨어와 함께 상용 하드웨어를 사용하여 스토리지 어레이를 구축할 수 있지만 배포하려면 전문 지식이 필요할 수 있습니다. 서버에서 직접 연결된 스토리지 솔루션과 함께 스케일 아웃 스토리지 솔루션을 사용할 수도 있지만 서버 하드웨어가 스토리지 솔루션을 지원하는지 확인해야 합니다.
스토리지 하드웨어를 설계할 때 다음 요소를 고려하십시오.
- 가용성. 인스턴스를 고가용성 또는 호스트 간 마이그레이션할 수 있어야 하는 경우 임시 인스턴스 데이터에 공유 스토리지 파일 시스템을 사용하여 노드 장애 발생 시 계산 서비스가 중단되지 않도록 합니다.
- 대기 시간. SSD(Solid-state drive) 디스크를 사용하여 인스턴스 스토리지 대기 시간을 최소화하고 CPU 지연을 줄이며 성능을 향상시킵니다. 컴퓨팅 호스트에서 RAID 컨트롤러 카드를 사용하여 기본 디스크 하위 시스템의 성능을 개선하는 것이 좋습니다.
- 성능. 컴퓨팅 중심 클라우드에는 일반적으로 스토리지에 주요 데이터 I/O가 필요하지 않지만 스토리지 성능은 여전히 고려해야 할 중요한 요소입니다. 스토리지 I/O 요청의 대기 시간을 관찰하여 스토리지 하드웨어 성능을 측정할 수 있습니다. 일부 컴퓨팅 집약적 워크로드에서는 스토리지에서 데이터를 가져오는 동안 CPU가 경험하는 지연을 최소화하면 애플리케이션의 전반적인 성능을 크게 향상시킬 수 있습니다.
- 확장 가능성. 스토리지 솔루션의 최대 용량을 결정합니다. 예를 들어, 50PB로 확장되는 솔루션은 10PB로만 확장되는 솔루션보다 확장할 수 있습니다. 이 메트릭은 확장 시 솔루션 성능 척도인 확장성과 관련이 있지만 다릅니다.
- 연결. 연결이 스토리지 솔루션 요구 사항을 충족해야 합니다. 중앙 집중식 스토리지 어레이를 선택하는 경우 하이퍼바이저를 스토리지 어레이에 연결하는 방법을 결정합니다. 연결은 대기 시간과 성능에 영향을 줄 수 있습니다. 따라서 네트워크 특성이 환경의 전체 성능을 높이기 위해 대기 시간을 최소화해야 합니다.
- 네트워크 하드웨어
2장. 네트워킹 In-Depth 에 설명된 기본 네트워크 고려 사항 외에도 다음 요소를 고려하십시오.
- 필요한 포트 수는 네트워크 설계에 필요한 물리적 공간에 영향을 미칩니다. 예를 들어 1U 서버의 각 포트에 대해 48개의 포트가 10GbE 용량을 제공하는 스위치는 2U 서버의 각 포트에 대해 10GbE 용량을 제공하는 스위치보다 포트 밀도가 높습니다. 포트 밀도가 클수록 컴퓨팅 또는 스토리지 구성 요소에 더 많은 랙 공간을 사용할 수 있습니다. 또한 내결함성 도메인 및 전원 밀도도 고려해야 합니다. 비용이 많이 들더라도 기능 요구 사항 이상으로 네트워크를 설계해서는 안되므로 밀도가 높은 스위치도 고려할 수 있습니다.
- 리프스라인 모델과 같은 용량 및 대역폭을 추가하는 데 도움이 되는 확장 가능한 네트워크 모델로 네트워크 아키텍처를 설계해야 합니다. 이러한 유형의 네트워크 설계에서는 대역폭을 추가하고 추가 장비 랙으로 확장할 수 있습니다.
- 필요한 포트 수, 포트 속도 및 포트 밀도를 지원하는 네트워크 하드웨어를 선택하는 것이 중요하며 워크로드 요구 사항이 증가할 때 향후 증가할 수 있습니다. 또한 중복을 제공하는 것이 중요한 네트워크 아키텍처에서 위치를 평가하는 것도 중요합니다. 네트워크 가용성과 중복성은 비용이 많이 들 수 있으므로 추가 비용을 중복 네트워크 스위치 및 호스트 수준에서 본딩된 인터페이스의 이점과 비교해야 합니다.
4.4. 스토리지에서 사용되는 아키텍처
4.4.4절. “스토리지에서 사용되는 아키텍처 고려 사항”
4.4.1. 스토리지에서 사용되는 아키텍처 유형
클라우드 스토리지 모델은 물리적 스토리지 장치의 논리 풀에 데이터를 저장합니다. 이러한 아키텍처는 종종 통합 스토리지 클라우드라고 합니다.
클라우드 스토리지는 일반적으로 호스팅된 오브젝트 스토리지 서비스를 나타냅니다. 그러나 용어에는 서비스로 사용할 수 있는 다른 유형의 데이터 스토리지도 포함될 수 있습니다. OpenStack은 Block Storage(cinder) 및 Object Storage(swift)를 모두 제공합니다. 클라우드 스토리지는 일반적으로 가상 인프라에서 실행되며 인터페이스 접근성, 탄력성, 확장성, 멀티 테넌시 및 측정된 리소스의 광범위한 클라우드 컴퓨팅과 유사합니다.
온프레미스 또는 오프-프레미스 클라우드 스토리지 서비스를 사용할 수 있습니다. 클라우드 스토리지는 중복 및 데이터 배포로 높은 내결함성을 가지며 버전 지정된 사본으로 매우 내구성이 뛰어나며 일관된 데이터 복제를 수행할 수 있습니다.
클라우드 스토리지 애플리케이션의 예는 다음과 같습니다.
- 활성 아카이브, 백업 및 계층적 스토리지 관리
- 개인 DropBox 서비스와 같은 일반 콘텐츠 스토리지 및 동기화
- 병렬 파일 시스템을 통한 데이터 분석
- 소셜 미디어 백엔드 스토리지와 같은 서비스를 위한 비정형 데이터 저장소
- 영구 블록 스토리지
- 운영 체제 및 애플리케이션 이미지 저장소
- 미디어 스트리밍
- 데이터베이스
- 콘텐츠 배포
- 클라우드 스토리지 피어링
OpenStack 스토리지 서비스에 대한 자세한 내용은 1.2.2절. “OpenStack Object Storage(swift)” 및 1.2.1절. “OpenStack Block Storage(cinder)” 을 참조하십시오.
4.4.2. 데이터 분석 아키텍처
대규모 데이터 세트의 분석은 스토리지 시스템의 성능에 따라 크게 달라집니다. 병렬 파일 시스템은 고성능 데이터 처리를 제공할 수 있으며 대규모 성능 중심 시스템에 권장됩니다.
설치 및 배포 문서는 5장. 배포 정보 에서 참조하십시오.
4.4.2.1. 설계 정보
OpenStack Data Processing(sahara)은 HDFS와 통합되어 클라우드 내에서 HDFS 클러스터를 관리합니다. 다음 다이어그램에서는 고성능 요구 사항이 있는 OpenStack 저장소를 보여줍니다.
하드웨어 요구 사항 및 구성은 4.4.3절. “고성능 데이터베이스 아키텍처” 에 설명된 고성능 아키텍처와 유사합니다. 이 예에서 아키텍처는 캐싱 풀에 연결하고 사용 가능한 풀을 가속화하는 Ceph Swift 호환 REST 인터페이스를 사용합니다.
4.4.2.2. 아키텍처 구성 요소
Component | 설명 |
---|---|
Compute | 컨트롤러에서 실행되는 컴퓨팅 관리 및 스케줄링 서비스. Compute 서비스는 각 컴퓨팅 노드에서도 실행됩니다. |
대시보드 | OpenStack 관리를 위한 웹 콘솔. |
ID | 기본 인증 및 권한 부여 기능 |
이미지 | 인스턴스 부팅 및 스냅샷 관리에 사용할 이미지를 저장합니다. 이 서비스는 컨트롤러에서 실행되며 작은 이미지 세트를 제공합니다. |
네트워킹 | 네트워킹 서비스. OpenStack 네트워킹에 대한 자세한 내용은 2장. 네트워킹 In-Depth 을 참조하십시오. |
telemetry | 기타 OpenStack 서비스에 대한 모니터링 및 보고. 이 서비스를 사용하여 인스턴스 사용량을 모니터링하고 프로젝트 할당량을 조정합니다. |
오브젝트 스토리지 | HDFS 백엔드에 데이터를 저장합니다. |
블록 스토리지 | 0.0.0.0 백엔드와 함께 볼륨을 저장합니다. |
오케스트레이션 | 인스턴스 및 블록 스토리지 볼륨의 템플릿을 관리합니다. 자동 확장을 위해 Telemetry를 사용하여 스토리지 집약적인 처리를 위해 추가 인스턴스를 시작하려면 이 서비스를 사용합니다. |
4.4.2.3. 클라우드 요구 사항
요구 사항 | 설명 |
---|---|
성능 | 성능을 높이기 위해 특수 솔루션을 선택하여 디스크 활동을 캐시할 수 있습니다. |
보안 | 전송 중 및 미사용 중 데이터를 보호해야 합니다. |
스토리지 근접성 | 고성능 또는 대량의 스토리지 공간을 제공하려면 각 하이퍼바이저에 스토리지를 연결하거나 중앙 스토리지 장치에서 제공해야 할 수 있습니다. |
4.4.2.4. 설계 고려 사항
3장. 설계 에 설명된 기본 설계 고려 사항 외에도 4.4.4절. “스토리지에서 사용되는 아키텍처 고려 사항” 에 설명된 고려 사항도 따라야 합니다.
4.4.3. 고성능 데이터베이스 아키텍처
데이터베이스 아키텍처는 고성능 스토리지 백엔드의 이점을 제공합니다. 엔터프라이즈 스토리지는 필수 사항은 아니지만 많은 환경에 OpenStack 클라우드가 백엔드로 사용할 수 있는 스토리지가 포함되어 있습니다.
스토리지 풀을 생성하여 인스턴스 및 오브젝트 인터페이스에 OpenStack Block Storage에 블록 장치를 제공할 수 있습니다. 이 아키텍처 예에서 데이터베이스 I/O 요구 사항은 빠른 SSD 풀의 높은 스토리지입니다.
4.4.3.1. 설계 정보
스토리지 시스템은 기존 스토리지 어레이에서 SSD 세트와 함께 지원되는 LUN을 사용하며 OpenStack 블록 스토리지 통합 또는 Ceph와 같은 스토리지 플랫폼을 사용합니다.
이 시스템은 추가 성능 기능을 제공할 수 있습니다. 데이터베이스 예에서 SSD 풀의 일부가 데이터베이스 서버에 대한 블록 장치로 작동할 수 있습니다. 고성능 분석 예에서 인라인 SSD 캐시 계층은 REST 인터페이스를 가속화합니다.
이 예제에서 Ceph는 Swift 호환 REST 인터페이스와 분산 스토리지 클러스터의 블록 수준 스토리지를 제공합니다. 유연하며 자동 복구 및 자동 분산과 같은 기능을 통해 운영 비용을 줄일 수 있습니다. 코딩된 풀 삭제는 사용 가능한 공간을 극대화하는 것이 좋습니다.
코딩된 풀에는 높은 컴퓨팅 요구 사항 및 개체에서 작업을 허용하는 제한과 같은 특수한 고려 사항이 필요합니다. 코딩된 풀 삭제는 부분 쓰기를 지원하지 않습니다.
4.4.3.2. 아키텍처 구성 요소
Component | 설명 |
---|---|
Compute | 컨트롤러에서 실행되는 컴퓨팅 관리 및 스케줄링 서비스. Compute 서비스는 각 컴퓨팅 노드에서도 실행됩니다. |
대시보드 | OpenStack 관리를 위한 웹 콘솔. |
ID | 기본 인증 및 권한 부여 기능 |
이미지 | 인스턴스 부팅 및 스냅샷 관리에 사용할 이미지를 저장합니다. 이 서비스는 컨트롤러에서 실행되며 작은 이미지 세트를 제공합니다. |
네트워킹 | 네트워킹 서비스. OpenStack 네트워킹에 대한 자세한 내용은 2장. 네트워킹 In-Depth 을 참조하십시오. |
telemetry | 기타 OpenStack 서비스에 대한 모니터링 및 보고. 이 서비스를 사용하여 인스턴스 사용량을 모니터링하고 프로젝트 할당량을 조정합니다. |
모니터링 | 프로젝트 할당량을 조정할 목적으로 Telemetry 서비스를 사용하여 미터링을 수행합니다. |
오브젝트 스토리지 | Ceph 백엔드와 함께 데이터를 저장합니다. |
블록 스토리지 | Ceph 백엔드와 함께 볼륨을 저장합니다. |
오케스트레이션 | 인스턴스 및 블록 스토리지 볼륨의 템플릿을 관리합니다. 자동 확장을 위해 Telemetry를 사용하여 스토리지 집약적인 처리를 위해 추가 인스턴스를 시작하려면 이 서비스를 사용합니다. |
4.4.3.3. 하드웨어 요구 사항
SSD 캐시 계층을 사용하여 블록 장치를 하이퍼바이저 또는 인스턴스에 직접 연결할 수 있습니다. REST 인터페이스는 SSD 캐시 시스템을 인라인 캐시로 사용할 수도 있습니다.
Component | 요구 사항 | 네트워크 |
---|---|---|
수평으로 확장 가능한 스파인-리프트 백엔드 스토리지 및 프론트 엔드 네트워크 10GbE | 스토리지 하드웨어 | * 캐싱 계층 24x1 TB SSD를 위한 5 스토리지 서버 * 각 서버에 대해 12x4TB 디스크가 12x4TB인 10개의 스토리지 서버, 3개의 복제본 후 약 160TB의 사용 가능한 공간이 있는 480TB의 총 공간 |
4.4.3.4. 설계 고려 사항
3장. 설계 에 설명된 기본 설계 고려 사항 외에도 4.4.4절. “스토리지에서 사용되는 아키텍처 고려 사항” 에 설명된 고려 사항도 따라야 합니다.
4.4.4. 스토리지에서 사용되는 아키텍처 고려 사항
3장. 설계 에 설명된 기본 설계 고려 사항 및 3.3절. “스토리지 리소스” 에 설명된 스토리지 노드 설계 외에도 스토리지 집약적인 아키텍처에서는 다음 항목을 고려해야 합니다.
- 연결
- 연결이 스토리지 솔루션 요구 사항과 일치하는지 확인합니다. 중앙 집중식 스토리지 어레이를 선택하는 경우 하이퍼바이저를 배열에 연결하는 방법을 결정합니다. 연결은 대기 시간과 성능에 영향을 줄 수 있습니다. 네트워크 특성이 설계의 전반적인 성능을 높이기 위해 대기 시간을 최소화하는지 확인합니다.
- 밀도
- 인스턴스 밀도. 스토리지 중심 아키텍처에서는 인스턴스 밀도 및 CPU/RAM 초과 구독이 더 낮습니다. 특히 설계에서 듀얼 소켓 하드웨어 설계를 사용하는 경우 예상되는 규모를 지원하기 위해 더 많은 호스트가 필요합니다.
- 호스트 밀도. 쿼드 소켓 플랫폼으로 더 높은 호스트 수를 처리할 수 있습니다. 이 플랫폼은 호스트 밀도를 줄이고 랙 수를 늘립니다. 이 구성은 전원 연결 수에 영향을 미치며 네트워크 및 공약 요구 사항에도 영향을 미칩니다.
- 전력 및 연약. 전력 및 혼합 밀도 요구 사항은 블레이드, 슬라이 또는 1U 서버 설계보다 2U, 3U 또는 4U 서버로 더 낮을 수 있습니다. 이 구성은 이전 인프라가 있는 데이터 센터에 권장됩니다.
- 유연성
- 조직은 온프레미스 클라우드 스토리지 옵션과 온프레미스 클라우드 스토리지 옵션 중에서 선택할 수 있는 유연성을 갖추고 있어야 합니다. 예를 들어 운영, 재해 복구, 보안 및 기록의 연속성은 보존 법률, 규정 및 정책을 기록하여 스토리지 공급자의 비용 효율성에 영향을 미칠 수 있습니다.
- latency
- SSD(Solid-State Drive)는 인스턴스 스토리지의 대기 시간을 최소화하고 스토리지 대기 시간이 발생할 수 있는 CPU 지연을 줄일 수 있습니다. 컴퓨팅 호스트에서 RAID 컨트롤러 카드를 사용하여 기본 디스크 하위 시스템의 성능을 개선할 때의 이점을 평가합니다.
- 모니터 및 경고
모니터링 및 경고 서비스는 스토리지 리소스에 대한 높은 요구 사항이 있는 클라우드 환경에서 중요합니다. 이러한 서비스는 스토리지 시스템의 상태 및 성능에 대한 실시간 보기를 제공합니다. 통합 관리 콘솔 또는 SNMP 데이터를 시각화하는 다른 대시보드는 스토리지 클러스터 문제를 검색하고 해결하는 데 도움이 됩니다.
스토리지 중심 클라우드 설계에는 다음이 포함되어야 합니다.
- 온도 및 유해와 같은 물리적 하드웨어 및 환경 리소스 모니터링.
- 사용 가능한 스토리지, 메모리 및 CPU와 같은 스토리지 리소스 모니터링.
- 스토리지 시스템이 예상대로 수행되도록 고급 스토리지 성능 데이터 모니터링.
- 스토리지 액세스에 영향을 주는 서비스 중단에 대한 네트워크 리소스 모니터링.
- 중앙 집중식 로그 수집 및 로그 분석 기능.
- 티켓팅 시스템 또는 티켓팅 시스템과의 통합을 통해 문제를 추적합니다.
- 스토리지 문제가 발생할 때 문제를 해결할 수 있는 책임이 있는 팀 또는 자동화된 시스템에 대한 경고 및 알림.
- NOC(Network Operations Center) 직원이 근무하고 항상 문제를 해결할 수 있습니다.
- 스케일링
- 스토리지 중심 OpenStack 아키텍처는 확장 대신 확장에 중점을 두어야 합니다. 비용, 전력, 순환, 물리적 랙 및 플로어 공간, 지원 경고 및 관리 용이성과 같은 요인에 따라 더 적은 수의 대규모 호스트 또는 더 적은 수의 호스트를 확인해야 합니다.
4.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 옵션이 포함됩니다. 예를 들어 대부분의 웹 서비스 애플리케이션에는 전체 메시 오버레이 네트워크에 문제가 없으며 일부 네트워크 모니터링 도구 또는 스토리지 복제 워크로드에는 처리량 또는 과도한 브로드캐스트 트래픽과 관련된 성능 문제가 있습니다.
5장. 배포 정보
다음 표에는 이 가이드에 언급된 구성 요소에 대한 배포 참조가 포함되어 있습니다.
Red Hat OpenStack Platform에 대한 추가 설명서는 https://access.redhat.com/documentation/en-US/Red_Hat_OpenStack_Platform/에서 확인할 수 있습니다.
Component | 참조 |
---|---|
Red Hat Enterprise Linux | Red Hat OpenStack Platform은 Red Hat Enterprise Linux 7.2 이상에서 지원됩니다. Red Hat Enterprise Linux 설치에 대한 자세한 내용은 https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/ 에서 해당 설치 가이드를 참조하십시오. |
OpenStack | OpenStack 구성 요소 및 해당 종속 항목을 설치하려면 Red Hat OpenStack Platform director를 사용합니다. director는 기본 OpenStack 언더클라우드 를 사용합니다. 이 언더클라우드는 최종 오버클라우드 에서 OpenStack 노드를 프로비저닝하고 관리하는 데 사용됩니다. 배포된 오버클라우드에 필요한 환경 외에도 언더클라우드 설치를 위해 하나의 추가 호스트 시스템이 필요합니다. 자세한 내용은 Red Hat OpenStack Platform Director 설치 및 사용을 참조하십시오. |
고가용성 | 추가 고가용성 구성 요소(예: HAProxy)의 구성은 Ceph Storage를 사용하여 고가용성 Red Hat OpenStack Platform 6 배포를 참조하십시오. 실시간 마이그레이션 구성에 대한 자세한 내용은 인스턴스 및 이미지 관리를 참조하십시오. |
LBasS | Load Balancing-as-a-Service를 사용하려면 네트워킹 가이드의 "Load Balancing-as-a-Service 구성"을 참조하십시오. |
Pacemaker | Pacemaker는 Red Hat Enterprise Linux에 애드온으로 통합되어 있습니다. 고가용성을 위해 Red Hat Enterprise Linux를 설정하려면 고가용성 애드온 개요 를 참조하십시오. |