Обновите Apigee Edge 4.52.02 или 4.53.00 до 4.53.01

Apigee поддерживает прямое обновление Edge for Private Cloud с версии 4.52.02 или 4.53.00 до версии 4.53.01. На этой странице описано, как выполнить такое обновление.

Обзор совместимых путей обновления см. в матрице совместимости обновлений для выпусков Edge for Private Cloud .

Кто может выполнить обновление?

Для выполнения обновления должен использоваться тот же пользователь, который изначально устанавливал Edge, или пользователь, запускающий обновление от имени root.

После установки RPM-пакетов Edge любой сможет их настроить.

Какие компоненты необходимо обновить?

Необходимо обновить все компоненты Edge. Edge не поддерживает установку, содержащую компоненты из нескольких версий.

Обновить предварительные условия

Ознакомьтесь с изменениями в Edge для частного облака 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.

  • Настройка ключей и сертификатов IDP в Edge для частного облака 4.53.01

    В Edge for Private Cloud 4.53.01 ключи и сертификаты IDP, используемые в компоненте apigee-sso теперь настраиваются через хранилище ключей. Вам потребуется экспортировать ранее использованные ключ и сертификат в хранилище ключей. Перед обновлением компонента 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

После выполнения необходимых действий в зависимости от вашей версии, вернитесь к основной процедуре обновления, чтобы продолжить.

Автоматическое распространение настроек объекта

Если вы задали какие-либо параметры, отредактировав файлы .properties в каталоге /opt/apigee/customer/application , то эти значения будут сохранены при обновлении.

Требуется обновление до OpenLDAP 2.6.

Ниже приведена пошаговая инструкция по обновлению базовой службы LDAP в Apigee Edge for Private Cloud с устаревшей версии OpenLDAP 2.4 до OpenLDAP 2.6. Это обновление является обязательным условием для обновления до версии Apigee Edge for Private Cloud 4.53.01 и выше. Данное обновление применимо ко всем топологиям развертывания Apigee LDAP: односерверная, активная-пассивная и активная-активная (мультимастерная).

Предварительные условия и соображения

  • Обратите внимание, что во время процесса обновления LDAP API управления и, следовательно, пользовательский интерфейс Apigee будут полностью недоступны во всех регионах. Все административные задачи, такие как управление пользователями, ролями, приложениями и организациями, будут завершаться с ошибкой и должны быть приостановлены. Это не повлияет на обработку трафика вашего API-прокси. Перед продолжением обновления LDAP обязательно отключите все серверы управления и пользовательский интерфейс.

  • Резервное копирование имеет решающее значение: полная и проверенная резервная копия существующих данных 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 управления и пользовательского интерфейса.

    • Остановите службу 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. Восстановите резервные данные.

      Прежде чем продолжить, убедитесь, что шаг 5 успешно выполнен на всех LDAP-серверах.

      • На первом активном сервере, который вы определили выше, перейдите в каталог резервных копий. 
        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 проходит без проблем. Cassandra 4.0.X, выпущенная вместе с Edge for Private Cloud 4.53.00, совместима с компонентами среды выполнения и управления Private Cloud 4.52.02.
  • Прямой откат на месте с Cassandra 4.0.X до 3.11.X невозможен. Откат с использованием реплик или резервных копий — сложная процедура, которая может привести к простою и/или потере данных. Устранение неполадок и обновление до Cassandra 4.0.X предпочтительнее, чем откат.
  • Перед началом обновления важно ознакомиться с процедурами отката. Учет нюансов отката во время обновления имеет решающее значение для обеспечения наличия соответствующих путей отката.

Единый центр обработки данных

Обновление Cassandra с версии 3.11.X до 4.0.X в рамках одного центра обработки данных происходит без проблем, но откат является сложным процессом и может привести к простоям и потере данных. Для производственных нагрузок настоятельно рекомендуется добавить новый центр обработки данных, в котором будет доступно как минимум необходимое количество узлов Cassandra, прежде чем начинать обновление. Это позволит выполнить откат Cassandra без потери данных или нарушения трафика API. Этот дополнительный центр обработки данных можно будет вывести из эксплуатации после завершения обновления или достижения контрольной точки 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. Вы должны продолжать использовать более новую версию Cassandra с другими компонентами Private Cloud 4.53.00 или 4.52.02.
  1. Обновляйте Cassandra в каждом центре обработки данных по отдельности: начните с обновления узлов Cassandra в рамках одного центра обработки данных. Завершите обновление всех узлов Cassandra в одном центре обработки данных, прежде чем переходить к следующему.
  2. Приостановите и проверьте: после обновления одного центра обработки данных приостановите процесс, чтобы убедиться в корректной работе кластера частного облака, особенно обновленного центра обработки данных.
  3. Помните: откат к предыдущей версии Cassandra возможен только в том случае, если хотя бы один ваш центр обработки данных все еще работает на старой версии.
  4. Ограничения по времени: Хотя вы можете сделать короткую паузу (рекомендуется несколько часов) для проверки функциональности, вы не можете оставаться в состоянии смешанных версий бесконечно. Это связано с тем, что неоднородный кластер Cassandra (с узлами разных версий) имеет операционные ограничения.
  5. Тщательное тестирование: Apigee настоятельно рекомендует провести всестороннее тестирование производительности и функциональности перед обновлением следующего центра обработки данных. После обновления всех центров обработки данных откат к предыдущей версии будет невозможен.
