2011/12/05

솔라리스 11이 발표가 되면서 기존 솔라리스 10과의 차이를 비교한 문서가 있군요.

Oracle Solaris 10 Compared to Oracle Solaris 11 - Transitioning From Oracle Solaris 10 to Oracle Solaris 11

뭐랄까 짜투리 존재하던 상당한 서비스 및 패키지들을 과감하게 버려버린 흔적이 여지없이 보이는 군요. 

몇가지를 들어보면

CDE의 완전 퇴출

오픈 솔라리스에서 예측되었던 거지만 좀 아쉽군요. 한때 IBM, HP, SGI등과 협심해서 MS의 윈도우에 대응하겠다고 만들었던, 나름 중원의 강자들이 최초로 단일화해서 상당히 오랜 기간 유지되었던 윈도우 환경이었는데 말이죠. 이때 단일화하지 말고, 그냥 오픈윈도우를 준수했더라면 어땠을까 하는 상념도 드는 군요.

UFS의 부팅 및 기본 화일 시스템에서 퇴출

그래도 ZFS 볼륨위에서 UFS를 만들 수는 있을 테므로 UFS 화일 시스템 자체는 더 존속하지 않을 까 싶습니다.

점프스타트 기능의 변화 : Automated Installer

이름이 참 오라클스럽다는 생각을 해봅니다. 느낌은 콩글리쉬라고나 할까... 

네트웍 구성의 변경 

가장 눈에 뜨이는 항목인데요. 네트웍은 자동 구성시때에는 netcfg를 사용하고 매뉴얼 구성때에는 dladm과 ipadm을 사용하는 것으로 바뀌게 되었습니다. 띄엄 띄엄 관리해온 솔라리스 관리자 분들 당황하시겠군요.

SV4 패키징의 변화 

SVR 패키징 방식이 없어지지는 않겠지만, 기본 패키징 방식은 IPS용으로 바뀌었죠. 인터넷이 없는 곳이나 인터넷 접속이 안되는 엔터프라이즈 내에서는 별도로 IPS 서버 구성을 해두어야 함을 내포하고 있는 부분입니다. 

프린트 서비스의 절제 

프린트 서비스가 전부 CUPS로 압축되는 군요. 이제 좀 리눅스만큼 프린팅이 될런지 자못 궁금하네요. 프린트 기능을 보면 썬이 얼마나 허술하게 솔라리스를 유지해왔는 지를 여실히 보여주는 아픈 기억입니다.

sys* 툴 대체제 등장

sysconfig 유틸 하나로 기존의 sys-config, sys-unconfig 등등의 뻘짓이 통일 되는 군요. 

Ksh의 버젼 변경 

솔라리스 기본 콘쉘의 버젼이 바뀝니다. 매우 중요한 부분인데요. 로그인하면 바로 손끝에 닿는 기능이기도 하고, 기존에 작성되었던 각종 스크립트들과의 호환성이슈가 있을 수도 있는 부분이기도 하구요. 새로운 콘쉘의 버젼은 ksh93이구요, 반면 사용자들에게 기본 할당되는 쉘은 ksh93이 아니라, bash라는 점입니다. 리눅스와의 호환성에서 중요한 부분인데, 리눅스는 sh 라고 불리우는 기본 쉘이 모두 bash기능이기 때문에 리눅스에서 쉘을 가져왔을 경우 쉘스크립트안의 첫번째 줄인 호출 인식자에 /bin/sh는 /usr/bin/bash로 변경해서 돌려야 합니다.

rdist, rstart등의 퇴출

대신에 rsync, ssh를 쓰는 것으로 바뀌었군요.

 

 

2011/10/05

솔라리스 10 2011.08 버젼의 새로운 기능 리뷰

오라클은 최근에 솔라리스 10 2011년 08 버젼(이하 솔라리스 10 08/11 )을 발표했습니다. 새로운 업데이트 버젼의 개선된 기능에 대한 요약 문서가 함께 발표되었는데요, 간단하게 요약해보겠습니다.

범주 별로 보면 얼추 다음과 같습니다.


  1. 설치 및 관리 기능 
  2. 시스템 성능 개선
  3. 네트워킹 및 보안 기능 개선
  4. 새로운 장치 지원 및 드라이버 개선
  5. 프리웨어 지원 개선


