Server Recovery

Open Minds April Newsletter

2011-03-29T07:06:00.001-07:00

	Friend on Facebook
	Follow on Twitter

SteelEye Updates

Version 7.3 of Lifekeeper for Linux gets released

Version 7.2 of Lifekeeper for Windows gets released

Solution provided by Open Minds- Low end protection through to enterprise protection for servers!

SteelEye Protection Suite for Linux V7.3 Now Available
On February 15, SIOS released version 7.3 of the SteelEye Protection Suite for Linux. Read more...

SteelEye Protection Suite for Windows v7.2 Now Available
On February 17, version 7.2 of the SteelEye Protection Suite for Windows was also released. Included in this update:

DataKeeper and DataKeeper Cluster Edition 7.2
LifeKeeper for Windows v7.2 and Protection Suite. Read more...

If you own annual support, the upgrade to this release is free. Contact support@openminds.co.uk to request the new bits. Complete details on version Lifekeeper for Linux 7.3 and Windows Lifekeeper 7.2 are available in the release notes (available upon request).

Solutions by Open Minds:

Data replication to iSCSI

More...

Data Replication and Manual Restore

More...

High Availability and Disaster recovery

More...

Copyright © 2011 Users:Open Minds Has Ltd, All rights reserved.
Our mailing address is:
Open Minds HAS Ltd
The Public
New Street
West Bromwich
B70 7PG

Open Minds April Newsletter

2011-03-29T07:05:00.001-07:00

	Friend on Facebook
	Follow on Twitter

SteelEye Updates

Version 7.3 of Lifekeeper for Linux gets released

Version 7.2 of Lifekeeper for Windows gets released

Solution provided by Open Minds- Low end protection through to enterprise protection for servers!

SteelEye Protection Suite for Linux V7.3 Now Available
On February 15, SIOS released version 7.3 of the SteelEye Protection Suite for Linux. Read more...

SteelEye Protection Suite for Windows v7.2 Now Available
On February 17, version 7.2 of the SteelEye Protection Suite for Windows was also released. Included in this update:

DataKeeper and DataKeeper Cluster Edition 7.2
LifeKeeper for Windows v7.2 and Protection Suite. Read more...

If you own annual support, the upgrade to this release is free. Contact support@openminds.co.uk to request the new bits. Complete details on version Lifekeeper for Linux 7.3 and Windows Lifekeeper 7.2 are available in the release notes (available upon request).

Solutions by Open Minds:

Data replication to iSCSI

More...

Data Replication and Manual Restore

More...

High Availability and Disaster recovery

More...

Copyright © 2011 Users:Open Minds Has Ltd, All rights reserved.
Our mailing address is:
Open Minds HAS Ltd
The Public
New Street
West Bromwich
B70 7PG

Exchange Server Disaster Recovery Solutions

2011-02-28T07:00:00.001-08:00

Microsoft Exchange server downtime can cost companies millions of pounds a year. Technical consultants therefore work with these organisations to reduce / minimise downtime through the implementation of high-availability systems and disaster-recovery systems. Building a geographically dispersed Exchange cluster is not a simple task; it requires proper planning, testing, deployment and validation. In this blog we aim to cover the basic steps during the planning stage for your company’s high availability/ disaster recovery plans. You have taken the first and most critical step toward deploying the system – recognising the need!
The process begins with the initial decision to implement an Exchange disaster-recovery system and continues as long as that system is in production. In the planning phase, you must answer these critical questions:

· What is the recovery time objective for the system?

· Based on the rate of change and expected growth, what bandwidth is required between the primary site and the disaster recovery site?

· What pieces of the system besides the Exchange server and processes them-selves must be monitored and recovered? Is there a minimum set of functionality that's acceptable for some time following recovery? If so, what is that subset?

· Are there site-specific error conditions that should be optimised for in the monitoring phase?

· Will automatic fail-over be allowed, or should administrator notification be the first recovery action?

