[GTER] Azure <-> Net-Virtua - AZCopy Falha comunicação

[Rubens Kuhl]

Configure um filtro de captura como "Limit each capture packet size to
100". Assim você não perde as sinalizações de TCP e TLS, e a captura é
pequena mesmo que muitos dados trafeguem.


Rubens


On Thu, Jan 3, 2019 at 10:16 AM Douglas Fischer <fischerdouglas at gmail.com>
wrote:

> Pois é...
> Vou ter que preparar um upload pequenininho para testar isso.
>
> Tentei fazer o sniffing com um upload de 800Gb, não deu muito certo.
> hahaha.
>
> Em qui, 3 de jan de 2019 às 10:06, Rubens Kuhl <rubensk at gmail.com>
> escreveu:
>
> > Esta me parece uma missão para o tcpdump. Mesmo com tráfego TLS dá para
> > concluir quem está puxando o tapete da conexão, e aí tentar entender o
> > motivo.
> >
> >
> > Rubens
> >
> >
> > On Thu, Jan 3, 2019 at 1:38 AM Douglas Fischer <fischerdouglas at gmail.com
> >
> > wrote:
> >
> > > Estamos fazendo uma migração de uma grande volume de dados(em TB e em
> > > número de arquivos) para a AZURE especificamente Office 365.
> > > Para isso utiliza-se uma ferramenta específica de cópia de dados em
> BLOB
> > > chamada AZCopy.
> > > https://github.com/Azure/azure-storage-azcopy
> > >
> > >
> > > Temos uma peculiaridade de termos uma boa parte desses dados em
> unidades
> > > remotas.
> > > (P.S.: É para acabar com isso que estamos migrando para a nuvem.)
> > >
> > > Em algumas dessas unidades, possuímos apenas links da NetVirtua.
> > > E por algum motivo desconhecido esse upload não funciona com links
> > > Net-Virtua.
> > >
> > >    O que me causa maior estranheza é que o
> > >    LINK FICA NA CAPACIDADE NOMINAL DE UPLOAD POR 15 MINUTOS
> > >    e então o AZCopy dá uma mensagem de falha.
> > >
> > > P.S.: Interessante informar que acesso a conteúdos do Office365
> > >       (E-mail, Teams, etc...) funciona corretamente por esse links.
> > >
> > >
> > > Eu já eliminei uma série de possíveis motivos para esse problema, e não
> > > encontrei nenhuma razão coerente como causa do problema...
> > >
> > >
> > > A única afirmação certeira que posso fazer até o momento é que:
> > > "O AZCopy não consegue enviar nada através de links da NetVirtua."
> > >
> > >  - Pensei que era Wifi.
> > >    Mudei para cabeada e mesmo assim problema persistiu.
> > >
> > >  - Pensei que era IPv6.
> > >    Fiz o Sniffing e a comunicação era em v4(Apesar de ter IPv6 rodando
> > > corretamente).
> > >    Desativei o IPv6 na máquina que iria fazer o Upload, e mesmo assim o
> > > problema persistiu.
> > >
> > >  - Pensei que podia estar relacionado com algum problema de CGNat.
> > >    Mas o mesmo problema aconteceu em duas unidades que usavam IPs
> > públicos.
> > >
> > >  - Pensei que fosse problema com configurações do roteador da rede
> > interna,
> > > ou com o computador de Upload.
> > >    Num dos locais que temos redundância de link Internet, usando o
> mesmo
> > > computador:
> > >    Foi só virar virar a redundância para o Link de uma operadora local
> e
> > > tudo funcionou lindamente.
> > >
> > >
> > > Cheguei a olhar alguns parâmetros do AZCopy, mas nada que fizesse
> sentido
> > > me saltou aos olhos.
> > >
> > >
> > > Fiquei imaginado que pudesse ser alguma assimetria de roteamento que
> > > evitasse a resposta vinda dos hosts que tocam esse serviço de blob da
> > > Microsoft.
> > > Mas não cheguei a nenhuma conclusão.
> > > Segue um tracert para auxiliar no diagnóstico.
> > >
> > >
> > >
> > > [douglas.fischer@<xxx>] <SAFE> /tool traceroute <xxx>.
> > > blob.core.windows.net
> > > use-dns=yes
> > >  # ADDRESS                          LOSS SENT    LAST     AVG    BEST
> > > WORST STD-DEV STATUS
> > >  1                                  100%    2 timeout
> > >  2 bb27b064.virtua.com.br             0%    1   7.2ms     7.2     7.2
> > > 7.2       0
> > >  3 embratel-g0-5-0-10-uacc02.cta...   0%    1  20.3ms    20.3    20.3
> > > 20.3       0
> > >  4 ebt-h0-15-0-0-tcore01.ctamr.e...   0%    1  34.5ms    34.5    34.5
> > > 34.5       0
> > >  5 ebt-b1421-tcore01.spo.embrate...   0%    1  32.1ms    32.1    32.1
> > > 32.1       0
> > >  6 ebt-h0-2-0-1-agg01.spo.embrat...   0%    1  26.5ms    26.5    26.5
> > > 26.5       0
> > >  7 peer-b54-2051-agg01.spo.embra...   0%    1  36.3ms    36.3    36.3
> > > 36.3       0
> > >  8 ae16-0.sao30-96cbe-1c.ntwk.ms...   0%    1  32.4ms    32.4    32.4
> > > 32.4       0 <MPLS:L=777721,E=0>
> > >  9 ae2-0.sao30-96cbe-1b.ntwk.msn...   0%    1  32.3ms    32.3    32.3
> > > 32.3       0 <MPLS:L=581271,E=0>
> > > 10 ae12-0.cpq02-96cbe-1b.ntwk.ms...   0%    1  34.8ms    34.8    34.8
> > > 34.8    0
> > > 11                                  100%    1 timeout
> > > 12                                  100%    1 timeout
> > > 13                                  100%    1 timeout
> > > 14                                  100%    1 timeout
> > >
> > >
> > > Alguém tem alguma ideia sobre a possível causa desse problema?
> > > Não creio que sejamos os únicos a utilizar links da Net-Virtua e
> também o
> > > os serviços de 365 com Blob.
> > >
> > >
> > >
> > > --
> > > Douglas Fernando Fischer
> > > Engº de Controle e Automação
> > > --
> > > gter list    https://eng.registro.br/mailman/listinfo/gter
> > >
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
> >
>
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter
>