WO2013087610A1 - Vorrichtung und verfahren zum dynamischen lastmanagement von cloud services - Google Patents

Vorrichtung und verfahren zum dynamischen lastmanagement von cloud services Download PDF

Info

Publication number
WO2013087610A1
WO2013087610A1 PCT/EP2012/075050 EP2012075050W WO2013087610A1 WO 2013087610 A1 WO2013087610 A1 WO 2013087610A1 EP 2012075050 W EP2012075050 W EP 2012075050W WO 2013087610 A1 WO2013087610 A1 WO 2013087610A1
Authority
WO
WIPO (PCT)
Prior art keywords
service
client
slm
resources
manager
Prior art date
Application number
PCT/EP2012/075050
Other languages
English (en)
French (fr)
Inventor
Gerald Kaefer
Anna-Sophie SCHWANENGEL
Original Assignee
Siemens Aktiengesellschaft
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 Siemens Aktiengesellschaft filed Critical Siemens Aktiengesellschaft
Priority to US14/365,201 priority Critical patent/US20140337435A1/en
Publication of WO2013087610A1 publication Critical patent/WO2013087610A1/de

Links

Classifications

    • 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/72—Admission control; Resource allocation using reservation actions during connection setup
    • H04L47/726—Reserving resources in multiple paths to be used simultaneously
    • 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/5083—Techniques for rebalancing the load in a distributed system
    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/5014—Reservation

Definitions

  • the invention relates to a method and a device for the dynamic load management of cloud services, in which the number of required IT resources is defined on the basis of an agreed service level agreement (SLA).
  • SLA agreed service level agreement
  • Cloud services can be categorized into two broad categories, namely end-user services with user interface and system-to-person interaction, and machine-to-machine or service-to-service interfaces without human interaction, the latter in their IT resource needs are easier to plan.
  • an adaptive IT resource management in which based on a feedback from the transmission network, a system is automatically adapted to dynamic load changes,
  • the adaptation due to the SLAs, is possible only within certain limits.
  • the service provider determines the number of IT resources required and creates empirical forecasts on the basis of load patterns or the like, thereby determining the course of a service usage over a defined time interval.
  • Such an approach is also pursued in SNAP.
  • the protocol was described by Foster et al. It is designed to negotiate service level agreements and then coordinate resources in distributed systems based on virtual machines.
  • Galstyan et al. an algorithm for distributed dynamic resource allocation without a central control mechanism and without inclusion of global information by "learning components".
  • the invention relates generally to an apparatus and a method for dynamic load management of cloud services, in / at least a cloud service from a Ser ⁇ vice client is available and the service client having a Lastma ⁇ management adapter with a Service Load Manager Reservation feedback messages exchanges messages in the form of an executive plan with Cloud Service exchanges.
  • Figure 1 is a diagram for explaining the relationships between the service client, service load manager and cloud service of a device according to the invention
  • Figure 2 shows a possible implementation of a corresponding
  • FIG. 3 Executions models for exemplary Verdeutli ⁇ monitoring of the actions in the service Load Manager and the client,
  • Figure 4 is a representation of a temporal resource allocation without load management for a use case and Figure 5 is a representation of zeiternern resource allocation with load management for the same application.
  • FIG. 1 shows a service client C and a cloud service S, which are connected via a service usage 1, the service client C having a load management adapter LMA, which is connected to a service load manager via resource reservation confirmations 2 , and wherein the Service Load Manager SLM is in communication with the Cloud Service S through a Resource Provisioning Schedule (Schedule) 3.
  • LMA load management adapter
  • SLM Resource Provisioning Schedule
  • FIG. 2 shows a communication model which specifies how the system participants communicate in the event of a peak load or which messages are exchanged as well.
  • the individual services S that is, the calculation, storage, and message service, register with the service load manager SLM and negotiate the terms of use in the form of service level agreements (SLA).
  • SLA service level agreements
  • the Service Load Manager SLM waits for incoming requests 21 from clients.
  • the client-identified requirement Cl is communicated including a deadline to the service load manager SLM, wel ⁇ cher the requests of all clients aggregated Ml and the possible M2 checks the declared demand with the help of the already registered resources.
  • FIG. 3 shows an execution model which defines how the service load manager SLM and the client C act and react before, during and after the message exchange or what typically happens within the components.
  • the service client C identified Cl initially his Anforde ⁇ requirements. If his need needs to be met immediately, he immediately requests resources from the Service Load Manager SLM. If there is a positive response - that is, if sufficient resources are available - he can connect to the service 26,36 and finally release the service 12 after use 11, and accordingly the Service Load Mager SLM inform about the release 27. If the client divorces ent ⁇ to send a reservation in advance to the service Load Manager SLM, he needs
  • Service Load Manager SLM When a service registration 31 arrives at the Service Load Manager SLM, the latter checks whether a corresponding service ID is already maintained in the directory. If so, a connection is established to the service and the SLAs negotiated with it. If, on the other hand, there is a new registration 31 of the service, it is stored in the register and then the SLAs are subsequently negotiated 32. If necessary, Ml aggregates the client requests to the SLM and checks whether the total demand can be covered by M2. For this he includes the planned times and the relevant time intervals in his resource planning. If the current resources are insufficient, new resources will be requested 33. If the need is met with existing resources, the terms of use will be negotiated with the client until an agreement is reached and the resources can be reserved.
  • the SLM When the client requests resources, the SLM always first checks to see if there is an appropriate reservation by the client. In this case, the client will tied the appropriate service 26,36. Because the Pro ⁇ protocol is not supported either, or because no pattern to the prognosis was available - - If the client had not expressed any reservations he is rejected in case of overload, data available with the reserved resources for the protocol-supporting requesting service clients. If a service client SC, which supports the resource management protocol, suddenly requests resources that it has not reserved and at the moment there are no free resources available, then it is informed that it is being put backwards as part of its shift interval ,
  • the Cloud Services S register 31 with the Service Load Manager SLM and thus provide their services for requesting
  • Each cloud service S must integrate resource control from the Service Load Manager SLM and create a resource deployment schedule (Schedule) 3. For this purpose, times scheduled by the Service Load Manager SLM and possible time intervals for resource utilization are exchanged, and a Schedule 3 is created for execution in consultation. This can then be optimized according to the requests to achieve a high utilization of resources. This avoids unnecessary empty spaces or gaps in the execution plan and largely prevents waste of resources.
  • An information model describes what information the messages carry and sets a message format. This includes information regarding:
  • Client ID Unique identification of a client to prevent false DoS alarms.
  • Manager ID Unique identification of the manager replicas for scalability.
  • - Service ID To describe the actual service to be used by the client.
  • - SLA ID Categorization of the negotiated SLAs.
  • the service user can pre-determine resource requirements for the entire load over time. This need will be considered in the IT resource management, to be readied ⁇ riding on known peak loads or to possibly even unexpected load peaks. This allows the required physical resources to be used as efficiently as possible.
  • the Intrusion Detection can be informed in advance and therefore does not block the service ⁇ user unintentionally system to high usage requirements. This prevents false warnings regarding denial-of-service attacks.
  • the service has the option of influencing the service user in his actual use of the service by scheduling client request in the permitted time interval. This allows the aggregated IT resource requirements of all service users to be optimized for service provision. The optimization of the schedules then makes it possible to provide the service to all users with a more constant amount of IT resources, which minimizes costs.
  • the service can serve service users who support the load management protocol as well as those who do not support it.
  • the difference in treatment is that for short-term overload the protocol ⁇ supported users will be operated and rejected the others.
  • the device according to the invention can advantageously be used to optimize route planning.
  • the route planning should be done dynamically based on the current traffic situation.
  • the service client C is the logistics service client
  • the cloud service S is specified as a route plan service
  • Client Load Management Adapters LMA and Service Load Manger SLM can exchange resource reservation information and feedback information.
  • the service Load Manager SLM and the route plan service S can vote in terms of resource allocation ⁇ is there.
  • the logistics service client C can use the route plan service S itself. So these are, for example, autonomous spontaneous users and participants of a logistics company.
  • ⁇ tung which route is selected for the delivery of goods, since the efficient scheduling of quality is crucial.
  • a logistics planning process corresponds to the determination of routes between individual destinations. A route can be optimized depending on the goods.
  • FIG. 4 illustrates the temporal resource assignment without load management for this application, wherein higher resource provision level b is required within a time interval and the resource requests above a certain provisioning level a are rejected.
  • the use of the device according to the invention means, on the one hand, that a logistics service client C can plan a journey and certain resources can already be reserved in advance in order to be reliably served at the desired implementation time.
  • a "long-running", ie a comparatively long-lasting, logistic planning process can be temporarily put back temporarily to prevent rejection or resource restart, which leads to a uniform utilization of resources, as can be seen in FIG.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

