최근 몇 년 동안 각각의 가상머신(VM)이 여러 운영 체제를 실행할 수 있도록 단일 하드웨어에 여러 가상 머신을 구축해 각 가상머신이 실제 컴퓨터를 에뮬레이션할 수 있도록 해주는 가상화의 진행속도가 갈수록 빨라지고 있다.
기업들은 가상화를 통해 하드웨어와 컴퓨팅 리소스를 보다 효율적으로 활용해 비용을 크게 줄이면서 성능, 유연성, 시장 출시 시간 측면에서 큰 이점을 얻을 수 있다는 사실을 깨닫고 있다.
가상화는 임베디드 시스템 개발자들에게 새로운 역량과 가능성을 제공한다. 시스템 아키텍트는 여러 운영 체제를 사용해 최고의 장점들을 결합한 장치를 설계할 수 있다. 예를 들어, 임베디드 시스템의 경우, HMI(Human Machine Interface)에는 Microsoft의 Windows를, 실시간성을 위해서는 VxWorks를, 그리고 클라우드로의 연결을 위해서는 리눅스를 선택할 수 있다.
각각의 운영 체제는 서로 다른 코어 세트상에서 실행되며 자체 디바이스를 가지고 있다. 시스템 아키텍트는 가상화를 통해 성능 저하, 제약이 없는 설계를 할 수 있게 된다.
이 글에서는 실시간 운영체제 ‘VxWorks’를 이용한 임베디드 가상화에 초점을 두고 있으며 가상화를 이용해 임베디드 시스템을 설계하는 방법, 시스템 아키텍트가 고려해야 할 사항, 그리고 혁신적인 새 디바이스를 설계하기 위해 필요한 각 단계에 대해 다루고 있다.
1단계: 운영 체제
최상의 시스템 설계를 위해 어떤 운영 체제를 사용해야 하는가에 대한 답은 시스템 설계의 목표에 따라 달라진다. 네트워킹이 중요한 경우에는 미들웨어와 어플리케이션을 신속하게 재사용하기 위해 오픈 소스를 기반으로 하는 리눅스가 그 해답이다.
HMI에서 특히 그래픽이 중요하다면? 최종 고객이 디바이스에서 기존 어플리케이션을 실행시켜야 한다면? 그렇다면 Windows가 가장 논리적인 해답이 될 수 있다.
실시간성, 마이크로세컨드(Microsecond, 1초의 1/10) 단위, 혹은 그 이하의 최소 응답 시간, 그리고 실행 로직에 실시간성(Determinism)이 요구되는 경우에는 VxWorks와 같은 실시간 운영 체제(RTOS, Real-Time Operating System)가 최적의 선택이다.
추가된 각각의 운영 체제는 전용 가상머신에서 실행되며 코어, 메모리, 장치 등의 리소스가 필요할 것이다. 리소스의 양은 각 운영 체제에서 요구하는 처리량에 따라 달라진다.
가상화는 가상머신을 구축하고 실행하는데 사용되는 하이퍼바이저를 통해 구현된다. 하이퍼바이저를 적용하기 위해 운영 체제를 수정할 필요는 없지만 추가적인 디바이스 드라이버가 필요할 수 있다 (7단계: 가상 I/O에서 설명).
2단계: 프로세서
프로세서는 효율적인 가상화를 지원하기 위해 핵심적인 요소이다. 최신 프로세서는 가상화를 위한 그리고 하이퍼바이저(가상화의 핵심 구성요소)가 하드웨어를 자유롭게 제어할 수 있는 권한을 가질 수 있도록 하드웨어 지원 기능을 제공한다.
하이퍼바이저는 운영체제보다 더 많은 권한을 가지며, 가상머신들간의 가용 하드웨어를 파티셔닝하기 위해 프로세서와 함께 동작한다. ARM의 Virtualization Extensions, 인텔의 V-PRO, 프리스케일의 e500mc이나 이후 버전 등과 같이 모든 주요 프로세서 아키텍처는 하드웨어 가속 지원을 제공하고 있다.
선택한 프로세서는 1단계에서 선택했던 모든 운영 체제를 실행하기 위해 충분한 코어가 있어야 하고 이들 코어에 필요한 처리 능력을 제공해야 한다. 예를 들어 쿼드 코어 프로세서는 VxWorks에 1개의 코어, 리눅스에 1개의 코어, Windows에 2개의 코어를 제공할 수 있다.
하이퍼스레딩도 유용한 기술인데 이는 하드웨어 레벨에서 논리적으로 쿼드 코어 프로세서가 8 코어의 기능을 하도록 한다. 하이퍼스레딩은 일반적으로 리눅스와 Windows와 같은 운영 체제에는 효과적이지만, 실시간성에 미치는 영향이 상당하기 때문에 대부분의 경우에 진정한 의미에서의 실시간 로드에는 적합하지 않다.
프로세서는 또한 충분한 메모리가 필요한데, 각각의 가상머신에 메모리가 할당되어야 할 것이다. 가령 Windows의 경우 통상적으로 기가비트 단위의 메모리가 필요하고, 리눅스는 그보다는 적은 메모리가 필요할 것이며, VxWorks 같은 RTOS는 구성에 따라 킬로바이트나 메가바이트 단위의 최소 메모리만 차지한다.
하이퍼바이저는 이러한 리소스를 나누는 일을 담당하는 구성 요소로, Windows(또는 다른 가상머신)가 사용하지 않는 코어나 메모리가 VxWorks에 할당 되도록 한다.
3단계: 안전성 및 인증
요구되는 안전성 및 보안 수준에 대해 정확하게 이해하고 있어야만 한다. 안전성 및 보안 기능에 대한 요구 수준이 높을수록 시스템 아키텍트는 더 많은 제약 사항에 대해 고려해야만 할 뿐만 아니라 더 많은 비용이 발생할 것이다.
안전성은 사람 또는 다른 시스템과 상호작용을 하는 디바이스의 리스크과 직접적으로 관련되어 있다.
이러한 디바이스는 IEC 61508, ISO 26262, CENELEC EN 50128 또는 DO-178C 같은 안전 표준을 한 가지 이상 충족하고 있다는 인증을 반드시 받아야 한다. 이러한 설계에서는 일반적으로 가상화 계층뿐만 아니라 최소 하나 이상의 가상 머신 역시 안전성을 확보해야만 한다. 다시 말하지만, 시스템 설계의 초기 단계에서부터 안전성을 고려해야 한다.
가상화는 다음과 같은 기능을 수행할 수 있기 때문에 안전성에서 중요한 역할을 한다.
a) 하나의 하드웨어 상의 별개의 분리된 기상머신에서 여러 세이프티 어플리케이션을 결합해 리던던시(Redundancy)를 제공하기 때문에 단일 멀티 코어 상에서 리던던시 구현이 가능하다. 언제나 그렇듯이 이 경우 시스템 설계에 주의가 필요하다.
b) 여러 위험 수준을 설정할 수 있다. 즉, 낮은 안전 요건의 가상머신 바로 옆에서 높은 수준의 안전성 요구사항을 가지고 있는 다른 하나의 가상 머신을 실행할 수 있다. 이를 통해 낮은 안전성의 가상머신을 수시로 업데이트하면서도, 높은 안전성의 가상머신을 일정하게 유지할 수 있다(재인증 필요 없음).
4단계: 보안
보안은 시스템이 부팅되는 방법, 안전하게 데이터를 저장하거나 전송하는 방법, 어떤 애플리케이션을 시스템상의 어떤 가상머신에서 실행할 수 있도록 허용할 것인가 하는 문제와 직접적으로 연결되어 있다.
보안은 매우 중요한 주제로 기존 설계를 나중에 보강하기는 쉽지 않은 경우가 많기 때문에 처음 단계에서부터 고려해야만 한다.
보안 요구는 가상화 계층에 직접적으로 영향을 주기 때문에 가상머신을 부팅하기 전 단계에 보안 부팅(Secure Boot)과 이미지 검증 등의 기능이 필요하다.
5단계: 부팅
시스템 아키텍트는 안전성 및 보안에 대한 요구를 충족시키기 위한 제약 사항을 고려해 시스템을 부팅하는 방법에 대해 생각해야 한다. 일반적으로 부트로더가 시스템을 시작시키는 물리적 저장매체가 있다.
이는 플래시 스토리지, USB, 시리얼 ATA(SATA), 또는 디바이스 기능 및 풋프린트가 허용하는 범위 내에 어떤 것이든 될 수 있다.
부팅은 단계별로 이루어진다. 먼저, 시스템이 BIOS나 일종의 펌웨어를 실행하고 뒤이어 부트로더가 실행되면, 가상화 컴포넌트를 포함하고 있는 임베디드 소프트웨어가 실행된다.
VxWorks는 운영체제에 직접 구현되는 가상화 기능을 제공한다. 부팅된 임베디드 소프트웨어 레이어는 전체 기능을 모두 갖추고 있는(full-fledged) 운영체제이며 RootOS라고도 알려져 있다. 이때 RootOS는 가상 머신을 부팅한다.
가상머신을 위한 커널은 RootOS에 포함되기도 하며 부트로더를 통해 직접 로딩되거나 일종의 로컬 저장매체나 원격 저장매체에 존재하기도 한다. 이것은 일반적으로 RTOS나 작은 운영 체제를 부팅하는 방법이다.
RootOS는 또한 가상머신에서 부트로더를 로딩하고 파티션에 부트로더를 지정해 디스크에서 가상머신을 직접 부팅할 수도 있다. 이 방법은 리눅스와 Windows 같은 큰 운영 체제를 부팅하는 일반적인 방법이다.
부팅은 9단계-업그레이드와 직접적으로 관련이 있다. 최신 임베디드 시스템은 유연하며, 로컬 스토리지를 업데이트를 해야 하기 때문에 새로운 워크로드를 다운로드할 수 있어야 한다.
6단계: 입력/출력 (INPUT/OUTPUT)
시스템의 가상머신은 외부와 통신할 수 있어야 하며 I/O 디바이스가 필요하다. 일반적으로 I/O 디바이스에는 네트워크 카드, 직렬 포트, 그래픽 카드, SATA, USB 등이 있다.
I/O로의 가장 단순하고도 효율적인 경로는 각각의 가상머신이 필요한 디바이스에 직접 액세스할 수 있도록 하는 것이다. 예를 들어 그래픽 카드는 Windows까지 곧장 통과해서 지나갈 것이고 표준 Windows 디바이스 드라이버는 이를 활용할 수 있다.
이 경우 다른 가상머신은 이 장치에 액세스할 수 있는 권한을 가질 수 없다. 오직 하나의 가상머신 만이 디바이스에 직접 액세스하거나 또는 패스 쓰루(Pass-through) 지정에 따라 디바이스를 이용할 수 있다.
가상머신이 디바이스에 직접 액세스할 수 있는 권한을 가지고 있기 때문에 패스 쓰루(Pass-through) 디바이스 액세스는 성능을 최적화한다.
하이퍼바이저 계층은 액세스에 관여하지 않으며 디바이스는 가상 머신으로 직접 메모리 액세스할 수 있다. 하이퍼바이저는 ‘격리’의 개념을 실행하기 위한 구성요소이다. 개별 가상머신은 시스템 아키텍트가 직접 할당한 디바이스만 볼 수 있다.
예를 들어 가상머신이 PCI Bus를 열거할 경우, 가상머신은 물리적 Bus에 대한 액세스를 기대하지만 하이퍼바이저가 물리적 Bus를 소유하고 에뮬레이션된 PCI 컨트롤러를 가상머신에 제공한다. 이 에뮬레이션된 컨트롤러는 해당 PCI 버스에 나타나도록 가상머신에 할당된 장치만을 제공한다.
직접적으로 할당하는 방식이 모든 I/O 디바이스에 적합하지 않을 수도 있다. 예를 들어 시스템 아키텍트가 외부 네트워크 카드로의 직접적인 엑세스 권한을 Windows에 주지 않는 대신 리눅스를 방화벽으로 사용하고 방화벽을 통해 트래픽을 통과시킨 후 해당 연결을 리눅스가 Windows와 공유하도록 허용하길 원할 수도 있다.
또 다른 문제로는 모든 가상머신에 연결하기에는 디바이스가 부족한 경우가 종종 있다. 이런 경우에는 가상 I/O를 사용할 수 있으며 이는 다음 단계에 설명되어 있다.
7단계: 가상 I/O
가상 디바이스는 가상머신에 디바이스를 패스 쓰루로 할당할 수 없는 상황에서 도움이 된다. 예를 들어 시스템에 단 하나의 SATA 저장장치 컨트롤러만 있는데 여러 가상머신이 저장장치에 액세스해야 하는 경우가 있을 것이다.
또는 가상머신이 서로 통신을 해야 할 때, 이를 위해 물리적 장치를 사용하는 것은 낭비일 것이다.
시스템 아키텍트와 관계가 없는 가상 디바이스도 많이 있다. 예를 들어 모든 가상머신은 해당 가상머신에 할당된 디바이스를 보여주는 가상 PCI Bus에 액세스할 수 있으며 하이퍼바이저는 이를 가상화하고 에뮬레이션한다.
마찬가지로 하이퍼바이저는 보드, 프로세서 레벨에서 기능과 컨트롤러를 인터럽트하기 위해 가상화된 액세스를 제공한다. 가상머신의 운영 체제는 가상 디바이스상에서 실행되고 있다는 것조차 인식하지 못한다. 하이퍼바이저가 이를 숨기고 있기 때문이다.
가상화 I/O의 핵심은 성능이다. 시스템은 가상 I/O를 통해 디바이스 경로에 소프트웨어를 추가하며 일반적으로 디바이스 액세스 성능은 임베디드 시스템에 매우 중요한다. 하이퍼바이저는 물리적 이더넷 카드를 완벽하게 에뮬레이션할 수 있지만 이를 위한 오버헤드는 상당한다. 대신 가상 I/O 시스템은 일반적으로 유사 가상화(Para-virtualization)를 활용한다.
하이퍼바이저는 이를 통해 가상머신에 소프트웨어 액세스 포인트를 제공한다. 가상머신은 Para-virtualization 드라이버라고 불리는 특정 드라이버를 가지고 있으며, 이는 하이퍼바이저, 또 때로는 RootOS와 함께 구동된다.
이러한 Para-virtualization 드라이버는 운영 체제를 추가로 수정할 필요 없이 기존 OS에 쉽게 추가할 수 있다.
VxWorks는 가상 시리얼 및 가상 스토리지 역량을 제공하기 위해 VirtIO 표준을 사용한다. VirtIO에서 가상머신 내 운영 체제는 에뮬레이션된 PCI 디바이스를 통해 소프트웨어 액세스 포인트를 찾아낸다.
이 에뮬레이션 디바이스는 구성 경로에서만 사용된다. 운영 체제는 이때 드라이버를 로딩하고 가상 디바이스를 사용하기 시작한다. 운영 체제가 디바이스와 상호작용할 때, 실제로는 디바이스 기능을 제공하는 RootOS 내의 드라이버와 상호작용하는 것이다.
VirtIO는 오픈 소스 표준이자 최첨단 운영 체제로, 이미 여러 가상 디바이스에 드라이버를 제공하고 있다. 이들 드라이버는 VxWorks의 VirtIO 가상화 디바이스에 액세스하기 위해 재사용할 수 있다.
VirtIO 시리얼은 리눅스 같은 운영 체제와 RootOS 사이에 가상 시리얼 연결을 만드는데 사용할 수 있다. 이 시리얼은 데이터 커뮤니케이션이나 콘솔에 대한 시리얼 액세스를 위해 사용할 수 있다. 이 시리얼 연결은 운영 체제에서 어떤 디바이스로든 나타나는데, VxWorks 하에서는 /tyCo/x, 리눅스 하에서는 /dev/hvcx로 확인할 수 있다.
VirtIO 스토리지의 경우, RootOS는 블록 디바이스를 가상화하고 VirtIO 블록 디바이스 드라이버를 통해 가상머신에 대한 액세스를 제공한다. RootOS는 가상머신에 파티션에 대한 가상머신 액세스를 제공할 수 있으며 운영 체제는 해당 파티션에 액세스하기 위해 자체 VirtIO 스토리지 드라이버를 사용할 것이다.
하나의 예를 들면, 시스템은 네 개의 파티션이 있는 단일 SATA 디스크를 가질 수 있다. 첫 번째 파티션에는 가상화 레이어를 가져오는 VxWorks의 시스템 이미지가 들어 있다. 두 번째 파티션은 컨피규레이션 및 데이터 로그 파일을 저장하는 VxWorks를 위한 지속적인 스토리지이다.
세 번째 파티션은 리눅스를 위한 것이고, 네 번째는 Windows용이다. 각각의 가상머신은 자신의 파티션에만 액세스할 수 있도록 구성될 수 있지만, 필요한 경우 VxWorks가 클라우드로 로그 데이터를 전송할 수 있도록 리눅스는 VxWorks 파티션에 대한 읽기 전용 액세스 권한을 받을 수 있다.
시스템 아키텍트는 VirtIO 기능을 지원하기 위해 RootOS가 충분한 처리 주기를 가지고 있는지 확인해야 할 것이다.
또 다른 가용 가상 디바이스는 가상 네트워크이다. VxWorks는 가상머신 간 고속 가상 네트워크 버스를 제공할 수 있으며, 이는 표준 TCP/IP 스택을 통해 가상머신들이 서로 커뮤니케이션할 때 활용된다. 이 가상 네트워크는 가상머신 간의 사이의 공유 메모리를 사용하기 때문에 일반적인 물리적 네트워크보다 빠른 속도를 구현할 수 있다.
예를 들어 리눅스에 패스쓰루 모드의 물리적 이더넷 장치가 부여되고, 가상 네트워크 장치는 Windows와 리눅스에 각각 제공된다. 이때 리눅스는 방화벽이며 방화벽이 있는 외부 액세스를 Windows에 제공할 수 있다.
8단계: 성능
성능은 임베디드 시스템에 있어서 매우 핵심적이다. 여러 다른 프로젝트들은 각각의 다양한 유형의 성능을 요구한다. 일반적인 성능 특성으로는 마이크로세컨드(microseconds) 단위의 실시간 응답 지연율, 초 단위의 알고리즘 성능, Gbps, 마이크로세컨드(microseconds)단위의 네트워크 처리량과 지연율 등 포함된다.
성능은 시스템이 구성되는 방식, 즉 가상머신의 코어 개수, 메모리 양, 그리고 패스 쓰루 디바이스인지 가상 디바이스인지에 따라 크게 달라진다.
또한 시스템에서 처리하는 로드의 양이 어느 정도인가에 따라서도 달라지는데, 첨단 CPU에는 시스템 버스(System bus)나 캐시(Cache) 같은 보이지 않는 공유 리소스가 있으며 이들 공유 리소스상의 로드는 전체적인 시스템 성능에 영향을 줄 수 있다.
시스템에 대한 초기 설계는 파워포인트나 화이트보드에서 완성되지만 최종 성능은 벤치마크와 세부 튜닝 작업을 통해서만 결정될 수 있다.
튜닝은 실시간 작업이 요구하는 프로세싱 파워를 위해 메모리와 코어 재할당, 인터럽트나 작업의 우선 순위 재배열, 또는 가상머신을 일시적으로 늦추는 (스로틀링-Throttling) 등의 항목이 포함될 수 있다.
9단계: 업그레이드
시스템은 종종 현장에서 운영 중에 업데이트가 진행되는 경우가 많다. 시스템 아키텍트는 이러한 가능성을 위한 계획을 마련해야 한다.
가상화된 시스템의 경우, 초기 임베디드 소프트웨어뿐만 아니라 가상머신 내부에서 실행되는 이미지도 업데이트가 필요할 것이다. 하이퍼바이저는 가상머신을 중단시키고 리셋할 수 있는 라이프사이클 제어 기능을 제공하지만 시스템 아키텍트는 시스템에 대응하기 위한 계획을 마련해야 한다.
예를 들어 VxWorks, 리눅스, Windows로 구성된 시스템에서 리눅스 가상머신은 클라우드로의 연결성을 제공하며, 새로운 시스템 이미지나 VxWorks에 대한 새로운 이미지를 수신할 수 있다. 이때 리눅스는 이 이미지를 디스크에 저장할 수 있는 RootOS에 전달할 수 있으며, 새로운 이미지를 사용하기 위해 가상머신이나 전체 시스템을 재부팅할 수 있다.
10단계: 개발자 툴
시스템은 사람이 구축한다. 따라서 사람이 신속하게 시스템을 탐색할 수 있도록 도와주는 툴이 필요한다. 이를 위해 VxWorks는 항상 뛰어난 유연성과 적응성을 지원한다. 개발자는 작업 및 프로세스의 시작과 중단, 디버깅, 파일 시스템 액세스를 위해 VxWorks 커맨드 라인을 활용할 수 있다.
또한 동일한 커맨드 라인을 사용해 매우 유연한 양방향/프로그래밍 방식으로 가상머신을 생성하고 제어 디바이스 할당을 제어할 수 있다.
VxWorks 디버그 인터페이스는 실행, 브레이크포인트(Breakpoints), 스테핑(Stepping) 같은 표준 디버거 동작을 제공할 뿐만 아니라, 개발자가 호스트 개발 워크스테이션에서 직접 가상머신과 바이너리 프로세스를 시작할 수 있도록 매우 유용한 호스트 파일 시스템 기능도 제공한다. 또한 개발자는 개발 및 디버깅을 위한 Wind River Workbench 통합 개발 환경을 활용할 수 있다.
Workbench는 가상화 레이어, VxWorks, Wind River 리눅스 워크로드를 개발하고 디버깅하며 분석하는 데 활용할 수 있는 단일(Eclipse 기반) 환경이다.
VxWorks 인터페이스는 운영 체제의 서비스를 통해 시스템에 대한 액세스를 제공한다. 특정 경우(예를 들어 장치 드라이버를 개발할 때)에, 운영 체제에 의존하지 않고 하드웨어 가까이에서 디버깅할 수 있는 능력이 중요하다.
이런 경우 시스템 상태를 살펴보기 위해 전체 시스템을 중단시키는 정지 모드 디버깅을 수행할 수 있는 하드웨어 기반 디버거가 큰 가치를 제공해 줄 것이다. 이것이 바로 Lauterbach가 TRACE32 제품 라인에서 제공하는 기능이다.
이들 제품을 통해 개발자는 작업 및 프로세스와 메모리 공간과 같은 OS 레벨 컨셉에 대한 가시성을 확보하는 한편, 가상머신과 하이퍼바이저를 인식하고 있는 상태에서 운영 체제 아래를 지나 아무 소프트웨어도 설치되어 있지 않은 하드웨어(bare hardware)에 액세스할 수 있다.
결론
가상화는 시스템 설계에 있어서 시스템 아키텍트에게 혁신적인 유연성을 제공하며, 시스템 아키텍트는 이를 통해 여러 애플리케이션을 제공하는데 있어서 하드웨어의 제약을 극복할 수 있다.
또한 성능적인 측면에서의 이점뿐만 아니라 높은 애플리케이션 가용성과 탁월한 확장성을 제공한다. 운영체제에서부터 프로세서, 인증, 보안, 부팅, 입/출력, 가상 I/O, 성능, 업그레이드, 개발자툴 등 가상화 구축을 위한 각각의 10가지 단계를 성공적으로 구현한다면 가상화의 이점을 극대화시킬 수 있을 것이다.
글 : 오규빈 차장 / 인더스트리얼 사업 총괄 / 윈드리버코리아
자료제공 : 윈드리버(www.windriver.com)
그래도 삭제하시겠습니까?