'스토리지 네트워크'에 해당되는 글 2

  1. 2007.08.07 스토리지 네트워크의 이해 2
  2. 2007.07.03 스토리지 네트워크 - NAS와 SAN (3)

스토리지 네트워크의 이해 2

출처 : http://www.ionthenet.co.kr/newspaper/view.php?idx=12283

=============================================================

스토리지 네트워크의 핵심은 SAN과 NAS로 설명할 수 있다. 하지만 예상을 넘어서는 데이터의 증가로 인해 스토리지 네트워크 역시 복잡하고 거대한 구성이 되고 말았다. 이에 따라 한계에 직면한 스토리지 네트워크를 보완하기 위한 방안이 속속 등장하기 시작했는데, 가상화나 IP 스토리지 등이 바로 그것이다. 편리하고 안전한 데이터 저장을 지향하는 스토리지 네트워크의 진화에 대해 알아본다.

박재곤 기자

새로운 기술은 당시의 문제점과 예측할 수 있는 가까운 미래의 과제를 해결하는데 중점을 두고 개발되는 것이 일반적이다. NAS와 SAN으로 대표되는 스토리지 네트워크 역시 당시의 데이터 증가를 기준으로 발전된 것으로, 시간이 지나면서 여러 가지 문제점을 나타낼 수밖에 없었다.
SAN은 2000년 초반부터 국내에서도 본격적으로 구축되기 시작했으며, 이를 통해 스토리지에 대한 광범위한 통합이 이뤄지기 시작했다. 하지만 SAN의 규모가 커지면서 스토리지의 관리 역시 복잡해지고 유지 비용도 증가하기 시작했다. SAN은 기본적으로 기존 SCSI 프로토콜을 사용하지만, 물리적인 매체는 파이버 채널을 사용한다. 그리고 서버와 스토리지가 네트워크 상에서 동등한 노드이기 때문에 모든 서버와 스토리지는 서로 접속할 수 있다. 이런 태생적인 장점은 바로 태생적인 단점으로 이어진다.
결국을 SAN을 통해 진행된 스토리지의 광범위한 통합은 새로운 요구에 직면하게 되는데, 예를 들어 스토리지 자원의 보다 광범위하고 자유로운 공유나 서버를 배제한 백업 같은 것이 바로 그것이다.


가상화를 통한 유연성 확보
이런 문제에 대한 해결책으로 등장한 것이 바로 스토리지 가상화이다. 서버와 스토리지 사이의 경로 상에 특정 가상화 장비를 통해 구현되는 스토리지 가상화는 스토리지의 통합은 물론 스토리지 관리의 통합, 그리고 특히 이기종 시스템 간의 스토리지 공유를 위한 액세스 관리 등의 이점을 제공한다. 특히 관리 측면에서는 시스템 관리와 스토리지 관리를 완전히 분리할 수 있다.
스토리지 가상화를 이용하면 서버나 서버 클러스터에 연결하지 않고도 스토리지 풀을 구현할 수 있다. 예를 들어 JBOD나 RAID, 테이프 라이브러리 등을 모아 가상화 장비에 연결한 다음, 클라이언트와 서버는 물리적인 스토리지와는 관계없이 중간의 가상 스토리지에 연결하는 방식이 가능해진다.
스토리지 가상화의 이점은 크게 세 가지로 정리할 수 있다.
첫째, 복잡한 스토리지 인프라를 단순화할 수 있다. 일반적으로 SAN 환경에서 접속하고 있는 각 서버는 SAN 환경에 포함된 모든 스토리지의 물리적인 경로를 관리해야 하는 부담을 갖게 된다. 경우에 따라 한 서버에 2개 이상의 파이버채널 HBA로 SAN에 접속하는 경우에는 2중, 3중으로 중복된 물리적인 경로를 관리해야 하는 경우도 있다. SAN 어플라이언스는 이런 복잡한 다수의 물리적인 경로에 대한 가상화를 통해 몇 개의 논리적인 경로로 그룹화하고 단순화해 서버에 제공한다. 따라서 서버는 실제 사용하는 물리적인 스토리지 경로보다 훨씬 적은 수의 논리적인 경로를 갖게 된다.
둘째, 스토리지 기반 구조에 대한 관리 기능의 향상이다. 가상화 장비는 서버로부터 시스템 관리 영역과 스토리지 관리 영역을 분리해 스토리지 관리 영역을 담당한다. 보다 전문적인 스토리지 관리가 가능해지는 것이다.
서버의 가용시간도 늘릴 수 있다. 가상화된 장비를 서버에 제공하므로 하단 스토리지와 같은 구성의 변경이 서버에 영향을 주지 않는다. 따라서 스토리지의 물리적인 장애나 하드웨어의 구성 변경으로 인해 시스템을 재부팅할 필요가 없어진다. 이는 시스템 가용 시간을 늘려 애플리케이션 서버의 서비스 시간을 늘릴 수 있다.