Die Erfindung betrifft im Wesentlichen eine Vorrichtung und ein Verfahren zum dynamischen Lastmanagement von Cloud Services, bei der/dem mindestens ein Cloud Service von einem Service Client nutzbar ist und der Service Client einen Lastmanagement-Adapter aufweist der mit einem Service Load Manager Nachrichten mit Reservierungsrückmeldungen austauscht der seinerseits weitere Nachrichten in Form eines Ausführplans mit dem Cloud Service austauscht. Hierdurch wird möglichst eine minimale Anzahl an physikalischen IT-Ressourcen bei gleichzeitiger Einhaltung der zuvor vereinbarten Service Level Agreements erreicht und es werden Denial-of-Service Fehlalarme durch große Lastspitzen vermieden. Die Erfindung kann vorteilhafter Weise zur Optimierung einer Routenplanung verwendet werden.

Description

Beschreibung
Vorrichtung und Verfahren zum dynamischen Lastmanagement von Cloud Services
Die Erfindung betrifft ein Verfahren und eine Vorrichtung zum dynamischen Lastmanagement von Cloud Services, bei dem die Anzahl der benötigten IT-Ressourcen auf Basis eines vereinbarten Service Level Agreements (SLAs) definiert wird.
Die von IT-Providern zur Verfügung gestellte Cloud- Servicedichte steigt seit Jahren zunehmend. Bisher wird ver¬ sucht der Anforderung der Skalierbarkeit dieser Cloud- Services per Virtualisierung, Replikation und dynamischer Um- Verteilung von virtuellen Ressourcen bzw. physikalischer Ressourcenzuteilung gerecht zu werden.
Obwohl der Einsatz von Cloud Computing Technologie neue Maßstäbe in der virtuellen Ressourcenumverteilung beziehungswei- se in der dynamischen Einbindung von physikalischen Ressourcen setzt, bleibt das Problem, dass sowohl das Bereitstellen der Ressourcen, wie auch das Umverteilen von virtuellen Ressourcen auf gleicher Hardware eine bestimmte minimale Zeit beansprucht. Diese bestimmten Zeitkonstanten können nicht un- terschritten werden.
Durch die starke Verbreitung dieser Technologien ist auch eine Verbreitung im industriellen Umfeld absehbar. Gerade im industriellen Umfeld stellt deterministisches Ver¬ halten jedoch eine Grundanforderung dar und Ressourcenverfügbarkeit muss für einzelne Services garantiert werden können, auch wenn diese sich einen Pool von physikalischer Hardware teilen. Hier besteht nach wie vor ein hoher Bedarf, nach au- tomatisierter und effizienter Reaktion auf variablen Ressourcenbedarf . Cloud Services können in zwei große Kategorien eingeteilt werden, nämlich End-User Services mit User Interface und Interaktion zwischen System und Mensch und Machine-to-Machine oder Service-to-Service Interfaces ohne menschliche Interak- tion, wobei letztere in ihrem IT-Ressourcenbedarf leichter planbar sind.
Neben einem statischen IT-Resourcenmanagement , bei dem bspw. Ressourcen wie Speicher oder Rechenleistung nicht reserviert werden können, ist bspw. auch ein adaptives IT-Resourcenmanagement bekannt, bei dem basierend auf einem Feedback aus dem Übertragungsnetz ein System automatisch an dynamische Laständerungen adaptiert wird, wobei jedoch die Adaption, auf Grund der SLAs, nur in gewissen Grenzen möglich ist.
Darüber hinaus ist ein Dynamisches IT-Ressourcen Management auf Service-Seite bekannt, beim Serviceanbieter die Anzahl der nötigen IT-Ressourcen ermittelt und auf Basis Lastmustern o. ä. empirische Vorhersagen erstellt und hiermit der Verlauf einer Servicenutzung in einem definierten Zeitintervall ermittelt wird. Ein solcher Ansatz wird auch in SNAP verfolgt. Das Protokoll wurde von Foster et al . entwickelt und dient der Aushandlung von Service Level Agreements und anschließender Koordinierung von Ressourcen in verteilten Systemen auf Basis von virtuellen Maschinen.
In "Resource Allocation in the Grid with Learning Agents" erklären Galstyan et al . einen Algorithmus zur verteilten dynamischen Ressourceneinteilung ohne zentralen Kontrollmechanis- mus und ohne Einbezug von globalen Informationen durch "Lernende Komponenten".
Nachteilig ist beim Dynamischen IT-Ressourcen Management auf der Service-Seite jedoch bspw., dass für eine Langzeit- Prognose eine Auswertung von zuvor gesammelten Daten langwierig und aufwendig oder evtl. nicht möglich ist, weil die Nut¬ zungsdaten mitunter überhaupt nicht verfügbar sind, und für eine Kurzzeit-Prognose für größere Veränderungen im kleinen Zeitintervall versagt, da die Zeitkonstante des dynamischen IT-Ressourcen Managements typischer Weise im Minutenbereich liegt .
Die der Erfindung zu Grunde liegende Aufgabe besteht nun dar¬ in, eine Vorrichtung und ein Verfahren zum dynamischen Lastmanagement von Cloud Services anzugeben, bei der/dem mög¬ lichst eine minimale Anzahl an physikalischen IT-Ressourcen bei gleichzeitiger Einhaltung der zuvor vereinbarten Service Level Agreements erreicht wird sowie Denial-of-Service Fehl¬ alarme durch große Lastspitzen und die oben genannten
Nachteile möglichst vermieden werden.
Diese Aufgabe wird hinsichtlich des Verfahrens durch die Merkmale des Patentanspruchs 1 und hinsichtlich der Vorrich¬ tung durch die Merkmale des Patentanspruchs 7 erfindungsgemäß gelöst. Die weiteren Ansprüche betreffen bevorzugte Ausges¬ taltungen der Erfindung.
Die Erfindung betrifft im Wesentlichen eine Vorrichtung und ein Verfahren zum dynamischen Lastmanagement von Cloud Services, bei der/dem mindestens ein Cloud Service von einem Ser¬ vice Client nutzbar ist und der Service Client einen Lastma¬ nagement-Adapter aufweist der mit einem Service Load Manager Nachrichten mit Reservierungsrückmeldungen austauscht der seinerseits weitere Nachrichten in Form eines Ausführplans mit dem Cloud Service austauscht. Hierdurch wird möglichst eine minimale Anzahl an physikalischen IT-Ressourcen bei gleichzeitiger Einhaltung der zuvor vereinbarten Service Level Agreements erreicht und es werden Denial-of-Service Fehl¬ alarme durch große Lastspitzen vermieden. Die Erfindung kann vorteilhafter Weise zur Optimierung einer Routenplanung verwendet werden.
Nachfolgend wird die Erfindung anhand von in der Zeichnung dargestellten Ausführungsbeispielen näher erläutert.
Dabei zeigt Figur 1 eine Darstellung zur Erläuterung der Beziehungen zwischen Service Client, Service Load Manager und Cloud Service einer erfindungsgemäßen Vorrichtung, Figur 2 eine mögliche Implementierung eines entsprechenden
Kommunikationsmodells ,
Figur 3 Executions-Modelle zur beispielhaften Verdeutli¬ chung der Aktionen im Service Load Manager und im Client,
Figur 4 eine Darstellung einer zeitlichen Resourcenbelegung ohne Load Management für einen Anwendungsfall und Figur 5 eine Darstellung der zeitlichern Resourcenbelegung mit Load Management für den selben Anwendungsfall.
In Figur 1 ist ein Service Client C und ein Cloud Service S dargestellt, die über eine Service-Nutzung 1 verbunden sind, wobei der Service Client C einen Load Management Adapter LMA aufweist, der über Ressourcenreservierungs-Rückmeldungen 2 mit einem Service Load Manager verbunden ist, und wobei der Service Load Manager SLM über einen Ausführplan (Schedule) 3 für die Ressourcenbereitstellung mit dem Cloud Service S in Verbindung steht.
In Figur 2 ist Kommunikationsmodell gezeigt, das festlegt wie die Systemteilnehmer im Falle einer Lastspitze kommunizieren bzw. welche Nachrichten dabei wie ausgetauscht werden. Zu¬ nächst registrieren 31 sich die einzelnen Services S, also Kalkulations- , Speicher-, Nachrichtendienst, bei dem Service Load Manager SLM und verhandeln 32 die Nutzungsbedingungen in Form von Service Level Agreements (SLA) . Nun wartet der Ser- vice Load Manager SLM auf eingehende Anfragen 21 von Clients. Der vom Client identifizierte Bedarf Cl wird inklusive einer Deadline an den Service Load Manager SLM kommuniziert, wel¬ cher die Anfragen aller Clients aggregiert Ml und die Mög- lichkeit prüft M2 den angemeldeten Bedarf mit Hilfe der bereits registrierten Ressourcen zu decken. Im Falle einer Überlast, also wenn mit Hilfe der bereits registrierten Res¬ sourcen der angemeldete Bedarf nicht zu decken ist, fragt 33 der Service Load Manager SLM neue Ressourcen, bspw. virtuelle Maschinen, an und meldet 22 dies an den Client C inklusive eines Verzögerungsvorschlags, wann die neuen Ressourcen zur Verfügung stehen. Die Nutzungs-bedingungen müssen entsprechend der Anforderungen zwischen Client C und SLM sowie dem Service S ausgehandelt 23, 35 werden. Sofern genügend Res¬ sourcen zur Verfügung stehen, werden bei positiver Übereinkunft die Ressourcen reserviert 24 und der Client C kann zum vorgemerkten Zeitpunkt die Ressourcen für die angemeldete Dauer nutzen 11. Dafür fordert 25 er beim Service Load Mana- ger SLM die entsprechende Ressource an, woraufhin der Service Load Manager SLM den Service S und den Client S verbindet 26,36. Nach erfolgreicher Servicenutzung 11, gibt der Client C den Service S wieder frei 12 und meldet 27 dies an den Ser¬ vice Load Manager SLM, der nun die freie Ressource in seiner Planung wieder mit einbeziehen kann.
In Figur 3 ist ein Exekutionsmodell gezeigt das festlegt wie der Service Load Manager SLM und der Client C vor, während und nach dem Nachrichtenaustausch agieren und reagieren bzw. was dabei innerhalb der Komponenten typischerweise passiert.
Im Folgenden werden nun die Funktionen der einzelnen Komponenten von Figur 1 anhand der Modelle der Figuren 2 und 3 näher beschrieben.
Service Client:
Der Service Client C identifiziert Cl zunächst seine Anforde¬ rungen. Wenn sein Bedarf sofort gedeckt werden muss, fragt 22 er die Ressourcen sofort bei dem Service Load Manager SLM an. Bei positiver Rückmeldung - also wenn genügend Ressourcen vorhanden sind - kann er sich mit dem Service verbinden 26,36 und im Anschluss der Nutzung 11 den Service schließlich wieder freigeben 12 und entsprechend den Service Load Mager SLM über die Freigabe informieren 27. Falls der Client sich ent¬ scheidet, eine Reservierung vorab an den Service Load Manager SLM zu schicken, benötigt er
entsprechend identifizierte Lastmuster und Historien. Sind solche vorhanden kann eine Reservierungsanfrage 22 abge¬ schickt werden. Falls noch keine Patternerkennung durchgeführt wurde, dies aber aufgrund gesammelter Daten möglich wäre, wird ein Pattern generiert und anschließend eine Reser¬ vierung losgeschickt. Nach Erhalt Bestätigungs-rückmeldung (Acknowledge) über die Reservierung kann der Client zum vereinbarten Zeitpunkt die Ressource beim Service Load Manager SLM einfordern 25 und anschließend den Service nutzen 11 und entsprechend freigeben 27. Das Verfahren zum dynamischen Ressourcen Management kann vom Service Client C optional genutzt werden. Damit bleibt die Kompatibilität zu bereits bestehenden Service Clients ge¬ wahrt . Service Load Manager:
Wenn beim Service Load Manager SLM eine Service-Registrierung 31 eingeht, überprüft dieser, ob eine entsprechende Service- ID bereits im Directory geführt wird. Ist dies der Fall, wird eine Verbindung zum Service aufgebaut und die SLAs mit diesem ausgehandelt. Liegt andererseits eine Neuregistrierung 31 des Services vor, wird er im Register abgelegt und wiederum anschließend die SLAs verhandelt 32. Bei Bedarf aggregiert Ml der SLM die Client-Anfragen und überprüft M2, ob der Gesamtbedarf gedeckt werden kann. Hierfür bezieht er die geplanten Zeiten und die maßgeblichen Zeitintervalle in seine Ressourcenplanung mit ein. Falls die aktuellen Ressourcen nicht ausreichen, werden neue Ressourcen angefordert 33. Ist der Bedarf mit den vorhandenen Ressourcen zu decken, werden mit dem Client die Nutzungsbedingungen ausgehandelt 35, bis eine Übereinkunft getroffen wurde und die Ressourcen reserviert werden können. Wenn der Client Ressourcen anfragt, überprüft der SLM zunächst immer, ob eine entsprechende Reservierung durch den Client vorliegt. In diesem Fall, wird der Client an den entsprechenden Service gebunden 26,36. Falls der Client keine Reservierung angemeldet hatte - entweder, weil das Pro¬ tokoll nicht unterstützt wird, oder weil kein Pattern zur Prognose verfügbar war - wird er bei Überlast abgewiesen, da- mit die reservierten Ressourcen für die protokollunterstützenden anfordernden Service Clients zur Verfügung stehen. Wenn ein Service Client SC, der das Ressourcen Management Protokoll unterstützt, plötzlich Ressourcen anfragt, welche er nicht reserviert hat und im Moment auch keine frei- en Ressourcen verfügbar sind, dann wird er darüber informiert, dass er im Rahmen seines Verschiebungsintervalls nach hinten eingereiht wird.
Cloud Service:
Die Cloud Services S registrieren 31 sich beim Service Load Manager SLM und stellen so ihre Services für anfragende
Clients C zur Verfügung. Ein jeweiliger Cloud Service S muss die Ressourcensteuerung vom Service Load Manager SLM integrieren und einen Ausführplan (Schedule) 3 für die Ressourcenbereitstellung erstellen. Dafür werden mit dem Service Load Manager SLM geplante Zeiten und mögliche Zeitintervalle zur Ressourcennutzung ausgetauscht und in Absprache ein Schedule 3 zur Ausführung erstellt. Dieser kann dann entsprechend der Anfragen optimiert werden, um eine hohe Auslastung der Ressourcen zu erreichen. So werden unnötige Leerzustande bzw. Lücken im Ausführplan vermieden und Ressourcenvergeudung weitgehend verhindert.
Protokoll-Beschreibung :
Ein Informationsmodell beschreibt, welche Informationen die Nachrichten transportieren und legt ein Nachrichtenformat fest. Dies umfasst Information bezüglich:
- Client-ID: Eindeutige Identifikation eines Clients zur Verhinderung falscher DoS-Alarme.
- Manager-ID: Eindeutige Identifikation der Managerreplikate für Skalierbarkeit.
- Service-ID: Zur Beschreibung des eigentlich zu nutzenden Service durch den Client. - SLA-ID: Kategorisierung der ausgehandelten SLAs .
- Ressourcenbedarf: Definition der benötigten Menge an Ressourcen durch den Client.
- Startzeit: Zur Angabe des Nutzungsbeginns.
- Dauer der Nutzung: Zur Angabe des Nutzungsdauer.
- Verzögerungsvorschlag: Wartezeitvorschlag der Managerkompo¬ nente bis Ressource verfügbar ist.
- Deadline : Maximal akzeptierte Verzögerung.
Vorteile der Erfindung:
- Mittels einer proaktiven Reservierung von IT-Ressourcenbedarf durch den Servicenutzer beim Service Load Manager kann dieser vorab den Ressourcenbedarf für die gesamte Last über die Zeit ermitteln. Dieser Bedarf wird dann im IT Ressourcenmanagement berücksichtigt, um auf bekannte Lastspitzen vorbe¬ reitet zu sein beziehungsweise, um eventuell unerwartete Lastspitzen zu glätten. So können die benötigten physikalischen Ressourcen möglichst effizient genutzt werden.
- Durch die Reservierung des Servicenutzer-Bedarfs und die damit eindeutige verbundene Identifikation des Nutzers, kann das Intrusion Detection System über hohen Nutzungsbedarf vorab informiert werden und blockiert somit nicht den Service¬ nutzer ungewollt. Somit lassen sich falsche Warnungen bzgl. Denial-of-Service Attacken verhindern.
- Der Service hat die Möglichkeit den Servicenutzer in seiner eigentlichen Nutzung des Services zu beeinflussen, indem er Client-Request in dem erlaubten Zeitintervall einplant. Damit lasst sich der aggregierte IT-Ressourcen-bedarf aller Servicenutzer zur Serviceerbringung optimieren. Die Optimierung des Schedules ermöglicht dann, mit konstanterer Menge an IT- Ressourcen den Service für alle Nutzer zu erbringen, was Kosten minimiert.
- Es kann bei kurzzeitiger Oberlast der Servicenutzer im Rahmen der SLAs zeitlich verzögert werden, um in der Zwischenzeit neue Ressourcen bereitstellen zu können. Der
Servicenutzer wird nicht abgewiesen mit einer Fehlermeldung, sondern über die kurzzeitige Verzögerung informiert und pro- duziert somit keine unnötige zusätzliche Last durch Wiederan¬ fragen, welche ohne dieses Feedback erzeugt würden.
- Der Service kann sowohl Servicenutzer bedienen, die das Load Management Protokoll unterstützen, als auch solche, die es nicht unterstützen. Der Unterschied in der Behandlung besteht darin, dass bei kurzfristiger Überlast die protokoll¬ unterstützten Nutzer bedient werden und die anderen abgewiesen werden. Beispiel einer vorteilhaften Verwendung der Erfindung:
Die erfindungsgemäße Vorrichtung kann vorteilhafter Weise zur Optimierung einer Routenplanung verwendet werden. Bei einem solchen Routenplanservice sollte die Routenplanung dynamisch aufgrund der aktuellen Verkehrssituation erfolgen.
Der Service Client C ist hierbei zum Logistik Service Client, der Cloud Service S wird hierbei zum Routenplanservice und die Service-Nutzung 1 zur Routenplanung und dynamischen Adap- tion konkretisiert.
Beispielsweise können Client Load Management Adapter LMA und Service Load Manger SLM Informationen zur Ressourcenreservierung und Feedback-Auskünfte austauschen. Der Service Load Manager SLM und der Routenplanservice S können sich da¬ bei bezüglich der Ressourceneinteilung abstimmen.
Woraufhin der Logistik Service Client C den Routenplanservice S selbst nutzen kann. Die sind also beispielsweise autonome spontane Nutzer und Teilnehmer einer Logistikfirma. Für einen Logistikplanungsservice ist es von enormer Bedeu¬ tung, welche Route für die Auslieferung von Waren ausgewählt wird, da die effiziente Zeitplanung für die Güte entscheidend ist. Ein Logistikplanungsprozess entspricht der Ermittlung von Strecken zwischen einzelnen Zielen. Eine Fahrtroute kann dafür abhängig von den Waren optimiert werden. In Figur 4 ist die zeitlichen Resourcenbelegung ohne Load Management für diesen Anwendungsfall dargestellt, wobei inner¬ halb eines Zeitintervalls höheres Resourcenbereit-stellungs- Niveau b erforderlich ist und die Ressourcen-Anfragen ober- halb eines bestimmten Provisionierungs-Niveaus a abgewiesen werden .
Wie in Figur 4 zu erkennen ist, würde bei hoher Anfragedichte (Requests) abgewiesen werden. Die Berechnung neuer Fahrrouten oder auch nötige dynamische Anpassungen berechneter Routen aufgrund von zum Beispiel neuen Verkehrsmeldungen sind ohne eine entsprechende Implementierung der Erfindung nicht möglich. In Figur 5 hingegen ist die zeitliche Resourcenbelegung mit erfindungsgemäßen Load Management ebenfalls für diesen Anwendungsfall dargestellt, wobei Anfragen innerhalb eines akzep¬ tierten Zeitintervalls zurückgestellt werden und damit eine Ressourcen-Hinzunahme und eine Abfrage-Abweisung zu verhin- dern.
Die Verwendung der erfindungsgemäßen Vorrichtung bedeutet einerseits, dass ein Logistik Service Client C eine Fahrt pla¬ nen kann und sich bestimmte Ressourcen bereits im Voraus re- servieren kann, um zum gewünschten Durchführungszeitpunkt sicher bedient zu werden. Andererseits kann ein „langlaufender", also ein vergleichsweise zeitlich lange andauernder, Logistikplanungsprozess zeitlich vorübergehend nach hinten gestellt werden, um eine Abweisung bzw. einen Ressourcenneu- Start zu verhindern. Dies führt zu einer gleichmäßigen Ressourcenauslastung, wie in Figur 5 zu sehen ist.

