Tactical Data Centres

Tactical data centers have unique characteristics that other ROBO and edge environments do not. They need to be deployed quickly, have a small footprint, be mobile, maintain data security if they are compromised physically, be resilient to physical damage and to the elements, and be battery backed. They also need to adhere to the strict security standards that are required by federal government and law enforcement agencies.

First let’s look at some use cases, then we’ll dig into the technology required.

1) Rapid Emergency Response / Disaster Relief

When natural disasters occur, such as hurricanes, forest fires and flooding, regular communication channels and systems are ineffective. Emergency personnel need reliable real-time voice and data communications systems. These are provided by base stations that connect to localized teams, and backhaul networks, providing the required services and connectivity to save lives and rebuild infrastructure.

2) Mobile and short-lived deployments

Mobile & Modular datacenters for short lived deployments need to be able to be stood up and started up very quickly, provide applications and services immediately, be resilient to component failure and environmental situations. These get moved around a lot, jostled and battered. They cannot afford a services outage just because a server has components or connections shaken loose.

3) Field office / Forward Operating Base (FOB)

When operations and missions require a longer term (but possible mobile) base, an FOB will be setup. These will have applications and services that are centrally managed, updated and deployed. There may also be data replication from FOBs to regional datacenters in Main Operating Bases (MOBs). The datacenter could be in a permanent structure with racks, but most likely a smaller than normal footprint.

4) In-theatre tactical environments

In-theatre tactical environments have a lot of similarities to Mobile and Short-lived deployments. However, they may also have GTFO (Get The **** Out) operational procedures. Those might include taking data with you, or erasing local systems. These systems may be in command posts or in vehicles. 

With command posts, mobility is normally not immediate and rather done in several phases. First, troops would start with tent infrastructure, then generators and UPS units. Then local network switching, server, and storage infrastructure would go up. Next would be satellite and other RF links, followed by the running of cables to provide the local area network in the command post.

There has also been a shift from relying on dedicated proprietary data communications systems to ruggedized COTS (commercial of the shelf) systems that adhere to the security specifications required. This has changed the landscape of communications methods for classified. The old method was:

In an FOB, use a locally wired LAN connected to another LAN via point to point RF, or secure satellite link. This meant that no WiFI, or cellular/LTE communications could be used for classified data.

In the new method, validated COTS hardware is used with layers of encryption in the hardware, network and at the application level. This increases the capability for situational awareness with sensor data, and mobile communications. It also increases network availability by leveraging alternative network paths and not have a single point of failure.

A good example of this is in the United States, where the NSA has established a program called Commercial Solutions for Classified.

The ultimate goal for in-theatre tactical environments is to be secure, quick, agile and with a high level of communication performance and availability. I’ll go deeper into tactical network architecture in another blog post when I discuss C4/C5/C6ISR. Here is a quick link that has a good overview. Basically, it is an acronym that encompasses the technological capabilities of a platoon, company, division, etc.

C2 is Command and Control

C3 is Command and Control, and Communications

C4 is Command and Control, Communications, and Computers

C5 is Command and Control, Communications, Computers, and Cyber Defense

C6 is Command and Control, Communications, Computers, Cyber Defense and Combat Systems

ISR is Intelligence, Surveillance, and Reconnaissance 

Most modernized militaries have some aspect of C4ISR / CS5ISR in theatre and can be achieved with a tactical datacenter. C6ISR is reserved for integrated Naval weapons systems like AEGIS.

---

Now lets look at what the technology looks like.

Nutanix has partnerships with a number of hardware vendors that operate in this space. Nutanix provides the software and the partner vendor provides the hardware. In the TDC space, a few partners stand out, KLAS, Crystal and HPE.

I would do a disservice if I only mentioned the hyperconverged infrastructure in the solutions, because to make it work there is always a networking component. There also may be other supporting systems that need integration and connectivity. So lets first look at what a logical diagram for the entire network topology may look like.

