개요

네트워크 스토리지, 전성기 활짝

스토리지 시스템은 스토리지 기술자들과 마찬가지로 변화를 수용해야만 하며, 이러한 변화의 주도 세력이 새로운 애플리케이션이든, 정부나 산업 규정이든, 아니면 임대 계약 만기와 같이 간단한 것이라도 마찬가지다.

서버와 스토리지를 관리하느라 시간을 보내 본 사람이라면 누구든 주저 없이 업그레이드가 잘못된 데 대한 최소한 몇 가지 끔찍한 얘기들을 풀어놓을 수 있을 것이다. 백업 테이프가 읽히지가 않았다. 볼륨 카피가 알 수 없게 실패했다. 쓸데없이 테이프와 디스크 드라이브를 새 것과 낡은 것 모두 몇 시간째 만지고 난 후, 소중한 데이터를 복구할 수 없거나, 가능하다고 해도 매우 힘들다는 사실을 알면 등골이 오싹해진다. 이런 경험을 통해 제대로 돌아가는 스토리지 시스템에 대해 엄청난 존경심을 갖게 된다. 그리고 “제대로 돌아가면 절대 그것을 고치지 말아야지!”라는 생각도 한다.
하지만 스토리지 시스템은 스토리지 기술자들과 마찬가지로 변화를 수용해야만 하며, 이러한 변화의 주도 세력이 새로운 애플리케이션이든, 정부나 산업 규정이든, 아니면 임대 계약 만기와 같이 간단한 것이라도 마찬가지다. 가장 흔히 사용되는 스토리지 시스템은 서버 인클로저에 드라이브 더미들을 쌓아놓는 것으로, 변화와 관련해 일어나는 재앙에 가장 취약한 경향이 있다. 이번 전문가 시리즈에 실린 많은 이야기들이 특히 유연한 데이터 저장 방안을 강조하고 있는 것도 바로 이런 이유에서다.

유연한 데이터 저장 방안 강조
대기업들에게는 네트워킹 스토리지 시스템이 가야 할 길이라고 설득시킬 필요가 없다. SAN(Storage Area Networks)이 글로벌 2000 기업들 사이에서는 유비쿼터스가 돼 있긴 하지만, 이들은 변화 관리와 데이터 이동성(mobility) 문제를 무시하지 않기 때문이다.
스토리지 가상화는 이런 과제를 해결할 수 있다고 약속하지만, 이 기술의 상당수는 아직 새로운 것으로 현장 검증이 필요한 것들이다. 대부분의 주요 스토리지 업체들이 가상화 방안을 선택했으며, 이제는 늘 해오던 익숙한 아이쇼핑을 할 때가 됐다. 많은 가상화 솔루션의 중추라고 할 수 있는 지능형 파이버 채널 스위치에 대해 이 부문을 담당하고 있는 돈 맥비티가 나섰다.
중소업체들의 경우 필요성이 덜하진 않지만 예산은 더 빡빡하다. 하지만 이들이 SAN 기술의 채택을 망설이는 것은 전문기술이 부족해서다. 파이버 채널을 구입한다고 해서 예산이 거덜나는 게 아니지만 대부분의 IT 조직들은 신기술을 배우고 관리할 수 있을 만한 처지가 못된다. 이들에게 iSCSI가 선택으로 떠오르고 있으며, 스티븐 힐이 iSCSI SAN 칼럼에서 이 부분을 다뤘다.

