SAN을 언제 고려해야 할까요?

모든 사람이 SAN 구매에 뛰어들고 싶어 하는 것 같습니다. 때로는 상당히 열정적으로요. SAN은 솔직히 꽤 멋집니다. 대부분의 IT 전문가가 자신의 현장에서 직접 보유할 기회를 얻을 수 있는 가장 흥미롭고 신나는 대규모 하드웨어 중 하나입니다. SAN을 소유하고 싶은 욕구는 종종 “남들에게 뒤처지지 않으려는” 심리에서 비롯되는데, SAN을 사용하는 것이 일종의 지위 상징이 되었습니다. 전용 서버실에서나 볼 수 있고 가정에서는 거의 볼 수 없는(물론 예외는 있지만) 대기업 IT의 마지막 영역 중 하나입니다. SAN은 강력하게 홍보되고, 내부 이중화로 인해 절대 고장나지 않으며 논리를 초월하는 속도를 자랑하고 당신이 필요한 줄도 몰랐던 기능들로 가득 찬 놀라운 장치로 광고되고 판매됩니다. 새로운 시스템을 설계하는 IT 전문가와 이야기할 때 가장 흔하게 듣는 설계 요소 중 하나는 “최종 설계에 대해서는 잘 모르지만 SAN이 필요하다는 것은 알고 있습니다.”라는 말입니다.

이 글에서 SAN은 가장 일반적인 맥락에서, 즉 “블록 스토리지 장치”를 의미하는 것으로 사용하며, 전체 스토리지 네트워크를 지칭하는 것이 아닙니다. 스토리지 네트워크는 NAS에도 존재할 수 있지만 SAN 블록 스토리지 장치를 전혀 사용하지 않을 수도 있습니다. 따라서 이 글에서 SAN은 네트워크로서의 SAN이 아닌 장치로서의 SAN만을 지칭합니다. SAN은 여러 의미로 사용될 수 있어 상당히 혼란스러울 수 있습니다. 네트워크 없이 구성된 SAN은 DAS가 됩니다. 네트워크에 연결된 DAS는 SAN이 됩니다.

잠시 멈춰봅시다. SAN은 백엔드 스토리지입니다. SAN의 필요성은 모든 경우에 아키텍처의 다른 측면에 의해 결정됩니다. 아직 많은 부분을 결정하지 않은 상태라면 최종 설계에 SAN이 필요한지, 심지어 유용한지조차 알 수 없습니다. 적신호입니다. 온통 적신호입니다. 말이 마차를 미는 로마 전차 경주를 상상해 보십시오(무슨 말인지 아신다면요).

SAN 도입에 대한 열망이 너무 강한 나머지, 전체 프로젝트가 SAN 구매를 정당화하기 위한 목적으로 설계되는 경우가 많습니다. 어떤 프로젝트든 먼저 물어야 할 질문은 “우리가 충족시키려는 비즈니스 요구사항은 무엇인가?”이며, 그 다음에 진행해야 합니다. “SAN을 구매하고 싶은데 어디에 사용할까?”가 아닙니다. SAN은 복잡하고, 복잡성은 취약성을 수반합니다. SAN은 종종 높은 비용을 동반합니다. 하지만 SAN에서 가장 우려스러운 부분은 SAN에 대한 심층적인 업계 지식이 광범위하게 부족하다는 점입니다. SAN은 그 사용을 정당화하기 위해 반드시 극복해야 하는 막대한 기술적, 비즈니스적 위험을 수반합니다. SAN은 의심할 여지 없이 매우 흥미롭고 꽤 유용하지만, 그것만으로는 SAN을 원하는 욕구를 정당화하기에 충분하지 않은 경우가 많습니다.

