지난 TenG 주식회사의 Grid군의 이야기가 어떠했는지 모르겠다. 자동화를 위한 기술 요건으로 데이터 그리드, 저장장치 그리드, 데이터 프로비저닝 등 3가지를 설명했는데, 도움이 됐길 바란다. 이달에는 오라클 10g의 여러 기능 중 스토리지 그리드를 위한 기능인 ASM(Automatic Storage Management)을 집중적으로 알아보자.
“DBA는 지금 몹시 지쳐 있다”
오라클 10g가 제공하는 ASM 기능을 사용함으로써 DBA는 디스크 관리 I/O 튜닝 작업을 포함해 스토리지 관리를 아주 편리하게 이뤄낼 수 있고, 많은 시간을 절약할 수 있게 된다. 결국 DBA들로 하여금 좀 더 가치 있는 분야에 집중할 수 있도록 도와주는 것이다.
ASM은 데이터베이스 구성시 기본이 되는 디스크를 효율적으로 관리하기 위해 오라클 10g에서 새로 선보인 데이터베이스 서비스이다. ASM은 하나의 SMP 장비뿐만 아니라 클러스터를 구성하는 모든 노드들에 대해서도 지원이 가능하다. ASM이 관리하는 모든 디스크에 대해 업무 분산 작업을 자동적으로 처리해 줌으로써 특정 디스크에 로드가 집중되는 핫 스팟(hot spot) 현상을 최소화할 수 있으며 이로 인해 성능을 극대화할 수 있다. 또한 데이터가 디스크에 균등한 크기로 저장?관리되어 fragmentation 현상이 발생하지 않는다. 그리고 ASM이 관리하는 영역에서 새로운 디스크가 추가되거나 삭제될 때마다, 기존 데이터들에 대해 재구성 작업이 자동적으로 일어난다. 또한 ASM은 특정 데이터에 대한 복사본을 자기 자신의 디스크에 유지할 수 있기 때문에 소프트웨어 미러링 효과를 볼 수 있다.
이처럼 ASM은 데이터에 대한 안정성, 그리고 성능을 어떻게 유지할 것인가에 대해 상당히 유연하게 지정할 수 있다. ASM을 단순히 기존 파일시스템(Filesystem), RAW 디바이스와 같은 파일 저장소로 간과하면 큰 오산이다. 앞으로 자세히 언급하겠지만, ASM은 여타 디스크 솔루션 없이 스트립핑(striping)과 미러링(mirroring) 효과를 볼 수 있을 뿐만 아니라 자동적으로 데이터 구성을 재분배할 수 있는 기능을 제공해 줌으로써 더 이상 I/O 튜닝을 할 필요로 없게 만들고 있다. 또한 자체가 클러스터 파일시스템이기 때문에 하나 이상의 노드에 있는 다른 데이터베이스에 대해서도 통합 관리가 가능하다. DBA들은 더 이상 스토리지 관리를 위해 엄청난 시간을 투자할 필요가 없게 된 것이다.
또한 ASM을 사용하면 관리 복잡성이 없어진다. 즉, 스토리지 관리가 단순해지는 것이다. 매일 처리해야만 하는 스토리지 관리 항목이 줄어들거나 제거되며, 모든 애플리케이션 로드에 대해 자동적인 I/O 튜닝이 수행된다. 또한 생성되는 데이터 파일에 대해 의미 있는 이름이 자동적으로 부여되고, 파일시스템 상에 데이터 파일이 있는 것이 아니기 때문에 실수로 파일을 삭제할 가능성도 사라진다.
Logical volume manager와 파일시스템 기능이 데이터베이스에 포함되어 있기 때문에 스토리지 제품 구입 비용이 대폭 절감된다. 모든 파일에 대해서 RAW 디스크 수준의 I/O 성능을 보장하며, ASM 자체가 클러스터 파일시스템인 이유로 오라클 RAC(Real Application Cluster) 지원에도 아무런 문제가 없다.
ASM의 일반적 구조
ASM은 데이터베이스 커널의 한 부분으로 존재한다. 데이터베이스 인스턴스처럼 물리적으로 메모리를 차지하는 데몬들의 집합체인 것이다. 이를 ‘ASM 인스턴스’라 한다. ASM 인스턴스는 데이터베이스를 마운트(mount)하지 않고, 관계되는 데이터베이스 인스턴스에서 사용 가능한 데이터 파일에 대한 메타 데이터를 관리하는 역할을 담당한다. 데이터베이스 인스턴스는 ASM 파일을 직접 접근해 처리하고, 파일의 구조에 대한 정보가 필요할 때에만 ASM 인스턴스와 서로 통신하게 된다. ASM 인스턴스는 데이터베이스 인스턴스보다 훨씬 작은 메모리를 점유한다. 일반적으로 64MB 정도의 SGA만으로도 충분하다.
RBAL
디스크 그룹을 대상으로 데이터 재분배 작업을 감독하는 기능을 한다(디스크 그룹은 ASM이 디스크를 관리하는 논리적인 통합 개념이다).
ORB0#
실제 Data Extent를 옮기는 작업을 수행한다. 하나 이상이 존재할 수 있다.
데이터베이스 인스턴스의 새로운 background processes 'RBAL'
디스크 그룹에 속해 있는 디스크들이 노드에 있는 다른 데이터베이스 인스턴스에서 접근 가능하도록 유지한다.
ASMB
데이터베이스 인스턴스 상에서 동작하며, ASM 인스턴스의 Foreground 프로세스와 통신한다. 주기적인 메시지 교환을 통해 통계정보를 공유하고 양쪽 인스턴스가 제대로 동작하는가를 검증하는 역할을 한다. 데이터파일(Datafile) 생성과 같은 ASM 인스턴스의 간섭이 필요한 경우에, 데이터베이스 인스턴스의 Foreground 프로세스는 ASM 인스턴스와 직접 연결하여 해당 작업을 수행하게 된다.
ASMB는 ASM 인스턴스와 통신이 필요할 때마다 동적으로 띄워진다. 띄워진 후에 ASM 인스턴스와 연결되면, 이 연결은 ASM 인스턴스가 관리하는 디스크 그룹 내의 데이터파일을 데이터베이스 인스턴스가 요구치 않을 때까지 유지된다. 데이터베이스 인스턴스는 ASM 인스턴스와의 연결을 하나만 유지할 수 있다. 때문에 ASMB background 프로세스는 데이터베이스 인스턴스당 최대 하나만 있을 수 있는 것이다.
그리고 ASM 인스턴스가 shutdown이 되면, 데이터베이스 인스턴스 또한 영향을 받아 shutdown이 된다. 그러나 데이터베이스 인스턴스의 failure에 ASM 인스턴스는 영향을 받지 않는다.
RAC 환경에서의 ASM 인스턴스
RAC 데이터베이스처럼 ASM 인스턴스들도 자체적으로 클러스터링을 할 수 있다. 이는 이미 셋업이 되어 있는 DLM 체계를 사용해서 가능한 것이다. 일반적으로 클러스터를 이루는 하나의 노드에는 하나의 ASM 인스턴스가 뜨도록 구성한다. 그리고 RAC 구성처럼 ASM 인스턴스가 관리하는 디스크는 모든 노드에서 인식 가능하도록 구성해야 한다. 데이터베이스 인스턴스는 오직 동일 노드에 있는 ASM 인스턴스와 상호 통신하게 된다. 만약 동일 노드에 서로 다른 데이터베이스 인스턴스가 존재할 경우, 그들은 그 노드에 있는 하나의 ASM 인스턴스를 공유하게 되는 것이다.
특정 디스크 그룹은 서로 다른 데이터베이스 파일을 저장할 수 있다. 이처럼 RAC 환경이 아닌 상태에서 서로 다른 데이터베이스가 동일한 디스크 그룹에 접근하는 것이 가능하다. 또한 하나의 데이터베이스는 동일한 ASM 인스턴스에 의해 관리되는 여러 개의 디스크 그룹에 그 데이터베이스 파일을 저장할 수도 있다.
데이터 구조
이 글에서는 ASM이 스토리지를 관리할 때 사용하는 중요한 데이터 구조들에 대해 살펴보도록 하겠다.
디스크 그룹
ASM 디스크 그룹은 논리적인 단위로써 관리되는 디스크 집합체이며, ASM에서 고려되는 최상의 데이터 구조이다. 개별 디스크 그룹은 자신의 파일 디렉토리와 디스크 디렉토리 그리고 다른 메타 데이터를 포함하고 있다.
디스크의 크기에 비례하는 숫자의 Extent가 개별 디스크에 할당됨으로써 애플리케이션에 의해 발생되는 I/O 로드는 하나의 디스크 그룹에 속해 있는 모든 디스크에 골고루 분산된다. 이러한 기능으로 디스크 그룹의 디스크 공간이 없는 상태는 바로 모든 디스크가 데이터로 꽉 차있다는 것을 의미한다.
이렇게 균등하게 I/O 로드가 분산되어 처리되기 때문에 특정 디스크 그룹의 구성시 사용되는 디스크들은 크기가 비슷하고, 동등한 수준의 성능을 나타내는 것으로 지정해야 원하는 수준의 결과를 달성할 수 있다. 즉 가장 좋은 성능을 나타내는 디스크들을 모아 특정 디스크 그룹을 생성하고, 이 디스크 그룹에 애플리케이션에서 가장 중요한 데이터들을 저장하는 방법을 모색할 수 있는 것이다. 현재 ASM 디스크 그룹은 동시에 63개의 디스크 그룹을 마운트할 수 있다.
Failure Group
Failure group은 스토리지 리소스를 공유하는 디스크 그룹의 일부분이다. 여기서 말하는 ‘리소스’는 장애 발생시 함께 영향을 받게 되는 디스크들이 서로 공유하고 있는 리소스를 일컫는다. 예를 들어, 어느 디스크들은 SCSI 컨트롤러 1번에 연결되어 있고, 나머지 디스크들은 SCSI 컨트롤러 2에 연결되어 있다면, 전자의 디스크들은 Failure group 1이 되는 것이고, 나머지 디스크들은 Failure group 2에 속하게 되는 것이다. 즉 운명을 같이하는 디스크들의 집합체가 Failure group을 형성하는 것이다. 결과적으로 하나의 디스크 그룹은 여러 개의 Failure group으로 구성될 수 있다.
Failure group을 어떻게 지정하는가는 고객이 원하는 안정성의 수준이 무엇인가에 따라 상당히 다를 수 있기 때문에 사용자가 수동으로 지정?활용하는 것이 일반적이라 하겠다. 만약 디스크 그룹 생성시 Failure group을 지정하지 않는다면 ASM은 개별 디스크에 대한 Failure group을 자신의 디스크로 지정한다.
디스크 그룹을 생성할 때마다 DBA들은 그 디스크 그룹의 redundancy를 고려해야 한다. 즉, 데이터의 복사본을 어떻게 유지할 것인가를 판단해야 한다(데이터 미러링과 관계가 있다). 이는 다음과 같이 세 개로 분류해 지정된다.
[2] NORMAL REDUNDANCY : 2-웨이 미러링, 하나의 failure group에 장애가 발생하더라도 데이터 손실을 예방할 수 있는 방법이다. 이렇게 지정하기 위해서는 적어도 두 개의 failure group을 지정할 수 있어야 한다.
[3] HIGH REDUNDANCY : 3-웨이 미러링, 가장 높은 수준의 데이터 보호 방법이다. 두 개의 failure group에 장애가 발생하더라도 데이터 손실이 발생하지 않는다. 적어도 3개의 failure group을 지정해야 한다.
ASM Disk
하나의 디스크 그룹은 ASM 디스크의 집합체로 구성되는 것이다. 즉 디스크 그룹에 스토리지가 추가되거나 삭제될 때 ASM Disk 단위로 처리된다. 또한 데이터베이스 인스턴스에서 다이렉트 I/O가 가능한 물리적인 디스크여야만 한다.
ASM 디스크는 서로 다른 노드에서도 동일하게 인식되는 추상적인 이름을 갖고 있다. 즉 OS에서 디스크를 접근하기 위해 사용하는 이름과는 다르다. 이렇게 다른 이름을 유지하는 이유는 다른 노드들이 동일한 디스크에 대해서 상이한 OS 이름을 갖게 될 경우가 있기 때문이다. ASM 디스크 이름은 디스크가 추가될 때 관리자가 지정할 수도 있고, 지정하지 않으면 자동적으로 지정된다.
ASM 인스턴스가 디스크 그룹을 마운트할 때 정확한 ASM 디스크를 찾기 위해 관련 OS 이름들이 검색된다. 그리하여 개별 OS 이름과 ASM 디스크 헤더 정보의 맵핑 작업이 이뤄지고 어떤 ASM 디스크가 사용될 것인지를 결정하는 것이다. 앞의 맵핑 정보는 데이터베이스 인스턴스의 메모리에 저장?관리된다. OS 이름은 사전 경고 없이 변경될 가능성이 있기 때문에 ASM 디스크에 저장되지 않는 특성을 갖는다. ASM은 동시에 1만개의 디스크를 지원할 수 있다.
ASM Files
ASM File은 ASM 디스크 그룹에 저장되는 오라클 데이터파일이다. 파일이 생성될 때 미러링을 어떻게 할 것인지, 스트립핑은 어떻게 할 것인가에 대한 정보가 함께 적용된다.
ASM File은 OS에 의해 확인될 수 없으며, RMAN이나 다른 오라클 지원 툴에 의해 확인이 가능하다. OMF(Oracle Managed File)와 유사하다. OMF처럼 더 이상 필요치 않는 파일들은 자동적으로 제거된다. 생성?삭제?읽기?쓰기?크기 변경이 가능하고, 하나의 ASM 파일은 하나의 디스크 그룹에 분산 저장된다. 디스크 그룹을 이루는 개별 파일들이 모든 디스크에 분산 저장되기 때문에 하나의 디스크에 대한 백업은 유용하지 않다. 이 때문에 ASM 파일에 대한 백업은 RMAN을 통해서만 가능하다. 그러나 PL/SQL 인터페이스를 통해서 ASM File의 내용을 읽어내는 것은 가능하다.
ASM 파일의 특성1, 로드밸런싱
디스크 그룹에 있는 모든 디스크에 걸쳐서 데이터가 분산 저장되는 이유로 파일 접근 형태가 균형을 이루게 된다. 이러한 특성의 장점을 극대화하기 위해서는 동일한 성능을 나타내는 디스크들로 디스크 그룹을 구성해야 한다.
ASM은 디스크 그룹을 구성하는 모든 디스크에 걸쳐서 하나의 AU(Allocation Unit) 단위로 파일들을 분산시킨다. 이것을 ‘COARSE striping’이라고 한다. 이에 반해 개별 AU 단위를 더 작은 크기로 잘라 분산시키는 것을 ‘FINE striping’이라고 일컫는다. FINE 스트립핑은 일반적인 크기의 I/O 오퍼레이션을 더욱 더 작은 여러 개의 I/O 오퍼레이션으로 나눠 병렬로 처리하는 것이다.
ASM 파일의 특성 2, 미러링
RAID-1과 같은 형태처럼 ASM도 다중의 데이터 복사본을 유지함으로써 중요 데이터를 보호할 수 있다. 그러나 RAID-1과 다르게 파일 단위로 처리된다. RAID-1은 멤버들이 획일적인 알고리즘을 따르게 된다.
ASM 파일 타입
ASM 디스크 그룹 내에 저장될 수 있는 파일 형태는 다음과 같다.
◆ Control File, Datafile , Online Redo Log, Archive Log, Temporary data file
◆ RMAN backup piece, Datafile Copy, SPFILE, Disaster Recovery Configuration
◆ Flashback Log, Change Tracking Bitmap, DataPump Dumpset
그러나 Oracle 실행 모듈과 ASCII 파일, alert log/trace 파일들은 ASM 디스크에 저장될 수 없다.
ASM 파일 템플릿
ASM 파일 템플릿은 데이터파일 생성시 파일에 적용될 성질(redundancy,striping)을 다양하게 분류해 목록화한 형태를 말한다. 템플릿이 없다면 파일 생성시마다 개별 성질들을 지정해야 할 것이다. 성질 부여 작업을 간편하게 수행하기 위한 도구라고 생각하면 무리가 없겠다.
특정 템플릿은 하나의 디스크 그룹과 연결 관계를 갖는다. 서로 다른 디스크 그룹은 다른 성질을 갖고 있으면서 이름이 동일한 템플릿을 가질 수 있다. 새로운 디스크 그룹이 생성될 때 ASM은 그 디스크 그룹과 관계된 디폴트 템플릿을 생성한다. 이 디폴트 템플릿은 다양한 오라클 데이터파일 타입에 대한 기본적인 성질들을 포함하게 되는 것이다. 디폴트 템플릿의 성질 내용은 DBA에 의해 변경 가능할 뿐만 아니라 DBA는 새로운 템플릿을 만들 수 있다. 디폴트 템플릿은 삭제될 수 없다.
ASM 파일 생성 후 그 파일에 대한 성질을 변경하기 위해서는 RMAN을 통해 새로운 성질을 갖고 있는 파일로 복사해야 한다. 이것이 파일의 성질을 변경할 수 있는 유일한 방법이다. 템플릿을 정의하거나 변경할 때 COARSE/Fine-Grained 스트립핑 성질도 함께 지정한다. ASM 메타 데이터에 대한 redundancy/striping 성질은 ASM에 의해 사전 정의되기 때문에 이 값들은 템플릿을 통해서 변경이 불가능하다.
ASM 파일네임
ASM 파일네임은 다음과 같은 다양한 형태로 존재할 수 있다.
Fully Qualified ASM Filenames
존재하고 있는 ASM 파일을 참조하기 위한 형태이다. 이는 디스크 그룹 이름, 데이터베이스 이름, 파일 타입, 타입에 따른 태그 정보, 파일 넘버, 그리고 incarnation number를 가지고 ASM 파일을 표현한다. 이 형태는 ASM 파일이 생성될 때 자동적으로 지정된다. ‘Alias’를 사용해 ASM 파일이 생성된다고 하더라도 이러한 형태의 파일네임도 함께 지정된다. ASM은 파일 생성시 이 파일 형태를 사용하기 때문에 DBA는 파일 생성 문장에서 이 형태를 사용할 수 없다.
형태 : +
- 예제 : +dgroupA/db1/controlfile/CF.257.8675309
Numeric ASM Filenames
존재하고 있는 ASM 파일을 참조하기 위한 형태이다. 이는 디스크 그룹 이름, 파일 넘버, 그리고 incarnation 넘버 로 구성된다. ASM은 파일 생성시 파일/Incarnation 넘버를 내부적으로 사용하기 때문에 이 형태는 파일 생성시 사용될 수 없다. 이 형태는 Fully qualified name 형태에서 유추되며, 사용자에게 공개되지 않는다. 다만 존재하는 파일을 참조하기 위한 API를 통해 사용이 가능하다.
- 예제 : +dgroupA.257.8675309
Alias ASM Filenames
이 형태는 기존의 ASM 파일을 참조할 뿐만 아니라 새로운 ASM 파일을 생성할 때에도 사용될 수 있다. 파일과 Incarnation 숫자를 지정하지 않고, 단지 디스크 그룹 이름과 사용자가 임의로 지정하는 문자열로 이뤄진다. 즉, DBA가 자신이 구별하기 쉽도록 파일 참조 정보를 지정할 수 있는 것이다.
Alias Filename은 ‘/’ 문자를 갖는 디렉토리 구조를 사용한다. 이름을 이루는 각 항목들은 UTF-8 포맷을 따르며 48바이트 이상이 될 수 없다. 또한 모든 항목이 포함하는 문자열은 256바이트를 넘을 수 없다. 문자열 사이에 space 문자를 넣을 수 있으나, 대소문자를 구별한다는 것을 유념해야 한다.
예제1 : +dgroupA/myfiles/control_file1
예제2 : +dgroupA/A rather LoNg and WeiRd name/for a file
ASM File은 파일 생성시 Fully qualified name 형태를 따른다. DBA는 이때 alias를 사용하여 파일을 생성할 수도 있고, 추후 ‘ALTER DISKGROUP ADD ALIAS’ 명령어로 파일을 만들 수 있다.
Alias ASM Filenames with template
오직 ASM 파일을 생성할 때에만 사용되는 형태이다. 이는 디스크 그룹 이름, alias 이름, 그리고 파일에 대한 템플릿 이름으로 구성된다. 파일 생성시 이러한 형태가 지정되고, alias가 존재하는 파일을 가리킨다면 템플릿은 무시된다.
- 예제 : +dgroupA/config1(spfile)
Incomplete ASM Filenames
파일 생성시에만 사용되는 형태이다. 디스크 그룹 이름만으로 구성한다. 이를 위해 ASM은 해당 파일의 타입이 정의되어 있는 디폴트 템플릿을 사용한다.
예제 : +dgroupA
Incomplete ASM Filenames with template
파일 생성시에만 사용되는 형태이다. 디스크 그룹 이름과 템플릿 이름으로 조합된다. 템플릿은 파일에 적용되어질 여러 가지 성질을 결정하게 된다.
예제 : +dgroupA(datafile)
Allocation Unit
Allocation Unit(AU)는 디스크 그룹 내에서 저장 영역을 할당하고자 할 때 사용하는 기본적인 단위이자 개념이다. ASM 디스크 내에서 가용한 공간은 AU 크기의 배수가 되는 것이다. ASM 디스크의 헤더에는 이러한 AU에 대한 정보를 포함하고 있는 테이블이 존재한다.
_ASM_AUSIZE에 의해 변경하지 않는 이상 기본적으로 AU는 1MB이다. 이 크기는 하나의 ASM 파일이 여러 디스크에 골고루 분산되어 저장될 수 있을 정도로 작은 크기일 뿐만 아니라 하나의 I/O 오퍼레이션에 의해 처리되는 하나의 AU가 좋은 처리량을 보장할 수 있을 정도로 충분히 큰 크기로 생각되는 것이 일반적이다(오라클 SAME 방법론 참조). 또한 AU를 접근하는 시간은 AU가 시작되는 곳을 찾아가는 seek time보다 디스크의 전송속도에 지대한 영향을 받는다. 디스크 그룹에 대한 Rebalancing 작업은 이 AU 단위로 처리된다.
ASM 구성 및 관리
여기에서는 ASM을 어떻게 셋업하고, 어떠한 방법으로 관리할 수 있는가에 대한 내용을 다뤄보도록 하겠다.
사전 준비 작업
디스크 파티셔닝
실제적으로는 /dev/hda 디스크 하나가 존재하는 상황이지만, 이 디스크를 파티셔닝하여 여러 개의 디스크를 사용하는 것으로 고려할 수 있다.
RAW 디바이스 맵핑
오라클에서 사용 가능한 character 디바이스 형태를 만들어 준다.
Required Oracle option
ASM은 오라클의 특별한 옵션이 아니다. DBMS에 기본적으로 포함되어 있으며, 엔터프라이즈/스탠다드 에디션 모두에서 활용이 가능하다. ASM 인스턴스와 ASM 디스크 그룹은 DBCA를 통해 생성하는 것이다. 오라클 소프트웨어 설치시에 고려해야 될 사항은 없다.
스토리지 관리체계 선택
DBCA 수행 절차 중 다음과 같은 스토리지 관리 체계에 대한 선택 윈도우를 만나게 된다. 일반 파일시스템/ASM/RAW 디바이스, 이 중에서 오라클 데이터파일을 어디에 저장할 것인가를 결정하는 것이다. ASM 방법을 선택해 보겠다.
ASM 인스턴스 생성
DBCA는 서버에 기존 ASM 인스턴스의 존재 유무를 검색한다. 만약 존재한다면 존재하는 모든 ASM 인스턴스를 도식화해 주고 그들이 관리하는 모든 디스크 그룹을 나타낸다. 이런 경우 우리는 기존 인스턴스를 활용해 디스크 그룹을 생성할 수 있다. 존재하지 않는다면 새로운 ASM 인스턴스를 자동적으로 생성한다. 이때 ASM 파라미터 파일과 패스워드 파일이 더불어 만들어진다.
INSTANCE_TYPE = ASM
데이터베이스 인스턴스가 아니라 ASM 인스턴스임을 나타낸다.
LOCK_NAME_SPACE = +ASM
바로 이 이름을 갖는 ASM 인스턴스가 디스크 그룹을 관리함을 나타낸다. 이 이름은 하나의 노드의 다중 ASM 인스턴스가 공존할 때에만 변경할 필요가 있다.
ASM_POWER_LIMIT = 1
ASM의 주요 기능 중 하나인 Rebalancing의 속도를 조정하는 파라미터이다. 즉 Rebalancing을 수행하는 seval 프로세스들의 수를 말한다. 011 사이의 값을 지정할 수 있으며, 0은 Rebalancing 기능을 중단한다는 뜻이고 11은 가장 빠른 Rebalancing을 도모한다는 것이다. 생략된다면 기본적으로 11이 할당된다. Rebalancing을 수행하는 seval 프로세스들의 수는 수동으로도 지정이 가능하다.
ASM_DISKSTRING = /dev/raw/raw*
OS에 존재하는 모든 디스크 중에서 ASM에 의해 검색될 디스크를 표현한다. 즉 디스크의 범주를 제한하는 것이다. 새로운 디스크가 디스크 그룹에 추가될 때 이 값에 근거하여 ASM 인스턴스가 해당 작업을 수행하는 것이다. 지정되지 않는다면 ASM 인스턴스가 read/write 권한을 갖는 모든 디스크가 검색 대상이 된다.
ASM_DISK_REPAIR_TIME = 14400
디스크 그룹의 특정 디스크에 I/O 에러가 발생해 더 이상 디스크 그룹에 속하지 못함을 결정하는 기준을 시간으로 나타낸 것이다. 이 시간이 경과하면 자동적으로 해당 디스크는 디스크 그룹에서 떨어져 나간다. 0은 한계가 없음을 나타낸다. 디스크 그룹이 External redundancy 성질을 갖고 있다면 앞의 값은 아무런 의미가 없게 된다. 이 값은 DBA가 문제의 디스크를 찾아내어 문제를 해결할 수 있을 시간만큼 어느 정도 커야 합리적이지만 데이터의 안정성을 위해서는 작은 수치가 유리하다.
ASM_DISKGROUPS = FIRST,SECOND,THIRD
ASM 인스턴스가 startup될 때 마운트 되는 디스크 그룹의 이름들이다.
LARGE_POOL_SIZE = 12M
ASM 인스턴스가 사용하는 내부 패키지들은 LARGE POOL 영역에서 실행되기 때문에 8MB 이상의 값을 유지하는 것이 권고된다.
디스크 그룹 생성
그럼 First 디스크 그룹 지정(with NORMAL Redundancy)과 디스크 그룹 생성 확인을 <화면2>, <화면3>, <화면4>, <화면5>, <화면6>, <화면7>을 통해 살펴보자.
Grid군의 스토리지 관리를 위한 질문
TenG 주식회사의 Grid군은 새로운 통합 시스템의 데이터베이스를 ASM 영역에서 관리하게끔 설정해 놓은 상태이다. 오라클에서 새로 제시한 기능이고 또한 스토리지 관리를 자동화해 준다는 자료를 보고 서둘러 적용해 본 기능이었다. 포함되어 있는 기술의 다양성에 비해 설정은 아주 간단하다는 것을 느꼈지만, 실제 이 기능이 얼마나 자산의 업무에 도움을 줄 지는 미지수라 생각하고 있는 상태이다.
설정이 종료된 지 얼마 안 되어 사내에 신규 스토리지가 도입되었다. Grid군의 매니저는 새로운 스토리지로 해당 데이터베이스를 이전하라는 지시를 했으며, 더불어 최적화된 I/O 프로세싱을 위한 튜닝을 요구하고 있다.Grid군은 머리가 텅 빈 듯한 표정을 짓고 있다. 1테라바이트(TB)가 넘는 데이터를 새로운 스토리지로 옮겨야 한다니…. 그리고 그 어렵다는 I/O 튜닝? Grid군은 서둘러 오라클 엔지니어(채은 아빠)에게 전화를 걸었다. 이를 어떻게 처리해야 하는가에 대한 자문을 구하기 위해서였다.
데이터 이전은 어떻게 하나요 ?
Grid군 : 안녕하세요? 저는 Grid입니다. 지난 번에 알려주신 ASM 설정 방법에 따라 해당 기능을 적용해 놓은 상태입니다. 설정은 아주 쉽더군요. 그런데 새로운 스토리지로 데이터를 모두 옮겨야 하는 상황입니다. 물론 Transportable tablespace나 Export(Import) 방법도 생각해 봤으나 시간이 너무 오래 걸릴 것 같군요. 저희 시스템은 잠시라도 다운되어서는 안 되는 시스템인 거 알고 계시죠?
채은 아빠(오라클 엔지니어) : 설정이 쉬웠다구요? 맞습니다. DBCA 돌리면서 ASM 관련된 것만 클릭하면 오라클이 알아서 다 만들어 주죠. 데이터가 많았던 것으로 기억하는데, 디스크 그룹은 몇 개로 설정했나요?
Grid군 : 1테라가 조금 안됩니다. 편의를 위해서 디스크 그룹 하나에 모든 데이터를 관리하고 있습니다. 디스크 그룹에 속해 있는 디스크들이 크기도 비슷하고, 성능도 동일한 디스크이기 때문에 별도의 디스크 그룹을 설정할 필요성을 못 느꼈습니다.
채은 아빠 : 잘 하셨습니다. 데이터가 많은 경우 Transportable tablespace 기능을 고려해 볼 수도 있으나, 이 기능은 어느 정도의 서비스 중단을 초래하게 됩니다. 먼저 새로운 스토리지를 시스템에 장착하고 OS에서 인식하도록 조치하세요. 그런 후 ASM 인스턴스에서 새로운 스토리지를 기존 디스크 그룹에 추가하는 명령을 내리기 바랍니다.
Grid군 : 네, 명령을 내렸습니다. 이게 끝인가요?
채은 아빠 : 네
Grid군 : 네? 끝이라고요? I/O 작업이 일어나고 있군요. 무슨 작업이 일어나고 있는 것 같은데…,
채은 아빠 : 네, 동적으로 디스크들의 데이터가 재분배되는 작업이 일어나고 있는 것입니다. 즉, 이전 디스크들과 새로운 디스크들이 균등하게 데이터를 갖고 있게끔 데이터들이 이동하는 작업이 발생하고 있는 것이죠. 이 작업이 발생 중일 때에도 서비스는 계속될 수 있습니다. 작업이 종료되면 이전 디스크들을 드롭하는 명령을 내리세요.
Grid군 : 네, 작업이 빨리 진행되는 군요. 드롭 명령을 내렸습니다. 그러면 이전 디스크들에 있던 데이터들이 새로운 디스크들로 이전된다? 맞습니까?
채은 아빠 : 이해가 빠르군요. 맞습니다. 이렇게 간단한 명령어 두 개로 새로운 디스크들로 모든 데이터를 옮길 수가 있는 것입니다.
Grid군 : 고맙습니다. 저는 오늘 밤을 꼬박 새야 되는 줄 알았는데, 집에 빨리 갈 수 있을 것 같습니다.
I/O 튜닝은 어떻게?
Grid군 : 그리고 데이터는 옮겼는데, 이 데이터들에 대한 I/O 튜닝은 어떻게 해야 하는가요? 제가 I/O 튜닝은 안 해봐서….
채은 아빠 : ASM은 데이터가 저장되어 있는 모든 디스크들에 대해 스트립핑 기능을 제공하고 모든 데이터들이 골고루 분포되게 유지하려는 시도를 계속합니다. 그렇기 때문에 기존 방식에서 고려했던 핫-스팟 문제는 제기되지 않는 것이고, 결론적으로 I/O 튜닝은 필요 없게 됩니다.
Grid군 : 정말 고맙습니다. 이런 큰 작업에 부딪쳐 보니 ASM 기능을 더욱 실감나게 느껴볼 수 있었던 것 같습니다. 더 좋은 기능은 없나, 더 많은 공부를 해야겠습니다. 좋은 조언 감사드립니다. 그리고 홈페이지에서 봤는데 따님이 넘 귀엽고 예쁘던데요, 채은이?
창조적인 업무에 집중할 수 있는 여지를 만들자!
ASM 기능이 기존 디스크 솔루션이 제공했던 것을 완전히 대체하는 것은 아니다. 실제로 그 솔루션들의 기능이 10가지라면 ASM은 그것 중 몇 개만을 지원할 수 있는 수준일 것이다. 그러나 ASM은 오라클 I/O 프로세싱을 저렴한 가격으로 좀 더 효율적으로 처리할 수 있다는 데에는 의심의 여지가 없다고 판단된다. 복잡한 스토리지 관리를 한층 간편화시키고, 향상된 성능을 발휘할 수 있는 ASM을 한번 사용해 봄으로써 DBA들이 좀 더 창조적인 업무에 집중할 수 있는 여지를 만들어 줄 때가 아닌가 한다. @
지금 뜨는 기사
이시각 헤드라인
ZDNet Power Center
