First Container Solution – Partha Seetala, CTO, Robin Systems | DataWorks Summit 2018 The CUBE Video

Robin Hyper-Converged Kubernetes Platform announced as the First and Only Container Solution certified to run Hortonworks Data Platform (HDP)

Robin Hyper-Converged Kubernetes Platform – the First Container Solution certified to run Hortonworks Data Platform (HDP)

Robin Hyper-Converged Kubernetes Platform – the First Container Solution certified to run Hortonworks Data Platform (HDP)

On day two at Dataworks Summit 2018, Rebecca Knight and Jame Kobielus spoke with Partha Seetala, Chief Technology Officer (CTO), Robin Systems at theCUBE to discuss the first container solution certified to run Hortonworks Data Platform (HDP).

Tell us about Robin Systems

Robin Systems, a venture-backed company is headquartered in San Jose in the Silicon Valley. The focus is in allowing applications, such as big data, databases, NoSQL, and AI ML, to run within the Kubernetes platform. What we have built (the first container solution certified to run HDP) is a product that converges storage, complex storage, networking, application workflow management, along with Kubernetes to create a one-click experience where users can get managed services kind of feel when they’re deploying these applications. They can also do one click lifecycle management on these apps. Our thesis has initially been to actually look at it from the applications down and then say, “Let the applications drive the underlying infrastructure to meet the user’s requirements.”, instead of looking at this problem from an infrastructure up into the application.

Is this the differentiating factor for Robin Systems?

Yes, it is because most of the folks out there today are looking at is as if it’s a component-based play, it’s like they want to bring storage to Kubernetes or networking to Kubernetes but the challenges are not really around storage and networking.

If you talk to the operations folk they say that “You know what? Those are underlying problems but my challenge is more along the lines of when my CIO says the initiative is to make my applications mobile. The management wants to go across to different Clouds. That’s my challenge.” The line of business user says “I want to get a managed source experience.” Yes, storage is the thing that you want to manage underneath, but I want to go and click and create my, let’s say, an Oracle database or distributions log.

In terms of the developer experience here, from the application down, give us a sense for how Robin Systems tooling your product in a certain way enables that degree of specification of the application logic that will then get containerized within?

Absolutely, like I said, we want applications to drive the infrastructure. What it means is that Robin is a software platform – the first container solution certified by Hortonworks to run HDP. We layer ourselves on top of the machines that we sit on – whether it is bare metal machines on premises, on VMs, or even an Azure, Google Cloud as well as AWs. Then we make the underlying compute, storage, network resources almost invisible. We treat it as a pool of resources. Now once you have this pool of resources, they can be attached to the applications that are being deployed as can (3:10) inside containers. I mean, it’s a software plane installed on machines. Once it’s installed, the experience now moves away from infrastructure into applications. You log in, you can see a portal, you have a lot of applications in that portal. We ship support for about 25 applications.

So are these templates that the developer can then customize to their specific requirements? Or no?

Yes. Absolutely, we ship reference templates for pretty much a wide variety of the most popular big data, NoSQL, database, AI ML applications today. But again, as I said, it’s a reference implementation. Typically, customers take the reference recommendation and they enhance it or they use that to onboard their custom apps, for example, or the apps that we don’t ship out of the box.

So it’s a very open, extensible platform – but the goal is that whatever the application might be, in fact, we keep saying that, if it runs somewhere else, it’s running on Robin. So the idea here is that you can bring any app or database, and with the flip of a switch, you can make it a 1-click deploy, 1-click manage, one-click mobile across Clouds.

You keep mentioning this one click and this idea of it being so easy, so convenient, so seamless. Is that what you say is the biggest concern of your customers? Are this ease and speed? Or what are some other things that are on their minds that you want to deliver?

So one click, of course, is a user experience part – but what is the real challenge? The real challenges are –  there are a wide variety of tools being used by enterprises today. Even the data analytic pipeline, there’s a lot across the data store, processor pipeline. Users don’t want to deal with setting it up and keeping it up and running. They don’t want the management but they want to get the job done. Now when you only get the job done, you really want to hide the underlying details of those platforms and the best way to convey that, the best way to give that experience is to make it a single click experience from the UI. So I keep calling it all one click because that is the experience that you get to hide the underlying complexity for these apps with the First Container Solution certified to run HDP.

