"서버 가상화"의 두 판 사이의 차이
69번째 줄: | 69번째 줄: | ||
===CPU 할당 방법=== | ===CPU 할당 방법=== | ||
− | 베어메탈 서버로 TA(Technical Architecture)를 설계할 때, 서버 가상화 기술로 설계할 경우 호스트 서버 한 대에 게스트 OS를 분리하여 애플리케이션 별로 최대한 고립시켜 주는 것이 | + | 베어메탈 서버로 TA(Technical Architecture)를 설계할 때, 서버 가상화 기술로 설계할 경우 호스트 서버 한 대에 게스트 OS를 분리하여 애플리케이션 별로 최대한 고립시켜 주는 것이 유리하다. 이는 분리된 애플리케이션들은 각각의 게스트 OS 내에서 인프라 자원을 할당 받기 위한 경합을 회피할 수 있으며, OS를 각 애플리케이션에 맞도록 최적화하여 운영할 수 있기 때문이다. 가상 시스템별로 CPU를 할당해야 하는 경우 애플리케이션의 다중 스레드를 요구하는지 단일 스레드를 요구하는지 확인해야 합니다. 이러한 활동을 워크로드 분석이라고 하며, 이렇게 조사한 결과를 기준으로 CPU 자원을 할당해야 한다. |
− | 가상 시스템별로 CPU를 할당해야 하는 경우 애플리케이션의 다중 스레드를 요구하는지 단일 스레드를 요구하는지 확인해야 합니다. 이러한 활동을 워크로드 분석이라고 하며, 이렇게 조사한 결과를 기준으로 CPU 자원을 할당해야 | ||
===메모리=== | ===메모리=== | ||
− | 메모리도 CPU 처럼 오버커밋이 있으나 메모리는 공간을 차지하는 개념이기 때문에 먼저 메모리 공간을 차지한 VM이 메모리를 해제하거나 재기동 하기 전에는 메모리 공간을 차지한 VM이 메모리를 할당 받지 못하고 기다리는 현상이 발생함으로 보수적으로 처리해야 | + | 메모리도 CPU 처럼 오버커밋이 있으나 메모리는 공간을 차지하는 개념이기 때문에 먼저 메모리 공간을 차지한 VM이 메모리를 해제하거나 재기동 하기 전에는 메모리 공간을 차지한 VM이 메모리를 할당 받지 못하고 기다리는 현상이 발생함으로 보수적으로 처리해야 한다. 따라서 메모리는 오버커밋하여 사용하지 않는다. 메모리가 부족하면 스왑(SWAP)이 발생하고, 메모리가 부족한 모든 VM에 성능 하락이 발생하게 된다. 서버 가상화 기술이 발전하면서 물리 메모리의 한계를 넘어서기 위한 기술도 존재한다. 씬 프로비저닝은 VM에서 실제로 메모리를 사용할 때 물리 메모리를 조금씩 할당해 주는 방식으로 메모리 사용률에서는 효율적이지만 메모리 단편화가 발생하는 단점이 있다. 메모리 오버커밋 상태에서 게스트 OS 메모리 사용량이 하이퍼바이저 메모리 크기를 초과하면 하이퍼바이저 디스크를 사용하며, 게스트 OS의 메모리 사용량이 줄어들면 하이퍼바이저 디스크에 저장된 데이터를 하이퍼바이저 메모리로 이동하는 기술이다. 이외에도 COW(Copy on Write)와 같이 VM을 복제하여 사용하는 경우 메모리를 동일하게 복제하면 2배의 메모리 공간이 필요함으로, 복제하지 않고 2개의 VM이 동일한 메모리 영역을 참조하다가 데이터가 변경되는 시점에서 새로운 메모리를 할당하는 방법이 있다. 또한 압축 캐시라고 하여 VM에서 메모리를 사용할 때 VM과 물리 메모리 사이에 별도의 캐시 메모리를 두고, 그 캐시에 데이터를 임시 저장 후 압축해서 실제 물리 메모리에 저장하는 기능이다. 벌룬 드라이버보다는 빠르다는 장점이 있으나 데이터의 형태에 따라서 압축률이 다르고, 데이터를 압축 및 해제하기 위해서 지속적으로 CPU 연산이 필요하다는 단점이 있다. <ref> Lucas 팬도라, 〈[https://judo0179.tistory.com/36 IT 인프라 6편 가상화]〉, 《티스토리》, 2018-10-19</ref> |
− | 따라서 메모리는 오버커밋하여 사용하지 | ||
− | 서버 가상화 기술이 발전하면서 물리 메모리의 한계를 넘어서기 위한 기술도 | ||
− | 씬 | ||
− | VM에서 실제로 메모리를 사용할 때 물리 메모리를 조금씩 할당해 주는 방식으로 메모리 사용률에서는 효율적이지만 메모리 단편화가 발생하는 단점이 | ||
− | 메모리 오버커밋 상태에서 게스트 OS 메모리 사용량이 하이퍼바이저 메모리 크기를 초과하면 하이퍼바이저 디스크를 사용하며, 게스트 OS의 메모리 사용량이 줄어들면 하이퍼바이저 디스크에 저장된 데이터를 하이퍼바이저 메모리로 이동하는 | ||
− | 이외에도 COW(Copy on Write)와 같이 VM을 복제하여 사용하는 경우 메모리를 동일하게 복제하면 2배의 메모리 공간이 필요함으로, 복제하지 않고 2개의 VM이 동일한 메모리 영역을 참조하다가 데이터가 변경되는 시점에서 새로운 메모리를 할당하는 방법이 | ||
− | 또한 압축 캐시라고 하여 VM에서 메모리를 사용할 때 VM과 물리 메모리 사이에 별도의 캐시 메모리를 두고, 그 캐시에 데이터를 임시 저장 후 압축해서 실제 물리 메모리에 저장하는 | ||
==전망== | ==전망== |
2020년 8월 14일 (금) 10:19 판
서버 가상화(server virtualization)는 하나의 물리적 서버 호스트에서 여러 개의 서버 운영 체제를 게스트로 실행할 수 있게 해주는 소프트웨어 아키텍처다. 서버는 물리적 시스템으로부터 추상화된 서버 소프트웨어를 통해 물리적 영역을 벗어난 하나의 ‘가상 시스템’이 된다.
목차
개요
서버 가상화는 CPU, 메모리, 입출력 등 단일 플랫폼 상의 서버 자원을 사용자가 여러 도메인이나 서버 애플리케이션으로 분할해 사용할 수 있는 기술이다. 즉 가상 플랫폼에서 모든 운영 체제의 가상 인스턴스를 생성할 수 있는 기술을 말한다. 운영 체제를 호스팅하기 위해 CPU, 디스크, 메모리 및 기타 연결된 하드웨어가 있는 서버인 물리적 플랫폼이 필요했다. 서버 가상화는 물리적으로 한대의 시스템 상에서 윈도우나 리눅스 등 각기 다른 운영체제의 다양한 서버 애플리케이션을 효율적으로 운영할 수 있어 비용 절감 및 서버 자원의 효율적인 활용이 가능하다. 일반적인 서버 가상화에서 많은 가상 시스템이 물리적 서버에 연결되며 하이퍼바이저(Hypervisor)는 호스트 하드웨어를 각 개별 가상 컴퓨터와 공유하는 데 사용된다. 서버 가상화를 통해 리소스를 다른 많은 가상 컴퓨터와 공유할 수 있으므로 조직은 데이터 센터 하드웨어 사용 공간 및 방대한 양의 물리적 하드웨어를 실행하는 데 드는 관련 비용을 크게 줄일 수 있다. 서버 가상화는 자바 가상머신처럼 현재의 운영체제 위에 가상머신을 만들어 마치 컴퓨터가 여러대 있는 것처럼 시스템을 구축하여 동시에 운영하는 방식과 하드웨어를 파티션으로 나누어 각기 다른 운영체계를 얹는 방식이다. 그리고 다중 운영체계와 하드웨어 사이에 가상화의 계층을 두는 방식 등 여러 가지가 있다.[1]
역사
최초로 가상화된 컴퓨터 자원은 메모리(Memory - Main Storage)로서 1964년에 발표된 IBM S/360의 다음 세대인 S/370 아키텍처가 최초로 가상화 스토리지(Virtual Storage)라는 개념을 사용하였다. 그러나 서버 가상화 (Server Virtualization)란 단순한 메모리 가상화를 넘어서 서버를 구성하는 모든 자원의 가상화를 의미하는 것이다. 서버 가상화는 최근 인기가 높아졌으나 50년 이상 개발된 기술이다. 1960년대에 IBM은 시스템 메모리의 첫 번째 가상화를 개척했다. 이것은 가상 하드웨어의 선구자 역할을 하였다. 1970년대에 IBM은 VM/370이라는 독점 운영 체제를 가상화했다. 이 OS 수준의 가상화는 메인프레임 컴퓨팅 외부에서 는 거의 사용되지 않았지만 결국 서버를 위해 상업적으로 판매된 최초의 가상 플랫폼인 z/VM이 된 제품으로 발전했다.
가상화의 인기는 1990년대 후반에 브이엠웨어(VMware)의 VMware 워크스테이션 출시와 함께 크게 증가했다. 이 제품은 모든 x86/x64 아키텍처의 가상화를 가능하게 하고 가상화 주류를 가져왔다. 이제 동일한 호스트 하드웨어에서 리눅스(Linux), 윈도우(Windows) 및 MacOS를 실행할 수 있다. 이 획기적인 기술은 지난 20년 동안 IT 인프라 서비스를 형성하는 데 핵심적인 역할을 해왔다.[2]
특징
장점
- 공통 관리 인터페이스(Common Management interface) : 단일 애플리케이션으로 모드 서버들을 통제한다는 것은 매우 효율적이지만, 단일 인터페이스를 통한 서버들의 통제 능력은 전혀 다른 문제다. 가상화는 가상 머신, 콘솔, 스토리지에 대한 접근성을 부여한다. 필요한 시스템을 바로 사용할 수 있는 환경이 만들어진다.
- iLO(Integrated Lights Out) 불필요 : 통합 라이트 아웃(Light Out) 인터페이스를 설정하지 않은 경우에도 가상화는 관련된 부담을 덜어 준다. 가상화 환경에서는 시스템에 대한 물리적 접근 없이도, 전원 오프 상태의 가상 머신을 부팅시킬 수 있다. 가상화 기반 인프라로의 전환에 있어서 데이터 센터 프로세스의 간소화는 전체 해택의 극히 일부분일 뿐이다.
- 하드웨어 교체 : 하드웨어 교체와 시스템 업그레이드는 용이한 작업이 아니다. 최첨단 데이터센터에서도 하드웨어 교체를 위해서 케이지를 열고, 노후 하드웨어를 제거한 후, 새로운 장비를 설치해야 하는 상당히 번거로운 작업을 필요로 한다. 만약 하드웨어의 동작이 정상적이지 않은 경우에는 모든 과정을 다시 진행해야한다. 가상 서버는 몇 번의 마우스 클릭만으로 CPU 수를 추가하거나 메모리 업그레이드 또는 하드디스크 추가를 손쉽게 진행할 수 있다.
- 스냅샷(Snapshots) : 가상 머신은 자체적으로 스냅샷 기능을 지원한다. 스냅샷은 가상 서버에서 추가 작업을 진행하기 전, 현재 운영되고 있는 구축 환경의 복사본으로 볼 수 있으며, 추가 작업중 문제가 생길 경우 스냅샷의 상태로 즉각 복원할 수 있는 기능이다.
- 프로토타이핑 : 가상 머신(VMS)은 몇 번이고 테스트해 볼 수 있는 기기다. 애플리케이션, 데이터베이스, 운영시스템(OS) 등의 기능 개선을 물리적인 시스템에서 진행할 경우 실패할 때만다 이미지를 다시 구성해야 하는 어려움이 있으나, 표준 가상 머신을 통해서는 몇 번이고 프로토타이핑을 하는 데에는 부담이 없다.
- 시스템 통신 : 호스트와 게스트, 게스트와 게스트 간의 통신은 홉(hop)을 필요치 않으며, 표준 물리 하드웨어의 제약을 받지 않는다. 프라이빗 VLAN은 시스템 간의 안전하고 빠른 통신을 가능하게 하며, 가상 머신 그룹에 프라이빗 VLAN을 적용하여, 외부 네트워크 노출이 제한되는 멀티 티어 애플리케이션을 생성할 수 있다. 또한 복잡한 네트워크 룰을 구성할 필요도 없다.
- 손쉬운 해체 : 물리 시스템을 해체하기 위해서는, 수 차례에 걸친 작업들을 필요로 한다. 네트워크 포트를 해제하고, 디스크를 삭제하고, 시스템 전원을 뽑은 후, 랙에서 시스템을 제거한 후에야 시스템을 폐기할 수 있다. 가상 머신의 해체 프로세스는 이와 동일한 과정을 거치지만, 데이터센터와 관련된 과정은 없다. 제거하거나 반납하여야 할 시스템이 없으며, 인벤토리에서 가상 머신을 제거하는 것은 몇 초면 끝난다.
- 템플릿 : 데이터 센터에서 필요한 골드 디스크(gold disk)는 하드웨어 유형마다 하나씩 필요하다. 가상 머신은 보통 하나의 템플릿으로 구축에 필요한 모든 것들을 담을 수 있으며, 몇 분만에 작업이 완료된다. 템플릿은 시스템 구축에 있어서 단 하나의 마스터 골드 디스크를 만들 수 있도록 한다.
- 신속한 구축 : 가상머신은 딜리버리, 설치, 전원 배선, 네트워크 드롭, SAN 케이블 작업 등이 필요 없으며, 템플릿이나 ISO 이미지를 사용하여 몇 분에서 몇 시간 정도면 구축을 완료할 수 있다.
- 다이내믹한 자원 활용 : 물리적인 컴퓨팅 자원의 신규 투입이 필요한 마케팅 캠페인을 위한 스케일업(scale-up)을 급변하는 비즈니스 조건에 맞춰 신속하게 적응할 수 있는 환경을 제공해 준다. 추가적인 자원의 투입이나 필요 없을 시 이러한 자원의 반납은 매우 손쉽게 진행될 수 있으며, 이러한 특성으로 가상화는 다이내믹 컴퓨팅을 가능하게 한다.[3]
제한 사항
처리 능력이 높은 응용 프로그램에 전념하는 서버의 경우 가상화는 좋은 선택이 아니다. 가상화는 기본적으로 서버의처리 능력을 가상 서버간에 분할하기 때문이다. 서버의 처리 능력이 응용 프로그램 요구 사항을 충족할 수 없는 경우 모든 것이 느려진다. 완료하는 데 시간이 오래 걸리지 않아야 하는 작업은 몇 시간 동안 지속될 수 있다. 더 나쁜 것은 서버가 처리 요구 사항을 충족할 수 없는 경우 시스템이 충돌할 수 있다. 네트워크 관리자는 실제 서버를 여러 가상 컴퓨터로 분할하기 전에 CPU 사용량을 자세히 살펴봐야 한다.또한 하나의 물리적 컴퓨터에 너무 많은 가상 서버를 만들어 서버의 CPU를 과부하하는 것도 현명하지 않다. 물리적 서버가 지원해야 하는 가상 시스템이 많을수록 각 서버가 받을 수 있는 처리 능력이 줄어든다. 또한 실제 서버에는 디스크 공간이 제한되어 있다. 너무 많은 가상 서버가 서버의 데이터 저장 기능에 영향을 줄 수 있다. 또 다른 제한 사항은 마이그레이션이다. 현재 두 실제 컴퓨터가 동일한 제조업체의 프로세서를 사용하는 경우에만 가상 서버를 한 실제 컴퓨터에서 다른 컴퓨터로 마이그레이션할 수 있다. 네트워크가 인텔 프로세서에서 실행되는 서버와 AMD 프로세서를 사용하는 서버를 사용하는 경우 가상 서버를 한 실제 컴퓨터에서 다른 컴퓨터로 이식하는 것은 불가능하다.관리자가 가상 서버를 마이그레이션하려는 이유는 물리적 서버에 유지 관리가 필요한 경우 가상 서버를 다른 컴퓨터로 이식하면 응용 프로그램 가동 중지 시간이 줄어든다. 마이그레이션이 옵션이 아닌 경우 유지 관리 중에 실제 컴퓨터에서 호스팅되는 가상 서버에서 실행되는 모든 응용 프로그램을 사용할 수 없다. 많은 기업들이 한계에도 불구하고 서버 가상화에 투자하고 있다. 서버 가상화 기술이 발전함에 따라 거대한 데이터 센터의 필요성이 감소할 수 있다. 서버 전력 소비와 열 출력도 감소하여 서버 활용도가 재정적으로 매력적일 뿐만 아니라 녹색 이니셔티브를 만들 수 있다. 네트워크가 최대한의 잠재력에 가까운 서버를 사용하므로 더 크고 효율적인 컴퓨터 네트워크를 볼 수 있다.[4]
종류
전가상화
전가상화(Full-Virtualization)는 하이퍼바이저라는 특수한 소프트웨어를 사용한다. 하이퍼바이저는 물리 서버의 CPU와 디스크에 직접 상호작용을 하며, 가상 서버의 운영체제를 위한 플랫폼 역할을 한다. 즉 운영체제 위에 하이퍼바이저가 설치되고, 그 위에서 가상 서버 및 운영체제가 실행되는 방식이다. 하이퍼바이저는 각각의 가상 서버들을 완전히 독립적으로 운용하도록 한다. 각각의 게스트 서버는 자체 운영체제에서 운영되기 때문에, 리눅스 기반 게스트와 윈도우 기반 게스트를 동시에 운용할 수도 있다. 하이퍼바이저는 물리 서버의 자원을 모니터링하여, 가상 서버에서 애플리케이션이 구동될 때, 물리 서버의 자원을 적절한 가상 서버에 할당해 준다. 물론 하이퍼바이저 자체 구동을 위해서도 처리능력 등의 리소스를 필요로 하기 때문에, 하이퍼바이저의 리소스 사용량은 전체 서버 퍼포먼스와 애플리케이션 구동속도에 영향을 줄 수 있다. 전가상화는 컴퓨팅 시스템의 하드웨어 리소스를 완전하게 가상화 하는 방식으로 그 위에서 동작하게 될 게스트 운영체제의 수정 없이 구동이 가능하다. 마이크로소프트 윈도우에서 리눅스 까지 다양한 운영체제를 사용할 수 있기 때문에 적용이 쉬운 편이다. 컴퓨팅환경을 기존의 운영체제 위에서 에뮬레이션 하는 형식으로 지원하기에 호스트(Host)형 가상화 라고도 한다. 다만 CPU의 가상화 지원 기술(VT, Virtualization Technology)과 같은 하드웨어 기능을 일부 지원받기 때문에 모든 기능을 소프트웨어적으로 구동하는 에뮬레이션과는 차이가 있다. 하이퍼바이저를 직접 실행하기에 편리한 인터페이스 화면을 제공하지만, 반면 이에 따른 성능 감소가 생긴다는 단점이 있다.
반가상화
반가상화(Para-Virtualization)는 전가상화와는 달리, 게스트 서버 간의 독립성 없이 상호작용한다. 물리 서버 위에 하이퍼바이저가 직접 설치되고, 그 위에서 가상 서버 및 운영체제가 실행되는 방식이다. 반가상화 하이퍼바이저는 게스트 운영체제를 관리하기 위해 필요한 자원(처리능력)이 상대적으로 적게 든다. 이는 각각의 운영체제가 동일한 물리 서버에서 운영되는 다른 운영체제에서 필요로 하는 자원을 이미 인지하고 있으며, 이들 시스템은 마치 하나처럼 동작하게 된다.반가상화는 하드웨어를 완전히 가상화하지 않는 방식이다. 하이퍼바이저가 하드웨어 위에서 직접 실행되기 때문에 네이티브(Native, Bare-metal) 가상화 라고도 한다. 물리 서버의 성능을 최대한 발휘하면서 가상 서버의 성능을 제공하기에 성능이 많이 감소되지 않으면서 가상 서버를 제공하지만, 물리 서버 바로 위에 설치된 하이퍼바이저를 직접적으로 관리하기에는 어려움이 있다. 반가상화는 하드웨어에 대한 제어권을 하이퍼바이저가 가지고 있기 때문에, 하드웨어와의 I/O 처리에 있어서 전가상화보다 직접적인 루틴을 사용한다.
운영체제 수준 가상화
운영체제 수준 가상화(operating-system-level virtualization)는 운영체제의 중앙 태스크 관리자인 커널에서 이루어진다. 이렇게 하면 리눅스 환경과 윈도우 환경을 함께 실행할 수 있다. 또한 기업은 가상 운영 체제를 컴퓨터에 푸시해 여러가지 이점을 얻을 수 있다. 컴퓨터에 고도의 OOTB(Out Of The Box) 기능이 필요하지 않으므로 하드웨어에 많은 비용이 소모되지 않는다. 모든 가상 인스턴스를 모니터링하고 격리할 수 있으므로 보안이 강화된다. 소프트웨어 업데이트와 같은 IT 서비스에 소요되는 시간이 절약된다. 운영 체제 수준 가상화는 커널이 여러 개의 격리된 사용자 공간 인스턴스의 존재를 허용하는 운영 체제 패러다임을 말한다. 컨테이너(LXC, 솔라리스 컨테이너, 도커), 솔라리스 컨테이너 영역, 가상 개인 서버(오픈VZ), 파티션, 가상 환경(VEs), 가상 커널(드래곤 플라이 BSD) 또는 감옥(FreeBSD 감옥 또는 chroot 감옥) 등 이것을 실행 하는 프로그램의 관점에서 실제 컴퓨터 처럼 보일 수 있다. 일반 운영체제에서 실행되는 컴퓨터 프로그램은 해당 컴퓨터의 모든 리소스를 볼 수 있다. 그러나 컨테이너 내부에서 실행되는 프로그램은 컨테이너에 할당된 컨테이너의 내용 및 장치만 볼 수 있다. 유닉스와 같은 운영 체제에서 이 기능은 표준 chroot 메커니즘의 고급 구현으로 볼 수 있으며, 이는 현재 실행 중인 프로세스및 해당 하위에 대한 명백한 루트 폴더를 변경한다. 커널은 격리 메커니즘 외에도 한 컨테이너 활동이 다른 컨테이너에 미치는 영향을 제한하는 리소스 관리 기능을 제공하는 경우가 많다.[4]
개념
하이퍼바이저
하이퍼바이저는 여러 개의 가상머신이 한정된 하드웨어 자원을 나눠 쓸 수 있도록 한다. 운영체제와 합쳐진 형태와 분리된 형태로 나뉜다. 전가상화 반가상화라고 부르는 이러한 방법은 하이퍼바이저의 역할 범위에 따라 구분한 것으로 전가상화는 하이퍼바이저가 호스트 운영체제에서 모든 일을 처리하는 것이며, 반가상화는 일부 역할을 가상머신의 도움을 받아서 처리하는 개념이다. VMware vSphere ESXi의 경우 모든 하이퍼콜(Hypercall)을 하이퍼바이저가 처리하는 반면 Xen의 경우 Dom 0라는 게스트 운영 체제가 하이퍼콜의 일부를 넘겨받아 처리하는 구조로 되어있다. 전가상화는 하이퍼바이저를 통해 하드웨어에 직접 접근하기 때문에 OS 커널의 수정없이 사용할 수 있다는 장점이 있으나 이러한 장점을 유지하기 위해서 모든 장치에 드라이버를 에뮬레이션 가상화 기법으로 제공하고 바이너리 변환 기법을 통해 하드웨어에 대한 커널 수준 접근을 가능하게 한다. Xen과 같이 반가상화의 경우 하이퍼바이저의 게스트 도메인이라고 불리는 가상머신 뿐만 아니라 컨트롤 도메인(Control Domain, Domain 0)이라는 아주 가벼운 리눅스환경의 가상머신이 존재한다. 게스트 도메인이 요청한 CPU, 메모리, 타이머 등에 대한 하이퍼콜은 하이퍼바이저에서 처리해주고 스토리지나 네트워크와 같이 I/O를 발생하는 하이퍼콜은 컨트롤 도메인이 하드웨어에 요청하는 구조다.[5]
아이비엠
서버 하드웨어를 제조하는 아이비엠(IBM)도 서버 가상화에 중요한 역할을 한다. IBM 플랫폼 시스템 P, 시스템 I 및 시스템 Z는 파라 가상 하이퍼바이저를 사용한다. 기본적으로 모든 게스트 가상 시스템은 호스트를 통해 서로 및 리소스 요구 사항을 알고 있다. 호스트 하드웨어 리소스는 분할되어 가상 컴퓨터(또는 논리 파티션)에 할당된다. IBM Z/VM은 이 파라 가상화 기술을 설립했으며 거의 모든 IBM 메인프레임 솔루션이 이 가상화 방법을 사용한다. 예를 들어 IBM System P는 HMC에서 관리하는 풀링된 가상화된 하드웨어 계층을 사용하여 논리 파티션에 리소스를 배포한다. 각 파티션은 다른 파티션의 요구 사항을 알고 있으며 각 서버에 정의된 최소 하드웨어가 있는지 확인하기 위해 리소스가 공유된다.
컨테이너
컨테이너(container)는 가상머신이 없으며 게스트 OS도 없다. 호스트 OS입장에서 보면 컨테이너는 하나의 프로세스로 기동하기 때문에 하드웨어를 초기화 하는 작업이 필요하지 않다. 따라서 가상 환경을 실행하고 종료하는데 시간이 매우 빠르며, 오버헤드도 거의 존재하지 않는다. 다른 가상화 환경 제공방식과 동일하게 프로세스를 수행하는 독립적인 공간을 제공하여, 보안적인 측면도 우수하며, 밀도 높은 설계가 가능하고 하드웨어 자원 수준이 낮다는 장점이 있다. 단, 호스트 OS인 리눅스 이외의 다른 OS에서는 동작하지 않으며, 리눅스 계열이 아닌 다른 OS를 설치할 수 없다. 이론적으로는 컨테이너의 리눅스의 모든 배포판을 설치하는 것이 가능하지만, 해당 라이브러리를 사용하는 것일 뿐, 리눅스 커널에서 실행되기 때문에 태생적인 한계도 가지고 있다. 또한 PaaS와 밀접한 이유는 독립적인 애플리케이션 수행 환경을 서비스 형태로 제공하는데 있어서 핵심 기능을 제공하고, 오버헤드가 가장 적기 때문에 가장 많이 사용되고 있는 추세다. 기업에서 사용할 때 고려해야 하는 점은 컨테이너들이 하드웨어의 리소스를 공유할 수 밖에 없기 때문에 발생하는 자원경합을 해결하는 것이 가장 중요한 과제다. 자원 경합 방지 기술 중에서 인텔 아이태니엄에만 포함되어 있다가 x86 CPU 중에서 인텔 하스웰 E7 CPU에 처음 탑재된 기능으로 TSX(Transactional Synchronoud eXtension) 기능이 있다.
이 기술은 여러 번의 연산을 컨텍스트 스위칭 없이 한 번에 처리해 준다. 컨텍스트 스위칭은 CPU 위에서 실행 중인 프로세스가 대기 중인 프로세스에게 양보하기 위해, 종료되지 않은 상태로 레지스터에 있던 데이터를 램(RAM)으로 저장하고 대기 중이던 프로세스의 데이터를 레지스터로 복사하는 작업을 말한다. 컨테이너라는 개념이 처음 등장한 것은 2000년대 중반부터 리눅스에 내장된 LXC(LinuX Container)기술로 소개되면서부터이다. 컨테이너 기술이 등장하게 된 계기는 개발한 프로그램이 구동환경의 달라짐에 따라 예상하지 못한 각종 오류를 발생시키는 것을 해결하기 위함이었다. 이런 오류가 발생하는 이유는 구동 환경마다 네트워크, 스토리지, 보안 등의 정책이 각각 다를 수 있기 때문이다. 결국 SW를 하나의 컴퓨팅 환경에서 다른 컴퓨팅 환경으로 이동하더라도 안정적으로 실행하는 방법을 모색하여 나온 방법이 바로 컨테이너이다.[6]
브이엠
브이엠(Virtual Machine, VM)은 하이퍼바이저’를 이용해 하드웨어 자원을 가상화하는 방식 또는 그 결과물을 말한다. 따라서 VM을 이해하기 위해서는 먼저 하이퍼바이저를 알아야 한다. 하이퍼바이저는 호스트 시스템에서 다수의 게스트 OS를 구동할 수 있게 하는 소프트웨어다. 하드웨어를 가상화하면서 하드웨어와 각각의 VM을 모니터링하는 중간 관리자 역할을 하는 것이 하이퍼바이저(i.e Virtual Machine Monitor)다.
구현 기술
- 한 가지 리소스에 대한 여러 논리적 구현
한 가지 리소스에 대한 여러 논리적 구현은 가장 일반적으로 사용되는 가상화 패턴 중 하나이다. 하나의 물리적 리소스와 이것의 사용자에 대한 한 개 이상의 논리적 구현으로 구성되어 있다. 소비자는 가상화 된 리소스와 인터페이싱 한다. 다른 소비자와 리소스를 공유하고 있다는 것을 모른 채 한 명의 소비자인 것처럼 말이다. 가상머신들은 패턴의 예제이다. 하드웨어 물리적 파티션과 논리적 파티션(IBM 시스템 p·z, 시스템i 서버 또는 브이엠웨어, 마이크로소프트 가상 서버, 젠 같은 소프트웨어 제품들)은 서버 가상화를 구현한다. 데이터베이스 뷰의 사용은 데이터를 분리하고 소비자는 역할과 권한에 따라 액세스 한다. 모든 소비자가 같은 데이터베이스에 액세스 하더라도 말이다. 또한 그리드는 가상화를 사용하여 네트워크를 통해 데이터를 관리하고 소비자에 대한 한 개의 시스템으로서 이를 논리적으로 표현한다.
- 다중 리소스에 대한 하나의 논리적 구현
다중 리소스에 대한 하나의 논리적 구현의 경우, 합체된 리소스들로 구성되어 하나의 인터페이스를 제공하는 하나의 논리적 구현으로서 나타난다. 하나의 보다 강력한 또는 기능적으로 가상화된 리소스들을 구현할 때 편리한 패턴이다. 스토리지 가상화는 이 패턴의 예이다. IBM의 샌 볼륨 컨트롤러(SAN Volume Controller)는 여러 스토리지 볼륨들을 결합하고 이들을 하나의 큰 스토리지 장치로 구현할 수 있다. 소비자는 데이터가 여러 디스크에 걸쳐 분포되어 있다는 사실을 모른다. 서버의 경우 클러스터링 기술은 소비자가 하나의 시스템인 헤드 노드와 상호작용 하고 있다는 착각을 하게한다. 실제로 클러스터는 많은 프로세서와 노드들을 포함하고 있다. 바로 이것이 그리드 컴퓨팅이 수행하는 것이다. 다양한 여러 리소스들이 간소화된 사용자 인터페이스(사용자 포탈 또는 애플리케이션용 표준 인터페이스)를 통해 구현된다. 전산 관점에서 볼 때 그리드는 작업 요청 소스를 제공하고, 결과를 리턴하는 등의 워크로드 가상화를 제공한다.
- 멀티 리소스들 간 하나의 논리적 구현
멀티 리소스들 간 하나의 논리적 구현의 경우, 많은 가용 리소스들 중 하나로 구현된 가상화된 리소스로 구성된다. 가상화된 리소스는 리소스 활용, 응답 시간, 접근성 같은 특정 기준에 근거하여 물리적 리소스 구현들 중 하나를 선택한다. 이들은 매우 비슷해 보이지만 이 패턴과 이전 패턴들 간에는 미묘한 차이가 있다. 우선, 각각의 물리적 리소스는 완벽한 복제고 논리적 구현으로 모아지지 않는다. 둘째, 각 물리적 리소스는 이전 패턴에서 제공된 부분적인 기능 보다는 논리적 구현에 필요한 전체 기능을 제공한다. 이 패턴의 일반적인 예로는 워크로드 밸런싱을 위해 애플리케이션 컨테이너를 사용하는 경우를 들 수 있다. 요청 또는 트랜잭션을 애플리케이션이나 서비스에 제출할 때 소비자는 여러 컨테이너들 중 하나에서 실행되는 애플리케이션의 어떤 카피가 요청과 트랜잭션을 제공하는지 신경 쓰지 않는다. 소비자는 요청 또는 트랜잭션이 핸들 되기만을 원한다. 구체적인 예로 IBM의 애플리케이션 개발 및 배치 지원 플랫폼인 웹스피어 애플리케이션 서버(WAS, WebSphere Application Server)와 가상화 제품인 웹스피어 익스텐디드 디플로이먼트(WebSphere Extended Deployment)를 들 수 있다. 또 다른 예제로는 파일 가상화이다. 데이터의 여러 카피들은 중복 또는 퍼포먼스를 위해 관리된다. 소비자가 파일에 액세스 할 때 IBM의 고성능 대용량 파일공유시스템(GPFS, General Parallel File System)과 같은 파일시스템은 여러 카피의 파일들 중 하나를 배치한다. 소비자는 사용되는 파일의 복제 위치를 몰라도 된다.[7]
할당 방법
가상 시스템을 구축하기 위해서는 물리 서버로 시스템을 구성할 때와 거의 유사한 패턴으로 진행하게 됩니다. 먼저, 시스템에서 수행될 애플리케이션의 워크로드 패턴을 분석해야 하며 이후 비기능 요구사항(NFR) 수집과 시스템 용량 분석을 진행하고, 논리 설계와 물리 설계를 진행합니다. 워크로드 패턴 : 시스템에서 애플리케이션을 수행하는 동안 소모하는 인프라 자원에 대한 사용 형태 및 사용량 비기능 요구사항(Non-Fuctional Requirement, NFR) : 비즈니스 또는 업무 기능과 무관한 시스템 자체에 대한 조건 오버커밋(overcommit) : 물리적인 용량 한계를 넘어서 할당하는 개념으로, 오버커밋 비율이 높으면 자원경합에 의한 성능 지연 현상이 발생합니다.
CPU 할당 방법
베어메탈 서버로 TA(Technical Architecture)를 설계할 때, 서버 가상화 기술로 설계할 경우 호스트 서버 한 대에 게스트 OS를 분리하여 애플리케이션 별로 최대한 고립시켜 주는 것이 유리하다. 이는 분리된 애플리케이션들은 각각의 게스트 OS 내에서 인프라 자원을 할당 받기 위한 경합을 회피할 수 있으며, OS를 각 애플리케이션에 맞도록 최적화하여 운영할 수 있기 때문이다. 가상 시스템별로 CPU를 할당해야 하는 경우 애플리케이션의 다중 스레드를 요구하는지 단일 스레드를 요구하는지 확인해야 합니다. 이러한 활동을 워크로드 분석이라고 하며, 이렇게 조사한 결과를 기준으로 CPU 자원을 할당해야 한다.
메모리
메모리도 CPU 처럼 오버커밋이 있으나 메모리는 공간을 차지하는 개념이기 때문에 먼저 메모리 공간을 차지한 VM이 메모리를 해제하거나 재기동 하기 전에는 메모리 공간을 차지한 VM이 메모리를 할당 받지 못하고 기다리는 현상이 발생함으로 보수적으로 처리해야 한다. 따라서 메모리는 오버커밋하여 사용하지 않는다. 메모리가 부족하면 스왑(SWAP)이 발생하고, 메모리가 부족한 모든 VM에 성능 하락이 발생하게 된다. 서버 가상화 기술이 발전하면서 물리 메모리의 한계를 넘어서기 위한 기술도 존재한다. 씬 프로비저닝은 VM에서 실제로 메모리를 사용할 때 물리 메모리를 조금씩 할당해 주는 방식으로 메모리 사용률에서는 효율적이지만 메모리 단편화가 발생하는 단점이 있다. 메모리 오버커밋 상태에서 게스트 OS 메모리 사용량이 하이퍼바이저 메모리 크기를 초과하면 하이퍼바이저 디스크를 사용하며, 게스트 OS의 메모리 사용량이 줄어들면 하이퍼바이저 디스크에 저장된 데이터를 하이퍼바이저 메모리로 이동하는 기술이다. 이외에도 COW(Copy on Write)와 같이 VM을 복제하여 사용하는 경우 메모리를 동일하게 복제하면 2배의 메모리 공간이 필요함으로, 복제하지 않고 2개의 VM이 동일한 메모리 영역을 참조하다가 데이터가 변경되는 시점에서 새로운 메모리를 할당하는 방법이 있다. 또한 압축 캐시라고 하여 VM에서 메모리를 사용할 때 VM과 물리 메모리 사이에 별도의 캐시 메모리를 두고, 그 캐시에 데이터를 임시 저장 후 압축해서 실제 물리 메모리에 저장하는 기능이다. 벌룬 드라이버보다는 빠르다는 장점이 있으나 데이터의 형태에 따라서 압축률이 다르고, 데이터를 압축 및 해제하기 위해서 지속적으로 CPU 연산이 필요하다는 단점이 있다. [8]
전망
지금까지 가상화 환경에 대하여 40여년의 경험을 축적한 IBM의 하이퍼바이저 기술을 중심으로 UNIX 서버 가상화의 현 주소를 가늠해 보았다. 이에 대하여 Sun에서는 "Sun의 새로운 Sun SPARC 엔터프라이즈 서버들은 메인프레임 급의 안정성, 가용성 및 서비스 용이성(RAS: Reliability, Availabiltiy & Serviceability)과 업계 선도적인 가상화 기능을 제공한다"고 주장하고 있다. Sun의 SPARC 엔터프라이즈 제품 라인은 UltraSPARC T1/T2 프로세서 또는 SPARC64-VI 프로세서, 둘 중 하나에 기반하고 있다. 여기에는 Intel, AMD, SPARC64-V, UltraSPARC IIi, IIIi, IV, IV+ 등을 탑재하는 서버들은 포함되지 않는다. 그러면 여기서는 Sun이 제공하는 각종 가상화 기능들을 살펴 보도록 하겠다.
Sun의 가상화 기술은 크게 세 가지로 나누어 볼 수 있다. 그 하나는 동적 도메인으로서 완벽한 전기적 절연 환경을 제공하는 물리적 파티셔닝이다. 물리적 파티셔닝은 물리적 자원의 한계를 넘어설 수 없다는 의미에서 복잡하게 전개된 오늘날의 데이터 센터의 문제들을 해결하는 방안이 될 수 없다. Sun이 제공하는 또 다른 파티셔닝 기술은 논리적 도메인이다. 논리적 도메인에는 일종의 펌웨어인 하이퍼바이저가 관련되는데, 이에 따라 하나의 단일 서버를 복수 개의 보다 작은 규모의 서버들로 분할할 수 있는 기능을 제공하지만 자원의 공유에 있어서 제한적이고 전체적인 자원에 대한 하나의 유연한 시야를 제공하는 데 있어서 제약이 있고 보다 근본적으로는 로우엔드에서만 제공되는 기능이어서 가상화 본연의 임무에 충실할 수 없다. 복잡하게 전개된 단일 워크로드용 서버를 하나로 통합하여 데이터 센터의 효율성을 제고할 수 있게 하려는 가상화의 근본 취지에 전혀 부합하지 못하기 때문이다. Sun은 모든 하이엔드, 미드레인지 제품군에서 동적 도메인만을 지원한다. 그 외, Sun에서는 Solaris 컨테이너를 가상화의 기능으로 주장하고 있지만 이는 하이퍼바이저에 기반한 기술이라기 보다는 운영 체제에 의존하는 가상화 기술이다. 이 기술로는 단일 운영 체제 안에서 특정 어플리케이션에 대하여 선별적으로 자원을 할당하거나 고립시킬 수 있다. 대개 시스템 수준에서의 가상화와 운영 체제 수준에서의 가상화를 묶어서 사용할 수는 있다.
HP 또한 Sun과 마찬가지로 크게 세 가지 종류의 파티셔닝 기술을 보유하고 있다. 그 하나는 Sun의 동적 도메인과 유사한 물리적 파티셔닝 nPAR 기술이고, 다른 하나는 논리적 파티셔닝 기술인 vPAR이며 나머지 하나는 운영 체제 위에서 작성되는 IVM(Integrity Virtual Machine)이다.
HP의 nPAR는 하나의 대규모 서버를 보다 작은 규모의 가상 서버들로 분할하여 사용할 수 있도록 지원하는 하드웨어 기반의 파티셔닝 기술이다. nPAR 또한 Sun의 동적 도메인과 크게 다르지 않아서 최소한 셀 보드 하나 단위 이하로는 구성이 불가능하다. nPAR 의 강조점은 데이터 센터의 유연한 구성을 지원하는 관리와 통제의 기능에 있지 않고 서버의 안정성이 불충분하여 시스템 장애가 발생하였을 때의 파티션의 안정성을 유지하기 위한 전기적 절연에 맞춰져 있다. 앞 서 살펴 보았던 IBM의 PowerVM과 비교해 보면 nPAR가 지니는 구성의 유연성이 상당히 제한적임을 쉽게 확인할 수 있다. HP의 논리적 파티셔닝 기술은 vPAR라고 불리운다. 이 기술에 의하여 nPAR에 속한 물리적 자원들은 보다 나은 조밀도를 가지고 (1 CPU, 64MB 메모리, 1 I/O 슬롯) 각 논리적 파티션에 할당될 수 있게 된다. vPAR는 nPAR와 마찬가지로 물리적 자원들을 가상 파티션에 할당 시킨다. 다만 nPAR와 비교하여 vPAR는 더 나은 조밀도를 가지는 대신 전기적 절연을 포기하였다고 볼 수 있다. 또한 vPAR는 IBM의 PowerVM과 같은 시분할 자원 공유 방식을 취하는 것이 아니라 nPAR와 마찬가지로 물리적 자원을 직접 파티션에 할당하기 때문에 프로세서 및 I/O 자원의 공유는 불가능하다. vPAR 기술로 시스템을 운영하는 중 자원을 재할당할 수 있으나 유연성의 측면에서는 다소 불충분할 수 있으므로 면밀하게 계획을 세워 파티션을 작성해야 한다.[9]
각주
- ↑ 서버 가상화 한국정보통신기술협회 - http://terms.tta.or.kr/dictionary/dictionaryView.do?word_seq=055358-1
- ↑ What is Server Virtualization? 아틀란틱넷 - https://www.atlantic.net/what-is-server-virtualization/
- ↑ 주창오, 〈가상화(Virtualization) 총정리 - 서버 가상화가 필요한 이유〉, 《티스토리》, 2012-05-21
- ↑ 4.0 4.1 서버 가상화 작동 방식 하우스터프웍스 - https://computer.howstuffworks.com/server-virtualization.htm
- ↑ 서버 가상화 기술의 진화: VM과 컨테이너 가비아 라이브러리 - http://library.gabia.com/contents/infrahosting/7426
- ↑ 안성원, 〈클라우드 가상화 기술의 변화 - 컨테이너 기반의 클라우드 가상화와 DevOps〉, 《소프트웨어정책연구소》, 2018-12-10
- ↑ 가상화: 패턴의 관점에서 본 가상화 한국데이터산업진흥원 - https://kdata.or.kr/info/info_04_view.html?field=&keyword=&type=techreport&page=260&dbnum=127235&mode=detail&type=techreport
- ↑ Lucas 팬도라, 〈IT 인프라 6편 가상화〉, 《티스토리》, 2018-10-19
- ↑ 이관용, 〈유닉스 서버 가상화 어디까지 왔나〉, 《컴퓨터월드》, 2008-03-31
참고자료
같이 보기