OpenStack Example Architecture

OpenStack Example Architecture

OpenStack Operation Guide를 참조하여 내게 필요한 Example Architecture 구성 자료 작성해 보았습니다.

1.Preface

  • 해당 문서는 OpenStack Havana Version을 기준으로 Architecture 구성에 대한 예제를 작성한 것임

1.1. 개념의 이해

1.1.1. 클러스터

  • 클러스터링은 목적에 따라 하나의 작업을 여러대의 컴퓨터에서 병렬형으로 분산처리해 전체적인 처리율을 높이기 위한 병렬처리(parallel processing) 클러스터링
  • 클러스터 내의 여러 컴퓨터들의 작업이 중단되지 않고 지속적으로 수행하게 하는 고가용(HA:High Availability) 클러스터링

1.1.1.1. 병렬처리 클러스터링

  • 대표적인 것은 MPP(Massive Parallel Processing)다. 그러나 MPP시스템에서 높은 성능을 얻기 위한 애플리케이션은 각 노드간에 교환되는 데이타를 최소화할 수 있도록 잘 분리돼야 한다.
  • 이런 이유로 인해 데이터 공유가 필수적이고 빠른 응답시간을 요구하는 OLTP 애플리케이션들은 MPP시스템에 적합하지 않으며, 주로 계산위주의 고급 연산에 사용된다.

1.1.1.2. HA 클러스터링

  • SPOF(Single Point Of Failure)를 방지하는 고가용성 구현을 위한 목적이다. 클러스터의 어떤 노드에 장애가 발생하더라도 클러스터 환경은 ‘Fail over’ 기능에 의해 그 장애를 고립화시켜 전체 시스템이 장애없이 가동될 수 있으며, 해당 노드의 장애가 복구되면 곧바로 클러스터 시스템에 다시 합류하게 된다. 일반적으로 클러스터링이라 하면 바로 HA 클러스터링을 지칭하는 것이다.






2.Architecture

  • OpenStack Logical Architecture

2.1. Example Architecture

2.1.1. Example Architecture—Legacy Networking (nova)

2.1.1.1. Overview

  • single cloud controller와 multiple compute 노드 기반의 단순한 architecture
  • 5개의 노드를 가진 Object Storage
  • 사용자와 API 요청에 대한 proxying 인증
  • 복제를 제공하는 4개의 스토리지 노드
2.1.1.1.1. Components

Component
Details
OpenStack release
Havana
Host operating system
Ubuntu 12.04 LTS or Red Hat Enterprise Linux 6.5, including derivatives such as CentOS and Scientific Linux
OpenStack package repository
Hypervisor
KVM
Database
MySQL*
Message queue
RabbitMQ for Ubuntu; Qpid for Red Hat Enterprise Linux and derivatives
Networking service
nova-network
Network manager
FlatDHCP
Single nova-network or multi-host?
multi-host*
Image Service (glance) backend
file
Identity Service (keystone) driver
SQL
Block Storage Service (cinder) backend
LVM/iSCSI
Live Migration backend
Shared storage using NFS*
Object storage
OpenStack Object Storage (swift)

  • 기본 설치에서 벗어난 셋팅에 대해서는 별표(*) 표시 해두었다
  • Note
    • Floating IP address
      • public IP 주소 할당
      • 미리 정의된 IP 주소 풀에서 실행중인 VM에 IP 할당
    • Live migration
      • 동작중인 instance를 서비스 중단 없이 이관 가능
2.1.1.1.2. Rationale
  • OpenStack은 다양한 배포판에서 동작 하도록 지원하지만 개발자 커뮤니티에서 주로 사용되는 Ubuntu 12.04 LTS 버전을 사용
  • Ubuntu OpenStack install packages 대신 Ubuntu Cloud Archive 사용을 추천
  • KVM은 Ubutu 선택에 따른 완벽한 hypervisor
  • Mysql database는 OpenStack에 있어 많이 테스트 되었고 문서화도 잘되어 있음
  • RabbitMQ를 클러스터링 한 구성을 추천
  • Live Migration은 분산 파일 시스템으로 NFS와 공유 스토리지의 방법으로 지원
  • Block Storage(cinder)는 외장 스토리지 노드에 기본적으로 설치 되었고 LVM/iSCSI 플러그 인을 사용
