Deployment and Maintenance / High Availability Deployment
DataFlux Func supports multiple deployments to meet high availability requirements.
This guide mainly introduces how to install and deploy a high availability DataFlux Func directly on servers.
- For information on installing DataFlux Func using Helm in k8s, please refer to Deployment and Maintenance / Installation and Deployment / Helm Deployment
- For information on scaling the DataFlux Func system, please refer to Deployment and Maintenance / Architecture, Scaling and Resource Limiting
- For the detailed process of function execution, please refer to Script Development / Function Execution Process
When selecting a high availability solution for Redis, please do NOT use 'Cluster Edition Redis'. You can use 'Master-Slave Edition Redis'.
If you have previously installed DataFlux Func in a standalone mode, please refer to Deployment and Maintenance / Daily Operations / Database Migration for migration when switching to a high availability deployment.
1. Multi-Replica Deployment
Both the Server and Worker services of DataFlux Func support multiple deployments to achieve high availability, scaling, and other requirements.
Generally, the bottleneck in function execution efficiency lies with the Worker service (i.e., the Python code). Therefore, the Server service only needs to avoid a single point of failure, while the Worker service requires increasing the number of replicas based on the actual business volume.
In a multi-replica deployment, it is essential to ensure that the user-config.yaml files for all services are completely identical, that they all connect to the same MySQL and Redis instances, and that the resource directory is mounted to the same storage.
Additionally, the Beat service, which acts as the trigger for scheduled tasks, can and must run only 1 replica. Running more may lead to duplicate scheduled tasks.
flowchart TB
USER[User]
SERVER_1[Server 1]
SERVER_2[Server 2]
WORKER_1[Worker 1]
WORKER_2[Worker 2]
WORKER_3[Worker 3]
BEAT[Beat]
REDIS[Redis]
USER --HTTP Request--> SLB
SLB --HTTP Forward--> SERVER_1
SLB --HTTP Forward--> SERVER_2
SERVER_1 --Enqueue Function Execution Task--> REDIS
SERVER_2 --> REDIS
REDIS --Dequeue Function Execution Task--> WORKER_1
REDIS --Dequeue Function Execution Task--> WORKER_2
REDIS --Dequeue Function Execution Task--> WORKER_3
BEAT --"Enqueue Function Execution Task\n(Scheduled)"--> REDIS
2. Fully Independent Active-Standby Deployment
Let's temporarily set aside whether this deployment method truly qualifies as 'High Availability', assuming such a deployment requirement indeed exists.
A fully independent active-standby deployment essentially involves deploying two completely independent sets of DataFlux Func (with identical Secret, MySQL, and Redis configurations in the user-config.yaml file for both).
Since the active and standby DataFlux Func instances operate independently, the Beat services on both the active and standby servers will trigger scheduled tasks within their respective environments, which will cause scheduled tasks to be triggered redundantly.
To avoid this issue, you can either keep the standby node's DataFlux Func turned off during normal operation, or implement logic within your scripts to handle and prevent duplicate task execution.
flowchart TB
USER[User]
MAIN_NODE_SERVER[Active Node Server]
MAIN_NODE_WORKER[Active Node Worker]
MAIN_NODE_BEAT[Active Node Beat]
MAIN_NODE_REDIS_QUEUE[Active Node Redis Queue]
BACKUP_NODE_SERVER[Standby Node Server]
BACKUP_NODE_WORKER[Standby Node Worker]
BACKUP_NODE_BEAT[Standby Node Beat]
BACKUP_NODE_REDIS_QUEUE[Standby Node Redis Queue]
USER --HTTP Request--> SLB
SLB --HTTP Forward--> MAIN_NODE_SERVER
SLB -.-> BACKUP_NODE_SERVER
subgraph "Standby Node - Off"
direction TB
BACKUP_NODE_SERVER --Enqueue Function Execution Task--> BACKUP_NODE_REDIS_QUEUE
BACKUP_NODE_REDIS_QUEUE --Dequeue Function Execution Task--> BACKUP_NODE_WORKER
BACKUP_NODE_BEAT --"Enqueue Function Execution Task\n(Scheduled)"--> BACKUP_NODE_REDIS_QUEUE
end
subgraph Active Node
direction TB
MAIN_NODE_SERVER --Enqueue Function Execution Task--> MAIN_NODE_REDIS_QUEUE
MAIN_NODE_REDIS_QUEUE --Dequeue Function Execution Task--> MAIN_NODE_WORKER
MAIN_NODE_BEAT --"Enqueue Function Execution Task\n(Scheduled)"--> MAIN_NODE_REDIS_QUEUE
end