어디서나 보호하라!
모든 규모의 기업들이 공유하고 있는 한 가지 문제는 데이터가 존재하는 곳 어디서나 이것을 보호해야 한다는 것이다. 이것이 정부 및 산업 규정을 준수하는 것이든, 아니면 좋은 비즈니스 감각에서 나온 것이든 간에, 스토리지 보안 정책을 만들고 시행하는 것은 필수다. 일단 정책이 만들어지면 다음은 솔루션을 구하러 다녀야 한다. 스토리지 보안은 너무도 중요하기 때문에 우리는 여기서 몇 가지 관련되는 이야기들을 담았다. 돈 맥비티가 보안의 베스트 프랙티스에 대해 기사를 쓰고, 론 앤더슨이 이메일 기록보존(archiving) 솔루션들을 평가했다.
물론 파일 네이밍(file-naming) 정책을 처음부터 시행하지 않고서 완벽한 스토리지 시스템은 없다. ‘최고의 예술, 데이터 네이밍’에서는 존 토이고가 비즈니스 매니저와 엔드유저로부터 입수한 좋은 네이밍 방안 만들기 방법을 담았다. 그리고 ‘ILM, 무엇이 문제인가?’에서는 브래드 오닐이 필수 표준과 기술 통합이 아직 현실이라기보다는 약속에 가까운 ILM(information lifecycle management) 시장을 분석했다.
이 스토리지 특집 기사는 여러분이 스토리지 계획 및 구축을 시작하는 데 있어 큰 도움이 될 것이다.

스토리지 가상화

비용 절감·데이터 관리 능력 향상, ‘필수품’

스토리지 가상화는 비용을 절감하고 데이터 관리 능력을 향상시켜 주며, 산업 및 정부 규정 준수를 도와준다고 약속하고 있다. 이 기술이 이렇게 충분히 성숙했다면 과연 가장 좋은 방안은 어떤 것일까?

Takeout

- 스토리지 가상화는 네트워크 패브릭이나 호스트, 혹은 파일 레벨에서 이행이 될 수 있으며, 각각의 방안에 대해 찬반 논란이 있다.
- 많은 어레이에서 SAN 볼륨은 애플리케이션의 필요에 따라 늘어날 수 있기 때문에 스토리지의 활용성이 높아진다.
- 파일 레벨 가상화는 예를 들어 전체 조직에서 하나의 글로벌 네임 공간으로 표시될 수 있게 해주는 등의 추가 이점들이 있다.

스토리지 아키텍트는 데이터 인프라의 신뢰성과 유연성, 그리고 관리 능력을 향상시킬 수 있는 방법을 모색하고 있으며, 가상화가 이것을 기존의 솔루션보다 종종 훨씬 더 저렴하게 가져다 줄 수 있다. 물론 각각의 가상화 전략에는 나름대로의 장단점이 있기 마련이지만, 이들 모두의 중심은 한 가지다. 즉 서버와 스토리지 사이뿐만 아니라, 스토리지 어레이들 사이에 반드시 가상화가 돼야 할 네트워크가 있다는 것이다.
이것은 FC(Fibre Channel)나 iSCSI SAN이 될 수도 있고, 심지어 네트워크 접속 NAS 파일러(filer) 세트가 될 수도 있다(데이터 풀링과 데이터 이동성을 원활하게 할 수 있는 일종의 네트워크만 있다면).

