Workshop-SAN
상태바
Workshop-SAN
  • 승인 2005.04.27 00:00
  • 댓글 0
이 기사를 공유합니다

무엇을 얻을 수 있는지 먼저 판단하라
마이그레이션 데이터 용량 파악 필수 … 과욕은 금물

SAN 구축에 대해 생각해 본 적이 있는가. SAN으로부터 무엇을 얻을 수 있는지를 먼저 판단해 보라. 통합된 스토리지인가, 보다 지능적인 스토리지 성장인가, 집중식 백업인가, 아니면 고 가용성 고 대역폭의 플랫폼인가. 그런 다음 이러한 필요를 충족시키도록 솔루션을 설계하고, 이에 따라 예산을 설정하라. 이것이 처음 시도하는 SAN이라면, 기존의 전용 스토리지 혹은 NAS(Network Attached Storage) 장비에서 SAN으로 어떤 데이터를 얼마나 많이 옮겨야 하는지를 결정하라. 또한 백업과 고 가용성의 무결성을 둘 다 어떻게 보장하는지도 알아야 한다.

SAN은 저렴하진 않지만 시리얼 ATA나 iSCSI와 같은 신기술들 덕분에 어포더블이 되어가고 있으며, 파이버 채널 제품들이 1만달러부터 출발하고 있다. iSCSI 솔루션 비용이 훨씬 낮은 편이지만, 이들은 보통 파이버 채널(FC) 제품의 성능을 가져다주지 못한다. 많은 고 대역폭 애플리케이션이 있다면, EMC, 히타치, IBM 등에서 내놓는 고성능 SAN 제품들을 고려해 보라.
기간업무지만 그다지 대역폭 집약적이 아닌 애플리케이션이 몇 된다면 이퀄로직(EqualLogic)이나 인트랜사(Intransa)의 고성능 iSCSI 옵션을 고려해 보라. 부족한 예산으로 FC SAN 성능을 원할 경우에는 애플 X서브 레이드(Apple XServ RAID)를 고려하라.
위스콘신 주 그린베이에 있는 네트워크 컴퓨팅 리얼월드 랩에 있는 주 테스팅 SAN은 혼성으로, 아답텍 SAN블록-2(Adaptec SANBlock-2) 2기가비트 드라이브 어레이와 애플 X서브 레이드, 그리고 에뮬렉스 스위치(Emulex Switch)가 있다. 3GB 램이 있는 우리의 양방향 하이퍼스레디드 서버는 LSI 로직 2기가비트 FC 카드를 사용하고 윈도 2000 SP4를 돌린다.

