SMB 스토리지 집중 조명

스토리지는 해결하기 어려운 문제입니다. 기업에게 스토리지는 모호한 이득처럼 보이는 것에 대해 큰 비용이 수반되기 때문에 어렵습니다. 대부분의 경영진은 데이터를 '저장'해야 하고 저장량도 더 늘어야 한다는 것은 이해하지만, 성능, 접근 방식, 이중화 및 위험 계산, 백업과 재해 복구에 대해서는 거의 알지 못합니다. 이는 IT의 업무를 어렵게 만드는데, 비즈니스 이해관계자들에게 보이지 않는 시스템처럼 보이는 것에 왜 예산이 매우 크게 필요한지 설명해야 하기 때문입니다.

IT 관점에서 스토리지는 스토리지 시스템이 복잡하기 때문에 어렵습니다. 흔히 SMB 내에서 단일로 가장 복잡한 시스템이며, 비용과 중앙 집중화로 인해 기업 내에서 매우 적은 수만 존재합니다. 이는 스토리지 시스템이 있는 대부분의 SMB가 하나만 보유하고 매우 오랫동안 유지한다는 것을 의미합니다. 스토리지 시스템에 대한 광범위한 경험 부족과 스토리지 시스템과 상호작용해야 하는 상대적으로 드문 필요성 때문에, SMB IT 부서는 사안의 특성상 실제로 경험이 거의 없는 비즈니스에 매우 중요한 대규모 예산 항목을 다루게 됩니다. IT의 다른 영역은 실험, 테스트 및 교육 목적으로 훨씬 더 접근하기 쉽습니다.

이 두 가지 주요 과제 사이에서 우리는 경영진과 IT 모두에게 일반적으로 잘 이해되지 않는 제품을 갖게 됩니다. 스토리지는 너무 잘못 이해되어 있어 IT 부서조차 무엇이 필요한지조차 모르는 경우가 많으며, 스토리지 다트판을 향해 다트를 던지고 다트가 떨어진 곳에서 시작하는 것 이상을 하지 못하는 경우가 많습니다. 그리고 종종 컨설턴트 대신 벤더에게 먼저 전화함으로써 겉으로는 조언을 구하는 것처럼 보이지만 실제로는 '이미 결정된' 방향으로 이끌려가는 경우가 많습니다.

이 모든 것을 알고 있는 스토리지 벤더는 SMB와 벤더 간의 접촉이 이루어지면 고객이 필요한 정보를 갖기 전에 이미 그 벤더에게 접근하기로 결정했기 때문에 고객을 교육하는 것이 벤더에게 이익이 되지 않기 때문에 상황 개선에 거의 도움이 되지 않습니다. 따라서 벤더는 단순히 자신이 보유한 것을 팔고 싶어합니다. 단일 스토리지 벤더가 자체 라인에 폭넓은 제품군을 보유하는 경우는 드물기 때문에, 무엇이 정확히 필요한지 알기 전에 벤더에게 직접 가는 것은 기술의 다른 영역보다 고객이 구매할 것을 사실상 이미 결정하는 방향으로 훨씬 더 많이 이어질 수 있으며, 이로 인해 비용이 필요한 것과 수 배 차이가 날 수 있습니다.

예: 대부분의 서버 벤더는 x64 계열과 대규모 RISC 머신 및 기타 틈새 제품 모두에서 다양한 서버를 제공합니다. 대부분의 스토리지 벤더는 SAN만 또는 NAS만 또는 '메인프레임' 급 스토리지만 또는 소규모 비복제 스토리지만 등 소규모 스토리지 제품 하위 집합만 제공합니다. 대부분의 요구사항을 충족할 수 있는 다양한 스토리지 제품을 보유한 벤더는 극소수에 불과하며, 이들 중 최고조차도 소규모 SMB 시장과 중간 및 엔터프라이즈 시장을 모두 커버하는 완전한 시장 규모에는 미치지 못합니다.

그렇다면 어디서부터 시작해야 할까요? 분명히 이것은 극복해야 할 심각한 과제입니다.

