Beschrieben wird ein komplett HTTP-basiertes Mirror-System, dass seine Kapazitäten automatisch je nach Lastverteilung anpasst.
Update: MirrorBrain tut fast genau das was ich meinte. Falls mal jemand sowas sucht…
Grundlage ist ein zentraler Server, der sämtliche Requests per GET erhält.
GET master.de/file/mybigfile.rar
(Hinweis: die Notation hier ist nicht ganz HTTP-konform, um gleichzeitig den empfangenden Server deutlich zu machen)
Ein serverseitiges Skript, dass per URL-rewrite den Angefragten Dateinamen erhält, leitet dann an einen (zufällig ausgewählten) der ihm bekannten Mirror für diese Datei per 302 Found weiter oder serviert die Datei selber. Dabei sind sowohl die Mirrors als auch der Master selbst gleich wahrscheinliche Quellen. Dabei führt er eine Statistik, welche Datei er am häufigsten selbst ausliefern musste. In regelmäßigen Abständen wird diese Statistik geprüft und einer der Mirror, die diese Datei noch nicht vorhalten, in Kenntnis gesetzt, dass eine Datei Spiegelung erfordert.
GET slave.de/control/needmirror/mybigfile.rar
Dieser Server wiederum prüft die Liste der „Bestellungen“ regelmäßig und spiegelt die Datei per normalem GET, so wie es ein Client tun würde. Damit wird auch dieser Request ggf. von einem Mirror beantwortet.
Ist die Datei vollständig übertragen, wird per HTTP-Request an den Zentral-Server ein neuer Mirror gemeldet:
GET master.de/control/mirrored/mybigfile.rar
Die Slave-Mirrors ändern mit jedem mal, bei dem sie eine Datei ausliefern deren „Last Accessed“ Dateisystemattribut. Somit können länger nicht abgefragte Dateien herausgefunden werden. Wird ein gewisses Limit seit dem letzten Download überschritten, kann die Datei vom Slave entfernt werden. Wird eine Datei deswegen gelöscht, meldet sich der Slave ab:
GET master.de/control/removed/mybigfile.rar
Existiert eine Datei auf einem Slave nicht, wird nie ein 404 gesendet, sondern ein 302 zurück auf den Master. Nur der Master kann 404 liefern, wenn er die Datei nicht findet.
Einfach umzusetzen ist dieses System in einer Apache/mod_rewrite/(PHP|Perl|Python|etc..)-Umgebung, jede andere, die das gleiche Protokoll implementieren kann ist geeignet.
Die Datenhaltung kann auf Flatfiles oder Datenbanken basieren. Flatfiles sind weniger Fehleranfällig, Datenbanken u.U. besser cachend.
Der Master führt eine manuell gewartete Liste von Mirror-Slaves, die dieses System unterstützen. Kommunikation über die /control/-channels sollte nur mit HOSTs von dieser Liste durchgeführt werden. Slaves sollten nur Kommunikation des bekannten Master akzeptieren. Ein Slave-Setup kommuniziert immer mit einem Master, es können jedoch (z.B. über Subdomains, Unterverzeichnisse o.Ä.) mehrere Slaves auf einem Host laufen.
