에서 고가용성 PeopleSoft 아키텍처 설정 AWS - AWS 권장 가이드
요약사전 조건 및 제한 사항아키텍처도구모범 사례에픽관련 리소스

기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

에서 고가용성 PeopleSoft 아키텍처 설정 AWS

작성자: Ramanathan Muralidhar(AWS)

환경: 프로덕션

기술: 비즈니스 생산성, 인프라, 웹 및 모바일 앱, 데이터베이스

워크로드: Oracle

AWS 서비스: Amazon EC2 Auto Scaling , Amazon EFS, Elastic Load Balancing(ELB), Amazon RDS

요약

PeopleSoft 워크로드를 로 마이그레이션할 때 AWS복원력이 중요한 목표입니다. 이를 통해 PeopleSoft 애플리케이션을 항상 고가용성으로 유지하고 장애로부터 신속하게 복구할 수 있습니다.

이 패턴은 의 PeopleSoft 애플리케이션에 대한 아키텍처AWS를 제공하여 네트워크, 애플리케이션 및 데이터베이스 계층에서 고가용성(HA)을 보장합니다. Oracle용 Amazon Relational Database Service(Amazon RDS) 또는 데이터베이스 계층용 Amazon RDS for SQL Server 데이터베이스를 사용합니다. 이 아키텍처에는 Amazon Route 53, Amazon Elastic Compute Cloud(Amazon EC2) Linux 인스턴스, Amazon Elastic Block Storage(Amazon EBS), Amazon Elastic File System(Amazon EFS) 및 Application Load Balancer와 같은 AWS 서비스도 포함되며 확장 가능합니다.

Oracle PeopleSoft은 인력 관리 및 기타 비즈니스 운영을 위한 도구 및 애플리케이션 제품군을 제공합니다.

사전 조건 및 제한 사항

사전 조건 

  • 활성 AWS 계정

  • 에서 설정하는 데 필요한 라이선스가 있는 PeopleSoft 환경 AWS

  • 다음 리소스를 사용하여 AWS 계정에 설정된 가상 프라이빗 클라우드(VPC)입니다.

    • 최소 두 개의 가용 영역

    • 각 가용 영역에 1개의 퍼블릭 서브넷과 3개의 프라이빗 서브넷

    • NAT 게이트웨이 및 인터넷 게이트웨이

    • 트래픽을 라우팅하기 위한 각 서브넷의 라우팅 테이블

    • 조직의 표준에 따라 PeopleSoft 애플리케이션의 보안을 보장하는 데 도움이 되도록 정의된 네트워크 액세스 제어 목록(네트워크 ACLs) 및 보안 그룹

제한 사항

  • 이 패턴은 고가용성(HA) 솔루션을 제공합니다. 재해 복구(DR) 시나리오는 지원하지 않습니다. 드물게 HA 구현의 전체 AWS 리전이 다운되는 경우 애플리케이션을 사용할 수 없게 됩니다.

제품 버전

  • PeopleSoft PeopleTools 8.52 이상을 실행하는 애플리케이션

아키텍처

대상 아키텍처

PeopleSoft 프로덕션 애플리케이션의 가동 중지 또는 중단은 애플리케이션의 가용성에 영향을 미치고 비즈니스에 큰 지장을 초래합니다.

항상 가용성이 높도록 PeopleSoft 프로덕션 애플리케이션을 설계하는 것이 좋습니다. 단일 장애 지점을 제거하고, 신뢰할 수 있는 크로스오버 또는 장애 조치를 추가하고, 장애를 감지함으로써 이를 달성할 수 있습니다. 다음 다이어그램은 의 에 대한 HA 아키텍처 PeopleSoft 를 보여줍니다AWS.

PeopleSoft 의 에 대한 고가용성 아키텍처 AWS

이 아키텍처 배포는 Amazon RDS for Oracle을 PeopleSoft 데이터베이스로 사용하고 Red Hat Enterprise Linux()에서 실행되는 EC2 인스턴스를 사용합니다RHEL. Amazon RDS for SQL Server를 Peoplesoft 데이터베이스로 사용할 수도 있습니다.

이 아키텍처에는 다음 구성 요소가 포함됩니다. 

  • Amazon Route 53은 인터넷에서 PeopleSoft 애플리케이션으로 요청을 라우팅하기 위한 도메인 이름 서버(DNS)로 사용됩니다.

  • AWS WAF 는 가용성에 영향을 미치거나 보안을 손상시키거나 과도한 리소스를 소비할 수 있는 일반적인 웹 악용 및 봇으로부터 보호합니다. AWS Shield Advanced(미도시)는 훨씬 광범위한 보호를 제공합니다.

  • 웹 서버를 대상으로 하는 고급 요청 라우팅이 포함된 Application Load Balancer 로드 밸런서 HTTP 및 HTTPS 트래픽입니다.

  • PeopleSoft 애플리케이션을 지원하는 웹 서버, 애플리케이션 서버, 프로세스 스케줄러 서버 및 Elasticsearch 서버는 여러 가용 영역에서 실행되고 Amazon EC2 Auto Scaling을 사용합니다.

  • PeopleSoft 애플리케이션에서 사용하는 데이터베이스는 다중 AZ 구성으로 AmazonRDS에서 실행됩니다.

  • PeopleSoft 애플리케이션에서 사용하는 파일 공유는 AmazonEFS에서 구성되며 인스턴스 전반의 파일에 액세스하는 데 사용됩니다.

  • Amazon Machine Images(AMIs)는 Amazon EC2 Auto Scaling에서 필요할 때 PeopleSoft 구성 요소를 빠르게 복제하는 데 사용됩니다.

  • NAT 게이트웨이는 프라이빗 서브넷의 인스턴스를 외부의 서비스에 연결하고 외부 서비스가 해당 인스턴스와의 연결을 시작할 수 VPC없도록 합니다.

  • 인터넷 게이트웨이는 와 VPC 인터넷 간의 통신을 허용하는 수평적으로 확장되고 중복되며 가용성이 높은 VPC 구성 요소입니다.

  • 퍼블릭 서브넷의 배스천 호스트는 인터넷 또는 온프레미스 네트워크와 같은 외부 네트워크에서 프라이빗 서브넷의 서버에 대한 액세스를 제공합니다. 배스천 호스트는 프라이빗 서브넷의 서버에 대한 제어되고 안전한 액세스를 제공합니다.