There are systems in place to get data from sensors. This data could be for surveillance, or for EMF radiation signatures, or a myriad of other things. The data can then be analyzed using an inference engine and provide immediate actionable information. That inference engine can operate within the TDC.

There are physical connections to each of the networks available to a site, but there are also management platforms and controllers for the connections. For instance, a platform used for managing the mesh networking and data synchronization of tactical radio endpoints could run on the TDC. Or cellular base-station software could run in a VM on the TDC, or a virtual routing platform to connect radio, cellular, satellite and point to point microwave links. 

In the diagram I show 3 x TDCs and a main operating base. Some TDCs can communicate directly via point to point links, while others need to route through other TDCs. This allows for the replication and distribution of data and uplinks that can provide alternative routes if some forms of communication are compromised. As vehicles or troops are mobile, they can use their coms devices to access any of the available networks as a client, then route to wherever as needed, automatically. 

It may seem complicated, but its really not, nor should it be. In the following diagram, I highlight the import part of this architecture, as it relates to the Nutanix TDC.

In these TDCs you have your HCI infrastructure and the local switching to connect them. The local networking may included firewalls, routers and other WAN connectivity and isolation devices. However, those are out of the scope of what I show with the following architectures. Some networking devices can actually run as software appliances within the TDC, further reducing 3rd party hardware requirements.

KLAS Voyager2 and the HPE DX8000 come with networking built into them, while the Crystal Servers do not. There are benefits and drawbacks to each approach. With Crystal, it is assumed that you will utilize your own pre-existing switching, so nothing is provided. With the other 2, the networking has a very small profile and does not hinder the setup, rack mounting, or overall space.

---

KLAS has the Voyager Tactical Data Center solution.

Overview of the KLAS Voyager TDC

 Voyager 8 case and chassis with built-in UPS and AC/DC charge options

• 4x TDC Blades each with
  • Xeon D CPU with 128GB RAM
  • NVMe storage for caching
  • 4x 2.5″ SATA SSDs
  • VIK for easy configuration changes
• Voyager TDC Switch with
  • 12x 10Gbits/s port with copper and fiber options
  • 121 Gbps backplane for line-speed processing on all ports simultaneously
  • 40 Gbps trunk for interconnection with 3rd party switches
  • Inter-VLAN routing in hardware at line rate
  • 1x 40 Gbps QSFP+ port for high-speed uplink. Can also operate as 4 x 10 Gbps SFP+ ports using included breakout cable
  • Port mirroring, IPFix
  • Ansible playbook management supported
  • Voyager Ignition Key (VIK) for configuration and storage
• Validated with Nutanix AOS on VMware ESXi and Nutanix AHV
• Can be removed from travel case and mounted in a regular 2, or 4 post rack

The KLAS Voyager system is very modular and the TDC is not the only solution they offer. You can mount routers, radios, and a whole host of other devices in the Voyager 8 series chassis. Also, the chassis depth is very short because of the orientation of the nodes and switching. This makes it light and very portable.

All hardware maintenance is done from the front of the chassis, including node/switch/cabling, etc. The chassis can also be removed from the protective hard-case to be mounted in a rack.

---

Crystal Group has a whole range of ruggedized servers and switches. 

The form factor used for Nutanix is the 2U rugged Carbon Fibre server.

The footprint is not going to be as small as the KLAS or HPE solution, but these things are indestructible. From the Crystal Group site:

“…withstands harsh environmental conditions, including shock and vibration, temperature extremes, sand/dust, sea spray/salt fog, and more.”

Stronger and lighter than their steel chassis counterparts, they minimize SWaP (Size, Weight and Power), while maximizing performance. A minimum rack RU height  for a scalable cluster would be 7RU with 3 x nodes and 1 x switch. However, if you wanted to minimize size, it would be possible to only use 3RU with a single node cluster and a single switch.

The switching used is a ruggedized version of a Brocade ICX switch.

If you wanted to have a completely self contained environment that can be maintained locally with no other hardware, like a laptop, then it may make sense to add a KVM to this. Crystal provides a 1RU 8-port KVM that fits the bill.

