Chapter 01. Automatic Storage Management in a Cloud World

클라우드 컴퓨팅은 다른 사람들에게 많은 것을 의미합니다.
대부분의 사람들의 클라우드 컴퓨팅 개념의 핵심에는 정보 기술의 민첩성, 확장성 및 비용 최소화에 관한 일련의 개념이 있습니다.
클라우드 컴퓨팅의 초기 지지자들은 IT가 전기와 매우 유사한 유틸리티로 보았습니다.
어느 정도까지, 모바일 플랫폼 공간에서, 그 비전은 현실이 되었습니다.
모바일 응용 프로그램의 비용은 결코 낮아진 적이 없으며 이러한 응용 프로그램에 데이터를 제공하는데 거의 보편적으로 접근 할 수 있습니다.
이 장의 초점은 클라우드 컴퓨팅이 Oracle 데이터베이스 환경에서 스토리지 관리에 미치는 영향입니다.
Oracle Database의 스토리지 관리에서 중요한 부분은 ASM (Automatic Storage Management)으로 알려진 데이터베이스 기능입니다.
ASM은 Oracle 데이터베이스용 통합 볼륨 관리자 및 파일 시스템입니다.
Oracle을 배치 할 때 오랜 관행이었던 호스트 기반 볼륨 관리자 및 파일 시스템 대신 사용됩니다.
ASM에는 데이터베이스 외부의 파일을 지원하는 파일 시스템의 볼륨 공간으로 ASM에서 제공하는 볼륨 관리에 의존하는 POSIX 호환 파일 시스템인 
ASM 클러스터 파일 시스템 (ACFS)이 번들로 제공됩니다.
이 책의 다음 장에서는 ASM 및 관련 기술의 현재 사용 가능한 기능에 중점을 둡니다.
이 장에서는 클라우드 컴퓨팅의 영향을 받은 최근의 많은 변경 사항과 향후 클라우드 컴퓨팅이 ASM에 미치는 영향에 대해 설명합니다.
 
초기
ASM은 Oracle9i 이전 버전에서 개발되었습니다. 이는 상용 클래스 클러스터 데이터베이스를 제공하는 RAC(Real Application Clusters) 데이터베이스 출시 이전이었습니다.
그러나 RAC가 된 제품은 이전에 Oracle Parallel Server 또는 단순히 OPS라고 불렸습니다.
ASM이 소규모 데이터베이스부터 다양한 요구 사항을 충족시킬 것으로 기대되었지만 Oracle 개발팀은 ASM이 OPS 및 데이터베이스 
인스턴스의 클러스터링에 중요 할 것으로 생각했습니다. 원래 ASM은 OPS와의 관계를 반영하여 Oracle Storage Manager (OSM)로 불렸습니다.
초기에는 대규모 Oracle 데이터베이스를 배포하는 고객을 위한 스토리지 관리가 다소 어려웠습니다.
고객인 경우 OPS를 배포하려면 NFS 기반 스토리지와 원시 연결 스토리지의 두 가지 옵션만 사용해야합니다.
Oracle의 클러스터된 데이터베이스 아키텍처는 클러스터에서 실행되는 모든 데이터베이스 서버가 모든 저장 장치에 액세스 할 수 있어야 하는 공유된 
모든 아키텍처이기 때문에 이러한 제한된 선택이 있었습니다.
또한 오라클의 공유-모든 아키텍처를 수용 할 수 있는 호스트 기반 글로벌 파일 시스템은 쉽게 사용할 수 없었습니다.
따라서 고객을 위한 스토리지 관리 선택은 네트워크 파일러가 제공하는 스토리지를 사용하거나 파일 시스템을 완전히 제거하고 중간 파일 시스템없이 
Oracle 데이터베이스 인스턴스가 직접 액세스 할 수 있도록 원시 볼륨을 배포하는 것입니다.
대부분의 고객은 파일 서버가 대형 데이터베이스의 경우 필요한 I/O 성능을 제공 할 수 없다고 인식하여 후자를 선택합니다.
오라클 데이터베이스의 원시 스토리지를 배치하면 우수한 스토리지 성능을 제공 할 수 있지만 데이터베이스 워크로드가 변경 될 때 데이터 레이아웃을 
유지 관리하는데 필요한 지속적인 스토리지 관리로 인해 높은 관리 오버 헤드가 발생합니다.
또한 데이터베이스 및 시스템 관리자는 일반적으로 데이터베이스 개체의 I/O 요구 사항을 저장소 장치의 I/O 기능과 일치시키기 위해 긴밀하게 협력해야했습니다.
스토리지 업계의 다른 곳에서는 공급 업체가 엔터프라이즈급 클러스터 인식 스토리지 관리 제품을 개발하기 시작했습니다.
가장 성공적인 공급 업체는 클러스터 인식 파일 시스템 및 논리 볼륨 관리자를 사용하는 Veritas입니다.
플랫폼 벤더들, 특히 IBM과 HP는 Veritas와 파트너쉽을 맺거나 클러스터 인식 스토리지 제품을 독자적으로 개발함으로써 이 분야에서 제품을 출시했습니다.
이러한 제품은 고객에게 중요했기 때문에 오라클은 이러한 공급 업체와 파트너 관계를 맺고 나중에 Oracle RAC가 될 Oracle Parallel Server에 대한 
요구 사항을 지원하는 실행 가능한 솔루션을 확보했습니다.
스토리지 관리를 간소화하기 위해 Oracle은 "Stripe and Mirror Everything"을 위해 SAME이라는 이니셔티브를 시작했습니다.
이 계획의 이면에 있는 아이디어는 단순하면서도 강력했습니다.
고객은 두 가지 원칙을 따르는 방식으로 데이터베이스 파일 시스템을 구성 할 것을 제안했습니다.
 
