|
Grid Computing
Mass Software Deployment with Oracle 10g
with Sudip Datta
Sudip Datta, Principal Product Manager for System Management in the Server Technologies division, talks about new mass software deployment strategies enabled by Oracle 10g
OTN: Why should DBAs and IT managers care about improving deployment management?
Datta: If you were to define deployment in terms of the full software lifecycle, it would include things such as installation, patching, cloning, software configuration, compliance tracking—such as tracking for compliance with security rules and other forms of standardization—and de-installation. According to a recent Forrester study, almost half of a DBA's time is consumed by deployment activities, which isn't surprising.
OTN: How has Oracle addressed this problem in Oracle 10g?
Datta: In Enterprise Manager 9.2, management primarily involved managing Oracle Database operations such as bringing up an instance, managing schemas and doing things like export, import, backup, and restore. In Oracle 10g, we have extended the scope of Enterprise Manager to include more Oracle products as well as to managing software deployment and configuration. These capabilities pertain to patching, mass cloning, generating compliance reports, analyzing and comparing installations, and tracking configuration changes. All these functions are included under the Oracle 10g deployment umbrella.
| "According to a recent Forrester study, almost half of a DBA's time is consumed by deployment activities."
|
OTN: Can you describe in detail some specific differences, in terms of focus and features relating to deployment, between Oracle Database 10g and earlier versions?
Datta: We had two key deployment goals with 10g: first, a better out-of-the-box experience for customers and for partners who integrate their software in ours; and second, a better experience for database and system administrators managing large-scale deployments in an enterprise grid environment.
So, for starters, we designed a faster database install in 10g, cutting 9.2 install time almost in half—to about 20 minutes, in most cases. For end user customers, installing Oracle 10g Database and Application Server also installs Enterprise Manager Grid Control. With no extra work required, the Enterprise Manager Web page comes up and the Oracle Database and Oracle Application Server software are ready to be managed out-of-the-box. Bear in mind that this simplicity has been attained without compromising the out-of-box setup of new technologies such as the Cluster Ready Services (CRS) and Automatic Storage Management (ASM).
We also rationalized the footprint of the software, both on the installer CD and in the Oracle Home where the software is installed. We did that by reducing unnecessary components and by distributing them more efficiently across the CDs, so that the most frequent installs are all on a single CD. For a partner, the implication is that if it has a few scripts or programs of its own, there is now enough room to include them as well as Oracle on the same CD. And because 10g installation and configuration can operate in a silent, unattended mode, partners that want to embed Oracle as a part of their application can kick off our installation from their installation. We are already seeing some positive response from partners in this regard.
The second part is that we've simplified the management of large-scale deployments in a grid environment. Here we provide the Enterprise Manager 10g Configuration Management Pack, which can manage a group of installations. It's part of Grid Control. The management capabilities include centralized software and compliance tracking, so that EM is capable of tracking whatever software is installed enterprisewide and that it doesn't conflict with internal IT compliance standards. Moreover, EM can clone Oracle software—if the customer wants to extend the software to multiple boxes after the first installation, it's capable of doing that, which is critical in a grid. The smaller footprint facilitates cloning across a network.
OTN: What about patches? Is that process automated as well?
| "Because 10g installation and configuration can operate in a silent, unattended mode, partners that want to embed Oracle as a part of their application can kick off our installation from their installation."
|
Datta: Yes; Enterprise Manager can also automate delivery of Oracle patches as well as the patching process itself with minimal effort. In pre-10g versions, when a customer faces a problem, they request a patch through Oracle Support and we make that patch available to the customer via a MetaLink download. In contrast, Enterprise Manager 10g offers a more complete service in which customers are proactively notified of patches based on their deployed products and versions. EM "knows" what different Oracle versions are running in the enterprise and what the respective hardware platforms are, and when a patch is made available for that particular version and hardware, the customer is proactively notified within the Enterprise Manager console.
There is a more advanced feature as well, called the Critical Patch Facility (CPF), which detects possible security vulnerabilities in the enterprise as well. CPF also has a live, proactive integration with MetaLink so that users can download and apply patches in order to plug vulnerabilities.
OTN: Can you elaborate on the deployment-related analytic capabilities of Enterprise Manager 10g?
Datta: Enterprise Manager 10g has powerful search-and-analysis capabilities. For example, it can tell you what installations use a particular database feature, or what hosts have a particular operating system property that's set. It can look for particular patches, so that the next time support returns a call to the customer, they can say, "Go to Enterprise Manager, bring up the screen, and see if this patch is installed." The customer doesn't need to go through cumbersome processes, or log into this or that box. Basically, all they need to do is fill out a form in Enterprise Manager and kick off a query, which would ask, "What are the installations that have that particular patch?"
Furthermore, if you have a reference configuration you can compare it with other hosts and find out if any of the hosts are deviating from that configuration. This capability helps you determine if the root cause of a problem lies in the software.
For example, let's say the customer is running identical applications on two machines and the problem appears in one of them. Using this host-to-host comparison, the customer can uncover any differences in the software stack: Do any properties of the operating systems differ? Are any settings within Oracle different? And so on.
The ability to compare operating system and network parameters across the enterprise also implies that DBAs will have less dependence on system and network administrators. This empowerment will definitely help them to make better use of their time and resources.
OTN: Let's get back to cloning for a moment. What is the scope of software cloning in 10g Release 1?
Datta: Oracle 10g lets you clone the Oracle Database Home and the Oracle Application Server Home. In terms of coverage, that capability caters to a vast majority of our deployments. Here's how it works: First, Enterprise Manager detects two hosts, the source and the target. You then go to the source, pick up a particular Oracle Home, and it gets zipped up in the proper format. An EM clone agent then pushes the package to the other host and the other host actually runs the installer agent in the background in clone mode. It extracts the software out of the zipped file and produces that clone on the other host. In 10g, you can multicast images from a single home to multiple homes. So you can pick a source and deploy to 50 different boxes. That's crucial for a grid environment.
| "In 10g, you can multicast images from a single home to multiple homes. So you can pick a source and deploy to 50 different boxes."
|
When you install through that cloning mechanism, the clone immediately appear as a first-class Oracle Home within the deployment page of the Enterprise Manager console. The clone is now capable of running, being patched or modified in some other form, and being monitored. And the clones are now capable of acting as a source for other clones.
Note that when you clone using Enterprise Manager, it actually submits a clone job, and that you're capable of monitoring every phase of that job. The Oracle cloning mechanism runs the pre-requisite checker to ensure that the cloning is not being attempted on an incompatible platform. Moreover, if a clone job fails at a particular phase, you can take corrective action by reviewing it from exactly the time if failed and reinitiating the clone from that point onward. Finally, through the Enterprise Manager job subsystem, a clone can be scheduled during any time window. If there is a weekend available, the DBA can schedule the cloning job for that time interval to ensure it doesn't interfere with other traffic.
OTN: What is the recommended software deployment strategy for data centers running 10g?
Datta: Oracle has long been respected for its flexibility, so we still offer a variety of deployment options in 10g. We haven't restricted the ability of users to deploy software in their own ways. So there is an interactive install, there is a silent install, there is cloning, there is one-off patching across the grid. There are a variety of options that Oracle can offer customers.
Having said that—acknowledging that there are a wide variety of customers, each residing within a market segment—for large data centers we have a recommended model, which we've arrived at through internal exploration as well as talking to external customers. Any software deployment strategy for data centers must optimize scalability of deployment, so that if you have to deploy more than 500 hosts the cost of labor doesn't increase 500 times over a single host deployment. You also want to minimize the risk that the software is installed in some manner that's noncompliant with enterprise standards.
For that goal, we strongly advocate the practice that the software should be built at source. In that approach, the customer would typically install the software in one place, take out unwanted components through the installation, patch it beforehand with the proper patch set or interim fixes, and then test the software against their application. Finally, when they are 100% sure that the software works, they approve it for mass deployment and roll it out using the clone feature. Then when you have rolled out the deployment and a new security patch arrives, Enterprise Manager CPF kicks in. The patch is pushed to that particular host, and applied through our patching tool, called OPatch.
| "We're following a hybrid model, using a combination of physical cloning from a 'gold' source for initial deployment, but where all updates and patches are done logically and incrementally through Enterprise Manager."
|
Thus, the model that we are following in 10g is a hybrid one, using a combination of physical cloning from a "gold" source for initial deployment, but where all subsequent updates and patches are done logically and incrementally through Enterprise Manager. This model is definitely more scalable model than conducting interactive installs on individual targets. You don't want DBAs running around with CDs and installing a hundred times on a hundred different boxes and then upgrade them individually.
OTN: Are there any common alternatives to this deployment strategy for typical data centers?
Datta: Yes. One alternative I can think of in terms of large enterprises is the case where you use a distributed deployment, installed from software depots. We have encountered customers and partners who adopt that model using silent install. These enterprises typically keep their software in a central location and then kick off the silent installers on the respective hosts. Assuming that the software is centrally hosted, and that all these silent installs are provided the same set of directives, you can then reach a level of standardization without physical cloning. So they would pull in the same bits, and do the same configuration to come an identical state. This approach is particularly useful when you have deployments with multiple national languages or multiple hardware platforms, for example—in those cases cloning is not an option because the physical clone won't work across language territories or multiple hardware systems.
The downside of this model is that the silent install applies only to the base release, so you cannot deploy already patched software. If you want to deploy proven, tested, and patched software, cloning is the best way to go. That said, you can upgrade and patch through silent methods, but then in each case you have to combine several silent steps and chain them together to reach a particular software level. But that's not too scalable either. In the end, if you want the install where you have patched and proven versions of the software, cloning is usually the best choice.
OTN: How does Oracle facilitate deployment best practices for customers and partners in 10g?
Datta: All the deployment best practices in 10g—the hybrid model of cloning and patching to deploy the software, using Enterprise Manager—were formulated after involving and consulting with key customers and partners that were early adopters of our programs. That said, we can facilitate more custom environments. All the back-end operations for deployment are exposed through command-line interfaces so that they can integrate 10g with their homegrown or third-party management systems. That means the patching, the silent install, and the cloning I talked about all have command-line interfaces, explicitly documented, which a customer can use to incorporate or integrate within their homegrown systems. Of course, using EM 10g helps them scale to an extent that homegrown systems may not be capable of.
For partners, the major beneficiaries of the 10g deployment story are the independent software vendors, the ISVs, and others who can embed Oracle in their applications. The smaller footprint, as well as the silent install capability, should make Oracle the technology of choice for these customers. Even hardware vendors like Dell have been using the silent technology to provide Oracle Standard Edition with Linux on certain hardware. In fact, when they build that software, they use our framework technology to achieve that goal.
The other partner beneficiaries include management vendors such as HP and Opsware, plus others who use our powerful APIs and command line interfaces as a back-end engine for their tools. With these vendors we enjoy a competitive/cooperative relationship that is mutually beneficial. We may compete with them in the systems management space, but we also cooperate to empower them so that the Oracle databases and application servers installed on their systems are better managed at the end of the day. The 10g deployment and management framework helps them to do that.
OTN: What key enhancements are targeted for the next release?
Datta: One key goal is to expand the cloning facility within a RAC setting, which is particularly useful within a grid. There are two use cases here. One is if you already have a cluster running and you want to replicate that cluster to set up a brand new cluster—say, cloning 10 or 15 nodes to a different cluster. The other case is if you have a cluster with 15 nodes running, you have a 16th node that has just arrived, you have provisioned the OS onto that node, and you just want to extend the software to that new node. So one use case is inter-cluster and the other one is intra-cluster.
In both cases we will be using the underlying cloning framework. We're also looking to expand the cloning framework to include other pieces. For example, the technology could be used to provision an entire stack of Oracle products. This capability may also extend from the operating system to the application layer to provision computing resources on demand.
We are also going to make OPatch the patching tool for all Oracle products. In Oracle 10g Release 1, it's restricted to the database, but in the very near future, patches on other Oracle core technology products are going to use the same technique. What that essentially means is that we will have a single patching strategy and mechanism for all Oracle technology products.
OTN: What about training?
Datta: We're rolling out a training program for DBAs that will cover best deployment practices. Oracle University's curriculum is trying to cater to that idea. It may not be called "deployment best practices" per se, but there will be training programs that cover installation, patching, cloning, configuration management, and so on. We'll also be improving our documentation for best practices. As the best practices we promote become more widely adopted, we'll need to beef up their documentation, so we are working very hard to do that. The goal here is to help customers and partners to align with our deployment philosophy and to encourage faster adoption of new Oracle deployment technologies.
|
Bookmark
