셀/B.E. 컨테이너 가상화, Part 1: 개념, 아키텍처, 도구

문서 옵션 JavaScript가 필요한 문서 옵션은 디스플레이되지 않습니다. 토론 영어원문  제안 및 의견 피드백

난이도 : 중급

Christian Kaiser, 리서치 인턴, IBM
Christian Rund, 연구 개발 엔지니어, IBM

2008 년 4 월 29 일

이 연재는 하드웨어 자원에 초점을 맞춘 컨테이너 가상화(또는 운영체제 가상화)로 알려진 소프트웨어 가상화 형태와 오픈 소스 프로젝트인 OpenVZ를 설명합니다. 이 연재물은 소프트웨어 방법론을 통해 셀/B.E. 프로세서 가상화에 필요한 모든 컴포넌트와 기법을 상세하게 개괄합니다. 첫 번째 기사는 관련된 기본 개념을 설명하고, OpenVZ와 셀/B.E. 아키텍처의 독특한 특성과 함께 동작하는 원리를 설명하고, 몇 가지 OpenVZ 도구 사용법을 다룹니다.

들어가기

가상화는 혁명적인 기술이다. 소프트웨어 가상화는 2007년에 가장 많이 논의된 IT 주제 중 하나다. 이번 짧은 연재에서 컨테이너 가상화(또는 운영체제 가상화)라고 불리는, 하드웨어 자원과 관련한 셀 브로드밴드 엔진 프로세서(셀/B.E.로 줄여서 부른다)를 위한 효율적인 가상화 방법을 설명한다. 또한 OpenVZ 프로젝트에 대해서도 설명한다. OpenVZ는 리눅스(Linux®)에 컨테이너 가상화 기능을 추가하는 오픈 소스 프로젝트다. OpenVZ의 상용 버전은 SWSoft 사가 만든 Virtuozzo다.

이번 기사에서는 셀/B.E. 프로세서를 소프트웨어 방법론으로 가상화하는 데 필요한 지식을 소개한다. 컨테이너 환경 내부에서 셀/B.E. 플랫폼을 활용하기 위해 변경이 필요한 OpenVZ 리눅스 커널 인터페이스를 소개한다. 또한 셀/B.E. 환경에서 컨테이너 가상화 효율성을 보여주기 위한 측정 보고서도 살펴볼 것이다.

위로

OpenVZ와 셀/B.E. 프로세서 이해

OpenVZ는 리눅스에서 컨테이너 가상화를 지원하기 위한 오픈 소스 소프트웨어 구현이다. OpenVZ는 두 가지 구성 요소로 이뤄져 있다.

• OpenVZ 리눅스 커널
• OpenVZ 사용자 영역 도구

OpenVZ 프로젝트의 주요 목표는 가상 리눅스 운영체제 인스턴스를 동작시키는 격리된 컨테이너 생성이다. 모든 컨테이너에는 단일 가상화 커널에 접근할 권한이 있다. 이 커널을 제공하는 호스트 시스템은 CPU, 메모리, 디스크 공간, 네트워크라는 가상화된 핵심 디바이스 네 가지를 다룬다. 또한 디바이스 하나를 컨테이너에 직접 전달해 디바이스를 소유한 컨테이너를 제외한 나머지 모든 컨테이너와 호스트 시스템에서 해당 디바이스에 접근하지 못하도록 만들 수도 있다(즉, 전용 디바이스 할당 지원).

그림 1은 세 컨테이너 인스턴스를 격리한 모습을 보여준다(각각 VS-1, VS-2, VS-3로 이름이 붙어있다). 세 컨테이너는 같은 OpenVZ 리눅스 커널을 공유한다. 참고자료를 살펴보자.

이제 셀/B.E. 프로세서에 익숙해질 차례다. 이 프로세서는 하이브리드 슈퍼컴퓨터에서 특수 제작한 투박한 임베디드 장비와 소니 플레이스테이션 3 게임 콘솔에 이르기까지 다양한 제품에 들어간다. 이 프로세서는 범용 Power Architecture™ 코어에 멀티미디어와 벡터 응용 분야 속력을 높이는 SPU를 결합했다. 단정도 부동소수점 성능은 SPU당 25.6기가플롭스에 이르므로 셀/B.E. 프로세서는 종종 칩 하나로 만든 슈퍼컴퓨터라고 부른다.