업체간 기술 경쟁 치열
가상화를 위한 한 가지 방법은 어레이의 컨트롤러에 이 기능을 탑재하는 것이다. 하이엔드 어레이를 구입하는 사람들은 단단하고 신뢰할 수 있는 시스템에 많은 투자를 해왔다. 단일 오류 지점은 없으며, 어레이 컨트롤러는 방대한 양의 컴퓨팅 능력과 I/O 대역폭을 지원할 수 있도록 단계적으로 강화될 수 있다. 게다가 어레이 컨트롤러는 지난 몇 년 동안 훨씬 더 똑똑해졌다. 데이터 미러링(data mirroing)과 스냅샷(snapshot)을 포함한 일군의 많은 애플리케이션들이 어레이 컨트롤러에서 성장해 왔다.
많은 어레이들에서 SAN 볼륨은 애플리케이션이 필요로 하는 만큼 대폭적으로 확대되어 스토리지 활용도를 엄청나게 향상시켰다. 이러한 모든 기능성은 어레이 컨트롤러에 존재하며, 따라서 컨트롤러를 조금 더 향상시켜 이것이 외부적으로 액세스되는 스토리지에서 뿐만 아니라 내장 스토리지에서도 가능하게 할 수 있지 않겠냐는 의문이 생겼다. HDS (Hitachi Data Systems)와 이 회사의 제품을 재판매하는 썬, HP 등에서 현재 이 방안을 택하고 있다.
하지만 가상화 장소로 네트워크 패브릭을 선호하는 사람들에게도 선택의 여지는 있다. 이들은 패킷을 저장 후 전송하는 어플라이언스와 회선속도 스위치 중에 선택을 할 수 있다. 이러한 선택을 하는 과정에서는 아마도 수많은 신생업체들과 IBM, EMC를 만나게 될 것이다.
IBM은 캐싱 어플라이언스를 사용하는데, 이것은 결국 디스크가 없는 컨트롤러(diskless controller)에 이르고 있다. IBM SVC(SAN Volumn Controller)는 전형적으로 애플리케이션 호스트와 스토리지 장비 사이에 있는 스토리지 패브릭에 위치하며, 성능 필요에 따라 쌍으로 또는 클러스터로 이행될 수 있다. SVC는 스토리지 컨트롤러처럼 작동하기 때문에, IBM의 관리 및 데이터 이동성 애플리케이션은 거의 아무런 변경없이 SVC로 이식되고 있다. 그리고 SVC는 스탠드얼론 어플라이언스기 때문에 대부분의 어떠한 SAN 스위치나 스토리지 어레이와도 작동이 가능하다.
개발 과정에서 ‘스토리지 라우터’라고 불린 EMC의 인비스타(Invista)는 소위 말하는 브로케이드, 시스코 및 맥데이터 등과 같은 업체들의 ‘지능형 스위치’와 CPC(Control Path Cluster)라는 별도의 어플라이언스 세트가 필요하다. 여기서 CPC는 테이블을 라우팅하고 메타데이터를 관리하는 것을 만들어 주는 역할을 하게 된다. 테이블은 지능형 스위치에 의해 FC와 SCSI 어드레스를 회선 속도로 다시 쓰는 데 사용되며, 이러한 능력은 아키텍처를 고도로 확장성 있게 해주지만 복잡성도 그만큼 추가된다.

업체마다 이용 방법 달라
호스트 기반 가상화는 서버에 상주하는 에이전트(server-resident agent)를 이용해 FC와 SCSI 어드레스를 다시 쓰며, 그 대행자는 부팅 때 프로그래밍되고 필요에 따라 제어경로 매니저(control path manager)에 의해 업데이트된다. 이 방안은 베리타스 소프트웨어(Veritas Software)나 스토어에이지(StoreAge)와 같이, 주로 스토리지 관리를 지원하는 호스트 대행자를 개발했던 업체들에 의해 한동안 사용돼 왔다.
스토리지 공식에 네트워크 파일 시스템을 집어넣으면 확실한 가상화의 기회가 생기게 된다. 저장된 데이터의 로케이션을 파일 시스템이 추적하고, 따라서 이것은 파일 이름에 영향을 미치지 않고 물리적으로 옮겨질 수 있다. 제품을 차별화시키는 요소는 이러한 이동이 자동화된 정도와 이것이 작동 중인 애플리케이션을 얼마나 많이 방해하느냐다.
한편 파일 레벨에서의 가상화를 이용하는 곳들도 있다. 예를 들어 조직 전체에서 하나의 글로벌 이름 공간이 제시될 수가 있다. 수많은 업체들이 이 시장에서 활동하면서 글로벌 파일 시스템, NAS 위의 가상화 NAS, 혹은 SAN 위의 NAS 등을 다양하게 공급하고 있다. 현재까지는 g파일러(gFiler)란 이름이었던 V시리즈(V-Series)를 내놓고 있는 네트워크 어플라이언스(Network Appliance)가 가장 큰 점유율을 차지하고 있다.

iSSCSI 스토리지

파이버 채널 딛고 ‘이륙 준비 완료!’

iSCSI는 SAN 시장의 불과 2%를 차지하고 있지만, 저렴한 비용과 사용의 편의로 성장 일로를 걷고 있다. 본지에서 네 가지 iSCSI 모듈러 SAN을 평가해 본 결과, 경쟁자를 압도하는 에디터즈 초이스를 찾을 수 있었다.