아키텍처 세부 정보

PeopleSoft 데이터베이스는 다중 AZ 구성의 Amazon RDS for Oracle(또는 Amazon RDS for SQL Server) 데이터베이스에 저장됩니다. Amazon RDS 다중 AZ 기능은 두 가용 영역에 걸쳐 데이터베이스 업데이트를 복제하여 내구성과 가용성을 높입니다. Amazon은 계획된 유지 관리 및 예기치 않은 중단을 위해 자동으로 대기 데이터베이스에 RDS 장애 조치합니다.

PeopleSoft 웹 및 중간 계층은 EC2 인스턴스에 설치됩니다. 이러한 인스턴스는 여러 가용 영역에 분산되어 있으며 오토 스케일링으로 묶여 있습니다. 이렇게 하면 이러한 구성 요소의 가용성이 항상 높아집니다. 애플리케이션을 항상 사용할 수 있고 필요할 때 확장할 수 있도록 필요한 최소 인스턴스 수를 유지합니다.

OEM EC2 인스턴스에 현재 세대 EC2 인스턴스 유형을 사용하는 것이 좋습니다. AWS Nitro 시스템 에 구축된 인스턴스와 같은 현재 세대 인스턴스 유형은 하드웨어 가상 머신()을 지원합니다HVMs. HVM AMIs 는 향상된 네트워킹 을 활용하는 데 필요하며 향상된 보안 기능도 제공합니다. 각 Auto Scaling 그룹의 일부인 EC2 인스턴스는 인스턴스를 교체하거나 확장할 AMI 때 자체 인스턴스를 사용합니다. PeopleSoft 애플리케이션이 처리할 부하와 PeopleSoft 애플리케이션 및 PeopleTools 릴리스에 대해 Oracle에서 권장하는 최소값을 기준으로 EC2 인스턴스 유형을 선택하는 것이 좋습니다. 하드웨어 및 소프트웨어 요구 사항에 대한 자세한 내용은 Oracle 지원 웹 사이트를 참조하십시오.

PeopleSoft 웹 및 중간 계층은 Amazon EFS 마운트를 공유하여 보고서, 데이터 파일 및 (필요한 경우) PS_HOME 디렉터리를 공유합니다. AmazonEFS은 성능 및 비용상의 이유로 각 가용 영역에 탑재 대상으로 구성됩니다.

Application Load Balancer는 PeopleSoft 애플리케이션에 액세스하고 다양한 가용 영역에 걸쳐 웹 서버 간의 트래픽을 로드 밸런싱하는 트래픽을 지원하도록 프로비저닝됩니다. Application Load Balancer는 최소 2개의 가용 영역에서 HA를 제공하는 네트워크 장치입니다. 웹 서버는 부하 분산 구성을 사용하여 서로 다른 애플리케이션 서버로 트래픽을 분산합니다. 웹 서버와 애플리케이션 서버 간의 부하 분산을 통해 인스턴스 전체에 부하가 고르게 분산되고 인스턴스 과부하로 인한 병목 현상과 서비스 중단을 방지할 수 있습니다.

Amazon Route 53은 인터넷에서 Application Load Balancer로 트래픽을 라우팅하는 DNS 서비스로 사용됩니다. Route 53은 가용성과 확장성이 뛰어난 DNS 웹 서비스입니다.

