오픈스택 아키텍처

VM 프로비저닝

• VM을 실행하는 과정은 Nova, Neutron, Cinder, glance등 인스턴스의 구성 요소를 형성하는 주요 서비스들의 상호작용임
• 프로비저닝:
  • 사용할 준비가 되도록 자원을 할당하고, 필요한 설정이나 소프트웨어까지 포함해 배포하는 일련의 과정
• ex)

• 사용자가 CLI 또는 대시보드(Horizon)을 통해 Nova API에 VM 생성을 요청함
• Nova API는 keystone을 통해 사용자 인증 및 권한 부여를 확인함
• Nova API는 glance에 이미지 정보를 요청하고, cinder에 볼륨을 생성하도록 요청함
• Nova API는 메시지 버스를 통해 Nova-scheduler에 VM 배치를 요청함
• Nova-scheduler는 Compute node의 리소스 상태를 확인하고 최적의 node를 선택함
• Nova-compute 서비스는 선택된 compute node에서 가상 머신을 시작함
  • 이 과정에서 neutron은 네트워킹 구성을 제공하고, glance는 VM 이미지를 전달함
• 이러한 모든 API 호출 및 서비스 요청에서 token 관리는 시간 제한이 있는 작업임
• openstack에서 프로비저닝 작업 실패 원인 중 하나는 후속 API 호출 중에 토큰이 만료되는 것 때문임
  • 그러나 Kilo 릴리스부터 Fernet토큰이 도입되어 토큰 성능 문제를 향상 시킴
  • Fernet토큰은 keystone내에서 사용자 ID, 권한 부여 범위, 만료 시간을 암호화하여 생성되며,
  • 데이터베이스에 저장될 필요가 없어 효율적임

 

Openstack 배포

개념 모델 설계

• openstack의 주요 구성 요소들을 일반적인 클래스(ex: compute, storage, identity...)로 매핑함

논리 모델 설계

• 개념적 설계를 바탕으로 openstack 핵심 구성 요소들 간의 관계와 의존성을 나타냄
• 고가용성(HA) 설정을 위해 이중화(redundancy)를 달성해야 하며, DB 및 메시지 큐와 같은 핵심 openstack 서비스는 별도로 클러스터링되거나 자체 패키징 될 수 있음
• HAProxy 및 Pacemaker와 같은 솔루션이 고확장성 및 이중화 환경을 위해 사용될 수 있음
• VM 워크로드를 실행하는 데 중점을 두므로 비교적 간단하며, nova-compute 서비스와 neutron에이전트 등이 실행될 수 있음

HAProxy란?

• HAProxy(High Availability Proxy)는 웹서버, API 서버 등 앞단에서 동작하는 오픈소스 로드밸런서
• 웹서비스, 클라우드, OpenStack 컨트롤러 등 어디서든 서버 여러 대를 하나의 주소(가상IP)로 묶고, 사용자 요청을 알아서 분배함

Pacemaker란?

• Pacemaker는 리눅스에서 사용하는 고가용성(HA) 클러스터 관리 도구
• 여러 대의 서버를 클러스터로 묶고, 어떤 서버에 장애가 나도 다른 서버가 즉시 자동으로 서비스(가상 IP, DB, 애플리케이션 등)를 대신 운영하도록 만들음
• OpenStack, 데이터베이스, 네트워크 장비 등 서비스 장애 시 자동으로 다른 노드에서 서비스를 재가동(Failover)함

 

---

물리적 네트워크 레이아웃(Physical network layout)

• 테넌트 데이터 네트워크(Tenant data network)
  • openstack 테넌트가 생성한 가상 네트워크를 위한 물리적 경로를 제공한다는 것임
  • 테넌트 데이터 트래픽을 openstack 구성 요소 간 통신에 필요한 인프라 통신 경로로부터 분리함
• 관리 및 API 네트워크
  • 소규모 배포에서는 관리 및 openstack 구성 요소 간 통신 트래픽이 동일한 물리적 링크에 있을 수 있음
  • 이 물리적 네트워크는 REST API 액세스 및 DB 트래픽과 같은 다양한 OpenStack 구성 요소 간 통신 경로뿐만 아니라 OpenStack 노드 관리를 위한 경로를 제공함
  • 프로덕션 환경의 경우, 트래픽 격리를 개선하고 개별 네트워크의 부하를 억제하기 위해 네트워크를 더 세분화할 수 있음
