Linux Solutions

Replicate changes of data to a backup server in real-time, and monitor all your applications continuously. The backup server can be on a LAN (for local recovery) or a WAN (for disaster recovery).

When a server or application dies, or is required for system maintenance, the backup server is brought online, and users automatically connected to it.

When the main server is returned to service, changes in data are automatically resynchronised and recovery is seamless and stress-free.

wsb0Benefits:

  • Replicate and monitor your Linux Servers
  • Failover automatically in case of data, server or application downtime
  • Email and/or text is sent to the administrator when an event happens
  • Automatic resynchronisation when a server is brought back into service
  • Return to service is seamless and easy
  • Easy to use and configure
  • Recover all of your standard and non-standard applications with our generic recovery kit

For a seamless recovery of your servers, SIOS Life Keeper from Open Minds guarantees to provide you with a complete disaster recovery solution ensuring that you maintain business continuity. Our high availability solutions will grant continuous data protection providing data replication as well as the monitoring of all your servers to ensure failover through the Java GUI.

SAP Protection

What happens to your business when your SAP system goes down, for any reason – hardware failure, administrator error, routine maintenance or local disaster? The impacts can easily include production and supply chain interruption, delivery delays, lost sales, customer service degradation, contractual liabilities and regulatory issues; the aggregate costs can be catastrophic.

That’s why many companies run their mission-critical SAP application server, web application server, and database environments on high-availability clusters configured for automatic switchover. Best practice implementations require a tightly integrated combination of clustering, continuous monitoring, data replication, and configurable recovery capabilities. But native support for these functions is limited or non-existent in SAP itself and do-it-yourself development for Linux-based environments can be complicated, time-consuming, error-prone, and expensive.

Fortunately, SIOS has a reliable, flexible and cost-effective solution with nearly a decade of proven service for over fifty major enterprise SAP deployments worldwide.

Integrated Application and Data Protection for SAP on Linux

SIOS Protection Suite for SAP on Linux (SPS-SAP) brings best-practice business continuity to SAP users with real-world resource constraints. It’s the industry’s most comprehensive and scalable solution for eliminating SAP server downtime from planned and unplanned outages. It addresses all levels of uptime requirements from local replication and failover to complete disaster recovery at a remote site, and it does so simply, reliably, and is affordable, with solutions that deploy in half the time and at half the cost of conventional point products.

MySQL Data Replication and Application recovery

Recover MySQL applications from a failure on the primary database server to a designated backup server without significant lost time or human intervention.
LifeKeeper is able to monitor all resources used by an application (IP, Disk, Volume) as well as checking that the application itself is running (for example it could execute a known data query). This proactive approach allows LifeKeeper to migrate an application in the event of a failure (for instance a network failure, local network card failure or even disk failure) to a different host.

Data Replication – eliminating the need for shared storage

Without shared storage, LifeKeepers data replication software can be used to mirror data to a remote server, and seamlessly handle the switch-over in the event of a failure.

LSB8

When data is written to disk, LifeKeeper data replication will mirror that data to a local or remote backup server. This ensures that the data is up to date in the event of a server or disk failure. The MySQL recovery kit enables switchover of MySQL applications to a backup server.

The data replication can occur over either a LAN or a WAN, and either synchronous or asynchronous approaches are available. Because the data replication software only transmits changes in data, and reads at the raw block level, it is efficient, versatile, relatively fast and is not dependant upon the file system type being used by the operating system.

The image illustrates the replication of data from one active node, to another backup node using the Data Replication software. Because the backup server will have an up to date copy of the data held on the active server, failover can occur at any time.

WSB12

Data replication over a Wide Area Network

The below image illustrates the data replication taking place over a Wide Area Network. As mentioned above, due to the efficiency of the data replication software, it is feasible for replication to take place to a remote site, allowing for optimal disaster recovery and data protection.

WSB12

LifeKeeper can run in an Active/Active or Active/Backup configuration

The diagrams so far have all shown MySQL running with LifeKeeper protection, in an Active/Backup configuration – i.e. one machine is always idle in case of emergency, this is an optimal configuration if performance is an issue. In some environments this redundancy of hardware may not be desirable, and a slight degradation of service may be acceptable over a short period of time (until the fault can be fixed with the primary server) and LifeKeeper can run in an Active/Active configuration as shown by the below diagrams.

