Posts

Piraeus datastore - port

LINBIT announces Piraeus Datastore – Software-Defined Storage (SDS) for Kubernetes

Piraeus Datastore offers high performance, highly reliable SDS solution for Persistent Volumes in Kubernetes

 

San Diego, November 18., 2019 – LINBIT, the inventor of the open-source software DRBD™ and leader in Linux storage software, has announced the project “Piraeus Datastore”. Piraeus Datastore offers a fast, stable way for users to provide Persistent Volumes for their Kubernetes applications. It is developed under the open-source development model and has been made publicly available via pre-built packages and containers in a joint-effort between LINBIT, Daocloud and the open-source community. 

 

Serving the rapidly growing containerized applications market, Piraeus Datastore fills a significant gap in the market by providing a stable Software-Defined Storage solution for Kubernetes applications requiring high-performance block storage. “When it comes to storage, Piraeus helps clients achieve better system availability than competitors in the space can offer ”, says  Philipp Reisner, CEO of LINBIT. “Most Kubernetes storage newcomers combined the data and control plane to push out a minimum viable product. By separating these components out, we ensure that controller failure doesn’t impact storage system availability.” 

 

DaoCloud has been a leading CloudNative computing vendor in China since 2014. They have extensive experience of Kubernetes production with Fortune Global 500 customers in manufacturing and finance industries like SAIC, Haier and SPDB bank. They believe that Piraeus fits their clients’ needs for a cloud-native, container attached storage that provides both reliability and performance. Roby Chen, CEO of DaoCloud, says: “It is very exciting that we have the Piraeus project to elevate DRBD technology into the cloud-native arena, where we believe it can play a key role.” 

Kubernetes is generating more and more buzz

Piraeus Datastore provides data persistence for elastic applications, which dynamically create or remove containers depending on the load. A recent survey of 390 IT professionals showed that 51% of participants acknowledge there has been an increase in Kubernetes adoption in the last six months. And 86% of respondents say they have now adopted Kubernetes. The number went up from 57% a half a year ago. Storage remains a requirement for enterprises that are beginning to move their applications over to Kubernetes and the Piraeus datastore solution is perfect for clients who need the combination of reliability and performance.

 

With Piraeus Datastore, two key Open Source technologies are packaged in a way that is easily accessible and consumable for Kubernetes users. They bring the highest performance by leveraging on the proven DRBD technology and real-world operable clusters by the way LINSTOR™ separates control and data paths.

Piraeus Datastore makes proven technologies cloud-native. DRBD is under development, improvements and optimizations for 19 Years. LINSTOR stands out in the field of SDS systems by having a separate and independent control plane that is independent from the data plane. This big advantage of this separation is it makes upgrades in a running storage cluster feasible, which saves downtime and therefore a lot of money. 

Piraeus Datastore is perfectly suited for databases, AI and analytics workloads, where the throughput and latency of primary storage is required.

 

LINBIT SDS™ is the industry’s fastest software-defined storage solution for enterprise, cloud, and container environments. LINBIT SDS leverages the DRBD™ and LINSTOR™ technology to provision, replicate, and manage data storage: independent of underlying hardware. The Piraeus containers intended for adoption by the community, while the LINBIT SDS containers are intended for consumption by corporate users. The LINBIT SDS product comes with enterprise support options, while Piraeus is supported by the community.

 

For a close comparison check out the following graphic:

 

Piraeus_logoPiraeus Datastore linbit_sdsLINBIT SDS
Container base image Debian_logodebian UBI
Pre-built available Publicly on Dockerhub, Quay For LINBIT customers drbd.io
Support community only ✅ enterprise, incl 24/7
Runs with OpenShift  without DRBD
OpenShift certified n.a.  
Kernel-module compile from source compile & pre-compiled
Contains DRBD logo, piraeus-operator, linstor-csi and

Linstor_logo

Licensing Open source software, GPL & Apache
Developed and verified for kubernetes container orchestration and redhat primed openshift
Platforms on the roadmap ibm cloud containerSuse Caas

 

Learn more:

 

About Linbit

 

