DE60131900T2

DE60131900T2 - Verfahren und system zur verwaltung von verteilten inhalten und verwandten metadaten

Info

Publication number: DE60131900T2
Application number: DE60131900T
Authority: DE
Inventors: Tsan-Fung San Marino Huang; Trygve San Lorenzo ISAACSON; James C. Jr. Portland FLOOD; Matthew San Francisco Orzen; Siew Young Cupertino SIM; Desmond Cho-Hung Mountain View CHAN; Wencheng San Jose CHAI; George Harlow Palo Alto MILLS
Original assignee: FLOOD JAMES C JUN; Flood James C jun Portland; HUANG TSAN FUNG; Intel Corp
Current assignee: Flood James C Jun Portland Oreg Us; Huang Tsan-Fung San Marino Calif Us; Isaacson Trygve San Lorenzo Calif Us; Orzen Matthew San Francisco Calif Us; Intel Corp
Priority date: 2000-10-26
Filing date: 2001-10-26
Publication date: 2008-12-04
Anticipated expiration: 2021-10-27
Also published as: WO2002035359A3; EP1364510A2; ATE381191T1; HK1058279A1; EP1364510B1; DE60131900D1; AU2002214659A1; US7272613B2; WO2002035359A2; US20020133491A1

Description

Stand der Technik
Gebiet der Erfindung
Die vorliegende Erfindung betrifft das Speichern und die Verteilung von Inhalten bzw. Content über ein Netzwerk.
Beschreibung des Stands der Technik
Die Fortschritte im Bereich der Kommunikation und des Switching in Telelcommunikationsnetzwerken schreiten mit enormer Geschwindigkeit voran. Die Verteilung von Dateien zwischen Netzwerkpositionen bzw. Netzwerkstandorten kann unter Verwendung herkömmlicher Techniken jedoch ziemlich lange dauern. Der Übertragungs- bzw. Übermittlungsfluss kann uneinheitlich sein. Wenn zum Beispiel große bzw. umfangreiche Inhalte, wie etwa eine Mediendatei eines Films zu einem Benutzer übertragen wird bzw. werden, können während der Übermittlung unzulässige bzw. nicht akzeptierbare Verzögerungen auftreten.
Bei einer herkömmlichen Technik zur Vermeidung von Verzögerungen bei der Präsentation von Inhalten an einen Benutzer handelt es sich um die Replikation von Kopien des Inhalts an verschiedenen Positionen bzw. Stellen in dem Netzwerk. Eine derartige Replikation kann die Verzögerung für einen Benutzer in der Nähe einer verfügbaren Kopie reduzieren, jedoch erfordert sie eine übermäßige Menge an Speicherplatz. Der Overhead der Verwaltung steigt ebenfalls an. Eine Management- bzw. Verwaltungsanwendung wird benötigt, so dass Administratoren und/oder Benutzer die replizierten Kopien des Inhalts verwalten können. Die Speicheradministratoren müssen ferner konstant wachsam sein, da für den Fall, dass an einem Ort bzw. Standort der Speicherplatz ausgeht, eine neue Replikation des Contents bzw. des Innalts fehlschlägt.
Zu weiteren Techniken zählt das Proxy Caching auf Anwendungsebene, wie etwa das Web bzw. Internet Caching und das Streaming Caching. Ein derartiges Caching erfordert nicht den Einsatz nicht verwaltbarer Mengen von Speicherkapazität, sondern löst das Problem nur für eine begrenzte Anzahl von Fällen, wo der Content bzw. die Inhalte bereits an den anfordernden Positionen im Cache gespeichert worden sind. Wenn ein Benutzer Inhalte anfordert, die noch nicht im Cache gespeichert worden sind, wo müssen die Inhalte bzw. der Content vom Kern abgerufen werden, und wobei die Verzögerung nicht akzeptabel sein kann. Eine weitere große Einschränkung des Caching-Ansatzes ist es, dass er auf eine bestimmte Anwendung beschränkt ist.
In "Enhancement and validation of Squid's cache replacement policy" von J. Dilley et al., HP Labs 1999 Technical Report, 31. Mai 1999, Seiten 1 bis 17, beschreibt ein Internet Caching System und im Besonderen einen Cache Replacement-Ansatz (Cache-Auswechselungsansatz). Eine Heap- bzw. Halden-basierte Implementierung fügt einem Referenzzählwert in einem LFU (Least Frequently Used) Cache Replacement-Ansatz ein Alter hinzu. Die Altersimplementierung neigt dazu, unter den am wenigsten genutzten Objekten die am längsten nicht verwendeten (least recently used) Objekte zu bevorzugen. Zwischen einem Höchst- und Niedrigststand wurde durch einen einfachen Mechanismus Raum erhalten, wobei Objekte unabhängig von ihrem Alter ausgestoßen werden, wobei nur der Altersschlüssel (Heap Key) berücksichtigt wird. Objekte werden entfernt, bis eine Begrenzung max_scan oder max_remove bzw. die Untergrenze erreicht wird.
Benötigt werden ein Verfahren und ein System zum Speichern und für die Verteilung von Inhalten bzw. Content über ein Netzwerk, wobei das Verfahren und das System eine Latenz über lange Übertragungsstrecken eliminieren können, und wobei keine Replikation in Höhe von 100% an alle Standorte bzw. Positionen erforderlich ist. Benötigt werden ein Verfahren und ein System zum Speichern und zur Verteilung von Inhalten bzw. Content, wobei eine intelligente Speicherverwaltung bereitgestellt wird auf der Basis der Nutzung und des Standort-transparenten Zugriffs, und wobei die Verwaltung Anwendungs-agnostisch ist, das heißt, sie kann mit anderen Anwendungsarten eingesetzt werden.
Zusammenfassung der Erfindung
Vorgesehen ist gemäß der vorliegenden Erfindung ein Verfahren zur effizienten Speicherverwaltung in einem verteilten Netzwerk nach Anspruch 1.
Weitere Ausführungsbeispiele der Erfindung sind in den Unteransprüchen enthalten.
Beschreiben werden ein Verfahren und ein System zur Erzeugung eines innovativen Dateisystems, das dessen Verzeichnisdarstellung von dessen Datenspeicher trennt. Dies erreicht ein angemessenes Gleichgewicht zwischen der Anforderung für eine einheitliche schnelle Zustellung sowie der Reduzierung der Speicheranforderungen. Das Verfahren und das System umfassen die Aufteilung, Verteilung und Wiedervereinigung/neues Zusammensetzen von Dateien, wobei die Präsentation bzw. Darstellung des Inhalts bzw. des Contents an den Benutzer nicht verzögert wird, wobei aber auch eine reduzierte Speicherraumgröße im Vergleich zu herkömmlichen Techniken eingesetzt wird. Das Verfahren und das System verwenden auch die Erzeugung eines integrierten Lese-Schreibfähigen Dateisystems sowie die Verteilung von Dateisystemobjekten, die Volumina, Verzeichnisse und Dateien enthalten. Das Verfahren und das System sind in der Lage, die Integrität der Dateisystemobjekte zu verwalten und zu steuern, die über das Netzwerk verteilt sind, und zwar unter Verwendung der Metadaten- und Metadateisystemarchitektur, und wobei das Verfahren und das System ferner unter Verwendung eines VFCS (Virtual File Control System) oder eines VFCS-Clusters Dateien in Echtzeit serven und rekonstruieren können. Die Metadaten- und Metadateisystemarchitektur stellt Mittel für Verteilungs-Server (DS als englische Abkürzung von Distribution Server) und das VFCS bereit, um die verteilten Informationen im Netzwerk zu überwachen, während das VFCS die organisierte bzw. strukturierte Wiederzusammensetzung der Informationen für die Übertragung bzw. Zustellung an den Benutzer vornimmt.
Ebenso beschrieben wird ein verbesserter Mechanismus für die Erzeugung eines integrierten Lese-Schreib-fähigen Dateisystems zur Verteilung großer Dateien über ein Computernetzwerk sowie für die Übertragung derartiger Dateien an Endbenutzersysteme oder Anwendungsserver. Bei einer Implementierung stellt der Mechanismus mehreren Benutzern von vielen verschiedenen Standorten eine Möglichkeit bereit, Zugriff auf Dateisystemobjekte zu erhalten, ohne dabei die Netzwerkressourcen übermäßig zu belasten. Wenn ein Benutzer zum Beispiel eine große Datei downloaden möchte, wie etwa eine Videodatei, so stellt der Mechanismus eine Möglichkeit bereit, diese Videodatei zu dem anfordernden Benutzer zu übertragen, ohne dabei das Netzwerk zu stark zu belasten. Das System erreicht dies durch ein Aufteilen der Datei in mehrere Abschnitte (Segmente oder Blockdateien) sowie durch das Speichern dieser Abschnitte an Stellen (z. B. Knoten), die über das Netzwerk verteilt sind. Beschreiben wird eine Technik zur Erzeugung eines Lese-Schreib-fähigen integrierten Dateisystems. Ebenso beschrieben wird eine Technik zur Aufteilung der Datei sowie zur Rekonstruktion dieser für die Verteilung sowie eine Technik zur Verteilung von Dateisystemobjekten.
Beschrieben wird ein Verfahren zur Erzeugung einer integrierten Dateisystemdarstellung auf der Basis einer Metadateisystemstruktur und der Objektmetadaten selbst, welche die Trennung der Dateisystemdarstellung und dessen Daten unterstützt, während die Daten über ein Netzwerk von Knoten lokalisiert werden und danach zeitgerecht und transparent für die Benutzer des Systems wieder zusammengesetzt werden können.
Ferner beschrieben wird die Aufteilung der Dateien in verwaltbare, nicht zusammenhängende Dateisegmente, die neue Anordnung der Dateisegmente und die Verteilung dieser nicht zusammenhängenden Dateisegmente für eine optimale Performance der Netzwerkknoten. Die nicht zusammenhängenden Dateisegmente werden wieder zusammengesetzt für eine Verteilung an einen Client, der die große Nutzlastdatei anfordert. Der Prozess des Wiederzusammenbaus ist für den Benutzer transparent und stellt die Dateidaten an den Benutzer mit minimaler Latenz bereit.
Beschrieben wird ein weiteres Verfahren für die Verteilung, Replikation und Synchronisation von Dateisystemobjekten unter einem Netzwerk aus Knoten.
Ein weiterer Teil der Beschreibung richtet sich an die Bereitstellung von nicht zusammenhängenden Dateisegmenten durch die globale Dateisystemdarstellung, während der ursprüngliche, nicht in Chunks aufgeteilte Inhalt Benutzern als ein Verzeichnis dargestellt wird.
Ferner beschrieben wird die Anwendung von Verteilungs- und Behandlungsrichtlinienn, um eine garantierte Dienst- bzw. Servicequalität zu ermöglichen.
Ebenfalls beschrieben wird, wie mehrere VFCS als ein Virtual File System Gateway Cluster gruppiert werden können, welcher die E/A-Bandbreite erhöht, während gleichzeitig Lastausgleich (Load Balancing) und Fehlertoleranz bereitgestellt werden.
Zu den Vorteilen des beschriebenen Systems und Verfahrens zählt die Fähigkeit, große Nutzlastdateien zu speichern, zu überwachen bzw. zu verfolgen, zu erteilen und wieder zusammenzusetzen, ohne die Präsentation bzw. die Darstellung von Inhalten an den Benutzer zu verzögern, wobei ferner auch nur ein minimaler Speicherraum erforderlich ist.
Beschrieben werden ein Verfahren und eine Vorrichtung zum effizienten Speichern großer Dateien. Ein Content-Netzwerk zur Übertragung von Dateien zu einem Benutzer umfasst eine Mehrzahl von Speicherelementen, die sich in einer Reihe geografisch verteilter Netzwerkknoten befinden und so konfiguriert sind, dass sie Abschnitte einer Datei speichern. Eine Software-Managementstruktur speichert Informationen über den Inhalt und die Position bzw. den Ort jedes der Speicherelemente in Bezug auf die Datei. Eine Software-Inhalts-Pruning-Struktur ist mit der Software-Managementstruktur gekoppelt und so konfiguriert, dass die in den Speicherelementen gespeicherten Inhaltsblöcke selektiv beschnitten werden, um sicherzustellen, dass die Datei in dem Netzwerk effizient gespeichert wird.
Die Abschnitte und die Größe einer an jedem Knoten gespeicherten Datei sind abhängig von dem verfügbaren Speicher, der Popularität des Inhalts, der Verteilungskriterien des Eigentümers der Inhalte, etc. Somit können die Blöcke einer Datei, deren Verwendung am wenigsten wahrscheinlich ist, beschnitten werden (d. h. aus dem lokalen Speicher gelöscht werden), um Platz für Inhalte zu schaffen, die mehr nachgefragt werden. Obgleich jedoch die Blöcke einer Datei beschnitten werden, die mit der geringsten Wahrscheinlichkeit verwendet werden, kann der ganze Inhalt einer Datei an einem Knoten in dem skalierbaren Netzwerk für die Lieferung von Inhalten (Content Delivery Network) verwaltet werden, solange der Eigentümer bzw. der Besitzer des Inhalts möchte, dass der Content in dem Netzwerk verbleibt. Auf diese Weise können sehr große Dateien effizient gespeichert werden.
Weitere Merkmale und Vorteile der vorliegenden Erfindung sowie der Aufbau und der Betrieb verschiedener Ausführungsbeispiele der vorliegenden Erfindung werden nachstehend in Bezug auf die beigefügten Zeichnungen näher beschrieben.
Kurze Beschreibung der Zeichnungen
Die beigefügten Zeichnungen, die hierin enthalten sind und einen Bestandteil der Patentschrift bilden, veranschaulichen die vorliegende Erfindung und dienen in Verbindung mit der Beschreibung der Erläuterung der Grundsätze der Erfindung sowie dazu, es einem Fachmann auf dem Gebiet zu ermöglichen, die Erfindung nachzuvollziehen und zu nutzen. In den beigefügten Zeichnungen zeigen:
1 eine Darstellung eines skalierbaren Content Delivery Networks für die Zustellung bzw. Übertragung von Dateisystemobjekten gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
2 eine Darstellung einer virtuellen Baumanordnung der Knoten für die Steuerinformationskommunikation gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
3 eine Darstellung einer Attribut-Bitmail und einer Rolled Up-Bitmap gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
die 4A–4C vereinfachte Layouts eines Verteilungszentrums gemäß Ausführungsbeispielen der vorliegenden Erfindung;
die 5A–5C drei veranschaulichende Ausführungsbeispiele der Anwendungsserver-Cluster gemäß der vorliegenden Erfindung;
6 ein Layout eines Virtual File Control System-Clusters gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
die 7A–B den Prozess des Einführens eines neuen Dateisystemobjekts in einen SCDN oder des Aktualisierens oder Löschens eines bestehenden Dateisystemobjekts aus dem SCD gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
7C die Anwendung von Richtlinien für die Service- bzw. Dienstqualität auf der Basis des Dateisystemobjekts und des Objekttyps gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
8 eine Darstellung linearer und nicht-linearer Strukturen, wie diese in der vorliegenden Erfindung eingesetzt werden;
9 den Prozess der Zerlegung einer Datei in Blockdateien zur Speicherung gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
die Figuren 10A–B zwei Darstellungen der zerlegten Datei gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
die 11A–B veranschaulichende Ausführungsbeispiele der Verteilung eines Dateisystemobjekts und der Metadaten in dem Netzwerk gemäß der vorliegenden Erfindung;
11C die Art und Weise, wie Verteilungsserver zusammenarbeiten, um Metainformationen und Inhalte dynamisch zu verteilen und zu replizieren, so dass jeder Server eine globale Dateisystemansicht darstellt, die eine aggregierte Ansicht des ganzen Netzwerks darstellt;
die 12A–C veranschaulichende Ausführungsbeispiele der Metadateisystemstruktur, der Blockdateistruktur eines zugrunde liegenden Dateisystems und von Metadatenbeispielen gemäß der vorliegenden Erfindung;
die 13A–C veranschaulichende Ausführungsbeispiele der Datenträger-, Verzeichnis- und Datei-Metadaten gemäß der vorliegenden Erfindung;
13D ein veranschaulichendes Ausführungsbeispiel von Blockindexanordnungs-Metadaten gemäß der vorliegenden Erfindung;
14A ein Diagramm des Prozesses der Rekonstruktion einer Datei aus einer oder mehreren Blockdateien gemäß der vorliegenden Erfindung;
14B ein Diagramm des Algorithmus zum Lokalisieren von Daten in dem Prozess der Rekonstruktion einer Datei in Echtzeit gemäß der vorliegenden Erfindung;
die 15A–C drei veranschaulichende Ausführungsbeispiele eines VFCS gemäß der vorliegenden Erfindung;
16 ein Flussdiagramm der Operationen eines VFCS-Servers, die während dem VFCS-Initialisierungsprozess ausgeführt werden, um eine globale Dateisystemdarstellung gemäß einem Ausführungsbeispiel der vorliegenden Erfindung zu erzeugen;
17A die VFCS-Server-Operationen, die während Laufzeit gemäß einem Ausführungsbeispiel der vorliegenden Erfindung ausgeführt werden;
17B die Anwendung von Richtlinien für die Service- bzw. Dienstqualität auf der Basis des Benutzers und des Dateisystemobjekttyps gemäß der vorliegenden Erfindung;
18 eine Darstellung der VFCS-Module gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
19 ein Flussdiagramm der Operationen eines VFCS-Servers, der eine Leseanforderung gemäß einem Ausführungsbeispiels der vorliegenden Erfindung bearbeitet;
20 ein Diagramm einer Server-Anforderungsverteilungsfähigkeit einer SCDN Lastverteilungseinrichtung gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
21 ein Diagramm einer Server-Redundanzfunktion, die durch eine SCDN Lastverteilungseinrichtung gemäß einem Ausführungsbeispiel der vorliegenden erfindung bereitgestellt wird;
22 ein Diagramm einer Instant-Failover-Funktion einer SCDN Lastverteilungseinrichtung als zustandslose Lastverteilungseinrichtung gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
23 ein Diagramm einer SCDN Lastverteilungseinrichtung, welche in Paket neu leitet, gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
24 ein veranschaulichendes Ausführungsbeispiel einer SCDN Lastverteilungseinrichtung, die Pakete mit direkter Serverrückführung gemäß einem Ausführungsbeispiel der vorliegenden Erfindung umleitet;
25 ein Flussdiagramm eines eingehend gerichteten Paketumleitungsprozesses, der von einer SCDN Lastverteilungseinrichtung ausgeführt wird, gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
26 ein Flussdiagramm eines Gesundheitsprüfungsprozesses, der von einer SCDN Lastverteilungseinrichtung ausgeführt wird, gemäß einem Ausführungsbeispiel der vorliegenden Erfindung;
27 eine Darstellung einer Station, welche eine exemplarische Steuereinheit und Datendepots darstellt;
28 ein Zustandsdiagramm der Speicherverwaltungsschritte, die gemäß einem Ausführungsbeispiel der vorliegenden Erfindung ausgeführt werden;
die 29A–E eine Unterteilung der Operationen aus 28 in kleinere Teilaufgaben;
30 die Speicherverwaltungs-Wissensbasistabellen; und
31 ein beispielhaftes Computersystem- und Computerprogrammprodukt, in dem die vorliegende Erfindung überwiegend in Software implementiert wird.
Genaue Beschreibung der bevorzugten Ausführungsbeispiele
Die folgende Beschreibung betrifft die besten Ausführungsmodi, die gegenwärtig für die Ausführung der Erfindung in Erwägung gezogen werden. Diese Beschreibung ist nicht einschränkend auszulegen, vielmehr dient sie lediglich dem Zweck der Beschreibung der allgemeinen Grundsätze der Erfindung. Der Umfang der Erfindung ist in Bezug auf die Ansprüche zu bestimmen.
Die vorliegende Erfindung betrifft ein Verfahren und ein System zum Speichern und Verteilen von Inhalten bzw. Content. Im Besonderen stellt die vorliegende Erfindung eine in hohem Maße effiziente Architektur und Technik bereit, um Inhalte zu verarbeiten, zu speichern und um Inhalte an einen Benutzer für Schulungszwecke, zur Unterhaltung, für geschäftliche Zwecke oder für jeden anderen gewünschten Zweck bereitzustellen. Bei einem Verfahren und System gemäß einem Ausführungsbeispiel der vorliegenden Erfindung wird ein hoch entwickeltes Lese-Schreib-fähiges integriertes Netzwerkdateisystem erzeugt, bei dem die Verzeichnispräsentation und die Datenspeicherung getrennt werden. Das Verfahren und das System umfassen die Aufteilung, die Verteilung und das Wiederzusammensetzen der Dateien, wobei die Präsentation von Inhalten an den Benutzer nicht verzögert werden, wobei aber auch kein unangemessen hoher Speicherplatz benötigt wird. Das Verfahren und das System umfassen ferner die Erzeugung eines integrierten Dateisystems und die Verteilung von Dateisystemobjekten, einschließlich Volumina, Verzeichnissen und Dateien.
Die Erfindung wird beschrieben in Bezug auf spezifische Architekturen und Protokolle. Der Fachmann auf dem Gebiet wird erkennen, dass die Beschreibung der Veranschaulichung dient sowie zur Bereitstellung der besten Ausführungsart der Erfindung. Ein Ausführungsbeispiel der vorliegenden Erfindung stellt einen verbesserten Mechanismus zur Aufteilung und Verteilung von Dateien (bezeichnet als Nutzlast bzw. Payload oder Inhalt bzw. Content) in einem Computernetzwerk bereit. Ein weiteres Ausführungsbeispiel der vorliegenden Erfindung stellt ein Verfahren zur Erzeugung einer integrierten Dateisystemansicht mit mehreren Inhaltsknoten bzw. Content-Knoten bereit. Vorgesehen ist gemäß einem weiteren Ausführungsbeispiel der vorliegenden Erfindung ein Verfahren zum Verteilen, Replizieren und Synchronisieren der Aktualisierung von Dateisystemobjekten, wie etwa von Volumina, Verzeichnissen und Dateien. In der folgenden Beschreibung sind zahlreiche besondere Einzelheiten ausgeführt, um eine umfassendere Beschreibung der Ausführungsbeispiele der Erfindung zu vermitteln. Die Beschreibung ist nicht einschränkend auszulegen. Zum Beispiel wird auf das Internet Protocol und UNIX verwiesen, wobei jedoch jedes Paketprotokoll und jedes Betriebssystem eingesetzt werden können.
Wenn die Erfindung gemäß einem Ausführungsbeispiel der vorliegenden Erfindung implementiert wird, so wird Endbenutzersystemen eine Möglichkeit bereitgestellt, auf Dateisystemobjekte zuzugreifen, ohne das Netzwerk zu stark zu belasten, welches das Endbenutzersystem jeweils für die Datenübermittlung verwendet. In einem Ausführungsbeispiel der vorliegenden Erfindung erreicht das System dies, indem die Datei in mehrere Abschnitte bzw. Teilstücke (Segmente oder Spuren) aufgeteilt wird, und wobei diese Abschnitte und andere Dateisystemobjekte an Orten bzw. Stellen (z. B. Knoten) gespeichert werden, die über das Netzwerk verteilt sind. Die Abschnitte und sonstigen Dateisystemobjekte, die im Netzwerk gespeichert sind werden unter Verwendung einer Flussoptimierungstechnik verteilt, die eine intelligente Verwaltung aller Dateisystemobjekte und Datenabschnitte bereitstellt. Somit werden Dateisystemobjekte und Abschnitte der Datei an Stellen bzw. Orten gespeichert, welche die benötigte Zeit minimieren, um den Abschnitt an das Endbenutzersystem zu liefern bzw. zu übertragen. Die Orte bzw. Stellen minimieren die Latenz, die der Zustellung der Daten an das Endbenutzersystem zugeordnet ist, und wobei diese Stellen hierin als der Rand des Netzwerks bezeichnet werden.
Jeder Knoten am Rand des Netzwerks, der die Aspekte der Erfindung ausführt bzw. aufweist, ist so konfiguriert, dass er so erscheint, als ob die Datei lokal gespeichert wäre, wenn Abschnitte der Datei tatsächlich an anderen Knoten gespeichert sind, die in dem Netzwerk verteilt angeordnet sind. Dies erhöht erheblich die virtuelle Speicherkapazität jedes Netzwerkknotens, ohne Systemressourcen zu verbrauchen. Die Knoten verteilen und replizieren Datenblöcke und andere Dateisystemobjekte in einer Art und Weise, welche die Datenübertragungseffizienz maximiert, während der Bandbreitenverbrauch minimiert wird. Wenn das Endbenutzersystem eine Anforderung von Inhalten bzw. Content ausgibt (z. B. für eine Datei), so wird die Anforderung zu dem am nächsten gelegenen Knoten geleitet, und der Knoten importiert nicht-residente Daten des angeforderten Inhalts von anderen Knoten auf eine Art und Weise, welche die geringste Zeit und die niedrigsten Kosten erfordert. Das Endergebnis ist es, dass jeder Netzwerkknoten auf zahlreiche oder alle Dateisystemobjekte (Volumina, Verzeichnisse und Dateien) zugreifen kann bzw. Zugriff hat, ohne dass der ganze Inhalt bzw. Content jedes dieser Objekte lokal gespeichert und verwaltet werden muss.
Vorgesehen sind gemäß einem oder mehreren Ausführungsbeispielen der vorliegenden Erfindung effiziente Verfahren und Systeme zur Aufteilung bzw. Zerlegung einer Datei zum Speichern und zur Rekonstruktion der Datei für die Zustellung bzw. Übertragung. Der Prozess der Aufteilung einer großen Nutzlastdatei wird als "Chunking" oder Zerlegung bezeichnet und wird nachstehend im Text näher beschrieben. Vorgesehen ist gemäß einem weiteren Ausführungsbeispiel der vorliegenden Erfindung ein Verfahren zur Erzeugung eines integrierten Dateisystems aus mehreren Knoten. Vorgesehen ist gemäß einem weiteren Ausführungsbeispiel der vorliegenden Erfindung ein Verfahren zum Verteilen, Replizieren und Synchronisieren von Dateisystemobjekten unter einem Netzwerk von Knoten. Vorgesehen sind gemäß einem weiteren Ausführungsbeispiel der vorliegenden Erfindung ein Verfahren und ein System zum Anordnen einer Gruppe von virtuellen Dateisystemen in Clustern. Diese Anordnung in Clustern einer Gruppe von virtuellen Dateisystemen erhöht die Zuverlässigkeit und die Verfügbarkeit und steigert gleichzeitig die E/A-Bandbreite durch Lastverteilung bzw. Lastausgleich. Diese Ausführungsbeispiele werden nachstehend im Text näher beschrieben.
A. Netzwerkarchitektur
1. Skalierbares Content Delivery Network
Die Abbildung aus 1 zeigt eine Ansicht eines skalierbaren Netzwerks für die Lieferung von Inhalten (Scalable Content Delivery Network bzw. SCDN) 100 für die Zustellung bzw. Übertragung großer Nutzlasten gemäß einem Ausführungsbeispiel der vorliegenden Erfindung. Bei dem SCDN 100 kann es sich um ein Netzwerk wie das Internet handeln, das konzeptuell einen Netzwerkkern 105 (d. h. den Backbone), intermediäre Netzwerksegmente 110, die von "nah an" und "weit von" dem Kern angeordnet reichen, und Netzwerksegmente, die "fern" von dem Kern angeordnet sind 120-A bis 120-C (gemeinsam 520). "Nah" bzw. "nah an" und "weit" bzw. "weit von" beziehen sich auf die Entfernung bzw. den Abstand und sollen die relativen Weg- bzw. Pfadlatenzen (kurz bzw. lang) zu dem Kern anzeigen, wobei diese Latenzen allgemein abhängig sind von der Anzahl der intermediären Hubs (z. B. Switches, Router und dergleichen), die gekreuzt bzw. passiert werden, um die Hochgeschwindigkeits-Backbones zu erreichen, welche den Kern des Netzwerks bilden, und durch welche der Netzwerkverkehr geleitet wird. Hiermit wird festgestellt, dass jeder intermediäre Hub eine gewisse beschränkte Verarbeitung ausführen kann, welche Latenz hinzufügt, bevor der Verkehr zu dem nächsten Hub weitergeleitet wird.
Die Abbildung aus 1 zeigt eine Mehrzahl von Content Provider Clients (CPCs) 130, eine Mehzahl von Endbenutzer-Clients (EUCs als englische Abkürzung von End-User Clients) 150 und einen oder mehrere Content Management Server (CMS) 170, die alle jenseits des Netzwerkrands 101 angeordnet sind. Diese Anordnung dient der Veranschaulichung und schränkt die Erfindung nicht ein. Zum Beispiel können sich ein CPC 130, EUC 150 und/oder CMS 170 an jeder Stelle in einem Netzwerk befinden, auch jenseits des Netzwerkrands, an einem Netzwerkrand oder an einer beliebigen Stelle innerhalb eines Netzwerks, wie zum Beispiel in einem Netzwerksegment oder Kern.
Im Allgemeinen kann der Content Provider Client 130 mit einem Content Management Server 170 verbunden (oder diesem zugeordnet) werden, der wiederum mit dem ihm zugeordneten Verteilungszentrum 140 verbunden ist, oder der Content Provider Client 130 kann mit jedem beliebigen Verteilungszentrum 140 verbunden werden (oder diesem zugeordnet sein). In dieser Umgebung kann jeder Anschluss bzw. jede Verbindung eingesetzt werden, die durch das SCDN 100 unterstützt werden. Zu den Beispielen für derartige Verbindungen zählen unter anderem ein physikalischer Übermittlungsabschnitt bzw. Link, (über jedes kabelgebundene oder kabellose Medium), ein Datenübermittlungsabschnitt, ein logischer Übermittlungsabschnitt, eine permanente virtuelle Schaltung, eine geschaltete virtuelle Schaltung, ein verbindungsorientiertes Protokoll, ein verbindungsloses Protokoll sowie jede andere direkte oder indirekte Netzwerkverbindung und/oder jedes Protokoll und Kombinationen dieser.
Ein Content Provider Client kann eine Anwendung zur Verwaltung von Inhalten in dem Netzwerk darstellen, wobei es sich dabei aber auch um einen allgemeinen Dateisystem-Client handeln kann, der eine Verbindung mit einem Virtual File Control System (nicht abgebildet) in einem Verteilungszentrum 140 aufweist. Ein Content Owner (Inhaltseigentümer) erstellt, benennt um, verschiebt, löscht und verwaltet Datenträger bzw. Volumen und Verzeichnisse über einen entsprechenden CPC 130. Ein Content Owner lädt ferner Dateien über seinen bzw. ihren CPC 130 in das SCDN 100 hoch, aktualisiert und verwaltet diese Dateien. Der EUC 150 ermöglicht einem Endbenutzer des Inhalts Zugriff auf die Dateien in den SCDN 100. Zum Beispiel kann es sich bei dem EUC 150 um jede Art von Browser (insbesondere einen Web-Browser oder jeden Dateisystem-Browser) handeln, der auf der lokalen Vorrichtung des Endbenutzers läuft. Dabei kann jede Art von Endbenutzervorrichtung eingesetzt werden, die einen Endbenutzer-Client 150 unterstützen kann, insbesondere ein Computer (z. B. ein Personalcomputer, eine Workstation oder ein Server), eine Set-Top-Box, ein Fernseher, ein Telefon oder eine Handheld-Computervorrichtung (z. B. Organizer, Palm-Top-Geräte).
Der Netzwerkrand 101 kann weit von dem Netzwerkkern 105 entfernt sein. Der Abstand bzw. die Entfernung (d. h. die Strecken- bzw. Pfadlatenz) zwischen dem Kern und dem Rand kann jedoch uneinheitlich sein und in Bezug auf einen bestimmten CPC oder EUC erheblich variieren. In einem Ausführungsbeispiel der vorliegenden Erfindung wird eine Mehrzahl von Verteilungszentren (DC) 140A–140I zur Nutzlastverwaltung am Rand des Netzwerks platziert, wodurch die Latenz für entsprechende Endbenutzer-Clients 150 reduziert oder eliminiert wird. Der Nutzlastinhalt von einem Content Owner wird von einem Verteilungszentrum zu anderen Verteilungszentren am Rand des Netzwerks übertragen. Ein Endbenutzer, der auf einen bestimmten Nutzlastinhalt zugreifen möchte, wird von dem am nächsten gelegenen Verteilungszentrum bedient (über einen Netzwerkdateisystem-Client oder einen Anwendungsserver), welches den gewünschten Inhalt aufweist. Die Latenz aufgrund von Streckenaspekten wird minimiert, da Inhalte bzw. Content über eine Mehrzahl von Anwendungsservern (AS) 160 und Verteilungszentren 140, die an dem Netzwerkrand 101 angeordnet sind, an die Endbenutzer (z. B. einen entsprechenden EUC 150) verteilt werden. Die Verteilung umfasst somit das Erhalten von etwaigen Dateisystemobjekten von einem Content Provider sowie das geografische Platzieren dieser Objekte oder Abschnitte jedes Objekts an den Verteilungszentren, die allgemein nah an dem Rand des Netzwerks angeordnet sind.
Die Verteilungszentren 140A–140I in dem SCDN 100 aus der Abbildung aus 1 sind zum Beispiel virtuell in Form eines Baums 200 angeordnet, wie dies in der Abbildung aus 2 dargestellt ist. Diese virtuelle Baumanordnung wird primär eingesetzt für die Kommunikation bzw. Übertragung von Steuerinformationen und Signalen zwischen den Knoten des skalierbaren Content Delivery Networks 100. Daten-Downloads können von jedem Knoten in dem Netzwerk ausgeführt werden, der die gewünschten Daten aufweist, vorzugsweise von dem am nächsten gelegenen Knoten (in Bezug auf die Netzwerkentfernung). Die Knoten A bis I aus der Abbildung aus 2 stellen die entsprechenden DCs 140A bis 140I dar. Die Knoten sind in einer logischen Reihenfolge bzw. Anordnung angeordnet. Wenn zum Beispiel angenommen wird, dass der Knoten B Europa-England darstellt, so kann es sich bei den logischen Tochter- bzw. Kindknoten in Europa um Europa-Frankreich (z. B. Knoten D) und Europa-Deutschland (z. B. Knoten E) handeln, und wobei es sich um einen Tochterknoten von Europa-Frankreich zum Beispiel um Europa-Italien (z. B. Knoten H) handeln kann. In diesem Beispiel stellt die linke Seite des Baums Europa dar, so dass die rechte Seite Asien darstellen kann.
Der Knoten A stellt den Wurzelknoten dar und kann zum Beispiel eine zentrale Steuerstation darstellen. In einem oder mehreren Ausführungsbeispielen weist jeder Knoten A bis I in dem Baum 200 eine eindeutige Attributanordnung auf, welche den Namen des Knoten darstellt. Die Attributanordnung für einen Knoten wird an einem entsprechenden DC 140A–140I gespeichert und kann in jeder geeigneten Datenstruktur dargestellt werden. Die Attributanordnung kann zum Beispiel als eine Variablen-Bitmap dargestellt werden (eine Bitmap ist die binäre Darstellung eines Objekts, wie zum Beispiel einer Zahl). Jeder Knoten weist ferner eine Darstellung der Attributanordnung jedes Kinds, Enkelkinds oder Urenkelkinds, etc. des Knotens auf (d. h. aller Knoten die von dem Knoten als Wurzelknoten abstammen – Abkömmlinge in gerader Linie). Diese Darstellung wird in englischer Sprache als "Rolled Up Set of Attributes" (aufgerollte Attributanordnung) bezeichnet, und wobei diesbezüglich jede geeignete Datenstruktur verwendet werden kann. Somit ist das "aufgerollte" Attribut eines Knotens die Darstellung des aufgerollten Attributs dessen Kindern bzw. Abkömmlingen. Zum Beispiel kann eine "Rolled Up Bitmap", bei der es sich um eine Kombination aus aufgerollten Attribut-Bitmaps aller Kinder des Knotens handelt, verwendet werden. Eine "Rolled Up Bitmap" kann definiert werden als ein "binäres ODER" (auch als "bitweises ODER" bezeichnet) der aufgerollten Attribute der Kindern des Knoten.
Die Abbildung aus 3 zeigt eine Darstellung beispielhafter Attribut-Bitmaps 300, 310, 320, 330 und aufgerollter bzw. Rolled Up Bitmaps 340, 350 gemäß einem Ausführungsbeispiel der vorliegenden Erfindung. Jede Bitmap 300 bis 350 verwendet zu Veranschaulichungszwecken 16 Bits, aber da die Bitmaps variabel sind, können sie nach Bedarf variieren, um jeden Knoten zu identifizieren und um andere Informationen bereitzustellen.
Die Bitmap 300 stellt die Attributanordnung für den Knoten B aus der Abbildung aus 2 dar und weist als Identifikation die Bits 1, 4 und 13 auf 1 gesetzt und alle anderen Bits auf 0 gesetzt auf. Das Bit 1 kann gesetzt werden, da der Knoten B zum Beispiel ein Tochterknoten von A ist, wobei as Bit 4 gesetzt werden kann, um Europa darzustellen, und wobei das Bit 13 gesetzt werden kann, um England darzustellen. Die Bitmap 310 stellt die Attributanordnung für den Knoten D aus der Abbildung aus 2 dar, einen Tochterknoten von B, und wobei die Bits 1, 4 und 14 auf 1 und alle anderen Bits auf 0 gesetzt sind. Das Bit 14 kann zum Beispiel für Frankreich stehen. Die Bitmap 320 stellt die Attributanordnung für den Knoten E aus 2 dar, ebenfalls ein Tochterknoten von B, und wobei die Bits 1, 4 und 15 auf 1 und alle anderen Bits auf 0 gesetzt sind. Das Bit 15 kann zum Beispiel Deutschland darstellen. Das Bitmap 330 stellt die Attributanordnung für den Knoten H aus der Abbildung aus 2 dar, einen Tochterknoten von D, und die Bits 1, 4 und 16 sind auf 1 und alle anderen Bits auf 0 gesetzt. Das Bit 16 kann zum Beispiel für Italien stehen. Aufgerollte Bitmaps werden ebenfalls für jeden Knoten gespeichert, der Abkömmlinge aufweist. Die Rolled Up Bitmap 340 stellt die aufgerollte Anordnung von Attributen für den Knoten D dar. In diesem Fall entspricht die aufgerollte Bitmap 340 für den Knoten D der Attribut-Bitmap des Knoten H, da H keine Kinder bzw. Abkömmlinge aufweist. Die aufgerollte Bitmap 350 stellt die aufgerollte Anordnung von Attributen für den Knoten B dar. In diesem Fall handelt es sich bei der aufgerollten Bitmap 350 für den Knoten B um das binäre ODER der Attribut-Bitmaps 310, 320 und 330. Das Ergebnis des binären ODER ist es, dass alle gesetzten Bits in den Bitmaps 310, 320 und 330 auch in der aufgerollten Bitmap 350 gesetzt sind bzw. werden (d. h. die Bits 1, 4, 14, 15 und 16).
Der Content Management Server 170 kann mit jedem Knoten A bis I des Baums 200 verbunden werden. Selbst in Beispielen, bei denen der Content Management Server 170 und das Verteilungszentrum 140A–140I sich nicht an dem gleichen Ort befinden, kann der Content Management Server 170 somit einem Content Owner bzw. Inhaltseigentümer ein Mittel zur Verfügung stellen, Dateisystemobjekte den Verteilungszentren 140A bis 140I zuzuführen und um die Dateisystemobjekte in dem Netzwerk 100 zu verwalten. Der Content Management Client 130 kann direkt mit einem Verteilungszentrum 140A bis 140I verbunden werden, um ähnliche Funktionen auszuführen, wie diese durch einen Content Management Server 170 bereitgestellt werden. In einem Ausführungsbeispiel handelt es sich bei dem Content Management Server 170 um einen Computer, der die Dateisystemobjekte des Content Owners zur Verteilung in dem Netzwerk 100 verarbeitet. In einem anderen Ausführungsbeispiel handelt es sich bei dem Content Management Server 170 um eine Untergruppe von Werkzeugen bzw. Tools (z. B. maschinenunabhängigen Objekten), welche die Verwaltung, Verteilung, den Zugriff auf und die Steuerung von Dateisystemobjekten in dem Netzwerk 100 ermöglicht. Die Tools können in dem Computer des Inhalteeigentümers eingebettet sein, für eine Verarbeitung und Verteilung einer großen Nutzlastdatei in dem Netzwerk 100. In einem anderen Ausführungsbeispiel handelt es sich bei dem Content Provider Client 130 um einen Standarddateisystem-Client, der eine direkte Verbindung zu dem Virtual File Control System (virtuelles Dateisteuersystem) eines Verteilungszentrums 140A bis 140I aufweist, während die Verarbeitungs-Tools in dem Virtual File Control System eingebettet sein können. Nachdem ein Content Provider ein Dateisystemobjekt in den Content Management Server 170 geladen hat, kann der CMS 170 das Objekt verarbeiten und es an ein Verteilungszentrum 140A bis 140I weiterleiten.
2. Verteilungszentrum
Die Verteilungszentren (DC) 400A–400C werden in Bezug auf die in den Abbildungen der 4A bis 4C dargestellten Ausführungsbeispiele beschrieben. Ein Verteilungszentrum wird auch als eine Station oder ein Datenzentrum bezeichnet. Die Funktionsweise bzw. der Betrieb von Verteilungszentren und deren Komponenten gemäß der vorliegenden erfindung wird danach ebenfalls in näheren Einzelheiten beschrieben.
Die Abbildung aus 4A zeigt ein Diagramm eines Verteilungszentrums 400A gemäß einem Ausführungsbeispiel der vorliegenden Erfindung. Das Verteilungszentrum 400A weist einen Verteilungsserver-Cluster (DSC) 410, einen Anwendungsserver-Cluster (ASC) 420A, eine Steuereinheit (CU) 450, ein gemeinsam genutztes Speichersystem 430, einen Speicher-Switch 440 und einen steuerungsbezogenen Intrastations-Switch 415 auf. Der Verteilungsserver-Cluster 410 kommuniziert mit dem Speichersystem 430 über den Speicher-Switch 440 unter Verwendung der Übermittlungsabschnitte 443 und 445. Der Anwendungsserver-Cluster 420A kommuniziert mit dem Speichersystem 430 über den Speicher-Switch 440 unter Verwendung der Übermittlungsabschnitte 441 und 444. Der Anwendungsserver-Cluster 420A weist ferner ein Virtual File Control System 470 gemäß der vorliegenden Erfindung auf. Die Steuereinheit 450, der Verteilungsserver-Cluster 410 und der Anwendungsserver-Cluster 420A kommunizieren alle über den steuerbezogenen Intrastations-Switch 415 (Intra-Station Control Related Switch), der mit dem Speicher-Switch 440 kommuniziert. Die Steuereinheit 450 weist ihr eigenes lokales Speichersystem 460 auf.
Das Verteilungszentrum 400A kommuniziert mit mehreren EUCs 150 über den Anwendungsserver-Cluster 420A. Der ankommende ASC-Verkehr 402 kommt an dem Anwendungsserver-Cluster 420A von einem oder mehreren EUCs 150 in dem Netzwerk 100 an. Der abgehende ASC-Verkehr 404 wird von dem Anwendungsserver-Cluster 420A in dem Netzwerk an einen oder mehrere EUCs 150 in dem Netzwerk gesendet. Das Verteilungszentrum 400A kommuniziert ferner mit anderen Verteilungszentren 140 und CMS 170 in dem Netzwerk 100 über den Verteilungsserver-Cluster 410. Der ankommende DS-Verkehr 412 kommt an dem Verteilungsserver-Cluster 410 von einem oder mehreren Verteilungszentren 140 und/oder CMS 170 in dem Netzwerk 100 an. Der abgehende DS-Verkehr 414 wird von dem Verteilungsserver-Cluster 410 an ein oder mehrere Verteilungszentren 140 und/oder CMS 170 in dem Netzwerk 100 gesendet. Die Steuereinheit 450 sendet und empfängt Steuerverkehr 416 an und von einem oder mehreren Verteilungszentren 140 und/oder CMS 170 in dem Netzwerk 100.
Die Abbildung aus 4B zeigt ein Diagramm des Verteilungszentrums 400B gemäß einem anderen Ausführungsbeispiel der vorliegenden Erfindung. Das Verteilungszentrum 400B weist eine Steuereinheit 450 auf, ein oder mehrer Virtual File Control Systeme (VFCS) 470, einen oder mehrere Verteilungsserver in einem Verteilungsserver-Cluster 410 und eine Mehrzahl von Speichervorrichtungen 430<1> 430<3>. Der Anwendungsserver-Cluster 420B weist einen oder mehrere Anwendungsserver 420<1>–420<M> und jedes VFCS 470 auf. Die Steuereinheit 450 ist der Netzwerkmanager für das Verteilungszentrum 400B und ist mit jedem VFCS 470 und DSC 410 gekoppelt. Bei den Anwendungsservern 420<1...N> kann es sich um jede Art von Anwendungsserver handeln, einschließlich und nicht beschränkt auf Streaming-Server, FTP-Server und Media Player. Die Anwendungsserver 420<1...N> sind kein Teil des Verteilungszentrums 400B, wobei sie jedoch mit dem Virtual File Control System 470 verbunden dargestellt sind, um zu veranschaulichen, wie Endbenutzer-Clients 150 auf Dateien zugreifen, die in dem SCDN 100 gespeichert sind. Die Speichervorrichtungen 430<1...3> sind zwischen dem 410 und jedem VFCS 470 gekoppelt.
Die Komponenten des Verteilungsserver-Clusters 410 müssen sich nicht an dem gleichen Knoten befinden wie die VFCS 470 und die Steuereinheit 450. Zum Beispiel kann jedes VFCS 470 mit den Anwendungsservern 420 angeordnet sein, und die Steuereinheit 450 kann sich an anderer Stelle befinden, wie zum Beispiel bei den VFCS 470. Somit ist es nicht erforderlich, dass sich alle Komponenten des Verteilungszentrums 400B gemeinsam an einem SCDN-Knoten befinden.
Die Abbildung aus 4C zeigt ein Verteilungszentrum 400C gemäß einem weiteren Ausführungsbeispiel der vorliegenden Erfindung. Die Abbildung aus 4C veranschaulicht, wie Verteilungsserver über Cluster miteinander verbunden sind, mit einem Load Balancer bzw. einer Lastverteilungseinrichtung als Schnittstelle zu dem Rest des Netzwerks 100. Das Verteilungszentrum 400C ist dem Verteilungszentrum 400A ähnlich, wobei es jedoch einen Verteilungszentrum-Cluster (DSC) 410 aufweist, der eine Lastverteilungseinrichtung 411 aufweist, die mit einer Mehrzahl von Verteilungsservern 413 DS<1...N> gekoppelt ist. Die Verteilungsserver 413 sind in der Station 400C in Cluster angeordnet, um deren Arbeitslast zu verteilen. Der DSC 410 stellt unter anderem Systemfehlertoleranz und Skalierbarkeit bereit. In einer Station befinden sich zwar mehrere Verteilungsserver 413, allerdings erscheinen sie als eine Schnittstelle zu den externen Stationen. Die Lastverteilungseinrichtung 411 ist deren Schnittstelle zu der äußeren Umgebung, wobei die Einrichtung Anforderungen an jeden DS<1..N> ausgibt, unter Berücksichtigung deren aktuellen Arbeitslast bzw. Workload.
Das Verteilungszentrum 400C weist ferner einen Anwendungsserver-Cluster 420C auf. Der Anwendungsserver-Cluster 420C weist ein Lastverteilungs- und/oder Routing-System 422, die Anwendungsserver 425 AS<1...M>, ein Lastverteilungs- und/oder Routing-System 424 und ein oder mehrere Virtual File Control Systeme (VFCS) 470 auf. Der ankommende ASC-Verkehr 402 kommt an dem Lastverteilungs- und/oder Routing-System 422 an, welches den Verkehr über die Anwendungsserver 425 AS<1...M> verteilt. Der Verkehr von den Anwendungsservern 425 wird zu dem Lastverteilungs- und/oder Routing-System 424 gesendet, welches den Verkehr über die Virtual File Control Systeme 470 VFCS<1...L> verteilt. Der abgehende ASC-Verkehr 404 wird von dem Switch 415 über die Virtual File Control Systeme 470 VFCS<1...L> zu den Anwendungsservern 425 geleitet und danach zu dem Lastverteilungs- und/oder Routing-System 422. Ausführungsbeispiele von Anwendungsserver-Clustern werden ferner in Bezug auf die Abbildungen der 5A bis 5C beschrieben. Ein Ausführungsbeispiel eines Virtual File Control System-Clusters mit einer Lastverteilungseinrichtung und mehrfachen virtuellen Dateisteuerung wird in Bezug auf die Abbildung aus 6 näher beschrieben.
Ein Content Owner erstellt, bewegt, löscht, benennt um, aktualisiert und verwaltet Dateisystemobjekte direkt über ein oder mehrere Verteilungszentren 140, 400 oder direkt über einen oder mehrere Content Management Server 170. Ein Content Owner kann ferner eine Datei oder Dateiverzeichnisse in einen oder mehrere Content Management Server 170 hochladen, unter Verwendung von Content Publishing und Management Tools, die auf einem Client-System 130 des Content Owners laufen bzw. ausgeführt werden. Nach dem Empfang der Dateisystemobjekte verarbeiten CMS 170 oder ein VFCS 470 die Dateisystemobjekte und erzeugen Objekt-Metadaten, wobei die diesbezüglichen Einzelheiten nachstehend in Bezug auf die Abbildungen der 7A bis 7C und andere Figuren beschrieben werden. Für die Verarbeitung eines Dateiobjekts bestimmen CMS 170 oder VFCS 470 Track- bzw. Verfolgungsdateien (auch als lineare Dateien bekannt) in der ursprünglichen Datei, sofern dies erforderlich ist. Eine lineare Datei ist eine Datei, die die Anordnung beibehält, welche der Substanz (d. h. dem substantiven Inhalt) der Datei zugeordnet ist. In einem Beispiel für die vorliegende Erfindung handelt es sich bei einer linearen Datei um eine Datei, bei der die ersten 10% des Inhalts der Anwendung ungefähr innerhalb der ersten 10% der ganzen Datei liegen müssen, beginnend am Anfang der Datei. In einer nicht linearen Datei können die ersten 10% des Inhalts über mehrere Standorte bzw. Positionen in der Datei verstreut sein. Wenn die lineare Datei zum Beispiel einen Film aufweist, so weist der Anfang der Datei die Anfangsabschnitte des Films auf. In ähnlicher Weise würden sich die mittleren Abschnitte und die Endabschnitte des Films in der Mitte und am Ende der linearen Datei befinden. Lineare Dateien sind wünschenswert, da diese Dateien leichter wieder zusammengesetzt werden können unter Verwendung von beispielsweise der linearen Überlagerung. Bestimmte Dateien sind nicht linear, das heißt, sie weisen mehrere Spuren oder Segmente auf, so dass der erste Teil des Inhalts zum Beispiel nicht am Anfang der Datei gespeichert wird.
Nach der Verarbeitung eines Dateisystemobjekts überträgt der CMS 170 oder das VFCS 470 das Dateisystemobjekt an einen Verteilungsserver 140, 400, mit dem eine Verbindung oder eine Zuordnung gegeben ist. Wenn es sich bei dem Objekt um eine Datei handelt, teilt der Verteilungsserver 140, 400 die ganze Datei (alle Track-Dateien) in Blockdateien auf, wie dies für die Speicherung gewünscht wird. Die Blockdateien können später an lokalen Speicherplätzen, wie zum Beispiel 430<1...n> gespeichert werden. Ein Teil der Metadaten wird während der Verarbeitung des Dateisystemobjekts erzeugt. Zum Beispiel wird in Bezug auf eine Datei ein "Chunking" Prozess eingesetzt, um die Track-Dateien zu lokalisieren und die Datei in Blockdateien zu zerlegen, welche den Großteil der Metadaten erzeugen. Die Metadaten einer Datei werden eingesetzt, um die Datei aus einer Gruppe von Blockdateien zu rekonstruieren.
Ein Dateiverteilungsprotokollbefehl (z. B. FDP-Befehl) wird in der Folge verwendet, um die Metadaten und die Dateisystemobjekte oder ausgewählte Teile dieser zu verteilen (d. h. zu replizieren), und zwar an andere Verteilungsserver-Knoten in dem skalierbaren Content Delivery Network 100. Für die erste Replikation einer Datei müssen nicht alle Blockdateien (die Chunks, die aus einer ursprünglichen Datei aufgeteilt worden sind) in allen Knoten gespeichert werden, wobei jedoch eine Masterkopie in bestimmten Knoten vollständig gespeichert werden kann (für gewöhnlich in bzw. an dem Ursprungsknoten). Das FDP weist Befehle auf, welche Dateiübertragungen und Manipulationen in dem SCDN 100 erleichtert. Die Größe der Blöcke beeinflusst die Leistung sowohl der Verteilung von Inhalten als auch der Zustellung bzw. der Übertragung von Inhalten und wird nachstehend im Text näher beschrieben.
a. Virtual File Control System:
Jedes Virtual File Control System (VFCS) 470 erzeugt eine integrierte Dateisystemverzeichnisdarstellung von Netzwerkknoten der Metadateisystemstruktur und Objektmetadaten. Die Metadateisystemstruktur und die Objektmetadaten werden anhand der Verarbeitung und des Speicherns von Dateisystemobjekten erzeugt; in Bezug auf ein Dateiobjekt handelt es sich bei diesem Prozess um den "Chunking" Prozes. Die Datenblöcke jeder durch ein VFCS 470 dargestellten Datei werden nicht unbedingt in lokalen Speichervorrichtungen eines einzelnen Knoten gespeichert. Das VFCS 470 kann die ursprüngliche Datei wieder in Echtzeit zusammenzusetzen, während eine Endbenutzeranforderung bearbeitet wird und die nicht-residenten Blöcke von anderen Knoten in die lokalen Speichervorrichtungen importiert werden. Wie dies nachstehend beschrieben wird, müssen nicht alle Blöcke der Datei an einem Verteilungszentrum gespeichert werden; wobei jedoch die ganze Datei in dem SCDN 100 zur Verfügung steht. Wenn ein Endbenutzer eine Verbindung mit einem Anwendungsserver herstellt, erzeugt das VFCS 470 ein virtuelles Erscheinungsbild, dass das ganze Dateisystemverzeichnis und alle Dateien bzw. die vollständigen Dateien an diesem Knoten zur Verfügung stehen. Wenn zum Beispiel angenommen wird, dass nur fünfzehn Prozent einer Datei von zwei Gigabyte in dem Speicher 430<1...3> gespeichert werden, so sorgt das VFCS 470 dafür, dass ein Anwendungsserver meint, dass die ganze Bibliothek und die ganze Datei von zwei Gigabyte an dem Ort zur Verfügung steht. Somit kann ein Anwendungsserver, wie zum Beispiel ein Streaming Server, die Wiedergabe einer Datei starten. Wenn die Datei wiedergegeben bzw. abgespielt wird, kommuniziert das VFCS 470 mit einem DS, um die restlichen Abschnitte der Datei an anderen Knoten in dem Netzwerk zu lokalisieren und abzurufen.
b. Anwendungsserver-Cluster:
Ein Anwendungsserver-Cluster (ASC) gemäß der vorliegenden Erfindung weist eine Gruppe von Anwendungsservern und eine Gruppe von Virtual File Control Systemen auf. Ein ASC stellt Unter anderem Dienste an einen Endbenutzer bereit (z. B. das Streaming eines Spielfilms bzw. Films in voller Länge an ein Client-System eines Endbenutzers). Wie dies vorstehend im Text bereits beschrieben worden ist, stellt das VFCS eine Management-Schnittstelle an den Content Owner bereit, während gleichzeitig Systemfehlertoleranz und Skalierbarkeit vorgesehen werden.
Die Abbildungen der 5A–5C zeigen Ausführungsbeispiele von drei entsprechenden Anwendungsserver-Clustern 500, 502, 504 gemäß der vorlegenden Erfindung. Jeder Anwendungsserver-Cluster 500, 502, 504 weist Lastverteilungseinrichtungen 520 und 530 auf, eine Mehrzahl von Anwendungsservern 425<1> bis 425<M> (gemeinsam 425) und eine Mehrzahl von Virtual File Control Systemen 470-1 bis 470-L (gemeinsam 470). In einem Beispiel wird jedes Virtual File Control System 470-1 bis 470-L an einem entsprechenden Server (als Virtual File Control System Server bezeichnet) implementiert. Die Anwendungsserver-Cluster 500, 502, 504 sorgen für fehlertolerante und skalierbare Systemleistung. Wenn zum Beispiel einer der Anwendungsserver 425<1> bis 425<M> ausfällt oder wenn einer der VFCS Server Systeme 470-1 bis 470-L ausfällt, verarbeitet einer der anderen vorhandenen Anwendungsserver 425 oder VFCS-Server 470 entsprechend die Anforderungen. Wenn in ähnlicher Weise mehr Systemleistung erforderlich ist, kann die Anzahl der Anwendungsserver, der VFCS-Server oder die Speicherkapazität des Speichersystems 430 nach Bedarf erhöht werden.
Die Abbildung aus 5A zeigt ein veranschaulichendes Ausführungsbeispiel eines Anwendungsserver-Clusters 500. Jeder Anwendungsserver 425 greift auf Daten (z. B. große Nutzlastdateien) über einen der VFCS-Server 470 der Station zu, wobei die Server wiederum über den Switch 440 auf Daten in dem Speichersystem 430 zugreifen. Obgleich die Lastverteilungseinrichtung 520 und die Lastverteilungseinrichtung 530 in der Abbildung aus 5A logisch als separate Einheiten dargestellt sind, können sie auch die gleiche physische Einheit darstellen. Ferner können sich der Anwendungsserver 425 und der VFCS-Server 470 in der gleichen physischen Einheit befinden, wodurch eine der Lastverteilungseinrichtungen 520 oder 530 eliminiert wird.
Ein Endbenutzer greift auf ein Dateisystemobjekt zu, erzeugt oder verwaltet ein Dateisystemobjekt unter Verwendung einer Standardschnittstelle (wie etwa eines Web-Browsers oder eines Dateisystem-Clients), die auf der Vorrichtung bzw. dem Gerät des Endbenutzer-Clients läuft. Wenn als Folge dessen der Benutzer über einen Anwendungsserver auf ein Dateisystemobjekt zugreift, wird eine Behandlungsanforderung für die Datei an den ASC 500 gesendet und erreicht die Lastverteilungseinrichtung 520. Die ankommenden Datenpakete für die Behandlungsanforderung werden durch die Lastverteilungseinrichtung 520 an einen der Anwendungsserver 425 weitergeleitet, wie zum Beispiel den Anwendungsserver 425-1 (ein willkürlicher, beispielhafter Server der Server 425-1 bis 425-M). Der Anwendungsserver 425-1 gibt eine Anforderung für die erforderlichen Daten an die Lastverteilungseinrichtung 530 aus. Die Lastverteilungseinrichtung 530 wählt einen der VFCS-Server 470 der Station aus, wie zum Beispiel VFCS 470-3 (ein willkürlicher, beispielhafter Server der Server 470-1 bis 470-L), um die Anforderung zu bearbeiten, und wobei die Datenpakete von dem Anwendungsserver 425-1 zu dem VFCS 470-3 weitergeleitet werden. Wenn angenommen wird, dass alle angeforderten Daten in dem Speichersystem 430 vorhanden sind, verarbeitet das VFCS 470-3 die Anforderung, indem die Daten in dem Speichersystem 430 über den Switch 440 gespeichert werden oder auf diese zugegriffen wird, und wobei die Daten und eine Antwort über die Lastverteilungseinrichtung 530 an den Anwendungsserver 425-1 zurückgesendet werden. Eine Endbenutzeranforderung kann danach direkt zu der Lastverteilungseinrichtung 530 verlaufen und direkt und danach zu einem ausgewählten VFCS-Server 470.
Wenn der Anwendungsserver 425-1 oder ein Dateisystem-Browser des Endbenutzer-Client-Systems CPC (130 aus 1) eine Sitzung mit einem VFCS 470-3 erzeugt, leitet die Lastverteilungseinrichtung 530 weiter Daten zwischen dem Anwendungsserver 425-1 und dem VFCS 470-3 oder zwischen dem CPC 130 und dem VFCS 470-3 weiter hin und her. Wenn die Lastverteilungseinrichtung 530 eine "sticky" Funktion unterstützt, und wenn die "sticky" Funktion "eingeschaltet" ist, können Daten von dem Anwendungsserver 425-1 oder dem CPC 130 über die aktuelle Sitzung hinaus weiter zu dem VFCS 470-3 geleitet werden, wenn das VFCS 470-3 weiter verfügbar bleibt (d. h. wenn die Lastverteilungseinrichtung 530 das VFCS 470-3 keinem anderen Anwendungsserver zuweist). Wenn das VFCS 470-3 nicht mehr verfügbar wird, leitet die Lastverteilungseinrichtung 530 die Datenpakete von dem Anwendungsserver 425-1 oder CPC 130 zu einem anderen VFCS-Server, wie zum Beispiel 470-1 (ein weiteres willkürliches Beispiel für einen der Server 470-1 bis 470-M). Das VFCS 470-1 verarbeitet die Anforderung von dem Anwendungsserver 425-1 oder CPC 130 und sendet Antwortdatenpakete über die Lastverteilungseinrichtung 530 an den Anwendungsserver 425-1 oder CPC 130. Datenpakete von dem Anwendungsserver 425-1 werden über die Lastverteilungseinrichtung 520 zurück zu dem Client übertragen. Wie die Lastverteilungseinrichtung 530 erhält die Lastverteilungseinrichtung 520 eine anhaltende Sitzung zwischen dem Client-System des Endbenutzers und dem Anwendungsserver 425-1 bei. Die Lastverteilungseinrichtung 520 kann ebenfalls eine "sticky" Funktion bereitstellen. In einem anderen Beispiel kann die Lastverteilungseinrichtung 520 Sitzungen aufbauen und wieder aufbauen, die nicht dauerhaft bzw. anhaltend sind.
Wenn eine neue Anforderung von einem anderen Endbenutzer-Client-System die Lastverteilungseinrichtung 520 des ASC 500 erreicht, leitet die Lastverteilungseinrichtung 520 die neue Anforderung an einen verfügbaren Anwendungsserver weiter, wie zum Beispiel den Anwendungsserver 425-3 (ein weiteres willkürliches Beispiel für einen der Server 425-1 bis 425-M). Der Anwendungsserver 425-3 verarbeitet die Anforderung und stellt in Folge dessen eine Datenanforderung an einen der VFCS-Server der Station über die Lastverteilungseinrichtung 530, wie z. B. VFCS 470-2 (ein weiteres willkürliches Beispiel für eines der Systeme 470-1 bis 470-L). Die Lastverteilungseinrichtung 530 leitet danach die Datenpakete von dem Anwendungsserver 425-3 zu dem VFCS 470-2 weiter. Das VFCS 470-2 verarbeitet die Anforderung von dem Anwendungsserver 425-3 und sendet Antworten über die Lastverteilungseinrichtung 530 zurück zu dem Anwendungsserver 425-3. Der Anwendungsserver 425-3 sendet Antworten über die Lastverteilungseinrichtung 520 zu dem neuen Endbenutzer-Client-System.
Die Abbildung aus 5B zeigt ein weiteres Ausführungsbeispiel eines Anwendungsserver-Clusters 502. Der ASC 502 weist einen oder mehrere Anwendungsserver 425-1 bis 425-M (gemeinsam 425) auf, eine Lastverteilungseinrichtung 520 mit niedriger Bandbreitenfähigkeit, einen Router 525 mit hohem Netzwerkdurchsatz, eine Lastverteilungseinrichtung 530 (ebenfalls mit niedriger Bandbreitenfähigkeit), einen Router 535 und einen oder mehrere VFCS-Server 470-1 bis 470-L (gemeinsam 470) auf. Jeder Anwendungsserver greift auf Daten (z. B. große Nutzlastdateien) über einen VFCS-Server 470 der Station zu, der wiederum über den Switch 440 auf Daten in dem Speichersystem 430 zugreift. Die Lastverteilungseinrichtung 520 und die Lastverteilungseinrichtung 530 sind in der Abbildung aus 5B zwar logisch als zwei separate Einheiten dargestellt, allerdings kann es sich dabei um die gleiche physikalische bzw. physische Einheit handeln. Ferner können sich der bzw. die Anwendungsserver 425 und der bzw. die VFCS-Server 470 in der gleichen physischen Einheit befinden, wodurch eine der Lastverteilungseinrichtungen 520 und 530 und einer der Router 525 und 535 eliminiert wird. Somit eliminiert eine Konfiguration gemäß einem Ausführungsbeispiel der vorliegenden Erfindung die Lastverteilungseinrichtung 530 und den Router 535 und kombiniert den bzw. die Anwendungsserver 425 mit dem bzw. den VFCS-Server(n) 470.
Die vorliegende Erfindung nutzt die Tatsache, dass der abgehende Verkehr von den VFCS-Servern 470 und den Anwendungsservern 425 des Anwendungsserver-Clusters deutlich höher sein kann als der ankommende Verkehr. Wie dies in der Abbildung aus 5B dargestellt ist, wird der abgehende Verkehr zu dem Router 525 und dem Router 535 übermittelt, während der ankommende Verkehr zu den Lastverteilungseinrichtungen 530, 530 gesendet wird, jedoch nicht zu den Routern 525, 535. Durch das Trennen von ankommendem und abgehendem Verkehr trägt dieses Ausführungsbeispiel zur Verbesserung der Netzwerkleistung bei.
Ein Endbenutzer fordert ein Dateisystemobjekt unter Verwendung einer Standardschnittstelle (wie etwa eines Web-Browsers) an, welche auf dem Client-Gerät des Endbenutzers ausgeführt wird. Als Folge dessen wird eine Behandlungs- bzw. Serviceanforderung für das Dateisystemobjekt zu dem ASC 502 übermittelt und erreicht die Lastverteilungseinrichtung 520 bzw. 530. Die ankommenden Datenpakete der Behandlungsanforderung werden durch die Lastverteilungseinrichtung 520 zu einem der Anwendungsserver 425 weitergeleitet, wie z. B. zu dem Anwendungsserver 425-1 (ein willkürliches veranschaulichendes Beispiel für einen der Server 425-1 bis 1810-M). Der Anwendungsserver 425-1 gibt eine Anforderung für die erforderlichen Daten an die Lastverteilungseinrichtung 530 aus. Die Lastverteilungseinrichtung 530 wählt einen der VFCS-Server 1470, wie zum Beispiel VFCS 470-1 (ein willkürliches veranschaulichendes Beispiel von 470-1 bis 470-L), für die Behandlung bzw. die Bearbeitung der Anforderung aus und leitet die Datenpakete von dem Anwendungsserver 425-1 zu VFCS 470-L weiter. VFCS 470-1 verarbeitet die Anforderung, indem über den Switch 440 in die Daten in dem Speichersystem 430 geschrieben wird oder auf diese Daten zugegriffen wird, und wobei die Daten und eine Antwort über den Router 535 zurück zu dem Anwendungsserver 425-1 oder direkt zurück zu dem Client oder über eine Lastverteilungseinrichtung gesendet wird, wie dies in einer Anordnung in der Abbildung aus 6 dargestellt ist.
Wenn der Anwendungsserver 425-1 eine Sitzung mit VFCS 470-1 aufbaut, sendet die Lastverteilungseinrichtung 530 weiter Daten von dem Anwendungsserver 425-1 an VFCS 470-1. Wenn die Lastverteilungseinrichtung 530 die "sticky" Funktion unterstützt und diese Funktion "eingeschaltet" ist, können Daten von dem Anwendungsserver 425-1 weiter zu VFCS 470-1 über die aktuelle Sitzung hinaus gesendet werden, solange VFCS 470-1 verfügbar bleibt (d. h. wenn die Lastverteilungseinrichtung 530 VFCS 470-1 keinem anderen Anwendungsserver zuweist). Die Daten von VFCS 470-1 zu dem Anwendungsserver 425-1 fließen durch den Router 535. Der Router 535 leitet Datenpakete, die von VFCS 470-1 empfangen werden, zu dem Anwendungsserver 425-1 weiter. Der Anwendungsserver 425-1 sendet Datenpakete über den Router 525 zu dem Endbenutzer-Client-System.
Wenn eine neue Anforderung von einem anderen Endbenutzer-Client an der Lastverteilungseinrichtung 520 des ASC 502 ankommt, leitet die Lastverteilungseinrichtung 520 die neue Anforderung an einen verfügbaren Anwendungsserver weiter, wie z. B. den Anwendungsserver 425-3 (ein weiteres willkürliches veranschaulichendes Beispiel für die Server 425-1 bis 425-M). Der Anwendungsserver 425-3 verarbeitet die Anforderung und gibt in der Folge eine Datenanforderung an einen der VFCS-Server über die Lastverteilungseinrichtung 530 aus, wie etwa über VFCS 470-3 (ein weiteres willkürliches veranschaulichendes Beispiel für 470-1 bis 470-L). VFCS 470-3 verarbeitet die Anforderung von dem Anwendungsserver 425-3 und sendet Daten über den Router 535 zurück zu dem Anwendungsserver 425-3. Der Anwendungsserver 425-3 sendet Antwortdaten über den Router 525 zurück zu dem Endbenutzer-Client-System.
Die Abbildung aus 5C zeigt ein drittes veranschaulichendes Ausführungsbeispiel eines Anwendungsserver-Clusters 504. Dieses Ausführungsbeispiel ist dem Ausführungsbeispiel aus der Abbildung aus 5B ähnlich, unterscheidet sich jedoch in zwei Aspekten: (1) sämtlicher EUC-bezogener Datenverkehr 402, 404 in und aus dem ASC verläuft durch den Router 525; und (2) sämtlicher Datenverkehr zwischen den Anwendungsservern 425 und den VFCS-Servern 470 verläuft durch den Router 535. Ankommende Client-Datenpakete fließen durch den Router 525 zu der Lastverteilungseinrichtung 520. Die Lastverteilungseinrichtung 520 gibt den ankommenden Verkehr danach über den Router 525 an die Anwendungsserver ab. Der komplette abgehende Verkehr fließt durch den Router 525 zu dem Endbenutzer-Client-System. Der Ankommende Verkehr zu den VFCS-Servern 470 fließt von dem Router 535 zu der Lastverteilungseinrichtung 530. Die Lastverteilungseinrichtung 530 gibt den ankommenden Verkehr über den Router 535 an die VFCS-Server 470 ab. Der abgehende Verkehr des VFCS-Servers fließt durch den Router 535 zu den entsprechenden Anwendungsservern 425. Wiederum kann es sich bei der Lastverteilungseinrichtung 520 und der Lastverteilungseinrichtung 530 um die gleiche physische Einheit handeln. Ferner können sich der Anwendungsserver 425 und der VFCS-Server 470 in der gleichen physischen Einheit befinden, wodurch eine der Lastverteilungseinrichtungen 520 und 530 und einer der Router 525 und 535 eliminiert wird. Somit eliminiert eine Konfiguration gemäß einem Ausführungsbeispiel der vorliegenden Erfindung die Lastverteilungseinrichtung 530 und den Router 535 und kombiniert den bzw. die Anwendungsserver 425 mit dem bzw. den VFCS-Server(n) 470.
Das Ausführungsbeispiel aus der Abbildung aus 5A setzt eine Lastverteilungseinrichtung mit ausreichender Kapazität ein, um sowohl ankommende als auch abgehende Verkehrs-Cluster zu bearbeiten bzw. zu behandeln. Die Ausführungsbeispiele aus den Abbildungen der 5B und 5C weisen Vorteile für Cluster mit starkem abgehenden Verkehr und geringerem ankommenden Verkehr auf. Beide nutzen zwei Lastverteilungseinrichtungen mit geringer Kapazität. In dem Ausführungsbeispiel aus der Abbildung aus 5B wird der ankommende und der abgehende Verkehr zwischen den Lastverteilungseinrichtungen und den Routern aufgeteilt, während in dem Ausführungsbeispiel aus der Abbildung aus 5C der ankommende und der abgehende Verkehr durch die Router verläuft, wobei die Lastverteilungseinrichtungen als eine Ressource verwendet werden. Für Anwendungsserver-Cluster mit starker Verkehr in zwei Richtungen sind Lastverteilungseinrichtungen mit geringerer Kapazität und Router wünschenswert, wie dies in den Ausführungsbeispielen der Abbildungen der 5B und 5C der Fall ist. Die Ausführungsbeispiele aus den Abbildungen der 5B und 5C können unter Verwendung von Lastverteilungseinrichtungen konfiguriert werden, die in einem transparenten Modus arbeiten können.
c. Virtual File Control System Cluster:
Die Abbildung aus 6 zeigt ein veranschaulichendes Ausführungsbeispiel eines Virtual File Control System Clusters 600. Der VFCS Cluster 600 weist eine oder mehrere VFCS-Einheiten 470<1...L> auf, die kombiniert werden, um ein virtuelles VFCS durch ein Lastverteilungs-Cluster-Manager 630 zu erzeugen (auch als Lastverteilungseinrichtung bezeichnet). Die Anforderungen von Daten 625 werden durch die Lastverteilungseinrichtung 630 zu einer am besten verfügbaren VFCS-Einheit 470<1...L> geleitet, während die zurückgeführten Daten direkt zu dem Aufrufer übermittelt werden. Bei diesem VFCS-Cluster 600 kommuniziert jede VFCS-Einheit 470<1...L> direkt mit einem lokalen Verteilungsserver, wie dies durch den Verkehr 648 dargestellt ist.
B. Content Publishing und Management
Das Content Publishing und Management umfasst das Erstellen, das Aktualisieren von Content, das Aktualisieren von Attributen, die neue Positionsanordnung, das Löschen und die sonstige Verwaltung von Dateisystemobjekten. Ein Dateisystemobjekt umfasst einen Datenträger, ein Verzeichnis und/oder eine Datei.
1. Erzeugung, Aktualisierung, Umbenennung, Neuzuweisung, Löschen von Dateisystemobjekten
Die Abbildungen der 7A–B zeigen Flussdiagramme des Publishing (Veröffentlichung), Verteilung und des Managements von Dateisystemobjekten gemäß Ausführungsbeispielen der vorliegenden Erfindung. Im Besonderen ist eine Routine 700 abgebildet, welche Schritte (702 bis 799) aufweist. Die Publikation, Verteilung und das Management von Dateisystemobjekten umfasst das Einführen eines neuen Dateisystemobjekts in das SCDN 100 entweder über CMS 170 oder VFCS 470 oder das Ändern von Inhalt und Informationen eines bestehenden Dateisystemobjekts in dem SCDN 100 oder das Löschen eines bestehenden Dateisystemobjekts. Zur Vereinfachung wird die Routine 700 in Bezug auf ein beliebiges der Verteilungszentren 400A bis 400C beschrieben; wobei diese Beschreibung veranschaulichend ist und die Routine 700 nicht unbedingt einschränken soll.
Wie dies in der Abbildung aus 7A dargestellt ist, wird eine Anforderung für Content Publishing und Management durch CPC 130 erzeugt bzw. gestellt. Der CPC 130 kann eine Anwendung darstellen, die durch CMS 170 unterstützt wird, oder es kann sich um einen Dateisystem-Client handeln, der durch VFCS 470 oder den VFCS-Cluster 600 unterstützt wird. Nachdem eine CPC-Client-Anforderung in dem Schritt 702 erzeugt worden ist, authentifiziert CMS 170 oder VFCS 470 den Benutzer und prüft den Anforderungstyp (Schritt 710). Wenn die Anforderungsarten eine neue Anordnung bzw. Neupositionierung oder Aktualisierung des Attributwertes des Dateisystemobjekts anzeigen (Attribute wie Name, Daten, Zugriffskontrolllisten, etc.), erzeugt CMS 170 oder VFCS 470 einen FDP-INFO-Befehl (FDP als englische Abkürzung von File Distribution Protocol) mit den relevanten Objektmetadaten und sendet den erzeugten INFO-Befehl an den Verteilungsserver-Cluster 410 in einem Verteilungszentrum (Schritt 730). Wenn der Anforderungstyp das Löschen des Dateisystemobjekts darstellt, erzeugt CMS 170 oder VFCS 470 einen FDE-CLEAN-Befehl (FDP Löschbefehl) mit den relevanten Objektmetadaten und sendet den erzeugten CLEAN-Befehl zur Anweisung an einen Verteilungsserver-Cluster 410 in einem Verteilungszentrum (Schritte 740 und 750).
Wenn in dem Schritt 760 die Anforderung lautet, ein neues Dateisystemobjekt zu erzeugen oder Dateiinhalt zu aktualisieren, so bearbeiten VFCS 470 und CMS 170 die Anforderung unterschiedlich. Wenn die Anforderung von einem VFCS 470 bearbeitet wird, fährt die Steuerung mit dem Schritt 770 fort. Wenn die Anforderung von einem CMS 170 bearbeitet wird, fährt die Steuerung mit dem Schritt 786 fort.
Wenn es sich in dem Schritt 770 bei dem Dateisystemobjekt um einen Datenträger oder ein Verzeichnis handelt, fährt die Steuerung mit dem Schritt 780 fort. Wenn es sich bei dem Dateisystemobjekt um eine Datei handelt, fährt die Steuerung mit dem Schritt 782 fort. In dem Schritt 780 ruft VFCS 470 einen Analyseprozess auf, um Datenträger- oder Verzeichnismetadaten zu erzeugen, wobei es ein Objekt in dessen Metadateisystemstruktur erzeugt, wobei es ferner die relevanten Objektmetadaten erzeugt. In dem Schritt 782 (wobei es sich bei dem Dateisystemobjekt um eine Datei handelt) wird ein "Chunking" Prozess eingesetzt, um die Datei zu zerlegen und eine Blockindexanordnung als Teil der Metadaten zu erzeugen. Wenn das Dateisystemobjekt neu ist, weist VFCS 470 eine neue eindeutige Objekt-ID der Datei zu, wobei ansonsten die bestehende bzw. vorhandene ID für die Datei verwendet wird. Nach dem Schritte 780 oder 782 fährt die Steuerung mit dem Schritt 784 fort.
Nach der Erzeugung oder Aktualisierung der Dateisystemobjekte und deren Metadaten in dem lokalen Speicher gibt VFCS 470 in dem Schritt 784 einen Befehl FDP DIST an den Verteilungsserver-Cluster 410 aus, um die Replikation der Veränderungen gemäß einer Reihe von Verteilungsregeln einzuleiten.
In dem Schritten 786 bis 788 wird die Anforderung durch CMS 170 behandelt bzw. bearbeitet. Wenn in dem Schritt 786 das Dateisystemobjekt einen Datenträger, ein Verzeichnis oder eine Datei darstellt, wendet CMS 170 einen Analyseprozess an, um die erforderlichen Objektmetadaten zu erzeugen (Datenträger, Verzeichnis und/oder Dateimetadaten) und gibt einen Befehl FDP PUT aus, um das Objekt in einen Verteilungsserver-Cluster 410 hochzuladen. Wenn das Dateisystemobjekt ein Dateiobjekt darstellt, wird in dem Schritt 786 ferner ein "Chunking" Prozess angewandt, um die Datei zu zerlegen und um Dateimetadaten zu erzeugen. In einem Ausführungsbeispiel wird dieser Chunking Prozess in CMS 170 und teilweise in dem Verteilungsserver-Cluster 410 ausgeführt. Nach dem Empfang eines Befehls FDP PUT speichert der Verteilungsserver-Cluster 410 die Objektmetadaten und das Dateisystemobjekt in dem lokalen Speicher (Schritt 787). Der Verteilungsserver-Cluster 410 erstellt ferner eine Metadateisystemstruktur, wenn das Dateisystemobjekt einen Datenträger oder ein Verzeichnis darstellt und erstellt eine Blockindexanordnung bzw. Block Index Array für ein Dateiobjekt als zusätzlichen Teil der Dateimetadaten (Schritt 787). CMS 170 folgt mit der Ausgabe eines Befehls FDP DIST an den Verteilungsserver-Cluster 410, um die Verteilung des Dateisystemobjekts gemäß einer Reihe von Verteilungsregeln einzuleiten (Schritt 788). Nach dem Schritt 784 oder dem Schritt 788 fährt die Steuerung mit dem Schritt 790 aus der Abbildung aus 7B fort.
Wenn, wie dies in der Abbildung aus 7B dargestellt ist, der Verteilungsserver-Cluster 410 die FDP-Befehle INFO, CLEAN oder DIST empfängt, so startet er einen Multicast-Signalgebungsprozess unter allen Verteilungsserver-Clustern in dem Netzwerk 100 (Schritte 790–791). Zur Unterstützung der Beschreibung aus der Abbildung aus 7B ist der Verteilungsserver-Cluster, der die Schritte 790 und 791 ausführt, auch mit "DSx" bezeichnet. Ein benachbarter oder anderer Verteilungsserver-Cluster ist in der Abbildung aus 7B mit "DSy" bezeichnet.
In einem Ausführungsbeispiel erfolgt das Signal-Multicasting nur innerhalb einer qualifizierten Gruppe von Verteilungsserver-Clustern auf der Basis von Verteilungsregeln und/oder -kriterien, die nachstehend im Text näher beschrieben werden. Die Multicast-Signalisierung bzw. Signalgebung für den Befehl INFO und für den Befehl CLEAN bleibt unverändert; das Multicast-Signal für einen Befehl DIST ist ein Replikatbefehl REPL. Indem Schritt 791 sendet der Verteilungsserver-Cluster DSx (bezeichnet als signalisierender Verteilungsserver-Cluster) das Signal an alle seine Nachbarn, welche mit den Verteilungskriterien/-regeln übereinstimmen, mit Ausnahme des signalisierenden DSx. Der Verteilungsserver-Cluster DSx kann das Signal beenden, wenn kein benachbarter Verteilungszentrum-Cluster den Verteilungskriterien/-regeln entspricht.
Es wird folgendes Beispiel angeführt. Wenn der Verteilungsserver-Cluster DSx (oder einfach A) einem benachbarten Verteilungsserver-Cluster DSy (oder einfach B) signalisiert, und wenn B temporär nicht verfügbar ist, wird das Signal für B bei A gespeichert, während A mit der Signalisierung aller benachbarten Verteilungsserver-Clients von B fortfuhr. Wenn B wieder verfügbar wird, nimmt A das Signal an B wieder auf. Nähere Einzelheiten zu der FDP-Signalisierung werden weiter unten im Text beschrieben.
In den Schritten 792–798 empfängt DSy das Signal und behandelt das Signal entsprechend. Wenn es sich bei dem Signal um den Befehl INFO handelt (Schritt 793), so validiert DSy die enisprechenden Zeitstempel (Erzeugungszeitstempel des Objekts und Aktualisierungszeitstempel) und verändert die Objektmetadaten und/oder die Metadateisystemstruktur entsprechend (Schritt 794). Die Metadateisystemstruktur wird aktualisiert, wenn ein Objekt in einem anderen Verzeichnis neu angeordnet wird. Wenn es sich bei dem Signal um den Befehl CLEAN handelt (Schritt 796), so entfernt DSy die Daten, Objektmetadaten und Metadateisystemstruktur, die dem Objekt zugeordnet sind (Schritt 797). Wenn es sich bei dem Objekt um einen Datenträger oder ein Verzeichnis handelt, so werden alle eingebetteten Unterverzeichnisse und Dateien entfernt. Wenn es sich bei dem Signal um einen Befehl REPL handelt (Schritt 798), so gibt DSy einen Befehl FDP GET an den bzw. die am nächsten liegenden Knoten aus, um die Objektmetadaten und bestimmte Datenblöcke herunterzuladen, wenn es sich bei dem Objekt um eine Datei handelt (Schritt 799). DSy erzeugt einen Verzeichnisknoten in der Metadateisystemstruktur, wenn der Befehl REPL bestimmt ist für einen neuen Datenträger oder ein Verzeichnis (Schritt 799). DSy speichert dann die Objektmetadaten in dem entsprechenden Verzeichnis in der Metadateisystemstruktur (Schritt 799). Wenn das Ziel von REPL ein Dateiobjekt ist und die Anzahl der herunterzuladenden Datenblocke konfiguriert werden kann oder auf einer Kostenfunktion basiert. DSy erzeugt ferner einen. Blockindexanordnung als Teil der Dateimetadaten (Schritt 799). In jedem der Schritte 794, 797 und 799 fährt der jeweilige Verteilungsserver-Cluser DSy mit dem Multicasting fort, indem er zu einem signalisierenden Verteilungsserver-Cluster wird (z. B. wird DSx auf DSy gesetzt). Die Steuerung kehrt danach zu dem Schritt 791 zurück. Auf diese Weise fahren die an dem Multicasting beteiligten Verteilungsserver-Cluster mit dem Multicasting des Signals fort, bis alle abschließenden Knoten in dem erreicht werden, Schritt 791, und Metadaten werden integriert.
Die Abbildung aus 7C veranschaulicht Prozesse in CMS 170, VFCS 470 und dem Verteilungsserver-Cluster 410 (z. B. DSx oder DSy), wobei die Dienstgüterichtlinien abgerufen (Schritt 704) und angewandt (Schritt 706) werden können, während Dateisystemobjekte gemäß den konfigurierten Parametern verteilt und gespeichert werden. Zum Beispiel kann eine Richtlinie so konfiguriert werden, dass sie eine bestimmte Qualitätsklasse der Behandlung (Service) für das Speichern und die Verteilung einer MPEG-Datei garantiert. Eine andere Richtlinie wiederum kann so konfiguriert werden, dass sie eine Servicequalität für eine bestimmte Benutzergruppe garantiert. CMS 170, VFCS 470 und der Verteilungsserver-Cluster 410 können Netzwerk- oder Speicherressourcen von Switches, Routern oder Server in dem Netzwerk 100 abrufen. Die Schritte 704 und 706 können als Teil eines oder mehrerer der Schritte 784, 730, 750, 788 und 791 ausgeführt werden.
2. Zerlegung großer Dateien-Chunking Prozess
a. Zerlegung linearer und nicht linearer Dateien
Die vorliegende Erfindung kann in Verbindung mit jeder Art von Datei verwendet werden. Eine Datei kann digitale Daten in jedem Dateiformat aufweisen. Derartige digitale Daten können jede Art von Daten darstellen, insbesondere Audio-Daten, Video-Daten, Grafikdaten, Textdaten, Steuerinformationen, Indexinformationen und Kombinationen dieser. Wenn eine Datei über CMS 170 oder VFCS 470 in das SCDN 100 eingeführt wird, wird die Datei in einer Reihe von Schritten in Blöcke aufgeteilt, und der Prozess kann davon abhängig sein, ob es sich um eine lineare Datei oder um eine nicht lineare Datei handelt. Wenn gemäß einem Aspekt der vorliegenden Erfindung zum Beispiel eine Filmdatei verwendet wird, so ist die Datei linear, wenn die ersten 10% des Films sich ungefähr innerhalb den ersten 10% der Datei befinden, wobei sich die nächsten 10% innerhalb der nächsten 10% der Datei befinden, usw. Im Gegensatz dazu gilt eine Filmdatei dann als eine nicht lineare Datei, wenn sich die ersten 10% des Films an anderer Stelle als ungefähr innerhalb den ersten 10% der Datei befinden.
Beispielhafte lineare und nicht lineare Dateistrukturen sind in der Abbildung aus 8 veranschaulicht. Das Format 800 kann zum Beispiel das mpeg-Format darstellen, das linear ist, da es in der Datei in einer einzigen Spur bzw. einem Track multiplexierte Audio-/Videodaten aufweist, beginnend am Anfang. Hiermit wird festgestellt, dass jeder Unterbereich in den verschiedenen Formaten eine Spur bzw. einen Track darstellt. Die Formate 810–830 weisen mehrere Tracks auf. Wie dies abgebildet ist, ist das Format 810 nicht linear, da es Header-Informationen in der ersten Spur der Datei aufweist, gefolgt von Metadaten in der nächsten Spur, von Videoinformationen in der dritten Spur, von Metadaten in der vierten Spur, von einem ersten Audiokanal in der fünften Spur, von einem zweiten Audiokanal in der sechsten Spur und von gewissen Steuerungsinformationen am Ende. Der Anfang eines für das Format 810 formatierten Films würde sich somit nicht am Anfang der Datei befinden. Die Formate 820 und 830 sind Darstellungen anderer möglicher nicht linearer Mediendatenformate. Zum Beispiel kann das Format 820 Daten aufweisen, die so formatiert sind, dass die Datei Header-Informationen am Anfang aufweist, wobei darauf eine bestimmte 56K Codierung für Formate wie z. B. MPEG folgt, gefolgt von 128 K Codierungsinformationen. Andere Formate 830 können Header-Informationen, gefolgt von Indexinformationen, gefolgt von Video- und schließlich von Audiodaten aufweisen. All diese und andere nicht lineare Dateien müssen zuerst unterteilt werden und auf lineare Weise neu angeordnet werden für eine Kompatibilität mit dem nachstehend beschriebenen Replikationsalgorithmus.
Die Abbildung aus 9 zeigt den Prozess der Zerlegung bzw. Aufteilung einer Datei in Blockdateien für die Speicherung. Dieser Prozess wird als "Chunking" bezeichnet und kann auf regelmäßige oder unregelmäßige Art und Weise erfolgen, wie dies nachstehend in Bezug auf die Abbildungen der 10A–B beschrieben ist.
Beim unregelmäßigen Chunking wird Medieninhalt in zwei Phasen in Chunks bzw. Stücke aufgeteilt. In der ersten Phase wird ein nicht linearer Medienanteil in mehrere lineare physikalische Spurdateien aufgeteilt. Mehrere Spurdateien werden durch Multiplexing zu einer Mediendatei zusammengesetzt. In der zweiten Phase wird eine lineare Spurdatei in Blockdateien aufgeteilt. Wie dies in der Abbildung aus 10A dargestellt ist, wird beim unregelmäßigen Chunking nicht mehr als eine Blockdatei vollständig populiert, da die große Nutzlastdatei in Spurdateien aufgeteilt wird und die Spurdateien danach weiter in Blockdateien aufgeteilt werden. Wenn somit eine Spurdatei sich nicht vollständig in Vielfache der ausgewählten Blockgröße aufteilen lässt, können Dateien mit mehreren Spuren einen oder mehrere Blöcke aufweisen, die nicht vollständig belegt sind.
Beim regelmäßigen Chunking wird der Demultiplexierungsprozess 910 eingesetzt, um die physischen Spurleitungen zu bestimmen, ohne die Datei tatsächlich in Spuren aufzuteilen. Der Inhalt wird danach in gleiche Stück- bzw. Chunk-Größen aufgeteilt, mit Ausnahme des letzten Blocks. Der Blocking Prozess überprüft bzw. untersucht danach jeden Block: der Block, der mindestens eine Spurleitung aufweist, wird zum Anfang einer logischen Spur- bzw. Track-Datei, und alle auf diesen Block folgenden Blöcke bilden die logische Spurdatei. Wie dies in der Abbildung aus 10B dargestellt ist, kann die letzte Blockdatei teilweise belegt werden durch das regelmäßige Chunking-Verfahren, da die große Nutzlastdatei nicht zuerst in Spurdateien aufgeteilt wird, sondern die Spurleitungen bestimmt und aus anderen Gründen eingesetzt werden, wie etwa zum Lokalisieren des Anfangs einer Spur zu Wiedergabezwecken. Danach wird die ganze Datei in Blockdateien aufgeteilt, wobei der letzte Block das Potenzial aufweist, nicht voll besetzt bzw. populiert zu sein.
Zum Beispiel unter Verwendung der in der Abbildung aus 10A zur Veranschaulichung dargestellten Daten weist die große Nutzlastdatei 1000 den Header in der ersten Spur auf, Video in der zweiten Spur, den ersten Audiokanal in der dritten Spur, den zweiten Audiokanal in der vierten Spur und schließlich Steuerungsinformationen in der fünften Spur. Der Content Management Server 170 (oder CPC 130) unterteilt die große Nutzlastdatei 1000 in fünf lineare Spurdateien 1010, so dass eine Datei den Header aufweist, eine zweite Datei Videodaten, eine dritte Datei den ersten Audiokanal und so weiter.
In erneutem Bezug auf die Abbildung aus 9 werden die linearen Spurdateien 920 oder die lineare große Nutzlastdatei 950 (die ebenfalls eine lineare Spurdatei darstellt) durch den CMS über das Netzwerk zu einem DS übertragen, mit dem er verbunden ist. Alternativ kann der ganze Chunking-Prozess in ein VFCS integriert werden, wobei das VFCS die Daten und die Metadaten in dem Speicher speichern, ohne durch einen DS zu verlaufen. Die Dateien können gemäß einem File Distribution Protocol (FDP) von dem CMS zu DS übertragen werden, wie dies nachstehend im Text beschrieben wird. Die Dateien von dem CMS werden in einen DS-basierten Blockbildungsprozess 930 eingegeben, der Blockdateien 940 erzeugt. Die Blockdateien 940 werden in der Folge in dem lokalen Speicher des DS gespeichert. Nach der Verarbeitung kann der Inhalt durch andere Verteilungsserver in dem Netzwerk heruntergeladen werden. Im Allgemeinen muss keine direkte Beziehung gegeben sein zwischen der Größe der über das Netzwerk übertragenen Dateien und den in dem lokalen Speichersystem des DS gespeicherten Blockdateien.
Der Blockbildungsprozess 930 unterteilt Spurdateien in kleinere, verwaltbare Einheiten, wie dies in dem Block 1020 aus der Abbildung aus 10A dargestellt ist. Der Blockbildungsprozess erzeugt die Mehrzahl von Blockdateien H, V_1-4, A_1,1-1,2, A_2,1-2,2 und C (gemeinsam in der Abbildung aus 10A als 1020 bezeichnet). Blockdateien können Datenüberschneidungen oder Versätze (z. B. Verschiebung) aufweisen. Zum Beispiel kann die Blockdatei V₁ einen bestimmten Teil der Header-Spur aufweisen und so weiter. In den Blockdateien ist der Anfang jeder Spur in der ersten für diese Spur erzeugten Blockdatei enthalten, zum Beispiel ist der Anfang von Audiokanal Ch1 in A_1,1 enthalten und wobei der Anfang von Audiokanal CH2 in A_2,1 enthalten ist, etc. In anderen Ausführungsbeispielen kann die Datei (d. h. nicht linear) direkt in Blockdateien aufgeteilt werden, ohne zuerst den Demultiplexierungsprozess zu durchlaufen (z. B. Block 910), so dass jede Blockdatei sich überlappende Spuren aufweisen kann. Der Blockbildungsprozess hat Metadaten erzeugt, die dazu verwendet werden die Datei zu einem späteren Zeitpunkt wieder zusammenzusetzen. Das Aufteilen der Datei in Blöcke macht es möglich, die Blockdateien in verschiedene Speichervorrichtungen zu verteilen und mehr Speichervorrichtungen hinzuzufügen, wenn dies erforderlich wird, ohne dabei die Systemleistung zu beeinträchtigen. Die Skalierbarkeit ermöglicht es unter anderem der vorliegenden Erfindung, einen effektiven Ansatz für die Globalisierung des Speicherns darzustellen. Zum Beispiel können mehr Speichervorrichtungen einem Verteilungszentrum 400A–C hinzugefügt werden, ohne dass Dateien verschoben oder andere Knoten neu konfiguriert werden müssen. Ferner können verschiedene Blöcke an verschiedenen Knoten des SCDN angeordnet werden. Die kleineren Blockdateien ermöglichen es, mehrere Anwendungsserver (z. B. Streaming Server) gleichzeitig zu unterstützen, mit erhöhter Speicherzugriffsbandbreite. Ferner können mehrere Blockdateien einer Datei parallel auf nicht zusammenhängende Art und Weise von verschiedenen Knoten in dem Netzwerk heruntergeladen werden. Des weiteren ist das schnelle Vorspielen und das schnelle Zurückspielen über einen Streaming Server durch einen Benutzer ebenfalls möglich, ohne dass die ganze Datei zuerst auf den Knoten heruntergeladen wird, der den Streaming Server unterstützt.
b. Leistungsaspekte in Bezug auf die Blockgröße und die Dateiverteilung
Das Aufteilen von Dateien in Blockdateien ist mit bestimmten Vorteilen verbunden. Zu den Vorteilen des Aufteilens von Dateien in Blockdateien zählen: (a) das parallele Herunterladen bzw. Downloaden einer einzelnen Datei durch mehrere lokale Verteilungsserver zu ermöglichen, um die Download-Performance zu verbessern; (b) das Downloaden einer Datei von mehreren Positionen bzw. Standorten zu ermöglichen; (c) das Verteilen eines Speicherzugriffsladens zu ermöglichen durch Speichern der Blöcke der gleichen Datei in mehreren Disks bzw. Plattenspeichern (dadurch wird die E/A-Bandbreite einer einzelnen Datei erhöht); (d) das Ermöglichen von Effekten des "schnellen Vorspulens" und "Zurückspulens", ohne alle Daten zwischen den Punkten herunterzuladen, wo das "schnelle Vorspulen" oder "Zurückspulen" beginnt und dem Zielpunkt. Das schnelle Vorspulen kann erreicht werden, indem die Download-Köpfe nach vorne bewegt werden – zu Blöcken, die näher an dem Ende der Datei liegen. Dadurch werden "Löcher" in dem mittleren Teil der Datei erzeugt, wo das Downloaden unvollständig ist. Das "Zurückspielen" bzw. "Zurückspulen" durch ein derartiges "Loch" bringt es mit sich, dass sich die Download-"Köpfe" über das "Loch" hinaus bewegen und die fehlenden Blöcke herunterladen; und (e) das Verbessern der Skalierbarkeit und den Verzicht auf die Notwendigkeit der Migration im großen Maßstab, wenn Speicherbegrenzungen erreicht werden. Wenn Hunderte von Blöcken in einem einzigen Speicherdatenträger angeordnet sind und der Datenträger voll ist, können zusätzliche Blöcke einer einzelnen Datei in einem neu hinzugefügten Speicherträger gespeichert werden und vollständig funktionstüchtig sein, ohne dass eine umfassende Migration der ganzen Datei auf den neuen Datenträger erforderlich ist.
Die Größe der Blöcke beeinflusst die Performance sowohl der Verteilung von Inhalten (Content Distribution) als auch der Zustellung von Inhalten (Content Delivery). Gemäß einem Merkmal von Ausführungsbeispielen der vorliegenden Erfindung werden bei der Bestimmung der Blockgröße mehrere Faktoren berücksichtigt:

1) die Ethernet MTU (Maximum Transmission Unit) Größe;
2) die Größe der physischen Speichereinheiten;
3) die erforderliche Zeit für die Übertragung eines Blocks (steht im Verhältnis zu der Netzwerkbandbreite); und
4) die kürzeste zulässige Dauer, die übersprungen werden kann als Reaktion auf einen Befehl zum schnellen Vorspulen oder Zurückspulen während der Zustellung von Inhalten (dies wird als minimales Flash-Intervall bezeichnet).

Die Erfinder haben erkannt, dass verschiedene Aufgaben bzw. Ziele bei der Bestimmung der Blockgröße berücksichtigt werden müssen. Eine Aufgabe ist es, die Raumnutzung in einer MTU zu maximieren, was die Verteilung von Inhalten effizienter gestalten würde. Eine weitere Aufgabe ist es, eine Überlastung an den Verteilungsknoten so gering wie möglich zu halten. Eine weitere wichtige Aufgabe zur Bestimmung der Blockgröße ist es, eine Speicherfragmentierung zu verhindern, da die Fragmentierung die Performance des Dateisystems verschlechtert, wiederum im Einklang mit dem Erreichen der anderen Ziele bzw. der Umsetzung der weiteren Aufgaben.
Blockgrößen, die zu groß oder zu klein sind, können die Performance bzw. die Leistung beeinflussen. Zum Beispiel ist dies in Bezug auf den Befehl zum schnellen Vorspulen bzw. Vorspielen möglich. Wenn die Blockgröße zu groß ist, kann die Serverantwort auf Anforderungen des schnellen Vorspulens während einem Download schwergängig sein, da der Server das Herunterladen der jeweiligen Blockdatei abschließen muss, bevor er derartige Anforderungen verarbeiten kann. Wenn die Blockgröße hingegen zu klein ist, ist das schnelle Vorspulen zu dem Ende des Blocks sehr schnell. Wenn die Blockgröße sich innerhalb des Mindest-Flash-Intervalls befindet, kann ein anderer Verteilungsserver auf Anforderungen zum schnellen Vorspulen ansprechen bzw. antworten, indem der Block abgerufen wird, der den Zielinhalt aufweist.
Auf der Basis der oben genannten Kriterien beträgt unter bedachten Annahmen zu den Betriebsparametern des physischen Netzwerks und dem Netzwerk an sic, welches das SCDN 100 unterstützt, und entsprechender Annahmen in Bezug auf die Größe des Flash-Intervalls sowie zur Minimierung der Netzwerküberlastung, kann die Blockgröße gemäß einem Aspekt der vorliegenden Erfindung 256 kBytes betragen. Für den Durchschnittsfachmann auf dem Gebiet ist es in Anbetracht der vorliegenden Beschreibung ersichtlich, dass sich die Blockgröße ändern kann, wenn ein oder mehrere Netzwerkparameter oder sonstige Annahmen sich ändern, und dass die optimale Blockgröße abhängig sein kann von der jeweiligen Implementierung und Anwendung. Im Allgemeinen können auch andere Blockgrößen (größer und kleiner als 256 kBytes) verwendet werden.
Darüber hinaus muss die Blockgröße in dem Speicher eines übertragenden oder Zustellnetzwerks nicht konstant sein. Jeder DS in dem Netzwerk kann eigene Einstellungen aufeisen abhängig von der jeweiligen Beschaffenheit der Speichervorrichtungen und dem jeweiligen Netzwerkzustand. Ferner kann jede Datei eine unterschiedliche Blockgröße aufweisen, abhängig von einer Reihe möglicher Parameter, wie zum Beispiel der Art der Datei (z. B. ob es sich um eine Textdatei, eine Audiodatei oder eine Videodatei handelt). Diese Blockgrößen können zum Beispiel von Zeit zu Zeit nach Bedarf verändert werden oder durch Messen der Netzwerkparameter und die dynamische Veränderung der Blockgröße.
Die Anzahl der an einen qualifizierten Knoten verteilten Blöcke während der anfänglichen Dateiverteilungsphase wird durch eine Reihe von Faktoren bestimmt, einschließlich der Entfernung von dem Ursprungs-DS (d. h. wo die Datei hochgeladen wurde) zu dem Knoten, der Bandbreite des vorderen und des hinteren Endes des Knotens (den aktuellen Netzwerkbedingungen), den prädizierten Netzwerkbedingungen, den Nutzungsinformationen aus der Vergangenheit zu dem Knoten, einem "Popularitätsindex", der durch den Inhalteanbieter festgelegt wird, sowie den Speicher, der dem Inhalteanbieter an diesem Knoten zur Verfügung steht. Ein Content Owner bzw. Inhalteeigentümer kann die prognostizierte Popularität eines Films während dessen ersten Distribution angeben. Die Popularität dient als Referenz, die Verteilungsserver dabei unterstützt zu bestimmen, wie viele Blöcke einer Datei zuerst bzw. anfänglich herunterzuladen sind. Im Zeitverlauf passt ein Speichermanager (Storage Manager), der in einer Steuereinheit 450 enthalten ist, auf der Basis der gesammelten Nutzungsinformationen die tatsächliche lokalisierte Popularität einer Datei, um die entsprechende Pruning-Fähigkeit zu bestimmen. Die Popularität einer Datei kann direkt proportional sein zu der Anzahl der Blockdateien, welche sie aufweist, oder die minimale Speichergröße kann konfiguriert werden.
Inhalteeigentümer können einen bestimmten Speicherplatz an jedem Knoten reservieren. An jedem Knoten zeichnen die Verteilungsserver die ankommende Übertragungsrate für jeden Inhalteeigentümer bzw. Content Owner auf. Ein Speichermanager legt einen Sicherheitsspeichergrenzwert für jeden Content Owner auf der Basis des Netzwerkzustands und der ankommenden Übertragungsrate fest. Der Speichermanager löscht regelmäßig einige der Blöcke der Dateien, die in der Zukunft mit der geringsten Wahrscheinlichkeit verwendet werden. Ein Parameter der Pruning-Rate kann festgelegt werden, um es zu verhindern, dass die Speichernutzung einen Sicherheitsschwellenwert überschreitet. Wenn die Pruning-Rate die vordefinierte Schwelle erreicht, wahrscheinlich aufgrund von übermäßigem Inhalt, so wird die Content Management-Anwendung an der Basisstation des Content Providers davon benachrichtigt. Wenn dies erfolgt, kann der Content Owner keine Inhalte zu der überlasteten Station übertragen, ohne den reservierten Speicher zu vergrößern bzw. zu erweitern. Es gibt zahlreiche Optionen zum Speichern von Blockdateien in dem Netzwerk. Mehrere der Optionen umfassen eine Kostenfunktion, wobei versucht wird, die Kosten für den Abruf so gering wie möglich zu halten, wie zum Beispiel durch Replikation zusätzlicher Blockdateien mit stark nachgefragtem Inhalt und weniger Blockdateien mit kaum nachgefragtem Inhalt, wobei Blockdateien an Speicherplätzen nahe der Nachfrage anstatt weit davon entfernt gespeichert werden, wobei Blockdateien dort gespeichert werden, wo auf sie durch Hochgeschwindigkeits-Übermittlungsstrecken anstatt durch langsame Übermittlungsstrecken zugegriffen wird, und wobei auch andere ähnliche Techniken möglich sind. Eine dynamische Kostenfunktionsoption ist eine Option, die dynamisch auf das Netzwerk zugreift und Blöcke gemäß einer neu berechneten Kostenfunktion lokalisiert bzw. anordnet und neu anordnet. Zusätzliche Optionen können auf durch einen Benutzer definierten Kriterien oder auf durch Richtlinien geregelten Kriterien basieren, wobei die Bedienungspersonen an jedem Knoten die Anzahl der Blöcke je Datei definieren, oder durch Inhalteeigentümer, welche die Anzahl der Blöcke definieren, die an jeden Knoten verteilt werden sollen. Eine Kombination aus diesen Optionen ist ebenfalls möglich.
Es gibt zahlreiche unterschiedliche Möglichkeiten, wie eine Datei an das SCDN 100 verteilt werden kann. Dazu zählen insbesondere die folgenden Möglichkeiten:

1) hierarchisch – wobei ein näher an dem Quellknoten bzw. Ursprungsknoten gelegener Knoten mehr Inhalt speichert als ein weiter von dem Ursprungsknoten entfernter Knoten in dem Steuerungsweg;
2) benutzerdefiniert oder auf der Basis von Richtlinien – wobei Operatoren bzw. Bedienungspersonen an jedem Knoten die Anzahl der Blöcke je Datei definieren, die an dem Knoten gespeichert werden, oder Inhalteeigentümer definieren die Anzahl der Blöcke, die an jeden Knoten zu verteilen sind für jede ihrer Dateien;
3) dynamisch – abhängig von der Benutzernachfrage und Ressourcen, während die Ressourcen die Netzwerkbandbreitenverfügbarkeit und die Speicherverfügbarkeit aufweisen; und
4) eine Kombination der vorstehenden Möglichkeiten bzw. Methoden.

3. Verteilung von Dateisystemobjekten
a. Verteilung von Dateisystemobjekten durch Inhalteeigentümer
Um bei dieser spezifischen Implementierung ein Dateisystemobjekt zu verteilen, legt ein Inhalteeigentümer bzw. Content Owner spezielle Kriterien für diese Datei fest. Die Verteilungskriterien können konfiguriert oder durch den Befehl FDP DIST eingeführt werden, wie dies vorstehend im Text in Bezug auf die Abbildungen der 7A–B beschrieben worden ist. Wenn ein Dateisystemobjekt über einen CMS in das SCDN eingeführt wird, kann der Inhalteeigentümer Verteilungsparameter festlegen, und der CMS-Server gibt FDP DIST für DS aus, um Objektmetadaten und das Dateisystemobjekt an andere Knoten in dem SCDN zu verteilen. Wenn ein Dateisystemobjekt über einen VFCS in das SCDN eingeführt wird, verwendet der VFCS vorkonfigurierte Verteilungsregeln für die Ausgabe von FDP DIST an einen DS, um die Objektmetadaten und das Dateisystemobjekt an das SCDN zu verteilen. Wenn es sich bei dem Dateisystemobjekt um eine Datei handelt, kann ein Teil bzw. eine Teilmenge der Datei an das SCDN verteilt werden, um zum Beispiel den Inhalt zum Rand des Netzwerks zu drängen. Die Verteilung erfolgt gemäß den spezifischen Verteilungskriterien, die von den Inhalteeigentümern festgelegt worden sind, und wobei das File Distribution Protocol (FDP) verwendet werden kann, das nachsehend im Text beschrieben wird. Diese Verteilungskriterien können Regionen (z. B. Europa), spezifische Knoten und andere Informationen spezifizieren, wie dies von den Inhalteeigentümern gewünscht wird, um die Verteilung des Inhalts zu steuern. Die Verteilungskriterien können zum Beispiel Informationen aufweisen, die in der Attributgruppe eines Knotens oder in einer aufgerollten Attributgruppe zu finden sind. Hiermit wird festgestellt, dass die Begriffe bzw. Abkürzungen "DS" und "DSC" hierin austauschbar verwendet werden und einen Verteilungsserver-Cluster (wie zum Beispiel DSC 410) bezeichnen, der einen oder mehrere Verteilungsserver aufweist. Ferner kann es sich bei einem Verteilungsserver um jede Art von Verarbeitungs- oder Rechenvorrichtung handeln, welche die hierin beschriebene Verteilungsfunktionalität ausführen kann.
b. File Distribution Protocol (FDP)
Das FDP Protokoll definiert die Primitive des Dateimanagements, die erforderlich sind, um Dateisystemobjekte und Objektmetadaten zu übertragen, zu speichern und zu manipulieren, die in dem Netzwerk gespeichert sind. Die Primitive weisen Befehle auf, welche Dateien hochladen, verteilen, zustellen, modifizieren und löschen. Die FDP-Befehle führen dazu, dass ein oder mehrere Pakete zwischen entsprechenden Servern in dem Netzwerk übertragen werden. Für den Durchschnittsfachmann auf dem Gebiet ist es offensichtlich, dass die hierin beschriebenen Befehlsbezeichnungen und Protokollimplementierungen zur vereinfachen Darstellung verwendet werden, und wobei andere Befehle oder Protokolle hinzugefügt, herausgenommen oder ersetzt werden können, sofern sie zu einer effizienten und zuverlässigen Übertragung von Dateien in dem Netzwerk führen.
In einem Ausführungsbeispiel der vorliegenden Erfindung weist das FDP-Protokoll den folgenden FDP-Befehl auf: Put (Senden), Distribute (Verteilen), Replicate (Replizieren), Get (Holen), Prepare (Vorbereiten), Search (Suchen), Remove (Entfernen), Clean (Löschen), Info (Info), Learn (Lernen), Fetch (Erfassen), Fetch (Erfassen), Fetch Info (Info erfassen) und Stop (Stopp). Jeder FDP-Befehl und alle Arten von Paketen, die dem Befehl zugeordnet sind, werden nachstehend im Text beschrieben.
"Put" (Senden): Ein Inhalteeigentümer verwendet Content Management-Anwendungen, die auf einem Content Provider Client-System ausgeführt werden, um ein Dateisystemobjekt (Datenträger, Verzeichnisse und Dateien) und Objektmetadaten (Daten in Bezug zu der Verwaltung der Dateisystemobjekte, die in dem Netzwerk gespeichert, übertragen und manipuliert werden) in einen Content Management Server (CMS) hochzuladen oder zu verändern. Wenn es sich bei dem Dateisystemobjekt um eine Datei handelt, unterteilt der CMS die Datei in lineare Spurdateien und gibt danach einen Befehl "put" an einen DS aus, der letztlich den Inhalt in dem Netzwerk verteilt. In einem Ausführungsbeispiel ist der CMS mit einem DS an einem SCDN-Knoten verbunden. Der CMS sendet einen Befehl "put" an den DS für jede der Spurdateien, um einen Datenträger, ein Verzeichnis oder eine Datei zu erzeugen. In seiner Wirkung ist der Befehl "put" eine Aktion des "Einspeicherns" bzw. der "Eingabe", wobei eine Spur oder ein Datenträger oder ein Verzeichnis von einem CSM in einen DS eingegeben werden. Ein Befehl "put" kann vier Pakete aufweisen, wie zum Beispiel "put", "put_response", "put_data" und "put_ack". Das jeweilige "put"-Paket teilt dem empfangenden DS mit, sich für den Empfang einer Spurdatei bereit zu machen. Das Paket "put_response" ist ein von dem DS ausgegebenes Paket, um dem CMS anzuzeigen, ob der DS die Spurdatei empfangen muss oder nicht, und wenn er es empfangen muss, wo mit der Übertragung begonnen werden muss. Dieses Paket kann in einer Situation nützlich sein, wenn eine Kommunikationssitzung aufgeteilt wird, nachdem ein Teil der Spurdatei übertragen worden ist, und wobei der CMS den restlichen Teil der Datei erneut übertragen muss. Nachdem der DS dem CMS kommuniziert hat, wo die Übertragung einer Spurdatei beginnen soll, kann der CMS ein Paket "put_data" in Verbindung mit der eigentlichen Spurdatei, dem Datenträger oder dem Verzeichnis ausgeben. Der DS kann mit einem Paket "put_ack" antworten, wenn die ganze Spurdatei oder ein anderes Dateisystemobjekt empfangen wird, um die erfolgreiche Übertragung anzuzeigen. Wenn es sich nachdem die Daten empfangen worden sind bei den Daten um eine Spurdatei handelt, teilt der DS die linearen Spurdateien in Blockdateien auf, speichert die Blockdateien im lokalen Speicher und aktualisiert die Dateimetadaten, um die Spur-, Block- und Positionsinformationen zu reflektieren – die Blockindexanordnung.
"Distribute" (Verteilen): Nachdem das ganze Dateisystemobjekt und dessen Objektmetadaten in den DS eingegeben oder in den Speicher geschrieben worden sind durch ein VFCS, können der CMS oder ein VFCS Pakete "verteilen", welche den DS anweisen, die Datei an andere Knoten in dem Netzwerk zu verteilen. Zum Beispiel kann der CMS ein Paket "distribute" (Verteilen) je Spurdatei, Datenträger oder Verzeichnis ausgeben, wobei jedes Paket die Verteilungskriterien des Inhalteeigentümers enthält. Die Verteilungskriterien können zum Beispiel spezifizieren, welche Knoten in dem Netzwerk das Dateisystemobjekt aufweisen sollten. Der Befehl "distribute" kann zwei Pakete aufweisen, wie zum Beispiel "distribute" und "distribute_ack". Der DS kann den Empfang des Befehls "distribute" bestätigen, indem ein Paket "distribute_ack" an den CMS oder VFCS ausgegeben wird.
"Replicate" (Replizieren): Als Reaktion auf den Befehl "distribute" kann der DS Pakete "replicate" an dessen Nachbarn ausgeben. Jeder Nachbar, der die durch den Content Owner spezifizierten Verteilungskriterien erfüllt, kann einen Befehl (wie zum Beispiel den Befehl "get" für ein Paket (Paket holen), der nachstehend im Text beschrieben wird) an einen oder mehrere DS in dem Verteilungspfad ausgeben, um einen Teil der Datei oder des Datenträgers oder des Verzeichnisses in dessen lokalen Speicher zu ziehen. Das Paket "replicate" beginnt an dem DS, wo die Dateisystemobjekte hochgeladen werden oder wo sich der VFCS befindet, der die Dateisystemobjekte aktualisiert. Das Paket "replicate" fungiert als eine Benachrichtigung an einen DS, dass er unter Umständen bestimmte Blockdateien oder Datenträger oder Verzeichnisinformationen von etwaigen der ausgebenden DS in dessen lokalen Speicher ziehen (d. h. replizieren) muss. Der empfangende DS kann die Benachrichtigung bestätigen, indem ein Paket "replicate_ack" ausgegeben wird, und wobei danach die Verantwortlichkeit für das Ziehen bzw. Entnehmen der Blockdateien aus dem ausgehenden DS übernommen wird, wenn diese bereit sind. Ein DS benachrichtigt ferner dessen benachbarte Knoten, um zu bestimmen, ob sie das Dateisystemobjekt entnehmen sollten, indem Pakete "replicate" an diese ausgegeben werden. Ein DS kann eine Replikationsanforderung an dessen Abkömmlingsknoten ausgeben, wenn das aufgerollte Attribut mit den Inhaltsverteilungskriterien übereinstimmt.
"Get" (Holen): Ein DS, der ein Dateisystemobjekt von einem anderen DS entnehmen muss, kann zum Beispiel einen Befehl "get" (holen) ausgeben. Der Befehl "get" kann vier Arten von Paketen aufweisen: "get", "get_response", "get_chunk" und "get_ack". Zum Beispiel kann das Paket "get" eingesetzt werden, um einen Pull einzuleiten, und das Paket "get_response" kann eingesetzt werden, um den Status der Station zu melden und Objektmetadaten nach Bedarf übertragen. Das Paket "get_chunk" kann eingesetzt werden, um Dateidaten oder Datenträger- oder Verzeichnisinformationen zu übertragen, und das Paket "get_ack" kann eingesetzt werden, um das Ende der "get" Sequenz zu bestätigen und den Status zu melden. Beim Herunterladen einer Datei kann ein DS eine Entscheidung hinsichtlich der Größe der zu entnehmenden (pull) Datei treffen auf der Basis von: (1) dessen Speicherverfügbarkeit; (2) der Position der Station in der Netzwerklandschaft; (3) der Popularität des Inhalts; (4) der Eigenschaft hinsichtlich der Beschneidbarkeit oder der fehlenden Beschneidbarkeit der Datei; und (5) der zulässigen Bandbreite. Ein DS kann "get" Befehlsfolgen als Reaktion auf eine "Replikationsanforderung" (replicate) und eine Anforderung "search_reply" ausgeben.
"Prepare" (Vorbereiten): Ein Befehl "prepare" kann zwei Pakete aufweisen, wie zum Beispiel: "prepare" und "prepare_ack". Wenn Benutzer oder Anwendungsserver über ein VFCS auf ein Dateiobjekt zugreifen, kann das VFCS ein Paket "prepare" an einen DS ausgeben, um die nicht residenten Abschnitte einer Datei für den Benutzer oder den Anwendungsserver zu ziehen bzw. zu entnehmen. Der DS kann das Paket "prepare_ack" verwenden, um zu bestätigen, dass er das Paket "prepare" empfangen hat und "prepare" so bald wie möglich ausführen wird.
"Search" (Suchen): Wenn der DS die Anforderung "prepare" verarbeiten kann, kann er einen Befehl "search" (Suchen) ausgeben, um die fehlenden Abschnitte bzw. Teile einer Datei zu suchen. Ein Befehl "search" kann drei Pakete aufweisen, wie zum Beispiel: "search", "search_ack" und "search_reply". Ein DS, der einen Befehl "prepare" bearbeitet, gibt ein Paket "search" aus, um eine Multicast-Suche unter dessen Nachbarn nach nicht residenten Abschnitten der Datei einzuleiten. Jeder Nachbar kann ein Paket "search_ack" ausgeben, das anzeigt, dass er eine Anforderung "search" empfangen hat. Das Paket "search_ack" ist keine Bestätigung, dass der DS Abschnitte der angeforderten Datei aufweist. Ein Knoten, der einen Abschnitt der benötigten Datei aufweist, kann ein Paket "search_reply" ausgeben. Das Paket "search_reply" kann die Blockindexanordnung aufweisen, welche den Abschnitt der gesuchten Datei anzeigt, die sich in dem Antwortknoten befindet, den Netzwerkzustand des Knotens und die Belastung des DS-Clusters des Knoten. Ein DS in dem einleitenden DS-Cluster empfängt Pakete "search_reply" und kann die entsprechenden entfernten DS-Knoten auswählen auf der Basis der Informationen in den Paketen "search_reply", um die fehlenden Abschnitte der Datei herunterzuladen. Ein DS in dem einleitenden DS-Cluster kann den Befehl "get" zum Beispiel an einen oder mehr Knoten (d. h. ausgewählte SCDN-Knoten) ausgeben, um den fehlenden Inhalt herunterzuladen.
"Remove" (Entfernen): Der Befehl "remove" kann zwei Pakete aufweisen, wie zum Beispiel "remove" und "remove_ack". Die Steuereinheit der Knoten kann einen Befehl "remove" an den DS ausgeben, um bestimmte Blöcke zu entfernen. Der Pruning-Prozess, der später im Text näher beschrieben wird, verwendet den Befehl "remove". Ein Paket "remove" ist eine Benachrichtigung bzw. Mitteilung an einen DS, dass bestimmte Blöcke entfernt werden müssen. Der DS kann in der Folge ein Paket "remove_ack" ausgeben, um zu bestätigen, dass er letztlich die angezeigten Blöcke entfernt, wenn er bereit ist.
"Clean" (Löschen): Der Befehl "clean" kann zwei Pakete aufweisen, "clean" und "clean_ack". Der CMS oder ein VFCS kann ein Paket "clean" oder ein ähnliches Paket ausgeben, um einen an dem gleichen Knoten angeordneten DS zu benachrichtigen, dass er ein bestimmtes Dateisystemobjekt entfernen muss. Der DS gibt ein Paket "clean_ack" oder ein ähnliches Paket aus, um zu bestätigen, dass das Dateisystemobjekt letztlich entfernt wird, wenn der DS dazu bereit ist. Dem während dem Befehl "replicate" verwendeten Pfad folgend (verfügbar in den Verteilungskriterien für die Datei), gibt der DS einen Befehl "clean" oder einen äquivalenten Befehl an dessen benachbarte Knoten aus, wobei das Löschen des Dateisystemobjekts angefordert wird sowie dessen verwandten Metadateisystemarchitektur und Objektmetadaten von allen Knoten in dem SCDN.
"Info": Der Befehl "info" kann zwei Pakete aufweisen, wie zum Beispiel "info" und "info_ack". Der CMS oder ein VFCS kann ein Paket "info" ausgeben, um Dateisystemobjektmetadaten (Daten in Bezug auf die Verwaltung von Datenträgern, Verzeichnissen und Dateien unter Verwendung des SCDN) an einen DS zu verteilen. Das Paket kann eingesetzt werden, um Attribute bestimmter Datenträger, Verzeichnisse oder Dateien hinzuzufügen, zu löschen, neu zu positionieren und zu modifizieren. Wenn ein DS ein Paket "info" empfängt, modifiziert er die Metadateisystemstruktur und die verwandten Objektmetadaten und verteilt danach das Paket "info" weiter an dessen Nachbarn. Ein DS gibt ein Paket "info_ack" an den Anforderer aus (CMS, VFCS oder DS) und gibt danach den Befehl "info" an alle seine Nachbarn mit Ausnahme des Anforderers aus. Ein Paket "info", das Datenträgerinformationen enthält, wird über das ganze SCDN ausgebreitet. Ein Paket "info", das Dateimetadaten enthält, wird auf der Basis der Verteilungskriterien für diese Datei ausgebreitet. Wenn ein CMS oder ein VFCS ein Paket "info" von Objektmetadaten in Verbindung mit den Verteilungskriterien des Dateisystemobjekts an einen DS sendet, so modifiziert der empfangende DS dessen Metadateisystemstruktur nach Bedarf, modifiziert dessen lokale Metadatendatei, welche die Objektmetadaten aufweist, gibt ein Paket "info_ack" an den Anforderer (CMS oder DS) aus und gibt danach ein Paket "info" an die Nachbarn aus, welche die Verteilungskriterien erfüllen (d. h. die Nachbarn, welche die Verteilung der Datei während dem Befehl "replicate" empfangen haben). Dieser Prozess dauert an, bis die Metadateisystemstruktur und die Metadatendatei, welche die Objektmetadaten in allen Knoten aufweisen, welche die Verteilungskriterien erfüllen, aktualisiert werden.
"Learn" (Lernen): Der Befehl "learn" kann von einem lernenden Agenten der Steuereinheit ausgegeben und verwendet werden, wenn ein DS dem SCDN hinzugefügt wird und dessen lokaler Speicher initialisiert werden muss, oder wenn sich die Attribute des Knoten ändern oder in Verbindung mit Netzwerkkonfigurationsänderungen oder während der Wiederherstellung nach einem Fehler. Der DS, der den Befehl "learn" empfängt, verbreitet den Befehl "learn" an alle seine Nachbarn mit Ausnahme des Anforderers. Das Paket "learn" führt die Attribute des Ursprungsknotens. Jeder DS, der ein Paket "learn" empfängt, bestimmt, ob dessen Station Dateisystemobjekte aufweist, welche die Attribute der lernenden Station erfüllen, und wenn dies der Fall ist, gibt der DS "replicate" an einen DS in der lernenden Station aus, um die relevanten Dateisystemobjekte zu entnehmen.
"Fetch" (Erfassen): Der Befehl "fetch" kann von dem lernenden Agenten der Steuereinheit verwendet werden, während dieser in dem aktiven Modus lernt. Der Befehl "fetch" kann zwei Pakettypen aufweisen: "fetch" und "fetch_ack". In dem aktiven Lernmodus erhält der lernende Agent eine Liste von Dateisystemobjekten (Datenträger, Verzeichnisse und Dateien), die zu lernen sind, und des zugeordneten Knotens der Dateisystemobjekte. Während dieser Zeit stehen die Metadateisystemstruktur und die Objektmetadaten für diese Dateisystemobjekte in der lokalen Station nicht bereit, und somit weist der DS nicht die Informationen auf, um eine Suche und einen Download der Dateisystemobjekte durchzuführen. Der lernende Agent gibt ein Paket "fetch" an einen lokalen DS aus, in Verbindung mit der Ursprungsstation des Inhalts. Der DS wiederum gibt ein Paket "fetch_info" an einen DS des zugeordneten Knoten der Dateisystemobjekte aus. Nachdem der DS die Objektmetadaten für die gewünschten Dateisystemobjekte erhalten hat, speichert er die Informationen in der lokalen Metadateisystemarchitektur und der Objektmetadatendatei und gibt "fetch_ack" an den lernenden Agenten zurück. Der lernende Agent kann in der Folge damit fortfahren, Befehle "prepare" zum Herunterladen der Datei auszugeben.
"Fetch_info" (Info erfassen): "Fetch_info" weist zwei Pakete auf, "fetch_info" und "fetch_info_block". Jeder Befehl "fetch" weist darin codiert die Identifikation eines bestimmten Dateisystemobjekts und einen bestimmten DS auf, der garantiert das Dateisystemobjekt aufweist. Als Reaktion auf einen Befehl "fetch" gibt ein DS "fetch_info" an den in "fetch" identifizierten DS-Knoten aus. Der entfernte DS kann mit "fetch_info_block" antworten, worin die erforderlichen Objektmetadaten enthalten sind, um es dem lokalen DS zu ermöglichen, dessen Metadateisystemstruktur und Objektmetadatendateien zu speichern oder zu aktualisieren.
"Stop" (Stopp): Der Befehl "stop" kann zwei Pakete aufweisen, wie etwa "stop" und "stop_ack". Der Befehl "stop" wird dazu verwendet, einen DS abzuschalten. Wenn ein DS ein Paket "stop" empfängt, antwortet er unverzüglich mit "stop_ack", und abhängig von der Abschlussanforderung kann der DS sofort abschalten oder abschalten, nachdem er alle gerade ausgeführten Aufträge abgeschlossen hat.
c. Prozedur für die Dateisystemobjektverteilung
Die Verteilungsprozedur wird eingesetzt, wenn ein neues Dateisystemobjekt erzeugt wird, oder wenn ein bestehendes Dateisystemobjekt modifiziert oder gelöscht wird. Die Modifikation eines Dateisystemobjekts umfasst das Umbenennen, das Ändern etwaiger Attribute, die neue Anordnung und das Ändern von Inhalt (Dateiobjekt).
Die Verteilung eines Dateisystemobjekts verläuft wie folgt: (1) Der DS antwortet bzw. reagiert auf die Anforderung des Inhalteeigentümers (d. h. eine Anforderung von CMS oder VFCS für die Erzeugung oder Änderung eines Dateisystemobjekts) über VFCS oder CMS, Informationen eines Dateisystemobjekts zu verteilen sowie die Anforderung durch Senden einer Mitteilung bzw. Benachrichtigung (d. h. einer Replikationsanforderung) an dessen Nachbarn, um Änderungen und die Verteilungskriterien des Dateisystemobjekts bekannt zu geben; (2) "Qualifizierte" Nachbarn (d. h. diejenigen, welche die Kriterien erfüllen) laden die Objektmetadaten, Informationen und Anforderung herunter. Für die Dateiverteilung werden während diesem anfänglichen Verteilungsprozess verschiedene Abschnitte der Datei heruntergeladen. Diese Nachbarn modifizieren ferner die Metadateisystemstruktur gemäß der Replikationsanforderung, und wobei die Objektmetadaten in deren lokalen Speicher aktualisiert werden; (3) Die Benachrichtigung/Anforderung wird danach von Nachbar zu Nachbar weitergeleitet, jedoch nicht zurück zu dem Nachbarn, von dem die Verteilungsanforderung empfangen wird; (4) Jeder Nachbar führt die Schritte 2 und 3 aus, bis er auf einen Blattknoten oder einen "abschließenden" Knoten trifft. Somit erfolgt die Verteilung der Dateisystemobjektinformationen in dem Netzwerk in Phasen bzw. Stufen über Multicast-Signalisierung, wie dies hierin beschrieben ist.
Jeder Knoten, der eine Verteilungsanforderung oder -benachrichtigung empfängt, leitet die Anforderung an alle seine Nachbarn weiter, mit Ausnahme des "anfordernden" Knotens (d. h. des Knotens, von dem er die Anforderung empfangen hat). Ein abschließender bzw. Abschlussknoten ist ein Knoten, an dem weder die Attribut-Bitmap des Knotens noch dessen aufgerollte Bitmap den Verteilungskriterien entspricht, und wo die Verteilungsanforderung nicht an die Mutter bzw. den Vater bzw. die übergeordnete Einheit übermittelt werden kann. Für jeden Knoten, dessen Attribut-Bitmap den Verteilungskriterien des Inhalteeigentümers bzw. Content Owners für die Datei entspricht, werden die relevanten Dateisystemobjektinformationen, oder wenn es sich um eine Datei handelt, ein Teil der Datei, von den am nächsten liegenden Nachbarn in dem Verteilungspfad heruntergeladen, der die Informationen aufweist, die heruntergeladen werden müssen. Die Benachrichtigung bzw. die Mitteilung basiert auf Transport Level Multicast und das Download der Informationen erfolgt über den gleichen Multicasting-Pfad unter Verwendung der Pull-Methode. Nach dem Download speichert ein DS die Dateiystemobjektinformationen lokal. Dieser DS erzeugt eine zugeordnete Metadateisystemhierarchie, speichert Metadaten, und bei einer vorgesehenen Dateiverteilung speichert der DS die Abschnitte der Datei als Blöcke, die über verschiedene Speicherdatenträger in den Speichervorrichtungen 430 verteilt sind. Beim Verteilen der Datei über mehrere Speicherdatenträger wird die Ein-Ausgabe-Last (E/A) über die Datenträger verteilt und es erhöht sich insgesamt die Performance bzw. Leistungsfähigkeit eines Verteilungszentrums 400A–C während der Inhaltsverteilung und der Zustellung von Inhalten. Im Sinne der vorliegenden Erfindung kann es sich bei den Speicherdatenträgern um jede Anordnung von Speichervorrichtung handeln, wie z. B. Disk Arrays bzw. Plattenanordnungen, die an einem Server angebracht sind, RAID-Systeme (RAID als englische Abkürzung von Redundant Array of Independent Disks) oder um einen Network Attached Storage (NAS) oder ein Storage Area Network (SAN).
Die Abbildungen der 11A–B veranschaulichen ein Ausführungsbeispiel der vorliegenden Erfindung, das sich auf die Verteilung eines Dateisystemobjekts, eine Aktualisierung oder Metadaten in einem SCDN bezieht. Die Abbildung aus 11A zeigt eine virtuelle Baumstruktur 1100 mit den Knoten A–I. Die Abbildung aus 11B zeigt ein Beispiel für die virtuelle Baumstruktur 1102 der Knoten A–I, wobei Daten und Metadaten, welche einer Datei oder Abschnitten einer Datei entsprechen, gemäß der Verteilungsprozedur der vorliegenden Erfindung verteilt worden sind. Ein Inhalteeigentümer erzeugt entweder ein neues Dateisystemobjekt oder eine Aktualisierung eines Dateisystemobjekts über das VFCS 470 des Knotens B oder lädt ein Dateisystemobjekt in den Content Management Server (CMS) 170 hoch, der mit dem Knoten B des SCDN 100 verbunden ist, und zwar unter Verwendung einer beliebigen Content Publishing und Management Software, die auf dem Client-System des Inhalteeigentümers (CPC) 130 ausgeführt wird. Der Inhalteeigentümer konfiguriert die Verteilungskriterien mit dem VFCS 470 oder lädt die Verteilungskriterien auf den CMS 170. Das VFCS 470 oder der Content Management Server 170 analysiert, wie dies vorstehend im Text bereits beschrieben worden ist, das Dateisystemobjekt und unterteilt eine Datei (wenn das Objekt eine Datei ist), so dass Metadaten erzeugt werden. Für den Fall eines CMS 170 wird das Dateisystemobjekt zuerst analysiert und zerlegt, wenn es sich bei dem Objekt um eine Datei handelt, um die Spurdateien zu bestimmen, und der CMS gibt einen Befehl aus, der dem FDP-Befehl "put" ähnlich ist, um Metadaten und Inhalte hochzuladen, oder er aktualisiert den in dem Knoten B angeordneten Verteilungsserver. In anderen Ausführungsbeispielen kann der CMS 170 mit jedem Knoten des SCDN 100 verbunden werden. An dem Knoten B aktualisiert der DS die Metadateisystemstruktur entsprechend und speichert ferner die relevante Metadatendatei. Für den Fall, dass es sich bei dem Objekt um eine Datei handelt, unterteilt der DS das Dateiobjekt zur lokalen Speicherung in Blockdateien. Für den Fall, dass das Dateisystemobjekt durch VFCS eingeführt wird, analysiert VFCS das Objekt, so dass Metadaten erzeugt werden. Das VFCS aktualisiert die Metadateisystemarchitektur und speichert die relevanten Metadaten. Wenn es sich bei dem Objekt um eine Datei handelt, unterteilt das VFCS die Datei in Blöcke und speichert diese Blöcke in dessen mit dem DS in dem Knoten B gemeinsam genutzten Speicher. Bei einem Dateiobjekt ist die ganze Kopie der Datei an dem Knoten B als ein ausgefüllter Punkt dargestellt (11B).
Während die Dateisystemobjektinformationen auf den Verteilungsserver hochgeladen werden, gibt der CMS einen FDP-Befehl vom Typ "distribute" (verteilen) an den Verteilungsserver an dem Knoten B aus. Für den Fall des VFCS, wenn das Dateisystemobjekt in den Speicher geschrieben wird, gibt das VFCS einen FDP-Befehl vom Typ "distribute" (verteilen) an den Verteilungsserver an dem Knoten B aus. Als Reaktion auf den Verteilungsbefehl gibt der DS einen Befehl an dessen benachbarte Knoten A, D und E aus, um die Informationen oder Inhalt zu replizieren (z. B. unter Verwendung des Befehls "replicate" (replizieren) des FDP). Dieser Replikationsbefehl stellt einfach eine Benachrichtigung an die Nachbarn hinsichtlich der Dateisystemobjektänderungen dar. Der Knoten D prüft das Replikationspaket und entscheidet, es soll die Metadaten oder den Inhalt nicht aufweisen, so dass der Replikationsbefehl an dessen Nachbarn, den Knoten H, weitergeleitet wird. Die Knoten A, E und H prüfen das Replikationspaket und entscheiden, dass sie alle den Verteilungskriterien entsprechen (d. h. es handelt sich um "qualifizierte Knoten). Wenn die Bereitschaft gegeben ist, geben die Knoten A, E und H Befehle aus, um die relevanten Metadaten abzurufen, und für das Dateiobjekt einen Abschnitt der Datei von dem am nächsten gelegenen Knoten (z. B. Knoten B) in dem SCDN. Bei den Knoten E und H handelt es sich um Blattknoten, welche somit den Replikationsbefehl nicht ausbreiten. Der Knoten A stellt jedoch den Wurzeknoten mit den Tochterknoten B und C dar. Der Knoten A sendet den Befehl "replizieren" unter Umständen nicht an den Knoten B zurück, da er den Ursprungsknoten darstellt. Der Knoten A kann jedoch auch die Replikationsanforderung an den Knoten C senden. Der Knoten C prüft die Verteilungskriterien und entscheidet, dass es sich um einen qualifizierten Knoten handelt, so dass der Knoten die relevanten Metainformationen bzw. Metadaten abruft, und bei einer Datei einen Abschnit der Datei von den am nächsten gelegenen Knoten (z. B. dem bzw. den nächsten der Knoten A, B, E und H), welche die benötigten Daten aufweisen. Der Knoten C sendet in der Folge den Replikationsbefehl an die Knoten F und G. Der Knoten F ist qualifiziert und ruft somit die Metainformationen ab und bei einer Datei einen Abschnitt der Datei von dem am nächsten gelegenen Knoten mit den Daten (z. B. Knoten B oder C). Die Knoten G und I sind nicht qualifiziert und empfangen somit nichts. Der Knoten G ist ein abschließender Knoten, da das aufgerollte Attribut dessen Zweigs die Verteilungskriterien nicht erfüllt.
Dieser anfängliche Replikationsprozess dauert an, bis alle qualifizierten Knoten in dem SCDN zumindest teilweise belegt sind. Wenn die qualifizierten Knoten Metadaten abrufen oder einen gewissen Abschnitt einer Datei, so modifizieren sie die Metadateisystemstruktur entsprechend, speichern die Metadaten und bei einem Dateiobjekt speichern den Datenblock und modifizieren die Blockindexanordnung entsprechend. In einem oder mehreren Ausführungsbeispielen der Verteilung einer Datei, siehe 11B, befindet sich der gleiche Abschnitt (z. B. Blöcke) der Datei in mindestens einem Knoten des SCDN. Vorzugsweise verwaltet eine Mehrzahl von Knoten den gleichen Abschnitt, wodurch Redundanz erzeugt und der Verlust von etwaigen Abschnitten der Datei vermieden wird, wenn ein oder mehrere Knoten oder Speicherdatenträger nicht mehr verfügbar sind (d. h. verloren gehen), wobei ein DS an dieser Station keine besondere Maßnahmen ergreifen muss, um den Inhalt des beschädigten Datenträgers wiederherzustellen, da die Abschnitte der in bzw. auf diesem Datenträger gespeicherten und später verlorenen Dateien automatisch von anderen Netzwerkknoten heruntergeladen werden, wenn die Nachfrage für die Bearbeitung bzw. Behandlung einer Benutzeranforderung gegeben ist, wobei dies als selbstheilende Fähigkeit des SCDN bezeichnet wird. Die Verteilungsserver leiten ferner Steuerungsinformationen einer fehlerhaften Station an Nachbarn der fehlerhaften Station weiter, um einen fehlerhaften Abbruch von Steuerbefehlen zu vermeiden. Für den Fall, dass ein neues Verzeichnis oder ein neuer Datenträger erzeugt oder modifiziert wird, wird der gleiche Replikationsbefehl an das ganze SCDN auf die gleiche Art und Weise ausgebreitet wie ein Replikationsbefehl für eine Datei ausgebreitet wird. Wenn die Knoten einen Replikationsbefehl für ein Verzeichnis empfangen oder sich der Datenträger ändert, so gibt der DS in den Knoten einen Befehl wie etwa den FDP-Befehl "get" aus, um die verwandten bzw. zugeordneten Dateisystemobjektmetadaten von den am nächsten liegenden Knoten herunterzuladen. Sobald der DS die Dateisystemobjektinformationen empfängt, erzeugt er oder verändert er die lokale Metadateisystemstruktur und aktualisiert die zugeordneten Metadaten.
Der FDP-Befehl "info" wird zur Benachrichtigung verwendet, wenn sich Attribute eines Dateisystemobjekts ändern. Ein Attribut eines Dateisystemobjekts umfasst den Objektnamen, Daten, Angaben zum Eigentümer, die Position des Objekts in der Dateisystemhierarchie, etc. Der FDP-Befehl "clean" wird zur Benachrichtigung aller Knoten in dem SCDN hinsichtlich der Löschung eines Dateisystemobjekts verwendet. Diese Benachrichtigungen werden auf die gleiche Art und Weise verbreitet, wie der FDP-Befehl "replicate" gemäß der Beschreibung in dem vorstehenden Absatz.
Bei normalem Betrieb sendet ein Verteilungsserver FDP-Befehle, wie zum Beispiel "replicate", "info", "search" und "clean", die an das ganze Netzwerk oder einen Teil des Netzwerks weitergeleitet werden, über andere Verteilungsserver in den unmittelbaren Nachbarstationen in dessen Steuerpfad. Wenn zum Beispiel ein Verteilungsserver einen FDP-Befehl empfängt, wie zum Beispiel "replicate" oder "info", so sendet er den Befehl an dessen benachbarte DS auf der Basis der FDP-Verteilungskriterien. In dem Fall, dass eine der Nachbarstationen ausfällt, behält der DS den Auftrag in dessen Auftragswarteschlange und ruft wiederholt ab, bis der Auftrag erfolgreich ausgeführt worden ist. Gleichzeitig nimmt der DS vorübergehend die Rolle des DS in der ausgefallenen bzw. fehlerhaften Station ein, indem der FDP-Befehl an die benachbarten DS der fehlerhaften Station weitergeleitet wird.
Dieses File Distribution Protocol (FDP) gemäß der vorliegenden Erfindung verwendet die Verteilungskriterien des Eigentümers der Inhalte, um die Verteilung des Dateisystemobjekts, wobei die Verteilung bei einer Datei ganz oder teilweise erfolgen kann, an alle Knoten in dem Netzwerk vorzugeben, welche die Verteilungskriterien des Eigentümers erfüllen. Eine Verteilungsanforderung kann von jedem Knoten in dem Baum beginnen und verläuft den Baum nach oben und nach unten, bis sie einen Blattknoten oder einen abschließenden Knoten erreicht. Für jeden Knoten mit den entsprechenden Attributen wird die Datei teilweise von den am nächsten gelegenen Nachbarn heruntergeladen, welche die spezifischen Leistungskriterien erfüllen, wenn diese Nachbarn den zu herunterladenden Abschnitt der Datei aufweisen. Der am nächsten gelegene Nachbar beim Herunterladen von Inhalten ist nicht unbedingt in dem virtuellen Baum der nächst gelegene Nachbar, sondern der nächste in Bezug auf die Entfernung. Dies verhindert massive Übertragungen von dem Knoten, an dem die Datei ursprünglich hochgeladen wird. Ferner verhindert das Staging der Verteilung übermäßige Nachfragen bzw. Anfragen im Netzwerk um den ursprünglichen Knoten (z. B. den Knoten B). Durch das Zustellen kleinerer Blöcke und nur einer teilweisen Datei, reduziert dieses Zustellungsverfahren die Netzwerkbelastung. Da ferner das Fortschreiten der Verteilungsanforderungen durch das SCDN angehalten wird bzw. anhält, wenn sie an einen "abschließenden" Knoten erreichen, verhindert die vorliegende Erfindung es, dass unnötige Verteilungsanforderungspakete das Netzwerk fluten bzw. überschwemmen.
d. Hinzufügen von Datenträgern, Verzeichnissen und Dateien
Neue Datenträger, Verzeichnisse und Dateien können an jedem Knoten hinzugefügt werden. Änderungen der Datenträger, Verzeichnisse und Dateien können ebenfalls an jedem Knoten vorgenommen werden. Die Abbildung aus 11C zeigt ein Beispiel dafür, wie die Verteilungsserver an den entsprechenden Knoten 1 bis 4 zusammen arbeiten, um Metainformationen und Inhalte dynamisch zu verteilen und zu replizieren, so dass jeder Server eine globale Dateisystemansicht darstellt, bei der es sich um eine aggregierte Ansicht des ganzen Netzwerks handelt. Durch die Verteilung, Synchronisierung und Replikation aggregieren die SCDN-Knoten die Speichervorrichtungen in dem Netzwerk, so dass diese als eine arbeiten bzw. funktionieren.
In dem in der Abbildung aus 11C dargestellten Beispiel wird angenommen, dass die Knoten 1 bis 4 alle in der gleichen Verteilungskarte angeordnet sind. Ein Ordner mit der Bezeichnung "dir1" und dessen Dateien werden an dem Knoten 1 in das SCDN 100 eingegeben, wie dies durch den Pfeil in den Knoten 1 dargestellt ist. Der Knoten 1 speichert den Ordner "dir1" in einem Pfad "root" (Wurzel). In ähnlicher Weise werden die Ordner "dir2", "dir3" und "dir4" und deren Dateien in das SCDN 100 an den entsprechenden Knoten 2 bis 4 eingegeben, wie dies durch die Pfeile in die Knoten 2 bis 4 dargestellt ist. Die Knoten 2 bis 4 speichern jeweils die entsprechenden Ordner "dir2", "dir3" und "dir4" in dem Pfad "root". Jede Art von Datei(en) kann in den Ordnern enthalten sein.
Die virtuellen Dateisteuersysteme an den Knoten 1 bis 4 arbeiten gemäß der Beschreibung hierin im Einklang mit der vorliegenden Erfindung zusammen, um Metainformationen und Inhalt dynamisch zu verteilen und zu replizieren, so dass jedes der virtuellen Dateisteuersysteme eine globale Dateisystemansicht darstellt, die eine aggregierte Ansicht des ganzen Netzwerks darstellt. Die Knoten 1 bis 4 weisen jeweils die gleichen Metadaten nach der Replikation auf. Dies ermöglicht es, dass jedes virtuelle Dateisteuersystem an den Knoten 1 bis 4 die gleiche globale Dateisystemansicht des Inhalts aller Knoten 1 bis 4 darstellt, unabhängig davon, welche Ordner tatsächlich in einem bestimmten Knoten gespeichert sind. Die Abbildung aus 11C zeigt ferner durch Pfeile, welche aus jedem der Knoten 1 bis 4 weg zeigen, die gleiche globale Dateisystemansicht, die durch jedes Knoten-VFCS dargestellt wird:
"/root/dir1
/dir2
/dir3
/dir4."
C. Inhalte bereitstellen (Serving Content)
Das Bereitstellen von Inhalten bzw. Content Serving wird über ein VFCS 470 in jedem Knoten bereitgestellt. Das Content Serving umfasst das Erzeugen einer Verzeichnisdarstellung eines globalen Dateisystems und die Rekonstruktion und das Serving von Daten des Dateisystemobjekts über eine Dateisystemschnittstelle des VFCS in Echtzeit. Die globale Dateisystemdarstellung wird aus der Metadateisystemstruktur und den Dateisystemobjektmetadaten erzeugt. Das durch das VFCS 470 dargestellte globale Dateisystem stellt den Inhalt des gesamten SCDN Content-Netzwerks dar. Diese Dateisystemdarstellung lässt sich nicht eins zu eins in die Daten in den lokalen Speichervorrichtungen abbilden. Die Dateisystemdarstellung ist getrennt von den tatsächlichen Daten. Die Metadateisystemstruktur stellt die Struktur des ganzen globalen Verzeichnisses in dem SCDN 100 (oder einfach "SCDN") dar, während die Dateisystemobjektmetadaten die Informationen führen, um ein Dateisystemobjekt zu konstruieren, wie zum Beispiel die Zugriffssteuerungsliste eines Datenträgers, die Erstellungs- und Modifikationsdaten eines Datenträgers oder eines Verzeichnisses, die Popularität einer Datei, die eindeutige ID bzw. Kennung des ganzen Dateisystemobjekts und die Informationen für die Rekonstruktion einer Datei aus den Blockdateien, etc. Es ist eine Schicht, welche die Dateisystemdarstellung und die tatsächlichen Daten verbindet, die in Speichervorrichtungen gespeichert sind. Die Dateimetadaten ermöglichen das Speichern von Blockdateien einer Datei in mehreren verteilten Speichervorrichtungen, und sie ermöglichen es ferner, dass Blockdateien verfolgt bzw. überwacht, aktualisiert und über ein Netzwerk von Knoten verteilt werden.
1. Metadateisystemstruktur und Dateisystemobjektmetadaten
In Bezug auf ein ganzes Dateisystem, das erzeugt wird durch die Integration aller Knoten eines SCDN 100, ist das VFCS 470 für zwei Aspekte zuständig: (a) es stellt eine Dateisystemschnittstelle für den Zugriff von Dateisystemobjekten bereit – Datenträger, Verzeichnisse, Dateien und deren Metadaten; und (b) in Bezug auf Dateien stellt es eine Abstraktion bereit, welche eine Gruppe von Blockdateien aus dem lokalen, zugrunde liegenden Dateisystem einem intakten Dateisystem zuordnet und diese zusammensetzt (in Echtzeit), das von jedem der Knoten dem SCDN zugeführt werden kann. Um dies zu implementieren hat das SCDN eine Metadateisystemstruktur und ein Dateisystemobjektmetadatenformat für die Konstruktion der globalen Dateisystemdarstellung durch ein VFCS 470 definiert. Das VFCS 470 und der DS sind zuständig bzw. verantwortlich für die Verwaltung der Metadateisystemstruktur und der Metadatendateien, wenn neue Objekte hinzugefügt, bestehende Objekte modifiziert und gelöscht werden. Und der DS ist zuständig für die Ausbreitung der Änderungen durch das ganze SCDN. In Bezug auf Dateiobjekte weist ein Teil ihrer Metadaten eine lokale Blockindexanordnung auf. Die Blockindexanordnung jeder Datei ist an verschiedenen Knoten nicht identisch. Die Blockindexanordnung stellt einem VFCS 470 die Informationen darüber bereit, wie eine Gruppe von Blockdateien angeordnet werden kann, um die ursprüngliche Datei wiederherzustellen, wobei sie einem VFCS 470 ferner anzeigt, ob sich ein Block in dem lokalen Knoten befindet oder nicht, und wenn dies der Fall ist, wird der spezifischen Speichervorrichtung angezeigt, wo sich der Block befindet. Die Blockdateien in einem SCDN-Knoten werden in Verzeichnissen mit spezifischen Benennungsmustern gespeichert.
a. Metadateisystemarchitektur
Die Metadateisystemstruktur 1210, die in der Abbildung aus 12A dargestellt ist, stellt ein Beispiel für die Dateisystemhierarchie des globalen Dateisystems gemäß der vorliegenden Erfindung dar. Dieses Verzeichnis existiert in allen Knoten in dem zugrunde liegenden Dateisystem, auf welche die SCDN-Komponenten zugreifen können. Das VFCS 470 verwendet die Metadateisystemstruktur für die Konstruktion der globalen Dateisystemdarstellung. An jedem Knoten gibt es einen Metadaten-Stamm- bzw. Wurzelpfad 1220 – {Metapfad}, wobei in dem {Metapfad} eines oder mehrere Unterverzeichnisse vorhanden sind, die mit einer SCDN-Netzwerk-ID bezeichnet sind. Jedes der Verzeichnisse weist eine Metadateisystemstruktur und Dateisystemobjektmetadaten auf, welche eine globale Dateisystemdarstellung darstellen; wobei jedes SCDN ein globales Dateisystem aufweist.
Jede Metadateisystemstruktur weist eines oder mehrere Datenträger bzw. Volumen (Container) auf, wobei jeder Datenträger ein oder mehrere Verzeichnisse aufweist, wobei jedes Verzeichnis Unterverzeichnisse oder Dateien aufweist. Da es sich bei der Metadateisystemstruktur um kein echtes Dateisystem handelt, weist sie keine tatsächlichen Daten der Dateien auf. In jedem Volumen bzw. Datenträger gibt es eine Datenträgermetadatendatei, die mit {Datenträgername}.vdat bezeichnet ist. In jedem Verzeichnis gibt es eine Verzeichnismetadatendatei, die mit {Verzeichnisname}.ddat bezeichnet ist. Die Dateien befinden sich in der Metadateisystemstruktur und weisen keine echten bzw. realen Daten auf, stattdessen enthalten diese Dateien Dateimetadaten.
Die Metadateisystemstruktur eines SCDN muss nicht an jedem Knoten identisch sein. Die Metadateisystemstruktur eines Knotens stellt die Datenträger, Verzeichnisse und Dateien dar, die an diesen Knoten repliziert werden. Da die Verteilung der Dateisystemobjekte geführt wird durch eine Reihe von Verteilungskriterien, können einige Dateisystemobjekte an bestimmte Knoten repliziert werden und an bestimmte andere Knoten nicht. Somit befindet sich eine Dateisystemobjektdarstellung nicht in der Metadateisystemstruktur eines Knotens, wenn das Objekt nicht an diesen Knoten repliziert wird.
Alle diese Dateisystemobjekte – Datenträger, Verzeichnisse und Dateien – können von jedem der Knoten in dem SCDN erzeugt bzw. erstellt werden. Diese Objekte können durch DS durch einen CMS erstellt werden und sich danach durch das SCDN ausbreiten, wobei sie aber auch durch ein VFCS 470 erzeugt werden und sich durch das SCDN über DS ausbreiten können. Diese Objekte können modifiziert oder gelöscht werden über jeden CMS oder das VFCS 470 von jedem Knoten in Verbindung mit entsprechender Benutzerbefugnis.
b. Datenträger, Verzeichnis und Dateimetadaten
Dateisystemobjektmetadaten unterstützen das VFCS 470 und den DS 410 beim eindeutigen Identifizieren der Objekte, beim Lokalisieren des Ursprungsknotens, beim Lokalisieren der Knoten, die die Objekte aufweisen sowie beim Lokalisieren der Daten in den Speichervorrichtungen in einem Knoten. In einem Ausführungsbeispiel der vorliegenden Erfindung gibt es drei Dateisystemobjektmetadatendateien, nämlich Datenträger (Volume), Verzeichnis (Directory) und Datei (File). Die Metadatendateien befinden sich in der Metadateisystemstruktur, siehe 12A. Die Abbildungen der 13A–D zeigen den Inhalt von Datenträger-, Verzeichnis- und Dateimetadaten eines Ausführungsbeispiels der vorliegenden Erfindung. Im Besonderen zeigt die Abbildung aus 13A den Inhalt einer beispielhaften Datenträgermetadatendatei 1300 (auch als Datenträgermetadatenobjekt bezeichnet). Die Abbildung aus 13B zeigt den Inhalt einer beispielhaften Verzeichnismetadatendatei 1310 1300 (auch als Verzeichnismetadatenobjekt bezeichnet). Die Abbildung aus 13C zeigt den Inhalt von beispielhaften Dateimetadaten 1320 (auch als Dateimetaobjekt bezeichnet). Die Abbildung aus 13D zeigt den Inhalt einer beispielhaften Blockindexanordnung 1330, die Teil beispielhafter Dateimetadaten 1320 ist. Hiermit wird festgestellt, dass die Datenträgermetadaten, die Verzeichnismetadaten und die Dateimetadaten (mit Ausnahme der Blockindexanordnung(en)) nach Replikation an jedem Knoten (zum Beispiel an jedem Server) alle gleich sind. Die Blockindexanordnung kann sich an jedem Knoten unterscheiden, abhängig von dem jeweiligen Zustand des Speichers an dem entsprechenden Knoten.
In einem SCDN (identifiziert durch eine eindeutige Netzwerk-ID) werden die Dateisystemdatenträger (Container) eindeutig identifiziert durch ihre Datenträger-ID und die Ursprungsknoten-ID, sie die Datenträgermetadatendatei 1300 aus 13A. Jedes Volumen bzw. jeder Datenträger weist einen Ursprungsknoten (Ursprungsknoten-ID) auf, wo es bzw. er erstellt bzw. erzeugt wird, sowie einen Content Owner bzw. Inhalteeigentümer (Eigentümer-ID), der den Datenträger erstellt hat. Ein Datenträger weist ferner eine Zugriffssteuerliste (Access Control List) auf, welche eine Liste von Benutzerberechtigungen aufweist. Eine Datenträgermetadatendatei weist ferner eine Verteilungskarte bzw. Verteilungsabbildung auf, welche den Knoten anzeigt, wo das Volumen verteilt wird. Eine identische Datenträgermetadatendatei für den Datenträger befindet sich an allen Knoten, wo der Datenträger repliziert wird. Benutzer können Datenträger von jedem VFCS 470 an jedem Knoten aktualisieren; die neuen und aktualisierten Datenträgermetadaten werden unter Verwendung des FDP in dem gesamten Netzwerk repliziert.
Verzeichnisse in einem SCDN werden eindeutig identifiziert durch deren Verzeichnis-ID und deren Ursprungsknoten, andere Bezeichner, die einem Verzeichnis zugeordnet sind, sind deren Datenträger-ID und Netzwerk-ID, siehe Verzeichnis 1310 aus der Abbildung aus 13B. Wie ein Datenträger weist auch ein Verzeichnis einen Ursprungsknoten, eine Verteilungskarte und ihre eigene Zugriffssteuerungsliste auf. Ein Verzeichnis kann die Zugriffssteuerungsliste von ihrem Datenträger erben bzw. übernehmen. Die Verteilungskarte zeigt den Knoten an, wo das Verzeichnis verteilt wird. In den Knoten, wo das Verzeichnis repliziert wird, wird ein Verzeichnis mit dem gleichen Namen dieses Verzeichnisses in der Metadateisystemstruktur erstellt, und die Verzeichnismetadaten sind in dem Verzeichnis eingebettet. Die Verzeichnismetadatendateien des gleichen Verzeichnisses an allen Knoten, wo das Verzeichnis repliziert wird, sind identisch. Ebenso wie bei den Datenträgern werden Verzeichnisinformationen unter Verwendung des FDP repliziert.
Dateien werden eindeutig identifiziert durch ihre Datei-ID und ihre Ursprungsknoten-ID, wobei zu den anderen Bezeichnern, die einer Datei zugeordnet sind, deren Verzeichnis-ID, deren Datenträger-ID und deren Netzwerk-ID zählen, siehe Datei 1320 aus der Abbildung aus 13C. Wie bei Datenträgern und Verzeichnissen weist eine Datei einen Ursprungsknoten und eine Verteilungskarte auf, obgleich die Datei an einem VFCS 470 jedes Knotens aktualisiert werden kann. Wenn eine Datei aktualisiert wird, werden Abschnitte des Inhalts und die Dateimetadaten repliziert. Die Datei-ID in den Metadaten ermöglicht es, dass eine Datei eindeutig in dem ganzen Netzwerk identifiziert werden kann; die Verteilungskarte zeigt an, wo die Datei repliziert wird; und die Blockindexanordnung (13D), die teil der Dateimetadaten ist, weist Informationen zu dem Layout der Blockdateien auf, so dass der DS weiß, wie die Blöcke zu verteilen sind für einen beschleunigten Transport, und das VFCS 470 weist, wie die Datei in Echtzeit zusammengesetzt werden sollen. Die Metadatendatei einer Datei existiert in allen Knoten, in denen die Datei repliziert wird. Neben der Blockindexanordnung ist der sonstige Teil bzw. Abschnitt der Metadaten in allen Knoten identisch. Der Inhalt der Blockindexanordnung ist an den verschiedenen Knoten unterschiedlich.
Die Abbildung aus 13D zeigt ein Beispiel für die Blockindexanordnung 1330 gemäß der vorliegenden Erfindung. In dem vorliegenden Beispiel weist die Datei drei Segmente auf, wobei das Segment 1332 fünf Datenblöcke aufweist, wobei das Segment 1334 zehn Blöcke aufweist, und wobei das Segment 1336 vier Datenblöcke aufweist. Die Sequenz der gesamten Datei beginnt mit Block #1 von Segment 1332 zu Block #5 von Segment 1332, gefolgt von Block #1 von Segment 1334 bis hin zu dem Ende des Segments 1334, gefolgt von dem Segment 1334. Diese Sequenz ermöglicht es einem VFCS 470, eine Benutzeranforderung transparent zu erfüllen, wenn auf einen bestimmten Teil der Datei zugegriffen wird. Der Beginn jedes Segments ist von der größten Bedeutung für die Anwendungen dieser Art von Datei. Für gewöhnlich greift eine Anwendung auf die Datei zu, indem die Anfänge aller Segmente gleichzeitig gelesen werden.
Die Segmente sind auch als Spuren bzw. Tracks bekannt. Sie ermöglichen es dem DS den wichtigsten Teil einer Datei zu lokalisieren, um mit der Verteilung zu beginnen, um die Fern- bzw. Weitverkehrszugriffslatenz zu eliminieren (d. h. für einen beschleunigten Transport). Wenn die Anfangsblocks jedes Segments von DS übertragen werden, kann ein VFCS 470 die Daten vollständig über die globale Dateisystemschnittstelle des VFCS 470 darstellen. Ein Endbenutzer greift auf die Datei unter Verwendung einer entsprechenden Anwendung zu, während die DS wieder den Rest der Blockdateien in allen Segmenten füllen. Die Anzahl in allen Blockindexanordnungszellen zeigt einem VFCS 470 an, ob die Blockdatei lokal angeordnet ist, und wenn dies der Fall ist, wo die Datei anzuordnen ist. In dem vorliegenden Beispiel zeigt eine 0 an, dass sich der Block nicht in dem lokalen Speicher befindet. Wenn in diesem Fall ein VFCS 470 auf den Datenblock zugreifen möchte, so kann es einem DS signalisieren, den Block zu downloaden. Bevor ein DS einen nicht residenten Datenblock importieren kann, hat der DS ein FDP-Suchsignal an die Knoten mittels Multicasting übermittelt, wo die Datei repliziert wird (unter Verwendung der Verteilungskarte), um zu lokalisieren, welche Knoten den jeweiligen Datenblock aufweisen. Eine –1 in der Zelle zeigt an, dass ein DS sich im Prozess des Downloadens des Blocks befindet. Die positiven Zahlen in der Zelle zeigen einem VFCS 470 die Speichervorrichtungsnummer an, wo die Blockdaten gespeichert werden.
Die Abbildung aus 12B zeigt ein Beispiel des Ausführungsbeispiels der Metadateisystemstruktur mit Dateiobjektmetadaten in zwei unterschiedlichen SCDN-Verteilungszentren 140A, 140B (auch als Knoten bezeichnet) gemäß der vorliegenden Erfindung. Der Knoten 140A weist Metadateninformationen 1230 auf. Der Knoten 140B weist die Metadateninformationen 1240 auf, wie dies abgebildet ist. Dieses Beispiel zeigt, wie die Datenträgermetadaten, die Verzeichnismetadaten und die Dateimetadaten (mit Ausnahme der Blockindexanordnung(en)) nach der Replikation an jedem Knoten 140A, 140B identisch sind (Ma = Mb, Va = Vb, Da = Db). Die Blockindexanordnung kann sich an jedem Knoten 140A, 140B unterscheiden, abhängig von dem jeweiligen Speicherzustand an dem entsprechenden Knoten (Fa nicht gleich Fb).
c. Blockdateien und Knotenbegrenzungspfad
Im Folgenden wird das Disk-Layout der Blockdateien beschrieben. Hierin werden bestimmte Konventionen für die Beschreibung der Verzeichnispfade verwendet. Die Abbildung aus 12C zeigt ein veranschaulichendes Ausführungsbeispiel des zugrunde liegenden Dateisystem-Blockdateiverzeichnislayouts in einem SCDN-Knoten. Abgebildet ist ein Blockdateipfadname 1250.
Die Gruppe der Blockdateien, welche eine Datei bilden, wird in Speichervorrichtungen gespeichert, wobei der Name der ursprünglichen Datei nicht verwendet wird, jedoch die Dateiobjekt-ID und eine Blocksequenznummer. Diese Blockdateien werden in Blockspeicherpfaden gespeichert, die in einer oder mehreren Speichervorrichtungen definiert sind. Ein Blockspeicherpfad ist ein Blockdateispeicherstammverzeichnis, das Informationen zu der Blockposition bereitstellt. Die einzelnen Blöcke können so gespeichert werden, dass die E/A-Last über mehrere Vorrichtungen verteilt bzw. ausgebreitet wird, um die Platten- bzw. Disk-Leistung zu maximieren. Um dies zu unterstützen, kann der SCDN-Knoten mit mehreren Blockspeicherwurzeln konfiguriert werden. Wenn der DS in jedem Knoten Blöcke speichert, so ruft er eine Funktion auf, um auszuwählen, in welcher Speicherwurzel der Block gespeichert werden soll. In einem Fall führt diese Funktion einfache eine Auswahl der Blockspeicherwurzeln nach dem Reigenmodell (englisch: Round Robin) aus, so dass wenn neue Blöcke geschrieben werden, diese gleichmäßig auf die Speicherwurzeln aufgeteilt werden. In anderen Fällen kann diese Funktion den Speicher optimieren, indem zum Beispiel Plattenspeicherinformationen verwendet und die Last neuer Blöcke auf die Vorrichtungen mit dem meisten freien Platz verteilt werden.
Die separaten Blockspeicherpfade sind durch ihre Indexe identifiziert, die als Speicherindexe bezeichnet werden. Wenn ein Datenblock in einem der Speicherpfade gespeichert wird, wird der Index des Speicherpfads in der Blockindexanordnung in den Metadaten für das Dateiobjekt registriert; somit wird der Speicherindex in jeder Blockindexanordnungszelle dazu verwendet, die Position eines bestimmten Blocks zu beschreiben. Neue Speicherwurzeln können frei hinzugefügt werden, wobei die Indexreihenfolge bestehender Speicherwurzeln jedoch nicht verändert werden darf, auch dürfen die Speicherwurzeln nicht gelöscht werden ohne ein Hilfsprogramm für die neue Indexierung laufen zu lassen, um die Blockindexanordnungsmetadaten mit den neuen Speicherwurzelindexen zu aktualisieren.
Die Speicherindexe liegen im Beeich von 1...n, wobei n die Anzahl der konfigurierten Speicherwurzeln darstellt. Jede Nummer bzw. Zahl wird auf einen Speicherwurzelpfad, eine Textfolge und das Speicherverzeichnis für Blockdateien abgebildet. Ein Speicherindexwert von 0 in der Blockindexanordnungszelle zeigt an, dass der Block nicht vorhanden ist. Ein Speicherindex –1 in den Metadaten zeigt an, dass der Block heruntergeladen wird, wobei der Vorgang jedoch noch nicht abgeschlossen ist.
Zur Unterstützung des Datenaustauschs mit anderen SCDN führen die Daten eine Netzwerk-ID. Ein SCDN-Knoten speichert die Netzwerk-ID in den Daten und verwahrt die Daten jedes Netzwerks getrennt in separaten Unterverzeichnissen. Die Daten von dem "lokalen" SCDN werden mit der lokalen Netzwerk-ID gespeichert, wobei es sich in dem vorliegenden Beispiel bei der lokalen SCDN-ID um die 0 handelt. Daten von externen SCDN werden gemäß den IDs dieser Netzwerke gespeichert. Unter jedem Verzeichnis {Speicherpfad[i]} bzw. {storagepath[i]} weist jedes SCDN ihr eigenes Unterverzeichnis auf. Diese Ebene der Verzeichnisstruktur wird bezeichnet als {Speicherpfad[i-1]}/{Netzwerk_ID}/.
Um es zu verhindern, dass ein bestimmter Plattenverzeichnisknoten mit mehr Konten als den maximalen Unterknoten des zugrunde liegenden Dateisystems überschwemmt wird, womit die resultierende Leistungsverschlechterung einher geht, die eine derartige Wucherung der gängigen Meinung nach verursacht, wird ein Mechanismus verwendet, um die Blockdateien in Unterverzeichnisse auszubreiten. Dieser Mechanismus wird als Knotenbegrenzungspfade (Hode Limiting Paths) bezeichnet, da er Verzeichnispfade erstellt bzw. erzeugt, welche die Anzahl der Knoten in einem einzelnen Verzeichnis auf die maximale Anzahl von Unterknoten begrenzt, die von dem zugrunde liegenden Dateisystem unterstützt wird. In einer regulären bzw. normalen UNIX-Umgebung beträgt die maximale Anzahl von Unterknoten in einem Verzeichnis zum Beispiel etwa 1.000.
Als Beispiel dient eine große Datei. Jede Datei kann zum Beispiel mehrere Segmente/Spuren aufweisen, und jedes Segment kann Tausende von Blöcken aufweisen. Die Blöcke einer Datei können nicht in dem gleichen zugrunde liegenden Verzeichnis gespeichert werden, wenn dieses eine Begrenzung in Bezug auf die Anzahl der Knoten pro Verzeichnis aufweist. Ferner kann ein Inhalteeigentümer Tausende von Dateien aufweisen. Es wird bevorzugt, dass das System nicht alle Blockdateien des Inhalteeigentümers in einem einzigen zugrunde liegenden Verzeichnis speichert. Knotenbegrenzungspfade lösen diese und ähnliche Datei- und Verzeichniswucherungsprobleme auf eine gemeinsame bzw. übliche Art und Weise.
Eine Dateisystemobjekt-ID in einem SCDN ist eine eindeutige 64 Bit ganze Zahl. Für ein Dateiobjekt wird die ID gebildet aus einer 32 Bit Ursprungsknoten-ID und einer 32 Bit Datei-ID. Eine derartige 64-Bit-Zahl weist, wenn sie als ein String bzw. eine Folge dargestellt wird, eine maximale Länge von 20 Stellen auf. Wie dies bereits vorstehend im Text beschrieben worden ist, wird eine Blockdatei unter Verwendung der Dateiobjekt-ID an Stelle des tatsächlichen Dateinamens gespeichert. Ein Beispiel ist eine Datei, deren ID "00000000001234567890" lautet, die drei Segmente aufweist und deren Blockgröße 256 K Bytes entspricht. Die Blockdatei mit der Bezeichnung "00000000001234567890.1.0001.block" bedeutet, dass die Blockdatei den ersten 256 K Byte Datenblock der Datei aufweist, dessen ID an dem Segment 1 gleich "00000000001234567890" lautet. Da es sich dabei um Segmentnummer 1 handelt, bedeutet dies ferner, dass die Blockdatei die ersten 256 K Bytes der ursprünglichen Datei enthält.
Eine Möglichkeit für die Erzeugung eines Knotenbegrenzungspfads für dieses Dateiobjekt ist es, dessen Wert als eine Folge zu verwenden und danach die Folge in eine Verzeichnishistorie aufzuteilen, wobei jedes Unterverzeichnis die nächsten drei Stellen verwendet. Zum Beispiel: Knotebegrenzungspfad = "000/000/000/012/345/678/90/1/0/". In diesem Fall wird die Blockdatei "00000000001234567890.1.0001.block" in dem Verzeichnis "000/000/000/012/345/678/90/1/0//" in dem Blockspeicherpfad gespeichert.
Unabhängig davon, welche wahlfreien IDs es in des System schaffen, es sollten sich nicht mehr als 1.000 Knoten in einem Verzeichnis befinden (die Unterverzeichnisnamen reichen von "000" bis "999"), und dies sicherzustellen umfasst keinerlei Plattenanalyse. Der Knotenbegrenzungspfad wird algorithmisch gebildet.
Eine weitere Möglichkeit, um einen Knotenbegrenzungspfad zu erzeugen, ist das Nutzen der Tatsache, dass die Dateiobjekt-ID keine vollständig wahlfreie Zahl darstellt – es ist lediglich eine eindeutige bzw. einzigartige Zahl für jede Datei, die zum Zeitpunkt der Erstellung erzeugt wird. Sie wird wie folgt erzeugt:
Eindeutige Datei-ID = (ID des Ursprungsknotens) + (eine Folgenummer aus der Datenbank)
Die Folgenummer bzw. Sequenznummer ist eine Zahl, die von 1 beginnt und die von der Datenbank mit jeder Zahl erhöht bzw. heraufgesetzt wird. Die wertniedrigsten Stellen der eindeutigen Datei-ID werden für eine Reigenmodellauswahl unter den Verzeichnissen verwendet.
Zuerst wird der Knotenbegrenzungspfad als "/dir1/dir2/Dateiobjekt-ID/" erstellt, wobei dir1 = "Eindeutige Datei-ID & 1000" und dir2 = "(Eindeutige Datei-ID/1000)% 1000". Das heißt, dir1 stellt die letzten drei Stellen der eindeutigen Datei-ID dar, und dir2 stellt die drei Stellen vor den letzten drei Stellen der eindeutigen Datei-ID dar.
Ein Knotenbegrenzungspfad für eine ID "id" wird als {Knotenbegrenzungspfad-(ID)} bezeichnet. Zurück zu dem Beispiel aus der Abbildung aus 12B, in dem es zwei Speichervorrichtungen oder Blockspeicherpfade gibt, nämlich "BlockRoot1/" und "/BlockRoot2", und wobei die SCDN-ID gleich 0 ist. Die Datei, deren ID "00000000001234567890" lautet, wird in dem Speicher gespeichert, wobei das Beispiel die ersten sechs Datenblöcke des ersten Segments zeigt. Die Blockindexanordnungszellen der ersten sechs Blöcke des ersten Segments zeigen, dass der erste Block in dem Blockspeicherpfad 1 ("BlockRoot1/") gespeichert wird, und wobei der zweite Block in dem Blockspeicherpfad 2 ("BlockRoot2/") gespeichert wird, etc.
Die Blockindexierung ermöglicht es nicht nur, dass Datenblöcke einer Datei in mehreren Speichervorrichtungen gespeichert werden, um die E/A-Bandbreite zu erhöhen, sie ermöglicht es auch, dass Datenblöcke parallel importiert oder exportiert werden, anstatt in einer zusammenhängenden Folge bzw. Sequenz. Die Chunking- bzw. Zerteilungsverfahren und die Metadaten ermöglichen es gemeinsam, dass im Inneren des SCDN eine Datei dynamisch wie ein Fluid und nicht wie ein starrer Körper behandelt wird. Das Blockindexierungsverfahren verhindert es, dass verschiedene DS-Threads den gleichen Datenblock gleichzeitig importieren; die Methode stellt ferner einen schnellen Datenzugriff auf das VFCS 470 während dem Prozess des Wiederzusammensetzens bereit. Durch das Entfernen der herkömmlichen Anforderung zum Speichern einer ganzen Datei in einer einzigen Speichervorrichtung, können jedem Knoten des SCDN zu jedem Zeitpunkt neue Speichervorrichtungen hinzugefügt werden, um Dateien zu verschieben. Da das SCDN als ein globales Dateisystem eines Wide Area Netzwerks fungieren kann, kann es gewaltige Datenmengen aufweisen, wobei die Speicherkapazität in einem VFCS 470 Server unter Umständen nicht ausreicht, um die vollständige Darstellung des Dateisystems zu cachen. Die Metadateisystemstruktur wird somit eingeführt, um die Objektmetadaten und Datenblöcke in eine globale Dateisystemverzeichnisstruktur abzubilden, wobei es dies dem VFCS Vnode ermöglicht, nur eine teilweise Darstellung zu erzeugen, während sich auf die Metadateisystemstruktur verlassen wird hinsichtlich des fehlenden Abschnitts bzw. Teils der Darstellung. Wenn dies erforderlich ist, kann der fehlende Teil der Darstellung zeitnah in den VFCS Vnode verschoben werden.
1. Zugriff auf ein Dateisystemobjekt
Sobald die Metadateisystemstruktur und die Objektmetadatendateien verfügbar sind, kann ein VFCS 470 diese Informationen verwenden, um eine globale Dateisystemdarstellung zu erzeugen und danach die Dateisystemanforderung für Datenträger-, Verzeichnis- und Dateiinformationen zu bedienen. Da alle Datenträger- und Verzeichnisinformationen leicht sind und in den Datenträger- und Verzeichnismetadatendateien gespeichert werden, ist das Bereitstellen der Datenträger- und Verzeichnisinformationen geradlinig. Dateiobjekte werden allerdings nicht nur in Blockdateien unterteilt, es ist ferner nicht erforderlich, dass sich alle Blockdateien für ein Dateiobjekt in dem lokalen Speicher befinden. In dem folgenden Abschnitt wird ein Ausführungsbeispiel der vorliegenden Erfindung eines Verfahrens zur Bereitstellung bzw. Serving eines Dateiobjekts und zum Importieren nicht residenter Abschnitte der Datei beschrieben.
a. Rekonstruktion einer Datei aus Blockdateien
Die Abbildung aus 14A zeigt ein Diagramm eines Prozesses 1400 der Rekonstruktion einer Datei aus mehreren Blockdateien 1401 durch das VFCS 470. Die Blockdateien 1400 werden in einen Prozess des Zusammensetzens 1410 eingegeben. Der Umkehrprozess des Blockierens wird als "Zusammensetzen" (Assembling) bezeichnet, wie dies bereits vorstehend im Text beschrieben worden ist. Das Virtual File Control System (VFCS 470) verwendet den Prozess des Zusammensetzens 1410, um mehrere Blockdateien in lineare Segment-/Spurdateien umzuwandeln. Der Prozess des Zusammensetzens 1410 erzeugt nur eine lineare Segment-/Spurdatei (z. B. die lineare Datei 1450), wenn die ursprüngliche Datei linear ist. Wenn die ursprüngliche Datei jedoch nicht linear ist, erzeugt der Prozess des Zusammensetzens 1410 mehrere lineare Segment-/Spurdateien 1420. Eine lineare Segment-/Spurdatei wird durch die lineare Kombination der entsprechenden Blockdateien erzeugt. Zum Beispiel wird die Videospurdatei aus der Abbildung aus 10A neu erzeugt durch lineare Kombination (d. h. Summieren) der Blockdateien V1, V2, V3 und V4. Lineare Spurdateien 1420 können ferner in dem Prozess des Multiplexierens 1430 kombiniert werden, um die nicht lineare ursprüngliche Datei 1440 zu erzeugen. Der Multiplexing-Prozess setzt die Spurdateien einfach neu zusammen, so dass die ursprüngliche nicht lineare Datei erzeugt wird. Dateien werden direkt "on the fly" wieder zusammengesetzt als Reaktion auf eine Anforderung eines Benutzers für den Zugriff auf die Datei. Es wird keine zusätzliche Kopie der Datei erzeugt.
Die Abbildung aus 14B veranschaulicht ein Ausführungsbeispiel der vorliegenden Erfindung in der Situation, wenn Dateiobjekte regelmäßig aufgeteilt werden (d. h. die Blockgröße aller Blöcke mit Ausnahme des letzten Blocks ist identisch), und das VFCS 470 bedient wahlfreie Dateisystemanforderungen. Die Abbildung aus 14B zeigt ein Flussdiagramm eines Algorithmus 1460 zur Lokalisierung von Daten in dem Prozess des Wiederzusammensetzens einer Datei in Echtzeit (Schritte 1462–1466). So kann zum Beispiel eine Dateisystemanforderung verarbeitet werden, bei der es sich um eine Leseanforderung handelt. In dem Schritt 1462 kann diese Anforderung wie folgt lauten: Anzahl X Bytes aus Y-Versatz von Datei Z lesen (wobei Z eine Dateikennung ist, während Y den Versatz bezeichnet und X für die Anzahl der Bytes angibt, die beginnend bei dem Versatz gelesen werden sollen. Das VFCS 470 empfängt die Dateisystemanforderung (Schritt 1464). Da das VFCS 470 die eindeutige Datei-ID als Kennung verwendet, ist die Datei-ID bekannt. Das VFCS 470 kann das erste Byte der Daten in einem Block B mit diesem Ansatz 1164 lokalisieren:
Setzen eindeutige Datei-ID = U = Dateikennung Z
Setzen Blockanzahl der Datei = B = ((Y% Blockgröße) + 1)
Setzen Versatz in Block B = F = (Y/Blockgröße)
Setzen Segment, das Block B = M = Funktion aufweist, die B auf das Segment Func(Segmentanordnung von U, B) abbilden
Setzen Blockanzahl von Block B innerhalb von Segment M = N
Setzen Blockindexanordnungszellen für B = C
Setzen Wert von C = Val(C), der den Blockspeicherpfadindex darstellt.
Der Pfadnahme der Blockdatei, der den Anfang der angeforderten Daten aufweist, lautet dabei:
/Blockpfad(Val(C)/SCDN ID/Knotenbegrenzungspfad(U.M.N).block
Bei diesem Pfadnamen öffnet das VFCS 470 die Blockdatei, sucht eine Anzahl von F Bytes und liest die Anzahl X von Bytes. Wenn der Block B nicht die ganze Anzahl von Bytes aufweist, kann das VFCS 470 mit dem nächsten Block für die verbliebenen Daten fortfachen.
b. Dateizugriff
Ein Endbenutzer kann einen Zugriff auf ein Dateiverzeichnis über eine VFCS 470 Dateisystemschnittstelle oder über eine Anwendungsschnittstelle, wie zum Beispiel einen Web-Browser, an dm Client-System des Endbenutzers anfordern. Wenn ein Endbenutzer durch einen Anwendungsserver bedient wird, wird die Anforderung weitergeleitet an einen entsprechenden Anwendungsserver (d. h. einen Server, der sich näher an dem Endbenutzer befindet, und mit einer Bandbreite zur Bearbeitung der Anforderung), der die Datei an den Endbenutzer bereitstellt, wie zum Beispiel ein Streaming Server für die Zustellung großer Videodateien, oder ein FTP-Server, der in der Lage ist das VFCS 470 als dessen entferntes Dateisystem anzunehmen, um Zugriff auf den Inhalt in dem SCDN zu haben. Der Anwendungsserver befindet sich in dem Netzwerk und kann somit mit dem am nächsten gelegenen Knoten des SCDN verbunden werden. Die Speicherdatenträger des SCDN-Knotens (d. h. Cache-Speicher) können einige, keine oder alle der Blöcke der angeforderten Datei des Endbenutzers aufweisen. Wenn entweder zusätzlicher Inhalt oder der ganze Inhalt der Datei benötigt wird, kommuniziert das VFCS 470 (über FDP "prepare") mit einem lokalen DS, so dass eine FDP-Anforderung "search" an alle Nachbarn des DS ausgegeben wird, um die benötigten (nicht residenten) Abschnitte der Datei zu lokalisieren. Der Befehl "search" wird mittels Multicasting-Methode verteilt.
Zum Beispiel wird davon ausgegangen, dass die angeforderte Datei eine Länge von 10 GB aufweist, was insgesamt 20 Blöcken eines Speichers von 500 MB entspricht (d. h., wenn jeder Block gleich 500 MB ist). Ferner wird angenommen, dass sich nur sechs derartige Blöcke von 500 MB lokal in dem SCDN-Knoten befinden. Auch wenn nur 3 GB der angeforderten Datei tatsächlich in dem Speichersystem des SCDN-Knotens gespeichert werden, "scheint es" für den Endbenutzer oder den Anwendungsserver über das VFCS 470 als würde sich die ganze Datei lokal befinden. Auf Anforderung durch das VFCS 470 werden die nicht residenten Abschnitte der Datei von verschiedenen Verteilungsservern in dem SCDN gleichzeitig nicht zusammenhängend gezogen und lokal gespeichert als Blöcke in dem gemeinsam genutzten Speicher (z. B. lokale Speichervorrichtungen). Das VFCS 470 setzt die gespeicherten Blockdateien in Echtzeit zusammen und multiplexiert diese, um die Anforderungen von dem Anwendungsserver oder Endbenutzern zu erfüllen.
Zum Lokalisieren der nicht residenten Abschnitte der Datei gibt ein DS in einem Cluster von DS eine Suchanforderung aus, welche den SCDN-Baum beginnend von den jeweiligen Nachbarknoten durchläuft. Die Suchanforderung kann die Verteilungskriterien der angeforderten Datei und einen Zähler für die Zeit bis zur Aktivierung aufweisen (Time-to-Live-Zähler). Ein Time-to-Live-Zähler kann zum Beispiel spezifizieren, dass die Suchanforderung nur zwei Hubs des SCDN von dem anfordernden Knoten durchlaufen bzw. passieren muss. Wenn ein Nachbarknoten die Suchanforderung empfängt und evaluiert, kann der Knoten den Zähler zum Beispiel herabsetzen. Eine Suchanforderung endet, sie auf einen Blattknoten, einen "abschließenden" Knoten trifft oder wenn der Time-to-Live-Zähler auf Null steht (d. h. wenn die Suchanforderung einen Zähler aufweist). Wenn die fehlenden Daten nicht lokalisiert werden und der Time-to-Live-Zähler Null erreicht, d. h. wenn er in der Suchanforderung enthalten ist, durchläuft die Suchanforderung weiter die SCDN-Knoten in dem Umkehrpfad des anfänglichen Verteilungsprozesses. Ein Knoten antwortet direkt auf den anfordernden DS, wenn der angeforderte Teil der Datei in diesem Knoten existiert. Knoten, die keinen Teil der angeforderten Datei aufweisen, antworten nicht. Eine Antwort umfasst auch den Leistungsstatus des Knotens, der die Antwort sendet, und einen Indikator der Abschnitte der verfügbaren Datei. Wenn das anfordernde DS Cluster Antwortpakete von beliebigen Knoten in dem SCDN empfängt, was anzeigt, dass sie einen Teil oder angeforderten Datei oder die ganze angeforderte Datei aufweisen, laden die DS in dem Cluster den fehlenden Inhalt von den Knoten herunter, die am wenigstens Verkehr bzw. Aufkommen aufweisen, und wobei der Inhalt in den gemeinsam genutzten Speichervorrichtungen des Verteilungsservers lokal gespeichert wird. Während das VFCS 470 somit die Daten an den Endbenutzer bereitstellt, erhalten die Verteilungsserver (DS) den Rest der Datei von anderen Knoten, und es gibt keine Unterbrechung der Kommunikation zwischen den Endbenutzern und dem VFCS 470.
Wie dies bereits vorstehend im Text beschrieben worden ist, wird eine Datei in Abschnitte (z. B. Blockdateien) unterteilt bzw. aufgeteilt und über das SCDN verteilt. Wenn somit durch die Suchanforderung Knoten gefunden werden, welche Abschnitte der Datei aufweisen, kann ein Cluster von DS Abschnitte dieser Datei parallel von mehreren Knoten herunterladen, im Besonderen von den Knoten, die gegenwärtig am wenigsten verstopft sind bzw. am wenigsten Verkehr aufweisen. Das einleitende DS Cluster entscheidet auf der Basis der Leistungsinformationen in den Antwortpaketen, wo der fehlende Inhalt heruntergeladen werden soll (d. h. "pull"), um die Latenz- und Bandbreitenanforderungen an anderen Verteilungsserver-Knoten zu minimieren. Wenn mehre DS-Threads oder Prozesse verschiedene Abschnitte einer Datei gleichzeitig herunterladen, werden die DS-Threads und Prozesse mit einem Sequenz- oder Folgeserver kombiniert, so dass nicht mehr als ein Thread oder Prozess den gleichen Datenblock herunterladen.
Nachdem die Datenblöcke von den entsprechenden Verteilungsservern gezogen worden sind, setzt ein VFCS 470 oder ein Cluster von VFCS 470 die angeforderten Daten für eine Datei aus den Datenblöcken in Echtzeit für den Endbenutzer zusammen. Das VFCS 470 ermöglicht es den Anwendungsservern oder Endbenutzern das verteilte Dateisystem anzuzeigen, das in dem ganzen SCDN existiert, und zwar als ein einziges großes virtuelles Dateisystem.
c. Abrufen von nicht zusammenhängenden Dateisegmenten
Aus einer Perspektive entspricht jeder gespeicherte Block in dem Systemspeicher eines SCDN-Knotens einem zusammenhängenden Abschnitt einer Datei (z. B. ein zusammenhängendes Intervall eines Films, wenn es sich um eine Videodatei handelt). Da die Datei in Blöcke unterteilt ist, können all diese Blöcke unabhängig voneinander gespeichert oder neu angeordnet werden. Als Beispiel dient eine Videodatei, bei welcher der Abschnitt einen Film umfasst. Wenn eine Betrachtung bzw. Anzeige der einzelnen Abschnitte vom ersten Abschnitt bis zum letzten Abschnitt nacheinander erfolgt, so würde dies dazu führen, dass der ganze Film angezeigt bzw. angesehen wird. Da sich die gleichen Inhaltsabschnitte (d. h. Abschnitt) an mehreren unterschiedlichen Knoten in dem SCDN befinden, kann der nicht zusammenhängende Abschnitt einer Datei (z. B. nicht zusammenhängende Abschnitte eines Films) unabhängig voneinander und parallel abgerufen werden. Dies weist mehrere wichtige Nebenwirkungen auf. Da ein DS zum Beispiel benötigte Inhaltsabschnitte von mehreren unterschiedlichen Verteilungsservern erhalten kann, erhöhen sich die Zuverlässigkeit und die Verfügbarkeit des SCDN erheblich. Darüber hinaus kann der Endbenutzer effizient auf den Abschnitt einer Datei "abweichend von der Reihenfolge" zugreifen, wobei ein Film zum Beispiel schnell vorgespielt bzw. vorgespult werden kann, ohne tatsächlich alle Abschnitte des Films herunterladen zu müssen, die nicht wirklich angezeigt bzw. angesehen werden. Hiermit wird festgestellt, dass ein "Pruning" (Freimachen des Speichers, der von bestimmten Blöcken verwendet wird für eine Verwendung durch andere Blöcke) auf "Blockebene" (im Vergleich zu der ganzen "Dateiebene") auf der Basis bestimmter Richtlinien des Inhalteeigentümers vorgenommen werden kann, wobei das Pruning auf Nutzungsmustern basieren kann. Die Nutzung des Inhalts kann auch auf Blockebene bewertet werden.
3. VFCS
a. Implementierungsoptionen für VFCS
Ein VFCS 470 kann auf eine Reihe unterschiedlicher Art und Weisen implementiert werden. Die Abbildung aus 15A zeigt eine erste optionale Implementierung eines Internet Protocol (IP) Front-End und eines Network Attached Storage (NAS) Back-End. Der bzw. die Anwendungsserver 1502 sind über einen IP-Link 1504 mit einer Station 1500A gekoppelt.
Die Station 1500A weist einen Virtual File Control System Cluster 1510, einen Verteilungsserver-Cluster 1520 und eine bzw. mehrere Steuereinheit(en) 1530 auf. Der Virtual File Control System Cluster 1510 weist ein oder mehrere Virtual File Control Systeme auf, die auf einem oder mehreren Servern ausgeführt werden.
Der VFCS Cluster 1510 (und die darin angeordneten Server) kommuniziert mit einer bzw. mehreren Front-End-Anwendung(en) an dem bzw. den Anwendungsserver(n) 1502 unter Verwendung von TCP/IP oder UDP/IP Kommunikation über den Link bzw. Übermittlungsabschnitt 1504 und mit einer oder mehreren Network Attached Speichervorrichtungen bzw. ans Netzwerk angeschlossenen Speichervorrichtungen (NAS 1540) an einem Back-End über den Übermittlungsabschnitt 1544. Der VFCS Cluster 1510 (und jeder Server darin) kommuniziert ebenfalls mit dem Verteilungsserver-Cluster 1520 unter Verwendung von TCP/IP oder UDP/IP Kommunikation über den Übermittlungsabschnitt bzw. den Link 1516 und mit der bzw. den Steuereinheit(en) 1503 über den Übermittlungsabschnitt 1514. Der Verteilungsserver-Cluster 1520 und die Steuereinheit(en) 1503 kommunizieren miteinander unter Verwendung von TCP/IP oder UDP/IP Kommunikation über den Übermittlungsabschnitt bzw. Link 1524. Der Verteilungsserver-Cluster 1520 und die Steuereinheit(en) 1503 kommunizieren ferner direkt mit NAS 1540 unter Verwendung von TCP/IP oder UDP/IP Kommunikation über entsprechende Übermittlungsabschnitte 1526, 1529.
Die Abbildung aus 15B zeigt eine zweite optionale Implementierung einer Station 1500B mit einem IP Front-End und einem Storage Area Network (SAN) Back-End. Der VFCS Server kommuniziert mit der Front-End-Anwendung unter Verwendung von TCP/IP oder UDP/IP Kommunikation sowie mit einem Storage Area Network an dem Back-End. Fibre Channel-Zwischenverbindungen (1552, 1554, 1556, 1558, die durch graue Schattierungen dargestellt sind) werden eingesetzt, um den Virtual File Control System Cluster 1510, den Verteilungsserver-Cluster 1520, die Steuereinheit(en) 1530 und ein Storage Area Network (SAN) oder ein NAS 1545 zu koppeln.
Die Abbildung aus 15C zeigt eine dritte optionale Implementierung einer Station 1500C mit einem integrierten Front-End, SAN oder NAS Back-End. In diesem Fall ist die VFCS Funktionalität 1570 (z. B. ein VFCS-Stapel) direkt in den bzw. die Anwendungsserver 1502 integriert. An dem Back-End kommuniziert ein VFCS mit einem SAN oder einem NAS über einen Hochgeschwindigkeits-Fibre-Channel-Übermittlungsabschnitt 1544.
Die folgende Beschreibung konzentriert sich auf die erste optionale Implementierung der Station 1500A, wobei der Fachmann auf dem Gebiet jedoch erkennt, dass die Konzepte auch auf andere Implementierungen anwendbar sind.
Einer der Schlüsselparameter in einem VFCS 470 ist die globale eindeutige Dateisystemobjekt-ID. Jedes Dateisystemobjekt, unabhängig davon, von welchem Knoten es erzeugt wird, weist einen globalen eindeutigen Bezeichner auf. Diese eindeutige ID ermöglicht es nicht nur, dass die Dateisystemobjekte an einer anderen Stelle in dem Netzwerk verfolgt werden, sie wird auch durch das VFCS 570 als eine Dateisystemobjektkennung exportiert. Durch das Exportieren der gleichen Kennung für das gleiche Dateisystemobjekt von einem beliebigen VFCS 470 kann eine Gruppe von VFCS 470 in Clustern zusammengefasst werden, um einen Endbenutzer-Client transparent zu unterstützen. Siehe dazu die Abbildung aus 6. Wenn ein VFCS einen Fehler aufweist, kann das andere VFCS die Endbenutzeranforderung erfüllen, da sie die Dateisystemobjektkennung erkennt, so wie dies jedes VFCS tut. Somit kann ein VFCS in Clustern zusammengefasst werden, um einen Lastausgleich vorzusehen und um transparent eine aktive Ausfallsicherung bereitzustellen. Wenn ein VFCS Cluster NFS UDP-Unterstützung bereitstellt, ist er in der Lage eine Ausfallsicherung bzw. Failover während der Sitzung (In-Session) vorzunehmen, wobei im Falle einer CIFS- oder NFS TCP-Unterstützung ein VFCS Cluster eine Ausfallsicherung bzw. Failover je Sitzung bereitstellen kann. Die Abbildung aus 6 zeigt ein Ausführungsbeispiel, bei dem die Lastverteilung bzw. der Lastausgleich an den VFCS Servern eingesetzt wird. Das VFCS ist so gestaltet, dass Anforderungen von einem Anwendungsserver an jeden VFCS Server in einem Cluster geleitet werden können, wodurch die Last auf die VFCS Server verteilt wird. Zu diesem Zweck ist die Dateisystemobjektkennung, welche das VFCS an die Anwendung zurückgibt, speziell so gestaltet, dass die Anwendung danach die gleiche Dateisystemobjektkennung für jeden VFCS Server verwenden kann, und wobei der VFCS-Server diese decodieren kann. Das Design bzw. der Aufbau der VFCS Dateisystemobjektkennung berücksichtigt die Tatsache, dass das VFCS zwei entfernte File Sharing-Protokolle in einem Cluster unterstützen muss, nämlich NFS und CIFS. Um die oben genannten Merkmale zu erfüllen, erfüllt die eindeutige Dateisystemobjektkennung gemäß einem weiteren Merkmal der Erfindung die folgenden beiden Kriterien:

(a) Die Dateisystemobjektkennung ist plattformunabhängig, so dass keine Anpassungen abhängig von dem Betriebssystem und dem Dateisystem vorgenommen werden müssen.
(b) Die Dateisystemobjektkennung kann durch jeden Server in dem VFCS Cluster decodiert werden, und wenn sie decodiert wird, bezeichnet sie die gleiche Datei in dem Cluster.

Die VFCS Dateisystemobjektkennung weist drei Informationsstücke auf: einen Dateisystembezeichner, eine Ursprungsknoten-ID und eine Dateisystemobjekt-ID (Datenträger, Verzeichnis oder Datei). Der Dateisystembezeichner wird zu dem Zeitpunkt erstellt, wenn das VFCS in den Kernel geladen wird. Die Ursprungsknoten-ID und die Dateisystemobjekt-ID werden unter Verwendung von Standarddateisystem-E/A-Schnittstellen in einer Kernel-Datenstruktur (inode) gespeichert. Eine Kennung wird von einem VFCS Server bei der Kommunikation mit Anwendungen verwendet, um eine Datei oder ein Verzeichnis in dem globalen Dateisystem des SCDN eindeutig zu identifizieren. Ein VFCS Server weiß, wie eine Dateisystemobjektkennung decodiert werden muss, die abhängig ist von dem Dateisystem. Bei einem herkömmlichen UNIX-Dateisystem weist eine Dateikennung eine Dateisystem-ID, eine inode-Nummer und eine inode-Erzeugungsnummer auf. Bei einem herkömmlichen nicht-UNIX-Dateisystem kann es sich bei einer Dateikennung um einen Zeiger auf eine Datenstruktur in dem Speicher des Dateisystems handeln. Da das herkömmliche Dateisystem keine hart codierte ID als eine Dateisystemobjektkennung verwendet, weisen zwei gespiegelte herkömmliche Dateisysteme auch identische Dateien und Verzeichnisse auf, welche nicht die gleiche Kennungsnummer für das gleiche Objekt aufweisen. Somit kann für ein herkömmliches Dateisystem keine Lastverteilung vorgenommen werden.
b. VFCS Initialisierungsprozedur
Die Abbildung aus 16 zeigt ein Flussdiagramm einer Routine 1600, wobei die Operationen eines VFCS Servers (z. B. VFCS 470) dargestellt werden, die während dem Prozess der VFCS Initialisierung gemäß einem Ausführungsbeispiel der vorliegenden Erfindung (Schritte 1601–1607) ausgeführt werden. In dieser Abbildung werden NAS- Vorrichtungen (Network Attached Storage-Vorrichtungen) für das gemeinsam genutzte Speichersystem verwendet. Die Metadateisystemstruktur und die Blockspeicherpfade (einschließlich Datenträgermetadatendateien) werden in der Operation 1601 eingerichtet, um Zugriff auf deren Daten bereitzustellen. Für Zwecke der vorliegenden Veranschaulichung wird angenommen, dass die Metadateisystemstruktur an /mp/metadata/ eingerichtet wird. Für einen Zugriff auf die ganze Anordnung der Blöcke, die in dem Speichersystem zur Verfügung stehen, werden alle Speichervorrichtungen in der Operation 1602 eingerichtet (mounted). Im Sinne der vorliegenden Erläuterung lauten die Einrichtungs- bzw. Mount-Punkte /mp/blockfiles bzw. /mp/blockdateien, wie zum Beispiel /mp/blockfiles/v1, /mp/blockfiles/v2, etc.
Ein VFCS Server initialisiert den Datenträgernamens-Cache, indem die Datenträgermetadatendatei in den Cache geladen wird (z. B. Operation 1603). Während der Operation 1604 beginnt der VFCS Server mit der Gestaltung des im Speicher vorgesehenen Dateisystems, das das Laden der ganzen Metadateisystemstruktur umfasst, und wobei der Wurzel der Struktur eine konstante Kennung zugewiesen wird. Ein Ausführungsbeispiel der vorliegenden Erfindung kann einen Baum VNODE unter Unix als die Kernel-Schnittstelle zu dem im Speicher vorgesehenen Dateisystem verwenden (Baum von "inodes" in dem Speicher). Das im Speicher vorgesehene Dateisystem ist eine Baumstruktur von inode, welche das globale Dateisystem darstellt. Die Initialisierung weist umfasst somit die Erstellung eines teilweisen im Speicher vorgesehenen Dateisystems in Form einer inode-Struktur und eines Baums VFCS VNODE als Kernel-Schnittstelle zu dem inode-Baum. Das Front-End VFS VNODE weist eine Wurzel VFCS VNODE für das exportierte Wurzel- bzw. Stammverzeichnis auf. Die Initialisierung weist ferner die Zuordnung einer konstanten Kennung an das Wurzelverzeichnis auf. Zu Zwecken der vorliegenden Erläuterung lautet das exportierte Verzeichnis/export. Das VFCS fährt danach gemäß der Anzeige in der Operation 1605 fort mit dem Aufbau des im Speicher vorgesehenen Dateisystems, indem Datenträger bzw. Volumen und Verzeichnisse sowie die Kernel-Schnittstelle erzeugt werden, d. h. die VFCS_VNODES von Datenträgern und VFCS_VNODES von Verzeichnissen. Zum Beispiel nehmen die Datenträger die Form/export/vol1, /export/vol2, etc. an. Es gibt einen VFCS_VNODE für jeden Datenträger und jedes Verzeichnis. Die zugeordneten Datenträger- und Verzeichnismetadatendateien werden geladen und die zugeordnete für das Objekt eindeutige ID wird der Objektkennung (Datenträger oder Verzeichnis) zugeordnet. Zum Beispiel wird angenommen, dass Studio X einen Datenträger darstellt, dessen eindeutige ID "123" lautet. Wenn eine Anwendung auf den Datenträger Studio X unter Verwendung dessen Namen zugreift, wird eine Kennung von 123 an die Anwendung zurückgegeben.
Während der Operation 1606 initialisiert das VFCS den Dateinamenscache (File Name Cache). Zum Beispiel erhält der VFCS Server abhängig von der Speicherverfügbarkeit eine vollständige oder teilweise Liste der Dateinamen und die eindeutige ID einiger der beliebtesten Dateien. Das VFCS erstellt die VNODEs oder die zugeordneten, im Speicher vorgesehenen inodes für diese Dateien nicht bevor auf diese zugegriffen wird. Dies ist ein Beispiel für ein "selektives und dynamisches Caching", d. h. die Caches, die für die Population ausgewählt werden, und wann diese populiert bzw. besetzt werden (zum Zeitpunkt der Initialisierung oder in Laufzeit) werden aus Leistungsgründen bestimmt. Nach der Initialisierung weist das im Speicher vorgesehene Dateisystem des VFCS einen Wurzelknoten und die Datenträgerknoten in den ersten beiden Schichten des Dateisystembaums auf. Die dritte und tiefere Ebene des Dateisystembaums weist Dateien und Verzeichnisse auf, und diese Objekte werden dynamisch belegt. Wenn eine Datei oder Verzeichnismetadaten sich nicht in dem Cache befinden, wenn ein Endbenutzer das Dateisystemobjekt anfordert, muss das VFCS die Metadaten aus dem Speicher lesen und einen inode für das im Speicher vorgesehene Dateisystem und den zugeordneten VNODE erzeugen. Nachdem ein inode und VNODE erstellt bzw. erzeugt worden sind, kann das VFCS die Blockindexanordnung prüfen und ein Anforderungspaket "prepare" an einen lokalen DS senden, um die nicht residenten Datenblöcke zu importieren.
Das VFCS fährt weiter mit dem Aufbau des im Speicher vorgesehenen Dateisystem-Cache fort während der Laufzeit, während der auf Dateien zugegriffen wird. Wenn ein Anwendungsserver auf eine bestimmte Datei zugreift, wie zum Beispiel /export/vol1/dir1/file_nameX, liest der VFCS Server, der die Anforderung bedient, den Dateinamen in dem Dateinamen-Cache aus, erzeugt einen VFCS_VNODE und den zugeordneten "inode" in dem im Speicher vorgesehenen Dateisystem für die entsprechende Datei und erhält die Liste der Blockdateien für die Datei. Gleichzeitig gibt der VFCS Server ein Anforderungspaket "prepare" über einen DSC Load Balancer bzw. eine Lastverteilungseinrichtung an einen DS aus. Nachdem der DS die angeforderten Dateiabschnitte heruntergeladen hat, speichert der DS die Abschnitte als Blöcke, aktualisiert die zugeordnete Blockindexanordnung der Datei, um die Ankunft der neuen Datenblöcke zu reflektieren, signalisiert VFCS oder VFCS ruft die Metadatendateien ab und erkennt, dass die Blöcke in dem Speichersystem vorhanden sind; der VFCS Server liest Datenblöcke, setzt diese zusammen und multiplexiert sie und sendet die Daten an den anfordernden Anwendungsserver. Jeder VFCS Server führt ein Read-Ahead-Caching oder eine direkte Paketweiterleitung (Spoofing) aus, um die Leistung bzw. die Performance zu verbessern.
c. Prozedur für den Zugriff auf ein VFCS Dateisystemobjekt
Die Abbildung aus 17A zeigt eine Routine 1700 der Operationen des VFCS 470, die während Laufzeit ausgeführt werden (Schritte 1702–1719). Wenn ein Anwendungsserver oder ein Endbenutzer-Client den Zugriff auf ein Dateisystemobjekt anfordert, prüft das VFCS 470 zuerst, ob sich der VFCS_VNODE und dessen zugeordneter inode für die Datei in dem im Speicher vorgesehenen Dateisystem des VFCS befinden (Operation 1711). Anders ausgedrückt bestimmt in der Operation 1711 der VFCS Server, ob ein VFCS-Knoten (z. B. ein Front-End-Vnode) für das Dateisystemobjekt existiert. Wenn dies der Fall ist, fährt der VFCS Server mit dem Schritt 1715 fort, während er ansonsten mit dem Schritte 1712 fort fährt. Für ein Dateiobjekt überprüft das VFCS in dem Schritt 1712 dessen Dateinamens-Cache, um zu bestimmen, ob ein Eingang für die Datei existiert (d. h. existieren die verwandten Dateiobjektmetadaten in dem Cache?). Wenn keine zugeordneten Dateimetadaten existieren oder wenn es sich bei dem angeforderten Objekt um einen Datenträger oder ein Verzeichnis handelt, fährt der VFCS Server mit der Operation 1713 fort und liest die Metadateisystemstruktur und die zugeordneten Metadatendateien. Gleichzeitig kann der VFCS Server einen Teil des Speichers frei machen, indem unbenutzte oder am wenigsten genutzte inodes (im Speicher vorgesehenes Dateisystem) und Front-End-Vnodes entfernt werden. Für ein Dateiobjekt speichert das VFCS die verwandten bzw. zugeordneten Dateisystemobjektmetadaten und speichert die Informationen in dem Dateinamens-Cache (File Name Cache) und fährt danach mit der Operation 1714 fort. Wenn jedoch in dem Schritt 1712 zugeordnete Dateimetadaten in dem Dateinamens-Cache existieren, so fährt der VFCS Server unverzüglich mit der Operation 1714 fort, wobei der im Speicher vorgesehene inode des VFCS-Dateisystems und der Front-End VNODE für die Datei erstellt werden. Wenn es sich bei einem Objekt um eine Datei handelt, speichert das VFCS das Dateiobjekt in dem Dateinamens-Cache. Danach fährt das VFCS direkt mit der Operation 1715 fort.
Während der Operation 1715 prüft der VFCS-Dateiserver, ob es sich bei dem angeforderten Objekt um einen Datenträger oder ein Verzeichnis handelt, und wenn dies der Fall ist, springt der Ablauf zu 1717. Wenn es sich bei dem angeforderten Objekt um eine Datei handelt, prüft der Server ferner, ob etwaige Blöcke für die angeforderte Datei in dem (vorübergehenden) Vorerfassungs-Block-Cache existieren. Wenn keine derartigen Blöcke vorhanden sind, fährt der VFCS Server mit der Operation 17166 fort, wo er Blöcke aus dem Speichersystem der Station liest, die der angeforderten Datei zugeordnet sind, ein Anforderungspaket "prepare" an den DSC der Station sendet, um die fehlenden Blöcke wieder zu belegen, einen Read-Ahead-Vorgang ausführt und danach mit der Operation 1717 fort fährt. Wenn hingegen einer oder mehrere Blöcke für die angeforderte Datei in dem Cache für vorerfasste Blöcke existieren, fährt der VFCS Server nach 1715 direkt mit 1717 fort. Wenn das VFCS einen Lesevorgang aus dem Speicher ausführt, wendet es einen Algorithmus an, der in Bezug auf den Schritt 1466 aus der Abbildung aus 14B beschrieben wird, um die Datenblöcke zu lokalisieren.
In der Operation 1717 erfasst der VFCS Server ferner die Datenträger- oder Verzeichnisinformationen, oder wenn es sich bei den angeforderten Daten um eine Datei handelt, setzt er die Datenblöcke wieder zusammen und multiplexiert diese, und in dem schritt 1719 führt er ein Read-Ahead-Caching aus, um die Leistung zu verbessern. Ferner kann der VFCS Server eine direkte Paketweiterleitung oder ein Paket-Spoofing ausführen, um Daten direkt aus dem Back-End-Speicher ohne Pufferkopiervorgang zu der Front-End-Anwendung zu transportieren.
Die Anzahl der vorerfassten Blöcke, die ein VFCS im Cache speichert, ist abhängig von der lokalen Speicherverfügbarkeit in dem VFCS Server. Die dritte und tiefere Ebene von Verzeichnissen und die Datei des im Speicher vorgesehenen Dateisystems können einem Pruning unterzogen werden, und der Cache der vorerfassten Blöcke kann geleert werden, wenn der Speicherplatz knapp wird. Abhängig von der Speicherverfügbarkeit kann ein VFCS eine vollständige oder teilweise Gruppe von Dateisystemverzeichnissen im Cache speichern. Bei begrenztem Speicher werden nur die Dateimetadaten für die Dateien im Cache gespeichert, auf welche am häufigsten zugegriffen wird, und danach wird der Cache regelmäßig aktualisiert auf der Basis der letzten Nutzungsinformationen. Dabei handelt es sich um das "selektive und dynamische Caching" des globalen Dateisystems.
Zum Beispiel zur Unterstützung einer Anzahl X von Datenträgern/Verzeichnissen, eine Anzahl Y von Dateien und eine Anzahl Z von gleichzeitigen Benutzern, jeweils mit einer Anzahl N von vorerfassten Blöcken für die bestmögliche Leistung, wird ein VFCS mit einer Speichergröße unter Verwendung der folgenden Gleichung konfiguriert:
Speichergröße in Mbyte =
VFCS OS-Speicheranforderung +
VFCS Laufzeit-Speicheranforderung +
X·(erforderlicher Speicher für jeden Datenträger-/Verzeichnis-Cache) +
Y·(erforderlicher Speicher für jeden Dateinamens-Cache) +
(1 + X + Y)·(Größe des VNODE-Baums) + Z·N·(Blockgröße).
Während der Behandlung der Anforderung kann das VFCS auch Dienstgüterichtlinien gemäß einer Gruppe von konfigurierten Parameter anwenden. Die Abbildung aus 17B zeigt eine Routine 1720 für die Anwendung von Richtlinien zur Dienstgüte bzw. Servicequalität auf der Basis des Benutzer- und Objektsystemtyps gemäß einem Ausführungsbeispiel der vorliegenden Erfindung (Schritte 1720–1722). Zum Beispiel kann die Routine 1720 in den vorstehend beschriebenen schritten 1702 und 1706 ausgeführt werden.
Die Routine 1720 veranschaulicht, dass während eine Anforderung empfangen und behandelt bzw. bearbeitet wird oder wenn nicht residente Datenblöcke von anderen Knoten importiert werden müssen, das VFCS konfigurierte Dienstgüterichtlinien abrufen kann (Schritt 1720). Zum Beispiel kann eine Richtlinie angeben, dass einer bestimmten Benutzergruppe höhere Priorität in Bezug auf Netzwerkressourcen eingeräumt wird und somit eine höhere Dienstgüte. Die Parameter können Benutzer, Dateisystemobjekt, Dateityp, Region bzw. Gebiet, Inhalteeigentümer, etc. umfassen. Wenn eine Richtlinie identifiziert wird, kann ein VFCS Netzwerk- und Speicherressourcen von Speichervorrichtungen, Netzwerk-Switches, Routern und anderen Servern reservieren (Schritt 1722).
d. VFCS-Module
Die Abbildung aus 18 zeigt Module in einem VFCS 1800 gemäß einem Ausführungsbeispiel der vorliegenden Erfindung. In dem SCDN-Netzwerk 100 existieren Dateien in Form vieler kleiner Blockdateien mit konfigurierbarer Größe, die in mehreren Speichervorrichtungen gespeichert sind, und Verzeichnisse und Datenträger existieren in der Form einer Metadatendatei- und Metadateisystemstruktur in dem Speicher aller Knoten. Das VFCS 1800 stellt einen speziellen Proxy-Dateiserver oder einen Dateisystem-Gateway dar, der für Endbenutzer-Clients oder Anwendungsserver eine Dateisystemschnittstelle sowohl in NFS- als auch in CIFS-Protokollen bereitstellt. Die folgende Beschreibung beschreibt hauptsächlich die NFS-Implementierungen. Zu den Aufgaben des VFCS 1800 zählen: 1) die Darstellung eines globalen Dateisystems; 3) das Zusammensetzen von "Blockdateien" in Echtzeit nach Anforderung durch Anwendungsserver, so dass die Anwendungsserver glauben, dass die Datei-E/A- an einer einzelnen großen Datei ausgeführt wird; und 3) die Modifikation von Dateisystemobjekten zu ermöglichen, die Verteilung von Aktualisierungen zu verwalten und einzuleiten. Das VFCS 1800 kann als ein Dateisystem-Gateway betrachtet werden, wobei ein NFS- und CIFS-Front-End an die Benutzer-Clients bereitgestellt wird und ein zugrunde liegendes Dateisystem an dem Back-End verwendet wird. Es kann als eine Dateisystemüberlagerung betrachtet werden. Bei dem zugrunde liegenden Dateisystem kann es sich um ein lokales Dateisystem handeln, das auf direkt angeschlossenen Speicher- oder Fibre Channel Storage Area-Netzwerk-Vorrichtungen aufgebaut wird, wobei es sich aber auch um einen Network Attached Storage (NAS) handeln kann. Für den Fall, dass es sich bei dem zugrunde liegenden Dateisystem um ein NAS handelt, wird ein NFS-Client an dem Back-End eingesetzt, um ein VFCS 1800 zu unterstützen. In diesem Fall muss das VFCS 1800 das zugrunde liegende System "einrichten" (mount).
Für den Beginn der Verwendung von NFS über VFCS muss eine Anwendungsservervorrichtung oder ein Endbenutzergerät mit NFS-Client an dem globalen Dateisystem eines VFCS über ein Netzwerk angebracht werden, um über das VFCS auf das Dateisystemobjekt zuzugreifen und dieses zu modifizieren. Für die Anbringung an dem VFCS-Dateisystem muss ein NFS-Client die Dateikennung für die Wurzel des exportierten Dateisystems erlangen, bevor auf etwaige Dateisystemobjekte in dem Dateisystem aus der Ferne zugegriffen werden kann. Das "mount" Protokoll bzw. Einrichtungsprotokoll ist für den NFS-Client so gestaltet, dass eine erste Dateikennung des exportierten Wurzel- bzw. Stammverzeichnisses für den Zugriff auf ein Netzwerkdateisystem erhalten wird. VFCS mountd 1820 implementiert die "Einrichtung" (mount), um eine Schnittstelle bereitzustellen, um es Endbenutzer-Clients oder Anwendungsservern zu ermöglichen, die Wurzelkennung zu erlangen, wobei dies ähnlich ist der Funktion "mount", welche durch reguläre bzw. normale NAS-Speichervorrichtungen bereitgestellt wird. VFCS mountd 1820 implementiert das standardmäßige NFS-Protokoll "mount". Es unterstützt alle RPC-Programme, nämlich NULLPROC, RPCMTN_MOUNT, RPCMNT_UMOUNT, RPCMNT_DUMP und RPCMNT_UMNTALL.
Zum Zeitpunkt des Bootens bzw. Hochfahrens richtet VFCSd 1805 das zugrunde liegende Dateisystem am Back-End ein, wobei dies die Meetadateisystemstruktur und die Blockspeicherverzeichnisse aufweist. Zum Beispiel: /backend/metapath/, /backend/blockfiles/1/, /backend/blockfiles/2/, etc. Diese Verzeichnisse weisen den ganzen lokalen Inhaltsbestand auf. VFCSd 1805 verwendet zuerst die Chunking-Schicht (FCL) 1810, um die Metadateisystemstruktur und die Datenträgermetadatendatei zu laden, um ein in einem Speicher vorgesehenes Dateisystem 1840 als Baum von inodes zu erzeugen, um dessen globale Dateisystemdarstellung zu unterstützen. Dabei können auch das Verzeichnis und die Dateimetadaten geladen werden, abhängig von der Speicherverfügbarkeit. Für den Fall, dass der Speicher nicht ausreichend groß ist, wird nur die Datenträgerebene in den Speicher geladen, wobei die Verzeichnis- und Datei-inodes nach Bedarf erzeugt werden können.
Nachdem das im Speicher vorgesehene Dateisystem erstellt bzw. erzeugt worden ist, leitet VFCSd 1804 die Front-End-VFS-Kernel-Schnittstelle 1830 ein und baut danach eine VFCS-VNODE-Baumstruktur. Der Baum VFCS_VNODE stellt die globale Dateisystemdarstellung dar und wird durch das im Speicher vorgesehene Dateisystem 1840 unterstützt. Das im Speicher vorgesehene Dateisystem 1840 speichert die Blockindexanordnung jeder Datei im Cache, um die Abbildung der ursprünglichen Datei zu ermöglichen, die über die VFCS-Schnittstelle den Blockdateien in dem Back-End-Dateisystem präsentiert wird. Es kann sein, dass der Speicher eines VFCS nicht ausreicht, um den ganzen VNODE des Dateisystems zu erzeugen, wobei VFCS_VNODE für ein Dateisystemobjekt nach Bedarf erstellt werden kann. VFCSd 1805 lädt ferner teilweise Dateimetadaten in dessen Dateinamens-Cache für die beliebtesten Inhalte. Wenn VNODE erzeugt wird, wird jeder Einheit VNODE eine global eindeutige ID als ihre Kennung zugewiesen. Dem Wurzelknoten (exportiertes Verzeichnis) wird eine "hart codierte" Kennung zugewiesen. Die Kennungen für Datenträger, Verzeichnisse und Dateien werden mit ihrer eindeutigen ID as deren Metadaten zugeordnet. Da die Daten physisch bzw. physikalisch an dem Back-End-Dateisystem gespeichert werden, möglicherweise NAS-Vorrichtungen, wird das in dem Speicher vorgesehene Dateisystem 1840 durch das Back-End-VFS-Kernel-Schnittstellenmodul 1850 unterstützt, so dass ein reales Dateisystem unterstützt wird. Die Back-End-VFS-Kernel-Schnittstelle 1850 stellt eine Standard-Kernel-Schnittstelle für das zugrunde liegende Dateisystem bereit, wobei es sich um jede Art von Dateisystem handeln kann, einschließlich des lokalen Dateisystems 1885 oder um jedes Netzwerkdateisystem, wie zum Beispiel CIFS oder NFS. Auf entfernte CIFS- und NFS-Server kann entsprechend über den CIFS-Client 1880 oder den NFS-Client 1890 zugegriffen werden. Das Back-End-Dateisystem weist die tatsächlichen Daten auf -Blockdateien.
Nachdem VFCSd 1805 den Boot-Prozess abgeschlossen hat, erhält VFCS mountd 1820 die globale "harte" Kennung für das exportierte Wurzelverzeichnis (einen Wurzelpfadnamen) des im Speicher vorgesehenen Dateisystems. Die Kennung dient zur Verwendung bei folgenden Dateisystem-E/A-Operationen, welche den Zugriff, die Erstellung und das Löschen von Verzeichnissen (getattr, readdir, etc.) und Dateien aufweisen. Die Hauptaufgabe von VFCS mountd 1820 ist es, dessen Endbenutzer-Clients zu verwalten, indem die Endbenutzer-Clients authentifiziert und an die Wurzelkennung übergeben werden.
Wenn in Laufzeit ein VFCSd 1805 eine Dateisystemanforderung empfängt, wird die Anforderung zuerst authentifiziert, bevor sie über den Front-End-VFS 1830 zu einem im Speicher bereitgestellten Dateisystem 1840 weitergeleitet wird. Die Anforderung kann die Erzeugung eines neuen Dateisystemobjekts darstellt oder das Löschen oder Modifizieren eines bestehenden Dateisystemobjekts oder den Zugriff auf ein solches. Für die Erzeugung eines neuen Dateisystemobjekts wird ein inode dem im Speicher vorgesehenen Dateisystem 1840 hinzugefügt, und ein zugeordneter Front-End VFCS_VNODE wird ebenfalls erzeugt, wobei die Metadaten und Datenblöcke in dem Speicher gespeichert und danach repliziert werden über einen DS an das SCDN. Für die Anforderungen, welche ein Dateisystemobjekt modifizieren, werden der entsprechende inode und der Front-End VNODE modifiziert, wobei die zugeordneten Metadaten, die Metadateisystemstruktur und die Datenblöcke in dem Speicher ebenfalls aktualisiert werden können, und wobei die neuen Informationen über einen DS repliziert werden. Zum Löschen von Dateisystemobjekten können der VNODE, der im Speicher vorgesehene inode, Metadaten und Datenblöcke entfernt werden, und der Befehl wird an den Rest des SCDN über einen DS repliziert. Für den Zugriff auf ein Dateisystemobjekt versucht der VFCSd 1805 den zugeordneten VFCS_VNODE zu lokalisieren und gibt die entsprechenden Datenträger- oder Verzeichnisinformationen zurück, wobei er für ein Dateiobjekt die Datenblöcke von bzw. aus den Speichervorrichtungen zurückgibt. Wenn der VFCS_VNODE nicht lokalisiert werden kann, liest VFCSd 1805 die Metadateisystemstruktur, um das Objekt zu validieren, und wenn das Objekt eine Datei darstellt, wird in dem Dateinamens-Cache gesucht. Ansonsten werden die Metadaten des zugeordneten Objekts in den Speicher geladen, und der zugeordnete inode und VFCS_VNODE werden erstellt und die entsprechenden Daten werden zurückgegeben. Wenn sich die Anforderung auf ein Dateiobjekt bezieht und wenn bestimmte Abschnitte der Datei nicht lokal angeordnet sind, gibt das Back-End VFS 1830 einen FDP-Befehl "prepare" an den DS aus, um die Blöcke zu importieren.
Das VFCS Front-End VFS 1830 achtet stets auf Benachrichtigungen bzw. Mitteilungen von dem lokalen DS, wobei der DS VFCS 1800 über die Ankunft aller neuen Dateisystemobjekte benachrichtigt. Wenn ein Endbenutzer auf eine Datei zugreift, die sich weder in dem im Speicher vorgesehenen Dateisystem noch in dem Namens-Cache befindet, so verifiziert das Front-End VFS 1830 mit der Metadateisystemstruktur in dem Back-End-Speicher, bevor ein Fehler "Datei nicht gefunden" (File not found) zurückgegeben wird.
Zur Leistungsverbesserung beim Lesen des Dateiobjekts führt das VFCS 1800 entweder ein Read-Ahead-Caching oder eine direkte Paketweiterleitung aus (IP-Paket-Spoofing), um die Daten direkt aus dem Back-End-Speicher zu der Front-End-Anwendung zu transportieren, ohne den Vorgang des Pufferkopierens. Der IP Redirector, eine Komponente innerhalb des IP-Stapels 1860, führt die direkte Paketweiterleitung aus. Gemäß einem Aspekt der vorliegenden Erfindung implementiert das System eine direkte Paketweiterleitung (IP Spoofing) der gelesenen Daten. Das IP Paket-Spoofing oder die direkte Paketweiterleitung kann nur ausgeführt werden, wenn es sich bei den Back-End-Speichervorrichtungen um NAS handelt. Für den Fall, dass es sich bei dem Back-End-Speicher nicht um NAS handelt, wird die Leistung der Leseanforderung verbessert, indem die Kernel-Speicherpuffer mit Speichervorrichtungstreibern gemeinsam genutzt werden, wobei ein MBUF Director 1870 für die Übermittlung von mbuf-Daten an die Endbenutzer verantwortlich ist.
Die Abbildung aus 19 zeigt ein Flussdiagramm 1900 eines Ausführungsbeispiels des Leseanforderungsprozesses, welcher durch das VFCS 1800 gemäß der vorliegenden Erfindung ausgeführt wird (Schritte 1904–1950). Dieses Flussdiagramm 1900 bezieht sich ebenfalls auf die Operationen, die vorstehend in Bezug auf die Abbildung aus 17A bereits beschrieben worden sind. In dem Schritt 1904 empfängt VFCSd 1805 eine NFS-Leseanforderung 2600 von einem Anwendungsserver. In diesem Modul prüfen das Front-End VFS 1830 und das im Speicher vorgesehene Dateisystem 1840 den zugeordneten vnode und inode und deren Namens-Cache. Wenn der angeforderte Dateiknoten nicht im Cache gespeichert wird, erzeugen Module des Front-End VFS 1830 und eines im Speicher vorgesehenes Dateisystems 1840 den erforderlichen VNODE und inode in dem Speicher und geben einen FDP-Befehl "prepare" an den lokalen DS aus.
Über das im Speicher vorgesehene Dateisystemmodul 1840 werden eine oder mehrere Back-End-Leseanforderungen über den entsprechenden inode erzeugt, der Informationen für die Datenabbildung bereitstellt (Schritt 1910). Eine Back-End-Leseoperation wird durch das Back-End VFS-Modul bearbeitet bzw. behandelt. Die Back-End Leseanforderung wird durch die Module des VFCS Back-End VFS 1850 bearbeitet sowie des Kernel-Netzwerk-E/A-Redirectors 1860 und 1870. Nachdem VFCSd 1805 eine Leseanforderung von dem Anwendungsserver in dem Schritt 1904 empfangen hat, wird die Leseanforderung schließlich in Blockdateien abgebildet, die sich an Back-End Speichervorrichtungen befinden können. Die durch das VFCS VFS-Modul 1830 erzeugte Back-End Leseanforderung wird an das VFCS Back-End VFS-Modul 1850 weitergeleitet (Schritt 1910). In dem Back-End VFS-Modul 1850 wird die Back-End-Anforderung in die Warteschlange eingestellt und verarbeitet (Schritt 1920). Wenn die Back-End-Speichervorrichtungen NAS sind, wird ein NFS-Lesepaket auf der Basis der gegebenen Parameter gebildet und zu dem Back-End Dateiserver gesendet (Schritt 1920). Wenn die Daten angekommen sind, weist im Falle eines NAS Back-End der VFCS 1800 die Option auf, die direkte Paketrückführung auf der IP-Ebene auszuführen (Schritt 1930). Wenn die direkte Paketweiterleitung auszuführen ist (Schritt 1950), führt der VFCS IP Redirector 1860 die Funktionen des IP Spoofing und Weiterleitens aus, indem die Ziel-IP und die Quellen-IP in dem Paket-Header so ersetzt bzw. ausgetauscht werden, dass der Anwendungsserver glaubt, dass die Antwort auf NFS-Lesen von VFCSd 1805 stammt. Das VFCS Back-End VFS-Modul wird durch den IP Redirector benachrichtigt, wenn Daten weitergeleitet werden. Wenn es sich in diesem Fall bei dem Back-End-Dateisystem nicht um NAS handelt, oder wenn IP Spoofing ausgeschaltet bzw. deaktiviert ist, so sammelt das Back-End VFS-Modul 1850 die Daten in Kernel-Speicherpuffern, wobei nur ein Puffer kopiert, bevor Speicher-Puffer zu dem Benutzer weitergeleitet werden (Schritt 1940). Die Kernel-Speicherpuffer werden durch das MBUF Director-Modul 1870 übermittelt. Das Back-End VFS-Modul 1850 säubert ihre Warteschlange nach der Ausführung der Anforderungen (Schritt 1950).
e. Lastverteilungseinrichtung des VFCS Clusters
Die hierin beschriebene Cluster Lastverteilungseinrichtung (Cluster Load Balancer) kann in Verbindung mit dem Verteilungsserver-Cluster 410 aus der Abbildung aus 4A, dem Anwendungsserver-Cluster 420A aus 4A und dem VFCS Cluster 600 aus 6 eingesetzt werden. Durch das Exportieren der gleichen Kennung für das gleiche Dateisystemobjekt von jedem VFCS kann eine Gruppe von VFCS 470<1...L> in einem Cluster zusammengefasst werden, um einen Endbenutzer-Client transparent zu unterstützen. Siehe dazu die Abbildung aus 6. Wenn ein VFCS ausgefallen ist, kann das andere VFCS die Endbenutzeranforderung erfüllen, da es die Dateisystemobjektkennung wie jedes VFCS erkennt. Somit kann ein VFCS einem Clustering unterzogen werden, um eine Lastverteilung vorzunehmen und transparent eine aktive-aktive Ausfallsicherung (Failover) vorzusehen. Für den Fall, dass ein VFCS Cluster eine NFS UDP-Unterstützung bereitstellt, ist es in der Lage eine Ausfallsicherung während der Sitzung (In-Session Failover) ausführen, für den Fall einer CIFS oder NFS TCP Unterstützung kann ein VFCS Cluster eine Ausfallsicherung je Sitzung durchführen (Per Session Failover).
Eine Lastverteilungseinrichtung stellt drei Funktionen bereit: Serveranforderungsverteilung, Serverredundanz und Unterstützung der Ausfallsicherung (Failover) für eine Lastverteilungseinrichtung. Bei der ersten Funktion, der Serveranforderungsverteilung, handelt es sich um die Verteilung von ankommenden bzw. eingehenden Anforderungen unter einer Gruppe von Servern. Jeder Server empfängt nur einen bestimmten Anteil der Anforderungen insgesamt. Die Abbildung aus 20 zeigt eine Lastverteilungseinrichtung und zwei Server (Server-1 und Server-2), welche an ein Netzwerksegment angeschlossen sind. Die Pfeile stellen den ankommenden Strom von Serveranforderungen dar. Wenn die beiden Server jeweils ungefähr die Hälfte der Anforderungen empfangen, wird die ankommende bzw. eingehende Serverbelastung zwischen ihnen "verteilt". Bei der zweiten Funktion, der Serverredundanz, handelt es sich um die Fähigkeit, Clients vor Serverausfällen abzuschirmen. Die Lastverteilungseinrichtung detektiert Serverausfälle bzw. Serverfehler, indem periodische Gesundheitsprüfungen an jedem Server vorgenommen werden. Wenn ein Server ausgefallen ist, verteilt die Lastverteilungseinrichtung die Anforderungen neu an die verbliebenen bzw. verbleibenden Server. Die Lastverteilungseinrichtung führt weiter periodische Gesundheitsprüfungen an ausgefallenen Servern durch, um zu detektieren, wann sie sich erholt haben. In der Abbildung aus 21 ist der Server-1 ausgefallen, wie dies durch die Schraffierung dargestellt ist, und alle Anforderungen werden jetzt an den einzigen verbliebenen Server verteilt. Bei der dritten Funktion handelt es sich um die Unterstützung der Ausfallsicherung der Lastverteilungseinrichtung. Die Lastverteilungseinrichtung ist ausreichend zustandslos im Betrieb, so dass in den meisten Fällen bei einem Ausfall der Lastverteilungseinrichtung eine sekundäre Lastverteilungseinrichtung direkt übernehmen kann und ankommende Anforderungen weiter verteilen bzw. ausgleichen kann, ohne dass eine Client-Störung bzw. Unterbrechung auftritt. In der Abbildung aus 22 ist die primäre Lastverteilungseinrichtung ausgefallen und die sekundäre Lastverteilungseinrichtung hat übernommen. Die Anforderungen werden weiter auf die Server verteilt.
f. IP Weiterleitung und direkte Serverantwort:
Die Serveranforderungsverteilung wird für die TCP/IP UDP und TCP Protokolle unterstützt. UDP ist ein Datagramm-orientiertes Protokoll. Clients öffnen eine TCP-Verbindung mit einem Server und senden eine Reihe von Anforderungen über die Verbindung.
In beiden Fällen erreicht der Client einen Server im Netzwerk durch Adressierung des UDP-Datagramms oder TCP-Verbindung mit der IP-Netzwerkadresse des Servers. Die Lastverteilungseinrichtung ist mit einer speziellen IP-Adresse konfiguriert, die als eine "virtuelle" IP-Adresse bekannt ist, von denen Clients davon ausgehen, dass es sich um einen Server handelt. Clients adressieren ihre UDP-Datagramme oder TCP-Verbindungen an die virtuelle IP-Adresse der Lastverteilungseinrichtung. Die Lastverteilungseinrichtung leitet danach diese UDP-Datagramme oder TCP-Verbindungen an einen der eigentlichen Server weiter.
Die Weiterleitung erfolgt auf der IP-Paketebene. TCP/IP verwendet das ARP-Protokoll zum Auflösen von IP-Netzwerkadressen in physikalische Netzwerk-Hardwareadressen. Im letzten Abschnitt oder Netzwerksegment der Zustellung erfolgt dies in die Netzwerk-Hardwareadresse der Ziel-IP-Adresse. Jedes IP-Paket enthält eine Ziel-IP-Adresse, und die Pakete, welche Client-UDP-Datagramme oder TCP-Verbindungen führen, werden an die virtuelle IP-Adresse der Lastverteilungseinrichtung adressiert. Wenn das Paket an dem lokalen Netzwerksegment ankommt, wird diese IP-Adresse zu der Netzwerk-Hardwareadresse der Lastverteilungseinrichtung aufgelöst.
Für die Weiterleitung eines Pakets an einen eigentlichen Server, sendet die Lastverteilungseinrichtung das nicht modifizierte Paket erneut an dem lokalen Netzwerksegment. Anstelle der Verwendung der Ziel-IP-Adresse des Pakets in der ARP-Protokollauflösung verwendet die Lastverteilungseinrichtung jedoch die eigentliche bzw. tatsächliche IP-Adresse des ausgewählten Servers. Das ARP-Protokoll löst diese Adresse zu der Netzwerk-Hardwareadresse des Servers auf, und das Paket wird von diesem Server empfangen, obgleich dieser eine andere Ziel-IP-Adresse aufweist als die Adresse, die bei der ARP-Auflösung verwendet worden ist. Die Abbildung aus 23 zeigt eine Lastverteilungseinrichtung mit zwei konfigurierten IP-Adressen, 10.0.0.1 und 198.1.1.1 und zwei Servern (Server-1 und Server-2) mit den IP-Adressen 10.0.0.2 und 10.0.0.3. Die Adresse 198.1.1.1 wird als die virtuelle IP-Adresse verwendet. Client-Anforderungen kommen in IP-Paketen an, die an 198.1.1.1 adressiert sind. Der Sender dieser Pakete auf dem lokalen Netzwerksegment, wie zum Beispiel ein Router, würde diese Pakete an die Netzwerk-Hardwareadresse der Lastverteilungseinrichtung auflösen. Die Lastverteilungseinrichtung wiederum sendet die Pakete erneut in dem lokalen Netzwerksegment ohne Modifikationen und verwendet eine tatsächliche Server-IP-Adresse (an Stelle der Zieladresse des Pakets) für die Auflösung der Netzwerk-Hardwareadresse eines Servers. In Bezug auf die Abbildung aus 23 wird ein Paket an den Server-1 weitergeleitet.
Da die Pakete ohne Modifizierungen weitergeleitet werden, kann der das Paket empfangene Server die Antwortpakete an den Originator der Anforderung adressieren, indem einfach die Quellen- und Zieladressen ausgetauscht werden, welche in dem Anforderungspaket enthalten sind. Die Antwortzieladresse stellt die IP-Adresse des Clients dar, und die Antwortquellenadresse stellt die virtuelle IP-Adresse dar. Die Antwortpakete fließen direkt zurück zu dem Client und werden nicht von der Lastverteilungseinrichtung empfangen. Dies wird als "direkte Serverantwort" (Direct Server Return) bezeichnet. Die Abbildung aus 24 zeigt den Pfad bzw. Weg eines Antwortpakets zu dem Server-1 von der Lastverteilungseinrichtung und den Pfad eines Antwortpakets von dem Server-1 zurück zu dem Client.
g. Laufzeitoperationen:
Die Abbildung aus 25 zeigt ein Cluster-Lastverteilungseinrichtungs-Paketverteilungs-Flussdiagramm 2500 gemäß einem Ausführungsbeispiel der vorliegenden Erfindung (Schritte 2510–2540). Die hierin beschriebene Cluster-Lastverteilungseinrichtung (oder einfach "Lastverteilungseinrichtung") kann in Verbindung mit dem Verteilungsserver-Cluster 410 aus 4A, dem Anwendungsserver-Cluster 420A aus 4A und dem VFCS Cluster 600 aus 6 eingesetzt werden. Die Lastverteilungseinrichtung ist als einer oder mehrere virtuelle Server konfiguriert. Ein virtueller Server ist dargestellt durch eine Kombination aus IP-Adresse und UDP- oder TCP-Port-Nummer. Ein virtueller Server kann als ein "Match any Port" konfiguriert werden anstatt mit einer bestimmten Port-Nummer. Jeder virtuelle Server ist so konfiguriert, dass er einen oder mehrere reale Server aufweist, und jeder reale Server ist mit dessen IP-Adresse konfiguriert und mit der Netzwerkschnittstelle, die so zu verwenden ist, dass der reale Server erreicht wird. Jeder virtuelle Server ist separat konfiguriert für die Server-Gesundheitsprüfungen.
Für jedes an einer Netzwerk-Hardwareschnittstelle empfangene IP-Paket (Schritt 2510) scannt die Lastverteilungseinrichtung die Konfiguration des virtuellen Servers in Bezug auf eine Übereinstimmung hinsichtlich der IP-Adresse und der Port-Nummer (Schritt 2512). wenn eine Übereinstimmung festgestellt wird, so wird einer der realen Server ausgewählt, entweder nach dem Reigenmodell, wenn es sich bei dem Protokoll um UDP handelt (Schritt 2516) oder über die Server-Hash-Funktion (oder eine modifizierte Hash-Funktion), wenn es sich bei dem Protokoll um TCP handelt (Schritt 2530). Nachdem der reale Server ausgewählt worden ist, wird das Paket an der für den realen Server konfigurierten Netzwerkschnittstelle konfiguriert sowie unter Verwendung der für den realen Server für die ARP-Hardwareadressenauflösung (ARP als englische Abkürzung von Address Resolution Protocol) ausgewählten IP-Adresse (Schritt 2526). Wenn keine derartigen realen Server für die Weiterleitung zur Verfügung stehen, wird das Paket zurückgewiesen, wobei ein Fehlerpaket "Port nicht erreichbar" (Port unreachable) des ICMP-Protokolls zurück zu dem Client übermittelt wird.
Für Anforderungen, die über das UDP-Protokoll übermittelt bzw. gesendet werden, wird jede Anforderung in einem UDP-Datagramm geführt, welches wiederum in einem einzelnen IP- Paket geführt wird. Da die Lastverteilungseinrichtung so gestaltet ist, dass sie mit dem NFS-Dateiserverprotokoll des VFCS arbeitet, wobei es bekannt ist, das jede einzelne Anforderung unabhängig ist von allen anderen Anforderungen. Somit werden IP-Pakete, welche UDP-Datagramme führen, mittels einfachem Reigenmodell unter den Servern verteilt (Schritt 2516). Wenn zum Beispiel drei Server gegeben sind, Server-1, Server-2 und Server-3, so empfängt Server-1 jedes dritte Paket.
In Bezug auf Anforderungen, die über das TCP-Protokoll gesendet werden, werden Anforderungen in TCP-Verbindungen transportiert. Die IP-Pakete, welche TCP-Verbindungsdaten führen, können nicht mittels Reigenmodell verteilt werden. Erstens besteht keine direkte Korrelation zwischen IP-Paketen, die TCP-Verbindungsdaten führen, und einzelnen Anforderungen – eine Anforderung kann auf mehrere Pakete aufgeteilt werden, und ein Paket kann mehr als eine Anforderung aufweisen. Ferner kann eine TCP-Verbindung nicht einfach zwischen Servern gemeinsam genutzt werden, indem einfach Pakete weitergeleitet werden. Somit müssen alle Pakete für eine bestimmte TCP-Verbindung zu dem gleichen Server weitergeleitet werden.
IP-Pakete, welche TCP-Verbindungen führen, werden auf der Basis der Quellen-IP-Adresse und der Quellen-TCP-Port-Nummer jedes Pakets verteilt. Da diese über die Lebensdauer einer TCP-Verbindung konstant bleiben und in jedem IP-Paket vorhanden sind, das TCP-Daten führt, werden alle Pakete der TCP-Verbindung zu dem gleichen Server verteilt.
Für die Auswahl eines Servers für die Weiterleitung des Pakets, wird die Quellen-IP-Adresse zu dem Quellen-TCP-Port hinzugefügt, und zwar als eine vorzeichenlose ganze Zahl von 32 Bit, und wobei sie danach durch die Anzahl der Server geteilt wird. Der Hashing-Algorithmus lautet: Serverindex = (Quellen-IP-Adresse + TCP Port)/Anzahl der Server in der Gruppe (Schritt 2530). Der arithmetische Rest der Division ist eine Zahl, die zwischen Null und eins weniger als die Anzahl der Server liegt. Dies wird als "Server-Hash-Funktion" bezeichnet. Wenn zum Beispiel drei Server vorhanden sind, ist das Ergebnis der Server-Hash-Funktion immer 0, 1 oder 2. Dieses Ergebnis dient als nullbasierter Index für die Auswahl eines Servers. Zum Beispiel wählt 0 den ersten Server aus, während 1 den zweiten Server auswählt, und wobei 2 den dritten Server auswählt. Hiermit wird festgestellt, dass die Lastverteilungseinrichtung keinen TCP-Verbindungsstatus aufrechterhalten bzw. speichern muss oder jegliches Wissen bzw. Informationen über aktuell offene Verbindungen, da jedes ankommende Paket die Informationen führt, die für dessen korrekte Verteilung verwendet werden.
Da die TCP-Portnummer bei einem typischen Client für aufeinander folgende CP-Verbindungen erhöht bzw. heraufgesetzt wird, werden mehrere Verbindungen von dem gleichen Client statistisch im Zeitverlauf gleichmäßig auf die Server verteilt, da die inkrementierende Port-Nummer dazu führt, dass die Server-Hash-Funktion wiederholt zyklisch verläuft. Zum Beispiel führt eine inkrementierende Port-Nummer zu einer zyklischen Reihe von Ergebnissen, wie etwa 0, 1, 2, 0, 1, 2, 0, 1, 2, etc. Da die Quellen-IP-Adresse ferner in der Server-Hash-Funktion enthalten ist, sollten Verbindungen von mehreren Clients statistisch zu unterschiedlichen Ergebnissen der Hash-Funktion führen, selbst wenn diese die gleiche TCP-Port-Nummer verwenden, da sich ihre IP-Adressen unterscheiden. Bei dieser Methode wird es versucht, eine statistisch ausgewogene Verteilung von TCP-Verbindungen über die Server vorzunehmen und somit eine statistisch ausgewogene Verteilung von Anforderungen.
Wenn ein Server ausfällt, verteilt die Lastverteilungseinrichtung neue Anforderungen an die verbleibenden Server. Für UDP-Pakete stellt dies kein Problem dar, da die Verteilung im Reigenmodell (Round Robin) erfolgt (Übergang von 2524 zu 2516). Die Pakete werden einfach im Reigenmodell auf die verbleibenden Server verteilt. Für TCP können die Pakete jedoch nicht einfach zu einem anderen Server weitergeleitet werden, da der Server die TCP-Verbindung nicht kennt bzw. keine Informationen über diese besitzt. Nachdem der Server ausgefallen ist, kann für diese TCP-Verbindungen nichts mehr getan werden. Wenn Pakete jedoch nicht um einen ausgefallenen Server zu einem anderen, aktiven bzw. laufenden Server neu verteilt werden, so schlagen die neuen TCP-Verbindungsversuche durch Clients fehl, sollten diese zu dem ausgefallenen Server verteilt werden.
Zur Behandlung dieses Problems wird eine modifizierte Hash-Funktion eingesetzt, wenn die Server-Hash-Funktion, die auf das Paket angewandt wird, zu einem ausgefallenen Server führt. Die modifizierte Hash-Funktion funktioniert wie die Server-Hash-Funktion, teilt jedoch durch die Anzahl der aktiven Server an Stelle der Anzahl aller Server. Das Ergebnis ist ein Index in die Gruppe bzw. Anordnung der aktiven Server. Dies leitet das Paket zu einem alternativen aktiven Server um, und so lange die Gruppe der aktiven Server die gleiche bleibt, werden alle Pakete an der gleichen TCP-Verbindung zu dem gleichen alternativen Server geleitet. Dies ist unter 2538 dargestellt, wobei der tote bzw. inaktive Server aus der Gruppe entfernt wird, bevor der Hash-Algorithmus in 2530 erneut angewandt wird. Hiermit wird festgestellt, dass die modifizierte Hash-Funktion angewandt wird, erst nachdem die Server-Hash-Funktion einen ausgefallenen Server ausgewählt hat. Dies beeinflusst nicht andere TCP-Verbindungen, die aktuell zu aktiven Servern geleitet werden.
Wenn die Lastverteilungseinrichtung (Load Balancer) damit beginnt, die modifizierte Hash-Funktion auf eine bestehende TCP-Verbindung anzuwenden, handelt es sich bei dem Ergebnis darum, dass Pakete, nachdem sie an einen ausgefallenen Server weitergeleitet worden sind, jetzt zu einem alternativen Server weitergeleitet werden. Dieser Server besitzt jedoch keine Informationen über die in den Paketen dargestellte TCP-Verbindung. Dies wird von dem Server als eine "halb offene" TCP-Verbindung erkannt, ein Zustand, der normalerweise an bzw. in einem TCP/IP Netzwerk auftreten kann und den das TCP-Protokoll bereits behandelt. Der alternative Server setzt die Verbindung zurück. Der Client, wenn er eine entsprechende Fehlerbehebung aufweist, öffnet eine neue TCP-Verbindung. Diese neue Verbindung, gesteuert durch die modifizierte Hash-Funktion, wird zu dem alternativen Server geöffnet. Unabhängig davon, wie lange der ursprüngliche Server außer Betrieb bleibt, sieht der Client nur eine vorübergehende Serviceunterbrechung.
Wenn sich der ausgefallene Server später erholt, führt die Server-Hash-Funktion nicht mehr zu einem ausgefallenen Server, und somit wird nicht mehr auf die modifizierte Hash-Funktion zurückgegriffen. In diesem Fall werden jetzt alle TCP-Verbindungen, die geöffnet wurden, während sie unter der Steuerung durch die modifizierte Hash-Funktion standen, jetzt zu einem anderen Server geleitet, dem durch die ursprüngliche Server-Hash-Funktion vorgegebene Server-Hash-Funktion. Wiederum interpretiert dieser Server diese Verbindungen als halb offene Verbindungen und setzt sie zurück. Alle angeschlossenen Clients erleben bzw. sehen eine vorübergehende Dienstunterbrechung. Der alternative Server, zu dem diese Verbindungen gemäß der modifizierten Hash-Funktion geöffnet worden sind, erlebt bzw. erfährt scheinbar inaktive Clients, und dies Verbindungen werden schließlich an dem Server ausgeschaltet bzw. laufen ab und werden geschlossen.
h. Server-Gesundheitsprüfungen:
Die Lastverteilungseinrichtung unterstützt zwei Verfahren der Server-Gesundheitsprüfungen. Bei dem ersten Verfahren handelt es sich um ein NFS-Protokoll NULL RPC über das UDP-Protokoll, Schritt 2524 aus 25. Bei dem zweiten Verfahren handelt es sich um eine offene TCP-Verbindung, gefolgt von einem unverzüglichen Schließen in Schritt 2538 aus 25. Wenn die Gesundheitsprüfung innerhalb eines spezifischen Zeitraums erfolgreich ist, wird angenommen, dass der Server aktiv und funktionsfähig ist. Wenn die Prüfung fehlschlägt bzw. ein negatives Ergebnis liefert, so wird davon ausgegangen, dass der Server ausgefallen ist.
Für die Gesundheitsprüfung werden drei Zeiträume konfiguriert und diese laufen für jeden Server unabhängig. Der Zeitraum "aktiv" (Up) entspricht dem Zeitraum, über den eine Gesundheitsprüfung nicht erforderlich ist. Während diesem Zeitraum werden Pakete zu dem Server weitergeleitet. Dies ist in den Schritten 2518 bis 2526 und 2532 bis 2526 aus der Abbildung aus 25 dargestellt.
Der Zeitraum "prüfen" (Check) ist der Zeitraum, über den eine Gesundheitsprüfung ausgeführt werden darf. Nachdem der Zeitraum "aktiv" abgelaufen ist, löst das nächste zu dem Server weitergeleitete Paket einen Versuch zur Gesundheitsprüfung aus, und der Zeitraum "prüfen" wird gestartet bzw. beginnt. Während dem Zeitraum "prüfen" werden Pakete weiter zu dem ausgewählten Server weitergeleitet. Dies ist in den Schritten 2520, 2522, 2534, 2536 und 2526 aus der Abbildung aus 25 dargestellt.
Der Zeitraum "inaktiv" (Dead) ist der Zeitraum bevor eine erneute Prüfung eines ausgefallenen Servers erfolgt. Wenn die Gesundheitsprüfung erfolgreich ist, bevor der Prüfzeitraum abgelaufen ist, so beginnt ein neuer Zeitraum "aktiv". Wenn die Gesundheitsprüfung hingegen fehlschlägt oder der Prüfzeitraum abläuft, so beginnt der Zeitraum "inaktiv". Jeder Beginn des Zeitraums "aktiv" löst einen neuen Versuch der Gesundheitsprüfung aus. Nachdem der Zeitraum "inaktiv" abgelaufen ist, löst das nächste Paket, das zu diesem Server weitergeleitet worden wäre (über die Server modifizierte Hash-Funktion vor dem Aufrufen der modifizierten Hash-Funktion), eine Prüfung bzw. Untersuchung des Ergebnisses der Gesundheitsprüfung aus, Siehe dazu die Schritte 2524– 2516 und 2538–2530 aus der Abbildung aus 25, und entweder einen Übergang zu dem Zeitraum "aktiv" oder einen Neustart des Zeitraums "inaktiv" (mit dem Starten einer neuen Gesundheitsprüfung). Ein Server in dem Zeitraum "aktiv" oder "prüfen" gilt als aktiv und gesund. Ein Server in dem Zeitraum "inaktiv" gilt als ausgefallen.
Die Abbildung aus 26 zeigt ein Flussdiagramm 2600 einer Gesundheitsprüfungsfolge (Schritte 2652–2660). Wenn eine Gesundheitsprüfung fehlschlägt oder der Prüfzeitraum ausläuft, beginnt der inaktive Zeitraum des Servers, 2652, 2656 und 2654 aus 26. Ansonsten beginnt der aktive Zeitraum des Servers, 2658 aus 26, bis dieser abgeschlossen ist (Schritt 2660).
Die Zeiträume und Ergebnisse der Gesundheitsprüfungen werden nur geprüft, wenn Pakete ankommen, und sie werden zu dem Server geleitet (entweder im Reigenmodell, durch die Server-Hash-Funktion oder durch die modifizierte Hash-Funktion). Die Pakete dienen als Ereignisse, um die Gesundheitsprüfungsfolge weiter nach vorne zu bringen.
4. Die Steuereinheitdatenspeicher und Verwaltungsteilsysteme
Die Abbildung aus 27 zeigt eine Darstellung der Steuereinheit und Daten einer Station 2700 in dem SCDN 100 gemäß einem Ausführungsbeispiel der vorliegenden Erfindung. Die Station 2700 weist die Steuereinheit 2710 und die Datenspeicher 2730 auf. Die Steuereinheit 2710 kann ein eingebettetes System darstellen, das in einem Ausführungsbeispiel der vorliegenden Erfindung vier Steuerteilsysteme aufweist. Die Abbildung aus 27 identifiziert die Teilsysteme der Steuereinheit und die Datenspeicher einer Station. Die Steuereinheit 2710 weist ein Ressourcenverwaltungs-Teilsystem 2712, ein Lernteilsystem 2714, ein Speicherverwaltungsteilsystem 2716 und ein Serviceverwaltungsteilsystem 2719 auf, die gemeinsam als Steuerungsteilsysteme bezeichnet werden. Der Datenspeicher 2730 in der Station weist einen Netzwerkressourcenspeicher 2732, einen Stammdaten- und Statistikressourcenspeicher 2734, einen Ereignisressourcenspeicher 2736 und einen Inhaltsspeicher 2738 auf.
Das Serviceverwaltungsteilsystem 2718 der Steuereinheit überwacht und verwaltet die DS und VFCS Server der Station. Das Ressourcenverwaltungs-Teilsystem 2712 unterstützt SCDN-Netzwerk- und Service- bzw. Dienstkonfigurationen und Protkoll- und Nutzungsdaten-Roll-Up-Aktivitäten. Das Lernteilsystem 2714 unterstützt die automatische Initialisierung, das inkrementale Lernen bzw. Erlernen von Inhalten und andere adaptive Methoden zur Verwaltung und Steuerung der Station. Das Speicherverwaltungs-Teilsystem 2716 überwacht die Cluster-Speichernutzung, unterstützt das Rating und Pruning von Inhalten und meldet dem CMS 170 die Speichernutzung jedes Inhalteeigentümers. Das Serviceverwaltungs-Teilsystem 2718 überwacht und steuert Dienste auf der Basis von Schwellenwerteinstellungen, gibt SNMP-Traps (SNMP als englische Abkürzung von Simple Network Management Protocol) aus, exportiert Enterprise MIBs (Verwaltungsinformationsbanken) und exportiert Stamm-, Statistik- und Ereignisdaten. Für den Durchschnittsfachmann auf dem Gebiet ist es ersichtlich, dass die hierin beschriebenen Funktionen aus Gründen der Praktikabilität eingesetzt werden, und dass weitere Funktionen hinzugefügt, subtrahiert oder ersetzt werden können, sofern diese zu einer effizienten und zuverlässigen Steuerung und Verwaltung der SCDN-Station führen.
a. Speicherverwaltungsinformationsbank
Das Speicherverwaltungs-Teilsystem 2716 verwaltet in einem Ausführungsbeispiel der vorliegenden Erfindung eine Informationsbank in einer relationalen Datenbank mit der Bezeichnung SM_DB, welche sich an dem CU befindet. Ferner wird auf die Abbildung aus 30 verwiesen, welche beispielhafte Speicherverwaltungs-Informationsbanktabellen (3005, 3015, 3025, 3035, 3045) und Datenträgermetadaten 3023, Dateimetadaten 3033 sowie Spurdateimetadaten 3043 veranschaulicht. In dieser Datenbank gibt es sieben Datenbanktabellen:

• Tabelle DS Log
• Tabelle Nutzungs-Log
• Tabelle Datenträgerinfo
• Tabelle Dateiinfo
• Tabelle Spurinfo
• Tabelle Speicheralarm-Log
• Tabelle SM Prüfungs-Log

Diese Tabellen werden nachstehend im Text beschrieben:
i. Tabelle DS Log
Die Tabelle DS Log 3005 oder Prism_DS_Log weist Datensätze für zahlreiche der Ereignisse oder Befehle auf, die von dem Verteilungsserver bearbeitet bzw. behandelt werden. Sie wird von dein Verteilungsserver-Teilsystem verwaltet. Wenn der DS etwaige dieser sechs FDP-Befehle verarbeitet, protokolliert er die vollständige Ausführung des Ereignisses an die Datenbank.

Die Felder der Tabelle Prism_DS_Log sind wie folgt gegeben:

FELD	BEDEUTUNG
CommandType	Entweder: INFO, PUT, REPLICATE, PREPARE, REMOVE oder CLEAN
InfoCategory	Entweder: CPUDATE, CPRESERVE, CPDELETE oder FILEUPDATE
Direction	Eingehend oder Abgehend
NetworkID	Die eindeutige ID des Netzwerks, wo dieser Datenträger seinen Ursprung hat
VolumeID	Die eindeutige ID des Datenträgers in dem Netzwerk
FileID	Die eindeutige ID der Datei in dem Netzwerk
TrackIndex	Der Index dieser Spur
ByteCount	Anzahl der betroffenen Bytes insgesamt, soweit zutreffend
Status	OK oder Fehlercode
OriginTime	Zeitpunkt, zu dem das Paket ursprünglich gesendet worden ist
StartTime	Zeitpunkt, zu dem die Ausführung des Befehls begonnen hat
EndTime	Zeitpunkt, zu dem die Ausführung des Befehls abgeschlossen war