명백한 선택지이자 사업장이 배제해서는 안 되는 옵션은 스토리지 컨설턴트를 활용하는 것입니다. 솔루션을 재판매하지 않거나, 최소한 단일 솔루션을 재판매하지 않고 선택할 수 있는 완전한 솔루션 세트를 갖추고 있는 사람, 즉 1,000달러짜리 저비용 솔루션과 1,000,000달러짜리 솔루션 모두를 제공할 수 있으며 NAS, SAN, 스케일 아웃 스토리지, 복제, 페일오버 등을 이해하는 사람입니다. 컨설턴트에게 갈 때는 비용이 얼마나 될지 미리 추정하지 마십시오. 많은 요소들이 있으며, 이를 신중하게 고려하면 예상보다 훨씬 적게 지출할 수 있습니다. 하지만 예산, 충분히 문서화된 리스크 회피 성향, 다운타임 비용, 그리고 예상 스토리지 사용 사례 시나리오의 완전한 세트를 마음에 두고 가십시오.

하지만 컨설턴트를 찾는 것이 유일한 방법은 아닙니다. 자체적으로 조사하고, 기본을 배우고, 구조화된 의사결정 프로세스를 따르면, 완벽한 솔루션에는 이르지 못하더라도 최소한 올바른 방향으로 나아갈 수 있습니다. 스토리지를 검토할 때 네 가지 주요 고려사항이 있습니다. 기능(스토리지가 사용되고 접근되는 방식), 용량, 속도, 그리고 신뢰성입니다.

첫 번째 요소인 기능은 가장 간과되고 가장 이해되지 않는 요소입니다. 사실, 이것이 가장 기본적인 관심사임에도 불구하고, 이것은 종종 단순히 덮어놓고 잊혀집니다. 우리는 '왜 스토리지를 구매하는가?'라는 질문을 통해 이 질문에 답할 수 있습니다.

이것을 체계적으로 살펴봅시다. 스토리지를 구매하는 이유는 많습니다. 몇 가지 일반적인 이유는 다음과 같습니다: 개별 서버나 데스크톱의 대량 로컬 스토리지를 보유하는 것보다 비용을 낮추기 위해, 데이터 관리를 중앙 집중화하기 위해, 성능을 향상시키기 위해, 그리고 시스템 장애 시 데이터를 더 가용하게 만들기 위해서입니다.

이러한 요소들 중 어떤 것이 공유 스토리지로 이끄는지, 또는 여기에 나열되지 않은 다른 요소가 있는지 아는 것이 중요합니다. 이는 의사결정 프로세스의 출발점을 제공할 가능성이 높습니다. 공유 스토리지가 필요한 이유를 알 때까지 우리는 이미 알고 있듯이 가장 기본적인 의사결정 요소인 스토리지의 기능을 살펴볼 수 없습니다. 스토리지의 기능을 결정할 수 없다면 공유 스토리지가 전혀 필요하지 않다고 가정해도 됩니다. 이 결정을 내리는 것을 두려워하지 마십시오. 소규모 기업의 대다수는 공유 스토리지에 대한 필요성이 거의 없거나 전혀 없습니다.

공유 스토리지의 기능을 결정하면 이제 용량과 성능 요구사항을 비교적 쉽게 결정할 수 있습니다. 용량은 스토리지의 가장 쉽고 가장 명확한 기능입니다. 성능 또는 속도는 말하고 설명하기는 쉽지만 정량화하기는 훨씬 어렵습니다. IOPS는 최선의 경우 모호한 개념이고 최악의 경우 완전히 잘못 이해됩니다. IOPS는 여러 형태로 나타나며, 랜덤 액세스, 순차 액세스, 버스트 속도, 지연 시간, 지속 속도에 대한 우려가 있으며, 읽기와 쓰기의 차이도 있습니다! 필요한 성능을 결정하는 것조차 어렵고 장치의 예상 성능을 결정하는 것은 더더욱 어렵습니다. 하지만 신중한 조사를 통해 이는 달성 가능하고 측정 가능합니다.

마지막 요소는 신뢰성입니다. 이것은 기능과 마찬가지로 공유 스토리지로 이동하려는 IT 전문가들에게 반복되는 걸림돌인 것 같습니다. 스토리지가 '그냥 또 다른 서버'라는 개념을 명심하고, 일반 서버에 적용되는 이중화 및 신뢰성 개념이 전용 공유 스토리지 시스템에도 동등하게 적용된다는 것이 중요하며, 아니 절대적으로 중요합니다. 거의 모든 경우에 엔터프라이즈 스토리지 시스템은 엔터프라이즈 서버를 기반으로 구축됩니다. 동일한 섀시, 동일한 드라이브, 동일한 구성 요소. 혼란스러운 것은 SMB도 훨씬 낮은 수준의 서버를 지원하기 위해 중간 또는 고급 스토리지 시스템을 찾는 경우가 있어 스토리지 시스템이 상품화된 서버 하드웨어에만 익숙한 사람에게 대형 서버처럼 신비롭게 보일 수 있다는 것입니다. 하지만 오해하지 마십시오. 동일한 신뢰성 원칙이 적용되며, 어떤 장비가 적합한지 결정하기 위해 항상 해왔어야 하는 것처럼 위험을 정확히 동일하게 평가해야 합니다.

