[2] 오픈스택 컴포넌트 및 아키텍쳐

OpenStack

-클라우드 컴퓨팅을 위한 오픈소스 소프트웨어 플랫폼

- IaaS클라우드 서비스 배포하는 소프트웨어

참고 www.redhat.com/ko/topics/cloud-computing/cloud-vs-virtualization 

 

 

 

구조 요약먼저

 

  1) Compute (프로젝트: NOVA)

  인스턴스(가상머신,서버)의 생성, 중지 스케쥴링 등 인스턴스의 라이프 사키을 을 관리

  - Nova는 VM/Instance를 생성 및 관리

 

  2) Networking (프로젝트: Neutron)

  인스턴스의 네트워크를 제공

  - Neutron 은 VM/Instance에 네트워크 제공

 

  3) Block Storage (프로젝트: Cinder)

  인스턴스의 영구 저장장치인 블록 장지를 제공

  - Cinder VM/Instance 에 영구 저장

 

  4) Identity (프로젝트: Keystone)

  모든 컴포넌트의 인증을 담당, LDAP과 같은 기술을 사용하여 사용자의 중앙 디렉토리 기능

  - Keystone 은 모든 컴포넌트에 인증을 제공

 

  5)Image (프로젝트: Glance)

  인스턴스를 생성하기 위한 운영체제 디스크 이미지 제공

  - Glance 는 VM/Instance를 생성하기 위한 이미지 제공

 

  6)Object Storage (프로젝트: Swift)

  사용자가 사용할 수 있는 클라우드 스토리지

- Swift 는 사용자가 데이터를 저장 할수 있도록 제공 Glance의 저장소를 Swift로, Cinder의 백업저장소를 Swift로 사용 가능

 

  7)DashBoard (프로젝트: Horizon)

  오픈스택 환경을 운영 및 관리 할 수 있는 웹기반의 셀프 서비스 포탈 인터 페이스를 제공

  - Horizon 은 모드 컴포넌트에 Web UI 인터페이스를 제공

 

  8)Orchestration (프로젝트 : Heat)

  템플릿 기반 으로 다양한 클라우드 어플리케이션을 배치하고 관리 할 수 있는 오케스트레이션 기능 제공

   - Heat는 모든 컴포넌트의 오케스트레이션 기능을 제공

 

  9)Telemetry (프로젝트: Ceilometer)

  오픈스택 전체 환경을 에이전트 기반으로 데이터를 수집하여 모니터링,사용량, 벤치마킹, 확장성, 토계 등을 제공

- Ceilometer는 모든 컴포넌트의 모니터링을 제공

 

  10)Container (프로젝트: Magnum) (ex, Docker Swarm, Kubernetes, Mesos)

  컨테이너 엔진을 제공해 컨테이너 라이프 사이클을 관리

 

노드

  1) 컨트롤러 노드

  전체 오픈스택 구성을 제어하기위한 노드

  주요 구성요소)

  Identity 서비스, Image 서비스, DashBoard 서비스, SQL DB, Message Queue, NTP

  옵션 구성요소)

  Orchestration 서비스, Telemetry 서비스

 

  2) 네트워크 노드

  외부 네트워크 뿐만 아니라 내부 네트워크 및 테넌트의 가상 네트워크를 제공

  주요 구성요소)

  Networking 서비스

 

  3) 컴퓨트 노드

  하이퍼바이저를 통해 가상머신/인스턴스를 제공

  주요 구성요소)

  Hypervisor, Telemetry 에이전트

 

 4) 스토리지 노드

  오픈스택에서 제공하는 스토리지 기능

  블록 스토리지 노드 구성요소)

  Cinder 서비스 및 스토리지

  오브젝트 스토리지 노드  구성요소)

  Swift Proxy 및 Storage 서비스

---

오픈스택 코어스비스 (핵심서비스 자세히 설명)

[1] compute = nova( 프로젝트명)

