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....
- The land of Milk and Sammy: Free music app touted by Samsung
- The long war on 'DRAM price fixing' is over: Claim YOUR spoils now (It's worth a few beers)
- Privacy warriors lob sueball at Facebook buyout of WhatsApp
- 20 Freescale staff on vanished Malaysia Airlines flight MH370
- Dell thuds down low-cost lap workstation for
cheapfrugal creatives or engineers