이기종 환경 지원과 관리 효율성 향상
일반적으로 가상화 기능을 구현하는 위치는 대부분 서버, 디스크, 네트워크 등이다,
먼저 서버의 가상화 구현은 단순한 소프트웨어 솔루션이다. 즉 각 서버에 가상화 기능을 수행하는 소프트웨어를 탑재해 구현하거나 별도의 전용 서버에 가상화 소프트웨어를 설치하고 SAN 구조에 연결해 이곳에서 관련 요구를 우회하는 방법 등이 있다. 전자의 경우 가상화 소프트웨어 관리가 SAN에 속하는 모든 서버에서 이뤄지므로 관리의 단순화라는 측면에 위배되고, 후자는 가상화와 관련된 요구가 항상 전용 서버를 우회해야 한다는 문제가 발생한다.
다음으로, 디스크에서 가상화 기능을 구현하는 것은 테이프 장비가 디스크의 뒤에 위치함으로써 테이프 장비의 효율을 저하시킨다. 또한 특정 디스크 스토리지에 구현되므로 범용성이 없다는 단점이 있다.
마지막으로 네트워크에서 가상화 기능을 구현하는 것은 이론적으로 가장 이상적인 형태이다. 모든 스토리지가 자연스럽게 네트워크를 거치면서 가상화돼 서버에 전달되고 서버는 가상화에 대한 모든 부담을 네트워크로 넘기게 되므로 관리 부담을 덜게 된다.
SAN 가상화 기술은 그동안 SAN의 문제로 지적되고 있던 상호 운영성을 문제를 해결해 이기종 서버와 스토리지를 하나의 SAN 구조로 연결할 수 있도록 지원하며, 지금까지 서버에 있던 스토리지 관리 기능이 SAN 환경에서 독립적으로 운영돼 관리의 효율성을 높일 수 있을 것이다. 더불어 RAID 기능이 스토리지 서브시스템에서 SAN으로 이동해 개별 스토리지 서브시스템의 컨트롤러가 불필요하게 됨에 따라 스토리지 하드웨어의 수익을 크게 잠식할 것이다.


IP를 지향하는 스토리지 네트워크
현재 많은 기업들이 활용하고 있는 스토리지 네트워크는 파이버 채널 기반 SAN으로, 일반적으로 SAN이라고 하면 모두 파이버 채널을 기반으로 한 SAN을 의미한다. 파이버 채널 SAN이 기업들에게 많은 이점을 제공하고 있지만, 동시에 해결해야할 과제들도 적지 않다. 우선 기존 네트워크와는 별도의 네트워크를 구축해야 하고, 이에 따른 구축과 운용 비용, 제한된 운용 범위 등이 바로 그것이다.
이런 파이버채널 기반의 스토리지 네트워크를 범용적으로 사용하고 있는 IP 네트워크에 연결하기 위한 노력이 지속적으로 이어졌다. 대표적인 것이 바로 기존 이더넷 네트워크를 그대로 사용하면서도 파이버 채널 SAN에서 얻을 수 있는 장점을 모두 수용할 수 있는 기술인 IP SAN이다.




IP SAN은 iSCSI(Internet SCSI) 프로토콜을 사용하는 IP 네트워킹 인프라를 기반으로 한다. (그림 2)을 보면 알 수 있듯이, IP SAN은 파이버 채널 SAN과 논리적으로는 동일한 구조다. 단지 기존 파이버 채널이 iSCSI로 대체되는 것이기 때문에 기존의 장점을 그대로 유지하고 있다.
일반적으로 파이버 채널 SAN을 구축할 때 서버에서 스토리지 연결시 HBA(Host Bus Adapter)를 거쳐 파이버 채널 SAN 스위치를 통해 스토리지로 연결된다. 하지만 IP SAN은 HBA 대신 네트워크 카드를, SAN 스위치 대신에 네트워크 스위치를 사용하기 때문에 기존의 IP 네트워크를 그대로 활용해 적은 비용으로 시스템을 구축할 수 있는 것이 가장 큰 특징이다.
또한 현재 거의 모든 기업에서 IP 네트워크 기술을 사용하고 있기 때문에 파이버 채널 SAN 스위치에 대한 기술을 따로 숙지할 필요없이 쉽게 활용할 수 있으며, 관리 포인트도 줄어들어 통합 관리도 가능해진다. 특히 DAS나 로컬 디스크를 쓰는 환경일 경우에 보다 활용도를 높일 수 있다.
이 외에도 파이버 채널 기반 SAN은 거리 제한이 있지만, IP SAN의 경우는 거리 제한 없이 어디든 연결을 지원할 수 있어, 원격 데이터 복제나 재해 복구에도 적용할 수 있는 추가적인 장점까지 제공한다.
이런 장점을 갖춘 IP SAN이지만, 순식간에 기존 파이버 채널 SAN을 대체하지는 못하고 있다. 이유는 IP 네트워크의 속도와 안전성에 대한 사용자들의 인식 때문이다. 속도 문제는 기가비트 이더넷의 보편화와 10기가비트 이더넷의 등장으로 불식됐다고 하지만, 베스트 에포트 기반 IP 네트워크의 가용성와 안정성에 대해서는 아직도 사용자의 신뢰도가 낮은 편이다. 때문에 대규모 아직은 대규모 IP SAN만을 구축하기보다 부분적인 단위 업무에 활용하고 있는 사례들이 많은 편이지만, 해마다 IP SAN 도입 사례들이 증가하고 있는 추세다.


