I cannot recommend to do this. I recommend to stay at least on the same version, e.g. have everything 7.2.x or 7.3.x. If you upgrade one system to 7.3 it may work, but the 7.3 version has new/modified properties, which are not known by the other systems. When you now try to add a new or change a modified property, the non 7.3 systems will reject the configuration, and mark it as "invalid".
You will end up with an error message in the UI and have to revert your changes. Not very nice in my opinion. If you want to play around with 7.3 you should start a VM and play with it. Additionally you could start upgrading your complete installation to 7.3 step by step, and see how it works. 7.3 is fully supported and working fine. However you should not run both brances for a longer time or while you still want to apply changes from time to time.
Thanks for the reply.
I remain unclear as to the best way to proceed.
I cannot recommend to do this. I recommend to stay at least on the same version, e.g. have everything 7.2.x or 7.3.x. If you upgrade one system to 7.3 it may work, but the 7.3 version has new/modified properties, which are not known by the other systems. When you now try to add a new or change a modified property, the non 7.3 systems will reject the configuration, and mark it as "invalid"
So that would indicate that the management unit should stay at the lowest version of all the systems so as not to encounter problems with systems running earlier versions rejecting configurations.
But then you stated:
Additionally you could start upgrading your complete installation to 7.3 step by step, and see how it works. 7.3 is fully supported and working fine. However you should not run both brances for a longer time or while you still want to apply changes from time to time.
My near term deployment will entail 8 dedicated MWGs functioning as proxies and 2 systems dedicated to management functions. Makes sense that the mgmt systems shouldn't be put into a situation where they're trying to talk new stuff to proxies running older software, but if I upgraded the production proxy systems to 7.3 while the mgmt systems remained on 7.2, would that cause significant problems?
Thanks in advance,
sorry for the confusion. I will try to make some specific recommendations :-)
When running a cluster (central management) of different versions there are most likely two things that may cause problems:
1. Properties were added
This causes problems when, as stated earlier, you upgrade the "master" (management instance) to a newer version. If you try to make changes and (accidentally) choose a new property, the "sites" (non-management instances) will fail to store the modified policy. They will tell the "master" that the policy is incorrect or broken, since they do not know about the new properties, so they can´t tell what exactly is the problem with the policy.
2. Properties were changed
It can also happen that properties change. In the past we had a property which started to require a parameter, which it did not require before. Now it does not matter whether you upgraded the master or one of the site instances, you will encounter problems when such a property is used in your policy or you want to add it. If the sites are newer and the master will try to save the property without the required parameter the sites will tell "there is a parameter missing for that property".
If the master is newer and you want to store the sites will get the property with a parameter they do not expect, and they will complain.
NOTE: Properties are not changed very often like in the above example (to avoid problems in mixed clusters). It may be unlikely that you encounter this problem, but it CAN happen to you, so I would like to make you aware.
Keeping this in mind I do not recommend customers to run different versions within the same cluster. Even if the chance may be low that they encounter incompatibilities the chance is present, and usually you don´t want to risk anything in your production environment.
Certainly if you upgrade you will have a time period running different versions. Usually this is only temporarily and you would not apply larger policy changes while being in the upgrade process, so this is fine. When I stated
"Additionally you could start upgrading your complete installation to 7.3 step by step, and see how it works"
I wanted to say if you decide you want to use 7.3 you can start migrating from 7.2 to 7.3 by upgrading a node, see how it works for a couple of days, then upgrade the next one, etc. But the target should be a cluster running on 7.3 completely, not a mixed cluster. While in the migration process you should avoid larger policy changes.
- Can a mixed cluster work without any problems? - Yes
- Can a mixed cluster cause unforeseen problems? - Yes
- Do I recommend a mixed cluster in production? - No
If you have 8 boxes and two management devices you could think about splitting the cluster into two clusters with each 1 master and 4 sites, and migrate one to 7.3 to compare versions. This means (of course) that a policy change has to be done on both management devices, since the clusters become independent.
Maybe a good question is why you want to go to 7.3? At this point of time 7.3 is the controlled release, so only new customers or customers requiring specific features/bugfixes in 7.3 should upgrade. If 7.2 is running fine, I do not recomment to upgrade, but wait until 7.3 becomes the main release and superseeds 7.2.
If you are just "curious" about 7.3 - put it into a VM :-) If you have issues with 7.2 they should be reported to support - they will recommend 7.3 if there is a bugfix available which cannot be backported to 7.2. In this case you certainly want to migrate your complete cluster to 7.3.
I'm going to mark your latest as Correct Answer because it's the best answer I've received to date.
I'll preface the following by stating that although I'm interested in 7.3, my plan is to wait until the first 7.3.x release ships and then wait a few weeks after that release date to ensure that there's nothing catastrophic introduced into the code base.
When that comes to pass, it sounds like one option would be to split the clusters multiple ways:
Break apart 4 proxies + 1 mgmt system from the other 4 proxies + 1 mgmt system.
Then break apart a 4+1 set into a 2 proxy +1 mgmt system set and a 2 proxy set.
Upgrade the 2 proxy + 1 mgmt system set and see how things work out in production. If all goes well, add in the 2-proxy set. Then repeat for the other set.
Alternately, I could break off a single proxy system and upgrade it and monitor it. Anyways, multiple options, but extremely good to know the risks associated with a 7.2/7.3 mix of systems.
There are several reasons that I'm interested in 7.3:
New features of interest:
- Application control for individual functions
- Additional options for the REST interface
- Whatever undocumented features may exist that we can utilize
Bug fixes of interest:
- Multiple. Nuff said.
just wait a couple of weeks and when you are interested just let me know and I will look up how many customers have already switched to 7.3. Currently we have 6% of our installation base running on 7.3... no catastrophic problems so far :-)