ii. Tabelle Nutzungs-Log
Das VFCS (wie etwa das VFCS 470, 600, 1800) ist zuständig dafür, den Inhalt über eine Dateisystemschnittstelle wie etwa NFS und CIFS bereitzustellen. Wenn das VFCS eine Anforderung für einen Datenblock empfängt, wird das Ereignis als eine Datei protokolliert. Die Granularität der Protokollierung ist konfigurierbar. Wenn auf das erste Byte einer Datei zugegriffen wird, erfolgt eine Aktualisierung der letzten Zugriffszeit/des letzten Zugriffsdatums des Inhalts mit der aktuellen Zeit. Die Tabelle Nutzungs-Log 3015 oder Prism_Usage_Log weist einen Datensatz für jede durch ein VFCS erfüllte "Leseanforderung" auf. Eine "Leseanforderung" ist definiert als jede Dateioperation, die das Lesen des ersten Bytes ("Byte 0") der Datei aufweist. Die Tabelle Nutzungs-Log wird von dem VFCS-Teilsystem zur Aufzeichnung der Dateinutzung verwaltet (d. h. Anforderungen der Datei).

Die Felder in der Tabelle Nutzungs-Log 3015 sind wie folgt gegeben:

FELD	BEDEUTUNG
RequestTime	Zeitpunkt, zu dem die Anforderung "Lesen" von dem VFCS empfangen worden ist
DataSource	Identifizieren einer Datenquelle (das Feld kann auch ungenutzt bleiben)
RequestorIp	Identifizieren einer IP-Adresse des Anforderers (das Feld kann auch ungenutzt bleiben)
NetworkId	Die eindeutige ID des Netzwerks, wo dieser Datenträger seinen Ursprung hat
VolumeId	Die eindeutige ID des Datenträgers in dem Netzwerk
FileID	Die eindeutige ID der Datei in dem Netzwerk

