Dynamic system workload placement in cloud infrastructure - Patents.com

JP2024544646A5Pending Publication Date: 2025-09-05ORACLE INT CORP
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
JP2024532511
Authority / Receiving Office
JP · JP
Patent Type
Applications
Current Assignee / Owner
Priority Date
2021-11-30
Filing Date
2022-11-29
Publication Date
2025-09-05

AI Technical Summary

Technical Problem

Traditional workload placement methods in cloud infrastructure are cumbersome, prone to errors, inefficient, and lack automation, particularly in multi-server systems, leading to inaccuracies and inefficiencies due to manual spreadsheet calculations, complex benchmark conversions, and the inability to handle high availability systems like clustering.

Method used

A system and method for dynamic workload placement using a migration infrastructure that analyzes source and target nodes, creates migration plans, and deploys workloads efficiently, incorporating bin packing algorithms to handle clustered and pluggable environments, with automated rollback and elasticization to optimize resource use.

Benefits of technology

Reduces errors, increases efficiency, and speeds up workload placement from days to hours by automating the process, ensuring high availability and reducing waste through intelligent resource allocation and elastic scaling.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure 00000000_0000_ABST
    Figure 00000000_0000_ABST
Patent Text Reader

Abstract

The system, method, and machine-readable medium can place a workload of a source system in a migration of data and applications from the source system to a target system. Data regarding a first number of source nodes and a second number of target nodes can be received and analyzed. A migration plan can be created that specifies the placement of the workload from the source system to the target system. The placement can include packing the pluggable environment or the clustered environment. Packing the pluggable environment or the clustered environment can include placing the workload from the source nodes to the target nodes if the second number of target nodes is greater than the first number of source nodes, and not placing the workload from the source nodes to the target nodes if the second number of target nodes is less than the first number of source nodes.
Need to check novelty before this filing date? Find Prior Art

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application is a non-provisional application of and claims priority to U.S. Provisional Patent Application No. 63 / 284,528, filed November 30, 2021, and is hereby incorporated by reference for all purposes.

[0002] Technical Field The present disclosure relates generally to systems and methods for system workload placement, and more particularly, to systems and methods for dynamic system workload placement in a cloud infrastructure. [Background technology]

[0003] background Capacity planning is an essential activity in the procurement and daily operation of any multi-server computer system. Workload placement is a well-known problem, and there are several solutions that help address the capacity planning problem of knowing where, when, and how much resources are needed (resources consumed) to place workloads of various shapes. Bin-packing algorithms can be widely used to address the workload placement problem.

[0004] However, traditional workload placement is fraught with many issues and challenges. For example, inaccuracies and inefficiencies can occur due to manual construction of spreadsheets that are cumbersome and cannot avoid calculation errors, chipset conversions using benchmarks (e.g., SPECInt, M-Values ​​benchmarks) that require complex spreadsheet conversions, complex spreadsheets that can only be understood by designers, low automation levels that require days / weeks to complete the design / plan when algorithms can place workloads by querying repositories, bespoke spreadsheets that are not standardized, insecure because the deployment specifications and designs are not stored in a secure and auditable cloud repository, etc. Such issues can affect different types of services, such as consolidated services where the system is using a multi-tenant architecture to merge or reduce server sprawl, managed cloud services where workloads are already deployed or scoped, and any cloud offering where workloads are consolidated. Furthermore, current bin-packing algorithms do not consider systems that employ high availability (HA) such as clustering, and often treat workloads individually as opposed to workloads that are composed of "sibling" workloads.

[0005] Thus, what is needed is a system and method that addresses complexity, improves efficiency, reduces errors, increases speed, and otherwise improves database or application workload placement. These and other needs are addressed by the present disclosure. Summary of the Invention [Means for solving the problem]

[0006] Quick Overview FIELD OF THE DISCLOSURE Embodiments of the present disclosure relate generally to systems and methods for system workload placement, and more particularly, to systems and methods for dynamic system workload placement in a cloud infrastructure.

[0007] In one aspect, a system is disclosed for placing workloads of one or more source systems in a data and / or application migration from the one or more source systems to the one or more target systems. The system may comprise one or more processing devices and a memory communicatively coupled to the one or more processing devices and readable by the one or more processing devices, the memory including processor-readable instructions that, when executed by the one or more processing devices, cause the one or more processing devices to perform operations that may include one or a combination of the following: Data regarding a first number of source nodes and a second number of target nodes may be received. A migration infrastructure may be located remotely from the first number of source nodes and may be configured to provide migration services. Data regarding the first number of source nodes and the second number of target nodes may be analyzed. A migration plan may be created that specifies the placement of workloads from the one or more source systems to the one or more target systems. The placement may include packing a pluggable or clustered environment. Packing the pluggable or clustered environment may include placing the workload from the source node to the target node if the second number of target nodes is greater than the first number of source nodes, and not placing the workload from the source node on the target node if the second number of target nodes is less than the first number of source nodes, and performing one or more rollback operations. A migration according to the migration plan may be performed. The migration may include placing the workload from the source node to the target node if the second number of target nodes is greater than the first number of source nodes.

[0008] In another aspect, a method is disclosed for placing a workload of one or more source systems in a data and / or application migration from the one or more source systems to the one or more target systems. The method may include one or a combination of the following: A migration infrastructure may receive data regarding a first number of source nodes and a second number of target nodes. The migration infrastructure may be located remotely from the first number of source nodes and may be configured to provide migration services. The migration infrastructure may analyze the data regarding the first number of source nodes and the second number of target nodes. The migration infrastructure may create a migration plan that specifies the placement of the workload from the one or more source systems to the one or more target systems. The placement may include packing a pluggable environment or a clustered environment. Packing the pluggable or clustered environment may include placing the workload from the source node to the target node if the second number of target nodes is greater than the first number of source nodes, and if the second number of target nodes is less than the first number of source nodes, the workload from the source node is not placed on the target node and one or more rollback operations may be performed. The migration infrastructure may perform migration according to the migration plan. The migration may include placing the workload from the source node to the target node if the second number of target nodes is greater than the first number of source nodes.

[0009] In yet another aspect, one or more non-transitory machine-readable media are disclosed having machine-readable instructions that, when executed by one or more processing devices, cause the one or more processing devices to perform operations that may include one or a combination of the following: Data regarding a first number of source nodes and a second number of target nodes may be received. A migration infrastructure may be located remotely from the first number of source nodes and configured to provide migration services. Data regarding the first number of source nodes and the second number of target nodes may be analyzed. A migration plan may be created that specifies placement of workloads from the one or more source systems to the one or more target systems. The placement may include packing the pluggable environment or the clustered environment. Packing the pluggable environment or the clustered environment may include placing the workload from the source nodes to the target nodes if the second number of target nodes is greater than the first number of source nodes, and if the second number of target nodes is less than the first number of source nodes, the workload from the source nodes is not placed on the target nodes and performing one or more rollback operations. A migration according to the migration plan may be performed. The migration may include distributing a workload from a source node to a target node when a second number of the target nodes is greater than the first number of the source nodes.

[0010] In various embodiments, the one or more target systems can correspond to a cloud infrastructure, and the placement of the workload can correspond to placing the workload in the cloud infrastructure. In various embodiments, the operations and methods can be scalable such that the placement of the workload can be based, at least in part, on one or more dimensions along which the vector can be augmented. In various embodiments, the vector can include a metric dimension corresponding to one or more of an input / output (IO) metric, a central processing unit (CPU) metric, and / or a memory metric. In various embodiments, the vector can be a function of time. In various embodiments, an integrated time series data signal corresponding to the workload can be obtained. The integrated time series data signal can be analyzed, and the integrated time series data signal can be compared to a target bin total to determine whether further efficiencies can be gained through elasticization to reduce waste. In various embodiments, the target bin can be elastic. The target bin can correspond to a node of a cloud configuration. In various embodiments, the migration service can be cloud-based.

[0011] Further scope of applicability of the present disclosure will become apparent from the detailed description provided hereinafter. It should be understood that the detailed description and specific examples, while indicating various embodiments, are intended for purposes of illustration only and are not intended to necessarily limit the scope of the present disclosure.

[0012] A further understanding of the nature and advantages of embodiments according to the present disclosure may be realized by reference to the remaining portions of the specification in conjunction with the accompanying figures, in which: [Brief description of the drawings]

[0013] [Figure 1] 1 is a simplified diagram of a distributed system consistent with embodiments disclosed herein; [Diagram 2] FIG. 1 is a simplified block diagram of one or more components of a system environment in which services provided by one or more components of the system can be provided as cloud services in accordance with embodiments disclosed by the present disclosure. [Diagram 3] FIG. 1 illustrates an exemplary computer system consistent with embodiments disclosed herein. [Diagram 5] 1A-1C illustrate examples of various configurations and workload complexities that the system can provide in accordance with embodiments disclosed herein. [Figure 6] FIG. 1 illustrates clusters participating and managed together to act as one system according to embodiments disclosed herein. [Figure 7] FIG. 13 illustrates aspects of CPU utilization in accordance with embodiments disclosed herein. [Figure 8] FIG. 2 illustrates an example aspect of RAC workload complexity addressed by disclosed embodiments of a system in accordance with disclosed embodiments of the present disclosure. [Figure 9] FIG. 1 illustrates aspects of a pluggable database having a multi-tenant architecture in accordance with embodiments disclosed herein. [Figure 10] FIG. 13 illustrates aspects of vectors according to embodiments disclosed herein. [Figure 11] FIG. 1 illustrates aspects of node resource capacity in accordance with embodiments disclosed herein. [Figure 12] FIG. 2 illustrates aspects of workload resource demands in accordance with embodiments disclosed herein. [Figure 13] FIG. 13 illustrates another example of how a system may determine aspects of a workload, consistent with embodiments disclosed herein. [Figure 14] FIG. 2 illustrates an example of how a system may analyze an aggregated temporal workload taking into account data anomalies, consistent with embodiments disclosed herein. [Figure 15] FIG. 1 illustrates an example method for facilitating migration of data and / or applications from one or more source systems to one or more target systems, consistent with embodiments disclosed herein. [Figure 16A] 4 illustrates several aspects of an example of workload consolidation and bin packing into target bins by first fit, consistent with embodiments disclosed herein; FIG. [Figure 16B] 4 illustrates several aspects of an example of bin packing and consolidation of workloads into target bins by optimal fit, consistent with embodiments disclosed herein; FIG.

[0014] In the accompanying figures, similar components and / or features shall have the same reference numerals. Furthermore, various components of the same type may be identified by a reference numeral followed by a dash and a second numeral that identifies the similar component. When only a first numeral is used in this specification, the description is applicable to any one of the similar components having the same first numeral, regardless of the second numeral. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0015] Detailed Description The following description merely provides preferred exemplary embodiments and is not intended to limit the scope, applicability, or configuration of the present disclosure. Rather, the following description of preferred exemplary embodiments provides those skilled in the art with an enabling description for implementing preferred exemplary embodiments of the present disclosure. It should be understood that various changes can be made in the function and arrangement of elements without departing from the spirit and scope of the present disclosure as set forth in the appended claims.

[0016] Various embodiments according to the present disclosure may provide a system, method, and non-transitory medium for dynamic database workload placement in a cloud infrastructure. Various embodiments may work for any workload consuming resources of a certain shape creating a vector. The vector may be any shape metric, such as input / output (IO) metrics (e.g., input / output operations per second (IOPS)), memory metrics (e.g., memory utilization), central processing unit (CPU) (e.g., CPU utilization), etc., including metrics that apply to applications in the PaaS, SaaS, and DBaaS tiers of cloud computing. Various embodiments may also include on-premise architectures such as N-Tier.