그림 2는 셀/B.E. 프로세서 기본 아키텍처를 개괄한다.

기본 아키텍처는 전통적인 메모리 하위 시스템과 함께 동작하는 PowerPC 코어인 PPE(Power Processing Element)와 EIB(Element Interconnect Bus)라는 고 대역폭 내부 연결 버스에 물려있는 SPE(Synergistic Processing Element) 여덟 개로 구성되어 있다. 각 SPE는 SPU(Synergistic Processing Unit), SPE 자료와 명령을 담고 있는 256KB 지역 저장소(LS), 메인 메모리와 SPE의 LS 사이에 DMA 전송을 처리하는 MFC(memory flow controller)로 구성되어 있다. PPE는 운영체제 동작만 지원한다. 현재 리눅스는 셀/B.E. 기능을 활용하는 유일한 운영체제다.

위로

컨테이너 가상화와 셀/B.E. 프로세서 이해하기

그림 3은 셀/B.E. 프로세서의 파티셔닝을 묘사한다.

컨테이너는 시스템에서 사용 가능한 전용 물리 SPU에 접근할 권한을 부여받았다. 컨테이너에서 접근 가능한 SPU는 할당 시점에서 호스트 시스템이나 다른 컨테이너 접근이 불가능하다. 각 컨테이너는 소유한 SPU만 사용한다. 이렇게 하려면 네 가지 준비사항이 필요하다.

1. SPU 파일 시스템(spuf)을 가상화한다. spuf는 컨테이너 내부에서 접근 가능해야 하며, 각 컨테이너는 자신을 생성한 SPE 스레드만 볼 수 있어야 한다.
   
   
2. 2.6 리눅스 커널이 제공하는 가상 파일 시스템(sysfs)을 조정한다. 컨테이너 내부의 sysfs는 할당할 SPU에 대한 /sys/devices/system/spu 내부에 올바른 디렉터리 항목을 포함해야 한다. libspe2는 이 디렉터리 항목을 사용해 컨테이너 내부에 있는 사용 가능한 SPU 숫자를 센다.
   
   
3. SPU 스케줄러를 수정한다. SPU 스케줄링을 변경해 컨테이너 내부에서 만들어진 SPE 스레드가 동일 컨테이너에 전용으로 지정한 SPU 내부에서만 동작하도록 해야 한다.
   
   
4. OpenVZ 도구를 변경한다. OpenVZ 도구에 포함된 vzctl 도구는 SPU를 컨테이너에 할당하고 컨테이너의 SPU를 할당 해제하는 기능을 지원해야 한다. 할당과 할당 해제는 컨테이너 실행 중에 작동해야 한다.

공유 가상화 디바이스 개념은 그림 4와 같이 모든 컨테이너가 접근 가능한 디바이스를 의미한다.

컨테이너가 전체 디바이스에 얼마나 오랫동안 얼마나 많은 디바이스에 접근할지를 통제하는 메커니즘이 필요하다. 단일 SPU를 전체가 공유하기란 불가능하므로, 컨테이너는 접근 가능한 주기 동안에 SPU를 공유한다.

구현은 다음 네 단계를 따라야 한다.

1. SPU 파일 시스템(spuf)을 가상화한다. spuf는 컨테이너 내부에서 접근 가능해야 하며, 각 컨테이너는 자신을 생성한 SPE 스레드만 볼 수 있어야 한다.
   
   
2. 가상 파일 시스템(sysfs)을 조정한다. 컨테이너 내부의 sysfs는 할당할 SPU에 대한 /sys/devices/system/spu 내부에 올바른 디렉터리 항목을 포함해야 한다. 더 나은 해법으로 모든 SPU에 접근할 수 있는 컨테이너를 시스템에 설치해 /sys/devices/system/spu 디렉터리가 호스트 시스템과 모든 컨테이너 내부에 똑같은 항목을 유지하도록 만든다.
   
   
3. SPU 스케줄러를 수정한다. SPU 스케줄링을 변경해 컨테이너 내부에서 만들어진 SPE 스레드가 특정 시간 동안 시스템에서 사용 가능한 SPU 내부에서만 동작하도록 만들어야 한다. OpenVZ 팀이 일반적인 프로세스를 위해 구현한 2단계 Fair CPU 스케줄러와 비슷한 스케줄링 알고리즘은 SPE 스레드를 위해 설계되었다. 심지어 완전히 다른 스케줄링 알고리즘을 배포할 수도 있다.
   
   
4. OpenVZ 도구를 변경한다. OpenVZ 도구에 포함된 vzctl 도구는 컨테이너 단위로 SPU 실행 시간 설정이 가능해야 한다. 이런 설정값은 컨테이너 실행 도중에 변경이 가능해야 한다.

