이 페이지는 Cloud Translation API를 통해 번역되었습니다.

Apigee Edge 4.51.00 또는 4.52.00 또는 4.52.01을 4.52.02로 업데이트

Apigee는 프라이빗 클라우드용 Edge를 버전 4.51.00, 4.52.00 또는 4.52.01에서 버전 4.52.02로 직접 업그레이드하는 기능을 지원합니다. 이 페이지에서는 이러한 업그레이드를 실행하는 방법을 설명합니다.

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

업데이트를 실행하는 사용자는 Edge를 처음 설치한 사용자 또는 root로 실행하는 사용자와 동일해야 합니다.

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

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

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

기본 요건 업데이트

Apigee Edge를 업그레이드하기 전에 다음 기본 요건을 충족해야 합니다.

모든 노드 백업
업데이트하기 전에 보안상의 이유로 모든 노드를 완전히 백업하는 것이 좋습니다. 현재 버전의 Edge에 해당하는 절차에 따라 백업을 실행합니다.
이렇게 하면 새 버전으로 업데이트가 제대로 작동하지 않을 경우를 대비한 백업 계획을 세울 수 있습니다. 백업에 관한 자세한 내용은 백업 및 복원을 참고하세요.
Edge가 실행 중인지 확인
다음 명령어를 사용하여 업데이트 프로세스 중에 Edge가 실행 중인지 확인합니다.
```
/opt/apigee/apigee-service/bin/apigee-all status
```
Cassandra 압축 전략이 LeveledCompactionStrategy인지 확인합니다.
현재 버전에 따라 Cassandra 압축 전략을 필요한 사항을 변경합니다. 아래 단계를 수행한 다음 기본 업그레이드 절차로 돌아갑니다.
- 버전 4.51.00에서 업그레이드하는 경우 v4.51.00용 Cassandra 압축 전략 문서를 참고하세요.
- 버전 4.52.00에서 업그레이드하는 경우 v4.52.00용 Cassandra 압축 전략 문서를 참고하세요.
- 버전 4.52.01에서 업그레이드하는 경우 v4.52.01용 Cassandra 압축 전략 문서를 참고하세요.

업그레이드 시 고려해야 할 특별한 단계

Edge for Private Cloud 4.52.02로 업그레이드하려면 특정 소프트웨어를 업그레이드하기 위한 특정 단계를 실행하는 것이 좋습니다. 필요한 단계는 현재 버전에 따라 다릅니다. 추가 단계가 필요한 다양한 소프트웨어는 아래 표를 참고하고 각 소프트웨어에 관한 자세한 안내를 따르세요. 필요한 작업을 완료한 후 기본 업그레이드 절차로 돌아가 업그레이드 프로세스를 계속합니다.

현재 버전	4.52.02로 업그레이드하는 데 특별한 단계가 필요한 소프트웨어
4.52.01	Cassandra
4.52.00	Zookeeper, Cassandra, Qpid
4.51.00	Zookeeper, Postgres, Cassandra, Qpid

사용 중인 버전에 따라 필요한 단계를 수행한 후 기본 업그레이드 절차로 돌아가서 계속 진행합니다.

속성 설정 자동 전파

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

Zookeeper 3.8.3으로 업그레이드

프라이빗 클라우드용 Edge 4.52.02에는 Zookeeper 업그레이드가 포함되어 있지 않습니다. 하지만 4.52.01보다 이전 버전에서 업그레이드하는 경우 아래에 설명된 Zookeeper 업그레이드 단계를 따라야 합니다.

Edge Private Cloud 버전 4.51.00 또는 4.52.00에서 업그레이드하는 경우 Zookeeper 3.8.3으로의 필수 업그레이드의 단계에 따라 Zookeeper를 업그레이드하세요.
프라이빗 클라우드용 Edge 버전 4.52.01에서 업그레이드하는 경우 이미 Zookeeper 버전 3.8.3을 사용하고 있어야 하며 Zookeeper를 업그레이드하기 위해 특별한 단계를 따를 필요가 없습니다.

참고:

Zookeeper와 Cassandra는 일반적으로 동일한 호스트 또는 가상 머신에 함께 배치되므로 Edge for Private Cloud 4.52.01에서 4.52.02로 업그레이드하는 것이 간소화됩니다. 따라서 중요한 Cassandra 업그레이드와 함께 별도의 Zookeeper 업그레이드 절차가 필요하지 않습니다.

Zookeeper를 특정 단계로 업데이트해야 하는 경우 한 번에 하나의 노드를 업데이트하여 모든 데이터 센터에서 Zookeeper를 업그레이드합니다. 전 세계의 모든 Zookeeper 노드가 업데이트되면 이 도움말 뒷부분에 설명된 절차에 따라 한 번에 하나의 데이터 센터씩 Cassandra를 업그레이드합니다.

다음 명령어는 별도의 Zookeeper 업그레이드를 지원합니다.

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

Zookeeper 롤백의 경우 표준 Zookeeper 롤백 절차를 사용하세요. Cassandra 또는 다른 구성요소에 롤백이 필요한 경우 해당 구성요소를 롤백해야 합니다. Zookeeper 롤백은 필요하지 않습니다.

Postgres 14로 업그레이드

프라이빗 클라우드용 Edge 4.51.00에서 4.52.02로 업그레이드하는 경우 프라이빗 클라우드용 Edge 4.52.02에 Postgres 업그레이드가 포함되어 있지 않더라도 Postgres 업그레이드 단계를 따라야 합니다. Private Cloud용 Edge 4.51.00에서 4.52.02로 업그레이드하려면 Postgres 업그레이드 단계를 추가로 진행해야 합니다. Postgres 14로의 필수 업그레이드 섹션을 참고하세요.
Private Cloud용 Edge 4.52.00 또는 4.52.01에서 4.52.02로 업그레이드하는 경우 추가 Postgres 업그레이드 단계가 필요하지 않습니다.