우리는 SAN을 “최후의 수단 스토리지”라고 부릅니다. 이것이 의미하는 바는, 스토리지 유형을 선택할 때 로컬 드라이브, DAS(Direct Attach Storage), NAS(Network Attached Storage)와 같은 다른 대안을 사용할 수 있기를 바란다는 것입니다. 대부분의 경우 다른 옵션들이 훌륭하게 작동합니다. 하지만 비즈니스 요구사항이 SAN으로만 합리적으로 충족될 수 있는 조건을 요구하는 경우도 있습니다. 그런 경우 선택의 여지 없이 SAN을 사용해야 합니다. 하지만 일반적으로는 더 간단하고 보통 비용이 낮거나 위험이 적은 옵션을 선호하여 SAN을 피할 수 있습니다.

SAN을 도입하려는 대부분의 사람들이 여러 가지 오해 아래에서 그렇게 한다는 것을 알게 되었습니다.

첫 번째는 SAN이 본질적으로 매우 신뢰할 수 있다는 것입니다. 매우 신뢰할 수 있는 SAN 벤더와 제품이 분명히 많이 있지만, 이는 모든 IT 제품에도 마찬가지입니다. 고급 SAN의 가격대에 있는 고급 서버도 SAN만큼이나 신뢰할 수 있습니다. SAN은 일반 서버와 동일한 하드웨어 구성 요소로 만들어지기 때문에 더 신뢰할 수 있게 만드는 마법 같은 것은 없습니다. SAN을 신뢰할 수 있게 만드는 데 사용할 수 있는 모든 것은 서버 RAS(Reliability, Availability and Serviceability) 기술의 파생물입니다. SAN과 마찬가지로 NAS, DAS, 로컬 디스크도 믿을 수 없을 만큼 신뢰할 수 있게 만들 수 있습니다. SAN은 단지 다른 작업을 수행하는 대신 블록 스토리지를 제공하는 데 사용되는 장치를 지칭합니다. SAN은 매우 단순한 서버에 불과합니다. SAN은 최상위 단의 메인프레임 수준의 신뢰성부터 최하위 단의 단순한 외장 하드 드라이브(네트워크에서 가장 신뢰할 수 없는 네트워크 장치)까지 신뢰성의 전 범위를 포함합니다. 따라서 SAN이 신뢰성을 의미하는 것이 아니라, 실제로 상상할 수 있는 가장 낮은 신뢰성의 몇 가지 특수 사례를 제공합니다. 하지만 실제로 모든 서버는 대략적으로 동일한 신뢰성 문제를 공유합니다. SAN이 신뢰성으로 명성을 얻는 것은 기업들이 서버에는 투자하지 않는 만큼 극단적인 예산을 SAN에 투입하는 경우가 많아서, 상대적으로 고급 SAN과 상대적으로 저예산 서버를 비교하게 되기 때문입니다.

두 번째는 SAN은 “대규모”를 의미하고 NAS는 “소규모”를 의미한다는 것입니다. 그러한 연관성은 없습니다. SAN과 NAS 모두 거의 모든 규모와 품질로 구현될 수 있습니다. 둘 다 전 범위를 아우르며, 선택된 기술만으로 장치가 크고 작음을 암시하는 것은 전혀 없습니다. 다시 위에서 언급한 것처럼, SAN은 실제로 기술적으로 NAS 솔루션보다 “더 작게” 구현될 수 있는데 이는 단순성 때문이지만 이는 특수 사례이며 대부분 이론적입니다. 시장에는 이 범주에 속하는 SAN 제품이 있지만 실제 사용 사례에서 찾기는 매우 드뭅니다.