Does your environment actually compile executable code based on that one click experience? Or where do the compilation and containerization actually happen in your distributed architecture?

Alright, so, I think the simplest to explain like this – You work on all the three big public clouds. Whether it is Azure, AWS or Google. Your entire application is containerized itself for deployment into these Clouds. So the idea here is let’s simplify it significantly. You have Kubernetes today, it can run anywhere, on premises, in the public Cloud and so on. Kubernetes is a great platform for orchestrating containers but it is largely inaccessible to a certain class of data-centric applications. Robin makes that possible.

But the Robin take is, just onboarding those applications on Kubernetes does not solve your CXO or your line of business user’s problems. You ought to manage the environment from an application point of view, not from a container management point of view. From an application point of view, management is a lot easier and that is where we create this one-click experience.

Give us a sense for how we’re here at DataWorks and it’s the Hortonworks show. Discuss with us your partnership with Hortonworks and you know, we’ve heard the announcement of HDP 3.0 and containerization support. Just give us a rough sense for how you align or partner with Hortonworks in this area.

Absolutely. It’s kind of interesting because Hortonworks is a data management platform, if you think about it from that point of view and when we engaged with them first – So some of our customers have been using the product, Hortonworks, on top of Robin, so orchestrating Hortonworks, making it a lot easier to use. One of the requirements was, “Are you certified with Hortonworks?” And the challenge that Hortonworks also had is they had never certified a container based deployment of Hortonworks before. They actually were very skeptical, you know, “You guys are saying all these things. Can you actually containerize and run Hortonworks?”

So we worked with Hortonworks and we are, I mean if you go to the Hortonworks website, you’ll see that we are the first in the entire industry who have been certified as a container based play that can actually deploy and manage Hortonworks. They have certified us by running a wide variety of tests, which they call the Q80 Test Suite, and when we got certified the only other players in the market that got that stamp of approval was Microsoft in Azure and EMC with Isilon.

So you’re in good company?

I think we are in great company.

Are you certified to work with HDP 3.0 or the prior version or both?

When we got certified we were still in the 2.X version of Hortonworks, HDP 3.0 is a more relatively newer version. But our plan is that we want to continue working with Hortonworks to get certified as they release the program and also help them because HDP 3.0 also has some container based orchestration and deployment. So we want to help them provide the underlying infrastructure so that it becomes easier for users to spin up more containers.

The higher level security and governance and all these things you’re describing, they have to be over the Kubernetes layer. Hortonworks supports it in their data plane services portfolio. Does Robin Systems solutions portfolio tap into any of that, or do you provide your own layer of sort of security and metadata management so forth?

We don’t want to take away the security model that the application itself provides because the user might have step it up so that they are doing governance, it’s not just logging in and auto control and things like this. Some governance is built into. We don’t want to change that. We want to keep the same experience and the same workflow hat customers have so we just integrate with whatever security that the application has. We, of course, provide security in terms of isolating these different apps that are running on the Robin platform where the security or the access into the application itself is left to the apps themselves. When I say apps, I’m talking about Hortonworks or any other databases.

Moving forward, as you think about ways you’re going to augment and enhance and alter the Robin platform, what are some of the biggest trends that are driving your decision making around that in the sense of, as we know that companies are living with this deluge of data, how are you helping them manage it better?

I think there are a few trends that we are closely watching. One is around Cloud mobility. CIOs want their applications along with their data to be available where their end users are. It’s almost like follow the sun model, where you might have generated the data in one Cloud and at a different time, different time zone, you’ll basically want to keep the app as well as the data moving. So we are following that very closely. How we can enable the mobility of data and apps a lot easier in that world.

The other one is around the general AI ML workflow. One of the challenges there, of course, you have great apps like TensorFlow or Theano or Caffe, these are very good AI ML toolkits but one of the challenges that people face, is they are buying this very expensive, let’s say NVIDIA DGX Box, this box costs about $150,000 each. How do you keep these boxes busy so that you’re getting a good return on investment? It will require you to better manage the resources offered with these boxes. We are also monitoring that space and we’re seeing that how can we take the Robin platform and how do you enable the better utilization of GPUs or the sharing of GPUs for running your AI ML kind of workload.