Откат как процесс с двумя контрольными точками.
  1. Контрольная точка 1: Исходное состояние, все компоненты работают на версии 4.52.02. Полный откат возможен, если хотя бы один центр обработки данных Cassandra останется на более старой версии.
  2. Контрольная точка 2: После обновления всех узлов Cassandra во всех центрах обработки данных. Вы можете откатиться к этому состоянию, но не можете вернуться к контрольной точке 1.
Пример

Рассмотрим кластер из двух центров обработки данных:

  1. Исходное состояние: узлы Cassandra в обоих центрах обработки данных работают на версии 3.11.X. Все остальные узлы работают на Edge for Private Cloud версии 4.52.02. Предположим, что на каждый центр обработки данных приходится три узла Cassandra.
  2. Обновление DC-1: Поочередно обновите три узла Cassandra в DC-1.
  3. Приостановка и проверка: Сделайте паузу, чтобы убедиться в корректной работе кластера, особенно DC-1 (проверьте производительность и функциональность). Вы можете вернуться к исходному состоянию, используя узлы Cassandra в DC-2. Помните, что эта пауза должна быть временной из-за ограничений кластера Cassandra, использующего разные версии.
  4. Обновление DC-2: Обновите оставшиеся три узла Cassandra в DC-2. Это станет вашей новой контрольной точкой отката.
  5. Обновите другие компоненты: обновите узлы управления, среды выполнения и аналитики, как обычно, во всех центрах обработки данных, по одному узлу и одному центру обработки данных за раз. Если возникнут проблемы, вы можете вернуться к состоянию, описанному в шаге 4.

Предварительные условия для обновления Cassandra

Вам необходимо использовать Cassandra 3.11.16 с Edge for Private Cloud 4.52.02 и выполнить следующие действия:
  1. Весь кластер находится в рабочем состоянии и полностью функционален с Cassandra 3.11.16.
  2. Стратегия сжатия установлена ​​на LeveledCompactionStrategy (необходимое условие для обновления до версии 4.52.02).

  3. Убедитесь, что каждый из описанных ниже шагов был выполнен в рамках первоначального обновления Cassandra 3.11 в Edge for Private Cloud до версии 4.52.02.

    • Команда post_upgrade была выполнена на каждом узле Cassandra во время предыдущего обновления.
    • Команда drop_old_tables была выполнена для всего кластера Cassandra во время предыдущего обновления.

Если вы не уверены, что команды post_upgrade и drop_old_tables были выполнены в Cassandra 3.11 при использовании Edge for Private Cloud 4.52.02, вы можете безопасно повторно запустить их перед попыткой обновления до версии 4.53.01.

Шаг 1: Подготовка к обновлению

Описанные ниже шаги дополняют стандартные файлы, которые вы обычно создаете, например, стандартный конфигурационный файл Apigee для включения обновления компонентов.

  1. Создайте резервную копию Cassandra с помощью Apigee.
  2. Сделайте снимки виртуальных машин узлов Cassandra (если это возможно).
  3. Убедитесь, что порт 9042 доступен для всех компонентов Edge for Private Cloud, включая сервер управления, обработчик сообщений, маршрутизатор, Qpid и Postgres, для узлов Cassandra, если он еще не настроен. Дополнительную информацию см. в разделе « Требования к портам» .

Шаг 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. Выполните следующую команду post_upgrade на узле Cassandra: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra post_upgrade
  5. Выполните следующую команду cleanup_old_index на узле Cassandra: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra cleanup_old_index
  6. Выполните следующие команды 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 при выключении ведущего узла. Это может повлиять на операции управления, которые записывают данные в Zookeeper, такие как развертывание прокси-сервера, и на изменения инфраструктуры Apigee, такие как добавление или удаление обработчика сообщений и т. д. При выполнении описанной ниже процедуры обновление Zookeeper не должно повлиять на API среды выполнения Apigee (если только эти API среды выполнения не вызывают API управления).

В общих чертах, процесс обновления включает в себя создание резервной копии каждого узла. Затем следует обновление всех наблюдателей и последователей, и, наконец, обновление ведущего узла.

Сделайте резервную копию

Создайте резервную копию всех узлов Zookeeper на случай, если потребуется откат. Обратите внимание, что откат восстановит Zookeeper до состояния, в котором он находился на момент создания резервной копии. Примечание: любые развертывания или изменения инфраструктуры в Apigee, произошедшие после создания резервной копии (информация о которых хранится в Zookeeper), будут потеряны во время восстановления.

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

