KR102106223B1 - Method and device of cloud orchestration based in openstack - Google Patents

Abstract

A cloud orchestration method and a cloud orchestration device are disclosed. An open stack-based cloud orchestration method according to an embodiment of the present invention is linked to a request to generate a template script, classifying user requirements included in the creation request, and classifying the user requirements as functional requirements If it does, creating a shell script for a selection item determined by a selection requirement (Option PR) belonging to the functional requirement, and generating a template script that executes the shell script, the hit received the template script In an orchestrator, a virtual machine (VM) that implements the functional requirements may be driven.

Description

Method and device for cloud orchestration based on open stack {METHOD AND DEVICE OF CLOUD ORCHESTRATION BASED IN OPENSTACK}

The present invention is an open source cloud platform OpenStack (OpenStack) environment, the device for automating the construction of a cloud environment OpenStack Heat Orchestrator (OpenStack Heat Orchestrator) and the template script used in this OpenStack Heat Orchestrator, the user needs It relates to an open-stack-based cloud orchestration method and device, which is automatically generated according to the requirements.

Conventionally, only the method of utilizing the service in the orchestration for the entire cloud, the profiling technique required to orchestrate the service itself, and the orchestration method of integrating each virtual resource are limitedly described.

For example, in Korean Publication No. 2016-0118708A (2016-10-12) 'Service Orchestration System and Method in a Distributed Cloud Environment', service orchestration for providing services required by a service provider by integrating network resources distributed in a cloud network Systems and methods are disclosed.

In addition, in Korean Publication No. 2017-0016962A (2017-02-14), 'Automated Service Profiling and Orchestration', service orchestration profiles are distributed among nodes and hierarchically related to each other, thereby determining desired services and desired services. It has been illustrated to process information in service orchestration profiles to use the information to implement them.

Therefore, in order to be differentiated from the conventionally disclosed inventions, a technique for automatically generating a script operating in a heat orchestrator, an orchestration service that supports automation of platform construction in an open stack environment, is required.

According to an embodiment of the present invention, a user's requirements are classified into functional / non-functional requirements, and the object of the template script is automatically generated to easily generate a script that operates in a heat orchestrator.

In addition, the embodiment of the present invention, based on user requirements, presents an architecture and a process for automatically generating a heat orchestration template, and through the heat orchestration template generated using the process, several necessary for building a cloud environment Another goal is to enable automation of resource creation and configuration.

An open stack-based cloud orchestration method according to an embodiment of the present invention is linked to a request to generate a template script, classifying user requirements included in the creation request, and classifying the user requirements as functional requirements If it does, creating a shell script for a selection item determined by a selection requirement (Option PR) belonging to the functional requirement, and generating a template script that executes the shell script, the hit received the template script In an orchestrator, a virtual machine (VM) that implements the functional requirements may be driven.

In addition, the open-stack-based cloud orchestration device according to an embodiment of the present invention, in conjunction with a request to create a template script, a classification unit to classify user requirements included in the creation request, functional requirements for the user requirements In the case of classifying as, when creating a script that creates a shell script for a selection item determined by a selection requirement belonging to the functional requirement, and a template script that executes the shell script, the hit ok that receives the template script It can be configured to include a generator that allows a VM that implements the functional requirements to run on a strator.

According to an embodiment of the present invention, by classifying user requirements into functional / non-functional requirements, the contents to be entered into the template script are automatically generated, so that a script operating in the heat orchestrator can be easily generated.

In addition, according to an embodiment of the present invention, based on user requirements, to present an architecture and process for automatically generating a heat orchestration template, and through the heat orchestration template generated using the process, to build a cloud environment You can automate the creation and configuration of multiple required resources.

1 is a block diagram showing an internal configuration of a cloud orchestration device according to an embodiment of the present invention.
2 is a view for explaining an overview of the system architecture related to the cloud orchestration device according to the present invention.
3 is a view for explaining an automated process for creating a template according to the present invention.
4A to 4C are diagrams illustrating template scripts generated according to the present invention.
5 is a flowchart illustrating a procedure of a cloud orchestration method according to an embodiment of the present invention.

Hereinafter, embodiments will be described in detail with reference to the accompanying drawings. However, various changes may be made to the embodiments, and the scope of the patent application right is not limited or limited by these embodiments. It should be understood that all modifications, equivalents, or substitutes for the embodiments are included in the scope of rights.

The terms used in the examples are used for illustrative purposes only and should not be construed as limiting. Singular expressions include plural expressions unless the context clearly indicates otherwise. In this specification, the terms "include" or "have" are intended to indicate the presence of features, numbers, steps, actions, components, parts or combinations thereof described herein, one or more other features. It should be understood that the existence or addition possibilities of fields or numbers, steps, operations, components, parts or combinations thereof are not excluded in advance.

Unless otherwise defined, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by a person skilled in the art to which the embodiment belongs. Terms, such as those defined in a commonly used dictionary, should be interpreted as having meanings consistent with meanings in the context of related technologies, and should not be interpreted as ideal or excessively formal meanings unless explicitly defined in the present invention. Does not.