Space will be required for maintenance of cabling, because all cabling and power connectivity is in the rear. Drive removals are done in the front, which is normal. However, in regular operation these nodes would not need any maintenance done for 10 years on average. So the maintenance issue is not a real concern.

Crystal Group Solution overview

Crystal Edge Networking

---

HPE has the DX8000 

The DX8000 series is essentially the same as the EdgeLine 8000 (EL8000), but specifically designed to run Nutanix AOS.

Here is the solution brief.

There are some specific things that I like about the DX8000, which I think are unique. With the PCI riser cards in each node, you can add network adapters to connect to external switching, or add GPUs for add processing capabilities. If you want to keep things a bit more compact, you can add internal unmanaged switches to the chassis. This will then use internal traces from the nodes (you will need internal network adapters) to the switch cards (as shown above). The switches will then uplink to another switch for greater connectivity. I don’t think you can make a VPC with those uplinks, as they are pretty basic. So they would essentially be a single uplink from each internal switch.

Another interesting thing with the DX8000, is that the widths is pretty small, so you could have two of these units side by side and not use any more rack units. That would give you 8 x nodes in 5RU, which is pretty dense. For non rack environments, the DX8000 can be bolted into a vehicle, or moved around fairly easily.

MEC or Multi-access Edge Computing

MEC is a continuation of the idea of Edge. It was originally referred to as Mobile Edge Computing, but has since been renamed to Multi-access Edge Computing. The main idea is that some data is processed locally and some data is passed to the cloud for processing. You have some devices that generate data, which then gets put in data pipelines and then applications follow business logic based on the data.

There are “System level”, “Host level”, and “Network level” components. Another way of looking at them is management, cluster/host, and network components. 

The system provides overarching management of the applications and is centrally controlled. This allows for the MEC applications to be deployed and treated as functions for data streams. The location of a host or cluster would be considered a “Service Domain”. The  network would be a combination of local and remote elements. Locally, data streams have aggregation and can then be processed by the functions in the local service domain, or they can be forwarded to another service domain to be processed. Those other service domains can be in another datacenter, or in the cloud.

The MEC applications might employ some level of AI for inferencing and thus use the real-time data collected and apply a function on it. The models that the inferencing engines use are trained with a lot of data. So the datapipe could continue to another service domain which would have the Machine Learning analytics capabilities for continuous training and improvement of the models. As those models get updated, they would then update the inferencing engines. 

Here is an example of this MEC architecture in use in a manufacturing context. Sensor data from PLC controllers, SCADA, etc., are collected. The data is monitored in real-time and custom dashboards are presented locally. Based on the defined business logic, there may be alternate machine / controller profiles that need to be loaded if there are variances in the sensor data. For example an increase in temperature may cause manufacturing process failures, unless they are accounted for or addressed. The inferencing engine could do this automatically, or provide indication on a dashboard suggesting preventative maintenance to avoid impact in the future. The output from the inferencing engines as well as the raw data can roll up to another service domain for longer retention, analysis and global management of multiple edge sites.

---

So how does Nutanix do this? 

Well there are always a number of ways and components involved, but the simplest answer is Nutanix Karbon Platform Services, or KPS.

KPS provides a simple management plane (provided via SaaS), that you specify your service domains, data sources, functions, business logic and machine learning. It works across different clouds, on-prem, with virtual machines, kubernetes / containers, and even baremetal. Its the glue for complex application architectures, both cloud native and traditional.

Some neat aspects of KPS:

• KPS can provide management of Kubernetes clusters running in Nutanix Karbon, AWS, Azure, GCP and others.
• GPUs are supported for inferencing at the edge.
• A Terraform provider is available to automate the deployment of a KPS service domain in the public cloud.
• KPS can manage service domains running on non-Nutanix VMware ESXi hosts

Here is a graphic that provides a high-level overview.

---

If you want to dive a bit deeper into KPS, have a look at these articles and links:

• KPS Solution Brief
• Blog – Introducing KPS
• Blog – KPS Overview
• Blog – From there to here, from here to there, Containers are everywhere!
• Blog – Ingress and Load Balancing in Karbon Platform Services
• Blog – Data Interfaces on Nutanix Karbon Platform Services
• Tutorial – Deploy a Stateful MySQL Application on Karbon Platform Services
• Tutorial – Deploy a Kubernetes Application on Karbon Platform Services
• Product page – https://www.nutanix.com/products/karbon/platform-services

SIZING

When you are looking at sizing an environment there are several factors that need to be addressed and questions that should be considered:

1) What are the workloads that will run on the environment?

2) What does “fit for use” look like in terms of metrics (availability, manageability, performance, recoverability, security)?

3) What are the priorities if trade-offs need to be considered (ie; fast, good, cheap, etc.)?

4) Create a requirement rubric that can have weight against a solution.

5) Identify requirements that are “must-have”, vs “nice-to-have”.

6) If this is an existing workload, get historical consumption and performance data for the workload and its existing infrastructure.

7) If this is a new workload, model based on recommended practices for that type of workload

8) Determine the constraints for a solution (power, space, cooling, physical access, etc.).

9) Determine the hardware vendors being considered and compare their portfolios of viable solutions.

10) Determine the budget for this initiative and evaluate against solutions with a TCO (Total Cost of Ownership).

This is not a comprehensive list, but serves as a starting ground for discussions. All too often people will just look at source hardware specs and utilization, then try to replicate that in a final solution, with a little space for growth. Although this may work for a quick and dirty estimate of what a solution may be, it might miss the finer requirement points and provide a functional but non-optimal solution.

With ROBO environments this can make a big difference because often they are replicated based on a certain configuration, or template. If that design is non-optimal, then the deficiency is multiplied by the number of sites.

Some key points to address:

• What does the network look like and what is the available port type, count and bandwidth?
• What do the traffic patterns look like? North-south? East-west? Traffic types? Network load?
• How is the network logically segmented? 
• What method is used to secure the environment? Network zone ACLs? Layer 3/7?
• Is there value in microsegmentation for the workload?
• Is the workload mobile, or does it need to have the ability to migrate automatically or manually?
• Does the workload need to have a backup, BC/DR plan?
• Is there currently a BC/DR plan in place? Does it meet the application owner requirements?
• Can the BC/DR plan be improved? Would it cost more, or less? Can management complexity be reduced?
• Is there application level data replication? Are there any infrastructure native alternatives that may be more beneficial for cost, performance, or manageability?
• How resilient does the platform need to be? How many simultaneous, and serial failures for components does it need to protect against?
• Does the platform need to be centrally managed?
• Would there be benefit for deployment automation?

With ROBO environments the most common constraints are cost, manageability, and lifecycle management. An organization may have a set budget that they need to design against, which will limit options right out of the gate. This is where we can start looking at the trade-offs of designing against that budget and see if it is able to provide an optimal fit-for-use solution. If budget was increased, would other options that are more in line with the requirements be available?

To size based against the most common constraints, lets dig into them a bit:

Cost

There are hardware costs, software costs, operational costs, and provisioning costs.

• Hardware will come from your vendor of choice. Its all x86 anyway, so the differences often come down to non-technical aspects like client relationships, procurement vehicles, capex costs for comparable hardware, and vendor support.
• Software costs cover the workload applications, hypervisor, guest OS, and infrastructure components.
• Operational costs can be calculated by the number of individuals supporting the solution, multiplied by the number of hours used for management, multiplied by the staff resource cost per hour.
• Provisioning costs are the operational costs required to stand up a new environment. Sometimes the operational staff resources will be different than the provisioning staff resources, so cost per hour may change.

Manageability

Some management solutions can manage multiple sites with no additional cost, while others will charge you for that capability. In a ROBO environment, it is good to understand this. Also where the management plane resides is important. A centralized management plane may be an issue if there is no site access. Local management capabilities may also be required.

Lifecycle Management