iii. Die Tabelle VolumeInfo (Datenträgerinfo)
Die Tabellen VolumeInfo, FileInfo und TrackInfo (3025, 3035, 3045) sind den VFCS Metadatendateien für die gleichen Objekte ähnlich (Datenträgermetadatendateien 3023, Dateimetadatendatei 3033 und Spurdateimetadaten 3043), wobei sie jedoch Daten auslassen, die nicht relevant sind für die Speicherverwaltungsaufgaben, und sie weisen andere bzw. weitere dynamische Daten auf, die für die Speicherverwaltungsaufgaben besonders sind.

Die Tabelle VolumeInfo 3025 weist einen Datensatz für jeden Datenträger auf. Die Felder in jedem Datensatz VolumeInfo sind wie folgt gegeben:

FELD	BEDEUTUNG
NetworkId	Die eindeutige ID des Netzwerks, wo dieser Datenträger seinen Ursprung hat
VolumeId	Die eindeutige ID des Datenträgers in dem Netzwerk
CurrentUsage	Die Gesamtgröße aller Blockdateien, die sich zu diesem Zeitpunkt an dieser Station im Speicher befinden
ReservedSpace	Der maximale Speicherplatz, den der Datenträger zu einem bestimmten Zeitpunkt an dieser Station beleben darf
AssignedStation	Die ID der Ursprungsstation für diesen Datenträger
PruningThreshold	Ein prozentualer Anteil des reservierten Raums bzw. Platzes, so dass für den Fall dass CurrentUsage einmal über diesem Wert liegt, der Speichermanager im nächsten Pruning-Zyklus ausreichend Blockdateien wieder zurück bereinigt, um CurrentUsage wieder unter diesen Wert zu führen.
AlarmThreshold	Ein prozentualer Anteil des reservierten Raums bzw. Platzes, so dass für den Fall, dass CurrentUsage einmal über diesen Wert ansteigt, sendet der Speichermanager eine Alarmmitteilung an die CMS-Anwendung, und dem Eigentümer wird es untersagt bzw. ist nicht befugt, weitere Dateien in das System einzuführen, bis CurrentUsage (aktuelle Nutzung) wieder zurück unter diesen Wert gebracht worden ist.

