Atualizar o Apigee Edge 4.52.02 ou 4.53.00 para 4.53.01

A Apigee oferece suporte ao upgrade do Edge para nuvem privada diretamente da versão 4.52.02 ou 4.53.00 para a versão 4.53.01. Nesta página, descrevemos como fazer esses upgrades.

Para uma visão geral dos caminhos de upgrade compatíveis, consulte a matriz de compatibilidade de upgrade para versões do Edge para nuvem privada.

Quem pode fazer a atualização

A pessoa que executa a atualização precisa ser a mesma que instalou o Edge originalmente ou uma pessoa que executa como root.

Depois de instalar os RPMs do Edge, qualquer pessoa pode configurá-los.

Quais componentes você precisa atualizar

Você precisa atualizar todos os componentes do Edge. O Edge não é compatível com uma configuração que contenha componentes de várias versões.

Atualizar pré-requisitos

Analisar as mudanças no Edge para nuvem privada 4.53.01

Vários problemas de segurança foram abordados nesta versão. Embora essas melhorias de segurança sejam essenciais, elas introduzem algumas mudanças que não são compatíveis com versões anteriores. Isso significa que o upgrade vai exigir etapas extras para garantir que não haja interrupções durante ou após o upgrade. Para mais informações, consulte este tópico ao fazer upgrade para a versão 4.53.01 de versões mais antigas da nuvem privada.

Verifique os seguintes pré-requisitos antes de fazer upgrade do Apigee Edge:

  • Faça backup de todos os nós
    Antes de atualizar, recomendamos que você faça um backup completo de todos os nós por motivos de segurança. Use o procedimento da sua versão atual do Edge para fazer o backup.

    Isso permite que você tenha um plano de backup caso a atualização para uma nova versão não funcione corretamente. Para mais informações sobre backup, consulte Backup e restauração.

  • Verifique se o Edge está em execução
    Verifique se o Edge está em execução durante o processo de atualização usando o comando: 
    /opt/apigee/apigee-service/bin/apigee-all status
  • Verificar os pré-requisitos do Cassandra

    Se você fez upgrade de uma versão mais antiga do Edge para nuvem privada para a versão 4.52.02 e agora planeja fazer upgrade para a versão 4.53.01, verifique se concluiu as etapas necessárias pós-upgrade para o Cassandra. Essas etapas estão descritas na documentação de upgrade da versão 4.52.02 e também mencionadas em Pré-requisitos para o upgrade do Cassandra. Se você não tiver certeza se essas etapas foram concluídas durante o upgrade anterior, faça tudo de novo antes de prosseguir com o upgrade para a versão 4.53.01.

  • Como configurar chaves e certificados de IdP no Edge para nuvem privada 4.53.01

    No Edge para nuvem privada 4.53.01, as chaves e os certificados do IDP usados no componente apigee-sso agora são configurados por um keystore. Você precisa exportar a chave e o certificado usados anteriormente para um keystore. Siga as etapas na seção Etapas para atualizar o Apigee SSO de versões mais antigas para ver as etapas detalhadas antes de atualizar o componente de SSO.

  • Requisitos do Python
    Verifique se todos os nós, incluindo os do Cassandra, têm o Python 3 instalado antes de tentar fazer o upgrade.

Quais etapas especiais considerar para o upgrade

Para fazer upgrade para o Edge para nuvem privada 4.53.01, siga as etapas específicas para atualizar determinados softwares. As etapas necessárias dependem da sua versão atual. Consulte a tabela abaixo para ver os vários softwares que exigem etapas complementares e siga as instruções detalhadas para cada um deles. Depois de concluir as tarefas necessárias, retorne ao procedimento principal de upgrade para continuar o processo.

Versão atual Software que exige etapas especiais para upgrade para a versão 4.53.01
4.52.02 LDAP, Cassandra, Zookeeper, Postgres
4.53.00 LDAP, Zookeeper, Postgres

Depois de realizar as etapas necessárias com base na sua versão, volte ao procedimento principal de upgrade para continuar.

Propagação automática das configurações da propriedade

Se você definiu propriedades editando arquivos .properties em /opt/apigee/customer/application, esses valores serão mantidos pela atualização.

Atualização obrigatória para o OpenLDAP 2.6

Confira o procedimento detalhado para fazer upgrade do serviço LDAP subjacente do Apigee Edge para nuvem privada do OpenLDAP 2.4 legado para o OpenLDAP 2.6. Essa atualização é um requisito obrigatório para a atualização da versão 4.53.01 e mais recentes do Apigee Edge para nuvem privada. Esse upgrade é aplicável a todas as topologias de implantação do LDAP do Apigee: servidor único, ativo-passivo e ativo-ativo (multimestre).

Pré-requisitos e considerações

  • Durante o processo de upgrade do LDAP, as APIs de gerenciamento e, consequentemente, a interface da Apigee vão ficar completamente indisponíveis em todas as regiões. Todas as tarefas administrativas, como gerenciar usuários, funções, apps e organizações, vão falhar e precisam ser pausadas. Não haverá impacto no processamento do tráfego do proxy de API. Desative todos os servidores de gerenciamento de borda e a interface de borda antes de continuar com o upgrade do LDAP.

  • O backup é essencial:um backup completo e validado dos seus dados LDAP atuais é indispensável. Continuar sem um backup válido vai causar perda de dados irreversível. O backup precisa ser iniciado enquanto o serviço LDAP ainda está em execução para capturar um snapshot consistente e pontual dos dados do LDAP. O backup é necessário para realizar o upgrade. Sem backup, não será possível executar o upgrade nem fazer o rollback, já que as etapas de upgrade envolvem a limpeza dos dados do LDAP.

Preparação e instalação (todos os servidores LDAP)

As etapas desta seção (2 a 5) são idênticas para todas as topologias de implantação do LDAP. Essas ações precisam ser realizadas em todos os servidores em que o componente apigee-openldap está instalado, independente da função.

  1. Desligue todos os edge-management-server e edge-ui antes de continuar com o upgrade do LDAP. 
    apigee-service edge-management-server stop
