2009.02.02 10:06

리눅스를 이용한 클러스터링 구축법

Cluster Overview

[ 목 차 ] 

1. 클러스터

2. 클러스터의 필요성

3. 클러스터의 종류

   3-1. 고계산용 클러스터 (HPC)

   3-2. 부하분산 클러스터 (LVS)

   3-3. 고가용성 클러스터 (HA)

   3-4. 그외의 클러스터 분류

4. 클러스터의 단점

 

1. 클러스터

 컴퓨팅 파워를 증가시키기 위한 다양한 방법이 있다. 그중 고성능 단일 컴퓨터를 이용한 계산은 이미 그 한계가 있음이 증명된 상태이며 이의 대안으로 다수의 프로세서(CPU)가 하나의 문제를 협동적으로 계산하는 병렬컴퓨팅이 등장하게 되었다. 다수의 프로세서가 하나의 메모리를 공유하는 SMP(symmetric multiprocessing) 머신, 다수의 프로세서가 각각 독립된 메모리를 가지고 있는 MPP(massively parallel processing) 머신, 다수의 프로세서의 지역 메모리를 계층적으로 공유하는 NUMA(non-uniform memory access) 등이 여기에 속한다. 그러나 기존 몇몇 벤더에 의해 제공되던 병렬컴퓨터 혹은 슈퍼컴퓨터들은 매우 고가이기 때문에 쉽게 접할수가 없었다.

한편 최근 마이크로프로세서들은 뛰어난 성능을 보여주고 있으며 고속네트워크 또한 널리 보급되었다. 이로 인해 단일 컴퓨터들을 네트워크로 연결함으로써 새로운 개념의 병렬컴퓨터를 만드는 것이 가능하게 되었다. 또한 리눅스라는 공개된 OS는 강력한 네트워크 성능을 제공하며 소스공개로 인한 자유로운 튜닝이 가능하기 때문에 이들을 위한 OS로 널리 사용되고 있다.
이러한 개념의 병렬컴퓨터를 통칭하여 '클러스터'라고 부른다.

2. 클러스터의 필요성

 많은 수치모델들은 좀 더 고품질의 결과를 얻기 위해서 또는 빠른 결과를 얻기 위해서 대규모 계산을 수행해야 하거나 대규모 데이타를 처리해야 한다. 이를 위해 주로 워크스테이션이 활용되고 있으나 단일 워크스테이션으로는 충분한 성능을 제공받지 못하거나 잠재적으로 성능 부족을 느끼게 된다. 병렬 컴퓨터는 이의 해결방안으로 좋은 선택이 될수 있으며 특히 클러스터는 아래와 같은 주목할만한 장점을 갖는다.

 첫째는 워크스테이션에 비해 월등한 컴퓨팅 파워를 제공할수 있으며 대규모 데이타 처리가 가능하다. 둘째는 범용하드웨어를 사용함으로 인해 상용 병렬컴퓨터에 비해 가격대 성능비가 매우 뛰어나다. 세째는 노드의 증설에 따라 성능향상이 자유로우며 퇴출된 컴퓨터들을 이용하여 고성능 병렬컴퓨터를 제작할수 있다. 네째는 자체 제작이 가능하다. 따라서 문제발생시 자체 해결이 용이하다.


3. 클러스터의 종류

 클러스터의 분류를 정의하는 것은 매우 다양하다. 일반적으로 많이 사용되는 분류법은 클러스터의 그 활용 목적에 따라 분류하는 것이며 이에 따르면 아래의 3가지로 나눌 수 있다.

  • 고계산용 클러스터 (HPC)
  • 부하분산 클러스터 (LVS)
  • 고가용성 클러스터 (HA)

3-1. 고계산용 클러스터 (HPC)

 HPC 클러스터는 고성능의 계산능력을 제공하기 위한 목적으로 제작된다. 주로 과학계산용으로 활용가치가 높으며 삼성종합기술원에서 개발한 Alpha-11 역시 HPC클러스터이다.

 HPC 클러스터를 구성하는 모든 컴퓨터들은 네트워크에 연결되어 있어서 상호간에 통신이 가능하므로 다수의 프로세서가 협동적으로 문제를 풀 수 있는 환경을 제공하게 된다. 그러나 이 기반을 이용하여 문제를 병렬로 푸는 것은 전적으로 프로그램 수준에서 이루어 진다. 따라서 클러스터 구축뿐만 아니라 프로그램 병렬화가 같이 고려되어야 한다.

3-2. 부하분산 클러스터 (LVS)

 대규모 서비스를 제공하기 위한 목적으로 제작되며 주로 웹서비스등에 활용가치가 높다.

 이러한 방식은 인터넷 사용자로 하여금 하나의 컴퓨터 즉 로드밸런서로부터 서비스를 제공받는 것으로 여겨지게 한다. 그러나 실제 서비스 제공은 로드밸런서에 연결되어 있는 서비스 노드들에 의해서 이루어진다. LVS 클러스터 역시 일반적으로 모든 컴퓨터간에 연결되어져서 구성된다. 그러나 이것은 필수적인 조건은 아니다.