· Which e-mail clients must be protected during fail-over? What access methods do they use? And how will these be migrated to the disaster recovery site during recovery?

The choice of a disaster recovery site should be the first decision you make. For some organisations backing up to a remote office is the perfect solution while others may look to collocated hosting centres that provide full redundancy for power and network connectivity. You need to ensure which ever route is take there are techniques and procedures in place for building a test environment, staff used to build the DR/HA environment should also be heavily involved in testing solutions and they should be hands-on in the deployment and validation stages.
The testing phase is often difficult because properly emulating a production Exchange environment within a test lab requires simulating cross-site network connectivity, user load, the influence of adjunct programs such as backup jobs and other factors unique to the specific environment. The closer you can get to a mirrored production environment within the test lab, the fewer issues you will see arise during deployment.
In testing, you are looking to answer questions such as these:

· Does the failover software perform as expected on both detection and recovery?

· Does the data replication software perform as expected in terms of speed and data consistency?

· Is there any noticeable performance impact on end users from the presence of the monitoring or data replication software?

· Are the various clients able to seamlessly migrate to Exchange running on the disaster recovery server?

Delivery of the solution should be straight forward if you assembled a team of experts and successfully emulated the production environment during the testing phase. Make sure you schedule sufficient time for the initial data mirror across site and subsequent testing of failovers to the disaster recovery site and back to the production server. Each of those tests should validate that client redirection works as planned and that all services needed for a fully functional Exchange environment are recovered.
Following the initial deployment, it is recommended that failover tests be made after any change to the Exchange environment (such as installation of service packs, introduction of new services, etc.). Carrying out regular system checks will avoid the disaster recovery system not working correctly and resulting in being unable to bring Exchange into service because of an administrative change that was not accounted for.

Open Minds HAS Ltd has been working with customers to deploy Exchange Server High Availability for over 10 years. To speak to one of our experts please contact us on 0121 533 7178

Microsoft SQL Server protection

2011-02-16T07:36:00.001-08:00

Every business has mission critical applications and data. Therefore, it is very important to keep servers up and running all the time 24 X 7. In today’s world there is a need to store and process terabytes of data and it is vital to make this data highly available.

High availability is all about your site, database or email being accessible all the time. High availability solutions minimise the downtime for these mission critical applications, such as SQL, Exchange or IIS.

Microsoft SQL Server is a powerful database used to store and maintain data in businesses of various levels, be they small, medium or large. As such loss of a MS SQL server can have a huge impact on business operations.

Our consultants can take you through pre and post installation concepts and common issues you come across while working with SQL Server. We can help answer common question like what is the best concept for you? What should you use?

1. Database mirroring?

2. Log shipping?

3. Clustering?

4. Or just real-time replication.

Business Data is the core of your business and as such it should be protected. If you are business owner you should be asking yourself; how much time can the business afford without access to critical data or emails? How much money could I lose if my website, ordering system was down? Depending on the type of business you may also want to check if you have any service level agreements you could fail to deliver due to systems being down.

If you are the IT administrator you will be worried about getting the systems up and running again. Your main pain point will be how quickly can I get this server back online? The answer is days if you are using tape backup and minutes if you are using a failover solution.

Although in this blog I have covered Microsoft application we can cover Linux applications and also bespoke Microsoft or Linux applications.

If you have a project like this coming up please feel free to give Open Minds a call on 0121 533 7178.

Birmingham Hippodrome

2009-10-21T04:19:00.000-07:00

We are fortunate in having so many great customers, and this month we have been lucky enough to have released a case study from Birmingham Hippodrome. A customer introduced to us by one of our partners, eSpida.

We have been working with eSpida for around 7 years now, and we have worked with them on many projects. Including implementing systems as diverse as SAP on Linux, Microsoft Exchange Servers and Linux file servers. They have a great attitude and we thoroughly enjoy working with them.

To read more about the work we have done with Birmingham Hippodrome and eSpida, the case study is available here. For more info on eSpida visit: www.espida.co.uk