각 분야별 중요한 것만 살펴보면 다음과 같습니다.

1. 설치 및 관기 기능
일단 이번 버젼의 솔라리스 부터 2TB 이상의 메모리를 지원하기 시작했군요. 향후 나오는 대형의 스팍 시스템의 메모리 크기가 2TB를 쉽게 넘을 것을 예측할 수 있는 부분이군요.
솔라리스 10까지 있는 라이브 업그레이드 기능이 ZFS를 보다 더 잘 지원하게 되었습니다. luupgrade를 이용하여 zfs 플래쉬를 설치한다거나, luucreate를 이용하여 새로운 BE를 지원하는 기능이 개선되었습니다. 라이브 업그레이드와 관련된 것들은 매뉴얼을 참고해야 합니다.

2. 시스템 성능 개선
smt_pause(3C)라는 API가 추가된 것이 눈에 띕니다. 하드웨어 기반의 가상 CPU를 제공하는 CMT 혹은 인텔의 Hyper-Thread 시스템의 경우, 실행 중인 애플리케이션이  그 가상 CPU를 사용하지 않는 것이 명시적일 경우 의도적으로 이 라이브러리를 호출함으로써 해당 가상 CPU가 공유하는 실제 코어에 연결되어있는 다른 가상 CPU로 다른 애플리케이션이 더욱 빠르게 코어 진입을 허용해주게 합니다.

아울러, 대량의 스레드를 가진 애플리케이션(프로세스)의 메모리 할당 라이브러리로 적합한 libmtmalloc(3C) API가 개선됨으로써 멀티 스레드의 성능이 더욱 좋아졌다는 군요. 참고로, 싱글 스레드를 사용하는 경우에는 libc의 메모리 라이브러리를, 16 이하의 스레드를 만드는 경우에는 libumem 메모리 할당 라이브러리를 그 이상의 스레드 수를 만드는 경우에는 libmtmalloc을 권고한다는 커멘트가 덧붙여져 있군요.

성능과 관련된 부분중 가장 실질적인 부분은 바로 이 '공유 메모리'관련 변경이 아닌가 생각이 듭니다. 발표문에 따르면, ISM 및 DISM에 관여하는 공유 메모리 기능(생성, 잠금, 잠금 해제, 삭제 방법)을 변경한후 해당 작업들의 성능이 대폭 개선되었다고 되어 있습니다. 이 부분의 메모리는 오라클 데이타베이스가 핵심적으로 사용하는 부분인데, 아무래도 데이타베이스의 성능이 개선되었음을 느끼게 하는 부분이군요.

3. 네트워킹 및 보안
IPFilter의 NAT가 IPv6를 지원하게 되었네요. 계정 암호와 관련해서 변경 사항이 눈에 보이는 데요. 이전 버젼에서는 계정이 잠기게 되었을 때(암호를 연속적으로 틀렸거나, 관리자가 잠궈 버렸을 경우) 다음 세가지 방법으로 잠긴 계정을 풀 수 있었습니다.


  • passwd -u 옵션 사용
  • passwd -d 옵션을 사용하여 암호 항목 삭제
  • 새 암호 지정

이번 릴리즈에서는 마지막 세번째 방법을 지원하지 않게 되었습니다. 잠긴 계정에 대해 암호를 지정하기 위해서는 두번째 방법으로 잠긴 암호를 일단 풀고나서 새로운 암호를 지정하는 방식으로 변경되었습니다.
아울러, root 계정에 대해서 면제되었던 암호 설정 방식이 이번 버젼부터는 일반사용자에게 적용되는 규칙을 동등하게 적용받도록 강제되어서 root에 대한 암호 설정이 강화되었습니다.  root 계정 단순하게 넣으시던 분들은 체감을 바로 하는 부분이겠습니다.

암호화 환경과 관련하여 인상적인 변경은 이번 버젼에서 ssh 서버(sshd)가 chroot()를 지원하기 시작했다는 점입니다. chroot를 사용하게 되면 ssh 를 통해 접속하는 외부 사용자에게 접근할 수 있는 디렉토리의 영역을 제한하게 함으로써 한층 보안이 강화된 모습을 엿볼 수 있겠습니다.

