System Compleat.

Raspberry PI, $25 Linux Box based on ARM

Techs
(younjin.jeong@gmail.com, 정윤진)

http://www.raspberrypi.org/

Raspberry PI Alpha board



ARM 베이스의 저렴한 리눅스가 임베드된 하드웨어가 나왔다. 가격은 무려 25달러. 아직 판매를 개시하고 있지는 않은 것으로 보이나, 출시될 경우 필요한 산업분야에 굉장히 저럼한 가격으로 원하는 서비스의 구성이 가능 할 것으로 생각된다.

일반적으로 생각 할 수 있는 서버/클라이언트 이외에, 예를들면 스키장의 자동화를 위한 임베디드 소프트웨어의 기반 시스템등을 생각 해 볼 수 있다. 이를테면 사용자의 손목에 부착된 바코드를 리프트에서 자동으로 스캔하는 엣지 모듈의 베이스 하드웨어, 온도센서를 부착하여 특정 온도가 되면 자동으로 눈을 뿌려준다든지 하는, 중앙의 서버와 통신하며 각 지역에 용도에 따라 분산되어있는 모듈의 기반장치로 사용이 가능 할 수도 있다는 것이다.

이러한 장비가 기존의 임베디드와 다른 것은, 어려운 SoC를 굳이 배울 필요가 없이 기존의 리눅스기반 프로그래밍 기술과 다양한 라이브러리를 사용한 일반적인 어플리케이션 수준의 소프트웨어 개발 및 구동이 가능하다는 점일 것이다.

딱 필요한 성능 만큼을 극한의 상황에서 구동해야 하는 경우는 많이 있다. 이를테면 자동차나 비행기, 또는 산 꼭대기에 있는 풍력발전 모듈의 제어, 클라우드기반 서비스와 연동 될 수 있는 모든 가능한 어플리케이션, 이를테면 게임, 영상, 기타 등등 필요한 부분은 얼마든지 있다. 이는 단일 PCB 기반의 장치에서 전원/네트워킹/USB 연결만 지원하게 되더라도 그 용도는 무궁무진해 질 수 있다.

물론 이 장치가 그러한 분야에 최적이다 라고 말하기엔 아직 정보가 부족하기는 하지만, 상상해 보라. 일반 서버 한대를 250만원 주고 구매하는 대신, 이 장비를 100대 구매해서 단순 이미지 서비스 용도로 구현 하는 것도 가능하지 않을까. 물론 10/100 이기는 하지만, 네트워크 부분만을 제외하고는 오히려 클라우드에서 사용하는 한대의 인스턴스 개념으로 사용 할 수도 있지 않을까?

100대의 인스턴스와 100대의 Raspberry. 물론 컴퓨트 클라우드의 인스턴스 만큼 신축성을 가지지는 못하겠지만, 비용이 저렴하기 때문에 분산의 개념이 잘 적용된 애플리케이션 구동에는 비슷한 성능을 보이지 않을까 한다. 

하지만 모든 것이 가능하지는 않을 것이다.  다만, 기존에 우리가 상상해 왔지만 임베디드 전문가가 아니면 범접하기 힘들었던 부분들에 보다 쉽게 접근이 가능 할 것이다.

아래는 아직 개발중인 Alpha 장비(위의 사진)를 사용하여 Quake III 를 구동하는 영상. 비록 퀘이크가 오래된 게임이긴 하지만, 이 정도의 성능은 일반 모바일 장치를 뛰어넘는 것으로 볼 수 있다.






Raspberry Pi alpha PCB



이 장치의 PCB. 현재 개발중인 Alpha 버전과 나중에 상용화될 장치의 다른 점은 다음과 같다고 한다.

  • 최종 상용버전의 크기는 신용카드 크기 정도가 될 것이며, 알파 보드는 이보다 20%정도 더 크다. 사진에서 확인 할 수 있듯, 이미 다양한 종류의 커넥터에 필요한 사이즈가 반영되어 있다.
  • 알파보드는 6레이어로 구성이 되어 있으며, 최종 버전의 출시 이전에 해결해야할 성능상의 문제가 일부 있다. 이러한 부분들에 알파 보드에서는 비교적 고가의 칩셋, 이를테면 HDI (blind, buried vias, via-in-pad) 와 같은 기능들을 하드웨어로 처리하는 칩셋을 사용하고 있다.
  • 알파 보드에서는 최종 버전의 보드에서는 지원하지 않는 다양한 테스트와 디버깅 기능을 포함하고 있다.

또한, 대략적인 스펙은

  • ARM-based application processor
  • SMSC LAN9512 USB 2.0 hub
  • 10/100 Ethernet controller

모델 A와 모델 B가 출시될 예정이며, 두 장치의 차이점은 모델 A는 128MB 의 메모리, 모델 B는 256MB의 메모리가 포함된 것이다. 모델 A의 경우 $25 수준이며, 모델 B의 경우에는 이보다 5~10 달러 정도 더 비싼 수준일 것이라 한다. 2011 년도 내에는 공급 될 것으로 보인다.

Raspbearry Pi running Ubuntu 9.04




prototype with 12M Pixel camera module


12M 픽셀 카메라 모듈을 붙인 프로토타입의 위용. USB 포트 사이즈를 통해 실제 하드웨어의 크기를 짐작해 볼 수 있다.


2000년대 초반 즈음, 어느 외국의 패션쇼인가 잡지에서 '컴퓨터 옷' 을 만들어 입고 치렁치렁 부품을 달고 돌아다니는 사진을 접한적이 있다. 그때는 피식 웃고 말았지만, 이제 세상은 정말로 USB 메모리 스틱만한 '제대로' 동작하는 컴퓨터를 만들어 내고 있다. 하지만, 모바일 및 전화의 기능성으로 인해 모든이들이 들고다니는 용도의 사용성 보다는, 아마도 종전의 임베디드 분야에서 더 필요한 하드웨어가 되지 않을까 하고 생각해 본다.

