SATA

현재 주류를 이루고 있는 인터페이스는 P-ATA(패러랠 ATA, parallel ATA, 병렬방식 ATA)방식의 하드디스크이다. PATA 방식은 약 23여년전 1981년 ATA으로 등장하여 현재 ATA 133까지 발전 하였으니 상당히 오랜기간 발전을 해왔다고 볼 수 있다, 그러나 현재는 그 기술적 발전의 한계에 다다랐다고 평가되고 있는 상황이다.

      그 기술적 발전의 한계란 PATA의 구조가 병렬식이라는데에서 그 원인을 찾아 볼 수 있다. 병렬식 구조상 데이터 전송시 여러 가닥의 데이터 전송 라인을 이용하기 때문에 신호간 간섭이 생길 가능성이 높은데, 이러한 신호간 간섭은 전송된 신호의 손실 또는 지체를 유발할 수 있으며 이는 데이터 무결성 저하로 이어져 병렬식의 특성상 다시 처음부터 신호를 보네야 하므로 결과적으로 전송 속도를 떨어뜨리는 원인이 된다.

SATA

▲ SATA(직렬방식)의 연결사진

따라서 현재 기술상으로 PATA 인터페이스이 최대 발전단계인 ATA133 인터페이스는 최대 133MB/s 의 전송 속도를 지원하지만 병렬구조에서 오는 신호간섭 ??문에 사실상 100MB/s의 전송속도가 한계 전송 속도로 평가되어지고 있다. 실 제로도 하드 제조사중에 맥스터를 제외한 다른 제조사들은 ATA133 HDD 상용화를 포기한 사례에서도 살펴볼수 있다. 즉, 신호의 이동 속도는 향상시킬 수 있을지는 모르지만 신호 간섭으로 인한 전송속도의 저하는 PATA 방식으로 해결하기에는 기술적인 한계가 있고 실제 ATA133 활성화 후에도 안정성면에서 문제가 있어 상용화를 하지 않은 것이다.

이 에 새롭게 각광받게 된 것이 S-ATA(시리얼 ATA, serial ATA, 직렬방식 ATA)방식의 인터페이스이다.  새로운 시리얼 ATA에서는 기존의 병렬 방식의 데이터 전송 방식을 버리고 직렬 방식의 전송 방식을 채택하였으며, 신호선이 4개로 병렬 ATA(80개)보다 적지만 직렬로 자료를 주고 받으므로  병렬 방식에서 문제가 되었던 데이터 무결성 저하로 인한 전송속도 저하 막을 수 있다. 따라서 ATA-133을 마지막으로 한계에 다다른 현재의 전송속도를 SATA 방식을 채용함므로서  증가시키는 것이 가능하게 된 것이다. 따라서 앞으로 모든 메이저 하드제조사들은 SATA로 그 주력 제품군을 옮겨 갈 것으로 전망이 된다.

그 러나 현재 선보인 Serial ATA는 아직은 1세대 SATA 단계 이다. 따라서 기존  PATA 하드디스크의 최대 전송속도인 133MB/s보다  조금 빠른 150MB/s 의 전송속도를 보여주고 있어 큰 성능향상을 기대한다면 무리가 있다. 하지만 얼마후 발표될 2세대 SATA 하드에서는 그 2배에 달하는 300MB/s로 향상될 예정이며 2007년 선보일 3세대에서는 600MB/s로 전송 속도가 증가될 것이라고 하니 지금까지 더디게만 발전하였던 하드디스크의 발전속도가 SATA방식의 등장으로 그 발전에 상당한 탄력을 받을 것으로 예상이 되는 바이다.

아래표는 PATA & SATA HDD의 비교표이다.

PATA & SATA HDD의 비교

Parallel ATA

차이점

Serial ATA

SATA 이점

133MB/s가 한계점이지만, 현재 기술적으론 100MB/초(s)가 한계이다.

전송속도

현재는 150MB/s 이 한계이지만 2세대는 300MB/s으로 증가할 예정에 있다.
PATA에 비해 성능상 이점은 이미 충분하다.

