DE112019005042T5 - Ressourcenzuweisung unter verwendung von wiederherstellungsguthaben - Google Patents

Ressourcenzuweisung unter verwendung von wiederherstellungsguthaben Download PDF

Info

Publication number
DE112019005042T5
DE112019005042T5 DE112019005042.7T DE112019005042T DE112019005042T5 DE 112019005042 T5 DE112019005042 T5 DE 112019005042T5 DE 112019005042 T DE112019005042 T DE 112019005042T DE 112019005042 T5 DE112019005042 T5 DE 112019005042T5
Authority
DE
Germany
Prior art keywords
client
credits
streams
stream
server
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
DE112019005042.7T
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 DE112019005042T5 publication Critical patent/DE112019005042T5/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
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1458—Management of the backup or restore process
    • G06F11/1464—Management of the backup or restore process for networked environments
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1446—Point-in-time backing up or restoration of persistent data
    • G06F11/1458—Management of the backup or restore process
    • G06F11/1469—Backup restoration techniques
    • 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/80—Actions related to the user profile or the type of traffic
    • H04L47/805—QOS or priority aware
    • 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
    • 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/50—Network services
    • H04L67/56—Provisioning of proxy services
    • H04L67/568—Storing data temporarily at an intermediate stage, e.g. caching
    • 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

Abstract

