SAP HANA 프로덕션 데이터베이스에서 데이터베이스 사용자 만들기

다음 단계에 따라 SAP HANA 프로덕션 데이터베이스에서 데이터베이스 사용자를 만들 수 있습니다.

1. 에서 데이터베이스 사용자를 만듭니다 SystemDBSAP HANA 에서 데이터베이스 사용자를 생성합니다, 또는 기존 사용자의 자격 증명을 제공하세요. 후크 스크립트는 이 데이터베이스 사용자를 사용하여 프로덕션 데이터베이스에 연결하고 구성 매개변수를 변경합니다.

   기본 인스턴스의 SystemDB 에 로그인하고 SAP HANA 데이터베이스 대화형 터미널 hdbsql 또는 SAP HANA 콕핏을 사용하여 새 사용자를 생성합니다.

   예를 들어 터미널 세션에서 hdbsql을 사용하여 데이터베이스에 연결합니다.

   sudo -i -u ${sid}adm -- hdbsql -i ${INSTNO} -d SYSTEMDB -u SYSTEM
   

   사용자를 작성합니다.

   CREATE USER HA_HOOK PASSWORD <Password> no force_first_password_change;
   

   사용자에게 필요한 권한을 부여합니다.

   프로필 매개변수를 변경할 수 있도록 INIFILE ADMIN 권한을 부여합니다.

   GRANT INIFILE ADMIN TO HA_HOOK;
   

   HA_HOOK 사용자를 확인합니다.

    sudo -i -u ${sid}adm -- hdbsql -d SYSTEMDB -u SYSTEM select \* from users where user_name = \'HA_HOOK\';
   

2. 사용자 자격 증명을 보안 사용자 저장소 hdbuserstore에 추가합니다.

   두 노드에서 다음 명령을 실행합니다. 이전 단계에서 설정한 비밀번호를 사용합니다.

   sudo -i -u ${sid}adm -- hdbuserstore SET HA_HOOK_KEY localhost:3${INSTNO}13 HA_HOOK <Password>
   

   Hdbuserstore의 업데이트를 확인하세요.

   sudo -i -u ${sid}adm -- hdbuserstore list
   

   기본 인스턴스에서 저장된 사용자 키로 연결을 테스트합니다.

   sudo -i -u ${sid}adm  -- hdbsql -U HA_HOOK_KEY select \* from m_inifiles;
   

후크 스크립트 만들기

Python 후크 스크립트 생성을 위한 샘플 파일은 SAP HANA 설치의 일부로 제공됩니다. 샘플은 $DIR_INSTANCE/exe/python_support/hdb_ha_dr 디렉토리에 있습니다.

대상 디렉터리 /hana/shared/myHooks 는 이미 훅 SAPHanaSR.py 에 대해 생성되었습니다. /hana/shared/myHooks 에서 HA/DR 공급자 후크를 생성합니다. 다음 훅 스크립트는 HADRdummy.py 샘플을 기반으로 합니다.

NODE2 에서 /hana/shared/myHooks/SAPHanaCostOptSR.py 파일을 편집하고 다음 내용을 추가합니다.

"""
Sample for a HA/DR hook provider.

When using your own code in here, please copy this file to location on /hana/shared outside the HANA installation.
This file will be overwritten with each hdbupd call! To configure your own changed version of this file, please add
to your global.ini lines similar to this:

    [ha_dr_provider_<className>]
    provider = <className>
    path = /hana/shared/haHook
    execution_order = 1


For all hooks, 0 must be returned in case of success.
"""

from __future__ import absolute_import
from hdb_ha_dr.client import HADRBase, Helper
from hdbcli import dbapi
import os, time

