약 5년 전부터 관심을 모으던 블레이드 서버가 최근 업체들의 적극적인 제품 출시와 함께 본격적으로 도입 사례가 발표되면서 새로운 전기를 맞이하고 있다. 블레이드 서버는 2m 표준 랙 하나에 수백 대의 서버를 장착할 수 있는 공간 집약적인 솔루션으로, 사실상 1U 랙 서버의 등장과 동일선상에 있다.
2000년대 초반 닷컴 열풍이 불면서 무한한 확장성을 제공하는 스케일 아웃 아키텍처에 대한 관심이 높아지면서 작은 공간에 밀집된 서버 팜을 구축할 수 있는 랙마운트 방식 1U 서버가 등장했다. 하지만 1U 서버의 경우 기본 랙에 42개의 서버, 최대 84개의 CPU를 장착할 수 있지만, 높은 발열량과 전력 소모량이 문제시 됐고, 랙에 밀집된 서버들을 관리하는 데도 어려움이 많았다. 이에 서버 밀도를 더욱 높여주고 통합 관리가 가능한 블레이드 서버가 등장한 것이다.
하나의 섀시에 모듈 방식으로 구성된 서버 블레이드들을 필요한 만큼 장착해 사용하는 방식인 블레이드 서버는 공간 절약과 낮은 운영비용이 최대 장점으로 꼽힌다. 하지만 이런 장점에도 불구하고 블레이드 서버는 그동안 더딘 성장률을 보여왔다.
이는 현재 많은 서버를 운영하고 있는 IDC에서 적극적인 도입을 꺼려왔기 때문이다. 과도한 전력 소모와 발열로 인한 IDC 설계상의 문제와 단위면적당 과금하는 요금 체계 문제 등으로 IDC에서는 지금까지도 고객 요청에 의한 제한적으로 경우를 제외하고는 블레이드 서버를 반기지 않고 있다.
LG히다찌 엔터프라이즈블레이드시스템팀 서태진 부장은 "IDC의 외면과 함께 블레이드 서버의 대당 가격이 비슷한 성능의 기존 랙형 서버에 비해 높았기 때문에 일반 기업에서는 1U 또는 2U 사이즈의 저가 서버를 더 선호했다"며, "더불어 초기 블레이드 서버가 단순히 서버 탑재 수에만 치중된 나머지 다른 여러 장점들을 충분히 전달되지 못했던 점도 시장 확산의 걸림돌이었다"고 설명했다.
이처럼 블레이드 서버는 그동안 시장에서 많이 거론돼 왔지만 실제적인 도입으로는 연결되지 않아 큰 인기를 모으지 못했다. 하지만 최근 IDC의 발표에 의하면 지난해 블레이드 서버 시장은 2004년 11억 5000만 달러에서 84% 증가한 21억 1000만 달러로 확대됐다. 또한 국내 블레이드 서버 시장은 현재 연 평균 50% 이상 급격한 성장률을 보이며, 2009년에는 전체 서버시장에서 30%가량을 차지할 것이라고 'IDC 서버 트랙커'에서는 전망했다. 업계 관계자들도 유닉스 서버와 x86 서버 시장이 뚜렷한 성장세를 보이지 않는 반면, 기존 서버의 교체시기가 도래하고 있어 블레이드 서버가 침체된 서버시장에 활력소가 될 것으로 예상하고 있다.

올해부터 본격적인 성장세 돌입 기대
블레이드 서버는 블레이드 섀시에 서버를 고밀도로 탑재하기 때문에 공간 활용면에서 커다란 장점을 제공할 수 있다는 것이 특징이다. 또한 서버 간 연결이 섀시 간 네트워크에 연결돼 시스템 구축을 단순화할 수 있으며, 확장성이 용이한 것도 장점이다. 이같은 장점 때문에 블레이드 서버는 등장 초기부터 많은 관심을 불러 일으켰으며, 여러 시장조사 기관에서는 전체 서버시장에서 높은 점유율을 보이며 시장의 기대주로 떠오를 것이라 호언장담했었다.
하지만 지난 5년 간 블레이드 서버의 보급 성적을 보면 그다지 좋은 편이 아니다. 지난해까지 국내에서 블레이드 서버 판매량이 1000대 미만이라는 사실은 많은 대형 서버업체들과 국내 업체들의 노력에 비하면 형편없는 수치다.
유니와이드 마케팅팀 권창선 팀장은 "현재 국내시장은 전체 서버 시장에서 1% 미만일 정도로 해외 시장과 비교해 저조한 성적을 보이고 있다"며, "작년 하반기부터 업체들이 시장을 확산시키기 위해 다양한 홍보와 마케팅에 주력하며 제품 출시를 앞다퉈온 만큼 올해는 좋은 결과가 있을 것"이라고 내다봤다.
IDC에 의하면 세계 블레이드 서버 시장은 매출 기준으로 오는 2009년까지 연평균 51%의 높은 성장세를 지속할 것이라고 전망하고 있다. 이에 따라 2009년이면 출하량 300만대, 매출 규모 100억 달러의 시장을 형성하게 될 것이라고 밝히고 있다. 이미 국내에서도 2004년 대비 2005년 15.8%의 매출 증가율을 보였으며, 올해도 이 같은 성장세는 더욱 가속화될 것으로 기대하고 있다.
IBM PLM부 명한신 전문차장은 "지난해 x86 서버 시장에서 블레이드 서버는 5% 수준이었으나 성장 가능성은 높다고 본다"며, "아무리 좋은 기술이 나오더라도 시장에서 무르익기까지는 어느 정도의 시간이 필요하듯 블레이드 서버는 이제부터가 시작이다"고 말했다.
업계에서는 그동안 블레이드 서버 도입을 방해하던 여러 가지 요소들에 대한 해결의 실마리가 보이고 시작했고, 기술적 수준도 높아짐에 따라 해외에서의 성장세를 국내에서도 이어갈 수 있을 것으로 기대하고 있다.

블레이드 서버 매력은 '관리 용이성'
블레이드 서버는 높은 프로세스 밀도를 통한 공간 절약이 대표적인 특징이지만, 기존 1U 서버와 비교했을 때 관리의 용의성과 유연성도 큰 매력이다. 1U 서버의 경우 하나의 표준 랙에 40여 개의 서버를 장착할 수 있기 때문에 단위 면적당 성능은 향상시킬 수 있었지만 관리 측면에서는 어려움이 많았다.
수십 대의 서버 중 문제가 발생한 서버를 찾기가 쉽지 않았으며, 좋은 관리 스프트웨어를 사용한다 할 지라도 한두 가지 변경이 필요할 때 전체 서버에 적용하는 것이 쉽지 않았다. 또한 40여 대의 서버에 연결하기 위한 수많은 전원 케이블과 네트워크 케이블 때문에 유지 보수하는 작업도 관리자에게는 부담스러웠다.
블레이드 서버는 이런 서버 관리의 문제를 보다 간편하게 해준다. 섀시와 블레이드로 구성된 블레이드 서버는 블레이드 자체로는 아무런 동작을 할 수 없다. 각각의 블레이드는 섀시를 통해 전원을 공급받고 콘솔과 I/O를 공유하는 구조를 가지고 있기 때문에 통합 관리가 가능해 보다 쉽게 관리와 유지보수를 할 수 있다. 갈수록 기업이 거대화되고 전산실 시스템 또한 복잡화됨에 따라 이런 서버 관리의 편의성은 기업들의 입맛을 충족시키기에 충분하다.
LG히다찌 서태진 부장은 "시스템 문제 시 이에 따른 비즈니스 기회가 손실됨에 따라 최근 기업들은 안정성과 함께 관리의 중요성에 초점을 맞추고 있다"며 "블레이드 서버는 통합 관리 기능을 제공함에 따라 통합이 간편하며, 전용 관리 솔루션을 이용하면 관리 인건비도 크게 줄일 수 있다"고 설명했다.
한국HP의 관계자는 기존 서버는 관리자당 15∼20대 정도의 서버를 관리했던 것에 비해 블레이드 서버는 약 50대, 가상화 솔루션을 적용할 경우에는 100대의 서버까지도 혼자서 관리할 수 있을 만큼 관리성이 좋다고 말한다.
또한 대부분의 블레이드 서버가 손쉽게 주요 부품을 핫플러깅 방식으로 교체할 수 있으며, HP에서는 인사이트 매니저의 오토메이션 팩을 적용하면 여분의 블레이드를 이용해 핫스왑 기능을 제공하기까지 한다고 말한다.
한편 블레이드 서버는 관리의 용이성 외에도 스케일 아웃과 스케일 업 모두가 가능하기 때문에 유연한 성능 확장을 제공해 준다. 따라서 기업이 초기 시스템 도입 시 오버스펙으로 용량을 산출할 필요가 없어 불필요한 IT 예산을 절감할 수 있다고 업계 관계자는 전했다.

기술적 발전 거듭하며 완성도 높여
고밀집도와 함께 확장성, 관리성 등이 유리하다고 평가받은 블레이드 서버는 초기 시장에서 CPU의 발열로 인해 성능 저하나 수명 단축과 같은 문제가 발생할 수 있다는 의심을 받았다. 하지만 블레이드 서버는 설계 단계에서부터 이 문제를 고려했고, 수많은 테스트를 거쳐서 나온 제품이기 때문에 발열에 대한 문제는 크게 신경쓰지 않아도 된다고 업체들은 주장한다.
현재 선보이고 있는 블레이드 서버는 주로 인텔 CPU 기반 시스템이며, 이외에 AMD의 CPU와 RISC CPU인 썬의 SPARC, IBM의 파워 PC 프로세스를 장착한 제품도 있다. 하지만 대부분의 블레이드 서버가 타깃하고 있는 시장 자체가 웹 서버와 같은 프론트 엔드 서버이며, 주요 운영체제로 리눅스를 채택하는 경우가 많기 때문에 인텔 기반 CPU를 사용하는 것이 일반적이다.    
업계에서는 윈도우와 유닉스가 득세하고 있는 국내 서버 환경에서 블레이드 서버 대부분이 리눅스를 운영체제로 채택하고 있음에 따라 도입 분야가 제한적일 것이라는 우려도 했었다. 하지만 지난해부터 공공, 통신, 금융, 제조 등 다양한 분야에서 리눅스 도입 사례가 늘어나면서 이 같은 걱정은 풀리고 있다.
유니와이드 권창선 팀장은 "1세대 블레이드는 단순히 서버, 네트워크 등을 하나의 랙에 제공했다"며, "최근에 등장하는 2세대 블레이드 서버는 기존 1세대에 비해 탁월한 공간 절약과 구성 관리가 용이하며, 애플리케이션 서버, 데이터 서버 등 3계층을 수용하면서 기간 시스템까지 폭넓게 적용 가능해졌다"고 설명했다.
또한 블레이드 서버는 예전에 비해 성능도 많이 향상됐다. 초기엔 1U 크기의 슬림형 서버 보다 2배 이상의 단위 면적당 컴퓨팅 기능을 제공했지만 지금은 2웨이에서 최대 16웨이까지 스케일 업이 가능하며 듀얼코어 제품이 출시되면서 성능 차이는 더욱 커질 것으로 예상된다.  
LG히다찌 서태진 부장은 "성능이 계속적으로 업그레이드되면서 대형 서버에 버금가는 성능을 발휘할 수 있게 됐다"며, "인텔의 가상화 기술인 VTi가 상용화되면 프로세서의 물리적인 제약을 받지 않는 멀티 운영체제 환경에서의 I/O 가상화 기술이 적용된 블레이드 시스템 운용이 가능해 질 것"이라고 설명했다.

고객의 인식 전환 위한 노력 필요
지금까지 블레이드 서버는 서버 밀도 향상으로 인한 공간의 효율성만을 앞세워왔기 때문에 다른 장점들에 대한 인식이 부족한 상태였다. 대부분 1U 서버를 대체하는 새로운 방식의 서버 정도로만 인식하고 있을 뿐 블레이드 서버의 다른 장점에 대해서는 거의 알지 못하고 있다.
업계에서는 이것 또한 시장 확산에 있어 어려움 중의 하나로 보고, 지난해부터 블레이드 서버의 확장성이나 성능, 관리성, 가용성 등에 대한 홍보에 집중해 오고 있다. 이런 업체들의 노력으로 블레이드 서버가 어떤 장점을 갖고 있는지 많이 알려져 가고 있지만,  대부분의 업체들이 기본 운영체제로 리눅스와 윈도우를 사용하기 때문에 안정성과 보안성에 대해서도 고객들이 의심의 여지를 갖고 있다고 업계 관계자는 전했다. 
또한 블레이드 서버의 비교적 높은 가격도 시장 확산의 장벽으로 작용하고 있다. 블레이드 서버는 서버당 가격이나 관리 비용 등을 감안하면 기존 1U 서버에 비해 저렴하지만, 초기 도입 시 섀시나 전원 장치, 전용 스위치 등의 가격을 고려했을 때 1U 서버에 비해 상당히 높은 편이다. 때문에 중소기업의 경우는 블레이드 서버의 도입이 쉽지 않은 상황이다. 이에 한국IBM은 지난해 블레이드 서버 무료 구축행사를 진행해 초기 설치 비용 때문에 도입을 주저하는 고객들에게 제품과 설치를 모두 무료로 제공하며 블레이드 서버의 장점을 적극 알리기도 했다.
이와 더불어 64비트 프로세서나 듀얼코어 프로세서 등의 등장으로 블레이드 서버의 경쟁상대인 1U 서버의 성능도 점차 향상되고 있어, 블레이드 서버로의 도입이 그다지 순탄하게 이뤄지진 않을 것으로 보인다는 게 업계의 의견이다.

