Marathon Technologies is adding disaster-recovery capability to its everRun MX fault-tolerant code. Just last month, Marathon Technologies tweaked its updated everRun MX fault-tolerant clustering for virtual machine hypervisors, which allows for FT clustering of VMs that span more than one core. This is something that VMware …
"...like putting on suspenders as well as a belt..."
This had me puzzled for a bit: Suspenders are held up with a belt. Then I realised, the author is probably from across the pond and is talking about "belt and braces" and wasn't just mentioning an article of ladies underwear to get people to read something boring about servers.
Another not on the licensing if your product is not MS Exchange or SQL or one of the other MS short list of products you cannot use the standard license you must buy the Enterprise product!!?? we use Marathon for our customers with our own custom software and are not allowed to use Standard due to protecting non MS core technologies even tho we have it running on Windows Server.
Is it just me...
or isn't it possible to use applications that are geographically redundant without resorting to sh...I mean stuff like this? Back in the day with Exchange we used to advise our clients against clustering through the OS because it wound up causing more problems than it solved. Eventually they moved their redundancy to the application layer and our clients are finally humming along with redudancy that finally works.
I recall one client recently who was sure OS clustering was still the way to go with some bastardized solution that sounds an awful lot like some of this stuff... and wound up with a flaky, almost unsupportable infrastructure.
Maybe I'm just old school, but the whole rush towards many tiny little OS'es with the redundancy/fail-over duct-taped underneath an OS and application layer that has no idea what's going on just seems like insanity.
Then again, I'm not too hip with server infrastructures outside of e-mail... so maybe it's just me.
What about patching
As far as I know, this solution still doesn't address the database patching issue when using SQL Server. You have to shift the database to another member in the cluster so it can be rebooted after Patch Tuesday....this takes between 30-300 seconds where there is no service.
Other RDBMSes are available, I know, but assuming your application forces you to do it...
Patching less frequently, yes, an option, if you can get your IS people to agree....
- NASA boffin: RIDDLE of odd BULGE FOUND on MOON is SOLVED
- SOULLESS machine-intelligence ROBOT cars to hit Blighty in 2015
- BuzzGasm! Thirteen Astonishing True Facts You Never Knew About SCREWS
- Worstall on Wednesday YES, iPhones ARE getting slower with each new release of iOS
- Tor attack nodes RIPPED MASKS off users for 6 MONTHS