Takeout

- 저렴한 비용과 단순성은 파이버 채널에 충분히 맞설 수 있는 iSCSI 스토리지의 경쟁력이다.
- 어떤 기가비트 환경에나 iSCSI SAN을 꽂을 수 있다.
- iSCSI 이니시에이터(initiator)는 윈도, 리눅스, 유닉스, 네트웨어 및 맥 OS X용이 나와 있다.

지난 2003년 2월 iSCSI 표준이 비준되기까지, SAN 시장의 판도는 매우 간단했다. 파이버 채널(FC)을 구입하면 됐기 때문이다. 물론 FC 스토리지가 여전히 새로 형성되고 있는 대형 SAN 기반에서 큰 몫을 차지하고 있긴 하지만, 이제는 iSCSI도 점점 힘을 얻어 가고 있다. IDC에 따르면 iSCSI 스토리지 기술은 현재 전체 네트워크 스토리지 판매량의 약 2% 남짓을 차지하고 있지만, 그 매출은 2004년 4분기에서 2005년 1분기에 이르는 동안 22%나 증가했다고 한다.

저렴한 비용과 단순성으로 ‘인기’
이러한 급성장의 주 원인은 FC와 비교할 때 iSCSI SAN 플랫폼의 저렴한 비용과 단순성 때문이다. iSCSI SAN 모듈은 전통적인 네트워크 트래픽과 마찬가지로 스위칭 및 라우팅되는 어떠한 기가비트 환경에든 꽂힐 수 있으며, 특정 호스트 버스 어댑터(Host Bus Adapter) 없이도 어떠한 호스트로든 확장 가능한 블록 레벨의 스토리지를 제공한다. 대부분의 경우 iSCSI SAN을 셋업하는 데는 몇 분이면 충분하며, 더 이상의 교육이나 전문 인력은 전혀 필요하지 않다. 나아가 윈도, 리눅스, 유닉스, 네트웨어 및 매킨토시 OS X용으로 iSCSI 이니시에이터(initiator)를 사용할 수 있다.
모듈러 iSCSI SAN은 네트워크 스토리지 통합이 필요한 중소기업들이 시작하기 부담없는 솔루션이다. 엔터프라이즈급에서는 iSCSI SAN이 세컨 티어(second tier), 부서용 및 원격 사무소 서버용의 주 스토리지를 제공할 수 있으며, D2D2T(disk-to-disk-to-tape) 백업용이나 장애복구 대비 원격 복제용 보조 스토리지의 역할도 할 수 있다. 고밀도 윈도 컴퓨팅 환경에서 iSCSI는 블레이드 서버나 클러스터용으로 편리한 SAN 부팅(boot-from-SAN) 기능을 갖고 있다. iSCSI SAN은 심지어 대학이나 기타 캠퍼스 기반 환경처럼 분산된 이더넷 기반의 스토리지 풀이 매우 효과적인 곳에서도 큰 인기를 끌고 있다.
자신들의 기존 NAS 제품에 가상의 블록 레벨 iSCSI 볼륨 지원을 추가하는 대신 iSCSI SAN 전용 제품을 만들고 있는 주류 업체들은 상대적으로 얼마 되지 않는다. 파일 레벨과 블록 레벨 스토리지의 혼합을 필요로 하는 환경에서는 이런 솔루션들이 얼마간의 편의를 제공해줄 수 있겠다.
우리는 블록 레벨 스토리지를 전문적으로 제공하는 SAN 전용 제품에 초점을 두고 다음과 같은 iSCSI SAN 전용 제품 네 가지를 위스콘신 주 그린베이의 리얼월드 랩에서 테스트했다. 레프트핸드 네트워크(LeftHand Network)의 NSM 150, MPC의 데이터프레임 420 (DataFrame 420), 이퀄로직(EqualLogic)의 PS200E, 그리고 EMC의 클라리온 CX300i(Clariion CS300i)가 테스트된 제품이다.
이퀄로직과 레프트핸드, 그리고 MPC 제품은 독립 SAN 모듈로서, 역동적으로 확장 가능한 환경으로 가상화될 수 있으며, 100TB 아래 범위를 타깃으로 하고 있다. 이 기초적인 전제 장비는 다중 모듈 클러스터링과 이들의 활성 GbE 포트를 통한 선형 대역폭 증가와 다중 스토리지 컨트롤러의 이점을 활용하고 있다.
이와 대조적으로 EMC 유니트는 독립적인 다중 디스크 어레이를 관리하는 중앙 스토리지 컨트롤러라는 전통적인 SAN 모델을 이용하고 있다. 이 아키텍처가 추가 디스크 어레이 비용을 없애주긴 하지만 CX300i는 최대 60개 드라이브와 최고 19.2TB의 속도를 지원한다. 추가 드라이브 캐비넷이 듀얼 FC 루프와 연결되지만, 사용 가능한 GbE 포트 수가 드라이브 인클로저를 추가할 때와 같기 때문에 대역폭 병목 가능성을 신경써야 한다.