Claims

Patentansprüche
1. Vorrichtung zum dynamischen Lastmanagement von Cloud Services,
- bei der mindestens ein Service (S) von einem Service Client (C) nutzbar (1, US) ist,
- bei der der Service Client (C) einen Lastmanagement-Adapter (LMA) aufweist der mit einem Service Load Manager (SLM) Nachrichten (2) austauscht und
- bei der der Service Load Manager (SLM) seinerseits weitere Nachrichten (3) mit dem Cloud Service (S) austauscht.
2. Vorrichtung nach Anspruch 1,
bei der der Service Load Manager (SLM) derart vorhanden ist, - dass er, wenn bei ihm eine Service-Registrierung (31) eingeht, überprüft, ob eine entsprechende Service-ID bereits in einem Verzeichnis geführt wird,
- dass er eine Verbindung zum Service aufbaut und die SLAs mit ihm aushandelt, wenn eine entsprechende Service-ID be- reits im Verzeichnis geführt wird und sonst vorher noch eine Neuregistrierung (31) des Services (S) vornimmt,
- dass er, bei Bedarf, Client-Anfragen aggregiert (Ml) und überprüft (M2), ob der Gesamtressourcenbedarf gedeckt werden kann,
- dass er, falls die aktuellen Ressourcen nicht ausreichen, neue Ressourcen angefordert (33) werden und dass er sonst mit dem Client (C) die Nutzungsbedingungen aushandelt (35) bis eine Übereinkunft getroffen wird und die Ressourcen reser¬ viert werden,
- dass er, wenn der Client (C) Ressourcen anfragt, zunächst immer überprüft, ob eine entsprechende Reservierung durch den Client vorliegt, und in diesem Fall der Client an den ent¬ sprechenden Service gebunden (26,36) wird,
- dass er, falls der Client keine Reservierung angemeldet hatte, bei Überlast abgewiesen wird, und
- dass er, wenn ein Client (C) plötzlich Ressourcen anfragt, welche er nicht reserviert hat und im Moment auch keine frei¬ en Ressourcen verfügbar sind, darüber informiert wird, dass er im Rahmen seines Verschiebungsintervalls nach hinten ein¬ gereiht wird.
3. Vorrichtung nach Anspruch 1 oder 2,
bei der der Service Client (C) derart vorhanden ist,
- dass er zunächst seine Anforderungen identifiziert (Cl) und, wenn sein Bedarf sofort gedeckt werden muss, beim Service Load Manager SLM sofort die Ressourcen anfragt (22),
- dass er, wenn er Rückmeldung erhält dass genügend Ressour- cen vorhanden sind, sich mit dem Service verbindet (26,36) und im Anschluss der Nutzung (11) den Service schließlich wieder freigibt (12) und den Service Load Manager SLM über die Freigabe informiert (27),
- dass er, falls er sich entscheidet, eine Reservierung vorab an den Service Load Manager (SLM) zu schicken, prüft ob ent¬ sprechende identifizierte Lastmuster und Historien vorliegen oder nicht und, falls solche vorhanden sind, eine Reservie¬ rungsanfrage abschickt und, falls noch keine Patternerkennung durchgeführt wurde, dies aber aufgrund gesammelter Daten mög- lieh wäre, ein Pattern generiert und anschließend eine Reser¬ vierung losschickt, und
- dass er, nach Erhalt einer Bestätigungsrückmeldung (24) über die Reservierung, zum vereinbarten Zeitpunkt die Ressource beim Service Load Manager (SLM) einfordert (25) und anschließend den Service (S) nutzt (11) und dann entsprechend wieder freigibt (27) .
4. Vorrichtung nach einem der Ansprüche 1 bis 3,
bei dem mindestens ein Cloud Service (S) derart vorhanden ist,
- dass er sich beim Service Load Manager (SLM) registriert (31) und so für mindestens einen anfragenden Client (C) zur Verfügung stellt und
- dass er die Ressourcensteuerung vom Service Load Manager (SLM) integriert und einen Ausführplan (3) für die Ressourcenbereitstellung erstellt, wobei hierfür mit dem Service Lo¬ ad Manager (SLM) geplante Zeiten und mögliche Zeitintervalle zur Ressourcennutzung ausgetauscht und in Absprache der Aus¬ führplan (3) erstellt wird.
5. Vorrichtung nach Anspruch 4,
bei der der Ausführplan (3) entsprechend der Anfragen derart optimiert wird, dass Lücken im Ausführungsplan (3) vermieden werden .
6. Vorrichtung nach einem der vorhergehenden Ansprüche, bei der die Nachrichten (2) und/oder die weiteren Nachrichten (3) folgende Informationen umfassen:
- „Client-ID" zur eindeutigen Identifikation eines Clients, - „Manager-ID" zur eindeutige Identifikation der Manager- replikate,
- „Service-ID" zur Beschreibung des zu nutzenden Service durch den Client,
- „SLA-ID" zur Kategorisierung der ausgehandelten SLAs,
- „Ressourcenbedarf" zur Definition der benötigten Menge an Ressourcen durch den Client,
- „Startzeit" zur Angabe des Nutzungsbeginns,
- „Dauer der Nutzung" zur Angabe des Nutzungsdauer,
- „Verzögerungsvorschlag" entspricht einem Wartezeitvorschlag der Managerkomponente bis die gewünschte Ressource verfüg¬ bar ist und
- „Deadline" eine maximal akzeptierte Verzögerung.
7. Verfahren zum dynamischen Lastmanagement von Cloud Services,
- bei dem durch den mindestens einen Service Client (C) ein Bedarf reserviert (2) wird und
- bei dem mindestens ein Cloud Service (S) im Rahmen der zu¬ vor vereinbarten Möglichkeiten des Service Level Agreements das Nutzerverhalten (1) des Service Clients (C) beeinflusst (2, 3) .
8. Verfahren nach Anspruch 7,
- bei dem sich der mindestens eine Service (S) zunächst bei dem Service Load Manager (SLM) registriert (31) und die Nut- zungsbedingungen in Form von Service Level Agreements verhandelt (32),
- bei dem der Service Load Manager (SLM) auf eingehende An¬ fragen (21) mindestens eines Service Clients (C) wartet, - bei dem ein von diesem mindestens einen Service Client identifizierter Bedarf (Cl) inklusive einer Deadline an den Service Load Manager (SLM) kommuniziert wird, welcher die An¬ fragen aller Clients aggregiert (Ml) und prüft (M2), ob der angemeldeten Bedarf mit Hilfe der bereits registrierten Res- sourcen zu decken ist,
- bei dem, im Falle einer Überlast, der Service Load Manager (SLM) neue Ressourcen anfragt (33) und dies an den Service Client (C) meldet (22) inklusive eines Verzögerungs¬ vorschlags, wann die neuen Ressourcen zur Verfügung stehen, - bei dem die Nutzungsbedingungen entsprechend der Anforde¬ rungen zwischen dem mindestens einen Service Client (C) und Service Load Manager (SLM) sowie dem jeweiligen Service (S) ausgehandelt (23, 35) werden,
- bei dem, sofern genügend Ressourcen zur Verfügung stehen, bei positiver Übereinkunft die Ressourcen reserviert (24) werden und der mindestens eine Service Client (C) zum vorge¬ merkten Zeitpunkt die Ressourcen für die angemeldete Dauer nutzt (11), wobei dieser Service Client (C) dafür beim Servi¬ ce Load Manager (SLM) die entsprechende Ressource an fordert (25) , woraufhin der Service Load Manager (SLM) den Service (S) und diesen Service Client (C) verbindet (26,36), und
- bei dem der mindestens eine Service Client (C) , nach er¬ folgreicher Servicenutzung (11), den Service (S) wieder freigibt (12) und dies an den Service Load Manager (SLM) meldet (27), der nun die freie Ressource in seiner Planung wieder mit einbezieht.
PCT/EP2012/075050 2011-12-13 2012-12-11 Vorrichtung und verfahren zum dynamischen lastmanagement von cloud services WO2013087610A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US14/365,201 US20140337435A1 (en) 2011-12-13 2012-12-11 Device and Method for the Dynamic Load Management of Cloud Services

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102011088390.8 2011-12-13
DE102011088390 2011-12-13