IP SAN의 핵심 기술 ‘iSCSI’
IP SAN을 구성하는 표준 프로토콜에는 iSCSI, FCIP(Fibre Channel over IP), iFCP(Internet Fibre Channel Protocol) 등이 있지만, 현재 가장 널리 이용하는 것은 iSCSI 다.
iSCSI는 TCP/IP를 사용하는 표준 SCSI 블록 스토리지 프로토콜로 ▲빠른 I/O 처리를 지원하며 ▲기존 네트워크 프로토콜을 통한 높은 가용성 보장 ▲SNMP와 기타 네트워크 관리 툴에 의한 수월한 네트워크 관리 ▲IPSec 등의 기술을 통한 높은 신뢰성 제공 ▲저렴한 네트워크 스토리지 구축 ▲IP 기반 LAN과 WAN 인프라와의 호환 ▲기존 네트워크 기술과 인력 이용 ▲거리상의 제약 해결 등 많은 장점을 제공한다.
iSCSI를 통해 IP SAN을 구성하는 방식에는 크게 3가지가 있다. 첫 번째 방식은 서버에 사용 중인 표준 NIC에 소프트웨어 iSCSI 이니시에이터를 적용하는 방식으로, 저렴한 비용으로 구현이 가능해 중소 규모의 애플리케이션 환경에 가장 적합하다.
두 번째 방식은 TCP/IP 네트워크를 통한 데이터 전송시 발생할 수 있는 TCP 오프로드를 제거하기 위해 TOE(TCP Offload Engine) NIC를 사용하는 것으로, 높은 성능이 요구되는 애플리케이션에 적합하다.
세 번째 방식으로는 iSCSI HBA를 사용하는 것으로, 이는 서버의 CPU 부하를 가장 적게 차지하지만, 표준 NIC에 비해 비용이 비싼 것이 단점이다.
기업은 3가지 방식 중에 가장 적합한 방식을 통해 iSCSI를 지원하는 스토리지 시스템이나 테이프 장비에 데이터를 액세스할 수 있다. 만약 iSCSI 방식을 지원하지 못하는 스토리지 장비라면 iSCSI 게이트웨이를 사용해 (그림 3)처럼 iSCSI 환경을 지원할 수도 있다.
 


SAN과 NAS의 통합
2000년 초반까지만 해도 스토리지 네트워크 분야에서 SAN(Storage Area Network)과 NAS(Networked Attached Storage)는 서로의 영역을 고집하며 시장 키우기에 여념이 없었다. 좀더 사실적으로 말한다면 기업 대부분이 SAN만 써도 별무리 없다는 인식이 강했다. 하지만 오늘날 대부분의 기업 애플리케이션 환경은 SAN 지향적 데이터베이스 애플리케이션뿐만 아니라 NAS 지향적 파일 애플리케이션들이 혼재돼 있는 상황이다.
이를테면 은행에서의 고객 데이터 관리를 위한 애플리케이션 서비스는 SAN 아키텍처를 통한 스토리지 구축이 안성맞춤이겠지만, 인터넷 뱅킹과 같은 업무에서는 파일 서비스가 가능한 NAS가 적합하다. 즉, 하나의 기업 고객에서 두 스토리지 아키텍처가 모두 필요해지면서 두 스토리지 네트워크의 통합 방안에 대한 공감대가 형성되기 시작했고, 상호 절충할 수 있는 방안으로 SAN과 NAS의 통합 구성 방안이 마련됐다.
초기에는 기존 SAN 환경에 NAS를 별도로 구축하는 것이 기본적인 통합 구성 방안이었다. 진정한 의미의 통합 구성이라 할 수는 없지만, 동일한 업체 제품으로 구성하다보니 관리는 하나로 이뤄질 수 있었다. 또한 별도로 구성되다 보니 높은 성능을 기대할 수 있어 초기에는 많이 추천되기도 했다.?
하지만 이처럼 기존 SAN 환경에 추가로 NAS를 독립적으로 구축하거나 제한적으로 서비스하는 환경에서는 ▲독립 구성에 따른 스토리지 투자비용 증가와 자원 활용 비효율 ▲SAN과 NAS별 별도의 관리 툴 적용과 독자적 서비스 체계 구축으로 인한 관리 비용과 운영 부담 증가 ▲크로스(Cross) 아키텍처가 필요한 애플리케이션의 서비스 품질 저하 등과 같은 단점들이 제기됐다. 이런 스토리지 비용과 관리 효율성 향상을 위한 기술적 노력이 관련 업체들에 인해 이뤄졌고, 그 결과 SAN과 NAS의 상호 보완적 아키텍처 지원이라는 통합 형태로 이어졌다.
이런 SAN과 NAS의 통합 아키텍처 구현은 무엇보다도 스토리지 자원 공유를 통해 스토리지 투자비용을 절감할 수 있다. 그리고 모든 인프라 구성 요소에 대한 통합 관리 시스템을 구현함으로써 보다 효율적인 관리 방안을 제시한다. 궁극적으로 기업의 가장 큰 화두인 통합 구성, 통합 자원 관리를 실현시켜 전체적인 운영 업무를 획기적으로 줄일 수 있는 방안이라고 할 수 있다.