이퀄로직 PS200E ‘최우수상’
네 개 시스템들은 모두가 iSCSI의 기본이라고 생각되는 기능들을 갖추고 있었는데, 이러한 기능들로는 역동적 볼륨 확장, 스냅샷 및 복제 기능, CHAP 지원, iSNS 탐색 및 LUN 마스킹 등이 포함된다. 모든 경우에 디스크 어레이가 스토리지 풀에 추가될 수 있으며, 이 풀은 중앙 콘솔에서 관리되고 생산 설비의 중단없이 할당이 된다. 단 재할당 기간 동안 어레이 성능은 떨어질 것이다. 테스트한 모든 SAN에는 모든 슬롯에 드라이브가 탑재돼 있었지만, 네 제품 모두 서너 개의 초기 드라이브만으로도 구성이 가능하고 향후 성장에 대비한 다양한 드라이브 크기 옵션들을 제공하고 있었다.
우리의 성능 테스트 결과 이퀄로직 PS200E가 경쟁자들을 물리치고 에디터즈 초이스로 선정됐다. EMC의 클라리온 CS300i는 폭넓은 구성 옵션을 갖고 있으며 EMC 장비 설치 기반이 있는 환경에 매우 잘 맞겠지만, EMC와 우리가 마감 기한까지 풀지 못한 문제들이 있었다. 즉 CX300i는 더 작은 전송기들은 예상처럼 작동했음에도 불구하고 64K 크기에서의 아이오미터 읽기 테스트에서 심각한 문제가 있었으며, 같은 곳에서의 쓰기 테스트에서도 의문스러운 결과가 나왔다. EMC는 그 이후 이 문제를 해결했다고 전해왔다.

데이터 네이밍

스토리지 혼란 피할 수 있는 ‘최고의 예술’

일반 직원들은 파일을 만들어 내지만 IT는 규정을 따르고 스토리지의 혼란을 피할 수 있게 해주는 네이밍 정책을 만들어야 한다.

Takeout

- 데이터 등급분류(classfication) 방안은 비즈니스 프로세스와 워크플로우를 기반으로 해야 한다. 처음부터 바로 애플리케이션으로 가서는 안 된다.
- 조직의 네이터 네이밍 플랜을 만들 때는 사용자와 비즈니스 매니저가 함께 참여하도록 하라.

사용자가 만든 파일을 담고 있는 기업 스토리지 시스템에 있어서는 브리트니 스피어스의 불법 비디오 파일이나 회사의 기간 마케팅 비디오나 둘 다 .mpg로 끝나는 한 다를 게 없다. 그 이유는 스토리지 중심 방안은 데이터 관리의 핵심 문제, 즉 데이터 네이밍(data naming)을 공략하는 게 아니기 때문이다.

