This document describes suggested best practices for deploying and upgrading ProActive DBA software in medium to large enterprises.

Transcription

1 Upgrades Best Practices Products: All Operating Systems: All RDBMS: All ProActive DBA This document describes suggested best practices for deploying and upgrading ProActive DBA software in medium to large enterprises. OVERVIEW Customers who manage large installations of ProActive DBA in their environments often have the same questions about deploying and upgrading our software: How can I minimize the work involved in performing installation and upgrades? How can I ensure that software upgrades will provide the new features I need, without introducing any new bugs or other problems? How can I try out a new software version on a small scale, and then deploy it enterprise wide once I feel comfortable with it? This FAQ addresses these questions and shows how White Sands s development methodology and tool set has been designed to make the upgrade process as painless as possible for large enterprise customers. TYPES OF CUSTOMER ENVIRONMENTS Customer environments using ProActive DBA can be divided into two general categories, each with its own upgrade strategy. Upgrade-Friendly Upgrade friendly environments are those where it is not a big problem to perform ProActive DBA upgrades. These environments typically have the following characteristics: One to several ProActive DBA Consoles; Up to 10 or 20 servers registered in ProActive DBA; Upgrades can be done on individual workstations, without having to go through any centralized packaging or deployment procedures. Last Updated: Page 1 of 6

2 In these environments, customers can simply download the ProActive DBA upgrade package, install it and be up and running on the new version in a matter of minutes. Upgrade-Critical Environments which we call upgrade critical are typically larger installations, where upgrades may affect many Console users and/or many monitored servers. These environments typically can be described as follows: They have a larger number of ProActive DBA Consoles (e.g or more); They have a larger number of servers registered in ProActive DBA (e.g. 20 or more); Software upgrades cannot be installed directly onto users workstations, but instead must go through a centralized packaging and deployment procedure, which can take several weeks or more. In this FAQ, we will focus mainly on upgrade critical environments, since more work and planning are involved in performing upgrades in those situations. WHITE SANDS SOFTWARE RELEASES At any given time, White Sands has up to three different software releases which are made available to customers. We don t term these releases GA (generally available) or not GA they are all available for customers who want them. Each release is at a different stage in White Sands s software life cycle for its respective feature set, as indicated by its major/minor version numbers. The following diagram describes the life cycle of a given software version: Piranha (New Feature Development) Barracuda (Stabilization, Minor Fixes and Features Added) Guppy (Final Release of Feature Set) Each new version proceeds through the above life cycle as follows: 1. The new version starts out as a Piranha release and receives the newest features, enhancements and changes that are being developed at that time. These releases are used by customers who want to participate in the development process and can tolerate frequent updates. 2. Once the release is feature complete, it changes to a Barracuda release. At this point the release is sealed off from any more major changes; however, bug fixes and minor changes will continue to be applied. Thus, a release that has been in the Barracuda stage for a while Last Updated: Page 2 of 6

3 is reasonably stable, but will still receive some updates. We also start giving the release to more and more customers who want to try out the new features, so that we can fix any problems that are discovered. However, for upgradecritical customers, in order to reduce the likelihood of updates during your UAT, we recommend waiting for the Guppy release, with which to begin your UAT. 3. After the Barracuda testing cycle is complete, the release series becomes a Guppy release and will not receive any further updates (except in the case of a critical bug fix, but this is rarely needed). At this point, a general notice is sent out to all our supported customers to inform them that the new Guppy version is available. A release in the Guppy stage is very stable, but for upgrade critical customers we still recommend performing a UAT cycle for 30 days prior to deploying it throughout your environment. Managing releases in this way enables us to better control the feature set and stability level of each new version we make available to customers, and it gives customers better control over the software they deploy as well. DEPLOYING UPGRADES Now we are ready to turn to the question of how to deploy a ProActive DBA upgrade in an upgrade critical environment. The process basically involves the following steps: 1. Deploy a Guppy release in a sandbox for a period of time (e.g. 30 days), to perform user acceptance testing (UAT) to find any issues that affect use of ProActive DBA in your environment. 2. During the UAT period, if any critical bugs or other issues are found by you or other customers, White Sands may provide updates to the Guppy release to address these issues. 3. After the Guppy testing period is complete, you can package the release (if necessary) and deploy it across your enterprise. In the following sections, we explain these steps in more detail. PLAYING IN THE SANDBOX A sandbox is a separate or parallel installation of ProActive DBA, which enables you to try out a new software version without affecting existing production installations and users. A sandbox installation is typically configured with a small number of Consoles and servers, so that if further updates are required during the UAT period, the upgrade procedure is simpler. Last Updated: Page 3 of 6