만약 정적인 데이타만을 서비스하는 웹클러스터라면 각 서버들은 Load Balancer 와의 통신만 가능해도 된다. 또는 그 중간적인 형태역시 가능하다. 즉 클러스터의 위상(topology)에 있어서는 다양한 형태로의 변형이 가능하다.

 LVS 클러스터의 웹요청 처리과정을 살펴보면 다음과 같다.

  1. 로드밸런서에게 인터넷으로부터 웹요청이 들어온다.
  2. 로드밸런서는 정해진 알고리즘에 따라 서비스를 수행할 server를 선택하고 웹요청을 forwarding 한다.
  3. forwarding된 웹요청은 선택된 server에 전달된다.
  4. 웹요청을 받은 서버는 이에 대한 응답을 로드밸런서에게 제공한다.
  5. 로드밸런서는 제공받은 데이타를 웹요청을 한 컴퓨터로 재 전송해준다.

 부하분산용 클러스터중에서도 이러한 방식을 NAT(Network Address Transaction)라고한다.

 이 방식의 장점은 server가 어떤 OS이든지 상관이 없다는 것이다.

 그리고 IP Tunneling 방식은 웹요청이 들어오면 요청패킷을 캡슐화해서 클러스터내의 노드들에게 전송해준다. 이것은 응답이 로드밸런서를 거쳐서 나가지 않으므로 하나의 로드밸런서가 매우 많은 server들을 거느릴수가 있다. 그러나 클러스터내의 server들이 캡슐화된 패킷을 해석할수 있어야 하므로 현재는 리눅스에서만 가능하다.

 마지막으로 DR(Direct Routing)방식은 클러스터의 확장성을 높이기 위해 IP NAT 방식과 IP Tunneling방식의 장점만을 가져온 방식이다. 즉 서비스요청이 들어오면 패킷을 최소한으로 빨리 가공하여 리얼서버에게 보내면 리얼서버는 다른 루트를 통하여 응답을 보내는 것이다.
라우터가 요청패킷에 MAC 어드레스를 추가하여 유일한 리얼서버를 결정할수 있게 해준다.

 이것을 위해서는 모든 노드들이 단일 segment에 존재해야한다.

 부하분산 클러스터에 더 많은 관심이 있다면 http://linuxvirtualserver.org/ 를 참고하라.


3-3. 고가용성 클러스터 (HA)

 지속적인 서비스 제공을 목적으로 제작되며 주로 미션 크리티컬한 업무에 사용된다.
위에서 설명한 LVS클러스터를 고려해 보자. 만약 로드밸런서가 고장났다면 클러스터 전체는 무용지물이 될 것이다. 또한 서버들중 server2가 고장났다고 가정해보자. 일부 사용자는 원하는 데이타를 제공받지 못할 것이다. 이러한 문제를 극복하기 위한 목적으로 구성하는 것을 고가용성 클러스터라고 한다.
로드밸런서의 고장에 대처하기 위해 현재 사용되는 방법은 heart beat 와 fake 를 이용하는 방법이다. heart beat는 로드밸런서와 하나의 백업서버간에 주기적으로 통신을 하며 이상유무를 체크하게 된다. 로드밸런서의 고장이 인식되면 fake 라는 프로그램은 로드밸런서가 점유하고 있는 IP를 백업서버로 이주시켜서 계속 서비스를 수행시켜준다. 한편 server2의 고장은 로드밸런서에 의해서 주기적으로 감시되고 고장발생시 웹요청을 server2로 포워딩 하지 않음으로써 서비스가 지속적으로 수행하게 된다.

 고가용성 클러스터에 대해서 더 많은 관심이 있다면 http://www.linux-ha.org/ 를 참고하라.


3-4. 그외의 클러스터 분류

3-4-1. 노드의 소유권에 따라서 (Node Ownership)

  • Dedicated Clusters
  • Nondedicated Clusters

3-4-2. 노드의 하드웨어에 따라서 (Node Hardware) ? PC, Workstation, 또는 SMP 등등

  • Clusters of PCs (CoPs) or Piles of PCs (PoPs)
  • Cluster of Workstations (COWs)
  • Clusters of SMPs (CLUMPs)

3-4-3. 노드의 운영시스템에 따라서 (Node Operating System) ? Linux, NT, Solaris, AIX 등

  • Linux Cluster (예: Beowulf)
  • Solaris Clusters (예: Berkeley NOW)
  • NT Clusters (예: HPVM)
  • AIX Cluster (예: IBM SP2)
  • Digital VMS Clusters
  • HP-UX Clusters
  • Microsoft Wolfpack Clusters

3-4-4. 노드의 구성에 따라서 (Node Configuration)

  • Homogeneous Clusters
    - 모든 노드가 비슷한 구조와 같은 OS를 이용하는 경우
  • Heterogeneous Clusters
    - 모든 노드가 서로 다른 구조로 이루어져 있고 또한 다른 OS를 이용하는 경우

3-4-5. 노드의 위치와 숫자에 따른 구분 (Level of Clustering )

  • Group Clusters (노드 수: 2-99)
    - 노드들끼리 Myrinet과 같은 SANs(System Area Networks)로 연결되어 있다.
  • Departmental Clusters (노드 수: 10-100)
  • Organization Clusters (노드 수: 수백 개)
  • National Metacomputers (WAN/Internet-based)
    - 많은 Departmental/Organizational systems 또는 Clusters
  • International Metacomputers (Internet-based)
    - 천 개부터 수백만 노드들의 Cluster

 

4. 클러스터의 단점

 클러스터의 문제점은 관리의 어려움과 프로그램의 어려움을 들수 있다. 이러한 문제점은 다수의 컴퓨터로 구성되어 있다는 것에 기인한다. 즉 다수의 컴퓨터를 관리하고 일반적인 문제들(S/W, H/W)을 해결하는데 상대적으로 많은 노력이 필요하다는 것이다.
다행히 관리의 어려움을 해결하기 위한 많은 툴들이 공개되어 있으며 이러한 툴들을 이용하여 상당 부분 관리에 필요한 노력을 줄일 수 있다. Reference를 참고하자.

 한편 기존 워크스테이션에서 수행되는 프로그램들은 단일 컴퓨터에서 수행되도록 프로그램되어 있다. 이를 시리얼 프로그램이라 한다.
그러나 클러스터를 비롯한 병렬 컴퓨터에서는 병렬 프로그램을 사용하여야만 한다. 인터넷을 통하여 병렬화된 프로그램을 구할 수도 있지만 공개된 병렬프로그램이 없다면 직접 프로그램을 병렬화하여야 한다. 이것은 경우에 따라 매우 많은 노력을 필요로 한다.



Building Cluster

[ 목  차 ]

1. 고려사항

2. 클러스터 구축하기

    2-1. 사설네트워크 구축

    2-2. 관리노드 세팅

    2-3. 컴퓨팅노드 세팅

    2-4. 클러스터 확장

3. 보안

4. 클러스터 관리툴

5. 벤치마킹

 