This includes updates, patches, expanding the environment, and removing end-of-life hardware. The expense for this is usually attributed to operational expense if it is a manual process. Also there may be limited time available for this because of staff being over-worked. This results in fewer updates, lower performance and higher risks of hitting software vulnerabilities or bugs. If it is automated, is there a cost for the platform that does this?

Some Nutanix Solutions that work very well in ROBO environments.

Prism Central

Centralized management for multiple clusters / sites.

Prism Pro

License tier on Prism Central that allows for playbook automation for operations, capacity planning, reporting analytics and VM right sizing. This will tell you when you are running out of resources, any issues on any sites and create automated actions for remediation. Essentially a self-driving datacenter model for all your sites.

Nutanix Flow

This allows for microsegmentation, environment isolation on layer 2, layer3 firewalling, ID based security policies with Active Directory integration, overlay networking, IPSEC VPN, NAT capability and VPC constructs.

Nutanix Files

This allows scale-out file sharing for SMB and NFS. Gets rid of CIFS silos, Windows file shares that need constant patching and downtime, the associated security risks, and single point of failure. All Nutanix software tiers come with 1TB free files licenses.

Protection Domains

Perform async and near-sync replication to another site, with RPOs as low as 20 seconds.

Nutanix On-Prem Leap

Perform orchestrated DR with the ability to perform start-up order prioritization, and IP re-addressing.

Foundation Central

This provides the ability to deploy and configure sites via automation from a central location, without the need for an onsite resource (except for racking and cabling).

Here are some resources to help with sizing Nutanix for ROBO environments:

Deploy and Operate ROBO on Nutanix

Nutanix ROBO solution page

Nutanix Design Guide (See chapter 16, by Greg White)

Nutanix Sizer

December 16, 2020|Design, ROBO

LICENSING

This article is not only about Nutanix licensing, but also software licensing in general. A general rule with software licensing is that customers want to get as much functionality as possible to meet their requirements, and pay as little as possible. Software vendors would like to make as much money of their customers as possible, while still providing value. Some models for licensing are:

One price, perpetual version license.

You buy it once and you own that version with updates, forever. You buy version 1.0 of a software and have access to all updates of the 1.x series. However, you will need to rebuy the software at version 2.0 to get new features.

Multiple feature tier prices, perpetual version license.

You buy it once and you own that version and tier with updates, forever. Feature sets may be labeled like bronze, silver, gold, or standard, advanced, enterprise, etc. If you buy version 1.0 bronze, you can pay the difference to go to 1.0 silver / gold. However if you want 2.0 silver, you need to rebuy the whole thing from scratch. 

All features, All you can eat, perpetual version license.

This license let you use the software as much as you want and make use of all the available features. This may be referred to as an ELA (Enterprise Licensing Agreement).

 In some cases, you may get a post-paid bill depending on which of the features you use and the quantity of deployed instances. This is called a true-up

The above licensing models are conducive to capex purchases that are performed every few years, depending on the software release cycle. As long as the software meets the demand of the user and updates are provided then there is little incentive to purchase a new version, unless additional features warrant the expense. One way for software vendors to increase sales for customers that do not want to buy the new version, is to sell support for a term. For instance if version 1.x is out and so is 2.x, then perhaps the customer does not want to buy 2.0 yet. So they will pay the software vendor a percentage of the purchase price to receive technical support and software updates for the 1.x series until it is end of life. This ends up being cheaper than a purchase of the 2.0 version, but only delays the capex expense. In the interim, the software vendor gets residual revenue, which is known as the “long tail”.

Another software licensing model is called subscription based licensing. There are a few different versions of this, but the two I will discuss are restrictive and non-restrictive. These aren’t necessarily the exact terms, but they convey the idea.

Restrictive subscription licensing

When the license term expires, all software functionality stops. Think of 30-day trial software, then extend that for longer terms.

Non-restrictive subscription licensing.