(younjin.jeong@gmail.com, 정윤진)



저작자표시 비영리
,

Quagga - Simple Router for Linux

Techs
( younjin.jeong@gmail.com, 정윤진) 

요새 라우터의 기능이나 성능 때문에 리눅스를 대용으로 사용 하려는 경향은 거의 없다. 하지만 Cisco 가 실리콘 밸리의 떠오르는 샛별이 되던 그 시절 즈음 해서, 아마도 ISA 버스를 사용하는 이더넷 랜카드가 대부분이던 그 시절에, LRP ( Linux Router Project ) 라는게 있었다. 지금이야 다들 Cisco 의 config를 모델로한 대부분의 상용 라우터를 사용하지만, 궁했던 그때에는 이런 리눅스 기반 라우터를 많이들 사용하곤 했더랬다.  플로피 디스켓의 추억이 떠올라 검색을 좀 해 보니, 이런 글이.  리눅스로 라우터 만들기

관련하여 LEAP (Linux Embedded Appliance Project) 라는 프로젝트도 있는데, 좀 재미있어 보이는 듯. 역시 좀 오래된 프로젝트인데, 마지막 업데이트가 언제인지는 잘 모르겠다.

http://leaf.sourceforge.net/index.php?module=pagemaster&PAGE_user_op=view_page&PAGE_id=4&MMN_position=18:18
http://sourceforge.net/projects/leaf/files/


아무튼 요새는 이런 정도로 사용 할 필요는 없지만, 간혹, 아주 간혹 시스템 내부에서 간단한 라우팅 프로토콜 설정이 필요한 경우가 있을 수 있다. 단순히 Static 라우팅이 아닌, rip 또는 ospf, 경우에 따라서는 bgp 정도의 구성이 필요한 경우가 있다. 이럴때 간단하게 사용 할 수 있는 도구가 바로 Quagga인데, 필요한 데몬의 조합으로 원하는 구성이 가능하다.

zebra : static 라우팅 및 인터페이스 정의
bgpd :  BGP 라우팅
ospfd :  OSPF
ospf6d : OSPF IPv6
ripd : RIP v2
ripngd : RIP IPv6


다음의 페이지에 간단한 샘플 구성이 있기에 가져와 보았다.
http://www.readytechnology.co.uk/open/bgp/loadbalanced.html

 

이런식의 이중화 구성을 사용하는데가 아직 있는지는 모르겠지만, 어쨌든 필요하면 할 수도 있는 것이므로 간단한 설정의 예제로서 참고하도록 한다.

위의 네트워크 다이어그램에서의 조건은 다음과 같다.

  • r1 과 r2 는 FreeBSD & Quagga 조합의 라우터일 수도 있고, Cisco 7204/7206 일 수도 있다. 어쨌든 분명한건 라우터이다.
  • 각 라우터는 각각의 ISP와 연결되어 있다. 
  • 2950 스위치 2대는 각각 서로 다른 사설 네트워크로 구성되어 있다. (192.168.1.0/24 , 192.168.2.0/24)
  • 이 조직은 외부 서비스 연결을 위해 공인 IP 블럭을 가지고 있다. 각 내부 호스트들은 루프백 인터페이스에 /32 넷마스크의 공인 IP를 하나씩 가지고 있다. 따라서, NAT 구성이 반드시 필요하지는 않다.
  •  각 서버는 리눅스로 동작하고 있으며, 이들의 커널은 Equal Cost Multi-Path 라우팅이 활성화 된 상태로 컴파일 된 것을 사용한다. 이는, 커널이 라우팅 테이블에 다수의 기본 게이트웨이를 가지도록 구성이 가능하므로, 외부로 전달되는 트래픽의 분산이 가능하다. ( 커널 config 옵션은 CONFIG_IP_ROUTE_MULTIPATH=y )
  •  전체 서버에서의 기본 게이트웨이를 포함한 라우팅 구성은 절대 수동으로 하지 않는다. 대신, Quagga 를 전체 서버에 구성하도록 한다. 내부의 서버들에서는, Quagga 의 OSPF를 사용하여 라우터의 주소를 설정하도록 구성 할 것이다.
  • 각각의 라우팅이 장비의 문제 등으로 인해 사용이 불가능한 경우에는, OSPF 프로토콜에 의해 5초 이내로 장애가 감지되며, 이후 라우팅 테이블에서 해당 경로를 삭제한다.
  • OSPF를 사용하여 장애를 감지하는 것이 최선 일 수 있다. 이는 OSPF 가 IP 계층을 기반으로 동작하기 때문이다. 만약 r2에 연결된 2950 에 케이블 문제가 발생한다 하더라도, OSPF는 이러한 상황을 잘 처리 할 수 있을 것이다.  

위의 구성을 바탕으로, 실제 서비스를 구성해 보면 된다. 예제에서는 데비안 리눅스를 사용하였으므로, 이변이 없다면 그냥 우분투를 사용해도 무방하겠다. 공인 IP 주소는 A.B.C.D 로 표현 되었음에 주의 하자.

Quagga 설치 
      apt-get update
      apt-get install quagga iproute

리눅스 인터페이스 설정. 당연히 우분투에서는 /etc/network/interfaces

auto lo
iface lo inet loopback
  up ip addr add dev lo A.B.C.D/32 scope global

# notice that we use `manual' rather than `static', so that we can
# over-ride the scope parameter
auto eth0
iface eth0 inet manual
  up ip link set dev eth0 up
  up ip addr add dev eth0 192.168.1.10/24 scope link

auto eth1
iface eth1 inet manual
  up ip link set dev eth1 up
  up ip addr add dev eth1 192.168.2.10/24 scope link