[0017] Various embodiments will now be disclosed in more detail with reference to the accompanying figures, beginning with FIG. 1. FIG. 1 illustrates a simplified diagram of a distributed system 100 for implementing the disclosed embodiments in accordance with the present disclosure. The selection and / or arrangement of components illustrated in FIG. 1 is provided merely as an example and is not intended to be limiting. In the illustrated embodiment, the distributed system 100 includes one or more client computing devices 102, 104, 106, and 108 configured to execute and operate client applications, such as web browsers, proprietary clients (e.g., Oracle Forms), etc., via one or more networks 110. A server 112 can be communicatively coupled to the remote client computing devices 102, 104, 106, and 108 via the network 110.

[0018] In various embodiments, the server 112 may be adapted to execute one or more services or software applications provided by one or more of the system's components. In some embodiments, these services may be provided to users of the client computing devices 102, 104, 106, and / or 108 as web-based or cloud services or under a Software as a Service (SaaS) model. Users operating the client computing devices 102, 104, 106, and / or 108 can then utilize one or more client applications that interact with the server 112 to utilize the services provided by these components.

[0019] In the illustrated configuration, the software components 118, 120, and 122 of the system 100 are shown as being implemented on the server 112. In other embodiments, one or more of the components of the system 100 and / or the services provided by these components may be implemented by one or more of the client computing devices 102, 104, 106, and / or 108. A user operating a client computing device may then utilize one or more client applications to use the services provided by these components. These components may be implemented in hardware, firmware, software, or a combination thereof. It should be understood that a variety of different system configurations are possible that may differ from the distributed system 100. Thus, the illustrated embodiment is one example of a distributed system for implementing a system embodiment and is not intended to be limiting.

[0020] The client computing devices 102, 104, 106, and / or 108 may be portable handheld devices (e.g., iPhone, mobile phone, iPad, computing tablet, personal digital assistant (PDA)) or wearable devices (e.g., Google Glass head mounted display) running software such as Microsoft Windows Mobile and / or various mobile operating systems such as iOS, Windows Phone, Android, BlackBerry, Palm OS, and capable of Internet, e-mail, short message service (SMS), Blackberry, or other communication protocols. The client computing devices may be general purpose personal computers, including, by way of example, personal computers and / or laptop computers running various versions of Microsoft Windows, Apple Macintosh, and / or Linux operating systems. The client computing devices may be workstation computers running any of a variety of commercially available UNIX or UNIX-like operating systems, including, but not limited to, various GNU / Linux operating systems such as Google Chrome OS. Alternatively, or in addition, client computing devices 102, 104, 106, and 108 may be any other electronic device, such as a thin-client computer, an Internet-enabled gaming system (e.g., a Microsoft Xbox® game console with or without a Kinect® gesture input device), and / or a personal messaging device, capable of communicating over network 110.

[0021] Although the exemplary distributed system 100 is shown with four client computing devices, any number of client computing devices may be supported. Other devices, such as devices with sensors, may interact with the server 112.

[0022] Network 110 in distributed system 100 may be any type of network familiar to those skilled in the art capable of supporting data communications using any of a variety of commercially available protocols, including, but not limited to, TCP / IP (Transmission Control Protocol / Internet Protocol), SNA (Systems Network Architecture), IPX (Internet Packet Exchange), AppleTalk, and the like. By way of example only, network 110 may be a local area network (LAN), such as one based on Ethernet, token ring, and the like. Network 110 may be a wide area network and the Internet. Network 110 may include virtual networks, including, but not limited to, a virtual private network (VPN), an intranet, an extranet, a public switched telephone network (PSTN), an infrared network, a wireless network (e.g., a network operating according to any of the Institute of Electrical and Electronics Engineers (IEEE) 802.11 protocol suite, Bluetooth, and / or other wireless protocols), and / or any combination of these and / or other networks.

[0023] Servers 112 may comprise one or more general purpose computers, dedicated server computers (including, by way of example, PC (personal computer) servers, UNIX servers, mid-range servers, mainframe computers, rack-mounted servers, etc.), server farms, server clusters, or any other suitable arrangement and / or combination. In various embodiments, servers 112 may be adapted to execute one or more services or software applications described in the preceding disclosure. For example, servers 112 may correspond to servers for executing the processes described above in accordance with embodiments of the present disclosure.

[0024] Server 112 may run an operating system, including any of those mentioned above, as well as any commercially available server operating system. Server 112 may also run any of a variety of additional server applications and / or mid-tier applications, including a HyperText Transfer Protocol (HTTP) server, a File Transfer Protocol (FTP) server, a Common Gateway Interface (CGI) server, a JAVA server, a database server, etc. Exemplary database servers include, but are not limited to, those commercially available from Oracle, Microsoft, Sybase, IBM (International Business Machines), etc.

[0025] In some embodiments, the server 112 may include one or more applications for analyzing and consolidating data feeds and / or event updates received from users of the client computing devices 102, 104, 106, and 108. By way of example, the data feeds and / or event updates may include, but are not limited to, Twitter® feeds, Facebook® updates, or real-time updates received from one or more third party information sources and continuous data streams, including real-time events associated with sensor data applications, financial tickers, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automobile traffic monitoring, and the like. The server 112 may also include one or more applications for displaying the data feeds and / or real-time events via one or more display devices of the client computing devices 102, 104, 106, and 108.

[0026] Distributed system 100 may also include one or more databases 114. Databases 114 may reside in a variety of locations. By way of example, one or more of databases 114 may reside on a non-transitory storage medium local to (and / or residing within) server 112. Alternatively, databases 114 may be remote from server 112 and communicate with server 112 via a network-based or dedicated connection. In various embodiments, databases 114 may reside on a storage area network (SAN), network attached storage (NAS), or cloud storage facility, such as block, file, or object storage. Similarly, any files necessary to perform functions attributed to server 112 may be stored locally on server 112 and / or remotely, as appropriate. In one set of embodiments, databases 114 may include relational databases adapted to store, update, and retrieve data in response to SQL-formatted commands, such as those provided by Oracle.

[0027] 2 is a simplified block diagram of one or more components of a system environment 200 that can provide services provided by one or more components of the system as cloud services, in accordance with some embodiments of the present disclosure. In the illustrated embodiment, system environment 200 includes one or more client computing devices 204, 206, and 208 that a user can use to interact with cloud infrastructure system 130-1 that provides cloud services. The client computing devices can be configured to run a client application, such as a web browser, a proprietary client application (e.g., Oracle Forms), or some other application that a user of the client computing device can use to interact with cloud infrastructure system 130-1 to use services provided by cloud infrastructure system 130-1.

[0028] It should be understood that the illustrated cloud infrastructure system 130-1 may have components other than those shown. Additionally, the illustrated embodiment is merely one example of a cloud infrastructure system that may incorporate embodiments of the present invention. In other embodiments, cloud infrastructure system 130-1 may have more or fewer components than those shown, may combine two or more components, or may have a different configuration or arrangement of components.

[0029] Client computing devices 204, 206, and 208 may be devices similar to those described above for 102, 104, 106, and 108. Although the exemplary system environment 200 is shown with three client computing devices, any number of client computing devices may be supported. Other devices, such as devices having sensors, may interact with cloud infrastructure system 130-1.

[0030] Network 210 may facilitate communication and data exchange between clients 204, 206, and 208 and cloud infrastructure system 130-1. Each network may be any type of network familiar to those skilled in the art capable of supporting data communications using any of a variety of commercially available protocols, including those described above for network 110. Cloud infrastructure system 130-1 may include one or more computers and / or servers, which may include those described above for server 112.

[0031] In some embodiments, the services provided by the cloud infrastructure system may include a host of services made available on demand to users of the cloud infrastructure system, such as online data storage and backup solutions, web-based email services, hosted office suites and document collaboration services, database processing, managed technical support services, etc. The services provided by the cloud infrastructure system may be dynamically scaled to meet the needs of its users. A particular instance of a service provided by the cloud infrastructure system is referred to herein as a "service instance." In general, any service made available to users from a cloud service provider's system over a communications network such as the Internet is referred to as a "cloud service." Typically, in a public cloud environment, the servers and systems that make up the cloud service provider's system are distinct from the client's own on-premise servers and systems. For example, the cloud service provider's system may host an application that users can order and use on demand over a communications network such as the Internet.

[0032] In some examples, services in a cloud infrastructure of a computer network may include protected computer network access to storage, hosted databases, hosted web servers, software applications, or other services as provided to users by a cloud vendor or as otherwise known in the art. For example, a service may include password-protected access to remote storage on the cloud via the Internet. As another example, a service may include a web-services-based hosted relational database and scripting language middleware engine for private use by networked developers. As another example, a service may include access to an email software application hosted on a cloud vendor's website.

[0033] In some embodiments, cloud infrastructure system 130-1 may include a suite of application, middleware, and database service offerings that are delivered to clients in a self-service, subscription-based, elastically scalable, reliable, highly available, and secure manner. One example of such a cloud infrastructure system is the Oracle Public Cloud offered by the assignee of the present application.

[0034] In various embodiments, cloud infrastructure system 130-1 can be adapted to automatically provision, manage, and track client subscriptions to services provided by cloud infrastructure system 130-1. Cloud infrastructure system 130-1 can provide cloud services through different deployment models. For example, services may be provided under a public cloud model, where an organization that sells cloud services (e.g., owned by Oracle) owns cloud infrastructure system 130-1 and makes the services available to the general public or to companies in different industries. As another example, services may be provided under a private cloud model, where cloud infrastructure system 130-1 is operated solely for a single organization and may provide services to one or more entities within that organization. Cloud services may be provided under a community cloud model, where cloud infrastructure system 130-1 and the services provided by cloud infrastructure system 130-1 are shared by several organizations within an associated community. Cloud services may be provided under a hybrid cloud model, which is a combination of two or more different models.

[0035] In some embodiments, the services provided by cloud infrastructure system 130-1 may include one or more services provided under the Software as a Service (SaaS) category, the Platform as a Service (PaaS) category, the Infrastructure as a Service (IaaS) category, or other categories of services, including hybrid services. A client may order one or more services provided by cloud infrastructure system 130-1 via a subscription order. Cloud infrastructure system 130-1 then performs processing to provide the services of the client's subscription order.

[0036] In some embodiments, the services provided by the cloud infrastructure system 130-1 may include, but are not limited to, application services, platform services, and infrastructure services. In some examples, application services may be provided by the cloud infrastructure system via a SaaS platform. The SaaS platform may be configured to provide cloud services that fall under the SaaS category. For example, the SaaS platform may provide the ability to build and deliver a suite of applications on demand on an integrated development and deployment platform. The SaaS platform may manage and control the underlying software and infrastructure for delivering the SaaS services. By utilizing the services provided by the SaaS platform, clients may utilize applications that run on the cloud infrastructure system. Clients may obtain application services without having to purchase separate licenses and support. A variety of different SaaS services may be provided. Examples include, but are not limited to, services that provide solutions for sales performance management, enterprise integration, and business flexibility for large organizations.

[0037] In some embodiments, platform services can be provided by the cloud infrastructure system through a PaaS platform. The PaaS platform can be configured to provide cloud services that fall under the PaaS category. Examples of platform services can include, but are not limited to, services that allow organizations (such as Oracle) to consolidate existing applications onto a shared common architecture, and the ability to build new applications that leverage the shared services provided by the platform. The PaaS platform can manage and control the underlying software and infrastructure for providing the PaaS services. Clients can obtain the PaaS services provided by the cloud infrastructure system without the need to purchase separate licenses and support. Examples of platform services can include, but are not limited to, Oracle Java Cloud Service (JCS), Oracle Database Cloud Service (DBCS), etc.

[0038] By utilizing the services provided by the PaaS platform, clients can adopt programming languages ​​and tools supported by the cloud infrastructure system and also control the deployed services. In some embodiments, the platform services provided by the cloud infrastructure system can include database cloud services, middleware cloud services (e.g., Oracle Fusion Middleware services), and Java cloud services. In one embodiment, the database cloud services can support a shared services deployment model that allows organizations to pool database resources and provide database as a service to clients in the form of a database cloud. The middleware cloud services can provide a platform for clients to develop and deploy various business applications, and the Java cloud services can provide a platform for clients to deploy Java applications in the cloud infrastructure system.