일관성이 없다
파일명이 일관성 있고 지능적으로 붙여져 있다면, 파일 관리는 훨씬 덜 고통스러운 작업이 될 것이다. 하지만 불행히도 사용자들은 종종 데이터 네이밍에 있어서는 계층적 스토리지 관리(Hierarchical Storage Management), 백업/복구 및 콘텐츠 추적 등과 같이 자동화된 데이터 관리 프로세스를 위한 관심이나 안내가 거의 없이 원하는 이름을 마음대로 갖다 붙이고 있다. 그리고 파일의 중대성(file criticality), 프라이버시 필요조건, 액세스 및 업데이트 빈도, 그리고 보유의 필요성 등과 같은 일반적인 속성을 기반으로 한 통일성 있는 데이터 등급분류 방안을 따라가기가 사실상 불가능하다는 사실을 깨닫고 있는 회사들도 있다.
파일은 자신들을 만들어 낸 비즈니스 프로세스로부터 등급분류의 속성을 물려받는다. 예를 들어 파일 중대성이란 파일이 장애복구 상황에서 얼마나 중요한지를 나타내는 것으로, 비즈니스 프로세스의 중대성과 연결된다.
이러한 정황 분석은 또한 특별한 프라이버시 보장이 돼야 하거나, 혹은 법적이나 규정상의 이유로 일정 기간 동안 보유해야 하는 파일을 식별하는 데 도움이 될 수 있다. 다른 파일들은 SEC(Securities and Exchange Commission) 규정에 따라 일정 기간 후에 삭제 표지됨으로써 ‘데이터 사용중지(data decommission)’ 명령 프로그램을 실천해야 한다. 파일 보유 및 폐기처분의 지적 자산권이나 거래 기밀도 또한 특별하게 다뤄져야 할 것이다.
그리고 시간이 경과하는 동안의 파일의 유용성을 식별해 내는 것도 보통 일이 아니다. 예를 들어 분산형 HSM(Hierarchical Storage Management)은 기록보존 스토리지에 안전히 마이그레이팅될 수 있는 거의 찾지 않는 파일과, 빈번하게 찾지만 변경되지는 않는, 웹사이트 콘텐츠와 같은 소위 ‘레퍼런스 데이터’를 분간할 수 없다. 하지만 HIPAA(Health Insurance Portability and Accountability Act) 같은 법률 조항에 따르면 환자 관련 파일은 수십년 동안 보관해야 하며, 어떤 경우 환자의 수명에 75년을 더 보관해야 하기 때문에, 오랜 세월 동안 플랫폼을 옮겨 다녀야 하는 일을 겪지 않을 수가 없다.

전통 파일 시스템을 데이터베이스로 교체
데이터 등급분류 방안을 확보하기 위해서는 비즈니스 프로세스를 구성하는 작업과 워크플로우를 한 가지 목록으로 조직화시켜야 한다. 일단 이런 요소들이 정리가 되면 지원 애플리케이션과 이들이 만들어내는 데이터가 신중하게 그려질 수 있다. 그리고 그 결과는 그리드(grid)로 만들어진다. 데이터 객체를 열로 만들어 세우라. 그런 다음 사용자와 비즈니스 매니저와 함께 의논하여 속성들을 행으로 정리하라.
중대성, 액세스 빈도, 보유 필요조건, 삭제 필요조건, 특수처리 필요조건 등과 같은 속성들이 지정돼야 하며, 각각의 데이터 객체와 연관돼야 한다. 이런 데이터를 소팅해서 서로 다른 데이터 객체들 사이에서 공통적인 속성을 찾아낼 때 데이터 등급이 드러난다. 어떠한 특정 수치로 등급이 지정되는 것은 아니며, 모든 기업이 나름의 비즈니스 프로세스를 갖고 있기 때문에, 어느 한 가지 지존의 방안이 존재하는 것은 아니다.
데이터 마이닝에서 골치 아픈 부분은 파일들이 만들어졌을 때 여기에 방안을 적용시킬 수 있는 방법을 찾는 일이다. 이들이 필요로 하는 엔드유저 참여의 양과, 이들의 이행이 기술적인 게 아니라 프로시저적인 수단에 의존하는 정도에 따라 대안 솔루션들을 표에 정렬해 두는 게 도움이 될 수 있다. 하지만 전체적으로 이런 방안들은 과거 이력이 그리 좋지 못하다.
또 한 가지 방안은 각각의 파일 유형에 적합한 디렉토리 세트로 사용자 아웃풋을 캡처하는 것으로, 뉴뷰(NuView)와 같은 글로벌 네임 공간 시스템 지지자들이 밀고 있다.
파일 시스템 교체도 또 하나의 잠정적인 솔루션이 된다. 지난 10년 동안 IBM, 마이크로소프트 및 오라클은 전통적인 파일 시스템을 데이터베이스로 교체함으로써 데이터를 보다 잘 조직화했다. 그리고 이것을 보다 빨리 검색하고, 특정 객체에 특정 속성을 연관시킴으로써 이들이 그룹으로 선택 및 관리될 수 있게 한다는 것에 대해 이야기해 왔다. 이러한 교체가 사용자에게 투명하다면 이것은 우리가 현재 구조화 데이터를 정렬할 수 있는 것과 같은 수준으로 파일을 조직화할 수 있게 해줄 것이다.
현재로서는 적어도 최소한으로 제대로 해내는 방안을 택하고, 기술이 성숙함에 따라 보다 정밀한 데이터 정의 및 분리 능력을 더해간다는 계획을 세우는 게 최선이겠다.