아래의 내용을 /etc/quagga/zebra.conf 에 구성 

      hostname www1
      password changeme
      enable password changeme

      interface lo
        ip address 127.0.0.1/8
        ip address A.B.C.D/32       (this is your server's real IP)

      interface eth0
        ip address 192.168.1.10/24
        multicast

      interface eth1
        ip address 192.168.2.10/24
        multicast

     !log file /var/log/quagga/zebra.log
아래의 내용을 /etc/quagga/ospfd.conf 에 적용 

hostname www1
password changeme
enable password changeme

interface eth0
 no ip ospf authentication-key
 ip ospf hello-interval 2
 ip ospf dead-interval 5

interface eth1
 no ip ospf authentication-key
 ip ospf hello-interval 2
 ip ospf dead-interval 5

router ospf
  ospf router-id A.B.C.D
  network 192.168.1.0/24 area 0
  network 192.168.2.0/24 area 0

!log file /var/log/quagga/ospfd.log

/etc/quagga/daemons.conf 를 수정.  set zebra=yes 및 ospfd=yes


확인

설정이 완료된 호스트를 재부팅 한다. 재부팅이 완료 되면, ip route 커맨드를 사용하여 여러개의 기본 게이트웨이가 있는지의 여부를 확인한다. 이후에는 라우터 또는 회선을 분리하여 OSPF가 잘 동작하는지 확인 할 수 있을 것이다.

위의 내용 대로 설정 했음에도 불구하고 잘 동작하지 않는다면, 다음의 내용을 확인 해 보도록 한다.

  • 커널이 Equal Cost Multi-Path 설정이 된 상태로 컴파일 되어있는지 확인한다.
  • 커널에서 Multicast 가 활성화 되어 있는지 확인한다. 또한, NIC 및 드라이버가 이를 지원하는지의 여부를 확인하도록 한다.
  • iptables 에 의해 OSPF 가 막혀 있지는 않은지 확인 한다. 만약 기존의 정책에 추가해야 할 필요가 있다면, 다음의 커맨드를 참조한다. 
    iptables --insert INPUT -s 192.168.0.0/16 --protocol ospf -j ACCEPT


이는 예제를 통해서 간단하게 살펴 본 것이므로, 보다 더 알고 싶은 경우에는 구글 검색을 해 보면 되겠다. 다음의 링크에 잘 정리된 Tutorials 가 있으므로 참조 하도록 한다.

Quagga Tutorials


( younjin.jeong@gmail.com, 정윤진)






저작자표시 비영리
,

sg3_utils

Techs
(younjin.jeong@gmail.com, 정윤진)


절대로_찾을수_없을걸_JPG

Image from : https://supcom.hgc.jp/english/img/supcom/DiskArray.jpg

 이런 저런 용도로 JBOD이 리눅스에서 굉장히 많이 사용되고 있다. 뭐 물론 계속 사용 해 왔던 분들에게는 별 문제는 아니지만, 이제 막 이런 장비를 사용하여 Swift 등을 구현하다 보면 아주 간단한 장애 디스크 하나 찾는게 골치 아파질 때가 있다.  물론 디스크 하나 찾기위해 이 도구가 필요 한 것은 아니지만, 이러한 도구 없이 X Window의 힘을 빌리기란 시스템 하는 분들 입장에서는 여간 챙피한 일이 아닐 것이다. 아, 물론 그렇게 느끼시지 않는다면 관계 없다.  살포시 디스크 매니저를 찾아 보자. 

제목에서와 같이, 이 오랜만의 포스팅은 sg3_utils 에 대한 내용을 설명한다. 아 물론, 친절하게 뭐가 뭐다 하고 설명하면 더 좋겠지만, 나는 여기서 더 친절하게 무려 sg3_utils 홈 페이지의 내용 중 가장 쓸만 하다 싶은 내용을 아예 번역을 해 버렸다. 물론 번역이 그다지 나이스한 품질은 아니지만, 일하다가 짬짬히 되는대로 써 놓은 것이기 때문에, 또 별도의 다른 번역 문서도 아직 존재하지 않는 듯 하기에 포스팅을 해 본다. 

아 물론, 각 표에 있는 내용까지 번역을 했더라면 좋았겠지만, 그닥 시간이 허용하지 않아서... 한시간 동안 완전 날림 번역이지만 그래도 영어로는 죽어도 못 보겠다 하시는 분들만 보시면 된다. 

sg3_utils 패키지는, 리눅스에서 디스크 관련 Low Level 작업을 할 때 꽤나 유용한 패키지다. 디스크가 두세개 정도 밖에 없다면 대략 무슨 디스크가 뭔 디스크인지 쉽게 알 테지만, 24개 48개 96개 이렇게 되어버리는 데다가 별도의 RAID 구성마저 하지 않는다면 골치가 아파질 것이다. 

RAID도 없이 그렇게 무식하게 디스크를 쓰는데가 어디 있냐고 물으신다면 Swift 라 답하겠어효... 

클라우드의 싸게 넣어서 준비시키고 쓰다가 쫑나면 교체해 버리고의 컨셉은 디스크 사용에도 적용되기 시작했다. 이는 바로 Swift 가 제공하는 '오브젝트 스토리지'라는 신개념 스토리지 (라고 쓰고 그냥 웹 파일 서비스 라고 읽는다) 에서는, 디스크에 별도의 볼륨 구성 없이 각 디스크를 생짜로 그냥 사용한다. 대부분의 시스템 관리자 분들 께서는 Writeback이니, ZFS의 log이니, RAID Level 이 어쩌고 저쩌고에 능통하시겠지만, 이 단순한 디스크+웹 서비스는 그 간단한 구성 만큼이나 디스크 구성도 간단하게 처리해 버린다. 

따라서 별로 되게 어려울 것은 없지만, 리눅스 그 자체의 안정성이 쵸큼 중요하게 되는 것도 이 서비스라고 할 수 있겠다. Commodity Hardware 에서 어떠한 방법으로 안정성을 구가하는가가 오히려 더 중요한 포인트가 될 수도 있음이다. 

아 물론, 우분투 LTS 버전이 무조건 안정적이다 하시는 분들도 계시고, 여기서 커널 바꾸면 세상 무너지는 줄 아는 분들도 계시긴 하지만, 그런 분들에게 이러한 Low Level 도구는 위험하므로 얼른 다른자료 찾아 보시길 권고한다. 물론, 그까이꺼 LED 따위 고장나면 바로 켜져야 하는거 아냐 하고 생각 하시는 분들 께서도 굳이 이런 난잡한 번역 읽느라 고생 하실 필요가 없음.

자꾸 새는데, 뭐 결국은 sg3_utils 로 해 볼 수  있는 것들이 많고, 보통 Production 단계 이전의 Dev나 STAG 환경에서 마음껏 가지고 놀아보는게 중요하겠다. 

각설하고, 웹 버전으로 보고 싶으신 분들은 아래의 펼쳐보기를 누르시면 된다. 
원래의 작업을 워드로 처음 해 봤더니, pdf 로 만들 수도 있어서 한번 만들어 봤다. 
번역이 좀 구려도 대충 보시라. 

sg3_utils_AUG2011.pdf

 


Swift 에 대해서는 시간이 나면 따로 포스팅을.. 


(younjin.jeong@gmail.com, 정윤진)

 
저작자표시 비영리
,

vSMP, Versatile Symmetric Multi-Processing

Techs
( younjin.jeong@gmail.com, 정윤진 )




클러스터링 환경에 익숙하거나, 병렬 컴퓨팅, 또는 일반 PC를 가혹하게 사용하시는 분들은 모두 이런 생각 한번쯤은 해 보셨을 것 같다. 

"아, 이 여러대의 컴퓨터를 각각 별도의 OS를 사용하여 MPI와 같은 방법으로 묶지 말고, 차라리 한대의 서버처럼 묶어 버릴 순 없을까? "

90년대 후반, 인텔이 SMP를 지원하는 프로세서를 시장에 내놓으면서, 워크스테이션 좋아라하는 컴덕후들은 입이 떡 벌어져 Pentium Pro 프로세서를 구매해 대고, 프로세서를 2개 이상 설치 할 수 있는 고가의 메인보드를 구매해 댔다. 그러고나서 당시의 전세계 수퍼 컴퓨팅의 Top 100 중 가장 빠른 컴퓨터는 바로 인텔이 Pentium Pro 프로세서를 병렬로 묶은 컴퓨터라 카더라 하는 이야기를 침튀어가며 이야기 했었다.

당시에도 수퍼컴퓨터 하면 Cray가 항상 다섯손가락 안에 들었으며, 냉각팬이 아닌 화학물질로 시스템 온도를 낮추어야만 하는 이 신기한 컴퓨터의 이미지를 쳐다보며 아~ 한번 만질수 있다면 얼마나 좋을까 하는 생각들을 했었더랬다. 그 시절 1G 이더넷을 구축하는 것도 엄청난 비용이 들었으며, 10G는 아직 나오지도 않은 시점에서 그나마 Cray보다 저렴한 MPI 클러스터를 지금도 고가인 InfiniBand 를 사용해 엮어 사용하기만 해도 대단한 클러스터로 쳐 주었다.

세월은 흐르고 흘러, 그저 꿈으로만 생각했던 소프트웨어가 나왔다. 물론 그 효용성과 성능에 대해서는 일부 검증을 직접 해 볼 수 있으면 좋겠지만, 일단 상용으로 나왔다는거 자체가 이미 어느정도의 지원은 가능하며, 어지간히 동작이 가능한 수준이라고 볼 수 있겠다.

바로 그렇다. 여러대의 x86 시스템위에 하나의 OS를 올릴 수 있는 시스템 소프트웨어가 출현 한 것이다. 개발 업체의 이름은 ScaleMP (http://www.scalemp.com), 제품은 vSMP Foundation 으로 소개되고 있는듯. 제품의 구매는 삼부 시스템이라는 업체에 문의 해 보면 될 듯 하다. (http://www.samboo.co.kr) 회사의 홈페이지를 보면 원래 Cray를 전문으로 취급하던 기업 같은데, 아마 이 분야의 사람들에게는 익숙한 업체이지 않을까 짐작해 본다.


일단, x86 기반의 머신들만 가지고 한대의 OS를 사용한 기존과는 획기적으로 다른, 상상해 왔던 바로 그 클러스터 시스템이 제공하는 기능은 다음과 같다.

vSMP Foundation for SMP


기능
  • 최대 128대의 노드를 사용하여 단 하나의 OS를 가진 시스템을 생성 
  • Highest CPU Capacity :  vSMP를 사용한 OS는 최대 16,384 개의 CPU를 단일 PC와 같이 하나의 공유메모리 기반에서 사용 가능 ( 8192개의 코어를 사용한다는 말도 있는데 이 두개의 숫자가 어떻게 다른지 써보기 전에는 모르겠다.)
  • Largest Memory footprint : 최대 64TB 의 메인 메모리 
  • High Speed I/O : 빡센 데이터의 처리에 병렬 스토리지를 활용 
  • 장애 대응을 위한 InfiniBand  연결 지원 
  • 장애로 부터 자동 복구
  • 나머지 생략

장점
  • 기존의 단일 머신의 SMP 성능을 뛰어넘는 기절할만한 성능
  • 투자 보호 : 서로 다른 속도의 CPU, 서로 다른 크기의 메모리, 다른 I/O 장치를 사용한 환경에서도 구성이 가능
  • 기타 생략

OMG

Image from : http://i7.photobucket.com/albums/y286/SNOOP97DAWG/NHL/homer-simpson-5.jpg



그렇다. 입이 떡 벌어진다.  기존의 병렬 시스템들이 추구하는바가 Scale-Out 으로, 단일 시스템이 Scale-Up 의 형태로 성능을 확장하기 힘들었기 때문에 생긴 방법들이다. 하지만 이 물건은, Scale-Up 과 Scale-Out 을 모두 지원함으로서, 아니, Scale-out 의 형태를 사용하여 Scale-Up 을 구현 함으로서, 비지니스의 성장요구에 따라 점진적으로 하드웨어의 추가가 가능하며, 더군다나 대부분의 Block 레벨로 I/O를 공유하는 클러스터가 요구하는 하드웨어의 동일성마저 없다. 따라서 세월이 지나면서 HCL 만 충족하는 하드웨어를 지속적으로 구매한다면, 다양한 하드웨어를 사용한 노드의 집합으로 하나의 OS를 사용하는 거대한 시스템을 구성 할 수가 있는 것이다!

난 쩔어 버렸어~ (태지 보이스, 필승)

혹시 국내에 사용중인 환경이 있는가 궁금해서 네이버등에 검색을 쌔워보니, 뉴스 이외의 정보는 없는것으로 봐서는 그다지 많이 알려져 있지는 않은 것 같다.


실리콘밸리의 벤처 회사들을 다니다 보면, 그런 생각을 갖게된다. 얘들이 설명하는거 절반만 제대로 동작해도 이건 먹어주는 물건이다, 라는.  OS라는건 나름 복잡한 물건이다. 관련 전공을 이수하신 분들이라면 한번쯤 읽어 보았을 Operating System Concepts 에서 설명하는 대부분의 내용들은 시스템이 동작하는 기본이며, PC와 서버가 발전하면서 단일 PCB상에서 연결된 장치들의 오묘한 타이밍 통제와 락, 스케줄링이 복합적으로 그리고 유기적으로 조합된 하나의 소프트웨어인 것이다. 이 새로운 패러다임의 단일 OS지원 클러스터는, 이 OS에서 제공하는 별도의 라이브러리를 사용한 별도의 소프트웨어만 동작한다면 기존의 클러스터보다 나을것이 그다지 없을 것이다. 하지만 상상해 보라. 만약, 이 OS에서 오라클이 아무 문제없이 동작하고, 리눅스 기본 패키지들이 별 문제 없이 동작한다면, 이건 정말 두손 두발 다 들어주어야 할 기존과는 다른, 그야말로 신세기 컴퓨팅 플랫폼이 되는 것이다. 물론 오라클이 동작하지 않을 거라는 심증이 좀더 크지만.

아무튼 ScaleMP 사이트의 제품 소개를 제외한 대부분의 정보는 Subscription 으로 보호되어 있다. 심지어 Whitepaper 조차 등록 후에 열람이 가능하다. 따라서 이 블로그에서 소개하는 것 이상의 정보가 필요하신 분들께서는 ScaleMP의 홈페이지 또는 삼부시스템의 홈페이지를 참조하시기 바란다.

궁금한 부분은, 각 시스템의 연결을 10G를 지원하는지의 여부 (어떻게 각 클러스터들을 연결하는지의 여부) 와 각 시스템의 Disk를 어떻게 사용하는가와 같은 부분들이다. 또는 별도의 Shared Storage를 연결해야 하는지 등도 매우 궁금하다. 나중에 알게되면 설명하겠다.

분명한 것은, ScaleMP는 컴퓨팅의 새로운 패러다임을 만들었다. 이들 역시 이 부분을 강조하는데, 기존의 클라우드와 같은 단일 서버를 여러대의 가상서버로 분리하는 것을 Partitioning 으로 정의 하며, 데이터 센터에 데스크탑을 설치해 두고 원격지의 Thin-Client로부터 접근하여 사용하는 방법을 Remotting 으로 정의 한다. 이 새로운 패러다임은 여러대의 물리서버를 사용하여 하나의 논리적인 OS로 구성하는 방법으로서, 이를 Aggregation 으로 정의하고 있다. 이는 가상화의 또 다른 모습이며, 여러분이 기존에 이해하고 있었던 가상화에 대한 신선한 충격이 될 것을 믿어 의심치 않는다.

상용 소프트웨어인데다가, 그 사용 방법 역시 널리 알려졌다고 보기엔 무리가 있다. 따라서 별도의 교육이 있지는 않은지 살펴 보니 역시 있다.  교육 과정은 다음과 같다.

VSMP101: Introducing vSMP Foundation
VSMP201: System Administration (Basic)
VSMP202: System Administration (Advanced)
VSMP301: Developers (Theory)
VSMP302: Developers (Hands-on)

301과 302는 각각 8시간, 나머지는 각 4시간으로 일주일 정도의 코스가 되지 않을까 싶다. 이 일주일 정도의 교육이 의미하는 바는, 아마도 개발자가 아니라면 기존의 시스템과 크게 다르지 않기 때문에 쉽게 적응이 가능하지 않을까 하는 기대를 품게한다.


자, 이제 ScaleMP 측의 제품에 대한 설명을 좀 살펴보자.


The Versatile SMP (vSMP) Architecture

현재 특허 출원중인 Versatile SMP 아키텍처는 하이엔드 SMP 시스템의 구성을 위해 사용된다.  vSMP는 기본적으로 InfiniBand 로 상호 연결된 시스템들을 사용해 기존의 시스템들을 대체한다. vSMP Foundation 은 ScaleMP가 만들어낸 아키텍처를 실제로 구현해 낸 제품이다. 이는 업계 표준의 일반적인 하드웨어를 사용하여 하나의 대형 X86 시스템을 만들어내는 기술이다. 이 기술은 특별히 하나의 하드웨어 벤더 또는 한 종류의 하드웨어를 사용할 필요가 없으므로, 기존 클러스터가 요구했던 맞춤형 하드웨어의 제작 또는 이러한 하드웨어를 제작하는 벤더만을 사용해야 하는 벤더-락-인 의 단점을 종식시킨다.

전통적인 멀티 프로세서 시스템은 프로세서간의 통신 및 공유 메모리, 사용자 정의 칩셋등이 하나의 메인보드에 집약되어있는 구성을 가진다. 이러한 구성은, 시스템이 4개 이상의 프로세서를 지원하기 위해서는 훨씬 복잡한 내부 구조로 인해 설계가 쉽지 않다. 따라서 이 이상의 프로세서를 지원하는 시스템은 거의 없다고 봐도 무방하다. 또한 프로세서의 빠른 신제품 발매주기로 인해 이러한 프로세서들을 메인보드는 지속적으로 지원해 주어야 하므로, 이렇게 수많은 프로세서의 탑재가 가능한 보드를 어렵게 설계 하는것은 큰 의미가 없다. 따라서, 기존의 Scale-UP 형태의 시스템 확장에 한계가 발생하는 동시에, 하이-엔드 컴퓨팅은 새로운 형태의 시스템을 요구 하게된다.

vSMP는, 별도의 커스텀 하드웨어를 사용할 필요가 없다. vSMP 아키텍처의 핵심은 바로 기존의 멀티 프로세서 시스템들과는 다른 형태의 칩세 서비스를(칩셋은 보통 하나의 PCB에 위치하므로 단일 시스템의 의미로 생각해도 좋다) 소프트웨어를 사용하여 구성한다는데 있다. vSMP 아키텍처는 I/O 및 시스템 인터페이스 (BIOS, ACPI)의 공유와 캐시등의 기존 OS에 필요한 모든것들을 제공한다. 이는 완전히 투명한 방식으로 구현되며, 별도의 추가적인 드라이버를 필요로 하지 않으며, 기존의 어플리케이션에 아무런 변경을 하지 않아도 동작하도록 한다.


Requirements

vSMP Foundation Requires :

  • Multiple high volume, 업계 표준 x86 시스템 또는 프로세서와 메모리를 탑재한 시스템 보드
  • HCA 리스트에 정의된 하드웨어를 사용한 InfiniBand 인프라. 케이블, 스위치.
  • vSMP Foundation 을 부팅하기위한 시스템 보드별 하나의 스토리지 장치. vSMP Foundation for Cloud 제품은 네트웍 부팅을 사용하므로 필요하지 않음.

One System

vSMP Foundation 은 최대 128대의 x86 시스템을 지원한다. 이 하나의 가상화된 OS는 각 노드의 메모리의 로딩이 끝나고 나면, vSMP Foundation 은 이 각 노드에 있는 컴퓨팅과 메모리, I/O 자원을 병합하여 단일화된 하나의 가상 OS와 이 OS 에서 사용할 어플리케이션의 구동이 가능하게 된다. vSMP Foundation 은 균등한 실행 환경을 제공하기위해 Virtual Machine Monitor(VMM) 의 형태를 사용한 소프트웨어 엔진을 사용한다. 또한, vSMP는 단일화된 시스템의 사용성을 위해 BIOS나 ACPI와 같은 환경을 만들어내는 부분도 포함한다.


Coherent Memory

vSMP 는 여러가지 신기술을 사용하여 각 시스템 보드간의 캐시 동일성을 유지한다. 이 복잡한 알고리즘은 실시간 메모리 활동 및 접근 패턴에 대해 블럭레벨로 동작한다. vSMP는 시스템간의 통신에 대한 지연시간을 최소화하기 위해 보드의 로컬 메모리와 최상의 캐시 알고리즘을 사용한다.


Shared I/O

vSMP Foundation 각 시스템 보드의 모든 PCI 자원을 하나로 병합하고 이를 공통의 I/O pool 리소스로서 OS와 어플리케이션에 제공한다. OS는 시스템 스토리지와 네트워크 장치를 적절히 활용 하여 최상의 성능을 제공한다. 


Flexible Versatile Architecture

vSMP Foundation 소프트웨어는 vSMP 아키텍처를 구현한 것으로서, 128대의 산업 표준의 일반적인 x86 시스템을 하나로 통합하여 가상의 단일화된 OS를 생성할 수 있다. vSMP Foundation 은 최대 1024 개의 프로세서 ( 8,192 코어) 와 64TB의 공유 메모리를 사용한 가상 시스템을 생성해 낼 수 있다.

vSMP Foundation 은 이러한 각 노드의 CPU와 메모리의 크기가 서로 다르더라도 지원이 가능하며, 심지어 I/O 장치가 다르더라도 동작한다. 이는 x86 공유 메모리 시스템의 고유한 기능이다.

높은 프로세서 부하를 요구하는 컴퓨팅 어플리케이션의 경우, 최대 1.5TFLOPS 를 사용하는 단일화된 시스템의 사용이 가능해진다. 만약 어플리케이션이 메모리를 많이 사용하지만 요구되는 컴퓨팅 파워는 그다지 높지 않은 경우, 높은 속도의 프로세서와 낮은 속도의 프로세서를 복합적으로 사용하는 아키텍처가 구성이 되는 경우가 있다. 이러한 불균형 구성에서, vSMP Foundation 소프트웨어는 OS 에서는 낮은 속도의 프로세서들을 노출하지 않는 동안에는 항상 가장 빠른 프로세서들을 병합하여 사용한다.
이러한 구성은 비용과 전력의 손실은 절감하면서, 최대 사이즈의 메모리와 최고의 성능을 발휘할 수 있게 한다. 마찬가지로, 사용자는 어플리케이션의 요구에 따라 I/O를 구성할 수 있으며, 따라서 업계 최고의 유연한 고성능 x86 시스템을 구비할 수가 있게된다. 이러한 비용/성능의 두마리 토끼를 모두 잡아냄으로서, vSMP Foundation 을 사용한 시스템은 고객에게 최고의 비용 효율성을 제공할 것이다.

Performances (http://www.scalemp.com/performance)


일반 - 메모리 대역폭 테스트

Memory Bandwidth



Life Science

Computational Chemistry




Computational Chemistry



Bio Informatics






Manufacturing

Fluid Dynamics




Weather Forecast

MOM4 - CM2P1:1 MODEL DAY



Numerical Simulations

Mathworks MATLAB





정리.

그런 생각을 해 본다.  GPGPU를 사용한 전통방식의 클러스터가 빠를까, 여러대의 머신을 하나로 클러스터링한 ScaleMP 의 클러스터가 빠를까. 그리고 또 ScaleMP가 향후 GPGPU 를 그들의 가상 OS 레벨에서 지원하게되면 또 어떻게 될까.  또, 이렇게 묶여진 가상 OS를 다시 병렬로 묶을 수 있을까?  (128 node vSMP) -- MPII -- (128 node vSMP) 이렇게 말이다.

기존에 했던 포스팅들과는 달리, 무언가 새로운 패러다임이 나타난것 같아서 흥분했다. 위의 퍼포먼스 사이트에 가시면 SPEC CPU2006 과 같은 일반적인 벤치마크 도구의 결과도 볼 수 있다.


사실, 오픈소스 진영에서 만들기는 쉽지 않은 도구다. 물론 뭐 어떤건 쉬웠겠냐마는.  물론 이 상용 소프트웨어 역시 그 기반기술의 대부분이 오픈소스에 의존하고 있을 것이라는 추측을 해 본다. 이 도구가 얼마나 많이 알려지고, 또 도입 사례가 발생할지는 모르겠지만, 이 소프트웨어의 HCL을 충족하는 하드웨어를 기존에 사용중이었다면, 충분히 테스트 해 봄직 하다 라는 생각을 해 본다. 더군다나 클라우드와 클러스터를 위한 패키지들을 함께 제공하므로, 관심있으신 분들은 직접 홈페이지에서 정보를 얻어보시는것도 좋을 것 같다.



ScaleMP Home page
http://www.scalemp.com

( younjin.jeong@gmail.com , 정윤진 )










저작자표시 비영리
,

Cloud is not a magic carpet.

Techs
(younjin.jeong@gmail.com , 정윤진)


클라우드, 클라우드, 클라우드.

문득 그런 생각을 해 본다. 전혀 새로울 것 없는 이 클라우드에 왜 다들 목숨들을 이렇게 걸어 대시는지들.
4년전에 아마존 서비스 테스트 하면서 그런 생각을 했더랬다.  이거 뭥미... 이렇게 I/O성능 안나오고 퍼포먼스 떨어지는데다가 공인 IP 갯수 제한도 있고.. ELB도 없던 시절이니 RR DNS나 내부에 별도의 Reverse-Proxy 를 구성해 두고 밸런싱 처리하고.. 

3년전에 Windows Azure 를 테스트 하면서도 비슷한 생각을 했다. 내가 뭐 닷넷 개발자도 아니고. SQL Azure 이거 이 성능 가지고 어디다 쓰지 했던.


뭐, 일찍 해 봤다고 자랑하는건 아니다. 다만, 대부분의 업장에서 이제 클라우드가 어떤건지 어렴 풋이들 이해하고 있는 듯 보이고, 주로 그 구성이 IaaS의 구성에만 촛점이 맞추어져 있는 현실.

예나 지금이나 중요한건, 메인프레임을 쓰느냐 클라이언트-서버를 사용하느냐 클라우드를 사용하느냐 하는 문제가 아니다. 더 중요한건, 실제 서비스가 어떠한 구성을 가져야 하느냐에 대한 부분일 것이다. 보안이 중요하다 한들 기업 내부 인프라가 아닌 이상, 아니 심지어 기업 인프라라 해도 모바일을 지원하기 위한 관리된 개방성이 필요하다. 일관성이 중요하다 한들, 오늘이 상반기 결산일이 아닌 이상 영업 데이터가 은행 계좌 잔고만큼 중요할리없다. 영상이나 컨텐츠의 저장과 배포를 위해 내부 시스템에서 마이크로초 단위의 디스크 seek time이 반드시 매번 중요하지는 않다. 무엇을 어디에 배치하고, 어떤 구조로 서비스를 만들어 내느냐 하는 문제는 예전부터 있어왔던 고민이고, 예전부터 있어왔던 해법이고, 예전부터 잘 처리해야 했던 부분들이다.  그게 클라우드에 넘어오면서 옵션이 조금 더 많아지고, 어떤 부분에서는 제한적인 요소도 있기 때문에 혼동하기 쉽지만, 똥과 된장을 구분할 줄 안다면 주전자를 쓰다음으며 지니가 나오길 바라지는 않을 것이다. 

최근의 클라우드 광풍을 보면 다들 무슨 마법의 양탄자 쯤으로 생각하고 있는 것 같다. 동시에, 마법의 양탄자가 아니었다는 사실을 깨닫고 빠르게 포기하거나 그 효용성 자체에 의문을 제기하는 사람들도 많은듯 하다.


주걱으로 국을 뜨려하고, 숟가락으로 라면을 먹으려 하는데 그게 쉬울턱이 있나.


예나 지금이나 컴퓨팅의 본질은 다르지 않고, 빠른 서비스를 위한 인프라 구성의 핵심 부분은 그 컨셉의 측면에 있어서 대동소이하다.  4메가 메모리와 5기가의 디스크를 가졌던 서버 시스템들에서 개발하던 빠른플리케이션의 코딩 방법이 42기가 메모리와 2페타 바이트를 가진 시스템을 위한 코딩과 핵심 컨셉이 다를리 없다. 여기에 클러스터링과 분산 컴퓨팅의 개념만 추가하면 무엇을 어떻게 만들어야 할 지에 대해서는 누가 굳이 그려주지 않아도 답은 뻔하지 않겠나. 

우주 왕복선에서 요구되는 연료의 연소와 노즐의 치밀한 각도 계산과 같은 실시간성이 요구되는 웹 서비스는 없다. 가급적 빠르면 좋은 시스템이라는 전제하에, 대부분의 비지니스 요구사항은 굳이 필요없는 RTOS와 같은 기능성을 요구하고 있지는 않은가 생각해 볼 일이다.

또, 그러한 요구사항을 클라우드 서비스에 들이대는 우를 범하지는 않아야 하겠다. 어플리케이션이 아무런 수정없이 클라우드에 적용되고, 기대했던 바와 같이 탄력성 있게 고객을 수용할 가능 성이 가장 높은 구조를 손에 꼽으라면, 아마도 클러스터링의 개념에 가장 충실했던 어플리케이션이 아니겠는가 싶다. 

클라우드에 서비스를 마이그레이션 할 때 가장 먼저 인정해야 하는것은, 비용이 아니라 바로 클라우드의 한계와 장애이다. 컴퓨팅 클라우드를 사용할때, 가장 높은 비용의 인스턴스를 사용할 것이 아니라 4메가 메모리를 가진 언제 고장나도 이상할 것이 없는 시스템 이라는 전제하에 구조를 짜야 할 것이다. 

하이브리드 클라우드 만드는데 기존 인프라와 빡세게 통신이 발생될 가능성이 있는 부분을 선택한다면 실패할 가능성이 높다고 말해주고 싶다.  캐시에 대한 고민없이 클라우드에 있는 디스크가 우리꺼보다 더 좋을꺼라는 환상을 가지고 있다면 얼른 깨어나시길.  아마존의 EBS가 Private Cloud 구성에 가장 중요한 덕목이 되었다면 어플리케이션 구조부터 다시 보시길 진심으로 권고하고 싶다.  그렇게 만드는거 아니라고. 

Share nothing 이라는 컨셉, Live Migration의 필요성등이 사설 클라우드를 만들고자 한다면 그 필요성에 비추어 반드시 재고되어야 할 것들이다. 아마존 클라우드의 각 서비스에 대한 분석을 제대로 했다면, 클라우드에서 구현해야 하고, 구현 할 수 있는 것이 무언인가에 대해 다들 이렇게 고민할 이유가 없다. 

진정 오라클을 잘 사용하고 있는 사업장에서는, Lock과 Latch가 가져오는 시스템 지연속도 등을 고려하고, 논리적인 관계는 쿼리와 어플리케이션에 녹아있지만 실제 FK를 걸어서 사용하지는 않는다.  내부 쿼리 처리가 어찌나 빠른지 페이지를 열면 데이터베이스에서 뽑아져 나오는 정보는 이미 페이지에 표시되어 있고, 이미지가 천천히 올라와 주신다. 이정도로 데이터베이스를 사용할 줄 아는 조직, 그렇게 많이 못봤다.  다들 오라클 주머니만 채우고 있지 않나.  

클라우드에 서비스를 구성 할 지 말지를 고민하기 전에, 서비스가 어떤 서비스인지 부터 고민하고 어떻게 인프라가 구성되어야 하는지에 대한 밑그림이 먼저 그려져야 하지 않겠는가. 

좋든 싫든, 또 지난시절 언제나 그래왔듯이 컨셉을 이해하고 그 구현을 고민하는 사람들에게는 지난날의 시스템도 이미 충분히 잘 동작하고 있을 것이다. 또 이런 시스템을 굴리고 있는 조직에서는 주변에서 하도 떠들고 있는 클라우드에 마이그레이션이 어떻게 되어야 하는지, 어떤 부분을 적용할 수 있는지의 여부도 면밀히 살펴보고 있을 것이다.  이런 분들에게는 이 새로운 환경은 그저 필요에 의해서 사용되고, 효율적으로 사용 될 것임을 믿어 의심치 않는다. 

대기업의 기존 인프라는 클라우드가 필요 없을 것이다 라는 식으로 이야기 하는 분들이 있는데, 당장 옮기기는 힘들긴 하지만, 그런건 단정 지을 수 있는게 아니다. 지금의 시스템들을 언제까지나 사용할 리도 없고, IBM pSeries를 다음번에 매번 구매해야 할 필요성이 있는건 아니다. 세상의 모든 데이터베이스가 RDBMS만 되어야 하지 않는다면, 자연히 클라우드는 아니라도 클러스터의 필요성은 생겨날 것이다. 

물론 컨셉을 이해하고 적용하시는 분들도 계시겠지만, 또 마케팅과 인문과학 출신으로 도배된 IT조직에서 귀까지 닫고 있는건 그들 사정이겠지만, 자꾸 말도 안되는 소리를 하는 분들이 있어 답답함에 간단히 적어본다.

원래 꼭 해야 했던건, 그게 클라우드라고 해서 안해도 되는건 아니다. 다만, 원래 꼭 해야 되는걸 하지 않았을때 클라우드는 예전보다 더 심한 좌절과 프로젝트의 처절한 실패만을 불러올 뿐이다. 서비스의 클라우드 마이그레이션은 일견 쉬워 보일지 모르겠으나, 그 기술적 진입장벽은 전보다 높아졌음을 이해할 필요가 있을 것이다. 한가지 더 중요한 사실은, 클라우드는 또 하나의 새로운 인프라 형태일 뿐이지 기존의 모든 것을 완전히 대체 할 수 있는 무언가는 아니다. 필요한곳에 적절히 사용 할 때, 비용과 성능, 그리고 가용성의 여러마리 토끼를 잡을 수 있을 것이다. 

국자는 국 뜨는데 쓰자. 

( younjin.jeong@gmail.com, 정윤진)

 
저작자표시 비영리
,

티스토리툴바