General

5 more ways to break your Ceph cluster

5 more ways to break your Ceph cluster 1650 1100 Michiel Manten

While we’ve been working with customers using Ceph in a variety of ways, we have encountered some several ways to break your Ceph cluster. In that light, here is an update on five more ways to break your Ceph cluster as a continuation of the original presentation done by Wido den Hollander which is called; 10 ways to break your Ceph cluster ( https://youtu.be/oFDPKqMEb3w ). All of the ways to break your Ceph cluster are based on real events and experiences we have had with our clients and not on clinically based testing or so.

The first way to break your Ceph cluster on the list is: overestimating your automation tool. In the IT world we have been automating everything the last years. However, we see automation tools, work in different ways. They can work well, they can work mediocre, and they can work badly. Regardless, if you do not understand the tool you are automating (in this case Ceph), it’s going to be a problem. What we experienced is that we had a case where a script was ran in front of the automation. A variable that was supposed to have a 3 in it there, was missing. So, it became a 0 instead. Then, because it became a 0 the three monitors were just removed. Everything was confirmed by the script, and it just removed everything. To take it a step further, very thoroughly all the directory structures of monitor databases were also removed. To solve this, we were fortunately able to recreate the monitor database by scraping all the OSD’s and combining all that information into a new working monitor database. We created a new monitor and added additional monitors to that.

In another but similar case a user went into the backend and removed the monitors using the docker commands which resulted in a cluster without monitors. This was an administrative mistake, no blame to ‘cephadm’. After some digging, we were fortunately able to find the original monitor directories. So, we were able to restore monitor functionality. In short, understand what your automation tool is doing, why it is doing that and definitely understand what it shouldn’t do. You should also be aware that your automation tool should help you execute what you already know. If you want to use Ceph, you should understand Ceph. As an example, if you want to use Ceph and ceph-ansible you should understand Ceph and Ansible.

The second way to break your Ceph cluster is an old, but important step. We have encountered it a couple of times. We used to call it: ‘running with size=2’. However, we have revised it to running min_size=1. In short: we still recommend you run with at least three copies. But if you can’t, don’t ever go decrease your min_size to lower than 1, or better yet don’t decrease your redundant objects to ‘0’. Make sure you always write at least 1 redundant object. This is also true for Erasure Coding.

The third way is interesting: not fully completing an update. The documentation of Ceph is sometimes a little bit, let’s say, ‘petit’. There are some cases where in regard to the generic documentation of Ceph the upgrade is fully done. However, if you look at the release notes, a lot of steps are skipped or not even touched. We have had at least four cases in the last couple of years with the upgrades towards Nautilus for instance. The messenger version 2 had already been enabled, yet nobody upgraded the minimum OSD versions (require_osd_release). A lot of daemons are down, a lot of pgs are peering, remapped, stale. Really the cluster is not doing anything useful at this moment. It only takes one setting to adjust, to fix it all, which is setting your minimal OSD version to Nautilus, or Octopus if your cluster miraculously survived into your Octopus upgrade, which sometimes happens.

So, check your clusters:

·      ceph versions.

·      ceph osd dump|grep require_osd_release.

·      ceph mon dump.

The fourth way is completing an update too soon. This is one we have experienced recently. We had a client that was overly enthusiastic and set the ‘auth_allow_insecure_global_id_reclaim‘ setting before they upgraded all the clients and daemons. Which meant that some of the clients and RGW’s could not connect. Please make sure you don’t finish an upgrade too soon and make sure you really follow all the steps.

The fifth step is a big one. Running multiple rbd’s with the same id behind a load balancer. We had a customer who had 9 rbd’s but only configured 3. For each named rbd they had 3 processes running. They were all skipping over which one was active. Behind a load balancer this resulted in many millions of partial uploads that were not finished. Their entire cluster got full. Next, they added new hardware and were still adding new hardware. Luckily, we figured out this was the problem. To solve it we renamed 6 rbd’s, inventoried all the objects and made sure it was all cleaned up.

And a bonus one: blindly trusting your PG autoscaler. We, at 42on, love the PG autoscaler. Its’ a great addition to a Ceph cluster. We have had some trouble in the beginning with it where it seems that users were just installing clusters with default settings. It’s not until you inject data that you really find out that the PG’s weren’t configured well. You are injecting a lot of data but also splitting all your placement groups at the same time, resulting in very poor performance, eventually resulting in unhappy users. There is no real way to fix it unless you take action.

From the original 10 ways to break your Ceph cluster (I recommend you to look this presentation up). There is one that is 100% solved because of Bluestore: mounting XFS with the ‘nobarrier’ option. Because of Bluestore you don’t use XFS anymore. The other 9 however, we sometimes, sadly, still encounter.

Do you know any more ways to break your Ceph cluster from your own experiences? Please let us know in the comments.

42on at Ceph month!

42on at Ceph month! 1650 1100 Michiel Manten

With June already here, it is time for the annual Ceph month. Previously held as a conference and called Cephalocon, this year the event will be held online due to obvious reasons.

So, why Ceph month? Ceph month aims at bringing together engineers and architects with an interest in Ceph, software defined storage and data center storage infrastructure to collaborate and share their knowledge and opinions about the future of storage. During Ceph month, Ceph presentations, lightning talks, and unconference sessions such as BOFs (Beginning of File) will be held by various members of the Ceph community. We at 42on are actively involved in the Ceph community to share our knowledge with you. This year we have signed up to some technical lightning talk on which you can find some more information below:

–       June 14 | 1600 CEST: 5 more ways to break your Ceph cluster.

–       June 15 | 1500 CEST: RBD latency with QD=1 bs=4k.

–       June 16 | 1530 CEST: Qemu: librbd vs krbd performance.

The whole calendar can be found here: https://pad.ceph.com/p/ceph-month-june-2021

All our lightning talks will take no more than 5 minutes, after which there will be a five minute questions session. After the talk we will publish the subjects here and add some additional guidance. We might follow up here as well for any interesting questions that were asked during the session.

Presentation: ‘5 more ways to break your Ceph cluster’

Now, you might be wondering, why is it called 5 more ways to break your Ceph cluster, instead of 5 ways to break your Ceph cluster? The reason for that is that this lightning talk by colleague Wout van Heeswijk is an addition to a presentation held by Wido den Hollander 4 years ago. Back then he gave a presentation on 10 ways to break your Ceph cluster on a Ceph day in the Germany. The information he shared was gathered from his own first-hand experiences with clients and Ceph. So, in order to make sure you know what not to do with your Ceph cluster, before joining our presentation, here is a short summary of the 10 ways on breaking your Ceph cluster by Wido den Hollander.

1. Wrong CRUSH failure domain

2. Decommissioning a host.

3. Removing log files in MON’s data directory.

4. Removing the wrong pool.

5. Setting the noout flag for a long time.

6. Mounting XFS with nobarrier option.

7. Enabling Writeback on HBA without BBU.

8. Creating too many placement groups.

9. Using 2x replication.

10. Underestimating Monitors.

11: Updating Cephx keys with the wrong permissions.

For the full talk, see: https://www.youtube.com/watch?v=-FOYXz3Bz3Q

Since that talk of Wido we received a lot of feedback and follow up question from Ceph users about these issues. And of course the community has resolved a lot of those issues in new releases of Ceph. As we at 42on still support Ceph users with their operations and especially emergencies, we thought it would be time to update the list as well, working with more recent versions of Ceph.

RBD latency with QD=1 bs=4k

This year, Wido will home in on a question a lot of our customers face: What latency can we achieve with RBD when benchmarking with Queue Depth=1 and a blocksize of 4k? Many applications benefit from a low latency at low queue depths. And how can we improve this with the new persistent RBD cache?

With fio we can properly benchmark different configurations and see what we can achieve? These are all questions we will be covering during this lightning talk.

Qemu: librbd vs krbd performance

We have encountered several support customers that have questions regarding the performance of qemu in combination with Ceph RBD. It seems that the perception is that Ceph RBD storage could be faster. We have investigated this and will show that Ceph is in fact not the most likely bottle neck. Our test results show show vastly different I/O statsbetween qemu using librbd and qemu using krbd. We will share our tests and test configurations so members of the community can this as well and increase the level of knowledge on this issue and spark initiatives to resolve this to the benefit of all Ceph users. (stellen we een plek voor waar deze discussie wordt voortgezet en de testresultaten worden gedeeld?

So, now you know about the topics 42on will cover this Ceph month. Our presentation will be held by two of our Ceph experts Wido den Hollander and Wout van Heeswijk who are also active and enthusiastic participants of the Ceph community.

Join the Ceph community and 42on as we discuss how Ceph, the massively scalable, open-source, software-defined storage system, can radically improve the economics and management of data storage for your enterprise.

Which sessions do you plan to attend? Let us know and we will e-meet there!

A brief history on Ceph

A brief history on Ceph 2560 1440 Michiel Manten

Ceph has emerged as the leading distributed storage platform. By using commodity hardware and software-defined controls, Ceph has proven its worth as an answer to the scaling data needs of today’s businesses.

Ceph is a software-defined storage solution designed to address the object, block, and file storage needs of data centres adopting open source as the new norm for high-growth block storage, object stores and data lakes.

It allows storage to scale seamlessly. When properly deployed and configured, it is capable of streamlining data allocation and redundancy. Automated rebalancing ensures that data is protected in the event of hardware loss. New servers can be added to an existing cluster in a timely and cost-efficient manner. Fast and accurate read and write capabilities along with its high-throughput capacity make Ceph a popular choice for today’s object, block and file storage needs.

Back to the beginning. Ceph was conceived by Sage Weil during his doctoral studies at University of California in Santa Cruz. Weil realized that the accepted system of the time, Lustre, presented a “storage ceiling” due to the finite number of storage targets it could configure. Weil designed Ceph to use a nearly-infinite quantity of nodes to achieve petabyte-level storage capacity. Decentralized request management would improve performance by processing requests on individual nodes. In 2004, Weil founded the Ceph open source project to accomplish these goals. He released the first version 2006, and refined Ceph after founding his web hosting company in 2007.

The initial implementation provided the Ceph Filesystem (CephFS) in approximately 40,000 lines of C++ code. This was open sourced in 2006 under a Lesser GNU Public License (LGPL) to serve as a reference implementation and research platform. Lawrence Livermore National Laboratory supported Sage’s early follow-up work from 2003 to 2007.

DreamHost, a Los-Angeles-based web hosting and domain registrar company also co-founded by Sage Weil, supported Ceph development from 2007 to 2011. During this period Ceph as we know it took shape: the core components gained stability and reliability, new features were also added. In 2012 Inktank Storage was founded by Sage Weil and Bryan Bogensberger which back then was the lead development contributor and financial sponsor company behind the open source Ceph distributed file system. Inktank was initially funded by DreamHost, Citrix and Mark Shuttleworth. In 2014 Inktank was acquired by Red Hat.

In October 2015, the Ceph Community Advisory Board was formed to assist the community in driving the direction of open source software-defined storage technology. The charter advisory board includes Ceph community members from global IT organizations that are committed to the Ceph project, including individuals from Red Hat, Intel, Canonical, CERN, Cisco, Fujitsu, SanDisk, and SUSE.

Ceph is a truly amazing storage platform used by enterprises all over the world; whether they are using private cloud solutions like OpenStack and Kubernetes or they are integrating it with AWS S3, we see different use cases every day. Ceph keeps improving itself, every year Ceph releases new versions of its software in order to ensure good maintenance and improvements. Driven by an active community you will never find yourself alone in the Ceph world. Our own Ceph engineers are actively involved in the Ceph community to support users all over the world.

Cephalocon 2021, Let’s talk Ceph!

Cephalocon 2021, Let’s talk Ceph! 960 540 Michiel Manten

At this moment we are busy with the organization of another Cephalocon. Cephalocon is an annual event organized by the Ceph Foundation. By organizing Cephalocon, Ceph aims to bring together technologists and adopters from across the globe to showcase Ceph’s history and its future, demonstrate real-world applications, and highlight vendor solutions. By doing this, Ceph enables the community to work closer together and at the same time become ‘’tighter’’. 

In previous years, some subjects that were discussed were:

– Status and future of the Ceph file system.
– Everything you want to know about RadosGW.
– Hybrid cloud based on Ceph object storage.
– Accelerating Ceph performance with high-speed networks and protocols.
– Ten ways to break your Ceph cluster.

Previously the Cephalocon events have been held in Spain, China and the United Kingdom. This year’s Cephalocon, although virtual, promises to make for incredible community building, cross-company collaboration and cutting-edge training. You may be thinking: how can a virtual event compare to the real-life version? Probably a question almost all of us have been asking ourselves for the past year.

Firstly, it is important to mention that physical events can be very busy, loud and are held in all kinds of venues, meaning they may not always be accessible to everyone. A virtual event removes any physical barriers someone may have to attending a venue. Entering an event via their own device means we can make use of the accessibility tools we need to gain information, navigate and communicate within the event. Hosting an event virtually means it can be completely diverse and accessible to all.

Moreover, a virtual event means that you can fit it in around your own schedule. Many events and trade shows will include a conference of industry speakers, but you may be interested in only one or two of the talks on offer. Having that said, attending virtually means that you can sit and watch as many talks as you want to, or you can dip in and out of them, whilst also popping into the expo area for meetings with exhibitors, meeting new people in the speed networking area, or even leave the event for a while to carry on with your own tasks. A virtual event will also send you notifications for any sessions you have signed up to, so you do not miss anything.

Networking is a benefit of any event, but it is more important than ever during this time of social distancing. These opportunities to exchange insights and establish relevant technical connections, cannot be beaten. The benefits compared to traditional events is no time crunch to meet everyone you would like to in between sessions and it’s easier to collect information from the people you meet online. Aside from the business aspect, it is good to have that human connection and sense of community during troubling times on a personal level. Other than the benefits mentioned above, we can also benefit from cost reduction, accessibility, and time saving, compared to real-life events.

So, with nearly only benefits to think of in attending the event, we at 42on, are exited for you to join our Ceph team, Ceph’s customers and partners, and the Ceph community as we discuss how Ceph, the massively scalable, open source, software-defined storage system, can radically improve the economics and management of data storage for your enterprise.

We, at 42on, love Ceph and would love to e-meet you at Cephalocon 2021! I am also curious if you have Ceph subjects which you would like to be handled during the event. If you have, then let me know below.

ZFS and Ceph, what a lovely couple they make!

ZFS and Ceph, what a lovely couple they make! 958 467 Michiel Manten

Stable, secure data storage is probably one of the most important things in today’s data driven world. With the ability to scale fast. Combining two great storage solutions provides you with all those in one. ZFS and Ceph are a couple that cannot easily be beaten!

Why is that? The short explanation is scalability. ZFS is a solution which ‘scales up’ as no other, while Ceph is built to ‘scale out’. The term ‘scaling up’ means to extend the storage pool with additional disks which are fully available for the filesystems that use the pool. This model is generally limited by the amount of disks that can be added to a node. ‘Scaling out’ is a different way of growing the storage capacity; not by adding disks (or bigger disks) to a machine or pool, but by adding storage nodes (a storage server with network, compute and storage capacity) to the existing storage capacity. This model is mostly limited by the bandwidth between the different nodes.

That makes it far more easier to grow your storage infrastructure, because you don’t have to change the current hardware architecture expect for the capacity.

Easily scaling up with ZFS

ZFS is a combined file system and logical volume manager partly developed by Sun Microsystems. The ZFS name stands for nothing; briefly assigned the backronym “Zettabyte File System”, it is no longer considered an initialism. ZFS is very scalable, and includes extensive protection against data corruption, support for high storage capacities, efficient data compression, integration of the concepts of filesystem and volume management, snapshots and copy-on-write clones, continuous integrity checking and automatic repair, RAID-Z, native NFSv4 ACLs, and can be very precisely configured.

Unlike most files systems, ZFS combines the features of a file system and a volume manager. This means that as supposed to other file systems, ZFS can create a file system that spans across a series of drives or a pool. Not only that; you can add storage to a pool by adding more drives. ZFS will handle partitioning and formatting.

Easily scaling out with Ceph

Ceph is a storage solution that provides applications with object, block, and file system storage. All in a single unified storage cluster. It is flexible, exceptionally reliable, and easy to manage. Ceph decouples the storage software from the underlying hardware. This enables you to build much larger storage clusters with less effort. You can scale out storage clusters indefinitely, using economical commodity hardware, and you can replace hardware easily when it malfunctions or fails. I explained more about Ceph storage here: https://www.42on.com/ceph-object-block-and-file-system-storage-in-a-single-storage-cluster/ and here: https://www.42on.com/follow-up-on-ceph/

The two combined

With that said, I often see organizations start using open source software defined storage with ZFS. Looking at the growth potential of open source storage; there is no limit to how fast companies’ data size grow; it’s stable, highly redundant, cheap, and fast. Because of this, the open source storage systems are ‘abused’ to the max. Now when this happens, the environment grows and at one point the storage infrastructure is ten times larger than imagined when started.

At some point the size of the data grows so fast that the ZFS storage controller node(s) are at the maximum capacity of what they can handle. At this moment you will need to migrate the data to a new ZFS system. At this point it would be very nice to have a way to scale the storage out (combine more units) instead of only up (grow units bigger). This is where Ceph storage complements ZFS. With Ceph you will never have to carry out data migrations when you grow because you will add new storage servers to grow capacity or to remove older storage servers; CEPH will always redistribute the data to make optimal use of all capacity of the platform (storage, compute and networking). Where ZFS can start with little hardware investment though, CEPH requires more hardware as it doesn’t accept compromising the data consistency by storing all data (at least) 3 times.

That’s why ZFS and CEPH make such a great storage couple, each with their own specific use cases within the organization. For example; ZFS is often used for creating a backup or to build archive data, while Ceph provides the S3 cloud storage and virtual disk storage for virtual machines. In other cases, ZFS is used for file system storage while Ceph provides the block storage infrastructure.

And with both solutions being open source and software defined, as you can imagine we at Fairbanks and 42on love them both equally for their own merits, and even more as a complementary couple. And whoever said you had to choose your favorite from such a lovely couple? That makes me curious however: do you use both solutions or did you pick only one for your storage infrastructure?

Follow up on Ceph

Follow up on Ceph 1200 400 Michiel Manten

April 3rd, 2019 I posted a Linkedin article about the basics of Ceph, a cloud storage platform often used in combination with OpenStack. Since then, I got a lot of questions to explain a bit more of the mechanics of Ceph. As Fairbanks also incorporated Ceph service provider 42on, I started to dive a little deeper into the subject. In this article I share my understandings of the techniques to answer some of your questions. I hope it helps you understand more about Ceph and why it is such an interesting storage platform. If you have any questions, please feel free to comment or e-mail me. For truly in depth understanding of Ceph I will get you in contact with our new colleagues of 42on.

What does “Ceph is scalable object, block and file system storage” mean?

As explained in my post in april, Ceph is a software defined storage solution that can scale both in performance and capacity. Ceph is used to build multi petabyte storage clusters. The basic building blocks of a Ceph storage cluster are the storage nodes. These storage nodes are commodity servers containing commodity hard drives and/or flash storage. Ceph is ´self healing´ and provides infinite scalability and redundancy and is able to grow in a linear way physically and financially. Financial scalability means that you invest in the amount of storage you need at this moment, not the amount you might need over, for example, five years.

Ceph is designed for scale. And you scale by adding additional storage nodes. You will need multiple servers to satisfy your capacity, performance and resiliency requirements. And as you expand the cluster with extra storage nodes, the capacity, performance and resiliency (if needed) will all increase at the same time.

You don’t need to start with petabytes of storage though. You can actually start small, with just a few storage nodes and expand as your needs increase. Because Ceph manages redundancy in software, you don’t need a RAID controller, therefore a generic server is sufficient. The hardware is simple and the intelligence resides all in software. These servers can exist from different hardware brands and/or generations, so you can expand your Ceph environment at your own pace. Alltogether this means that the risk of hardware vendor lock-in is mitigated. You are not tied to any particular proprietary storage hardware.

What makes Ceph so special?

At the heart of the Ceph storage cluster is the CRUSH algoritm, developed by Sage Weil, the co-creator of Ceph. The CRUSH algoritm allows storage clients to calculate which storage node needs to be contacted for retrieving or storing data. The storage client can determine what to do with data or where to get it.

Ceph is unique because there is no centralised ‘registry’ that keeps track of the location of data on the cluster (metadata). Such a centralised registry can become a performance bottleneck, preventing further expansion, or a single-point-of-failure. This is why Ceph can scale in capacity and performance while assuring availability. At the core of the CRUSH algoritm is the CRUSH map. That map contains information about the storage nodes in the cluster and the rules for storing data. That map is the basis for the calculations the storage client needs to perform in order to decide which storage node to contact.

The CRUSH map is distributed across the cluster from special servers: the ‘monitor’ nodes. Those nodes are contacted by both the storage nodes and the storage clients.

It’s important to keep in mind that while the Ceph monitor nodes are an essential part of your Ceph cluster, they are not in the data path. They do not store or process client data.They only keep track of the cluster state for both clients and individual storage nodes. Data always flows directly from the storage node towards the client and vice versa.

So there is no central bottleneck

A storage client will contact the appropriate storage node directly to store or retrieve data. There are no components in between, except for the network, which you will need to size accordingly. Because there are no intermediate components or proxies that could potentially create a bottleneck, a Ceph cluster can really scale horizontally in both capacity and performance. And while scaling storage and performance, data is protected by redundancy.

How does Ceph provide data redundancy?

To have the most redundant and safe storage infrastructure Ceph provides both replication and erasure encoding. For replication Ceph distributes copies of the data and assures that the copies are stored on different storage nodes.

You are able to configure an infinite amount of replicas. The only downside of storing more replicas are the costs of extra hardware you need to setup to provide the extra raw storage capacity. You may decide that data durability and availability are so important that you may have to sacrifice space and absorb the cost, but in general Ceph advises 3 replica’s as a minimum replica count.

Does Ceph also support erasure encoding?

So what if you think having 3 replicas is too costly? How does Ceph ensure your data?

To explain this technique it would be easy to comparing it to RAID technologies. In that case, I would say that RAID1 resembles the Ceph equivalent of ‘replication’: they offer the best overall performance both are not most storage space efficient. Especially as you need more than one replica of the data to achieve the level of redundancy you need.

This is why we got to RAID5 and RAID6 in the past as an alternative to RAID1 or RAID10. Parity RAID assures redundancy but with much less storage overhead. As always in IT, this comes at a price though: in this case at the cost of storage performance (mostly write performance). Ceph and RAID 5 and 6 both use a type of ‘erasure encoding’ to achieve comparable results. In this example of erasure encoding you are telling Ceph to chop up the data in 8 data segments and 4 parity segments:

You will have only 33% storage overhead for redundancy instead of 50% (or even more) you may face using replication, depending on how many copies you want. This example does assume that you have at least 8 + 4 = 12 storage nodes. But any scheme will do, you could do 6 data segments + 2 parity segments (comparable to RAID6) with only 8 hosts.

What failure domains does Ceph protect against?

Ceph is datacenter aware; the CRUSH map can represent your physical datacenter topology, consisting of racks, rows, rooms, floors, datacenters and so on. You can customise your topology. This allows you to create very clear data storage policies that Ceph will use to assure that the cluster can tollerate failures across certain boundaries. An example of a Ceph infrastructure:

If you want, you can be protected to lose a whole rack. Or a whole row of racks and the cluster could still be fully operational, although performance and capacity are reduced. That much redundancy may cost so much storage that you may not want to employ it for all of your data. That’s no problem. You can create multiple storage pools that each have their own protection level and thus cost.

What is this Object Storage Daemon (OSD) I always read about?

If you read about Ceph, you read a lot about the OSD. This is a service that runs on the storage node. The OSD is the actual workhorse of Ceph, it serves the data from the hard drive or ingests it and stores it on the drive. The OSD also assures storage redundancy, by replicating data to other OSDs based on the CRUSH map. So for every hard drive or solid state drive in the storage node, an OSD will be active. A Ceph environment with 24 hard drives, runs 24 OSDs.

When a drive goes down, the OSD will go down too and the monitor nodes will redistribute an update CRUSH map so the clients are aware and know where to get the data. The OSDs also respond to this update, because 1 replica of some data is lost, they will start to replicate affected data to make it redundant again (across fewer nodes though). After this automatic process the is fully healthy again. This is comparable to having a ‘hot-spare’ without the need for ‘hot-spares’.

When the drive is replaced, the cluster will revert back to the original state. This means that the replaced drive will be filled with data once again to make sure data is spread evenly across all drives within the cluster.

Press release

Press release 1600 899 Michiel Manten

Fairbanks

acquires 42on.

Fairbanks, leading provider in open source cloud solutions, announces the acquisition of 42on, leading provider of services for the Ceph storage platform.

Press

release.

Amersfoort, July 23 2019

Fairbanks, leading provider in open source cloud solutions, announces the acquisition of 42on, leading provider of services for the scalable, open source Ceph storage platform.

With this acquisition, Fairbanks expands its service portfolio in the open infrastructure realm. Ruud Harmsen, founder and CEO of Fairbanks: “We have been managing and supporting highly available private OpenStack clouds for our customers for over 7 years now. We’ve recognized that our customers have a growing need for specialized, highly reliable private cloud storage as well. We are already very familiar with the Ceph cloud storage solutions as part of OpenStack clouds and have successfully collaborated with Wido den Hollander and 42on at several mutual customers. We discovered we share a vision on servicing customers and the potentials of open infrastructures, combining our forces became an obvious next step”.

“We are delighted to become a part of Fairbanks,” said Wido den Hollander, world renowned Ceph expert, co-founder and CTO of 42on. “We believe this is the perfect combination of technology, strategy and culture. As 42on will remain a strong brand for Ceph services as it is, the cooperation with Fairbanks enables us to expand our service portfolio for our Ceph-only customers with fully managed services for example and other variants of support than we can provide now. Our customers that are interested in other open infrastructure technologies can of course benefit from Fairbanks’ years long expertise. I am looking forward to exciting times for our employees, both communities as well as our customers!”.

Fairbanks supports organizations with the design, implementation and management of sustainable and innovative open infrastructures since 2012. Open infrastructures enable companies to flexibly follow the growth of the digital organization, replace investments (CAPEX) with operational costs (OPEX) and quickly embrace innovations. Fairbanks helps telecom companies, hosting/service providers, software developers, SaaS companies, universities, governments, banks and eCommerce companies to build and manage OpenStack Cloud environments. Fairbanks is also the ambassador for the OpenStack Foundation in the Benelux.

42on provides high quality Ceph consultancy since 2012. Assisting organizations in designing, deploying and supporting Ceph clusters. Ranging from terabytes to petabytes, spinning disks or all flash, 42on has implemented all kinds and types of Ceph clusters. 42on also is actively involved in the open source communities of Ceph, Apache CloudStack, libvirt and multiple other projects.

For more information about Fairbanks, see fairbanks.nl.

Interested?
Let’s get in touch.

Ceph: Object, block and file system storage in a single storage cluster

Ceph: Object, block and file system storage in a single storage cluster 2560 1185 Michiel Manten

Cloud storage in your datacenter

Storage growth for the coming years

The International Data Corporation (IDC) has released a report on the ever-growing collective world’s data, a.k.a. the datasphere. Numbers are staggering: the IDC predicts that the collective sum of the world’s data will grow from 33 zettabytes this year to a 175ZB by 2025, growing at a yearly rate of 61%.

Some other remarkable stats for the year 2025 are:

  • The storage industry will ship 42ZB of capacity over the next 7 years.
  • 90ZB of data will be created on IoT devices by 2025.
  • By 2025, 49% of data will be stored in public clouds.
  • 30% of data generated will be consumed in real-time by 2025.

Cloud datamanagement

To facilitate this growth, companies look at ways to store their data safely and effectively. But more over, ways to improve management of ever growing datasets. A great way to start this is by adopting cloud storage solutions in your own infrastructure. Integrating object, block and file storage in a single unified storage cluster while simultaneously delivering high-performance and infinite scalability.

Ceph storage

Ceph is the storage solution that provides applications with object, block, and file system storage. All in a single unified storage cluster. It is flexible, highly reliable and easy to manage. Ceph storage is scalable for thousands of client hosts accessing petabytes of data. Applications can use any of the system interfaces to the same cluster simultaneously, which means your Ceph storage system serves as a flexible foundation for all of your data storage needs.

Ceph storage at a glance

  • Use Ceph for free, and deploy it on commodity hardware, keeping hardware expenses low.
  • Ceph replicates data and makes it fault tolerant.
  • The system is both self-healing and self-managing by design.
  • Proven Enterprise grade technology since 2011.
  • Endlessly scalable and agile by design. The only limits to size and speed of your storage cluster is the hardware.
  • Supported by major vendors and several service models possible, to guarentee uptime.
  • Integrates object, block and file storage in a single unified storage cluster.
  • Build as you grow: You can grow the cluster while migrating virtual machines, keeping the initial investment interesting enough.

Scale out on commodity hardware

Ceph decouples the storage software from the underlying hardware. This enables you to build much larger storage clusters with less effort. You can scale out storage clusters infinitely, using economical commodity hardware, and you can replace hardware easily when it malfunctions or fails. If your cloud journey is going to be hybrid: Ceph integrates with private as well as public clouds like AWS and Azure. The following picture shows an overview of the Ceph services:

Suitable for you?

So wether your current storage is ‘end-of-life’, your current data growth is not sustainable anymore, you want to easily combine object, block and file storage, you want to free yourself from the expensive lock-in proprietary hardware based storage solutions, you want a cloud native storage solution, you want to automate your replication and management, or you just want to find out for yourself what storage options are available at the moment; Ceph is most certainly worth taking a look at.

Get

in touch.

    ConsultancyTrainingSupport
    Privacy Preferences

    When you visit our website, it may store information through your browser from specific services, usually in the form of cookies. Here you can change your Privacy Preferences. It is worth noting that blocking some types of cookies may impact your experience on our website and the services we are able to offer.

    Click to enable/disable Google Analytics tracking code.
    Click to enable/disable Google Fonts.
    Visit privacy policy Visit terms and conditions
    Our website uses cookies, mainly from 3rd party services. Define your Privacy Preferences and/or agree to our use of cookies.