Documentação do Oracle Cloud Infrastructure

Mantendo Circuitos Virtuais

Saiba mais sobre a manutenção planejada de circuitos virtuais FastConnect.

A Oracle executa manutenção regular nos roteadores dedicados para uso com circuitos virtuais FastConnect. Essa manutenção permite que a Oracle melhore a estabilidade operacional geral do dispositivo substituindo hardware defeituoso, aplicando patches e muito mais. Essas atividades de manutenção são cruciais para a melhoria do serviço. Cada tarefa de manutenção é planejada com cuidado e programada com antecedência para minimizar qualquer impacto nos serviços. Este artigo descreve o que acontece durante a manutenção do FastConnect e quais etapas devem ser tomadas para minimizar interrupções de serviço por causa da manutenção planejada ou não planejada.

Recomendamos que você sempre configure uma conexão secundária principal e redundante com o Oracle Cloud Infrastructure. A conexão secundária redundante pode ser um circuito virtual privado FastConnect ou uma conexão IPSec. Quando uma conexão IPSec estiver sendo usada como caminho secundário, certifique-se de que os túneis IPSec da VPN Site a Site estejam configurados para usar o Roteamento BGP. Ao usar essas conexões, o Oracle Cloud sempre prioriza FastConnect em relação aos túneis IPSec usando o mecanismo de pré-anexação do Caminho AS.

Estabeleça conexões primárias e secundárias em diferentes dispositivos físicos para oferecer conectividade confiável de recursos locais para o OCI. Ao criar uma conexão FastConnect secundária com o FastConnect Direct, use a opção "especificar proximidade do roteador" na Console do OCI para fazer a conexão secundária pousar em outro dispositivo físico. Para conexões de Parceiro, trabalhe com o parceiro FastConnect para provisionar um circuito virtual secundário em uma conexão cruzada de parceiro redundante. Isso ajuda você a ter conectividade ininterrupta durante qualquer evento planejado ou não planejado. Para obter informações sobre práticas de redundância, consulte o Guia de redundância de conectividade (PDF).

Alta Disponibilidade em Circuitos Virtuais

A alta disponibilidade em circuitos virtuais é obtida por meio de conexões redundantes entre a OCI e a rede local. A implementação de alta disponibilidade mantém a rede intacta durante qualquer interrupção ou atividades planejadas. Caso você esteja usando o modelo de conectividade do parceiro Oracle, o Oracle tratará a redundância das conexões físicas entre o parceiro e o Oracle e a redundância dos roteadores nos locais de FastConnect. Espera-se que você trate a redundância da conexão física entre a rede local e o parceiro da Oracle. Para outros modelos de conectividade FastConnect, como Terceiros e co-localização, você é responsável por garantir a redundância entre os roteadores FastConnect e os dispositivos de borda da rede local, configurando circuitos virtuais redundantes usando diferentes roteadores físicos FastConnect fornecidos pela Oracle em todas as regiões e no local do POP FastConnect.

As topologias de rede a seguir mostram circuitos virtuais redundantes usados no cenário de parceiro Oracle, provedor de terceiros ou co-localização com cenário Oracle e IPSec VPN como backup para FastConnect.

Esta imagem mostra uma configuração com um provedor Oracle e vários circuitos virtuais em diferentes roteadores em um único local onde há FastConnect.
Esta imagem mostra uma configuração de co-localização na qual há duas conexões físicas e dois circuitos virtuais no local onde há FastConnect.
Esta imagem mostra o FastConnect com VPN Site a Site como backup.

Para obter mais informações, consulte FastConnect Melhores Práticas de Redundância.

Eventos e Notificações de Manutenção

A manutenção planejada dos serviços FastConnect é cuidadosamente programada para se concentrar em um roteador FastConnect de cada vez para garantir conectividade ininterrupta nos circuitos virtuais durante a manutenção. Essa abordagem garante que pelo menos um caminho esteja sempre disponível para acessar circuitos redundantes com caminhos diversos.

Durante a manutenção, a Oracle envia a mensagem "BGP GRACEFUL SHUTDOWN 65535:0" da RFC 8326 para dispositivos de borda CPE junto com a pré-anexação do caminho AS. Se o dispositivo CPE reconhecer essa mensagem, a preferência local no dispositivo CPE será definida como zero para garantir que o caminho em manutenção não seja mais preferido. A alteração de caminho AS é feita pré-anexando o Oracle AS 31898 às rotas BGP propagadas do OCI para o CPE. O envio dessa mensagem junto com a pré-anexação do caminho AS garante que o tráfego mude normalmente para o caminho redundante antes da atividade de manutenção.

Certifique-se de que todos os dispositivos locais no caminho estejam configurados para reconhecer a pré-anexação do caminho AS ou a mensagem da Comunidade de Shutdown Gracioso do BGP. Além disso, valide se a redundância está configurada para mudar o tráfego para um caminho alternativo, caso o caminho principal seja preferido. Por fim, quando aplicável, verifique com o provedor de serviços para confirmar que eles suportam mensagens de pré-anexação de Caminho AS ou Comunidade BGP na conexão que eles gerenciam com a rede local.

