Apigee는 프라이빗 클라우드용 Edge를 버전 4.52.02에서 버전 4.53.00으로 직접 업그레이드하는 기능을 지원합니다. 이 페이지에서는 이러한 업그레이드를 실행하는 방법을 설명합니다.
호환되는 업그레이드 경로에 관한 개요는 비공개 클라우드용 Edge 출시의 업그레이드 호환성 매트릭스를 참고하세요.
업데이트를 실행할 수 있는 사용자
업데이트를 실행하는 사용자는 Edge를 처음 설치한 사용자 또는 root로 실행하는 사용자와 동일해야 합니다.
Edge RPM을 설치한 후에는 누구나 구성할 수 있습니다.
업데이트해야 하는 구성요소
모든 Edge 구성요소를 업데이트해야 합니다. Edge는 여러 버전의 구성요소가 포함된 설정을 지원하지 않습니다.
기본 요건 업데이트
Apigee Edge를 업그레이드하기 전에 다음 기본 요건을 충족해야 합니다.
- 모든 노드 백업
업데이트하기 전에 안전을 위해 모든 노드를 완전히 백업하는 것이 좋습니다. 현재 버전의 Edge에 해당하는 절차에 따라 백업을 실행합니다.이렇게 하면 새 버전으로 업데이트가 제대로 작동하지 않을 경우를 대비한 백업 계획을 세울 수 있습니다. 백업에 관한 자세한 내용은 백업 및 복원을 참고하세요.
- Edge가 실행 중인지 확인
다음 명령어를 사용하여 업데이트 프로세스 중에 Edge가 실행 중인지 확인합니다./opt/apigee/apigee-service/bin/apigee-all status
- Cassandra 기본 요건 확인
이전에 Private Cloud용 Edge의 이전 버전에서 버전 4.52.02로 업그레이드한 후 이제 버전 4.53.00으로 업그레이드하려는 경우 Cassandra의 필수 업그레이드 후 단계를 완료했는지 확인하세요. 이 단계는 버전 4.52.02 업그레이드 문서의 업그레이드 후 단계에 설명되어 있습니다. 이전 업그레이드 중에 이 단계가 완료되었는지 확실하지 않은 경우 버전 4.53.00으로 업그레이드하기 전에 다시 완료하세요. - Python 요구사항
업그레이드를 시도하기 전에 Cassandra 노드를 포함한 모든 노드에 Python 3이 설치되어 있는지 확인합니다.
숙박 시설 설정 자동 전파
/opt/apigee/customer/application
에서 .properties
파일을 수정하여 속성을 설정한 경우 이러한 값은 업데이트 시 유지됩니다.
Cassandra 4.0.13으로 업그레이드 필요
프라이빗 클라우드용 Apigee Edge 4.53.00에는 Cassandra를 버전 4.0.13으로 업그레이드하는 기능이 포함되어 있습니다.
업그레이드 및 롤백
- Cassandra 3.11.X에서 Cassandra 4.0.X로 업그레이드하는 과정은 원활합니다. 프라이빗 클라우드용 Edge 4.53.00과 함께 출시된 Cassandra 4.0.X는 프라이빗 클라우드 4.52.02의 런타임 및 관리 구성요소와 호환됩니다.
- Cassandra 4.0.X에서 3.11.X로 직접 인플레이스 롤백은 불가능합니다. 복제본 또는 백업을 사용하여 롤백하는 것은 복잡한 절차이며 다운타임 또는 데이터 손실이 발생할 수 있습니다. 문제를 해결하고 Cassandra 4.0.X로 업그레이드하는 것이 롤백하는 것보다 좋습니다.
- 업그레이드를 시도하기 전에 롤백 절차를 숙지하는 것이 중요합니다. 적절한 롤백 경로를 사용할 수 있도록 하려면 업그레이드 중에 롤백의 미묘한 차이를 고려하는 것이 중요합니다.
단일 데이터 센터
단일 데이터 센터 내에서 Cassandra를 3.11.X에서 4.0.X로 업그레이드하는 것은 원활하지만 롤백은 복잡하며 다운타임 및 데이터 손실이 발생할 수 있습니다. 프로덕션 워크로드의 경우 업그레이드를 시작하기 전에 새 데이터 센터에서 사용할 수 있는 Cassandra 노드가 하나 이상 있는 새 데이터 센터를 추가하는 것이 좋습니다. 이렇게 하면 데이터 손실이나 API 트래픽 중단 없이 Cassandra를 롤백할 수 있습니다. 이 추가 데이터 센터는 업그레이드가 완료되거나 체크포인트 2에 도달하면 지원 중단할 수 있습니다.
새 데이터 센터를 추가할 수 없지만 롤백 기능이 필요한 경우 Cassandra 3.11.X를 복원하려면 백업이 필요합니다. 그러나 이 방법을 사용하면 다운타임과 데이터 손실이 모두 발생할 수 있습니다.
여러 데이터 센터
Private Cloud용 Edge 4.52.02로 여러 데이터 센터를 운영하면 Private Cloud용 Edge 4.53.00으로 업그레이드하는 동안 롤백을 더 유연하게 처리할 수 있습니다.
- 롤백은 이전 Cassandra 버전 (3.11.X)을 실행하는 데이터 센터가 하나 이상 있는지에 따라 달라집니다.
- 전체 Cassandra 클러스터가 4.0.X로 업그레이드된 경우 Cassandra 3.11.X로 롤백해서는 안 됩니다. 프라이빗 클라우드 4.53.00 또는 4.52.02의 다른 구성요소와 함께 최신 Cassandra 버전을 계속 사용해야 합니다.
권장 업그레이드 방법론
- 한 번에 하나의 Cassandra 데이터 센터 업그레이드: 단일 데이터 센터 내에서 Cassandra 노드를 개별적으로 업그레이드하는 것으로 시작합니다. 다음 데이터 센터로 진행하기 전에 한 데이터 센터의 모든 Cassandra 노드 업그레이드를 완료합니다.
- 일시중지 및 확인: 데이터 센터 하나를 업그레이드한 후 일시중지하여 비공개 클라우드 클러스터, 특히 업그레이드된 데이터 센터가 제대로 작동하는지 확인합니다.
- 참고: 이전 버전을 계속 실행하는 데이터 센터가 하나 이상 있는 경우에만 이전 Cassandra 버전으로 롤백할 수 있습니다.
- 시간에 민감함: 기능을 검증하기 위해 잠시 (몇 시간 권장) 일시중지할 수는 있지만 혼합 버전 상태로 무기한 유지할 수는 없습니다. 이는 버전이 다른 노드가 있는 비균일 Cassandra 클러스터에는 운영상의 제한사항이 있기 때문입니다.
- 철저한 테스트: Apigee에서는 다음 데이터 센터를 업그레이드하기 전에 성능과 기능을 포괄적으로 테스트할 것을 적극 권장합니다. 모든 데이터 센터가 업그레이드되면 이전 버전으로 롤백할 수 없습니다.
두 체크포인트 프로세스로 롤백
- 체크포인트 1: 모든 구성요소가 버전 4.52.02인 초기 상태입니다. 하나 이상의 Cassandra 데이터 센터가 이전 버전으로 유지되는 한 전체 롤백이 가능합니다.
- 체크포인트 2: 모든 데이터 센터의 모든 Cassandra 노드가 업데이트된 후 이 상태로 롤백할 수는 있지만 체크포인트 1로 되돌릴 수는 없습니다.
예
데이터 센터 (DC) 클러스터가 2개인 경우를 생각해 보겠습니다.
- 시작 상태: 두 데이터 센터의 Cassandra 노드가 모두 버전 3.11.X를 사용합니다. 다른 모든 노드는 Edge for Private Cloud 버전 4.52.02를 사용합니다. DC당 Cassandra 노드가 3개 있다고 가정합니다.
- DC-1 업그레이드: DC-1의 Cassandra 노드 3개를 하나씩 업그레이드합니다.
- 일시중지 및 유효성 검사: 일시중지하여 클러스터(특히 DC-1)가 올바르게 작동하는지 확인합니다(성능, 기능 확인). DC-2의 Cassandra 노드를 사용하여 초기 상태로 롤백할 수 있습니다. 혼합 버전 Cassandra 클러스터의 제한으로 인해 일시적으로 일시중지해야 합니다.
- DC-2 업그레이드: DC-2의 나머지 세 개의 Cassandra 노드를 업그레이드합니다. 이 지점이 새 롤백 체크포인트가 됩니다.
- 기타 구성요소 업그레이드: 모든 데이터 센터에서 관리, 런타임, 분석 노드를 평소와 같이 한 번에 하나의 노드와 하나의 데이터 센터씩 업그레이드합니다. 문제가 발생하면 4단계의 상태로 롤백할 수 있습니다.
Cassandra 업그레이드의 기본 요건
Private Cloud용 Edge 4.52.02에서 Cassandra 3.11.16을 실행하고 다음을 확인해야 합니다.- 전체 클러스터가 Cassandra 3.11.16으로 작동하며 모든 기능을 사용할 수 있습니다.
- 압축 전략이
LeveledCompactionStrategy
로 설정됩니다 (버전 4.52.02로 업그레이드하기 위한 기본 요건). - 4.52.02 업그레이드의 일환으로 Cassandra 3.11.16으로의 초기 업그레이드부터의 모든 업그레이드 후 단계가 완료되었습니다. 그렇지 않으면 이 단계를 다시 실행합니다. 이전 버전에서 비공개 클라우드 버전 4.52.02로 업그레이드한 경우에만 적용됩니다.
1단계: 업그레이드 준비
아래 단계는 구성요소 업그레이드를 사용 설정하기 위한 Apigee의 표준 구성 파일과 같이 일반적으로 만드는 표준 파일 외에 추가로 수행해야 하는 단계입니다.
- Apigee를 사용하여 Cassandra를 백업합니다.
- Cassandra 노드의 VM 스냅샷을 찍습니다 (가능하면).
- 아직 구성되지 않은 경우 관리 서버, 메시지 프로세서, 라우터, Qpid, Postgres를 비롯한 모든 Edge for Private Cloud 구성요소에서 Cassandra 노드에 포트 9042에 액세스할 수 있는지 확인합니다. 자세한 내용은 포트 요구사항을 참고하세요.
2단계: 모든 Cassandra 노드 업그레이드
모든 Cassandra 노드는 각 데이터 센터에서 한 번에 하나씩 업데이트해야 합니다. 데이터 센터 내에서 노드를 업그레이드할 때는 업데이트된 노드가 완전히 시작되고 클러스터에 참여했는지 확인하기 위해 몇 분 정도 기다린 후 같은 데이터 센터의 다른 노드 업그레이드를 진행합니다.
데이터 센터 내의 모든 Cassandra 노드를 업그레이드한 후 다음 데이터 센터의 노드를 진행하기 전에 30분에서 몇 시간 정도 기다립니다. 이 기간 동안 업데이트된 데이터 센터를 철저히 검토하고 Apigee 클러스터의 기능 및 성능 측정항목이 손상되지 않았는지 확인합니다. 이 단계는 Cassandra가 버전 4.0.X로 업그레이드되었지만 나머지 Apigee 구성요소는 버전 4.52.02로 유지되는 데이터 센터의 안정성을 보장하는 데 중요합니다.
-
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.0.0 | Cassandra 4.0.13 | CQL spec 3.4.5 | Native protocol v5] Metadata is verified
3단계: 모든 관리 노드 업그레이드
모든 리전의 모든 관리 노드를 하나씩 업그레이드합니다.
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
4단계: 모든 런타임 노드 업그레이드
모든 리전의 모든 라우터 및 메시지 프로세서 노드를 하나씩 업그레이드합니다.
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
5단계: 나머지 모든 Private Cloud용 Edge 4.53.00 구성요소 업그레이드
모든 리전의 나머지 edge-qpid-server
및 edge-postgres-server
노드를 하나씩 업그레이드합니다.
6단계: 업그레이드 후 단계
업그레이드가 완료된 후 각 Cassandra 노드에서 다음 명령어를 하나씩 실행합니다.
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra post_upgrade
새 Edge UI
이 섹션에는 Edge UI와 관련된 고려사항이 나열되어 있습니다. 자세한 내용은 프라이빗 클라우드용 새 Edge UI를 참고하세요.
Edge UI 설치
초기 설치를 완료한 후에는 Apigee Edge for Private Cloud의 개발자 및 관리자를 위한 향상된 사용자 인터페이스인 Edge UI를 설치하는 것이 좋습니다.
Edge UI를 사용하려면 기본 인증을 사용 중지하고 SAML 또는 LDAP와 같은 IDP를 사용해야 합니다.
자세한 내용은 새 Edge UI 설치를 참고하세요.
Apigee mTLS로 업데이트
Apigee mTLS를 업데이트하려면 다음 단계를 따르세요.
- Apigee mTLS를 제거합니다.
- Apigee mTLS를 다시 설치합니다.
업데이트 롤백
업데이트에 실패한 경우 문제를 해결한 후 update.sh
를 다시 실행할 수 있습니다. 업데이트를 여러 번 실행할 수 있으며, 업데이트는 마지막으로 중단된 지점부터 계속 진행됩니다.
업데이트를 이전 버전으로 롤백해야 하는 경우 자세한 안내는 4.53.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단계를 반복합니다.
- 설치의 나머지 머신에 대한 업데이트를 계속합니다.
업데이트 전후에 다음 사항에 유의하세요.
- 결합된 라우터 및 메시지 프로세서 노드:
- 업데이트 전 – 다음을 실행합니다.
- 라우터에 연결할 수 없도록 합니다.
- 메시지 프로세서에 연결할 수 없도록 합니다.
- 업데이트 후 – 다음을 실행합니다.
- 메시지 프로세서에 연결할 수 있도록 합니다.
- 라우터에 연결할 수 있도록 합니다.
- 업데이트 전 – 다음을 실행합니다.
- 단일 라우터 노드:
- 업데이트하기 전에 라우터에 연결할 수 없도록 합니다.
- 업데이트 후 라우터에 연결할 수 있도록 합니다.
- 단일 메시지 프로세서 노드에서 다음을 실행합니다.
- 업데이트하기 전에 메시지 프로세서에 연결할 수 없도록 합니다.
- 업데이트 후 메시지 프로세서에 연결할 수 있도록 합니다.
무음 구성 파일 사용
업데이트 명령어에 무음 구성 파일을 전달해야 합니다. 무음 구성 파일은 프라이빗 클라우드용 Edge 4.52.02를 설치하는 데 사용한 파일과 동일해야 합니다.
외부 인터넷에 연결된 노드에서 4.53.00으로 업데이트
노드에서 Edge 구성요소를 업데이트하려면 다음 절차를 따르세요.
- 있는 경우 업데이트가 완료될 때까지 Cassandra에서 수리 작업을 실행하도록 구성된
cron
작업을 사용 중지합니다. - 루트로 노드에 로그인하여 Edge RPM을 설치합니다.
- Edge apigee-setup 유틸리티 설치에 설명된 대로 SELinux를 사용 중지합니다.
- 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
나중에 업데이트를 롤백하려면 4.53.00 롤백에 설명된 절차를 따르세요.
로컬 저장소에서 4.53.00으로 업데이트
Edge 노드가 방화벽 뒤에 있거나 다른 방식으로 인터넷을 통해 Apigee 저장소에 액세스할 수 없는 경우 Apigee 저장소의 로컬 저장소 또는 미러에서 업데이트를 실행할 수 있습니다.
로컬 Edge 저장소를 만든 후 로컬 저장소에서 Edge를 업데이트하는 방법에는 두 가지가 있습니다.
- 저장소의 .tar 파일을 만들고 .tar 파일을 노드에 복사한 다음 .tar 파일에서 Edge를 업데이트합니다.
- 다른 노드에서 액세스할 수 있도록 로컬 저장소가 있는 노드에 웹서버를 설치합니다. Apigee에서는 사용할 수 있는 Nginx 웹 서버를 제공하거나 자체 웹 서버를 사용할 수 있습니다.
로컬 4.53.00 저장소에서 업데이트하려면 다음 단계를 따르세요.
- Edge apigee-setup 유틸리티 설치의 '로컬 Apigee 저장소 만들기'에 설명된 대로 로컬 4.53.00 저장소를 만듭니다.
- .tar 파일에서 apigee-service를 설치하려면 다음 단계를 따르세요.
- 로컬 저장소가 있는 노드에서 다음 명령어를 사용하여 로컬 저장소를
/opt/apigee/data/apigee-mirror/apigee-4.53.00.tar.gz
라는 단일 .tar 파일로 패키징합니다./opt/apigee/apigee-service/bin/apigee-service apigee-mirror package
- .tar 파일을 Edge를 업데이트할 노드에 복사합니다. 예를 들어 새 노드의
/tmp
디렉터리에 복사합니다. - 새 노드에서 파일의 압축을 풀어
/tmp
디렉터리에 배치합니다.tar -xzf apigee-4.53.00.tar.gz
이 명령어는 .tar 파일이 포함된 디렉터리에
repos
라는 새 디렉터리를 만듭니다. 예:/tmp/repos
/tmp/repos
에서 Edgeapigee-service
유틸리티 및 종속 항목을 설치합니다.sudo bash /tmp/repos/bootstrap_4.53.00.sh apigeeprotocol="file://" apigeerepobasepath=/tmp/repos
이 명령어에는 저장소 디렉터리의 경로가 포함됩니다.
- 로컬 저장소가 있는 노드에서 다음 명령어를 사용하여 로컬 저장소를
- Nginx 웹서버를 사용하여 apigee-service를 설치하려면 다음 단계를 따르세요.
- Edge apigee-setup 유틸리티 설치의 'Nginx 웹 서버를 사용하여 저장소에서 설치'에 설명된 대로 Nginx 웹 서버를 구성합니다.
- 원격 노드에서 Edge
bootstrap_4.53.00.sh
파일을/tmp/bootstrap_4.53.00.sh
로 다운로드합니다./usr/bin/curl http://uName:pWord@remoteRepo:3939/bootstrap_4.53.00.sh -o /tmp/bootstrap_4.53.00.sh
여기서 uName:pWord는 이전에 저장소에 설정한 사용자 이름과 비밀번호이고 remoteRepo는 저장소 노드의 IP 주소 또는 DNS 이름입니다.
- 원격 노드에서 Edge
apigee-setup
유틸리티와 종속 항목을 설치합니다.sudo bash /tmp/bootstrap_4.53.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 구성요소입니다. 일반적으로 다음 구성요소를 업데이트합니다.
cs
: Cassandraedge
: Edge UI를 제외한 모든 Edge 구성요소: 관리 서버, 메시지 프로세서, 라우터, QPID 서버, Postgres 서버ldap
: OpenLDAPps
: postgresqlqpid
: qpiddsso
: Apigee SSO (SSO를 설치한 경우)ue
새 Edge UIui
: 기존 Edge UIzk
: 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 /tmp/sa_silent_config
- component는 업데이트할 Edge 구성요소입니다. 일반적으로 다음 구성요소를 업데이트합니다.
- 아직 UI 구성요소를 실행하는 모든 노드에서 UI 구성요소를 다시 시작합니다.
/opt/apigee/apigee-service/bin/apigee-service [edge-management-ui|edge-ui] restart
- 설치 테스트에 설명된 대로 관리 서버에서
apigee-validate
유틸리티를 실행하여 업데이트를 테스트합니다.
나중에 업데이트를 롤백하려면 4.53.00 롤백에 설명된 절차를 따르세요.
기계 업데이트 순서
Edge 설치에서 머신을 업데이트하는 순서는 중요합니다.
- 다른 노드를 업데이트하기 전에 Cassandra 및 ZooKeeper 노드를 모두 업데이트해야 합니다.
- Edge 구성요소(관리 서버, 메시지 프로세서, 라우터, QPID 서버(Postgres 서버 제외))가 여러 개인 머신의 경우
-c edge
옵션을 사용하여 모두 동시에 업데이트합니다. - 단계에서 여러 머신에서 실행해야 한다고 지정된 경우 지정된 머신 순서대로 실행합니다.
- 수익 창출을 업데이트하는 별도의 단계는 없습니다.
-c edge
옵션을 지정하면 업데이트됩니다.
1노드 독립형 업그레이드
1노드 독립형 구성을 4.53.00으로 업그레이드하는 방법:
- 모든 구성요소 업데이트:
/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에서 Cassandra 및 ZooKeeper를 업데이트합니다.
/opt/apigee/apigee-setup/bin/update.sh -c cs,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
- 머신 2 및 1에서 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에서 Cassandra 및 ZooKeeper를 업데이트합니다.
/opt/apigee/apigee-setup/bin/update.sh -c cs,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
- 머신 4, 5, 1, 2, 3에서 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
- 기존 UI: 기존 UI를 사용하는 경우 다음 예와 같이 머신 1에서
- (
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
- 기존 UI: 기존 UI를 사용하는 경우 다음 예와 같이 머신 1에서
9노드 클러스터 업그레이드
9노드 클러스터 설치의 경우 다음 구성요소를 업데이트합니다.
에지 토폴로지 및 노드 번호 목록은 설치 토폴로지를 참고하세요.
- 머신 1, 2, 3에서 Cassandra 및 ZooKeeper를 업데이트합니다.
/opt/apigee/apigee-setup/bin/update.sh -c cs,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
- 머신 6, 7, 8, 9, 1, 4, 5에서 차례로 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
- 기존 UI: 기존 UI를 사용하는 경우 다음 예와 같이 머신 1에서
13노드 클러스터 업그레이드
13노드 클러스터 설치의 경우 다음 구성요소를 업데이트합니다.
에지 토폴로지 및 노드 번호 목록은 설치 토폴로지를 참고하세요.
- 머신 1, 2, 3에서 Cassandra 및 ZooKeeper를 업데이트합니다.
/opt/apigee/apigee-setup/bin/update.sh -c cs,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
- 머신 12, 13, 8, 9, 6, 7, 10, 11에서 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
- 기존 UI: 기존 UI를 사용하는 경우 다음 예와 같이 머신 6 및 7에서
12노드 클러스터 업그레이드
12노드 클러스터 설치의 경우 다음 구성요소를 업데이트합니다.
에지 토폴로지 및 노드 번호 목록은 설치 토폴로지를 참고하세요.
- Cassandra 및 ZooKeeper를 업데이트합니다.
- 데이터 센터 1의 머신 1, 2, 3에서 다음을 실행합니다.
/opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
- 데이터 센터 2의 머신 7, 8, 9
/opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
- 데이터 센터 1의 머신 1, 2, 3에서 다음을 실행합니다.
- 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
- 데이터 센터 1의 머신 6
- 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
- 데이터 센터 1의 머신 1
- Edge 구성요소를 업데이트합니다.
- 데이터 센터 1의 머신 4, 5, 6, 1, 2, 3
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
- 데이터 센터 2의 머신 10, 11, 12, 7, 8, 9
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
- 데이터 센터 1의 머신 4, 5, 6, 1, 2, 3
- qpidd를 업데이트합니다.
- 데이터 센터 1의 머신 4, 5
- 머신 4에서
qpidd
를 업데이트합니다./opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
- 머신 5에서
qpidd
를 업데이트합니다./opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
- 머신 4에서
- 데이터 센터 2의 머신 10, 11
- 머신 10에서
qpidd
를 업데이트합니다./opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
- 머신 11에서
qpidd
를 업데이트합니다./opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
- 머신 10에서
- 데이터 센터 1의 머신 4, 5
- 새 UI (
ue
) 또는 기존 UI (ui
)를 업데이트합니다.- 데이터 센터 1의 머신 1:
/opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile
- 데이터 센터 2의 머신 7:
/opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile
- 데이터 센터 1의 머신 1:
- (
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
- 데이터 센터 1의 머신 1:
- (Apigee SSO를 설치한 경우) Apigee SSO를 업데이트합니다.
- 데이터 센터 1의 머신 1:
/opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file
- 데이터 센터 2의 머신 7:
/opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file
여기서 sso_config_file은 SSO를 설치할 때 만든 구성 파일입니다.
- 데이터 센터 1의 머신 1:
- 머신 1 및 7에서 새 Edge UI (
edge-management-ui
) 또는 기존 Edge UI(edge-ui
) 구성요소를 다시 시작합니다./opt/apigee/apigee-service/bin/apigee-service [edge-ui|edge-management-ui] restart
비표준 구성
비표준 구성인 경우 다음 순서대로 Edge 구성요소를 업데이트합니다.
- ZooKeeper
- Cassandra
- ps
- LDAP
- Edge: Qpid 서버가 있는 노드, Edge Postgres 서버, 관리 서버, 메시지 프로세서, 라우터 순으로 모든 노드의 '-c edge' 프로필을 의미합니다.
- qpidd
- Edge UI (기존 또는 신규)
apigee-adminapi
- Apigee SSO
업데이트를 완료한 후 Edge UI 구성요소를 실행하는 모든 머신에서 Edge UI 구성요소를 다시 시작해야 합니다.