MÉTODO Y SISTEMA PARA GESTIONAR LA ASIGNACIÓN DE RECURSOS EN DESPLIEGUES ESCALABLES.

Método y sistema para gestionar la asignación de recursos en despliegues escalables.

El método de la invención tiene en cuenta el ahorro de coste acumulado de recursos (en el pasado) para extender el límite de recursos que pueden asignarse en dichos despliegues escalables según una dependencia actual de los recursos.

El sistema está dispuesto para implementar el método de la presente invención.

MÉTODO Y SISTEMA PARA GESTIONAR LA ASIGNACIÓN DE RECURSOS EN DESPLIEGUES ESCALABLES

Campo de la técnica La presente invención se refiere, en general, a un método para gestionar la asignación de recursos en despliegues escalables, implementando dichos despliegues escalables una elasticidad automática y teniendo un límite de recursos que pueden asignarse y, más particularmente, a un método que tiene en cuenta el ahorro de coste acumulado (en el pasado) para extender dicho límite según la dependencia actual de los recursos.

Un segundo aspecto de la invención se refiere a un sistema dispuesto para implementar el método del primer aspecto.

Estado de la técnica anterior Los enfoques de informática en nube [1] permiten ajustar los recursos asignados a clientes (normalmente, potencia de cálculo, almacenamiento y red) según la demanda de utilización actual de sus servicios. La elasticidad automática (vista como una de las “aplicaciones asesinas” de la informática en nube) consiste en sumar

o restar automáticamente los recursos anteriormente mencionados a los servicios desplegados en la nube sin ninguna intervención humana basándose en la demanda 20 [2].

Por ejemplo, una compañía dada desarrolla un nuevo servicio de compras en línea. Cuando lanza el servicio, la compañía puede tener una estimación de los recursos necesarios, pero el uso real puede variar con el tiempo (por ejemplo durante las primeras semanas puede que sólo unos pocos usuarios lo usen, y después empezar a aumentar de manera lineal) e incluso el uso puede cambiar dependiendo de las horas del día (por ejemplo la hora punta podría ser de 6 a 10 p.m. mientras que de 2 a 6 a.m. apenas se usa) o los días de la semana (por ejemplo podría usarse más en días entre semana que los fines de semana) . Puesto que a priori es difícil estimar con precisión la demanda real de recursos en un periodo de tiempo dado, el ajuste a escala automático es una de las características más importantes que un servicio en nube debe proporcionar. Los recursos consumidos en la informática en nube se facturan habitualmente usando modelos de pago por uso [1] o modelos combinados (tasa fija más pago por uso) . La componente de coste de pago por uso implica un riesgo económico para los clientes cuando se combina con elasticidad automática debido a que los recursos pueden escalar más allá del umbral de pago aceptable para el cliente. Esto puede deberse a un funcionamiento normal (por ejemplo el servicio es increíblemente exitoso) o a ataques maliciosos (denegación de servicio económico, EDoS [3]) . Por tanto, estos sistemas necesitan incluir una manera de especificar un límite superior (en términos de coste o cantidad de recursos) para poner un tope a acciones de escalado ascendente automáticas. Naturalmente, si la demanda del servicio necesita más recursos que el límite, la calidad de servicio del servicio/experiencia se verá afectada negativamente.

La propuesta [4] describe un sistema de gestión de nube que puede asignar

nodos inactivos a tareas en lotes de una manera en rejilla. Sin embargo, no se refiere al ahorro de coste basándose en elasticidad/asignación. Otra propuesta [5] describe un mecanismo para la fijación de precios para reservas de QoS en redes. Al igual que [4], no se refiere a la elasticidad/asignación basándose en ahorro de coste. El problema en los sistemas actuales que implementan elasticidad automática con tope de coste/recursos es que no tienen en cuenta el ahorro de coste acumulado. El tope de coste es constante a lo largo del tiempo (o en función del tiempo pero independiente del ahorro de coste acumulado) . Por tanto, no se tiene en cuenta el coste ahorrado cuando los recursos están por debajo del límite para permitir elevar la asignación de recursos en periodos en los que los recursos necesarios sobrepasan el