Cassandra 3.11.16으로 업그레이드

프라이빗 클라우드용 Apigee Edge 4.52.02에는 Cassandra를 버전 3.11.16으로 업그레이드하는 기능이 포함되어 있습니다. Cassandra는 Apigee의 핵심 구성요소이며 이번 업그레이드에는 Cassandra에 쿼리하고 쓰는 데 사용되는 다양한 런타임 및 관리 구성요소의 드라이버 소프트웨어 업데이트도 포함되어 있습니다.

이번 업그레이드는 대규모 업그레이드이므로 최신 버전에서 최적의 성능을 보장하기 위해 Cassandra의 Apigee 데이터 모델을 일부 변경해야 했습니다. 이러한 변경사항은 최소하지만 업그레이드가 시작되면 업그레이드 프로세스로 인해 특정 관리 API가 중단됩니다. 일반적으로 중단되는 정확한 관리 API는 아래의 관련 섹션에 나와 있습니다.

또한 업그레이드 프로세스로 인해 업그레이드 중인 데이터 센터의 더 많은 런타임 프록시 흐름과 관리 API가 중단됩니다. 이러한 중단을 최소화하려면 런타임 및 관리 트래픽을 업그레이드 중인 데이터 센터에서 격리하는 것이 중요합니다. 자세한 내용은 아래의 단일 데이터 센터 및 다중 데이터 센터 섹션을 참고하세요.

참고: cassandra-cli 도구는 Cassandra 3.X에서 더 이상 지원되지 않으며 사용할 수 없습니다.

개발자 포털 - API 문서화

Apigee Drupal 개발자 포털은 API 문서화에 다양한 기능을 제공합니다. Drupal 7 기반 개발자 포털을 사용하지 않는 것이 좋지만, 여전히 이 포털을 사용하고 SmartDocs 기능을 활용하는 경우 SmartDocs API 사용 문서가 적용됩니다. 최신 버전의 개발자 포털을 사용하는 경우 이 업그레이드 중에 API 문서에 영향을 미치지 않습니다.

Apigee를 버전 4.52.02로 업그레이드하면 Drupal 7 개발자 포털의 SmartDocs 기능을 사용하여 만든 API 모델은 자동으로 최신 버전으로 이전되지 않습니다. 개발자 포털을 사용하여 각 모델을 수동으로 내보낸 후 업그레이드를 완료한 후 다시 가져와야 합니다.

아래에 사용된 용어

런타임: 런타임은 런타임 프록시 트래픽 처리를 포함합니다. 여기에는 기존 프록시의 런타임 API 요청을 효과적으로 처리하기 위해 라우터와 메시지 프로세서에서 실행하는 모든 작업이 포함됩니다. 단, 새 프록시 또는 프록시의 새 버전 배포는 포함되지 않습니다.

관리: 관리에는 Apigee Edge 시스템의 관리가 포함됩니다. 여기에는 앱, 제품, 대상 서버, 키 저장소 등의 배포, 수정이 포함되며 이에 국한되지 않습니다. 모든 관리 API (및 Apigee UI, 개발자 포털과 같은 클라이언트)가 이 범위에 포함됩니다.

이 업그레이드 중에 업데이트가 실행되는 리전 또는 데이터 센터 (DC)에서 런타임 및 관리 트래픽이 영향을 받습니다. 업데이트되는 데이터 센터와 관계없이 모든 데이터 센터의 특정 관리 API에 영향을 미칩니다. 각 단계 후에 이러한 영향이 표시됩니다.

아래의 각 단계에서는 업그레이드 절차의 다양한 단계를 진행할 때 런타임 및 관리 상태가 설명됩니다.

업그레이드 전략

여러 데이터 센터

트래픽 연속성을 보장하고 다운타임을 방지하려면 한 번에 하나의 데이터 센터를 업그레이드해야 합니다. DC를 업그레이드하기 전에 트래픽을 다른 작동하는 DC로 다시 라우트해야 합니다.

참고:

업그레이드 중에 트래픽 영향을 방지하려면 업그레이드 중인 데이터 센터에서 일시적으로 트래픽을 리디렉션하는 데이터 센터별 (DC-by-DC) 접근 방식을 따르세요. 이를 통해 서비스 가용성을 유지하면서 Cassandra, 관리 서버, 런타임 노드의 업그레이드 프로세스를 제어할 수 있습니다.

데이터 센터 2개 설정의 경우 다음과 같은 대략적인 단계를 따르세요.

DC-1에서 DC-2로 트래픽을 리디렉션하고 DC-1로 들어오는 트래픽을 차단합니다.
Cassandra, 관리 서버, 런타임 구성요소를 포함하여 DC-1을 업그레이드합니다.
DC-1로 트래픽을 리디렉션하고 DC-2로 들어오는 트래픽을 차단합니다.
Cassandra, 관리 서버, 런타임 구성요소를 포함하여 DC-2를 업그레이드합니다.

이 프로세스를 통해 업그레이드를 실행하는 동안 원활한 트래픽 관리가 보장됩니다. 데이터 센터가 2개 이상인 설정에서는 트래픽이 완전히 업그레이드되었거나 아직 업그레이드되지 않은 데이터 센터로 일시적으로 리디렉션되므로 유사한 패턴을 따라야 합니다.

단일 데이터 센터

단일 데이터 센터 설정의 경우 업그레이드 절차가 런타임 트래픽 및 특정 관리 API에 상당한 영향을 미칩니다. 단일 데이터 센터 설정에는 다음 옵션이 제공됩니다.

