back to article Marathon ships He-Man virtual machine protector

What happens when my physical machine collapses? That's what a lot of virtualization newcomers wonder about while considering the prospect of stacking tons of applications on a single, physical box. Virtualization players such as VMware and Symantec/Veritas have addressed these concerns through HA (high availability) packages …


This topic is closed for new posts.
  1. Pyros

    Begs the question...

    With a company name like "Marathon Technologies," is their main server named Durandal and does it run funny, according to their IT staff?

    Mine's the armor-cased one with the sub-machine rifle on the back.

  2. Anonymous from Mars

    Bleeding obvious?

    "As you might expect, the Marathon everRun VM architecture requires a customer to run duplicate systems, so that one can pick up where the other left off when failures happen."

    Now, I may not be following the virtualization bandwagon as closely as everyone else, but in a virtualization environment, isn't it BLEEDING OBVIOUS to have two physical boxes working in tandem for failover?

    Or is this the next pitch to keep customers throwing cash at them?

  3. Jack Pastor

    This changes EVERYTHING !!

    A Tandem for well under $100K ?? The reason this doesn't run on VMware is a combinations of "closed source" and millions of lines of old code. Xen was a natural for these guys, and finally, shops that already have locked-in contract with VMware have a reason to look at Xen.

    There's a HUGE difference between "high Availability" and "Fault Tolerance" which si what these guys offer (and let's face it, if you're consolidating 10 servers down to one, having to buy a spare is downright CHEAP for what you get.

    I think some readers are missing the point. This is not FAILOVER. The is KEEP ON RUNNING .....

  4. The Cube

    A solution to a problem you shouldn't have

    The problem here is not the virtualisation platform, it is the legacy monolithic software that is too damn stupid to be run in more than one place. Clusters are not the answer to high availability, neither is shoring up bad applications with sticking tape and string. Less than 10% of service impacting failures are the hardware, 80% are the software or operator errors which begs the question, what happens to my 10% and my 80% when I add all the extra complication of this extra cluster-ware? (your 10% gets a tiny bit smaller whilst the loss of mainainability makes your 80% quite a bit larger).

    The solution to this problem is to stop buying legacy applications that have not been written to be fault tolerant at the application or database transaction level and still need clusters and other neolithic patches to make them work. Clusters and hardware replicating SANs are just a really good way to propagate a software fault from one place to another. Once customers walk away from this kind of jurassic code those vendors will either have to move into this century or go out of business, personally I am hoping for the latter...

    The real irony here is that Marathon clearly understand how to write an application that is fault tolerant but then waste that talent shoring up rubbish, perhaps Oracle and the other offenders should be taking some lessons in how to write software that works.

  5. amanfromMars Silver badge

    Not such an Alien Viewpoint ......?

    "Now, I may not be following the virtualization bandwagon as closely as everyone else, but in a virtualization environment, isn't it BLEEDING OBVIOUS to have two physical boxes working in tandem for failover?" ... By Anonymous from Mars

    Posted Monday 24th March 2008 23:21 GMT

    Sounds BLEEDING OBVIOUS to me too, Anonymous from Mars.

    And surely a Virtual Machine will always fail if it reverts to being just a physical box/physical boxes?

  6. Senor Beavis

    Holy shit

    amanfromMars' comment made sense. You are not amanfromMars

  7. The Avangelist

    What is the point?

    Virtualisation is THE dumbest concept ever and yet seems to be continuing to grow en mass.

    It is the biggest iPhone known to man and who wants that?

    Example of why it is stupid

    [NOTE] This can also be applied to WAN based VoIP systems

    My data center hosts as many servers as I like all running boxes with XP for example on them which have Office installed so that all my staff can log in and use slimlined licensed desktops.

    One server goes down. Not a problem I have fifty others to take up the strain.

    My ADSL line goes down to at the office. We are all up shit creek because BT wont come out to look at it for 3 days.

    We have a backup ISDN line but it will take 1 day to reroute all the traffic because i is set to go via proxy which was also being hosted at the data center.

  8. Curtis W. Rendon
    Paris Hilton


    You failed to make a point about virtualization.

  9. Jack Pastor

    Marathon is not a cluster

    I'm still not sure most people understand how this works. It is NOT a cluster, and at the highest level (System Fault Tolerance) there is no concept of FAILOVER. FAILOVER assumes some latency (up to and including re-starting the guests and then the applications without any real regard to their respective QoS.)

    Marathon is running one instance of an OS on two guests SIMULTANEOUSLY (Lockstepping) which is how Tandem and Stratus do it (but with proprietary hardware.)

    Data Centers don't always have a lot of choice in the applications they buy or the quality thereof. I think it is great that a company can make crap run flawlessly. Face, it, there is a lot of crap out there, and aside from coding your own (which is usually cost-prohibitive) all you can do is apply bandages. If someone makes a quality bandage, I think they should be applauded.

    BTW, Virtualization is one of the BEST concepts ever to hit IT, and I think history has already proven that. Now it's a matter of making it open and ubiquitous.

    Xen is helping to do that. Marathon is making it more viable for mission-critical apps.

This topic is closed for new posts.

Other stories you might like