límite nominal. Se proporciona un ejemplo para aclarar este punto. Un cliente dado despliega un servicio en la nube y establece que no quiere gastar más de 28? (de media) por semana (considerando el coste de 1 unidad de recursos por día = 1?; siendo una unidad de recursos cualquier recurso escalable tal como máquinas virtuales) .

Distribuido uniformemente a lo largo de una semana, esto significa un límite de 4 unidades de recursos por día. Considerando que el lunes y martes de una semana dada, la demanda de servicio es de modo que se consumen 2 unidades de recursos el lunes y 3 el martes, eso implica un coste de 5?, entonces hay un ahorro de 3? (correspondiendo a los 8?

asociados al uso máximo de recursos, es decir 4 unidades de recursos cada día) . El miércoles, la demanda de servicio aumenta. El sistema de escalabilidad determina que deben asignarse 5 unidades de recursos, pero esto sobrepasa el límite, por lo que se asignan 4 unidades de recursos. Obsérvese que en esta situación, el cliente ha ahorrado 3? los días anteriores, que podrían usarse para pagar la unidad de recursos excedente, pero el sistema no lo sabe. Naturalmente, la diferencia entre lo que demanda el servicio y lo que puede proporcionar la nube implica una degradación de la calidad de servicio (empobrecimiento de la experiencia de usuario) .

Descripción de la invención En necesario ofrecer una alternativa al estado de la técnica que cubra las lagunas encontradas en la misma, particularmente en relación con la falta de propuestas que mejoren la flexibilidad de los sistemas escalables que se basan en un tope fijo para limitar el crecimiento de recursos asignados a servicios o usuarios.

Con ese fin, la presente invención proporciona, en un primer aspecto, un método para gestionar la asignación de recursos en despliegues escalables, implementando dichos despliegues escalables una elasticidad automática y teniendo un límite de recursos que pueden asignarse. A diferencia de las propuestas conocidas, el método de la invención, de una manera característica, comprende variar dicho límite durante un periodo de tiempo dado según al menos un ahorro de recursos producido en un periodo de tiempo anterior, en el que dicho ahorro de recursos se refiere a un consumo de recursos por debajo de un valor inicial de dicho límite.

Otras realizaciones del método del primer aspecto de la invención se describen según las reivindicaciones 2 a 15 adjuntas, y en una sección posterior correlativa a la 20 descripción detallada de varias realizaciones.

Un segundo aspecto de la invención se refiere a un sistema para gestionar la asignación de recursos en despliegues escalables, implementando dichos despliegues escalables una elasticidad automática y teniendo un límite de recursos que pueden asignarse.

El sistema del segundo aspecto de la invención, a diferencia de los sistemas conocidos mencionados en la sección de estado de la técnica anterior, y de una manera característica, comprende una unidad de asignación de recursos responsable de variar dicho límite durante un periodo de tiempo dado según al menos un ahorro de recursos producido en un periodo de tiempo anterior, en el que dicho ahorro de recursos se refiere a un consumo de recursos por debajo de un valor inicial de dicho límite. El sistema del segundo aspecto de la invención está adaptado para implementar el método del primer aspecto. Otras realizaciones del sistema del segundo aspecto de la invención se 35 describen según las reivindicaciones 16 a 24 adjuntas, y en una sección posterior

correlativa a la descripción detallada de varias realizaciones.

Breve descripción de los dibujos Las anteriores y otras ventajas y características se entenderán más completamente a partir de la siguiente descripción detallada de realizaciones, con referencia a los dibujos adjuntos (algunos de los cuales ya se han descrito en el la sección de estado de la técnica anterior) , que deben considerarse de una manera ilustrativa y no limitativa, en los que:

La figura 1 muestra un diagrama del ejemplo proporcionado en la sección de 10 estado de la técnica anterior, en el que el ahorro de coste anterior no se tiene en cuenta cuando se necesitan algunos recursos por encima del límite.

La figura 2 muestra la extensión del límite de recursos que pueden asignarse a un servicio o usuario dado como resultado de un ahorro de recursos anterior, según una realización de la presente invención.

