Google oficializa o protocolo DPLDPC
DPLDPC é uma das formas mais antigas de transporte de dados entre computadores, e ainda é a mais eficiente em termos de volume
Carlos Cardoso 2 anos atrás
DPLDPC é, assim como salada-mista uma brincadeira que entrega a idade. Ao mesmo tempo era a forma mais rápida de transporte de dados em uma empresa, é o protocolo disquete pra lá, disquete pra cá. Sim, antigamente a maioria das empresas não usavam rede, e mesmo hoje como o Google demonstrou, ainda é uma opção viável.
- Microsoft apresenta a DataCentreCam Submarina
- Intel anuncia Thunderbolt 2 e apresenta o protótipo de pendrive mais rápido do mundo
A DataMala do Google. Loura not included. (Crédito: Google)
Não disquetes, claro.
O fato é que redes ainda são lentas, e é muito fácil engargalar. Já participei de uma infra com 40 filiais acessando servidores em uma rede com um link internet de 64Kbps, e funcionava, inclusive os backups, mas se perdêssemos o link, não teríamos como ressincronizar, os dados novos + os na fila excederiam a capacidade da linha de dados.
Mesmo hoje isso é um problema. Como transportar toneladas de dados para um servidor na Nuvem, sem contratar links extremamente rápidos e caros, além de pagar as exorbitantes taxas de transferências? Felizmente isso foi resolvido lá nos Anos 1970, quando alguém no Laboratório de Propulsão a Jato da NASA cunhou a frase:
“Nunca subestime a largura de banda de um carro cheio de fitas em uma autoestrada”.
Uma Station Wagon da NASA. (Crédito: NASA)
A origem foi um problema entre as antenas da Deep Space Network, em Goldstone, e o JPL, separados por uns 300Km. Na época eles tinham vários links de dados, variando entre 1200bps (bits por segundo) e até dois links de luxo a incríveis 9600bps. Dava pro dia-a-dia, mas eis que uma obra na estrada meteu uma escavadeira e cortou todos os cabos.
Com os reparos levando pelo menos um ou dois dias, e os dados sendo constantemente gravados em fitas magnéticas, a NASA teve a idéia de manter o serviço funcionando, pegando uma Station Wagon, carregando com as fitas do dia e mandando o motorista levar tudo para o JPL.
O resultado foi um carro levando uma caixa de 24 fitas magnéticas, num total de 4.08GB de dados. Depois de 3h30min de viagem, as fitas foram entregues. Calculando, os 4.08GB foram “transferidos” a uma velocidade de 258.4kbps, mais de 100 vezes mais rápido que as linhas de dados disponíveis. DPLDPC, baby.
Hoje temos muito mais velocidade nos nossos links, mas os dados cresceram horrores. Então, como você transfere o banco de dados da sua empresa para um datacentre do Google, por exemplo?
Tabelinha de tempo de transferência de dados, mas como um monte de mamães e papais bem sabem, nunca confie na tabelinha. (Crédito: Google)
Nesta tabelinha do Google vemos que é complicado lidar com dados em quantidades industriais. Um link de 10Mbps levaria 12 dias para transferir 1TB. Isso dá pro Correio mandar um HD entre Rio e SP... ok, péssimo exemplo, já levaram 19 dias para me entregar uma encomenda SP-RJ. OK, Amazon. Isso daria pra Amazon entregar um HD várias vezes, no mesmo período de tempo.
Os dados de observações que geraram as imagens do buraco negro M87 ocuparam mais de 700TB. A única forma viável de transportar esses dados do Hawaii para o MIT foi despachar HDs em um avião. (Crédito: MIT)
Mesmo com um link de 100Mbps uma transferência de 1TB levaria 30 horas. 100 Terabytes levam 12 dias para ser transferidos. Isso em um link de 1Gb.
Por isso o transporte físico de dados ainda é a melhor opção, e aí entra o Google Cloud Transfer Appliance, uma espécie de servidor de arquivos portátil, se 35Kg é considerado portátil.
Com armazenamento em SSD, e capacidade de 40 ou 300TB, o equipamento vem com uma porta Ethernet 10Gb, e uma QSFP+ de 40Gb. A configuração é mínima, ele expõe um share NFS, você conecta de sua rede e enche o bicho.
Copiados os dados, você desliga o bicho, aplica o lacre de segurança, e ativa o DPLDPC; requisita a transportadora, e o Google cuida do resto.
Quais as vantagens? Bem, você não precisa levar uma semana para transferir os 300TB. Do lado do Google, eles têm uma padronização de hardware, não precisam depender de discos os servidores exóticos enviados pelo cliente.
Eles podem controlar quais processos de ingestão de dados estão na fila, e como os equipamentos são consistentes e padronizados, prever o tempo de duração de cada processo.
Telinha de configuração da appliance do Google (Crédito: Google)
Também acaba a burocracia de ficar de olho no hardware do cliente, e enviar de volta corretamente.
Esse tipo de serviço é extremamente conveniente, não só para migrações e deploy, mas também para backups, que não precisam de disponibilidade imediata. E não é de hoje, a Amazon tem o Snowball, praticando o bom e velho DPLDPC a pelo menos 5 anos.
Não duvido que a prática perdure, e nas futuras missões a Marte parte da carga sejam servidores levando cópias de boa parte da Internet, afinal é melhor consultar um artigo desatualizado na wikipedia, do que acessar com um ping de 43 minutos.