업그레이드 중에 트래픽을 처리할 수 있도록 기존 데이터 센터 옆에 데이터 센터를 추가하여 Edge for Private Cloud 클러스터를 임시 데이터 센터로 확장한 다음 업그레이드 프로세스가 완료되면 데이터 센터 중 하나를 해제합니다.
데이터 센터를 추가로 확장할 수 없는 경우 다운타임에 대비하고 트래픽이 적은 기간에 업그레이드를 예약하여 관리 API 및 런타임 트래픽에 미치는 영향을 최소화하세요.

런타임 트래픽 및 관리 API에 미치는 영향을 방지하려면 추가 데이터 센터로 확장하는 것이 좋습니다. 업그레이드 중에는 업그레이드되는 데이터 센터에 다음과 같은 영향을 미치지만 이에 국한되지 않습니다.

OAuth 토큰을 새로고침하는 런타임 API
액세스 항목 정책을 사용하는 런타임 API
개발자 앱을 나열하는 관리 API
제품을 나열하는 관리 API

위에 설명된 영향은 모든 데이터 센터가 업그레이드될 때까지 모든 데이터 센터에서 작동하지 않는 특정 관리 API와는 별개입니다. 이러한 관리 API는 후속 섹션의 단계에 나와 있습니다.

롤백 - 개요

롤백 중 영향
Cassandra 3.11.x에서 2.1.x로 롤백하면 롤백이 실행되는 데이터 센터 (DC) 내의 런타임 트래픽과 관리 트래픽 모두에 영향을 미칩니다. 또한 현재 롤백 중인 DC와 관계없이 특정 관리 API에 모든 데이터 센터에서 중단이 발생할 수 있습니다.
DC 롤백 접근 방식에 따른 DC 따라하기
서비스 연속성을 유지하고 다운타임을 방지하려면 한 번에 하나의 데이터 센터에서 롤백을 실행해야 합니다. 특정 DC에서 롤백을 시작하기 전에 애플리케이션 트래픽이 완전히 작동하는 다른 데이터 센터로 다시 라우팅되었는지 확인합니다.
부분적으로 업그레이드된 클러스터 롤백
이전 버전의 Cassandra (2.1.22)에서 하나 이상의 데이터 센터가 계속 완전히 작동하는 경우 완전히 작동하는 Cassandra 2.1.X DC에서 다시 빌드하여 다른 업그레이드된 DC를 롤백할 수 있습니다.
클러스터 전체 롤백
전체 Cassandra 클러스터가 업그레이드되었으며 롤백이 필요한 경우 백업 또는 VM 스냅샷을 사용하여 롤백을 실행해야 합니다. 이 접근 방식은 복잡하며 일시적인 다운타임 또는 데이터 손실이 발생할 수 있습니다.
업그레이드 전 고려사항
업그레이드를 시도하기 전에 롤백 절차를 숙지하는 것이 중요합니다. 적절한 롤백 경로를 사용할 수 있도록 업그레이드하는 동안 롤백의 미묘한 차이를 고려하는 것이 중요합니다.

단일 데이터 센터를 사용하는 클러스터 롤백

Cassandra를 버전 2.1.x에서 3.11.x로 업그레이드하면 런타임 트래픽과 특정 관리 API에 상당한 영향을 미칠 수 있습니다. 이러한 영향은 롤백 중에 적용되며 다운타임 또는 데이터 손실이 발생할 수 있습니다.

프로덕션 워크로드의 경우 업그레이드하기 전에 새 데이터 센터를 프로비저닝하는 것이 좋습니다. 이를 통해 데이터 손실이나 API 트래픽 중단 없이 더 안전한 롤백 경로를 사용할 수 있습니다. 업그레이드가 완료된 후에는 추가 데이터 센터를 지원 중단할 수 있습니다.

새 데이터 센터를 추가할 수 없지만 롤백 기능이 여전히 필요한 경우 업그레이드하기 전에 안정적인 백업을 수행해야 합니다. 백업에서 Cassandra 2.1.x를 복원할 수는 있지만 이 접근 방식을 사용하면 서비스 중단이 발생하고 데이터가 손실될 수 있습니다.

여러 데이터 센터가 있는 클러스터 롤백

여러 데이터 센터를 롤백할 때는 데이터 센터별 (DC-by-DC) 접근 방식을 따릅니다. 이 접근 방식에서는 롤백되는 데이터 센터의 트래픽이 다른 작동 중인 데이터 센터로 리디렉션되므로 Cassandra, 관리 서버, 런타임 노드의 롤백 프로세스를 제어하고 격리하여 트래픽 중단을 방지할 수 있습니다.

자세한 내용은 Cassandra 3.11.16 롤백 업데이트 섹션을 참고하세요.

0단계: 시작 상태

Zookeeper, Postgres, LDAP 구성요소는 이미 4.52.02 버전으로 업그레이드되었습니다. 프라이빗 클라우드 클러스터용 Edge가 안정적으로 작동합니다. 롤백이 필요한 경우 클러스터가 이 상태로 롤백됩니다.
Apigee의 Cassandra가 버전 2.1.22로 실행됩니다.
Edge 구성요소:

이전 thrift 프로토콜을 통해 Cassandra와 통신하는 관리 서버
이전 thrift 프로토콜을 통해 Cassandra와 통신하는 런타임 서버 (메시지 프로세서 및 라우터)

이 단계의 런타임 상태	이 단계의 관리 상태
런타임이 완전히 작동함	관리가 완전히 작동함

1단계: 업그레이드 준비

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