Se a rede não suportar as ações anteriores, é provável que você experimente roteamento assimétrico e eliminações de pacotes durante as atividades de manutenção.

Observação

A definição da preferência local como zero no dispositivo CPE após o recebimento da comunidade de shutdown normal pode ser específica do fornecedor. Validar com os fornecedores de equipamentos que o dispositivo CPE possui esse recurso. Caso contrário, configure uma política de roteamento de entrada para definir a preferência local no CPE como zero, com base no recebimento da mensagem da comunidade de shutdown normal do OCI.

Os roteadores da OCI suportam o caminho AS pré-anexado quando também é suportado em dispositivos CPE. O roteamento assimétrico é possível se o tráfego nos roteadores internos do CPE e da OCI não acontecer ao mesmo tempo, devido a um atraso na mudança de tráfego. Para eliminar esses problemas, recomendamos que você ative o suporte para roteamento assimétrico em dispositivos CPE.

Quando a manutenção planejada é programada, você é notificado pelo menos 14 dias antes dos períodos de manutenção por meio de Anúncios da Console e também notificações por e-mail se estiver inscrito para notificações por e-mail. Os contatos de notificação por e-mail são adicionados e gerenciados pelo Administrador do Serviço. Você é notificado sobre interrupções de serviço e incidentes de segurança usando os mesmos mecanismos.

Verificando o Failover do Circuito Virtual

Ao provisionar conexões redundantes pela primeira vez, valide se elas estão funcionando corretamente antes de colocá-las em produção. Repita a validação regularmente (a cada 6 meses, todos os anos e assim por diante) ou antes das janelas de manutenção programadas para garantir que o failover ainda esteja funcionando corretamente, pois as alterações podem ser feitas após o teste de failover inicial que pode interromper o failover. Se você testá-lo apenas quando provisionar pela primeira vez a conectividade redundante, correrá o risco de descobrir que ele não está funcionando quando ocorre uma interrupção real, o que pode ser tarde demais. Além disso, lembre-se de validar essa falha ao retornar às obras primárias.

O processo de validação de failover tem dois estágios, cada um dos quais é visto durante a manutenção do roteador do OCI:

  1. Despreferir o caminho principal usando preferência local e pré-anexar caminho AS, em seguida, verifique se o tráfego muda para o caminho secundário. O Guia de redundância de conectividade (PDF) explica como o pré-anexo do caminho AS e AS configurações de preferência locais podem ser usados para priorizar um caminho específico. Este é o principal teste de failover que você executa, pois o processo de preferência do caminho é executado pelo OCI durante a janela de manutenção antes do shutdown da sessão BGP.
  2. Encerre temporariamente a sessão BGP principal entre redes locais e do OCI. Para fazer shutdown da sessão BGP, desative o circuito virtual na Console do OCI. Isso força o tráfego a fluir através da conexão secundária. Consulte a seção "Gerenciando sua Conexão" da documentação do modo FastConnect usado (Parceiro, Colocado ou Provedor de Terceiros). Este não é um "desligamento gracioso" e pode ser retomado rapidamente após a validação do failover.

Você pode abrir o caminho principal revertendo as alterações e, em seguida, verificando se o tráfego é encaminhado de volta para o caminho principal. Recomendamos testar o failover usando os dois métodos já sugeridos para garantir que o mecanismo de failover esteja funcionando sem problemas.

Para modelos de conectividade do parceiro Oracle, se você tiver vários circuitos virtuais, terá a opção de validar o failover usando os métodos mencionados anteriormente. Se você tiver apenas um circuito virtual, não terá a opção de testar o failover, pois a redundância só existe entre o roteador FastConnect da Oracle e o provedor.

Se a rede local usar firewalls com monitoramento de estado, você estará propenso a problemas durante o failover, por isso é ainda mais importante garantir que o failover de tráfego aconteça conforme esperado.

As estatísticas de tráfego podem ser monitoradas na Console do OCI. Os bits recebidos e os bits enviados incrementam apenas as métricas no caminho ativo atual. Você pode monitorar a integridade, a capacidade e o desempenho de uma conexão FastConnect usando métricas, alarmes e notificações. Para obter mais informações, consulte os serviços Monitoring e Notifications.

Perguntas Frequentes

