이 섹션은 리눅스를 사용한 클러스터 병렬 처리의 개관을 제공하려고 시도할 것이다. 클러스터는 현재 가장 인기있는 것이자 가장 다양하다. 이것은 전통적인 워크스테이션들을 여러대 묶은 네트웍(NOW; network of workstations)에서 이제 막 프로세서 노드로써 리눅스 피씨들로 사용하기 시작한 커스텀 병렬 기계까지 있다. 또한 리눅스 기계들의 클러스터를 사용하는 병렬 처리를 위한 많은 소프트웨어 지원들이 있다.
클러스터 병렬 처리는 다음과 같은 중요한 장점들을 제공한다:
좋다. 클러스터는 프리이거나 싸고 아주 커질 수 있으며 가용성이 높다... 그렇다면 왜 모든 사람들이 클러스터를 사용하지 않는가? 글쎄 거기에는 다음과 같은 문제들이 존재한다:
ps 명령은 단일 리눅스 시스템에 실행 중인 프로세스들에
대해서만 보고할 뿐 리눅스 시스템들로 만들어진 클러스터 전체에서 실행
중인 모든 프로세스들에 대해서 보고하지 않는다.
그래서, 클러스터는 굉장한 잠재력을 제공하지만 이 잠재력이 대부분의 어플리케이션들에 대해서 획득되기에는 아주 어려울 수 있다. 이런 환경에 적합한 프로그램들에 대해서 좋은 성능을 획득하도록 하는 많은 소프트웨어 지원이 있다는 것과 좋은 성능을 획득할 수 있는 프로그램들의 범위를 넓힐 수 있도록 특별히 설계된 네트웍들도 있다는 것은 좋은 소식이다.
컴퓨터 네트워킹은 급증하고 있다... 이미 이것을 알고 있을 것이다. 네트워킹 기술과 제품들의 계속-증가하는 영역은 개발이 진행 중에 있고 대부분은 기계들(예, 각각 리눅스를 돌리는 피씨들)의 그룹에 병렬-처리 클러스터를 만드는 데 사용될 수 있는 형태로 사용 가능하다.
불행하게도 어떤 네트웍 기술도 모든 문제들을 훌륭하게 풀지 못한다; 사실 접근, 비용, 성능의 범위는 얼른 봐서 믿기 힘들다. 예를 들어서 표준 상업적으로-가능한 하드웨어를 사용해서 네트웍으로 기계들을 묶는 데 드는 비용은 기계 당 적게는 5달러에서 많게는 4000달러까지 이른다. 제조자가 말하는 대역폭(delivered bandwidth)와 지체 시간 각각은 크기의 네가지 등급(four orders of magnitude)에 따라 변한다.
특정 네트웍에 대해서 배우려고 하기 이전에 이런 것들은 바람처럼 쉽게 변한다는 것을 인식하는 것이 중요하다(리눅스 네트워킹 뉴스들에 대해서는 http://www.uk.linux.org/NetNews.html을 참조). 그리고 어떤 네트웍들에 대하 정확한 데이터를 얻는 것은 아주 어렵다. 특별히 확실하지 않는 곳에 저자는 물음표(?)를 놓았다. 이 주제를 연구하는 데 많은 시간을 썼지만 나는 내 요약(이 문서)이 잘못 투성이고 많은 중요한 것들을 빼먹었다는 것을 확신한다. 교정이나 추가해야 하는 것을 갖고 있다면 pplinux@ecn.purdue.edu로 이메일을 보내주기 바란다.
http://web.syr.edu/~jmwobus/comfaqs/lan-technology.html에 있는 LAN Technology Scorecard와 같은 요약들은 많은 서로 다른 타입들의 네트웍과 LAN 표준들에 대한 특성들을 보여준다. 그러나 이 하우투에 있는 요약은 대부분 리눅스 클러스터를 만드는 데 관련이 있는 네트웍 특성들에 대해서 촛점을 맞췄다. 각 네트웍을 논의하는 섹션은 짧은 특성 리스트로 시작한다. 다음은 이런 엔트리들이 의미하는 바를 정의한다.
(이것에 대한) 답변이 no라면, 그 의미는 분명하다. 다른 대답들은 네트웍을 억세스하는 데 사용되는 기본 프로그램 인터페이스를 설명하려고 할 것이다. 대부분의 네트웍 하드웨어는, 전형적으로 TCP/UDP 통신을 지원하는, 커널 드라이버를 통해서 인터페이스된다. 어떤 다른 네트웍들은 커널을 거치지 않고서 지체 시간을 좀 더 줄이기 위해서 좀 더 직접적인 인터페이스들(예, 라이브러리)을 사용하기도 한다.
몇년전 OS 호출을 통해서 부동 소숫점 유니트를 억세스 하는 것이 완전히 훌륭한 것으로 생각되어졌다. 그러나 이제 그것은 분명 우스운 것이다; 내 의견으로는 병렬 프로그램을 실행하는 프로세서들 간 각 통신이 OS 호출을 요구한다는 것은 어색한 것이다. 문제는 컴퓨터들이 아직도 이런 통신 메카니즘들을 통합하지 못했다는 것이다. 그래서 비-커널 접근은 이식성 문제들을 가지는 경향이 있다. 여러분은 가까운 미래에 이런 것에 대해서 좀 더 많은 것을 듣게 될 것이다. 대개 새로운 Virtual Interface (VI) Architecture http://www.viarch.org/의 형태로 듣게 될 것인 데 이것은 일반적인 OS 호출 계층을 피하는 대부분의 네트웍 인터페이스 작업들에 대한 표준화된 방법이다. VI 표준은 Compaq, Intel, 그리고 Microsoft에 의해서 지원받고 있으며 다음 몇 년 안에 SAN(시스템 영역 네트웍) 디자인에 대한 강한 충격이 될 것임에 틀림없다.
이것은 모든 사람이 신경쓰는 숫자이다. 나는 일반적으로 이론적으로 최선인 경우의 수치를 사용했다; 여러분의 마일리지는 변할 것이다.
내 의견으로는, 이것은 모든 사람들이 대역폭보다 더 신경써야 할 수치이다. 다시 나는 비현실적인 최선인 경우(base-case) 수치를 사용했지만 적어도 이 수치들은 하드웨어와 소프트웨어 모두를 포함하는 모든 지체 소스들을 포함한다. 대부분의 경우 네트웍 지체는 몇 마이크로초이다; 수치가 크면 클수록 하드웨어와 소프트웨어 인터페이스들의 계층들이 비효율적이다는 것을 반영한다.
단순하게 말해서, 이것은 이 타입의 네트웍 하드웨어를 갖출 수 있는 방법을 설명한다. 상품들은 주요 구분 인자로 가격을 가지면서, 많은 벤더들에 의해서 살 수 있다. 다수-벤더에 의한 것들은 하나의 경쟁적인 벤더보다 좀 더 사기 쉽지만 이들은 중요한 차이와 잠재적인 호환성(interoperability) 문제들이 있다. 단일-벤더 네트웍은 공급자의 손에 완전히 종속된다(그러나 그들은 친철할 수도 있다). 퍼블릭 도메인 디자인이란 그것을 여러분에게 팔 사람을 찾지 못하더라도 부품들을 사서 그것을 만들 수 있다는 것을 말한다. 연구 프로토타입들은 말 그대로이다; 그들은 일반적으로 일반적으로 외부 사용자들에게 준비된 것이 아니거나 그들이 살 수 있는 것이 아니다.
이 네트웍을 어떻게 접속(hook-up)할 것인가? 현재 가장 높은 성능과 가장 일반적인 것은 PCI 버스 인터페이스 카드이다. EISA, VESA 로컬 버스(VL 버스), 그리고 ISA 버스 카드들도 있다. ISA는 맨처음에 나온 것이고 아직도 낮은-성능의 카드들에 대해서 많이 사용되는 것이다. EISA는 많은 PCI 기계들에서 두번째 버스로 사용되고 있어서 몇가지 카드들이 있다. 오늘날 VL 물건들을 많이 볼 수 없을 것이다(비록 http://www.vesa.org/가 의견을 달리하지만 말이다).
물론 여러분의 피씨의 케이스를 한번도 열어보지 않고 사용할 수 있는 어떤 인터페이스는 작은 매력 이상 가진다. IrDA와 USB 인터페이스들은 계속 빈번하게 나타나고 있다. 표준 패러럴 포트(SPP)는 프린터를 붙이는 데 사용되지만 ISA 버스의 외부 확장으로써 많이 사용되어 왔다; 이 새로운 기능은 EPP와 ECP 개선을 규정한 IEEE 1284 표준에 의해서 증진되었다. 또한 오래되고 신뢰성 있지만 느린 RS232 시리얼 포트가 있다. 나는 VGA 비디오 커넥터, 키보드, 마우스, 또는 게임 포트들을 사용해서 기계들을 연결하는 것을 알지 못한다... 그래서 여기에 없다.
버스는 구리 선이거나 구리 선들의 모임이거나 광섬유이다. 허브는 여기에 꼽혀 있는 서로 다른 구리선/광섬유들을 연결하는 방법을 알고 있는 작은 박스이다; 스위칭 허브(switched hub)는 다수 커넥션들이 동시에 데이터를 전송하도록 하는 허브이다.
여기서 이런 수치들을 사용하는 방법을 말한다. 네트웍 커넥션을 세지 않고서 클러스터의 한 노드에 쓸려고 피씨를 사는 데 2000달러가 들었다고 가정해보자. 패스트 이더넷(Fast Ethernet)을 더하는 것은 노드당 약 2400달러가 든다; Myrinet을 대신 더하는 데에는 약 3800달러가 든다. 2만달러가 있다면 Fast Ethernet에 연결된 8개의 기계나 Myrinet에 연결돈 5개의 기계를 가질 수 있다는 것을 의미한다. 멀티 네트웍을 가지는 것도 아주 의미있을 수 있다; 예, $20,000로 패스트 이더넷과 TTL_PAPERS 둘 다 가지는 8개 기계들을 구매할 수 있다. 어플리케이션을 가장 빨리 실행할 클러스터를 만들 가능성이 가장 높은 네트웍이나 네트웍 집합을 선택하자.
이것을 읽는 현재 이런 수치들은 틀릴 수도 있다... 제기럴 그들은 아마도 이미 틀렸을 것이다. 또한 양이 줄어들거나 특별 판매(special deal)등이 있을 수 있다. 그러나 여기서 언급된 가격들때문에 여러분이 아주 부적절한 선택을 하게끔 하기에 충분한 잘못된 것일 가능성이 적다. 여러분의 어플리케이션이 네트웍의 특별한 속성을 요구하거나 클러스터링된 피씨들이 상대적으로 비싼 것일 때에만 비싼 네트웍이 의미가 있다는 것을 아는 데는 박사 학위(비록 나는 하나 가지고 있지만 ;-)가 필요 없다.
내 의견을 들었으므로 쇼와 함께 다음에....(Now that you have the disclaimers, on with the show....)
ARCNET은 주로 내장 실시간 제어 시스템들에서 사용되기 위해서 고안된 지역 네트웍(LAN)이다. 이더넷과 비슷하게 네트웍은 물리적으로 버스에 붙인 탭이나 하나 이상의 허브들로 조직된다. 그러나 이더넷과 다르게 이것은 네트웍을 논리적으로 링으로 구축하는 토큰-기반 프로토콜을 사용한다. 패킷 헤더는 작다(3 또는 4바이트). 그리고 메시지들은 단일 바이트 데이터만큼 작게 전달될 수 있다. 그래서, ARCNET은 제한된 지연 등을 가지면서, 이더넷보다 좀 더 일관된 성능을 가진다. 불행하게도 이것은 이더넷보다 더 느리고 덜 유명하다. 그러면서도 더 비싸다. http://www.arcnet.com/에 있는 ARCNET Trade Association로부터 더 자세한 정보를 얻을 수 있다.
지난 몇년 동안 혼수 상태에 있지 않았다면 아마 ATM(비동기 전송 모드)가 어떻게 미래가.. 글쎄, 일종의 미래가 될 수 있는지에 대해서 많이 들었을 것이다. ATM은 HiPPI보다 더 싸고 패스트 이더넷보다 더 빠르며 전화 회사들이 제공하는 거리만큼 긴 거리에도 사용될 수 있다. ATM 네트웍 프로토콜은 또한 더 낮은-오버헤드 소프트웨어 인터페이스를 제공하도록, 그리고 작은 메시지들과 실시간 통신(예, 디지털 오디오와 비디오)을 좀 더 효과적으로 관리하도록 고안되었다. 이것은 또한 리눅스가 현재 지원하는 가장-높은 대역폭 네트웍들 중의 하나이다. 나쁜 소식은 ATM은 싸지 않고 벤더들 간에 호환성 문제가 아직 있다는 것이다. 리눅스 ATM 개발에 대한 개관은 http://lrcwww.epfl.ch/linux-atm/에서 찾을 수 있다.
CAPERS(병렬 실행과 빠른 동기를 위한 케이블 어댑터; Cable Adapter for Parallel Execution and Rapid Synchronization)는, 전기 컴퓨터 엔지니어링의 퍼듀 대학 학교(Purdue University School of Electrical and Computer Engineering)에서의 PAPERS 프로젝트 http://garage.ecn.purdue.edu/~papers/의 부산물이다. 기본적으로 이것은 두 리눅스 피씨들에 대한 PAPERS 라이브러리를 구현하기 위해서, 일반 "LapLink" SPP-to-SPP 케이블을 사용하기 위해서 소프트웨어 프로토콜을 정의한다. 아이디어는 깍이지 않지만 가격을 더 낮출 수는 없다(역자주: 그만큼 싸다?). 시스템 보안을 개선하기 위해서 TTL_PAPERS와 마찬가지로 권고되는 마이너 커널 패치가 있다. 그러나 반드시 필요한 것은 아니다: http://garage.ecn.purdue.edu/~papers/giveioperm.html.
몇년동안 10 Mbits/s 이더넷은 표준 네트웍 기술이 되었다. 좋은 이더넷 인터페이스 카드들은 $50 이하로 살 수 있다. 꽤 많은 피씨들이 이제는 마더보드에 이더넷 컨트롤러를 가지고 있다. 가볍게-사용되는 네트웍에 대해서 이더넷 연결은 허브 없는 멀티-탭 버스로 조직될 수 있다; 그런 설정은 최소의 비용으로 200개까지의 기계들을 묶을 수 있다. 그러나 병렬 처리에는 적절하지 않다. 더비 허브(unswitched hub)를 더하는 것은 실제 성능 향상에 도움이 되지 않는다. 그러나 동시 연결들에 대해서 전체 대역폭을 제공할 수 있는 스위치 허브(switched hub)들은 포트당 단지 약 $100만 든다. 리눅스는 놀라울 정도로 많은 이더넷 인터페이스들을 지원하지만 인터페이스 하드웨어의 변종들은 심각한 성능 차이를 부를 수 있다는 것을 기억하는 것이 중요하다. 어떤 것들이 지원되는지와 그들이 잘 작동하는지에 대해서 하드웨어 호환성 하우투(Hardware Compatibility HOWTO)를 보라; 그리고 다음을 보자 http://cesdis1.gsfc.nasa.gov/linux/drivers/.
성능을 향상하는 흥미로운 방법은 NASA CESDIS에서 수행된 비오울프(Beowulf) 프로젝트 http://cesdis.gsfc.nasa.gov/linux/beowulf/beowulf.html에서 수행된 16-기계 리눅스 클러스터에 의해서 제안되었다. 많은 이더넷 카드 드라이버의 저자인 Donald Becker는 각자 다른 것을 shadow하는(즉, 동일한 네트웍 주소들을 공유하는) 다수의 이더넷 네트웍을 통해서 로드 공유(load sharing)하는 지원을 개발하였다. 이 로드 공유는 표준 리눅스 배포판에 내장되게 되었고 소켓 작업 레벨 아래에 보이지 않게 내장되게 되었다. 허브 비용이 중요하기 때문에 각 기계가 허브 없는 또는 더미 허브를 가진 두 개 이상의 이더넷 네트웍 (역자주: 카드)에 연결하는 것은 성능을 개선하기 위한 비용-효과적인 방법이 될 수 있다. 사실 한 기계가 네트웍 성능 병목에 걸린 상황에서 shadow 네트웍을 사용하는 로드 공유는 단일 스위치 허브 네트웍을 사용하는 것보다 훨씬 더 좋다.
비록 그들을 "패스트 이더넷"으로 부르는 몇가지 다른 기술들이 실제 존재하지만 이 용어는 대개 옛날 "10 BaseT" 100 Mbits/s 장비와 케이블들과 다소 호환되는 허브-기반 100Mbits/s 이더넷을 가리킨다. 기대하는 것처럼 이더넷으로 불리는 것들은 어떤 것이나 일반적으로 용량으로 가격이 매겨지고 이런 인터페이스들은 일반적으로 155 Mbits/s ATM 카드들의 가격에 자그마한 조각에 지나지 않는다. 일단의 기계들이 단일 100 Mbits/s "버스" (더미 허브를 사용해서)의 대역폭을 나눠 쓰도록 하는 것은 각 기계의 연결에 풀로 10 Mbits/s를 제공할 수 있는 스위치 허브를 가지고 10 Mbits/s 이더넷을 사용하는 것보다 좋지 않을 수 있다는 함정(단점)이 있다.
각 기계에게 동시에 100 Mbits/s를 제공할 수 있는 스위치 허브는 비싸지만 가격이 매일 떨어지고 있고 이런 스위치들은 더미 허브보다 훨씬 더 높은 전체 네트웍 대역폭을 만든다. ATM 스위치들을 비싸게 만드는 요인은 그들이 각 ATM 셀(상대적으로 작은)들에 대해서 반드시 스위치해야 한다는 점이다; 어떤 패스트 이더넷 스위치들은 스위치를 지날 때 작은 지체를 가질 수 있는 기술들을 사용함으로써 기대되는 더 낮은 스위칭 주기의 이점을 이용한다. 그러나 스위치 패스를 변경하는 데 몇 밀리초(역자주: 마이크로 초가 아니다)가 걸린다... 그래서 라우팅 패턴이 자주 변한다면 이런 스위치는 피하는 것이 좋다. 여러 카드들과 드라이버들에 대해서는 http://cesdis1.gsfc.nasa.gov/linux/drivers/를 보라.
또한 이더넷에서 설명한 것처럼 NASA에서 이뤄진 Beowulf 프로젝트 http://cesdis.gsfc.nasa.gov/linux/beowulf/beowulf.html가 멀티 패스트 이더넷을 통해서 로드 공유함으로써 성능을 개선한 지원을 개발해오고 있다니 참고 바란다.
기가비트 이더넷(Gigabit Ethernet) http://www.gigabitethernet.org/이 이더넷으로 불리는 좋은 기술적 이유를 가진다고 확신하지 못한다. 그러나 이것이 싸고 큰 시장이 있고 IP를 지원하는 컴퓨터 네트웍 기술을 갖고 있다는 것을 이름이 정확하게 의미하는 것은 아니다. 그러나 현재 가격은 Gb/s 하드웨어가 아직 만들기에 까다로운 것이라는 사실을 반영한다.
다른 이더넷 기술들과는 다르게 기가비트 이더넷은 좀 더 믿을 수 있는 네트웍을 만드는 흐름 제어의 레벨을 제공한다. FDR, 즉 풀-듀플렉스 리피터(Full-Duplex Repeater)는 성능을 향상시키기 위해서 버퍼링과 지역화된 흐름 제어를 사용하면서, 단순하게 라인들을 멀티플렉스한다. 대부분의 스위치 허브들은 현존하는 기가비트-가능 광섬유 스위치(gigabit-capable switch fabrics)에 대한 새로운 인터페이스 모듈들로써 구축되고 있다. 스위치/FDR 제품들은 적어도 다음과 같은 사이트들에서 구매될 수 있거나 발표되고 있다. http://www.acacianet.com/, http://www.baynetworks.com/, http://www.cabletron.com/, http://www.networks.digital.com/, http://www.extremenetworks.com/, http://www.foundrynet.com/, http://www.gigalabs.com/, http://www.packetengines.com/. http://www.plaintree.com/, http://www.prominet.com/, http://www.sun.com/, and http://www.xlnt.com/.
리눅스 드라이버 http://cesdis.gsfc.nasa.gov/linux/drivers/yellowfin.html가 존재하며 Packet Engines "Yellowfin" G-NIC에 대해서는 http://www.packetengines.com/. 리눅스에서 한 초기 테스트는 가장 좋은 100 Mb/s 패스트 이더넷으로 획득될 수 있는 것보다 약 2.5배 높은 대역폭을 얻었다; 기가비트 네트웍의 경우PCI 버스 사용을 조심스럽게 튜닝하는 것이 중요한 인자이다. 의심할 바 없이 드라이버 개선과 다른 NIC들에 대한 리눅스 드라이버 지원이 계속 이어질 것이다.
FC(광섬유 채널)의 목적은 높은-성능 블럭 I/O(2,048 바이트 데이터 하중을 실어나르는 FC 프레임)를 제공하는 것이다. 특별히 컴퓨터를 통해서가 아니라 FC에 직접 연결될 수 있는 다른 저장 장치와 디스크들을 공유하기 위해서 말이다. 대역폭-별로 FC는 133에서 1,062 Mbits/s 사이 어디에서나 실행되면서 상대적으로 빠르다고 한다. FC가 high-end SCSI를 대체할 만큼 유명해진다면 이것은 값싼 기술이 될 것이다; 지금은 값싼 기술이 아니며 리눅스에 의해서 지원되지 않는다. FC 레퍼런스들에 대한 좋은 콜랙션은 http://www.amdahl.com/ext/CARP/FCA/FCA.html에서 Fibre Channel Association에 의해서 관리되고 있다.
FireWire, http://www.firewire.org/, IEEE 1394-1995 표준인 이것은 고객 전자장비(electronics)를 위한 저비용 고속 디지탈 네트웍을 위해서 고안된 것이다. 진열장 어플리케이션은 DV 디지털 비디오 캠코더를 컴퓨터에 연결하는 것이지만 FireWire는 SCSI를 대체하는 것부터 여러분의 가정극장(home theater)의 각 컴포넌트들을 상호연결하는 것까지의 어플리케이션들을 위하여 사용되도록 의도되었다. 이것은 원(cycle)을 만들지 않는 버스들과 브리지들을 사용하는 임의의 토폴로지에서 연결된 64K 장비들까지 허락하고 컴포넌트들이 더해지거나 제거될 때 자동으로 설정을 검출한다. 짧고(4 바이트 "quadlet") 낮은 지체 시간을 가지는 메시지들이 ATM-like한 동기(isochronous) 전송(멀티미이더 메시지들의 동기를 맞추는 데 사용된다)과 함께 지원된다. 아답텍(Adaptec)은 단일 PCI 인터페이스 카드에 63개까지 장치들을 허락하는 FireWire 제품들을 가지고 있고 http://www.adaptec.com/serialio/에 FireWire에 대한 좋은 일반적인 정보를 담고 있다.
비록 FireWire가 사용 가능한 가장 높은 대역폭 네트웍이 될 수는 없겠지만 고객-레벨 마켓(가격을 아주 낮게 만들)과 낮은 지체 시간 지원은 이것을 몇년 이내에 리눅스 피씨 클러스터 메시지-전달 네트웍 기술들 중의 하나로 만들 것이다.
HiPPI (High Performance Parallel Interface)는 원래 슈퍼 컴퓨터와 다른 기계(슈퍼컴, 프레임 버퍼, 디스크 어레이 등) 간에 대량의 데이터 셋들의 전송을 위해서 아주 높은 대역폭을 제공하도록 의도되었으며 슈퍼컴에 대한 지배적인 ㅍ준이 되었다. 비록 이것은 모순 어법(oxymoron)이긴 하지만 시리얼 HiPPI도 또한 32-비트 폭 표준(패러럴) HiPPI 케이블 대신에 광섬유 케이블을 전형적으로 사용함으로써, 유명해질 것이다. 지나 몇 년동안 HiPPI 크로스바 스위치들은 일반적인 것이 되었으며 가격들은 급격하게 떨어졌다; 불행하게도 시리얼 HiPPI는 아직 비싸고 이것이 바로 PCI 버스 인터페이스 카드들은 일반적으로 지원하는 것이다. 더 나쁜 것은 리눅스는 아직 HiPPI를 지원하지 못한다는 것이다. HiPPI의 좋은 개관은 CERN에 의해서 http://www.cern.ch/HSI/hippi/에서 관리되고 있다; 그들은 또한 http://www.cern.ch/HSI/hippi/procintf/manufact.htm에 HiPPI 벤더들의 다소 기다란 리스트를 관리한다.
IrDA(적외선 데이터 연합, http://www.irda.org/)는 많은 랩톱 피시들의 측면에 있는 작은 적외선 장치이다. 이 인터페이스를 사용해서 두 개 이상의 기계들을 커넥트하는 것은 타고 날 때부터 어렵다. 그래서 클러스터링에 사용될 가능성이 낮다. Don Becker가 IrDA에 몇가지 예비 작업을 했었다.
Myrinet http://www.myri.com/은 "시스템 영역 네트웍" (System Area Network, SAN)으로 사용될 수 있도록 고안된 근거리 영역 네트웍(LAN)이다. 즉 병렬 시스템으로 연결된 기계들이 가득찬 네트웍 케비넷. LAN과 SAN 버전들은 서로 다른 물리적 매체를 사용하고 다소 다른 특성들을 가진다; 일반적으로 SAN 버전은 클러스터 안에서 사용될 것이다.
Myrient은 구조적으로 아주 전통적인 것이지만 특별히 잘-구현된 것이라는 평판을 듣고 있다. 리눅스를 위한 드라이버는 성능이 좋다는 말을 듣는다. 비록 호스트 컴퓨터에 대한 서로 다른 PCI 버스 구현물들에 대해서 여러 커다란 성능 변화들이 리포트된 바가 있었지만 말이다.
현재 Myrinet은 너무 심각하게 "예산을 위협하는" 것이 아닌 클러스터 그룹의 선호되는 네트웍임에 틀림없다. 리눅스 피씨에 대한 생각이 최소 256 MB RAM과 SCSI RAID를 가진 Pentium Pro나 Pentium II라면 Myrinet의 가격은 꽤 합리적인 것이 된다. 그러나 좀 더 일반적인 피씨 설정을 사용한다면 여러분의 선택이 Myrinet에 연결된 N 기계들이나 멀티 패스트 이너넷으로 묶인 2N과 TTL_PAPERS 사이에 있다는 것을 알게 될 것이다. 여러분의 예산이 얼마나 되는가와 여러분이 신경쓰는 컴퓨터의 사양이 어떤 것인가에 따라 좌지 우지 된다.
Karlsruhe 대학교 정보공학과(Department of Informatics)의 파라스테이션(Parastation) 프로젝트 http://wwwipd.ira.uka.de/parastation는 PVM-호환 커스텀 저-지체 네트웍을 구축 중이다. 그들은 맨처음 커스텀 EISA 인터페이스와 BSD UNIX를 실행하는 피씨들을 사용한 맨처음 구축된 두개의 프로세서 ParaPC 프로토타입을 만들었으며 그 다음 DEC Alpha들을 사용한 좀 더 큰 클러스터들을 만들었다. PCI 카드들은 Hitex이라고 불리는 회사와 공조해서 만들어졌다( http://www.hitex.com:80/parastation/ 참조). 파라스테이션 하드웨어는 빠르고 신뢰성 있는 메시지 전송과 단순한 관문(barrier) 동기화를 구현한 것이다.
"LapLink" 케이블의 비용으로 PLIP(Parallel Line Interface Protocol)는 표준 소켓-기반 소프트웨어를 사용하여 표준 패러럴 포트들을 통해서 두 리눅스 기계들이 통신할 수 있도록 한다. 대역폭, 지체, 그리고 측정가능성(scalability)의 측면에서 보면 이것은 아주 중요한 네트웍 기술이 아니다. 그러나 거의 영에 가까운 가격과 소프트웨어 호환성이 유용하다. 드라이버는 표준 리눅스 커널 배포판의 일부이다.
SCI (Scalable Coherent Interconnect, ANSI/IEEE 1596-1992)의 목적은 기본적으로 많은 수의 기계들에 걸쳐 근접(coherent) 공유 메모리 공유를 지원할 수 있는 고성능 메카니즘과 다양한 타입의 메시지 전송을 제공하는 것이다. SCI의 고안된 대역폭과 지체는 대부분의 다른 네트웍 기술들과 비교해서 둘 다 "놀라운 것"이라고 말해도 괜찮다. 단점은 SCI가 싼 제품 유니트로써 널리 사용가능하지 않다는 것과 리눅스 지원이 아직 없다는 것이다.
SCI는 주로 HP/Convex Exemplar SPP와 Sequent NUMA-Q 2000( http://www.sequent.com/)와 같은 지역적으로-공유된 물리적으로-배포된 메모리 기계들(logically-shared physically-distributed memory machines)에 대한 다양한 고유 디자인 안에서 사용되었다. 그러나 Dolphin( http://www.sequent.com/ 참조)로부터 SCI는 PCI 인터페이스 카드와 4-way 스위치(16 기계들까지 네개의 4-way 스위치들을 붙여서 연결될 수 있다)들이 그들의 CluStar 제품 라인으로써 사용가능하다. SCI 개관에 대한 좋은 링크들은 CERN에 의해서 http://www.cern.ch/HSI/sci/sci.html에서 관리된다.
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보다 더 빠르고 장비들을 좀 더 효율적으로 관리할 수 있다는 것을 안다.
많은 사람들이 깨닫지 못하는 것은 두 컴퓨터들이 단일 SCSI 버스를 공유하는 것이 아주 단순하다는 사실이다. 이런 설정 타입은 기계간 디스크 드라이브들을 공유하고 장애 복구(fail-over)를 구현-한 기계가 다른 기계가 실패했을 때 데이터베이스 요구를 떠맡도록 하게 함으로써-에 아주 유용하다. 현재 이것은 마이크로소프트의 PC 클러스터 제품 WolfPack에 의해서 지원되는 유일한 메카니즘이다. 그러나 좀 더 큰 시스템들로 확장될 수 없다는 것이 공유 SCSI를 일반적인 병렬 처리에 있어 덜 흥미롭게 만든다.
서버넷(ServerNet)은 Tandem, http://www.tandem.com의 고-성능 네트웍 하드웨어이다. 특별히 온라인 트랜잭션 처리(OLTP) 세계에서 탠덤은 고-신뢰도 시스템들의 선두로 알려져 있어서 그들의 네트웍이 고-성능 뿐만이 아니고 "높은 데이터 통합(integrity)과 신뢰도"까지 주장해도 놀라운 일이 아니다. ServerNet의 다른 흥미로운 면은 임의의 장치에서 다른 임의의 장치로 직접 데이터를 전송할 수 있다고 주장한다는 것이다; MPI 섹션에서 설명된 MPI 리모트 메모리 억세스 메카니즘들에 의해서 제안된 것과 비슷한 원-사이드 스타일로, 프로세서들사이뿐만이 아니고 디스크 드라이브들 등 사이에서도 그렇다. 서버넷에 대한 마지막 한가지 코멘트: 단지 싱글 벤더만 존재하지만 그 벤더는 서버넷을 주요 표준으로, 잠재적으로 만들 수 있을 만큼 충분히 강력하다. Tandem은 Compaq 소유이다.
프린스턴 대학교 컴퓨터 과학 학과에서 진행하고 있는 SHRIMP 프로젝트, http://www.CS.Princeton.EDU/shrimp/는 처리 노드로써 리눅스를 실행하는 피씨들을 사용한 병렬 컴퓨터를 구축하고 있다. 첫번째 SHRIMP(Scalable, High-Performance, Really Inexpensive Multi-Processor의 약자)는 커스텀 EISA 카드 인터페이스 위의 듀얼 포트를 가지는 RAM을 사용한 단순한 두-프로세서 프로토 타입이었다. 지금은 인텔 Paragon( http://www.ssd.intel.com/paragon.html 참조)에서 사용된 그물망(mesh) 라우팅 네트웍과 기본적으로 동일한 "hub"에 연결하기 위해서 커스텀 인터페이스를 사용하는 좀 더 큰 설정들에 확장가능한 프로토타입이 존재한다. 오베헤드가 적은 "가상 메모리 맵된 통신" 하드웨어와 지원 소프트웨어를 개발하기 위한 상당히 많은 노력이 이루어졌다.
비록 SLIP(시리얼 라인 인터페이스 프로토콜;Serial Line Interface Protocol)은 성능 스펙트럼에서 낮은 쪽에 완전히 위치하고 있지만 SLIP(또는 CSLIP또는 PPP)는 두 기계들이 일반 RS232 시리얼 포트들을 통해서 소켓 통신을 수행할 수 있도록 한다. 또는 그들은 모뎀을 경유한 다이얼-업을 통해서 연결될 수도 있다. 어떤 경우에도 지체 시간은 높고 대역폭은 낮다. 그래서 SLIP은 다른 대안들이 전혀 불가능할 때만 사용되어야 할 것이다. 그러나 대부분의 피씨드이 두 개의 RS232 포트들을 갖고 있다는 것은 주목할만한 가치가 있다. 그래서 기계들을 선형 배열이나 링형으로 단순하게 연결해서 기계들 그룹을 네트워킹하는 것이 가능하다. EQL이라고 불리는 로드 쉐어링 소프트웨어도 존재한다.
퍼듀 대학교의 전자 및 컴퓨터 엔지니어링 학교에서 수행 중인 PAPERS (Purdue's Adapter for Parallel Execution and Rapid Synchronization) 프로젝트, http://garage.ecn.purdue.edu/~papers/는 병렬 슈퍼컴퓨터가 변조되지 않은 피씨들/워크스테이션들을 노드로 사용하여 구축될 수 있도록 하는, 크기 조절 가능하고 낮은-지체 시간을 가지며 집합 함수 통신 하드웨어와 소프트웨어를 구축 중에 있다.
두가지 개발 라인들을 대략 따르는 SPP(표준 패러럴 포트; Standard Parallel Port)를 통해서 피씨들/워크스테이션들을 연결한 PAPERS 하드웨어는 그 종류가 12가지가 넘는다. "PAPERS"라고 불리는 버전들은 적절한 기술이면 무엇이든지 사용해서 더 높은 성능을 목표로 한다; 현재 작업은 FPGA들과 지금 개발 중에 있는 높은 대역의 PCI 버스 인터페이스 설계들을 사용한다. 반면에 "TTL_PAPERS"이라고 불리는 버전들은 퍼듀 대학 바깥에서 쉽게 재생산될 수 있도록 디자인된 것이고 일반적인 TTL 로직을 사용해서 만들어질 수 있는 아주 단순한 공용 도메인 설계(public domain designs)이다. 이런 디자인 중 하나는 상용으로 만들어졌다. http://chelsea.ios.com:80/~hgdietz/sbm4.html
다른 대학들의 커스텀 하드웨어 디자인과 다르게 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들이 가장 잘 지원되는 플랫폼이다.
TTL_PAPERS AFAPI를 사용하는 사용자 프로그램들은 리눅스에서, 각
억세스에 대해서 OS 호출없이 SPP 하드웨어 포트 레지스터들을 억세스한다.
이렇게 하기 위해서 AFAPI는 맨먼저 iopl()나 ioperm()를
사용해서 포트 퍼미션을 획득한다. 이런 호출들의 문제점은 둘 다 사용자
프로그램이 권한을 갖도록(역자주: 아무래도 루트 권한일 것 같다) 요구해서
잠재적인 보안 구멍을 만든다는 것이다. 솔루션은 선택적인 커널 패치,
http://garage.ecn.purdue.edu/~papers/giveioperm.html이다. 이것은
권한있는 프로세스가 임의의 프로세스에 대한 포트 퍼미션을 제어하도록
한다.
USB (Universal Serial Bus, http://www.usb.org/)는 키보드, 화상 회의 카메라 등 127개까지 주변기기들을 달 수 있고 핫-플러그(hot-pluggable) 가능한 일반 이더넷 수준의 속도를 내는 버스이다. 얼마나 많은 컴퓨터들이 서로 USB를 사용해서 연결될 수 있는지는 실제 명확하지 않다. 어쨌든 USB 포트들은 지금 빠르게 RS232와 SPP와 같은 PC 마더보드의 표준이 되어가고 있다. 그러므로 여러분이 구매한 차기 PC의 뒤편에 USB 포트들이 숨어 있더라도 놀라지 말기 바란다. 리눅스 드라이버 개발은 http://peloncho.fis.ucm.es/~inaky/USB.html에서 논의되고 있다.
여러가지 점에서 USB는 거의 여러분이 현재 구매할 수 있는, 낮은-성능, 제로-비용(zero-cost)인 FireWire 버전이다.
WAPERS (병렬 실행과 빠른 동기화를 위한 Wired-AND 아답터; Wired-AND Adapter for Parallel Execution and Rapid Synchronization)는 퍼듀 대학교의 전자 컴퓨터 공학 학교에서 수행 중인 PAPERS 프로젝트, http://garage.ecn.purdue.edu/~papers/의 부산물이다. 적절하게 구현된다면 SPP는 4-비트 폭 wired AND를 구현하기 위해서 기계들 간 서로 묶일 수 있는 4비트 오픈-콜렉터 출력을 가진다. 이 wired-AND는 전자공학적으로 다루기 어려운 것이고 이런 식으로 연결될 수 있는 기계들의 최대 개수는 포트의 아날로그 특성에 종속적이다(최대 수신 전류(sink current)와 휴식 레지스터(pull-up register) 값); 전형적으로 7개 내지 8개 기계들이 WAPERS로 네트워킹될 수 있다. 비록 비용과 지체시간이 아주 낮지만, 그래서 대역폭도 낮다; WAPERS는 클러스터에서 단일 네트웍으로써가 아니라 집합 작업들에 대한 두번째 네트웍으로써 훨씬 더 좋다. TTL_PAPERS와 함께, 시스템 보안을 높이기 위해서, 반드시 필요하지는 않지만 권고되는 마이너 커널 패치가 있다: http://garage.ecn.purdue.edu/~papers/giveioperm.html.
병렬 어플리케이션들을 지원하는 소프트웨어를 논의하기 이전에 네트웍 하드웨어에 대한 로우-레벨 소프트웨어 인터페이스의 기본을 간단히 먼저 얘기하는 것이 유용하다. 실제로 3가지 기본 선택만 존재한다: 소켓, 장치 구동기(device drivers), 그리고 유저-레벨 라이브러리.
지금까지 가장 일반적인 로우-레벨 네트웍 인터페이스는 소켓 인터페이스이다. 소켓은 지난 10년간 유닉스의 일부였고 대부분의 표준 네트웍 하드웨어는 적어도 두가지 타입의 소켓 프로토콜들: UPD와 TCP를 지원하도록 설계된 것이다. 두 소켓 타입들은 한 기계에서 다른 것으로 임의 크기의 데이터 블럭을 전송할 수 있도록 하지만 몇가지 중요한 차이가 있다. 비록 성능은 네트웍 트래픽에 따라서 훨씬 악화될 수 있지만 전형적으로 이 두가지는 약 1,000 마이크로 초 정도의 최소 지체를 만든다.
이런 소켓 타입들은 대부분의 이식 가능, 하이-레벨, 병렬 처리 소프트웨어에 대한 기본 네트웍 소프트웨어 인터페이스이다; 예를 들어서 PVM은 UDP와 TCP를 혼합하여 사용하기 때문에 이 둘의 차이점을 아는 것은 성능을 튜닝하는 데 도움을 줄 것이다. 좀 더 나은 성능을 위해서 프로그램 안에서 직접 이런 메카니즘들을 사용할 수도 있다. 다으은 UDP와 TCP의 단순한 개관이다; 자세한 내용은 매뉴얼 페이지들과 좋은 네트웍 프로그래밍 책을 보기 바란다.
UDP는 사용자 데이터그램 프로토콜(User Datagram Protocol)이지만 UDP의 속성을 신뢰할 수 없는 데이터그램 처리(Unreliable Datagram Processing)로 좀 더 쉽게 기억할 수 있을 것이다. 다른 말로 해서 UDP는 각 블럭이 개별 메시지로 전송되도록 허락하지만 메시지는 전송 중 유실될 수 있다. 사실 네트웍 트래픽에 종속적으로 UDP 메시지들은 유실될 수 있고 여러번 도착할 수 있거나 그들이 보내진 순서와 다른 순서로 도착할 수 있다. UDP 메시지의 전송자는 자동으로 받았다는 통지(acknowledgement)를 받지 않는다. 그래서 이런 문제들을 검출하고 보충하는 것은 사용자가 작성한 코드에 의존한다. 다행스럽게도 UDP는 메시지가 도착했다면 받은 메시지가 손상된 것이 아니고 완전한 것이라고(즉, UDP 메시지 조각만 받았다고) 보장한다.
UDP가 좋은 점은 가장 빠른 소켓 프로토콜이 되려고 한다는 것이다. 더 나아가 UDP는 "연결 없는(connectionless)" 것이다. 이것은 각 메시지가 기본적으로 모든 다른 것들과 독립이다는 것을 의미한다. 이것에 대한 좋은 비유는 편지이다; 여러분은 동일한 집주소로 여러 편지를 보낼 수 있지만 각각은 다른 것들과 독립이며 여러분이 편지를 보낼 수 있는 사람의 수에 대한 제한이 없다.
UDP와 다르게 TCP는 신뢰할 수 있고, 연결-기반인 프로토콜이다. 보내진 각 블럭은 메시지로 보이지 않고 겉보기에 전송자와 수신자 사이의 연결을 통해서 전송된 연속적인 바이트안에서 데이터 블럭으로 보인다. 이것은 UDP 메시징과 아주 다르다. 왜냐면 각 블럭은 단순하게 바이트 스트림의 일부이고 각 블럭을 바이트 스트림에서 추출하는 방법을 알아 내는 것은 사용자 코드에 종속적이기 때문이다; 메시지들을 분리하는 마킹은 없다. 더 나아가 네트웍 문제들에 대해서 연결은 좀 더 깨지기 쉬운 것이고 연결의 제한된 개수들만이 각 프로세스들에 대해서 동시에 존재할 수 있다. 이것은 신뢰할 수 있기 때문에 TCP는 일반적으로 UDP보다 좀 더 무거운 오버헤드를 가진다.
그러나 TCP에 관한 몇가지 즐거운 놀라운 것들이 존재한다. 다수 메시지들이
연결을 통해서 전달되었다면, 짧은 또는 짝이 맞지 않은 크기의 메시지들의
그룹에 대해서 UDP보다 더 나은 성능을 잠재적으로 내면서, TCP는 그것들을
버퍼 안에서 네트웍 하드웨어 패킷 크기에 더 잘 맞도록 묶을 수 있다는 것이
첫번째이다. 다른 보너스는 기계들 간에 신뢰할 수 있는 직접 물리적
링크들을 사용해서 구축된 네트웍은 TCP 연결을 쉽고 효율적으로 흉내낼 수
있다는 것이다. 예를 들어서 ParaStation의 "Socket Library" 인터페이스
소프트웨어의 경우 이렇게 되었다. 이 소프트웨어는 표준 TCP OS 호출들과 각
함수 이름에다 접두사 PSS를 붙이는 것만 다른 사용자-레벨
호출들을 사용한 TCP 문법(semantics)을 제공한다.
네트웍에 데이터를 실제로 넣을 때가, 또는 네트웍으로부터 데이터를 끄집어
올 때가 오면 표준 유닉스 소프트웨어 인터페이스는 장치 구동기라고 불리는
유닉스 커널의 일부가 된다. UDP와 TCP는 단지 데이터만 전송하지 않고
그들은 또한 상당한 양의 소켓 관리의 오버헤드를 갖고 있다. 예를 들어서
어떤 것들은 다수의 TCP 커넥션들이 하나의 물리적 네트웍 인터페이스를
공유할 수 있다는 사실을 관리해야 한다. 이에 비해서 전용 네트웍
인터페이스에 대한 장치 구동기는 단지 몇가지 단순한 데이터 전송 함수들만
구현하면 된다. 이런 장치 드라ㅇ이버 함수들은 사용자 프로그램에 의해서,
적절한 장치를 확인하기 위해서 open()을 사용하고 오픈된 "파일"에
대해서 read()와 write()와 같은 시스템 호출을
사용함으로써, 호출될 수 있다. 그래서 각각의 그런 작업은 데이터 블럭을
시스템 호출의 오버헤드보다 더 작은 오버헤드로 전송할 수 있다. 이런
시스템 호출은 수십 마이크로 초가 걸린다.
리눅스에 대한 장치 구동기를 작성하는 것은 어렵지 않다... 장치 하드웨어가 작동하는 방법을 정확하게 알고 있다면 말이다. 이것이 작동하는 방법을 모른다면 추측하지 말라. 장치 드라이버를 디버깅하는 것은 즐겁지 않은 일이고 실수들은 하드웨어를 태워먹을 수 있다. 그러나 이것이 여러분을 그렇게 겁주는 것이 아니라면, 예를 들어서 전용 이더넷 카드를 더미로 그러나 일반적인 이더넷 프로토콜 오버헤드 없이 기계-대-기계 빠른 직접 연결로 사용하기 위해서, 장치 구동기를 작성하는 것은 가능한 일이 될 수 있다. 사실 초기 인텔 슈퍼컴퓨터들이 했던 것과 상당히 유사하다.... 좀 더 자세한 정보를 보고 싶다면 Device Driver HOWTO를 보라.
여러분이 OS 코스를 택했다면 하드웨어 장치 레지스터에 대한 사용자-레벨 억세스는 정확히 여러분이 한번도 배운 적이 없는 것이다. 왜냐면 OS의 주요 목적 중 하나는 장치 억세스를 제어하는 것이기 때문이다. 그러나 OS 호출은 적어도 수십 마이크로 초 오버헤드가 걸린다. 단지 3 마이크로 초 동안에 기본 네트웍 작업을 수행할 수 있는 TTL_PAPERS와 같은 커스텀 네트웍 하드웨어의 경우 그런 OS 호출 오버헤드는 참을 수 없는 것이다. 그런 오버헤드를 피하는 유일한 방법은 하드웨어 장치 레지스터들을 직접 억세스하는 사용자-레벨 코드 - 사용자-레벨 라이브러리 - 를 가지는 것이다. 그래서 사용자-레벨 라이브러리가 하드웨어를 직접 억세스할 수 있는 방법은 무엇인가, 하지만 장치 억세스 권한에 대한 OS 제어와 타협하지 않는 방법은 무엇인가와 같은 것이 질문이 될 것이다.
전형적인 시스템에서 사용자-레벨 라이브러리가 하드웨어 장치 레지스터를 직접 억세스하는 유일한 방법은 다음과 같다:
mmap() 호출(섹션
메모리 맵 호출 에서 맨처음 언급됨)이 I/O
장치들의 물리적 메모리 페이지 주소들의 표현하는 특수 파일을 맵핑하는 데
사용될 수 있다. 또는 이런 기능을 수행하는 장치 구동기를 작성하는 일은
상대적으로 쉽다. 더 나아가 이 장치 구동기는 필요한 특정 장치
레지스터들을 담고 있는 페이지(들)을 맵핑하는 것만으로 억세스를 제어할 수
있다. 그래서 OS 억세스 제어를 유지할 수 있다.
*((char *) 0x1234) = 5;는
메모리 위치 1234(16진수)에다 바이트 값 5를 저장할 것이다.다행스럽게도 인텔 386(그리고 호환 프로세스들)에 대한 리눅스가 좀 더 나은 솔루션을 제공하는 일이 벌어졌다:
ioperm() OS 호출을
사용함으로써 장치 레지스터에 대응하는 정확한 I/O 포트 주소들에
억세스하는 퍼미션을 얻는다. 또는 리눅스에 대한 패치
http://garage.ecn.purdue.edu/~papers/giveioperm.html을 사용하여
독립된 권한있는 사용자 프로세스(즉, "메타 OS")에 의해서 퍼미션이 관리될
수 있다.
다수의 I/O 장치들이 단일 페이지 안에 그들의 레지스터를 갖는 것이 일반적이기 때문에 이 두번째 솔루션이 더 선호된다. 이런 경우 첫번째 기술은 의도된 것과 동일한 페이지에 위치하게 된 다른 장치 레지스터들을 억세스하지 못하도록 하는 보호를 제공하지 못할 것이다. 물론 386 포트 I/O 명령들이 C로 코딩될 수 없다는 것이 단점이다 - 대신 여러분은 약간의 어셈블리 코드를 사용할 필요가 생길 것이다. 바이트 값의 포트 입력을 위한 GCC-랩핑된(C 프로그램에서 사용 가능한) 인라인 어셈블리 코드 함수는 다음과 같다:
extern inline unsigned char
inb(unsigned short port)
{
unsigned char _v;
__asm__ __volatile__ ("inb %w1,%b0"
:"=a" (_v)
:"d" (port), "0" (0));
return _v;
}
비슷하게 바이트 포트 출력을 위한 GCC-랩핑된 코드는 다음과 같다:
extern inline void
outb(unsigned char value,
unsigned short port)
{
__asm__ __volatile__ ("outb %b0,%w1"
:/* no outputs */
:"a" (value), "d" (port));
}
PVM(병렬 가상 기계)는 일반적으로 소켓 위에 구현된, 자유롭게 사용할 수 있고 이식될 수 있는 메시지 전달 라이브러리이다. 이것은 분명히 메시지 전달 클러스터 병렬 컴퓨팅을 위한 사실상의 표준으로 자리를 잡았다.
PVM은 단일-프로세서와 SMP 리눅스 기계들, 그리고 소켓-가능 네트웍(예, SLIP, PLIP, 이더넷, ATM)에 의해서 링크된 리눅스 기계들의 클러스터를 지원한다. 사실 PVM은 다양한 서로 다른 타입들의 프로세서들, 설정, 그리고 물리적인 네트웍들이 사용된 기계들 그룹 - 이기종 클러스터 -에서 병렬 클러스터로써 인터넷을 통해서 링크된 기계들을 처리하는 범위까지 작동한다. PVM은 또한 클러스터를 통해서 병렬 작업 제어를 위한 기능들을 제공한다. 이들 중 가장 좋은 것, PVM은 오랫동안 자유롭게 사용 가능하였고(현재는 http://www.epm.ornl.gov/pvm/pvm_home.html에 있음) 많은 프로그래밍 언어, 어플리케이션 라이브러리, 디버깅 툴 등과 같은 것에, 그것을 그들의 "이식 가능한 메시지-전달 타겟 라이브러리"로 사용하여, 이르게 되었다. 네트웍 뉴스 그룹 comp.parallel.pvm이 있다.
그러나 PVM 메시지 전달 호출들은 일반적으로 이미 높은 지체를 가지는 표준 소켓 작업들에 심각한 오버헤드를 추가한다. 더 나가아가 메시지 핸들링 호출들 자신은 특별히 "프렌들리"한 프로그래밍 모델을 이루지 않았다.
섹션 예제 알고리즘에서 맨처음 설명된 것과 동일한 파이(pi) 계산 예제를 사용해서 만든, C와 PVM 라이브러리 호출을 사용한 버전은 다음과 같다:
#include <stdlib.h>
#include <stdio.h>
#include <pvm3.h>
#define NPROC 4
main(int argc, char **argv)
{
register double lsum, width;
double sum;
register int intervals, i;
int mytid, iproc, msgtag = 4;
int tids[NPROC]; /* array of task ids */
/* enroll in pvm */
mytid = pvm_mytid();
/* Join a group and, if I am the first instance,
iproc=0, spawn more copies of myself
*/
iproc = pvm_joingroup("pi");
if (iproc == 0) {
tids[0] = pvm_mytid();
pvm_spawn("pvm_pi", &argv[1], 0, NULL, NPROC-1, &tids[1]);
}
/* make sure all processes are here */
pvm_barrier("pi", NPROC);
/* get the number of intervals */
intervals = atoi(argv[1]);
width = 1.0 / intervals;
lsum = 0.0;
for (i = iproc; i<intervals; i+=NPROC) {
register double x = (i + 0.5) * width;
lsum += 4.0 / (1.0 + x * x);
}
/* sum across the local results & scale by width */
sum = lsum * width;
pvm_reduce(PvmSum, &sum, 1, PVM_DOUBLE, msgtag, "pi", 0);
/* have only the console PE print the result */
if (iproc == 0) {
printf("Estimation of pi is %f\n", sum);
}
/* Check program finished, leave group, exit pvm */
pvm_barrier("pi", NPROC);
pvm_lvgroup("pi");
pvm_exit();
return(0);
}
PVM은 사실상 표준 메시지-전달 라이브러리인 반면에 MPI(메시지 전달 인터페이스)는 상대적으로 새로운 공식 표준이다. MPI 표준에 대한 홈 페이지는 http://www.mcs.anl.gov:80/mpi/이며 뉴스그룹은 comp.paralle.mpi이다.
그러나 MPI를 논의하기 전에 저자는 지난 몇년 동안 일어난 PVM 대 MPI 종교 전쟁에 대해서 조금 얘기하고 싶은 충동을 느낀다. 다음은 차이점들에 대해서 상대적으로 편견없이 요약하려고 시도한 것이다:
단순하게 얘기해서 MPI는 실행 제어 환경이 어떻게 구현되는가와 구현될 수 있는지 없는지를 지정하지 않은 반면 PVM은 실행 제어 환경 하나를 갖는다. 그래서 PVM 프로그램 실행을 시작하는 것과 같은 일들은 모든 곳에서 동일하게 이루어지는 반면 MPI의 경우 이것은 어떤 구현이 사용되는가에 따라서 다를 수 있다.
PVM은 워크스테이션 사이클-활용 세계에서 자라났고 그래서 직접 기계와 운영 체제의 이기종 혼합을 관리한다. 반면에 MPI는 타겟이 MPP(거대한 병렬 프로세서)이거나 거의 동일한 워크스테이션들의 전용 클러스터일 것이라고 가정한다.
PVM는 MPI 2.0이 하지 못하는 목적의 통일을 증명한다. 새로운 MPI 2.0 표준은 기본 메시지 전달 모델을 벗어나는 많은 기능들을 담고 있다 - RMA(리모트 메모리 억세스, Remote Memory Access)와 병렬 파일 I/O와 같은 것들. 이런 것들이 유용한가? 물론 그들은 그렇다... 그러나 MPI 2.0을 배우는 것은 완전히 새로운 프로그래밍 언어를 배우는 것과 거의 똑같다.
MPI는 PVM을 따라 설계되었고 분명히 그것으로부터 배웠다. MPI는 더 단순하고 더 효과적인 버퍼 핸들링과 메시지로 사용자-정의 데이터 구조가 전달되도록 하는 고수준 추상화를 제공한다.
내 계산에 의하면 MPI를 사용하는 것보다 PVM을 사용하도록 설계된 것들이 아직 아주 많이 있다; 그러나 그것들을 MPI로 포팅하는 것은 쉽다. 그리고 MPI가 널리 지원되는 형식적인 표준에 의해서 지원된다는 사실은 MPI를 사용하는 것은 많은 기관들의 경우, 정책상의 문제이다는 것을 의미한다.
결론이 났는가? 글쎄 리눅스 시스템들로 만든 클러스터에서 실행할 수 있는, 자유롭게 사용할 수 있고 독립적으로 개발된 MPI 버전은 적어도 세가지 존재한다(그리고 나는 그것들 중 하나를 여기에서 설명한다):
이들 MPI 구현물들중 어떤 것을 쓰던 간에 대부분의 공용 통신 타입들을 수행하는 것은 아주 단순하다.
그러나 MPI 2.0은, 이들 중에 하나를 사용하는 프로그래머가 MPI와 같은 다른 코딩 스타일들을 인식하지 못할 정도로 충분히 서로 다른 여러가지 통신 패러다임들을 서로 연동시킨다. 그래서 단 하나의 예제 프로그램을 제공하는 것보다 MPI가 지원하는 기본적으로 서로 다른 통신 패러다임들 각각의 예제를 가지는 것이 유용하다. 아래에 나오는 모든 세가지 프로그램들은 이 HOWTO를 통해서 사용되는 Pi의 값을 구하는, 동일한 기본 알고리즘을 구현한다.
각 프로세서가 그것의 부분합을 총합을 구하고 그 결과를 출력하는 프로세서 0번에게 전달하기 위해서 기본 MPI 메시지-전달 호출들을 사용하는 첫번째 MPI 프로그램:
#include <stdlib.h>
#include <stdio.h>
#include <mpi.h>
main(int argc, char **argv)
{
register double width;
double sum, lsum;
register int intervals, i;
int nproc, iproc;
MPI_Status status;
if (MPI_Init(&argc, &argv) != MPI_SUCCESS) exit(1);
MPI_Comm_size(MPI_COMM_WORLD, &nproc);
MPI_Comm_rank(MPI_COMM_WORLD, &iproc);
intervals = atoi(argv[1]);
width = 1.0 / intervals;
lsum = 0;
for (i=iproc; i<intervals; i+=nproc) {
register double x = (i + 0.5) * width;
lsum += 4.0 / (1.0 + x * x);
}
lsum *= width;
if (iproc != 0) {
MPI_Send(&lbuf, 1, MPI_DOUBLE, 0, 0, MPI_COMM_WORLD);
} else {
sum = lsum;
for (i=1; i<nproc; ++i) {
MPI_Recv(&lbuf, 1, MPI_DOUBLE, MPI_ANY_SOURCE,
MPI_ANY_TAG, MPI_COMM_WORLD, &status);
sum += lsum;
}
printf("Estimation of pi is %f\n", sum);
}
MPI_Finalize();
return(0);
}
두번째 MPI 버전은 집합적인(collective) 통신(이 특별한 어플리케이션의 경우 이것은 가장 적절하다):
#include <stdlib.h>
#include <stdio.h>
#include <mpi.h>
main(int argc, char **argv)
{
register double width;
double sum, lsum;
register int intervals, i;
int nproc, iproc;
if (MPI_Init(&argc, &argv) != MPI_SUCCESS) exit(1);
MPI_Comm_size(MPI_COMM_WORLD, &nproc);
MPI_Comm_rank(MPI_COMM_WORLD, &iproc);
intervals = atoi(argv[1]);
width = 1.0 / intervals;
lsum = 0;
for (i=iproc; i<intervals; i+=nproc) {
register double x = (i + 0.5) * width;
lsum += 4.0 / (1.0 + x * x);
}
lsum *= width;
MPI_Reduce(&lsum, &sum, 1, MPI_DOUBLE,
MPI_SUM, 0, MPI_COMM_WORLD);
if (iproc == 0) {
printf("Estimation of pi is %f\n", sum);
}
MPI_Finalize();
return(0);
}
세번째 MPI 버전은 각 프로세서가 자신의 로컬 lsum를 프로세서
0번의 sum로 더하기 위해서 MPI 2.0 RMA 메카니즘을 사용한다.
#include <stdlib.h>
#include <stdio.h>
#include <mpi.h>
main(int argc, char **argv)
{
register double width;
double sum = 0, lsum;
register int intervals, i;
int nproc, iproc;
MPI_Win sum_win;
if (MPI_Init(&argc, &argv) != MPI_SUCCESS) exit(1);
MPI_Comm_size(MPI_COMM_WORLD, &nproc);
MPI_Comm_rank(MPI_COMM_WORLD, &iproc);
MPI_Win_create(&sum, sizeof(sum), sizeof(sum),
0, MPI_COMM_WORLD, &sum_win);
MPI_Win_fence(0, sum_win);
intervals = atoi(argv[1]);
width = 1.0 / intervals;
lsum = 0;
for (i=iproc; i<intervals; i+=nproc) {
register double x = (i + 0.5) * width;
lsum += 4.0 / (1.0 + x * x);
}
lsum *= width;
MPI_Accumulate(&lsum, 1, MPI_DOUBLE, 0, 0,
1, MPI_DOUBLE, MPI_SUM, sum_win);
MPI_Win_fence(0, sum_win);
if (iproc == 0) {
printf("Estimation of pi is %f\n", sum);
}
MPI_Finalize();
return(0);
}
MPI 2.0 RMA 메카니즘은, 서로 다른 메모리 위치들에 거주하는 다양한
프로세서들위의 대응하는 데이터 구조의 임의의 잠재적 문제점들을 아주 잘
극복한다는 점을 주목하는 것이 좋을 것이다. 이것은, 베이스 주소를
의미하는 "창(window)"를 참조하는 것과 경계 초월 억세스(out-of-bound
access)에 대한 보호와 그리고 평등한 주소 크기 조절(even address
scaling)에 의해서 가능하다. RMA 처리는 다음
MPI_Win_fence 이전까지 연기될 수 있다는 사실에
의해서 도움을 받는다. 간단히 말해서 RMA 메카니즘은 분산 공유
메모리와 메시지 전달 간의 이상한 조합(strange cross)이라고 말할 수도
있겠지만 잠재적으로 아주 효율적인 통신을 생성하는 아주 깨끗한
인터페이스이다.
PVM, MPI 등과 다르게 AFAPI(집합 함수 어플리케이션 프로그램 인터페이스; Aggregate Function Application Program Interface)는 현존하는 네트웍 하드웨어와 소프트웨어 위에 놓인 포팅가능한 추상 인터페이스를 구축하는 시도로써 일생을 시작하지 않았다. 그러기 보다는 AFAPI는 PAPERS (병렬 실행과 빠른 동기화를 위한 퍼듀 아답터; Purdue's Adapter for Parallel Execution and Rapid Synchronization; http://garage.ecn.purdue.edu/~papers/ 참조)에 대한 하드웨어-종속적인 로우-레벨 지원 라이브러리로써 시작하였다.
PAPERS는 네트웍 하드웨어에서 약간 논의되었다; 이것은 지체시간이 약 수 마이크로 초동안인 공용 도메인 설계 커스텀 집합 함수 네트웍이다. 그러나 현존하는 슈퍼컴퓨터들보다 컴파일러 기술에서 더 나은 타겟이 될 수 있는 슈퍼컴퓨터를 만들려는 시도로써 이것이 개발되었다는 것이 PAPERS에 대해서 중요한 것이다. 이것은 질적으로 대부분의 리눅스 클러스터 노력들과, 상대적으로 별로 충분하지 않는 성긴 병렬 어플리케이션들에 대한 표준 네트웍을 사용하려고 노력하는 데 촛점을 맞춘 PVM/MPI들과 아주 다르다. 리눅스 피씨들이 PAPERS 시스템의 컴포넌트들로 사용된다는 사실은 단순하게 가능한한 가장 비용-효율적인 방식으로 프로토타입들을 구현해본 것이다는 것을 말할 뿐이다.
한 타스의 서로다른 프로토타입 구현물들에 대한 공용 로우-레벨 소프트웨어 인터페이스 필요가 AFAPI로 PAPERS 라이브러리가 표준화되도록 한 것이다. 그러나 AFAPI에 의해서 사용되는 모델은 타고날 적부터 더 단순하고, 전형적인 병렬처리 컴파일러에 의해서 컴파일된 코드나 SIMD 아키텍쳐들을 위해서 작성된 코드들의 더 정교한 상호작용에 좀 더 적당하다. 이 모델의 단순성은 PAPERS 하드웨어를 만들기 쉽게 할 뿐만 아니고 SMP들과 같은 다른 하드웨어 시스템들에 대한 놀랍도록 효율적인 AFAPI 포팅을 가능하게 한다.
AFAPI는 현재 TTL_PAPERS, CAPERS, 또는 WAPERS를 사용하여 커넥트된 리눅스 클러스터들에서 잘 작동한다. 이것은 또한 (OS 호출들이나 심지어 버스-락킹 명령어들 없이도, 섹션 공유 메모리 프로그래밍에 대한 소개 참조) SHMAPERS라고 불리는 시스템 V 공용 메모리 라이브러리(System V Shared Memory library)를 사용한 SMP 시스템들 위에서도 작동한다. 전통적인 네트웍(예, 이더넷) 위에서 UDP 브로드캐스트를 사용한 리눅스 클러스터 위에서 실행하는 버전이 개발 중에 있다. 모든 관련된 버전들이 http://garage.ecn.purdue.edu/~papers/에서 얻을 수 있을 것이다. AFAPI의 모든 버전들은 C나 C++로부터 호출되도록 설계되었다.
다음 예제는 섹션 예제 알고리즘에서 설명된 바 있는 Pi의 AFAPI버전이다.
#include <stdlib.h>
#include <stdio.h>
#include "afapi.h"
main(int argc, char **argv)
{
register double width, sum;
register int intervals, i;
if (p_init()) exit(1);
intervals = atoi(argv[1]);
width = 1.0 / intervals;
sum = 0;
for (i=IPROC; i<intervals; i+=NPROC) {
register double x = (i + 0.5) * width;
sum += 4.0 / (1.0 + x * x);
}
sum = p_reduceAdd64f(sum) * width;
if (IPROC == CPROC) {
printf("Estimation of pi is %f\n", sum);
}
p_exit();
return(0);
}
PVM, MPI, 그리고 AFAPI에 덧붙여 다음 라이브러리들은 리눅스 클러스터를 사용해서 병렬 컴퓨팅하는 데 유용할 기능들을 제공한다. 이런 시스템들은 이 문서에서 좀 더 가벼운 취급을 받았다. 왜냐면 PVM, MPI, 그리고 AFAPI와 다르게 나는 리눅스 클러스터에 이런 시스템들을 직접 사용할 기회가 전혀 또는 거의 없었기 때문이다.이런 것들이나 다른 라이브러리들 중 어떤 것이라도 특별히 유용하다고 생각되면 여러분이 찾은 것을 설명한 이메일을 pplinux@ecn.purdue.edu로 보내주기 바란다. 그러면 나는 그 라이브러리를 확장 섹션에 더하는 것을 고려하겠다.
Condor는 워크스테이션들의 커다란 이기종 클러스터를 관리할 수 있는 분산 자원 관리 시스템이다. 이것의 설계 동기는 클러스터의 활용되지 않는 역량을 오래-실행되고 계산이 많은 일들에 대해서 사용하고자 하는 사람들의 요구에 의해서이다. Condor는 시각 및 실행 기계들이 공통 파일 시스템을 공유하지 않고/거나 패스워드 메카니즘을 공유하지 않을지라도, 실행 기계에 커다란 시작 기계의 환경을 유지한다. 단일 프로세스를 유지하는 Condor 작업들은 이벤트 완료를 확인하는 데 필요하기 때문에 자동으로 checkpoint되고 워크스테이션들 사이에서 이주된다.
Condor는 http://www.cs.wisc.edu/condor/ 에서 찾을 수 있다. 리눅스 포팅된 버전이 존재한다; 더 자세한 내용은 http://www.cs.wisc.edu/condor/linux/linux.html을 찾아 볼 수 있다. 자세한 것은 condoradmin@cs.wisc.edu을 만나보라.
DFN-RPC(독일 연구 네트웍 RPC) 툴은 워크스테이션과 계산 서버나 클러스터 간에 과학-기술적인 어플리케이션 프로그램들을 분산하고 병렬화(parallelize)하기 위해서 개발되었다. 이 인터페이스는 포트란으로 작성된 어플리케이션에 최적화되어 잇지만 DFN-RPC는 또한 C 환경에서도 사용될 수 있다. 이것은 리눅스로 포팅되었다. 자세한 정보는 ftp://ftp.uni-stuttgart.de/pub/rus/dfn_rpc/README_dfnrpc.html에 있다.
정확하게 말해서 라이브러리는 아니지만 DQS 3.0 (분산 큐잉 시스템)은 리눅스에서 개발되고 테스트된 작업 큐잉 시스템이다. 이것은 이기종 클러스터를 하나의 엔터티로써 사용하고 관리할 수 있도록 설계되었다. 이것은 http://www.scri.fsu.edu/~pasko/dqs.html에서 얻을 수 있다.
CODINE 4.1.1(분산 네트웍 환경에서의 계산, COmputing in DIstributed Network Environments)라고 불리는 상업용 버전도 또한 존재한다. 이것의 정보는 http://www.genias.de/genias_welcome.html에서 찾을 수 있다.
클러스터들은 아주 많은 방식으로 구축되고 사용될 수 있기 때문에 흥미로운 공헌을 한 그룹들이 꽤 있다. 다음은 일반적인 관심거리가 될 수 있는 다양한 클러스터-관련 프로젝트들에 대한 레퍼런스이다. 이것은 리눅스에 한정된 것과 그렇지 않은 일반적인 클러스터 레퍼런스들을 담고 있다. 이 리스트는 알파벳 순서로 나와 있다.
Beowulf 프로젝트는, http://cesdis1.gsfc.nasa.gov/beowulf/, 상품 피씨-클래스 하드웨어, 고-대역폭 클러스터-인터널 네트웍, 그리고 리눅스 운영 체제를 기반으로 한 규격품 워크스테이션 클러스터를 사용하기 위한 소프트웨어 제작에 집중하고 있다.
Thomas Sterling가 Beowulf 뒤의 추진력이었으며 계속해서 일반적인 과학 컴퓨팅을 위한 리눅스 클러스터링의 웅변적이고 솔직한 제안자이었다. 사실, 많은 그룹들의 지금 그들의 클러스터를 "Beowulf class" 시스템들이라고 부른다 - 심지어 그 클러스터가 실제 공식적인 Beowulf 설계에 전혀 비슷하지 않더라도 말이다.
Beowulf 프로젝트를 지원하는 일을 하는 Don Becker는 리눅스에 의해서 일반적으로 사용되는 많은 네트웍 드라이버들을 만들었다. 이들 중 많은 것들이 BSD에서 사용되도록 적용되어 왔다. Don은 또한 비싼 스위치 허브없이 더 높은 대역폭을 획득하도록 다수의 병렬 커넥션들을 통해서 로드-분배를 허용하는 많은 리눅스 네트웍 드라이버들에 대해서도 책임을 지고 있다. 이런 로드-분배(load-sharing) 타입은 Beowulf 클러스터가 원조인 다른 것과 구별된는 기능이었다.
Linux/AP+ 프로젝트, http://cap.anu.edu.au/cap/projects/linux/는 정확하게 리눅스 클러스터링에 대한 것이 아니고 리눅스를 Fujitsu AP1000+으로 포팅하는 것과 적절한 병렬 처리 증진을 더하는 것에 촛점을 맞춘 것이다. AP1000+는 환형 토폴로지, 25 MB/s 대역폭, 그리고 10 마이크로 초 지체 시간 ... 을 가진 커스텀 네트웍을 사용하는 상용 SPARC-기반 병렬 기계이다. 단순하게 말해서 이것은 SPARC 리눅스 클러스토와 아주 유사하다.
로커스트(Locust) 프로젝트, http://www.ecsl.cs.sunysb.edu/~manish/locust/는 메시지-지체시간을 숨기기 위해서 그리고 실시간으로 네트웍 트래픽을 줄이기 위해서 컴파일-시간 정보를 사용하는 분산 가상 공유 메모리 시스템을 구축하고 있다. Pupa는 로커스트의 기반 통신 서브시스템이고 FreeBSD의 486 피씨들을 연결하기 위해서 이더넷을 사용하여 구현되었다. 리눅스인가?
Midway, http://www.cs.cmu.edu/afs/cs.cmu.edu/project/midway/WWW/HomePage.html는 TreadMarks와 다르지 않는, 소프트웨어-기반 DSM(분산 공유 메모리) 시스템이다. 이것은 상대적으로 느린 페이지-폴트 메카니즘들보다는 컴파일-시간 도움(aids)을 사용하고 공짜라는 것이 희소식이다. 나쁜 소식은 이것이 리눅스 클러스터들 위에서 작동하지 않는다는 것이다.
MOSIZ는 BSDI BSD/OS를 변조해서 피씨들을 네트웍으로 묶은 그룹 위에서 동적 로드 밸런싱과 선점(preemptive) 프로세스 이주를 제공하도록 한 것이다. 이것은 병렬 처리에 대해서뿐만이 아니고 조절 가능한(scalable) SMP와 아주 유사한 클러스터를 일반적으로 사용하는 데에도 좋은 것이다. 리눅스 버전이 있을까? 좀 더 자세한 정보는 http://www.cs.huji.ac.il/mosix/를 참조하자.
버클리 NOW (네트웍으로 묶은 워크스테이션들, Network Of Workstations) 프로젝트, http://now.cs.berkeley.edu/는 네트웍으로 묶은 워크스테이션들을 사용해서 병렬 컴퓨팅을 하도록 많은 압력을 행사해왔다. 현재 많은 작업들이, 모두 "다음 몇년 안에 실질적인 100개의 프로세서 시스템을 데모하는 것"을 향해서, 이루어지고 있다. 아뿔사, 이들은 리눅스를 사용하지 않는다.
리눅스를 사용한 병렬 처리 WWW 사이트, http://yara.ecn.purdue.edu/~pplinux/, 는 이 HOWTO의 홈 페이지이며 하루짜리 튜터리얼을 노린 온라인 슬라이들을 포함한 많은 관련된 문서들이 있는 곳이다. PAPERS 프로젝트에 대한 작업을 제외하고도 퍼듀 대학교 전자 및 컴퓨터 공학 학교는 일반적으로 병렬 처리의 리더로 군림해왔다; 이 사이트는 다른 사람들이 리눅스 피씨들을 병렬 처리에 적용하는 것을 돕기 위해서 설립되었다.
퍼듀의 첫번째 리눅스 피씨 클러스터가 1994년 2월에 조립된 이래로 비디오 벽(video wall)을 포함한, 수많은 리눅스 피씨 클러스터들이 퍼듀에서 조립되어왔다. 비록 이런 클러스터들이 386, 486, 그리고 Pentium 시스템들(Pentium Pro 시스템은 없다)을 사용했지만 요근래 인텔이 Pentium II 시스템들로 된 다수의 커다란 클러스터들을 만들 수 있도록 퍼듀 대학교에 기부를 했다. 이런 클러스터들이 모두 PAPERS 네트웍을 가지고 가질 것이지만 대부분의 것들이 또한 전통적인 네트웍을 가진다.
아이오와(Iowa) 주 데모인(Des Moines)에서 1997년 4월 10-11에 AMES 랩은 펜티엄 프로 클러스터 워크샵을 열었다. 이 워크샵의 WWW 사이트, http://www.scl.ameslab.gov/workshops/PPCworkshop.html, 는 모든 참가자들로부터 수집된 풍부한 피씨 클러스터 정보들을 갖고 있다.
DSM (분산 공유 메모리, Distributed Shared Memory)는 이것에 의해서 메시지-전달 시스템이 SMP처럼 행동하는 것같이 보일 수 있는, 기술이다. 몇가지 그런 시스템들이 존재하고 이들 중 대부분은 메시지 전송을 트리거(촉발)하기 위해서 OS 페이지-오류 메카니즘을 사용한다. TreadMarks, http://www.cs.rice.edu/~willy/TreadMarks/overview.html는 이런 시스템들 중 좀 더 효율적인 것이며 리눅스 클러스터 위에서 실행된다. 슬픈 소식은 "TreadMarks가 대학교들이나 비영리 기관들에 저비용으로 배포되고 있다는 것이다". 이 소프트웨어에 대한 좀 더 많은 정보를 원한다면 treadmarks@ece.rice.edu과 접촉해보기 바란다.
코넬 대학교의 U-Net (User-level NETwork interface architecture) 프로젝트, http://www2.cs.cornell.edu/U-Net/Default.html는 네트웍 인터페이스를 가상화해서(virtualize) 어플리케이션들이 메시지들을 운영체제의 간섭없이 전송하거나 수신할 수 있도록 하는, 상품 네트웍 하드웨어를 사용한 낮은 지체 시간과 높은 대역폭을 제공하는 시도를 하고 있다. U-Net은 Fast 이더넷에 기반한 DECchip DC21140 를 사용하거나 Fore Systems PCA-200(PCA-200E가 아님) ATM 카를 사용하는 리눅스 피씨들 위에서 작동한다.
위스콘신에는 상당히 많은 클러스터-관련 작업들이 이루어지고 있다. WWT (Wisconsin Wind Tunnel) 프로젝트, http://www.cs.wisc.edu/~wwt/는 컴파일러들과 기반 패러럴 하드웨어 사이의 "표준" 인터페이스를 개발하는 쪽의 모든 종류의 일들을 수행하고 있다. Wisconsin COW (Cluster Of Workstations), Cooperative Shared Memory and Tempest, Paradyn Parallel Performance Tools 등이 있다. 불행하게도 리눅스에 관한 일들은 별로 없다.