EXTENSIBLE MODEL FOR IT RESOURCE CHARGEBACK

The present disclosure provides techniques for chargeback of IT resources. Resource change data may be stored until the data is accessed by a chargeback system. The chargeback system may access the resource change data daily and may convert the resource change data to daily resource usage and cost data. The resource usage and cost data may be stored in a chargeback database and the daily usage and cost data may be reported.

DETAILED DESCRIPTION OF SPECIFIC EMBODIMENTS

Embodiments disclosed herein provide techniques for chargeback of IT resources. Defining a chargeback solution for a cloud environment is a difficult task due to growing complexity and evolving characteristics of the cloud environment. The chargeback solution described herein enables a cloud computing service provider to accommodate the pace of innovation and harvest economic value from new concepts still emerging in cloud computing.

Current chargeback, metering, and account systems do not integrate extract, transform, and load (ETL) with data warehousing concepts in a chargeback use case in a way that provides a built-in/pre-configured solution that can be analyzed to support decision processes. In general, chargeback use cases are implemented in terms of a ticket without the capability of daily consolidated view. The implementation of a data warehouse solution requires a large effort of definition, configuration, and database specialists. The integration of the technologies provides a built-in chargeback system that allows some evaluations of trends, frequently used resources, and the like.

FIG. 1is a diagram of a cloud computing system with a chargeback system. The cloud computing system100can be a public system, a community system, a hybrid system, a private system, or some combination of systems. In an example, a cloud computing system100includes a cloud102including a combination of physical hardware104, virtual hardware106, and software108. The cloud computing system100also includes a client110. The cloud computing system100may include a single client device110or multiple client devices110. The client device110can be a desktop computer, a laptop computer, a tablet computer, a cellular phone, such as a smartphone, or any other suitable device. The client device110may be coupled to the cloud102via a wired connection or a wireless connection. In an example, the client device110is coupled to the cloud102via an Ethernet connection, a WLAN connection, a LAN connection, or any other suitable connection method. In an example, the cloud102receives service requests from a client110and returns a service result to the client.

A cloud computing system100is a system in which multiple pieces of hardware and software are utilized over a network to perform specific computing tasks. The combination of physical hardware104, virtual hardware106, and software108is often referred to as the cloud102. The cloud symbol is often used to represent the abstraction of a network.

Physical hardware104may include processors, memory devices, and networking equipment, among others. The physical hardware104performs the actual computing and processing required by the cloud computing system100. For example, the physical hardware104performs a computation requested by a client device110.

Virtual hardware106is a type of software that is processed by physical hardware104but is designed to emulate a specific set of hardware. For example, a particular piece of software is designed to be run by a specific type of hardware. By running virtual hardware106on top of the physical hardware104, a given piece of hardware can run software designed for many different types of hardware.

Software108may be defined as a set of instructions and data configured to cause a processor to perform specific processes. These processes can be used for running applications which are made available to an end user. Software is designed to operate with specific hardware architecture. Hardware architecture may indicate the format of the processor instructions. Thus, one benefit of using virtual hardware is that multiple different hardware components can all operate the same software.

The physical hardware104, virtual hardware106, and the software108associated with the cloud can be configured to receive service requests from a client device110. The cloud computing system100can then perform the desired processes and return the result to the client device110.

The cloud computing system100may also include an infrastructure management system112. The infrastructure management system112is responsible for managing the computing resources of the cloud computing system100. For example, infrastructure management system112creates new virtual hardware106emulated by physical hardware104and installs software108on either physical hardware104or virtual hardware106.

The cloud computing system100further includes a chargeback system114, which may be coupled to the infrastructure management system112. The chargeback system114is a hardware system including one or more processors. The chargeback system114tracks the computing resource usage of the cloud computing system100that is attributable to specific users. For example, the chargeback system114tracks computing resource usage, such as by a specific user, and the cost of the resource usage on a daily basis. By tracking the computing resource usage of the cloud computing system100, a client system or device110can be charged for the use of resources in a cloud computing system100.

