Container-native storage from Red Hat is on a roll at Red Hat Summit 2018!

By Steve Bohac, Product Marketing, Red Hat Storage

It’s Red Hat Summit week, with this year’s edition taking place in San Francisco! As always, Red Hat has a plethora of announcements this week.

If you haven’t already heard the news, yesterday we announced substantial customer adoption momentum with container-native storage from Red Hat. Customers such as Lufthansa Technik, Aragonesa de Servious Telematico (AST), Generali Switzerland, IHK-GfI, and Vorwerk (amongst many more) are using Red Hat OpenShift Container Platform for cloud-native applications and are representative of how organizations are seeking out scalable, fully integrated, developer friendly storage for containers.

Based on Red Hat Gluster Storage, container-native storage from Red Hat offers these organizations scalable, persistent storage for containers across hybrid clouds with increased application portability. Tightly integrated with Red Hat OpenShift Container Platform, container-native storage from Red Hat can be used to persist not only application data but data for logging, metrics, and the container registry. The deep integration with Red Hat OpenShift Container Platform helps developers easily provision and manage elastic storage for applications and offers a single point of support. Customers use container-native storage to persist data for a variety of applications, including SQL and NoSQL databases, CI/CD tools, web serving, and messaging applications.

Organizations using container-native storage from Red Hat can benefit from simplified management, rapid deployment, and a single point of support. The versatility of container-native storage from Red Hat can enable customers to run cloud-native applications in containers, on bare metal, in virtualized environments, or in the public cloud.

For those of you attending Red Hat Summit this week, as always we know you love breakout sessions to learn more about Red Hat solutions—and we have a bunch covering container-native storage from Red Hat! Don’t forget to get your raffle tickets at each of the storage sessions you attend. Here’s what the line up for container-native storage from Red Hat sessions looks like:

(All in Moscone West unless otherwise noted)

Tuesday, May 8

Thursday, May 10

Want to learn more?

For hands-on experience combining OpenShift and container-native storage, check out our test drive, a free, in-browser lab experience that walks you through using both.

Happy Red Hat Summit! Hope to see you this week!

 

 

 

Five ways to experience UnStorage at Red Hat Summit

Welcome to Red Hat Summit 2018 in San Francisco! The Storage team has been hard at work to make this the best possible showcase of technology and customers—and have fun while doing it. This year our presence is built around the theme: UnStorage for the modern enterprise.

What is UnStorage?

Today’s users need their data so accessible, so scalable, so versatile that the old concept of “storing” it seems counterintuitive. Perhaps a better way of describing the needs of the modern enterprise is UnStorage, as outlined in this blog post by Red Hat Storage VP and GM, Ranga Rangachari.

Five ways to experience UnStorage at Red Hat Summit

  1. Content is king: We have 24 sessions packed with storage knowledge, best practices, and success stories. Over 21 Red Hat Storage customers will be featured at the event, including on a panel at our breakfast (open to all attendees) on Wednesday at 7 am at the Marriott Marquis. Learn how some of the most innovative enterprises leverage the power of unStorage to solve their scale and agility challenges.
  2. Without hardware partners, it’s like clapping with one hand: By definition, the success of software-defined storage hinges on the strength of the hardware ecosystem. Since the storage controller software is only half the solution, it’s important to have deep engineering investment with hardware and component vendors to build rock-solid solutions for customers. With partners like Supermicro, Mellanox, Penguin Computing, Intel, Commvault, and QCT, all featured at the conference, Red Hat Storage enables greater customer choice and openness—a key tenet of UnStorage.
  3. Explore your storage curiosity: UnStorage is all about breaking the rules to make things better. You’ll find a lot of creative ideas that are off the beaten track. Just as UnStorage is ubiquitous—it stretches across private, public, and hybrid cloud boundaries—it’s hard to miss Storage at the conference. You can find storage lockers near the expo entrance where you can drop off backpacks and charge phones while you attend sessions. Or enter to win one of two Star Wars collector edition drones by attending sessions or visiting the booth. Stop by the Storage Launch Pad to play online games, take surveys, and pick up a ton of giveaways, including two golden tickets handed out every day, which will afford you a special set of prizes.
  4. Test drive storage: Kick the tires on UnStorage with one of three test drives for Ceph, Gluster, and OpenShift Ops. As the name suggests, software-defined storage is completely decoupled from hardware, making it easy to test and deploy in the cloud. On the other side of the deployment spectrum, you can also try out the sizing tool for Red Hat Storage One, our single SKU pre-configured system announced last week. Stop by one of four Storage pods on the expo floor for demos and conversations with Storage experts.
  5. The proof of the pudding: Stop by Thursday’s keynote with CTO Chris Wright and live demos by Burr Sutter and team featuring container-native storage baked into Red Hat platforms such as OpenShift. UnStorage is as invisible as it is pervasive. Modern enterprises demand that storage be fully integrated into compute platforms for easier management and scale. With container-native storage surpassing 150 customers in the last year alone, learn how customers such as Schiphol, FICO, and Macquarie Bank are building next-generation hybrid clouds with Red Hat technologies.

We’re not all-work-all-the-time at Red Hat Storage, though. Join us at the community happy hour or the hybrid cloud infrastructure party on Tuesday to blow off some steam during a long week. Our social media strategist, Colleen Corrice, is running a way cool Twitter contest: All you have to do is post a picture at a Storage session or booth @RedHatStorage with the hashtag #UnStorage to receive a T-shirt and be included in a drawing for a personal planetarium.

Finally, check out this infographic on all things UnStorage @ Red Hat Summit. Please check back for a daily blog through this week. We hope to see you at Red Hat Summit 2018.

Container-native storage 3.9: Enhanced day-2 management and unified installation within OpenShift Container Platform

By  Annette Clewett, Humble Chirammal, Daniel Messer, and Sudhir Prasad