In addition, in the description with reference to the accompanying drawings, the same reference numerals are assigned to the same components regardless of reference numerals, and redundant descriptions thereof will be omitted. In describing the embodiments, when it is determined that detailed descriptions of related well-known technologies may unnecessarily obscure the subject matter of the embodiments, detailed descriptions thereof will be omitted.

1 is a block diagram showing an internal configuration of a cloud orchestration device according to an embodiment of the present invention.

Referring to FIG. 1, according to an embodiment of the present invention, the cloud orchestration device 100 may include a classification unit 110, a creation unit 120, and a generation unit 130. Further, according to an embodiment, the cloud orchestration device 100 may be configured by selectively adding the processing unit 140.

First, the classifying unit 110 classifies user requirements included in the creation request by interworking with the creation request of the template script. That is, the classification unit 110 may perform a function of determining whether the user requirements are functional requirements or non-functional requirements.

Functional requirements relate to functional requirements that the system must have, such as in 'machinery and control', heating control, freezer control, boiler control, lighting control, air conditioning control, blind control, cooling control, power It can be defined as requirements such as control.

Non-functional requirements are related to external requests for access to the system, and can be defined as requirements such as the total number of devices, the number of VM access personnel, reaction time, and availability of high availability.

When classifying the user requirements as functional requirements, the composition unit 120 creates a shell script for selection items determined by the selection requirements (Option PR) belonging to the functional requirements. That is, the writing unit 120 may serve to write a shell script included in a template script for driving a virtual machine (VM) in units of selection items.

The selection requirement may refer to a function required by a user to select and select. For example, a user who wants to monitor a customer visiting through an elevator can select 'elevator', 'remote meter reading', and 'visitor management' as the above selection requirements, and include these selection requirements to satisfy functional requirements. You can ask.

Subsequently, the creating unit 120 creates a shell script for each of the selection requirements, for example, in the above-described example, 'elevator.sh', 'remote meter reading.sh', and 'visitor management' by the operation of the application. You can write a shell script called sh '.

According to an embodiment, the preparation unit 120 may analyze a selection item determined by the selection requirement, and identify a common item of a common requirement (Common PR) to be determined according to the analysis result. That is, the creation unit 120 may serve to determine a common item to be operated in connection with the selected item.

As in the above-described example, when 'elevator', 'remote meter reading', and 'visitor management' are selected as the selection requirements, the composer 120 interprets these selection items and performs the functions of the selection items The 'mechanical and control' related to heating control and freezer control, which are essential for the purpose, and 'BMES' for energy consumption analysis and energy evaluation can be identified as common items.

Thereafter, the creating unit 120 may create a shell script for the identified common item. That is, the creation unit 120 can create a shell script in units of a common item in addition to creating a shell script in units of a selected item. For example, the creation unit 120 may create a shell script 'Common.sh' including the identified common items 'machinery and control' and 'BMES'.

When a selection item is not determined by the selection requirement, the creation unit 120 may identify a basic common item in a predetermined common requirement and create a shell script for the basic common item. That is, as the user 120 does not select a separate selection item, the creation unit 120 may create a shell script for a basic common item determined in advance. For example, if the user requirements are interpreted as management for a building, the creation unit 120 may identify basic common items including 'light control', 'power control', and the like, and create a related shell script.

Alternatively, when the selection item selected by the user is an unspecified item, the creation unit 120 may create a predetermined basic common item as a shell script. For example, if the selected item selected by the user is 'theft monitoring', but the corresponding item is not yet defined, the preparation unit 120 includes basics including 'integrated control', 'alarm management', and the like most similar to 'theft monitoring'. By identifying common items, you can write related shell scripts.

The generator 130 generates a template script that executes the shell script, so that a VM implementing the functional requirements is driven by a hit orchestrator that has received the template script. Here, the template script may be a command or a command syntax for realizing user requirements in a virtual environment through an orchestrator.

That is, the generator 130 may serve to generate a template script that directly executes the shell script.

According to an embodiment, the cloud orchestration device 100 of the present invention may be configured to include a processing unit 140 that changes performance in a VM according to non-functional requirements.

When classifying the user requirements as non-functional requirements, the processing unit 140 assigns weights matching each of the 'total number of devices', 'VM access number', and 'reaction time' belonging to the non-functional requirements. , It is extracted from the table, and the extracted weights are added for each disk weight, RAM weight, and vCPU weight. That is, the processing unit 140 calculates the disk weight, the RAM weight, and the vCPU weight for each of the 'total number of devices', 'the number of VM access persons', and 'reaction time', and then the disk weight, the RAM weight, and the vCPU It can serve to add up by weight.