LINBIT is the force behind DRBD and a leader in open-source Linux block storage software for enterprise and cloud computing. The LINBIT software has helped dozens of global companies such as Volkswagen, Intel, Cisco, Siemens, BBC to provide High Availability (HA), Geo Clustering for Disaster Recovery (DR), and Software-Defined Storage (SDS) for public and private clouds. Based in Vienna LINBIT partners with other companies like Redhat, Intel, IBM or DaoCloud to accelerate Linux storage software. For more information, visit linbit.com or follow @linbit

 

Social Media Channels:

 

LINBIT on Twitter

LINBIT on Linkedin

LINBIT on Youtube

LINBIT on Facebook

 

About DaoCloud

 

DaoCloud is a leading CloudNative computing vendor in China since 2014. They have extensive experience of Kubernetes production with Fortune Global 500 customers in manufacturing and finance industries like SAIC, Haier and SPDB bank. 

 

PR contact:

 

Sebastian Schinhammer

Marketing Manager

sebastian.schinhammer(@)linbit.com

Phone: 0043 1 817 82 92 -64

LINBIT HA-Solutions GmbH

Vivenotgasse 48

1120 Wien

 

Kubernetes Operator: LINSTOR’s Little Helper

Before we describe what our LINSTOR Operator does, it is a good idea to discuss what a Kubernetes Operator actually is. If you are already familiar with Kubernetes Operators, feel free to skip the introduction.

Introduction

CoreOS describes Operators like this:

An Operator is a method of packaging, deploying and managing a Kubernetes application. A Kubernetes application is an application that is both deployed on Kubernetes and managed using the Kubernetes APIs and  kubectl tooling.

That is quite a lot to grasp if you are new to the concept of Operators. What users want to do is their work, without having to worry about setting up infrastructure. Still, there is more to a software lifecycle than just firing up the application in a cluster once. This is where an Operator comes into play. In my opinion, a good analogy is to think of a Kubernetes Operator as an actual human operator. So what would the responsibilities of such a human operator be?

A human operator would be an expert in the business logic of the software that she runs and the dependencies that need to be fulfilled to run the software. Additionally, the operator would be responsible for configuring the software: to scale it, to upgrade it, to make backups, and so on. This is also the responsibility of a Kubernetes Operator implemented in software. It is a software component that is built by experts for a particular containerized software. This Operator is executed by an administrator who isn’t necessarily an expert for that particular software.

A Kubernetes Operator is executed in the Kubernetes cluster itself. In contrast to shell scripts or Ansbile playbooks, which are pretty generic, the Operator framework has one specific purpose, as well as access to Kubernetes cluster information. Additionally, they are managed by standard Kubernetes tools and not some external tools for configuration management. An Operator has a managed lifecycle on its own and is managed by the lifecycle manager.

LINSTOR Operator

CoreOS FAQ contains the following sentence:

Experience has shown that the creation of an Operator typically starts by automating an application’s installation and self-service provisioning capabilities, and then evolves to take on more complex automation.

This pretty much sums up the current state of the linstor-operator. The project is still very young and the current focus was on automating the setup of the LINSTOR cluster. If you are familiar with LINSTOR, you know that there is a central component named the LINSTOR controller, and workers — named LINSTOR satellites — that actually create LVM volumes and configure DRBD to provide data redundancy.

Currently, the Operator can add new nodes/kubelets to the LINSTOR cluster by registering them with their name and network interface configuration by the LINSTOR controller. A second important task is that a LINSTOR satellite can actually provide storage to the cluster. Therefore, the linstor-operator can also register one or multiple storage pools. Metrics of the LINSTOR satellite set’s storage pools are exposed by the operator. Therefore the system administrator saves a lot of time, because the LINSTOR Kubernetes Operator automates a lot of standard tasks, which were previously performed manually.

Future work

There is a lot of possible future work that can be done. Some tasks are obvious, some will be driven by actual input of our users. For example we think that configuring storage is one of the pain points for our uses. Therefore, having a sidecar container that can discover and prepare storage pools to be consumed by LINSTOR might be a good idea. In a dynamic environment such as Kubernetes it might be worthwhile to handle nodes failures in clever ways. We also have container images that can inject the DRBD kernel module into the running host kernel, which could help users with getting started with DRBD. High Availability is always an important topic and related to that using etcd as database backend. Further, we want to tackle one of the core tasks of Operators, which is managing upgrades from one LINSTOR controller version to the next.