결정해야 할 것들
SAN을 설계할 때 가장 우선되는 작업 가운데 하나는 NAS와 전담 스토리지에서 SAN 패브릭으로 얼마나 많은 데이터를 이동시킬지 결정하는 것이다. 단 하나의 애플리케이션을 SAN으로 옮긴다고 해서 그 애플리케이션이 기간업무 애플리케이션이 아니라면 수용 가능한 ROI를 줄 수 없다. SAN 이동을 평가할 때는 익스체인지 서버와 데이터베이스가 가장 좋은 출발점이다.
SAN은 서버를 떼어내 분해해서 새 드라이브를 꽂은 다음 나중에 시스템에 넣어 사용하도록 하기보다는, 공간을 추가하고 나서 시스템에게 정확히 구성됐음을 알릴 수 있게 해준다. 지금은 ‘보기 좋음(looks good)’ 버튼을 누르기만 하면 궁핍한 논리적 볼륨에 드라이브를 자동으로 분배해 주는 SAN 제품들이 늘어나고 있다. 그리고 거의 모든 고성능 SAN은 다운타임 제로와 디스크 용량 성장을 원활하게 하기 위해 드라이브를 핫스왑할 수 있게 해준다. 이러한 것들은 전용 스토리지로부터는 얻을 수 없는 혜택들이며, 장기적으로는 사용자들을 보다 행복하게 만들어줄 수 있다.
애플이나 HP, 윈체스터(Winchester) 등의 SAN 인 어 박스(SAN-in-a-box) 솔루션이나, 아답텍이나 이퀄로직 제품 같은 단일 유닛 iSCSI 솔루션을 원치 않을 경우에는 적절한 개별 컴포넌트를 구입해야 SAN이 날라갈 수 있다. 이러한 컴포넌트들로는 드라이브 인클로저(이들을 채울 드라이브가 있어야 한다), 하나 이상의 SAN 스위치, 호스트 버스 어댑터, 그리고 관리 및 백업용 소프트웨어 등이 포함된다. 또한 보통은 옵티컬인 FC 케이블링도 필요할 것이다. SAN을 지원하는 FC 테이프 백업 유닛을 구입하는 것을 고려해 보라. 어떤 기업에서는 백업이 SAN으로 옮기는 데 충분한 이유가 되기도 한다. SAN으로 고속의 디스크 투 디스크 백업을 한 다음, 여가 시간에 테이프로 백업을 할 수도 있다.
한 마디 경고하자면, FC는 여전히 호환성 문제로 고통을 겪고 있다. 따라서 자신이 선택한 서로 다른 모든 업체의 제품들이 서로간에 상호작동을 하는지 확인해 보아야 한다. 아니면 작동하지 않는 FC SAN 컴포넌트가 있음을 발견하게 될 것이다. 호환성 문제는 오늘날에는 줄어들긴 했지만, 지금도 업체들이 우리에게 테스트로 찾아올 때 SAN 조각의 모델 번호나 펌웨어 갱신을 요청하는 경우가 많아 다소 불안하게 만든다.
SAN을 하나씩 구축하고, 모든 게 함께 잘 돌아가도록 하는 게 엄두가 나지 않는다면, 대신 SAN 인 어 박스 키트를 구입하거나, 혹은 주로 이용하는 업체에게 SAN의 나머지 부분들을 추천해달라고 요청하라. 자사 제품이 어떤 컴포넌트와 작동을 하는지를 잘 알고 있다면, 고객 지원에 소모되는 시간을 줄일 수 있을 것이다.
SAN에서는 백업이 중요하며, 특히 증명 가능한 백업이 중요하다. 복구가 불가능하다면 SAN을 구축하는 의미가 없다. 좋은 소식은 선택의 여지가 있다는 사실이다. 사실 거의 실시간에 가까운 복제와 보다 큰 테이프들이 나와 있으며, 이들은 둘 다 수많은 데이터를 한 곳에 두고, 이 곳이 계속 안전하다고 믿으려 할 때 중요하다.

적합한 백업 솔루션을 선택하라
D2D2T(Disk-to-Disk-to-Tape) 어플라이언스의 가격은 점점 저렴해지고 있다. 그리고 전체 복구가 필요한 방대한 다운타임이 아니라 대부분의 저장소들이 “방금 어제 작업한 파일을 삭제했다. 다시 돌려놓을 수 있겠는가”라는 식의 상황이라면, D2D2T가 매력적일 것이다. 지난 며칠이 디스크에 있기 때문에, 어제의 우발적인 삭제를 수십 분, 수십 시간이 아니라 몇 초나 몇 분 만에 복구할 수 있기 때문이다. 그리고 오프사이트에서 들고다닐 수 있는 테이프 역시 갖게 된다.
SAN이 어떻게 사용될 것인지를 살펴본 다음, 적합한 백업 솔루션을 선택하라. D2D2T 솔루션은 보통 테이프 체인저들보다 비싸기 때문에, 이들 장비에서 ROI를 얻기 충분할 만큼 신속한 복구가 가능한지 여부를 먼저 파악해야 한다.