For example, the processing unit has a disk weight (x_d) 2, a RAM weight (x_r) 1, a vCPU weight (x_c) 1 at 'total number of devices (x)' 0 <x <= 10, and a 'VM access number (y) Disk weight (y_d) 2 at 0 <y <= 10, RAM weight (y_r) 1, vCPU weight (y_c) 1, and disk weight (z_d) 1 at 'reaction time (z)' z = low RAM weight (z_r) 3, vCPU weight (z_c) 3, 5 (2 + 2 + 1) summing disk weights, 5 (1 + 1 + 3) summing RAM weights, and 5 summing vCPU weights (1 + 1 + 3).

In addition, the processing unit 140 checks the disk capacity, RAM capacity, and vCPU capacity corresponding to the summed values from the table, and the performance for the VM is considered in consideration of the identified disk capacity, RAM capacity, and vCPU capacity. Can be changed.

That is, the processor 140 may check the number of devices corresponding to each of the disk weight, RAM weight, and vCPU weight calculated from the VM performance mapping table different from the weight value, and change and adjust the VM through this.

In the above example, since the sum of the disk weights is 5, the processor 140 may change the VM by determining the disk capacity '1 GB' corresponding to 4 <x_d + y_d + z_d <= 8. In addition, since the sum of the RAM weights is 5, the processor 140 may change the VM by determining '2 GB' of RAM corresponding to 5 <= x_r + y_r + z_r <10. In addition, since the sum of the vCPU weights is 5, the processor 140 may change the VM by determining the vCPU '1 core' corresponding to 5 <= x_c + y_c + z_c <10.

In addition, the processing unit 140 confirms whether or not to activate the 'high availability support' belonging to the non-functional requirements, and confirms the activation of the 'high availability support', by adding an autoscaling module to the VM, the A specific function in the VM can be implemented by an autoscaling module.

Here, auto-scaling may be defined as a technique for setting a predetermined number of resources to increase when traffic occurs according to a policy predefined by a user. That is, autoscaling may mean a service that monitors real-time usage of CPU and traffic and automatically expands or contracts instances according to a predetermined policy.

That is, the processing unit 140 may operate the VM by adding an auto-scaling module as the user confirms that the user wants to use the 'high availability resource' by the non-functional requirement.

Through this, the VM can support a stable service as resources such as a server, storage, and network are automatically increased through autoscaling as needed.

In addition, the processing unit 140, the 'total number of devices', the 'number of VM access personnel', and the 'reaction time', the first data value exceeding the set limit value is divided by 1/2, and the division For each of the obtained first data values, load balancing may be processed.

Here, when the processing limit is reached, load balancing may mean distributing the load and processing at the same time by multiple servers.

For example, when the 'total number of devices' exceeds the limit value of 50 and is 70, the processing unit 140 defines the 'total number of devices' 70 as a first data value and adds a load balancing function to obtain the first data 70. By dividing by 1/2, the disk weight is extracted for each of the 'total devices' 35 and 35 to determine the degree of VM change.

In addition, the processing unit 140 may maintain, during the load balancing process, a second data value below the threshold among the 'total number of devices', the 'number of VM access persons', and the 'reaction time'.

In the above example, excluding the 'total number of devices' exceeding the limit value, the 'number of VM access personnel' and the 'reaction time' below the limit value may be defined as second data values. When determining the degree of VM change for the load-balanced 'total number of devices' 35, the processing unit 140 may maintain the 'number of VM accesses' and 'reaction time' to be calculated.

According to an embodiment of the present invention, by classifying user requirements into functional / non-functional requirements, the contents to be entered into the template script are automatically generated, so that a script operating in the heat orchestrator can be easily generated.

In addition, according to an embodiment of the present invention, based on user requirements, to present an architecture and process for automatically generating a heat orchestration template, and through the heat orchestration template generated using the process, to build a cloud environment You can automate the creation and configuration of multiple required resources.

2 is a view for explaining an overview of the system architecture related to the cloud orchestration device according to the present invention.

As shown in FIG. 2, the cloud orchestration device identifies the user using the keystone (210).

User requirements can be broadly classified into functional requirements and non-functional requirements. Functional requirements are divided into common and optional functions again, and common functions have applications that perform basic operations that the system should have, and optional functions may additionally refer to functions required by the user.

In addition, the cloud orchestration device may include a Template resource mapping table (220).

The cloud orchestration device can be added to the template script by mapping the application through the Template table so that the common and optional functions can be used in the VM when the user adds the optional functions.

Non-functional requirements are delivered to the template table by calculating the weight for each requirement, and the cloud orchestration device can change the template script through the corresponding template table to determine the RAM, disk capacity, CPU, etc. for the VM to operate.

In addition, the cloud orchestration device may generate a template file (.yami) based on user requirements (230). In other words, the cloud orchestration device can finally generate a template script in .yaml format.

The generated template file is transferred to the heat orchestrator 240, and the heat orchestrator can create a VM based on the transmitted information. Each module of Keystone (241), Glance (242), Neutron (243), Octavia (244), and Senlin (245) executes each operation according to the command of the heat orchestrator (240).

The Keystone 241 is an authentication management module, and matches a user and a project through a keypair, and can execute an operation to determine which user and which project the corresponding VM will run.

