In this NetApp training tutorial, I will cover the NetApp Service Processor (SP). The Service Processor provides remote management capabilities for your NetApp system. Scroll down for the video and also text tutorial.
NetApp Service Processor Video Tutorial
I just passed my NCDA and I owe many thanks to your in-depth, straight forward and enthusiastic content. Being able to see you teach all the features and functionality and then test them out myself was fantastic and helped the info sink in. The ability to come back to the content whenever I need a refresher on something complicated is extremely valuable. Whenever I hear of a new engineer looking to get their NCDA I always point them in your direction first.
What is a Service Processor?
Service Processor is an independent system used for monitoring and management of the storage system properties through the System Manager.
Since the Service Processor operates as an independent system, you can think of it as a separate computer within the controller chassis. It doesn't depend on the controller and ONTAP to be up to continue to operate. As long as one power supply is connected and supplying power, the Service Processor will stay up and available, even if ONTAP is down.
Service Processor SP vs Remote LAN Module RLM vs Baseboard Management Controller BMC
It did the same job as the Service Processor and was available in the NetApp FAS30x0, FAS31x0, and FAS60x0 series systems. Prior to that, we had the Baseboard Management Controller (BMC) in the SA200 and FAS20x0 systems.
NetApp Service Processor Overview
The Service Processor has got its own IP address and its own command line which you can SSH into, separate from the main ONTAP operating system. You can access, monitor, and troubleshoot the system from the SP CLI.
There is a limited set of commands available at the Service Processor CLI, designed for monitoring and troubleshooting. See the NetApp Knowledge Base article ‘What is a Service Processor and how do I use it?’ article for the full list of commands.
You can view environmental properties such as the system temperature, fan speeds, and voltages, and you can reboot your system. You can also console connect to the normal ONTAP CLI through the Service Processor if the usual Management IP address is unresponsive.
Service Processor AutoSupport Messages
You can SSH into the Service Processor, and you can view environmental properties yourself from there. The system also does this monitoring automatically by itself. If it sees that the environmental properties are outside limits, it will send an AutoSupport message to notify NetApp.
If there is a serious issue such as the system is overheating, it will automatically shut down the system to save it from having long-term damage.
Service Processor Topology
Let's look at the topology of the Service Processor.
In the diagram above, we've got our physical management switch at the top, connected to the physical management port on the controller. The management port is identified by a picture of a wrench on the back of the controller. The e0m port with the Node Management IP address for normal management of the system lives here.
The Service Processor also lives behind the management port. It doesn't have its own separate physical port. Behind the physical management port, we have a virtual switch. The virtual switch is not a physical thing, it’s internal in the controller.
The e0m port, which is your normal management port, is connected to that virtual switch. The Service Processor is also connected to the virtual switch. The Service Processor is its own entity, separate from ONTAP.
You have your normal Node Management IP address for ONTAP on the e0m port. Say, for example, we're using 10.10.10.10. The Service Processor is also available behind the same physical port on your controller. We give it a different IP address that’s in the same subnet, for example, 10.10.10.11. Now we have connectivity to both.
We also have a physical console port on our controller, identified with an ‘IOIOI’ symbol on the back of the controller. e0m and the Service Processor are also available through the console port, as well as through the physical management port.
Service Processor Configuration
As long as the Service Processor IP address is available, you can SSH into it for monitoring and troubleshooting, and you can also access the normal ONTAP CLI from there.
To set this up, you need to put an IP address on the Service Processor. Using our example in the diagram above, the command we would enter would be:
system service-processor network modify -node cluster1-01 -address-family IPv4 -enable true -ip-address 10.10.10.11 -netmask 255.255.255.0 -gateway 10.10.10.1
The command is entered at the normal ONTAP command line.
Each node in the cluster is its own separate controller. Each controller has its own Service Processor. The Service Processors are configured at the node level. If you had an 8-node cluster, you would need to enter the command 8 times - once for each of your different nodes.
Accessing the Service Processor
Once the Service Processor has been set up there are two ways to access it. The most common way is to SSH to the Service Processor IP address, and log in with the admin account.
We can also press CTRL-G if we're in a console session. To get back to the normal console session, we press control-D to break out.
When you log in to the SP, you're not at the ONTAP command line. You're at the Service Processor command line which is a different CLI with monitoring commands.
The last thing to tell you about the Service Processor is that it supports the Hardware-Assisted Failover feature for High Availability.
Controllers in a High Availability pair send each other keepalives over the HA connection. If several keepalives are missed, then a failover will be initiated. Let’s say we have Controller 1 and Controller 2 as shown in the diagram below.
They are an HA pair and have the HA connection. If Controller 1 fails, then Controller 2 will stop receiving keepalives from it. It's not going to failover as soon as it misses one keepalive though, because maybe it was just a temporary glitch over the connection.
Failovers can be disruptive events, so we don't want to failover unless we really have to. Controller 2 is going to wait for several missed keepalives until it fails over. This is good because it makes things more reliable, but it's bad in that it's going to take longer for the failover to occur, so we’ll have a longer outage when there really is a problem.
There's a way that we can speed this up by using the Service Processors. This is the Hardware-Assisted Failover feature. To enable this, all you have to do is configure IP addresses on your Service Processors. Once that is done, as part of the High Availability setup the two controllers in an HA pair will tell each other their Service Processor's IP address.
Let’s look at our example again. When Controller 1 fails, as long as it's got one power supply still up and running, its Service Processor will still be operational. The Service Processor is monitoring ONTAP, and it will see that the system has gone down.
When this happens, it will immediately signal over to Controller 2 telling it to initiate a failover. This means that Controller 2 doesn't wait for the missed keepalives over the HA connection, it will initiate a failover immediately. This speeds up our High Availability failover.
The official NetApp documentation is pretty sparse, Eric Railine has an excellent tour of the Service Processor on his blog.