HA 세부 정보

  • 데이터베이스: Amazon의 다중 AZ 기능은 동기 복제를 사용하여 여러 가용 영역에서 두 개의 데이터베이스를 RDS 운영합니다. 이렇게 하면 자동 장애 조치가 가능한 가용성이 높은 환경이 만들어집니다. AmazonRDS은 장애 조치 이벤트 감지 기능을 갖추고 있으며 이러한 이벤트가 발생할 때 자동 장애 조치를 시작합니다. Amazon RDS 를 통해 수동 장애 조치를 시작할 수도 있습니다API. 자세한 설명은 Amazon RDS Under The Hood: Multi-AZ 블로그 게시물을 참조하세요. 장애 조치가 원활하며 장애 조치 발생 시 애플리케이션이 자동으로 데이터베이스에 다시 연결됩니다. 하지만 장애 조치 중에 발생하는 모든 프로세스 스케줄러 작업은 오류를 생성하므로 다시 제출해야 합니다.

  • PeopleSoft 애플리케이션 서버: 애플리케이션 서버는 여러 가용 영역에 분산되어 있으며 Auto Scaling 그룹이 정의되어 있습니다. 인스턴스가 실패하면 Auto Scaling 그룹이 즉시 애플리케이션 서버 템플릿AMI의 에서 복제된 정상 인스턴스로 교체합니다. 특히 부트 풀링이 활성화되어 있으므로 애플리케이션 서버 인스턴스가 다운되면 세션이 자동으로 다른 애플리케이션 서버로 장애 조치되고 Auto Scaling 그룹이 자동으로 다른 인스턴스를 스핀업하고 애플리케이션 서버를 가져와 Amazon EFS 마운트에 등록합니다. 새로 생성된 애플리케이션 서버는 웹 서버의 PSSTRSETUP.SH 스크립트를 사용하여 웹 서버에 자동으로 추가됩니다. 이렇게 하면 애플리케이션 서버의 가용성이 항상 높고 장애 발생 시 신속하게 복구할 수 있습니다.

  • 프로세스 스케줄러: 프로세스 스케줄러 서버는 여러 가용 영역에 분산되어 있으며 이를 위해 오토 스케일링이 정의되어 있습니다. 인스턴스가 실패하면 Auto Scaling 그룹이 즉시 프로세스 스케줄러 서버 템플릿AMI의 에서 복제된 정상 인스턴스로 교체합니다. 특히, 프로세스 스케줄러 인스턴스가 다운되면 오토 스케일링은 자동으로 다른 인스턴스를 가동시키고 프로세스 스케줄러를 불러옵니다. 인스턴스에 장애가 발생했을 때 실행 중이었던 모든 작업을 다시 제출해야 합니다. 이렇게 하면 프로세스 스케줄러가 항상 고가용성을 유지하고 장애로부터 빠르게 복구할 수 있습니다.

  • Elasticsearch 서버: Elasticsearch 서버에는 이들을 위한 오토 스케일링이 정의되어 있습니다. 인스턴스가 실패하면 Auto Scaling 그룹이 즉시 Elasticsearch 서버 템플릿AMI의 에서 복제된 정상 인스턴스로 교체합니다. 특히, Elasticsearch 인스턴스가 다운되면 요청을 처리하는 Application Load Balancer가 장애를 감지하고 해당 인스턴스로의 트래픽 전송을 중단합니다. 오토 스케일링은 자동으로 다른 인스턴스를 가동시키고 Elasticsearch 인스턴스를 불러옵니다. Elasticsearch 인스턴스가 백업되면 Application Load Balancer는 정상 상태임을 감지하고 다시 요청을 보내기 시작합니다. 이렇게 하면 Elasticsearch 서버가 항상 고가용성을 유지하고 장애로부터 빠르게 복구할 수 있습니다.

  • 웹 서버: 웹 서버에는 오토 스케일링이 정의되어 있습니다. 인스턴스가 실패하면 Auto Scaling 그룹이 즉시 웹 서버 템플릿AMI의 에서 복제된 정상 인스턴스로 교체합니다. 특히 웹 서버 인스턴스가 다운되면 요청을 처리하는 Application Load Balancer가 장애를 감지하고 해당 인스턴스에 대한 트래픽 전송을 중단합니다. 오토 스케일링은 자동으로 다른 인스턴스를 가동시키고 웹 서버 인스턴스를 불러옵니다. 웹 서버 인스턴스가 백업되면 Application Load Balancer는 정상 상태임을 감지하고 요청을 다시 보내기 시작합니다. 이렇게 하면 웹 서버의 가용성이 항상 높아지고 장애로부터 신속하게 복구할 수 있습니다.

도구

AWS 서비스

모범 사례

운영 모범 사례

  • PeopleSoft 에서 를 실행할 때 Route 53을 AWS사용하여 인터넷 및 로컬에서 트래픽을 라우팅합니다. 기본 DB 인스턴스를 사용할 수 없는 경우 장애 조치 옵션을 사용하여 트래픽을 재해 복구(DR) 사이트로 다시 라우팅합니다.

  • 항상 PeopleSoft 환경 앞에 Application Load Balancer를 사용합니다. 이렇게 하면 트래픽이 웹 서버로 안전하게 로드 밸런싱됩니다.

  • Application Load Balancer 대상 그룹 설정에서 로드 밸런서가 생성한 쿠키로 고정성이 켜져 있는지 확인합니다.

    참고: 외부 Single Sign-On()을 사용하는 경우 애플리케이션 기반 쿠키를 사용해야 할 수 있습니다SSO. 이렇게 하면 웹 서버와 애플리케이션 서버 간에 연결이 일관되게 유지됩니다.

  • PeopleSoft 프로덕션 애플리케이션의 경우 Application Load Balancer 유휴 제한 시간은 사용하는 웹 프로필에 설정된 시간과 일치해야 합니다. 이렇게 하면 로드 밸런서 계층에서 사용자 세션이 만료되는 것을 방지할 수 있습니다.

  • PeopleSoft 프로덕션 애플리케이션의 경우 애플리케이션 서버 휴지 수를 메모리 누수를 최소화하는 값으로 설정합니다.

  • 이 패턴에 설명된 대로 PeopleSoft 프로덕션 애플리케이션에 Amazon RDS 데이터베이스를 사용하는 경우 고가용성을 위해 다중 AZ 형식으로 실행하십시오.

  • 데이터베이스가 PeopleSoft 프로덕션 애플리케이션의 EC2 인스턴스에서 실행 중인 경우 고가용성을 위해 대기 데이터베이스가 다른 가용 영역에서 실행되고 있는지 확인합니다.

  • DR의 경우 Amazon RDS 데이터베이스 또는 EC2 인스턴스에 프로덕션 데이터베이스와 별도의 AWS 리전에 구성된 대기가 있는지 확인합니다. 이렇게 하면 해당 지역에 재해가 발생할 경우 애플리케이션을 다른 리전으로 전환할 수 있습니다.

  • DR의 경우 Amazon Elastic 재해 복구를 사용하여 프로덕션 구성 요소와는 별도의 지역에 애플리케이션 수준 구성 요소를 설정할 수 있습니다. 이렇게 하면 해당 지역에 재해가 발생하는 경우 애플리케이션을 다른 지역으로 전환할 수 있습니다.

  • AmazonEFS(보통 I/O 요구 사항의 경우) 또는 AmazonFSx(높은 I/O 요구 사항의 경우)을 사용하여 PeopleSoft 보고서, 첨부 파일 및 데이터 파일을 저장합니다. 이를 통해 콘텐츠가 한 곳에 중앙 위치에 저장되고 인프라 내 어느 곳에서나 액세스할 수 있습니다.

  • Amazon CloudWatch(기본 및 세부 정보)을 사용하여 PeopleSoft 애플리케이션이 거의 실시간으로 사용하고 있는 AWS 클라우드 리소스를 모니터링합니다. 이렇게 하면 문제에 대해 즉시 알림을 받고 환경 가용성에 영향을 미치기 전에 문제를 신속하게 해결할 수 있습니다.

  • Amazon RDS 데이터베이스를 데이터베이스로 사용하는 경우 Enhanced Monitoring을 PeopleSoft 사용합니다. 이 기능은 CPU, 메모리, 파일 시스템 I/O 및 디스크 I/O를 포함하여 50개 이상의 지표에 대한 액세스를 제공합니다.

  • AWS CloudTrail 를 사용하여 PeopleSoft 애플리케이션이 사용 중인 AWS 리소스에 대한 API 호출을 모니터링합니다. 이를 통해 보안 분석, 리소스 변경 추적 및 규정 준수 감사를 수행할 수 있습니다.

