This week we have a guest blogger. Christine works with me in the
Solaris Adoption Practice. She doesn't have a blog but suddenly finds
that this week she has something to say. Here is her two-part discussion
about starting your Solaris 10 Migration.
She can be reached at christine DOT tran AT sun.com.
Part 1: "How much does it cost to upgrade to Solaris 10?"
We in the Solaris Adoption group get questions like this once in a while,
from customers and from account managers. It has grown more frequent in
recent weeks. The answer is: "It depends!" This answer exasperates some
people and drives others up the wall.
They try asking it another way: "How long does it take?"
"Give me a ball-park level-of-effort estimate." "What's the cost of NOT
upgrading to Solaris 10?"
The answer is: It depends.
I can understand the impetus behind the question. Before buying a
car, a phone plan, a Twinkie, I want to know how much it costs.
I'm trading my moneys for goods or service, and I want to know how much I'm in for.
For crying out loud if they can estimate how much it costs to raise a
child ($165,630 for 17 years, before inflation), you can tell me how much it
costs to upgrade to Solaris 10! What is this "it depends" monkey business?
Introducing change into any system will cost you. It doesn't
matter if you're patching, upgrading a firmware version, Apache, or the entire
OS. At the very least it'll cost you
time: even if you don't incur downtime, you will have expended time to do the
task. Let's say you'll expend five
minutes of time to introduce a patch to your system." There's your cost:
five minutes." Will you install the patch?" "Sure. Why not?" How
about one hour? Will you install the patch if it takes you
one hour? How about eight hours? "We-l-l-l ... that's a wee bit long for a
patch, isn't it? What's the patch for?"
And THERE is the first
question you should ask, "What is it for?"
If the patch fixes a rarely used OpenGL library, you may patch if it
takes five minutes. You may not patch if
it takes one hour, unless you had other patches to apply. You certainly are not going to spend eight
hours. On the other hand if the patch
fixes a security vulnerability with open exploits, you
definitely are going to patch even if it takes you eight hours.
Before collaring your
sales rep and asking him how much will it cost to upgrade to Solaris 10, ask
"What is it for?" The cost is related to
the benefits derived, a price tag by itself is meaningless
Should you upgrade to
Solaris 10? From 2.6, Solaris 8, Solaris
9, migrate from some other OS? Perhaps not. Perhaps
your system is running at the utilization rate you want, at the stable patch
level you want, you're not going to be adding new hardware, you don't expect to
grow your users, your disks, your bandwidth, you don't want any new
feature. In short, you are perfectly
happy with your server and there's no improvement you can think to make.
In that case, no, you probably shouldn't
spend the effort to run Solaris 10.
Of course, this scenario only exists in a perfect world. Solaris
10 is so full of Wheaties goodness that it would be
near impossible to find a case where it's not an improvement on a previous
version of Solaris. However, upgrading
to Solaris 10 only to be running the latest, the hippest, the coolest, will
give you no quantifiable benefit except that you're now hip and cool
Begin with a problem in your datacenter that you want to solve.
Make it a business problem, and not a technical problem. Not "poor
network performance", but "buyers take too long to go from checkout to payment."
Not "consolidation" but "maintenance contracts and license on 25 web
servers eating up IT budget."
These problems will resolve into technical problems: want a
faster network stack, want consolidation but guaranteed computing resources per
server, want faster and better development tools, want
to re-use old JBODs. The technical problems will be solved by Solaris 10.
If you answer yes to all
of the above, and have other requirements beyond that, prioritize and pick the
top three. You're going to spend time, money, and manpower. Keeping
the migration scope small makes the
project manageable, and the relationship between cost and benefit clear
Part II: "How do I upgrade to Solaris 10?"
You've identified the top
three business problems that Solaris 10 will solve. As an example, let's make them
- paying transaction too slow, users have to
wait 5 seconds for payment to complete
- no planning for projected user growth tripling
in 6 months
- acquisition of competitor, who wants to keep
their own server environment
Let's say Solaris 10
improved TCP/IP stack will solve problem number 1, buying a big honking new
server will solve problem number 2, and deploying zones to mimic your
acquisition environment on the big honking new server will solve problem number
Your pilot migration plan
will focus on the "before" and "after" of these three things. You want
to know if upgrading to Solaris 10
will make your transaction faster, if new hardware will give you room to grow,
and if you can host your acquisition without adding footprint in your
datacenter. Granted, these are strawman problems simplified for the brevity of this post,
but these are not very far removed from the real problems in real datacenters
or mom-n-pop shops.
Scope your migration. Let's say you're just
migrating 10 older platforms to a Sun Fire V890. You want to see faster paying transaction,
enough memory and CPU power to triple the workload, and a several zones to
mimic the environment of your recent acquisition. Decide on the target: for example, you'll
want to end up with Solaris 10 11/06, most current patch cluster, application
Take an inventory. What applications will be
loaded on the V890, what firmware, what driver?
Are there supporting applications that will have to be carried
over? Don't forget any network or SAN
support, like trunking or PowerPath.
inventory. Is your COTS application
supported by the vendor on Solaris 10?
Sun can help you check this. If
your application is developed in-house, can it pass Appcert,
the tool to flag binary incompatibility between Solaris
versions? If you have application versions not
supported on Solaris 10, can you upgrade the application.
Understand your operating environment. Do you know
how your applications are backed up?
Where are traps and alerts being sent?
What to do for Disaster Recovery?
What firewall policy or user policy is in effect? What are the intersections between
applications which will be moved
Have test methods and criteria. What test will
verify that your application is functional?
Are there performance benchmark?
Have you taken a performance baseline measurement? A baseline measurement indicates how you are
performing now. After migration, take
another measurement and compare it with your baseline.
Some /etc/systems parameters have been obsoleted in
Solaris 10, replaced by Resource Management parameters. Check your
/etc/systems to see if you need to
convert these parameters.
Solaris 10 comes with SMF (Service Management Facility.)
Are there scripts in /etc/rc
that you want to convert to XML manifest?
There are special considerations to using zones.
Have a plan for creating, patching, and managing zones.
Do you have a Change Management framework? If yes, fit
your migration activities into this framework.
File your migration plan with the Change Management Board.
Upgrade a test environment first.
your standard installation practice, write up an install plan for upgrading to
Solaris 10. It can be as simple as
taking a backup and inserting a Solaris 10 CD, or as complex as
un-encapsulating rootdg, removing disks from Veritas Volume Manager and
using LiveUpgrade. The install plan should have a section on how
to fall-back if the installation does not go well.
Have a good backup. Test your good backup.
Schedule a maintenance window and follow your installation plan.
Install any additional drivers, firmware, support packages, mandatory patches.
Install your zones. Install your applications.
Perform functional tests (does the OS and application work?) performance test (does the
application run as well or better than before?) and integration test (does the
application interact and perform as before when interfacing with other
applications?) You have documented these
test methods and results in Step 5.
Can you perform routine administration tasks as before?
Check cron jobs, log management, backups, system
management, patching, name service, directory service, remote management, and
anything else you do in your daily care-and-feeding routine. You have
documented these tasks in Step 4.
Repeat the previous two steps for your zones and applications running in a zone.
It's important to define
an endpoint for your pilot where you stop work and examine if your migration
has fulfilled your objectives. In other
words, now your application is twice as fast, your new server can support three
times the workload, and it contains zones which enclose a separate working
environment for your recently-acquired business unit.
A successful small pilot
can be broaden to cover a production environment. Document your pilot project, and repeat it
for your production environment. From
here, repeat the steps, with modifications from your experience, to upgrade
another part of your datacenter. Or you
can write another project plan for an OS refresh to gradually transform the
rest of your datacenter. But you're done
with the hardest part: the beginning.