Ensuring High Availability on a budget

2009-06-18T02:55:00.000-07:00

In trying to meet the conflicting demands of costs and maintaining uptime, do you have to look for more creative ways to spend your IT budget?

Many organisations are turning to Linux for a proven and reliable solution. As the SteelEye Solution Centre for UK, Ireland and the Gulf region, Open Minds have been providing organisations with Linux clustering and Disaster Recovery for over 10 years, providing enterprise-grade clustering for the Linux market. SteelEye LifeKeeper for Linux provides enterprise-grade high availability for the most demanding deployments, supporting configurations built on commodity servers and storage whilst removing the need for shared storage and enterprise edition licences.

If you would like to find out more about how we provide enterprise grade Linux solutions to our customers, then please reply to this email with your telephone number and we will contact you to discuss your requirements in greater detail. The first five enquires will receive a copy of “Free Software, Free Society” selected essays of Richard M. Stallman, and all enquiries will be sent a free Linux distribution CD courtesy of the Linux Emporium. For more information on Linux adoption, click here

Celebrate with us...

2009-05-29T04:26:00.000-07:00

Open Minds are pleased to announce that the SteelEye Protection Suite for Windows was recently awarded the 2009 Global Product Excellence – Disaster Recovery Award by the Info Security Products Guide Awards. The Guide is the world’s most comprehensive guide on Info Security with the awards recognising and honouring excellence in all areas of information security.

The SteelEye Protection Suite for Windows provides a highly functional and cost effective combination of data replication and application recovery for your file servers and IIS servers.
To see for yourself why SteelEye Protection Suite for Windows was awarded the 2009 Global Product Excellence – Disaster Recovery Award, please send us and email to evalrequest@openminds.co.uk to request a free 30 day product evaluation license.

Furthermore, to celebrate SteelEye’s success, if you order the award winning SPS for Windows before 18th June 2009, we will give you LifeKeeper Protection Suite for Bespoke Applications, normally costing £350.00, free of charge. To take advantage of this offer, please quote 11990f when ordering your SPS for Windows.

Warm regards

The Open Minds Team

What is the cost to your business if your servers fail? FREE Calculator & free workshop

2009-04-30T04:56:00.000-07:00

When you look at your most critical servers, can you immediately identify what the impact on the business would be if these servers went down?

What would be the lost revenue?

What would be the lost productivity?

How about the damage to your reputation?

Or,
All of the above?

Visit our cost of Downtime Calculator, to build a business case for building a more resilient IT infrastructure.

By completing the Downtime Calculator, you now have an indication of the cost to your company should your servers fail, but you also need to identify two key objectives for your critical servers:

1. Recovery Time Objective (RTO):
How long does it take your business to recover from a server failure?

2. Recovery Point Objective (RPO):
At what point will you recover up to?

For example, your current operating system takes 5 hours to recover from server failure (RTO) but can only recover to the latest back-up which occurred at midnight (RPO):
Wednesday, 12noon, server failure occurs, it will be 5pm before server failure recovery (RTO), but, the latest back-up occurred midnight Tuesday (RPO), which would result in up to a 17 hour window of Downtime, depending on your company’s operating hours.

If you apply the 17 hour window of Downtime to your Calculator within System Restoration Cost, you will identify your IT department’s internal costs. This is only a fraction of the cost and lost productivity that the company will experience during server failure.

Your business case complete: In most cases, the cost of one hour’s server Downtime to the company will pay for a high availability or a disaster recovery solution. Delivering replication, helping you to achieve a virtually immediate recovery point, and, failover which helps you to achieve a minimal recovery time with the added benefit that system users will be unaware that there has been any server failure.

If you are interested in finding out how to plan for server failure and supporting your business case argument, then, please reply to this email or call 0121 313 3943 before 15th May and we will offer you a free place on our Disaster Recovery and High Availability Planning Workshop, worth £250.