We’ll be discussing these trends at the next DataWorks Summit, I’m sure, at some other time in the future.

Learn more about Robin Hyper-Converged Kubernetes Platform – the First Container Solution Certified to run Hortonworks Data Platform (HDP) for big data, nosql databases and RDBMS applications.

Self-service deployment of a Cloudera cluster on the Robin platform demo video

Self-service deployment of a Cloudera cluster on the Robin platform

Robin Systems Videos

In this demo video, we demonstrate how you can setup a Cloudera cluster with a click of a button on the Robin Platform.

Robin’s application-aware manager simplifies deployment and lifecycle management using container-based “virtual clusters.” Each cluster node is deployed within a container. The collection of containers running across servers makes the “virtual cluster.” This allows Robin to automate all tasks pertaining to the creation, scheduling, and operation of these virtual application clusters, to the extent that an entire data pipeline can be provisioned or cloned with a single click and minimal upfront planning or configuration.

Robin Platform has three components

Robin Application-aware compute

Robin platform aggregates the existing compute – proprietary or commodity servers – and creates a single layer of all compute resources that are available to each application that the enterprise uses.

Container Technology

Robin leverages container technology to consolidate applications with complete runtime isolation. Container is a lightweight, OS-based virtualization technology that allows creation of compartmentalized and isolated application environment on top of the standard OS.

Performance-Sensitive Workloads

Robin is the first and only product in the industry that brings application lifecycle management benefits to all types of enterprise applications – including highly performance-sensitive workloads such as NoSQL databases RDBMS and Big Data.

Appropriate Container Configuration

Robin’s Adaptive container technology picks the appropriate container configuration depending on the application types. Traditional applications are deployed within “system containers” to provide VM-like semantics and Robin supports the deployment of stateless microservices applications such as Docker containers.

Zero Performance Impact

When used with bare-metal servers, Robin enables “zero-performance-impact” consolidation of data-havy databases, and other distributed applications such as Elasticsearch, with Application lifecycle management features, resulting in significant operational efficiency gains and cost reduction.

Robin Application-aware storage

Robin Application-aware manager

Agile Provisioning

  • Simplify cluster deployment using application-aware fabric controller—provision an entire operational data pipeline within minutes
  • Deploy container-based “virtual clusters” running across commodity servers
  • Automate tasks – create, schedule and operate virtual application clusters
  • Scale-up or scale-out instantaneously to meet application performance demands

Self-service deployment of a Cloudera cluster on the Robin platform

Robin Systems Videos

Provisioning, scaling, cloning and time travel an ELK cluster demo video

Provisioning, scaling, cloning and time travel an ELK cluster

Robin Systems Videos

In this demo video we show 3 very important lifecycle management operations with Robin Hyper-Converged Kubernetes Platform on a ELK (Elasticsearch, Logstash, Kibana) cluster. Provisioning followed by scaling and then cloning and time travel.

Provisioning, scaling, cloning and time travel an ELK cluster

Robin Systems Videos

The Open Source Elastic Stack

Reliably and securely take data from any source, in any format, and
search, analyze, and visualize it in real time.

ELK Cluster – Elasticsearch, Kibana, Logstash

Elasticsearch

Elasticsearch is a distributed, JSON-based search and analytics engine designed for horizontal scalability, maximum reliability, and easy management.

The Heart of the Elastic Stack

Elasticsearch is a distributed, RESTful search and analytics engine capable of solving a growing number of use cases. As the heart of the Elastic Stack, it centrally stores your data so you can discover the expected and uncover the unexpected.

SPEED

Elasticsearch Is Fast.
Really, Really Fast.

When you get answers instantly, your relationship with your data changes. You can afford to iterate and cover more ground.

Being this fast isn’t easy. We’ve implemented inverted indices with finite state transducers for full-text querying, BKD trees for storing numeric and geo data, and a column store for analytics.

And since everything is indexed, you’re never left with index envy. You can leverage and access all of your data at ludicrously awesome speeds.

Kibana

Kibana gives shape to your data and is the extensible user interface for configuring and managing all aspects of the Elastic Stack.

Your Window into
the Elastic Stack

Kibana lets you visualize your Elasticsearch data and navigate the Elastic Stack, so you can do anything from learning why you’re getting paged at 2:00 a.m. to understanding the impact rain might have on your quarterly numbers.