1. 고려사항

 클러스터 구축을 위해서는 어떠한 하드웨어를 사용하여 어떠한 규모의 클러스터를 구축할 것인지 H/W적인 선택을 하여야 한다. 그리고 어떠한 소프트웨어들을 설치할 것인지 몇가지 선택을 하여야 한다. 다음은 이러한 고려에 대한 작은 조언이다.

1-1. H/W의 고려사항

 클러스터 제작에 사용할 하드웨어를 선택하는 것은 중요하다. 특히 특정한 프로그램을 돌리기 위한 전용 클러스터를 구축하고자 한다면 더욱 중요하다. 다음은 일반적 몇가지 선택에 대한 조언이다.

1-1-1. 프로세서 (CPU)

 클러스터를 구축하여 원하는 컴퓨팅 파워를 얻기위한 두가지 고려사항이 있다. 저성능의 컴퓨터를 다수 연결할 것인가 고성능의 컴퓨터를 소수 연결할 것인가를 고려해야 한다. 일반적으로 노드의 수가 증가할수록 프로세서간의 통신이 증가하므로 네트워크 비용이 증가하게 되고 동기화에 필요한 시간이 증가하므로 병렬화 효율 역시 줄어들게 된다. 따라서 고성능 컴퓨터를 소수 연결하는 것이 효율면에서는 좋다. 그러나 고성능 컴퓨터의 가격은 그 성능에 비해 비싸기 때문에 타협을 하여야 한다.

 ALPHA 프로세서는 floating 계산 능력에 있어서 가장 앞선다. 동일클락의 intel 머신에 비해 약 2.5배 정도 빠르며 대부분의 수치모델들이 floating 연산이 주를 이루는 것을 감안하면 수치모델을 위한 클러스터 구축에 적합하다. 또한 64bit 아키텍쳐이므로 그에 따른 몇가지 장점이 있으며 그중 하나로 리눅스에서의 최대 파일사이즈 2G의 제한이 없다. 비록 리눅스 커널 2.4버전에서는 intel역시 2G제한이 없어졌으나 32bit 기반이므로 2개의 레지스트리가 주소참조시 사용되므로 여전히 알파가 빠른 주소결정을 할수있다. 그러나 가격이 비싸다는 단점이 있다.

 INTEL의 Pentium 시리즈로 대변되는 인텔 프로세서들은 저가에 클러스터를 구성할 수 있으며 다양한 H/W와 S/W의 지원을 받을 수 있는 장점이 있다.

 AMD 프로세서 역시 저가에 구성할 수 있으며 각종 벤치마킹에 의하면 Intel 프로세서에 비해 우수하다. 그러나 지원되는 하드웨어가 부족한것이 단점이며 듀얼(dual)보드가 아직 지원되지 않는 것 역시 단점이다. 참고로 듀얼보드를 사용할 경우 동일 보드상의 프로세서간의 통신이 빠르고 가격/프로세서 비용을 낮출 수 있다는 장점이 있다. 

1-1-2. 네트워크 장치 (랜카드, 허브)

 가장 일반적인 경우 100Mbps 스위칭 허브와 랜카드를 사용하여 구성된다. 100Mbps 네트워크 장치를 사용하여 제작한 클러스터는 많은 사용자들에 의해 충분히 사용할 만한 장비라는것이 입증되었다. 만약 더 좋은 네트워크 장치를 사용하기를 원한다면 미리넷과 기가비트이더넷을 고려할수 있으나 이들 장비는 매우 고가이다. 특히 미리넷은 전용 프로토콜을 사용할 경우 패킷전송시 지연시간(latency)이 매우 작은 클러스터 전용 네트워크 장치이지만 TCP가 지원되지 않는 문제점은 있다.

 최근 TCP를 에뮬레이션할 수 있는 방법이 나와 있으나 아직 안정화 되어 있지 않으며 성능에도 문제가 있다.

1-1-3. 기타 주변장치

 메모리에 있어서는 1 bit 에러 보정능력이 있는 ECC램과 일반램이 고려될 수 있다. 좀더 신뢰성 있는 시스템을 구축하기 위해서는 ECC램을 사용하는것이 좋으나 가격은 좀더 비싸다.

 보드의 선택에 있어서는 성능보다는 안정성에 중점을 두어서 선택해야 하는 것이 바람직하다. 클러스터는 다수의 컴퓨터로 구성되므로 하드웨어가 문제를 일으킬 확률이 그만큼 증가하게 되기 때문이다. Storage(저장장치)의 경우 일반적으로 IDE방식과 SCSI방식의 HDD가 고려될 수 있다. 이는 전적으로 어떤 프로그램을 수행할 것인지에 따라 결정될 수 있다. I/O가 빈번이 발생하는 프로그램을 수행한다거나 동시에 다수의 프로세스에 의해서 I/O가 이루어진다면 SCSI을 고려해야 할것이다. 그리고 더 나은 안정성과 속도를 원하다면 고가의 RAID역시 고려될 수 있다. 한편 다수의 하드 디스크를 이용하여 소프트웨어적으로 RAID를 구성하는 방법도 있다.  

1-2. S/W의 고려사항

 클러스터를 위한 소프트웨어를 크게 3가지로 나눈다면 클러스터에 사용될 OS, 클러스터를 구축하는데 필요한 MiddleWare, 마지막으로 클러스터를 구성한후 사용할 프로그램으로 나눌 수 있다.

 다음은 이들에 대한 간단한 조언이다.

1-2-1. OS에 대한 고려사항

 가장 널리 사용되는 OS로는 역시 리눅스를 들 수 있다. 현재 리눅스를 이용하여 클러스터를 구축하기 위한 많은 기술문서와 라이브러리, 모니터링 툴, 큐잉시스템 등이 공개되어 있으며 심지어는 클러스터링을 위한 커널이미지, 배포판 등도 나와 있다.
한편 리눅스뿐만 아니라 UNIX, NT등에서도 클러스터를 구축할 수 있다. 

