기업 스토리지의 열쇠. iSCSI SAN

System/Storage 2011. 10. 28. 11:09

NAS가 이길까, SAN이 이길까"

불과 2, 3년 전만해도 수 많은 국내외 IT관련 월간지나 정보지 등의 특집 기사 제목이나 칼럼의 소제목으로 자주 등장했던 말이다. 서기 2003년의 스토리지 업계에서 이 말처럼 시대에 뒤떨어지고 진부한 말도 없을 것이다. NAS(Network Attached Storage)와 SAN(Storage Area Network)은 모두 한가지 큰 목적을 가지고 시장에 등장했다. 흩어져 있는 디스크를 한곳에서 집중 관리하고 서버는 그 중앙 스토리지가 나누어주는 디스크 공간을 '네트워크'를 통하여 할당 받고 사용하자는 아이디 어이다. 이러한 것을 '네트워크 스토리지(Networked Storage)'라고 부른다. NAS는 이더넷(Ethernet)을, SAN은 파이버 채널(Fiber Channel)을 중간 매개체인 '네트워크'로 선택해서 발전 해 왔다. 어느쪽이 더 좋은 성능을 내고 더 안정적인가를 논한다는 것은 이제 더 이상 무의미해진 일에 불과할 정도로 양 쪽 모두 눈부신 발전을 거듭 해 온 것이다.

"NAS가 맞을까, SAN이 맞을까"

바로 이것이 최근에 네트워크 스토리지를 도입하고 구성하려는 IT 담당자들이 가장 고민하는 부분일 것이다. 대형 서버의 부속품쯤으로 여겨졌던 디스크가 이제는 기업 전산실이나 대외 인터넷 서비스의 핵심 요소로 자리잡은 이 때에 그 디스크의 총체적 집합체인 스토리지 아키텍쳐를 이분법적으로 NAS 아니면 SAN으로 단일화한다는 것은 정말로 심사숙고해야 할 문제이다.

수 많은 기업들이 이미 네트워크 스토리지를 도입하여 성공적으로 운영하고 있고 수 많은 매체에서 네트워크 스토리지에 대하여 과거 수년 동안 심도 있게 다루어 왔음에도 불구하고 의외로 많은 사람 들이 NAS와 SAN의 차이점을 명확히 알지 못하고 있는 듯 하다. 혹자에게는 지겨운 이야기가 되겠으나 그래도 한번 짚고 넘어가 보자.

표 1. NAS와 SAN의 비교

NAS는 데이터 공유가 되고 SAN은 데이터 공유가 안된다는 이야기는 파일 시스템을 디스크가 관리하는가 서버가 관리하는가의 차이에서 비롯된다. 데이터의 전송 단위가 파일이냐 블록이냐 하는 것은 뭐가 되고 안되고의 문제가 아닌 애플리케이션의 특성에 따라 어느쪽이 유리한가의 문제이다. 대표적인 예가 데이터베이스의 경우인데 전통적으로 데이터베이스는 블록 단위의 액세스에 유리하도록 제작되어 있다. 대부분 대용량의 미션 크리티컬한 업무에 사용되는 데이터베이스의 스토리지로 SAN이 선택되는 이유도 이 때문이다.

물론 요즘에는 오라클을 위시한 대표적인 데이터베이스가 NAS에서 잘 돌아가도록 재설 되고 있고 하이엔드급의 NAS에서 데이터베이스를 운영하는데 아무런 문제가 없는 시대가 되었다.

표 1을 가만히 보면 NAS와 SAN은 완전히 다른 구조를 가지고 있음을 알 수 있다. 하지만 이것은 전적으로 스토리지를 만드는 사람과 구성하는 사람의 입장에서 본 관점일 수 있다. 정작 데이터를 저장하고 저장된 데이터를 유용하게 사용하려는 사람의 입장에서 보면 프로토콜이나 전송단위 따위는 알려고 하면 골치 아프고 별로 알아야 할 필요도 없는 것이 사실이다.

"NAS도 필요하고 SAN도 필요하다"

문제는 이것이다. 둘 다 필요하다는 것. 'NAS에 데이터를 저장하는 것에 대해서는 데이터의 정합성을 보장할 수 없다'고 하는 몇몇 데이터베이스 애플리케이션의 경우에는 선택의 여지가 없이 SAN을 사용해야 한다. 수십에서 수백, 수천대의 서버가 동일한 데이터를 공유해야 하는 경우에는 역시 선택의 여지가 없이 NAS를 사용해야 한다.