세 번째는 SAN과 NAS가 섀시 내부적으로 극적으로 다르다는 것입니다. 오늘날 대부분의 SAN 및 NAS 장치는 “통합 스토리지”라고 불리는 것, 즉 SAN과 NAS 모두로 동시에 작동하는 스토리지 어플라이언스이기 때문에 이는 분명히 사실이 아닙니다. 이는 두 가지의 핵심 차이점이 백엔드 기술, 하드웨어, 크기 또는 신뢰성에 있는 것이 아니라 스토리지 전송에 사용되는 프로토콜에 있다는 것을 강조합니다. SAN은 파이버 채널, iSCSI, SAS, ZSAN, ATA over Ethernet(AoE) 또는 Fibre Channel over Ethernet(FCoE)와 같은 프로토콜을 사용하여 네트워크에 원시 블록 장치를 노출하는 블록 스토리지입니다. 반면 NAS는 네트워크 파일 시스템을 사용하며 TCP/IP를 통해 이동하는 NFS, SMB, AFP, HTTP 및 FTP와 같은 애플리케이션 계층 프로토콜을 사용하여 네트워크에 파일을 노출합니다.

네 번째는 SAN이 본질적으로 파일 공유 기술이라는 것입니다. 그것은 NAS입니다. SAN은 단순히 블록 스토리지(하드 디스크 서브시스템)를 가져다가 네트워크를 통해 원격으로 사용 가능하게 만드는 것입니다. 네트워크의 특성상 여러 장치에 동시에 해당 스토리지를 연결할 수 있으며 실제로 물리적으로도 그렇게 할 수 있습니다. 마치 하드 드라이브가 중간에 매달려 있는 SCSI 리본 케이블의 양 끝에 여러 컨트롤러를 물리적으로 연결할 수 있었던 것처럼요. 이는 일반적인 상황에서 드라이브의 모든 데이터를 파괴하게 됩니다. 서로에 대해 아무것도 모르는 컨트롤러들이 서로의 데이터를 덮어씌워 거의 즉각적인 데이터 손상을 일으키기 때문입니다. 특별한 클러스터 파일 시스템과 해당 드라이버에는 이를 가능하게 하는 메커니즘이 있지만, 이는 많은 사람들이 SAN을 도입할 때 인식하지 못하는 수준의 전문 지식과 이해를 필요로 합니다. SAN이 대부분의 사람들이 SAN의 목적이라고 믿는 바로 그 사용 사례를 위험에 빠뜨리고, 그들이 추구하는 거의 마법 같은 보호를 제공하지 못할 뿐만 아니라 오히려 데이터 손실의 바로 그 원인이 된다는 사실은 잘못 이해된 스토리지 기술을 구현할 때의 위험 수준을 보여줍니다. 저는 거의 매주 이런 일을 겪은 사람과 이야기합니다.

다섯 번째는 SAN이 빠르다는 것입니다. SAN은 빠를 수도 있지만 끔찍하게 느릴 수도 있습니다. SAN 기술 자체만으로는 본질적인 속도 향상이 없습니다. SAN이 위치한 네트워크가 도입하는 고유한 병목 현상을 극복하는 것은 실제로 꽤 어렵습니다. DAS와 같은 일부 다른 스토리지 옵션은 SAN과 동일한 기술을 모두 사용하지만 실제 네트워크의 병목 현상과 지연 시간이 없기 때문에 동등한 DAS가 SAN보다 조금 더 빠를 것입니다. SAN은 일반적으로 하드웨어가 동일한 NAS에 비해 조금 더 빠르지만, 이것도 보장되지 않습니다. SAN과 NAS는 다르게 작동하며 서로 다른 사용 사례에서 어느 쪽이든 더 나은 성능을 발휘할 수 있습니다. SAN은 성능 요구사항을 기반으로 솔루션으로 선택되는 경우가 거의 없습니다.