Logstash

Visualize your data. Navigate the Elastic Stack.

Logstash –

Ingest any data, from any source, in any format.

Logstash is a dynamic data collection pipeline with an extensible plugin ecosystem and strong Elasticsearch synergy.

Centralize, Transform & Stash Your Data

Logstash is an open source, server-side data processing pipeline that ingests data from a multitude of sources simultaneously, transforms it, and then sends it to your favorite “stash.”

QUERY

Be Curious. Ask Your Data Questions of All Kinds.

Elasticsearch lets you perform and combine many types of searches — structured, unstructured, geo, metric — any way you want. Start simple with one question and see where it takes you.

ANALYZE

Step Back and Understand the Bigger Picture.

It’s one thing to find the 10 best documents to match your query. But how do you make sense of, say, a billion log lines? Elasticsearch aggregations let you zoom out to explore trends and patterns in your data.

Share data across two Cloudera clusters

Share data across two cloudera clusters

Robin Systems Videos

In this demo, we will demonstrate how we can share data across two Cloudera clusters with Robin Hyper-Converged Kubernetes Platform

Agile Provisioning

  • Simplify cluster deployment using application-aware manger—provision an entire operational data pipeline within minutes
  • Deploy container-based “virtual clusters” running across commodity servers
  • Automate tasks – create, schedule and operate virtual application clusters
  • Scale-up or scale-out instantaneously to meet application performance demands

Share data – Robin eliminates cluster sprawl by deploying a data pipeline on shared hardware. This also results in better hardware utilization. The key to successful multi-tenancy is the ability to provide performance isolation and dynamic performance controls. The Robin application-aware manager equips each virtual cluster with dynamic QoS controls for every resource that it depends on – CPU, memory, network, and storage. This creates a truly elastic infrastructure that delivers CPU, memory, network and storage resources – both capacity and performance – to an application exactly at the instant it is needed.

Cluster Consolidation and QoS

  • Eliminate cluster sprawl with data pipeline components on the same shared hardware
  • Enable multi-tenancy with performance isolation and dynamic performance controls
  • Leverage dynamic QoS controls for every resource – CPU, memory, network and storage

Robin provides out of the box support for application time travel. Cluster level distributed snapshots at pre-defined intervals can be really useful to restore the entire pipeline or parts of it if anything goes wrong. Robin recommends admins to take snapshots before making any major changes. Whether you are upgrading the software version or making a configuration change make sure to have a snapshot. If anything goes wrong the entire cluster can be restored to the last known snapshot in matter of minutes.

Application Time Travel

  • Take unlimited cluster snapshots
  • Restore or refresh a cluster to any point-in-time using snapshots

Robin for Big Data

Setting up Hadoop cluster in the cloud

Robin Videos

Controlling IOPS in a shared Environment

Controlling IOPS in a shared Environment

Robin Systems Videos

In this video, we demonstrate how easily we can throttle IOPS from an application to address the noisy neighbor problem with Robin Hyper-Converged Kubernetes Platform

Controlling IOPS in a Shared Environment

Robin Systems Videos

nput/output operations per second (IOPS, pronounced eye-ops) is an input/output performance measurement used to characterize computer storage devices like hard disk drives (HDD), solid state drives (SSD), and storage area networks (SAN). Like benchmarks, IOPS numbers published by storage device manufacturers do not directly relate to real-world application performance.[1][2]

Controlling IOPS – Background

To meaningfully describe the performance characteristics of any storage device, it is necessary to specify a minimum of three metrics simultaneously: IOPS, response time, and (application) workload. Absent simultaneous specifications of response-time and workload, IOPS are essentially meaningless. In isolation, IOPS can be considered analogous to “revolutions per minute” of an automobile engine i.e. an engine capable of spinning at 10,000 RPMs with its transmission in neutral does not convey anything of value, however an engine capable of developing specified torque and horsepower at a given number of RPMs fully describes the capabilities of the engine.