[0039] In a cloud infrastructure system, an IaaS platform may provide a variety of different infrastructure services that facilitate management and control of underlying computing resources such as storage, network, and other fundamental computing resources for clients that utilize the services provided by the SaaS and PaaS platforms.

[0040] In some embodiments, cloud infrastructure system 130-1 may also include infrastructure resources 230 for providing resources used to provide various services to clients of the cloud infrastructure system. In one embodiment, infrastructure resources 230 may include a pre-integrated and optimized combination of hardware, such as servers, storage, and networking resources, for running the services provided by the PaaS and SaaS platforms. In some embodiments, resources in cloud infrastructure system 130-1 may be shared by multiple users and dynamically reallocated per request. Furthermore, resources may be allocated to users in different time zones. For example, cloud infrastructure system 230 may allow a first set of users in a first time zone to utilize resources of the cloud infrastructure system for a specified number of hours and then reallocate the same resources to another set of users in a different time zone, thereby maximizing resource utilization.

[0041] In some embodiments, multiple internal shared services 232 may be provided that are shared by different components or modules of the cloud infrastructure system 130-1 as well as by services provided by the cloud infrastructure system 130-1. These internal shared services may include, but are not limited to, security and identity services, integration services, enterprise repository services, enterprise manager services, virus scanning and whitelist services, high availability, backup and recovery services, services for enabling cloud support, email services, notification services, file transfer services, and the like. In some embodiments, the cloud infrastructure system 130-1 may provide comprehensive management of cloud services (e.g., SaaS, PaaS, and IaaS services) in the cloud infrastructure system. In one embodiment, cloud management functions may include functions such as provisioning, managing, and tracking client subscriptions received by the cloud infrastructure system 130-1.

[0042] In some embodiments, as shown, the cloud management functionality may be provided by one or more modules, such as an order management module 220, an order orchestration module 222, an order provisioning module 224, an order management and monitoring module 226, and an identity management module 228. These modules may include or be provided using one or more computers and / or servers, which may be general purpose computers, dedicated server computers, server farms, server clusters, or any other suitable arrangement and / or combination.

[0043] In an example operation 234, a client using a client device, such as client device 204, 206, or 208, may interact with cloud infrastructure system 130-1 by requesting one or more services offered by cloud infrastructure system 130-1 and placing an order for a subscription to one or more services offered by cloud infrastructure system 130-1. In some embodiments, the client may access cloud user interfaces (UIs), cloud UI 212, cloud UI 214, and / or cloud UI 216, and place the subscription order via these UIs. Order information received by cloud infrastructure system 130-1 in response to the client placing the order may include information identifying the client and one or more services offered by cloud infrastructure system 130-1 to which the client intends to subscribe.

[0044] After an order is placed by a client, order information is received via cloud UI 212, 214, and / or 216. At operation 236, the order is stored in order database 218, which may be one of several databases operated by cloud infrastructure system 218 along with other system elements. At operation 238, the order information is forwarded to order management module 220. In some cases, order management module 220 may be configured to perform billing and accounting functions related to the order, such as validating the order and registering the order after validation.

[0045] At operation 240, information about the order is communicated to the order orchestration module 222. The order orchestration module 222 can utilize the order information to orchestrate the provisioning of services and resources for the order placed by the client. In some cases, the order orchestration module 222 may orchestrate the provisioning of resources to support subscribed services that use the services of the order provisioning module 224.

[0046] In some embodiments, the order orchestration module 222 enables management of business processes associated with each order and applies business logic to determine whether the order should proceed to provisioning. In operation 242, upon receiving an order for a new subscription, the order orchestration module 222 sends a request to the order provisioning module 224 to allocate and configure resources required to fulfill the subscription order. The order provisioning module 224 enables allocation of resources for the services ordered by the client. The order provisioning module 224 provides a level of abstraction between the cloud services provided by the cloud infrastructure system 130-1 and the physical implementation layer used to provision resources to provide the requested services. Thus, the order orchestration module 222 can be insulated from implementation details such as whether the services and resources are actually provisioned on the fly or whether they are pre-provisioned and allocated / allocated only upon request.

[0047] In operation 244, once the services and resources are provisioned, a notification of the provided services may be sent by the order provisioning module 224 of the cloud infrastructure system 130-1 to the clients at the client devices 204, 206, and / or 208. In operation 246, the clients' subscription orders may be managed and tracked by the order management and monitoring module 226. In some cases, the order management and monitoring module 226 may be configured to collect usage statistics for the services in the subscription orders, such as the amount of storage used, the amount of data transferred, the number of users, and the amount of system uptime and system downtime.

[0048] In some embodiments, cloud infrastructure system 130-1 may include identity management module 228. Identity management module 228 may be configured to provide identity services, such as access management and authorization services in cloud infrastructure system 130-1. In some embodiments, identity management module 228 may manage information about clients that wish to utilize services provided by cloud infrastructure system 130-1. Such information may include information authenticating the identities of such clients and information describing which operations those clients are authorized to perform with respect to various system resources (e.g., files, directories, applications, communication ports, memory segments, etc.). Identity management module 228 may also include management of descriptive information about each client and how and who may access and modify that descriptive information.

[0049] 3 illustrates an exemplary computer system 130 in which various embodiments of the present invention may be implemented. The system 130 may be used to implement any of the computer systems described herein. As shown, the computer system 130 includes a processing unit 304 that communicates with a number of peripheral subsystems via a bus subsystem 302. These peripheral subsystems may include a processing acceleration unit 306, an I / O subsystem 308, a storage subsystem 318, and a communication subsystem 324. The storage subsystem 318 includes a tangible computer-readable storage medium 322 and a system memory 310.

[0050] Bus subsystem 302 provides a mechanism for allowing the various components and subsystems of computer system 130 to communicate with each other as intended. Although bus subsystem 302 is shown diagrammatically as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses. Bus subsystem 302 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. For example, such architectures may include an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Enhanced ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect (PCI) bus, which may be implemented as a Mezzanine bus manufactured in accordance with the IEEE P1386.1 standard.

[0051] The processing unit 304, which may be implemented as one or more integrated circuits (e.g., conventional microprocessors or microcontrollers), controls the operation of the computer system 130. The processing unit 304 may include one or more processors. These processors may include single-core or multi-core processors. In some embodiments, the processing unit 304 may be implemented as one or more independent processing units 332 and / or 334 with a single-core or multi-core processor included in each processing unit. In other embodiments, the processing unit 304 may be implemented as a quad-core processing unit formed by integrating two dual-core processors into a single chip.

[0052] In various embodiments, the processing unit 304 may execute various programs in response to program code and may maintain multiple simultaneously executing programs or processes. At any given time, some or all of the program code to be executed may reside in the processor 304 and / or the storage subsystem 318. Through suitable programming, the processor 304 may provide various functions as described above. The computer system 130 may further include a processing acceleration unit 306, which may include a digital signal processor (DSP), a special purpose processor, etc. In some embodiments, the processing acceleration unit 306 may include or work in conjunction with an acceleration engine as disclosed herein to enhance the functionality of the computer system.

[0053] The I / O subsystem 308 may include user interface input devices and user interface output devices. User interface input devices may include a keyboard, a pointing device such as a mouse or trackball, a touchpad or touch screen integrated into a display, a scroll wheel, a click wheel, a dial, a button, a database, a keypad, a voice input device with a voice command recognition system, a microphone, and other types of input devices. User interface input devices may include motion sensing and / or gesture recognition devices such as a Microsoft Kinect® motion sensor that allows a user to control and interact with an input device such as a Microsoft Xbox® 360 game controller through a natural user interface using gestures and spoken commands. User interface input devices may also include eye gesture recognition devices such as a Google Glass® blink detector that detects eye activity from a user (e.g., "blinking" during picture taking and / or menu selection) and translates eye gestures as input to an input device (e.g., Google Glass®). Additionally, the user interface input devices may include a voice recognition sensing device that allows a user to interact with a voice recognition system (e.g., the Siri® Navigator) via voice commands.

[0054] User interface input devices may also include, but are not limited to, three-dimensional (3D) mice, joysticks or pointing sticks, game pads and graphic tablets, as well as audio / visual devices such as speakers, digital cameras, digital video cameras, portable media players, webcams, image scanners, fingerprint scanners, barcode readers 3D scanners, 3D printers, laser distance measuring devices, and eye tracking devices. Additionally, user interface input devices may include medical image input devices, such as, for example, computed tomography, magnetic resonance imaging, positron emission tomography, medical ultrasound, etc. User interface input devices may also include audio input devices, such as, for example, MIDI keyboards, digital musical instruments, etc.

[0055] User interface output devices may include a display subsystem, indicator lights, or non-visual displays such as audio output devices, and the like. The display subsystem may be a flat panel device such as one using a cathode ray tube (CRT), liquid crystal display (LCD) or plasma display, a projection device, a touch screen, and the like. In general, use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from computer system 130 to a user or to another computer. For example, user interface output devices may include a variety of display devices that visually convey text, graphics, and audio / video information, such as, but not limited to, monitors, printers, speakers, headphones, automobile navigation systems, plotters, audio output devices, and modems.

[0056] The computer system 130 may include a storage subsystem 318, which includes software elements that are shown currently residing in the system memory 310. The system memory 310 may store program instructions that are loadable into and executable by the processing unit 304, as well as data that is generated during the execution of these programs. Depending on the configuration and type of computer system 130, the system memory 310 may be volatile (such as random access memory (RAM)) and / or non-volatile (such as read-only memory (ROM), flash memory, etc.). RAM typically includes data and / or program modules that are immediately accessible to and / or currently being operated and executed by the processing unit 304. In some implementations, the system memory 310 may include a number of different types of memory, such as static random access memory (SRAM) or dynamic random access memory (DRAM). In some implementations, the ROM may store a basic input / output system (BIOS), which typically includes the basic routines that help to transfer information between elements within the computer system 130, such as during start-up. By way of example and not limitation, system memory 310 also illustrates application programs 312, which may include client applications, a web browser, a mid-tier application, a relational database management system (RDBMS), and the like; program data 314; and an operating system 316.By way of example, operating system 316 may include various versions of Microsoft Windows®, Apple Macintosh®, and / or Linux operating systems, various commercially available UNIX® or UNIX-like operating systems (including, but not limited to, various GNU / Linux operating systems, Google Chrome® OS, etc.), and / or mobile operating systems such as iOS, Windows® Phone, Android® OS, BlackBerry® 10 OS, and Palm® OS operating systems.

[0057] The storage subsystem 318 may also provide a tangible, computer-readable storage medium for storing the basic programming and data constructs that provide the functionality of some embodiments. The storage subsystem 318 may store software (programs, code modules, instructions) that, when executed by the processor, provide the functionality described above. These software modules or instructions may be executed by the processing unit 304. The storage subsystem 318 may also provide a repository for storing data used in accordance with the present invention.

[0058] Storage subsystem 130 may also include a computer-readable storage medium reader 320 that may be further connected to a computer-readable storage medium 322. Optionally in combination with system memory 310, computer-readable storage medium 322 may collectively represent remote, local, fixed, and / or removable storage devices plus storage media for temporarily and / or more permanently storing, storing, transmitting, and retrieving computer-readable information.