필요에 따라 증설
일단 SAN 컴포넌트를 모두 갖췄다면 디스크 공간을 어떻게 나누는지도 고려해 보라. 디스크가 전용 기계에 있을 때는 필요에 따라 디스크를 추가할 수 있지만, 공간을 합할 때 디스크 공간 할당에 대해 생각해 봐야 한다.
논리적 볼륨이 서버로 분할 및 할당되며, 대부분의 솔루션들은 로컬 볼륨을 키울 수 있게 허용하지만 이들을 줄일 수 있게 해주는 것은 몇 되지 않는다. 따라서 우선 옮기고 있는 각 시스템용으로 전담된 기존의 스토리지를 SAN으로 모델링을 한 다음, 필요에 따라 로컬 볼륨을 늘리도록 하라. 각 기계나 특정 계산에 따라 요구되는 디스크 공간을 줄여주는 ILM 솔루션으로 귀찮아할 필요가 없다. 각각의 SAN과 애플리케이션, 그리고 환경은 서로 다르기 때문이다. 과거는 미래의 가장 좋은 지표가 된다. 특정 애플리케이션의 스토리지 필요가 1년에 20% 증가한다고 알고 있다면, DAS 시스템에서 갖고 있던 공간의 120%를 주라. 앞으로 언제든지 이 LUN(Logical Unit Number)에 더 많은 스토리지를 할당할 수가 있다.
SAN의 크기를 정하는 데에는 일종의 비법이 있다. 오늘날의 데이터를 지원하기에만 충분히 큰 디스크로 고성능 솔루션의 모든 드라이브 베이를 채운다면, 앞으로의 확장을 보증할 수가 없다. 업체로 하여금 SAN과 함께 성장하지 않는 작은 드라이브로 박스를 채우게 해서는 안 된다. 향후 5년간 얼마나 많은 공간이 더 필요할지를 판단해 보고, 거기에 따라 크기를 정해야 한다. 디스크 공간은 여전히 싸겠지만, FC SAN용 드라이브 어레이는 그렇지가 않으며, 이들을 전체 인프라에 맞추는 데도 마찬가지다. 인클로저보다는 드라이브를 추가하는 편이 더 낫다.
스위치의 경우도 마찬가지다. 각각의 인클로저와 각 서버, 그리고 아마도 테이프 체인저용으로 포트가 필요할 것이다. 5년 이상 필요를 지원할 수 있는 스위치나, 혹은 오픈 슬롯이 있어서 앞으로 포트를 추가할 수 있는 스위치를 선택하라(디렉터급 장비라면). 백업과 다중업체 패브릭, 그리고 가상 LUN용으로는 그에 걸맞는 관리 소프트웨어가 필요할 것이다(몇 개의 물리적 인클로저에 하나의 ‘가상 디스크’를 분할함으로써 몇 개의 인클로저 등과 같은 많은 소스들의 디스크들을 하나인 것처럼 관리할 수 있다).
각각의 스토리지 업체가 포함시켜 둔 놀랄만큼 유용한 툴들을 이용할 수도 있지만, 이들은 보통 너무나 업체 전용이다. 이런 소프트웨어가 SAN을 고통없는 것으로 만들어 주기 위해 아직도 먼 길을 가야만 한다.

가상 SAN
업체들이 뭐라고 말하든 SAN 구성은 정확히 말해 플러그 앤 플레이가 아니다. 스위치를 구성하고, 호스트 버스 어댑터에게 어디서 스토리지를 찾을지를 알린 다음, 관리 툴을 이용해 스토리지를 분석해야 하며, 이런 모든 작업은 전에 해본 적이 없는 사람이라면 몇 번씩 시도를 해야 될 것이다. FC 또한 다른 네트워킹 프로토콜이 하는 것과 같은 일을 해야 하는 네트워킹 프로토콜이라는 사실을 명심해야 한다. 즉 이것은 메시지를 돌려보내기 위한 타깃과 경로를 고유하게 식별해 내는 수단이다.
SAN 스위치는 여러 가지 면에서 성장해 왔다. 여기에는 VSAN(Virtual SAN) 기능이 있는데, 이것은 가상랜이 데이터를 트렁킹하는 방식과 유사하게, ‘이 포트들만 타깃을 볼 수 있다’는 식의 정의를 가능하게 해준다. VSAN은 HR과 같이 SAN에 민감한 정보를 두는 부서에서 유용하게 사용된다.
SAN을 처음 구축할 때는 패브릭의 개념이 그다지 중요하지 않다. 패브릭은 FC 제품의 전체적인 네트워크로, 규모가 큰 설치 기반에서는 최소한 랜 만큼은 복잡하다. 패브릭이 작다면 에러로 다운타임이 유발될 가능성은 거의 없으며, 따라서 여기서 더 이상 이 문제를 논하지는 않을 것이다. 다만 패브릭에 있는 각 장비에는 IP 네트워크에 있는 것 것과 같은 ID가 있으며, IP 네트워크에서처럼 SAN에서도 중복 이름이 문제가 된다는 사실을 명심하라. FC의 ID는 월드 와이드 네임(World Wide Name)이라 불리며, 비록 추천 사항은 아니지만 일부 업체에서는 스스로 이것을 구성할 수 있게 해주고 있다.
한편, 랜용 허가(permission)를 구성해야 하는데, 많은 제품을 널리 개방시켜둘 수도 있지만 이것이 최선이 아니다. 대부분의 스위치들은 이제 온 스위치 액세스 제어나, 일종의 저장소(ADS나 래디우스 등) 액세스 제어를 지원하고 있다. 저장소 액세스 제어가 보다 간편하다. 대부분의 서버와 애플리케이션들이 SAN에 액세스를 하고 있을 것이기 때문에, 코어 비즈니스 애플리케이션을 돌리는 사용자들에게는 인증이 필요하다는 사실을 명심하라.
SAN에서라는 점만 다를 뿐 백업은 백업이며, 약간 더 SAN에서는 더 위력이 크다. SAN에서 백업이 실패하면 한 두 개의 애플리케이션이 있는 하나의 서버가 아니라 20개의 서버와 40개의 애플리케이션이 다운될 수 있다. 여기서는 D2D2T가 도움이 되는데, 즉 디스크 기반 백업을 훨씬 더 빨리 확인할 수 있으며, 이것은 심지어 테이프 전용 솔루션보다 훨씬 좋아진 복구시간은 염두에 두지도 않았을 때다.
필요를 신중하게 검토해 보고, SAN 업체의 도움을 구한다면, 처음 하는 SAN 배치도 크게 힘들지는 않을 것이다. 하지만 업체들이 SAN 인 어 박스라고 부르는 것이라 하더라도 구성을 하는 데는 얼마간의 여분의 시간을 따로 할당해야 한다. 기성품 SAN의 경우 아웃 오브 더 박스로 필요를 충족시켜 주지는 못하기 때문에, 맞춤화를 준비해야 한다. iSCSI를 이용한다면 iSCSI SAN 업체가 금방 문 닫을 곳은 아닌지 확인해야 한다. 이 고속 성장 시장은 얼마간의 통폐합이 예상되기 때문에, 규모가 있는 업체에서 구매를 해야 밖에서 떨게 되는 일을 피할 수 있다.
어떤 SAN 솔루션을 선택하든, 스토리지 관리 소프트웨어는 SAN용 가동시간을 관리 및 유지하도록 도와줄 수 있다. 어떤 기능이 자신에게 유용한지를 찾아보고 가장 잘 맞는 툴을 구입하도록 하라. 하지만 필요 이상을 사서는 안 된다. 구입하는 각 패키지는 고유의 기능성을 제공해야 하며, 유지보수가 필요할 것이다.