보안 모범 사례

  • SQL 주입 또는 사이트 간 스크립팅(XSS)과 같은 일반적인 악용으로부터 PeopleSoft 애플리케이션을 보호하려면 AWS WAF를 사용합니다. 맞춤형 탐지 및 완화 서비스를 위해 AWS Shield Advanced를 사용하는 것이 좋습니다.

  • Application Load Balancer에 규칙을 추가하여 에서 HTTPS 자동으로 HTTP 로 트래픽을 리디렉션하여 PeopleSoft 애플리케이션을 보호합니다.

  • Application Load Balancer에 대해 별도의 보안 그룹을 설정합니다. 이 보안 그룹은 HTTPS/HTTP 인바운드 트래픽만 허용하고 아웃바운드 트래픽은 허용하지 않아야 합니다. 이렇게 하면 의도된 트래픽만 허용되고 애플리케이션을 보호하는 데 도움이 됩니다.

  • 애플리케이션 서버, 웹 서버 및 데이터베이스에 프라이빗 서브넷을 사용하고 아웃바운드 인터넷 트래픽에 NAT 게이트웨이를 사용합니다. 이렇게 하면 애플리케이션을 지원하는 서버에 공개적으로 접속할 수 없고 필요한 서버에만 퍼블릭 액세스를 제공할 수 있습니다.

  • 다른 VPCs를 사용하여 PeopleSoft 프로덕션 환경과 비프로덕션 환경을 실행합니다. AWS Transit Gateway , VPC 피어링 , 네트워크 ACLs및 보안 그룹을 사용하여 와 필요한 VPC경우 온프레미스 데이터 센터 간의 트래픽 흐름을 제어합니다.

  • 최소 권한 원칙을 따르십시오. 애플리케이션이 절대적으로 필요한 사용자에게만 PeopleSoft 애플리케이션에서 사용하는 AWS 리소스에 대한 액세스 권한을 부여합니다. 작업을 수행하는 데 필요한 최소 권한만 부여합니다. 자세한 내용은 AWS Well-Architected Framework의 보안 요소를 참조하세요.

  • 가능하면 AWS Systems Manager를 사용하여 PeopleSoft 애플리케이션이 사용하는 EC2 인스턴스에 액세스합니다.