• 모든 디스크에서 모든 파일을 스트라이프합니다.
• 고 가용성을 위해 여러 디스크에서 파일 시스템 미러링
 
이전에는 고객이 각 데이터베이스 개체의 요구 사항에 맞게 많은 개별 파일 시스템을 최적화하는데 상당한 시간을 투자했습니다.
SAME 개념은 파일 시스템의 수를 줄임으로써 결과적으로 Oracle Database에 대한 스토리지 자원의 지속적인 조정을 단순화했습니다.
ASM의 핵심은 동일한 개념입니다. ASM은 모든 디스크에서 모든 파일을 스트라이프하고 선택적으로 파일을 미러링합니다.
소개를 통해 ASM은 기존의 파일 시스템 대안과 차별화 된 기능을 제공했습니다.
Oracle 데이터베이스 환경에 대한 스토리지 관리에는 일반적으로 운영 체제 기반 볼륨 관리자 및 파일 시스템이 포함됩니다.
파일 시스템 및 볼륨 관리자는 시스템 관리자가 가장 자주 관리하며 데이터베이스 관리자를 위해 파일 시스템을 설정합니다.
이는 시스템 관리자가 데이터베이스 관리자와 자주 상호 작용을 한다는 것을 의미합니다.
그러나 ASM은 데이터베이스 파일을 관리하는 데이터베이스 관리자 중심의 파일 시스템을 제공했습니다.
ASM에서 공간 관리 엔티티는 파일 시스템이라고 할 수 있는 디스크 그룹이라고 합니다. 
디스크 그룹은 대개 시스템 관리자가 아니라 데이터베이스 관리자의 권한입니다. 이것의 효과는 논리 공간이 관리되는 방식을 변경했기 때문입니다.
이 변경으로 인해 시스템 관리자는 디스크 그룹을 채우는 물리적 볼륨을 계속 제공하지만 DBA는 데이터베이스가 의존하는 파일 시스템인 디스크 그룹을 관리해야합니다.
또한 ASM은 본질적으로 디스크 그룹 내에서 Stripe and Mirror Everything 개념을 구현하기 때문에 시스템 관리자가 이전에 요구했던 관리 오버 헤드를 제거합니다.
기존 파일 시스템과 달리 ASM은 Oracle 데이터베이스와 통합되어 있습니다. 
이러한 통합은 기존의 파일 시스템에서는 불가능했던 최적화를 제공합니다.
데이터베이스와 마찬가지로 ASM은 단순히 메모리 영역을 공유하는 프로세스 모음인 인스턴스를 사용합니다.
ASM 인스턴스는 파일 블록의 위치를 ​​실제 저장 영역 위치에 맵핑하는 파일 메타 데이터를 담당합니다.
그러나 데이터베이스가 I/O 작업을 수행 할 때, 해당 작업은 ASM 인스턴스를 거치지 않습니다.
데이터베이스는 저장 장치에 직접 I/O를 실행합니다. 
기존의 파일 시스템에서는 데이터베이스가 I/O 작업을 수행 할 때 해당 작업이 파일 시스템의 계층에서 처리됩니다.
이것을 설명하는 또 다른 방법은 기존의 파일 시스템과 달리 ASM이 데이터베이스와 스토리지 간의 I/O 경로에 있지 않다는 것입니다.
아마도 ASM의 가장 중요한 측면은 RAC 또는 Real Application Clusters와 잘 작동한다는 것입니다.
Oracle Release 11.2부터는 클러스터의 각 노드에 ASM 인스턴스가 있습니다. 모든 데이터베이스 인스턴스는 해당 노드에서 작동하는 ASM 인스턴스에 따라 다릅니다.
노드에서 데이터베이스와 ASM 인스턴스 간의 통신은 효율적입니다.
또한 클러스터 내의 모든 ASM 인스턴스는 해당 작업을 조정하고 해당 클러스터를 사용하는 관련 데이터베이스에 대한 공유 디스크 그룹 공간의 관리를 제공합니다.
클러스터에서의 관리 및 효율성의 단순성 때문에 ASM for RAC의 사용은 상당히 높으며 점유율 85% 이상으로 간주됩니다.
 