Если вы используете виртуальные машины и у вас есть такая возможность, можно также создавать снимки или резервные копии виртуальных машин для восстановления или отката (при необходимости).

Определите лидера, последователей и наблюдателей.

Примечание: В приведенных ниже примерах команд для отправки данных в Zookeeper используется утилита nc . Вы также можете использовать другие утилиты для отправки данных в Zookeeper.

  1. Если nc не установлен на узле ZooKeeper, установите его: 
      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 (то есть участник голосования, не являющийся лидером) в зависимости от конфигурации узла. Примечание: В автономной установке Edge с одним узлом ZooKeeper Mode установлен на standalone.

  3. Повторите шаги 1 и 2 для каждого узла ZooKeeper.

Обновите Zookeeper на узлах-наблюдателях и узлах-последователях.

Обновите Zookeeper на каждом из узлов-наблюдателей и узлов-последователей следующим образом:

  1. Загрузите и запустите загрузку Edge for Private Cloud 4.53.01, как описано в разделе «Обновление до версии 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. Это может повлиять на операции записи в Zookeeper, такие как развертывание прокси-серверов или изменения инфраструктуры Apigee, например, добавление или удаление обработчиков сообщений и т. д.

Убедитесь, что новый лидер избран.

Выполнив действия, описанные в разделе «Идентификация лидера, последователей и наблюдателей» выше, убедитесь, что после остановки текущего лидера из числа последователей был избран новый лидер. Обратите внимание, что лидер мог быть избран в другом центре обработки данных, нежели текущий лидер.

Лидер модернизации

Выполните те же действия, что и при обновлении Zookeeper на узлах-наблюдателях и узлах-последователях, описанных выше.

После обновления старого ведущего узла проверьте работоспособность кластера и убедитесь в наличии ведущего узла.

Обновление Nginx до версии 1.26 в Edge-Router

Обновление Edge for Private Cloud до версии 4.53.01 с предыдущих версий не приводит к автоматическому обновлению программного обеспечения Nginx до последней версии (1.26.x). Это сделано для предотвращения случайных побочных эффектов во время выполнения в результате изменений, описанных в разделе «Изменения Nginx 1.26 в Apigee Edge 4.53.01» . Вы можете вручную обновить 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. Остановите процесс edge-router на узле маршрутизатора. 

    /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. Повторите процесс на каждом узле маршрутизатора по очереди.

Требуется обновление до PostgreSQL версии 17.

В этом релизе Edge включено обновление до PostgreSQL 17. В рамках этого обновления все данные из PostgreSQL перенесены в PostgreSQL 17.

В большинстве производственных систем Edge используются два узла Postgres, настроенных на репликацию типа "мастер-резерв". Во время процесса обновления, пока узлы Postgres отключены для обновления, аналитические данные продолжают записываться на узлы Qpid. После обновления узлов Postgres и их повторного подключения аналитические данные передаются на узлы Postgres.

Способ выполнения обновления PostgreSQL зависит от того, как вы настроили хранилище данных для ваших узлов PostgreSQL:

  • Если вы используете локальное хранилище данных для узлов Postgres , вам необходимо установить новый резервный узел Postgres на время обновления. После завершения обновления вы можете вывести из эксплуатации новый резервный узел Postgres.

    Дополнительный резервный узел Postgres необходим, если по какой-либо причине потребуется откатить обновление. В этом случае новый резервный узел Postgres станет основным узлом Postgres. Поэтому при установке нового резервного узла Postgres его следует размещать на узле, отвечающем всем аппаратным требованиям сервера Postgres, как это определено в требованиях к установке Edge.

    В конфигурациях Edge с одним или двумя узлами, используемых для прототипирования и тестирования, у вас есть только один узел Postgres. Вы можете обновлять эти узлы Postgres напрямую, без необходимости создавать новый узел Postgres.

  • Если вы используете сетевое хранилище для своих узлов Postgres , как рекомендует Apigee, вам не нужно устанавливать новый узел Postgres. В описанных ниже процедурах вы можете пропустить шаги, которые указывают на необходимость установки и последующего вывода из эксплуатации нового резервного узла Postgres.

    Перед началом процесса обновления создайте сетевой снимок хранилища данных, используемого Postgres. Затем, если во время обновления возникнут ошибки и вам придётся выполнить откат, вы сможете восстановить узел Postgres из этого снимка.

Установка нового резервного узла Postgres

Эта процедура создает резервный сервер Postgres на новом узле. Убедитесь, что вы устанавливаете новый резервный сервер Postgres для вашей существующей версии Edge (4.52.02 или 4.53.00), а не для версии 4.53.01.

Для установки используйте тот же конфигурационный файл, который вы использовали для установки текущей версии Edge.

