BLOG

AWS에서 고가용성 IBM Db2 데이터베이스 생성하기
작성일: 2018-06-22

AWS의 많은 고객들은 IBM Db2 데이터베이스 플랫폼을 사용하여 업무에 필수적인 워크 로드를 실행합니다. 노드의 이벤트 발생 또는 사이트 장애 발생 시에 데이터베이스를 사용할 수 있도록 하려면 이러한 워크 로드를 고가용성으로 구성해야 합니다.

 

고가용성을 위한 기존의 IBM 방법은 Tivoli System Automation for Multi-Platforms (TSAMP)에 의해 조정된 공유 스토리지 및 가상 IP 주소를 사용하는 것입니다. 이 글에서는 네이티브 IBM 및 AWS 기술을 사용하는 완전 자동화된 솔루션을 제공합니다. 이제 AWS에서 업무에 필수적인 Db2 워크 로드를 실행하고 Db2 데이터베이스의 가용성을 높일 수 있습니다.

 

참고: 이 안내서에 구현된 IBM Db2버전은 Linux, Unix 및 Microsoft Windows 버전 11용 Db2의 90일 평가판입니다. 평가판 사용 기간이 끝나면 관련 라이선스 파일을 구입하고 설치할 때 필요한 Db2 버전을 선택할 수 있습니다. 이 과정에서 지원되는 버전은 Db2 Advanced Enterprise Server Edition, Db2 Enterprise Server Edition, Db2 Advanced Workgroup Server Edition 및 Db2 Workgroup Server Edition입니다. 각 버전의 기능에 대한 자세한 내용은 IBM 웹 사이트에서 이 문서를 참조하십시오.

 

 

본 과정을 따라 하는 것으로 두 개의 가용영역(AZs)에 걸쳐 사용 가능한 고가용성 Db2 데이터베이스를 생성하게 됩니다. IBM High Availability Disaster Recovery (HADR) 복제를 사용하여 AZ1의 주 인스턴스와 AZ2의 보조 인스턴스 간에 데이터가 복제됩니다. 기본 노드를 사용할 수 없게 되면 TSAMP에서 이를 감지하고 대기 인스턴스로 페일 오버(failover)합니다. Db2 클라이언트 응용프로그램은 IBM Automatic Client Reroute (ACR) 기능을 사용하여 대기 인스턴스에 자동으로 다시 연결합니다.

 

초기 설정

 

이 솔루션은 AWS의 기본 VPC(가상 프라이빗 클라우드)에 배포됩니다. 기본 VPC는 AWS 계정을 만들 때 각 AWS 리전에 자동으로 생성됩니다. 그러나 기본 VPC가 없는 경우엔 다음을 확인하여 환경을 구축하십시오.

 

  • 공용 서브넷이 두 개인 VPC여야 합니다. 각 서브넷은 동일한 AWS 리전 내의 다른 가용성 영역에 배치해야 합니다.
  • VPC에 인터넷 게이트웨이가 연결되어 있어야 합니다. 각 서브넷에는 인터넷 게이트웨이를 통해 인터넷으로 연결되는 통로가 있어야 합니다.

 

먼저, Amazon S3 버킷을 만들고 다음과 같이 IBM DB2 설치 파일을 업로드 합니다. S3 버킷은 자동 빌드 주기 동안 주 인스턴스와 보조 인스턴스 간에 정보를 교환하는 데도 사용됩니다.

 

  1. Db2 솔루션을 배포할 동일한 AWS 리전에 S3 버킷을 만듭니다. 버킷 구성에는 추가 설정이 필요하지 않습니다.
  2. 버킷에 db2라는 폴더(prefix)를 생성합니다.
  3. IBM 웹 사이트에서 IBM Db2 90일 평가판을 다운로드 합니다.
  4. 다운로드 한 gunzip 파일을 이전에 생성한 S3 버킷의 db2 폴더로 업로드 합니다.

 

고가용성 Db2 솔루션 구축하기

 

솔루션 구현은 AWS CloudFormation 템플릿으로 완전히 자동화됩니다. 시작하기 위해 CloudFormation 콘솔을 열려면 여기를 클릭하십시오. 필요한 경우 콘솔 내에서 CloudFormation 템플릿을 볼 수 있습니다.

