Uso del protocolo bittorrent para distribuir compilaciones de CI y nocturnas

Question

Esta pregunta continúa de acuerdo con lo que aprendí de mi pregunta de ayer titulada using git to distribute nightly builds.

En las respuestas a las preguntas anteriores estaba claro que el git no se ajustaba a mis necesidades y me animé a reexaminar usando BitTorrent.

---

versión corta

necesidad de distribuir versiones compiladas a 70+ personas cada mañana, le gustaría utilizar gitBitTorrent a equilibrar la carga de la transferencia.

Versión larga

NB. Puede omitir el párrafo siguiente si ha leído mi previous question.

Cada mañana tenemos que distribuir nuestra construcción nocturna en el estudio de más de 70 personas (artistas, evaluadores, programadores, producción, etc.). Hasta ahora, hemos copiado la compilación en un servidor y hemos escrito un programa de sincronización que lo recupera (usando Robocopy debajo); incluso con la configuración de espejos, la velocidad de transferencia es inaceptablemente lenta, demorando hasta una hora o más para sincronizarse en las horas punta (los períodos de menos de 15 minutos) lo que apunta a ser un cuello de botella de E/S de hardware y posiblemente un ancho de banda de red.

Lo que sabemos hasta ahora

Lo que he encontrado hasta ahora:

• he encontrado la excelente entrada en la Wikipedia sobre el BitTorrent protocol que era una lectura interesante (yo sólo tenía previamente conocido conceptos básicos de cómo funcionaban los torrentes). También encontré este StackOverflow answer en el intercambio BITFIELD que ocurre después del intercambio de información del cliente al servidor.

• También encontré el MonoTorrent C# Library (GitHub Source) que puedo usar para escribir nuestro propio rastreador y cliente. No podemos usar rastreadores o clientes fuera de la plataforma (por ejemplo, uTorrent).

Preguntas

en mi diseño inicial, que cuentan con nuestro sistema de construcción creación de un archivo .torrent y añadiendo que el rastreador. Me gustaría super-seed el torrente utilizando nuestros espejos existentes de la construcción.

Usando este diseño, ¿necesitaría crear un nuevo archivo .torrent para cada compilación nueva? En otras palabras, ¿sería posible crear un "rolling" .torrent donde, si el contenido de la construcción solo ha cambiado un 20%, eso es todo lo que necesita descargarse a obtener el último?

... En realidad.Al escribir la pregunta anterior, creo que necesitaría crear un nuevo archivo , sin embargo Podría descargarlo a la misma ubicación en la máquina de los usuarios y el hash automáticamente determinar lo que ya tengo. ¿Es esto correcto?

En respuesta a los comentarios

1. para la sincronización completamente nuevo toda la construcción (incluyendo: el juego, código fuente, los datos localizados, y las imágenes de disco para PS3 y X360) ~ 37.000 archivos y que viene en solo bajo 50 GB. Esto va a aumentar a medida que la producción continúa. Esta sincronización tardó 29 minutos en completarse en el momento en que solo se realizaron otras 2 sincronizaciones, que en el punto bajo si se tiene en cuenta que a las 9 a. M. Tendremos más de 50 personas que quieran obtener lo último.

2. Hemos investigado la E/S de disco y el ancho de banda de red con el departamento de TI; la conclusión fue que el almacenamiento en red se estaba saturando. También estamos registrando estadísticas en una base de datos de sincronizaciones, estos registros muestran que incluso con un puñado de usuarios, obtenemos tasas de transferencia inaceptables.

3. En lo que se refiere no utilizar clientes off-the-shelf, es una preocupación legal con tener una aplicación como uTorrent instalado en las máquinas de los usuarios, dado que otros elementos pueden ser fácilmente descargado usando ese programa. También queremos tener un flujo de trabajo personalizado para determinar qué compilación desea obtener (por ejemplo, solo PS3 o X360 dependiendo de qué DEVKIT tenga en su escritorio) y tener notificaciones de compilaciones nuevas disponibles, etc. Crear un cliente utilizando MonoTorrent no es la parte que me preocupa

