Dead Bare Metal, High Availability, and Being Clustered
In the community of IT professionals, "being clustered" can take on whole new meaning when you're staring at failed server hardware (aka "dead bare metal") and wondering why you paid all that money for (and spent all that time configuring) clustering software, only to have it not save you from disaster.
We recently attended a disaster recovery trade show, and it became very clear to us that the industry is still fundamentally lacking a straightforward, reliable solution to "high availability" in the face of a hardware failure.
But let's start by defining high availability.
In every company, servers can be divided into three groups: clustered / mirrored, highly available, and important.
The "clustered / mirrored" servers are those who must present a single face to other servers / users (regardless of the number of actual machines doing processing) and who cannot suffer even a second of service interruption. Such servers include things like trade processors, or Automatic Teller Machine backend servers.
For such servers, clustering and mirroring software - software used to meld many physical instances of independent operating servers into a single functional unit, and replicate actions - makes sense. Clustering and mirroring software ensures that if there's the slightest hiccup in even the application (much less the OS or physical server) on any machine in the cluster, another machine will automatically "pick up" where the first left off.
Yet such software is exceptionally expensive and complex to correctly install and configure - and has significant limitations. For example, disaster recovery demands that there be at least one physical machine per clustered application stack. So clustering and mirroring would ideally be used only as absolutely necessary.
At the other end of the spectrum, the "important" servers are those who can suffer some downtime without significant adverse impact. For example, report generation servers can effectively be down without any repercussions as long as they're available when reports are needed (daily, weekly, monthly...?). Such servers can safely be backed up on tape, or associated with "cold standby" servers.
Yet 80% of company servers are in the midground: "highly available". These are the servers which don't need real-time coverage - they have store & forward approaches - but which must be recoverable to current state in five minutes or less. Such servers include Exchange or other email servers, ERP and CRM applications, file & print, and other daily operating servers.
For these servers, the goal is fast recovery - from dead bare metal to live, connected (to network and storage) servers in five minutes or less.
Yet too many companies still ignore these servers, judging them (correctly) to be too expensive to cluster. (See our prior month's blog on recovery time).
There is a better way. Scalent can take servers from dead bare metal to live connected servers, in five minutes or less, on disparate hardware. So there's less exposure and less cost, and yet high availability becomes a reality.
Come talk to us. Don't let yourself get clustered.
-- Kevin Epstein, VP Marketing, January 2007
We recently attended a disaster recovery trade show, and it became very clear to us that the industry is still fundamentally lacking a straightforward, reliable solution to "high availability" in the face of a hardware failure.
But let's start by defining high availability.
In every company, servers can be divided into three groups: clustered / mirrored, highly available, and important.
The "clustered / mirrored" servers are those who must present a single face to other servers / users (regardless of the number of actual machines doing processing) and who cannot suffer even a second of service interruption. Such servers include things like trade processors, or Automatic Teller Machine backend servers.
For such servers, clustering and mirroring software - software used to meld many physical instances of independent operating servers into a single functional unit, and replicate actions - makes sense. Clustering and mirroring software ensures that if there's the slightest hiccup in even the application (much less the OS or physical server) on any machine in the cluster, another machine will automatically "pick up" where the first left off.
Yet such software is exceptionally expensive and complex to correctly install and configure - and has significant limitations. For example, disaster recovery demands that there be at least one physical machine per clustered application stack. So clustering and mirroring would ideally be used only as absolutely necessary.
At the other end of the spectrum, the "important" servers are those who can suffer some downtime without significant adverse impact. For example, report generation servers can effectively be down without any repercussions as long as they're available when reports are needed (daily, weekly, monthly...?). Such servers can safely be backed up on tape, or associated with "cold standby" servers.
Yet 80% of company servers are in the midground: "highly available". These are the servers which don't need real-time coverage - they have store & forward approaches - but which must be recoverable to current state in five minutes or less. Such servers include Exchange or other email servers, ERP and CRM applications, file & print, and other daily operating servers.
For these servers, the goal is fast recovery - from dead bare metal to live, connected (to network and storage) servers in five minutes or less.
Yet too many companies still ignore these servers, judging them (correctly) to be too expensive to cluster. (See our prior month's blog on recovery time).
There is a better way. Scalent can take servers from dead bare metal to live connected servers, in five minutes or less, on disparate hardware. So there's less exposure and less cost, and yet high availability becomes a reality.
Come talk to us. Don't let yourself get clustered.
-- Kevin Epstein, VP Marketing, January 2007
posted by Scalent Systems at 12:38 PM
0 Comments:
Post a Comment
<< Home