[14] ASM 환경에서 ASM 인스턴스, ASMB, RBAL, ARB에 대한 가벼운 정리

들어가기에 앞서


ASM 자료 조사 시에 찾은 유용한 자료들을 먼저 소개합니다.

  • 굳어스 ASM 정리 자료 (기본 개념 정리부터 동작원리 및 테스트까지 정리가 잘 되어있습니다)
  • ASM FAQ 자료 (FAQ 형식으로 정리한 자료입니다. 아주 간단 명료하게 설명이 잘되어있습니다)
  • ASM 인터널 자료 : 구글에서 “A closer Look inside Oracle ASM – Luca Canali – CERN” 검색 후 나오는 첫 번째 PPT 자료

ASM 자료들은 대부분 오래된 자료들입니다. 하지만 ASM 아키텍처의 변화가 크지 않았다는 점을 고려하면 아직도 유용한 자료라고 생각됩니다. 따라서 ASM 학습 시에 숙지하면 좋은 내용들입니다. 이번 포스팅에서는 기존 자료의 내용을 중복해서 다루기보다는 제가 궁금했던 몇 가지 사항들을 정리해보려고 합니다.

질문1. ASM 인스턴스는 무엇이고, 반드시 필요할까요?


ASM(Automatic Storage Management)을 처음 접할때 가장 당황스러운 부분은 “ASM을 사용하기 위해서 별도의 ASM 인스턴스가 필요하다”는 사실입니다. ASM의 용도가 볼륨 매니저라는 점을 놓고 볼때 “별도의 인스턴스까지 운영해야할까?” 라는 의문점을 갖게 되는건 엔지니어로서는 자연스러운 일일겁니다. 저 역시 이부분이 궁금해서 여러가지 자료를 찾아봤지만, 명확한 내용을 기술해놓은 자료를 찾아볼 수는 없었습니다. 그마다 “A closer Look inside Oracle ASM – Luca Canali – CERN” 문서에 어느 정도 설득력 있는 내용이 정리되어있습니다.

  • 가벼운 인스턴스를 이용한 관리 (ASM 인스턴스는 리두로그, 데이터파일 등이 존재하지 않음)
  • SQL 명령어를 이용해서 환경 설정 가능 (사용 편의성)
  • V$ 뷰들을 통해 메타 정보 및 ASM 디스크 성능 정보 제공 (모니터링 편의성)
  • udump 및 bdump에 로그 기록 (문제 추적의 편의성)

하지만, 아무리 가벼운 인스턴스라고 할지라도 11g까지는 1노드당 1개의 ASM 인스턴스가 필요하다는 점과 ASM 인스턴스가 다운될 경우 (이런 경우가 거의 없다고는 하지만) DB 인스턴스도 즉시 다운된다는 사실은 운영 입장에서 보면 민감한 사실임에 틀림없습니다.

Note
12c의 Flex ASM을 사용할 경우에 노드의 개수와 무관하게 일정 개수(ASM 카디날리티)의 ASM 인스턴스만을 사용하면 됩니다.

 

질문2. ASM 환경에서 IO처리를 위해 ASM 인스턴스를 경유할까요?


ASM 디스크의 extent map 은 ASM 인스턴스가 관리하므로, IO 시에 ASM 인스턴스를 경유할 것 같다는 생각을 할 수 있습니다. 하지만, ASM 인스턴스를 경유해서 IO를 처리한다면 성능 지연이 발생할 가능성이 높습니다. 따라서 오라클은 ASM 인스턴스를 경유하지 않고도 IO를 처리할 수 있도록, ASMB 프로세스를 이용해서 extent map 정보를 DB 인스턴스에게 제공합니다. ASMB 프로세스는 ASM 인스턴스, DB 인스턴스 각각 1개씩 구동되며, 각 ASMB 프로세스들은 오라클 쉐도우 프로세스를 각각 1개씩 fork 시켜 ASM 인스턴스에 접속합니다. (그림-1. 참조) 이러한 연결 고리(‘브릿지’)를 이용해서 DB 인스턴스와 ASM 인스턴스 간에 메타 정보를 전송하게 됩니다. Extent map 정보는 File Open 시에 전송 (10g는 전체 set 전송, 11g부터는 파일별로 n개의 정보만 전송한 후 필요 시에 전송)되므로, 이후의 DB IO는 ASM 인스턴스를 경유하지 않고도 처리가 가능하게 됩니다.