With today’s release of Red Hat OpenShift Container Platform 3.9, you will now have the convenience of deploying Container-Native Storage (CNS) 3.9 built on Red Hat Gluster Storage as part of the normal OpenShift deployment process in a single step. At the same time, major improvements in ease of operation have been introduced to give you the ability to monitor provisioned storage consumption, expand persistent volume (PV) capacity without downtime, and use a more intuitive naming convention for persistent volume names.

Continue reading “Container-native storage 3.9: Enhanced day-2 management and unified installation within OpenShift Container Platform”

Product of the Year finalist

By Daniel Gilfix, Red Hat Storage

For the second year in a row, Red Hat Ceph Storage has been named as a finalist in Storage Magazine and SearchStorage’s 2017 Products of the Year competition. Whereas in 2016, the honor was bestowed upon what was arguably the most important product release since Ceph came aboard the Red Hat ship, this year’s candidate was Red Hat Ceph Storage 2.3, a point release. This means a lot to us, but as a reader—perhaps a current or prospective customer, why should you care?

Excellent question, I must say, since normally we don’t like to boast. Our focus here at Red Hat is on the needs, experiences, and ultimate satisfaction of those who use our solutions. And given the evolution of Red Hat Ceph Storage from its acquisition from Inktank, the storage vendor, to Red Hat, the IT vendor, one would hope that we’re making progress.

Source: Wikimedia Commons, https://commons.wikimedia.org/wiki/File:Conflict_Resolution_in_Human_Evolution.jpg

The fact that Red Hat Ceph Storage 2.3 was recognized as among those reflecting the latest trends in flash, cloud, and container technologies is a good sign that this is true. More important validation, however, comes from customers like Produban and UK Cloud, who are incorporating the product into broad Red Hat solutions. It also comes from those like Monash University and CLIMB, who can appreciate improvements to versatility, connectivity, and flexibility, like the NFS gateway to an S3-compatible object interface, compatibility testing with the Hadoop S3A plugin, and a containerized version of the product.

Even more uplifting from a user perspective today is the fact that v2.3 has already been superseded by Red Hat Ceph Storage 3, a more substantive advance into the realm of object storage that addresses a few key customer requirements while making adoption less challenging. For example, the product rounded its value as a cost and resource-saving unified storage platform with full support for file-based access (CephFS) and links to legacy storage environments through iSCSI. Containerization was advanced to include CSDs, enabling nearly 25% hardware deployment savings and more predictable performance through the co-location of storage daemons. And we added a snazzy new monitoring interface and additional layers of automation to make deployments more self-maintaining. According to Olivier Delachapelle, Head of Data Center Category Management EMEIA at Fujitsu, “Red Hat Ceph Storage 3 is probably the most advanced software-defined storage solution combining extreme scalability, inherent disaster resilience, and significant price-capacity value.     

Snapshot of Red Hat Ceph Storage management console, top-level interface

In the end, we feel good about the public recognition, but we feel even better when our customers and partners are happy and have what they need to succeed. I encourage you to share your thoughts about where we’re on target and/or perhaps missing the boat. Ultimately, being part of an IT company means our storage solution can serve a role that was perhaps unimaginable before, and it supports our commitment to real-world deployment of the future of storage.  

 

The rise of object storage in the modern datacenter

Red Hat Ceph Storage 3 greatly advances object storage capabilities

By Uday Boppana, Red Hat Storage

From speaking with customers across industry verticals and geographies, Red Hat is finding that object storage is increasingly top of mind as enterprises address growing data volumes, regulatory pressure, and threats to data security.

Take financial services firms, for instance. Their IT teams fight multiple fires trying to appease internal and external stakeholders in a fast-moving industry. They are expected to provide lines of business with cost-effective, cloud-like services, from development frameworks, storage backup, archive, to sync and share, while also bridging the traditional in-house banking applications with a plethora of cloud-native applications–and deploying all of them on a single storage platform to reduce costs. Satisfying these challenging goals requires a scalable, on-prem storage platform that can also be extended across hybrid cloud deployments–something that cannot be satisfied through traditional file or block storage solutions.

Red Hat Ceph Storage 3 offers a unified, petabyte-scale solution that addresses these pain points. The newest release, announced late last year, adds much in terms of scalability, security features, ease of management, and lowered costs. It also enhances the multiprotocol support for file and  object storage interoperability and migration that was introduced in Red Hat Ceph Storage 2.

Cost-effective private cloud backups

Red Hat Ceph Storage 3 helps customers modernize their backup infrastructures and reduce the cost of data backups for private cloud infrastructure through certified interoperability with Veritas NetBackup and Rubrik Cloud Data Management. These software offerings will back up to a Red Hat Ceph Storage cluster using its AWS-compatible S3 API. Details on supported versions are listed in the product’s compatibility guide.

Better scale for file workloads, at lower cost

The benefits of object storage as a data storage platform are well documented, making possible increased reach and applicability of object storage to a variety of workloads. Expanded support of its NFS gateway for RGW to include NFS V3 in addition to V4 means Red Hat Ceph Storage users can now gradually transition most NFS file workloads to a modern, scalable, object storage platform without disruption, with full migration only when their applications, tools, and management processes are ready.

Increased security for data assets

Red Hat Ceph Storage 3 enables greater data security for at-rest data and enables permanent data deletion. Object granular encryption is supported for data at-rest using user-provided keys. This functionality can also be used to permanently delete an object by encrypting the object  and shredding the key before deleting the object.

Reduced storage costs by eliminating redundant object data

Inline, object granular compression means being able to eliminate redundant data within an object before saving it to the disk and saving storage costs. The compression operation happens in-line as data is written to RGW from the hosts, before saving it to the disk.

Simpler data lifecycle management

Red Hat Ceph Storage 3 eases storage and data management through a policy-based S3 API framework for bucket and object lifecycle management. The Red Hat Ceph Storage object access API is fully compatible with AWS S3 API and now adds support for S3 bucket lifecycle API for object and version expiration.

The web-scale modern datacenter