Step by Step

기본만 잘 갖추면, SAN을 선택 및 구성하는 일도 쉽게 할 수가 있다.

현재의 디스크 상태를 점검하라. 얼마나 많은 디스크 공간을 사용하고 있는지, 그리고 데이터는 얼마나 빨리 성장하고 있는지를 파악하라.

어떤 애플리케이션(그리고 따라서 얼마나 많은 디스크 공간)이 SAN으로 이동하게 될지를 판단하라. 5년 동안의 연간 성장률을 계산해서 실제 요건들을 파악하라.

성능과 사양 요건을 결정하라. 부하를 조절할 수 있는 SAN을 구입하되 과도하게 넘지는 말라. 필요하다면 초당 1천만 트랜잭션을 지원하는 시스템이 좋겠지만, 그렇지 않을 경우에는 낭비다.

패키징을 선택하라. 인클로저, 호스트 버스 어댑터 및 스위치를 고르거나, 아니면 SAN 인 어 박스를 사라.

모든 컴포넌트를 설치 및 구성하라. SAN의 각 서버는 호스트 버스 어댑터가 설치되는 동안 다운타임이 필요할 것이며, 스위치들은 IP 접속이 필요할 것이다. 그런 다음 이 모든 것을 케이블링하라.

보안과 가상랜을 구성하라. 스위치가 액세스 제어를 어떻게 처리하는지를 반드시 알고, 이것을 구성할 시간을 따로 마련해야 한다.

최소한의 LUN 크기를 결정하라. 이것은 계산으로 나온 예상 공간 요건을 기반으로 할 것(2단계 참조).

논리적 볼륨을 구축하라. 현재의 데이터를 수용할 수 있을 만큼 크게 잡되 너무 지나치게는 잡지 말라. 대부분의 시스템들이 나중에 공간을 추가할 수 있게 해주고 있기 때문이다.

SAN에 적합한 백업 솔루션을 선택하라. FC 백업 어플라이언스를 살펴보고, D2D2T 어플라이언스를 고려하라. 여분의 공간이 있다면 복제도 나쁜 생각은 아니다.


댓글삭제
삭제한 댓글은 다시 복구할 수 없습니다.
그래도 삭제하시겠습니까?
댓글 0
댓글쓰기
계정을 선택하시면 로그인·계정인증을 통해
댓글을 남기실 수 있습니다.