SAN과 NAS의 통합 지원 방안
SAN과 NAS의 통합은 어느 쪽을 중심으로 두느냐에 따라 크게 두 가지 방법으로 나눌 수 있다. 즉 기존 SAN에서 NAS 파일 서비스를 지원하는 방법과 기존 NAS 환경에서 SAN 블록 서비스를 지원하는 거싱 그것이다.
우선 SAN 환경에서의 NAS 통합부터 살펴보자. SAN으로 스토리지 인프라를 갖춘 기업의 경우, 기업 내 NAS와 같은 데이터 공유, 파일 서비스가 필요한 애플리케이션을 위해 NAS 게이트웨이의 도입을 적극적으로 검토한다. 또한 기존 SAN을 쓰고 있는 기업 중 실제 사용하고 있는 스토리지 용량 외에 사용하지 않은 스토리지 자원을 보다 효율적으로 활용하기 위한 목적으로도 NAS 게이트웨이를 이용해 SAN 인프라 위에 NAS 서비스를 제공하는 경우도 있다.
(그림 4)를 보면 기존 SAN 환경에 NAS와의 연결을 위해 중간에 게이트웨이를 거쳐가는 것을 알 수 있다. 즉, NAS 게이트웨이를 SAN의 클라이언트로 수용해 SAN 스토리지의 특정 볼륨을 NAS 서비스로 수용하는 구성으로, 개별 아키텍처 대비 스토리지 투자비용을 절감할 수 있다는 장점이 있다. 이런 구성 방안은 주로 고성능, 고가용성 서비스가 필요한 데이터베이스 애플리케이션 환경에 이미 SAN 인프라를 구현했고, 추가적으로 웹 서비스나 파일 데이터 공유 등의 요구를 충족시키기 위해 적용할 수 있다.



NAS 환경에서 SAN을 수용하는 방법은 크게 NAS 컨트롤러 내에서 네이티브 파이버채널 인터페이스를 제공하는 방법과 NAS 컨트롤러 내 iSCSI를 통한 IP 기반 SAN 블럭 IO 서비스를 제공하는 방법이 있다.
(그림 5)는 NAS 컨트롤러 내에서 iSCSI를 통한 NAS와 IP 기반 SAN을 수용하는 통합 아키텍처를 나타낸 것이다. 주로 윈도우 기반의 환경을 구축한 비교적 소규모 기업 환경에서 비용 부담을 가능한 낮춰야 하는 경우에 활용된다.
또한 이런 구성은 주요 비즈니스 애플리케이션이 NAS 인프라 환경에 맞춰져 있고, 부분적으로 고객 데이터 관리를 위해 데이터베이스 애플리케이션을 위한 SAN 환경이 필요한 경우에 적합한 구성이다. 이때는 NAS 컨트롤러 상에서 iSCSI를 이용한 IP SAN으로 SAN 서비스 요구를 수용할 수 있다. 이런 구성은 주로 인터넷 비즈니스나 인터넷 서비스 업체들이 많이 도입하며, 윈도우나 리눅스와 같은 운영체제 환경에 최적화된 모델이다.
동시에 하나의 스토리지에서 NAS와 IP SAN을 통합 구축하는 경우도 있다. (그림 3)을 보면 단일 스토리지 시스템을 이용해 윈도우 서버 플랫폼에 있는 데이터베이스 서버를 iSCSI로 구현했고, 그래픽 작업용 서버들은 NAS 업무를 처리하고 있는 것을 알 수 있다. 이는 광 채널 기반의 SAN과 비교해 저비용의 IP 네트워크를 통해 SAN을 구성한 것으로, 무엇보다 이런 구성은 단일 스토리지 시스템에서 NAS과 IP SAN을 구축하기 때문에 전체적인 TCO 절감 차원에서 가장 큰 효과를 기대할 수 있다.