이제 spufs를 살짝 들여다보자.

spufs 활용하기

spufs는 잘 알려진 또 다른 가상 파일 시스템(VFS)인 procfs와 비교가 가능하다. procfs는 리눅스에서 등장한 첫 번째 추상화된 파일 시스템으로 간단한 방식으로 프로세스 정보를 표현할 수 있다. procfs가 CPU에서 동작하는 프로세스를 표현하는 반면 spufs는 셀/B.E. 프로세서에 탑재된 SPU에서 동작하는 스레드를 표현한다.

spufs는 특수 목적으로 만들어진 파일 시스템이다. spufs는 셀/B.E. 프로세서에서 SPU를 통제할 목적으로 개발된 VFS다. spufs에 나타나는 모든 디렉터리는 논리적인 SPE 문맥이다. 이런 SPE 문맥은 물리적인 SPE처럼 취급한다. 문맥 속성은 디렉터리 내부에서 파일로 표현한다. SPE 문맥에 접근하면 메모리에서 저장된 상태나 실제 SPE를 직접 다룬다. SPU 프로그램을 시작하려면 SPU ELF 실행 파일을 SPE의 LS로 옮겨 spu_run 시스템 호출을 수행한다.

셀/B.E. SPU에서 동작하는 프로그램과 같이 셀/B.E. 전용 코드를 리눅스에서 수행하려면, spufs를 사용해야만 한다. 리눅스에서 셀/B.E.의 SPU를 사용하도록 프로세스를 시작하는 다른 방법은 없다.

Listing 1은 ls 명령을 실행하기 전에 셀 SDK에 들어있는 fft 예제 프로그램을 두 SPE 스레드로 동작시킨 상황을 보여준다. /spu는 spufs를 마운트한 지점이다.

                
[root@c02b12-0 ~]# ls /spu
spethread-20914-25296904 spethread-20914-25297464

[root@c02b12-0 ~]# ls /spu/*
/spu/spethread-20914-25296904:
cntl decr_status event_mask fpcr ibox_info lslr mbox_info mem mss
object-id proxydma_info regs signal1_type signal2_type wbox wbox_stat
decr dma_info event_status ibox ibox_stat mbox mbox_stat mfc npc physid
psmap signal1 signal2 srr0 wbox_info

/spu/spethread-20914-25297464:
cntl decr_status event_mask fpcr ibox_info lslr mbox_info mem mss
object-id proxydma_info regs signal1_type signal2_type wbox wbox_stat
decr dma_info event_status ibox ibox_stat mbox mbox_stat mfc npc physid
psmap signal1 signal2 srr0 wbox_info

첫 번째 명령 실행 결과는 프로세스 ID(PID)와 함께 각 SPE 스레드마다 디렉터리 하나(kobject)와 이 디렉터리 이름에서 SPE 스레드에 대한 스레드 ID를 보여준다. 두 번째 결과는 양쪽 디렉터리 내부에 있는 파일을 보여준다.

그림 5는 두 가지 ELF 실행 파일 유형을 어떻게 처리하는지 보여준다.

SPE 목적 파일 형태로 존재하는 SPE 실행 파일은 물리적인 SPE에서 실행하는 SPE 스레드로 묶인다. 특수한 SPE 스케줄러는 물리적인 SPE에서 어떤 SPE 스레드를 언제 수행할지 결정한다. PPE 목적 파일은 JS21 블레이드 서버와 같은 표준 PowerPC® 아키텍처처럼 취급된다. PPE 목적 파일은 표준 리눅스 스레드에 묶여서 커널에 구현된 리눅스 스케줄러가 스케줄링한다. 따라서 PPE에서 동작하는 응용 프로그램에 대해서는 특별히 새로운 내용이 없다.

