In an ONTAP cluster made up of individual nodes with individual hardware resources, it’s useful if a storage administrator can manage the entire cluster as a monolithic entity, without having to worry about what lives where.
Prior to ONTAP 9.3, name service caches were node-centric, for the most part. This sometimes could create scenarios where a cache could become stale on one node, where it was recently populated on another node. Thus, a client may get different results depending on which physical node the network connection occurred.
The following is pulled right out of the new name services best practices technical report (https://www.netapp.com/us/media/tr-4668.pdf), which acts as an update to TR-4379. I wrote some of this, but most of what’s written here is by the new NFS/Name Services TME Chris Hurley. (@averageguyx) This is basically a copy/paste, but I thought this was a cool enough feature to highlight on its own.
Global Name Services Cache in ONTAP 9.3
ONTAP 9.3 offers a new caching mechanism that moves name service caches out of memory and into a persistent cache that is replicated asynchronously between all nodes in the cluster. This provides more reliability and resilience in the event of failovers, as well as offering higher limits for name service entries due to being cached on disk rather than in node memory.
The name service cache is enabled by default. If legacy cache commands are attempted in ONTAP 9.3 with name service caching enabled, an error will occur, such as the following:
Error: show failed: As name service caching is enabled, "Netgroups" caches no longer exist. Use the command "vserver services name-service cache netgroups members show" (advanced privilege level) to view the corresponding name service cache entries.
The name service caches are controlled in a centralized location, below the name-service cache command set. This provides easier cache management, from configuring caches to clearing stale entries.
The global name service cache can be disabled for individual caches using vserver services name-service cache commands in advanced privilege, but it is not recommended to do so. For more detailed information, please see later sections in this document.
ONTAP also offers the additional benefit of using the caches while external name services are unavailable. If there is an entry in the cache, regardless if the entry’s TTL is expired or not, ONTAP will use that cache entry when external name services servers cannot be reached, thereby providing continued access to data served by the SVM.
Hosts Cache
There are two individual host caches; forward-lookup and reverse-lookup but the hosts cache settings are controlled as a whole. When a record is retrieved from DNS, the TTL of that record will be used for the cache TTL, otherwise, the default TTL in the host cache settings will be used (24 hours). The default for negative entries (host not found) is 60 seconds. Changing DNS settings does not affect the cache contents in any way.
- The network ping command does not use the name services hosts cache when using a hostname.
User and Group Cache
The user and group caches consist of three categories; passwd (user), group and group membership.
- Cluster RBAC access does not use the any of the caches
Passwd (User) Cache
User cache consists of two caches, passwd and passwd-by-uid. The caches only cache the name, uid and gid aspects of the user data to conserve space since the other data such as homedir and shell are irrelevant for NAS access. When an entry is placed in the passwd cache, the corresponding entry is created in the passwd-by-uid cache. By the same token, when an entry is deleted from one cache, the corresponding entry will be deleted from the other cache. If you have an environment where there are disjointed username to uid mappings, there is an option to disable this behavior.
Group Cache
Like the passwd cache, the group cache consists of two caches, group and group-by-gid. When an entry is placed in the group cache, the corresponding entry is created in the group-by-gid cache. By the same token, when an entry is deleted from one cache, the corresponding entry will be deleted from the other cache. The full group membership is not cached to conseve space and is not necessary for NAS data access, therefore only the group name and gid are cached. If you have an environment where there are disjointed group name to gid mappings, there is an option to disable this behavior.
Group Membership Cache
In file and NIS environments, there is no efficient way to gather a list of groups a particular user is a member of, so for these environments ONTAP has a group membership cache to provide these efficiencies. The group membership cache consists of a single cache and contains a list of groups a user is a member of.
Netgroup Cache
Beginning in ONTAP 9.3, the various netgroup caches have been consolidated into 2 caches; a netgroup.byhost and a netgroup.byname cache. The netgroup.byhost cache is the first cache consulted for the netgroups a host is a part of. Next, if this information is not available, then the query reverts to gathering the full netgroup members and comparing that to the host. If the information is not in the cache, then the same process is performed against the netgroup ns-switch sources. If a host requesting access via a netgroup is found via the netgroup membership lookup process, that ip-to-netgroup mapping is always added to the netgroup.byhost cache for faster future access. This also leads to needing a lower TTL for the members cache so that changes in netgroup membership can be reflected in the ONTAP caches within the TTL timeframe.
Viewing cache entries
Each of the above came service caches and be viewed. This can be used to confirm whether or not expected results are gotten from name services servers. Each cache has its own individual options that you can use to filter the results of the cache to find what you are looking for. In order to view the cache, the name-services cache <cache> <subcache> show command is used.
Caches are unique per vserver, so it is suggested to view caches on a per-vserver basis. Below are some examples of the caches and the options.
ontap9-tme-8040::*> name-service cache hosts forward-lookup show ?
(vserver services name-service cache hosts forward-lookup show)
[ -instance | -fields <fieldname>, ... ]
[ -vserver <vserver name> ] *Vserver
[[-host] <text>] *Hostname
[[-protocol] {Any|ICMP|TCP|UDP}] *Protocol (default: *)
[[-sock-type] {SOCK_ANY|SOCK_STREAM|SOCK_DGRAM|SOCK_RAW}] *Sock Type (default: *)
[[-flags] {FLAG_NONE|AI_PASSIVE|AI_CANONNAME|AI_NUMERICHOST|AI_NUMERICSERV}] *Flags (default: *)
[[-family] {Any|Ipv4|Ipv6}] *Family (default: *)
[ -canonname <text> ] *Canonical Name
[ -ips <IP Address>, ... ] *IP Addresses
[ -ip-protocol {Any|ICMP|TCP|UDP}, ... ] *Protocol
[ -ip-sock-type {SOCK_ANY|SOCK_STREAM|SOCK_DGRAM|SOCK_RAW}, ... ] *Sock Type
[ -ip-family {Any|Ipv4|Ipv6}, ... ] *Family
[ -ip-addr-length <integer>, ... ] *Length
[ -source {none|files|dns|nis|ldap|netgrp_byname} ] *Source of the Entry
[ -create-time <"MM/DD/YYYY HH:MM:SS"> ] *Create Time
[ -ttl <integer> ] *DNS TTL
ontap9-tme-8040::*> name-service cache unix-user user-by-id show
(vserver services name-service cache unix-user user-by-id show)
Vserver UID Name GID Source Create Time
---------- ----------- ------------ -------------- ------- -----------
SVM1 0 root 1 files 1/25/2018 15:07:13
ch-svm-nfs1
0 root 1 files 1/24/2018 21:59:47
2 entries were displayed.
If there are no entries in a particular cache, the following message will be shown:
ontap9-tme-8040::*> name-service cache netgroups members show
(vserver services name-service cache netgroups members show)
This table is currently empty.
There you have it! New cache methodology in ONTAP 9.3. If you’re using NAS and name services in ONTAP, it’s highly recommended to go to ONTAP 9.3 to take advantage of this new feature.