4. 새로운 장치 및 드라이버 개선
눈에 뜨이는 부분이 RDSv3 RDMA의 지원인 것 같습니다. 이번 버젼부터 오라클 솔라리스는 오라클 데이타베이스 11g가 요구하는 RDSv3 RDMA인터페이스를 지원합니다.  

오라클은 RDS(Reliable Datagram Sockets)용 RDMA(Remote Direct Memory Access) 인터페이스를 정의했습니다. 이러한 인터페이스는 OFED(OpenFabrics Enterprise Distribution) 버전 1.3 이후 Linux 플랫폼에서 제공되었습니다. 이 기능은 주로 InifiniBand 전송에 사용됩니다. RDSv1에서 RDS 드라이버는 userland에서 커널로 데이터를 복사하는 방식으로 원격 대상으로 데이터를 전송합니다. 이와 같은 방식으로 대용량 데이터 복사는 시간과 비용을 많이 소비합니다. RDSv3은 InifiniBand를 지원함으로써 DMA(direct memory access)로 응답 시간을 줄여서 이 문제를 해결합니다.

5. 프리웨어
흥미로운 지원이 추가되었습니다. 바로 오픈소스에서 많이 사용되는 Apache C++ Standard Library 지원이 추가된 점인데요.  Apache C++ Standard Library(stdcxx)는 ISO/IEC:14882:2003 표준(프로그래밍 언어 C++)과 완전히 호환되도록 C++ 표준 라이브러리를 구현한 것입니다. 이 라이브러리는 현재 기본 Oracle Solaris libCstd.so.1 또는 STLport4 표준 라이브러리 구현과 함께 사용할 수 없는 수많은 표준 C++ 라이브러리 기능에 프로그래밍 방식으로 액세스합니다. Oracle Solaris Studio 12 Update 1부터는 Oracle Solaris Studio C++ 컴파일러가 Apache C++ Standard Library를 지원합니다.

원문 참고: http://download.oracle.com/docs/cd/E24846_01/html/E23296/gijtg.html#scrolltoc

2011/09/21

솔라리스에서 병목 추적(LatencyTop for Solaris modified by Bonghwan)

TCP Write 부분에 대해서는 오류가 있어서 소스에서 삭제했습니다. 따라서, 아래 그림에 있는 TCP Write와 같은 부분은 더 이상 출력되지 않습니다. 추후 별도로 TCP status를 하는 스크립트를 소개해보겠습니다.

---
곧 출시를 앞두고 있는 솔라리스 11의 프리젠테이션 자료를 보니, LatencyTop 라는 스크립트를 언급하고 있더군요.  검색을 해보니 리눅스 시스템에서 지연 부분을 찾기 위해서 인텔이 만들었던 LatencyTop이라는 유틸리티를 흉내내기 위하여  솔라리스 커널 엔지니어인 브라이언 칸트릴(Bryan Cantrill)이 만들어 놓은 스크립트인 듯 하더군요.

인텔 만들어서 오픈한 LatencyTop의 자료는 http://www.latencytop.org/ 에서 참고할 수 있으며, 관련 소스도 다운 받을 수 있습니다. 처음에는 여기의 소스도 다운받아서 솔라리스에서 컴파일 해보려 했으나 불행하게도 소스코드 내에서 리눅스 만의 화일 시스템 debugfs을 마운트하는 것 때문에 컴파일이 불가능했습니다.

여하튼 브라이언 덕분에 솔라리스용을 손쉽게 구할 수 있었습니다.


다음은 여기서 다운받은 LatencyTop 원본의 출력의 예입니다.


그렇지만 다운 받아서 출력을 해보니 뭔가 개인적으로 좀 불만스럽더군요. 출력도 다소 플렌들리하지 않고, 보고 싶은 부분도 추가가 필요해 보였습니다. 그래서, 약간의 수정을 가하여 다음과 같은 개선된 LatencyTop을 만들어 봤습니다.

새로 개선된 LatencyTop은 일단 가로줄을 더 넓게 쓰도록 했고, Mutex Lock과 같은 주요 병목 포인트는 물론이거니와 아울러서 Mutex Spin과 TCP 데이타 전송시 걸리는 소요 시간들도 보이도록 했습니다. 

