pkg://Parallel-Processing-HOWTO-html.tar.gz:76146/Parallel-Processing-HOWTO-3.html
downloads
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
<META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
<TITLE>Linux Parallel Processing HOWTO: 리눅스 시스템의 클러스터(Clusters Of Linux Systems)</TITLE>
<LINK HREF="Parallel-Processing-HOWTO-4.html" REL=next>
<LINK HREF="Parallel-Processing-HOWTO-2.html" REL=previous>
<LINK HREF="Parallel-Processing-HOWTO.html#toc3" REL=contents>
</HEAD>
<BODY>
<A HREF="Parallel-Processing-HOWTO-4.html">다음</A>
<A HREF="Parallel-Processing-HOWTO-2.html">이전</A>
<A HREF="Parallel-Processing-HOWTO.html#toc3">차례</A>
<HR>
<H2><A NAME="s3">3. 리눅스 시스템의 클러스터(Clusters Of Linux Systems)</A></H2>
<P>
<P>이 섹션은 리눅스를 사용한 클러스터 병렬 처리의 개관을 제공하려고 시도할
것이다. 클러스터는 현재 가장 인기있는 것이자 가장 다양하다. 이것은
전통적인 워크스테이션들을 여러대 묶은 네트웍(<B>NOW</B>; network of
workstations)에서 이제 막 프로세서 노드로써 리눅스 피씨들로
사용하기 시작한 커스텀 병렬 기계까지 있다. 또한 리눅스 기계들의
클러스터를 사용하는 병렬 처리를 위한 많은 소프트웨어 지원들이 있다.
<P>
<H2><A NAME="ss3.1">3.1 왜 클러스터인가(Why A Cluster)?</A>
</H2>
<P>
<P>클러스터 병렬 처리는 다음과 같은 중요한 장점들을 제공한다:
<UL>
<LI>클러스터에 있는 각 기계들은 넓은 범위의 다른 컴퓨팅 어플을 사용할 수
있는 완전한 시스템이 될 수 있다. 그래서 많은 사람들이 클러스터 병렬
컴퓨팅은 사람들의 책상 위에서 할 일없이 놀고 있는 워크스테이션들의
"버려지는 시간들(wasted cycles)" 모두를 가져다 쓴다고 제안하게
되었다. 이런 시간들을 구하는 것은 실제 그렇게 쉬운 것이 아니다. 그리고
이것은 동료의 스크린 세이버를 느리게 할 것이다. 그러나 이것을 그렇게 될
수 있다.
</LI>
<LI>네트웍 시스템들이 최근 급증하는 것은 클러스터를 만들기 위한 하드웨어
대부분이 대용량으로, 이에 대응해서 결과적으로 낮은 "상품"
가격으로, 팔리고 있다는 것을 의미한다. 클러스터 하나에 한개의 비디오
카드, 모니터, 키보드가 필요하는 사실이 좀 더 비용을 아낄 수 있도록
한다(비록 초기 리눅스 설치를 수행할 때 클러스터의 각 기계들에 이들을
옮겨 가며 써야 하지만, 일단 실행되면 전형적인 리눅스 피씨는 "콘솔"을
필요로 하지 않는다). 이와 비교해서 SMP와 부속 프로세서는 훨씬 더 작은
시장에서 단위 수행 성능에 대한 더 높은 가격을 형성해가고 있다.
</LI>
<LI>클러스터 컴퓨팅은 <EM>아주 커다란 시스템</EM>까지 커질 수 있다. 현재까지
4개 이상의 프로세서들을 가지는 리눅스-호환 SMP를 찾는 것이 어려운 반면에
일반적으로 사용 가능한 네트웍 하드웨어는 16개 기계들까지 클러스터로 쉽게
묶을 수 있다. 조금만 작업하면 수백개 또는 심지어 수천개 기계들을
네트웍으로 묶을 수 있다. 사실 전체 인터넷이 하나의 커다란 클러스터로 볼
수 있다.
</LI>
<LI>클러스터 안에서 "고장난 기계"를 교체하는 것이 패러티가 잘못된 SMP를
고치는 것에 비해서 더 단순하다는 사실은 조심스럽게 디자인된 클러스터
설정에 좀 더 높은 가용성을 제공한다. 이것은(높은 가용성은) 중요한 서비스
중단을 견딜 수 없는 특별한 어플리케이션들에 대해서 중요할 뿐만이 아니고,
단일-기계 고장이 자주 일어나는 충분한 프로세스들을 가진 시스템들의
일반적인 사용에도 중요하다. (예를 들어서 PC 고장의 평균 시간이
2년일지라도 32개 기계를 갖는 클러스터에서 적어도 한 기계가 6개월 이내에
고장날 확률은 꽤 높다.) </LI>
</UL>
<P>
<P>좋다. 클러스터는 프리이거나 싸고 아주 커질 수 있으며 가용성이 높다...
그렇다면 왜 모든 사람들이 클러스터를 사용하지 않는가? 글쎄
거기에는 다음과 같은 문제들이 존재한다:
<P>
<UL>
<LI>
아주 작은 예외들을 제외하고 네트웍 하드웨어는 병렬 처리를 위해서 고안된
것이 아니다. 전형적으로 SMP와 부속 프로세서에 비해서 지체는 아주 높고
대역폭은 상대적으로 낮다. 예를 들어서 SMP 지체는 일반적으로 몇
마이크로초(역자주: 100만분의 1초)를 넘지 않지만 클러스터의 경우
일반적으로 수백 내지 수천 마이크로 초가 걸린다. SMP 통신 대역폭은 대개
100MBytes/sec이 넘는다; 비록 가장 빠른 네트웍 하드웨어(예, "기가비트
이더넷")가 이에 필적할 속도를 제공하긴 하지만 가장 일반적으로 사용되는
네트웍은 이보다 10에서 1000배 정도 더 느리다.
네트웍 하드웨어의 성능은 <EM>고립된 클러스터 네트웍</EM>에 충분할 만큼
낮다(The performance of network hardware is poor enough as an isolated
cluster network). 네트웍이 다른 트래픽으로부터 고립되어 있지 않다면,
클러스터로 디자인된 시스템보다 "네트웍으로 묶은 기계들"을 사용한 경우가
더 많기 때문에 성능은 아주 악화될 수 있다.
</LI>
<LI>클러스터를 단일 시스템으로 취급하는 소프트웨어 지원은 거의 없다. 예를
들어서 <CODE>ps</CODE> 명령은 단일 리눅스 시스템에 실행 중인 프로세스들에
대해서만 보고할 뿐 리눅스 시스템들로 만들어진 클러스터 전체에서 실행
중인 모든 프로세스들에 대해서 보고하지 않는다. </LI>
</UL>
<P>
<P>그래서, 클러스터는 굉장한 잠재력을 제공하지만 이 잠재력이 대부분의
어플리케이션들에 대해서 획득되기에는 아주 어려울 수 있다. 이런
환경에 적합한 프로그램들에 대해서 좋은 성능을 획득하도록 하는 많은
소프트웨어 지원이 있다는 것과 좋은 성능을 획득할 수 있는 프로그램들의
범위를 넓힐 수 있도록 특별히 설계된 네트웍들도 있다는 것은 좋은
소식이다.
<P>
<H2><A NAME="sec_NetworkHardware"></A> <A NAME="ss3.2">3.2 네트웍 하드웨어(Network Hardware)</A>
</H2>
<P>컴퓨터 네트워킹은 급증하고 있다... 이미 이것을 알고 있을 것이다.
네트워킹 기술과 제품들의 계속-증가하는 영역은 개발이 진행 중에 있고
대부분은 기계들(예, 각각 리눅스를 돌리는 피씨들)의 그룹에 병렬-처리
클러스터를 만드는 데 사용될 수 있는 형태로 사용 가능하다.
<P>불행하게도 어떤 네트웍 기술도 모든 문제들을 훌륭하게 풀지 못한다; 사실
접근, 비용, 성능의 범위는 얼른 봐서 믿기 힘들다. 예를 들어서 표준
상업적으로-가능한 하드웨어를 사용해서 네트웍으로 기계들을 묶는 데 드는
비용은 기계 당 적게는 5달러에서 많게는 4000달러까지 이른다. 제조자가
말하는 대역폭(delivered bandwidth)와 지체 시간 각각은 크기의 네가지
등급(four orders of magnitude)에 따라 변한다.
<P>특정 네트웍에 대해서 배우려고 하기 이전에 이런 것들은 바람처럼 쉽게
변한다는 것을 인식하는 것이 중요하다(리눅스 네트워킹 뉴스들에 대해서는
<A HREF="http://www.uk.linux.org/NetNews.html">http://www.uk.linux.org/NetNews.html</A>을 참조). 그리고 어떤
네트웍들에 대하 정확한 데이터를 얻는 것은 아주 어렵다.
특별히 확실하지 않는 곳에 저자는 물음표(<EM>?</EM>)를 놓았다. 이 주제를
연구하는 데 많은 시간을 썼지만 나는 내 요약(이 문서)이 잘못 투성이고
많은 중요한 것들을 빼먹었다는 것을 확신한다. 교정이나 추가해야 하는 것을
갖고 있다면
<A HREF="mailto:pplinux@ecn.purdue.edu">pplinux@ecn.purdue.edu</A>로 이메일을 보내주기 바란다.
<P>
<A HREF="http://web.syr.edu/~jmwobus/comfaqs/lan-technology.html">http://web.syr.edu/~jmwobus/comfaqs/lan-technology.html</A>에
있는 LAN Technology Scorecard와 같은 요약들은 많은 서로 다른 타입들의
네트웍과 LAN 표준들에 대한 특성들을 보여준다. 그러나 이 하우투에 있는
요약은 대부분 리눅스 클러스터를 만드는 데 관련이 있는 네트웍 특성들에
대해서 촛점을 맞췄다. 각 네트웍을 논의하는 섹션은 짧은 특성 리스트로
시작한다. 다음은 이런 엔트리들이 의미하는 바를 정의한다.
<P>
<DL>
<DT><B>리눅스 지원(Linux support):</B><DD><P>(이것에 대한) 답변이 <EM>no</EM>라면, 그 의미는 분명하다. 다른 대답들은
네트웍을 억세스하는 데 사용되는 기본 프로그램 인터페이스를
설명하려고 할 것이다. 대부분의 네트웍 하드웨어는, 전형적으로 TCP/UDP
통신을 지원하는, 커널 드라이버를 통해서 인터페이스된다. 어떤 다른
네트웍들은 커널을 거치지 않고서 지체 시간을 좀 더 줄이기 위해서 좀
더 직접적인 인터페이스들(예, 라이브러리)을 사용하기도 한다.
<P>
<P>
<P>몇년전 OS 호출을 통해서 부동 소숫점 유니트를 억세스 하는 것이 완전히
훌륭한 것으로 생각되어졌다. 그러나 이제 그것은 분명 우스운 것이다; 내
의견으로는 병렬 프로그램을 실행하는 프로세서들 간 각 통신이 OS 호출을
요구한다는 것은 어색한 것이다. 문제는 컴퓨터들이 아직도 이런 통신
메카니즘들을 통합하지 못했다는 것이다. 그래서 비-커널 접근은 이식성
문제들을 가지는 경향이 있다. 여러분은 가까운 미래에 이런 것에 대해서 좀
더 많은 것을 듣게 될 것이다. 대개 새로운 <B>Virtual Interface (VI)
Architecture</B>
<A HREF="http://www.viarch.org/">http://www.viarch.org/</A>의 형태로 듣게 될
것인 데 이것은 일반적인 OS 호출 계층을 피하는 대부분의 네트웍 인터페이스
작업들에 대한 표준화된 방법이다. VI 표준은 Compaq, Intel, 그리고
Microsoft에 의해서 지원받고 있으며 다음 몇 년 안에 SAN(시스템 영역
네트웍) 디자인에 대한 강한 충격이 될 것임에 틀림없다.
<P>
<DT><B>최대 대역폭(Maximum bandwidth):</B><DD><P>이것은 모든 사람이 신경쓰는 숫자이다. 나는 일반적으로 이론적으로 최선인
경우의 수치를 사용했다; 여러분의 마일리지는 변<EM>할 것이다</EM>.
<P>
<DT><B>최소 지체(Minimum latency):</B><DD><P>내 의견으로는, 이것은 모든 사람들이 대역폭보다 더 신경써야 할 수치이다.
다시 나는 비현실적인 최선인 경우(base-case) 수치를 사용했지만 적어도 이
수치들은 하드웨어와 소프트웨어 모두를 포함하는 <EM>모든</EM> 지체
소스들을 포함한다. 대부분의 경우 네트웍 지체는 몇 마이크로초이다; 수치가
크면 클수록 하드웨어와 소프트웨어 인터페이스들의 계층들이 비효율적이다는
것을 반영한다.
<P>
<DT><B>구입 방법(Available as):</B><DD><P>단순하게 말해서, 이것은 이 타입의 네트웍 하드웨어를 갖출 수 있는 방법을
설명한다. 상품들은 주요 구분 인자로 가격을 가지면서, 많은 벤더들에
의해서 살 수 있다. 다수-벤더에 의한 것들은 하나의 경쟁적인 벤더보다 좀
더 사기 쉽지만 이들은 중요한 차이와 잠재적인 호환성(interoperability)
문제들이 있다. 단일-벤더 네트웍은 공급자의 손에 완전히 종속된다(그러나
그들은 친철할 수도 있다). 퍼블릭 도메인 디자인이란 그것을 여러분에게 팔
사람을 찾지 못하더라도 부품들을 사서 그것을 만들 수 있다는 것을 말한다.
연구 프로토타입들은 말 그대로이다; 그들은 일반적으로 일반적으로 외부
사용자들에게 준비된 것이 아니거나 그들이 살 수 있는 것이 아니다.
<P>
<DT><B>사용된 인터페이스 포트/버스(Interface port/bus used):</B><DD><P>이 네트웍을 어떻게 접속(hook-up)할 것인가? 현재 가장 높은 성능과 가장
일반적인 것은 PCI 버스 인터페이스 카드이다. EISA, VESA 로컬 버스(VL
버스), 그리고 ISA 버스 카드들도 있다. ISA는 맨처음에 나온 것이고 아직도
낮은-성능의 카드들에 대해서 많이 사용되는 것이다. EISA는 많은 PCI
기계들에서 두번째 버스로 사용되고 있어서 몇가지 카드들이 있다. 오늘날 VL
물건들을 많이 볼 수 없을 것이다(비록
<A HREF="http://www.vesa.org/">http://www.vesa.org/</A>가
의견을 달리하지만 말이다).
<P>
<P>
<P>물론 여러분의 피씨의 케이스를 한번도 열어보지 않고 사용할 수 있는 어떤
인터페이스는 작은 매력 이상 가진다. IrDA와 USB 인터페이스들은 계속
빈번하게 나타나고 있다. 표준 패러럴 포트(SPP)는 프린터를 붙이는 데
사용되지만 ISA 버스의 외부 확장으로써 많이 사용되어 왔다; 이 새로운
기능은 EPP와 ECP 개선을 규정한 IEEE 1284 표준에 의해서 증진되었다. 또한
오래되고 신뢰성 있지만 느린 RS232 시리얼 포트가 있다. 나는 VGA 비디오
커넥터, 키보드, 마우스, 또는 게임 포트들을 사용해서 기계들을 연결하는
것을 알지 못한다... 그래서 여기에 없다.
<P>
<DT><B>네트웍 구조(Network structure):</B><DD><P>버스는 구리 선이거나 구리 선들의 모임이거나 광섬유이다. 허브는 여기에
꼽혀 있는 서로 다른 구리선/광섬유들을 연결하는 방법을 알고 있는 작은
박스이다; 스위칭 허브(switched hub)는 다수 커넥션들이 동시에 데이터를
전송하도록 하는 허브이다.
<P>
<DT><B>기계당 비용(Cost per machine connected):</B><DD><P>여기서 이런 수치들을 사용하는 방법을 말한다. 네트웍 커넥션을 세지 않고서
클러스터의 한 노드에 쓸려고 피씨를 사는 데 2000달러가 들었다고
가정해보자. 패스트 이더넷(Fast Ethernet)을 더하는 것은 노드당 약
2400달러가 든다; Myrinet을 대신 더하는 데에는 약 3800달러가 든다.
2만달러가 있다면 Fast Ethernet에 연결된 8개의 기계나 Myrinet에 연결돈
5개의 기계를 가질 수 있다는 것을 의미한다. 멀티 네트웍을 가지는 것도
아주 의미있을 수 있다; 예, $20,000로 패스트 이더넷과 TTL_PAPERS
둘 다 가지는 8개 기계들을 구매할 수 있다. 어플리케이션을 가장 빨리
실행할 클러스터를 만들 가능성이 가장 높은 네트웍이나 네트웍 집합을
선택하자.
<P>
<P>
<P>이것을 읽는 현재 이런 수치들은 틀릴 수도 있다... 제기럴 그들은 아마도
이미 틀렸을 것이다. 또한 양이 줄어들거나 특별 판매(special deal)등이
있을 수 있다. 그러나 여기서 언급된 가격들때문에 여러분이 아주 부적절한
선택을 하게끔 하기에 충분한 잘못된 것일 가능성이 적다. 여러분의
어플리케이션이 네트웍의 특별한 속성을 요구하거나 클러스터링된 피씨들이
상대적으로 비싼 것일 때에만 비싼 네트웍이 의미가 있다는 것을 아는 데는
박사 학위(비록 나는 하나 가지고 있지만 ;-)가 필요 없다.
</DL>
<P><EM>내 의견을 들었으므로 쇼와 함께 다음에....(Now that you have the
disclaimers, on with the show....)</EM>
<P>
<H3>아크넷(ArcNet)</H3>
<P>
<UL>
<LI>리눅스 지원: <EM>커널 드라이버</EM></LI>
<LI>최대 대역폭: <EM>2.5 Mb/s</EM></LI>
<LI>최소 지체: <EM>1,000 microseconds?</EM></LI>
<LI>구입 방법: <EM>멀티-벤터 하드웨어</EM></LI>
<LI>사용된 인터페이스 포트/버스: <EM>ISA</EM></LI>
<LI>네트웍 구조: <EM>스위치되지 않는(unswitched) 허브나 버스(논리적인
링)</EM></LI>
<LI>기계당 비용: <EM>$200</EM></LI>
</UL>
<P>ARCNET은 주로 내장 실시간 제어 시스템들에서 사용되기 위해서 고안된 지역
네트웍(LAN)이다. 이더넷과 비슷하게 네트웍은 물리적으로 버스에 붙인
탭이나 하나 이상의 허브들로 조직된다. 그러나 이더넷과 다르게 이것은
네트웍을 논리적으로 링으로 구축하는 토큰-기반 프로토콜을 사용한다. 패킷
헤더는 작다(3 또는 4바이트). 그리고 메시지들은 단일 바이트 데이터만큼
작게 전달될 수 있다. 그래서, ARCNET은 제한된 지연 등을 가지면서,
이더넷보다 좀 더 일관된 성능을 가진다. 불행하게도 이것은 이더넷보다 더
느리고 덜 유명하다. 그러면서도 더 비싸다.
<A HREF="http://www.arcnet.com/">http://www.arcnet.com/</A>에 있는 ARCNET Trade Association로부터 더
자세한 정보를 얻을 수 있다.
<P>
<H3>ATM</H3>
<P>
<UL>
<LI>리눅스 지원: <EM>커널 드라이버, AAL* 라이브러리.</EM></LI>
<LI>최대 대역폭: <EM>155 Mb/s</EM> (곧, <EM>1,200 Mb/s</EM>)</LI>
<LI>최소 지체: <EM>120 microseconds</EM></LI>
<LI>구매 방법: <EM>멀티-벤더 하드웨어</EM></LI>
<LI>사용된 인터페이스 포트/버스: <EM>PCI</EM></LI>
<LI>네트웍 구조: <EM>스위치 허브</EM></LI>
<LI>기계 당 비용: <EM>$3,000</EM></LI>
</UL>
<P>지난 몇년 동안 혼수 상태에 있지 않았다면 아마 ATM(비동기 전송 모드)가
어떻게 미래가.. 글쎄, 일종의 미래가 될 수 있는지에 대해서 많이 들었을
것이다. ATM은 HiPPI보다 더 싸고 패스트 이더넷보다 더 빠르며 전화
회사들이 제공하는 거리만큼 긴 거리에도 사용될 수 있다. ATM 네트웍
프로토콜은 또한 더 낮은-오버헤드 소프트웨어 인터페이스를 제공하도록,
그리고 작은 메시지들과 실시간 통신(예, 디지털 오디오와 비디오)을 좀 더
효과적으로 관리하도록 고안되었다. 이것은 또한 리눅스가 현재 지원하는
가장-높은 대역폭 네트웍들 중의 하나이다. 나쁜 소식은 ATM은 싸지 않고
벤더들 간에 호환성 문제가 아직 있다는 것이다. 리눅스 ATM 개발에 대한
개관은
<A HREF="http://lrcwww.epfl.ch/linux-atm/">http://lrcwww.epfl.ch/linux-atm/</A>에서 찾을 수
있다.
<P>
<H3>CAPERS</H3>
<P>
<UL>
<LI>리눅스 지원: <EM>AFAPI 라이브러리</EM></LI>
<LI>최대 대역폭: <EM>1.2 Mb/s</EM></LI>
<LI>최소 지체: <EM>3 microseconds</EM></LI>
<LI>구매 방법: <EM>상품 하드웨어</EM></LI>
<LI>사용된 인터페이스 포트/버스: <EM>SPP</EM></LI>
<LI>네트웍 구조: <EM>2개의 기계들 간 케이블</EM></LI>
<LI>기계당 비용: <EM>$2</EM></LI>
</UL>
<P>CAPERS(병렬 실행과 빠른 동기를 위한 케이블 어댑터; Cable Adapter for
Parallel Execution and Rapid Synchronization)는, 전기 컴퓨터
엔지니어링의 퍼듀 대학 학교(Purdue University School of Electrical and
Computer Engineering)에서의 PAPERS 프로젝트
<A HREF="http://garage.ecn.purdue.edu/~papers/">http://garage.ecn.purdue.edu/~papers/</A>의 부산물이다. 기본적으로
이것은 두 리눅스 피씨들에 대한 PAPERS 라이브러리를 구현하기 위해서, 일반
"LapLink" SPP-to-SPP 케이블을 사용하기 위해서 소프트웨어 프로토콜을
정의한다. 아이디어는 깍이지 않지만 가격을 더 낮출 수는 없다(역자주:
그만큼 싸다?). 시스템 보안을 개선하기 위해서 TTL_PAPERS와 마찬가지로
권고되는 마이너 커널 패치가 있다. 그러나 반드시 필요한 것은 아니다:
<A HREF="http://garage.ecn.purdue.edu/~papers/giveioperm.html">http://garage.ecn.purdue.edu/~papers/giveioperm.html</A>.
<P>
<H3>이더넷(Ethernet)</H3>
<P>
<UL>
<LI>리눅스 지원: <EM>커널 드라이버</EM></LI>
<LI>최대 대역폭: <EM>10 Mb/s</EM></LI>
<LI>최소 지체: <EM>100 마이크로초</EM></LI>
<LI>구매 방법: <EM>상품 하드웨어</EM></LI>
<LI>사용된 인터페이스 포트/버스: <EM>PCI</EM></LI>
<LI>네트웍 구조: <EM>스위치 또는 스위치 없는 허브, 또는 허브 없는
버스</EM></LI>
<LI>기계당 비용: <EM>$100</EM>(허브 없는 경우
<EM>$50</EM>)</LI>
</UL>
<P>몇년동안 10 Mbits/s 이더넷은 표준 네트웍 기술이 되었다. 좋은 이더넷
인터페이스 카드들은 $50 이하로 살 수 있다. 꽤 많은 피씨들이
이제는 마더보드에 이더넷 컨트롤러를 가지고 있다. 가볍게-사용되는
네트웍에 대해서 이더넷 연결은 허브 없는 멀티-탭 버스로 조직될 수 있다;
그런 설정은 최소의 비용으로 200개까지의 기계들을 묶을 수 있다. 그러나
병렬 처리에는 적절하지 않다. 더비 허브(unswitched hub)를 더하는 것은
실제 성능 향상에 도움이 되지 않는다. 그러나 동시 연결들에 대해서 전체
대역폭을 제공할 수 있는 스위치 허브(switched hub)들은 포트당 단지 약
$100만 든다. 리눅스는 놀라울 정도로 많은 이더넷 인터페이스들을
지원하지만 인터페이스 하드웨어의 변종들은 심각한 성능 차이를 부를 수
있다는 것을 기억하는 것이 중요하다. 어떤 것들이 지원되는지와 그들이 잘
작동하는지에 대해서 하드웨어 호환성 하우투(Hardware Compatibility
HOWTO)를 보라; 그리고 다음을 보자
<A HREF="http://cesdis1.gsfc.nasa.gov/linux/drivers/">http://cesdis1.gsfc.nasa.gov/linux/drivers/</A>.
<P>성능을 향상하는 흥미로운 방법은 NASA CESDIS에서 수행된 비오울프(Beowulf)
프로젝트
<A HREF="http://cesdis.gsfc.nasa.gov/linux/beowulf/beowulf.html">http://cesdis.gsfc.nasa.gov/linux/beowulf/beowulf.html</A>에서 수행된
16-기계 리눅스 클러스터에 의해서 제안되었다. 많은 이더넷 카드 드라이버의
저자인 Donald Becker는 각자 다른 것을 shadow하는(즉, 동일한 네트웍
주소들을 공유하는) 다수의 이더넷 네트웍을 통해서 로드 공유(load
sharing)하는 지원을 개발하였다. 이 로드 공유는 표준 리눅스 배포판에
내장되게 되었고 소켓 작업 레벨 아래에 보이지 않게 내장되게 되었다. 허브
비용이 중요하기 때문에 각 기계가 허브 없는 또는 더미 허브를 가진 두 개
이상의 이더넷 네트웍 (역자주: 카드)에 연결하는 것은 성능을 개선하기 위한
비용-효과적인 방법이 될 수 있다. 사실 한 기계가 네트웍 성능 병목에 걸린
상황에서 shadow 네트웍을 사용하는 로드 공유는 단일 스위치 허브 네트웍을
사용하는 것보다 훨씬 더 좋다.
<P>
<H3>이더넷(패스트 이더넷, Fast Ethernet)</H3>
<P>
<UL>
<LI>리눅스 지원: <EM>커널 드라이버.</EM></LI>
<LI>최대 대역폭: <EM>100 Mb/s</EM></LI>
<LI>최소 지체: <EM>80 마이크로 초</EM></LI>
<LI>구매 방법: <EM>상품 하드웨어</EM></LI>
<LI>사용된 인터페이스 포트/버스: <EM>PCI</EM></LI>
<LI>네트웍 구조: <EM>스위치 또는 더미 허브</EM></LI>
<LI>기계당 비용: <EM>$400?</EM></LI>
</UL>
<P>비록 그들을 "패스트 이더넷"으로 부르는 몇가지 다른 기술들이 실제
존재하지만 이 용어는 대개 옛날 "10 BaseT" 100 Mbits/s 장비와 케이블들과
다소 호환되는 허브-기반 100Mbits/s 이더넷을 가리킨다. 기대하는 것처럼
이더넷으로 불리는 것들은 어떤 것이나 일반적으로 용량으로 가격이
매겨지고 이런 인터페이스들은 일반적으로 155 Mbits/s ATM 카드들의 가격에
자그마한 조각에 지나지 않는다. 일단의 기계들이 단일 100 Mbits/s "버스"
(더미 허브를 사용해서)의 대역폭을 나눠 쓰도록 하는 것은 각 기계의 연결에
풀로 10 Mbits/s를 제공할 수 있는 스위치 허브를 가지고 10 Mbits/s
이더넷을 사용하는 것보다 좋지 않을 수 있다는 함정(단점)이 있다.
<P>각 기계에게 동시에 100 Mbits/s를 제공할 수 있는 스위치 허브는 비싸지만
가격이 매일 떨어지고 있고 이런 스위치들은 더미 허브보다 훨씬 더 높은
전체 네트웍 대역폭을 만든다. ATM 스위치들을 비싸게 만드는 요인은 그들이
각 ATM 셀(상대적으로 작은)들에 대해서 반드시 스위치해야 한다는 점이다;
어떤 패스트 이더넷 스위치들은 스위치를 지날 때 작은 지체를 가질 수 있는
기술들을 사용함으로써 기대되는 더 낮은 스위칭 주기의 이점을 이용한다.
그러나 스위치 패스를 변경하는 데 몇 밀리초(역자주: 마이크로 초가
아니다)가 걸린다... 그래서 라우팅 패턴이 자주 변한다면 이런 스위치는
피하는 것이 좋다. 여러 카드들과 드라이버들에 대해서는
<A HREF="http://cesdis1.gsfc.nasa.gov/linux/drivers/">http://cesdis1.gsfc.nasa.gov/linux/drivers/</A>를 보라.
<P>또한 이더넷에서 설명한 것처럼 NASA에서 이뤄진 Beowulf 프로젝트
<A HREF="http://cesdis.gsfc.nasa.gov/linux/beowulf/beowulf.html">http://cesdis.gsfc.nasa.gov/linux/beowulf/beowulf.html</A>가 멀티
패스트 이더넷을 통해서 로드 공유함으로써 성능을 개선한 지원을 개발해오고
있다니 참고 바란다.
<P>
<H3>이더넷(기가비트 이더넷,Gigabit Ethernet)</H3>
<P>
<UL>
<LI>리눅스 지원: <EM>커널 드라이버</EM></LI>
<LI>최대 대역폭: <EM>1,000 Mb/s</EM></LI>
<LI>최소 지체: <EM>300 마이크로 초?</EM></LI>
<LI>구매 방법: <EM>멀티-벤더 하드웨어</EM></LI>
<LI>사용된 인터페이스 포트/버스: <EM>PCI</EM></LI>
<LI>네트웍 구조: <EM>스위치 허브 또는 FDR</EM></LI>
<LI>기계당 비용: <EM>$2,500?</EM></LI>
</UL>
<P>기가비트 이더넷(Gigabit Ethernet)
<A HREF="http://www.gigabitethernet.org/">http://www.gigabitethernet.org/</A>이 이더넷으로 불리는 좋은 기술적
이유를 가진다고 확신하지 못한다. 그러나 이것이 싸고 큰 시장이 있고 IP를
지원하는 컴퓨터 네트웍 기술을 갖고 있다는 것을 이름이 정확하게 의미하는
것은 아니다. 그러나 현재 가격은 Gb/s 하드웨어가 아직 만들기에 까다로운
것이라는 사실을 반영한다.
<P>다른 이더넷 기술들과는 다르게 기가비트 이더넷은 좀 더 믿을 수 있는
네트웍을 만드는 흐름 제어의 레벨을 제공한다. FDR, 즉 풀-듀플렉스
리피터(Full-Duplex Repeater)는 성능을 향상시키기 위해서 버퍼링과
지역화된 흐름 제어를 사용하면서, 단순하게 라인들을 멀티플렉스한다.
대부분의 스위치 허브들은 현존하는 기가비트-가능 광섬유
스위치(gigabit-capable switch fabrics)에 대한 새로운 인터페이스
모듈들로써 구축되고 있다. 스위치/FDR 제품들은 적어도 다음과 같은
사이트들에서 구매될 수 있거나 발표되고 있다.
<A HREF="http://www.acacianet.com/">http://www.acacianet.com/</A>,
<A HREF="http://www.baynetworks.com/">http://www.baynetworks.com/</A>,
<A HREF="http://www.cabletron.com/">http://www.cabletron.com/</A>,
<A HREF="http://www.networks.digital.com/">http://www.networks.digital.com/</A>,
<A HREF="http://www.extremenetworks.com/">http://www.extremenetworks.com/</A>,
<A HREF="http://www.foundrynet.com/">http://www.foundrynet.com/</A>,
<A HREF="http://www.gigalabs.com/">http://www.gigalabs.com/</A>,
<A HREF="http://www.packetengines.com/">http://www.packetengines.com/</A>.
<A HREF="http://www.plaintree.com/">http://www.plaintree.com/</A>,
<A HREF="http://www.prominet.com/">http://www.prominet.com/</A>,
<A HREF="http://www.sun.com/">http://www.sun.com/</A>, and
<A HREF="http://www.xlnt.com/">http://www.xlnt.com/</A>.
<P>리눅스 드라이버
<A HREF="http://cesdis.gsfc.nasa.gov/linux/drivers/yellowfin.html">http://cesdis.gsfc.nasa.gov/linux/drivers/yellowfin.html</A>가
존재하며 Packet Engines "Yellowfin" G-NIC에 대해서는
<A HREF="http://www.packetengines.com/">http://www.packetengines.com/</A>. 리눅스에서 한 초기 테스트는 가장
좋은 100 Mb/s 패스트 이더넷으로 획득될 수 있는 것보다 약 2.5배 높은
대역폭을 얻었다; 기가비트 네트웍의 경우PCI 버스 사용을 조심스럽게 튜닝하는
것이 중요한 인자이다. 의심할 바 없이 드라이버 개선과 다른 NIC들에 대한
리눅스 드라이버 지원이 계속 이어질 것이다.
<P>
<H3>FC (광섬유 채널, Fibre Channel)</H3>
<P>
<UL>
<LI>리눅스 지원: <EM>no</EM></LI>
<LI>최대 대역폭: <EM>1,062 Mb/s</EM></LI>
<LI>최소 지체: <EM>?</EM></LI>
<LI>구매 경로: <EM>멀티-벤더 하드웨어</EM></LI>
<LI>인터페이스 포트/버스: <EM>PCI?</EM></LI>
<LI>네트웍 구조: <EM>?</EM></LI>
<LI>기계 당 가격: <EM>?</EM></LI>
</UL>
<P>
<P>FC(광섬유 채널)의 목적은 높은-성능 블럭 I/O(2,048 바이트 데이터 하중을
실어나르는 FC 프레임)를 제공하는 것이다. 특별히 컴퓨터를 통해서가 아니라
FC에 직접 연결될 수 있는 다른 저장 장치와 디스크들을 공유하기 위해서
말이다. 대역폭-별로 FC는 133에서 1,062 Mbits/s 사이 어디에서나
실행되면서 상대적으로 빠르다고 한다. FC가 high-end SCSI를 대체할 만큼
유명해진다면 이것은 값싼 기술이 될 것이다; 지금은 값싼 기술이 아니며
리눅스에 의해서 지원되지 않는다. FC 레퍼런스들에 대한 좋은 콜랙션은
<A HREF="http://www.amdahl.com/ext/CARP/FCA/FCA.html">http://www.amdahl.com/ext/CARP/FCA/FCA.html</A>에서 Fibre Channel
Association에 의해서 관리되고 있다.
<P>
<H3>파이어와이어(FireWire, IEEE 1394)</H3>
<P>
<UL>
<LI>리눅스 지원: <EM>no</EM></LI>
<LI>최대 대역폭: <EM>196.608 Mb/s</EM> (곧, <EM>393.216 Mb/s</EM>)</LI>
<LI>최소 지체: <EM>?</EM></LI>
<LI>구매 방법: <EM>멀티벤더 하드웨어</EM></LI>
<LI>인터페이스 포트/버스: <EM>PCI</EM></LI>
<LI>네트웍 구조: <EM>사이클 없는 랜덤(자가-설정)</EM></LI>
<LI>기계당 비용: <EM>$600</EM></LI>
</UL>
<P>FireWire,
<A HREF="http://www.firewire.org/">http://www.firewire.org/</A>, IEEE 1394-1995 표준인
이것은 고객 전자장비(electronics)를 위한 저비용 고속 디지탈 네트웍을
위해서 고안된 것이다. 진열장 어플리케이션은 DV 디지털 비디오 캠코더를
컴퓨터에 연결하는 것이지만 FireWire는 SCSI를 대체하는 것부터 여러분의
가정극장(home theater)의 각 컴포넌트들을 상호연결하는 것까지의
어플리케이션들을 위하여 사용되도록 의도되었다. 이것은 원(cycle)을 만들지
않는 버스들과 브리지들을 사용하는 임의의 토폴로지에서 연결된 64K
장비들까지 허락하고 컴포넌트들이 더해지거나 제거될 때 자동으로 설정을
검출한다. 짧고(4 바이트 "quadlet") 낮은 지체 시간을 가지는 메시지들이
ATM-like한 동기(isochronous) 전송(멀티미이더 메시지들의 동기를 맞추는 데
사용된다)과 함께 지원된다. 아답텍(Adaptec)은 단일 PCI 인터페이스
카드에 63개까지 장치들을 허락하는 FireWire 제품들을 가지고 있고
<A HREF="http://www.adaptec.com/serialio/">http://www.adaptec.com/serialio/</A>에 FireWire에 대한 좋은
일반적인 정보를 담고 있다.
<P>비록 FireWire가 사용 가능한 가장 높은 대역폭 네트웍이 될 수는 없겠지만
고객-레벨 마켓(가격을 아주 낮게 만들)과 낮은 지체 시간 지원은 이것을
몇년 이내에 리눅스 피씨 클러스터 메시지-전달 네트웍 기술들 중의 하나로
만들 것이다.
<P>
<H3>HiPPI과 시러얼 HiPPI</H3>
<P>
<UL>
<LI>리눅스 지원: <EM>no</EM></LI>
<LI>최대 대역폭: <EM>1,600 Mb/s</EM> (시리얼은 <EM>1,200 Mb/s</EM>)</LI>
<LI>최소 지체: <EM>?</EM></LI>
<LI>구입 방법: <EM>멀티-벤더 하드웨어</EM></LI>
<LI>사용된 인터페이스 포트/버스: <EM>EISA, PCI</EM></LI>
<LI>네트웍 구조: <EM>스위치 허브</EM></LI>
<LI>기계당 비용: <EM>$3,500</EM> (시리얼은 <EM>$4,500</EM>)</LI>
</UL>
<P>
<P>HiPPI (High Performance Parallel Interface)는 원래 슈퍼 컴퓨터와 다른
기계(슈퍼컴, 프레임 버퍼, 디스크 어레이 등) 간에 대량의 데이터 셋들의
전송을 위해서 아주 높은 대역폭을 제공하도록 의도되었으며 슈퍼컴에 대한
지배적인 ㅍ준이 되었다. 비록 이것은 모순 어법(oxymoron)이긴 하지만
<B>시리얼 HiPPI</B>도 또한 32-비트 폭 표준(패러럴) HiPPI 케이블 대신에
광섬유 케이블을 전형적으로 사용함으로써, 유명해질 것이다. 지나 몇 년동안
HiPPI 크로스바 스위치들은 일반적인 것이 되었으며 가격들은 급격하게
떨어졌다; 불행하게도 시리얼 HiPPI는 아직 비싸고 이것이 바로 PCI 버스
인터페이스 카드들은 일반적으로 지원하는 것이다. 더 나쁜 것은 리눅스는
아직 HiPPI를 지원하지 못한다는 것이다. HiPPI의 좋은 개관은 CERN에 의해서
<A HREF="http://www.cern.ch/HSI/hippi/">http://www.cern.ch/HSI/hippi/</A>에서 관리되고 있다; 그들은 또한
<A HREF="http://www.cern.ch/HSI/hippi/procintf/manufact.htm">http://www.cern.ch/HSI/hippi/procintf/manufact.htm</A>에 HiPPI
벤더들의 다소 기다란 리스트를 관리한다.
<P>
<H3>IrDA (적외선 데이터 연합; Infrared Data Association)</H3>
<P>
<UL>
<LI>리눅스 지원: <EM>no?</EM></LI>
<LI>최대 대역폭: <EM>1.15 Mb/s와 4 Mb/s</EM></LI>
<LI>최소 지체: <EM>?</EM></LI>
<LI>구매 방법: <EM>멀티-벤더 하드웨어</EM></LI>
<LI>인터페이스/버스: <EM>IrDA</EM></LI>
<LI>네트웍 구조: <EM>짧은 거리 무선(thin air) ;-)</EM></LI>
<LI>기계당 비용: <EM>$0 </EM></LI>
</UL>
<P>IrDA(적외선 데이터 연합,
<A HREF="http://www.irda.org/">http://www.irda.org/</A>)는 많은 랩톱 피시들의 측면에 있는 작은
적외선 장치이다. 이 인터페이스를 사용해서 두 개 이상의 기계들을
커넥트하는 것은 타고 날 때부터 어렵다. 그래서 클러스터링에 사용될
가능성이 낮다. Don Becker가 IrDA에 몇가지 예비 작업을 했었다.
<P>
<H3>Myrinet</H3>
<P>
<UL>
<LI>리눅스 지원: <EM>라이브러리</EM></LI>
<LI>최대 대역폭: <EM>1,280 Mb/s</EM></LI>
<LI>최소 지체: <EM>9 마이크로 초</EM></LI>
<LI>구매 방법: <EM>단일-벤더 하드웨어</EM></LI>
<LI>인터페이스 포트/버스: <EM>PCI</EM></LI>
<LI>네트웍 구조: <EM>스위치 허브</EM></LI>
<LI>기계당 가격: <EM>$1,800</EM></LI>
</UL>
<P>Myrinet
<A HREF="http://www.myri.com/">http://www.myri.com/</A>은 "시스템 영역 네트웍" (System
Area Network, SAN)으로 사용될 수 있도록 고안된 근거리 영역
네트웍(LAN)이다. 즉 병렬 시스템으로 연결된 기계들이 가득찬 네트웍
케비넷. LAN과 SAN 버전들은 서로 다른 물리적 매체를 사용하고 다소 다른
특성들을 가진다; 일반적으로 SAN 버전은 클러스터 안에서 사용될 것이다.
<P>Myrient은 구조적으로 아주 전통적인 것이지만 특별히 잘-구현된 것이라는
평판을 듣고 있다. 리눅스를 위한 드라이버는 성능이 좋다는 말을 듣는다.
비록 호스트 컴퓨터에 대한 서로 다른 PCI 버스 구현물들에 대해서 여러
커다란 성능 변화들이 리포트된 바가 있었지만 말이다.
<P>현재 Myrinet은 너무 심각하게 "예산을 위협하는" 것이 아닌 클러스터 그룹의
선호되는 네트웍임에 틀림없다. 리눅스 피씨에 대한 생각이 최소 256 MB
RAM과 SCSI RAID를 가진 Pentium Pro나 Pentium II라면 Myrinet의 가격은 꽤
합리적인 것이 된다. 그러나 좀 더 일반적인 피씨 설정을 사용한다면
여러분의 선택이 Myrinet에 연결된 <EM>N</EM> 기계들이나 멀티 패스트
이너넷으로 묶인 <EM>2N</EM>과 TTL_PAPERS 사이에 있다는 것을 알게
될 것이다. 여러분의 예산이 얼마나 되는가와 여러분이 신경쓰는 컴퓨터의
사양이 어떤 것인가에 따라 좌지 우지 된다.
<P>
<H3>파라스테이션(Parastation)</H3>
<P>
<UL>
<LI>리눅스 지원: <EM>HAL 또는 소켓 라이브러리</EM></LI>
<LI>최대 대역폭: <EM>125 Mb/s</EM></LI>
<LI>최소 지체: <EM>2 microseconds</EM></LI>
<LI>구입 방법: <EM>단일-벤더 하드웨어</EM></LI>
<LI>사용된 인터페이스/버스: <EM>PCI</EM></LI>
<LI>네트웍 구조: <EM>허브없는 망(mesh)</EM></LI>
<LI>기계당 비용: <EM>> $1,000</EM></LI>
</UL>
<P>
<P>Karlsruhe 대학교 정보공학과(Department of Informatics)의
파라스테이션(Parastation) 프로젝트
<A HREF="http://wwwipd.ira.uka.de/parastation">http://wwwipd.ira.uka.de/parastation</A>는 PVM-호환 커스텀 저-지체
네트웍을 구축 중이다. 그들은 맨처음 커스텀 EISA 인터페이스와 BSD UNIX를
실행하는 피씨들을 사용한 맨처음 구축된 두개의 프로세서 ParaPC
프로토타입을 만들었으며 그 다음 DEC Alpha들을 사용한 좀 더 큰
클러스터들을 만들었다. PCI 카드들은 Hitex이라고 불리는 회사와 공조해서
만들어졌다(
<A HREF="http://www.hitex.com:80/parastation/">http://www.hitex.com:80/parastation/</A> 참조).
파라스테이션 하드웨어는 빠르고 신뢰성 있는 메시지 전송과 단순한
관문(barrier) 동기화를 구현한 것이다.
<P>
<H3>PLIP</H3>
<P>
<UL>
<LI>리눅스 지원: <EM>커널 드라이버</EM></LI>
<LI>최대 대역폭: <EM>1.2 Mb/s</EM></LI>
<LI>최소 지체: <EM>1,000 microseconds?</EM></LI>
<LI>구입 방법: <EM>상품 하드웨어</EM></LI>
<LI>사용된 인터페이스/버스: <EM>SPP</EM></LI>
<LI>네트웍 구조: <EM>2 기계 간 케이블</EM></LI>
<LI>기계당 비용: <EM>$2</EM></LI>
</UL>
<P>
<P>"LapLink" 케이블의 비용으로 PLIP(Parallel Line Interface Protocol)는
표준 소켓-기반 소프트웨어를 사용하여 표준 패러럴 포트들을 통해서 두
리눅스 기계들이 통신할 수 있도록 한다. 대역폭, 지체, 그리고
측정가능성(scalability)의 측면에서 보면 이것은 아주 중요한 네트웍 기술이
아니다. 그러나 거의 영에 가까운 가격과 소프트웨어 호환성이 유용하다.
드라이버는 표준 리눅스 커널 배포판의 일부이다.
<P>
<H3>SCI</H3>
<P>
<UL>
<LI>리눅스 지원: <EM>no</EM></LI>
<LI>최대 대역폭: <EM>4,000 Mb/s</EM></LI>
<LI>최소 지체: <EM>2.7 microseconds</EM></LI>
<LI>구입 방법: <EM>멀티-벤더 하드웨어</EM></LI>
<LI>사용된 인터페이스/버스: <EM>특정회사(proprietary) PCI</EM></LI>
<LI>네트웍 구조: <EM>?</EM></LI>
<LI>기계당 비용: <EM>> $1,000</EM></LI>
</UL>
<P>
<P>SCI (Scalable Coherent Interconnect, ANSI/IEEE 1596-1992)의 목적은
기본적으로 많은 수의 기계들에 걸쳐 근접(coherent) 공유 메모리 공유를
지원할 수 있는 고성능 메카니즘과 다양한 타입의 메시지 전송을 제공하는
것이다. SCI의 고안된 대역폭과 지체는 대부분의 다른 네트웍 기술들과
비교해서 둘 다 "놀라운 것"이라고 말해도 괜찮다. 단점은 SCI가 싼 제품
유니트로써 널리 사용가능하지 않다는 것과 리눅스 지원이 아직 없다는
것이다.
<P>SCI는 주로
HP/Convex Exemplar SPP와 Sequent NUMA-Q 2000(
<A HREF="http://www.sequent.com/">http://www.sequent.com/</A>)와 같은
지역적으로-공유된 물리적으로-배포된 메모리 기계들(logically-shared
physically-distributed memory machines)에 대한 다양한 고유
디자인 안에서 사용되었다. 그러나 Dolphin(
<A HREF="http://www.sequent.com/">http://www.sequent.com/</A> 참조)로부터 SCI는 PCI 인터페이스
카드와 4-way 스위치(16 기계들까지 네개의 4-way 스위치들을 붙여서 연결될
수 있다)들이 그들의 CluStar 제품 라인으로써 사용가능하다. SCI
개관에 대한 좋은 링크들은 CERN에 의해서
<A HREF="http://www.cern.ch/HSI/sci/sci.html">http://www.cern.ch/HSI/sci/sci.html</A>에서 관리된다.
<P>
<H3>SCSI</H3>
<P>
<UL>
<LI>리눅스 지원: <EM>커널 드라이버</EM></LI>
<LI>최대 대역폭: <EM>5 Mb/s</EM>에서 <EM>20 Mb/s</EM> 이상까지</LI>
<LI>최소 지체: <EM>?</EM></LI>
<LI>구입 방법: <EM>멀티-벤더 하드웨어</EM></LI>
<LI>사용된 인터페이스/버스: <EM>PCI, EISA, ISA 카드</EM></LI>
<LI>네트웍 구조: <EM>SCSI 장비들을 공유하는 기계간 버스</EM></LI>
<LI>기계당 비용: <EM>?</EM></LI>
</UL>
<P>
<P>SCSI (Small Computer Systems Interconnect)는 기본적으로 디스크
드라이브들, CDROM들, 이미지 스캐너 등과 같은 데 사용되는 I/O 버스이다.
여기에는 분리된 세개의 표준들 SCSI-1, SCSI-2, 그리고 SCSI-3; Fast and
Ultra speeds; 그리고 데이터 패스 너비로 8, 16, 또는 32비트(SCSI-3에서
언급된 FireWire 호환성과 함께) 가 있다. 이것은 아주 혼란스럽다.
그러나 우리는 모두 좋은 SCSI는 EIDE보다 더 빠르고 장비들을 좀 더
효율적으로 관리할 수 있다는 것을 안다.
<P>많은 사람들이 깨닫지 못하는 것은 두 컴퓨터들이 단일 SCSI 버스를 공유하는
것이 아주 단순하다는 사실이다. 이런 설정 타입은 기계간 디스크
드라이브들을 공유하고 <B>장애 복구(fail-over)</B>를 구현-한 기계가
다른 기계가 실패했을 때 데이터베이스 요구를 떠맡도록 하게 함으로써-에
아주 유용하다. 현재 이것은 마이크로소프트의 PC 클러스터 제품 WolfPack에
의해서 지원되는 유일한 메카니즘이다. 그러나 좀 더 큰 시스템들로 확장될
수 없다는 것이 공유 SCSI를 일반적인 병렬 처리에 있어 덜 흥미롭게 만든다.
<P>
<H3>서버넷(ServerNet)</H3>
<P>
<UL>
<LI>리눅스 지원: <EM>no</EM></LI>
<LI>최대 대역폭: <EM>400 Mb/s</EM></LI>
<LI>최소 지체: <EM>3 microseconds</EM></LI>
<LI>구입 방법: <EM>단일-벤더 하드웨어</EM></LI>
<LI>사용된 인터페이스/버스: <EM>PCI</EM></LI>
<LI>네트웍 구조: <EM>허브의 육각 트리/4면체 격자(hexagonal
tree/tetrahedral lattice of hubs)</EM></LI>
<LI>기계당 비용: <EM>?</EM></LI>
</UL>
<P>
<P>서버넷(ServerNet)은 Tandem,
<A HREF="http://www.tandem.com">http://www.tandem.com</A>의 고-성능
네트웍 하드웨어이다. 특별히 온라인 트랜잭션 처리(OLTP) 세계에서 탠덤은
고-신뢰도 시스템들의 선두로 알려져 있어서 그들의 네트웍이 고-성능 뿐만이
아니고 "높은 데이터 통합(integrity)과 신뢰도"까지 주장해도 놀라운 일이
아니다. ServerNet의 다른 흥미로운 면은 임의의 장치에서 다른 임의의
장치로 직접 데이터를 전송할 수 있다고 주장한다는 것이다;
<A HREF="#sec_MPI">MPI</A> 섹션에서
설명된 MPI 리모트 메모리 억세스 메카니즘들에 의해서 제안된 것과 비슷한
원-사이드 스타일로, 프로세서들사이뿐만이 아니고 디스크 드라이브들 등
사이에서도 그렇다. 서버넷에 대한 마지막 한가지 코멘트: 단지 싱글
벤더만 존재하지만 그 벤더는 서버넷을 주요 표준으로, 잠재적으로 만들 수
있을 만큼 충분히 강력하다. Tandem은 Compaq 소유이다.
<P>
<H3>SHRIMP</H3>
<P>
<UL>
<LI>리눅스 지원: <EM>사용자-레벨 메모리 맵된(memory-mapped) 인터페이스</EM></LI>
<LI>최대 대역폭: <EM>180 Mb/s</EM></LI>
<LI>최소 지체: <EM>5 microseconds</EM></LI>
<LI>구입 방법: <EM>연구 프로토타입</EM></LI>
<LI>사용된 인터페이스/버스: <EM>EISA</EM></LI>
<LI>네트웍 구조: <EM>mesh backplane (인텔 Paragon와 유사)</EM></LI>
<LI>기계당 비용: <EM>?</EM></LI>
</UL>
<P>
<P>프린스턴 대학교 컴퓨터 과학 학과에서 진행하고 있는
SHRIMP 프로젝트,
<A HREF="http://www.CS.Princeton.EDU/shrimp/">http://www.CS.Princeton.EDU/shrimp/</A>는
처리 노드로써 리눅스를 실행하는 피씨들을 사용한 병렬 컴퓨터를 구축하고
있다. 첫번째 SHRIMP(Scalable, High-Performance, Really Inexpensive
Multi-Processor의 약자)는 커스텀 EISA 카드 인터페이스 위의 듀얼 포트를
가지는 RAM을 사용한 단순한 두-프로세서 프로토 타입이었다. 지금은 인텔
Paragon(
<A HREF="http://www.ssd.intel.com/paragon.html">http://www.ssd.intel.com/paragon.html</A> 참조)에서 사용된
그물망(mesh) 라우팅 네트웍과 기본적으로 동일한 "hub"에 연결하기 위해서
커스텀 인터페이스를 사용하는 좀 더 큰 설정들에 확장가능한 프로토타입이
존재한다. 오베헤드가 적은 "가상 메모리 맵된 통신" 하드웨어와 지원
소프트웨어를 개발하기 위한 상당히 많은 노력이 이루어졌다.
<P>
<H3>SLIP</H3>
<P>
<UL>
<LI>리눅스 지원: <EM>커널 드라이버</EM></LI>
<LI>최대 대역폭: <EM>0.1 Mb/s</EM></LI>
<LI>최소 지체: <EM>1,000 microseconds?</EM></LI>
<LI>구입 방법: <EM>상품 하드웨어</EM></LI>
<LI>사용된 인터페이스/버스: <EM>RS232C</EM></LI>
<LI>네트웍 구조: <EM>두 기계들 사이에 케이블 사용</EM></LI>
<LI>기계당 비용: <EM>$2</EM></LI>
</UL>
<P>
<P>비록 SLIP(시리얼 라인 인터페이스 프로토콜;Serial Line Interface
Protocol)은 성능 스펙트럼에서 낮은 쪽에 완전히 위치하고 있지만
SLIP(또는 CSLIP또는 PPP)는 두 기계들이 일반 RS232 시리얼 포트들을
통해서 소켓 통신을 수행할 수 있도록 한다. 또는 그들은 모뎀을 경유한
다이얼-업을 통해서 연결될 수도 있다. 어떤 경우에도 지체 시간은 높고
대역폭은 낮다. 그래서 SLIP은 다른 대안들이 전혀 불가능할 때만
사용되어야 할 것이다. 그러나 대부분의 피씨드이 두 개의 RS232 포트들을
갖고 있다는 것은 주목할만한 가치가 있다. 그래서 기계들을 선형 배열이나
링형으로 단순하게 연결해서 기계들 그룹을 네트워킹하는 것이
가능하다. EQL이라고 불리는 로드 쉐어링 소프트웨어도 존재한다.
<P>
<H3>TTL_PAPERS</H3>
<P>
<UL>
<LI>리눅스 지원: <EM>AFAPI 라이브러리</EM></LI>
<LI>최대 대역폭: <EM>1.6 Mb/s</EM></LI>
<LI>최소 지체: <EM>3 microseconds</EM></LI>
<LI>구입 방법: <EM>퍼블릭-도메인 설계, 싱글-벤더 하드웨어</EM></LI>
<LI>사용된 인터페이스/버스: <EM>SPP</EM></LI>
<LI>네트웍 구조: <EM>허브들의 트리</EM></LI>
<LI>기계당 비용: <EM>$100</EM></LI>
</UL>
<P>
<P>퍼듀 대학교의 전자 및 컴퓨터 엔지니어링 학교에서 수행 중인
PAPERS (Purdue's Adapter for Parallel Execution and Rapid
Synchronization) 프로젝트,
<A HREF="http://garage.ecn.purdue.edu/~papers/">http://garage.ecn.purdue.edu/~papers/</A>는 병렬 슈퍼컴퓨터가
변조되지 않은 피씨들/워크스테이션들을 노드로 사용하여 구축될 수 있도록
하는, 크기 조절 가능하고 낮은-지체 시간을 가지며 집합 함수 통신
하드웨어와 소프트웨어를 구축 중에 있다.
<P>두가지 개발 라인들을 대략 따르는 SPP(표준 패러럴 포트; Standard Parallel
Port)를 통해서 피씨들/워크스테이션들을 연결한 PAPERS 하드웨어는 그
종류가 12가지가 넘는다. "PAPERS"라고 불리는 버전들은 적절한 기술이면
무엇이든지 사용해서 더 높은 성능을 목표로 한다; 현재 작업은 FPGA들과
지금 개발 중에 있는 높은 대역의 PCI 버스 인터페이스 설계들을 사용한다.
반면에 "TTL_PAPERS"이라고 불리는 버전들은 퍼듀 대학 바깥에서 쉽게
재생산될 수 있도록 디자인된 것이고 일반적인 TTL 로직을 사용해서 만들어질
수 있는 아주 단순한 공용 도메인 설계(public domain designs)이다. 이런
디자인 중 하나는 상용으로 만들어졌다.
<A HREF="http://chelsea.ios.com:80/~hgdietz/sbm4.html">http://chelsea.ios.com:80/~hgdietz/sbm4.html</A><P>다른 대학들의 커스텀 하드웨어 디자인과 다르게 TTL_PAPERS
클러스터들은 USA에서 대한민국까지 많은 대학들에서 조립되어 왔다.
대역폭은 SPP 커넥션들에 의해서 심각하게 제한되어 있지만 가장 빠른
메시지-기반 시스템들은 그러한 집합 함수들(aggregate functions)에 대해서
필적할만한 성능을 제공할 수 없다. 그래서 PAPERS는 특별히 비디오 벽(video
wall; 역자주: 전시장 등에서 볼 수 있는 대형 디스플레이 및 컴퓨터,
사운드 시스템의 조합)의 디스플레이를 동기화하는 데(비디오 벽에 대해서
앞으로 나올 Video Wall HOWTO에서 자세히 다룰 것이다), 고-대역 네트웍에
대한 스케줄링 억세스, 유전자 검색(genetic search)에서 전역 비교(global
fitness)를 평가하는 것 등에서 탁월하다. 비록 PAPERS 클러스터들이 IBM
PowerPC AIX, DEC Alpha OSF/1, 그리고 HP PA-RISC HP-UX 기계들을 사용해서
만들어졌지만 리눅스-기반 PC들이 가장 잘 지원되는 플랫폼이다.
<P>TTL_PAPERS AFAPI를 사용하는 사용자 프로그램들은 리눅스에서, 각
억세스에 대해서 OS 호출없이 SPP 하드웨어 포트 레지스터들을 억세스한다.
이렇게 하기 위해서 AFAPI는 맨먼저 <CODE>iopl()</CODE>나 <CODE>ioperm()</CODE>를
사용해서 포트 퍼미션을 획득한다. 이런 호출들의 문제점은 둘 다 사용자
프로그램이 권한을 갖도록(역자주: 아무래도 루트 권한일 것 같다) 요구해서
잠재적인 보안 구멍을 만든다는 것이다. 솔루션은 선택적인 커널 패치,
<A HREF="http://garage.ecn.purdue.edu/~papers/giveioperm.html">http://garage.ecn.purdue.edu/~papers/giveioperm.html</A>이다. 이것은
권한있는 프로세스가 임의의 프로세스에 대한 포트 퍼미션을 제어하도록
한다.
<P>
<H3>USB (Universal Serial Bus)</H3>
<P>
<UL>
<LI>리눅스 지원: <EM>kernel driver</EM></LI>
<LI>최대 대역폭: <EM>12 Mb/s</EM></LI>
<LI>최소 지체: <EM>?</EM></LI>
<LI>구입 방법: <EM>commodity hardware</EM></LI>
<LI>사용된 인터페이스/버스: <EM>USB</EM></LI>
<LI>네트웍 구조: <EM>bus</EM></LI>
<LI>기계당 비용: <EM>$5?</EM></LI>
</UL>
<P>
<P>USB (Universal Serial Bus,
<A HREF="http://www.usb.org/">http://www.usb.org/</A>)는 키보드,
화상 회의 카메라 등 127개까지 주변기기들을 달 수 있고
핫-플러그(hot-pluggable) 가능한 일반 이더넷 수준의 속도를 내는 버스이다.
얼마나 많은 컴퓨터들이 서로 USB를 사용해서 연결될 수 있는지는 실제
명확하지 않다. 어쨌든 USB 포트들은 지금 빠르게 RS232와 SPP와 같은 PC
마더보드의 표준이 되어가고 있다. 그러므로 여러분이 구매한 차기 PC의
뒤편에 USB 포트들이 숨어 있더라도 놀라지 말기 바란다. 리눅스 드라이버
개발은
<A HREF="http://peloncho.fis.ucm.es/~inaky/USB.html">http://peloncho.fis.ucm.es/~inaky/USB.html</A>에서
논의되고 있다.
<P>여러가지 점에서 USB는 거의 여러분이 현재 구매할 수 있는, 낮은-성능,
제로-비용(zero-cost)인 FireWire 버전이다.
<P>
<H3>WAPERS</H3>
<P>
<UL>
<LI>리눅스 지원: <EM>AFAPI library</EM></LI>
<LI>최대 대역폭: <EM>0.4 Mb/s</EM></LI>
<LI>최소 지체: <EM>3 microseconds</EM></LI>
<LI>구입 방법: <EM>public-domain design</EM></LI>
<LI>사용된 인터페이스/버스: <EM>SPP</EM></LI>
<LI>네트웍 구조: <EM>wiring pattern between 2-64 machines</EM></LI>
<LI>기계당 비용: <EM>$5</EM></LI>
</UL>
<P>
<P>WAPERS (병렬 실행과 빠른 동기화를 위한 Wired-AND 아답터;
Wired-AND Adapter for Parallel Execution and Rapid
Synchronization)는 퍼듀 대학교의 전자 컴퓨터 공학 학교에서 수행 중인
PAPERS 프로젝트,
<A HREF="http://garage.ecn.purdue.edu/~papers/">http://garage.ecn.purdue.edu/~papers/</A>의
부산물이다. 적절하게 구현된다면 SPP는 4-비트 폭 wired AND를 구현하기
위해서 기계들 간 서로 묶일 수 있는 4비트 오픈-콜렉터 출력을 가진다. 이
wired-AND는 전자공학적으로 다루기 어려운 것이고 이런 식으로 연결될 수
있는 기계들의 최대 개수는 포트의 아날로그 특성에 종속적이다(최대 수신
전류(sink current)와 휴식 레지스터(pull-up register) 값); 전형적으로 7개
내지 8개 기계들이 WAPERS로 네트워킹될 수 있다. 비록 비용과 지체시간이
아주 낮지만, 그래서 대역폭도 낮다; WAPERS는 클러스터에서 단일
네트웍으로써가 아니라 집합 작업들에 대한 두번째 네트웍으로써 훨씬 더
좋다. TTL_PAPERS와 함께, 시스템 보안을 높이기 위해서, 반드시
필요하지는 않지만 권고되는 마이너 커널 패치가 있다:
<A HREF="http://garage.ecn.purdue.edu/~papers/giveioperm.html">http://garage.ecn.purdue.edu/~papers/giveioperm.html</A>.
<P>
<H2><A NAME="ss3.3">3.3 네트웍 소프트웨어 인터페이스(Network Software Interface)</A>
</H2>
<P>
<P>병렬 어플리케이션들을 지원하는 소프트웨어를 논의하기 이전에 네트웍
하드웨어에 대한 로우-레벨 소프트웨어 인터페이스의 기본을 간단히 먼저
얘기하는 것이 유용하다. 실제로 3가지 기본 선택만 존재한다: 소켓, 장치
구동기(device drivers), 그리고 유저-레벨 라이브러리.
<P>
<H3>소켓</H3>
<P>
<P>지금까지 가장 일반적인 로우-레벨 네트웍 인터페이스는 소켓
인터페이스이다. 소켓은 지난 10년간 유닉스의 일부였고 대부분의 표준
네트웍 하드웨어는 적어도 두가지 타입의 소켓 프로토콜들: UPD와 TCP를
지원하도록 설계된 것이다. 두 소켓 타입들은 한 기계에서 다른 것으로
임의 크기의 데이터 블럭을 전송할 수 있도록 하지만 몇가지 중요한 차이가
있다. 비록 성능은 네트웍 트래픽에 따라서 훨씬 악화될 수 있지만
전형적으로 이 두가지는 약 1,000 마이크로 초 정도의 최소 지체를 만든다.
<P>이런 소켓 타입들은 대부분의 이식 가능, 하이-레벨, 병렬 처리 소프트웨어에
대한 기본 네트웍 소프트웨어 인터페이스이다; 예를 들어서 PVM은 UDP와
TCP를 혼합하여 사용하기 때문에 이 둘의 차이점을 아는 것은 성능을
튜닝하는 데 도움을 줄 것이다. 좀 더 나은 성능을 위해서 프로그램 안에서
직접 이런 메카니즘들을 사용할 수도 있다. 다으은 UDP와 TCP의 단순한
개관이다; 자세한 내용은 매뉴얼 페이지들과 좋은 네트웍 프로그래밍 책을
보기 바란다.
<P>
<H3>UDP 프로토콜 (SOCK_DGRAM)</H3>
<P>
<P><B>UDP</B>는 사용자 데이터그램 프로토콜(User Datagram Protocol)이지만
UDP의 속성을 신뢰할 수 없는 데이터그램 처리(Unreliable Datagram
Processing)로 좀 더 쉽게 기억할 수 있을 것이다. 다른 말로 해서 UDP는 각
블럭이 개별 메시지로 전송되도록 허락하지만 메시지는 전송 중 유실될 수
있다. 사실 네트웍 트래픽에 종속적으로 UDP 메시지들은 유실될 수 있고
여러번 도착할 수 있거나 그들이 보내진 순서와 다른 순서로 도착할 수 있다.
UDP 메시지의 전송자는 자동으로 받았다는 통지(acknowledgement)를 받지
않는다. 그래서 이런 문제들을 검출하고 보충하는 것은 사용자가 작성한
코드에 의존한다. 다행스럽게도 UDP는 메시지가 도착했다면 받은 메시지가
손상된 것이 아니고 완전한 것이라고(즉, UDP 메시지 조각만 받았다고)
보장한다.
<P>UDP가 좋은 점은 가장 빠른 소켓 프로토콜이 되려고 한다는 것이다. 더
나아가 UDP는 "연결 없는(connectionless)" 것이다. 이것은 각 메시지가
기본적으로 모든 다른 것들과 독립이다는 것을 의미한다. 이것에 대한 좋은
비유는 편지이다; 여러분은 동일한 집주소로 여러 편지를 보낼 수 있지만
각각은 다른 것들과 독립이며 여러분이 편지를 보낼 수 있는 사람의 수에
대한 제한이 없다.
<P>
<H3>TCP 프로토콜(SOCK_STREAM)</H3>
<P>
<P>UDP와 다르게 <B>TCP</B>는 신뢰할 수 있고, 연결-기반인 프로토콜이다.
보내진 각 블럭은 메시지로 보이지 않고 겉보기에 전송자와 수신자 사이의
연결을 통해서 전송된 연속적인 바이트안에서 데이터 블럭으로 보인다.
이것은 UDP 메시징과 아주 다르다. 왜냐면 각 블럭은 단순하게 바이트
스트림의 일부이고 각 블럭을 바이트 스트림에서 추출하는 방법을 알아 내는
것은 사용자 코드에 종속적이기 때문이다; 메시지들을 분리하는 마킹은 없다.
더 나아가 네트웍 문제들에 대해서 연결은 좀 더 깨지기 쉬운 것이고 연결의
제한된 개수들만이 각 프로세스들에 대해서 동시에 존재할 수 있다. 이것은
신뢰할 수 있기 때문에 TCP는 일반적으로 UDP보다 좀 더 무거운 오버헤드를
가진다.
<P>그러나 TCP에 관한 몇가지 즐거운 놀라운 것들이 존재한다. 다수 메시지들이
연결을 통해서 전달되었다면, 짧은 또는 짝이 맞지 않은 크기의 메시지들의
그룹에 대해서 UDP보다 더 나은 성능을 잠재적으로 내면서, TCP는 그것들을
버퍼 안에서 네트웍 하드웨어 패킷 크기에 더 잘 맞도록 묶을 수 있다는 것이
첫번째이다. 다른 보너스는 기계들 간에 신뢰할 수 있는 직접 물리적
링크들을 사용해서 구축된 네트웍은 TCP 연결을 쉽고 효율적으로 흉내낼 수
있다는 것이다. 예를 들어서 ParaStation의 "Socket Library" 인터페이스
소프트웨어의 경우 이렇게 되었다. 이 소프트웨어는 표준 TCP OS 호출들과 각
함수 이름에다 접두사 <CODE>PSS</CODE>를 붙이는 것만 다른 사용자-레벨
호출들을 사용한 TCP 문법(semantics)을 제공한다.
<P>
<H3>장치 구동기(Device Drivers)</H3>
<P>
<P>네트웍에 데이터를 실제로 넣을 때가, 또는 네트웍으로부터 데이터를 끄집어
올 때가 오면 표준 유닉스 소프트웨어 인터페이스는 장치 구동기라고 불리는
유닉스 커널의 일부가 된다. UDP와 TCP는 단지 데이터만 전송하지 않고
그들은 또한 상당한 양의 소켓 관리의 오버헤드를 갖고 있다. 예를 들어서
어떤 것들은 다수의 TCP 커넥션들이 하나의 물리적 네트웍 인터페이스를
공유할 수 있다는 사실을 관리해야 한다. 이에 비해서 전용 네트웍
인터페이스에 대한 장치 구동기는 단지 몇가지 단순한 데이터 전송 함수들만
구현하면 된다. 이런 장치 드라ㅇ이버 함수들은 사용자 프로그램에 의해서,
적절한 장치를 확인하기 위해서 <CODE>open()</CODE>을 사용하고 오픈된 "파일"에
대해서 <CODE>read()</CODE>와 <CODE>write()</CODE>와 같은 시스템 호출을
사용함으로써, 호출될 수 있다. 그래서 각각의 그런 작업은 데이터 블럭을
시스템 호출의 오버헤드보다 더 작은 오버헤드로 전송할 수 있다. 이런
시스템 호출은 수십 마이크로 초가 걸린다.
<P>리눅스에 대한 장치 구동기를 작성하는 것은 어렵지 않다... 장치 하드웨어가
작동하는 방법을 <EM>정확하게</EM> 알고 있다면 말이다. 이것이 작동하는
방법을 모른다면 추측하지 말라. 장치 드라이버를 디버깅하는 것은 즐겁지
않은 일이고 실수들은 하드웨어를 태워먹을 수 있다. 그러나 이것이 여러분을
그렇게 겁주는 것이 아니라면, 예를 들어서 전용 이더넷 카드를 더미로
그러나 일반적인 이더넷 프로토콜 오버헤드 없이 기계-대-기계 빠른 직접
연결로 사용하기 위해서, 장치 구동기를 작성하는 것은 가능한 일이 될 수
있다. 사실 초기 인텔 슈퍼컴퓨터들이 했던 것과 상당히 유사하다.... 좀 더
자세한 정보를 보고 싶다면 Device Driver HOWTO를 보라.
<P>
<H3>사용자-레벨 라이브러리(User-Level Libraries)</H3>
<P>
<P>여러분이 OS 코스를 택했다면 하드웨어 장치 레지스터에 대한 사용자-레벨
억세스는 정확히 여러분이 한번도 배운 적이 없는 것이다. 왜냐면 OS의 주요
목적 중 하나는 장치 억세스를 제어하는 것이기 때문이다. 그러나 OS 호출은
적어도 수십 마이크로 초 오버헤드가 걸린다. 단지 3 마이크로 초 동안에
기본 네트웍 작업을 수행할 수 있는 TTL_PAPERS와 같은 커스텀 네트웍
하드웨어의 경우 그런 OS 호출 오버헤드는 참을 수 없는 것이다. 그런
오버헤드를 피하는 유일한 방법은 하드웨어 장치 레지스터들을 직접
억세스하는 사용자-레벨 코드 - 사용자-레벨 라이브러리 - 를 가지는 것이다.
그래서 사용자-레벨 라이브러리가 하드웨어를 직접 억세스할 수 있는 방법은
무엇인가, 하지만 장치 억세스 권한에 대한 OS 제어와 타협하지 않는 방법은
무엇인가와 같은 것이 질문이 될 것이다.
<P>전형적인 시스템에서 사용자-레벨 라이브러리가 하드웨어 장치 레지스터를
직접 억세스하는 유일한 방법은 다음과 같다:
<P>
<OL>
<LI>사용자 프로그램 시작에서 장치 레지스터를 포함하는 메모리 주소
공간을 사용자 프로세스 가상 메모리 맵으로 맵핑하는 OS 호출을 사용한다.
어떤 시스템들에서는 <CODE>mmap()</CODE> 호출(섹션
<A HREF="Parallel-Processing-HOWTO-2.html#sec_MemoryMapCall">메모리 맵 호출</A> 에서 맨처음 언급됨)이 I/O
장치들의 물리적 메모리 페이지 주소들의 표현하는 특수 파일을 맵핑하는 데
사용될 수 있다. 또는 이런 기능을 수행하는 장치 구동기를 작성하는 일은
상대적으로 쉽다. 더 나아가 이 장치 구동기는 필요한 특정 장치
레지스터들을 담고 있는 페이지(들)을 맵핑하는 것만으로 억세스를 제어할 수
있다. 그래서 OS 억세스 제어를 유지할 수 있다.
</LI>
<LI>맵핑된 주소들에 단순하게 로딩하거나 저장함으로써 OS 호출 없이 장치
레지스터들을 억세스. 예를 들어서 <CODE>*((char *) 0x1234) = 5;</CODE>는
메모리 위치 1234(16진수)에다 바이트 값 5를 저장할 것이다.</LI>
</OL>
<P>다행스럽게도 인텔 386(그리고 호환 프로세스들)에 대한 리눅스가 좀 더 나은
솔루션을 제공하는 일이 벌어졌다:
<P>
<OL>
<LI>권한이 있는 프로세스로부터 <CODE>ioperm()</CODE> OS 호출을
사용함으로써 장치 레지스터에 대응하는 정확한 I/O 포트 주소들에
억세스하는 퍼미션을 얻는다. 또는 리눅스에 대한 패치
<A HREF="http://garage.ecn.purdue.edu/~papers/giveioperm.html">http://garage.ecn.purdue.edu/~papers/giveioperm.html</A>을 사용하여
독립된 권한있는 사용자 프로세스(즉, "메타 OS")에 의해서 퍼미션이 관리될
수 있다.
</LI>
<LI>386 포트 I/O 명령어들을 사용해서 OS 호출 없이 장치 레지스터들을 억세스.</LI>
</OL>
<P>
<P>다수의 I/O 장치들이 단일 페이지 안에 그들의 레지스터를 갖는 것이
일반적이기 때문에 이 두번째 솔루션이 더 선호된다. 이런 경우 첫번째
기술은 의도된 것과 동일한 페이지에 위치하게 된 다른 장치 레지스터들을
억세스하지 못하도록 하는 보호를 제공하지 못할 것이다. 물론 386 포트 I/O
명령들이 C로 코딩될 수 없다는 것이 단점이다 - 대신 여러분은 약간의
어셈블리 코드를 사용할 필요가 생길 것이다. 바이트 값의 포트 입력을 위한
GCC-랩핑된(C 프로그램에서 사용 가능한) 인라인 어셈블리 코드 함수는
다음과 같다:
<P>
<HR>
<PRE>
extern in