1-2-2. MiddleWare에 대한 고려사항

 여기서 말하는 미들웨어란 병렬라이브러리, 모니터링 툴, 큐잉시스템등 클러스터 관련 소프트웨어를 지칭한다. 먼저 병렬라이브러리는 무수히 많이 있으며 이들중 원하는 라이브러리를 하나 또는 여러개 선택해서 설치할 수 있다. 모니터링 툴과 큐잉시스템 역시 다수가 공개되어 있으며 상용 툴들도 나와 있다. 이들에 대한 자세한 정보는 Reference Sites에 나와있는 각 소프트웨어의 홈페이지를 참고하기 바란다.

1-2-3. 프로그램 병렬화에 대한 고려

 기존 워크스테이션에서 돌고 있는 시리얼 프로그램을 클러스터에서 돌린다고 성능향상이 되는 것은 아니다. 클러스터를 비롯한 병렬컴퓨터는 병렬화된 코드를 요구한다. 즉 시리얼 프로그램을 병렬화 한후 이를 클러스터에서 수행해야 한다. 만약 인터넷을 통해 병렬화된 코드를 구할수 있다면 가장 바람직한 경우이다. 그렇치 않다면 모델 병렬화를 고려해야 한다. 병렬화 작업은 많은 노력이 필요할 수도 있다. C, C++, fortran 으로 작성된 프로그램이 병렬화가 가능하며 현재 ETRI(링크)에서 병렬화 작업에 필요한 교육을 주기적으로 진행하고 있으며 Alpha-11팀에서도 교육을 위한 문서를 제공하고 있다.

 일부 프로그램의 경우 병렬화된 프로그램이 공개된것이 있으며 그에 대한 정보를 얻으려면 S/W pool을 참조하자. Alpha-11팀에서는 S/W pool을 통하여 병렬 프로그램 및 기타 유용한 프로그램들을 수집하고 이를 공유하고자 한다. 당신이 제공하는 정보는 많은 사람들로부터 환영받을것이다.

 

2. 클러스터 구축하기

 본문서에서 제공하는 클러스터 제작 기법은 고성능 계산을 제공하기 위한 HPC 클러스터를 구축하기 위한 것이다. 그러나 대규모 클러스터(32노드 이상)에서는 본 문서에서 제공하는 기술이 그대로 적용가능하지 않을 수도 있다. 이것은 공개된 소프트웨어 특히 NFS에 의한 문제이며 대규모 클러스터를 구축하기 위해서는 많은 관련 연구가 필요하다. 따라서 본 문서에서는 이에 대해 다루지는 않을 것이다.

 리눅스는 Redhat 6.2를 사용하기로 한다. Redhat 6.*배포판과는 여러 설정파일의 변화는 거의 없으므로 이후 설명들이 그대로 적용가능하다. 그러나 Redhat 7.*에서는 몇몇 설정파일명과 구조가 바뀌었으므로 이후 설명이 그대로 적용가능하지는 않다.

 4대의 컴퓨터를 클러스터링 할 것이며 이후 필요한 장비는 다음과 같다.
컴퓨터 4대, 각 컴퓨터는 CPU, RAM, BOARD, HDD, VGA, Lan Card등의 기본적인 장치를 갖고 있다.
추가로 Lan Card 1개, 스위치허브 1개, 모니터 1개, 마우스 1개, 키보드 1개, IP(이후 111.111.111.111 이라고 가정) 한 개가 필요하다.

 클러스터 구축 방법은 컴퓨팅 노드의 하드디스크 유무에 따라 아래와 같이 두가지로 구분될 수 있다. 첫째 모든 컴퓨터가 물리적인 하드디스크를 갖고 있다. 그러나 /home을 위한 물리적 공간을 가지고 있지 않다. 단지 하나의 리눅스박스에만 /home을 위한 물리적 공간을 준다. 나머지 컴퓨터에서는 이 디렉토리를 네트워크를 통하여 공유하여 사용하는 것이다. 이 방식이 확장성과 편리성에 있어서 좋다.

 둘째 하나의 리눅스 박스에만 하드디스크가 있고 나머지 리눅스박스들은 하드디스크를 가지고 있지 않는 방식이다. 따라서 디스크가 없는 컴퓨터들은 부팅 디스켓 또는 부트롬을 사용해서 최소한의 부팅을 한후 NFS ROOT를 사용하여 다른 컴퓨터의 하드디스크 일부를 자신의 하드디스크처럼 사용한다. 이 방식은 하드디스크를 위한 비용을 절약할수 있으며, 이후에 노드(클러스터를 이루고 있는 컴퓨터 하나 하나를 노드라고 부름)를 추가하기 매우 쉬운 장점이 있다. 그러나 역시 확장성과 편리성에는 제약이 따르게 된다.

 이 문서에서는 첫 번째 방식으로 구현할 것이다.

 한편 준비된 4대의 컴퓨터중 어떤 컴퓨터를 관리 노드로 사용할것인지를 결정해야 한다. 클러스터는 하나의 시스템이다. 클러스터가 비록 여러대의 컴퓨터로 구성되어 있다고 할지라도 전체적인 관리는 한곳에서 이루어져야 한다. 우리는 이렇게 관리 작업을 할 컴퓨터를 관리 노드라고 부르자. 클러스터가 구축된후에 사용자들은 모두 관리 노드로 접속하여 작업을 수행하게 될 것이며 관리자 역시 관리 노드에서 클러스터의 관리를 수행하게 될것이다. 따라서 이왕이면 다른 컴퓨터 보다 성능이 좋은 컴퓨터를 관리노드로 사용하는 것이 좋겠다. 최소한 동일한 성능의 컴퓨터를 관리 노드로 사용하면 된다. 나머지 컴퓨터들을 컴퓨팅 노드라고 부르자. 

2-1. 사설 네트워크 구축

 구축하게 될 클러스터는 4대의 컴퓨터가 하나의 독립된 네트워크를 형성하게 될 것이다. 따라서 물리적으로 아래와 같이 연결하여야 한다.
