[리뷰] IBM System x x3630 M3 랙 최적화 서버

네트워크와 인터넷을 사용하는 인구가 늘어나고 접속 단말도 다양해지면서, 인터넷을 활용하는 방법 또한 다양해지고 있다. 처음 공개될 때만 해도 단순한 텍스트와 이미지 정보만 늘어 놓던 웹 환경은, 이제 그 자체로 훌륭한 ‘플랫폼’으로의 기능을 할 수 있을 정도로 발전했으며, 아직도 새로운 활용 방법이 계속 등장하고 있다.

웹을 필두로 한 인프라와 환경을 구성하고, 사용하는 방법이 다양해지면서, 서버 또한 정형화된 형태로는 사용자들을 만족시킬 수 없게 되고 있다. 서비스들마다 서로 집중해야 할 부분이 다른 만큼, 인프라 또한 서비스의 성격에 최적화해야 할 필요가 있다. 이에 따라 특정 용도군에 최적화된, 변형 구성을 가진 서버들이 모습을 보이고 있다.

▲ IBM System x3630 M3 서버의 성격은 외관을 통해 확연히 알 수 있다.

■ 분명한 목적성이 엿보이는 독특한 구성

IBM System x3630 M3 랙 최적화 서버는 이런 ‘변형 구성’을 가진 서버의 좋은 예다. X3620 M3의 플랫폼을 기본으로 하고 있지만 스토리지 부분의 ‘밀도’를 차별화 포인트로 내세우고 있는 이 시스템은, 높은 효율과 밀도를 가진 스토리지 덕분에 이를 집중적으로 사용하는 어플리케이션들에서 좋은 결과를 기대할 수 있는 ‘스페셜리스트’ 적인 성격을 지닌다.

x3630 M3의 내부는 이 시스템의 기본이 되는 x3620 M3와 드라이브 베이 부분을 제외하고는 동일하다. 인텔 제온 5500, 5600 시리즈 프로세서의 듀얼 구성과 함께 프로세서 소켓 당 6개의 메모리 소켓을 갖춰 최대 96GB의 메모리를 사용 가능하고, 프로세서의 지원 여부에 따라 DDR3-1333 규격까지 사용 가능하도록 지원한다.

* 참고기사 : [리뷰] IBM System x x3620 M3 랙 최적화 서버
http://www.acrofan.com/ko-kr/commerce/content/20100831/0001040001

▲ x3630 M3의 내부 모습

▲ 두 개의 소켓과 12개의 메모리 슬롯을 갖추고 있다.

시스템의 전체적인 쿨링은 패시브 형태로 이루어지며, 네 개의 리던던트 지원 팬 모듈과 덕트를 사용한다. 팬의 배치는 시스템의 주요 열원인 프로세서와 메모리 부분에 집중되어 있어 비용과 냉각 효율을 동시에 잡고 있다. 또한 이 시스템에 사용되는 팬에는 핫 스왑 기능이 빠져 있지만, 리던던트 요소를 갖춤으로써 ‘계획된 중단’ 수준까지의 시스템 신뢰성을 확보하고 있다.

확장 슬롯은 외부 두 개, 내부 한 개를 사용할 수 있는데, 실질적으로 내부의 슬롯은 x3630 M3에서 사용할 수 있는 옵션 카드가 없어서 큰 의미가 없다. 또한 PCI 익스프레스 x8 슬롯 두 개로 구성된 외부 슬롯의 경우도, 이미 한 개의 슬롯을 스토리지를 위한 RAID 컨트롤러가 사용하고 있어 실질적으로 남는 슬롯은 한 개 정도라고 봐야 한다.

▲ 2.5 형 드라이브 베이 24개가 이색적이다.

IBM System x3630 M3의 차별화 포인트는 ‘스토리지’ 다. 전면에서 사용할 수 있는 드라이브 베이 수는 3.5형을 사용할 때 12개, 2.5형을 사용할 때는 최대 24개까지 사용할 수 있다. 2U 섀시 수준에서 공간이 허용되는 최대한의 스토리지 밀도를 갖추고 있으며, 이를 통해 사용자에게는 필요에 따라 유연한 스토리지 구성 폭을 제시한다.