LeveledCompactionStrategy를 사용하도록 Cassandra를 변경합니다.
Apigee를 사용하여 Cassandra를 백업합니다.
Cassandra 노드의 VM 스냅샷을 찍습니다 (가능하면).
/opt/apigee/apigee-cassandra/cass_upgrade.conf의 각 Cassandra 노드에 다음 콘텐츠가 포함된 Cassandra 업그레이드 구성 파일을 만듭니다.
```
# IP Address of node
HOSTIP=10.0.0.1

# Username for running Cassandra queries. Optional. Can be skipped if you have not enabled Cassandra authentication.
CASS_USERNAME=<cassuser>

# Password for running Cassandra queries. Optional. Can be skipped if you have not enabled Cassandra authentication.
CASS_PASSWORD=<casspass>

# Port for connecting to Cassandra via thrift. Optional. Defaults to 9160 if skipped.
CASS_PORT=9160

# Port for connecting to Cassandra via CQL. Optional. Defaults to 9042 if skipped.
CASS_CQL_PORT=9042

# Directory to be used by Cassandra upgrade scripts. Optional. Defaults to /tmp/cass_upgrade_scripts if skipped.
# Note that if upgrade is successful, this directory is deleted via root user - so provide a directory accordingly.
CASS_TMP_DIR=/tmp/cass_upgrade_scripts
    
```
/opt/apigee/apigee-cassandra/cass_upgrade.conf에서 파일을 만들 수 없는 경우 각 Cassandra 노드에 동일한 콘텐츠가 포함된 /opt/silent.conf 파일을 만듭니다.
주의: Apigee의 업그레이드 설치 프로그램은 위에 나열된 위치에서 파일을 찾습니다. 위에 나열된 위치 중 어느 곳에도 파일이 없으면 업그레이드가 실패하며 다음과 같은 메시지가 표시됩니다.
```
could not read env location: '/opt/apigee/apigee-cassandra/cass_upgrade.conf'
file does not exist or cannot be sourced
could not read env location: '/opt/silent.conf'
file does not exist or cannot be sourced
```
이 경우 업그레이드가 실패하지만 노드의 Cassandra 서비스는 중지된 상태일 수 있습니다. 평소와 같이 Cassandra 서비스를 시작하고 예상 위치 중 하나에 구성 파일을 배치하여 업그레이드를 다시 시도할 수 있습니다. 또한 파일이 있지만 제공된 구성이 잘못된 경우 (예: Cassandra 사용자 인증 정보가 잘못됨) 업그레이드가 실패하고 다음과 같은 오류가 발생합니다.
```
Error in PREIN scriptlet in rpm package apigee-cassandra-X.XX.XX-X.X.XXXX.noarch
```
이 경우에도 마찬가지로 업그레이드에 실패하여 중지된 경우 Cassandra 서비스를 시작하고 파일에서 구성을 수정한 후 업그레이드를 다시 시도합니다.
Apigee Drupal 7 개발자 포털의 SmartDocs 기능을 사용하는 경우 개발자 포털 UI에서 JSON 형식으로 각 모델을 다운로드하여 내보냅니다. 이러한 모델은 관리 서버가 업데이트된 후 Apigee로 다시 가져와야 합니다.
포트 9160 및 9042가 아직 없는 경우 모든 Edge 구성요소에서 Cassandra 노드에 액세스할 수 있는지 확인합니다. 자세한 내용은 포트 요구사항을 참고하세요.

2단계: 첫 번째 데이터 센터에서 트래픽 리디렉션

첫 번째 데이터 센터에서 들어오는 런타임 및 관리 트래픽을 차단합니다.
모든 런타임 트래픽 및 관리 API를 다른 작동하는 데이터 센터로 리디렉션합니다.
런타임 및 관리 트래픽이 다른 DC에서 성공적으로 처리되는지 확인합니다.

3단계: 첫 번째 데이터 센터의 모든 Cassandra 노드 업그레이드

데이터 센터의 모든 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 5.0.1 | Cassandra 3.11.16 | CQL spec 3.4.4 | Native protocol v3] Metadata is verified

업그레이드가 완료된 후 각 Cassandra 노드에서 다음 post_upgrade 명령어를 하나씩 실행합니다.
```
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra post_upgrade
```

이 단계의 런타임 상태	이 단계의 관리 상태
업그레이드 중인 데이터 센터에서 런타임 트래픽이 차단됨 다른 데이터 센터에서 런타임이 완전히 작동함	업그레이드 중인 데이터 센터에서 관리 트래픽이 차단되었습니다. 다른 데이터 센터에서 Cassandra가 업그레이드된 후 다음 관리 기능이 저하됩니다. 환경이 포함된 API 제품을 만드는 Management API 환경으로 API 제품을 업데이트하는 Management API 조직을 삭제하는 관리 API

4단계: 첫 번째 데이터 센터의 모든 관리 노드 업그레이드

데이터 센터의 모든 관리 노드를 업그레이드합니다.

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

이 단계의 런타임 상태	이 단계의 관리 상태
업그레이드 중인 데이터 센터에서 런타임 트래픽이 차단됨 런타임이 완전히 작동함	업그레이드 중인 데이터 센터에서 관리 트래픽이 차단되었습니다. Cassandra를 업그레이드한 후 다음 관리 기능이 저하됩니다. 환경이 포함된 API 제품을 만드는 Management API 환경으로 API 제품을 업데이트하는 관리 API 조직을 삭제하는 관리 API

5단계: 첫 번째 데이터 센터의 모든 런타임 노드 업그레이드

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

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

이 단계의 런타임 상태	이 단계의 관리 상태
업그레이드 중인 데이터 센터에서 런타임 트래픽이 차단됨 다른 데이터 센터에서 런타임이 완전히 작동함	업그레이드 중인 데이터 센터에서 관리 트래픽이 차단되었습니다. 다른 데이터 센터에서 Cassandra가 업그레이드된 후 다음 관리 기능이 저하됩니다. 환경이 포함된 API 제품을 만드는 Management API 환경으로 API 제품을 업데이트하는 Management API 조직을 삭제하는 관리 API

6단계: 트래픽을 첫 번째 데이터 센터로 다시 리디렉션

