Robert P. Goldberg. Gerald J. Popek 과 함께 가상화 기술을 연구한 선구자.
원문 링크
Ver.대충
소개.
한 컴퓨터 시스템 상의 다른 시스템에서 하는 완전한 인스트럭션 단위의 가상화는 익숙한 컴퓨팅 기술이다. 이를 소프트웨어 개발자들이 자주 이용하게 되는 때가 하드웨어 기반이 변경될 경우이다. 예를들어, 만약 프로그래머가 소프트웨어 개발을 어떤 특수한 의도로(aerospace같은) 개발할때 컴퓨터 X가 제작중이고 아직 가용하지 않을때, 그는 적당히 쓸만한 일반적인 머신G에서 시뮬레이터를 작서앟고자 할 것이다. 시뮬레이터는 상세한 시뮬레이션을 X의 환경에 특별히 맞춰 제공할 것이고, 이는 프로세서, 메모리, I/O 디바이스들을 포함한다. 있을 수 있는 타이밍 의존성을 제외하고, 프로그램이 "시뮬레이션된 머신 X"에서 돌아가면 후에 "진짜 머신 X"에서 ( 그게 최종 빌드 & 체크아웃 됐을때 ) 돌아가는 것과 같은 효과를 준다. X에서 동작하는 프로그램들은 임의적일 수 있다 - I/O 디바이스들을 시뮬레이트 하기 위한 코드, 시뮬레이트하는 메모리 상의 데이터 이동이나 시뮬레이트 되는 머신에서의 어떤 명령의 실행을 포함한다. 시뮬레이터는 소프트웨어 필터링 레이어를 제공하는데 이는 X 상의 프로그램들이 오동작 하는 것으로 부터 머신 G의 리소스를 보호한다.
만약 몇몇의 다른 프로그래머들이 동시에 X를 위한 소프트웨어를 개발한다면, 아마 G의 운영체제 하에 다수의 시뮬레이터가 동작해야 할 것 이다. 그렇지 않다면, 특수한, 더 강력한 버전의 개발되야 할 것이고 이는 다수의 사용자를 위해 스스로 타임-쉐어링 해야한다. 두 경우에, 결과물은 머신 G상의 하드웨어-소프트웨어 인터페이스로 존재하는 머신 X의 다량 카피본의 환영일 것이다.
머신 X와 G가 임의로 결정된다면, 상당히 다른 구조를 가지고 있을 것이다. 이것은 매우 큰 시뮬레이션 프로그램과 각 X의 명령들에 대한 시뮬레이션이란 추가 부담을 의미한다. 이런 이유로, 머신이 1000 to 1 (?) 만큼 느려지는 경우를 찾을 수 있다. 그래서 시뮬레이션은 소프트웨어 개발에 국한되어 사용되고 production mode(?)에는 거의 사용되지 않는다.
X와 G가 다르긴 하지만, 그들을 동일하게 선택이 가능하다. - 예., X=G. 이런 경우 우리는 하나의 머신 G에 많은 G의 하드웨어-소프트웨어 복제본을 지원해야 할 것이다. 각 사용자는 그들의 고유한 머신 G의 복사본을 갖고 그의 "고유한" 컴퓨터에 운영체제를 선택해 구동할 수 있다. 그는 또한 자신이 개발이나 디버그할 자신의 운영체제를 선택할 수 있다. 그 이전, 시뮬레이트된 G의 각 명령어들이 실제 G 상의 소프트웨어에 의해 인터프리트 되고 있고, 그렇기에 한 시뮬레이트되는 머신이 다른 머신들에 간섭할 방도가 없다.
만약 실제와 시뮬레이트 되는 머신들이 동일하다면 그 때는 아마 성능 하락이 20 to 1 정도인 시뮬레이터를 만들 수 있을 것이다.* 이는 좀더 범용적인 시뮬레이터를에 고려될만한 성능향상 같지만, 프로그램이 네이티브 하드웨어처럼 동작한다는게 이상하게 여겨진다, i.e.,머신들이 이를 위해 설계되면, 모든 경우에 느려진다. 이런 경우에 대한 숙고는 그 자신의 다량의 복사본을 엄청나게 더 효율적으로 할 수 있는 시뮬레이터의 개발을 끌어냈다. 이런 시스템들에서, 소프트웨어 인터프리젠테이션 없이 시뮬레이트되는 머신을 의한 많은 소프트웨어들이 하드웨어에서 직접 실행된다. 이런 종류의 시스템을 가상 머신 시스템 ( Virtual Machine systems), 이라고 하고 시뮬레이트 되는 머신들을 가상 머신 ( Virtual Machines : VMs ), 그리고 시뮬레이터 소프트웨어를 가상 머신 모니터 ( Virtual Machine Monitor : VMM )라고 한다.
VMM을 구현하는 것은 대상 머신의 아키텍처에 달렸다. 그리고 가상 머신 모니터들이 생성되더라도 아직 성능과 사용에 관한 많은 흥미로운 의문들이 남아 있다.
IBM의 System/370 을 위한 향상된 가상머신, 가상 머신 시스템의 어플리케이션의 데이터 보안/신뢰성은 중요한 문제가 있고, 가상 머신을 소프트웨어 개발 비용 절감을 위해 사용하는 테크닉은 단지 현재 가상 머신의 흥미로운 점들 중 가장 널리 퍼질 이유가 있었을 뿐이다.
이 페이퍼에서 우리는 가상머신의 원리, 성능, 그리고 실현에 걸쳐 최근의 작업이슈들을 얘기하고자 한다. 부분적으로, 우리는 가상 머신의 이유, 새 아키턱처 디자인 상의 가상 머신의 영향에 대한 토론, 가상 머신 성능 비용에 대한 숙고, 그리고 마지막으로 가상 머신으로 가능한 유일할 몇 어플리케이션에 대한 탐구에 대한 조사를 했다. Buzen과 Gagliardi 의 지침서, Parmelee et al, 그리고 Meyer 와 Seawright, 챕터 1-3과 같은 박사 논문들을 읽는 것이 아마 추가적인 배경 지식이 되 줄 것이다. 마지막으로 Madnic과 Donovan에 의해 최근에 쓰여진 책은 운영체제 과정의 한 부분으로 가상머신을 훌륭히 소개하고 있다.
Principles - 원리
가상 머신 시스템은 곧 일반적인 모습으로 등장할 삼세대 아키텍처와 멀티프로그래밍 운영체제를 위해 개발되었다. - 예,OS/360. 이 시스템들의 고유한 아키텍처적 특징은 특권(privileged)와 비특권(non-privileged) 모드의 이중상태를 하드웨어 적 구현이 되겠다. 특권 모드에서 소프트웨어에겐 모든 인스트럭션이 가용하지만 비특권 모드에서는 그렇지 않다. 운영체제는 소규모의 특권모드 소프트웨어 nucleus라고 불리는 프로그램을 내재한다. 사용자 프로그램은 비특권의 하드웨어 인스트럭션의 수행이나 슈퍼바이저 콜을 -e.g., SVCs - 특권 명령을 수행하기 위해서 특권모드 소프트웨어 nucleus에게 요청한다. - e.g., I/O - 비특권 명령군과 슈퍼바이저 콜의 조합은 실질적으로 bare machine과 유사해 보이지만 같지 않은 extended machine(확장머신)임을 정의한다. 확장 머신은, 이론 상으로는, 더 휴먼-엔지니어적이고 원본 bare머신보다 프로그램이 용이하다.
확장 머신의 등장으로 많은 컴퓨터 시스템에의 설치가 매우 성공적이 되었지만, 이와 관련해서는 아직 많은 문제가 존지한다. 도면 1 에서는 다수의 확장 머신 인터페이스를 보여주고 있는데, 오직 하나의 bare-머신 인터페이스가 제공된다. 그런고로, 오직 하나의 특권 소프트웨어 nucleus가 한 시간대에 동작할 수 있다. 그 결과로, 다른 운영체제 시스템을 돌리 수가 없게 되었고, 이는 진단 프로그램 외에 확장 머신 인터페이스를 대신하는 bare-머신 인터페이스를 요구하는 어떤 소프트웨어 또한 포함한다. 이런 경직된 구조는 유저 소프트웨어의 이식성에( 다른 운영체제를 위해 쓰여진 ), 운영체제의 테스팅과 수정 ( 특권모드 소프트웨어 ), 그리고 테스트와 진단 프로그램들 ( T & D )에 중요한 영향을 미친다. 이런 문제에 직면했을때 설치의 관리는 보통 스케쥴링을 쉬프팅 함으로서 해결하고자 한다: 운영체제 시스템 디버깅, T&D, 사용할 수 없거나 릴리즈된지 오래된 운영체제 시스템, 그리고 일반적인 시스템을 하루의 ( 그리고 밤의 ) 시간을 나누어 스케쥴하는데 사용한다.
가상머신의 주된 혁신은 앞선 문제를 해결하고자 함이다. 가상 머신 시스템(VMs)의 핵심은 가상 머신 모니터(VMM)으로 이는 단독으로 존재하던 머신 인터페이스를 다수의 환영으로 변환시키는 것이다. 이 인터페이스들(가상머신들) 각각은 실제 컴퓨터 시스템을 대체할 만한 능력을 갖고, 모든 프로세서 인스트럭션을 완수할 수 있고(i.e., 특권 인스트럭션과 비특권 인스트럭션 모두 포함 ) 시스템 자원도 포함한다.(i.e., 메모리와 I/O 디바이스들). 각 운영체제를 그 자신들의 가상 머신에서 구동시키는 것으로 다수의 다른 운영체제 시스템에서 구동하는 효과를 얻을 수 있다.( 특권모드 소프트웨어 nuclei).
아마 가장 널리 아는 가상 머신 시스템은 IBM의 VM/370일 것이다. 각 가상 370 에는 사용자가 System/360 이나 System/370을 선택할 수 있고, DOS/360, OS/VS1, OS/VS2 혹은 OS/360의 어떤 버전이든 구동할 수 있다. 사용자는 Conversational Monitor System(CMS) 를 구동할 수도 있고, 간단하게 단순프로그래밍 된 운영체제 시스템을 가상 머신을 이용해 개발할 수도 있다.
다른 가상 머신 시스템 개발 현황 ... ( 생략 )
가상 머신과, 멀티프로그래밍, 가상 저장장치가 독립되는 컨셉이긴 하지만, 이들이 함게 조합된 형태를 갖춘다면 매우 강력할 것이다. 가상 머신은 컴퓨터 시스템의 환경을 형태를 따로 분리하여 유용함을 제공해준다. 멀티프로그래밍과 함께라면 하나의 하드웨어 시스템에서 다양한 다수의 가상머신이 가능하다. 마지막으로, 가상 저장장치까지 더해지면, 메모리 요구량이 실제 가용한 자원을 넘어서는 가상 머신도 가능할 수 있다.
가상 머신 의도의 힘에도 불구하고, 실제로는 제한된 수의 머신만이 구현되고 있다. 이런 상황은 삼세대 머신들이 가상 머신을 지원하지 않게 설계된 특징 때문이다. 그 결과, 이 시스템들은 적절한 아키텍처적 지원을 해주지 않아 VMM을 억지스러운 소프트웨어 테크닉이 되게 만들었다.
소개부에서 논했던 시뮬레이트된 머신과 마찬가지로 가상 머신은 믿을 수 있는 프로세서, 메모리, I/O 시스템 과 운영체제 콘솔까지의 복제품의 지원이 필요하다. 뿐만 아니라, 가상 머신 컨셉으로서 효율에 요구사항까지 만족시키켜야 하고, 가상 CPU에서의 인스트럭션들을 호스트 하드웨어에서 바로 실행시킬 수 있는 구조가 중요한 위치를 갖으며 필요하다. 가상 머신에서 동작하는 인스트럭션들이 머신의 모드를 수정하는 것으로 특권 인스트럭션까지 포함, I/O, etc... 하기 시작한 뒤로 가상 머신에서 VMM 혹은 다른 가상 머신들에서 간섭하여 제한함으로서 소프트웨어의 직접 실행을 완성할 수 있다. 이런 상황을 막기 위해서 VMM에는 실제 프로세서의 state를 포함 제어하고 유지하는 기능이 꼭 필요하다.
Third-Generation Implementation Issues
앞서 다뤘던 문제를 해결하기 위한 삼세대 아키텍처는 비특권모드에서 동작하는 가상머신 소프트웨어들이 소프트웨어 테이블에 가상 모드 비트를 갖게 하는 것이다. 가상 모드 비트는 소프트웨어가 bare-머신에서 직접 실행시킬 것인지를 나타내는 상태 비트이다. 굳이 제어하지 않아도 되는 인스트럭션은 VMM으로의 상태 전환 없이 bare-머신에서 직접 실행될 것이다. 다른 인스트럭션들은 VMM에 의해 trap될 것이고 ( 디버거를 연상해보세요 ) 가상 모드 비트를 통해 각 케이스 별로 해야되는 동작들을 정의할 것이다.
일반적으로, 비-특권 인스트럭션군은 바로 실행하도록 하고, 특권 인스트럭션군은 trap 되고 시뮬레이트되야 할 것이다. 하지만, 이는 항상 이뤄질 수 없게 하는 몇몇의 프로세서 모드가 매핑되기도 전에 반응하는 특권이 아닌 인스트럭션 군이 있다. -i.e., 비특권모드에서 실행될 때는 자동으로 trap되지 않는다. 이런 이유로 이런 소불안전한 프트웨어 설계를 가지고는 가상머신 시스템을 지원하기가 불가능한 경우가 있다.
삼-세대 가상머신 시스템들에서, 가상머신들의 메모리는 시스템의 메모리를 매핑하여 사용하는 동작 구조를 사용한다. 가상 머신의 메모리는 실제 메모리의 속성을 간지해야 한다. 주소 영역 0 이나 인터럽트 컨트롤 위치들이 이에 속한다. 메모리 매핑은 현 시스템에서 단순한 리로케이션이나 페이징 둘이 사용된다. 만약 호스트 머신이 페이지된다면, 가상 머신도 페이징 메커니즘을 포함해야 할 것이다. 이런 경우, VMM은 페이지테이블을 조작하여 페이지되는 주소대역을 그들에 맞는 실제 주소로 맵해야 한다. 현재의 기술은 조금 불편하고 필요하지 않은 소프트웨어 오버해드가 있지만 최근의 향상이 이 문제들을 해결할 것이다.
I/O 인스트럭션 군이 대게 특권명령이 된 뒤로, 가상 머신의 소프트웨어에 의해 실되는 것은 VMM으로의 trap을 유발한다. 이런 관점에서 VMM은 디바이스나 메모리 주소들을 I/O 명령이 발행되기 전에 변환할 수 있는 가상머신의 장점이 있다. I/O 가 완료되는 인터럽트가 VMM으로 왔을때, 적합한 가상 머신에 반영될 것이다. I/O 명령들이 "비교적 저 주파수"와 함께 동작한 뒤로 VMM 소프트웨어 중재로 인한 성능 하락은 참을만해졌다. 현 컴퓨터 아키텍처들은 부적절하게 쓰여진 채널 프로그램이 다른 가상 머신이나 VMM 자신에게 형향을 미칠 수 있기 때문에 VMM 소프트웨어의 중재로 시스템의 무결성을 유지해야 한다. 이에 대한 부가 효과로 소프트웨어 중재는 한 디바이스의 요청을 위한 것에서 다른 것들을 위한 요청으로 I/O 를 맵하거나 실제로는 물려있지 않은 특별한 디바이들을 제공할 수 있게 됐다.
어떻게 가상머신 맵들을 다양한 시스템에 맞게 설계하고 그 맵핑을 머신들이 허용하는 토의는 문언에서 다룬다.최근의 공부에서는 삼-세대 가상 머신 지원을 위해 정형화된 수학적 기법까지 정확한 아키텍처적 상태를 수립하는데 사용되고 있다. 이 결과로 다수의 연구자들이 가상 머신들을 지원하기 위해 현재의 머신들을 수정하고 있다.
Virtualizable Architectures
'IT > IT 기술 관련' 카테고리의 다른 글
| Survey of Virtual Machine Research - 번역 중 (0) | 2011/07/09 |
|---|