2.1.1.1.3. Why use multi-host networking?
  • OpenStack 기본 설치 시 nova-network 서비스가 동작 해당 서비스에서는 NAT(network address translation), DHCP and DNS 서비스를 guest instance에 제공
  • 단일 노드에서 novanetwork에 실행 중 장애가 발생되면 해당 instance들은 인터넷에 접근이 불가(단일 Fail off)
  • 과도한 네트워크 traffic 이 발생하고 클라우드에서 벗어나게 된다면, 단일 node에서  nova-network 서비스만 제공되므로 병목 현상이 발생
  • Multi-host
    • 하나의 노드에서 nova-network 서비스가 동작하는 것 대신에 모든 compute node에서 nova-network 서비스가 동작

2.1.1.2. Detailed Description

  • 전체 구성 정보
  • 기본 구성
    • multiple compute node를 고려하여,  control node, instance 스토리지를 위한 외장 NFS, volume 스토리지를 위한 Block Storage server 구성
    • 모든 노드들은 시간 동기화가 이루어져야 함
  • Node 구성
    • Cloud controller 동작하는 서비스
      • API services
      • database (MySQL)
      • message queue server (RabbitMQ)
      • scheduler for choosing compute resources( nova-scheduler )
      • Identity services (keystone, nova-consoleauth )
      • Image services( glance-api , glance-registry )
      • services for console access of guests
      • Block Storage services
      • scheduler for storage resources ( cinder-api and cinder-scheduler )
    • Compute node
      • hypervisor (KVM)
      • libvirt
        • the driver for the hypervisor,which enables live migration from node to node
      • nova-compute
      • nova-api-metadata
        • (generally only used when running in multi-host mode, it retrieves instance-specific metadata)
      • nova-vncproxy
      • nova-network
    • network
      • network 구성
        • 하나의 manage network 또는 private network
        • floating IP를 포함한 public network
      • controller , compute node들은 각각 2개의 NIC가 필요
      • OpenStack Block Storage and NFS storage 서버는 private network만 필요하며 nic card를 bonding 하여 사용할 것을 권장
      • Flating IP는 NAT를 통해 인터넷에 직접 접근
  • Compute Node 구성 정보

2.1.1.X. Nova-Network와 Neutron 비교 분석



2.1.2. Example Architecture—OpenStack Networking

  • OpenStack Networking을 사용한 Exam Architecture

2.1.2.1. Overview

  • 해당 구성은 수평 확장 가능한 구조와 node fail에 따르 고가용성 환경을 구성을 위한 Architecture
  • Havana version을 예제로 구성
2.1.2.1.1. Components

Component
Details
OpenStack release
Havana
Host operating system
Red Hat Enterprise Linux 6.5
OpenStack package repository
Red Hat Distributed OpenStack (RDO)
Hypervisor
KVM
Database
MySQL
Message queue
Qpid
Networking service
OpenStack Networking
Tenant Network Separation
VLAN
Image Service (glance) backend
GlusterFS
Identity Service (keystone) driver
SQL
Block Storage Service (cinder) backend
GlusterFS

2.1.2.1.2. Rationale
  • RDO
    • Red Hat Distributed OpenStack package
  • KVM
    • 라이센스에 제한이 없는 hypervisor
  • Qpid
    • Apache Qpid는 Advanced Message Queuing Protocol Standard를 안정적으로 제공
  • OpenStack Networking
    • Layer 2 (L2) network을 포함하여 network제공 및 분리 기능
  • VLAN
  • GlusterFS
    • scale out storage

2.1.2.2. Detailed Description

2.1.2.2.1. Node types

Type
Description
Example hardware
Controller
  • Contorller node는 OpenStack 관리 소프트웨어 서비스가 동작
  • 관련된 기능
    • 사람들이 접근 가능한 API 서비스 외 다른 기능들을 제공
    • 고가용성 서비스
      • Pacemaker
      • HAProxy
      • 가상 IP와 load-balancing 기능 제공
    • 고가용성 기능이 제공되는 infrastructure 서비스
      • MySQL
      • Qpid
