Shulou(Shulou.com)06/01 Report--

I. XAPI's management of resource pool

As a set of management tools for XenServer, XAPI manages the hosts, networks, and storage of XenServer. Whether it's OpenStack or CloudStack, if you use XenServer as the underlying virtualization layer, its calls to XenServer must use XAPI. In the real sense, XAPI mainly provides the interface of XenCenter and the communication of each XenServer host in the resource pool in XenServer.

First of all, the operation requests of all XenServer hosts in the resource pool are passed to Dom0 through XAPI, and the communication between all XenServer hosts in the pool is also passed through XPAI. For example, the database in the resource pool (XenServer configuration database) will be synchronized among all XenServer hosts through XAPI, so that after the resource pool Master goes down, other XenServer hosts can correctly and quickly replace Master and maintain the functions and services of the resource pool. The brief schematic diagram is as follows:

As shown in the figure above, when creating a XenServer resource pool, a XenServer host is selected by default as the Master, the so-called resource pool owner. The role of Master is to coordinate and lock resources within the resource pool. By default, when creating a resource pool, the first XenServer host that joins the resource pool is selected as Master by default. Master can transfer roles when the Master host of the resource pool fails and is no longer available. There are two cases of transfer: one is to transfer manually, and the other is to transfer automatically when the resource pool is highly available.

Although all XenServer hosts in a resource pool have XAPI and run HTTP port 80 and TLS / SSL port 443 on the XML / RPC interface, control operations are only handled on the Master host. If a control action instruction is sent to the Slave host of the resource pool, XAPI on the Slave host will redirect the control instruction to the Master host, and XAPI on the Slave host will generate a XAPI redirect error message and store it in the log. To improve efficiency, the following operations are allowed on the Slave host:

Query performance counters (and host history)

Connect to the VNC console

Import / export (especially when disk on local storage)

Because the Master host acts as a coordination and lock manager, other hosts often have a lot of interaction with Master when they need to invoke resources. Of course, Slave hosts also interact with each other, such as:

Transfer the memory image of VM (virtual machine migration)

Mirrored disk (storage migration)

Secondly, XenCenter reads the configuration, management, License information and database information of the XenServer host through XAPI. At the same time, XAPI also interacts with the toolstack series tools run by the XenServer core we described in the previous article, including all components such as Xenopsd, Xcp-rrdd, Xcp-networkd, SM, perfmon, mpathalert, snapwatchd, stunnel, xenconsoled and xenstored, which communicate with XAPI and monitor the command interface of XAPI. Execute the corresponding function control according to the command sent by XAPI.

The following figure shows the software running on a XenServer host. Run the same software on all hosts. We can see a relationship between XAPI and other Toolstack.

II. Analysis of XAPI architecture and operating mechanism

The following diagram shows the internal operating relationships and architecture of xapi:

The top of the figure shows connecting XenAPI clients: XenCenter, XenOrchestra, OpenStack, and CloudStack. These clients communicate with XAPI through XenAPI (XenAPI's XMLRPC through HTTP POST) and HTTP GET/PUT on ports 80 and 443. And mutual trust between the two parties is established by using PAM authentication (local passwd and group files by default) or through Active Directory.

The Xen API in XAPI is subdivided into three categories:

* master-only: this is the most important API and the most commonly used API type. As the name implies, this type of API can only be accepted and executed by Master.

* normally-local: these API are special API that allow Slave hosts to perform under the premise of improving performance, which are often related to the performance of hosts and virtual machines. For example, disk input / output and virtual machine console are connected to the API controlled by these interfaces, these API are directly controlled and executed locally by the Slave host, and there is no need for Master to write down and forward them, which improves the access speed and performance.

* emergency: these API are classified as API solutions in emergency situations, such as emergency repair of resource pools when the Master host is offline.

For API execution, when the resource pool is normal, XAPI will first determine the type of API. If the user's operation on Slave in XenCenter is an API that needs to be performed through Master, then the XAPI of the Slave host will redirect the API to the Master host and hand it over to the Master host for execution control. After confirming the API type and passing the preliminary check, the API call goes into the "message forwarding" layer-controlling and locking resources (through the current_operations mechanism)-to determine which hosts should execute the request. If the request is executed locally, the host can directly call the function or the process can use the function; otherwise, the message forwarding layer will synchronize the request to other hosts that need to be executed together.

Note: XAPI currently uses the mode of "one separate thread per request", resulting in the creation of a complete POSIX thread for each request. Even when the request is created on this host and forwarded to other hosts, the created thread still exists on the host that was created for the first time. There is no doubt that the disadvantage of this mode must be that when there are a large number of requests, the processing of the XenServer host is blocked and the performance of the virtual machine is affected.

How exactly does API execute the call next? If the call to XenAPI is about a VM lifecycle operation, it will be converted through JSON-RPC (similar to Unix domain sockets) into a specific API call to Xenopsd, the component responsible for VM lifecycle management. Between XAPI and Xenopsd components, each call to XAPI uses a concept similar to asynchronous message queuing, and each call to XAPI does not require Xenopsd to immediately return the execution result. So at present, XAPI binds each task (all operations are run in the context of the task) to the Xenopsd task, and when XAPI receives the call, it throws its corresponding task to the corresponding bound Xenopsd. Whether the execution is successful or not needs to wait for feedback from Xenopsd, so after we execute a command in XenCenter, we see that the progress bar of the task is moving, but when we finish the progress bar, we need the underlying execution component to give XAPI feedback. XAPI updates its status in the status database, and XenCenter will communicate with XAPI constantly to receive status updates. If an error occurs when the Xenopsd component executes the command, the corresponding error message is returned and stored in the log.

If the call to XenAPI is a storage operation, then the Storage access layer verifies that the storage object is in the correct state (SR connection / detach; VDI connection / active state, read-only / read-write), and then invokes the relevant operations in the storage management API (SMAPI) V2 interface There is also a SMAPIv2-to-SMAPIv1 converter that can generate the necessary commands to follow the SMAPIv1 plug-in (EXT,NFS,LVM, etc.) and execute the storage types supported by these plug-ins.

When making API calls to the storage, they are all Master-type API calls, and the Slave host does not have permission to perform operations on the disk. So internally, the SMAPIv1 plug-in uses privileges to access XAPI's database and sets read-only field properties (such as VDI.virtual_size) directly to clients that are treated as read-only permissions. At the same time, because the shared storage is accessed by multiple hosts in the resource pool at the same time, only one host can access it at a time in order to ensure the security of the data. Therefore, the SMAPIv1 plug-in also cooperates with XAPI to control the access to storage, and it uses the common locking mechanism of shared storage to control multiple hosts accessing shared storage.

XAPI's database contains host and virtual machine metadata and resource pool information. The database is loaded into memory by the Master host of the resource pool and shared with all other Slave of the resource pool. Other Slave hosts access the database remotely and synchronize it to the local host. The database stores the event.next and event.from implemented by each API object in the database. After receiving the data, it is stored to disk in XML format and is refreshed asynchronously. If redo log is enabled, all database writes are synchronized and incrementally stored in the given shared block device. If redo logging is not enabled, XAPI may lose its most recent updates after a restart.

At the same time, XAPI also implements the high availability of hosts in the resource pool. High availability means that when one of the hosts fails in the resource pool, it not only ensures the normal operation in the resource pool, but also ensures that the virtual machine running on the failed host is restarted on other hosts. XAPI is tightly integrated with a component called xhad to achieve the high availability of the XenServer resource pool. Xhad is a host activity monitor. When xhad confirms that the host has failed (which is determined by monitoring the timeout and the connection status of the host to storage, etc.), XAPI will restart the failed virtual machine that has been marked by HA as "protected". XAPI can also limit resource utilization to prevent resource pools from becoming overloaded in case there are no resources to run HA when there are multiple host failures.

Finally, XAPI also carries the task of implementing XE CLI, and its XE execution efficiency is directly related to XAPI. The XE program remotely controls access to the XAPI command line, while XAPI displays a series of simple commands (prompt for input; print screen; fetch files; exit, etc.) based on returning a Shell interface.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.