Rancher Setup Basics

A client asked recently how SolidFire can integrate with Rancher.  I had a few RHEL servers available, so I'm going to set up Rancher on RHEL.  Here are the first steps:

Install a supported version of Docker (align compatibility for Docker, K8s, and Rancher): curl https://releases.rancher.com/install-docker/1.12.sh | sh

sudo service docker start

sudo docker run -d --restart=unless-stopped -p 8080:8080 rancher/server

Alright, let's pause here.  What did we just do?  First, we installed Docker.  Docker is the software that enables you to easily download, create, run, and manage containers.  Next we made sure the docker service was running.  Last we downloaded a container that will run the Rancher software.  At this point, you should be able to reach rancher's gui at :8080.

So let's get K8s and Trident up!  First we need a place to deploy K8s.  Click Infrastructure | Hosts.

Click add host.

And then save

Then enter the IP address of the server that will function as a host for containers.  Follow the instructions to copy-paste the command into a console on your new host server.

Done!

https://docs.rancher.com/rancher/v1.5/en/installing-rancher/installing-server/#single-container

Why Rancher: http://rancher.com/beyond-kubernetes/ 

Understanding SolidFire Capacity

To calculate the effective capacity available, follow this formula:

• Error Threshold (#3) minus Used Capacity (#1) = Available physical space
• In the example below, 86.24TB - 48.41TB = 37.83TB
• Multiply Redupe Ratio * Compression Ratio, then divide by 2 (for Double Helix)
• In the example below, (1.81 * 1.79)/2 = 1.62:1
• Multiply the results of (a) and (b)
• 37.83TB * 1.62 = 61.29TB

*This calculation assumes the current rate of dedupe and compression will continue
*This calculates capacity until the Error Threshold is reached, not the Total Capacity.

From ActiveIQ, our cloud monitoring tool:

1. Used Capacity.  This is the capacity physically taken up on disk by data.  After dedupe, compression, and double helix occur, this number is the end result.
2. Warning Threshold.  This is an adjustable alert threshold to alert that you’re approaching the Error Threshold.
3. Error Threshold.  This is the point after which the system cannot rebuild the second copy of data after a node loss.  This is calculated by subtracting one node’s physical block capacity from the Total Capacity.
4. Total Capacity.  This is the raw physical space on disk.  In this example, 1.92TB * 9 SSD’s * 5 nodes = 86.42TB.

From the SolidFire GUI:

      5. Block Remaining.  This is calculated subtracting the Used Capacity (#1) from Total Capacity (#4).

      6. Block Capacity until Warning.  This is calculated subtracting the Used Capacity (#1) from Warning Threshold (#2).

***Bonus***

       7. In ActiveIQ, under Reporting | Cluster Efficiency, hover over the graph to view the dedupe and compression ratios.  In this lab system, 1.81 * 1.79 = 3.24:1

Setting up PowerShell for SolidFire

A simple Guide to setting up PowerShell for SolidFire.

1. Enable PowerShell
2. Download SolidFire PowerShell toolkit 
3. Unzip the toolkit
4. Navigate to PowerShell-master\PowerShell-master\Install\ and run SolidFire_PowerShell_1_3_1_4-install.msi 
5. Done!

https://www.youtube.com/watch?v=nvnpzP4-T5I

Trident in Action

Some screenshots of NetApp's dynamic storage provisioner for K8s!  In this case, we're using OpenShift on SolidFire.

OpenShift, Trident, Docker, and SolidFire: Part 1

***This is part of an ongoing series I call "Mode 1 Storage Guy goes to a Mode 2 World."  I'm not an expert (yet), YMMV.***

We have a group of NetApp/SolidFire customers already live with OpenShift on SolidFire, which is very exciting but a bit scary too.  It's a bit scary because many of these clients went live without ever chatting with us!  This means they're running into issues like having to manually create hundreds of volumes, because they hadn't heard of our dynamic volume manager, Trident.

So we're partnering with RedHat to get a local OpenShift lab implementation tricked out with all the best SolidFire has to offer.  The goal is to get OpenShift running, then move on to containerized Elasticsearch and MongoDB and all sorts of other fun stuff.

Note: YOU DO NOT need NDVP in order to install/use Trident.  We do so here only for experience and demonstration purposes.

Here's the basic layout of the lab:  

1) 3 RHEL servers running as VMs in VMware (1 master, 2 other nodes)

2) NetApp Docker Volume Plugin installed

3) SolidFire for persistent storage (great API, all flash performance)

