We can only get there through standardization. As long as different
vendors mess with whatever directories they want, we always run the risk
of missing or overwriting something during the service or upgrade
process. Careful inventory and change controls can circumvent the issue,
but it gets complicated when multiple people or groups work on the same
image. It would be great to eventually isolate apps and associated
utilities onto dedicated file systems that can be copied, detached,
reattached, and moved around at will. That would leave the original
linux distribution and it's site-specific mods intact. We are 'sort of'
there, but not quite.


Ray Mrohs    

-----Original Message-----
From: Linux on 390 Port [mailto:[EMAIL PROTECTED] On Behalf Of
Rob van der Heij
Sent: Thursday, March 27, 2008 9:30 AM
To: [email protected]
Subject: Re: curiousity question: Linux usage: many or few

I fully agree that bundling the operating system with the application
(as the VMware appliance does) is only good for disposable servers
where you don't build data. I use them to kick the tires of a Wiki or
some other application. In theory you should be able to take the
application data out again and import that into a newer version of the
appliance.

Back when I was still wearing a systems management hat, we worked on
application cloning. Basically when you need a server you get the
current operating system image overlaid with the application payload.
This avoids the need for N new appliance images each time the
operating system is upgraded.

With Linux on z/VM it is very easy to bring down the server and
inspect the contents of its disks by mounting them elsewhere. When you
have kept track of the operating system you put there, you can also
tell what has been changed since then. This gives mechanical means to
extract the changes and reapply them.

Some schools of change management require a full set of development-
test- and integration servers for each application. When there is not
much change, this gets hard to justify. An installation I worked with
wanted a scheme where you would "peel" the application from the server
and archive that. The server would then be removed. When the server
was needed again, the application "peeling" was re-applied to a fresh
current empty server (looking very similar to the production systems
that had been running all the time and had operating system fixes
applied over time).

When you can separate operating system, application layer and
application data by nature (with COW file systems) the scheme gets
very neat. It also saves you on disk resources and backup
requirements.

Rob
--
Rob van der Heij
Velocity Software GmbH
http://velocitysoftware.com/

----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or
visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390

Reply via email to