FIG. 2is a diagram of an example of the chargeback system and an infrastructure management system. The infrastructure management system112may be coupled to a chargeback system114via a staging area202. The staging area202can record changes in computing resources. For example, recording changes in computing resources include recording the state of the infrastructure of a computing system, such as the cloud computing system100. The state of the infrastructure can be recorded at the moment of change to the state of the infrastructure. A change in the infrastructure can trigger a recording of the instantaneous state of the infrastructure. In an example, a change in the infrastructure is caused or initiated by a user. The infrastructure management system112may log changes to the infrastructure in the staging area202. Changes to the infrastructure can include changes to the hardware configuration of the virtual hardware106, changes to physical hardware104configuration, changes to the power state, changes to software108, changes to the cost of computing resources, changes of the owning user, and creation of new virtual hardware106or new physical hardware104. In another example, the staging area monitors the infrastructure for changes. The staging area can also list all policy costs. Policy costs refer to the set cost for use of each resource for a specified period of time. For example, the policy cost can be the cost to a user for the use or allocation of a resource for a specified period of time.

The staging area202can store recorded changes in computing resources until the data is accessed by the chargeback system114. For example, the chargeback system114can access the staging area202daily, such as at a predetermined period of time each day. In another example, the staging area202notifies the chargeback system114of resource change data awaiting analysis. The resource change data can be received in the cleanser204. The cleanser204can perform uniformization of the data. For example, the cleanser204resolves conflicts within the resource change data. In another example, the cleanser204removes inconsistencies within the resource change data.

The resource change data can be passed to a transformer206. The transformer206can perform calculations, such as resource usage calculations. The transformer206can also perform resource usage cost calculations. In an example, the cost is based on the resource usage. In an example, the resource usage is calculated first, then used to calculate the cost of the calculate usage. The policy costs may be stored in the staging area202and accessed by the chargeback system114. For example, the policy costs are accessed by the chargeback system114when the resource change data is transferred from the staging area202to the chargeback system114.

The resource usage and cost data can be transferred to a loader208, which loads the data into a chargeback database210. The chargeback database210can be a warehouse-like database. The chargeback database210can be pre-defined in terms of charged resources, such as network, servers, disks, and infrastructure services. If a new resource is to be tracked, the chargeback database can add a new definition for the new resource. The chargeback database210stores the usage and cost data in tables. Each table can track a particular resource. If a new resource is to be tracked, a new table can be added to the chargeback database210to track the new resource. The tables of the chargeback database210may be interrelated in a database schema to facilitate information retrieval. For example, the tables are interrelated in a star schema design.

A retriever212gathers information from the chargeback database210. For example, the retriever212gathers resource usage and cost data from the chargeback database210. The retriever212can consolidate the gathered data into a daily report of resource usage and cost. In some examples, the retriever212gathers resource usage and/or cost data for a period of time determined by a user. The retriever212can then consolidate the gathered data into a report.

The information gathered by the retriever212may be accessed by another application, such as a billing system. Access to the information gathered by the retriever212can be facilitated by a simple object access protocol (SOAP) application programming interface (API)214. In some examples, the SOAP API214is a web services layer allowing another application to access resource usage and cost data. In another example, the SOAP API214allows integration with another system.

The information gathered by the retriever212may also be accessed by a user. For example, the retriever212is accessed by a command line interface (CLI)216. The CLI216can retrieve user data, resource usage data, resource cost data, or any other data requested by a user. In an example, the SOAP API214and/or the CLI216are accessed by an IT administrator.

FIGS. 3A-3Bare an abstraction of an example of the tables in the staging area. In an example, the staging area includes four tables in which are stored the state of the infrastructure. Each table monitors a type of resource. For example, table302monitors the server resource, table304monitors the IP resource, table306monitors the disk resource, and table308monitors the infrastructure resource. Tables302,304,306, and308each include date and hour entries310that identify a particular date and time that a resource change was made. Tables302,304,306, and308each also include cost listings312stating the cost of resource usage. Further, as resources are organized in a hierarchy, i.e. an infrastructure with a set of servers, tables302,304, and306each include references to the server314and the infrastructure316.