apigee-service edge-ui stop

  2. Fazer backup dos dados do LDAP

    Antes de fazer qualquer mudança, faça um backup completo dos dados atuais do LDAP de todos os servidores LDAP. Isso cria um ponto de restauração seguro.

    • Execute o comando de backup. Essa ação cria um arquivo de backup com carimbo de data/hora no diretório /opt/apigee/backup/openldap. 
      apigee-service apigee-openldap backup
    • Receber a contagem total de registros:capture o número de registros no seu diretório para validação pós-upgrade. A contagem de registros precisa ser igual em todos os servidores LDAP. Esta é uma verificação de integridade. 
      # 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. Parar o LDAP e limpar os diretórios de dados

    Essa etapa precisa ser realizada em todos os servidores LDAP. Ela é obrigatória devido à mudança na versão principal e às diferenças estruturais subjacentes. Um diretório limpo garante que não haja conflitos. Quando todos os servidores LDAP forem interrompidos, a interrupção das APIs e da interface do usuário de gerenciamento vai começar.

    • Interrompa o serviço LDAP. 
      apigee-service apigee-openldap stop
    • Remova permanentemente os diretórios de configuração e dados LDAP antigos. 
      rm -rf /opt/apigee/data/apigee-openldap/*

  4. Instalar e configurar a nova versão do LDAP

    Em todos os servidores LDAP, use os scripts padrão da Apigee para fazer o download e instalar a nova versão do componente.

    • Instale o novo componente LDAP:o script de atualização lê seu arquivo de configuração e instala o novo pacote apigee-openldap. 
      /opt/apigee/apigee-setup/bin/update.sh -c ldap -f /opt/silent.conf
    • Valide a nova versão do LDAP:depois que a instalação for concluída, recarregue o perfil e verifique se a nova versão do LDAP foi instalada corretamente. 
      source ~/.bash_profile
ldapsearch -VV
Expected output:
ldapsearch: @(#) $OpenLDAP: ldapsearch 2.6.7

  5. Interrompa o LDAP em todos os servidores antes da restauração de dados

    Essa é uma etapa de sincronização essencial. Antes de restaurar o backup, verifique se o serviço LDAP recém-instalado está interrompido em todos os servidores. Em cada servidor LDAP, execute os seguintes comandos: 

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

  6. Restaurar dados do LDAP

    A estratégia é restaurar o backup no primeiro servidor ativo. Esse servidor vai atuar como a fonte da verdade, replicando os dados para os colegas em uma configuração de vários servidores.

    1. Identificar o primeiro servidor ativo para restauração

      • Para configuração de servidor único:este é seu único servidor LDAP. Você pode prosseguir diretamente para a próxima etapa.
      • Para configurações ativo-passivo e ativo-ativo:execute o seguinte comando de diagnóstico em cada servidor 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. Restaurar os dados de backup

      Antes de continuar, verifique se a etapa 5 foi concluída em todos os servidores LDAP.

      • No primeiro servidor ativo identificado acima, navegue até o diretório de backup. 
        cd /opt/apigee/backup/openldap
      • Execute o comando restore. Recomendamos especificar o carimbo de data/hora exato do backup da etapa 2 para evitar a restauração de uma versão não intencional ou mais antiga. 
        # 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
      • Depois que o processo de restauração for concluído, inicie o serviço LDAP no primeiro servidor ativo. 
        apigee-service apigee-openldap start

  7. Iniciar os servidores LDAP restantes

    Se você tiver uma configuração de vários servidores, inicie o serviço em cada um dos servidores LDAP: 

    apigee-service apigee-openldap start

  8. Validação final

    A etapa final é verificar se o upgrade foi bem-sucedido e se os dados estão consistentes em todo o cluster LDAP.

    • Execute o comando de validação em todos os servidores LDAP. A contagem de registros precisa ser idêntica em todos os servidores e corresponder à contagem capturada na etapa 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
    • Depois de confirmar que os dados estão corretos e consistentes, a atualização do LDAP será concluída. Agora você pode iniciar o edge-management-server e o edge-ui, além de outros componentes dependentes, de acordo com o procedimento padrão de upgrade da sua organização.

Upgrade obrigatório para o Cassandra 4.0.18

O Apigee Edge para nuvem privada 4.53.01 inclui um upgrade do Cassandra para a versão 4.0.18.

Upgrades e reversão

  • O upgrade do Cassandra 3.11.X para o Cassandra 4.0.X é um processo tranquilo. O Cassandra 4.0.X, lançado com o Edge para nuvem privada 4.53.00, é compatível com os componentes de gerenciamento e de tempo de execução da nuvem privada 4.52.02.
  • Não é possível fazer um rollback direto no local do Cassandra 4.0.X para o 3.11.X. A reversão usando réplicas ou backups é um procedimento complexo e pode envolver tempo de inatividade e/ou perda de dados. É preferível resolver problemas e fazer upgrade para o Cassandra 4.0.X do que fazer um rollback.
  • É importante conhecer os procedimentos de rollback antes de tentar fazer o upgrade. Considerar as nuances do rollback durante o upgrade é fundamental para garantir que os caminhos de rollback adequados estejam disponíveis.

Data center único

O upgrade do Cassandra da versão 3.11.X para a 4.0.X em um único data center é perfeito, mas a reversão é complexa e pode resultar em tempo de inatividade e perda de dados. Para cargas de trabalho de produção, é altamente recomendável adicionar um novo data center com pelo menos nós do Cassandra disponíveis antes de iniciar o upgrade. Isso vai permitir o rollback do Cassandra sem perda de dados ou interrupção no tráfego da API. Esse data center adicional pode ser desativado quando o upgrade for concluído ou o ponto de verificação 2 for atingido.

Se não for possível adicionar um novo data center, mas ainda for desejável ter a capacidade de rollback, será necessário fazer backups para restaurar o Cassandra 3.11.X. No entanto, esse método provavelmente envolverá inatividade e perda de dados.

Vários data centers

Operar vários data centers com o Edge para nuvem privada 4.52.02 oferece mais flexibilidade para rollbacks durante o upgrade para o Edge para nuvem privada 4.53.00.

  • As reversões dependem de pelo menos um data center executando a versão mais antiga do Cassandra (3.11.X).
  • Se todo o cluster do Cassandra for atualizado para 4.0.X, não será possível reverter para o Cassandra 3.11.X. Você precisa continuar usando a versão mais recente do Cassandra com os outros componentes do Private Cloud 4.53.00 ou 4.52.02.
  1. Faça upgrade de um data center do Cassandra por vez:comece fazendo upgrade dos nós do Cassandra individualmente em um único data center. Conclua os upgrades de todos os nós do Cassandra em um data center antes de passar para o próximo.
  2. Pausar e validar:depois de fazer upgrade de um data center, pause para garantir que o cluster do Private Cloud, especialmente o data center atualizado, esteja funcionando corretamente.
  3. Lembrete:só é possível reverter para a versão anterior do Cassandra se você tiver pelo menos um data center ainda executando a versão mais antiga.
  4. Sensível ao tempo:é possível pausar por um curto período (algumas horas são recomendadas) para validar a funcionalidade, mas não é possível permanecer em um estado de versão mista indefinidamente. Isso ocorre porque um cluster do Cassandra não uniforme (com nós em versões diferentes) tem limitações operacionais.
  5. Testes completos:a Apigee recomenda fazer testes abrangentes de desempenho e funcionalidade antes de atualizar o próximo data center. Depois que todos os data centers forem atualizados, não será possível reverter para a versão anterior.
Reversão como um processo de dois checkpoints
  1. Ponto de verificação 1:o estado inicial, com todos os componentes na versão 4.52.02. É possível fazer um rollback completo desde que pelo menos um data center do Cassandra permaneça na versão mais antiga.
  2. Ponto de verificação 2:depois que todos os nós do Cassandra em todos os data centers forem atualizados. É possível reverter para esse estado, mas não para o ponto de verificação 1.
Exemplo

Considere um cluster de dois data centers (DCs):

  1. Estado inicial:os nós do Cassandra em ambos os DCs estão na versão 3.11.X. Todos os outros nós estão na versão 4.52.02 do Edge para nuvem privada. Suponha três nós do Cassandra por DC.
  2. Fazer upgrade do DC-1:faça upgrade dos três nós do Cassandra no DC-1 um por um.
  3. Pausar e validar:pause para garantir que o cluster, principalmente o DC-1, esteja funcionando corretamente. Verifique o desempenho e a funcionalidade. É possível reverter para o estado inicial usando os nós do Cassandra em DC-2. Lembre-se de que essa pausa precisa ser temporária devido às limitações de um cluster do Cassandra de versão mista.
  4. Fazer upgrade do DC-2:faça upgrade dos três nós restantes do Cassandra no DC-2. Esse será seu novo ponto de verificação de reversão.
  5. Fazer upgrade de outros componentes:faça upgrade dos nós de gerenciamento, de tempo de execução e de análise como de costume em todos os data centers, um nó e um data center por vez. Se surgirem problemas, você poderá reverter para o estado da etapa 4.

Pré-requisitos para o upgrade do Cassandra

Você precisa executar o Cassandra 3.11.16 com o Edge para nuvem privada 4.52.02 e garantir o seguinte:
  1. Todo o cluster está operacional e totalmente funcional com o Cassandra 3.11.16.
  2. A estratégia de compactação está definida como LeveledCompactionStrategy, um pré-requisito para o upgrade para a versão 4.52.02.

  3. Confirme se cada etapa abaixo foi concluída como parte do upgrade inicial do Cassandra 3.11 no Edge para nuvem privada 4.52.02.

    • O comando post_upgrade foi executado em cada nó do Cassandra durante o upgrade anterior.
    • O comando drop_old_tables foi executado em todo o cluster do Cassandra durante o upgrade anterior.

Se você não tiver certeza de que os comandos post_upgrade e drop_old_tables foram executados no Cassandra 3.11 ao usar o Edge para nuvem privada 4.52.02, execute-os novamente antes de tentar o upgrade para 4.53.01.

Etapa 1: preparar para o upgrade

As etapas abaixo são adicionais aos arquivos padrão que você normalmente cria, como o arquivo de configuração padrão da Apigee para ativar upgrades de componentes.

  1. Faça backup do Cassandra usando o Apigee.
  2. Faça snapshots de VM dos nós do Cassandra (se possível).
  3. Verifique se a porta 9042 está acessível de todos os componentes do Edge para nuvem privada, incluindo o servidor de gerenciamento, o processador de mensagens, o roteador, o Qpid e o Postgres, para os nós do Cassandra, se ainda não estiver configurada. Consulte os requisitos de porta para mais informações.

Etapa 2: fazer upgrade de todos os nós do Cassandra

Todos os nós do Cassandra precisam ser atualizados um por um em cada data center, um data center por vez. Entre os upgrades de nós em um data center, aguarde alguns minutos para garantir que um nó atualizado tenha sido totalmente iniciado e ingressado no cluster antes de fazer upgrade de outro nó no mesmo data center.

Depois de fazer upgrade em todos os nós do Cassandra em um data center, aguarde algum tempo (de 30 minutos a algumas horas) antes de continuar com os nós no próximo data center. Durante esse período, revise completamente o data center atualizado e verifique se as métricas funcionais e de performance do cluster do Apigee estão intactas. Essa etapa é crucial para garantir a estabilidade do data center em que o Cassandra foi atualizado para a versão 4.0.X, enquanto o restante dos componentes do Apigee permanece na versão 4.52.02.

  1. Para fazer upgrade de um nó do Cassandra, execute o seguinte comando: 
    /opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
  2. Depois que um nó for atualizado, execute o comando a seguir nele para fazer algumas validações antes de continuar: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra validate_upgrade -f configFile
  3. O comando acima vai gerar algo como: 
    Cassandra version is verified - [cqlsh 6.0.0 | Cassandra 4.0.18 | CQL spec 3.4.5 | Native protocol v5] 
Metadata is verified
  4. Execute o seguinte comando post_upgrade no nó do Cassandra: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra post_upgrade
  5. Execute os seguintes comandos do nodetool para recriar índices no nó do 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
     Se você estiver usando a monetização, execute também os seguintes comandos de recriação de índices relacionados aos keyspaces de monetização: 
    /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

Etapa 3: fazer upgrade de todos os nós de gerenciamento

Faça upgrade de todos os nós de gerenciamento em todas as regiões, um por um:

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

Etapa 4: fazer upgrade de todos os nós de execução

Faça upgrade de todos os nós de roteadores e processadores de mensagens em todas as regiões, um por um:

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

Etapa 5: fazer upgrade de todos os componentes restantes do Edge para nuvem privada 4.53.01

Faça upgrade de todos os nós edge-qpid-server e edge-postgres-server restantes em todas as regiões, um por um.

Upgrade necessário para o Zookeeper 3.8.4

Esta versão do Edge para nuvem privada inclui uma atualização para o Zookeeper 3.8.4. Como parte dessa atualização, todos os dados do Zookeeper serão migrados para o Zookeeper 3.8.4.

Antes de fazer upgrade do Zookeeper, leia o guia de manutenção do Zookeeper. A maioria dos sistemas de produção do Edge usa um cluster de nós do Zookeeper distribuídos em vários data centers. Alguns desses nós são configurados como eleitores que participam da eleição de líder do Zookeeper, e o restante é configurado como observadores. Consulte Sobre líderes, seguidores, eleitores e observadores para mais detalhes. Os nós eleitores escolhem um líder, e depois se tornam seguidores.

Durante o processo de atualização, pode haver um atraso momentâneo ou uma falha de gravação no Zookeeper quando o nó principal é desligado. Isso pode afetar operações de gerenciamento que gravam no Zookeeper, como a operação de implantação de um proxy, e mudanças na infraestrutura da Apigee, como adição ou remoção de um processador de mensagens etc. Não deve haver impacto nas APIs de tempo de execução da Apigee (a menos que essas APIs de tempo de execução chamem APIs de gerenciamento) durante o upgrade do Zookeeper enquanto segue o procedimento abaixo.

De forma geral, o processo de upgrade envolve fazer um backup de cada nó. Em seguida, todos os observadores e seguidores são atualizados, e por fim, o nó líder.

Fazer um backup

Faça um backup de todos os nós do Zookeeper para usar caso seja necessário um rollback. Uma reversão restaura o Zookeeper para o estado em que estava quando o backup foi feito. Observação:implantações ou mudanças na infraestrutura do Apigee desde que o backup foi feito (cujas informações são armazenadas no Zookeeper) serão perdidas durante a restauração. 

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

Se você estiver usando máquinas virtuais e tiver a capacidade, também será possível fazer snapshots ou backups de VMs para restauração ou rollback (se necessário).

Identificar líderes, seguidores e observadores

Observação:os comandos de exemplo abaixo usam o utilitário nc para enviar dados ao Zookeeper. Você também pode usar utilitários alternativos para enviar dados ao Zookeeper.

  1. Se ele não estiver instalado no nó do ZooKeeper, instale o nc: 
      sudo yum install nc
  2. Execute o comando nc a seguir no nó, em que 2181 é a porta do ZooKeeper: 
      echo stat | nc localhost 2181

    O resultado será assim:

      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

    Na linha Mode da saída dos nós, você vai encontrar "observer", "leader" ou "follower" (um eleitor que não é o líder), dependendo da configuração do nó. Observação:em uma instalação independente do Edge com um único nó do ZooKeeper, o Mode é definido como independente.

  3. Repita as etapas 1 e 2 em cada nó do ZooKeeper.

Fazer upgrade do Zookeeper nos nós observador e seguidor

Faça upgrade do Zookeeper em cada um dos nós observador e seguidor da seguinte maneira:

  1. Faça o download e execute o bootstrap do Edge para nuvem privada 4.53.01, conforme descrito em Atualizar para 4.53.01 em um nó com uma conexão externa de Internet. O processo provavelmente vai variar dependendo se o nó tem uma conexão de Internet externa ou se você está fazendo uma instalação off-line.
  2. Faça upgrade do componente Zookeeper: 
      /opt/apigee/apigee-setup/bin/update.sh -c zk -f <silent-config-file>
     Observação:se esses nós tiverem outros componentes instalados (como o Cassandra), você poderá fazer upgrade deles agora também (como com o perfil cs,zk) ou poderá fazer upgrade dos outros componentes mais tarde. A Apigee recomenda que você faça upgrade do Zookeeper primeiro e verifique se o cluster está funcionando corretamente antes de fazer upgrade de outros componentes.
  3. Repita as etapas acima em cada um dos nós observador e seguidor do Zookeeper.

Desligar o líder

Depois que todos os nós de observador e seguidor forem atualizados, desligue o líder. No nó identificado como líder, execute o comando abaixo: 

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

Durante esse evento, antes da eleição de um novo líder, pode haver atrasos momentâneos ou falhas de gravação no Zookeeper. Isso pode afetar operações que gravam no Zookeeper, como a ação de implantação de proxies ou mudanças na infraestrutura do Apigee, como adição ou remoção de processadores de mensagens etc.

Verifique se o novo líder foi eleito

Usando as etapas na seção Identificar líder, seguidores e observadores acima, verifique se um novo líder foi eleito entre os seguidores depois que o líder atual for interrompido. O líder pode ter sido eleito em um data center diferente do atual.

Líder de upgrade

Siga as mesmas etapas em Fazer upgrade do Zookeeper nos nós observador e seguidor acima.

Depois que o nó líder antigo também for atualizado, verifique a integridade do cluster e confirme se há um nó líder.

Upgrade do Nginx 1.26 no Edge-Router

O upgrade para o Edge para nuvem privada 4.53.01 de versões anteriores não atualiza automaticamente o software Nginx para a versão mais recente (1.26.x). Isso evita efeitos colaterais acidentais no tempo de execução como resultado das mudanças documentadas em Mudanças do Nginx 1.26 no Apigee Edge 4.53.01. É possível fazer upgrade manual do Nginx da versão 1.20.x para a 1.26.x após a verificação em ambientes inferiores. Para fazer upgrade manualmente:

  1. Verifique se o nó do roteador de borda tem o software 4.53.01 mais recente.

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

  2. Verifique a versão do Nginx que você está executando

    /opt/nginx/sbin/nginx -V

    Se você estiver usando uma versão mais antiga do Nginx, siga as etapas abaixo para fazer upgrade para a versão 1.26.X no nó do roteador.

  3. Interromper o processo do roteador de borda no nó do roteador

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

  4. Fazer upgrade do software nginx no nó do roteador

    dnf update apigee-nginx

  5. Verificar se a versão do Nginx foi atualizada

    /opt/nginx/sbin/nginx -V

  6. Iniciar o processo de roteador no nó

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

  7. Repita o processo em cada nó de roteador, um de cada vez.

Upgrade necessário para o Postgres 17

Esta versão do Edge inclui um upgrade para o Postgres 17. Como parte desse upgrade, todos os dados do Postgres serão migrados para o Postgres 17.

A maioria dos sistemas de produção do Edge usa dois nós do Postgres configurados para replicação mestre-standby. Durante o processo de atualização, enquanto os nós do Postgres estão inativos para atualização, os dados de análise ainda são gravados nos nós do Qpid. Depois que os nós do Postgres são atualizados e voltam a ficar on-line, os dados de análise são enviados para eles.

A forma como você realiza a atualização do Postgres depende de como configurou o armazenamento de dados para os nós do Postgres:

  • Se você usa armazenamento de dados local para os nós do Postgres, instale um novo nó de espera do Postgres durante a atualização. Depois que o upgrade for concluído, será possível desativar o novo nó de espera do Postgres.

    O nó de espera adicional do Postgres é necessário se você precisar reverter a atualização por qualquer motivo. Se for necessário reverter a atualização, o novo nó de espera do Postgres se tornará o nó principal do Postgres após a reversão. Portanto, ao instalar o novo nó de espera do Postgres, ele precisa estar em um nó que atenda a todos os requisitos de hardware de um servidor Postgres, conforme definido em Requisitos de instalação do Edge.

    Em uma configuração de 1 nó e 2 nós do Edge, topologias usadas para prototipagem e teste, você tem apenas um nó do Postgres. É possível atualizar esses nós do Postgres diretamente sem precisar criar um novo.

  • Se você usa armazenamento de rede para seus nós do Postgres, conforme recomendado pela Apigee, não é necessário instalar um novo nó do Postgres. Nos procedimentos abaixo, você pode pular as etapas que especificam a instalação e a desativação de um novo nó de espera do Postgres.

    Antes de iniciar o processo de atualização, tire um snapshot de rede do repositório de dados usado pelo PostgreSQL. Em seguida, se ocorrerem erros durante a atualização e você precisar fazer um rollback, será possível restaurar o nó do Postgres desse snapshot.

Instalar um novo nó de espera do Postgres

Esse procedimento cria um servidor standby do Postgres em um novo nó. Instale um novo servidor standby do Postgres para sua versão atual do Edge (4.52.02 ou 4.53.00), não para a versão 4.53.01.

Para fazer a instalação, use o mesmo arquivo de configuração usado para instalar a versão atual do Edge.

Para criar um novo nó de espera do Postgres:

  1. No mestre do Postgres atual, edite o arquivo /opt/apigee/customer/application/postgresql.properties para definir o seguinte token. Se esse arquivo não existir, crie-o: 
    conf_pg_hba_replication.connection=host replication apigee existing_standby_ip/32 trust\ \nhost replication apigee new_standby_ip/32 trust

    Em que existing_standby_ip é o endereço IP do servidor standby atual do Postgres e new_standby_ip é o endereço IP do novo nó standby.

  2. Reinicie o apigee-postgresql no mestre do Postgres: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart
  3. Verifique se o novo nó em espera foi adicionado visualizando o arquivo /opt/apigee/apigee-postgresql/conf/pg_hba.conf no mestre. Você vai ver as seguintes linhas no arquivo: 
    host replication apigee existing_standby_ip/32 trust
host replication apigee new_standby_ip/32 trust
  4. Instale o novo servidor standby do Postgres:
    1. Edite o arquivo de configuração usado para instalar a versão atual do Edge e especifique o seguinte: 
      # 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. Desative o SELinux conforme descrito em Instalar o utilitário apigee-setup do Edge.

    3. Se você estiver usando o Edge 4.52.02:

      1. Faça o download do arquivo Edge bootstrap_4.52.02.sh para /tmp/bootstrap_4.52.02.sh : 
        curl https://software.apigee.com/bootstrap_4.52.02.sh -o /tmp/bootstrap_4.51.00.sh
      2. Instale o utilitário e as dependências do Edge apigee-service: 
        sudo bash /tmp/bootstrap_4.52.02.sh apigeeuser=uName apigeepassword=pWord

      Se você estiver na versão 4.53.00 do Edge:

      1. Faça o download do arquivo Edge bootstrap_4.53.00.sh para /tmp/bootstrap_4.53.00.sh : 
        curl https://software.apigee.com/bootstrap_4.53.00.sh -o /tmp/bootstrap_4.53.00.sh
      2. Instale o utilitário e as dependências do Edge apigee-service: 
        sudo bash /tmp/bootstrap_4.53.00.sh apigeeuser=uName apigeepassword=pWord
    4. Use apigee-service para instalar o utilitário apigee-setup: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-setup install
    5. Instale o Postgres: 
      /opt/apigee/apigee-setup/bin/setup.sh -p ps -f configFile
    6. No novo nó em espera, execute o seguinte comando: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-standby

      Verifique se é o standby.

Como fazer um upgrade no local do Postgres

Observação:é necessário realizar a seguinte etapa preliminar antes de fazer um upgrade in-loco do Postgres.

Etapa preliminar

Antes de fazer um upgrade local para o Postgres, siga estas etapas no host principal e no standby para atualizar a propriedade max_locks_per_transaction em apigee-postgresql:

  1. Se ele não estiver presente, crie o arquivo /opt/apigee/customer/application/postgresql.properties.
  2. Mude a propriedade do arquivo para apigee: 
    sudo chown apigee:apigee /opt/apigee/customer/application/postgresql.properties
  3. Adicione a seguinte propriedade ao arquivo: 
    conf/postgresql.conf+max_locks_per_transaction=30000
  4. Configurar apigee-postgresql: 
    apigee-service apigee-postgresql configure
  5. Restart apigee-postgresql: 
    apigee-service apigee-postgresql restart

Realizar o upgrade no local

Para fazer um upgrade no local para o Postgres 17, siga estas etapas:

  1. Fazer upgrade do postgres no host mestre 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f /opt/silent.conf
  2. Execute o comando de configuração no host principal: 
    apigee-service apigee-postgresql setup -f /opt/silent.conf
  3. Execute o comando de configuração no host principal: 
    apigee-service apigee-postgresql configure
  4. Reinicie o host principal: 
    apigee-service apigee-postgresql restart
  5. Configure como mestre: 
    apigee-service apigee-postgresql setup-replication-on-master -f /opt/silent.conf
  6. Verifique se o host principal foi iniciado: 
    apigee-service apigee-postgresql wait_for_ready
  7. Interrompa o modo de espera: 
    apigee-service apigee-postgresql stop
  8. Faça upgrade do standby.

    Observação:se esta etapa gerar erros ou falhar, ignore-a. O update.sh vai tentar iniciar o servidor de espera com uma configuração incorreta. Desde que a instalação do Postgres seja atualizada para a versão 17, o erro pode ser ignorado.

    /opt/apigee/apigee-setup/bin/update.sh -c ps -f /opt/silent.conf
  9. Verifique se o standby está parado: 
    apigee-service apigee-postgresql stop
  10. Remova a configuração de espera antiga: 
    rm -rf /opt/apigee/data/apigee-postgresql/
  11. Configure a replicação no servidor em espera: 
    apigee-service apigee-postgresql setup-replication-on-standby -f /opt/silent.conf
  12. Remova a linha conf/postgresql.conf+max_locks_per_transaction=30000 do arquivo /opt/apigee/customer/application/postgresql.properties no host principal e no standby. Essa linha foi adicionada na etapa preliminar.

Depois de concluir esse procedimento, o modo de espera será iniciado.

Desativação de um nó do Postgres

Depois que a atualização for concluída, desative o novo nó em espera:

  1. Verifique se o Postgres está em execução: 
    /opt/apigee/apigee-service/bin/apigee-all status

    Se o Postgres não estiver em execução, inicie-o: 

    /opt/apigee/apigee-service/bin/apigee-all start
  2. Para receber o UUID do novo nó em espera, execute o seguinte comando curl no novo nó em espera: 
    curl -u sysAdminEmail:password http://node_IP:8084/v1/servers/self

    Você vai ver o UUID do nó no final da saída, no formato: 

    "type" : [ "postgres-server" ],
"uUID" : "599e8ebf-5d69-4ae4-aa71-154970a8ec75"
  3. Pare o novo nó em espera executando o seguinte comando nele: 
    /opt/apigee/apigee-service/bin/apigee-all stop
  4. No nó mestre do Postgres, edite /opt/apigee/customer/application/postgresql.properties para remover o novo nó de espera de conf_pg_hba_replication.connection: 
    conf_pg_hba_replication.connection=host replication apigee existing_standby_ip/32 trust
  5. Reinicie o apigee-postgresql no mestre do Postgres: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart
  6. Verifique se o novo nó em espera foi removido acessando o arquivo /opt/apigee/apigee-postgresql/conf/pg_hba.conf no mestre. Você vai ver apenas a seguinte linha no arquivo: 
    host replication apigee existing_standby_ip/32 trust
  7. Exclua o UUID do nó em espera do ZooKeeper fazendo a seguinte chamada de API de gerenciamento do Edge no nó do servidor de gerenciamento: 
    curl -u sysAdminEmail:password -X DELETE http://ms_IP:8080/v1/servers/new_standby_uuid

Etapas pós-upgrade para o Postgres

Depois de um upgrade importante do Postgres, as estatísticas internas dele são apagadas. Essas estatísticas ajudam o planejador de consultas do Postgres a usar os índices e caminhos mais adequados para executar consultas.

O Postgres pode reconstruir gradualmente as estatísticas ao longo do tempo à medida que as consultas são executadas e quando o daemon autovacuum é executado. No entanto, até que as estatísticas sejam recriadas, suas consultas podem ficar lentas.

Para resolver esse problema, execute ANALYZE em todas as tabelas do banco de dados no nó principal do Postgres. Outra opção é executar ANALYZE para algumas tabelas por vez.

Etapas para atualizar o Apigee SSO de versões mais antigas

No Edge para nuvem privada 4.53.01, as chaves e os certificados do IDP usados no componente apigee-sso agora são configurados por um keystore. Você precisará exportar a chave e o certificado usados anteriormente para um keystore, configurá-lo e continuar com a atualização do SSO normalmente.

  1. Identifique a chave e o certificado atuais usados para configurar o IdP:

    1. Recupere o certificado pesquisando o valor de SSO_SAML_SERVICE_PROVIDER_CERTIFICATE no arquivo de configuração de instalação do SSO ou consultando o componente apigee-sso para conf_login_service_provider_certificate.

      Use o comando a seguir no nó de SSO para consultar apigee-sso e encontrar o caminho do certificado do IdP. Na saída, procure o valor na última linha. 

      apigee-service apigee-sso configure -search conf_login_service_provider_certificate

    2. Para recuperar a chave, procure o valor de SSO_SAML_SERVICE_PROVIDER_KEY no arquivo de configuração de instalação do SSO ou consulte o componente apigee-sso para conf_login_service_provider_key.

      Use o seguinte comando no nó de SSO para consultar apigee-sso e encontrar o caminho da chave do IdP. Na saída, procure o valor na última linha.

      apigee-service apigee-sso configure -search conf_login_service_provider_key
  2. Exporte a chave e o certificado para um keystore:
    1. Exporte a chave e o certificado para um keystore PKCS12: 
      sudo openssl pkcs12 -export -clcerts -in <certificate_path> -inkey <key_path> -out <keystore_path> -name <alias>

      Parâmetros:

      • certificate_path: caminho para o arquivo de certificado recuperado na etapa 1.a.
      • key_path: caminho para o arquivo de chave privada recuperado na etapa 1.b.
      • keystore_path: caminho para o keystore recém-criado que contém o certificado e a chave privada.
      • alias: alias usado para o par de chaves e certificados no keystore.

      Consulte a documentação do OpenSSL para mais detalhes.

    2. (Opcional) Exporte a chave e o certificado do PKCS12 para um keystore JKS: 
      sudo keytool -importkeystore -srckeystore <PKCS12_keystore_path> -srcstoretype PKCS12 -destkeystore <destination_keystore_path> -deststoretype JKS -alias <alias>

      Parâmetros:

      • PKCS12_keystore_path: caminho para o keystore PKCS12 criado na etapa 2.a, que contém o certificado e a chave.
      • destination_keystore_path: caminho para o novo keystore JKS em que o certificado e a chave serão exportados.
      • alias: alias usado para o par de chaves e certificados no keystore JKS.

      3. Consulte a documentação do keytool para mais detalhes.

  3. Mude o proprietário do arquivo de keystore de saída para o usuário "apigee": 
    sudo chown apigee:apigee <keystore_file>
  4. Adicione as seguintes propriedades no arquivo de configuração do SSO da Apigee e atualize-as com o caminho do arquivo de keystore, a senha, o tipo de keystore e o 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. Atualize o software do SSO da Apigee no nó de SSO normalmente usando o seguinte comando: 
    /opt/apigee/apigee-setup/bin/update.sh -c sso -f /opt/silent.conf

Nova interface do Edge

Esta seção lista considerações sobre a interface do Edge. Para mais informações, consulte A nova interface do Edge para nuvem privada.

Instalar a interface do Edge

Depois de concluir a instalação inicial, a Apigee recomenda que você instale a interface do Edge, que é uma interface do usuário aprimorada para desenvolvedores e administradores do Apigee Edge para nuvem privada.

A interface do Edge exige que você desative a autenticação básica e use um IDP, como SAML ou LDAP.

Para mais informações, consulte Instalar a nova interface do Edge.

Atualizar com mTLS da Apigee

Para atualizar o mTLS do Apigee , siga estas etapas:

Como reverter uma atualização

Em caso de falha na atualização, tente corrigir o problema e execute update.sh novamente. É possível executar a atualização várias vezes, e ela continua de onde parou.

Se a falha exigir que você reverta a atualização para a versão anterior, consulte Reverter para a versão 4.53.01 para instruções detalhadas.

Informações de atualização do Logging

Por padrão, o utilitário update.sh grava informações de registro em:

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

Se a pessoa que executa o utilitário update.sh não tiver acesso a esse diretório, o registro será gravado no diretório /tmp como um arquivo chamado update_username.log.

Se a pessoa não tiver acesso a /tmp, o utilitário update.sh vai falhar.

Atualização sem inatividade

Uma atualização sem inatividade, ou atualização gradual, permite atualizar a instalação do Edge sem interromper o Edge.

A atualização sem tempo de inatividade só é possível com uma configuração de cinco nós ou mais.

A chave para o upgrade sem tempo de inatividade é remover cada roteador, um de cada vez, do balanceador de carga. Em seguida, atualize o roteador e todos os outros componentes na mesma máquina que ele e adicione o roteador de volta ao balanceador de carga.

  1. Atualize as máquinas na ordem correta para sua instalação, conforme descrito em Ordem de atualização da máquina.
  2. Quando for a hora de atualizar os roteadores, selecione um deles e deixe-o inacessível, conforme descrito em Ativar/desativar a acessibilidade do servidor (processador de mensagens/roteador).
  3. Atualize o roteador selecionado e todos os outros componentes do Edge na mesma máquina que o roteador. Todas as configurações do Edge mostram um roteador e um processador de mensagens no mesmo nó.
  4. Faça com que o roteador fique acessível novamente.
  5. Repita as etapas de 2 a 4 para os outros roteadores.
  6. Continue a atualização para as máquinas restantes na instalação.

Antes e depois da atualização, faça o seguinte:

Usar um arquivo de configuração silenciosa

É necessário transmitir um arquivo de configuração silenciosa para o comando de atualização. O arquivo de configuração silencioso precisa ser o mesmo usado para instalar o Edge para nuvem privada 4.52.02 ou 4.53.00.

Atualizar para 4.53.01 em um nó com uma conexão de Internet externa

Use o procedimento a seguir para atualizar os componentes do Edge em um nó:

  1. Se houver, desative todos os jobs cron configurados para realizar uma operação de correção no Cassandra até que a atualização seja concluída.
  2. Faça login no nó como raiz para instalar os RPMs do Edge.
  3. Desative o SELinux conforme descrito em Instalar o utilitário apigee-setup do Edge.
  4. Se você estiver instalando na AWS, execute os seguintes comandos 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. Se você estiver usando o Edge 4.52.02 ou 4.53.00:

    1. Faça o download do arquivo bootstrap_4.53.01.sh do Edge em /tmp/bootstrap_4.53.01.sh: 
      curl https://software.apigee.com/bootstrap_4.53.01.sh -o /tmp/bootstrap_4.53.01.sh
    2. Instale o utilitário apigee-service e as dependências do Edge 4.53.01 executando o seguinte comando: 
      sudo bash /tmp/bootstrap_4.53.01.sh apigeeuser=uName apigeepassword=pWord

      Em que uName:pWord são o nome de usuário e a senha que você recebeu da Apigee. Se você omitir pWord, será solicitado a inserir esse valor.

      Por padrão, o instalador verifica se você tem o Java 1.8 instalado. Caso contrário, o instalador vai fazer isso para você.

      Use a opção JAVA_FIX para especificar como lidar com a instalação do Java. JAVA_FIX usa os seguintes valores:

      • I: instale o OpenJDK 1.8 (padrão).
      • C: continue sem instalar o Java.
      • Q: sair. Para essa opção, você precisa instalar o Java.
    3. Use apigee-service para atualizar o utilitário apigee-setup, conforme mostra o exemplo a seguir: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-setup update
    4. Atualize o utilitário apigee-validate no servidor de gerenciamento, como mostra o exemplo a seguir: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-validate update
    5. Atualize o utilitário apigee-provision no servidor de gerenciamento, como mostra o exemplo a seguir: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-provision update
    6. Execute o utilitário update nos nós com o seguinte comando: 
      /opt/apigee/apigee-setup/bin/update.sh -c component -f configFile

      Faça isso na ordem descrita em Ordem da atualização da máquina.

      Em que:

      • component é o componente do Edge a ser atualizado. Os valores possíveis são:
        • cs: Cassandra
        • edge: todos os componentes do Edge, exceto a interface do Edge: servidor de gerenciamento, processador de mensagens, roteador, servidor QPID, servidor Postgres.
        • ldap: OpenLDAP
        • ps: postgresql
        • qpid: qpidd
        • sso: Apigee SSO (se você instalou o SSO)
        • ue: nova interface do Edge
        • ui: interface clássica do Edge
        • zk: Zookeeper
      • configFile é o mesmo arquivo de configuração usado para definir os componentes do Edge durante a instalação da versão 4.52.02 ou 4.53.00.

      Você pode executar update.sh em todos os componentes definindo component como "all", mas apenas se tiver um perfil de instalação do Edge tudo em um (AIO). Exemplo:

      /opt/apigee/apigee-setup/bin/update.sh -c all -f ./sa_silent_config
    7. Reinicie os componentes da interface do Edge em todos os nós que os executam, caso ainda não tenha feito isso: 
      /opt/apigee/apigee-service/bin/apigee-service [edge-management-ui|edge-ui] restart
    8. Teste a atualização executando o utilitário apigee-validate no servidor de gerenciamento, conforme descrito em Testar a instalação.

Se você decidir reverter a atualização mais tarde, use o procedimento descrito em Reverter para a versão 4.53.01.

Atualizar para a versão 4.53.01 de um repositório local

Se os nós do Edge estiverem atrás de um firewall ou proibidos de acessar o repositório do Apigee pela Internet, será possível fazer a atualização de um repositório local, ou espelho, do repositório do Apigee.

Depois de criar um repositório local do Edge, você tem duas opções para atualizar o Edge no repositório local:

  • Crie um arquivo .tar do repositório, copie-o para um nó e atualize o Edge com ele.
  • Instale um servidor da Web no nó com o repositório local para que outros nós possam acessá-lo. A Apigee fornece o servidor da Web Nginx para você usar, ou você pode usar seu próprio servidor da Web.

Para atualizar de um repositório local 4.53.01:

  1. Crie um repositório local 4.53.01 conforme descrito em "Criar um repositório local da Apigee" em Instalar o utilitário apigee-setup do Edge.
  2. Para instalar o apigee-service de um arquivo .tar:
    1. No nó com o repositório local, use o comando a seguir para empacotar o repositório local em um único arquivo .tar chamado /opt/apigee/data/apigee-mirror/apigee-4.53.01.tar.gz: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-mirror package
    2. Copie o arquivo .tar para o nó em que você quer atualizar o Edge. Por exemplo, copie para o diretório /tmp no novo nó.
    3. No novo nó, descompacte o arquivo no diretório /tmp: 
      tar -xzf apigee-4.53.01.tar.gz

      Esse comando cria um novo diretório, chamado repos, no diretório que contém o arquivo .tar. Por exemplo, /tmp/repos.

    4. Instale o utilitário apigee-service do Edge e as dependências de /tmp/repos: 
      sudo bash /tmp/repos/bootstrap_4.53.01.sh apigeeprotocol="file://" apigeerepobasepath=/tmp/repos

      Observe que você inclui o caminho para o diretório "repos" nesse comando.

  3. Para instalar o apigee-service usando o servidor da Web Nginx:
    1. Configure o servidor da Web Nginx conforme descrito em "Instalar do repositório usando o servidor da Web Nginx" em Instalar o utilitário apigee-setup do Edge.
    2. No nó remoto, faça o download do arquivo bootstrap_4.53.01.sh do Edge para /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

      Em que uName:pWord são o nome de usuário e a senha definidos anteriormente para o repositório, e remoteRepo é o endereço IP ou o nome DNS do nó do repositório.

    3. No nó remoto, instale o utilitário e as dependências do Edge apigee-setup: 
      sudo bash /tmp/bootstrap_4.53.01.sh apigeerepohost=remoteRepo:3939 apigeeuser=uName apigeepassword=pWord apigeeprotocol=http://

      Em que uName:pWord são o nome de usuário e a senha do repositório.

  4. Use apigee-service para atualizar o utilitário apigee-setup, como mostra o exemplo a seguir: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-setup update
  5. Atualize o utilitário apigee-validate no servidor de gerenciamento, como mostra o exemplo a seguir: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-validate update
  6. Atualize o utilitário apigee-provision no servidor de gerenciamento, como mostra o exemplo a seguir: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-provision update
  7. Execute o utilitário update nos nós na ordem descrita em Ordem de atualização da máquina: 
    /opt/apigee/apigee-setup/bin/update.sh -c component -f configFile

    Em que:

    • component é o componente do Edge a ser atualizado. Normalmente, você atualiza os seguintes componentes:
      • cs: Cassandra
      • edge: todos os componentes do Edge, exceto a interface do Edge: servidor de gerenciamento, processador de mensagens, roteador, servidor QPID e servidor Postgres.
      • ldap: OpenLDAP
      • ps: postgresql
      • qpid: qpidd
      • sso: Apigee SSO (se você instalou o SSO)
      • ue Nova interface do Edge
      • ui: interface clássica do Edge
      • zk: Zookeeper
    • configFile é o mesmo arquivo de configuração usado para definir os componentes do Edge durante a instalação das versões 4.52.02 ou 4.53.00.

    Você pode executar update.sh em todos os componentes definindo component como "all", mas apenas se tiver um perfil de instalação do Edge all-in-one (AIO). Exemplo:

    /opt/apigee/apigee-setup/bin/update.sh -c all -f /tmp/sa_silent_config
  8. Reinicie os componentes da interface em todos os nós que a executam, caso ainda não tenha feito isso: 
    /opt/apigee/apigee-service/bin/apigee-service [edge-management-ui|edge-ui] restart
  9. Teste a atualização executando o utilitário apigee-validate no servidor de gerenciamento, conforme descrito em Testar a instalação.

Se você decidir reverter a atualização mais tarde, use o procedimento descrito em Reverter para a versão 4.53.01.

Ordem de atualização da máquina

A ordem em que você atualiza as máquinas em uma instalação do Edge é importante:

  • É necessário atualizar todos os nós do LDAP antes de atualizar qualquer outro componente. Você precisa seguir etapas especiais para fazer upgrade do LDAP.
  • Você precisa atualizar todos os nós do Cassandra e do ZooKeeper. Se você estiver fazendo upgrade da versão 4.52.02, siga as etapas especiais para atualizar o Cassandra. Siga as etapas especiais para fazer upgrade do Zookeeper para as versões 4.52.02 ou 4.53.00.
  • É necessário fazer upgrade de todos os servidores de gerenciamento e processadores de mensagens e roteadores usando a opção -c edge para atualizá-los.
  • Faça upgrade de todos os nós do Postgres seguindo as etapas especiais para upgrade do Postgres.
  • É necessário atualizar os componentes edge-qpid-server e edge-postgres-server em todos os data centers.
  • É necessário fazer upgrade de todos os nós do Qpid.
  • É necessário fazer upgrade dos nós da interface do Edge, da nova interface do Edge e dos nós de SSO(se aplicável).
  • Não há uma etapa separada para atualizar a monetização. Ele é atualizado quando você especifica a opção de borda -c.

Upgrade independente de um nó

Para fazer upgrade de uma configuração independente de um nó para a versão 4.53.01:

  1. Atualize todos os componentes: 
    /opt/apigee/apigee-setup/bin/update.sh -c all -f configFile
  2. (Se você instalou o apigee-adminapi) Atualize o utilitário apigee-adminapi: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

Upgrade independente de dois nós

Atualize os seguintes componentes para uma instalação independente de dois nós:

Consulte Topologias de instalação para ver a lista de topologias de Edge e números de nós.

  1. Atualize o LDAP na máquina 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
  2. Atualize o Cassandra e o ZooKeeper na máquina 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
  3. Atualize os componentes do Edge na máquina 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  4. Atualize o Postgres na máquina 2: 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  5. Atualize os componentes do Edge na máquina 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  6. Atualize o Qpid na máquina 2: 
    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  7. Atualize a interface na máquina 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c ui -f configFile
  8. (Se você instalou o apigee-adminapi) Atualize o utilitário apigee-adminapi na máquina 1: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
  9. Se você instalou o Apigee SSO, atualize-o na máquina 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

    Em que sso_config_file é o arquivo de configuração que você criou ao instalar o SSO.

  10. Reinicie o componente da interface do Edge na máquina 1: 
    /opt/apigee/apigee-service/bin/apigee-service edge-ui restart

Upgrade de cinco nós

Atualize os seguintes componentes para uma instalação de cinco nós:

Consulte Topologias de instalação para ver a lista de topologias de borda e números de nós.

  1. Atualize o LDAP na máquina 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
  2. Atualize o Cassandra e o ZooKeeper nas máquinas 1, 2 e 3: 
    /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
  3. Atualize os componentes do Edge nas máquinas 1, 2 e 3: 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  4. Atualize o Postgres na máquina 4: 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  5. Atualize o Postgres na máquina 5: 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  6. Atualize os componentes do Edge nas máquinas 4 e 5: 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  7. Atualize o Qpid na máquina 4: 
    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  8. Atualize o Qpid na máquina 5: 
    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  9. Atualize a interface do Edge:
    • Interface clássica:se você estiver usando a interface clássica, atualize o componente ui na máquina 1, conforme mostrado no exemplo a seguir: 
      /opt/apigee/apigee-setup/bin/update.sh -c ui -f configFile
    • Nova interface do Edge:se você instalou a nova interface do Edge, atualize o componente ue na máquina apropriada (pode não ser a máquina 1): 
      /opt/apigee/apigee-setup/bin/update.sh -c ue -f /opt/silent.conf
  10. (Se você instalou o apigee-adminapi) Atualize o utilitário apigee-adminapi na máquina 1: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
  11. Se você instalou o Apigee SSO, atualize-o na máquina 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

    Em que sso_config_file é o arquivo de configuração que você criou ao instalar o SSO.

  12. Reinicie o componente da interface:
    • Interface clássica:se você estiver usando a interface clássica, reinicie o componente edge-ui na máquina 1, conforme mostrado no exemplo a seguir: 
      /opt/apigee/apigee-service/bin/apigee-service edge-ui restart
    • Nova interface do Edge:se você instalou a nova interface do Edge, reinicie o componente edge-management-ui na máquina apropriada (pode não ser a máquina 1): 
      /opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart

Upgrade de cluster de nove nós

Atualize os seguintes componentes para uma instalação em cluster de nove nós:

Consulte Topologias de instalação para ver a lista de topologias de borda e números de nós.

  1. Atualize o LDAP na máquina 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
  2. Atualize o Cassandra e o ZooKeeper nas máquinas 1, 2 e 3: 
    /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
  3. Atualize os componentes do Edge nas máquinas 1, 4 e 5 (servidor de gerenciamento, processador de mensagens e roteador) nessa ordem: 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  4. Atualize o Postgres na máquina 8: 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  5. Atualize o Postgres na máquina 9: 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  6. Atualize os componentes do Edge nas máquinas 6, 7, 8 e 9 nessa ordem: 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  7. Atualize o Qpid nas máquinas 6 e 7: 
    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  8. Atualize a nova interface (ue) ou a interface clássica (ui) na máquina 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile
  9. (Se você instalou o apigee-adminapi) Atualize o utilitário apigee-adminapi na máquina 1: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
  10. Se você instalou o Apigee SSO, atualize-o na máquina 1: 
    /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

    Em que sso_config_file é o arquivo de configuração que você criou ao instalar o SSO.

  11. Reinicie o componente da interface:
    • Interface clássica:se você estiver usando a interface clássica, reinicie o componente edge-ui na máquina 1, conforme mostrado no exemplo a seguir: 
      /opt/apigee/apigee-service/bin/apigee-service edge-ui restart
    • Nova interface do Edge:se você instalou a nova interface do Edge, reinicie o componente edge-management-ui na máquina apropriada (pode não ser a máquina 1): 
      /opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart

Upgrade de cluster de 13 nós

Atualize os seguintes componentes para uma instalação em cluster de 13 nós:

Consulte Topologias de instalação para ver a lista de topologias de Edge e números de nós.

  1. Atualize o LDAP nas máquinas 4 e 5: 
    /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
  2. Atualize o Cassandra e o ZooKeeper nas máquinas 1, 2 e 3: 
    /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
  3. Atualize os componentes do Edge nas máquinas 6, 7, 10 e 11 nessa ordem: 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  4. Atualize o Postgres na máquina 8: 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  5. Atualize o Postgres na máquina 9: 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  6. Atualize os componentes do Edge nas máquinas 12, 13, 8 e 9 nessa ordem: 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  7. Atualize o Qpid nas máquinas 12 e 13: 
    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  8. Atualize a nova interface (ue) ou a interface clássica (ui) nas máquinas 6 e 7: 
    /opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile
  9. (Se você instalou o apigee-adminapi) Atualize o utilitário apigee-adminapi nas máquinas 6 e 7: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
  10. (Se você instalou o Apigee SSO) Atualize o Apigee SSO nas máquinas 6 e 7: 
    /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

    Em que sso_config_file é o arquivo de configuração que você criou ao instalar o SSO.

  11. Reinicie o componente da interface:
    • Interface clássica:se você estiver usando a interface clássica, reinicie o componente edge-ui nas máquinas 6 e 7, conforme mostrado no exemplo a seguir: 
      /opt/apigee/apigee-service/bin/apigee-service edge-ui restart
    • Nova interface do Edge:se você instalou a nova interface do Edge, reinicie o componente edge-management-ui nas máquinas 6 e 7: 
      /opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart

Upgrade de cluster de 12 nós

Atualize os seguintes componentes para uma instalação em cluster de 12 nós:

Consulte Topologias de instalação para ver a lista de topologias de borda e números de nós.

  1. Atualizar LDAP:
    1. Máquina 1 no data center 1 
      /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
    2. Máquina 7 no data center 2 
      /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
  2. Atualize o Cassandra e o ZooKeeper:
    1. Máquinas 1, 2 e 3 no data center 1: 
      /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
    2. Nas máquinas 7, 8 e 9 do data center 2: 
      /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
  3. Atualize os componentes do Edge:
    1. Nas máquinas 1, 2 e 3 no data center 1: 
      /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
    2. Nas máquinas 7, 8 e 9 no data center 2 
      /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  4. Atualize o Postgres:
    1. Máquina 6 no data center 1 
      /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
    2. Máquina 12 no data center 2 
      /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  5. Atualize os componentes do Edge:
    1. Máquinas 4, 5 e 6 no data center 1 
      /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
    2. Máquinas 10, 11 e 12 no data center 2 
      /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  6. Atualize o qpidd:
    1. Máquinas 4 e 5 no data center 1
      1. Atualize qpidd na máquina 4: 
        /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
      2. Atualize qpidd na máquina 5: 
        /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
    2. Máquinas 10 e 11 no data center 2
      1. Atualize qpidd na máquina 10: 
        /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
      2. Atualize qpidd na máquina 11: 
        /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  7. Atualize a nova interface (ue) ou a interface clássica (ui):
    1. Máquina 1 no data center 1: 
      /opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile
    2. Máquina 7 no data center 2: 
      /opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile
  8. (Se você instalou o apigee-adminapi) Atualize o utilitário apigee-adminapi:
    1. Máquina 1 no data center 1: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
    2. Máquina 7 no data center 2: 
      /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
  9. (Se você instalou o Apigee SSO) Atualize o Apigee SSO:
    1. Máquina 1 no data center 1: 
      /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file
    2. Máquina 7 no data center 2: 
      /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

      3. Em que sso_config_file é o arquivo de configuração que você criou ao instalar o SSO.

  10. Reinicie o novo componente da interface do Edge (edge-management-ui) ou da interface clássica do Edge (edge-ui) nas máquinas 1 e 7: 
    /opt/apigee/apigee-service/bin/apigee-service [edge-ui|edge-management-ui] restart

Para uma configuração não padrão

Se você tiver uma configuração não padrão, atualize os componentes do Edge na seguinte ordem:

  1. LDAP
  2. Cassandra
  3. Zookeeper
  4. Servidor de gerenciamento
  5. processador de mensagens
  6. Roteador
  7. Postgres
  8. "Edge", ou seja, o perfil "-c edge" em todos os nós na ordem: nós com servidor Qpid, servidor Edge Postgres.
  9. qpidd
  10. IU do Edge (clássica ou nova)
  11. apigee-adminapi
  12. SSO da Apigee

Depois de concluir a atualização, reinicie o componente da interface do Edge em todas as máquinas que o executam.