SAN의 시작, 기초부터 확실하게!

일반입력 :2004/09/22 16:38

시스코 코리아 (on the NET)

이제는 SAN이 시장에서 본격적으로 자리를 잡고 있으며, 기존의 엔터프라이즈 환경뿐 아니라 일반 중소규모의 기업까지도 SAN을 고려하고 있는 상황에 이르고 있다.대규모 엔터프라이즈 환경에서 서버 콘솔리데이션이 부상하면서 동시에 개별적으로 관리되던 독립된 SAN 섬(SAN Island)를 통합하기 위한 방안을 모색하고 있다. 또한 구축비용의 하락과 더불어 중소 조직에서도 SAN의 효능이 입증되고 있다. 특히 IP-SAN 기술이 투자비용을 절감하기 위한 효과적인 방법으로 떠오르면서 네트워크 관리자도 SAN 기술을 수용하는 시야를 갖춰야할 것을 요구하고 있다.그동안 온더넷 등의 네트워크 전문지에서도 스토리지 관련 기사를 본격적으로 다뤄왔으며, 이번 연재를 통해 전송 기술 관점에서 SAN 기술에 대해 살펴보는 자리를 마련하고자 한다. 이번 글의 대상은 SAN 환경에 익숙하지 않은 일반 네트워크 관리자에서부터, SAN 환경을 이미 구축한 상태이지만, 향후 증설과 효율적인 SAN 인프라 설계를 고려하는 스토리지 담당자에 이르기까지 다양한 독자층을 대상으로 하고 있다.서버 관리자 영역에 머물고 있는 SAN어디까지가 SAN의 영역이고, 그 관리대상, 주체, 목표는 무엇인지 알아보자. 기술적인 것을 논하기 이전에 관리 주체에 대한 정의를 해보자. 지금까지 SAN은 서버 관리자의 고유 업무 중 하나였다.외장형 스토리지 자체가, 대형 핵심 업무 서버에서 주로 사용하던 것이고, 여기서 사용하는 SAN 스위치나 장거리 백업을 위한 DWDM 등의 컴포넌트는 일반 네트워크와는 다른 목적의 별개 프로젝트였기 때문이다.스토리지가 여전히 서버 담당자의 고유한 업무라는 것에는 변함이 없다. 그러나 이제 이것을 네트워크의 입장에서 해석하고, 기업전체의 주요 IT 자산으로 공유할 수 있는 방향을 생각해야 할 때가 된 것이다. 비금까지의 SAN은 진정한 의미의 ‘네트워크’라고 보기는 힘들었다. 동일한 역할을 수행하는 몇 개의 서버와 1~2개의 스토리지만을 연결하는 독립적인 SAN이 존재하는 것이 일반적인 구성이고, 서버 담당자들은 각각의 SAN을 별도로 관리하는 것이 관례처럼 여겨졌다.담당자 별로 개별 관리, 운영하는 방식에 익숙해진 서버 시스템 환경에서, SAN도 동일한 방식으로 설치돼 왔고, SAN이 워낙 개별 시스템과 관리자의 요구 상황에 맞춰져 있는 상태라 이를 굳이 통합하고자 하는 요구가 크지 않았기 때문이기도 하다.SAN의 확산과 인프라의 진화그러나 SAN 기술이 성숙되고, 이점이 널리 확산되면서 SAN의 확대 적용과 함께 비용 절감이라는 과제가 IT 관리자들에게 던져졌다. 개별 SAN을 중복해서 투자함에 따라 장비 가격의 과다 지출과 관리비의 상승이 불가피하다. 데이터 네트워크가 그랬듯이, 스토리지 네트워크에서도 확장성 있는 인프라 구축과 설계라는 진화 과정을 맞이하게 된 것이다.업계에서는 이같은 요구를 다양한 기술을 통해 수용하려 노력 중이다. 그 첫번째가 현재의 SAN 인프라 장비 자체의 용량을 확대하는 것이다. 16포트 스탠드얼론 위주의 구성에서, 64포트 이상은 물론, 256개의 포트까지 지원할 수 있는 섀시형 장비를 여러 회사에서 경쟁적으로 출시하기 시작했으며, 크기 경쟁을 유도하고 있다. 스탠드얼론 장비에 있어서도 더 이상 16포트가 아닌 32포트, 48포트 등으로 고밀도화 하고 있다.포트 밀도의 증가와 함께 진행되고 있는 것은 기능의 고도화다. 안정성과 호환성을 강조하는 수준을 넘어, SAN과 SAN의 콘솔리데이션, 그리고 대규모의 SAN 확장성을 보장하기 위한 지능화 기능이 SAN 스위치 기술에 도입되고 있다.이미 몇몇 업체들은 QoS, VSAN, 트렁킹, 보안 등의 네트워크 전송 계층 기술을 조닝(zoning), FSPF, 다양한 패브릭 서비스와 같은 파이버채널 기술과 유기적으로 결합하는 그림을 제시하고 있다.