La figura 3 muestra la arquitectura del sistema propuesto en la presente invención. La figure 4 muestra un algoritmo que debe seguirse para calcular el ahorro acumulado para un servicio o usuario dado, según una realización de la presente invención.

La figura 5 muestra el algoritmo que debe seguirse para ajustar los recursos asignados a un servicio o usuario dado, según una realización...

1. Método para gestionar la asignación de recursos en despliegues escalables, implementando dichos despliegues escalables una elasticidad automática y teniendo un límite de recursos que pueden asignarse, caracterizado porque comprende variar dicho límite durante un periodo de tiempo dado según al menos un ahorro de recursos producido en un periodo de tiempo anterior, en el que dicho ahorro de recursos se refiere a un consumo de recursos por debajo de un valor inicial de dicho límite.

2. Método según la reivindicación 1, en el que dicho consumo de recursos se 10 realiza por un usuario o un servicio.

3. Método según las reivindicaciones 1 ó 2, en el que dicho ahorro de recursos es la diferencia entre dicho valor inicial de dicho límite y dicho consumo de recursos.

4. Método según cualquiera de las reivindicaciones anteriores, que comprende

aumentar dicho límite cuando se produce dicho ahorro de recursos en dicho periodo de tiempo anterior, considerando también un factor de corrección de ahorro.

5. Método según cualquiera de las reivindicaciones anteriores, que comprende disminuir dicho límite cuando dicho consumo de recursos está por encima de 20 dicho valor inicial de dicho límite.

6. Método según cualquiera de las reivindicaciones anteriores, que comprende cuantificar dicho consumo de recursos y dicho ahorro de recursos por medio de unidades de recursos.

7. Método según la reivindicación 6, que comprende almacenar dicho ahorro de

recursos de cada periodo de tiempo en un fondo de ahorro cuyo valor indica la cantidad de ahorro acumulado de dichas unidades de recursos.

8. Método según la reivindicación 7, que comprende calcular dicho valor de dicho fondo de ahorro para el próximo periodo de tiempo, cuando dicho consumo de recursos está por debajo de o es igual a dicho valor inicial de dicho límite,

como:

Sn=S+ (L-C) ·fs en el que Sn es dicho valor de dicho fondo de ahorro S es el valor actual de dicho fondo de ahorro;

L es dicho valor inicial de dicho límite;

C es dicho consumo de recursos; y fs es un factor de corrección mayor que 0.

9. Método según la reivindicación 8, que comprende calcular dicho valor de dicho fondo de ahorro para el próximo periodo de tiempo, cuando dicho consumo de 5 recursos está por encima de dicho valor inicial de dicho límite y se cumple la condición S; (C-L) ·fe, como:

Sn=S- (C-L) ·fe donde fe es un factor corrector de gasto mayor que 0.

10. Método según la reivindicación 9, que comprende liberar al menos parte de dichas unidades de recursos consumidas por dicho servicio o usuario y hacer que Sn sea igual a 0 cuando dicho consumo de recursos está por encima de dicho valor inicial de dicho límite y se cumple la condición S< (C-L) •fe.

11. Método según la reivindicación 10, en el que el número de al menos dicha parte de dichas unidades de recursos consumidas por dicho servicio o usuario se determina por la siguiente expresión: R = (C – L) – S/fe 12. Método según la reivindicación 7, que comprende añadir un número determinado de unidades de recursos a las unidades de recursos asignadas actuales para un servicio o usuario dado cuando dicho servicio o usuario requiera una cantidad de dichas unidades de recursos mayor que dichas unidades de recursos asignadas actuales, estando dicha cantidad mayor por debajo de dicho límite, en el que dicho número se determina por: R = (D –C) donde D es dicha cantidad de dichas unidades de recursos requeridas por dicho servicio o usuario; y C son dichas unidades de recursos asignadas actuales.