The Glance 242 is an image management module, and may perform an operation of providing an image to be mounted on a VM in Nova by transferring an image that the user currently decides to use to the Nova module. Here, Nova is a computing module in which a VM is created and managed. When a VM is created and a VM is used in an emulator environment, the VM can be shown to a user through a Qemu emulator that is basically installed.

Neutron (243) is a network management module for software network services, and determines the network to manage multiple VMs. VMs created in the private network connect to the external Internet to perform operations that users can use. Can be.

Octavia (244) is a load balancer management module for load balancing of the OpenStack platform, which checks the status and traffic of VMs through a health monitor and prevents excessive traffic to one VM with listeners assigned to each VM. You can perform the operation.

Senlin 245 is an autoscaling management module for the clustering service of the OpenStack platform. When autoscaling occurs, a message may be sent to a user and each module to recognize a change.

3 is a view for explaining an automated process for creating a template according to the present invention.

3, the cloud orchestration device of the present invention issues a token through a service UI login (310). That is, the cloud orchestration device can handle user authentication in the application.

In addition, the cloud orchestration device receives user requirements from the service UI (320). For example, the cloud orchestration device may receive user requirements regarding control processing desired by the user through a terminal in which a token is issued and the user is authenticated.

Thereafter, the cloud orchestration device analyzes the requirements through the mapping table (330). The cloud orchestration device may identify processing contents in the mapping table corresponding to the input user requirements.

As a process of the analysis, the cloud orchestration device checks whether the user selects Optional Requirement (340). If the selection is confirmed in step 340 (yes direction), the cloud orchestration device may add the installation resource through the function-application mapping (342).

If the selection is not confirmed in step 340 (No direction), the cloud orchestration device checks whether the user selects the high availability support as another process of the analysis (350). If the selection is confirmed in step 350 (yes direction), the cloud orchestration device may add an Auto Scaling resource (352).

If the selection is not confirmed in step 350 (No direction), the cloud orchestration device checks whether the user requirement exceeds the system allowable specification (360) as another process of the analysis. If the selection is confirmed in step 360 (yes direction), the cloud orchestration device may add a load balancer resource (362).

Subsequently, the cloud orchestration device generates a template file (.Yami) including resources for requirements analysis contents (370). That is, the cloud orchestration device may identify the processing content by the mapping table and generate a template script according to the identified processing content.

In addition, the cloud orchestration device transmits the template file (.Yami) generated by the heat orchestrator to create a VM (380).

Through this, the cloud orchestration device checks the IoT development framework and the service according to user requirements in the created VM (390).

Hereinafter, a method of automatically constructing a cloud environment using the OpenStack Heat Orchestrator presented in the present invention will be described by applying it to an example of an IoT smart building.

The cloud orchestration device of the present invention can generate a template script according to functional requirements.

Functional requirements can be classified into common requirements (Common PR) and optional requirements (Optional PR) as shown in Table 1.

Since the common requirements are requirements that must be configured in common in all IoT environments, the same application can be applied. The selection requirement is to select an additional required requirement in building an IoT environment, and only the application related to the user requirement can be applied.

Table 1 illustrates the functional requirements classification.

For example, assuming that the user selects the elevator management, remote meter reading, and visitor management functions among the optional PRs, the application for common requirements is installed by default, so that the shell script of common.sh can be executed. In addition, the cloud orchestration device can additionally configure template scripts to execute shell scripts called elevator.sh, remote meter reading.sh, and visitor management.sh for optional requirements.

Table 2 shows the mapping table of functional requirements.

In addition, the cloud orchestration device may generate a template script according to non-functional requirements.

As non-functional requirements, the total number of devices, the number of VM access personnel, response time, and availability of high availability were defined. These requirements can be selected by the user.

Tables 3 to 5 below are requirements-weighted mapping tables for disk capacity, RAM, and vCPU. Specifically, Table 3 is a mapping table for calculating the weight for each total device, Table 4 is a mapping table for calculating the weight for each VM access, and Table 5 is a mapping table for calculating the weight by response speed importance. In Tables 3 to 5, since the RAM and vCPU have a greater influence on the response time than the total number of devices and the number of VM accesses, the weight value can be given larger.

For example, if the requirement for the total number of devices (x) is '40', the cloud orchestration device according to Table 3, disk weight (x_d) '8', RAM weight (x_r) '4', vCPU weight ( x_c) '4' can be added.

In addition, if the requirement for the number of VM access (y) is '60', the cloud orchestration device according to Table 4, disk weight (y_d) '6', RAM weight (y_r) '3', vCPU weight (y_c) '3' can be added.

In addition, if the requirement for the response time (response rate importance (z)) is 'medium', the cloud orchestration device according to Table 5, Disk weight (z_d) '2', RAM weight (z_r) '6', vCPU weight (z_c) '6' can be added.

Based on the weight value calculated as described above, the cloud orchestration device may determine a flavor defining an OpenStack VM performance type.