위로

셀/B.E. SDK와 libspe 이해하기

셀/B.E.를 위한 SDK는 지금 버전 3.0이 나와있다(셀 자료 센터 다운로드에서 최신 버전을 구하자). 셀/B.E. SDK는 셀/B.E. 프로세서를 사용하도록 응용 프로그램을 개발하는 과정에 필요한 모든 도구를 포함한다. 여러 도구 중에서 SDK는 다양한 컴파일러와 링커, (libspe와 같이) 개발을 단순하게 만드는 라이브러리, SPU, MFS, LS와 같은 셀/B.E. 아키텍처와 밀접한 기능을 활용하는 예제 프로그램을 포함한다.

이 시점에서 libspe(libspe1과 libspe2)가 spufs를 사용하는 유일한 코드다. libspe는 SPE에서 동작하는 셀/B.E. 아키텍처용 코드를 개발하기 쉽게 만들어주는 프레임워크다. spufs는 ELF 실행파일을 SPE의 LS로 복사해 spu_run 시스템 호출을 불러주므로 SPE에서 일어나는 내부 동작 원리를 몰라도 된다.

그림 6은 셀/B.E. 프로세서를 사용해 리눅스에서 구현한 계층적 확장을 보여준다.

그림은 커널 영역에서 구현된 spufs 파일 시스템을 사용자 영역에서 활용하는 libspe(SPE Management Runtime Library)를 보여준다.

위로

sysfs 이해하기

sysfs는 원래 커널이 알고 있는 모든 디바이스와 드라이버 정보를 보여줄 목적으로 리눅스 커널에 만든 드라이버 파일 시스템이다. sysfs는 procfs보다 디바이스와 드라이버 접근을 좀더 깔끔하게 수행할 목적으로 설계되었다. sysfs는 kobject 자료 구조(각각은 디렉터리) 계층과 속성 집합(kboject 구조체 형태로)을 파일 형태로 보여주는데, 파일은 일반적으로 텍스트 문자열로 인코딩된 값 하나만 포함한다.

예를 들어, Listing 2는 QS21 셀/B.E. 블레이드에서 살펴본 /sys/devices/system/spu 디렉터리 목록이다.

                
[root@c02b12-0 ~]# ls /sys/devices/system/spu/
spu0  spu1  spu10  spu11  spu12  spu13  spu14  spu15  spu2  spu3  spu4  spu5  spu6
spu7  spu8  spu9
[root@c02b12-0 ~]#

Q21 셀/B.E. 블레이드는 각각 SPU 여덟 개를 탑재한 두 셀/B.E. 프로세서를 포함하고 있으므로, 블레이드에는 총 SPU 16개가 들어간다. 살펴보면 알겠지만 /sys/devices/system/spu 디렉터리는 각 SPU마다 디렉터리 하나씩을 포함한다. libspe2는 이 디렉터리 항목을 사용해 시스템에 존재하는 물리적으로 사용 가능한 SPU 숫자를 센다.

위로

OpenVZ 커널 이해하기

OpenVZ 커널은 변경된 리눅스 커널로 격리된 운영체제 컨테이너 환경을 포함하도록 기능이 추가되었다. 여기에 컨테이너 복원 지점 설정과 자원 관리를 제공한다. 각 컨테이너는 물론이고 심지어 호스트 시스템이 같은 공유 가상 커널을 활용한다는 사실을 염두에 두자.

각 컨테이너마다 다음과 같이 커널이 제공하는 독자적인 자원 집합이 존재한다.

