How Much Does it cost to upgrade to Solaris 10
By Jeff Victor-Oracle on May 24, 2007
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 3
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.
1. 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 version x.y.
2. 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.
3. Check your 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.
4. 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
5. 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.
6. 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.
7. Solaris 10 comes with SMF (Service Management Facility.) Are there scripts in /etc/rc that you want to convert to XML manifest?
8. There are special considerations to using zones. Have a plan for creating, patching, and managing zones.
9. 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.
10. Upgrade a test environment first.
11. Depending on 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.
12. Have a good backup. Test your good backup.
13. Schedule a maintenance window and follow your installation plan. Install any additional drivers, firmware, support packages, mandatory patches. Install your zones. Install your applications.
14. 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.
15. 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.
16. 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.