You all are familiar with goodies of R80.10, but the cost to have these features might be high. The path to the R80.10 has not been smooth and some very useful R77.30 Multi-Domain server features are not available in R80.10 anymore.
Some missing features
No CMA export anymore! According to the TAC export of a CMA is not supported anymore since R80 and maybe it is going to be implemented in the future. Hello R80.20, do you have this feature? CMA export was a reliable and quick way to have a backup of a CMA and it was possible to migrate CMA data from one MDS to another MDS.
The Cross-CMA search was a really fine tool under R77.30 in GUI and on CLI as well. In R80.10 you are on your own and you might use or create an API script but you could not get results under 10 seconds line in R77.30. 3rd party tools might be needed which fetch periodically info from the MDS and which allow to run local search on top of it's internal database. Tufin costs some $$$.
SmartLog had nice timeline view about frequency of filtered events which R80.10 does not have anymore. In the R77.30 the log and index rotation policy could be tuned in each CMA individually, which again is not possible under R80.10 MDS, all domain are supposed to have the same rotation settings.
Just annoying issues
After a restoration of a backup additional time is needed to build the solr index.
mds_backup might get stuck dumping the DB from time to time.
R77.30 -> R80.10 gradual upgrade scripts still have bugs, admin users in R80.10 MDS might lose their certificates during R77.30 CMA import/upgrade.
The SmartConsole enables anti-spoofing on each interface when fetching interface details without topology. The fix will be available in the future, but hey, how long the R80.10 has been out there?
MDS performance
Management server - it takes all you could throw at it.
The R77.30 Multi-Domain Server performed well on a VM having 64GB RAM and 16 CPU cores, the R80.10 VM has finally got 200GB RAM and 30 CPU cores and still quite often solr indexing must be restarted to get any response to log search queries and overall search response time has grown. It was a quite a struggle to get good recommendations to improve stability and performance of the MDS from TAC. The final recommendation is to spend some money on licenses and set up a dedicated MLM and it is supposed to cure all our performance and stability problems in the management server It seems that R80.10 solr is not capable of handling the same amount of logs the R77.30 did while having almost 2x more CPU cores and 3x RAM. A fat minus to R80.10, need to spend more $$$.
The MDS VM has consumed all the resources several times, resulting at least one hour of downtime each time.
And the main hit of R80.10, the API is still in it's early age, many operations take much more time than using cpmiquery or dbedit, in general the API is just way too slow and needs some internal redesign OR some nice documentation how to make it faster, maybe it would be enough to change stock configuration and provide more resources to the components serving the API.
Feature wise the API has been out more than 2 years, some additional features have been added into version 1.1, but as far as I know there is still no solid way to create clusters only by using the API. I would be thankful if I am wrong and have missed some details in documentation.
Don't get me wrong, the API is very useful, but there is some room for improvements.
Gateway performance
There are several sweet features in R80.10 gateway software, some bottlenecks have been solved (big hopes are on the multi core VPN) but again the performance is a concern, at least for now. Maybe it is too early to draw final conclusions but initial impressions about an upgraded HA cluster are not very promising. The firewalls in a pre-prod HA cluster have only trivial FW, VPN blades, SecureXL acceleration stats being over 90% under R80.10, but average worker CPU usage is about 65% in R80.10 and CUL kicks in very often, in R77.30 average worker CPU usage used to be between 25-35% in the vry same environment. Two fold CPU usage rise is high enough to get attention. According to the smokeping the average ping latency used to be about 0.6 ms, after the upgrade it has been almost 2 ms including high latency peaks. We have an ongoing investigation about this performance problem, but at least at first it seems to be a clear warning sign not to rush into R80.10 gateways, maybe in our case it would be better to wait some months and upgrade to R80.20 gateways.