Чтобы создать новый резервный узел PostgreSQL:

  1. На текущем главном сервере PostgreSQL отредактируйте файл /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 — это IP-адрес текущего резервного сервера Postgres, а new_standby_ip — это IP-адрес нового резервного узла.

  2. Перезапустите apigee-postgresql на главном сервере 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. Отключите SELinux, как описано в разделе «Установка утилиты Edge apigee-setup» .

    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-setup используйте apigee-service : 
      /opt/apigee/apigee-service/bin/apigee-service apigee-setup install
    5. Установите PostgreSQL: 
      /opt/apigee/apigee-setup/bin/setup.sh -p ps -f configFile
    6. На новом резервном узле выполните следующую команду:
      /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-standby

      Убедитесь, что это резервный режим.

Выполняется обновление PostgreSQL без остановки процесса.

Примечание: Перед выполнением обновления PostgreSQL без установки необходимых изменений необходимо выполнить следующий предварительный шаг.

Предварительный шаг

Перед выполнением обновления PostgreSQL на месте выполните следующие действия на главном и резервном серверах, чтобы обновить свойство max_locks_per_transaction в apigee-postgresql :

  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

Выполните обновление на месте.

Для выполнения обновления PostgreSQL до версии 17 без изменения конфигурации выполните следующие действия:

  1. Обновите PostgreSQL на главном хосте. 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f /opt/silent.conf
  2. Выполните команду настройки на главном хосте: 
    apigee-service apigee-postgresql setup -f /opt/silent.conf
  3. Выполните команду configure на главном хосте: 
    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. Удалите строку conf/postgresql.conf+max_locks_per_transaction=30000 из файла /opt/apigee/customer/application/postgresql.properties как на главном, так и на резервном хосте. Эта строка была добавлена ​​на предварительном этапе .

After completing this procedure, the standby will start successfully.

Decommissioning a Postgres node

After the update completes, decommission the new standby node:

  1. Make sure Postgres is running:
    /opt/apigee/apigee-service/bin/apigee-all status

    If Postgres is not running, start it: 

    /opt/apigee/apigee-service/bin/apigee-all start
  2. Get the UUID of the new standby node by running the following curl command on the new standby node:
    curl -u sysAdminEmail:password http://node_IP:8084/v1/servers/self

    You should see the UUID of the node at the end of the output, in the form: 

    "type" : [ "postgres-server" ],
"uUID" : "599e8ebf-5d69-4ae4-aa71-154970a8ec75"
  3. Stop the new standby node by running the following command on the new standby node: 
    /opt/apigee/apigee-service/bin/apigee-all stop
  4. On the Postgres master node, edit /opt/apigee/customer/application/postgresql.properties to remove the new standby node from conf_pg_hba_replication.connection : 
    conf_pg_hba_replication.connection=host replication apigee existing_standby_ip/32 trust
  5. Restart apigee-postgresql on the Postgres master: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart
  6. Verify that the new standby node was removed by viewing the /opt/apigee/apigee-postgresql/conf/pg_hba.conf file on the master. You should see only the following line in that file: 
    host replication apigee existing_standby_ip/32 trust
  7. Delete the UUID of the standby node from ZooKeeper by making the following Edge management API call on the Management Server node: 
    curl -u sysAdminEmail:password -X DELETE http://ms_IP:8080/v1/servers/new_standby_uuid

Post-upgrade steps for Postgres

After a major Postgres upgrade, the internal statistics of Postgres are wiped out. These statistics aid the Postgres query planner in utilizing the most optimal indexes and paths to execute queries.

Postgres can gradually rebuild its statistics over time as queries are executed and when the autovacuum daemon runs. However, until the statistics are rebuilt, your queries may be slow.

To address this issue, execute ANALYZE on all tables in the database on the master Postgres node. Alternatively, you can execute ANALYZE for a few tables at a time.

Steps for updating Apigee SSO from older versions