4 Sandboxed Consoles For the Console component of the sandbox, the new installation can reside on the same workstation(s) as the existing installation, or it can be placed on one or more other workstations if desired. Some customers will create a virtual machine or Citrix or Terminal Server account specifically for testing a new sandboxed version of ProActive DBA; these are good choices as well. If installing the sandbox version on the same workstation as an existing installation, you can switch between installations by using a software component called the ProActive DBA Domain Chooser, which allows the user to choose which environment (production or sandbox) to use when starting the Console. The different installed software environments are referred to as domains in this context. Sandboxed Servers and Agents Typically, customers will want to use development or test servers with the sandboxed version of ProActive DBA. This is fine, but if your development or test servers do not receive the same type or volume of usage as your production servers, then it may be a good idea to use one or more production servers in the sandbox as well. The back end components (the middle tier Agents and server side Agents) in the sandbox need to be configured to communicate using different TCP ports from the production installation, so that the two sets of components will not conflict with each other. The two ProActive DBA installations (production and sandbox) can in most cases monitor the same servers if you want, although this is not usually done. For assistance in setting up a sandbox to test a new ProActive DBA release, please contact your White Sands Technology Technical Support representative and weʹll be glad to help. USER ACCEPTANCE TESTING (UAT) A user acceptance testing or UAT phase gives you a period of time to try out a new ProActive DBA software release, in order to ensure that the new features in it meet your needs, and that the new software does not introduce any new bugs or other problems in your environment. A UAT period of 30 days works well for most customers, but it can go longer if needed. Updates During the UAT Period During the UAT period for testing a Guppy release, if any critical bugs or other issues are found by you or other customers, White Sands may incorporate fixes for these issues and provide further Guppy releases which you may install in the sandbox for further testing. Each release we produce will require upgrading all ProActive DBA components (Consoles, middle tier Agents and server side Turbo Agents). It is also possible that updates to the ProActive DBA repository and/or Warehouse or its components is necessary. It is not possible Last Updated: Page 4 of 6

5 to only update individual components when an update needs to be deployed; all components will be updated. For this reason, it is not recommended that you deploy any Barracuda release throughout your enterprise, since you wonʹt get the benefit of any additional fixes White Sands incorporates during the rest of the test cycle. We strongly recommend waiting until the end of the UAT period, and using the final Guppy release that White Sands provides. Some customers may feel that since they have tested a particular release, they feel safer using that, rather than a slightly newer release which they have not yet tested. Our reply to that is that during the Barracuda phase, and especially once the Guppy phase is reached, White Sands takes great care to only add fixes and minor enhancements that have a low likelihood of introducing unwanted side effects, so that the stability of the release only increases until the end of the test cycle. This methodology has proven to be very effective at minimizing the number of undiscovered problems in our final Guppy releases, so we feel very confident that it will work in your environment too, if applied properly. DEPLOYING THE GUPPY VERSION By the end of the UAT period, White Sands will provide you with a final Guppy release, to be packaged (if required) and installed enterprise wide. At that point, any servers that were being used in the sandbox can be unregistered and moved back to the production domain (White Sands can assist with this process, if needed). CONCLUSION We hope this document has been helpful in understanding White Sands s release cycle and software development methodology. It has been designed so as to make the maintenance and upgrading of ProActive DBA as easy as possible for everyone in your organization. For any questions or feedback, please feel free to contact us weʹd like to know what you think! Last Updated: Page 5 of 6

6 CONTACT US White Sands Technology, Inc. Technical Support is available to assist with questions related to the installation, configuration and daily use of ProActive DBA tools. Contact us at: Phone (USA): Fax: support@whitesands.com www: FAQ: Last Updated: Page 6 of 6