LatencyTop을 실행하면 6개의 컬럼이 나타나는데, 실행후 5초간 샘플링을 한 후 그 결과를 좌측으로 부터 프로세스의 이름, 프로세스 ID, 관련 병목 포인트, 그 병목 요소 호출수, 각 병목 요소 처리 최대 시간과 평균시간이 차례로 출력이 됩니다.  아래와 예를 참고하시기 바랍니다.


-Process-            -PID-  -Cause-                   -Count-      -Maximum-      -Average-
notification-dae    [1631  ] mutex spin                      1         1 usecs         1 usecs
wnck-applet         [1575  ] mutex spin                      1         2 usecs         2 usecs
xscreensaver        [1584  ] mutex spin                      1        26 usecs        26 usecs
firefox-bin         [1709  ] Unlink file                     1       102 usecs       102 usecs
Xorg                [1410  ] mutex lock                      1       129 usecs       129 usecs
gnome-terminal      [1647  ] mutex lock                      1       141 usecs       141 usecs
xscreensaver        [1584  ] mutex lock                      1       170 usecs       170 usecs
Xorg                [1410  ] mutex spin                      2        22 usecs        11 usecs
dtrace              [2090  ] mutex spin                      4       165 usecs        43 usecs
pageout             [2     ] mutex lock                      4      1521 usecs       462 usecs
gnome-terminal      [1647  ] mutex spin                      5       149 usecs        39 usecs
firefox-bin         [1709  ] mutex lock                      9       562 usecs       158 usecs
firefox-bin         [1709  ] TCP write                      10      1502 usecs       288 usecs
firefox-bin         [1709  ] Reading from file              10     20863 usecs      3886 usecs
sched               [0     ] mutex lock                     28       214 usecs        65 usecs
firefox-bin         [1709  ] mutex spin                     41        49 usecs         6 usecs
zpool-rpool         [5     ] mutex lock                     51      3453 usecs       255 usecs
sched               [0     ] mutex spin                     67      1225 usecs        29 usecs
pageout             [2     ] Writing to file                83     22971 usecs      1507 usecs
pageout             [2     ] mutex spin                     98       994 usecs       132 usecs
zpool-rpool         [5     ] mutex spin                    332       309 usecs        11 usecs


분석을 위해서는 이 결과에서 어떤 병목 요소의 호출수가 가장 많은가( 위의 예에서는 zpool-rpool )와 어떤 요소의 최대 지연시간이 많은 지를 보아야 합니다. 지연 시간 관점에서 위의 예를 살펴 보게 되면 pageout과 firefox-bin의 지연 시간이 긴 것을 할 수가 있는데, pageout은 화일 쓰기에 대한 병목을 유발하면서 호출당 최대 지연 시간이 22971/83 = 276.7590361445783 microseconds 인 반면에 firefox-bin은 화일 읽기를 위한 행위를 하고 있고, 호출당 최대 지연시간이 2086.3 microseconds 임을 알 수가 있습니다. 

따라서, 단위 호출당 관점에서 튜닝을 접근해야 한다면 이 시스템은 firefox가 접근하는 스토리지를 개선하거나 firefox가 사용하는 메모리를 대폭 늘리거나 하여 보다 건전한 환경을 구축할 수 있다고 할 수 있겠습니다. 중요한 것은 지금 현재 이 시스템이 결코 느리거나 문제가 있는 것은 아니라는 것입니다.

부하가 일시적으로 몰리거나 하여 증폭되었을 때같은 최악의 경우를 생각했을 경우를 대비하여 사전에 준비하기 위한 데이타로 바라봐야 하며, 아울러, 이와 같은 샘플링을 여러번 반복하여서 나온 값을 기준으로 가장 중요한 것부터 환경을 개선하는 기반 데이타로 사용되어져야 합니다. 

추가로 위 환경에서 발생한 pageout은 firefox-bin이 많은 읽기를 시도하기 때문에 발생하는 것임을 추측해볼 수 있는데(다른 Dtrace script로 추가 증명을 해볼 수 있습니다.) 따라서,결과적으로 본다면  화일에 대한 읽기와 쓰기를 동시에 개선해야 하는 것이 보다 더 중요하다고 생각해볼 수 있습니다. 결국 보다 좋은 스토리지의 확보가 더욱 중요하다는 것을 추리해볼 수가 있겠습니다.