스토리지 시스템은 매우 높은 비용과 교체의 복잡성으로 인해 오랫동안 네트워크의 백본 구성 요소로 남아있을 가능성이 높기 때문에, 스토리지 요구사항을 평가하고 조사하며 이해하는 데 시간을 투자하는 것이 매우 중요합니다. Microsoft Office 최신 버전과 달리, 새로운 공유 스토리지 시스템을 구매하는 것은 경영진의 데스크톱에 직접적인 영향을 미치지 않으므로 '기능 업데이트'를 촉진하는 데 필요한 화제성이 부족합니다.

이제 우리 앞에 옵션이 있으므로 실제 제품을 검토하기 시작할 수 있습니다. 기능 조사를 바탕으로 SAN, NAS, 또는 둘 다 필요하지 않은지 결정할 수 있어야 합니다. 많은 경우, 사람들이 깨닫는 것보다 훨씬 많은 경우에서, 둘 다 필요하지 않은 것이 올바른 선택입니다. 기존 서버에 드라이브를 추가하거나 필요한 곳에 DAS 드라이브 섀시를 연결하는 것이 더 복잡한 것을 하는 것보다 비용 효율적이고 신뢰성이 높은 경우가 많습니다. 이것을 간과해서는 안 됩니다. 실제로 DAS가 현재 요구사항을 충족한다면 다른 것이 의미 있는 경우는 드뭅니다. 단순성은 IT 관리자의 친구입니다.

DAS가 현재 요구사항을 충족하지 못하는 경우도 많습니다. 공유 스토리지는 분명 데스크톱 사용자 간에 파일을 공유하는 것만을 위해서라도 그 자리가 있습니다. 오늘날의 현대적인 가상화 시스템에서 공유 스토리지는 점점 더 인기를 얻고 있습니다. 비록 그곳에서도 기존 요구사항에 잘 맞을 수 있는 DAS가 너무 쉽게 기피됩니다.

드문 예외를 제외하고 공유 스토리지가 필요할 때는 NAS가 선택해야 할 곳입니다. NAS는 네트워크 결합 스토리지(Network Attached Storage)의 약자입니다. NAS는 파일 서버의 동작을 모방하여(NAS는 단순히 어플라이언스로 패키징된 파일 서버입니다) 관리하기 쉽고 이해하기 쉽습니다. NAS는 매우 다목적으로 사용되어 전통적인 파일 서버를 대체하고 가상화의 공유 백엔드로도 자주 사용됩니다. NAS는 NFS 및 CIFS 프로토콜로 대표되지만 NAS 장치에서 HTTP, FTP, SFTP, AFS 등도 드물지 않게 볼 수 있습니다. NAS는 Windows와 UNIX 시스템이 각자의 네이티브 프로토콜만으로 파일을 쉽게 공유할 수 있게 해주는 연결자 역할을 합니다. NAS는 일반적으로 VMware의 vSphere, Citrix XenServer, Xen 및 KVM의 공유 스토리지로 사용됩니다. NAS를 사용하면 공유 스토리지를 다양한 역할로 쉽게 사용하고 공유 스토리지 시스템에서 좋은 활용률을 얻기가 쉽습니다.

NAS가 항상 우리의 요구사항을 충족하는 것은 아닙니다. 일부 특수 애플리케이션은 여전히 공유 스토리지가 필요하지만 NAS 프로토콜을 활용할 수 없습니다. 이에 가장 영향을 받는 주목할 만한 제품은 Microsoft의 HyperV, 데이터베이스, 서버 클러스터입니다. 이런 제품들을 위한 답은 SAN입니다. SAN, 즉 스토리지 에어리어 네트워킹(Storage Area Networking)은 어려운 개념이며 최선의 경우에도 분류하기 어렵습니다. NAS가 단순히 전통적인 파일 서버를 다르게 표현하는 방법인 것처럼, SAN은 진정으로 직접 연결 디스크를 다르게 표현하는 방법입니다. SAN과 DAS의 차이점이 명확해 보일 수 있지만 실제로 둘을 구분하는 것은 최선의 경우 모호하고 최악의 경우 불가능합니다. SAN과 DAS는 일반적으로 프로토콜, 섀시, 제한사항 및 미디어를 공유합니다. 많은 SAN 장치를 DAS로 연결하여 사용할 수 있습니다. 그리고 대부분의 DAS 장치를 스위치에 연결하여 SAN으로 사용할 수 있습니다. 실제로 우리는 일반적으로 이 용어들을 다른 어떤 것보다 사용 시나리오를 지칭하는 데 사용합니다.