관리노드와 컴퓨팅노드 2, 3, 4, ...., n 가 클러스터링 된 모습이다.

 사설 네트워크를 구축하는 이유는 아래의 몇가지를 들 수 있다.

 첫째, 모든 사용자가 관리노드로 접속하여 작업을 하도록 유도함으로써 관리가 편리한 장점이있다.

 둘째, 모든 노드에 대한 보안설정이 필요없고, 관리노드에 대한 보안설정만으로 전체 노드들을 지켜낼 수 있다.

 셋째, 컴퓨팅 노드들은 외부 패킷의 영향을 받지 않을 수 있다.

 넷째, 불필요한 공인 IP의 낭비를 막을 수 있다.  

 2-2. 관리노드 세팅

2-2-1. 리눅스 설치하기

여분의 준비된 Lan Card를 장착한다.
리눅스를 설치한다.
알파리눅스의 설치는 인텔 계열에 비해서 어렵다. 문제가 있다면 여기를 참고한다.
리눅스에 익숙하지 않다면 전부설치를 권장한다.

2-2-2. 네트워크 설정하기

두 개의 랜카드에 다음과 같은 주소를 부여한다. eth1에 부여되는 주소에 대해서는 그대로 따라하면 된다. 내부네트워크에서 사용될 주소이므로 어떠한 값이 사용되어도 상관없다.

eth0 : IP(111.111.111.111)
eht1 : IP(192.168.1.1)
hostname : master.cluster.net
hostname : node1.cluster.net

[root@master /etc]# /sbin/ifconfig 명령을 사용하여 제대로 설치됬는지를 확인해 볼수 있다.

[root@master /etc]# /sbin/ifconfig

eth0


eth1


lo


Link encap:Ethernet  HWaddr 00:60:08:F6:AB:24
inet addr:111.111.111.111  Bcast:75.1.50.255  Mask:255.255.255.0
. . . . . . . . .
Link encap:Ethernet  HWaddr 00:60:08:F6:AB:25
inet addr:192.168.1.1  Bcast:10.0.1.255  Mask:255.255.255.0
. . . . . . . . .
Link encap:Local Loopback
inet addr:127.0.0.1  Mask:255.0.0.0
. . . . . . . . .

한편 라우팅은 아래와 같이 설정해 주어야 한다. xwindow 환경에서 netcfg 명령을 사용하여쉽게 설정할 수 있다.

[root@master /etc]# /sbin/route
Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use lface
192.168.1.1
192.168.1.0
111.111.111.111
111.111.111.0
127.0.0.0
default
*
*
*
*
*
your.gateway
255.255.255.255
255.255.255.0
255.255.255.255
255.255.255.0
255.0.0.0
0.0.0.0
UH
U
UH
U
U
UG
0
0
0
0
0
0
0
0
0
0
0
0
0 eth1
0 eth1
0 eth0
0 eth0
0 lo
0 eth0

2-2-3. hosts 파일 편집한다.

클러스터를 이루고 있는 각노드의 주소와 이름을 정의해 준다. 이것은 관리노드와 모든 컴퓨팅노드에서 동일하게 설정해 준다.

[root@master /]# vi /etc/hosts

210.123.54.230
192.168.1.1
192.168.1.2
192.168.1.3
192.168.1.4
master.cluster.net
node1.cluster.net
node2.cluster.net
node3.cluster.net
node4.cluster.net
master
node1
node2
node3
node4

2-2-4. /home을 공유한다.

다음과 같이 exports 파일을 편집하자.

[root@master /etc]# cat /etc/exports
/home   node2 (rw,no_all_squash,no_root_squash)
/home   node3 (rw,no_all_squash,no_root_squash)
/home   node3 (rw,no_all_squash,no_root_squash)

그리고 다음의 명령을 사용하여 nfs를 다시 시작해주자.

[root@master /etc]# /etc/rc.d/init.d/nfs restart

마스터 노드에 nfs 데몬이 제대로 떠있는지 확인해보자. 아래와 비슷하게 나와야 한다..

[scshin@master scshin]$ ps -auex |  grep nfs
root     549   0.0   0.0   0   0 ?       SW   Jan05   0:34 [nfsd]
root     550   0.0   0.0   0   0 ?       SW   Jan05   0:34 [nfsd]
. . . . .

nfs 데몬이 떠 있지 않다면 nfs는 RPC(Remote Procedure Call)를 사용하기 때문에 포트매퍼(Port mapper)라는 데몬이 먼저 떠 있어야 한다. 이를 확인해 보자.

[root@master /etc]# rpcinfo -p
  프로그램 버전 원형   포트
  100000   2   tcp    111   portmapper
  100000   2   udp   111   portmapper
  . . . . . .

이 데몬이 떠 있지 않다면 다음과 같은 명령을 사용하여 portmapper를 먼저 띠우고 nfs를 재시작 해보자.

[root@master /etc]# /etc/rc.d/init.d/portmap start

위 두가지 모두 정상적으로 작동한다면 nfs가 제대로 동작할 것이다. 그러나 그렇치 않다면 nfs가 커널에서 지원되지 않는 경우일수 있다. 이를 위해서는 커널 컴파일을 해주어야 한다. 커널 컴파일시 nfs 관련 옵션들을 모두 커널에 포함시켜 주어야 한다. 이것은 커널 컴파일에 익숙한 사용자라면 별 어려움이 없겠지만 그렇치 않은 사용자라면 http://kldp.org/ 에 가서 "kernel compile" 이라는 검색어로 검색하면 많은 문서를 찾을수 있을 것이다. 이를 참고하여 커널 컴파일을 해야 한다.

kernel 2.2.13 버전에서는 아래와 같은 옵션들이 포함되어야 한다.

Code maturity level options  --->
       [*] Prompt for development and/or incomplete code/drivers
Filesystems  --->
       Network File Systems  --->
             <*> NFS filesystem support
                     <*> NFS server support (NEW)
                     <*> Emulate sun server

커널 컴파일을 마쳤으면 커널과 모듈들을 적재하고 재부팅한후 nfs를 다시 시작해보자.

2-2-5. rsh을 허가한다.

