"서버 가상화"의 두 판 사이의 차이
leejia1222 (토론 | 기여) |
|||
(사용자 2명의 중간 판 19개는 보이지 않습니다) | |||
1번째 줄: | 1번째 줄: | ||
− | '''서버 가상화'''<!--서버 가상화, 서버가상화-->(server virtualization)<!--(server virtualization, servervirtualization, Server Virtualization, ServerVirtualization, Server virtualization)-->는 하나의 물리적 서버 호스트에서 여러 개의 서버 운영 체제를 게스트로 실행할 수 있게 해주는 소프트웨어 아키텍처다. 서버는 물리적 시스템으로부터 추상화된 서버 소프트웨어를 통해 물리적 영역을 벗어난 하나의 | + | '''서버 가상화'''<!--서버 가상화, 서버가상화-->(server virtualization)<!--(server virtualization, servervirtualization, Server Virtualization, ServerVirtualization, Server virtualization)-->는 하나의 물리적 서버 호스트에서 여러 개의 서버 운영 체제를 게스트로 실행할 수 있게 해주는 소프트웨어 아키텍처다. 서버는 물리적 시스템으로부터 추상화된 서버 소프트웨어를 통해 물리적 영역을 벗어난 하나의 가상 시스템이 된다. |
==개요== | ==개요== | ||
− | 서버 가상화는 CPU, 메모리, 입출력 등 단일 플랫폼 상의 서버 자원을 사용자가 여러 도메인이나 서버 애플리케이션으로 분할해 사용할 수 있는 기술이다. 즉 가상 플랫폼에서 모든 운영 체제의 가상 인스턴스를 생성할 수 있는 기술을 말한다. 운영 체제를 호스팅하기 위해 CPU, 디스크, 메모리 및 기타 연결된 하드웨어가 있는 서버인 물리적 플랫폼이 필요했다. 서버 가상화는 물리적으로 한대의 시스템 상에서 윈도우나 리눅스 등 각기 다른 운영체제의 다양한 서버 애플리케이션을 효율적으로 운영할 수 있어 비용 절감 및 서버 자원의 효율적인 활용이 가능하다 | + | 서버 가상화는 CPU, 메모리, 입출력 등 단일 플랫폼 상의 서버 자원을 사용자가 여러 도메인이나 서버 애플리케이션으로 분할해 사용할 수 있는 기술이다. 즉 가상 플랫폼에서 모든 운영 체제의 가상 인스턴스를 생성할 수 있는 기술을 말한다. 운영 체제를 호스팅하기 위해 CPU, 디스크, 메모리 및 기타 연결된 하드웨어가 있는 서버인 물리적 플랫폼이 필요했다. 서버 가상화는 물리적으로 한대의 시스템 상에서 윈도우나 리눅스 등 각기 다른 운영체제의 다양한 서버 애플리케이션을 효율적으로 운영할 수 있어 비용 절감 및 서버 자원의 효율적인 활용이 가능하다. 서버 가상화는 자바 가상머신처럼 현재의 운영체제 위에 가상머신을 만들어 마치 컴퓨터가 여러대 있는 것처럼 시스템을 구축하여 동시에 운영하는 방식과 하드웨어를 파티션으로 나누어 각기 다른 운영체계를 얹는 방식이다. 그리고 다중 운영체계와 하드웨어 사이에 가상화의 계층을 두는 방식 등 여러 가지가 있다.<ref>서버 가상화 한국정보통신기술협회 - http://terms.tta.or.kr/dictionary/dictionaryView.do?word_seq=055358-1</ref> 일반적인 서버 가상화에서 많은 가상 시스템이 물리적 서버에 연결되며 하이퍼바이저(Hypervisor)는 호스트 하드웨어를 각 개별 가상 컴퓨터와 공유하는 데 사용된다. 서버 가상화는 과거에는 가능하지 않았던 수준으로 효율적인 IT 리소스의 사용을 지원한다. 서버 가상화가 등장하기 전에는 하나의 데이터센터에 너무 많이 사용되는 하드웨어와 많이 사용되지 않는 하드웨어가 동시에 존재하는 경우가 많았다. 그러나 가상화 등장 후 여러 가상 시스템에서 부하에 따라 워크로드를 이동할 수 있게 되었으며, 하나의 물리적 서버에서 여러 개의 서버 운영체제와 구성을 실행할 수 있게 되어 효율성이 향상되었다. 따라서 서버 가상화를 통해 리소스를 다른 많은 가상 컴퓨터와 공유할 수 있으므로 조직은 데이터 센터 하드웨어 사용 공간 및 방대한 양의 물리적 하드웨어를 실행하는 데 드는 관련 비용을 크게 줄일 수 있다. 한편 서버 가상화는 클라우드 컴퓨팅과 하이브리드 IT의 근간이 된다. |
==역사== | ==역사== | ||
− | + | 서버당 운영체제 인스턴스 하나와 애플리케이션 하나를 실행하는 대신 여러 운영체제 인스턴스 및 관련 워크로드를 하나의 실제 서버에서 실행할 수 있게 해주는 소프트웨어 계층, 즉 하이퍼바이저를 추가할 수 있다는 생각이 서버 가상화의 기원이며 그 유래는 1960년대 IBM 메인프레임 시대까지 거슬러 올라간다. 서버 가상화가 보편화된 것은 2000년대 초반 VM웨어가 x86 서버를 위한 가상화 소프트웨어를 출시하면서부터다. 이후 다른 여러 업체에서도 자체 서버 가상화 플랫폼을 개발했고 업계 전반적으로 가상머신(Virtual Machine) 워크로드의 배포, 이동, 관리를 쉽게 해주는 고급 관리, 자동화 및 오케스트레이션 툴이 탄생했다. 서버 가상화 이전, 기업은 무질서한 서버 증설과 제대로 활용되지 못하는 컴퓨팅 성능, 치솟는 전력 요금에 시달렸으며, 데이터센터 환경에는 수동 프로세스와 전반적인 비효율성, 경직성이 만연했다. 서버 가상화는 이러한 모든 상황을 바꿔 놓았고 광범위하게 도입됐다. 사실 오늘날 대부분의 워크로드를 VM 환경에서 실행하지 않는 기업을 찾기 어려울 정도다. 그러나 모두가 알다시피 그 다음 큰 물결에 밀려나지 않는 기술이란 없다. 서버 가상화의 경우 다음 큰 물결은 소형화다. 서버 가상화는 실제 디바이스를 가상으로 잘게 나눠서 여러 운영체제와 여러 애플리케이션이 기반 컴퓨팅 파워를 끌어 쓸 수 있도록 한다. 컴퓨팅의 다음 변화는 애플리케이션을 가벼운 컨테이너에서 실행되는 더 작은 마이크로서비스로 나누는 것, 그리고 아직 실험 중이지만 서버리스 컴퓨팅이다. 두 가지 시나리오 모두 VM을 완전히 생략하고 베어 메탈에서 코드를 실행한다.<ref> Neal Weinberg , 〈[http://www.itworld.co.kr/news/110031 서버 가상화의 미래 : 컨테이너 및 서버리스 비교 진단]〉, 《아이티월드》, 2018-07-13</ref> | |
− | |||
− | |||
==특징== | ==특징== | ||
− | === | + | ===필요성=== |
− | + | 서버 가상화에 대한 투자가 이루어지는 데는 많은 이유가 있다. 일부는 비용 절감의 일환으로 진행되는가 하면, 순수하게 기술적인 이유로 진행되는 경우도 있다. 서버 가상화는 통합을 통하여 공간을 줄일 수 있다. 하나의 서버는 하나의 애플리케이션을 구동하는 형태가 일반적인데, 상당수의 애플리케이션들은 적은 양의 처리능력만을 사용한다. 따라서 네트워크 관리자는 이러한 서버들을 하나의 서버로 통합하여, 다수의 가상 환경을 구동시킴으로써, 물리 서버 및 공간을 절감할 수 있다. 수백 또는 수천 대의 서버를 운영하는 기업에게 있어서 가상화의 적용을 통해 물리적 공간을 현저히 줄일 수 있다. 서버 가상화는 추가적인 물리 서버 구매 없이도 리던던시(Redundancy)를 확보할 수 있게 한다. 리던던시는 여러 개의 하드웨어에 동일한 애플리케이션을 구동함으로써, 하나의 서버가 오동작을 하더라도 다른 서버에서 동일 애플리케이션을 구동하므로 중요한 안전장치가 된다. 이러한 리던던시는 서비스 중단을 최소화한다. 하나의 애플리케이션을 구동하는 두 개의 가상서버가 하나의 물리 서버에 구축되는 경우, 물리 서버의 다운은 가상 서버의 즉각적인 중단을 유발하므로, 대부분의 네트워크 관리자들은 리던던시 가상 서버를 다른 물리 서버에 구축하는 것이 일반적이다. 가상 서버는 프로그래머의 독립성을 보장해준다. 즉 독립된 시스템에서 신규 애플리케이션을 테스트하거나 운영할 수 있도록 한다. 네트워크 관리자는 전용 물리 서버를 구매하지 않고도 신규 가상 서버를 즉시 생성하여 할당할 수 있다. 서버 하드웨어가 노후화되는 경우, 하나의 시스템에서 다른 시스템으로 전환하는 것은 매우 어려운 작업일 수 있다. 노후화 된 시스템(종종 레가시 시스템으로 부른다)에서 제공되는 서비스의 연속성을 위해, 네트워크 관리자는 최신 물리 서버에 가상 서버를 생성할 수 있다. 애플리케이션 운영상 볼 때 바뀌는 것은 없으며, 프로그램은 마치 과거의 하드웨어에서 구동되는 것처럼 운영된다. 이는 새로운 프로세스로의 전환 시, 하드웨어 오동작에 대한 우려를 덜어주며, 특히 레가시 하드웨어 공급업체가 없어져서 더 이상의 유지보수가 불가능한 경우에는 더욱 유효하다.<ref="굿">ITX's Cloud, 〈[https://itxcloud.tistory.com/entry/%EA%B0%80%EC%83%81%ED%99%94Virtualization-%EC%B4%9D%EC%A0%95%EB%A6%AC-2-%EC%84%9C%EB%B2%84-%EA%B0%80%EC%83%81%ED%99%94-Server-Virtualization-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80?category=439331 가상화(Virtualization) 총정리 (2) - 서버 가상화(Server Virtualization)란 무엇인가?]〉, 《티스토리》, 2012-05-22</ref> | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | === | + | ===한계=== |
− | + | 서버 가상화가 주는 혜택은 너무도 매력적이어서, 모든 기술에는 한계가 있다는 사실을 종종 잊어버리게 한다. 서버 가상화는 도입 전 반드시 자체 네트워크 아키텍처와 필요 사항, 도입 예정인 서버 가상화 기술을 면밀히 검토하여야 한다. CPU 점유율이 높은 애플리케이션의 전용 서버에 있어서 가상화는 큰 도움이 되지 않을 수도 있다. 가상화는 본질적으로 물리 서버의 처리능력을 여러 개의 가상 서버에 나누어 사용하기 때문에, 애플리케이션의 요구환경에 미달할 경우, 문제가 발생할 수 있다. 최악의 경우 서버의 처리능력을 넘어서게 되면, 시스템이 다운될 가능성도 있다. 따라서 네트워크 관리자는 사전에 CPU 사용량을 자세히 검토해야 한다. 하나의 물리 서버에 지나치게 많은 가상 서버들을 생성하여 서버의 CPU에 과부하를 일으키는 것은 그다지 현명한 일이 아니다. 하나의 물리 서버에서 구동하는 가상 서버가 많아지면 많아질수록, 각각의 가상 서버가 사용할 수 있는 처리 능력은 줄어들게 되며, 물리 서버의 디스크 사용량 또한 동일한 문제를 일으킬 수 있다. 또 다른 문제는 마이그레이션인데, 현재는 하나의 물리 서버에서 구동되는 가상 서버를 마이그레이션할 수 있는 전제조건은 동일한 제조사의 프로세서를 사용해야 한다는 것이다. 만일 동일한 네트워크 상에 있는 인텔 프로세서를 사용하는 서버에서 AMP 프로세서를 사용하는 서버로 가상 서버를 포팅하고자 한다면, 이는 불가능하다. 가상 서버의 마이그레이션이 왜 필요한 이유는 만일 하나의 물리 서버에 대한 유지보수가 필요할 경우, 다른 물리 서버로 가상 서버를 포팅하는 것이 애플리케이션 다운타임을 최소화 할 수 있기 때문이다. 마이그레이션은 선택사항이 아니다. 하나의 물리서버에서 구동되는 가상 서버의 모든 애플리케이션들은, 유지보수 시에는 서비스가 불가하게 될 것이다. 이러한 제약사항에도 불구하고 많은 기업들은 서버 가상화에 대한 투자를 지속하고 있다. 서버 가상화 기술이 발전하게 되면, 대규모 데이터센터가 필요하지 않는 상황이 발생할 수도 있다. 서버의 전력 소비량과 열 발생량 또한 감소하게 되면, 자원 활용에 대한 효율성 뿐만 아니라, 그린 IT에 대한 니즈 또한 충족시킬 수 있다.<ref="굿"></ref> | |
==종류== | ==종류== | ||
===전가상화=== | ===전가상화=== | ||
− | 전가상화(Full | + | 전가상화(Full Virtualization)는 하이퍼바이저라는 특수한 소프트웨어를 사용한다. 하이퍼바이저는 물리 서버의 CPU와 디스크에 직접 상호작용을 하며, 가상 서버의 운영체제를 위한 플랫폼 역할을 한다. 즉 운영체제 위에 하이퍼바이저가 설치되고, 그 위에서 가상 서버 및 운영체제가 실행되는 방식이다. 하이퍼바이저는 각각의 가상 서버들을 완전히 독립적으로 운용하도록 한다. 각각의 게스트 서버는 자체 운영체제에서 운영되기 때문에, [[리눅스]] 기반 게스트와 [[윈도우]] 기반 게스트를 동시에 운용할 수도 있다. 하이퍼바이저는 물리 서버의 자원을 모니터링하여, 가상 서버에서 애플리케이션이 구동될 때, 물리 서버의 자원을 적절한 가상 서버에 할당해 준다. 물론 하이퍼바이저 자체 구동을 위해서도 처리능력 등의 리소스를 필요로 하기 때문에, 하이퍼바이저의 리소스 사용량은 전체 서버 퍼포먼스와 애플리케이션 구동속도에 영향을 줄 수 있다. 전가상화는 컴퓨팅 시스템의 하드웨어 리소스를 완전하게 가상화 하는 방식으로 그 위에서 동작하게 될 게스트 운영체제의 수정 없이 구동이 가능하다. [[마이크로소프트]] [[윈도우]]에서 리눅스 까지 다양한 운영체제를 사용할 수 있기 때문에 적용이 쉬운 편이다. 컴퓨팅환경을 기존의 운영체제 위에서 에뮬레이션 하는 형식으로 지원하기에 호스트(Host)형 가상화 라고도 한다. 다만 CPU의 가상화 지원 기술(VT, Virtualization Technology)과 같은 하드웨어 기능을 일부 지원받기 때문에 모든 기능을 소프트웨어적으로 구동하는 에뮬레이션과는 차이가 있다. 하이퍼바이저를 직접 실행하기에 편리한 인터페이스 화면을 제공하지만, 반면 이에 따른 성능 감소가 생긴다는 단점이 있다. |
===반가상화=== | ===반가상화=== | ||
− | 반가상화(Para-Virtualization)는 전가상화와는 달리, 게스트 서버 간의 독립성 없이 상호작용한다. 물리 서버 위에 하이퍼바이저가 직접 설치되고, 그 위에서 가상 서버 및 운영체제가 실행되는 방식이다. 반가상화 하이퍼바이저는 게스트 운영체제를 관리하기 위해 필요한 자원(처리능력)이 상대적으로 적게 든다. 이는 각각의 운영체제가 동일한 물리 서버에서 운영되는 다른 운영체제에서 필요로 하는 자원을 이미 인지하고 있으며, 이들 시스템은 마치 하나처럼 동작하게 된다.반가상화는 하드웨어를 완전히 가상화하지 않는 방식이다. 하이퍼바이저가 하드웨어 위에서 직접 실행되기 때문에 네이티브(Native, Bare-metal) 가상화 라고도 한다. 물리 서버의 성능을 최대한 발휘하면서 가상 서버의 성능을 제공하기에 성능이 많이 감소되지 않으면서 가상 서버를 제공하지만, 물리 서버 바로 위에 설치된 하이퍼바이저를 직접적으로 관리하기에는 어려움이 있다. 반가상화는 하드웨어에 대한 제어권을 하이퍼바이저가 가지고 있기 때문에, 하드웨어와의 I/O 처리에 있어서 전가상화보다 직접적인 루틴을 사용한다. | + | 반가상화(Para-Virtualization)는 전가상화와는 달리, 게스트 서버 간의 독립성 없이 상호작용한다. 물리 서버 위에 하이퍼바이저가 직접 설치되고, 그 위에서 가상 서버 및 운영체제가 실행되는 방식이다. 반가상화 하이퍼바이저는 게스트 운영체제를 관리하기 위해 필요한 자원(처리능력)이 상대적으로 적게 든다. 이는 각각의 운영체제가 동일한 물리 서버에서 운영되는 다른 운영체제에서 필요로 하는 자원을 이미 인지하고 있으며, 이들 시스템은 마치 하나처럼 동작하게 된다. 반가상화는 하드웨어를 완전히 가상화하지 않는 방식이다. 하이퍼바이저가 하드웨어 위에서 직접 실행되기 때문에 네이티브(Native, Bare-metal) 가상화 라고도 한다. 물리 서버의 성능을 최대한 발휘하면서 가상 서버의 성능을 제공하기에 성능이 많이 감소되지 않으면서 가상 서버를 제공하지만, 물리 서버 바로 위에 설치된 하이퍼바이저를 직접적으로 관리하기에는 어려움이 있다. 반가상화는 하드웨어에 대한 제어권을 하이퍼바이저가 가지고 있기 때문에, 하드웨어와의 I/O 처리에 있어서 전가상화보다 직접적인 루틴을 사용한다. |
===운영체제 수준 가상화=== | ===운영체제 수준 가상화=== | ||
− | 운영체제 수준 가상화(operating-system-level virtualization)는 운영체제의 중앙 태스크 관리자인 [[커널]]에서 이루어진다. 이렇게 하면 리눅스 환경과 윈도우 환경을 함께 실행할 수 있다. 또한 기업은 가상 운영 체제를 컴퓨터에 푸시해 여러가지 이점을 얻을 수 있다. 컴퓨터에 고도의 OOTB(Out Of The Box) 기능이 필요하지 않으므로 하드웨어에 많은 비용이 소모되지 않는다. 모든 가상 인스턴스를 모니터링하고 격리할 수 있으므로 보안이 강화된다. 소프트웨어 업데이트와 같은 IT 서비스에 소요되는 시간이 절약된다. 운영 체제 수준 가상화는 커널이 여러 개의 격리된 사용자 공간 인스턴스의 존재를 허용하는 운영 체제 패러다임을 말한다. 컨테이너(LXC, 솔라리스 컨테이너, 도커), 솔라리스 컨테이너 영역, 가상 개인 서버(오픈VZ), 파티션, 가상 환경(VEs), 가상 커널(드래곤 플라이 BSD) 또는 감옥(FreeBSD 감옥 또는 chroot 감옥) 등 이것을 실행 하는 프로그램의 관점에서 실제 컴퓨터 처럼 보일 수 있다. 일반 운영체제에서 실행되는 컴퓨터 프로그램은 해당 컴퓨터의 모든 리소스를 볼 수 있다. 그러나 컨테이너 내부에서 실행되는 프로그램은 컨테이너에 할당된 컨테이너의 내용 및 장치만 볼 수 있다. 유닉스와 같은 운영 체제에서 이 기능은 표준 chroot 메커니즘의 고급 구현으로 볼 수 있으며, 이는 현재 실행 중인 프로세스및 해당 하위에 대한 명백한 루트 폴더를 변경한다. 커널은 격리 메커니즘 외에도 한 컨테이너 활동이 다른 컨테이너에 미치는 영향을 제한하는 리소스 관리 기능을 제공하는 경우가 많다.<ref name="하우">서버 가상화 작동 방식 하우스터프웍스 - https://computer.howstuffworks.com/server-virtualization.htm</ref> | + | 운영체제 수준 가상화(operating-system-level virtualization)는 OS레벨 가상화라고도 하며 운영체제의 중앙 태스크 관리자인 [[커널]]에서 이루어진다. 이렇게 하면 리눅스 환경과 윈도우 환경을 함께 실행할 수 있다. 또한 기업은 가상 운영 체제를 컴퓨터에 푸시해 여러가지 이점을 얻을 수 있다. 컴퓨터에 고도의 OOTB(Out Of The Box) 기능이 필요하지 않으므로 하드웨어에 많은 비용이 소모되지 않는다. 모든 가상 인스턴스를 모니터링하고 격리할 수 있으므로 보안이 강화된다. 소프트웨어 업데이트와 같은 IT 서비스에 소요되는 시간이 절약된다. 운영 체제 수준 가상화는 커널이 여러 개의 격리된 사용자 공간 인스턴스의 존재를 허용하는 운영 체제 패러다임을 말한다. 컨테이너(LXC, 솔라리스 컨테이너, 도커), 솔라리스 컨테이너 영역, 가상 개인 서버(오픈VZ), 파티션, 가상 환경(VEs), 가상 커널(드래곤 플라이 BSD) 또는 감옥(FreeBSD 감옥 또는 chroot 감옥) 등 이것을 실행 하는 프로그램의 관점에서 실제 컴퓨터 처럼 보일 수 있다. 일반 운영체제에서 실행되는 컴퓨터 프로그램은 해당 컴퓨터의 모든 리소스를 볼 수 있다. 그러나 컨테이너 내부에서 실행되는 프로그램은 컨테이너에 할당된 컨테이너의 내용 및 장치만 볼 수 있다. 유닉스와 같은 운영 체제에서 이 기능은 표준 chroot 메커니즘의 고급 구현으로 볼 수 있으며, 이는 현재 실행 중인 프로세스및 해당 하위에 대한 명백한 루트 폴더를 변경한다. 커널은 격리 메커니즘 외에도 한 컨테이너 활동이 다른 컨테이너에 미치는 영향을 제한하는 리소스 관리 기능을 제공하는 경우가 많다.<ref name="하우">서버 가상화 작동 방식 하우스터프웍스 - https://computer.howstuffworks.com/server-virtualization.htm</ref> |
− | == | + | ==기능== |
− | + | 서버 가상화는 관리 면에서 장점이 많다. 서버 가상화는 한 대의 서버를 많은 서버로 분할하여 이용하는 기술로, 가상화 소프트웨어를 사용하여 하드웨어(CPU나 메모리, 스토리지 드라이브 등)를 논리적으로 분할하여 운영체제에 할당함으로써 서버의 분할을 구현한다. 서버 가상화로 만든 서버를 가상머신 또는 가상서버라고 한다. 서버 가상화는 물리적으로 몇 개의 서버를 한 대로 집약하여 설치 공간을 줄이거나 스케줄링(scheduling), 라이브 마이그레이션(live migration), 결함 포용(fault tolerance) 기능을 사용하여 다른 서버로 가상머신을 이동시킬 수 있는 등 시스템 관리자에게 있어서 큰 장점을 갖고 있어 폭발적으로 보급되었다. 그중 서버 가상화의 주요 기능은 라이브 마이그레이션이다. | |
− | |||
− | |||
− | === | + | ===라이브 마이그레이션=== |
− | + | 라이브 마이그레이션(Live Migration)은 1대의 서버에서 동작 중인 애플리케이션을 다른 서버로 이동해서 동작을 계속하도록 하는 것을 말한다. 공통 메모리가 아니라 다른 서버로 이동할 경우는 가상 프로세서의 상태를 이동하면서 동시에 원래의 가상 프로세서가 사용하고 있던 명령이나 데이터 메모리를 이동해갈 프로세서의 메모리로 카피해서, 애플리케이션 프로그램에서 볼 때 동일한 어드레스가 되도록 페이지 테이블을 구축할 필요가 있다. 그러고 나서 애플리케이션이 사용하고 있던 파일이나 LAN 등으로의 액세스도 넘겨줄 필요가 있다. 라이브 마이그레이션이 가능하다면 부하가 높은 서버에서 부하가 낮은 서버로 처리를 옮겨서 부하를 평준화하거나, IDC 전체의 부하가 낮은 경우에는 소수의 서버로 처리를 집중시켜 남은 서버의 전원을 오프해서 에너지 사용을 줄이는 것과 같은 사용법이 가능하다. | |
− | === | + | ==종류== |
− | + | ===호스트=== | |
+ | [[파일:호스트 가상화.png|썸네일|400픽셀|호스트형 서버 가상화]] | ||
− | + | 호스트형 서버 가상화는 교육이나 실습 환경으로도 많이 사용하는 환경으로, 흔히 사용하는 운영체제 위에 가상화 프로그램을 설치해 거기에 가상머신을 띄워 원하는 운영체제를 설치하는 기술이다.<ref>Flature, 〈[https://thinkground.studio/%ED%98%B8%EC%8A%A4%ED%8A%B8%ED%98%95-%EC%84%9C%EB%B2%84-%EA%B0%80%EC%83%81%ED%99%94hosted-virtualization-architecture/ 호스트형 서버 가상화(Hosted Virtualization Architecture)]〉, 《띵크그라운드》, 2019-04-14</ref> 하이퍼바이저 또는 가상머신 모니터라고 하는 소프트웨어가 호스트 운영체제 위에 설치되며, 이를 통해 사용자들은 애플리케이션 윈도우 내에서 다양한 게스트 운영체제를 실행할 수 있다. 호스트형 가상화는 물리 컴퓨터의 하드웨어를 에뮬레이트 하기 때문에 오버헤드는 크지만, 게스트 운영체제 종류에 대한 제약이 없어서 거의 대부분의 운영체제에서 동작시킬 수 있다. 호스트형 가상화의 장점으로는 사용자가 호스트 운영체제를 수정하지 않고도 가상머신 아키텍처를 설치할 수 있다는 것이다. 가상화 소프트웨어는 호스트 운영체제에 의존하여 장치 드라이버 및 기타 저수준 서비스를 제공할 수 있다. 이로 인하여 가상머신의 설계가 간소화되고 배포도 쉬워진다. 호스트형 가상화의 단점으로는 성능이 하이퍼바이저나 가상머신 모니터를 사용하는 가상화에 비해 낮을 수 있다. 예를 들면 응용 프로그램에서 하드웨어 액세스를 요청하면 4개의 매핑 계층을 통과해야 하기 때문에 성능이 크게 저하된다. 브이엠웨어(VMware)의 워크스테이션(Workstation), 서버(Server), 플레이어(Player), 마이크로소프트(MS)의 가상서버(Virtual Sever), 가상PC(Virtual PC), 가상박스(Virtual Box), 패러렐 워크스테이션(Paralles Workstation) 등이 있다.<ref>LIB, 〈[https://blog.naver.com/gkenq/10190004678 서버 가상화 종류: ② 호스트(Hosted)형]〉, 《네이버 블로그》, 2014-04-25</ref> | |
− | === | + | ===하이퍼바이저=== |
− | + | [[파일:하이퍼바이저 가상화.png|썸네일|400픽셀|하이퍼바이저형 서버 가상화]] | |
− | + | 하이퍼바이저(Hypervisor)는 서버 가상화를 실현하는 플랫폼이다. 가상화 머신 모니터 또는 가상화 머신 매니저라고도 부르며 여러 개의 가상머신이 한정된 하드웨어 자원을 나눠 쓸 수 있도록 한다. 운영체제와 합쳐진 형태와 분리된 형태로 나뉜다. 전가상화 반가상화라고 부르는 이러한 방법은 하이퍼바이저의 역할 범위에 따라 구분한 것으로 전가상화는 하이퍼바이저가 호스트 운영체제에서 모든 일을 처리하는 것이며, 반가상화는 일부 역할을 가상머신의 도움을 받아서 처리하는 개념이다. 하이퍼바이저는 크게 TYPE1과 TYPE2 2가지 방식으로 구분된다. TYPE1 방식은 물리 서버 위에 하이퍼바이저가 직접 설치되고, 그 위에서 가상 서버 및 운영체제가 실행되는 방식이고, TYPE2 방식은 운영체제 위에 하이퍼바이저가 설치되고, 그 위에서 가상 서버 및 운영체제가 실행되는 방식이다. TYPE1 하이퍼바이저는 네이티브(Native) 또는 베어메탈(Bare-metal) 방식의 하이퍼바이저라고도 하며, 하드웨어 계층 바로 위에서 하이퍼바이저가 동작하여 가상 서버를 제공한다. 물리 서버의 성능을 최대한 발휘하면서 가상 서버의 성능을 제공하기에, 성능이 많이 감소되지 않으면서 가상 서버를 제공하지만, 물리 서버 바로 위에 설치된 하이퍼바이저를 직접적으로 관리하기에는 어려움이 있다. | |
− | |||
+ | 반면, TYPE2 하이퍼바이저는 Hosted 하이퍼바이저라고도 하며, 기존 물리 서버에 설치된 운영체제 위에 하이퍼바이저가 설치되어 동작하므로, 하나의 물리 서버 위에 여러 종류의 하이퍼바이저를 실행할 수 있다. 또한, 하이퍼바이저를 직접 실행하기에 편리한 인터페이스 화면을 제공하지만, 반면 이에 따른 성능 감소가 생긴다는 단점이 있다. 실제로 TYPE1 하이퍼바이저는 성능에 대한 이점이 있어 서버 인프라 환경을 구성할 때 많이 사용한다. 단, 하이퍼바이저를 관리하기 위해 별도의 관리용 네트워크 망을 구성하여 특정 컴퓨터에서 하이퍼바이저에 접속하여 관리하는 형태로 사용한다. 반면, TYPE2 하이퍼바이저는 주로 가정용 컴퓨터 또는 운영체제가 이미 설치된 컴퓨터에서 여러 운영체제를 설치하여 테스트하는 목적으로 사용 가능하다.<ref>최영락 휴레이포티지브 선임연구원, 오픈플로우코리아 기술매니저, 〈[http://tech.kobeta.com/wp-content/uploads/2016/10/23212.pdf 가상화와 컴퓨터 네트워크의 활용 1 : 가상화와 데이터센터]〉, 《방송과 기술 Vol.232》</ref> | ||
− | == | + | ===컨테이너=== |
− | + | [[파일:컨테이너 가상화.png|썸네일|400픽셀|컨테이너형 서버 가상화]] | |
− | |||
− | + | 컨테이너(container)는 가상머신이 없으며 게스트 OS도 없다. 호스트 OS입장에서 보면 컨테이너는 하나의 프로세스로 기동하기 때문에 하드웨어를 초기화 하는 작업이 필요하지 않다. 따라서 가상 환경을 실행하고 종료하는데 시간이 매우 빠르며, 오버헤드도 거의 존재하지 않는다. 다른 가상화 환경 제공방식과 동일하게 프로세스를 수행하는 독립적인 공간을 제공하여, 보안적인 측면도 우수하며, 밀도 높은 설계가 가능하고 하드웨어 자원 수준이 낮다는 장점이 있다. 단, 호스트 OS인 리눅스 이외의 다른 OS에서는 동작하지 않으며, 리눅스 계열이 아닌 다른 OS를 설치할 수 없다. 이론적으로는 컨테이너의 리눅스의 모든 배포판을 설치하는 것이 가능하지만, 해당 라이브러리를 사용하는 것일 뿐, 리눅스 커널에서 실행되기 때문에 태생적인 한계도 가지고 있다. 또한 PaaS와 밀접한 이유는 독립적인 애플리케이션 수행 환경을 서비스 형태로 제공하는데 있어서 핵심 기능을 제공하고, 오버헤드가 가장 적기 때문에 가장 많이 사용되고 있는 추세다. 기업에서 사용할 때 고려해야 하는 점은 컨테이너들이 하드웨어의 리소스를 공유할 수 밖에 없기 때문에 발생하는 자원경합을 해결하는 것이 가장 중요한 과제다. 자원 경합 방지 기술 중에서 인텔 아이태니엄에만 포함되어 있다가 x86 CPU 중에서 인텔 하스웰 E7 CPU에 처음 탑재된 기능으로 TSX(Transactional Synchronoud eXtension) 기능이 있다. | |
− | |||
− | + | 이 기술은 여러 번의 연산을 컨텍스트 스위칭 없이 한 번에 처리해 준다. 컨텍스트 스위칭은 CPU 위에서 실행 중인 프로세스가 대기 중인 프로세스에게 양보하기 위해, 종료되지 않은 상태로 레지스터에 있던 데이터를 램(RAM)으로 저장하고 대기 중이던 프로세스의 데이터를 레지스터로 복사하는 작업을 말한다. 컨테이너라는 개념이 처음 등장한 것은 2000년대 중반부터 리눅스에 내장된 LXC(LinuX Container)기술로 소개되면서부터이다. 컨테이너 기술이 등장하게 된 계기는 개발한 프로그램이 구동환경의 달라짐에 따라 예상하지 못한 각종 오류를 발생시키는 것을 해결하기 위함이었다. 이런 오류가 발생하는 이유는 구동 환경마다 네트워크, 스토리지, 보안 등의 정책이 각각 다를 수 있기 때문이다. 결국 SW를 하나의 컴퓨팅 환경에서 다른 컴퓨팅 환경으로 이동하더라도 안정적으로 실행하는 방법을 모색하여 나온 방법이 바로 컨테이너이다.<ref> 안성원, 〈[https://spri.kr/files/1544421791_k7LnlkLc9mgJgots3jU7H3BR_0.pdf 클라우드 가상화 기술의 변화 - 컨테이너 기반의 클라우드 가상화와 DevOps]〉, 《소프트웨어정책연구소》, 2018-12-10</ref> | |
− | |||
==할당 방법== | ==할당 방법== | ||
− | 가상 시스템을 구축하기 위해서는 물리 서버로 시스템을 구성할 때와 거의 유사한 패턴으로 진행하게 | + | 가상 시스템을 구축하기 위해서는 물리 서버로 시스템을 구성할 때와 거의 유사한 패턴으로 진행하게 된다. 먼저, 시스템에서 수행될 애플리케이션의 워크로드 패턴을 분석해야 하며 이후 비기능 요구사항(NFR) 수집과 시스템 용량 분석을 진행하고, 논리 설계와 물리 설계를 진행한다. 워크로드 패턴이란 시스템에서 애플리케이션을 수행하는 동안 소모하는 인프라 자원에 대한 사용 형태 및 사용량을 말한다. 그리고 비기능 요구사항(Non-Fuctional Requirement, NFR)은 비즈니스 또는 업무 기능과 무관한 시스템 자체에 대한 조건을 말한다. 또한 오버커밋(overcommit)은 물리적인 용량 한계를 넘어서 할당하는 개념으로, 오버커밋 비율이 높으면 자원경합에 의한 성능 지연 현상이 발생한다. |
− | 먼저, 시스템에서 수행될 애플리케이션의 워크로드 패턴을 분석해야 하며 이후 비기능 요구사항(NFR) 수집과 시스템 용량 분석을 진행하고, 논리 설계와 물리 설계를 | ||
− | 워크로드 | ||
− | 비기능 요구사항(Non-Fuctional Requirement, NFR) | ||
− | 오버커밋(overcommit) | ||
− | ===CPU | + | ===CPU=== |
− | 베어메탈 서버로 TA(Technical Architecture)를 설계할 때, 서버 가상화 기술로 설계할 경우 호스트 서버 한 대에 게스트 OS를 분리하여 애플리케이션 별로 최대한 고립시켜 주는 것이 유리하다. 이는 분리된 애플리케이션들은 각각의 게스트 OS 내에서 인프라 자원을 할당 받기 위한 경합을 회피할 수 있으며, OS를 각 애플리케이션에 맞도록 최적화하여 운영할 수 있기 때문이다. 가상 시스템별로 CPU를 할당해야 하는 경우 애플리케이션의 다중 스레드를 요구하는지 단일 스레드를 요구하는지 확인해야 | + | 베어메탈 서버로 TA(Technical Architecture)를 설계할 때, 서버 가상화 기술로 설계할 경우 호스트 서버 한 대에 게스트 OS를 분리하여 애플리케이션 별로 최대한 고립시켜 주는 것이 유리하다. 이는 분리된 애플리케이션들은 각각의 게스트 OS 내에서 인프라 자원을 할당 받기 위한 경합을 회피할 수 있으며, OS를 각 애플리케이션에 맞도록 최적화하여 운영할 수 있기 때문이다. 가상 시스템별로 CPU를 할당해야 하는 경우 애플리케이션의 다중 스레드를 요구하는지 단일 스레드를 요구하는지 확인해야 한다. 이러한 활동을 워크로드 분석이라고 하며, 이렇게 조사한 결과를 기준으로 CPU 자원을 할당해야 한다. |
===메모리=== | ===메모리=== | ||
− | 메모리도 CPU 처럼 오버커밋이 있으나 메모리는 공간을 차지하는 개념이기 때문에 먼저 메모리 공간을 차지한 | + | 메모리도 CPU 처럼 오버커밋이 있으나 메모리는 공간을 차지하는 개념이기 때문에 먼저 메모리 공간을 차지한 가상머신이 메모리를 해제하거나 재기동 하기 전에는 메모리 공간을 차지한 가상머신이 메모리를 할당 받지 못하고 기다리는 현상이 발생함으로 보수적으로 처리해야 한다. 따라서 메모리는 오버커밋하여 사용하지 않는다. 메모리가 부족하면 스왑(SWAP)이 발생하고, 메모리가 부족한 모든 가상머신에 성능 하락이 발생하게 된다. 서버 가상화 기술이 발전하면서 물리 메모리의 한계를 넘어서기 위한 기술도 존재한다. 씬 프로비저닝은 가상머신에서 실제로 메모리를 사용할 때 물리 메모리를 조금씩 할당해 주는 방식으로 메모리 사용률에서는 효율적이지만 메모리 단편화가 발생하는 단점이 있다. 메모리 오버커밋 상태에서 게스트 OS 메모리 사용량이 하이퍼바이저 메모리 크기를 초과하면 하이퍼바이저 디스크를 사용하며, 게스트 OS의 메모리 사용량이 줄어들면 하이퍼바이저 디스크에 저장된 데이터를 하이퍼바이저 메모리로 이동하는 기술이다. 이외에도 COW(Copy on Write)와 같이 가상머신을 복제하여 사용하는 경우 메모리를 동일하게 복제하면 2배의 메모리 공간이 필요함으로, 복제하지 않고 2개의 가상머신이 동일한 메모리 영역을 참조하다가 데이터가 변경되는 시점에서 새로운 메모리를 할당하는 방법이 있다. 또한 압축 캐시라고 하여 가상머신에서 메모리를 사용할 때 가상머신과 물리 메모리 사이에 별도의 캐시 메모리를 두고, 그 캐시에 데이터를 임시 저장 후 압축해서 실제 물리 메모리에 저장하는 기능이다. 벌룬 드라이버보다는 빠르다는 장점이 있으나 데이터의 형태에 따라서 압축률이 다르고, 데이터를 압축 및 해제하기 위해서 지속적으로 CPU 연산이 필요하다는 단점이 있다.<ref> Lucas 팬도라, 〈[https://judo0179.tistory.com/36 IT 인프라 6편 가상화]〉, 《티스토리》, 2018-10-19</ref> |
− | |||
− | |||
− | |||
− | |||
− | 썬의 가상화 기술은 크게 세 가지로 나누어 볼 수 있다. 그 하나는 동적 도메인으로서 완벽한 전기적 절연 환경을 제공하는 물리적 파티셔닝이다. 물리적 파티셔닝은 물리적 자원의 한계를 넘어설 수 없다는 의미에서 복잡하게 전개된 오늘날의 데이터 센터의 문제들을 해결하는 방안이 될 수 없다. | + | ==주요 기업== |
+ | ===썬 마이크로시스템즈=== | ||
+ | [[썬 마이크로시스템즈]](SUN Microsystems)에서는 "썬의 새로운 Sun SPARC 엔터프라이즈 서버들은 메인프레임 급의 안정성, 가용성 및 서비스 용이성(RAS: Reliability, Availabiltiy & Serviceability)과 업계 선도적인 가상화 기능을 제공한다"고 주장하고 있다. 썬 마이크로시스템즈의 SPARC 엔터프라이즈 제품 라인은 UltraSPARC T1/T2 프로세서 또는 SPARC64-VI 프로세서, 둘 중 하나에 기반하고 있다. 여기에는 인텔(Intel), AMD, SPARC64-V, UltraSPARC IIi, IIIi, IV, IV+ 등을 탑재하는 서버들은 포함되지 않는다. 썬 마이크로시스템즈의 가상화 기술은 크게 세 가지로 나누어 볼 수 있다. 그 하나는 동적 도메인으로서 완벽한 전기적 절연 환경을 제공하는 물리적 파티셔닝이다. 물리적 파티셔닝은 물리적 자원의 한계를 넘어설 수 없다는 의미에서 복잡하게 전개된 오늘날의 데이터 센터의 문제들을 해결하는 방안이 될 수 없다. 썬 마이크로시스템즈가 제공하는 또 다른 파티셔닝 기술은 논리적 도메인이다. 논리적 도메인에는 일종의 펌웨어인 하이퍼바이저가 관련되는데, 이에 따라 하나의 단일 서버를 복수 개의 보다 작은 규모의 서버들로 분할할 수 있는 기능을 제공하지만 자원의 공유에 있어서 제한적이고 전체적인 자원에 대한 하나의 유연한 시야를 제공하는 데 있어서 제약이 있고 보다 근본적으로는 로우엔드에서만 제공되는 기능이어서 가상화 본연의 임무에 충실할 수 없다. 복잡하게 전개된 단일 워크로드용 서버를 하나로 통합하여 데이터 센터의 효율성을 제고할 수 있게 하려는 가상화의 근본 취지에 전혀 부합하지 못하기 때문이다. 썬 마이크로시스템즈는 모든 하이엔드, 미드레인지 제품군에서 동적 도메인만을 지원한다. 그 외, 썬에서는 솔라리스(Solaris) 컨테이너를 가상화의 기능으로 주장하고 있지만 이는 하이퍼바이저에 기반한 기술이라기 보다는 운영 체제에 의존하는 가상화 기술이다. 이 기술로는 단일 운영 체제 안에서 특정 어플리케이션에 대하여 선별적으로 자원을 할당하거나 고립시킬 수 있다. 대개 시스템 수준에서의 가상화와 운영 체제 수준에서의 가상화를 묶어서 사용할 수 있다. | ||
===에이치피=== | ===에이치피=== | ||
− | [[에이치피]](HP) 또한 | + | [[에이치피]](HP) 또한 썬 마이크로시스템즈와 마찬가지로 크게 세 가지 종류의 파티셔닝 기술을 보유하고 있다. 그 하나는 썬의 동적 도메인과 유사한 물리적 파티셔닝 nPAR 기술이고, 다른 하나는 논리적 파티셔닝 기술인 vPAR이며 나머지 하나는 운영 체제 위에서 작성되는 IVM(Integrity Virtual Machine)이다. 에이치피의 nPAR는 하나의 대규모 서버를 보다 작은 규모의 가상 서버들로 분할하여 사용할 수 있도록 지원하는 하드웨어 기반의 파티셔닝 기술이다. nPAR 또한 썬의 동적 도메인과 크게 다르지 않아서 최소한 셀 보드 하나 단위 이하로는 구성이 불가능하다. nPAR 의 강조점은 데이터 센터의 유연한 구성을 지원하는 관리와 통제의 기능에 있지 않고 서버의 안정성이 불충분하여 시스템 장애가 발생하였을 때의 파티션의 안정성을 유지하기 위한 전기적 절연에 맞춰져 있다. IBM의 PowerVM과 비교해 보면 nPAR가 지니는 구성의 유연성이 상당히 제한적임을 쉽게 확인할 수 있다. 에이치피의 논리적 파티셔닝 기술은 vPAR라고 불리운다. 이 기술에 의하여 nPAR에 속한 물리적 자원들은 보다 나은 조밀도를 가지고 각 논리적 파티션에 할당될 수 있게 된다. vPAR는 nPAR와 마찬가지로 물리적 자원들을 가상 파티션에 할당 시킨다. 다만 nPAR와 비교하여 vPAR는 더 나은 조밀도를 가지는 대신 전기적 절연을 포기하였다고 볼 수 있다. 또한 vPAR는 IBM의 PowerVM과 같은 시분할 자원 공유 방식을 취하는 것이 아니라 nPAR와 마찬가지로 물리적 자원을 직접 파티션에 할당하기 때문에 프로세서 및 I/O 자원의 공유는 불가능하다. vPAR 기술로 시스템을 운영하는 중 자원을 재할당할 수 있으나 유연성의 측면에서는 다소 불충분할 수 있으므로 면밀하게 계획을 세워 파티션을 작성해야 한다. |
− | + | ===아이비엠=== | |
− | + | [[아이비엠]](IBM)은 서버 하드웨어를 제조하는 서버 가상화에 중요한 역할을 한다. IBM 플랫폼 시스템 P, 시스템 I 및 시스템 Z는 파라 가상 하이퍼바이저를 사용한다. 기본적으로 모든 게스트 가상 시스템은 호스트를 통해 서로 및 리소스 요구 사항을 알고 있다. 호스트 하드웨어 리소스는 분할되어 가상 컴퓨터(또는 논리 파티션)에 할당된다. IBM Z/VM은 이 파라 가상화 기술을 설립했으며 거의 모든 IBM 메인프레임 솔루션이 이 가상화 방법을 사용한다. 예를 들어 IBM 시스템 P는 HMC에서 관리하는 풀링된 가상화된 하드웨어 계층을 사용하여 논리 파티션에 리소스를 배포한다. 각 파티션은 다른 파티션의 요구 사항을 알고 있으며 각 서버에 정의된 최소 하드웨어가 있는지 확인하기 위해 리소스가 공유된다. IBM은 세계 컴퓨터 시장의 점유율을 대부분 차지하고 있으며 컴퓨터 외에도 사무기기들과 정보 처리 시스템을 제조한다.<ref> 이관용, 〈[http://www.comworld.co.kr/news/articleView.html?idxno=12534 유닉스 서버 가상화 어디까지 왔나]〉, 《컴퓨터월드》, 2008-03-31</ref> | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
{{각주}} | {{각주}} | ||
==참고자료== | ==참고자료== | ||
− | + | * 이관용, 〈[http://www.comworld.co.kr/news/articleView.html?idxno=12534 유닉스 서버 가상화 어디까지 왔나]〉, 《컴퓨터월드》, 2008-03-31 | |
+ | * 주창오, 〈[https://itxcloud.tistory.com/entry/%EA%B0%80%EC%83%81%ED%99%94Virtualization-%EC%B4%9D%EC%A0%95%EB%A6%AC-1-%EC%84%9C%EB%B2%84-%EA%B0%80%EC%83%81%ED%99%94%EA%B0%80-%ED%95%84%EC%9A%94%ED%95%9C-%EC%9D%B4%EC%9C%A0 가상화(Virtualization) 총정리 - 서버 가상화가 필요한 이유]〉, 《티스토리》, 2012-05-21 | ||
+ | * Neal Weinberg , 〈[http://www.itworld.co.kr/news/110031 서버 가상화의 미래 : 컨테이너 및 서버리스 비교 진단]〉, 《아이티월드》, 2018-07-13 | ||
+ | * Lucas 팬도라, 〈[https://judo0179.tistory.com/36 IT 인프라 6편 가상화]〉, 《티스토리》, 2018-10-19 | ||
+ | * 안성원, 〈[https://spri.kr/files/1544421791_k7LnlkLc9mgJgots3jU7H3BR_0.pdf 클라우드 가상화 기술의 변화 - 컨테이너 기반의 클라우드 가상화와 DevOps]〉, 《소프트웨어정책연구소》, 2018-12-10 | ||
+ | * 전동운, 〈[http://w3.kirs.or.kr/download/tech/2019-143.%EB%82%98%EB%AC%B4%EA%B8%B0%EC%88%A0_%EA%B8%B0%EC%88%A0%EB%B6%84%EC%84%9D%EB%B3%B4%EA%B3%A0%EC%84%9C.pdf 기술분석보고서]〉, 《NICE평가정보(주)》, 2019-03-14 | ||
+ | * 이광재, 〈[http://www.efnews.co.kr/news/articleView.html?idxno=82546 (2020 전망) 엔터프라이즈가 주목해야 할 기술…SW 인프라 구축 필요성 확대]〉, 《파이낸셜신문》, 2019-12-26 | ||
+ | * 서버 가상화 한국정보통신기술협회 - http://terms.tta.or.kr/dictionary/dictionaryView.do?word_seq=055358-1 | ||
+ | * What is Server Virtualization? 아틀란틱넷 - https://www.atlantic.net/what-is-server-virtualization/ | ||
+ | * 서버 가상화 작동 방식 하우스터프웍스 - https://computer.howstuffworks.com/server-virtualization.htm | ||
+ | * 서버 가상화 기술의 진화: VM과 컨테이너 가비아 라이브러리 - http://library.gabia.com/contents/infrahosting/7426 | ||
+ | * 가상화: 패턴의 관점에서 본 가상화 한국데이터산업진흥원 - https://kdata.or.kr/info/info_04_view.html?field=&keyword=&type=techreport&page=260&dbnum=127235&mode=detail&type=techreport | ||
+ | * 가상화/컨테이너 중소벤처기업부 - http://smroadmap.smtech.go.kr/0201/view/m_code/A010/id/1883/idx/1886 | ||
==같이 보기== | ==같이 보기== |
2020년 8월 19일 (수) 14:27 기준 최신판
서버 가상화(server virtualization)는 하나의 물리적 서버 호스트에서 여러 개의 서버 운영 체제를 게스트로 실행할 수 있게 해주는 소프트웨어 아키텍처다. 서버는 물리적 시스템으로부터 추상화된 서버 소프트웨어를 통해 물리적 영역을 벗어난 하나의 가상 시스템이 된다.
목차
개요[편집]
서버 가상화는 CPU, 메모리, 입출력 등 단일 플랫폼 상의 서버 자원을 사용자가 여러 도메인이나 서버 애플리케이션으로 분할해 사용할 수 있는 기술이다. 즉 가상 플랫폼에서 모든 운영 체제의 가상 인스턴스를 생성할 수 있는 기술을 말한다. 운영 체제를 호스팅하기 위해 CPU, 디스크, 메모리 및 기타 연결된 하드웨어가 있는 서버인 물리적 플랫폼이 필요했다. 서버 가상화는 물리적으로 한대의 시스템 상에서 윈도우나 리눅스 등 각기 다른 운영체제의 다양한 서버 애플리케이션을 효율적으로 운영할 수 있어 비용 절감 및 서버 자원의 효율적인 활용이 가능하다. 서버 가상화는 자바 가상머신처럼 현재의 운영체제 위에 가상머신을 만들어 마치 컴퓨터가 여러대 있는 것처럼 시스템을 구축하여 동시에 운영하는 방식과 하드웨어를 파티션으로 나누어 각기 다른 운영체계를 얹는 방식이다. 그리고 다중 운영체계와 하드웨어 사이에 가상화의 계층을 두는 방식 등 여러 가지가 있다.[1] 일반적인 서버 가상화에서 많은 가상 시스템이 물리적 서버에 연결되며 하이퍼바이저(Hypervisor)는 호스트 하드웨어를 각 개별 가상 컴퓨터와 공유하는 데 사용된다. 서버 가상화는 과거에는 가능하지 않았던 수준으로 효율적인 IT 리소스의 사용을 지원한다. 서버 가상화가 등장하기 전에는 하나의 데이터센터에 너무 많이 사용되는 하드웨어와 많이 사용되지 않는 하드웨어가 동시에 존재하는 경우가 많았다. 그러나 가상화 등장 후 여러 가상 시스템에서 부하에 따라 워크로드를 이동할 수 있게 되었으며, 하나의 물리적 서버에서 여러 개의 서버 운영체제와 구성을 실행할 수 있게 되어 효율성이 향상되었다. 따라서 서버 가상화를 통해 리소스를 다른 많은 가상 컴퓨터와 공유할 수 있으므로 조직은 데이터 센터 하드웨어 사용 공간 및 방대한 양의 물리적 하드웨어를 실행하는 데 드는 관련 비용을 크게 줄일 수 있다. 한편 서버 가상화는 클라우드 컴퓨팅과 하이브리드 IT의 근간이 된다.
역사[편집]
서버당 운영체제 인스턴스 하나와 애플리케이션 하나를 실행하는 대신 여러 운영체제 인스턴스 및 관련 워크로드를 하나의 실제 서버에서 실행할 수 있게 해주는 소프트웨어 계층, 즉 하이퍼바이저를 추가할 수 있다는 생각이 서버 가상화의 기원이며 그 유래는 1960년대 IBM 메인프레임 시대까지 거슬러 올라간다. 서버 가상화가 보편화된 것은 2000년대 초반 VM웨어가 x86 서버를 위한 가상화 소프트웨어를 출시하면서부터다. 이후 다른 여러 업체에서도 자체 서버 가상화 플랫폼을 개발했고 업계 전반적으로 가상머신(Virtual Machine) 워크로드의 배포, 이동, 관리를 쉽게 해주는 고급 관리, 자동화 및 오케스트레이션 툴이 탄생했다. 서버 가상화 이전, 기업은 무질서한 서버 증설과 제대로 활용되지 못하는 컴퓨팅 성능, 치솟는 전력 요금에 시달렸으며, 데이터센터 환경에는 수동 프로세스와 전반적인 비효율성, 경직성이 만연했다. 서버 가상화는 이러한 모든 상황을 바꿔 놓았고 광범위하게 도입됐다. 사실 오늘날 대부분의 워크로드를 VM 환경에서 실행하지 않는 기업을 찾기 어려울 정도다. 그러나 모두가 알다시피 그 다음 큰 물결에 밀려나지 않는 기술이란 없다. 서버 가상화의 경우 다음 큰 물결은 소형화다. 서버 가상화는 실제 디바이스를 가상으로 잘게 나눠서 여러 운영체제와 여러 애플리케이션이 기반 컴퓨팅 파워를 끌어 쓸 수 있도록 한다. 컴퓨팅의 다음 변화는 애플리케이션을 가벼운 컨테이너에서 실행되는 더 작은 마이크로서비스로 나누는 것, 그리고 아직 실험 중이지만 서버리스 컴퓨팅이다. 두 가지 시나리오 모두 VM을 완전히 생략하고 베어 메탈에서 코드를 실행한다.[2]
특징[편집]
필요성[편집]
서버 가상화에 대한 투자가 이루어지는 데는 많은 이유가 있다. 일부는 비용 절감의 일환으로 진행되는가 하면, 순수하게 기술적인 이유로 진행되는 경우도 있다. 서버 가상화는 통합을 통하여 공간을 줄일 수 있다. 하나의 서버는 하나의 애플리케이션을 구동하는 형태가 일반적인데, 상당수의 애플리케이션들은 적은 양의 처리능력만을 사용한다. 따라서 네트워크 관리자는 이러한 서버들을 하나의 서버로 통합하여, 다수의 가상 환경을 구동시킴으로써, 물리 서버 및 공간을 절감할 수 있다. 수백 또는 수천 대의 서버를 운영하는 기업에게 있어서 가상화의 적용을 통해 물리적 공간을 현저히 줄일 수 있다. 서버 가상화는 추가적인 물리 서버 구매 없이도 리던던시(Redundancy)를 확보할 수 있게 한다. 리던던시는 여러 개의 하드웨어에 동일한 애플리케이션을 구동함으로써, 하나의 서버가 오동작을 하더라도 다른 서버에서 동일 애플리케이션을 구동하므로 중요한 안전장치가 된다. 이러한 리던던시는 서비스 중단을 최소화한다. 하나의 애플리케이션을 구동하는 두 개의 가상서버가 하나의 물리 서버에 구축되는 경우, 물리 서버의 다운은 가상 서버의 즉각적인 중단을 유발하므로, 대부분의 네트워크 관리자들은 리던던시 가상 서버를 다른 물리 서버에 구축하는 것이 일반적이다. 가상 서버는 프로그래머의 독립성을 보장해준다. 즉 독립된 시스템에서 신규 애플리케이션을 테스트하거나 운영할 수 있도록 한다. 네트워크 관리자는 전용 물리 서버를 구매하지 않고도 신규 가상 서버를 즉시 생성하여 할당할 수 있다. 서버 하드웨어가 노후화되는 경우, 하나의 시스템에서 다른 시스템으로 전환하는 것은 매우 어려운 작업일 수 있다. 노후화 된 시스템(종종 레가시 시스템으로 부른다)에서 제공되는 서비스의 연속성을 위해, 네트워크 관리자는 최신 물리 서버에 가상 서버를 생성할 수 있다. 애플리케이션 운영상 볼 때 바뀌는 것은 없으며, 프로그램은 마치 과거의 하드웨어에서 구동되는 것처럼 운영된다. 이는 새로운 프로세스로의 전환 시, 하드웨어 오동작에 대한 우려를 덜어주며, 특히 레가시 하드웨어 공급업체가 없어져서 더 이상의 유지보수가 불가능한 경우에는 더욱 유효하다.<ref="굿">ITX's Cloud, 〈가상화(Virtualization) 총정리 (2) - 서버 가상화(Server Virtualization)란 무엇인가?〉, 《티스토리》, 2012-05-22</ref>
한계[편집]
서버 가상화가 주는 혜택은 너무도 매력적이어서, 모든 기술에는 한계가 있다는 사실을 종종 잊어버리게 한다. 서버 가상화는 도입 전 반드시 자체 네트워크 아키텍처와 필요 사항, 도입 예정인 서버 가상화 기술을 면밀히 검토하여야 한다. CPU 점유율이 높은 애플리케이션의 전용 서버에 있어서 가상화는 큰 도움이 되지 않을 수도 있다. 가상화는 본질적으로 물리 서버의 처리능력을 여러 개의 가상 서버에 나누어 사용하기 때문에, 애플리케이션의 요구환경에 미달할 경우, 문제가 발생할 수 있다. 최악의 경우 서버의 처리능력을 넘어서게 되면, 시스템이 다운될 가능성도 있다. 따라서 네트워크 관리자는 사전에 CPU 사용량을 자세히 검토해야 한다. 하나의 물리 서버에 지나치게 많은 가상 서버들을 생성하여 서버의 CPU에 과부하를 일으키는 것은 그다지 현명한 일이 아니다. 하나의 물리 서버에서 구동하는 가상 서버가 많아지면 많아질수록, 각각의 가상 서버가 사용할 수 있는 처리 능력은 줄어들게 되며, 물리 서버의 디스크 사용량 또한 동일한 문제를 일으킬 수 있다. 또 다른 문제는 마이그레이션인데, 현재는 하나의 물리 서버에서 구동되는 가상 서버를 마이그레이션할 수 있는 전제조건은 동일한 제조사의 프로세서를 사용해야 한다는 것이다. 만일 동일한 네트워크 상에 있는 인텔 프로세서를 사용하는 서버에서 AMP 프로세서를 사용하는 서버로 가상 서버를 포팅하고자 한다면, 이는 불가능하다. 가상 서버의 마이그레이션이 왜 필요한 이유는 만일 하나의 물리 서버에 대한 유지보수가 필요할 경우, 다른 물리 서버로 가상 서버를 포팅하는 것이 애플리케이션 다운타임을 최소화 할 수 있기 때문이다. 마이그레이션은 선택사항이 아니다. 하나의 물리서버에서 구동되는 가상 서버의 모든 애플리케이션들은, 유지보수 시에는 서비스가 불가하게 될 것이다. 이러한 제약사항에도 불구하고 많은 기업들은 서버 가상화에 대한 투자를 지속하고 있다. 서버 가상화 기술이 발전하게 되면, 대규모 데이터센터가 필요하지 않는 상황이 발생할 수도 있다. 서버의 전력 소비량과 열 발생량 또한 감소하게 되면, 자원 활용에 대한 효율성 뿐만 아니라, 그린 IT에 대한 니즈 또한 충족시킬 수 있다.<ref="굿"></ref>
종류[편집]
전가상화[편집]
전가상화(Full Virtualization)는 하이퍼바이저라는 특수한 소프트웨어를 사용한다. 하이퍼바이저는 물리 서버의 CPU와 디스크에 직접 상호작용을 하며, 가상 서버의 운영체제를 위한 플랫폼 역할을 한다. 즉 운영체제 위에 하이퍼바이저가 설치되고, 그 위에서 가상 서버 및 운영체제가 실행되는 방식이다. 하이퍼바이저는 각각의 가상 서버들을 완전히 독립적으로 운용하도록 한다. 각각의 게스트 서버는 자체 운영체제에서 운영되기 때문에, 리눅스 기반 게스트와 윈도우 기반 게스트를 동시에 운용할 수도 있다. 하이퍼바이저는 물리 서버의 자원을 모니터링하여, 가상 서버에서 애플리케이션이 구동될 때, 물리 서버의 자원을 적절한 가상 서버에 할당해 준다. 물론 하이퍼바이저 자체 구동을 위해서도 처리능력 등의 리소스를 필요로 하기 때문에, 하이퍼바이저의 리소스 사용량은 전체 서버 퍼포먼스와 애플리케이션 구동속도에 영향을 줄 수 있다. 전가상화는 컴퓨팅 시스템의 하드웨어 리소스를 완전하게 가상화 하는 방식으로 그 위에서 동작하게 될 게스트 운영체제의 수정 없이 구동이 가능하다. 마이크로소프트 윈도우에서 리눅스 까지 다양한 운영체제를 사용할 수 있기 때문에 적용이 쉬운 편이다. 컴퓨팅환경을 기존의 운영체제 위에서 에뮬레이션 하는 형식으로 지원하기에 호스트(Host)형 가상화 라고도 한다. 다만 CPU의 가상화 지원 기술(VT, Virtualization Technology)과 같은 하드웨어 기능을 일부 지원받기 때문에 모든 기능을 소프트웨어적으로 구동하는 에뮬레이션과는 차이가 있다. 하이퍼바이저를 직접 실행하기에 편리한 인터페이스 화면을 제공하지만, 반면 이에 따른 성능 감소가 생긴다는 단점이 있다.
반가상화[편집]
반가상화(Para-Virtualization)는 전가상화와는 달리, 게스트 서버 간의 독립성 없이 상호작용한다. 물리 서버 위에 하이퍼바이저가 직접 설치되고, 그 위에서 가상 서버 및 운영체제가 실행되는 방식이다. 반가상화 하이퍼바이저는 게스트 운영체제를 관리하기 위해 필요한 자원(처리능력)이 상대적으로 적게 든다. 이는 각각의 운영체제가 동일한 물리 서버에서 운영되는 다른 운영체제에서 필요로 하는 자원을 이미 인지하고 있으며, 이들 시스템은 마치 하나처럼 동작하게 된다. 반가상화는 하드웨어를 완전히 가상화하지 않는 방식이다. 하이퍼바이저가 하드웨어 위에서 직접 실행되기 때문에 네이티브(Native, Bare-metal) 가상화 라고도 한다. 물리 서버의 성능을 최대한 발휘하면서 가상 서버의 성능을 제공하기에 성능이 많이 감소되지 않으면서 가상 서버를 제공하지만, 물리 서버 바로 위에 설치된 하이퍼바이저를 직접적으로 관리하기에는 어려움이 있다. 반가상화는 하드웨어에 대한 제어권을 하이퍼바이저가 가지고 있기 때문에, 하드웨어와의 I/O 처리에 있어서 전가상화보다 직접적인 루틴을 사용한다.
운영체제 수준 가상화[편집]
운영체제 수준 가상화(operating-system-level virtualization)는 OS레벨 가상화라고도 하며 운영체제의 중앙 태스크 관리자인 커널에서 이루어진다. 이렇게 하면 리눅스 환경과 윈도우 환경을 함께 실행할 수 있다. 또한 기업은 가상 운영 체제를 컴퓨터에 푸시해 여러가지 이점을 얻을 수 있다. 컴퓨터에 고도의 OOTB(Out Of The Box) 기능이 필요하지 않으므로 하드웨어에 많은 비용이 소모되지 않는다. 모든 가상 인스턴스를 모니터링하고 격리할 수 있으므로 보안이 강화된다. 소프트웨어 업데이트와 같은 IT 서비스에 소요되는 시간이 절약된다. 운영 체제 수준 가상화는 커널이 여러 개의 격리된 사용자 공간 인스턴스의 존재를 허용하는 운영 체제 패러다임을 말한다. 컨테이너(LXC, 솔라리스 컨테이너, 도커), 솔라리스 컨테이너 영역, 가상 개인 서버(오픈VZ), 파티션, 가상 환경(VEs), 가상 커널(드래곤 플라이 BSD) 또는 감옥(FreeBSD 감옥 또는 chroot 감옥) 등 이것을 실행 하는 프로그램의 관점에서 실제 컴퓨터 처럼 보일 수 있다. 일반 운영체제에서 실행되는 컴퓨터 프로그램은 해당 컴퓨터의 모든 리소스를 볼 수 있다. 그러나 컨테이너 내부에서 실행되는 프로그램은 컨테이너에 할당된 컨테이너의 내용 및 장치만 볼 수 있다. 유닉스와 같은 운영 체제에서 이 기능은 표준 chroot 메커니즘의 고급 구현으로 볼 수 있으며, 이는 현재 실행 중인 프로세스및 해당 하위에 대한 명백한 루트 폴더를 변경한다. 커널은 격리 메커니즘 외에도 한 컨테이너 활동이 다른 컨테이너에 미치는 영향을 제한하는 리소스 관리 기능을 제공하는 경우가 많다.[3]
기능[편집]
서버 가상화는 관리 면에서 장점이 많다. 서버 가상화는 한 대의 서버를 많은 서버로 분할하여 이용하는 기술로, 가상화 소프트웨어를 사용하여 하드웨어(CPU나 메모리, 스토리지 드라이브 등)를 논리적으로 분할하여 운영체제에 할당함으로써 서버의 분할을 구현한다. 서버 가상화로 만든 서버를 가상머신 또는 가상서버라고 한다. 서버 가상화는 물리적으로 몇 개의 서버를 한 대로 집약하여 설치 공간을 줄이거나 스케줄링(scheduling), 라이브 마이그레이션(live migration), 결함 포용(fault tolerance) 기능을 사용하여 다른 서버로 가상머신을 이동시킬 수 있는 등 시스템 관리자에게 있어서 큰 장점을 갖고 있어 폭발적으로 보급되었다. 그중 서버 가상화의 주요 기능은 라이브 마이그레이션이다.
라이브 마이그레이션[편집]
라이브 마이그레이션(Live Migration)은 1대의 서버에서 동작 중인 애플리케이션을 다른 서버로 이동해서 동작을 계속하도록 하는 것을 말한다. 공통 메모리가 아니라 다른 서버로 이동할 경우는 가상 프로세서의 상태를 이동하면서 동시에 원래의 가상 프로세서가 사용하고 있던 명령이나 데이터 메모리를 이동해갈 프로세서의 메모리로 카피해서, 애플리케이션 프로그램에서 볼 때 동일한 어드레스가 되도록 페이지 테이블을 구축할 필요가 있다. 그러고 나서 애플리케이션이 사용하고 있던 파일이나 LAN 등으로의 액세스도 넘겨줄 필요가 있다. 라이브 마이그레이션이 가능하다면 부하가 높은 서버에서 부하가 낮은 서버로 처리를 옮겨서 부하를 평준화하거나, IDC 전체의 부하가 낮은 경우에는 소수의 서버로 처리를 집중시켜 남은 서버의 전원을 오프해서 에너지 사용을 줄이는 것과 같은 사용법이 가능하다.
종류[편집]
호스트[편집]
호스트형 서버 가상화는 교육이나 실습 환경으로도 많이 사용하는 환경으로, 흔히 사용하는 운영체제 위에 가상화 프로그램을 설치해 거기에 가상머신을 띄워 원하는 운영체제를 설치하는 기술이다.[4] 하이퍼바이저 또는 가상머신 모니터라고 하는 소프트웨어가 호스트 운영체제 위에 설치되며, 이를 통해 사용자들은 애플리케이션 윈도우 내에서 다양한 게스트 운영체제를 실행할 수 있다. 호스트형 가상화는 물리 컴퓨터의 하드웨어를 에뮬레이트 하기 때문에 오버헤드는 크지만, 게스트 운영체제 종류에 대한 제약이 없어서 거의 대부분의 운영체제에서 동작시킬 수 있다. 호스트형 가상화의 장점으로는 사용자가 호스트 운영체제를 수정하지 않고도 가상머신 아키텍처를 설치할 수 있다는 것이다. 가상화 소프트웨어는 호스트 운영체제에 의존하여 장치 드라이버 및 기타 저수준 서비스를 제공할 수 있다. 이로 인하여 가상머신의 설계가 간소화되고 배포도 쉬워진다. 호스트형 가상화의 단점으로는 성능이 하이퍼바이저나 가상머신 모니터를 사용하는 가상화에 비해 낮을 수 있다. 예를 들면 응용 프로그램에서 하드웨어 액세스를 요청하면 4개의 매핑 계층을 통과해야 하기 때문에 성능이 크게 저하된다. 브이엠웨어(VMware)의 워크스테이션(Workstation), 서버(Server), 플레이어(Player), 마이크로소프트(MS)의 가상서버(Virtual Sever), 가상PC(Virtual PC), 가상박스(Virtual Box), 패러렐 워크스테이션(Paralles Workstation) 등이 있다.[5]
하이퍼바이저[편집]
하이퍼바이저(Hypervisor)는 서버 가상화를 실현하는 플랫폼이다. 가상화 머신 모니터 또는 가상화 머신 매니저라고도 부르며 여러 개의 가상머신이 한정된 하드웨어 자원을 나눠 쓸 수 있도록 한다. 운영체제와 합쳐진 형태와 분리된 형태로 나뉜다. 전가상화 반가상화라고 부르는 이러한 방법은 하이퍼바이저의 역할 범위에 따라 구분한 것으로 전가상화는 하이퍼바이저가 호스트 운영체제에서 모든 일을 처리하는 것이며, 반가상화는 일부 역할을 가상머신의 도움을 받아서 처리하는 개념이다. 하이퍼바이저는 크게 TYPE1과 TYPE2 2가지 방식으로 구분된다. TYPE1 방식은 물리 서버 위에 하이퍼바이저가 직접 설치되고, 그 위에서 가상 서버 및 운영체제가 실행되는 방식이고, TYPE2 방식은 운영체제 위에 하이퍼바이저가 설치되고, 그 위에서 가상 서버 및 운영체제가 실행되는 방식이다. TYPE1 하이퍼바이저는 네이티브(Native) 또는 베어메탈(Bare-metal) 방식의 하이퍼바이저라고도 하며, 하드웨어 계층 바로 위에서 하이퍼바이저가 동작하여 가상 서버를 제공한다. 물리 서버의 성능을 최대한 발휘하면서 가상 서버의 성능을 제공하기에, 성능이 많이 감소되지 않으면서 가상 서버를 제공하지만, 물리 서버 바로 위에 설치된 하이퍼바이저를 직접적으로 관리하기에는 어려움이 있다.
반면, TYPE2 하이퍼바이저는 Hosted 하이퍼바이저라고도 하며, 기존 물리 서버에 설치된 운영체제 위에 하이퍼바이저가 설치되어 동작하므로, 하나의 물리 서버 위에 여러 종류의 하이퍼바이저를 실행할 수 있다. 또한, 하이퍼바이저를 직접 실행하기에 편리한 인터페이스 화면을 제공하지만, 반면 이에 따른 성능 감소가 생긴다는 단점이 있다. 실제로 TYPE1 하이퍼바이저는 성능에 대한 이점이 있어 서버 인프라 환경을 구성할 때 많이 사용한다. 단, 하이퍼바이저를 관리하기 위해 별도의 관리용 네트워크 망을 구성하여 특정 컴퓨터에서 하이퍼바이저에 접속하여 관리하는 형태로 사용한다. 반면, TYPE2 하이퍼바이저는 주로 가정용 컴퓨터 또는 운영체제가 이미 설치된 컴퓨터에서 여러 운영체제를 설치하여 테스트하는 목적으로 사용 가능하다.[6]
컨테이너[편집]
컨테이너(container)는 가상머신이 없으며 게스트 OS도 없다. 호스트 OS입장에서 보면 컨테이너는 하나의 프로세스로 기동하기 때문에 하드웨어를 초기화 하는 작업이 필요하지 않다. 따라서 가상 환경을 실행하고 종료하는데 시간이 매우 빠르며, 오버헤드도 거의 존재하지 않는다. 다른 가상화 환경 제공방식과 동일하게 프로세스를 수행하는 독립적인 공간을 제공하여, 보안적인 측면도 우수하며, 밀도 높은 설계가 가능하고 하드웨어 자원 수준이 낮다는 장점이 있다. 단, 호스트 OS인 리눅스 이외의 다른 OS에서는 동작하지 않으며, 리눅스 계열이 아닌 다른 OS를 설치할 수 없다. 이론적으로는 컨테이너의 리눅스의 모든 배포판을 설치하는 것이 가능하지만, 해당 라이브러리를 사용하는 것일 뿐, 리눅스 커널에서 실행되기 때문에 태생적인 한계도 가지고 있다. 또한 PaaS와 밀접한 이유는 독립적인 애플리케이션 수행 환경을 서비스 형태로 제공하는데 있어서 핵심 기능을 제공하고, 오버헤드가 가장 적기 때문에 가장 많이 사용되고 있는 추세다. 기업에서 사용할 때 고려해야 하는 점은 컨테이너들이 하드웨어의 리소스를 공유할 수 밖에 없기 때문에 발생하는 자원경합을 해결하는 것이 가장 중요한 과제다. 자원 경합 방지 기술 중에서 인텔 아이태니엄에만 포함되어 있다가 x86 CPU 중에서 인텔 하스웰 E7 CPU에 처음 탑재된 기능으로 TSX(Transactional Synchronoud eXtension) 기능이 있다.
이 기술은 여러 번의 연산을 컨텍스트 스위칭 없이 한 번에 처리해 준다. 컨텍스트 스위칭은 CPU 위에서 실행 중인 프로세스가 대기 중인 프로세스에게 양보하기 위해, 종료되지 않은 상태로 레지스터에 있던 데이터를 램(RAM)으로 저장하고 대기 중이던 프로세스의 데이터를 레지스터로 복사하는 작업을 말한다. 컨테이너라는 개념이 처음 등장한 것은 2000년대 중반부터 리눅스에 내장된 LXC(LinuX Container)기술로 소개되면서부터이다. 컨테이너 기술이 등장하게 된 계기는 개발한 프로그램이 구동환경의 달라짐에 따라 예상하지 못한 각종 오류를 발생시키는 것을 해결하기 위함이었다. 이런 오류가 발생하는 이유는 구동 환경마다 네트워크, 스토리지, 보안 등의 정책이 각각 다를 수 있기 때문이다. 결국 SW를 하나의 컴퓨팅 환경에서 다른 컴퓨팅 환경으로 이동하더라도 안정적으로 실행하는 방법을 모색하여 나온 방법이 바로 컨테이너이다.[7]
할당 방법[편집]
가상 시스템을 구축하기 위해서는 물리 서버로 시스템을 구성할 때와 거의 유사한 패턴으로 진행하게 된다. 먼저, 시스템에서 수행될 애플리케이션의 워크로드 패턴을 분석해야 하며 이후 비기능 요구사항(NFR) 수집과 시스템 용량 분석을 진행하고, 논리 설계와 물리 설계를 진행한다. 워크로드 패턴이란 시스템에서 애플리케이션을 수행하는 동안 소모하는 인프라 자원에 대한 사용 형태 및 사용량을 말한다. 그리고 비기능 요구사항(Non-Fuctional Requirement, NFR)은 비즈니스 또는 업무 기능과 무관한 시스템 자체에 대한 조건을 말한다. 또한 오버커밋(overcommit)은 물리적인 용량 한계를 넘어서 할당하는 개념으로, 오버커밋 비율이 높으면 자원경합에 의한 성능 지연 현상이 발생한다.
CPU[편집]
베어메탈 서버로 TA(Technical Architecture)를 설계할 때, 서버 가상화 기술로 설계할 경우 호스트 서버 한 대에 게스트 OS를 분리하여 애플리케이션 별로 최대한 고립시켜 주는 것이 유리하다. 이는 분리된 애플리케이션들은 각각의 게스트 OS 내에서 인프라 자원을 할당 받기 위한 경합을 회피할 수 있으며, OS를 각 애플리케이션에 맞도록 최적화하여 운영할 수 있기 때문이다. 가상 시스템별로 CPU를 할당해야 하는 경우 애플리케이션의 다중 스레드를 요구하는지 단일 스레드를 요구하는지 확인해야 한다. 이러한 활동을 워크로드 분석이라고 하며, 이렇게 조사한 결과를 기준으로 CPU 자원을 할당해야 한다.
메모리[편집]
메모리도 CPU 처럼 오버커밋이 있으나 메모리는 공간을 차지하는 개념이기 때문에 먼저 메모리 공간을 차지한 가상머신이 메모리를 해제하거나 재기동 하기 전에는 메모리 공간을 차지한 가상머신이 메모리를 할당 받지 못하고 기다리는 현상이 발생함으로 보수적으로 처리해야 한다. 따라서 메모리는 오버커밋하여 사용하지 않는다. 메모리가 부족하면 스왑(SWAP)이 발생하고, 메모리가 부족한 모든 가상머신에 성능 하락이 발생하게 된다. 서버 가상화 기술이 발전하면서 물리 메모리의 한계를 넘어서기 위한 기술도 존재한다. 씬 프로비저닝은 가상머신에서 실제로 메모리를 사용할 때 물리 메모리를 조금씩 할당해 주는 방식으로 메모리 사용률에서는 효율적이지만 메모리 단편화가 발생하는 단점이 있다. 메모리 오버커밋 상태에서 게스트 OS 메모리 사용량이 하이퍼바이저 메모리 크기를 초과하면 하이퍼바이저 디스크를 사용하며, 게스트 OS의 메모리 사용량이 줄어들면 하이퍼바이저 디스크에 저장된 데이터를 하이퍼바이저 메모리로 이동하는 기술이다. 이외에도 COW(Copy on Write)와 같이 가상머신을 복제하여 사용하는 경우 메모리를 동일하게 복제하면 2배의 메모리 공간이 필요함으로, 복제하지 않고 2개의 가상머신이 동일한 메모리 영역을 참조하다가 데이터가 변경되는 시점에서 새로운 메모리를 할당하는 방법이 있다. 또한 압축 캐시라고 하여 가상머신에서 메모리를 사용할 때 가상머신과 물리 메모리 사이에 별도의 캐시 메모리를 두고, 그 캐시에 데이터를 임시 저장 후 압축해서 실제 물리 메모리에 저장하는 기능이다. 벌룬 드라이버보다는 빠르다는 장점이 있으나 데이터의 형태에 따라서 압축률이 다르고, 데이터를 압축 및 해제하기 위해서 지속적으로 CPU 연산이 필요하다는 단점이 있다.[8]
주요 기업[편집]
썬 마이크로시스템즈[편집]
썬 마이크로시스템즈(SUN Microsystems)에서는 "썬의 새로운 Sun SPARC 엔터프라이즈 서버들은 메인프레임 급의 안정성, 가용성 및 서비스 용이성(RAS: Reliability, Availabiltiy & Serviceability)과 업계 선도적인 가상화 기능을 제공한다"고 주장하고 있다. 썬 마이크로시스템즈의 SPARC 엔터프라이즈 제품 라인은 UltraSPARC T1/T2 프로세서 또는 SPARC64-VI 프로세서, 둘 중 하나에 기반하고 있다. 여기에는 인텔(Intel), AMD, SPARC64-V, UltraSPARC IIi, IIIi, IV, IV+ 등을 탑재하는 서버들은 포함되지 않는다. 썬 마이크로시스템즈의 가상화 기술은 크게 세 가지로 나누어 볼 수 있다. 그 하나는 동적 도메인으로서 완벽한 전기적 절연 환경을 제공하는 물리적 파티셔닝이다. 물리적 파티셔닝은 물리적 자원의 한계를 넘어설 수 없다는 의미에서 복잡하게 전개된 오늘날의 데이터 센터의 문제들을 해결하는 방안이 될 수 없다. 썬 마이크로시스템즈가 제공하는 또 다른 파티셔닝 기술은 논리적 도메인이다. 논리적 도메인에는 일종의 펌웨어인 하이퍼바이저가 관련되는데, 이에 따라 하나의 단일 서버를 복수 개의 보다 작은 규모의 서버들로 분할할 수 있는 기능을 제공하지만 자원의 공유에 있어서 제한적이고 전체적인 자원에 대한 하나의 유연한 시야를 제공하는 데 있어서 제약이 있고 보다 근본적으로는 로우엔드에서만 제공되는 기능이어서 가상화 본연의 임무에 충실할 수 없다. 복잡하게 전개된 단일 워크로드용 서버를 하나로 통합하여 데이터 센터의 효율성을 제고할 수 있게 하려는 가상화의 근본 취지에 전혀 부합하지 못하기 때문이다. 썬 마이크로시스템즈는 모든 하이엔드, 미드레인지 제품군에서 동적 도메인만을 지원한다. 그 외, 썬에서는 솔라리스(Solaris) 컨테이너를 가상화의 기능으로 주장하고 있지만 이는 하이퍼바이저에 기반한 기술이라기 보다는 운영 체제에 의존하는 가상화 기술이다. 이 기술로는 단일 운영 체제 안에서 특정 어플리케이션에 대하여 선별적으로 자원을 할당하거나 고립시킬 수 있다. 대개 시스템 수준에서의 가상화와 운영 체제 수준에서의 가상화를 묶어서 사용할 수 있다.
에이치피[편집]
에이치피(HP) 또한 썬 마이크로시스템즈와 마찬가지로 크게 세 가지 종류의 파티셔닝 기술을 보유하고 있다. 그 하나는 썬의 동적 도메인과 유사한 물리적 파티셔닝 nPAR 기술이고, 다른 하나는 논리적 파티셔닝 기술인 vPAR이며 나머지 하나는 운영 체제 위에서 작성되는 IVM(Integrity Virtual Machine)이다. 에이치피의 nPAR는 하나의 대규모 서버를 보다 작은 규모의 가상 서버들로 분할하여 사용할 수 있도록 지원하는 하드웨어 기반의 파티셔닝 기술이다. nPAR 또한 썬의 동적 도메인과 크게 다르지 않아서 최소한 셀 보드 하나 단위 이하로는 구성이 불가능하다. nPAR 의 강조점은 데이터 센터의 유연한 구성을 지원하는 관리와 통제의 기능에 있지 않고 서버의 안정성이 불충분하여 시스템 장애가 발생하였을 때의 파티션의 안정성을 유지하기 위한 전기적 절연에 맞춰져 있다. IBM의 PowerVM과 비교해 보면 nPAR가 지니는 구성의 유연성이 상당히 제한적임을 쉽게 확인할 수 있다. 에이치피의 논리적 파티셔닝 기술은 vPAR라고 불리운다. 이 기술에 의하여 nPAR에 속한 물리적 자원들은 보다 나은 조밀도를 가지고 각 논리적 파티션에 할당될 수 있게 된다. vPAR는 nPAR와 마찬가지로 물리적 자원들을 가상 파티션에 할당 시킨다. 다만 nPAR와 비교하여 vPAR는 더 나은 조밀도를 가지는 대신 전기적 절연을 포기하였다고 볼 수 있다. 또한 vPAR는 IBM의 PowerVM과 같은 시분할 자원 공유 방식을 취하는 것이 아니라 nPAR와 마찬가지로 물리적 자원을 직접 파티션에 할당하기 때문에 프로세서 및 I/O 자원의 공유는 불가능하다. vPAR 기술로 시스템을 운영하는 중 자원을 재할당할 수 있으나 유연성의 측면에서는 다소 불충분할 수 있으므로 면밀하게 계획을 세워 파티션을 작성해야 한다.
아이비엠[편집]
아이비엠(IBM)은 서버 하드웨어를 제조하는 서버 가상화에 중요한 역할을 한다. IBM 플랫폼 시스템 P, 시스템 I 및 시스템 Z는 파라 가상 하이퍼바이저를 사용한다. 기본적으로 모든 게스트 가상 시스템은 호스트를 통해 서로 및 리소스 요구 사항을 알고 있다. 호스트 하드웨어 리소스는 분할되어 가상 컴퓨터(또는 논리 파티션)에 할당된다. IBM Z/VM은 이 파라 가상화 기술을 설립했으며 거의 모든 IBM 메인프레임 솔루션이 이 가상화 방법을 사용한다. 예를 들어 IBM 시스템 P는 HMC에서 관리하는 풀링된 가상화된 하드웨어 계층을 사용하여 논리 파티션에 리소스를 배포한다. 각 파티션은 다른 파티션의 요구 사항을 알고 있으며 각 서버에 정의된 최소 하드웨어가 있는지 확인하기 위해 리소스가 공유된다. IBM은 세계 컴퓨터 시장의 점유율을 대부분 차지하고 있으며 컴퓨터 외에도 사무기기들과 정보 처리 시스템을 제조한다.[9]
각주[편집]
- ↑ 서버 가상화 한국정보통신기술협회 - http://terms.tta.or.kr/dictionary/dictionaryView.do?word_seq=055358-1
- ↑ Neal Weinberg , 〈서버 가상화의 미래 : 컨테이너 및 서버리스 비교 진단〉, 《아이티월드》, 2018-07-13
- ↑ 서버 가상화 작동 방식 하우스터프웍스 - https://computer.howstuffworks.com/server-virtualization.htm
- ↑ Flature, 〈호스트형 서버 가상화(Hosted Virtualization Architecture)〉, 《띵크그라운드》, 2019-04-14
- ↑ LIB, 〈서버 가상화 종류: ② 호스트(Hosted)형〉, 《네이버 블로그》, 2014-04-25
- ↑ 최영락 휴레이포티지브 선임연구원, 오픈플로우코리아 기술매니저, 〈가상화와 컴퓨터 네트워크의 활용 1 : 가상화와 데이터센터〉, 《방송과 기술 Vol.232》
- ↑ 안성원, 〈클라우드 가상화 기술의 변화 - 컨테이너 기반의 클라우드 가상화와 DevOps〉, 《소프트웨어정책연구소》, 2018-12-10
- ↑ Lucas 팬도라, 〈IT 인프라 6편 가상화〉, 《티스토리》, 2018-10-19
- ↑ 이관용, 〈유닉스 서버 가상화 어디까지 왔나〉, 《컴퓨터월드》, 2008-03-31
참고자료[편집]
- 이관용, 〈유닉스 서버 가상화 어디까지 왔나〉, 《컴퓨터월드》, 2008-03-31
- 주창오, 〈가상화(Virtualization) 총정리 - 서버 가상화가 필요한 이유〉, 《티스토리》, 2012-05-21
- Neal Weinberg , 〈서버 가상화의 미래 : 컨테이너 및 서버리스 비교 진단〉, 《아이티월드》, 2018-07-13
- Lucas 팬도라, 〈IT 인프라 6편 가상화〉, 《티스토리》, 2018-10-19
- 안성원, 〈클라우드 가상화 기술의 변화 - 컨테이너 기반의 클라우드 가상화와 DevOps〉, 《소프트웨어정책연구소》, 2018-12-10
- 전동운, 〈기술분석보고서〉, 《NICE평가정보(주)》, 2019-03-14
- 이광재, 〈(2020 전망) 엔터프라이즈가 주목해야 할 기술…SW 인프라 구축 필요성 확대〉, 《파이낸셜신문》, 2019-12-26
- 서버 가상화 한국정보통신기술협회 - http://terms.tta.or.kr/dictionary/dictionaryView.do?word_seq=055358-1
- What is Server Virtualization? 아틀란틱넷 - https://www.atlantic.net/what-is-server-virtualization/
- 서버 가상화 작동 방식 하우스터프웍스 - https://computer.howstuffworks.com/server-virtualization.htm
- 서버 가상화 기술의 진화: VM과 컨테이너 가비아 라이브러리 - http://library.gabia.com/contents/infrahosting/7426
- 가상화: 패턴의 관점에서 본 가상화 한국데이터산업진흥원 - https://kdata.or.kr/info/info_04_view.html?field=&keyword=&type=techreport&page=260&dbnum=127235&mode=detail&type=techreport
- 가상화/컨테이너 중소벤처기업부 - http://smroadmap.smtech.go.kr/0201/view/m_code/A010/id/1883/idx/1886
같이 보기[편집]