Linux OS 사전 작업

설치될 RPA 관련 프로그램들이 정상적으로 동작하기 위해 필요한 OS 환경설정이 제대로 구성되어 있는지 아래의 상세항목들을 확인하고 조치해주어야 합니다.

아래의 사전 체크 과정은 sudo 권한이 있는 ipaadm 계정으로 진행 가능합니다.

OpenJDK 설치는 Brity RPA Orchestrator를 설치하는 시점에도 함께 진행이 가능하오니 사전에 요청을 해주시면 지원 가능합니다.

OpenJDK 설치

Brity RPA Orchestrator의 동작을 위해서는 Java Runtime 환경이 반드시 필요합니다. java -version 커맨드 라인(command line) 명령이 동작하지 않는다면 아래 JDK 설치와 환경 구성 방법을 확인하여 적절한 조치를 취하세요. 본 문서 2. 설치 스크립트 준비 내용을 먼저 참조하여 설치 패키지를 풀어보면 그 하위 lib 디렉토리에 설치 가능한 OpenJDK 패키지가 포함되어 있습니다.

OpenJDK File 복사를 통한 JDK 신규 설치

cd /rpa/install/lib/openjdk
tar xvzf zulu8.54.0.21-ca-jdk8.0.292-linux_x64.tar.gz
mv zulu8.54.0.21-ca-jdk8.0.292-linux_x64 /usr/local/src/

Oracle JDK도 사용할 수 있으나 이 경우에는 라이선스를 구매해야 합니다.

JDK Path 추가

vi /etc/profile
# 아래 정보 추가
export JAVA_HOME=/usr/local/src/zulu8.54.0.21-ca-jdk8.0.292-linux_x64
export PATH=$JAVA_HOME/bin:$PATH
export CLASSPATH=$CLASSPATH:$JAVA_HOME/jre/lib/ext:$JAVA_HOME/lib/tools.jar
 alias java=/usr/local/src/zulu8.54.0.21-ca-jdk8.0.292-linux_x64/bin/java

Java 설치 완료 테스트 커맨드 창에서 java -version 명령을 실행하여 버전 정보를 확인하세요.

source /etc/profile
java –version

OS 날짜 설정 확인

Linux 시스템 시간 또는 시간대 설정에 오류가 있을 경우 인증이 실패하거나 라이선스 Activation이 정상적으로 되지 않을 수 있습니다. date command 명령어로 현재 시간을 확인할 수 있고, zdump /etc/localtime command 명령어로 시간대를 확인할 수 있습니다.

$date
2020. 10. 18. (일) 03:49:06 EDT 

$zdump /etc/localtime 
/etc/localtime Sun Oct 18 03:49:06 2020 EDT 

$ timedatectl set-timezone Asia/Seoul
$date
2020. 10. 18. (일) 16:49:06 KST

"timedatectl set-timezone Asia/Seoul"으로부터 시간대가 KST로 변경되었음을 확인할 수 있습니다.

설치 후 시간대를 재설정한 경우 아래 3개 테이블의 데이터를 비우고 재시작해야 합니다.

rpa.tb_scheduled_operation_lock

auth.tb_scheduled_operation_lock

catalog.tb_scheduled_operation_lock

OS 방화벽 체크

OS 자체가 포함하고 있는 방화벽 설정에 따라 내/외부에서의 서비스 접속이 불가능할 수 있습니다. 이 경우 서버 자체 방화벽을 disable로 설정하여야 합니다.

(CentOS, RHEL)

# 상태확인 (active / inactive)
systemctl status firewalld

# 서비스 중지
sudo systemctl stop firewalld

# 방화벽 영구 비활성화 (재부팅시 자동 중지)
sudo systemctl disable firewalld

(Ubuntu)

# 상태 확인 (active / inactive)
sudo ufw status

# 방화벽 중지 및 비활성화
sudo ufw disable

Linux OS에 설정된 ulimit 체크

Linux에서 프로세스가 OS에 요청할 수 있는 최대 Open 가능한 파일 개수에 limit이 있으면 그 제한을 초과할 경우, 로그상에 "Too many open files" 라는 문구와 함께 에러가 발생합니다.

RPA 서비스와 DB가 설치된 각 Linux 서버의 해당 계정들(주로 ipaadm, ipadb 사용)에 대해서 계정별로 ulimit이 어떻게 설정되어있는지 확인하고, 
내용중 open files 항목이 기본값인 1024로 설정되어 있는 경우에는 큰값으로 아래와 같이 변경을 해줍니다.

# 상태확인 (open files 갯수)
[ipaadm@brity ~]$ ulimit -a
중략 
open files                      (-n) 1024

프로세스가 열 수 있는 최대 파일수(open files) 변경 방법은 아래와 같습니다.

명령어를 사용하는 방법과 limits.conf 파일을 수정하는 방법 두가지가 있고 두 방법 모두 장비 재부팅 없이 설정할 수 있으나, 
명령어를 사용하는 방법은 세션이 끊어지면 초기화 되고 
limits.conf 파일을 수정하는 방법은 한번 세션을 끊었다가 다시 로그인해야 적용됩니다.

영구적인 설정을 위해서 limits.conf 파일에 반드시 등록해두고, 현재 세션에서의 즉시 적용도 필요한 경우에는 명령어를 사용하는 방법을 이용하여 바로 적용하시면 됩니다.

1) 명령어를 사용하는 방법 (임시, 즉시 적용)

이 명령어를 이용하여 ulimit을 변경하는 방법은 세션이 끊기게 되면 설정 했던 값은 초기화됩니다.

사용중인 계정으로 로그인한 상황에서 다음과 같은 명령어 실행 
(ipaadm, ipadb 사용중이면 모두 적용)

[ipaadm@brity ~]$ ulimit -Hn 65536
[ipaadm@brity ~]$ ulimit -Sn 65536