안정성 모범 사례

  • Application Load Balancer를 사용하는 경우 활성화된 각 가용 영역에 대해 단일 대상을 등록하십시오. 따라서 로드 밸런서가 가장 효과적입니다.

  • 각 PeopleSoft 프로덕션 환경에URLs는 애플리케이션에 액세스URL하기 위한 환경, 통합 브로커를 서비스하기 위한 환경, 보고서를 보기 위한 환경 등 세 가지 구분이 있는 환경이 권장됩니다. 가능하면 각 에는 전용 웹 서버와 애플리케이션 서버가 있어야 URL 합니다. 이 설계는 각 애플리케이션에 고유한 기능과 제어된 액세스 URL 권한이 있기 때문에 PeopleSoft 애플리케이션을 더 안전하게 만드는 데 도움이 됩니다. 또한 기본 서비스에 장애가 발생할 경우 영향을 받을 수 있는 범위를 최소화합니다.

  • PeopleSoft 애플리케이션의 로드 밸런서 대상 그룹에 대한 상태 확인을 구성하는 것이 좋습니다. 상태 확인은 해당 서버를 실행하는 EC2 인스턴스 대신 웹 서버에서 수행해야 합니다. 이렇게 하면 웹 서버가 충돌하거나 웹 서버를 호스팅하는 EC2 인스턴스가 다운되면 Application Load Balancer가 해당 정보를 정확하게 반영합니다.

  • PeopleSoft 프로덕션 애플리케이션의 경우 웹 서버를 3개 이상의 가용 영역에 분산하는 것이 좋습니다. 이렇게 하면 가용 영역 중 하나가 다운되더라도 PeopleSoft 애플리케이션을 항상 고가용성으로 유지할 수 있습니다.

  • PeopleSoft 프로덕션 애플리케이션의 경우 부트 풀링()을 활성화합니다joltPooling=true. 이렇게 하면 패치 적용 목적 또는 VM 장애로 인해 서버가 다운되는 경우 애플리케이션이 다른 애플리케이션 서버로 페일오버될 수 있습니다.

  • PeopleSoft 프로덕션 애플리케이션의 경우 를 1DynamicConfigReload 로 설정합니다. 이 설정은 PeopleTools 버전 8.52 이상에서 지원됩니다. 서버를 다시 시작하지 않고도 웹 서버에 새 애플리케이션 서버를 동적으로 추가합니다.

  • PeopleTools 패치를 적용할 때 가동 중지 시간을 최소화하려면 웹 및 애플리케이션 서버의 Auto Scaling 그룹 시작 구성에 블루/그린 배포 방법을 사용합니다. 자세한 내용은 백서의 배포 옵션 개요를 참조하세요AWS.

  • AWS 백업을 사용하여 에서 PeopleSoft 애플리케이션을 백업합니다AWS. AWS 백업은 대규모 데이터 보호를 간소화하는 비용 효율적이고 완전 관리형 정책 기반 서비스입니다.

성능 모범 사례

  • 비즈니스에서 PeopleSoft 환경 전체에서 암호화된 트래픽이 필요하지 않는 한 환경의 최적 성능을 위해 Application Load BalancerSSL에서 를 종료합니다.

  • Amazon Simple Notification Service(AmazonSNS) 및 와 같은 AWS 서비스에 대한 인터페이스 VPC 엔드포인트를 생성CloudWatch하여 트래픽이 항상 내부가 되도록 합니다. 이는 비용 효율적이며 애플리케이션을 안전하게 유지하는 데 도움이 됩니다.

비용 최적화 모범 사례

  • PeopleSoft 환경에서 사용하는 모든 리소스에 태그를 지정하고 비용 할당 태그 를 활성화합니다. 이러한 태그를 통해 리소스 비용을 확인하고 관리할 수 있습니다.

  • PeopleSoft 프로덕션 애플리케이션의 경우 웹 서버와 애플리케이션 서버에 Auto Scaling 그룹을 설정합니다. 이렇게 하면 애플리케이션을 지원하는 웹 및 애플리케이션 서버 수를 최소한으로 유지할 수 있습니다. 오토 스케일링 정책을 사용하여 필요에 따라 서버를 확장하거나 축소할 수 있습니다.

  • 비용이 지정한 예산 임계값을 초과할 경우 청구 경보를 사용하여 알림을 받을 수 있습니다.

지속가능성 모범 사례

  • 인프라를 코드로 사용하여(IaC ) PeopleSoft 환경을 유지 관리합니다. 이를 통해 일관된 환경을 구축하고 변경 관리를 유지할 수 있습니다.

에픽

작업설명필요한 기술

DB 서브넷 그룹을 생성합니다.

Amazon RDS 콘솔 의 탐색 창에서 서브넷 그룹 을 선택한 다음 여러 가용 영역에 서브넷이 있는 Amazon RDS DB 서브넷 그룹을 생성합니다. 이는 Amazon RDS 데이터베이스가 다중 AZ 구성으로 실행되기 위해 필요합니다.

클라우드 관리자

Amazon RDS 데이터베이스를 생성합니다.

PeopleSoft HA 환경에 대해 선택한 AWS 리전의 가용 영역에 Amazon RDS 데이터베이스를 생성합니다. Amazon RDS 데이터베이스를 생성할 때 다중 AZ 옵션(대기 인스턴스 생성)과 이전 단계에서 생성한 데이터베이스 서브넷 그룹을 선택해야 합니다. 자세한 내용은 Amazon RDS 설명서 를 참조하세요.

클라우드 관리자, Oracle 데이터베이스 관리자

PeopleSoft 데이터베이스를 Amazon 로 마이그레이션합니다RDS.

PeopleSoft Database Migration ServiceAWS( )를 사용하여 기존 AWS 데이터베이스를 Amazon RDS 데이터베이스로 마이그레이션합니다DMS. 자세한 내용은 AWS DMS 설명서와 AWS 블로그 게시물 를 사용하여 가동 중지 시간이 거의 없는 Oracle 데이터베이스 마이그레이션AWS을 참조하세요DMS.

클라우드 관리자, PeopleSoft DBA
작업설명필요한 기술

파일 시스템을 생성합니다.

Amazon EFS 콘솔 에서 각 가용 영역에 대한 파일 시스템 및 탑재 대상을 생성합니다. 지침은 Amazon EFS 설명서 를 참조하세요. 파일 시스템이 생성되면 DNS 이름을 기록해 둡니다. 파일 시스템을 탑재할 때 이 정보를 사용합니다.

클라우드 관리자
작업설명필요한 기술

EC2 인스턴스를 시작합니다.

