A server system including a first server to execute first role, other server to execute at other role, spare server and management layer server. The management layer server is configured to allocate first group of users to access first server and other group of users to access other server, receive status information sent by first server and status information sent by other server, analyse status information to determine an operational status of first server and operational status of other server, update role of spare server to first role when operational status of first server indicates failed state and reallocate first group of users to the spare server, and update a role of another spare server to the other role when the operational status of the other server indicates a failed state and reallocate the other group of users to the other spare server.

Examples of systems are described herein which may dynamically allocate compute resources to recovery clusters. Accordingly, a recovery site may utilize fewer compute resources in maintaining recovery clusters for multiple associate clusters, while ensuring that, during use, compute resources are allocated to a particular cluster. This may reduce and/or avoid vulnerabilities arising from a use of shared resources in a virtualized and/or cloud environment.

The invention relates to a method for providing a fault-tolerant global time via a time server in a distributed real-time computer system, wherein the time server comprises four components which are connected to one another via a bi-directional communication channel. At a priori defined periodic, internal synchronization times, each of the four components transmits an internal synchronization message, which is simultaneously transmitted to the other three components, from which each internal computer of a component determines a correction term for the tick counter contained in its component and corrects the reading of the local tick counter by this correction term.

Example implementations relate to application-specific policies for failing over from an edge site to a cloud. When an application becomes operational within an edge site, a discovery phase is performed by a local disaster recovery (DR) agent. I/O associated with a workload of the application is monitored. An I/O rate for data replication that satisfies latency characteristics of the application is predicted based on the incoming I/O. Based on results of tests against multiple clouds indicative of their respective RTO/RPO values, information regarding a selected cloud to serve as a secondary system is stored in an application-specific policy. The application-specific policy is transferred to a remote DR agent running in the selected cloud. Responsive to a failover event, infrastructure within a virtualized environment of the selected cloud is enabled to support a failover workload for the application based on the application-specific policy.

Systems and methods for managing a highly available distributed hybrid database comprising: a memory storing instructions; and one or more processors configured to execute the instructions to: receive a query from a user device to retrieve data from a distributed database comprising a source node, a first plurality of replica nodes, and a second plurality of replica nodes, wherein the source node and the first plurality of replica nodes form a transactional cluster, and wherein the second plurality of replica nodes forms an analytical cluster; determine whether to process the query using the transactional cluster or the analytical cluster based on one or more rules; translate the query into a first protocol that the determined cluster comprehends; select a replica node corresponding to the determined cluster; process the query using the selected replica node; and send data associated with results from processing the query to the user device.

An illustrative method for storing disaster recovery data includes receiving a plurality of copies of data stored by a first memory device. Each of the plurality of copies includes a plurality of blocks of data. The method also includes storing, in a second memory device, the plurality of copies in an object-oriented format, determining, using recovery time objectives, a number of the plurality of copies to be stored in a block-oriented format, and selecting a subset of the plurality of copies having the determined number of the plurality of copies. The method further includes assigning each of the other copies of the plurality of copies to one of a plurality of clusters. Each cluster of the plurality of clusters includes one of the subset of the plurality of copies. The method also includes determining, for each cluster, a copy having a highest number of blocks also present in the other copies of the cluster and storing, in the block-oriented format, the determined copy from each cluster in a third memory device.

Described are examples for deploying workloads in a cloud-computing environment. In an aspect, based on a desired number of workloads of a process to be executed in a cloud-computing environment and based on one or more failure probabilities, an actual number of workloads of the process to execute in the cloud-computing environment to provide a level of service can be determined and deployed. In another aspect, a standby workload can be executed as a second instance of the process without at least a portion of the separate configuration used by the multiple workloads, and based on detecting termination of one of multiple workloads, the standby workload can be configured to execute based on the separate configuration of the separate instance of the process corresponding to the one of the multiple workloads.

Replicated instances in a database environment provide for automatic failover and recovery. A monitoring component can periodically communicate with a primary and a secondary replica for an instance, with each capable of residing in a separate data zone or geographic location to provide a level of reliability and availability. A database running on the primary instance can have information synchronously replicated to the secondary replica at a block level, such that the primary and secondary replicas are in sync. In the event that the monitoring component is not able to communicate with one of the replicas, the monitoring component can attempt to determine whether those replicas can communicate with each other, as well as whether the replicas have the same data generation version. Depending on the state information, the monitoring component can automatically perform a recovery operation, such as to failover to the secondary replica or perform secondary replica recovery.

Herein are resource-constrained techniques that plan ahead for resiliently moving pluggable databases between container databases after a failure in a high-availability database cluster. In an embodiment that has a database cluster that hierarchically contains many pluggable databases in many container databases in many virtual machines, a computer identifies many alternative placements that respectively assign each pluggable database instance (PDB) to a respective container database management system (CDBMS). For each alternative placement, a respective placement score is calculated based on the PDBs and the CDBMSs. Based on the placement scores of the alternative placements, a particular placement is selected with a best placement score that indicates optimal resilience for accommodating adversity such as failover and overcrowding.

Examples of systems are described herein which may dynamically allocate compute resources to recovery clusters. Accordingly, a recovery site may utilize fewer compute resources in maintaining recovery clusters for multiple associate clusters, while ensuring that, during use, compute resources are allocated to a particular cluster. This may reduce and/or avoid vulnerabilities arising from a use of shared resources in a virtualized and/or cloud environment.