From Oracle Solaris to vmware Red Hat
June 11, 2014 8:31 AM Subscribe
My boss wants me to find out how to convert our server room full of Oracle / Sun Solaris machines, into vmware Guest Machine instances running Red Hat Enterprise Linux.
He's pretty excited about the cost savings, of not having to pay Oracle and Sun so much money for software license fees. But, it's all on my shoulders to figure out how to do it.
Which blogs and websites can you suggest, to get me pointed in the right direction?
He's pretty excited about the cost savings, of not having to pay Oracle and Sun so much money for software license fees. But, it's all on my shoulders to figure out how to do it.
Which blogs and websites can you suggest, to get me pointed in the right direction?
This question as stated doesn't have nearly enough detail for us to answer properly.
What kind of software are you currently running on the Solaris machines? Is it the Oracle RDBMS? Anything else? How is that software used by your organization?
If it is a database, are you planning on migrating to another database platform? Depending on your current setup, that could be easy or it could take years of work and specialized knowledge.
What kind of experience and knowledge do you have?
posted by ripley_ at 8:39 AM on June 11, 2014
What kind of software are you currently running on the Solaris machines? Is it the Oracle RDBMS? Anything else? How is that software used by your organization?
If it is a database, are you planning on migrating to another database platform? Depending on your current setup, that could be easy or it could take years of work and specialized knowledge.
What kind of experience and knowledge do you have?
posted by ripley_ at 8:39 AM on June 11, 2014
What sort of migration are you talking about? Solaris 9/10 to Red Hat? Also Physical to Virtual I assume. My advice is to specify the migration and the options better.
Option 1: Virtualisation environment. VmWare against Oracle VM
Option 2: Operation System. Solaris, Oracle unbreakbale Kernel (UEK), Readhat are all options.
Wrt licenses you should split the yearly license part from the software support part. For example UEK is license free but if you want 8Oracle) support you need to pay for it.
Also do not make the classic mistake on forgetting conversion costs. These costs can (easily) wipe out any cost savings made on the license part.
posted by Eltulipan at 8:45 AM on June 11, 2014
Option 1: Virtualisation environment. VmWare against Oracle VM
Option 2: Operation System. Solaris, Oracle unbreakbale Kernel (UEK), Readhat are all options.
Wrt licenses you should split the yearly license part from the software support part. For example UEK is license free but if you want 8Oracle) support you need to pay for it.
Also do not make the classic mistake on forgetting conversion costs. These costs can (easily) wipe out any cost savings made on the license part.
posted by Eltulipan at 8:45 AM on June 11, 2014
The simple answer is to call a Red Hat sales rep and a VMWare sales rep and tell them what you want to do. Both should be able to get you started on figuring out your ROM costs. But the simple answer is probably not that simple, and while the Solaris->Red Hat process and the physical->virtual transition is well documented (as in there are lots of documents on the web telling you about it) the reality is more than running a bunch of tools and throwing a switch. I would factor in a consultant or two into the cost comparison if you have no expertise in Red Hat and VM's. And training for your staff.
posted by Runes at 8:52 AM on June 11, 2014 [1 favorite]
posted by Runes at 8:52 AM on June 11, 2014 [1 favorite]
You've got two weakly linked tasks here
1. Converting services from running on Solaris and Oracle platforms to open source platforms
2. Converting from hardware-based hosts to virtual hosts
The first is likely to be the greater challenge, depending on the services you're running. For the second, will you be loading a virtual hosting environment on the old hardware, or on new machines? RedHat has a virtual machine suite as well, so conceivably you could move to an all-RedHat environment.
As others have pointed out, there's no guarantee that this will be an immediate savings, as the migration costs in training, redeveloping services for a different OS, and acquiring hardware to set up a virtual hosting environment might offset current licensing. You could do the first task without the second, maybe even the second without the first.
posted by bendybendy at 9:04 AM on June 11, 2014 [2 favorites]
1. Converting services from running on Solaris and Oracle platforms to open source platforms
2. Converting from hardware-based hosts to virtual hosts
The first is likely to be the greater challenge, depending on the services you're running. For the second, will you be loading a virtual hosting environment on the old hardware, or on new machines? RedHat has a virtual machine suite as well, so conceivably you could move to an all-RedHat environment.
As others have pointed out, there's no guarantee that this will be an immediate savings, as the migration costs in training, redeveloping services for a different OS, and acquiring hardware to set up a virtual hosting environment might offset current licensing. You could do the first task without the second, maybe even the second without the first.
posted by bendybendy at 9:04 AM on June 11, 2014 [2 favorites]
I would also add that if you are thinking of migrating from Oracle to an open source database like Postgres, you should also be thinking about whether "cloud" options make sense for some of your applications.
Really though, this doesn't sound like a project you, or perhaps even your boss, are ready to tackle without a lot of learning, including things you aren't yet considering.
One thing you should be asking yourselves is, can we do this without the end users noticing. Chances are that the answer is no, that you will have to update commercial apps you are using, or that you'll need to make revisions to internal apps that open the question of doing "one more thing." If end users will notice, then the savings from the transition should be considered against the costs of training users, or inefficiency as they figure out the changes on their own.
posted by Good Brain at 10:04 AM on June 11, 2014
Really though, this doesn't sound like a project you, or perhaps even your boss, are ready to tackle without a lot of learning, including things you aren't yet considering.
One thing you should be asking yourselves is, can we do this without the end users noticing. Chances are that the answer is no, that you will have to update commercial apps you are using, or that you'll need to make revisions to internal apps that open the question of doing "one more thing." If end users will notice, then the savings from the transition should be considered against the costs of training users, or inefficiency as they figure out the changes on their own.
posted by Good Brain at 10:04 AM on June 11, 2014
The main advantages of physical -> hypervisor migration are threefold;
a) sysadmin time. Being able to spin up new virtual machines from templates, assign the appropriate hardware share and kick it off without worrying about networking, buying new hardware, backups etc (which are all taken care of at the virtual server layer if done properly) is a major time saving for deploying new services. It also makes implementing clustered services much easier. In addition, you can hot-migrate VMs from one physical server to another (assuming shared SAN storage), so any updates to the hypervisor platform don't cause any downtime.
b) easier disaster recovery. If a physical server dies, you can have the virtual machine spin up on another physical box in the time it takes it to boot. If the OS gets corrupted, you bring it back from the previous snapshot on the SAN (or VM backup). If your entire datacentre goes up in flames, you can fire up your backup clone of your SAN and be up and running much quicker. However, all of that costs money. If you had a duplicate backup network before it will be cheaper if its virtual; if you didn't, provisioning one will cost more.
c) higher resource utilization. The main cost saving of virtual infrastructure is that instead of running a server room with many servers running at low load, you replace them with a small number of high spec'd servers with shared storage, and run them at a much higher load percentage of both CPU and RAM. Whether this actually saves you money entirely depends upon how much you spend on the infrastructure (a decent SAN is not cheap, for example) vs how much spare capacity you were 'wasting' on the previous physical plant.
Plus of course, licencing costs for the hypervisor platform itself.
We do use vmware, because the costs worked out quite substantially for it, as it allowed us to leverage our existing manpower (ie me) more effectively, and drastically lowered our physical server count. I still think it's a better platform than hyper-v and kvm, both of which I've looked at again recently (I'm a windows and debian sysadmin). VMWare is still king of hot-migration, for example, and anything more than a trivial deployment will probably involve spending money on management software at some point, so it's not as big a cost-difference as it can first appear.
The best thing I can recommend is finding a good local reseller for vmware (given your boss has expressed a strong preference), and get them to give you the spiel, and the numbers based upon your current load/space usage. Then you can get some real data on what you're going to need to spend. Then it's definitely worth looking at alternatives such as redhat's own virtual platform based on KVM. You should definitely be able to set up trials (vmware esxi is free, for example) to see how you get on.
The physical-virtual transition isn't going to be your problem. Spinning up virtual redhat servers is going to be easier than building real ones. Making sure all your software runs on a different architecture/OS is going to be the real fun part. Definitely worth talking with RedHat directly on that front, as they definitely have training and migration people that help oracle refugees.
posted by ArkhanJG at 10:12 AM on June 11, 2014 [1 favorite]
a) sysadmin time. Being able to spin up new virtual machines from templates, assign the appropriate hardware share and kick it off without worrying about networking, buying new hardware, backups etc (which are all taken care of at the virtual server layer if done properly) is a major time saving for deploying new services. It also makes implementing clustered services much easier. In addition, you can hot-migrate VMs from one physical server to another (assuming shared SAN storage), so any updates to the hypervisor platform don't cause any downtime.
b) easier disaster recovery. If a physical server dies, you can have the virtual machine spin up on another physical box in the time it takes it to boot. If the OS gets corrupted, you bring it back from the previous snapshot on the SAN (or VM backup). If your entire datacentre goes up in flames, you can fire up your backup clone of your SAN and be up and running much quicker. However, all of that costs money. If you had a duplicate backup network before it will be cheaper if its virtual; if you didn't, provisioning one will cost more.
c) higher resource utilization. The main cost saving of virtual infrastructure is that instead of running a server room with many servers running at low load, you replace them with a small number of high spec'd servers with shared storage, and run them at a much higher load percentage of both CPU and RAM. Whether this actually saves you money entirely depends upon how much you spend on the infrastructure (a decent SAN is not cheap, for example) vs how much spare capacity you were 'wasting' on the previous physical plant.
Plus of course, licencing costs for the hypervisor platform itself.
We do use vmware, because the costs worked out quite substantially for it, as it allowed us to leverage our existing manpower (ie me) more effectively, and drastically lowered our physical server count. I still think it's a better platform than hyper-v and kvm, both of which I've looked at again recently (I'm a windows and debian sysadmin). VMWare is still king of hot-migration, for example, and anything more than a trivial deployment will probably involve spending money on management software at some point, so it's not as big a cost-difference as it can first appear.
The best thing I can recommend is finding a good local reseller for vmware (given your boss has expressed a strong preference), and get them to give you the spiel, and the numbers based upon your current load/space usage. Then you can get some real data on what you're going to need to spend. Then it's definitely worth looking at alternatives such as redhat's own virtual platform based on KVM. You should definitely be able to set up trials (vmware esxi is free, for example) to see how you get on.
The physical-virtual transition isn't going to be your problem. Spinning up virtual redhat servers is going to be easier than building real ones. Making sure all your software runs on a different architecture/OS is going to be the real fun part. Definitely worth talking with RedHat directly on that front, as they definitely have training and migration people that help oracle refugees.
posted by ArkhanJG at 10:12 AM on June 11, 2014 [1 favorite]
How you migrate the clients across to your new setup is also something that is going to require a lot of thought, by the way. It took us several years before we were finally able to turn off the last of the old kit, as we did a staged migration (and rolled in other upgrades into the same migration). It's amazing how many custom odds and sods you discover lurking in dark corners. So you will need a total audit of your current setup to work out what's going to need to come across.
It's not just the headline stuff, it's that app that's not been touched by sysadmin hand for many years, but is still critical for that one senior exec's PA, or that oddball print server for the label printer (yes, both real examples). Be prepared for surprises and things you didn't know about or hadn't thought of.
posted by ArkhanJG at 10:21 AM on June 11, 2014
It's not just the headline stuff, it's that app that's not been touched by sysadmin hand for many years, but is still critical for that one senior exec's PA, or that oddball print server for the label printer (yes, both real examples). Be prepared for surprises and things you didn't know about or hadn't thought of.
posted by ArkhanJG at 10:21 AM on June 11, 2014
I have been engaged in just such a project. The first, obvious, thing: Red Hat has thorough documentation. Anyone can read the docs but you'll need an account with them to get to the knowledge base. VMWare has lots of docs. Both have specific recommendations about considerations in configuring Red Hat guests.
RHEL 7 was just released on Tuesday (and is not yet officially supported by VMWare as a guest, but it's to be presumed that'll come soon -- whether soon means a week or three months, I don't know.)
The good news is that I've found for all there are a bunch of differences between Solaris and Linux, the differences have yet to create a nuisance in porting the mostly web apps we've been moving. (I'd expect lowel-level apps to have a higher chance of being nuisances.) We were already using MySQL so there weren't any db conversion issues.
Like everyone says, depending on details, you shouldn't necessarily count on savings.
So how many physical servers do you have? What kind of apps with what kind of resource requirements? Are they running applications written in house, or things off the shelf? Do you have lots of different things running on the same servers that you'll want to split into different VMs? Are you the top IT person involved here, or is your office/department/whatever part of a larger organization? What's your sysadmin-ish experience and how many sysadmins and programmers will be involved? What are your uptime requirements like?
posted by Zed at 8:26 AM on June 12, 2014
RHEL 7 was just released on Tuesday (and is not yet officially supported by VMWare as a guest, but it's to be presumed that'll come soon -- whether soon means a week or three months, I don't know.)
The good news is that I've found for all there are a bunch of differences between Solaris and Linux, the differences have yet to create a nuisance in porting the mostly web apps we've been moving. (I'd expect lowel-level apps to have a higher chance of being nuisances.) We were already using MySQL so there weren't any db conversion issues.
Like everyone says, depending on details, you shouldn't necessarily count on savings.
So how many physical servers do you have? What kind of apps with what kind of resource requirements? Are they running applications written in house, or things off the shelf? Do you have lots of different things running on the same servers that you'll want to split into different VMs? Are you the top IT person involved here, or is your office/department/whatever part of a larger organization? What's your sysadmin-ish experience and how many sysadmins and programmers will be involved? What are your uptime requirements like?
posted by Zed at 8:26 AM on June 12, 2014
From what you've said, this project seem worthwhile and something I'd be excited about if I worked there. But depending on how you use it, Solaris is a much different beast from any of the Linux distributions. For example:
Zones: in simple terms, a very light weight type of OS level (opposed to hardware level) virtualization for applications. You could have 10 instances of Apache running in 10 different zones and they'd never conflict. Linux kind of has a feature called control groups, but I hear they're not nearly as developed as the Solaris zones.
ZFS: if you depend on any ZFS features like quick snapshotting, cloning, dedup, etc then you have a lot of reading to do. Linux is trying to catch up with btrfs but it's still very, very new. The kernel has had support some of the ZFS features through LVM/Device Mapper for awhile, but how it works also depends on the filesystem you choose. Not every filesystem supports every feature. You can also get ZFS on Linux, but you'll void your RHEL support contract.
DTrace: this is something more for debugging and advanced system administration. It lets you instrument any programs and the kernel to figure out what's going on in your system, and hopefully help you figure out how to fix it. Linux has systemtap, but if you have any folks who are used to DTrace they'll have to relearn things.
Complex In-House Softare: although they are both Unix-ish (Solaris real UNIX, Linux kind of Unix) there are differences. If you've written programs that were only ever meant to run on Solaris it will take some time to port them to Linux. File layouts are different; standard C library functions are different; stdlib functions return different errno's in the same situations; etc. Not impossible, but you should budget time for it.
Those are just some of the things that pop into my mind. Mostly as a Linux used looking over the fence at the Solaris playground. One of our divisions at work within the last year was forced (by an emergency situation) to moved their large filesystem storage from OpenSolaris to a Windows/Linux mix. Suddenly all the Linux users (mounting home over NFS) sorely missed the quick ZFS snapshot feature, and no one really planned for that.
Again, I think the project is worth doing. I don't mind giving Oracle money for Oracle Database, but I'd hate to give them more than that. Just make sure you fully understand how you're using Solaris and how all of that maps to a new platform.
posted by sbutler at 11:16 AM on June 12, 2014
Zones: in simple terms, a very light weight type of OS level (opposed to hardware level) virtualization for applications. You could have 10 instances of Apache running in 10 different zones and they'd never conflict. Linux kind of has a feature called control groups, but I hear they're not nearly as developed as the Solaris zones.
ZFS: if you depend on any ZFS features like quick snapshotting, cloning, dedup, etc then you have a lot of reading to do. Linux is trying to catch up with btrfs but it's still very, very new. The kernel has had support some of the ZFS features through LVM/Device Mapper for awhile, but how it works also depends on the filesystem you choose. Not every filesystem supports every feature. You can also get ZFS on Linux, but you'll void your RHEL support contract.
DTrace: this is something more for debugging and advanced system administration. It lets you instrument any programs and the kernel to figure out what's going on in your system, and hopefully help you figure out how to fix it. Linux has systemtap, but if you have any folks who are used to DTrace they'll have to relearn things.
Complex In-House Softare: although they are both Unix-ish (Solaris real UNIX, Linux kind of Unix) there are differences. If you've written programs that were only ever meant to run on Solaris it will take some time to port them to Linux. File layouts are different; standard C library functions are different; stdlib functions return different errno's in the same situations; etc. Not impossible, but you should budget time for it.
Those are just some of the things that pop into my mind. Mostly as a Linux used looking over the fence at the Solaris playground. One of our divisions at work within the last year was forced (by an emergency situation) to moved their large filesystem storage from OpenSolaris to a Windows/Linux mix. Suddenly all the Linux users (mounting home over NFS) sorely missed the quick ZFS snapshot feature, and no one really planned for that.
Again, I think the project is worth doing. I don't mind giving Oracle money for Oracle Database, but I'd hate to give them more than that. Just make sure you fully understand how you're using Solaris and how all of that maps to a new platform.
posted by sbutler at 11:16 AM on June 12, 2014
Depending on your Oracle license, beware that switching to VMware might have implications for the per-core calculations that determine your final cost.
If you have a site license, Oracle may well want to renegotiate when you switch platforms. Now I don't know this for a fact, but their Vader-like reputation for deal-making makes me weak in the knees when we discuss a Solaris/SPARC-to-Linux/VMware move.
posted by wenestvedt at 6:57 AM on June 13, 2014
If you have a site license, Oracle may well want to renegotiate when you switch platforms. Now I don't know this for a fact, but their Vader-like reputation for deal-making makes me weak in the knees when we discuss a Solaris/SPARC-to-Linux/VMware move.
posted by wenestvedt at 6:57 AM on June 13, 2014
This thread is closed to new comments.
posted by H. Roark at 8:35 AM on June 11, 2014 [2 favorites]