In sum, as the modern datacenter relies more on web-scale infrastructure, object storage can help organizations bring to bear much of the value in other digital transformation efforts in the development and applications space. As the hybrid cloud becomes a mainstream reality, standardizing on a scalable object-storage solution that can span on-prem, private, and public clouds becomes more imperative to the success of the modern enterprise.

For more on the new and exciting features in Red Hat Ceph Storage 3, check out this blog post by Federico Lucifredi in our “Architects’ Corner.”

Why traditional storage doesn’t cut it in the new world of containers

By Steve Bohac, Red Hat Storage

Persistent storage for containers is a hot topic these days. While containers do a great job of storing application logic, they do not offer a built-in solution for storing application data across the lifecycle of containers. Ephemeral (or local) storage is not enough–Stateful applications require that the container data be available beyond the life of the containers. They also require that the underlying storage layer provide all the enterprise features available to applications that are deployed in, say, virtualized environments.

Another important consideration is that because many view containers as the next step in the evolution of server virtualization, it’s critical to provide persistent storage options to administrators because hypervisors have always allowed for persistent storage in one form or the other.

One approach is to use traditional storage appliances that support legacy applications. This is a natural inclination and assumption, but… the wrong one.

Traditional storage appliances are based on decades-old architectures at this point and were not made for a container-based application world. These approaches also fail to offer the portability you need for your apps in today’s hybrid cloud world. Some of these traditional storage vendors offer additional software for your containers, which can be used as a go-between for these storage appliances and your container orchestration, but this approach still falls short as it is undermined by those same storage appliance limitations. This approach would also mean that storage for the container is provisioned separately from your container orchestration layer.

There’s a better way! Storage containers containing storage software co-­reside with compute containers and serve storage to the compute containers from hosts that have local or direct-attached storage. Storage containers are deployed and provisioned using the same orchestration layer you’ve adopted in house (like Red Hat OpenShift Container Platform, which is Kubernetes based), just like compute containers. In this deployment scenario, storage services are provided by containerized storage software (like Red Hat Container-Native Storage based on Red Hat Gluster Storage) to pool and expose storage from local hosts or direct-attached storage to containerized applications.

Red Hat Container-Native Storage for Red Hat OpenShift Container Platform is built with Red Hat Gluster Storage and is flexible, cost-effective, and developer-friendly storage for containers. It helps organizations standardize storage across multiple environments and easily integrates with Red Hat OpenShift to deliver a persistent storage layer for containerized applications that require long-term storage. Enterprises can benefit from a simple, integrated solution including the container platform, registry, application development environment, and storage–all in one, supported by a single vendor.

To hear from one customer who implemented a Red Hat Container-Native Storage solution, please check out our Brinker International case study. Also, take our solution for a free test drive and see for yourself.

If you–like we are–attending KubeCon and CloudNativeCon in Austin, Texas, this week, we’d love to take a minute to meet with you and talk about Red Hat Container-Native Storage. Stop by the Red Hat booth (D1, near the Hub Lounge) or attend one of our sessions devoted to container storage to learn more about running Red Hat Container-Native Storage for your container-based application platform. Also, our own Steve Watt from the Red Hat Office of the CTO will be speaking from the show on theCube tomorrow, December 7, as well. If you’re not able to make it to Austin, please find us at a roadshow event coming to a city near you.

Red Hat Ceph Storage 3: Featuring CephFS and iSCSI support and containerized storage daemons

By Douglas Fuller, Red Hat Ceph Storage Engineering

If you missed last week’s huge announcement about Red Hat Ceph Storage 3, you can find details here. To quickly get you up to speed, though, the big news in this release is around enabling a large variety of storage needs in OpenStack, easing migration from legacy storage platforms, and deploying enterprise storage in Linux containers.

CephFS is here!

One of the highlights of the Red Hat Ceph Storage 3 announcement was production support for CephFS. This delivers a POSIX-compliant shared file system layered on top of massively scalable object storage. Client support is available in the Red Hat Enterprise Linux 7.4 kernel and via FUSE. CephFS leverages Ceph’s RADOS object store for data scalability as well as a natively clustered metadata server (MDS) for metadata scalability, high availability, and performance.

One cluster to do it all

Red Hat Ceph Storage uses the CRUSH structured data distribution scheme, enabling users to deploy a highly scalable and reliable file system using industry-standard, commodity hardware. Expensive, custom-engineered RAID controllers are no longer necessary. Expanding a CephFS deployment is as easy as expanding a Ceph cluster—CRUSH smoothly manages cluster changes, including expansions with new or different hardware.

Have a hybrid storage cluster with SSDs, HDDs, and NVMe devices? CRUSH can divide your storage workload across any and all devices for maximum performance where you need it and maximum capacity at commodity cost where you don’t. This allows disparate workloads—such as scratch, home, or archive data—to coexist in the same cluster using different or overlapping hardware as needed.

In addition, CephFS’s MDS may be dynamically provisioned and resized online to maximize performance and scalability. For metadata-intensive workloads, the Ceph MDS cluster can repartition its workload, either statically or dynamically, online in response to demand. It’s also fault-tolerant by design, with no need for passive standby or expensive and complex “Shoot the Other Node in the Head” (STONITH) configurations to maintain constant availability.

Take the “cluster” out of cluster management

Red Hat Ceph Storage 3 deploys with Red Hat Ansible Automation, integrating smoothly into existing cluster management environments. Now you can deploy and manage compute and storage both using Ansible playbooks.

New in Red Hat Ceph Storage 3 is a REST API for cluster data and management tools. Monitoring tools are available out of the box to provide detailed health and performance data across your Ceph cluster.

A million uses and counting

Red Hat Ceph Storage offers great flexibility to customers. It can be deployed across a wide variety of storage applications, allowing enterprises to manage one unified system supporting block, file, and object interfaces. With the added flexibility of iSCSI support, users from heterogeneous environments—such as VMware and Windows—can leverage the power of the storage platform.

