리눅스박스 클러스터링

제 의견으로도 알파 프로세서를 그렇게 쉽게 신뢰할 수 없다고 봅니다.

우선, 푸는 문제에 따라서 실제 씨피유가 보여주는 성능은 차이가 큽니다. 특히, 메모리를 많이 사용하는 과학기술 계산 어플리케이션을 돌리는 경우는 시피유의 캐쉬와 메모리 대역폭이 계산 시간에 많은 영향을 미칩니다. 특히, 캐쉬의 크기는 결정적인 요소가 되는 경우도 많습니다.

그 다음으로, 컴파일 시의 최적화 문제입니다. 일반 사용자는 다들 모르고 사용하겠지만, i386쪽 컴파일 옵션은 보통 이미 최적화가 되어 나옵니다. 한번 리눅스 커널을 컴파일할때 athlon을 선택한 경우와 pIII를 선택한 경우를 비교해 보면 gcc에 들어가는 옵션이 틀립니다. 실제, athlon 시피유의 경우는 컴파일 옵션을 잘 조절하면 컴파일 된 바이너리가 10%정도의 성능 향상을 보입니다. 한번 이 컴파일 옵션을 리눅스 커널에 넣어 컴파일 해 보려고 했더니 이미 makefile에 들어가 있더군요. :)

그래도 i386쪽의 완벽한 호환성을 보이는 애슬론도 이렇게 최적화용 컴파일 옵션이 따로 나오는 상황인데 사용자가 많지 않은 알파는 어떻겠습니까... 그냥 gcc로 대강 컴파일을 하면 그 바이너리 성능이 동급 클럭의 인텔이나 amd 시피유에 비해서도 떨어지는 경우가 실제 발생합니다.

이런 경우 가장 쉬운 해결책은 컴팩 (예전에는 디지털)의 Tru64 Unix를 돈주고 사고 여기에 따라오는 씨 컴파일러를 쓰는 방법이 제일 쉽습니다. 그런데 이 방법은 대신 돈이 많이 들죠.

실제 과거의 알파 프로세서 (EV6 버스를 쓰는 1기가 제품군까지)는 이런 최적화 문제가 심각했습니다. 대강 gcc로 컴파일 하면 실망스러운 결과가 자주 나왔습니다. 게다가 메모리 버스가 66Mhz였는데 여기서 병목이 생기면 동급의 펜3에 많이 뒤지는 결과가 나오곤 했습니다. 특히, 삼각함수를 많이 쓰는 어플은 성능 저하가 심각했는데 이 때문인지 누군가가 아예 알파 어셈블리로 math.h의 sin(), cos(), tan()와 같은 삼각함수들을 새로 만들어서 배포한 적도 있습니다.

그런까닭으로, 단순히 시피유 성능 벤치마크만 보고 과학기술계산용 프로세서를 결정하는 것은 상당한 무리가 있습니다. 한마디로, 돌려보기 전에는 모릅니다. 실제, 제 경험상으로도 예전에 어떤 실험실 선배 중의 하나는 실험실 내부의 울트라스팍, SGI, 알파 모두 놔두고 맨날 리눅스가 깔린 펜티엄 프로 200메가헤르쯔 컴퓨터에 들어가서 코드를 돌리곤 했습니다. 이유는요? 펜프로 피씨에서 결과가 평균 두배 빨리 나왔습니다. 그 선배만 그랬죠.

다만, 과학기술 계산용 프로세서를 생각할 때 다음과 같은 구매 원칙이 있기는 합니다. 글이 길어지지만 몇자 더 보태 보겠습니다.

1. 캐쉬 성능이 중요하다.

시피유 캐쉬는 가능한한 큰 것이 좋습니다. 그리고 같은 사이즈의 시피유라면 특별한 캐쉬 접근 기술을 채용한 시피유가 성능이 좋습니다. 1기가헤르쯔 씨피유가 맨날 133메가헤르쯔 메모리만 억세스 하고 있으면 그 시피유는 놀다 보니 133Mhz 클럭의 시피유가 되고 맙니다.

2. 최적화된 컴파일러가 있는가.

특히 널리 퍼져 있지 않은 시피유를 구입할때는 반드시 체크해야 할 사항입니다. 달리 말하면, gcc만 써도 시피유 성능이 제대로 나오는가를 체크해야 한다는 것입니다. 이걸 알아보기 위해서는 뉴스그룹을 뒤져가며 전세계 어딘가에서 이미 이 시피유로 과학기술계산 프로그래밍을 해 본 사람의 경험을 찾아보는 수 밖에 없습니다...

3. 유지 보수 비용은 어떤가