Systeme und Verfahren zum Zuweisen von Ressourcen werden offenbart. Ressourcen, wie z.B. Streams, werden unter Verwendung von Wiederherstellungsguthaben 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. Wiederherstellungsguthaben sind mit Lesevorgängen 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 Stream- oder Ressourcenzuweisung bei der Durchführung von Datenschutzoperationen, wie z.B. Wiederherstellungsvorgängen. 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 eine Ressourcenzuweisung, einschließlich einer Streamzuweisung im Rahmen von Cluster- oder Serverressourcen, näher veranschaulicht;
    • 3A ein Beispiel für ein Verfahren zum Durchführen einer Ressourcenzuweisung und insbesondere zum Zuweisen von Streams in einer Datenverarbeitungsumgebung veranschaulicht;
    • 3B ein Beispiel für ein Verfahren zum Auswerten eines Streamzuweisungsstatus eines Knotens oder eines Servers oder eines Clusters veranschaulicht; und
    • 3C das Verfahren zum Auswerten des Streamzuweisungsstatus der 3B näher veranschaulicht;
    • 4 ein Beispiel für ein System veranschaulicht, in dem Wiederherstellungsguthaben anfragenden Clients zugewiesen werden; und
    • 5 ein Flussdiagramm ist, das ein Beispiel für ein Verfahren zum Durchführen einer Ressourcenzuweisung während einer Datenschutzoperation, wie z.B. eines Wiederherstellungsvorgangs, 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, zum Zuweisen von Wiederherstellungsguthaben beispielsweise beim Durchführen von Wiederherstellungsvorgängen.
  • 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. 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.
  • 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 Streams. Ein Client könnte in der Lage sein, mehrere Streams mit mehreren Servern einzurichten. Ein Server kann ebenso mehrere Streams mit mehreren Clients einrichten.
  • Diese Ressourcen (und/oder andere Ressourcen, einschließlich Leseressourcen, Schreibressourcen, Verarbeitungsressourcen etc.) werden so zugewiesen, dass der Cluster-Server 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 wird mittels eines Guthabensystems erzielt. 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 Guhaben 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.
  • 1 zeigt einen Server (z.B. einen Datenschutz- oder Sicherungsserver) 110, der Ressourcen für Clients bereitstellt, 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 konfiguriert, um den Clients 102, 104, 106 und 108 Streams zuzuweisen. Der Server 102 ist konfiguriert, um eine Streamzuweisung durchzuführen, wobei in einem Beispiel Stream-Guthaben verwendet werden. Die Stream-Guthaben können unter Verwendung einer Ressourcenzuweisungstabelle 120 verwaltet werden, die eine Bestimmung des Zuweisungsstatus (z.B. sicher, unsicher) ermöglicht. Immer wenn Guthaben ausgegeben werden (unabhängig vom Typ), wird die Zuweisungstabelle 120 aktualisiert, so dass nachfolgende Anfragen ausgewertet werden können.
  • In einem Beispiel wird eine Anfrage nach Stream-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. Anders ausgedrückt, 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 Streams pro Guthaben gewähren. Der Server 110 könnte einem anfragenden Client ein Stream-Guthaben gewähren, wenn es möglich ist, dass alle Streams, 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 Stream-Guthaben verschiedene Clients zum Zeitpunkt der Beendigung des bestimmten Client-Streams angefordert haben werden, darf der Server 110 davon ausgehen, dass alle Clients letztendlich versuchen werden, ihre maximal zulässigen Stream-Guthaben zu erwerben, die Stream-Guthaben zu verwenden und die Stream-Guthaben dann freizugeben.
  • Unter diesen Voraussetzungen kann der Server feststellen, ob der Streamzuweisungsstatus sicher ist, indem er einen hypothetischen Satz von Stream-Guthabenanfragen durch die Clients findet, der es jedem Client ermöglichen würde, sein Maximum an angeforderten Stream-Guthaben zu erwerben und die Stream-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 Stream-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.
  • 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). Die nachfolgende Erörterung betreffend Stream-Guthaben umfasst Folgendes. Dieses Zuweisungsverfahren wird unter Bezugnahme auf die nachstehend beschriebenen 3B und 3C 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 [ C 0 ] + CALM [ C 1 ] + … + CALM [ CN ] ) ;
    Figure DE112019005042T5_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 ] = CDM [ i , j ] − CALM [ i , j ] .
    Figure DE112019005042T5_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 DE112019005042T5_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. 2 zeigt einen Cluster, der Knoten oder Server 202 und Clients 204 enthält. 2 zeigt im Speziellen vier Knoten oder Server: N1, N2, N3 und N4. 2 zeigt auch die Clients C1, C2 und C3 (Clients 204), die Ressourcen der Server 202 nutzen. In diesem Beispiel umfassen die Ressourcen der Server 202, die den Clients 204 zugewiesen sind, Streams 206. Die Streams 206 können Sicherungsstreams, Wiederherstellungsstreams oder andere Datenstreams umfassen.
  • Gehen wir beispielsweise davon aus, dass in 2 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 DE112019005042T5_0004
    Figure DE112019005042T5_0005
  • Ganz allgemein erkennt die CAM, welche Knoten oder Server die den Clients 204 zugewiesenen Streams bereitstellen. Wie zuvor angegeben, können die Clients 204 eine Verbindung zu jedem der Server 202 herstellen und daher Guthaben von jedem der Server 202 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 DE112019005042T5_0006
  • 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 >
    Figure DE112019005042T5_0007
  • 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 204 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 DE112019005042T5_0008
  • 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 DE112019005042T5_0009
  • 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 202 kann einen oder mehrere der Clients 204 drosseln und den unsicheren Zuweisungsstatus durch Ausgabe negativer Guthaben überwinden. Anders ausgedrückt, die Server 202 ü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.
  • Stream-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.
  • 3A 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 302 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 300 kann zu einem einzigen Zeitpunkt durchgeführt werden. Dieser Aspekt des Verfahrens 300 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 202 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 300 das Zuweisungsverfahren oder führt es aus. Eine Anfrage nach Stream-Guthaben kann beispielsweise empfangen werden 304. 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 306. 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 308 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.
  • 3B zeigt ausführlicher ein Beispiel für das Auswerten des Streamstatus. 3B zeigt im Speziellen ein Beispiel für das Auswerten des in 3A dargestellten Serverstreamstatus 306. Somit stellt das Verfahren 320 ein Beispiel für das Auswerten des Serverstreamstatus 306 dar. In einem Beispiel des Verfahrens 320 kann der Server die TAM 322 berechnen, welche die insgesamt verfügbaren Streams bestimmt. Der Server kann dann in der CALM 324 nachschlagen. Die CALM identifiziert die Streams, die den Clients aktuell zugewiesen sind.
  • Als nächstes wird die CAM zu einem Zeitpunkt bestimmt 326. 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 328, und die CNMs werden bestimmt 330, indem die CALM von der CDM abgezogen wird (CNM = CDM - CALM).
  • Nach Ermittlung dieser Information erfolgt die Bestimmung 332, ob der Streamzuweisungsstatus sicher oder unsicher ist. Wenn der Streamzuweisungsstatus nicht sicher ist, werden Null- oder negative Guthaben gewährt 340. Wenn der Streamzuweisungsstatus sicher ist, werden Guthaben gewährt. Es können zum Beispiel partielle Guthaben gewährt werden 334, gleiche Guthaben können gewährt werden 336, oder Prefetch-Guthaben können gewährt werden 338. Die Guthaben werden dann ausgegeben 308. In einem Beispiel kann das Ausgeben von Guthaben 308 Teil des Verfahrens 320 sein und ist in das Gewähren von Guthaben 334, 336, 338 oder 340 integriert.
  • 3C zeigt ein Beispiel für das Bestimmen eines Streamzuweisungsstatus. 3C zeigt im Speziellen ein Beispiel für das Bestimmen, ob der Streamzuweisungsstatus in 3B sicher ist 332. Das Verfahren 348 kann für jeden Client 350 durchgeführt werden. Beginnend mit einem ersten Client 350 erfolgt eine Bestimmung, um festzustellen 352, ob CNM größer als CDM ist. Wenn die aktuelle Nachfrage nicht größer als der aktuelle Bedarf ist, ist der Status somit unsicher 354 und negative oder Null-Guthaben werden ausgegeben oder gewährt, wie in 3B 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 356. 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 (356) bestimmt, indem die Streams, die vom Client erworben wurden, um den maximalen Bedarf 360 des Clients zu erreichen, von der Anzahl der aktuell verfügbaren Streams 358 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 362. 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 356 erfolgt die Bestimmung, ob die verfügbaren Streams geringer als die insgesamt verfügbare Matrix 364 sind. Wenn nicht, ist der Status unsicher 366. Wenn dies der Fall ist und alle Clients verarbeitet wurden 368, ist der Status sicher 372, und die Guthaben können gewährt werden, wie in 3B dargestellt. Wenn nicht alle Clients verarbeitet werden, wird der nächste Client verarbeitet 370.
  • Die 3A-3C 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.
  • Neben Stream-Guthaben beziehen sich Ausführungsformen der Erfindung auch auf Wiederherstellungsguthaben, die ein anderes Beispiel für Guthaben darstellen. Ein Wiederherstellungsvorgang kann das Auslesen von Daten aus einer von einem Sicherungsserver verwalteten Sicherung und das Übermitteln oder Senden der aus der Sicherung ausgelesenen Daten an einen Wiederherstellungssort oder ein Wiederherstellungsgerät umfassen. In einem Beispiel können sich die Ressourcenzuweisungssysteme und -verfahren ausschließlich auf die Wiederherstellungsguthaben, die in Bezug auf Daten definiert sein können (z.B. 1 Guthaben = 256 MG oder 500 MB oder 1 GB etc. der ausgelesenen Daten), und/oder auf Stream-Guthaben, wie zuvor beschrieben, stützen.
  • Wiederherstellungsguthaben verbessern den Betrieb eines Clients oder Servers, indem sie einem Client bei der Zuweisung/Dimensionierung seines Vorauslese-Cache helfen, einem Client helfen, eine intelligente Vorauslesung durchzuführen, und die Leistung des Wiederherstellungsvorgangs verbessern. Außerdem helfen Ausführungsformen der Erfindung dabei, nur Daten wiederherzustellen, die benötigt werden. Dadurch können Kosten im Zusammenhang mit Daten vermieden werden, die für einen Wiederherstellungsvorgang nicht erforderlich sind.
  • Im Speziellen implementieren Clients häufig eine Vorauslese-Zwischenspeicherung und lesen möglicherweise mehr Daten aus, die erforderlich sind. Dies kann beispielsweise in einer Cloud-Umgebung ein Problem sein, in der die Kosten pro Wiederherstellungsbyte ermittelt werden. Anders ausgedrückt, das Auslesen von mehr Daten als erforderlich kann teuer sein. Ausführungsformen der Erfindung ermöglichen die Dimensionierung oder Abstimmung des Vorauslese-Cache oder -Puffers eines Clients basierend auf der Größe der Daten, die wiederhergestellt werden. Dies ist nützlich, da der Client in einem Beispiel die Größe der wiederherzustellenden Daten möglicherweise nicht kennt. Der Server kann die Zuweisung und Größe des Vorauslese-Cache des Clients unterstützen, indem er Prefetch-Wiederherstellungsguthaben bereitstellt.
  • 4 zeigt beispielsweise ein Beispiel für einen Client, der einen Wiederherstellungsvorgang unter Verwendung von Wiederherstellungsguthaben und/oder Stream-Guthaben ausführt. Der Server (oder ein Cluster) kann möglicherweise mehrere Clients unter Verwendung von Wiederherstellungs- und/oder Stream-Guthaben unterstützen.
  • In 4 stellt ein Client 402 wiederhergestellte Daten 406 im Speicher 404 (oder einer anderen Vorrichtung/Maschine) wieder her. Bei den wiederhergestellten Daten 406 kann es sich um eine Datenbank, eine virtuelle Maschine, ein Dateisystem oder dergleichen handeln. Beim Durchführen des Wiederherstellungsvorgangs werden die wiederhergestellten Daten 4006 aus den Sicherungen 412 (z.B. einer bestimmten Sicherung) wiederhergestellt. Aus den Sicherungen 412 ausgelesene Daten werden somit vom Server 408 gelesen und an den Client 402 übermittelt. Der Client schreibt dann die Daten in die wiederhergestellten Daten 406.
  • In diesem Beispiel kann der Client 402 Wiederherstellungsguthaben vom Server 408 (z.B. von einem Sicherungsserver) anfordern. Der Server 408 kann eine Zuweisungstabelle 414 verwalten, welche die Nachverfolgung von Wiederherstellungsguthaben und/oder Stream-Guthaben ermöglicht. In diesem Beispiel kennt der Client 402 die Größe des wiederherzustellenden Datensatzes nicht. Der Server 408 kennt jedoch möglcherweise die Größe des Datensatzes, da dieser Kontext auf dem Server 408 vorhanden ist.
  • Unter der rein beispielhaften Annahme, dass 256 MB Daten einem Wiederherstellungsguthaben zugeordnet sind, könnten die folgenden Szenarien auftreten. Der Client 402 möchte 1 GB Daten auslesen und könnte daher 4 Wiederherstellungsguthaben vom Server 408 anfordern. Der Client könnte auch ein „Prefetch“-Flag setzen, das dem Server 408 anzeigt, dass dies eine sequentielle Wiederherstellung ist und der Server mehr Guthaben als angefordert gewähren könnte. Wenn der wiederherzustellende Datensatz 4 GB beträgt, kann der Server 408 dem Client 402 16 Wiederherstellungsguthaben gewähren, obwohl 4 Wiederherstellungsguthaben angefordert wurden.
  • Die Anzahl der Wiederherstellungsguthaben, die dem Client 402 gewährt werden, kann zum Anpassen der Größe der Vorauslese-Cache-Puffer 416 des Clients verwendet werden. Eine große Anzahl von Guthaben kann beispielsweise dazu führen, dass der Client 402 die Größe des Vorauslese-Puffers oder -Cache auf eine Größe erhöht, welche die Datenmenge im Zusammenhang mit den gewährten Guthaben aufnehmen kann. Alternativ könnten die Puffer 416 auf eine Weise bemessen sein, die einer Geschwindigkeit Rechnung trägt, mit der die zwischengespeicherten Daten zu den wiederhergestellten Daten 406 wiederhergestellt werden. In einem Beispiel kann sich die Größe der Puffer 416 dynamisch an die Anzahl der Guthaben im Besitz des Clients 402 anpassen.
  • Wenn der Wiederherstellungsvorgang in einer Cloud-Umgebung stattfinden sollte, kann der Server 408 das Prefetch-Flag ignorieren und die Entscheidung treffen, die Anzahl der Wiederherstellungsguthaben in der vom Client angeforderten Menge zu gewähren. Dies kann geschehen, weil das Vorauslesen und Wiederherstellen oder Auslesen von mehr Daten als erforderlich in einer Cloud-Umgebung koststpielig sein kann.
  • Die Anzahl der vom Server 408 gewährten Wiederherstellungsguthaben kann auf eine Weise gewährt werden, die der Art und Weise ähnelt, in der Stream-Guthaben gewährt werden. Die gewährte Menge an Wiederherstellungsguthaben kann gleich der Anzahl der angeforderten Wiederherstellungsguthaben, geringer als die Anzahl der angeforderten Wiederherstellungsguthaben, größer als die Anzahl der vom Client angeforderten Gutschriften, null oder negativ sein.
  • Abhängig von der Anzahl der Wiederherstellungsguthaben, die der Client 402 empfangen hat, würde der Client 402 die Wiederherstellungsguthaben zum Ausführen von Wiederherstellungsvorgängen verwenden. Die Wiederherstellungsguthaben werden zum Auslesen von Daten verwendet, und beim Auslesen der Daten werden die Wiederherstellungsguthaben entsprechend verwendet oder zurückgegeben. Die Verwendung jedes Blocks von Lesevorgängen würde zur Verwendung jedes Wiederherstellungsguthabens führen.
  • Wenn die Anzahl der gewährten Wiederherstellungsguthaben bei null liegt oder ein negativer Wert ist, ist dies ein Hinweis für den Client, dass er drosseln soll. Folglich kann die Wiederherstellungsanfrage nicht durchgeführt werden (oder nur teilweise durchgeführt werden), und Wiederherstellungsguthaben werden vom Client an den Server zurückgegeben. Dadurch wird dem Server das Erreichen eines sicheren Zuweisungsstatus ermöglicht.
  • Wenn der Wiederherstellungsvorgang abgeschlossen wurde und der Client 402 zusätzliche Wiederherstellungsguthaben in seiner Verbindungsstruktur zwischengespeichert hat, kann der Client 402 wählen, diese Wiederherstellungsguthaben eigenmächtig freizugeben. Der Server 408 kann seine interne Guthaben-Buchhaltungsdatenbank, die Zuweisungstabelle 414, aktualisieren, um der Freigabe der Wiederherstellungsguthaben von einem bestimmten Client Rechnung zu tragen.
  • Bei der Gewährung von Guthaben (unabhängig vom Typ) kann der Server 408 ein Guthabenzuweisungsverfahren durchführen. Ausführungsformen der Erfindung sehen vor, dass viele Metriken zum Bestimmen der Guthabenzuweisung oder des Guthabenzuweisungsstatus eingesetzt werden können. Beispiele umfassen Maschinenkapazitäten (Verbindungen, Prozessoren, Kerne, Speichergröße, Speichertypen, Clientverbindungen, bestehende Streams, verfügbare Ressourcen und dergleichen oder eine Kombination davon).
  • 5 zeigt ein Beispiel für ein Verfahren zum Zuweisen von Wiederherstellungsguthaben. Das Verfahren 500 kann Schritte oder Handlungen umfassen, die nicht jedes Mal ausgeführt werden, wenn das Verfahren durchgeführt wird. In 5 wird das Ausmaß oder die Anzahl von Lesevorgängen, die durchschnittlich 1% eines Prozessors oder Kerns (z.B. einer CPU oder zentralen Verarbeitungseinheit) verbrauchen, bestimmt oder definiert 502. Während diese Zahl typischerweise eine Schätzung ist, kann das Sammeln von statistischen Daten durch Ausführung einer empirischen Datenwiederherstellung zum Qualifizieren dieser Zahl verwendet werden. Der Prozentsatz der CPU-Auslastung während verschiedener Wiederherstellungsdurchläufe oder -operationen unterschiedlicher Größe und/oder unterschiedlichen Datentyps kann erhalten oder gemessen werden. Der Durchschnitt dieser Beobachtungen kann beispielsweise zum Berechnen einer Anzahl von Lesevorgängen, die 1% Daten verbrauchen, herangezogen werden. Wenn zum Beispiel festgestellt wird, dass das Wiederherstellen von 1 GB Daten 10% der CPU verbraucht und durchschnittlich 10.000 Leseanfragen ergibt, kann geschätzt werden, dass 1000 Leseanfragen an den Server 1% der CPU verbrauchen. Dieses Ergebnis kann verwendet werden, um die Anzahl der Wiederherstellungsguthaben zu bestimmen, die anfragenden Clients zugewiesen werden sollen.
  • Als nächstes wird die durchschnittliche Anzahl der pro Kern zulässigen Lesevorgänge bestimmt 504. In einem Beispiel wird dies ermittelt, indem die Anzahl der Lesevorgä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 Lesevorgä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 Wiederherstellungsguthaben 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 Wiederherstellungsguthaben ausmachen.
  • Als nächstes können Guthaben an anfragende Clients 510 ausgegeben werden. Die Anzahl der ausgegebenen Guthaben kann beispielsweise nur unter Verwendung des Minimums der angeforderten Wiederherstellungsguthaben und der berechneten Guthaben pro Client ermittelt werden. Wenn der Client eine Vorabrufung angefordert hat, kann die Anzahl der ausgegebenen Wiederherstellungsguthaben ein Maximum der angeforderten Wiederherstellungsguthaben und der berechneten Guthaben pro Client sein.
  • Das folgende Beispiel ist zu betrachten. Wenn die Anzahl der Lesevorgänge, 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 Wiederherstellungsguthaben anfordert, sind die gewährten Wiederherstellungsguthaben 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 Wiederherstellungsguthaben 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.
  • In einem anderen Beispiel können die Wiederherstellungsguthaben auf ähnliche Weise wie die Stream-Guthaben verwaltet werden, so dass jede Anfrage nach Wiederherstellungsguthaben im Rahmen aller verfügbarer Wiederherstellungsguthaben betrachtet wird und nicht die maximal zulässigen Clients jedes Clients oder berechnete Wiederherstellungsguthaben basierend auf dem Abstimmungsfaktor.
  • In einem Beispiel stellen Wiederherstellungsguthaben ein Beispiel für Stream-Guthaben zumindest deshalb dar, weil die Daten, die wiedergestellt werden, auch vom Server zu den Clients gestreamt werden. Diese Typen von Guthaben können jedoch auch gemeinsam verwendet werden. Beispielsweise können die Stream-Guthaben zum Verwalten der Anzahl von Streams verwendet werden, und die Wiederherstellungsguthaben können bestimmen, wie viele Daten ein bestimmter Client für alle Streams des Clients auslesen kann.
  • 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