4) Trident for the automatic volume management

5) OpenShift Enterprise (instructions) as our container platform, installed on the RHEL servers.

6) OSE has several requirements, such as Docker as our container engine

The instructions for each of these are actually really good, so I'll just elaborate on a few things for this specific workflow.

• Start with the OSE requirements instructions.  You need to make sure you have the correct RHEL licensing to access the OSE repos or you'll hit a roadblock in a real hurry!
• Once you get to "Configuring Docker Storage" I recommend you detour over to the NDVP instructions, where you see "iSCSI RHEL/CentOS." 
• Complete those steps, then continue with the "Configuring Docker Storage" instructions and complete through the rest of the page.  I used option 1, presenting a LUN for docker to use as the storage pool.
• You can then install the NetApp Docker Volume Plugin (NDVP).  
• Note that this is where the storage expertise comes in.  You'll need to know the management and storage IP's for the SolidFire, you'll need to setup iSCSI on the RHEL servers, and you'll need to present targets from the SolidFire to your RHEL servers. 



Create an access group with all the IQNs.

• If you need help, I recommend this video.  You can find your iSCSI IQN with cat /etc/iscsi/initiatorname.iscsi and then create an access group on the solidfire for it:

• Don't forget to add the port (3260) to the iscsiadm discover command
• sudo iscsiadm -m discoverydb -t st -p 172.21.40.X:3260 --discover
• iscsiadm -m node -l to log into all available targets
• fdisk -l will show whether your mounts were successful and their device names
• Once your RHEL server has logged into each target, you're able to run netappdvp --config=/etc/netappdvp/solidfire-san.json &
• Don't forget the ampersand.  If you just run the command, it'll appear to hang but it's actually running.

NDVP Ready to Go!

And here we go, all three RHEL servers have the OSE prereqs and NDVP installed.  Here's our first NDVP-created volume!

Trident for Kubernetes

Last week NetApp dropped a huge development in the emerging tech market.  It’s called Project Trident, and it makes storage easier for Kubernetes.  Backstory: Kubernetes (also called k8s) started at google, it’s software that manages containers.  Basically you take a bunch of linux servers with Docker installed and tie them together with k8s, and it manages which container should live where.  If a container dies, k8s replaces it with a new one, that kind of thing.  You can think of k8s as Vmware for containers, except free and open source.

Most clients aren’t using basic k8s, but rather enterprise versions of it like RedHat OpenShift or Apprenda for reasons like security, support, and version management.  Trident is compatible with any version of k8s, which means it solves a big problem for RedHat.

Trident is similar to our vCenter plugin only even smoother: it allows k8s to ask a storage array for an NFS share or iSCSI LUN instantly, plus all sorts of LUN management abilities.  Better yet it’s free, open source, and storage vendor agnostic.

You can find information about it here: https://github.com/NetApp/trident and  http://netapp.io/2016/12/23/introducing-trident-dynamic-persistent-volume-provisioner-kubernetes/

SolidFire Architecture #1

 It's time I write a long-overdue overview of SolidFire: how it works, how it solves problems, and why service providers love it.  So here is Part 1!

First, SolidFire is not the solution to everything.  But it is the best in the world at what it does solve, which is why it won Gartner awards for the last two years.  Since this is an engineering blog, let's talk about how it works.

SolidFire hardware is regular servers with SSD's and no RAID, so you get commodity hardware prices and a truly software-defined architecture.  It protects data by writing it in two places using an algorithm we call Double Helix, and then earns space back with inline compression and global inline dedupe.  The global inline dedupe allows for much greater dedupe ratios than anything else on the market, because every block of data written is unique.  Other storage solutions have silos of dedupe, pools of blocks that are unique locally but duplicated many times throughout the environment.

The SolidFire robot

