Pang`s

 클라우드 컴퓨팅을 많이 도입하고 있지만, 클라우드 서비스 고객과 제공자 모두 해결해야 할 과제가 있다.

고객의 해결과제

 비즈니스 크리티컬 데이터는 보호와 액세스에 대한 지속적인 모니터가 필요하다. 데이터를 사내 프라이빗 클라우드가 아닌 다른 클라우드 모델에 저장하면, 고객은 자신의 민감한 데이터에 대한 절대적인 제어를 잃을 수 있다. 대부분의 클라우드 서비스 제공자가 강화된 데이터 보안을 제공하지만 고객은 비즈니스 크리티컬 데이터에 대한 제어를 클라우드에 넘기는 것을 꺼릴 수 있다.

 클라우드 서비스 제공자는 클라우드 서비스를 제공하기 위해 여러 국가에 위치한 데이터 센터를 사용할 수 있다. 이들은 고가용성과 로드 분산을 위해 데이터 센터 사이에 데이터를 옮기거나 복제할 수 있다. 고객은 자신의 데이터가 어떤 국가에 저장됐는지 알지 못한다. 몇몇 클라우드 서비스 제공자는 고객이 자신의 데이터를 어느 국가에 저장할지 선택할 수 있게 한다. 데이터 프라이버시나 EU 개인 정보 보호 지침이나 U.S. 세이프 하버(Safe Harbor) 프로그램 같은 규제사항의 준수는 고객이 클라우드 컴퓨팅을 채택하는 데 걸림돌이 된다.

 클라우드 서비스는 네트워크를 이용해 어디서든 액세스할 수 있다. 그러나 클라우드 인프라스트럭처가 액세스 포인트와 가깝지 않으면 네트워크 지연이 발생할 수 있다. 높은 네트워크 지연으로 인해 애플리케이션의 응답 시간이 늘어나거나 애플리케이션에 타임아웃이 발생할 수 있다. 이런 문제는 클라우드 서비스 제공자와 서비스 레벨 협정을 맺음으로써 해결할 수 있다.

 또 다른 문제로는 클라우드 플랫폼 서비스가 고객이 원하는 애플리케이션을 지원하지 않을 수 있다는 점이다. 예를 들어, 서비스 제공자가 고객의 애플리케이션을 개발하고 운영할 수 있는 OS나 선호하는 프로그래밍 언어 같은 전문적이고 특정한 제품 환경을 사용하지 않을 수 있다.

 벤더 락인(lock-in) 문제도 발생할 수 있다. 이는 고객이 클라우드 서비스 제공자를 변경하기 어려운 상황을 말한다. 각기 다른 클라우드 서비스 제공자 간에 API의 상호운영성이 없으면 서비스 제공자 간에 데이터를 이동하기가 어려워지고 마이그레이션 비용이 높아진다.

제공자의 해결 과제

 클라우드 서비스 제공자는 보통 서비스 레벨 협정(SLA)을 공개해 고객이 서비스의 가용성과 서비스 품질, 다운타임 보상, 법적 규제 등에 대한 내용을 알 수 있게 한다. 또는 고객별로 SLA를 맺을 수 있다. SLA에서는 클라우드 서비스 제공자가 규정한 서비스 품질을 제공하지 못한 경우의 벌금을 규정한다. 따라서 클라우드 서비스제공자는 필요한 수준의 서비스를 제공하기 위해 필요한 리소스를 확보해야 한다. 클라우드 리소스는 분산돼 있고 서비스 요구 수준도 변동하기 때문에, 서비스 클라우드 제공자가 모든 사용자의 최고 요구 수준에 대응하기 위한 리소스를 공급하고 서비스를 제공하는 데 필요한 실제 비용을 계산하는 일은 어렵다.

 많은 소프트웨어 벤더 회사는 클라우드 소프트웨어 라이선스 모델을 갖고 있지 않다. 어떤 벤더는 기존 라이선스 모델보다 높은 가격에 클라우드 라이선스를 제공한다. 클라우드 소프트웨어 라이선스는 벤더 소프트웨어를 클라우드에 설치하는 데 문제가 된다.

 클라우드 서비스 제공자는 자신의 클라우드에 액세스하기 위한 전용 API를 제공한다. 그러나 고객은 여러 클라우드에 액세스 할 수 있는 공개 API나 표준 API를 필요로 한다. 이를 위해서는 클라우드 서비스 제공자 간의 협의가 필요하다.

클라우드 채택 고려사항

 클라우드를 채택하려는 조직은 항상 다음과 같은 질문에 직면한다. "클라우드가 조직의 환경에 적합할까?" 대부분의 조직은 기존의 IT 투자를 포기하고 모든 비즈니스 프로세스를 바로 클라우드로 옮길 수 없다. 대신 비즈니스 프로세스를 클라우드로 옮기기 전에 여러 가지 사항을 고려해봐야 한다. 클라우드 서비스를 사용하려는 개인도 클라우드 채택과 관련한 고려사항을 이해해야 한다. 다음은 클라우드 채택과 관련한 고려사항이다.

- 배치 모델의 선택

클라우드를 채택할 때는 위험성과 편의성을 잘 따져봐야 한다. 이 고려사항은 적합한 클라우드 배치 모델을 선택하는 데도 중요하다. 퍼블릭 클라우드는 개인이나 스타트업 비즈니스에 적합하다. 이들에게는 퍼블릭 클라우드가 제공하는 비용 절감이 보안이나 가용성 위험보다 더 크다. 중소 비즈니스는 적당한 고객 기반을 갖고 있으며, 고객 데이터나 서비스 레벨에 이상이 발생하면 비즈니스에 영향을 받는다. 따라서 그들은 퍼블릭 클라우드에서 온라인 트랜잭션 프로세싱(OLTP, Online Transaction Processing) 같은 티어 1 애플리케이션을 배치하려 하지는 않을 것이다. 이런 경우에는 하이브리드 클라우드 모델이 더 적합하다. 티어 1 애플리케이션은 프라이빗 클라우드에서 운영하고, 백업이나 아카이브, 테스트처럼 덜 중요한 애플리케이션은 퍼블릭 클라우드에 배치할 수 있다. 대기업은 전 세계적인 고객 기반을 갖추고 있다. 그들은 매우 중요한 고객 데이터를 보호하기 위해 엄격한 보안 정책을 적용하며, 자금력이 있으므로 자신의 프라이빗 클라우드를 구축하는 편을 선호한다.

- 애플리케이션 적합성

모든 애플리케이션이 퍼블릭 클라우드에 맞는 것은 아니다. 이는 클라우드 플랫폼 소프트웨어와 고객 애플리케이션 간에 호환이 되지 않거나 조직이 레거시 애플리케이션을 클라우드로 옮기려고 계획하기 때문일 수도 있다. 전용 미션 크리티컬 애플리케이션은 비즈니스에 핵심적이다. 이 애플리케이션은 사내에서 디자인학 개발, 운영한다. 이들은 여러 가지 장점을 제공한다. 보안상의 문제점 때문에 조직은 이 애플리케이션을 퍼블릭 클라우드로 옮기길 꺼려한다. 이 애플리케이션은 사내 프라이빗 클라우드에 적합하다. 전용이 아닌 덜 중요한 애플리케이션은 퍼블릭 클라우드에 배치하기 적당하다. 애플리케이션의 워크로드가 네트워크 트래픽을 많이 발생시키다면 퍼블릭 클라우드에 설치하는 게 최적이 아닐 수 있다. 또한 애플리케이션이 여타 데이터 센터 리소스나 애플리케이션과 통신한다면 성능 문제가 생기 수 있다.

- 자금적인 이점

자금적인 이점을 주의 깊게 분석하면 클라우드를 채택하는 데 명확한 계획을 구상할 수 있다. 클라우드와 비클라우드 환경의 총 소유 비용(TCO,Total Cost of Ownership)과 투자 수익률(ROI, Return on Investment)을 비교해보고 잠재적인 비용상의 이점을 분석해야 한다. TCO와 ROI를 계산할 때 조직과 개인은 자신의 인프라스트럭처를 배치하고 유지하는 비용과 클라우드 채택 비용을 고려해야 한다. 인프라스트럭처를 소유하는 비용을 계산할 때는 자본 지출(CAPEX)과 운영 비용(OPEX, operation expenditure)을 모두 고려해야 한다. CAPEX에는 서버와 스토리지, OS, 애플리케이션, 네트워크 디바이스, 부동산 등을 구매하는 비용이 포함된다. OPEX에는 전력과 냉방, 인력, 유지, 백업 등의 비용이 포함된다. 이런 지출을 클라우드를 채택할 때 발생하는 비용과 비교해야 한다. 클라우드 채택 비용에는 클라우드로 마이그레이션 하는 비용과 규정 준수와 보안을 보장하는 비용, 사용료나 가입비 등이 포함된다. 애플리케이션을 클라우드로 옮길 경우 사내 클라우드를 구축하는 경우가 아니라면 CAPEX는 감소한다.

- 클라우드 서비스 제공자의 선택

퍼블릭 클라우드에서는 제공자를 선택하는 일이 중요하다. 고객은 제공자가 얼마나 오랫동안 서비스를 잘 제공했는지 알아야 한다. 또한 제공자의 서비스를 중단하는 일이 얼마나 쉬운지도 파악해야 한다. 다른 제공자로 서비스를 옮기는 데 어려움은 없는지도 알아야 한다. 제공자가 보안과 법적, 프라이버시 규약을 어떻게 준수하는지도 파악해야 한다. 또한 제공자가 고객 지원을 얼마나 잘 수행하는지도 알아봐야 한다.

- 서비스 레벨 협정(SLA)

클라우드 서비스 제공자는 클라우드 서비스와 함께 대역폭과 업타임 같은 서비스 품질(QoS)에 대해서도 정보를 제공한다. QoS 관련 정보는 SLA의 일부인데, 이는 제공자와 고객 간에 채결한 서비스 계약이다. SLA는 고객과 제공자 간에 기대하는 서비스의 수준이다. 클라우드 서비스를 채택하기 전에 고객은 QoS가 자신의 요구사항에 맞는지 확인해야 한다.

 애플리케이션과 플랫폼 소프트웨어 레이어에는 비즈니스 애플리케이션과 OS와 데이터베이스 같은 플랫폼 소프트웨어가 포함된다. 플랫폼 소프트웨어는 비즈니스 애플리케이션을 실행할 수 있는 환경을 제공한다. 가상 머신이 애플리케이션과 플랫폼 소프트웨어를 호스트해 SaaS와 PaaS를 만든다. SaaS에서는 클라우드 서비스 제공자가 애플리케이션과 플랫폼 소프트웨어를 제공한다. PaaS의 경우에는 클라우드 서비스 제공자가 플랫폼 소프트웨어만 제공하고 고객이 자신의 애플리케이션을 클라우드에 설치한다.

 클라우드 관리와 생성 툴 레이어에는 다음과 같은 세 가지 유형의 소프트웨어가 포함된다.

- 물리적 인프라스트럭처 및 가상 인프라스트럭처 관리 소프트웨어

- 통합 관리 소프트웨어

- 사용자 액세스 관리 소프트웨어

 이는 소프트웨어가 수행하는 기능에 기반해 분류한 것이다. 이 소프트웨어는 서로 상호작용하며 클라우드 서비스의 공급을 자동화한다.

 물리적 인프라스트럭처 및 가상 인프라스트럭처 관리 소프트웨어는 여러 인프라스트럭처 리소스의 벤더나 서드파티 조직에서 제공한다. 예를 들어, 소프트웨어 어레이는 자신의 관리 소프트웨어를 갖고 있다. 네트워크와 물리적 서버 역시 각각 네트워크와 컴퓨트 관리 소프트웨어로 관리한다. 이 소프트웨어는 기저의 물리적 인프라스트럭처에서 가상 인프라스트럭처를 구축하기 위한 인터페이스를 제공한다

 통합 관리 소프트웨어는 모든 스탠드얼론 물리적, 가상 인프라스트럭처 관리 소프트웨어와 상호작용한다. 이는 존재하는 물리적, 가상 인프라스트럭처의 설정과 연결, 활용도에 대한 정보를 수집한다. 통합 관리 소프트웨어는 이 정보를 모아 여러 데이터 센터에 흩어져 있는 인프라스트럭처 리소스에 대한 통합된 뷰를 제공한다. 관리자는 이 툴을 사용해 물리적, 가상 리소스의 성능과 용량, 가용성을 중앙에서 모니터링할 수 있다. 통합 관리 소프트웨어는 물리적, 가상 인프라스트럭처를 설정하고 컴퓨트(CPU와 메모리)와 네트워크, 스토리지 풀을 통합할 수 있는 단일 관리 인터페이스를 제공한다. 이 툴을 사용해 컴퓨트 풀의 그룹이 데이터를 저장하고 전송하기 위해 스토리지 명령을 물리적, 가상 인프라스트럭처 관리 소프트웨어에게 각각 보내고, 이들은 이 명령을 실행한다. 이를 이용하면 컴퓨트와 스토리지, 네트워크 리소스를 각 네이티브 관리 소프트웨어를 이용해 따로 관리하지 않아도 된다.

 통합 관리 소프트웨어의 주요 기능은 클라우드 서비스의 생성을 자동화하는 것이다. 관리자는 CPU와 메모리, 네트워크 대역폭, 스토리지 용량, 애플리케이션과 플랫폼 서비스의 이름과 설명, 리소스의 위치. 백업 정책 등의 서비스 속성을 정의할 수 있다. 통합 관리 소프트웨어가 고객의 요청을 받으면 미리 정의된 서비스 속성에 따라 서비스를 생성한다.

 사용자 액세스 관리 소프트웨어는 고객에게 웹 기반 사용자 인터페이스를 제공한다. 고객은 이 인터페이스를 이용해 서비스 카탈로그를 탐색하고 클라우드 서비스를 요청할 수 있다. 사용자 액세스 관리 소프트웨어는 사용자의 요청을 통합 관리 소프트웨어로 보내기 전에 사용자를 인증한다. 또한 클라우드 서비스 인스턴스와 관련된 리소스의 할당과 사용량을 모니터링한다. 리소스의 할당과 사용량에 기반해 환불(chargeback) 리포트를 만든다. 환불 리포트는 고객이 볼 수 있으며 고객과 제공자 사이에 투명성을 제공한다.

 클라우드 최적화 스토리지

사용자가 생성한 비정형 데이터의 증가와 함께 컨텐츠 리치 애플리케이션은 대용량 데이터를 저장하던 전통적인 기법으로는 관리하기 어렵다. 이처럼 새로운 유형의 데이터가 대규모로 증가하고 전 세계에 걸친 다양한 지역의 사용자를 서비스해야 함에 따라 정보 저장과 관리를 글로벌 스케일로 처리해야 하는 상황이 됐다. 클라우드 최적화 스토리지는 이런 요구사항을 위한 솔루션이다. 이는 기민한 탄력성과 글로벌 액세스, 온디맨드 스토리지 용량을 제공하는 확장 가능하고 유연한 아키텍처다. 이 스토리지는 또한 전체 스토리지 인프라스트럭처에 대해 단일 액세스 포인트를 제공함으로써 스토리지와 고객 사이의 엄격한 마운트 지점 기반의 상호작용 제한을 해결했다.

 클라우드 최적화 스토리지는 빌트인 멀티테넌시 모델을 활용하고 셀프 서비스를 가능케 한다. 스토리지 리소스에 대한 액세스를 측정하고 공유 인프라스트럭처에서 서비스로서의 스토리지를 제공한다. 클라우드 최적화 스토리지는 스토리지 설치와 보호, 생명 주기 정책을 결정하기위해 커스터마이즈가 가능하고 가치 중심의 메타데이터를 사용하는 객체 기반 스토리지 기술을 활용한다. 다음은 클라우드 최적화 스토리지 솔루션의 주요 특징이다.

- 전 세계적으로 분산된 인프라스트럭처에 분산된 많은 수의 객체를 처리하기 위한 대규모 확장 가능 인프라스트럭처

- 용량과 위치 및 기타 파일 시스템이 지닌 제한을 없앤 통함 네임스페이스

- 서비스 레벨에 기반해 데이터 보호와 가용성, 비용을 최적화하는 메타데이터 및 정책 기반 정보 관리 기능

- 여러 애플리케이션을 같은 인프라스트럭처에서 안전하게 서비스할 수 있는 안전한 멀티테넌시. 각 애플리케이션은 안전하게 분리되고 데이터는 뒤섞이거나 다른 고객이 액세스할 수 없다.

- REST, SOAP 웹 서비스 API와 다양한 클라이언트 디바이스를 사용한 파일 기반 액세스를 제공한다.

 프라이빗 클라우드(private cloud) 모델에서는 여러 고객으로 구성된 단일 조직(예: 비즈니스 유닛)만이 사용할 수 있도록 클라우드 인프라스트럭처를 제공한다. 이는 조직이나 제3자 또는 이들의 조합이 소유하고 관리, 운영할 수 있다. 또한 사내 클라우드이거나 사외 클라우드일 수 있다. 다음은 두 가지 프라이빗 클라우드 모델이다.

-사내 프라이빗 클라우드

사내 프라이빗 클라우드는 내부 클라우드라고도 하며, 기업이 자신의 데이터 센터에서 호스트한다. 이 모델은 크기와 리소스 확장성 면에서 제한이 있지만, 기업이 자신의 클라우드 서비스 관리 프로세스와 보안을 표준화할 수 있다. 또한 기업은 물리적 리소스에 대한 자본과 운영 비용이 필요할 수 있다. 이 모델은 애플리케이션과 인프라스트럭처 설정, 보안 메커니즘에 대한 완전한 제어가 필요한 기업에게 최적이다.

-외부 호스트 프라이빗 클라우드

조직의 외부에서 호스트하고 제3의 조직이 관리하는 프라이빗 클라우드다. 제3의 조직은 특정 조직에 대한 프라이버시와 기밀 유지를 전적으로 보장하며, 배타적인 클라우드 환경을 제공한다.

 커뮤니티 클라우드(community cloud) 모델에서는 관심 사항(예: 임무나 보안 요구사항, 정책, 규제)을 공유하는 여러 조직의 고객들로 구성된 커뮤니티가 독점적으로 사용할 수 있는 클라우드 인프라스트럭처를 제공한다. 커뮤니티나 제3자, 또는 이들의 조합에 있는 여러 조직이 소유하고 관리, 운영할 수 있다.

 커뮤니티 클라우드는 퍼블릭 클라우드에 비해 더 작은 고객이 비용을 부담한다. 따라서 이 옵션은 좀 더 비싸지만, 높은 수준의 프라이버시와 보안, 규제 준수를 제공할 수 있다. 커뮤니티 클라우드 또한 프라이빗 클라우드에 비해 방대한 리소스 풀을 제공한다. 커뮤니티 클라우드가 유용한 한 가지 예로는 정부 기관이 있다. 정부안에 가이드라인이 유사한 여러 기관이 있다면 이 기관들은 같은 인프라스트럭처를 공유함으로써 개별 기관의 투자를 줄일 수 있다.

 하이브리드 클라우드(hybrid  cloud) 모델에서 클라우드 인프라스트럭처는 두 가지 이상의 클라우드 인프라스트럭처(프라이빗이나 커뮤니티, 퍼블릭)의 조합으로, 이들은 고유한 엔티티이지만 데이터와 애플리케이션의 이동을 가능케 하는 표준 또는 전용 기술(예: 클라우드 간의 로드 밸런싱을 위한 클러스터 버스팅bursting)을 이용해 서로 연결돼 있다.

 하이브리드 모델에서는 중요하지 않은 애플리케이션이나 데이터는 퍼블릭 클라우드에 배치해 퍼블릭 클라우드의 확장성과 비용의 장점을 활용한다. 조직의 미션 크리티컬 애플리케이션과 데이터는 프라이빗 클라우드에 남겨둠으로써 안전하게 보호한다.

 클라우드 컴퓨팅 인프라스트럭처는 클라우드 컴퓨팅의 다섯 가지 주요 특징을 실현하기 위한 하드웨어와 소프트웨어의 집합이다. 클라우드 컴퓨팅 인프라스트럭처는 다음의 레이어로 구성된다.

- 물리적 인프라스트럭처

- 가상 인프라스트럭처

- 애플리케이션과 플랫폼 소프트웨어

- 클라우드 관리와 서비스 생성 툴

 이 레이어의 리소스들이 합해지고 조율돼 고객에게 클라우드 서비스를 제공한다.

 물리적 인프라스트럭처는 물리적 서버와 스토리지 시스템, 네트워크를 포함한 물리적 컴퓨팅 리소스로 구성된다. 물리적 서버는 IP나 FC SAN, IP SAN, FCoE 네트워크 등을 통해 여타 서버와 스토리지 시스템, 클라이언트와 연결돼 있다.

 클라우드 서비스 공급자는 여러 데이터 센터에 있는 물리적 컴퓨팅 리소스를 사용해 서비스를 제공할 수도 있다. 컴퓨팅 리소스가 여러 데이터 센터에 분산돼 있으며 그들 간에 연결이 설정돼야 한다. 이 연결은 다른 지역의 데이터 센터가 하나의 큰 데이터 센터로 동작할 수 있게 해준다. 이는 비즈니스 애플리케이션과 데이터를 다른 데이터 센터로 마이그레이션 할 수 있게 하고, 여러 데이터 센터의 리소스를 사용해 클라우드 서비스를 공급할 수 있게 한다.

 클라우드 서비스 공급자는 가상화 기술을 사용해 물리적 인프라스트럭처 위에 가상 인프라스트럭처 레이어를 만든다. 가상화는 리소스 풀링과 기민한 탄력성 같은 클라우드의 특징을 충족시켜준다. 또한 클라우드 서비스를 제공하는 비용을 줄이는 데도 도움이 된다. 아직 물리적 인프라스트럭처를 완전히 가상화하지 않은 클라우드 서비스 공급자도 있지만, 이들도 효율성과 최적화를 위해 가상화를 채택하고 있다.

 가상화는 물리적 컴퓨팅 리소스를 추상화하고 리소스의 용량에 대한 통합 뷰를 제공한다. 통합 리소스는 리소스 풀(resource pool)이라 불리는 단일 엔티티로 관리된다. 예를 들어, 리소스 풀이 클러스터의 물리적 서버 CPU를 그룹화한다고 하자. 리소스 풀의 용량은 클러스터에서 사용 가능한 모든 CPU 능력(예: 10,000메가헤르츠)의 합이다. CPU 풀뿐만 아니라 가상 인프라스트럭처에는 메모리 풀과 네트워크 풀, 스토리지 풀 같은 유형의 리소스 풀이 있다. 리소스 풀과는 별도로 가상 인프라스트럭처는 VLAN ID 풀과 VSAN ID 풀 같은 아이덴티티 풀(identity pool)도 포함된다. 각 유형의 풀 개수나 풀의 용량은 클라우드 서비스 공급자가 어떤 클라우드 서비스를 제공하려는 지에 따라 달라진다.

 가상 인프라스트럭처에는 가상 머신, 가상 스토리지 볼륨, 가상 네트워크 같은 가상화 컴퓨터 리소스도 포함된다. 이 리소스는 CPU, 메모리, 네트워크 대역폭, 스토리지 공간 같은 용량을 리소스 풀에서 얻어온다. 이들은 서비스 요구사항에 따라 쉽고 유연하게 가상 컴퓨팅 리소스에게 할당된다. 가상 네트워크는 해당 아이덴티티 풀에서 VLAN ID와 VSAN ID를 얻어와 생성한다. 가상 컴퓨팅 리소스는 클라우드 인프라스트럭처 서비스를 만드는 데 사용된다.

 클라우드 컴퓨팅의 주요 장점으로는 다음과 같다.

 IT 비용의 감소
클라우드 서비스는 이용량이나 가입 비용에 기반해 구매한다. 이는 고객의 IT 자본 지출(CAPEX, capital expenditure)을 줄이거나 없애준다.

 비즈니스 기민성
클라우드 컴퓨팅은 컴퓨팅 용량을 빠르게 할당하고 조절할 수 있다. 클라우드 컴퓨팅은 새로운 어플리케이션과 서비스를 공급하고 배치하는 데 필요한 시간을 월 단위에서 분 단위로 줄일 수 있다. 이로 인해 비즈니스가 시장의 변동에 빠르게 대처하고 시장화 시간을 줄일 수 있다.

 유연한 확장성
클라우드 컴퓨팅은 고객이 컴퓨팅 리소스를 쉽게 확장하거나 축소할 수 있게 해준다. 고객은 클라우드 서비스 공급자와의 상호작용 없이 혼자서 자동적으로 컴퓨팅 리소스의 스케일을 조절할 수 있다. 클라우드 컴퓨팅의 유연한 서비스 공급으로 인해 고객들은 제한 없이 확장 가능하다고 느끼게 된다.

 고가용성
고객의 정책과 우선순위에 따라 알맞은 수준의 리소스 가용성을 보장한다. 인프라스트럭처 컴포넌트(서버와 네트워크 경로, 스토리지 디바이스, 클러스터화된 소프트웨어)를 중복함으로써 클라우드에 재난 대비를 제공한다. 다수의 데이터센터를 여러 지역에 설치함으로써 지역적인 재해로 인한 데이터 비가용성도 방지한다.

 NIST에 따르면 클라우드 서비스 공급은 다음의 세 가지로 분류된다. IaaS(infrastructure-as-a-Service[서비스로서의 인프라스트럭처]), PaaS(Platform-as-a-Service[서비스로서의 플랫폼]), SaaS(Software-as-a-Service[서비스로서의 소프트웨어])

 IaaS
고객이 운영체제와 애플리케이션을 포함한 임의의 소프트웨어를 설치하고 실행할 수 있도록 프로세싱과 스토리지, 네트워크 그리고 그 외의 기본적인 컴퓨팅 리소스를 제공한다. 고객은 기저의 클라우드 인프라스트럭처를 관리하거나 제어할 수 있으며 애플리케이션을 설치할 수 있다. 그리고 네트워크 컴포넌트(예: 호스트 방화벽)를 제한적으로 제어할 수도 있다.

IaaS는 클라우드 서비스 스택에서 가장 기본이 되는 레이어다. 이는 SaaS와 PaaS 레이어의 기초를 제공한다.

아마존 EC2(Elastic Compute Cloud)는 확장 가능한 컴퓨팅을 클라우드에서 온디맨드로 제공하는 IaaS의 예다. 고객은 사전의 자본 투자 없이 아마존의 대규모 컴퓨팅 인프라스트럭처를 사용할 수 있다.

 PaaS
공급자가 제공하는 프로그래밍 언어와 라이브러리, 서비스, 툴을 사용해 만들어진 애플리케이션(사용자가 작성하거나 이미 작성된)을 클라우드 인프라스트럭처에 배치할 수 있다. 고객은 네트워크와 서버, 운영체제, 스토리지를 포함한 기저의 클라우드 인프라스트럭처를 제어할 수는 없지만 애플리케이션의 배치를 제어할 수 있으며, 애플리케이션 호스트 환경을 설정할 수도 있다.

PaaS는 클라우드 서비스 공급자가 제공하는 애플리케이션 개발 환경으로도 사용될 수 있다. 고객은 이 플랫폼을 사용해 애플리케이션을 작성할 수 있으며 이를 클라우드에 배치할 수 있다. 배치된 애플리케이션의 워크로드는 애플리케이션마다 다르기 때문에 컴퓨팅 리소스의 확장성은 보통 컴퓨팅 플랫폼에 의해 보장된다. 구글앱 엔진(Google App Engine)과 마이크로소프트 윈도우 애저 플랫폼(Microsoft Windows Azure Platform)이 PaaS의 예다.

 SaaS
클라우드 인프라스트럭처에서 운영되는 공급자의 애플리케이션을 고객이 이용할 수 있다. 웹 브라우저와 같은 씬(thin) 클라이언트 인터페이스(예: 웹 기반 이메일)나 프로그램 인터페이스를 이용한 다양한 클라이언트 디바이스를 사용해 애플리케이션을 이용한다. 고객은 네트워크와 서버, 운영체제, 스토리지, 또는 개별 애플리케이션을 포함해 기저의 클라우드 인프라스트럭처를 제어하거나 관리하지 않는다. 사용자 개별 애플리케이션 서정만을 제한적으로 제어할 수 있다.

SaaS 모델에서는 클라우드 서비스 공급자가 고객 관계 관리(CRM, customer relationship management)와 이메일, 인스턴트 메시징(IM, instant messaging) 같은 애플리케이션을 서비스로 제공한다. 클라우드 서비스 제공자는 서비스를 제공하기 위한 컴퓨팅 인프라스트럭처와 소프트웨어를 독점적으로 관리한다. 고객은 애플리케이션을 커스터마이즈하기 위해 애플리케이션 설정을 변경할 수 있다.

EMC 모지(mozy)는 SaaS의 예다. 고객은 모지 콘솔을 사용해 손쉽고 안전하고 자동적으로 자신의 데이터를 온라인으로 백업하고 복구할 수 있다. 세일즈포스닷컴(Salesforce.com)은 세일즈 클라우드(Sales Cloud)와 서비스 클라우드(Service Cloud) 같은 SaaS 기반 CRM 애플리케이션을 공급한다.

 NIST에 따르면 클라우드 컴퓨팅은 퍼블릭, 프라이빗, 커뮤니티, 하이브리드라는 네 가지 배치 모델로 분류된다. 이는 클라우드 인프라스트럭처가 구성되고 사용되는 기초를 제공한다.

 퍼블릭 클라우드(public cloud) 모델에서는 일반 대중이 사용할 수 있게 클라우드 인프라스트럭처를 공급한다. 기업이나 학교, 정부 기관 또는 이런 조직들의 조합이 소유하고 관리하고 운영할 수 있다. 클라우드 공급자가 있어야 존재한다.

 고객은 인터넷을 통해 공급자가 제공하는 클라우드 서비스를 사용하고 측정된 사용량에 따른 비용을 지불하거나 가입비를 낸다. 퍼블릭 클라우드의 장점은 높은 확장성을 지녔음에도 비용이 싸다는 것이다. 그러나 고객에게 이런 장점은 위험 요소로 다가올 수도 있다. 클라우드 리소스를 제어할 수 없으며 기밀 데이터의 보안, 네트워크 성능, 상호 운영성 등이 문제가 될 수 있다. 유명한 퍼블릭 클라우드 서비스 공급사로는 아마존과 구글, 세일즈포스닷컴이 있다.

 오늘날처럼 경쟁이 치열한 상황에서 기업은 적은 투자로 더 많은 이익을 얻기 위해 자신의 IT 프로세스의 효율성을 높이고 혁신해야 한다. 변화하는 비즈니스 요구사항과 혁신의 속도를 맞추기 위해서는 비즈니스의 상품화 시간(time-to-market)을 줄이고 긴밀해야 하며 가용성은 높이고 비용은 줄여야 한다. 이런 비즈니스의 요구사항을 충족시키려면 IT 팀이 해결해야 할 여러 가지 어려운 문제가 있다. 이런 해결 과제에는 24시간 동안 전 세계의 고객들을 대응해야 하며, 기술을 빠르게 개선하고 IT 리소스를 좀 더 빠르게 제공해야 하는 것들이 있다. 이 모든 것을 더 적은 비용으로 해결해야 한다.

 이런 오래된 문제가 새로운 컴퓨팅 스타일인 클라우드 컴퓨팅(cloud computing)의 등장으로 해결되고 있다. 클라우드 컴퓨팅은 조직과 기업이 IT 리소스를 서비스로 공급받고 사용할 수 있게 해준다. 클라우드 컴퓨팅에서는 사용자가 컴퓨트나 소프트웨어, 스토리지 또는 이런 리소스의 묶음 같은 클라우드 서비스를 포탈을 통해 검색하고 선택할 수 있다. 클라우드 컴퓨팅은 고객이 선택한 클라우드 서비스를 자동으로 제공한다. 조직과 개인이 더 적은 비용으로 더 빠르게 IT 리소스를 배치할 수 있게 도와준다.

 미국 국립 표준 기술 연구소(NIST, National Institute of Standards and Technology)에서는 클라우드 컴퓨팅을 다음과 같이 정의하고 있다. (NIST Special Publication 800-145)
 클라우드 컴퓨팅은 최소한의 관리나 서비스 공급자와의 상호작용만으로도 빠르게 공급되고 사용할 수 있는 설정 가능한 컴퓨팅 리소스(예: 네트워크와 서버, 스토리지, 애플리케이션, 서비스)의 공유 풀을 네트워크를 통해 언제 어디서든지 편리하게 필요할 때마다 접근할 수 있는 모델이다.

 클라우드 컴퓨팅은 그리드 컴퓨팅과 유틸맅 컴퓨팅, 가상화 기술, 서비스 지향 아키텍처 등의 기술을 기반으로 한다.

 그리드 컴퓨팅(grid computing)은 네트워크에 존재하는 수많은 이기종 컴퓨터의 리소스가 하나의 작업을 동시에 함께 수행하게 하는 분산 컴퓨팅의 한 형태다. 그리드 컴퓨팅은 병렬 컴퓨팅을 가능하게 하며, 대규모 워크로드에 적합하다.

 유틸리티 컴퓨팅(utility computing)은 사용자가 필요로 할 경우 서비스 공급자가 리소스를 공급하고 사용한 만큼만 비용을 지불하는 서비스 고급 모델이다. 이것은 사용량에 따라 비용을 지불하는 전력 같은 공공 서비스와 유사하다.

 가상화(virtualization)는 IT 리소스의 물리적 특징을 사용자로부터 추상화하는 기술이다. 이는 리소스를 풀(pool)로 관리하고, 이 풀에서 사용자가 가상의 리소스를 만들 수 있게 한다. 가상화는 비 가상화 환경에서의 리소스 공급에 비해 유연한 리소스 공급을 제공한다. 가상화는 리소스의 활용도를 최적화하고 좀 더 효율적으로 공급할 수 있게 도와준다.

 서비스 지향 아키텍처(SOA, Service Oriented Architecture)는 서로 상호작용이 가능한 서비스의 집합을 제공한다. 이 서비스는 함께 동작해 어떤 작업을 수행하거나 단순히 여러 서비스 간에 데이터를 전달하기도 한다.

 클라우드 서비스에 사용되는 컴퓨팅 인프라스트럭처가 갖춰야 할 기능과 특징이 있다. NIST에 따르면 클라우드 인프라스트럭처는 다섯 가지 특징을 지녀야 한다.

 온디맨드 셀프서비스 사용자는 서버 시간과 네트워크 스토리지 같은 컴퓨팅 리소스를 단독으로 필요한 만큼, 각 서비스 공급자와의 직접적인 상호작용 없이 자동으로 공급받을 수 있어야 한다.

 클라우드 서비스 공급자는 서비스카탈로그를 공개해야 하는데, 이는 고객이 사용할 수 있는 클라우드 서비스에 대한 정보를 제공한다. 서비스 카탈로그에는 서비스 속성과 가격, 요청 과정 등에 대한 정보가 있다. 고객은 웹 기반의 사용자 인터페이스를 이용해 서비스 카탈로그를 보고 이를 이용해 서비스를 신청한다. 고객은 준비된 서비스를 이용하거나 서비스를 커스터마이즈하기 위해 몇 가지 서비스 파라미터를 변경할 수도 있다.

 브로드 네트워크 액세스 네트워크를 통해 기능을 사용할 수 있어야 하고 다양한 기종의 클라이언트 플랫폼(예: 모바일 폰, 태블릿, 랩탑, 워크스테이션 등)에서 표준 메커니즘을 통해 액세스할 수 있어야 한다.

 리소스 풀링 공급자의 컴퓨팅 리소스는 풀(pool)로 구성돼 멀티 테넌트(multi tenant) 모델을 이용해 여러 사용자에게 제공하고 사용자의 요구에 따라 물리적, 가상 리소스를 동적으로 할당하고 재할당할 수 있어야 한다. 고객은 리소스의 정확한 위치를 선택하거나 알 수도 없지만, 높은 단계(예: 국가나 주, 데이터 센터)에서 위치를 지정할 수는 있다. 리소스에는 스토리지와 프로세싱, 메모리, 네트워크 대역폭이 있다.

 기민한 탄력성 요청에 맞게 스케일을 조정하기 위해 때로는 자동적으로 서비스를 탄력적으로 공급하고 배치할 수 있어야 한다. 고객에게는 공급 가능한 서비스가 무제한적으로 보일 수 있어야 하며, 언제든 필요한 만큼 사용할 수 있어야 한다.

 고객은 IT 리소스에 대한 요구가 변동이 심한 경우 클라우드의 기만한 탄력성을 활용할 수 있다. 예를 들어, 기업이 웹과 애플리케이션 서버를 특정 작업을 완수하기 위해 잠시 두 배로 늘려야 한다고 하면, 그 외의 기간에는 쉬고 있는 서버 리소스를 줄여 비용을 낮추고자 한다. 클라우드는 이렇게 동적으로 고객의 리소스에 대한 수요를 변경할 수 있게 해준다.

 측정되는 서비스 클라우드 시스템은 서비스의 종류(예: 스토리지나 프로세싱, 대역폭, 사용자 계정)에 따라 적당한 수준으로 측정함으로써 리소스를 자동으로 제어하고 최적화한다. 공급자와 사용자에게 모두 투명성을 제공하며 리소스 사용량을 모니터링하고 제어, 보고할 수 있다.

 스토리지 프로비저닝(storage provisioning)이란 스토리지 리소스를 호스트가 실행하는 애플리케이션의 용량과 가용성,성능 요구 조건에 따라 호스트에 할당하는 과정을 말한다. 스토리지 프로비저닝은 전통적인 방법과 가상화 방법, 이 두 가지 방법으로 수행할 수 있다. 가상 프로비저닝(virtual provisioning)은 가상화 기술을 이용해 스토리지를 공급한다.

 전통적인 스토리지 프로비저닝에서느 물리적 디스크를 논리적으로 그룹화하고, 요청된 RAID 레벨을 적용해 RAID 집합을 형성한다. RAID 집합의 드라이브 개수와 RAID 레벨은 RAID 집합의 가용성과 용량, 성능을 결정한다. 종류와 속도, 용량이 같은 드라이브를 사용해 RAID 집합을 구성해 최대 사용 용량과 안정성, 성능의 지속성을 보장하는 것이 좋다. 예를 들어, RAID 집합에 용량이 다른 드라이브가 섞여 있으면 가장 작은 디스크 용량에 맞춰 RAID 집합의 전체 용량을 구성한다. 더 큰 드라이브의 남은 저장 공간은 사용하지 않는다. 이와 비슷하게 RPM(revolutions per minute)이 높은 드라이브와 낮은 드라이브가 있으면 RAID 집합의 전체 성능은 떨어진다.

 RAID 집합은 보통 집합의 개별 드라이브 용량을 합하기 때문에 대용량 저장 공간을 갖는다. 가용 저장 공간을 작은 단위로 파티션해 논리적 유닛(logical unit)을 만든다. 이 유닛을 호스트의 요구사항에 따라 호스트에 할당한다.

 논리적 유닛은 집합에 속한 물리적 디스크에 고르게 분포한다. RAID 집합에서 만들어진 각 논리적 유닛은 논리적 유닛 넘버(LUN, logical unit number)라 불리는 고유 ID를 부여받늗나. LUN은 호스트로부터 RAID 집합이 어떻게 구성되고 조직되는지 숨긴다. 전통적인 프로비저닝 기법으로 생성된 LUN을 가상화 프로비저닝 기법으로 생성한 LUN과 구분하기 위해 두꺼운 LUN(thick LUN)이라고도 한다.

 LUN을 구성하고 가상화가 아닌 호스트에 할당할 때는 LUN을 찾기 위한 버스 스캔이 필요하다. 운영체제에게 이 LUN은 로raw 디스크로 보인다. 이 디스크를 사용하려면 파일 시스템으로 포맷한 후 파일 시스템을 마운트해야 한다.

 가상 호스트 환경에서는 LUN이 하이퍼바이저에게 할당된다. 하이퍼바이저도 LUN을 로 디스크로 인식한다. 이 디스크는 하이퍼바이저 파일 시스템으로 설정하고 가상 디스크를 생성한다. 가상 디스크는 하이퍼바이저 파일 시스템에 있는 파일이다. 그 후 가상 디스크를 가상 머신에 할당하면 가상 머신에 로 디스크로 나타난다. 가상 디스크를 사용하려면 가상화가 아닌 환경에서와 같은 단계를 수행하면 된다. 여기서는 LUN 공간이 여러 가상 머신에 의해 공유되고 동시에 액세스될 수 있다.

 가상 머신은 스토리지 시스템의 LUN을 직접 액세스할 수도 있다. 이렇게 하면 전체 LUN이 단일 가상 머신에 할당된다. 가상 머신에서 실행하는 애플리케이션이 응답 시간이 중요하고 다른 가상 머신과 스토리지를 공유하는 것이 응답 시간에 영향을 끼치는 경우 이렇게 하는 것이 좋다. 직접 액세스하는 방법은 가상 머신이 물리적 머신과 클러스터된 경우에도 사용한다. 이 경우 가상 머신은 물리적 머신이 액세스하고 있는 LUN을 액세스하게 된다.

 메타LUN은 용량을 추가하거나 성능을 높이기 위해 LUN을 확장하는 방법이다. 메타LUN은 2개 이상의 LUN을 합해 만든다. 메타LUN은 베이스 LUN과 1개 이상의 컴포넌트 LUN으로 구성된다. 메타LUN은 이어 붙이거나(concatenated) 스트라이핑될 수 있다.

 이어 붙인 확장은 추가 용량을 베이스 LUN에 더한다. 이 확장에서 컴포넌트 LUN은 베이스 LUN과 같은 크기일 필요는 없다. 이어 붙인 메타LUN의 모든 LUN은 반드시 모두 보호되거나(패리티나 미러) 모두 보호되지 않아야 한다(RAID 0). 메타LUN 안에서 여러 RAID 유형을 섞어 사용할 수 있다. 예를 들어 RAID 1/0 LUN은 RAUD 5 LUN과 결합할 수 있다. 그러나 RAID 0 LUN은 RAID 0 LUN과만 이어 붙일 수 있다. 이어 붙인 확장은 빠르지만 성능상의 이점은 없다.

 스트라이프 확장은 베이스 LUN의 데이터를 베이스 LUN과 컴포넌트 LUN에 다시 스트라이핑한다. 스트라이프 확장에서 모든 LUN은 같은 크기이며 같은 RAID 레벨을 가져야 한다. 스트라이프 확장은 스트라이핑된 드라이브의 개수가 늘어나기 때문에 성능이 향상된다.

 이어 붙인 확장과 스트라이프 확장의 모든 LUN은 디스크-드라이브 유형이 반드시 같아야 한다. 즉 모두 파이버 채널이거나 모두 ATA여야 한다.

 가상화 프로비저닝은 스토리지 어레이에서 물리적으로 할당된 것보다 많은 용량의 LUN을 만들고 제공할 수 있다. 가상화 프로비저닝으로 만들어진 LUN을 전통 LUN과 구분하기 위해 얇은 LUN(thin LUN)이라고 한다.

 얇은 LUN은 만들어져 호스트에 제공될 때에 필요한 모든 물리적 스토리지를 할당하지 않아도 된다. 물리적 스토리지는 물리적 공간의 공유 풀에서 필요할 때 호스트에게 할당된다. 공유 풀(shared pool)은 물리적 디스크로 이뤄진다. 가상화 프로비저닝의 공유 풀은 LUN을 만드는 드라이브의 집합인 RAID 그룹과 유사하다. RAID 그룹과 마찬가지로 공유 풀은 1개의 RAID 보호 레벨을 지원한다. 그러나 RAID 그룹과는 달리 공유 풀은 많은 개수의 드라이브를 포함할 수 있다. 공유 풀은 단일 종류이거나(단일 드라이브 유형) 여러 종류가 섞여 있을 수 있다. (플래시, FC, SAS, SATA 드라이브 등).

 가상화 프로비저닝은 좀 더 효율적으로 스토리지를 호스트에게 할당할 수 있다. 가상화 프로비저닝은 또한 실제 스토리지 어레이에서 사용 가능한 양보다 더 많은 용량을 할당할 수 있다. 공유 풀과 얇은 LUN은 호스트의 저장 공간 요청이 커짐에 따라 쉽게 확장할 수 있다. 스토리지 어레이에 여러 개의 공유 풀을 만들 수 있고, 공유 풀을 여러 얇은 LUN이 공유할 수도 있다.

 캐시는 전용 캐시 또는 글로벌 캐시로 구현할 수 있다. 전용 캐시는 별도의 메모리 공간을 읽기와 쓰기에 할당하는 것을 말한다. 글로벌 캐시는 읽기와 쓰기가 가능한 모든 메모리 주소를 사용할 수 있다. 글로벌 캐시에서는 글로벌 주소 집합만을 관리하면 되기 때문에 캐시를 효율적으로 관리할 수 있다.

 글로벌 캐시는 사용자가 읽기와 쓰기에 사용 가능한 캐시 비율을 저장할 수 있다. 보통 읽기 캐시는 작게 설정하는데, 애플리케이션이 읽기 연산을 많이 수행하는 경우에는 늘려야 한다. 그 밖의 글로벌 캐시 구현에서는 읽기와 쓰기에 사용할 수 있는 캐시 비율이 워크로드에 따라 동적으로 변화한다.

 캐시는 한정되고 비싼 리소스이기 때문에 잘 관리해야 한다. 최신 지능형 스토리지 시스템이 많은 캐시를 사용한다고 해도 모든 캐시 페이지를 사용한 후에는 새로운 데이터를 캐시에 저장하고 성능 저하를 막기 위해 캐시의 몇몇 페이지를 해제해야 한다. 지능형 스토리지 시스템에는 사용 가능한 페이지의 집합과 잠재적으로 필요시 해제할 수 있는 페이지의 목록을 관리하기 위한 여러 캐시 알고리즘이 구현돼 있다.

 다음은 가장 많이 사용하는 알고리즘이다.

- 최소 최근 사용(LRU, Least Recently Used)

캐시 데이터 액세스를 계속 관찰하고 오랜 기간 사용되지 않은 페이지를 찾아내는 알고리즘이다. LRU는 이 페이지를 해제하거나 재사용할 수 있다고 마크한다. 이 알고리즘은 한동안 사용되지 않은 페이지는 앞으로도 호스트가 요청하지 않을 것이라는 가정에 기초한다. 그러나 커밋되지 않은 데이터를 가진 페이지는 재사용하기 전에 먼저 디스크에 기록해야 한다.

- 최대 최근 사용(MRU, Most Recently Used)

이 알고리즘은 LRU의 반대로 가장 최근에 사용한 페이지를 해제하거나 재사용하도록 마크한다. 최근에 액세스한 데이터는 한동안 사용하지 앟을 것이라는 가정에 기초한다.

 캐시에 빈 공간이 없으면 더티 페이지(캐시에 기록된 후 디스크에 기록되지 않은 데이터)를 플러시해 사용 가능한 공간을 관리해야 한다. 플러시(flushing)는 캐시의 데이터를 디스크에 커밋하는 과정이다. I/O 액세스 속도나 패턴에 기초해 워터마크(watermark)라 불리는 상한/하한 레벨을 캐시에 설정해 플러시를 관리한다. 하이 워터마크 (HWM, high watermark)는 스토리지 시스템이 캐시 데이터를 빨리 플러시해야 하는 한도다. 로우 워터마크(LWM, log watermark)는 플러시를 멈추는 지점이다.

- 느린 플러시(idle flushing)

캐시 활용도가 하이 워터마크와 로우 워터마크 사이면 지속적으로 적당한 속도로 플러시한다.

- 하이 워터마크 플러시(high watemark flushig)

캐시 활용도가 하이 워터마크를 넘으면 발생한다. 스토리지 시스템은 플러시를 위한 추가 전용 리소스를 할당한다. 이 플러시는 I/O 처리에 영향을 끼친다.

- 강제 플러시(forced flushing)

갑자기 많은 I/O가 발생해 캐시를 100% 사용한 경우 실행한다. 강제 플러시는 좀 더 많은 리소스를 할당해 먼저 처리한다.

 캐시는 휘발성 메모리이기 때문에 전력이 끊기거나 어떤 캐시 자애가 발생하면 디스크에 커밋하지 않은 데이터를 잃게 된다. 캐시에 저장된 데이터를 잃을 위험을 줄이기 위해 캐시 미러링이나 캐시 볼팅을 사용한다.

- 캐시 미러링(cache mirroring)

캐시 기록을 독립적인 2개의 메모리 주소에 저장한다. 캐시 장애가 발생하더라도 쓰기 데이터는 미러에 데이터가 보존돼 있어 디스크에 커밋할 수 있다. 읽기는 디스크에서 캐시로 이관된다. 따라서 캐시 장애가 발생해도 디스크에서 데이터를 읽을 수 있다. 쓰기만 미러링하기 때문에 이 방법은 사용 가능한 캐시의 활용도를 높일 수 있다.

 캐시 미러링 방식에서는 캐시 일관성(cache coherency)을 유지해야 하는 문제가 발생한다. 캐시 일관성은 다른 두 캐시의 데이터가 항상 같아야 함을 말한다. 이를 보장하는 일은 어레이 운영 환경의 책임이다.

- 캐시 볼팅(cache vaulting)

전력 장애로 데이터를 잃을 수 있는 위험을 방지하는 여러 가지 방법이 있다. AC 전역이 복구될 때까지 배터리를 사용해 메모리에 전원을 공급하거나 캐시 컨텐츠를 디스크에 기록할 수 있다. 추가 전력도 끊긴 경우 배터리를 사용하는 것은 사용 가능한 옵션이 아니다. 이는 지능형 스토리지 시스템에서는 많은 양의 데이터를 여러 디스크에 기록해야 하기 때문에 배터리의 전력만으로는 부족하기 때문이다. 따라서 스토리지 벤더는 전력 장애 시 캐시의 컨텐츠를 덤프하기 위한 물리적 디스크를 사용한다. 이를 캐시 볼팅이라고 하며, 이 디스크를 볼트 드라이브(vault drive)라고 한다. 전력이 복구되면 이 디스크의 데이터를 다시 캐시에 기록하고 알맞은 디스크에 데이터를 기록한다.

 서버 플래시-캐싱 기술은 지능형 소프트웨어와 호스트의 PCI 익스프레스(PCIe, PCI Express) 플래시 카드를 사용한다. 이는 지연 시간을 줄이고 처리량을 늘려 애플리케이션의 성능을 극적으로 향상시킨다. 서버 플래시-캐싱 기술은 물리적 환경과 가상 환경에서 모두 동작하며 읽기가 많은 워크로드에서 성능 향상을 제공한다. 이 기술은 플래시 관리를 PCIe 카드에 이관함으로써 서버의 CPU와 메모리의 부하를 최소화 한다.

 서버의 PCIe 플래시에 어떤 데이터를 위치시켜 애플리케이션에 더 가깝게 함으로써 이득을 얻을 수 있늕 지능적으로 결정한다. 스토리지 어레이에 액세스하기 위한 네트워크 I/O의 지연 시간을 피할 수 있다. 이를 사용해 애플리케이션이 가장 최근에 사용한 데이터를 찾기 위한 프로세싱을 백엔드 스토리지에서 PCIe 카드로 이관할 수 있다. 따라서 스토리지 어레이는 좀 더 많은 프로세싱 파워를 다른 애플리케이션에 할당할 수 있다.

 지능형 스토리지 시스템은 프로트엔드, 캐시, 백엔드, 물리적 디스크라는 4개의 주요 요소를 갖는다. 호스트의 I/O 요청은 프론트엔드 포트에 도착해 캐시와 백엔드를 통해 처리돼 물리적 디스크로부터 데이터를 추출하거나 저장하게 된다. 요청된 데이터가 캐시에 있으면 캐시에서 바로 읽기 요청을 처리할 수 있다. 최신 지능형 스토리지 시스템에서는 프론트엔드와 캐시, 백엔드는 보통 단일 보드(스토리지 프로세서 storage processor 나 스토리지 컨트롤러 storage controller라고 함)에 집적된다.

 프론트엔드는 스토리지 시스템과 호스트 사이의 인터페이스를 제공한다. 이는 프론트엔드 포트와 프론트엔드 컨트롤러라는 2개의 컴포넌트로 구성된다. 보통 프론트엔드는 고가용성을 위해 여분의 컨트롤러를 갖고 있으며, 각 컨트롤러는 여러 개의 포트를 갖고 있어, 많은 호스트가 지능형 스토리지 시스템에 연결할 수 있다. 각 프론트엔드 컨트롤러는 스토리지 연결을 위해 파이버 채널이나 iSCSI, FICON, FCoE 등의 알맞은 전송 프로토콜을 실행하는 처리 로직을 갖고 있다.

 프론트엔드 컨트롤러(front-end controller)는 내부 데이터 버스를 통해 캐시와 데이터를 주고받는다. 캐시가 쓰기 데이터를 받으면 컨트롤러는 호스트에게 수신확인(acknowledgment) 메시지를 호스트에게 보낸다.

 캐시는 호스트의 I/O 요청 처리 시간을 줄이기 위해 데이터를 임시 저장하는 반도체 메모리를 말한다.

 캐시는 호스트가 회전 디스크나 하드 디스크 드라이브(HDD, hard disk drive)의 기계적 지연 시간을 기다리지 않게 해 성능을 향상시킨다. 회전 디스크는 지능형 스토리지 시스템에서 가장 느린 컴포넌트다. 회전 디스크의 데이터 액세스는 탐색 시간과 회전 지연 시간으로 인해 수 밀리초가 걸린다. 캐시에서 데이터를 액세스하면 밀리초 이하의 시간이 걸려 매우 빠르다. 지능형 어레이에서 쓰기 데이터는 먼저 캐시에 적재된 후 디스크에 기록된다.

 캐시는 캐시 할당의 가장 작은 단위인 페이지로 구성된다. 캐시 페이지의 크기는 애플리케이션 I/O 크기에 따라 결정된다. 캐시는 데이터 스토어(data store)와 태그 RAM(tag RAM)으로 구성된다. 데이터 스토어는 데이터를 저장하고, 태그 RAM은 데이터 스토어와 디스크에서의 데이터 위치를 추적한다.

 태그 RAM의 엔트리는 데이터의 캐시 위치와 디스크의 위치를 알려준다. 태그 RAM에는 더티 비트(dirty bit) 플래그가 있다. 이는 캐시의 데이터가 디스크에 커밋됐는지 알려준다. 여기에는 또한 최근 액세스 시간 같은 시간 관련 정보도 있다. 이 정보는 장기간 사용되지 않아 제거될 수 있는 캐시 정보를 판별하는 데 사용한다.

 호스트가 읽기 연산을 요청하면 스토리지 컨트롤러는 태그 RAM을 읽어 요청한 데이터가 캐시에 있는지 확인한다. 요청 데이터가 캐시에 있으면 이는 읽기 캐시 히트(read cache hit) 또는 읽기 히트라고 하며, 디스크 연산 없이 데이터를 바로 호스트에 전송한다. 이를 통해 호스트에게 매우 빠른 응답 시간을 제공한다(약 1밀리초). 요청 데이터가 캐시에 없으면 이는 캐시 미스(cache miss)라고 하며, 디스크로부터 데이터를 읽어야 한다. 백엔드가 디스크에 액세스해 요청 데이터를 가져온다. 이 데이터는 캐시에 저장되고 최종적으로 프론트엔드를 거쳐 호스트에게 전송한다. 캐시 미스는 I/O 응답 시간을 증가시킨다.

 시퀀셜 읽기 요청인 경우에는 프리페치(prefetch)나 미리 읽기(read-ahead) 알고리즘을 사용한다. 시퀀셜 읽기 요청은 연속된 블록을 가져온다. 호스트가 아직 요청하지 않은 다른 블록도 디스크에서 읽어와 캐시에 미리 저장한다. 호스트가 이후에 이 블록을 요청하면 읽기 히트가 발생한다. 이 과정은 호스트의 응답 시간을 상당히 감소시킨다. 지능형 스토리지 시스템은 고정된 크기나 변동 크기 프리페치 크기를 지원한다. 고정 크기 프리페치(fixed prefetch)에서는 지능형 시스템이 고정된 양의 데이터를 프리페치한다. 호스트 I/O 크기가 일정한 경우 사용한다. 변동 크기 프리페치(variable prefetch)에서는 스토리지 시스템이 호스트가 요청한 크기의 배수만큼의 데이터를 프리페치한다. 최대 프리페치 한도를 정해 프리페치로 인해 너무 많은 I/O가 발생하지 않게 한다.

 읽기 성능은 읽기 히트 비율(read hi ratio)이나 히트 비율로 측정된다. 이 비율은 전체 읽기 요청에서 읽기 히트가 발생한 비율이다. 읽기 히트 비율이 높을수록 읽기 성능이 향상된다.

 캐시를 사용하면 디스크에 직접 쓸 때보다 성능이 향상된다. I/O가 캐시에 기록되고 확인 메시지를 보내면, 디스크에 직접 기록할 때보다 훨씬 적은 시간이 걸린다(호스트의 관점에서). 시퀀셜 쓰기의 경우에도 캐시를 사용하면 작은 쓰기 연산을 합쳐 더 큰 데이터를 디스크에 전달함으로써 최적화할 수 있다.

 캐시를 사용한 쓰기 연산은 다음과 같이 구현된다.

- 후 기입 캐시(write-back cache)

캐시에 데이터를 저장하고 바로 호스트에게 응답메시지를 보낸다. 그리고 후에 여러 쓰기 데이터가 디스크에 커밋된다. 쓰기 연산에서 기계적인 디스크 지연 시간이 없어지기 때문에 응답 시간이 매우 빨라진다. 그러나 커밋되지 않은 데이터로 인해 캐시 실패가 발생하면 데이터를 잃을 수 있다.

- 연속 기입 캐시(write-through cache)

데이터를 캐시에 저장하고 바로 디스크에 저장하며 호스트에게 응답 메시지를 보낸다. 데이터가 바로 디스크에 커밋되기 때문에 데이터를 잃을 위험은 줄어든다. 그러나 디스크 연산으로 인해 쓰기 응답 속도가 길어진다.

 많은 데이터를 기록하는 I/O 같은 특정 상황에서는 캐시를 우회할 수 있다. 이런 구현에서는 I/O 요청의 크기가 쓰기 우회 크기(write aside size)라 불리는 지정한 크기를 넘어서면 바로 디스크에 기록해 쓰기 연산이 캐시 공간을 많이 사용하는 이을 방지한다. 이는 캐시 크기가 제한되고 캐시가 주로 작은 랜덤 I/O에 필요한 경우 많이 사용한다.