DE112019005038T5 - Ressourcenzuweisung unter verwendung von guthaben mit verteilter segmentverarbeitung - Google Patents

Ressourcenzuweisung unter verwendung von guthaben mit verteilter segmentverarbeitung Download PDF

Info

Publication number
DE112019005038T5
DE112019005038T5 DE112019005038.9T DE112019005038T DE112019005038T5 DE 112019005038 T5 DE112019005038 T5 DE 112019005038T5 DE 112019005038 T DE112019005038 T DE 112019005038T DE 112019005038 T5 DE112019005038 T5 DE 112019005038T5
Authority
DE
Germany
Prior art keywords
credits
client
segment
server
streams
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE112019005038.9T
Other languages
English (en)
Inventor
Keyur B. Desai
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
EMC Corp
Original Assignee
EMC IP Holding Co LLC
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by EMC IP Holding Co LLC filed Critical EMC IP Holding Co LLC
Publication of DE112019005038T5 publication Critical patent/DE112019005038T5/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/78—Architectures of resource allocation
    • H04L47/783—Distributed allocation of resources, e.g. bandwidth brokers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90—Details of database functions independent of the retrieved data types
    • G06F16/907—Retrieval characterised by using metadata, e.g. metadata not derived from the content or metadata generated manually
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/82—Miscellaneous aspects
    • H04L47/822—Collecting or measuring resource availability data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/5013—Request control
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/504—Resource capping
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0638—Organizing or formatting or addressing of data
    • G06F3/064—Management of blocks
    • G06F3/0641—De-duplication techniques
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Abstract

Systeme und Verfahren zum Zuweisen von Ressourcen werden offenbart. Ressourcen wie Verarbeitungszeit, Schreibvorgänge oder Lesevorgänge werden zugewiesen. Guthaben werden an die Clients auf eine Weise ausgegeben, durch die sichergestellt ist, dass das System in einem sicheren Zuweisungsstatus arbeitet. Die Guthaben können nicht nur zum Zuweisen von Ressourcen verwendet werden, sondern bei Bedarf auch zum Drosseln von Clients. Guthaben können vollständig, partiell und in einer Anzahl, die größer als angefragt ist, gewährt werden. Null- oder negative Guthaben können ebenfalls ausgegeben werden, um Clients zu drosseln. Segmentguthaben sind mit der Identifizierung eindeutiger Fingerabdrücke oder Segmente verbunden und können zugewiesen werden, indem bestimmt wird, wie viele Guthaben eine CPU/Kerne unterstützen kann bzw. können. Diese maximale Anzahl kann auf Clients aufgeteilt werden, die mit dem Server verbunden sind.