유지보수로 따지만 정말 x86솔루션만한 것이 없습니다. 막말로 조립해서 리눅스 깔고 돌리면 끝입니다. 뻑나면 부품별로 통째 갈아버리면 끝입니다.

그런데 막상 x86 세상을 벗어나면 당장 리눅스를 까는 것조차 문제를 일으키는 플랫폼이 많습니다. 알파의 경우, 삼성에서 만든 그 무엇이냐... rufian 계열 보드들은 리눅스를 설치하는데도 상당한 어려움이 있었습니다. 깔고 나서도 몇몇 프로그램이 오동작을 하기 시작하면 정말 막막할때가 많습니다.

이런 까닭으로 특히 대학원 실험실 내부의 현실을 고려한다면 특별한 이유가 있지 않은 한 그냥 최신의 x86 솔루션이 대학원 실험실에서는 최상의 과학기술 계산용 플랫폼이 될 수 밖에 없는 상황입니다. 그래도 잡일 많은 우리네 대학원생들 이런데까지 신경 다 쓰고 나면 제때 졸업 안됩니다. :)

참고로 예전에 알파머신을 정말로 괜찮게 사용하신 분의 얘기를 하나 적어볼까 합니다. 이분 전공은 정확히 기억이 안나는데... 아마 열쪽이나 유체쪽일겁니다. 그 당시 실험실에 데모용으로 알파 머신이 하나 두달간 임대되어 왔는데 여기에는 윈도우즈 NT와 비주얼 포트란이 깔려 있었습니다. 어느날 옆 실험실 박사과정에 계시는 이 분이 윈도우즈 NT용 텔넷 대몬을 하나 깔아달라고 그러더군요. 그 다음부터 이 알파 머신이 하루종일 뭔가 작업을 하기 시작했는데 한달 지나고 나니까 이 분이 박사 논문 발표를 하더군요. 나중에 물어보니 알파에서 자기 프로그램이 몇배로 빨리 돌아갔다나요?

그러나 비슷한 경우가 구조역학을 전공하는 제 실험실 구성원 중에서는 발생하지 않았습니다. 알파 별로 안빠르네가 중론이었죠. :)

참고로 하십시오.

저도 공대 출신이지만 플라즈마 쪽은 아예 모르겠구요. 동역학 쪽 솔루션들은 전체적으로 병렬화가 어렵다고 알고 있습니다. 가능한 알고리즘들이 많기는 하지만요. 혹 Genetic Programming으로 문제 해결이 가능하다면 클러스터 사용을 추천합니다. 이게 딴게 아니고 씨 많이 뿌려서 제일 잘나가는 놈들만 수확하겠다는 것이기 때문에 뿌릴 수 있는 '밭의 수'가 많으면 많을 수록 좋죠. 병렬화에 무척 요긴합니다.

MPI를 좀 보셨다면.. 우선은 localhost에서 MPI프로세스를 여러개 띄워서 컴퓨터 한대에서 병렬 프로그램을 돌려 보십시오. 병렬 프로그래밍이라는게 컴퓨터 여러대가 꼭 필요한 것은 아닙니다. 한대로도 병렬 프로세스를 수십개 돌릴 수 있죠. 다만, 이렇게 되면 속도 향상은 하나도 없습니다만 그래도 일주일 꼬박 새어서 클러스터 구축한 다음 MPI 셋업 다잡고 어플 돌려봤더니 도저히 안되겠더라.... 이것보다는 훨씬 낫습니다.

일단 어플리케이션이 잘 돌고... MPI 프로그래밍으로 가능성이 좀 보이면 컴퓨터 숫자를 두대로 늘여 보십시오. 두대에서 MPI 셋업이 잘 잡히고 어플이 잘 돌면 넉대, 여덟대, 이렇게 숫자를 늘여나가도 상관없습니다.

간단히 손쉽게 병렬 프로그래밍의 이점을 볼 수 있는 하드웨어 구성은 듀얼 프로세서 시스템입니다. 여기도 마찬가지로 프로세서가 두개가 된다고 컴퓨터 성능이 두배로 빨라지는 것은 아닙니다. 그런데 만약 MPI 프로그램을 만들었고 이 MPI 프로그램이 두개의 프로세스를 돌린다고 가정합시다. 이 프로그램을 듀얼 프로세서 시스템에서 돌리면 어떤 일이 벌어질까요?