Table 6 illustrates a VM performance mapping table according to weight values.

That is, the cloud orchestration device can sum the extracted weights for each Disk weight, RAM weight, and vCPU weight, and check the Disk capacity, RAM capacity, and vCPU capacity corresponding to the summed values from the table in Table 6. Accordingly, the cloud orchestration device may change the performance of the VM in consideration of the identified disk capacity, RAM capacity, and vCPU capacity.

For example, the cloud orchestration device corresponds to '16', which is the sum of the disk weights 'x_d 8 y_d 6 z_d 2' identified from Tables 3 to 5 for each of the total number of devices, the number of VM accesses, and the response time. You can change the performance of the VM by adding an additional '4 GB' of disk capacity.

In addition, the cloud orchestration device corresponds to the '13' sum of the RAM weights 'x_r 4 y_r 3 z_r 6' identified from Tables 3 to 5 for each of the total number of devices, the number of VM accesses, and the response time. You can change the performance of the VM by adding an additional '4 GB' of RAM.

In addition, the cloud orchestration device corresponds to '13' sum of the vCPU weights 'x_c 4 y_c 3 z_c 6' identified from Tables 3 to 5 for each of the total number of devices, the number of VM accesses, and the response time. You can change the performance of the VM by adding more vCPU '2 Core'.

If there is a requirement for high availability, the cloud orchestration device can be designed to add an Auto Scaling module to automatically add VMs by operating when more traffic is expected than the acceptable traffic.

 In addition, if the disk weight, RAM weight, and vCPU weight exceed the values in the corresponding mapping table table, and a specification higher than the highest flavor is required, the cloud orchestration device can create two or more VMs and deploy the Load Balancer. .

For example, assuming that the weight of the currently calculated disk capacity is 40, the cloud orchestration device may generate two VMs corresponding to each weight 20 by setting the disk capacity for each VM to be the same. At this time, in order to prevent traffic from being concentrated on only one VM, the cloud orchestration device may add a load balancer function.

Tables 7 to 9 show the results of calculating the disk, RAM, and vCPU performance calculated through the mapping table when the user selects a non-functional requirement.

Table 7 summarizes the results extracted by matching the user's non-functional requirements to the matching table through Tables 3 to 6 described above. According to Table 7, the cloud orchestration device adds Disk capacity '4GB', RAM '4GB', and vCPU '2 Core' to change the performance of the VM while adding the Auto Scaling function.

If, in the results shown in Table 7, the total number of devices is increased to 70, the cloud orchestration device, as the increased '70' exceeds the limit of '50', the total number of devices (x) as the first data value Can be defined. In addition, the cloud orchestration device may define the number of VM access persons (y) and the response time (z) that do not exceed the limit as second data values.

The cloud orchestration device load-balances the total number of devices (x), which is the first data value, to create two VMs for each of '35', which is divided by half of the existing '70'. Can be. At this time, the second data value, the number of VM access personnel (y) and the reaction time (z) are maintained during the load balancing process.

Table 8 illustrates a mapping table when the total number of devices (x) exceeds a limit, and Table 9 illustrates creating a plurality of VMs according to Load Balancing processing.

As shown in Table 9, the cloud orchestration device, for the total number of load-balanced devices (x) '35', according to Table 3 above, Disk weight (x_d) '6', RAM weight (x_r) '3 By checking ', vCPU weight (x_c)' 3 'newly, it is possible to check the disk capacity, RAM, and vCPU added to the two created VMs.

4A to 4C are diagrams illustrating template scripts generated according to the present invention.

FIG. 4A shows an example of setting a flavor among template script files, and FIG. 4B shows an example of adding auto scaling among template script files, and FIG. 4C shows load balancer among template script files. The area to be described is shown as an example.

4A to 4C, template script files in the generated .yaml format are illustrated. The template script file may be a script file generated according to a user's functional / non-functional requirements.

The template script file illustrated in FIGS. 4A to 4C shows script resources that are mainly changed in the current system.

For example, the OS :: Nova :: Flavor resource of FIG. 4A can determine the ram capacity, disk capacity, and number of CPUs of the VM that is finally calculated by calculating weights for the number of devices, access personnel, and response time among non-functional requirements. .

OS :: Heat :: AutoScailingGroup of FIG. 4B is a resource used when auto scaling is supported, and indicates an initial state of a VM that is auto-scaling by specifying a VM therein, and uses OS :: Heat :: ScailingPolicy resource. To specify the point at which the auto scale will operate.

4C OS :: Octavia :: LoadBalancer is a resource used when multiple VMs are created at once, and checks traffic allocated to the current VM through OS :: Octavia :: HealthMonitor and OS :: Octavia :: Listener. , You can properly allocate the traffic to each VM connected through OS :: Octavia :: Pool.

When the finally created template script file is input to Heat Orchestrator, the cloud orchestration device creates and connects VMs and other resources (Auto Scaling, Load Balancer), and then distributes the VM to the user. The user who has been assigned a VM can manage the smart building by using the function according to the requirements entered using the VM.