Table302lists all information relating to the server resource, including multiple server resources present in the computing system. Each server resource318is included in table302, which is updated with each server resource data change. The status316of each server resource is also included in table302.

Similar to table302, table304lists all information relating the IP resource. All IP resources320in the computing system and the corresponding changes to the IP resources are tracked by table304. In addition, table304lists information relating to the date and time310, the cost312, and the server314and infrastructure316.

As with tables302and304, table306lists all information relating to the disk resource. All disk resources322in the computing system and their corresponding changes are tracked by table306. Table306also lists information relating to date and time310, cost312, the server314, and the infrastructure316.

Table308lists all information relating to the infrastructure resource. All infrastructure resources324in the computing system are tracked by table308, as are all changes to the infrastructure resources. Table308also tracks date and time310, cost312, and status326.

The infrastructure as a whole can be recorded when a change occurs. The infrastructure may be saved in each table and can be used to perform usage and cost calculations. Each table can be interrelated to the remaining tables, such as by references within each table to the other resources. This relationship will be discussed in greater detail in regards toFIG. 4.

FIG. 4is an example of a database schema used by the chargeback system. The data can be recorded in a variety of tables, resulting in different levels of abstraction of the data. By including different levels, a variety of data queries can be performed. In an example, the database schema is a star schema design. The database schema can include a main table, such as a fact table. The schema can include multiple fact tables402,404,406,408, and/or410, each fact table tracking a resource type. For example, table402tracks IP resources, table404tracks infrastructure resources, table406summarizes all resources, table408tracks disk resources, and table410tracks server resources. The fact table may store compiled values, such as compiled usage and cost data. Each fact table402,404,408, and410stores usage and cost data for the resource the table tracks. The fact table can be associated with at least one additional table. For example, the fact table can be associated with a dimension table412,414,416,418, and/or420, a table storing information that does not change about a resource, i.e. information other than usage and cost data.

Each fact table can be associated with a single dimension table or multiple dimension tables. In addition, each dimension table may be associated with multiple fact tables. For example, each fact table402,404,406,408, and410is associated with calendar dimension table412. Calendar dimension table412stores full date information, including day, week, month, and year, allowing usage and cost data to reference the particular day on which they occur. Fact table402is additionally associated with dimension tables414and416. Dimension table414stores static information about all IP resources, such as the IP address and type of each IP resource. Dimension table416stores static information about all infrastructure resources, such as organization, billing code and owner. Fact table404is associated with calendar dimension table412, as well as dimension table416. Fact table406is also associated with calendar dimension table412and dimension table416. Fact table408is associated with calendar dimension table412, as well as dimension tables416and418. Dimension table418stores static information about all disk resources. Fact table410is associated with calendar dimension table412, as well as dimension tables416and420. Dimension table420stores static information about all server resources.

There can be several levels within each table. The levels within the tables allow for an amount of flexibility in data retrieval. For example, data can be searched for by different types of dimensions and in a variety of levels.

FIG. 5is an example of a relationship in the database schema. A fact table, such as server fact table502, can store data usage and cost information. The information stored in the fact table can be modified or added to. The server fact table502can be associated with at least one dimension table. For example, the server fact table502is associated with a calendar dimension table504in order to relate usage and cost data to a particular day and/or time. The server fact table502can also be associated with an infrastructure dimension table506. The infrastructure dimension table506can store information associated with the infrastructure that does not change. The server fact table502can additionally be associated with a server dimension table508. The server dimension table508can store information that does not change, which is associated with the server. Additional relationships, such as relationships arranged similarly to the relationship described here, may be present within a database schema and each relationship may be interrelated with each other. For example, each dimension table associated with a fact table is associated with another fact table.