For further information about the content of the Disaster Recovery and High Availability Planning Workshop, please refer to the document available here.

Do you test your systems recovery?

2009-04-08T08:24:00.000-07:00

Do you remember the amount of investment spent in time and money when you decided to implement your recovery solution?

Are you confident that your recovery systems will work should the worst happen?

To maintain the resilience of your LifeKeeper solution, we have devised a 5-Point Checklist:

When did you last complete a system test?

LifeKeeper systems need to be tested on a regular basis. It is recommended that you perform a failover test every month, but as a minimum, tests should be performed every 3 months. This is to make sure that when recovery on the back up server is invoked, it will run smoothly.

How often do you monitor the status of the mirror?

If the mirroring stops, it means that your data is no longer replicated. Therefore, it is critical to regularly monitor the status of your mirror. You can never really do this too often, so make it a regular practice to look at your mirror status at least daily.

Have you set up email notification for your servers?

Being notified by email or text every time a failover or switchover happens is extremely easy to set up. It is an easy way to be notified every time you need to pay some attention to your LifeKeeper servers.

Do you check your event logs regularly?

For the general health and housekeeping of the server, check event logs daily. Al events such as hardware failures, LifeKeeper information, quotas, application specific actions, logons are logged in your event logs. Failover can sometimes be prevented by detecting errors early enough and taking corrective action.

Do you verify all configuration changes? Eg passwords

If you perform changes to configurations such as passwords, settings, files, you will also need to ensure that these changes won’t affect the functionality of LifeKeeper. To do this you need to check your event logs. It is also advisable to test changes by performing a switchover. Of course, it is best to do this outside of normal hours, or in periods of low usage.

If you need assistance assessing the resilience of your high availability solution, Open Minds are able to perform a Health Check, either remotely or on-site to ensure that your LifeKeeper servers are running smoothly, ready, should the worst happen.

For more details about the Health Check please read the Open Minds Health Check document or contact us on sales@openminds.co.uk or 0121 313 3943.

Hyper V and Xen virtualisation

2008-12-01T01:42:00.000-08:00

There has been a certain buzz about the place here at Open Minds these last couple of weeks We are eagerly anticipating the release of several new products. The main event coming up in at the end of November is the release of DataKeeper. Datakeeper includes not just data replication for Windows server (which we have always been able to do with LifeKeeper Data Replication for Windows). It also includes replication of Hyper-V. We are finding that there is already a groundswell of demand for DataKeeper.

As far as virtualisation products go, we also have a recovery solution VirtualCentre recovery, usually the one single point of failure in a VMWare solution. We were the first in the market to produce this. For a preview video of the solution see the following link: http://www.steeleye.com/downloads/videos/datakeeper-and-hyper-v-wsfc/

2008-10-21T03:48:00.000-07:00

Tuning NFS

This is a brief blog outlining some general tweaking guidelines for NFS. Generally as NFS itself is relatively simplistic. You will notice the most change in performance by tweaking you network environment and the storage systems.
Below are a couple of idea which will hopefully improve your NFS performance.

One of the ways to improve performance in an NFS environment is to limit the amount of data the file system must retrieve from the server. This limits the amount of network traffic generated, and, in turn, improves file system performance. Metadata to be retrieved on the client and updated on the server includes:

access time
modification time
change time
ownership
permissions
size

Under most local file systems this data is cached in RAM and written back to
disk when the operating system finds the time to do so. The conditions under which NFS runs are far more constrained. An enormous amount of excess network traffic would be generated by writing back file system metadata when a client node changes it. On the other hand, by waiting to write back metadata, other client nodes do not see updates from each other, and applications that rely on this data can experience excess latencies and race conditions. Depending on which applications use NFS, the attribute cache can be tuned to provide optimum performance. The following mount options affect how the attribute cache retains attributes:

acregmin – The amount of time (in seconds) the attributes of a regular file must be retained in the attribute cache.
acregmax – The amount of time (in seconds) the attributes of a regular file may remain in cache before the next access to the file must refresh them from the server.
Acdirmin – Same as acregmin, but applied to directory inodes
Acdirmax – Sam as acregmax, but applied to directory inodes

There are also two settings: actimeo, which sets all four of the above numbers to the same value, and noac, which completely disables the attribute cache. By increasing these values, one can increase the amount of time attributes remain in cache, and improve performance.

One of the most important client optimization settings are the NFS data transfer buffer sizes, specified by the mount command options rsize and wsize. E.g.:

# mount server:/data /data -o rsize=8192,wsize=8192

This setting allows the NFS server to reduce the overhead of client-server communication, allowing it to send larger transactions to the NFS server when the server is available. By default, most NFS clients set their read and write size to 8Kb, allowing a read or write NFS transaction to transfer up to 8Kb of file data. This transaction consists of an NFS read/write transaction request and a set of packets. In the case of a write, the payload is data carrying packets; if it’s read, they are response packets. By increasing the read and write size, fewer read/write transactions are required, which means less network traffic and better performance.

However setting the rsize and wsize to a figure above your mtu (usually set to 1500) will cause IP fragmentation when using NFS over UDP. IP Fragmentation and re-assembly require a significant amount of CPU resource at both ends of a network connection.
In addition, packet fragmentation also exposes your network traffic to greater unreliability, since a complete RPC request must be retransmitted if a UDP packet fragment is dropped for any reason. Any increase of RPC retransmissions, along with the possibility of increased timeouts, are the single worst impediment to performance for NFS over UDP.
Packets may be dropped for many reasons. If your network is complex, fragment routes may differ, and may not all arrive at the Server for reassembly. NFS Server capacity may also be an issue, since the kernel has a limit of how many fragments it can buffer before it starts throwing away packets. With kernels that support the /proc filesystem, you can monitor the files /proc/sys/net/ipv4/ipfrag_high_thresh and /proc/sys/net/ipv4/ipfrag_low_thresh. Once the number of unprocessed, fragmented packets reaches the number specified by ipfrag_high_thresh (in bytes), the kernel will simply start throwing away fragmented packets until the number of incomplete packets reaches the number specified by ipfrag_low_thresh.

Two mount command options, timeo and retrans, control the behavior of UDP requests when encountering client timeouts due to dropped packets, network congestion, and so forth. The -o timeo option allows designation of the length of time, in tenths of seconds, that the client will wait until it decides it will not get a reply from the server, and must try to send the request again. The default value is 7 tenths of a second. The -o retrans option allows designation of the number of timeouts allowed before the client gives up, and displays the Server not responding message. The default value is 3 attempts. Once the client displays this message, it will continue to try to send the request, but only once before displaying the error message if another timeout occurs. When the client reestablishes contact, it will fall back to using the correct retrans value, and will display the Server OK message.

If you are already encountering excessive retransmissions (see the output of the nfsstat command), or want to increase the block transfer size without encountering timeouts and retransmissions, you may want to adjust these values. The specific adjustment will depend upon your environment, and in most cases, the current defaults are appropriate.
Most startup scripts, Linux and otherwise, start 8 instances of nfsd. In the early days of NFS, Sun decided on this number as a rule of thumb, and everyone else copied. There are no good measures of how many instances are optimal, but a more heavily-trafficked server may require more. You should use at the very least one daemon per processor, but four to eight per processor may be a better rule of thumb. If you want to see how heavily each nfsd thread is being used, you can look at the file(s) in /proc/fs/nfsd. The last ten numbers on the n'th line in that file indicate the number of seconds that the thread usage was at that percentage of the maximum allowable. If you have a large number in the top three deciles, you may wish to increase the number of nfsd instances. This is done upon starting nfsd using the number of instances as the command line option, and is specified in the NFS startup script (/etc/rc.d/init.d/nfs on Red Hat) as RPCNFSDCOUNT. See the nfsd(8) man page for more information.