여섯 번째는 SAN이라는 이유만으로 스토리지 선택과 관련된 고유한 문제들이 더 이상 적용되지 않는다는 것입니다. 좋은 예시는 RAID 5의 사용입니다. 서버에서는 좋지 않은 관행으로 여겨지겠지만, SAN을 사용할 때(이론적으로 독립형 서버보다 훨씬 더 중요한)는 SAN이기 때문에 어떻게든 그 문제들을 해결했거나 적용되지 않는다는 믿음을 바탕으로 신중한 스토리지 서브시스템 계획이 종종 무시됩니다. 일부 고급 SAN이 다른 곳에서는 찾기 어려운 일정 수준의 위험 완화 기능을 갖추고 있는 것은 사실이지만, 이는 드물고 취약한 설계가 이미 드물었을 매우 고급 장치에만 국한됩니다. 물리적 서버의 스토리지를 계획할 때는 큰 주의와 고려를 기울이지만 SAN을 사용할 때는 SAN이 내부적으로 모든 것을 처리하거나 더 이상 필요하지 않다는 가정 하에 동일한 계획과 감독을 건너뛰는 것은 위험하지만 매우 흔한 관행입니다.

SAN에 대한 많은 오해를 불식시킨 후 SAN이 과연 적합한 경우가 있는지 궁금해할 수 있습니다. 물론 올바르게 사용될 때 SAN은 매우 중요하고 믿을 수 없을 만큼 가치 있습니다. SAN의 가장 강력한 장점은 통합과 특정 유형의 공유 스토리지에서 비롯됩니다.

통합은 고객을 SAN 솔루션으로 이끈 역사적 동인이었습니다. SAN을 통해 여러 파일 시스템을 단일 디스크 어레이로 통합하여 스토리지 리소스를 훨씬 더 효율적으로 사용할 수 있습니다. SAN은 블록 수준이기 때문에 기존의 로컬 디스크 서브시스템을 사용할 수 있는 언제든지 이를 수행할 수 있습니다. 많은 서버, 심지어 많은 데스크탑에서도 성장, 계획 및 디스크 용량 세분성의 필요성 때문에 스토리지 공간이 낭비됩니다. 각각 300GB 드라이브 어레이를 가진 20개의 서버가 있지만 각각 80GB만 사용하고 있다면, 엄청난 낭비가 발생합니다. SAN으로는 오버헤드에 필요한 소량을 더한 1.6TB로만 통합하여 각 서버가 자체 스토리지를 유지하는 경우보다 물리적 디스크에 훨씬 적게 지출할 수 있습니다.

스토리지 통합을 시작하면 고급 통합 기회를 찾게 됩니다. 단일 SAN에 많은 서버 파일 시스템을 통합한 후 SAN 구현이 지원하는 경우 해당 데이터를 중복 제거하고 압축할 기회를 갖게 됩니다. 서버 파일 시스템과 같은 많은 경우에 이는 잠재적으로 상당한 활용률 감소를 가져올 수 있습니다. 위의 예에서 1.6TB가 실제로는 800GB 이하가 될 수도 있습니다. 갑자기 통합 수치가 점점 더 좋아지고 있습니다.

통합을 효율적으로 활용하려면 규모가 필요하며, 이 부분에서 SAN이 진정으로 빛을 발합니다. 용량 면에서뿐만 아니라 더 중요하게는 연결 노드 수가 매우 많아질 때입니다. SAN은 대규모 스토리지 통합에 가장 적합합니다. 이것이 SAN의 가장 뛰어난 영역이며, 대기업에서는 거의 어디서나 볼 수 있고 소규모 기업에서는 매우 드문 이유입니다.

SAN은 또한 단일 공유 파일 시스템 액세스가 필요한 특정 유형의 클러스터링 및 공유 스토리지에도 매우 중요합니다. 이것은 한 가지 특별한 상황, 즉 데이터베이스를 제외하고는 실제로 상당히 드문 요구사항입니다. 대부분의 애플리케이션은 제공된 모든 유형의 스토리지를 기꺼이 사용하지만, 데이터베이스는 종종 데이터를 가장 효과적으로 조작하기 위해 저수준 블록 액세스가 필요합니다. 이 때문에 NAS나 파일 서버에서는 사용하거나 효과적으로 사용하기 어려운 경우가 많습니다. 데이터베이스 클러스터를 위한 고가용성 스토리지 환경 제공은 오랫동안 SAN 스토리지의 핵심 사용 사례였습니다.

