- AWS Outposts

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Sob o modelo de responsabilidade compartilhada, modelo , AWS é responsável pelo hardware e software que executam AWS os serviços. Isso se aplica a AWS Outposts, assim como a uma AWS região. Por exemplo, AWS gerencia patches de segurança, atualiza o firmware e faz a manutenção do equipamento Outpost. AWS também monitora o desempenho, a integridade e as métricas do seu de rack Outposts e determina se alguma manutenção é necessária.

Atenção

Os dados sobre volumes de armazenamento de instâncias são perdidos se o drive de disco subjacente falhar ou se a instância parar, hibernar ou terminar. Para evitar a perda de dados, recomendamos que você faça backup de seus dados de longo prazo em volumes de armazenamento de instâncias em armazenamento persistente, como um bucket do Amazon S3, um EBS volume da Amazon ou um dispositivo de armazenamento de rede em sua rede local.

Atualizar detalhes de contato

Se o proprietário do Outpost mudar, entre em contato com a AWS Support Central com o nome e as informações de contato do novo proprietário.

Manutenção de hardware

Se AWS detectar um problema irreparável com o hardware durante o processo de provisionamento do servidor ou ao hospedar instâncias da Amazon em EC2 execução no seu de rack Outposts, notificaremos o proprietário do Outpost e o proprietário das instâncias de que as instâncias afetadas estão programadas para serem desativadas. Para obter mais informações, consulte Desativação de instâncias no Guia EC2 do usuário da Amazon.

O proprietário do Outpost e o proprietário da instância podem trabalhar juntos para resolver o problema. O proprietário da instância pode parar e iniciar uma instância afetada para migrá-la para a capacidade disponível. Os proprietários de instâncias podem interromper e iniciar as instâncias afetadas em um horário que seja conveniente para eles. Caso contrário, AWS interrompe e inicia as instâncias afetadas na data de desativação da instância. Se não houver capacidade adicional no Outpost, a instância permanecerá no estado parado. O proprietário do Outpost pode tentar liberar a capacidade usada ou solicitar capacidade adicional para o Outpost, para que a migração possa ser concluída.

Se a manutenção do hardware for necessária, AWS entraremos em contato com o proprietário do Outpost para confirmar a data e a hora da visita da equipe de AWS instalação. As visitas podem ser agendadas em até dois dias úteis a partir do momento em que o proprietário do Outpost fala com a AWS equipe.

Quando a equipe de AWS instalação chegar ao local, ela substituirá os hosts, switches ou elementos de rack insalubres e colocará a nova capacidade on-line. Eles não realizarão nenhum diagnóstico ou reparo de hardware no local. Se substituírem um host, removerão e destruirão a chave NIST de segurança física compatível, destruindo efetivamente todos os dados que possam permanecer no hardware. Isso garante que nenhum dado saia do seu local. Se eles substituírem um dispositivo de rede Outpost, as informações de configuração da rede poderão estar presentes no dispositivo quando ele for removido do local. Essas informações podem incluir endereços IP e ASNs são usadas para estabelecer interfaces virtuais para configurar o caminho para sua rede local ou de volta para a região.

Atualizações de firmware

A atualização do firmware do Outpost normalmente não afeta as instâncias do seu Outpost. No caso raro de precisarmos reinicializar o equipamento Outpost para instalar uma atualização, você receberá um aviso de desativação de instância para todas as instâncias em execução com esse recurso.

Manutenção de equipamentos de rede

A manutenção dos dispositivos de rede Outpost (OND) é realizada sem afetar as operações e o tráfego regulares do Outpost. Se a manutenção for necessária, o tráfego é desviado doOND. Você pode notar mudanças temporárias nos BGP anúncios, como a prependência AS-Path, e as alterações correspondentes nos padrões de tráfego nos uplinks do Outpost. Com as atualizações de OND firmware, você pode notar BGP oscilações.

Recomendamos que você configure o equipamento de rede do cliente para receber BGP anúncios do Outposts sem alterar os atributos e BGP habilite BGP o balanceamento de vários caminhos/carga para obter fluxos de tráfego de entrada ideais. A prependência de caminho AS é usada para prefixos de gateway local para afastar o tráfego, ONDs caso seja necessária manutenção. A rede do cliente deve preferir rotas de Outposts com um comprimento de caminho AS de 1 em vez de rotas com um comprimento de caminho AS de 4.

A rede de clientes deve anunciar BGP prefixos iguais com os mesmos atributos para todos. ONDs Por padrão, a carga da rede Outpost equilibra o tráfego de saída entre todos os uplinks. As políticas de roteamento são usadas no lado do Posto Avançado para afastar o tráfego de um, OND se a manutenção for necessária. Essa mudança de tráfego exige BGP prefixos iguais do lado do cliente para todosONDs. Se for necessária manutenção na rede do cliente, recomendamos que você use o acréscimo de caminho AS para mudar temporariamente a matriz de tráfego de uplinks específicos.

Melhores práticas para eventos de energia e de rede

Conforme declarado nos Termos de AWS Serviço para AWS Outposts clientes, a instalação onde o equipamento Outposts está localizado deve atender aos requisitos mínimos de energia e rede para apoiar a instalação, manutenção e uso do equipamento Outposts. Um de rack Outposts pode operar corretamente somente quando a energia e a conectividade de rede são ininterruptas.