This flexibility is extremely attractive to organizations such as academic research institutions, many of which are participating in the SuperComputing17 conference in Denver this week. Their IT departments have the onerous task of supporting complicated workflows and yet have to work with shoestring budgets in many cases.

To learn more, check out this additional blog post, and join us at the Red Hat SC17 booth (1763) for presentations, swag, and more.

Gartner pegs Red Hat as storage visionary. Two years in a row.

Red Hat Storage strengthens position relative to key competitors

It’s finally here! The Gartner 2017 Magic Quadrant for Distributed File Systems and Object Storage.

We’re extremely excited to announce that Gartner has once again positioned Red Hat in the “Visionaries” quadrant. More important, Red Hat is the furthest to the right and top in the visionary quadrant since last year’s Magic Quadrant. Gartner’s Magic Quadrant judges vendors on completeness of vision and ability to execute.

We are humbled and excited with this new development. It corroborates key investments and strategic product decisions taken over the years by our leadership to deliver tangible and substantial value to customers. The relative movement of Red Hat vis-à-vis established storage vendors tells a compelling story about the rapidly changing enterprise storage landscape.

Some of the key highlights from the past year include:

  • Continued leadership with container-native storage to enable a unified storage platform for cloud-native applications and container infrastructure.
  • Customer traction across geographies and industry verticals that brings to bear Red Hat’s vision of storage for the open hybrid cloud.
  • Strong leadership in upstream open source communities for private cloud infrastructure and Infrastructure as a Service (IaaS), as well as enterprise adoption of highly elastic object storage.
  • Breakthrough innovation around open source hyperconverged infrastructure for remote-office/branch-office and IoT use cases.

You can download a complimentary copy of the Gartner 2017 Magic Quadrant for Distributed File Systems and Object Storage here.

Container-native storage for the OpenShift masses

By Daniel Messer, Red Hat Storage

 

Red Hat Container-Native Storage 3.6, released today, reaches a new level of storage capabilities on the OpenShift Container Platform. Container-native storage can now be used for all the key infrastructure pieces of OpenShift: the registry, logging, and metrics services. The latter two services come courtesy of the new block storage implementation. Object storage is now also available directly to developers in the form of the well-known S3 API. Administrators will enjoy a more robust cns-deploy utility, support for online volume expansion, and more choice in deployment topologies in the OpenShift Advanced Installer. Last, but just as important, it now supports more concurrent workloads serving over 1,000 persistent volumes with just 3 nodes.

________________________________________

You know you must be doing something right when some of your users are looking to use your technology in different ways than expected. Initially, the idea of running GlusterFS alongside Kubernetes and OpenShift promised the ability to use a distributed storage system with a framework for distributed applications. They goes nicely together because both approaches are entirely based on scale-out software, hence independent of the underlying platform, and they are driven by a declarative API-driven design. On the GlusterFS side, that API is available in the form of an additional software daemon, called heketi. Things soon took a new direction when the first experiments of running the GlusterFS/heketi combination as an OpenShift workload were conducted.

A lot of engineering cycles later, the idea of hacking GlusterFS onto OpenShift has emerged to a fully supported product offering: container-native storage. Today, we are happy to announce container-native storage 3.6.

For the impatient: In essence, we have taken container-native storage from being an optional supplement in OpenShift to being a storage solution that now serves file, block, and object storage to applications on top of OpenShift and to the entire OpenShift internal infrastructure, as well.

For the curious reader, let’s go see how we did that….

Increase density

The first thing we had to do was ensure that container-native storage was a robust, scalable, long-term solution for the different possible OpenShift cluster sizes. When we launched container-native storage with OpenShift 3.2 last summer, the container images were based on Red Hat Gluster Storage 3.1.3 and, on average, each brick process on a GlusterFS host/pod consumed about 300 MB of RAM.

That may not sound like much, but you have to be aware that every PersistentVolume served by container-native storage results in a GlusterFS volume being created. Bricks are local directories on GlusterFS pods that make up volumes. The consistency of volumes across all its bricks (by default, 3 in container-native storage) is handled by the glusterfsd process, which is what consumes the memory.

In older releases of Red Hat Gluster Storage, there was one such process per brick on each host. It’s easy to see that with potentially hundreds of application pods in OpenShift requiring their own PersistentVolumes, the resulting number of brick processes in each GlusterFS pod will easily consume gigabytes of RAM and would create a significant effort to coordinate in each pod.

That many processes in a pod are an anti-pattern for Kubernetes and, even if we would have broken out those in separate containers, the memory overhead would still be huge.

Fortunately, Red Hat Gluster Storage 3.3 came to the rescue. Released just a little over 2 weeks ago, it introduced a new feature called brick-multiplexing. It’s easier to depict how this feature changes the structure of a GlusterFS pod in a diagram than a lengthy explanation:

With brick-multiplexing, only one glusterfsd process is governing the bricks such that the amount of memory consumption of GlusterFS pods is drastically reduced and the scalability is significantly improved.

By introducing brick-multiplexing in version 3.6, we are able to support over 1,000 PersistentVolumes in a single container-native storage cluster. The amount of memory consumed increases linearly, so that 32GB of RAM are only needed at the high end of that. The rule of thumb is roughly 30-35 MB RAM per volume on each of the participating GlusterFS pods.

Container-native storage can probably support an even greater number of volumes, and we hope to confirm that soon. Until then, you always have the option to either run more GlusterFS pods in your OpenShift cluster or deploy a second container-native storage cluster, governed by the same Heketi API service.

Optimized storage for logging/metrics

File storage is what containers on OpenShift (and in general) deal with today. It’s a ubiquitous, well-understood concept. There are also proposals for native access to block devices in pods, but they are still in design or planning phases.

That is—at least for now—storage (including block) in Kubernetes and OpenShift always ends up being a mounted file system on the host running the pod, which is then bind-mounted to the target container’s file system namespace. Block storage provisioners in OpenShift eventually format the device with XFS too, before handing it over to the container.

