Google은 AI 기술을 사용하여 콘텐츠를 사용자의 기본 언어로 번역합니다. AI 번역에는 오류가 있을 수 있습니다.

Apigee Edge 4.53.00 또는 4.53.01을 4.54.00으로 업데이트

Apigee는 버전 4.53.00 또는 4.53.01에서 버전 4.54.00으로 직접 프라이빗 클라우드용 Edge를 업그레이드하는 것을 지원합니다. 이 페이지에서는 이러한 업그레이드를 수행하는 방법을 설명합니다.

호환되는 업그레이드 경로에 대한 개요는 프라이빗 클라우드용 Edge 출시 버전의 업그레이드 호환성 매트릭스를 참조하세요.

업데이트를 실행할 수 있는 사용자

업데이트를 실행하는 사용자는 원래 Edge를 설치한 사용자와 동일하거나 루트로 실행하는 사용자여야 합니다.

Edge RPM을 설치한 후에는 누구나 구성할 수 있습니다.

업데이트해야 하는 구성요소

모든 Edge 구성요소를 업데이트해야 합니다. Edge는 여러 버전의 구성요소가 포함된 설정을 지원하지 않습니다.

사전 읽기 자료

프라이빗 클라우드용 Edge 4.54.00에 도입된 변경사항에 관한 중요한 정보는 다음 주제를 참고하세요.

4.54.00의 변경사항: 업그레이드 전에 준비가 필요한 TLS 및 Java 콜아웃의 변경사항을 검토하세요. 자세한 내용은 4.54.00의 변경사항을 참고하세요.
이중 Java 런타임 아키텍처 (Java 17 및 Java 21): 4.54.00부터 프라이빗 클라우드용 Edge는 Java 8 지원을 삭제하고 Java 17 또는 Java 21에서 구성요소를 실행합니다. 자세한 내용은 4.54.00의 변경사항을 참고하세요.
부트스트랩 중 자동 Java 설치 없음: 프라이빗 클라우드용 Edge 4.54.00에는 Java 설치를 검색하고 Java 17과 21이 모두 설치되어 있는지 확인하는 기능이 있습니다.
4.54.00의 새로운 Edge UI: 기본 관리 인터페이스로의 새로운 Edge UI 전환과 클래식 UI (edge-ui) 삭제에 대해 알아봅니다. 자세한 내용은 새 Edge UI를 참조하세요.
4.54.00의 Apigee SSO: 인증을 위한 업데이트된 SSO 아키텍처 및 구성 변경사항을 이해합니다. 자세한 내용은 Apigee SSO를 참조하세요.
4.54.00의 Nginx 1.30: Edge 라우터의 자동 Nginx 1.30.x 업그레이드, 잠재적인 런타임 영향, 완화 단계를 검토합니다. 자세한 내용은 Nginx 1.30 변경사항을 참고하세요.

업그레이드 사전 준비 사항

Apigee Edge를 업그레이드하기 전에 다음 기본 요건을 확인하세요.

출시 노트 및 새로운 기능 검토하기

업그레이드 프로세스를 시작하기 전에 프라이빗 클라우드용 Edge 버전 4.54.00 출시 노트에 자세히 설명된 모든 새로운 기능, 동작 변경사항, 지원 중단을 철저히 검토하고 이해해야 합니다.
업그레이드 중 자동 Java 바이너리 검색 및 공존: 표준 패키지 관리자 (예: yum) 또는 표준 위치 (예: /usr/lib/jvm 또는 update-alternatives)를 사용하여 Java를 설치합니다. 시스템 PATH에서 두 버전을 동시에 구성할 필요는 없습니다. 업그레이드하기 전에 Java 8을 제거하지 마세요. 기존 프라이빗 클라우드용 Edge 4.53.xx 서비스가 업데이트될 때까지 중단 없이 계속 실행되도록 Java 17 및 Java 21과 함께 Java 8을 설치된 상태로 유지합니다.
모든 노드 백업

업데이트하기 전에 안전을 위해 모든 노드를 완전히 백업하는 것이 좋습니다. 현재 버전의 Edge에 해당하는 절차를 사용하여 백업을 실행합니다. 이렇게 하면 새 버전으로의 업데이트가 제대로 작동하지 않는 경우에 대비한 백업 계획을 세울 수 있습니다. 백업에 관한 자세한 내용은 백업 및 복원을 참고하세요.
자동 구성 파일 백업

필요한 경우 롤백을 용이하게 하기 위해 프라이빗 클라우드용 Edge 4.53.00 또는 4.53.01의 자동 구성 파일 백업 사본이 유지되는지 확인합니다.
Edge가 실행 중인지 확인

다음 명령어를 사용하여 업데이트 프로세스 중에 Edge가 실행 중인지 확인합니다.
```
/opt/apigee/apigee-service/bin/apigee-all status
```
Cassandra 기본 요건 확인

이전에 이전 버전의 프라이빗 클라우드용 Edge에서 버전 4.53.00 (또는) 4.53.01로 업그레이드했고 이제 버전 4.54.00으로 업그레이드할 계획이라면 Cassandra에 필요한 업그레이드 후 단계를 완료했는지 확인하세요. 이 단계는 버전 4.53.00 또는 4.53.01 업그레이드 문서에 설명되어 있으며 Cassandra 업그레이드 필수사항에도 언급되어 있습니다. 이전 업그레이드 중에 이 단계가 완료되었는지 확실하지 않은 경우 버전 4.54.00으로 업그레이드를 진행하기 전에 다시 완료하세요.
apigee-monit 중지: apigee-monit가 노드에서 실행 중인 경우 업그레이드하기 전에 /opt/apigee/apigee-service/bin/apigee-service apigee-monit stop으로 중지합니다. 이렇게 하면 apigee-monit이 업그레이드 중에 구성요소를 자동으로 다시 시작하지 않습니다. 업그레이드가 완료된 후 apigee-service apigee-monit start로 다시 사용 설정합니다.

속성 설정 자동 전파

/opt/apigee/customer/application에서 .properties 파일을 수정하여 속성을 설정한 경우 업데이트를 통해 이러한 값이 유지됩니다.

라우터 및 메시지 프로세서 업그레이드

데이터 센터의 모든 라우터 및 메시지 프로세서 노드를 하나씩 업그레이드합니다.

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

관리 서버 업그레이드

데이터 센터의 모든 관리 서버 노드를 하나씩 업그레이드합니다.

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

OpenLDAP 2.6.10으로 업그레이드

프라이빗 클라우드용 Edge 4.54.00에는 OpenLDAP 2.6.10이 도입되었습니다. 이 업그레이드는 단일 서버, 활성-수동, 활성-활성 (멀티 마스터) 등 모든 Apigee OpenLDAP 배포 토폴로지에 적용됩니다.

준비 및 설치 (모든 LDAP 서버)

LDAP를 4.53.00에서 4.54.00으로 업그레이드하는 단계

기본 요건 및 고려사항

OpenLDAP 2.4~2.6.10 마이그레이션 프로세스 (4.53.00에서 업그레이드하는 경우) 중에는 모든 지역에서 관리 API를 사용할 수 없으며 따라서 Apigee UI도 사용할 수 없습니다. 사용자, 역할, 앱, 조직 관리와 같은 모든 관리 작업이 실패하며 일시중지해야 합니다. API 프록시 트래픽 처리에는 영향을 미치지 않습니다. LDAP 이전을 진행하기 전에 모든 edge-management-server 및 edge-ui 인스턴스를 종료합니다.
백업이 중요함 (4.53.00에서 업그레이드하는 경우): 프라이빗 클라우드용 Edge 4.53.00 (OpenLDAP 2.4.46)에서 업그레이드하는 경우 기존 LDAP 데이터의 완전하고 검증된 백업이 필수입니다. 유효한 백업 없이 진행하면 되돌릴 수 없는 데이터 손실이 발생합니다. LDAP 서비스가 계속 실행되는 동안 백업을 시작하여 LDAP 데이터의 일관된 특정 시점 스냅샷을 캡처합니다. 백업이 없으면 4.53.00 이전 단계에서 기존 LDAP 데이터 디렉터리를 완전 삭제하므로 2.4에서 2.6.10으로의 이전을 실행하거나 롤백할 수 없습니다.

