Tag Archives: ccna

CCNA Data Center – The Finite State Machine in UCS

Finite State Machine

A key element of the Cisco UCS system you should understand is called the Finite State Machine (FSM). The FSM is a workflow model that is composed of the following:

  • A finite number of stages (states)
  • Transitions between those stages
  • Operations

The current stage in an FSM is determined by past stages and the operations performed to transition between the stages. A transition from one stage to another is dependent on the success or failure of an operation.

Cisco UCS Manager uses FSM tasks that run in the Data Management Engine (DME) to manage endpoints in the Cisco UCS object model. For your CCNA Data Center studies, it is very important that you realize what types of tasks fall under this FSM workflow model. These include:

  • Physical components – examples include the chassis, I/O module, and servers
  • Logical components – examples include the LAN cloud and policies
  • Workflows – examples include server discovery, service profile management, downloads, upgrades, and backups

The DME manages the FSM stages and transitions and instructs the Application Gateway (AG) to perform operations on the managed endpoints. Each stage can be considered to be an interaction between the DME, AG, and managed endpoint. The AGs do the real work in interacting with managed endpoints, such as the CIMC, adapter, or I/O module.

When all of the FSM stages have run successfully, Cisco UCS considers the FSM to be successful. If the FSM encounters an error or timeout at a stage, the FSM retries that stage at scheduled intervals. When the retry count has been reached for that stage, the FSM stops and Cisco UCS Manager declares the change to have failed. If an FSM task fails, Cisco UCS Manager raises faults and alarms.

Multiple FSM tasks can be associated with an endpoint. However, only one FSM task at a time can run. Additional FSM tasks for the same end point are placed in a queue and are scheduled to be run when the previous FSM task is either successfully completed or fails. You can view the FSM details for a particular endpoint to determine if a task succeeded or failed. You can also use the FSM to troubleshoot any failures.

IoT Edge and Fog Computing

In my CBT Nuggets course – Cisco CCIE Evolving Technologies – we tackle IoT in some decent depth as required of us by Cisco Systems. In this post, I wanted to warm you up for some of that by introducing you to two terms – Fog and Edge Computing.

Fog Computing

These days, all we seem to hear about is cloud computing. And cloud computing certainly plays into IoT, as we’ll discuss. But there’s also edge and fog computing that is quite popular when it comes to the Internet of Things.

Fog Computing

Let’s actually start with fog computing. You’re going to note that both fog and edge computing refer to having processing taking place that is much closer to the actual devices than the cloud. So think about the cloud, public or private. It’s kind of way up there in the stack.

So we might have all of these IoT devices running at a local location. And we want computing to take place closer to them than that faraway cloud. So fog computing is an example of this. And where the processing takes place with fog computing is in the network devices, such as gateways and routers and switches that make up the network.

If we can do some of the processing there, closer to the actual devices– thus, the concept of fog, which is closer to the ground instead of a full-blown cloud– then this is going to do wonders for the IoT implementation. Typically, notice that we’re processing or storing information for the higher levels and those higher levels might actually exist in the cloud. We often do this in a hierarchical type format.

An example I want to give you is temperature monitoring. So let’s say we have these IoT devices that are monitoring temperatures.
 
If we can have intelligence in our network devices and do some fog computing, one of the things that we might have those devices do is see, inside the data, if there’s actually been any temperature change and, if there hasn’t been a temperature change, to stop the flow right there. Otherwise, the device can alert the cloud, and then have the cloud trigger some type of temperature alarm.
 So in this case, it’s reducing the amount of bandwidth we consume, and even reducing processing that we might need to do somewhere else in the stack, based on the fact that there’s been no temperature change.

Edge Computing

Edge computing takes the computing horsepower or the processing horsepower and it moves it even closer to the smart things by actually building the intelligence into the smart things themselves. We sometimes refer to this as mist computing because it’s even closer to the actual devices than fog computing. Typically, it’s intelligence built into those smart devices.

Notice that we could structure this in a very hierarchical fashion. If it’s time-sensitive information, we should be analyzing it as close to the source as possible. We could then use our fog nodes, things like gateways and network devices, that can aggregate the information taken from the actual smart things themselves.

Notice you might want to store information locally in your data center initially and then move it to the cloud for the ultimate storage and for more long-term things, like trend analysis and more detailed analysis. This might even include some machine learning.

So remember, fog computing is intelligence and processing that we’re going to do pretty close to the devices themselves. But edge computing would be an IoT reference, where we’re even closer to those devices. In fact, this is often implemented in the devices themselves, making them smart devices that are capable of computing and processing.

Thanks for reading!

Interested in more great information on this fascinating topic? Check out this article:

Do We Need To Replace The Cloud With Edge Computing?