IDC, 블레이드 서버 '안되겠네∼'
블레이드 서버의 가장 큰 수요처로 꼽히는 IDC에서의 외면도 블레이드 서버 보급에 있어 가장 큰 난관 중의 하나다. 이는 공간과 전력, 네트워크 등의 인프라에 대한 임대를 통해 수익을 올리는 IDC가 공간 절약에 절대적인 블레이드 서버의 입주를 반길 수만은 없기 때문이다. 이에 따라 IDC측은 서버 업체들이 IDC 설계에 맞는 저발열, 저전력 블레이드 제품을 만들어야 한다고 주장하며, 업체 측에서는 블레이드 서버에 맞도록 IDC의 관련 정책이 변해야 한다는 입장이다.
또한 호스팅 서비스 업체들도 계약을 통해 1∼2년 이후에는 서버를 고객에게 양도하는 방식을 사용하기 때문에 하나의 섀시에 장착된 여러 개의 블레이드 서버를 어떻게 양도할 것인가에 대한 문제가 발생해, 블레이드 서버 도입에 어려움이 있다고 말한다.
IBM 명한신 전문차장은 "IDC의 경우 기존 랙에 들어가는 전원 용량으로는 블레이드 서버를 감당할 수 없기 때문에 새로운 시설 투자가 있어야 한다"며, "이 같은 전원 문제는 IDC뿐 아니라 기존의 랙마운트 서버에 맞춰 전원 용량을 설계한 기업 데이터센터도 상황은 마찬가지다"고 설명했다.
지난 하반기부터 블레이드 서버의 장점에 주목한 여러 온라인 기업에서는 브레이드 서버를 적극적으로 도입함에 따라 IDC에서도 일부 제한적으로나마 받아들이고 있는 상태다. 업계 관계자는 지난해까지 IDC 영업이 힘들어 대기업 시장을 겨냥한 프로모션을 진행해 왔으나, 이제는 고객들의 블레이드 서버에 대한 요구가 늘어남에 따라 IDC와의 단계적인 협력으로 올해 안으로 좋은 성과가 나올 것이라 전했다.

업체별 제품 출시 경쟁 '치열'
지난해 말부터 블레이드 서버의 시장 진입이 본격적으로 이뤄지면서 서버 업체들은 블레이드 서버 출시에 열을 올리고 있다. 특히 최근 등장하고 있는 제품은 64비트 프로세서를 채택한 고성능 제품들이며, 듀얼코어 프로세서를 채택한 제품들도 선보이고 있어 블레이드 서버의 고성능화가 점차 가속화되고 있다.
현재 국내 블레이드 서버 시장은 한국HP, 한국IBM, 한국후지쯔 등이 선도하고 있으며, 델코리아, 유니와이드 등이 그 뒤를 따르고 있는 상황이다. 이외에도 한국썬, 이제네라, 이슬림, 디지털헨지 등이 제품을 선보이고 있으며, 최근에는 LG히다찌와 저전력 블레이드 서버로 유명한 미국의 버라리시스템즈(VerariSystems)가 제품을 출시하며 시장 공략에 적극 나서고 있다.
IBM 명한신 전문차장은 "아직 블레이드 서버 시장 규모가 미미해 대형 수주 한 건만으로도 쉽게 업체의 시장 점유율 순위가 바뀌고 있다"며, "시장이 막 형성되는 단계이기 때문에 누가 많은 레퍼런스를 확보하느냐에 따라 향후 시장 선점에 보다 유리할 것"이라고 설명했다. 
지난해 다양한 고객사를 확보하며 블레이드 서버 시장에서 입지를 강화해 온 한국HP는 최근 인텔 제온 듀얼코어 기반의 'BL20pG3'과 인텔 아이태니엄 기반의 'BL60p' 등 신제품 출시를 통해 인텔 기반 블레이드 서버 제품 라인업을 강화했다. 
특히 이들 서버는 기존 블레이드 시스템과 동일한 엔클로저를 그대로 사용할 수 있고, 다중 운영체제 환경에서 서버, 스토리지 네트워크를 통합 관리할 수 있기 때문에 고객들의 투자비용을 획기적으로 절감할 수 있는 것이 특징이다.
블레이드 서버 사업을 올해 중요 사업으로 선정한 한국IBM은 올해부터 자사 블레이드 서버인 블레이드 센터에 썬의 솔라리스 10을 탑재해 로우엔드 솔라리스 서버에 대한 블레이드 서버 통합을 적극 제안할 방침이다.
또한 최근 네트워크 상에서 전송속도가 10배 이상 향상된 신규 블레이드 서버인 '블레이드센터 H'를 이번 달에 출시한다고 밝혔다. 블레이드센터 H는 기존 IBM의 블레이드 센터와 호환되는 제품으로 '빌트인 가상화' 기능을 비롯해, CPU 당 9개의 코어가 탑재돼 있다. 또한 데이터센터에서 필요한 정확한 전력량을 측정하는 기능이 있어, 전력과 냉방 효율이 높아졌으며 다중운영체제 지원서버인 IBM i5와 iSCSI로 연결돼 i5의 가상 스토리지, 네트워킹, 테이프 자원 등을 이용해 윈도우 서버 시스템의 인프라를 단순화시킬 수 있다.
한국후지쯔는 지난해 포스코, 중앙고용정보원 등에 블레이드 서버를 공급하면서 국내 시장에 성공적으로 안착했다는 평가를 받고 있으며, 오는 4월까지 블레이드 서버 전문 채널도 선정할 예정이다. 그동안 저가 서버 위주로 제품을 공급해온 델은 블레이드 서버 사업을 통해 올해 x86 서버의 수익성을 크게 개선할 수 있을 것으로 기대하고 있다.
기존 서버 업체들의 다양한 움직임과 더불어 1990년대 후반 국내 서버 시장에서 철수했다가 재진입을 노리고 있는 히다찌도 LG히다찌를 통해 블레이드 서버 사업을 본격화한다고 밝혔다. LG히다찌는 최대 8개의 인텔 아이테니엄 프로세서를 탑재한 블레이드 서버인 블레이드심포니(BladeSymphony)를 국내 첫 출시하며 시장 공략에 적극 나선다는 방침이다.
유니와이드는 인피니밴드 스위치가 내장된 최초의 블레이드 서버인 익스트림블레이드 제품으로 클러스터링 등 HPC 부문에서 좋은 성과를 보이고 있으며, 올 상반기 내에 옵테론 프로세서를 4웨이까지 확장 가능한 노드와 함께 부분적인 모델 업그레이드가 이뤄질 계획이라 전했다.
버라리는 자체 냉각 기술인 '버라리 쿨링 기술' 특허를 확보하고 있는 업체로, 전력 소모가 다른 블레이드 서버에 비해 35% 정도 낮은 것이 가장 큰 특징이다. 특히 버라리는 블레이드 서버의 차별화에 성공해, 미국 시장에서 IBM, HP 등 대형 서버업체들과 어깨를 나란히 하고 있다는 평가를 받고 있어 국내 시장에서의 향후 활약도 기대된다.

올해 전망 '맑음'
지난해까지는 관련 업체들이 좀처럼 열리지 않는 국내 블레이드 서버 시장의 수요를 창출하기 위해 다양한 홍보와 마케팅 활동을 하는데 주력해 왔다면 올해는 시장 선점을 위한 본격적인 경쟁을 펼칠 것으로 예상된다.
또한 여기에 블레이드 서버의 운영체계도 다양화되고 있고, 올해를 기점으로 기존 랙형 서버의 전환 수요가 적극적으로 이뤄질 것으로 예상됨에 따라 어느 해 보다 '쾌청'할 것으로 예상하고 있다.
한 블레이드 서버 업체 관계자는 블레이드 서버로의 전환은 현재와 전혀 다른 아키텍처로 가는 것에 대한 추가 투자가 필요하고, 1U 서버로도 아직 한계를 느끼지 않고 있기 때문에 일반 기업들이 블레이드 서버로 옮겨가기에는 시간이 좀더 필요하다고 말한다.
실질적으로 블레이드 서버의 시장 규모는 아직 미미할 뿐 아니라 향후 2∼3년 내에도 큰 성장세를 보일 것으로 예상되지는 않지만, 공간 활용성과 통합관리 용이성 등 다양한 장점을 무기로 지속적인 성장세를 보이고 있다는 게 업계 전반의 의견이다.
특히 초기에 등장했던 블레이드 서버가 비용 절감을 위한 제한적인 용도로 사용하는 서버 솔루션이었던데 비해 최근의 블레이드 서버는 고성능의 고밀집형 디자인을 통해 메시징 시스템, CRM, ERP 등 대규모 엔터프라이즈 애플리케이션 시스템이나 데이터센터, 통신업체의 기간 시스템 시장까지도 노리고 있다. 이에 블레이드 서버의 주요 타깃인 IDC 보다는 현재 대기업과 공공, 금융권에서 더 많은 수요가 발생할 것으로 보고 있다.
업계 관계자는 블레이드 서버에 대한 수요가 커지고 있는 것은 네트워크, 스토리지, 소프트웨어 등을 모두 통합해 제공하는 또 하나의 IT 인프라 제품으로 의미가 확장되고 있기 때문이라고 분석했다.
이처럼 블레이드 서버는 올해 다시금 관심을 모으며 시장 확산에 열을 올리고 있다. 하지만 아직 IDC와의 해결점과 높은 초기 도입 비용 등 시장을 가로막는 장벽들이 아직 과제로 남아 있어 이들을 얼마나 빨리 해결하는지에 따라 성장세에 진입하는 시간을 앞당길 수 있을 것으로 보인다.

출처 : on the NET

따르릉. 어느날 사무실로 전화를 한 고객이 다짜고짜 묻는다.

고객 : 동시 접속자가 3만 명인데 어느 정도 사양의 서버가 필요합니까.
나 : 제일 좋은 서버 쓰세요(이때 나의 표정은 -.-;)

왜 못마땅한 표정(-.-;)을 지었을까. 컴팩, IBM, 델 등 그 어떤 서버에 대한 설명에도 동시 접속자가 3만 명을 지원한다는 수치는 기록하고 있지 않기 때문이다. 때문에 서버 사양을 결정하는 데는 고객의 환경이 가장 중요하며, 고객 역시 무조건 답만 알아내려고 할 것이 아니라 사전에 환경에 대한 파악부터 해야 한다.
IT에 종사하는 이들이나 IT를 조금 안다는 이들은 숫자 놀이를 좋아한다. 모든 데이터는 수치로 나타낼 수 있어야 하고, 그것을 바탕으로 다른 것과 비교할 수 있기 때문일 것이다. 그러나 아쉽게도 용량 계획은, 더군다나 초기 용량 계획에 대한 숫자는 존재할 수 없을 것이다. 없는 것은 아니지만 없다고 생각하는 것이 정답이다.

www.tpc.org라는 사이트가 있다. 여기서는 여러 가지 설정을 하고 그에 맞는 성능 테스트를 해서 그 결과를 볼 수 있다. 여기서 보면 애플리케이션 서버, 웹 서비스, 온라인 트랜잭션 프로세싱 등의 항목이 나온다. 그렇다면 여기에 기록된 수치가 앞으로 자기가 운영할 IIS와 MS SQL 서버에 그대로 적용될 수 있을까? 절대 아니다. 해당 사이트가 테스트한 환경과 내가 테스트할 환경은 절대적으로 틀리기 때문이다. 비슷한 환경에서 테스트했다고 생각할 수 있을지 모르지만, 정확하고 투명한 데이터도 아니고 신뢰할 만한 사항도 아니다. 결론은 '사전 용량 계획에 대한 답은 없다'라는 것이다. 답이 없다기 보다는 그걸 만들어내는 공식이 없다는 것이다.
그럼 방법이 없는가. 결론부터 이야기기를 한다면 서버용량에 대한 수치를 그려내기 위해서는 크기를 설정하고, 용량이라는 것을 계획한 후 운영을 하면서 정확한 데이터를 얻어야 한다.

용량 계획과 SLA
용량 계획은 사전 용량 계획과 사후 용량 계획 두 부분으로 나눌 수 있다. 이들에 대해 언급하기 전에 SLA(Service Level Agreement)라는 것에 대해 먼저 짚고 넘어가자. SLA를 한국말로 그대로 해석하면 '서비스 수준 동의'쯤 될 것이다. 이에 대한 정의는 다음과 같다.
SLA는 네트워크 서비스 공급업체와 고객간에 체결하는 계약으로, 대개 어떤 서비스가 제공될 것인지를 측정이 가능한 조건으로 명시한 것이다. 많은 수의 인터넷 서비스 업체들이 SLA와 같은 형태의 계약을 고객들에게 제공한다. 최근에는 대기업의 IT 관련 부서가 자신의 고객, 즉 사내 각 부서에서 근무하는 사용자에 대한 서비스를 측정하고, 근거를 제시하며, 외부 네트워크 제공업체와 비교하는 것이 가능하도록 SLA를 작성해 활용하는 방안을 채택하고 있다.

다음은 SLA에 포함돼야 할 척도 중의 일부다.

최근에는 SLA 경험자를 찾는 구인광고도 간간히 등장할만큼 SLA에 대한 중요성이 높아졌다.
SLA는 공급업체와 고객 간의 서비스 레벨에 대한 동의서이므로, 서로의 동의한 사항을 위반하면 그에 대한 벌금을 물게 되는 것이다. 고객의 서비스 항목을 잘 파악을 하고 그에 대해 공급업체는 '서버 가동시간을 99% 이상으로 하겠다'라거나, 고객은 '99.5%로 해달라' 등의 세부 항목을 설정하게 되는 것이다.
이런 항목 중에 빠지지 않고 들어가는 것이 용량 계획이다. 여기에는 사전 용량 계획에 대한 부분도 포함돼 있다.
일례로 CPU 사용률이 80% 이상을 넘을 경우(단, 하드웨어나 애플리케이션에서 이상이 없으면) 시스템을 업그레이드를 할 것이며, 업그레이드를 할 때는 어떤 크기로 할 것인지에 대해서 계약하기도 한다. 즉, 용량 계획이나 성능에 대한 부분과 그 이외의 여러가지 모니터링 부분 등이 결합돼 SLA가 맺어진다. 

