Re: Beginnning to think about VMware and SCO 5.0.5
- From: Nico Kadel-Garcia <nkadel@xxxxxxxxx>
- Date: Wed, 25 Jun 2008 01:38:38 -0700 (PDT)
On 25 Jun, 08:48, "Steve M. Fabac, Jr." <smfa...@xxxxxxx> wrote:
I have not touched VMWare and don't know where to
start to investigate this issue. So I thought I'd
post it here where several users have implemented various
systems for their own use or client's to solicit recommendations
on suitable system configurations to replace the client's
current servers.
The client running SCO 5.0.5 Enterprise on two
servers, one is the live production and the other is
a "hot spare."
Gack. Can you get the clients upgraded to 5.0.7? There are real
problems installing older versions of OpenServer under VMware, due to
issues with older drivres for the emulated BusLogic SCSI controller.
These are identical SuperMicro PIII 1.4Ghz machines with
512M RAM and a DPT 3754U2 RAID controller with 16M cache RAM,
and two 36G SCA 10K disks in RAID1.
Time to upgrade: you're going to take a serious performance hit from
virtualization. I like Dell 2950's and 2970's, which are what a number
of Xen consultants use, and give decent performance for VMware
Workstation.
Both machines are backed up each night to their own Sony
SDT-9000 DAT drive. And the application data directories and
user home directories are copied from the live server to the
backup server before the tape backup runs.
You need to think hard about your server technology. VMware ESX is
RHEL 3, stripped down to a nerarly useless micro-installation. As
such, you're nearly compelled to use VMware's backup tools or install
expensive backup tools directly on your SCO virtual instances. But
such backup services are pretty inefficient, and prone to all sorts of
problems, and the ability to do bare metal restorations on OpenServer
is.... awkward.
I've switched to using rsnapshot on my OpenServer boxes, and
downloading nightly images to a centralized backup server with tape
drives on it, or with a Backup Exec or other network client. The
backup server can then provide NFS or otherwise authorized access to
the snapshots, to the server that got backed up, for users to have
file recovery from snapshots. It can save one heck of a lot of work
mounting tapes.
Charged with upgrading this hardware, it makes sense to plan
to migrate to a single CPU system board hosting a 2-3 GHz dual
or quad core Xeon CPU. I would then replace the full length
DPT RAID controllers with a current technology RAID controller
either SATA or SAS with suitable 76G to 146G hard drives in RAID1
Think about speed. SAS can go up to 15K RPM's but have smaller sizes,
SATA is typicall 7200 RPM at the 500 GB or larger sizes.
Clearly, moving both live and backup systems to modern hardware
will require upgrading the SCO 5.0.5 OS to either 5.0.7 or
SCO Openserver 6.0 on both machines.
I've heard bad reports of 6, but I'm not sure I trust them and don't
have time to pursue it. If you find a source for cheap 5.0.7 licenses,
post it! I'd love to upgrade the 5.0.6 that I'm working with.
What's the current opinion on a solid system that will run either
5.0.7 or 6.0 and have drivers for a RAID controller?
An alternative strategy I'd like to offer the client is a configuration
using VMWare to Virtualize both the primary and backup 5.0.5
servers.
Xen won't do it, it doesn't support SCO OpenServer (and shows no signs
of ever doing so). VMware ESX is expensive and will buy you,
personally, nothing. Get the VMware Workstation, spend a bit of time
integrating it to your needs, and you can install various SCO
OpenServers with emulated IDE controllers that require nothing in
terms of SCSI driver wackiness to get installed.
I've checked the VMWare web site and I see VMW products ranging
in price from $3624 to $21824 and I have no clue on how to
specify the product the client needs.
Unless you need a lot of GUI's and live migration, stick with VMware
Workstation 6. The ability to use IDE emulation will save you hours of
work installing and managing SCO OpenServer.
Please comment on the following:
1) One or two hardware platforms? The client desires to maintain
hardware redundancy so that if the primary box goes down, we can
switch operations to the secondary box.
You've just answered your own question.
2) Then should I use one platform to host the primary (live) 5.0.5
instance and a second VMWare platform hosting a running instance
of the current backup server? This continues to require we take
the time to copy the application data from the primary instance
to the backup instance so that the backup instance is ready to
go should the primary box fail.
Yup. Welcome to rsnapshot. Depending on the data, you can fold up
hourly or daily copies of entire OS's to take much less space than
you'd expect, by hardlinking duplicate files.
3) Or, not bother to keep a backup 5.0.5 server running on the redundant
VMWare host but just migrate the live 5.0.5 image from the primary
VMWare host to the backup VMWare host as needed? Can that even be
done?
It requires storage of the 5.0.5 image somewhere reliable. That image
has to be on a centralized block device, such as an iscsi server or
fiber channel array. Expensive, and unnecessary for such a small
instance, and you're still vulnerable to failures of that storage
array.
4) How do we back up the live 5.0.5 server? Continue to use a dedicated
SONY tape drive and BackupEdge running in the live 5.0.5 instance?
Or is backup performed at the VMWare level? Is that reliable?
VMware can make snapshots of live instances, but if you're running
databases, this is begging for corruption when you try to start a new
instance from that snapshot. The VMware 'tools' normally available for
backing up clients *will not work* in SCO OpenServer. You need to have
a system, besides the VMware images, that can talk to your backup
media. This is why I like VMware Workstation, running on a nice stable
OS like RHEL or CentOS, that can support backup solutions, monitoring
solutions, etc., incidental to their use as VMware servers.
5) where is the UPS communication and monitoring software installed?
under 5.0.5 or VMWare? Do we shutdown the 5.0.5 instance and then
shutdown VMWare and power off the UPS to preserve the UPS battery?
There are theoretically ways to get VMware instances to talk to UPS
devices directly. VMware has no official support for SCO OpenServer,
and it's much easier to do from the VMware server. The underlying RHEL
3 used for VMware ESX is an antique 2.4 Linux kernel, it's a wildly
out of date OS, and it's deliberately stripped down. You cannot expect
anything to operate with it other than VMware and VMware sold tools.
There's also a fascinationg problem with VMware and SCO Openserver
systems and clocks, which I've written about before, which you can see
at http://unix.derkeiler.com/Newsgroups/comp.unix.sco.misc/2008-06/msg00041..html
I'm sure that there are other questions that I have not thought of that
will have to be answered to design the optimal strategy for the client.
If you can answer any of the above questions or offer insights into
other important considerations, please post them.
--
Steve Fabac
S.M. Fabac & Associates
816/765-1670
I'm a consultant, in the UK and pretty busy right now, or I'd offer to
take it up as a project. Can you find a VMware guru near you?
.
- Follow-Ups:
- Re: Beginnning to think about VMware and SCO 5.0.5
- From: Bill Campbell
- Re: Beginnning to think about VMware and SCO 5.0.5
- References:
- Beginnning to think about VMware and SCO 5.0.5
- From: Steve M. Fabac, Jr.
- Beginnning to think about VMware and SCO 5.0.5
- Prev by Date: Beginnning to think about VMware and SCO 5.0.5
- Next by Date: Re: OSR505 and ld (was OSR505 and GCC)
- Previous by thread: Beginnning to think about VMware and SCO 5.0.5
- Next by thread: Re: Beginnning to think about VMware and SCO 5.0.5
- Index(es):
Relevant Pages
|
|