When the license term expires, all features and functions remain, but updates are no longer provided. Some software has separate support and subscription costs, so you may have one expire and the other one not. For instance, if your support expires, but not your subscription, then you can keep getting updates but no help with any issues. If your subscription expires, but not your support, then you cannot update your software, but you can get assistance on issues from the software vendor. They may tell you that you “need to update”, which would be code for “renew your subscription”. 

Nutanix licensing

Alright now that you have a bit of a foundation in a non-exhaustive list of comparative software licensing models, I’ll describe how Nutanix does licensing and support.

Nutanix offers tiered non-restrictive subscription licensing with integrated support. So there is just one price for licensing and support for a period of time. You can get licensing for 1-5 year terms, but will get the best bang for your buck on a 1-3-year contract. After your term is up, you can still use the software, but you can’t get updates or create support tickets. Renew your subscription and you get the latest version, updates and support again. 

As long as you have an active subscription, you can update to the latest version.

Now we look at the software tiers and how this all relates to ROBO environments.

Core AOS provides hyperconverged functionality and management with Prism. The tiers for AOS are Starter, Pro, and Ultimate. See here for a functionality comparison.

https://www.nutanix.com/products/software-options

There are also tiers for Prism (also called Starter, Pro, Ultimate). Prism Starter comes at no additional cost to all AOS versions. It allows for multi-cluster management and health monitoring and troubleshooting. Prism Pro adds operational insights, planning and automation. Prism Ultimate adds service level insights for applications, cost metering and chargeback.

License metering

The cost of license depends on how it is metered. Nutanix has a few ways to do this, even though the license tiers may be the same. 

• Capacity Based Licensing (CBL) will look at the total cluster capacity of SSD (in TiB) and the total core count. For example, lets look at a 3-node cluster with the following individual node specs.

2 x 12-core CPUs (24 cores per node)

2 x 1.92TB SSDs (3.84TB or 3.49TiB – https://www.gbmb.org/tb-to-tib )

So the licensing cost for the 3-node cluster would be 11TiB SSD and 72 cores.

• Per VM licensing, which is sometimes referred to as ROBO licensing, is a defined cost based on the number of VMs on the cluster. The amount of resources is not measured. This works well in situations where you required only a few VMs and want to give them the maximum resources possible.  One limitation of this is that you are only allowed a maximum of 32GB of RAM per VM. This limitation stops things like massive databases running on that licensing.

• VDI core licensing will use concurrent users as a measure of metering. This allows for a linear cost based on users and not infrastructure resources. Another benefit is that you can have license mobility between sites, depending on where your users are. A 2-site architecture with 200 concurrent users and active / passive failover, can have 200 x VDI core licenses at site 1 and 1 x VDI core license at site 2. In the process of a DR event, you would then reallocate 199 licenses from site 1 to site 2. This allows a very cost effective licensing for DR capability of VDI environments. VDI core could be applied to Citrix, VMware Horizon, Nutanix Frame, or any other VDI solution.

Here is a link to the Nutanix Licensing Guide

NODE TYPES

In the Nutanix world, there are several main node types:

 1) Hyperconverged (HC)

These are your standard nodes that provide a combination of storage and compute. In this node classification, you also have a sub-classification:

• Light Compute. – This is usually lower end processors and was historically used for older Storage-Only nodes, like the NX-6035C G5. You don’t see these anymore.
• Single CPU – This is used in very small environments that need to keep costs, power, and core licensing down. An example of this is the NX-1175S-G7, or the NX-1120S. The “S” designation on the model indicates a single CPU.
• Entry level- Lower end dual CPU, but only a single SSD and limited memory scalability. These reduce core and SSD costs to a near minimum. An SSD failure will be seen as a CVM failure because there is no redundancy. An example is the NX-1065-G7.
•  Multi-node blocks- These cram as many nodes as possible into a small form factor. You get 4-nodes in 2U with something like the NX-3065-G7, or 2 nodes in 2U with the NX-8035-G7.
• Slim profile blocks – These 1U servers have the same node density as the 8035 nodes, but you have physical block separation. An example of this is the NX-3170-G7
• GPU nodes – These nodes have physical space and slots for GPU cards. An example of this is the NX-3155-G7