그림-1. DB 인스턴스와 ASM 인스턴스 메타 정보 전송 및 리밸런싱 수행 구성도

14-1

Note
Extent Map 정보는 ASM 인스턴스의 X$KFFXP Fixed 테이블을 통해서만 확인할 수 있습니다. (DB 인스턴스에도 동일한 이름의 테이블이 있지만 0건임)

 

질문3. ASM 환경에서 디스크 리밸런싱은 어떻게 처리될까요?


ASM의 장점 중의 하나는 자동으로 디스크 리밸런싱을 수행하므로 DBA가 별도의 IO 튜닝 작업을 하지 않아도 된다는 것입니다. 예를 들어, 디스크 그룹에 디스크가 추가된 경우에 자동으로 리밸런싱을 수행합니다. (수동 수행도 가능) 이를 위해 ASM 인스턴스는 RBAL (Rebalance Master) 프로세스를 이용해서 리밸런싱 작업을 코디네이트하고 1개 이상의 ARB 프로세스들을 이용해서 실제 리밸런싱 처리를 수행하도록 합니다. ARB 프로세스는 리밸런싱 업무 시에만 구동됩니다.

 

질문4. DB 인스턴스와 ASM 인스턴스에 존재하는 V$ASM_ 뷰들은 동일한 내용을 제공하나요?


DB 인스턴스와 ASM 인스턴스에서는 동일한 이름의 V$ASM_ 뷰들이 존재합니다. 그렇다면 “제공되는 내용도 동일할까?” 라는 궁금증이 생기게 됩니다. 결론부터 이야기하면 ASM 인스턴스는 ASM 디스크그룹을 제공하는 입장이고 DB 인스턴스는 ASM 디스크그룹을 사용하는 입장이라는 점을 제외하곤 거의 동일한 정보를 제공합니다. 예를 들면, ASM 인스턴스의 V$ASM_DISKGRUOP.STATE에는 ‘MOUNTED’로 표시되는 것에 비해서, DB 인스턴스에서는 ‘CONNECTED’라고 표시되는 정도의 차이점이 있습니다.

그리고 아래의 뷰들을 조회하면, ASMB 프로세스를 이용한 ‘브릿지’를 통해 ASM 인스턴스로부터 결과를 전송 받게 됩니다.  즉, ASM 구성정보, 디스크 정보 등 다이나믹하게 변경 가능한 정보들은 항상 ASM 인스턴스를 통해서 최신 정보를 전달 받는다고 보면 될 것 같습니다.

V$ASM_ATTRIBUTE;
V$ASM_DISK
V$ASM_DISK_STAT;
V$ASM_FILE;

 

글을 마치며


ASM은 다소 싱겁게 마무리된 측면이 있습니다. 일반적인 개념을 정리하기에는 이미 정리가 너무 잘 되어있고, “How”를 고민하기에는 그렇게 많은 고민 포인트가 없기 때문이기도 합니다. 다만, ASM을 사용하기 위해서는 ASM 인스턴스가 필요하고, ASM 인스턴스와 DB 인스턴스 간의 데이터 전송은 어떻게 이루어지고, 리밸런싱은 누가 수행하고, V$ASM 뷰들은 왜 동일한 내용을 각 인스턴스에서 제공하는지에 대한 가벼운 대답을 정리하는 수준으로 ASM을 마무리 하려고 합니다. 방문자가 많은 블로그도 아니고, 연재라고 해서 아직까지는 기다리는 독자가 있는 건 아니지만 늘 하나의 글을 마무리한 후에는 새로운 마음으로 다음 주제를 잡고 있습니다. 다음 주제는 “RAC 네트워크”입니다. 이 또한 정리할 내용이 많을지는 모르겠습니다. “RAC 네트워크”가 마무리되면 RAC 연재에서 가장 재미있을 만한 “캐시퓨전 및 RAC 옵타마이징”이라는 주제를 다룰 예정입니다.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s