수용 가능한 디스크 수가 많다는 것은 용량과 성능 양 쪽에서 모두 유리한 면이 있다. 용량적인 면을 생각한다면 3.5형 드라이브 베이에 고용량 디스크를 사용한 구성이 가능하고, 최대 성능을 생각한다면 2.5형 고성능 하드 디스크의 대규모 RAID 구성을 사용할 수 있기 때문이다. RAID 성능이 어레이를 구성하는 물리 디스크의 수와 밀접한 관계를 가지는 만큼, 24개의 디스크를 사용할 수 있다는 것은 스토리지 성능의 보증과도 같은 의미가 된다.

더 재미있는 점은, 전면에 있는 베이가 전부가 아니라는 것이다. x3630 M3는 시스템 후면에서 찾을 수 있는 빈 공간에 별도의 드라이브 베이를 장착해 사용할 수 있으며, 이 때 시스템에 장착 가능한 총 디스크 수는 3.5형의 경우 14개, 2.5형의 경우 28개에 이른다. 현재 출시되고 있는 최고 용량인 3.5형 2TB 드라이브를 사용할 경우 최대 28TB의 원시 용량 확보가 가능하다.

▲ RAID 컨트롤러의 옵션에는 고급형 모델이 존재한다.

▲ 드라이브와의 물리적 접속을 맡는 백플레인 패널의 모습

일단 스토리지 구성의 ‘규모’ 가 전제되다 보니, x3630 M3에서 선택 가능한 컨트롤러는 M1014/5014/5015 등 2포트 구성의 비교적 고급형 컨트롤러만 남는다. 또한 이 컨트롤러들의 공통점이라고 한다면 6Gbps SAS 규격 지원과 함께 PCI 익스프레스(Express) 2.0 x8 슬롯을 사용해 시스템과 연결된다는 것이며, 이는 고성능 드라이브의 대규모 RAID 구성에서도 제 성능을 내기 위한 목적이다.

PCI 익스프레스 2.0 x8 규격의 최대 대역폭은 4GB/s 수준이며, 이 정도 대역폭이면 현재 나오는2.5형 하드 디스크 24개의 대역폭을 충분히 뒷받침하고도 어느 정도 여유가 남는다. 하지만 컨트롤러가 이보다 낮은 대역폭으로 시스템에 연결되면 컨트롤러의 능력과 상관 없이 병목 현상을 피할 수 없게 된다. 덕분에 x3630 M3의 스토리지 컨트롤러는 외부 슬롯 하나를 점유하는 형태로 장착되며, 실질적으로 남는 확장 슬롯은 하나다.

한편, 일반적인 2포트 RAID 컨트롤러라면 포트당 4대의 드라이브, 최대 8개의 드라이브까지 직접 연결을 지원한다. 이 시스템처럼 컨트롤러 하나로 24개에 다다르는 디스크들을 지원하기 위해서는 별도의 익스펜더(Expander) 가 반드시 필요하다. x3630 M3는 전면 드라이브 베이의 백 패널에 익스펜더가 통합된 형태로, 케이블링이 최소화되어 깔끔한 모습을 확인할 수 있다.

■  원격 관리 중심의 높은 관리성

▲ 시스템 진단 모듈은 최대한 간소화된 모습이다.

최근의 서버들에 있어 그 중요성이 대폭 올라간 요소 중 하나가 ‘관리성’ 이다. 이제 관리성이라 하면 기계적인 구조 뿐 아니라 원격 관리, 자동화된 시스템의 진단 기능까지를 모두 포함하게 되며, 이는 시스템의 비용 효율 뿐 아니라 신뢰성과도 연관되는 중요한 부분이 되었다. 덕분에 현재 각 서버 제조사들이 만드는 서버의 개성은 ‘관리 솔루션’ 의 특성이 되는 경우가 많다.