관리 서버 및 UI 종료: 버전 4.53.00에서 LDAP 이전을 진행하기 전에 모든 edge-management-server 및 edge-ui 인스턴스를 종료합니다.
```
apigee-service edge-management-server stop
apigee-service edge-ui stop
```
기존 LDAP 데이터 백업: 버전 4.53.00 (OpenLDAP 2.4.46)에서 업그레이드할 때 변경하기 전에 모든 LDAP 서버에서 현재 LDAP 데이터를 전체 백업합니다. 이렇게 하면 안전한 복원 지점이 생성됩니다. (버전 4.53.01에서 4.54.00으로 업그레이드하는 경우에는 이 백업, 중지, 정리 시퀀스가 필요하지 않습니다.)
- 백업 명령어를 실행합니다. 이 작업을 수행하면 /opt/apigee/backup/openldap 디렉터리 내에 타임스탬프가 지정된 백업 보관 파일이 생성됩니다.
```
apigee-service apigee-openldap backup
```
- 총 레코드 수 가져오기: 업그레이드 후 검증을 위해 디렉터리의 레코드 수를 캡처합니다. (레코드 수는 모든 LDAP 서버에서 일치해야 합니다.)
```
# Note: Replace 'YOUR_PASSWORD' with your current LDAP manager password.
ldapsearch -o ldif-wrap=no -b "dc=apigee,dc=com" \
-D "cn=manager,dc=apigee,dc=com" -H ldap://:10389 -LLL -x -w 'YOUR_PASSWORD' | wc -l
```
LDAP 중지 및 데이터 디렉터리 정리: 버전 4.53.00 (OpenLDAP 2.4.46)에서 업그레이드하는 경우에만 모든 LDAP 서버에서 이 단계를 수행합니다. 4.53.01 (OpenLDAP 2.6.7) 버전에서 업그레이드하는 경우 LDAP를 중지하거나 /opt/apigee/data/apigee-openldap/*를 삭제하지 마세요. 4.53.00 업그레이드의 경우 메이저 버전 변경 및 기본 데이터베이스 구조 차이로 인해 이 단계가 필수입니다. 모든 LDAP 서버가 중지되면 Management API 및 UI가 중단되기 시작합니다.
- LDAP 서비스를 중지합니다.
```
apigee-service apigee-openldap stop
```
- 이전 LDAP 데이터 및 구성 디렉터리를 영구적으로 삭제합니다.
```
rm -rf /opt/apigee/data/apigee-openldap/*
```
새 LDAP 버전 설치 및 구성 모든 LDAP 서버에서 표준 Apigee 스크립트를 사용하여 새 구성요소 버전을 다운로드하고 설치합니다.
- 새 LDAP 구성요소 설치: 업데이트 스크립트가 구성 파일을 읽고 새 apigee-openldap 패키지를 설치합니다.
```
/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
```
- 새 LDAP 버전 검증: 설치가 완료되면 프로필을 새로고침하고 새 LDAP 버전 (2.6.10)이 설치되었는지 확인합니다.
```
echo 'export PATH=/opt/symas/bin:$PATH' >> ~/.bash_profile
source ~/.bash_profile
ldapsearch -VV
```
  위에 지정된 명령어의 출력은 아래와 같이 LDAP 버전 2.6.10을 확인해야 합니다.
```
Expected output:
ldapsearch: @(#) OpenLDAP: ldapsearch 2.6.10
```
데이터 복원 전에 모든 서버에서 LDAP 중지: 버전 4.53.00 (OpenLDAP 2.4.46)에서 업그레이드하는 경우에만 5, 6, 7단계를 수행합니다 (4단계에서 버전 4.53.01에서 인플레이스 업그레이드한 경우 기존 LDAP 데이터가 보존되고 업그레이드가 완료됨). 4.53.00에서 백업을 복원하기 전에 새로 설치된 LDAP 서비스가 모든 서버에서 중지되었는지 확인합니다. 모든 LDAP 서버에서 다음 명령어를 실행합니다.
```
apigee-service apigee-openldap stop
rm -rf /opt/apigee/data/apigee-openldap/ldap/*
```
LDAP 데이터 복원: 첫 번째 활성 서버에서 백업을 복원하는 전략입니다. 그러면 이 서버가 정보 소스 역할을 하여 다중 서버 설정에서 데이터를 피어에 복제합니다.
1. 복원을 위해 첫 번째 활성 서버를 식별합니다.
  - 단일 서버 설정: 유일한 LDAP 서버입니다. 다음 단계로 바로 진행할 수 있습니다.
  - 활성-대기 및 활성-활성 설정의 경우: 각 LDAP 서버에서 다음 진단 명령어를 실행합니다.
```
grep -i '^olcSyncrepl:' /opt/apigee/data/apigee-openldap/slapd.d/cn=config/olcDatabase*.ldif
```
    참고:
    - 위 명령어가 출력을 반환하면 서버는 수동 서버입니다.
    - 출력이 반환되지 않으면 서버가 활성 서버입니다.
2. 백업 데이터 복원: 계속하기 전에 모든 LDAP 서버에서 5단계가 완료되었는지 다시 한번 확인합니다.
  - 위에서 확인한 첫 번째 활성 서버에서 백업 디렉터리로 이동합니다.
```
cd /opt/apigee/backup/openldap
```
  - 복원 명령어를 실행합니다. 의도하지 않은 버전이나 이전 버전이 복원되지 않도록 2단계의 정확한 백업 타임스탬프를 지정합니다.
```
# To restore a specific backup (recommended):
apigee-service apigee-openldap restore 2025.08.11,23.34.00

# To restore the latest available backup by default:
apigee-service apigee-openldap restore
```
  - 복원 프로세스가 완료되면 첫 번째 활성 서버에서 LDAP 서비스를 시작합니다.
```
apigee-service apigee-openldap start
```
나머지 LDAP 서버 시작: 다중 서버 설정이 있는 경우 각 LDAP 서버에서 서비스를 시작합니다.
```
apigee-service apigee-openldap start
```
참고: 이러한 피어 서버에서는 데이터를 수동으로 복원할 필요가 없습니다. 시작되면 복원된 데이터가 포함된 첫 번째 서버에 연결되고 복제를 통해 전체 디렉터리가 자동으로 동기화됩니다.
최종 검증 마지막 단계는 업그레이드가 성공적으로 완료되었고 전체 LDAP 클러스터에서 데이터가 일관되게 유지되는지 확인하는 것입니다.
- 모든 LDAP 서버에서 검증 명령어를 실행합니다. 레코드 수는 모든 서버에서 동일해야 하며 2단계에서 캡처한 수와 일치해야 합니다.
```
# Note: Replace 'YOUR_PASSWORD' with your LDAP manager password.
ldapsearch -o ldif-wrap=no -b "dc=apigee,dc=com" -D "cn=manager,dc=apigee,dc=com" -H ldap://:10389 -LLL -x -w 'YOUR_PASSWORD' | wc -l
```
- 데이터가 올바르고 일관적인지 확인하면 LDAP 업그레이드가 완료됩니다. 이제 조직의 표준 업그레이드 절차에 따라 edge-management-server, edge-ui 및 기타 종속 구성요소를 시작할 수 있습니다.

LDAP를 4.53.01에서 4.54.00으로 업그레이드하는 단계

새 LDAP 버전 설치 및 구성 모든 LDAP 서버에서 표준 Apigee 스크립트를 사용하여 새 구성요소 버전을 다운로드하고 설치합니다.

새 LDAP 구성요소 설치: 업데이트 스크립트가 구성 파일을 읽고 새 apigee-openldap 패키지를 설치합니다.
```
/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
```
새 LDAP 버전 검증: 설치가 완료되면 프로필을 새로고침하고 새 LDAP 버전 (2.6.10)이 설치되었는지 확인합니다.
```
echo 'export PATH=/opt/symas/bin:$PATH' >> ~/.bash_profile
source ~/.bash_profile
ldapsearch -VV
```
위에 지정된 명령어의 출력은 아래와 같이 LDAP 버전 2.6.10을 확인해야 합니다.
```
Expected output:
ldapsearch: @(#) OpenLDAP: ldapsearch 2.6.10
```

새 Edge UI 및 Apigee SSO (설치된 경우)로 업그레이드

Apigee Edge for Private Cloud 4.54.00에서는 기본 UI (edge-ui)가 삭제되고 새 Edge UI (edge-management-ui)로 대체됩니다. 설정에서 Apigee 싱글 사인온 (SSO)이 설치되고 사용되는지 여부에 따라 아래 두 옵션 중 하나를 따르세요.

옵션 1: UI 업그레이드 (Apigee SSO 없음)

이 섹션은 기존 프라이빗 클라우드용 Edge 버전 4.53.00 또는 4.53.01 설치에 Apigee SSO (apigee-sso)가 구성 / 설치되지 않은 경우에만 적용됩니다.

프라이빗 클라우드용 Edge 버전 4.54.00 업그레이드 프로세스의 일환으로 클래식 UI (edge-ui)가 삭제됩니다. 다음 업그레이드 명령어를 실행하면 UI 노드가 기존 UI (edge-ui)에서 새 Edge UI(edge-management-ui)로 전환됩니다.

1단계: 구성 파일 백업

시작하기 전에 모든 UI 노드에서 기존 자동 구성 파일 (configFile)과 /opt/apigee/customer/application/ 디렉터리를 백업합니다.

2단계: 기본 인증의 자동 구성 파일 업데이트

자동 구성 파일 (예: /opt/silent.conf)을 수정하고 기본 인증을 위해 다음 New Edge UI 속성을 추가합니다.

# Authentication mode for New Edge UI (Basic Authentication - No Apigee SSO)
AUTH_MODE=basic

# Access configuration for the New Edge UI
MANAGEMENT_UI_PORT=3001
MANAGEMENT_UI_APP_ENV=OPDK
MANAGEMENT_UI_IP=MANAGEMENT_UI_NODE_IP #Replace MANAGEMENT_UI_NODE_IP with the IP address or hostname of the UI node.
MANAGEMENT_UI_SCHEME=http

3단계: UI 구성요소 업그레이드

-c ue 구성요소로 update.sh 스크립트를 실행하여 기본 UI (edge-ui)에서 새 Edge UI (edge-management-ui)로 업그레이드합니다.

/opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile

4단계: New Edge UI 업그레이드 확인

모든 UI 노드에서 업그레이드 프로세스를 완료한 후 버전 4.54.00 New Edge UI가 완전히 작동하고 액세스 가능한지 확인하세요.

edge-management-ui 서비스가 실행 중인지 확인합니다.
```
apigee-service edge-management-ui status
```
브라우저를 열고 다음으로 이동합니다.
```
http://MANAGEMENT_UI_NODE_IP:3001
```
확인되면 옵션 2: UI 업그레이드 (Apigee SSO 사용)를 건너뛰고 Qpid로 필수 업그레이드로 바로 진행합니다.

옵션 2: UI 업그레이드 (Apigee SSO 사용)

프라이빗 클라우드용 Edge 4.53.00 또는 4.53.01 환경에 Apigee SSO (apigee-sso) 가 구성 / 설치된 경우 이 섹션을 사용합니다.

프라이빗 클라우드용 Apigee Edge 4.54.00:

기본 Apigee SSO 서비스가 기존 apigee-sso 구성요소에서 apigee-openldap에서 관리되는 Apigee SSO로 전환됩니다. 프라이빗 클라우드용 Edge 버전 4.53.00 또는 4.53.01에서 SSO가 사용 설정된 경우 프라이빗 클라우드용 Apigee Edge 버전 4.54.00으로 업그레이드할 때 이 업그레이드는 필수입니다.
SSO가 포함된 4.53.x 클래식 UI (edge-ui)와 SSO가 포함된 4.53.x 새 Edge UI (edge-management-ui)가 모두 Apigee SSO가 포함된 4.54.00 새 Edge UI (edge-management-ui)로 업그레이드됩니다.

다음 도움말을 읽고 새로운 Apigee SSO 설계와 Management API를 사용하는 유틸리티 및 자동화 흐름에 미치는 영향을 알아보세요.
새로운 Apigee SSO 구조 정보
SSO를 사용한 자동 작업

아래의 통합된 엔드 투 엔드 단계에 따라 중복 구성 단계 없이 UI와 Apigee SSO를 모두 완전히 업그레이드하세요.

1단계: 구성 파일 백업

계속하기 전에 모든 UI 및 SSO 노드에서 기존 자동 configFile 및 /opt/apigee/customer/application/ 디렉터리를 백업합니다.

2단계: 지원 중단된 UI/SSO 변수 삭제 및 자동 구성 파일 (`configFile`) 업데이트

새 Edge UI를 업그레이드하고 Apigee SSO 모듈을 구성하기 전에 현재 4.53.x UI 설정을 기반으로 한 단계로 무인 구성 파일 (configFile)을 업데이트합니다.

configFile에서 지원 중단된 4.53.x UI 및 SSO 변수를 삭제하거나 주석 처리합니다.

apigee-sso를 사용하여 기본 UI (edge-ui)에서 업그레이드하는 경우: 기본 UI 및 SSO 관련 속성을 삭제하거나 주석 처리합니다.

EDGEUI_SSO_ENABLED=y
EDGEUI_SSO_CLIENT_NAME=edgeui
EDGEUI_SSO_CLIENT_SECRET=edgeuisecret
EDGEUI_PUBLIC_URIS=
EDGEUI_SSO_CLIENT_OVERWRITE=y
EDGEUI_SSO_REGISTERD_PUBLIC_URIS=$EDGEUI_PUBLIC_URIS

apigee-sso를 사용하여 New Edge UI (edge-management-ui)에서 업그레이드하는 경우: 지원 중단된 4.53.x Classic UI, Shoehorn, SSO 관련 속성을 삭제하거나 주석 처리합니다.

EDGEUI_SSO_ENABLED=y
EDGEUI_SSO_CLIENT_NAME=edgeui
EDGEUI_SSO_CLIENT_SECRET=edgeuisecret
EDGEUI_PUBLIC_URIS=
EDGEUI_SSO_CLIENT_OVERWRITE=y
EDGEUI_SSO_REGISTERD_PUBLIC_URIS=$EDGEUI_PUBLIC_URIS
EDGEUI_ENABLE_UNIFIED_UI=n
SHOEHORN_SCHEME=$MANAGEMENT_UI_SCHEME
SHOEHORN_IP=$MANAGEMENT_UI_IP
SHOEHORN_PORT=9000
CLASSIC_UI_SCHEME=http
CLASSIC_UI_PORT=9000
MANAGEMENT_UI_PUBLIC_URIS=http://Public_IP:3001
MANAGEMENT_UI_SSO_REGISTERD_PUBLIC_URIS=$MANAGEMENT_UI_PUBLIC_URIS
ROUTES_CLASSICUI=""
ROUTES_SHOEHORN=""

apigee-openldap 노드에서 다음 명령어를 사용하여 새 Edge UI의 머신 사용자를 만들고, 후속 단계에서 자동 구성 파일 (configFile)에 속성을 정의할 때 정확히 동일한 사용자 인증 정보를 사용해야 합니다. 자세한 내용은 UI용 머신 사용자 만들기를 참조하세요.
```
/opt/apigee/apigee-openldap/bin/apigee-machineuser.sh add -u ui-machine-user@apigee.com -p Secret123
```

configFile에서 필수 4.54.00 Apigee SSO 및 새 Edge UI 속성을 추가하거나 업데이트합니다.

# ==========================================
# SSO Enablement
# ==========================================
ENABLE_SSO=y

# ==========================================
# SSO Hostname/IP and Port config for Apigee SSO
# ==========================================
SSO_PUBLIC_URL_SCHEME=http
SSO_PUBLIC_URL_HOSTNAME=YOUR_SSO_NODE_IP_OR_HOSTNAME #Replace YOUR_SSO_NODE_IP_OR_HOSTNAME with the IP address or hostname of the SSO node.
SSO_PUBLIC_URL_PORT=9099

# ==========================================
# Static Client UI credentials
# ==========================================
MANAGEMENT_UI_SSO_CLIENT_ID=YOUR_SSO_CLIENT_ID #Example : MANAGEMENT_UI_SSO_CLIENT_ID=unifiedui
MANAGEMENT_UI_SSO_CLIENT_SECRET=YOUR_SSO_CLIENT_SECRET #Example : MANAGEMENT_UI_SSO_CLIENT_SECRET=secret123

# ==========================================
# Management UI & SSO redirect URLs
# ==========================================
MANAGEMENT_UI_SCHEME=http
MANAGEMENT_UI_IP=MANAGEMENT_UI_NODE_IP #Replace MANAGEMENT_UI_NODE_IP with the IP address or hostname of the UI node.
MANAGEMENT_UI_PORT=3001

# ==========================================
# Management Server parameters (Required for SSO registration)
# ==========================================
MSIP=MS_IP_OR_HOSTNAME #Replace MS_IP_OR_HOSTNAME with the IP address or hostname of the Management Server node.
ADMIN_EMAIL=your@email.com
APIGEE_ADMINPW=your_password

# ==========================================
# Machine user for UI
# ==========================================
UI_MACHINE_USER=ui-machine-user@apigee.com
UI_MACHINE_PWD=Secret123

# ==========================================
# Postgres connection parameters
# ==========================================
# Postgres username and password as set when you installed Edge.
PG_HOST=PG_IP_OR_HOSTNAME
PG_USER=apigee
PG_PWD=YOUR_PG_PASSWORD

# ==========================================
# Other UI Parameters
# ==========================================
AUTH_MODE=sso

# Y to use Internal/Local LDAP for authentication, N to use external IDP
SSO_LOCAL_LDAP=y

MANAGEMENT_UI_APP_ENV=OPDK
MANAGEMENT_UI_SSO_ENABLED=y
MANAGEMENT_UI_SSO_CSRF_SECRET=YOUR_CSRF_SECRET
MANAGEMENT_UI_SSO_CSRF_EXPIRATION_HOURS=24
MANAGEMENT_UI_SSO_STRICT_TRANSPORT_SECURITY_AGE_HOURS=24
MANAGEMENT_UI_SSO_PUBLIC_KEY_CACHE_HOURS=0.5

3단계: New Edge UI 구성요소 업그레이드

새 Edge UI가 현재 사용 중인 경우 edge-management-ui (새 Edge UI) 및 edge-ui (Shoehorn UI) 구성요소를 모두 중지하고 제거합니다.

#Remove 4.53.xx New Edge UI from installation node 
apigee-service edge-management-ui stop
apigee-service edge-management-ui uninstall

#Remove Shoehorn UI from the node with 4.53.xx New Edge UI
apigee-service edge-ui stop
apigee-service edge-ui uninstall

기본 UI(edge-ui) 노드에서 update.sh 스크립트를 실행하여 새 Edge UI(edge-management-ui) 구성요소를 설치하고 업그레이드합니다.
```
/opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile
```

4단계: `apigee-sso` 중지

서비스가 설치된 모든 노드에서 기존 apigee-sso 서비스를 중지합니다.

apigee-service apigee-sso stop

5단계: Postgres 노드에서 Apigee SSO용 `apigee_dex` 데이터베이스 만들기

Postgres 기본 노드에서 다음 명령어를 사용하여 Postgresql에 로그인합니다.
```
psql -h $(hostname -i) -U apigee
```
psql 프롬프트에서 다음 명령어를 실행하여 Apigee SSO 데이터베이스를 만듭니다.
```
create database apigee_dex;
```

6단계: OpenLDAP 노드에서 Apigee SSO 설정

Apigee SSO가 설치될 apigee-openldap 노드에서 다음 명령어를 실행합니다.

/opt/apigee/apigee-service/bin/apigee-service apigee-openldap setup-sso -f configFile

7단계: Apigee SSO의 관리 UI 구성 및 UI 다시 시작

프라이빗 클라우드용 Edge 4.54.00 edge-management-ui이 설치된 모든 노드에서 다음 명령어를 실행합니다.

/opt/apigee/apigee-service/bin/apigee-service edge-management-ui configure-sso -f configFile

8단계: 새로운 Edge UI 및 Apigee SSO 업그레이드 확인

위 단계를 완료한 후 4.54.00 New Edge UI 및 Apigee SSO가 실행 중이고 액세스할 수 있는지 확인합니다.

edge-management-ui 서비스가 실행 중인지 확인합니다.
```
apigee-service edge-management-ui status
```
브라우저를 열고 다음으로 이동합니다.
```
http://MANAGEMENT_UI_NODE_IP:3001
```
구성된 SSO 사용자 인증 정보를 사용하여 로그인합니다.

9단계: 기존 `apigee-sso` 제거하기

기존 apigee-sso가 설치된 모든 노드에서 apigee-sso 구성요소를 제거합니다.

apigee-service apigee-sso uninstall

Qpid 10.0.1로 업그레이드

이 방법을 사용하면 Edge 런타임 환경에 다운타임이 발생하지 않으며 분석을 위해 획득한 런타임 데이터의 손실을 최소화할 수 있습니다.

Qpid로 인플레이스(In-Place) 다운타임 없는 업그레이드를 수행하려면 다음 안내를 따르세요.

시작할 Qpid 노드를 하나 선택합니다.
노드에서 Qpid 브로커를 중지합니다.
```
apigee-service apigee-qpidd stop
```
방화벽을 적용하여 모든 메시지 프로세서에서 브로커 포트 5672로 들어오는 트래픽을 차단합니다. 이 방화벽은 Qpid 노드 인스턴스 또는 다른 외부 방화벽/네트워크 구성요소 수준에서 적용할 수 있습니다.

모든 메시지 프로세서 IP 주소에 동일한 단계를 수행하는 것이 좋습니다. 예를 들어 IPTables를 사용하여 메시지 프로세서 IP 주소에서 포트 5672의 Qpid 노드로 들어오는 요청을 삭제하려면 다음과 같은 명령어를 사용하면 됩니다.
```
iptables -A INPUT -p tcp --dport 5672 -s MESSAGE_PROCESSOR_IP -j DROP
```
기존 메시지가 있는 경우 Qpid 브로커를 다시 시작하여 기존 메시지를 드레인합니다.
```
apigee-service apigee-qpidd start
```
기존 대기열이 비어 있는지 확인합니다.
```
/opt/apigee/apigee-qpidd/bin/qpid-stat -q
```
메시지가 데드 레터 큐 (DLQ) (ax-q-axgroup-001-consumer-group-001-dl)에 걸려 있는 경우 데드 레터 큐에 걸려 있는 분석 데이터를 해결하는 단계를 사용하여 큐를 드레이닝합니다.
이전 노드에서 큐가 비워졌는지 확인한 후 apigee-qpidd를 중지합니다.
```
apigee-service apigee-qpidd stop
```

노드에서 Qpid를 업그레이드합니다.

/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

edge-qpid-server를 다시 시작합니다.
```
apigee-service edge-qpid-server restart
```
3단계에서 적용한 방화벽 규칙을 삭제합니다.

방화벽이 적용된 모든 메시지 프로세서 IP 주소에 대해 동일한 삭제 단계를 수행합니다. 방화벽이 삭제되면 메시지 프로세서 IP 주소에서 포트 5672의 Qpid 노드로 전송되는 요청이 수락됩니다. iptables를 사용하여 방화벽을 추가한 경우 방화벽을 삭제하고 기존 설정을 나열하려면 다음과 같은 명령어를 사용하면 됩니다.
```
iptables -F
iptables -L
```
웹 모니터링을 사용하여 Qpid 큐가 메시지를 수신하는지 확인합니다.
```
http://QPID_NODE_IP:8090
```
각 Qpid 노드에 대해 1~9단계를 반복합니다.

Postgres 18.6으로 업그레이드

이 Edge 출시 버전에는 Postgres 18.6으로의 업그레이드가 포함되어 있습니다. 이 업그레이드의 일환으로 모든 Postgres 데이터가 Postgres 18.6으로 이전됩니다.

대부분의 Edge 프로덕션 시스템은 기본-대기 복제를 위해 구성된 두 개의 Postgres 노드를 사용합니다. 업데이트 프로세스 중에 Postgres 노드가 업데이트를 위해 다운되어 있는 동안에도 분석 데이터는 Qpid 노드에 계속 기록됩니다. Postgres 노드가 업데이트되고 다시 온라인 상태가 되면 분석 데이터가 Postgres 노드로 푸시됩니다.

Postgres 업데이트를 실행하는 방법은 Postgres 노드의 데이터 스토리지를 구성한 방법에 따라 다릅니다.

Postgres 노드에 로컬 데이터 스토리지를 사용하는 경우 업그레이드 기간 동안 새 Postgres 대기 노드를 설치해야 합니다. 업그레이드가 완료되면 새 Postgres 대기 노드를 사용 중단할 수 있습니다. 어떤 이유로든 업데이트를 롤백해야 하는 경우 추가 Postgres 대기 모드 노드가 필요합니다. 업데이트를 롤백해야 하는 경우 롤백 후 새 Postgres 대기 노드가 기본 Postgres 노드가 됩니다. 따라서 새 Postgres 대기 노드를 설치할 때는 Edge 설치 요구사항에 정의된 대로 Postgres 서버의 모든 하드웨어 요구사항을 충족하는 노드에 설치해야 합니다.

프로토타입 제작 및 테스트에 사용되는 토폴로지인 Edge의 1노드 및 2노드 구성에는 단일 Postgres 노드만 있습니다. 새 Postgres 노드를 만들지 않고도 이러한 Postgres 노드를 직접 업데이트할 수 있습니다.
Apigee에서 권장하는 대로 Postgres 노드에 네트워크 스토리지를 사용하는 경우 새 Postgres 노드를 설치할 필요가 없습니다. 아래 절차에서는 새 Postgres 대기 노드를 설치하고 나중에 사용 중단하도록 지정하는 단계를 건너뛸 수 있습니다. 업데이트 프로세스를 시작하기 전에 Postgres에서 사용하는 데이터 스토어의 네트워크 스냅샷을 만드세요. 그런 다음 업데이트 중에 오류가 발생하여 롤백을 강제로 실행해야 하는 경우 해당 스냅샷에서 Postgres 노드를 복원할 수 있습니다.

새 Postgres 대기 노드 설치

이 절차는 새 노드에 Postgres 대기 서버를 만듭니다. 버전 4.54.00이 아닌 기존 Edge 버전 (4.53.00 또는 4.53.01)용 새 Postgres 대기 서버를 설치해야 합니다.

설치를 수행하려면 현재 버전의 Edge를 설치하는 데 사용한 것과 동일한 구성 파일을 사용합니다.

새 Postgres 대기 노드를 만들려면 다음 안내를 따르세요.

현재 Postgres 기본에서 /opt/apigee/customer/application/postgresql.properties 파일을 수정하여 다음 토큰을 설정합니다. 해당 파일이 없으면 파일을 만듭니다.
```
conf_pg_hba_replication.connection=host replication apigee existing_standby_ip/32 trust\ \nhost replication apigee new_standby_ip/32 trust
```
여기서 existing_standby_ip는 현재 Postgres 대기 서버의 IP 주소이고 new_standby_ip는 새 대기 노드의 IP 주소입니다.

Postgres 기본에서 apigee-postgresql을 다시 시작합니다.

/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart

기본 노드에서 /opt/apigee/apigee-postgresql/conf/pg_hba.conf 파일을 확인하여 새 대기 노드가 추가되었는지 확인합니다. 이 파일에 다음 줄이 표시됩니다.
```
host replication apigee existing_standby_ip/32 trust
host replication apigee new_standby_ip/32 trust
```
새 Postgres 대기 서버를 설치합니다.
1. 현재 버전의 Edge를 설치하는 데 사용한 구성 파일을 수정하여 다음을 지정합니다.
```
# IP address of the current primary(master):
PG_MASTER=PG_MASTER_NODE_IP
# IP address of the new standby node
PG_STANDBY=PG_STANDBY_NODE_IP
```
2. Edge apigee-setup 유틸리티 설치에 설명된 대로 SELinux를 사용 중지합니다.
3. 현재 Edge 버전에 따라 부트스트랩 스크립트를 다운로드하고 실행합니다.
  - 현재 Edge 4.53.00을 사용 중인 경우:
    
    Edge bootstrap_4.53.00.sh 파일을 /tmp/bootstrap_4.53.00.sh에 다운로드합니다.
```
curl https://software.apigee.com/bootstrap_4.53.00.sh -o /tmp/bootstrap_4.53.00.sh
```
    Edge apigee-service 유틸리티 및 종속 항목을 설치합니다.
```
bash /tmp/bootstrap_4.53.00.sh apigeeuser=uName apigeepassword=pWord
```
  - 현재 Edge 4.53.01을 사용 중인 경우:
    
    Edge bootstrap_4.53.01.sh 파일을 /tmp/bootstrap_4.53.01.sh에 다운로드합니다.
```
curl https://software.apigee.com/bootstrap_4.53.01.sh -o /tmp/bootstrap_4.53.01.sh
```
    Edge apigee-service 유틸리티 및 종속 항목을 설치합니다.
```
bash /tmp/bootstrap_4.53.01.sh apigeeuser=uName apigeepassword=pWord
```
4. apigee-service을 사용하여 apigee-setup 유틸리티를 설치합니다.
```
/opt/apigee/apigee-service/bin/apigee-service apigee-setup install
```
5. Postgres를 설치합니다.
```
/opt/apigee/apigee-setup/bin/setup.sh -p ps -f configFile
```
6. 새 대기 노드에서 다음 명령어를 실행하고 대기인지 확인합니다.
```
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-standby
```

Postgres 인플레이스 업그레이드 수행

예비 단계

Postgres로 인플레이스 업그레이드를 수행하기 전에 기본 호스트와 대기 호스트 모두에서 다음 단계를 수행하여 apigee-postgresql에서 max_locks_per_transaction 속성을 업데이트합니다.

파일이 없으면 /opt/apigee/customer/application/postgresql.properties 파일을 만듭니다 .

이 파일의 소유권을 apigee로 변경합니다.

chown apigee:apigee /opt/apigee/customer/application/postgresql.properties

파일에 다음 속성을 추가합니다.

conf/postgresql.conf+max_locks_per_transaction=30000

apigee-postgresql 구성 :

apigee-service apigee-postgresql configure

apigee-postgresql을 다시 시작합니다.
```
apigee-service apigee-postgresql restart
```

인플레이스(In-Place) 업그레이드 수행

Postgres 18로 인플레이스 업그레이드를 수행하려면 다음 단계를 따르세요.

기본 호스트에서 postgres 업그레이드

/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

기본 호스트에서 설정 명령어를 실행합니다.
```
apigee-service apigee-postgresql setup -f configFile
```
기본 호스트에서 구성 명령어를 실행합니다.
```
apigee-service apigee-postgresql configure
```
기본 호스트를 다시 시작합니다.
```
apigee-service apigee-postgresql restart
```

기본으로 구성합니다.

apigee-service apigee-postgresql setup-replication-on-master -f configFile

기본 호스트가 시작되었는지 확인합니다.
```
apigee-service apigee-postgresql wait_for_ready
```
대기 모드를 중지합니다.
```
apigee-service apigee-postgresql stop
```
대기 인스턴스를 업그레이드합니다.

참고: 이 단계에서 오류가 발생하거나 실패하면 무시해도 됩니다. update.sh에서 잘못된 구성으로 대기 서버를 시작하려고 시도합니다. Postgres 설치가 18로 업그레이드되면 오류를 무시할 수 있습니다.
```
/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
```
대기 모드가 중지되었는지 확인합니다.
```
apigee-service apigee-postgresql stop
```

이전 대기 구성을 삭제합니다.

rm -rf /opt/apigee/data/apigee-postgresql/

대기 서버에서 복제를 설정합니다.

apigee-service apigee-postgresql setup-replication-on-standby -f configFile

기본 호스트와 대기 호스트 모두에서 /opt/apigee/customer/application/postgresql.properties 파일의 conf/postgresql.conf+max_locks_per_transaction=30000 줄을 삭제합니다. 이 줄은 사전 단계에서 추가되었습니다 .

이 절차를 완료하면 대기 모드가 성공적으로 시작됩니다.

Postgres 노드 사용 중단

업데이트가 완료되면 새 대기 노드를 사용 중단합니다.

Postgres가 실행 중인지 확인합니다.
```
/opt/apigee/apigee-service/bin/apigee-all status
```
Postgres가 실행되고 있지 않으면 시작합니다.
```
/opt/apigee/apigee-service/bin/apigee-all start
```
새 대기 노드에서 다음 curl 명령어를 실행하여 새 대기 노드의 UUID를 가져옵니다.
```
curl -u sysAdminEmail:password http://node_IP:8084/v1/servers/self
```
출력 끝에 노드의 UUID가 다음 형식으로 표시됩니다.
```
"type" : [ "postgres-server" ],
"uUID" : "599e8ebf-5d69-4ae4-aa71-154970a8ec75"
```
새 대기 노드에서 다음 명령어를 실행하여 새 대기 노드를 중지합니다.
```
/opt/apigee/apigee-service/bin/apigee-all stop
```
Postgres 기본 노드에서 /opt/apigee/customer/application/postgresql.properties을 수정하여 conf_pg_hba_replication.connection에서 새 대기 노드를 삭제합니다.
```
conf_pg_hba_replication.connection=host replication apigee existing_standby_ip/32 trust
```

Postgres 기본에서 apigee-postgresql을 다시 시작합니다.

/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart

기본 노드에서 /opt/apigee/apigee-postgresql/conf/pg_hba.conf 파일을 확인하여 새 대기 노드가 삭제되었는지 확인합니다. 해당 파일에는 다음 줄만 표시됩니다.
```
host replication apigee existing_standby_ip/32 trust
```
관리 서버 노드에서 다음 Edge Management API 호출을 실행하여 ZooKeeper에서 대기 노드의 UUID를 삭제합니다.
```
curl -u sysAdminEmail:password -X DELETE http://ms_IP:8080/v1/servers/new_standby_uuid
```

Postgres 업그레이드 후 단계

Postgres 메이저 업그레이드 후에는 Postgres의 내부 통계가 삭제됩니다. 이러한 통계는 Postgres 쿼리 플래너가 쿼리를 실행하는 데 가장 최적의 색인과 경로를 활용하는 데 도움이 됩니다.

Postgres는 쿼리가 실행되고 autovacuum 데몬이 실행될 때 시간이 지남에 따라 통계를 점진적으로 다시 빌드할 수 있습니다. 하지만 통계가 다시 빌드될 때까지는 쿼리가 느릴 수 있습니다.

이 문제를 해결하려면 기본 Postgres 노드의 데이터베이스에 있는 모든 테이블에서 ANALYZE를 실행합니다. 또는 한 번에 몇 개의 테이블에 대해 ANALYZE를 실행할 수 있습니다.

ZooKeeper 3.8.5로 업그레이드

이 프라이빗 클라우드용 Edge 출시 버전에는 ZooKeeper 3.8.5로의 업그레이드가 포함되어 있습니다. 이 업그레이드의 일환으로 모든 ZooKeeper 데이터가 ZooKeeper 3.8.5로 이전됩니다.

ZooKeeper를 업그레이드하기 전에 ZooKeeper 유지관리 가이드를 읽어보세요. 대부분의 Edge 프로덕션 시스템은 여러 데이터 센터에 분산된 ZooKeeper 노드 클러스터를 사용합니다. 이러한 노드 중 일부는 ZooKeeper 리더 선택에 참여하는 투표자로 구성되고 나머지는 관찰자로 구성됩니다. 자세한 내용은 리더, 팔로어, 유권자, 관찰자 정보를 참고하세요. 투표자 노드는 리더를 선출한 후 투표자 노드 자체가 팔로어가 됩니다.

업데이트 프로세스 중에 리더 노드가 종료되면 ZooKeeper에서 일시적인 지연 또는 쓰기 실패가 발생할 수 있습니다. 이는 프록시 배포 작업과 같은 ZooKeeper에 쓰는 관리 작업과 메시지 프로세서 추가 또는 삭제와 같은 Apigee 인프라 변경사항에 영향을 미칠 수 있습니다. 아래 절차에 따라 ZooKeeper를 업그레이드하는 동안 Apigee의 런타임 API에는 영향을 미치지 않습니다 (이러한 런타임 API가 관리 API를 호출하지 않는 한).

개략적으로 말해 업그레이드 프로세스에는 각 노드의 백업이 포함됩니다. 그 후 모든 옵저버와 팔로어를 업그레이드하고 마지막으로 리더 노드를 업그레이드합니다.

백업 수행

롤백이 필요한 경우에 사용할 수 있도록 ZooKeeper의 모든 노드를 백업합니다. 롤백하면 ZooKeeper가 백업이 수행된 상태로 복원됩니다.

/opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper backup

가상 머신을 사용하고 있다면 복원 또는 롤백 (필요한 경우)을 위해 VM 스냅샷 또는 백업을 만들 수도 있습니다.

리더, 팔로어, 관찰자 식별

ZooKeeper 노드에 설치되지 않은 경우 nc를 설치합니다.
```
yum install nc
```

노드에서 다음 nc 명령어를 실행합니다. 여기서 2181은 ZooKeeper 포트입니다.

echo stat | nc localhost 2181

다음과 같은 출력이 표시되어야 합니다.

Zookeeper version: 3.8.5-19f1842d4b6ee1f82cc8b05284959b26c6ae507d, built on 2025-09-03 21:35 UTC
Clients:
 /[0:0:0:0:0:0:0:1]:40696[0](queued=0,recved=1,sent=0)

Latency min/avg/max: 3/4.3333/6
Received: 4
Sent: 3
Connections: 1
Outstanding: 0
Zxid: 0x500000005
Mode: follower

노드 출력의 Mode 줄에 노드 구성에 따라 옵저버, 리더 또는 팔로어 (리더가 아닌 투표자)가 표시됩니다.

각 ZooKeeper 노드에서 1단계와 2단계를 반복합니다.

옵저버 및 팔로어 노드에서 ZooKeeper 업그레이드

다음과 같이 각 옵저버 및 팔로어 노드에서 ZooKeeper를 업그레이드합니다.

외부 인터넷 연결이 있는 노드에서 4.54.00으로 업데이트 에 설명된 대로 프라이빗 클라우드용 Edge 4.54.00의 부트스트랩을 다운로드하고 실행합니다. 이 프로세스는 노드에 외부 인터넷 연결이 있는지 또는 오프라인 설치를 실행하는지에 따라 달라질 수 있습니다.
ZooKeeper 구성요소를 업그레이드합니다.
```
/opt/apigee/apigee-setup/bin/update.sh -c zk -f silent-config-file
```
참고: 이러한 노드에 다른 구성요소 (예: Cassandra)가 설치되어 있으면 지금 업그레이드하거나 (zk,cs 프로필과 같이) 나중에 다른 구성요소를 업그레이드할 수 있습니다. Apigee에서는 ZooKeeper만 먼저 업그레이드하고 다른 구성요소를 업그레이드하기 전에 클러스터가 제대로 작동하는지 확인하는 것이 좋습니다.
각 ZooKeeper 관찰자 및 팔로어 노드에서 위 단계를 반복합니다.

리더 종료

모든 옵저버 및 팔로어 노드가 업그레이드되면 리더를 종료합니다. 리더로 식별된 노드에서 아래 명령어를 실행합니다.

/opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper stop

이 이벤트 중에 새 리더가 선출되기 전에 ZooKeeper에서 일시적인 지연이나 쓰기 실패가 발생할 수 있습니다. 이는 프록시 배포 작업 또는 Apigee 인프라 변경사항(예: 메시지 프로세서 추가 또는 삭제 등)과 같이 ZooKeeper에 쓰는 작업에 영향을 줄 수 있습니다.

새 리더가 선출되었는지 확인

위의 리더, 팔로어, 옵저버 식별 섹션의 단계를 사용하여 기존 리더가 중지되면 팔로어 중에서 새 리더가 선출되었는지 확인합니다. 리더는 현재 리더와 다른 데이터 센터에서 선출되었을 수 있습니다.

업그레이드 리더

위의 관찰자 및 팔로어 노드에서 ZooKeeper 업그레이드와 동일한 단계를 따릅니다.

이전 리더 노드도 업그레이드되면 클러스터 상태를 확인하고 리더 노드가 있는지 확인합니다.

Cassandra 5.0.8로 업그레이드

프라이빗 클라우드용 Apigee Edge 4.54.00에는 Cassandra 버전 5.0.8로의 업그레이드가 포함되어 있습니다.

업그레이드 및 롤백

Cassandra 4.0.X에서 Cassandra 5.0.X로 업그레이드하는 것은 순차적 프로세스입니다.
Cassandra 5.0.X에서 4.0.X로 직접 인플레이스 롤백할 수 없습니다. 복제본 또는 백업을 사용하여 롤백하는 것은 복잡한 절차이며 다운타임 또는 데이터 손실이 발생할 수 있습니다. 문제를 해결하고 Cassandra 5.0.X로 업그레이드하는 것이 롤백하는 것보다 좋습니다.
업그레이드를 시도하기 전에 롤백 절차를 숙지하는 것이 중요합니다. 적절한 롤백 경로를 사용할 수 있도록 하려면 업그레이드 중 롤백의 미묘한 차이를 고려하는 것이 중요합니다.

단일 데이터 센터

단일 데이터 센터 내에서 Cassandra를 4.0.X에서 5.0.X로 업그레이드하는 것은 원활하지만 롤백은 복잡하며 다운타임과 데이터 손실이 발생할 수 있습니다. 프로덕션 워크로드의 경우 업그레이드를 시작하기 전에 새 데이터 센터에서 사용할 수 있는 Cassandra 노드가 최소한 하나 이상 있는 새 데이터 센터를 추가하는 것이 좋습니다. 이렇게 하면 데이터 손실이나 API 트래픽 중단 없이 Cassandra를 롤백할 수 있습니다. 이 추가 데이터 센터는 업그레이드가 완료되면 사용 중지할 수 있습니다.

새 데이터 센터를 추가할 수 없지만 롤백 기능이 필요한 경우 Cassandra 4.0.X를 복원하려면 백업이 필요합니다. 하지만 이 방법을 사용하면 다운타임과 데이터 손실이 발생할 수 있습니다.

여러 데이터 센터

프라이빗 클라우드용 Edge 4.53.00 또는 4.53.01에서 여러 데이터 센터를 운영하면 프라이빗 클라우드용 Edge 4.54.00으로 업그레이드하는 동안 롤백의 유연성이 향상됩니다.

롤백하려면 이전 Cassandra 버전 (4.0.X)을 실행하는 데이터 센터가 하나 이상 있어야 합니다.

권장 업그레이드 방법

한 번에 하나의 Cassandra 데이터 센터 업그레이드: 단일 데이터 센터 내에서 Cassandra 노드를 개별적으로 업그레이드하는 것으로 시작합니다. 한 데이터 센터의 모든 Cassandra 노드 업그레이드를 완료한 후 다음 데이터 센터로 진행합니다.
일시중지 및 검증: 데이터 센터 하나를 업그레이드한 후에는 프라이빗 클라우드 클러스터, 특히 업그레이드된 데이터 센터가 올바르게 작동하는지 확인하기 위해 일시중지합니다.
주의: 이전 버전을 실행하는 데이터 센터가 하나 이상 있는 경우에만 이전 Cassandra 버전으로 롤백할 수 있습니다.
시간 민감성: 기능을 검증하기 위해 잠시 (몇 시간 권장) 일시중지할 수 있지만 혼합 버전 상태를 무기한 유지할 수는 없습니다. 이는 버전이 다른 노드가 있는 균일하지 않은 Cassandra 클러스터에는 운영상의 제한이 있기 때문입니다.
철저한 테스트: Apigee는 다음 데이터 센터를 업그레이드하기 전에 성능과 기능을 종합적으로 테스트할 것을 적극 권장합니다. 모든 데이터 센터가 업그레이드되면 이전 버전으로 롤백할 수 없습니다.

롤백 체크포인트 프로세스

단일 롤백 체크포인트: 모든 구성요소가 4.54.00으로 업그레이드되면 하나 이상의 Cassandra 데이터 센터에서 이전 버전을 계속 실행하는 경우에만 Cassandra 롤백이 가능합니다. 마지막 Cassandra 데이터 센터가 업그레이드되면 프라이빗 클라우드용 Edge 4.54.00으로의 업그레이드가 완료되고 더 이상 롤백할 수 없습니다.

예

데이터 센터 (DC)가 두 개인 클러스터를 고려해 보세요.

시작 상태: 두 DC의 Cassandra 노드가 버전 4.0.X입니다. 다른 모든 노드는 프라이빗 클라우드용 Edge 버전 4.54.00에 있습니다. DC당 Cassandra 노드가 3개 있다고 가정합니다.
DC-1 업그레이드: DC-1의 Cassandra 노드 3개를 하나씩 업그레이드합니다.
일시중지 및 검증: 일시중지하여 클러스터, 특히 DC-1이 올바르게 작동하는지 확인합니다 (성능, 기능 확인). DC-2의 Cassandra 노드를 사용하여 초기 상태로 롤백할 수 있습니다. 혼합 버전 Cassandra 클러스터의 제한사항으로 인해 이 일시중지는 일시적이어야 합니다.
DC-2 업그레이드: DC-2에서 나머지 Cassandra 노드 3개를 업그레이드합니다. DC-2의 모든 Cassandra 노드가 성공적으로 업그레이드되면 프라이빗 클라우드용 Edge 4.54.00 업그레이드가 완료됩니다.

Cassandra 업그레이드 기본 요건

프라이빗 클라우드용 Edge 4.53.00 또는 4.53.01에서 Cassandra 4.0.X를 실행해야 하며 다음을 확인해야 합니다.

서버에서 Java 17을 기본 Java 버전으로 설정: Cassandra 5.0.X에서는 Java 8 지원이 삭제됩니다. Java 8에서는 Cassandra 5.0.X 또는 nodetool 유틸리티를 실행할 수 없습니다. 각 Cassandra 노드에 Java 17이 설치되어 있는지 확인하고 Cassandra 업그레이드 단계를 실행하기 전에 Java 17을 기본 Java 버전으로 설정하여 nodetool 명령어가 Java 17로 실행되도록 합니다.
```
alternatives --set java JAVA_17_PATH/bin/java
```
활성 기본 Java 버전이 Java 17인지 확인합니다.
```
java -version
```
전체 클러스터가 Cassandra 4.0.X에서 작동하며 완전히 작동합니다.
압축 전략이 LeveledCompactionStrategy로 설정됩니다(버전 4.53.00 또는 4.53.01로 업그레이드하기 위한 기본 요건).
아래의 각 단계가 프라이빗 클라우드용 Edge 4.53.00 또는 4.53.01의 Cassandra 4.0.X 초기 업그레이드의 일부로 완료되었는지 확인합니다.
- 이전 업그레이드 중에 각 Cassandra 노드에서 post_upgrade 명령어가 실행되었습니다.
- 이전 업그레이드 중에 전체 Cassandra 클러스터에서 drop_old_tables 명령어가 실행되었습니다.

Edge for Private Cloud 4.53.00 또는 4.53.01을 사용하는 동안 Cassandra 4.0.X에서 post_upgrade 및 drop_old_tables 명령어가 실행되었는지 확실하지 않은 경우 4.54.00으로 업그레이드하기 전에 안전하게 다시 실행할 수 있습니다.

1단계: 업그레이드 준비

아래 단계는 구성요소 업그레이드를 사용 설정하기 위한 Apigee의 표준 구성 파일과 같이 일반적으로 만드는 표준 파일에 추가됩니다.

Apigee를 사용하여 Cassandra를 백업합니다.
가능한 경우 Cassandra 노드의 VM 스냅샷을 생성합니다.
아직 구성되지 않은 경우 관리 서버, 메시지 프로세서, 라우터, Qpid, Postgres를 포함한 모든 프라이빗 클라우드용 Edge 구성요소에서 Cassandra 노드로 포트 9042에 액세스할 수 있는지 확인합니다. 자세한 내용은 포트 요구사항을 참고하세요.

2단계: 모든 Cassandra 노드 업그레이드

모든 Cassandra 노드는 각 데이터 센터에서 한 번에 하나씩 업데이트해야 합니다. 데이터 센터 내 노드 업그레이드 사이에 몇 분 정도 기다려 업데이트된 노드가 완전히 시작되고 클러스터에 조인되었는지 확인한 후 동일한 데이터 센터에서 다른 노드 업그레이드를 진행합니다.

한 데이터 센터 내의 모든 Cassandra 노드를 업그레이드한 후 다음 데이터 센터의 노드를 진행하기 전에 일정 시간 (30분~몇 시간)을 기다립니다. 이 기간 동안 업데이트된 데이터 센터를 철저히 검토하고 Apigee 클러스터의 기능 및 실적 측정항목이 그대로 유지되는지 확인합니다. 이 단계는 Cassandra가 버전 5.0.X로 업그레이드되고 나머지 Apigee 구성요소가 4.54.00으로 업그레이드된 데이터 센터의 안정성을 보장하는 데 중요합니다.

Cassandra 노드를 업그레이드하려면 다음 명령어를 실행합니다.
```
/opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
```
노드가 업데이트되면 노드에서 다음 명령어를 실행하여 계속 진행하기 전에 유효성 검사를 실행합니다.
```
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra validate_upgrade -f configFile
```

위의 코드는 다음과 같은 결과를 출력합니다.

Cassandra version is verified - [cqlsh 6.2.0 | Cassandra 5.0.8 | CQL spec 3.4.7 | Native protocol v5]
Metadata is verified

Cassandra 노드에서 다음 post_upgrade 명령어를 실행합니다.

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra post_upgrade

Cassandra 노드에서 다음 cleanup_old_index 명령어를 실행합니다.

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra cleanup_old_index

다음 nodetool 명령어를 실행하여 Cassandra 노드에서 색인을 다시 빌드합니다.

/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms api_products api_products_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms app_credentials app_credentials_api_products_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms app_credentials app_credentials_organization_app_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms app_credentials app_credentials_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms app_end_user app_end_user_app_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_app_family_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_app_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_app_type_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_parent_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_parent_status_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_status_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms maps maps_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect companies companies_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect companies companies_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect companies companies_status_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect company_developers company_developers_company_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect company_developers company_developers_developer_email_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect company_developers company_developers_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect developers developers_email_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect developers developers_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect developers developers_status_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis a_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis a_org_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_active_rev
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_def_index_template
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_def_method_template
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_latest_rev
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_base_url
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_is_active
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_is_latest
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_org_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_rel_ver
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_rev_num
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_a_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_api_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_ar_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_base_url
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_org_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_r_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_r_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_res_path
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_rev_num
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_a_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_api_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_ar_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_base_url
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_org_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_res_path
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_rev_num
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 schemas s_api_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 schemas s_ar_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 security sa_api_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 security sa_ar_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_a_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_a_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_entity
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_org_name
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template_auth au_api_uuid
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index dek keys usecase_index
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_operation_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_requesturi_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_responsecode_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_timestamp_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_user_idx    
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index cache cache_entries cache_entries_cache_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_access_tokens oauth_10_access_tokens_app_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_access_tokens oauth_10_access_tokens_consumer_key_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_access_tokens oauth_10_access_tokens_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_access_tokens oauth_10_access_tokens_status_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_request_tokens oauth_10_request_tokens_consumer_key_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_request_tokens oauth_10_request_tokens_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_verifiers oauth_10_verifiers_organization_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_verifiers oauth_10_verifiers_request_token_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_access_tokens oauth_20_access_tokens_app_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_access_tokens oauth_20_access_tokens_client_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_access_tokens oauth_20_access_tokens_refresh_token_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_authorization_codes oauth_20_authorization_codes_client_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_authorization_codes oauth_20_authorization_codes_organization_name_idx

수익 창출을 사용하는 경우 수익 창출 키스페이스와 관련된 다음 인덱스 재빌드 명령어도 실행합니다.

/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint limits limits_created_date_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint limits limits_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint limits limits_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint limits limits_updated_date_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_created_date_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_currency_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_dev_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_limit_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_prod_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_reason_code_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_sub_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_company_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_created_at_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_developer_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_lastmodified_at_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers triggers_env_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers triggers_job_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers triggers_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus job_details job_details_job_class_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus job_details job_details_job_group_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus job_details job_details_job_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus org_triggers org_triggers_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers_suite triggers_suite_group_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers_suite triggers_suite_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers_suite triggers_suite_suite_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_service_item notification_service_item_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_service_item notification_service_item_status_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_service_black_list_item notification_service_black_list_item_org_id_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_service_black_list_item notification_service_black_list_item_to_email_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_email_template_item notification_email_template_item_name_idx
/opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_email_template_item notification_email_template_item_org_id_idx

Apigee mTLS로 업데이트

Apigee mTLS를 업데이트하려면 다음 단계를 수행합니다.

업데이트 롤백

업데이트에 실패한 경우 문제를 수정한 후 update.sh를 다시 실행하면 됩니다. 업데이트를 여러 번 실행할 수 있으며 마지막으로 중단된 지점부터 업데이트가 계속됩니다.

실패로 인해 업데이트를 이전 버전으로 롤백해야 하는 경우 4.54.00 롤백에서 자세한 안내를 확인하세요.

로깅 업데이트 정보

기본적으로 update.sh 유틸리티는 로그 정보를 다음에 기록합니다.

/opt/apigee/var/log/apigee-setup/update.log

update.sh 유틸리티를 실행하는 사용자에게 해당 디렉터리에 대한 액세스 권한이 없으면 로그를 /tmp 디렉터리에 update_username.log 파일로 작성합니다.

사용자에게 /tmp에 대한 액세스 권한이 없으면 update.sh 유틸리티가 실패합니다.

제로 다운타임 업데이트

다운타임 없는 업데이트 또는 순차적 업데이트를 사용하면 Edge를 중단하지 않고 Edge 설치를 업데이트할 수 있습니다.

다운타임 없는 업데이트는 노드 5개 이상의 구성에서만 가능합니다.

다운타임 없는 업그레이드의 핵심은 부하 분산기에서 라우터를 한 번에 하나씩 삭제하는 것입니다. 그런 다음 라우터와 라우터와 동일한 머신에 있는 다른 구성요소를 업데이트한 후 라우터를 부하 분산기에 다시 추가합니다.

머신 업데이트 순서에 설명된 대로 설치에 적합한 순서로 머신을 업데이트합니다 .
라우터를 업데이트할 때가 되면 서버 (메시지 프로세서/라우터) 연결 가능성 사용 설정/사용 중지에 설명된 대로 라우터를 선택하고 연결할 수 없도록 설정합니다 .
선택한 라우터와 라우터와 동일한 머신의 다른 모든 Edge 구성요소를 업데이트합니다. 모든 Edge 구성은 동일한 노드에 라우터와 메시지 프로세서를 표시합니다.
라우터를 다시 연결할 수 있도록 합니다.
나머지 라우터에 대해 2~4단계를 반복합니다.
설치에 남아 있는 머신에 대한 업데이트를 계속합니다.

업데이트 전후에 다음 사항을 확인하세요.

결합된 라우터 및 메시지 프로세서 노드:
- 업데이트 전 – 다음을 수행합니다.
  1. 라우터에 연결할 수 없도록 설정
  2. 메시지 프로세서에 연결할 수 없도록 합니다.
- 업데이트 후 – 다음을 수행합니다.
  1. 메시지 프로세서에 도달할 수 있도록 합니다.
  2. 라우터에 연결할 수 있도록 설정
단일 라우터 노드:
- 업데이트하기 전에 라우터에 연결할 수 없도록 설정합니다.
- 업데이트 후 라우터에 연결할 수 있도록 합니다.
단일 메시지 프로세서 노드:
- 업데이트하기 전에 메시지 프로세서에 연결할 수 없도록 합니다.
- 업데이트 후 메시지 프로세서에 연결할 수 있도록 합니다.

자동 구성 파일 사용

업데이트 명령어에 무인 구성 파일을 전달해야 합니다. 자동 구성 파일은 프라이빗 클라우드용 Edge 4.53.00 또는 4.53.01을 설치하는 데 사용한 파일과 대부분 비슷하지만 새 Edge UI 및 Apigee SSO로 업그레이드 (설치된 경우)에 설명된 대로 UI 및 SSO와 같은 구성요소를 변경해야 할 수 있습니다.

외부 인터넷 연결이 있는 노드에서 4.54.00으로 업데이트

다음 절차에 따라 노드에서 Edge 구성요소를 업데이트합니다.

있는 경우 업데이트가 완료될 때까지 Cassandra에서 복구 작업을 수행하도록 구성된 cron 작업을 사용 중지합니다.
Edge RPM을 설치하려면 노드에 루트로 로그인합니다.

참고: RPM 설치에는 루트 액세스 권한이 필요하지만 루트 액세스 권한 없이 Edge 구성을 실행할 수 있습니다.
Edge apigee-setup 유틸리티 설치에 설명된 대로 SELinux를 사용 중지합니다 .

AWS에 설치하는 경우 다음 yum-configure-manager 명령어를 실행합니다.

yum update rh-amazon-rhui-client.noarch
yum-config-manager --enable rhui-REGION-rhel-server-extras rhui-REGION-rhel-server-optional

현재 프라이빗 클라우드용 Edge 4.53.00 또는 4.53.01을 사용 중인 경우:
1. Edge bootstrap_4.54.00.sh 파일을 /tmp/bootstrap_4.54.00.sh에 다운로드합니다.
```
curl https://software.apigee.com/bootstrap_4.54.00.sh -o /tmp/bootstrap_4.54.00.sh
```
2. 다음 명령어를 실행하여 Edge 4.54.00 apigee-service 유틸리티 및 종속 항목을 설치합니다.
```
bash /tmp/bootstrap_4.54.00.sh apigeeuser=uName apigeepassword=pWord
```
  여기서 uName:pWord는 Apigee에서 받은 사용자 이름과 비밀번호입니다. pWord를 생략하면 입력하라는 메시지가 표시됩니다.
  
  기본적으로 설치 프로그램은 Java 17 및 21이 설치되어 있는지 확인합니다.
3. 다음 예와 같이 apigee-service를 사용하여 apigee-setup 유틸리티를 업데이트합니다.
```
/opt/apigee/apigee-service/bin/apigee-service apigee-setup update
```
4. 다음 예와 같이 관리 서버에서 apigee-validate 유틸리티를 업데이트합니다.
```
/opt/apigee/apigee-service/bin/apigee-service apigee-validate update
```
5. 다음 예와 같이 관리 서버에서 apigee-provision 유틸리티를 업데이트합니다.
```
/opt/apigee/apigee-service/bin/apigee-service apigee-provision update
```
6. 다음 명령어를 실행하여 노드에서 update 유틸리티를 실행합니다.
```
/opt/apigee/apigee-setup/bin/update.sh -c component -f configFile
```
  머신 업데이트 순서에 설명된 순서대로 이 작업을 수행합니다.
  
  각 항목의 의미는 다음과 같습니다.
  - component은 업데이트할 Edge 구성요소입니다. 가능한 값은 다음과 같습니다.
    - edge : New Edge UI를 제외한 모든 Edge 구성요소: 관리 서버, 메시지 프로세서, 라우터, QPID 서버, Postgres 서버
    - ldap : OpenLDAP
    - ue : 새 Edge UI
    - qpid : Apigee Qpid
    - ps : Apigee PostgreSQL
    - zk : ZooKeeper
    - cs : Cassandra
  - configFile는 4.53.00 또는 4.53.01 설치 중에 Edge 구성요소를 정의하는 데 사용한 것과 동일한 구성 파일입니다.
  참고: 구성 파일은 'apigee' 사용자가 읽을 수 있어야 합니다. 소유자를 변경하려면 다음 명령어를 사용합니다.
```
chown apigee:apigee configFile
```
  component를 'all'로 설정하여 모든 구성요소에 대해 update.sh를 실행할 수 있지만 Edge 올인원 (AIO) 설치 프로필이 있는 경우에만 가능합니다. 예를 들면 다음과 같습니다.
```
/opt/apigee/apigee-setup/bin/update.sh -c all -f configFile
```
7. 아직 실행하지 않은 경우 실행 중인 모든 노드에서 New Edge UI 구성요소를 다시 시작합니다.
```
/opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart
```
8. 설치 테스트에 설명된 대로 관리 서버에서 apigee-validate 유틸리티를 실행하여 업데이트를 테스트합니다.

나중에 업데이트를 롤백하려면 4.54.00 롤백에 설명된 절차를 사용합니다.

로컬 저장소에서 4.54.00으로 업데이트

Edge 노드가 방화벽 뒤에 있거나 다른 방식으로 인터넷을 통해 Apigee 저장소에 액세스할 수 없는 경우 Apigee 저장소의 로컬 저장소 또는 미러에서 업데이트를 수행할 수 있습니다.

로컬 Edge 저장소를 만든 후 로컬 저장소에서 Edge를 업데이트하는 방법에는 두 가지가 있습니다.

저장소의 .tar 파일을 만들고 .tar 파일을 노드에 복사한 후 .tar 파일에서 Edge를 업데이트합니다.
다른 노드가 액세스할 수 있도록 로컬 저장소가 있는 노드에 웹 서버를 설치합니다. Apigee는 사용할 수 있는 Nginx 웹 서버를 제공하거나 자체 웹 서버를 사용할 수 있습니다.

로컬 4.54.00 저장소에서 업데이트하려면 다음을 실행하세요.

Edge apigee-setup 유틸리티 설치의 '로컬 Apigee 저장소 만들기'에 설명된 대로 로컬 4.54.00 저장소를 만듭니다.

참고: 기존 저장소가 있는 경우 Edge apigee-setup 유틸리티 설치의 '로컬 Apigee 저장소 업데이트'에 설명된 대로 4.54.00 저장소를 추가할 수 있습니다.
다음 방법 중 하나를 사용하여 타겟 노드에 apigee-service를 설치합니다.
- 옵션 1: .tar 파일에서 apigee-service 설치
  1. 로컬 저장소가 있는 노드에서 다음 명령어를 사용하여 로컬 저장소를 /opt/apigee/data/apigee-mirror/apigee-4.54.00.tar.gz라는 단일 .tar 파일로 패키징합니다.
```
/opt/apigee/apigee-service/bin/apigee-service apigee-mirror package
```
  2. Edge를 업데이트하려는 노드에 .tar 파일을 복사합니다. 예를 들어 새 노드의 /tmp 디렉터리에 복사합니다.
  3. 새 노드에서 파일을 /tmp 디렉터리에 untar합니다.
```
tar -xzf apigee-4.54.00.tar.gz
```
    이 명령어는 .tar 파일이 포함된 디렉터리에 repos라는 새 디렉터리를 만듭니다. 예를 들면 /tmp/repos입니다.
  4. /tmp/repos에서 Edge apigee-service 유틸리티 및 종속 항목을 설치합니다.
```
bash /tmp/repos/bootstrap_4.54.00.sh apigeeprotocol="file://" apigeerepobasepath=/tmp/repos
```
    이 명령어에 repos 디렉터리의 경로를 포함합니다.
- 옵션 2: Nginx 웹 서버를 사용하여 apigee-service 설치
  1. Edge apigee-setup 유틸리티 설치의 'Nginx 웹 서버를 사용하여 저장소에서 설치'에 설명된 대로 Nginx 웹 서버를 구성합니다.
  2. 원격 노드에서 Edge bootstrap_4.54.00.sh 파일을 /tmp/bootstrap_4.54.00.sh에 다운로드합니다.
```
/usr/bin/curl http://uName:pWord@remoteRepo:3939/bootstrap_4.54.00.sh -o /tmp/bootstrap_4.54.00.sh
```
    여기서 uName:pWord은 이전에 저장소에 설정한 사용자 이름과 비밀번호이고 remoteRepo은 저장소 노드의 IP 주소 또는 DNS 이름입니다.
  3. 원격 노드에서 Edge apigee-service 유틸리티 및 종속 항목을 설치합니다.
```
bash /tmp/bootstrap_4.54.00.sh apigeerepohost=remoteRepo:3939 apigeeuser=uName apigeepassword=pWord apigeeprotocol=http://
```
    여기서 uName:pWord는 저장소 사용자 이름과 비밀번호입니다.
다음 예와 같이 apigee-service를 사용하여 apigee-setup 유틸리티를 업데이트합니다.
```
/opt/apigee/apigee-service/bin/apigee-service apigee-setup update
```
다음 예와 같이 관리 서버에서 apigee-validate 유틸리티를 업데이트합니다.
```
/opt/apigee/apigee-service/bin/apigee-service apigee-validate update
```
다음 예와 같이 관리 서버에서 apigee-provision 유틸리티를 업데이트합니다.
```
/opt/apigee/apigee-service/bin/apigee-service apigee-provision update
```
머신 업데이트 순서에 설명된 순서대로 노드에서 update 유틸리티를 실행합니다.
```
/opt/apigee/apigee-setup/bin/update.sh -c component -f configFile
```
각 항목의 의미는 다음과 같습니다.
- component은 업데이트할 Edge 구성요소입니다. 가능한 값은 다음과 같습니다.
  - edge : New Edge UI를 제외한 모든 Edge 구성요소: 관리 서버, 메시지 프로세서, 라우터, QPID 서버, Postgres 서버
  - ldap : OpenLDAP
  - ue : 새 Edge UI
  - qpid : Apigee Qpid
  - ps : Apigee PostgreSQL
  - zk : ZooKeeper
  - cs : Cassandra
- configFile는 4.53.00 또는 4.53.01 설치 중에 Edge 구성요소를 정의하는 데 사용한 것과 동일한 구성 파일입니다.
  
  참고: 구성 파일은 'apigee' 사용자가 읽을 수 있어야 합니다. 소유자를 변경하려면 다음 명령어를 사용하세요.
```
chown apigee:apigee configFile
```
component를 'all'로 설정하여 모든 구성요소에 대해 update.sh를 실행할 수 있지만 Edge 올인원 (AIO) 설치 프로필이 있는 경우에만 가능합니다. 예를 들면 다음과 같습니다.
```
/opt/apigee/apigee-setup/bin/update.sh -c all -f configFile
```
아직 실행하지 않은 경우 UI 구성요소를 실행하는 모든 노드에서 UI 구성요소를 다시 시작합니다.
```
/opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart
```
설치 테스트에 설명된 대로 관리 서버에서 apigee-validate 유틸리티를 실행하여 업데이트를 테스트합니다.

나중에 업데이트를 롤백하려면 4.54.00 롤백에 설명된 절차를 사용합니다.

머신 업데이트 순서

Edge 설치에서 머신을 업데이트하는 순서가 중요합니다. 아래 순서대로 구성요소를 업그레이드합니다.

-c edge 옵션을 사용하여 모든 데이터 센터의 모든 라우터 및 메시지 프로세서 노드를 업그레이드합니다.
-c edge 옵션을 사용하여 모든 데이터 센터의 모든 관리 서버 노드를 업그레이드합니다.
모든 데이터 센터의 모든 LDAP 노드를 업그레이드합니다. 프라이빗 클라우드용 Edge 4.53.00에서 업그레이드하는 경우 LDAP 업그레이드의 특별 단계에 따라 추가 단계를 수행해야 합니다.
모든 데이터 센터에서 UI 및 Apigee SSO (설치된 경우)를 업그레이드합니다.
1. apigee-sso가 설치되지 않은 경우: 옵션 1: UI 업그레이드 (Apigee SSO 없음)에 따라 새 Edge UI로 업그레이드합니다.
2. apigee-sso가 설치된 경우: 옵션 2: UI 업그레이드 (Apigee SSO 사용)에 따라 새 Edge UI 및 Apigee SSO로 업그레이드합니다.
Qpid의 특별 단계에 따라 모든 데이터 센터에서 모든 Qpid 및 edge-qpid-server 구성요소를 업그레이드합니다.
Postgres의 특별 단계에 따라 모든 데이터 센터에서 모든 Postgresql 및 edge-postgres-server 구성요소를 업그레이드합니다.
Zookeeper 업그레이드의 특별 단계에 따라 모든 데이터 센터에서 모든 Zookeeper 구성요소를 업그레이드합니다.
Cassandra 업그레이드의 특별 단계에 따라 모든 데이터 센터의 모든 Cassandra 구성요소를 업그레이드합니다.
수익 창출을 업데이트하는 별도의 단계는 없습니다. -c edge 옵션을 지정하면 업데이트됩니다.

1노드 독립형 업그레이드

1노드 독립형 구성을 4.54.00으로 업그레이드하려면 다음 안내를 따르세요.

프라이빗 클라우드용 Edge 4.53.00에서 업그레이드할 때는 모든 구성요소의 업그레이드를 시작하기 전에 먼저 4.53.00에서 4.54.00으로 업그레이드하는 단계에 따라 LDAP를 업그레이드해야 합니다.

모든 구성요소 업데이트:

/opt/apigee/apigee-setup/bin/update.sh -c all -f configFile

(apigee-adminapi를 설치한 경우) apigee-adminapi 유틸리티를 업데이트합니다.
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```

2노드 독립형 업그레이드

2노드 독립형 설치를 위해 다음 구성요소를 업데이트합니다.

Edge 토폴로지 및 노드 번호 목록은 설치 토폴로지를 참조하세요.

머신 1에서 Edge 구성요소를 업데이트합니다.

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

머신 1에서 LDAP를 업데이트합니다.

/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile

머신 1에서 새로운 Edge UI를 업데이트합니다.
```
/opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile
```
참고: apigee-sso가 설치된 경우 Apigee SSO로 구성하는 방법은 옵션 2: UI 업그레이드 (Apigee SSO 사용)를 참조하세요.

머신 2에서 Edge 구성요소를 업데이트합니다.

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

머신 2에서 Qpid를 업데이트합니다.

/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

머신 2에서 Postgres를 업데이트합니다.

/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

머신 1에서 Cassandra 및 ZooKeeper를 업데이트합니다.
```
/opt/apigee/apigee-setup/bin/update.sh -c zk,cs -f configFile
```
(apigee-adminapi를 설치한 경우) 머신 1에서 apigee-adminapi 유틸리티를 업데이트합니다.
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```

노드 5개 업그레이드

5노드 설치를 위해 다음 구성요소를 업데이트합니다.

Edge 토폴로지 및 노드 번호 목록은 설치 토폴로지를 참조하세요.

머신 2, 3, 1에서 Edge 구성요소를 업데이트합니다.
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```

머신 1에서 LDAP를 업데이트합니다.

/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile

머신 1에서 New Edge UI를 업데이트합니다.
```
/opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile
```
참고: apigee-sso가 설치된 경우 Apigee SSO로 구성하는 방법은 옵션 2: UI 업그레이드 (Apigee SSO 사용)를 참조하세요.

머신 4, 5에서 Edge 구성요소를 업데이트합니다.

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

머신 4, 5에서 Qpid 업데이트:

/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

머신 4, 5에서 Postgres 업데이트:

/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

머신 1, 2, 3에서 Cassandra 및 ZooKeeper를 업데이트합니다.
```
/opt/apigee/apigee-setup/bin/update.sh -c zk,cs -f configFile
```
(apigee-adminapi를 설치한 경우) 머신 1에서 apigee-adminapi 유틸리티를 업데이트합니다.
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```

9노드 클러스터 업그레이드

9노드 클러스터 설치를 위해 다음 구성요소를 업데이트합니다.

Edge 토폴로지 및 노드 번호 목록은 설치 토폴로지를 참조하세요.

4, 5, 1번 머신 (라우터, 메시지 프로세서, 관리 서버)의 Edge 구성요소를 다음 순서로 업데이트합니다.
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```

머신 1에서 LDAP를 업데이트합니다.

/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile

머신 1에서 New Edge UI를 업데이트합니다.
```
/opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile
```
참고: apigee-sso가 설치된 경우 Apigee SSO로 구성하는 방법은 옵션 2: UI 업그레이드 (Apigee SSO 사용)를 참조하세요.
머신 6, 7, 8, 9에서 Edge 구성요소를 순서대로 업데이트합니다.
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```

머신 6 및 7에서 Qpid를 업데이트합니다.

/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

머신 8에서 Postgres를 업데이트합니다.

/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

머신 9에서 Postgres를 업데이트합니다.

/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

머신 1, 2, 3에서 Cassandra 및 ZooKeeper를 업데이트합니다.
```
/opt/apigee/apigee-setup/bin/update.sh -c zk,cs -f configFile
```
(apigee-adminapi를 설치한 경우) 머신 1에서 apigee-adminapi 유틸리티를 업데이트합니다.
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```

노드 13개 클러스터 업그레이드

13노드 클러스터 설치의 다음 구성요소를 업데이트합니다.

Edge 토폴로지 및 노드 번호 목록은 설치 토폴로지를 참고하세요.

머신 10, 11, 6, 7의 Edge 구성요소를 순서대로 업데이트합니다.
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```

머신 4 및 5에서 LDAP를 업데이트합니다.

/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile

머신 6, 7에서 New Edge UI를 업데이트합니다.
```
/opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile
```
참고: apigee-sso가 설치된 경우 Apigee SSO로 구성하는 방법은 옵션 2: UI 업그레이드 (Apigee SSO 사용)를 참조하세요.
12, 13, 8, 9번 컴퓨터에서 순서대로 Edge 구성요소를 업데이트합니다.
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```

머신 12 및 13에서 Qpid를 업데이트합니다.

/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

머신 8에서 Postgres를 업데이트합니다.

/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

머신 9에서 Postgres를 업데이트합니다.

/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

머신 1, 2, 3에서 Cassandra 및 ZooKeeper를 업데이트합니다.
```
/opt/apigee/apigee-setup/bin/update.sh -c zk,cs -f configFile
```
(apigee-adminapi를 설치한 경우) 머신 6과 7에서 apigee-adminapi 유틸리티를 업데이트합니다.
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```

노드 12개 클러스터 업그레이드

12노드 클러스터 설치의 다음 구성요소를 업데이트합니다.

Edge 토폴로지 및 노드 번호 목록은 설치 토폴로지를 참조하세요.

Edge (라우터 및 메시지 프로세서) 구성요소를 업데이트합니다.
- 데이터 센터 1의 머신 2, 3:
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
- 데이터 센터 2의 머신 8, 9:
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
Edge (Management Server) 구성요소를 업데이트합니다.
- 데이터 센터 1의 머신 1에서 다음을 실행합니다.
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
- 데이터 센터 2의 머신 7:
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```

LDAP 업데이트:

데이터 센터 1의 머신 1:

/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile

데이터 센터 2의 머신 7:

/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile

새 Edge UI 구성요소를 업데이트합니다.
- 데이터 센터 1의 머신 1에서 다음을 실행합니다.
```
/opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile
```
  참고: apigee-sso가 설치된 경우 Apigee SSO로 구성하는 방법은 옵션 2: UI 업그레이드 (Apigee SSO 사용)를 참조하세요.
- 데이터 센터 2의 머신 7:
```
/opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile
```
  참고: apigee-sso가 설치된 경우 Apigee SSO로 구성하는 방법은 옵션 2: UI 업그레이드 (Apigee SSO 사용)를 참고하세요.

Edge 구성요소를 업데이트합니다.

데이터 센터 1의 머신 4, 5, 6:

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

데이터 센터 2의 머신 10, 11, 12:

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

qpidd를 업데이트합니다.

데이터 센터 1의 머신 4, 5:

/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

데이터 센터 2의 머신 10, 11:

/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

Postgres 업데이트:

데이터 센터 1의 머신 6:

/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

데이터 센터 2의 머신 12:

/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

Cassandra 및 ZooKeeper를 업데이트합니다.

데이터 센터 1의 머신 1, 2, 3:

/opt/apigee/apigee-setup/bin/update.sh -c zk,cs -f configFile

데이터 센터 2의 머신 7, 8, 9:

/opt/apigee/apigee-setup/bin/update.sh -c zk,cs -f configFile

(apigee-adminapi를 설치한 경우) apigee-adminapi 유틸리티를 업데이트합니다.
- 데이터 센터 1의 머신 1:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```
- 데이터 센터 2의 머신 7:
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```

비표준 구성의 경우

비표준 구성이 있는 경우 다음 순서로 Edge 구성요소를 업데이트합니다.

라우터
메시지 프로세서
관리 서버
LDAP
UI (기본 UI 또는 새로운 UI)
SSO (해당하는 경우)
Qpid 및 edge-qpid-server
Postgres 및 edge-postgres-server
ZooKeeper
Cassandra
apigee-adminapi

Apigee Edge 4.53.00 또는 4.53.01을 4.54.00으로 업데이트

업데이트를 실행할 수 있는 사용자

업데이트해야 하는 구성요소

사전 읽기 자료

업그레이드 사전 준비 사항

속성 설정 자동 전파

라우터 및 메시지 프로세서 업그레이드

관리 서버 업그레이드

OpenLDAP 2.6.10으로 업그레이드

준비 및 설치 (모든 LDAP 서버)

LDAP를 4.53.00에서 4.54.00으로 업그레이드하는 단계

기본 요건 및 고려사항

LDAP를 4.53.01에서 4.54.00으로 업그레이드하는 단계

새 Edge UI 및 Apigee SSO (설치된 경우)로 업그레이드

옵션 1: UI 업그레이드 (Apigee SSO 없음)

1단계: 구성 파일 백업

2단계: 기본 인증의 자동 구성 파일 업데이트

3단계: UI 구성요소 업그레이드

4단계: New Edge UI 업그레이드 확인

옵션 2: UI 업그레이드 (Apigee SSO 사용)

1단계: 구성 파일 백업

2단계: 지원 중단된 UI/SSO 변수 삭제 및 자동 구성 파일 (configFile) 업데이트

3단계: New Edge UI 구성요소 업그레이드

4단계: apigee-sso 중지

5단계: Postgres 노드에서 Apigee SSO용 apigee_dex 데이터베이스 만들기

6단계: OpenLDAP 노드에서 Apigee SSO 설정

7단계: Apigee SSO의 관리 UI 구성 및 UI 다시 시작

8단계: 새로운 Edge UI 및 Apigee SSO 업그레이드 확인

9단계: 기존 apigee-sso 제거하기

Qpid 10.0.1로 업그레이드

Postgres 18.6으로 업그레이드

새 Postgres 대기 노드 설치

Postgres 인플레이스 업그레이드 수행

예비 단계

인플레이스(In-Place) 업그레이드 수행

Postgres 노드 사용 중단

Postgres 업그레이드 후 단계

ZooKeeper 3.8.5로 업그레이드

백업 수행

리더, 팔로어, 관찰자 식별

옵저버 및 팔로어 노드에서 ZooKeeper 업그레이드

리더 종료

새 리더가 선출되었는지 확인

업그레이드 리더

Cassandra 5.0.8로 업그레이드

업그레이드 및 롤백

단일 데이터 센터

여러 데이터 센터

권장 업그레이드 방법

롤백 체크포인트 프로세스

예

Cassandra 업그레이드 기본 요건

1단계: 업그레이드 준비

2단계: 모든 Cassandra 노드 업그레이드

Apigee mTLS로 업데이트

업데이트 롤백

로깅 업데이트 정보

제로 다운타임 업데이트

자동 구성 파일 사용

외부 인터넷 연결이 있는 노드에서 4.54.00으로 업데이트

로컬 저장소에서 4.54.00으로 업데이트

머신 업데이트 순서

1노드 독립형 업그레이드

2노드 독립형 업그레이드

노드 5개 업그레이드

9노드 클러스터 업그레이드

노드 13개 클러스터 업그레이드

노드 12개 클러스터 업그레이드

비표준 구성의 경우

2단계: 지원 중단된 UI/SSO 변수 삭제 및 자동 구성 파일 (`configFile`) 업데이트

4단계: `apigee-sso` 중지

5단계: Postgres 노드에서 Apigee SSO용 `apigee_dex` 데이터베이스 만들기

9단계: 기존 `apigee-sso` 제거하기