Inicialmente eu ia ser um opositor da idéia de tentar "otimizar a WAN" do tráfego rsync, mas quanto mais eu pensava nisso, mais eu decidi que era possível.
Um compressor de dicionário baseado em TCP (que acredito que os equipamentos Steelhead da Riverbed podem fazer) provavelmente beneficiaria um fluxo rsync não criptografado. Presumivelmente, os dispositivos da Riverbed podem fazer criptografia no tráfego "otimizado", portanto, a execução do rsync não criptografado não deve comprometer a integridade ou a confidencialidade do tráfego para a WAN. (Entre o servidor de origem e o dispositivo Riverbed pode ser uma história diferente.)
Você não precisa executar o rsync por SSH. Ele funcionará perfeitamente bem em TCP ou qualquer outro transporte de fluxo confiável.
Parece que uma boa arquitetura de aceleração de WAN seria contrária a uma boa arquitetura de segurança, já que o tráfego criptografado seria de alta entropia e baixa redundância e não propiciaria a compactação. Acho que essas são preocupações que você precisa equilibrar. Eu não acompanho a Riverbed há alguns anos, mas isso realmente parece ser um lugar onde a descriptografia man-in-the-middle de protocolos criptografados pode fazer muito sentido (embora isso torne o acelerador WAN em um enorme alvo de ataques).
Editar:
Estou voltando a essa resposta algumas horas depois porque, francamente, está me mantendo acordada à noite.
Eu quero esclarecer algumas suposições que estou fazendo. Eu estou assumindo:
-
Você está trabalhando com links WAN significativamente mais lentos que uma LAN - 100 Mbps ou menos.
-
Você está realizando backups nesses links WAN que você gostaria de acelerar, em termos de tempo de exibição.
-
Os servidores que hospedam os arquivos de origem e destino têm conectividade de rede e CPU suficiente para saturar completamente o link WAN e a WAN é realmente o gargalo.
-
Você está usando sistemas operacionais com implementações TCP que podem dimensionar razoavelmente a janela de recebimento para acomodar o produto de atraso de largura de banda do seu link WAN.
Se os servidores não puderem saturar o link da rede, seu gargalo estará em outro lugar. Basicamente, estou assumindo que você tem um pequeno canal que seus servidores podem saturar ao executar backups. Se você está fazendo um gargalo na CPU ou na E / S dos servidores, nenhuma quantidade de "mágica" relacionada à rede irá ajudá-lo.
Falando sem rodeios, me sinto um pouco bobo falando positivamente sobre os dispositivos de aceleração de WAN. Eu tenho sido menos do que impressionado com eles no passado (principalmente a partir de uma perspectiva de ROI e custo) e desconfiado deles depois de ouvir inúmeras histórias de horror sobre o aplicativo e sistema operacional "estranheza" que desaparecem quando os aceleradores WAN foram desativados. Suspeitei deles como uma "tecnologia" e geralmente senti que eles são um sintoma do uso de protocolos mal planejados, decisões ruins sobre a colocação de servidores ou uma arquitetura de rede ruim.
Passei a maior parte de duas horas lendo em compressores de protocolo baseados em dicionário e brincando com o rsync. Eu acho que, dependendo da quantidade de redundância nas mudanças que você está sincronizando com o rsync, há realmente um potencial para ver alguma melhoria de desempenho menor usando um acelerador de WAN baseado em dicionário. Vai depender muito do aspecto dos seus dados.
Eu não tenho números usando um acelerador de WAN real para fazer isso. Também não tenho nenhuma experiência pessoal com aceleradores de WAN em uso de produção, muito menos "acelerando" o protocolo rsync. Eu certamente não iria sair e comprar algo baseado no que estou dizendo aqui, mas se você já tem algo em prática, eu consideraria rodar algum tráfego rsync não criptografado através dele para ver o que ele faz.