class SAPHanaCostOptSR(HADRBase):

    def __init__(self, *args, **kwargs):
        # delegate construction to base class
        super(SAPHanaCostOptSR, self).__init__(*args, **kwargs)

    def about(self):
        return {"provider_company" :        "SAP",
                "provider_name" :           "SAPHanaCostOptSR", # provider name = class name
                "provider_description" :    "Handle reconfiguration event for cost-optimized system replication",
                "provider_version" :        "1.0"}

    def postTakeover(self, rc, **kwargs):
        """Post takeover hook."""

        # prepared SQL statements to remove memory allocation limit and pre-load of column tables
        stmnt1 = "ALTER SYSTEM ALTER CONFIGURATION ('global.ini','SYSTEM') UNSET ('memorymanager','global_allocation_limit') WITH RECONFIGURE"
        stmnt2 = "ALTER SYSTEM ALTER CONFIGURATION ('global.ini','SYSTEM') UNSET ('system_replication','preload_column_tables') WITH RECONFIGURE"

        myPort = int('3' + os.environ.get('DIR_INSTANCE')[-2:] + '15')
        myKey = self.config.get("userkey") if self.config.hasKey("userkey") else "HA_HOOK_KEY"

        self.tracer.info("%s.postTakeover method called with rc=%s" % (self.__class__.__name__, rc))
        self.tracer.info("%s.postTakeover method: userkey: %s, port: %s" % (self.__class__.__name__, myKey, myPort))

        if rc in (0, 1):
            # rc == 0: normal takeover succeeded
            # rc == 1: waiting for force takeover
            conn = dbapi.connect(userkey=myKey, address='localhost', port=myPort)
            self.tracer.info("%s: Connect using userkey %s - %s" % (self.__class__.__name__, myKey, conn.isconnected()))
            cursor = conn.cursor()
            rc1 = cursor.execute(stmnt1)
            self.tracer.info("%s: (%s) - %s" % (self.__class__.__name__, stmnt1, rc1))
            rc2 = cursor.execute(stmnt2)
            self.tracer.info("%s: (%s) - %s" % (self.__class__.__name__, stmnt2, rc2))
            return 0
        elif rc == 2:
            # rc == 2: error, something went wrong
            return 0

비용 최적화 후크 활성화

비용 최적화 후크를 활성화하려면 다음 단계를 따르세요.

1. 클러스터를 중지합니다.

   클러스터 노드에서 다음 명령을 실행합니다.

   pcs cluster stop --all
   

2. 후크 스크립트의 파일 소유권을 설정합니다.

   NODE2 에서 다음 명령을 실행합니다.

   chown -R ${sid}adm:sapsys /hana/shared/myHooks
   

3. NODE2 에서 global.ini 구성 파일을 업데이트하여 후크 스크립트를 활성화합니다.

   NODE2 에서 다음 명령을 실행하여 global.ini 파일에 필요한 매개 변수를 추가합니다.

   sudo -i -u ${sid}adm -- <<EOT
       python \$DIR_INSTANCE/exe/python_support/setParameter.py \
         -set SYSTEM/global.ini/ha_dr_provider_SAPHanaCostOptSR/provider=SAPHanaCostOptSR \
         -set SYSTEM/global.ini/ha_dr_provider_SAPHanaCostOptSR/path=/hana/shared/myHooks \
         -set SYSTEM/global.ini/ha_dr_provider_SAPHanaCostOptSR/userkey=HA_HOOK_KEY \
         -set SYSTEM/global.ini/ha_dr_provider_SAPHanaCostOptSR/execution_order=2 \
         -set SYSTEM/global.ini/trace/ha_dr_saphanacostoptsr=info
   EOT
   

4. global.ini 파일의 내용을 확인하세요.

   cat /hana/shared/${SID}/global/hdb/custom/config/global.ini
   

5. 후크가 작동하는지 확인합니다.

   • NODE2 에서 HANA 인스턴스를 다시 시작하고 후크 스크립트가 예상대로 작동하는지 확인합니다.
   • SAP HANA 인수 작업으로 훅을 트리거합니다.
   • 훅이 추적 파일에 로깅한 내용이 있는지 확인합니다.

   sudo -i -u ${sid}adm -- \
       sh -c 'grep SAPHanaCostOptSR $DIR_INSTANCE/$VTHOSTNAME/trace/nameserver_*.trc'
   

   후크가 작동하는지 확인한 후 HA 클러스터를 다시 시작할 수 있습니다.

6. HA 클러스터를 시작합니다.

   클러스터 노드에서 다음 명령을 실행합니다.

   pcs cluster start --all
   

   클러스터의 상태를 확인합니다.

   pcs status --full
   

Test1- 설명

NODE1 에서 실행 중인 기본 HANA 데이터베이스 인스턴스의 충돌을 시뮬레이션합니다.

Test1- 전제 조건

• HANA 시스템 복제를 위한 기능적인 2노드 RHEL HA 애드온 클러스터입니다.
• 두 클러스터 노드 모두 활성 상태입니다.
• 클러스터는 NODE1 및 NODE2 에서 시작됩니다.
• 클러스터 리소스 SAPHana_${SID}_${INSTNO} 는 AUTOMATED_REGISTER=false 로 구성됩니다.
• SAP HANA 시스템 복제 상태를 확인합니다:
  • 기본 SAP HANA 데이터베이스는 NODE1 에서 실행 중입니다.
  • 보조 SAP HANA 데이터베이스는 NODE2 에서 실행 중입니다.
  • HANA 시스템 복제가 활성화되고 동기화됩니다.