x3630 M3는 기계적인 관점에서의 관리 기능들 중 몇 가지를 비용과 맞바꾼 면이 있다. 시스템 내부의 쿨링 팬에서 핫 스왑 지원 기능이 빠지고, 외부에서의 시스템 진단 기능이 최대한 간소화된 것이 그것이다. 하지만 쿨링 팬 자체도 리던던트 지원이며, 파워 서플라이 또한 핫 스왑 지원의 이중화 구성이 기본인 만큼, 기본적인 관리성과 신뢰도는 높은 수준이다.

단, 시스템의 관리성에서 주의할 부분이 있다. 이는 로컬 수준의 기계적 관리는 상당 부분 생략되었지만, 원격 관리 부분은 강력한 모습을 그대로 유지하고 있기 때문이다. X3630의 경우 로컬 관리를 위한 전면 VGA 연결 포트도 없고 운영 체제 설치를 위한 ODD 드라이브에 대한 배려도 없어 로컬 수준의 관리성 면에서는 다소 아쉬울 수 있으나, 원격 환경이라면 IBM의 툴 지원으로 큰 어려움이 없다.

▲ 이 시스템의 관리성의 핵심은 ‘원격 관리’

x3630 M3의 관리성은 ‘원격 관리’ 를 위주로 구성된다. IBM의 시스템들에 공통적으로 탑재되는 IMM(Intregrated Management Module)는 원격 시스템 관리 기능을 제공하는 원 칩 형태의 통합 모듈이며, 이를 통해 원격으로 서버 상태의 모니터링과 운영체제의 상태에 상관 없는 원격 시스템 구성과 관리 등의 기능을 제공하여, 하드웨어적인 문제 이외에는 물리적인 조작을 할 필요가 거의 없다.

이 모듈은 현 System x 라인업에 같은 바이너리를 기반으로 올라가기 때문에 모든 모델에서 동일한 형태로 접근과 사용이 가능하다. 또한 IMM은 관련 표준을 준수해 동작할 수 있도록 설계되었기 때문에 IBM의 시스템 디렉터(Systems Director) 뿐 아니라 관련 표준을 준수하는 모든 관리 솔루션과 연동해 사용할 수 있게 만들어져 있어 이기종 조합의 복잡한 환경에서도 충분한 관리성을 확보할 수 있다.

기존 시스템들에 사용되던 BIOS 또한 UEFI(Unified Extensible Firmware Interface)로 대체되었다. UEFI는 기존 BIOS에 비해 큰 용량과 많은 편의 기능을 제공할 수 있으며, 이 시스템에서는 시스템 진단 도구와 IMM과의 연동을 통해 전반적인 시스템 관리성을 높여 주고 있다. 특히 시스템 전면에서 볼 수 있는 LED 형태의 진단 도구는 기존 시스템의 ‘비프 코드’ 를 완전히 대체하게 되었으며, 에러 코드도 좀 더 알기 쉬운 형태로 바뀌었다.

이 시스템에서 UEFI는 시스템 내, 외부적으로 기능성과 관리성을 높여 주고 있다. 내부적으로는 지금까지 별도의 방법으로 접근해야 했던, 별도의 펌웨어 설정을 가진 옵션 카드들에 접근하는 방법을 UEFI 콘솔 안에서 단일화하여 반복 작업의 효율을 높여 준다. 또한 기존의 BIOS가 가지고 있던 옵션 카드 수 제한이 사라짐으로써, 더 유연한 가상화 환경의 사용이 가능하게 되었다.

또한 UEFI를 사용한 덕분에 시스템의 원격 설정과 관리 부분에서도 기능 개선이 있었다. 스크립트를 사용해 원격에서 시스템의 설정을 자동화할 수 있으며, 펌웨어 업데이트 또한 IMM과의 연계를 통해 쉽게 관리 가능하게 되었다. 이를 통해 전체 인프라에서 시스템 서비스 중지 시간을 최소화하여 비용 부담을 줄이고, 플랫폼의 손쉬운 관리성을 확보하고 있다.

▲ 인프라 수준까지 충실한 관리 도구가 준비되어 있다.