Hereinafter, the operation flow of the cloud orchestration device 100 according to embodiments of the present invention will be described in detail in FIG. 5.

5 is a flowchart illustrating a procedure of a cloud orchestration method according to an embodiment of the present invention.

The cloud orchestration method according to the present embodiment may be performed by the cloud orchestration device 100 described above.

First, the cloud orchestration device 100 classifies a user requirement included in the creation request by interworking with the request for generating the template script (510). Step 510 may be a process of determining whether a user requirement is a functional requirement or a non-functional requirement.

Functional requirements relate to functional requirements that the system must have, such as in 'machinery and control', heating control, freezer control, boiler control, lighting control, air conditioning control, blind control, cooling control, power It can be defined as requirements such as control.

Non-functional requirements are related to external requests for access to the system, and can be defined as requirements such as the total number of devices, the number of VM access personnel, reaction time, and availability of high availability.

When the user requirement is classified as a functional requirement, the cloud orchestration device 100 creates a shell script for a selection item determined by a selection requirement (Option PR) belonging to the functional requirement (520). Step 520 may be a process of writing a shell script included in a template script for driving a virtual machine (VM) in units of selection items.

The selection requirement may refer to a function required by a user to select and select. For example, a user who wants to monitor a customer visiting through an elevator can select 'elevator', 'remote meter reading', and 'visitor management' as the above selection requirements, and include these selection requirements to satisfy functional requirements. You can ask.

Subsequently, the cloud orchestration device 100 creates a shell script for each of the selection requirements, for example, in the above example, by the operation of the application, 'elevator.sh', 'remote meter reading.sh', 'visitor management You can write a shell script called .sh '.

According to an embodiment, the cloud orchestration device 100 may analyze a selection item determined by the selection requirement, and identify a common item of a common requirement (Common PR) to be determined according to the analysis result. . That is, the cloud orchestration device 100 may serve to determine a common item to be operated in association with the selected item.

As in the above example, when 'elevator', 'remote meter reading', and 'visitor management' are selected as the selection requirements, the cloud orchestration device 100 interprets these selection items and performs the functions of the selection items The 'mechanical and control' for heating control and freezer control, and the 'BMES' for energy consumption analysis and energy evaluation can be identified as common items.

Thereafter, the cloud orchestration device 100 may create a shell script for the identified common items. That is, the cloud orchestration device 100 can create a shell script of a common item unit as well as a shell script of a selected item unit. For example, the cloud orchestration device 100 may create a shell script 'Common.sh' including the identified common items 'machinery and control' and 'BMES'.

If the selection item is not determined by the selection requirement, the cloud orchestration device 100 may identify a basic common item in a predetermined common requirement and create a shell script for the basic common item. That is, the cloud orchestration device 100 may create a shell script for a basic common item determined in advance, as the user does not select a separate selection item. For example, if the user requirements are interpreted as management for a building, the cloud orchestration device 100 may identify basic common items including 'light control', 'power control', and the like, and create a related shell script.

Alternatively, when the selection item selected by the user is an unspecified item, the cloud orchestration device 100 may create a predetermined basic common item as a shell script. For example, if the selected item selected by the user is 'theft monitoring', but the corresponding item is not yet specified, the cloud orchestration device 100 includes 'integrated control', 'alarm management', and the like most similar to 'theft monitoring'. By identifying the basic common items, you can write related shell scripts.

Subsequently, the cloud orchestration device 100 generates a template script that executes the shell script (530), so that a VM implementing the functional requirements is driven by a heat orchestrator that has received the template script. Here, the template script may be a command or a command syntax for realizing user requirements in a virtual environment through an orchestrator.

Step 530 may be a process of generating a template script that directly executes the shell script.

According to an embodiment, the cloud orchestration device 100 may perform processing for changing performance in the VM according to non-functional requirements.

Accordingly, when the cloud orchestration device 100 classifies the user requirements as non-functional requirements, each of the 'total number of devices', 'the number of VM access persons', and 'reaction time' belonging to the non-functional requirements The weights matched to, are extracted from the table, and the extracted weights are added for each Disk weight, RAM weight, and vCPU weight.

That is, the cloud orchestration device 100 calculates the disk weight, the RAM weight, and the vCPU weight for each of the 'total number of devices', 'the number of VM access persons', and 'reaction time', thereby calculating the disk weight, RAM weight, And vCPU weighting.

For example, the cloud orchestration device 100 has a disk weight (x_d) 2, a RAM weight (x_r) 1, a vCPU weight (x_c) 1 at 'total number of devices (x)' 0 <x <= 10, and a 'VM access Disk weight (y) '0 <y <= 10 Disk weight (y_d) 2, RAM weight (y_r) 1, vCPU weight (y_c) 1, and' Reaction time (z) 'Disk weight at z = low (z_d) 1, RAM weight (z_r) 3, vCPU weight (z_c) 3, 5 (2 + 2 + 1) summing the disk weight, 5 (1 + 1 + 3) summing the RAM weight, and vCPU We can get 5 (1 + 1 + 3) which sums the weights.