대표적인 두 가지 예를 들었지만, 오늘날 기업의 90%가 SAN과 NAS의 필요성을 모두 가지고 있다는 보고서가 나오는걸 보면 기업의 전산 환경이 날로 다양해지고 복잡한 요구가 계속된다는 것을 미루어 짐작할 수 있으리라 생각된다. 사실 답은 간단하다. 둘 다 도입하면 된다. SAN이 필요한 업무의 서버는 SAN을 이용한 스토리지 통합을 추진하면 되고 NAS가 필요한 업무의 서버는 NAS를 이용한 스토리지 통합을 추진하면 두 가지 요건을 모두 충족시킬 수 있게 된다.

하지만 이렇게 하기엔 몇 가지 쉽지 않은 문제가 따른다. 우선 투자 비용이 과다하다는 점이다. 전혀 다른 두 제품을 구매해야 한다는 이유에서다. 네트워크 스토리지의 특성상 스토리지만 구매한다고 모든 것이 해결되지는 않는다. 더군다나 SAN의 경우는 파이버 채널이라는 기존에 사용하던 이더넷 환경과 전혀 다른 종류의 네트워크를 구성해야 하기 때문에 그에 따른 파이버 채널 스위치라던가 서버의 HBA(Host Bus Adapter)등이 추가로 요구된다.

그 다음으로 관리적인 리스크 문제를 생각 해 볼 수 있다. SAN을 도입한다는 것은 뭔가 상당히 전문적인 스토리지를 도입한다는 느낌이 든다. 흔히 인터넷을 사용하면서 친숙하게 오랫동안 사용해온 네트워크와는 전혀 다른 네트워크를 구성한다는 것, 사무실 여기저기에 굴러다니는 이더넷 스위치를 그대로 두고 그보다 몇 배 비싼 파이버 채널 스위치를 또 구입해야 한다는 것, 결정적으로 이러한 모든 것들이 대단히 낯설고 아주 하찮은 문제라도 생기면 전문 인력에게 전적으로 의존해야 한다는 석연찮음 등이 그 느낌의 일부분일 것이다. 결론적으로 이미 회사에서 열심히 일하고 있는 네트워크 관리자가 관리할 수 없는 네트워크가 새로 생긴다는 것이다.

"SAN과 NAS를 결합하면?"

이러한 요구 사항을 만족시키는 동시에 위에서 제기한 문제를 해결하기 위한 스토리지 업계의 노력은 다양한 방법으로 표출되어 왔다.

그 중 하나는 'NAS 게이트웨이(Gateway)'라는 것이다. EMC의 Celerra나 HDS의 gFiler가 그 대표적인 예라고 볼 수 있다. 이것은 SAN을 중심으로 하여 SAN 스토리지를 NAS의 컨트롤러 역할을 하는 장비와 연결하여 SAN의 디스크 공간의 일부를 NAS 컨트롤러에 할당 하여 사용할 수 있게 해 주는 솔루션이다. 주된 타겟은 이미 SAN을 도입하여 사용하는 기업이 NAS의 요구가 있을 때, 새로 NAS 스토리지를 도입 할 것이 아니라 NAS 게이트웨이라는 NAS 컨트롤러만 도입하도록 하여 디스크 자체에 대한 중복 투자를 방지하자는 것이다. 사실상 이러한 제품을 통하여 SAN업계의 선두주자인 EMC가 NAS 시장으로 진입을 시작하였으며, HDS는 NAS업계의 선두주자인 네트워크 어플라이언스(이하 넷앱)와 손을 잡고 자사의 SAN제품에 NAS 게이트웨이를 공급하고 있다. 강력한 방법이긴 하나 역시 하드웨어가 들어가는 만큼 투자 비용이 만만치 않다.