2) limits.conf 파일을 수정해서 영구 적용하는 방법

사용중인 계정으로 로그인한 상황에서 아래의 디렉토리로 이동
cd /etc/security/
여기 아래에 있는 limits.conf 파일을 vi 에디터로 열고 하단부분에 내용 추가 
(ipaadm 계정의 예시, ipadb도 사용중이면 동일하게 적용)

재로그인이나 재부팅할 경우, 해당 계정의 값으로 영구 적용됨

# /etc/security/limits.conf

중략


ipaadm soft nofile 65536
ipaadm hard nofile 65536

# End of file

설치 스크립트 준비

설치 스크립트는 설치 상의 편의를 위해 두가지 버전으로 구성되어 있습니다.

rpa-basic-install.sh: ipaadm 단일 계정으로 하나의 서버에 원클릭 단일 설치 (간단 설치용)
rpa-custom-install.sh : 설치 옵션을 다양하게 변경 가능하고 각 SW별로 선택하여 설치할 수 있으며, 이미 RPA를 사용중인 환경에서 AP만 업데이트 설치기능까지 제공

설치를 위해서는 ipaadm, ipadb 계정 은 이미 생성되어 있어야 합니다. (ipaadm 계정으로 설치하는 것을 기본으로 하지만, DB계정을 나눠야 하는 상황에서는 ipadb 계정을 추가로 생성해주는 것이 필요합니다. ipaadm 단일 계정을 사용할 경우, 아래의 설명 중 ipadb 계정과 관련한 내용도 ipaadm으로 진행하면 됩니다)
생성되지 않은 경우, 아래와 같은 절차로 계정 생성을 진행해주며, 설치파일을 업로드할 install 디렉토리를 /rpa 하위에 미리 생성해줍니다.

root 계정으로 작업을 진행합니다.
useradd ipaadm
useradd ipadb
passwd ipaadm
passwd ipadb

mkdir /rpa
mkdir /rpa/install
chown -R ipaadm:ipaadm /rpa

설치 파일을 서버 /rpa/install 폴더에 ipaadm 계정으로 업로드하세요. /rpa/install 폴더에는 아래 4개 파일이 있어야 합니다.

apache-activemq-5.15.14.tgz
apache-tomcat-9.0.46.tar.gz
BRITY_RPA_server_install.tgz
mariadb-10.6.10-linux-systemd-x86_64.tar.gz

아래와 같이 Brity RPA install 프로그램 압축을 해제하세요.

su ipaadm
cd /rpa/install
tar xvzf BRITY_RPA_server_install.tgz
chmod -R ugo+rwx /rpa/install   (모든 사용자에게 접근 권한을 부여합니다.)

Basic 설치

ipaadm 계정에 설치하는 경우를 예시로 설명합니다.
(ipaadm이 아닌 다른 사용자 계정으로도 설치할 수 있으며, 단일계정으로 home 하위에 일괄 설치하는 절차이기 때문에 sudo 권한이 없이도 설치가 가능합니다.)
 
Step by Step 형식의 복잡한 단계없이 설치가 일괄 진행되며 설치진행자가 의도적으로 변경을 하지
않는 경우에는 RPA의 서비스와 오픈소스들이 설치 계정의 home 디렉토리 /home/ipaadm/rpa에 
기본 설치됩니다. 설치를 완료한 후에는 오픈소스들과 RPA 서비스를 자동으로 실행시킵니다.

설치 경로와 IP/Port 등을 변경하고 싶은 경우, ‘C’를 입력하여 순차적으로 제시하는 각 항목을 원하는 값으로 수정하여 설치 환경을 변경할 수 있습니다.

다음과 같은 절차로 진행하세요.

커맨드 라인에 다음과 같이 입력하여 설치를 실행하세요.

cd /rpa/install
./rpa-basic-install.sh

첫 화면에 나오는 최종 사용자 라이선스 동의 (EULA)에 Y를 선택하면 설치메뉴로 바로 이동하게 됩니다.

RPA 솔루션에 사용할 DBMS를 선택합니다. Brity RPA는 MariaDB와 MSSQL (Microsoft SQL Server)를 공식적으로 지원합니다.

최초 실행시 Java, MariaDB, Tomcat, ActiveMQ, RPA AP, IPv6 비활성화를 체크하세요. Process가 OK가 아니면 2) Exit를 선택하여 프로세스를 종료하고 다시 진행합니다. 혹시나 IPv6를 사용 중일 경우엔 ipv6를 사용하지 않도록 설정하는 것이 좋습니다. (자세한 내용은 본 문서의 IPv6 사용 여부 확인 (IPv6 비활성화) 내용을 참고하세요.)

체크필요함

사전 check가 모두 OK인 최적 상태임을 확인한 후, 1) Install new Brity RPA v3.0.0_hotfix. (Basic Install)을 선택하세요. 설치 설정 정보가 표시됩니다.

6. 설치 정보가 표시되면 설정 내용을 자세히 확인합니다. 정보를 변경하고 싶다면 C를 눌러서 순차적으로 모든 설정값들을 원하는 값으로 변경할 수 있습니다. Server IP와 Port를 포함하여 전체 설정값들이 모두 이상이 없다면, Y를 눌러 설치를 바로 진행하세요.

설치가 바로 진행되면서 MariaDB -> Tomcat -> ActiveMQ -> RPA Application -> RPA Web Portal -> DB Schema 순으로 하나씩 설치됩니다.

DB Schema 설치를 진행하기 전에 table definition cache 관련한 물음이 나옵니다. 이는 설치된 MariaDB의 table_definition_cache 기본값이 작기 때문에 일시적으로 14000 이상값으로 늘여주어야하는데 여기서 설정한 값은 설치 시에만 활용되도록 임시 반영될 뿐 영구값으로 저장되지는 않습니다.