2) Storage Nodes (SN) 

Any node can be configured as a storage node. The main difference will be that of memory and CPU resources which will be reduced because only the CVM has to run on the node.

There are more node types for other workloads, and a full list of current node types from Nutanix and OEM vendors, can be viewed here. https://www.nutanix.com/products/hardware-platforms/specsheet

I am only focusing on the node types that are most often seen in ROBO environments. Therefore Storage Heavy, Compute Heavy, and Compute Only will not be discussed.

I’ve given examples for each node type for ROBO in NX hardware. The same, or equivalent can also be obtained from other hardware vendors. See the dynamic spec sheet above to find the OEM nodes that best fit your use case.

Some key node models that should be looked at from the OEMs are:

HPE DX 8000 

This ruggedized 5U 4-node block is fairly small and can be affixed to a vehicle or other tactical or edge environment.

HPE ProLiant DX8000 5U Front Cabling Chassis View

Description

1. 1U Blank

2. ProLiant DX910 1U Server Blade

3. Chassis Manager

4. HPE ProLiant DX8000 1500W (AC/DC) Power Supplies

DX 8000 Specs Here:

KLAS Voyager 2 TDC

These nodes are ruggedized, small, come with their own switching and can be fit in an airline carry-on compartment. If they were to be installed in a rack, it would be 5U and short depth.

Voyager 2 TDC specs here

Lenovo HX 1021 

This node is 1U half width, so you can put 2 nodes in 1RU. A very small form factor indeed. This is great for maximizing space with a limited number of nodes.

HX 1021 Specs here:

Nutanix NX-1120S

Not an OEM node, but a recent addition to the Nutanix NX line-up, and worth mentioning. This tiny node is 1U, less than 1′ deep and only uses about 120W. That’s the same power draw as running a bright incandescent light bulb. 

NX-1120S Specs here.

---

USE CASES

ROBO can mean a lot of different things to people, depending on the use case. So I’m going to list some of those use cases and drill into them so that we can better understand how to design for them.

1) Remote Office Branch Office

This is the literal interpretation of ROBO, where a small amount of infrastructure is required for local workloads and a larger datacenter infrastructure is located somewhere else.

2) SMB

Small and Medium Business. This is a small infrastructure that may act as the only datacenter for a company. Costs and management overhead are primary factors. Some SMBs may have multiple sites, and require some datacenter-like functionality.

3) DR site

A DR site may require the capabilities of running all workloads from another site, or run a subset of them, or possibly just act as a replication target.

4) Pop-up site (Edge)

On-demand, or pop-up sites need to be provisioned and deployed in a very short period of time, then torn down just as quickly. There is no room for config or operational error and the entire process must be streamlined.

5) Mobile (Edge)

This means physical mobile. Terrestrial vehicle, aircraft, watercraft, spacecraft. These require physically hardened systems resistant to shock, vibrate, temperature extremes, pressure, fire, water, and physical damage.

6) Industrial (Edge)

Hardened, resilient systems that need extremely high availability. These are often parts of critical systems and have no room for loss of availability. An example are SCADA control and monitoring systems.

7) IoT (Edge)

Internet of Things device management, data analysis and processing. Run applications to interpret data closure to the edge for quicker response times or higher security, than sending data to the cloud.

8) Tactical (Edge)

These are meant for rapid deployment and centralized management. They provide operational services for military, government and emergency services. They need to be easily deployable, replicate data, ensure encryption and can be disposed of in short order if required.

9) Small datacenter

This may be a small quantity of nodes, thus it fits the ROBO ideal, but it has tier 1 workloads. These could be databases, Artificial Intelligence GPU backed workloads, etc.

10) Dev / Test / Lab

Also not entirely ROBO, it will often start small to replicate a production workload. Because of its often small initial footprint, it is being added to this category.

In the next post we will look at node types from Nutanix and various OEMs to see what hardware can be used for these use cases.