ES3057778T3 - Power saving through automated power scheduling of virtual machines with reliability index adjustments - Google Patents

Power saving through automated power scheduling of virtual machines with reliability index adjustments

Info

Publication number
ES3057778T3
ES3057778T3 ES23163866T ES23163866T ES3057778T3 ES 3057778 T3 ES3057778 T3 ES 3057778T3 ES 23163866 T ES23163866 T ES 23163866T ES 23163866 T ES23163866 T ES 23163866T ES 3057778 T3 ES3057778 T3 ES 3057778T3
Authority
ES
Spain
Prior art keywords
virtual machine
virtual machines
power
time
machines
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.)
Active
Application number
ES23163866T
Other languages
English (en)
Inventor
Stefano Visconti
Kanika Dhyani
Jeyashree Sivasubramanian
Marco Bertoli
Luca Poddigue
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.)
Bmc Helix Inc
Original Assignee
Bmc Helix Inc
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 Bmc Helix Inc filed Critical Bmc Helix Inc
Application granted granted Critical
Publication of ES3057778T3 publication Critical patent/ES3057778T3/es
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • G06F9/4893—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues taking into account power or heat criteria
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26—Power supply means, e.g. regulation thereof
    • G06F1/28—Supervision thereof, e.g. detecting power-supply failure by out of limits supervision
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26—Power supply means, e.g. regulation thereof
    • G06F1/32—Means for saving power
    • G06F1/3203—Power management, i.e. event-based initiation of a power-saving mode
    • G06F1/3206—Monitoring of events, devices or parameters that trigger a change in power modality
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26—Power supply means, e.g. regulation thereof
    • G06F1/32—Means for saving power
    • G06F1/3203—Power management, i.e. event-based initiation of a power-saving mode
    • G06F1/3234—Power saving characterised by the action undertaken
    • G06F1/3287—Power saving characterised by the action undertaken by switching off individual functional units in the computer system
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26—Power supply means, e.g. regulation thereof
    • G06F1/32—Means for saving power
    • G06F1/3203—Power management, i.e. event-based initiation of a power-saving mode
    • G06F1/3234—Power saving characterised by the action undertaken
    • G06F1/329—Power saving characterised by the action undertaken by task scheduling
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/5094—Allocation of resources, e.g. of the central processing unit [CPU] where the allocation takes into account power or heat criteria
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/4557—Distribution of virtual machine instances; Migration and load balancing
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45575—Starting, stopping, suspending or resuming virtual machine instances
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; 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/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45595—Network integration; Enabling network access in virtual machine instances
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Supply And Distribution Of Alternating Current (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Debugging And Monitoring (AREA)

Abstract

Un ordenador monitoriza las máquinas virtuales que se ejecutan en máquinas físicas y extrae datos de rendimiento. Clasifica las máquinas virtuales como activas o inactivas durante un periodo de observación. Con base en los datos de rendimiento y en criterios de inactividad, el ordenador genera una serie de actividad-inactividad para cada máquina virtual y determina al menos una periodicidad de tiempos de inactividad recurrentes. A continuación, para cada máquina virtual con al menos una periodicidad, el ordenador determina un programa de encendido y apagado y realiza la transición entre el estado encendido y el apagado según dicho programa. El ordenador también realiza un análisis de frecuencia de la serie de actividad-inactividad y compara un porcentaje de conteo activo con un umbral de frecuencia. Además, el ordenador calcula un índice de fiabilidad del programa durante un periodo de estimación de fiabilidad correspondiente al periodo de observación. Si el índice de fiabilidad desciende por debajo de un umbral, el ordenador repite el análisis de frecuencia aplicando un umbral de frecuencia ajustado. (Traducción automática con Google Translate, sin valor legal)

Description

[0001] DESCRIPCIÓN
[0002] Ahorro de energía a través de la programación automatizada de energía de máquinas virtuales con ajustes del índice de fiabilidad
[0003] Campo técnico
[0004] Esta descripción se refiere a la gestión de energía para máquinas virtuales.
[0005] Antecedentes
[0006] La informática en la nube proporciona muchas funciones y ventajas. En la informática en la nube, los proveedores de la nube proporcionan recursos de hardware y software a los consumidores de la nube. Por ejemplo, los proveedores de la nube pueden ser responsables de adquirir, configurar y desplegar grandes cantidades de recursos informáticos físicos, tales como servidores y equipos de red relacionados. Como tal, los proveedores de la nube típicamente son responsables de los recursos físicos (p. ej., el espacio físico, los administradores humanos y la energía eléctrica) utilizados por tales recursos informáticos, así como del mantenimiento y la seguridad de los mismos.
[0007] Mientras tanto, los consumidores de la nube están exentos de estas obligaciones directas y otras responsabilidades relacionadas y, al mismo tiempo, obtienen los recursos informáticos necesarios de manera rápida y flexible. Específicamente, por ejemplo, a los consumidores de la nube se les pueden proporcionar máquinas virtuales, en las que el software que se ejecuta en los recursos informáticos físicos del (de los) proveedor(es) de la nube divide esos recursos informáticos físicos entre los consumidores de la nube. En este paradigma, cada consumidor de la nube utiliza un(os) dispositivo(s) informático(s) local(es) para conectarse a través de una red a una o más máquinas virtuales proporcionadas por el proveedor de la nube. De este modo, se proporciona al consumidor de la nube la capacidad de acceder y utilizar los recursos informáticos de una manera altamente eficiente.
[0008] Es problemático monitorizar y gestionar grandes cantidades de máquinas virtuales en entornos informáticos en la nube, de una manera que sea eficiente y que evite el desperdicio de recursos. Por ejemplo, un consumidor de la nube puede utilizar una gran cantidad de máquinas virtuales, quizás utilizando múltiples proveedores de la nube, para diversos propósitos diferentes. Mientras tanto, un proveedor de la nube debe proporcionar una gran cantidad de máquinas virtuales solicitadas a los consumidores de la nube correspondientes y, al mismo tiempo, mantener los niveles de servicio especificados. Por lo tanto, es difícil para los consumidores de la nube evitar un exceso de capacidad de las máquinas virtuales y para los proveedores de la nube es difícil utilizar los recursos físicos de forma eficiente.
[0009] La patente US-9.846.476 B1 se refiere a un centro de datos con múltiples servidores y matrices de almacenamiento. Los programas agentes se ejecutan en las máquinas del servidor para monitorizar el estado de las máquinas del servidor y de las matrices de almacenamiento. Los agentes envían datos de estado a un servidor de monitorización centralizado para su procesamiento. El servidor de monitorización se encarga de apagar las máquinas del servidor (y/o las matrices de almacenamiento) que están inactivas.
[0010] Resumen
[0011] Según un aspecto general, un sistema puede incluir un medio de almacenamiento no transitorio legible por ordenador y al menos un procesador. Cuando las instrucciones almacenadas en el medio de almacenamiento no transitorio legible por ordenador son ejecutadas por el al menos un procesador, el sistema puede monitorizar, durante un tiempo de observación dividido en divisiones de tiempo, una pluralidad de máquinas virtuales que se ejecutan en máquinas físicas, y extraer datos de rendimiento que caracterizan el consumo de recursos físicos de las máquinas físicas por parte de la pluralidad de máquinas virtuales durante el tiempo de observación, extrayéndose los datos de rendimiento con respecto a cada una de las divisiones de tiempo. El sistema puede clasificar cada una de la pluralidad de máquinas virtuales como activa o inactiva durante cada división de tiempo del tiempo de observación, basándose en los datos de rendimiento y en los criterios de inactividad, para generar de este modo una serie activa-inactiva para cada una de la pluralidad de máquinas virtuales, y determinar, para cada serie activa-inactiva de cada máquina virtual de la pluralidad de máquinas virtuales, al menos una periodicidad de tiempos de inactividad recurrentes dentro del tiempo de observación. Por lo tanto, el sistema puede predecir, para cada máquina virtual con la al menos una periodicidad, un horario de encendido-apagado, y realizar la transición de cada una de las máquinas virtuales con la al menos una periodicidad entre un estado encendido y un estado apagado según el horario de encendido/apagado.
[0012] Según otro aspecto general, un método puede incluir monitorizar, durante un tiempo de observación dividido en divisiones de tiempo, una pluralidad de máquinas virtuales que se ejecutan en máquinas físicas, y extraer datos de rendimiento que caracterizan el consumo de recursos físicos de las máquinas físicas por parte de la pluralidad de máquinas virtuales durante el tiempo de observación, extrayéndose los datos de rendimiento con respecto a cada una de las divisiones de tiempo. El método puede incluir clasificar cada una de la pluralidad de máquinas virtuales como activa o inactiva durante cada división de tiempo del tiempo de observación, basándose en los datos de rendimiento y en los criterios de inactividad, para generar de este modo una serie activa-inactiva para cada una de la pluralidad de máquinas virtuales, y determinar, para cada serie activa-inactiva de cada máquina virtual de la pluralidad de máquinas virtuales, al menos una periodicidad de tiempos de inactividad recurrentes dentro del tiempo de observación. El método puede incluir además predecir, para cada máquina virtual con la al menos una periodicidad, un horario de encendidoapagado; y realizar la transición de cada una de las máquinas virtuales con la al menos una periodicidad entre un estado encendido y un estado apagado según el horario de encendido-apagado.
[0013] Según otro aspecto general, un producto de programa informático puede incluir instrucciones grabadas en un medio de almacenamiento no transitorio legible por ordenador y configuradas, cuando son ejecutadas por al menos un procesador, para hacer que el al menos un procesador acceda a un conjunto de criterios de inactividad para una pluralidad de máquinas virtuales que se ejecutan en una pluralidad de máquinas físicas, incluyendo los criterios de inactividad un conjunto predeterminado de umbrales de utilización, definidos por cada división de tiempo, de uno o más de al menos un procesador de las máquinas físicas, una velocidad de bytes de red de los bytes de datos intercambiados con una red por las máquinas físicas, y una velocidad de transferencia de datos de los bytes de datos por una memoria de las máquinas físicas. Las instrucciones, cuando son ejecutadas por al menos un procesador, pueden estar configuradas además para hacer que el al menos un procesador extraiga datos de rendimiento que caracterizan el consumo de recursos físicos de las máquinas físicas por parte de la pluralidad de máquinas virtuales durante un tiempo de observación, los datos de rendimiento extraídos con respecto a la división de tiempo durante el tiempo de observación, y clasifique cada máquina virtual como activa o inactiva durante cada división de tiempo del tiempo de observación, basándose en una comparación de los datos de rendimiento y los criterios de inactividad, para obtener de este modo una serie activa-inactiva para cada máquina virtual. Las instrucciones, cuando son ejecutadas por al menos un procesador, pueden estar configuradas además para hacer que el al menos un procesador examine la serie activa-inactiva para cada máquina virtual en un intervalo de datos que incluye unidades de tiempo de uno o más días, semanas o meses, y ejecute, para la serie activa-inactiva de cada máquina virtual, un análisis de frecuencia en el que un porcentaje del recuento de actividad para cada división de tiempo de la serie activa-inactiva de cada máquina virtual, con respecto a las unidades de tiempo del intervalo de datos, se compara con un umbral de frecuencia. Las instrucciones, cuando son ejecutadas por al menos un procesador, pueden estar configuradas además para hacer que el al menos un procesador genere, para cada máquina virtual, un modelo de encendido-apagado previsto, basándose en el análisis de frecuencia, y realice la transición, después del tiempo de observación, de cada máquina virtual entre un estado encendido y un estado apagado, basándose en el modelo de encendido-apagado previsto. Los detalles de una o más implementaciones se exponen en los dibujos adjuntos y en la descripción a continuación. Otras características resultarán evidentes a partir de la descripción y los dibujos y de las reivindicaciones.
[0014] Breve descripción de los dibujos
[0015] La figura 1 es un diagrama en bloque de un sistema para la gestión de energía para máquinas virtuales.
[0016] La figura 2 es un diagrama de flujo que ilustra operaciones ilustrativas del sistema de la figura 1.
[0017] La figura 3 es un diagrama en bloque que ilustra un primer flujo operativo ilustrativo del sistema de la figura 1.
[0018] La figura 4 es un diagrama en bloque que ilustra un segundo flujo operativo del sistema de la figura 1.
[0019] La figura 5 es un diagrama de flujo que ilustra operaciones ilustrativas más detalladas del sistema de la figura 1, para predecir intervalos periódicos para realizar la secuenciación de energía de máquinas virtuales.
[0020] La figura 6 es un diagrama de flujo que ilustra una implementación ilustrativa de las figuras 1-5, que incluye ejemplos específicos de los períodos previstos de la figura 5.
[0021] Descripción Detallada
[0022] La figura 1 es un diagrama en bloque de un sistema 100 para la gestión de energía para máquinas virtuales. En el ejemplo de la figura 1, se ilustra que un gestor energético 102 está configurado para operar en al menos un dispositivo informático 104, donde el al menos un dispositivo informático 104 incluye al menos un procesador 106, así como al menos un medio 108 de almacenamiento no transitorio legible por ordenador. Es decir, debe entenderse que el al menos un dispositivo informático 104 representa, p. ej., uno o más ordenadores que operan juntos. De forma similar, el al menos un procesador 106 puede representar dos cualesquiera o más procesadores, quizás que actúan en paralelo, y puede entenderse que el al menos un medio 108 no transitorio legible por ordenador representa o incluye cualquier dispositivo de almacenamiento para almacenar datos y/o para almacenar instrucciones que son ejecutables por el al menos un procesador 106.
[0023] En diversas implementaciones, el al menos un dispositivo informático 104 puede ser implementado, o accedido, por un consumidor de la nube, para de este modo permitir que el consumidor de la nube interactúe con un proveedor 110 de la nube para obtener acceso y utilizar las máquinas virtuales 112, 114 ilustradas. De forma similar, el gestor energético 102 en el al menos un dispositivo informático 104 puede permitir al consumidor de la nube utilizar los servicios de un proveedor 116 de la nube para proporcionar máquinas virtuales 118, 120. En otras palabras, tal consumidor de la nube generalmente puede utilizar los servicios de múltiples proveedores de la nube para obtener las cantidades y los tipos deseados de máquinas virtuales.
[0024] En las diversas implementaciones en las que un consumidor de la nube proporciona el al menos un dispositivo informático 104, entonces, como se ha mencionado anteriormente, el al menos un dispositivo informático 104 puede representar una gran cantidad de dispositivos informáticos. En tales situaciones, se puede proporcionar acceso a las máquinas virtuales 112, 114 y a las máquinas virtuales 118, 120 a muchas personas o entidades diferentes.
[0025] Por ejemplo, aunque se simplifica bastante para mayor claridad y concisión de la explicación, la figura 1 incluye y representa situaciones en las que, por ejemplo, un gran negocio u otra entidad, que quizás tenga grandes cantidades de empleados y/o departamentos, utiliza una gran cantidad correspondiente de máquinas virtuales. En consecuencia, y de forma similar, se apreciará que los proveedores 110, 116 de la nube también pueden representar a tres o más proveedores de la nube, y que las máquinas virtuales 112/114 y 118/120 pueden representar cientos, miles o más máquinas virtuales que el consumidor de la nube puede desplegar y utilizar mediante el al menos un dispositivo informático 104.
[0026] En estas implementaciones y en implementaciones similares, los proveedores 110/116 de la nube, además de proporcionar recursos informáticos físicos, tales como máquinas físicas, como se ha descrito anteriormente, típicamente proporcionan diversas funciones de gestión para, p. ej., crear instancias, desplegar, monitorizar, mantener y gestionar de cualquier otro modo todas las máquinas virtuales proporcionadas por el proveedor 110 de la nube, incluidas las máquinas virtuales 112, 114. Por lo tanto, en el ejemplo de la figura 1, se ilustra que el proveedor 110 de la nube incluye un gestor 115 de máquinas virtuales, que proporciona estas funciones y funciones relacionadas, que incluyen interactuar con una interfaz 121 del proveedor de la nube adecuada a la que el al menos un dispositivo informático 104 puede acceder.
[0027] La(s) interfaz (interfaces) 121 del proveedor de la nube representa(n), por lo tanto, una posible pluralidad de interfaces para interactuar con los proveedores 110, 116 de la nube, así como con otros proveedores de la nube, para utilizar de este modo las funcionalidades de gestión de MV de tales proveedores de la nube, representadas por el gestor 115 de MV del proveedor 110 de la nube. Durante las operaciones normales del sistema 100, cualquier persona o rol de administrador autorizados puede utilizar la una o más interfaces 121 del proveedor de la nube, y cualquier software de gestión asociado proporcionado por el consumidor de la nube, para desplegar nuevas máquinas virtuales. Una vez desplegadas, tales máquinas virtuales pueden ser accedidas y utilizadas por personas o roles adicionales autorizados para tal acceso.
[0028] Por ejemplo, el consumidor de la nube que implementa el al menos un dispositivo informático 104 puede representar a una empresa de desarrollo de software. El personal autorizado dentro de la empresa de desarrollo de software puede encargar y desplegar una serie de máquinas virtuales, tales como las máquinas virtuales 112, 114, para su utilización por diversos equipos de desarrolladores de software. Mientras tanto, otras funciones administrativas del negocio de desarrollo de software, tal como contabilidad o recursos humanos, también pueden incluir personal autorizado para encargar y desplegar máquinas virtuales adicionales, tales como las máquinas virtuales 118, 120.
[0029] En tales situaciones, en las que una gran cantidad de personal en un consumidor de la nube despliega y utiliza una gran cantidad de máquinas virtuales en una pluralidad de proveedores de la nube, es difícil evitar el desperdicio de recursos informáticos. Por ejemplo, cada proveedor 110, 116 de la nube típicamente mantendrá un acuerdo de nivel de servicio con el consumidor de la nube, que rige la utilización y las operaciones de las máquinas virtuales proporcionadas por ese proveedor de la nube. En las situaciones descritas en la presente memoria, el consumidor de la nube es responsable del despliegue y la utilización de tales máquinas virtuales según los acuerdos de nivel de servicio correspondientes, independientemente de un nivel de actividad real de tales máquinas virtuales por parte del consumidor de la nube.
[0030] En otras palabras, por ejemplo, si la máquina virtual 112 se enciende y se ejecuta utilizando recursos informáticos físicos subyacentes del proveedor 110 de la nube, entonces el consumidor de la nube que utiliza el al menos un dispositivo informático 104 tiene la libertad de determinar si utilizará activamente la máquina virtual 112 en diferentes grados o dejará que la máquina virtual 112 permanezca inactiva. Sin embargo, permitir períodos de baja actividad o inactividad de la máquina virtual 112 es un desperdicio de los recursos informáticos físicos del proveedor 110 de la nube. Como consecuencia, el proveedor de la nube podría decidir desactivar estas máquinas, según y en la medida en que se rija por el acuerdo de nivel de servicio correspondiente.
[0031] En consecuencia, como se describe en la presente memoria, el gestor energético 102 puede estar configurado para realizar la transición de las máquinas virtuales 112, 114 y las máquinas virtuales 118, 120 entre un estado encendido y un estado apagado. Por ejemplo, el gestor energético 102 puede estar configurado para activar y desactivar las máquinas virtuales 112/114 y 118/120, de una manera que conserve los recursos físicos de los proveedores 110, 116 de la nube y, al mismo tiempo, minimizar las pérdidas de disponibilidad no deseables o inaceptables de las MV 110/114 y 118/120 por parte del consumidor de la nube que utiliza el al menos un dispositivo informático 104. Dicho de otro modo, y como se describe en detalle a continuación, el gestor energético 102 está configurado para monitorizar las utilizaciones de las máquinas virtuales, predecir horarios periódicos de utilización para el futuro y encender/apagar activamente máquinas virtuales individuales o grupos de máquinas virtuales según los horarios previstos.
[0032] Por ejemplo, el gestor energético 102 incluye un extractor 122 de metadatos de despliegue, no contemplado en las reivindicaciones. El extractor 122 de metadatos de despliegue está configurado para monitorizar, detectar y de cualquier otro modo extraer metadatos de despliegue que caracterizan una manera y un grado en que se despliegan las diversas máquinas virtuales 112/114 y 118/120 ilustrativas.
[0033] Por ejemplo, tales metadatos de despliegue pueden incluir caracterizaciones de cuándo, cómo y por quién se desplegó cada máquina virtual, así como caracterizaciones del personal que utiliza cada máquina virtual. Por ejemplo, en el ejemplo de desarrollo de software descrito anteriormente, los metadatos de despliegue pueden incluir una identificación del administrador que desplegó las máquinas virtuales relevantes que se utilizan para el desarrollo de software, así como de los diferentes equipos de desarrolladores de software que utilizan cada máquina virtual, junto con detalles que describen a las personas y los equipos. Por ejemplo, se puede designar a algunos desarrolladores de software o grupos de desarrolladores de software como que trabajan en zonas horarias particulares, o con horarios de trabajo particulares, o en proyectos o tipos de proyectos particulares.
[0034] Otros tipos de metadatos de despliegue pueden incluir caracterizaciones de los tipos de aplicaciones u otros servicios que se proporcionan en o por cada máquina virtual. En otros ejemplos, puede ocurrir que una o más máquinas virtuales estén provistas de etiquetas, donde tales etiquetas generalmente se refieren a categorías o identificadores que se pueden asignar a máquinas virtuales, individualmente o como grupos. Otros ejemplos de tales metadatos de despliegue se proporcionan a continuación o resultarían evidentes.
[0035] Además de tales metadatos de despliegue, un extractor 124 de datos de rendimiento puede estar configurado para monitorizar las diversas máquinas virtuales y extraer métricas de rendimiento y otros datos que caracterizan las operaciones en curso de las diversas máquinas virtuales. Tales datos de rendimiento pueden incluir, por ejemplo, la utilización de la CPU, las velocidades de transferencia de red, la utilización de la memoria y las velocidades de transferencia entre las diferentes memorias que se utilizan.
[0036] En otras palabras, tales datos de rendimiento hacen referencia a una manera y un grado en que cada máquina virtual utiliza sus recursos físicos asignados, tales como las máquinas físicas, de entre los recursos físicos disponibles en el proveedor de la nube correspondiente. Por ejemplo, los datos de rendimiento pueden caracterizar, en términos absolutos, las cantidades de recursos de procesamiento, memoria y transferencia de datos que se utilizan. En otros ejemplos, se pueden rastrear las mismas métricas de rendimiento o métricas de rendimiento similares con respecto a los niveles de cada uno de tales recursos estipulados para proporcionarse dentro de un acuerdo de nivel de servicio relevante con el proveedor de la nube en cuestión. Al igual que con los metadatos de despliegue referidos anteriormente, ejemplos adicionales o alternativos de tales datos de rendimiento se proporcionan a continuación o resultarían evidentes.
[0037] En el ejemplo simplificado de la figura 1, se ilustra que un repositorio 126 de máquinas virtuales se utiliza para almacenar uno o ambos de los metadatos de despliegue y los datos de rendimiento. Por ejemplo, puede entenderse que el repositorio 126 de máquinas virtuales representa una implementación ilustrativa de un tipo del medio 108 de almacenamiento no transitorio legible por ordenador, utilizado en la presente memoria para el almacenamiento de datos. Por supuesto, los diferentes tipos de metadatos se pueden almacenar utilizando diferentes bases de datos u otros repositorios, y se puede acceder a ellos según sea necesario, utilizando consultas adecuadas u otras solicitudes de acceso.
[0038] En el ejemplo de la figura 1, un detector 128 de patrones de utilización está configurado para acceder al repositorio 126 de máquinas virtuales, para de este modo descubrir y caracterizar los patrones de utilización de las diversas máquinas virtuales 112/114 y 118/120. Por ejemplo, se ilustra que el detector 128 de patrones de utilización incluye un detector 130 de inactividad que está configurado para clasificar cada una de las máquinas virtuales 112/114 y 118/120 como activas o inactivas durante cada una de una pluralidad de divisiones de tiempo de un tiempo de prueba durante el cual se detectan patrones de utilización.
[0039] Por ejemplo, durante la operación del gestor energético 102, se puede iniciar y definir un tiempo de observación con respecto a una o más divisiones de tiempo específicas. Por ejemplo, un usuario del gestor energético 102 puede iniciar un tiempo de observación que es indefinido o que tiene un punto final definido de días, semanas, meses o años. El tiempo de observación y la extracción asociada de los datos/metadatos de las máquinas virtuales, tales como los metadatos de despliegue y los datos de rendimiento, se pueden definir con respecto a divisiones de tiempo especificadas. Por ejemplo, se pueden extraer y/o caracterizar los metadatos de las máquinas virtuales cada hora, y en los diversos ejemplos que siguen se utiliza el uso de la hora como la división de tiempo relevante más pequeña del tiempo de observación implementado por el gestor energético 102.
[0040] Por supuesto, se apreciará que se pueden utilizar otras divisiones de tiempo. Por ejemplo, las divisiones de tiempo relevantes se pueden definir en términos de minutos, grupos de minutos u otra escala de tiempo absoluta, o se pueden definir con respecto a la utilización específico de las máquinas virtuales 112/114 y 118/120 en cuestión. Por ejemplo, las divisiones de tiempo se pueden definir en términos de bloques de tiempo de los turnos de trabajo estándar de los empleados, o partes de los mismos, que particularmente pueden ser relevantes o se pueden aplicar al consumidor de la nube que utiliza el gestor energético 102.
[0041] Continuando con los ejemplos en los que la división de tiempo utilizada es la hora, el detector 130 de inactividad puede estar configurado para aplicar criterios de inactividad predeterminados para clasificar, para cada hora, cada máquina virtual como activa o inactiva. A continuación se proporcionan en detalle ejemplos específicos de tales criterios de inactividad. En general, se apreciará que tales criterios de inactividad especifican tasas o cantidades mínimas o máximas de recursos informáticos físicos utilizados por cada máquina virtual durante cada hora que se caracteriza, así como combinaciones de las mismas.
[0042] Por ejemplo, los criterios de inactividad pueden especificar tasas de utilización o cantidades máximas de utilización de la CPU, utilización de la memoria y/o utilización de la transferencia de datos o combinaciones de las mismas. De este modo, el detector 130 de inactividad puede estar configurado para generar una serie activa-inactiva para cada una de las máquinas virtuales 112/114 y 118/120.
[0043] Un detector 132 de periodicidad puede estar configurado para analizar cada serie activa-inactiva resultante proporcionada por el detector 130 de inactividad. El detector 132 de periodicidad está configurado para determinar si existe una periodicidad de tiempos de inactividad recurrentes dentro de un tiempo de observación relevante para cada máquina virtual. Por ejemplo, el detector 132 de periodicidad puede detectar que la máquina virtual 112 tiene un período de inactividad que dura una o más divisiones de tiempo, y eso ocurre con una periodicidad definida en términos de horas, días, semanas o meses. Por ejemplo, puede ocurrir un período de inactividad que dura dos horas y que ocurre cada día desde la medianoche hasta las 2:00 a. m. con una zona horaria relevante de la máquina virtual 112. Como se describe en detalle a continuación, el detector 132 de periodicidad puede estar configurado para determinar y definir períodos de tiempos de inactividad recurrentes para cada máquina virtual con diferentes niveles de confianza. En otras palabras, el detector 132 de periodicidad no se requiere necesariamente para detectar un período absoluto o completo de tiempos de inactividad recurrentes. Por ejemplo, en el ejemplo dado anteriormente en el que ocurre un intervalo de inactividad de dos horas al día a medianoche, puede ocurrir que el intervalo de inactividad relevante no ocurra cada día durante el tiempo de observación relevante. El intervalo de inactividad puede ocurrir seis de los siete días de una semana o 28 días de los 30 días de un mes. Por lo tanto, el detector 132 de periodicidad puede estar configurado para designar un grado en el que ocurren períodos de tiempos de inactividad recurrentes, sin requerir necesariamente el cumplimiento completo de los tiempos de inactividad detectados por cada máquina virtual en cuestión.
[0044] El detector 130 de inactividad y el detector 132 de periodicidad están configurados, por lo tanto, para recopilar y analizar metadatos existentes que se recopilan y almacenan dentro del repositorio 126 de máquinas virtuales. Un predictor 134 de intervalos está configurado para utilizar los períodos definidos por el detector 132 de periodicidad, para predecir intervalos en los que cada una de las máquinas virtuales 112/114 y 118/120 debería apagarse o encenderse durante futuras operaciones de las mismas.
[0045] Durante las operaciones iniciales, el predictor 134 de intervalos puede predecir tales horarios de encendido/apagado para las diversas máquinas virtuales y realizar una estimación de fiabilidad de los mismos, antes de utilizar los intervalos previstos. Por ejemplo, un gestor 136 de fiabilidad puede estar configurado para detectar y comparar los intervalos de encendido/apagado previstos para una máquina virtual, con la utilización o la actividad real de esa máquina virtual (determinada a partir de los datos de rendimiento correspondientes dentro del repositorio 126 de máquinas virtuales). Basándose en estas comparaciones, se puede cuantificar y caracterizar una precisión y fiabilidad de los intervalos previstos.
[0046] Por ejemplo, en el ejemplo simplificado anterior en el que se prevé que la máquina virtual 112 se apague cada día entre la medianoche y las 2:00 a. m., el gestor 136 de fiabilidad puede monitorizar datos de rendimiento de la máquina reales y en curso para la máquina virtual 112 desde el repositorio 126, para analizar de este modo una precisión del intervalo previsto. En otras palabras, por ejemplo, el gestor 136 de fiabilidad puede determinar un número o porcentaje de veces que la máquina virtual 112 experimenta una utilización activa durante el intervalo de tiempo de inactividad prevista.
[0047] Dicho de otro modo, durante un tiempo de estimación de fiabilidad que se incluye dentro del tiempo de observación, el gestor 136 de fiabilidad puede comparar los tiempos de inactividad reales presentados por la máquina virtual 112 durante el tiempo de estimación de fiabilidad, en comparación con los tiempos de inactividad previstos proporcionados por el predictor 134 de intervalos. De forma similar, el gestor 136 de fiabilidad puede comparar los tiempos de actividad reales presentados por la máquina virtual 112 durante el tiempo de estimación de fiabilidad, en comparación con los tiempos de actividad previstos. En los casos en los que la fiabilidad resultante de los intervalos previstos no alcanza un umbral de fiabilidad determinado, el gestor 136 de fiabilidad puede iniciar un bucle de retroalimentación a uno o más de los detectores 130 de inactividad, el detector 132 de periodicidad y/o el predictor 134 de intervalos, de modo que se puedan predecir intervalos más precisos y fiables.
[0048] Como se ha descrito anteriormente, aunque el ejemplo simplificado de la figura 1 ilustra únicamente las máquinas virtuales 112/114 y 118/120, las situaciones prácticas pueden incluir, p. ej., consumidores de la nube que utilizan cientos o miles de máquinas virtuales, en una pluralidad de proveedores de la nube. Para ayudar con la gestión de energía en estas situaciones, un gestor 138 de grupos está configurado para acceder a los metadatos de despliegue desde el repositorio 126 de máquinas virtuales. El gestor 138 de grupos puede utilizar los metadatos de despliegue para agrupar máquinas virtuales para su inclusión como grupos dentro de intervalos de encendido/apagado previstos por el predictor 134 de intervalos y analizados por el gestor 136 de fiabilidad. De este modo, por ejemplo, grupos enteros de máquinas virtuales se pueden apagar y encender juntos, aumentando de este modo una eficiencia global de las operaciones del gestor energético 102.
[0050] Como se describe en detalle a continuación, el gestor 138 de grupos puede utilizar cualquiera de los metadatos de despliegue referidos anteriormente, o descritos en mayor detalle a continuación, solos o juntos para definir grupos de máquinas virtuales para la programación colectiva de encendido/apagado. Por ejemplo, puede ocurrir que la máquina virtual 114 y la máquina virtual 120 sean utilizadas por el mismo equipo de desarrolladores de software y/o se desplieguen con las mismas aplicaciones o aplicaciones similares instaladas en las mismas. En consecuencia, las máquinas virtuales 114/120 se pueden encender/apagar juntas como parte de un grupo definido, aunque las máquinas virtuales 114/120 estén desplegadas en los diferentes proveedores 110/116 de la nube.
[0052] Por lo tanto, en general, y como se describe en mayor detalle a continuación, la presencia de los mismos metadatos de despliegue o metadatos de despliegue similares en uno o más grupos de máquinas virtuales puede ser indicativa de o estar correlacionada con el mismo horario de encendido/apagado o un horario de encendido/apagado similar. En otras situaciones, puede ocurrir que los grupos de máquinas virtuales definidos por el gestor 138 de grupos no tengan intervalos de energía que coincidan exactamente. No obstante, puede ocurrir que las eficiencias obtenidas al agrupar máquinas virtuales para programar la energía puedan superar las reducciones globales de la fiabilidad del cumplimiento, por parte de las máquinas virtuales individuales, de los intervalos previstos para esas máquinas virtuales.
[0054] Por ejemplo, dos o más máquinas virtuales pueden tener intervalos previstos iguales o similares, pero con diferentes niveles de fiabilidad según lo determine el gestor 136 de fiabilidad. Como se acaba de mencionar, se puede mejorar la eficiencia global aceptando el menor nivel de fiabilidad de las máquinas virtuales en cuestión. Dicho de otro modo, a un diseñador de sistemas se le proporciona ventajosamente la flexibilidad de configurar niveles relativos de fiabilidad y eficiencia en un horario de energía previsto.
[0056] De forma más general, el gestor 136 de fiabilidad puede operar estimando una fiabilidad de cada grupo definido por el administrador 108 de grupos, de una manera similar a las técnicas de estimación de fiabilidad descritas en la presente memoria que se realizan con respecto a máquinas virtuales individuales. En particular, por ejemplo, las salidas del gestor 136 de fiabilidad se pueden utilizar en bucles de retroalimentación apropiados con respecto a cualquiera de los detectores 130 de inactividad, el detector 132 de periodicidad, el predictor 134 de intervalos y el gestor 138 de grupos, para garantizar que los horarios de intervalos de energía previstos y analizados sean lo suficientemente fiables para la aplicación de los mismos a las diversas máquinas virtuales representadas por las máquinas virtuales 112/114 y 118/120.
[0058] Una vez que se ha completado el tiempo de estimación de fiabilidad del tiempo de observación global, se puede proporcionar el horario de energía resultante a un controlador 140 de energía. El controlador 140 de energía está configurado para encender y apagar los grupos de máquinas virtuales identificados según el horario de energía previsto durante un tiempo de implementación de la operación del gestor energético 102.
[0060] Durante las transiciones de energía subsiguientes que ejecuta el controlador 140 de energía, el gestor energético 102 puede continuar ejecutando uno o más procedimientos paralelos. Por ejemplo, el extractor 122 de metadatos de despliegue y/o el extractor 124 de datos de rendimiento pueden continuar extrayendo y almacenando metadatos de las máquinas virtuales dentro del repositorio 126 de máquinas virtuales. Adicionalmente, se puede implementar un tiempo de observación posterior, que incluye detecciones asociadas de patrones de utilización actualizados, junto con operaciones de agrupamiento actualizadas del gestor 138 de grupos.
[0062] En consecuencia, el controlador 140 de energía puede implementar un horario de energía actualizado. Por ejemplo, el horario de energía actualizado puede reemplazar el horario de energía anterior después de una cantidad de tiempo predeterminada. En otros ejemplos, las actualizaciones detectadas en los metadatos de despliegue y/o los datos de rendimiento pueden activar una transición al horario de energía actualizado. Por ejemplo, los cambios en los metadatos de despliegue pueden obviar o reducir la aplicabilidad de los grupos calculados por el gestor 138 de grupos. En algunas implementaciones, el controlador 140 de energía puede estar configurado para interactuar con las interfaces 121 del proveedor de la nube para ejecutar la energía deseada del horario de energía. Por ejemplo, el controlador 140 de energía puede utilizar una de las interfaces 121 del proveedor de la nube para interactuar con el gestor 115 de MV del proveedor 110 de la nube.
[0063] En los ejemplos descritos anteriormente, se describe que el al menos un dispositivo informático 104 es implementado por un consumidor de la nube que consume servicios de máquinas virtuales de los proveedores 110, 116 de la nube. Sin embargo, en otras implementaciones ilustrativas, el al menos un dispositivo informático 104 puede ser implementado por cualquiera de los proveedores 110, 116 de la nube o ambos.
[0065] Por ejemplo, el proveedor 110 de la nube puede implementar el gestor energético 102 para conservar los recursos físicos del proveedor 110 de la nube. Por ejemplo, el proveedor 110 de la nube puede implementar una gran cantidad de máquinas virtuales en una gran cantidad de máquinas físicas subyacentes y para una pluralidad de consumidores de la nube. En general, el proveedor 110 de la nube puede desear utilizar sus recursos informáticos físicos de forma eficiente, tal como consolidando máquinas virtuales para su operación en la menor cantidad necesaria de máquinas físicas.
[0067] Al apagar grupos de máquinas virtuales utilizando el gestor energético 102 como se describe en la presente memoria, se puede proporcionar al proveedor 110 de la nube una capacidad, por ejemplo, de apagar algunas o todas las máquinas virtuales que se ejecutan en una máquina física en particular. En consecuencia, se puede proporcionar al proveedor 110 de la nube una capacidad de desactivar tal máquina física al menos temporalmente y/o se le puede facilitar la tarea de consolidar las máquinas virtuales apagadas en otra máquina física que actualmente se está infrautilizando.
[0069] La figura 2 es un diagrama de flujo que ilustra operaciones ilustrativas más detalladas del sistema 100 de la figura 1. En el ejemplo de la figura 2, las operaciones 202-212 se ilustran como operaciones secuenciales independientes. En diversas implementaciones, puede ocurrir que se incluyan operaciones o suboperaciones adicionales o alternativas y/o que se omitan una o más operaciones o suboperaciones. Además, en todas estas implementaciones, se apreciará que diversas operaciones o suboperaciones se pueden ejecutar de manera parcial o completamente coincidente o paralela, o de forma anidada, ramificada, en bucle o iterativa.
[0071] En el ejemplo de la figura 2, para un tiempo de observación dividido en divisiones de tiempo, se puede monitorizar una pluralidad de máquinas virtuales que se ejecutan en máquinas físicas (202). Por ejemplo, el gestor energético 102, p. ej., el extractor 122 de metadatos de despliegue y/o el extractor 124 de datos de rendimiento, puede utilizar una o más interfaces 121 del proveedor de la nube para monitorizar aspectos de las máquinas virtuales 112/114 y 118/120. Por lo tanto, como se describe, tal monitorización se puede realizar en o por un consumidor de la nube, que puede consumir máquinas virtuales de múltiples proveedores de la nube. Como también se describe, tal monitorización la puede realizar un único proveedor de la nube, con respecto a las máquinas virtuales proporcionadas por ese proveedor de la nube a una pluralidad de consumidores de la nube.
[0073] Se pueden extraer datos de rendimiento que caracterizan el consumo de recursos físicos de las máquinas físicas por parte de las máquinas virtuales durante el tiempo de observación, extrayéndose los datos de rendimiento con respecto a cada una de las divisiones de tiempo (204). Por ejemplo, el extractor 124 de datos de rendimiento puede extraer datos de rendimiento que caracterizan el consumo de recursos físicos tanto del proveedor 110 de la nube como del proveedor 116 de la nube provocado por las máquinas virtuales 112/114 y 118/120, respectivamente. Cuando la unidad o división de tiempo que se puede aplicar es, p. ej., una hora, entonces los datos de rendimiento relevantes se pueden extraer y/o almacenar dentro del repositorio 126 de máquinas virtuales en incrementos de una hora. Como también se ha mencionado, debe entenderse que los recursos físicos de las máquinas físicas de los proveedores 110, 116 de la nube se refieren en sentido amplio, por ejemplo, a cualquier servidor, ordenador, enrutador, conmutador, procesador, memoria u otro hardware relacionado con el ordenador o la red. Tales recursos físicos se pueden caracterizar utilizando cualquier manera apropiada o adecuada, tal como, por ejemplo, ciclos de procesamiento, cantidades de memoria utilizadas, velocidades de transferencia, o energía consumida. Además, los datos de rendimiento se pueden extraer y almacenar con respecto a cada máquina virtual, aunque se apreciará que todos estos datos de rendimiento representan, caracterizan, y podrían expresarse en términos de, la utilización de los recursos físicos subyacentes correspondientes de las máquinas físicas.
[0075] Cada una de la pluralidad de máquinas virtuales se puede clasificar como activa o inactiva durante cada división de tiempo del tiempo de observación, basándose en los datos de rendimiento y en los criterios de inactividad, para generar de este modo una serie activa-inactiva para cada una de la pluralidad de máquinas virtuales (206). Por ejemplo, como se ha mencionado anteriormente y como se describe y detalla a continuación, el detector 130 de inactividad puede implementar tales criterios de inactividad, por ejemplo, combinaciones especificadas de las caracterizaciones de datos de rendimiento relevantes de los recursos físicos, con respecto a un umbral o disposiciones de inactividad predefinidos. Por lo tanto, puede entenderse que la serie activa-inactiva resultante para cada una de las máquinas virtuales 112/114 y 118/120 se representa como una serie de incrementos consecutivos de una hora, en los que cada hora se marca efectivamente como activa o inactiva.
[0077] Para cada serie activa-inactiva de cada máquina virtual de la pluralidad de máquinas virtuales, se puede determinar que existe al menos una periodicidad de tiempos de inactividad recurrentes dentro del tiempo de observación (208). Por ejemplo, el detector 132 de periodicidad del detector 128 de patrones de utilización de la figura 1 puede estar configurado para analizar cada serie activa-inactiva y ejecutar uno o más algoritmos para determinar si existe una periodicidad y en qué grado. Por ejemplo, dependiendo de la duración del tiempo de observación, el detector 132 de periodicidad puede detectar uno o más períodos que son diarios, semanales o mensuales.
[0078] El detector 132 de periodicidad también puede cuantificar o caracterizar un nivel de confianza o intensidad de una periodicidad detectada. Por ejemplo, un período de inactividad diario detectado puede ocurrir en un único momento de cada día del tiempo de observación y con la misma duración de inactividad cada día. Sin embargo, en otros ejemplos, una máquina virtual dada puede presentar el período diario detectado solo durante un porcentaje de días del tiempo de observación. Durante otros días del tiempo de observación, la misma máquina virtual puede que no presente ningún tiempo de inactividad durante la una o más horas de inactividad detectadas y/o puede presentar solo una inactividad parcial o coincidente.
[0079] Para cada máquina virtual con la al menos una periodicidad, se puede predecir un modelo de encendido/apagado (210). Por ejemplo, el predictor 134 de intervalos puede estar configurado para recibir los períodos detectados y las caracterizaciones de los mismos desde el detector 132 de periodicidad. El predictor 134 de intervalos puede ejecutar criterios de predicción de intervalos para generar el horario de encendido/apagado.
[0080] Por ejemplo, se puede requerir que un período detectado tenga un nivel umbral de confianza, duración u otra característica antes de ser utilizado por el predictor 134 de intervalos. En algunas implementaciones, como se describe, los intervalos previstos se pueden analizar utilizando el gestor 136 de fiabilidad, antes de proceder al paraciclado real de las diversas máquinas virtuales mediante el controlador 140 de energía.
[0081] Por ejemplo, el tiempo de observación puede continuar con, e incluir, un tiempo de estimación de fiabilidad durante el cual el gestor 136 de fiabilidad utiliza metadatos de las máquinas virtuales del repositorio 126 de máquinas virtuales para evaluar la precisión y fiabilidad de los intervalos previstos por el predictor 134 de intervalos. Por ejemplo, los extractores 122, 124 pueden continuar extrayendo los diversos tipos de metadatos de las máquinas virtuales descritos en la presente memoria durante el tiempo de estimación de fiabilidad, para su utilización por el gestor 136 de fiabilidad. Al utilizar, por ejemplo, salidas adicionales del detector 130 de inactividad, el gestor 136 de fiabilidad puede comparar eficazmente los metadatos reales de las máquinas virtuales con los intervalos previstos por el predictor 134 de intervalos. De este modo, por ejemplo, el gestor 136 de fiabilidad puede caracterizar en qué grado los intervalos previstos habrían generado incorrectamente el apagado de una máquina virtual que realmente se utilizó durante el tiempo de inactividad previsto o, a la inversa, el número de veces que una máquina virtual está inactiva durante un tiempo de actividad previsto.
[0082] La transición de cada una de las máquinas virtuales con la al menos una periodicidad se puede realizar con la al menos una periodicidad entre un estado encendido y un estado apagado según el modelo de encendido/apagado previsto (212). Por ejemplo, el controlador 140 de energía puede estar configurado para encender, y apagar, cualquiera de las máquinas virtuales 112/114 y 118/120. En consecuencia, se pueden conservar los recursos asociados con proporcionar esas máquinas virtuales.
[0083] Aunque no se ilustra específicamente con respecto a la figura 2 y no está contemplado en las reivindicaciones, el gestor 138 de grupos puede estar configurado para utilizar los metadatos de despliegue proporcionados por el extractor 122 de metadatos de despliegue, y almacenados en el repositorio 126 de máquinas virtuales, para agrupar varias de las máquinas virtuales 112/114 y 118/120 para el ciclado de energía colectivo de las mismas.
[0084] Las figuras 3 y 4 son diagramas en bloque que ilustran flujos operativos ilustrativos del sistema 100 de la figura 1 y del diagrama 200 de flujo de la figura 2. En el ejemplo de la figura 3, se ilustra que un primer proveedor 302 de la nube incluye y proporciona una pluralidad de máquinas virtuales 304. Al mismo tiempo, se ilustra que un segundo proveedor 306 de la nube incluye y proporciona una pluralidad de máquinas virtuales 308.
[0085] En la figura 3, los servicios, las aplicaciones y las etiquetas se pueden descubrir y extraer, como una implementación ilustrativa del extractor 122 de metadatos de despliegue, y los metadatos de despliegue resultantes se pueden almacenar utilizando la base 312 de datos, ilustrada como una base de datos de la gestión de configuración (CMDB, por sus siglas en inglés)/base de datos de descubrimiento, y proporcionando un ejemplo del repositorio 126 de máquinas virtuales de la figura 1. Además, en la figura 3, los ETL (parámetros de extracción, transformación, carga) de rendimiento se ejecutan además para extraer datos de rendimiento ilustrativos, p. ej., información que caracteriza las métricas de rendimiento ilustradas en la figura 3 como ETL de rendimiento.
[0086] La recolección 316 de métricas resultante, que incluye, en el ejemplo, las métricas de utilización de la CPU, la red y el disco de la máquina virtual, se puede proporcionar para la detección 318 del patrón de encendido/apagado. Como se describe, tales patrones de utilización representan períodos recurrentes en los que las máquinas virtuales se pueden encender o apagar basándose en las recomendaciones de los horarios 320 de tiempo exactos.
[0087] Los servicios, las aplicaciones, las etiquetas y otros metadatos de despliegue previamente descubiertos y extraídos se pueden utilizar entonces para la formación 322 de grupos. Es decir, el gestor 138 de grupos de la figura 1 puede utilizar los horarios de encendido/apagado recomendados para agrupar pluralidades de ciclados de energía colectivos de las máquinas virtuales.
[0088] Por ejemplo, continuando con el ejemplo de la figura 3 y la figura 4, se ilustra que el primer proveedor 302 de la nube incluye un primer grupo de máquinas virtuales 402, el segundo grupo 404 y el tercer grupo 406. Al mismo tiempo, se ilustra que el segundo proveedor 306 de la nube incluye un primer grupo 406 y un segundo grupo 408. En diversas implementaciones, los grupos se pueden formar dentro de un único proveedor de la nube, como se muestra en la figura 4, o en múltiples proveedores de la nube.
[0089] Además en la figura 4, un usuario 410, tal como un administrador en el consumidor de la nube que consume las diversas máquinas virtuales de los proveedores 302, 306 de la nube, puede aplicar las reglas 412 basadas en etiquetas para determinar si se aprueba el horario de energía generado y las predicciones de formación de grupos. Como se ilustra, la aprobación 414 también puede incluir una aprobación basada en reglas, que no requiere intervención humana.
[0090] La orquestación 416 en la nube se puede utilizar entonces para encender y apagar grupos de máquinas virtuales, según los horarios de energía de la recomendación, como se muestra en el bloque 418. Por ejemplo, con referencia nuevamente a la figura 1, el controlador 140 de energía del gestor energético 102 puede utilizar las interfaces 121 del proveedor de la nube adecuadas para ordenar y ejecutar el ciclado de energía recopilado de los grupos de máquinas virtuales descritos, según los horarios de energía previstos.
[0091] La figura 5 es un diagrama de flujo que ilustra operaciones ilustrativas más detalladas del sistema 100 de la figura 1. Específicamente, la figura 5 ilustra operaciones ilustrativas más detalladas del detector 128 de patrones de utilización. Como se describe con respecto a la figura 1, el detector 130 de inactividad está configurado para acceder a los datos de rendimiento extraídos por el extractor 124 de datos de rendimiento y almacenados dentro del repositorio 126 de máquinas virtuales. En el ejemplo de la figura 5, tales datos de rendimiento incluyen los datos 502 de rendimiento, que se ilustran como que incluyen la utilización de la CPU, las velocidades de transferencia de disco y la utilización de la red (p. ej., la velocidad de bytes de red) de la máquina virtual.
[0092] Como también se ha descrito anteriormente, el detector 130 de inactividad puede procesar los datos 502 de rendimiento, basándose en los criterios 504 de detección de inactividad predeterminados. Por ejemplo, se puede describir cada uno de los datos 502 de rendimiento con respecto a las métricas de rendimiento diseñadas en relación con las tasas de utilización mínimas o máximas, o las cantidades de utilización. Por lo tanto, se pueden considerar tales valores limitados de las métricas de rendimiento, solos o juntos, con respecto a cada división de tiempo del tiempo de observación.
[0093] Por ejemplo, una máquina virtual dada se puede definir como inactiva dentro de una hora si, durante esa hora, la máquina virtual tiene una utilización de la CPU que es inferior a un umbral especificado, una velocidad de bytes de red que es inferior a un determinado umbral de velocidad y/o una velocidad de transferencia de disco que es inferior a un umbral predefinido. Por lo tanto, por ejemplo, una máquina virtual se puede considerar inactiva durante una hora en la que la utilización de la CPU de la máquina virtual es inferior a, p. ej., el 5 %, una velocidad de bytes de red utilizada por la máquina virtual es inferior a, p. ej., 200 kilobits por segundo y/o la velocidad de transferencia de disco de la máquina virtual es inferior a, por ejemplo, 100 kilobytes por segundo. Por supuesto, se pueden utilizar otros intervalos y umbrales de parámetros adecuados.
[0094] Por lo tanto, los criterios de detección de inactividad que se utilizan pueden estar configurados de cualquier manera adecuada o deseada. Por ejemplo, además de variar los umbrales para cada métrica de rendimiento, los criterios 504 de detección de inactividad pueden utilizar métricas de rendimiento adicionales o alternativas y combinaciones de las mismas. Por ejemplo, en el ejemplo que se acaba de dar, se puede considerar que se cumplen los criterios de detección de inactividad si dos cualesquiera de los tres valores de las métricas de rendimiento están por debajo de sus umbrales relevantes.
[0095] Por lo tanto, en el ejemplo, el detector 130 de inactividad puede estar configurado para realizar determinaciones de inactividad cada hora, para proporcionar de este modo una serie inactiva_activa 505 para cada máquina virtual. Por ejemplo, la serie inactiva_activa 505 puede estar construida como una serie binaria de 0-1. Es decir, en tales ejemplos, si una máquina virtual está inactiva en una hora dada, entonces a la serie se le asigna un valor de 0 para esa hora y en caso contrario se le asigna un valor de 1.
[0096] En las siguientes partes de la figura 5, se analiza la serie inactiva_activa 505 para determinar la existencia de períodos, si los hubiera, que presentan patrones recurrentes durante los cuales la máquina virtual pasa de estar funcionando activamente a estar inactiva. Como se ha mencionado anteriormente, una determinación inicial para extraer estos períodos recurrentes incluye un intervalo de tiempo (y los metadatos asociados) del que posiblemente se pueden extraer los períodos recurrentes. En general, los intervalos más largos proporcionarán más tipos de períodos recurrentes que se pueden detectar.
[0097] Por ejemplo, como se muestra en la figura 5, en situaciones ilustrativas, un intervalo de datos considerado puede tener seis meses de duración (506), tres meses de duración (508) o un mes de duración (510). Por ejemplo, para un intervalo de datos que incluye seis meses (506), se puede detectar la presencia de períodos mensuales, semanales o diarios o combinaciones de los mismos. Por ejemplo, un ejemplo de un patrón relevante puede incluir una máquina virtual que funciona todos los meses los dos primeros días del mes y entre los horarios de las 3:00 p. m. y las 10:00 p. m., o una máquina virtual que funciona todos los meses, las dos primeras semanas del mes y solo los sábados y domingos. Para un intervalo de datos de tres meses (508), se puede detectar la presencia de combinaciones semanales, diarias o semanales/diarias. Por ejemplo, una máquina virtual puede funcionar todas las semanas, pero solo los fines de semana entre las 3:00 p. m. y las 8:00 p. m., mientras que durante el resto de la semana está inactiva.
[0098] Para un intervalo de datos de un mes (510), se pueden detectar períodos diarios. Por ejemplo, tales períodos diarios de inactividad se pueden repetir todos los días, a la misma hora u horas. Por ejemplo, este patrón puede incluir una máquina virtual que funciona todos los días entre las 9:00 a. m. y las 6:00 p. m., mientras que durante el resto del día está inactiva.
[0099] En el ejemplo de la figura 5, como se muestra, el detector 130 de inactividad puede realizar una determinación de sí o no en cada intervalo 506, 508, 510 de datos disponible. Si uno o más de los intervalos de datos están disponibles, entonces el detector 132 de periodicidad puede proceder a ejecutar uno o más algoritmos de detección de períodos. En el ejemplo de la figura 5, el detector 132 de periodicidad está configurado para implementar una detección (512) de frecuencia para encontrar una probabilidad de los respectivos períodos recurrentes subyacentes en los metadatos analizados, utilizando solo puntos dentro del intervalo relevante. Por ejemplo, para encontrar un período diario, se puede ejecutar un análisis de frecuencia que incluye determinar u obtener, p. ej., contar, un número de horas de actividad durante todos los días dentro del intervalo relevante. Entonces, si un porcentaje de tales horas de actividad, que puede denominarse porcentaje de actividad, es mayor que un umbral de frecuencia predefinido, entonces se determina que la máquina virtual en cuestión está encendida durante la hora relevante considerada.
[0100] El umbral de frecuencia se puede seleccionar inicialmente para representar un balance entre la disponibilidad de capacidad y la optimización de recursos. Por ejemplo, se puede calcular un recuento del porcentaje de actividad como un porcentaje que se define como un recuento de los valores de actividad para la hora específica dentro del intervalo considerado, dividido por el número total de muestras para esa hora dentro del intervalo.
[0101] Por ejemplo, una hora en consideración puede ser la hora que ocurre entre las 3:00 p. m. y las 4:00 p. m. para una máquina virtual en particular. Durante un mes (p. ej., 30 días) de datos de rendimiento recopilados, se puede considerar cada una de las 30 instancias de la hora de 3:00 p. m.-4:00 p. m. Como se ha descrito anteriormente con respecto a la serie inactiva_activa 505, cada una de las 30 horas consideradas tendrá un valor de 0 o 1. Si, en un ejemplo, cada una de las instancias de 30 horas tiene un valor de 1, de modo que se considera que la máquina virtual ha estado activa durante cada hora de cada día considerado, y el porcentaje del recuento de actividad sería del 100 %.
[0102] Por otro lado, si, en la misma situación, puede ocurrir que la hora de 3:00 p. m.-4:00 p. m considerada para cada uno de los 30 días tenga un recuento de actividad de 15 de los 30 días disponibles. Entonces, el porcentaje del recuento de actividad sería del 50 %. Si el umbral de frecuencia se define para tener un valor de, p. ej., el 70 %, entonces el porcentaje del recuento de actividad superaría el umbral de frecuencia en el primer ejemplo, pero no superaría el umbral de frecuencia en el segundo ejemplo.
[0103] Para encontrar un patrón de encendido-apagado semanal, se puede repetir el mismo mecanismo de recuento que se acaba de describir para obtener un análisis de frecuencia semanal. Por ejemplo, para un intervalo que incluye uno o más meses, se puede construir el par (hora, día de la semana). Es decir, a cada valor de la hora se le puede asignar entre 1-24, mientras que a cada valor del día de la semana se le puede asignar entre 1-7. Entonces, durante todas las semanas en el intervalo considerado, si el porcentaje de actividad por hora para cada hora supera el umbral de frecuencia que se ha establecido, entonces se considera que estas horas en el día de la semana en que estas horas se encuentran posiblemente presenten un patrón recurrente.
[0104] Por ejemplo, para un intervalo de tres meses, el número total de semanas es de 12 semanas. Se puede contar un número de veces que la máquina virtual en cuestión estuvo activa durante cada hora, superponiendo el mismo día de la semana para todas las 12 semanas en el conjunto de datos. Este enfoque es un ejemplo de cómo identificar la existencia de patrones semanales, así como patrones diarios, dentro del intervalo que se está considerado. Este enfoque se describe e ilustra en mayor detalle más adelante, con respecto a la figura 6. Sin embargo, generalmente, en un ejemplo simplificado, puede ocurrir que se determine que una máquina virtual dada funciona únicamente todos los sábados y domingos, de 3:00 p. m.-10:00 p. m. y 1:00 a. m-5:00 a. m., cada semana.
[0105] En un ejemplo final de la detección 512 de frecuencia, para encontrar un período mensual, se puede realizar un análisis de frecuencia mensual, que amplía el enfoque que se acaba de describir anteriormente para la detección del período semanal. Es decir, por ejemplo, se puede construir un par (hora, día del mes) para cada hora en todos los meses en el intervalo considerado. En otras palabras, se puede construir un par (hora, día del mes) en el que el valor de la hora varía entre 1-24, y el valor del día del mes varía entre 1-31.
[0106] Utilizando este enfoque, se pueden identificar los días en cada mes el intervalo considerado en los que se ocurre una actividad recurrente. Además, se pueden identificar las horas específicas en las que se encuentra un patrón. Por ejemplo, durante un intervalo de seis meses, se puede determinar que una máquina virtual examinada está activa cada 4.º, 5.º y 6.º día del mes, durante un intervalo de 5:00 p. m-11:00 p. m.
[0107] En los tipos de ejemplos descritos anteriormente, el umbral de frecuencia se puede establecer en un nivel deseado y también se puede ajustar, como se describe a continuación. Los patrones recurrentes se pueden definir de forma equivalente como períodos recurrentes de actividad o períodos recurrentes de inactividad. Por ejemplo, en algunas situaciones, puede que una máquina virtual dada solo esté activa durante unas pocas horas cada semana o cada mes, mientras que durante el resto de un intervalo considerado esté inactiva. Por otro lado, puede que otras máquinas virtuales solo estén activas durante pequeños porcentajes de tiempo durante el intervalo considerado.
[0108] Si se descubre que existen (514) uno o más períodos, se puede obtener un modelo de períodos activos que llena una serie de 1,0 horas que se denomina serie patrón_de_encendido_apagado (516). En la figura 5, en la que representa una hora que se recomienda encender para la máquina virtual en cuestión, y 0 representa una hora donde se debe apagar la máquina virtual.
[0109] Se pueden utilizar múltiples algoritmos, si es necesario o se desea, para determinar los períodos activos o inactivos. Por ejemplo, si el enfoque de detección de frecuencia no puede encontrar un período recurrente, se puede utilizar una función de autocorrelación (ACF, por sus siglas en inglés) para una posible detección (524) adicional de períodos. En el enfoque de la ACF, la periodicidad se detecta calculando una función de autocorrelación de la serie inactiva_activa, detectando después los picos en la función resultante y encontrando la distancia promedio entre ellos. Una salida de ACF que muestra un pico relevante en un desfase de tiempo dado indica la existencia de una periodicidad que no está dentro de una periodicidad diaria/semanal/mensual. Por ejemplo, la ACF puede detectar periodicidades tales como “cada 5 horas”.
[0110] Por lo tanto, este enfoque puede ayudar a encontrar una periodicidad no esperada. El método de la ACF es sensible al ruido y a la variabilidad aleatoria coincidente con la señal periódica, lo que ocurre típicamente en los datos de rendimiento. El detector 132 de periodicidad complementa esto con el enfoque de probabilidad/frecuencia que, si bien opera solo en períodos fijos (predefinidos, pero muy probables en los sistemas de TI), compensa el ruido utilizando el umbral de frecuencia, como se describe en la presente memoria.
[0111] Si la detección (524) de períodos mediante la ACF u otras técnicas de detección de períodos no encuentran la existencia de períodos recurrentes (526), entonces el proceso de la figura 5 se detendrá para la máquina virtual considerada y no se proporciona (528) ninguna recomendación para la MV considerada.
[0112] Por otro lado, si se descubre que existen (526) períodos adicionales, entonces se puede proporcionar el mismo tiempo de la serie patrón_de_encendido_apagado (516). La serie patrón_de_encendido_apagado resultante se puede someter entonces a los tipos de cálculo (518) de fiabilidad descritos anteriormente con respecto al gestor 136 de fiabilidad de la figura 1. Por ejemplo, como se ha descrito anteriormente, el cálculo (518) de fiabilidad se puede ejecutar durante un tiempo de estimación de fiabilidad que está incluido dentro del tiempo de observación global. Es decir, como se describe, la serie patrón_de_encendido_apagado (516) se utiliza y compara durante el tiempo de estimación de fiabilidad con los datos de rendimiento actuales o recientes que el extractor 124 de datos de rendimiento continúa recopilando. En otras palabras, en el ejemplo de la figura 5, los metadatos 502 de utilización se recopilan de forma continua durante el tiempo de estimación de fiabilidad y se clasifican como activos o inactivos. A continuación, la serie activa/inactiva resultante obtenida para cada máquina virtual a partir de los metadatos 502 de utilización en curso se compara, hora por hora, con la serie patrón_de_encendido_apagado (516) prevista.
[0113] A continuación, se puede calcular y analizar un índice de fiabilidad (520). Por ejemplo, el índice de fiabilidad se puede calcular como un porcentaje de horas en la serie activa/inactiva de los datos 502 de rendimiento en curso, con respecto a cada hora correspondiente de la serie patrón_de_encendido_apagado (516) prevista. Según esta definición, el índice de fiabilidad puede tener un valor de 100 en situaciones en las que cada hora de la serie inactiva_activa calculada para los datos de rendimiento en curso coincide con cada hora correspondiente de la serie patrón_de_encendido_apagado (516). Dicho de otro modo, basándose en un período de observación relevante, puede entenderse que la fiabilidad de una máquina virtual representa una diferencia entre el número de horas que se prevé que la máquina virtual esté inactiva y el número de horas que la máquina virtual no estuvo inactiva, dividida por el número de horas que se prevé que la máquina virtual esté inactiva.
[0114] En diversos ejemplos, no es necesario que el índice de fiabilidad tenga un valor de 100, y puede determinarse que valores más bajos para el índice de fiabilidad son aceptables, dependiendo de otros parámetros del sistema. Por ejemplo, puede que se requiera que las máquinas de misión crítica tengan un índice de fiabilidad más alto que las máquinas virtuales que se utilizan para ejecutar tareas que no son urgentes. El índice de fiabilidad lo puede establecer el gestor 136 de fiabilidad y puede estar configurado para que se pueda aplicar a cada implementación del sistema 100 en su conjunto, o se puede modificar para tener valores diferentes para grupos diferentes de máquinas virtuales o, no contemplado en las reivindicaciones, se puede cambiar basándose en metadatos de despliegue extraídos obtenidos por el extractor 122 de metadatos de despliegue y almacenados utilizando el repositorio 126 de máquinas virtuales (p. ej., las máquinas virtuales que ejecutan diferentes aplicaciones o servicios se pueden proporcionar con diferentes índices de fiabilidad).
[0115] En algunas implementaciones, como se ilustra en la figura 5, se pueden implementar requisitos adicionales para analizar el índice de fiabilidad. Por ejemplo, se puede requerir una estabilidad del índice de fiabilidad dentro de un cierto intervalo y que se presente durante un período de tiempo definido. En algunas implementaciones ilustrativas, se pueden requerir la estabilidad del índice de fiabilidad y un valor mínimo del índice de fiabilidad mientras que, en otras implementaciones, solo se puede requerir alguna combinación de uno o ambos.
[0116] Si se supera la prueba de fiabilidad, entonces se puede proporcionar (522) la recomendación con intervalos en los que encender/apagar la máquina virtual en cuestión. De cualquier otro modo, como se muestra, se puede proporcionar un bucle de retroalimentación en el que, por ejemplo, se modifica un umbral de frecuencia relevante, y se repite la detección de períodos (512-520, 524, 526). Por ejemplo, si el índice de fiabilidad que se calcula es indeseablemente bajo, entonces el umbral de frecuencia se puede modificar para aplicar requisitos más estrictos para la detección de períodos. Sin embargo, en otros ejemplos, si el índice de fiabilidad es igual a 100, entonces el umbral de frecuencia se puede modificar en una dirección para flexibilizar los requisitos para la detección de períodos.
[0117] Por ejemplo, se pueden repetir las operaciones de detección de períodos, predicción de patrones y pruebas de fiabilidad, mientras se aumenta progresiva e iterativamente el umbral de frecuencia, con un valor de fiabilidad estable como condición de salida. En tales ejemplos, la serie patrón_de_encendido_apagado correspondiente al primer umbral en el que se estabilizó el índice de fiabilidad se devuelve como el patrón encontrado. En el ejemplo, en este punto, se considera que se ha encontrado el patrón de encendido/apagado para la máquina virtual en cuestión.
[0118] Las operaciones de la figura 5 se pueden repetir para todas las máquinas virtuales relevantes. Siempre que sea posible, las operaciones de la figura 5 se pueden repetir para cada máquina virtual en paralelo. Como también se ha descrito anteriormente, una vez que las operaciones de la figura 5 se han repetido para todas las máquinas virtuales disponibles, el gestor 138 de grupos puede procesar los horarios de encendido/apagado resultantes.
[0119] Por ejemplo, como se describe, las máquinas virtuales se pueden agrupar por servicios, aplicaciones y etiquetas, junto con las zonas horarias relevantes y otros factores, y de una manera que proporciona horarios de encendido/apagado coincidentes y/o simultáneos. De forma similar al índice de fiabilidad descrito anteriormente, se puede calcular un índice de grupo que refleje en qué grado los horarios de encendido/apagado de cada máquina virtual de cada grupo coinciden con los de otras máquinas virtuales de ese grupo. Por ejemplo, un índice de grupo de 100 puede indicar que todas las máquinas virtuales de un grupo específico tienen patrones_de_encendido_apagado exactamente correspondientes y coincidentes.
[0120] Por ejemplo, si una máquina virtual en un grupo tiene una hora de inactividad cada semana que es una hora de actividad para el resto de las máquinas virtuales de ese grupo, entonces puede que la máquina virtual en cuestión simplemente se deje encendida junto con las máquinas virtuales restantes del grupo, independientemente de la predicción real de la serie activa/inactiva para esa máquina virtual. En tales casos, en otras palabras, se puede considerar que el beneficio de poder realizar un ciclado de energía colectivo para el grupo supera la desventaja de dejar la máquina virtual encendida durante una hora que es inactiva para esa máquina virtual.
[0121] Por otro lado, puede ocurrir que se prediga que una máquina virtual estará activa durante una hora en la que se predice que el resto de las máquinas virtuales del grupo estarán inactivas. En tales casos, la determinación de si se debe apagar la máquina virtual en cuestión durante la hora que problema puede depender de diversos factores. Por ejemplo, tales factores pueden incluir el porcentaje de máquinas virtuales que se prevé que estén activas o inactivas durante la hora en cuestión, o la criticidad de las operaciones de la máquina virtual que se apagarían durante una hora en la que se prevé la actividad.
[0122] En general, es posible hacer cumplir o flexibilizar las restricciones de agrupamiento ampliando o encogiendo los intervalos de encendido/apagado para incluir más máquinas virtuales dentro del grupo que se forma. Una vez que los grupos están definidos, los grupos pueden analizarse de una forma similar a las pruebas de fiabilidad descritas anteriormente y someterse a un bucle de retroalimentación para optimizar los agrupamientos. En otros ejemplos, un administrador puede o denegar la aprobación del grupo que se ha formado.
[0123] Una vez que se han formado los grupos, el controlador 140 de energía puede utilizar las credenciales de la nube para las máquinas virtuales en cuestión para encender o apagar las diversas máquinas virtuales en grupos, y basándose en los intervalos programados recomendados.
[0124] La figura 6 es un diagrama de flujo que ilustra una implementación ilustrativa de las figuras 1-5, que incluye ejemplos específicos de los períodos previstos de la figura 5. En el ejemplo de la figura 6, las técnicas de la figura 5 se utilizan para encontrar un período semanal. Como se muestra, se aplican (602) los criterios de inactividad, tal como mediante el detector 130 de inactividad de la figura 1, para obtener la serie activa-inactiva 604. Es decir, como se muestra, la serie activa-inactiva 604 identifica las horas de actividad e inactividad en un intervalo de datos de aproximadamente 500 horas, o aproximadamente 3 semanas. Por supuesto, la figura 6 se simplifica a modo de ejemplo, y se pueden utilizar intervalos de datos más largos.
[0125] El detector 132 de periodicidad de la figura 1 se puede utilizar para implementar la detección (606) de periodicidad. Como se muestra, y como se acaba de describir con respecto a la figura 5, el detector 132 de periodicidad puede calcular primero una frecuencia de actividad de la máquina virtual en cuestión (608). El gráfico 610 ilustra la frecuencia con la que la máquina virtual estará activa (o inactiva) durante cada hora de cada una de las tres semanas del ejemplo. A continuación, se puede aplicar (612) el umbral de frecuencia. Es decir, como se muestra, el gráfico 614 incluye un límite o umbral 615, que requiere una frecuencia de al menos dos de las tres semanas del ejemplo. Se puede observar a partir de la aplicación del umbral 615 que algunas partes del recuento de frecuencias del gráfico 610 ya no están incluidas en el gráfico 614, tal como los recuentos 213.
[0126] De este modo, el predictor 134 de intervalos puede proceder a predecir un modelo de períodos activos, o un modelo (616) de encendido-apagado, ilustrado como modelo 618. En el ejemplo, se prevén intervalos de tiempos de actividad para los tiempos ilustrados del lunes y el viernes, mientras que la máquina virtual se apagaría durante el resto del lunes/viernes y el resto de la semana (sábado/domingo y martes-jueves), de modo que se puedan conservar los recursos.
[0127] En otras palabras, un sistema comprende un medio de almacenamiento no transitorio legible por ordenador y al menos un procesador. Las instrucciones almacenadas en el medio de almacenamiento no transitorio legible por ordenador (es decir, un producto de programa informático) están configuradas para hacer que el al menos un procesador: monitorice, durante un tiempo de observación dividido en divisiones de tiempo, una pluralidad de máquinas virtuales que se ejecutan en máquinas físicas; extraiga datos de rendimiento que caracterizan el consumo de recursos físicos de las máquinas físicas por parte de la pluralidad de máquinas virtuales durante el tiempo de observación, extrayéndose los datos de rendimiento con respecto a cada una de las divisiones de tiempo; clasifique cada una de la pluralidad de máquinas virtuales como activa o inactiva durante cada división de tiempo del tiempo de observación, basándose en los datos de rendimiento y en los criterios de inactividad, para generar de este modo una serie activainactiva para cada una de la pluralidad de máquinas virtuales; determine, para cada serie activa-inactiva de cada máquina virtual de la pluralidad de máquinas virtuales, al menos una periodicidad de tiempos de inactividad recurrentes dentro del tiempo de observación; prediga, para cada máquina virtual con la al menos una periodicidad, un horario de encendido-apagado; y realice la transición de cada una de las máquinas virtuales con la al menos una periodicidad entre un estado encendido y un estado apagado según el horario de encendido-apagado.
[0128] Opcionalmente, las divisiones de tiempo son horas, y los datos de rendimiento comprenden la utilización por hora de al menos un procesador de las máquinas físicas, una velocidad de bytes de red de los bytes de datos intercambiados con una red por las máquinas físicas, y una velocidad de transferencia datos de los bytes de datos por una memoria de las máquinas físicas.
[0129] Opcionalmente, los criterios de inactividad comprenden un conjunto predeterminado de umbrales de utilización, para cada división de tiempo, de dos o más de al menos un procesador de las máquinas físicas, una velocidad de bytes de red de los bytes de datos intercambiados con una red por las máquinas físicas, y una velocidad de transferencia datos de los bytes de datos por una memoria de las máquinas físicas.
[0130] Opcionalmente, las instrucciones, cuando se ejecutan para determinar la al menos una periodicidad, están configuradas además para hacer que el al menos un procesador: examine la serie activa-inactiva para un intervalo de datos que incluye unidades de tiempo de uno o más días, semanas o meses; y ejecute, para la serie activa-inactiva, un análisis de frecuencia en el que un porcentaje del recuento de actividad para cada división de tiempo de la serie activa-inactiva, con respecto a las unidades de tiempo del intervalo de datos, se compara con un umbral de frecuencia. Opcionalmente, las instrucciones, cuando se ejecutan para predecir el horario de encendido-apagado, están configuradas además para hacer que el al menos un procesador prediga el horario de encendido-apagado para cada máquina virtual basándose en el análisis de frecuencia.
[0131] Las instrucciones, cuando se ejecutan, están configuradas además para hacer que el al menos un procesador: calcule, antes de la transición, un índice de fiabilidad del horario de encendido-apagado durante un tiempo de estimación de fiabilidad del tiempo de observación, que incluye comparar el horario de encendido-apagado calculado para cada máquina virtual con un horario real de la misma durante el tiempo de estimación de fiabilidad.
[0132] Las instrucciones, cuando se ejecutan, están configuradas además para hacer que el al menos un procesador: determine que el índice de fiabilidad es inferior a un umbral de fiabilidad; y ajuste el umbral de frecuencia para mejorar el índice de fiabilidad; y vuelva a ejecutar el análisis de frecuencia con el umbral de frecuencia ajustado.
[0133] Opcionalmente, no contempladas en las reivindicaciones, las instrucciones, cuando se ejecutan, están configuradas además para hacer que el al menos un procesador: extraiga metadatos de despliegue que caracterizan una manera en la que cada máquina virtual se despliega durante el tiempo de observación, incluidos uno o más de una aplicación instalada, un servicio, o un usuario asignado.
[0134] Opcionalmente, no contempladas en las reivindicaciones, las instrucciones, cuando se ejecutan, están configuradas además para hacer que el al menos un procesador: defina un grupo de la pluralidad de máquinas virtuales, basándose en los metadatos de despliegue y en la similitud de los horarios de encendido-apagado de cada máquina virtual del grupo; determine un horario de encendido-apagado grupal para el grupo; y realice la transición del grupo entre el estado encendido y el estado apagado de forma colectiva y según el horario de encendido-apagado grupal.
[0135] Opcionalmente, al menos dos proveedores de la nube que proporcionan las máquinas físicas proporcionan la pluralidad de máquinas virtuales.
[0136] Las implementaciones de las diversas técnicas descritas en la presente memoria se pueden implementar en sistemas de circuitos electrónicos digitales o en hardware, firmware, software informáticos, o en combinaciones de los mismos. Las implementaciones se pueden implementar como un producto de programa informático, es decir, un programa informático incorporado de forma tangible en un soporte de información no transitorio, p. ej., en un dispositivo de almacenamiento legible por máquina (un medio legible por ordenador) para su procesamiento mediante, o para controlar la operación de, un aparato de procesamiento de datos, p. ej., un procesador programable, un ordenador o múltiples ordenadores. Un programa informático, tal como el (los) programa(s) informático(s) descrito(s) anteriormente, se puede escribir en cualquier forma de lenguaje de programación, incluidos los lenguajes compilados o interpretados, y se puede desplegar en cualquier forma, incluso como un programa independiente o como un módulo, un componente, una subrutina u otra unidad adecuada para utilizar en un entorno informático. Un programa informático se puede desplegar para procesarse en un ordenador o en múltiples ordenadores en un sitio o distribuirse en múltiples sitios e interconectarse mediante una red de comunicaciones.
[0137] Uno o más procesadores programables que ejecutan un programa informático pueden realizar los pasos del método para realizar funciones operando con datos de entrada y generando datos de salida. Los pasos del método también pueden ser realizados por, y un aparato se puede implementar como, sistema de circuitos lógicos de propósito especial, p. ej., una FPGA (matriz de puertas programables en campo) o un ASIC (circuito integrado de aplicación específica).
[0138] Los procesadores adecuados para el procesamiento de un programa informático incluyen, a modo de ejemplo, microprocesadores de propósito tanto general como especial, y uno cualquiera o más procesadores de cualquier tipo de ordenador digital. Generalmente, un procesador recibirá instrucciones y datos de una memoria de solo lectura o de una memoria de acceso aleatorio o ambas. Los elementos de un ordenador pueden incluir al menos un procesador para ejecutar instrucciones y uno o más dispositivos de memoria para almacenar instrucciones y datos. Generalmente, un ordenador también puede incluir o estar acoplado operativamente para recibir datos de o transferir datos a, o ambos, uno o más dispositivos de almacenamiento masivo para almacenar datos, p. ej., discos magnéticos, discos magnetoópticos o discos ópticos. Los soportes de información adecuados para incorporar instrucciones y datos de programas informáticos incluyen todas las formas de memoria no volátil, incluidos, a modo de ejemplo, los dispositivos de memoria semiconductora, p. ej., EPROM, EEPROM y dispositivos de memoria flash; discos magnéticos, p. ej., discos duros internos o discos extraíbles; discos magnetoópticos; y discos CD ROM y DVD-ROM. El procesador y la memoria pueden complementarse con o incorporarse en sistema de circuitos lógicos de propósito especial.
[0139] Para proporcionar interacción con un usuario, las implementaciones se pueden implementar en un ordenador que tiene un dispositivo de visualización, p. ej., un monitor de tubo de rayos catódicos (CRT, por sus siglas en inglés) o con pantalla de cristal líquido (LCD), para mostrar información al usuario y un teclado y un dispositivo de señalización, p. ej., un ratón o una bola de seguimiento, por el cual el usuario puede proporcionar entrada al ordenador. Otros tipos de dispositivos se pueden usar para proporcionar interacción con un usuario; por ejemplo, la retroalimentación proporcionada al usuario puede ser cualquier forma de retroalimentación sensorial, p. ej., retroalimentación visual, retroalimentación auditiva o retroalimentación táctil; y la entrada del usuario puede recibirse en cualquier forma, incluyendo entrada acústica, de voz o táctil.
[0140] Las implementaciones se pueden implementar en un sistema informático que incluye un componente de back-end, p. ej., como un servidor de datos, o que incluye un componente de middleware, p. ej., un servidor de aplicación, o que incluye un componente de front-end, p. ej., un ordenador de cliente que tiene una interfaz gráfica de usuario o un navegador Web a través del cual un usuario puede interactuar con una implementación, o cualquier combinación de tales componentes de back-end, middleware o front-end. Los componentes pueden estar interconectados por cualquier forma o medio de comunicación de datos digitales, p. ej., una red de comunicaciones. Los ejemplos de redes de comunicaciones incluyen una red de área local (LAN) y una red de área amplia (WAN), p. ej., el Internet.
[0141] Si bien ciertas características de las implementaciones descritas se han ilustrado como se describe en la presente memoria, a los expertos en la técnica se les ocurrirán ahora muchas modificaciones, sustituciones, cambios y equivalentes. Por lo tanto, debe entenderse que las reivindicaciones adjuntas pretenden contemplar todas estas modificaciones y cambios que están dentro del alcance de las realizaciones. Debe entenderse que se han presentado solo a modo de ejemplo, no de limitación, y se pueden realizar diversos cambios en la forma y los detalles. Cualquier parte del aparato y/o los métodos descritos en la presente memoria se puede combinar en cualquier combinación, excepto combinaciones mutuamente excluyentes. Las realizaciones descritas en la presente memoria pueden incluir diversas combinaciones y/o subcombinaciones de las funciones, componentes y/o características de las diferentes realizaciones descritas.

Claims (6)

1. REIVINDICACIONES
1. Un método implementado por ordenador para operar un dispositivo informático (104) que interactúa con al menos una máquina física de un proveedor (110) de la nube a través de una interfaz (121) del proveedor de la nube, comprendiendo el método:
monitorizar mediante un extractor (124) de datos de rendimiento del dispositivo (104), una pluralidad de máquinas virtuales que se ejecutan en máquinas físicas y extraer datos de rendimiento como métricas que caracterizan las operaciones en curso de las máquinas virtuales, extrayéndose la métrica de los datos de rendimiento con respecto a divisiones de tiempo de un tiempo de observación;
clasificar mediante un detector (128) de patrones de utilización cada una de la pluralidad de máquinas virtuales como activa o inactiva durante cada división de tiempo del tiempo de observación, basándose en los datos de rendimiento y en los criterios de inactividad, para generar de este modo una serie activa-inactiva para cada una de la pluralidad de máquinas virtuales;
determinar mediante un detector (132) de periodicidad del dispositivo (104), , para cada serie activa-inactiva de cada máquina virtual de la pluralidad de máquinas virtuales, al menos una periodicidad de tiempos de inactividad recurrentes dentro del tiempo de observación;
predecir mediante un predictor (134) de intervalos del dispositivo (104), , para cada máquina virtual con la al menos una periodicidad, un horario de encendido/apagado; y
realizar mediante un controlador (140) de energía del dispositivo (104), la transición de cada una de las máquinas virtuales con la al menos una periodicidad entre un estado encendido y un estado apagado según el horario de encendido-apagado, en donde el controlador (140) de energía utiliza la interfaz (121) del proveedor de la nube para interactuar con un gestor (115) de MV del proveedor (110) de la nube;
en donde el determinar la al menos una periodicidad comprende:
examinar la serie activa-inactiva para un intervalo (506, 508, 510) de datos que incluye unidades de tiempo de uno o más días, semanas o meses; y
ejecutar, para la serie activa-inactiva (505), un análisis de frecuencia calculando un porcentaje del recuento de actividad para la serie activa-inactiva, como el número de instancias de actividad para una división de tiempo específica con respecto al número de divisiones de tiempo específicas correspondientes dentro del intervalo de datos, comparando el porcentaje del recuento de actividad con un umbral de frecuencia; comprendiendo el método además: calcular, antes de la transición, un índice de fiabilidad del horario de encendido-apagado durante un tiempo de estimación de fiabilidad del tiempo de observación, que incluye comparar el horario de encendido-apagado calculado para cada máquina virtual con un horario real de la misma durante el tiempo de estimación de fiabilidad; determinar que el índice de fiabilidad es inferior a un umbral de fiabilidad; ajustar el umbral de frecuencia para mejorar el índice de fiabilidad; y volver a ejecutar el análisis de frecuencia con el umbral de frecuencia ajustado.
2. El método de la reivindicación 1, en donde las divisiones de tiempo son horas, y en donde los datos de rendimiento incluyen la utilización por hora de al menos un procesador de las máquinas físicas, una velocidad de bytes de red de los bytes de datos intercambiados con una red por las máquinas físicas, y una velocidad de transferencia datos de los bytes de datos por una memoria de las máquinas físicas.
3. El método de la reivindicación 1, en donde los criterios de inactividad incluyen un conjunto predeterminado de umbrales de utilización, para cada división de tiempo, de dos o más de al menos un procesador de las máquinas físicas, una velocidad de bytes de red de los bytes de datos intercambiados con una red por las máquinas físicas, y una velocidad de transferencia datos de los bytes de datos por una memoria de las máquinas físicas.
4. El método de la reivindicación 3, en donde el predecir el horario de encendido-apagado comprende:
predecir el horario de encendido-apagado para cada máquina virtual basándose en el análisis de frecuencia, en donde el análisis de frecuencia se basa en intervalos de fechas que incluyen intervalos de tiempo, con intervalos de datos relativamente más grandes que tienen intervalos de tiempo relativamente grandes y con intervalos de datos relativamente cortos que tienen intervalos de tiempo relativamente cortos.
5. Un sistema informático adaptado para ejecutar el método según cualquiera de las reivindicaciones 1 a 4.
6. Un producto de programa informático que comprende instrucciones que, cuando el programa es ejecutado por un ordenador, hacen que el ordenador lleve a cabo el método según cualquiera de las reivindicaciones 1 a 4.
ES23163866T 2018-12-31 2019-12-29 Power saving through automated power scheduling of virtual machines with reliability index adjustments Active ES3057778T3 (en)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
US16/236,939 US10817046B2 (en) 2018-12-31 2018-12-31 Power saving through automated power scheduling of virtual machines

Publications (1)

Publication Number Publication Date
ES3057778T3 true ES3057778T3 (en) 2026-03-04

Family

ID=69055802

Family Applications (1)

Application Number Title Priority Date Filing Date
ES23163866T Active ES3057778T3 (en) 2018-12-31 2019-12-29 Power saving through automated power scheduling of virtual machines with reliability index adjustments

Country Status (3)

Country Link
US (1) US10817046B2 (es)
EP (2) EP4224318B1 (es)
ES (1) ES3057778T3 (es)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11526370B2 (en) * 2019-03-10 2022-12-13 Microsoft Technology Licensing, Llc. Cloud resource management using machine learning
US11698814B2 (en) * 2019-08-28 2023-07-11 Vega Cloud, Inc. Cloud resources management
CN112328289B (zh) * 2020-11-26 2023-08-25 新华三信息技术有限公司 一种固件升级方法、装置、设备及存储介质
US11385973B1 (en) * 2020-12-17 2022-07-12 Citrix Systems, Inc. High-availability for power-managed virtual desktop access
CN113010269B (zh) * 2021-03-29 2024-02-23 深信服科技股份有限公司 一种虚拟机调度方法、装置、电子设备及可读存储介质
CN113110730B (zh) * 2021-04-09 2022-02-01 北京润尼尔网络科技有限公司 运行设备节能的方法、装置及电子设备
US12149417B2 (en) * 2021-07-14 2024-11-19 Hughes Network Systems, Llc Efficient maintenance for communication devices
US20230351124A1 (en) * 2022-04-29 2023-11-02 Zoom Video Communications, Inc. Providing real-time translation during virtual conferences
US20240111591A1 (en) * 2022-09-30 2024-04-04 Advanced Micro Devices, Inc. Executing Kernel Workgroups Across Multiple Compute Unit Types
US12309050B2 (en) * 2023-07-25 2025-05-20 Dish Wireless L.L.C. Network computing for network function testing

Family Cites Families (24)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5249920B2 (ja) * 2007-07-05 2013-07-31 パナソニック株式会社 データ処理装置、データ処理方法、データ処理プログラム、記録媒体及び集積回路
US20090265707A1 (en) 2008-04-21 2009-10-22 Microsoft Corporation Optimizing application performance on virtual machines automatically with end-user preferences
US8046468B2 (en) * 2009-01-26 2011-10-25 Vmware, Inc. Process demand prediction for distributed power and resource management
US9201485B2 (en) * 2009-05-29 2015-12-01 Red Hat, Inc. Power management in managed network having hardware based and virtual resources
JP5469940B2 (ja) 2009-07-13 2014-04-16 株式会社日立製作所 計算機システム、仮想計算機モニタ及び仮想計算機モニタのスケジューリング方法
US8887171B2 (en) * 2009-12-28 2014-11-11 Intel Corporation Mechanisms to avoid inefficient core hopping and provide hardware assisted low-power state selection
US20120053925A1 (en) 2010-08-31 2012-03-01 Steven Geffin Method and System for Computer Power and Resource Consumption Modeling
US9250962B2 (en) 2011-01-10 2016-02-02 International Business Machines Corporation Optimizing energy use in a data center by workload scheduling and management
US9639379B1 (en) 2011-07-19 2017-05-02 Open Invention Network Llc Dynamic configuration of virtual machines
DE102012217202B4 (de) 2011-10-12 2020-06-18 International Business Machines Corporation Verfahren und System zum Optimieren des Platzierens virtueller Maschinen in Cloud-Computing-Umgebungen
US8904008B2 (en) 2012-01-09 2014-12-02 Microsoft Corporation Assignment of resources in virtual machine pools
US9396008B2 (en) 2012-07-13 2016-07-19 Ca, Inc. System and method for continuous optimization of computing systems with automated assignment of virtual machines and physical machines to hosts
US10289437B2 (en) 2014-01-07 2019-05-14 Red Hat Israel, Ltd. Idle processor management in virtualized systems via paravirtualization
US9405572B2 (en) 2014-04-07 2016-08-02 International Business Machines Corporation Optimized resource allocation and management in a virtualized computing environment
US9672068B2 (en) * 2014-10-09 2017-06-06 Vmware, Inc. Virtual machine scheduling using optimum power-consumption profile
JP6347730B2 (ja) 2014-11-27 2018-06-27 株式会社日立製作所 計算機システム及び計算機リソースの割当て管理方法
CA2987734A1 (en) 2015-04-28 2016-11-03 Solano Labs, Inc. Cost optimization of cloud computing resources
US20160350214A1 (en) 2015-05-29 2016-12-01 Google Inc. Idle time software garbage collection
US9846476B1 (en) 2015-06-30 2017-12-19 EMC IP Holding Company LLC System and method of identifying the idle time for lab hardware thru automated system
CN108207114B (zh) 2015-08-18 2021-12-21 瑞典爱立信有限公司 用于重新配置虚拟机的技术
US20170093966A1 (en) 2015-09-28 2017-03-30 International Business Machines Corporation Managing a shared pool of configurable computing resources having an arrangement of a set of dynamically-assigned resources
US9678783B2 (en) 2015-10-14 2017-06-13 International Business Machines Corporation Temporal dynamic virtual machine policies
WO2017105376A1 (en) * 2015-12-14 2017-06-22 Vce Company, Llc Methods, systems, and computer readable mediums for workload clustering
US9766693B2 (en) * 2016-01-07 2017-09-19 International Business Machines Corporation Scheduling framework for virtual machine power modes

Also Published As

Publication number Publication date
EP4224318A1 (en) 2023-08-09
EP3674892A1 (en) 2020-07-01
EP3674892B1 (en) 2023-11-08
US10817046B2 (en) 2020-10-27
US20200209946A1 (en) 2020-07-02
EP4224318B1 (en) 2025-12-03

Similar Documents

Publication Publication Date Title
ES3057778T3 (en) Power saving through automated power scheduling of virtual machines with reliability index adjustments
US10521002B2 (en) Systems and methods for dynamic spatial power steering
Awad et al. Machine learning in action: Examples
Udayasankaran et al. Energy efficient resource utilization and load balancing in virtual machines using prediction algorithms
JP6668355B2 (ja) 動的時間的電力ステアリングのためのシステム及び方法
Mandala et al. Optimizing cloud resource management via dynamic auto-scaling in e-commerce applications: Enhancing load balancing and performance efficiency
US11301348B2 (en) Computer network with time series seasonality-based performance alerts
Kim et al. P 4: Phase-based power/performance prediction of heterogeneous systems via neural networks
Makrani et al. Adaptive performance modeling of data-intensive workloads for resource provisioning in virtualized environment
Algarni et al. Predictive energy management for Docker containers in cloud computing: A time series analysis approach
Nawrocki et al. Anomaly detection in the context of long-term cloud resource usage planning
Kim et al. A supervised learning model for identifying inactive VMs in private cloud data centers
Huang et al. Cloudprophet: a machine learning-based performance prediction for public clouds
Pasricha et al. Data analytics enables energy-efficiency and robustness: from mobile to manycores, datacenters, and networks (special session paper)
Sáez et al. Design support for performance aware dynamic application (re-) distribution in the cloud
Ilager Machine Learning-based Energy and Thermal Efficient Resource Management Algorithms for Cloud Data Centres.
Massari et al. Harnessing performance variability: A HPC-oriented application scenario
Kim Safe Exploration for Dynamic Computer Systems Optimization
Capalbo et al. Enhancing Cloud Energy Efficiency through Predictive Machine Learning for Inter-and Intra-Data Center VM Consolidation
Wang et al. Performance Prediction for Power-Capped Applications based on Machine Learning Algorithms
Kavanagh et al. Energy-aware self-adaptive middleware for heterogeneous parallel architectures
US11442442B2 (en) Sensor event coverage and energy conservation
Sharma et al. An Empirical Study of Different Techniques for the Improvement of Quality of Service in Cloud Computing
Saha Predictive analysis for cloud resource management
Zhang et al. THOR: A Generic Energy Estimation Approach for On-Device Training