값을 14000 이상 값으로 수정해주고 엔터를 누르세요.

7. DB Schema 설치가 끝난 후, 모든 것이 순차적으로 설치가 완료되고 나면 Tomcat 기동을 마지막으로 설치는 종료하게 됩니다. 각 단계에서 설치완료 후 기동까지 해주기 때문에 각 서비스들을 별도로 기동해주는 절차는 필요하지 않습니다.

설치가 정상적으로 수행되면 이 문서의 2. 라이선스 활성화를 참고하여 라이선스 등록을 진행하세요.
설치 중에 오류가 발생했을 경우 이 문서 별첨 파트의 2. 문제 해결을 참고하세요.

Custom 설치

MariaDB, ActiveMQ, Tomcat을 포함하여 Brity RPA를 한 대의 서버에 단일 설치하는 방법을 예시로 설명합니다. 계정은 ipaadm 계정을 이용해서 설치하는 것을 기본으로 설명합니다. 만약 DB 설치 계정을 ipadb로 나눠서 설치를 진행하고자 한다면 rpa-custom-install.sh을 sudo 권한으로 실행해줍니다.

다음과 같이 설치 프로그램을 실행하세요.

cd /rpa/install
./rpa-custom-install.sh

첫화면에 등장하는 최종사용자 라이선스 동의(EULA)에서는 Y를 선택해야 설치를 진행할 수 있습니다.

RPA 솔루션에 사용할 DBMS를 선택합니다. Brity RPA는 MariaDB와 MS-SQL (Microsoft SQL Server)를 공식적으로 지원합니다.

1) Install Opensource Program ( MariaDB, Tomcat, ActiveMQ )을 선택하세요.

1) install Mariadb를 선택하세요.

기본 Installation Path는 /rpa 이며, 설치 계정은 ipaadm 입니다. 만약 다른 값으로 설정이 되어 있거나 의도적으로 변경하고자 한다면 C를 선택해서 값들을 변경합니다. 이후 최종적으로 값들이 세팅되면 Y를 선택해서 설치를 진행하세요. DB 설치 계정을 분리해서 설치하고자 하는 경우에도 이 화면에서 해당 계정(예 : ipadb)을 지정해서 설치를 진행하면 되는데, 이때는 sudo 권한으로 실행해줍니다.

MariaDB가 정상적으로 설치되고, 프로세스가 실행되었는지 확인하세요. MariaDB의 경우, 후속으로 RPA 서비스들을 설치하는 과정에서 DB schema 들을 적용하기 위해서는 MariaDB에 직접 클라이언트로 접속하여 설치 명령들을 진행하기 때문에 DB 설치와 동시에 미리 기동을 시켜둡니다.

다시 설치 스크립트(rpa-custom-install.sh)를 실행시킨 후, 오픈소스 설치 메뉴까지 이동해서 2) install Tomcat을 선택하세요.

Y 를 눌러 Tomcat 설치를 진행하세요.

Tomcat 설치가 정상적으로 수행되었음을 확인하세요. 단, 자동으로 기동이 되지는 않습니다.

다시 설치 스크립트(rpa-custom-install.sh)를 실행시킨 후, 오픈소스 설치 메뉴까지 이동해서 3) install ActiveMq를 선택하세요.

DB서버의 IP를 확인하세요. 변경이 필요하면 아래의 화면처럼 C를 눌러서 정확한 DB서버의 IP로 수정해준 후, Y를 눌러 설치를 진행하세요. MQ의 포트는 8888을 기본사용합니다.

ActiveMQ 설치가 정상적으로 수행되었는지 확인하세요

다시 설치 스크립트(rpa-custom-install.sh)를 실행시킨 후, RPA AP 설치를 위해 #HOME 메뉴까지 이동해서 2) Install new Brity RPA v3.0.0_hotfix. 를 선택하세요

RPA 서비스 어플리케이션을 먼저 설치하기 위해 1) Install the RPA v3.0.0_hotfix Service application. 을 선택하세요.

2installnewbrityRPA선택합니다

설치 정보가 표시되면 설정 내용을 자세히 확인합니다. 정보를 변경하고 싶다면 C를 눌러서 순차적으로 모든 설정값들을 원하는 값으로 변경할 수 있습니다. 보여지는 설정값들이 모두 이상이 없다면, Y를 눌러 설치를 바로 진행하세요. 이중화 설치가 아닌 경우는 맨 아래 Redunant Server 관련 설정 2가지는 변경할 필요없고, 이중화 설치인 경우에는 Redundant server 항목은 서버 두대 모두 Y로, Redundant server type의 경우는 AP1일때는 1로 AP2일때는 2로 각각 변경합니다. 이중화 설치에선 Gateway server address에 L4의 VIP를 입력해줍니다.

16G 이상의 Mememory가 설치된 경우, Maximum Heap Memory 설정을 변경할 수 있습니다. 변경이 필요하지 않다면, N을 눌러 설치를 진행하세요.

Brity RPA service application 설치가 정상적으로 수행되었음을 확인하세요.

다시 설치 스크립트(rpa-custom-install.sh)를 실행시킨 후, RPA AP 설치를 위해 #HOME 메뉴까지 이동해서 2) Install new Brity RPA v3.0.0_hotfix. 를 다시 선택하고, 2) Install the RPA v3.0.0_hotfix Web application. 을 선택하세요.

2installnewbrityRPA선택합니다

Y를 눌러 설치를 진행하고 Brity RPA web application 설치가 정상적으로 수행되었음을 확인하세요.

다시 설치 스크립트(rpa-custom-install.sh)를 실행시킨 후, RPA AP 설치를 위해 #HOME 메뉴까지 이동해서 2) Install new Brity RPA v3.0.0_hotfix. 를 다시 선택하고, 3) Install the RPA v3.0.0_hotfix DB schema. 를 선택하세요. (만약 DB 설치계정을 ipadb로 분리해서 설치한다면 상기 rpa-custom-install.sh 스크립트를 sudo 권한으로 실행시켜야합니다)