또 한가지 방법은 NAS 스토리지에서 SAN을 지원하는 것이다. 네트워크 어플라이언스가 대표적이면서 또한 유일한 경우인데, 자사의 NAS 스토리지에서 이더넷 포트 뿐만 아니라 파이버채널 스위치나 서버의 HBA와 바로 연결할 수 있는 파이버 채널 인터페이스를 지원하여 디스크의 일부를 SAN호스트에게 할당하여 사용할 수 있도록 하는 방법이다. 유니파이드 스토리지(Unified Storage), 혹은 FAS(Fabric Attached Storage)라는 개념이 출발하게 된 직접적인 계기가 된 경우라고 볼 수 있다. 물론 NAS 게이트웨이와 SAN 디스크를 하나의 제품이라고 본다면 그 또한 FAS라고 보는 견해도 있다. 어찌 되었건 궁극적으로 하나의 스토리지 박스만으로 NAS와 SAN을 모두 사용하자는 것이 이러한 제품의 의도라고 볼 수 있다.

"그런데...여전히 너무 비싸다."

위의 두 가지 방법은 업계 최고의 기술을 응집하여 최대의 성능을 내면서 '단일 박스 내에서의 NAS와 SAN의 지원'이라는 명제를 외형적으로 해결한 것은 사실이지만 문제는 여전히 투자비용이 많다는 것이다. 전자의 경우는 디스크 몇 개(?)의 가격을 절약한 정도이고 후자는 훨씬 근본적인 접근 방법이긴 하지만 여전히 파이버채널 네트워크가 필요하다는 숙제가 남아 있다.

그래서 눈을 돌린 것이 네트워크 프로토콜에 대한 접근법이다. 즉, 친숙하고 상대적으로 가격이 훨씬 저렴한데다가 라우팅이 가능하여 거리제한이 전혀 없는(참고로 파이버채널은 라우팅이 불가능하고, 따라서 직접적으로는 50Km라는 거리 제한이 있다) IP 네트워크를 이용하여 NAS와 SAN을 모두 사용하고자 하는 필요조건을 만족시키기 위한 다양한 시도가 행해진 것이다. 그래서 등장한 것이 바로 'iSCSI(Internet Small Computer System Interface)'라는 프로토콜이다.

"iSCSI? iSCSI!"

앞의 두 방법이 스토리지 장비 자체를 중심으로 한 접근법 내지는 해결책이었다면 iSCSI는 네트워크 프로토콜을 중심으로 한 해결책이라고 볼 수 있다. iSCSI는 넷앱과 인텔이 프로토콜의 프로토타입을 만들어 IETF(Internet Engineering Task Force)에 상정, 지난 2월에 HTTP, FTP등과 같은 인터넷 표준 프로토콜로 인정 받은 이후로 TCP/IP상에서 블록단위의 데이터를 전송할 수 있도록 하는 최적의 솔루션으로 각광 받고 있다. "TCP/IP상에서 블록단위의 데이터를 전송한다"라는 말은 어떻게 사용하라는 말인지 사실 크게 와 닿지 않는 것이 사실이다. 다음과 같은 상황을 한번 생각 해 보자.

A라는 회사의 정보시스템 부서장인 나부장은 지난달까지 회사의 핵심 시스템들에 대한 대대적인 스토리지 통합 작업을 완료하고 그 성능이나 관리의 효율성에 대단히 만족하고 있다. 회사 내부의 ERP 및 외부 서비스 관련 대형 DB서버 4대는 SAN 스토리지를 도입하여 통합시켰고, 인터넷 서비스용의 중형 서버 80여대는 NAS 스토리지를 도입하여 역시 각 서비스 특성 별로 공간할당을 하여 완벽하게 로드 밸런싱 환경을 구현 해 놓았다. 그런데 문제는 2주전부터 다른 곳에서 발생하기 시작했다. SAN으로 통합한 것 이외에도 회사 여기저기에 흩어져 있는 20여대의 Windows 및 Linux를 사용하는 DB서버의 디스크 공간이 거의 80%에 이르고 있다는 보고가 올라 오기 시작 한 것이다. 물론 SAN을 도입 할 당시에 이 서버들을 고려하지 않은 것은 아니지만 그 서버에도 두개씩 HBA를 탑재하고 SAN 스위치까지 도입한다고 계산하니 도저히 예산 범위 내에서 해결 할 수 있는 문제가 아니었다. 사실 크리티컬한 업무가 아니라고 과소평가한 부분도 없지 않았다. 하지만 어제 발생한 제2부서의 Exchange서버가 노화되어 문제가 생겼을 때 공교롭게도 디스크 장애로 인하여 시스템을 완전히 새로 구성하였는데 꼬박 8시간 30분이 걸렸다. 결국 그 시간 동안 아무도 사내 이메일을 사용할 수 없었다. 이런 작은 서버들 까지도 모두 그 값비싼 파이버 채널로 연결하여야 한다는 말인가…