스토리지 스위치

지능적인 스토리지 스위치, ‘비상(飛上) 준비 완료’

SAN 서비스를 호스트와 어레이에서 스위치로 이동시킨다는 개념이 제 시대를 맞고 있다. 파이버 채널 패브릭을 지능적으로 만드는 게 무엇인지, 여기서 어떤 이점을 기대할 수 있는지, 그리고 왜 일부 스토리지 전문가들이 여전히 회의적인지를 살펴봤다.

Takeout

- PC 스위치에서 소프트웨어를 실행시킴으로써 호스트 소프트웨어를 제거하고, 스토리지 어레이들간 상호운용성을 유지할 수 있다.
- 복제 및 가상화 애플리케이션은 서버에서보다 스위치에서 이행이 보다 간편하고 더욱 효율적인 실행이 가능하다.

파이버 채널 SAN에서는 백업에서부터 관리에 이르는 작업을 수행하기 위한 많은 소프트웨어가 필요하다. 그렇다면 소프트웨어가 상주할 수 있는 최적의 장소는 어디일까? 어레이? 하나 이상의 호스트 서버? 6년 전 업체들은 또 다른 장소를 떠올렸는데, 바로 FC 스위치였다. 그리고 오늘날 마침내 FC 스위치와 이들이 지원하는 지능형 패브릭 아키텍처는 마침내 우리가 평가해 보기 충분할 만큼 성숙했다.
우리는 패브릭 스위치를 날아다니고 있는 데이터와 상호작동을 하는 애플리케이션이나 펌웨어를 돌릴 수 있는 스위치로 정의를 내렸다. 여기에는 애플리케이션이 기능을 하도록 하는 충분한 프로세싱 파워와 메인 메모리, 그리고 애플리케이션을 유지할 일종의 장기적 메모리, 보통은 플래시가 필요하다. 여기서 핵심 요소는 SAN의 다른 어딘가에서 스위치로 성능 손상 없이 기능성을 옮길 수 있는 능력이다.
어떠한 대기시간이든 존재하는 환경에서의 호스팅 애플리케이션은 받아들일 수 없기 때문에, 이것은 CPU 시간을 조정하고 메모리의 차이를 메꾸는 것보다 훨씬 더 많은 것을 전제로 한다.