vm제공서비스 , virtualization , firewall (security group), keypair(ssh key)

-가장 핵심이 되는 기능이다.

-가상 환경을 제어하는 인스턴스(물리적으로나 논리적으로 존재하는 것, vm)의 생성, 중지, 스케쥴링 등 인스턴스의 라이플 사이클을 관리한다.

-하이퍼바이저(kvm ,Xen,VMware등)의 제어를 담당한다.

- 리눅스 컨테이너 (LXC_LinuXContainer) 와 Docker 등을 지원하지만 컨테이너는 현재 Magnum 프로젝트에서 지원한다. 이전에는 nova가 vm 과 컨테이너를 모두 제어했지만, 요즘에는 컨테이너는 magnum이 vm은 nova가 나눠서 제어하게 되었다.

-firewalll : 기존에 실습에서 사용했던 vm 방화벽에서 그 방화벽이 아니라 외부에 있는 방화벽을 의미하는데 보안 그룹과 관련이 있다.

-오픈스택도 passwd인증 불가하다. key 기반 인증만 가능.

 

libvirtd (library virtualization demon) - 

 

[2] Networking = Neurtron (프로젝트명)

이전의 nova_network 부터 quantum 프로젝트 를 지나 neutron 까지 변화되었다.

1) nova_network :  nova 하이퍼바이저에 있는 가상 네트워크를 사용했었다. 이 네트워크는  L3까지의 기능만 제공했었다. L4까진 (로드밸런스 ex_ HAproxy ) 불가

2) 그 다음의 Quantum프로젝트의 목적은  L7까지 제공하는 것이었는데, Quantum 프로젝트 다음에 등장한 Neutron 과는 이름만 다르고  목적도 같다.

3) Neutron : 상표권의 문제 때문에 Quantum서 Neutron 으로 바뀐 것일 뿐 동일한 프로젝트로 목적도 L7까지 제공하는 것으로 같다.

DHCP , VLAN , 플로팅 IP(인스턴스를 외부에 노출시키는 역할을 한다), Firewall, Load Balancer ,VPN, IDS/IPS NFV 기능도 제공한다.

-  LAN (network) : L2

-  Routing : L3

-  LB : L4

DHCP, VLAN,network Fw, vpn

 

[3] Block Stroage  = Cinder(프로젝트명)    // 데이터 보관이 기업에서는 가장 중요한 부분. 그래서 스토리지가 중요하다.

 

전통적인 storage 세가지 

1) DAS (Diret Attached Storage) : 직접 연결된 스토리지. Block 장치로 기본적으로 운영체제가 사용한다. 디스크 저장과 같은

2) NAS (Network Attached Storage) : NFS, SMB(CIFS_Common Internet File system) // 두개 모두 file storage로 sharing이 목적이다.

       -SAMBA _ 윈도우의 공유폴더를 리눅스와 연결하기 위해 samba패키지를 통해 smb프로토콜을 분석했다. 이 분석을 통해 리눅스에서도 smb가 작동할 수 있도록 samba라는 패키지를 만든 것이다. smb는 cifs는 구조가 같으며 이 두가지가 samba 와 통신을 할 수 있다.

      - nfs

3) SAN (Storage Area Network) :

       - FC-SAN  스토리지용 프로토콜로서 이더넷 프로토콜(tcp,udp같은) 구조가 아니기 때문에 이러한 이더넷 프로토콜은 스토리지 데이터를 전송하기에는 효율적이지 못해 이러한 스토리지용 프로토콜을 만든 것.

       - IP-San : iscsi, FCoE

 

추가로 클라우드와 함께 자주등장하는 object 스토리지가 있다.

[기존의 block 스토리지 ]:  공유 가 안됨. 