Model: Dell R620
CPU: 2x Intel® Xeon® CPU E5-2620 0 @ 2.00 GHz
Memory: 32 GB
Disk: two 300 GB 10000 RPM SAS Disks
Network: two 10G network ports
Compute
  • Compute node는 OpenStack 에서 가상 머신 인스턴스가 동작
    • 최소한의 서비스로 동작
    • 노드 장애시 VM 마이그레이션과 인스턴스 복구를 사용되지 않기 위해 Node의 로컬 스토리지를 사용
Model: Dell R620
CPU: 2x Intel® Xeon® CPU E5-2650 0 @ 2.00 GHz
Memory: 128 GB
Disk: two 600 GB 10000 RPM SAS Disks
Network: four 10G network ports (For future proofing expansion)
Storage
  • Storage node는 환경에서 필요한 모든 데이터를 저장
    • 이미지 서비스에 사용되는 디스크 이미지
    • Block Storage 서비스에서 생성된 지속적으로 저장되는 볼륨 정보
  • Storage node는 고가용성과 확장성을 위해 GlusterFS 기술을 사용
Model: Dell R720xd
CPU: 2x Intel® Xeon® CPU E5-2620 0 @ 2.00 GHz
Memory: 64 GB
Disk: two 500 GB 7200 RPM SAS Disks and twenty-four 600 GB 10000 RPM SAS Disks
Raid Controller: PERC H710P Integrated RAID Controller, 1 GB NV Cache
Network: two 10G network ports
Network
  • Network Node는 공용 또는 사설 네트워크를 생성하고 외부에 자신의 가상 컴퓨터를 업 링크 명에 필요한 모든 가상 네트워킹을 수행
    • OpenStack 상단의 실행중인 인스턴스에서 ingress 와 egress point를 두어 방화벽을 형성
    • 네트워킹 API 서비스를 제외한 환경의 네트워킹 서비스를 모두 동작(컨트롤러 노드에서 실행)
Model: Dell R620
CPU: 1x Intel® Xeon® CPU E5-2620 0 @ 2.00 GHz
Memory: 32 GB
Disk: two 300 GB 10000 RPM SAS Disks
Network: five 10G network ports
Utility
  • Utility node는 실행되는 하드웨어, OS, 소프트웨어 및 유지에 필요한 실행 환경을 얻을 수 있음
  • 기본적인 시스템 관리 기능들을 제공하기 위해 내부 관리 직원에 의해 사용
  • 동작하는 서비스
    • provisioning
    • 설정 관리
    • 모니터링
    • GlusterFS 관리
Model: Dell R620
CPU: 2x Intel® Xeon® CPU E5-2620 0 @ 2.00 GHz
Memory: 32 GB
Disk: two 500 GB 7200 RPM SAS Disks
Network: two 10G network ports

2.1.2.2.2. OpenStack internal network
  • 내부 네트워크에서 사용되는 기능과 traffic 정보
    • 물리 노드에서 provisioning 이 필요한 서비스 포함
      • pxe
      • tftp
      • kickstart
    • 다양한 OpenStack node 타입 사이에서 사용되는 OpenStack API와 messages
      • nova-compute와 keystone 통신
      • cinder-volume과 nova-api 통신
    • Storage 데이타에 사용되는 traffic
      • Gluster protocol
  • 모드 물리적 노드는 적어도 하나 이상의 network가 내부 네트워크에 연결 되어야 함
  • 해당 네트워크는 22 번 port를 사용하여 접근 가능
2.1.2.2.3. Public Network
  • 공인 네트워크
    • controller node상에서 공인망에 사용되는 IP 주소
    • floating IP를 위해 OpenStack Networking에 사용되는 IPv4 network 주소
      • IPv4 주소로 접근이 제한됨
      • 광범위한 IPv4 주소 불필요
    • OpenStack 내에 생성된 사설 네트워크들의 라우터 기능
2.1.2.2.4. VM traffic network
  • 닫쳐진 network로 공용 네트워크로 routing 되지 않는 사설, 내부 네트워크
  • OpenStack 내에서 가성 머신 사이의 traffic
  • 공인 네트워크를 통해 나가기 위한 L3 router를 제공하기 위한 가상 머신과 네트워크 노드 사이의 traffic
  • Compute와 OpenStack Networking node들은 이 네트워크에 대해서 접근이 필요