Today SF is iSCSI and FCP only.  When you create a LUN, SF chooses where in the cluster to place the data, removing the enormous complexity of we call the "placement question."  Let's spend some time on that: in most traditional storage environments, you have a couple of storage nodes that form capacity and performance silos.  When you scale out to 20 or 1000 nodes, your provisioning encounters a complex question: where do I place this data?  That spurs hours of performance and capacity analysis, trending and peaks vs average conversations.  On SF, the cluster does it for you.

It also solves the performance question that multi-tenancy brings by allowing you to provision performance.  Not just capacity, but performance!  SF does this by allowing you to set a minimum, maximum, and burst for each volume, guaranteeing a service level.

I've only scratched the surface on this one: we'll save the scale cluster model and more for the next blog post.

SolidFire and ONTAP

I had a reseller ask last week "Now that NetApp bought SolidFire, are they going to kill all-flash FAS?"  My answer: not on your life. 

NetApp has sold tens of thousands of all-flash FAS (AFF) systems, which run CDOT, our flagship operating system.  It's a great product that enormous enterprises (and governments) are spending a billion dollars a year on: there's no way we'd back down from continuing to invest in R&D there.  

Besides that, SolidFire has a completely different architecture than AFF.  One way to understand it is that AFF's architecture starts with smaller building blocks.  Here's what I mean:

1. AFF dedupes each volume individually: SolidFire dedupes the entire cluster.
2. AFF protects each disk using RAID: SolidFire protects each node using two copies of everything.
3. AFF puts QOS on each volume: SolidFire shows you whether your QOS promises exceed the cluster's ability.
4. AFF deals with node failure by having a redundant partner take over: SolidFire deals with node failure by having ALL the other nodes pick up the slack.

These are different architectures, which solve different needs.   I thought this was a great overview of SolidFire as well:
http://www.virtualtothecore.com/en/solidfire-a-quality-storage/

SolidFire

SolidFire is a "make private cloud easy" solution primarily designed for service providers.  It's a "born in OpenStack" all-flash whitebox solution that aims to be stupid-easy to deploy and manage.

The goal for SolidFire is not to be the fastest, the most resilient, or the most features.  It aims to answer one question, best in class: "How do I easily deploy Storage as a Service?"  You can see this in their design choices:

1. Because this is a product service providers sell, they're flash only, have required QOS policies, and skip all the management tools, leaving that to OpenStack.
2. Because they use two copies of everything instead of RAID, they achieve node level resiliency and skip expensive hardware and software, using inline dedupe/compression to recover the space delta.  This also spreads performance requirements across the entire cluster.
3. Because they expect you'll be deploying a single configuration thousands of times, they support only 1 protocol and have very limited configuration options.
4. Because this is for a cloud, not a single-purpose, the cluster (up to 100 nodes) auto-grows when you add a new node and recovers quickly when you lose one.

A few technical details:

• Platform today is Dell servers.  Now that Dell owns EMC, it'll probably convert to Cisco.
• 10 drives per node
• SF2405: 5-10TB and 50k IOPS
• SF4805: 10-20TB and 50k IOPS
• SF9605: 20-40TB and 50k IOPS
• SF9010:  20-40TB and 75k IOPS
• Features:
• Inline dedupe and compression
• For QOS you can set min, max, and burst limits.
• Mix any node platform
• You can hot remove nodes
• iSCSI, FCP (with a gateway device)
• native snapshot capability and can backup to any Amazon Web Services S3 or OpenStack SWIFT-compatible API. 
• Under the hood:
• Nodes are connected via 10GbE over your shared network.  Not a private intracluster network.
• “All connections for a particular LUN presented to storage go back to the primary node for that LUN. IE: multipath doesn't help you weather a failover. They're dependent on long iSCSI timeouts to give them time to fail a node and redirect traffic.”
• Performance and QOS: http://www.solidfire.com/resources/provision-control-and-change-storage-performance-on-the-fly
• Node Loss Demo: http://www.solidfire.com/resources/demonstration-of-solidfires-automated-self-healing-ha

SolidFire wins Gold in the Storage magazine/SearchStorage.com 2015 products of the Year Storage Systems: All-Flash Systems category.  http://searchsolidstatestorage.techtarget.com/feature/SolidFire-SF9605