수정된 LatencyTop의 소스는 다음과 같습니다.


#!/usr/sbin/dtrace -Cs


/*
#
# latencytop is monitoring hot places of bottlenecks
# This was written by Bryan Cantrill in 2008
# Bonghwan Kim, have updated a little bit to have more comfortable output. 2011
#
#
*/


#pragma D option quiet


#define RW_READER 0x1


dtrace:::BEGIN
{
printf("######\n");
printf("###### This script is written by Bryan Cantrill(2008) and updated by Bonghwan Kim(2011)\n");
printf("######\n");
printf("Tracing... Hit Ctrl-C to end.\n");
}


/*
* Reading from file
* Writing to file
*/
io:::start
{
start[args[0]->b_edev, args[0]->b_blkno] = timestamp;
self->iostart=1;
}


io:::done
/self->iostart && start[args[0]->b_edev, args[0]->b_blkno]/
{
this->delta = timestamp - start[args[0]->b_edev, args[0]->b_blkno];
this->cause = args[0]->b_flags & B_READ ?
"Reading from file" : "Writing to file";
@lcount[execname,pid,this->cause] = count();
@lmax[execname,pid,this->cause] = max(this->delta);
@lavg[execname,pid,this->cause] = avg(this->delta);
start[args[0]->b_edev, args[0]->b_blkno]=0;
self->iostart=0;
}


/*
* mutex lock
*/
lockstat:::adaptive-block
{
@lcount[execname,pid,"mutex lock"] = count();
@lmax[execname,pid,"mutex lock"] = max(arg1);
@lavg[execname,pid,"mutex lock"] = avg(arg1);
}


/*
* mutex spin
*/
lockstat:::adaptive-spin
{
@lcount[execname,pid,"mutex spin"] = count();
@lmax[execname,pid,"mutex spin"] = max(arg1);
@lavg[execname,pid,"mutex spin"] = avg(arg1);
}




/*
* rwsem read lock
* rwsem write lock
*/
lockstat:::rw-block
{
this->cause = arg2 == RW_READER ?
"rwsum read lock" : "rwsum write lock";
@lcount[execname,pid,this->cause] = count();
@lmax[execname,pid,this->cause] = max(arg1);
@lavg[execname,pid,this->cause] = avg(arg1);
}


/*
* Unlinking file
*/
syscall::unlink:entry
{
self->start_unlink = timestamp;
}


syscall::unlink:return
/self->start_unlink/
{
this->delta = timestamp - self->start_unlink;
@lcount[execname,pid,"Unlink file"] = count();
@lmax[execname,pid,"Unlink file"] = max(this->delta);
@lavg[execname,pid,"Unlink file"] = avg(this->delta);
self->start_unlink = 0;
}


/*
* sync system call
*/
syscall::syssync:entry
{
self->start_syssync = timestamp;
}


syscall::syssync:return
/self->start_syssync/
{
this->delta = timestamp - self->start_syssync;
@lcount[execname,pid,"sync system call"] = count();
@lmax[execname,pid,"sync system call"] = max(this->delta);
@lavg[execname,pid,"sync system call"] = avg(this->delta);
self->start_syssync = 0;
}


/*
* fsync system call
*/
syscall::fdsync:entry
{
self->start_fdsync = timestamp;
}


syscall::fdsync:return
/self->start_fdsync/
{
this->delta = timestamp - self->start_fdsync;
@lcount[execname,pid,"fsync system call"] = count();
@lmax[execname,pid,"fsync system call"] = max(this->delta);
@lavg[execname,pid,"fsync system call"] = avg(this->delta);
self->start_fdsync = 0;
}




/*
* Print output summary
*/