First Release of ASM and Beyond
ASM 출시 이후의 첫 번째 릴리스
 
Automatic Storage Management는 Oracle 10g에서 소개되었습니다.
개발 관점에서 이 릴리스는 2003년 9월 Oracle Open World 컨퍼런스에서 발표되었습니다.
이 행사에서 Larry Ellison은 그리드 컴퓨팅에 대해 이야기하고 Real Application Clusters가 메인 프레임의 
안정성과 성능을 비용 대비 단 시간에 제공하는 방법을 설명했습니다.
당시 Charles는 개발 당시 부사장이었던 Rozwat씨가 ASM을 시연하면서 기조 연설을 했습니다.
ASM은 Oracle 데이터베이스의 스토리지를 관리하는 방식을 근본적으로 변화 시켰으며, 이 사실로 인해 우리 모두는 
ASM의 가치를 고객 및 스토리지 파트너에게 제시하는데 매우 적극적이었습니다.
초기 제품 관련 활동은 ASM 생태계의 개발로 잘 묘사됩니다. 개발팀은 ASM의 가치 제안을 오라클 고객에게 제시하는 스토리지 공급 업체를 만났습니다.
초기에는 파트너의 스토리지 배열에 대한 성능 측정 및 호환성 테스트가 있었습니다. 오라클과 스토리지 어레이 벤더는 
ASM이 장비를 통해 원활하게 작동하는지 확인했습니다.
이러한 측정 결과를 바탕으로 스토리지 하드웨어와 함께 ASM을 사용하기위한 베스트 프랙티스 절차가 문서화 되었습니다.
이러한 노력 중 하나는 ASM 환경에서 씬 프로비저닝의 유효성 검사를 이끌어 냈습니다.
오라클은 씬 프로비저닝 선두 업체인 3Par와 협력하여 씬 프로비저닝 스토리지와 ASM 간의 호환성을 설명했습니다.
ASM은 Oracle 데이터베이스용 통합 볼륨 관리자 및 파일 시스템을 제공합니다.
Oracle 데이터베이스는 엔터프라이즈 고객을 위한 가장 중요한 스토리지 배포 중 하나 일 가능성이 있지만 스토리지의 유일한 소비자는 아닙니다.
분명히 모든 고객은 스토리지가 필요한 응용 프로그램 및 비 관계형 데이터를 가지고 있습니다.
이것은 ASM 사용자가 오라클 데이터베이스와 다른 모든 것 사이에서 스토리지 관리를 단편화해야한다는 것을 의미합니다.
결과적으로 ASM 개발 팀은 ASM을 고객의 모든 데이터 요구에 대한 범용 스토리지 관리를 위한 플랫폼으로 활성화하는 것이 정말 유용 할 것이라는 아이디어를 내놓았습니다.
이 개념은 다음 주요 ASM 개발 포커스의 토대가 되었습니다.
오라클은 VMS 운영 체제에서 파일 시스템 작업을 수행 한 전체 개발 팀을 고용하여 ASM의 다음 주요 진화 단계를 제공하는 그룹이 되었습니다.
데이터베이스 환경 외부에서 관리되는 데이터를 확장하려면 POSIX 호환 파일 시스템이 ASM 디스크 그룹에 상주하는 스토리지를 활용할 수 있어야했습니다.
이 기능을 제공하기 위한 아키텍처는 두 부분으로 나뉘어 있습니다.
첫 번째는 ASM 파일을 파일 시스템이 상주하는 논리 볼륨으로 노출하는 기능입니다.
두 번째 부분은 노출된 논리 볼륨을 활용하는 클러스터 파일 시스템입니다.
ASM 파일을 파일 시스템 볼륨으로 노출시키는 것은 ASM 파일이 데이터베이스를 대상으로하기 때문에 일반적으로 상당히 큽니다.
이 기능을 제공하는 구성 요소를 ASM ADVM (장치 볼륨 관리자)이라고합니다.
볼륨 확장 레이아웃 메타 데이터를 얻기 위해 ASM 인스턴스와 통신하는 로드 가능한 운영 체제 모듈입니다.
ADVM은 익스텐트 맵 메타 데이터에 표현된 스토리지 공간을 운영 체제의 논리 장치로 제공합니다.
마지막으로, ADVM은 "클러스터를 인식"합니다. 즉, 클러스터 전체에 일관된 논리 볼륨을 제공 할 수 있습니다.
ASM 스토리지 관리를 확장하는 두 번째 부분은 ADVM에서 제공하는 스토리지 공간을 활용하여 클러스터 파일 시스템을 개발하는 것입니다.
이 구성 요소를 ASM 클러스터 파일 시스템 (ACFS)이라고합니다.
이는 10장에서 설명하는 다양한 기능을 구현하는 POSIX 호환 클러스터 파일 시스템입니다.
ADVM과 ACFS를 함께 사용하면 데이터베이스를 넘어서서 HPUX를 제외한 모든 Oracle 플랫폼에서 사용할 수 있는 스토리지 관리 플랫폼을 구현할 수 있습니다.
HPUX는 현재 해당 환경의 드라이버 개발에 필요한 HPUX 내부 정보가 부족하기 때문에 사용할 수 없습니다.
ADVM과 ACFS는 Oracle의 11.2 릴리스에서 사용 할 수 있게 되었습니다.
이것은 ASM 디스크 그룹에 Oracle Clusterware 파일을 지원하는 기능을 포함하는 ASM의 주요 릴리스였습니다.
오라클의 Clusterware는 "Voting 디스크" 및 Oracle Clusterware Repository (OCR)라고하는 두 가지 중요한 스토리지 구성 요소를 지원합니다.
이전에는 이 두 엔티티를 전용 저장 장치에 저장해야했습니다.
11.2가 출시되면 Clusterware 파일을 ASM 디스크 그룹에 보관할 수 있으므로 관리상의 주요 과제를 해결할 수 있습니다.
ASM은 Oracle Clusterware에 의존하기 때문에 이 기능은 약간의 마법이지만 Clusterware 파일은 이제 ASM에 있습니다.
닭고기 및 달걀 문제냐는 완전히 해결되었습니다.
ASM은 Oracle Clusterware 및 Real Application Clusters와 밀접한 관련이 있습니다.
ASM은 단일 인스턴스 데이터베이스에 많은 이점을 제공하지만 Oracle 데이터베이스 (즉, RAC)의 클러스터링된 버전은 ASM이 대부분의 용도를 보는 곳입니다.
이러한 이유로 ASM은 이제 ACFS/ADVM 및 Oracle Clusterware와 함께 Grid Infrastructure라는 패키지에 번들로 제공됩니다.
ASM과 ACFS를 비 RAC 환경에 설치할 수 있지만 Grid Infrastructure 번들링은 RAC를 사용하는 고객이 설치를 하는데 있어 단순화되었습니다.
 