IBM 툴센터(IBM ToolsCenter)는 시스템의 구성과 설정, 관리를 위한 툴로, 다수의 시스템들에 설치, 업데이트, 설정, 진단 등의 작업을 수행하는 데 있어 반복 작업을 줄이고 효율을 높여 주는 강력한 통합 툴이다. 이 툴은 일관적이고 간편한 인터페이스를 가지고 있으며, 통합 형태로 구성되어 필요한 툴을 쉽게 찾고 사용할 수 있도록 만들어져 있다.

인프라 수준의 관리 도구로는 IBM 시스템 디렉터(Systems Director) 가 있다. 시스템 디렉터는 기존의 툴센터 등과도 유사한 인터페이스를 가져 쉽게 접근 가능하도록 구성되어 있으며, 강력한 통합성과 확장성이 특징이다. 이를 통해 관리자는 하나의 통합 툴로 인프라를 관리할 수 있어 관리의 복잡성을 줄이고, 교육과 운영에 들어가는 비용을 줄일 수 있다.

이 툴은 물리적, 가상화된 자원 모두를 통합 관리할 수 있으며, System x 브랜드의 x86 계열뿐 아니라 IBM 블레이드센터(BladeCenter), IBM의 Power 계열 시스템과 System z 등의 비 x86 계열 시스템과 스토리지, 비 IBM 브랜드의 x86 시스템까지도 통합 관리 가능한 강력한 성능을 자랑한다. 그리고 티볼리(Tivoli) 제품군과도 통합될 수 있도록 기능이 제공되는 등 강력한 통합성을 자랑한다.

■  다양한 활용을 가능하게 해주는 조화로운 구성

▲ 테스트 시스템의 구성

System x3630 M3의 주요 차별화 방법은 ‘스토리지’ 다. 하지만 이 시스템은 단순히 스토리지만을 강조하는 NAS나 스토리지 서버 패키지가 아니며, 스토리지 부분이 특화되어 있지만 엄연한 ‘범용 시스템’ 이다. 그리고 이를 위해서는 스토리지 뿐 아니라, 서비스를 제공하기 위한 기본 이상의 성능 또한 갖추고 있어야 하며, 이를 통해 다른 시스템들과도 다른 독특한 위치를 만들 수 있다.

테스트 시스템은 인텔 제온 E5620 프로세서의 단일 구성이며, 메모리는 4GB DDR3 PC3-10600 규격의 모듈을 6개 사용해 총 24GB로 구성했다. 제온 E5620 프로세서는 32nm 웨스트미어 아키텍처 기반의 프로세서로, 4코어 8스레드 구성과 12MB L3 캐시, 트리플 채널 DDR3 메모리 컨트롤러를 가지고 있다.

스토리지는 ServeRAID M5014 컨트롤러와 SAS 6GB/s 규격의 2.5형 10,000rpm 300GB 하드 디스크 두 개를 RAID 1으로 구성해 테스트를 진행했다. 기반 환경은 레드햇 엔터프라이즈 리눅스(Redhat Enterprise Linux) 5.5 기반으로 php 5.3.2를 제외한 나머지 시스템 라이브러리는 기본 리포지터리의 버전을 사용했다.

▲ MD-Gromacs 테스트 결과, 단위는 Gflops, 수치는 높을수록 좋다.

▲ Stream 테스트 결과, 단위는 MB/s, 수치는 높을수록 좋다.

프로세서와 메모리를 포함한 기본 플랫폼의 연산 성능을 알아보기 위해 사용한 MD-Gromacs 결과에서는 이 시스템이 사용하고 있는 인텔 제온 E5620 프로세서의 특징을 확인할 수 있다. 전반적인 성능 자체는 동급 프로세서를 사용한 시스템들과 비교해 큰 차이가 나지 않으며, 이는 같은 프로세서와 플랫폼을 사용하는 데서 예상할 수 있는 결과기도 하다.