2installnewbrityRPA선택합니다

Database installed path 항목이 정상적으로 지정되어 있는 것을 확인하고 변경이 필요한 경우 C를 눌러 적절한 값들로 변경해주고, 최종적으로는 Y를 눌러 설치를 진행하세요.

2installnewbrityRPA선택합니다

"Remote DB Install" 설정 안내

: default로는 n 이며, 이는 DB가 깔려있는 서버에서 직접 본 설치프로그램을 실행해서 작업하는 것을 의미합니다. DB서버에 직접 설치프로그램을 업로드할 수 없는 제약적인 환경 (클라우드 RDS 서비스 이용 등)에서는 y를 선택하여 AP서버 등에서 Remote로 DB서버에 Schema 설치를 할 수 있습니다.

단, 이런 Remote 설치인 경우에 주의할 점은 DB Schema의 원격 설치에는 내부적으로 MariaDB의 바이너리를 사용하는 부분이 있기 때문에 AP서버에 MariaDB를 임시로 깔아서 원격 작업을 완료하고 그 후에 AP서버에 깔아놓은 MariaDB는 제거해주세요.

Remote작업을 위해 AP서버에 임시로 깔아준 MariaDB는 삭제 항목들

AP서버에 떠있는 MariaDB 프로세스 stop
/rpa/bin 하위의 mysql start/stop 스크립트 제거
/rpa/logs 하위의 mariadb 폴더 삭제
/rpa/pkgs 하위의 mariadb 폴더 삭제

그리고 Remote 설치로 진행하는 경우에는 두번째 항목인 "Database installed path" 의 경로설정을 AP서버 내에 임시 설치해준 MariaDB의 경로로 지정해주어야 합니다.

(DB서버 내의 설치경로가 아닌 점을 반드시 주의하세요)

"DB Install user" 설정 안내

: default로는 root이며, 클라우드 환경에서 Managed 서비스로 제공되는 MariaDB를 사용하는 경우에는 root 계정을 제공하지 않기 때문에 all privileges 를 획득한 특정 계정을 사용해야하는 경우에만 그 계정값을 입력해주세요.

모든 설정값을 확인한 후, Y를 눌러서 실행을 시키면 DB Schema 설치를 진행하기 전에 table definition cache 관련한 물음이 나옵니다. 이는 설치된 MariaDB의 table_definition_cache 기본값이 작기 때문에 일시적으로 14000 이상값으로 늘여주어야하는데 여기서 설정한 값은 설치 시에만 활용되도록 임시 반영될 뿐 영구값으로 저장되지는 않습니다.

값을 14000 이상 값으로 수정해주고 엔터를 누르세요.

Brity RPA v3.0.0_hotfix database schema 설치가 정상적으로 수행되었음을 확인하세요.

# 모든 설치가 완료되었습니다.

설치 HOME의 메뉴 중, 3) Update Brity RPA v3.0.0_hotfix 메뉴는 기존에 하위 버전 Brity RPA를 사용중인 환경에서 RPA AP만 업데이트 설치하는 메뉴입니다. 신규 설치에는 사용되지 않고, 구 버전을 업데이트 설치하는 경우 수행하며 오픈소스의 변경없이 RPA 서비스와 DB 스키마 등을 업데이트합니다.

RPA AP 서버와 DB 서버 분리

방화벽 설정

어플리케이션(AP) 서버와 DB 서버가 분리된 환경에 설치하는 경우, 반드시 DB서버의 4406 포트에 대한 통신이 가능해야 합니다.

AP 서버와 DB 서버 간 방화벽 설정: AP 서버 → DB 서버(4406)

설치 방법

아래의 작업들은 설치 프로그램중 Custom 설치 스크립트를 이용해야 합니다.

DB 서버 작업
1. Setup Program에서 "1) Install Opensource Program" -> "1) install Mariadb"를 이용하여 MariaDB를 먼저 설치하세요. 설치가 완료된 후에는 MariaDB가 자동으로 기동됩니다.
2. MariaDB가 설치완료되면, 다시 한번 Setup Program에서 "2) Install new Brity RPA v3.0.0_hotfix." -> "3) Install the RPA v3.0.0_hotfix DB schema."를 수행하세요. 이 때 반드시 DB 서버 IP를 127.0.0.1 이 아닌 실제 DB 서버의 IP로 입력하세요..
AP 서버 작업
1. Setup Program에서 "1) Install Opensource Program" -> "2) install Tomcat"을 이용하여 Tomcat을 설치하세요.
2. 이어서 Setup Program에서 "1) Install Opensource Program" -> "3) install ActiveMq"를 이용하여 Tomcat을 설치하세요.
3. Tomcat과 ActiveMQ는 설치완료 후, 자동으로 기동되지 않습니다.
4. 오픈소스 설치에 이어 RPA 솔루션을 설치합니다. Setup Program에서 "2) Install new Brity RPA v3.0.0_hotfix." -> "1) Install the RPA v3.0.0_hotfix Service application."를 이용하여 RPA 서비스를 설치하세요.
5. 마지막으로, Setup Program에서 "2) Install new Brity RPA v3.0.0_hotfix." -> "2) Install the RPA v3.0.0_hotfix Web application."를 이용하여 RPA 웹포탈을 설치하세요. 이 때 반드시 DB 서버 IP를 127.0.0.1 이 아닌 실제 DB 서버의 IP로 입력하세요.
6. 서비스들을 순차적으로 기동해주세요. 순서는 ActiveMQ -> RPA 서비스 -> Tomcat 순으로 실행하세요.

MS-SQL용 DB Schema 설치