고민중에 문득 "NAS서버에 DB를 돌려도 아무런 문제가 없다"는 말이 생각났다. "그래! 2대의 Exchange서버와 18대의 DB서버를 NAS로 통합하는 거야!" 스스로의 번뜩이는 아이디어에 감탄한 나부장이 좋아했던 것도 잠시. Exchange 서버와 SQL 서버는 NAS에서 운영하는 것에 대한 데이터 정합성을 보장할 수 없다는 자료를 부하 직원이 보고해 왔다.

고민은 줄었다. 첫째, 그냥 하던 대로 디스크를 추가하면 된다. 하지만 언제까지 이렇게 할 것인가. 왜 값비싼 SAN을 도입하고 NAS를 도입하였는데. 둘째, 20대의 서버에 HBA를 꼽고, 모자라는 파이버 채널 포트 수를 충당하기 위하여 SAN스위치를 도입하여 기존의 SAN에 통합하는 것이다. 견적을 받아 보니 엄청나다. 애초에 예산을 잡아놓지 않았기 때문에 당장 집행할 수 있는 일도 아니다. 방법이 없을까?

이와 같은 상황에서 가장 적합한 솔루션이 바로 iSCSI를 이용한 SAN을 구성하는 방법이다. 다행히 나부장이 도입한 NAS장비는 완벽하게 iSCSI를 지원하고 있다. 그것도 프로토콜 라이센스를 무료로 사용할 수 있다니! 기존의 SAN 스토리지 및 파이버 채널 네트워크는 전혀 생각하지 않아도 된다. 20대의 서버에서 사용하지 않던 여분의 이더넷 포트와 전산실 구석에서 잠자고 있는 L2스위치 한대만 있으면 NAS 스토리지를 이용하여 간단하게 SAN을 구축할 수 있게 된 것이다. Exchange도 완벽하게 동작하고 MS SQL서버도 완벽하게 동작한다. iSCSI를 사용하는 서버에서 바라본 NAS의 볼륨은 로컬 하드디스크와 완전히 동일하게 보인다. 허…이거 완전히 SAN이네…

"iSCSI는 어떻게 작동하길래…"

도대체 iSCSI라는 것이 어떻게 작동하길래 돈 한푼 안들이고 SAN 환경을 구축할 수 있다고 하는 것일까. 이더넷 네트워크상에서의 데이터는 IP 패킷 형태로 흘러다닌다. 마찬가지로 SCSI 케이블을 통해서는 SCSI 패킷의 형태로 흘러 다니게 된다. 당연히 이더넷 네트워크로 SCSI 패킷을 보내려고 하면 전송되지 않고 반대의 경우도 마찬가지이다.

그림 1. SCSI패킷

그림 2. iSCSI 패킷

위의 그림 1은 전형적인 SCSI 패킷을 단순하게 그린 것이다. 여기에 그림 2에서와 같이 IP 헤더만 덧붙이면 그대로 IP 패킷이 되는데 이 형태로 전송하게 되면 이더넷 네트워크의 입장에서는 이것을 단지 IP 패킷이라고 생각하고 전송하게 되는 원리이다. 따라서 스토리지나 서버에서는 SCSI 패킷에 IP 헤더를 붙였다 떼었다하는 작업이 수반되게 되는데 이것이 iSCSI의 전부라 해도 과언이 아니다. 단순히 몇 바이트의 IP 헤더만 데이터에서 탈부착시키는 과정이 더해지는 것 뿐, 어떠한 데이터의 변환이나 암호화 등의 연산은 일어나지 않으므로 많은 시스템 오버헤드도 필요치 않게 된다.

iSCSI를 이용한 스토리지 통합을 구현하기 위해서는 크게 세가지 구성 요소가 필요하다.