Publications (1)

Publication Number Publication Date
WO2013087610A1 true WO2013087610A1 (de) 2013-06-20

Family

ID=47520905

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2012/075050 WO2013087610A1 (de) 2011-12-13 2012-12-11 Vorrichtung und verfahren zum dynamischen lastmanagement von cloud services

Country Status (2)

Country Link
US (1) US20140337435A1 (de)
WO (1) WO2013087610A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105959412A (zh) * 2016-06-29 2016-09-21 安徽理工大学 一种基于队列挖掘的云服务资源分配方法

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10055240B2 (en) 2014-09-23 2018-08-21 At&T Intellectual Property I, L.P. Service creation and management
US9571377B2 (en) 2014-12-11 2017-02-14 Oracle International Corporation Dynamic denial of service protection
US9923821B2 (en) 2015-12-23 2018-03-20 Intel Corporation Managing communication congestion for internet of things devices
US10097379B2 (en) 2015-12-23 2018-10-09 Intel Corporation Managing communication congestion for internet of things devices
US10057150B2 (en) * 2015-12-23 2018-08-21 Intel Corporation Managing communication congestion for internet of things devices
US10367914B2 (en) * 2016-01-12 2019-07-30 Cisco Technology, Inc. Attaching service level agreements to application containers and enabling service assurance
US10644961B2 (en) 2018-01-12 2020-05-05 Intel Corporation Self-adjusting data processing system
CN111461511A (zh) * 2020-03-19 2020-07-28 北京美住美宿科技有限公司 基于弹性计算的酒店管理系统、控制方法及设备
CN117687767A (zh) * 2022-09-02 2024-03-12 华为云计算技术有限公司 一种资源规划的方法、装置及相关设备
CN117076133B (zh) * 2023-10-13 2024-01-26 深圳云天畅想信息科技有限公司 云游戏平台异构资源分配方法、计算机装置及存储介质

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030154112A1 (en) * 2002-02-08 2003-08-14 Steven Neiman System and method for allocating computing resources
EP1693763A1 (de) * 2005-02-18 2006-08-23 International Business Machines Corporation System, Verfahren und Computerprogrammprodukt zur Bereitstellung von Rechnerdienstleistung für Dienstbenutzer mittels heterogener verteilter Rechnerumgebung
WO2011008219A1 (en) * 2009-07-15 2011-01-20 Cluster Resources, Inc. System and method of brokering cloud computing resources

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB2475897A (en) * 2009-12-04 2011-06-08 Creme Software Ltd Resource allocation using estimated time to complete jobs in a grid or cloud computing environment
US8396771B2 (en) * 2010-11-09 2013-03-12 Ca, Inc. Using cloud brokering services for an opportunistic cloud offering
US8495648B1 (en) * 2011-02-28 2013-07-23 Amazon Technologies, Inc. Managing allocation of computing capacity

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030154112A1 (en) * 2002-02-08 2003-08-14 Steven Neiman System and method for allocating computing resources
EP1693763A1 (de) * 2005-02-18 2006-08-23 International Business Machines Corporation System, Verfahren und Computerprogrammprodukt zur Bereitstellung von Rechnerdienstleistung für Dienstbenutzer mittels heterogener verteilter Rechnerumgebung
WO2011008219A1 (en) * 2009-07-15 2011-01-20 Cluster Resources, Inc. System and method of brokering cloud computing resources

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
ANNA SCHWANENGEL AND GERALD KAEFER: "Light-Weight Load Management Protocol based on Reservation and Feedback Loops", PROCEEDINGS OF THE 23RD IASTED INTERNATIONAL CONFERENCE ON PARALLEL AND DISTRIBUTED COMPUTING AND SYSTEMS : DECEMBER 14 - 16, 2011, DALLAS, USA,, 14 December 2011 (2011-12-14), pages 165 - 172, XP009168045, ISBN: 978-0-88986-917-2, DOI: 10.2316/P.2011.757-042 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN105959412A (zh) * 2016-06-29 2016-09-21 安徽理工大学 一种基于队列挖掘的云服务资源分配方法