MS-SQL용 DB Schema 설치 진행

상용 솔루션인 MS-SQL 2019 Server의 설치작업은 Brity RPA에서 지원해드리지 않습니다.

설치 이후에 Brity RPA Orchestrator의 DB Schema 설치를 진행하기 위해서는 MS-SQL이 기동 상태여야 하고, 데이터베이스 생성 및 사용자 생성 권한이 있는 사용자 계정을 준비해주셔야 합니다.

지원가능 MS-SQL 은 2019 버전입니다.
MS-SQL 용 rpa 초기 데이터 구성 시, 별도로 제공되는 MSSQL DB Installer 프로그램을 이용합니다.
DB 스키마는 rpa 데이터베이스에 설치됩니다. (rpa 데이터베이스가 이미 존재하는 경우 drop 필요)
신규 설치 실패 시 database drop 후 재설치해주셔야 합니다.
설치시 추가되는 사용자 계정들 : admin, auth, catalog, rpa, inerface, {추가되는 태넌트아이디}_rpa
설치된 MS-SQL 서버에 성능을 위해 Read committed snapshot 설정을 진행하세요.
MS-SQL용 activemq는 DB 설정이 달라지기 떼문에 제공되는 패키지 파일을 이용해서 설치하거나 수정해야합니다.

Read committed snapshot 설정 방법

MS-SQL DB에 접속하신 후, 아래의 쿼리문을 적용시켜주세요.

select is_read_committed_snapshot_on from sys.databases where name = N'rpa';
use master;
alter database rpa set single_user with rollback immediate;
alter database rpa set read_committed_snapshot on;
alter database rpa set multi_user;
select is_read_committed_snapshot_on from sys.databases where name = N'rpa';

DB data 또는 주요 로그파일 저장 분리

Maria DB의 data 파일 위치 변경

DB의 data를 별도의 스토리지로 분리해서 운영하려는 경우 아래의 파일내용을 변경해주면 해당 위치에 data 파일이 쌓이게 됩니다.

변경 대상 파일 : /rpa/pkgs/mariadb/conf/mysqld.conf

MariaDB를 먼저 stop 시킨 후, 상기 mysqld.conf 파일을 에디터로 열고 datadir 속성의 경로 정보를 원하는 스토리지 경로로 변경해주고 다시 기동시켜주면 됩니다

로그파일 저장경로 변경

MariaDB 로그파일 저장 정보 변경
- 변경 대상 파일 : /rpa/pkgs/mariadb/conf/mysqld.conf
- 변경 경로 속성 (3개)

server_audit_file_path
slow_query_log_file
log-error

Tomcat access 로그파일 저장 정보 변경
- 변경 대상 파일 : /rpa/pkgs/tomcat/conf/server.xml
- 변경 정보 : directory

<Valve className="org.apache.catalina.valves.AccessLogValve" directory="/DATA/rpa/logs/admin" prefix="admin_access_log" suffix=".txt" 이하 생략>

Tomcat 로그파일 저장 정보 변경
- 변경 대상 파일 : /rpa/pkgs/tomcat/conf/logging.properties
- 변경 정보 (4개) : directory

1catalina.org.apache.juli.AsyncFileHandler.directory = /DATA/rpa/logs/admin
2localhost.org.apache.juli.AsyncFileHandler.directory = /DATA/rpa/logs/admin
3manager.org.apache.juli.AsyncFileHandler.directory = /DATA/rpa/logs/admin
4host-manager.org.apache.juli.AsyncFileHandler.directory = /DATA/rpa/logs/admin

Tomcat catalina.out 로그파일 저장 정보 변경
- 변경 대상 파일 : /rpa/pkgs/tomcat/bin/catalina.sh
- 변경 정보

. CATALINA_OUT=/DATA/rpa/logs/admin/catalina.out

RPA AP의 logs 하위 로그파일 저장 정보 변경
- 변경 대상 파일 : /rpa/apps 하위에 있는 각 서비스용 구동 run.sh (총 8개)
- 변경 정보

. java -jar -DDEV_HOME=/DATA/rpa/logs

이중화 설치 방법

L4 스위치를 앞 단에 두고 두대의 RPA AP 서버와 한대의 ActiveMQ와 한대의 DB 서버에 구성하는 경우를 예시로 설명합니다. 
ActiveMQ와 DB 이중화는 필요 시 별도로 구성해야 합니다.

** 3.1 버젼 부터 전체 모듈에 대해 Active-Active의 부하 분산 형태의 클러스터로 동작합니다. **

L4 설정

8080 포트로 접속하는 Web Portal에 대해 ip_hash 설정 적용 권장
공인 인증서 적용시 L7(L4) 스위치 8080, 8777, 9001 포트에 인증서 적용

LB Method 설정 예시
VIP	VPort	Protocal	RIP	RPort	LB Method	Service Module
Virtual IP	8080	TCP https	Real IP 1	8080	ip_hash	Web Portal
Virtual IP	8080	TCP https	Real IP 2	8080	ip_hash	Web Portal
Virtual IP	8777	TCP https	Real IP 1	8777	Least Connection, RR, ip_hash	Gateway
Virtual IP	8777	TCP https	Real IP 2	8777	Least Connection, RR, ip_hash	Gateway
Virtual IP	9001	TCP https	Real IP 1	9001	Least Connection, RR, ip_hash	Communication
Virtual IP	9001	TCP https	Real IP 2	9001	Least Connection, RR, ip_hash	Communication
Virtual IP	9091	TCP http	Real IP 1	9091	Least Connection, RR, ip_hash	Auth
Virtual IP	9091	TCP http	Real IP 2	9091	Least Connection, RR, ip_hash	Auth
Virtual IP	9093	TCP http	Real IP 1	9093	Least Connection, RR, ip_hash	Scheduler
Virtual IP	9093	TCP http	Real IP 2	9093	Least Connection, RR, ip_hash	Scheduler
Virtual IP	9096	TCP http	Real IP 1	9096	Least Connection, RR, ip_hash	Core
Virtual IP	9096	TCP http	Real IP 2	9096	Least Connection, RR, ip_hash	Core
Virtual IP	9099	TCP http	Real IP 1	9099	Least Connection, RR, ip_hash	Tenant
Virtual IP	9099	TCP http	Real IP 2	9099	Least Connection, RR, ip_hash	Tenant
Virtual IP	9094	TCP http	Real IP 1	9094	Least Connection, RR, ip_hash	Workflow
Virtual IP	9094	TCP http	Real IP 2	9094	Least Connection, RR, ip_hash	Workflow
Virtual IP	9098	TCP	Real IP 1	9098	Least Connection, RR, ip_hash	Batch
Virtual IP	9098	TCP	Real IP 2	9098	Least Connection, RR, ip_hash	Batch

