개발자를 위한 새로운 선택, 오픈 솔라리스
- 썬 마이크로시스템즈 김봉환 부장
오픈 솔라리스 - 개발자들의 새로운 신천지
지난 2005년 6월에는 IT 업계에 아주 흥미로운 소식이 있었다. 그것은 IT 인프라스트럭쳐를 위한 하드웨어와 소프트웨어를 공급하고 있는 거대 기업인 썬마이크로시스템즈(이하. 썬)가 자사의 대표 하드웨어에 운용되는 대표 소프트웨어 제품인 운영체제 솔라리스10(Solaris10)의 대부분의 소스코드를 공개했다는 것이다.
1990년대말 이른바 DOT.COM 시대의 대부분의 백엔드 환경을 점유했던 썬의 솔라리스는 지금 우리가 향유하는 인터넷 환경을 주도하는 네트웍 환경에 가장 발전된 운영체제였다. 이러한 발전이 썬의 자만심을 불러있으켰을까? 가정에서 사용되는 개인용 컴퓨터로 일컬어지는 PC가 단순한 클라이언트에서 윈도우즈와 리눅스의 발달에 따라 서버로서의 기능도 가능해지면서 IT 서비스의 세계는 새로운 변화의 물결을 맞이하게 되었다. 특히나, 리눅스의 획기적인 성장은 x86 플랫폼에 신선한 바람을 불어넣기 시작했으며, 이제는 비교적 덜 중요한 업무용으로 많이 사용되게 되었다.
이러한 리눅스가 성장하게 된 가장 기본적인 바탕은 바로 소스가 공개되어 있다는 점에 주목하게 된다. 임의의 불특정 사용자들이 자신의 불편함을 스스로(참다못해?) 수정하게 되다 보니, 현재 엔터프라이즈 운영체제에 상당하는 기능들을 가지게 되었고 직접 참여한 사용자들은 그 자신의 공헌을 외부에 알리게끔 노력하면서 리눅스의 세계는 상당히 성장했다고 볼 수 있다. 개별적으로 보면 볼 것 없어 보이는 사람의 힘이 모이면 역시 위대하다.
썬은 바로 이 부분에 주목했다고 볼 수 있다. 끊임없이 첨단 기술을 개발하여 추가하고자 하려면 엄청난 개발 비용이 들었고, 이렇게 만들어진 솔라리스를 팔기 위해서는 엄청난 마케팅 비용이 또 들었다. 또한 첨단 기술을 개발하는 속도가 오픈 소스 계열보다 점점 처지기 시작했다는 점이다. 물론, 오픈 소스 세계에서는 상상할 수 없는 기능을 개발하기는 하지만 그러한 기능이 시장에서 매력을 가지게 하는데는 또다른 노력이 필요했다. 이런 고찰하에 썬은 자사 지적 재산의 상당한 부분을 차지하는 솔라리스의 소스를 공개하게 이르른다. 이름하여 오픈 솔라리스(http://opensolaris.org).
오픈 솔라리스는 기존의 유닉스 사용자들과 리눅스 사용자들에게 대단한 관심을 불러왔는데, 그 이유는 솔라리스를 보는 관점에 따라 다양했다. 유닉스에 고비용 때문에 리눅스로 이전한 사용자들은 오픈 솔라리스를 통해 다시 솔라리스로 돌아갈 수 있게 된점을 매우 크게 반겼는데 그 이유는 오픈된 솔라리스를 통하여 저비용으로 엔터프라이즈 수준의 운영체제를 사용할 수 있게 되었다는 점이다. 또한 기존의 솔라리스를 사용하던 사용자들은 오픈된 솔라리스의 소스를 통하여 솔라리스의 커널 구조, 디바이스 관리 구조등을 완벽하게 이해하게 됨에 따라 보다 안정된 구조의 솔라리스 환경을 구축할 수 있게 되었으며, 솔라리스의 입증된 소스를 이용하여 구미에 맞는 각종 유틸리티들을 쉽게 구축할 수 있으리라 생각되었기 때문이다.
또한 취약한 보안에 시달려온 리눅스 관리자들에게는 기존 미국방성에서 유일하게 인정받은 보안 기술을 가지고 있는 솔라리스를 무상으로 사용할 수 있게 됨에 따라 전체적으로 혹은 선택적으로 솔라리스를 사용할 수 있게 되었다는 점이다. 아울러, 기존의 리눅스 및 유닉스용 보안툴을 개발해서 제공하던 보안 개발업체들도 솔라리스의 발전된 보안 기술을 참조할 수 있게 되었으며, 보다 향상된 보안 솔루션을 만들어갈 수 있게 되었다.
또한, 활발한 리눅스 혹은 FreeBSD와 같은 오픈소스 개발자들은 솔라리스의 소스코드를 참조하여 한층 나아진 오픈소스를 작성하게 될 수 있게되었다. 특히, 솔라리스10에서 새로이 추가된 독보적인 기능(Dtrace, ZFS)들은 오픈소스 계열의 운영체제 개발자들로 하여금 깊은 관심을 받게 되었고, 그 결과로 MacOS X Leopard 버젼에는 솔라리스10의 Dtrace와 ZFS가 포팅 내장되어 나타나게 되었다.
이러한 개발자들을 위한 오픈 솔라리스의 특성이외에 법률적인 특징이 하나 있는데, 오픈 솔라리스는 기존의 오픈 소스 라이센스인 BSD 라이센스의 변형인 썬의 새로운 배포 라이센스인 CDDL[2]을 기반으로 소스를 공급하게 되었다. 이는 기존의 GPL 기반의 라이센스와 매우 달라서, GPL은 GPL하의 소스코드를 참고하여 작성된 모든 결과물은 오픈 되어야 하는 반면에 CDDL은 오픈 솔라리스의 소스 코드를 참고해서 작성된 결과물이라 하더라도 그 소스를 오픈할 필요가 없다. 이는 오픈 소스를 기반으로 작성한 애플리케이션을 수출하는 업체들은 매우 유리한 조건이 아닐수 없다. 기존의 GPLv2를 기반의 소스들을 참고해서 만들어 수출했다 GPL 위반 사유로 소송당한 업체들이 점점 증가하는 것으로 보아 오픈 솔라리스의 CDDL은 오픈 소스를 참조해 새로운 솔루션을 개발하는 업체들에 매우 매력적인 배포 라이센스가 아닐 수 없다.
결론적으로 오픈솔라리스를 통하여 기존의 개발자들은 무엇을 얻을 수 있는가? 비록 솔라리스가 데스크탑용의 운영체제는 아니어서 쉽게 다가가기는 어려우나, 아주 오랜기간 네트웍을 염두에 두고 만들어진 운영체제로서 네트웍을 바탕으로 하는 애플리케이션들 개발자에게는 가장 신뢰성있는 참조 구현[3](reference implementation)체로 얻은 셈이다.
때문에 일반 애플리케이션을 개발하는 개발자들에게는 신뢰도 높은 소스 코드를 제공함에 따라 완성도 높은 애플리케이션을 제공할 수 있게 되며, 커널 애플리케이션을 개발하는 개발자들에게는 커널의 모든 코드를 볼 수 있게 됨에 따라 보다 대표적인 유닉스의 내부 구조를 이해할 수 있게되어 안정적인 커널 코드를 빠르게 구축할 수 있게 되었다.
또한, 리눅스 운영체제의 큰 특징은 매우 많은 임의의 자원 코딩 봉사자들에 의해서 구성된다는 것인데, 이런 경우에는 코드의 안정성을 확보하는 것이 매우 어렵다. 따라서, 리눅스는 독특하게 ‘안정판(stable edition)’이라던가 ‘베타판(development release)’라던가 하는 등의 다양한 릴리즈와 이러한 릴리즈를 테스트해서 제공되는 다양한 배포판 업체가 난립하게 되는 데, 기술의 발전 측면에서는 좋을 지 모르나, 특정 솔루션을 개발하는 개발자 입장에서는 이러한 수많은 릴리즈와 배포판의 난립이 결코 행복한 것만은 아니다. 어디를 기준을 두고 호환성을 유지할 것인지가 난감하기 때문이다. 실행 화일 면에서는 모든 리눅스에서 돌아야 함에도 불구하고, 패키지의 차이(패키징 방식, 포함된 라이브러리등) 때문에 어떤 배포판에서는 수행될 수도 있고 안될 수도 있는 일이 발생하기 때문이다. 반면, 솔라리스는 기존의 어느 수준이상 완성되어 있는 코드위에서 확장하면서 호환성을 유지하도록 프로젝트 커뮤니티의 통제가 있기 때문에 매 릴리즈 끼리의 새로운 기술을 보충해나가면서도 호환성을어느 정도 유지할 수 있도록 운영이 되고 있다. 물론, 현재는 3-4개 정도의 오픈 솔라리스 배포판이 더욱 많이 늘어나게 되면 현재의 리눅스와 같은 문제가 없으리라고 보장하기는 힘들것이나 리눅스 계열보다 적을 것은 확실하다.
오픈 솔라리스는 썬에서 공급하는 3개의 배포판을 제외하고 현재 4개의 배포판[4]이 제공되고 있다. 썬에서는 Solaris Express, Solaris Express Community Release, Sun Solaris로서 Solaris Express Community Release가 OpenSolaris 를 바탕으로 만드는 가장 최신 빌드이며 업데이트 서비스가 없는 무상 제품이다. 반면, 여기에 업데이트 서비스를 제공하는 배포판은 Solaris Express에 해당되며, 이 최신 빌드를 기반으로 썬의 추가 테스트와 별도 소프트웨어 패키지를 추가한 배포판이 Sun Solaris 가 되는 셈이다.
썬이외에 공급되고 있는 배포판중 현재 가장 왕성한 활동을 하는 배포판은 NexentaOS로서 커널과 주요 실행 화일만을 가지며 완전히 오픈소스 기반의 GUI와 데비안 패키징 시스템을 제공함으로써 기존의 데비안 패키징을 사용하는 리눅스를 경험한 리눅스 고객들에겐 거의 차이없는 인터페이스를 제공함으로써 매우 빠르게 적응할 수 있는 버젼이다. 오픈 솔라리스 배포판중 가장 깊은 주시를 받고 있는 버젼이라고 할 수 있겠다.
이렇게 기존 개발자들에게 깊은 관심을 이끌어낸 오픈 솔라리스의 최신 기능을 볼 필요가 있겠다.
최강의 네트웍 서비스를 제공하는 오픈 솔라리스의 커널 : SunOS 5.10
오픈 솔라리스의 커널은 SunOS로 명명되어져 있다. 레드햇이나 수세 리눅스의 커널이 Linux로 나오는 것과 같은 개념이라고 할 수 있다. 현재에 이르는 SunOS 5.11은 최신 솔라리스 10의 기본이 되는 커널 버젼으로 네트웍 서비스, 분산 컴퓨팅, SMP & NUMA, 멀티코어와 같은 최신 기술 모두에 최적화 되어 있는 유닉스 서버중 가장 진보된 커널이라고 자타가 인정하고 있다. 특히, 솔라리스는 아주 이른 시기부터 멀티코어에 최적화되어 있으며, 심지어 AMD의 옵테론이 구성하는 NUMA 비슷한 구조에서도 최적화되어 있다. 최신 하드웨어 기술에 가장 잘 맞추어져 있는 운영체제인 셈이다.
솔라리스는 컴퓨팅 이론을 구현하는 데 많은 공을 들였으며 이러한 노력으로 하여금 솔라리스의 명성이 유지되었다고 볼 수 있으며 솔라리스 10과 오픈 솔라리스 이후 그러한 솔라리스의 사고와 기술은 다른 운영체제에도 영향을 주고 있다.
솔라리스의 커널은 특히, SMP[7] 시스템에 가장 최적화 되어 있는 운영체제로 알려져 있으며 실제로 썬마이크로시스템즈는 업계에서 유일하게 최대 144개의 CPU 코어를 가지고 있는 단일 박스(SMP)를 솔라리스와 함께 제공하고 있다. 많은 CPU를 운영할 수 있다는 것은 커널 자체의 병렬화가 매우 잘되어 있음을 의미하는 것이다. 때문에 솔라리스는 매우 우수한 멀티스레드 하부 시스템을 제공하고 있다. 웹서버와 같은 인터넷 서비스들은 대개 멀티스레드를 이용해서 작동되도록 구성되는 것이 최신 흐름임을 비추어 보면, 솔라리스가 인터넷 서비스에 매우 적합함을 쉽게 예측할 수 있다.
솔라리스 커널의 특징을 간략하게 요약하면 다음과 같다.[8]
그외 추가 이전 솔라리스 버젼대비 솔라리스10의 새로운 기능에 대해서는 이곳(http://www.sun.com/software/solaris/whats_new.jsp) 을 참조하길 바란다.
솔라리스 장애 관리, 서비스 관리 기능과 자가 치유 기능
솔라리스의 자가 치유 기능은 기술적으로 솔라리스 서비스 관리 기능과 솔라리스 장애 관리 기능의 구현으로 인해 저절로 생기게 된 솔라리스의 기능이라고 볼 수 있다. 솔라리스 장애 관리자는 솔라리스 내에 구성된 장애 감시 오브젝트들에 실시간으로 감시하다가 장애 발생시 이에 대한 통보와 조치를 취하게 되는데, 이때 부연으로 발생하는 서비스 장애에 대응할 수 있도록 생긴 기능이 솔라리스 서비스 관리 기능이다. 예를 들어, 특정 CPU에 장애가 발생해서 운영체제가 그 CPU를 offline 시켜야 하는 경우. 강제 오프라인을 시키게 되면 그 CPU에서 동작하던 애플리케이션은 우선 정지되어진다. 이때 서비스 매니저는 정지된 해당 서비스를 새로이 동작하게 지원해줌으로써 서비스는 자동으로 복구되게 됨으로 기존의 시스템과 서비스의 가용성을 크게 늘릴 수 있게 된다. 설사 서비스가 죽었다 하더라도 빠르게 서비스를 재가동할 수 있도록 지원함으로써 관리자는 서비스 중지에 따른 피해를 최소화할 수 있다.
다음은 장애를 실시간 보고해주는 예이다.
솔라리스의 가상화와 존(솔라리스 컨테이너)
썬 마이크로시스템즈는 최신 경향에 걸맞게 다양한 형태의 가상화 기법을 하드웨어,소프트웨어에 제시하고 있다. 썬의 최신예 멀티코어를 가진 SPARC기반의 하드웨어에는 LDom이라는 논리적 기법의 파티션 기능을 추가하고 있다. 이는 하나의 박스를 여러개의 박스가 있는 것처럼 분리해주며, 각각의 영역에 새로운 운영체제를 설치할 수 있도록 하는 기술이다. 기존의 IBM의 LPAR와 매우 흡사한 기능을 제공하고 있다. 그러나, 이 기능은 아직은 썬의 하드웨어 제품에서만 구현이 가능하다.
이와 함께 제공되는 솔라리스의 존은 최근 강력해진 하드웨어의 성능을 배경으로 불고 있는 가상화 기술의 일종이다. 흔히들 알려져 있는 가상화 대표주자인 vmware의 방식과는 달리, 게스트 영역에 별도의 운영체제를 사용하지 않고 호스트 운영체제를 빌려쓰는 기법을 사용한다. 기술적으로는 운영체제는 그냥 하나이면서, 마치 여러개가 있는 것처럼 보이도록 하는 자원관리 기능을 확장한 기술에 기반한 가상화 기법이다.[10]
이 기법은 vmware가 가지고 있는 오버헤드를 완전하게 없앰으로써 동일 운영시스템 혹은 다른 버젼의 동일 운영 시스템에서 서비스할 수 있는 애플리케이션들을 가상화 영역으로 분리함으로써 하드웨어 활용율을 극대화할 수 있음은 물론 각 가상화 영역별 관리의 독립과 보안성 개선, 안정성 개선등을 이루어 낼 수 있다. 기존에 단일 솔라리스 영역에 웹서버, DB 서버, 웹 애플리케이션 서버들을 한번에 설치해서 사용했다면 존을 이용하여 각각을 분리함으로써 용도별 분할 관리가 가능해지고 더 쉬어질 뿐 아니라, 전체적인 관리의 효율성이 증가하고 관리에 들어가는 시간도 낮출 수 있게 되었다.
또한, 오픈 솔라리스 build 49에는 x86 솔라리스만을 위한 존 기능이 추가되어 있는데, 존 영역에 솔라리스 버젼 뿐만아니라 32비트 레드햇 계열의 리눅스도 설치할 수 있게 되었다[11]. 이 기능으로 하여금, 인텔이나 AMD에 설치된 솔라리스안에는 32비트 리눅스도 함께 설치해서 운영할 수 있게 되어서[12], 솔라리스로 이동하려는 관리자나, 리눅스의 애플리케이션이 어떻게 동작하는 지를 솔라리스의 Dtrace로 추적해보고 싶은 개발자들이 좋아할 수 있겠다.
[그림 솔라리스 컨테이너/리눅스(Branz)]
동적 자원 관리 풀
솔라리스는 풀(pool)개념을 도입하여 자원을 관리할 수 있는 기능을 제공하고 있는데, 필요한 작업(project, task, zone)에 필요한 양만큼의 자원(CPU, 메모리)등을 동적으로 할당해서 사용할 수 있도록 해준다. 즉 특정 프로젝트나 업무를 만들어서 그 영역에 필요한 만큼 할당해서 사용하고 필요없으면 자원을 동적으로 조절할 수 있도록 하는 것이다. 존도 기술적으로는 일련의 업무(project)의 모임이므로 동적 자원의 관리 대상이다. 오픈 솔라리스에는 이러한 동적 자원 관리가 한층 지능화되어서 CPU 사용율에 따라 CPU의 자동 추가등과 같은 것을 구성할 수 있다.
동적 시스템 추적 툴(Dtrace)
솔라리스10에 처음으로 추가된 동적 추적 툴인 Dtrace는 그야말로 IT업계에 커다란 충격을 줬다. 기존의 제공되던 사후추적 툴의 한계를 벗어나서 실시간으로 이벤트 중심의 동적 추적을 업계에서 최초로 구현한 툴인 셈이다.
모든 운영체제에서 그렇듯이 정상적인 경우에는 문제가 없다. 비정상적인 경우에 문제가 발생하며 이러한 경우는 예측하지 못한 경우에 발생하므로 업무가 죽은 이후에 비정상적인 경우를 재생, 추적하기란 정말 쉽지 않은 것이다. 이때 Dtrace는 예상된 영역에 덫을 놓듯이 덫을 놓아서 특정 이벤트가 실행되게 되면 보고할 수 있도록 한다. 이 기술을 이용하여 솔라리스 커널 자체의 버그, 시스템 튜닝, 애플리케이션의 메모리 릭(memory leak)이나 병목등을 예전과 달리 훨씬 손쉽게 추적할 수 있게 되었으며, 이와 함께 솔라리스10 자체의 품질도 향상되게 되었다.
Dtrace는 그 기능에서 이미 많은 타 운영체제 개발자들에게 영감을 주었으며, 애플사는 이 Dtrace의 기능을 MaxOSX의 개발버젼에 해당하는 Machintosh OSX Leopard 버젼에 Xcode에 포팅,추가해놓은 것만을 보아도 얼마나 훌륭한 기능인지 가히 짐작할 수 있다. 설명했던 바와 마찬가지로 Dtrace는 커널 중심이 아니라 프로세서 중심 혹은 데이타 중심 혹은 사용자 중심인 객체 지향적 기술 처리의 흐름을 파악함으로써 비정상 문제를 야기하는 근본적인 원인을 빠르게 추적할 수 있다.
[그림 dtrace 개념도 ] [그림 dtrace chime 2 & prstat ]
프로세스 권한 관리
전통적인 유닉스 계열에서는 root 즉, 수퍼유저이면 모든 것을 할 수가 있었다. 실제로 수퍼유저는 특정 업무를 위해서만 사용되어야 함에도 많은 곳에서 root를 노출해 사용하거나 공유하는 경우가 발생한다. 이렇게 되면 시스템은 보안에 매우 취약해질 수 밖에 없다. 솔라리스는 기본적으로 root가 할 수 있는 모든 업무들을 일정한 범주의 역할로 구분하고 사용자들에게 역할을 할당함으로써 root로 해야하는 업무를 일반 사용자로 수행하면서도 동시에 root가 할 수 있는 실수[13]를 원천적으로 방지할 수 있으며, 이러한 시스템을 사용함으로써 실질적인 root 사용자를 완전히 없애버릴 수도 있다. 이 기능은 솔라리스 하부에 있는 RBAC과 함께 이용되어 특정 프로세스에 대해서 권한을 조정할 수도 있으며, 특정 사용자 혹은 특정 역할에 대해서 권한을 조정할 수 있게 됨으로써 한층 강화된 보안과 관리가 가능해진다.
ZFS - 지구상의 마지막 화일 시스템
썬 마이크로시스템즈가 솔라리스를 오픈하기 이전부터 해결하고자 하려 했던 프로젝트가 하나 있었는데, 그건 바로 솔라리스가 기본적으로 사용하는 화일 시스템인 UFS를 대체할 만한 화일 시스템을 만드는 것이었다. 이 프로젝트는 오랜 검토와 코딩 그리고 테스트를 거쳐서 나오게 되었는데, 마침 나오자 마자 오픈되어 있던 솔라리스와 함께 오픈 소스의 세계에서 모습을 나타내게 되었다.
이러한 ZFS는 시스템 관리자의 디스크/스토리지 관리에 들어가는 수고를 대폭 줄여주면서도 서비스 장애 및 데이타 발생율을 현격하게 낮춰줌으로써 일주일 24시간 내내 수행되어야 하는 인터넷 서비스나 중요 서비스 업무에 진정 최적이 아니라 할 수 없다. 또한, ZFS는 솔라리스의 실시간 장애 관리 오브젝트로 등록이 되어 있어서, 관리자가 언제든지 화일시스템의 장애를 실시간으로 관리할 수 있게 되어 있다. 결과적으로 이 ZFS는 사용자 관점에 매우 편리한 방식을 제공하게 되는 데, 그런 점이 매력적이었는지 이 ZFS도 애플에 간택이 되어 미래 Mac OSX 버젼에 나타나게 될 전망이다.
썬마이크로시스템즈는 운영체제를 만드는 입장에서 관리자의 작업의 종류와 어려운 수준, 소요 시간등을 고찰해왔는데, 그 결과는 매우 흥미로운 것이었다. 시스템 관리자는 스토리지 관리와 화일 시스템 구축 및 변경, 복구에 매우 많은 시간을 보내고 있었다는 것이다. 그 이유는 zfs 이전의 모든 화일 시스템들은 스토리지/디스크에 문제나 변경이 생기면, 가장 커다란 문제가 발생하기 때문이었다. 서비스는 모두 내려져야 하고, 기존 데이타는 모두 백업/복구되어져야 하며 새로운 디스크/스토리지와 새로운 구성을 하고 나서야 새로운 화일시스템을 구축할 수 있게 되었기 때문이다. 솔라리스 화일 시스템 개발자는 관점의 전환을 이루어 디스크/스토리지가 중심이 아닌 ‘서비스’를 중심인 화일 시스템에 촛점을 두었다. 시스템에 디스크 관련 어떠한 일이 일어나도 서비스는 절대 죽지 않아야 하며, 서비스 가동중에 디스크/스토리지는 얼마든지 추가 및 제거가 가능해야 하며, 얼마든지 이전의 구성으로 되돌아갈 수 있는(undo) 그런 환상적인 화일 시스템을 고려해 보게 되었다. 이런 기능에 가장 근접한 기술이 이미 있었는데 그것은 바로 솔라리스가 메모리를 관리하는 기술이었다. 시스템 사용자들은 메모리를 장착하면서, 메모리를 어떻게 나누어야 할 지, 메모리를 어떻게 구성해야할 지에 대해서는 전혀 신경쓰지 않는다. 운영체제는 전체의 메모리를 하나의 커다란 풀(pool)로 운영하면서 필요한 요청에 대응한다. 이점에 착안하여 새로이 만들어진 화일 시스템이 바로 zfs 화일 시스템이다. ZFS 화일 시스템은 모든 스토리지를 하나의 거대한 풀(Pool)로 구성 운영한다. 구성된 풀에서 필요한 만큼의 화일 시스템을 만들고 변경하며 운영할 수 있도록 하고 있다. 따라서, 새로운 디스크를 추가할때 어떻게 화일 시스템을 나눌지, 파티션을 어떻게 해야할 지에 대해서 고민할 필요가 없어지게 되었다. 풀이 허용하는 한 화일 시스템의 크기는 커졌다 작아졌다를 마음대로 할 수 있으며, 필요에 따라서 특정 상태를 저장(snapshot)을 무한정 해두었다 원하는 상태로 원복(undo)을 할 수 있게 됨에 따라, 이론적으로 풀의 용량이 허용하는 한 백업도 필요가 없게 되었다. 그 뿐만 아니라 ZFS는 데이타는 물론 메타데이타에 대한 첵섬을 유지함으로써 데이타의 장애시 복구율을 혁신적으로 증가시켜놓았다. 즉, 데이타의 장애로 인한 데이타의 분실 자체를 고민할 필요가 없어졌다는 얘기다. 더불어, ZFS는 미러로 구성된 환경에서 한 디스크에 장애가 발생하면 문제없는 디스크로부터 정상적인 데이타를 이용하여 장애가 난 디스크를 치료하는 기능까지 제공함에 따라 백업의 필요성도 덜해졌다. 저가의 스토리지에서는 그야말로 환상적인 궁합이다.
[그림 ZFS 아키텍쳐]
솔라리스 트러스티드 익스텐션
최신 오픈솔라리스 b54 및 썬 솔라리스 업데이트3(11/06)에는 “솔라리스 Trusted Extension(이하, TE)” 이라는 솔라리스의 확장된 보안 기능이 추가되었다. 솔라리스 TE는 선택적으로 구현되는 규칙 기반의 다층구조의 보안 기술이다. 업계중에 유일하게 미국 국방성과의 독자 개발에 따른 결과물로 만들어졌던 Trusted Solaris 8의 기능을 오픈 솔라리스에 구현한 것이다. 이 솔라리스TE가 활성화된 환경은 보안등급 B2에 준하는 등급으로서 LSPP, RBAC를 준수할 뿐 아니라 기존에 DAC[14],MAC[15]로 알려져 있는 보안 정책들을 지원하게 된다. 솔라리스TE에서 제공되는 MAC을 구성하게 되면 모든 문서나 장치들에 대해서 접근자의 보안 등급에 따라 보이는 내용을 다르게 보이게 하거나, 보안 등급에 준하는 내용만 가져가도록 할 수가 있다.
오픈 솔라리스는 이러한 강력한 기능을 통하여 기존의 보안툴이라고 불리던 툴을 굳이 추가할 필요가 없으며, 확장된 감사 및 보고 기능을 통하여 시스템 보안에 위협이 되는 요소들을 검사할 수가 있다.
솔라리스의 성능
운영체제를 논하면서 성능을 논하지 않을 수는 없다. 솔라리스는 오랜 기간 서버용 운영 체제로 많이 사용되면서 안정된 서버로서 작동할 수 있도록 많은 부분의 가감이 있어왔다. 대개 데스크탑을 우선으로 하는 애플리케이션은 사용자 작동에 더 많은 우선 순위할당을 함으로써 백그라운드 모드로 동작하는 서비스에 덜 신경쓰도록 구성이 되어 있는 반면 솔라리스는 상대적으로 백그라운드 서비스에 더 많은 기회를 주도록 구성되어 있다. 이러한 특징은 솔라리스가 네트웍과 스레드 기반의 서비스에 최적화 되어 있음을 쉽게 예상할 수 있는 부분이다.
또한, 서버로서 전원장애나 시스템 장애시 데이타의 손실을 최소화하기 위하여 성능 감소에도 불구하고 쓰지않는 기능들도 있다. 대개 MS사의 Windows 계열의 서버들이나 리눅스는 SCSI 디스크의 경우 Disk 내의 캐쉬를 자동으로 활성화함으로써 디스크 쓰기가 좋아지도록 구성하고 사용하나, 솔라리스는 기본 설치에서는 읽기에 한해서만 구성하고, 쓰기에 대해서는 캐쉬를 사용하지 않도록 함으로써, 전원이상이나 시스템 장애시 데이타의 손실을 최소화하고 있다. 만약 디스크 쓰기 성능을 높이고 싶다면 쓰기 캐쉬를 활성화하는 것이 좋다.[16] 이러한 운영체제를 만드는 몇가지 관점의 차이[17] 때문에 솔라리스는 멀티스레드나 네트웍의 우수성에도 불구하고 리눅스나 MS사의 Windows 계열에 비해 특정 성향에서 성능이 뒤쳐지는 것처럼 생각되어지는 경향이 있다. 그러나, 솔라리스는 시스템을 멈추게 할 만큼 서비스가 더욱 더 몰릴때 그 진가를 발휘한다. 엄청난 부하가 주어진다면 타 운영체제들은 묵묵부답일테지만, 솔라리스는 느리게라도 응답을 할 것이다. 관리자들이 대응할 수 있는 시간을 더 벌어다 주는 것은 당연지사다. 안정된 서비스를 생각한다면 솔라리스를 염두에 둘 필요가 있다.
[그림 솔라리스 버젼간 성능 변화]
오픈 소스 번들
오픈 솔라리스는 다양한 오픈소스 프로젝트를 번들공급하고 있다. 어쩌면 이런 명성있는 오픈 소스 프로젝트와 함께 하기 위해서 솔라리스를 오픈했어야 할 지도 모르는 일이다. 유명한 리눅스의 배포판 처럼 오픈 솔라리스를 설치하게 되면 볼 수 있는 몇가지 유용한 오픈 소스 프로젝트들을 살펴보자.
gcc
두말할 필요없는 오픈 소스계의 대표 컴파일러이다. 지금은 썬에서 솔라리스와 함께 유명한 썬컴파일러가 담겨있는 썬스튜디오[18]를 무상으로 제공하고 있기 때문에 솔라리스에서는 실제적으로 우수한 컴파일러를 두개 가지게 된 셈이다. 솔라리스 애플리케이션 최적화에는 당연지사 썬컴파일러가 더욱 훌륭하기 때문에 가급적이면 썬 컴파일러를 사용하기를 권고하나, 리눅스에서 포팅되는 애플리케이션들은 gcc만이 가지고 있는 확장 기능을 간혹 이용하기 때문에 리눅스 애플리케이션 포팅에서는 gcc를 이용하는 편이 더욱 쉬울 수 있다. gcc는 솔라리스 자체에 번들된 것을 사용하는 것이 좋다. gcc 자체의 버그로 인하여, 썬에서 gcc를 포팅하여 제공한다. gcc가 들어있는 디렉토리는 표준 실행 화일 경로가 아닌 무료 소프트웨어만을 담은 경로 /usr/sfw/bin 에 들어있는 관계로 make를 실행해야 하는 경우에는 PATH=/usr/sfw/bin:$PATH 와 같이 경로에 정의한 후 사용하도록 한다.
mysql
불행하게도 오픈 솔라리스에 들어있는 mysql은 한글 관련 부분이 빠져있다. 오픈 솔라리스내에서 사용하기 위해서는 별도로 한글코드를 지원하는 mysql을 다운받아 설치해야 한다.
postgreSQL
오픈 솔라리스 빌드49에는 PostgreSQL 8.1.4가 번들되어 있다. 한글도 지원할 뿐 아니라, JDBC와 같은 유용한 툴도 들어있다. 오픈 솔라리스 내부적으로 PostgreSQL을 필요하기 때문에 번들된 것으로 보이나, 기존 PostgreSQL 사용자들에게는 매우 반가운 일이 아닐 수 없다. PostgreSQL은 오픈소스 프로젝트에서 가장 활발한 프로젝트이며 리눅스 세계에서는 mysql과 함께 가장 많이 사용되는 객체형 데이타베이스이기 때문이다.
python
오픈 소스 계열에서 많이 사용되는 객체 지향형 스크립트 언어이다. 웹서비스는 물론 다양한 환경에서 적용 및 사용되고 있어서 매우 활발하게 활동하고 있는 오픈소스 프로젝트이다. python 2.4 버젼이 번들되어 있다.
perl
두말할 필요조차 없는 문자열 처리 스크립트 언어이다. 웹서비스용으로 많이 사용되고 있으며, 다양한 종류의 막강한 플러그인과 함께 강력한 활용성을 제공하고 있다. 오픈 솔라리스안에는 몇가지 이유 때문에 여러개의 버젼이 들어가 있는 경우가 있다. 솔라리스 내부 유틸리티가 perl을 이용하기 때문에 그런 것으로 보이며, 오픈 솔라리스 빌드 49에는 Perl 5.6.1과 Perl 5.8.4 두가지가 번들되어 있다. /usr/bin에 설치되어 있는 Perl은 5.8.4로 다른 버젼의 사용이 필요한 경우 Perl Script 상단 경로 설정을 달리해서 사용하는 편이 좋다.
apache1, apache2
솔라리스에는 apache의 두개 버젼이 모두 포함되어 있다. 솔라리스에 들어있는 Apache는 몇가지 특징을 가지고 있다. 일단 apache2 는 솔라리스 서비스 매니전에 등록이 되어 있어서, 솔라리스의 서비스 관리를 받는 구조로 되어 있다. apache2를 실행하고 싶다면 /etc/apache2/httpd.conf 를 구성한 후 #svcadm enable apache2와 같이 단순히 실행하면 apache2의 서버가 동작된다. 반대로 솔라리스에 번들되어 있는 apache2를 정지시키고 싶으면 #svcadm disable apache2와 같이 실행하면 된다. 대개 리눅스 사용자들은 apache와 같은 오픈 소스의 새소스를 가져다와서 컴파일한 후 실행하는 경우가 많은데, 이 때 썬에서 사전 최적화 컴파일을 제공하는 경우보다 나은 경우가 많지 않을 뿐더러, 솔라리스에 들어있는 apache2는 솔라리스만이 가지는 커널내 웹서버 가속 기능[19]을 이용할 수 있도록 튜닝되어 제공이 되고 있다. 따라서, apache2의 경우는 솔라리스내에 번들되어 있는 것을 사용하는 것이 바람직하다.
이 외에도 다양한 오픈소스 유틸리티나 툴들이 /usr/sfw/bin에 포함되어 있다. gcc관련 개발툴이외에도 그래픽툴이라던가 혹은 wget과 같은 인터넷 유틸리티들도 포함되어 있으므로 실행 경로에 넣어 놓도록 하는 것이 유용하다.
오픈 솔라리스 로드맵
현실적으로 오픈 소스 프로젝트에 대한 로드맵이 어떻다고 말하기는 매우 어려운 부분이다. 오픈 소스 프로젝트에 참여하는 사람들이 꾸준히 활발히 활동한다고 말하기는 힘들기 때문이다. 그래서, 그런지 오픈 솔라리스 사이트에는 2007년 1/4분기 해당하는 계획만이 올라와 있다.
- 썬 마이크로시스템즈 김봉환 부장
오픈 솔라리스 - 개발자들의 새로운 신천지
지난 2005년 6월에는 IT 업계에 아주 흥미로운 소식이 있었다. 그것은 IT 인프라스트럭쳐를 위한 하드웨어와 소프트웨어를 공급하고 있는 거대 기업인 썬마이크로시스템즈(이하. 썬)가 자사의 대표 하드웨어에 운용되는 대표 소프트웨어 제품인 운영체제 솔라리스10(Solaris10)의 대부분의 소스코드를 공개했다는 것이다.
1990년대말 이른바 DOT.COM 시대의 대부분의 백엔드 환경을 점유했던 썬의 솔라리스는 지금 우리가 향유하는 인터넷 환경을 주도하는 네트웍 환경에 가장 발전된 운영체제였다. 이러한 발전이 썬의 자만심을 불러있으켰을까? 가정에서 사용되는 개인용 컴퓨터로 일컬어지는 PC가 단순한 클라이언트에서 윈도우즈와 리눅스의 발달에 따라 서버로서의 기능도 가능해지면서 IT 서비스의 세계는 새로운 변화의 물결을 맞이하게 되었다. 특히나, 리눅스의 획기적인 성장은 x86 플랫폼에 신선한 바람을 불어넣기 시작했으며, 이제는 비교적 덜 중요한 업무용으로 많이 사용되게 되었다.
이러한 리눅스가 성장하게 된 가장 기본적인 바탕은 바로 소스가 공개되어 있다는 점에 주목하게 된다. 임의의 불특정 사용자들이 자신의 불편함을 스스로(참다못해?) 수정하게 되다 보니, 현재 엔터프라이즈 운영체제에 상당하는 기능들을 가지게 되었고 직접 참여한 사용자들은 그 자신의 공헌을 외부에 알리게끔 노력하면서 리눅스의 세계는 상당히 성장했다고 볼 수 있다. 개별적으로 보면 볼 것 없어 보이는 사람의 힘이 모이면 역시 위대하다.
썬은 바로 이 부분에 주목했다고 볼 수 있다. 끊임없이 첨단 기술을 개발하여 추가하고자 하려면 엄청난 개발 비용이 들었고, 이렇게 만들어진 솔라리스를 팔기 위해서는 엄청난 마케팅 비용이 또 들었다. 또한 첨단 기술을 개발하는 속도가 오픈 소스 계열보다 점점 처지기 시작했다는 점이다. 물론, 오픈 소스 세계에서는 상상할 수 없는 기능을 개발하기는 하지만 그러한 기능이 시장에서 매력을 가지게 하는데는 또다른 노력이 필요했다. 이런 고찰하에 썬은 자사 지적 재산의 상당한 부분을 차지하는 솔라리스의 소스를 공개하게 이르른다. 이름하여 오픈 솔라리스(http://opensolaris.org).
[오픈 솔라리스 로고]
오픈 솔라리스는 기존의 유닉스 사용자들과 리눅스 사용자들에게 대단한 관심을 불러왔는데, 그 이유는 솔라리스를 보는 관점에 따라 다양했다. 유닉스에 고비용 때문에 리눅스로 이전한 사용자들은 오픈 솔라리스를 통해 다시 솔라리스로 돌아갈 수 있게 된점을 매우 크게 반겼는데 그 이유는 오픈된 솔라리스를 통하여 저비용으로 엔터프라이즈 수준의 운영체제를 사용할 수 있게 되었다는 점이다. 또한 기존의 솔라리스를 사용하던 사용자들은 오픈된 솔라리스의 소스를 통하여 솔라리스의 커널 구조, 디바이스 관리 구조등을 완벽하게 이해하게 됨에 따라 보다 안정된 구조의 솔라리스 환경을 구축할 수 있게 되었으며, 솔라리스의 입증된 소스를 이용하여 구미에 맞는 각종 유틸리티들을 쉽게 구축할 수 있으리라 생각되었기 때문이다.
또한 취약한 보안에 시달려온 리눅스 관리자들에게는 기존 미국방성에서 유일하게 인정받은 보안 기술을 가지고 있는 솔라리스를 무상으로 사용할 수 있게 됨에 따라 전체적으로 혹은 선택적으로 솔라리스를 사용할 수 있게 되었다는 점이다. 아울러, 기존의 리눅스 및 유닉스용 보안툴을 개발해서 제공하던 보안 개발업체들도 솔라리스의 발전된 보안 기술을 참조할 수 있게 되었으며, 보다 향상된 보안 솔루션을 만들어갈 수 있게 되었다.
또한, 활발한 리눅스 혹은 FreeBSD와 같은 오픈소스 개발자들은 솔라리스의 소스코드를 참조하여 한층 나아진 오픈소스를 작성하게 될 수 있게되었다. 특히, 솔라리스10에서 새로이 추가된 독보적인 기능(Dtrace, ZFS)들은 오픈소스 계열의 운영체제 개발자들로 하여금 깊은 관심을 받게 되었고, 그 결과로 MacOS X Leopard 버젼에는 솔라리스10의 Dtrace와 ZFS가 포팅 내장되어 나타나게 되었다.
[그림 MaxOSX Xray(dtrace fontrend)]
이러한 개발자들을 위한 오픈 솔라리스의 특성이외에 법률적인 특징이 하나 있는데, 오픈 솔라리스는 기존의 오픈 소스 라이센스인 BSD 라이센스의 변형인 썬의 새로운 배포 라이센스인 CDDL[2]을 기반으로 소스를 공급하게 되었다. 이는 기존의 GPL 기반의 라이센스와 매우 달라서, GPL은 GPL하의 소스코드를 참고하여 작성된 모든 결과물은 오픈 되어야 하는 반면에 CDDL은 오픈 솔라리스의 소스 코드를 참고해서 작성된 결과물이라 하더라도 그 소스를 오픈할 필요가 없다. 이는 오픈 소스를 기반으로 작성한 애플리케이션을 수출하는 업체들은 매우 유리한 조건이 아닐수 없다. 기존의 GPLv2를 기반의 소스들을 참고해서 만들어 수출했다 GPL 위반 사유로 소송당한 업체들이 점점 증가하는 것으로 보아 오픈 솔라리스의 CDDL은 오픈 소스를 참조해 새로운 솔루션을 개발하는 업체들에 매우 매력적인 배포 라이센스가 아닐 수 없다.
결론적으로 오픈솔라리스를 통하여 기존의 개발자들은 무엇을 얻을 수 있는가? 비록 솔라리스가 데스크탑용의 운영체제는 아니어서 쉽게 다가가기는 어려우나, 아주 오랜기간 네트웍을 염두에 두고 만들어진 운영체제로서 네트웍을 바탕으로 하는 애플리케이션들 개발자에게는 가장 신뢰성있는 참조 구현[3](reference implementation)체로 얻은 셈이다.
때문에 일반 애플리케이션을 개발하는 개발자들에게는 신뢰도 높은 소스 코드를 제공함에 따라 완성도 높은 애플리케이션을 제공할 수 있게 되며, 커널 애플리케이션을 개발하는 개발자들에게는 커널의 모든 코드를 볼 수 있게 됨에 따라 보다 대표적인 유닉스의 내부 구조를 이해할 수 있게되어 안정적인 커널 코드를 빠르게 구축할 수 있게 되었다.
또한, 리눅스 운영체제의 큰 특징은 매우 많은 임의의 자원 코딩 봉사자들에 의해서 구성된다는 것인데, 이런 경우에는 코드의 안정성을 확보하는 것이 매우 어렵다. 따라서, 리눅스는 독특하게 ‘안정판(stable edition)’이라던가 ‘베타판(development release)’라던가 하는 등의 다양한 릴리즈와 이러한 릴리즈를 테스트해서 제공되는 다양한 배포판 업체가 난립하게 되는 데, 기술의 발전 측면에서는 좋을 지 모르나, 특정 솔루션을 개발하는 개발자 입장에서는 이러한 수많은 릴리즈와 배포판의 난립이 결코 행복한 것만은 아니다. 어디를 기준을 두고 호환성을 유지할 것인지가 난감하기 때문이다. 실행 화일 면에서는 모든 리눅스에서 돌아야 함에도 불구하고, 패키지의 차이(패키징 방식, 포함된 라이브러리등) 때문에 어떤 배포판에서는 수행될 수도 있고 안될 수도 있는 일이 발생하기 때문이다. 반면, 솔라리스는 기존의 어느 수준이상 완성되어 있는 코드위에서 확장하면서 호환성을 유지하도록 프로젝트 커뮤니티의 통제가 있기 때문에 매 릴리즈 끼리의 새로운 기술을 보충해나가면서도 호환성을어느 정도 유지할 수 있도록 운영이 되고 있다. 물론, 현재는 3-4개 정도의 오픈 솔라리스 배포판이 더욱 많이 늘어나게 되면 현재의 리눅스와 같은 문제가 없으리라고 보장하기는 힘들것이나 리눅스 계열보다 적을 것은 확실하다.
오픈 솔라리스는 썬에서 공급하는 3개의 배포판을 제외하고 현재 4개의 배포판[4]이 제공되고 있다. 썬에서는 Solaris Express, Solaris Express Community Release, Sun Solaris로서 Solaris Express Community Release가 OpenSolaris 를 바탕으로 만드는 가장 최신 빌드이며 업데이트 서비스가 없는 무상 제품이다. 반면, 여기에 업데이트 서비스를 제공하는 배포판은 Solaris Express에 해당되며, 이 최신 빌드를 기반으로 썬의 추가 테스트와 별도 소프트웨어 패키지를 추가한 배포판이 Sun Solaris 가 되는 셈이다.
썬이외에 공급되고 있는 배포판중 현재 가장 왕성한 활동을 하는 배포판은 NexentaOS로서 커널과 주요 실행 화일만을 가지며 완전히 오픈소스 기반의 GUI와 데비안 패키징 시스템을 제공함으로써 기존의 데비안 패키징을 사용하는 리눅스를 경험한 리눅스 고객들에겐 거의 차이없는 인터페이스를 제공함으로써 매우 빠르게 적응할 수 있는 버젼이다. 오픈 솔라리스 배포판중 가장 깊은 주시를 받고 있는 버젼이라고 할 수 있겠다.
[그림 nexentaOS 화면 ]
이렇게 기존 개발자들에게 깊은 관심을 이끌어낸 오픈 솔라리스의 최신 기능을 볼 필요가 있겠다.
최강의 네트웍 서비스를 제공하는 오픈 솔라리스의 커널 : SunOS 5.10
오픈 솔라리스의 커널은 SunOS로 명명되어져 있다. 레드햇이나 수세 리눅스의 커널이 Linux로 나오는 것과 같은 개념이라고 할 수 있다. 현재에 이르는 SunOS 5.11은 최신 솔라리스 10의 기본이 되는 커널 버젼으로 네트웍 서비스, 분산 컴퓨팅, SMP & NUMA, 멀티코어와 같은 최신 기술 모두에 최적화 되어 있는 유닉스 서버중 가장 진보된 커널이라고 자타가 인정하고 있다. 특히, 솔라리스는 아주 이른 시기부터 멀티코어에 최적화되어 있으며, 심지어 AMD의 옵테론이 구성하는 NUMA 비슷한 구조에서도 최적화되어 있다. 최신 하드웨어 기술에 가장 잘 맞추어져 있는 운영체제인 셈이다.
[그림 Solaris/SunOS 히스토리]
솔라리스는 컴퓨팅 이론을 구현하는 데 많은 공을 들였으며 이러한 노력으로 하여금 솔라리스의 명성이 유지되었다고 볼 수 있으며 솔라리스 10과 오픈 솔라리스 이후 그러한 솔라리스의 사고와 기술은 다른 운영체제에도 영향을 주고 있다.
솔라리스의 커널은 특히, SMP[7] 시스템에 가장 최적화 되어 있는 운영체제로 알려져 있으며 실제로 썬마이크로시스템즈는 업계에서 유일하게 최대 144개의 CPU 코어를 가지고 있는 단일 박스(SMP)를 솔라리스와 함께 제공하고 있다. 많은 CPU를 운영할 수 있다는 것은 커널 자체의 병렬화가 매우 잘되어 있음을 의미하는 것이다. 때문에 솔라리스는 매우 우수한 멀티스레드 하부 시스템을 제공하고 있다. 웹서버와 같은 인터넷 서비스들은 대개 멀티스레드를 이용해서 작동되도록 구성되는 것이 최신 흐름임을 비추어 보면, 솔라리스가 인터넷 서비스에 매우 적합함을 쉽게 예측할 수 있다.
솔라리스 커널의 특징을 간략하게 요약하면 다음과 같다.[8]
- 시스템 콜 인터페이스- 모든 유닉스 및 유사 운영체제가 그렇듯이 모든 사용자 프로세스는 커널과 커뮤니케이션하기 위해서 시스템 콜을 써야한다.
- 프로세스 관리와 스케쥴링 -프로세스의 생성,실행,관리, 종료등 모든 프로세스/스레드 관련 행위를 관리하며, 스케쥴러는 이러한 스레드의 우선순위 기반의 스케쥴링을 지원한다. 완벽한 우선순위 기반의 사전 스케쥴링 (preemption)을 지원함으로서 실시간 애플리케이션을 지원한다.
- 가상 메모리 시스템-가상메모리 시스템을 만들어 실제 메모리를 사용자 프로세스와 커널에 제공한다. 솔라리스 메모리 관리는 크게 두개의 계층으로 구분된다. 하나는 공통 메모리 관리 계층과 하드웨어 지원 계층으로 나뉜다.
- 화일 시스템 인터페이스 - 솔라리스는 가상 파일 시스템 프레임웍을 구현한다. 때문에 다양한 종류의 화일 시스템(ufs,nfs,hsfs,specfs,procfs,sockfs 등등)이 가상 화일 시스템 내부에 장착되어서 사용자는 모든 형태의 화일 시스템을 일관된 방법으로 접근, 제어할 수 있도록 한다.
- 구조적 I/O 버스와 장치 관리 - 솔라리스 I/O 프레임웍은 버스를 중심으로 연계되어 있는 장치를 구조적으로 (hiercarchical) 관리하도록 되어있다.
- 네트워킹 – TCP/IP 프로토콜 관련 기능을 지원한다. SunOS 5.10이후 부터는 이전 커널과 달리 TCP와 IP의 드라이버를 단일 드라이버로 통합함으로서 레이어간 발생할 수 있는 지연시간을 단축했다.
[그림 솔라리스 커널 인터페이스]
오픈 솔라리스의 주요 기능
위와 같은 SunOS 5.10을 기반으로 작성되어진 썬솔라리스 최신 배포판은 매우 많은 신기능들을 가지고 있는데 그 중에 커널과 관련이 있는 기능 중에는 크게 다음과 같은 기능이 있다.
- 자가 치유 기능
- 솔라리스 서비스 관리
- 솔라리스 장애 관리
- 솔라리스 존(가상서버)
- 동적 자원 풀
- 동적 트레이싱 툴(DTrace)
- 프로세스 권한 관리
- 솔라리스 보안 확장셋 (Trusted Extension)
- ZFS
그외 추가 이전 솔라리스 버젼대비 솔라리스10의 새로운 기능에 대해서는 이곳(http://www.sun.com/software/solaris/whats_new.jsp) 을 참조하길 바란다.
솔라리스 장애 관리, 서비스 관리 기능과 자가 치유 기능
솔라리스의 자가 치유 기능은 기술적으로 솔라리스 서비스 관리 기능과 솔라리스 장애 관리 기능의 구현으로 인해 저절로 생기게 된 솔라리스의 기능이라고 볼 수 있다. 솔라리스 장애 관리자는 솔라리스 내에 구성된 장애 감시 오브젝트들에 실시간으로 감시하다가 장애 발생시 이에 대한 통보와 조치를 취하게 되는데, 이때 부연으로 발생하는 서비스 장애에 대응할 수 있도록 생긴 기능이 솔라리스 서비스 관리 기능이다. 예를 들어, 특정 CPU에 장애가 발생해서 운영체제가 그 CPU를 offline 시켜야 하는 경우. 강제 오프라인을 시키게 되면 그 CPU에서 동작하던 애플리케이션은 우선 정지되어진다. 이때 서비스 매니저는 정지된 해당 서비스를 새로이 동작하게 지원해줌으로써 서비스는 자동으로 복구되게 됨으로 기존의 시스템과 서비스의 가용성을 크게 늘릴 수 있게 된다. 설사 서비스가 죽었다 하더라도 빠르게 서비스를 재가동할 수 있도록 지원함으로써 관리자는 서비스 중지에 따른 피해를 최소화할 수 있다.
다음은 장애를 실시간 보고해주는 예이다.
[그림 fmstat]
솔라리스의 가상화와 존(솔라리스 컨테이너)
썬 마이크로시스템즈는 최신 경향에 걸맞게 다양한 형태의 가상화 기법을 하드웨어,소프트웨어에 제시하고 있다. 썬의 최신예 멀티코어를 가진 SPARC기반의 하드웨어에는 LDom이라는 논리적 기법의 파티션 기능을 추가하고 있다. 이는 하나의 박스를 여러개의 박스가 있는 것처럼 분리해주며, 각각의 영역에 새로운 운영체제를 설치할 수 있도록 하는 기술이다. 기존의 IBM의 LPAR와 매우 흡사한 기능을 제공하고 있다. 그러나, 이 기능은 아직은 썬의 하드웨어 제품에서만 구현이 가능하다.
이와 함께 제공되는 솔라리스의 존은 최근 강력해진 하드웨어의 성능을 배경으로 불고 있는 가상화 기술의 일종이다. 흔히들 알려져 있는 가상화 대표주자인 vmware의 방식과는 달리, 게스트 영역에 별도의 운영체제를 사용하지 않고 호스트 운영체제를 빌려쓰는 기법을 사용한다. 기술적으로는 운영체제는 그냥 하나이면서, 마치 여러개가 있는 것처럼 보이도록 하는 자원관리 기능을 확장한 기술에 기반한 가상화 기법이다.[10]
이 기법은 vmware가 가지고 있는 오버헤드를 완전하게 없앰으로써 동일 운영시스템 혹은 다른 버젼의 동일 운영 시스템에서 서비스할 수 있는 애플리케이션들을 가상화 영역으로 분리함으로써 하드웨어 활용율을 극대화할 수 있음은 물론 각 가상화 영역별 관리의 독립과 보안성 개선, 안정성 개선등을 이루어 낼 수 있다. 기존에 단일 솔라리스 영역에 웹서버, DB 서버, 웹 애플리케이션 서버들을 한번에 설치해서 사용했다면 존을 이용하여 각각을 분리함으로써 용도별 분할 관리가 가능해지고 더 쉬어질 뿐 아니라, 전체적인 관리의 효율성이 증가하고 관리에 들어가는 시간도 낮출 수 있게 되었다.
또한, 오픈 솔라리스 build 49에는 x86 솔라리스만을 위한 존 기능이 추가되어 있는데, 존 영역에 솔라리스 버젼 뿐만아니라 32비트 레드햇 계열의 리눅스도 설치할 수 있게 되었다[11]. 이 기능으로 하여금, 인텔이나 AMD에 설치된 솔라리스안에는 32비트 리눅스도 함께 설치해서 운영할 수 있게 되어서[12], 솔라리스로 이동하려는 관리자나, 리눅스의 애플리케이션이 어떻게 동작하는 지를 솔라리스의 Dtrace로 추적해보고 싶은 개발자들이 좋아할 수 있겠다.
[그림 솔라리스 컨테이너/리눅스(Branz)]
동적 자원 관리 풀
솔라리스는 풀(pool)개념을 도입하여 자원을 관리할 수 있는 기능을 제공하고 있는데, 필요한 작업(project, task, zone)에 필요한 양만큼의 자원(CPU, 메모리)등을 동적으로 할당해서 사용할 수 있도록 해준다. 즉 특정 프로젝트나 업무를 만들어서 그 영역에 필요한 만큼 할당해서 사용하고 필요없으면 자원을 동적으로 조절할 수 있도록 하는 것이다. 존도 기술적으로는 일련의 업무(project)의 모임이므로 동적 자원의 관리 대상이다. 오픈 솔라리스에는 이러한 동적 자원 관리가 한층 지능화되어서 CPU 사용율에 따라 CPU의 자동 추가등과 같은 것을 구성할 수 있다.
동적 시스템 추적 툴(Dtrace)
솔라리스10에 처음으로 추가된 동적 추적 툴인 Dtrace는 그야말로 IT업계에 커다란 충격을 줬다. 기존의 제공되던 사후추적 툴의 한계를 벗어나서 실시간으로 이벤트 중심의 동적 추적을 업계에서 최초로 구현한 툴인 셈이다.
모든 운영체제에서 그렇듯이 정상적인 경우에는 문제가 없다. 비정상적인 경우에 문제가 발생하며 이러한 경우는 예측하지 못한 경우에 발생하므로 업무가 죽은 이후에 비정상적인 경우를 재생, 추적하기란 정말 쉽지 않은 것이다. 이때 Dtrace는 예상된 영역에 덫을 놓듯이 덫을 놓아서 특정 이벤트가 실행되게 되면 보고할 수 있도록 한다. 이 기술을 이용하여 솔라리스 커널 자체의 버그, 시스템 튜닝, 애플리케이션의 메모리 릭(memory leak)이나 병목등을 예전과 달리 훨씬 손쉽게 추적할 수 있게 되었으며, 이와 함께 솔라리스10 자체의 품질도 향상되게 되었다.
Dtrace는 그 기능에서 이미 많은 타 운영체제 개발자들에게 영감을 주었으며, 애플사는 이 Dtrace의 기능을 MaxOSX의 개발버젼에 해당하는 Machintosh OSX Leopard 버젼에 Xcode에 포팅,추가해놓은 것만을 보아도 얼마나 훌륭한 기능인지 가히 짐작할 수 있다. 설명했던 바와 마찬가지로 Dtrace는 커널 중심이 아니라 프로세서 중심 혹은 데이타 중심 혹은 사용자 중심인 객체 지향적 기술 처리의 흐름을 파악함으로써 비정상 문제를 야기하는 근본적인 원인을 빠르게 추적할 수 있다.
[그림 dtrace 개념도 ] [그림 dtrace chime 2 & prstat ]
프로세스 권한 관리
전통적인 유닉스 계열에서는 root 즉, 수퍼유저이면 모든 것을 할 수가 있었다. 실제로 수퍼유저는 특정 업무를 위해서만 사용되어야 함에도 많은 곳에서 root를 노출해 사용하거나 공유하는 경우가 발생한다. 이렇게 되면 시스템은 보안에 매우 취약해질 수 밖에 없다. 솔라리스는 기본적으로 root가 할 수 있는 모든 업무들을 일정한 범주의 역할로 구분하고 사용자들에게 역할을 할당함으로써 root로 해야하는 업무를 일반 사용자로 수행하면서도 동시에 root가 할 수 있는 실수[13]를 원천적으로 방지할 수 있으며, 이러한 시스템을 사용함으로써 실질적인 root 사용자를 완전히 없애버릴 수도 있다. 이 기능은 솔라리스 하부에 있는 RBAC과 함께 이용되어 특정 프로세스에 대해서 권한을 조정할 수도 있으며, 특정 사용자 혹은 특정 역할에 대해서 권한을 조정할 수 있게 됨으로써 한층 강화된 보안과 관리가 가능해진다.
ZFS - 지구상의 마지막 화일 시스템
썬 마이크로시스템즈가 솔라리스를 오픈하기 이전부터 해결하고자 하려 했던 프로젝트가 하나 있었는데, 그건 바로 솔라리스가 기본적으로 사용하는 화일 시스템인 UFS를 대체할 만한 화일 시스템을 만드는 것이었다. 이 프로젝트는 오랜 검토와 코딩 그리고 테스트를 거쳐서 나오게 되었는데, 마침 나오자 마자 오픈되어 있던 솔라리스와 함께 오픈 소스의 세계에서 모습을 나타내게 되었다.
이러한 ZFS는 시스템 관리자의 디스크/스토리지 관리에 들어가는 수고를 대폭 줄여주면서도 서비스 장애 및 데이타 발생율을 현격하게 낮춰줌으로써 일주일 24시간 내내 수행되어야 하는 인터넷 서비스나 중요 서비스 업무에 진정 최적이 아니라 할 수 없다. 또한, ZFS는 솔라리스의 실시간 장애 관리 오브젝트로 등록이 되어 있어서, 관리자가 언제든지 화일시스템의 장애를 실시간으로 관리할 수 있게 되어 있다. 결과적으로 이 ZFS는 사용자 관점에 매우 편리한 방식을 제공하게 되는 데, 그런 점이 매력적이었는지 이 ZFS도 애플에 간택이 되어 미래 Mac OSX 버젼에 나타나게 될 전망이다.
썬마이크로시스템즈는 운영체제를 만드는 입장에서 관리자의 작업의 종류와 어려운 수준, 소요 시간등을 고찰해왔는데, 그 결과는 매우 흥미로운 것이었다. 시스템 관리자는 스토리지 관리와 화일 시스템 구축 및 변경, 복구에 매우 많은 시간을 보내고 있었다는 것이다. 그 이유는 zfs 이전의 모든 화일 시스템들은 스토리지/디스크에 문제나 변경이 생기면, 가장 커다란 문제가 발생하기 때문이었다. 서비스는 모두 내려져야 하고, 기존 데이타는 모두 백업/복구되어져야 하며 새로운 디스크/스토리지와 새로운 구성을 하고 나서야 새로운 화일시스템을 구축할 수 있게 되었기 때문이다. 솔라리스 화일 시스템 개발자는 관점의 전환을 이루어 디스크/스토리지가 중심이 아닌 ‘서비스’를 중심인 화일 시스템에 촛점을 두었다. 시스템에 디스크 관련 어떠한 일이 일어나도 서비스는 절대 죽지 않아야 하며, 서비스 가동중에 디스크/스토리지는 얼마든지 추가 및 제거가 가능해야 하며, 얼마든지 이전의 구성으로 되돌아갈 수 있는(undo) 그런 환상적인 화일 시스템을 고려해 보게 되었다. 이런 기능에 가장 근접한 기술이 이미 있었는데 그것은 바로 솔라리스가 메모리를 관리하는 기술이었다. 시스템 사용자들은 메모리를 장착하면서, 메모리를 어떻게 나누어야 할 지, 메모리를 어떻게 구성해야할 지에 대해서는 전혀 신경쓰지 않는다. 운영체제는 전체의 메모리를 하나의 커다란 풀(pool)로 운영하면서 필요한 요청에 대응한다. 이점에 착안하여 새로이 만들어진 화일 시스템이 바로 zfs 화일 시스템이다. ZFS 화일 시스템은 모든 스토리지를 하나의 거대한 풀(Pool)로 구성 운영한다. 구성된 풀에서 필요한 만큼의 화일 시스템을 만들고 변경하며 운영할 수 있도록 하고 있다. 따라서, 새로운 디스크를 추가할때 어떻게 화일 시스템을 나눌지, 파티션을 어떻게 해야할 지에 대해서 고민할 필요가 없어지게 되었다. 풀이 허용하는 한 화일 시스템의 크기는 커졌다 작아졌다를 마음대로 할 수 있으며, 필요에 따라서 특정 상태를 저장(snapshot)을 무한정 해두었다 원하는 상태로 원복(undo)을 할 수 있게 됨에 따라, 이론적으로 풀의 용량이 허용하는 한 백업도 필요가 없게 되었다. 그 뿐만 아니라 ZFS는 데이타는 물론 메타데이타에 대한 첵섬을 유지함으로써 데이타의 장애시 복구율을 혁신적으로 증가시켜놓았다. 즉, 데이타의 장애로 인한 데이타의 분실 자체를 고민할 필요가 없어졌다는 얘기다. 더불어, ZFS는 미러로 구성된 환경에서 한 디스크에 장애가 발생하면 문제없는 디스크로부터 정상적인 데이타를 이용하여 장애가 난 디스크를 치료하는 기능까지 제공함에 따라 백업의 필요성도 덜해졌다. 저가의 스토리지에서는 그야말로 환상적인 궁합이다.
[그림 ZFS 아키텍쳐]
 |
솔라리스 트러스티드 익스텐션
최신 오픈솔라리스 b54 및 썬 솔라리스 업데이트3(11/06)에는 “솔라리스 Trusted Extension(이하, TE)” 이라는 솔라리스의 확장된 보안 기능이 추가되었다. 솔라리스 TE는 선택적으로 구현되는 규칙 기반의 다층구조의 보안 기술이다. 업계중에 유일하게 미국 국방성과의 독자 개발에 따른 결과물로 만들어졌던 Trusted Solaris 8의 기능을 오픈 솔라리스에 구현한 것이다. 이 솔라리스TE가 활성화된 환경은 보안등급 B2에 준하는 등급으로서 LSPP, RBAC를 준수할 뿐 아니라 기존에 DAC[14],MAC[15]로 알려져 있는 보안 정책들을 지원하게 된다. 솔라리스TE에서 제공되는 MAC을 구성하게 되면 모든 문서나 장치들에 대해서 접근자의 보안 등급에 따라 보이는 내용을 다르게 보이게 하거나, 보안 등급에 준하는 내용만 가져가도록 할 수가 있다.
오픈 솔라리스는 이러한 강력한 기능을 통하여 기존의 보안툴이라고 불리던 툴을 굳이 추가할 필요가 없으며, 확장된 감사 및 보고 기능을 통하여 시스템 보안에 위협이 되는 요소들을 검사할 수가 있다.
솔라리스의 성능
운영체제를 논하면서 성능을 논하지 않을 수는 없다. 솔라리스는 오랜 기간 서버용 운영 체제로 많이 사용되면서 안정된 서버로서 작동할 수 있도록 많은 부분의 가감이 있어왔다. 대개 데스크탑을 우선으로 하는 애플리케이션은 사용자 작동에 더 많은 우선 순위할당을 함으로써 백그라운드 모드로 동작하는 서비스에 덜 신경쓰도록 구성이 되어 있는 반면 솔라리스는 상대적으로 백그라운드 서비스에 더 많은 기회를 주도록 구성되어 있다. 이러한 특징은 솔라리스가 네트웍과 스레드 기반의 서비스에 최적화 되어 있음을 쉽게 예상할 수 있는 부분이다.
또한, 서버로서 전원장애나 시스템 장애시 데이타의 손실을 최소화하기 위하여 성능 감소에도 불구하고 쓰지않는 기능들도 있다. 대개 MS사의 Windows 계열의 서버들이나 리눅스는 SCSI 디스크의 경우 Disk 내의 캐쉬를 자동으로 활성화함으로써 디스크 쓰기가 좋아지도록 구성하고 사용하나, 솔라리스는 기본 설치에서는 읽기에 한해서만 구성하고, 쓰기에 대해서는 캐쉬를 사용하지 않도록 함으로써, 전원이상이나 시스템 장애시 데이타의 손실을 최소화하고 있다. 만약 디스크 쓰기 성능을 높이고 싶다면 쓰기 캐쉬를 활성화하는 것이 좋다.[16] 이러한 운영체제를 만드는 몇가지 관점의 차이[17] 때문에 솔라리스는 멀티스레드나 네트웍의 우수성에도 불구하고 리눅스나 MS사의 Windows 계열에 비해 특정 성향에서 성능이 뒤쳐지는 것처럼 생각되어지는 경향이 있다. 그러나, 솔라리스는 시스템을 멈추게 할 만큼 서비스가 더욱 더 몰릴때 그 진가를 발휘한다. 엄청난 부하가 주어진다면 타 운영체제들은 묵묵부답일테지만, 솔라리스는 느리게라도 응답을 할 것이다. 관리자들이 대응할 수 있는 시간을 더 벌어다 주는 것은 당연지사다. 안정된 서비스를 생각한다면 솔라리스를 염두에 둘 필요가 있다.
[그림 솔라리스 버젼간 성능 변화]
 |
오픈 소스 번들
오픈 솔라리스는 다양한 오픈소스 프로젝트를 번들공급하고 있다. 어쩌면 이런 명성있는 오픈 소스 프로젝트와 함께 하기 위해서 솔라리스를 오픈했어야 할 지도 모르는 일이다. 유명한 리눅스의 배포판 처럼 오픈 솔라리스를 설치하게 되면 볼 수 있는 몇가지 유용한 오픈 소스 프로젝트들을 살펴보자.
gcc
두말할 필요없는 오픈 소스계의 대표 컴파일러이다. 지금은 썬에서 솔라리스와 함께 유명한 썬컴파일러가 담겨있는 썬스튜디오[18]를 무상으로 제공하고 있기 때문에 솔라리스에서는 실제적으로 우수한 컴파일러를 두개 가지게 된 셈이다. 솔라리스 애플리케이션 최적화에는 당연지사 썬컴파일러가 더욱 훌륭하기 때문에 가급적이면 썬 컴파일러를 사용하기를 권고하나, 리눅스에서 포팅되는 애플리케이션들은 gcc만이 가지고 있는 확장 기능을 간혹 이용하기 때문에 리눅스 애플리케이션 포팅에서는 gcc를 이용하는 편이 더욱 쉬울 수 있다. gcc는 솔라리스 자체에 번들된 것을 사용하는 것이 좋다. gcc 자체의 버그로 인하여, 썬에서 gcc를 포팅하여 제공한다. gcc가 들어있는 디렉토리는 표준 실행 화일 경로가 아닌 무료 소프트웨어만을 담은 경로 /usr/sfw/bin 에 들어있는 관계로 make를 실행해야 하는 경우에는 PATH=/usr/sfw/bin:$PATH 와 같이 경로에 정의한 후 사용하도록 한다.
mysql
불행하게도 오픈 솔라리스에 들어있는 mysql은 한글 관련 부분이 빠져있다. 오픈 솔라리스내에서 사용하기 위해서는 별도로 한글코드를 지원하는 mysql을 다운받아 설치해야 한다.
postgreSQL
오픈 솔라리스 빌드49에는 PostgreSQL 8.1.4가 번들되어 있다. 한글도 지원할 뿐 아니라, JDBC와 같은 유용한 툴도 들어있다. 오픈 솔라리스 내부적으로 PostgreSQL을 필요하기 때문에 번들된 것으로 보이나, 기존 PostgreSQL 사용자들에게는 매우 반가운 일이 아닐 수 없다. PostgreSQL은 오픈소스 프로젝트에서 가장 활발한 프로젝트이며 리눅스 세계에서는 mysql과 함께 가장 많이 사용되는 객체형 데이타베이스이기 때문이다.
python
오픈 소스 계열에서 많이 사용되는 객체 지향형 스크립트 언어이다. 웹서비스는 물론 다양한 환경에서 적용 및 사용되고 있어서 매우 활발하게 활동하고 있는 오픈소스 프로젝트이다. python 2.4 버젼이 번들되어 있다.
perl
두말할 필요조차 없는 문자열 처리 스크립트 언어이다. 웹서비스용으로 많이 사용되고 있으며, 다양한 종류의 막강한 플러그인과 함께 강력한 활용성을 제공하고 있다. 오픈 솔라리스안에는 몇가지 이유 때문에 여러개의 버젼이 들어가 있는 경우가 있다. 솔라리스 내부 유틸리티가 perl을 이용하기 때문에 그런 것으로 보이며, 오픈 솔라리스 빌드 49에는 Perl 5.6.1과 Perl 5.8.4 두가지가 번들되어 있다. /usr/bin에 설치되어 있는 Perl은 5.8.4로 다른 버젼의 사용이 필요한 경우 Perl Script 상단 경로 설정을 달리해서 사용하는 편이 좋다.
apache1, apache2
솔라리스에는 apache의 두개 버젼이 모두 포함되어 있다. 솔라리스에 들어있는 Apache는 몇가지 특징을 가지고 있다. 일단 apache2 는 솔라리스 서비스 매니전에 등록이 되어 있어서, 솔라리스의 서비스 관리를 받는 구조로 되어 있다. apache2를 실행하고 싶다면 /etc/apache2/httpd.conf 를 구성한 후 #svcadm enable apache2와 같이 단순히 실행하면 apache2의 서버가 동작된다. 반대로 솔라리스에 번들되어 있는 apache2를 정지시키고 싶으면 #svcadm disable apache2와 같이 실행하면 된다. 대개 리눅스 사용자들은 apache와 같은 오픈 소스의 새소스를 가져다와서 컴파일한 후 실행하는 경우가 많은데, 이 때 썬에서 사전 최적화 컴파일을 제공하는 경우보다 나은 경우가 많지 않을 뿐더러, 솔라리스에 들어있는 apache2는 솔라리스만이 가지는 커널내 웹서버 가속 기능[19]을 이용할 수 있도록 튜닝되어 제공이 되고 있다. 따라서, apache2의 경우는 솔라리스내에 번들되어 있는 것을 사용하는 것이 바람직하다.
이 외에도 다양한 오픈소스 유틸리티나 툴들이 /usr/sfw/bin에 포함되어 있다. gcc관련 개발툴이외에도 그래픽툴이라던가 혹은 wget과 같은 인터넷 유틸리티들도 포함되어 있으므로 실행 경로에 넣어 놓도록 하는 것이 유용하다.
오픈 솔라리스 로드맵
현실적으로 오픈 소스 프로젝트에 대한 로드맵이 어떻다고 말하기는 매우 어려운 부분이다. 오픈 소스 프로젝트에 참여하는 사람들이 꾸준히 활발히 활동한다고 말하기는 힘들기 때문이다. 그래서, 그런지 오픈 솔라리스 사이트에는 2007년 1/4분기 해당하는 계획만이 올라와 있다.
맺음말
아직도 100명 이상이 근무하는 엔터프라이즈 기업에서는 백엔드 시스템의 상당부분을 썬의 하드웨어와 솔라리스를 사용하는 곳이 매우 많다. 이렇게 기간 시스템의 주요 운영체제로 사용되는 솔라리스의 소스가 공개되었다는 것은 매우 고무적인 일이 아닐 수 없다. 이러한 변화를 실감하지 못하는 이들도 있으나, 이것은 1995년 말에 자바가 발표된 것이상의 커다란 의미를 지닌다. 어쩌면 썬의 가장 마지막 정신적 보루를 모든 이들에 내놓은 셈이다. 많은 이들이 솔라리스 소스를 보기 위해서 오픈 솔라리스 사이트를 방문할 것이고, 어떤 부분에서는 훌륭하다고 감탄할 수도 있고, 어떤 부분에서는 막상 보니까 실망이라고 할 수도 있을 것이다. 마치 지금의 상황은 썬이 모든 사람들에게 자기의 벌거벗은 모습을 모두 까발려 놓은 듯한 입장으로 지켜보고 있는 것이 아닌가 하는 느낌이다.
이러한 솔라리스 공개는 썬 스스로에게도 커다란 자극제가 될 것이고, 이를 선망하던 혹은 배척하던 이들에게 조차도 미래를 어떻게 가야할 지에 대한 나침반 역할을 하게 될 것으로 보인다.
[1] 기존 인텔이 제작해온 CPU나 그 호환 제품을 탑재한 PC 혹은 서버를 대개 x86이라고 지칭한다. 반면에 AMD가 제작한 64bit 옵테론 계열과 EM64T를 채택한 인텔 Xeon 계열의 CPU를 탑재한 서버를 x64로 지칭한다.
[3] 코드 작성이 기능 수행이 검증된 완성된 참조용 코드
[4] http://www.opensolaris.org/os/downloads/
[5] 오픈 솔라리스는 5.11로 되어있다. 특별한 의미는 없으며 현 솔라리스 패키지가 가지고 있는 버젼 5.10보다 앞선 버젼이란 의미를 지닌다.
[6]리눅스 같은 경우에는 멀티코어를 인식하고 별도로 처리하는 개념의 적용이 아주 미약하다.
[7] SMP:Symmetric Multi Processing
[8] Solaris Internals 2nd Edition 참조
[9] Solaris Inters 2nd Edition – Kernel Overview 참조
[10] 공개 소프트웨어에서 솔라리스의 컨테이너(존) 기법을 흉내내서 만든 기술도 이미 나와있다. OpenVZ 참조
[11] 오픈 솔라리스 프로젝트 이름으로는 브랜즈(Brandz)라고 명명되어 있다.
[12] 리눅스 커널은 설치되지 않으면 리눅스 애플리케이션의 인스트럭션을 솔라리스 존이 실시간 변환해서 실행하는 구조를 가진다. 변환에 들어가는 오버헤드는 매우 작아서 어떤 경우 존에 설치된 리눅스의 애플리케이션이 리눅스에서 동작하는 것보다 더 빠른 경우가 보고된 바 있다.
[13] 전통적으로 root 유저가 흔히 하는 실수는 / 디렉토리에서 rm *을 실행하는 일이다.
[14] DAC:Discretionary Access Control. 소유권자의 권한으로 접근 권한을 설정하는 규칙
[15]MAC:Mandatory Access Control 레이블 기간의 접근 권한을 설정하는 규칙
[16]#format -e 를 실행해서 원하는 SCSI 디스크를 선택한 후 cache를 선택하면 read/write cache를 활성시킬 수 있다.
[17]대개 화일 시스템용 캐쉬로 활용하는 크기의 차이가 있다. 특히, 솔라리스x86/x64 시스템에서는 /etc/system 내에 set segmapsize=
반응형
'[OS] > Embedded&Linux' 카테고리의 다른 글
| [ MySQL 설치/사용시 나는 에러 유형별 대처방법 ] (0) | 2007.08.20 |
|---|---|
| solaris boot_archive 깨진 경우 복구 방법 (0) | 2007.08.20 |
| [명령어] dtrace로 실시간 IO 체크 - Solaris 10 - (0) | 2007.08.17 |
| svn-howto (0) | 2007.08.15 |
| Status of C99 features in GCC 4.2 (0) | 2007.08.14 |