SAN은 여러 가지 이유로 효과적으로 활용하기 어렵습니다. 첫 번째는 잘 이해되지 않는다는 것입니다. SAN은 실제로 단순합니다. 너무 단순하여 파악하기 매우 어렵고, 따라서 놀랍도록 복잡하게 느껴집니다. SAN은 사실상 추상화되고 재분할되어 다시 호스트에 DAS로 제공되는 DAS입니다. '공유 스토리지'라는 용어는 NAS처럼 SAN 기술이 여러 호스트를 단일 스토리지 시스템에 연결할 수 있도록 하지만 동일한 파일시스템에 연결된 호스트들 간의 조정 형태를 제공하지 않기 때문에 혼란스럽습니다. NAS는 지능적이며 이를 처리하여 공유 스토리지를 '공유'하기 쉽게 만듭니다. SAN은 그렇지 않으며, 너무 단순합니다. SAN은 너무 단순하여 사실상 발생하는 것은 단순히 단일 하드 드라이브(추상화될 수 있지만)가 여러 호스트의 컨트롤러에 연결되는 것입니다. 공유 스토리지가 두 서버를 단일 SCSI 케이블에 연결하는 것을 의미했던 시절에는 이것을 쉽게 상상할 수 있었습니다. 오늘날 SAN의 추상화와 NAS의 보편화로 인해 대부분의 IT 사업장은 SAN이 무엇을 하는지 잊어버리고 재난이 발생할 수 있습니다.

SAN에는 분명 그 자리가 있지만, SAN은 사용하고 관리하기 복잡하며 매우 제한적입니다. 종종 매우 비싸기도 합니다. SAN에 관한 경험의 법칙은 이것입니다: SAN이 필요하지 않으면 다른 것을 사용하십시오. 그것이 전부입니다. SAN은 유일한 옵션이 될 때까지 피해야 하며, 그럴 때 그것이 올바른 선택입니다. 성능이나 비용 때문에 선택되는 경우는 거의 없습니다. 일반적으로 다른 옵션보다 성능이 떨어지고 비용이 더 들기 때문입니다. 하지만 HyperV를 백업하거나 데이터베이스 클러스터를 구축할 때는 다른 선택지가 없습니다. SMB에서 대부분의 사용 사례에서 SAN을 효과적으로 사용하려면 스토리지를 공유하기 위해 그 앞에 NAS를 배치해야 할 것입니다.

NAS는 공유 스토리지 사용 시나리오의 대다수를 차지합니다. 단순하고, 잘 이해되며, 유연합니다.

오늘날 많은, 아니 대부분의 공유 스토리지 어플라이언스는 SAN과 NAS를 모두 처리하며, 둘의 차이는 무엇보다 사용 방식, 프로토콜 및 이념에 있습니다. 종종 물리적 장치는 유사하거나 동일하며, 오늘날의 연결 기술도 마찬가지입니다.

무엇보다도 공유 스토리지를 찾을 때 구체적인 목표를 마음에 두는 것이 중요합니다. 이러한 목표를 적어두고 각 기술과 제품이 이러한 목표를 어떻게 충족하는지 또는 충족하지 않는지 살펴보십시오. 즉각적인 결정이나 마케팅 자료 또는 시장 모멘텀처럼 보이는 것에 기반하여 작업하지 마십시오. 공유 스토리지가 필요한지 먼저 결정하는 것부터 시작하십시오. 그렇다면 NAS가 요구사항을 충족하는지 결정하십시오. 그렇지 않다면 SAN을 검토하십시오. 스토리지는 큰 투자입니다. 대안을 살펴보고, 많은 조사를 하고, 몇 가지 구체적인 경쟁 제품으로 범위를 좁힌 후에만 최종 세부 사항과 가격을 위해 벤더에게 문의하십시오.