Thursday, February 24, 2005
[Enterprise : Management]DR tip: separate servers from applications
DR tip: separate servers from applications
By Mike Talon, TechRepublic
Tuesday, February 8 2005 10:44 AM
Many times, when discussing Disaster Recovery (DR), engineers tend to lump together both servers and the applications that sit on those servers.
The mistake made in these situations is that most disaster scenarios require only a limited number of users or systems be supported by an application, which in turn will require fewer server resources than the frontline version of the app. I must admit I've fallen into this habit myself on occasion, and very few qualified engineers are immune.
The main issue with this line of thinking is that--in many cases--doing so will limit your ability to failover applications, and this will often force you to allocate a larger budget number to a disaster recovery project than is necessary. There are two common repercussions that can come about as a result of not thinking about applications separately from servers:
* You may allocate an entire failover server to an application that could have shared space with another app on a DR server.
* You could also allocate hardware that is powerful enough to handle normal operations to the DR center, when only a small sub-set of the total processing power is needed for failover scenarios.
Single-engine applications
Many applications must be allocated to their own servers in order to operate at top capacity or to operate at all.
Common examples are data systems that are single-engine programs, where only one copy of the software can conceivably run at any given time. In these cases, you will no doubt find that you do have to protect and failover these applications and servers as a unit. However, you may not need to allocate nearly the same budget amount to the backup data-systems as to those in production.
Unless all operations are going to failover in the event of an emergency, you will have far fewer users--both internal and external--after a disaster has occurred. Because of this, your data-systems will almost definitely be able to operate with much lower levels of hardware in terms of CPU, RAM and other critical and often expensive components. In many cases, you can even use equipment made available by a hardware refresh to be repurposed as disaster recovery equipment.
In the majority of cases, applications have no problem sharing servers with other applications. A large number of applications are beginning to be built with this idea in mind, allowing for multi-instancing or the ability to limit the amount of system resources they consume. This allows you to either failover multiple applications to a single physical machine, or deploy multiple redundant instances of the same application, depending on the application in question.
Just make certain to properly size the DR servers so they can handle the load of multiple applications, keeping in mind that there will be fewer users on each app.
As server virtualization tools become more mature and readily available, you will be further empowered to create customized combinations of failover systems that take into account the distinction between applications and their parent servers.
No matter what combinations of solutions you decide on, taking this into account during disaster recovery planning will ensure that you have the most effective combination of budget and protection.
By Mike Talon, TechRepublic
Tuesday, February 8 2005 10:44 AM
Many times, when discussing Disaster Recovery (DR), engineers tend to lump together both servers and the applications that sit on those servers.
The mistake made in these situations is that most disaster scenarios require only a limited number of users or systems be supported by an application, which in turn will require fewer server resources than the frontline version of the app. I must admit I've fallen into this habit myself on occasion, and very few qualified engineers are immune.
The main issue with this line of thinking is that--in many cases--doing so will limit your ability to failover applications, and this will often force you to allocate a larger budget number to a disaster recovery project than is necessary. There are two common repercussions that can come about as a result of not thinking about applications separately from servers:
* You may allocate an entire failover server to an application that could have shared space with another app on a DR server.
* You could also allocate hardware that is powerful enough to handle normal operations to the DR center, when only a small sub-set of the total processing power is needed for failover scenarios.
Single-engine applications
Many applications must be allocated to their own servers in order to operate at top capacity or to operate at all.
Common examples are data systems that are single-engine programs, where only one copy of the software can conceivably run at any given time. In these cases, you will no doubt find that you do have to protect and failover these applications and servers as a unit. However, you may not need to allocate nearly the same budget amount to the backup data-systems as to those in production.
Unless all operations are going to failover in the event of an emergency, you will have far fewer users--both internal and external--after a disaster has occurred. Because of this, your data-systems will almost definitely be able to operate with much lower levels of hardware in terms of CPU, RAM and other critical and often expensive components. In many cases, you can even use equipment made available by a hardware refresh to be repurposed as disaster recovery equipment.
In the majority of cases, applications have no problem sharing servers with other applications. A large number of applications are beginning to be built with this idea in mind, allowing for multi-instancing or the ability to limit the amount of system resources they consume. This allows you to either failover multiple applications to a single physical machine, or deploy multiple redundant instances of the same application, depending on the application in question.
Just make certain to properly size the DR servers so they can handle the load of multiple applications, keeping in mind that there will be fewer users on each app.
As server virtualization tools become more mature and readily available, you will be further empowered to create customized combinations of failover systems that take into account the distinction between applications and their parent servers.
No matter what combinations of solutions you decide on, taking this into account during disaster recovery planning will ensure that you have the most effective combination of budget and protection.
# posted by MiDBA @ 2/24/2005 09:58:00 AM 