첫 번째 데이터 센터가 Cassandra, 런타임 구성요소, 관리 서버로 업그레이드되면 첫 번째 데이터 센터로의 런타임 및 관리 트래픽을 다시 사용 설정합니다.
여러 데이터 센터에서 런타임 및 관리 트래픽이 성공적으로 전송되는지 확인합니다.

7단계: 다른 데이터 센터 업그레이드

나머지 데이터 센터에서 트래픽을 리디렉션하고, Apigee 소프트웨어를 업데이트하고, 해당 데이터 센터에서 트래픽을 다시 사용 설정하여 1단계~6단계를 한 번에 하나씩 반복합니다.

8단계: 모든 관리 노드에서 업그레이드 단계 다시 실행

데이터 센터의 모든 관리 노드에서 다음 업그레이드 명령어를 다시 실행합니다.

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

9단계 - [선택사항] 이전에 내보낸 스마트 문서 가져오기

모든 관리 서버가 업그레이드되면 1단계에서 내보낸 스마트 문서 모델을 가져올 수 있습니다. 나중에 결정해도 됩니다.

Drupal 7 기반 개발자 포털을 사용하고 스마트 문서 기능을 사용하는 경우에만 이 작업을 실행하면 됩니다.

이 단계의 런타임 상태	이 단계의 관리 상태
런타임이 완전히 작동함	관리가 완전히 작동함

10단계 - 사용하지 않는 테이블 삭제

다음 명령어를 실행하여 Cassandra 클러스터에서 오래된 사용하지 않는 테이블을 삭제합니다. 이 작업이 실행될 때까지 Cassandra의 특정 기능 (예: 새 인증 설정)을 사용할 수 없습니다. 이전 인증 메커니즘은 계속 작동합니다. 이 명령어는 클러스터의 노드 하나에서만 실행할 수 있습니다.

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra drop_old_tables -f configFile

11단계 - Private Cloud 4.52.02의 나머지 모든 Edge 및 기타 구성요소 업그레이드

모든 리전의 나머지 edge-qpid-server 및 edge-postgres-server 노드를 하나씩 업그레이드합니다.

이 단계에서 아래와 같이 Edge for Private Cloud 4.52.01 이전 버전에서 업그레이드하는 경우 Qpid 및 Postgres를 각각 업그레이드하기 위한 추가 단계를 수행하고 나머지 구성요소는 이 단계에 따라 업그레이드합니다.

Qpid J-Broker로 업그레이드

Edge for Private Cloud 4.52.02에는 Qpid 업그레이드가 포함되어 있지 않지만 4.52.01보다 이전 버전에서 업그레이드하는 경우 QPID를 업그레이드하는 단계를 따라야 합니다.

프라이빗 클라우드용 Edge 4.51.00 또는 4.52.00에서 4.52.02로 업그레이드하는 경우 추가 Qpid 업그레이드 단계를 따라야 합니다. 버전 4.51.00 또는 4.52.00에서 4.52.02로 업그레이드하는 경우 Qpid 업그레이드 섹션을 참고하세요.
Edge for Private Cloud 4.52.01에서 4.52.02로 업그레이드하는 경우 이미 최신 버전의 Qpid 브로커를 사용하고 있어야 하며 추가 Qpidupgrade 단계가 필요하지 않습니다.

새 Edge UI

이 섹션에는 Edge UI와 관련된 고려사항이 나열되어 있습니다. 자세한 내용은 프라이빗 클라우드용 새 Edge UI를 참고하세요.

Edge UI 설치

초기 설치를 완료한 후에는 Apigee Edge for Private Cloud의 개발자 및 관리자를 위한 향상된 사용자 인터페이스인 Edge UI를 설치하는 것이 좋습니다.

Edge UI를 사용하려면 기본 인증을 사용 중지하고 SAML 또는 LDAP와 같은 IDP를 사용해야 합니다.

자세한 내용은 새 Edge UI 설치를 참고하세요.

Edge UI 업데이트

Edge UI 구성요소를 업데이트하려면 업그레이드하려는 Edge for Private Cloud 버전을 고려하세요.

4.51.00에서 4.52.00으로 (새 Edge UI가 이미 설치됨): edge-management-ui 구성요소에 이 섹션의 업그레이드 안내를 사용합니다.

Apigee mTLS로 업데이트

Apigee mTLS를 업데이트하려면 다음 단계를 따르세요.

Apigee mTLS를 제거합니다.
Apigee mTLS를 다시 설치합니다.

업데이트 롤백

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

업데이트를 이전 버전으로 롤백해야 하는 경우 자세한 안내는 4.52.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. 라우터에 연결할 수 있도록 합니다.
단일 라우터 노드:
- 업데이트하기 전에 라우터에 연결할 수 없도록 합니다.
- 업데이트 후 라우터에 연결할 수 있도록 합니다.
단일 메시지 프로세서 노드에서 다음을 실행합니다.
- 업데이트하기 전에 메시지 프로세서에 연결할 수 없도록 합니다.
- 업데이트 후 메시지 프로세서에 연결할 수 있도록 합니다.

무음 구성 파일 사용

update 명령어에 무음 구성 파일을 전달해야 합니다. 무음 구성 파일은 Edge 4.50.00 또는 4.51.00을 설치하는 데 사용한 것과 동일해야 합니다.

외부 인터넷에 연결된 노드에서 4.52.02로 업데이트

노드에서 Edge 구성요소를 업데이트하려면 다음 절차를 따르세요.