GlusterFS is a distributed, networked file system which, in contrast to local filesystems like XFS, allows shared access from multiple hosts and stores the data in the backend distributed across multiple nodes. This big advantage does not come without cost, however: Some type of operations that are fast and cheap on a local file system are quite expensive in a distributed file system.

For some workloads (e.g., OpenShift Logging and Metrics), this can be a show-stopper. To properly support those, we designed something that might seem counter-intuitive at first: gluster-block. Take a look at the implementation scheme below:

Yes, you see that right: We are using TCM (the Linux kernel’s iSCSI stack, also called LIO) managed by targetcli to create iSCSI LUNs from files on a GlusterFS volume and present those as block devices to pods. The TCM stack allows local storage of a Linux system to be made available on the network via the iSCSI protocol. In our specific case, the local storage is a large raw file on a GlusterFS volume. On the client side, the iSCSI block device will be formatted with XFS and then bind-mounted to the target container’s file system namespace.

But why go through all the trouble? In distributed file systems—and here GlusterFS is no exception—metadata-intensive operations like file create, file open, or extended attribute updates are particularly expensive and slow compared to a local file system. In particular, indexing solutions likes ElasticSearch (part of OpenShift Logging) and scale-out NoSQL databases like Cassandra (part of OpenShift Metrics) generate such workloads.  But also other database software might make heavy use of locking and byte-range locking, which are costly compared to simple read and writes.

In order to qualify OpenShift Metrics and Logging Services to run well on a container-native storage backend, a significant speed up was needed for a lot of special file system operations like these.

You can probably guess what we were thinking: In software, many problems can be solved by adding an additional layer of indirection.

The indirection in accessing data on GlusterFS via iSCSI instead of a normal GlusterFS mount converts otherwise expensive file system operations to a single stream of continuous reads and writes to a single raw file on GlusterFS. The TCM stack delivers this IO stream over the network via iSCSI. On the receiving end, the file in GlusterFS backing the iSCSI LUN is accessed via libgfapi, a userspace library to access files in GlusterFS without the need to mount a volume.

The clients, in our case containers in pods on OpenShift, still write to an XFS file system the iSCSI LUN is formatted with. As a result, simple client-level read and write requests remain virtually as fast as accessing the file directly on GlusterFS, but also all the other file system operations are converted into much faster reads and writes to the file backing the block volume because they are not distributed. From the perspective of GlusterFS, it’s a constant stream of basic read and write requests, which GlusterFS is efficient at. Of course, this comes with a trade-off: gluster-block is not shared storage.

Container-Native Storage version 3.6 now provides backend storage for OpenShift Logging and OpenShift Metrics with gluster-block. For the moment, the use of gluster-block in production is only supported for OpenShift Logging and Metrics services, but use of gluster-block beyond that is under qualification, and support is expected to be extended soon.

The Logging and Metrics services have strict performance and latency requirements and are important for any OpenShift cluster in production. They provide vital information and debugging capabilities for administrators. By design, they are scale-out services, because their storage backend (ElasticSearch for Logging, Cassandra for Metrics) supports a shared-nothing approach. However, in production you do not want additional shards of ElasticSearch and Cassandra run side-by-side with your application pods. That’s why there is a concept of infrastructure nodes in OpenShift that do not run business applications but are dedicated to OpenShift infrastructure components like these. Typically, these kind of servers only have storage locally available, which is limited in capacity and performance. Thus, it might quickly become insufficient to store the logs and metrics of hundred of pods. With container-native storage, you now have a scalable, robust, and long-term storage solution for logging and metrics that utilizes the entire cluster’s storage capacity.

Support a scale-out registry

There is one additional component in OpenShift that’s crucial for operations: the container image registry. This is where all the resulting images from source-to-image builds will be pushed to and where developers can upload their custom images. If it’s unavailable, those operations will fail, and users will be unable to launch new or update existing applications.

The default configuration for the OpenShift registry is to use `emptyDir` storage, that is, a local file system on the container host that depends on the registry pod’s lifetime. In this setup, the registry, of course, cannot be scaled out, updated, or restarted on another host.

Fortunately, as of version 3.5, container-native storage allows for a scale-out registry using shared storage on a PersistentVolume served by GlusterFS. This has several advantages:

  1. No external storage is required, like NFS, which can cause problems with metadata consistency with a busy registry.
  2. There is no dependency on provider storage (e.g., AWS S3 being unavailable in a VMware environment) for shared data access.
  3. The registry can now be scaled out, ideally across all infra nodes.
  4. The registry storage backend can grow dynamically with the platform.

The beauty of this is that it can be installed like this right away. Like we’ve already covered during the announcement of OpenShift Container Platform 3.6 earlier this year, the OpenShift Advanced Installer now supports deploying container-native storage and the registry on container-native storage out of the box. See this video here for details.

All you have to do since OpenShift Container Platform 3.6 is add a few lines to your Ansible inventory file.

To deploy an OpenShift registry backed by container-native storage, first add the following variable definition in the [OSEv3:vars] section:

openshift_hosted_registry_storage_kind=glusterfs

And then add a new host group defining the container-native storage nodes to the inventory, for example:

[glusterfs_registry]
infra-1.lab glusterfs_devices='[ "/dev/sdd" ]'
infra-2.lab glusterfs_devices='[ "/dev/sdd" ]'
infra-3.lab glusterfs_devices='[ "/dev/sdd" ]'

This is enough to tell the OpenShift Advanced Installer that it should create a basic 3-node container-native storage cluster, in this case on the infrastructure nodes, using the supplied devices to create bricks. From this cluster a PersistentVolume will be created and supplied to the registry DeploymentConfig.

That way the registry will be launched with shared storage, provided by container-native storage, and scaled to 3 instances across the infrastructure nodes. You get a highly available and robust registry out of the box with no additional configuration needed.

S3 object storage for applications