클러스터내의 모든 노드들간에 rsh 이 가능하도록 세팅해야 한다. 이것은 MPI가 정상작동하기 위해 필요하다. 다음의 순서대로 따라해보자. 역시 관리노드와 모든 컴퓨팅 노드에 동일하게 설정해 주어야 한다.

[root@master /root]# whoami
root
[root@master /root]# cd /etc
[root@master /etc]# vi inetd.conf
. . . . .
# Shell, login, exec, comsat and talk are BSD protocols.
shell     stream   tcp     nowait   root    /usr/sbin/tcpd   in.rshd
login     stream   tcp     nowait   root    /usr/sbin/tcpd   in.rlogind
#exec   stream   tcp     nowait   root    /usr/sbin/tcpd   in.rexecd
. . . . .

/etc/inetd.conf 파일을 열고 약 40번째 줄을 보면 위와 비슷한 내용이 보일 것이다. 여기서 shell 과 login 이 아마 주석처리되어 있을 것이다 다. 주석을 제거해 주자. 다음과 같은 명령을 사용하여 inetd를 다시 시작해주자. 참고로 rsh는 보안상 위험하기 때문에 독자들은 rsh을 풀어주는 대신 정확한 설정을 통하여 위험을 줄여야 한다. 이에 대한 내용은 뒤에서 다루기로 하겠다.

[root@master /etc]# /etc/rc.d/init.d/inet restart

그리고 어떤 컴퓨터들이 자신에게 rsh이 가능하도록 허가할지를 정의해 주어야 한다. 다음의 명령들을 따라해 보자.

[root@master /etc]# vi /etc/hosts.equiv
node1
node2
node3
node4

hosts.equiv 파일이 없으면 이를 만들고 위와 같이 2개의 호스트 이름을 적어주자. 이제 이 두 개의 호스트간에는 일반 사용자에 한해서 rsh 명령이 가능해 질 것이다. 이제 rsh 이 제대로 동작하는지 확인해보자. root 가 아닌 일반 유저로 테스트 해야 한다.

관리노드에서 컴퓨팅 노드로 rsh이 되는지 확인해보자.

[scshin@master scshin]$ rsh node2
Last login: . . . . . .
[scshin@node2 scshin]$

슬레이브 노드에서 마스터 노드로 rsh이 되는지 확인해보자.

[scshin@node2 scshin]$ rsh node1
Last login: . . . . . .
[scshin@master scshin]$

2-2-6. 병렬라이브러리를 설치한다.

MPI 라이브러리에는 몇가지 종류가 있다. 그중 유명한 것이 LamMPI 와 MPICH 이다. 이 글에서는 LamMPI를 설치해보겠다.
http://www.mpi.nd.edu/lam/download/ 에서 lam 최신버전을 받아오자. 이 글을 쓰는 시점에서는 6.3.2가 최신버전이다. 참고로 새로운 버전이 나올때 설치방법이 변경될수 있으므로 다운받은 파일에 있는 설치문서를 참고하기 바란다.

[root@master /tmp]# wget http://www.mpi.nd.edu/downloads/lam/lam-6.3.2.tar.gz
--14:15:57--   http://www.mpi.nd.edu:80/downloads/lam/lam-6.3.2.tar.gz
         => `lam-6.3.2.tar.gz'
Connecting to www.mpi.nd.edu:80... connected!
HTTP request sent, awaiting response... 200 OK
Length: 1,411,693 [application/x-tar]
   0K -> .......... .......... .......... .......... .......... [   3%]
                . . . . . . . . . . .
  1350K -> .......... .......... ........               [100%]
14:28:11 (1.89 KB/s) - `lam-6.3.2.tar.gz' saved [1411693/1411693]

[root@master /tmp]# ./configure --prefix=/usr/local/lam
. . . . . . .
[root@master /tmp]# make
. . . . . . .

이제 lamMPI 설치가 끝났다. 그러나 실행을 위해서 몇가지 설정이 남아 있다. 사용자가 LamMPI를 사용하기 위해서는 먼저 LAMHOME 이라는 환경변수가 선언되야 한다. 이를 위해서 다음과 같이 하자.

[root@master /tmp]# vi /etc/bashrc
. . . . . . .
export LAMHOME=/usr/local/lam
export PATH=$PATH:$LAMHOME/bin

/etc/bashrc 파일을 열고 마지막에 위의 두줄을 넣어주자. 이렇게 함으로써 모든 사용자가 로그인 할 때 LAMHOME 과 PATH가 적당하게 설정될 것이다.

 

2-3. 컴퓨팅노드 셋팅

2-3-1. 리눅스 설치하기

관리노드와 마찬가지로 리눅스를 설치한다.

2-3-2. 네트워크 설정하기

하나의 랜카드에 다음과 같은 주소를 부여한다. eth1에 부여되는 주소에 대해서는 내부네트워크에서 사용될 주소이므로 어떠한 값이 사용되어도 상관없다. 여기서는 node2(192.168.1.2), node3(192.168.1.3), node4(192.168.1.4)를 부여하기로 한다.

eht0 : IP(192.168.1.2)     hostname : node2.cluster.net

[root@node2 /etc]# /sbin/ifconfig 명령을 사용하여 제대로 설치됐는지를 확인해 볼수 있다.

[root@node2 /etc]# /sbin/ifconfig

eth0


lo


Link encap:Ethernet  HWaddr 00:60:08:F6:AB:24
inet addr:192.168.1.2  Bcast:75.1.50.255  Mask:255.255.255.0
. . . . . . . . .
Link encap:Local Loopback
inet addr:127.0.0.1  Mask:255.0.0.0
. . . . . . . . .

한편 라우팅은 아래와 같이 설정해 주어야 한다. 기본게이트웨이는 관리노드가 된다. X-window 환경에서 netcfg 명령을 사용하여 쉽게 설정할 수 있다.

[root@node2 /etc]# /sbin/route
Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use lface
192.168.1.2
192.168.1.0
127.0.0.0
default
*
*
*
111.111.111.111
255.255.255.255
255.255.255.0
255.0.0.0
0.0.0.0
UH
U
U
UG
0
0
0
0
0
0
0
0
0 eth1
0 eth1
0 lo
0 eth0