신고

'개발' 카테고리의 다른 글

XML 금지 문자  (0) 2007.08.29
Browser Debugging tool  (0) 2007.08.08
스토리지 네트워크의 이해 2  (0) 2007.08.07
매쉬업이란  (0) 2007.07.11
스토리지 네트워크 - NAS와 SAN  (3) 2007.07.03
jar 묶는 법  (2) 2007.06.27
TRACKBACK 0 COMMENT 0

스토리지 네트워크 - NAS와 SAN

출처 : http://www.ionthenet.co.kr/newspaper/view.php?idx=12195

초보자를 위한 네트워크의 이해 9 | 스토리지 네트워크의 이해 1
  출판일 :2007년 7월호

 NAS와 SAN으로 대표되는 스토리지 네트워크는 이제 네트워크 환경에서 없어서는 안될 중요한 위치를 차지하고 있다. 서버의 구성요소 중 하나였던 저장장치가 네트워크를 만나 독립된 네트워크로 재탄생한 스토리지 네트워크는 NAS와 SAN을 넘어 IP 스토리지로 발전하고 있다. 이번호에는 스토리지 네트워크의 기본 개념에 대해 알아본다.

박재곤 기자

스토리지 네트워크는 말 그대로 스토리지를 위한 네트워크를 말한다. 하지만 모든 네트워크는 다른 용도를 위해 존재하는 것인 만큼, 이 정도의 설명으로는 스토리지 네트워크를 제대로 나타낼 수 없다. 스토리지 네트워크라는 용어가 생겨난 것은 그만큼의 특징이 있기 때문이다.


독립 스토리지의 발전과 한계
스토리지는 데이터 저장장치를 말하며, 가장 일반적인 스토리지로 컴퓨터의 하드디스크를 들 수 있다. 초기에는 독립된 장치로 인식되기 보다는 메모리와 비교해 보조기억장치로 불리우기도 했다. 그도 그럴 것이 스토리지는 컴퓨터가 처리한 데이터를 단순히 저장하기만 하는 보조 장치였기 때문이다. 초기 IT 분야에서는 컴퓨팅, 즉 계산이나 처리가 중요한 사안이었으며, 데이터와 정보는 아직 그 중요성을 인정받지 못하고 있었다.
이 때문에 스토리지는 반드시 컴퓨터와 함께 사용하는 장치였다. PC의 하드디스크와 마찬가지로 서버 역시 개별적인 저장장치를 갖고 있었다. 메인프레임과 같은 대형 시스템 분야에서는 RAID 개념이 등장하고 디스크 서브시스템이란 스토리지 시스템이 등장했지만, 전체 IT 시스템의 구성 상에서는 여전히 컴퓨터에 해당하는 서버와 함께 사용됐다.
물론 스토리지 자체도 용량과 속도, 안정성 등에서 눈부신 발전을 하고 있다. 일반 사용자들에게도 친숙한 예를 들면, 1990년대 초에 한창 인기를 얻은 PC인 286 AT의 하드디스크는 보통 20MB~40MB 정도였다. 이러던 것이 90년대 말 펜티엄III급 PC에서는 10GB, 현재의 최신 PC에서는 200GB~300GB 정도의 하드디스크가 사용되고 있다. 속도 또한 5400RPM에서 7200RPM으로, 그리고 현재는 1만 RPM 제품이 보급되고 있다.
디스크 스토리지에 대한 용량과 성능, 안정성에 대한 요구가 높아지면서 디스크 스토리지는 서서히 시스템으로 발전하기 시작했다. 디스크 서브시스템으로 알려진 것이 바로 그것으로, 이것은 여러 대의 디스크를 모아서 하나의 단일 시스템을 만드는 개념이다.
파일 서버와는 달리 디스크 서브시스템은 하드디스크 서버의 개념으로 설명할 수 있다. 서버들은 고유의 인터페이스를 통해 접속 포트를 통해 디스크 서버시스템에 연결되는데, 이때 서버들은 디스크 서브시스템을 완전히 하나의 하드디스크처럼 인식한다.
디스크 서브시스템은 서버와는 분리된 별도의 시스템으로 구성돼 SCSI나 파이버채널 등의 인터페이스를 통해 단일 서버 또는 여러 대의 서버와 연결된다. 디스크 서브시스템의 핵심은 바로 컨트롤러다. 여러 개의 접속 포트를 통해 들어오는 요청에 따라 디스크 서브시스템 내의 하드디스크를 제어해 필요한 데이터를 서버로 전송해주는 역할을 하기 때문이다(그림 1).