• 파일: 시스템 라이브러리와 응용 프로그램
• 가상 파일 시스템: procfs와 sysfs
• 사용자와 그룹: 각 컨테이너는 독자적인 루트 사용자와 다른 사용자/그룹을 포함한다.
• 프로세스 트리: 컨테이너에는 가상화된 PID(init PID는 1이다)로 독자적인 프로세스가 떠 있다.
• 네트워크: 가상 네트워크 디바이스는 독자적인 IP 주소, 라우팅 정보, 필터 규칙을 유지한다.
• 디바이스: 몇몇 디바이스는 가상화되어 있다. 필요하다면, 컨테이너에게 실제(가상이 아닌) 디바이스 접근이 가능하도록 권한을 부여할 수 있다.
• IPC 객체: 세마포어, 메시지, 공유 메모리

자원 관리

다양한 자원 유형에 대한 관리가 필요하다.

• 디스크 할당: OpenVZ는 2단계 디스크 할당을 도입해 컨테이너에 제공할 디스크 공간을 제한할 수 있으며, 컨테이너는 다시 자신의 환경에 할당을 걸 수 있다.
• CPU 스케줄러: Fair CPU 스케줄러는 또한 2단계 메커니즘을 사용한다. 1단계로 특정 컨테이너가 CPU 시간을 얼마나 사용할지를 정의할 수 있는 컨테이너 단위로 환경 설정 가능한 스케줄러를 둔다. 2단계로 컨테이너 환경 내부에서 프로세스 스케줄링을 맡고 있다.
• 사용자 카운터: 컨테이너 자원을 세고, 제약을 가하고 보장하는 집합이다. 메모리와 IPC 공유 메모리/네트워크 버퍼와 같은 다양한 커널 내부 객체를 관리하는 매개변수가 20여개 존재한다.

복원 지점 설정

복원 지점 설정은 또 다른 핵심 기능이다. 복원 지점 설정과 복원은 살아있는 상태에서 이주하기 위한 필수 기능이다. 복원 지점 설정은 컨테이너를 잠시 얼린 다음에 완전한 상태를 디스크 파일에 저장하는 과정이다. 복원은 복원 지점 설정의 반대 기능이다. 살아있는 상태에서 컨테이너를 이주하려면 특정 호스트에서 컨테이너에 복원 지점을 설정하고, 다른 호스트 시스템에서 복원하는 과정을 밟으면 된다.

그림 7은 살아있는 이주와 복원 지점 설정/복원 프로세스 사이의 차이점을 보여준다.

그림 7은, 살아있는 이주는 단일 기능인 데 비해 복원 지점 설정과 복원은 양쪽 하드웨어 노드에서 접근 가능한 추가적인 저장소가 필요한 서로 다른 기능임을 보여준다.

위로

vzctl과 다른 OpenVZ 도구 활용하기

핵심 OpenVZ 도구는 vzctl이며, 컨테이너 환경을 관리하기 위한 고수준 명령행 인터페이스다. vzctl은 가상 운영체제 환경을 생성하고 시작하고 멈추고 제거하기 위해 사용된다. 이를 컨테이너 생명주기라고 부른다.

vzctl은 또한 IP 주소, 메모리, 컨테이너 환경이 사용할 수 있는 CPU 시간 같은 다양한 컨테이너 자원을 관리하는 데도 쓰인다. 대다수 매개변수는 컨테이너 동작 과정에서 설정하고 변경한다. 동적 변경은 일반적으로 플랫폼 가상화와 같은 다른 가상화 기법에서는 불가능하다.

컨테이너 내부가 아닌 호스트 시스템에서만 vzctl 도구 사용이 가능하다.

vzctl 이외에, OpenVZ 컨테이너를 관리하기 위한 많은 도구가 있다. 이런 도구는 OpenVZ에서 지원하는 셀/B.E.에 대한 가상화와는 상관이 없다. OpenVZ 사용자 지침서(참고자료 참조)에서 컨테이너 환경의 일반 관리에 대해 더 많은 정보를 찾을 수 있다. 참고로 이 연재 기사를 쓴 저자는 POWER™를 위한 OpenVZ 지침서를 썼다.

위로

Part 2를 위한 준비

Part 2는 그림 3에서 보여주는 전용 가상화(파티셔닝) 개념 구현을 설명한다.

위로

감사의 글

그림 1에 나온 이미지 사용을 허락한 "Mehrarbeit fur CPUs"(Linux Magazin, 2006년 4월) 저자에게 감사한다.

참고자료