2-3-3. hosts 파일 편집한다.

클러스터를 이루고 있는 각 노드의 주소와 이름을 정의해 준다.

[root@node2 /]# vi /etc/hosts

210.123.54.230
192.168.1.1
192.168.1.2
192.168.1.3
192.168.1.4
master.cluster.net
node1.cluster.net
node2.cluster.net
node3.cluster.net
node4.cluster.net
master
node1
node2
node3
node4

2-3-4. /home을 공유한다.

이미 관리노드에서는 node2, node3, node4가 관리노드 자신의 /home을 마운트하는 것을 허락했다. 따라서 컴퓨팅노드에서는 관리노드의 /home 공간을 아래와 같은 한 줄을 추가함으로써 마운트할 수 있다.

[root@node2 /]# vi /etc/fstab
. . . . . . .
192.168.1.1:/home     /home   nfs   hard,intr,rw

컴퓨터 192.168.1.1의 /home을 자신의 /home 으로 사용하라는 명령이다. 이때 파일시스템은 nfs 이고 hard는 강한연결을 의미한다. 즉 마스터 노드의 nfs가 죽었다면 /home을 사용하기를 원하는 슬레이브 노드의 프로세스는 마스터 노드가 살아나서 /home 에 접근할 수 있을때까지 기다린다. 그리고 이 프로세스를 죽이거나 정지시킬수 없는 상태가 된다. 그러나 intr 옵션을 줌으로써 죽이는 것이 가능하게 된다. 반대로 soft 옵션을 timeo=

2-3-5. rsh을 허가한다.

컴퓨팅노드 역시 관리노드와 마찬가지로 inetd.conf 파일을 동일하게 주석 처리 부분을 제거해해 주고 /hosts.equiv 파일을 편집해준다. 이제 rsh 이 제대로 동작하는지 확인해보자. root 가 아닌 일반 유저로 테스트 해야 한다.

관리노드에서 컴퓨팅 노드로 rsh이 되는지 확인해보자.

[scshin@master scshin]$ rsh node2
Last login: . . . . . .
[scshin@node2 scshin]$

컴퓨팅노드에서 관리노드로 rsh이 되는지 확인해보자.

[scshin@node2 scshin]$ rsh node1
Last login: . . . . . .
[scshin@master scshin]$

2-3-6. 병렬라이브러리를 설치 및 테스트

이제 컴퓨팅노드에도 동일한 방법으로 LamMPI를 설치하자. 컴퓨팅노드는 인터넷에 연결되어 있지 않으므로 ftp 또는 rcp을 이용하여 관리노드로부터 lam-6.3.2.tar.gz 파일을 받아서 설치하면 된다.

이제 2개의 컴퓨터 master(node1) 와 node2가 클러스터링 되었다. 이제 lamMPI를 사용하여 클러스터가 제대로 동작하는지를 테스트해보고 나머지 node3, node4를 클러스터링 할 것이다. 특이할만한 것은 node3, node4의 설치는 다른 방법을 사용할 것이다. 일단 테스트를 해보자.

테스트를 위한 프로그램 이 준비되있다. 이를 다운받아서 아래와 같이 수행해 보자. 아래와 같이 됬다면 LamMPI 가 정상적으로 설치되고 작동할 것이다. 여기서 lamhosts라는 파일은 클러스터내에 어떤 노드가 있는지를 지시해주는 파일이며 반드시 lamhosts 라는 이름을 가질 필요는 없으며 클러스터내의 호스트주소를 담고 있으면 된다.

[root@master /tmp]# su - scshin
[scshin@master scshin]$ vi lamhosts
node1
node2
[scshin@master scshin]$ lamboot -v lamhosts
LAM 6.3.2/MPI 2 C++ - University of Notre Dame
Executing hboot on n0 (node1)...
Executing hboot on n1 (node2)...
topology done
[scshin@master scshin]$

병렬 라이브러리를 포함하여 컴파일을 한다. gcc 대신 hcc를 사용해야 한다.

[scshin@master scshin]$ hcc -o parall_add ./parall_add.c -lmpi

우리는 2개의 노드를 가지고 있으므로 -np 2 라는 옵션을 사용하여 병렬로 수행한다. 프로그램에서 입력을 요청할 것이다. 적당한 integer 숫자를 적어주자. 프로그램은 1부터 사용자가 입력한 숫자까지 병렬로 덧셈을 수행하고 시리얼로 덧셈을 수행하여 speeup을 알려줄것이다.

[scshin@master scshin]$ mpirun -np 2 ./parall_add
*****************************************************
          Notice !!
If input is not enough large,
    Parallel method is not efficient.
This program will add from 1 to your input.
*****************************************************
Input integer number : 10000000
    Parallel SUM = 2290707264,   Wall clock time = 0.075050
    Serial Sum = 2290707264,   Wall clcok time = 0.144484
    SPEED UP = 1.925171
Goodbye! : )
[scshin@atom scshin]$

1∼10000000 까지 더하였다. 병렬로 계산해서 0.144484 초가 걸렸으며 스피드업은 약 1.9가 나왔다. 컴퓨터 사양에 따라 당연히 결과값은 조금씩 틀릴 것이다. 여기까지 왔다면 기본적인 클러스터가 구성된 것이다.

 

2-4. 클러스터의 확장

이제 우리는 master(node1) 와 node2을 클러스터링 하였다. 이제 남은 node3, node4를 클러스터에 붙여보자. 위에서 설명한 컴퓨팅노드의 세팅에 준해서 설치를 하면 된다. 그러나 컴퓨팅 노드가 하드웨어적으로 완전히 동일한 사양이라고 한다면 다른 유용한 방법이 있어서 이를 소개한다.

추가는 하나씩 하나씩 해나가면 된다. node3을 추가해 보자. node3에서 HDD를 분리하여 node2에 붙인다. 이제 node2를 부팅하자. 이제 node2는 2개의 HDD를 갖게 되었다. 원래 node2가 갖고 있던 HDD가 /dev/hda 라고 하고 node3에서 띠어낸 HDD가 /dev/hdc 라고 하면 다음과 같은 명령을 사용하여 디스크복사를 하자.