In Edge for Private Cloud 4.53.01, the IDP keys and certificates used in the apigee-sso component are now configured through a keystore. You will need to export the key and certificate used earlier into a keystore, configure it, and then proceed with the SSO update as usual.

  1. Identify the existing key and certificate used for configuring IDP:

    1. Retrieve the certificate by looking up the value of SSO_SAML_SERVICE_PROVIDER_CERTIFICATE in the SSO installation configuration file or by querying the apigee-sso component for conf_login_service_provider_certificate .

      Use the following command on the SSO node to query apigee-sso for the IDP certificate path. In the output, look for the value in the last line. 

      apigee-service apigee-sso configure -search conf_login_service_provider_certificate

    2. Retrieve the key by looking up the value of SSO_SAML_SERVICE_PROVIDER_KEY in the SSO installation configuration file or by querying the apigee-sso component for conf_login_service_provider_key .

      Use the following command on the SSO node to query apigee-sso for the IDP key path. In the output, look for the value on the last line. 

      apigee-service apigee-sso configure -search conf_login_service_provider_key
  2. Export the key and certificate to a keystore:
    1. Export the key and certificate to a PKCS12 keystore:
      sudo openssl pkcs12 -export -clcerts -in <certificate_path> -inkey <key_path> -out <keystore_path> -name <alias>

      Параметры:

      • certificate_path : Path to the certificate file retrieved in Step 1.a.
      • key_path : Path to the private key file retrieved in Step 1.b.
      • keystore_path : Path to the newly created keystore containing the certificate and private key.
      • alias : Alias used for the key and certificate pair within the keystore.

      Refer to the OpenSSL documentation for more details.

    2. (Optional) Export the key and certificate from PKCS12 to a JKS keystore:
      sudo keytool -importkeystore -srckeystore <PKCS12_keystore_path> -srcstoretype PKCS12 -destkeystore <destination_keystore_path> -deststoretype JKS -alias <alias>

      Параметры:

      • PKCS12_keystore_path : Path to the PKCS12 keystore created in Step 2.a, containing the certificate and key.
      • destination_keystore_path : Path to the new JKS keystore where the certificate and key will be exported.
      • alias : Alias used for the key and certificate pair within the JKS keystore.

      3. Refer to the keytool documentation for more details.

  3. Change the owner of the output keystore file to the "apigee" user: 
    sudo chown apigee:apigee <keystore_file>
  4. Add the following properties in Apigee SSO configuration file and update them with the keystore file path, password, keystore type, and alias: 
    # 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. Update Apigee SSO software on the SSO node as usual using the following command: 
    /opt/apigee/apigee-setup/bin/update.sh -c sso -f /opt/silent.conf

New Edge UI

This section lists considerations regarding the Edge UI. For more information, see The new Edge UI for Private Cloud .

Install the Edge UI

After you complete the initial installation, Apigee recommends that you install the Edge UI, which is an enhanced user interface for developers and administrators of Apigee Edge for Private Cloud.

Note that the Edge UI requires that you disable Basic authentication and use an IDP such as SAML or LDAP.

For more information, see Install the new Edge UI .

Update with Apigee mTLS

To update Apigee mTLS , do the following steps:

Rolling back an update

In the case of an update failure, you can try to correct the issue, and then execute update.sh again. You can run the update multiple times and it continues the update from where it last left off.

If the failure requires that you roll back the update to your previous version, see Roll back 4.53.01 for detailed instructions.

Logging update information

By default, the update.sh utility writes log information to: 

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

If the person running the update.sh utility does not have access to that directory, it writes the log to the /tmp directory as a file named update_username.log .

If the person does not have access to /tmp , the update.sh utility fails.

Zero-downtime update

A zero-downtime update, or rolling update, lets you update your Edge installation without bringing down Edge.

Zero-downtime update is only possible with a 5-node configuration and larger.

The key to zero-downtime upgrading is to remove each Router, one at a time, from the load balancer. You then update the Router and any other components on the same machine as the Router, and then add the Router back to the load balancer.

  1. Update the machines in the correct order for your installation as described Order of machine update .
  2. When it is time to update the Routers, select any one Router and make it unreachable, as described in Enabling/Disabling server (Message Processor/Router) reachability .
  3. Update the selected Router and all other Edge components on the same machine as the Router. All Edge configurations show a Router and Message Processor on the same node.
  4. Make the Router reachable again.
  5. Repeat steps 2 through 4 for the remaining Routers.
  6. Continue the update for any remaining machines in your installation.

Take care of the following before and after the update:

Use a silent configuration file

You must pass a silent configuration file to the update command. The silent configuration file should be the same one that you used to install Edge for Private Cloud 4.52.02 or 4.53.00.

Update to 4.53.01 on a node with an external internet connection

Use the following procedure to update the Edge components on a node:

  1. If present, disable any cron jobs configured to perform a repair operation on Cassandra until after the update completes.
  2. Log in to your node as root to install the Edge RPMs.
  3. Disable SELinux as described in Install the Edge apigee-setup utility .
  4. If you are installing on AWS , execute the following yum-configure-manager commands: 
    yum update rh-amazon-rhui-client.noarch
