Schnelle Netze erlauben ganz andere Cluster-Betriebsmodelle als noch vor wenigen Jahren. Das Booten auch via Weitverkehrsnetz sorgt dafür, dass sich die Test-, Einrichtungs- und Rekonfigurationszeiten von Cluster-Nodes drastisch reduzieren lassen. Damit werden ganz neue Cloud-Modelle denkbar. Alle wichtigen Komponenten, wie das jeweils optimale Betriebssystem, die geeignetesten Maschinen und der beste Ort für die konkrete Ausführung lassen sich dynamisch über größere geografische Entfernungen zusammenfügen, solange eine ausreichend hohe Netzwerkbandbreite zur Verfügung steht. Ein solches Modell lässt eine stärkere Spezialisierung zu, in der sich verschiedene, verteilte Gruppen um unterschiedliche Aspekte des Cluster-Betriebs kümmern.

Je nach zu bearbeitender Job-Klasse kann es attraktiv sein, das Modell eine Abstraktionsstufe zu heben und auf dem Grundsystem einer Basisinstallation verschiedene Virtualisierungsumgebungen wiederum übers Netz anzubieten. Die vorherige Job-Klassifikation sorgt dafür, dass dem Anwender ein sinnvoller Vorschlag unterbreitet wird, ob er entweder einen Pool von Maschinen mit einer speziell angepassten Softwareumgebung direkt bootet, eine bestimmte Art einer virtuellen Maschine komplett zum Ablaufen lassen auf einer bestimmten Anzahl von Cluster-Nodes bereitstellt oder der Job vom Scheduler in eine virtuelle Maschine zugeteilt wird.

Durch die Abstraktion von der eigentlichen Maschine durch Netzwerk-Boot oder eine Stufe weiter durch Virtualisierung, sollte es möglich werden, bestimmte Job-Klassen irgendwo laufen zu lassen. Das sollte es dann auch ermöglichen Jobs unter Umständen schnell über Kontinente hinweg zu verlagern, wenn der Overhead %(definieren)
klein genug ist und die Maschinenauslastung das nahe legt.

Denkt man die Idee des Grid-Portals weiter, könnten im einem weiteren Schritt auch virtuelle Maschinen für die Übermittlung erlaubt werden. Spezielle Beschreibungsdateien, wie das bereits erwähnte OVF, könnten dafür sorgen, dass man bei der Auswahl der Virtualisierungsart flexibel bleiben kann und sich nicht auf eine festlegen muss. Die Idee einer solchen Management-Schnittstelle existiert bereits (Sky Computing \cite{keahey:SkyComputing}). Mit Hilfe des Netzwerk-Boots wird man aber nicht auf die Verwendung einer Virtualisierung festgelegt. Außerdem ist sie eine einfache Möglichkeit verschiedene Virtualisierungslösungen anbieten zu können.

Das vorgeschlagene Cloud-Modell würde damit nicht zu einer Zentralisierung der Hardware an wenigen Orten führen und Single-Point-of-Failures schaffen. Zudem bliebe das Wissen der beteiligten Institutionen gewahrt, liesse sich aber deutlich schneller untereinander austauschen und ausprobieren. Gleichzeit hätte man ein Servicemodell für eine effizientere Aufgabenverteilung. So könnte es das Angebot von bestimmten Standardservices durch Dritte geben, in dem man einen bestimmten Bootserver auswählt und automatisch eine grundkonfigurierte Basissoftware für einen bestimmten Einsatzzweck erhält. Sollten sich Bandbreiten als ungenügend, das Delay oder Jitter als zu hoch herausstellen, hätte man jedoch mindestens die Grundlagen für diverse Test- und Klassifikationsszenarien.

% TODO: Ausformulieren
Nach ermutigenden Erfahrungen im BelWü stehen DFN-Tests über größere Distanzen an. Neue Herausforderungen bezüglich Latenzen und Schwankungen der Netzwerkparameter ergeben sich
sicherlich bei den Versuchen mit der Ausweitung nach Brasilien.