평가할 만큼 성숙
소프트웨어를 FC 스위치에서 돌림으로써 얻을 수 있는 주된 이점은 호스트 소프트웨어를 없애면서 동시에 스토리지 어레이들간의 상호운용성을 유지할 수 있다는 점이다. 전형적인 FC 환경에서는 일부 소프트웨어(복제 프로그램 등)는 어레이에서 돌아가고 다른 애플리케이션들(가상화 등)은 SAN에 액세스하는 각각의 호스트에서 대행자로서 운용된다. 하지만 이러한 방식에는 문제도 또한 있는데, 예를 들어 호스트 에이전트를 돌리고 있으면 액세스가 필요한 각각의 호스트에 반드시 소프트웨어를 설치해야 한다는 것이다.
따라서 자동 배포 소프트웨어가 있다 하더라도 건드리는 기계가 많아지면 일이 잘못될 가능성이 그만큼 커진다. 게다가 소프트웨어가 어레이에서 돌아가면 보통 업체에게 구속되는 문제를 직면하게 된다. 즉 소프트웨어를 이 시스템에서 돌릴 경우 어레이 업체를 자유롭게 바꿀 수가 없을 것이다.
하지만 전형적으로 에이전트 기반인 소프트웨어에 대해 FC 스위치는 호스트에 아무 것도 설치할 필요없이, 운영시스템에 독립적으로 에이전트에 의해 한번 수행만 되면 된다. 그리고 얼마간의 업체 구속성이 있긴 하지만 이것은 보다 덜 비싼 스위치나 어플라이언스 레벨에서다.
물론 모든 애플리케이션이 스위치에서 효과가 있는 것은 아니다. 예를 들어 최고 파워의 백업은 서버를 써야 소중한 스위치 자원을 아낄 수 있다. 하지만 복제(replication)와 가상화(virtualization)는 스위치에서 이행이 더 쉽고 효율적이다.
복제는 약간의 지능을 내장한 스위치에 의해 ‘포트 맵(port map)’이나 ‘포트 미러(port mirror)’로서 간단히 이행될 수 있을 것이다. 쓰기 명령어가 스위치에 입력되면 스위치는 데이터를 LUN(Logical Unit Number)이 쓰여지고 있는 포트 밖으로 내보내는 대신 카피를 두 개의 포트 밖으로 보낸다. 여기서 포트 하나는 프라이머리용이고 다른 하나는 복제용이다. 쉽고, 빠르고, 지능형 스위치를 제외한 모든 것이 독립적이며, 스위치 업체가 복제를 지원하지 않기 때문에 별도의 복제 툴을 필요로 하지 않는 한 업체 구속성도 전혀 없다.
물론 데이터를 두개의 포트 밖으로 전송하는 것 이상이 있긴 하지만 여기서부터는 지능이 개입이 된다. 복제 타깃이 어디로 향하게 돼 있는지를 알 수 있도록 복사된 패킷에 있는 목적지 정보가 바뀌어야 하지만, 이것은 약간의 프로세싱 파워와 약간 느린 속도로 복제할 수 있는 능력만 있으면 가능하다.

호스트에 에이전트 필요 없어
가상화에서도 마찬가지로 스위치를 스토리지 프록시로 변형시킨다. 매핑 테이블(mapping table)은 가상 LUN과 이들 상의 블록으로 이루어지며, 물리적 디스크 로케이션과 상응한다. 이 매핑 테이블은 유지보수되며 필요한 경우 OS가 가상 LUN으로 쓰기를 요청한다. 다른 일부 엔티티는 매핑 테이블을 이용해 이 정보를 정확한 물리적 로케이션으로 번역하기도 한다. 보통 이 다른 엔티티는 인라인 어플라이언스거나 호스트 에이전트로서, 각각의 OS용으로 쓰여지고 관리되며, SAN으로의 액세스가 필요한 각 호스트에 배치돼야 하는 전문 드라이버가 된다.
가상화 소프트웨어를 스위치로 이동시킴으로써, 호스트 에이전트가 등식에서 제외된다. 대신 인라인 어플라이언스와 이것이 가져오는 대기시간이 제거될 수도 있다. 프로세싱은 스위치에서 이뤄지기 때문에 데이터는 두 번이 아니라 한 번만 멈춰 서면 된다.
한편 스위치는 표준 FC 패킷을 확보함으로써 어떤 OS가 요청을 만들던 관계없이 모든 OS에 대한 지원이 자동으로 제공된다. 그리고 스위치에서 돌아가는 소프트웨어는 가상 로케이션에서 물리적 로케이션으로 매핑하기 때문에 호스트 에이전트가 필요치 않다.