클라우드는 모든 것을 바꿉니다.
"클라우드" 또는 클라우드의 활성화는 IT 업계뿐만 아니라 일상 생활에서도 혁신적인 영향을 미쳤습니다.
이 섹션에서는 개인 데이터베이스 클라우드 및 특히 ASM에 영향을 주는 클라우드 컴퓨팅에 대해 설명합니다.
 
클라우드란?
이 장은 클라우드 컴퓨팅에 대한 정의를 암시하여 시작되었습니다.
많은 기업들이 제품 및 기능을 "클라우드 사용"("클라우드 화"라고 부르는 것)으로 재 분류했지만 
클라우드 모니 커는 제품 기능 및 고객이 원하는 것에 관해 진정한 의미를 부여합니다.
이 정의의 핵심은 기존 제품에 비해 향상된 확장성, 민첩성 및 비용 절감에 대한 고객의 요구입니다.
클라우드 활성화는 일반적으로 소비자 및 비즈니스 응용 프로그램을 다른 곳에서 관리되고 액세스가 
일반적으로 인터넷 인 네트워크를 통해 제공되는 불투명 한 인프라로 변환하는 것을 의미합니다.
클라우드 애플리케이션 및 관련 인프라는 대부분 변경 요구 사항을 충족시킬 수있는 무한한 리소스가 
있으며 사용하는 제품에 대해서만 비용을 지불한다는 인식하에 제 3자가 관리하는 것으로 간주됩니다.
전기 유틸리티는 종종 완벽한 은유로 사용됩니다.
물론, 사회적 영향으로 인해 클라우드 컴퓨팅의 더 중요한 영향은 최종 소비자에게 있습니다.
그러나 여기에있는 질문은 일반적으로 Oracle 데이터베이스와 ASM 기능에 대한 클라우드 컴퓨팅의 
의미는 무엇입니까? 이 질문은 클라우드 컴퓨팅 동향, 엔터프라이즈 관계형 데이터베이스의 요구 사항 및 
후자의 질문에 대한 스토리지 관련 측면이 향후 제품 진화에 미치는 영향을 조사하여 검사합니다.
 
