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.16.tgz apache-tomcat-9.0.83.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를 눌러서 순차적으로 모든 설정값들을 원하는 값으로 변경할 수 있습니다. Gateway server address에는 반드시 설치하는 서버의 실제 IP로 지정을 해주셔야 합니다. Queue server address와 Database server address의 경우는 실제 서버 IP로 지정하는 것을 권장하지만, 한대의 서버에 모두 단일 설치하는 일반적인 경우라면 이 두가지 속성은 127.0.0.1의 로컬호스트 주소를 유지해도 지장은 없습니다. 전체 설정값들이 모두 이상이 없다면, 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.1.1. 를 선택하세요
RPA 서비스 어플리케이션을 먼저 설치하기 위해 1) Install the RPA v3.1.1 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.1.1. 를 다시 선택하고, 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.1.1. 를 다시 선택하고, 3) Install the RPA v3.1.1 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.1.1 database schema 설치가 정상적으로 수행되었음을 확인하세요.
# 모든 설치가 완료되었습니다.
설치 HOME의 메뉴 중, 3) Update Brity RPA v3.1.1 메뉴는 기존에 하위 버전 Brity RPA를 사용중인 환경에서 RPA AP만 업데이트 설치하는 메뉴입니다. 신규 설치에는 사용되지 않고, 구 버전을 업데이트 설치하는 경우 수행하며 오픈소스의 변경없이 RPA 서비스와 DB 스키마 등을 업데이트합니다.
RPA AP 서버와 DB 서버 분리
방화벽 설정
어플리케이션(AP) 서버와 DB 서버가 분리된 환경에 설치하는 경우, 반드시 DB서버의 4406 포트에 대한 통신이 가능해야 합니다.
AP 서버와 DB 서버 간 방화벽 설정: AP 서버 → DB 서버(4406)
설치 방법
아래의 작업들은 설치 프로그램중 Custom 설치 스크립트를 이용해야 합니다.
DB 서버 작업
Setup Program에서 "1) Install Opensource Program" -> "1) install Mariadb"를 이용하여 MariaDB를 먼저 설치하세요. 설치가 완료된 후에는 MariaDB가 자동으로 기동됩니다.
MariaDB가 설치완료되면, 다시 한번 Setup Program에서 "2) Install new Brity RPA v3.1.1" -> "3) Install the RPA v3.1.1 DB schema."를 수행하세요. 이 때 반드시 DB 서버 IP를 127.0.0.1 이 아닌 실제 DB 서버의 IP로 입력하세요..
AP 서버 작업
Setup Program에서 "1) Install Opensource Program" -> "2) install Tomcat"을 이용하여 Tomcat을 설치하세요.
이어서 Setup Program에서 "1) Install Opensource Program" -> "3) install ActiveMq"를 이용하여 Tomcat을 설치하세요.
Tomcat과 ActiveMQ는 설치완료 후, 자동으로 기동되지 않습니다.
오픈소스 설치에 이어 RPA 솔루션을 설치합니다. Setup Program에서 "2) Install new Brity RPA v3.1.1." -> "1) Install the RPA v3.1.1 Service application."를 이용하여 RPA 서비스를 설치하세요.
마지막으로, Setup Program에서 "2) Install new Brity RPA v3.1.1." -> "2) Install the RPA v3.1.1 Web application."를 이용하여 RPA 웹포탈을 설치하세요. 이 때 반드시 DB 서버 IP를 127.0.0.1 이 아닌 실제 DB 서버의 IP로 입력하세요.
서비스들을 순차적으로 기동해주세요. 순서는 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 이중화는 필요 시 별도로 구성해야 합니다. ♦ v3.1 부터는 전체 모듈에 대해 Active-Active의 부하 분산 형태의 클러스터로 동작합니다.
L4 설정
8080 포트로 접속하는 Web Portal에 대해 IP_Hash 설정 적용
공인 인증서 적용시 L7(L4) 스위치 8080, 8777, 9001 포트에 인증서 적용 (HTTPS 사용)
Web Portal을 제외한 다른 서비스들은 IP_Hash, Least Connection, Roound Robin 중에 자유롭게 택1하여 적용해도 무방
Text Recognition (OCR)의 이중화에 대한 사전검토 권고 : Abbyy 라이선스가 2개 필요
VIP | VPort | Protocal | RIP | RPort | LB Method | Service Module |
|---|---|---|---|---|---|---|
Virtual IP | 8080 | TCP HTTPS | Real IP 1 | 8080 | IP_Hash | Web Portal |
Real IP 2 | ||||||
Virtual IP | 8777 | TCP HTTPS | Real IP 1 | 8777 | IP_Hash / Least Connection / Round Robin | Gateway |
Real IP 2 | ||||||
Virtual IP | 9001 | TCP HTTPS | Real IP 1 | 9001 | IP_Hash / Least Connection / Round Robin | Communication |
Real IP 2 | ||||||
Virtual IP | 9091 | TCP HTTP | Real IP 1 | 9091 | IP_Hash / Least Connection / Round Robin | Auth |
Real IP 2 | ||||||
Virtual IP | 9093 | TCP HTTP | Real IP 1 | 9093 | IP_Hash / Least Connection / Round Robin | Scheduler |
Real IP 2 | ||||||
Virtual IP | 9094 | TCP HTTP | Real IP 1 | 9094 | IP_Hash / Least Connection / Round Robin | Workflow |
Real IP 2 | ||||||
Virtual IP | 9095 | TCP HTTP | Real IP 1 | 9095 | IP_Hash / Least Connection / Round Robin | Text Recognition |
Real IP 2 | ||||||
Virtual IP | 9096 | TCP HTTP | Real IP 1 | 9096 | IP_Hash / Least Connection / Round Robin | Core |
Real IP 2 | ||||||
Virtual IP | 9098 | TCP HTTP | Real IP 1 | 9098 | IP_Hash / Least Connection / Round Robin | Batch |
Real IP 2 | ||||||
Virtual IP | 9099 | TCP HTTP | Real IP 1 | 9099 | IP_Hash / Least Connection / Round Robin | Tenant |
Real IP 2 |
Brity RPA v3.1 변경사항
- 모든 서비스는 Active-Active 이중화 지원함
(기존 v3.0 이전에는 comm, workflow 서비스는 Active-Standby 이중화)
- Batch 서비스 추가됨
- Text Recognition (OCR)을 사용하지 않거나 라이선스가 2개 확보되지 않은 고객사에서는 9095 포트에 대한 L4 작업은 불필요
방화벽 설정
RPA BOT → L4스위치(8777, 9001)
RPA Designer → L4스위치(8777)
Portal 접속 PC → L4스위치(8080, 8777, 9001)
AP 서버와 DB 서버 간 방화벽 설정
AP1 서버 → DB 서버(4406)
AP2 서버 → DB 서버(4406)
L4 스위치와 서버 간 방화벽 설정
L4 → Server1 (8080, 8777, 9001, 9091, 9093, 9095, 9096, 9098, 9099)
L4 → Server2 (8080, 8777, 9001, 9091, 9093, 9095, 9096, 9098, 9099)
설치 방법
DB 서버에 Custom 설치를 이용하여 MariaDB를 설치하고 Install the RPA v3.1.1 DB schema를 수행하세요. 이때 DB 서버 아이피를 127.0.0.1이 아닌 실제 DB 서버의 IP로 입력하세요.
AP1 서버에 ActiveMQ, Tomcat을 설치하세요. Install the RPA v3.1.1 Service application단계에서 설치 옵션에 DB 서버 IP를 변경하고 Redundant Server : Y, Redundant Server type : 1 로 설정하세요.
API GW의 정보는 일반적으로 VIP를 지정해주며, ActiveMQ는 AP1의 IP를 지정해줍니다.
AP2 서버에 Tomcat을 설치하세요. Install the RPA v3.1.1 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을 실행하세요.
(필수) 추가 설정 작업
[프로퍼티 생성/변경 작업] AP1와 AP2 양쪽 모두에 아래의 작업내용을 적용해주세요. 1) Communication, Workflow 이중화를 위한 속성 추가/변경 - 변경 대상 파일 : /rpa/properties/application.properties vi 에디터로 대상 파일을 열고, 아래의 내용을 추가합니다. (기존에 속성이 정의되어 있는 경우는 수정, 기존에 해당 속성이 없는 경우에는 추가)
workflow.redundancy_configuration=Y #게이트웨이 포트 server.vPort=8777 #게이트웨이 IP (= L4 스위치 아이피) server.domain=182.193.17.123
2) Gateway 서비스 하위에 추가 프로퍼티 파일 신규 생성 - 신규파일 생성 위치 : /rpa/apps/gateway/addconfig.properties 파일을 생성하여 vi 에디터로 파일을 열고, Communication 서비스 이중화 및 포털 웹디자이너 사용을 위해 아래 내용을 추가합니다 예시에서 AP1_IP에는 실제 1번 AP서버의 Real IP를 넣어주고, AP2_IP에는 2번 AP서버의 Real IP를 넣어줍니다.
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://AP1_IP:9001
spring.cloud.discovery.client.simple.instances.communication[1].uri=https://AP2_IP:9001
rpa.server.workflow.websocket.http.url=lb://workflow/workflow/webdesigner/processflow/connect
rpa.server.workflow.websocket.url=lb://workflow/webdesigner/**3) 신규 추가한 addconfig.properties 설정 파일이 Gateway 서비스에서 로딩되도록 실행 shell 을 수정 - 변경 대상 파일 : /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 &
(선택 가능) Gateway를 활용한 방식의 이중화 서비스 확대
Gateway를 활용하여 기타 서비스들에 의한 이중화를 확대 적용하는 것도 가능합니다. Gateway와 Communication을 제외한 RPA 서비스들은 고유 포트에 대해 L4 설정작업을 하지 않더라도 Gateway를 통해 분배가 되어 이중화가 가능합니다. (Gateway는 L4 설정을 통해 반드시 이중화가 구성된 상태에서 적용) 서버정보를 예시로 AP1과 AP2 서버의 정보가 아래와 같을 때, * AP1 IP : 182.193.17.111 * AP2 IP : 182.193.17.222 - 설정파일 : /rpa/apps/gateway/addconfig.properties vi 에디터로 파일을 열고, 아래의 내용에서 원하는 서비스 모듈을 선택 추가해줍니다. 아래의 예시는 RPA 전체 서비스를 등록한 샘플입니다. 필수적으로 등록해줘야 하는 Communication 이외에도 RPA의 다른 서비스 모듈들을 추가로 등록하여 Gateway를 통한 이중화를 구현 가능하기 때문에 L4설정을 통해서 전체 이중화를 적용할지 Gateway 설정을 확대할지는 검토 후 선택하시면 됩니다.
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:9001rpa.server.workflow.websocket.http.url=lb://workflow/workflow/webdesigner/processflow/connect rpa.server.workflow.websocket.url=lb://workflow/webdesigner/** 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
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.propertiesWeb 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
logback.xml 설정(custom appender)
RPA의 각 서비스들은 logback.xml을 이용하여 log 저장 정책을 관리하고 있습니다. 파일관련 로그 정책 외에도 DB에 Log를 저장하는 custom appender를 관리하고, 이렇게 저장된 Log는 테넌트 포털 "서버 모니터링" 화면에서 확인 할 수 있습니다.
Batch, OCR 서비스에는 사용하지 않습니다.
프로퍼티 값 사용 방법(Web Portal) Web Portal의 경우 comm.properties 파일의 속성들을 사용 가능 합니다. logback.xml 파일 상단에 아래 속성 추가(default로 추가되어 있음), comm.propterties 경로가 변경된 경우 수정이 필요합니다.
<property resource="properties/comm.properties" />
프로퍼티 값 사용 방법(Web Portal 제외한 서비스들) application.properties 파일의 속성들을 사용 가능 합니다. logback.xml 파일 상단에 <springProperty> 태그를 이용하여 사용할 속성들을 정의합니다.
<springProperty name="serverPort" source="server.port"/> <springProperty name="loggingServerProtocol" source="ipa.server.scheme"/> <springProperty name="loggingServerIp" source="ipa.server.ip"/> <springProperty name="loggingServerPort" source="ipa.server.port"/> <springProperty name="loggingServerContextPath" source="ipa.server.contextPath.batch"/>
batch서버 정보 수정 LogHttpAppender는 현재 서버의 포트정보와 로그 정보를 저장 할 서비스(Batch서비스)의 정보가 필요합니다. 아래는 Web Portal의 logback.xml로 서버포트 정보(포털은 8080)와 Batch 서버 정보를 저장, 변경 할 수 있습니다. Batch 서버 정보는 comm.properties에 정의된 속성 값을 사용하고 있으며, 변경이 가능합니다.
<appender name="logHttp" class="com.sds.rpa.lib.appender.LogHttpAppender">
<serverPort>8080</serverPort>
<loggingServerProtocol>${gateway.server.protocol}</loggingServerProtocol>
<loggingServerIp>${gateway.server.ip}</loggingServerIp>
<loggingServerPort>${gateway.server.port}</loggingServerPort>
<loggingServerContextPath>/batch</loggingServerContextPath>
</appender>Web Portal을 제외한 서비시들의 logback.xml 예시입니다. logback 상단에 정의한 <springProperty> 변수들을 사용할 수 있습니다. gateway의 경우 loggingServer의 정보가 gateway ip, port가 아닌 Batch서버로의 직접 호출이 가능한 정보를 사용합니다.
<appender name="logHttp" class="com.sds.rpa.lib.appender.LogHttpAppender">
<serverPort>${serverPort}</serverPort>
<loggingServerProtocol>${loggingServerProtocol}</loggingServerProtocol>
<loggingServerIp>${loggingServerIp}</loggingServerIp>
<loggingServerPort>${loggingServerPort}</loggingServerPort>
<loggingServerContextPath>${loggingServerContextPath}</loggingServerContextPath>
</appender>Log level 변경 및 log 옵션 수정
DB에 저장할 로그 레벨을 <filter> 하위 <level> 태그에서 변경할 수 있습니다. 기본으로 ERROR 레벨로 설정되어 있습니다.
ERROR레벨이 아닌 경우 DB에 많은 데이터가 저장되어 시스템 성능 하락에 원인이 될 수 있습니다.
includerCallerData: caller 정보를 추가로 보여주는 옵션이며, 현재는 caller 정보를 따로 사용하지 않으므로 false 상태를 유지합니다. true 사용 시 성능에 크게 하락할 수 있습니다.
queueSize: Appender가 로그 전송 중 보관하는 Queue의 사이즈 옵션도 변경 가능합니다. 해당 사이즈 이상의 정보가 대기하는 경우 나머지는 저장되지 않습니다.
neverBlock: false로 설정한 경우 Queue가 가득찬 상황에서 appneder는 메시지 유실을 방지하기 위해 application을 block. true로 설정하면 메시지를 버립니다.
maxFlushTime: LoggerContext이 정지하면 AsyncApperder의 stop 메소드는 작업 스레드가 timeout 될 때 까지 대기하는데, maxflushTime을 설정하면 해당시간 안에 처리 못한 이벤트는 삭제합니다.
<appender name="HTTP-APPENDER" class="ch.qos.logback.classic.AsyncAppender">
<filter class="ch.qos.logback.classic.filter.ThresholdFilter">
<level>ERROR</level>
</filter>
<includeCallerData value="false"/>
<queueSize value="2048"/>
<neverBlock value="true"/>
<maxFlushTime value="60000"/>
<appender-ref ref="logHttp"/>
</appender>Appender 사용 여부
추가된 DB저장용 appender의 사용 여부도 설정할 수 있습니다.
logback.xml 하단에 logger 정보 중 해당 appender 정보를 추가하면 사용, 제거하면 사용하지 않습니다.
<logger name="com.sds.ipa" level="DEBUG" additivity="false">
<appender-ref ref="FILE-AUDIT" />
<appender-ref ref="FILE-ERROR"/>
<appender-ref ref="STDOUT" />
<appender-ref ref="HTTP-APPENDER" />
</logger>