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

Apigee는 버전 4.52.02 또는 4.53.00에서 버전 4.53.01로 직접 Edge for Private Cloud를 업그레이드하는 것을 지원합니다. 이 페이지에서는 이러한 업그레이드를 실행하는 방법을 설명합니다.

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

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

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

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

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

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

기본 요건 업데이트

Edge for Private Cloud 4.53.01의 변경사항 검토

이 버전에서는 여러 보안 문제가 해결되었습니다. 이러한 보안 개선사항은 필수적이지만 이전 버전과 호환되지 않는 변경사항이 도입됩니다. 즉, 업그레이드 중이나 업그레이드 후에 중단이 발생하지 않도록 하려면 추가 단계가 필요합니다. 이전 비공개 클라우드 버전에서 버전 4.53.01로 업그레이드하는 동안 이 주제를 자세히 검토하세요.

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

  • 모든 노드 백업
    업데이트하기 전에 안전을 위해 모든 노드를 완전히 백업하는 것이 좋습니다. 현재 버전의 Edge에 해당하는 절차를 사용하여 백업을 실행합니다.

    이렇게 하면 새 버전으로의 업데이트가 제대로 작동하지 않는 경우를 대비해 백업 계획을 세울 수 있습니다. 백업에 관한 자세한 내용은 백업 및 복원을 참고하세요.

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

    이전에 Edge for Private Cloud의 이전 버전에서 버전 4.52.02로 업그레이드했으며 이제 버전 4.53.01로 업그레이드하려는 경우 Cassandra에 필요한 업그레이드 후 단계를 완료했는지 확인하세요. 이 단계는 버전 4.52.02 업그레이드 문서에 설명되어 있으며 Cassandra 업그레이드 필수사항에도 언급되어 있습니다. 이전 업그레이드 중에 이 단계를 완료했는지 확실하지 않은 경우 버전 4.53.01로 업그레이드하기 전에 다시 완료하세요.

  • Edge for Private Cloud 4.53.01에서 IDP 키 및 인증서 구성

    프라이빗 클라우드용 Edge 4.53.01에서는 이제 apigee-sso 구성요소에 사용되는 IDP 키와 인증서가 키 저장소를 통해 구성됩니다. 이전에 사용한 키와 인증서를 키 저장소로 내보내야 합니다. SSO 구성요소를 업데이트하기 전에 이전 버전에서 Apigee SSO 업데이트 단계 섹션의 단계를 따르세요.

  • Python 요구사항
    업그레이드를 시도하기 전에 Cassandra 노드를 포함한 모든 노드에 Python 3이 설치되어 있는지 확인합니다.

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

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

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

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

속성 설정 자동 전파

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

OpenLDAP 2.6으로 업그레이드 필요

다음은 Apigee Edge for Private Cloud의 기본 LDAP 서비스를 기존 OpenLDAP 2.4에서 OpenLDAP 2.6으로 업그레이드하는 단계별 절차입니다. 이 업그레이드는 Private Cloud용 Apigee Edge 버전 4.53.01 이상으로 업데이트하는 데 필수입니다. 이 업그레이드는 단일 서버, 활성-수동, 활성-활성 (다중 마스터) 등 모든 Apigee LDAP 배포 토폴로지에 적용됩니다.

기본 요건 및 고려사항

  • LDAP 업그레이드 프로세스 중에 관리 API와 결과적으로 Apigee UI를 모든 리전에서 완전히 사용할 수 없게 됩니다. 사용자, 역할, 앱, 조직 관리와 같은 모든 관리 작업이 실패하며 일시중지해야 합니다. API 프록시 트래픽 처리에 미치는 영향은 없습니다. LDAP 업그레이드를 진행하기 전에 모든 edge-management-server와 edge-ui를 종료해야 합니다.

  • 백업은 필수: 기존 LDAP 데이터의 완전하고 검증된 백업은 필수입니다. 유효한 백업 없이 진행하면 되돌릴 수 없는 데이터 손실이 발생합니다. LDAP 데이터의 일관된 특정 시점 스냅샷을 캡처하려면 LDAP 서비스가 실행 중인 동안 백업을 시작해야 합니다. 실제 업그레이드를 실행하려면 백업이 필요합니다. 백업이 없으면 업그레이드를 실행할 수도 롤백할 수도 없습니다. 업그레이드 단계에 LDAP 데이터 삭제가 포함되기 때문입니다.

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

이 섹션의 단계 (2단계~5단계)는 모든 LDAP 배포 토폴로지에서 동일합니다. 이러한 작업은 역할과 관계없이 apigee-openldap 구성요소가 설치된 모든 서버에서 실행해야 합니다.

  1. LDAP 업그레이드를 계속 진행하기 전에 모든 edge-management-server와 edge-ui를 종료해야 합니다. 
    apigee-service edge-management-server stop