PeopleSoft 애플리케이션의 EC2 인스턴스를 시작합니다. 지침은 Amazon EC2 설명서 를 참조하세요.

  • 이름에 APP_TEMPLATE을 입력합니다.

  • OS 이미지의 경우 Red Hat을 선택하십시오.

  • 인스턴스 유형 에서 PeopleSoft 애플리케이션에 적합한 인스턴스 유형을 선택합니다. 자세한 내용은 아키텍처 섹션의 아키텍처 세부 정보를 참조하십시오.

클라우드 관리자, PeopleSoft 관리자

인스턴스 PeopleSoft 에 를 설치합니다.

생성한 EC2 인스턴스 PeopleTools 에 PeopleSoft 애플리케이션 및 를 설치합니다. 지침은 Oracle 설명서를 참조하십시오.

클라우드 관리자, PeopleSoft 관리자

애플리케이션 서버를 생성합니다.

AMI 템플릿의 애플리케이션 서버를 생성하고 템플릿이 Amazon RDS 데이터베이스에 성공적으로 연결되었는지 확인합니다.

클라우드 관리자, PeopleSoft 관리자

Amazon EFS 파일 시스템을 탑재합니다.

루트 사용자로 EC2 인스턴스에 로그인하고 다음 명령을 실행하여 Amazon EFS 파일 시스템을 서버에 라는 폴더에 탑재PSFTMNT합니다.

sudo su –
mkdir /psftmnt
cat /etc/fstab

/etc/fstab 파일에 다음 줄을 추가합니다. 파일 시스템을 생성할 때 기록한 DNS 이름을 사용합니다.

fs-09e064308f1145388.efs.us-east-1.amazonaws.com:/ /psftmnt nfs4 nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport,_netdev 0 0
mount -a
클라우드 관리자, PeopleSoft 관리자

권한을 확인합니다.

PeopleSoft 사용자가 폴더에 제대로 액세스할 수 있도록 PSFTMNT 폴더에 적절한 권한이 있는지 확인합니다.

클라우드 관리자, PeopleSoft 관리자

인스턴스를 더 생성합니다.

이 에픽의 이전 단계를 반복하여 프로세스 스케줄러, 웹 서버 및 Elasticsearch 서버용 템플릿 인스턴스를 생성합니다. 이들 인스턴스의 이름을 PRCS_TEMPLATE, WEB_TEMPLATE, SRCH_TEMPLATE(으)로 지정합니다. 웹 서버의 경우 joltPooling=true 및 DynamicConfigReload=1을(를) 설정합니다.

클라우드 관리자, PeopleSoft 관리자
작업설명필요한 기술

애플리케이션 서버를 설치하는 스크립트를 생성합니다.

Amazon EC2 APP_TEMPLATE 인스턴스에서 PeopleSoft 사용자로서 다음 스크립트를 생성합니다. 이름을 appstart.sh(으)로 지정하고 PS_HOME 디렉터리에 배치합니다. 이 스크립트를 사용하여 애플리케이션 서버를 가져오고 Amazon EFS 마운트에 서버 이름도 기록합니다.

#!/bin/ksh
. /usr/homes/hcmdemo/.profile.
psadmin -c configure -d HCMDEMO
psadmin -c parallelboot -d HCMDEMO
touch /psftmnt/`echo $HOSTNAME`
PeopleSoft 관리자

스크립트를 생성하여 프로세스 스케줄러 서버를 설치합니다.

Amazon EC2 PRCS_TEMPLATE 인스턴스에서 PeopleSoft 사용자로서 다음 스크립트를 생성합니다. 이름을 prcsstart.sh(으)로 지정하고 PS_HOME 디렉터리에 배치합니다. 이 스크립트를 사용하여 프로세스 스케줄러 서버를 불러올 수 있습니다.

#!/bin/ksh
. /usr/homes/hcmdemo/. profile
/* The following line ensures that the process scheduler always has a unique name during replacement or scaling activity. */ 
sed -i "s/.*PrcsServerName.*/`hostname -I | awk -F. '{print "PrcsServerName=PSUNX"$3$4}'`/" $HOME/appserv/prcs/*/psprcs.cfg
psadmin -p configure -d HCMDEMO
psadmin -p start -d HCMDEMO
PeopleSoft 관리자

스크립트를 생성하여 Elasticsearch 서버를 설치하세요.

Amazon EC2 SRCH_TEMPLATE 인스턴스에서 Elasticsearch 사용자로 다음 스크립트를 생성합니다. 이름을 srchstart.sh(으)로 지정하고 HOME 디렉터리에 배치합니다.

#!/bin/ksh
/* The following line ensures that the correct IP is indicated in the elasticsearch.yaml file. */
sed -i "s/.*network.host.*/`hostname  -I | awk '{print "host:"$0}'`/" $ES_HOME_DIR/config/elasticsearch.yaml
nohup $ES_HOME_DIR/bin/elasticsearch &
PeopleSoft 관리자

웹 서버를 설치하는 스크립트를 생성합니다.

Amazon EC2 WEB_TEMPLATE 인스턴스의 웹 서버 사용자로서 HOME 디렉터리에 다음 스크립트를 생성합니다.

renip.sh: 이 스크립트는 에서 복제할 때 웹 서버에 올바른 IP가 있는지 확인합니다AMI.

#!/bin/ksh
hn=`hostname`
/* On the following line, change the IP with the hostname with the hostname of the web template. */
for text_file in `find  *  -type f -exec grep -l '<hostname-of-the-web-template>' {} \;`
do
sed -e 's/<hostname-of-the-web-template>/'$hn'/g' $text_file > temp
mv -f temp $text_file
done