보통 운영체제가 사용하는 디스크로 성능이 제일 좋은 스토리지다. 디스크장치는 보통 이러한 블록장치를 사용. 디스크의 파일사이즈는 대부분 크고 입출력단위가 블록이기 때문에 빠르게 읽고 쓰는 것이 가능하다. 블록단위로 입출력을 해야하기 때문에 사이즈가 크다. 사이즈는 크지만 보다 안전성은 있다.  

좋은 성능이 필요한 db같은 것들이 block스토리지에 저장되어야한다.

※아이옵스(Input/Output Operations Per Second, IOPS)는 HDD, SSD, SAN 같은 컴퓨터 저장 장치를 벤치마크하는 데 사용되는 성능 측정 단위다. IOPS는 보통 인텔에서 제공하는 Iometer 같은 벤치마크 프로그램으로 측정된다.

IOPS 측정값은 벤치마크 프로그램에 따라 다르다. 구체적으로는 임의 접근과 순차 접근 여부, 벤치마크 프로그램의 쓰레드 개수와 큐의 크기, 데이터 블록 크기, 읽기 명령과 쓰기 명령의 비중 등에 따라 달라지며, 이외에도 많은 변수들이 있다. 일반적으로는 종합 IOPS, 임의 접근 읽기(Random Access Read) IOPS, 임의 접근 쓰기(Random Access Write) IOPS, 순차 접근 읽기(Sequential Access Read) IOPS, 순차 접근 쓰기(Sequential Access Write) IOPS로 나누어 측정한다.

 

[기존의 file 스토리지_nfs,smb ]: sharing의 목적을 가지고 있다. 성능은 그렇게 좋지 않음. 이 세가지 스토리중 중간정도

보통은 사용자가 사용. os / user 모두 사용한

웹서버같은 것들. 어플리케이션 서버같은 것들이 file스토리지 사용됨.

 

[object 스토리지 ]:  형식이 정해지지 않은 비정형화된 파일의 목적을 정해준다. 성능은 제일 떨어진다.

데이터의 형식은 목적에 따라 정해지는데 비정형화된 파일들(그림파일,동영상파일 같은)을

메타데이터(파일의 위치 정보같은,inode table, ls-l 과 로 출력되는 ? 데이터들 )와 데이터가

실제로 데이터가저장되는 백엔드서비스와 프론트엔드 서비스를 모두활용하는데 프론트엔드에 요청하면 백엔드에서 알아서 요청을 처리한다.

file 시스템이 없다. 네트워크를 통해 요청만 할뿐이다.

대규모 파일들을 블록에 저장할 수 없다. 이러한 미디어파일들은 object스토리지 를 사용해야한다. 클라이언트입장에서.

물론 서버 관리자 입장에서는 object스토리지도 결국 블록장치가 뒷받침되기는 하지만 표면적으로 다르다.

백단에서는 결국 블록스토리지, 파일시스템이 작동하는 것이다.

거대한 용량의 파일들을 저장해야할 때 이 스토리지를 사용한다.

---

다시 설명하자면,

객체스토리지가 조금 더 옳은 표현이라하며 오브젝트 스토리지를 이하 객체스토리지로 기술하였습니다.

우선 객체스토리지를 알기위해서는 3가지를 알아야한다. 블록스토리지(Block Storage), 파일스토리지(File Storage), 객체스토리지(Object Storage)

 

 

 

파일스토리지

폴더와 파일로 이루어지는 계층구조를 갖는 스토리지. 각 파일은 폴더에 종속되며 폴더 역시 다른 폴더에 종속될 수 있다. 케비넷을 떠올리면 이해하기 쉽다. 각각의 파일철들이 케비넷별로 저장되어있고 언제든 꺼내어 수정하거나 변경할 수 있다. 파일철을 찾으려면 어느 케비넷이 있는지 알고있어야 한다. 마찬가지로 파일을 찾으려면 어느 경로에 있는지 알고있어야한다. 파일철이 그리 많지않다면 분류하고 정리하는데 큰 문제가없지만 파일철들이 계속해서 늘어나면 늘어날수록 점점 분류하고 정리하는(파일시스템에서의 인덱싱)이 많아지고 찾기가 힘들어진다.