Thanks to Hayley for reviewing this blog post, she is too busy doing the actual work. This is just a subset of the capabilities we plan for the linstor-operator. Stay tuned for more information!

 

Roland Kammerer
Software Engineer at Linbit
Roland Kammerer studied technical computer science at the Vienna University of Technology and graduated with distinction. Currently, he is a PhD candidate with a research focus on time-triggered realtime-systems and works for LINBIT in the DRBD development team.
Container-kubernetes-linsto

Containerize LINSTOR

LINBIT and its Software-Defined Storage (SDS) solution LINSTOR has provided integration with Linux containers for quite some time. These range from a Docker volume plugin, to a Flexvolume plugin, and recently, a CSI plugin for Kubernetes. While we always provided excellent integration to the container world, most of our software itself was not available as a container/base image. Containerizing our services is a non-trivial task. As you probably know, the core of the DRBD software consists of a Linux kernel module and user space utilities that interact via netlink with this kernel module. Additionally, our software needs to create LVM devices and DRBD block devices within a container. These tasks are interesting and challenging to put into containers. For this article, we assume 3 nodes, one node that acts as a LINSTOR controller, and two that act as satellites. We tested this with recent Centos7 machines and with a current version of Docker.

Prerequisites

In this article, we assume access to our Docker registry hosted on drbd.io. On all hosts you should run the following commands:

docker login drbd.io
Username: YourUserName
Password: YourPassword
Login Succeeded

Installing the DRBD kernel modules

We need the DRBD kernel module and its dependencies on the LINSTOR satellites (the controller does not need access to DRBD). For that we provide a solution for the most common platforms, namely Centos7/RHEL7 and Ubuntu Bionic.

docker run --privileged -it --rm \
  -v /lib/modules:/lib/modules drbd.io/drbd9:rhel7
DRBD modul sucessfully loaded 

What this does is check which kernel is actually executed on the host, then found it the most appropriate package in the container and installed it. We ship the same, unmodified rpm/deb packages in the container as we provide in our customer repositories. If you are using Ubuntu Bionic, you should use the drbd.io/drbd9:bionic container.

Running a LINSTOR controller

docker run -d --name=linstor-controller \
  -p 3376:3376 -p 3377:3377 drbd.io/linstor-controller

The controller does not have any special requirements, it just needs to be accessible to the client via TCP/IP. Please note that in this configuration the controller’s database is not persisted. One possibility is to bind-mount the directory used for the controller’s database by adding
-v /some/dir:/var/lib/linstor .

Running a LINSTOR satellite

docker run -d --name=linstor-satellite --net=host \
 --privileged drbd.io/linstor-satellite 

The satellite is the component that creates actual block devices. On one hand the backing devices (usually LVM) and the actual DRBD block devices. Therefore this container needs access to/dev, and it needs to share the host networking. Host networking is required for the communication between drbdsetup and the actual kernel module.

Configuring the Cluster

We have to set up LINSTOR as usual, which fortunately, is an easy task and has to be done only once. In the spirit of this blog post, let’s use a containerized LINSTOR client as well. As the client obviously has to talk to the controller, we need to tell the client in the container where to find the controller. This is done by setting the environment variable LS_CONTROLLERS.

docker run -it --rm -e LS_CONTROLLERS=Controller \ 
  drbd.io/linstor-client interactive
  ...
- volume-definition (vd)
LINSTOR ==> node create Satellite1 172.42.42.10
LINSTOR ==> node create Satellite2 172.42.42.20
LINSTOR ==> storage-pool-definition create drbdpool
LINSTOR ==> storage-pool create lvm Satellite1 drbdpool drbdpool
LINSTOR ==> storage-pool create lvm Satellite2 drbdpool drbdpool 

Creating a replicated DRBD resource

So far we loaded the kernel module on the satellites, started the controller and satellite containers and configured the LINSTOR cluster. Now it is time to actually create resources.

docker run -it --rm -e LS_CONTROLLERS=Controller \ 
  drbd.io/linstor-client interactive
  ... 