[0059] The computer readable storage medium 322 containing the code, or portions of the code, may include any suitable medium known or used in the art, including, but not limited to, storage media and communication media, such as volatile and non-volatile, removable and non-removable media, implemented in any manner or technology for storing and / or transmitting information. This may include tangible computer readable storage media, such as RAM, ROM, Electronically Erasable Programmable ROM (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disk (DVD), or other optical storage, magnetic cassette, magnetic tape, magnetic disk storage or other magnetic storage device, or other tangible computer readable medium. This may also include non-tangible computer readable media, such as data signals, data transmission, or any other medium that can be used to transmit the desired information and that can be accessed by the computing system 130.

[0060] By way of example, the computer readable storage medium 322 may include hard disk drives that read from or write to non-removable, non-volatile magnetic media, magnetic disk drives that read from or write to removable, non-volatile magnetic disks, and optical disk drives that read from or write to removable, non-volatile optical disks, such as CD ROMs, DVDs, and Blu-Ray® disks, or other optical media. The computer readable storage medium 322 may include, but is not limited to, Zip® drives, flash memory cards, Universal Serial Bus (USB) flash drives, Secure Digital (SD) cards, DVD disks, digital video tapes, and the like. The computer-readable storage media 322 may also include solid-state drives (SSDs) based on non-volatile memory such as flash memory-based SSDs, enterprise flash drives, solid-state ROM, volatile memory-based SSDs such as solid-state RAM, dynamic RAM, static RAM, DRAM-based SSDs, magnetoresistive RAM (MRAM) SSDs, and hybrid SSDs that use a combination of DRAM and flash memory-based SSDs. Disk drives and their associated computer-readable media may provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data for the computer system 130.

[0061] The communications subsystem 324 provides an interface to other computer systems and networks. The communications subsystem 324 serves as an interface for receiving data from the computer system 130 and transmitting data from the computer system 130 to other systems. For example, the communications subsystem 324 may enable the computer system 130 to connect to one or more devices via the Internet. In some embodiments, the communications subsystem 324 may include a radio frequency (RF) transceiver component for accessing a wireless voice and / or data network (e.g., using cellular technology, advanced data network technologies such as 3G, 4G, 5G, or EDGE (enhanced data rates for global evolution), Wi-Fi (IEEE 802.11 family of standards, or other mobile communications technologies, or any combination thereof), a global positioning system (GPS) receiver component, and / or other components. In some embodiments, the communications subsystem 324 may provide wired network connectivity (e.g., Ethernet) in addition to or instead of a wireless interface.

[0062] In some embodiments, the communications subsystem 324 may also receive incoming communications in the form of structured and / or unstructured data feeds 326, event streams 328, event updates 330, etc., on behalf of one or more users that may use the computer system 130. By way of example, the communications subsystem 324 may be configured to receive data feeds 326 in real time from users of social networks and / or other communications services, such as web feeds, such as Twitter® feeds, Facebook® updates, Rich Site Summary (RSS) feeds, and / or real-time updates from one or more third party information sources.

[0063] Additionally, the communications subsystem 324 may be configured to receive data in the form of continuous data streams, which may include event streams 328 of real-time events and / or event updates 330, which may be continuous or infinite in nature with no apparent end. Examples of applications that generate continuous data may include, for example, sensor data applications, financial tickers, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automobile traffic monitoring, etc. The communications subsystem 324 may also be configured to output structured and / or unstructured data feeds 326, event streams 328, event updates 330, etc. to one or more databases that may be in communication with one or more streaming data source computers coupled to the computer system 130.

[0064] The computer system 130 can be one of a variety of types, including a handheld portable device (e.g., an iPhone® mobile phone, an iPad® computing tablet, a PDA), a wearable device (e.g., a Google Glass® head-mounted display), a PC, a workstation, a mainframe, a kiosk, a server rack, or any other data processing system. Because the nature of computers and networks is constantly changing, the description of the computer system 130 shown in the figure is intended only as a specific example. Many other configurations are possible having more or fewer components than the system shown in the figure. For example, customized hardware may be used and / or particular elements may be implemented in hardware, firmware, software (including applets), or a combination. Additionally, connections to other computing devices, such as network input / output devices, may be employed. Based on the disclosure and teachings provided herein, one of ordinary skill in the art will appreciate other manners and / or methods for implementing various embodiments.

[0065] Various methods described herein may be implemented by a computer system, such as computer system 130. Each step of these methods may be performed automatically by computer system 130. In various embodiments, some steps may provide inputs and outputs involving a user. For example, a user may provide inputs for each step of the method, each of which may be responsive to a particular output requiring such input, where the output is generated by computer system 130. Further, inputs may be received from a user, received from another computer system as a data stream, retrieved from a memory location, retrieved over a network, requested from a web service, and the like. Similarly, outputs may be provided to a user, provided to another computer system as a data stream, stored in a memory location, transmitted over a network, provided to a web service, and the like. Further, some embodiments of each of the methods described herein may be implemented as a set of instructions stored on a tangible, non-transitory storage medium to form a tangible software product.

[0066] Like nearly all software-based systems, database systems often need to undergo periodic upgrades to take advantage of new computing technologies. In a migration process, one or more older database systems may be migrated to a new database system. Migration may be necessary because software or hardware has become obsolete, or because benefits offered by a new database system may provide efficiency, cost savings, or other benefits. In embodiments of the present disclosure, migration may allow for upgrading existing hardware and / or changing the operating system of a legacy database server machine while maintaining the database. As an example, an existing database may be migrated from legacy hardware to a new database machine (e.g., an Exadata Database Machine).

[0067] A source database may refer to a database installation and may correspond to a grouping of one or more computer systems that store and include the database installation. A source database may perform retrievals, updates, and other forms of database queries. A migration may refer to moving or copying objects in one or more source databases to one or more target databases. Thus, prior to migration, a database installation may only be available at the source database. Following migration, the database installation exists at the target database and may possibly still exist at the source database. A target database may refer to a grouping of one or more computer systems that store a database installation after migration. Thus, a target database includes a database installation and may perform retrievals, updates, and other forms of database queries following migration.

[0068] 4 illustrates a schematic block diagram of several aspects of a migration environment 400, in accordance with embodiments of the present disclosure. The migration environment 400 may correspond, at least in part, to the distributed system 100 and the system environment 200. The migration environment 400 may include a system 130, which may be or may otherwise correspond to an adaptive migration infrastructure 130. The adaptive migration infrastructure 130 (sometimes referred to herein as an “adaptive migration system” or a “migration system”) may include one or more servers 112 and / or one or more computer systems 300, which may correspond in some embodiments to a cloud infrastructure system 202.

[0069] A client IT infrastructure may house one or more source systems 404 (e.g., database systems) and one or more target systems 408 (e.g., database systems). For larger enterprises, the client IT infrastructure may be geographically distributed across multiple locations. For smaller clients, the client IT infrastructure may be located in a single facility. In some cases, for example, the target system 408 may reside in the same room as the source system 404.

[0070] In some embodiments, the target system 408 may be remotely located. In some embodiments, the target system 408 may be operated by a cloud storage facility. This type of migration may relieve the client from the responsibility of operation and maintenance of the target system 408. In some embodiments, the target system 408 may be co-located with or commonly operated by the same entity that provides the cloud migration services. For example, the target system 408 may be integrated in some embodiments with a remote operations center of a cloud service, such as the cloud infrastructure system 202.

[0071] It will be appreciated that the adaptive migration infrastructure 402 may be remotely located from the source system 404 and the target system 408, and the source system 404 and the target system 408 may or may not be remotely located from one another. The term "remotely located" as used herein will be understood to mean geographically distant or geographically displaced. Entities that are remotely located from one another are typically located in separate facilities many miles away from one another. For example, entities that are remotely located from one another may be separated by a distance of at least 5 miles, 10 miles, 15 miles, 100 miles, etc.

[0072] The migration infrastructure 402 may include one or more migration control server systems 100-1 and one or more automated migration suite databases 114 and may be configured to provide an automated migration suite designed to facilitate migration from one or more source systems 404 to one or more target systems 408 in the most highly automated manner possible. The migration infrastructure 402 may accommodate a centralized structure supporting various migration methodologies for migration of the target systems 408 to various targets, such as on-premise cloud, public cloud, autonomous database, etc. Furthermore, the migration infrastructure 402 may enable dynamic switching between two or more different migration deployment methodologies for migrating components of one or more source systems 404 to one or more target systems 408 (e.g., migrating databases, applications, etc.). The migration infrastructure 402 may be configured to provide many automated services for performing migration bundled into a single approach. Additionally, the migration infrastructure 402 can be configured to dynamically identify the most appropriate set of one or more services depending on the migration characteristics of a particular migration scenario for migration from one or more source systems 404 to one or more target systems 408. In doing so, the migration infrastructure 402 can be configured to select a set of one or more methods that are optimal for a particular migration, the selection being dependent on multiple variables / factors as disclosed herein.

[0073] Contrary to traditional migration, migration facilitated by migration infrastructure 402 does not require a technician to connect to source system 408, configure it, install required software, obtain activation keys, etc. The automated migration suite can be executed on a centralized host, e.g., a virtual machine in some embodiments. The machine can correspond to one or more control server systems 100-1. The control server system 100-1 can initiate and control the migration process. Access to source system 404 and target system 408 can use secure connections (e.g., Secure Shell (SSH) connections, etc.) and / or database links in databases. Data transport can rely on database-to-database communication and can be completely independent of the underlying operating system and storage platform. The network interface of migration infrastructure 402 can include one or more API interfaces for sending and / or receiving communications to and from source system 404 and / or target system 408 using APIs. The one or more API interfaces may include one or more APIs that define protocols and routines for interfacing with the source system 404 and / or the target system 408 via the API interfaces. The APIs may specify API calls to and from the source system 404 and / or the target system 408. In various embodiments, Secure Shell (SSH) and / or any other suitable protocol may be used to facilitate communication between the migration infrastructure 402 and the source system 404 and / or the target system 408.In some embodiments, to collect system data, the migration infrastructure 402 can execute one or more scripts, select one or more databases, establish one or more communication pipes to the one or more databases, log into the one or more databases for command line access via a transport layer, e.g., by IP address and SSH, and pull the system data from the one or more databases.

[0074] All manual steps on the source system 404 and the target system 408 can be eliminated. This architecture can allow hundreds or more systems to be included in a migration project and allows all migrations to be controlled from a single application. Each server in the control server system 100-1 can have enough hardware resources to run all the processes for 4, 10, 20, or more parallel migrations. The automated migration suite can store all scripts and log files created with each migration on the file system and in the automated migration suite database 114.

[0075] Migration setup may include initially registering source systems with migration infrastructure 402, configuring source access (e.g., source OS access) for access by migration infrastructure 402 at least in part by loading source access definitions from a file and automatically generating definitions for all systems, deploying collection and / or analysis agents to source systems 404 to perform database analysis, configuring database links and database link information required to remotely access the systems, and analyzing source systems 404 by performing source system analysis to obtain detailed information about the configured source systems 404. The disclosed embodiments can increase the speed of setup to take only a few minutes as opposed to half a day to copy all files, do exports and imports, configure user permissions, configure source system access, etc. In some embodiments, a CSV file can be used and instead of having to log on to source systems 404 to load SQL packages, create directories, file systems, etc., one can log into a central instance provided by infrastructure 402 to load the information from a file and do it all remotely. Access to the source systems 404 may be provided through database links to skip manual configuration of the source systems 404. Such processes, e.g., deploying analysis agents and performing analyses, may be performed in the background, allowing for seamless testing of large numbers of systems without blocking, interfering with, or otherwise disrupting other activities.

[0076] The migration infrastructure 402 can automatically install the agent on the source database 404 to perform the analysis after the agent is granted any necessary permissions (e.g., select any dictionary, limited session, connect, select catalog role, run with database system administrator, etc.). Configuring the database to connect to the source system 404 can include loading a migration package and running the migration package by the migration infrastructure 402. The analysis can then be performed remotely through a database link. The suite can automatically create the database link. To do so, TNS configuration may not be required and the database link may connect to the source system 404 and the target system 408 using a connection string (e.g., hostname:port / SID). The client can configure the firewall to allow inbound connections using TNS-specific ports to the source system. If only connections from specific hosts are configured, the listener configuration may be updated on the source system 404 and / or the target system 408. The database link configuration can use an input file to load database link definitions having hostname and database name syntax corresponding to hostname and database name combinations of the source system 404 configuration and / or target system 408 configuration to facilitate mapping to the source system 404 and / or target system 408. Analysis of the source system 404 and / or target system 408 can proceed to pass validation for the database link configuration.

[0077] One of the elements of the cloud support service may be a gateway that communicates with the migration infrastructure 402 over a secure connection using a communication module over the network 210. To interface with the migration infrastructure 402 and the services available thereby, the IT infrastructure may include a gateway provided by the migration infrastructure 402 and operating locally with respect to the source system 404. An enterprise manager may be implemented as a dedicated module within the gateway. The gateway may include a module that can access the source system 404 and provide statistics and information regarding the source system 404 to the adaptive migration infrastructure 402. The gateway may include a hardware and / or virtual software appliance installed in the client data center.

[0078] The gateway can collect information from the source system 404, including information about data objects to be migrated to the target system 408, source / target information, and operating system configuration, and can transmit such information to both the target system 408 and / or the adaptive migration infrastructure 402. The supporting gateway can collect performance and configuration data related to the source system 404 and / or the target system 408, and the adaptive migration infrastructure 402 can then use the performance information to perform migration analysis, generate migration scripts, generate a migration plan customized for the client IT infrastructure, and then execute the migration plan to migrate the source system 404 to the target system 408.

[0079] In some embodiments, migration and data analysis can be performed by a gateway installed as an integrated part of the client system. The gateway can communicate with the migration infrastructure 402 and portal disclosed herein to manage and report the migration process. The disclosed embodiments can utilize an enterprise manager to monitor and model the database systems 404 and / or 408 on a consistent and / or periodic basis. An enterprise manager agent can be employed to collect and monitor modeling data related to the customer's databases. Additionally, customer configurations such as EM plugins or custom collectors can be used that query the source and / or target systems and analyze the source and / or target systems. This information can be uploaded to the migration infrastructure 402 service via a gateway present on the client system. The migration infrastructure 402 service can then perform calculations and analysis on the data recorded by the agent to provide data for specific migration scenarios.

[0080] The migration infrastructure 402 can determine whether a gateway is available that provides access to / from one or more client sites to enable service provision. If a gateway is available, the migration infrastructure 402 can check the configuration of the gateway to ensure that it is properly configured with an agent, and the migration infrastructure 402 configures the gateway and agent as necessary. If a gateway is not available, the gateway can be downloaded for installation. The gateway can be installed at the client site and configured with agents and plugins using auto-discovery to set up the workflow of the service. The agents can be deployed to all relevant hosts identified in the preflight phase. The agents, in various embodiments, can correspond to bots, listeners, plugins, and / or similar software components / modules configured to perform functions disclosed herein with respect to the source system 404, the target system 408, and / or the migration infrastructure 402.

[0081] Among other things, various embodiments according to the present disclosure can facilitate the placement of system workloads on complex cloud infrastructures. System workloads can include application workloads and cloud workloads, including database workloads from advanced relational database management system (RDBMS) architectures. Various embodiments can provide new bin-packing / workload placement algorithms for provisioning database workloads that take into account fine-grained monitoring information and advanced architectures such as clustered Oracle databases that enable high availability (HA). In some embodiments, the systems, methods, and non-transitory media disclosed herein may be cloud agnostic and uniform to a cloud vendor, and / or may be implemented in any architecture or configuration, such as remote, on-premise, etc., independent of the cloud configuration, as long as there is a source and a target.

[0082] Various embodiments can facilitate the placement of database workloads, at least in part, by utilizing a bin-packing algorithm that can address the challenges and problems discussed above and can accurately place any vector (multiple metrics) of any dimension, regardless of whether the workload is from a pluggable, clustered, or standby database configuration. Various embodiments can include extensions to the bin-packing algorithm, which may be required when dealing with workloads from advanced computational architectures such as clustering, or workloads that exhibit complex data patterns in their signals, such as seasonality, trends, and / or shocks (exogenous or otherwise). These extensions may be particularly required when consolidating workloads, for example, consolidating multiple databases into one (pluggable database) to reduce database server sprawl in an estate. In accordance with the disclosed embodiments including bin-packing for clustered environments, various embodiments are further configured to utilize a new algorithm that introduces a time element, giving a richer system awareness of the resources required as workloads are consolidated together, ensuring high availability (HA) of workloads derived from advanced database configurations. The disclosed embodiments can reduce the risk of provisioning waste in on-demand cloud architectures.

[0083] Additionally, the disclosed embodiments may provide advantages such as: deploying clustered workloads without compromising high availability from a maximum availability architecture; high-end automation to eliminate manual engineer spreadsheet approaches or reduce the time required for such approaches from days / weeks to minutes / hours; reducing human error in calculating benchmarks such as SPECInt, Disk IO; generating storable plans / design specifications that can be stored in a central repository of bin-packing workloads being deployed; being recursive in that the embodiments can work for any vector and can be used for applications as well as RDBMS; scalable, vectors that can bin-pack for multiple metrics, acting as templates with user input; etc. Additionally, the disclosed embodiments may process clustered workloads and once placement is assigned, the newly created signals may be re-evaluated to identify if there is a need for elasticization of cloud resources. As further disclosed herein, various embodiments may employ software algorithms that track data from metrics such as CPU, memory, and IO, and then take the max_value of the metrics to build vectors. Various embodiments may identify that the vector is part of a cluster and then deploy all siblings of the cluster. If the cluster cannot be deployed discretely in the target cloud environment, any previously deployed sibling workloads may be rolled back.

[0084] FIG. 5 shows an example of various configurations and workload complexities that the system 130 can provide according to the disclosed embodiments of the present disclosure. As shown in the example, there are many types of database configurations that can consume vectors of resources according to the disclosed embodiments. An organization served by the system 130 has an eclectic set of configurations 500 that can include a single instance configuration 505 with standby database. Each workload may have a vector that includes a standby because the standby is still consuming resources and is usually more IO-utilized. Organizations tend to move to a RAC configuration 510 approach with standby, where each instance in the cluster will consume resources. The key here is that the cluster operates non-uniformly. Thus, some workloads will consume more resources than other workloads in the cluster. Now, the pluggable configuration 515 allows for workloads to be separated and consolidated within container databases, but one thing in common is that the container has a workload, just as each individual pluggable database has a workload. Regardless of configuration, all workloads have vectors, and when moving to or already in the cloud, it's important to understand which vectors are where. Systems can be sensitive to different metrics (some may be more IO intensive than CPU, for example), so adding more metrics can also increase vectors.

[0085] When adopting IT (Information Technology) systems to meet requirements, regardless of their type, mix, or configuration, one thing is always common: the challenge of consumption, whether before migration, replatforming, upgrade, or installation. Understanding what resources are required over a period of time is important for the management of all IT systems. For example, as hardware specifications improve in performance and capacity, the actual physical infrastructure decreases, but with the adoption of virtualization, the challenge of server sprawl remains arguably the same. The tradeoff of system isolation is opposed to true consolidation, where workloads must be combined or share the same infrastructure. Knowing how to best fit workloads is a challenge, and it has always been a key challenge to solve. In computing, bin packing can be used to place smaller workloads within a larger infrastructure to establish how resources should be allocated for a set number of tasks. However, bin packing requires further constraints when dealing with advanced system architectures, such as clustering and making the placed workloads elastic.

[0086] The problem to be solved is multi-faceted. When analyzing the deployment problem, it becomes clear that these facets are interrelated, i.e., all parts of the problem need to be addressed together, not just individual elements. A cluster is a group of servers (also known as nodes) that typically join and are managed together to act as one system to provide high availability, as shown in FIG. 6. FIG. 6 illustrates clusters 600 that join and are managed together to act as one system, according to embodiments disclosed by the present disclosure. These clusters 600 can reduce downtime and outages by allowing another server to take over if an outage occurs or maintenance is required. Database clustering is the running of a database 605 across multiple servers while accessing database data files stored on shared storage, e.g., SAN (storage area network), NAS (network attached storage), disk array, or cloud storage facilities such as block, file, or object storage. In FIG. 6, a user can request access to HR, sales, call center applications from any web server 610. The net services layer of the technology stack can handle client access and direct user connections to the node where the service is running (e.g. sales is directed to run from node 2). Heartbeats between the nodes can ensure the integrity of the cluster; if one of the nodes becomes unresponsive or stops generating heartbeats, the service fails over and user connections are handled by the remaining node. This type of architecture can facilitate 24x7 SLAs.

[0087] Referring again to FIG. 5, a workload may include a collection of tasks submitted by a user. In some examples, a workload may be a database, an application, or even a piece of code. A task may be a small unit of work, such as Data Modification Language (DML) statements that perform inserts, updates, and deletes, or individual SQL, for example, by an online transaction processing (OLTP) system serving a web application. Other workloads may include larger units of work, such as batch jobs that periodically aggregate information in a database, for example, daily, weekly, or monthly aggregations of hourly sales data, which is a common feature in data warehouses (e.g., OLAP). Another type of workload is a data mart, which can be said to be somewhere between OLTP and OLAP. A data mart can be made up of a combination of medium OLAP type aggregations and smaller DML OLTP units of work. A data mart can be a subset of a large data warehouse that is subject-oriented, such as sales, HR, or call centers, with aggregations of days and weeks rather than months or years. These units of work may vary in the amount of resources consumed, and when analyzed in a time series format, the tasks often determine when the consumption of resources consumed to satisfy the task occurs. When these tasks are analyzed via traces, the system 130 can identify tasks that exhibit different patterns in their resource consumption. For example, FIG. 7 illustrates an aspect of CPU utilization 700 with a complex data structure according to an embodiment disclosed by the present disclosure. In FIG. 7, four workloads of the CPU are side-by-side. The first task 705, OLTP, exhibits a gradual trend with subtle repeating patterns (e.g., seasonality). The next two tasks 710, 715, OLAP and data mart, respectively, exhibit more definitive patterns of repeating tasks with little trend.

[0088] FIG. 8 illustrates an example aspect of the complexity of workloads 800 in a RAC configuration 510 that is addressed by the disclosed embodiment of the system 130. When placing workloads 800, each workload 800 can be handled individually by extracting the peak values ​​of each metric from each database instance on each node at each time interval and placing them on the target node. This may be simple enough as long as the workloads 800 are singular (independent of each other and running on a single node). If the workloads 800 are clustered, it becomes more complicated because when the placement begins, the placement of the workloads 800 must be done without compromising HA. Thus, in order to place one clustered workload 800, all workloads 800 in the cluster must be placed. If the clustered workloads 800 are placed without sibling workloads, there is a risk that the clustered workloads 800 will reduce to a single workload, resulting in loss of high availability and therefore compromised SLA. The same understanding is needed for pluggable databases, where a database may be detached from a single database instance and plugged into another clustered database instance.

[0089] As an example of a problem in the prior art, the workloads 800 of the RAC configuration 510 may be distributed across each source node. As shown in FIG. 8, the workloads 800 of the RAC configuration 510 cannot be placed on the same target node unless there are enough nodes, so all the workloads 800 are placed discretely. In one example of a problem in the prior art, four workloads 800 cannot be placed on three target nodes 805 in the cloud. No other bin-packing algorithm (i.e., other than the one disclosed herein) can solve this challenge when placing the workloads 800. If all the workloads 800 cannot be placed discretely, the placement may be rolled back and resources may become available for other workloads 800 that need to be placed. In OCI, three target nodes 805 may be configured and built, but since there are four siblings in the cluster, MAA cannot function because four does not fit into three. The workloads 800 of the RAC configuration 510 may be shared across multiple nodes 805 (MAA). QoS is employed when several nodes are separated to perform functions. Therefore, each database instance and the resources consumed should be considered. The reason is that in case of node 805 failure, there may be a quality of service where some applications are given priority for the node over others.

[0090] Consolidation can be described as running several workloads on a shared collection of nodes. Whether it is the number of servers, clusters, databases, or workloads, there are several drivers for consolidation such as simplifying the system or reducing server sprawl. Server sprawl can be described as a situation where servers are not being used to their full capacity, resulting in significant waste in terms of space, power, and cooling, which ultimately results in significant costs to the organization. Database consolidation has been made easier with the development of pluggable databases, which allow a database to be decoupled from a single or clustered container DBMS (the memory structures that make up the instance) and plugged into another container DBMS that already has multiple databases plugged in. By decoupling and plugging in a pluggable database, the pluggable database (and its associated data files) can be moved to another server and managed by another database instance (DBMS).

[0091] This is illustrated in FIG. 9, which adds an additional layer of abstraction when working with HA. FIG. 9 illustrates aspects of a pluggable database 905 with a multi-tenant architecture 900 according to an embodiment disclosed by the present disclosure. Each node 805 in the cluster also houses a clustered container, and within each clustered container is a pluggable database 905. This architecture 900 removes the support overhead of a database instance serving one database, when one database instance can serve multiple plugged databases 905 while achieving HA. However, when you get down to doing the deployment, it becomes difficult to understand where resources are consumed. For simplicity's sake, the pluggable databases 905 can be handled by the same database instance, but there is no reason why the pluggable database 905 cannot be separated as its own entity and handled as its own own workload.

[0092] Part of the problem solved by system 130 can be considered as follows: Consider a collection of workloads 800, some of which are clustered, and a collection of computational nodes 805. Each workload 800 has a time-varying demand for resources defined using some metric, and each server has a capacity defined using the same metric. The task is to assign workloads 800 to nodes 805 such that the demands imposed by the workloads 800 always fall within the capacity of the nodes 805, while respecting the constraints imposed by the clustered workloads 800. Conventional bin-packing algorithms do not take into account the diverse types of applications assigned to individual servers.

[0093] In cloud computing, the need for optimal resource usage with the goal of reducing waste becomes even more evident as users can access resources (vectors) of any shape from any location and still be required to be optimized. As shown in Figure 10, a vector can define multiple metrics (e.g., IOPS, memory utilization, CPU utilization, etc.) that make up the shape, rather than one single metric. Each workload can be defined by one or more vectors. Regarding vector placement using bin-packing techniques in a clustered environment, several workloads running on the same cluster may be full or a combination of classifications that may terminate their algorithm. In clustered workloads, where workloads with different priorities may run from x nodes in the cluster, SLA enforcement was required. Vector bin-packing can ensure that the sum of the workloads does not exceed the sum of the bins at any given time. In the illustrated example, there are three vectors (vectors 1, 2, and 3) to be placed together on an empty target. If vectors 1 and 2 are placed together, they will not fit as they will exceed the sum of the bins, but that is not the case for vectors 1 and 3. The vector can correspond to multiple metrics that the system 130 can use to account for peaks and troughs in the workload over time. The system 130 can predict future utilization of the workload and identify waste as the workload is consolidated. The vector can be dynamic and its size can be increased by adding more metrics.

[0094] The basic bin packing problem is the process of packing items of different volumes into a finite number of bins (boxes) in a way that minimizes the number of bins used. In practice, approximations, especially heuristic algorithms, are often used. There are many techniques for bin packing, such as First-Fit Decreasing (FFD), Next-Fit (NF), and Best-Fit (BF). Considering First Fit Decreasing, all provisioned workloads may be treated as having equal priority. Elastic Resource Provisioning (ERP) is to assign all workloads to one bin and make the bin elastic to fit around the workloads placed. Various embodiments improve FFD to tackle complex architectures such as clustered workloads and evaluate them experimentally and empirically.

[0095] First Fit Decreasing Configuration (FFD) The notation used to describe bin packing herein is listed in Table 1 and illustrated in Figures 11 and 12. Figure 10 illustrates an aspect of node resource capacity 1000 according to an embodiment disclosed by the present disclosure. Figure 12 illustrates an aspect of workload resource demand 1200 according to an embodiment disclosed by the present disclosure. The available resources can be represented as a set of nodes, each of which has a capacity defined using a set of metrics that may include CPU, memory utilization, logical I / O operations per second, etc. The bin packing task can be to assign a set of workloads to the nodes. The demand associated with each workload can be defined in terms of the same metrics used to describe the nodes, but the demand may vary over a series of times. The time-varying demand may be based on measured or forecasted loads, for example, using time series analysis techniques to model database workloads for capacity planning.

[0096] [Table 1]

[0097] Sorting Workloads First fid decreasing allows the workloads to be sorted so that they can be allocated largest first, hence the notion of magnitude. Here, the order can be defined in terms of the demand across different metrics, normalizing according to the total utilization for each metric. The overall demand for each metric (CPU, IOPS, memory, storage) can be obtained from the demand of each workload as follows:

[0098]

number

[0099] Then, the normalized demand of a workload w may be the normalized sum of its demand across all metrics.

[0100]

number

[0101] The workloads can then be sorted by their normalized demands. In practice, when allocating clustered workloads, the clusters can be considered in order of the demands of their most demanding workloads, and then the workloads within the clusters can also be sorted locally.

[0102] Node Capacity The capacity of node i for metric m at time t can be taken as the original capacity of the node minus the resource utilization of the workload assigned to the node.

[0103]

number

[0104] Compatibility If there is always capacity for all metrics, then workload w can be added to node n.

[0105] fits(w,n)=∀m∈Metrics∀t∈Times Demand(w,m,t)≦node_capacity(n,m,t) (4) A clustered workload,isClustered,from Table 1 may be database instances (workloads) that are siblings of each other, as shown in Figure 6. A node is a i may be the number of nodes to be executed, and w∈ClusteredWorkload may be the set of workloads that need to be discretely assigned to the target nodes. A rule may be enforced that all siblings must be packed into discrete target nodes before the cluster is said to be packed. If at any point in time we fail to pack one of the siblings into a discrete target node, all siblings may be rolled back and resources may be released back to node_capacity.

[0106] Using techniques based on FFD and the definitions disclosed herein, the system 130 can place database workloads on a target cloud infrastructure (e.g., Oracle Cloud Infrastructure (OCI)) that supports clustered workflows. The system 130 can achieve savings in both monetary (pay-per-use) costs and the cost of returning resources to a cloud pool for use elsewhere.

[0107] Workload Placement Algorithm A high-level description is given in Algorithm 1. One of the main challenges in workload placement on computing assets employing clustered configurations is to consider whether the clustered workflow should be placed in its entirety or not at all. Identifying that a workload is clustered and the number of nodes can be important for placing the workload on a target cloud configuration.

[0108] [Table 2]

[0109] First, system 130 can extract key information as input to order workloads by demand. Key configuration data can be stored in a central repository that stores whether a workload is clustered or not. If a workload is part of a cluster, system 130 can set a flag (represented by isClustered in Table 1) for that particular workload and can use Siblings in Table 1 to get the full set of workloads that are clustered.

[0110] When placing a workload, if the workload w is from a single database instance, the system 130 determines whether the workload fits (f its (Eq. 5)) on an available node, and if so, adds it to the Assignment of that node. The system 130 can report to the user all the workloads that were fitted (by Assignment) and the workloads that were not fitted (by NotAssigned). However, if the workload is clustered, the system 130 may extract the associated Sibling workloads in the cluster from a central repository, since the Oracle Enterprise Manager system and OEM intelligent agents can be used to obtain all the performance and configuration data related to the database instance. The OEM can utilize a database schema to hold the information related to the workload. The database instance and this information can be addressed via a Global Unique Identifier (GUID).

[0111] Clustered Workload Adaptation Adaptation of a clustered workload may aim to enforce high availability by placing all workloads in a cluster before the workload can report that it has been adapted. For example, as illustrated in Figure 6, if a clustered workload has three nodes with a database instance running on each node, the workload can be deployed to discrete target nodes or rolled back what has already been placed (which in some embodiments may involve returning to an earlier decision point in the process flow with appropriate notification via a user interface). This is shown in Algorithm 2.

[0112] [Table 3]

[0113] First, the system can determine the number of nodes that make up the cluster (1, 2,..., N), which indicates the number of target nodes required. If the clustered workload from three nodes cannot be fit onto two target nodes, the system 130 can perform a test to ensure that the required number of target nodes are available. If there are not enough target nodes, the system 130 can loop through all workloads, ensuring that siblings of the cluster are assigned to discrete target nodes. Each time an assignment is made, the amount of resources of the target node may be reduced by the workload vector. Finally, the system 130 can report what workloads have been assigned to each target node.

[0114] Evaluation of adapted placement Once the workloads from all database instances are assigned and placed on their target nodes, each workload can be stacked with a time frequency (hourly) to understand the existing data signal (peaks and troughs) when the workloads are consolidated. A simple groupby(Σ) by time and metric can show the newly consolidated data signal. In a traditional bin-packing run, the max_value of the metric can be taken and the bin-packing can be based on that value. However, if the peaks are singular, e.g. without a pattern, overprovisioning may be evident. When new traces are displayed (stacked) on X,Y, the consolidated workloads may show their complex characteristics such as seasonality, trends, shocks to the bin threshold limits, etc. This technique reveals further elicitation runs that can be performed on the bins to more closely match the consolidated workloads, which can be implemented or reflected in them if possible.

[0115] Various embodiments can be configured to perform vector bin packing utilizing a first-fit decreasing algorithm for databases employing advanced techniques such as clustering and pluggable databases in order to fit various workloads into complex target cloud configurations such as Oracle Cloud Infrastructure with bare metal configurations. A vector approach may be required when placing a workload into a cloud configuration, since most cloud providers provision in multiple dimensions such as IOPS, storage, CPU, and memory. When the cloud consumer is also a cloud provider, the vectors may increase in number and cover other areas of cloud technology such as network throughput, NIC bandwidth, or VNIC configuration, just to name a few.

[0116] As a workload migrates through the architecture, the max_value signals of the metrics associated with that workload may change over time, especially when analyzed in a time series format. Thus, there may be a risk of overprovisioning if the max_value of a metric over a period of time is blindly allowed without determining if a pattern or trend is repeated. What was initially provisioned may not be necessary once the workload is placed, consolidated, and cumulative signals are obtained from the target node.

[0117] Although bin packing is disclosed in some examples herein, including those focusing on First-Fit Decreasing (FFD) as a bin-packing technique, the workload placement function may be used in one or combination of any of the following: A first-fit implementation may order the items in descending order of magnitude and then proceed from the first bin until all bins are full. A worst-fit implementation may focus on the bin with the smallest load and attempt to fit the item. If the item can fit, it may be placed. If not, the next bin may be evaluated as to whether the item fits. A best-fit implementation may keep a list of items and bins that are free. The bin with the largest load may be determined. If the item can be placed, it may be placed. If not, a new bin may be freed. A next-fit implementation may order the items from largest to smallest and free a bin. If the item fits, it may be placed. If not, the flow can move to the next bin until the item can fit. If the item cannot fit, it cannot be placed. A refined-first-fit implementation can categorize the bins according to size, and then the item can be fit. This can include evaluating bins of different sizes and placing the item. A harmonic implementation can order the items as 0, 1, and then pack the items into the minimum number of bins to the correct number. A refined harmonic implementation can place items into bins based on 1 / 3, and can be designed to reduce waste for items that are 1 / 2. That is, two items can go into a bin with 2 / 3 less waste than 1 / 2. A modified harmonic implementation can be a derivative of the refined harmonic approach.The harmonic +1 and harmonic ++ implementations may be derivatives of the modified and improved harmonic approaches. An almost-worst fit implementation and other embodiments are also possible.

[0118] FIG. 13 illustrates another example of how the system 130 determines workload aspects according to the disclosed embodiments of the present disclosure. An example of a CPU with a plot 1300 of CPU utilization versus time with three different workloads is shown. As shown by 1305, the system 130 can take the max_value from the entire signal and place the workload at that value. Additionally, the system 130 can detect repeating patterns that result in waste, as shown by 1310. As shown by 1315, the system 130 can make predictions. The system 130 can sum the max_values. Thus, a workload may appear to fit but not fit when integrated together and each of the time points (hourly) are measured correctly. Other bin-packing placement algorithms can take the max_value for a given number of observations (e.g., hourly), but they may not be repeating patterns, which means the probability of overprovisioning is very high.

[0119] FIG. 14 illustrates an example of how the system 130 analyzes the aggregated temporal workloads considering anomalies in the data, according to an embodiment disclosed by the present disclosure. Only if the system 130 analyzes the workloads more deeply can the system 130 understand whether dynamic configuration or further elasticization is required. An example of a CPU with CPU utilization versus time plot 1400 is shown. As shown by 1405, there may be three workloads with fairly low utilization. As shown by 1410, the aggregated workload can aggregate all three workloads 1405. As shown by 1415, elasticization is shown. As shown by 1420, the system 130 can detect anomalies in the data that skew the placement algorithm. As shown by 1425, the system 130 can increase the target node capacity from 100 CPU to 140 CPU so that all workloads fit. As shown by 1430, the anomalies cause opportunities for waste because the placement algorithm only takes the maximum value from each workload. Thus, anything between the aggregate line and the provision line is unused and provisioned. As shown by 1435, what is needed is to elasticize around the aggregate signal of all workloads once the signal has been determined.

[0120] The system 130 can perform analysis of the aggregated time series data signals, including comparisons with target bin totals (nodes in cloud configuration or not) to see if further efficiencies can be gained by elasticization to reduce waste in provisioning. The analysis can consider OLTP type workloads with trends and seasonality to identify provisioning that can be "throttled" or elasticized to achieve further efficiencies. The sum of the workloads for a particular instance of a set of workloads added together may exceed the sum of the bins. Bin packing algorithms can be orthogonal (statically independent) when placing vectors, placing based on what is given to place. Thus, the system 130 can perform forecasting (e.g., future capacity planning) and then perform placement design. Often, bin packing is done based on a maximum value, but the maximum value may have occurred only once, with a short, transient spike (or, in some cases, a similarly small number of spikes that are unlikely to occur again). If provisioning is determined by that one-time spike, the potential for waste is very high. Such waste situations are detected and eliminated by the system 130.

[0121] Given the prevalence of high availability techniques such as replication (standby databases), isolation (pluggable databases), or clustering to enforce SLAs, and the lack of a bin-packing algorithm that can account for clustered workloads, system 130 can be configured to use a different FFD bin-packing algorithm. The introduction of pluggable databases allows a different approach to be adopted by system 130 other than simply mapping database instances to VMs as a one-to-one mapping. Consolidating workloads together provides additional complexity that system 130 can accommodate. For example, pluggable databases provide isolation and agility by allowing users to more easily detach and attach databases from one location to another, while still connecting to global database memory structures that are consuming resources. Treating pluggables as single instance workloads can reduce complexity within system 130's algorithms, which may enable placement of pluggable databases. Pluggable databases can be assigned to nodes, and collections of pluggable databases can be assigned to target nodes, as clustered pluggable databases can be shared across multiple target nodes. Thus, the system 130 can be configured to use algorithms that can be versatile in terms of arranging simple, complex, and highly complex vectors resulting from any database workload, regardless of the composition of the source database.

[0122] Treating pluggable and standby databases as single instance workloads allows the system 130 to perform workload placement without introducing additional notation into the formulas. The standby database may be in recovery mode, typically applying all archive logs from all nodes in the primary cluster. Thus, the standby may be single instance with more IO resources than memory or CPU.

[0123] Central repository. The system 130 can be configured to provide a central repository. The system 130 can be configured to spin up and use Monitor-Analyze-Plan-Execute (MAPE) capable intelligent agents to centrally identify, retrieve, and store metric and configuration data, allowing the system 130 to uniformly align workload time series data. The intelligent agents can run commands, such as sar or iostat, at specific times, and the command results are stored in the central repository, for example, in a database schema with one or more databases 114. The system 130 can perform aggregation to hourly values ​​on the metric data, which has the negative effect of smoothing the signal (averaging the time points), but may allow easier comparison of workloads at any given time period, as shown in FIG. 11. FIG. 11 illustrates aspects of node resource capacity 1100 in accordance with an embodiment disclosed by the present disclosure. Centralized analysis of workloads allows the system 130 to much more easily identify workload sar and iostat outputs from different machines and can reduce the amount of data wrangling required at the application layer (e.g., via Python libraries such as Pandas, Numpy, etc.).

[0124] Benchmarks. Comparing one CPU model to another is a challenge. System 130 may use benchmark SPECInt 2017 to compare workloads consuming CPU on one architecture to workloads running on another chip architecture. If a benchmark is not available, system 130 may select SPECInts from the closest chip models above and below. System 130 may store SPECInts chip benchmarks in a central repository and perform a calculation of 50% of CPU used, which may equal 50% of peak SPECInts. System 130 may also utilize storage benchmarks based on Transaction Processing Performance Council benchmarks. However, RDBM systems may utilize complex storage algorithms that often bypass database fetch operations. For example, Oracle Exadata technology may pin commonly requested data to memory caches to aid database performance. Complexity is also added to SAN, NAS, or cloud storage facilities such as block, file, or object storage where database files are stored as mounted volumes and therefore may utilize complex techniques with logical reads interpreted as metrics. However, given that the algorithms disclosed herein allow for placement into metrics (i.e., vectors) that can grow in number (i.e., are scalable), there is no reason why system 130 cannot use physical IOPS or a combination of physical reads and physical writes. In embodiments disclosed herein, placement into larger vectors with additional metrics can be performed.

[0125] Templates. The system 130 can use templates that allow user input, where the user selects a metric or set of metrics that can be assigned to a vector from a workload of either a single, pluggable, or clustered database instance. This can facilitate the cloud service provider use case of placing workloads on all sides of the cloud. The system can be susceptible to a myriad of performance challenges, with bottlenecks appearing at the network layer as well as the CPU or disk architecture. Thus, it can be important for the user and / or the system to be able to extend the vector by adding more metrics to be deployed. Systems behave differently from one another as they are called upon to perform different functions within a business silo. By utilizing templates, the system 130 can give the algorithm the ability to extend the vector.

[0126] Automation. In a manual approach to performing workload placement, engineers tend to adopt a spreadsheet approach when deploying workloads to the cloud. This approach can be cumbersome, for example, manually researching and converting CPU (SPECint), IO speeds, and memory between source and target architectures to create spreadsheets is time consuming. Often, these spreadsheets become complex, bespoke to individual customers, and inflexible, resulting in "expert-friendly" analyses that can only be understood by the creator. However, the disclosed embodiments of the system 130 can automate this process, aiming to reduce the level of effort that engineers expend in manually building spreadsheets, reduce errors due to miscalculations that can occur in bespoke spreadsheets, and reduce the time to complete a deployment plan from weeks / months to hours / days or less.

[0127] An embodiment of the system 130 executing the disclosed algorithms can effectively retrieve configuration and performance data from a central repository. For example, rather than manually researching the make, model, and SPECInt value of a CPU, that data is extracted by an intelligent agent, and a comparison is then made, eliminating all such manual research. And an embodiment executing the algorithms can rapidly deploy and store a deployment design for a workload as a "plan" in a normalized database schema, rather than having a complex set of custom spreadsheets. This can enable the execution of the deployment algorithm in minutes or less, rather than days or weeks.

[0128] Thus, the system 130 can be configured to provide accurate workload placement, especially when provisioning services such as IaaS, PaaS, DbaaS, or SaaS, whether on-premise, remote, or hybrid cloud. However, when advanced workload configurations such as clustering are employed, standard or off-the-shelf approaches are problematic, so the system's selection of the optimal algorithm or collection of placement algorithms to use is important. Due to the first-fit decreasing bin packing method in advanced database architectures such as clustering and pluggables, the disclosed embodiments of the system 130 can extend the FFD algorithm to accommodate sibling workloads in a cluster, especially when the cluster is consuming resources unevenly. By considering siblings when ordering clustered workloads, the system 130 can order a workload and its siblings. This is to take into account siblings in a cluster that consume resources unevenly. If clustered instance workloads are individually enumerated, one workload in a cluster may be ranked quite low compared to its siblings when a simple ordering exercise is performed. Eventually, the target nodes will exhaust their resources and the placement will stop. If the target node exhausts its available resources before its sibling nodes are placed, a rollback execution may be implemented by the system 130. Therefore, ordering the clusters and their siblings in descending order may be important. Other protocols may be employed by the system 130, including a cumulative approach of the total amount of resources consumed per cluster, and ordering based on the number of nodes and then the resources consumed. Additionally, a user-defined priority assignment feature may be facilitated by the system 130. Assigning user-defined priorities to workloads may allow for isolation between live systems, as some systems may be more critical than others.System 130 can leverage machine learning (supervised) combined with time series analysis to predict future resource consumption of a workload in combination with placement, which may further facilitate system 130 in determining which systems can be placed based on future resource consumption.

[0129] FIG. 15 illustrates an example method 1500 for facilitating migration of data and / or applications from one or more source systems to one or more target systems in accordance with disclosed embodiments according to the present disclosure. Method 1500 should be understood as representing some, but not all, aspects of the methods and operations disclosed above. The teachings of the present disclosure may be implemented in a variety of configurations. Thus, the order of steps constituting method 1500 and / or other methods disclosed herein may be permuted or combined in any suitable manner and may depend on the implementation selected. Additionally, although the following steps may be separated for purposes of illustration, it should be understood that some steps may be performed simultaneously or substantially simultaneously.

[0130] Method 1500 may illustrate example services provided by system 130, including discovery, capacity planning, modeling, and decision services for placing workloads of one or more source systems in a migration of data and / or applications from one or more source systems to one or more target systems. Method 1500 may include planning the placement of workloads of one or more source systems in one or more target systems to facilitate the migration. Method 1500 may incorporate machine learning and artificial intelligence to model the workloads, plan the placement of the workloads in the target systems, predict bin placements and corresponding workloads, and / or create placement specifications for packing clustered environments.

[0131] As indicated by block 1505, the system 130 may perform a source discovery operation. The source discovery operation may be facilitated by a migration setup operation, a collection and / or analysis agent deployed on the source system and configured to facilitate the discovery operation, a gateway configured to facilitate the discovery operation, etc., as disclosed herein. Thus, the system 130 may receive data related to the first number of source nodes. The source discovery operation may include the system 130 discovering attributes of the on-premise workload. The system 130 may determine one or more workload types (e.g., database, RDBMS, application, SaaS, etc.). The source discovery operation may include the system 130 determining characteristics of the workload (e.g., architecture, RAC, pluggable, etc.). The system 130 may use a bin-packing algorithm to improve efficiency and accuracy of the provisioning task. When performing data collection, the system 130 can use automated collectors / agents (e.g., EM and AWR Extract, Transform, and Load (ETL) etc.) to collect key metrics and transmit the data securely.

[0132] As indicated by block 1510, the system 130 may perform a target discovery operation. The target discovery operation may be facilitated by a migration setup operation, analysis of data collected by a source discovery operation, and / or a determination by the system 130 regarding requirements of one or more source systems. Thus, the system 130 may receive data related to a second number of target nodes. The target discovery operation may include the system 130 determining OCI target bins. The system 130 may identify one or more bins into which the system 130 may fit a workload.

[0133] As indicated by block 1515, system 130 can use machine learning and artificial intelligence to perform mapping and modeling for migrating source (i.e., current) workloads to the target. In performing data analysis, system 130's process can be automated for each tier to the stack and can include machine learning to predict future resource consumption and can include ongoing analysis with a repeatable process to track progress as workloads are migrated. System 130 can use machine learning to predict bins and bin packing as consolidation is performed.

[0134] The system 130 can perform capacity planning. To do this, the system 130 can use machine learning to analyze resource consumption and workload metrics of on-premise workloads and make predictions of future usage based, at least in part, on the analyzed resource consumption. The system 130 can use a base workload consisting of resources (CPU, memory, storage / IOPS) taken from the maximum value over a period of time. The system 130 can consider the sum of bins and their capacities. The system 130 can then order the shapes based on size / requirements and / or priority. When designing new landscapes, the system 130 can facilitate an automated UI that is continuously updated during the life of the service.

[0135] The system 130 may generate a feature mapping configuration for mapping one or more source features to one or more targets. Such operations may facilitate the creation of a placement plan or may be included in the placement plan. The mapping techniques of the system 130 may include automated lookup, automated mapping, and bin-packing algorithms to ensure that the correct workloads are matched and satisfied with the correct target configuration. The system 130 may perform modeling to facilitate the bin-packing. This may include creating a bin-packing specification to specify the matching of the workloads. The system 130 may determine the best model for matching the workloads in the OCI. Such operations may include mapping source features to targets or may be based, at least in part, on such mapping. Thus, the system 130 may analyze data associated with a first number of source nodes and a second number of target nodes and may create a migration plan that specifies the placement of workloads from one or more source systems to one or more target systems.

[0136] As indicated by block 1520, the system 130 can match shapes to the correct target bins according to first fit, best fit, and / or elasticization based on the size and priority applicable to the available shapes. FIG. 16A illustrates some aspects of an example workload consolidation and bin packing into target bins by first fit according to embodiments disclosed by the present disclosure. FIG. 16B illustrates some aspects of an example workload consolidation and bin packing into target bins by best fit. If the bins are not large enough, the system 103 can elasticize the provisioning to accommodate the workload. The system 130 can generate a report on the best bin based on the priority, workload characteristics, features, monetary report of elasticization vs. provisioning, waste eliminated by best fit, etc., which the system 130 can communicate to one or more endpoint devices via a UI and / or via network transmission.

[0137] The system 130 can perform migration according to the migration plan. The placement can include packing the pluggable or clustered environment. As disclosed herein with respect to workload placement algorithms and matching clustered workloads, the system 130 can utilize workload placement algorithms that can include performing tests. The pluggable database provides a degree of isolation like a clustered environment, and the embodiments disclosed herein can be configured to handle clustered and pluggable composite environments because they treat sibling workloads as instances, as disclosed above. The system 130 can be configured to intelligently provision the minimum provisioning for each workload, as well as to place sibling workloads together if there are multiple siblings. This can be an improvement over conventional approaches that can only provision for the largest workload and placement of only one workload at a time, resulting in a lot of waste between each sibling workload where the sibling workloads are related to each other. Thus, the disclosed embodiments can reduce waste and handle such related workloads, as disclosed in detail above.

[0138] If the number of target nodes is greater than the number of source nodes, the workload may be placed from the source nodes to the target nodes. If the number of target nodes is less than the number of source nodes, the workload from the source nodes is not placed on the target nodes and one or more rollback operations may be performed. This allows the system 130 to ensure that its design maintains its design for important attributes such as quality of service (some nodes may be given preference over others) and SLA. The SLA may accommodate some nodes that may be switched off to less important parts of the "whole" system. Thus, migration may include placing the workload from the source nodes to the target nodes when the number of target nodes is greater than the number of source nodes.

[0139] Further, as disclosed herein, a migration operation including placement of a workload from one or more source systems to one or more target systems may be scalable such that the placement of the workload is based, at least in part, on one or more dimensions along which a vector may be augmented. The vector may include dimensions of a metric corresponding to one or more IO metrics, CPU metrics, memory metrics, etc., and may be a function of time. The system 130 may obtain an integrated time series data signal corresponding to the workload. The system 130 may analyze the integrated time series data signal and compare the integrated time series data signal to a target bin total to determine whether further efficiency can be gained by elasticization to reduce waste, and if so, the system 130 may elasticize the target bin.

[0140] As indicated by block 1525, the system 130 can continually evaluate the migration using reinforcement learning as the migration continues and after one or more parts / phases of the migration are completed. The process flow may, for example, cycle back to 1505. The system 130 can accommodate for time complexity by adding an element of time, at least in part, as the time each shape is required. Workloads are likely to change as they are migrated to the target, and thus the system 130 can perform continuous modeling operations, including machine reinforcement learning (MRL), to ensure the best integration. In performing the recursive analysis, the system 130 can utilize reinforcement learning and continuous evaluation of AI and ML (e.g., MDP) to ensure the reliability of the configuration and adjust the target cloud as needed, as the workload moves.

[0141] In the foregoing description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of various embodiments of the present invention. However, it will be apparent to one skilled in the art that embodiments of the present invention may be practiced without some of these specific details. In other instances, well-known structures and devices are shown in block diagram form.

[0142] The foregoing description merely provides exemplary embodiments and is not intended to limit the scope, applicability, or configuration of the present disclosure. Rather, the foregoing description of exemplary embodiments provides those skilled in the art with an enabling description for implementing the exemplary embodiments. It should be understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope of the invention as set forth in the appended claims.

[0143] Specific details are provided in the foregoing description to provide a thorough understanding of the embodiments. However, it will be understood by those skilled in the art that the embodiments may be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may be shown as components in block diagram form in order to avoid obscuring the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to avoid obscuring the embodiments.

[0144] It should also be noted that the particular embodiments may be described as a process that is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe operations as a sequential process, many of the operations may be performed in parallel or simultaneously. Additionally, the order of operations may be rearranged. A process terminates when its operations are completed, but may have additional steps not included in the diagram. A process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination may correspond to a return of the function to the calling function or to the main function.

[0145] The terms "computer-readable medium", "computer-readable medium(s)", "processor-readable medium(s)", "processor-readable medium(s)", "machine-readable medium", and "machine-readable medium(s)" include, but are not limited to, portable or non-removable storage devices, optical storage devices, wireless channels, and various other media capable of storing, housing, or transporting instructions and / or data. A code segment or machine-executable instructions may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a class, or any combination of instructions, data structures, or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and / or receiving information, data, arguments, parameters, or memory contents. Information, arguments, parameters, data, etc. may be passed, forwarded, or transmitted via any suitable means including memory sharing, message passing, token passing, network transmission, etc.

[0146] Furthermore, the embodiments can be implemented by hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented by software, firmware, middleware, or microcode, the program code or code segments to perform the necessary tasks can be stored in a machine-readable medium. A processor can perform the necessary tasks.

[0147] In the foregoing specification, aspects of the invention have been described with reference to specific embodiments thereof, but those skilled in the art will recognize that the invention is not limited thereto. The various features and aspects of the invention described above can be used individually or jointly. Moreover, the embodiments can be utilized in any number of environments and applications beyond those described herein without departing from the broader spirit and scope of the specification. Accordingly, the specification and drawings should be regarded as illustrative rather than restrictive.

[0148] Furthermore, for illustrative purposes, the methods have been described in a particular order. It should be understood that in alternative embodiments, the methods may be performed in an order different from that described. It should also be understood that the methods described above may be performed by hardware components or embodied in a sequence of machine-executable instructions that can be used to cause a machine, such as a general-purpose or special-purpose processor or logic circuitry programmed with the instructions, to perform such methods. These machine-executable instructions may be stored on one or more machine-readable media, such as a CD-ROM or other type of optical disk, a floppy diskette, a ROM, a RAM, an EPROM, an EEPROM, a magnetic or optical card, a flash memory, or any other type of machine-readable medium suitable for storing electronic instructions. Alternatively, the method may be performed by a combination of hardware and software.

[0149] Additionally, the terms in the claims have their plain and ordinary meaning unless expressly and unambiguously defined by the patentee. The indefinite articles "a" or "an" when used in the claims are defined herein to mean one or more elements that the particular article introduces, and the use of the definite article "the" thereafter is not intended to negate that meaning. Furthermore, the use of ordinal terms such as "first," "second," etc. to distinguish different elements in the claims is not intended to confer a particular position in the series, or any other sequential order or sequence, to the element to which the ordinal term is applied.

Claims

1. 1. A system for deploying workloads of one or more source systems in a data and / or application migration from the one or more source systems to one or more target systems, the system comprising: one or more processing devices; and a memory communicatively coupled to and readable by the one or more processing devices; The memory includes processor-readable instructions that, when executed by the one or more processing devices, cause the one or more processing devices to perform operations, the operations including: receiving data relating to a first number of source nodes and a second number of target nodes; analyzing data relating to the first number of source nodes and the second number of target nodes; creating a migration plan that specifies placement of workloads from one or more source systems to one or more target systems; The deployment includes packing a pluggable environment or a clustered environment, and packing the pluggable environment or the clustered environment includes: if the second number of target nodes is greater than the first number of source nodes, placing workload from the source nodes to the target nodes; if the second number of target nodes is less than the first number of source nodes, the workload from the source nodes is not placed on the target nodes and one or more rollback operations are performed; performing the migration according to the migration plan; The system, wherein the migration includes placing the workload from the source node to the target node if the second number of target nodes is greater than the first number of source nodes.

2. The system of claim 1 , wherein the one or more target systems correspond to a cloud infrastructure, and the placement of the workload corresponds to placing the workload in the cloud infrastructure.

3. The system of claim 2 , wherein the operation is scalable such that the placement of the workload is based, at least in part, on one or more dimensions along which a vector can grow.

4. The system of claim 3 , wherein the vector includes metric dimensions corresponding to one or more of an input / output (IO) metric, a central processing unit (CPU) metric, and / or a memory metric.

5. The system of claim 4 , wherein the vector is a function of time.

6. The operation is obtaining an integrated time series data signal corresponding to the workload; 6. The system of claim 5, further comprising: analyzing the integrated time series data signal and comparing the integrated time series data signal to a target bin total to determine whether further efficiencies can be gained through elasticization to reduce waste.

7. The operation is further comprising making the target bin elastic; The system of claim 6 , wherein the target bin corresponds to a node in a cloud configuration.

8. The system of claim 7 , wherein the migration service is cloud-based.

9. 1. A method for deploying workloads of one or more source systems in a data and / or application migration from the one or more source systems to one or more target systems, the method comprising: a migration infrastructure receiving data relating to a first number of source nodes and a second number of target nodes; the migration infrastructure is located remotely from the first number of source nodes and is configured to provide migration services; The method comprises: the migration infrastructure analyzing the data regarding the first number of source nodes and the second number of target nodes; the migration infrastructure creating a migration plan that specifies placement of workloads from one or more source systems to one or more target systems; The deployment includes packing a pluggable environment or a clustered environment, and packing the pluggable environment or the clustered environment includes: if the second number of target nodes is greater than the first number of source nodes, placing workload from the source nodes to the target nodes; if the second number of target nodes is less than the first number of source nodes, the workload from the source nodes is not placed on the target nodes and one or more rollback operations are performed; The method comprises: The migration infrastructure further includes executing the migration according to the migration plan; The method, wherein the migration includes placing the workload from the source node to the target node if the second number of target nodes is greater than the first number of source nodes.

10. The method of claim 9 , wherein the one or more target systems correspond to a cloud infrastructure, and the placing of the workload corresponds to placing the workload in the cloud infrastructure.

11. The method of claim 10 , wherein the method is scalable such that the placement of the workload is based, at least in part, on one or more dimensions along which a vector can grow.

12. The method of claim 11 , wherein the vector includes metric dimensions corresponding to one or more of an input / output (IO) metric, a central processing unit (CPU) metric, and / or a memory metric.

13. The method of claim 12 , wherein the vector is a function of time.

14. The method comprises: obtaining an integrated time series data signal corresponding to the workload; 14. The method of claim 13, further comprising: analyzing the integrated time series data signal and comparing the integrated time series data signal to a target bin total to determine whether further efficiencies can be gained through elasticization to reduce waste.

15. The method comprises: further comprising making the target bin elastic; The method of claim 14 , wherein the target bin corresponds to a node in a cloud configuration.

16. The method of claim 15 , wherein the migration service is cloud-based.

17. A program causing one or more processor devices to execute the method according to any one of claims 9 to 16.