/*

 * 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 _streams[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 C1 C2 30 10 10 30 20 30 20 30 50 20 40 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ürung 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
    C1 0 0 0
    C2 0 10 40
    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
    N N2 N3 N4
    3 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 und zum Wiederherstellen von Daten aus dem Server, wobei das Verfahren Folgendes umfasst: das Empfangen einer Anfrage nach Wiederherstellungsguthaben von einem Client, wobei die Wiederherstellungsguthaben jeweils einer Datenmenge entsprechen, die aus dem Server ausgelesen werden soll; das Bestimmen einer Anzahl von Guthaben, die dem Client zur Verfügung stehen, wobei die Anzahl der Guthaben, die dem Client zur Verfügung stehen, für Wiederherstellungsguthaben verantwortlich ist, die bereits an den Client ausgegeben wurden; das Ausgeben von Guthaben basierend auf der Anfrage und der Anzahl der Guthaben, die dem Client zur Verfügung stehen.
    2. Verfahren nach Anspruch 1, ferner umfassend zumindest eines von Folgendem: das Ausgeben von Wiederherstellungsguthaben entsprechend einer Anzahl von Wiederherstellungsguthaben, die vom Client angefordert wurden; das Ausgeben von mehr Wiederherstellungsguthaben als die Anzahl der vom Client angeforderten Wiederherstellungsguthaben; das Ausgeben von weniger Wiederherstellungsguthaben als die Anzahl der vom Client angeforderten Wiederherstellungsguthaben; das Ausgeben von Null-Wiederherstellungsguthaben an den Client; oder das Ausgeben von negativen Wiederherstellungsguthaben an den Client.
    3. Verfahren nach Anspruch 1, ferner umfassend das Bestimmen einer Größe eines Client-Cache basierend auf der Anzahl von Wiederherstellungsguthaben, die an den Client ausgegeben wurden.
    4. Verfahren nach Anspruch 1, ferner umfassend das Einbeziehen eines Prefetch-Flags in die Anfrage, wobei das Prefetch-Flag anzeigt, dass der Client sequentiell auf die Daten auf dem Server zugreift.
    5. Verfahren nach Anspruch 1, ferner umfassend das Bestimmen einer Anzahl von Lesevorgängen, die durchschnittlich 1% einer CPU verbrauchen.
    6. Verfahren nach Anspruch 5, ferner umfassend das Bestimmen eines Durchschnitts der pro Kern zulässigen Lesevorgänge basierend auf der Anzahl der Lesevorgänge, die 1% der CPU und den durchschnittlichen freien Prozentsatz der CUP verbrauchen, und das Bestimmen eines maximalen Guthabens pro Client basierend auf der Anzahl von Clientverbindungen.
    7. Verfahren nach Anspruch 6, ferner umfassend das Bestimmen einer berechneten Anzahl von Guthaben pro Client basierend auf einem Abstimmungsfaktor, der auf die maximalen Guthaben pro Client angewendet wird.
    8. Verfahren nach Anspruch 7, ferner umfassend das Ausgeben der Wiederherstellungsguthaben in einer Anzahl, die einem Minimum der Anfrage oder der berechneten Anzahl von Guthaben entspricht.
    9. Verfahren nach Anspruch 7, ferner umfassend das Ausgeben der Wiederherstellungsguthaben in einer Anzahl, die einem Maximum der Anfrage oder der berechneten Anzahl von Guthaben entspricht.
    10. Verfahren nach Anspruch 1, ferner umfassend das Drosseln aller Clients, wenn ein durchschnittlicher freier Prozentsatz pro Kern eines Prozessors geringer als ein vorbestimmter Schwellenwert ist.
    11. Nicht-transitorisches computerlesbares Medium, einschließlich computerausführbarer Anweisungen zum Umsetzen eines Verfahrens zum, wenn es ausgeführt wird, Zuweisen von Ressourcen eines Servers zu mit dem Server verbundenen Clients und zum Wiederherstellen von Daten aus dem Server, wobei das Verfahren Folgendes umfasst: das Empfangen einer Anfrage nach Wiederherstellungsguthaben von einem Client, wobei die Wiederherstellungsguthaben jeweils einer Datenmenge entsprechen, die aus dem Server ausgelesen werden soll; das Bestimmen einer Anzahl von Guthaben, die dem Client zur Verfügung stehen, wobei die Anzahl der Guthaben, die dem Client zur Verfügung stehen, für Wiederherstellungsguthaben verantwortlich ist, die bereits an den Client ausgegeben wurden; das Ausgeben von Guthaben basierend auf der Anfrage und der Anzahl der Guthaben, die dem Client zur Verfügung stehen.
    12. Nicht-transitorisches computerlesbares Medium nach Anspruch 11, ferner umfassend zumindest eines von Folgendem: das Ausgeben von Wiederherstellungsguthaben entsprechend einer Anzahl von Wiederherstellungsguthaben, die vom Client angefordert wurden; das Ausgeben von mehr Wiederherstellungsguthaben als die Anzahl der vom Client angeforderten Wiederherstellungsguthaben; das Ausgeben von weniger Wiederherstellungsguthaben als die Anzahl der vom Client angeforderten Wiederherstellungsguthaben; das Ausgeben von Null-Wiederherstellungsguthaben an den Client; oder das Ausgeben von negativen Wiederherstellungsguthaben an den Client.
    13. Nicht-transitorisches computerlesbares Medium nach Anspruch 11, ferner umfassend das Bestimmen einer Größe eines Client-Cache basierend auf der Anzahl von Wiederherstellungsguthaben, die an den Client ausgegeben wurden.
    14. Nicht-transitorisches computerlesbares Medium nach Anspruch 11, ferner umfassend das Einbeziehen eines Prefetch-Flags in die Anfrage, wobei das Prefetch-Flag anzeigt, dass der Client sequentiell auf die Daten auf dem Server zugreift.
    15. Nicht-transitorisches computerlesbares Medium nach Anspruch 11, ferner umfassend das Bestimmen einer Anzahl von Lesevorgängen, die durchschnittlich 1% einer CPU verbrauchen.
    16. Nicht-transitorisches computerlesbares Medium nach Anspruch 15, ferner umfassend das Bestimmen eines Durchschnitts der pro Kern zulässigen Lesevorgänge basierend auf der Anzahl der Lesevorgänge, die 1% der CPU und den durchschnittlichen freien Prozentsatz der CUP verbrauchen, und das Bestimmen eines maximalen Guthabens pro Client basierend auf der Anzahl von Clientverbindungen.
    17. Nicht-transitorisches computerlesbares Medium nach Anspruch 16, ferner umfassend das Bestimmen einer berechneten Anzahl von Guthaben pro Client basierend auf einem Abstimmungsfaktor, der auf die maximalen Guthaben pro Client angewendet wird.
    18. Nicht-transitorisches computerlesbares Medium nach Anspruch 16, ferner umfassend das Ausgeben der Wiederherstellungsguthaben in einer Anzahl, die einem Minimum der Anfrage oder der berechneten Anzahl von Guthaben entspricht.
    19. Nicht-transitorisches computerlesbares Medium nach Anspruch 16, ferner umfassend das Ausgeben der Wiederherstellungsguthaben in einer Anzahl, die einem Maximum der Anfrage oder der berechneten Anzahl von Guthaben entspricht.
    20. Verfahren zum Durchführen einer Ressourcenzuweisung, wenn ein Client Wiederherstellungsguthaben von einem Server anfordert, wobei das Verfahren Folgendes umfasst: das Bestimmen einer Anzahl von Lesevorgängen, die durchschnittlich 1% eines Prozessors verbrauchen; das Bestimmen einer durchschnittlichen Anzahl der pro Kern zulässigen Lesevorgänge durch Multiplizieren der Anzahl der Lesevorgänge, die 1% des Prozessors verbrauchen, mit einem durchschnittlichen freien Prozentsatz jedes Kerns jedes Prozessors; das Bestimmen einer maximalen Anzahl von Guthaben pro Client durch Multiplizieren der durchschnittlichen Anzahl der pro Kern zulässigen Lesevorgänge mit der Anzahl von Kernen und Teilen durch eine Anzahl von Clientverbindungen; das Abstimmen der maximalen Anzahl von Guthaben pro Client, um eine berechnete Anzahl von Guthaben pro Client zu erhalten; und das Gewähren der Anfrage in einer Menge, die einem Minimum zwischen den angeforderten Wiederherstellungsguthaben und der berechneten Anzahl von Guthaben entspricht.
    DE112019005042.7T 2018-10-08 2019-07-29 Ressourcenzuweisung unter verwendung von wiederherstellungsguthaben Pending DE112019005042T5 (de)

    Applications Claiming Priority (3)

    Application Number Priority Date Filing Date Title
    US16/154,518 US10630602B1 (en) 2018-10-08 2018-10-08 Resource allocation using restore credits
    US16/154,518 2018-10-08
    PCT/US2019/043976 WO2020076394A1 (en) 2018-10-08 2019-07-29 Resource allocation using restore credits

    Publications (1)

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

    Family

    ID=67551451

    Family Applications (1)

    Application Number Title Priority Date Filing Date
    DE112019005042.7T Pending DE112019005042T5 (de) 2018-10-08 2019-07-29 Ressourcenzuweisung unter verwendung von wiederherstellungsguthaben

    Country Status (5)

    Country Link
    US (2) US10630602B1 (de)
    CN (1) CN112805684A (de)
    DE (1) DE112019005042T5 (de)
    GB (1) GB2591928B (de)
    WO (1) WO2020076394A1 (de)

    Families Citing this family (2)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    US10990447B1 (en) * 2018-07-12 2021-04-27 Lightbits Labs Ltd. System and method for controlling a flow of storage access requests
    CN112260955B (zh) * 2020-09-18 2022-11-11 苏州浪潮智能科技有限公司 一种混合读写流量控制方法和装置

    Family Cites Families (59)

    * Cited by examiner, † Cited by third party
    Publication number Priority date Publication date Assignee Title
    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
    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
    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
    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
    US7698478B2 (en) * 2006-09-19 2010-04-13 Apple Inc. Managed credit update
    US8127099B2 (en) * 2006-12-26 2012-02-28 International Business Machines Corporation Resource recovery using borrowed blocks of memory
    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
    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
    US20160005007A1 (en) 2014-07-04 2016-01-07 Flashback Survey, Inc. Methods and systems for using scanable codes to obtain maintenance and reminder services
    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
    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
    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
    US11005776B2 (en) 2021-05-11
    WO2020076394A1 (en) 2020-04-16
    US20200112520A1 (en) 2020-04-09
    GB202104643D0 (en) 2021-05-12
    GB2591928A (en) 2021-08-11
    US20200228461A1 (en) 2020-07-16
    GB2591928B (en) 2023-05-17
    US10630602B1 (en) 2020-04-21
    CN112805684A (zh) 2021-05-14

    Similar Documents

    Publication Publication Date Title
    DE112011100819B4 (de) Speicherplatzreservierung in einem Deduplizierungssystem
    DE60117818T2 (de) Verwaltung des ersetzens von daten in einem zwischenspeicher auf einem knoten aufgrund von zwischenspeichern anderer knoten
    DE69628682T2 (de) System und Verfahren um die Belastung einer Mehrzahl von Datei-Servern zu verteilen
    DE112012004336B4 (de) System, Verfahren und Programmprodukt für kostenbewusste Auswahl von Vorlagen zum Bereitstellen von gemeinsam genutzten Ressourcen
    DE69937946T2 (de) Hashen von objekten mit inkrementalen änderungen
    DE112018000193T5 (de) Daten sequenziell in Zonen in einem verstreuten Speichernetzwerk speichern
    DE60016283T2 (de) Arbeitsbelastungsverwaltung in einer rechnerumgebung
    DE202012013432U1 (de) Speichern von Daten auf Speicherknoten
    DE112012004999T5 (de) Beschleunigungselement zur Cloud-Bereitstellung
    DE10296791T5 (de) Auswahl einer Ressource in einem verteilten Rechnersystem
    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
    DE112011101633T5 (de) Virtualisierung und dynamische Ressourcenzuweisung berücksichtigendes Neuordnen von Speicherebenen
    DE112013004098B4 (de) Verwalten eines Daten-Cache für ein Computersystem
    DE112010003675T5 (de) Adress-Server
    DE112020004661T5 (de) Ermitteln einer optimalen Anzahl von Threads pro Kern in einem Mehrkern-Prozessorkomplex
    DE112021000390T5 (de) Anpassen der leistung eines datenverarbeitungssystems
    DE112013003300T5 (de) Schrittweise Vorbereitung von Videos auf die Lieferung
    DE102018209188A1 (de) Technologien zum Verwalten der Dienstgüte für Plattformverbindungen
    DE112019005042T5 (de) Ressourcenzuweisung unter verwendung von wiederherstellungsguthaben
    US11765099B2 (en) Resource allocation using distributed segment processing credits
    DE102009056282A1 (de) Technik zum Steuern von Verarbeitungsressourcen
    DE202013012479U1 (de) System zur Commit Ausführung von Transaktionen auf entfernten Servern
    DE102005048729B4 (de) Verfahren und Systeme zum Defragmentieren eines Teilnetzraums innerhalb einer adaptiven Infrastruktur
    DE112022000344T5 (de) Anwenden von änderungen in einem ziel-datenbanksystem