DataServer Scaling Guide¶
Overview¶
This guide provides guidelines on when and how to scale Privacera DataServer for S3 deployments, including scaling thresholds, configuration best practices, and operational considerations to ensure efficient performance and stability.
DataServer Architecture¶
For detailed information, please refer to the Privacera DataServer documentation
Prerequisites¶
Before scaling DataServer, ensure the following:
- Kubernetes cluster (EKS, AKS, or GKE) is deployed
- kubectl access is configured with appropriate permissions
- Kubernetes version meets the requirements. Refer to Compatibility & Versions for supported versions
- Privacera Manager is installed
- AWS S3 prerequisites (required only for DataServer with S3): IAM role configured with S3 access permissions. Refer to AWS S3 prerequisites
- Service Account with IAM Role (for AWS deployments): DataServer service account has IAM role annotation configured for accessing AWS services
Complete Prerequisites
For complete base installation prerequisites, refer to prerequisites for Self-Managed deployments or prerequisites for DataPlane deployments.
Scaling Rationale for DataServer¶
Despite STS reducing data plane load, DataServer must scale for:
| Load Factor | Impact on DataServer | Why Scaling Needed |
|---|---|---|
| Token Generation Rate | CPU + Memory | Many concurrent users requesting tokens |
| Policy Evaluation | CPU | Complex Ranger policies per token request |
| Policy Cache | Memory | Thousands of policies cached in memory |
Scaling Approaches¶
Manual Replica Scaling¶
DataServer uses manual scaling by configuring the number of pods:
- How it works
- Set desired replica count in configuration
- Apply using Privacera Manager
- Kubernetes maintains specified number of pods
When to Scale¶
-
Scale Horizontally (Add Replicas):
- CPU consistently > 70%
- High token generation rate
- Many concurrent users
- Request latency increasing
-
Scale Vertically (More Resources per Pod):
- Complex policy evaluations
- Large policy cache needed
- Individual pods hitting limits
Configuration Best Practices¶
All DataServer configuration variables should be added to the vars.sizing.yaml file in your Privacera Manager config directory.
Core Configuration Variables¶
| Variable | Purpose | Small | Medium | Large |
|---|---|---|---|---|
| DATASERVER_K8S_CLUSTER_SIZE | Number of pods | min=1 max=1 | min=2 max=4 | min=3 max=20 |
| DATASERVER_HEAP_MIN_MEMORY_MB | JVM min heap | 512 | 8192 | 8192 |
| DATASERVER_HEAP_MAX_MEMORY_MB | JVM max heap | 2048 | 8192 | 8192 |
| DATASERVER_CPU_MIN | CPU request | 1 | 2 | 4 |
| DATASERVER_CPU_MAX | CPU limit | 1 | 4 | 8 |
- Key Principles:
- Heap = 75% of container memory to leave room for non-heap JVM memory.
- CPU min/max ratio allows bursting but prevents unlimited usage.
Note
The following steps apply to Self-Managed and DataPlane deployments only.
Deployment Size Templates¶
-
Update Configuration
Edit
~/privacera/privacera-manager/config/custom-vars/vars.sizing.yamlbased on the configuration guidelines provided in the sections below.-
Test Environment (Small Scale)
-
Production (Medium Scale)
DATASERVER_K8S_CLUSTER_SIZEcan be scaled between 2 to 4. -
Production (Large Scale)
DATASERVER_K8S_CLUSTER_SIZEcan be scaled between 3 to 20.
-
-
Validation Checklist
- All pods in
Runningstate - All pods show
1/1Ready - CPU utilization 50-65% average
- Memory utilization 60-75%
- All pods in
Grafana Monitoring and Alerts¶
Monitor DataServer Dashboard¶
Use the Privacera Grafana monitoring dashboards to track DataServer resource utilization:
-
Access Grafana Dashboard
- Navigate to: Dashboards → Infra-Dashboards → Cluster RAM and CPU Utilization
-
View DataServer Metrics
- The dashboard provides the following views:
Dashboard View What to Check Focus On Memory usage by namespace Overall namespace memory Identify if namespace hitting limits Memory usage by pod Individual DataServer pod memory Find which pods need attention CPU Usage by namespace Overall namespace CPU Track aggregate CPU consumption CPU Usage by pod Individual DataServer pod CPU Identify high CPU pods -
Interpret Dashboard Colors
- The dashboard uses a gradient color scale to indicate resource usage intensity:
Color Indicator Usage Level What It Means Action Required Light Yellow
Low usage Resources are healthy Monitor regularly
Yellow-Orange
Moderate to high usage Resources approaching limits Plan scaling soon
Red-Dark Red
Critical usage Resources at or near capacity Take immediate scaling action
Scaling Alert Criteria
- Memory: Red indicators show pods using high memory (e.g., > 30 GiB or > 80% of pod limit)
- CPU: Red indicators show pods with sustained high CPU usage (e.g., > 500ms or > 70% utilization)
- Look for pods with
dataserver-*names showing orange/red colors.
Monitor DataServer Alerts¶
Privacera monitoring includes pre-configured alerts that automatically notify when DataServer pods exceed resource thresholds. These alerts help identify when scaling is needed.
-
Open your Grafana portal
- Navigate to: Home → Alerting → Alert rules
-
Identify DataServer Alert Types
In the Alert rules page, look for the following alert rules in the Common-Dashboards folder:
- pod_cpu_usage
- pod_memory_usage
- node_cpu_usage
- node_memory_usage
- pod-container-not-ready-alert
- pvc_usage
-
When an alert fires for DataServer
- Alert identifies the issue - You receive notification that a threshold is breached.
- Check the dashboard for details - Go to the Cluster RAM and CPU Utilization dashboard in Grafana.
- For troubleshooting steps - Refer to Resource Utilization Issues section.
Alert-Driven Scaling
Alerts are your early warning system. When you receive a pod_cpu_usage or pod_memory_usage alert for DataServer pods, it indicates scaling thresholds have been reached. Use the deployment size templates to scale appropriately based on your current load.
- Prev topic: Advanced Configuration