JP2014501995A - Elastic computing cloud system upgrade - Google Patents

Abstract

The server of the elastic computing cloud system includes a block device driver device and at least one block device service device. The server performs hot deployment on the storage service so that the storage service can be upgraded without interrupting the storage service. The block device driver device maintains a waiting queue and a pending queue for each storage service. In response to the determination that the storage service is performing an upgrade, the block device driver device stops processing write / read requests for data that is maintained in the hold queue for the service and waits in the hold queue. Returning the current data write / read request back to the wait queue for redispatch, thereby completing the storage service upgrade process in the elastic computing cloud system without interrupting the storage service Is done.

Description

  The present disclosure relates to the technical field of elastic computing cloud and storage services associated with block devices, and in particular, elastic computing that implements storage of data based on storage services associated with block devices. The present invention relates to an apparatus, a method, and a system for upgrading a cloud system.

(Cross-reference of related applications)
This application is filed on January 5, 2011, Chinese Patent Application 201110001297, entitled “Apparatus, Method and System of Upgrading Elastic Computing System”. Claim X priority, which is incorporated herein by reference in its entirety.

  Elastic computing cloud is a computing cloud service that virtualizes local physical servers as multiple virtual servers for use based on virtualization technology to improve resource utilization and reduce costs It is. A virtual server (ie, virtual machine) storage service virtualized based on elastic computing cloud technology is a block device-based remote storage service, referred to in the industry as elastic block storage.

  A block device remote storage service is a block level storage service provided by a block device driver. The local physical server and / or virtual server can store the server's data in blocks in the remote storage resource pool, thereby conserving local storage resources. In other words, the remote storage service of the block device provides a service similar to a physical hard drive for storing data of a local physical server and / or virtual server, and there is no restriction on the data format and the file system format.

  With the rapid development of elastic computing cloud technology, elastic block storage services have high standards for the high availability of remote storage services. In general, there are tens of thousands of virtual servers virtualized based on the elastic computing cloud. These tens of thousands of virtual servers are provided for use by third parties (government agencies, traditional large enterprises, and small businesses, small and medium internet webmasters, individual users, etc.) The Clusters formed from multiple virtual servers rely on block device remote storage services for operation. Remote storage holds and circulates data for the entire elastic computing cloud system. The availability of the remote storage service is related to the overall availability of the elastic computing cloud system.

  When upgrading an elastic computing cloud system that performs storage of data based on a block device remote storage service, existing technology will first inform the service user that the service is temporarily unavailable for the upgrade process. And temporarily suspend the services of each virtual server in the entire elastic computing cloud system to perform storage upgrade service upgrades (eg, fix bugs or provide new features) There is a need to. After the redeployed service operates normally, the virtual server of the entire elastic computing cloud system can return to normal operation, thereby completing the upgrade process. The upgrade process prevents the user from continuing to access web pages that use web services provided by the virtual server of the elastic computing cloud system, i.e., the elastic computing cloud for the user to perform distributed computing. When using the system's virtual server, it forces the user to terminate the ongoing distributed computing.

  As described above, when an elastic computing cloud system that performs data storage based on a remote storage service of a block device is upgraded with existing technology, the related upgrade process is very complicated. The upgrade process takes a relatively long time and generally requires several hours to complete the upgrade operation, so the efficiency of the upgrade is relatively low. In addition, during the upgrade process, the user may be forced to terminate an ongoing transaction, so it cannot be guaranteed to provide high service availability to the user and will deteriorate the user experience. .

  The exemplary embodiments of the present disclosure improve the efficiency of the upgrade through online upgrade techniques and address the problem of poor user experience due to the transactions currently being used by the user being terminated during the upgrade. To avoid, an apparatus, method, and system for upgrading an elastic computing cloud system that implements storage of data based on remote storage of block devices is provided.

  According to a first aspect of the present disclosure, exemplary embodiments of the present disclosure provide a server of an elastic computing cloud system that implements data storage based on a block device storage service. In one embodiment, the server includes a block device driver device and at least one block device service device. In response to receiving the data write / read request corresponding to the block device service device, the block device driver device waits for the block device service device to receive the received data write / read request in advance. Configured to be placed in a queue.

  In addition, the block device driver device further fetches data write / read requests from the wait queue and forwards the fetched requests to a pending queue that is maintained in advance for the block device service device. A request to write / read data in the hold queue can be sent to the block device service device for processing. In response to receiving the processing result from the block device service apparatus for the received data write / read request, the block device driver apparatus may delete the transmitted data write / read request from the pending queue. it can.

  In one embodiment, the block device driver device sends a write / read request for data in the pending queue to the block device service device for processing in response to a determination that the block device service device performs a service upgrade. In response to a determination that a service upgrade has been or has been completed, a write / read request for data in the pending queue can be transferred back to the waiting queue.

  Further, the block device service apparatus performs read and write operations corresponding to the data requested for the storage resource pool of the block device based on the data write / read request transmitted from the block device driver apparatus. May be configured.

  According to a second aspect of the present disclosure, exemplary embodiments of the present disclosure further provide a method for upgrading an elastic computing cloud system that performs storage of data based on a storage service associated with a block device. To do. In one embodiment, the method is pre-maintained for a service associated with a block device each time in response to receiving a data write / read request corresponding to the service associated with the block device. Placing a write / read request for received data in a waiting queue. The method may further fetch data write / read requests from the waiting queue and forward the fetched requests to a pending queue that is pre-maintained for services associated with the block device. it can.

  In one embodiment, the method sends a write / read request for data in the pending queue to a service associated with the block device for processing and a block for the received write / read request for data. In response to receiving a processing result from the service associated with the device, the transmitted data write / read request is deleted from the pending queue. In some embodiments, the method responds to a determination that a service associated with the block device performs a service upgrade by sending a write / read request for data in the pending queue to the block device for processing. In response to a determination that a service upgrade has occurred or has been completed, sending data write / read requests in the pending queue back to the waiting queue can stop sending to the associated service be able to.

  According to a third aspect of the present disclosure, an exemplary embodiment of the present disclosure provides an apparatus for upgrading an elastic computing cloud system that performs storage of data based on a storage service associated with a block device. Provide further. In one embodiment, the apparatus associates a received data write / read request with the block device each time in response to receiving a data write / read request corresponding to a service associated with the block device. A wait queue maintenance unit is included that is configured to be placed in a wait queue that is pre-maintained for a given service.

  In addition, the device fetches data write / read requests from the standby queue and forwards the fetched requests to a pending queue that is pre-maintained for services associated with the block device. A hold queue maintenance unit may be further included that is configured to:

  In some embodiments, the apparatus includes a write / read request configured to send a write / read request for data in the pending queue to a service associated with the block device for processing. A processing unit may further be included. The write / read request processing unit is responsive to receiving a processing result from the service associated with the block device for the received data write / read request, and holds the transmitted data write / read request in a pending queue. It may be further configured to be deleted from In one embodiment, the write / read request processing unit is responsive to a determination that a service associated with the block device is performing a service upgrade to process a write / read request for data in the pending queue for processing. In response to a determination that a service upgrade has occurred or has been completed, a write / read request for data in the pending queue can be stopped from being sent to the service associated with the block device. Can be transferred back to.

  According to a fourth aspect of the present disclosure, an exemplary embodiment of the present disclosure provides a system for upgrading an elastic computing cloud system that performs storage of data based on a storage service associated with a block device. Provide further. In one embodiment, the system may include a storage resource pool configured to store data for the elastic computing cloud system based on a storage service associated with the block device.

  In addition, the system may further include at least one physical server. In response to receiving a data write / read request corresponding to a service associated with the block device, the at least one physical server sends the received data write / read request to the service associated with the block device each time. May be configured to be placed in a pre-maintained waiting queue.

  In addition, the at least one physical server fetches data write / read requests from the wait queue and places the fetched requests in a pending queue that is pre-maintained for services associated with the block device. And read and write operations corresponding to the requested data for the storage resource pool can be performed based on write / read requests for data in the pending queue.

  In some embodiments, at least one physical server is responsive to a determination that a service associated with the block device performs a service upgrade to process a write / read request for data in a pending queue. In response to a determination that a service upgrade has occurred or has been completed and forwards write / read requests for data in the pending queue to the waiting queue. You can go back.

  In a physical server of an elastic computing cloud system that implements storage of data based on a storage service associated with a block device, the technical concept proposed by the exemplary embodiment of the present disclosure is for each block device Two queues are maintained individually for virtualized services. One is a wait queue for data write / read requests and is used to maintain data write / read requests sent to the service associated with the block device and awaiting processing. The other is a pending queue used by the physical server to maintain data write / read requests that are currently being processed by services associated with the block device.

  This technical concept is for a request to write / read data that is maintained in a pending queue for a service associated with a block device when the service associated with the block device needs to be upgraded. Elastic computing without stopping processing and returning data write / read requests that are currently being processed in the pending queue back to the wait queue for redispatching, without interrupting storage services Completion of the service upgrade processing of the storage service in the cloud system is realized. This improves the efficiency of service upgrades, avoids interruption of transactions currently used by users, and provides highly available services during the upgrade process, thereby improving the user experience.