Brity RPA v3.1 변경사항

- 모든 서비스는 Active-Active 이중화 지원함

(기존 v3.0 이전에는 comm, workflow 서비스는 Active-Standby 이중화)

- Batch 서비스 추가됨

방화벽 설정

RPA BOT → L4스위치(8777, 9001)
PA Designer → L4스위치(8777)
Portal 접속 PC → L4스위치(8080, 9001)

AP 서버와 DB 서버 간 방화벽 설정
- AP1 서버 → DB 서버(4406)
- AP2 서버 → DB 서버(4406)

L4 스위치와 서버 간 방화벽 설정
- L4 ↔ Server1 8080 8777 9001 9091 9093 9096 9099 9094, 9098
- L4 ↔ Server2 8080 8777 9001 9091 9093 9096 9099 9094, 9098

설치 방법

DB 서버에 Custom 설치를 이용하여 MariaDB를 설치하고 Install the RPA v3.0.0_hotfix DB schema를 수행하세요. 이때 DB 서버 아이피를 127.0.0.1이 아닌 실제 DB 서버의 아이피로 입력하세요.
AP1 서버에 ActiveMQ, Tomcat을 설치하세요. Install the RPA v3.0.0_hotfix Service application단계에서 설치 옵션에 DB 서버 IP를 변경하고 Redundant Server : Y, Redundant Server type : 1 로 설정하세요.
API GW의 정보는 일반적으로 VIP를 지정해주며, ActiveMQ는 AP1의 IP를 지정해줍니다.
AP2 서버에 Tomcat을 설치하세요. Install the RPA v3.0.0_hotfix Service application단계에서 설치옵션에 DB서버 IP를 변경하고 Redundant Server : Y, Redundant Server type : 2로 설정하세요.
Redundant Server 2로 선택됨에 따라 내부적으로 인증서가 AP1 서버과 분리되어 설정됩니다.
API GW의 정보는 일반적으로 VIP를 지정해주며, ActiveMQ는 AP1의 IP를 지정해줍니다.
3개의 comm.properties에서 Portal SSO Properties 항목들에서 각 서버의 Real IP로 세팅이 되어있는 부분이 있다면 VIP로 변경해주세요. -> 참조 : 프로퍼티 추가 변경
AP1 서버의 ActiveMQ, RPA AP, Tomcat을 실행하세요..
AP2서버의 RPA AP, Tomcat을 실행하세요.

설정 추가 작업

[작업1] 
커뮤니케이션, 프로세스플로우 서버 이중화 하기 위한 변경
AP1/AP2 서버에 아래의 작업들을 수행해주세요. 
각 프로퍼티 파일들에 대한 추가적인 속성 등록을 해줘야 합니다.
- 변경 대상 파일 : /rpa/properties/application.properties

vi 에디터 등으로 파일을 열고, 아래의 내용을 append 추가합니다.

workflow.redundancy_configuration=Y

#게이트웨이 포트
server.vPort=8777

#게이트웨이 IP (= L4 스위치 아이피)
server.domain=182.193.17.123

- 파일 생성하여 추가 : /rpa/apps/gateway/addconfig.properties

파일을 생성하여 vi 에디터 등으로 파일을 열고, 아래의 내용을 추가합니다.

spring.cloud.loadbalancer.enabled=true
spring.application.name=gateway
spring.cloud.loadbalancer.health-check.refetch-instances=true
spring.cloud.loadbalancer.health-check.refetch-instances-interval=5S
rpa.server.communication.url=lb://communication
spring.cloud.loadbalancer.health-check.path.communication=${ipa.server.contextPath.communication}/version
#실제 1번 커뮤니케이션 서버 IP/port
spring.cloud.discovery.client.simple.instances.communication[0].uri=https://182.193.17.111:9001
#실제 2번 커뮤니케이션 서버 IP/port
spring.cloud.discovery.client.simple.instances.communication[1].uri=https://182.193.17.222:9001

- 변경대상 파일 : /rpa/apps/gateway/run.sh

vi 에디터 등으로 파일을 열고, 아래의 내용을 수정합니다.

java -jar -DDEV_HOME=/data/rpa/logs -Xms2G -Xmx2G spring.config.location=/data/rpa/properties/application.properties,classpath:/application.properties rpago_api_gateway.jar &
==>
java -jar -DDEV_HOME=/data/rpa/logs -Xms2G -Xmx2G spring.config.location=/data/rpa/properties/application.properties,classpath:/application.properties,./addconfig.properties  rpago_api_gateway.jar &

[작업2] 
선택사항으로 작업의 난이도가 높아 안정화 상태에서 시도해야함 
오케스트레이터 포털서버 세션을 공유하기 위한 작업 (선택사항)
포털을 순차 재기동해도 포털 사용자는 추가적인 로그인이 필요하지 않음
AP1/AP2 서버에 아래의 작업들을 수행해주세요. 