Que impacto podem ter os circuitos virtuais redundantes?
Quando você usa circuitos virtuais redundantes, é menos provável que ocorra interrupções durante a manutenção. Se os pares BGP suportam a pré-anexação do caminho AS e o GSHUT (desligamento gracioso), o processo de convergência de tráfego é mais rápido e suave. O tráfego alterna perfeitamente para o caminho secundário após a reconvergência do BGP, eliminando interrupções. Em tais cenários, não esperamos qualquer impacto perceptível. Sempre siga a documentação descrita anteriormente.
O que acontece se eu não tiver circuitos virtuais redundantes?
Se você confiar em um único circuito virtual, poderá sofrer interrupções de tráfego durante a janela de manutenção descrita na notificação. Recomendamos seguir as Melhores Práticas de Redundância FastConnect para implementar conexões redundantes. Para redundância imediata, configurar uma conexão IPSec como um caminho redundante pode ajudar a mitigar interrupções, tendo em mente a limitação de largura de banda da VPN Site a Site.
Qual é a duração de impacto esperada para conexões não redundantes?
A manutenção real não leva todo o tempo especificado no aviso, mas o impacto pode ocorrer a qualquer momento dentro da janela de manutenção especificada. Prepare e planeje com base nos horários de início e término fornecidos.
Posso solicitar uma modificação no caminho do AS pré-anexando para pré-anexar mais de 3 vezes durante a manutenção ou alterar a configuração do GSHUT?
Não. Os procedimentos de pré-anexação de caminho AS e GSHUT são padronizados globalmente na OCI e não podem ser alterados para acomodar solicitações individuais.
Como posso verificar rapidamente a redundância do circuito virtual?
Você pode verificar a redundância por meio da Console do OCI. Os circuitos virtuais não redundantes acionam notificações na Console indicando a falta de redundância informando "Este circuito virtual FastConnect tem um único ponto de falha. Proporcionar uma conexão redundante para evitar possíveis interrupções." Para confirmar:
  1. Abra a página de detalhes do circuito virtual na Console do OCI.
  2. Veja a seção BGP dos detalhes. O campo "Dispositivo Lógico" exibe o nome do dispositivo que hospeda o circuito virtual. Para redundância, os dispositivos lógicos de cada circuito virtual devem ser diferentes.
Ambos os circuitos virtuais pousam no mesmo dispositivo físico. É possível realizar manutenção em um circuito virtual de cada vez?
A manutenção é realizada no nível do dispositivo físico, não no nível do circuito virtual. A manutenção em um dispositivo afeta todos os circuitos virtuais associados simultaneamente. Recomendamos que você implemente conexões redundantes em diferentes dispositivos físicos para evitar esses cenários. Siga as Melhores Práticas de Redundância FastConnect.
Por que uma janela de manutenção foi cancelada ou reprogramada?
A manutenção pode ser adiada se forem identificados problemas que possam levar a interrupções imprevistas. A prioridade é concluir a manutenção com o mínimo de impacto para você. A reprogramação garante que todos os bloqueadores sejam resolvidos antes de continuar.
Recebi várias notificações com datas diferentes. Como posso confirmar quando a manutenção está programada?
Se você tiver várias notificações por causa do reagendamento, considere a notificação mais recente a fonte definitiva da verdade. Sempre planeje com base nos intervalos de tempo atualizados fornecidos na notificação mais recente.
Qual redundância eu preciso provisionar ao usar um Parceiro da Oracle para fornecer conectividade de Camada 3 ao OCI?
A Oracle garante que nossos parceiros que oferecem conectividade da Camada 3 já tenham redundância física provisionada em seu nome. Você é responsável por provisionar a redundância preferencial para o Parceiro Oracle. Se você estiver usando uma região com um único local FastConnect e também quiser diversidade de local, considere provisionar um segundo circuito virtual para uma região próxima. Consulte Sessão BGP para Parceiro Oracle (Camada 3) para obter mais detalhes.
É possível usar um túnel de VPN Site a Site como backup para FastConnect?

Sim. Consulte VPN Site a Site como Backup para o FastConnect.

Posso solicitar que a manutenção seja cancelada ou reprogramada?
Notificamos todos os clientes afetados 14 dias antes da alteração em relação à manutenção para dar tempo suficiente para acomodar e gerenciar a rede local. Essa notificação é enviada a todos os clientes que têm circuitos virtuais em execução no mesmo dispositivo. Não podemos acomodar solicitações individuais de clientes com base em sua preferência de data ou hora.
Posso solicitar que a notificação de manutenção seja enviada novamente?
Não. A Oracle envia e-mails em um formato automatizado com base em IDs de compartimento e OCIDs de circuito virtual, e a automação o envia para o e-mail de notificação associado a esse compartimento. A equipe de notificação do cliente não pode enviar e-mails individuais. Essas notificações só acontecem em um lote.
Quando a manutenção do FastConnect geralmente é programada?

Para minimizar o impacto nos negócios, a manutenção geralmente está programada para ser executada fora do horário comercial normal para o fuso horário da região local.

Qual é o status da manutenção? Não recebemos uma notificação de que a manutenção foi concluída.
A manutenção é realizada apenas durante o período mencionado na notificação. As notificações são enviadas aos clientes pelo menos 14 dias antes de qualquer atividade de manutenção. As janelas de manutenção quase sempre têm tempo suficiente para concluir todas as tarefas necessárias. Se uma janela de manutenção precisar ser estendida por causa de circunstâncias imprevistas, uma nova notificação será enviada a todos os clientes afetados. Se nenhuma outra notificação for enviada, pode-se entender que a manutenção foi concluída com sucesso dentro do tempo alocado. Outra notificação será enviada a todos os clientes afetados se uma atividade de manutenção tiver sido adiada ou cancelada.