FIG. 3 is a structural diagram illustrating the topology of an elastic computing cloud system that implements data storage based on block device storage services used by the technical concept proposed by the exemplary embodiments of the present disclosure. . FIG. 3 is a structural diagram illustrating an improved physical server, according to an exemplary embodiment of the present disclosure. 5 is a flow diagram illustrating improved physical server internal processing for reading and writing data in a local or remote storage resource pool, according to an exemplary embodiment of the present disclosure. 5 is a flow diagram illustrating details of the operation of a block device driver apparatus in an improved physical server, according to an exemplary embodiment of the present disclosure. Before or after a service upgrade of a block device service device according to an exemplary embodiment of the present disclosure, an improved physical server block device driver device dispatches for the wait and hold queues maintained thereby It is the schematic which illustrates the process for performing. FIG. 3 is a structural diagram illustrating a new block device driver apparatus of an improved server, according to an exemplary embodiment of the present disclosure. FIG. 3 is a schematic diagram illustrating operations for controlling a block device driver device of a physical server when performing a service upgrade of the server according to an exemplary embodiment of the present disclosure. FIG. 7 illustrates the exemplary device described in FIG. 6 in more detail.

  When an elastic computing cloud system that performs data storage based on block device storage services is upgraded due to the lack of hot deployment to achieve online upgrades in existing technologies, Each virtual server in the cloud cloud system needs to be shut down for service upgrade, and restarted after the upgrade is completed. For storage service providers or storage service users, this greatly increases maintenance costs and reduces the availability of related services. In view of this problem, the present disclosure is for a block device storage service in an elastic computing cloud system that performs data storage based on the block device storage service to achieve an online upgrade of the storage service. In addition, we propose the implementation of hot deployment. Specifically, the storage service upgrade is performed without interrupting the storage service. Accordingly, the availability of the storage service of the service provider and the transparency of the storage service are improved, and the storage service user does not have to worry about the back-end service upgrade process.

  Hot deployment of block device storage services is a technique for online upgrade of block device services. Since the block device storage service is based on the block device driver technology, the physical server of the elastic computing cloud system includes a kernel mode block device driver service program. The kernel mode service program of the block device driver needs to transfer the data write / read request to the user mode service program of the block device included in the physical server, and the user mode service program of the block device Are transferred to a storage resource pool of a remote network, a storage resource pool of a local physical disk, or the like for processing. The kernel mode service program of the block device driver is more stable than the user mode service program of the block device. Block device user mode service programs frequently require version upgrades to provide better quality storage services. Based on the technical concept provided in the exemplary embodiments of the present disclosure, a block device driver service program capable of supporting an online upgrade is provided to enhance the availability of storage services and user experience Is provided within the physical server of the elastic computing cloud system.

  FIG. 1 illustrates the topology of an elastic computing cloud system that implements storage of data based on block device storage services used in the technical concept proposed by the exemplary embodiments of the present disclosure. A structural diagram is shown. The elastic computing cloud system includes a plurality of virtual servers (virtual server 1, virtual server 2, virtual server 3,..., Virtualized from a local physical server based on the elastic computing cloud technology. Virtual server n) is included. Each virtual server implements locally provided data storage services using remote storage resource pools or local storage resource pools based on block device storage service technology. Specifically, each virtual server stores data that needs to be stored locally in a remote storage resource pool or a local storage resource pool, and then remote storage when presented with a request to read the relevant data. Read the data from the resource pool or local storage resource pool. In this way, each physical server can share a storage resource pool that is set up remotely or locally without occupying the storage resources of the local physical server itself. Resource utilization is improved.

  In order to implement the technical concept provided in this disclosure, the physical server functionality of the elastic computing cloud system described above is to achieve the objective of performing an online upgrade for storage services. Need to be improved.

  FIG. 2 shows a structural diagram illustrating an improved physical server according to an exemplary embodiment of the present disclosure, specifically a kernel mode block device driver device 20, a user mode client device 21, and at least One block device service device 22 and a local or remote storage resource pool 23 are included. The block device driver apparatus 20 can control jobs of a plurality of block device service apparatuses 22. Each component implements an online upgrade of the storage service based on the following operating principle.

  The block device driver device 20 in the kernel mode receives a data write / read request from the write / read dispatch layer at the lowest layer of the physical server, and sends the data write / read request to the user mode via the TCP protocol, for example. Transfer to the block device service device 22. In order to implement an online upgrade function that supports hot deployment, the block device driver device 20 maintains two queues for each block device service device 22 that are virtualized from the physical server, one of which Is a wait queue. Each time a data write / read request corresponding to a specific block device service device 22 is received from the write / read dispatch layer at the lowest layer of the physical server, the block device driver device 20 receives the received write / read. The request is placed in a wait queue that is maintained in advance for the block device service device 22 to wait for subsequent processing. The other is a hold queue. Each time the block device service device 22 processes a data write / read request, the block device driver device 20 first begins to receive data from a wait queue maintained in advance for the block device service device 22. Fetch a write / read request, forward the request to a pending queue that is maintained in advance for the block device service device 22, and process the request in the pending queue for processing by the block device service. Transmit to device 22. As can be seen, all write / read requests in the pending queue are write / read requests that are currently being processed by the physical server. After the pending queue write / read request transmitted from the block device driver apparatus 20 is properly completed, the block device service apparatus 22 transmits the result of the appropriate processing to the block device driver apparatus 20. In response to receiving the properly processed result, the block device driver device 20 removes the transmitted and fully processed write / read request from the pending queue and writes other writes in the pending queue. / Process read requests, etc. Thereafter, in response to the determination that the block device service device 22 performs a service upgrade, the block device driver device 20 requests to write / read data in the hold queue maintained for the block device service device 22. To the block device service apparatus 22 is stopped. Further, when it is determined that a service upgrade has been performed or has been completed, the block device driver device 20 issues a write / read request for data in a pending queue that is maintained in advance for the block device service device 22. Add back to the wait queue previously maintained for the block device service device 22 to wait for subsequent redispatch and processing.

  Preferably, the block device driver apparatus 20 checks whether the TCP communication connection between the block device driver apparatus 20 itself and the block device service apparatus 22 is normal, so that the block device service apparatus 22 performs the upgrade operation. It can be determined whether to perform or complete the upgrade. When the TCP communication connection between the block device driver apparatus 20 and the block device service apparatus 22 is disconnected, the block device driver apparatus 20 can determine that the block device service apparatus 22 performs a service upgrade. When the TCP communication connection between the block device driver apparatus 20 and the block device service apparatus 22 is recovered for the connection, the block device driver apparatus 20 determines that the service upgrade of the block device service apparatus 22 has been completed. can do.

  The block device service apparatus 22 in the user mode receives a data write / read request transmitted from the block device driver apparatus 20 via, for example, the TCP protocol. Specifically, the block device service device 22 in the user mode sends a write / read request for data processed by the block device driver device 20 in a hold queue that is maintained in advance for the block device service device 22. To receive. Upon receiving the write / read request, the user mode block device service device 22 determines whether the write / read request is legitimate, whether it is a read request or a write request, and initiates the write / read request. Analyzing (including verifying) location and length information, etc., performs an analysis operation on the request, and performs a read or write operation on the local or remote storage resource pool based on the analysis result. When the request is a read request, the block device service device 22 in the user mode reads the requested data from the local or remote storage resource pool 23, and the read data and the processing result are sent to the block device driver device 20 in the kernel mode. Return, for example, via the TCP protocol. When the request is a write request, the block device service device 22 in the user mode stores the data requested to be written to the local or remote storage resource pool 23, and the processing result of the write request is stored in the block device driver in the kernel mode. Return to device 20 via, for example, TCP protocol.

  The user mode client device 21 can control each block device service device 22 to start or stop a job via the kernel mode block device driver device 20. When the block device service apparatus 22 is controlled to start a job, the client apparatus 21 first starts TCP request with the block device service apparatus after the user starts creating a request for a block device service via the client apparatus 21. The connection is established, and the created TCP socket handle is transmitted to the block device driver apparatus 20 through an ioctl command. Thereafter, the client device 21 can close the TCP socket. In this manner, the client device 21 realizes a TCP connection between the block device driver device 20 in the kernel mode and the block device service device 22 in the user mode. All subsequent data write / read requests sent to the block device driver device 20 may be sent to the block device service device 22 via a TCP connection. When controlling the block device service apparatus 22 to stop the job, the client apparatus 21 sends a stop request to the ioctl command after the user starts a request for stopping the service of the block device via the client apparatus 21. To the block device driver device 20. When receiving the request, the block device driver apparatus 20 first transmits a stop request to the block device service apparatus 22. In response to the reception of this request, the block device service device 22 closes the TCP socket and ends safely. After receiving a stop response from the block device service device 22, the block device driver device 20 stops processing the write / read request in the associated pending queue. As a result, the block device service apparatus 22 stops operating. When the block device service apparatus 22 is in the process of upgrading, the client apparatus 21 can try to establish a TCP link with the block device service apparatus 22 every second. If the new TCP link is successfully established, this indicates that the block device service device 22 has been successfully upgraded, and the client device 21 can send the newly created TCP socket handle to the block device driver via the ioctl command. Transmit to device 20. Thus, after the block device service device 22 is upgraded, the block device driver device 20 and the block device service device 22 establish a new TCP link for communicating data write / read requests.

  The client device 21 can be an optional component of the physical server in the present disclosure. In order to realize the user control of the operation mode of the block device service device 22 in the user mode, in addition to using the client device 21, other trigger mechanisms such as a timing function and an event trigger function are used to The operation mode of the block device service device 22 can be automatically controlled.

  In general, the local or remote storage resource pool 23 is a storage server of a distributed file system or the like. This resource pool 23 can be deployed locally or remotely, and in most cases is a remotely deployed storage resource pool. The storage resource pool 23 stores service data of each virtual server in the elastic computing cloud system. Specifically, when a data read request is received from a specific block device service device 22 of a physical server, the storage resource pool 23 reads data related to the request from the data, and reads the read data from the block device service device 22. To give feedback. When a data write request is received from a specific block device service device 22 of a physical server, the storage resource pool 23 stores the data requested to be written therein.

  FIG. 3 shows a flow diagram illustrating improved physical server internal processing for reading and writing data in a local or remote storage resource pool, according to an exemplary embodiment of the present disclosure. In one embodiment, the process of reading data may include:

  After the file system layer of the local physical server sends a read request for data of a specific block device service device to the block device driver device via the general block layer and the write / read dispatch layer, the block device driver device Place the request in a wait queue that is pre-maintained for the block device service device to wait for subsequent processing, after which a request to read data is sent from the queue to the block device service device. Fetch into a pending queue that is maintained in advance and process the read request, ie send the read request to the block device service device. The block device service device reads data related to the request from the storage pool according to the read request, and returns the read result to the block device driver device via the TCP connection. The block device driver device transmits the read result to the file system layer via the general block layer and the write / read dispatch layer, and the file system layer returns the read result to the system for dispatch.

  In one embodiment, the data writing process may include:

  The local physical server sends the data write request and the data that is requested to be written to the block device driver device via the file system layer, general block layer, and write / read dispatch layer called by the system. ,Store. The block device driver device places the write request in a wait queue that is maintained in advance for the block device service device to wait for subsequent processing, and then fetches the write request for data from the queue. This request is then placed in a pending queue that is maintained in advance for the block device service device, and the write request is processed, ie, the data write request and the data to be written are sent to the block device service device. The block device service device analyzes the data write request to achieve storage of the data to be written in the storage resource pool.

  FIG. 4 shows a flowchart illustrating details of the operation of a block device driver apparatus in an improved physical server, according to an exemplary embodiment of the present disclosure. The block device driver device maintains two queues individually for each block device service device, one of the queues being a wait queue, transmitted and by the corresponding block device service device Used to wait for processing, put a data write / read request in this wait queue, and place this request in a queue waiting for processing, the other queue is pending It is used to place in the pending queue data write / read requests that are queues and are currently being processed by the corresponding block device service device. The specific operation principle of the block device driver device based on these two maintained queues is as follows.

  In 40, each time a data write / read request corresponding to a specific block device service device is received from the lowest layer of the physical server, the block device driver device waits for the received data write / read request. Place it in a wait queue that is maintained in advance for that block device service device.

  At 42, when processing a data write / read request corresponding to the block device service device, the block device driver device first fetches the data write / read request from the wait queue and passes the request to the block device service device. Block device service device that forwards to a hold queue that is maintained in advance for the device, and sends write / read requests for data in the hold queue to the block device service device in user mode for processing In response to receiving an appropriate processing result of the received data write / read request from the server, the transmitted data write / read request is deleted from the pending queue.

  At 44, in response to the determination that the block device service device is performing a service upgrade, the block device driver device sends a write / read request for all data in the pending queue to the block device service device for processing. To stop doing.

  If it is determined at 46 that a service upgrade has occurred or has been completed, the block device driver device waits for a write / read request for data in the pending queue to wait for subsequent redispatch and processing. Transfer back to the queue. Specifically, the block device driver apparatus determines whether the block device service apparatus performs a service upgrade or completes the service upgrade, and indicates the state of the communication connection between the block device driver apparatus itself and the block device service apparatus. This can be determined by inspection. More specifically, upon detecting that the communication connection between the block device driver apparatus itself and the block device service apparatus has been disconnected, the block device driver apparatus determines that the block device service apparatus performs a service upgrade. Can do. Further, when detecting that the communication connection between the block device driver apparatus itself and the block device service apparatus has been recovered, the block device driver apparatus can determine that the block device service apparatus has completed the service upgrade.

  FIG. 5 illustrates a wait queue and a hold queue with which an improved physical server block device driver device is maintained before or after a service upgrade of a block device service device according to an exemplary embodiment of the present disclosure. FIG. 2 shows a schematic diagram illustrating a process for performing dispatch for the purpose of FIG. In order to support hot deployment (ie, online upgrade) of the block device service device, the kernel mode block device driver device needs to maintain write / read requests for received data. The block device driver device uses the two data read and write queues individually for each block device service device to maintain the state of the write / read request. One is a wait queue that is used to maintain write / read requests sent from the write / read dispatch layer in the physical server for each block device service device, A queue is placed in the wait queue to wait for subsequent processing by the block device driver device. The other is a pending queue that is used to maintain write / read requests that are currently being processed by the block device driver device for each block device service device. These write / read requests in the pending queue may not be completely processed and the block device driver device may be waiting for a processing response from the corresponding block device service device. If a particular block device service device is not performing a service upgrade, the block device driver device first begins the wait queue that is maintained in advance for the block device service device when processing a write / read request. Fetches the write / read request from the queue, deletes the fetched write / read request from the wait queue, and places the write / read request at the head of the pending queue that is maintained in advance for the block device service device. Each write / read request in the hold queue is sent to the block device service device for processing and after receiving the appropriate processing result of the received write / read request from the block device service device, The sent write / read request To remove from the distillate queue. When the block device service device needs a service upgrade, the block device driver device stops sending write / read requests in the pending queue to the block device service device for processing, i.e., new Stop sending the write / read request to the block device service device. After the block device service device performs an upgrade or completes the upgrade, the block device driver device will request all write / read requests in the corresponding pending queue (FIGS. 1, 2, 3, 4, 5, 6... Are put back into the corresponding wait queue for subsequent redispatch by the block device driver device.

  As described above, by adding a block device driver device to the physical server of the elastic computing cloud system and through two queues that are maintained in advance for each block device service device By dispatching the device driver device, the service upgrade of the back-end storage service can be completed without interrupting the provision of the storage service to the data storage user, so that the data storage in the elastic computing cloud system can be completed. Increases availability. In addition, the aforementioned concept is transparent to the user so that the data storage user feels almost no impact on the data storage transaction due to the service upgrade of the storage service, thus improving the user experience. Is done.

  Correspondingly, FIG. 6 shows a structural diagram illustrating a new block device driver apparatus for an improved physical server, according to an exemplary embodiment of the present disclosure. In one embodiment, the apparatus may include a wait queue maintenance unit 60 that is used to maintain a wait queue for each block device service device individually. Within it, data write / read requests for each block device service device are placed into a queue waiting for processing. In addition, the apparatus may further include a hold queue maintenance unit 61 that is used to maintain a separate hold queue for each block device service device individually. Placed in the pending queue are data write / read requests that are currently being processed for each block device service device.

  Specifically, a data write / read request is fetched from a wait queue previously maintained by the wait queue maintenance unit 60 for a particular block device service device and the block device service device's Is moved to a pending queue that is maintained. Specifically, the pending queue maintenance unit 61 fetches a data write / read request from the head of the corresponding wait queue, deletes the fetched data write / read request from the wait queue, Requests to write / read fetched data can be forwarded to the head of the corresponding pending queue maintained in advance.

  In some embodiments, the apparatus may further include a write / read request processing unit 62. The write / read request processing unit 62 sends a write / read request for data in the corresponding hold queue maintained by the hold queue maintenance unit 61 to the block device service device for processing. Can be used. Further, the write / read request processing unit 62 suspends the transmitted data write / read request in response to receiving an appropriate processing result of the received data write / read request from the block device service apparatus. In response to a determination that the block device service device is to perform a service upgrade that can be removed from the queue, a write / read request for data in the pending queue is sent to the block device service device for processing. Can be stopped.

  In some embodiments, the write / read request processing unit 62 is further configured to respond to a determination that a service upgrade has occurred or has been completed with a write / read request for data in the pending queue. To wait for a subsequent redispatch by processing unit 62, it can be transferred back to the corresponding wait queue. Specifically, when the write / read request processing unit 62 detects the disconnection of the communication connection by checking the state of the communication connection between the block device driver apparatus and the block device service apparatus, the block device service apparatus It can be determined that the service upgrade is to be performed, and if it is detected that the communication connection has been restored, it can be determined that the block device service apparatus has completed the service upgrade.

  FIG. 7 shows a schematic diagram illustrating operations for controlling a block device driver device of a physical server when performing a service upgrade of the server according to an exemplary embodiment of the present disclosure. Specifically, the process of operation includes the following.

  At 70, prior to the storage service upgrade, the upgrade maintenance manager sends an ioctl command to the kernel mode block device driver device via the user mode client device, and the block device driver device writes all writes. / Instructs to hold the read request.

  At 72, the upgrade maintenance manager then uses the normal upgrade process to upgrade the service for the storage service (service upgrade includes stopping the service, upgrading the service program, and publishing a new service). Is included). In this way, the hot deployment for performing an online service upgrade for the storage service is completed. During the hot deployment process, the block device driver device holds all write / read requests.

  At 74, upon deployment, the block device driver device releases all write / read requests and the data storage service continues processing.

  It should be understood by one of ordinary skill in the art that the exemplary embodiments of the present disclosure can be provided as a method, apparatus (device), or computer program product. Accordingly, the present disclosure can be implemented in units of hardware only, software only, or a combination of hardware and software. Further, the present disclosure is implemented in the form of a computer program product having one or more computer storage media (including but not limited to disk storage, CD-ROM, optical disk, etc.) containing computer-executable instructions. can do.

  The present disclosure is described with reference to flowchart illustrations and / or block diagrams of example methods, apparatus (devices) and computer program products. It is to be understood that each flow and / or block, and combinations of flows and / or blocks in the flowchart and / or block diagram, may be performed by computer program instructions. These computer program instructions perform the functions indicated in one or more flows of the flowchart and / or in one or more blocks of the block diagram through execution of instructions by a computer or other programmable data processor. May be provided to a general computer, a specialized computer, an embedded processor to create a machine, or other programmable data processor.

  These computer program instructions may alternatively operate in a specific manner for a computer or other programmable data processor such that instructions stored in computer readable storage produce a product that includes an instruction device. It may be stored in a computer readable storage area that can be instructed. The instruction device performs the functions indicated in one or more flows of the flowchart and / or one or more blocks of the block diagram.

  These computer program instructions may alternatively reside in a computer or other programmable data processor so that the computer or other programmable data processor can take a series of operational actions to create a computer-implemented process. May be loaded. As a result, instructions executed on a computer or other programmable data processor provide actions to implement the functions indicated in one or more flows in the flowchart and / or one or more blocks in the block diagram. can do.

  For example, FIG. 8 shows an exemplary apparatus 800 in more detail, such as the apparatus described above. In one embodiment, the device 800 may include, but is not limited to, one or more processors 801, a network interface 802, a memory 803, and an input / output interface 804.

  Memory 803 includes computer readable media in the form of volatile memory, such as random access memory (RAM), and / or non-volatile memory, such as read only memory (ROM) or flash RAM. May be included. The memory 803 is an example of a computer-readable medium.

  Computer-readable media includes volatile and nonvolatile, implemented in any method or technique for storage of information such as computer readable instructions, data structures, program modules, or other data. Includes removable and non-removable media. Examples of computer storage media include phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read only memory (ROM), electrical Erasable Programmable Read Only Memory (EEPROM), Flash Memory or Other Memory Technology, Compact Disc Read Only Memory (CD-ROM), Digital Multipurpose Disc (DVD) or Other Optical Storage, Magnetic Cassette, Magnetic Tape, Magnetic Includes any disk storage or other magnetic storage device or any other non-transmission medium that can be used to store information for access by a computing device. But it is not limited to. As defined herein, computer-readable media does not include temporary media, such as modulated data signals and carrier waves.

  The memory 803 may include a program unit 805 and program data 806. In one embodiment, the program unit 805 may include a wait queue maintenance unit 807, a hold queue maintenance unit 808, and a write / read request processing unit 809. Details of these program units can be found in the previous embodiments described above.

  While preferred embodiments of the present disclosure have been described, those skilled in the art can make additional modifications and changes to these embodiments as soon as they understand the basic creative concepts. Accordingly, the claims are intended to cover all modifications and variations that fall within the scope of the claims and the preferred embodiments of the present disclosure.

  Those skilled in the art can modify or change the disclosed methods, systems, and devices in many different ways without departing from the spirit and scope of the disclosure. Accordingly, this disclosure is intended to embrace all such alterations and modifications that fall within the scope of the claims of this disclosure and their equivalents.