• RSS 피드를 구독해 이 연재물이 새로 등록되면 통보를 요청하기 바란다.(더 많은 정보는 developerWorks 내용에 대한 RSS 피드 정보를 살펴보자.)
  
  
• OpenVZ와 가상화에 대해 "Virtualization in Linux"(2006년 9월)를 찾아보기 바란다. OpenVZ에 세 가지 핵심 가상화 접근 방법(에뮬레이션, 의사 가상화, 운영체제 수준 가상화)를 다룬다.
  
  
• Arnd Bergmann이 쓴 "Spufs: The Cell Synergistic Processing Unit as a virtual file system"(developerWorks, 2005년 6월)을 읽고 셀/B.E.에서 리눅스가 동작하도록 허용하는 SPU 파일 시스템 인터페이스 세부 내역을 확인한다. Bergmann이 쓴 "How to not invent kernel interfaces"(LinuxConf Europe, 2007년 7월에 실린 논문)는 커널 코드가 사용자 영역 인터페이스 형식을 선택하는 방법을 설명한다. Bergmann은 또한 스레드 모델, 리눅스 실행 전략, PPU/SPU 실행 요구 사항, spufs, 시그널 처리를 다루는 virtual class on Linux on Cell/B.E. platforms를 작성했다.
  
  
• Daniel Hackenberg가 만든 발표 자료인 "Performance Measurements on Cell SMP Systems"(Center for Information Services and High Performance Computing's Cell/B.E. cluster meeting, 2007년 5월)를 찾아 매트릭스 연산, XDR DMA 대역폭, SPE-to-SPE DMA 대역폭과 같은 성능 척도를 살펴본다.
  
  
• Duc Vianney가 쓴 "Cell Software Solutions Programming Model" 발표 자료(2006년 3월)를 읽고 PPE와 SPE 중심 셀/B.E. 프로그래밍 모델 쟁점, 함수 오프로드, DMA와 계산 중첩, 이질적인 멀티 스레드 관련 정보를 얻자.
  
  
• 공통 패턴이라는 수단을 통해 기본 가상화 개념을 다루는 소개 기사는 "가상화: 패턴의 관점에서 본 가상화 (한글)"(한국 developerWorks, 2006년 6월)다. "가상 리눅스 (한글)"(2006년 12월)는 리눅스 관점에서 다양한 가상화 형태(그리고 현재 가상화 프로젝트)를 설명한다.
  
  
• 의사 가상화에 대한 내용은 "coLinux를 이용한 가상화"(developerWorks, 2007년 3월)와 "QEMU를 이용한 시스템 에뮬레이션"(2007년 9월)을 읽어본다.
  
  
• SDK 3.0 최신 주제를 요약해 다루는 블로그 연재물을 살펴본다.
  • Introducing the Accelerated Library Framework (ALF)
  • Illustrating the 10 most important concepts of ALF
  • Introducing the Data Communication and Synchronization (DaCS) library services
  
  
• libspe2 개념, libspe2와 통신하고 기본적으로 SPE 프로세스를 관리하는 방법을 익히려면 "Changes in libspe: libspe2가 Cell Broadband Engine 프로그래밍에 미치는 영향"(developerWorks, 2007년 7월)을 읽어본다.
  
  
• "Introduction to the Cell Multiprocessor"(IBM Journal of Research and Development, 2005년)를 참조해 셀/B.E. 개괄, 다중 프로세서 역사, 프로그램 목적과 도전, 설계 개념, 아키텍처와 프로그래밍 모델, 구현에 대해 살펴본다.
  
  
• 리눅스 영역과 오픈 소스 영역을 포함한 다른 developerWorks 자료를 찾아 가상화와 관련된 흥미있는 자료를 살펴보기 바란다.
  
  
• 셀/B.E. 프로그램을 익히려면 다음 연재물을 살펴보자.
  • "Programming high-performance applications on the Cell/B.E. processor"
  • "PS3 fab-to-lab"
  • "The little broadband engine that could"
  
  
• 풍부한 매뉴얼, 명세를 제공하는 IBM 반도체 솔루션 기술 도서관에서 셀/B.E. 문서를 살펴보기 바란다.
  
  
• developerWorks 소식지를 구독해 최신 개발자 소식과 셀/B.E. 관련 소식을 매주 받아보자. 구독 과정에서 파워 아키텍처를 선택해서 소식지에 셀/B.E. 소식을 받도록 하자.
  
  

• SWsoft에서 ""OpenVZ 사용자 지침서" 버전 2.7.0-8을 구한다.
  
  
• 다양한 유닉스 시스템 성능을 비교하기 위한 이식성 높은 벤치마크를 포함해서 성능 분석을 위한 LMbench 도구 슈트를 사용해본다.
  
  
• power.org에서 제공하는 셀/B.E. 환경을 위한 4웨이 SIMD 단정도 복소수 FFT를 수행하는 예제 코드를 사용해본다.
  
  
• 최신 셀/B.E. SDK 릴리즈인 다중 코어 가속을 위한 SDK 3.0을 포함하여 셀/B.E. 개발 센터를 둘러보자. 이를 지원하는 문서 라이브러리도 있다.
  
  
• 셀/B.E.에 대한 최신 자료를 담고 있는 IBM developerWorks 셀/B.E. 엔진 자료 센터에서 셀/B.E. 관련 기사, 토론 포럼, 다운로드를 찾아보자.
  
  
• IBM에 연락해서 셀/B.E. 기반이나 특수 프로세스 기반 솔루션에 대해 알아보자.
  
  

• 포럼에 참여하기.
  
  
• OpenVZ 포럼에 질문을 올린다.
  
  
• 프로세서에 대한 기술 질문 대답을 얻기 위해 셀/B.E. 아키텍처 포럼을 살펴본다. 포럼에서 유용한 문제와 대답이 주기적으로 올라오며, 중요 질문과 대답은 "포럼 감시" 블로그 연재물에서 다시 한번 강조될 것이다.
  
  
• 파워 아키텍처 블로그를 살펴서 새소식, 내려받기, 도움이 되는 자원, 셀/B.E.와 다른 파워 아키텍처 관련 기술을 위한 이벤트 정보를 얻자. 인기있는 "포럼 감시" 블로그 연재(Q&A 정리), "FixIT" 기술 갱신, Infobomb 기술 요약 정리를 찾을 수 있을 것이다.

필자소개

		Christian Kaiser는 독일 아헨에 있는 RWTH 대학교에서 컴퓨터 공학을 공부했다. 2007년에 Kaiser는 독일 뵈블링엔에 위치한 IBM 독일 연구소에서 인턴으로 근무했다. IBM에서 인턴으로 근무하는 동안 셀/B.E. 프로세서에서 시각화 방법을 연구했다. 인턴을 마치고 Kaiser는 RWTH 아헨에서 운영체제 관련 논문을 마치러 돌아갔다. 논문 제목은 "Analysis of asynchronous collective communication in memory-coupled high-speed networks"다.

		Christian Rund는 독일 뵈블링엔에 있는 IBM 개발 연구소에서 근무하고 있다. Rund는 슈튜트가르트 대학교에서 컴퓨터 과학을 공부했으며, 스웨덴 웁살라 대학교를 1997년에 졸업했다. 학창 시절에 Rund는 독일 헤른베르크에 있는 IBM에서 실습생으로 일했다. 1988년 Rund는 슈투트가르트에 있는 란데스쩬트랄방크(도이체 분데스방크)의 시스템 개발 부서에 합류했다. 2001년에 Rund는 IBM에 합류해 zSeries FCP 채널을 위한 개발 팀에서 연구 개발 엔지니어로 일했다. 2006년 중반 셀/B.E. 기반 서버를 위한 호스트 펌웨어 개발 연구 엔지니어로 근무하고 있다.

기사에 대한 평가

보다 나은 서비스를 제공하기 위함이오니 잠시 짬을 내어 이 양식을 제출하여 주십시오. 귀하께서 원하시는 정보를 얻었습니까? 예 아니오 잘 모르겠음   이 페이지 개선을 위한 의견을 주십시오:   이 정보가 얼마나 유용했습니까? (1 = 전혀 도움이 되지 않음, 5 = 매우 유용함) 1 2 3 4 5

이 문서 북마킹 하기 mar.gar.in naver eolin del.icio.us

위로