블록스토리지

블록스토리지는 정해진 블록안에 데이터를 저장합니다. 우리가 SQL에서 테이블을 만들때 각 칼럼별로 저장할 데이터를 설정해주고 이후의 데이터 삽입도 맨처음 설정한 값 범위안에서 저장해주는것과 유사합니다. 블록스토리지는 컴퓨터의 C드라이브, D드라이브와 유사합니다. 맨처음 파티션을 나누어주고 그 공간안에서 사용을 할 수 있습니다. 하지만 파일스토리지와 다른점은 파일스토리지는 1개의 경로만 갖는데 반하여 블록스토리지는 여러개의 경로를 가질 수 있습니다. C드라이브와 D드라이브를 네트워크를 통해서 공유하고 여러 사용자가 해당 드라이브를 참조하는것과 유사합니다. (물론 공유는 할 수 있지만 OS와의 연결은 한번에 1개만 가능합니다.) 낮은 IO 레이턴시를 보이기때문에 RDB와 같은 데이터베이스에 아주 적합합니다.

오브젝트 스토리지

그래도 이해가 잘 안간다면…?

블록스토리지와 파일스토리지는 모두 OS단에서 동작하지만 오브젝트 스토리지는 어플리케이션 단에서 동작합니다. 쉽게 말하면 S3나 Cloud Sotrage에서 폴더를 만들거나 다른 버킷으로 파일을 옮긴다고하여도 실제로 블록을 이동하거나 폴더에 종속된게 아닌 단지 사용자에게 그렇게 보이게 해주기만 해줍니다. 즉 논리적인 스토리지라고 볼 수 있습니다. 위의 이미지에서 보듯이 오브젝트 스토리지는 물리적 제약이 없기때문에 원하는 만큼 공간을 확장시킬 수 있습니다. 저는 이부분에서 많이 헷갈리다가 한가지 좋은 사례를 보고 조금 더 이해할 수 있던 이미지가 있었습니다.

 

 

 

블록 스토리지는 주차장과 같습니다. 주차장이 꽉차면 더이상 주차할 수 없습니다. 그렇다면 필요한만큼 주차장을 늘려놓아야합니다. 파일 스토리지는 주차타워와 같습니다. 문제는 내 차를 타기 위해서는 주차타워가 한번 돌아가야합니다. 즉 주차가 많아지면 많아질수록 폴더가 깊어지고 많아질수록 차를 찾기가 힘듭니다. 오브젝트 스토리지는 발렛아저씨들이 알아서 주차를 해줍니다. 강남이나 판교에서 발렛 맡겨보시면 아시겠지만 이 아저씨들은 정말 공간의 예술을 보여줍니다. 어떠한 공간도 정말 효율적이고 예술적으로 사용하고 공간의 낭비가 하나도 없도록 주차를 해줍니다.

클라우드에서 오브젝트 스토리지를 쓰는 이유는?

역시 확장성과 속도 그리고 저렴한 가격입니다. 오브젝트 스토리지는 오로지 2가지 키값과 데이터만 저장합니다. 발렛을 맡길때도 자동차(데이터) 세워두고 번호표만 줍니다. 어디에 주차되어있는지 알필요는 없습니다. 마찬가지로 오브젝트 스토리지는 RESTFul Protocol(HTTP)를 이용하여 Get 혹은 Post로 요청을하면 파일을 내려줍니다. 그 이상은 알 필요가 없습니다. 또한 파일에 대해 가지고 있는 정보가 적기때문에 파일이 아무리 많아져도 블록스토리지나 파일스토리지에 비해서 빠르게 작동합니다. 마지막으로 공간을 아주 효율적으로 사용할 수 있기때문에 저렴합니다.