Claims (20)

A server of an elastic computing cloud system that performs data storage based on a storage service associated with a block device, comprising a block device driver device and at least one block device service device;
The block device driver device is:
In response to receiving a data write / read request corresponding to a block device service device, the received data write / read request is placed in a wait queue that is maintained in advance for the block device service device. put,
Fetching a data write / read request from the wait queue and transferring the fetched request to a pending queue that is maintained in advance for the block device service device;
Sending data write / read requests in the hold queue to the block device service device for processing;
In response to receiving a processing result from the block device service apparatus for the received data write / read request, the transmitted data write / read request is deleted from the pending queue;
In response to a determination that the block device service device is to perform a service upgrade, stop sending data write / read requests in the pending queue to the block device service device for processing;
Responsive to a determination that a service upgrade has occurred or has been completed, configured to transfer a write / read request for the data in the pending queue back to the standby queue;
The block device service device
A server configured to perform read and write operations corresponding to data requested for a storage resource pool of a block device based on a write / read request for the data transmitted from the block device driver device . Controlling the start of the block device service device;
The server of claim 1, further comprising a client device configured to establish a communication connection between the block device driver device and the started block device service device at startup. The client device is
Controlling the stop of the block device service device,
The server of claim 2, further configured to release the communication connection between the block device driver device and the stopped block device service device when stopped.   The server of claim 1, wherein the block device driver device is further configured to verify a communication connection with the block device service device.   The block device driver apparatus is further configured to determine that the block device service apparatus performs a service upgrade in response to determining that the communication connection with the block device service apparatus has been disconnected. 4. The server according to 4.   The block device driver device is further configured to determine that the block device service device has completed the service upgrade in response to determining that the communication connection with the block device service device has been restored for connection. The server of claim 4 configured. A method for upgrading an elastic computing cloud system that implements storage of data based on a storage service associated with a block device comprising:
In response to receiving a data write / read request corresponding to a service associated with a block device, each time in a wait queue maintained in advance for the service associated with the block device, Placing a write / read request for the received data;
Fetching data write / read requests from the waiting queue, forwarding the fetched requests to a pending queue that is pre-maintained for the service associated with the block device; Sending a write / read request for data in the pending queue to the service associated with the block device for processing and associated with the block device for the received write / read request for data In response to receiving a processing result from the service, deleting the transmitted data write / read request from the pending queue;
In response to a determination that the service associated with the block device is to perform a service upgrade, a write / read request for data in the pending queue is sent to the service associated with the block device for processing. Stop sending, and
In response to a determination that a service upgrade has been or has been completed, transferring a write / read request for the data in the pending queue back to the standby queue;
Including a method.   The method of claim 7, wherein determining that a service upgrade has been performed or has completed includes checking a communication connection with the service associated with the block device.   The determination that a service upgrade is performed or has completed further includes determining that the block device service apparatus performs a service upgrade in response to a determination that the communication connection with the block device service apparatus is disconnected. 9. The method of claim 8, comprising.   A determination that a service upgrade has been or has been completed is responsive to a determination that the communication connection with the block device service device has been restored for connection, wherein the block device service device has completed the service upgrade 9. The method of claim 8, further comprising determining that it has been. Fetching a write / read request for data from the wait queue and forwarding the fetched request to a pending queue that is pre-maintained for the service associated with the block device;
Fetching the data write / read request from the head of the wait queue;
Deleting the fetched data write / read request from the waiting queue;
Forwarding the fetched data write / read request to the hold queue previously maintained;
The method of claim 7 comprising: An apparatus for upgrading an elastic computing cloud system for storing data based on a storage service associated with a block device, comprising:
In response to receiving a data write / read request corresponding to a service associated with a block device, each time in a wait queue maintained in advance for the service associated with the block device, A wait queue maintenance unit configured to place a write / read request for the received data;
Configured to fetch data write / read requests from the wait queue and forward the fetched requests to a pending queue previously maintained for the service associated with the block device. A hold queue maintenance unit;
Sending a write / read request for data in the pending queue to the service associated with the block device for processing;
In response to receiving a processing result from the service associated with the block device for the received data write / read request, the transmitted data write / read request is deleted from the pending queue. ,
In response to a determination that the service associated with the block device is to perform a service upgrade, a write / read request for data in the pending queue is processed for processing the service associated with the block device. Stop sending to
A write / read request configured to forward the write / read request for the data in the pending queue back to the wait queue in response to a determination that a service upgrade has occurred or has been completed. A processing unit;
An apparatus comprising:   The apparatus of claim 12, wherein the write / read request processing unit is further configured to verify a communication connection between the apparatus and the block device service apparatus.   14. The write / read request processing unit is further configured to determine that the block device service device performs a service upgrade in response to a determination that the communication connection has been disconnected. apparatus.   The write / read request processing unit is further configured to determine that the block device service device has completed the service upgrade in response to determining that the communication connection has been restored. The device described.   The hold queue maintenance unit fetches the data write / read request from the head of the wait queue, deletes the fetched data write / read request from the wait queue, and fetches the fetched data. 13. The device of claim 12, wherein the device writes / reads requests to the pending queue that is maintained in advance. An elastic computing cloud system for storing data based on a storage service associated with a block device,
A storage resource pool configured to store data of the elastic computing cloud system based on the storage service associated with the block device;
Each time in response to receipt of a data write / read request corresponding to a service associated with a block device, in a wait queue maintained in advance for the service associated with the block device Put the request to write / read the received data in
Fetching data write / read requests from the waiting queue and forwarding the fetched requests to a pending queue that is maintained in advance for the service associated with the block device;
Performing read and write operations corresponding to the requested data for the storage resource pool based on write / read requests for the data in the pending queue;
In response to a determination that the service associated with the block device is to perform a service upgrade, a write / read request for data in the pending queue is processed for processing the service associated with the block device. Stop sending to
At least one physical configured to forward a write / read request for the data in the pending queue back to the standby queue in response to a determination that a service upgrade has been performed or has been completed Server,
An elastic computing cloud system.   The system of claim 17, wherein the storage resource pool is deployed locally with the at least one physical server.   The system of claim 17, wherein the storage resource pool is deployed remotely from the at least one physical server.   The at least one physical server removes the fetched data write / read request from the wait queue in response to transferring the fetched data write / read request to the pending queue. The system of claim 17, further configured as follows:

Images