In general, server performance and server disk access speed will have an important effect on NFS performance. However the above will help you to start tweaking the system to improve the performance of your NFS resources.

These are just a couple of suggestions as to how to improve the general performance of your NFS systems. The list above is no where near exhaustive, however it points you in the right direction. Tuning the underlying technologies is generally the easiest way to see gain in performance with NFS and NFS itself in not that complex a file sharing protocol.

Linux NFS General Setup Guide

2008-10-14T05:57:00.000-07:00

The Network File System (NFS) was originally developed by Sun Microsystems in 1983, to allow a user on a client PC to access files over the network with as much ease as if accessing a local disk.

A unique aspect of NFS, which makes it appear seamless to the end-user, is that connecting to a NFS share does not require a password, and files on the server appear in every respect to be a users' own files. Security is enforced by limiting access to trusted hosts, and by using the standard Linux file system permissions. The UIDs and GIDs of users are mapped from the server to the client. Therefore, if a user on a client has the same UID and GID as a user on the server, they have access to files in the NFS share owned by that UID and GID. NFS is easy to grasp, which leads to quick and easy configuration. It is worthwhile to mention, that NFS does not use any encrypted communication, making it possible for data to be caught in transmission by a third-party. Also, improper management of users on a client can incorrectly give file access to the wrong user. However it is critical that the administrators of all allowed hosts are trusted.

In a general Linux scenario, in which one machine (the client) requires access to data stored on another machine (the NFS server) the general procedure for setting up the NFS environment is as follows:

The server runs NFS daemon processes (running by default as nfsd) in order to make its data generically available to clients.
The server administrator determines what to make available, exporting the names and parameters of directories (typically using the /etc/exports configuration file and the exportfs command).
The server security-administration ensures that it can recognize and approve validated clients.
The server network configuration ensures that appropriate clients can negotiate with it through any applicable firewall system.
The client machine requests access to exported data, typically by issuing a mount command.
If all goes well, users on the client machine can then view and interact with mounted filesystems on the server within the parameters permitted.

NFS shares are stored in the /etc/exports file, and are specified one per line. Each share can contain several hosts/options declarations. The general syntax is:

/share_path hosts_1(options) hosts_2(options) ... hosts_n(options)

For example:

/share *(ro,all_squash) 192.168.1.152(rw,root_squash)

(For more examples, see the exports man page).

To mount a NFS share on a client, add the share to the /etc/fstab file. The syntax is:

host:/share_path /local_mount_point nfs options dump fsck

For example:

server.openminds.local:/data /share nfs defaults 0 0

The hosts permitted to connect to a share can be specified in several ways (taken from the exports(5) man page):

Single host - This is the most common format. You may specify a host either by an abbreviated name resolvable in DNS or the hosts file, the fully qualified domain name, or an IP address.

Netgroups - NIS netgroups may be given as ‘@group’. Only the host part of each netgroups member is considered in checking for membership. Empty host parts or those containing a single dash (-) are ignored.

Wildcards - Machine names may contain the wildcard characters * and ?. This can be used to make the exports file more compact; for instance, *.openminds.local matches all hosts in the domain openminds.local. As these characters also match the dots in a domain name, the given pattern will also match all hosts within any sub-domain of openminds.local (e.g. host.subdom.openminds.local).