1. iSCSI Target (=스토리지)
iSCSI가 완벽하게 지원되는 스토리지가 있어야 함은 물론이다. 즉 디스크통합의 최종 주체가 되는 스토리지에서 iSCSI 프로토콜을 지원해야 한다. 이럴 경우 해당 스토리지를 'iSCSI Target'이라고 부른다. 아직까지는 전 제품 모델에서 iSCSI를 완벽하게 지원하는 스토리지는 넷앱의 파일러 제품군밖에는 없다. 넷앱의 파일러 제품을 가지고 있다면 iSCSI 프로토콜 라이센스를 무료로 추가할 수 있다.

2. iSCSI 네트워크 (=일반 TCP/IP 네트워크)
iSCSI 전용 네트워크가 있는 것은 아니다. 기존의 일반 TCP/IP의 이더넷 환경이라면 더 이상 필요한 것은 없다. iSCSI는 표준 TCP/IP상에서 작동하도록 설계되어 있기 때문이다.

3. iSCSI Initiator (=서버)
iSCSI는 기본적으로 서버의 이더넷 랜 카드를 통하여 작동한다. 단, 여타의 드라이버들처럼 iSCSI 패킷을 이해할 수 있도록 iSCSI 드라이버가 있어야 하고 이러한 iSCSI 드라이버는 각 OS벤더에서 무료로 제공하고 있다. 이와 같이 기존의 랜카드에 iSCSI 드라이버만 설치해서 사용하는 경우를 소프트웨어 이니시에이터라고 하며, iSCSI와 관련된 연산은 서버의 CPU가 하게 된다. 반대로 iSCSI와 관련된 연산을 하는 전용 카드를 iSCSI HBA라고 하는데 이러한 전용 카드를 사용하는 경우를 하드웨어 이니시에이터라고 한다. 넷앱 파일러를 이미 사용하고 있으면서 소프트웨어 방식을 선택하였다면 정말로 돈 한 푼 안들이고 SAN을 구축하는 것이 가능해진다는 이야기가 된다.

iSCSI는 2003년 2월에 표준으로 채택된 신기술이지만 대부분의 스토리지, 서버 벤더들은 iSCSI에 대한 적극적인 지원을 표명하고 있으며 지금도 끊임없이 제품 개발에 박차를 가하고 있다. 하지만 아직은 그리 오래 되지 않은 표준 프로토콜이기 때문에 스토리지에 있어서는 넷앱의 전 모델, 서버측은 Windows 2000 이상, Linux 계열 그리고 노벨 NetWare만 정식 지원되고 있다. 올 연말에서 내년 초,중반까지 IBM의 AIX, HP의 HP-UX, Sun Microsystems의 Solaris운영체제도 지원 될 전망이다. 아래 그림 3은 넷앱의 스토리지를 이용하여 iSCSI를 통한 스토리지 통합을 구현한 다이어그램을 보여준다.

그림 3. iSCSI를 이용한 스토리지 통합 다이어그램

iSCSI가 가져다 주는 이점은 비단 저렴한 가격의 SAN을 구축할 수 있다는 점 뿐만이 아니다. 전체 스토리지 시장의 60% 이상을 차지하고 있는 중소형 서버의 DAS(Direct Attached Storage)를 네트워크 스토리지로 통합하는 가장 손쉽고 리스크가 적은 솔루션으로 급속히 자리잡아 가고 있는 iSCSI는 SAN이 가져다 주는 이점을 대부분 그대로 제공해 준다.

다만 아직까지 계속 발전 단계에 있는 프로토콜이고 지속적으로 지원 플랫폼을 넓혀가고 있는 새로운 솔루션이기 때문에 보유하고 있는 서버 기종에 따라 좀 더 기다려야 하는 경우가 있을 수 있다. 회사의 주요 업무를 관장하는 대형 서버는 SAN과 NAS를 도입하여 모두 통합하였다. 이제 각 부서에, 전산실 여기저기에 흩어져서 각자 나름대로 중요한 업무를 담당하고 있는 중소형 서버들을 손볼 차례다. 무얼 망설이는가. 무얼 망설이는가. iSCSI에 그 해답이 있다.

출처 : 넷엡( http://www-kr.netapp.com/tech_library/kr_iscsi_1.html#7)
http://hostindex.tistory.com/entry/%EA%B8%B0%EC%97%85-%EC%8A%A4%ED%86%A0%EB%A6%AC%EC%A7%80%EC%9D%98-%EC%97%B4%EC%87%A0-iSCSI-SAN