2.1.2.2.5. Node connectivity
  • Network에 연결 시 network bonding과 같은 사항을 고려 해야 함
2.1.2.2.6. Initial deployment
  • Ininital deployment 구성
    • 처음에는 연결 설정은 연결 유지을 중심으로 설정
    • 연결 배치 복잡성과 배포하는 시간을 최소화하기 위해 단순하고 간단하게 설정
    • 최대 성능을 위해 적절한 노드에서 network bonding을 활용하여 모든 compute node에 사용 가능한 1 * 10G network  연결하여 설정
  • Basic node deployment

2.1.2.2.7. Connectivity for maximum performance
  • 기본 레이아웃의 네트워킹 성능이 충분하지 않은 경우, Storage layer에 더 많은 네트워크 대역폭을 제공 할뿐만 아니라 환경의 모든 인스턴스에 2 × 10G 네트워크 링크를 제공하도록 설정
  • Performance node deployment

2.1.2.2.8. Node diagrams
  • 다이어그램은 서비스의 가용성과 확장 성을 달성하는 방법을 알려줌
2.1.2.2.8.1. Controller node
2.1.2.2.8.2. Compute node
2.1.2.2.8.3. Network node
2.1.2.2.8.4. Storage node



(Havana Release)

2.1.2.3. Example Component Configuration

2.1.2.3.1. Third party component configuration
Component
Tuning
Availability
Scalability
MySQL
binlog-format = row
  • Pacemaker with DRBD
    • Pacemaker 가상 IP로 DB 접속이 이루어짐, Database는 비동기식 복제로 구현.
  • Mysql for galera
    • 예제에서는 나오지 않지만 cluster로 구현 하는 인터넷 예제도 있음
  • 확장성이 크게 고려 되지 않음
  • 멀티 마스터 또는 마스터/ 슬레이브 설정이 하여, 충분히 확장 가능하게 MySQL 서버를 일단 로드.
Qpid
max-connections=1000 worker-threads=20connection-backlog=10, sasl security enabled with SASL-BASIC authentication
  • Qpid는 Controller node들에 위치하여 해당 node에서 동작하는 Pacemaker software의 자원으로 추가 할 수 있음.
  • 오직 하나의 Qpid 인스턴스가 동작하고, Pacemaker 가상 IP를 사용하는 노드는 항상 Qpid를 동작.
  • 확장성이 크게 고려 되지 않음
  • 가용성의 목적으로 Qpid는 모든 controller node에서 동작 할 수 있음.(Pacemkaer에서는 제거되어야 함)
HAProxy
maxconn 3000
  • HAProxy는 OpenStack API 컴퍼넌트들과 SSL termination에서 앞단에서 Layer-7 load balancer로 사용됨.
  • HAProxy는 Controller node들에 위치하여 해당 node에서 동작하는 Pacemaker software의 자원으로 추가 할 수 있음.
  • 오직 하나의 HAProxy 인스턴스가 동작하고, Pacemaker 가상 IP를 사용하는 노드는 항상 HAProxy를 동작.
  • 확장성이 고려 되지 않음
  • HAProxy는 작은 만큼 성능 오버헤드가 있음, 단일 인스턴스는 이 workload에서 사용되기에 충분한 확장성을 지님.
  • 추가 확장이 필요한 경우 HAProxy 여분을 앞단에  복사하여 keepalived 또는 Layer-4 Load balancing 형태로 제공될 수 있음
Memcached
MAXCONN="8192" CACHESIZE="30457"
  • Memcached는 caching data와 성능 향상을 위한 OpenStack 컴퍼넌트에 사용되는 Software
  • 빠른 in-memory key-value 형태의 cache software
  • Memcached는 모든 노드에서 동작하며, 해당 서비스가 down 되는 경우 다른 Memcached instance를 사용 가능.
  • 확장성이 고려 되지 않음
  • Memcached 단일 인스턴스는 workload의 부하를 확장 할 수 있어야 함.
  • 확장이 요구될 경우, multiple Memcached instance를 사용하기 위해 Memcached 앞 단에 HAProxy를 설정 해야 함.
    • 하지만 cache 일관성의 문제가 발생할 수 있음.