In addition, the cloud orchestration device 100 checks the disk capacity, RAM capacity, and vCPU capacity corresponding to the sum, respectively, from the table, and considers the identified disk capacity, RAM capacity, and vCPU capacity to the VM. Performance can be changed.

That is, the cloud orchestration apparatus 100 may check the number of devices corresponding to each of the disk weight, RAM weight, and vCPU weight calculated in the VM performance mapping table different from the weight value, and change and adjust the VM through this.

In the above example, since the sum of the disk weights is 5, the cloud orchestration device 100 may change the VM by determining the disk capacity '1 GB' corresponding to 4 <x_d + y_d + z_d <= 8. In addition, since the sum of the RAM weights is 5, the cloud orchestration device 100 may change the VM by determining the RAM '2 GB' corresponding to 5 <= x_r + y_r + z_r <10. In addition, since the sum of the vCPU weights is 5, the cloud orchestration device 100 may change the VM by determining the vCPU '1 core' corresponding to 5 <= x_c + y_c + z_c <10.

In addition, the cloud orchestration device 100, by confirming whether the activation of the 'high availability support' belonging to the non-functional requirements, and confirming the activation of the 'high availability support', by adding an autoscaling module to the VM , The specific function in the VM may be implemented by the autoscaling module.

Here, auto-scaling may be defined as a technique for setting a predetermined number of resources to increase when traffic occurs according to a policy predefined by a user. That is, autoscaling may mean a service that monitors real-time usage of CPU and traffic and automatically expands or contracts instances according to a predetermined policy.

The cloud orchestration device 100 may run an VM by adding an autoscaling module as the user confirms that the user wants to use the 'high availability resource' by non-functional requirements.

Through this, the VM can support a stable service as resources such as a server, storage, and network are automatically increased through autoscaling as needed.

In addition, the cloud orchestration device 100 divides the first data value exceeding a set threshold value by 1/2 among the 'total number of devices', the 'number of VM access persons', and the 'reaction time', For each of the divided first data values, load balancing may be processed.

Here, when the processing limit is reached, load balancing may mean distributing the load and processing at the same time by multiple servers.

For example, when the 'total number of devices' exceeds the limit value of 50 and is 70, the cloud orchestration device 100 defines the 'total number of devices' 70 as a first data value and adds a load balancing function, so that the first data By dividing 70 by 1/2, the disk weights can be extracted for each of the 'total number of devices' 35 and 35 to determine the degree of VM change.

In addition, the cloud orchestration device 100, during the processing of the load balancing, the second data value below the threshold value among the 'total number of devices', the 'number of VM access persons', and the 'reaction time', Can be maintained.

In the above example, excluding the 'total number of devices' exceeding the limit value, the 'number of VM access personnel' and the 'reaction time' below the limit value may be defined as second data values. The cloud orchestration device 100 may be calculated by maintaining the 'number of VM access personnel' and 'reaction time' as it is when determining the degree of VM change for the load-balanced 'total number of devices' 35.

According to an embodiment of the present invention, by classifying user requirements into functional / non-functional requirements, the contents to be entered into the template script are automatically generated, so that a script operating in the heat orchestrator can be easily generated.

In addition, according to an embodiment of the present invention, based on user requirements, to present an architecture and process for automatically generating a heat orchestration template, and through the heat orchestration template generated using the process, to build a cloud environment You can automate the creation and configuration of multiple required resources.

The method according to the embodiment may be implemented in the form of program instructions that can be executed through various computer means and recorded on a computer-readable medium. The computer-readable medium may include program instructions, data files, data structures, or the like alone or in combination. The program instructions recorded in the medium may be specially designed and configured for the embodiments or may be known and usable by those skilled in computer software. Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tapes, optical media such as CD-ROMs, DVDs, and magnetic media such as floptical disks. -Hardware devices specifically configured to store and execute program instructions such as magneto-optical media, and ROM, RAM, flash memory, and the like. Examples of program instructions include high-level language codes that can be executed by a computer using an interpreter, etc., as well as machine language codes produced by a compiler. The hardware device described above may be configured to operate as one or more software modules to perform the operations of the embodiments, and vice versa.

The software may include a computer program, code, instruction, or a combination of one or more of these, and configure the processing device to operate as desired, or process independently or collectively You can command the device. Software and / or data may be interpreted by a processing device, or to provide instructions or data to a processing device, of any type of machine, component, physical device, virtual equipment, computer storage medium or device. , Or may be permanently or temporarily embodied in the transmitted signal wave. The software may be distributed over networked computer systems, and stored or executed in a distributed manner. Software and data may be stored in one or more computer-readable recording media.

As described above, although the embodiments have been described with limited drawings, those skilled in the art may apply various technical modifications and variations based on the above. For example, the described techniques are performed in a different order than the described method, and / or the components of the described system, structure, device, circuit, etc. are combined or combined in a different form from the described method, or other components Alternatively, even if substituted or substituted by equivalents, appropriate results can be achieved.