Die Tabelle VolumeInfo 3025 kann Daten aufweisen, die aus der Datenträgermetadatendatei 3023 kopiert worden sind, wie dies durch den Pfeil 3020 dargestellt ist.
iv. Die Tabelle FileInfo (Dateiinfo)

Die Tabelle FileInfo 3035 weist einen Datensatz für jede an dieser Station bekannte Datei auf. Die Tabelle FileInfo 3035 kann Daten aufweisen, die aus dem Nutzungs-Log bzw. Nutzungsprotokoll 3010 kopiert worden sind und Dateimetadaten 3033, wie dies durch die Pfeile 3010 und 3030 dargestellt ist. Die Felder jedes Datensatzes FileInfo sind wie folgt gegeben:

FELD	BEDEUTUNG
NetworkId	Die eindeutige ID des Netzwerks, wo diese Datei ihren Ursprung hat
VolumeId	Die eindeutige ID (in dem Netzwerk) des Datenträgers, dem diese Datei gehört
FileID	Die eindeutige ID dieser Datei in dem Netzwerk
TrackCount	Die Anzahl der Spuren (Tracks), in welche diese Datei zerlegt worden ist
BlockSize	Die Größe (in Bytes) jeder Blockdatei für diese Datei (der letzte Block jeder Spur kann kleiner sein als dieser)
Duration (Dauer)	Die Dauer oder "Wiedergabezeit" dieser Datei, sofern dies zutreffend ist
Popularity	Die prognostizierte oder erwartete Nachfrage nach dieser Datei auf einer Skala von 0 bis 10.
ExpirationDate	Das Datum, an dem diese Datei ausläuft bzw. verfällt (die genau Zeit des Ablaufs ist 23:59:59 GMT an diesem Datum). Die Datei wird während dem ersten Pruning-Zyklus am ersten Tag ORTSzeit NACH der genauen Ablaufzeit von jeder lokalen Station entfernt.
FirstUsed	Zeitpunkt der ersten Anforderung dieser Datei durch einen Benutzer (innerhalb des von Usage Log abgedeckten Zeitraums)
LastUsed	Zeitpunkt der letzten (zeitlich am kürzesten zurück liegenden) Anforderung dieser Datei (innerhalb des Zeitraums).
UseCount	Die Häufigkeit der Anforderung der Datei (innerhalb des Zeitraums)

v. Die Tabelle TrackInfo (Spurinfo)

Die Tabelle TrackInfo 3045 enthält einen Datensatz für jede Spur jeder an dieser Station bekannten Datei. Die Tabelle TrackInfo 3045 kann Daten aufweisen, die aus den Metadaten TrackFile 3043 kopiert werden, wie dies durch den Pfeil 3040 dargestellt ist. Die Felder jedes Datensatzes TrackInfo sind wie folgt gegeben:

FELD	BEDEUTUNG
NetworkId	Die eindeutige ID des Netzwerks, wo diese Datei ihren Ursprung hat
VolumeId	Die eindeutige ID (in dem Netzwerk) des Datenträgers
FileID	Die eindeutige ID dieser Datei in dem Netzwerk
TrackIndex	Der Index dieser Spur
TrackLength	Die ganze Größe dieser Spur
CurrentSize	Die gesamte Größe aller Blockdateien, die sich aktuell im Speicher befinden
MinRetainSize	Die Mindestgröße, auf welche diese Spur beschnitten werden soll
BlockSize	Die Größe jeder Blockdatei dieser Spur (unter Umständen mit Ausnahme des letzten Blocks)
Truncatable	Boolscher Wert, der anzeigt, ob überhaupt Blöcke aus dieser Spur entfernt bzw. beschnitten werden können

vi. Die Tabelle Speicheralarm-Log (Storage Alarm Log)

Die Tabelle Speicheralarm-Log weist einen Eintrag für jedes Mal auf, wenn ein Datenträger in einen Alarmzustand eintritt oder diesen verlässt. Ein Datenträger befindet sich in einem Alarmzustand, wenn die aktuelle Speichernutzung den Alarmschwellenwert überschreitet. Die Felder des Speicheralarm-Log sind wie folgt gegeben:

FELD	BEDEUTUNG
NetworkId	Die eindeutige ID des Netzwerks, wo diese Datei ihren Ursprung hat
VolumeId	Die eindeutige ID (in dem Netzwerk) des Datenträgers, dem diese Datei gehört
UpdateTime	Der Zeitpunkt, zu dem dieser Datensatz erstellt worden ist
CurrentUsage	Die Anzahl der Speicherbytes, welche der Datenträger zum Zeitpunkt der Aktualisierung genutzt hat
ReservedSpace	Die Anzahl der Speicherbytes, welche der Datenträger reserviert hat
AlarmState	Ob sich der Datenträger IN oder NICHT IN einem Alarmzustand befindet (wahr oder falsch)

vii. Die Tabelle Speicherverwaltungs-Prüf-Log
Die Tabelle Speicherverwaltungs-Prüf-Log weist die folgenden Datensatzfelder auf:
Lokaler Netzwerkspeicher insgesamt
Speichergröße insgesamt
Lokale Netzwerkspeichernutzung und -verfügbarkeit insgesamt
Speichernutzung = Summe der vollständigen Speicherdatenträgergröße – Summe der vollständigen Datenträgerspeichernutzung.
5. Optimierte Speicherverwaltung
a. Die Rolle der Speicherverwaltung
Wenn Inhalt veröffentlicht wird, wird die vollständige Datei im Ganzen oder ein Teil dieser an die Speichervorrichtungen im ganzen Netzwerk verteilt. Wenn eine Inhaltsdatei von einem Benutzer über VFCS angefordert wird, werden nicht residente Datenblöcke für die angeforderte Datei von anderen DS in die lokalen Speichervorrichtungen importiert. Das Importieren von Datenblöcken füllt letztlich den lokalen Speicher, was es erforderlich macht, das bestimmte weniger genutzte Inhalte gelöscht werden, um Platz für die neu importierten Blicke zu schaffen. Somit muss die Speichernutzung an jedem Verteilungszentrum sorgfältig überwacht und verwaltet werden, so dass die Speichernutzung optimiert wird.
Das Löschen von weniger beliebten Inhalten, um Platz für beliebtere Inhalte zu schaffen, wird als "Pruning" bezeichnet. Es ist die Aufgabe des Speicherverwaltungsteilsystems 2716, das auch als Speichermanager (Storage Manager) bezeichnet wird, das Pruning nach Bedarf auszuführen. Für die Verwaltung der Speichervorrichtungen, müssen die Speicherverfügbarkeit, die Benutzernachfrage und die Datenimportaktivitäten alle überwacht werden, so dass eine präzise Prognose der Daten, für welche ein Zugriff am wahrscheinlichsten ist, vorgenommen werden kann, und so dass lokale Speichervorrichtungen so angepasst werden können, dass sie nur die beliebtesten Inhalte speichern.
Der Speichermanager 2716 überwacht ferner die Speichernutzung jedes Datenträgers insgesamt. Er meldet dem Content Management Server (CMS 170) die Speichernutzung eines Datenträgers. Er meldet einem CMS ferner, wenn die Speichernutzung eines Datenträgers die reservierte Quote übersteigt.
Um Speicherverwaltungsentscheidungen zu treffen, überwacht der Speichermanager 2716 folgendes: 1) die Speicherverfügbarkeit insgesamt; 2) die Datenträgerspeicherreservierung und -informationen; 3) die Speicheraktivitäten für einen Datenträgerspeicherplatzraum; 4) die Speicheraktivitäten in der Station; 5) die Nutzung von Inhalten; 6) die Netzwerksituationen; und 7) die Attribute des Inhalts. Er entscheidet, wann er bestimmte Inhalte entfernen muss, um Platz für neue oder beliebtere Inhalte zu schaffen. Er entscheidet ferner darüber, welche und wie viele Datenblöcke entfernt werden sollen. Verschiedene unterschiedliche intelligente Algorithmen können eingesetzt werden, um Inhaltsblöcke für das Pruning gemäß Ausführungsbeispielen der vorliegenden Erfindung auszuwählen.
Wenn festgestellt wird, dass ein oder mehrere Datenträger (Volumen) sich oberhalb ihres Speicherschwellenwertes befindet bzw. befinden, wird der Inhalt in den Datenträgern untersucht und nach "Pruning-Fähigkeit" geordnet. Ein Inhalt gilt als Pruning-fähig, wenn er beschnitten werden kann, nicht auf seine zulässige Mindestgröße reduziert worden ist und zurzeit nicht verwendet wird (siehe unten). Diese Inhalte, die Pruning-fähig sind, werden für das Pruning geordnet (priorisiert), um eine ausgewählte Kostenfunktion zu optimieren. Zum Beispiel kann die Ordnung bzw. Sortierung abhängig von der Netzwerkkostenstruktur des Datenträgers mit dem Ziel vorgenommen werden, die Gesamtanzahl von Bytes des Netzwerkverkehrs für den Datenträger zu minimieren. Alternativ kann es Ziel der Rangordnung sein, lediglich die Spitzenbandbreitennutzung für den Datenträger zu minimieren oder eine Kostenfunktion zu minimieren, die eine mathematische Kombination dieser und anderer Faktoren darstellt, wie zum Beispiel des rechenbetonten Overheads oder der Lastverteilung über das gesamte Netzwerk.
Die Rangordnung umfasst das Analysieren der Informationen in der Informationsbank bzw. der Wissensbank, das heißt des aktuellen Status und des Nutzungsverlaufs des Inhalts. Unter Verwendung all dieser verfügbaren Informationen werden die unterschiedlichen Inhalte gemäß ihrer wahrscheinlichen Auswirkung auf die ausgewählte Kostenfunktion sortiert bzw. angeordnet. Wenn es sich bei der Kostenfunktion zum Beispiel nur um den Netzwerkverkehr insgesamt (in Bytes) handelt, so gilt ein Inhalt mehr Pruning-fähig als ein anderer Inhalt, wenn es für ihn weniger wahrscheinlich ist, dass er wieder angefordert wird (er wird weniger häufig verwendet). Bin Algorithmus zur seltensten Verwendung (Least Frequently Used) kann für diese Kostenfunktion eingesetzt werden. Die Indexe der sortierten Ergebnisse werden entweder in einer Datenbank oder einer Datei gespeichert, so dass mehrere Speichermanager einen gemeinsamen Zugriff auf die Ergebnisse ihrer Berechnungen aufweisen.
Der Speichermanager 2716 verwendet einen beliebigen einer Reihe von Algorithmen, welche die Nutzungsdaten untersuchen und bestimmen, welcher Inhalt die ausgewählte Kostenfunktion optimiert. Die Architektur ermöglicht das Hinzufügen neuer Algorithmen. Zusätzlich zu einem LFU-Algorithmus (Least Frequently Used Algorithmus) unterstützt der Speichermanager 2716 aktuell die Algorithmen Least Recently Used (LRU), Least Frequently Used Capped (LFUCapped), Lest Recently Used K-times (LRU-2, LRU-3, ...), Uniform Decay (UD) und ein Zufallsauswahlalgorithmus. Der LRU versucht die gleiche Kostenfunktion zu optimieren wie LFU (Netzwerkverkehr insgesamt), wobei jedoch ein Teil des Ziels geopfert wird im Austausch für eine bessere Recheneffizienz. LRU-K ist ein rechenbetonter Kompromiss zwischen LFU und LRU. LFUCapped ist eine auf den Zählwert begrenzte Version von LFU, welche empfindlicher sein möchte in Bezug auf Veränderungen der Popularität bzw. der Beliebtheit des Inhalts im Zeitverlauf. UD weist das Ziel der Reduzierung der Variabilität der Netzwerknutzung auf, so dass der resultierende Netzwerkverkehr ein höheres Gesamtvolumen aufweisen kann, jedoch im Zeitverlauf gleichmäßiger verteilt wird.
Der Speichermanager 2716 wechselt zwischen Algorithmen, wenn er bestimmt, dass bestimmte Netzwerkbedingungen oder Nutzungsmuster eine temporäre Präferenz für einen Algorithmus gegenüber einem anderen anzeigen. Der Speichermanager 2716 kann automatisch und/oder manuell zwischen Algorithmen wechseln als Reaktion auf die Auswahl eines Administrators oder eines Benutzers.
Das Maß des Pruning, das heißt, wie viel Pruning erfolgen soll, kann ebenfalls geregelt werden. Der Speichermanager 2716 erzeugt eine sortierte Liste von Inhalten, die nach Pruning-Fähigkeit geordnet werden. Durch das Besuchen jedes Inhaltsobjekts der Reihe nach, beginnend mit dem Objekt mit der größten Pruning-Fähigkeit, löscht er eine bestimmte Anzahl von Datenblöcken aus jedem Inhalt. Er stoppt diesen Prozess, wenn eine ausreichende Anzahl von Bytes einem Pruning unterzogen worden ist, um die Gesamtnutzung des Datenträgers auf ein akzeptables Maß zu senken – das unterhalb des Pruning-Schwellenwerts liegt. Die Anzahl der Datenblöcke, die er aus einem bestimmten Inhalt löscht, wird auf der Basis der ausgewählten Kostenfunktion und des Algorithmus berechnet.
Die meisten Algorithmen führen ein Pruning einer variablen Anzahl von Blockdateien aus jeder Pruning-fähigen Inhaltsdatei aus. Ein Algorithmus "Uniform Decay" kann zum Beispiel jedoch eingesetzt werden, welcher nur einen kleinen Teil jeder Pruning-fähigen Inhaltsdatei einem Pruning unterzieht, so dass die Gesamtanzahl an Bytes, die einem Pruning unterzogen werden müssen, so einheitlich wie möglich allen Pruning-fähigen Inhalten entnommen werden. Als Folge dessen neigt im Zeitverlauf jeder Inhalt eines Datenträgers dazu, dass daraus eine Menge gelöscht wird, die umgekehrt proportional ist zu dessen Häufigkeit der Verwendung. Je seltener ein Inhalt verwendet wird, desto mehr Bytes des Inhalts werden nicht lokal gespeichert. Es lässt sich mathematisch zeigen, dass diese Anordnung bei bestimmten Anwendungen zu einer geringeren Variabilität (statistische Varianz bzw. Abweichung) in dem Netzwerkverkehr führt. Die Fähigkeit für das Pruning von Inhaltsabschnitten bzw. Inhaltsteilen ermöglicht es einem Speichermanager 2716, die bestimmte Optimierung auszuführen.
Wie wird das Pruning ausgeführt?
Wenn der Speichermanager 2716 entscheidet, eine Inhaltsdatei einem Pruning zu unterziehen, wird die Datei genau untersucht bzw. geprüft, um den richtigen Bereich der Blöcke zu bestimmen, die entfernt werden sollen. Ein Pruning-Modell ist das Entfernen der Blöcke nur von dem Ende (temporär) der Datei. Ein weiteres Modell ist die Entfernung von Blöcken, beginnend mit Blocknummer (n + 1), wobei die Blöcke 1 bis n die entsprechende Anzahl der mindestens gespeicherten Blöcke darstellen.
Nachdem der Entfernungsbereich bestimmt worden ist, gibt der Speichermanager 2716 einen Befehl FDP REMOVE an den DS aus. Der Speichermanager 2716 aktualisiert nicht seine Informationsbank, bis nicht alle Blöcke tatsächlich durch den DS entfernt werden und der DS die Entfernung in dem DS-Log bzw. dem DS-Protokoll protokolliert hat.
Schutz während dem Einsatz
Wenn bestimmt wird, dass ein Inhalt eingesetzt wird, versucht der Speichermanager 2716 nicht, davon etwas zu löschen, d. h. die Datei wird nicht durch einen Pruning-Algorithmus untersucht.
In einem Beispiel gilt ein Inhalt als sich im Einsatz befindend, wenn die folgende Bedingung erfüllt ist:
Aktuelle Zeit < Anfangszeit des Ansehens + max(Inhaltsdauer·Einsatzfaktor, Inhaltsdauer + minPufferimEinsatz).
In bestimmten Situationen kann der Speichermanager 2716 bestimmen, dass der Inhalt Pruning-fähig ist, und während diesem Prozess kann der Inhalt in den Einsatz gelangen. Um es zu verhindern, dass Inhalte gelöscht werden, wurde eine Sicherheitsmaßnahme ergriffen, wodurch der DS verifiziert, dass sich der Inhalt nicht im Einsatz befindet, bevor die Löschung ausgeführt wird. Diese Sicherheitsmaßnahmen können Datenträgerspeichersicherheitsschwellenwerte für den Inhalt aufweisen, wie etwa ein Alarmschwellenwert und ein Pruning-Schwellenwert. Jeder Schwellenwert stellt einen prozentualen Anteil der reservierten Speichergröße des Datenträgers dar; wobei der prozentuale Anteil konfigurierbar ist.
Die Funktionsweise des Speichermanagement-Teilsystems bzw. des Speicherverwaltungs-Teilsystems 2716 wird später im Text beschrieben.
b. Überblick über den Speicherverwaltungszyklus
Das Speicherverwaltungs-Teilsystem 2716 läuft ununterbrochen in einer Endlosschleife. Jeder vollständige Schleifendurchlauf wird als Zyklus bzw. Pruning-Zyklus bezeichnet. Die Abbildung aus 28 zeigt ein Ausführungsbeispiel des Zustandsdiagramms eines Speicherverwaltungszyklus der vorliegenden Erfindung (Schritte 2810–2870). Der Speichermanager 2716 verarbeitet periodisch die DS- und VFCS Aktivitätsprotokolle, um dessen Informationsbank zu aktualisieren und die erforderlichen Maßnahmen zu ergreifen, um den lokalen Speicher zu verwalten. Der maximale Zeitraum zwischen Zyklen ist konfigurierbar. Die in jedem Schritt eines Pruning-Zyklus ausgeführte Verarbeitung wird nachstehend wie folgt beschrieben:

• Schritt 0: (2870 aus 28) Ruhen über einen ausreichend langen Zeitraum, so dass ausreichend Aktivität aufgetreten sein kann, um einen weiteren Pruning-Zyklus nützlich zu machen, wobei der Zeitraum aber auch ausreichend kurz sein muss, so dass es unwahrscheinlich ist, dass ein Datenträger die Kapazität von 100% erreicht hat.
• Schritt 1: (2810 aus 28) Scannen des DS-Log auf Ereignisse, die Veränderungen von Informationen über Datenträger, Dateien oder Spurdateien bewirken oder von Parametern, die Datenträgern, Dateien oder Spurdateien zugeordnet sind. Für jedes "berührte" Objekt wird die Speicherverwaltungs-Informationsbank mit aus den VFCS Metadaten gewonnenen aktuellen Daten aktualisiert.
• Schritt 2: (2820 aus 28) Einmal täglich oder immer dann, wenn die Ablaufdaten von Dateien modifiziert worden sind, wird auf Dateien geprüft, die vor dem aktuellen Datum des Tages abgelaufen sind, und wobei diese Dateien gelöscht werden.
• Schritt 3: (2830 aus 28) Berechnen der aktuellen Speichernutzung jedes Datenträgers als prozentualer Anteil des reservierten Speicherplatzes des Datenträgers. Warnmeldung an CMS senden für jeden Datenträger, dessen prozentualer Nutzungsanteil den Alarmschwellenwert erreicht hat. Aufstellen einer Liste von Datenträgern, deren prozentuale Nutzung den Pruning-Schwellenwert überschritten hat.
• Schritt 4: (2840 aus 28) Für jeden Datenträger, dessen Speichernutzung über dem Pruning-Schwellenwert liegt wird entschieden, welche Blöcke welcher Dateien gelöscht werden sollen, um die Speichernutzung wieder sicher unter den Pruning-Schwellenwert zu bringen.
• Schritt 5: (2850 aus 28) Ausgeben von FDP-Befehlen REMOVE (Entfernen) an den DS, um die ausgewählten Blöcke zu erntfernen. Der DS stellt diese Befehle unabhängig von dem Speichermanager in die Warteschlange ein und verarbeitet sie später.
• Schritt 6: (2860 aus 28) Datenträgernutzungsstatistiken an CMS melden.

Der in der Abbildung aus 28 dargestellte Speicherverwaltungszyklus kann in mehreren Vorrichtungen implementiert werden als mehrere Prozesse, die parallel ausgeführt werden, während sie die gleiche Informations- bzw. Wissensbank nutzen.
Jeder der Schritte (oder Zustände) des Speicherverwaltungszyklus aus der Abbildung aus 28 wird später im Text in Bezug auf zusätzliche Implementierungen der vorliegenden Erfindung näher beschrieben. Die Abbildungen der 29A–29E zeigen zusätzliche Unterschritte zur Ausführung der Schritte 1 bis 6 (d. h. der Schritte 2810–2860).
c. Bestimmung des Ruheintervalls zwischen Pruning-Zyklen
Es folgt eine Beschreibung von Schritt 2 aus 28 (Schritt 2800) gemäß einem Ausführungsbeispiel der vorliegenden Erfindung. Vor Beginn jedes neuen Pruning-Zyklus wird ein Algorithmus angewandt, um zu entscheiden, ob der Zyklus unverzüglich beginnen soll oder ob bis zu dem Beginn einen bestimmten Zeitraum lang "geruht" (gewartet) werden soll. Wenn ein Inhaltsdatenträger den Pruning-Schwellenwert in dem vorherigen Zyklus überschritten hat (was bedeutet, dass ein bestimmter Inhalt einem Pruning unterzogen werden musste, um die aktuelle Nutzung dieses Datenträgers auf einen Wert unterhalb des Schwellenwerts zu senken), so beginnt der nächste Zyklus unverzüglich. Wenn in dem vorherigen Zyklus für keinen Datenträger ein Pruning erforderlich gewesen ist, so ruht der Datenträger eine Weile bevor mit dem nächsten Zyklus begonnen wird. Die Dauer des Ruhezustands basiert darauf, wie lange es her ist, seit das letzte Pruning erforderlich gewesen ist. Je länger es zurückliegt, dass ein Pruning erforderlich gewesen ist, desto länger ist der Ruhezustand, maximal bis zu einem bestimmten maximalen Ruheintervall. Das maximale Ruheintervall stellt einen konfigurierbaren Parameter dar. Für den Fachmann auf dem Gebiet ist es unter Berücksichtigung der vorliegenden Beschreibung offensichtlich, dass ein höherer Algorithmus an dieser Stelle eingesetzt werden kann, um einen sicheren Zeitraum für den Ruhezustand zu schätzen bzw. zu prognostizieren, der das Risiko minimieren würde, dass ein Datenträger 100% des für ihn reservierten Speicherplatzes füllt, während sich der Speichermanager 2716 im Ruhezustand befindet.
d. Aktualisierung der Informationsbank
Es folgt eine Beschreibung von Schritt 2 (2810) aus 28 gemäß der Implementierung in einem Ausführungsbeispiel der vorliegenden Erfindung. Zu den dabei aktualisierten Informationen zählen die Speichernutzung des Inhaltsdatenträgers, die Inhaltsnutzung, die Datenträgerliste und Informationen, die Inhaltsdateiliste und Informationen, die aktuellen Bandbreitenkosten, die Kosten für die Übertragung jeder Inhaltsdatei, die tatsächliche Popularität der Inhalte, die optimale Speichergröße für jeden Inhalt und die Pruning-Fähigkeit der Inhalte. Die Unterschritte in diesem Zustand sind in dem Diagramm aus der Abbildung aus 29A dargestellt und werden nachstehend wie folgt beschrieben:

• (2911) Lesen des DS-Log für alle INFO-Befehle: die Arten der INFO-Befehle, die erfasst werden, lauten CPUdate (neue oder überarbeitete Daten zu einem Datenträger), ResUpdate (neue oder überarbeitete Speicherreservierung für einen Datenträger), CPDelete (Löschen eines Datenträgers) und FileUpdate (neue oder überarbeitete Daten zu einer Datei).
• (2912) Für jeden Datenträger, der von einem Info-Befehl betroffen ist, wird der Eintrag dieses Datenträgers in der Tabelle VolumeInfo aktualisiert, indem die Metadaten für den Datenträger aus dem VFCS gelesen werden. Für jede betroffene Datei wird der Eintrag in der Tabelle FileInfo für diese Datei aktualisiert, indem die aktuellen VFCS Metadaten für diese Datei gelesen werden.
• (2913) Lesen des DS-Log für alle Ereignisse, welche die aktuelle Größe von Dateien beeinflussen können. Derartige Ereignisse sind PUT, REPLICATE, PREPARE, REMOVE und CLEAN, die jeweils eine ganze Datei oder eine Spur in einer Datei beeinflussen.
• (2914) Für jede betroffene Spurdatei oder Datei wird der entsprechende Eintrag in der entsprechenden Tabelle TrackInfo oder FileInfo aktualisiert, indem die aktuellen Metadaten aus dem VFCS gelesen werden.

e. Abgelaufene Inhalte entfernen
Es folgt eine Beschreibung von Schritt 2 (2820) aus 28. Die Unterschritte sind in der Abbildung aus 29B als Diagramm dargestellt und werden nachstehend wie folgt beschrieben:

• (2921 & 2922) Bestimmen, ob der Zeitpunkt gekommen ist, um eine Prüfung hinsichtlich eines Dateiablaufs vorzunehmen. Dies ist der Fall, wenn an diesem Kalendertag noch keine Prüfung in Bezug auf abgelaufene Dateien vorgenommen worden ist (2921) oder wenn ein Teil der Dateiinformationen nach der letzten Prüfung aktualisiert worden ist (2922). Wenn keine dieser Bedingungen zutrifft, wird mit diesen Schritten nicht fortgefahren.
• (2923) Aus der Tabelle FileInfo eine Liste aller Dateien einholen, deren Ablaufdatum vor dem aktuellen Datum lag. (Das "Ablaufdatum" ist der letzte Tag, an dem die Datei gültig ist, so dass die Datei erst nach dem Ablaufdatum gelöscht wird.)
• (2924) Für jede abgelaufene Datei wird ein FDP-Befehl REMOVE an den DS ausgegeben, um die Datei zu entfernen.

f. Bestimmen, ob ein Pruning erforderlich ist
Es folgt eine Beschreibung von Schritt 3 (2830) aus 28. Untersuchen der Speicherverfügbarkeit und der Inhaltsdatenträgerreservierung, um zu bestimmen, ob ein Pruning in diesen Zyklus erforderlich ist. Die Unter- bzw. Teilschritte sind in der Abbildung aus 29C in Diagrammform dargestellt und werden nachstehend wie folgt beschrieben:

• (2931) Neue Berechnung des Felds CurrentUsage (aktuelle Nutzung) in der Tabelle VolumeInfo für jeden Datenträger auf der Basis der Summe aller Werte für die aktuelle Größe für alle Spurdateien, die allen Dateien zugeordnet sind, die zu diesem Datenträger gehören.
• (2932) Abfrage der Tabelle VolumeInfo in Bezug auf eine Liste aller Datenträger, deren aktuelle Nutzung oberhalb deren Alarmschwellenwerts liegt. Der Alarmschwellenwert für jeden Datenträger ist ein bestimmter prozentualer Anteil des reservierten Speicherplatzes dieses Datenträgers, wie zum Beispiel 90%.
• (2933) Für jeden Datenträger, dessen Nutzung den Alarmschwellenwert überschreitet, wird ein Alarmdatensatz in der Tabelle StorageAlarmLog (Speicheralarm-Log) gesetzt. (Ein separater Prozess nimmt diesen Eintrag auf und leitet ihn an den CMS an der dem Datenträger zugeordneten Station weiter).
• (2934) Abfrage der Tabelle VolumeInfo in Bezug auf eine Liste aller Datenträger, deren aktuelle Nutzung deren Pruning-Schwellenwert überschreitet. Der Pruning-Schwellenwert für jeden Datenträger ist ein bestimmter prozentualer Anteil des reservierten Speicherplatzes dieses Datenträgers an der Station, wie zum Beispiel 80%.

g. Aktualisierung des Inhaltsnutzungsverlaufs
Dies ist der erste Abschnitt von Schritt 4 (2840) aus 28. Immer, wenn bestimmt wird, dass ein oder mehrere Datenträger ein Pruning benötigen, erfolgt ein einzelner Durchlauf durch die Nutzungs-Log-Tabelle, um die Einträge zu löschen, die älter sind als ein bestimmter Zeitraum. Diese hilft dabei, sicherzustellen, dass das Nutzungs-Log bzw. Nutzungsprotokoll nicht zu groß wird. Im Allgemeinen werden Nutzungsdaten nur für die letzten 30 Tage zurückverfolgt bzw. überwacht, wobei jedoch der Zeitraum, über den die Überwachung erfolgt, einen konfigurierbaren Parameter darstellt.
h. Priorisierung von Inhalten für das Pruning
Es folgt eine Beschreibung des Rests von Schritt 4 (2840) aus 28. Die Unterschritte sind in der Abbildung aus 29D in Diagrammform dargestellt und werden nachstehend beschrieben. Diese Schritte werden für jeden Datenträger aus der in dem Schritt 2934 aus 29C erzeugten Liste wiederholt, das heißt, für jeden Datenträger, dessen Speichernutzung oberhalb des Schwellenwertes liegt:

• (2941) Aktualisieren der Nutzungszusammenfassungsinformationen in der Tabelle FileInfo für alle Dateien, die diesem Datenträger angehören, auf der Basis der Daten in der Nutzungs-Log-Tabelle. Die Felder FirstUsed, LastUsed und UsageCount in der Tabelle FileInfo werden für jede Datei aktualisiert, die diesem Datenträger angehört.
• (2942) Auswahl der Dateirangordnungskriterien und der Dateischutzkriterien. Die Dateirangordnungskriterien stellen eines der Kriterien LRU, LFU, UD, LRU-k oder anderer vorstehend beschriebener Kriterien dar. Die Schutzkriterien gelten für Dateien oder Dateiabschnitte. Wenn dieser Schritt zum ersten Mal ausgeführt wird, werden Dateien, die sich im Einsatz befinden und Dateien, die erst sehr kürzlich eingeführt worden sind, werden vor einem Pruning geschützt, d. h. sie werden nicht in die Kandidatenliste aufgenommen. Ferner wird ein anfänglicher Abschnitt jeder Spur jeder Datei in der Kandidatenliste geschützt, so dass Benutzer in der Lage sind, mit einer Latenz von Null auf Dateien zuzugreifen, selbst wenn der Rest jeder Spur einem Pruning unterzogen wird. In folgenden Runden werden die Schutzkriterien gelockert, so dass mehr Dateien Kandidaten werden und mehr Bytes jeder Kandidatendatei werden für das Pruning in Betracht gezogen: zuerst werden die Latenschutzvorkehrungen aufgehoben, danach wird der Schutz der zuletzt hinzufügten Dateien aufgehoben und schließlich wird der Schutz während dem Einsatz aufgehoben.
• (2943) Nutzung der Daten in der Tabelle FileInfo, um eine sortierte bzw. geordnete Liste von Kandidatendateien zu erstellen, die für das Pruning zur Verfügung stehen. Die Rangordnung basiert auf den in 2942 festgelegten Kriterien.
• (2944) Wenn die Kandidatenliste leer ist, erfolgt ein Rücksprung zu dem Schritt 2942 und eine Lockerung der Schutzkriterien, so dass mehr Dateien in eine neue Kandidatenliste aufgenommen werden. Im anderen Fall erfolgt ein Sprung zu 2945.
• (2945) Die obere bzw. führende Datei wird der Kandidatenliste aus Schritt 2943 entnommen. Ein Löschziel für die Datei wird festgelegt (eine Zielanzahl von Bytes, die mittels Pruning versucht werden, daraus zu entfernen) und es wird versucht daraus Blöcke zu löschen, welche insgesamt diese vielen Bytes ergeben (Schritt 5 (2850) aus 28 gemäß der nachstehenden Beschreibung). Das Löschziel ist abhängig von der Anzahl an Bytes, die noch erforderlich sind, um die Nutzung des Datenträgers unter den Schwellenwert zu senken sowie in Bezug auf die Rangordnungs- und Schutzkriterien, die in 2942 festgelegt worden sind. Algorithmen können das Löschziel so hoch wie möglich festlegen (100% der Datei), so dass so viel wie möglich einer Kandidatendatei einem Pruning unterzogen wird, bevor die nächste Datei aus der Kandidatenliste einem Pruning unterzogen wird. Der Algorithmus Uniform Decay (einheitlicher Verfall) versucht jedoch einige Bytes aus jeder Kandidatendatei einem Pruning zu unterziehen, und zwar auf eine Art und Weise, so dass die aus jeder Datei einem Pruning unterzogene Menge umgekehrt proportional ist zu der Häufigkeit der Nutzung der Datei.
• (2946) Wenn die kumulative Anzahl von Bytes, die erfolgreich aus allen Kandidatendateien gelöscht worden sind, die bislang besucht wurden, ausreicht, um die Nutzung des Datenträgers unter den Pruning-Schwellenwert zu senken, wird das Pruning ausgefürt (2947). Ansonsten kehrt die Steuerung zurück zu dem Schritt 2944, um die nächste Kandidatendatei für das Pruning zu untersuchen.

i. Blockdateien entfernen
Es folgt eine Beschreibung von Schritt 5 (2850) aus 28, aufgerufen aus 2945 aus 29D, wobei wir versuchen, Blockdateien zu löschen, die insgesamt eine bestimmte Anzahl von Bytes einer bestimmten Datei entsprechen. Wenn die Datei mehrere Tracks bzw. Spuren aufweist, können Blockdateien aus mehreren Spuren gelöscht werden. Die einfachste Strategie, die bei einer Implementierung der vorliegenden Erfindung eingesetzt wird, ist es, nacheinander jede Spur zu besuchen und mit der Auswahl von Blöcken fortzufahren, bis entweder keine Blöcke mehr aus dieser Spur gelöscht werden können oder bis die Gesamtgröße aller bislang ausgewählten Blöcke ausreicht, um das Löschziel zu erreichen. Nach der Auswahl, welche Blöcke einer Spur einem Pruning unterzogen werden sollen, gibt der Speichermanager einen FDP-Befehl "Remove" aus, um die tatsächliche Entfernung der ausgewählten Blöcke auszuführen.
Die Schritte für die Entscheidung, wie viele und welche Blöcke aus einer bestimmten Spur- bzw. Track-Dateie einem Pruning unterzogen werden sollen, sind in der Abbildung aus 29E in Diagrammform dargestellt und werden nachstehend im Text wie folgt beschrieben:

• (2951) Bestimmen der zulässigen Mindestgröße (als MinRetainSize bezeichnet) für die Spur auf der Basis des Dateityps und der Schutzkriterien, die in 2942 aus 29D festgelegt worden sind. Die MinRetainSize ist in allen Fällen gleich 0, ausgenommen dann, wenn der Latenzschutz aktiv ist und es sich bei der Datei um eine Mediendatei oder einen anderen Dateityp handelt. Für den Fall, dass die Datei in der Tabelle TrackInfo NICHT als trunkierbar gekennzeichnet ist, stellt die MinRetainSize die ganze Spur dar (die Datei kann in keiner Weise einem Pruning ausgesetzt werden). Im anderen Fall entspricht MinRetainSize dem Maximum von: i) einer bestimmten festen Anzahl von Bytes, ii) einem bestimmten festen prozentualen Anteil der Spur, iii) ausreichend Bytes für die Unterstützung des Streaming der ersten S Sekunden der Datei, wobei S eine feste Anzahl von Sekunden bezeichnet (die Gesamtdauer D der Datei ist aus der Tabelle FileInfo bekannt, so dass der Anteil S/D der Spur für S Sekunden ausreichen sollte.

Diese festen Anzahlen aus i), ii) und iii) stellen alle konfigurierbaren Parameter dar. In einem anderen Ausführungsbeispiel der vorliegenden Erfindung kann S dynamisch angepasst werden auf der Basis der gemessenen und prognostizierten Netzwerklatenz zwischen dieser Station und anderen Stationen. Nach der Berechnung von MinRetainSize muss diese auf eine ganze Anzahl von Blöcken aufgerundet werden. Dies wird in geeigneter Weise unter Verwendung der folgenden ganzzahligen Operationen berechnet: MinRetatinSize = ((MinRetainSize + BlockSize – 1)BlockSize)·BlockSize(BlockSize = Blockgröße).

• Berechnen der verfügbaren Größe der Spur (AvailableSize) als aktuelle Größe (CurrentSize) – MinRetainSize. Dabei handelt es sich um die Mindestanzahl von Bytes, die wir hoffen, aus dieser Spur löschen zu können. Der Wert der CurrentSize steht in der Tabelle TrackInfo zur Verfügung oder kann aus den Metadaten TrackFile gewonnen werden.
• Wenn AvailableSize <= 0, so kann an dieser Spur kein Pruning vorgenommen werden.
• Anpassen des Löschziels für diese Spur nach unten, sofern dies erforderlich ist, so dass das Ziel nicht größer ist als die AvailableSize.
• Aus den Metadaten der Spurdatei eine "Bitmap" erhalten, die angibt, welche Blockdateien dieser Spur sich aktuell im Speicher befinden. Diese Bitmap ist eine Anordnung von "0ern" und "1ern", indexiert von 0 bis N – 1, wobei N der Anzahl von Blöcken in der Spur entspricht, wobei ein Wert von "0" anzeigt, dass der Block aktuell nicht im Speicher enthalten ist, und wobei eine "1" anzeigt, dass sich der Block aktuell im Speicher befindet. Zum Beispiel: 111111111110011101110101110111111111100000000000
• Unter Verwendung der vorstehenden Bitmap werden die Anfangs- und Endblockindizes iStart und iEnd bestimmt, so dass iStart ausreichend "1er" (Blöcke, die vorhanden sind) aufweist, BEVOR es die MinRetainSize Bytes aufweist, die NICHT gelöscht werden, und es gibt ausreichend "1er" ZWISCHEN iStart und iEnd inklusive, um das Löschziel zu erfüllen. Dies ist möglich, da das Löschziel nicht größer ist (oder so angepasst wurde, dass es nicht größer ist) als die AvailableSize. Eine konkrete Methode, um iStart und iEnd auszuwählen, die in einem Ausführungsbeispiel der Erfindung eingesetzt wird, ist es, zuerst iEnd gleich dem Indes der letzten "1" in der Bitmap zu setzen, wobei iStart danach rückwärts abgetastet wird, beginnend bei iEnd, bis ausreichend "1er" gezählt worden sind, um das Löschziel zu erreichen. Diese Methode bewirkt, dass die Spurdateien stets "von dem Ende" einem Pruning ausgesetzt werden können. Andere Ausführungsbeispiele der vorliegenden erfindung können anders vorgehen, wie zum Beispiel indem iStart zuerst auf den Mindestindex gesetzt wird, der weiter MinRetainSize Bytes vorher aufweist, und wobei danach iEnd vorwärts abgetastet wird, bis ausreichend "1er" gezählt worden sind, um das Löschziel zu erreichen.
• Ausgabe eines FDP-Befehls REMOVE an den DS, wobei dieser aufgefordert wird, alle Blöcke von iStart bis iEnd (inklusive) aus dieser Spur dieser Datei zu entfernen. (Einige dieser Blöcke können bereits nicht mehr vorhanden sein, wobei diese redundanten Löschungsanforderungen jedoch unschädlich sind.)
• Hinzufügen der Anzahl von Bytes, die tatsächlich aus der Spur gelöscht worden sind, zu der kumulativen Summe aller Bytes, die aus dieser Datei gelöscht worden sind.

j. Datenträgerspeichernutzung an deren CMS melden
Es folgt eine Beschreibung von Schritt 6 (2860) aus 28. Die CMS-Adresse eines Datenträgers wird in der Datenträgertabelle in dem Inhaltsspeicher gespeichert. Wenn eine Speichernutzung des Inhaltsdatenträgers den Alarmschwellenwert übersteigt und der Speichermanager keinen der Inhaltsblöcke entfernen kann, die zu dem Datenträger gehören, so benachrichtigt der Speichermanager den CMS des Datenträgers und den Netzwerkbetreiber. Nach Empfang der Benachrichtigung bzw. Mitteilung verhindert der CMS, dass der Inhalteeigentümer mehr Inhalt hochlädt, ohne dem Datenträger zusätzlichen reservierten Speicherplatz hinzuzufügen. Wenn die Nutzung des Datenträgerspeichers unter den Alarmschwellenwert sinkt, benachrichtigt der Speichermanager den CMS hinsichtlich der Aufhebung der Upload-Beschränkung.
Während dem gesamten Verwaltungszyklus meldet der Speichermanager ferner Fehler, Warnungen und die Speichernutzungsstatistiken insgesamt an das Servicemanaagement-Teilsystem.
Der Speichermanager stellt sicher, dass der Speicherplatz insgesamt ausreichend groß ist für den insgesamt reservierten Speicherplatz für den Inhaltsdatenträger. Dies wird durchgesetzt mithilfe der Kooperation des CMS und des lernenden Agenten bzw. des Lernagenten an einer Station. Der Speichermanager informiert den CMS bezüglich der Speichernutzung jedes Datenträgers. Er sendet ferner eine Alarm- bzw. Warnmeldung an den CMS, wenn sich eine Datenträgernutzung jenseits des Sicherheitsschwellenwertes befindet. Der CMS kann es verhindern, dass der Inhalteeigentümer bzw. Content Owner des Datenträgers dem Netzwerk neue Inhalte hinzufügt. Der lernende Agent kann dessen Lernen von Inhalten aussetzen, wenn ein Datenträger dessen Quote überschreitet.
6. Rechenumgebung
Die vorliegende Erfindung kann in Software, Hardware oder einer Kombination beider implementiert werden sowie unter Verwendung eines oder mehrerer Computersysteme oder Verarbeitungssysteme. Ein Beispiel für ein Computersystem, das eingesetzt werden kann, um zum Beispiel einen Content Management Server 170, einen Content Provider Client 130, einen Verteilungsserver in einem Cluster DSC 410, eine Steuereinheit 450, einen Anwendungsserver, ein VFCS 470, 1800 oder jede andere Rechenplattform zu implementieren (hierin auch als "Maschinen", "Vorrichtungen", "Geräte" oder "Server" bezeichnet), ist das Computersystem 3100, das in der Abbildung aus 31 dargestellt ist. Das Computersystem 3100 weist einen oder mehrere Prozessoren auf, wie etwa den Prozessor 3104. Der Prozessor 3104 ist mit einer Kommunikationsinfrastruktur 3106 (z. B. einem Bus oder einem Netzwerk) verbunden. Verschiedene Ausführungsbeispiele können in Bezug auf dieses beispielhafte Computersystem beschrieben werden. Nach dem Lesen der vorliegenden Beschreibung ist es für den Fachmann auf dem Gebiet jedoch erkennbar, wie die Erfindung unter Verwendung anderer Computersysteme und/oder Computerarchitekturen implementiert werden kann.
Das Computersystem 3100 kann auch einen Hauptspeicher 3108 aufweisen, vorzugsweise einen Direktzugriffsspeicher (RAM), und es kann ferner einen sekundären Speicher 3110 aufweisen. Der sekundäre Speicher 3110 kann zum Beispiel ein Festplattenlaufwerk 3112 und/oder ein entfernbares bzw. Wechselspeicherlaufwerk 3114 aufweisen, das ein Floppy-Diskettenlaufwerk, ein Magnetbandlaufwerk, ein optisches Plattenlaufwerk, etc. darstellt. Das Wechselspeicherlaufwerk 3114 liest aus einer entfernbaren bzw. Wechselspeichereinheit 3118 bzw. beschreibt diese auf allgemein bekannte Art und Weise. Die Wechselspeichereinheit 3118 stellt eine Floppy-Diskette, ein Magnetband, eine optische Disk, etc. dar. Wie dies erkennbar ist, weist die Wechselspeichereinheit 3118 ein in einem Computer einsetzbares Speichermedium auf, auf dem Computersoftware und/oder Daten gespeichert sind.
Der sekundäre Speicher 3110 kann auch weitere ähnliche Einrichtungen aufweisen, die es ermöglichen, dass Computerprogramme oder Eingabedaten in das Computersystem 3100 geladen werden. Zu derartigen Einrichtungen können zum Beispiel eine Wechselspeichereinheit 3122 und eine Schnittstelle 3120 zählen. Zu den Beispielen dafür zählen eine Programmkassette und eine Kassettenschnittstelle (wie diese etwa in Videospielvorrichtungen vorhanden sind), ein Wechselspeicherchip (wie etwa ein EPROM oder PROM) und ein zugeordneter Steckplatz sowie sonstige Wechselspeichereinheiten 3122 und Schnittstellen 3120, die es ermöglichen, dass Software und Daten von der Wechselspeichereinheit 3122 zu dem Computersystem 3100 übertragen werden.
Das Computersystem 3100 kann ferner eine Kommunikationsschnittstelle 3124 aufweisen. Die Kommunikationsschnittstelle 3124 ermöglicht es, dass Software und Daten zwischen dem Computersystem 3100 und externen Vorrichtungen übertragen werden. Zu den Beispielen für die Kommunikationsschnittstelle 3124 können unter anderem ein Modem, eine Netzwerkkarte (z. B. eine Ethernet-Karte), ein Kommunikations-Port, ein PCMCIA-Steckplatz und eine PCMCIA-Karte, etc. zählen. Software und Daten, die über die Kommunikationsschnittstelle 3124 übertragen werden, sind in Form von Signalen 3128 gegeben, bei denen es sich um elektronische, elektromagnetische, optische oder andere Signale handeln kann, die von der Kommunikationsschnittstelle 3124 empfangen werden können. Diese Signale 3128 werden an die Kommunikationsschnittstelle 3124 über einen Kommunikationspfad (d. h. Kanal) 3126 bereitgestellt. Dieser Kanal 3126 führt Signale 3128 in das und aus dem Computersystem 3100 und kann implementiert werden unter Verwendung von Draht oder Kabel, Lichtwellenleitern, einer Telefonleitung, eines Mobiltelefonvermittlungsabschnitts, eines HF-Links und sonstiger Kommunikationskanäle.
In einem Ausführungsbeispiel der vorliegenden Erfindung können die Signale 3128 Inhalte oder verschiedene Signale, die von Prozessen erzeugt werden, die auf dem Computersystem 3100 erzeugt werden, übermitteln, um Blockdateien zu erfassen bzw. zu senden und um das Zusammensetzen einer Nutzlast zu verwalten.
In dem vorliegenden Dokument werden die Begriffe "Computerprogrammmedium" und "in einem Computer einsetzbares Medium" eingesetzt, um allgemein Medien zu bezeichnen, wie etwa ein Wechselspeicherlaufwerk 3114, eine in einem Festplattenlaufwerk 3112 installierte Festplatte und die Signale 3128. Diese Computerprogrammprodukte sind Einrichtungen, die Software an das Computersystem 3100 bereitstellen. Die vorliegende Erfindung weist derartige Computerprogrammprodukte auf.
Computerprogramme (auch als Computersteuerlogik bezeichnet) werden in dem Hauptspeicher 3108 und/oder dem sekundären Speicher 3110 gespeichert. Die Computerprogramme können auch über die Kommunikationsschnittstelle 3124 empfangen werden. Wenn derartige Computerprogramme ausgeführt werden, ermöglichen sie es, dass das Computersystem 3100 die Merkmale der vorliegenden Erfindung ausführt, wie dies hierin beschrieben ist. Im Besonderen ermöglichen es die Computerprogramme, wenn sie ausgeführt werden, dass der Prozessor 3104 die Merkmale der vorliegenden Erfindung ausführt. Folglich stellen derartige Computerprogramme Steuereinheiten des Computersystems 3100 dar.
D. Schlussfolgerung
Zu den Vorteilen der vorliegenden Erfindung zählen die Fähigkeiten, Dateisystemobjekte von jedem Knoten eines Netzwerks von Knoten zu speichern, zu verteilen, zu verwalten und zu synchronisieren, ohne die Darstellung des Objekts an den Benutzer zu verzögern, wobei aber auch gleichzeitig nur ein Mindestmaß an Speicherplatz erforderlich ist. Die Erfindung ermöglicht die Festlegung und Durchsetzung von Servicequalitätsrichtlinien über eine generische Dateisystemschnittstelle. Die Erfindung integriert Speichervorrichtungen und Dateisysteme in einem lokalen oder Wide Area-Netzwerk und sorgt dafür, dass die Vorrichtungen als eine mit einer integrierten Dateisystemansicht funktionieren. Ein Dateisystemserver gemäß der vorliegenden Erfindung ist in der Lage, ein "selektives und dynamisches Caching" auszuführen, um Endbenutzern eine riesige Bibliothek von Inhalten bereitzustellen, mit begrenzten Speicher- und Netzwerkressourcen. Die Dateiserver sind zu Clustern zusammengefasst, die durch eine zustandslose Lastverteilungseinrichtung unterstützt werden können.
Die vorstehende Beschreibung der Ausführungsbeispiele dient dazu, es Fachleuten auf dem Gebiet zu ermöglichen, die vorliegende Erfindung zu implementieren oder zu nutzen. Die Erfindung wurde zwar speziell in Bezug auf deren Ausführungsbeispiele dargestellt und beschrieben, wobei hiermit für den Fachmann auf dem Gebiet festgestellt wird, dass verschiedene Abänderungen in Bezug auf Ausführung und Einzelheiten diesbezüglich vorgenommen werden können, ohne dabei vom Umfang der vorliegenden Erfindung abzuweichen, der durch die folgenden Ansprüche definiert ist.

Claims

Verfahren zur effizienten Speicherverwaltung (420) in einem verteilten Netzwerk (100) mit einer Mehrzahl von verbundenen Knoten, wobei das Verfahren die folgenden Schritte umfasst: das Bestimmen (2830, 2934), wenn ein bestimmter Dateispeicherparameter einen Pruning-Schwellenwert überschreitet; und das Ausführen eines Pruning-Zyklus, wobei dies folgendes aufweist: (a) das Identifizieren (2840) der dem Speicher zugeordneten Inhaltskomponenten; (b) das selektive Pruning (2850) der Inhaltskomponenten zumindest teilweise auf der Basis der Nutzungsstatistik, so dass der Dateispeicherparameter auf einen Wert unterhalb des Pruning-Schwellenwerts reduziert wird; und (c) das Aktualisieren von Metadaten (2860), die den Inhaltskomponenten zugeordnet sind, um die aktualisierten Speichersystemparameter zu reflektieren; gekennzeichnet durch: (d) das Präsentieren des Inhalts des aktualisierten Speichernetzwerks als ein virtuelles Dateisystem, so dass alle Dateien für jeden Knoten lokal zugänglich erscheinen.
Verfahren nach Anspruch 1, wobei dieses ferner den folgenden Schritt umfasst: das Bereitstellen der Dateien an Benutzer unabhängig von der physikalischen Position der Inahltskomponenten.
Verfahren nach Anspruch 2, wobei dieses ferner den folgenden Schritt umfasst: das Bereitstellen der Dateien an Benutzer mit der gleichen Rate, wie dies möglich wäre, wenn die ganze Datei lokal gespeichert werden würde.
Verfahren nach Anspruch 3, wobei: der Schritt des Bereitstellens weniger Netzwerkübertragungsverkehr insgesamt erfordert, als wie dieser erforderlich wäre, wenn die ganze Datei über einen einzigen Knoten dem Benutzer bereitgestellt werden würde.
Verfahren nach Anspruch 2, wobei: der Schritt des Bereitstellens parallel zu dem Pruning-Schritt ausgeführt wird.