Pacemaker
Configured to use corosync and cman as a cluster communication stack/quorum manager, and as a two-node cluster.
  • Pacemaker는 controller과 network 노드 위에 동작하여 가용성을 위한 clustering software.
    • Pacemaker는 cluster software이기에 corosync와 cman을 활용하여 다루어야 함
    • GlusterFS native client를 사용하는 경우, virtual IP필요 하지 않음.
      • client가 모든  node의 접속 정보를 알고 있기에 clinet쪽에서 경로 실패시 자동적으로 다른곳으로 바뀜
      • NFS또는 SMB를 사용하는 경우 GlusterFS volume을 mount하기 위한 가상 IP정보가 필요
  • 더 많은 노드가  클러스터 인식할 필요가 있는 경우, Pacemaker는 64개의 노드까지 확장 가능
GlusterFS
glusterfs performance profile "virt" enabled on all volumes. Volumes are setup in two-node replication.
  • Glusterfs는 cluster된 파일 시스템으로 storage노드 위에서 동작하며 지속적이과 확장 가능한 데이타 저장 공간을 제공하는 환경에 사용.
  • Gluster 대한 모든 연결이 gluster native mount point를 사용하기 때문에 gluster 인스턴스 자체는 가용성 및 장애 복구 기능을 제공.
  • GlusterFS storage 의 확장성은 storage 볼륨 추가로 달성할 수 있음.

2.1.2.3.2. OpenStack component configuration
2.1.2.3.2.1. Component Tuning point

Component
Node type
Tuning
Dashboard (horizon)
Controller
  • session 저장소로서의 Memcached 사용 설정
  • neutron 지원 활성화
  • can_set_mount_point = False
Identity (keystone)
Controller
  • 토큰 PKI와 caching Memecached 사용을 위한 설정
Image Service (glance)
Controller
  • /var/lib/glance/images는 GlusterFS native로 저장 계층에 gluster volume을 마운트 함
Compute (nova)
Controller, Compute
  • Qpid 사용 하도록 설정
    • qpid_heartbeat =10
  • caching Memcached  사용 하도록 설정
  • libvirt 사용 하도록 설정
  • neutron 사용 하도록 설정
  • 세션 관리 Memcached 사용 하도록 nova-consoleauth 설정
    • load balancer에서 동작하여 세션 정보가 다중으로 복사되어야 함
Block Storage (cinder)
Controller
  • Qpid 사용 하도록 설정
    • qpid_heartbeat =10
  • Gluster native client를 사용하여 Block Storage를 위한  backend 저장 공간으로 Gluster volume을 사용 하도록 설정
OpenStack Networking (neutron)
Controller, Compute, Network
  • Qpid 사용 하도록 설정
    • qpid_heartbeat =10
  • kernel namespace 지원 활성화
  • tenant_network_type = vlan
  • allow_overlapping_ips = true
  • tenant_network_type = vlan
  • bridge_uplinks = br-ex:em2
  • bridge_mappings = physnet1:br-ex

2.1.2.3.2.2. Component 가용성과 확장성 point

Component
Availability
Scalability
Dashboard (horizon)
  • Dashboard는 모든 contorller node에서 동작
  • node 장애 발생 시 적어도 하나의 인스턴스에서 동작 되어야 함.
  • 소프트웨어 장애가 발생하여 장애 발생된 인스턴스 주위에서 요청을 라우팅 할 때, 이를 감지하는 역할을 하는 HAProxy 뒷 단에 Dashboard가 있음
  • Dashboard는 모든 contorller node에서 동작
    • controller node 추가로  확장할 수 있음
  • HAProxy는 노드 추가에 따라 dashboard를 확장
Identity (keystone)
  • Identity는 모든 controller node에서 동작
  • Node 장애 발생 시 적어도 하나의 인스턴스에서 동작 되어야 함
  • 소프트웨어 장애가 발생하여 장애 발생된 인스턴스 주위에서 요청을 라우팅 할 때, 이를 감지하는 역할을 하는 HAProxy 뒷 단에 Identity가 있음
  • Identity는 모든 contorller node에서 동작
    • controller node 추가로  확장할 수 있음
  • HAProxy는 노드 추가에 따라 Identity를 확장
