using Snapcenter in a segregated network

[bobalon]

Hi there

For security reasons we have a segregated network, with Snapcenter and the storage controllers in Zone A and the host servers in zones B C and D.

Each Zone has its own SVM to support the hosts and is providing storage over iscsi to the hosts. To allow snapcenter to manage the SVMs the SVMs for Zones B C and D have 2 management IPs on separate lifs and Vlans. e.g IP 1 192.x.x. and IP2 10.x.x.x

issue arises when trying to implement snapcenter and adding SVMS to Snapcenter that it can resolve and that the hosts can access.

So far using Snapcenter 4.4 i have tried

1: Adding the SVM with the local IP and the Host zone IP as preferred. Error Snapcenter cannot access preferred IP so will not add host

2: Adding the SVM with the Host Zone IP, Error snapcenter cannot access the preferred IP

3: Adding the SVM via a DNS name  locally resolvable to Snapcentre local management IP - error when host enumerates storage as gets storage controller SVM details from Snapcenter and selects incorrect IP for management

4: Adding the SVM via a full FQDN, resolvable locally and in the host zone to the relevant IPs - error as 3  host plugin does not appear to do a  local dns lookup and gets the storage controller details from snapcenter and selects the incorrect IP for management

when enumerating the storage on the host the logs show the correct IP for the host zone is listed second but as no preference IP is set it chooses the first, and fails to connect.

It seems the preferred IP option was created to overcome the problems above, but assumes that the Snapcenter server can access all areas! not ideal in a secure segregated environment.

Can anyone advise how  I can may be able to workaround or solve this  e.g. reorder the management IPs on the SVM so that the host selects the correct IP, or how I can set the preferred Ip without the snapcenter server then trying to connect to that IP and the throwing an error.

if any one from netapp is looking can we please consider a change so that the SVM IP for each host is defined when adding the host rather then letting  it discover this for itself - as this would solve the problem also and allow for segregated networks where Snapcenter does not require god like access.

any other suggestion or approach welcome as running out of road

thank you

[mrahul]

Rather than registering individual SVMs, if your Cluster IP is resolvable to SnapCenter server network. you can register the cluster with SnapCenter.

[bobalon]

Hi there

thank you for the suggestion, but unless the cluster IP is accessible from all zones (which would reduce the segementation) this will not work. The hosts and the SC servers are on seperate VLans and IP ranges. e.g Zone A is a 192.x.x.x network and Zone B C and D are 10.x.x.x subnets

To work around this limitation at present I have had to allow the SC servers in Zone A to access to the SVM management IPs via both Vlans i.e direct via Zone A and indirect via Zone B C and D , which then allows the preferred IP to be set to the SVM Management IP the Host should use.

[mrahul]

Good to know that your lab is working now with the network changes. Just that you know, SnapCenter doesn't require SVMs to have management LIFs as mandatory if you are registering cluster to SnapCenter server. This would also reduce your IP requirements at storage end.

[bobalon · Accepted solution]

hi there

you are missing the point of this issue. adding the cluster IP does not solve the problem. the reason for using separate SVMs and separate management IP ranges is to maintain segmentation and security within the network. You seem to assume all networks are flat and all resources have access to the cluster IP direct or to the same management VLans

hence my suggestion that you allow the administrator define the SVM IP that the host plugin should use rather than assuming the Snapcenter server can confirm and connect to all SVM management IPs and provide these to plugin

From my perspective the Snapcenter designers and architects need to consider its use in a segmented network.