sudo yum-config-manager --enable rhui-REGION-rhel-server-extras rhui-REGION-rhel-server-optional

  5. If you are currently on Edge 4.52.02 or 4.53.00:

    1. Download the Edge bootstrap_4.53.01.sh file to /tmp/bootstrap_4.53.01.sh : 
      curl https://software.apigee.com/bootstrap_4.53.01.sh -o /tmp/bootstrap_4.53.01.sh
    2. Install the Edge 4.53.01 apigee-service utility and dependencies by executing the following command:
      sudo bash /tmp/bootstrap_4.53.01.sh apigeeuser=uName apigeepassword=pWord

      Where uName:pWord are the username and password you received from Apigee. If you omit pWord , you will be prompted to enter it.

      By default, the installer checks that you have Java 1.8 installed. If you do not, the installer installs it for you.

      Use the JAVA_FIX option to specify how to handle Java installation. JAVA_FIX takes the following values:

      • I : Install OpenJDK 1.8 (default).
      • C : Continue without installing Java.
      • Q : Quit. For this option, you must install Java yourself.
    3. Use apigee-service to update the apigee-setup utility, as the following example shows: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-setup update
    4. Update the apigee-validate utility on the Management Server, as the following example shows: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-validate update
    5. Update the apigee-provision utility on the Management Server, as the following example shows: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-provision update
    6. Run the update utility on your nodes by executing the following command:
      /opt/apigee/apigee-setup/bin/update.sh -c component -f configFile

      Do this in the order described in Order of machine update .

      Где:

      • component is the Edge component to update. Possible values include:
        • cs : Cassandra
        • edge : All Edge components except Edge UI: Management Server, Message Processor, Router, QPID Server, Postgres Server
        • ldap : OpenLDAP
        • ps : postgresql
        • qpid : qpidd
        • sso : Apigee SSO (if you installed SSO)
        • ue : New Edge UI
        • ui : Classic Edge UI
        • zk : Zookeeper
      • configFile is the same configuration file that you used to define your Edge components during the 4.52.02 or 4.53.00 installation.

      You can run update.sh against all components by setting component to "all", but only if you have an Edge all-in-one (AIO) installation profile. For example: 

      /opt/apigee/apigee-setup/bin/update.sh -c all -f ./sa_silent_config
    7. Restart the Edge UI components on all nodes running them, if you haven't done so already: 
      /opt/apigee/apigee-service/bin/apigee-service [edge-management-ui|edge-ui] restart
    8. Test the update by running the apigee-validate utility on the Management Server, as described in Test the install .

If you later decide to roll back the update, use the procedure described in Roll back 4.53.01 .

Update to 4.53.01 from a local repo

If your Edge nodes are behind a firewall, or in some other way are prohibited from accessing the Apigee repository over the Internet, then you can perform the update from a local repository, or mirror, of the Apigee repo.

After you create a local Edge repository, you have two options for updating Edge from the local repo:

  • Create a .tar file of the repo, copy the .tar file to a node, and then update Edge from the .tar file.
  • Install a webserver on the node with the local repo so that other nodes can access it. Apigee provides the Nginx webserver for you to use, or you can use your own webserver.

To update from a local 4.53.01 repo:

  1. Create a local 4.53.01 repo as described in "Create a local Apigee repository" at Install the Edge apigee-setup utility .
  2. To install apigee-service from a .tar file :
    1. On the node with the local repo, use the following command to package the local repo into a single .tar file named /opt/apigee/data/apigee-mirror/apigee-4.53.01.tar.gz : 
      /opt/apigee/apigee-service/bin/apigee-service apigee-mirror package
    2. Copy the .tar file to the node where you want to update Edge. For example, copy it to the /tmp directory on the new node.
    3. On the new node, untar the file to the /tmp directory:
      tar -xzf apigee-4.53.01.tar.gz

      This command creates a new directory, named repos , in the directory containing the .tar file. For example /tmp/repos .

    4. Install the Edge apigee-service utility and dependencies from /tmp/repos :
      sudo bash /tmp/repos/bootstrap_4.53.01.sh apigeeprotocol="file://" apigeerepobasepath=/tmp/repos

      Notice that you include the path to the repos directory in this command.

  3. To install apigee-service using the Nginx webserver:
    1. Configure the Nginx web server as described in "Install from the repo using the Nginx webserver" at Install the Edge apigee-setup utility .
    2. On the remote node, download the Edge bootstrap_4.53.01.sh file to /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

      Where uName:pWord are the username and password you set previously for the repo, and remoteRepo is the IP address or DNS name of the repo node.

    3. On the remote node, install the Edge apigee-setup utility and dependencies:
      sudo bash /tmp/bootstrap_4.53.01.sh apigeerepohost=remoteRepo:3939 apigeeuser=uName apigeepassword=pWord apigeeprotocol=http://

      Where uName:pWord are the repo username and password.

  4. Use apigee-service to update the apigee-setup utility, as the following example shows: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-setup update
  5. Update the apigee-validate utility on the Management Server, as the following example shows: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-validate update
  6. Update the apigee-provision utility on the Management Server, as the following example shows: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-provision update
  7. Run the update utility on your nodes in the order described in Order of machine update :
    /opt/apigee/apigee-setup/bin/update.sh -c component -f configFile

    Где:

    • component is the Edge component to update. You typically update the following components:
      • cs : Cassandra
      • edge : All Edge components except Edge UI: Management Server, Message Processor, Router, QPID Server, Postgres Server
      • ldap : OpenLDAP
      • ps : postgresql
      • qpid : qpidd
      • sso : Apigee SSO (if you installed SSO)
      • ue New Edge UI
      • ui : Classic Edge UI
      • zk : Zookeeper
    • configFile is the same configuration file that you used to define your Edge components during the 4.52.02 or 4.53.00 installation.

    You can run update.sh against all components by setting component to "all", but only if you have an Edge all-in-one (AIO) installation profile. For example: 

    /opt/apigee/apigee-setup/bin/update.sh -c all -f /tmp/sa_silent_config
  8. Restart the UI components on all nodes running it, if you haven't done so already: 
    /opt/apigee/apigee-service/bin/apigee-service [edge-management-ui|edge-ui] restart
  9. Test the update by running the apigee-validate utility on the Management Server, as described in Test the install .