• NODE2 의 보조 SAP HANA 데이터베이스가 메모리 감소 구성으로 실행 중입니다.
  • global_allocation_limit 이 줄어듭니다.
  • 열 테이블 미리 로드가 비활성화됩니다(preload_column_tables = false).
• 비프로덕션 SAP HANA 시스템 ${SID_NP} 이 NODE2 에서 실행 중입니다.

Test1- 테스트 절차

사용자 ${sid}adm 로 시그킬 신호를 보내 SAP HANA 기본을 크래시합니다.

NODE1 에서 다음 명령을 실행합니다.

sudo -i -u ${sid}adm -- HDB kill-9

Test1- 예상되는 동작

• SAP HANA NODE1 의 기본 인스턴스가 충돌합니다.
• 클러스터는 중지된 기본 HANA 데이터베이스를 감지하고 리소스를 failed 로 표시합니다.
• 이 클러스터는 NODE2 의 보조 HANA 데이터베이스를 새로운 기본 데이터베이스로 승격합니다.
  • 클러스터는 NODE2 에서 비프로덕션 데이터베이스 ${SID_NP} 를 중지합니다.
  • 활성화하는 동안 global_allocation_limit 및 preload_column_tables 매개 변수는 기본값으로 재설정됩니다.
• 클러스터는 NODE1 에서 가상 IP 주소를 해제하고 NODE2 의 새 기본 주소에서 이를 획득합니다.
• SAP NetWeaver 와 같은 애플리케이션이 SAP HANA 의 테넌트 데이터베이스에 연결되어 있는 경우 애플리케이션은 자동으로 새 기본 데이터베이스에 다시 연결됩니다.

NODE2 에서 다음 명령을 실행하여 global_allocation_limit 및 preload_column_tables 이 설정 해제되었는지 확인합니다.

sudo -i -u ${sid}adm -- hdbcons "mm globallimit" | grep limit

grep -E "global_allocation_limit|preload_column_tables" \
     /hana/shared/${SID}/global/hdb/custom/config/global.ini

Test1- 복구 절차

클러스터 리소스 SAPHana_${SID}_${INSTNO} 가 AUTOMATED_REGISTER=false 로 구성되어 있으므로 클러스터는 장애가 발생한 HANA 데이터베이스를 다시 시작하지 않으며 새 기본 데이터베이스에 대해 등록하지 않습니다. 새 기본 계정( NODE2 )의 상태는 보조 계정 상태를 '연결 시간 초과'로 표시합니다.

NODE1 에서 다음 명령을 실행하여 이전 기본 계정을 새 보조 계정으로 등록합니다.

sudo -i -u ${sid}adm -- <<EOT
    hdbnsutil -sr_register \
        --name=${DC1} \
        --remoteHost=${NODE2} \
        --remoteInstance=${INSTNO} \
        --replicationMode=sync \
        --operationMode=logreplay \
        --online
EOT

시스템 복제 상태를 확인합니다.

sudo -i -u ${sid}adm -- <<EOT
    hdbnsutil -sr_state
    HDBSettings.sh systemReplicationStatus.py
EOT

NODE1 에서 다음 명령을 실행하여 클러스터 노드를 시작합니다.

pcs cluster start

새 보조 인스턴스가 다시 시작되고 동기화된 상태로 표시됩니다(SOK).

pcs status --full

AUTOMATED_REGISTER=true 으로 클러스터 리소스 SAPHana_${SID}_${INSTNO} 를 구성합니다.

NODE1 에서 다음 명령을 실행합니다.

pcs resource update SAPHana_${SID}_${INSTNO} AUTOMATED_REGISTER=true

pcs resource config SAPHana_${SID}_${INSTNO}

Test2- 설명

클러스터 명령을 사용하여 기본 인스턴스를 다른 노드로 다시 이동합니다.

Test2- 전제 조건