In addition to providing block and file storage services, Container-Native Storage 3.6 now provides an S3 object storage interface as a TechPreview. Application developers have a ready-to-use REST API at hand to provide object storage to workloads on OpenShift, just a HTTP PUT or GET request away.

Object storage in Red Hat Container-Native Storage 3.6 provides a simple yet scalable storage layer for distributed applications that were previously tied to specific cloud provider S3 object storage. These application now run with little or no modification on OpenShift.

In this implementation, a gluster-s3 service is deployed as a pod in your OpenShift cluster, and an OpenShift Route is generated for it. The Route’s URL is provided to applications as their S3 endpoint. The service receives the S3 requests and translates those to file system operations on GlusterFS volumes. The S3 buckets and objects are stored as directories and files on that volume, respectively.

For now, this service can be deployed with the cns-deploy utility. There are some new command switches available for this purpose:

cns-deploy topology.json --namespace gluster-storage --log-file=cns-deploy.log --object-account dmesser --object-user dmesser --object-password redhat

The new parameters allow you to specify a name for the S3 account (object-account, an aggregate of multiple S3 buckets, one per CNS cluster), a named user (object-user), and the authentication password for that user in that account (object-password). Once all of these 3 switches are presented, cns-deploy will create the glusterfs-s3 infrastructure.

Support for doing this with the OpenShift Advanced Installer is expected to follow soon. The design foresees exactly one S3 domain/account per CNS cluster, although multiple CNS clusters can be deployed easily.

Improvements for deployment and operations

Besides a whole bunch of new features, we’ve also introduced improvements in usability to make the container-native storage experience better.

In Container-Native Storage 3.6, the cns-deploy tool has been improved in a number of ways. It is now more idempotent, allowing the administrator to run the installer multiple times without having to start from scratch. There will still be error scenarios that may require manual intervention, but it should be much easier to recover from such errors. It will also deploy the required resources to use gluster-block and gluster-s3. Combined with the idempotency improvements, administrators will be able to run cns-deploy to deploy those features into an environment that’s already running container-native storage.

Container Native Storage 3.6 also provides improved integration with container-ready storage. All of our new features will work just as well on container-ready storage as container-native storage. In addition, we have introduced support for a configuration we’re calling Container-Ready Storage without Heketi. heketi is the volume management API service for GlusterFS. In this configuration, container-ready storage runs with the usual Red Hat Gluster Storage nodes outside the OpenShift cluster, but heketi resides as a pod within OpenShift. This has the advantage of making the heketi service highly available rather than residing on a single machine. For new deployments, the cns-deploy can be used to initialize a container-ready storage cluster in this configuration.

Another common scenario that is likely to occur over time, even with the short-lived nature of some workloads, is PersistentVolumes filling to capacity. This can happen when a user under-estimates the required capacity for a workload or the pod simply runs way longer than expected. In any case, heketi now allows for online volume expansion.

To take advantage of this, simply use the heketi-client on the CLI to expand the size of any given volume:

heketi-cli volume expand --volume=0e8a8adc936cd40c2df3698b2f06bba9 --expand-size=2

In the background, heketi changes the GlusterFS volume layout from a 3-way replicated to distributed-replicated. See below for a comparison from GlusterFS perspective.

Before volume expansion:

sh-4.2# gluster vol info vol_0e8a8adc936cd40c2df3698b2f06bba9

Volume Name: vol_0e8a8adc936cd40c2df3698b2f06bba9
Type: Replicate
Volume ID: 841bd097-659b-4b5d-b3ec-56bb8cc51c2f
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x 3 = 3
Transport-type: tcp
Bricks:
Brick1: 10.20.5.232:/var/lib/heketi/mounts/vg_c05319c8a95eaa083adbedb7d43913fa/brick_4bf9ae183dacceccf4bf525186850bdd/brick
Brick2: 10.20.6.239:/var/lib/heketi/mounts/vg_bd7fbf9053d6340771f7b75ce2872339/brick_e1175aaaa8596aedc18bf8c56b42fe8d/brick
Brick3: 10.20.4.184:/var/lib/heketi/mounts/vg_0797a1d458309eec3e5e818a9b87f6c6/brick_2b5255cc2c0297e4e34eb6f1b4319fb9/brick
Options Reconfigured:
transport.address-family: inet
nfs.disable: on
cluster.brick-multiplex: on

After volume expansion:

sh-4.2# gluster vol info vol_0e8a8adc936cd40c2df3698b2f06bba9

Volume Name: vol_0e8a8adc936cd40c2df3698b2f06bba9 
Type: Distributed-Replicate 
Volume ID: 841bd097-659b-4b5d-b3ec-56bb8cc51c2f 
Status: Started 
Snapshot Count: 0 
Number of Bricks: 2 x 3 = 6 
Transport-type: tcp 
Bricks: 
Brick1: 10.20.5.232:/var/lib/heketi/mounts/vg_c05319c8a95eaa083adbedb7d43913fa/brick_4bf9ae183dacceccf4bf525186850bdd/brick 
Brick2: 10.20.6.239:/var/lib/heketi/mounts/vg_bd7fbf9053d6340771f7b75ce2872339/brick_e1175aaaa8596aedc18bf8c56b42fe8d/brick 
Brick3: 10.20.4.184:/var/lib/heketi/mounts/vg_0797a1d458309eec3e5e818a9b87f6c6/brick_2b5255cc2c0297e4e34eb6f1b4319fb9/brick 
Brick4: 10.20.6.239:/var/lib/heketi/mounts/vg_bd7fbf9053d6340771f7b75ce2872339/brick_c48d4ea4b43635f62c464ddf0259d733/brick 
Brick5: 10.20.4.184:/var/lib/heketi/mounts/vg_0797a1d458309eec3e5e818a9b87f6c6/brick_121fbc266c905311d8a8810f221fbdca/brick 
Brick6: 10.20.5.232:/var/lib/heketi/mounts/vg_c05319c8a95eaa083adbedb7d43913fa/brick_5f208c680444b4820f53c923aa079614/brick 
Options Reconfigured: transport.address-family: inet nfs.disable: on cluster.brick-multiplex: on 