클라우드의 관계형 데이터베이스
오라클 스토리지 관리에 대한 클라우드 컴퓨팅의 영향을 조사하기 위해 오라클 고객의 환경과 요구 사항을 고려해야합니다.
오라클의 최대 고객은 오라클 데이터베이스를 기반으로 비즈니스 핵심 애플리케이션을 배포합니다.
이러한 데이터베이스가 실패 할 경우 기본 응용 프로그램에 미치는 영향이 비즈니스에 심각한 영향을 미칠 수 있는 경우가 종종 있습니다.
오라클 고객은 일반적으로 기업 애플리케이션 및 기본 인프라의 운영을 관리하는 팀을 보유하고 있습니다.
특정 응용 프로그램을 타사에 아웃소싱하여 일부 고객에게 비용 절감 기회를 제공 할 수 있는 경우입니다.
이러한 사례는 Salesforce.com 시장과 오라클의 호스팅 비즈니스에서 볼 수 있습니다.
그러나 이 논의에서 초점은 데이터베이스 및 관련 스토리지 관리 고객 요구 사항과 관련됩니다.
비즈니스 연속성은 이러한 환경의 가동 시간에 따라 달라지기 때문에 더욱 중요한 응용 프로그램 환경은 운영의 연속성을 보장하는 중복 인프라를 배포합니다.
이러한 회사는 필요한 자원을 공급하기 위해 세 번째 계획에 의존 할 수 없습니다.
배포 모델을 설명 할 때 가장 자주 사용되는 설명은 공용 클라우드 컴퓨팅과 개인용 클라우드 컴퓨팅입니다.
공개 클라우드 컴퓨팅은 공용 인터넷을 통해 응용 프로그램에 대한 액세스를 제공하는 타사 공급자에 대한 전체 응용 프로그램의 아웃소싱으로 생각할 수 있습니다.
명백한 고객은 데이터베이스와 같은 응용 프로그램의 인프라 요소에 인터넷을 통해 액세스 할 수 있습니다.
그러나 여기서의 목적은 클라우드 컴퓨팅이 사설 클라우드 컴퓨팅인 퍼블릭 클라우드 컴퓨팅의 역전에 미치는 영향에 초점을 맞추는 것입니다.
사설 클라우드 컴퓨팅은 클라우드 컴퓨팅의 가치를 전달하는 수단이지만 기업이 관리하는 네트워크와 컴퓨팅 인프라 스트럭처를 통해 제공됩니다.
사설 클라우드의 단점은 고객이 공용 클라우드를 통해 제공 할 수 있는 비용보다 기업의 비용이 높지만 중요 요소의 보안 및 배치를 제어 할 수 있다는 것입니다.
다음 논의를 위해 기업의 사설 클라우드를 단순히 엔터프라이즈 클라우드 컴퓨팅이라고합니다.
엔터프라이즈 클라우드에서 Oracle 데이터베이스를 관리한다는 것은 무엇을 의미합니까? 
엔터프라이즈 클라우드 모델로의 변경은 주로 데이터베이스와 기본 인프라가 관리되는 방식입니다.
기존 모델에서는 별도의 응용 프로그램과 데이터베이스가 수직적으로 배포됩니다.
즉, 새로운 응용 프로그램 및 지원 인프라가 자체 하드웨어 스택에 포함됩니다.
 