Image Service (glance)
  • Image Service는 모든 controller node에서 동작
  • Node 장애 발생 시 적어도 하나의 인스턴스에서 동작 되어야 함
  • 소프트웨어 장애가 발생하여 장애 발생된 인스턴스 주위에서 요청을 라우팅 할 때, 이를 감지하는 역할을 하는 HAProxy 뒷 단에 Image Service가 있음
  • Image Service는 모든 contorller node에서 동작
    • controller node 추가로  확장할 수 있음
  • HAProxy는 노드 추가에 따라 Image Service를 확장
Compute (nova)
  • Nova API, scheduler, objectstore, cert, consoleauth, conductor 그리고 vncproxy 서비스들이 모든 controller node 에서 동작
  • Node 장애 발생 시 적어도 하나의 인스턴스에서 동작 되어야 함
  • 소프트웨어 장애가 발생하여 장애 발생된 인스턴스 주위에서 요청을 라우팅 할 때, 이를 감지하는 역할을 하는 HAProxy 뒷 단에 Compute가 있음
  • Compute node에서 동작하는 compute와 conductor 서비스는 해당  노드에서 서비스가 동작에 필요
    • 해당 노드들의 가용성을 위해 서비스들은 서로 밀접하게 연결 되어 있음
  • Compute node가 가능한 오랫 동안 작동 시 필요로 하는 서비스들은 맨 윗단에서 동작되어야 함
  • Nova API, scheduler, objectstore, cert, consoleauth, conductor 그리고 vncproxy 서비스들이 모든 controller node 에서 동작
    • controller node 추가로  확장할 수 있음
  • HAProxy는 노드 추가에 따라 Compute를 확장
    • compute node가 동작중인 상태에서 서비스 확장이 가능, 선형 확장이 가능
Block Storage (cinder)
  • Block Storage API, scheduler 그리고 volume  서비스는 모든 controller node에서 동작
  • Node 장애 발생 시 적어도 하나의 인스턴스에서 동작 되어야 함
  • 소프트웨어 장애가 발생하여 장애 발생된 인스턴스 주위에서 요청을 라우팅 할 때, 이를 감지하는 역할을 하는 HAProxy 뒷 단에 Block Storage가 있음
  • Block Storage API, scheduler 그리고 volume 서비스들이 모든 controller node 에서 동작
    • controller node 추가로  확장할 수 있음
  • HAProxy는 노드 추가에 따라 Block Storage를 확장
OpenStack Networking (neutron)
  • OpenStack Networking 서비스는 모든 controller node에서 동작
  • Node 장애 발생 시 적어도 하나의 인스턴스에서 동작 되어야 함
  • 소프트웨어 장애가 발생하여 장애 발생된 인스턴스 주위에서 요청을 라우팅 할 때, 이를 감지하는 역할을 하는 HAProxy 뒷 단에 OpenStack Networking 서비스가 있음
  • OpenStack Networking의 ovs-agent, l3-agent, dhcp-agent 그리고 metadata-agent 서비스들이  Pacemaker의 내부 lsb 자원으로써 network node 내부에서 동작
    • 이 의미는 network node 장애 발생 시에도 또 다른 node에서 서비스가 동작
  • ovs-agent 서비스는 모든 compute node에서 동작하고, compute node 장애 발생하는 경우 다른 node에서 동작 중인 서비스들의 사본을 이용하여  계속적으로 기능이 유지
  • OpenStack Networking 서비스는 모든 controller node에서 동작
    • controller node 추가로  확장할 수 있음
  • HAProxy는 노드 추가에 따라 OpenStack Networking를 확장
  • network node가 동작중인 상태에서 확장은 현재 OpenSack networking에서 지원하지 않고 있음
  • 작업 부하를 처리하기 위해서 서비스의 하나의 사본으로 충분
  • 컴퓨팅 노드에서 실행되는  ovs-agent의 확장성은 필요에 따라 compute node의 추가로 이루어짐









X.참조 정보

X.1. Openstack Operations Guide

X.2. Packemaker Documentation




파일 정보

https://docs.google.com/document/d/1qpkrN3WZlDYatkBfJD7W6T_hVGo8PECHruMHIeDFsTA/edit?usp=sharing

댓글

이 블로그의 인기 게시물

How To Restart Windows Server 2012