psstrsetup.sh: 이 스크립트는 웹 서버가 현재 실행 IPs 중인 올바른 애플리케이션 서버를 사용하도록 합니다. 충격 포트의 각 애플리케이션 서버에 연결을 시도하여 구성 파일에 추가합니다.

#!/bin/ksh
c2=""
for ctr in `ls -1 /psftmnt/*.internal`
do
c1=`echo $ctr | awk -F "/" '{print $3}'`
/* In the following lines, 9000 is the jolt port. Change it if necessary. */
if nc -z $c1 9000 2> /dev/null; then
if [[ $c2 = "" ]]; then
c2="psserver="`echo $c1`":9000"
else
c2=`echo $c2`","`echo $c1`":9000"
fi
fi
done

webstart.sh: 이 스크립트는 두 개의 이전 스크립트를 실행하고 웹 서버를 시작합니다.

#!/bin/ksh
/* Change the path in the following if necessary. */
cd  /usr/homes/hcmdemo 
./renip.sh
./psstrsetup.sh
webserv/peoplesoft/bin/startPIA.sh
PeopleSoft 관리자

crontab 항목을 추가합니다.

Amazon EC2 WEB_TEMPLATE 인스턴스에서 웹 서버 사용자로서 crontab 에 다음 줄을 추가합니다. 필요한 값을 반영하도록 시간과 경로를 변경하십시오. 이 항목을 사용하면 웹 서버의 configuration.properties 파일에 항상 올바른 애플리케이션 서버 항목이 포함될 수 있습니다.

* * * * * /usr/homes/hcmdemo/psstrsetup.sh
PeopleSoft 관리자
작업설명필요한 기술

애플리케이션 서버 템플릿에 AMI 대한 을 생성합니다.

Amazon EC2 콘솔에서 Amazon EC2 APP_TEMPLATE 인스턴스의 AMI 이미지를 생성합니다. 의 이름을 AMI 지정합니다PSAPPSRV-SCG-VER1. 지침은 Amazon EC2 설명서 를 참조하세요.

클라우드 관리자, PeopleSoft 관리자

다른 서버에 AMIs 대해 를 생성합니다.

이전 단계를 반복하여 프로세스 스케줄러, Elasticsearch 서버 및 웹 서버에 AMIs 대해 를 생성합니다.

클라우드 관리자, PeopleSoft 관리자

애플리케이션 서버 오토 스케일링 그룹에 대한 시작 템플릿을 만듭니다.

애플리케이션 서버 오토 스케일링 그룹에 대한 시작 템플릿을 만듭니다. 템플릿 이름 지정 템플릿PSAPPSRV_TEMPLATE.에서 APP_TEMPLATE 인스턴스에 대해 AMI 생성한 을 선택합니다. 지침은 Amazon EC2 설명서 를 참조하세요.

  • 시작 템플릿에서 요구 사항에 따라 인스턴스 유형을 선택합니다.

  • 고급 세부 정보 섹션의 사용자 데이터 필드에 다음 항목을 추가합니다. 경로와 사용자 정보가 정확한지 확인합니다. 이전 단계에서 appstart.sh 스크립트를 만들었습니다.

    #! /bin/ksh
su -c “/usr/homes/hcmdemo/appstart.sh” - hcmdemo
클라우드 관리자, PeopleSoft 관리자

프로세스 스케줄러 서버 오토 스케일링에 대한 시작 템플릿을 생성합니다.

이전 단계를 반복하여 프로세스 스케줄러 서버 오토 스케일링에 대한 시작 템플릿을 생성합니다. 템플릿의 이름을 PSPRCS_TEMPLATE(으)로 지정합니다. 템플릿에서 프로세스 스케줄러에 대해 AMI 생성한 을 선택합니다.

  • 고급 세부 정보 섹션의 사용자 데이터 필드에 다음 항목을 추가합니다. 경로와 사용자 정보가 정확한지 확인합니다. 이전 단계에서 prcsstart.sh 스크립트를 만들었습니다.

    #! /bin/ksh
su -c “/usr/homes/hcmdemo/prcsstart.sh” - hcmdemo
클라우드 관리자, PeopleSoft 관리자

Elasticsearch 서버 오토 스케일링을 위한 시작 템플릿을 생성합니다.

이전 단계를 반복하여 Elasticsearch 서버 오토 스케일링에 대한 시작 템플릿을 생성합니다. 템플릿의 이름을 SRCH_TEMPLATE(으)로 지정합니다. 템플릿에서 검색 서버에 대해 AMI 생성한 을 선택합니다.

  • 고급 세부 정보 섹션의 사용자 데이터 필드에 다음 항목을 추가합니다. 경로와 사용자 정보가 정확한지 확인합니다. 이전 단계에서 srchstart.sh 스크립트를 만들었습니다.

    #! /bin/ksh
su -c “/usr/homes/essearch/srchstart.sh” - essearch
클라우드 관리자, PeopleSoft 관리자

웹 서버 오토 스케일링에 대한 시작 템플릿을 만듭니다.

이전 단계를 반복하여 웹 서버 오토 스케일링에 대한 시작 템플릿을 생성합니다. 템플릿의 이름을 WEB_TEMPLATE(으)로 지정합니다. 템플릿에서 웹 서버에 대해 AMI 생성한 을 선택합니다.

  • 고급 세부 정보 섹션의 사용자 데이터 필드에 다음 항목을 추가합니다. 경로와 사용자 정보가 정확한지 확인합니다. 이전 단계에서 webstart.sh 스크립트를 만들었습니다.

    #! /bin/ksh