엔터프라이즈 클라우드 모델에서 새 응용 프로그램 및 데이터베이스는 전용 플랫폼 및 소프트웨어 
인프라에 배포되지 않지만 다른 응용 프로그램과 플랫폼을 공유 할 수 있습니다.
이러한 공유를 지원하는 하나의 모델은 소프트웨어 구성 요소에 의한 소비자의 논리적 분리를 통해 
여러 소비자가 소프트웨어 구성 요소를 공유하는 것을 의미하는 multitenance입니다.
데이터베이스와 관련하여 다중 테넌트 (multitenancy)의 예는 각 응용 프로그램이 자체 스키마와 
데이터베이스 인스턴스를 포함하는 여러 응용 프로그램에서 단일 데이터베이스 인스턴스를 공유하는 것입니다.
엔터프라이즈 클라우드를 만드는 데 사용되는 또 다른 아키텍처 도구는 서버 가상화입니다.
엔터프라이즈 클라우드의 서비스에 사용되는 가상화의 예로는 기업이 여러 플랫폼에 여러 응용 프로그램과 
관련 인프라를 배포하지만 각 응용 프로그램 환경은 자체 가상 서버 이미지에서 작동하는 서버 가상화입니다.
엔터프라이즈 클라우드 환경을 구축하기 위한 이러한 접근 방식의 장점에 대한 공개 토론이 있지만 
오라클의 관점에서 이러한 트렌드를 지원하는 제품 기능을 둘러싼 개발에 많은 관심이 있습니다.
 