In 1999, recognizing the confusion created by industry abuse of IOPS numbers following Intel‘s release of IOmeter, a performance benchmarking tool, the Storage Performance Council developed an industry-standard, peer-reviewed and audited benchmark that has been widely recognized as the only meaningful measurement of storage device IO performance; the SPC-1 benchmark suite[citation needed]. The SPC-1 requires storage vendors to fully characterize their products against a standardized workload closely modeled on ‘real-world’ applications, reporting both IOPS and response-times and with explicit prohibitions and safeguards against ‘cheating’ and ‘benchmark specials’. As such, an SPC-1 benchmark result provides users with complete information about IOPS, response-times, sustainability of performance over time and data integrity checks. Moreover, SPC-1 audit rules require vendors to submit a complete bill-of-materials including pricing of all components used in the benchmark, to facilitate SPC-1 “Cost-per-IOPS” comparisons among vendor submissions.

Among the single-dimension IOPS tools created explicitly by and for benchmarketers, applications, such as Iometer (originally developed by Intel), as well as IOzone and FIO[3]have frequently been used to grossly exaggerate IOPS. Notable examples include Sun (now Oracle) promoting its F5100 Flash array purportedly capable of delivering “1 million IOPS in 1 RU” (Rack Unit). Subsequently, tested on the SPC-1, the same storage device was only capable of delivering 30% of the IOmeter value on the SPC-1.[4][5]

The specific number of IOPS possible in any system configuration will vary greatly, depending upon the variables the tester enters into the program, including the balance of read and write operations, the mix of sequential and random access patterns, the number of worker threads and queue depth, as well as the data block sizes.[1] There are other factors which can also affect the IOPS results including the system setup, storage drivers, OS background operations etc. Also, when testing SSDs in particular, there are preconditioning considerations that must be taken into account.[6]

Performance characteristics and Controlling IOPS

Random access compared to sequential access.

The most common performance characteristics measured are sequential and random operations. Sequential operations access locations on the storage device in a contiguous manner and are generally associated with large data transfer sizes, e.g. 128 kB. Random operations access locations on the storage device in a non-contiguous manner and are generally associated with small data transfer sizes, e.g. 4kB.

The most common performance characteristics are as follows:

Measurement Description
Total IOPS Total number of I/O operations per second (when performing a mix of read and write tests)
Random Read IOPS Average number of random read I/O operations per second
Random Write IOPS Average number of random write I/O operations per second
Sequential Read IOPS Average number of sequential read I/O operations per second
Sequential Write IOPS Average number of sequential write I/O operations per second

For HDDs and similar electromechanical storage devices, the random IOPS numbers are primarily dependent upon the storage device’s random seek time, whereas, for SSDs and similar solid state storage devices, the random IOPS numbers are primarily dependent upon the storage device’s internal controller and memory interface speeds. On both types of storage devices, the sequential IOPS numbers (especially when using a large block size) typically indicate the maximum sustained bandwidth that the storage device can handle.[1]Often sequential IOPS are reported as a simple MB/s number as follows:

{displaystyle {text{IOPS}}*{text{TransferSizeInBytes}}={text{BytesPerSec}}} (with the answer typically converted to MegabytesPerSec)

Some HDDs will improve in performance as the number of outstanding IOs (i.e. queue depth) increases. This is usually the result of more advanced controller logic on the drive performing command queuing and reordering commonly called either Tagged Command Queuing (TCQ) or Native Command Queuing (NCQ). Most commodity SATA drives either cannot do this, or their implementation is so poor that no performance benefit can be seen.[citation needed] Enterprise class SATA drives, such as the Western Digital Raptor and Seagate Barracuda NL will improve by nearly 100% with deep queues.[7] High-end SCSI drives more commonly found in servers, generally show much greater improvement, with the Seagate Savvio exceeding 400 IOPS—more than doubling its performance.[citation needed]

While traditional HDDs have about the same IOPS for read and write operations, most NAND flash-based SSDs are much slower writing than reading due to the inability to rewrite directly into a previously written location forcing a procedure called garbage collection.[8][9][10] This has caused hardware test sites to start to provide independently measured results when testing IOPS performance.