su -c “/usr/homes/hcmdemo/webstart.sh” - hcmdemo
클라우드 관리자, PeopleSoft 관리자
작업설명필요한 기술

애플리케이션 서버를 위한 오토 스케일링을 생성합니다.

Amazon EC2 콘솔에서 PSAPPSRV_TEMPLATE 템플릿을 사용하여 애플리케이션 서버에 PSAPPSRV_ASG 대해 라는 Auto Scaling 그룹을 생성합니다. 지침은 Amazon EC2 설명서 를 참조하세요.

  • 인스턴스 시작 옵션 선택 페이지에서 올바른 항목을 VPC 선택한 다음 다른 가용 영역에서 여러 서브넷을 선택합니다.

  • 고급 옵션 구성 페이지에서 로드 밸런서를 선택하지 마십시오.

  • 그룹 크기 및 조정 정책 구성 페이지에서 시스템을 설계하려는 부하의 양과 조정 정책을 사용할지 여부에 따라 설정을 선택합니다. 원하는 용량과 최소 용량을 최소 2로 설정하여 언제든지 트래픽을 처리하는 데 사용할 수 있는 인스턴스가 하나 이상 있도록 하는 것이 좋습니다. Auto Scaling 정책에 대한 자세한 내용은 Amazon EC2 설명서 섹션을 참조하세요.

클라우드 관리자, PeopleSoft 관리자

다른 서버에 대한 오토 스케일링을 생성합니다.

이전 단계를 반복하여 프로세스 스케줄러, Elasticsearch 서버 및 웹 서버를 위한 오토 스케일링을 생성합니다.

클라우드 관리자, PeopleSoft 관리자
작업설명필요한 기술

웹 서버의 대상 그룹 생성

Amazon EC2 콘솔에서 웹 서버의 대상 그룹을 생성합니다. 자세한 내용은 Elastic 로드 밸런싱 설명서를 참조하세요. 포트를 웹 서버가 수신하는 포트로 설정합니다.

클라우드 관리자

상태 확인을 구성합니다.

상태 확인에 비즈니스 요구 사항을 반영하는 올바른 값이 있는지 확인합니다. 자세한 내용은 Elastic 로드 밸런싱 설명서를 참조하십시오.

클라우드 관리자

Elasticsearch 서버를 위한 대상 그룹을 생성합니다.

이전 단계를 반복하여 Elasticsearch 서버에 대해 PSFTSRCH이라는 대상 그룹을 생성하고 올바른 Elasticsearch 포트를 설정합니다.

클라우드 관리자

오토 스케일링에 대상 그룹을 추가합니다.

앞서 생성한 PSPIA_ASG 웹 서버 오토 스케일링을 엽니다. 로드 밸런싱 탭에서 편집을 선택한 다음 오토 스케일링에 PSFTWEB 대상 그룹을 추가합니다.

Elasticsearch 오토 스케일링 그룹 PSSRCH_ASG에 대해 이 단계를 반복하여 앞서 생성한 대상 그룹 PSFTSRCH을 추가합니다.

클라우드 관리자

세션 고정성을 설정합니다.

대상 그룹 PSFTWEB에서 속성 탭을 선택하고 편집 을 선택한 다음 세션 고정도를 설정합니다. 고정성 유형의 경우 로드 밸런서 생성 쿠키를 선택하고 기간을 1로 설정합니다. 자세한 내용은 Elastic Load Balancing 설명서를 참조하십시오.

대상 그룹 PSFTSRCH에 대해 단계를 반복합니다.

클라우드 관리자
작업설명필요한 기술

웹 서버용 로드 밸런서를 만듭니다.

웹 서버에 대한 트래픽을 로드 밸런싱하기 위해 PSFTLB로 이름이 지정된 Application Load Balancer를 생성합니다. 자세한 내용은 Elastic 로드 밸런싱 설명서를 참조하십시오.

  • 로드 밸런서 이름을 입력합니다.

  • 계획에서 인터넷 연결을 선택합니다.

  • 네트워크 매핑 섹션에서 서로 다른 가용 영역에서 올바른 퍼블릭 서브넷VPC과 최소 2개의 퍼블릭 서브넷을 선택합니다.

  • 리스너 및 라우팅 섹션에서 대상 그룹 PSFTWEB을(를) 선택하고 올바른 프로토콜과 포트 번호를 지정합니다.

클라우드 관리자

Elasticsearch 서버를 위한 로드 밸런서를 생성합니다.

Elasticsearch 서버로 향하는 트래픽을 로드 밸런싱하기 위해 PSFTSCH로 이름이 지정된 Application Load Balancer를 생성합니다.

  • 로드 밸런서 이름을 입력합니다.

  • 계획에서 내부 를 선택합니다.

  • 네트워크 매핑 섹션에서 올바른 VPC 프라이빗 서브넷을 선택합니다.

  • 리스너 및 라우팅 섹션에서 대상 그룹 PSFTSRCH을(를) 선택하고 올바른 프로토콜과 포트 번호를 지정합니다.

클라우드 관리자

Route 53을 구성합니다.

Amazon Route 53 콘솔 에서 PeopleSoft 애플리케이션을 서비스할 호스팅 영역에 레코드를 생성합니다. 지침은 Amazon Route 53 설명서를 참조하십시오. 이렇게 하면 모든 트래픽이 PSFTLB 로드 밸런서를 통과하게 됩니다.

클라우드 관리자

관련 리소스