Overcoming the weight of history
Are the battle scars from previous CommVault upgrades still fresh in your mind? I’m sure there are a number of you reading this that have had a less than optimal experience with upgrades in the past, and are now thinking “oh no, not again”.
Although I cannot go as far as to say “all your problems are now solved, you don’t need to worry about planning anymore”, I can confidently state that the focus CommVault has placed on the upgrade experience in their latest Version 10 release is great. After having performed a number of Simpana v10 upgrades, I have seen first-hand what works (and often more importantly, what does not) and hope to be able to give you some insight into considerations for the upgrade in order to significantly reduce your risk, and to give you peace of mind that the CommVault v10 upgrade experience is the easiest version to upgrade to date.
Coping with complexity
In general, the overlying architecture for a Simpana environment remains the same (which was not true in the previous two upgrade cycles) which means no, or very little redesign is needed to upgrade. Planning is still required in all deployments, so please don’t take this as a “just press the buttons and you will be fine” comment, but in basic deployments, it can typically be acceptable to upgrade all components to the latest version and carry on with little change.
That being said, the Simpana platform can contain many different modules, and so as the complexity of your environment increases, additional consideration must be undertaken. One such item is the removal of the CommNet reporting component from previous releases, which has been replaced with the new “Metrics” reporting. Whilst this new reporting engine offers a richer end user experience and cleaner interface into complex reporting, like for like functionality is not available as yet. A number of CommNet reports are simply not available and/or are still being developed. Therefore if there is a reliance on CommNet reports in your environment, there could be a loss of functionality that needs to be communicated to users and alternative solutions formulated.
Another big change is around the Content Indexing and Search functionality. With the introduction of a new indexing engine, there is now a One Storage Policy to Search Engine Server restriction. Depending upon the specific environment, this may need significant redesign work and additional infrastructure to accommodate. Separation of compliance and end-user search is also recommended, which adds further consideration. If Search is heavily used, then further engagement with a CommVault partner is highly recommended.
By failing to prepare, you are preparing to fail
It is obvious to me that CommVault has put great focus on the upgrade experience for Simpana 10. Once you have decided to embark on the upgrade path, there is a wealth of information available online to assist with planning the upgrade, which I recommend you review, in addition to discussing with a CommVault partner. Documentation as always can be found at documentation.commvault.com, as well as planning tools at cloud.commvault.com.
If you have enabled the sending of "Diagnostics and Usage" information from your existing CommServe, a "Pre-upgrade readiness" report is available through cloud.commvault.com which will perform around 25 checks and list any issues which must be remediated prior to upgrade. If this option has not been enabled, I highly recommend doing so as it provides a great way to check for issues prior to upgrading, as well as giving a taste for the new reporting available in version 10.
By far the most common item I have come across in the pre-upgrade check is that of client agent versions. Whilst the documentation states that all clients must be at least version 8 SP6, or version 9 SP3, experience has shown that the later the service pack that is deployed, the less client issues will result. It is therefore important to ensure all clients are kept up to date. I would recommend that at least version 9 SP6 is rolled out to all clients prior to starting an upgrade.
When all items have been resolved, you can be fairly sure that your upgrade will be a success, however one last check that can be performed is the “Request an Upgrade” test through the cloud.commvault.com site. In this test, a copy of the Simpana database can be uploaded to CommVault who will run the database through the upgrade process and perform a verification. Once submitted, the database is checked for errors that might occur during upgrade and email back a report with any further issues. If all the components are reported as 'Passed', your CommServe is ready for an upgrade!
Think outside the box
As I have mentioned, whilst it is perfectly acceptable to perform an in place upgrade for all components, I often recommend to customers that this is a good time to look at what other work can be done at the same time as the upgrade. One option that can offer additional value is to consider refreshing the entire CommServe. Take a look at the Operating System lifecycle – it may be a good time to look at upgrading Windows versions to increase the longevity of the CommServe, or maybe the CommServe could just benefit from a fresh OS installation due to other factors such as degraded performance or general health. Additionally, whilst an in place upgrade will maintain the previously installed SQL version, a fresh install will use SQL 2012 – again increasing support lifespan.
All systems go
The upgrade sequence is as per any CommVault update; CommServe, Media Agents and then Clients. Running through the upgrade on the CommServe usually takes a couple of hours, and whilst clients do not immediately need to be upgraded and will continue to function with a version 9 agent, there are a number of follow up tasks that need to be performed once the CommServe is upgraded and before normal operations can fully resume.
- The Media Agent which performs the CommVault DR backup must also be upgraded for the DR backup to function correctly.
- All Media Agents performing DASH copies must be on the same version, so if the DR Media Agent has any DASH copy partners, they must be upgraded too.
- If Virtual Server backups are being performed and VSAs have been deployed in a master VSA configuration under the CommServe (which is often the recommended architecture), all VSAs must be upgraded and any Media Agents that they interact with.
In order to accommodate these requirements, I generally make sure to plan from the outset that all Media Agents and VSA servers are upgraded on the same day as the CommServe. Whilst this can make for a very busy day, it will result in version consistency across your environment, and minimise any issues as a result of mixed versions.
The biggest reward for a thing well done, is to have done itSo there you have it – your ultimate CommVault upgrade - which with the proper planning and consideration, need not be the fearful prospect it once was. Just remember…
- Plan, plan, plan
- Consider all Simpana components in your environment
- Utilise the documentation and tools available
- Use the opportunity to refresh servers if practical
- Upgrade all components in as short time frame as possible to minimise issues
- To help plan your CommVault upgrade effectively - download our 15-point checklist.
Disclaimer: The above information is intended as a guideline only and does not cover all possible scenarios. ViFX provide no guarantee on the success of upgrade by sole use of the information and recommends that additional guidance be sought as required.