인텔 제온 5600 프로세서와 플랫폼이 가진 특유의 처리 효율 또한 이 결과에서 찾아볼 수 있다. E5620 프로세서가 물리적으로는 4코어만 탑재하고 있음에도, 하이퍼스레딩 기술을 통해 멀티 스레드 성능은 물리적 코어 이상의 효율을 보여 주고 있다. 이런 성능 추이는 전반적으로 높은 플랫폼 성능이 필요한 가상화 통합 등에서 이점을 가져다 준다.

Stream 을 통한 메모리 테스트 결과도 단일 프로세서 수준에서 예상할 수 있는 수준의 성능을 보여 준다. 테스트 시스템의 경우 단일 프로세서의 트리플 채널 메모리 구성인 만큼, 듀얼 프로세서 환경을 제대로 구축할 경우 메모리 성능의 개선 또한 생각할 수 있다. 이는 x3630 M3의 기본 시스템이 되는 x3620 M3의 테스트 결과를 통해서도 확인 가능할 것이다.

▲ IOzone 테스트 결과, 단위는 MB/s, 수치는 높을수록 좋다.

타 시스템과 비교할 때, 이 시스템의 가장 큰 특징은 스토리지의 ‘규모’ 다. 일반적으로 다수의 디스크를 RAID 구성할 경우, 1차적으로는 장착하는 디스크의 수만큼 분산처리를 통해 성능이 올라가는 만큼, 스토리지 구성 규모의 확보는 스토리지의 성능과도 상관이 있다. 물론 어느 정도 이상의 규모와 워크로드가 확보되면 스토리지 컨트롤러의 성능과 대역폭 등에서도 차이가 나게 된다.

또한 이 시스템의 테스트 결과를 볼 때, 결과치에 미치는 각 부분의 기여도를 생각할 필요가 있다. 일반적으로 스토리지 테스트의 결과에 가장 직접적인 영향을 미치는 것은 스토리지를 이루는 물리적인 디스크의 수와, 이를 구성하는 방법이다. 또한 워크로드의 형태에 따라서는 스토리지 컨트롤러가 가진 처리 속도나 연결 인터페이스, 캐시 등의 특성이 영향을 미치며, 실제 사용에 있어서는 운영체제 수준에서의 메모리 캐싱 부분도 변수로 작용한다.

이런 변수들을 생각하면서 x3630 M3의 테스트 시스템 구성과 결과값을 보면, 결과값이 보여 주는 의미들을 좀 더 정확하게 파악할 수 있다. 테스트 시스템의 스토리지 구성이 10,000rpm의 2.5형 디스크 두 개라는 것을 생각할 때, 이 결과값에서 확인할 수 있는 디스크의 ‘물리적 성능’ 은 RAID 구성에 따라 달라지므로 큰 의미를 가지지 못하게 된다.

IOzone의 8GB 파일 테스트 결과는 테스트 시스템에서의 스토리지의 ‘캐싱 성능’ 이 반영된 모습임을 짐작할 수 있다. 테스트 결과에서 읽기 성능은 스토리지 컨트롤러의 캐시와 함께 운영 체제 차원에서의 디스크 캐싱이 적용된 모습이다. 쓰기 성능 또한 어느 정도 캐싱의 영향이 있는데, 읽기 성능과의 격차가 크게 나오는 것은 읽기와 쓰기 과정에서 캐시 운영의 방법이 다르기 때문이다.

▲ TIObench 테스트 결과, 단위는 MB/s, 높을수록 좋다.

▲ Dbench 테스트 결과, 단위는 MB/s, 높을수록 좋다.

TIObench의 테스트 결과는 이 시스템이 가진 물리적인 디스크 성능과 캐싱을 통한 성능을 모두 볼 수 있다. 테스트 시스템이 사용한 디스크 두 개의 RAID 1 구성은 이론적으로 싱글 디스크 성능과 별반 차이가 없거나, 읽기 성능에서만 이득을 볼 수 있는 구조이며, 일반적으로 쓰기 작업에서 캐싱이 제한적으로 사용되는 만큼, 여기서의 쓰기 결과는 물리적인 디스크 성능을 반영한다고 볼 수 있다.