물론 단점도 존재합니다. 파일의 수정이 불가능합니다. 파일이 수정될때 트랜잭션을 통해 일관성을 유지하기가 힘들기때문에 덮어쓰는 방법을 이용합니다. 이렇기 때문에 이미지나 동영상같이 수정이 잘 일어나지 않는 정적인 데이터를 호스팅할때 좋습니다. 또한 내구성이 블록스토리지에 비해 떨어지기때문에 내구성을 상당히 요야하는 데이터를 처리하기 힘듭니다.

 

• • 오브젝트 스토리지(Object Storage)

  • 계층형 디렉토리 구조를 사용하는 파일 스토리지와는 반대로 데이터를 오브젝트로 관리하는 스토리지 아키텍처입니다. 하나의 오브젝트에는 데이터, 메타데이터 및 고유 글로벌 ID가 포함되어 있습니다. 오브젝트 스토리지는 기본적인 대규모 확장성 기능, 공통 API를 통한 액세스 기능, 물리적 하드웨어의 여러 인스턴스로 확장할 수 있는 네임스페이스 사용 기능 덕분에 클라우드 애플리케이션에 우선적으로 사용됩니다.

• • 오브젝트 스토리지의 사용 주체 및 사용 이유

    애플리케이션 개발자가 모바일 앱을 포함한 모든 유형의 클라우드 기반 첨단 애플리케이션을 개발하기 위해 공통 API를 통해 프로그램을 제작할 때 사용합니다. 이러한 첨단 애플리케이션에서는 기존 파일이나 블록 스토리지가 아닌 오브젝트 스토리지가 사용됩니다. IT 관리자는 지리적으로 분산된 글로벌 콘텐츠 저장소, 콜드 아카이브, IoT(Internet of Things) 스토리지, 분석 등과 같은 사례에서 비정형 데이터를 경제적인 비용으로 저장하기 위해 오브젝트 스토리지를 사용합니다. 오브젝트 스토리지는 IoT 데이터, 그래픽 파일, 센서 데이터 등의 비정형 데이터를 효율적으로 저장하는 데 사용됩니다.

    오브젝트 스토리지의 작동 방식

    오브젝트 스토리지는 폴더와 하위 폴더가 포함된 디렉토리 트리가 없다는 점에서 파일 스토리지와는 다릅니다. 하나의 오브젝트에는 데이터, 메타데이터 및 글로벌 고유 ID 번호가 포함되어 있습니다. 오브젝트 스토리지에는 디렉토리나 마운트 지점이 없습니다.  쉽게 기억하기 위한 식별 번호를 저장하는 데 인덱스가 사용됩니다. 애플리케이션과 최종 사용자는 파일 위치를 알 필요가 없으며 단지 고유 ID만 제공하면 시스템에서 데이터를 검색합니다. 또한 오브젝트 스토리지 시스템에는 노드 수나 지리적 위치에 관계없이 단일 평면 글로벌 네임스페이스가 사용됩니다. 따라서 파일 시스템에서 데이터 배치를 통제할 필요 없이, 위치와 무관한 데이터 사용이 가능합니다. 여러 개의 노드와 사이트는 하나의 논리적 스토리지 시스템으로 나타납니다. 데이터의 복제와 원거리 분산은 전용 복제 및 백업 인프라스트럭처가 아닌 오브젝트별 정책에 따라 실행됩니다.

    오브젝트 스토리지의 이점

    클라우드 스토리지에서 실현되는 비용 효율성의 비결은 경제적인 스토리지 시스템으로 시작하는 데 있습니다. 기존 NAS 및 SAN 스토리지를 구동하는 복잡하고 제약이 많은 구형 파일 시스템을 사용할 경우 스토리지 관리가 복잡해지고, 인위적 용량 한도로 인해 확장성이 제약되고, 값비싼 전용 하드웨어로 특정 공급업체에 종속되기 때문에 클라우드 스토리지의 잠재적 비용 절감 효과가 상쇄되기 쉽습니다. 오브젝트 스토리지는 클라우드 인프라스트럭처에 매우 적합한 솔루션입니다. 복잡하고 관리하기가 어려우며 시대에 뒤떨어진 파일 시스템을 대체하는 오브젝트 스토리지 시스템에서는 단일 평면 주소 공간을 활용하여 데이터를 적합한 스토리지 시스템에 자동으로 전달하고, 컨텐츠 수명주기를 지정하고, 활성 데이터 및 아카이브 데이터 모두를 적절한 보호 수준이 적용된 단일 계층 내에 보관합니다. 따라서 오브젝트 스토리지에서는 데이터 가치와 저장 비용을 균형 있게 조율함으로써 더욱 향상된 가치를 제공할 수 있습니다. 이 경우, 데이터를 적합한 계층으로 직접 이동해야 하는 과도한 관리 부담도 없으면서 무한한 확장성을 통해 클라우드 스토리지의 용량을 필요에 따라 확장할 수 있습니다. 

    오브젝트 스토리지의 그 밖의 이점은 다음과 같습니다.

    • 상용 서버 하드웨어에서 최고 수준의 효율성으로 실행되도록 설계되었습니다.
    • 위치, 시간 및 디바이스 종류에 상관없이 HTTP를 통해 스토리지에 간편하게 액세스할 수 있습니다.
    • 클라우드 스토리지는 대개 인터넷을 통해 SaaS(Storage as a Service) 애플리케이션으로 제공되므로, 오브젝트 스토리지 풀에 액세스할 때 기본 프로토콜로 HTTP를 사용한다면 클라우드 스토리지 공급업체가 오브젝트 스토리지 시스템을 자체 서비스 오퍼링으로 더욱 간단하게 통합할 수 있습니다.