profile:::tick-5s,
dtrace:::END
{
/* normailze nanoseconds samples into microseconds samples */
normalize(@lmax, 1000);
normalize(@lavg, 1000);


printf("%-20s %-6s %-20s %12s %14s %14s\n", "-Process-","-PID-","-Cause-", "-Count-","-Maximum-","-Average-");
printa("%-20s[%-6d] %-20s %@12d %@9d usecs %@9d usecs\n", @lcount, @lmax, @lavg);
printf("\n");


trunc(@lcount);
trunc(@lmax);
trunc(@lavg);
}

2011/07/22

페이스북의 클라우드 아키텍쳐

최근 일어나고 있는 최신의 유행은 Hadoop이라고 할 수 있겠습니다. Hadoop은 대규모 병렬 화일 시스템 처럼 사용이 될 뿐 아니라, MAP & Reduce의 기능을 활용하여 저장되는 텍스트 화일들의 실시간 분석 기능을 제공하기 때문에, 일석이조의 관점에서 많이 회자되고 있습니다.
그런데, 이런 Hadoop 기반의 분석(Analytics) 기능이 다수의 장애 포인트와 아울러 실제 실시간 분석으로 제공하지 못하는 점 때문에 대형의 서비스 업체 : 구굴, 페이스북, 야후가 분석 기능을 쓰지 않는 다는 얘기입니다.
실시간 분석을 하려면 아무래도 메모리에 모든 것을 두어야 하는데, 특히 카운터를 메모리에 두면 유리할 수 있겠죠. 이 기능을 위해서 Facebook은 memcached를 이용해서 구축했다고 되어 있네요. 그러나, 이런 memcache 기반의 환경은 1%장애만 나도 분석 결과에 영향을 끼치기 때문에 고가용이 중요한데 facebook의 구성은 고가용은 아니라고 되어있네요.
아울러 컴퓨팅에서는 '쓰기IO'가 매우 중요한데, 병렬 쓰기를 통해서 성능을 높이기 위해서 카산드라를 Hbase의 플랫폼으로 쓰고 있다는 점을 언급하고 있네요.
Nati Shalom's Blog: Architecture

링크: http://natishalom.typepad.com/nati_shaloms_blog/architecture/

2011/07/14

[클라우드 컴퓨팅] 이메일과 클라우드 컴퓨팅

이메일 서비스는 사실 단순한 서비스라서 클라우드 컴퓨팅화 하기가 다소 애매하다고 생각할 수 있는데, 아래 회사는 멋지게도 벌크 이메일 서비스를 클라우드 컴퓨팅화해서 제공을 하는 군요. 대량 이메일 발송 서비스를 위한 플랫폼 애즈어 서비스(Platform as a service)를 제공하고 있는 Elastic Email 이라는 서비스를 소개합니다.

회사의 포털 사이트는 http://elasticemail.com/ 입니다.

이 회사는 서비스 사용자로부터 미리 약속되어져 있는 API를 통해서 이메일과 관련 파라메터(발송 수, 대상,예약등) 접수를 받아서 대량 발송을 대행해주는 역할을 한다고 할 수 있습니다. 이런 이메일 대량 발송서비스는 이미 커머셜 단계에서는 상당히 발전되어 있는데, 거의 모든 대부분의 서비스는 전용 클라이언트나 해당 웹사이트에 기 저장된 정보를 이용해서 메일을 발송하도록 되어 있습니다만, 이 회사는 사용자의 웹 애플리케이션에서 API를 통해서 관련 데이타의 접근과 주문을 할 수 있도록 허용하고 있다는 점입니다. 이전 전용 클라이언트를 활용하는 방식이 SaaS 모델이라면 API를 통해서 접속의 유연성을 제어하는 것은 PaaS의 모델이라고 할 수 있습니다.

서비스 제공자는 API를 통해서 발생된 트랜잭션들을 모두 저장해놓음으로써 향후 과금을 시도하는 방식이겠습니다.

클라우드 컴퓨팅의 관점에서 보면 이메일 서비스의 상당히 발전된 형태를 취하고 있으며, SaaS와 아울러 PaaS를 어떻게 취급해야 하는 지, 기존의 SaaS 모델을 어떻게 하면 PaaS 모델로 확장할 수 있는 지를 보여주는 좋은 예라고 할 수 있을 듯 합니다.

아울러 이 링크는 최근 미국에서의 클라우드 컴퓨팅 현황입니다. 참고가 될 듯 합니다.