- 변경 대상 파일 : 
/rpa/apps/admin/admin/WEB-INF/classes/config/applicationContext-security.xml
/rpa/apps/admin/tenant/WEB-INF/classes/config/applicationContext-security.xml
/rpa/apps/admin/user/WEB-INF/classes/config/applicationContext-security.xml
vi 에디터 등으로 파일을 열고, 아래의 내용을 수정 합니다.

line 154
    <bean id="rpaSessionRegistry" class="org.springframework.security.core.session.SessionRegistryImpl" />
==> 교체
 <bean id="rpaSessionRegistry" class="org.springframework.session.security.SpringSessionBackedSessionRegistry">
    <constructor-arg ref="sessionRepository"/>
  </bean>

- 변경 대상 파일 : 
/rpa/apps/admin/admin/WEB-INF/web.xml
/rpa/apps/admin/tenant/WEB-INF/web.xml
/rpa/apps/admin/user/WEB-INF/web.xml
vi 에디터 등으로 파일을 열고, 아래의 내용의 주석을 제거합니다.

line 140 149 주석 제거
    <filter>
        <filter-name>springSessionRepositoryFilter</filter-name>
        <filter-class>org.springframework.web.filter.DelegatingFilterProxy</filter-class>
    </filter>
    <filter-mapping>
        <filter-name>springSessionRepositoryFilter</filter-name>
        <url-pattern>/*</url-pattern>
    </filter-mapping>

- 파일 추가 : 
/rpa/apps/admin/admin/WEB-INF/classes/properties/jdbcsession.properties
/rpa/apps/admin/tenant/WEB-INF/classes/properties/jdbcsession.properties
/rpa/apps/admin/user/WEB-INF/classes/properties/jdbcsession.properties
파일을 생성하여 에디터 등으로 파일을 열고, 아래의 내용의 추가 합니다.

#1800초 30분
portal.session.timeout=1800

- 오케스트레이터 세션 공유를 위한 테이블 생성 쿼리 수행 :
JDBC Session 데이터 저장을 위해 catalog schema에 아래의 테이블을 생성한다.
tb_spring_session_admin
tb_spring_session_admin_attributes
tb_spring_session_tenant
tb_spring_session_tenant_attributes
tb_spring_session_user
tb_spring_session_user_attributes
첨부파일을 참조합니다. mariaDB 와 SqlServer 데이터베이스에 대한 쿼리를 제공합니다.

첨부 RPA Jdbc Session Table DB Script.txt

[작업3]
RPA Gateway 서비스를 통한 RPA 서비스 이중화설정 방법
Gateway 서비스가 이중화가 된 상태에서 설정해야함

설정파일 : /rpa/apps/gateway/addconfig.properties

spring.cloud.loadbalancer.enabled=true
spring.application.name=gateway
spring.cloud.loadbalancer.health-check.refetch-instances=true
spring.cloud.loadbalancer.health-check.refetch-instances-interval=5S

rpa.server.communication.url=lb://communication
spring.cloud.loadbalancer.health-check.path.communication=${ipa.server.contextPath.communication}/version
spring.cloud.discovery.client.simple.instances.communication[0].uri=https://182.193.17.111:9001
spring.cloud.discovery.client.simple.instances.communication[1].uri=https://182.193.17.222:9001

rpa.server.auth.url=lb://auth
spring.cloud.loadbalancer.health-check.path.auth=/auth/version
spring.cloud.discovery.client.simple.instances.auth[0].uri=http://182.193.17.111:9091
spring.cloud.discovery.client.simple.instances.auth[1].uri=http://182.193.17.222:9091

rpa.server.asset.url=lb://asset
spring.cloud.loadbalancer.health-check.path.asset=${ipa.server.contextPath.asset}/version
spring.cloud.discovery.client.simple.instances.asset[0].uri=http://182.193.17.111:9096
spring.cloud.discovery.client.simple.instances.asset[1].uri=http://182.193.17.222:9096

rpa.server.scheduler.url=lb://scheduler
spring.cloud.loadbalancer.health-check.path.scheduler=${ipa.server.contextPath.scheduler}/version
spring.cloud.discovery.client.simple.instances.scheduler[0].uri=http://182.193.17.111:9093
spring.cloud.discovery.client.simple.instances.scheduler[1].uri=http://182.193.17.222:9093

rpa.server.workflow.url=lb://workflow
spring.cloud.loadbalancer.health-check.path.workflow=${ipa.server.contextPath.workflow}/version
spring.cloud.discovery.client.simple.instances.workflow[0].uri=http://182.193.17.111:9094
spring.cloud.discovery.client.simple.instances.workflow[1].uri=http://182.193.17.222:9094

rpa.server.ocr.url=lb://ocr
spring.cloud.loadbalancer.health-check.path.ocr=${ipa.server.contextPath.ocr}/version
spring.cloud.discovery.client.simple.instances.ocr[0].uri=http://182.193.17.111:9095
spring.cloud.discovery.client.simple.instances.ocr[1].uri=http://182.193.17.222:9095

rpa.server.interface.url=lb://interface
spring.cloud.loadbalancer.health-check.path.interface=${ipa.server.contextPath.interface}/version
spring.cloud.discovery.client.simple.instances.interface[0].uri=http://182.193.17.111:9096
spring.cloud.discovery.client.simple.instances.interface[1].uri=http://182.193.17.222:9096

rpa.server.event.url=lb://event
spring.cloud.loadbalancer.health-check.path.event=${ipa.server.contextPath.event}/version
spring.cloud.discovery.client.simple.instances.event[0].uri=http://182.193.17.111:9096
spring.cloud.discovery.client.simple.instances.event[1].uri=http://182.193.17.222:9096

rpa.server.batch.url=lb://batch
spring.cloud.loadbalancer.health-check.path.batch=${ipa.server.contextPath.batch}/version
spring.cloud.discovery.client.simple.instances.batch[0].uri=http://182.193.17.111:9098
spring.cloud.discovery.client.simple.instances.batch[1].uri=http://182.193.17.222:9098

rpa.server.tenant.url=lb://tenant/tenant
spring.cloud.loadbalancer.health-check.path.tenant=${ipa.server.contextPath.tenant}/version
spring.cloud.discovery.client.simple.instances.tenant[0].uri=http://182.193.17.111:9099
spring.cloud.discovery.client.simple.instances.tenant[1].uri=http://182.193.17.222:9099

rpa.server.workflow.websocket.http.url=lb://workflow/workflow/webdesigner/processflow/connect
rpa.server.workflow.websocket.url=lb://workflow/webdesigner/**

MariaDB를 별도로 설치/관리하는 경우

규모가 큰 고객사에서는 DB를 전담으로 관리 운용하는 부서가 따로 존재하는 경우가 있으며, 이런 경우 고객사의 DBA가 직접 별도의 DB서버에 MariaDB를 설치/구성하는 경우가 있습니다.

이 경우에는 아래의 필수 설정값들이 누락없이 적용될 수 있도록 반드시 사전에 DBA측에 요청을 해주셔야 합니다.

DB Config 설정

설치 패키지를 통하지 않고 MariaDB 를 자체 설치한 경우 다음과 같은 DB Config 가 적용 되어야 합니다.
설치 경로 등이 다른 경우 고객 자체적으로 변경 적용해야 됩니다..

[client]
port = 4406
default-character-set = utf8

[mysqld]
datadir = /rpa/pkgs/mariadb/data
basedir = /rpa/pkgs/mariadb
explicit_defaults_for_timestamp = 1
log_bin_trust_function_creators=1
open_files_limit = 20480
plugin_load=server_audit=server_audit.so
server_audit_file_path = /rpa/logs/mariadb/server_audit.log
server_audit_file_rotate_size = 104857600
server_audit_events = CONNECT
server_audit_logging = ON
max_connections = 5000
max_allowed_packet = 64M
init_connect = SET collation_connection = utf8_general_ci
init_connect = SET NAMES utf8
character-set-server = utf8
collation-server = utf8_general_ci
lower_case_table_names = 1
user = ipaadm
port = 4406
pid-file = /rpa/pkgs/mariadb/conf/mysqld.pid
log-output=FILE
slow-query-log=1
slow_query_log_file=/rpa/logs/mariadb/mariadb-slow.log
long_query_time=30
log-error=/rpa/logs/mariadb/mariadb.err
default-time-zone='+0:00'

[mysqldump]
default-character-set = utf8

[mysql]
default-character-set = utf8

프로퍼티 추가 변경

RPA 서비스에서 사용하는 프로퍼티 파일들은 크게 2종류가 있으며, 프로퍼티 내용들은 설치과정 중에 입력하는 인프라 정보로 대부분 설정이 완료되지만 설치 환경에 따라서 일부 속성값들을 변경해줘야하는 경우가 있습니다.

application.properties의 경우는 크게 바꿀 부분이 없지만, Web Portal과 관련한 comm.properties의 경우, 아래 항목들을 검토하고 필요시 변경해야합니다.
(RPA의 설치 home을 /rpa 라고 가정한 예시)

comm.properties (3개가 동일)

경로 : /rpa/apps/admin/tenant/WEB-INF/classes/properties/comm.properties
     /rpa/apps/admin/user/WEB-INF/classes/properties/comm.properties
     /rpa/apps/admin/admin/WEB-INF/classes/properties/comm.properties

Web Portal의 접속 포트를 기본 8080을 사용하지 않는 경우
Portal SSO 관련 속성값들을 클라이언트에서 실제 Web 접속하는 URL로 맞춰서 세팅합니다.
(VIP를 사용한다면 VIP로 입력하고, L4에서 443 포트를 받아서 뒤로 8080으로 던진다면 https 기본포트인 443은 생략가능)
아래는 VIP로 접속을 하고, 포트는 8090으로 변경하여 접속하는 예시입니다.

#Portal SSO Properties
portalSSO=true
portal.sso.authUrl=https://서버VIP:8090/user/auth
portal.sso.adminLoginUrl=https://서버VIP:8090/admin/portal/sso
portal.sso.tenantLoginUrl=https://서버VIP:8090/tenant/portal/sso
portal.sso.userLoginUrl=https://서버VIP:8090/user/portal/sso
portal.sso.logout=https://서버VIP:8090/user/portal/logoutFilter
portal.sso.adminLogoutUrl=https://서버VIP:8090/admin/logoutProcess
portal.sso.tenantLogoutUrl=https://서버VIP:8090/tenant/logoutProcess
portal.sso.userLogoutUrl=https://서버VIP:8090/user/logoutProcess

실제 Tomcat 구동 port도 8090으로 변경되어야 하는 경우라면 Tomcat의 환경설정 파일(server.xml)도 함께 바꿔주어야 합니다. 

경로 : /rpa/pkgs/tomcat/conf/server.xml

아래는 Tomcat의 접속 port를 8090으로 변경하는 예시입니다.

<Connector port="8090"
scheme="https" secure="true" SSLEnabled="true" 이하생략

삼성그룹 관계사 설치인 경우에만 추가해줘야할 속성
아래의 속성값을 3개의 comm.properties 파일 내에 명시적으로 추가해주어야만 테넌트 포탈의 환경설정 메뉴에서 “KNOX 연계” 라는 항목이 나타나게 됩니다.
이 속성값은 기본 설치를 완료해도 프로퍼티 파일에 들어있지 않기 때문에 마지막 줄에 수동으로 입력해주어야 합니다

useKnox=true