Therefore, other implementations, other embodiments, and equivalents to the claims are also within the scope of the following claims.

100: cloud orchestration device
110: classification unit 120: preparation unit
130: generating unit 140: processing unit

Claims (14)

In the cloud orchestration method implemented by an open stack-based cloud orchestration device,
Classifying a user requirement included in the creation request in association with a request for creating a template script in the classification unit within the cloud orchestration device;
When the user requirements are classified as functional requirements,
Creating a shell script for a selection item determined by a selection requirement (Option PR) belonging to the functional requirement in the creation unit in the cloud orchestration device;
In the cloud orchestration device generating unit, by generating a template script that executes the shell script, a virtual machine (VM) that implements the functional requirements is driven by a heat orchestrator that receives the template script. To do;
When the user requirements are classified as non-functional requirements,
An extraction step of extracting a weight matching each of the 'total number of devices', 'the number of VM access persons', and 'reaction time' belonging to the non-functional requirements from the processing unit in the cloud orchestration device;
A checking step of summing the extracted weights for each disk weight, RAM weight, and vCPU weight, and checking the disk capacity, RAM capacity, and vCPU capacity corresponding to the summed values from the table; And
In the processing unit, a change step of changing the performance of the VM in consideration of the checked disk capacity, RAM capacity, and vCPU capacity
Cloud orchestration method based on OpenStack, including. According to claim 1,
The step of writing the shell script,
Interpreting a selection item determined by the selection requirement;
Identifying a common item of a common requirement (Common PR) to be determined according to the analysis result; And
Creating a shell script for the above common items
Cloud orchestration method based on OpenStack, including. According to claim 1,
The step of writing the shell script,
If the selection item is not determined by the above selection requirements,
Identifying basic common items within predetermined common requirements; And
Creating a shell script for the above common items
Cloud orchestration method based on OpenStack, including. delete According to claim 1,
After the change step,
Checking whether the 'high availability support' belonging to the non-functional requirement is activated in the processing unit; And
When the processing unit confirms activation of the 'high availability support', adding an auto-scaling module to the VM, so that a specific function in the VM is implemented by the auto-scaling module.
Cloud orchestration method based on OpenStacks further comprising. According to claim 1,
Before the extraction step,
Dividing, by the processing unit, the first data value exceeding a set threshold among the 'total number of devices', the 'number of VM access persons', and the 'reaction time' by 1/2; And
In the processing unit, for each of the divided first data values, processing a load-balance that independently performs the extraction step, the checking step, and the changing step
Cloud orchestration method based on OpenStacks further comprising. The method of claim 6,
During the step of processing the load balance,
In the processing unit, during the processing of the load balance, maintaining the second data value below the limit among the 'total number of devices', the 'number of VM access persons', and the 'reaction time'
Cloud orchestration method based on OpenStacks further comprising. A classification unit that classifies user requirements included in the generation request in association with a template script generation request;
When classifying the user requirements into functional requirements, a writing unit that creates a shell script for selection items determined by selection requirements belonging to the functional requirements;
A generator configured to generate a template script that executes the shell script, so that a VM implementing the functional requirements is driven by a hit orchestrator that has received the template script; And
When the user requirements are classified as non-functional requirements, weights matching each of the 'total number of devices', 'VM access number', and 'reaction time' belonging to the non-functional requirements are extracted from the table. , Sums the extracted weights for each Disk weight, RAM weight, and vCPU weight, checks Disk capacity, RAM capacity, and vCPU capacity corresponding to the summed values from the table, and checks the checked Disk capacity, RAM Processing unit to change the performance of the VM in consideration of capacity and vCPU capacity
Cloud orchestration device based on the OpenStack, including. The method of claim 8,
The preparation unit,
Interpreting the selection items determined by the selection requirements, identifying the common items of the common requirements to be determined according to the analysis result, and writing a shell script for the common items
OpenStack-based cloud orchestration device. The method of claim 8,
If the selection item is not determined by the above selection requirements,
The preparation unit,
Identify basic common items within predefined common requirements, and write shell scripts for the default common items
OpenStack-based cloud orchestration device. delete The method of claim 8,
The processing unit,
When checking whether or not the 'high availability support' belonging to the non-functional requirements is activated, and confirming the activation of the 'high availability support', by adding an autoscaling module to the VM, in the VM by the autoscaling module To ensure that certain features of
OpenStack-based cloud orchestration device. The method of claim 8,
The processing unit,
Among the 'total number of devices', the 'number of VM access persons', and the 'reaction time', a first data value exceeding a set threshold is divided by 1/2, and for each of the divided first data values , Which handles load balancing
OpenStack-based cloud orchestration device. The method of claim 13,
The processing unit,
Among the 'total number of devices', the 'number of VM access persons', and the 'reaction time', a second data value below the threshold is maintained when processing the load balance.
OpenStack-based cloud orchestration device.

Images