개념적 차원에서 엔터프라이즈 클라우드를 만드는 고객을 지원하기 위해 진화 할 오라클 데이터베이스와 관련하여 적어도 네 가지 제품 개발 영역이 존재합니다.
• 대규모 클러스터링: 엔터프라이즈 클라우드는 가단성이 있으며 변화하는 응용 프로그램 요구에 따라 확장 또는 축소 할 수있는 IT 리소스 모음입니다.
오라클 데이터베이스 관점에서, 이러한 유연성은 데이터베이스 클러스터링과 함께 제공됩니다. 
엔터프라이즈 클라우드는 기업이 쉽게 관리 할 수있는 더 큰 규모의 서버 및 스토리지 클러스터에 대한 필요성을 증가시킬 것을 요구합니다.
• 대규모 플랫폼 공유: 클러스터 내에서 작동하는 까다로운 애플리케이션을 위해 데이터베이스 서비스를 확장해야 할 필요가 있는 한, 
단일 서버에서 덜 까다로운 애플리케이션을 위해 데이터베이스 인스턴스를 효과적으로 공유해야한다는 요구 사항이 있습니다.
이러한 공유를 제공하는 기술의 예로는 데이터베이스 멀티 테넌시 및 서버 가상화가 있습니다.
• 효율적인 클러스터 재구성: 클러스터링과 관련된 엔터프라이즈 클라우드는 하나의 큰 단일 클러스터가 아니라 많은 별도로 관리되는 클러스터입니다.
엔터프라이즈 클라우드는 변화하는 요구 사항에 맞게 이러한 클러스터 모음을 쉽게 재구성해야합니다.
구성 요소 오류의 결과 인 계획되지 않은 재구성도 있습니다.
결과적으로 클러스터 재구성은 가능한 한 응용 프로그램에 원활하고 투명해야합니다.
• 엔터프라이즈 클라우드 관리 모델: 기업의 클라우드 컴퓨팅은 기술 변화에 따른 관리 사고 방식과 관련하여 많은 변화가 있습니다.
엔터프라이즈 클라우드 관리 모델은 IT가 구성 요소가 아닌 일련의 서비스를 제공하는 것으로 생각합니다.
예상 서비스가 SLA (Service Level Agreement)에서 합의한대로 제공되는 한 비즈니스 응용 프로그램이 실행되는 최종 사용자에게는 아무런 문제가되지 않습니다.
즉, 엔터프라이즈 클라우드를 관리하는 직원은 SLA가 제공되고 서비스가 적절히 청구되도록 보장하는 도구가 있어야합니다.
기업에서 클라우드 컴퓨팅과 관련된 주요 요구 사항은 앞으로 몇 년 동안 제품 개발을 주도 할 것입니다.
다음으로 이러한 요구 사항이 ASM 발전에 어떻게 영향을 주는지 살펴 보겠습니다.
 
클라우드 안에서 ASM
ASM은 원래 오라클 데이터베이스에 사용된 스토리지와 관련된 관리상의 어려움을 줄이기 위해 고안되었습니다.
그러나 ASM으로 구현된 원래 접근 방식은 데이터베이스 외부의 스토리지 및 데이터를 관리하는데 사용할 수 없다는 것을 의미했습니다.
ASM의 두 번째 주요 개발 단계는 ASM's 스토리지 관리 모델을 데이터베이스 외부의 데이터로 확장한 ACFS를 가져 왔습니다.
엔터프라이즈에서의 클라우드 컴퓨팅은 ASM이 오라클 데이터베이스와 원격으로 연결된 모든 요소에 대한 스토리지 관리의 토대가 될 가능성이 높습니다.
클라우드 컴퓨팅은 애플리케이션 및 지원 인프라가 서버 및 클러스터 내에서 그리고 서버 및 클러스터 전반에서 유연해야한다는 것을 의미합니다.
고립된 플랫폼에 묶여있는 스토리지 관리가 이러한 유연성을 저해합니다.
 
공통 스토리지 관리
스토리지 관리는 엔터프라이즈에 대해 글로벌해야합니다.
아키텍처 관점에서 볼 때, 글로벌 스토리지 관리는 스토리지 레벨 또는 호스트 레벨에서 수행 될 수 있습니다.
극단적인 경우 스토리지 수준에서의 글로벌 스토리지 관리는 EMC 및 Network Appliance에서 제공되는 것과 같은 
스토리지 배열 제품을 통해 스토리지를 완전히 관리하고 응용 프로그램 및 인프라에서 사용할 수 있음을 의미합니다.
호스트에서의 글로벌 스토리지 관리는 물리적 스토리지에 대한 예상이 줄어들고 스토리지 관리가 주로 기업 관리와 
관련된 글로벌 관리 구조를 제공하는 호스트 관리 구성 요소에 의해 제공된다는 것을 의미합니다.
ASM/ACFS는 호스트 기반의 글로벌 스토리지 관리의 한 예이며, 시간이 지남에 따라 애플리케이션 
데이터와 관리 할 뿐만 아니라 하나의 경계를 넘어 더 많은 관리 범위를 제공하도록 확장 될 것입니다.
ASM/ACFS는 엔터프라이즈 클라우드를 위한 공통 스토리지 및 데이터 관리 플랫폼이 될 것입니다.
 