반면 읽기 성능의 경우 스레드 당 256MB의 32스레드 동시 작업에서도 시스템 메모리의 캐싱 성능이 반영된 결과를 볼 수 있다. 이는 32스레드 동시 작업시 디스크에 걸리는 총 부하량이 8GB 정도로, 테스트 시스템에 장착된 24GB의 메모리가 테스트 시나리오 수준의 부하를 캐싱으로 모두 처리해낼 수 있기 때문이다. 이는 이미 IOzone의 결과에서도 확인할 수 있던 수준이다.

RHEL 기본 리포지터리 시나리오 상태에서의 Dbench 테스트 결과 또한 테스트 시스템의 캐싱 능력이 잘 반영되어 있다. 이 테스트 결과에서는 48클라이언트 이후부터 성능이 떨어지기 시작하는 것을 확인할 수 있지만, 수치에서 짐작할 수 있듯이 테스트한 전체 클라이언트 범위에서 캐싱 성능이 반영되는 것을 확인할 수 있다.

▲ Timed Benchmark, 단위는 ‘초’, 수치는 낮을수록 좋다.

▲ Timed Benchmark, 단위는 ‘초’, 수치는 낮을수록 좋다.

시스템 레벨에서의 성능을 측정하는 각종 테스트에서도 x3630 M3은 범용 서버로써의 충실한 역할을 할 수 있는 능력을 가지고 있는 것을 확인할 수 있다. 이는 기본적으로 이 시스템이 사용하는 인텔 제온 프로세서와 이에 기반한 플랫폼이 가진 성능에 기반하고 있으며, 이런 성능은 이 시스템을 스토리지 뿐인 시스템이 아닌, 스토리지에 강점을 가진 시스템으로 포지셔닝할 수 있게 해 준다.

MySQLBench 테스트의 경우, 비슷한 급의 싱글 프로세서가 가진 성능 수준의 결과를 확인할 수 있다. 또한 SQLite 테스트 결과에서도 나름대로의 성능을 보이고 있으며, 시스템 구성을 생각해 볼 때 성능 개선의 여지도 충분하다. 물론 이 시스템이 단순히 스토리지 서버가 될 지, 강력한 스토리지를 가진 범용 서버 형태로 사용될 지는 사용자의 선택에 달려 있다.

■ 유연성과 활용도가 돋보이는 고효율의 시스템

▲ x3630 M3 효율성의 한계는 사용자가 ‘쓰기 나름’

IBM System x3630 M3는 스토리지 부분의 강화를 통한 개성과, 플랫폼 레벨에서의 성능을 모두 갖춘 시스템이다. 이 시스템의 기본이 되는 x3620 M3가 가진 플랫폼의 성능과 효율, 신뢰성이라는 장점을 그대로 이어받으면서 스토리지 구성의 규모를 확보함으로써 효율과 성능, 기능성을 더 끌어올려 다양한 부분에서 제 성능을 발휘할 수 있도록 하고 있다.

이 시스템이 가진 스토리지 구성의 '규모' 는, 자칫 이 시스템을 단순한 스토리지 서버나 NAS 대용 정도로 보이게 하는 경우도 있다. 하지만 이 시스템의 본질은 스토리지 집중적인 서비스에 최적화된 '범용 서버' 의 성격을 가지고 있으며, 이는 전체 포트폴리오에서 이 라인업의 위치, 그리고 이 시스템의 구성에 있어 별다른 제약이 없다는 데서 짐작할 수 있다.

이런 시스템 구성의 유연함은 시스템의 활용도와 비용 효율을 극대화한다. 이 시스템은 단순한 스토리지나 공유 포인트 정도로 사용하는 데부터 시작해 스토리지 사용량이 많은 웹, 스트리밍 비디오의 서비스부터 플랫폼과 스토리지 성능이 모두 필요한 각종 비즈니스 서비스, 가상화까지 어떤 용도에서도 적응할 수 있을 정도의 유연함을 가지고 있으며, 적절한 시스템 구성 계획을 통해 비용 효율과 성능을 극대화할 수 있을 것으로 기대된다.

▲ IBM System x3630 M3 시스템 사양