이런 스토리지 자체의 발전에도 불구하고 날로 늘어만 가는 데이터와 그에 비례해 높아진 데이터의 중요성은 독립 스토리지 장비 만으로 감당하기에는 한계가 있었다. 용량 외에도 엔터프라이즈 환경의 스토리지가 해결해야 할 과제들이 날로 늘어갔기 때문이다.
가장 시급한 것은 방대한 데이터를 모든 사용자가 편리하게 공유해야 한다는 것이었다. 기업 환경에서 네트워크가 일반화되면서 모든 사용자들이 네트워크로 연결됐고, 모든 사용자들이 스토리지에 저장된 데이터를 편리하게 이용하길 원했기 때문이다.
이렇게 데이터에 대한 액세스 요구가 늘어나면서 인증받지 못한 사용자가 데이터에 접근하지 못하도록 보안도 확실해야 한다. 또한 늘어나는 데이터를 감당하기 위한 확장성을 고려해야 한다. 하지만 지금까지의 스토리지는 이런 점을 모두 만족시켜 주지는 못하고 있었다. 엄청나게 늘어난 데이터와 스토리지 용량, 이들을 보다 효율적으로 관리하고, 잘 활용할 수 있도록 지원하는 것이 스토리지의 새로운 과제로 떠오른 것이다.
이를 해결하기 위해 등장한 기술이 네트워크와 스토리지를 결합한 스토리지 네트워크다. 현재 기존의 서버와 직접 연결된 스토리지를 일컫는 DAS(Direct Attached Storage)란 용어는 사실 네트워크 스토리지가 부상하면서 기존 스토리지를 좀더 쉽게 부르기 위해 등장한 말이다.
네트워크 스토리지의 핵심은 스토리지를 서버에 속한 IT 장비가 아니라 네트워크에서 서버나 다른 장비와 동등한 장비로 만들었다는 것이다.
현재 스토리지 네트워크를 구성하는 기술은 크게 NAS(Network Attached Storage)와 SAN(Storage AreaNetwork)이라는 두 기술로 나눌 수 있다. NAS는 기존의 이더넷 인프라를 사용하기 때문에 별도의 추가 비용이 적게 소요되며 설치와 구축이 쉽다는 것이 특징이다. 반면 SAN은 확장이 용이하며, 대규모 엔터프라이즈 환경을 구축하기에 적합한 특징을 제공한다는 것이 특징이다.


비용 대비 효과 뛰어난 NAS
NAS는 그 이름에서도 알 수 있듯이 스토리지를 네트워크에 바로 연결해 사용해 보자는 생각에서 시작됐다. 복잡하고 비싼 서버를 거치지 않고 단순히 데이터를 공유하는 목적으로 스토리지를 사용해 보자는 것이다. 따라서 일반 서버에서 파일 서버의 기능 만을 특화해 구성하는 것이 일반적이다.
이 때문에 NAS는 비교적 적은 비용으로 스토리지 네트워크를 구성할 수 있다는 점이 장점이다. 또한 기존의 네트워크 인프라를 그대로 사용하면서 확장성 높은 스토리지 네트워크를 구성할 수 있어 최소의 비용으로 스토리지 네트워크를 구성할 때 우선적으로 고려되는 방법이다.
NAS를 구축하는 방식은 다양하지만 스토리지 측면에서 볼 때 두 가지로 나눌 수 있다. 별도의 컨트롤러와 스토리지 시스템으로 구성된 파일 서버를 구축하는 방식과 컨트롤러와 스토리지가 일체화된 제품을 구입해 바로 네트워크에 연결하는 방식이 그것이다.
또 네트워크 측면에서도 두 가지로 구분할 수 있다. 클라이언트와 서버가 함께 묶여있는 이더넷 등의 일반적인 네트워크에 바로 추가해 클라이언트와 서버에서 모두 사용할 수 있게 구성하는 방식이 있다. 이 방식은 클라이언트와 서버가 동시에 스토리지를 사용하기 때문에 효용성은 크지만 많은 클라이언트가 접속할 경우 대역폭에 제한이 생길 수 있다. 이를 해결하기 위한 방법으로는 조금 큰 규모의 네트워크인 경우 서버와 스토리지만을 별도의 고속 네트워크로 묶고 클라이언트와 서버는 기존의 네트워크를 사용하는 2중 구조를 사용하기도 한다.
NAS는 이전의 서버-스토리지 방식에 비해 여러 가지 장점을 갖고 있다. 이전의 스토리지 구성은 병렬 SCSI나 파이버채널 등을 통해 서버와 스토리지를 연결하고 클라이언트는 서버를 거쳐 스토리지에 접근해야 했다. 이때 만약 서버가 다른 작업에 리소스를 모두 할당하고 있다면 클라이언트가 스토리지에 접근하는데 어려움을 겪게 된다. 이를 피하기 위해서도 서버와 스토리지의 분리는 필수적인 조건이다.
이외에도 스토리지가 서버와 분리돼, 독립된 구성요소가 되면서 몇 가지 부가적인 이점을 얻게 됐다. 그 중에서도 가장 큰 장점은 관리가 편해진다는 것이다. 기존의 서버-스토리지 방식에서는 각 서버마다 별도의 관리 툴을 이용해 스토리지를 관리해야 한다. 만약 윈도우 NT와 유닉스, 네트웨어 서버와 메인프레임이 혼재된 시스템이라면 각각의 서버마다 별도의 관리 툴을 사용해 서버에 연결된 스토리지를 관리해야 하는 난점이 있다. 더군다나 서로 간의 데이터 호환이나 자원 공유에 대한 문제까지 신경쓰자면 한도 끝도 없이 복잡해진다. 하지만 NAS를 도입하면 스토리지 관리를 원격지에서 통일된 방식의 관리 툴을 사용해 수행할 수 있을 뿐 아니라 자원 공유시의 호환성 문제도 어느 정도 해결할 수 있게 된다. 또한 확장성은 추가로 스토리지만 구입하면 되므로 이전의 방식과는 비교할 바가 아니다.
특히 NAS는 기가비트 이더넷이 적용되면서 엔터프라이즈 환경에 광범위한 도입이 이뤄졌다. 기존 네트워크 인프라를 공유하는 NAS의 특징 때문에 100Mbps의 고속 이더넷으로는 확장성이나 성능에 한계가 있었지만, 기가비트 이더넷이나 10기가비트 이더넷의 등장으로 이같은 부분이 거의 해소됐으며, 그동안 취약하다고 여겨지던 많은 부분에 도입이 이뤄지고 있다.