있는 경우 업데이트가 완료될 때까지 Cassandra에서 수리 작업을 실행하도록 구성된 cron 작업을 사용 중지합니다.
루트로 노드에 로그인하여 Edge RPM을 설치합니다.
참고: RPM 설치에는 루트 액세스 권한이 필요하지만 루트 액세스 권한 없이도 Edge 구성을 실행할 수 있습니다.
yum-utils 및 yum-plugin-priorities를 설치합니다.
참고: 운영체제가 RHEL 8.0~8.6인 경우 이 단계를 건너뜁니다.
```
sudo yum install yum-utils
sudo yum install yum-plugin-priorities
```
Edge apigee-setup 유틸리티 설치에 설명된 대로 SELinux를 사용 중지합니다.
Oracle 7.x에 설치하는 경우 다음 명령어를 실행합니다.
```
sudo yum-config-manager --enable ol7_optional_latest
```

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

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

현재 Edge 4.51.00을 사용하는 경우:
1. Edge bootstrap_4.52.02.sh 파일을 /tmp/bootstrap_4.52.02.sh로 다운로드합니다.
```
curl https://software.apigee.com/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.sh
```
2. 다음 명령어를 실행하여 Edge 4.52.02 apigee-service 유틸리티 및 종속 항목을 설치합니다.
```
sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord
```
  여기서 uName:pWord은 Apigee에서 받은 사용자 이름과 비밀번호입니다. pWord를 생략하면 입력하라는 메시지가 표시됩니다.
  
  기본적으로 설치 프로그램은 Java 1.8이 설치되어 있는지 확인합니다. 설치하지 않으면 설치 프로그램에서 자동으로 설치합니다.
  
  JAVA_FIX 옵션을 사용하여 Java 설치를 처리하는 방법을 지정합니다. JAVA_FIX는 다음 값을 사용합니다.
  - I: OpenJDK 1.8을 설치합니다 (기본값).
  - C: Java를 설치하지 않고 계속 진행합니다.
  - Q: 종료 이 옵션을 사용하려면 Java를 직접 설치해야 합니다.
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 구성요소입니다. 가능한 값은 다음과 같습니다.
    - cs: Cassandra
    - edge: Edge UI를 제외한 모든 Edge 구성요소: 관리 서버, 메시지 프로세서, 라우터, Qpid 서버, Postgres 서버
    - ldap: OpenLDAP
    - ps: postgresql
    - qpid: qpidd
    - sso: Apigee SSO (SSO를 설치한 경우)
    - ue: 새로운 Edge UI
    - ui: 기존 Edge UI
    - zk: Zookeeper
  - configFile는 4.50.00 또는 4.51.00 설치 중에 Edge 구성요소를 정의하는 데 사용한 것과 동일한 구성 파일입니다.
  Edge 올인원 (AIO) 설치 프로필이 있는 경우에만 component을 'all'로 설정하여 모든 구성요소에 대해 update.sh를 실행할 수 있습니다. 예를 들면 다음과 같습니다.
```
/opt/apigee/apigee-setup/bin/update.sh -c all -f ./sa_silent_config
```
7. 아직 Edge UI 구성요소를 실행하는 모든 노드에서 Edge UI 구성요소를 다시 시작합니다.
```
/opt/apigee/apigee-service/bin/apigee-service [edge-management-ui|edge-ui] restart
```
8. 설치 테스트에 설명된 대로 관리 서버에서 apigee-validate 유틸리티를 실행하여 업데이트를 테스트합니다.

나중에 업데이트를 롤백하려면 4.52.02 롤백에 설명된 절차를 따르세요.

로컬 저장소에서 4.52.02로 업데이트

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

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

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

로컬 4.52.02 저장소에서 업데이트하려면 다음 단계를 따르세요.

Edge apigee-setup 유틸리티 설치의 '로컬 Apigee 저장소 만들기'에 설명된 대로 로컬 4.52.02 저장소를 만듭니다.
참고: 기존 저장소가 이미 있는 경우 Edge apigee-setup 유틸리티 설치의 '로컬 Apigee 저장소 업데이트'에 설명된 대로 4.52.02 저장소를 추가할 수 있습니다.
.tar 파일에서 apigee-service를 설치하려면 다음 단계를 따르세요.
1. 로컬 저장소가 있는 노드에서 다음 명령어를 사용하여 로컬 저장소를 /opt/apigee/data/apigee-mirror/apigee-4.52.02.tar.gz라는 단일 .tar 파일로 패키징합니다.
```
/opt/apigee/apigee-service/bin/apigee-service apigee-mirror package
```
2. .tar 파일을 Edge를 업데이트할 노드에 복사합니다. 예를 들어 새 노드의 /tmp 디렉터리에 복사합니다.
3. 새 노드에서 파일의 압축을 풀어 /tmp 디렉터리에 배치합니다.
```
tar -xzf apigee-4.52.02.tar.gz
```
  이 명령어는 .tar 파일이 포함된 디렉터리에 repos라는 새 디렉터리를 만듭니다. 예: /tmp/repos
4. /tmp/repos에서 Edge apigee-service 유틸리티 및 종속 항목을 설치합니다.
```
sudo bash /tmp/repos/bootstrap_4.52.02.sh apigeeprotocol="file://" apigeerepobasepath=/tmp/repos
```
  이 명령어에는 저장소 디렉터리의 경로가 포함됩니다.
Nginx 웹서버를 사용하여 apigee-service를 설치하려면 다음 단계를 따르세요.
1. Edge apigee-setup 유틸리티 설치의 'Nginx 웹 서버를 사용하여 저장소에서 설치'에 설명된 대로 Nginx 웹 서버를 구성합니다.
2. 원격 노드에서 Edge bootstrap_4.52.02.sh 파일을 /tmp/bootstrap_4.52.02.sh로 다운로드합니다.
```
/usr/bin/curl http://uName:pWord@remoteRepo:3939/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.52.02.sh
```
  여기서 uName:pWord는 이전에 저장소에 설정한 사용자 이름과 비밀번호이고 remoteRepo는 저장소 노드의 IP 주소 또는 DNS 이름입니다.
