What is most valuable?
The valuable features are the cost and the convenience of the physical machines, meaning that you can have multiple virtual machines that you can use for many other different tools, not just Hyperion. We work with different Oracle products such as EBS, OBIEE, and Hyperion and they're all integrated so we don't have to have different physical servers located in our datacenter. What you can do is create different virtual machines in the same physical server and use that for any of our products.
How has it helped my organization?
For example, we are going to upgrade our Oracle BI product, so that needs to have more servers. What we are thinking to do is to create more VM's in the same physical server instead of buying more physical servers. It's just a matter of creating a new virtual machine, which is not a big task for the administration team. Probably within an hour they're able to build up a new server for us, so it's easy, faster and cheaper that way.
What needs improvement?
Initially, you did not have an option in Oracle VM to build an image and just restore into a different physical or virtual environment, but now the option is included. That's one thing I thought wasn't there and wanted to have, because we are planning to move our Essbase database server from physical to virtual, and I thought it's not going to be easier because you can't just export the physical server and just import everything into the virtual machine. Now the integration is there. You can export the physical server's configuration, their registries and everything, the databases and then just import them to virtual machines. That's the only lacking feature I thought was with VM, but they have included it.
It still takes some time and the valuations have to be done by the admin, so it still is taking more time. That's, I think, one of the challenges that we recently had when we were talking to our administration team. The Windows and Linux admins took some time, like a couple of days, to build servers for us, which as far as I think being an IT person, it's a virtual machine. Once you have the image it should be easy enough to import it into the new virtual machine, built up like a snapshot.
I think they could make the implementation faster. It's still taking some time, which should be eliminated in the future, I think, and it will be because I've seen a lot of improvement already.
What was my experience with deployment of the solution?
If deployment could be more faster, that would good, but right now it's fine. It solved my problem of migrating from physical to virtual, so initially I had to reinstall Essbase and it's a big challenge in the Linux machine.
What do I think about the stability of the solution?
I haven't seen any big issue with the stability. There have been no issues with instability that I've seen.
What do I think about the scalability of the solution?
It's been able to scale for our needs.
How was the initial setup?
Within one day, we had migrated a physical to virtual server and then we had a database working, and it was like seamless transition. We just changed the alias of that machine to whatever the listing server alias name was, and the application picked up right away.
What about the implementation team?
We implemented it with our in-house team.
Which other solutions did I evaluate?
I looked into vSphere and Hyper-V, and then decided that we could not go with any other non-Oracle virtual technology. It had to be Oracle VM, so that's one thing I wanted to make sure was that we had Oracle VM as a new server, otherwise Hyperion is not going to be supported on non-Oracle virtual servers.
For us, the biggest thing I think is the compatibility with all the other Oracle products. We have ERP and EPM and all these reporting tools like BI. The most important factor for us is when you talk about the compatibility of all these different products, it has to have compatibility with dependent operating systems, the servers, the database, Internet Explorer browsers, Java, and all those different tools that are integrated in our system.
If we go with any other virtual servers or virtual products, let's say VMware, it is compatible but it's not 100% guaranteed that we'll be supported by Oracle support. Let's say in the future if we have a problem, Oracle support might say we are not able to support because you are using third-party tools. That's the most important factor and advantage over other tools in the market available when we choose to go with Oracle.
We just did the upgrade of our Oracle Hyperion, so one thing I learned is we could not go with any other tool because we have all these Oracle products integrated tightly and we cannot just install them on some other non-Oracle products. I think we are also talking about to move from physical to virtual for one of our Essbase databases. Right now it's on Essbase, which is under Hyperion, on a physical server, so again, just to take advantage of the cost and the recovery and the disaster recovery and all those benefits that virtual machine has to offer.
What other advice do I have?
Prepare for the development time and the allocation of resources. That's the key thing. When you're building an image or a Oracle VM server, how much resources are you allocating? Let's say for example, the storage and buffer memory and the processor speed for each of your instance for that physical server capable of 100 gigabyte of memory, and then you're trying to build 10 servers out of it that are virtual servers. You need to analyze and review, out of those 10 servers, which server needs more resource and more hard space based on your application growth. That is the key thing that I've seen. Some admins don't pay attention when they're building the package. It really depends on the factor of what tool is going to be implemented on what server. How much space and how much processor speed is it going to need?
For example, the Essbase database in Hyperion needs a lot of memory and processing speed. It needs more threads to calculate the data, so for that you need to allocate as much resources as you can as compared to maybe other tools which don't need that much of resources.
Planning to build your package for your client for the virtual machine on the physical server is the key thing.