what is the CPU Concurrency for iSCSI processing in ONTAP 9.3 on 16 or more cores

[Ontapforrum]

Hi,

Per this KB:
https://kb.netapp.com/app/answers/answer_view/a_id/1001217/~/faq%3A-cpu-utilization-in-data-ontap%3A-scheduling-and-monitoring-

ssan_exempt = Introduced in clustered Data ONTAP 8.2 = CPU Concurrency = 1+ CPU


According to the iSCSI Performance improvements in 9.3:
The entire iSCSI stack was re-written for ONTAP 9.3 : iSCSI (ONTAP 9.3) is now able to take advantage of numerous CPU cores.

My question is :
In ONTAP 9.3 what is the CPU Concurrency for iSCSI processing on systems such as AFF-A300 with 16 cores ?


Thanks,
-Ashwin

[AlexDawson]

CPU concurrency refers to how many CPUs a given type of task can run on - in this instance, the SSAN process can run on multiple CPUs, but this would require multiple volumes and balances against how many other tasks are running.

If this level of performance consideration is important to you, please work with a NetApp partner and/or NetApp Systems Engineer to ensure the systems proposed meet you business needs. 

[Ontapforrum]

Thanks for taking time to attend to this query. I appreciate it. This was just a educational query for me, and perhaps others who are equally interested to udnerstand how CPU concurreny works in - Multi CPU and All Flash SSD environment, perhaps in more technical depth. 

CPU concurrency is very well explained in that KB, so that wasn't my question.

This is a curiosity to understand  what exact NetApp means when you say :"iSCSI (ONTAP 9.3) is now able to take advantage of numerous CPU cores each of which can concurrently process iSCSI threads" ?

Example : If  I have AFF-A300 runing ONTAP 9.3, Per Node : 8 cores (16 threads) and  128 GB Mem.

Two scenarios:

1st :    2 Volumes [ 2 LUNs] and 2 iSCSI data session = Will it be '2' cores and '4' threads

2nd :  1 Volume [ 1 LUN] and   1 iSCSI data session = Will it be '1' core and '2' threads

Basically one-2-one mapping between volume and CPU.

Further, what I was really curious to understand is : First, depending upon heavy client workload of random [read/write ratio of 30/70] on a particular LUN (Volume), how does it work in the today's SSD & Multi-core CPU environment. I udnerstand that CPU domains have been created in order to split the domain specfiic processes to run on different cores to make the most of the multi-core CPUs.

My curiosity is : With SSDs there is no disk waiting kind of scenarios on CPU {as there is no mechanical parts, just electircal signals} SSDs for an example, let's say will do it's job in micro-seconds and interrupt (context switching) CPUs, isn't there a chances that eventually due to a heavy workload [100s of clients, accessign single volume data] and with mtu 1500 scenarios could choke-up the CPU ?  All I wanted to understand is - Will multi-cores be benefetial here, or it will still be bound to 1 CPU considering it's a single volume.

Thanks,

-Ashwin

[paul_stejskal]

Basically the code length was optimized by quite a bit for SAN operations in 9.3. You'll see benefits across multiple LUNs.

[AlexDawson · Accepted solution]

Hi there,

At a high level, ONTAP receives data in a seperate process to the one it uses for reading data and writing data to and from disks (or SSDs), so multiple cores will be used for different parts of the transaction, but actual volume access is a per volume process, in order to ensure in-order read/write, which will then be assigned to one processor thread at a time. My understanding is that the two iSCSI sessions will run as different threads, but that data I/O for a single volume will be running on a single thread.

Hopefully this answers your query in terms of interest, as we are unlikely to talk much more in depth in a public forum, but I would really encourage you to go far beyond this in looking at your storage operations - be it for comparison purposes, or in terms of understanding of how to run the system.

If you have specific performance needs, please let your sales team know, and we'll be able to meet it. We aim to make our systems easy to run, so that you don't need to know how we do it, just that it will work. Check out our most recent SpecFS results - https://www.spec.org/sfs2014/results/res2019q1/sfs2014-20190125-00061.html for validation.

[Ontapforrum]

Thank you Alex for this information. I appreciate it.