If you later decide to roll back the update, use the procedure described in Roll back 4.53.01 .

Order of machine update

The order that you update the machines in an Edge installation is important:

  • You must update all LDAP nodes before updating any other components. You will need to follow special steps to upgrade LDAP.
  • You must update all Cassandra and ZooKeeper nodes. If you're upgrading from 4.52.02 then, follow the special steps to upgrade cassandra. You will need to follow the special steps to upgrade Zookeeper for 4.52.02 or 4.53.00.
  • You must upgrade all the Management Servers and Router & Message Processors using the -c edge option to update them.
  • You must upgrade all Postgres nodes following the special steps for upgrade Postgres.
  • You must update edge-qpid-server & edge-postgres-server components across all data centers.
  • You must upgrade all Qpid nodes.
  • You must upgrade Edge UI nodes and also upgrade the New Edge UI and SSO nodes(if applicable).
  • There is no separate step to update Monetization. It is updated when you specify the -c edge option.

1-node standalone upgrade

To upgrade a 1-node standalone configuration to 4.53.01:

  1. Update all components: 
    /opt/apigee/apigee-setup/bin/update.sh -c all -f configFile
  2. (If you installed apigee-adminapi ) Update the apigee-adminapi utility: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

2-node standalone upgrade

Update the following components for a 2-node standalone installation:

See Installation topologies for the list of Edge topologies and node numbers.

  1. Update LDAP on machine 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
  2. Update Cassandra and ZooKeeper on machine 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
  3. Update Edge components on machine 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  4. Update Postgres on machine 2: 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  5. Update Edge components on machine 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  6. Update Qpid on Machine 2: 
    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  7. Update the UI on machine 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c ui -f configFile
  8. (If you installed apigee-adminapi ) Updated the apigee-adminapi utility on machine 1: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
  9. (If you installed Apigee SSO) Update Apigee SSO on machine 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

    Where sso_config_file is the configuration file you created when you installed SSO .

  10. Restart the Edge UI component on machine 1: 
    /opt/apigee/apigee-service/bin/apigee-service edge-ui restart

5-node upgrade

Update the following components for a 5-node installation:

See Installation topologies for the list of Edge topologies and node numbers.

  1. Update LDAP on machine 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
  2. Update Cassandra and ZooKeeper on machine 1, 2, and 3: 
    /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
  3. Update Edge components on machine 1, 2, 3: 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  4. Update Postgres on machine 4: 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  5. Update Postgres on machine 5: 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  6. Update Edge components on machine 4, 5: 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  7. Update Qpid on machine 4: 
    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  8. Update Qpid on machine 5: 
    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  9. Update the Edge UI:
    • Classic UI: If you are using the classic UI, then update the ui component on machine 1, as the following example shows: 
      /opt/apigee/apigee-setup/bin/update.sh -c ui -f configFile
    • New Edge UI: If you installed the new Edge UI, then update the ue component on the appropriate machine (may not be machine 1): 
      /opt/apigee/apigee-setup/bin/update.sh -c ue -f /opt/silent.conf
  10. (If you installed apigee-adminapi ) Updated the apigee-adminapi utility on machine 1: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
  11. (If you installed Apigee SSO) Update Apigee SSO on machine 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

    Where sso_config_file is the configuration file you created when you installed SSO .

  12. Restart the UI component:
    • Classic UI: If you are using the classic UI, then restart the edge-ui component on machine 1, as the following example shows: 
      /opt/apigee/apigee-service/bin/apigee-service edge-ui restart
    • New Edge UI: If you installed the new Edge UI, then restart the edge-management-ui component on the appropriate machine (may not be machine 1): 
      /opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart

9-node clustered upgrade

Update the following components for a 9-node clustered installation:

See Installation topologies for the list of Edge topologies and node numbers.

  1. Update LDAP on machine 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
  2. Update Cassandra and ZooKeeper on machine 1, 2, and 3: 
    /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
  3. Update Edge components on machine 1, 4, and 5 (Management server, message processor, router) in that order: 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  4. Update Postgres on machine 8: 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  5. Update Postgres on machine 9: 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  6. Update Edge components on machine 6, 7, 8, and 9 in that order: 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  7. Update Qpid on machines 6 and 7: 
    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  8. Update either the new UI ( ue ) or classic UI ( ui ) on machine 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile
  9. (If you installed apigee-adminapi ) Update the apigee-adminapi utility on machine 1: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
  10. (If you installed Apigee SSO) Update Apigee SSO on machine 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

    Where sso_config_file is the configuration file you created when you installed SSO .

  11. Restart the UI component:
    • Classic UI: If you are using the classic UI, then restart the edge-ui component on machine 1, as the following example shows: 
      /opt/apigee/apigee-service/bin/apigee-service edge-ui restart
    • New Edge UI: If you installed the new Edge UI, then restart the edge-management-ui component on the appropriate machine (may not be machine 1): 
      /opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart

13-node clustered upgrade

Update the following components for a 13-node clustered installation:

See Installation topologies for the list of Edge topologies and node numbers.

  1. Update LDAP on machine 4 and 5: 
    /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
  2. Update Cassandra and ZooKeeper on machines 1, 2, and 3: 
    /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
  3. Update Edge components on machines 6, 7, 10, and 11 in that order: 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  4. Update Postgres on machine 8: 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  5. Update Postgres on machine 9: 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  6. Update Edge components on machines 12, 13, 8, and 9 in that order: 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  7. Update Qpid on machines 12 and 13: 
    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  8. Update either the new UI ( ue ) or classic UI ( ui ) on machines 6 and 7: 
    /opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile
  9. (If you installed apigee-adminapi ) Updated the apigee-adminapi utility on machines 6 and 7: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
  10. (If you installed Apigee SSO) Update Apigee SSO on machines 6 and 7: 
    /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

    Where sso_config_file is the configuration file you created when you installed SSO .

  11. Restart the UI component:
    • Classic UI: If you are using the classic UI, then restart the edge-ui component on machines 6 and 7, as the following example shows: 
      /opt/apigee/apigee-service/bin/apigee-service edge-ui restart
    • New Edge UI: If you installed the new Edge UI, then restart the edge-management-ui component on machines 6 and 7: 
      /opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart

12-node clustered upgrade

Update the following components for a 12-node clustered installation:

See Installation topologies for the list of Edge topologies and node numbers.

  1. Update LDAP:
    1. Machine 1 in Data Center 1 
      /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
    2. Machine 7 in Data Center 2 
      /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
  2. Update Cassandra and ZooKeeper:
    1. Machines 1, 2 and 3 in Data center 1: 
      /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
    2. On machines 7, 8, and 9 in Data Center 2: 
      /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
  3. Update Edge components:
    1. On machines 1, 2 and 3 in Data Center 1: 
      /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
    2. On machines 7, 8, and 9 in Data Center 2 
      /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  4. Update Postgres:
    1. Machine 6 in Data Center 1 
      /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
    2. Machine 12 in Data Center 2 
      /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  5. Update Edge components:
    1. Machines 4, 5, 6 in Data Center 1 
      /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
    2. Machines 10, 11, 12 in Data Center 2 
      /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  6. Update qpidd:
    1. Machines 4, 5 in Data Center 1
      1. Update qpidd on machine 4: 
        /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
      2. Update qpidd on machine 5: 
        /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
    2. Machines 10, 11 in Data Center 2
      1. Update qpidd on machine 10: 
        /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
      2. Update qpidd on machine 11: 
        /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  7. Update either the new UI ( ue ) or classic UI ( ui ):
    1. Machine 1 in Data Center 1: 
      /opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile
    2. Machine 7 in Data Center 2: 
      /opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile
  8. (If you installed apigee-adminapi ) Updated the apigee-adminapi utility:
    1. Machine 1 in Data Center 1: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
    2. Machine 7 in Data Center 2: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
  9. (If you installed Apigee SSO) Update Apigee SSO:
    1. Machine 1 in Data Center 1: 
      /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file
    2. Machine 7 in Data Center 2: 
      /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

      3. Where sso_config_file is the configuration file you created when you installed SSO .

  10. Restart the new Edge UI ( edge-management-ui ) or classic Edge UI ( edge-ui ) component on machines 1 and 7: 
    /opt/apigee/apigee-service/bin/apigee-service [edge-ui|edge-management-ui] restart

For a non-standard configuration

If you have a non-standard configuration, then update Edge components in the following order:

  1. LDAP
  2. Кассандра
  3. Смотритель зоопарка
  4. Сервер управления
  5. Message Processor
  6. Маршрутизатор
  7. PostgreSQL
  8. Edge, meaning the "-c edge" profile on all nodes in the order: nodes with Qpid server, Edge Postgres Server.
  9. qpidd
  10. Edge UI (either classic or new)
  11. apigee-adminapi
  12. Apigee SSO

After you finish updating, be sure to restart the Edge UI component on all machines running it.