이외에도 비용 절감에 대한 대안으로 IP-SAN 기술이 부상하고 있다. 네트워크의 진화는 별도로 존재하던 SAN을 IP의 영역으로 끌어내렸다는 평가를 받고 있다.엔터프라이즈 네트워크의 기반으로 자리잡고 있는 기가비트 스위칭 인프라는 데이터 네트워크 트래픽만을 전송하기에는 과분한 성능을 제공하고 있다. SAN을 통해 이 여유 성능을 활용할 수 있다면, 기존 투자를 보다 효율적으로 사용할 수 있는 길을 열 수도 있다. 바로 이것이 IP-SAN의 출발점이었고, 진화하는 SAN 전송 기술을 보조하는 역할을 충분히 기대할 수 있다.이와같은 해석이 CIO의 입장이라면, 일반 관리자의 입장은 바로 관리 대상의 통합을 의미한다. 바로 이때문에 네트워크 관리자가 SAN에 대한 관심을 기울여야 하는 이유다. 특히, 발전하는 스위칭 하드웨어 기술은 크로스바 스위칭 패브릭에서 이더넷 프레임과 파이버채널 프레임을 구분하지 않게 될 것이다. 스위칭 기술은 각각의 프로토콜 헤더를 광속으로 해석하고 전송함으로써, 결국 음성과 데이터의 통합과 같은 움직임을 스토리지 블럭 데이터와 이더넷 프레임 사이에서도 볼 수 있게 될 것이다.또한 미래에는 기존 SAN 관리 소프트웨어의 영역이었던 SAN 애플리케이션도 중앙의 네트워크 장비에서 직접 수행하게 될 것으로 예상된다. 기존 파이버채널 스위칭 장비들은 순수하게 파이버채널 프레임의 전송 기능에 국한된 서비스를 제공해 왔다. 업계에서는 향후 네트워크 스위칭 하드웨어가 SAN 소프트웨어 영역을 커버하게 됨으로써 관리와 서비스의 일관성, 구성의 단순화와 함께 SAN 애플리케이션의 성능 또한 하드웨어 기반으로 대폭 향상될 것으로 기대하고 있다.스토리지의 이해SAN 스위칭에 대해 이해하려면, 우선 SAN이 전송하고자 하는 것이 무엇인지 파악하는 것이 중요하다. SAN 스위치의 역할은 디스크나 테이프 백업 장비, 또는 HBA(Host Bus Adapter) 등의 스토리지 장비로부터 블록 데이터를 받아 전송하는 것이다. 즉, 전송의 최소단위는 블록 기반이며, 이 ‘블록’ 을 이해하는 것이 스토리지에 대한 이해의 시작이다.하드디스크는 정보를 일정한 단위로 잘라 저장한다. 하드디스크는 파티셔닝과 포맷이라는 과정을 통해 기록을 위한 구분선을 나누고 각 저장 장소에 주소를 부여한다. 이같은 하드디스크 내의 위치 주소가 바로 LBA(Logical Block Address)다. 물리적인 주소를 사용하지 않고, 논리적인 주소를 사용하는 이유는, 하드디스크 마다 모두 물리적인 구조가 다르기 때문이다.물리적으로는 트랙과 섹터로 구분되는 이 구조는 공장에서 제조시에 미리 지정된다. 그러나 이 구조가 다들 각각인 관계로, 일반적인 운영체제에서 하드디스크를 액세스할 때는 공통적인 방법을 취할 수 밖에 없는데, 이것이 LBA에 기준한 어드레싱이다. LBA로 구분되는 각 단위는 블록이라고 하며, 512바이트의 크기를 갖는 이것이 블록 레벨 전송이라고 하는 스토리지 액세스 방식의 기초가 된다.하지만 데이터 블록만으로는 SAN 스위칭을 할 수 없다. 스위칭은 A라는 노드에서 B로, 또는 A에서 C로 출발지와 목적지가 분명히 존재하는 것이 원칙이다. 결국 A와 B, C라는 지점을 구분하기 위한 ‘주소’ 가 필요하다.이 부분은 바로 파이버채널에서 담당하고 있다. 블럭 I/O만 존재했던 스토리지에 네트워크 I/O를 가능케한 것이 파이버채널이다. 물론 이를 위한 별도의 파이버채널 어드레스, 제어와 표준을 규정하는 다양한 레벨의 파이버채널 프로토콜 계층을 통해 이를 구현하고 있다.
이외에 눈에 띄는 부분은 중간에 위치하는 SCSI(Small Computer System Interface) 커맨드 부분이다. SCSI야 말로 스토리지 자체의 명령 체계며 핵심이다. 블록 데이터를 처리하기 위한 명령이 여기에 들어있다. 즉 데이터의 읽기나 쓰기 등의 가장 기초적인 동작 영역이 들어간다. 또한 이것은 파이버채널에서만 존재하는 것은 물론 아니라는 것을 잘 알 것이다. SCSI는 데이터 I/O 규격의 총 집대성이다. 파이버채널은 이같은 SCSI 규격을 그대로 수용해서 파이버채널로 ‘전달’하는 역할에 불과하다.정리하자면 파이버채널을 통한 스토리지 블록은 크게 3가지 영역으로 나누어진다.·파이버 채널 영역 : 파이버채널을 통한, 전송, 스위칭, 어드레싱을 담당한다.·SCSI 헤더 영역 : 데이터 블록의 처리 명령을 담고 있다.·데이터 블록 영역 : 실제 디스크에 기록되거나 디스크로부터 읽어들인 순수 데이터. 물리적인 디스크에 액세스하기 위한 위치 정보를 담고 있는 LBA를 포함한다.이같은 파이버채널 프레임을 빠르고, 정확하게 전달하는 것이 바로 파이버채널 스위치, 즉 SAN 스위치다. SCSI의 기초지금까지의 설명만 보면 많은 SAN 기반 애플리케이션은 모두 파이버채널 기술에 기반한 것처럼 오인될 수 있다. 하지만 파이버채널은 스토리지의 엔드 투 엔드 통신 과정에서 하위 계층의 전송 기술에서 그다지 많이 벗어나지 않는다. 실제 스토리지의 제어 영역은 SCSI가 대부분을 담당한다고 봐도 크게 틀리지 않다.스토리지 표준은 주로 ANSI에서 정의한다. ANSI의 산하 조직인 INCITS의 T10 그룹에서 SCSI 표준을 담당하고 있다. SAM(SCSI Architecture Model)이라고 하는 표준안은 물리적/논리적 인터페이스, 명령어 형태와 규격, 전기적 신호 규격까지 정의하고 있다. 그럼 SAM의 내용을 중심으로 SCSI에 대해 자세히 알아보자.
SCSI는 클라이언트/서버 구조로 구성돼 있다. 각 역할의 명칭이 클라이언트는 이니시에이터(Initiator : 실제로는 서버와 운영체제가 이 역할을 담당)이며, 서버는 타깃(target : 디스크 내의 SCSI 컨트롤러)으로 구분된다.여기서 LU라고 하는 굉장히 중요한 개념이 나온다. LU(Logical Unit)는 보통 번호를 붙여 LUN(Logical Unit Number)이라고 부르며, LUN은 디스크를 액세스할 때 구분자로 사용하는 논리적인 단위다.SCSI의 관점에서는 하드디스크라는 것은 존재하지 않는다. 각각의 물리적인 하드디스크는 사용자가 물리적으로 인식하는 것일 뿐, SCSI 시스템에서는 LUN이 바로 스토리지 자체가 된다. 따라서 SCSI 타깃을 액세스할 때는 반드시 LUN을 통해 접근하게 되며, LUN은 논리적인 디스크가 된다. LUN은 관리자가 관리 소프트웨어에서 임의로 생성할 수 있으며, 물리적인 디스크를 대신한다.
SAM에는 LUN을 통해 스토리지에 액세스하는 명령들이 정의돼 있다. SPC, SBC, SSC, SES 등으로 구분되는 SCSI 명령어는 CDB(Command Description Block)에 실려 발송된다.SCSI는 스토리지에 액세스하는 하위 레벨의 블록 I/O 프로토콜이며, 데이터베이스나 스토리지 관리 소프트웨어에서 운영체제를 바이패스해 직접 SCSI 명령을 전송해 스토리지를 직접 제어하기도 한다. 파이버채널의 기초파이버채널은 네트워크 I/O와 채널 I/O의 장점만 취해 만들어진 전송용 프로토콜이다. SCSI가 스토리지 서브 시스템의 제어와 물리적인 채널 인터페이스를 규정했다면, 파이버채널은 여기에 고속의 광기반 전송 시스템을 덧붙였다. 내장형 장치로써만 운영될 수 있었던 SCSI가 SAN을 통해 수정 없이 확대 사용할 수 있게 된 것도, 파이버채널 전송 시스템의 덕이다.파이버채널 프로토콜은 SCSI 시스템을 그대로 수정없이 계승할 수 있도록, SCSI 블록을 캡슐화해 전송한다. 또한 각 SCSI I/O 동작을 파이버채널 프로토콜에 맵핑함으로써 각각의 I/O 요청과 응답에 파이버채널이 효율적으로 연동할 수 있게 했다.파이버채널은 양방향의 포인트 투 포인트 시리얼 데이터 채널로, 상위 프로토콜에 독립적인 구조를 갖는다. 다시 말해, 파이버채널을 통해 SCSI 데이터만 전송하는 것이 아니라, IP도 전송할 수 있다는 얘기다. 파이버채널을 단순한 스토리지 전용 전송 규격으로 생각하면 안된다. 다만, 스토리지 블록 전송 용도로 가장 널리 사용되고 있는 수단이므로 파이버채널 기술을 이해하는 것이 SAN 인프라를 이해하는 가장 직접적인 방법이 될 것이다.
파이버 채널로 SAN을 설계할 때는 크게 3가지 방식을 사용할 수 있다. 첫번째는 포인트 투 포인트의 1:1 연결이다. 파이버채널을 통해 스토리지와 호스트를 직접 연결하는 경우가 대표적으로, DAS 환경에서 파이버채널을 전송 매커니즘으로 사용하는 것이 전형적인 예다. 두번째는 스위치 패브릭을 통해 다양한 파이버채널 지원 장비를 연결하는 환경으로, 전형적인 패브릭 기반 SAN 스위칭 환경이다. 마지막 세번째는 링 형태의 환형 연결 구조(루프 토폴로지)다. 같은 링 내의 파이버채널 장비들이 대역폭을 공유하면서 사용하는 방식으로, 최근의 SAN 스위치들은 스위칭 패브릭 구조에서도 링 토폴로지를 수용하는 혼합 구조를 지원한다. 이것은 과거의 파이버채널 장비들이 링 형태의 FC-AL만을 지원하고 패브릭 접속을 지원하지 못하는 경우가 있었기 때문이다.이런 3가지 구조가 SAN 스위치에서 통합 지원됨은 물론이다. SAN 에서는 파이버채널을 스위칭하기 위한 기반 아키텍처를 패브릭이라는 이름으로 부른다. 스위칭 패브릭은 주로 네트워크 업계에선 백본 스위치에 내장된 스위칭 하드웨어 부분을 의미했지만, SAN에서 말하는 패브릭은 SAN 전송 인프라 자체를 의미한다. 따라서 패브릭은 하나의 SAN 스위치 내부에 존재할 수 도 있지만, 여러 개의 SAN 스위치 내에 공유되는 스위칭 기반이라고 해석하는 것이 좋을 것이다.
스위치드 패브릭에서는 다양한 포트 타입을 정의하고 있다. 포트 타입은 기존 네트워크에서도 존재해 온 개념이다. DTE나 DCE와 같이 역할에 따라 인터페이스의 종류가 달라진다는 것은 이미 알고 있을 것이다. SAN에서는 이같은 포트의 종류가 훨씬 다양하게 구분된다.·N_port : 단말장비가 연결된 포트를 말한다. 스토리지에 장착된 파이버채널 인터페이스나, 호스트에 연결된 HBA의 인터페이스가 N_port다. 앞에서 언급했던 3가지 구성 중, 첫번째의 포인트 투 포인트 형태는 바로 N_port끼리 연결된 것이다.·NL_port : 단말 장비가 퍼블릭 루프 토폴로지에 접속될 때, NL_port가 된다.·FL_port : NL_port가 퍼블릭 루프 네트워크에 접속할 때, 스위치 측 포트가 FL_port다. 퍼블릭 루프는 패브릭에 로그인하는 과정을 통해 패브릭에서 인식할 수 있다.·F_port : N_port가 스위칭 패브릭 토폴로지에 접속할 때, 스위치 측 포트는 F_port로 동작한다.·E_port : 패브릭 내의 스위치와 스위치 간의 접속시에 사용하는 포트로 확장 포트(Expansion Port)를 의미한다.·G_port : 접속하는 장비의 종류에 맞춰 자동으로 F_port나 E_port로 설정되는 스위치 포트.·TE_port : 다중의 VSAN을 트렁킹할 수 있는 E_port를 의미한다(Trunking E_port). VSAN 태그를 갖는 Extended ISL 프레임을 처리할 수 있다.·TL_port : 사설 루프(Private Loop) 장비를 패브릭에 연결할 때 사용하는 포트(Translative Loop port). 사설 루프 장비는 패브릭을 인식하지 못하며, 로그인을 하지 않는다. 따라서 통상적으로는 스위칭 패브릭을 통해 통신이 불가능하다. 이를 위해 별도의 주소를 부여하고, 매핑을 통해 사설 루프 장비를 패브릭에 접속할 수 있도록 해주는 포트다.일반적인 네트워크를 OSI 7 계층 모델로 설명하듯이 파이버채널 네트워크도 동일한 기준으로 나눠 정의할 수 있다.이중 물리적인 전송 매체와 송수신 인터페이스에 대해 정의하는 부분이 FC-0 물리 계층이며, 8b/10b 방식의 인코딩/디코딩와 에러 제어를 수행하는 FC-1의 전송 계층, 시그널링 프로토콜을 정의하는 FC-2 프로토콜 계층에서는 디렉토리 서비스와 같은 일반적인 서비스와 기본/확장 링크 서비스가 정의돼 있다. 또한 SAN 환경에서 자주 논의되는 흐름 제어와 버퍼 관리가 수행되는 계층이기도 하다.이외에도 공통 서비스 계층인 FC-3와 파이버채널 상위의 스토리지 계층 프로토콜인 SCSI, IP 명령어들과의 매핑을 담당하는 FC-4 매핑 계층이 있다.각 계층의 역할과 정의에 대한 구체적인 내용은 본 연재의 범위를 넘어서므로 좀더 자세한 사항에 대해서는 관련 문서를 찾아보기 바란다. @