AWS - Otimizar o link WAN entre VPCs [fechado]

2

Eu tenho 2 VPCs, um em us-east-1 e outro em ap-northeast-1, com um túnel OpenVPN entre eles.

De acordo com o meu teste de ping, a latência entre as duas regiões é de ~ 160-180 ms. Supondo que todos os serviços (banco de dados, armazenamento em cache, fila / funcionários, etc) devem permanecer nos EUA, enquanto apenas os servidores da Web serão implantados no JP. Haverá um grande atraso no acesso a esses serviços nos EUA pelos servidores da web JP.

Existem produtos "Otimização / aceleração de WAN" no mercado da AWS. Mas eu não consigo encontrar muita informação do google.

  1. Silver Peak
    • Eu sou forçado a "aproveitar" uma avaliação gratuita de 30 dias depois de aceitar os termos. Eu lancei um nos EUA e outro no JP, e tentei conectá-los em um túnel ... ele então reclamou chave de licença duplicada porque as chaves de avaliação são as mesmas em ambas as instâncias ...
  2. CloudOpt
    • não faço ideia de como configurá-lo após o lançamento em ambas as regiões. A interface do usuário é horrível, assim como seu kb.
  3. CloudBridge
    • pensei que isso seria muito melhor porque é de um grande nome. mas na primeira etapa do assistente para começar, é só continuar dizendo que minha credencial da AWS está incorreta e não me deixará passar.

Alguém tem experiência em otimizar o link WAN entre VPCs? Não tenho certeza se estou no caminho certo. Existem outras maneiras de alcançar a mesma coisa (reduzir a latência e garantir velocidade de rede suficiente entre as regiões)?

    
por Chris Lam 13.07.2014 / 18:45

2 respostas

3

Supondo que o seu túnel OpenVPN não esteja aumentando significativamente o tempo de ida e volta (RTT) do link quando comparado ao RTT entre os sites sem o OpenVPN, não há tecnologia que possa realmente reduzir o RTT real abaixo do os links subjacentes.

Você está limitado pelas leis da física (o atraso de propagação de sinais através de fios e cabos de fibra ótica, e possivelmente para um satélite e para trás, embora este último pareça improvável ou o RTT seria ainda pior) e pela velocidade em que os roteadores intermediários dentro e entre as regiões podem alternar os pacotes.

Usando números extremamente redondos (7.000 milhas x 2, a 2/3 da velocidade da luz no vácuo), eu diria que ~ 113ms do seu atraso é simplesmente o melhor momento para a luz viajar de um lugar para o outro. outro e de volta. Nada pode eliminar isso.

A compressão, análoga ao empacotamento de mais passageiros em um avião ou ao vôo de aviões maiores, gera mais dados em um link de uma determinada capacidade por unidade de tempo, mas nenhum passageiro passa menos tempo em trânsito.

O armazenamento em cache, em suas várias formas, também pode fornecer a conveniente ilusão de recuperação mais rápida de dados, mas os dados não armazenados em cache não podem chegar mais rápido que o normal.

Se o OpenVPN não estiver adicionando nenhuma latência adicional apreciável (e na minha experiência, não deveria ser), então você não encontrará uma solução mágica.

A arquitetura do seu aplicativo provavelmente terá que se adaptar para acomodar esse atraso essencialmente fundamental, incluindo réplicas de leitura do banco de dados, filas locais (possivelmente para lidar com eventual execução de gravações de banco de dados não críticas) e acesso ao banco de dados mais eficiente.

    
por 14.07.2014 / 02:07
2

Todos os produtos de otimização de WAN são caches. Sabendo que por que não apenas implantar caches padrão, como memcached, servidores slave mysql / percona, nginix / verniz para o Japan VPC? Eu realmente olharia nos bastidores para os produtos de otimização de WAN que você estava implantando, eles provavelmente aproveitam esses tipos de caches em um pacote bonito.

    
por 13.07.2014 / 19:25