Finally, with Container-Native Storage 3.6, we have expanded the amount of technical documentation available. We provide more examples of things both new and pre-existing that you can do with container-native storage, as well as detailed upgrade procedures from a variety of configurations to make sure you can get the latest set of features.

Verdict

The storage play for containers is an exciting space at the moment. There are many options available for customers, and Red Hat container-native storage is unique in the way it runs natively on OpenShift and provides scalable shared file, block, and object storage to business applications and container platform infrastructure.

OpenShift Container Platform 3.6: Streamlined installation and configuration of Red Hat Gluster Storage for containers

By Erin Boyd, Jose Rivera, and Scott Creeley, Red Hat

Did you ever get a new, exciting toy only to have that excitement squashed by the phrase “Batteries not included”?

With the introduction of Red Hat OpenShift Container Platform 3.6, no longer will customers have to wait or jump extra hurdles to get resilient, persistent storage with their new installations. Now they can more easily deploy Red Hat Gluster Storage ready for use by their containerized applications—This is PaaS with batteries included!

With the release of Red Hat OpenShift Container Platform 3.6, users will have the convenience of using a single tool to use Red Hat Gluster Storage as either container-native storage (CNS) or container-ready storage (CRS) alongside the rest of their OpenShift installations. As part of the OpenShift Advanced Installation, users can specify two new storage options: Red Hat Gluster Storage for (1) hosted registry storage or (2) general application storage. To facilitate evaluation of these, an Openshift Container Platform evaluation subscription now includes Red Hat Gluster Storage evaluation binaries and subscriptions.

Following is a sample inventory file that would be used with an OpenShift Container Platform Advanced Installation that deploys two CNS clusters for both hosted registry storage and general application storage.

[OSEv3:children]
 masters
 nodes
 glusterfs_registry
 glusterfs

[OSEv3:vars]
 ansible_ssh_user=root
 openshift_master_default_subdomain=cloudapps.example.com
 openshift_deployment_type=openshift-enterprise
 openshift_hosted_registry_storage_kind=glusterfs
 openshift_disable_check=disk_availability,memory_availability

[nodes]
 master1 node=True storage=True master=True openshift_schedulable=False
 node1 node=True storage=True openshift_node_labels="{'region': 'infra'}"
 openshift_schedulable=True
 node2 node=True storage=True openshift_node_labels="{'region': 'infra'}"
 openshift_schedulable=True
 node3 node=True storage=True openshift_node_labels="{'region': 'infra'}"
 openshift_schedulable=True
 node4 node=True storage=True openshift_schedulable=True
 node5 node=True storage=True openshift_schedulable=True
 node6 node=True storage=True openshift_schedulable=True

[glusterfs_registry]
 node1 glusterfs_devices="[ '/dev/xvdc' ]"
 node2 glusterfs_devices="[ '/dev/xvdc' ]"
 node3 glusterfs_devices="[ '/dev/xvdc' ]"

[glusterfs]
 node4 glusterfs_devices="[ '/dev/xvdc' ]"
 node5 glusterfs_devices="[ '/dev/xvdc' ]"
 node6 glusterfs_devices="[ '/dev/xvdc' ]"

[masters]
 master1 node=True storage=True master=True openshift_schedulable=False

Let’s go over the highlighted portions in detail.

The first section defines the host groups the installation will be using. We’ve defined two new groups: (1) glusterfs_registry and (2) glusterfs. The first specifies a cluster that will host a single volume for use exclusively by a hosted registry. The second specifies a cluster for general application storage and will, by default, come with a Storage Class to enable dynamic provisioning.

[OSEv3:children]
 masters
 nodes
 glusterfs_registry
 glusterfs

In the following section, we indicate that we want the hosted registry to use Red Hat Gluster Storage for its storage needs.

[OSEv3:vars]
 ansible_ssh_user=root
 openshift_master_default_subdomain=cloudapps.example.com
 openshift_deployment_type=openshift-enterprise
 openshift_hosted_registry_storage_kind=glusterfs
 openshift_disable_check=disk_availability,memory_availability

In the [nodes] section, we need to specify all nodes in the OpenShift Container Platform cluster. For our installation, we also need to specify which nodes will run pods for the hosted registry. This is done by specifying “openshift_node_labels=”{‘region’: ‘infra’}”” for each such node. It is recommended to have at least three nodes running your hosted registry.

[nodes]
 master1 node=True storage=True master=True openshift_schedulable=False
 node1 node=True storage=True openshift_node_labels="{'region': 'infra'}"
 openshift_schedulable=True
 node2 node=True storage=True openshift_node_labels="{'region': 'infra'}"
 openshift_schedulable=True
 node3 node=True storage=True openshift_node_labels="{'region': 'infra'}"
 openshift_schedulable=True
 node4 node=True storage=True openshift_schedulable=True
 node5 node=True storage=True openshift_schedulable=True
 node6 node=True storage=True openshift_schedulable=True

Now we get to our new sections where we specify the nodes that will be used for storage. CNS and CRS require that each cluster have a minimum of three nodes. Multiple clusters can not share a given node. Because we are deploying two clusters, we need to specify six nodes total. It is also required that each node have at least one dedicated, bare storage device (no data or formatting of any kind) for exclusive use by Red Hat Gluster Storage.

Our first new section is [glusterfs_registry]. Here we specify the nodes of the Red Hat Gluster Storage cluster and the storage devices on those nodes that will be used for a hosted registry’s storage. It is not required that these nodes be the same as the ones running the hosted registry.

[glusterfs_registry]
 node1 glusterfs_devices="[ '/dev/xvdc' ]"
 node2 glusterfs_devices="[ '/dev/xvdc' ]"
 node3 glusterfs_devices="[ '/dev/xvdc' ]"

