Autonomic computing concentrates on the self-management characteristics of distributed computing resources, in light of unpredictable changes for hiding intrinsic complexity to operators and users   . Meanwhile, data center is a facility used to house computer systems and associated components, such as telecommunications and storage systems. Consequently, cloud data center networks includes redundant or backup power supplies, redundant data communication connections, environmental controls and various security devices. A large data center is the industrial-scale operation used as much electricity as a small town for growing complexity of self-management    .
This paper proposes a service-oriented autonomic cloud computing self-con- figuration method, i.e., MCDN (Model of Autonomic Cloud Data Center Net- works). It divides the self-configuration into structure self-configuration and in- terface self-configuration. Consequently, a dynamic contract network protocol is proposed to solve the self-optimization problem of autonomic cloud computing structure, concerning reference group intelligence   . We introduce the au- tonomic in the traditional contract networks, and develop a dynamic contract network protocol under the algorithm description. The protocol can take full advantage of the previous service matching process of autonomous units under the dynamic environment in autonomic cloud data center networks   .
With the modeling process of autonomic cloud data center networks, a system of autonomic cloud computing is built based on component reuse development process, which is divided into reusable entity layer, autonomous behavior layer, autonomous unit layer and autonomy social layer   . Autonomous unit function development and interactive development organic separation are will- ing to improve autonomous unit function reusability. In the multi-agent envi- ronment, we have developed an autonomous calculation of the prototype system with the hierarchical development, which can provide a good support for the rapid development of autonomic cloud data center networks   .
2. Intelligent Subject in the Cloud
2.1. Intelligent Subject
Intelligent subject and multi-agent system in the subject theory, multi-agent ar- chitecture, with the main body of the software engineering and other aspects have made some research results  . The main body can be used to refer to a particular environment with autonomy, initiative, social ability, responsiveness and other special hardware or software entity.
The reason why the subject’s research is so important is that it can meet the access to the information highway on behalf of people, to solve the information overload and the global scope of the new distributed computing model needs. The main structure of the problem to be solved is what the module by the com- position, how to exchange information between them, how the known informa- tion affects its behavior and its internal state, and how these modules are grouped in software/hardware together to form an organic whole of the main body.
2.2. Autonomous Calculation
The complexity of the computer software system structure and the computer organization structure is increasing. However, it is that the complexity of the computer system itself has become an urgent need to solve the problem.
The autonomy is inspired by the complex autonomic nervous system, which predicts the system’s need in the same way. What is going to be solved is the in- creasingly complex computing environment in the management and cost pro- blems. The important difference between autonomic cloud data center networks and the autonomic nervous system of the human body is that many of the au- tonomy decisions made by the body are unconsciously, and the autonomic cloud computing components of the computer system follow the human make. We build the framework for automatic performance optimization for component- based enterprise applications, as shown in Figure 1.
Achieving autonomic cloud computing is an evolutionary process, which can be divided into five levels with its autonomy maturity:
1) Basic level: The professionals manage each element of the system separately, install, monitor, maintain, uninstall and so on.
2) Management level: System management technology used to collect the scattered system information collected to the console, thus saving the manage- ment, in terms of the time required for the information to be collected and syn- thesized.
3) Forecast level: The use of new technology has a number of elements asso- ciated with the optimal allocation, and gives the administrator providing deci- sion-making advice.
4) Autonomous level: The administrator need release business strategy and objectives. Administrator can monitor business processes and change business strategies.
By focusing on the hotspots of the system, these modules can optimize their system overhead, making the framework suitable for long-running systems.
The self-improvement is different from the traditional optimization method, while the traditional optimization method based on system metrics, such as re- sources availability. According to business objectives, we can get business rules and SLA about how metrics affect business objectives. Once the business rules and service level agreements are defined, the business purpose is defined.
We identify how to design adaptive middleware to support autonomic cloud computing in a pervasive computing environment. The focus of the study is
Figure 1. Autonomic computing in MCDN over data center to the Internet.
when the mobile users in the wireless network environment with different de- vices, how to optimize the network changes connectivity. The goal is to make this change the best, and the application code for the core should be transparent.
There is a framework for the deployment of component-based distributed ap- plications and the implementation of self-management. The initial deployment target is represented by a declarative binding language, which can express the component and host the mapping between the components can also be used to express the interconnection between components of the topology. A constraint solver is used to find the configuration that satisfies the target and is automati- cally deployed.
In the construction of the system or change the system configuration, the op- erator is often easy to make some mistakes. It describes some algorithms that al- low the system to ensure robustness and stability when initializing and changing configurations. They set out a new optimization framework to capture the spe- cific aspects of the system reconfiguration. In a distributed or mobile environ- ment, the connection among sites where the software system is running is often unstable. This method allows the system to monitor connections between nodes when connected self-configuring and self-deploying when lost, increasing the availability of the entire system.
We use dynamic meta-programming to insert transactional recovery code at runtime system. Because this recovery method does not require programmers to intervene, but the dynamic conversion code does, it can greatly simplify the re- covery design and implementation of complex systems. Consequently, we use decision tree learning methods to diagnose large site failures. The method records the run-time attributes of each request, and uses machine learning and data mining techniques to identify the cause of the failure.
The path followed the fault degree of association is given to different levels, and the nodes are merged according to the observed partial ordering of the sys- tem components. The method has a lot of request and run-time information, so as to make statistical analysis meaningful. The systems implemented in this way enable the network to be effective after a failure Restore the network connection.
The recovery simplifies the management in two ways. The first is to reduce the recovery line taken by the recovery the price required for the move, which allows the user to use statistical techniques to fail to capture failures. The second is to simplify the planning and other steps required for troubleshooting.
A self-management system can continue to monitor the own incorrect configu- ration, to prevent the system from being hurt. Although there are many con- straints that can distinguish the correct configuration from the wrong configura- tion, these constraints are rarely recorded down, let alone be effectively used to organize.
For a wide range of network attacks, we propose an on-line monitoring and analysis framework for self-protection. They use the software main body to monitor some of the properties of the system and put all the network and com- puting resources. The software body is to implement the corresponding recovery mechanism. As the peak demand for subscribers is not easy to predict, the current department demand for resources changes. When there is an unpredictable load peak, the system has time to implement the resources. Dynamic peak load protection is used for three technologies: adaptive short term forecasting, online capacity planning capacity planning and configuration management.
3. Autonomic Cloud Data Center Networks Model Framework
3.1. Autonomous Units
We define the autonomous unit as managing the behavior according to the us- er’s policy and interacting with other autonomous units provide a certain ser- vice, i.e., computing power, resources, knowledge. Autonomous units can collect information from the environment, make decisions, and root according to the need to adjust their own, making their own self-configuration, self-repair, self- optimization, self-protection capabilities. But the autonomous unit and the main body also have important differences:
1) Different functions: The main body is in certain environment autonomy of the computing entity, in addition, the autonomous unit must also be able to self- configuration, self-optimization, self-repair and self-protection.
2) Different structure: In order to meet the needs of self-management, auto- nomous units must have a strategy management, complexity analysis and other general body does not have the internal structure.
3) Different life cycle: Autonomous unit has a more complex than the main life cycle.
3.2. Functional Structure
We divide the structure of the autonomous unit into four parts of the shared knowledge function:
1) Monitoring: It is about collection, filtering, management, and reporting in- formation. The above resources in the system should have a unified information source model, making information monitoring and collection easier.
2) Analysis: The complexity lies in the current environment analysis, con- struction system model. This makes autonomous units available to environment to learn, and to help the autonomous unit to predict the future.
3) Planning: In accordance with the strategy and the agreement, it is to build the target sequence of behavior.
4) Implementation: It is about the implementation of the planning in the sequence behavior, and the implementation of process control management.
3.3. Autonomous Unit Mental State
3.3.1. Mental State Model
The belief of the autonomous unit is the most basic element in the mental state of the autonomous unit and the most important element. The state of mind for reasoning and other related issues are based on faith, must rely on faith. The main unit’s belief can often be seen as autonomous knowledge bases, which contain rich content, including basic rational, autonomous units familiar with the field of justice, autonomous units in the field of objective facts and data un- derstanding.
The goal reflects the state or behavior to be achieved, usually because the au- tonomous unit receives a certain strategy, or because of the autonomy of the unit’s own beliefs and standards arising from the goal. So the goal is more with the belief of the autonomous unit, which comes from the outside world and the autonomy of the unit faith. The plan actually describes the autonomy unit belief, the autonomy unit behavioral capability, and the autonomous unit organically linked together, indicating that in a certain state of faith, in order to achieve a certain goal, what kind of behavior will be taken.
3.3.2. Behavioral Competencies
Generally, the capacity of an autonomous unit refers to the ability of the autonomous unit to perform certain actions and to perform certain tasks or function, corresponding to a certain behavioral entity, i.e., functional modules. Thus, the description of the capacity of the autonomous unit actually corresponds to the description of the action in the dynamic description logic, indicates what type of action the autonomous unit can perform and, on the other hand, points out what is going on what kind of results. The representation of the capacity of the autonomous unit is the essential part of the belief for the autonomous unit, but it is more involved in the action of the autonomous unit and the state of change.
In the traditional theory of action and logic programming, generally do not specify the action of the operation of the object. The axiom of action in dynamic description logic includes two aspects, one is to specify under what conditions an action is enforceable over the premise of axiom, the other is to specify a move what will happen when executed in a certain state over the successor state of jus- tice.
3.3.3. Behavioral Planning
When there is a certain goal, the autonomous unit must find an effective way to achieve these goals standard under behavioral planning, and sometimes need to modify existing goals with the reasoning process. In order to complete this reg- ulation planning reasoning, autonomous units can be used in two ways: static planning and dynamic planning.
Dynamic planning is for a certain goal, autonomous units based on their cur- rent state of faith, combined with the autonomy of the unit with the domain of justice and their ability to describe, to find an effective way to achieve goals and ways. Combined with the strategy target planning problem, we can give static planning algorithm and dynamic programming algorithm.
3.4. Composition of the Structure
In order to enable the autonomous unit having the function given and imple- ment the mental state model, autonomous unit should have what kind of inter- nal structure. It is considered when defining the structure of autonomous units the following points:
1) The versatility of the autonomous unit structure: The definition of the internal structure of the autonomous unit is universal on their own structure needs.
2) The autonomy of the composition of the structure of the scalability: The structural scalability makes the autonomous unit can be easily and flexible insert new of the functional modules, without destroying the autonomous unit should have the characteristics.
3) The composition of the structure of the autonomy of the unit interopera- bility support: The interoperability between autonomous units is the autonom- ous unit, since the main computing system has the necessary prerequisite for self-management characteristics.
Consequently, we define the structure of the autonomous unit as shown in Figure 2.
・ Sensor: The autonomous unit senses the external environment through the sensor and collects the required information, in light of the autonomous unit through the function module interface on the external environment.
・ Communicator: In order to improve the interoperability between autonomous units, the single the communication between the elements are based on the mode of message passing.
・ Model construction: the complexity of the current environment analysis, modeling system model.
・ Planning scheduler: A system model based on the model construction mod- ule, it can be used to achieve the goal according to the policy plan, concerning the behavior of the implementation of scheduling operations.
・ Coordination engine: The coordination of the interaction between the various modules, communication and collaboration, maintenance of autonomous unit daily operation, to ensure that main unit is always running.
Figure 2. Architecture of autonomous unit over intelligence from big data.
・ Resource database: It saves the list of autonomous units owned and available resources.
This paper presents functional structure, mental state, service description and composition structure, in terms of constraints made for autonomous units. When an autonomous unit satisfies the above issues, it can be presented as a certain self-management characteristic. This paper also develops the MCDN (Model of Autonomic Cloud Data Center Networks) architecture, in terms of the analysis of the autonomous unit under the interactive mode. Finally, the sys- tem of independent computing side surface has made a useful attempt, given the framework of the autonomic cloud data center networks model for the standardization of independent work to achieve independent software system.
 Gerla, M., et al. (2014) Internet of Vehicles: From Intelligent Grid to Autonomous Cars and Vehicular Clouds. 2014 IEEE World Forum on Internet of Things, New York, March 2014, 241-246.
 Bitam, S., Mellouk, A. and Zeadally, S. (2015) VANET-Cloud: A Generic Cloud Computing Model for Vehicular Ad Hoc Networks. IEEE Wireless Communications, 22, 96-102.
 Yan, Q., et al. (2016) Software-Defined Networking (SDN) and Distributed Denial of Service (DDoS) Attacks in Cloud Computing Environments: A Survey, Some Research Issues, and Challenges. IEEE Communications Surveys & Tutorials, 18, 602-622.
 Gomer, R. and Gerding, E. (2014) Consenting Agents: Semi-Autonomous Interactions for Ubiquitous Consent. Proceedings of the 2014 ACM International Joint Conference on Pervasive and Ubiquitous Computing: Adjunct Publication, 13-17 September 2014, 653-658.