Se você encontrar um erro durante uma atualização para o Edge 4.52.02, poderá reverter o componente que causou o erro e tentar a atualização novamente.
É possível reverter o Edge 4.52.02 para qualquer uma das seguintes versões principais:
- Versão 4.52.01
- Versão 4.52.00
- Versão 4.51.00
O downgrade de uma versão envolve o downgrade de todos os componentes que você pode ter atualizado. Além disso, com base na versão inicial, talvez seja necessário seguir etapas especiais antes de reverter determinados componentes de software. A tabela a seguir lista os vários componentes de software para os quais etapas especiais podem ser necessárias durante a reversão:
| Reverter para a versão | Consideração especial para software |
|---|---|
| 4.52.01 | Cassandra |
| 4.52.00 | Zookeeper, Cassandra, Qpid |
| 4.51.00 | Zookeeper, Postgres, Cassandra, Qpid |
Há dois cenários em que você pode querer fazer uma reversão:
- Reverter para uma versão principal ou secundária anterior. Por exemplo, de 4.52.02 para 4.52.00.
- Reverter para uma versão de patch anterior na mesma versão. Por exemplo, de 4.52.00.02 para 4.52.00.01.
Para mais informações, consulte o processo de lançamento do Apigee Edge.
Ordem de reversão
A reversão dos componentes precisa seguir a ordem inversa do upgrade, com a exceção de que os servidores de gerenciamento precisam ser revertidos após o Cassandra. O Cassandra, os componentes de ambiente de execução e o Management Server precisam ser revertidos usando uma abordagem de data center por data center (DC-por-DC), redirecionando temporariamente o tráfego para os data centers funcionais.
Uma ordem geral típica de reversão para a Private Cloud 4.52.02 será semelhante a esta:
Data center único
Na configuração de um único data center, o procedimento de reversão terá um impacto significativo no tráfego no ambiente de execução e em algumas APIs de gerenciamento.
- Rollback Qpid e outros componentes relacionados à análise
- Roteadores de reversão e processadores de mensagens
- Reversão do Cassandra
- Servidor de gerenciamento de reversão
- Reversão do Postgres e do Zookeeper
Vários data centers
Em uma configuração de vários data centers, as revisões devem seguir uma abordagem de data center por data center (DC por DC), redirecionando temporariamente o tráfego para os data centers funcionais. Isso garante a continuidade do tráfego, evita inatividade e permite um processo de reversão controlado para o Cassandra, o Servidor de gerenciamento e os nós de execução.
- Rollback Qpid e outros componentes relacionados à análise em todos os DCs.
- Bloqueie o tráfego no primeiro data center e redirecione para outros data centers.
- Roteadores de reversão e processadores de mensagens no primeiro data center.
- Faça o rollback do Cassandra no primeiro data center.
- Servidor de gerenciamento de reversão no primeiro data center.
- Desbloqueie o tráfego no primeiro data center e siga as etapas de 2 a 6 até que o último data center tenha o rollback dos nós de execução, do Cassandra e do servidor de gerenciamento.
- Faça o rollback do Postgres, do Zookeeper e do LDAP em todos os DCs.
Para ter uma perspectiva, suponha que você tenha feito upgrade de todo o cluster do Cassandra, de todos os servidores de gerenciamento e de alguns processadores de mensagens de execução (RMPs) da versão 4.52.01 para 4.52.02 e precise fazer um rollback. Nesse caso, a reversão precisa ser feita da seguinte maneira:
- Bloqueie o tráfego para o primeiro data center (data center) e redirecione o tráfego para os outros DCs ativos para garantir a continuidade do serviço.
- Roteadores de reversão e processadores de mensagens no primeiro data center.
- Reverter o Cassandra no primeiro data center restaurando de um backup ou snapshot da VM.
- Reverter o servidor de gerenciamento no primeiro data center.
- Desbloqueie o tráfego para o primeiro data center.
- Repita as etapas de 1 a 5 para cada data center restante até que todos os nós de execução, o Cassandra e os servidores de gerenciamento tenham sido revertidos.
Quem pode fazer uma reversão
O usuário que executa uma reversão precisa ser o mesmo que atualizou o Edge originalmente ou um usuário que esteja executando como raiz.
Por padrão, os componentes do Edge são executados como o usuário "apigee". Em alguns casos, você pode estar executando componentes do Edge como usuários diferentes. Por exemplo, se o roteador precisar acessar portas privilegiadas, como as abaixo de 1000, execute o roteador como raiz ou como um usuário com acesso a essas portas. Ou você pode executar um componente como um usuário e outro componente como outro usuário.
Componentes com código comum
Os componentes do Edge a seguir compartilham um código comum. Portanto, para reverter qualquer um desses componentes em um nó, você precisa reverter todos os componentes que estão nesse nó.
edge-management-server(servidor de gerenciamento)edge-message-processor(processador de mensagens)edge-router(roteador)edge-postgres-server(servidor Postgres)edge-qpid-server(servidor Qpid)
Por exemplo, se você tiver o servidor de gerenciamento, o roteador e o processador de mensagens instalados no nó, para reverter qualquer um deles, você precisará reverter os três.
Reversão do Cassandra
Quando um upgrade importante do Cassandra é realizado em um determinado nó, o Cassandra modifica o esquema dos dados armazenados no nó, tornando a reversão direta inviável. Há duas metodologias para fazer o rollback. Você vai usar uma dessas metodologias com base no estado do upgrade que você está revertendo.
Metodologias para reversão
Cenários de reversão
O Edge para nuvem privada 4.52.02 inclui um upgrade no Cassandra e no driver usado pelo processador de mensagens e pelo servidor de gerenciamento para se conectar ao Cassandra. Como resultado, os upgrades e rollbacks desses três componentes estão intimamente relacionados. A tabela abaixo lista exemplos gerais de cenários de reversão para esses três componentes específicos. A reversão de outros componentes deve seguir a ordem da reversão.
Esta seção descreve vários cenários de reversão e a metodologia recomendada a ser seguida com base nas abordagens descritas acima.
| Cenário | Estratégia de reversão |
|---|---|
| Um único data center, alguns nós do Cassandra atualizados | Restauração de backup |
| Um único data center, todos os nós do Cassandra atualizados | Restauração de backup |
| Um data center único, todos os nós (Cassandra, servidor de gerenciamento e nós de execução) atualizados | |
| Vários data centers, alguns/todos os nós do Cassandra no primeiro data center atualizado | Recriar a partir de um data center existente |
| Vários data centers, todos os nós do Cassandra, o servidor de gerenciamento e os nós de execução no primeiro data center atualizados |
Isso precisa ser feito em um data center por vez. |
| Vários data centers, alguns/todos os nós do Cassandra do último data center são atualizados |
|
| Vários data centers, todos os nós do Cassandra, o servidor de gerenciamento e os nós de execução atualizados em todos os DCs |
Isso precisa ser feito um data center por vez. |
Em geral, considere o seguinte ao reverter o Cassandra:
- Reversão de componentes de execução ou gerenciamento
Se você precisar reverter componentes, como o Edge Management Server ou o Edge Message Processor, para uma versão anterior da Edge Private Cloud em qualquer data center (DC), verifique se o Cassandra também está revertido nesse data center específico ao mesmo tempo. Isso é necessário para evitar falhas de gerenciamento e tráfego de execução.
- Reversão usando backups
Os backups feitos no Cassandra 3.11.x não são compatíveis com os do Cassandra 2.1.x. Para ativar a reversão usando a restauração de backup, faça backup do Cassandra 2.1.x antes de realizar o upgrade.
- Como isolar o data center para reversão
Para evitar inatividade, redirecione o tráfego para data centers totalmente funcionais e bloqueie o data center que está sendo revertido.
Reversão do Cassandra usando a reconstrução
Pré-requisitos
- Você está operando um cluster do Edge para nuvem particular 4.51.00 / 4.52.00 / 4.52.01 em vários data centers
- Você está fazendo upgrade do Cassandra da versão 2.1.X para a 3.11.X e encontrou problemas durante o upgrade
- Você tem pelo menos um data center totalmente funcional no cluster que ainda está na versão mais antiga do Cassandra (Cassandra 2.1.X).
Etapas avançadas
- Escolha um data center (parcial ou totalmente atualizado) que você quer reverter. Redirecionar todo o tráfego do aplicativo desse data center para outro data center totalmente funcional.
- Se o roteador e o processador de mensagens tiverem sido atualizados, reverta todos os nós do roteador e do processador de mensagens no data center, um por vez.
- Pare o Cassandra em um nó, desinstale-o e limpe todos os dados associados.
- Instale o bootstrap da versão anterior e configure o Cassandra versão 2.1.x no nó limpo.
- Recrie o nó no data center funcional que ainda está executando o Cassandra 2.1.x.
- Execute as etapas 3 a 5 em cada nó do Cassandra restante no data center, um por vez.
- Execute novamente a configuração do servidor de gerenciamento no data center.
- Realize testes para validar a reversão. Depois de verificado, redirecione o tráfego do aplicativo de volta ao data center restaurado.
- Repita as etapas acima para os outros data centers que exigem uma reversão, um por vez.
Etapas detalhadas para limpar e usar nós existentes no cluster para recriar o nó:
Comece com o nó que você quer reverter.
- Verifique se o tráfego é redirecionado para data centers totalmente funcionais antes de prosseguir para as próximas etapas.
- Se o roteador e o processador de mensagens tiverem sido atualizados, reverta todos os nós do roteador e do processador de mensagens para a versão anterior no data center, um por vez.
- Pare o Cassandra no nó:
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop
- Desinstale o software do Cassandra do nó:
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra uninstall
-
Remova o diretório de dados do nó:
rm -rf /opt/apigee/data/apigee-cassandra
Faça o download e execute o bootstrap da versão anterior do Edge para nuvem privada para a qual você quer fazer o rollback:
Exemplo:como fazer o rollback para a versão 4.52.01
- Faça o download do bootstrap 4.52.01:
curl https://software.apigee.com/bootstrap_4.52.01.sh -o /tmp/bootstrap_4.52.01.sh -u ‘uName:pWord’
- Executar o bootstrap da versão 4.52.01:
sudo bash /tmp/bootstrap_4.52.01.sh apigeeuser=uName apigeepassword=pWord
- Instale o software Cassandra no nó:
apigee-service apigee-cassandra install
- Adicione a propriedade abaixo no arquivo
/opt/apigee/apigee-cassandra/source/conf/cassandra-env.sh.JVM_OPTS="$JVM_OPTS -Dcassandra.replace_address=<cass_ip-address>"
Exemplo:
JVM_OPTS="$JVM_OPTS -Dcassandra.replace_address=10.0.0.1"
- Configurar o Cassandra no nó:
/opt/apigee/apigee-setup/bin/setup.sh -p c -f configFile
- Depois que o Cassandra estiver em execução, remova o CWC acima do arquivo abaixo:
/opt/apigee/apigee-cassandra/source/conf/cassandra-env.sh. - Reinicie o nó do Cassandra
apigee-service apigee-cassandra restart
- Execute a reconstrução no nó fornecendo o nome do data center funcional:
/opt/apigee/apigee-cassandra/bin/nodetool rebuild -h <node-IP> <functional-dc>
Exemplo:
/opt/apigee/apigee-cassandra/bin/nodetool rebuild -h 10.0.0.1 dc-2
- Repita as etapas acima em cada nó que você quer reverter no data center, um por vez.
Depois que todos os nós do Cassandra no data center forem revertidos e reconstruídos
- Execute a configuração de qualquer um dos nós do servidor de gerenciamento no data center que está sendo revertido. Verifique se o servidor de gerenciamento é da versão revertida. Caso contrário, restaure o servidor de gerenciamento.
- Pare o servidor de gerenciamento:
/opt/apigee/apigee-service/bin/apigee-service edge-management-server stop
- Se você usa a monetização, desinstale-a também:
/opt/apigee/apigee-service/bin/apigee-service edge-mint-gateway uninstall
- Desinstale o edge-gateway e o apigee-cassandra-client:
/opt/apigee/apigee-service/bin/apigee-service edge-gateway uninstall
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra-client uninstall
- Faça o download e execute o bootstrap da versão mais antiga. Por exemplo, siga as etapas abaixo para fazer o download e executar o bootstrap da versão 4.52.01.
curl https://software.apigee.com/bootstrap_4.52.01.sh -o /tmp/bootstrap_4.52.01.sh -u ‘uName:pWord’
sudo bash /tmp/bootstrap_4.52.01.sh apigeeuser=uName apigeepassword=pWord
- Execute a configuração de um nó de servidor de gerenciamento:
/opt/apigee/apigee-setup/bin/setup.sh -p mt -f configFile
- Depois de concluir as etapas acima, redirecione o tráfego de volta para o data center revertido.
Fazer o rollback do servidor de gerenciamento para uma versão mais antiga
Configuração do servidor de gerenciamento
Otimização após a reconstrução
Nas etapas acima, todos os dados no nó são transmitidos do data center remoto durante a reconstrução. É possível otimizar esse processo usando um reparo depois que todas as réplicas forem transmitidas para o data center local. Isso evita o streaming entre data centers e deve ser mais rápido do que recriar todos os nós de um data center remoto.
Exemplo:suponha que você tenha seis nós do Cassandra no data center local. Por padrão, o fator de replicação do Apigee é três, então cada nó tem 50% dos dados. Nesse caso, você pode reconstruir os nós 1 e 4 seguindo o procedimento acima. Para os nós 2, 3, 5 e 6, siga as etapas abaixo para restaurar o backup e executar um reparo.
- Siga o procedimento até as etapas acima, conforme documentado, para recriar as réplicas no data center local.
- Para os outros nós, siga as etapas abaixo em cada um deles.
- Restaure o backup que você fez neste nó. Esse backup provavelmente tem dados desatualizados, porque foi feito antes de você iniciar o upgrade do Cassandra:
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restore backup_file
Se você tiver um snapshot da VM do nó, poderá restaurá-lo em vez do backup do Cassandra.
- Depois que o backup for restaurado, inicie o serviço do Cassandra no nó:
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra start
- Execute um reparo no nó para que os dados mais recentes possam ser transmitidos por streaming de um data center:
/opt/apigee/apigee-cassandra/bin/nodetool -h <node-IP> repair -dc <local-dc-name>
Exemplo:
/opt/apigee/apigee-cassandra/bin/nodetool -h 10.0.0.1 repair -dc dc-1
- Repita todas as etapas mencionadas na etapa 2 em cada nó que você quer reparar.
Fazer o rollback do Cassandra usando o backup / snapshot da VM
Esse procedimento é o único disponível se você tiver feito upgrade do cluster do Cassandra inteiro e quiser reverter. Além disso, os backups do Apigee são específicos do nó. Não é possível restaurar um backup de um nó em outro. Os backups do Cassandra incluem informações de metadados do nó (como endereço IP, posição do anel etc.).
Pré-requisitos
- Você está no processo de upgrade do Cassandra de 2.1.X para 3.11.X no último data center e encontrou problemas durante o upgrade.
- Você tem backups do nó antes do upgrade que está sendo revertido. O backup foi feito antes da tentativa de upgrade da versão 2.1.X para a 3.11.X.
Etapas avançadas
- Escolha um data center (parcial ou totalmente atualizado) para reverter. Redirecionar todo o tráfego de execução desse data center para outro data center totalmente funcional.
- Se o roteador e o processador de mensagens tiverem sido atualizados, faça o rollback de todos os nós do roteador e do processador de mensagens no data center, um por vez.
- Pare o Cassandra em um nó, desinstale-o e limpe todos os dados associados.
- Instale o bootstrap da versão anterior e configure o Cassandra versão 2.1.x no nó limpo.
- Pare o nó do Cassandra e limpe todos os dados associados.
- Restaure o nó do Cassandra a partir do backup feito antes do upgrade.
- Repita as etapas 3 a 6 para cada um dos nós do Cassandra restantes no data center, um por vez.
- Execute novamente a configuração do servidor de gerenciamento no data center.
- Realize testes para validar a reversão. Depois de verificado, redirecione o tráfego de execução de volta ao data center restaurado.
- Repita as etapas acima para os outros data centers que exigem uma reversão, um por vez.
- (Opcional) Execute o comando de reparo em todos os nós do Cassandra em todos os data centers se houver inconsistência de dados entre eles.
Etapas detalhadas para reverter o Cassandra usando backups/snapshot da VM
Comece com um nó do Cassandra no cluster
- Verifique se o tráfego é redirecionado para data centers totalmente funcionais antes de prosseguir para as próximas etapas.
- Se o roteador e o processador de mensagens tiverem sido atualizados, reverta todos os nós do roteador e do processador de mensagens para a versão anterior no data center, um por vez.
- Pare o Cassandra no nó:
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop
- Desinstale o software do Cassandra do nó:
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra uninstall
- Remova o diretório de dados do nó:
rm -rf /opt/apigee/data/apigee-cassandra
Faça o download e execute o bootstrap da versão anterior do Edge para nuvem privada para a qual você quer fazer o rollback:
Exemplo: como fazer o rollback para a versão 4.52.01
- Faça o download do bootstrap 4.52.01:
curl https://software.apigee.com/bootstrap_4.52.01.sh -o /tmp/bootstrap_4.52.01.sh -u ‘uName:pWord’
- Executar o bootstrap da versão 4.52.01:
sudo bash /tmp/bootstrap_4.52.01.sh apigeeuser=uName apigeepassword=pWord
- Configurar o Cassandra no nó:
/opt/apigee/apigee-setup/bin/setup.sh -p c -f configFile
- Pare o Cassandra no nó:
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop
- Exclua o diretório de dados no nó:
rm -rf /opt/apigee/data/apigee-cassandra/data
- Restaurar backup:
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restore backup_file
- Inicie o serviço do Cassandra no nó
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra start
- Repita as etapas em cada nó do Cassandra, um por vez.
- Execute a configuração de qualquer um dos nós do servidor de gerenciamento no data center que está sendo revertido. Verifique se o servidor de gerenciamento é da versão revertida. Caso contrário, restaure o servidor de gerenciamento.
- Depois de concluir as etapas acima, redirecione o tráfego de volta para o data center revertido.
- (Opcional) Execute o comando de reparo em todos os nós do Cassandra em todos os data centers se houver inconsistência de dados entre eles.
/opt/apigee/apigee-cassandra/bin/nodetool -h <node-IP> repair -pr
Fazer o rollback da atualização do Zookeeper 3.8.3
Se você estiver revertendo para as versões 4.52.00 ou 4.51.00, será necessário consultar algumas etapas especiais antes de reverter o Zookeeper. Essas etapas estão listadas em Reversão.
Se você estiver revertendo para a versão 4.52.01, reverta o Zookeeper como faria com qualquer software, conforme listado na seção Reverter para uma versão principal ou secundária anterior abaixo.
Qpid de reversão
Se você estiver revertendo para as versões 4.52.00 ou 4.51.00, será necessário consultar algumas etapas especiais antes de reverter o Qpid. Essas etapas estão listadas em Reversão.
Se você estiver revertendo para a versão 4.52.01, reverta o Qpid como faria com qualquer software, conforme listado em Reverter para uma versão principal ou secundária anterior.
Reverter a atualização do Postgres 10.17
Se você estiver revertendo para a versão 4.51.00, será necessário consultar algumas etapas especiais antes de reverter o Postgres. Essas etapas estão listadas em Reversão.
Se você estiver revertendo para a versão 4.52.01 ou 4.52.00, reverta o Postgres como faria com qualquer software, conforme listado na seção Reverter para uma versão principal ou secundária anterior abaixo.
Reverter para uma versão principal ou secundária anterior
Para reverter para uma versão principal ou secundária anterior, faça o seguinte em cada nó que hospeda o componente:
-
Faça o download do arquivo
bootstrap.shda versão para a qual você quer reverter:- Para reverter para a versão 4.51.00, faça o download de
bootstrap_4.51.00.sh
- Para reverter para a versão 4.51.00, faça o download de
- Pare o componente para reverter:
- Para reverter qualquer um dos componentes com código comum no
nó, é necessário interromper todos eles, conforme mostrado no exemplo a seguir:
/opt/apigee/apigee-service/bin/apigee-service edge-management-server stop
/opt/apigee/apigee-service/bin/apigee-service edge-router stop/opt/apigee/apigee-service/bin/apigee-service edge-message-processor stop/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server stop/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server stop - Para reverter qualquer outro componente no nó, interrompa apenas esse componente:
/opt/apigee/apigee-service/bin/apigee-service component stop
- Para reverter qualquer um dos componentes com código comum no
nó, é necessário interromper todos eles, conforme mostrado no exemplo a seguir:
- Se você estiver revertendo a monetização, desinstale-a de todos os nós do servidor de gerenciamento e do processador de mensagens:
/opt/apigee/apigee-service/bin/apigee-service edge-mint-gateway uninstall
- Desinstale o componente para reverter no nó:
- Para reverter qualquer um dos componentes com código comum no
node, desinstale todos eles desinstalando o grupo de componentes
edge-gatewayeapigee-cassandra-client, conforme mostrado no exemplo a seguir:/opt/apigee/apigee-service/bin/apigee-service edge-gateway uninstall
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra-client uninstall
- Para reverter qualquer outro componente no nó, desinstale apenas esse componente, conforme o
exemplo a seguir:
/opt/apigee/apigee-service/bin/apigee-service component uninstall
Em que component é o nome do componente.
- Para reverter o roteador de borda, exclua o conteúdo do arquivo
/opt/nginx/conf.de desinstale o grupo de componentesedge-gateway:cd /opt/nginx/conf.drm -rf *
- Para reverter qualquer um dos componentes com código comum no
node, desinstale todos eles desinstalando o grupo de componentes
- Desinstale a versão 4.52.02 do
apigee-setup:/opt/apigee/apigee-service/bin/apigee-service apigee-setup uninstall
- Instale a versão 4.51.00 do utilitário
apigee-servicee as dependências dele. O exemplo a seguir instala a versão 4.51.00 doapigee-service:sudo bash /tmp/bootstrap_4.51.00.sh apigeeuser=uName apigeepassword=pWord
Em que uName e pWord são o nome de usuário e a senha que você recebeu da Apigee. Se você omitir pWord, será solicitado que você o insira.
Se você receber um erro, verifique se fez o download do arquivo
bootstrap.shna etapa 1. - Instale
apigee-setup:/opt/apigee/apigee-service/bin/apigee-service apigee-setup install
- Instale a versão mais antiga do componente:
/opt/apigee/apigee-setup/bin/setup.sh -p component -f configFile
em que component é o componente a ser instalado e configFile é o arquivo de configuração da versão mais antiga.
- Se você estiver revertendo o Qpid, limpe as iptables:
sudo iptables -F
- Repita esse processo para cada nó que hospeda o componente que você está revertendo.
Reverter para uma versão anterior do patch
Para reverter um componente para uma versão específica do patch, faça o seguinte em cada nó que hospeda o componente:
- Faça o download da versão específica do componente:
/opt/apigee/apigee-service/bin/apigee-service component_version install
Em que component_version é o componente e a versão do patch a ser instalada. Exemplo:
/opt/apigee/apigee-service/bin/apigee-service edge-ui-4.51.05-0.0.3749 install
Se você estiver usando o repositório on-line da Apigee, determine as versões do componente disponível usando o seguinte comando:
yum --showduplicates list component
Exemplo:
yum --showduplicates list edge-ui
- Use
apigee-setuppara instalar o componente:/opt/apigee/apigee-setup/bin/setup.sh -p component -f configFile
Exemplo:
/opt/apigee/apigee-setup/bin/setup.sh -p ui -f configFile
Ao instalar, você especifica apenas o nome do componente, não a versão.
- Repita esse processo para cada nó que hospeda o componente que você está revertendo.
Reverter o mTLS
Para reverter a atualização do mTLS, siga estas etapas em todos os hosts:
- Parar a Apigee:
apigee-all stop
- Parar o mTLS:
apigee-service apigee-mtls uninstall
- Reinstale o mTLS:
apigee-service apigee-mtls install
apigee-service apigee-mtls setup -f /opt/silent.conf