• HANA 시스템 복제를 위한 기능적인 2노드 RHEL HA 애드온 클러스터입니다.
• 두 클러스터 노드 모두 활성 상태입니다.
• 클러스터는 NODE1 및 NODE2 에서 시작됩니다.
• 클러스터 리소스 SAPHana_${SID}_${INSTNO} 는 AUTOMATED_REGISTER=true 로 구성됩니다.
• SAP HANA 시스템 복제 상태를 확인합니다:
  • 기본 SAP HANA 데이터베이스는 NODE2 에서 실행 중입니다.
  • 보조 SAP HANA 데이터베이스는 NODE1 에서 실행 중입니다.
  • HANA 시스템 복제가 활성화되고 동기화됩니다.
• 비프로덕션 SAP HANA 시스템 ${SID_NP} 이 NODE2 에서 중지되었습니다.

Test2- 시험 준비

비프로덕션 SAP HANA 시스템에 대한 클러스터 리소스 관리를 해제하여 보조 메모리 리소스가 제한되지 않은 상태에서 시작되지 않도록 합니다.

NODE1 에서 다음 명령을 실행합니다.

pcs resource unmanage group_${sid_np}_non_prod

Test2- 테스트 절차

NODE1 에서 다음 명령을 실행하여 SAP HANA 기본값을 NODE1 으로 다시 이동합니다.

pcs resource move SAPHana_${SID}_${INSTNO}-clone

Test2- 예상되는 동작

• 클러스터는 리소스를 이동하기 위한 위치 제약 조건을 생성합니다.
• 클러스터는 NODE1 에서 보조 HANA 데이터베이스로의 테이크오버를 트리거합니다.
• SAP NetWeaver 와 같은 애플리케이션이 SAP HANA 의 테넌트 데이터베이스에 연결되어 있는 경우 애플리케이션은 자동으로 새 기본 데이터베이스에 다시 연결됩니다.
• 비프로덕션 SAP HANA 시스템의 리소스 ${SID_NP} 의 리소스가 관리되지 않는 상태이며 자동으로 시작되지 않습니다.

Test2- 복구 절차

완전한 HA 시나리오를 다시 설정하려면 몇 가지 단계를 따라야 합니다.

1. 기본 HANA 인스턴스가 활성화될 때까지 기다립니다. 그런 다음 보조 메모리의 메모리 공간을 줄이세요.

   NODE2 에서 다음 명령을 실행하여 메모리를 줄입니다.

   export GLOBAL_ALLOCATION_LIMIT=<size_in_mb_for_hana_secondary>
   

   sudo -i -u ${sid}adm -- <<EOT
       python \$DIR_INSTANCE/exe/python_support/setParameter.py \
         -set SYSTEM/global.ini/system_replication/preload_column_tables=false \
         -set SYSTEM/global.ini/memorymanager/global_allocation_limit=$GLOBAL_ALLOCATION_LIMIT
   EOT
   

2. 보조 인스턴스의 시작을 트리거하는 위치 제약 조건을 제거합니다.

   pcs resource clear SAPHana_${SID}_${INSTNO}-clone
   

   제약 조건이 해제되었는지 확인합니다.

   pcs constraint
   

   클러스터 상태를 확인합니다.

   pcs status --full
   

3. NODE2 에서 다음 명령을 실행하여 global_allocation_limit 및 preload_column_tables 이 설정되어 있는지 확인합니다.

   sudo -i -u ${sid}adm -- hdbcons "mm globallimit" | grep limit
   

   grep -E "global_allocation_limit|preload_column_tables" \
        /hana/shared/${SID}/global/hdb/custom/config/global.ini
   

4. 비프로덕션 SAP HANA 시스템에 대한 리소스를 다시 활성화합니다.

   NODE2 에서 다음 명령을 실행합니다.

   pcs resource manage group_${sid_np}_non_prod
   

   비프로덕션 SAP HANA 시스템의 리소스는 ${SID_NP} 에서 관리되며 비프로덕션 시스템은 NODE2 에서 시작됩니다.

   pcs status --full
   

Test3- 설명

기본 HANA 데이터베이스를 실행하는 노드의 충돌을 시뮬레이션합니다.

Test3- 전제 조건

• HANA 시스템 복제를 위한 기능적인 2노드 RHEL HA 애드온 클러스터입니다.
• 두 클러스터 노드 모두 활성 상태입니다.
• 클러스터는 NODE1 및 NODE2 에서 시작됩니다.
• 클러스터 리소스 SAPHana_${SID}_${INSTNO} 는 AUTOMATED_REGISTER=true 로 구성됩니다.
• SAP HANA 시스템 복제 상태를 확인합니다:
  • 기본 SAP HANA 데이터베이스는 NODE1 에서 실행 중입니다.
  • 보조 SAP HANA 데이터베이스는 NODE2 에서 실행 중입니다.
  • HANA 시스템 복제가 활성화되고 동기화됩니다.