Also Published As

Publication number Publication date
US20140337435A1 (en) 2014-11-13

Similar Documents

Publication Publication Date Title
WO2013087610A1 (de) Vorrichtung und verfahren zum dynamischen lastmanagement von cloud services
DE69931052T2 (de) Middleware-basiertes echtzeit-kommunikationssystem
DE102017201789B4 (de) Verfahren zum Betrieb eines Kraftfahrzeugs und Kraftfahrzeug
DE69433968T2 (de) Kommunikationsnetwerkverwaltung
DE602005004334T2 (de) Nms zur Verarbeitung von Multi-Server Ereignissen
DE112018003482T5 (de) Serveranfrageverwaltung
WO2007003535A1 (de) Verfahren und konferenzserver zum initialisieren von terminierten konferenzen
WO2020126827A1 (de) Verfahren zum management von rechnerkapazitäten in einem netzwerk mit mobilen teilnehmern
EP0959407A2 (de) Verfahren zum Zuteilen von Aufträgen Datenverarbeitungssystem, Client-Datenbearbeitungsknoten und computerlesbares Speichermedium
DE19838055A1 (de) Kommunikationssystem
EP1872595B1 (de) Änderungsverfahren der arbeitsweise einer technischen-kommunikationsgruppen-plattform (tkgp) eines telekommunikations-netzes (tk-netzes)
DE60209526T2 (de) Optimiertes mobilitätsmanagement auf basis von ortsbezogenem kontext
EP1123622A1 (de) Verfahren zur steuerung von netzelementen
EP1668860A1 (de) Verfahren zur bereitstellung von leistungsmerkmalen bei bedarf
DE112014002365T5 (de) Drahtlosübertragungskapazitätsregelung
WO2021089310A1 (de) Verfahren und vorrichtung zum verwalten von zugriffen mehrerer softwarekomponenten auf softwareschnittstellen
EP1942633A2 (de) Verfahren und System für ein Erreichbarkeitsmanagement
DE60109280T2 (de) Regelung der Verkehrslast in einem Telekommunikationsnetz, und ein entsprechender Netzknoten
EP1658705A1 (de) Bereitstellung einer einem benutzer eines kommunikationsdienstes zugeordneten anwesenheitsinformation
DE69532452T2 (de) Elemente für die Steuerung eines Telekommunikationsnetzes
DE60114544T2 (de) Mobilkommunikationssystem, und Standortregistrierungsverfahren einer Mobilstation, Ressourcensteuerungsverfahren und Informationsaufzeichnungsmedium in einem Mobilkommunikationssystem
DE102019127632A1 (de) Verfahren und vorrichtung zum einstellbaren routing mehrerer fahrzeuge
DE10340386B3 (de) Aktualisierung einer einem Benutzer eines Kommunikationsdienstes zugeordneten Anwesenheitsinformation
DE60100685T2 (de) Verwaltungsverfahren vor einem telekommunikationsnetzwerk und vorrichtung zur durchführung des Verfahrens
DE102006033830A1 (de) Verfahren und Anordnung zur Realisierung von Zugangsnetzwerken zu einem öffentlichen Netzwerk

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12812550

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 14365201

Country of ref document: US

122 Ep: pct application non-entry in european phase

Ref document number: 12812550

Country of ref document: EP

Kind code of ref document: A1