ontap-nas-economy HA

[sebastianries]

Hello

We are planning to use the plugin on some standalone docker hosts. We will use the ontap-nas-economy driver to use less volumes in the Netapp-System and to separate the volumes of the different hosts within one SVM.

One open question is: How can we remap the netapp-volume to a new docker host e.g. in case of a reinstallation after a crach? Is it possible to configure the volume in the plugin configuration file?

Regards Sebastian

[clintonk]

Hello, @sebastianries. If you are asking about reinstalling nDVP, as long as the backend definition file is the same, especially including the storage prefix, the nDVP drivers (including ontap-nas-economy) should just rediscover all the same volumes and work fine from a different host.

[sebastianries]

Thank you for the quick answer. I tried this on a test system an it show: it just works. So now I just do not understand why ther is some ID appended to the volume name... Regards Sebastian

[adkerr]

@sebastianries,

What type of id are you seeing appended to the name? I think swarm and/or docker “services” will automatically append identifiers to related objects.

[clintonk]

@sebastianries, if you are asking about the Flexvols created by the ontap-nas-economy driver, then that is expected. Qtrees must reside in Flexvols, and the ontap-nas-economy driver manages the complete lifecycle of the those Flexvols, creating them as needed to match requested volume attributes and deleting them when no qtrees remain. The Flexvol names include the storage prefix from the config file as well as a random suffix to prevent name collisions; the latter may be what you're seeing.

[sebastianries]

@clintonk yes, this is everything as I expected and I am talking about exactly this random suffix. I did try to install the nDVP on a second maschine using the same config. This resulted in using the same volume with the same "random" suffix. So the suffix does not seem to be completely random. Do you know how this suffix is generated? Is there a way to fix this suffix (or the volume name)? I want to make sure that I can use the same netapp-volume (and therefore the same docker volumes inside it) when I have to replace the docker host. And I also want to be able to run multiple (single) docker hosts against the same SVM without sharing the volumes. Is there a way to configure this in the nDVP configuration? (I know that I can separate the docker hosts by using different prefixes)

Regards Sebastian

[sebastianries]

I played arround with it a litte bit: I deleted all docker volumes (qtrees on netapp) on server1 => they disappeard on netapp as expected but the volume still existed Then I restarted the plugin on server1 => the volume was deleted on the netapp After that I created a new docker volume on server2 => volume and qtree was created on netapp with a NEW random suffix => new qtree was visible on server1 without doing something

So it seems that the qtrees are found regardless what the random suffix is. Therefore I do now understand why it is needed....

Regards Sebastian

[adkerr]

The suffix is actually completely random. However, when creating a new qtree the driver first searches for an existing flexvol that starts with the known prefix that can satisfy the required attributes of the new qtree. This is why you saw the same flexvol getting reused.

If there are no existing flexvols, or the existing flexvol(s) cannot satisfy a required attribute or are full, then a new flexvol is created using the same prefix but a new random suffix (to prevent name collisions).

When searching for an existing qtree the ONTAP api allows us to list all the qtrees, regardless of owning flexvol, so that is why you saw the flexvol’s suffix didn’t seem to matter.

The flexvol to our driver simply a bucket in which to place the qtree. It’s name doesn’t really matter and since its entire lifecycle is controlled by the driver we didn’t include any way to tweak or change the random suffix generation.

[sebastianries]

@adkerr Thank you very much for the explanation. This exatly describes what I see and answeres my questions. With this I now know that I can

• easily reconnect the existing data by a new host by setting up the same prefix
• separate the volumes of different hosts by configuring different prefixes

This is exactly what I was searchig for.

Regards Sebastian