IP networks - You can also export directories to all hosts on an IP (sub-) network simultaneously. This is done by specifying an IP address and netmask as address/netmask where the netmask can be specified in dotted-decimal format, or as mask length (for example, either `/255.255.255.0' or `/24').
N.B. Wildcard characters generally do not work on IP addresses, though they may work by accident when reverse DNS lookups fail.

There are many options for shares. Here are some of the most common:

root_squash - Maps the root user to the nobody user. This prevents a user logged in as root on a client to gain root file access permissions on the server.
no_root_squash - Does not map the root user to the nobody user. The root user on a client has the same rights as the root user on the server.
all_squash - Maps all the UIDs and GIDs to the nobody user. This is useful if the share is to have anonymous access, much like an anonymous FTP server.
anonuid, anongid - If root_squash and all_squash are used, the UIDs and GIDs are mapped to the specified UID and GID instead of the nobody user.
ro - Forces all files on the share to be read-only. This is the default behavior.
rw - Allows write access to the share.
sync - Ensures data is written to disk before another request is serviced.

The NFS server is controlled with the /sbin/rcnfsserver script, and the client is controlled with the /sbin/rcnfs script. The major options are:

start
stop
restart

For example, to start the server, execute:

# rcnfsserver start

What is the difference between replication, high availability and disaster recovery?

2008-07-31T03:49:00.000-07:00

There is a lot of confusion about these terms, and it seems that everyone has their own definition so we thought that we would clarify these terms a little.Before we put label onto anything lets talk a little about what we are trying to do. Here are a number of scenarios:

We want to protect our data so we create another real-time copy somewhere else, this is typically on another server, which is located either locally or remotely
We want to minimise servers downtime, so we want to minimise the time interval between a server being down and a backup server coming back up in its place. The best way to do this is to put both the active and backup servers on the same LAN.
We want to protect our applications, so we want to minimise the time taken for users to re-gain access to their apps. Again the best way to do this is to put both servers on the same LAN.
We want to have the server recovery take place on a remote site to protect against site disasters
We want the application recovery take place on a remote site to protect against site disasters

Scenario no. 1 we call data replication, it requires replication software on both servers.

Scenario no. 2 we call server availability, it requires replication, monitoring and failover software on both servers.

Scenario no. 3 we call application availability and requires everything for Scenario 2 plus application-sensitive monitoring and recovery

Scenario no.4 we call disaster recovery, it will require data replication software, but it may also require a manual procedure for applications to restart on the backup server, and users to be able to reconnect to the disaster recovery site.

Scenario no. 5 is also called disaster recovery (hence the confusion), and it will require replication, monitoring and failover software. But the beauty of this solution is that it can cut down the work required when a disaster occurs such as repointing client connections, restarting the server on the backup site etc.

However, someone who knows what they are doing to oversee a disaster recovery is always recommended.
From our experience, we have found that labels are not as important as knowing what you want to achieve. Having a clear idea of what you want to happen in the case of downtime and having a capable individual to take responsibility for the project is an essential starting point for any successful recovery project.

How does your solution work with virtual servers

2008-06-25T06:24:00.000-07:00

There are products which move virtual servers from one server to another such as VMotion. Our solutions work alongside virtualisation solutions such as VMWare and Xen - on the one hand, they perform data replication between servers without the need for shared storage and on the other hand they perform application monitoring and recovery.

We monitor and recover at application level, not just at hardware level. This means that applications are monitored and recovered to a backup server. The active and the backup server can be physical or virtual. This brings me to the third differentiation. Our solutions work in both physical and virtual environments and any combination of physical or virtual. For example, we have many customers with physical environments who want to use a virtual server for a backup/failover server. The benefits of having virtual servers as backups are obvious (less hardware, less power etc), but many people have physical servers as active servers and do not want to invest in the additional licences and storage required to put in a fully virtualised solution.

So to summarise, we perform data replication without relying on any form or shared storage, we work at application level, and we work with any combination of physical and virtual infrastructure.

For more information on our virtual solutions.

What is the difference between the different types of replication, and what are the advantages of them? Which ones should I use?

2008-05-21T05:52:00.000-07:00

Firstly there are basically 2 types of replication technology.
1. File based replication and
2. Disk based replication

File based replication takes a view of a file system and is at a higher level than disk based replication which is implemented at device level, often as a device driver.

As for advantages, and disadvantages, disk based replication is more responsive as individual blocks of a disk are mirrored to the target system, creating a more immediate backup.

File based replication, because it looks at changed files, can be cumbersome if you have large files, as if it sees that a file has changed, even though you have only changed a few blocks, it will need to replicate the whole file.

The other types of replication are synchronous and asynchronous. The difference between these is that synchronous replication will wait for an acknowledgement from the target server, and asynchronous replication will continue to send writes to the target server without waiting for acknowledgements. In theory, waiting for acknowledgements sounds like a good idea, but in practice, it is usually used only for LAN based replication where additional bandwidth to allow this is available.

Advantages of volume-based replication:
- File-system independent. Works on all filesystems.

- Sits below file-system which allows replication engine to bypass using file-system calls (open, read, close). This places less burden on the host server which results in lower CPU utilization.

- Because we do not deal with files, there is no issue with open files not being replicated. There is also no requirement for agents being needed to deal with open files.

- Every bit on the data volume is replicated. This ensures that no files are missed due to improper configuration of the replication software and that any changes made volume metadata (such as access control lists) are also replicated.

For more information please Click Here for an independent article.

What does High Availability mean?

2008-02-07T02:42:00.000-08:00

The term High Availability was coined many years ago.

It was coined when uptime was defined in percentages. If a server is up all the time, then it is said to be 100% available. That is, it is always available to its users all the time. This is only possible with very specialist hardware and software. If it is down, say 1 hour a month for maintenance, then, looking at 24x365 = 8760 hours per year, it is down for 12 of those. In percentage terms, 12 hours out of 8760 is 0.137%, it is up for 99.86%. Or, available for 99.86% of the time.

Often, people talk about three nines or four nines availability, this means 99.9% or 99.99% availability. There was a time when High Availability was defined in terms of percentage of uptime, if a system had greater than 99.9% availability, it was classed as highly available, and if it had greater than 99.99% availability it was fault resilient.

Today, I would say that there is no real ‘definition’ of high availability, the term is used to mean that a system is resilient and all single points of failure (SPOF) have been eliminated. Its failure modes are known and well defined, including networks and applications. Some of this resilience is achieved through doubling up on hardware such as network cards, power supplies etc, and some is achieved through software such as LifeKeeper.

I would say that today, the term means that users have their systems available for their use when they need it. It requires the administrator to think carefully about downtime, and plan for system recovery, should a failure occur. In other words, to plan for failure of each critical component, have a recovery scenario ready and know in advance the amount of time the systems is likely to be down for. It also means that this recovery time is acceptable to your users.

Frequently Asked Questions on Server Recovery

2008-01-30T07:34:00.000-08:00

How does Server Recovery Help?
The solution provides automated failover of any application on Windows and Linux. The failover can be on a LAN or a WAN environment. When failover occurs, it can notify you via email or text to inform you what has happened.

How does the solution work on a WAN?
The LAN and WAN solutions work in exactly the same way. However, for a WAN solution external factors such as bandwidth need to be taken into account.

How does the replication work?
The replication works at block level, as one data block is changed, it is copied to the backup server. Are there mechanisms to minimize the traffic on the network? There are various ways that the traffic on the network is reduced. For example, white space is not replicated, various levels of compression can be set, or asynchronous replication can be used. For more details, refer to the documentation or contact us.

How do the licences work?
The software is licenced on a per server basis. It is independent of the number of CPU’s or the underlying OS. Each product is licenced separately. You will require a combination of Data Replication, the LifeKeeper core software and a number of application recovery kits, which have been written to monitor

Do I need hardware to be the same?
The LifeKeeper solution works with dissimilar hardware. However, it does require the operating system to be the same on both the active and standby servers.

Do I need shared storage?
Although it works with shared storage, this is not a requirement. Where there is no shared storage between the two servers, data replication is used to provide an up-to-date copy of the data on the bakup server.

I have non standard applications that I need to recover can you help?
Openminds can recover any application with out customization kit, this will allow you to put in the start and stop scripts for your application and the rest of the monitoring that uses LifeKeeper is generated from these.