Newer flash SSDs, such as the Intel X25-E, have much higher IOPS than traditional HDD. In a test done by Xssist, using IOmeter, 4 KB random transfers, 70/30 read/write ratio, queue depth 4, the IOPS delivered by the Intel X25-E 64GB G1 started around 10000 IOPs, and dropped sharply after 8 minutes to 4000 IOPS, and continued to decrease gradually for the next 42 minutes. IOPS vary between 3000 and 4000 from around the 50th minutes onwards for the rest of the 8+ hours test run.[11] Even with the drop in random IOPS after the 50th minute, the X25-E still has much higher IOPS compared to traditional hard disk drives. Some SSDs, including the OCZ RevoDrive 3 x2 PCIe using the SandForce controller, have shown much higher sustained write performance that more closely matches the read speed.[12]

Controlling IOPS in an Oracle Database with Robin

Oracle as a Service on Kubernetes Solution Brief

More Robin Hyper-Converged Kubernetes Platform Demos and Videos

Controlling IOPS Oracle Database

Relational Databases

No Compromise Database Consolidation

[button color=”accent-color” hover_text_color_override=”#fff” size=”large” url=”/solutions/relational-databases/” open_new_tab=”true” text=”Learn More” color_override=””]

More Robin Hyper-Converged Kubernetes Platform Demos and Videos

Managing IOPS with Robin Hyper-Converged Kubernetes Platform

Learn More – Robin Hyper-Converged Kubernetes Platform for big data & databases

Managing IOPS with Robin Systems

Managing IOPs with Robin Hyper-Converged Kubernetes Platform for Big Data & Databases

Allocate the right amount of IOPs for each Application in your data center. Make sure one Application does not hog all the IOPs or majority of the IOPs. Set min and max IOPs for each Application and change them dynamically with Robin Hyper-Converged Kubernetes Platform for big data and databases.

DataStax Cassandra: Provision and Scale Out

DataStax Cassandra Provision and Scale Out

1-click, rapid, self-service Cassandra deployment with Robin Hyper-Converged Kubernetes Platform

  • Build elastic infrastructure that provides all resources to each application as needed
  • Create single-click clone of entire data pipeline
  • Get out-of-the-box 2-way or 3-way replication
  • Create thin clones on the fly without affecting data in production
  • Achieve data sharing pointing HDFS of one cluster to another

It is necessary to scale up or out as demand for resources spikes and then comes back to normal. Robin enables you to scale up with a single click by allocating more resources to the application. Robin enables you to scale out easily when you need to add nodes and helps you clone parts of your data when you need give data to developers and analysts for analytics, test upgrades, testing changes or for integration testing.

More Robin Hyper-Converged Kubernetes Platform Videos and Demos

Cassandra: Snapshot, Clone and Time Travel

More Robin Hyper-Converged Kubernetes Platform demo videos

Cassandra: Snapshot, Clone, and Time Travel

Cassandra Snapshot, Clone, Time-travel

  • Take unlimited cluster snapshots
  • Restore or refresh a cluster to any point-in-time using snapshots

Robin Hyper-Converged Kubernetes Platform provides out of the box support for application time travel. Cluster level distributed snapshots at pre-defined intervals can be really useful to restore the entire pipeline or parts of it if anything goes wrong.

Robin Systems recommends admins to take snapshots before making any major changes. Whether you are upgrading the software version or making a configuration change make sure to have a snapshot. If anything goes wrong the entire cluster can be restored to the last known snapshot in a matter of minutes.

View Demo – Cassandra: Snapshot, Clone and Time Travel

Cassandra: Quality of Service

Robin Hyper-Converged Kubernetes Platform for NoSql databases such as Cassandra

More Robin Hyper-Converged Kubernetes Platform Demos and Videos

Cassandra: Quality of Service Control

Cassandra QoS – Quality of Service

Guaranteed Availability and Performance

  • Eliminate cluster sprawl with data pipeline components on the same shared hardware
  • Enable multi-tenancy with performance isolation and dynamic performance controls
  • Leverage dynamic QoS controls for every resource – CPU, memory, network and storage

Robin eliminates cluster sprawl by deploying a data pipeline on shared hardware. This also results in better hardware utilization. The key to successful multi-tenancy is the ability to provide performance isolation and dynamic performance controls. The Robin application-aware fabric controller equips each virtual cluster with dynamic QoS controls for every resource that it depends on – CPU, memory, network, and storage. This creates a truly elastic infrastructure that delivers CPU, memory, network and storage resources – both capacity and performance – to an application exactly at the instant it is needed.

More Robin Hyper-Converged Kubernetes Platform Demos and Videos