5 posts tagged with "Operations"

Capacity is never right for long. Traffic grows, a launch lands, a season ends — and the store you sized last quarter is either straining or half-idle. The question that decides whether that's a chore or a crisis is simple: can you change the size of a running store without taking it down?

For Zaris the answer is yes, with an important asymmetry that's worth being honest about up front. Scaling out — adding servers — is the easy, safe, lossless direction, and it happens live while the store keeps serving. Scaling in — removing servers — is also supported, but it's a deliberate, monitored operation because the data on a departing server has to go somewhere first.

This post walks both directions: growing a store with Add-ZrServer, shrinking it with Remove-ZrServer, why scale-in needs a drain, and where the web console fits.

Half of the "works in dev, breaks in prod" connection bugs come down to the same thing: the connection details were spelled three different ways in three different places. The appsettings.json had one host list, the ops runbook pasted another into a PowerShell session, and the string someone copied off a wiki had a stale token baked right into it.

Zaris takes that whole class of problem off the table with a single, platform-agnostic connection-string format. The exact same string works when your .NET app reads it from configuration, when an operator hands it to a PowerShell cmdlet, and when someone copies it straight out of the web console. One canonical spelling, everywhere.

This post breaks the string down part by part, shows all three ways to use it, and makes the case for the one rule that matters most in production: never put a raw token in the string.

Getting a distributed store onto Kubernetes is easy. Getting it there with TLS on, reachable from outside the cluster, and a client that actually connects is where most walkthroughs quietly stop. Zaris ships a Helm chart, and we've validated the whole path — including the secured, externally-reachable configuration — end to end on a local cluster.

This post is that walkthrough. We run it on kind (Kubernetes-in-Docker) so you can reproduce every step on a laptop, and we take the harder road on purpose: TLS enabled, certificates with the right subject alternative names, external access on, and a client connecting over the secured endpoint. We call this the Model B configuration — externally-reachable and secured, versus an internal-only cluster.

One correctness rule snags almost every first deploy, and it has nothing to do with certificates: the store name in your connection string must equal the deployment's clusterId. We'll flag exactly where that bites. Everything else is identical on a production cluster — kind just gives us a clean, disposable place to prove it.

Run Zaris in Kubernetes and the happy path is easy: in-cluster clients reach the pods by their internal addresses — pod IPs and cluster-DNS names like zaris-0.zaris.svc — and everything routes cleanly. The moment a client lives outside the cluster, that breaks. An external application cannot dial zaris-0.zaris.svc or a pod IP; those names and addresses only resolve and route inside the cluster network.

This is not a Zaris quirk — it is the fundamental split between the cluster's internal network and the outside world. It bites hardest with topology-aware clients. A cluster-mode Redis client, or any client that discovers nodes and routes per-key, fetches a topology map from the server and connects to the addresses in it. If those addresses are internal, an external client gets a map full of endpoints it can never reach.

Zaris solves this with advertised addresses, handled as a per-listener "boundary view."

Zaris exposes a Redis-protocol (RESP) front-end so any Redis client, in any language, can point at a Zaris cluster and use it as a drop-in store. But "any Redis client" hides a real problem: Redis client ecosystems do not agree on how to discover topology or how to recover when a node disappears. A plain client expects a single stable endpoint. A Sentinel-based client expects to ask a discovery service "who is the master?" A cluster-mode client expects hash slots and MOVED/ASK redirects.

If a store spoke only one of those dialects, a whole class of clients would be locked out. So the Zaris RESP front-end supports three failover models, each matching how a particular family of Redis clients already expects to work. You pick the model per deployment; the client behaves exactly as it would against real Redis.

One honest note up front, because it shapes everything below: all three models sit in front of the same replicated, partitioned Zaris store. The model you choose changes discovery and redirection semantics — how a client finds a node and what it does when one fails — not where your data actually lives.