3. 원격 노드에서 Edge apigee-setup 유틸리티와 종속 항목을 설치합니다.
```
sudo bash /tmp/bootstrap_4.52.02.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 구성요소입니다. 일반적으로 다음 구성요소를 업데이트합니다.
  - cs: Cassandra
  - edge: Edge UI를 제외한 모든 Edge 구성요소: 관리 서버, 메시지 프로세서, 라우터, Qpid 서버, Postgres 서버
  - ldap: OpenLDAP
  - ps: postgresql
  - qpid: qpidd
  - sso: Apigee SSO (SSO를 설치한 경우)
  - ue 새 Edge UI
  - ui: 기존 Edge UI
  - zk: Zookeeper
- configFile는 4.50.00 또는 4.51.00 설치 중에 Edge 구성요소를 정의하는 데 사용한 것과 동일한 구성 파일입니다.
  참고: 구성 파일은 'apigee' 사용자가 읽을 수 있어야 합니다. 소유자를 변경하려면 다음 명령어를 사용합니다.
```
chown apigee:apigee configFile
```
Edge 올인원 (AIO) 설치 프로필이 있는 경우에만 component을 'all'로 설정하여 모든 구성요소에 대해 update.sh를 실행할 수 있습니다. 예를 들면 다음과 같습니다.
```
/opt/apigee/apigee-setup/bin/update.sh -c all -f /tmp/sa_silent_config
```
아직 실행하지 않았다면 UI 구성요소를 실행하는 모든 노드에서 UI 구성요소를 다시 시작합니다.
```
/opt/apigee/apigee-service/bin/apigee-service [edge-management-ui|edge-ui] restart
```
설치 테스트에 설명된 대로 관리 서버에서 apigee-validate 유틸리티를 실행하여 업데이트를 테스트합니다.

나중에 업데이트를 롤백하려면 4.52.02 롤백에 설명된 절차를 따르세요.

머신 업데이트 순서 - 4.51.00 (또는) 4.52.00 (또는) 4.52.01에서 업그레이드

Edge 설치에서 머신을 업데이트하는 순서는 중요합니다.

다른 모든 구성요소를 업그레이드하기 전에 데이터 센터의 모든 ZooKeeper 노드를 업데이트해야 합니다. Edge Private Cloud 4.51.00 또는 4.52.00에서 업그레이드하는 경우 zookeeper를 업그레이드하기 위한 추가 단계도 따라야 합니다.
모든 데이터 센터에서 Postgresql을 업데이트해야 합니다. Edge Private Cloud 4.51.00에서 업그레이드하는 경우 PostgreSQL을 업그레이드하기 위한 추가 단계도 따라야 합니다.
모든 데이터 센터에서 LDAP 노드를 업데이트해야 합니다.
모든 데이터 센터가 업그레이드될 때까지 모든 Cassandra, 관리 서버, 메시지 프로세서, 라우터 노드를 한 번에 하나의 데이터 센터씩 업데이트해야 합니다.
모든 데이터 센터에서 edge-qpid-server 및 edge-postgres-server 구성요소를 업데이트해야 합니다.
모든 데이터 센터에서 Qpid 노드를 업그레이드해야 합니다. Edge Private Cloud 4.51.00 또는 4.52.00에서 업그레이드하는 경우 Qpid를 업그레이드하기 위한 추가 단계도 따라야 합니다.
모든 데이터 센터의 Edge UI 및 새 Edge UI, SSO 노드를 업데이트합니다.
수익 창출을 업데이트하는 별도의 단계는 없습니다. -c edge 옵션을 지정하면 업데이트됩니다.
참고: Edge UI 구성요소를 업데이트한 후에는 업데이트 설치 안내에 설명된 대로 Edge UI 서비스를 다시 시작해야 합니다.

노드 1개 독립형 업그레이드

1노드 독립형 구성을 4.52.02로 업그레이드하는 방법:

모든 구성요소 업데이트:

/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노드 독립형 설치의 경우 다음 구성요소를 업데이트합니다.

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

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

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

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

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

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

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

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

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

머신 1 및 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

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

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

(apigee-adminapi를 설치한 경우) 머신 1에서 apigee-adminapi 유틸리티를 업데이트했습니다.
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```
(Apigee SSO를 설치한 경우) 머신 1에서 Apigee SSO를 업데이트합니다.
```
/opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file
```
여기서 sso_config_file은 SSO를 설치할 때 만든 구성 파일입니다.
머신 1에서 Edge UI 구성요소를 다시 시작합니다.
```
/opt/apigee/apigee-service/bin/apigee-service edge-ui restart
```

5노드 업그레이드

5노드 설치의 경우 다음 구성요소를 업데이트합니다.

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

머신 1, 2, 3에서 ZooKeeper를 업데이트합니다.

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

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

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

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

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

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

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

머신 1, 2, 3에서 Cassandra를 업데이트합니다.

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

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

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

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

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

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