Eventos de energia

Com quedas de energia completas, há um risco inerente de que um AWS Outposts recurso não retorne ao serviço automaticamente. Além de implantar soluções redundantes de energia e energia de backup, recomendamos que você faça o seguinte com antecedência para mitigar o impacto de alguns dos piores cenários:

  • Retire seus serviços e aplicações dos equipamentos da Outposts de forma controlada, usando mudanças de balanceamento de carga DNS baseadas ou fora da prateleira.

  • Pare contêineres, instâncias e bancos de dados de forma incremental ordenada e use a ordem inversa ao restaurá-los.

  • Planos de teste para movimentação ou parada controlada de serviços.

  • Faça backup de dados e de configurações essenciais e armazene-os fora dos Outposts.

  • Mantenha os tempos de inatividade de energia no mínimo.

  • Evite a troca repetida das fontes de alimentação (off-on-off-on) durante a manutenção.

  • Reserve mais tempo no intervalo de manutenção para lidar com o inesperado.

  • Gerencie as expectativas de seus usuários e clientes comunicando um prazo de manutenção mais amplo do que você normalmente precisaria.

  • Depois que a energia for restaurada, crie um caso no AWS Support Centro para solicitar a verificação de que AWS Outposts os serviços relacionados estão em execução.

Eventos de conectividade de rede

A conexão do link de serviço entre seu Posto Avançado e a AWS Região ou Região de origem do Posto Avançado normalmente se recupera automaticamente de interrupções ou problemas de rede que possam ocorrer em seus dispositivos de rede corporativa upstream ou na rede de qualquer provedor de conectividade terceirizado após a conclusão da manutenção da rede. Durante o período em que a conexão do link de serviço está inativa, suas operações de Outposts são limitadas às atividades da rede local.

Para obter mais informações, consulte a pergunta O que acontece quando a conexão de rede da minha instalação cai? na FAQs página da AWS Outposts prateleira.

Se o link do serviço estiver inativo devido a um problema de energia no local ou à perda de conectividade de rede, AWS Health Dashboard ele enviará uma notificação para a conta proprietária dos Outposts. Nem você nem AWS pode suprimir a notificação de uma interrupção do link de serviço, mesmo que a interrupção seja esperada. Para obter mais informações, consulte Como iniciar o AWS Health Dashboard no Guia do usuário do AWS Health .

No caso de uma manutenção de serviço planejada que afetará a conectividade da rede, siga as seguintes etapas proativas para limitar o impacto de possíveis cenários problemáticos:

  • Se seu rack Outposts se conectar à AWS região principal por meio da Internet ou do Direct Connect público, antes de uma manutenção planejada, capture uma rota de rastreamento. Ter um caminho de rede funcional (pre-network-maintenance) e um caminho de rede problemático (post-network-maintenance) para identificar as diferenças ajudaria na solução de problemas. Se você encaminhar um problema pós-manutenção para AWS ou seuISP, você pode incluir essas informações.

    Capture uma rota de rastreamento entre:

    • Os endereços IP públicos no local dos Outposts e o endereço IP retornado pelo outposts.region.amazonaws.com. Substituir region com o nome da AWS região mãe.

    • Qualquer instância na região principal com conectividade pública à Internet e endereços IP públicos no local dos Outposts.

  • Se você estiver no controle da manutenção da rede, limite a duração do tempo de inatividade do link de serviço. Inclua uma etapa em seu processo de manutenção que verifique se a rede foi recuperada.

  • Se você não estiver no controle da manutenção da rede, monitore o tempo de inatividade do link de serviço em relação ao intervalo de manutenção anunciado e encaminhe antecipadamente para a parte responsável pela manutenção planejada da rede se o link de serviço não estiver funcionando novamente no final do intervalo de manutenção anunciado.

Recursos

Aqui estão alguns recursos relacionados ao monitoramento que podem garantir que os Outposts estejam operando normalmente após um evento planejado ou não planejado de energia ou de rede:

  • O AWS blog Monitoring best practices for AWS Outposts aborda as melhores práticas de observabilidade e gerenciamento de eventos específicas para Outposts.

  • O AWS blog Ferramenta de depuração para conectividade de rede da Amazon VPC explica a ferramenta AWSSupport etupIPMonitoring-S From. VPC Essa ferramenta é um AWS Systems Manager documento (SSMdocumento) que cria uma instância do Amazon EC2 Monitor em uma sub-rede especificada por você e monitora os endereços IP de destino. O documento executa testes de diagnóstico de pingMTR, TCP trace-route e trace-path e armazena os resultados no Amazon CloudWatch Logs, que podem ser visualizados em um CloudWatch painel (por exemplo, latência, perda de pacotes). Para o monitoramento de Outposts, a Instância de Monitor deve estar em uma sub-rede da AWS região principal e configurada para monitorar uma ou mais de suas instâncias Outpost usando seus IPs privados. Isso fornecerá gráficos de perda de pacotes e latência entre e a região principal. AWS Outposts AWS

  • O AWS blog Implantando um CloudWatch painel automatizado da Amazon para AWS Outposts uso AWS CDK descreve as etapas envolvidas na implantação de um painel automatizado.

  • Se você tiver dúvidas ou precisar de mais informações, consulte Criação de um caso de suporte no AWS Guia do usuário de suporte.