• NODE2 의 보조 SAP HANA 데이터베이스가 메모리 감소 구성으로 실행 중입니다.
  • global_allocation_limit 이 줄어듭니다.
  • 열 테이블 미리 로드가 비활성화됩니다(preload_column_tables = false).
• 비프로덕션 SAP HANA 시스템 ${SID_NP} 이 NODE2 에서 실행 중입니다.

Test3- 테스트 절차

크래시 시스템 요청을 보내 NODE1 에서 기본 크래시를 발생시킵니다.

NODE1 에서 다음 명령을 실행합니다.

sync; echo c > /proc/sysrq-trigger

Test3- 예상되는 동작

• NODE1 종료됩니다.
• 클러스터는 실패한 노드를 감지하고 해당 상태를 OFFLINE 로 설정합니다.
• 이 클러스터는 NODE2 의 보조 HANA 데이터베이스를 새로운 기본 데이터베이스로 승격합니다.
  • 클러스터는 NODE2 에서 비프로덕션 데이터베이스 ${SID_NP} 를 중지합니다.
  • 활성화하는 동안 SAP HANA ${SID} 의 global_allocation_limit 및 preload_column_tables 매개 변수가 재설정됩니다.
• 클러스터는 새 기본값의 NODE2 에서 가상 IP 주소를 얻습니다.
• SAP NetWeaver 와 같은 애플리케이션이 SAP HANA 의 테넌트 데이터베이스에 연결되어 있는 경우 애플리케이션은 자동으로 새 기본 데이터베이스에 다시 연결됩니다.

Test3- 복구 절차

IBM Cloud® 콘솔에 로그인하고 NODE1 을 시작합니다. NODE1 을 다시 사용할 수 있을 때까지 기다린 다음 클러스터 프레임워크를 다시 시작합니다.

NODE1 에서 다음 명령을 실행합니다.

pcs cluster start

pcs status --full

클러스터 리소스 SAPHana_${SID}_${INSTNO} 가 AUTOMATED_REGISTER=true 로 구성되어 있으므로 NODE1 이 클러스터에 가입하면 SAP HANA 이 다시 시작되고 이전 기본 리소스가 보조 리소스로 등록됩니다.

그런 다음 Test2- SAPHana 리소스를 다른 노드로 수동 이동 테스트의 단계를 다시 실행하여 를 실행하여 초기 상황으로 되돌립니다.

Test4- 설명

보조 HANA 데이터베이스의 충돌을 시뮬레이션합니다.

Test4- 전제 조건

• HANA 시스템 복제를 위한 기능적인 2노드 RHEL HA 애드온 클러스터입니다.
• 두 노드 모두 활성 상태입니다.
• 클러스터는 NODE1 및 NODE2 에서 시작됩니다.
• 클러스터 리소스 SAPHana_${SID}_${INSTNO} 는 AUTOMATED_REGISTER=true 로 구성됩니다.
• SAP HANA 시스템 복제 상태를 확인합니다:
  • 기본 SAP HANA 데이터베이스는 NODE1 에서 실행 중입니다.
  • 보조 SAP HANA 데이터베이스는 NODE2 에서 실행 중입니다.
  • HANA 시스템 복제가 활성화되고 동기화됩니다.

Test4- 테스트 절차

사용자 ${sid}adm 로 시그킬 신호를 전송하여 SAP HANA 보조를 충돌시킵니다.

NODE2 에서 다음 명령을 실행합니다.

sudo -i -u ${sid}adm -- HDB kill-9

Test4- 예상되는 동작

• SAP HANA NODE2 충돌이 발생합니다.
• 클러스터는 중지된 보조 HANA 데이터베이스를 감지하고 리소스를 failed 로 표시합니다.
• 클러스터가 보조 HANA 데이터베이스를 다시 시작합니다.
• 클러스터가 시스템 복제가 다시 동기화되었음을 감지합니다.

Test4- 복구 절차

보조 HANA 인스턴스가 시작되고 다시 동기화될 때까지 기다린 다음(SOK), pcs status 에 표시된 대로 실패한 리소스 작업을 정리합니다.

NODE2 에서 다음 명령을 실행합니다.

pcs resource refresh SAPHana_${SID}_${INSTNO}

pcs status --full