wb21

The above diagrams show how LifeKeeper runs in an Active/Active configuration, where on failure of one node, the other node takes over and runs both services locally. An Active/Active configuration may use either shared storage, or the data replication discussed above. The Active/Active configuration allows for optimal resource usage combined with high availability; although in the event of a failover it is possible for performance to suffer if a server becomes heavily loaded.

Alternatively, if many servers are to be used, it is feasible to have an N+1 configuration where one machine acts as a backup to numerous active servers. In the event of more than one failover occurring, the applications can fail over to any other active machines, in an order determined by the administrator during installation / initial configuration.

LSB9

In a shared storage environment (FC/SAN/NAS/iSCSI)

Manage shared storage, and determine when to failover in the event of a localised failure on the local machine.

PostgreSQL

LifeKeeper is able to monitor all resources used by PostgreSQL (IP, Disk, File System) as well as checking that PostgreSQL itself is running (for example it could execute a known SQL query). This proactive approach allows LifeKeeper to initiate a failover to a different node in the cluster regardless of whether the fault was software related (O/S, Application etc) or hardware related (disk, network etc).

Server Organisation

LifeKeeper works through the server virtualisation concept, where all resources required for a particular application are available on all servers. This requires that there all nodes have access to binary files and application data. Generally binary files will be installed separately on each server, while application data will be shared or replicated between servers. The LifeKeeper PostgreSQL recovery kit allows the administrator to share or replicate the binary files between servers. Because the same resources are available to all nodes, it is necessary to be able to ensure data integrity across nodes, by only allowing one machine access to the data at any one time.

LSB8

PostgreSQL with Data Replication – eliminating the need for shared storage

Shared storage is often expensive, and does not allow for a cluster to span a LAN or WAN, so it can not provide a true disaster recovery solution. In addition, the shared storage itself is the single point of failure.

LifeKeeper’s data replication software can be used to mirror data to a remote server, and seamlessly handle the switchover in the event of a failure.

When data is written to disk, LifeKeeper data replication will mirror the data to a remote server. This ensures that the data is up to date in the event of a failover occurring.

In the event of a failover, LifeKeeper will bring the target of the mirror into service, and reverse the direction of replication (if possible). After this, the PostgreSQL server is started.

The data replication can occur on either a LAN or a WAN, and either synchronous or asynchronous approaches are available. Because the data replication software only transmits changes in data, and reads at the raw block level, it is efficient, versatile, relatively fast and independent of the file system used by the operating system.

The image below illustrates the replication of data from one active node, to another backup node using the replication software. Because the backup server will have an up to date copy of the data held on the active server, failover can occur at any time.

WSB12

PostgreSQL recovery over a Wide Area Network

The below image illustrates the data replication taking place over a Wide Area Network. As mentioned above, due to the efficiency of the data replication software, it is feasible for replication to take place to a remote site, allowing for optimal disaster recovery and data protection.

WSB12

Active/Active

The diagrams so far have all shown PostgreSQL running with LifeKeeper protection, in an Active/Backup configuration – i.e. one machine is always idle in case of emergency. In some environments this redundancy of hardware may not be desirable and LifeKeeper can run in an Active/Active configuration. LifeKeeper can run in an Active/Active configuration, where on failure on one node, the other node takes over and runs both services locally. An Active/Active configuration may use either shared storage, or the data replication discussed above. The Active/Active configuration allows for optimal resource usage combined with high availability.

LifeKeeper in an N+1 Configuration

Alternatively, if many servers are to be used, it is feasible to have an N+1 configuration where one machine acts as a backup to numerous active servers. In the event of more than one failover occurring, the applications can fail over to any other active machines, in an order determined by the administrator during installation / initial configuration.

LifeKeeper can manage shared storage, and determine when to failover in the event of a failure on the active machine. The image below illustrates LifeKeeper in a shared storage configuration.

LSB9

PostgreSQL in a shared storage environment

LifeKeeper ensures data integrity by locking access to a SCSI resource at the LUN level on shared storage. This eliminates any chance of data corruption occurring in a split brain scenario, and removes the requirement to purchase STONITH devices which add an extra layer of complexity to a solution.
This requires some form of external SCSI / NAS / RAID array, which is connected to all servers in the cluster. The storage unit itself should be configured to provide redundancy – providing fault tolerance at the data layer.