---

[4] Identity = Keystone (프로젝트명)  : 인증 (백엔드)

1) sql (기본적으로 사용) :기본적으로 MariaDB사용, 실습서 사용한 admin계정정보같은

2) LDAP

 

keystone 대표적 기능 중 하나인 * 카탈로그 관리기능

카탈로그 : 여러 오픈스택의 컴포넌트 목록

- service목록 : nova , neutron,cinder 등등에 대한 컴포넌트 정보들

- Endpoint목록: 위의 컴포넌트에 접근할 주소목록

[5] Image = Glance

[6] Object Storage = Swift

[7]Dashboard = Horizon

오픈스택 API 또는  aws api를 지원. 셀프 서비스 포탈 인터페이스를 제공한다.

 

[8]Orhestration= Heat (프로젝트명)

템플릿 기반으로 다양한 클라우드 어플리케이션을 배치하고 관리할 수 있는 오케스트레이션 기능을 제공한다.

IaC (Infrastructure as Code): 코드를 통해 관리. 앤서블은 시스템 구성관리의 성격이 강하고 테라폼은 시스템 배포에 주로 쓴다.

테라폼을 통해 배포하고 해당 vm의 인스턴스를 앤서블로 관리 하는 형태로 많이 씀.

 

테라폼이 Ansible이나 Chef와 비슷하다고 생각할 수 있으나, 테라폼은 '특정 클라우드 환경' 을 배포하는 것에 좀 더 초점이 맞춰져 있다는 것이 다르다. Ansible은 일반 서버,가상 머신, 심지어 라즈베리파이에서도 SSH를 통해 동일한 환경을 배포할 수 있는 반면, 테라폼은 AWS, GCP 등의 클라우드 플랫폼 위에서 환경을 배포할 때 주로 사용한다. 그러나 코드로서 인프라를 정의한다는 개념 자체는 Ansible과 같은 환경 배포 툴과 동일하며, 일반 베어메탈 서버가 아닌 특정 클라우드 플랫폼의 특징에 맞는 환경을 코드로서 배포한다는 점이 다르다.