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 em seus serviços. Este artigo descreve o que acontece durante uma manutenção de circuito virtual FastConnect e quais etapas você deve seguir para minimizar interrupções de serviço devido a manutenção planejada ou não planejada.
A Oracle recomenda que você sempre configure uma conexão principal e secundária com o Oracle Cloud Infrastructure. A conexão secundária pode ser um circuito virtual FastConnect redundante ou uma conexão IPsec. Caso a conexão IPSec esteja 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 de Caminho AS.
As conexões primária e secundária devem ser estabelecidas em diferentes dispositivos físicos para oferecer conectividade confiável de recursos locais para o OCI. Ao criar uma conexão secundária FastConnect comFastConnect Direct, use a opção "especificar proximidade do roteador" na console do OCI para fazer com que a conexão secundária aterre em outro dispositivo físico. Para conexões de Parceiro, trabalhe com seu parceiro FastConnect para provisionar um circuito virtual secundário em uma conexão cruzada de parceiro redundante. Isso ajudará você a ter uma conexão ininterrupta se houver algum evento planejado ou não planejado. Para obter informações sobre práticas de redundância, siga 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 da 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 sistema Oracle cuida da redundância das conexões físicas entre o parceiro e o sistema Oracle e da 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 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 seus próprios dispositivos de borda configurando circuitos virtuais redundantes usando diferentes roteadores físicos FastConnect fornecidos pela Oracle em cada região e localização POP FastConnect.
As topologias de rede abaixo 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.
Para obter mais informações, consulte FastConnect Redundancy Best Practices.
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 a fim de garantir uma conectividade ininterrupta em circuitos virtuais durante a manutenção. Essa abordagem garante que sempre haja pelo menos um caminho disponível para acessar a rede do OCI quando circuitos redundantes estiverem em vigor, minimizando qualquer interrupção potencial.
Durante a manutenção, a Oracle envia a conhecida mensagem RFC8326 "BGP GRACEFUL SHUTDOWN 65535:0" para seus dispositivos de borda CPE juntamente 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 seja deferido. A alteração do caminho AS é feita pela pré-anexação do AS 31898 (três vezes) às rotas BGP que vão do OCI para o CPE. O envio dessa mensagem permite que o tráfego mude normalmente para o caminho redundante.
Você precisa garantir que todos os dispositivos locais no caminho sejam configurados para reconhecer a pré-anexação do caminho AS ou a mensagem da Comunidade de Shutdown Gracioso do BGP. Além disso, certifique-se de que a redundância esteja configurada corretamente para mudar o tráfego para um caminho alternativo, caso o caminho principal seja deferido. É importante verificar com o provedor de serviços para confirmar se eles estão configurados para permitir a pré-anexação do caminho AS e mensagens da Comunidade BGP na conexão se eles estiverem gerenciando sua rede.
Se sua rede não permitir as ações acima, você provavelmente experimentará roteamento assimétrico e eliminações de pacotes durante as atividades de manutençã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. Confirme com os fornecedores de equipamentos que seu dispositivo CPE tem esse recurso incorporado ou não. 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 normal da comunidade de shutdown do OCI.
Os roteadores do OCI permitem a pré-anexação do caminho AS quando ele também é feito em dispositivos CPE. Há uma possibilidade de roteamento assimétrico se a mudança de tráfego nos roteadores internos do CPE e do OCI não ocorrer ao mesmo tempo, o que pode acontecer se houver 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 for programada, você será notificado pelo menos 14 dias antes das janelas de manutenção por meio de Anúncios da Console e também de 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ê será notificado sobre interrupções de serviço e incidentes de segurança usando os mesmos mecanismos.
Verificando o Failover do Circuito Virtual
Quando você provisionar suas conexões redundantes pela primeira vez, valide se elas estão funcionando corretamente antes de colocá-las em produção. Repita a validação da mesma forma regularmente (a cada 6 meses, a cada ano etc.) ou antes das janelas de manutenção programadas para garantir que o failover ainda esteja funcionando corretamente, pois as alterações podem ser feitas em seu ambiente após o teste de failover inicial que pode interromper o failover. Se você só testá-lo quando provisionar a conectividade redundante pela primeira vez, corre o risco de descobrir que ela não está funcionando quando ocorre uma interrupção real que pode ser tarde demais. Além disso, não se esqueça de validar essa falha de volta às obras primárias.
O processo de validação de failover tem dois estágios, cada um dos quais será visto durante a manutenção do roteador do OCI:
- De-preferir o caminho principal usando preferência local e AS caminho pré-anexar, em seguida, verificar se o tráfego muda para o caminho secundário ou não. O Guia de Redundância de Conectividade (PDF) explica como o caminho AS precede e as configurações de preferência locais podem ser usadas para priorizar um caminho específico. Este deve ser o principal teste de failover que você executa, pois o processo de cancelamento de preferência do caminho é executado pelo OCI durante a janela de manutenção antes do shutdown da sessão BGP.
- Faça shutdown da sessão BGP principal entre as redes locais e do OCI. Para fazer shutdown da sessão BGP, desative o circuito virtual na console do OCI. Isso forçará o tráfego a fluir pela conexão secundária.
Você pode abrir o caminho principal revertendo as alterações acima e verificando se o tráfego é encaminhado de volta ao caminho principal. A Oracle recomenda testar o failover usando os dois métodos sugeridos acima para garantir que o mecanismo de failover esteja funcionando sem problemas.
Para modelos de conectividade de parceiros da Oracle, se você tiver vários circuitos virtuais, terá a opção de validar o failover usando os métodos mencionados acima. 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 sua rede local usar firewalls com monitoramento de estado, você estará propenso a problemas durante o failover, por isso é ainda mais importante garantir que o tráfego faça failover corretamente.
As estatísticas de tráfego podem ser monitoradas na console do OCI. As métricas de bits recebidos e bits enviados só devem ser incrementadas no caminho que está ativo no momento. Você pode monitorar a integridade, a capacidade e o desempenho da sua conexão do FastConnect usando métricas, alarmes e notificações. Para obter mais informações, consulte https://docs.oracle.com/iaas/Content/Monitoring/home.htm e https://docs.oracle.com/iaas/Content/Notification/home.htm.