13. Método según la reivindicación 12, que comprende disminuir dicho valor de dicho fondo de ahorro para el próximo periodo de tiempo cuando dicho servicio o usuario requiera una cantidad de dichas unidades de recursos mayor que dichas unidades de recursos asignadas actuales si se cumple la condición M;C, estando dicha cantidad mayor por encima de dicho límite, según la siguiente expresión:

Sn = S – (M – E) •fe 35 donde Sn es dicho valor de dicho fondo de ahorro S es el valor actual de dicho fondo de ahorro; E=máx (L, C) , máx calcula el valor máximo; M=mín (E+S/fe, D) , mín calcula el valor mínimo;

L es dicho valor inicial de dicho límite; fe es un factor corrector de gasto mayor que 0.

14. Método según la reivindicación 13, que comprende añadir un número determinado de unidades de recursos a las unidades de recursos asignadas actuales para un servicio o usuario dado, determinándose dicho número determinado por: R = (M– C)

15. Método según la reivindicación 7, que comprende retirar un número determinado de unidades de recursos a las unidades de recursos asignadas actuales para un usuario o servicio dado cuando dicho servicio o usuario requiera una cantidad de dichas unidades de recursos menor que dichas unidades de recursos asignadas actuales, determinándose dicho número determinado por:

R = (C –D) donde

C son dichas unidades de recursos asignadas actuales; y D es dicha cantidad de dichas unidades de recursos requeridas por dicho servicio o usuario.

16. Sistema para gestionar la asignación de recursos en despliegues escalables, implementando dichos despliegues escalables una elasticidad automática y 25 teniendo un límite de recursos que pueden asignarse, caracterizado porque comprende un sistema de control de asignación de recursos responsable de variar dicho límite durante un periodo de tiempo dado según al menos un ahorro de recursos producido en un periodo de tiempo anterior, en el que dicho ahorro de recursos se refiere a un consumo de recursos por debajo de un valor inicial

de dicho límite.

17. Sistema según la reivindicación 16, en el que dicho consumo de recursos y dicho ahorro de recursos se cuantifican por medio de unidades de recursos.

18. Sistema según la reivindicación 17, en el que un fondo de ahorro almacena

dicho ahorro de recursos de cada periodo de tiempo, y un valor de ahorro de 35 dicho fondo de ahorro indica la cantidad de ahorro acumulado de dichas unidades de recursos.

19. Sistema según la reivindicación 18, en el que un fondo de recursos gestionado por dicho sistema de control de asignación de recursos almacena el número de unidades de recursos asignadas para un servicio o usuario dado y un fondo de recursos libres almacena los recursos de dicho despliegue escalable que no están usándose.

20. Sistema según la reivindicación 19, en el que dicho sistema de control de asignación de recursos al menos comprende:

- un controlador que determina el número de dichas unidades de recursos que

deben almacenarse en dicho fondo de ahorro, dicho fondo de recursos y dicho fondo de recursos libres;

- un calculador de recursos que proporciona a dicho controlador el número óptimo de dichas unidades de recursos que deben asignarse a un usuario o servicio dado; y

- un reloj que se usa para coordinar diferentes funciones de dicho sistema de control de asignación de recursos.

21. Sistema según la reivindicación 20, en el que dicho controlador ejecuta al menos una de las siguientes instrucciones:

- consolidar el ahorro para un servicio o usuario dado.

20. ajustar recursos para un servicio o usuario dado; y

- retirar recursos de un servicio o usuario dado.

22. Sistema según la reivindicación 21, en el que dicha instrucción de consolidar el ahorro para un servicio o usuario dado se ejecuta de manera síncrona al final de un periodo de dicho reloj.

23. Sistema según la reivindicación 21, en el que dicha instrucción de ajustar recursos para un servicio o usuario dado se ejecuta de manera asíncrona.

24. Sistema según la reivindicación 21, en el que dicha instrucción de retirar recursos de un servicio o usuario dado se ejecuta o bien de manera síncrona al final de un periodo de dicho reloj y antes de dicha instrucción de consolidar el

ahorro para un servicio o usuario dado, o bien de manera asíncrona.

Figura 1

Figura 2

Figura 3

Figura 4

Figura 5

Figura 6

Figura 7