이렇게 되면 프로세스 하나는 CPU 1번에서, 프로세스 두번째는 cpu 2번에서 돌아가게 됩니다. 프로세스간의 통신은 자동적으로 씨피유 사이의 버스를 이용하니까 사용자가 신경을 써 줄 필요도 없구요. 간단한 병렬화는 이런 듀얼 프로세서 시스템이 합리적인 선택이 될 수도 있습니다. 즉, 2 노드 클러스터를 구축하는 것 보다는 그냥 돈들여 듀얼 프로세서 시스템을 하나 사는 것이 비용면에서나 셋업을 잡는데 훨씬 유리할 수가 있는 겁니다.

그런데 여기도 문제가 없는 것은 아닙니다. 현재 펜4는 버스 구조가 어떻게 바뀌었는지 모르겠는데... 펜3까지는 듀얼 시피유가 달릴 경우 이 시피유들은 각각 동등하게 메모리와 시피유 사이의 버스 대역폭을 나누어 씁니다. 예를들어 시피유 하나가 달렸을때 시피유와 메모리 사이의 대역폭이 2 기가바이트/초 였다면 시피유 두개가 달리면 시피유 하나와 메모리 사이의 대역폭은 1 기가바이트/초로 줄어드는 것이죠. 만약, 프로세스간의 통신량이 엄청나게 많은 경우는 이 대역폭이 bottleneck으로 성능 저하를 가져올 수 있습니다.

AMD의 Athlon MP는 이런 면에서 우수합니다. 위의 예의 경우, AMD 칩셋을 쓴 듀얼 프로세서 마더보드의 경우 각각의 시피유마다 동일한 2 기가바이트/초의 대역폭을 줍니다. 그런데 전반적으로 AMD의 솔루션은 실제 메모리 성능 벤치마크를 해 보면 인텔에 비해 상당히 떨어지는 수치가 나오는 경우가 많습니다. 인텔이 2기가/초 결과가 나왔다면 amd는 1.5기가/초가 나오는 식이죠.

일단 제가보기에는 님의 경우는 2 노드 클러스터로 갈 것인지 아니면 4노드나 좀더 많은 숫자의 노드 클러스터로 갈 것인지를 결정을 해야 할 것 같습니다. 노드 숫자가 많아지니까 계산 결과도 빨리 튀어 나오더라... 그러면 예산 범위내에서 어드민 노가다 수준을 예상하고 클러스터를 구축하면 됩니다. 다만, 2 노드 클러스터로도 충분하겠다 싶으면 그냥 듀얼 프로세서 시스템을 하나 더 구입하는 것이 최선의 방법입니다.

어떻게 보면, 공대 대학원 실험실에는 듀얼 프로세서 시스템은 하나 정도는 있어야 합니다. 한두명이 계산 프로그램을 돌리는 게 아닌데 이미 한 사람이 컴퓨터에 들어가서 하루종일 도는 프로그램을 돌리고 있으면 막상 거기에 다른 사람이 들어가서 프로그램 하나를 더 돌려놓고 오기가 뭣하거든요... (보통 이때는 짬밥에 따라 컴퓨터 이용 우선순위가 결정되죠.) 그런데 빵빵한 듀얼 프로세서 시스템이 하나 있으면 급한 사람 두명은 한번에 처리가 가능하다는 장점이 생깁니다.

얘기가 길어지는데요. 현실적으로 오후 5시가 넘어가면 에어컨을 칼같이 끄는 우리나라의 실정에서 실험실에 1U나 2U 노드로 클러스터를 꾸미면 그 클러스터 여름에는 열과 소음 때문에 사람고생 컴퓨터고생입니다. 반드시 컴퓨터는 그래도 열 덜받는 데스크탑으로 꾸미세요. 안그러면 관리안됩니다. :) 그리고 가능하다면 클러스터는 어디 환기 잘되는 참고 같은데 쳐박아 놓는게 좋습니다. 제일 좋은 장소는 학교 전산실 같은데 자리를 좀 얻는 것이죠.

전체적으로 리눅스 클러스터의 딜레마는 이렇습니다. 리눅스 클러스터링은 '슈퍼컴퓨터가 반드시 필요한 사람'에게는 이만한 솔루션이 없습니다. 비싼 IBM나 SGI 기계 사는 몇분지 일의 가격으로 (셋업 노동비 포함) 슈퍼컴을 하나 만들 수 있습니다. 다만, 막연히 '수퍼컴퓨터가 필요하다고 느끼는' 사람에게는 끝없는 노가다 세팅의 고역을 안겨줄 수도 있습니다. 우선 풀려고 하는 알고리즘의 병렬화 가능성을 반드시 직접 프로그래밍을 해서 체크해 보시고 그 다음에 구축할 노드 숫자를 결정해 보시기 바랍니다. 2노드 클러스터를 구축할 요량이면 그냥 듀얼 프로세서 시스템을 구입하는 것이 유리합니다.

그럼.