In previous posts, I showed how easy it is to configure advanced networking on new Avamar nodes without the need to use dpnnetutil. When you upgrade your Avamar grid to Avamar 6.1 there are some things you need to keep in mind, because adding nodes is not that easy any more, or is it?
When you want to add nodes to your Avamar 6.1 grid, there is a new procedure. First of all, you connect your eth1 and eth3 to the internal switch of the Avamar grid. Besides this, you need to wipe alle the files below the /etc/sysconfig/network folder. When you now want to add new nodes, you can “easily” do this using the AvInstaller web interface that is reachable on port 8543.
When the node addition procedure starts, you need to be sure the networking configuration is wiped out of the specified location. Why is EMC doing this? First of all, they want to make it easier for guys like us to add nodes to the grid. I think that makes sense, but it does not really mean it will be easier.
When proceeding with the node addition, you need to create a small csv file and fill in the desired networking part in here. I will not specify this in here, because it is not important for this post. The workflow will now try to detect new nodes connected to the internal switches by using somekind of broadcast. With the csv file, he will now try to configure the networking part of the new nodes.
Anyway, the node addition procedure uses somekind of predefined workflow which will process the small csv file for the networking configuration. Now he will compare this to the dpnnetutil.xml file, which is a file you generated at the initial grid installation. This means that when you changed the networking configuration on an Avamar OS level after the initial installation, the dpnnetutil.xml is not up to date anymore. Now the node addition workflow will give you all kinds of errors resulting in contacting EMC support most of the time.
Now you manually updated the dpnnetutil.xml file, which cost you quite some time I must say! Now you can proceed with the workflow.
When you are using VLAN tagging on your Bond0 (eth0 and eth2), I can not find a reason for configuring an IP on the Bond0 itself, but only on the subinterfaces. Do you remember the dpnnetutil procedure?
In the dpnnetutil procedure, even when using subinterfaces, you need to specify an IP configuration for the Bond0, besides doing this for the subinterfaces. Something you can easily workaround by configuring the networking part by yourself without using dpnnetutil. Now this is not possible anymore! Even the node addition workflow needs to have an IP configured on the Bond0 or else the workflow will fail again and you again need to contact EMC support. I needed to do this and it took EMC 4 days to find a solution for this issue. Besides this, they do not want to share this solution with me at this moment which is something I can understand.
What is the idea behind this post?
First of all I want to show you that EMC tries to make it easier for us to do some basic Avamar stuff, but will it be easier? Besides this, you kind of need to make sure you will never try to change the networking configuration on an Avamar grid and also need to make sure the Bond0 is configured with the use of a native vlan, even when you desire to use only subinterfaces to keep things clear. Something that is very common in the “networking infra” world.
The cool thing about adding nodes in Avamar 6.1 is that the balancing is now part of the regular maintenance window, so it will not have that much impact anymore on your backup windows and you do not need to keep an eye on it anymore. Some other nice improvement is that you can now add more than 2 nodes at the same time.