FIG. 6is a process flow diagram illustrating a chargeback method. The chargeback method600can begin at block602with recording of daily resource change data. In an example, the resource change data are daily recorded changes to computing resource status, such as changes to computing resource status within a cloud computing system. In an example, the resource change data is a recording of the state of the infrastructure at a moment of change. In an example, the recording is triggered by the change in resource status. In an example, the resource change data is stored in a staging area before being accessed by a chargeback system, such as chargeback system114. The data may be received in the chargeback system when the chargeback system accesses the staging area. In another example, the staging area notifies the chargeback system of data awaiting analysis. In a further example, the resource change data is transferred to the chargeback system at a predetermined time each day. The predetermined time can be set by a user, such as an IT administrator.

At block604, uniformization of the resource change data is performed. Uniformization can include removing inconsistencies within the resource change data. In another example, uniformization includes resolving conflicts with the resource change data.

At block606, the resource change data is converted to usage and cost data. The resource change data can be converted by performing usage calculations and cost calculations using the resource change data. Usage refers to the length of time a particular resource was in use. For example, usage may refer to how long a server was up or how long a disk or network was in use. Policy costs, the set cost for use of each resource for a specified period of time, can be stored within the staging area and can be accessed or transferred along with the resource change data. The cost can be based on the usage. In an example, the usage is calculated, then the cost of the calculated usage is determined. The data can be converted daily, such as at a predetermined time. The predetermined time can be selected by a user, such as an IT administrator.

At block608the usage and cost data can be loaded in a chargeback database. For example, a loader208loads the usage and cost data in chargeback database210. The chargeback database can be a warehouse-like database. The data within the chargeback database is stored in tables. The tables may be interrelated in a database schema to facilitate data retrieval. In an example, the database schema is a star schema design, such as schema design400. The database can be pre-defined in terms of IT charged resources. For example, the database is pre-defined in terms of network, servers, disks, and infrastructure services. In an example, if a new resource is to be monitored, an additional table is added to the chargeback database.

At block610, daily reports on resource usage and cost are compiled. Logic, such as retriever212, gathers usage and cost data from the chargeback database to compile the daily reports. The daily reports can include consolidated data for all infrastructure services managed by the infrastructure management system. The daily reports may be organized in a particular manner, such as a manner specified by a user. For example, the daily reports are organize and filtered by different attributes, such as organization, billing code, owner, and service name. The daily reports may be accessed by a user or another application. The daily reports can be used to charge users for resource usage. The daily reports can also be used to internally judge resource usage. For example, the daily reports are used to evaluate trends in resource usage and to identify high areas of resource usage. In addition, the daily compilation of resource usage and cost allows the chargeback data for a specified period of time to be retrieved very quickly. For example, the chargeback data for an entire year can be extracted within minutes.

The chargeback system114can be embodied in code stored on tangible, non-transitory, computer-readable storage medium. The code is executed by a processor. The code causes the processor to receive resource change data, convert the resource change data to usage and cost data, and store the usage and cost data in a chargeback database. The resource change data includes recordings of a state of infrastructure taken at particular moments in time, such as at the time of a change. The resource change data is converted to usage and cost data via usage calculations and cost calculations. The resource cost depends upon the resource usage. The usage and cost data may be stored in tables within the chargeback database. The tables each track an individual resource and the tables may be interrelated in a database schema, such as a star schema design, to facilitate data retrieval. In an example, the resource monitored by each table is one of server, IP, disk, and infrastructure. The resource usage and cost data can be converted and compiled daily and reported to a user.

While the present techniques may be susceptible to various modifications and alternative forms, the exemplary examples discussed above have been shown only by way of example. It is to be understood that the technique is not intended to be limited to the particular examples disclosed herein. Indeed, the present techniques include all alternatives, modifications, and equivalents falling within the true spirit and scope of the appended claims.