Answer 1

A la pregunta si necesita o no crear un nuevo .torrent, la respuesta es: sí.

Sin embargo, dependiendo un poco del diseño de sus datos, es posible que pueda hacer algunas actualizaciones semi-delta simples.

Si la información que distribuye es una gran colección de archivos individuales, con cada compilación algunos archivos pueden haber cambiado simplemente puede crear un nuevo archivo .torrent y hacer que todos los clientes lo descarguen en la misma ubicación que el anterior (solo como sugieres). Los clientes primero verificaban los archivos que ya existían en el disco, actualizaban los que habían cambiado y descargaban nuevos archivos. El principal inconveniente es que los archivos eliminados no se eliminarán en realidad en los clientes.

Si escribe su propio cliente de todos modos, eliminar archivos en el sistema de archivos que no están en el archivo .torrent es un paso bastante simple que se puede hacer por separado.

Esto no funciona si distribuye un archivo de imagen, ya que los bits que permanecieron iguales en las versiones pueden haberse movido, y por lo tanto produciendo hashes de piezas diferentes.

No necesariamente recomiendo usar super-siembra. Dependiendo de cuán estricta sea la implementación de súper siembra que use, en realidad puede dañar las tasas de transferencia. Tenga en cuenta que el objetivo de la superposición es minimizar el número de bytes enviados desde la semilla, no maximizar la velocidad de transferencia. Si todos sus clientes se comportan correctamente (es decir, usando primero los más raros), la distribución de las piezas no debería ser un problema de todos modos.

Además, para crear un torrente y verificar hash un torrent de 50 GiB pone mucha carga en el disco, es posible que desee comparar la implementación de bittorrent que utiliza para esto, para asegurarse de que sea lo suficientemente eficiente. A 50 GiB, la diferencia entre las diferentes implementaciones puede ser significativa.

Answer 2

Solo para agregar otra opción a la mezcla, ¿ha considerado BITS? No lo uso yo mismo, pero al leer la documentación, admite un peer caching model distribuido que parece que logrará lo que desea. El inconveniente es que se trata de un servicio en segundo plano, por lo que renunciará al ancho de banda de la red en favor de la actividad iniciada por el usuario, agradable para sus usuarios pero posiblemente no lo que usted desea si necesita datos en una máquina apurada.

Aún así, es otra opción.

Answer 3

sólo quería añadir algunas sugerencias no BitTorrent para su lectura:

• Si la diferencia entre versiones compiladas no es significativa, es posible que pueda utilizar rsync para reducir el tráfico de red y disminuir la el tiempo que toma copiar la compilación. En una compañía anterior usamos rsync para enviar compilaciones a nuestro editor, ya que descubrimos que las imágenes de nuestros discos no cambiaban mucho de compilación a compilación.

• ¿Ha considerado simplemente escalonar las operaciones de copia para que los clientes no ralenticen la transferencia entre sí? Hemos estado usando un script de Python simple internamente cuando hacemos ramas de hito: el script se queda dormido hasta un tiempo aleatorio en un rango específico, se activa, descarga y revisa los repositorios necesarios y ejecuta una compilación. El usuario ejecuta el script al salir del trabajo para el día, cuando regresa tiene una copia nueva de todo listo para usar.

Answer 4

Usted podría utilizar BitTorrent sync ¿Qué es de alguna manera una alternativa a Dropbox, pero sin un servidor en la nube. Le permite sincronizar cualquier cantidad de carpetas y archivos de cualquier tamaño. con varias personas y usa los mismos algoritmos del bit del protocolo Torrent. Puede crear una carpeta de solo lectura y compartir la clave con otros. Este método elimina la necesidad de crear un nuevo archivo torrent para cada compilación.