CloudFormation 스택에는 다음과 같은 몇 가지 매개 변수가 필요합니다.

 

  • VpcId: 솔루션을 생성할 VPC의 ID를 입력합니다.
  • Stack Name: 스택에 대한 의미 있는 이름을 입력합니다(예:Db2- hadr).
  • KeyPairName: Db2 EC2 인스턴스에 접근하려면 기존 Amazon EC2 key pair를 선택합니다.
  • LinuxInstanceType: 워크 로드에 적합한 인스턴스 유형을 선택합니다.
  • DB2VolumeSize: 데이터베이스를 호스트 할 Amazon EBS 볼륨의 크기를 입력합니다.
  • S3Bucket: 이전에 생성된 S3 버킷 이름을 입력합니다.
  • DB2Instance: 이 매개 변수를 기본 값으로 두거나 Db2 인스턴스 이름을 입력합니다.
  • DB2Database: 이 매개 변수를 기본 값으로 두거나 Db2 데이터베이스 이름을 입력합니다.
  • SyncMode: 필요한 동기화 모드를 선택합니다.
  • SSHCidr: 유효한 CIDR 블록을 입력합니다. 이 CIDR 블록 내의 머신은 SSH(Secure Shell)를 사용하여 EC2 인스턴스에 연결할 수 있습니다.
  • DB2ClientCidr: 유효한 CIDR 블록을 입력합니다. 이 CIDR 블록 내의 머신은 Db2 데이터베이스에 연결할 수 있습니다.
  • PrimaryEC2InstanceName: 기본값으로 두거나 EC2 인스턴스 이름을 입력하십시오.
  • PrimarySubnetId: 주 EC2 인스턴스를 배치할 서브넷의 ID를 입력합니다.
  • SecondaryEC2InstanceName: 기본값으로 두거나 EC2 인스턴스 이름을 입력하십시오.
  • SecondarySubnetId: 보조 EC2 인스턴스를 배치할 서브넷의 ID를 입력합니다.

 

매개 변수를 입력했으면 다음을 수행합니다.

 

  1. Next(다음)를 선택합니다.
  2. 다음 화면에서 필요한 태그, IAM 역할 또는 고급 옵션을 입력하고 Next(다음)를 선택합니다.
  3. 최종 화면에서 세부 정보를 검토한 후 Create(생성)를 선택하여 솔루션 구축을 시작합니다.

 

이 솔루션은 유저 데이터를 사용하여 각 EC2 인스턴스에 부트스트랩 합니다. 자세한 내용은 CloudFormation 템플릿에서 사용자 데이터 섹션을 참조하십시오. 진행률을 보려면 SSH 클라이언트를 사용하여 각 EC2 인스턴스에 연결하고 tail –f /var/log/cloud-init-output.log 명령을 실행하면 됩니다.

 

Db2 클러스터 세부 정보 보기

 

CloudFormation 템플릿의 부트스트랩 순서가 완료되면 lssam, lsrpnode 및 db2pd의 세가지 표준 IBM 명령을 사용하여 클러스터 세부 정보를 볼 수 있습니다.

 

주 인스턴스와 보조 인스턴스에서 루트 사용자로 다음 명령을 실행하여 HADR 구성을 볼 수 있습니다(testdb를 사용자 지정 데이터베이스 이름으로 바꿀 수 있음).

 

su – db2inst1 -c “db2pd -hadr -db testdb”

 

각 인스턴스의 경우 다음과 유사한 내용이 표시되어야 합니다.

 

HADR_ROLE = PRIMARY

                          REPLAY_TYPE = PHYSICAL

                        HADR_SYNCMODE = NEARSYNC

                           STANDBY_ID = 1

                        LOG_STREAM_ID = 0

                           HADR_STATE = PEER

                           HADR_FLAGS = TCP_PROTOCOL

                  PRIMARY_MEMBER_HOST = ip-10-240-16-50

                     PRIMARY_INSTANCE = Db2inst1

                       PRIMARY_MEMBER = 0

                  STANDBY_MEMBER_HOST = ip-10-240-17-180

                     STANDBY_INSTANCE = Db2inst1

                       STANDBY_MEMBER = 0

                  HADR_CONNECT_STATUS = CONNECTED

             HADR_CONNECT_STATUS_TIME = 12/06/2017 15:31:15.222197 (1512574275)

          HEARTBEAT_INTERVAL(seconds) = 15

                     HEARTBEAT_MISSED = 0

                   HEARTBEAT_EXPECTED = 26

                HADR_TIMEOUT(seconds) = 60

        TIME_SINCE_LAST_RECV(seconds) = 3

             PEER_WAIT_LIMIT(seconds) = 0

           LOG_HADR_WAIT_CUR(seconds) = 0.000

    LOG_HADR_WAIT_RECENT_AVG(seconds) = 0.000460

   LOG_HADR_WAIT_ACCUMULATED(seconds) = 0.056

                  LOG_HADR_WAIT_COUNT = 121

SOCK_SEND_BUF_REQUESTED,ACTUAL(bytes) = 0, 332800