- volume-definition (vd)
 LINSTOR ==> resource-definition create demo
 LINSTOR ==> volume-definition create demo 1G
 LINSTOR ==> resource create demo --storage-pool drbdpool --auto-place 2 

If you have drbd-utils installed on the host, you can now see the DRBD resource as usual viadrbdsetup status. But we can also use a container to do that. On one of the satellites you can run a throw-away linstor-satellite container which contains drbd-utils:

docker run -it --rm --net=host --privileged \
 --entrypoint=/bin/bash drbd.io/linstor-satellite
$ drbdsetup status
$ lvs

Note that by default you will not see the symbolic links for the backing devices created by LVM/udev in the LINSTOR satellite container. That is expected. In the container you will see something like /dev/drbdpool/demo_00000, while on the host you will only see/dev/dm-X, and  lvs will not show the LVs. If you really want to see the LVs on the host, you could execute  lvscan -a --cache, but there is no actual reason for that. One might also map the lvmetad socket to the container.

Summary

As you can see, LINBIT’s container story is now complete. It is now possible to deploy the whole stack via containers. This ranges from the lowest level of providing the kernel modules to the highest level of LINSTOR SDS including the client, the controller, and satellites.

Roland Kammerer
Software Engineer at Linbit
Roland Kammerer studied technical computer science at the Vienna University of Technology and graduated with distinction. Currently, he is a PhD candidate with a research focus on time-triggered realtime-systems and works for LINBIT in the DRBD development team.

LINBIT SDS Adds Disaster Recovery and Support for Kubernetes

LINBIT SDS (Linux SDS) will showcase cloud-native enterprise storage management at KubeCon + CloudNativeCon in Seattle

Beaverton, OR, Dec. 3, 2018 – LINBIT enhances open source software-defined storage (SDS) by providing disaster recovery (DR) replication for critical data. LINBIT SDS is an enterprise-class storage management solution designed for cloud and container storage workloads.

To simplify administration, enhance user experience, and accelerate integration with other software, LINBIT SDS relies on the pre-existing storage management capabilities native to Linux, such as LVM and DRBD. These capabilities are complemented by LINSTOR, a feature-rich volume management software. One supported storage tool is DRBD, the in-kernel block level data-replication for Linux. By announcing support for DRBD Proxy, LINBIT extends replication to disaster recovery scenarios since DRBD Proxy enables fast and reliable data replication over any distance by resolving network communications and handling data access latencies.

“LINBIT SDS is rapidly becoming the reliable, high performance, and economical choice for enterprise and cloud workloads,” said Brian Hellman COO of LINBIT. “With simplified support for DR, LINBIT SDS is surpassing the costly and complex proprietary cloud storage solutions.”

LINBIT SDS provides a host of capabilities to manage persistent block storage for Kubernetes environments. It supports logical volume management (LVM) snapshots, which enhance application availability while minimizing data loss; thin provisioning, which improves efficient resource utilization in virtualized environments; and volume management, which simplifies tasks such as adding, removing, or replicating storage volumes.

LINBIT SDS supports Kubernetes

The Linux based SDS solution works with the leading cloud projects Kubernetes, OpenStack, and OpenNebula, as well as a range of virtualization platforms, and as a stand-alone product. Learn more about how the software works by watching a short video-demo here:

Persistent Kubernetes Storage for Databases (MySQL) with LINSTOR and DRBD (Demo)

OpenStack Cinder: Open-Source Volume Management with LINSTOR and DRBD

Linux Disaster Recovery Replication with DRBD Proxy (Demo)

LINBIT is a member of the Linux Foundation and is proud to support KubeCon, a Linux Foundation conference. Visit us at KubeCon + CloudNativeCon at booth #S7, December 11th-13th, 2018 in Seattle.

ABOUT LINBIT

LINBIT is the force behind DRBD and is the de facto open standard for High Availability (HA) software for enterprise and cloud computing. The LINBIT DRBD software is deployed in millions of mission-critical environments worldwide to provide High Availability (HA), Geo-Clustering for Disaster Recovery (DR), and Software Defined Storage (SDS) for OpenStack and OpenNebula based clouds. Don’t be shy. Visit us at LINBIT.com.

###