IIS  사전 용량 계획하기 : CPU와 메모리
일반적으로 사전 용량 계획은 모든 환경(시스템, 애플리케이션, 네트워크 등)을 제품 기준으로 맞추고 스트레스 툴(Stress Tool)로 테스트해서 결과를 얻어낸다.
하지만 개인적으로 필자가 생각하고 있는 사전 용량 계획은 웹 애플리케이션 개발이 완료되고, 데이터베이스의 디자인도 끝내고, DB도 생성을 한 이후에 이 애플리케이션을 운영할 적당한 시스템이 어느 정도의 사양을 갖춰야 하는 가에 대한 값이다. 안타깝게도 이 부분에 대해 제시된 데이터는 없다. 하지만 좌절할 필요는 없다. 만들 수는 있기 때문이다.
일반적으로 시스템 크기를 선정할 때 CPU, 메모리, HDD(엄밀하게 얘기를 하면 디스크의 I/O), 네트워크의 네가지 구성 요소를 고려하는데, 이들의 한계치는 설정할 수가 있다. 만일 초보 시스템 관리자라면 아마 앞서 말한 TPC 사이트에 의존할지도 모르겠다.
그러나 이 글에서는 성능 모니터를 설정해서 어느 정도의 해답을 제시하려 한다. 그러나 여기서 제시하는 사항도 어디까지나 참고사항일 뿐이며, 그 수치가 아무리 신뢰할만한 데이터라고 해도 사전 용량 계획으로 잡아 둔 크기의 3배 이상으로 용량 계획을 할 것을 권장한다. 이유는 서버가 본격적으로 운영되기 시작하면서 예측하지 못한 부분에서의 서버 자원을 사용할 수가 있기 때문이다.
IIS를 설치하건 MS SQL을 설치하건 마이크로소프트가 주장하는 가장 첫 번째 요소는 HCL(Hardware Compatibility List)을 사용하라는 것이다. 핵심은 간단하다. 마이크로소프트에서 제공하는 드라이버가 있느냐 없느냐 하는 것이다. 마이크로소프트에서 제공하는 드라이버가 없다면 시스템 장애가 발생할 것이고, 마이크로소프트는 그에 대한 책임이 없다는 것이다. HCL에 있는데도 블루 스크린이 발생을 한다면? 이것은 장치가 고장이 났거나 드라이버의 문제가 있으므로 업데이트를 해야 한다. 기본적인 사항이므로 점검을 해보고 넘어가는 것이 좋다.
HCL 목록은 www.microsoft.com/whdc/hcl/default.mspx이다.