SOCK_RECV_BUF_REQUESTED,ACTUAL(bytes) = 0, 236184

            PRIMARY_LOG_FILE,PAGE,POS = S0000000.LOG, 64, 45099263

            STANDBY_LOG_FILE,PAGE,POS = S0000000.LOG, 64, 45099263

                  HADR_LOG_GAP(bytes) = 0

     STANDBY_REPLAY_LOG_FILE,PAGE,POS = S0000000.LOG, 64, 45099263

       STANDBY_RECV_REPLAY_GAP(bytes) = 1220384

                     PRIMARY_LOG_TIME = 12/06/2017 15:34:17.000000 (1512574457)

                     STANDBY_LOG_TIME = 12/06/2017 15:34:17.000000 (1512574457)

              STANDBY_REPLAY_LOG_TIME = 12/06/2017 15:34:17.000000 (1512574457)

         STANDBY_RECV_BUF_SIZE(pages) = 4300

             STANDBY_RECV_BUF_PERCENT = 0

           STANDBY_SPOOL_LIMIT(pages) = 25600

                STANDBY_SPOOL_PERCENT = 0

                   STANDBY_ERROR_TIME = NULL

                 PEER_WINDOW(seconds) = 120

                      PEER_WINDOW_END = 12/06/2017 15:39:47.000000 (1512574787)

             READS_ON_STANDBY_ENABLED = N

 

이 출력에서 다음 파라미터에 주목하십시오.

 

  • HADR_ROLE: 이 파라미터는 인스턴스가 주 노드인지 보조 노드인지 나타냅니다.
  • HADR_STATE: 이 파라미터는 PEER 값을 표시해야 합니다.
  • HADR_ CONNECT_STATUS: 이 파라미터에는 CONNECTED 값이 표시되어야 합니다.

 

주 인스턴스나 보조 인스턴스에서 lsrpnode 명령을 루트 사용자로 실행하여 TSA 클러스터 노드를 나열할 수 있습니다. 따라서 각 노드의 이름, 상태 및 IBM RSCT(IBM Reliable Scalable Cluster Technology) 버전을 보여 주는 다음과 유사한 정보가 표시되어야 합니다.

 

Name             OpState RSCTVersion

ip-10-240-17-180 Online  3.2.1.2    

ip-10-240-16-50  Online  3.2.1.2

 

TSA 클러스터 리소스는 주 인스턴스에서 Issam 명령을 실행하여 볼 수 있습니다. 따라서 다음과 유사한 내용을 확인할 수 있습니다.

 

Online IBM.ResourceGroup:Db2_Db2inst1_Db2inst1_TESTDB-rg Nominal=Online

        ‘- Online IBM.Application:Db2_Db2inst1_Db2inst1_TESTDB-rs

                |- Online IBM.Application:Db2_Db2inst1_Db2inst1_TESTDB-rs:ip-10-240-16-50

                ‘- Offline IBM.Application:Db2_Db2inst1_Db2inst1_TESTDB-rs:ip-10-240-17-180

Online IBM.ResourceGroup:Db2_Db2inst1_ip-10-240-16-50_0-rg Nominal=Online

        ‘- Online IBM.Application:Db2_Db2inst1_ip-10-240-16-50_0-rs

                ‘- Online IBM.Application:Db2_Db2inst1_ip-10-240-16-50_0-rs:ip-10-240-16-50

Online IBM.ResourceGroup:Db2_Db2inst1_ip-10-240-17-180_0-rg Nominal=Online

        ‘- Online IBM.Application:Db2_Db2inst1_ip-10-240-17-180_0-rs

                ‘- Online IBM.Application:Db2_Db2inst1_ip-10-240-17-180_0-rs:ip-10-240-17-180

Online IBM.Equivalency:Db2_Db2inst1_Db2inst1_TESTDB-rg_group-equ

        |- Online IBM.PeerNode:ip-10-240-16-50:ip-10-240-16-50

        ‘- Online IBM.PeerNode:ip-10-240-17-180:ip-10-240-17-180

Online IBM.Equivalency:Db2_Db2inst1_ip-10-240-16-50_0-rg_group-equ

        ‘- Online IBM.PeerNode:ip-10-240-16-50:ip-10-240-16-50

Online IBM.Equivalency:Db2_Db2inst1_ip-10-240-17-180_0-rg_group-equ

        ‘- Online IBM.PeerNode:ip-10-240-17-180:ip-10-240-17-180

 

Issam 명령은 TSA 클러스터 내의 리소스 및 리소스 그룹을 보여 줍니다. 오프라인 리소스는 데이터베이스가 보조 노드에서 활성 상태가 아님을 나타냅니다.

 

클러스터 테스트

 

다음 명령을 사용하여 수동 페일 오버(failover)를 시작하여 클러스터를 테스트할 수 있습니다.

 

rgreq -o move <name of TSAMP resource group>

 

아래 예제처럼 할 수 있습니다.

 

