ONTAP is keeping the twice-yearly release cadence by providing spring and fall releases to keep up with the need for new and rapidly developing features. In addition, the cloud versions of ONTAP will use different release numbers. ONTAP 9.9 signifies the cloud release of ONTAP and ONTAP 9.9.1 is the on-prem release.
You can download the latest ONTAP releases here:
https://mysupport.netapp.com/site/products/all/details/ontap9/downloads-tab
So, here’s a brief rundown on what’s new in ONTAP 9.9.1 (copied from the customer communiques that go out). You can also view the Feature Overview TR for ONTAP 9.9.1 here:
https://docs.netapp.com/us-en/ontap-whatsnew/ontap991fo_netapp_ontap.html
Simplified Management
ONTAP System Manager enhanced UI. ONTAP System Manager 9.9.1 supports new ONTAP 9.9.1 capabilities including ASA Cluster expansion, SVM-DR support for FlexGroup volumes, and more. In addition to the new features, NetApp has made many enhancements to address customer feedback, such as improved capacity reporting, support for nested iGroups, UI performance optimizations, and much more.
SnapMirror® Business Continuity (General Availability)
For your SAN workloads, this feature enables flexible, cost-effective, instant failover for your most important business applications such as SAP, Oracle, and more. You have the flexibility to improve TCO by consolidating many different types of workloads onto your ONTAP based systems and then granularly deciding which critical SAN workloads you want supported with the continuous availability of SMBC. SMBC enables applications to fail over to a secondary copy of storage without requiring the application to reconnect to the storage or disrupting the users of that application. It expands your choices across the spectrum of NetApp solutions and partnerships that deliver business continuity, disaster recovery, backup and recovery, and Snapshot™ technology.
New MetroCluster IP enhancements.
Customers can maximize capacity and performance with scalability up to 8-node NetApp MetroCluster IP configurations. Also, ONTAP 9.9.1 RC1 supports routed layer 3 network configuration and up to 1,600 volumes per HA pair.
SnapLock/WORM Compliance
- Storage efficiencies for SnapLock volumes – supports volume data compaction, cross volume or aggregate level deduplication (AFF only), continuous segment cleaning, and Temperature Sensitive Storage Efficiency.
- Ransomware protection support for snapshot copies containing LUNs
FlexGroup Enhancements
- SnapMirror topology (Cascade and Fanout) – replicate a FlexGroup from site A to site B to site C (cascade) or site A to sites B and C (fan-out)
- Storage Virtual Machine Disaster Recovery (SVM-DR) – replicate FlexGroup volumes and SVM configuration (CIFS shares, NFS exports, data LIFs, NFS file handles)
- Logical Space Accounting/Enforcement – Monitor and enforce based on the actual storage used before efficiencies are applied for more accurate chargebacks
All SAN Array Enhancements
- Scalable out ASA clusters. Customers can leverage the power of ONTAP clustering with scale out up to 12 nodes of ASA systems. ASA clusters can include a mix of ASA system types.
- Increase performance with NVMe-OF on ASA systems. With ONTAP 9.9.1 RC1, modernize and accelerate business applications nondisruptively with NVME-oF for ASA systems.
- AFF to ASA in-place conversion. For your mission-critical SAN workloads running Unified AFF, take advantage of ASA benefits such as large LUN support (128TB) and symmetric active-active support with seamless AFF to ASA in-place conversion capability.
- Single LUN performance improvement. With ONTAP 9.9.1 RC1, single LUN performance has been significantly improved compared to previous ONTAP releases. Ideal for simplifying deployments in virtual environments; for example, A800 can provide up to 400% more random read IOPS.
Data Protocol Enhancements
- NFSv4.2 Security Labels (MAC labels) – MAC labels enable granular file access control with SE Linux, above and beyond Unix permissions and NFSv4 ACLs. The benefits provided by this feature include multilevel security for files, simplifying administration of sensitive NAS data in highly secure environments.
- ONTAP S3 object tags for ObjectCreate and MultipartUpload calls – When a HEAD or GET is performed on an object, the user defined metadata and count of the number of tags will be returned as part of the HTTP header in the response. These tags allow you to better categorize your objects within ONTAP buckets for more robust data management and are compatible with applications that require the ability to create metadata and tags.
Will Ontap 9.9 implement NIS over LDAP in the “secure” or in the “sloppy” way ?
https://www.netapp.com/pdf.html?item=/media/19423-tr-4835.pdf page 73 and page 74 contradicts each other.
“netgroup.byhost entries can vastly speed up netgroup entry lookup. With netgroup.byhost, the
cluster can avoid having to query every entry in a netgroup for access and instead can fetch the netgroup
by way of LDAP lookup per host.”
According the Oracle documentation (https://docs.oracle.com/cd/E19253-01/816-4556/anis2-14244/index.html) netgroup.byhost entries are also just a “speedup” addition to the classical nisNetgroup (on which i can put access rights in the AD).
“On a network using NIS, the netgroup input file on the master NIS server is used for generating three maps: netgroup, netgroup.byuser, and netgroup.byhost. The netgroup map contains the basic information in the netgroup input file. The two other NIS maps contain information in a format that speeds lookups of netgroup information, given the machine or user.”
A client which has only a nisObject entry in the AD with the name of the netgroup is in the nisMapEntry attribute but no entry in nisNetgroupTriple should be denied.
But on page 74 the example shows that the speedup is a replacement, the centos get access while there is no nisnetgroup triple – while the netgroup members are blocked.
I can hardly imagine a use case for this behavior.
Imaging Brain ordered a Export datasvm.acme.corp:/datavol/brainqtree at the file service department of ACME.
They create a OU ou=brainqtree,ou=datasvm,ou=fileservices,dc=acme,dc=corp and but 3 netgroups ng_brain_root,ng_brain_ro,ng_brain_rw for each export-policy rule in.
Brain add “(evilmachine.acme.corp,-,-)” to the nisNetgroupTriple attribute of his root netgroup and has now full control over his data – and only he has.
Pinky can order a Export datasvm.acme.corp:/datavol/pinkyqtree for his narfserver.acme.corp too which resides on the same SVM – same volume – just in another qtree. He can ask Brain for read access to his share too – Brain can deny or put Pinky’s server in the root-squashed netgroups and keep control over his data.
You see netgroup.byname works well here.
When changing to netgroup.byhost I need allow Pinky and Brain to create his own nisObjects and set the and how can I prevent that pinky add ng_brain_root to the nisMapEntry attribute ?
I always thought I have to protect the date against the clients, but the Netapp approach seems to be built to protect the clients against data oO NARF.
LikeLike
There is no contradiction here.
When you set is-netgroup-by-host-enabled, ONTAP no longer uses the standard NisNetGroupTriple field for netgroup lookups. Instead, it takes the netgroup name and searches LDAP for a nisMapEntry with the netgroup name for a nisObject that has the correct hostname attempting access rather than populating all the entries in a netgroup, which can take a lot of time if there are hundreds or thousands of entries.
This command checks the netgroup “netgroup1” if the host “centos7” is in the netgroup. Netgroup.byhost is used because it’s enabled:
::*> getxxbyyy netgrpcheck -node node1 -vserver DEMO -netgroup netgroup1 -clientIP x.x.x.x
(vserver services name-service getxxbyyy netgrpcheck)
Client x.x.x.x is not a member of netgroup netgroup1
Searched using NETGROUP_BYHOST
This is the LDAP search filter as seen from a packet capture.
x.x.x.x = client IP
x.x.x.y = Data LIF in ONTAP
x.x.x.z = LDAP server/DNS server/DC
First we do a reverse DNS lookup:
183 9.037971 x.x.x.y x.x.x.z DNS 86 Standard query 0x4e05 PTR x.x.x.x.in-addr.arpa
184 9.038133 x.x.x.z x.x.x.y DNS 139 Standard query response 0x4e05 PTR x.x.x.x.in-addr.arpa PTR sles15 PTR centos7.ntap.local
We take that name from DNS (centos7) and then use it in an LDAP search for a nisObject with that name.
187 9.042335 x.x.x.y x.x.x.z LDAP 179 searchRequest(5) “DC=NTAP,DC=LOCAL” wholeSubtree
Filter: (&(objectClass=nisObject)(name=centos7.*))
It’s looking for two attributes:
AttributeDescription: nisMapName
AttributeDescription: nisMapEntry
If it can’t find the entry we’re looking for, then we try the same LDAP search using the IP address in case that’s what the entry is added as. If that fails, too then we determine the host is not a member of the netgroup. (as shown in the above command)
When the entry *is* a member (this time, we use the netgroup “powershell”) this is what it looks like:
::*> getxxbyyy netgrpcheck -node node1 -vserver DEMO -netgroup powershell -clientIP x.x.x.x -show-source true
(vserver services name-service getxxbyyy netgrpcheck)
Success. Client x.x.x.x is member of netgroup powershell
Searched using NETGROUP_BYHOST
Source used for lookup: LDAP
The trace looks like this now (as we found the entry):
34 1.248029 x.x.x.z x.x.x.y LDAP 497 searchResEntry(19) “CN=centos7.ntap.local.*,CN=netgroup.byhost,OU=netgroups,DC=NTAP,DC=local” | searchResRef(19) | searchResRef(19) | searchResRef(19) | searchResDone(19) success [2 results]
objectName: CN=centos7.ntap.local.*,CN=netgroup.byhost,OU=netgroups,DC=NTAP,DC=local
type: nisMapName
AttributeValue: netgroup.byhost
type: nisMapEntry
AttributeValue: powershell
If I disable netgroup.byhost, we’re not looking for the same things.
::*> getxxbyyy netgrpcheck -node node1 -vserver DEMO -netgroup netgroup1 -clientIP x.x.x.x -show-source true
(vserver services name-service getxxbyyy netgrpcheck)
Client x.x.x.x is not a member of netgroup netgroup1
Searched using NETGROUP_BYNAME
Source used for lookup: LDAP
This is the LDAP query:
199 10.144881 x.x.xy x.x.x.z LDAP 195 searchRequest(11) “DC=NTAP,DC=LOCAL” wholeSubtree
In the netgroup.byhost search, we’re looking for a nisObject with the hostname we gathered from DNS.
In this search, we’re looking for this:
Filter: (&(objectClass=nisNetgroup)(name=netgroup1))
And these are the attributes we want:
AttributeDescription: nisNetgroupTriple
AttributeDescription: memberNisNetgroup
And this is the response:
200 10.145327 x.x.x.z x.x.x.y LDAP 434 searchResEntry(11) “CN=netgroup1,OU=netgroups,DC=NTAP,DC=local” | searchResRef(11) | searchResRef(11) | searchResRef(11) | searchResDone(11) success [2 results]
objectName: CN=netgroup1,OU=netgroups,DC=NTAP,DC=local
PartialAttributeList item nisNetgroupTriple
type: nisNetgroupTriple
AttributeValue: (sles15-1,,)
We don’t have the host “centos7” in the triple here, thus we are disallowed access.
I can find the host in the “powershell” netgroup still, as the host is in the netgroup triple in that netgroup.
Basically, you’re either controlling netgroup access centrally (via a nisNetgroup object) or on each host entry (with a nisMapEntry/nisMapName).
You wouldn’t normally “allow” Pinky and Brain to create their own NIS objects; the domain administrator of AD does that. That’s where the security comes in. Why do you think we need to allow clients to define their own access to mounts? That’s the same for netgroup.byname; you add hosts to the NisNetgroupTriple field the same way – via AD.
Of course if you give the keys to the castle to the clients it’s less secure – that has nothing to do with NetApp, which uses a the IETF standard for netgroups. That’s on the admins.
All netgroup.byhost does is provide an alternate lookup method for netgroups that uses the hostname and netgroup name to find things more efficiently than dumping out the entire contents of the netgroup each time access is requested.
The Oracle link you provided is for classic NIS, which is not what I was referring to in the TR. Maybe that’s why you were confusing things?
LikeLike