그럼 CPU는 어느 정도의 크기로 잡아야 할까. 정확한 수치를 제시할 수는 없지만 여유있게 투자하고 가능하면 캐시가 큰 것으로 할 것을 권장한다.
다행히 수치를 주는 사이트(http://servers.digitaldaze.com/compare/spec.html)가 있기에 소개한다. 그러나 너무 믿지는 말기 바란다.
메모리는 윈도우 2000 서버에서나 IIS 그리고 MS SQL에서도 가장 접근하기 어려운 부분이다. 병목 현상도 메모리에서 가장 빈번하게 발생한다. 이번 강좌에서 테스트하려는 서버의 IIS가 사용하는 메모리량은 30MB 정도다. 윈도우 2000에서 사용하는 메모리를 빼니 400MB 정도가 사용 가능한 메모리의 양이다. 메모리에 대한 수치도 사전에 제시한다는 것이 어렵다.
CPU나 메모리 크기를 적게 산정했다면 큰 문제가 되지 않을 수 있다. CPU가 2웨이, 4웨이를 지원한다면(물론 싱글만을 지원하는 보드를 구매할까 걱정이긴 하지만), CPU를 추가 장착하고 장치 관리자를 연다(화면 1).

(화면 1) ACPI 등록정보로 드라이버 업데이트하기

ACPI의 등록정보를 열어서 드라이버 업데이트를 연다. 특정한 드라이버를 선택할 수 있도록 이 장치에 적절한 드라이버 목록 표시를 선택하고 ACPI 다중 프로세스 PC를 선택한다(화면 2). 경고 메시지가 뜨면 예를 클릭하고 설치 완료를 하면 된다. 시스템 변경 관계로 재부팅을 하라는 메시지가 뜬다. 재부팅을 하면 원하는 숫자 만큼의 CPU가 있는 것을 여러 경로를 통해서 알 수가 있다.

(화면 2) ACPI 다중 프로세서 PC 선택하기

그럼 메모리가 부족하면? 마찬가지다. 원하는 만큼의 메모리만을 추가하면 된다. 그러나 디스크를 다시 재구성해야 할 상황이라면 문제가 있다. 심한 경우 시스템을 재설치해야 하는 경우가 생길 수도 있고 데이터를 이리저리 옮겨야 할 수도 있다. 쉽지 않은 부분인 만큼 계획을 잘 세워야 할 것이다.

IIS  사전 용량 계획하기 : 디스크 I/O와 네트워크
디스크 크기를 산정할 때는 시스템 파티션, 페이징 파티션, 데이터 파티션 그리고 백업과 로그를 생각해 볼 수가 있다. 조금 더 욕심을 내서 많은 애플리케이션들이 올라간다면 그것에 대한 디스크를 따로 가져가는 것도 고려해야 한다. 여러 다른 상황이 있겠지만 우선은 이 정도만을 고려하자.
윈도우 2000을 설치하고, IIS를 설정했다면 1GB가 조금 넘는 용량이 시스템 파티션에 사용되고 있을 것이다. 여유 있게 3배로 하라고 했으니 적어도 3GB 이상(권장 사항은 5GB 이상)이다.
참고로 디스크 전체 크기의 85%가 사용되고 있다면 그 디스크는 사용을 하지 않는 것이 좋다.
왜 15%나 남았는데 쓰지 말라고 하는 것일까. 그것은 바로 디스크의 검색 속도 때문이다. 디스크는 헤드가 왔다갔다 하면서 데이터를 읽거나 쓰거나 하는데, 85% 이상이 되면 검색 속도가 느려진다. 빨리 빨리 데이터가 메모리로 올라가서 CPU와 통신을 해야 하는데 검색 속도가 느려지면 메모리와 CPU는 대기 상태가 된다.
PAGEFILE.SYS가 위치할 페이징 파티션은 시스템 파티션과 마찬가지로 5GB로 잡는다. 아무리 물리적인 RAM의 양이 많다고 해도 실질적으로 가상 메모리인 페이징 파일은 4GB 이상을 사용하지 못한다. 물리적으로 메모리의 1.5배가 적당하다고 해서 그 숫자대로 한다면 큰 손해는 없지만 참고로 알아 두자.
데이터 파티션은 이미 개발이 완료됐기에 어느 정도의 데이터 양이 필요한지 계산이 끝났을 것이다. 거기에 맞게 계산을 해서 데이터 파티션을 잡으면 된다.
백업은 여러 용도로 사용될 수 있을 것이다. 데이터를 백업받을 수도 있고 윈도우 2000의 시스템 백업을 받은 다음 용량을 계산하면 쉽지만, 로그는 유동적이라 계산하기가 어렵다. 로그는 여러모로 필요한 사항이기 때문에 저장하는 것이 좋다. 그러나 디스크가 모자란다면 로그의 보관주기를 짧게 가져갈 것을 권장한다.
여기까지가 논리적인 파티션에 대한 설명이다. 이런 논리적인 볼륨들이 36GB SCSI 디스크 두개로 구성될 수도 있다.
그러나 현재 많은 브랜드의 서버 제품이 RAID를 많이 사용하는 추세다. RAID는 레벨로 따지며 0, 1, 5가 주로 사용되고 있으며, 0, 1, 5의 단점을 서로 보완하기 위해 01과 10이라는 레벨이 개발됐다. 레벨 01과 10의 차이는 스트라이프가 먼저 되는가. 미러가 먼저 되는가의 차이다(http://www.raid.co.kr/sub/study/RAID를 참고하자).
RAID 레벨을 이해하는 것도 중요하지만 운영할 IIS 서버에 맞게 레벨을 선택하는 것이 좋다.
윈도우 2000에서 소프트웨어적으로 RAID를 구현할 수 있지만 권장 사항이 아니다. RAID를 구성하려면 하드웨어적으로 하기를 바란다.

어느날 고객으로부터 연락을 받았다. 웹 페이지의 이미지 로딩이 한번에 펼쳐지는 것이 아니라 순차적으로 위에서부터 아래로 이미지가 하나씩 뜬다고 한다. 사이트에 들어가 봤더니 정말 사진이 한장씩 펼쳐진다. 이미지를 관리하는 서버가 따로 있고 모든 이미지는 이 서버에서 로딩되고 있는 상황이었다. 결론을 먼저 이야기하면 처음부터 디스크 사이징을 잘하고 RADI 레벨을 잘 선택했다면 이런 현상은 없을 것이다. 결국 이 사이트는 RAID 레벨 10을 도입했다. 변경 후 웹페이지는 정상적으로 작동했다.
디스크 용량 계획을 할 때는 크기도 중요하지만 그 데이터가 어떤 용도로 사용될 것인가를 고려하는 것도 중요하다.
최근 기업들은 100Mbps 전용 네트워크를 많이 선택한다. 우선은 이 정도면 충분하다. 때로는 10Mbps도 충분하다. 네트워크 회선 증설은 CPU나 메모리를 증설하는 것보다 쉽기 때문에 큰 걱정은 하지 않아도 된다. 100Mbps 전용이 양에 안차면 기가비트 이더넷을 사용하면 되지만 기가비트로 바로 가기 보다는 차라리 팀(team) 기능을 사용해서 100Mbps 네트워크 두 개를 묶어서 200Mbps를 사용하거나, 한쪽의 LAN 카드가 문제가 있으면 예비용으로 사용할 수 있게 스탠바이로 준비해 두는 것도 좋다. 다만 서버가 제공하는 한도가 초과되면 서버를 증설하면서 로드 밸런싱을 염두해둬야 할 것이다.
지금까지 IIS에 대한 사전 용량 계획을 주제로 이야기했지만 많은 부분을 성능에 대해 언급한 것 같다. 용량 계획과 성능 분석은 실과 바늘의 관계다. 용량 계획을 하기 위해서는 데이터를 추출해야 하고, 그것을 가능하게 하는 것이 성능 분석이기 때문이다. 그렇기 때문에 앞으로도 성능에 대한 부분이 많이 언급될 것이고, 서버 설정 후 테스트 과정에서도 성능 분석에 대해 자세하게 언급할 것이다.

MS SQL의 사전 용량 계획 : CPU와 메모리
MS SQL 뿐만이 아니고 다른 제품의 SQL도 모든 용량 계획은 트랙잭션 처리량에 의존한다. MS SQL 역시 3배 이상의 여유를 갖고 사이징을 잡으라고 권하고 싶다. 마이크로소프트가 40개 이상의 물리적인 디스크를 물리고 초당 1000 트랜잭션을 처리했다는 벤치마크 결과도 있다.
SQL 서버의 CPU 용량을 계획할 때는 IIS에서 알려준 http://servers.digitaldaze.com/compare/spec.html을 권장하고 싶다. 여러 가지 벤치마크에 대한 사항이 있어 도움이 될 것이다. 여기서 중요하게 살펴봐야 할 부분은 정수 처리 성능이다. 정확한 계산이 어렵다면 역시 캐시가 큰 CPU를 선택하고 싱글로 먼저 테스트를 해보는 것이 좋다. 싱글에 부하가 걸린다면 듀얼로 업그레이드를 하면 부족한 부분은 없을 것이다. 물론 선택된 제품의 사양 중 가장 빠른 CPU와 가장 큰 캐시를 선택하는 조건이다.

마이크로소프트 SQL은 생각보다 CPU를 많이 사용한다. 다른 애플리케이션에서는 CPU를 늘려도 큰 차이는 없지만 MS SQL은 CPU 하나만을 추가해도 3배의 용량을 차지한다고 봐도 과장은 아니다. CPU는 많은 연결을 관리하고, 데이터 캐시를 효과적으로 관리하고, 쿼리를 최적화해서 실행하고, 제약조건을 검사하고, 저장 프로시저를 실행시키고 테이블과 인덱스를 잠그는 등 프로세싱 주기를 많이 사용한다. MS SQL 서버의 CPU는 가장 빠른, 가장 큰 캐시를 가진 것을 추천한다.
MS SQL의 메모리 운영 방식의 기본값은 동적이다. 이 말은 MS SQL은 자신이 사용할 메모리의 양을 운영체제와 애플리케이션의 메모리 사용량에 따라서 자동으로 설정하게 된다. MS SQL의 관점에 본다면 RAM에서 불러오는 작업이 가상 메모리에서 불러오는 것보다 수천 배가 빠르다. RAM의 양이 적으면 메모리 공간이 부족하므로 X86 기반의 멀티 프로세스는 FIFO 알고리즘이 적용돼 먼저 들어온 주소의 페이지가 하드디스크의 가상 메모리로 페이지 된다는 것이다.
나간 데이터를 다시 메모리로 불러 들여할 상황이면 그 대기 시간 때문에 병목이 생긴다. 만일 충분한 메모리를 가지고 있다면? 가상 메모리로 갈 일이 없다. 다시 말하면 충분한 메모리의 양은 SQL 서버의 성능을 좌지우지 한다는 것이다. 메모리 역시 일정한 수치값이 없으며, 이것을 얻을려고 하는 것도 무의미하다. 중소 기업이라면 2GB부터 시작할 것을 권장한다.
메모리의 성능은 조정할 수가 있는데, 이 부분은 테스트 후 성능 분석에서 언급하도록 하겠다. 노파심에서 하는 이야기지만 보드에 메모리 뱅크가 몇 개가 있는지 반드시 확인하고, 해당 서버의 최대 메모리 사양과 그에 맞는 MS SQL 제품을 선택하는 것을 잊지말자.
참고로 자신이 개발한 DB가 쿼리 중심이냐 트랙잭션 중심이냐에 따라 메모리의 사용 용도가 달라진다. 쿼리는 컴파일이 되고 캐시(메모리)에 머무르기 때문에 큰 메모리를 갖고 있는 것이 유리하다. 반대로 트랙잭션 중심은 캐시(메모리) 히트율이 떨어지기 때문에 적은 메모리가 유리할 수 있다. 트랜잭션 중심의 성능 향상은 디스크 I/O를 향상시키는 것이 더 좋을 것이다.

MS SQL의 사전 용량 계획 : 디스크 I/O와 네트워크
디스크 I/O는 IIS에서도 언급했지만 용량만을 보고 결정할 사항이 아니다. 더군다나 MS SQL이면 I/O의 속도와 폴트 톨러런스(fault tolerance)를 고려해야 한다. 일반적으로 IIS는 결함 제어를 위해 로드밸런싱을 사용한다. MS SQL은 클러스터를 사용한다. 차이는 데이터의 사용 목적 때문이다.
MS SQL이 한 개의 디스크 드라이브에서 운영할 수 없다는 것은 아니다. 그러나 한 개 보다는 두 개가 좋고, 두 개 보다는 세 개가 좋다는 것이다. 데이터 용량 계산은 기본적으로 독자에게 맡기겠다.

디스크의 개수도 중요하지만 SCSI의 채널도 중요하다. 한 채널에 물리는 드라이브 개수는 5개 이상을 넘기지 않을 것을 권장한다. 물론 한 채널에 물릴 수 있는 드라이브 수는 그 이상이지만, 가장 속도가 느린 자원인 디스크이지만 디스크 용량을 써가면서 낼 수 있는 권장값이다. 아예 큰맘 먹고 한 디스크에 한 파티션씩 할당할 것을 권장한다.
그럼 몇 개의 디스크가 필요할까. 시스템 파티션에는 윈도우 2000을 설치한다. 페이지 파티션은 가상 메모리인 페이징 파일만을 가지고 있다. MS SQL의 시스템 파일과 시스템 DB가 있을 것이다. 그러나 여기서 TEMP DB는 제외를 한다. TEMP DB는 입출력이 많은 DB 이므로 아예 따로 디스크를 하나 할당할 것을 권장한다. 이것도 한 개의 디스크로 가자. 그리고 사용자 DB를 하나의 디스크로 가져간다.
백업을 테이프로 받는다면 상관 없겠지만 디스크로 받겠다면 이것 역시 하나의 디스크로 가져가야 한다. 기본적으로 많이 쓰면 6개다. 결함 허용이 없는 디스크 구성이기 때문에 RAID 레벨을 독자 여러분의 상황에 맞게 구성하면 무척이나 많은 디스크를 가지게 될 것이다. 그래도 성능이 제대로 발휘만 된다면 성공적인 용량 계획이 될 것이다.

네트워크는 사용량이 적을 것이다. 많은 양의 네트워크 트래픽을 보내고 받는 것을 IIS가 처리하기 때문이다. 일반적으로 SQL은 애플리케이션의 뒤에 배치된다. 심지어는 3티어에 배치되는 경우도 있다. 이런 구조덕에 관련된 데이터만을 전송해주면 될 것이고 이것은 IIS까지만 또는 애플리케이션 서버까지만 전송하면 되기 때문에 그렇게 많은 양의 트래픽이 사용되지는 않을 것이다.
다음 시간에는 용량 계획을 위한 테스트에 대해 살펴볼 것이다. 테스트를 위해서는 준비 설정을 해야 할 것이고 WAS(Web Application Stress)라는 툴을 돌려서 모의 실험을 할 것이다. 이 모의 실험을 하고 있는 동안 IIS와 MS SQL에서 성능 분석을 설정해서 로그를 남기고 있을 것이고, MS SQL에서는 쿼리 분석을 위해서 프로파일러(PROFILER)도 실행시켜 놓을 것이다. 이런 자료를 토대로 서버의 사양을 파악하고 적정 기준치 설정을 할 것이며, 이 기준치를 갖고 사후 용량 계획도 잡아볼 것이다.

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

효율적인 서버 관리를 위한 관리자의 행동지침 4가지 

관리해야 하는 서버 수가 많아지면 그것을 혼자서 관리한다는 것은 불가능하다. 마이크로소프트가 제시하는 모든 제품을 구매하지 않는 이상은, 혼자라기 보다는 소수의 인원이 관리를 한다는 것이 맞을 것이다. 소수가 됐던 다수가 됐던 여러명이 팀을 이뤄 서버를 관리하다 보면 혼선을 빚을 때가 많다. 동일한 작업이 같은 시간에 서로 다른 사람에 의해 이뤄지다보면, 나중에 문제가 생겼을 때 서로 책임을 떠넘기게 된다. 아니면 아예 작업 기록이 없어서 해당 작업이 누구에 의해 이뤄졌는지를 아예 모를 때도 있다. 이 같은 문제를 해결하기 위해서는 사전에 어떤 작업이 필요한지 필자의 경험을 통해 살펴보자

하나, 모든 정보에 대한 설명은 필수

(화면) 계정별로 상세하게 설명이 기록돼 있는 화면 

(화면)은 윈도우 서버 2000 뿐만 아니라 윈도우 NT 4.0에서도 유사하게 볼 수 있는 환경이다. 문제는 규모가 큰 시스템을 관리하든 작은 규모의 시스템을 관리하든 관리자다들이 (화면)의 오른쪽에 있는 계정별 설명을 잘 기록하지 않는다는 것이다. 초창기에 업무를 그렇게 처리했다면 계속해서 그럴 것이다. 사실 필자도 처음에는 그랬다. 그럼 그렇게 관리자들이 귀찮아 하는 사항을 굳이 마이크로소프트가 계속해서 사용하게 하는 이유는 무엇일까. 그것은 바로 필요해서이다. 이는 단지 윈도우 서버에만 해당되는 내용이 아니라 다른 운영체제를 비롯해 네트워크 장비, 더 나아가서는 일반 업무에서도 상당히 필요한 부분이다.
혼자서 관리하는 서버라면 굳이 이런 설명이 필요없을 지도 모른다.
하지만 이런 경우를 한번 생각해보자. 여러대의 윈도우 서버 시스템이 있는 회사에서 익스체인지 서버를 담당하던 직원이 그만두게 됐다. 그것도 급작스럽게 그만두게 돼 업무 인수인계가 제대로 되지 못했다. 이런 상황에서 전임자가 계정별 상세 설명을 서버에 기록하지 않았다면 후임자는 계정 파악에만 많은 노력을 들여야 할 것이다. 그러나 설명에 해당 계정의 사용목적이나 관련 정보를 일목 요연하게 적어 놨다면 후임자는 업무에 대해 보다 쉽게 파악할 수가 있다. 자기가 할 업무가 아니니까 신경 안쓴다고? 그러지 말자. 나도 똑같은 경우를 당할 수 있다.

둘, '삽질'이냐 '내공'이냐는 나의 몫
보통 이 바닥에서는 '삽질' 또는 '내공' 등의 단어를 종종 사용한다. 그런데 내공은 저절로 쌓이는 것이 아니다. 영화를 보면 주인공의 부모가 원수의 손에 죽임을 당하고, 주인공은 가까스로 살아나서 힘든 생활과 무술을 열심히 연마한다. 이후 사부님으로부터‘이제 하산하여도 좋다'라는 말을 듣고 밀짚모자를 눌러 쓰고 고향으로 돌아간다. 그리고 바람이 부는 날에 원수를 찾아가서 복수를 한다.
여기서 가장 주목할만한 대목은 바로 '이제 하산하여도 좋다'이다. 난 언제쯤 하산해도 될까. 눈만 뜨고 일어나면 새로운 기술이 쏟아진다. 내가 기술을 배우는 속도보다 새로운 기술의 등장 속도가 더 빠르니 한숨은 절로 나온다. 하지만 뜻이 있는 곳에 길은 아주 많다. 단, 본인이 게을러지지만 않는다면.

셋, 정정당당해지자.
또 한가지 얘기를 하고 싶은 것은 정정당당 하자는 것이다. 잘못은 누구나 할 수가 있다. 그러나 그 잘못을 숨기려고 하는 것이 잘못된 것이다. 예전에 모 사이트에서 ASP의 잘못된 루프로 메모리 누수가 발생해서 웹서버가 죽어나갔다. 루프를 잡아 놓고 전화를 했더니 담당자는 코드를 고친적이 없다고 잡아뗀다. 증거를 들이미니 그때서야 잘못했다고 한다. 또 다른 사례다. 프로그램이 구동이 안돼서 들어가 봤더니 해당 프로그램이 삭제돼 있었다. 누가 그랬을까 하고 찾아 봤더니 개발자였다. 왜 지웠냐고 했더니 그런적이 없다고 펄쩍 뛴다. 로그를 보여줬음에도 불구하고 자기가 아니라고 끝까지 우긴다.
이렇게 뭘 만져 놓고 잘못 수정을 했음에도 불구하고 모른다고 발뺌하는 나몰라라 형은 다른 사람을 더 많이 고생시키게 된다. 작업을 하면서 크고 작은 실수는 누구나 하게 마련이다. 그러나 그것을 덮을려고 하지 말고 빨리 실토하고 해결책을 찾는 것이 좋다. 

넷, 문서화
문서화 작업은 정말 아무것도 아닌 것 같지만 귀찮고 힘든 작업이다. 그러나 이 문서가 얼마나 업무에 도움이 되는지는 만들어 놓고 보면 안다. 시스템을 운영하다 보면 계정, 보안과 관련된 사항뿐만이 아니라 IIS, MS SQL, 익스체인지 등에 대해 자기만의 구축 방법과 마이크로소프트에서 제시한 값이 있을 것이다. 이런 것들에 대해 될 수 있으면 전 부분에 대해 문서화를 해 놓고 그 값에 맞추는 방식을 채택하자. 그럴 경우 다른 사람과의 공동 작업에서도 이미 정책이 결정된 사항이기 때문에 혼선이 일어날 일이 없다. 예를 FTP 설정 사항에 대해 다음과 같이 정리할 수 있을 것이다. 

추천 설정 사항 : 익명의 FTP 로그온 허용하지 않음
현재 설정 사항 : 익명의 FTP 로그온 허용

단적인 예를 들긴 했지만 서버에는 설정할 사항들이 무수히 많다. 레지스트리, 폴더의 ACL 권한 등은 추천 설정 사항으로 아주 모범적인 사항을 만들어 놓고, 어디에서나 그 환경에 맞게 설정만 하면 된다. 추천 설정 사항에 대한 정보는 마이크로소프트나 정보보호진흥원 등의 보안 관련 사이트를 뒤지면 된다.

출처 : on the NET

대부분의 IT 전문가들은 RAID의 기본 기능에 대해 잘 알고 있다. 최근에는 향상된 디스크 I/O 성능과 데이터 보호를 위해 일부 운영체제에서는 RAID 0(단순 스트라이핑),  RAID 1(미러링)과 같은 RAID의 기능들을 기본적으로 제공하고 있다. 심지어 패리티를 통한 데이터 복구 기능을 제공하는 RAID 4 혹은 RAID 5도 사용자들에게 익숙한 방식이 되고 있다.
그러나 아직까지도 '온라인 용량 확장'이나 '온라인 RAID 레벨 변경'과 같은 엔터프라이즈 급의 RAID 기능은 사용자에게 잘 알려지지 않았다. 하지만 최근들어 몇몇 하이엔드 RAID만으로 제한됐던 기능들이 SATA 스토리지 기술을 기반으로 점점 더 폭넓게 적용되고 있다. 이들 기능들에 대해 하나씩 살펴보도록 하겠다.

중단없는 확장을 위한 시스템 운영 중 교체, OCE, ORLM
다수의 향상된 RAID 기능들은 일반적으로 다른 기능들과 함께 사용되곤 한다. 예를 들어 시스템 운영 중 교체, 온라인 용량 확장(Online Capacity Expansion, OCE), 온라인 RAID 레벨 변경(Online RAID Level Migration, ORLM) 등의 기능과 함께 사용될 경우 서비스를 중지하지 않고도 스토리지 시스템의 주요 변경 사항을 적용할 수 있다.
시스템 운영 중 교체 기능은 물리적으로 디스크가 추가되거나 혹은 제거되도록 지원하며, 온라인 용량 확장 기능은 새롭게 추가된 디스크를 이용해 데이터 어레이가 확장되도록 지원한다. 온라인 RAID 레벨 변경 기능은 시스템 운영 중 새로운 RAID 형태로 RAID 어레이를 변경해준다.
시스템 운영 중에 중단없이 스토리지 시스템을 변경할 수 있는 이런 기능들은 변경 작업이 빈번한 조직에 매우 유용하다. 예를 들어 트랜잭션 처리(Transaction Processing)를 주 업무로 하는 작은 규모의 빠르게 성장하는 조직을 예를 들어보자. 이 경우, 일반적으로 중요한 데이터를 단순하게 2개의 디스크에 걸쳐 데이터를 미러링하는 RAID 1으로 데이터를 보호할 수 있다. 예산이 빠듯한 상황에서 비즈니스 규모는 더욱 커지고 트랜잭션의 수준이 증가함에 따라 디스크의 용량을 증설할 필요가 발생한다. 이때 패리티를 이용한 데이터 복구 방식인 RAID 4 혹은 RAID 5는 단지 3번째 디스크 하나만을 추가함으로써 기존 용량의 두 배를 제공할 수 있기 때문에 좋은 선택이 될 수 있다. 그러나 TP 서버는 어느 시점에서라도 절대로 오프라인이 되면 안되는 서비스다. 따라서 반드시 시스템 운영 중 교체, 온라인 용량 확장, 온라인 RAID 레벨 변경 등의 기능이 필요하다.

앞의 설명이 마음에 와 닿지 않는 독자들을 위해 일화 하나를 소개해 보고자 한다. 몇 년 전 추석 연휴 즈음, 한 고객이 중요한 데이터 보관을 위해 엔터프라이즈급의 스토리지 시스템을 RAID 1으로 구매했다. 구매 당시에는 데이터 보호 측면에서 RAID 1의 구성을 고려한 듯 했다. 논리적으로 사용할 수 있는 스토리지 공간은 구매한 스토리지 용량의 절반 수준이었지만 예상과 달리 데이터 증가가 빨라 곧 저장 공간이 부족한 상태에 도달했다. 그 고객이 내린 결정은 RAID 1을 공간 사용율이 높은 패리티 기반의 RAID로 변경하는 것이었다. 하지만 스토리지 시스템의 모든 데이터를 테이프를 이용해 백업받고(약 15시간 소요), 스토리지 시스템의 RAID를 변경해 다시 포맷하고(약 7시간 소요), 그리고 다시 데이터를 복구하고(약 10시간 이상 소요), 마지막으로 데이터를 확인하기까지 (약 2시간 소요) 작업 시간만 거의 이틀 정도가 필요했다. 결국 추석날 아침 간단하게 차례 지내는 시간만 제외하고는 모든 연휴 기간을 차가운 바람이 나오는 전산실에서 보내야만 했다.
만일 그 당시에 온라인 용량 증설이 가능했다면, RAID 레벨 변경 대신에 온라인 용량 확장을 선택했을 것이고, 그것이 불가능했다면 차선책으로 RAID 레벨 변경을 통한 저장 공간을 확보해 효율적으로 일을 진행했을 것이다.

RAID 기법 중에서는 RAID 4가 온라인 용량 확장을 지원하고 있다. (그림 1)에서 보는 것처럼 기존 데이터와 패리티로 구성돼 있는 RAID 그룹에 단순하게 모든 비트를 '0'으로 지정해, 기존 RAID 그룹에 온라인 중 추가하더라도 기존 데이터에는 전혀 영향을 미치지 않는다. 이는 하나 뿐만이 아니라 다수의 디스크를 추가하더라도 마찬가지다. 하나의 디스크의 온라인 용량 확장은 물론, 지금도 RAID 레벨을 온라인 중에 변경하는 것을 지원하는 스토리지는 현재 업계에 그리 많지 않다.

지난 기고에서도 언급했지만, 최근에는 대용량의 SATA 디스크 드라이브의 출시가 줄을 잇고 있다. 현재 단일 디스크로 500GB까지 출시됐다. 이런 대용량의 SATA 디스크로 RAID를 구성해 데이터를 저장할 때, 디스크의 손상이 발생할 수 있다. 이럴 경우 패리티에 의한 데이터 복구가 진행되는데, 소요 시간은 기존 작은 크기의 디스크를 구성할 경우보다 더 많은 시간이 소요된다. 또한 데이터 복구가 진행되는 동안 같은 RAID 그룹 내에 있는 또 다른 디스크의 장애가 발생하면 모든 데이터는 손실된다. 이 경우를 대비해 최근에는 패리티를 이중으로 구성하는 RAID DP 혹은 RAID 6가 출시됐다. 그래서 두 개의 디스크가 동시에 장애가 발생하더라도 데이터를 안전하게 보호할 수 있도록 지원한다.

하지만 이런 경우를 고려해보자. 초기에는 데이터의 중요도나 디스크의 손실률을 고려해 패리티를 이용한 방식의 RAID를 구성했으나, 그 데이터의 성격이 기업의 비즈니스 변화에 의해 더욱 중요한 데이터가 되고, 그 데이터를 보다 강하게 보호할 수 있는 RAID를 고려한다면 이중 패리티를 생각하게 될 것이다. 이 경우 온라인 중에 사용하던 RAID 그룹에 단순하게 하나의 디스크만을 추가해 RAID DP로 이중의 패리티를 구성할 수 있다면, 서비스의 지속성을 보장하면서 데이터를 더욱 신뢰성 있게 구성할 수 있을 것이다. 그러나 만일 단순 패리티로 구성됐던 RAID를 RAID 6로 변경하기 위해서는 앞서 언급한 대로 몇 시간의 데이터 백업, 하드 디스크 포맷, 데이터 리스토어 같은 시간을 소비하는 작업을 진행해야 할 것이다. 다시 한번 민족 최대의 명절을 차가운 전산실에서 보내야 하는 신세가 됨으로, ORLM의 중요성이 절로 생각날 것이다.

데이터 보호를 위한 N-웨이 미러링, 스플리팅, 하이딩 기능
다른 기능들과 함께 사용될 때 더욱 큰 힘을 발휘하는 기능들이 있다. 이 기능들은 악의적인 사용자, 우연한 사고에 의한 데이터 삭제 혹은 바이러스로부터 유발되는 시스템에 대한 위협으로부터 데이터를 보호할 수 있다. 이런 데이터 보호 기능들에는 N-웨이 미러링, 어레이 스플리팅(array splitting), 어레리 하이딩(array hiding) 등이 있다.
N-웨이 미러링은 단순한 2-웨이 미러링을 넘어 추가적인 데이터 세트의 생성을 지원한다. 어레이 스플리팅은 미러 중의 하나를 사용 중인 어레이에서 제거할 수 있도록 한다. 그리고 어레리 하이딩은 권한을 가진 관리자에게만 접근이 가능하도록 하고 사용자에게는 접근이 불가능하도록 지정해 데이터를 보호할 수 있다.
이런 기능들이 동시에 사용될 경우 시스템 관리자는 사용 중인 데이터 어레이의 안전한 백업을 생성할 수 있다. 일단 시스템 관리자는 N-웨이 미러링을 이용해  3-웨이 미러를 생성한다. 다음 어레이 스플리팅을 이용해 사용 중인 어레이로부터 미러 중에 하나를 제거한다(사용 중인 어레이는 미러 중에 하나가 제거된 이후에도 2-웨이 미러를 통해 데이터의 정합성을 유지할 수 있다). 마지막으로 스플릿(split) 미러를 숨김으로써, 다른 사용자나 운영 시스템이 그 데이터를 볼 수 없도록 한다. 데이터를 직접 볼 수 없기 때문에 데이터에 대한 삭제 위협으로부터 보호할 수 있다.
만일 사용 중인 어레이에 재해가 발생한다면 복구 방안은 매우 단순하다. 관리자는 손상된 어레이에 있는 손상된 데이터를 삭제하고, 감춰진 어레이를 드러나게 해 ORLM을 이용, 상태가 양호한 미러에 포함시키면 된다. 새롭게 투입된 데이터는 감춰지기 전까지만 데이터가 일치하기 때문에 그 시점 이후에 변경된 데이터는 반영되지 않았다는 것을 알아야 한다.

그외 유용한 기능들
·드라이브 로밍 기능
시스템 운영 중 교체 기능과 더불어 드라이브 로밍 기능은 RAID 컨트롤러에 연결돼 있던 드라이브들을 지속적으로 확인할 필요가 없기 때문에 시스템 간에 디스크 이동을 더욱 수월하게 한다. 드라이브 로밍 기능을 이용하면 시스템은 사용자를 위해 지속적으로 그 정보를 유지한다. 이것은 애플리케이션의 관점에서는 시스템 간에 대용량의 데이터를 빠르게 이동시켜야 할 경우에 매우 유용하다. 이런 애플리케이션에서는 네트워크를 통한 데이터 복제에 비해 매우 빠르게 드라이브를 이동시킬 수 있다. 

·컨트롤러 스패닝 기능
컨트롤러 스패닝은 디스크들이 다수의 RAID 컨트롤러에 연결되도록 해주는 기능이다. 그렇게 함으로써 대용량의 어레이를 구성할 수 있도록 하며 높은 처리량을 제공할 수 있다. 예를 들어, 4개의 RAID 컨트롤러를 보유하고 있고 각각의 컨트롤러는 8개의 디스크 드라이브가 연결돼 있다고 가정할 때, 컨트롤러 스패닝은 모두 32개의 디스크 드라이브까지 확장 가능한 어레이를 생성할 수 있다. 또한 성능이 선형적으로 증가하기 때문에 단일 어레이에서 32개의 디스크를 동시에 운영할 수 있는 매우 높은 수준의 I/O 전송 성능을 지원한다.

·분산 스패어링 기능
분산 스패어링은 별도의 디스크 드라이브를 사용하지 않고 스패어 페일오버 드라이브를 생성하는 기법이다. 본질적으로 분산 스패어링은 충분한 디스크 공간을 선점하기 때문에 선점된 공간의 합은 어레이에서 대용량의 드라이브와 동일하다. 글로벌 혹은 전용 스패어링과 비교해 이 기능의 중요한 장점은 모든 드라이브가 사용 가능하며, 결과적으로 뛰어난 성능을 제공하게 된다는 것이다.

지금까지 3회에 걸쳐 RAID에 대한 전반적인 설명을 진행했다. RAID의 역사, 정의, 각각의 특징, 장단점, 애플리케이션별로 알맞은 RAID 타입 그리고 이번에 정리한 새로운 기능들까지 알아봤다. IT 업계 종사자라면 한번쯤은 다루는 내용인데도 그냥 쉽게 넘겼던 개념에 대한 정리였다. 이번 기회를 통해 이미 알고 있던 내용이지만 새로 소개된 기능들과 함께 다시 한번 잘 정리하기를 바란다.

출처 : on the NET

각 RAID별 구성 상의 특징을 알아보고 권장 애플리케이션 환경을 살펴보도록 하겠다. 물론, 여기서 설명할 내용들이 모두 완벽히 적용될 수 있는 것은 아니다. 실제로 사용자가 스토리지 시스템을 선정해 구축하기 위해서는 RAID 뿐만 아니라 사용하고자 하는 애플리케이션의 I/O 성격, 필요한 데이터 용량, 가격, 시스템 아키텍처, 마이크로 코드 등의 다양한 스토리지 시스템 요소들을 고려해야 한다. 단지 본 기고를 통해 향후 독자들이 RAID에 의한 스토리지 시스템을 선정하는데 있어 조금이나마 도움이 되기를 바란다. 

별도의 데이터 백업을 고려해야하는 RAID 0

RAID 0는 데이터를 블럭으로 나눠 다수의 디스크 드라이브에 저장하는 방식을 취한다. 따라서 I/O 로드를 다수의 채널과 드라이브에 분산시킴으로써, 성능을 급격하게 향상시킬 수 있다. 가장 좋은 성능을 내기 위해서는 하나의 디스크 드라이브만을 스토리지 컨트롤러에 할당하며, 다수의 컨트롤러에 데이터를 분산시킨다. 또한 RAID 0는 별도의 패리티를 생성하지 않기 때문에 패리티 생성을 위한 오버헤드를 줄일 수 있으며, 단순한 디자인으로 구성할 수 있어 수월하다.

하지만 RAID 0는 내고장성을 제공하지 못하는 치명적인 약점이 있기 때문에 ‘진정한’ RAID라 볼 수 없다. 즉, 이는 하나의 디스크 드라이브가 손상된다면 스토리지에 저장된 모든 데이터가 손실될 수 있다는 것을 의미하기 때문에 중요 업무 환경에서 사용돼서는 안된다.

업계에서는 거의 RAID 0를 사용하고 있지 않으며, 넷앱에서 제공하는 V-시리즈의 경우, HDS, IBM, HP, SUN/STK 등의 스토리지를 외장 스토리지로 사용하기 때문에 스토리지 제공업체에서 제공하는 RAID 기법을 그대로 이용할 수 있도록 단순 스트라이핑의 RAID 0 기법을 제공하고 있다. 또 다른 스토리지 공급업체에서는 내부 복제솔루션을 이용한 타깃 볼륨의 구성을 RAID 0로 구성하기를 권장한 적도 있다. 그러나 이 경우, 타깃 볼륨의 RAID를 구성하는 디스크 드라이브의 손상 시 원본 볼륨에서 다시 한번 데이터를 복사(full copy)해야 하는 부담을 준다.

RAID 0를 이용해 구성하는데 권장되고 있는 애플리케이션은 다음과 같다. 단, RAID 0의 경우 앞에서 언급한대로 디스크 드라이브의 손상 시 완벽한 데이터의 보호 기능을 제공하지 못하기 때문에 반드시 별도의 데이터 백업을 동시에 고려해야 한다.

- 비디오 제작과 편집 작업

- 이미지 편집

- 전자 출판 애플리케이션 중 인쇄전과정을 위한 애플리케이션

- 높은 대역폭을 필요로 하는 애플리케이션

금융 서비스에 용이한 RAID 1

RAID 1의 경우는 미러링된 영역을 단일 쓰기 업무와 이중 읽기 업무에 사용할 수 있다. 읽기 업무의 경우 단일 디스크때 보다 2배의 트랜잭션 성능을 제공하며, 쓰기 업무의 경우 같은 성능을 지원한다. 단일 디스크 손상에 비해 100%의 데이터 가용성을 보장하기 때문에 별도의 재설치 작업이 필요하지 않으며, 단지 대체 디스크에 데이터를 복제하는 작업만이 필요하다. 블럭당 전송률은 단일 디스크때와 동일하며, 특정 환경에서 RAID 1은 동시에 다수 디스크 드라이브의 손상에서도 데이터 전송을 지원할 수 있다.

이런 다양한 장점에도 불구하고 RAID 1은 용량 측면에서 RAID 구성 상 가장 높은 오버헤드를 발생시켜 비효율적이다. 일반적으로 RAID 기능은 시스템 소프트웨어에 의해 수행되기 때문에 많은 I/O가 발생할 경우에 CPU/서버 처리량의 저하 현상이 발생할 수 있다. 그래서 하드웨어적인 RAID 구현이 바람직하다. 대부분의 스토리지 제공업체는 하드웨어 혹은 소프트웨어 방식으로 RAID 1(미러링)을 지원하고 있다.

- 회계

- 급여

- 금융 서비스

- 높은 가용성을 필요로 하는 애플리케이션

아직 상용화되지 않은 RAID 2

RAID 2는 시스템 작동 중 데이터 에러 수정이 가능하며, 매우 높은 데이터 전송을 지원할 수 있다. 또한 RAID 2는 RAID 3, 4, 5에 비해 상대적으로 단순한 컨트롤러 디자인이 특징이다.

반면, 매우 작은 데이터 사이즈의 데이터 전송 시 많은 패리티 디스크를 필요로 하기 때문에 비효율적이며 초기 도입 비용도 높은 편이다. 처리량은 가장 최고일 경우에도 단일 디스크 드라이브와 동일할 수 밖에 없다. 가장 큰 약점은 현재 상업적으로 RAID 2를 구현한 사례가 없으며, 앞으로도 그럴 것으로 예상된다. 따라서 RAID 2에 권장되는 애플리케이션은 구체적으로 명시하지 않는다.

다소 복잡한 디자인으로 구성되는 RAID 3

RAID 3는 높은 읽기와 쓰기 데이터 전송을 지원하며, 디스크 손상이 전체 데이터 처리에 심각한 영향을 미치지도 않는다. 그리고 하나의 패리티 디스크로 많은 수의 데이터 디스크를 지원할 수 있기 때문에 높은 효율성을 제공한다.

그러나 처리량은 가장 최고일 경우에도 단일 디스크 드라이브와 동일할 수 밖에 없다. 또한 컨트롤러 디자인도 다소 복잡한 편이며, 소프트웨어 방식으로 RAID를 구성할 경우 매우 어렵고 많은 자원이 필요하다. 따라서 업계에서는 몇몇 스토리지 공급업체에서 RAID 3를 지원하고 있으나, 거의 사용되지 않고 있는 것이 현실이다.

- 비디오 제작과 라이브 스트리밍

- 이미지 편집

- 비디오 편집

- 전자 출판 애플리케이션 중 인쇄전과정을 위한 애플리케이션

- 높은 처리량을 필요로 하는 애플리케이션

온라인 서비스에 적합한 RAID 4

RAID 4는 매우 높은 읽기 데이터 전송률을 지원한다. 하나의 패리티 디스크로 많은 수의 데이터 디스크를 지원할 수 있기 때문에 높은 효율성을 제공하며, 전체 전송률도 높은 수준이다. 반면, 컨트롤러 디자인은 다소 복잡한 편이며, 쓰기 업무에는 성능 저하가 발생할 수 있다. 그리고 디스크 손상 시 데이터 재설치 작업이 어렵고 비효율적이다. 블럭 읽기 전송률은 단일 디스크의 전송률과 동일하다.

또한 RAID 4의 경우, 온라인 중에 용량을 증설할 수 있기 때문에 주로 닷컴, 병원과 커뮤니티 서비스 등 온라인을 통한 서비스를 주 애플리케이션으로 사용하는 환경에 알맞다. 현재 RAID 4는 이런 온라인 중에 용량을 확장할 수 있는 장점을 내세워서 NAS 시장에서 좋은 반응을 얻고 있다. 더불어 RAID 4 기반의 RAID-DP(Dual Parity)도 제공하고 있다.

- 비디오 제작과 라이브 스트리밍

- 이미지 편집

- 비디오 편집

- 전자 출판 애플리케이션 중 인쇄전과정을 위한 애플리케이션

- 닷컴, 병원 등의 온라인 애플리케이션 서비스

활용도 높은 RAID 5

일반적으로 RAID 5는 높은 읽기 데이터 전송률과 중간 정도의 쓰기 데이터 처리를 지원한다. RAID 4처럼, 하나의 패리티 디스크로 많은 수의 데이터 디스크를 지원할 수 있기 때문에 높은 효율성을 제공하며, 전체 전송률도 높은 편이다. 그러나 디스크 손상 시 전체 데이터 처리에 대해 어느 정도 영향을 받으며, 매우 복잡한 컨트롤러 디자인을 가지고 있는 것이 단점이라고 할 수 있다.

또한 RAID 1과 비교해 디스크 손상 시, 디스크 재설치 작업이 상당히 어렵다. 일반적으로 단일 디스크에 블럭 데이터 전송률과 거의 같은 수준으로 각각의 디스크에 데이터를 전송한다. 현재 거의 대부분의 스토리지 공급업체에서 RAID 5를 지원하고 있다.

- 파일과 애플리케이션 서버

- 데이터베이스 서버

- 웹, 전자우편, 뉴스 서버

- 인트라넷 서버

- 대부분의 애플리케이션에 대해 적용 가능

높은 가용성 지원하는 RAID 6

RAID 6는 근본적으로는 두 번째 독립 분산 패리티를 이용해 추가적인 내고장성을 가능하게 한 RAID 5의 확장판이라고 할 수 있다. RAID 5처럼, 데이터는 드라이브에 걸쳐 블럭 레벨로 분산돼 저장되고, 두 번째 패러티가 모든 드라이브에 걸쳐 계산되고 저장된다. 

RAID 6는 매우 높은 데이터 가용성을 제공할 수 있으며, 동시에 다수의 드라이브가 손상되더라고 지속적인 서비스를 제공할 수 있기 때문에 기업의 중요한 애플리케이션에 알맞은 솔루션이다.

반면, RAID 6는 컨트롤러 디자인이 매우 복잡하며, 패리티 주소들을 계산하기 위한 컨트롤러 오버헤드가 매우 높다. 또한 쓰기 업무 시에 성능에 영향을 받을 수 있으며, 이중 패리티를 생성하기 위해 반드시 N+2의 디스크 드라이브가 필요하다.

최근 HDS에서 발표한 제품들이 RAID 6를 지원하고 있다. RAID 6는 RAID 5를 기반으로 하고 있으며, 쓰기 업무의 경우 최악의 경우 RAID 5에 비해 약 33%의 성능 저하가 발생할 수도 있는 것으로 알려지고 있다.

- 파일과 애플리케이션 서버

- 데이터베이스 서버

- 웹, 전자우편 서버

- 인트라넷 서버

- 적은 오버헤드로 높은 가용성을 필요로 하는 기업 애플리케이션

출처 : on the NET

본론에 앞서 필자가 겪은 재미있는 에피소드를 잠깐 소개하고자 한다. 1997년, 당시에는 PC 통신의 한계를 넘어 인터넷이 거의 모든 PC 사용자들에게 새로운 대세로 전환되던 때였다. 이에 발빠른 한 방송국에서는 문제를 출제하고, 그 답을 인터넷 검색을 통해 빨리 맞추는 팀이 승리하게 되는 '인터넷 정보사냥'이라는 프로그램을 진행했다.
필자는 그 프로그램에 ITist(정보처리 기술 전문가라는 의미)라는 팀으로 회사 동료와 함께 출연한 적이 있다. 출제된 스피드 퀴즈 중에 '복수개의 자원을 이용해 데이터의 입출력시 장애가 발생하더라도 데이터의 손실을 없애 주는 저장 방식 혹은 장치를 뜻하는 것은 무엇인가'라는 문제가 있었다. 필자는 자신있게 벨을 누르고 대답했다. "디스크?", "땡, 아닙니다." 옆 팀에서는 "테이프?", "땡, 역시 아닙니다. 정답은 RAID입니다." 그때 필자는 "맞다! RAID지"하고 뒤늦은 후회를 했고, 결과적으로 그 문제 때문은 아니지만 필자팀은 예선에서 탈락하고 말았다.
필자는 이 글을 읽는 독자들이 나중에 RAID라는 개념 때문에 필자 본인처럼 혹시 겪을지도 모를 불이익(?)을 사전에 예방할 수 있길 바라며 본 기고를 시작한다. 본 기고는 3회에 걸쳐 RAID 전반에 걸쳐서 다룰 것이다. 다만 세월이 흐른 뒤 새로운 기술 개발에 의해 본 기고 내용이 '640KB이면 모든 사람에게 충분한 메모리 용량'이라는 1981년 빌 게이츠의 예언처럼, 후에 의미없는 것으로 평가되지 않길 바랄 뿐이다.

비용절감이냐, 데이터 보호냐
일반적으로 RAID의 개념을 최초로 소개한 사람으로 1988년 'A Case for Redundant Arrays of Inexpensive Disks(RAID)'라는 논문을 발표한 데이비드 패터슨(David Patterson)과 가쓰 깁슨(Garth Gibson), 랜디 캐츠(Randy Katz)로 알고 있지만, 사실 IBM에서 근무했던 노먼 켄 오치(Norman Ken Ouchi)다.
노먼 켄 오치는 1978년 'System for recovering data stored in failed memory unit(손상된 메모리에 저장된 데이터를 복구하기 위한 시스템)'으로 미국 특허를 받았다. 이 특허에서는 풀 스트라이프 쓰기(Full Stripe Write)로 정의되는 RAID 5와 RAID 1이라는 용어로 확립된 디스크 미러링 혹은 듀플렉싱 뿐만 아니라 RAID 4로 정의된 전용 패리티를 이용한 보호에 관해서도 언급했다.
이처럼 RAID는 약 30년 전으로 거슬러 올라가게 된다. 여기서 눈여겨볼 사항은 RAID의 목적에 대해 서로 다른 접근 방식을 가지고 있었다는 것이다. 즉, RAID라는 개념을 노먼 켄 Ouchi는 저장된 데이터 보호와 복구라는 측면에서, 나머지 3명의 박사들은 저렴한 전산 자원을 이용해 고성능의 저장 장치를 대체할 수 있는 방안으로 생각했다는 점에서 약간의 차이가 있었던 것을 알 수 있다.

서로 다른 방식으로 리던던시 제공하는 RAID
1988년 'A Case for RAID'에서 언급했던 RAID 종류에 대해 설명하고자 한다. 한 가지 유념할 것은 RAID 레벨의 숫자가 RAID의 성능을 의미하는 것은 절대 아니라는 것이다.

·RAID 0 : 스트라이핑
가장 쉽게 기억하는 방법은 RAID 0은 리던던시를 제공하지 못한다는 것이다. 디스크를 스트라이핑해서 성능을 향상시킬 수 있을지는 모르지만 단순 스트라이핑만 구성할 경우, 스트라이프로 구성돼 있는 디스크 중 어느 하나만 손실되더라도 모든 스트라이프는 손상되기 때문에 가용성을 보장하지 못한다. 즉, 데이터를 잃어버리게 된다. 몇몇 RAID 기관이나 관련 전문지 기고에서 RAID 0를 RAID의 기본 목적인 리던던시를 제공하지 못하기 때문에 RAID로 인정하지 않는 경우도 있다. 영화 '죽은 시인의 사회'에서 키팅선생(캡틴)이 시가 적힌 교과서를 찢는 것처럼 RAID 0는 잊어도 좋다.

·RAID 1 : 미러링
디스크에 있는 모든 데이터는 정확하게 다른 디스크에 복사된다. 저장 작업이 완료됐을 시점에는 두 개의 디스크에 완벽하게 데이터가 저장된다. 만일 하나의 디스크가 손상될 경우 파트너 디스크는 아무런 시스템 개입없이 계속 운영된다. RAID 1의 장점은 관리하기 매우 수월하고, 정상 운영 혹은 복구시 CPU 자원을 많이 사용하지 않는다는 것이다. 반면에 RAID 1의 단점은 가격이다. 정확하게 보호하고자 하는 디스크 용량의 2배가 필요하다.

·RAID 2 : 해밍 ECCcode error
RAID 2는 ECC(Error code correction) 메모리가 사용하는 디스크 데이터 검증 방식인 해밍 인코딩 방식을 사용한다. 현재까지 RAID 2를 적용한 상용 제품을 보거나 들은 적은 없다.

·RAID 3 : 가상 디스크 블록
RAID 3, RAID 4, RAID 5은 같은 방식에서 출발했다. 즉, 패리티에 기반을 둔 RAID라는 것이다. RAID 1처럼 모든 데이터의 복제본을 유지하는 것이 아니라 패리티 기반의 RAID는 하나의 디스크를 추가해, 데이터를 여러 디스크에 걸쳐서 저장하는 것이다. 추가된 디스크에는 다른 디스크에 저장된 데이터를 기반으로 해 XOR로 연산된 데이터 값을 저장한다. 만일 어느 디스크에 있는 데이터가 손상되면 그 값은 남아 있는 디스크들의 데이터를 가지고 복구할 수 있다. 이 방식은 RAID 1 방식이 100%의 디스크를 더 필요로 하는 것에 비해 훨씬 저렴하다. 그러나 디스크에 있는 데이터를 연산해야 하기 때문에 데이터를 저장하거나 디스크가 손상된 후 데이터 복구가 필요할 경우에 성능에 영향을 받는다. 상용화된 대부분의 패리티 기반 RAID는 이런 성능 상의 문제를 해결하기 위해 캐시 메모리를 사용하고 있다. 
RAID 3에서는 모든 쓰기 작업은 RAID 어레이의 모든 디스크(대분분 4개 이상)에 걸쳐 스크라이프돼 저장된다. 모든 쓰기 작업은 모든 디스크에서 수행되기 대문에 어레이의 입장에서는 한 순간에 단지 하나의 데이터 블록만 저장할 수 있으므로, RAID로 인해 성능 저하가 발생할 수 있다. RAID 3의 성능은 쓰기 작업에 따라 달라질 수 있다. 작은 크기의 쓰기 작업은 성능 저하가 많이 발생할 수 있으며, 대용량의 순차 쓰기 작업은 더 나은 성능을 보여준다.

·RAID 4 : 전용 패리티 디스크
RAID 4는 다수의 데이터 디스크와 데이터 디스크로부터 생성된 패리티를 관리하는 전용 디스크로 구성된다. 패리티가 전용 디스크에만 저장되기 때문에 데이터용 디스크의 용량이 부족할 경우에, 새로운 데이터 디스크의 블록을 모두 '0'으로 지정하면, 사용하던 어레이의 RAID 셋에 상관없이 용량을 사용 중에도 확장할 수 있다. 그러나 모든 쓰기 작업은 반드시 패리티 디스크를 통해 수행되기 때문에 이 디스크가 전체 어레이의 쓰기 작업에 영향을 미치는 성능 상의 병목 지점이 될 수 있는 단점이 있다.

·RAID 5 : 스트라이프 패리티
RAID 5는 RAID 4 방식에서 패리티가 하나의 전용 디스크에 저장되는 것이 아니라, 어레이에 있는 모든 디스크에 분산돼 저장된다는 점만 빼고 동일하다고 할 수 있다. 패리티를 각각의 데이터 디스크에 분산시킴으로써 RAID 4에서 단점이라고 했던 패리티 디스크의 병목 현상을 줄일 수 있다. 그러나 RAID 5를 소프트웨어적으로 구현할 때 만일 디스크 작업에 15% 이상의 쓰기 작업이 발생할 경우, 성능은 급격히 저하될 수 있다.
최근에 출시되고 있는 하드디스크는 점점 대용량화되고 있다. 이것은 사용자의 데이터가 예전의 단순한 데이터베이스에서 멀티미디어, 이미지, 아카이빙 등의 대용량 데이터화되고 있는 추세에 발맞추기 위함이다. 또한 최근에는 데이터의 가치에 알맞도록 저장 장치의 위치를 다르게 할 수 있는 ILM(Information Lifecycle Management)도 사용자의 큰 관심사 중에 하나다.
이런 사용자의 요구 사항을 충족시키기 위해 업계에서는 비싼 광 채널 기반의 하드디스크보다는 대용량을 지원할 수 있는 SATA(Serial ATA) 하드디스크를 앞다퉈 출시하고 있다. SATA 디스크의 경우 단일 디스크로 250GB, 320GB 혹은 500GB까지 지원하고 있다. 하지만 대용량 디스크를 이용해 RAID를 구성할 경우, 저용량 디스크보다 물리적인 손상이 발생할 확률이 높아진다. RAID를 구성해 리던던시를 제공한다고 하더라도 물리적으로 하나의 디스크가 손상돼 재설치하는 중에, 그 RAID 그룹 안에 있는 또 다른 디스크가 물리적으로 손상될 확률 역시 높아지는 것이다. 동시에 2개의 디스크가 손상될 경우(글로벌 핫 스페어가 없고, 별도의 백업 정책을 수립하지 않았을 경우), 그 RAID 그룹 안에 저장된 모든 데이터는 불행히도 복구할 수 없다. 그래서 업계에서는 2개의 디스크에 동시에 장애가 발생하더라도, 데이터를 보호할 수 있는 이중 패리티(Dual Parity)를 지원하는 RAID를 출시하고 있다.

·RAID 6 : 이중 패리티
RAID 6는 RAID 5의 분산 패리티를 채용하고 있으며, 그 패리티를 이중으로 하고 있다. RAID 6에 있는 모든 디스크는 두개의 패리티 영역이 있으며, 각각 독립적으로 연산된다. RAID 6의 장점은 만일 2개의 디스크에 동시에 장애가 발생하더라도, RAID는 모든 데이터를 저장해 서비스를 제공할 수 있으며 복구할 수 있다는 것이다. 가장 큰 단점은 성능 저하가 발생한다는 것이다. RAID 5에 비해 거의 2배 정도의 저하가 발생한다고 볼 수 있는데, 이것은 2개의 패리티가 독립적으로 생성되기 때문이다. 또한 RAID 5에 비해 2개의 패리티를 저장해야 하기 때문에 하나의 디스크가 더 필요하며, 이는 추가적인 비용 부담을 의미한다.

·이중 RAID(RAID 10, RAID 0+1)
RAID에 대한 변형이라고 할 수 있는 이중 RAID 방식도 상당히 업계에서 많이 사용되고 있다. RAID 10의 경우는 RAID 0와 RAID 1을 혼합해 적용한 방식으로 RAID 1처럼 미러링을 실시한 후 그 데이터를 다시 스트라이핑하는 기법이다. 이에 반해 RAID 0+1은 RAID 0와 RAID 1을 혼합한 것은 동일하지만, 먼저 데이터를 스트라이핑 한후, 그 데이터를 미러링하는 방식을 취한다. 두 RAID 방식 모두 서로 간의 약점을 보완할 수 있는 방식을 채택하고 있다.

다양한 RAID 구현 방식
RAID 구현 방식은 전용 하드웨어에서 구현되는 하드웨어 방식과 일반 하드웨어에서 특정 소프트웨어를 이용해 구현하는 소프트웨어 방식이 있다. 또한 하드웨어 방식과 소프트웨어 방식을 함께 사용하는 하이브리드 RAID 방식도 있다. 다음에 설명할 방식은 현재 출시돼 있는 스토리지 시스템의 아키텍처나 다른 구성들을 고려하지 않은 순수한 RAID에 대한 설명이라는 것을 미리 밝혀둔다.

먼저 소프트웨어 방식에는 일반적인 드라이브 컨트롤러(IDE/ATA, SCSI, 혹은 파이버 채널)를 통해 운영체제가 디스크 어레이를 관리한다. 현재 CPU의 처리 속도를 고려해, 다른 작업에 사용돼야 할 CPU 자원을 사용해 RAID를 관리한다고는 해도, 소프트웨어 RAID는 하드웨어 RAID보다 빠를 수 있다. 하드웨어 방식과 한가지 큰 차이가 있다면, 하드웨어적인 RAID 구현 방식은 OLTP 데이터베이스와 같은 애플리케이션의 처리 속도를 향상시킬 수 있도록 설계된 쓰기 전용 캐시와 함께 연동된다는 것이다. 이 경우 하드웨어 RAID 방식은 쓰기 전용 캐시에 저장된 데이터를 안전하게 스토리지 저장 공간으로 이동시켜 데이터를 보호한다. 소프트웨어 RAID의 단점은 손상된 디스크와 부트 영역에 할당된 디스크에 따라서, 어레이가 리빌딩되고 나서야 컴퓨터가 재시동될 수 있다는 것이다.

하드웨어 RAID 방식은 최소한 전용 RAID 컨트롤러를 필요로 한다. 데스크탑 PC에서는 PCI 확장 슬롯에 장착되는 카드가 될 수도 있고, 메인보드에 그 기능이 포함돼 있는 빌트 인(built in) 형태를 취하기도 한다. 규모가 큰 RAID 환경에서는 일반적으로 컨트롤러와 디스크는 다수로 구성돼 있는 외장 캐비닛에 장착되곤 한다. 디스크는 IDE, ATA, SATA, SCSI, 파이버 채널 혹은 서로 혼합된 구성이 될 수도 있다. 컨트롤러는 서버에 한 개 혹은 다수의 SCSI, 광 채널 혹은 iSCSI를 통해 직접 또는 패브릭을 통해 연결된다. 이 컨트롤러는 디스크 관리와 패리티 연산을 수행한다.

하드웨어 RAID는 일반적인 디스크 드라이브보다는 빠른 속도를 지원하며, 특히 스토리지 시스템의 RAM 속도, 캐시가 다른 컨트롤러에 이중화되는 비율, 캐시 양, 그리고 캐시에서 디스크로 데이터가 이동되는 속도에 의해 달라진다. 따라서 배터리로 백업되는 캐싱 디스크 컨트롤러는 고성능의 데이터베이스 서버 처리에 알맞다고 할 수 있다. 일반적으로 하드웨어 RAID 구현 방식은 시스템 운영 중에 손상된 드라이브를 교체할 수 있다. 극히 드문 경우에 하드웨어 컨트롤러 손상에 의한 데이터 손실이 발생하기도 한다.

하이브리드 RAID 방식은 저렴한 하드웨어 RAID 컨트롤러의 도입으로 점점 더 많은 관심을 받고 있다. 하이브리드 RAID 방식은 하드웨어는 RAID 기능이 없는 일반적인 디스크 컨트롤러와 사용자가 부팅시에 BIOS를 통해 RAID를 셋업할 수 있는 애플리케이션으로 구성된다.
하드웨어 방식과 소프트웨어 방식은 모두 손상된 드라이브를 즉각적으로 교체해 사용할 수 있도록 미리 설치돼 있는 핫 스페어를 지원한다. 이것은 시스템 점검과 수리에 필요한 시간을 절감할 수 있으며, 같은 RAID에서 또 다른 드라이브의 손상으로 인한 데이터의 손실을 예방할 수 있다.

지금까지 RAID의 역사, 구현 방법과 특성까지 기본적인 사항에 대해 알아봤다. 앞서 언급했듯이 RAID는 초기에는 고가의 디스크를 대체하기 위한 저가의 디스크를 연결해 사용하는 비용 효과적인 목적에서 출발해 저장된 데이터를 보호하는 기능을 제공하는 동시에, 서버에서 운영되는 애플리케이션의 성능을 향상시키기 위해 사용되고 있다. 다음 호에서는 서버에서 운영되는 애플리케이션에 알맞은 RAID를 비교 설명하도록 하겠다.

출처 : on the NET

급변하는 IT 환경이 다양한 백업 솔루션 요구
백업의 필요성은 PDA 등의 정보 단말기 사용자부터 엔터프라이즈 환경의 서버까지 다양한 환경에서 요구되고 있다. 따라서 각각의 용도에 알맞은 다양한 방법의 백업 장비와 솔루션이 소개되고 있다. 특히 최근 모빌 컴퓨팅 사용자를 위해 인터넷을 이용한 웹 백업 등의 새로운 솔루션이 발표되고 있으며, 스토리지 업계의 최대 현안인 SAN(Storage Area Network)이 가시화되면서 새로운 백업 방식이 고안되고 있다. 또한 중단 없는 서비스를 제공하기 위한 솔루션으로 실시간 백업이라는 방식이 도입되고, 백업의 필요성을 크게 느끼지 않던 데스크톱 PC급의 백업 솔루션도 여러 가지가 선보이고 있다.
백업 스토리지는 테이프 미디어 방식을 많이 사용하고 있다. 특히 데이터의 양과 하드디스크 용량이 기하급수적으로 증가하면서 저렴하면서도 대용량의 데이터를 저장할 수 있는 콜로라도 백업 테이프나 트라반 등의 미디어는 거의 자취를 감췄으며, DAT(Digital Audio Tape)도 서버급 백업 장비에서 데스크톱 백업 장비로 내려왔다. 또한 서버급 백업 장비로는 DLT/sDLT, LTO 등의 고용량 테이프 장비를 이용한 오토로더나 라이브러리가 일반화되고 있다,
이와 함께 일반 데스크톱 환경에서는 기존의 CD-R, CD-RW 외에도 4GB 이상의 대용량을 지원하는 DVD-R, DVD-RW 등이 속도 향상과 가격 하락으로 인기를 모으고 있다. 특히 이같은 광 미디어들은 가격이 저렴하고 복원 속도가 빠르다는 장점과 함께 반영구적인 데이터의 안정성을 보장한다는 것이 장점이다.
엔터프라이즈급의 백업 솔루션은 기하급수적으로 증가하는 데이터를 백업하기 위한 여러가지 방안을 모색하고 있다. 예전과 같이 서버마다 장착된 별도의 백업 장치를 통해 백업하는 방식으로는 날이 갈수록 복잡해지는 전산환경에 대비할 수 없다. 이에 등장한 것이 중앙 집중형 백업 방식이다. 오토로더나 라이브러리, 광 주크박스 등을 별도의 백업 서버에 연결하고, 이 서버를 통해 네트워크로 연결된 전체 서버를 백업하는 것이 중앙 집중형 백업 방식이다. 이를 통해 원격지에서도 모든 작업을 수행할 수 있다. 또한 이런 백업 작업을 수행하는 백업 소프트웨어는 NMS(Network Management System)나 시스템 관리 소프트웨어와 통합 운영할 수 있기 때문에, 관리자의 업무가 훨씬 줄어들 뿐 아니라 통합된 백업 전략을 세울 수 있어 스토리지의 활용도도 높아진다.

백업의 고속화를 위한 기술
백업 데이터의 양이 늘어나면서 백업 미디어의 용량뿐 아니라 백업 속도도 중요한 이슈로 떠오르고 있다. 빠른 백업을 위해 최근에는 디스크 백업을 이용하는 경우도 늘고 있으며, 테이프 백업 장비와 온라인 스토리지 사이에 2차 스토리지를 위치시켜 백업 속도와 효율성을 높이는 방식이 도입되기도 한다.
테이프 미디어도 다른 저장 장치에 비해 속도가 느리다는 단점이 있다. 대용량의 데이터를 저장하기 위해서는 이 속도 문제를 해결하는 것이 중요한데, 이를 위해 패러럴 스트리밍 기법이나 테이프 RAID 등의 새로운 기술이 적용되고 있다.
패러럴 스트리밍은 하나의 서버에 몇 개의 테이프 드라이브를 연결해 사용하는 방법으로, 디스크 드라이브에서 각각의 테이프 드라이브에 액세스하는 방법이다. 이는 테이프 드라이브의 성능을 최대한으로 사용하지는 못하지만, 기존의 방식보다는 훨씬 빠른 백업/복구 속도를 제공한다.
테이프 RAID 기법은 테이프 드라이브를 마치 RAID 디스크를 구성하듯이 구성해 사용하는 것이다. RAID 0에서부터 1, 3, 5를 주로 사용하며, RAID 0의 경우는 스트라이프 세트를 구성해 입출력 속도를 높인다. 그러나 이 방식은 에러를 보정할 수 있는 방법이 없기 때문에 패리티를 사용해 에러를 보정할 수 있는 RAID-5를 많이 사용한다.
실제 환경에서는 이 두가지 방법을 혼용해 사용하기도 한다.

중앙 집중화로 관리 기능 향상
최근 등장하고 있는 백업 솔루션의 경향중 하나는 자동화된 백업으로, 관리자의 작업을 최소한으로 줄이고 향상된 백업 속도로 대용량의 데이터를 빠르게 백업하는 것이다. 여기에 다양한 지원 프로그램을 통해 RDBMS 등의 특수한 애플리케이션을 최적화된 방법으로 백업하는 방법과, 다양한 환경에서 중앙 집중화된 관리기능을 제공하고 있다.
특히 SAN 등의 스토리지 솔루션이 백업 장비까지 포함하면서 다른 디스크 스토리지와 함께 백업 장비까지 통합 관리할 수 있는 방법이 고안되고 있다. SAN 구조에 백업 솔루션이 통합되면서 얻을 수 있는 장점은 이외에도 실시간으로 백업 상태를 확인할 수 있으며, 서버를 거치지 않고 디스크에서 백업 장비로 데이터를 직접 백업할 수 있다는 점 등이다.
스토리지 업계의 최대 현안으로 떠오른 SAN은 스토리지를 서버와 분리된 별도의 파이버채널 네트워크로 구성해 넓은 대역폭을 확보하고 활용도를 높이기 위한 기술이다. 이런 SAN이 본격적으로 구축되기 위해서는 디스크나 백업 스토리지와 함께 대역폭과 확장성을 위한 파이버채널 기술, 그리고 스토리지 관리를 위한 관리 소프트웨어가 유기적으로 통합돼야 한다.
특히 SAN의 도입으로 인해 얻을 수 있는 가장 큰 변화는 통합 관리다. 예전에는 백업 서버를 사용한다고 하더라도 이곳저곳에 분산된 스토리지를 통합해서 백업한다는 것은 불가능한 일이었다. 그러나 백업 스토리지까지 SAN 구조에 포함되면 SAN에 연결된 어떤 스토리지라도 백업할 수 있다. 뿐만 아니라 기존과 같이 서버를 통해 백업하는 것이 아니라 디스크 스토리지에서 바로 백업 스토리지로 데이터를 전송해 백업할 수도 있다. 따라서 전체적인 성능에 전혀 영향을 미치지 않고 실시간으로 백업할 수 있다.

대표적인 테이프 백업 장비
컴퓨터의 초창기부터 저장장치로 사용됐으며, 아직까지도 백업 스토리지의 대명사로 군림하고 있는 것은 테이프 백업 장비다. 테이프 백업 장비가 백업 스토리지로 사랑받는 이유는 저렴한 미디어 가격과 용량 확장이 다른 미디어에 비해 쉽기 때문이다. 그러나 테이프 백업 장비는 DAT, 트라반, AIT, DLT, LTO, 8mm 테이프 등이 있으며, 또 각각의 미디어는 용량에 따라 여러 가지 표준이 있다.
아직도 백업 장비의 대부분은 테이프가 차지하고 있지만 최근 데스크톱 환경을 위한 CD-R, CD-RW, DVD-R, DVD-RW 등 여러 가지 다른 백업 장비가 선보이고 있다. 특히 광 디스크 장비들은 일반 CD-ROM이나 DVD-ROM에서도 데이터를 읽을 수 있기 때문에 범용성이 높아 최근 빠르게 발전하고 있다.

· DAT
DAT는 오디오용으로 개발된 4mm 테이프를 사용한다. 가장 많이 사용되는 백업 스토리지 중 하나인 DAT은 최소 1.3GB에서 최대 20GB에 이르는 다양한 포맷의 제품이 시장에 나와 있다. 각각의 미디어 용량에 따라 DDS-1, DDS-2, DDS-3, DDS-4로 구분된다. DAT는 보다 많은 용량을 저장하기 위해 헬리컬(Helical) 스캔 방식을 사용한다. 현재 가장 많이 사용되는 포맷은 12GB 용량의 DDS-3며, 서버의 내장 스토리지 용량이 급증하면서 빠르게 DDS-4로 교체되고 있으며 조만간 36GB의 용량을 제공하는 DDS-5 제품이 시장에 등장할 것으로 보인다.

· 8mm 테이프 드라이브
8mm 테이프는 DAT와 마찬가지로 헬리컬 스캔 방식을 사용하는 백업 장비다. 이 장비는 오디오 장비에서 유래한 DAT와는 달리 8mm 비디오 장비 포맷을 사용한다. 8mm 테이프는 2GB에서 7GB까지의 용량을 제공하며, 하이엔드 8mm 테이프의 경우는 보다 빠른 속도를 제공하고 60GB의 용량을 제공한다. 이 장비는 고성능 워크스테이션이나 메인프레임 등 성능이 중요한 시스템에 많이 사용돼 왔으나 현재는 DLT나 LTO로 빠르게 교체되고 있다.

· DLT/SDLT
DLT는 현재 가장 빠른 테이프 드라이브 기술중 하나다. 퀀텀(www.quantum.com)의 메커니즘을 사용하는 DLT는 최대 40GB의 비압축 용량을 제공하며, 선형 기록 방식을 채택해 보다 안정적이다. 최근 빠른 성장세로 기존의 DAT가 차지하고 있던 시장을 잠식하고 있으며, SDLT의 경우는 약 100GB에서 300GB에 이르는 대용량을 하위 호환성과 빠른 속도를 제공해 시장에서 각광을 받고 있다. 현재 백업 장비 시장을 LTO와 함께 양분하고 있는 기술이다.

· LTO
LTO 기술은 IBM, HP, 씨게이트 3사에 의해 공동 개발된 테이프 백업 기술로 개방형 포맷을 지향할 뿐 아니라 고용량, 고속의 저장을 지원하고 다양한 서버 및 네트워크 환경을 수용할 수 있다. LTO 기술은 크게 울트리움(Ultrium)과 액셀리스(Accelis)로 구분된다.
울트리움은 뛰어난 안정성을 바탕으로 용량의 확장에 초점을 맞춘 LTO 기술로, 단독 또는 자동화 시스템에 모두 적용될 수 있다. 울트리움은 용량 확장을 위해 하나의 릴 카트리지(Reel cartridge)를 사용하며 백업, 복구, 저장을 위해 최적화돼 있다.
LTO는 현재 100GB에서 200GB에 이르는 대용량으로 SDLT와 함께 시장을 양분하고 있다.

· 오토로더, 라이브러리
오토로더나 라이브러리는 하나 또는 그 이상의 테이프 드라이브를 모아놓고 기계적인 로더를 사용해 테이프 미디어를 번갈아 장착할 수 있도록 만든 제품이다. 마치 주크박스처럼 사용하고자하는 미디어를 로봇 팔과 같은 로더를 이용해 그때그때 교체해 가며 사용하기 때문에 데이터 미디어 장착수만큼 데이터 저장 용량을 확장할 수 있다. 또한 백업 소프트웨어를 사용하면 여러 개의 백업 세트를 구성해 사용할 수도 있다. 대용량 라이브러리의 경우는 대용량 캐시와 CPU를 내장해 일반 테이프 백업 장비에 비해 빠른 속도를 제공한다.

출처 : on the NET

RAID(Redundant Array of Inexpensive Disks)는 여러개의 저용량 저가격의 하드디스크를 모아 논리적으로 하나의 대형 드라이브처럼 사용하거나 혹은 장애 발생시 데이터를 안전하게 복구할 수 있도록 하는 장비다.
RAID는 1987년 버클리 대학의 데이비드 패터슨, 가스 깁슨, 랜디 카츠가 SIGMOD에서 ‘A Case for Redundant Array of Inexpensive Disks'라는 논문을 발표하면서부터 관심을 모으게 됐다. 이 논문은 데이터와 패리티 정보를 디스크에 배치하는 방법에 따라 디스크 어레이를 분류했으며, 이것은 나중에 RAID 레벨이라고 불리게 됐다.
RAID의 가장 큰 장점으로는 시스템에 있는 디스크의 수가 증가함에 따라 디스크가 장애를 일으킬 가능성이 높아가고 있는 상황에서 미러링이나 패리티 정보를 이용해 디스크 장애에 대비할 수 있다는 것이다. 또한 여러 개의 물리적인 하드디스크를 하나의 논리적인 드라이브로 인식함으로써, 용량과 드라이브 수의 제한을 극복할 수 있다. 이외에도 하나의 디스크에 대한 입출력 요구에 비해 여러 디스크에 데이터를 분산시키고 병렬로 입출력을 처리함으로써 속도와 효율성을 증가시킬 수 있다는 것도 장점이다.

RAID의 목적
RAID의 목적은 크게 세 가지로 볼 수 있다. 첫째는 여러 개의 디스크 모듈을 하나의 대용량 디스크처럼 사용할 수 있도록 하는 것이고, 두번째는 여러 개의 디스크 모듈에 데이터를 나누어서 한꺼번에 쓰고 한꺼번에 읽는 식으로 입출력 속도를 높인다는 것이다. 마지막으로 여러 개의 디스크를 모아서 하나의 디스크로 만들었으니 그 중 하나 혹은 그 이상의 디스크에 장애가 나더라도 최소한 데이터가 사라지는 것은 방지하자는 것이다.
이같은 RAID에는 몇 가지 종류가 있다. RAID 레벨이라고 하는 것이 그것인데, RAID-0, RAID-1 이런 식으로 뒤에 번호가 붙는다. RAID 레벨에는 0부터 7까지가 있고 이들을 조합한 것이 몇 가지가 있다.
RAID 시스템 가운데 어떤 것은 시스템을 끄지 않고서도 몇 가지 작업을 할 수 있는 주요 기능을 지니고 있다. 먼저 '핫 애드(hot add)'가 있다. 이 기능을 이용하면 시스템을 켠 상태에서 어레이 내에 있는 디스크를 추가할 수 있다. 그리고 '핫 스왑(hot swap)' 기능을 이용하면 작동하지 않는 디스크를 다른 디스크로 교체할 수 있다. '핫 스페어(hot spare)'는 배열 내에 한 개 이상의 디스크를 예비 디스크로 지정할 수 있는데, 이렇게 하면 손상된 디스크의 데이터가 예비 디스크에 자동으로 복사된다.
이 기능은 서버를 지속적으로 관리하기 어려운 곳에서 사용하기에 적합하다. 일부 RAID 장치는 동적인 확장(dynamic expansion)으로 알려져 있는 '핫 RAID 레벨 변환' 기능도 갖고 있다. 이것은 가령 RAID 레벨 1 시스템의 용량이 다 됐을 때 즉석에서 RAID 5 시스템으로 환경을 재설정해 부족한 디스크 공간을 메워주는 기능이다.
하드디스크는 질과 성능이 크게 향상되긴 했지만 아직도 컴퓨터 시스템 가운데 가장 취약한 부분으로 남아 있다. 때로는 회복이 불가능할 정도로 손상되기도 하는데 시스템이 다운되면 회사로서는 큰 낭패가 아닐 수 없다. 그리고 네트워크에서 병목현상이 가장 심하게 일어나는 부분도 바로 하드디스크다. RAID 시스템은 그런 하드디스크의 결함을 비교적 저렴한 비용으로 해결할 수 있는 솔루션이다.
예전에는 채널당 여러개의 하드디스크를 장착할 수 있는 SCSI 방식을 인터페이스로 많이 사용했지만, 최근에는 로우엔드는 ATA 방식을, 하이엔드는 파이버채널 인터페이스를 주로 채용하고 있다.

RAID 레벨
버클리 대학의 연구팀은 RAID를 여섯개의 레벨로 분류했으며, RAID의 각 레벨은 서로 다른 용도를 위해 최적화된 시스템을 구현할 수 있다.

· RAID 0(stripping)
RAID 0은 데이터의 빠른 입출력을 위해 데이터를 여러 드라이브에 분산 저장한다. 데이터의 복구를 위한 추가 정보를 기록하지 않기 때문에 성능은 뛰어나지만, 어느 한 드라이브에서 장애가 발생하면 데이터는 모두 손실된다. 실제로 RAID 0만으로 구성된 스토리지는 주변에서 찾기 쉽지 않다.

· RAID 1(mirroring)
빠른 기록 속도와 함께 장애 복구 능력이 요구되는 경우에 사용되며, 2대의 드라이브 만으로도 구성할 수 있다. RAID 1은 한 드라이브에 기록되는 모든 데이터를 다른 드라이브에 복사해 놓는 방법으로 복구 능력을 제공한다. RAID 1은 하나의 드라이브를 사용하는 것에 비해 약간 나은 정도의 성능을 제공한다. 읽을 때는 조금 빠른 속도를 제공하지만, 저장할 때는 속도가 약간 느려진다. 하지만 ECC를 계산하지 않기 때문에 RAID 4나 5보다는 빠르다. 두 개의 디스크에 데이터가 동일하게 기록되므로 데이터의 복구 능력은 높지만, 전체 용량의 절반이 여분의 데이터를 기록하기 위해 사용되기 때문에 저장용량당 단가가 비싸다.

· RAID 2
RAID 2는 ECC 기능이 없는 드라이브를 위해 해밍(hamming) 오류정정코드를 사용하는 방식이다. SCSI 디스크 드라이브는 기본적으로 에러검출능력을 갖고 있기 때문에 SCSI 디스크 드라이브를 사용할 경우에는 사용하지 않는다. 또한 RAID 3에 비해 장점이 없기 때문에 거의 사용되지 않는다.

· RAID 3
RAID 3은 한 드라이브에 패리티 정보를 저장하고, 나머지 드라이브들 사이에 데이터를 바이트 단위로 분산한다(Block Striping: 전용 패리티를 이용한 블록 분배). 만약 하나의 드라이브에 문제가 생기면, 컨트롤러가 전용 패리티 드라이브로부터 문제가 생긴 드라이브의 손실된 데이터를 가져와 복구/재생한다. RAID 3은 RAID 4와 유사하나 바이트 단위의 분산 저장을 경제적으로 수행하기 위해 하드웨어적인 지원이 요구되며 효율적인 동작을 위해 동기 가능한(synchronized-spindle) 드라이브를 사용해야 한다. 입출력 작업이 동시에 모든 드라이브에 대해 이루어지는 RAID 3은 입출력을 겹치게 할 수 없기 때문에 대형 레코드가 많이 사용되는 업무에서 단일 사용자 시스템에 적합하다.

· RAID 4(parity)
RAID 4는 한 드라이브에 패리티 정보를 저장하고 나머지 드라이브 사이에 데이터를 블럭 단위로 분산하는 방식이다. 패리티 정보는 어느 한 드라이브에 장애가 발생했을 때 데이터를 복구할 수 있게 한다. RAID 4는 데이터를 읽어들일 때 RAID 0에 필적하는 우수한 성능을 보이나, 저장할 때는 매번 패리티 정보를 갱신하기 때문에 추가적인 시간이 필요하다. 실제적으로는 작고 랜덤하게 기록할수록 느리며, 크고 순차적인 기록을 행할 때는 속도 저하가 거의 없다. 여러 드라이브들 중에서 한대의 드라이브만 여분의 패리티 정보를 기록하는데 사용되기 때문에 RAID 4의 용량당 비용은 그리 높지 않다.
또한 데이터 디스크와 패리티 디스크가 독립적이기 때문에 볼륨을 확장할 때 별도의 데이터 백업과 복구 과정을 거치지 않는 유연성을 제공한다. 하지만 하나의 디스크 장애에 대해서는 완벽하게 대처할 수 있지만, 두개 이상의 디스크에 장애가 발생할 경우에는 데이터 손실이 발생한다. 또한 패리티 디스크에 병목 현상이 발생해 전체 스토리지의 성능 저하를 가져올 수 있다는 것이 단점이다.

· RAID 5(distributed parity)
RAID 5는 패리티 정보를 모든 드라이브에 나눠 기록한다. 따라서 문제가 발생할 경우, 컨트롤러가 정상적으로 운영되고 있는 다른 드라이브로부터 손실된 데이터를 가져와 복구/재생한다. 패리티를 담당하는 디스크가 병목현상을 일으키지 않기 때문에 RAID 5는 멀티프로세스 시스템과 같이 작은 데이터 기록이 수시로 발생할 경우 더 빠르다. 하지만 읽기 작업일 경우 각 드라이브에서 패리티 정보를 건너뛰어야 하기 때문에 RAID 4보다 느리다.
작고 랜덤한 입출력이 많은 경우 더 나은 성능을 제공하며, 빠른 기록속도가 필수적이지 않다면 일반적인 다중 사용자 환경을 위해 가장 좋은 선택이다. 그러나 최소한 3대, 일반적으로는 5대 이상의 드라이브가 필요하다.
RAID 4와 마찬가지로 두개 이상의 디스크에 장애가 발생할 경우에는 데이터 손실이 발생하며, RAID 4가 제공하는 볼륨 확장의 유연성도 제공하지 못한다. 하지만 현재 가장 많이 사용되는 RAID 방식이다.

· RAID 6
RAID 5와 비슷하지만, 다른 드라이브들 간에 분포되어 있는 2차 패리티 구성을 포함함으로써 매우 높은 장애 대비 능력을 제공한다. RAID 6를 채택한 상용 디스크 어레이는 찾아보기 힘들다.

· RAID 7
이 형식은 컨트롤러에 내장된 실시간 운영체계를 사용하며, 속도가 빠른 버스를 통한 캐시, 독자적인 컴퓨터의 여러 가지 특성을 포함하고 있다. RAID 7을 상용 제품에 적용한 업체는 한 곳에 불과하다.

· RAID 0+1(Striping & Mirroring)
RAID 0+1은 RAID 0의 빠른 속도와 RAID 1 의 안정적인 복구 기능을 합쳐 놓은 방식이다. 최소 4대의 디스크로 구성되는 방식으로서, 데이터가 입력되면 스트라이핑 방식으로 두 개 이상의 디스크에 나눠서 저장하며 동시에 같은 형태로 다른 하드디스크에도 동일하게 저장된다.
4개의 디스크로 RAID 0 + 1 방식으로 구성하면 2개의 디스크로 스트라이핑할 때와 같은 쓰기 속도가 나오며 읽기 속도는 4개의 디스크에서 나눠서 읽어오기 때문에 보다 빠른 속도를 갖게 된다. 그리고 미러링으로 똑같은 디스크 복사본을 갖고 있기 때문에 장애가 발생했을 때도 완벽한 복구가 가능하다.

출처 : on the NET