Samba File Shares Recovery

Samba enables Linux servers to act as file and print servers for Windows based clients. LifeKeeper allows the recovery of Samba file and print servers when a hardware or application failure occurs.

SAMBA Failover

The Samba Recovery provides a mechanism to recover protected Samba file and print shares from a failed primary server onto a backup server. LifeKeeper can detect failures either at the server level (via heartbeat) or resource level (by monitoring the Samba daemons, or IP resources) so that control of the Samba resources is transferred to a backup server. Other Samba services may coexist on a LifeKeeper server.

As with many other LifeKeeper configurations, it is possible to either use shared storage, or use the data replication option, or both.

Data Replication

This is a more economical option for smaller installations, where (generally) a private network is used between a pair of servers to replicate data over. This allows for a lower cost initial solution (reduced hardware costs), yet gives a high level of reliability.

LSB6

The other advantage of Data Replication is that there is no limit to the distance separating the machines (as long as sufficient bandwidth is available), this allows for a relatively easy set-up and configuration of a disaster recovery solution.

Shared Storage and Data Replication

This gives the scalability of shared storage on the local network, as well as the power of data replication for use across a local, or wide area, network – providing good performance and offsite disaster recovery.

Data Replication – removing the requirement for Shared Storage

Once data is written to disk, LifeKeeper data replication will mirror that data to a remote server. This ensures that the data is up to date in the event of a server or a disk failure. The SAMBA recovery kit then enables the switchover to a backup server.

LSB7

Shared Storage

This requires some form of external SCSI/ NAS/ RAID array, which is connected to all servers in the cluster. The storage unit itself should be configured to provide redundancy – providing fault tolerance at the data layer.

Samba Resource Hierarchies

A typical Samba hierarchy will be comprised of a Samba resource, one or more file system resources, one or more IP resources, and possibly a print services resource. An example of a resource hierarchy protecting a Samba file and print share in an active/active environment is shown below:

In this example, ServerA protects file share /Fshare-A; ServerB protects the file share /Fshare-B.
In addition, ServerA protects the print share /lp_publicprinter; ServerB does not protect a print share.

For a seamless recovery of your servers, SIOS LifeKeeper from Open Minds guarantees to provide you with a complete disaster recovery solution ensuring that you maintain business continuity. Our high availability solutions will grant continuous data protection providing data replication as well as the monitoring of all your servers to ensure failover through the Java GUI.

Apache Web Server

For a seamless recovery of your Apache servers, SIOS Life Keeper from Open Minds guarantees to provide you with a complete disaster recovery solution ensuring that you maintain business continuity. Our high availability solutions will grant continuous data protection providing data replication as well as the monitoring of all your Apache servers to ensure failover through the Java GUI.

LSB4

In a typical local configuration, data is replicated between the servers. Identical copies of the Apache Web Server configuration file, web documents, DSO modules (and their configuration files, if any), and the httpd executable reside in exactly the same locations on each server. MySQL databases are replicated between the active and backup servers. As there is no requirement for redundant servers, one possible scenario would be to have an active Apache server and an active MySQL server both acting as a hot backup to each other.

When the Apache hierarchy is switched over from one server to another, this particular httpd instance is stopped and the IP addresses are deactivated on the first server, then the IP addresses are reactivated and the instance started on the other server. Clients will then be automatically connected via TCP/IP to the identical web site on the other server.

Recovering Apache servers using Shared file systems

Apache web servers can be recovered using shared storage (below). The example below shows an active/active environment where the Apache server is acting as a backup for a SAMBA server. This eliminates the need to have a redundant server as a backup server.

Failover in an n+1 environment

Multiple servers can be protected simultaneously by setting up an N+1 configuration. The example below shows a typical server farm running multiple apache servers. These servers can be protected by a single backup server that will monitor all of the servers in the cluster. LifeKeeper allows up to 32 nodes in a cluster.

Disaster recovery to a remote site

To protect against a site disaster, failover to another site is achieved by recovering to server located in a separate location.

LSB5

The scenario above shows data replication taking place across a WAN to a backup server in a remote location. When Apache fails over, the data is up to date.