별도의  점퍼세팅(master/slave이 필요하다

점퍼

별도의 점퍼세팅이 불필요하다.
point to point 방식이라 한다.

넓다.

데이터커넥터

얇다.
선정리와 냉각효과에 이점.

4핀 커넥터를 쓴다.

전원커넥터

15핀 SATA 전용 케이블을 쓴다

공기흐름을 막는다.

냉각효과

상대적으로 데이터커넥터가 얇아 공기순환에 이점이 있다.
PATA에 비해 선정리가 자유롭다.

반드시 전원을 차단하고 HDD를 연결하거나 제거 해야 한다.

핫스왑기능

(Hot Swap)

전원이 들어오는 상태에서도 연결과 제거가 자유롭다.
특히 서버처럼 24시간 운용해야 하는 경우에 특히 강점이다.

데이타 블록의 에러만 체크(CRC)한다. 

에러체크

명령,상태,데이터 블록의 3가지신호의 에러를 체크(CRC)한다.

PATA에 비해 안정적이다.

SCSI

SCSI는 Small Computer Systems Interface의 약어입니다. 이는 컴퓨터 업계에서 선도하는 I/O 버스 중 하나인 ANSI 표준입니다. SCSI 표준의 초석은 SASI (Shugart Associates Standard Interface) bus를 소개한 Shugart Associates에 의해 (세계 최초로 소형 플로피 디스크를 제공한 사람들) 만들어졌습니다.

얼마후 디바이스가 다른 제작사의 것들과 함께 동작할 수 있도록 하도록 좀더 엄격한 표준을 이루려는 업계의 노력이 있었습니다. 그 노력으로 ANSI SCSI-1 표준이 만들어졌습니다. SCSI-1는 (approx 1985) 빠르게 사장되어가고 있습니다. 현재의 표준은 SCSI-2이고 ( 추가사항을 보십시오), 앞으로 계획상 SCSI-3가 될 것입니다.

물리적인 상호 연결 표준에 추가로, SCSI는 디스크 디바이스가 반드시 지켜야만 되는 논리적 (명령어 집합체) 표준을 정의하고 있습니다. 이 표준은 일반 명령어 집합체라 (CCS : Common Canmmand Set) 하고 ANSI SCSI-1과는 다소 병렬적으로 개발되었습니다. SCSI-2는 자체에 표준의 일부로서 (계정된) CCS를 포함하고 있습니다. 이 명령어들은 쓰고 있는 장치의 종류에 의존합니다. 스캐너에서 쓰기 명령을 정의하는 것은 당연히 이치에 맞지 않습니다.

SCSI 버스는 병렬 버스인데, 이는 여러가지 종류가 있습니다. 오래된 것 그리고 대다수의 것들은 단일-종단형(single-ended) 신호이고 50개의 선으로 전송되는 8 bit 폭의 버스입니다. (단일-종단이 무얼 의미하는지 몰라도 걱정하지 마십시오, 문서에는 그것에 대한 모든 것이 있읍니다.) 근래의 디자인은 차동형 신호, 16 bit 폭의 버스를 또한 사용하고 있습니다. 이것은 20MB/s의 전송 속도를 허용하고 있으며, 케이블 길이도 25미터까지 가능합니다. SCSI-2는 추가 케이블을 사용해서 최대 32bit의 버스 폭까지 허용하고 있습니다. Ultra SCSI (또는 Fast-20이라 일컬어지는) 그리고 Ultra2가 (또는 Fast-40) 정말 빠르게 성장하고 있습니다. Fast-20은 초당 2000만 단위로 전송할 수 있고 (8 bit 버스에서 20 MB/s), Fast-40은 초당 4000만 단위로 전송할 수 있습니다. (8 bit 버스에서 40 MB/s) 오늘날 판매되는 대부분의 하드 드라이브는 단일-종단형 (8 또는 16 bit) Ultra SCSI입니다.

물론 SCSI 버스는 데이터 선만이 아니라, 여러 제어선도 지니고 있습니다. 매우 정교하고 복잡한 프로토콜은 효과적인 방법으로 복수의 디바이스가 버스를 공유토록하는 표준의 한 부분입니다. SCSI-2에서, 데이터는 항상 별도의 패리티 라인(line)을 이용하여 검사되고 있습니다. SCSI-2이전의 구상에서는 패리티는 옵션이었습니다.

SCSI-3에서는 케이블 오버헤드를 줄이고 최대 길이를 보다 길게한 직렬 SCSI 버스와 함께 보다 빠른 버스들이 소개되고 있습니다. 이 문서에서 SSA와 Fiberchannel과 같은 이름을 보게될 것입니다. 직렬 버스들 중 어느 것도 지금 널리 쓰이고 있지는 않습니다. (특히 전형적인 FreeBSD 환경에서는 그렇습니다.) 이런 이유로 직렬 버스 타입은 이 이후로 언급하지 않겠습니다.

위의 소개로 추측할 수 있는 것과 같이 SCSI 디바이스는 지능적입니다. 이것들은 SCSI 표준을 (2 인치의 두께의 BTW입니다.) 지켜야만 합니다. 그래서, 하드 디스크 드라이브를 예로 들면 특정 블럭에 접근하기 위해 헤드/실린더/섹터를 일일이 정해주지 않고 단지 간단히 원하는 블럭의 번호만 지정해주면 됩니다. 정교한 캐시처리 계획, 자동 배드 블럭 교체 등등은 이 ‘지능적인 디바이스’ 접근으로 모두 가능합니다.

SCSI 버스에서 장치들의 각가의 가능한 짝은 소통될 수 있습니다. 그것들의 기능이 그것을 허용하거나 않하거나는 또다른 문제이지만, 표준은 그것을 강요하지 않습니다. 신호 다툼을 피하기 위해 두 디바이스는 사용하기 전에 버스에 대해 조정해야 합니다.

SCSI의 철학은 오래된-표준 디바이스가 새로운-표준의 것과 같이 동작하게 하는 표준을 마련하는 것입니다. 그래서, 오래된 SCSI-1 디바이스는 SCSI-2 버스에서도 보통 동작을 할 것입니다. 보통이라고 한 것은 오래된 장치의 구현이 새로운 버스에 정말로 적합한 (오래된) 표준을 따르고 있는지 절대적으로 확신하지 못하기 때문입니다. 근래의 디바이스들은 표준화가 더욱 엄격하게 되어있으며 디바이스 제조업자에 의해 더욱 잘 지켜지기에 보통 더 잘 동작합니다.

일반적으로 말해서, 단일 버스에서 디바이스의 작동 셋을 얻는 기회는 모든 디바이스가 SCSI-2이거나 그 이후의 것일 때 더욱 좋습니다. 이는 반짝반짝 빛나는 2GB 디스크를 구했을 때 오래된 기기를 내다버려야 한다고 말하는 것은 아닙니다: 필자의 경우를 보아도 pre-SCSI-1 디스크, SCSI-2 QIC 테이프 유닛, SCSI-1 helical 스캔 테이프 유닛, 그리고 2개의 SCSI-1 디스크가 한 시스템에서 그런데로 잘 동작하고 있습니다. 그러나 성능을 염두에 둔다면 오래된 디바이스와 새로운 (=더 빠른) 디바이스를 분리하는 것이 더 낳을 수도 있습니다.

12.5.2.1. SCSI의 구성
앞에서 말한 바와 같이, SCSI 디바이스들은 지능적입니다. 아이디어는 SCSI 디바이스 자체에 깊숙한 하드웨어 세부에 대한 지식을 집어넣는 것입니다. 이 방법으로, 호스트 시스템은 하드 디스크가 얼마나 많은 헤드를 가지고 있는지, 특정 테이프 디바이스에 얼마나 많은 트랙이 있는지와 같은 걱정은 할 필요가 없습니다. 궁금함을 참지못하는 이를 위해 설명을 하자면, 표준은 하드웨어의 상세한 부분에 대해 디바이스에 질의하는 명령어를 정해놓고 있습니다. FreeBSD는 부팅시에 어떤 장치가 연결이 되어있는지 그것이 특정한 처리를 필요로하는지 안하는지 검사하기 위해 이러한 능력을 이용합니다.

지능적인 디바이스의 이점은 확연합니다: 호스트에서의 디바이스 드라이버를 훨씬 더 일반화된 형태로 만들 수가 있고, 더이상 소개되는 모든 기묘한 새 디바이스에 대해 드라이버를 변경할 (그리고 최적화할!) 필요가 없습니다.

케이블과 커넥터에 대해 황금률이 있습니다: 좋은 기기로 구하라는 것입니다. 좋은 재료를 사용하는 것이 버스 스피드를 높이게 되므로 항상 고통을 덜어드릴 것입니다.

그래서, 금도금된 커넥터, 보호처리된 케이블, 변형 방지를 가진 튼튼한 커넥터 후드(덮개) 등이 잘 팔리는 이유입니다. 두번째 황금률: 필요이상 긴 케이블을 쓰지 말라는 것입니다. 필자의 경우를 예로 들자면 한 괴짜 컴퓨터에서 발생한 문제를 잡는데 있어 단지 SCSI 버스 길이를 1m로 줄이는 것으로 해결된다는 것을 발견하는데 3일이 걸렸습니다. 그리고 원래의 버스 길이는 SCSI 스펙 상에서 잘 (정의) 되어있습니다.

12.5.2.2. SCSI 버스의 종류
전자공학적 관점에 의하면, 두가지 비호환 버스 형태가 있습니다: 단일-종단형(single-ended)과 차동형(differential). 이는 SCSI 장치와 컨트롤러에 두가지 다른 주요 그룹이 있다는 것을 의미합니다, 이들은 동일한 버스에 섞일 수 없습니다. 그러나, 특별한 변환기 하드웨어를 사용해서 단일-종단형 버스에서 차동형의 것으로 전송하는 것이 (그리고 역으로도) 가능합니다. 버스 타입의 차이점은 다음에 설명합니다.

SCSI와 연관된 많은 문서에서 각가지 버스 종류를 축약해서 사용하는 전문용어의 종류가 있습니다. 조금만 소개하면:

FWD: Fast Wide Differential
FND: Fast Narrow Differential
SE: Single Ended
FN: Fast Narrow
등등.

조금만 생각해보면 무엇을 뜻하는 지는 쉽게 알 수 있습니다.

와이드(wide)란 말은 좀 모호합니다, 이는 16 또는 32 bit 버스를 지칭할 수 있습니다. 그러나, 32 bit 류는 (아직) 사용되지 있지 않습니다. 그래서 와이드는 보통 16 bit를 지칭합니다.

패스트(fast)라는 것은 버스에서의 타이밍이 다소 다름을 의미하는데, 내로우(narrow) (8 bit) 버스에서 ‘느린’ SCSI의 5MB/s 대신 10MB/s가 가능합니다. 앞에서 말한 바와 같이, 초당 2000만 4000만 단위로 전송하는 버스 스피드도 생겨나고 있습니다. (Fast-20 == Ultra SCSI, Fast-40 == Ultra2 SCSI)

8번째 이후 데이터 라인(line)은 오직 데이터 전송과 장치의 어드레싱(addressing)에만 쓰인다는 것을 주의하십시오. 명령어와 상태 메세지 등의 전송은 오직 하위 8개의 데이터 라인에서 수행됩니다. 표준은 내로우 디바이스들이 와이드 버스에서 작동토록 하고 있습니다. 유효 버스 폭은 디바이스간에도 성립됩니다. 와이드와 내로우가 섞여있을 때 분명히 디바이스 어드레싱을 살펴보아야 합니다.

단일-종단형 버스(single ended buses)
단일-종단형 SCSI 버스는 5V 또는 0V (사실, TTL 수준), 그리고 *일반* 접지 참조(COMMON ground reference)와 연관있는 시그널을 사용합니다. 단일 종단형 8 bit SCSI 버스는 대체로 25개의 접지 라인을 가지고 있는데, 그것은 모든 디바이스에 단일한 `레일(rail)’로 묶여있습니다. 표준 단일 종단 버스는 최대 6m까지 가능합니다. 동일한 버스에 Fast-SCSI 디바이스를 사용하는 경우 최대 3m까지 허용합니다. Fast-SCSI는 5MB/s대신 버스가 10MB/s의 전송량을 허용하는 것을 의미합니다.

Fast-20 (Ultra SCSI)와 Fast-40은 각각 초당 2000, 4000만 단위의 전송량을 허용합니다. 그래서 F20은 8 bit 버스에서 20MB/s, 16 bit 버스에서 40MB/s 등을 허용하게 됩니다. 그리고, F20에 경우 최대 1.5m, F40 경우 0.75m의 버스길이가 허용됩니다. F20은 상당히 한계를 압박한다는 것을 알아두십시오, SCSI 버스가 전기적으로 올바른가 빨리 알 수 있습니다.

이는 버스의 몇몇 디바이스가 통신하기 위해 ‘패스트’를 사용한다면 버스는 빠른 버스를 위해 길이 제한을 철저히 지켜야한다는 것을 주의하라는 것입니다.

최근의 fast-SCSI 디바이스에서 버스 길이가 실제로 병목 현상을 일으킬 수 있음이 분명합니다. 이는 차동형 SCSI가 SCSI-2 표준에서 소개된 이유입니다.

커넥터 핀과 커넥터 유형에 대해서는 SCSI-2 표준 자체를 ( 추가 사항을 보십시오) 참조하십시오, 커넥터 등이 그 부분에 정말 자세히 설명해 놓고 있습니다.

비표준 케이블을 사용하는 디바이스에 대해 인지하고 계셔야 합니다. 예를 들어 Apple은 25핀 D-type 커넥터를 (직렬포트와 병렬 프린터에서의 그것과 같은) 사용합니다. 공식적인픓CSI 버스는 50핀을 사용한다는 것을 고려해볼 적에 이 커넥터의 사용은 몇가지 ‘독창적인 케이블 연결’을 필요로 한다것을 상상할 수 있습니다. 그와 같은 접지선(ground wire) 수의 절약은 어리석은 생각입니다, SCSI 표준과 일치하는 50핀 케이블로 연결하는 것을 지키는 것이 좋습니다. Fast-20과 40에서는 이와같은 버스는 고려조차 하고 있지 않습니다.

차동형 버스(Differential buses)
차동형 SCSI 버스 길이는 최대 25m까지 가능합니다. 단일-종단형 패스트-SCSI 버스의 3m와는 꽤 다르지요. 차동 신호의 아이디어는 각각의 버스 신호가 자신만의 회신 와이어(wire)를 가진다는 것입니다. 그래서, 각각의 신호는 (완전히 꼬여있는) 전선 뭉치로 전송됩니다. 이 두 선의 사이의 전압 차이는 신호가 사용중(asserted)인지 아니면 그렇지 않은지 검사합니다. 접지선과 신호선 간의 전압차이는 그다지 관계없습니다. (그렇더라도 10 kV 정도는 시도하지 마십시오)

이 차동형의 개념이 왜 뛰어난 것인지 설명하는 것은 이 문서의 범위를 넘어섭니다. 단지 차동 신호의 사용이 전기적으로 훨씬 더 노이즈를 줄여주는 것으로 보인다는 것을 받아들이십시오. 케비넷끼리 연결하는데 보통 차동형 버스를 볼 수 있을 것입니다. 단일종단형은 비용이 적게 들기 때문에 내부 케비넷과 같은 대체로 상당히 짧은 버스에 사용됩니다.

FreeBSD에서 디바이스 드라이버 지원을 하는 장치를 사용하는 한, 차동형 제품의 사용을 막을 이유가 없습니다. 예를 들어, Adaptec에서는 단일 종단형 기판으로 AHA1740을 판매했습니다만, 반면에 AHA1744는 차동형이었습니다. 호스트에 대한 소프트웨어 인터페이스는 둘다 동일합니다.

터미네이터(Terminators)
SCSI 전문용어로 터미네이터는 올바른 저항 배합(impedance matching)을 얻기위해 사용되는 저항회로(resistor networks)입니다. 저항 매칭은 버스에서 반사(reflections)나, 울림(ringing)이 없는 깨끗한 신호를 얻는데 중요합니다. 그리 좋지 않은 전화선으로 먼 거리의 전화를 설치했다면 아마도 반사가 무엇인지 알 것입니다. SCSI 버스에서 20MB/s의 전송속도를 얻으려면, 신호 메아리가 울리는 것을 원치는 않을 것입니다.

터미네이터는 다소 복잡한 디자인으로, 다양한 형태가 있습니다. 물론, 내부적으로 외부적으로도 그러합니다. 많은 SCSI 디바이스는 다수의 저항회로가 (반드시!) 설치되어있는 다수의 소켓으로 되어있습니다. 디바이스에서 터미네이터를 제거할 때, 조심스럽게 그것을 보관하십시오. SCSI 버스를 다시 구성하기로 했을 때, 그것이 필요할 것입니다. 정확한 대체품을 찾는 것이 전혀 불필요한 이 아 간단하고 조금한 것에도 다양한 것들이 있습니다. 또한 자체 테미네이터를 작동시키거나 않게하는 단일 점퍼를 가지고 있는 SCSI 장치도 있습니다. 플랫(flat) 케이블 버스에다가 꽂는 특별한 터미네이터도 있습니다. 외부 커넥터와 같은 것, 케이블이 없는 커넥터 후드와 같은 것도 있습니다. 찾아보면 매우 다양한 선택을 할 수 있습니다.

간단한 저항 (수동(passive)) 터미네이터에서 자동(active) 터미네이터로의 교체를 계획하거나 교체할 때 숙고해야 할 것이 있습니다. 자동 터미네이터는 깨끗한 버스 시그널을 주기위한 약간 더 복잡한 회로를 가지고 있습니다. 일반적으로 긴 버스 그리고/또는 빠른 디바이스를 사용할 때, 자동 터미네이션의 유용성이 증가한다고 평가하고 있습니다. SCSI 버스에 문제가 있을 시, 자동 터미네이터에 대해 고려해보는 것이 좋습니다. 최초의 도입 시에, 들리는 바에 따르면 상당한 비용이 든다고 합니다.

차동형과 단일-종단형 버스에 따른 터미네이터가 동일하지 않다는 것을 염두에 두십시오. 두 가지가 *섞여서는 않됩니다.*

좋습니다, 그럼 지금 어디에다 터미네이터를 장착하셨습니까? 이는 많은 이들이 SCSI에 대해 오해하는 부분입니다. 그에 비해 가장 간단한 것이기도 합니다. 원칙은: *SCSI 버스에서 모든 한 라인은 버스의 양끝에 하나씩, 2개의 터미네이터를 가진다는 것입니다.* 그래서 두개, 하나도, 세개도, 다른 어떤 것도 아닙니다. 충실히 이 원칙을 지키도록 하십시오. 그렇게 하는 것으로 끝없는 고통에서 벗어날 수 있을 것입니다, 잘못된 터미네이션은 전혀 알 수 없는 버그를 유발 할 수 있는 잠재력을 지녔기 때문이랍니다. (여기서 “잠재력”에 주의하십시오; 이 애매함은 일어날 수도 안일어날 수도 있음을 나타내는 것입니다.)

일반적인 함정은 컴퓨터 안에 내부 (플랫) 케이블이 그리고 컨트롤러에 부착되는 외부 케이블이 있다는 점입니다. 이는 컨트롤러에 있는 터미네이터를 제거해야한다는 생각을 대부분의 경우 잊어버리게 합니다. 이같은 경우 터미네이터는 컨트롤러가 아닌, 가장 마지막 외부 디바이스에 있어야 합니다! 일반적으로 SCSI 버스를 재조정할 때 항상 반드시 이에 주의를 기울여야 합니다.

터미네이션은 각각의 라인(line)을 바탕으로 되어야 한다는 점을 주의하십시오. 이는 동일 호스트 어댑터에 내로우(narrow)와 와이드(wide)가 같이 연결되어있다면 어댑터에 버스의 상위 8 bit에 대한 터미네이션을 해주어야 한다는 것입니다. (물론, 각 버스의 마지막 디바이스도 해주는 것은 당연합니다.)

필자가 행한 방식을 소개하자면, 일단 SCSI 디바이스와 컨트롤러에 있는 모든 터미네이터를 제거합니다. 필자는 외부 터미네이터를 두개 가지고 있는데, 모두 동심형 외부 케이블, 내부 플랫(flat) 케이블 커넥터에 연결하는 것입니다. 이는 재설정을 훨씬 쉽게 해 줄겁니다.

근래의 디바이스에서, 때때로 통합된 터미네이터가 사용됩니다. 이것들은 제어핀으로 설정/해제를 할 수 있는 특수 목적의 통합 회로입니다. 이는 디바이스에서 물리적으로 꼭 제거할 필요가 없습니다. 최신의 호스트 어댑터에서 이런 것을 볼 수 있는데, 때로는 일종의 설정툴을 사용해서 소프트웨어 설정이 가능합니다. 또 일부는 커넥터에 부착된 케이블을 자동으로 인식을 하고 자동으로 필요한 터미네이션을 설정합니다. 여하튼 제품 설명서를 잘 살펴보시기 바랍니다!

터미네이터 파워(Terminator power)
앞에서 얘기한 터미네이터가 정상적으로 작동케할 파워가 필요합니다. SCSI 버스에서, 라인은 이 목적에 부합되어 있다. 허, 그렇게 간단할까요?

그렇지가 않습니다. 각각의 디바이스는 디바이스에 장착되어있는 터미네이터 소켓에 터미네이터 파워를 제공할 수 있습니다. 하지만, 이미 외부 터미네이터가 있거나, SCSI 버스 라인에 터미네이터 파워를 공급하는 디바이스가 꺼져있다면 곤란하겠지요.

아이디어는 이니티에이터(initiator)들은 (이것들은 버스에서 동작을 시작하는 디바이스입니다, 뒤에 설명이 나옵니다.) 반드시 터미네이터 파워를 공급해야 한다는 것입니다. 모든 SCSI 디바이스들은 (반드시는 아니고) 터미네이터 파워를 공급할 수 있게 되어 있습니다.

버스에서 파워가 공급되지 않는 디바이스를 고려해, 터미네이터 파워는 반드시 다이오드를 통해 버스에 공급이 되어야 합니다. 이는 파워가 공급되지 않는 디바이스에 역류를 방지하기 위해서입니다.

모든 종류의 노이즈(nastiness)를 예방하기 위해, 터미네이터 파워는 잘 접지가 되어있습니다. 생각해 보았겠지만, 퓨즈는 끊어질 수 있습니다. 이는 그럴 수도 있지만, 그래서는 않되는, 동작하지 않는 버스가 되어버릴 것입니다. 복수의 디바이스가 터미네이터 파워를 공급하는 경우는, 하나정도 끊어진 퓨즈는 문제가 되지 않을 것입니다. 문제는 바로, 퓨즈가 끊어진 단일 공급장치에서 입니다. 때때로 영리한 외부 터미네이터들은 터미네이터 파워가 공급되고 있는지를 보여주는 LED 표식을 가지고 있습니다.

최근의 디자인에서 때때로 얼마 후 그것들을 ‘재설정’하는 자동-저장 퓨즈가 사용되고 있습니다.

디바이스 어드레싱(Device addressing)
SCSI 버스는, 에, 버스이기에 각각의 디바이스가 그것에 연결된 다른 디바이스간에 구분 또는 어드레싱(addressing)을 할 방법이 있어야 합니다.

이는 SCSI 또는 타겟 ID으로 해결됩니다. 각각의 디바이스는 유일한 타겟 ID를 가집니다. 점퍼를 설정하거나, 딥(dip) 스위치, 여타의 유사한 것을 사용해서 디바이스가 응답해야할 ID를 고를 수 있습니다. 일부의 SCSI 호스트 어댑터는 부트 메뉴에서 타겟 ID를 바꾸게 해줍니다. (아직 다른 것들은 타겟 ID를 7외의 것으로 바꿀 수 없습니다.(Some others will not let you change a target ID from 7)) 더 자세한 사항은 디바이스의 설명서를 보시기 바랍니다.

동일한 ID를 사용토록 설정된 다수의 디바이스를 조심하십시오. 보통 이 경우 대혼란을 초래할 것입니다. 문제는 때때로 동일한 ID를 공유하는 디바이스중 하나가 입출력 요구를 응답하려고 한다는 것입니다.

8 bit 버스에서는, 최대 8개의 타겟이 가능합니다. 최대가 8인 이유는 버스에 8개의 데이타 라인을 사용하는 bit폭으로 선택이 이루어지기 때문입니다. 와이드 버스의 경우 데이터 라인의 수에 따라 이것도 증가하게 됩니다 (보통 16).

내로우 SCSI 디바이스는 7보다 큰 타겟 ID의 SCSI 디바이스와는 교류할 수 없음을 주의하십시오. 이는 SCSI 호스트 어댑터의 타겟 ID를 7보다 큰 어떤 값으로 바꾸는 것이 그리 좋은 생각이 아님을 의미합니다. (그렇지 않으면 CD-ROM 같은 것은 동작을 멈추게 될 것입니다.)

더 높은 SCSI 타겟 ID를 가질 수록 디바이스는 더 높은 우선순위를 가지게 됩니다. 동시에 버스를 사용하려는 디바이스들을 조정할 때, 가장 높은 SCSI ID를 가진 디바이스가 우선권을 가집니다. 이는 또한 SCSI 호스트 어댑터가 보통 타겟 ID 7을 가지는 이유이기도 합니다. 그러나 wide-SCSI 버스에서 상위 8개의 ID보다는 낮은 8개의 ID가 더 높은 우선순위를 가지고 있습니다. 이렇게해서, wide-SCSI 시스템에서 타겟 ID의 순위는: [7 6 .. 1 0 15 14 .. 9 8] 순으로 됩니다. (왜 낮은 8개가 더 높은 우선순위를 가지는지 이해하지 못한다면, 힌트로 앞문장을 살펴보십시오.)

추가로, 표준은 논리 단위(Logical Units) 또는 짧게 LUN이라는 것을 고려하고 있습니다. 단일한 타겟 ID는 다수의 LUN을 가질 수 있습니다. 예를 들어, 테이프 교환기를 포함한 테이프 디바이스는 테이프 디바이스 자체에 LUN 0를 가지고, 테이프 교환기에 LUN 1을 가지게 할 수 있습니다. 이러한 방법으로 호스트 시스템은 희망하는 대로 테이프 교환기의 동작 단위마다 어드레싱(addressing)할 수 있습니다.

버스 배치
SCSI 버스는 선형입니다. 그래서, Y-접합, 별모양, 반지형, 거미집형 또는 인간이 만들어낸 여타의 어느 형태도 않됩니다. 일반적으로 일어나는 대부분의 실수 중 하나는 wide-SCSI 호스트 어댑터일 때 세개의 커넥터 (외부 커넥터, 내부 와이드 커넥터, 내부 내로우 케넥터) 전부에다 디바이스를 연결하는 것입니다. 그렇게 하는 것이 아닙니다. 이는 운이 정말로 좋으면 작동하는 것처럼 보일 수도 있지만, 확신하기를, 대단히 불운한 순간에 시스템이 동작을 멈추게 될 것입니다. (이게 바로 “머피의 법칙”이라고 알려져 있지요.)

버스가 선형이 아니라면, 앞에서 논의된 터미네이터 문제가 심각해진다는 것에 주의하십시오. 또한, 내부 SCSI 케이블에 디바이스보다 더 많은 커넥터가 있다면, 중간에 있는 커넥터를 사용하는 대신에 양끝 커넥터에 디바이스가 부착되어있는지 확인하고 한쪽이나 양쪽 끝에다 매달도록 하십시오. 이는 버스의 터미네이션조차 해결시켜 줄 것입니다.

전기적 특성상, 이것의 깨끗한 신호, 궁극적으로 신뢰성은 선형 버스 법칙에 좌우됩니다.

*선형 버스 법칙을 꼭 지키십시오!*

12.5.2.3. FreeBSD에서 SCSI 사용하기
변환, BIOS, 그리고 마법에 대해서…
앞에서 했던대로, 먼저 전기적으로 올바른 버스인지를 확인하십시오.

부트 디스크로 PC에서 SCSI 디스크를 사용하려고 할 때, PC BIOS와 관련된 몇가지 변덕에 대해 알고 있어야 합니다. 초창기 PC BIOS는 하드 디스크에 대해 저수준의 물리적 인터페이스를 사용했습니다. 그래서, (설정 툴이나 BIOS 내장 설정 프로그램을 이용해서) 디스크가 물리적으로 어떤지 BIOS에 알려 주어야 했습니다. 이는 헤드의 수, 실린더 수, 트랙당 섹터 수, 그리고 선행 보정과 감소한 현재 쓸 수 있는 실린더 (reduced write currnet cylinder) 등 불명확한 것들을 설명하는 것을 포함합니다.

누군가 SCSI 디스크는 영리하기에 이에 대해 잊고 지낼 수 있다는 것을 생각해냈는지도 모르습니다. 저런, 난해한 설정이라는 것은 오늘날에도 여전히 현존하고 있습니다. 시스템 BIOS는 부팅하는 동안 FreeBSD 커널을 읽어들이기 위해 헤드/실린더/섹터 순서로 어떻게 SCSI 디스크를 억세스할 수 있는지 알 필요가 있습니다.

그리해서 디스크를 연결한 AT/EISA/PCI/다른 어떤 버스에다 설치한 SCSI 호스트 어댑터나 SCSI 컨트롤러는 자체에 내장한 BIOS를 가지고 있는 것입니다. 시스템이 동작을 시작할 때, SCSI BIOS는 시스템 BIOS에서 하드 디스크 인터페이스 부분을 넘겨받습니다. 시스템 BIOS를 속이기위해, 시스템 설정은 보통 하드 디스크가 없는 것으로 합니다. 당연히, 그렇지 않지요?

존재합니다. 이는 PC가 드라이브를 부팅하게하는 가짜 드라이브 테이블이 구성되었음을 의미합니다. 이 변환은 자주 (항상은 아니지만) 64개의 헤드와 트랙당 32개의 섹터를 가진 가상 드라이브을 사용해 왔습니다. 실린더의 수를 바꿈으로써, SCSI BIOS는 실제 드라이브 크기에 맞춰집니다. 32 * 64 / 2 = MB 단위로 드라이브의 크기라는 것을 주의하는 것이 좋습니다. 2로 나누는 것은 크기가 512B를 디스크 블럭으로부터 KB로 환산하는 것입니다.

좋습니다. 모든 것이 지금 잘 될까요? 아니요, 그렇지 않습니다. 시스템 BIOS는 뛰어들어야 할 또다른 괴벽이 있습니다. 부팅할 수 있는 하드 디스크의 실린더 수는 1024보다 클 수가 없습니다. 위의 변환을 사용해서, 1GB보다 큰 디스크에 대해서는 이는 거대한 벽이 아닐 수 없습니다. 지속적으로 디스크의 용량이 커짐에 따라 이는 문제가 되고 있습니다.

다행이도, 해결은 간단합니다: 단지 또다른 변환을 사용하면 됩니다, 예를 들어, 32개 대신에 128개의 헤드. 대부분의 경우 오래된 SCSI 호스트 어댑터를 업그레이드하도록 새로운 SCSI BIOS 버전이 마련되어 있습니다. 일부 최근 어댑터는 SCSI BIOS가 사용할 변환을 바꾸는 점퍼나 소프트웨어 설정 선택과 같은 옵션이 있있습니다.

디스크에 있는 *모든* OS들은 적절한 파티션을 어디서 찾을 수 있을지에 대해 올바른 인식을 얻기 위해 *동일한 변환*을 사용한다는 것은 대단히 중요합니다. 그래서, FreeBSD를 설치할 때 호스트 어댑터가 사용하는 변환된 값을 사용한 헤드/실린더 등에 대해 어떤 질문이든 답해야 합니다.

변환 결과에 대해 탐색하는데 실패하는 이유는 부팅할 수 없는 시스템이거나 각각 다른 파티션을 덮어쓰는 OS때문입니다. fdisk를 사용해서 모든 파티션을 찾아볼 수 있어야 합니다.

‘장착된’ 디스크에 대해 들어본 적이 있습니까? 오래된 FreeBSD 커널은 부팅할 때 SCSI 디스크의 구조를 보고하곤 했습니다. 필자의 시스템을 예로 들면:

aha0 targ 0 lun 0: <MICROP  1588-15MB1057404HSP4>
sd0: 636MB (1303250 total sec), 1632 cyl, 15 head, 53 sec, bytes/sec 512

새로운 커널은 보통 위의 정보를 보고하지 않습니다. 예로,
  (bt0:0:0): “SEAGATE ST41651 7574″ type 0 fixed SCSI 2
  sd0(bt0:0:0): Direct-Access 1350MB (2766300 512 byte sectors)

왜 이렇게 바뀌었을까요?

이 정보는 SCSI 디스크 자체에서 검색된 것입니다. 새로운 디스크는 자주 zone bit recording이라는 기술을 사용합니다. 이 기술의 기반은 드라이브의 실린더 외곽에 공간이 더 많아서 그 자리에 더많은 트랙당 섹터가 들어갈 수 있다는 것입니다. 안쪽보다 바깥쪽 실린더가 더 많은 트랙을 가지는 디스크에서 성과는, 마지막으로 말하건데, 더 많은 용량을 가지게 된다는 것입니다. 형태(geometry)에 대해 질의할 때 드라이브에 의해 보고된 값은 현재 최상의 상태에 맞춰지게 되고, 거의 항상 오류를 포함하고 있습니다. 형태에 대해 물어 보았을 때, 거의 항상 BIOS에서 사용된 형태를 제공하는 것이 오히려 더 나으며, *BIOS가 이 디스크에 대해 알 수 없게 된다면*, (예를 들어, 이것이 부팅한 디스크가 아닌 경우) 편리한 대로 허구의 형태를 제공하는 것이 더 좋습니다.

SCSI 하부구조 디자인(SCSI subsystem design)
FreeBSD는 여러번 겹쳐진 SCSI 하부구조를 사용합니다. 각각 다른 컨트롤러 카드에 대해 디바이스 드라이가 작성됩니다. 이 드라이버는 제어할 하드웨어에 대해서 모든 세부적인 것을 알고 있습니다. 이 드라이버는 명령어를 받고 어떤 상태를 되돌려 보내는 식의 SCSI 하부구조의 상층에 대한 인터페이스를 갖추고 있습니다.

카드 드라이버의 최상층에는 디바이스의 계층에서 더욱 일반적인 드라이버들이 있습니다. 더 자세히 말해서: 테이프 디바이스에 대한 드라이버 (축약: st), 자기 디스크 (sd), CD-ROM (cd) 등등. 이 자료를 어디서 얻을 수 있는지 궁금한 경우에, /sys/scsi를 찾아보십시오. 더 자세한 사항에 대해서는 매뉴얼 페이지 섹션 4를 보도록 하십시오.

복수의 레벨 디자인은 저수준의 비트 충돌(bit banging)과 고수준 자료의 분리가 가능합니다. 하드웨어의 또다른 기기 지원을 추가하는 것은 훨씬 더 처리하기 쉬운 문제입니다.

커널 설정
하드웨어에 따라, 커널 설정 파일은 반드시 해당 호스트 어댑터를 기술한 하나 또는 여러 라인을 포함해야 합니다. 이는 I/O 어드레스, 인터럽트 등을 포함합니다. 추가 정보를 얻으러면 해당 호스트 어댑터의 메뉴얼 페이지를 잘 살펴 보십시오. 이와는 달리, 커널 설정 파일의 전반에 대해서는 /sys/i386/conf/LINT를 검토하십시오. LINT는 해볼 수 있는 모든 가능한 옵션을 포함하고 있습니다. 이는 실제로 동작하는 커널을 제공하는 것은 *아닙니다.*

그럼에도 아마 분명히 말할 수 있는 것은: 커널 설정 파일은 실제 하드웨어 설정의 반영이어야 한다는 것입니다. 그래서, 인터럽트, I/O 어드레스 등은 반드시 커널 설정 파일에 맞추어야 합니다. 시스템 부팅시 설정된 하드웨어를 실제로 발견했는지 메시지가 출력될 것입니다. EIAS/PCI 드라이버의 대부분은 (이름하기를 ahb, ahc, ncr, amd) 부팅시 자동으로 호스트 어댑터로부터 자체적으로 올바른 파라메터(parameter)를 얻게 될 것입니다; 그래서, 예를 들자면 “controller ahc0″와 같이 쓰기만 하면 됩니다.

몇가지 추가 주석을 갖춘 FreeABSD 2.2.5-Release 커널 설정 파일 LINT에 기반한 예제 일부 ([] 사이):

# SCSI host adapters: `aha’, `ahb’, `aic’, `bt’, `nca’
#
# aha: Adaptec 154x
# ahb: Adaptec 174x
# ahc: Adaptec 274x/284x/294x
# aic: Adaptec 152x and sound cards using the Adaptec AIC-6360 (slow!)
# amd: AMD 53c974 based SCSI cards (e.g., Tekram DC-390 and 390T)
# bt: Most Buslogic controllers
# nca: ProAudioSpectrum cards using the NCR 5380 or Trantor T130
# ncr: NCR/Symbios 53c810/815/825/875 etc based SCSI cards
# uha: UltraStore 14F and 34F
# sea: Seagate ST01/02 8 bit controller (slow!)
# wds: Western Digital WD7000 controller (no scatter/gather!).
#

[For an Adaptec AHA274x/284x/294x/394x etc controller]
controller ahc0

[For an NCR/Symbios 53c875 based controller]
controller ncr0

[For an Ultrastor adapter]
controller uha0 at isa? port “IO_UHA0″ bio irq ? drq 5 vector uhaintr

# Map SCSI buses to specific SCSI adapters
controller scbus0 at ahc0
controller scbus2  at ncr0
controller scbus1  at uha0

# The actual SCSI devices
disk sd0 at scbus0 target 0 unit 0 [SCSI disk 0 is at scbus 0, LUN 0]
disk sd1 at scbus0 target 1  [implicit LUN 0 if omitted]
disk sd2 at scbus1 target 3  [SCSI disk on the uha0]
disk sd3 at scbus2 target 4  [SCSI disk on the ncr0]
tape st1 at scbus0 target 6  [SCSI tape at target 6]
device cd0 at scbus?   [the first ever CD-ROM found, no wiring]

위의 예제는 커널이 ahc (Adaptec 274x) 컨트롤러, 그후 NCR/Symbios 보드, 등을 찾게 하고 있음을 보여줍니다. 컨트롤러 특성을 담은 라인에서 커널이 특정 디바이스를 설정하게 하고있지만 *오직* 일치하는 버스에서 정해진 타겟 ID와 LUN을 맞을 때에만 부착될 것입니다.

등록된 (wired down) 디바이스는 ‘등록’되지 않은 디바이스에 앞서서 유닛 넘버에 ‘우선 순위(first shot)’를 가지게 되는데 이에 ‘등록’되지 않은 디바이스는 디바이스의 종류에 따라 가장 높은 ‘등록된’ 유닛의 번호보다 더 큰 유닛 번호가 할당됩니다. 그래서, 타겟 ID 6에 테이프가 유닛 넘버(unit number) 1에 i 등록되어있으니, 타겟 ID 2에 SCSI 테이프가 있다면 st2로 설정이 될 것입니다. 유닛 번호를 찾기 위해 *등록된 디바이스는 탐색되어야 할 필요가 없음을* 주의하십시오. 등록된 디바이스의 유닛 번호는, 설사 부팅 시에 켜있지 않았더라도 그 디바이스에 이미 지정됩니다. 이는 디바이스가 리부팅을 하지 않고도 나중에 켜서 사용할 수 있도록 합니다. 디바이스의 유닛 번호는 결코 SCSI 버스 상의 타겟 ID와 연관성이 *없음을* 명심하십시오.

아래에는 FreeBSD 2.0.5 이하 버전에서 사용되는 커널 설정 파일의 예제입니다. 앞 예제와 다른점은 디바이스가 ‘등록’되지 않았다는 것입니다. ‘wired down’이라는 것은 어떤 SCSI 타겟에 어떤 디바이스를 할당하겠는지 정해주는 것을 의미합니다.

아래 설정 파일로 만들어진 커널은 탐색한 첫번째 SCSI 디스크에 sd0를, 두번째 디스크에 sd1 등으로 정해줍니다. 만일 디스크를 제거하거나 추가하는 경우에, 동일한 타입의 디바이스들은 (이 경우 디스크) ‘옮겨져’ 버릴 것입니다. 이는 매번 /etc/fstab를 바꾸어 주어야 한다는 것입니다.

비록 이전 양식으로 여전히 쓸 수 있지만, 위의 새로운 방식으로 쓰기를 *강력하게* 주장합니다. 이는 SCSI 버스에서 하드웨어를 옮길 때마다의 많은 고통을 덜어 줄 것입니다. 그래서, FreeBSD2.0.5.R 이전 시스템에서 업그레이드를 한 후 오래되고도 충실한 설정 파일을 재사용할 때 이를 검토하시기 바랍니다.

[driver for Adaptec 174x]
controller      ahb0    at isa? bio irq 11 vector ahbintr
[for Adaptec 154x]
controller      aha0    at isa? port “IO_AHA0″ bio irq 11 drq 5 vector ahaintr
[for Seagate ST01/02]
controller      sea0    at isa? bio irq 5 iomem 0xc8000 iosiz 0×2000 vector seaintr
controller      scbus0

device          sd0 [support for 4 SCSI harddisks, sd0 up sd3]

device          st0 [support for 2 SCSI tapes]

[for the CD-ROM]
device          cd0     #Only need one of these, the code dynamically grows

두 예제 모두 SCSI 디스크를 지원합니다. 부팅시에 부팅 커널에서 정해준 것보다 특정 형태의 (예를 들어 sd 디스크) 디바이스가 더 발견이 되면, 시스템은 간단하게 ‘등록’된 마지막 번호에서 시작하는 유닛 번호를 증가시켜, 추가 디바이스를 할당할 것입니다. ‘등록’된 디바이스가 없으면, unit 0에서 시작하게 됩니다.

SCSI 하부구조에 대해 최근 정보를 검토하려면 man 4 scsi를 사용하십시오. 호스트 어댑터 드라이버에 대한 보다 자세한 정보에 대해서는 Adaptec 294x 드라이버에 대한 정보인 man 4 ahc 예제를 이용하십시오.

SCSI 커널 설정 조정
(부팅시에 일어난) SCSI 버스 재설정 후 INQUIRY 명령에 대한 응답에 일부 디바이스가 느리다는 실험 결과가 나왔습니다. INQUIRY 명령어는 특정 타겟 ID에 어떤 종류의 디바이스가 (디스크, 테이프, CD-ROM 등) 연결되어있는지 확인하기 위해 부팅시에 커널이 보냅니다. 이 처리는 말이 나온 김에 말하면 디바이스 검사(device probing)라고 불립니다.

‘늦은 응답’을 해결하기 위해, FreeBSD는 SCSI 디바이스가 SCSI 버스 재설정을 따라 검사되기 전에 조정할 수 있는 지연 시간을 허용하고 있습니다. 다음과 같은 라인을 커널 설정 파일에 추가해서 이 지연 시간을 설정할 수 있습니다.

options         SCSI_DELAY=15         #Be pessimistic about Joe SCSI device

여기서는 지연 시간을 15초로 하고 있습니다. 필자의 시스템의 경우, 충실하고도 오래된 CD-ROM이 인식되기에는 최소 3초가 필요합니다. 디바이스 인식에 문제가 있는 경우 높은 값으로 (30초 쯤으로) 해 보십시오. 이래서 해결이 된다면, 동작이 되게끔 계속 조정하십시오.

부랑자 SCSI 디바이스
비록 SCSI 표준은 완벽하고 간결하고자 하지만, 이는 대단히 복잡한 표준이며 옳게 구현하는 것은 그리 쉬운 일이 아닙니다. 일부의 회사는 다른 곳보다 더좋게 처리하고 있습니다.

이는 정확히 ‘부랑자’ 디바이스가 어디서 보이는가 하는 점입니다. 부랑자란 FreeBSD에서 약간(…) 비표준으로 작동하는 것으로 인식되는 디바이스를 말합니다. 부랑자 디바이스는 부팅시 커널에서 보고합니다. 필자의 카트리지 유닛 두개에 대한 예제입니다:

Feb 25 21:03:34 yedi /kernel: ahb0 targ 5 lun 0: <TANDBERG TDC 3600       -06:>
Feb 25 21:03:34 yedi /kernel: st0: Tandberg tdc3600 is a known rogue

Mar 29 21:16:37 yedi /kernel: aha0 targ 5 lun 0: <ARCHIVE VIPER 150  21247-005>
Mar 29 21:16:37 yedi /kernel: st1: Archive  Viper 150 is a known rogue

예를 들어, 실제로는 오직 하나의 디바이스임에도, 어떤 타겟 ID에서 모든 LUN으로 응답하는 디바이스가 있습니다. 커널이 그 특정 타겟 ID에 8개의 LUN이 있다고 믿는 어리석은 짓을 하는 것을 보는 것은 쉽습니다. 이것이 일으킨 혼동을 예상하는 것은 독자에게 맏기겠습니다.

FreeBSD의 SCSI 하부구조는 검색시 그것들이 보내는 INQUIRY 응답을 찾는 그리 안좋은 기법으로 디바이스를 인식합니다. INQUIRY 응답은 또한 디바이스 펌웨어 버전 번호도 포함하고 있어, 다른 펌웨어 버전에 대해 다른 동작기반이 사용될 수도 있습니다. 위의 것이 어떻게 동작하는 지에 대한 더 자세한 정보는 예제 /sys/scsi/st.c와 /sys/scsi/scsiconf.c을 참고하십시오.

이 구성은 잘 동작하지만, 또한 이는 기묘하다고 *알려진* 디바이스도 동작한다는 것을 염두에 두십시오. 우선 엉터리 Mumbletech SCSI CD-ROM을 연결하고자 하면 필요한 동작기반을 정의해야만 할 것입니다.

Mumbletech가 작동한다면, FreeBSD의 다음 배포본에 추가하겠으니 FreeBSD 개발팀에 요구된 동작기반을 보내주셨으면 합니다. 다른 Mumbletech 소유자들이 당신에게 대단히 고마워할 것입니다.

복수의 LUN 디바이스
가끔 하나의 SCSI ID에 복수의 논리 유닛을 (LUN) 사용하는 디바이스를 다루기도 할 것입니다. 대부분의 경우 FreeBSD는 오직 LUN 0에 대한 디바이스만을 인식합니다. SCSI 버스에 SCSI 방식이 아닌 하드디스크 두개를 연결시켜주는 브릿지 보드와 (예로, 오래된 Sun 시스템에 들어있는 Emulex MD21) 같은 경우를 말합니다.

이는 LUN이 0이 아닌 다른 디바이스들은 시스템이 부팅 때, 디바이스 인식과정에서 정상적으로 발견되지 않는다는 것을 뜻합니다. 이 문제를 해결하려면 반드시 /sys/scsi/scsiconf.c에 적절한 엔트리를 추가해서 커널을 다시 만들어야 합니다.

아래와 같이 초기화된 구조를 보십시오:

   {
                T_DIRECT, T_FIXED, “MAXTOR”, “XT-4170S”, “B5A”,
                “mx1″, SC_ONE_LU
          }

하나 이상의 LUN을 가지고 있고, SCSI 하드로 작동하며, 펌웨어 리비전(revision)이 123을 가지고 있는 Mumbletech BRIDGE2000의 경우, 다음의 것들을 추가해야합니다:

   {
                T_DIRECT, T_FIXED, “MUMBLETECH”, “BRIDGE2000″, “123″,
                “sd”, SC_MORE_LUS
          }

부팅 시 커널은 테이블에서 받은 질의 데이터를 찾고 그에 따라 동작합니다. 더 자세한 것은 소스를 보도록 하십시오.

덧붙인 명령어 큐잉(Tagged command queueing)
근래의 SCSI 디바이스는, 특히 자기 디스크는 덧붙인 명령어 큐잉 (tagged comand queuing) (TCQ) 라는 것을 지원합니다.

간략하자면, TCQ는 디바이스가 동시에 다수의 I/O 요구가 발생하는 것을 허용합니다. 디바이스는 지능적이기에, 자신의 요구 큐에 기반한 그 동작을 (헤드 위치지정과 같은) 최적화할 수 있습니다. RAID (Redundant Array of Independent Disk) 어레이와 같은 SCSI 디바이스에서 TCQ 기능은 디바이스의 타고난 병렬주의를 이용할 때 없어서는 곤란할 정도입니다.

각각의 I/O 요구는 ‘태그’에 의해 (그러니가, 이름하기를 tagged command queuing) 유일하게 명시되고 이 태크는 FreeBSD에서 디바이스 드라이버 큐에서 어떤 I/O이 디바이스가 완벽하다고 보고하는지 찾기위해 사용됩니다.

그러나, TCQ는 디바이스 드라이버가 지원해야 한다는 것과 일부 디바이스는 펌웨어에서 ‘충실하지 않게’ 구현하고 있음을 반드시 숙지하고 있어야 합니다. 이 문제는 필자를 골치아프게 하고 있으며, 대단히 이해할 수 없는 문제를 야기하고 있습니다. 그런 경우라면, TCQ를 사용하지 마십시오.

버스마스터 호스트 어댑터
대부분, 다는 아니지만, SCSI 호스트 어댑터는 버스 마스터링 컨트롤러입니다. 이는 데이터 전송에 있어서 호스트 CPU 부하를 가중하지 않고 자체적으로 I/O을 할 수 있다는 것입니다.

이는 물론 FreeBSD 같은 멀티테스킹 OS에서 이득이 됩니다. 그러나, 좀은 불완전한 부분이 있음을 주의해야 합니다.

예를 들자면 Adaptec 1542 컨트롤러는 호스트 버스에 (이 경우 ISA 또는 AT) 다른 전송 속도를 설정해 줄 수 있습니다. 컨트롤러는 모든 마더보드가 더 높은 속도를 관리할 수 있는 것은 아니기에 다른 비율로 설정할 수 있도록 해놓았습니다. 연결 장애, 올바르지 않은 데이터 같은 문제는 마더보드가 소화할 수 있는 전송속도보다 더 높은 속도를 사용할 때의 결과입니다.

해결은 물론 명백합니다: 더 낮은 전송률로 바꾸고 더 잘 작동하는지 검사하는 것입니다.

Adaptec 1542와 같은 경우, 가능한 가장 빠른 전송률의 쓰기, 읽기를 동적으로 검사하도록 커널 설정 파일에 넣을 수 있는 옵션이 있습니다. 기본적으로 이 옵션은 설정되어 있지 않습니다:

options        “TUNE_1542″             #dynamic tune of bus DMA speed

사용하는 호스트 어댑터에 대한 메뉴얼 페이지를 검사하십시오. 더 나은 방법으로, 궁극의 문서를 (드라이버 소스를 읽으세요) 사용하십시오.

12.5.2.4. 문제의 추적
다음의 목록은 대부분 일반적인 SCSI 문제와 그 해결에 대한 지침을 주기 위한 시도입니다. 이것은 완벽하고는 거리가 멉니다.

느슨한 커넉터와 케이블을 검사하십시오.
터미네이션의 위치와 숫자를 검사 또 검사하십시오.
적어도 하나의 터미네이터 파워 공급장치가 (특히 외장 터미네이터) 있는지 검사하십시오.
타겟 ID가 겹치게 사용되지는 않은지 검사하십시오.
사용되는 모든 디바이스가 켜져있는지 확인하십시오.
가능한 적은 디바이스에 맞춰 최소한의 버스 설정을 만드십시오.
가능하다면 호스트 어댑터가 느린 버스 스피드를 사용하도록 설정하십시오.
가능한 간단하게 구성하기 위해 TCQ 기능을 사용하지 마십시오 (시스템에 기반한 NCR 호스트어댑터에 대해서는 man ncrcontrol을 해 보십시오)
커 널 컴파일을 할 수 있으면, SCSIDEBUG 옵션을 넣은 것을 하나 만들고, 그 디바이스에 대한 돌려진 디버깅에서 디바이스를 억세스 하도록 해보십시오. 시작시에 디바이스가 전혀 인식이 않되면, 실패한 디바이스의 주소를 정의해야할수도, 그리고 /sys/scsi/scsidebug.h에 희망하는 디버그 수준을 정해 주어야 합니다. 인식은 되지만 작동하지 않으면, 동작하는 커널에서 (SCSIDEBUG가 정의되어 있으면) 동적으로 디버그 수준을 그것에다 정해주도록 scsi(8) 명령을 사용할 수 있습니다. 이는 권위자조차 혼란시킬 수 있는 *엄청난* 디버깅 출력을 줄 수 있습니다. 더욱 정확한 정보는 man 4 scsi를 보십시오. 또 man 8 scsi을 찾아 보도록 하십시오.

12.5.2.5. 추가 사항
혹시나 당신이 몇가지 심각한 SCSI 해킹을 하려면, 공식적인 표준을 손을 쥐어야 할 겁입니다.

승인된 미국 국가 표준은 11 West 42nd Street, 13th Floor, New York, NY 10036, Sales Dept: (212) 642-4900의 ANSI로부터 구입할 수 있습니다. Global Engineering Documents, 15 Inverness Way East, Englewood, CO 80112-5704, Phone: (800) 854-7179, Outside USA and Canada: (303) 792-2181, FAX: (303) 792-2192로부터 많은 ANSI 표준도 살 수 있고 대부분의 위원회 드래프트 문서(committee draft documents)를 살 수도 있습니다.

SCSI BBS (719-574-0424)와 ncrinfo.ncr.com anonymous ftp 사이트에서 많은 X3T10 드래프트 문서를 전자적으로 사용이 가능합니다.

최신의 X3T10 위원회 문서는:

AT Attachment (ATA or IDE) [X3.221-1994] (Approved)
ATA Extensions (ATA-2) [X3T10/948D Rev 2i]
Enhanced Small Device Interface (ESDI) [X3.170-1990/X3.170a-1991] (Approved)
Small Computer System Interface – 2 (SCSI-2) [X3.131-1994] (Approved)
SCSI-2 Common Access Method Transport and SCSI Interface Module (CAM) [X3T10/792D Rev 11]
추가적인 정보를 제공하는 다른 문건:
“SCSI: Understanding the Small Computer System Interface”, written by NCR Corporation. Available from: Prentice Hall, Englewood Cliffs, NJ, 07632 Phone: (201) 767-5937 ISBN 0-13-796855-8
“Basics of SCSI”, a SCSI tutorial written by Ancot Corporation Contact Ancot for availability information at: Phone: (415) 322-5322 Fax: (415) 322-0455
“SCSI Interconnection Guide Book”, an AMP publication (dated 4/93, Catalog 65237) that lists the various SCSI connectors and suggests cabling schemes. Available from AMP at (800) 522-6752 or (717) 564-0100
“Fast Track to SCSI”, A Product Guide written by Fujitsu. Available from: Prentice Hall, Englewood Cliffs, NJ, 07632 Phone: (201) 767-5937 ISBN 0-13-307000-X
“The SCSI Bench Reference”, “The SCSI Encyclopedia”, and the “SCSI Tutor”, ENDL Publications, 14426 Black Walnut Court, Saratoga CA, 95070 Phone: (408) 867-6642
“Zadian SCSI Navigator” (quick ref. book) and “Discover the Power of SCSI” (First book along with a one-hour video and tutorial book), Zadian Software, Suite 214, 1210 S. Bascom Ave., San Jose, CA 92128, (408) 293-0800

Usenet 뉴스그룹에는 comp.preiphs.scsi와 comp.preiphs이 추가 정보를 찾아볼 수 있는 두드러진 장소입니다. 또 거기에서 SCSI-Faq를 찾아볼 수 있는데, 이는 정기적으로 포스팅 됩니다.

ECC 메모리

패리티 메모리

PC가 출시되었던 초기에는 메모리의 오류를 막기 위해서 모든 컴퓨터에 패리티 방식이 사용되었다. 패리티라는 것은 8bit당 1bit의 패리티 비트를 두어서 데이터의 전달과정중에 오류가 생긴 것을 검출하는 방식을 지칭한다. 즉, 시스템에서 나타날 수 있는 오류를 방지하고자 패리티 메모리를 포함시켰고, 이것은 그 역할을 충분히 해냈다.

그런데, 1994년부터 분위기가 조금씩 달라졌다. 메모리 기술의 발달로 메모리의 오류 발생 확률이 점점 적어지자 일부 PC 제조사에서 패리티가 포함되지 않은 메모리를 탑재한 컴퓨터를 내놓기 시작한 것이다. 물론 오류 발생 확률은 일반 사용자들이 신경쓸 필요가 없을 정도로 적었으며, 패리티를 제거함으로써 패리티 메모리에 필요한 약 10~15%의 추가 메모리 비용 부담을 줄일 수 있어서 제조사 측에서는 즐거운 일이었다. 하지만, 대단히 중요한 데이터를 다루는 사용자들에게는 역시 패리티는 필요한 것이었으며 그러한 사용자는 별도로 요청을 해야만 했다.

이러한 추세를 급격히 가속시킨 것은 일부 대형 PC 제조사들이 패리티가 없는(넌패리티 : non-parity) 메모리를 탑재한 채로 PC를 출하한 것이다. 대형 PC 제조사들이 이러한 정책을 펴나가자 너도나도 이 정책을 따랐으며, 그 결과 넌 패리티 메모리가 거의 표준으로 굳어진다. 그리고 이것을 완전히 굳어지게 한 것이 인텔의 430FX 칩셋의 출시였다.

인텔 430FX 칩셋은 아예 패리티라는 것을 지원하지 않았다. 칩셋 레벨에서의 패리티 지원은 사실 원가상승에는 그다지 기여하지 않는다. 있으나 없으나 가격은 어차피 비슷하며, 회로도 복잡하지 않기에 만들기도 만만했다. 하지만 430FX는 패리티를 외면해버렸고, 인텔이 그러한 정책을 펼치자 다들 그냥 그러려니 하고 이를 따라갔다. 결국 일반 사용자용 메모리에서는 패리티가 사라졌고, 이것은 ECC까지 그대로 이어졌다.

하지만, 웍스테이션이나 서버, 그리고 대단히 중요한 작업을 하는 시스템들은 가격보다는 시스템의 안정성과 신뢰도가 절대적으로 우선되기 때문에 패리티 메모리나 ECC 메모리를 요구한다.

패리티 메모리와 ECC 메모리의 원리

SDRAM이 나오기 전까지, EDO 메모리나 FPM 등이 사용한 에러 정정방식은 패리티(parity) 방식이었다. 이것과 지금의 ECC를 혼동하는 사용자들도 많다. 우선 패리티가 무엇인지부터 정리해보자.

패리티의 원리는 다음과 같다.

PC에서 사용되는 것은 홀수 패리티(odd parity)이다. 홀수 패리티라는 것은 전송되는 데이터들의 합이 홀수가 되도록 패리티 비트가 정해진다.(보다 정확하게는, 전체의 XOR 값이 1이 되어야 한다고 정의된다. 그러나 이해를 편하게 하기 위해서 전체 합을 홀수가 되어야 한다는 것으로 표현하였다.) 예를 들어서 다음과 같은 데이터가 전송된다고 하자.

 parity0

전송되는 8bit 내에 1이 다섯개 있어서 전체의 합은 홀수가 된다. 이를 홀수로 유지시키기 위해서는 0이 더해져야만 하며, 그래서 패리티 비트가 0이 된다. 한편, 데이터 안에 1이 짝수개가 있다면 패리티 비트가 1이 되어서 전체의 합을 홀수로 유지시킨다.

 parity1

데이터를 수신하는 측에서는 수신된 데이터와 패리티 비트를 합해서 그 결과가 홀수가 나오는지, 짝수가 나오는지를 살펴보고, 홀수가 나온다면 무사히 지나가고 짝수가 나온다면 사용자에게 에러가 발생했다는 것을 통보한다.

패리티를 사용하면 시스템의 어디서 문제가 발생했는지를 검출할 수 있다. 데이터가 전달되는 부분마다 패리티 검사를 수행하기 때문에 만약 메모리 컨트롤러에서 문제가 생겼는지, 메모리 자체에서 문제가 생겼는지 등이 검출되어서 시스템을 수리하는 과정도 보다 용이해진다.

물론 단점도 있다. 만약 2개의 bit에서 동시에 문제가 발생했다면, 데이터에 문제가 있다고 할지라도 데이터의 합계의 홀/짝은 그대로 유지된다. 즉, 이러한 경우에는 데이터 오류가 검출되지 않는다. 물론, 메모리 자체의 오류도 적게 일어나거니와, 전체 메모리 오류 중에서 97% 이상이 단일 bit에서 발생하는 문제이기 때문에 패리티가 잡아낼 수 없는 문제점은 거의 없다고 보아도 좋다. 그러나 확률적으로 문제가 있는 데이터가 그대로 전달되는 상황이 발생하기도 한다.

이러한 문제를 해결한 것이 ECC(Error Correcting Code)이다. ECC는 단지 에러를 검출하기만 하는 패리티에서 대폭 향상되어서 단일 bit의 에러에 대해서는 이를 검출하여 직접 교정할 수 있는 능력을 가지고 있다. 즉, 패리티에서는 데이터에 오류가 있을 경우 이의 재전송을 요구하거나 동작을 중지하였던 것에 반해서 절대 다수를 차지하는 단일 bit의 에러에서는 시스템의 정지 없이 바로 교정하면서 연속적인 동작이 가능하다.

ECC의 종류에는 여러가지가 있는데, PC용 메모리에 적용되어 있는 ECC는 ‘단일 bit 에러 교정, 2bit 에러 검출(SEC-DED : Single-bit Error Correcting, Double-bit Error Detecting)’ 방식이다. 그래서 하나의 bit에서 문제가 발생했다면 이를 직접 교정하고, 2개의 bit에서 문제가 발생한다고 해도 이를 검출하여 사용자에게 통보할 수 있다.

ECC의 구현원리는 다음과 같다.

먼저, 데이터를 기록할 때, 메모리 컨트롤러는 체크 비트를 만들어내어 이를 같이 기록한다.

 ecc_input

이때 만들어진 체크 비트는 메모리에 같이 저장되었다가 이를 메모리 컨트롤러가 읽어낼 때 같이 읽혀진다.

 ecc_output

이 과정에서, 메모리 컨트롤러는 저장되어 있는 데이터와 체크 비트를 비교하면서 서로 맞는 것인가를 확인한다. 이 때, 데이터와 체크 비트가 서로 맞는 것이라면 그대로 데이터가 출력되고, 만약, 데이터 내에 1bit의 오류가 발생했다면 이를 자동으로 정정한다. 2bit 이상의 오류가 발견될 경우 이를 사용자에게 알리고 그 이상의 시스템 운영을 정지시킨다.

그래서 ECC 메모리는 패리티에 비해서 높은 데이터 신뢰도를 구현하면서 동시에 단일 bit에 대해서는 직접적으로 정정을 수행함으로 인해 성능저하를 줄일 수 있게 되었다.

물론, ECC 메모리 컨트롤러 내에서 체크 비트를 연산하고, 이를 사용하여 검사하는 과정에서 성능의 하락이 일어난다. 하지만 이것은 수 % 내외이므로 큰 폭의 성능하락은 일어나지 않으며, 안정성의 극대화라는 측면에서 본다면 실보다는 득이 훨씬 크다.

SIMM에서는 패리티이고, DIMM에서는 ECC가 사용된다는데..

simm
이제는 과거의 유물이 되어버린 72pin SIMM

i430TX 칩셋까지 사용되었던 72pin SIMM과 현재 사용되고 있는 168pin SDRAM DIMM 및 184pin DDR SDRAM DIMM의 근본적인 차이점은 단면(SIMM – Single Inline Memory Module), 양면(DIMM – Double~) 이라는 차이 외에도, 메모리 인터페이스의 폭에 있다. 72핀 메모리는 32bit의 메모리 버스를 가졌고, DIMM은 64bit의 메모리 버스를 가지고 있었다.(펜티엄에 72pin 메모리를 사용하기 위해서 2개의 메모리를 꽂는 것은 바로 이 버스 폭을 맞추기 위함이었다. 펜티엄 프로세서는 64bit의 메모리버스를 갖고 있기 때문이다. 즉, 당시의 72pin 메모리는 듀얼채널로 동작했다는 놀라운 사실!!!)

패리티의 경우 8bit당 1bit의 패리티 비트를 필요로 한다. 버스폭이 넓어진다면 이 역시 16bit에 2bit, 64bit에 8bit 하는 식으로 커지면 된다. 그런데, ECC는 연산 방법이 좀 복잡해서, 32bit의 메모리가 한번에 전송된다면 여기에 7bit의 체크 비트를 필요로 한다. 만약, 32bit의 버스폭을 가지는 메모리에서 32MB의 메모리 용량을 구현한다면 여기에 7MB의 메모리가 추가로 장착되어야만 ECC가 구현된다는 것이다. 한편, 64bit가 한번에 전송된다면 8bit의 체크 비트를 필요로 한다. 이것은 결국 패리티와 같은 수준의 추가 메모리만을 요구한다는 것이다.

이러한 이유 때문에, 32bit의 버스폭을 갖는 72핀 메모리에서는 패리티가 사용되었지만, 64bit의 버스폭을 갖는 168핀 DIMM 부터는 패리티 대신에 ECC가 사용되고 있는 것이다.

레지스터드 메모리가 그러한 이름으로 불리는 이유는 지극히 간단하다. 바로 레지스터(Register)가 달려있기 때문이다. 흔히, 레지스터드 메모리를 ECC 메모리와 혼동하는 경우가 있는데, 레지스터드 메모리와 ECC 메모리는 바로 레지스터의 유무를 보고 쉽게 분간할 수 있다.

대개 서버용으로 ECC가 사용되기도 하고 레지스터드 ECC가 사용되기도 한다는 점이 이러한 혼란에 일조하기도 하지만, 모든 레지스터드 메모리가 기본적으로 ECC가 적용된 것이기 때문에 ‘레지스터드’ 대신 ‘레지스터드 ECC’ 메모리라고도 불리고 있다는 것도 이러한 혼란을 불러일으키는 이유이다.

하지만, ECC와 레지스터드의 개념을 확실히 알고 있다면 외형적으로 완전히 틀리는 이들 메모리를 분간하지 못할 까닭은 없다.

레지스터와 레지스터드 메모리

레지스터의 역할은 신호왜곡(skew)의 제거, 쉽게말하면 신호의 정렬이며, 이는 곧 메모리 칩의 제어를 의미한다.

 module_register

즉, 간소화된 메모리 컨트롤러가 메모리 모듈 상에 위치한다고 보면 된다. 이러한 구성은 시스템의 수준에서, 그리고 메모리 모듈 자체의 수준에서 각각 한가지씩의 잇점을 제공한다.

일반적인 언버퍼드 메모리의 경우 각 메모리 디바이스까지도 칩셋의 메모리 컨트롤러가 담당하는 구조를 가진다.

reg_unbuffered

이러한 구조는 전체적인 구조가 간소화되며, 빠른 동작을 기대할 수 있다는 잇점을 가지지만, 반대로, 메모리 컨트롤러 하나가 모든 메모리 디바이스까지 직접 제어해야 하기 때문에 메모리의 확장이 쉽게 한계에 다다른다. 특히나 메모리의 속도가 빨라질수록 메모리의 타이밍이 대단히 민감해지기 때문에 컨트롤러 하나로 모든 메모리를 제어하는 방법에서는 다룰 수 있는 메모리 디바이스의 제한이 더욱 심해진다.

일반 사용자들이라면야 2개 혹은 3개의 모듈을 사용해도 별 상관이 없지만 수십 GB급의 고용량을 필요로 하는 서버 및 그에 준하는 시스템에서는 언버퍼드 메모리로는 메모리 확장에 답답함을 느낄수밖에 없다.

한편, 레지스터드 메모리는 이러한 문제점을 상당부분 해소한다.

 reg_registered

각 메모리 디바이스의 제어는 메모리 모듈에 탑재된 레지스터에서 행하고 있기 때문에 메인 칩셋에 있는 메모리 컨트롤러는 단지 레지스터들만을 제어하면 된다. 이는 메모리 컨트롤러의 설계를 대단히 단순하게 바꿀 수 있을뿐만 아니라 메모리 모듈을 보다 많이 사용하게 해 줌으로써 대용량 메모리의 구현이 가능해진다.

또한, 메모리 모듈 자체에서 얻을 수 있는 잇점도 있다. 일반적으로 하나의 메모리 모듈에 탑재할 수 있는 메모리 칩의 개수는 한 면에 8개, ECC 칩까지 포함해서 9개이다. 그리고 양면 구성으로 18개까지가 가능하다. 현재 가장 많이 사용되는 메모리 칩의 용량은 256Mbit. 이 칩으로 단면 메모리를 구성하면 256MB가 된다. 그리고 양면 메모리를 만들면 512MB. 만약 1GB 용량의 모듈을 만들고 싶다면 어떻게 해야할까. 한 면에 9개의 칩이 아닌, 18개의 칩이 장착되어야만 한다.

이러한 구성을 위해서, 메모리는 복층구조, 혹은 다열구조를 가져야만 한다. 그러나 복층/다열구조를 가지게 된다면 문제가 발생한다. 바로 메모리의 위치 때문이다.

간단히 생각해 본다면, 메모리를 2열로 구성하면 메모리 용량이 2배가 되기는 한다. 이러한 구조가 되면서 메모리 디바이스의 수가 많아지고, 컨트롤러에서 이들 메모리를 제어하는게 힘들어진다는 것은 쉽게 생각할 수 있다. 그런데, 한가지 문제가 더 발생하는데, 바로 신호왜곡(skew)이 상당히 커진다는 것이다.

메모리 칩으로부터 모듈이 보드에 연결되는 핀까지의 거리가 윗 열과 아랫 열의 메모리 사이에 엄청난 차이가 생긴다. 안그래도 높은 클럭으로 인해서, 그리고 64bit라는 넓은 버스로 인해서 신호왜곡은 상당히 민감한 문제가 되고 있는데도 불구하고 여기에 어려움을 주는 대단히 큰 요소가 하나 더 등장한 것이다. 여기에 레지스터가 개입됨으로써 문제는 해소될 수 있다.

 registered_skew

레지스터는 각 메모리 디바이스를 제어함과 동시에, 메모리 디바이스들로부터 신호를 받아서 이들의 타이밍을 재조정하여 출력함으로써 내부적으로 발생하는 신호왜곡을 제거하는 효과를 가진다. 대신, 레지스터드 메모리에서는 속도의 저하가 일어난다.

레지스터에서 각 칩의 신호들을 정렬하기 위해서는 한번의 클럭을 필요로 한다. 즉, 데이터의 전송과정에서 레지스터가 ‘까먹는’ 클럭이 생기는 것이다. 이 때문에 레지스터드 메모리는 언버퍼드 메모리에 비해서 약간 낮은 성능을 갖는다. 일반 사용자들용 제품군에 레지스터드 메모리를 사용하지 않으려는 것은 가격도 가격이지만, 이러한 성능의 차이 때문이기도 하다.

여하튼, 이러한 특징으로 인해 레지스터드 메모리는 다열구조나 복층구조는 물론이며, 메모리 칩의 배치에서 상당한 다양성을 가질 수 있게 되며, 다수의 메모리 칩을 장착함으로써 대용량의 메모리를 만들 수 있다. 아래의 사진들은 그러한 ‘다양한’ 메모리 배치의 사례를 보여주고 있다.

레지스터드 메모리의 반대말은 언버퍼드 메모리라고?

이제 레지스터드 메모리가 어떤 것인지 독자분들도 어느정도 감을 잡았을 것이라고 생각한다. 그런데, 분명 이러한 생각을 가지는 독자가 있을 것이다. ‘레지스터드의 반대말이 왜 언버퍼드인가? 언레지스터드가 아닌가? 또한, 언버퍼드의 반대말은 버퍼드가 되어야하지 않는가?’라고.

분명히 생길 수 있는 의문점이다.

이것은 이전부터 이어져내려온 관례라고 생각하는 것이 좋다. EDO 메모리가 한창 사용되던 때에 사용된 서버용 메모리는 ‘버퍼드(buffered)’라고 불렸다. 여기에서의 버퍼 역시 지금의 레지스터와 거의 유사한 역할을 한다. 그래서 이러한 메모리의 반대되는 말로 ‘언버퍼드(unbuffered)’가 사용되었다.

이후에, EDO 메모리의 영역을 SDRAM이 대체하게 되면서, 버퍼드 메모리는 레지스터드 메모리로 바뀌었다. 이것은 EDO 메모리와 SDRAM 간의 특성 차이로 인해서 이름이 변경된 것인데, 일반 사용자용 언버퍼드 메모리들은 어차피 달라지는 것이 거의 없어서 그대로 언버퍼드 메모리로 불리게 되었다.

결국, 현재에 이르러서도 ‘언레지스터드-레지스터드’가 아닌, ‘언버퍼드-레지스터드’로 불리고 있다.

출처: http://cafe.naver.com/mynet/32

RAID

RAID란 무엇인가?
IT업계에 종사하는 사람 중에 RAID (Redundant Array of Independent Disks)라는 말을 들어보지 못한 사람은 그리 많지 않을 것 같다. RAID는 특정 제품이나 상품명은 아니다. 하지만 스토리지 혹은 어레이라고 부르는 제품중에 RAID기술을 적용하지 않은 제품은 단 한 개도 없을 정도로 널리 사용되다 보니 이러한 제품 자체를 RAID라고 부르는 경우도 종종 있다. RAID는 원래 1988년 미국의 U.C. Berkely의 컴퓨터공학과에서 발표한 논문으로부터 시작된 전산학 개념중의 하나이다. 과거 대용량 디스크가 엄청나게 비쌌던 시절에, 값싼 저용량 디스크를 여러 개 묶어서 하나의 대용량 디스크처럼 쓰고자 하는 기술로 출발한 것이 RAID이다. 스토리지 업체 뿐만 아니라 웬만한 OS에서도 그것이 하드웨어 방식이건 소프트웨어 방식이건 RAID는 기본적으로 제공하는 기술이다. 과거에 비하여 100GB이상의 대용량 디스크가 가정에서도 쉽게 사용되고 있는 현대 시대에도 RAID는 필요하다. 스토리지에서 흔히 사용되는 테라바이트 단위의 정말로 대용량이 필요한 곳에는 없어서는 안될 기술이 바로 RAID이다. 단적으로 1TB짜리 디스크 모듈은 지구상에 존재하지 않는걸 봐도 그렇지 않은가. 사실 RAID를 논한다는 것은 대단히 기술적인 문제이고 아무리 쉽게 이야기를 하고 싶어도 어쩔 수 없이 어느 정도는 골치 아픈 용어와 익숙치 않은 개념 들을 사용할 수 밖에 없는, 별로 재미 없는 주제이긴 하지만 한번만 머리 아프면 IT업계에 종사하는 사람들에겐 여러 곳에서 아는 척(?)할 수 있는 유용한 개념중의 하나이기도 하므로 하품은 조금 뒤에 하기로 하고 수박 겉핥는 식으로라도 한번 알아보기로 하자.
RAID의 목적은 크게 세가지라고 볼 수 있다. 첫째는 서두에 밝힌 바와 같이 여러 개의 디스크 모듈을 하나의 대용량 디스크처럼 사용할 수 있도록 한다는 것, 두번째는 여러 개의 디스크 모듈에 데이터를 나누어서 한꺼번에 쓰고 한꺼번에 읽는 식으로 IO속도를 높인다는 것, 마지막으로 여러 개의 디스크를 모아서 하나의 디스크로 만들었으니 그중 하나 혹은 그 이상의 디스크에 장애가 나더라도 최소한 데이터가 사라지는 것은 방지하자는 것이 그 목적이라고 할 수 있다. 이러한 RAID에는 몇 가지 종류가 있다. RAID 레벨이라고 하는 것이 그것인데 RAID-0, RAID-1 이런 식으로 뒤에 번호가 붙는다. RAID 레벨에는 0부터 7까지가 있고 이들을 조합한 것이 몇 가지가 있는데, 모두 설명하자면 정말 이 페이지를 바로 지나쳐 버릴지도 모르므로 실제로 업무 환경에서 사용되고 제품에 적용되는 몇 가지만 간단하게 알고 넘어가자.
RAID-0
두번 째 목적에서 언급한 것처럼 여러 개의 디스크 모듈에 데이터를 분산 저장하는 기술을 스트라이핑(striping)이라고 한다. RAID-0는 단순한 스트라이핑이다. 10개의 100GB용량의 디스크를 하나의 1TB디스크로 묶어서 RAID-0를 적용할 수 있다. 10GB짜리 파일 하나를 1개의 디스크에 저장하는 것보다는 10개의 디스크에 동시에 나누어 저장하고 한꺼번에 읽어들이는 것이 빠르다는 것은 직감으로도 알 수 있으리라. 얼핏 보면 10배 빠를 것 같기도 하다. 다섯번째 디스크에 장애가 난다면….? 10개 디스크에 저장된 모든 데이터는 지구상에서 사라진다. 이것이 RAID-0이다. 실제로 RAID-0만으로 구성된 스토리지는 주변에서 찾기 쉽지 않다. 어지간한 강심장이 아니라면 RAID-0만으로는 사용하지 않는다고 보면 된다. 단, 이후에 설명하는 모든 RAID레벨은 기본적으로 RAID-0를 포함한다고 보면 된다. 데이터를 분산 저장한다는 개념은 누가 보아도 명백히 훌륭하기 때문이다.
raid-1
그림 1. RAID-0의 데이터 저장 방식
RAID-1
그 렇다면 어떻게 해야 디스크 모듈의 장애로 인하여 데이터가 사라지는 경우를 막을 수 있을까. 이것을 연구한 것이 RAID-0를 제외한 모든 종류의 RAID가 고민하는 부분이고 각각 다른 접근 방식을 택하고 있다. 가장 단순하면서도 가장 강력한 방법이 RAID-1이다. RAID-1은 미러링(mirroring)이라고도 하는데, 말 그대로 완전히 동일한 내용의 디스크 모듈을 두개씩 가져가는 것이다. 100GB디스크 모듈 10개로 500GB의 대용량 디스크를 만들 수 있다. 각 모듈이 두개씩 한쌍이 되기 때문에 실제 가용량은 반밖에 되지 않는다. 이것이 RAID-1의 단점이다. 원하는 만큼의 용량을 구성하고자 할 때 가장 돈이 많이 든다는 것이다. 어떤 디스크에 장애가 나도 데이터는 멀쩡히 살아 있게 된다. 단, 하나의 쌍으로 이루어진 디스크 두개가 동시에 장애가 난다면 역시 속수 무책이다.
raid-2
그림 2. RAID-1의 데이터 저장 방식
RAID-4
RAID -1은 너무 비싸다. 디스크를 반밖에 사용하지 못한다니… 너무 아깝다는 생각이 들지 않는가. 그래서 연구해낸 것이 패리티(Parity)라는 것이다. 각 디스크에 데이터를 분산 저장할 때 저장되는 데이터들을 특정 연산을 한 결과값이 패리티 데이터인데, 이러한 패리티 데이터를 별도의 패리티 디스크에 저장하는 것이 RAID-4이다. 데이터 디스크와 패리티 디스크가 독립적이기 때문에 볼륨을 확장할 때 별도의 데이터 백업과 복구 과정을 없앨 수 있는 유연성을 가지고 있는데 이것이 RAID-4의 최대 장점이다. 하지만 문제는 한 개의 디스크 장애에 대해서는 완벽하게 대처할 수 있지만 동시에 두개의 디스크에 장애가 나면 데이터가 손실된다. 왜 그럴 수 밖에 없는가는 계속 숫자 이야기를 해야 하기 때문에 자세히 설명 하지는 않겠다. 또 하나의 문제는 패리티 디스크에 병목 현상이 발생할 소지가 매우 많고 이로써 전체 스토리지의 성능 저하를 가져온다는 것이 가장 큰 단점인데, 이 병목 현상을 근본적으로 해결하는 원천 기술을 보유한 네트워크 어플라이언스(Network Appliance, 이하 넷앱)를 제외한 다른 스토리지 업체들이 RAID-4를 채택하지 못하는 이유가 여기에 있다. 이 병목현상만 없앨 수 있다면 RAID-4는 가장 장점이 많은 RAID방식이라고 할 수 있다.
raid-3
그림 3. RAID-4의 데이터 저장 방식
RAID-5
RAID -4의 병목현상을 해결하기 위하여 나온 것이 RAID-5이다. 별도의 패리티 디스크를 가지고 있지 않고 모든 패리티 데이터를 데이터 디스크에 분산 저장하는 것이다. 이렇게 하면 패리티 디스크 자체가 없기 때문에 패리티 디스크로 인한 병목 현상 자체도 없어지는 것은 당연하다. 하지만 동시에 두개의 디스크에 장애가 나면 데이터를 손실하는 문제는 여전히 가지고 있고 더군다나 RAID-4가 가지고 있는 볼륨 확장의 유연성은 사라진다. 디스크를 추가할 때 모든 데이터에 대한 패리티 데이터를 다시 연산하여 재기록 해야 하기 때문이다. 하지만 현재까지는 세계적으로 가장 많이 사용되는 RAID레벨이기도 하다.
raid-4
그림 4. RAID-5의 데이터 저장 방식
RAID-DP
이번 연재에서 주제로 삼은 것이 바로 RAID-DP이다. DP는 이중 패리티(Dual Parity)의 약자인데, RAID-DP라는 것은 원래의 RAID논문에 나온 공개되어 있는 개념이 아닌 넷앱이 독자적 기술로 개발하여 이번에 새로 발표한 기술이다. RAID-DP는 기본적으로 RAID-4가 가지는 모든 장점을 그대로 가져간다. RAID-DP가 RAID-4를 기반으로 만들어졌기 때문이다. 이중 패리티라는 말 자체가 알려주듯이 패리티를 이중으로 가져간다는 것이다. 좀 더 정확히 말하면 패리티 디스크가 하나의 RAID그룹에 두개가 들어간다. 그렇다면 두개의 디스크에 장애가 발생해도 데이터는 멀쩡히 살아 있을 수 있다. 한 개의 디스크에 장애가 생기면 RAID-4나 RAID-5에는 보통 여유분의 디스크인 스페어 디스크(Spare Disk)가 있기 때문에 자동으로 이 스페어 디스크에 기존의 데이터 정보를 기초로 한 패리티 연산을 통하여 그대로 원래의 데이터를 100% 살려 낼 수 있다. 문제는 이 데이터를 살려 내는 그 시간 동안 또 다른 디스크가 장애가 나는 최악의 사태가 흔하지는 않지만 발생은 한다는 것이다. 더군다나 요즘처럼 해가 갈수록 단위 디스크 모듈의 크기가 날로 증가하는 추세에 있어서 이러한 데이터 재생 시간도 비례해서 증가하게 된다. 단순한 확률적인 계산으로 따지면 RAID-DP는 RAID-5에 비하여 70만배정도 안정성이 향상된다. 물론 어디까지나 확률적인 문제이긴 하지만. 자, 그럼 여기서 한가지 의문이 생긴다. 일반적으로 대용량의 볼륨은 몇 개의 RAID그룹으로 나뉘게 된다. RAID 4의 예를 들면, 파이버채널 기반의 스토리지를 기준으로 데이터디스크 7개+패리티디스크 1개의 8개 디스크를 하나의 RAID그룹으로 묶는 것이 일반적이다. 여기에 RAID-DP를 적용하면 데이터디스크 6개+패리티디스크 2개가 되므로 결국 디스크 한 개의 용량만큼 가용량이 줄어들게 된다. 정말 그럴까? 그렇지 않다. RAID-DP를 적용할 시에는 데이터디스크 12개+패리티디스크 2개를 하나의 RAID그룹으로 묶는 것이 권장 사항이다. 그렇다면 결국 가용할 수 있는 데이터 공간은 동일하고 안정성은 훨씬 향상되는 두마리 토끼를 동시에 잡을 수 있게 된다.
RAID-DP를 적용해야 할까?
그렇다면 지금 사용하고 있는 스토리지에 RAID-DP를 바로 적용해야 할까? 지금까지도 잘 쓰고 있었는데 갑자기 RAID 레벨을 바꾸는게 좀처럼 쉽지 않을텐데… RAID-1을 사용하다가 RAID-5로 바꾼다면 볼륨 전체의 데이터를 백업 한 후에 해당 볼륨을 파괴하고 RAID-5로 다시 재구성 한 후에 데이터를 복원시키는 “엄청난” 작업이 필요하다. 물론 반대의 경우도 마찬가지이다. 그 동안에 서비스가 중지되어야 함은 물론이거니와 이러한 작업을 좋아하는 운영자는 아무도 없을 것이다. 넷앱의 제품을 사용한다면(RAID-DP는 넷앱의 고유 기술이니까) RAID-4를 사용하고 있을것이다. RAID-DP를 사용하고자 한다면 OS가 DataONTAP 6.5인지 확인해야 한다. 만약 그렇다면 데이터의 백업과 복구, 볼륨의 파괴와 재 생성, 서비스의 중단과 같은 만나고 싶지 않은 일들은 결코 일어나지 않는다. 볼륨의 RAID만 RAID-DP로 바꿔주는 명령 한 줄이면 바로 RAID-DP로 바뀌게 된다. 어떤 이유에서건 RAID-DP에서 RAID-4로 돌아가는 일 또한 같은 과정을 밟는다. 물론 이중 패리티가 저장될 디스크 여유분이 있어야 함은 물론이다.
RAID-DP와 2차 스토리지
2차 스토리지라는 것은 테이프 라이브러리나 주크박스와 같은 용량 대비 저렴한 저장 매체의 단점, 즉 속도의 문제를 해결하기 위하여 대안으로 나온 디스크 기반의 백업 솔루션이다. 보통 우리가 스토리지라고 부르는 것을 1차 스토리지라고 한다면 2차스토리지와 1차스토리지의 가장 큰 차이점은 가격을 낮추기 위하여 파이버 채널 디스크나 SCSI디스크 대신에 ATA디스크를 사용한다는 것이다. 파이버채널 디스크가 144GB모듈까지 나온데 비하여 ATA디스크는 320GB모듈까지도 사용하고 있다. 이렇게 단위 디스크 모듈이 커지는게 문제다. 용량면에서는 대단히 이익인건 틀림없는 사실이지만 앞에서도 언급했듯이 디스크 모듈에 장애가 발생했을 때 데이터 재생 시간이 오래 걸린다는 것이다. 데이터 재생이 다 마치기 전에 또 하나의 디스크에 장애가 난다면 데이터가 모두 사라진다는데에 문제가 있다. 대부분이 ATA디스크를 사용하는 2차 스토리지는 성능보다는 안정성을 최우선으로 생각한다. 그렇다면 RAID-1을 사용하면 되지 않을까. 이것은 2차 스토리지를 사용하는 이유에 근본적으로 위배된다. 가격이 비싸지기 때문이다. RAID-5를 사용하면 어떨까. 지금까지는 선택의 여지가 없었다. RAID-DP를 적용한다면 가격과 안정성 모두를 만족시킬 수 있게 될 것이다.
RAID-DP의 동작 원리
RAID -DP의 동작 원리를 살펴보면 그림과 같이 약간의 숫자 계산을 해야 한다. DP라는 부분은 이중패리티 디스크이고 이것만 빠지면 RAID-4와 동일하다. 그림 5에서 D는 데이터 디스크, P는 패리티 디스크, DP는 이중 패리티 디스크를 표시한다. 각 데이터 디스크의 첫번째 줄을 더한 값인 9를 패리티 디스크에 기록하고, 두번째 줄을 더한 값인 5를 역시 패리티 디스크에 기록하는 방식이다. 첫번째 디스크에 장애가 발생한다면 패리티 디스크의 9에서 두번째, 세번째, 네번째 디스크의 값인 1,2,3을 빼면 3이 되므로 원래 그 값이 3이었다는 것을 알 수 있는 식으로 디스크의 데이터를 복구한다. 두번째 디스크에 추가로 장애가 나면 어떨까. 페리티 디스크의 9에서 세번째, 네번째 디스크의 값인 2,3을 빼면 4가 되는데 첫번째 디스크와 두번째 디스크에 각각 1,3이 있어도 4가 되고 2,2가 있어도 4가 되는 식으로 어디에 어떤값이 있었는지 알 방법이 없어진다. 이를 방지하기 위하여 이중 패리티 디스크에는 각 디스크의 대각선으로 숫자를 계산하여 그 값을 기록한다. 색깔로 구분이 되어 있으므로 말로 설명하는 것 보다 덧셈과 뺄셈만 약간 하면 두개의 디스크에 장애가 생겨도 완벽하게 데이터를 복구할 수 있다는 것을 이해할 수 있으리라 생각 된다.
raid-5
그림 5. RAID-DP의 데이터 저장 방식
결론
RAID -1이 현재로서는 가장 안정적인 RAID방식이라는 것은 서두에서도 언급했었고 아직까지는 누구도 의심 할 여지가 없다. 그럼에도 불구하고 다른 방식의 패리티를 사용하는 RAID기술이 나오고 널리 사용되는 것은 어디까지나 안정성과 비용이라는 두가지 상반된 물건을 수평저울에 올려놓고 저울질하는 것과 같다. 비용과 전혀 상관 없이 안정성만을 추구한다면 망설이지 말고 미러링을 구성하면 된다. 하지만 훨씬 저렴한 비용에 안정성을 추구한다면 이 글을 읽는 순간부터는 망설이지 말고 RAID-DP를 적용 하라. 장애가 난 디스크는 바꾸면 그만이고 최악의 경우 돈으로 살 수 있다. 하지만 그 안의 데이터, 기업이 각고의 노력으로 축적해 오고 만들어낸 그 데이터는 이 세상 어디에서도 돈으로 살 수 없는 값진 것이다.
출처 : http://www-kr.netapp.com/

블레이드 서버

블레이드 서버의 개요

이상민* 박종원** 박진원 ***

칼날처럼 얇은 초박형 블레이드를 슬롯에 꽂아 컴퓨터 시스템을 구성하는 블레이드 서버는 컴퓨팅 성능 향상에 따른 전력소비와 발열량 증가 문제를 해결할 수 있을 것으로 예상된다. 저전력 칩들을 기반으로 작은 크기로 모듈화시키는 블레이드 구성 방법은 전력소비량을 감소시키는 것 외에도여러 가지 장점을 얻을 수 있다.
본 고에서는 블레이드 서버의 등장 배경, 장점, 구성 방법, 그리고 응용분야 등에 대해 살펴 볼 것이다. 특히, 최신 기술을 채택하여 제작된 블레이드 서버들의 개발사례를 통해서 블레이드 서버 구성 방법의 최근 동향을 소개할 것이다.

I. 서 론

고속 인터넷 및 인트라넷 기술의 발달에 따라 대량의 데이터를 고속으로 처리할 수 있는 서버 기술이 요구되어 왔고 시스템 확장성, 적용성, 그리고 높은 가격대 성능비도 만족시켜야 했다. 이와 같은 요구사항들을 만족시키기 위해서 랙 마운트형 클러스터 서버 기술이 등장하게 되었다. 그러나 랙 마운트형 클러스터 서버는 부피가 커지고 전력 소비량도 크게 증가하는 문제점을 갖고 있고 각 모듈들을 케이블로 연결함으로써 시스템 확장성과 유지 관리(maintenance and management)에 많은 어려움을 겪게 되었다. 이러한 문제들을 해결할 수 있는 새로운 대용량 서버 기술은 저전력, 고집적 마이크로 프로세서와 같은 효율적인 에너지 절약형 칩을 기반으로 부피, 발열량 등의 문제를 해결할 수 있어야 한다.

블레이드 서버는 랙 마운트형 서버처럼 가로로 랙 서버를 쌓아 올리지 않고, 슬롯에 칼날처럼 얇은 블레이드들을 세로로 꽂는 것이 특징이다. 얇은 초박형 블레이드를 슬롯에 꽂아 제작하는 블레이드 서버는 두께를 얇게 구성할 수 있으므로, 수십 개 혹은 수백 개의 서버들을 하나의 캐비넷에 장착할 수 있다((그림 1) 참조). 그리고 네트워크, 스위치, 스토리지, 어플라이언스 등을 특정한 기능에 따라 독립적인 블레이드로 구성할 수도 있다.

blade01

고속 프로세서의 엄청난 발열량은 블레이드 서버의 확장성을 제한하는 중요한 요인이다. 그러나 발열문제는 저전력에 기반한 인텔의 Tualatin과 트랜스메타의 Crusoe 프로세서와 같은 저전력 소비 기술의 등장으로 어느 정도 해소되고 있다.

저전력 프로세서와 고집적 칩 제조기술이 발전함에 따라, 블레이드 서버 제조회사는 더욱 더 얇고, 고집적화된 블레이드 서버의 설계가 가능하게 되었다. 이에 따라 블레이드 서버 제조회사는 전력소모뿐만 아니라 공간활용 면에서 우수한 블레이드 서버를 생산할 수 있다.

최근 여러 컴퓨팅 센터에서는 와트와 부피 당 프로세싱 파워로서 효율성을 평가한 결과를 바탕으로, 랙 당 수백 개의 프로세서들을 탑재할 수 있는 블레이드 서버의 도입을 고려하고 있다[6].

블레이드 서버는 구매자가 원하는 저비용(low cost), 확장성, 그리고 신뢰성을 충족시킬 수 있다. 시스템 관리 소프트웨어와 대용량 스토리지 시스템으로 구성된 블레이드 서버는 front-end 시스템으로서 역할을 충분히 수행할 수 있을 것으로 예상된다.

본 고는 블레이드에 기반한 클러스터링 형태의 블레이드 서버가 다음 세대 대용량 컴퓨터 서버기술로서 자리 매김할 것으로 예상됨에 따라, 이에 대한 장점, 구성 방법, 그리고 적용 분야에 대해 살펴 볼 것이다. I장 서론에 이어 II장에서 기존 서버와 비교해서 블레이드 서버의 장점을 살펴 볼 것이다. III장에서 시장에서 판매되고 있는 상용 블레이드 서버를 설명함으로써 최근에 제작되고 있는 블레이드 서버의 구성 형태를 소개할 것이다. IV장에서 블레이드 서버의 응용분야에 대해서 언급할 것이며, 마지막으로 V장에서 결론과 블레이드 서버의 향후 발전 방향에 대해서 언급할 예정이다.

II. 블레이드 서버의 장점

1. 고속의 연결망(High-speed Connectivity)

블레이드 서버의 첫번째 장점은 여러 블레이드들을 연결하기 위해서 특별히 고안된 high-speed 연결방식(InfiniBand, 중복적으로 구성된 고속 시리얼 버스 등)을 사용하는 데 있다. 고속 연결망은 블레이드 간에 초당 수 기가비트 수준으로 통신이 가능하게 함으로써 빠른 데이터 교환을 통해서 시스템 성능을 향상시킬 수 있다. 특히, InfiniBand와 같은 고속 연결망은 운영체제 커널 수준의 통신기능을 하드웨어적으로 지원해 줌으로써 통신 오버 헤드를 더욱 줄일 수 있다[1,2].

2. 고밀도(High Density) 및 확장성

기존의 랙 마운트 형태의 클러스터 서버는 고속의 케이블 형태가 주요 연결 방식이었다. 따라서 연결 대상이 많아질수록 더 넓은 공간과 복잡한 케이블 배선이 필요하게 되었다. 그러나 블레이드 서버의 연결 인터페이스는 슬롯 형태로 주 연결망에 세로로 꽂게 구성되어 있어서 기존의 랙 마운트 형태의 클러스터 서버와 같은 복잡한 케이블 연결이 필요없게 되었다. 즉, 블레이드 서버에서 채용한 슬롯 형태의 연결 방법은 하나의 섀시에 프로세서, 메모리, 연결 인터페이스 등이 포함된 작고 얇게 모듈화된 블레이드를 여러 개 담을 수 있게 된다.

블레이드 서버는 시스템을 확장할 때 노드 단위로 확장하지 않고 용도가 특화된 블레이드 단위로 확장한다. 그러므로 블레이드에는 장착되지 않는 CD롬 드라이버, 플로피 디스크와 같은I/O 디바이스와 전원 공급 장치를 공동으로 사용함으로써 좀 더 낮은 가격에 높은 성능을 얻을 수 있다. 예를 들어, IU 서버 정도 크기의 시스템에 4개의 hot-pluggable 블레이드를 장착할 수 있다.

기존의 서버 시스템은 초기에 엄청난 비용이 소요되는 것이 일반적이었다. 그러나 블레이드 서버의 경우에는 시스템 구성을 블레이드 단위로 확장할 수 있으므로, 초기 투자 비용이 절감되고 확장 시에도 융통성을 갖게 되었다. 시스템 확장 시 블레이드를 추가하더라도 이미 탑재된(pre-loaded) 소프트웨어를 재사용함으로써, 전체 시스템 차원에서 추가적인 소프트웨어 비용은 발생하지 않는다. 따라서 블레이드 서버 시스템은 적은 시간과 비용으로 필요한 시점에 보다 용이하게 시스템을 확장해 나갈 수 있다.

3. 적용성(Deployment)

블레이드 서버에서 각각의 블레이드는 용도에 따라 쉽게 특화될 수 있다. 이러한 블레이드로 구성된 블레이드 서버는 사용 목적(웹 서버, ftp 서버, 이메일 서버, 데이터베이스 서버 등)에 따라 특화된 시스템을 구성할 수 있다. 예를 들어, 동시에 많은 사용자가 액세스하는 웹 서버인 경우, 액세스되는 웹 페이지에 더 많은 프로세싱 블레이드를 배치하거나, 고속의 인터넷 연결망으로 연결된 웹 캐싱용 블레이드를 배치함으로써 보다 빠르게 사용자 액세스 요구를 처리할 수 있다.

III. 블레이드 서버의 구성

블레이드 서버는 크게 블레이드와 섀시(연 결망 포함)로 구성되어 있다. 블레이드는 연산을 담당하는 서버 블레이드(혹은 연산 블레이드), 연결망을 관리하는 스위치 블레이드, 네트워크와 I/O 연결을 담당하는 제어 블레이드, 특정 용도에 알맞게 설계된 블레이드 등으로 분류할 수 있다. 한편, 섀시는 블레이드에게 연결망을 제공하고 전원도 공급한다. 일반적으로 블레이드와 섀시는 블레이드 제조 회사에 따라 서로 다른 형태를 갖고 있다.

여기서 대표적인 블레이드 서버 제품을 통해 블레이드 서버의 구성을 살펴본 후 여러 다른 블레이드 서버와 비교해 보자.

1. Nitro

Nitro(Mellonox InfiniBand Bladed Server)는 Mellanox의 InfiniBand 기반의 블레이드 서버 참조 디자인(reference design)이다[4,5]. (그림 2)에서 보는 바와 같이 Nitro 블레이드 서버는 전통적인 연결망(PCI 버스, 기가비트 이더넷, 시리얼 버스 등) 대신에 InfiniBand Backplane을 사용하고 있다. Nitro는 커널 수준의 네트워크 기능(즉, TCP/IP)을 하드웨어로 처리할 수 있는 InfiniBand 구조를 채택함으로써, 블레이드들 간의 통신 오버헤드를 최소화 할 수 있다[1,2]. 그리고 InfiniBand 연결망 기술이 제공하는 신뢰성, 확장성, 그리고 가용성을 바탕으로 클러스터 구성 시 관리(maintenace)의 용이함뿐만 아니라 전체 시스템의 효율성도 높일 수 있다.

blade02

(그림 3)은 Nitro블레이드 서버의 전체 구조를 보여주고 있다. Nitro는 16개의 블레이드와 이들을 고속으로 연결하기 위한 2개의 InfiniBand Switch로 구성되어 있다.

blade03

16 개의 블레이드 중에서 Ethernet 망과의 연결을 위해 Ethenet에서 InfiniBand로 변환하는 2개의 Ethernet Target Control Adapter(TCA) 블레이드와 대용량 스토리지를 연결하기 위한 2개의 Fibre Channel TCA 블레이드가 있다. 그리고 나머지 12개의 블레이드는 실제적인 연산 작업을 수행하는 서버 블레이드(server blade) 이다.

(그 림 4)는 확장성과 가용성을 보장하는 InfiniBand 연결망을 사용해서 여러 대의 Nitro 블레이드 서버와 대용량의 고성능 스토리지(Netwok Attached Storage(NAS) 혹은 InfiniBand 기반 스토리지)를 연결해서 InfiniBand System Area Network(ISAN)를 구성하는 예를 보여주고 있다. ISAN 기반의 System Area Network는 수많은 클라이언트의 요청을 동시에 처리해야 하는 Internet Data Center(IDC)와 Enterprise Data Center(EDC) 혹은 유전자 정보 분석과 같은 빠르게 대용량의 연산을 수행해야 하는 응용 분야에 활용될 수 있다.

blade04

2. BladeFrame

고성능(high performance)과 고가용성(high availability)을 설계 목표로 설정한 BladeFrame 블레이드 서버는 Egenera사에서 개발되었다. BladeFrame 서버는 단독으로 존재하기 보다는 (그림 5)에서 보는 바와 같이 Processing Area Network(PAN)를 통해 대규모 시스템으로 존재하는 것이 일반적이다.

blade05

BladeFrame 시스템의 분산된 컴포넌트 하드웨어 구조는 디스크 없는 프로세싱 블레이드들을 고속의 Switched Fabric으로 연결함으로써, Storage Area Network(SAN)과 고속의Ethernet과 같은 전통적인 네트워크와 접속이 가능하게 된다. PAN은 네트워크에 분산되어 있는 자원들(프로세스, 메모리, 스토리지, 네트워크 연결, CD-ROM 등)을 논리적으로 하나의 클러스터 형태로 구성한다[7]. 여기서 PAN의 프로세싱 자원들이 stateless(diskless)이기 때문에, 동적인 할당과 재할당 그리고 failover를 융통성 있게 관리할 수 있다[7]. 확장성 면에서도 고속의 Switched Fabric으로 다른 PAN을 연결해서 Processing Blade Pools라고 불리는 더 큰 규모의 PAN을 구성함으로써 성능을 향상시킬 수 있다[7].

(그림 6)은 BladeFrame 시스템의 실제 구성도를 나타내고 있으며, 이는 다음과 같은 요소들로 구성되어 있다.

- BackPlane: BackPlane은 중복적으로 구성되는 고속의 시리얼 버스로서, PAN의 물리적인 내부 네트워크와 모든 블레이드를 연결하며, 블레이드들 간에 Switch Blade를 통해 초당 2.5 기가비트의 point-to-point 방식으로 데이터 전송을 지원한다. 또한 BackPlane은 모든 블레이드에 전력을 공급하고 블레이드 식별(identification) 메커니즘을 제공한다[7].

- Switch Blade(sBlade): 중복적으로 구성되는 두 개의 Switch Blade는 내부, 외부 I/O, 그리고 외부 네트워크를 위해서 PAN의 point-to-point 구조의 물리적인 Switching Layer를 제공한다. 각 Switch Blade는 BackPlane을 통해서 각 Processing Blade와 Control Blade와 연결되어 있어서 고속의 연결망을 지원, 관리한다[7]. Switch Blade와의 연결을 위해 Processing Blade와 Control Blade는 2개의 중복된 Switch Blade Host Adapter를 가지고 있다.

- Processing Blade(pBlade): 실질적인 연산을 담당하는 Processing Blade는 4개의 인텔 Xeon 프로세서, 메모리, 그리고 BackPlane에 연결된 두 개의(full-duplex) Connection Adapter로 구성되어 있다[7]. 디스크 없는 Processing Blade는 외부 스토리지와 외부 네트워크와 연결된 링크를 통해서 설정되며 일반적인 서버처럼 동작한다.

- Control Blade(cBlade): 두 개의 Control Blade는 전체 시스템을 대신하여 모든 I/O 작업을 수행한다[7]. 이를 위해서 각 Control Blade는 두 개의 100 Megabyte/second Fibre Channel 링크에 연결되며, PAN의 모든 저장장치를 관리하는 SAN망에 연결되어 있다[7]. 그리고 외부 네트워크의 연결을 위해서 각 Control Blade는 두 개의 125 Megabyte/ second Gigabit Ethernet으로 접속할 수 있는 링크를 제공한다.

blade06

3. 블레이드 서버의 구성 비교

앞에서 언급한 Nitro와 BladeFrame외에도 여러 가지 블레이드 서버가 존재한다[9-12]. 비교적 초기에 나온 RLX Technologies의 RLX System 324, 대형 컴퓨터 제조회사인 HP에서 개발한 bh 7800, Compaq의 BL10e 등이 대표적인 예이다. 그리고 Open Clustering에서 프로토타입 시스템인 Samurai Blade Server가 있다. 이들 블레이드 서버들의 구성비교는 <표 1>에 제시하였다.

blade07

IV. 응용 분야

1. 인터넷 서버

블레이드 서버는 일반 인터넷 사용자들에게 클러스터링 구조의 인터넷 서버로서 최적의 서버 플랫폼으로 인식되고 있다. 동일한 서비스를 많은 사용자에게 제공하거나, 서비스별로 별도의 서버를 운영하고자 하는 경우 블레이드 서버가 적합한 것으로 평가되며, 구체적인 용도는 다음과 같다[13].

- 웹 서버

- 메일 서버

- 인터넷 방송 스트림 서버, Video On Demand(VOD) 서버

- Application Service Provider(ASP)

2. 병렬처리가 가능한 과학계산용 서버

시뮬레이션, 그래픽 애니메이션, 통계, 수치 계산 등에 활용되어 과학계산용 프로그램을 주로 사용하는 연구소, 실험실에서 저렴한 비용으로 고성능 서버를 구축하는 데에 블레이드 서버가 적합하다. 최근 수요가 급증하고 있는 유전자 정보 분석 분야에도 높은 가격대 성능비를 제공할 수 있는 서버 솔루션으로 평가되며, 구체적인 응용분야는 다음과 같다[13].

- 유전자 정보 분석용 서버

- 모델링 및 시뮬레이션용 서버

- 암호 해독, 수치해석용 서버

3. IDC 전용 서버

많은 서버들을 관리해야 하는 인터넷 데이터 센터(IDC)에서 문제가 되는 공간과 전력 소비 문제를 해결해 줄 수 있는 가장 효율적이며, 확장성 및 관리가 용이한 최상의 클러스터 서버이다[13].

- 탁월한 공간 절약형 서버

- 성능 확장을 위한 용이한 서버 증설 가능

- 클러스터 시스템 모니터링을 통한 통합 관리 가능

V. 결론 및 향후 발전방향

최근 몇년 동안 네트워크 속도의 향상과 더불어 대규모 연산을 요하는 응용 분야가 속속 등장하고 있다. 이러한 분야에서 고가용성, 고성능, 확장성, 그리고 높은 가격대 성능비를 보장하는 서버를 필요로 한다. 비교적 저렴한 가격으로 이러한 요구사항을 충족시킬 수 있는 랙 마운트형 클러스터 서버가 폭 넓게 사용되어 왔으나 시스템의 크기가 계속 확대됨으로써 공간 배치 문제가 야기되었고, 전력 소비가 증가함으로써 발열량이 증가하는 문제가 대두되었다.

이러한 랙 마운트형 클러스터 서버의 한계점을 해결하기 위해 저전력 칩을 사용하여 작게 모듈화한 블레이드를 고속의 연결망을 통해서 하나의 케이스에 담을 수 있는 블레이드 서버가 제안되었다. 블레이드 서버는 높은 가격대 성능비, 고밀도 및 용이한 확장성, 그리고 각 응용분야에 특화될 수 있는 장점이 있다.

여러 선도 서버 제조 업체들이 앞다투어서 그들만의 고유한 구성방식으로 블레이드 서버를 제안하여서 여러 응용 분야에 적용하고 있다. 이러한 추세로 본다면 기존 랙 마운트형 클러스터 서버 시장을 블레이드 서버가 빠르게 대체할 것으로 예상된다.

그러나 블레이드 서버의 대중화를 위해서는 블레이드 모듈 규격과 연결망과의 인터페이스 표준화를 통해서 상호 호환성을 보장해야 하고, 더 낮은 가격으로 고성능의 제품을 구성할 수 있어야 할 것으로 보인다.

<참 고 문 헌>

[1] 박경, “InfiniBand의 개요,” 주간기술동향, 통권 967호, 2000. 10, pp.10-22.

[2] InfiniBandTM Architecture Specification Volume 1, June 19, 2001, http://www.infinibandta.org/ data/spec/10a/vol1r1a2.pdf

[3] InfiniBandTM Architecture-TurboCharging the Bladed Server, A VIEO White Paper, Jan. 2000, http://www.vieo.com/infiniband/bladeserver.pdf

[4] Realizing the Full Potential of Server, Switch & I/O Blades with InfiniBand Architecture, Mellanox TechnologiesTM White Paper, http://www.mellanox.com/products/shared/BladesArchWP110.pdf

[5] InfiniBandTM in the Internet Data Center, Mellanox TechnologiesTM White Paper, http://www. mellanox.com/products/shared/IBIDC160.pdf

[6] Mellanox Performance, Price, Power, Volume, Metric(PPPV), Mellanox TechnologiesTM White Paper, http://www.mellanox.com/products/shared/PPPV.pdf

[7] The EgeneraTM Processing Area Network(PAN) Architecture, EgeneraTM White Paper, 2002, http://www.egenera.com/pdf/wp_pan_arch.pdf

[8] BladeFrameTM System Overview, 2001, http://www.egenera.com/pdf/system_data.pdf

[9] RLX Technologies Products, RLX Technologies Inc., http://www.rlxtechnologies.com/products/ products.php

[10] HP Blade Server, HP Corporation, http://www.hp.co.kr/product1/servers/bladeserver

[11] Compaq BL e-Class, Compaq Corporation, http://www.compaq.com/products/servers/proliant-bl/e-class/

[12] Samurai Blade Server, Open Clustering Organization, http://www.openclustering.com/samurai_specs.php

[13] Uniclus380 응용분야, shellcomm Inc., http://www.incache.com/uniclus380/uniclus380_appl.htm

팔로우

모든 새 글을 수신함으로 전달 받으세요.