스토리지 만을 위한 네트워크 SAN
엔터프라이즈 환경을 겨냥한 스토리지 네트워크인 SAN은 그 기본 개념부터 이전의 방식과는 큰 차이를 보인다. NAS가 기존 인프라에 가장 효과적인 방법으로 스토리지를 연결했다면, SAN은 기존 인프라를 무시하고 스토리지 만을 위한 네트워크를 새로 구축하자는 개념이기 때문이다. SAN은 전통적인 분산 컴퓨팅 환경에서 유지 보수와 관리의 효용성을 높이기 위해 등장한 프로세서 풀과 비슷한 맥락에서 해석할 수 있다. 다시 말해 스토리지를 한곳에 모아 스토리지 풀을 구성한다는 것이다.
이를 위해 스토리지만을 위한 별도의 네트워크를 구성하며, 서버는 파이버채널 스위치를 통해 스토리지에 접근하는 구조를 갖는다. 하지만 여기서 주의해야 할 점은 SAN은 NAS처럼 클라이언트에 대한 배려는 하고 있지 않다는 것이다. 이것은 SAN이 엔터프라이즈 환경을 지향하고 있다는 점에서 이해해야 한다. 다시 말해 SAN은 서버와 스토리지 풀을 연결하기 위한 기술로, 이것은 서버와 스토리지 사이의 대역폭을 최대한으로 확보하기 위한 노력의 일환이다.
NAS와 마찬가지로 SAN도 네트워크의 대역폭이 민감한 문제로 대두된다. 특히 SAN은 NAS와는 비교할 수 없을 정도로 커다란 구조를 갖기 때문에 이 같은 문제가 더욱 크게 부각된다. 따라서 기존의 네트워크와는 약간 다른 구조를 갖게 된다. 주로 서버와 스토리지 사이나 스토리지 간의 연결에 사용되던 파이버채널 기술을 사용해 네트워크를 구성하는 것이다.
SAN은 파이버채널로 연결된 스토리지를 파이버채널 전용 스위치를 통해 서버들과 연결하는 방식을 취하고 있다. 그리고 클라이언트는 이더넷 등의 일반 네트워크로 서버와 연결돼 스토리지에 접속하는 구조로 구성된다. 설명은 간단하지만 이를 구성하기 위해서는 여러 가지 새로운 기술이 필요하다.
우선 파이버채널로 네트워크를 구성하기 위한 각종 컴포넌트가 있어야 한다. 일반적인 네트워크를 구성하는데 필요한 허브, 스위치, 디렉터, 브리지 등을 그대로 사용하면 좋겠지만, 파이버채널을 지원하는 새로운 제품이 필요한 것이다. 이외에도 SAN을 위한 새로운 프로토콜과 원격지에서 스토리지를 관리하기 위한 각종 툴과 백업/미러링 솔루션도 필요하다.