엔터프라이즈 클라우드 내구성
ASM이 엔터프라이즈 급 스토리지 및 데이터 관리를 위한 효과적인 플랫폼이되기 위해서는 
이전 섹션에서 설명한 네 가지 제품 개발 영역에 적응해야합니다.
ASM 진화에는 대규모 클러스터에 대한 지원 확대가 포함될 것으로 예상됩니다.
예를 들어, 클러스터 크기가 커지면 ASM은 경합 및 재구성 오버 헤드로 인해 발생할 수 있는 성장에 문제가 되지 않습니다.
모든 호스트 기반 글로벌 스토리지 관리 구성 요소에는 공유 리소스에 액세스하기 위한 몇 가지 형식의 직렬화가 필요합니다.
이것은 일반적으로 전역 lock 관리자를 포함합니다.
클러스터 크기가 커지면 락에 대한 경합이 증가합니다.
효과적으로 구현되지 않으면, 이 경합은 가장 큰 규모의 규모을 방해 할 수 있습니다.
관련 ASM 발전은 클러스터 재구성 비용과 관련이 있습니다.
계획된 또는 계획되지 않은 오버 헤드는 관리 요소를 재구성하고 클러스터의 모든 활성 구성원과 
연관된 메타 데이터를 업데이트하는 것과 관련되어 클러스터가 재구성 될 때마다 발생합니다.
엔터프라이즈 클러스터와 같은 대규모 클러스터는 클러스터 재구성 이벤트 빈도가 훨씬 높다는 것을 의미합니다.
ASM은 이 오버 헤드를 최소화 할 뿐만 아니라 재구성 이벤트의 영향을 받을 수 있는 서비스에 대한 
영향을 제한하도록 진화 할 것으로 예상됩니다.
 
엔터프라이즈 클라우드 정책 관리
클라우드 컴퓨팅 환경은 비 클라우드 환경보다 훨씬 동적입니다.
클러스터의 구성원은 자주 변경되며 스토리지 관리 인프라는 이러한 빈번한 변경 사항에 신속하게 적응해야합니다.
또한 스토리지 관리에는 프로비저닝이 필요하며 성능 및 안정성 측면에서 서비스 수준을 폭넓게 제공해야합니다.
사용 가능한 스토리지 기능과 지속적으로 변화하는 요구 사항을 맞추면 관리하기 어려운 환경이 발생할 수 있습니다.
 
클러스터 간 공유
일반적인 엔터프라이즈 클라우드에는 많은 별도 클러스터 환경이 포함될 가능성이 큽니다.
별도의 클러스터 환경은 고도로 독립적이며 다양한 서비스 레벨을 필요로하는 워크로드간에 결함 및 성능 격리를 제공합니다.
그러나 이러한 분리에도 불구하고 클러스터 간의 데이터 액세스를 공유해야 할 필요가 있습니다.
이에 대한 예는 프로덕션 환경과 동일한 응용 프로그램의 테스트 및 개발 환경 사이에 필요한 분리입니다.
테스트 및 개발 환경은 프로덕션 환경과 분리되어 있지만 테스트 환경에서는 프로덕션 환경에 대한 액세스가 제어되어야 할 수도 있습니다.
이렇게하면 데이터의 클러스터 간 액세스가 가능하도록 ASM에 대한 요구 사항이 적용됩니다.
이것은 Oracle 11.2에서 쉽게 사용할 수있는 것은 아니지만 향후 요구 사항이 될 것입니다.
 
요약
클라우드 컴퓨팅은 비용을 줄이고 사용률을 개선하며 효율성을 향상시켜야 할 필요성에 의해 주도되었습니다.
이 클라우드의 중심에는 사설 데이터베이스 클라우드가 있습니다.
Oracle ASM은 모든 파일 및 컨텐츠 유형을 지원하므로 Oracle Private Database 클라우드 이동의 핵심 구성 요소가 되었습니다.