Our second new section, [glusterfs], is used for specifying the Red Hat Gluster Storage cluster and storage devices that will be used for general application storage. These storage devices must also be for exclusive use by Red Hat Gluster Storage. As mentioned, these nodes may not also be part of the cluster used by [glusterfs_registry]. In the case of CNS, it is not required that these nodes be dedicated exclusively to serving storage; CNS pods can coexist with other application pods.

[glusterfs]
 node4 glusterfs_devices="[ '/dev/xvdc' ]"
 node5 glusterfs_devices="[ '/dev/xvdc' ]"
 node6 glusterfs_devices="[ '/dev/xvdc' ]"

Once the installer is complete, the user can see the pre-defined Storage Class by executing:

# oc get storageclasses
 NAME TYPE
 glusterfs-storage kubernetes.io/glusterfs

This Storage Class can be used for applications by specifying a Persistent Volume Claim to dynamically provision the required storage volume:

apiVersion: v1
 kind: PersistentVolumeClaim
 metadata:
 name: mypvc
 namespace: glusterfs
 spec:
 accessModes:
 - ReadWriteOnce
 resources:
 requests:
 storage: 100Gi
 storageClassName: glusterfs-storage

And that’s it, your PaaS solution with built-in storage is ready to go! If you want to tune the installation further, more options are available in the Advanced Installation, and a demo video is available here.

Introducing Red Hat Hyperconverged Infrastructure 1.0

By Steve Bohac, Red Hat Storage

Today we’re proud to announce Red Hat Hyperconverged Infrastructure 1.0! By combining Red Hat virtualization and storage technologies with a stable, proven operating platform, Red Hat Hyperconverged Infrastructure is designed to help enterprises bring datacenter capabilities into locations with limited space, such as branch offices and other remote facilities.

Built on Red Hat Virtualization and Red Hat Gluster Storage, Red Hat Hyperconverged Infrastructure provides simplified planning and procurement, streamlined deployment and management, and a single support stack for virtual compute and virtual storage resources. Red Hat Hyperconverged Infrastructure is an ideal solution for remote/branch office or edge computing needs. Deployment is enabled by Ansible by Red Hat, and Red Hat CloudForms can be used to manage all the Red Hat Hyperconverged Infrastructure installations in your enterprise via a single application.

Customers have been asking us for this type of an integrated solution, so we’re happy to offer this hyperconverged combination in a single SKU to satisfy that request.

Organizations with distributed operations, such as those in the banking, energy, or retail industries, can benefit from offering the same infrastructure services in remote and branch offices as they run in their datacenters. However, remote and branch offices can have unique challenges: less space and power/cooling and fewer (or no) technical staff on site. Organizations in this situation need powerful services, integrated on a single server that allow them to keep their key applications local to the remote site.

Red Hat Hyperconverged Infrastructure addresses these challenges for remote installations. The following figure depicts the benefits that consolidation with a hyperconverged infrastructure provides:

  • Eliminate storage as a discrete tier
  • Easily virtualize business applications, maximizing resource utilization
  • Single budget for compute and storage
  • Single team managing infrastructure
  • Simplified planning and procurement
  • Streamlined deployment and management
  • Single support stack for compute and storage

Removing the storage tier by consolidating compute and storage onto a single server platform/tier offers streamlined deployment and management (enabled by Ansible by Red Hat and Red Hat CloudForms), a single support stack (one vendor to call now instead of two), and simplified planning and procurement (reducing the number of vendors to source from).

For more information on Red Hat Hyperconverged Infrastructure, click here.

For an on-demand webinar discussing Red Hat Hyperconverged Infrastructure in more detail, click here.

Storage can make your digital transformation—or break it

By Ross Turk, Red Hat Storage

The following chart might look familiar, especially if you’ve ever studied patterns of online behavior.

Like all the best charts, this one has a glorious up-and-to-the-right shape. But each year at the end of December, when much of the world goes offline for a few quiet days, there’s a characteristic drop. This chart—from Google Trends—represents a phrase that’s growing in prominence: “digital transformation.”

Digital transformation is everywhere

When I noticed—with distinct déjà vu—the industry using this phrase, I admit I was somewhat taken aback. Many of us live in a world dominated by technology. I can’t remember the last time I paid for fast-food tacos with actual money, but I do know I stopped carrying cash completely when the taco shops began accepting credit cards. Every time I need to mail a letter now, it’s a huge production! I’m just not prepared for that kind of task anymore.

Imagine a world without digital technology…. See?! You can’t do it.

Not all digital transformation is equal

Another case in point. I renewed my driver’s license recently and found myself wondering: Now that the DMV is doing business using modern technology, who’s left to transform? If you live your life in an ivory tower made of wifi and capacitive touch screens—like me—a phrase like “digital transformation” can seem obsolete. It can throw you off the scent a bit. And, indeed, I was missing the point. Sure, even taxi companies embrace digital technologies these days…but are they any good at it? Do they enjoy the same efficiencies as a digitally native service like Uber?

Technology is now serious business

Digital transformation isn’t about using technology—or even offering digital services. It’s about redefining a business in technology terms, putting the modern technology experience first. It’s about businesses coming to terms with the truth: Technology can’t be a hobby for them anymore. They’re going to have a ton of applications and data, and they need to get really good at managing all of it. That means having solid priorities; agility and elasticity are a great place to start.

Modern storage can transform your business

Speaking of great places to start, there’s no better example of the challenges of digital transformation than storage. The amount of data that enterprises need to maintain is growing at a steady clip, and their customers expect all that data to be available instantly. Access patterns change as frequently as customer behaviors. Data is getting bigger, analytics are getting even more sophisticated. The traditional storage appliances that do a lot of the heavy lifting today are convenient, but at petabyte scale they show their inflexibility and limitation.

That’s where Ceph and Gluster come in. They’re flexible, scale-out, software-defined storage technologies built for those who don’t think storage is a hobby.

Learn how storage can make your digital transformation

If you want to learn more about modern approaches to storage—and Red Hat Storage, of course!—join me on June 22 for a 45-minute webinar. Register here.