rgreq -o move Db2_Db2inst1_Db2inst1_TESTDB-rg

 

명령을 실행한 후 lssam 명령을 몇 번 실행하여 보조 노드의 데이터베이스 페일 오버(failover)를 감시합니다.

 

ACR(Automatic Client Rerouting) 테스트

 

다음으로 ACR을 테스트합니다. 간단히 말하면 Db2 클라이언트 인스턴스의 DBA 사용자를 사용하여 데이터베이스에 연결합니다. 그러나 연결하려면 DBA 사용자가 주 인스턴스와 보조 인스턴스 모두에 암호를 설정해야 합니다. 각 Db2 인스턴스에서 다음 명령을 실행하여 DBA 사용자에게 암호를 할당합니다.

 

echo “<DBA user name>:<Password>” | chpasswd

 

아래 예제처럼 할 수 있습니다.

 

echo “db2inst1:Pass.123” | chpasswd

 

그런 다음 SSH를 사용하여 Db2 클라이언트 시스템에 연결하고 다음 단계를 수행합니다. 이러한 단계는 기본 인스턴스에 연결되고 데이터베이스 세부 정보를 요청합니다. 주 인스턴스는 대체 서버 호스트 이름(보조 인스턴스)을 반환합니다. ACR 호환 가능한 Db2 클라이언트는 대체 호스트 이름을 기억하고 주 인스턴스를 사용할 수 없는 경우 자동으로 대체 호스트 이름에 연결합니다.

 

Db2 클라이언트에서 DBA 사용자를 사용하여 다음 명령을 실행합니다.

 

  1. 다음 명령을 사용하여 Db2 데이터베이스의 별칭(alias)을 만듭니다.

db2 catalog tcpip node HAPNODE remote <NAME-OF-PRIMARY-INSTANCE> server <DB Listener Port>

 

아래 예제처럼 할 수 있습니다.

 

db2 catalog tcpip node HAPNODE remote ip-1-1-1-1 server 60000

 

  1. 다음 명령을 사용하여 데이터베이스의 카탈로그를 만듭니다.

 

db2 catalog db <DB-Name> at node HAPNODE

 

아래 예제처럼 할 수 있습니다.

 

db2 catalog db TESTDB at node HAPNODE

 

  1. 다음 명령을 사용하여 데이터베이스에 연결합니다.

 

db2 connect to <DB-Name> user <Db2InstanceName> using <Password>

 

아래 예제처럼 할 수 있습니다.

 

db2 connect to TESTDB user db2inst1 using Pass.123

 

  1. 다음 명령을 실행하여 대기 인스턴스의 이름을 표시합니다. 이 이름은 다음과 같은 출력과 같이 eodks 서버 호스트네임 필드에 나타납니다.

 

db2 list db directory

 

아래와 같은 결과를 볼 수 있습니다.

 

Alternate server hostname            = ip-10-240-17-180

Alternate server port number         = 60000

 

요약

이제 AWS에서 사용 가능한 고가용성 Db2 데이터베이스를 실행할 수 있습니다. 기본 인스턴스에 기록된 모든 트랜잭션은 선택한 동기화 방법(ASYNC, NEARSYNC 또는 SYNC)을 사용하여 대기 인스턴스에 자동으로 동기화됩니다.

 

주 인스턴스가 실패하거나 사용할 수 없게 되면 TSAMP에서 장애를 감지하고 보조 인스턴스로 자동으로 페일 오버(failover)됩니다. 장애 조치 시 Db2 클라이언트는 주 인스턴스는 사용할 수 없음을 감지하고 보조 인스턴스에 자동으로 연결됩니다.

 

프로덕션 사용을 위해 이 솔루션을 고려하기 전에 몇 가지 사항을 변경해야 할 수 있습니다. 예를 들어 Db2 서버를 프라이빗 서브넷에 배치할 수도 있습니다. 고려해야 할 다른 잠재적인 변경 사항은 응답 파일의 옵션을 사용자 정의하거나 Db2 소프트웨어 라이센스를 자동으로 구성하는 것입니다.

 

업무에 필수적인 Db2 기반 애플리케이션을 AWS로 마이그레이션을 시작하세요!

 

원문 URL: https://aws.amazon.com/ko/blogs/database/creating-highly-available-ibm-db2-databases-in-aws/

** 메가존 TechBlog는 AWS BLOG 영문 게재글중에서 한국 사용자들에게 유용한 정보 및 콘텐츠를 우선적으로 번역하여 내부 엔지니어 검수를 받아서, 정기적으로 게재하고 있습니다. 추가로 번역및 게재를 희망하는 글에 대해서 관리자에게 메일 또는 SNS페이지에 댓글을 남겨주시면, 우선적으로 번역해서 전달해드리도록 하겠습니다.