SAN 설치의 대다수를 정당화하는 이 두 가지 주요 사용 사례 외에도, SAN은 물리적 이동이나 복잡한 조달 및 프로비저닝을 처리할 필요 없이 대규모 환경에서 스토리지를 이동, 확장 및 수정하는 것을 잠재적으로 매우 간단하게 만들어 높은 수준의 스토리지 유연성을 제공합니다. 다시 통합과 마찬가지로 이것은 대규모의 산물입니다.

매우 대규모 환경에서는 SAN 사용이 스토리지와 시스템 엔지니어링 팀 간의 경계 지점을 제공하는 데도 활용될 수 있습니다. 일반적으로 파이버 채널이나 iSCSI의 네트워크 계층에서 인수인계를 가능하게 합니다. 이 명확한 업무 분리는 스토리지, 네트워크, 시스템 팀을 고도로 분리하고자 하는 기업에서 팀들이 각자의 영역에만 집중할 수 있도록 하는 데 매우 중요할 수 있습니다. 이를 통해 스토리지 팀은 스토리지에만, 시스템 팀은 시스템에만 집중할 수 있으며 상대방의 구현에 대한 지식이 전혀 필요 없게 됩니다.

SAN은 오랫동안 스토리지 성능 향상을 위한 편리한 수단으로도 자신을 제시해 왔습니다. 이것은 SAN의 고유한 구성 요소가 아니라 통합을 위한 일반적인 사용의 부산물입니다. 가상화를 통한 통합과 유사하게 공유 SAN은 사용 가능한 스핀들의 활용도 향상, 중앙화된 캐시, 그리고 많은 개별 서버에 분산된 동등한 스토리지보다 더 큰 하드웨어를 갖는 자연스러운 이점을 누립니다. 공유 CPU 리소스와 마찬가지로 SAN이 여러 클라이언트로부터 요청을 받지 않을 때 단일 클라이언트의 요청을 처리하는 데 모든 용량을 전용할 수 있어, 개별 서버가 자체적으로 합리적인 비용으로 달성할 수 있는 것보다 잠재적으로 훨씬 높은 평균 성능 경험을 제공할 수 있습니다.

그러나 SSD 스토리지의 등장으로 SAN의 성능을 위한 사용은 빠르게 인기를 잃고 있습니다. 믿을 수 없을 만큼 낮은 지연 시간과 높은 IOPS 성능을 가진 SSD의 가격이 독립형 서버에 로컬 캐시로 또는 잠재적으로 주요 스토리지로 사용될 만큼 낮아지면서, SAN 네트워킹의 병목 현상이 점점 더 큰 요인이 되고 있습니다. 이는 SAN의 통합 이점이 로컬 SSD의 성능 이점을 상쇄하는 것을 점점 더 어렵게 만들고 있습니다. SSD는 로컬 스토리지 쪽으로 성능 이점을 되돌려 공유 스토리지 시장을 잠재적으로 크게 흔들 수 있습니다. 이는 스토리지 아키텍처 설계의 흐름과 역류에서 단지 최신 변화일 뿐입니다.

SAN 사용에서 기억해야 할 가장 중요한 것은 SAN이 스토리지 계획의 기본 출발점이 되어서는 안 된다는 점입니다. SAN은 여러 기술 선택 중 하나이며, 의도한 대로 요구사항을 충족시키지 못하거나 충족시키더라도 금전적 또는 복잡성 측면에서 불필요하게 높은 비용을 초래하는 경우가 많습니다. 비즈니스 목표와 요구사항을 정의하는 것에서 시작하십시오. SAN이 해당 요구사항을 가장 효과적으로 해결할 때 SAN을 선택하되, 열린 마음을 갖고 환경의 전반적인 스토리지 요구사항을 고려하십시오.