High availability

But within that as well, there's a couple of other features beyond that.

So the ability to have read replicas, HA replicas, all self-managed by their team, having a connection load balancer that sits on the outside.

So if you need to scale up, if a single instance isn't going to suffice across many different instances, the ability to scale across those many different read replicas as well.

One of the other features I think that's worth calling out that makes a big difference for users that want to retain a long history of data without keeping all of that data hot is tiered data.

The other area we have, and I mentioned so far two offerings.

I mentioned the open source offering with TimescaleDB, and I mentioned Tiger Cloud.

And as we grow in the physical world, in, in industrial operations, we're also building a product called TimescaleDB Enterprise, which is an on-prem version of the open source solution that uses a number of technologies to allow with its own console and platform to be able to stand up an HA environment with read replicas, with, you know, connection load balancing, backups, you know, automating a lot of the things that if you were gonna build yourself, you'd have to start with the open source product, add etcd, Patroni, other technologies on top of that to build a true HA configuration.

We're providing that, uh, out of the box as well.

For most enterprises that are running a distributed DDI platform configuration of some type, whether that's a commercial product or they're doing it themselves, sort of baked from open source.

The reality is that coming up with high availability, redundancy, how do you build in redundancy? How do you deal with all the related dependencies that go on with allocations and scope management and hygiene and address tracking and all that other stuff? actually becomes a really hard architecture and design problem to sort of figure out about how you want to do it at scale.

And so we wanted to just take a little bit of time and talk our way through some of the things that we think are maybe major issues or things to consider in sort of working your way through that.

So I guess we'll kick it off and start from there and really sort of talk about maybe some of the the first challenges that go on for everything that we sort of talk about with V4 and V6, which is sort of the scale difference, right? There's just a fundamental scale difference between V4 and V6.

Yeah.

And I think that's a real problem because how do you deploy at scale and figure out where you're getting exploited or where you have operational issues or why you're having login and authentication problems? Like all these things become exponentially harder at scale with the address space that you have, but also with the distributed portion of sort of building on these platforms.

And I don't think anyone really has a great solution for like, at least for DHCPv6, you know, high availability in DHCPv6 is... not really super pretty, right? Split scope instead of actual redundancy.

Yeah, split scope instead of redundancy is not a great answer.

Karmada is a CNCF incubation project now.

It provides centralized multi-cloud Kubernetes management, speaking Kubernetes, native APIs, with advanced scheduling including cluster affinity and multi-dimension HA across regions, availability zones, and providers.

There's Cilium Cluster Mesh, which was used in a production case study for a regulated payments workload spanning AWS, GCP, and Azure.

They reduced region level RTO from 22 minutes manual to 47 seconds automatic.

Data restored from cloud storage backups.

Warm Standby, a minimal database instance, runs continuously in Google Cloud, receiving replicated transactions from the on-premise primary.

Hot HA, both sides serve production traffic simultaneously with

DNS-weighted routing.