Edge UI를 업데이트합니다.
- 기존 UI: 기존 UI를 사용하는 경우 다음 예와 같이 머신 1에서 ui 구성요소를 업데이트합니다.
```
/opt/apigee/apigee-setup/bin/update.sh -c ui -f configFile
```
- 새로운 Edge UI: 새 Edge UI를 설치한 경우 적절한 머신 (머신 1이 아닐 수 있음)에서 ue 구성요소를 업데이트합니다.
```
/opt/apigee/apigee-setup/bin/update.sh -c ue -f /opt/silent.conf
```
(apigee-adminapi를 설치한 경우) 머신 1에서 apigee-adminapi 유틸리티를 업데이트했습니다.
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```
(Apigee SSO를 설치한 경우) 머신 1에서 Apigee SSO를 업데이트합니다.
```
/opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file
```
여기서 sso_config_file은 SSO를 설치할 때 만든 구성 파일입니다.
UI 구성요소를 다시 시작합니다.
- 기존 UI: 기존 UI를 사용하는 경우 다음 예와 같이 머신 1에서 edge-ui 구성요소를 다시 시작합니다.
```
/opt/apigee/apigee-service/bin/apigee-service edge-ui restart
```
- 새로운 Edge UI: 새 Edge UI를 설치한 경우 적절한 머신 (머신 1이 아닐 수 있음)에서 edge-management-ui 구성요소를 다시 시작합니다.
```
/opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart
```

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

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

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

머신 1, 2, 3에서 ZooKeeper를 업데이트합니다.

/opt/apigee/apigee-setup/bin/update.sh -c zk -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에서 LDAP를 업데이트합니다.

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

머신 1, 2, 3에서 Cassandra를 업데이트합니다.

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

머신 1, 4, 5, 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

머신 1에서 새 UI (ue) 또는 기존 UI (ui)를 업데이트합니다.
```
/opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile
```
(apigee-adminapi를 설치한 경우) 머신 1에서 apigee-adminapi 유틸리티를 업데이트합니다.
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```
(Apigee SSO를 설치한 경우) 머신 1에서 Apigee SSO를 업데이트합니다.
```
/opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file
```
여기서 sso_config_file은 SSO를 설치할 때 만든 구성 파일입니다.
UI 구성요소를 다시 시작합니다.
- 기존 UI: 기존 UI를 사용하는 경우 다음 예와 같이 머신 1에서 edge-ui 구성요소를 다시 시작합니다.
```
/opt/apigee/apigee-service/bin/apigee-service edge-ui restart
```
- 새로운 Edge UI: 새 Edge UI를 설치한 경우 적절한 머신 (머신 1이 아닐 수 있음)에서 edge-management-ui 구성요소를 다시 시작합니다.
```
/opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart
```

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

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

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

머신 1, 2, 3에서 ZooKeeper를 업데이트합니다.

/opt/apigee/apigee-setup/bin/update.sh -c zk -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

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

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

머신 1, 2, 3에서 Cassandra를 업데이트합니다.

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

머신 6, 7, 10, 11, 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

머신 6 및 7에서 새 UI (ue) 또는 기존 UI (ui)를 업데이트합니다.
```
/opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile
```
(apigee-adminapi를 설치한 경우) 머신 6 및 7에서 apigee-adminapi 유틸리티를 업데이트했습니다.
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```
(Apigee SSO를 설치한 경우) 머신 6 및 7에서 Apigee SSO를 업데이트합니다.
```
/opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file
```
여기서 sso_config_file은 SSO를 설치할 때 만든 구성 파일입니다.
UI 구성요소를 다시 시작합니다.
- 기존 UI: 기존 UI를 사용하는 경우 다음 예와 같이 머신 6 및 7에서 edge-ui 구성요소를 다시 시작합니다.
```
/opt/apigee/apigee-service/bin/apigee-service edge-ui restart
```
- 새 Edge UI: 새 Edge UI를 설치한 경우 머신 6 및 7에서 edge-management-ui 구성요소를 다시 시작합니다.
```
/opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart
```

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

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

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

두 데이터 센터의 머신 1,2,3,7,8,9에서 ZooKeeper를 업데이트합니다.
```
/opt/apigee/apigee-setup/bin/update.sh -c zk -f configFile
```
두 데이터 센터의 머신 6,12에서 Postgres를 업데이트합니다.
```
/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
```

두 DC의 머신 1,7에서 LDAP를 업데이트합니다.

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

DC-1에서 트래픽을 차단하고 모든 트래픽이 다른 DC-2로 다시 라우팅되는지 확인합니다.
DC-1의 머신 1,2,3에서 Cassandra를 업데이트합니다.
```
/opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
```
DC-1의 머신 1에서 관리 서버를 업데이트합니다.
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
DC-1의 머신 2, 3에서 라우터,메시지 프로세서를 업데이트합니다.
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
DC-1에서 트래픽을 차단 해제하고 DC-1을 확인한 후 DC-2에서 트래픽을 차단하고 트래픽을 DC-1로 다시 라우팅하여 DC-2를 진행합니다.
DC-2의 머신 7,8,9에서 Cassandra를 업데이트합니다.
```
/opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
```
DC-2의 머신 7에서 관리 서버를 업데이트합니다.
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
DC-2의 머신 8, 9에서 라우터,메시지 프로세서를 업데이트합니다.
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
DC-2에서 트래픽을 차단 해제하면 이제 두 데이터 센터에서 모두 트래픽을 처리합니다.
머신 1 및 7의 모든 DC의 모든 관리 서버에서 update 명령어를 다시 실행합니다.
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
두 데이터 센터의 머신 4,5,6,10,11,12에서 edge-qpid-server 및 edge-postgres-server를 업데이트합니다.
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
두 DC의 머신 4,5,10,11에서 Qpid를 업데이트합니다.
```
/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
```
두 데이터 센터에서 새 UI (ue) 또는 기존 UI (ui)를 업데이트합니다.
```
/opt/apigee/apigee-setup/bin/update.sh -c  [ui|ue] -f configFile
```
(apigee-adminapi를 설치한 경우) 두 DC에서 apigee-adminapi를 업데이트합니다.
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```
(Apigee SSO를 설치한 경우) 두 데이터 센터의 Apigee SSO 노드를 업데이트합니다.
```
/opt/apigee/apigee-setup/bin/update.sh -c sso -f configFile
```
두 데이터 센터에서 새 Edge UI (edge-management-ui) 또는 기존 Edge UI (edge-ui) 구성요소를 다시 시작합니다.
```
/opt/apigee/apigee-service/bin/apigee-service [edge-ui|edge-management-ui] restart
```