• 스토리지 네트워크
  • 스토리지 네트워크는 VM과 스토리지 서버 간의 스토리지 관련 트래픽에 대한 물리적 연결 및 격리를 제공함
  • 스토리지 네트워크의 트래픽 부하가 상당히 높기에, 스토리지 네트워크 부하를 관리 및 테넌트 트래픽으로부터 격리하는 것이 좋음

가상 네트워크 유형(Virtual Network types)

• External network
  • 인터넷에서 볼 수 있고 라우팅 가능해야 함
  • 라우팅 가능한 서브넷 블록을 사용해야 함
  • openstack 환경으로 인터넷 라우팅을 위한 기본 게이트웨이를 제공해야 함
  • 인스턴스에 플로팅 IP를 할당하여 공개적으로 액세스 할 수 있도록 할 수 있음
• Tenant network
  • 테넌트 네트워크는 테넌트가 생성하는 가상 네트워크
  • 이는 사설 IP 주소를 사용하며, 이 주소는 인스턴스 내에서 가시적이며, 테넌트의 인스턴스가 다른 테넌트의 트래픽으로부터 격리를 유지하면서 통신할 수 있도록 함
  • 사설 IP 주소는 인터넷에 노출되지 않음

네트워킹 설계

• openstack 네트워킹 관리를 위해 nova-network와 neutron 중에서 선택할 수 있음
• 대규모 환경 배포를 목표로 할때는 neutron이 더 유연하고 확장성이 뛰어남
• Neutron OSI 모델의 Layer2와3을 가상화하며, VLAN 기반 네트워크와 터널링 기반 네트워크(GRE,VXLAN 등)을 지원함
• 터널링 기반 네트워크는 훨씬 더 많은 테넌트 네트워크를 생성할 수 있지만, VLAN 기반 네트워크가 더 나은 성능을 보일 수 있음
• 물리적 네트워크 레이아웃에서는 다른 유형의 트래픽을 처리하기 위해 관리 네트워크, API 네트워크, 테넌트 데이터 네트워크, 외부 네트워크 등을 분리하는 것이 좋음

물리적 모델 설계

• 논리적 설계를 실제 물리적 설계로 구현함
• 하드웨어 성능 예측 (Estimating the HW Capabilities)
  • 인프라 경제성을 예측하기 위해 CPU, RAM, 네트워크, 디스크와 같은 리소스에 대한 용량 계획을 수립하는 것이 중요함
  • IT 위험을 줄이고 고객 요구에 신속하게 대응하는 데 도움이 됨
• CPU 계산
  •  CPU 초과 구독(oversubscription)을 하지 않는 200개의 VM을 기준으로 약 7~8개의 듀얼 소켓 서버가 필요하며, 서버당 25개의 가상 머신을 배포할 수 있음
• 메모리 계산
  •  컴퓨트 노드당 25개의 VM과 VM당 2GB RAM을 할당한다면, 컴퓨트 노드당 200GB의 RAM이 필요하며, 이는 16GB 스틱 16개에 해당함
• 네트워크 계산
  • VM당 200Mbits/초가 필요하며, 각 서버에 10GB 링크를 사용하면 만족스러운 값을 제공
  • 고가용성 네트워크 아키텍처를 위해 최소 24포트의 데이터 스위치 2개(또는 48포트 스위치 2개)를 계획하고, NIC 본딩을 통해 대역폭을 늘릴 수 있음
• 스토리지 계산
  • 컴퓨트 노드당 25개의 VM을 위해 초기 스토리지를 계획해야함
  • VM당 100GB의 임시 스토리지(ephemeral storage)를 가정하면 각 컴퓨트 노드에 2.5TB의 로컬 스토리지가 필요하고, VM당 250GB의 영구 스토리지(persistent storage)를 가정하면 5TB의 영구 스토리지가 필요함
  • 오브젝트 스토리지의 복제는 필요한 공간의 3배를 사용하므로, 50TB의 오브젝트 스토리지를 계획하면 총 150TB의 저장 공간이 필요함
  • 더 나은 IOPS를 위해 SSD 투자를 고려할 수도 있음