apigee-service edge-ui stop

  2. 기존 LDAP 데이터 백업

    변경하기 전에 모든 LDAP 서버에서 현재 LDAP 데이터를 전체 백업합니다. 이렇게 하면 안전한 복원 지점이 생성됩니다.

    • 백업 명령어를 실행합니다. 이 작업은 /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

  3. LDAP 중지 및 데이터 디렉터리 정리하기

    이 단계는 모든 LDAP 서버에서 수행해야 합니다. 주 버전 변경과 기본 구조 차이로 인해 필수입니다. 깨끗한 디렉터리는 충돌이 없음을 보장합니다. 모든 LDAP 서버가 중지되면 관리 API 및 UI가 중단됩니다.

    • LDAP 서비스를 중지합니다. 
      apigee-service apigee-openldap stop
    • 이전 LDAP 데이터 및 구성 디렉터리를 영구적으로 삭제합니다. 
      rm -rf /opt/apigee/data/apigee-openldap/*

  4. 새 LDAP 버전 설치 및 구성

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

    • 새 LDAP 구성요소 설치: 업데이트 스크립트가 구성 파일을 읽고 새 apigee-openldap 패키지를 설치합니다. 
      /opt/apigee/apigee-setup/bin/update.sh -c ldap -f /opt/silent.conf
    • 새 LDAP 버전 확인: 설치가 완료된 후 프로필을 새로고침하고 새 LDAP 버전이 올바르게 설치되었는지 확인합니다. 
      source ~/.bash_profile
ldapsearch -VV
Expected output:
ldapsearch: @(#) $OpenLDAP: ldapsearch 2.6.7

  5. 데이터 복원 전에 모든 서버에서 LDAP 중지

    이 단계는 중요한 동기화 단계입니다. 백업을 복원하기 전에 새로 설치된 LDAP 서비스가 모든 서버에서 중지되어 있는지 확인해야 합니다. 모든 LDAP 서버에서 다음 명령어를 실행합니다. 

    apigee-service apigee-openldap stop
rm -rf /opt/apigee/data/apigee-openldap/ldap/*

  6. LDAP 데이터 복원하기

    전략은 첫 번째 활성 서버에서 백업을 복원하는 것입니다. 그러면 이 서버가 정보 소스 역할을 하여 멀티 서버 설정에서 데이터를 피어에 복제합니다.

    1. 복원할 첫 번째 활성 서버 식별

      • 단일 서버 설정: LDAP 서버가 하나만 있습니다. 다음 단계로 바로 진행할 수 있습니다.
      • 활성-대기 및 활성-활성 설정의 경우: 각 LDAP 서버에서 다음 진단 명령어를 실행합니다. 
        grep -i '^olcSyncrepl:' /opt/apigee/data/apigee-openldap/slapd.d/cn=config/olcDatabase*\ldif
Note:
-If this command returns output, the server is a passive server.
-If it returns no output, the server is the active server.

    2. 백업 데이터 복원

      계속하기 전에 모든 LDAP 서버에서 5단계가 성공적으로 완료되었는지 다시 한번 확인합니다.

      • 위에서 식별한 첫 번째 활성 서버에서 백업 디렉터리로 이동합니다. 
        cd /opt/apigee/backup/openldap
      • restore 명령어를 실행합니다. 의도하지 않은 버전이나 이전 버전이 복원되지 않도록 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

  7. 나머지 LDAP 서버 시작하기

    다중 서버 설정이 있는 경우 각 LDAP 서버에서 서비스를 시작합니다. 

    apigee-service apigee-openldap start

  8. 최종 유효성 검사

    마지막 단계는 업그레이드가 성공했는지, 데이터가 전체 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와 기타 종속 구성요소를 시작할 수 있습니다.

Cassandra 4.0.18로 업그레이드해야 함

Apigee Edge for Private Cloud 4.53.01에는 Cassandra가 버전 4.0.18로 업그레이드됩니다.

업그레이드 및 롤백

  • 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를 복원하려면 백업이 필요합니다. 하지만 이 방법을 사용하면 다운타임과 데이터 손실이 발생할 수 있습니다.

여러 데이터 센터

Edge for Private Cloud 4.52.02로 여러 데이터 센터를 운영하면 Edge for Private Cloud 4.53.00으로 업그레이드하는 동안 롤백을 더 유연하게 수행할 수 있습니다.

  • 롤백은 이전 Cassandra 버전 (3.11.X)을 실행하는 데이터 센터가 하나 이상 있어야 가능합니다.
  • 전체 Cassandra 클러스터가 4.0.X로 업그레이드된 경우 Cassandra 3.11.X로 롤백하면 안 됩니다. Private Cloud 4.53.00 또는 4.52.02의 다른 구성요소와 함께 최신 Cassandra 버전을 계속 사용해야 합니다.
  1. 한 번에 하나의 Cassandra 데이터 센터 업그레이드: 단일 데이터 센터 내에서 Cassandra 노드를 개별적으로 업그레이드하는 것부터 시작합니다. 다음 데이터 센터로 진행하기 전에 한 데이터 센터의 모든 Cassandra 노드의 업그레이드를 완료합니다.
  2. 일시중지 및 검증: 데이터 센터 하나를 업그레이드한 후 일시중지하여 Private Cloud 클러스터, 특히 업그레이드된 데이터 센터가 올바르게 작동하는지 확인합니다.
  3. 기억하세요: 이전 버전을 실행하는 데이터 센터가 하나 이상 있는 경우에만 이전 Cassandra 버전으로 롤백할 수 있습니다.
  4. 시간 제한: 기능을 검증하기 위해 잠시 (몇 시간 권장) 일시중지할 수는 있지만 혼합 버전 상태를 무기한 유지할 수는 없습니다. 이는 버전이 다른 노드가 있는 균일하지 않은 Cassandra 클러스터에는 운영상의 제한이 있기 때문입니다.
  5. 철저한 테스트: Apigee에서는 다음 데이터 센터를 업그레이드하기 전에 성능과 기능을 포괄적으로 테스트할 것을 적극 권장합니다. 모든 데이터 센터가 업그레이드되면 이전 버전으로 롤백할 수 없습니다.
2개의 체크포인트 프로세스로 롤백
  1. 검문소 1: 모든 구성요소가 버전 4.52.02인 초기 상태입니다. 하나 이상의 Cassandra 데이터 센터가 이전 버전에 남아 있는 한 전체 롤백이 가능합니다.
  2. 체크포인트 2: 모든 데이터 센터의 모든 Cassandra 노드가 업데이트된 후 이 상태로 롤백할 수는 있지만 체크포인트 1로 되돌릴 수는 없습니다.
예

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

  1. 시작 상태: 두 DC의 Cassandra 노드가 버전 3.11.X에 있습니다. 다른 모든 노드는 Edge for Private Cloud 버전 4.52.02에 있습니다. DC당 Cassandra 노드가 3개라고 가정합니다.
  2. DC-1 업그레이드: DC-1의 Cassandra 노드 3개를 하나씩 업그레이드합니다.
  3. 일시중지 및 검증: 클러스터, 특히 DC-1이 올바르게 작동하는지 확인하기 위해 일시중지합니다 (성능, 기능 확인). DC-2의 Cassandra 노드를 사용하여 초기 상태로 롤백할 수 있습니다. 혼합 버전 Cassandra 클러스터의 제한으로 인해 이 일시중지는 일시적이어야 합니다.
  4. DC-2 업그레이드: DC-2의 나머지 Cassandra 노드 3개를 업그레이드합니다. 이 시점이 새로운 롤백 체크포인트가 됩니다.
  5. 기타 구성요소 업그레이드: 모든 데이터 센터에서 관리, 런타임, 분석 노드를 한 번에 한 노드와 한 데이터 센터씩 평소와 같이 업그레이드합니다. 문제가 발생하면 4단계의 상태로 롤백할 수 있습니다.

Cassandra 업그레이드 필수사항

Edge for Private Cloud 4.52.02를 사용하여 Cassandra 3.11.16을 실행하고 다음을 확인해야 합니다.
  1. 전체 클러스터가 Cassandra 3.11.16으로 작동하며 모든 기능을 갖추고 있습니다.
  2. 압축 전략이 LeveledCompactionStrategy로 설정됩니다 (버전 4.52.02로 업그레이드하기 위한 필수 요건).

  3. 아래 각 단계가 Edge for Private Cloud 4.52.02의 Cassandra 3.11 초기 업그레이드의 일부로 완료되었는지 확인합니다.

    • 이전 업그레이드 중에 각 Cassandra 노드에서 post_upgrade 명령어가 실행되었습니다.
    • 이전 업그레이드 중에 전체 Cassandra 클러스터에서 drop_old_tables 명령어가 실행되었습니다.

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

1단계: 업그레이드 준비

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

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

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

모든 Cassandra 노드는 각 데이터 센터에서 한 번에 하나의 데이터 센터씩 순서대로 업데이트해야 합니다. 데이터 센터 내에서 노드를 업그레이드하는 경우 업데이트된 노드가 완전히 시작되고 클러스터에 참여할 때까지 몇 분 정도 기다린 후 동일한 데이터 센터에서 다른 노드 업그레이드를 진행합니다.

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

  1. Cassandra 노드를 업그레이드하려면 다음 명령어를 실행합니다. 
    /opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
  2. 노드가 업데이트되면 노드에서 다음 명령어를 실행하여 검증을 실행한 후 계속 진행합니다. 
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra validate_upgrade -f configFile
  3. 위의 명령어를 실행하면 다음과 같은 결과가 출력됩니다. 
    Cassandra version is verified - [cqlsh 6.0.0 | Cassandra 4.0.18 | CQL spec 3.4.5 | Native protocol v5] 
Metadata is verified
  4. Cassandra 노드에서 다음 post_upgrade 명령어를 실행합니다. 
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra post_upgrade
  5. 다음 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 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 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 cache cache_entries cache_entries_cache_name_idx
/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 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 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

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단계: 나머지 모든 Edge for Private Cloud 4.53.01 구성요소 업그레이드

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

Zookeeper 3.8.4로 업그레이드해야 함

이 Edge for Private Cloud 버전에는 Zookeeper 3.8.4로의 업그레이드가 포함되어 있습니다. 이 업그레이드의 일환으로 모든 Zookeeper 데이터가 Zookeeper 3.8.4로 이전됩니다.

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

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

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

백업하기

롤백이 필요한 경우에 사용할 수 있도록 ZooKeeper의 모든 노드를 백업합니다. 롤백하면 백업이 생성된 시점의 상태로 Zookeeper가 복원됩니다. 참고: 백업이 생성된 이후 Apigee에서 발생한 배포 또는 인프라 변경사항 (정보가 ZooKeeper에 저장됨)은 복원 중에 손실됩니다. 

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

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

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

참고: 아래 샘플 명령어는 nc 유틸리티를 사용하여 데이터를 ZooKeeper에 전송합니다. 대체 유틸리티를 사용하여 데이터를 ZooKeeper로 전송할 수도 있습니다.

  1. ZooKeeper 노드에 설치되어 있지 않으면 nc를 설치합니다. 
      sudo yum install nc
  2. 노드에서 다음 nc 명령어를 실행합니다. 여기서 2181은 ZooKeeper 포트입니다. 
      echo stat | nc localhost 2181

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

      Zookeeper version: 3.8.4-5a02a05eddb59aee6ac762f7ea82e92a68eb9c0f, built on 2022-02-25 08:49 UTC
  Clients:
   /0:0:0:0:0:0:0:1:41246[0](queued=0,recved=1,sent=0)
  
  Latency min/avg/max: 0/0.2518/41
  Received: 647228
  Sent: 647339
  Connections: 4
  Outstanding: 0
  Zxid: 0x400018b15
  Mode: follower
  Node count: 100597

    노드 출력의 Mode 줄에는 노드 구성에 따라 observer, leader 또는 follower (리더가 아닌 유권자)가 표시됩니다. 참고: 단일 ZooKeeper 노드를 사용하는 Edge의 독립형 설치에서 Mode은 독립형으로 설정됩니다.

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

관찰자 및 팔로어 노드에서 ZooKeeper 업그레이드

각 관찰자 및 팔로어 노드에서 다음과 같이 ZooKeeper를 업그레이드합니다.

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

리더 종료

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

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

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

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

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

최우수 대안 업그레이드

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

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

Edge-Router의 Nginx 1.26 업그레이드

이전 버전에서 Edge for Private Cloud 4.53.01로 업그레이드해도 Nginx 소프트웨어가 최신 버전 (1.26.x)으로 자동 업그레이드되지 않습니다. 이는 Apigee Edge 4.53.01의 Nginx 1.26 변경사항에 설명된 변경사항으로 인해 발생하는 우발적인 런타임 부작용을 방지하기 위한 것입니다. 하위 환경에서 확인한 후 Nginx를 1.20.x에서 1.26.x로 수동으로 업그레이드할 수 있습니다. 수동으로 업그레이드하려면 다음 단계를 따르세요.

  1. 에지 라우터 노드에 최신 4.53.01 소프트웨어가 있는지 확인

    /opt/apigee/apigee-service/bin/apigee-service edge-router version

  2. 현재 실행 중인 Nginx 버전을 확인합니다.

    /opt/nginx/sbin/nginx -V

    이전 버전의 Nginx를 운영하는 경우 아래 단계에 따라 라우터 노드에서 Nginx를 버전 1.26.X로 업그레이드할 수 있습니다.

  3. 라우터 노드에서 에지 라우터 프로세스 중지

    /opt/apigee/apigee-service/bin/apigee-service edge-router stop

  4. 라우터 노드에서 nginx 소프트웨어 업그레이드

    dnf update apigee-nginx

  5. Nginx 버전이 업데이트되었는지 확인

    /opt/nginx/sbin/nginx -V

  6. 노드에서 라우터 프로세스 시작

    /opt/apigee/apigee-service/bin/apigee-service edge-router start

  7. 각 라우터 노드에서 한 번에 하나씩 이 프로세스를 반복합니다.

Postgres 17로 업그레이드 필요

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

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

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

  • Postgres 노드에 로컬 데이터 스토리지를 사용하는 경우 업그레이드 기간 동안 새 Postgres 대기 노드를 설치해야 합니다. 업그레이드가 완료되면 새 Postgres 대기 노드를 폐기할 수 있습니다.

    어떤 이유로든 업데이트를 롤백해야 하는 경우 추가 Postgres 대기 노드가 필요합니다. 업데이트를 롤백해야 하는 경우 롤백 후 새 Postgres 대기 노드가 마스터 Postgres 노드가 됩니다. 따라서 새 Postgres 대기 노드를 설치할 때는 Edge 설치 요구사항에 정의된 대로 Postgres 서버의 모든 하드웨어 요구사항을 충족하는 노드에 설치해야 합니다.

    프로토타입 제작 및 테스트에 사용되는 토폴로지인 Edge의 1노드 및 2노드 구성에서는 단일 Postgres 노드만 있습니다. 새 Postgres 노드를 만들지 않고 이러한 Postgres 노드를 직접 업데이트할 수 있습니다.

  • Postgres 노드에 네트워크 스토리지를 사용하는 경우(Apigee 권장) 새 Postgres 노드를 설치하지 않아도 됩니다. 아래 절차에서는 새 Postgres 대기 노드를 설치하고 나중에 폐기하도록 지정하는 단계를 건너뛸 수 있습니다.

    업데이트 프로세스를 시작하기 전에 Postgres에서 사용하는 데이터 스토어의 네트워크 스냅샷을 만드세요. 그런 다음 업데이트 중에 오류가 발생하여 롤백을 강제로 실행해야 하는 경우 해당 스냅샷에서 Postgres 노드를 복원할 수 있습니다.

새 Postgres 대기 노드 설치

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

설치를 실행하려면 현재 버전의 Edge를 설치하는 데 사용한 것과 동일한 구성 파일을 사용하세요.

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

  1. 현재 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 주소입니다.

  2. Postgres 마스터에서 apigee-postgresql를 다시 시작합니다. 
    /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart
  3. 마스터에서 /opt/apigee/apigee-postgresql/conf/pg_hba.conf 파일을 확인하여 새 대기 노드가 추가되었는지 확인합니다. 해당 파일에 다음 줄이 표시됩니다. 
    host replication apigee existing_standby_ip/32 trust
host replication apigee new_standby_ip/32 trust
  4. 새 Postgres 대기 서버를 설치합니다.
    1. 현재 버전의 Edge를 설치하는 데 사용한 구성 파일을 수정하여 다음을 지정합니다. 
      # IP address of the current master:
PG_MASTER=192.168.56.103
# IP address of the new standby node
PG_STANDBY=192.168.56.102
    2. Edge apigee-setup 유틸리티 설치에 설명된 대로 SELinux를 사용 중지합니다.

    3. 현재 Edge 4.52.02를 사용 중인 경우:

      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.51.00.sh
      2. Edge apigee-service 유틸리티 및 종속 항목을 설치합니다. 
        sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord

      현재 Edge 4.53.00을 사용 중인 경우:

      1. 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
      2. Edge apigee-service 유틸리티 및 종속 항목을 설치합니다. 
        sudo bash /tmp/bootstrap_4.53.00.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의 인플레이스(In-Place) 업그레이드 수행

참고: Postgres의 인플레이스 업그레이드를 실행하기 전에 다음 예비 단계를 실행해야 합니다.

예비 단계

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

  1. 파일이 없으면 /opt/apigee/customer/application/postgresql.properties 파일을 만듭니다.
  2. 이 파일의 소유권을 apigee로 변경합니다. 
    sudo chown apigee:apigee /opt/apigee/customer/application/postgresql.properties
  3. 파일에 다음 속성을 추가합니다. 
    conf/postgresql.conf+max_locks_per_transaction=30000
  4. apigee-postgresql을 구성합니다. 
    apigee-service apigee-postgresql configure
  5. apigee-postgresql를 다시 시작합니다. 
    apigee-service apigee-postgresql restart

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

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

  1. 마스터 호스트에서 postgres 업그레이드 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f /opt/silent.conf
  2. 마스터 호스트에서 설정 명령어를 실행합니다. 
    apigee-service apigee-postgresql setup -f /opt/silent.conf
  3. 마스터 호스트에서 구성 명령어를 실행합니다. 
    apigee-service apigee-postgresql configure
  4. 마스터 호스트를 다시 시작합니다. 
    apigee-service apigee-postgresql restart
  5. 마스터로 구성합니다. 
    apigee-service apigee-postgresql setup-replication-on-master -f /opt/silent.conf
  6. 마스터 호스트가 시작되었는지 확인합니다. 
    apigee-service apigee-postgresql wait_for_ready
  7. 대기 모드를 중지합니다. 
    apigee-service apigee-postgresql stop
  8. 대기 업그레이드

    참고: 이 단계에서 오류가 발생하거나 실패하면 무시해도 됩니다. update.sh에서 잘못된 구성으로 대기 서버를 시작하려고 시도합니다. Postgres 설치가 17로 업그레이드된 경우 오류를 무시할 수 있습니다.

    /opt/apigee/apigee-setup/bin/update.sh -c ps -f /opt/silent.conf
  9. 대기 모드가 중지되었는지 확인합니다. 
    apigee-service apigee-postgresql stop
  10. 이전 대기 구성 삭제: 
    rm -rf /opt/apigee/data/apigee-postgresql/
  11. 대기 서버에서 복제를 설정합니다. 
    apigee-service apigee-postgresql setup-replication-on-standby -f /opt/silent.conf
  12. 마스터 호스트와 스탠바이 모두에서 /opt/apigee/customer/application/postgresql.properties 파일에서 conf/postgresql.conf+max_locks_per_transaction=30000 줄을 삭제합니다. 이 줄은 사전 단계에서 추가되었습니다.

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

Postgres 노드 폐기

업데이트가 완료되면 새 대기 노드를 서비스 해제합니다.

  1. Postgres가 실행 중인지 확인합니다. 
    /opt/apigee/apigee-service/bin/apigee-all status

    Postgres가 실행되고 있지 않으면 시작합니다. 

    /opt/apigee/apigee-service/bin/apigee-all start
  2. 새 대기 노드에서 다음 curl 명령어를 실행하여 새 대기 노드의 UUID를 가져옵니다. 
    curl -u sysAdminEmail:password http://node_IP:8084/v1/servers/self

    출력 끝에 다음과 같은 형식으로 노드의 UUID가 표시됩니다. 

    "type" : [ "postgres-server" ],
"uUID" : "599e8ebf-5d69-4ae4-aa71-154970a8ec75"
  3. 새 대기 노드에서 다음 명령어를 실행하여 새 대기 노드를 중지합니다. 
    /opt/apigee/apigee-service/bin/apigee-all stop
  4. 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
  5. Postgres 마스터에서 apigee-postgresql을 다시 시작합니다. 
    /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart
  6. 마스터에서 /opt/apigee/apigee-postgresql/conf/pg_hba.conf 파일을 확인하여 새 대기 모드 노드가 삭제되었는지 확인합니다. 해당 파일에는 다음 줄만 표시되어야 합니다. 
    host replication apigee existing_standby_ip/32 trust
  7. 관리 서버 노드에서 다음 Edge 관리 API 호출을 실행하여 ZooKeeper에서 대기 노드의 UUID를 삭제합니다. 
    curl -u sysAdminEmail:password -X DELETE http://ms_IP:8080/v1/servers/new_standby_uuid

Postgres 업그레이드 후 단계

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

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

이 문제를 해결하려면 마스터 Postgres 노드의 데이터베이스에 있는 모든 테이블에서 ANALYZE를 실행하세요. 또는 한 번에 여러 테이블에 대해 ANALYZE를 실행할 수 있습니다.

이전 버전에서 Apigee SSO를 업데이트하는 단계

프라이빗 클라우드용 Edge 4.53.01에서는 이제 apigee-sso 구성요소에 사용되는 IDP 키와 인증서가 키 저장소를 통해 구성됩니다. 이전에 사용한 키와 인증서를 키 저장소로 내보내고 구성한 다음 평소와 같이 SSO 업데이트를 진행해야 합니다.

  1. IDP 구성에 사용되는 기존 키와 인증서를 식별합니다.

    1. SSO 설치 구성 파일에서 SSO_SAML_SERVICE_PROVIDER_CERTIFICATE 값을 조회하거나 apigee-sso 구성요소에 conf_login_service_provider_certificate를 쿼리하여 인증서를 가져옵니다.

      SSO 노드에서 다음 명령어를 사용하여 IDP 인증서 경로에 대해 apigee-sso를 쿼리합니다. 출력에서 마지막 줄의 값을 확인합니다. 

      apigee-service apigee-sso configure -search conf_login_service_provider_certificate

    2. SSO 설치 구성 파일에서 SSO_SAML_SERVICE_PROVIDER_KEY 값을 조회하거나 apigee-sso 구성요소에 conf_login_service_provider_key를 쿼리하여 키를 가져옵니다.

      SSO 노드에서 다음 명령어를 사용하여 IDP 키 경로에 대해 apigee-sso를 쿼리합니다. 출력에서 마지막 줄의 값을 확인합니다.

      apigee-service apigee-sso configure -search conf_login_service_provider_key
  2. 키와 인증서를 키 저장소로 내보냅니다.
    1. 키와 인증서를 PKCS12 키 저장소로 내보냅니다. 
      sudo openssl pkcs12 -export -clcerts -in <certificate_path> -inkey <key_path> -out <keystore_path> -name <alias>

      매개변수:

      • certificate_path: 1.a단계에서 가져온 인증서 파일의 경로입니다.
      • key_path: 1.b단계에서 검색된 비공개 키 파일의 경로입니다.
      • keystore_path: 인증서와 비공개 키가 포함된 새로 생성된 키 저장소의 경로입니다.
      • alias: 키 저장소 내에서 키 및 인증서 쌍에 사용되는 별칭입니다.

      자세한 내용은 OpenSSL 문서를 참고하세요.

    2. (선택사항) PKCS12에서 JKS 키 저장소로 키와 인증서를 내보냅니다. 
      sudo keytool -importkeystore -srckeystore <PKCS12_keystore_path> -srcstoretype PKCS12 -destkeystore <destination_keystore_path> -deststoretype JKS -alias <alias>

      매개변수:

      • PKCS12_keystore_path: 인증서와 키가 포함된 2.a단계에서 생성된 PKCS12 키 저장소의 경로입니다.
      • destination_keystore_path: 인증서와 키가 내보내질 새 JKS 키 저장소의 경로입니다.
      • alias: JKS 키 저장소 내에서 키 및 인증서 쌍에 사용되는 별칭입니다.

      3. 자세한 내용은 keytool 문서를 참고하세요.

  3. 출력 키 저장소 파일의 소유자를 'apigee' 사용자로 변경합니다. 
    sudo chown apigee:apigee <keystore_file>
  4. Apigee SSO 구성 파일 에 다음 속성을 추가하고 키 저장소 파일 경로, 비밀번호, 키 저장소 유형, 별칭으로 업데이트합니다. 
    # Path to the keystore file
SSO_SAML_SERVICE_PROVIDER_KEYSTORE_PATH=${APIGEE_ROOT}/apigee-sso/source/conf/keystore.jks

# Keystore password
SSO_SAML_SERVICE_PROVIDER_KEYSTORE_PASSWORD=Secret123  # Password for accessing the keystore

# Keystore type
SSO_SAML_SERVICE_PROVIDER_KEYSTORE_TYPE=JKS  # Type of keystore, e.g., JKS, PKCS12

# Alias within keystore that stores the key and certificate
SSO_SAML_SERVICE_PROVIDER_KEYSTORE_ALIAS=service-provider-cert
  5. 다음 명령어를 사용하여 SSO 노드에서 Apigee SSO 소프트웨어를 평소와 같이 업데이트합니다. 
    /opt/apigee/apigee-setup/bin/update.sh -c sso -f /opt/silent.conf

새 Edge UI

이 섹션에서는 Edge UI에 관한 고려사항을 나열합니다. 자세한 내용은 프라이빗 클라우드를 위한 새로운 Edge UI를 참고하세요.

Edge UI 설치

초기 설치를 완료한 후 Apigee에서는 프라이빗 클라우드용 Apigee Edge의 개발자 및 관리자를 위한 향상된 사용자 인터페이스인 Edge UI를 설치할 것을 권장합니다.

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

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

Apigee mTLS로 업데이트

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

업데이트 롤백

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

실패로 인해 업데이트를 이전 버전으로 롤백해야 하는 경우 자세한 안내는 4.53.01 롤백을 참고하세요.

로깅 업데이트 정보

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

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

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

사용자가 /tmp에 액세스할 수 없으면 update.sh 유틸리티가 실패합니다.

제로 다운타임 업데이트

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

무중단 업데이트는 5노드 구성 이상에서만 가능합니다.

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

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

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

자동 구성 파일 사용

자동 구성 파일을 업데이트 명령어에 전달해야 합니다. 무음 구성 파일은 Edge for Private Cloud 4.52.02 또는 4.53.00을 설치하는 데 사용한 파일과 동일해야 합니다.

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

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

  1. 업데이트가 완료될 때까지 Cassandra에서 복구 작업을 실행하도록 구성된 cron 작업을 사용 중지합니다(있는 경우).
  2. 루트로 노드에 로그인하여 Edge RPM을 설치합니다.
  3. Edge apigee-setup 유틸리티 설치에 설명된 대로 SELinux를 사용 중지합니다.
  4. 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

  5. 현재 Edge 4.52.02 또는 4.53.00을 사용 중인 경우:

    1. 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
    2. 다음 명령어를 실행하여 Edge 4.53.01 apigee-service 유틸리티와 종속 항목을 설치합니다. 
      sudo bash /tmp/bootstrap_4.53.01.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.52.02 또는 4.53.00 설치 중에 Edge 구성요소를 정의하는 데 사용한 구성 파일과 동일합니다.

      component을 'all'로 설정하여 모든 구성요소에 대해 update.sh을 실행할 수 있지만, Edge 올인원 (AIO) 설치 프로필이 있는 경우에만 가능합니다. 예를 들면 다음과 같습니다.

      /opt/apigee/apigee-setup/bin/update.sh -c all -f ./sa_silent_config
    7. 아직 실행하지 않은 경우 실행 중인 모든 노드에서 Edge UI 구성요소를 다시 시작합니다. 
      /opt/apigee/apigee-service/bin/apigee-service [edge-management-ui|edge-ui] restart
    8. 설치 테스트에 설명된 대로 관리 서버에서 apigee-validate 유틸리티를 실행하여 업데이트를 테스트합니다.

나중에 업데이트를 롤백하려면 4.53.01 롤백에 설명된 절차를 사용하세요.

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

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

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

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

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

  1. Edge apigee-setup 유틸리티 설치의 '로컬 Apigee 저장소 만들기'에 설명된 대로 로컬 4.53.01 저장소를 만듭니다.
  2. .tar 파일에서 apigee-service를 설치하려면 다음을 실행하세요.
    1. 로컬 저장소가 있는 노드에서 다음 명령어를 사용하여 로컬 저장소를 /opt/apigee/data/apigee-mirror/apigee-4.53.01.tar.gz라는 단일 .tar 파일로 패키징합니다. 
      /opt/apigee/apigee-service/bin/apigee-service apigee-mirror package
    2. Edge를 업데이트할 노드에 .tar 파일을 복사합니다. 예를 들어 새 노드의 /tmp 디렉터리에 복사합니다.
    3. 새 노드에서 파일을 /tmp 디렉터리에 압축 해제합니다. 
      tar -xzf apigee-4.53.01.tar.gz

      이 명령어는 .tar 파일이 포함된 디렉터리에 repos라는 새 디렉터리를 만듭니다. 예: /tmp/repos

    4. /tmp/repos에서 Edge apigee-service 유틸리티와 종속 항목을 설치합니다. 
      sudo bash /tmp/repos/bootstrap_4.53.01.sh apigeeprotocol="file://" apigeerepobasepath=/tmp/repos

      이 명령어에는 저장소 디렉터리 경로가 포함되어 있습니다.

  3. Nginx 웹 서버를 사용하여 apigee-service를 설치하려면 다음 단계를 따르세요.
    1. Edge apigee-setup 유틸리티 설치의 'Nginx 웹 서버를 사용하여 저장소에서 설치'에 설명된 대로 Nginx 웹 서버를 구성합니다.
    2. 원격 노드에서 Edge bootstrap_4.53.01.sh 파일을 /tmp/bootstrap_4.53.01.sh에 다운로드합니다. 
      /usr/bin/curl http://uName:pWord@remoteRepo:3939/bootstrap_4.53.01.sh -o /tmp/bootstrap_4.53.01.sh

      여기서 uName:pWord는 이전에 저장소에 설정한 사용자 이름과 비밀번호이고 remoteRepo는 저장소 노드의 IP 주소 또는 DNS 이름입니다.

    3. 원격 노드에서 Edge apigee-setup 유틸리티와 종속 항목을 설치합니다. 
      sudo bash /tmp/bootstrap_4.53.01.sh apigeerepohost=remoteRepo:3939 apigeeuser=uName apigeepassword=pWord apigeeprotocol=http://

      여기서 uName:pWord은 저장소 사용자 이름과 비밀번호입니다.

  4. 다음 예시와 같이 apigee-service를 사용하여 apigee-setup 유틸리티를 업데이트합니다. 
    /opt/apigee/apigee-service/bin/apigee-service apigee-setup update
  5. 다음 예와 같이 관리 서버에서 apigee-validate 유틸리티를 업데이트합니다. 
    /opt/apigee/apigee-service/bin/apigee-service apigee-validate update
  6. 다음 예와 같이 관리 서버에서 apigee-provision 유틸리티를 업데이트합니다. 
    /opt/apigee/apigee-service/bin/apigee-service apigee-provision update
  7. 머신 업데이트 순서에 설명된 순서대로 노드에서 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.52.02 또는 4.53.00 설치 중에 Edge 구성요소를 정의하는 데 사용한 것과 동일한 구성 파일입니다.

    component을 'all'로 설정하여 모든 구성요소에 대해 update.sh을 실행할 수 있지만, Edge 올인원 (AIO) 설치 프로필이 있는 경우에만 가능합니다. 예를 들면 다음과 같습니다.

    /opt/apigee/apigee-setup/bin/update.sh -c all -f /tmp/sa_silent_config
  8. 아직 실행하지 않은 경우 실행 중인 모든 노드에서 UI 구성요소를 다시 시작합니다. 
    /opt/apigee/apigee-service/bin/apigee-service [edge-management-ui|edge-ui] restart
  9. 설치 테스트에 설명된 대로 관리 서버에서 apigee-validate 유틸리티를 실행하여 업데이트를 테스트합니다.

나중에 업데이트를 롤백하려면 4.53.01 롤백에 설명된 절차를 사용하세요.

머신 업데이트 순서

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

  • 다른 구성요소를 업데이트하기 전에 모든 LDAP 노드를 업데이트해야 합니다. LDAP를 업그레이드하려면 특별한 단계를 따라야 합니다.
  • 모든 Cassandra 및 ZooKeeper 노드를 업데이트해야 합니다. 4.52.02에서 업그레이드하는 경우 특별 단계를 따라 cassandra를 업그레이드하세요. 4.52.02 또는 4.53.00의 경우 특별 단계를 따라 Zookeeper를 업그레이드해야 합니다.
  • -c edge 옵션을 사용하여 모든 관리 서버와 라우터 및 메시지 프로세서를 업그레이드하여 업데이트해야 합니다.
  • Postgres 업그레이드의 특별 단계를 따라 모든 Postgres 노드를 업그레이드해야 합니다.
  • 모든 데이터 센터에서 edge-qpid-server 및 edge-postgres-server 구성요소를 업데이트해야 합니다.
  • 모든 Qpid 노드를 업그레이드해야 합니다.
  • Edge UI 노드를 업그레이드해야 하며 새 Edge UI 및 SSO 노드도 업그레이드해야 합니다(해당하는 경우).
  • 수익 창출을 업데이트하는 별도의 단계는 없습니다. -c edge 옵션을 지정하면 업데이트됩니다.

1노드 독립형 업그레이드

1노드 독립형 구성을 4.53.01로 업그레이드하려면 다음 단계를 따르세요.

  1. 모든 구성요소 업데이트: 
    /opt/apigee/apigee-setup/bin/update.sh -c all -f configFile
  2. (apigee-adminapi를 설치한 경우) apigee-adminapi 유틸리티를 업데이트합니다. 
    /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

2노드 독립형 업그레이드

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

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

  1. 머신 1에서 LDAP를 업데이트합니다. 
    /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
  2. 머신 1에서 Cassandra와 ZooKeeper를 업데이트합니다. 
    /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
  3. 머신 1에서 Edge 구성요소를 업데이트합니다. 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  4. 머신 2에서 Postgres를 업데이트합니다. 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  5. 머신 1에서 Edge 구성요소를 업데이트합니다. 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  6. 머신 2에서 Qpid를 업데이트합니다. 
    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  7. 머신 1에서 UI를 업데이트합니다. 
    /opt/apigee/apigee-setup/bin/update.sh -c ui -f configFile
  8. (apigee-adminapi를 설치한 경우) 머신 1에서 apigee-adminapi 유틸리티를 업데이트했습니다. 
    /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
  9. (Apigee SSO를 설치한 경우) 머신 1에서 Apigee SSO를 업데이트합니다. 
    /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

    여기서 sso_config_file은 SSO를 설치할 때 생성한 구성 파일입니다.

  10. 머신 1에서 Edge UI 구성요소를 다시 시작합니다. 
    /opt/apigee/apigee-service/bin/apigee-service edge-ui restart

5노드 업그레이드

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

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

  1. 머신 1에서 LDAP를 업데이트합니다. 
    /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
  2. 머신 1, 2, 3에서 Cassandra와 ZooKeeper를 업데이트합니다. 
    /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
  3. 머신 1, 2, 3에서 Edge 구성요소를 업데이트합니다. 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  4. 머신 4에서 Postgres를 업데이트합니다. 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  5. 머신 5에서 Postgres를 업데이트합니다. 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  6. 머신 4, 5에서 Edge 구성요소를 업데이트합니다. 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  7. 머신 4에서 Qpid를 업데이트합니다. 
    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  8. 머신 5에서 Qpid를 업데이트합니다. 
    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  9. 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
  10. (apigee-adminapi를 설치한 경우) 머신 1에서 apigee-adminapi 유틸리티를 업데이트했습니다. 
    /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
  11. (Apigee SSO를 설치한 경우) 머신 1에서 Apigee SSO를 업데이트합니다. 
    /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

    여기서 sso_config_file은 SSO를 설치할 때 생성한 구성 파일입니다.

  12. 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노드 클러스터 설치의 다음 구성요소를 업데이트합니다.

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

  1. 머신 1에서 LDAP를 업데이트합니다. 
    /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
  2. 머신 1, 2, 3에서 Cassandra와 ZooKeeper를 업데이트합니다. 
    /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
  3. 1, 4, 5번 머신 (관리 서버, 메시지 프로세서, 라우터)에서 순서대로 Edge 구성요소를 업데이트합니다. 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  4. 머신 8에서 Postgres를 업데이트합니다. 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  5. 머신 9에서 Postgres를 업데이트합니다. 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  6. 머신 6, 7, 8, 9에서 순서대로 Edge 구성요소를 업데이트합니다. 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  7. 머신 6과 7에서 Qpid를 업데이트합니다. 
    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  8. 머신 1에서 새 UI (ue) 또는 클래식 UI (ui)를 업데이트합니다. 
    /opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile
  9. (apigee-adminapi를 설치한 경우) 머신 1에서 apigee-adminapi 유틸리티를 업데이트합니다. 
    /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
  10. (Apigee SSO를 설치한 경우) 머신 1에서 Apigee SSO를 업데이트합니다. 
    /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

    여기서 sso_config_file은 SSO를 설치할 때 생성한 구성 파일입니다.

  11. 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개 노드 클러스터 설치의 다음 구성요소를 업데이트합니다.

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

  1. 머신 4와 5에서 LDAP를 업데이트합니다. 
    /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
  2. 머신 1, 2, 3에서 Cassandra와 ZooKeeper를 업데이트합니다. 
    /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
  3. 머신 6, 7, 10, 11의 Edge 구성요소를 순서대로 업데이트합니다. 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  4. 머신 8에서 Postgres를 업데이트합니다. 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  5. 머신 9에서 Postgres를 업데이트합니다. 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  6. 12, 13, 8, 9번 머신에서 순서대로 Edge 구성요소를 업데이트합니다. 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  7. 머신 12와 13에서 Qpid를 업데이트합니다. 
    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  8. 머신 6과 7에서 새 UI (ue) 또는 클래식 UI (ui)를 업데이트합니다. 
    /opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile
  9. (apigee-adminapi 설치 시) 6번 및 7번 컴퓨터에서 apigee-adminapi 유틸리티를 업데이트했습니다. 
    /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
  10. (Apigee SSO를 설치한 경우) 머신 6과 7에서 Apigee SSO를 업데이트합니다. 
    /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

    여기서 sso_config_file은 SSO를 설치할 때 생성한 구성 파일입니다.

  11. 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노드 클러스터 설치의 다음 구성요소를 업데이트합니다.

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

  1. LDAP 업데이트:
    1. 데이터 센터 1의 머신 1 
      /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
    2. 데이터 센터 2의 머신 7 
      /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
  2. Cassandra 및 ZooKeeper를 업데이트합니다.
    1. 데이터 센터 1의 머신 1, 2, 3: 
      /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
    2. 데이터 센터 2의 머신 7, 8, 9에서 다음을 실행합니다. 
      /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
  3. Edge 구성요소를 업데이트합니다.
    1. 데이터 센터 1의 머신 1, 2, 3에서 다음을 실행합니다. 
      /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
    2. 데이터 센터 2의 머신 7, 8, 9 
      /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  4. Postgres 업데이트:
    1. 데이터 센터 1의 머신 6 
      /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
    2. 데이터 센터 2의 머신 12 
      /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  5. Edge 구성요소를 업데이트합니다.
    1. 데이터 센터 1의 머신 4, 5, 6 
      /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
    2. 데이터 센터 2의 머신 10, 11, 12 
      /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  6. qpidd 업데이트:
    1. 데이터 센터 1의 머신 4, 5
      1. 머신 4에서 qpidd를 업데이트합니다. 
        /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
      2. 머신 5에서 qpidd를 업데이트합니다. 
        /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
    2. 데이터 센터 2의 머신 10, 11
      1. 머신 10에서 qpidd 을 업데이트합니다. 
        /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
      2. 머신 11에서 qpidd 을 업데이트합니다. 
        /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  7. 새 UI (ue) 또는 클래식 UI (ui)를 업데이트합니다.
    1. 데이터 센터 1의 머신 1: 
      /opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile
    2. 데이터 센터 2의 머신 7: 
      /opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile
  8. (apigee-adminapi을 설치한 경우) apigee-adminapi 유틸리티를 업데이트했습니다.
    1. 데이터 센터 1의 머신 1: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
    2. 데이터 센터 2의 머신 7: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
  9. (Apigee SSO를 설치한 경우) Apigee SSO를 업데이트합니다.
    1. 데이터 센터 1의 머신 1: 
      /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file
    2. 데이터 센터 2의 머신 7: 
      /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

      3. 여기서 sso_config_file은 SSO를 설치할 때 생성한 구성 파일입니다.

  10. 머신 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 구성요소를 업데이트합니다.

  1. LDAP
  2. Cassandra
  3. Zookeeper
  4. 관리 서버
  5. 메시지 프로세서
  6. 라우터
  7. Postgres
  8. Edge: Qpid 서버가 있는 노드, Edge Postgres 서버 순서로 모든 노드에서 '-c edge' 프로필을 의미합니다.
  9. qpidd
  10. Edge UI (기본 또는 새 UI)
  11. apigee-adminapi
  12. Apigee SSO

업데이트를 완료한 후 Edge UI 구성요소를 실행하는 모든 머신에서 Edge UI 구성요소를 다시 시작해야 합니다.