Description

  • GEBIET DER ERFINDUNG
  • Ausführungsformen der vorliegenden Erfindung beziehen sich auf Systeme und Verfahren zum Zuweisen von Ressourcen. Ausführungsformen der Erfindung beziehen sich im Besonderen auf Systeme und Verfahren zur Ressourcenzuweisung bei der Durchführung von Datenschutzoperationen, wie z.B. verteilter Segmentverarbeitung (DSP [Distributed Segment Processing]) und/oder Deduplizierung. Anlage A ist Teil der vorliegenden Offenbarung und durch diese Bezugnahme hierin in ihrer Gesamtheit aufgenommen.
  • HINTERGRUND
  • In einem einzelnen Knoten oder einer verteilten/Scale-Out-Cluster-Umgebung kann das Zuweisen von Ressourcen eine herausfordernde Aufgabe sein. Die Aufgabe wird noch komplizierter, wenn der Versuch unternommen wird, sicherzustellen, dass die Ressourcen unter Verwendung der verfügbaren Ressourcen allen Clients gerecht zugewiesen werden. Zum Beispiel sollte ein Client nicht über einen ungerechtfertigt großen Anteil der verfügbaren Ressourcen verfügen können. Gleichzeitig besteht die Notwendigkeit, die Anforderungen hinsichtlich der Dienstgüte (QOS [Quality of Service]) zu erfüllen.
  • Im Speziellen sind Datenschutzoperationen (z.B. Sichern, Wiederherstellen) häufig mit Problemen bei der Ressourcenzuweisung sowie Fragen der Dienstgüte (QOS) verbunden. Diese Probleme treten auf, wenn einige Clients zu viele Ressourcen verwenden und andere Clients daher vernachlässigt werden oder nicht in der Lage sind, die erforderlichen Ressourcen zu erwerben. Zudem leidet die QOS häufig, wenn der Bedarf an Ressourcen höher ist als das, was der Knoten oder Cluster bewältigen kann. Um diesen Umstand zu vermeiden oder diesen Umstand zu korrigieren, besteht die Notwendigkeit, Anfragen von einem bestimmten Client zu einem bestimmten Zeitpunkt zu drosseln. Folglich sind Systeme und Verfahren zum gerechten Zuweisen von Ressourcen erforderlich, wobei gleichzeitig die Anforderungen hinsichtlich der Dienstgüte sichergestellt oder erfüllt werden.
  • Figurenliste
  • Um die Art und Weise zu beschreiben, in der zumindest manche Aspekte dieser Offenbarung erlangt werden können, wird eine speziellere Beschreibung unter Bezugnahme auf spezifische Ausführungsformen davon geliefert, welche in den beigefügten Zeichnungen dargestellt sind. In dem Verständnis, dass diese Zeichnungen nur beispielhafte Ausführungsformen der Erfindung darstellen und daher nicht als Einschränkung ihres Umfangs anzusehen sind, werden Ausführungsformen der Erfindung mit zusätzlicher Spezifität und Detailgenauigkeit unter Verwendung der beigefügten Zeichnungen beschrieben und erläutert, in denen:
    • 1 ein Beispiel für einen Server veranschaulicht, der konfiguriert ist, um Clients Ressourcen zuzuweisen;
    • 2 ein Beispiel für einen Client veranschaulicht, der Segmentguthaben nutzt, um Daten an einen Server zu übertragen;
    • 3 ein Beispiel für ein Verfahren zum Zuweisen von Ressourcen veranschaulicht, einschließlich einer Verarbeitung oder Schreiboperationen in einem Server oder Cluster;
    • 4 ein Beispiel für ein Verfahren zum Verwenden von Guthaben ist, die von einem Server oder Cluster gewährt wurden;
    • 5 ein Beispiel für ein Verfahren zum Durchführen einer Ressourcenzuweisung während einer Datenschutzoperation, wie z.B. Segmentverarbeitung, ist;
    • 6 eine Ressourcenzuweisung, einschließlich einer Streamzuweisung im Rahmen von Cluster- oder Serverressourcen, näher veranschaulicht;
    • 7A ein Beispiel für ein Verfahren zum Durchführen einer Ressourcenzuweisung und insbesondere zum Zuweisen von Streams in einer Datenverarbeitungsumgebung veranschaulicht; und
    • 7B ein Beispiel für ein Verfahren zum Auswerten eines Streamzuweisungsstatus eines Knotens oder eines Servers oder eines Clusters veranschaulicht; und
    • 7C das Verfahren zum Auswerten des Streamzuweisungsstatus der 7B näher veranschaulicht.
  • DETAILLIERTE BESCHREIBUNG EINIGER BEISPIELHAFTER AUSFÜHRUNGSFORMEN
  • Ausführungsformen der Erfindung beziehen sich auf Systeme und Verfahren zum Durchführen von Datenschutzoperationen. Beispiele für Datenschutzoperationen umfassen Ressourcenzuweisungsoperationen, einschließlich Streamzuweisungen, Lesezuweisungen, Segmentverarbeitungszuweisungen oder dergleichen, ohne darauf beschränkt zu sein. Datenschutzoperationen können auch Sicherungsvorgänge, Wiederherstellungsvorgänge, Deduplizierungsvorgänge, Spiegelungsvorgänge, Datenreplikationsvorgänge und dergleichen oder eine Kombination davon umfassen.
  • Ausführungsformen der Erfindung beziehen sich auf Systeme und Verfahren zum Zuweisen von Ressourcen in einer Datenverarbeitungsumgebung. Ausführungsformen der Erfindung beziehen sich ferner auf Systeme und Verfahren zum Messen und Verbessern der Dienstgüte und zum Drosseln von Clients im Rahmen einer Ressourcenzuweisung. Ausführungsformen der Erfindung beziehen sich ferner auf Systeme und Verfahren zum Zuweisen von Streams zu Clients und zum Zuweisen von Guthaben mit verteilter Segmentverarbeitung (DSP).
  • In einem Beispiel kann ein Cluster von Servern (oder ein einzelner Server oder Knoten) über Ressourcen verfügen, die Clients zugewiesen werden können. Diese Ressourcen umfassen Streams, Lesevorgänge, Schreibvorgänge, Verarbeitung, Deduplizierung oder dergleichen. Ein bestimmter Server kann beispielsweise eine Anzahl von x Streams oder eine bestimmte Anzahl von Lese-/Schreibvorgängen bereitstellen. Ein bestimmter Server oder Cluster kann in der Lage sein, ein bestimmtes Ausmaß an Verarbeitung, z.B. verteilter Segmentverarbeitung (DSP), durchzuführen, wobei dies selbständig oder als Teil einer anderen Datenschutzoperation, wie z.B. eines Sicherungsvorgangs und/oder eines Deduplizierungsvorgangs, erfolgen kann. Insgesamt kann der Cluster auch eine größere Anzahl von Streams, Lese-/Schreibvorgängen und Verarbeitung bereitstellen. Ausführungsformen der Erfindung beziehen sich auf Systeme und Verfahren zum Zuweisen dieser Ressourcen.
  • Beispielsweise beziehen sich Ausführungsformen der Erfindung ferner auf Systeme und Verfahren zum Aufnehmen von Daten in einen Server. Das Aufnehmen von Daten kann das Deduplizieren der Daten, das Übertragen der Daten und das Schreiben der Daten in eine Sicherung umfassen. Im Speziellen kann der Client während mancher Datenschutzoperationen (Sicherung, Deduplizierung etc.) nur eindeutige Daten oder Daten, die vom Sicherungsserver zuvor nicht gespeichert wurden, an den Server senden.
  • Ausführungsformen der Erfindung beziehen sich somit auf das Zuweisen von DSP-Guthaben, die von Clients zur Durchführung einer verteilten Segmentverarbeitung verwendet werden können.
  • In einem Beispiel können die DSP-Guthaben mit Stream-Guthaben kombiniert werden. Stream-Guthaben beziehen sich typischerweise auf Datenströme zwischen Clients und Servern. Diese Guthaben können gemeinsam verwendet werden. Alternativ können die DSP-Guthaben auch Streaming-Ressourcen begründen oder umgekehrt.
  • 1 veranschaulicht ein Beispiel für eine Datenverarbeitungsumgebung, in der Clients mit einem Server (oder einem Cluster) kommunizieren. In diesem Beispiel umfassen die dem Client zugewiesenen Ressourcen die Ressourcen 122. Ein Client könnte in der Lage sein, die Ressourcen 122 von einem oder mehreren Servern zu nutzen. Ein Server kann ebenso mehrere Clients mit den Ressourcen 122 versorgen.
  • Diese Ressourcen 122 können Leseressourcen, Schreibressourcen, Verarbeitungsressourcen, Segmentverarbeitungsressourcen, Streamressourcen oder dergleichen oder eine Kombination davon umfassen. Die Ressourcen 122 werden so zugewiesen, dass der Server oder Cluster in einem sicheren Zuweisungsstatus arbeitet. Ein sicherer Zuweisungsstatus ist ein solcher, in dem alle Ressourcenanfragen gewährt und bis zur Fertigstellung bedient werden können. Dies kann mittels eines Guthabensystems erzielt werden. Um mehreren Szenarien gerecht zu werden, gibt es verschiedene Typen von Guthaben, die gewährt werden können. Jeder Typ kann sich jedoch auf die Ressourcen beziehen, die zugewiesen werden. Die verschiedenen Typen von Guthaben stehen gewissermaßen für eine unterschiedliche Antwort auf Guthabenanfragen. Das Guthabensystem kann verwendet werden, um verschiedene Typen von Ressourcen zuzuweisen und/oder um mehrere Ressourcen gleichzeitig zuzuweisen.
  • Die Anzahl der vom Server oder Cluster gewährten Guthaben kann beispielsweise gleich wie die Anzahl der angeforderten Guthaben, kleiner als die Anzahl der angeforderten Guthaben, größer als die Anzahl der angeforderten Guthaben, null oder negativ sein. Durch Ausgabe von Null- oder negativen Guthaben wird es dem Server ermöglicht, Ressourcen voll zu nutzen, bei Bedarf aber auch zu drosseln. Dadurch wird es dem Server oder Cluster auch ermöglicht, einen unsicheren Status zu überwinden und in einen sicheren Zuweisungsstatus zurückzukehren. Die Guthaben können beispielsweise wie folgt beschrieben werden:
    • Prefetch-Guthaben: Mehr als die Anzahl der von Clients angeforderten Guthaben.
    • Partielle Guthaben: Weniger als (jedoch mehr als 0) die Anzahl der von Clients angeforderten Guthaben.
    • Gleiche Guthaben: Gleich wie die Anzahl der von Clients angeforderten Guthaben. Null-Guthaben: Gleich null, was darauf hinweist, dass die aktuelle Clientanfrage nicht verarbeitet werden kann. Der Client muss warten und erneut versuchen, Guthaben zu erlangen.
    • Negative Guthaben: Eine negative Zahl, die den Client darauf hinweist, die Anzahl der zwischengespeicherten Guthaben freizugeben.
    • Die Null- und die negativen Guthaben ermöglichen dem Server das Drosseln einer Anfrage von einem Client.
    • Ausführungsformen der Erfindung beziehen sich ferner auf Systeme und Verfahren zum Aufnehmen von Daten in einen Server. Das Aufnehmen von Daten kann das Deduplizieren der Daten, das Übertragen der Daten und/oder das Schreiben der Daten in eine Sicherung umfassen. Im Speziellen kann der Client während mancher Datenschutzoperationen nur eindeutige Daten oder Daten, die vom Sicherungsserver zuvor nicht gespeichert wurden, an den Server senden.
  • In diesem Beispiel zeigt 1 einen Server (z.B. einen Datenschutz- oder Sicherungsserver) 110, der Ressourcen 122 bereitstellt (wobei dies an Clients umfassen kann, die durch die Clients 102, 104, 106 und 108 dargestellt sind). Der Server 110 kann auch für einen Cluster von Knoten oder Servern stehen. In einem Beispiel streamen die Clients 102, 104, 106 und 108 Daten (z.B. Sicherungsdaten oder -streams, Wiederherstellungsstreams, Streams, die Daten für eine Verarbeitung, wie z.B. eine Deduplizierung, enthalten, etc.) zum/vom Server 110. Der Client 102 kann zum Beispiel eine Mehrzahl von virtuellen Maschinen, eine Datenbank, ein Dateisystem oder einen anderen Datentyp unter Verwendung von Streams 112 sichern. Auf ähnliche Weise ist der Client 104 den Streams 114 zugeordnet, der Client 106 ist den Streams 116 zugeordnet, und der Client 108 ist den Streams 118 zugeordnet.
  • In diesem Beispiel ist der Server 110 unter der Annahme, dass der Client eine verteilte Segmentverarbeitung ausführt, konfiguriert, um den Clients 102, 104, 106 und 108 Stream-Guthaben und/oder Segmentguthaben zuzuweisen. Der Server 102 ist konfiguriert, um eine Ressourcenzuweisung durchzuführen, wobei in einem Beispiel Stream-Guthaben und/oder Segmentguthaben verwendet werden. Diese Guthaben können unter Verwendung einer Ressourcenzuweisungstabelle 120 verwaltet werden. Die Ressourcenzuweisungstabelle 120 ermöglicht eine Bestimmung des Zuweisungsstatus (z.B. sicher, unsicher). Immer wenn Guthaben ausgegeben werden (unabhängig vom Typ), wird die Zuweisungstabelle 120 aktualisiert, so dass der Zuweisungsstatus des Systems im Lichte nachfolgender Anfragen nach Guthaben bewertet werden kann.
  • In einem Beispiel wird eine Anfrage nach Guthaben ausgewertet, um festzustellen, ob das Gewähren der Anfrage zu einem sicheren Zuweisungsstatus führt. Im Allgemeinen wird die Anfrage gewährt, wenn der resultierende Zuweisungsstatus sicher ist. Wenn die Anfrage zu einem unsicheren Zuweisungsstatus führt, wird die Anfrage abgelehnt, beispielsweise indem Null-Guthaben ausgegeben werden oder negative Guthaben ausgegeben werden.
  • Es wird in der nachfolgenden Offenbarung rein beispielhaft angenommen, dass 1 verfügbarer Stream einem gewährten Stream-Guthaben zugeordnet ist. Ebenso kann 1 Segmentprozess eine Einheitsverarbeitungszuweisung darstellen. Anders ausgedrückt und rein beispielhaft steht 1 Guthaben für 1 Stream. Andere Zuweisungsschemata mit einem Guthaben pro Ressource könnten anders sein. Ein Server könnte beispielsweise eine Anzahl von x Ressourcen pro Guthaben gewähren. Der Server 110 könnte einem anfragenden Client ein Stream-Guthaben und/oder ein Segmentguthaben gewähren, wenn es möglich ist, dass alle Streams/Segmentverarbeitungen, die allen Clients zugeordnet sind, die Ausführung beenden.
  • Da der Server 110 möglicherweise nicht weiß, wann ein bestimmter Client-Stream enden wird oder wie viele weitere Guthaben verschiedene Clients zum Zeitpunkt der Beendigung durch den bestimmten Client angefordert haben werden, darf der Server 110 davon ausgehen, dass alle Clients letztendlich versuchen werden, ihre maximal zulässigen Guthaben zu erwerben, die Guthaben zu verwenden und die Guthaben dann freizugeben.
  • Unter diesen Voraussetzungen kann der Server feststellen, ob der Streamzuweisungsstatus sicher ist, indem er einen hypothetischen Satz von Guthabenanfragen durch die Clients findet, der es jedem Client ermöglichen würde, sein Maximum an angeforderten Guthaben zu erwerben und die Guthaben zu verwenden. Wenn es einen Zustand gibt, in dem kein solcher Satz existiert, kann dies dazu führen, dass der Server 110 Null-Stream-Guthaben oder negative Stream-Guthaben gewährt. Dies kann dazu führen, dass Clients, die diese Gewährungen oder Anfragen erhalten, jegliche Guthaben, über die verfügt wird, zurückgeben. Anders ausgedrückt, die Möglichkeit, Null-Guthaben oder negative Guthaben zu gewähren oder auszugeben, ermöglicht das Drosseln der Clients. In einem Beispiel könnte der Client sich selbst drosseln, da er möglicherweise nicht über ausreichende Guthaben verfügt oder möglicherweise Guthaben an den Server 110 zurückgeben muss. Auf diese Weise versucht der Server dann, in einen sicheren Streamzuweisungsstatus zurückzukehren, um die angeforderten Guthaben zu gewähren.
  • In einem anderen Beispiel kann das System die Guthaben auf die Clients aufteilen. Dadurch wird es jedem Client ermöglicht, Guthaben bis zu deren Maximum anzufordern. Ein Client kann jedoch weiterhin basierend auf dem Prozessorstatus, der Prozessornutzung, einem Abstimmungsfaktor oder dergleichen gedrosselt werden.
  • Ausführungsformen der Erfindung können Ressourcen zuweisen, wenn der Zuweisungsstatus des Systems, der sich aus einer bestimmten Zuweisung ergibt, sicher ist. Wenn die vorgeschlagene Zuweisung zu einem unsicheren Status führt, kann die Zuweisung vorgenommen werden, um das System in einen sicheren Zuweisungsstatus zurückzubringen (z.B. durch Ausgabe von negativen oder Null-Guthaben).
  • Ferner beziehen sich Ausführungsformen der Erfindung genauer auf Systeme und Verfahren zum Aufnehmen von Daten in einen Server. Das Aufnehmen von Daten kann das Deduplizieren der Daten, das Übertragen der Daten vom Client auf den Server und das Schreiben der Daten in eine Sicherung umfassen. Im Speziellen kann der Client während mancher Datenschutzoperationen nur eindeutige Daten oder Daten, die vom Sicherungsserver zuvor nicht gespeichert wurden, an den Server senden. Dies wird beispielsweise mittels Fingerabdrücken erreicht.
  • Ein Fingerabdruck kann beispielsweise ein Hash eines Datensegments sein. Der Hash identifiziert die entsprechenden Daten eindeutig. Durch Identifizieren von Fingerabdrücken, die nicht bereits auf dem Server vorhanden sind, kann eine Bestimmung bezüglich der Daten vorgenommen werden, die an den Server gesendet werden müssen. Wahrscheinlich wird die an den Server gesendete Datenmenge vorteilhafterweise verringert.
  • 2 zeigt ein Beispiel für ein System, das Datenschutzoperationen, einschließlich einer Ressourcenzuweisung für die verteilte Segmentverarbeitung, ausführt. In einem Beispiel bezieht sich die verteilte Segmentverarbeitung auf Deduplizierungsvorgänge und/oder Sicherungsvorgänge. Die Verarbeitung kann bei der verteilten Segmentverarbeitung ferner aufgeteilt sein. Beispielsweise kann ein Client die Daten segmentieren und/oder die Daten mit Fingerabdruck versehen. Der Server kann aus den vom Client bereitgestellten Fingerabdrücken eindeutige Fingerabdrücke und damit eindeutige Daten erkennen. Dadurch wird es dem Client auch ermöglicht, nur eindeutige Daten während eines Sicherungsvorgangs zu senden.
  • 2 zeigt einen Client 202, der sich mit einem Server 210 abstimmt, um Datenschutzoperationen, wie z.B. Sicherungsvorgänge, durchzuführen. In diesem Beispiel bereitet sich der Client 202 zusammen mit dem Server 210 darauf vor, die Daten 204 zu sichern. Während dieser Operation kann (können) der Client 202 und/oder der Server 210 eine verteilte Segmentverarbeitungsoperation durchführen.
  • Im Speziellen werden die Daten 204 in Segmente 206 segmentiert, und die Fingerabdrücke 208 werden für jedes der Segmente 206 generiert. Die Fingerabdrücke 208 werden dann zur Verarbeitung an den Server 210 übermittelt. Der Server 210 kann die Fingerabdrücke 208 unter Verwendung eines Fingerabdruckfilters 212 mit einer Fingerabdruckdatenbank 214 abgleichen.
  • Im Speziellen wertet der Server 210 die Fingerabdrücke 208 aus, um eindeutige Fingerabdrücke zu identifizieren, die nicht in der Fingerabdruckdatenbank 214 enthalten sind. Die eindeutigen oder neuen Fingerabdrücke entsprechen Datensegmenten, die zuvor nicht vom Server 210 gesichert wurden. Der Server 210 kann dem Client 202 dann anzeigen, welche der Fingerabdrücke 208 eindeutig oder neu sind. Der Client 202 kann die Daten 204 dann sichern, indem er nur die Segmente sendet, die den eindeutigen Fingerabdrücken entsprechen, die in der Fingerabdruckdatenbank 214 nicht vorhanden sind. Sobald diese Segmente zu den vom Server 210 verwalteten Sicherungen hinzugefügt werden, werden die neuen Fingerabdrücke zu der Fingerabdruckdatenbank 214 hinzugefügt. Dies ermöglicht die Ausführung verteilter Segmentverarbeitungsoperationen, und zwar in einem Beispiel im Rahmen eines Sicherungsvorgangs. In einem Beispiel kann die verteilte Segmentverarbeitung unabhängig vom Sicherungsvorgang durchgeführt werden.
  • Die Datensegmentverarbeitung kann unter Verwendung verteilter Segmentguthaben (hierin als Segmentguthaben bezeichnet) erfolgen, die ein Beispiel für Guthaben sind und gleich wie oder anders als Stream-Guthaben sein können. Segmentguthaben spiegeln wider, dass die Verarbeitung im Zusammenhang mit der verteilten Segmentverarbeitung zwischen dem Client und dem Server aufgeteilt wird, wie zuvor angegeben. Die Segmentguthaben helfen der Systemfunktion, sich zu verbessern. Im Speziellen kann die CPU oder können Prozessoren des Servers 210 mit verschiedenen Aufgaben beschäftigt sein, wie z.B. Speicherbereinigung, der Verarbeitung von Anfragen von anderen Clients oder dergleichen. Als Ergebnis ist der Server 210 möglicherweise nicht in der Lage, alle vom Client 202 empfangenen Fingerabdrücke rechtzeitig zu verarbeiten. Dies kann dazu führen, dass die Fingerabdrücke entweder nicht oder nur teilweise gefiltert werden. Folglich muss der Client 202 mehrere Anfragen an den Server 210 senden, bis alle Fingerabdrücke auf dem Server 210 verarbeitet und gefiltert wurden. Durch Zuweisen von Ressourcen unter Verwendung von Segmentguthaben verbessert sich der Prozess, da der Client versteht, welche Ressourcen verfügbar sind, und eine bessere Erwartungshaltung hinsichtlich der Erledigung der Aufgabe hat. Probleme im Zusammenhang mit der QOS werden außerdem entschärft, da die Ressourcen allen Clients, die möglicherweise mit dem Server 212 oder dem Cluster kommunizieren, gerechter zugewiesen werden. Ausführungsformen der Erfindung stellen beispielsweise durch das Ausgeben von negativen oder Null-Guthaben sicher, dass ein Client mit einer hohen Aufnahmerate, der alle Deduplizierungsressourcen auf dem Server verwendet, die Verarbeitungsanforderungen anderer Clients nicht verzögert. Anders ausgedrückt, Clients können durch Verwendung von Guthaben, wie z.B. Segmentguthaben, gedrosselt werden oder sich selbst drosseln.
  • 3 zeigt ein Beispiel für ein Verfahren zum Zuweisen von Ressourcen zu Clients. Das Verfahren 300 kann mit dem Vorbereiten 302 von Daten für die Aufnahme beginnen. Wie zuvor angegeben, kann das Vorbereiten der Daten das Identifizieren der Daten für die Sicherung, das Segmentieren der Daten und das Generieren von Fingerabdrücken für jedes der Segmente umfassen. Dadurch wird es einem Client ermöglicht, die Anzahl der Fingerabdrücke zu bestimmen, die an den Server gesendet werden sollen. Diese Aspekte einer verteilten Segmentverarbeitung können vom Client ausgeführt werden.
  • In einem Beispiel kann ein Segmentguthaben einem Fingerabdruck entsprechen. Daher kann die Anzahl der angeforderten Guthaben von der Anzahl der Fingerabdrücke abhängen, die zur Verarbeitung an den Server gesendet werden sollen. Alternativ kann ein Guthaben basierend auf der Verarbeitungsleistung bestimmt werden (z.B. wie viele Fingerabdrücke unter Verwendung eines Prozentsatzes (z.B. 1%) der CPU verarbeitet werden können). In diesem Fall kann der Client Segmentguthaben entsprechend anfordern 304.
  • Sobald der Client die Guthaben anfordert, kann der Client Guthaben vom Server erhalten 306. Die Anzahl der vom Server gewährten Guthaben kann gleich wie die Anzahl der vom Client angeforderten Guthaben, geringer als die Anzahl der vom Client angeforderten Guthaben, größer als die Anzahl der vom Client angeforderten Guthaben, null oder negativ sein.
  • Sobald Guthaben empfangen wurden, wird die Datenschutzoperation (z.B. eine verteilte Segmentverarbeitung, ein Sicherungsvorgang etc.) basierend auf den gewährten Guthaben vorgenommen 308.
  • 4 zeigt ein Beispiel für ein Verfahren zum Verwenden von Guthaben, die von einem Server oder Cluster empfangen wurden. Beim Verfahren der 4 kann ein Client Guthaben (DSP-Guthaben oder andere Typen von Guthaben) von einem Server empfangen 402. Nach dem Empfang der Guthaben kann (können) der Client und/oder der Server eine Datenschutzoperation (z.B. DSP-Verarbeitung, Deduplizierung, Sicherung) unter Verwendung der vom Server gewährten Guthaben 404 vornehmen.
  • Wenn die Anzahl der gewährten Guthaben 406 beispielsweise gleich (=) der Anzahl der angeforderten Guthaben ist, kann der Client die gewährten Segmentguthaben verwenden, um nach eindeutigen Fingerabdrücken auf dem Server zu suchen. Wie zuvor angegeben, kann der Client die Daten segmentieren und mit Fingerabdruck versehen und die resultierenden Fingerabdrücke an den Server senden. Die Anzahl der an den Server gesendeten Fingerabdrücke oder die Anzahl der Fingerabdruckanfragen entspricht der Anzahl der gewährten Segmentguthaben. Dies hängt, wie zuvor angegeben, davon ab, wie viele Fingerabdrücke pro Guthaben verarbeitet werden. Ein Guthaben kann einem Fingerabdruck entsprechen. Ein Guthaben kann jedoch x Guthaben entsprechen. Ein anderes Schema kann verwendet werden. Der Client kann jeden Fingerabdruck einzeln oder zu einem Satz gruppiert an den Server senden. Die Guthaben, die der Client erhalten und verwendet hat, werden vom Server in einer Zuweisungstabelle nachverfolgt.
  • Wenn die Anzahl der gewährten Guthaben 408 > die Anzahl der angeforderten Guthaben ist, verwendet der Client die gewährten Segmentguthaben, um nach eindeutigen Fingerabdrücken auf dem Server zu suchen (oder um Fingerabdrücke zu identifizieren, die nicht auf dem Server liegen, wodurch Daten identifiziert werden, die vom Server nicht gesichert wurden). In diesem Fall entspricht die Anzahl der an den Server gesendeten Anfragen oder Fingerabdrücke der Anzahl der angeforderten Segmentguthaben. Der Client kann entweder die überschüssigen Guthaben für eine spätere Verwendung aufbewahren oder ungenutzte Guthaben zurückgeben.
  • Wenn die Anzahl der gewährten Guthaben 410 kleiner als (<) die Anzahl der angeforderten Guthaben ist, verwendet der Client die gewährten Segmentguthaben, um nach eindeutigen Fingerabdrücken auf dem Server zu suchen. Die Anzahl der vom Client ausgegebenen Anfragen kann die gewährten Segmentguthaben nutzen. In diesem Fall muss der Client möglicherweise zusätzliche Guthaben vom Server anfordern, um etwaige restliche Fingerabdrücke zu verarbeiten.
  • Wenn die Anzahl der gewährten Kredite 412 gleich 0 ist, wird der Client gedrosselt, und keine weiteren Operationen (z.B. DSP-Operationen) können vom Client durchgeführt werden. Andere Clients können ebenfalls gedrosselt werden. Der Client oder Server kann nach einem gewissen Zeitintervall einen erneuten Versuch starten, um die Anfrage erneut zu versuchen. Alternativ kann der Client nach einem gewissen Zeitraum eine neue Anfrage stellen, um Guthaben zu erhalten. Alternativ kann der Client eine geänderte Anfrage versuchen (z.B. weniger Guthaben anfordern, damit ein Teil der Verarbeitung durchgeführt werden kann).
  • Wenn die Anzahl der gewährten Guthaben 412 ein negativer Wert ist und wenn der Client über einige zwischengespeicherte Guthaben verfügt, muss der Client seine zwischengespeicherten Guthaben um das Ausmaß des gewährten negativen Guthabens abziehen, und die Anfragen des Clients werden gedrosselt. Wenn der Client keine zwischengespeicherten Guthaben hat, kann der Client den Wert der gewährten negativen Guthaben ignorieren und einfach drosseln. Nach einem Zeitraum kann der Client erneut versuchen, Guthaben zu erhalten.
  • Sobald die Anfrage gewährt wurde und die Annahme gilt, dass der Client nicht gedrosselt wird, versucht der Server, eindeutige Fingerabdrücke zu finden, wobei er die vom Client empfangenen Fingerabdrücke verwendet. Eindeutige Fingerabdrücke werden dann an den Client zurückgesendet. Der Client kann dann die Segmente identifizieren, die den eindeutigen Fingerabdrücken entsprechen, die Segmente komprimieren und die Segmente zur Speicherung als Sicherung an den Server zurücksenden. Wie es nachstehend ausführlicher erörtert wird, können die Segmentguthaben Streaming-Ressourcen begründen. Alternativ muss der Client möglicherweise Streaming-Guthaben anfordern, um Daten/Fingerabdrücke an den Server zu senden.
  • Wenn der Client keine Daten mehr zum Aufnehmen oder Sichern zur Verfügung hat und immer noch Segmentguthaben in einer Cache-Verbindung hat, kann der Client diese Guthaben einseitig freigeben, indem er einen Befehl zur Freigabe von Guthaben ausgibt. Der Server aktualisiert dann seine Zuweisungstabelle, um die von einem bestimmten Client freigegebenen Guthaben zu erfassen.
  • Sobald ein Client Segmentguthaben (Stream-Guthaben oder andere Typen von Guthaben) erhält, ist die entsprechende Operation vorteilhafterweise größtenteils garantiert, da die Zuweisung auf Ressourcen beruht, die auf dem Server verfügbar sind. Die Clients müssen nicht weiterhin erneut Anfragen versuchen und an den Server senden, bis alle Fingerabdrücke gefiltert sind. Die Operationen werden somit effizienter und reibungsloser durchgeführt.
  • 5 zeigt ein Beispiel für ein Guthabenzuweisungsverfahren 500. In einem anderen Beispiel kann das Verfahren der 5 hinsichtlich der Verarbeitung eines Fingerabdrucks definiert werden.
  • 5 veranschaulicht im Speziellen ein Beispiel für ein Verfahren zum Zuweisen von Segmentguthaben. Das Verfahren 500 kann Schritte oder Handlungen enthalten, die nicht jedes Mal ausgeführt werden, wenn das Verfahren durchgeführt wird. In 5 wird das Ausmaß oder die Anzahl von Schreibvorgängen, die durchschnittlich 1% eines Prozessors oder Kerns (z.B. einer CPU oder zentralen Verarbeitungseinheit) verbrauchen, bestimmt oder definiert 502. Während diese Zahl eine Schätzung sein darf, kann das Sammeln von statistischen Daten durch Ausführung einer empirischen Datensicherung zum Qualifizieren dieser Zahl verwendet werden. Der Prozentsatz der CPU-Auslastung während verschiedener Sicherungsdurchläufe unterschiedlicher Größe kann beobachtet oder gemessen werden. Diese Beobachtungen oder Messungen können herangezogen werden, um die durchschnittliche Anzahl der Schreibvorgänge zu bestimmen, die 1% der Daten verbrauchen. Wenn zum Beispiel festgestellt wird, dass eine Sicherung von 1 GB Daten 10% der CPU verbraucht und durchschnittlich 10.000 Schreibanfragen ergibt, kann geschätzt werden, dass 1000 Schreibanfragen an den Server 1% der CPU verbrauchen. Dieses Ergebnis kann verwendet werden, um die Anzahl der Segmentguthaben zu bestimmen, die anfragenden Clients zugewiesen werden sollen.
  • Als nächstes wird die durchschnittliche Anzahl der pro Kern zulässigen Schreibvorgänge bestimmt 504. In einem Beispiel wird dies ermittelt, indem die Anzahl der Schreibvorgänge, die 1% der CPU verbrauchen, mit dem durchschnittlichen Prozentsatz an freier CPU pro Kern multipliziert wird. Wenn der durchschnittliche Prozentsatz an freier CPU pro Kern unter einem Schwellenwert liegt (z.B. 2%), liegen die allen Clients gewährten Guthaben bei null oder sind negativ.
  • Als nächstes werden die maximalen Guthaben pro Client bestimmt 506. Dies kann ermittelt werden, indem der Durchschnitt der pro Kern zulässigen Schreibvorgänge mit der Anzahl der CPU-Kerne multipliziert und dann durch die Anzahl der Clientverbindungen geteilt wird. Die maximalen Guthaben pro Client stellen die Höchstzahl an Guthaben dar, die ein Client erwerben kann.
  • Die Zuweisungstabelle berücksichtigt Guthaben, die bereits an den Client ausgegeben wurden. Wenn beispielsweise die maximalen Guthaben eines Clients 100 betragen und 60 bereits gewährt wurden, kann eine Anfrage nach 50 DSP-/Schreibguthaben eine Gewährung von partiellen Guthaben oder Null-Guthaben oder negativen Guthaben zur Folge haben. Die Zuweisungstabelle wird aktualisiert, wenn Guthaben gewährt, freigegeben etc. werden.
  • In einem Beispiel wird die Anzahl der Guthaben pro Client ermittelt 508. Dies unterscheidet sich von den maximalen Guthaben, da bei dieser Handlung oder in diesem Schritt ein Abstimmungsfaktor berücksichtigt werden kann, der angepasst werden kann oder konfigurierbar ist. Der Abstimmungsfaktor ermöglicht, dass Ausführungsformen der Erfindung in die Ressourcen, die zugewiesen werden, einen Reservewert einbeziehen. Der Abstimmungsfaktor kann 50-70% der maximalen DSP-/Schreibguthaben ausmachen.
  • Als nächstes können Guthaben an anfragende Clients 510 ausgegeben werden. Die Anzahl der ausgegebenen Guthaben kann beispielsweise unter Verwendung des Minimums der angeforderten DSP-/Schreibguthaben und der berechneten Guthaben pro Client ermittelt werden.
  • Das folgende Beispiel ist zu betrachten. Wenn die Anzahl der Schreibvorgänge (oder der Fingerabdruckverarbeitung), die durchschnittlich 1% der CPU verbrauchen, 1000 beträgt und der durchschnittliche Prozentsatz an freier CPU pro Kern bei 50% liegt, beträgt der Durchschnitt der pro Kern zulässigen Lesevorgänge ((1000*0,5)=500). Wenn die Anzahl der CPU-Kerne 4 und die Anzahl der Clients 10 beträgt, sind die maximalen Guthaben pro Client ((500*4)/10 = 200). Wenn der Abstimmungsfaktor bei 50% liegt, betragen die berechneten Guthaben pro Client (200*0,5 = 100). Es besteht somit ein Unterschied zwischen den maximalen Guthaben pro Client und den abgestimmten oder berechneten Guthaben pro Client.
  • Wenn ein Client dann 40 DSP-/Schreibguthaben anfordert, sind die gewährten DSP-/ Schreibguthaben MIN(40,100) = 40. 40 Guthaben werden somit gewährt. Wenn der Client eine Vorabrufung anfordert, sind die gewährten Guthaben MAX(40,100) = 100. 100 Guthaben werden somit gewährt. Bei einer Wiederherstellung aus der Cloud kann die Vorabrufung ignoriert werden, in welchem Fall die gewährten Guthaben in diesem Beispiel 40 betragen können.
  • Jedes Mal, wenn Segmentguthaben angefordert werden, können Ausführungsformen der Erfindung sicherstellen, dass die Gewährung nicht zu einem unsicheren Zuweisungsstatus führt. Das Anfordern von Guthaben, welche die maximalen Guthaben eines Clients überschreiten, könnte beispielsweise zu einem unsicheren Zuweisungsstatus führen. Außerdem können die vom Client und von anderen Clients bereits verwendeten Guthaben bei der Gewährung von Guthaben ebenfalls berücksichtigt werden. Bei der Bestimmung des Zuweisungsstatus kann auch der durchschnittliche Prozentsatz an freier CPU pro Kern bestimmt werden. Wenn die Gewährung den durchschnittlichen Prozentsatz an freier CPU unter einen Schwellenwert drückt, kann die Gewährung für Null-Guthaben oder negative Guthaben gelten, bis ein sicherer Zuweisungsstatus wiederhergestellt ist.
  • Die nachfolgende Erörterung betreffend Stream-Guthaben umfasst Folgendes. Dieses Zuweisungsverfahren wird unter Bezugnahme auf die nachstehend beschriebenen 7B und 7C ausführlicher beschrieben.
  • In einem Beispiel soll C die Anzahl der Clients im System und N die Anzahl der Knoten oder Server im System sein.
  • Total (Maximum Streams) Availability Matrix (TAM): Eine Matrix mit der Länge N, die eine maximale Anzahl verfügbarer Streamressourcen für jeden Knoten angibt
  • TAM[j] = k, es gibt k Instanzen einer verfügbaren Streamressource Rj.
  • Current Allocation Matrix (CALM): Eine C×N-Matrix, welche die Anzahl der Streamressourcen definiert, die aktuell jedem Client zugewiesen sind.
  • CALM[i,j] = k, Client Ci sind dann aktuell k Instanzen einer Streamressource Rj zugewiesen.
  • Current Availability Matrix (CAM): Eine Matrix mit der Länge N, welche die aktuelle Anzahl der für jeden Knotentyp verfügbaren Streams angibt. Dies wird bestimmt, indem aktuell zugewiesene Streams für sämtliche Clients an jedem einzelnen Knoten hinzugefügt werden und das Ergebnis von den gesamten maximalen Streams für diesen Knoten abgezogen wird. CAM [ j ] = TAM [ j ] − ( CALM [ C0 ] + CALM [ C1 ] + ... + CALM [ CN ] ) ;
    Figure DE112019005038T5_0001
  • Current Demand Matrix (CDM): Eine C×N-Matrix, welche den aktuellen Bedarf oder den Zeitpunkt maximal angeforderter Streams definiert.
  • Wenn CDM[i,j] = k, kann Client Ci höchstens k Instanzen einer Streamressource Rj anfordern.
  • Current Need Matrix (CNM): Eine C×N-Matrix gibt die Nachfrage nach Stream-Guthaben für jeden Client an. (Nachfrage = Bedarf - zugewiesen). CNM [ i ,j ] = CMD [ i ,j ] − CALM [ i ,j ] .
    Figure DE112019005038T5_0002
  • Zu jedem Zeitpunkt bestimmt der Server, ob es sicher ist, Stream-Guthaben als Reaktion auf die angeforderten Client-Guthaben zuzuweisen. Das System befindet sich in einem sicheren Zustand, wenn zu einem bestimmten Zeitpunkt alle Client-Guthabenanfragen erfüllt werden können, d.h., die Nachfrage nach Streamressourcen bei allen Clients geringer als die aktuelle Stream-Verfügbarkeit für alle Knoten in einem System ist. CNM [ i ,j ] < CAM [ j ]
    Figure DE112019005038T5_0003
  • Wenn die Stream-Nachfrage eines Clients größer als die verfügbaren Streams ist (CNM[i,j] > CAM[j]), wird das System als unsicher angesehen (unsicherer Zuweisungsstatus), und den Clients werden negative oder Null-Guthaben gewährt, und es werden Anstrengungen unternommen, um das System in einen sicheren/stabilen Streamzuweisungsstatus zu bringen.
  • Die folgenden Beispiele veranschaulichen diesen Prozess ausführlicher. 6 zeigt einen Cluster, der Knoten oder Server 602 und Clients 604 enthält. 6 zeigt im Speziellen vier Knoten oder Server: N1, N2, N3 und N4. 6 zeigt auch die Clients C1, C2 und C3 (Clients 604), die Ressourcen der Server 602 nutzen. In diesem Beispiel umfassen die Ressourcen der Server 602, die den Clients 604 zugewiesen sind, Streams 606. Die Streams 606 können Sicherungsstreams, Wiederherstellungsstreams oder andere Datenstreams umfassen.
  • Gehen wir beispielsweise davon aus, dass in 6 die TAM oder die insgesamt an jedem der Knoten maximal verfügbaren Streams wie folgt dargestellt sind:
    N1 N2 N3 N4
    60 50 70 60
  • Somit verfügt N1 über 60 Streams für die Zuweisung zu Clients. Auf ähnliche Weise verfügen N2, N3 und N4 über 50, 70 bzw. 60 Streams für die Zuweisung zu Clients.
  • Die gesamten maximalen Streams können ermittelt werden, indem die Anzahl der Prozessoren und Kerne an einem Server berücksichtigt wird und ermittelt wird, wie viel Rechenleistung ein Stream verbraucht. Die gesamten maximalen Streams können auf andere Weise bestimmt werden, beispielsweise durch Testen oder durch Benutzereingabe.
  • Die nachstehende CALM-Matrix gibt die Stream-Guthaben an, die dem Client C1-C3 bereits zugewiesen wurden. In diesem Beispiel wird davon ausgegangen, dass den Clients C1, C2 und C3 die folgenden Stream-Guthaben bereits zugewiesen wurden.
    N1 N2 N3 N4
    C1 10 20 20 10
    C2 10 00 30 30
    C3 10 20 10 00
    CALM
  • Die CAM oder die aktuell verfügbaren Streams (oder Streams, die nicht zugewiesen wurden) kann bzw. können aus der TAM und der CALM, die obenstehend angeführt sind, berechnet werden. Zum Beispiel: Der Knoten N1 verfügt über maximal 60 Streams, die er aus der obigen TAM-Matrix zuweisen kann. Der Knoten N1 hat C1, C2 und C3 jeweils bereits 10 Streams zugewiesen. Die gesamten Streams, die aktuell an N1 verfügbar sind, wären somit
    CAM[N1] = TAM[N1] - (CALM[0, C1] +CALM[0, C2] + CALM[0, C3]), d.h.
    CAM[N1] = 60 - (10 + 10 + 10) = 30.
  • Ebenso
    CAM[N2] = 50 - (20 + 0 + 20) = 10.
    CAM[N3] = 70 - (20 + 30 + 10) = 10.
    CAM[N4] = 60 - (10 + 30 + 0) = 20.
    Figure DE112019005038T5_0004
  • Ganz allgemein erkennt die CAM, welche Knoten oder Server die den Clients 604 zugewiesenen Streams bereitstellen. Wie zuvor angegeben, können die Clients 604 eine Verbindung zu jedem der Server 602 herstellen und daher Guthaben von jedem der Server 602 in dem Cluster anfordern.
  • Die folgende CDM definiert die maximale Client-Stream-Guthabenanfrage zu einem bestimmten Zeitpunkt. Anders ausgedrückt, die folgende Matrix definiert, wie viele Streams jeder Client zu einem bestimmten Zeitpunkt von jedem der Server anfordern kann. Diese Zahlen oder Höchstwerte können von einem Administrator vorgegeben und festgelegt werden. Ferner können diese Zahlen dynamisch sein und auf der Anzahl an Clients und/oder der Anzahl an Servern beruhen. Bei Änderung der Anzahl der Server und Clients können sich die Zahlen der Stream-Guthabenanfragen zu einem Zeitpunkt ändern.
    N1 N2 N3 N4
    C1 30 30 20 20
    C2 10 20 30 40
    C3 10 30 50 00
    CDM
  • Durch Abziehen der aktuell zugewiesenen Stream-Matrix (CALM) von der Current Demand Matrix (CDM) kann das insgesamt benötigte Stream-Guthaben oder die CNM für C1, C2 und C3 wie folgt bestimmt werden:
    Figure DE112019005038T5_0005
  • Anhand der obigen Informationen ist es möglich festzustellen, ob jeder Client seine maximal angeforderten Stream-Guthaben erwerben und verwenden kann. In der nachfolgenden Erörterung wird folgendes Format verwendet. <xx xx xx xx> steht für Streams, die den Knoten N1, N2, N3 bzw. N4 zugeordnet sind.
  • Beispielsweise fordert C1 bei der CNM 20 N1-Stream-Guthaben, 10 N2-Stream-Guthaben und 10 N4-Stream-Guthaben an und erwirbt diese, um seine maximal angeforderten Guthaben zu erreichen. Der Server kann diese Bestimmung durchführen, bevor die Anfrage tatsächlich gewährt wird.
  • Nach der Anfrage und dem Erwerb durch C1 werden die verfügbaren Streams nun wie folgt ermittelt:
    • <30 10 10 20> (CAM oder verfügbare Streams) -
    • <20 10 00 10> (Streams, die von C1 erworben wurden, um das Maximum von C1 zu erreichen) =
    • <10 00 10 10> (Streams, die noch verfügbar sind)
  • Somit stehen dem Cluster noch 10 N1-Streams, 00 N2-Streams, 10 N3-Streams und 10 N4-Streams zur Verfügung.
  • Als nächstes beendet C1 die Prozesse im Zusammenhang mit den Streams und gibt 30 N1-, 30 N2-, 20 N3- und 20 N4-Stream-Guthaben an das System zurück. Dabei handelt es sich um die Streams, die der C1-Zeile in der CDM zugeordnet sind. Dies wird zu den aktuell verfügbaren Streams hinzugefügt.
    <10 00 10 10> + <30 30 20 20> = <40 30 30 30>
  • Als Ergebnis stehen dem Cluster nun insgesamt 40 N1-, 30 N2-, 30 N3- und 30 N4-Streams zur Verfügung. Dieses <40 30 30 30> ist geringer als oder gleich wie die TAM <60 50 70 60> oder der gesamte maximale Stream für jeden Knoten des Clusters, d.h. <40 30 30 30> <= <60 50 70 60>, so dass der Systemstatus sicher für die Zuweisung und Verarbeitung der nächsten Clientanfrage ist.
  • C2 erwirbt nun 20 N1-Streams und 10 N4-Streams. C2 beendet dann und gibt all seine Stream-Guthaben zurück. In diesem Beispiel und nach diesen Schritten sind die verfügbaren Streams Folgende oder entsprechen Folgenden:
    <40 30 30 30> (Streams, die vor der Anfrage durch C2 aktuell verfügbar sind) -
    <00 20 00 10> (Streams, die von C2 erworben wurden, um das Maximum von C2 zu erreichen) =
    <40 30 30 30> - <00 20 00 10> = <40 10 30 20> (Streams, die noch verfügbar sind) +
    <10 20 30 40> (Streams, die der C2-Zeile in der CDM zugeordnet sind)
    <10 20 30 40> + <40 10 30 20> = <50 30 60 60> (Streams, die verfügbar sind, nachdem C2 Stream-Guthaben zurückgegeben hat).
  • Dieses <50 30 60 60> ist geringer als oder gleich wie die TAM <60 50 70 60> oder der gesamte maximale Stream für jeden Knoten des Clusters, d.h. <50 30 60 60> <= <60 50 70 60>, so dass der Systemstatus sicher für das Zuweisen und Verarbeiten ist, um die nächste Clientanfrage zu verarbeiten.
  • Als nächstes erwirbt C3 10 N2- und 40 N3-Streams, beendet und gibt alle Streams zurück (gibt Stream-Guthaben zurück). Das Ergebnis ist wie folgt:
    <50 30 60 60> (Streams, die vor jenen von C3 aktuell verfügbar sind) -
    <00 10 40 00> (Streams, die von C3 erworben wurden, um das Maximum von C3 zu erreichen) +
    <10 30 50 00> (Streams, die von C3 zurückgegeben wurden) =
    <60 50 70 60> (verfügbare Stream-Guthaben).
  • Dieses <60 50 70 60> ist geringer als oder gleich wie die TAM <60 50 70 60> oder der gesamte maximale Stream für jeden Knoten des Clusters, d.h. <60 50 70 60> <= <60 50 70 60>, so dass der Systemstatus sicher für das Zuweisen und Verarbeiten ist, um die nächste Clientanfrage zu verarbeiten.
  • Dies zeigt, dass die Streamzuweisungszustände sicher sind und Stream-Guthaben allen Clients gewährt werden können, wie es obenstehend beschrieben wurde, da es jedem Client möglich ist, seine maximal angeforderten Stream-Guthaben zu erwerben und die Stream-Guthaben zu nutzen.
  • Ein sicherer Status für die Streamzuweisung zeigt an, dass Stream-Guthaben gewährt oder ausgegeben werden können. In Ausführungsformen der Erfindung werden mehrere verschiedene Arten von Guthaben in Erwägung gezogen, die angefordert und gewährt werden können.
  • Die nachfolgenden Beispiele veranschaulichen diese Arten von Guthaben und zeigen, ob die Guthaben gewährt werden.
  • Beispiel 1: Ein Server gewährt „gleiche“ Guthaben.
  • Wenn im gleichen Zustand gestartet wird, in dem das vorherige Beispiel startete, ist es anzunehmen, dass C3 10 Stream-Guthaben an Knoten N3 anfordert. In diesem Beispiel sind genügend Streams verfügbar, so dass die Guthabenanfrage gewährt werden kann. Nach der Gewährung lautet der neue Streamzuweisungsstatus wie folgt: CAM oder die verfügbaren Streams an den Knoten:
    N1 N2 N3 N4
    Verfügbare Streams 30 10 00 20
  • Die den Clients 604 aktuell zugewiesenen CALM-Streams sind nun die Folgenden (unter der Annahme, dass die Anfrage von C3 nach 10 N3-Guthaben gewährt wird):
    N1 N2 N3 N4
    C1 10 20 20 10
    C2 10 00 30 30
    C3 10 20 20 00
    CALM
  • Die maximal von den Clients angeforderten Streams sind nun die Folgenden:
    N1 N2 N3 N4
    C1 30 30 20 20
    C2 10 20 30 40
    C3 10 30 50 00
    CDM
  • Mit diesen Informationen kann die Bestimmung erfolgen, ob der neue Streamzuweisungsstatus sicher ist.
    Figure DE112019005038T5_0006
  • Im obigen Beispiel kann C1 20 N1-, 10 N2- und 10 N4-Streams erwerben, verwenden und freigeben. Dann kann C2 20 N2- und 10 N4-Streams erwerben, verwenden und freigeben. Schließlich kann C3 10 N2- und 30 N3-Streams erwerben, verwenden und dann freigeben. Daher ist dieser neue Zuweisungsstatus sicher.
  • Da der neue Status sicher ist, wird die Anfrage von C3 nach 10 Stream-Guthaben am Knoten N3 gewährt. Dies ist ein Beispiel für einen Server, der Stream-Guthaben entsprechend der Anzahl der vom Client angeforderten Stream-Guthaben gewährt.
  • Beispiel 2: Der Server gewährt „partielle“ Guthaben.
  • Wenn im gleichen Zustand gestartet wird, in dem das vorherige Beispiel startete, ist es anzunehmen, dass C3 20 Stream-Guthaben an N3 anfordert. In diesem Beispiel sind die vor Gewährung der angeforderten Stream-Guthaben verfügbaren Streams die Folgenden:
    N1 N2 N3 N4
    30 10 10 20
  • Die nach Gewährung der Stream-Guthaben verfügbaren Streams sind die Folgenden:
    N1 N2 N3 N4
    30 10 -10 20
  • Da die Anzahl der nach der Gewährung verfügbaren Streams insgesamt weniger als null beträgt, kann der Server die Entscheidung treffen, 10 Stream-Guthaben zu gewähren (was eine partielle Gewährung ist, da 20 Stream-Guthaben angefordert wurden). Wie bereits in Bezug auf das vorherige Beispiel angegeben, führt die Gewährung von 10 Stream-Guthaben von N3 an C3 zu einem sicheren Zuweisungsstatus. Dies stellt ein Beispiel für eine partielle Gewährung von Stream-Guthaben dar.
  • Beispiel 3: „Null-“ oder „negative“ Stream-Guthabenzuweisung
  • Ausgehend von dem vorherigen Startzustand ist es anzunehmen, dass der Client C2 10 Stream-Guthaben von dem Knoten N2 anfordert. In diesem Beispiel gibt es genügend Streams, um Stream-Guthaben zu gewähren. Unter der Voraussetzung, dass die Anfrage gewährt wird, wäre der neue Status: CAM oder die verfügbaren Streams an den Knoten:
    N1 N2 N3 N4
    Verfügbare Streams 30 00 10 20
  • Die CALM oder die aktuell zugewiesenen Streams entsprechend dem Ausgangszustand:
    N1 N2 N3 N4
    C1 10 20 20 10
    C2 10 10 30 30
    C3 10 20 10 00
    CALM
  • Die CDM oder die maximal angeforderten Streams zu einem Zeitpunkt wird bzw. werden wie folgt bestimmt:
    N1 N2 N3 N4
    C1 30 30 20 20
    C2 10 20 30 40
    C3 10 30 50 00
    CDM
  • Nun erfolgt eine Bestimmung, um festzustellen, ob der neue Zuweisungsstatus sicher ist. Es besteht die Annahme, dass die Clients C1, C2 und C3 mehr Stream-Guthaben von N2 und N3 anfordern.
    Figure DE112019005038T5_0007
  • In diesem Fall kann C1 nicht genügend Streams von N2, d.h., von der obigen CNM, erwerben, er benötigt 10 Streams von N2. Gemäß der obengenannten CAM beträgt die Anzahl der für N2 verfügbaren Streams jedoch 0. Außerdem kann C2 nicht genügend Streams von N2 erwerben, und C3 kann nicht genügend Streams von N2 erwerben.
  • Keiner der Clients in diesem Beispiel kann genügend Stream-Guthaben erwerben, um seine maximal zulässigen Stream-Guthaben zu erlangen. Infolgedessen ist dieser Status nicht sicher, und der Server 602 kann einen oder mehrere der Clients 604 drosseln und den unsicheren Zuweisungsstatus durch Ausgabe negativer Guthaben überwinden. Anders ausgedrückt, die Server 602 überwinden diesen unsicheren Zustand durch Drosseln und Ausgabe negativer Guthaben.
  • Beispielsweise kann der Server N2 C1 20 negative Stream-Guthaben gewähren. Gegebenenfalls gewährt N2 den Clients C2 und C3 Null-Guthaben (d.h., die Clients C2 und C3 drosseln ihre Anfragen und starten einen erneuten Versuch nach einiger Zeit). Client C1 gibt die 20 Stream-Guthaben, die er besitzt, an N2 zurück, und die Überprüfung des sicheren Zuweisungsstatus wird durchgeführt, um festzustellen, ob der Status sicher ist.
  • Guthaben, wie z.B. Stream-Guthaben und andere Typen von Guthaben, werden verwendet, um eine Ressourcenzuweisung durchzuführen. Das Streamzuweisungsverfahren kann bei vielen Arten von Streams eingesetzt werden. Das Streamzuweisungsverfahren kann stabile Streamzuweisungszustände aufrechterhalten, indem verschiedenen Clients negative/Null-Guthaben gewährt werden. Ausführungsformen der Erfindung ermöglichen ferner verschiedene Arten der Gewährung von Guthaben, wie zuvor beschrieben.
  • Im Speziellen können Stream-Guthaben vorab abgerufen werden. Wenn ein Client keine Stream-Guthaben besitzt (oder auch wenn der Client einige Stream-Guthaben besitzt) und wenn auf dem Server genügend freie Streams vorhanden sind, kann der Server dem Client mehr Guthaben gewähren als angefordert.
  • Das Vorabrufen von Guthaben kann beispielsweise basierend auf den erwarteten Auslastungen angefordert werden. Dies kann beispielsweise während eines Wiederherstellungsvorgangs gelten, bei dem die Stream-Guthaben in Erwartung der Wiederherstellung eines Streams durch Auslesen einer Sicherung verwendet werden.
  • Gewährte Guthaben können auch verwendet werden, um Entscheidungen in Bezug auf die Dimensionierung des Cache in Clientgröße zu treffen. Dies bezieht sich beispielsweise auf das Vorauslesen von Stream-Guthaben, die für den Wiederherstellungsvorgang verwendet werden, das Durchführen eines intelligenten Vorauslesens oder das Verwenden von Guthaben zum Verwalten der Kosten einer Lösung.
  • Durch eine partielle Gewährung von Guthaben kann das teilweise Abschließen von Operationen ermöglicht werden. Außerdem können Stream-Guthaben von den Clients abgerufen werden, indem negative Guthaben ausgegeben werden und die Anzahl der negativen Guthaben aus dem Cache eines Clients gelöscht wird. Anders ausgedrückt, ein Client kann gedrosselt werden, wenn die Anzahl der gewährten Guthaben bei null liegt oder negativ ist. Weitere unterschiedliche Guthabenzuweisungsverfahren können basierend auf der Art der angeforderten Guthaben umgesetzt werden.
  • 7A zeigt ein Beispiel für ein Verfahren zum Durchführen einer Ressourcenzuweisung. In einem Beispiel können verschiedene Parameter im Zusammenhang mit der Ressourcenzuweisung definiert 702 oder bestimmt werden. Es kann beispielsweise eine Bestimmung hinsichtlich dessen erfolgen, wie viele Streams jeder Knoten oder Server sicher unterstützen kann. Dies kann auf der Anzahl der Prozessoren/ Kerne, dem Speicher, Schreib-/Leseparametern oder dergleichen beruhen. Es kann beispielsweise eine Beziehung zwischen Schreiboperationen, Prozessor- oder Kernverbrauch festgestellt werden. Wenn eine vorgegebene Anzahl von Schreiboperationen oder eine Datenübertragungsrate 1% einer CPU verbraucht, dann dürfte ein Stream bei dieser Übertragungsrate 1 Guthaben entsprechen. Die maximal zulässige Anzahl von Streams pro Client kann ebenfalls bestimmt werden.
  • Dieser Aspekt des Verfahrens 700 kann zu einem einzigen Zeitpunkt durchgeführt werden. Dieser Aspekt des Verfahrens 700 kann jedoch neu bewertet werden, wenn Knoten hinzugefügt/entfernt werden oder wenn Clients hinzugefügt/aus dem System entfernt werden. Diese Werte könnten auch andere Funktionen erklären, die von den Servern 602 ausgeführt werden, welche möglicherweise keine Streams umfassen oder möglicherweise nicht die bestimmte Ressource betreffen, die zugewiesen wird. Ferner sind diese Werte möglicherweise imstande, basierend auf anderen Faktoren wie der Tageszeit zu variieren. Wenn der Prozessor beispielsweise nicht für andere Aufgaben benötigt wird, wie z.B. während einer langsameren Periode, könnte es möglich sein, die Anzahl der verfügbaren Streams vorübergehend zu erhöhen.
  • Sobald die Ressourcenzuweisungen definiert wurden und der Server den Clients Ressourcen zuweist, erzwingt das Verfahren 700 das Zuweisungsverfahren oder führt es aus. Eine Anfrage nach Stream-Guthaben kann beispielsweise empfangen werden 704. Diese Anfrage wird ausgewertet, wie zuvor erörtert, um festzustellen, ob die angeforderte Zuweisung zu einem sicheren Zuweisungsstatus führt. Somit kann der Server den Streamstatus oder den Zuweisungsstatus durch hypothetisches Gewähren der Anfrage bewerten 706. Dazu gehört die Überlegung, ob den anderen Clients noch ihre maximalen Guthaben zugewiesen werden können. Wie zuvor angegeben, besteht bei einer Ausführungsform die Annahme, dass Clients letztendlich ihre maximal zulässigen Guthaben anfordern, verwenden und freigeben könnten. Die Auswertung legt somit fest, wie der Zuweisungsstatus wäre, wenn die Anfrage gewährt werden sollte.
  • Der Server gibt dann Guthaben 708 entsprechend dem Ergebnis (dem festgestellten Zuweisungsstatus) an den anfragenden Client (und/oder an andere Clients) aus. Wenn der Zuweisungsstatus sicher ist, kann der Server Guthaben ausgeben, die der Anfrage entsprechen oder mehr als entsprechend der Anfrage sind. Wenn der Zuweisungsstatus nicht sicher ist, kann eine partielle Gewährung erfolgen, die immer noch zu einem sicheren Zuweisungsstatus führt. Wenn der Zuweisungsstatus nicht sicher ist, kann der Server Null- oder negative Guthaben ausgeben. In einem Beispiel könnten die Null- und/oder negativen Guthaben an jeden der Clients ausgegeben werden.
  • 7B zeigt ausführlicher ein Beispiel für das Auswerten des Streamstatus. 7B zeigt im Speziellen ein Beispiel für das Auswerten des in 7A dargestellten Serverstreamstatus 706. Somit stellt das Verfahren 720 ein Beispiel für das Auswerten des Serverstreamstatus 706 dar. In einem Beispiel des Verfahrens 720 kann der Server die TAM 722 berechnen, welche die insgesamt verfügbaren Streams bestimmt. Der Server kann dann in der CALM 724 nachschlagen. Die CALM identifiziert die Streams, die den Clients aktuell zugewiesen sind.
  • Als nächstes wird die CAM zu einem Zeitpunkt bestimmt 726. Dies wird durch Abziehen der CALM von der TAM bestimmt (CAM = TAM - CALM). Dadurch wird es dem Server ermöglicht, festzustellen, wie viele Streams für die Zuweisung verfügbar sind. Dies kann aus Sicht des Systems insgesamt und/oder pro Knoten oder pro Server bestimmt werden. Wie obenstehend erläutert, kann die Anzahl der verfügbaren Streams pro Server bestimmt werden. In einem Beispiel wird dadurch sichergestellt, dass die Ressourcen eines bestimmten Servers nicht überlastet werden. Zudem kann dies in einer Ausführungsform dem Server oder Cluster Flexibilität beim Bestimmen verleihen, welche Server Ressourcen bereitstellen oder zuweisen. Es könnte beispielsweise einem Server möglich sein, eine Anfrage an einen anderen Server umzuleiten, wenn die Umleitung zu einem sicheren Zuweisungsstatus führen würde.
  • Als nächstes wird die CDM bestimmt 728, und die CNM wird bestimmt 730, indem die CALM von der CDM abgezogen wird (CNM = CDM - CALM).
  • Nach Ermittlung dieser Information erfolgt die Bestimmung 732, ob der Streamzuweisungsstatus sicher oder unsicher ist. Wenn der Streamzuweisungsstatus nicht sicher ist, werden Null- oder negative Guthaben gewährt 740. Wenn der Streamzuweisungsstatus sicher ist, werden Guthaben gewährt. Es können zum Beispiel partielle Guthaben gewährt werden 734, gleiche Guthaben können gewährt werden 736, oder Prefetch-Guthaben können gewährt werden 738. Die Guthaben werden dann ausgegeben 708. In einem Beispiel kann das Ausgeben von Guthaben 708 Teil des Verfahrens 720 sein und ist in das Gewähren von Guthaben 734, 736, 738 oder 740 integriert.
  • 7C zeigt ein Beispiel für das Bestimmen eines Streamzuweisungsstatus. 7C zeigt im Speziellen ein Beispiel für das Bestimmen, ob der Streamzuweisungsstatus in 7B sicher ist 732. Das Verfahren 748 kann für jeden Client 750 durchgeführt werden. Beginnend mit einem ersten Client 750 erfolgt eine Bestimmung, um festzustellen 752, ob CNM größer als CDM ist. Wenn die aktuelle Nachfrage nicht größer als der aktuelle Bedarf ist, ist der Status somit unsicher 754 und negative oder Null-Guthaben werden ausgegeben oder gewährt, wie in 7B dargestellt.
  • Wenn die CNM größer als die CDM ist, wird die Stream-Verfügbarkeit nach Gewährung der maximalen Streamanfragen für den Client bestimmt 756. Diese Berechnung kann so durchgeführt werden, als ob die angeforderten Guthaben gewährt worden wären, um festzustellen, ob der resultierende Status sicher ist. Ferner werden alle Clients in einer Ausführungsform als Ganzes ausgewertet, um festzustellen, ob der Streamzuweisungsstatus sicher ist.
  • In einem Beispiel wird die Stream-Verfügbarkeit (756) bestimmt, indem die Streams, die vom Client erworben wurden, um den maximalen Bedarf 760 des Clients zu erreichen, von der Anzahl der aktuell verfügbaren Streams 758 abgezogen werden (dies kann insgesamt oder pro Server oder pro Knoten erfolgen). Dieses Ergebnis wird dann zu den Streams hinzugefügt, die vom Client zurückgegeben wurden, nachdem der Bedarf verarbeitet wurde 762. Anders ausgedrückt, das System bewertet den Status in einem Beispiel unter der Annahme, dass die Clients ihre maximal möglichen Streams angefordert haben und dass diese ihnen gewährt werden.
  • Auf Grundlage dieser Bestimmung 756 erfolgt die Bestimmung, ob die verfügbaren Streams geringer als die insgesamt verfügbare Matrix 764 sind. Wenn nicht, ist der Status unsicher 766. Wenn dies der Fall ist und alle Clients verarbeitet wurden 768, ist der Status sicher 772, und die Guthaben können gewährt werden, wie in 7B dargestellt. Wenn nicht alle Clients verarbeitet werden, wird der nächste Client verarbeitet 770.
  • Die 7A-7C zeigen somit ein Beispiel für ein Verfahren zum Zuweisen von Ressourcen auf eine solche Weise, dass der Zuweisungsstatus des Systems sicher ist. Wenn eine vorgeschlagene Zuweisung von Ressourcen (z.B. eine Anfrage von einem Client) zu einem unsicheren Zuweisungsstatus führt, kann die Zuweisung bei null liegen oder negativ sein, wodurch es dem System ermöglicht wird, entweder einen unsicheren Zuweisungsstatus zu vermeiden oder in einen sicheren Zuweisungsstatus zurückzukehren.
  • Es sollte zu erkennen sein, dass die vorliegende Erfindung auf vielfältige Weise umgesetzt werden kann, einschließlich als Prozess, Apparatur, System, Vorrichtung, Verfahren oder computerlesbares Medium, wie z.B. computerlesbares Speichermedium oder Computernetzwerk, in dem Computerprogrammanweisungen über optische oder elektronische Kommunikationsverbindungen gesendet werden. Anwendungen können die Form einer Software annehmen, die auf einem Universalrechner ausgeführt wird, oder können in Hardware festverdrahtet oder hartcodiert sein. In dieser Beschreibung können diese Implementierungen oder jede andere Form, welche die Erfindung annehmen kann, als Techniken bezeichnet werden. Im Allgemeinen kann die Reihenfolge der Schritte der offenbarten Prozesse im Rahmen der Erfindung geändert werden.
  • Die hierin offenbarten Ausführungsformen können die Verwendung eines Spezial- oder Universalrechners, einschließlich verschiedener Computerhardware- oder -softwaremodule, umfassen, wie dies nachstehend ausführlicher erörtert wird. Ein Computer kann einen Prozessor sowie Computerspeichermedien enthalten, die Instruktionen tragen, die, wenn sie vom Prozessor ausgeführt werden und/oder vom Prozessor zum Ausführen gebracht werden, eines oder mehrere der hierin offenbarten Verfahren ausführen.
  • Wie obenstehend angeführt, umfassen Ausführungsformen im Rahmen der vorliegenden Erfindung auch Computerspeichermedien, die physische Medien zum Tragen oder Speichern computerausführbarer Anweisungen oder Datenstrukturen sind. Bei solchen Computerspeichermedien kann es sich um alle verfügbaren physischen Medien handeln, auf die ein Universal- oder Spezialrechner zugreifen kann.
  • Beispielsweise und ohne Einschränkung können solche Computerspeichermedien Hardware wie eine Solid-State-Disk (SSD), RAM, ROM, EEPROM, CD-ROM, einen Flash-Speicher, einen Phasenwechselspeicher („PCM“) oder einen anderen optischen Plattenspeicher, Magnetplattenspeicher oder andere magnetische Speichervorrichtungen oder andere Hardwarespeichervorrichtungen umfassen, die zum Speichern von Programmcode in Form von computerausführbaren Anweisungen oder Datenstrukturen verwendet werden können, auf die ein Universal- oder Spezialrechnersystem zugreifen kann und die von einem solchen ausgeführt werden können, um die offenbarte Funktionalität der Erfindung zu implementieren. Kombinationen aus dem Obengenannten sollten ebenfalls in den Geltungsbereich von Computerspeichermedien fallen. Solche Medien sind auch Beispiele für nicht-transitorische Speichermedien, und nicht-transitorische Speichermedien umfassen auch Cloud-basierte Speichersysteme und -strukturen, obwohl der Umfang der Erfindung nicht auf solche Beispiele für nicht-transitorische Speichermedien beschränkt ist.
  • Computerausführbare Anweisungen umfassen beispielsweise Anweisungen und Daten, die dazu führen, dass ein Universalrechner, ein Spezialrechner oder eine Spezialverarbeitungsvorrichtung eine bestimmte Funktion oder Funktionsgruppe ausführt. Obwohl der Gegenstand in einer Sprache beschrieben wurde, die für Strukturmerkmale und/oder methodische Handlungen spezifisch ist, versteht es sich, dass der in den beigefügten Ansprüchen definierte Gegenstand nicht zwangsläufig auf die obenstehend beschriebenen spezifischen Merkmale oder Handlungen beschränkt ist. Die hierin offenbarten spezifischen Merkmale und Handlungen werden eher als beispielhafte Formen der Umsetzung der Ansprüche offenbart.
  • Wie hierin verwendet, kann sich der Begriff „Modul“ oder „Komponente“ auf Softwareobjekte oder -routinen beziehen, die auf dem Computersystem ausgeführt werden. Die verschiedenen hierin beschriebenen Komponenten, Module, Maschinen und Dienste können als Objekte oder Prozesse implementiert werden, die auf dem Computersystem beispielsweise als separate Threads ausgeführt werden. Während das hierin beschriebene System und die hierin beschriebenen Verfahren in Software implementiert werden können, sind Implementierungen in Hardware oder einer Kombination aus Software und Hardware ebenfalls möglich und werden in Erwägung gezogen. In der vorliegenden Offenbarung kann eine „Recheneinheit“ ein beliebiges Computersystem, wie hierin bereits definiert, oder ein beliebiges Modul oder eine Kombination von Modulen sein, die auf einem Computersystem ablaufen.
  • Zumindest in einigen Fällen wird ein Hardwareprozessor bereitgestellt, der dahingehend funktionsfähig ist, ausführbare Anweisungen zur Durchführung eines Verfahrens oder Prozesses, wie z.B. der hierin offenbarten Verfahren und Prozesse, auszuführen. Der Hardwareprozessor kann ein Element einer anderen Hardware, wie z.B. die hierin offenbarten Computervorrichtungen und -systeme, umfassen oder nicht umfassen.
  • In Bezug auf Computerumgebungen können Ausführungsformen der Erfindung in Client-Server-Umgebungen, egal ob Netzwerk- oder lokale Umgebungen, oder in jeder anderen geeigneten Umgebung durchgeführt werden. Geeignete Betriebsumgebungen zumindest für einige Ausführungsformen der Erfindung umfassen Cloud-Computerumgebungen, in denen sich eines oder mehr von einem Client, Server oder einer virtuellen Zielmaschine in einer Cloud-Umgebung befinden und dort arbeiten kann.
  • Die vorliegende Erfindung kann in anderen spezifischen Formen ausgeführt werden, ohne von ihrem Geist oder ihren wesentlichen Eigenschaften abzuweichen. Die beschriebenen Ausführungsformen sind in jeder Hinsicht nur als veranschaulichend und nicht als einschränkend anzusehen. Der Umfang der Erfindung wird daher eher durch die beigefügten Ansprüche als durch die vorstehende Beschreibung angegeben. Alle Änderungen, die in die Bedeutung und den Äquivalenzbereich der Ansprüche fallen, sind in deren Geltungsbereich einzubeziehen.
  • ANLAGE A ZUR BESCHREIBUNG
 /*
 * Stream Guthaben Zuweisungsalgorithmus, der verschiedenen Clients Stream Guthaben
 * durch Aufrechterhalten eines stabilen Stream Zuweisungszustands gewährt.
 *
 * erhält einen stabilen Stream Guthaben Zuweisungszustand durch Gewähren
 * negativer/Null Streams an Clients und Ausgleichen des Zustands aufrecht.
 */
 #include <stdio.h>
 #include <stdlib.h>
 #include <stdbool.h>
 /* Anzahl an Clients */
 const int C = 3;
 /* Anzahl verfügbarer Streams */
 const int S = 4;
 /* Verfügbare Streams */
 int available_streams[4];
 /* Maximale Streams, die einem Client zugewiesen warden können */
 int maxm[3][4];
 /* Aktuelle Streams, die einem Client zugewiesen sind */
 int allot[3][4];
 /* Initialisieren eines stabilen Stream Zuweisungszustands */
 static void
 init_state(void)
 {
  int i = 0, j = 0;
     /* Verfügbare Instanzen von Stream Ressourcen */
     int available_streams_s[] = { 30, 10, 10, 20 };
     /* Maximale Streams die einem Client zugewiesen werden können */
     int maxm_s[3][4] = {
          { 30, 30, 20, 20 },
          { 10, 20, 30, 40 },
          { 10, 30, 50, 00 } 
     };
     /* Aktuelle Streams, die einem Client zugewiesen sind */
     int allot_s[3][4] = {
          { 10, 20, 20, 10 },
          { 10,00,30,30 }, 

          { 10, 20, 10, 00 } 
     };
     for (i = 0; i < 4; i++) {
      available_streams[i] = available_streams_s[i]; 
     }
    for (i = 0; i < 3; i++) {
     for (j = 0; j < 4; j++) {
       maxm[i][j] = maxm_s[i][j];
       allot[i][j] = allot s[i][j];
     }
    }
 }
 static void
 print_matrix(int x[][S],int n,int m)
 {
  int i,j;
  printf("\n");
  printf("\tN1 \tN2\tN3\tN4 ");
  for(i = 0; i < n; i++) {
   printf("\n");
   printf("C%d\t", i);
   for(j = 0; j < m; j++) {
    printf("%d\t",x [i][j]);
   }
  }
  }printf("\n"); 
 }
 /* Funktion zur Berechnung wie viele Stream Guthaben jeder Client erfordert */
 static void
 calculateNeed(int need[C][S], int maxm[C][S], int allot[C][S])
 {
  int i, j;
  for (i = 0 ; i < C ; i++) {
   for (j = 0; j < S ; j++) {
    /* Erforderliche Stream Guthaben = (maxm Streamzuweisung - aktuelle Zuweisung)
 */
    need[i][j] = maxm[i][j] - allot[i][j];
    if (need[i][j] < 0) {
      need[i][j] = 0; 
    }
  }
 }

    printf("\n Verfügbare Streams");
    printf("\n\tN1\tN2\tN3\tN4");
    printf("\n\t%d\t%d\t%d\t%d\n", available _streams[0], available_streams[1],
 available _streams[2], available_streams[3]);
  printf("\n Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)");
  print_matrix(allot, i, j);
  printf("\n Maximale Stream Anforderungen pro Client Matrix");
  print_matrix(maxm, i, j);
  printf("\n Benötigte Streams pro Client Matrix");
  print_matrix(need, i, j); 
 }
 /* Stream Guthaben Zuweisungsalgorithmus */
 static bool
 stream_credit_allocation(int clients[],
            int avail[],
            int maxm[][S],
            int allot[][S])
 {
  int need[C][S];
  int i, p, k;
  int negative_credit;
  int finish[C];
  /* Funktion zur Berechnung wie viele Stream Guthaben jeder Client erfordert */
  calculateNeed(need, maxm, allot);
  /* Zähler zur Nachverfolgung der Stream Guthaben Anforderungen eines jeden Clients */
  for (i = 0 ; i < C ; i++) {
    finish[i] = 0; 
 }
 /* Erstelle eine Kopie der verfügbaren Streams */
 int work[S];
 for (i = 0; i < S; i++) {
   if (avail[i] < 0) {
     avail[i] = 0;
   }
   work[i] = avail[i]; 
 }
 /*
 * Bestimme für alle Clients, ob die Guthabenanforderung gewährt warden kann;
 * falls nicht, gib negative oder Null Guthaben an die Clients aus, um den
 * Modell Stream Guthaben Zuweisungszustand stabil zu machen
 */
 int count = 0; 

     while (count < C)
     {
      bool found = false;
      for (p = 0; p < C; p++)
      {
       /* Check if clients has the credit already granted */
       if (finish[p] == 0)
       {
         /*
         * Falls mehr verfügbare Streams vorhanden als benötigt, kann das Guthaben
 gewährt werden.
         * Falls weniger verfügbare Streams vorhanden als benötigt, sollen negative
 Guthaben gewährt werden und
         * es soll versucht warden sicherzustellen, dass das System in einem stabilen
 Streams Zuweisungszustand ist, um mehr Stream Guthaben zu gewähren.
         */
         int j;
         for (j =0; j < S; j++) {
                          /* Nachfrage größer als Angebot */
          if (need[p][j] > work[j]) {
           negative_credit = (need[p][j] - work[j]);
           /* Sag dem Client er soll sein zugewiesenes Guthaben um den Betrag des
 negative Guthabens zurückgeben */
           printf("Selbst-Sicherheitsprüfung durch Gewährung von negativen
 Guthaben=(%d) an Client = %d von Server = %d\n", negative _credit, p, j);
                                  allot[p] [j ] = allot[p] [j] - negative _credit;
                                  if (allot[p][j] < 0) {
                                    allot[p][j] = 0;
                                  }
                                  avail[j] += negative_credit;
                                  break;
          }
        }
        /* Alle Stream Nachfragen der Clients sind erfüllt */
                      if (j == S)
        {
          /*
          * Addiere dem aktuellen Client zugewiesene Streams
          * zu den verfügbaren Stream Aufzeichnungen.
         */
         for (k = 0; k < S; k++)
           work[k] += allot[p][k];
         count++;
         /* Stream Verarbeitung für diesen Client beendet */
         finish[p] = 1; 

         found = true;
        }
      } 
     }
          if (found == false)
          {
               printf("System ist nicht in sicherem Zustand\n");
               return false;
          } 
 }
     printf("System ist in sicherem Zustand. ");
     printf("\n");
  }return true; 
 }
 /* Streams Zuweisung durch Guthabenverteilung */
 int
 main()
 {
    int i = 0, j = 0, k = 0, count = 0;
    int clients[] = { 1, 2, 3 }; /* Array of clients ids */
       int client_requested_streams[4] = { 10, 20, 30, 40 };
       init_state();
    /* Stream Guthaben Zuweisungsalgorithmus */
    if (stream_credit_allocation(clients, available_streams, maxm, allot)) {
      printf("Stream Zuweisung ist in stabilem Zustand.\n"); 
    }*
    /*
    * Für alle Clients, fordere 10, 20, 40 and 40 Stream Guthaben von
    * einzelnen Servern.
    */
    for (i = 0; i < C; i++) { /* Client */
     for (j = 0; j < S; j++) {/* Streams von Server */
      for (k = 0; k < 4; k++) {
       printf("\n\n -------------- \n);
       printf("EXPERIMENT %d : Client C%d fordert %d Streams von Server N%d. \n",
          ++count, i, client requested treams[k], j);
       printf(''-------------- \n\n"),
       available_streams[j] = available_streams[j] - client_requested_streams[k];
          if (available_streams[j] < 0) { 
            available_streams[j] = 0;
       }
     allot[i][j] = allot[i][j] + client_requested_streams[k];
     /*
     * Versuche einen stabilen Streams Guthaben Zuweisungszustand zu erreichen
     * durch Gewährung negativer Guthaben an verschiedene Clients.
     */
     while (!stream_credit_allocation(clients, available_streams, maxm, allot)) {
      printf("Nach Gewährung negativer Guthaben Neuberechnung des Stream
  Zuweisungszustands ....\n");
         }
         printf("Stream Zuweisung ist in stabilem Zustand.\n");
         /* Zustand zurücksetzen */
         init_state();
        }
     }
  }
  return 0;
 }
  • Ergebnisse: Verfügbare Streams
    N1 N2 N3 N4
    30 10 10 20
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 20 20 10
    C1 10 0 30 30
    C2 10 20 10 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 10 0 10
    C1 0 20 0 10
    C2 0 10 40 0
    System ist in sicherem Zustand.
    Stream Zuweisung ist in stabilem Zustand.
  • EXPERIMENT 1 : Client C0 fordert 10 Streams von Server N0.
  • Verfügbare Streams
    N1 N2 N3 N4
    20 10 10 20
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 20 20 20 10
    C1 10 0 30 30
    C2 10 20 10 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 10 10 0 10
    C1 0 20 0 10
    C2 0 10 40 0
    System ist in sicherem Zustand.
    Stream Zuweisung ist in stabilem Zustand.
  • EXPERIMENT 2 : Client C0 fordert 20 Streams von Server N0.
  • Verfügbare Streams
    N1 N2 N3 N4
    10 10 10 20
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 30 20 20 10
    C1 10 0 30 30
    C2 10 20 10 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 0 10 0 10
    C1 0 20 0 10
    C2 0 10 40 0
    System ist in sicherem Zustand.
    Stream Zuweisung ist in stabilem Zustand.
  • EXPERIMENT 3 : Client C0 fordert 30 Streams von Server N0.
  • Verfügbare Streams
    N1 N2 N3 N4
    0 10 10 20
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 40 20 20 10
    C1 10 0 30 30
    C2 10 20 10 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 0 10 0 10
    C1 0 20 0 10
    C2 0 10 40 0
    System ist in sicherem Zustand.
    Stream Zuweisung ist in stabilem Zustand.
  • EXPERIMENT 4 : Client C0 fordert 40 Streams von Server N0.
  • Verfügbare Streams
    N1 N2 N3 N4
    0 10 10 20
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 50 20 20 10
    C1 10 0 30 30
    C2 10 20 10 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 0 10 0 10
    C1 0 20 0 10
    C2 0 10 40 0
    System ist in sicherem Zustand.
    Stream Zuweisung ist in stabilem Zustand.
  • EXPERIMENT 5 : Client C0 fordert 10 Streams von Server N1.
  • Verfügbare Streams
    N1 N2 N3 N4
    30 0 10 20
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 30 20 10
    C1 10 0 30 30
    C2 10 20 10 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 0 0 10
    C1 0 20 0 10
    C2 0 10 40 0
    System ist in sicherem Zustand.
    Stream Zuweisung ist in stabilem Zustand.
  • EXPERIMENT 6 : Client C0 fordert 20 Streams von Server N1.
  • Verfügbare Streams
    N1 N2 N3 N4
    30 0 10 20
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 40 20 10
    C1 10 0 30 30
    C2 10 20 10 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 0 0 10
    C1 0 20 0 10
    C2 0 10 40 0
    System ist in sicherem Zustand.
    Stream Zuweisung ist in stabilem Zustand.
  • EXPERIMENT 7 : Client C0 fordert 30 Streams von Server N1.
  • Verfügbare Streams
    N1 N2 N3 N4
    30 0 10 20
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 50 20 10
    C1 10 0 30 30
    C2 10 20 10 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 0 0 10
    C1 0 20 0 10
    C2 0 10 40 0
    System ist in sicherem Zustand.
    Stream Zuweisung ist in stabilem Zustand.
  • EXPERIMENT 8 : Client C0 fordert 40 Streams von Server N1.
  • Verfügbare Streams
    N1 N2 N3 N4
    30 0 10 20
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 60 20 10
    C1 10 0 30 30
    C2 10 20 10 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 0 0 10
    C1 0 20 0 10
    C2 0 10 40 0
    System ist in sicherem Zustand.
    Stream Zuweisung ist in stabilem Zustand.
  • EXPERIMENT 9 : Client C0 fordert 10 Streams von Server N2.
  • Verfügbare Streams
    N1 N2 N3 N4
    30 10 0 20
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 20 30 10
    C1 10 0 30 30
    C2 10 20 10 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 10 0 10
    C1 0 20 0 10
    C2 0 10 40 0
    System ist in sicherem Zustand.
    Stream Zuweisung ist in stabilem Zustand.
  • EXPERIMENT 10 : Client C0 fordert 20 Streams von Server N2.
  • Verfügbare Streams
    N1 N2 N3 N4
    30 10 0 20
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 20 40 10
    C1 10 0 30 30
    C2 10 20 10 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 10 0 10
    C1 0 20 0 10
    C2 0 10 40 0
    System ist in sicherem Zustand.
    Stream Zuweisung ist in stabilem Zustand.
  • EXPERIMENT 11 : Client C0 fordert 30 Streams von Server N2.
  • Verfügbare Streams
    N1 N2 N3 N4
    30 10 0 20
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 20 50 10
    C1 10 0 30 30
    C2 10 20 10 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 10 0 10
    C1 0 20 0 10
    C2 0 10 40 0
    System ist in sicherem Zustand.
    Stream Zuweisung ist in stabilem Zustand.
  • EXPERIMENT 12 : Client C0 fordert 40 Streams von Server N2.
  • Verfügbare Streams
    N1 N2 N3 N4
    30 10 0 20
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 20 60 10
    C1 10 0 30 30
    C2 10 20 10 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 10 0 10
    C1 0 20 0 10
    C2 0 10 40 0
    System ist in sicherem Zustand.
    Stream Zuweisung ist in stabilem Zustand.
  • EXPERIMENT 13 : Client C0 fordert 10 Streams von Server N3.
  • Verfügbare Streams
    N1 N2 N3 N4
    30 10 10 10
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 20 20 20
    C1 10 0 30 30
    C2 10 20 10 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 10 0 0
    C1 0 20 0 10
    C2 0 10 40 0
    System ist in sicherem Zustand.
    Stream Zuweisung ist in stabilem Zustand.
  • EXPERIMENT 14 : Client C0 fordert 20 Streams von Server N3.
  • Verfügbare Streams
    N1 N2 N3 N4
    30 10 10 0
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 20 20 30
    C1 10 0 30 30
    C2 10 20 10 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 10 0 0
    C1 0 20 0 10
    C2 0 10 40 0
    System ist in sicherem Zustand.
    Stream Zuweisung ist in stabilem Zustand.
  • EXPERIMENT 15 : Client C0 fordert 30 Streams von Server N3.
  • Verfügbare Streams
    N1 N2 N3 N4
    30 10 10 0
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 20 20 40
    C1 10 0 30 30
    C2 10 20 10 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 10 0 0
    C1 0 20 0 10
    C2 0 10 40 0
    System ist in sicherem Zustand.
    Stream Zuweisung ist in stabilem Zustand.
  • EXPERIMENT 16 : Client C0 fordert 40 Streams von Server N3.
  • Verfügbare Streams
    N1 N2 N3 N4
    30 10 10 0
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 20 20 50
    C1 10 0 30 30
    C2 10 20 10 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 10 0 0
    C1 0 20 0 10
    C2 0 10 40 0
    System ist in sicherem Zustand.
    Stream Zuweisung ist in stabilem Zustand.
  • EXPERIMENT 17 : Client C1 fordert 10 Streams von Server N0.
  • Verfügbare Streams
    N1 N2 N3 N4
    20 10 10 20
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 20 20 10
    C1 20 0 30 30
    C2 10 20 10 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 10 0 10
    C1 0 20 0 10
    C2 0 10 40 0
    System ist in sicherem Zustand.
    Stream Zuweisung ist in stabilem Zustand.
  • EXPERIMENT 18 : Client C1 fordert 20 Streams von Server N0.
  • Verfügbare Streams
    N1 N2 N3 N4
    10 10 10 20
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 20 20 10
    C1 30 0 30 30
    C2 10 20 10 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 10 0 10
    C1 0 20 0 10
    C2 0 10 40 0
    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(10) an Client = 0 von Server = 0
    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(10) an Client = 1 von Server = 1
    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(30) an Client = 2 von Server = 2
    System ist nicht in sicherem Zustand
    Nach Gewährung negativer Guthaben Neuberechnung des Stream Zuweisungszustands ....
  • Verfügbare Streams
    N1 N2 N3 N4
    20 20 40 20
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 0 20 20 10
    C1 30 0 30 30
    C2 10 20 0 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 30 10 0 10
    C1 0 20 0 10
    C2 0 10 50 0

    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(10) an Client = 0 von Server = 0
    System ist in sicherem Zustand.
    Stream Zuweisung ist in stabilem Zustand.
  • EXPERIMENT 19 : Client C1 fordert 30 Streams von Server N0.
  • Verfügbare Streams
    N1 N2 N3 N4
    0 10 10 20
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 20 20 10
    C1 40 0 30 30
    C2 10 20 10 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 10 0 10
    C1 0 20 0 10
    C2 0 10 40 0

    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(20) an Client = 0 von Server = 0
    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(10) an Client = 1 von Server = 1
    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(30) an Client = 2 von Server = 2
    System ist nicht in sicherem Zustand
    Nach Gewährung negativer Guthaben Neuberechnung des Stream Zuweisungszustands ....
  • Verfügbare Streams
    N1 N2 N3 N4
    20 20 40 20
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 0 20 20 10
    C1 40 0 30 30
    C2 10 20 0 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 30 10 0 10
    C1 0 20 0 10
    C2 0 10 50 0

    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(10) an Client = 0 von Server = 0
    System ist in sicherem Zustand.
    Stream Zuweisung ist in stabilem Zustand.
  • EXPERIMENT 20 : Client C1 fordert 40 Streams von Server N0.
  • Verfügbare Streams
    N1 N2 N3 N4
    0 10 10 20
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 20 20 10
    C1 50 0 30 30
    C2 10 20 10 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 10 0 10
    C1 0 20 0 10
    C2 0 10 40 0

    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(20) an Client = 0 von Server = 0
    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(10) an Client = 1 von Server = 1
    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(30) an Client = 2 von Server = 2
    System ist nicht in sicherem Zustand
    Nach Gewährung negativer Guthaben Neuberechnung des Stream Zuweisungszustands ....
  • Verfügbare Streams
    N1 N2 N3 N4
    20 20 40 20
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 0 20 20 10
    C1 50 0 30 30
    C2 10 20 0 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 30 10 0 10
    C1 0 20 0 10
    C2 0 10 50 0

    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(10) an Client = 0 von Server = 0
    System ist in sicherem Zustand.
    Stream Zuweisung ist in stabilem Zustand.
  • EXPERIMENT 21 : Client C1 fordert 10 Streams von Server N1.
  • Verfügbare Streams
    N1 N2 N3 N4
    30 0 10 20
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 20 20 10
    C1 10 10 30 30
    C2 10 20 10 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 10 0 10
    C1 0 10 0 10
    C2 0 10 40 0

    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(10) an Client = 0 von Server = 1
    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(10) an Client = 1 von Server = 1
    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(10) an Client = 2 von Server = 1
    System ist nicht in sicherem Zustand
    Nach Gewährung negativer Guthaben Neuberechnung des Stream Zuweisungszustands ....
  • Verfügbare Streams
    N1 N2 N3 N4
    30 30 10 20
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 10 20 10
    C1 10 0 30 30
    C2 10 10 10 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 20 0 10
    C1 0 20 0 10
    C2 0 20 40 0

    System ist in sicherem Zustand.
    Stream Zuweisung ist in stabilem Zustand.
  • EXPERIMENT 22 : Client C1 fordert 20 Streams von Server N1.
  • Verfügbare Streams
    N1 N2 N3 N4
    30 0 10 20
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 20 20 10
    C1 10 20 30 30
    C2 10 20 10 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 10 0 10
    C1 0 0 0 10
    C2 0 10 40 0

    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(10) an Client = 0 von Server = 1
    System ist in sicherem Zustand.
    Stream Zuweisung ist in stabilem Zustand.
  • EXPERIMENT 23 : Client C1 fordert 30 Streams von Server N1.
  • Verfügbare Streams
    N1 N2 N3 N4
    30 0 10 20
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 20 20 10
    C1 10 30 30 30
    C2 10 20 10 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 10 0 10
    C1 0 0 0 10
    C2 0 10 40 0

    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(10) an Client = 0 von Server = 1
    System ist in sicherem Zustand.
    Stream Zuweisung ist in stabilem Zustand.
  • EXPERIMENT 24 : Client C1 fordert 40 Streams von Server N1.
  • Verfügbare Streams
    N1 N2 N3 N4
    30 0 10 20
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 20 20 10
    C1 10 40 30 30
    C2 10 20 10 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 10 0 10
    C1 0 0 0 10
    C2 0 10 40 0

    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(10) an Client = 0 von Server = 1
    System ist in sicherem Zustand.
    Stream Zuweisung ist in stabilem Zustand.
  • EXPERIMENT 25 : Client C1 fordert 10 Streams von Server N2.
  • Verfügbare Streams
    N1 N2 N3 N4
    30 10 0 20
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 20 20 10
    C1 10 0 40 30
    C2 10 20 10 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 10 0 10
    C1 0 20 0 10
    C2 0 10 40 0

    System ist in sicherem Zustand.
    Stream Zuweisung ist in stabilem Zustand.
  • EXPERIMENT 26 : Client C1 fordert 20 Streams von Server N2.
  • Verfügbare Streams
    N1 N2 N3 N4
    30 10 0 20
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 20 20 10
    C1 10 0 50 30
    C2 10 20 10 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 10 0 10
    C1 0 20 0 10
    C2 0 10 40 0

    System ist in sicherem Zustand.
    Stream Zuweisung ist in stabilem Zustand.
  • EXPERIMENT 27 : Client C1 fordert 30 Streams von Server N2.
  • Verfügbare Streams
    N1 N2 N3 N4
    30 10 0 20
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 20 20 10
    C1 10 0 60 30
    C2 10 20 10 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 10 0 10
    C1 0 20 0 10
    C2 0 10 40 0

    System ist in sicherem Zustand.
    Stream Zuweisung ist in stabilem Zustand.
  • EXPERIMENT 28 : Client C1 fordert 40 Streams von Server N2.
  • Verfügbare Streams
    N1 N2 N3 N4
    30 10 0 20
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 20 20 10
    C1 10 0 70 30
    C2 10 20 10 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 10 0 10
    C1 0 20 0 10
    C2 0 10 40 0

    System ist in sicherem Zustand.
    Stream Zuweisung ist in stabilem Zustand.
  • EXPERIMENT 29 : Client C1 fordert 10 Streams von Server N3.
  • Verfügbare Streams
    N1 N2 N3 N4
    30 10 10 10
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 20 20 10
    C1 10 0 30 40
    C2 10 20 10 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 10 0 10
    C1 0 20 0 0
    C2 0 10 40 0

    System ist in sicherem Zustand.
    Stream Zuweisung ist in stabilem Zustand.
  • EXPERIMENT 30 : Client C1 fordert 20 Streams von Server N3.
  • Verfügbare Streams
    N1 N2 N3 N4
    30 10 10 0
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 20 20 10
    C1 10 0 30 50
    C2 10 20 10 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 10 0 10
    C1 0 20 0 0
    C2 0 10 40 0

    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(10) an Client = 0 von Server = 3
    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(10) an Client = 1 von Server = 1
    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(30) an Client = 2 von Server = 2
    System ist nicht in sicherem Zustand
    Nach Gewährung negativer Guthaben Neuberechnung des Stream Zuweisungszustands ....
  • Verfügbare Streams
    N1 N2 N3 N4
    30 20 40 10
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 20 20 0
    C1 10 0 30 50
    C2 10 20 0 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 10 0 20
    C1 0 20 0 0
    C2 0 10 50 0

    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(10) an Client = 0 von Server = 3
    System ist in sicherem Zustand.
    Stream Zuweisung ist in stabilem Zustand.
  • EXPERIMENT 31 : Client C1 fordert 30 Streams von Server N3.
  • Verfügbare Streams
    N1 N2 N3 N4
    30 10 10 0
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 20 20 10
    C1 10 0 30 60
    C2 10 20 10 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 10 0 10
    C1 0 20 0 0
    C2 0 10 40 0

    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(10) an Client = 0 von Server = 3
    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(10) an Client = 1 von Server = 1
    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(30) an Client = 2 von Server = 2
    System ist nicht in sicherem Zustand
    Nach Gewährung negativer Guthaben Neuberechnung des Stream Zuweisungszustands ....
  • Verfügbare Streams
    N1 N2 N3 N4
    30 20 40 10
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 20 20 0
    C1 10 0 30 60
    C2 10 20 0 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 10 0 20
    C1 0 20 0 0
    C2 0 10 50 0

    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(10) an Client = 0 von Server = 3
    System ist in sicherem Zustand.
    Stream Zuweisung ist in stabilem Zustand.
  • EXPERIMENT 32 : Client C1 fordert 40 Streams von Server N3.
  • Verfügbare Streams
    N1 N2 N3 N4
    30 10 10 0
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 20 20 10
    C1 10 0 30 70
    C2 10 20 10 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 10 0 10
    C1 0 20 0 0
    C2 0 10 40 0

    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(10) an Client = 0 von Server = 3
    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(10) an Client = 1 von Server = 1
    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(30) an Client = 2 von Server = 2
    System ist nicht in sicherem Zustand
    Nach Gewährung negativer Guthaben Neuberechnung des Stream Zuweisungszustands ....
  • Verfügbare Streams
    N1 N2 N3 N4
    30 20 40 10
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 20 20 0
    C1 10 0 30 70
    C2 10 20 0 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 10 0 20
    C1 0 20 0 0
    C2 0 10 50 0

    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(10) an Client = 0 von Server = 3
    System ist in sicherem Zustand.
    Stream Zuweisung ist in stabilem Zustand.
  • EXPERIMENT 33 : Client C2 fordert 10 Streams von Server N0.
  • Verfügbare Streams
    N1 N2 N3 N4
    20 10 10 20
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 20 20 10
    C1 10 0 30 30
    C2 20 20 10 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 10 0 10
    C1 0 20 0 10
    C2 0 10 40 0

    System ist in sicherem Zustand.
    Stream Zuweisung ist in stabilem Zustand.
  • EXPERIMENT 34 : Client C2 fordert 20 Streams von Server N0.
  • Verfügbare Streams
    N1 N2 N3 N4
    10 10 10 20
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 20 20 10
    C1 10 0 30 30
    C2 30 20 10 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 10 0 10
    C1 0 20 0 10
    C2 0 10 40 0

    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(10) an Client = 0 von Server = 0
    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(10) an Client = 1 von Server = 1
    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(30) an Client = 2 von Server = 2
    System ist nicht in sicherem Zustand
    Nach Gewährung negativer Guthaben Neuberechnung des Stream Zuweisungszustands ....
  • Verfügbare Streams
    N1 N2 N3 N4
    20 20 40 20
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 0 20 20 10
    C1 10 0 30 30
    C2 30 20 0 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 30 10 0 10
    C1 0 20 0 10
    C2 0 10 50 0

    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(10) an Client = 0 von Server = 0
    System ist in sicherem Zustand.
    Stream Zuweisung ist in stabilem Zustand.
  • EXPERIMENT 35 : Client C2 fordert 30 Streams von Server N0.
  • Verfügbare Streams
    N1 N2 N3 N4
    0 10 10 20
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 20 20 10
    C1 10 0 30 30
    C2 40 20 10 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 10 0 10
    C1 0 20 0 10
    C2 0 10 40 0

    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(20) an Client = 0 von Server = 0
    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(10) an Client = 1 von Server = 1
    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(30) an Client = 2 von Server = 2
    System ist nicht in sicherem Zustand
    Nach Gewährung negativer Guthaben Neuberechnung des Stream Zuweisungszustands ....
  • Verfügbare Streams
    N1 N2 N3 N4
    20 20 40 20
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 0 20 20 10
    C1 10 0 30 30
    C2 40 20 0 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 30 10 0 10
    C1 0 20 0 10
    C2 0 10 50 0

    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(10) an Client = 0 von Server = 0
    System ist in sicherem Zustand.
    Stream Zuweisung ist in stabilem Zustand.
  • EXPERIMENT 36 : Client C2 fordert 40 Streams von Server N0.
  • Verfügbare Streams
    N1 N2 N3 N4
    0 10 10 20
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 20 20 10
    C1 10 0 30 30
    C2 50 20 10 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 10 0 10
    C1 0 20 0 10
    C2 0 10 40 0

    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(20) an Client = 0 von Server = 0
    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(10) an Client = 1 von Server = 1
    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(30) an Client = 2 von Server = 2
    System ist nicht in sicherem Zustand
    Nach Gewährung negativer Guthaben Neuberechnung des Stream Zuweisungszustands ....
  • Verfügbare Streams
    N1 N2 N3 N4
    20 20 40 20
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 0 20 20 10
    C1 10 0 30 30
    C2 50 20 0 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 30 10 0 10
    C1 0 20 0 10
    C2 0 10 50 0

    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(10) an Client = 0 von Server = 0
    System ist in sicherem Zustand.
    Stream Zuweisung ist in stabilem Zustand.
  • EXPERIMENT 37 : Client C2 fordert 10 Streams von Server N1.
  • Verfügbare Streams
    N1 N2 N3 N4
    30 0 10 20
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 20 20 10
    C1 10 0 30 30
    C2 10 30 10 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 10 0 10
    C1 0 20 0 10
    C2 0 0 40 0

    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(10) an Client = 0 von Server = 1
    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(20) an Client = 1 von Server = 1
    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(30) an Client = 2 von Server = 2
    System ist nicht in sicherem Zustand
    Nach Gewährung negativer Guthaben Neuberechnung des Stream Zuweisungszustands ....
  • Verfügbare Streams
    N1 N2 N3 N4
    30 30 40 20
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 10 20 10
    C1 10 0 30 30
    C2 10 30 0 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 20 0 10
    C1 0 20 0 10
    C2 0 0 50 0

    System ist in sicherem Zustand.
    Stream Zuweisung ist in stabilem Zustand.
  • EXPERIMENT 38 : Client C2 fordert 20 Streams von Server N1.
  • Verfügbare Streams
    N1 N2 N3 N4
    30 0 10 20
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 20 20 10
    C1 10 0 30 30
    C2 10 40 10 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 10 0 10
    C1 0 20 0 10
    C2 0 0 40 0

    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(10) an Client = 0 von Server = 1
    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(20) an Client = 1 von Server = 1
    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(30) an Client = 2 von Server = 2
    System ist nicht in sicherem Zustand
    Nach Gewährung negativer Guthaben Neuberechnung des Stream Zuweisungszustands ....
  • Verfügbare Streams
    N1 N2 N3 N4
    30 30 40 20
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 10 20 10
    C1 10 0 30 30
    C2 10 40 0 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 20 0 10
    C1 0 20 0 10
    C2 0 0 50 0

    System ist in sicherem Zustand.
    Stream Zuweisung ist in stabilem Zustand.
  • EXPERIMENT 39 : Client C2 fordert 30 Streams von Server N1.
  • Verfügbare Streams
    N1 N2 N3 N4
    30 0 10 20
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 20 20 10
    C1 10 0 30 30
    C2 10 50 10 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 10 0 10
    C1 0 20 0 10
    C2 0 0 40 0

    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(10) an Client = 0 von Server = 1
    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(20) an Client = 1 von Server = 1
    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(30) an Client = 2 von Server = 2
    System ist nicht in sicherem Zustand
    Nach Gewährung negativer Guthaben Neuberechnung des Stream Zuweisungszustands ....
  • Verfügbare Streams
    N1 N2 N3 N4
    30 30 40 20
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 10 20 10
    C1 10 0 30 30
    C2 10 50 0 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 20 0 10
    C1 0 20 0 10
    C2 0 0 50 0

    System ist in sicherem Zustand.
    Stream Zuweisung ist in stabilem Zustand.
  • EXPERIMENT 40 : Client C2 fordert 40 Streams von Server N1.
  • Verfügbare Streams
    N1 N2 N3 N4
    30 0 10 20
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 20 20 10
    C1 10 0 30 30
    C2 10 60 10 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 10 0 10
    C1 0 20 0 10
    C2 0 0 40 0

    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(10) an Client = 0 von Server = 1
    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(20) an Client = 1 von Server = 1
    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(30) an Client = 2 von Server = 2
    System ist nicht in sicherem Zustand
    Nach Gewährung negativer Guthaben Neuberechnung des Stream Zuweisungszustands ....
  • Verfügbare Streams
    N1 N2 N3 N4
    30 30 40 20
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 10 20 10
    C1 10 0 30 30
    C2 10 60 0 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 20 0 10
    C1 0 20 0 10
    C2 0 0 50 0

    System ist in sicherem Zustand.
    Stream Zuweisung ist in stabilem Zustand.
  • EXPERIMENT 41 : Client C2 fordert 10 Streams von Server N2.
  • Verfügbare Streams
    N1 N2 N3 N4
    30 10 0 20
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 20 20 10
    C1 10 0 30 30
    C2 10 20 20 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 10 0 10
    C1 0 20 0 10
    C2 0 10 30 0

    System ist in sicherem Zustand.
    Stream Zuweisung ist in stabilem Zustand.
  • EXPERIMENT 42 : Client C2 fordert 20 Streams von Server N2.
  • Verfügbare Streams
    N1 N2 N3 N4
    30 10 0 20
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 20 20 10
    C1 10 0 30 30
    C2 10 20 30 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 10 0 10
    C1 0 20 0 10
    C2 0 10 20 0

    System ist in sicherem Zustand.
    Stream Zuweisung ist in stabilem Zustand.
  • EXPERIMENT 43 : Client C2 fordert 30 Streams von Server N2.
  • Verfügbare Streams
    N1 N2 N3 N4
    30 10 0 20
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 20 20 10
    C1 10 0 30 30
    C2 10 20 40 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 10 0 10
    C1 0 20 0 10
    C2 0 10 10 0

    System ist in sicherem Zustand.
    Stream Zuweisung ist in stabilem Zustand.
  • EXPERIMENT 44 : Client C2 fordert 40 Streams von Server N2.
  • Verfügbare Streams
    N1 N2 N3 N4
    30 10 0 20
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 20 20 10
    C1 10 0 30 30
    C2 10 20 50 0
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 10 0 10
    C1 0 20 0 10
    C2 0 10 0 0

    System ist in sicherem Zustand.
    Stream Zuweisung ist in stabilem Zustand.
  • EXPERIMENT 45 : Client C2 fordert 10 Streams von Server N3.
  • Verfügbare Streams
    N1 N2 N3 N4
    30 10 10 10
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 20 20 10
    C1 10 0 30 30
    C2 10 20 10 10
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 10 0 10
    C1 0 20 0 10
    C2 0 10 40 0

    System ist in sicherem Zustand.
    Stream Zuweisung ist in stabilem Zustand.
  • EXPERIMENT 46 : Client C2 fordert 20 Streams von Server N3.
  • Verfügbare Streams
    N1 N2 N3 N4
    30 10 10 0
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 20 20 10
    C1 10 0 30 30
    C2 10 20 10 20
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 10 0 10
    C1 0 20 0 10
    C2 0 10 40 0

    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(10) an Client = 0 von Server = 3
    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(10) an Client = 1 von Server = 1
    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(30) an Client = 2 von Server = 2
    System ist nicht in sicherem Zustand
    Nach Gewährung negativer Guthaben Neuberechnung des Stream Zuweisungszustands ....
  • Verfügbare Streams
    N1 N2 N3 N4
    30 20 40 10
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 20 20 0
    C1 10 0 30 30
    C2 10 20 0 20
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 10 0 20
    C1 0 20 0 10
    C2 0 10 50 0

    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(10) an Client = 0 von Server = 3
    System ist in sicherem Zustand.
    Stream Zuweisung ist in stabilem Zustand.
  • EXPERIMENT 47 : Client C2 fordert 30 Streams von Server N3.
  • Verfügbare Streams
    N1 N2 N3 N4
    30 10 10 0
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 20 20 10
    C1 10 0 30 30
    C2 10 20 10 30
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 10 0 10
    C1 0 20 0 10
    C2 0 10 40 0

    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(10) an Client = 0 von Server = 3
    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(10) an Client = 1 von Server = 1
    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(30) an Client = 2 von Server = 2
    System ist nicht in sicherem Zustand
    Nach Gewährung negativer Guthaben Neuberechnung des Stream Zuweisungszustands ....
  • Verfügbare Streams
    N1 N2 N3 N4
    30 20 40 10
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 20 20 0
    C1 10 0 30 30
    C2 10 20 0 30
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 10 0 20
    C1 0 20 0 10
    C2 0 10 50 0

    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(10) an Client = 0 von Server = 3
    System ist in sicherem Zustand.
    Stream Zuweisung ist in stabilem Zustand.
  • EXPERIMENT 48 : Client C2 fordert 40 Streams von Server N3.
  • Verfügbare Streams
    N1 N2 N3 N4
    30 10 10 0
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 20 20 10
    C1 10 0 30 30
    C2 10 20 10 40
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 10 0 10
    C1 0 20 0 10
    C2 0 10 40 0

    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(10) an Client = 0 von Server = 3
    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(10) an Client = 1 von Server = 1
    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(30) an Client = 2 von Server = 2
    System ist nicht in sicherem Zustand
    Nach Gewährung negativer Guthaben Neuberechnung des Stream Zuweisungszustands ....
  • Verfügbare Streams
    N1 N2 N3 N4
    30 20 40 10
  • Stream Zuweisung pro Client Matrix (Aktuelle Zuweisung)
    N1 N2 N3 N4
    C0 10 20 20 0
    C1 10 0 30 30
    C2 10 20 0 40
  • Maximale Stream Anforderungen pro Client Matrix
    N1 N2 N3 N4
    C0 30 30 20 20
    C1 10 20 30 40
    C2 10 30 50 0
  • Benötigte Streams pro Client Matrix
    N1 N2 N3 N4
    C0 20 10 0 20
    C1 0 20 0 10
    C2 0 10 50 0

    Selbst-Sicherheitsprüfung durch Gewährung von negativen Guthaben=(10) an Client = 0 von Server = 3
    System ist in sicherem Zustand.
    Stream Zuweisung ist in stabilem Zustand.

    • Claims (20)

    1. Verfahren zum Zuweisen von Ressourcen eines Servers zu mit dem Server verbundenen Clients für die verteilte Segmentverarbeitung durch den Server, wobei das Verfahren Folgendes umfasst: das Segmentieren von Daten, die in eine Datenschutzoperation aufgenommen werden sollen; das Abnehmen von Fingerabdrücken der Segmente, um Fingerabdrücke der Segmente zu generieren; das Anfordern von Segmentguthaben basierend auf einer Anzahl von Fingerabdrücken; das Gewähren der Segmentguthaben an den Client, wobei die Segmentguthaben zum Durchführen der verteilten Segmentverarbeitung verwendet werden; und das Durchführen der verteilten Segmentverarbeitung zum Identifizieren eindeutiger Fingerabdrücke unter den Fingerabdrücken der Segmente unter Verwendung der gewährten Segmentguthaben, wobei die eindeutigen Fingerabdrücke auf dem Server nicht gespeichert sind.
    2. Verfahren nach Anspruch 1, ferner umfassend zumindest eines von Folgendem: das Ausgeben der Segmentguthaben in einer Anzahl, die einer Anzahl der vom Client angeforderten Segmentguthaben entspricht; das Ausgeben der Segmentguthaben in einer Anzahl, die höher als die Anzahl der vom Client angeforderten Segmentguthaben ist; das Ausgeben der Segmentguthaben in einer Anzahl, die geringer als die Anzahl der vom Client angeforderten Segmentguthaben ist; das Ausgeben von Null-Segmentguthaben an den Client; oder das Ausgeben von negativen Segmentguthaben an den Client.
    3. Verfahren nach Anspruch 2, ferner umfassend das Deduplizieren der Segmente basierend auf Ergebnissen der verteilten Segmentverarbeitung.
    4. Verfahren nach Anspruch 2, ferner umfassend das Abgleichen der Fingerabdrücke mit einer Fingerabdruckdatenbank, um die eindeutigen Fingerabdrücke zu identifizieren.
    5. Verfahren nach Anspruch 2, ferner umfassend das Drosseln des Clients, wenn die Anzahl der gewährten Segmente bei null liegt oder negativ ist.
    6. Verfahren nach Anspruch 2, das Bestimmen einer Anzahl von Schreibvorgängen oder Segmentverarbeitungen, die durchschnittlich 1% einer CPU verbrauchen.
    7. Verfahren nach Anspruch 6, ferner umfassend das Bestimmen eines Durchschnitts der pro Kern zulässigen Lesevorgänge basierend auf der Anzahl von Schreibvorgängen oder Segmentverarbeitungen, die 1% der CPU und den durchschnittlichen freien Prozentsatz der CUP verbrauchen, und das Bestimmen eines maximalen Segmentguthabens pro Client basierend auf der Anzahl der Clientverbindungen.
    8. Verfahren nach Anspruch 7, ferner umfassend das Bestimmen einer berechneten Anzahl von Segmentguthaben pro Client basierend auf einem Abstimmungsfaktor, der auf die maximalen Segmentguthaben pro Client angewendet wird.
    9. Verfahren nach Anspruch 8, ferner umfassend das Ausgeben der Segmentguthaben in einer Anzahl, die einem Minimum der Anfrage oder der berechneten Anzahl von Segmentguthaben entspricht.
    10. Verfahren nach Anspruch 9, ferner umfassend das Ausgeben der verteilten Verarbeitungsguthaben in einer Anzahl, die einem Maximum der Anfrage oder der berechneten Anzahl von Guthaben entspricht.
    11. Nicht-transitorisches computerlesbares Medium, das computerausführbare Anweisungen zum Umsetzen eines Verfahrens zum Zuweisen von Ressourcen eines Servers zu mit dem Server verbundenen Clients für die verteilte Segmentverarbeitung durch den Server umfasst, wobei das Verfahren Folgendes umfasst: das Segmentieren von Daten, die in eine Datenschutzoperation aufgenommen werden sollen; das Abnehmen von Fingerabdrücken der Segmente, um Fingerabdrücke der Segmente zu generieren; das Anfordern von Segmentguthaben basierend auf einer Anzahl von Fingerabdrücken; das Gewähren der Segmentguthaben an den Client, wobei die Segmentguthaben zum Durchführen der verteilten Segmentverarbeitung verwendet werden; und das Durchführen der verteilten Segmentverarbeitung zum Identifizieren eindeutiger Fingerabdrücke unter den Fingerabdrücken der Segmente unter Verwendung der gewährten Segmentguthaben, wobei die eindeutigen Fingerabdrücke auf dem Server nicht gespeichert sind.
    12. Nicht-transitorisches computerlesbares Medium nach Anspruch 11, ferner umfassend zumindest eines von Folgendem: das Ausgeben der Segmentguthaben in einer Anzahl, die einer Anzahl der vom Client angeforderten Segmentguthaben entspricht; das Ausgeben der Segmentguthaben in einer Anzahl, die höher als die Anzahl der vom Client angeforderten Segmentguthaben ist; das Ausgeben der Segmentguthaben in einer Anzahl, die geringer als die Anzahl der vom Client angeforderten Segmentguthaben ist; das Ausgeben von Null-Segmentguthaben an den Client; oder das Ausgeben von negativen Segmentguthaben an den Client.
    13. Nicht-transitorisches computerlesbares Medium nach Anspruch 12, ferner umfassend das Deduplizieren der Segmente basierend auf Ergebnissen der verteilten Segmentverarbeitung.
    14. Nicht-transitorisches computerlesbares Medium nach Anspruch 12, ferner umfassend das Abgleichen der Fingerabdrücke mit einer Fingerabdruckdatenbank, um die eindeutigen Fingerabdrücke zu identifizieren.
    15. Nicht-transitorisches computerlesbares Medium nach Anspruch 12, ferner umfassend das Drosseln des Clients, wenn die Anzahl der gewährten Segmente bei null liegt oder negativ ist.
    16. Nicht-transitorisches computerlesbares Medium nach Anspruch 12, ferner umfassend das Bestimmen einer Anzahl von Schreibvorgängen oder Segmentverarbeitungen, die durchschnittlich 1% einer CPU verbrauchen.
    17. Nicht-transitorisches computerlesbares Medium nach Anspruch 16, ferner umfassend das Bestimmen eines Durchschnitts der pro Kern zulässigen Lesevorgänge basierend auf der Anzahl von Schreibvorgängen oder Segmentverarbeitungen, die 1% der CPU und den durchschnittlichen freien Prozentsatz der CUP verbrauchen, und das Bestimmen eines maximalen Segmentguthabens pro Client basierend auf der Anzahl der Clientverbindungen.
    18. Nicht-transitorisches computerlesbares Medium nach Anspruch 17, ferner umfassend das Bestimmen einer berechneten Anzahl von Segmentguthaben pro Client basierend auf einem Abstimmungsfaktor, der auf die maximalen Segmentguthaben pro Client angewendet wird.
    19. Nicht-transitorisches computerlesbares Medium nach Anspruch 18, ferner umfassend das Ausgeben der Segmentguthaben in einer Anzahl, die einem Minimum der Anfrage oder der berechneten Anzahl von Segmentguthaben entspricht.
    20. Nicht-transitorisches computerlesbares Medium nach Anspruch 19, ferner umfassend das Ausgeben der DSP-/Schreibguthaben in einer Anzahl, die einem Maximum der Anfrage oder der berechneten Anzahl von Guthaben entspricht.
    DE112019005038.9T 2018-10-08 2019-07-30 Ressourcenzuweisung unter verwendung von guthaben mit verteilter segmentverarbeitung Pending DE112019005038T5 (de)

    Applications Claiming Priority (3)

    Application Number Priority Date Filing Date Title
    US16/154,671 2018-10-08
    US16/154,671 US11005775B2 (en) 2018-10-08 2018-10-08 Resource allocation using distributed segment processing credits
    PCT/US2019/044209 WO2020076400A1 (en) 2018-10-08 2019-07-30 Resource allocation using distributed segment processing credits

    Publications (1)

    Publication Number Publication Date
    DE112019005038T5 true DE112019005038T5 (de) 2021-09-16

    Family

    ID=67614657

    Family Applications (1)

    Application Number Title Priority Date Filing Date
    DE112019005038.9T Pending DE112019005038T5 (de) 2018-10-08 2019-07-30 Ressourcenzuweisung unter verwendung von guthaben mit verteilter segmentverarbeitung

    Country Status (5)

    Country Link
    US (3) US11005775B2 (de)
    CN (1) CN112823338B (de)
    DE (1) DE112019005038T5 (de)
    GB (1) GB2591930B (de)
    WO (1) WO2020076400A1 (de)

    Families Citing this family (2)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    US20220283997A1 (en) * 2021-03-03 2022-09-08 EMC IP Holding Company LLC Efficient method to optimize distributed segment processing mechanism in dedupe systems by leveraging the locality principle
    US11797187B2 (en) * 2021-06-28 2023-10-24 QoS Tech LLC Optimized I/O performance regulation for non-volatile storage

    Family Cites Families (74)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    US3350702A (en) 1965-01-26 1967-10-31 Ruth A Herman Infrared detection system for fault isolation and failure prediction
    US5453982A (en) * 1994-08-29 1995-09-26 Hewlett-Packard Company Packet control procedure between a host processor and a peripheral unit
    US5956321A (en) * 1995-03-16 1999-09-21 Kabushiki Kaisha Toshiba Stream scheduling system for real time stream server
    US5586121A (en) 1995-04-21 1996-12-17 Hybrid Networks, Inc. Asymmetric hybrid access system and method
    US6002667A (en) * 1995-07-19 1999-12-14 Fujitsu Network Communications, Inc. Minimum guaranteed cell rate method and apparatus
    US5812545A (en) * 1996-01-04 1998-09-22 Orion Atlantic, L.P. Full mesh satellite-based multimedia networking system
    US5778320A (en) 1996-10-04 1998-07-07 Motorola, Inc. Method for allocating communication resources among groups of communication units
    US6438141B1 (en) * 1998-04-20 2002-08-20 Sun Microsystems, Inc. Method and management of communications over media of finite bandwidth
    US6459901B1 (en) 1999-07-01 2002-10-01 At&T Corp. Wireless network resource allocation
    US6467024B1 (en) 1999-09-07 2002-10-15 International Business Machines Corporation Accessing data volumes from data storage libraries in a redundant copy synchronization token tracking system
    US6502165B1 (en) 1999-12-03 2002-12-31 International Business Machines Corporation Balanced access to data volumes with redundant copies stored in data storage libraries
    US6625709B2 (en) 2000-10-30 2003-09-23 Microsoft Corporation Fair share dynamic resource allocation scheme with a safety buffer
    AU2002304842A1 (en) 2001-08-20 2003-03-10 Datacentertechnologies N.V. File backup system and method
    US7155475B2 (en) 2002-02-15 2006-12-26 Sony Corporation System, method, and computer program product for media publishing request processing
    US7539735B2 (en) 2002-03-06 2009-05-26 International Business Machines Corporation Multi-session no query restore
    US7398557B2 (en) 2002-09-13 2008-07-08 Sun Microsystems, Inc. Accessing in a rights locker system for digital content access control
    US7539199B2 (en) * 2003-02-21 2009-05-26 Gireesh Shrimali Switch fabric scheduling with fairness and priority consideration
    US7269697B1 (en) 2003-05-07 2007-09-11 Avago Technologies General Ip (Singapore) Pte. Ltd. Apparatus and methodology for an input port scheduler
    US7519725B2 (en) 2003-05-23 2009-04-14 International Business Machines Corporation System and method for utilizing informed throttling to guarantee quality of service to I/O streams
    US7698115B2 (en) 2003-06-30 2010-04-13 Microsoft Corporation System and method for dynamically allocating resources in a client/server environment
    JP4235506B2 (ja) 2003-08-14 2009-03-11 株式会社エヌ・ティ・ティ・ドコモ 送信装置、中継装置およびプログラム
    EP1523134B1 (de) 2003-10-06 2010-12-15 TELEFONAKTIEBOLAGET LM ERICSSON (publ) Koordinierte Datenflusssteuerung und Datenpufferteilung in UMTS
    JP4611319B2 (ja) 2004-02-16 2011-01-12 デービーズ，クリストファー，マイケル ネットワークアーキテクチャ
    US7478158B1 (en) 2004-03-01 2009-01-13 Adobe Systems Incorporated Bandwidth management system
    US7583658B1 (en) 2004-06-17 2009-09-01 Cisco Technology, Inc. Signal processing allocation using credit prediction
    US7493426B2 (en) 2005-01-31 2009-02-17 International Business Machines Corporation Data communication method and apparatus utilizing programmable channels for allocation of buffer space and transaction control
    US7814242B1 (en) 2005-03-25 2010-10-12 Tilera Corporation Managing data flows in a parallel processing environment
    DE502005009040D1 (de) 2005-09-12 2010-04-01 Siemens Ag Verfahren zur Steuerung eines Zugriffs auf Ressourcen eines Datenverarbeitungssystems und Steuerungsprogramm
    US7716180B2 (en) * 2005-12-29 2010-05-11 Amazon Technologies, Inc. Distributed storage system with web services client interface
    US7685306B2 (en) 2006-01-20 2010-03-23 Microsoft Corporation Streaming content navigation
    JP2007241419A (ja) 2006-03-06 2007-09-20 Fujitsu Ltd 入力支援装置、入力支援プログラムおよび入力支援方法
    US7698478B2 (en) 2006-09-19 2010-04-13 Apple Inc. Managed credit update
    US7872975B2 (en) 2007-03-26 2011-01-18 Microsoft Corporation File server pipelining with denial of service mitigation
    US20080307094A1 (en) 2007-06-11 2008-12-11 Olli Karonen Association of peer-to-peer contribution credits with multiple devices
    US7707248B2 (en) * 2007-06-25 2010-04-27 Microsoft Corporation Credit-based peer-to-peer storage
    US20090171812A1 (en) 2007-12-31 2009-07-02 Apple Inc. Media streams and media store
    US8306036B1 (en) 2008-06-20 2012-11-06 F5 Networks, Inc. Methods and systems for hierarchical resource allocation through bookmark allocation
    US20100031157A1 (en) 2008-07-30 2010-02-04 Robert Neer System that enables a user to adjust resources allocated to a group
    US8374576B2 (en) 2008-12-04 2013-02-12 At&T Intellectual Property I, L.P. Methods, systems, and computer program products for generating resource utilization alerts through communication terminals
    US8045472B2 (en) 2008-12-29 2011-10-25 Apple Inc. Credit management when resource granularity is larger than credit granularity
    US20120327779A1 (en) 2009-06-12 2012-12-27 Cygnus Broadband, Inc. Systems and methods for congestion detection for use in prioritizing and scheduling packets in a communication network
    US8085801B2 (en) 2009-08-08 2011-12-27 Hewlett-Packard Development Company, L.P. Resource arbitration
    US20110184998A1 (en) 2010-01-22 2011-07-28 Palahnuk Samuel L Universally accessible encrypted internet file system for wired and wireless computing devices supplanting synchronization, backup and email file attachment
    US8381217B1 (en) * 2010-04-30 2013-02-19 Netapp, Inc. System and method for preventing resource over-commitment due to remote management in a clustered network storage system
    JP5541718B2 (ja) 2010-08-19 2014-07-09 キヤノン株式会社 撮像装置及びその欠陥画素検出方法
    US9253159B2 (en) 2011-05-06 2016-02-02 Citrix Systems, Inc. Systems and methods for cloud bridging between public and private clouds
    US8863140B2 (en) * 2011-08-29 2014-10-14 Oracle International Corporation Method for resource management allocating and freeing credits from and to a resource credit tree
    US20130061233A1 (en) * 2011-09-02 2013-03-07 Exludus Inc. Efficient method for the scheduling of work loads in a multi-core computing environment
    US10200493B2 (en) 2011-10-17 2019-02-05 Microsoft Technology Licensing, Llc High-density multi-tenant distributed cache as a service
    US9838269B2 (en) 2011-12-27 2017-12-05 Netapp, Inc. Proportional quality of service based on client usage and system metrics
    US8763154B2 (en) 2012-01-23 2014-06-24 Verizon Patent And Licensing Inc. Federated authentication
    US9619127B2 (en) 2012-04-17 2017-04-11 Netzero Wireless, Inc. User controlled data speed selector systems and methods
    US9507639B2 (en) 2012-05-06 2016-11-29 Sandisk Technologies Llc Parallel computation with multiple storage devices
    US9495379B2 (en) * 2012-10-08 2016-11-15 Veritas Technologies Llc Locality aware, two-level fingerprint caching
    US9055078B2 (en) 2013-01-10 2015-06-09 International Business Machines Corporation Token-based flow control of messages in a parallel computer
    US20150007189A1 (en) * 2013-06-29 2015-01-01 Robert de Gruijl Service rate redistribution for credit-based arbitration
    US9477526B2 (en) * 2013-09-04 2016-10-25 Nvidia Corporation Cache utilization and eviction based on allocated priority tokens
    US20160005007A1 (en) 2014-07-04 2016-01-07 Flashback Survey, Inc. Methods and systems for using scanable codes to obtain maintenance and reminder services
    US10110300B2 (en) * 2014-09-08 2018-10-23 Hughes Network Systems, Llc Bandwidth management across logical groupings of access points in a shared access broadband network
    US10419621B2 (en) 2014-11-14 2019-09-17 Tracfone Wireless, Inc. Methods, systems and applications for managing wireless services on a wireless device
    CN106301805B (zh) * 2015-05-11 2019-12-17 华为技术有限公司 一种策略和计费执行功能装置、在线计费装置及在线计费方法
    WO2017070797A1 (en) 2015-10-30 2017-05-04 Investel Capital Corporation Data network access selection, migration and quality management systems and methods
    US10115214B2 (en) 2015-11-03 2018-10-30 Verizon Patent And Licensing Inc. Shared data splitting interface
    CN105487818B (zh) * 2015-11-27 2018-11-09 清华大学 针对云存储系统中重复冗余数据的高效去重方法
    US10007457B2 (en) * 2015-12-22 2018-06-26 Pure Storage, Inc. Distributed transactions with token-associated execution
    US20170208120A1 (en) 2016-01-15 2017-07-20 Google Inc. Probabilistic throttling
    US10146665B2 (en) * 2016-03-24 2018-12-04 Oracle International Corporation Systems and methods for providing dynamic and real time simulations of matching resources to requests
    US10146684B2 (en) * 2016-10-24 2018-12-04 Datrium, Inc. Distributed data parallel method for reclaiming space
    CA3054407A1 (en) * 2017-02-23 2018-08-30 John Mezzalingua Associates, LLC System and method for adaptively tracking and allocating capacity in a broadly-dispersed wireless network
    US10536482B2 (en) * 2017-03-26 2020-01-14 Microsoft Technology Licensing, Llc Computer security attack detection using distribution departure
    US11500681B2 (en) 2017-06-29 2022-11-15 Intel Corporation Technologies for managing quality of service platform interconnects
    US10469395B2 (en) 2017-08-31 2019-11-05 Hewlett Packard Enterprise Development Lp Packet transmission credit allocation
    US20190348158A1 (en) * 2018-05-11 2019-11-14 Michigan Health Information Network Shared Services Systems and methods for managing data privacy
    US11201828B2 (en) 2018-10-08 2021-12-14 EMC IP Holding Company LLC Stream allocation using stream credits

    Also Published As

    Publication number Publication date
    CN112823338B (zh) 2024-02-20
    WO2020076400A1 (en) 2020-04-16
    US20220407817A1 (en) 2022-12-22
    GB2591930B (en) 2022-12-14
    US20210203614A1 (en) 2021-07-01
    US11005775B2 (en) 2021-05-11
    CN112823338A (zh) 2021-05-18
    GB2591930A (en) 2021-08-11
    US11431647B2 (en) 2022-08-30
    US20200112521A1 (en) 2020-04-09
    GB202104657D0 (en) 2021-05-12
    US11765099B2 (en) 2023-09-19

    Similar Documents

    Publication Publication Date Title
    DE112011100819B4 (de) Speicherplatzreservierung in einem Deduplizierungssystem
    DE112012004336B4 (de) System, Verfahren und Programmprodukt für kostenbewusste Auswahl von Vorlagen zum Bereitstellen von gemeinsam genutzten Ressourcen
    DE112012004999T5 (de) Beschleunigungselement zur Cloud-Bereitstellung
    DE10296791T5 (de) Auswahl einer Ressource in einem verteilten Rechnersystem
    DE112019006784T5 (de) Skalierbare Datenbereinigung für die deduplizierte Speicherung
    DE202012013432U1 (de) Speichern von Daten auf Speicherknoten
    DE112011101633T5 (de) Virtualisierung und dynamische Ressourcenzuweisung berücksichtigendes Neuordnen von Speicherebenen
    DE112012002762T5 (de) Replikationen von Datenobjekten von einem Quellserver auf einen Zielserver
    DE112012005275T5 (de) Datenauswahl zur Sicherung von Datenspeichern
    DE112018006769B4 (de) Erweiterte zwischenspeicherzuweisung basierend auf virtuellen knotenressourcen
    DE112011100094T5 (de) Verfahren und System zum Abstrahieren eines auf nichtfunktionalen Anforderungen beruhenden Einsatzes von virtuellen Maschinen
    DE102013204186A1 (de) Ermitteln von Prioritäten für zwischengespeicherte Objekte zum Ordnen des Übertragens von Änderungen an zwischengespeicherten Objekten beruhend auf gemessener Netzwerkbandbreite
    DE112019005043T5 (de) Streamzuweisung unter verwendung von stream-guthaben
    DE112010003675T5 (de) Adress-Server
    DE112021000390T5 (de) Anpassen der leistung eines datenverarbeitungssystems
    DE112019006530T5 (de) Markieren von betroffenen ähnlichkeitsgruppen in freispeichersammeloperationen in duplizierten speichersystemen
    US11765099B2 (en) Resource allocation using distributed segment processing credits
    DE102018209188A1 (de) Technologien zum Verwalten der Dienstgüte für Plattformverbindungen
    DE102020112531A1 (de) Operationelle metrische Berechnung für Arbeitsbelastungstyp
    DE112019005042T5 (de) Ressourcenzuweisung unter verwendung von wiederherstellungsguthaben
    DE102005048729B4 (de) Verfahren und Systeme zum Defragmentieren eines Teilnetzraums innerhalb einer adaptiven Infrastruktur
    DE102016109565A1 (de) Verwalten einer Speicherung von digitalem Inhalt
    DE202013012479U1 (de) System zur Commit Ausführung von Transaktionen auf entfernten Servern
    DE102016125020B4 (de) Verfahren zum Betreiben eines Druckservers für digitale Hochleistungsdrucksysteme
    DE102013205739A1 (de) Programmgestütztes lastbasiertes verwalten der prozessorbelegung

    Legal Events

    Date Code Title Description
    R012 Request for examination validly filed