페타바이트 시대를 위한 스토리지 확장성
SAN 표준화 단체인 SNIA(Storage Networking Industry Association)는 ‘호스트 종류와 무관하게 분산돼 있는 스토리지 장비 사이에, 대용량의 데이터를 이동시킬 수 있는 고속 네트워크’라고 SAN의 개념을 정의했다. 다시 말해 데이터 포맷에 상관없이 어떤 데이터로 언제, 어디서나 액세스할 수 있게 해주는 것이다. 전기나 수도, 도시가스 등도 마찬가지로 무수히 복잡한 네트워크를 이루고 있지만 단지 집에까지 들어와 있는 배선이나 배관에 연결하면 바로 사용할 수 있다. SAN은 스토리지를 이런 방식으로 사용할 수 있게 하자는 개념이다.
스토리지 네트워크가 있다고 생각해 보자. 여기에는 무수히 많은 서버가 연결돼 있고 각각의 서버는 윈도우 서버, 유닉스, 리눅스, MVS 등 다양한 운영체제를 탑재하고 있다. 여기에 접속한 사용자는 어떤 서버에 접속했건, 또 어떤 스토리지에 저장돼 있는가에 상관없이 어떤 데이터라도 검색하고 액세스할 수 있다. 이것이 바로 SAN이다. 네트워크로 그물망처럼 연결된 무수한 스토리지를 수도나 전화를 사용하듯이 편하게 사용할 수 있게 하자는 것이다.
실제적으로 데이터 포맷에 상관없이 언제, 어디서라도 액세스할 수 있는 진정한 SAN을 구현하기 위해서는 단순히 파이버채널에 연결할 수 있는 제품으로만 가능한 것은 아니다. 현재 구축된 하드웨어, 소프트웨어와 차후 도입하게 될 제품에 대한 통합적인 관리 기능으로 통합 시스템을 구성할 수 있을 때 비로소 SAN을 운용하기 위한 기반을 갖췄다고 말할 수 있다.
물론 파이버채널이 여기서 중요한 역할을 할 것이라는 점에 대해서는 이견이 없다. 파이버채널은 LAN이 갖고 있는 데이터 전송 속도를 향상시키고, SCSI가 갖고 있는 접속 거리의 제한을 해결할 뿐 아니라, 다양한 프로토콜 지원, 높은 확장성을 제공하기 때문이다.
SAN은 기존 스토리지 시스템이 갖고 있는 여러 가지 문제를 해결할 수 있는 대안으로 제시된 아키텍처다. 고전적인 DAS(Direct Attached Storage) 아키텍처는 서버마다 스토리지를 장착하고 있는 형태다. 이 같은 구조의 단점은 특정 데이터에 접근하기 위해서는 꼭 지정된 서버를 거쳐야만 한다는 것이다. 이로 인해 특정 서버에 부하가 몰려 시스템의 성능이 저하될 수 있다. 또한 서버나 스토리지 사이에 호환성이 없기 때문에 한 서버의 스토리지 용량이 부족하다고 다른 서버의 스토리지를 빌려 사용할 수 없기 때문에, 서버 별로 용량을 확장해 줘야한다. 뿐만 아니라, 통합적인 관리가 불가능해 각 서버별로 스토리지에 대한 용량 분할이나, 데이터 정리, 백업 등을 수행해야 한다.
SAN은 이런 문제를 스토리지로 구성된 별도의 네트워크를 구축하는 것으로 해결한다. 우선 스토리지를 파이버채널로 구성된 네트워크로 연결한다. 그리고 파이버 허브나 스위치를 이용, 서버와 연결해 어떤 서버에서도 필요로 하는 데이터에 접근할 수 있는 방법을 제공한다. 이로 인해 스토리지의 전체적인 용량 계획을 수립하기가 훨씬 용이해졌다.
다시 말해 스토리지 용량이 부족하면, 네트워크에 새로운 스토리지를 추가하는 것으로 전체적인 용량을 확장할 수 있다. 물론 이를 위해서는 스토리지와 서버 사이, 서버와 서버 사이의 호환성이란 문제가 해결돼야 한다. 그리고 SAN에서는 서버를 경유해 DLT나 테이프 라이브러리에 백업 받는 것이 아니라, 디스크 스토리지에서 바로 백업 장비로 데이터를 전송할 수도 있다. 통합된 원격 관리가 가능해지는 것은 물론이다. 따라서 기존의 서버-스토리지 구조에 비해 관리자의 생산성이 훨씬 높아지는 것뿐만 아니라, 전사적인 데이터의 공유가 가능해짐으로써 필요한 자료를 수집하는데 소요되는 시간과 비용을 줄일 수 있다.
인터넷과 네트워크의 활용도가 커지면서 점차 데이터의 용량은 늘어가고 있다. 테라바이트를 넘어 페타바이트의 시대로 넘어가면서 늘어난 데이터를 좀 더 효율적으로 활용하기 위해, SAN의 등장은 필연적이라고 할 수 있다.

신고

'개발' 카테고리의 다른 글

스토리지 네트워크의 이해 2  (0) 2007.08.07
매쉬업이란  (0) 2007.07.11
스토리지 네트워크 - NAS와 SAN  (3) 2007.07.03
jar 묶는 법  (2) 2007.06.27
썬, 자바 오픈소스화 한다  (0) 2007.05.11
Struts - 간단한 애플리케이션 작성  (0) 2007.04.26
TRACKBACK 0 Comment 3