[root@node2 /root]# dd if=/dev/hda of=/dev/hdc

이제 node2에서 새로 붙인 HDD를 분리하여 node3에 붙이자. 그리고 node3을 부팅한후 몇가지 설정 파일을 변경하자. 이 파일들은 위에서 다루었던 파일들이므로 자세한 내용은 생략한다.

  1. 모든 노드의 /etc/hosts 파일에 192.168.1.3 node3 node.cluster.net을 추가한다.
  2. 모든 노드의 /etc/hosts.equiv 파일에 node3을 추가한다.
  3. 마스터 노드의 /usr/local/atom/cluster.list 에 node3을 추가한다.
  4. 마스터 노드의 /etc/exports을 변경하여 node3이 /home을 마운트하는 것을 허락해준다.
  5. 추가한 노드의 /etc/fstab을 변경하여 마스터 노드의 /home을 마운트하도록 한다.
  6. 추가한 노드의 /etc/sysconfig/network에서 호스트 네임을 node3으로 변경하자.
  7. 추가한 노드의 /etc/sysconfig/network-scripts/ifcfg-eth0의 IP를 192.168.1.3 으로 바꾸자.
  8. 마스터노드의 nfs를 다시 시작해주고, node3을 리부팅해서 테스트 해보자.

 

3. 보안

일반적으로 가장 간단한 몇가지 최소한의 보안에 대해서 고려해보고자 한다. 클러스터의 보안은 전적으로 관리노드에서 이루어져야 하며 리눅스에서 기본으로 제공하고 있는 tcp wrapper를 이용해보자.

모든 보안설정이 그러하듯 모든 접근권한을 막고, 일부를 열어주는 방법을 사용한다. 아래는 tcp_wrapper 에 의해서 제어 가능한 모든 서비스포트의 접근을 막기위한 설정이다. 아래 한줄을 추가한다.

[root@master /]# cat /etc/hosts.deny
. . . . . . .
ALL : ALL EXCEPT localhost : twist ( /etc/deny_message %h ) &

twist 는 거부된 접근에 대해서 정해진 스크립트를 수행하도록 해준다. 따라서 허가되지 않은 IP로 부터의 접근은 /etc/deny_message을 출력을 보내주고 연결을 끊는다. 아래 간단한 스크립트 예제가 있다.

[root@master /]# cat /etc/deny_message
#!/bin/sh
echo "Your IP=$1 is not allowed."
[root@master /]# /etc/rc.d/init.d/inet restart
. . . . . .
. . . . . .

이제 모든 곳으로부터의 접근은 거부될 것이다. 정확하게 말하면 tcpd에 의해서 제어되는 모든 서비스로의 접근은 거부될 것이다. tcpd에 의해서 제어되는 서비스와 서비스 네임은 /etc/inetd.conf에서 확인할 수 있다.

이제 허가할 IP에 대해서 접근을 허가해 주어야 한다. 이 설정은 /etc/hosts.allow 파일에 의해서 아래와 같이 이루어진다.

[root@master /]# cat /etc/hosts.allow
. . . . . . .
##### IP of cluster #####
ALL     : 127.0.0.1

##### IP of cluster #####
ALL     : 192.168.1.

##### IP of allowed user #####
ALL     : 123.123.123.4
ALL     : 123.123.53.1
. . . . . .

이외에도 서비스단위로 접근제어가 가능하다. 123.123.123.123 에 대해서 telnet과 ftp만 허락하고자 한다면 다음과 같이 하면 된다.

in.telnetd   :   123.123.123.123
in.ftpd     :   123.123.123.123

또 한가지 고려되야 할 것은 필요없는 데몬(서버)들을 내려야 한다. 일반적으로 HPC클러스터의 경우 httpd, sendmail, smba, named 등은 사용하지 않을 것이므로 이들 서비스를 내리는 것이 바람직하다.

 

4. 클러스터 관리툴

ALPHA11팀에서 제작 사용하고 있는 간단한 클러스터 관리 프로그램을 설치하고 사용하는 방법에 대한 설명을 할것이다.

 

5. 벤치마킹

현재의 Setting되어진 System Configuration상에서 각종 기준이 될수 있는 Performance를 측정하는 것은 매우 중요한 일이다. Benchmark는 System의 성능을 check해 본다는 중요성도 있지만, 더 나아가 향후 System을 upgrade해나가는 과정중에 성능이 실제로 향상되었느냐는 관점에서 중요한 지침이 되는것이다. 물론 자신이 사용하고 있는 병렬 Application을 돌려보는 일은 우선적이다.

그러나, 그 밖에 일반적인 공개/표준 Benchmark program을 돌려본다면, 다른 Cluster System과 상호 성능 비교를 할수 있는 중요 자료를 확보하는 것이다.
흔히 쉽게구할 수 있는 대표적인 병렬 Benchmark program들은 아래와 같다.

NPB (NAS Parallel Benchmark)
      - http://www.nas.nasa.gov/Software/NPB/

Linpack Benchmark (ScaLAPACK Benchmark)
      http://www.netlib.org/scalapack/

PMB (Pallas MPI Benchmark)
      http://www.pallas.de/pages/pmbd.htm

NPB2 (클러스터의 성능 벤치마킹)
      - http://www.nas.nasa.gov/NAS/NPB

Linux/Unix nbench (리눅스 유닉스 성능 벤치마킹)
      - http://www.tux.org/~mayer/linux/bmark.html

NetPIPE (네트워크 벤치마킹)
      - http://www.scl.ameslab.gov/Projects/ClusterCookbook/nprun.html


출처 : http://www.alpha11.com - SAMSUNG Advanced Institute Of Technology

저작자 표시
신고

Trackback 6 Comment 1
  1. 김시우 2016.03.18 13:38 신고 address edit & del reply

    좋은 정보 감사합니다. 알기 쉽게 잘 정리해 놓으셨네요!