Hey everyone Brett Kelly here for another Tuesday tech tip 45 Drives. Today I want to talk about Multisite Clusters. It's a topic that comes up a lot. People are very interested in the idea of having a cluster across multiple physical locations. So what I want to do is demystify the concept of it and kind of lay out the ground rules, what you can and what you can't do with multisite cluster.

OK, so before I get into the specifics of Multisite, I want to make it absolutely clear that multisite clustering is not equal to disaster recovery. There are two different concepts here. Disaster recovery is a one-way sync from your primary storage location to somewhere else. Should that disaster strike in your primary location, you can all pull back from this. But remember, one way. It goes one direction. If you make changes on one end here, it does not get sent back to the primary. And we've got other resources on what Disaster recovery is. You can check that out.

Multisite clustering as we are calling in here and as we are with Ceph, is a two-way sync between your multiple locations. Meaning that primary side A and side B secondary, you could access the same data from either or if you make a change here, it shows up over and side, vice versa. And so that's it. Multisite is not DR. DR is one way. Multisite is two way. OK, so with the definitions out of the way, we can dig into multisite.

Like I said, multisite, you keep your data in sync between the two of them. You work from one shows up in the other, vice versa. So, sync, that's the keyword sync. But there's two ways to think about multisite clusters. Yes, they're always in sync, but are they synchronous as in they're always exactly in sync with each other, or are they asynchronous as in it happens one and then it eventually gets pushed over to the other one relatively quickly.

OK, so I'll start with Synchronoss Multisite Ceph clusters. Ceph in its nature is synchronous. What I mean by that is if I make a write and it's got to be distributed to all the many nodes of Ceph. Until me, the client, I will not see this as finished until all participating storage locations in the cluster said, “yup. Got the file, we're done.”

So what that means is if any part of your storage infrastructure is in a lower network connection than the other ones, whether that's high latency or just too low a bandwidth. It doesn't matter how fast the other ones is, you will apparently see only the speed of your slowest link, classic bottleneck stuff, right? Ceph is synchronous by nature. That's why you want it all on a high-speed network and stuff like that. So, when I say Synchronoss multisite, think one cluster spanned across multiple locations. Now, this is great because it's relatively simple, Ceph just works the same way. You have access to file, block and object.

It's just one big Ceph cluster. It's logically all there. It doesn't know it's in two separate sites. Remember what I said about the bottleneck in Hispan? Cluster your synchronous by default. Therefore, you're if you're if your bandwidth is too low, if your latency is too high, then your Ceph cluster is going to be to feel too sluggish to use. And a span multisite is not going to work in your case. So particularly where I'm getting at is you cannot do this across the Internet or a large geographic location.

OK, in this case, how are you going to get around Ceph’s synchronous nature by default? Well, the first one was one span cluster across multiple sites. These are one individual cluster in multiple sites, that are all aware and in sync with each other. So how this works is you get the benefit of the synchronous nature of Ceph in each of the individual high-speed networks that they're on and then their larger lower latency link or whatever they keep in sync and push it around that way. Awesome.

There's only a little bit of a caveat. Like everything I said with the first one, with the caveat, you get everything. But the caveat is you need the right networking between everything. This one is you're limited to the S3 Object Protocol or RBD mirroring due to the way the file object and block works. The Block and object protocol entrances into the Ceph cluster play a lot nicer to this asynchronous will sync later nature.

Very tough challenge to solve a filesystem. So, when you are doing asynchronous, so multi site, multi region kind of locations with Ceph clusters, you are limited to S3 and block storage only. However, you don't really have to worry about the network location. So, if you have an S3 object store cluster in New York and you needed the secondary location down in L.A. and they share their data that way, an asynchronously multi site S3 gateway into your Ceph cluster will achieve your needs.

OK, so that is the rundown on building Ceph clusters that span multiple sites. Multisite Ceph clustering is not DR. It is a two-way synchronization of your data between sites. And remember, when you get into it, there's a synchronous multisite cluster and an asynchronous multisite cluster. Think for Synchronoss one spanned cluster across multiple locations, but they require a good high network between them all. And asynchronous is one unique cluster in multiple locations that all keep in sync with each other, that don't require big beefy networks put in between it. Public Internet connection would be fine. Or if you're on a large geographical distance.

So, if you're in the need of a multisite cluster, reach out. We'd love to help you get the right solution for your environment, your location, your needs. So, yeah, hope you enjoyed the video. Hope to learn something. We'd love to hear from you.