宕机自动恢复服务

简介: 在服务或脚本运行过程中,可能会因为程序异常、服务器重启或掉电等原因停止运行,导致业务受损。通过使用云助手插件 `ecs-tool-servicekeepalive`,可以在服务或脚本被中断时快速恢复运行,确保其可靠性和持续性。该插件基于 Linux 系统的 systemd service 实现,用户只需输入启动命令即可自动生成 systemd service 配置,无需手动配置。具体实践包括启动插件、查看配置状态及取消自恢复等功能。

服务或脚本在运行过程中可能会因程序异常、服务器重启、掉电等情况而停止运行,如果不能及时恢复运行,会给线上业务造成损失。您可以通过云助手插件ecs-tool-servicekeepalive,使服务或脚本在被中断时快速恢复运行,保障服务的可靠性和持续性。

自动恢复服务挂网文档:https://help.aliyun.com/zh/ecs/use-cases/automatic-recovery-service?spm=a2c6h.12873639.article-detail.11.5db173dcSqhcLS


方案原理

该方案是基于Linux操作系统的systemd service服务实现的。启用插件ecs-tool-servicekeepalive时,用户只需输入服务/程序的启动命令(例如,python /home/root/main.py)。启用后,该插件会根据用户输入的启动命令,自动生成systemd service配置,实现服务或脚本自启动,无需您手动配置systemd service。

说明

systemd service是Linux系统中的一个组件,可以用来自动管理服务,例如实现开机自启动和服务意外停止后自启动等。详细介绍,请参见systemd官方文档

方案实践

  1. 完成服务或程序等部署后,以root权限启动云助手插件ecs-tool-servicekeepalive
    以root用户运行服务/脚本
    通过指定用户运行服务/脚本
sudo acs-plugin-manager --exec --plugin ecs-tool-servicekeepalive --params "start,'cmd'"
  1. cmd:需替换为服务启动命令。例如,脚本执行命令(/bin/bash /home/work/debug/debug.sh )、程序运行命令(python /home/root/main.py)等。
    重要
    脚本或程序文件路径需为根路径。
  2. 执行以下命令,查看服务是否已被配置为自恢复。
sudo acs-plugin-manager --exec --plugin ecs-tool-servicekeepalive --params "status"
  1. 类似如下回显,表示配置成功。
  2. (可选)如果您需要取消服务/脚本自恢复,可执行如下命令。
sudo acs-plugin-manager --exec --local --plugin ecs-tool-servicekeepalive --params "stop service_name"
  1. service_name:替换为已配置的服务配置名称(即步骤2回显中的service_name列)。

应用示例

  1. 准备环境。
    创建一个/home/work/debug文件夹,并在该文件夹下创建debug.sh脚本,该脚本会每秒打印一行日志到用户指定的日志文件中。
sudo mkdir -p /home/work/debug && \
sudo tee /home/work/debug/debug.sh > /dev/null << 'EOF'
#!/bin/bash
while true
do
   sudo echo "$(date '+%Y-%m-%d %H:%M:%S') progress is alive" >> $1
    sleep 1
done
EOF
  1. 通过命令ps aux |grep debug.sh,发现脚本并未运行。
  2. 启动云助手插件。
sudo acs-plugin-manager --exec --plugin ecs-tool-servicekeepalive --params "start,'/bin/bash /home/work/debug/debug.sh /home/work/debug/debug.log'"
  1. 此时通过命令ps aux | grep debug.sh查看,发现脚本已经在运行(此时进程号为2572)。
  2. 验证脚本是否会自动恢复运行。
    重启ECS脚本正常运行
    Kill进程脚本正常运行
    在控制台重启ECS实例,ECS恢复后,登录实例,执行如下命令。
ps aux |grep debug.sh
  1. 发现服务debug.sh的进程仍正常运行,且进程号更新为764,说明脚本被重新启动过。

相关实践学习
借助OSS搭建在线教育视频课程分享网站
本教程介绍如何基于云服务器ECS和对象存储OSS,搭建一个在线教育视频课程分享网站。
7天玩转云服务器
云服务器ECS(Elastic Compute Service)是一种弹性可伸缩的计算服务,可降低 IT 成本,提升运维效率。本课程手把手带你了解ECS、掌握基本操作、动手实操快照管理、镜像管理等。了解产品详情:&nbsp;https://www.aliyun.com/product/ecs
相关文章
|
3月前
|
存储 运维 Python
基于 ChunkServer 的数据备份与恢复方案
【8月更文第30天】在分布式文件系统中,数据的安全性和持久性是至关重要的。为了应对可能发生的硬件故障、网络中断等问题,需要有一套完善的备份与恢复方案。本文将详细介绍如何设计和实现一套基于 ChunkServer 的数据备份与恢复流程,确保数据的完整性和持久性。
43 0
|
3月前
|
运维 监控 定位技术
故障转移和自动恢复
故障转移和自动恢复
|
12月前
|
监控 安全 数据安全/隐私保护
服务器数据恢复—如何预防服务器故障?发生故障后如何恢复服务器数据?
服务器常见故障: 硬件故障:磁盘、板卡、电源故障等。 软件故障:操作系统崩溃、程序运行错误等。 入侵破坏:加密、删除服务数据等。 不可控力:浸水、火烧、倒塌等。 误操作:格式化、删除、覆盖等。
|
运维 监控 NoSQL
记一次redis主从切换导致的数据丢失与陷入只读状态故障
背景 最近一组业务redis数据不断增长需要扩容内存,而扩容内存则需要重启云主机,在按计划扩容升级执行主从切换时意外发生了数据丢失与master进入只读状态的故障,这里记录分享一下。 业务redis高可用架构 该组业务redis使用的是一主一从,通过sentinel集群实现故障时的自动主从切换,这套架构已经平稳运行数年,经历住了多次实战的考验。 高可用架构大体如下图所示: 简单说一下sentinel实现高可用的原理: 集群的多个(2n+1,N>1)哨兵会定期轮询redis的所有master/slave节点,如果sentinel集群中超过一半的哨兵判定redis某个节点已主观下线,就会将
|
监控
一个 datanode 宕机,恢复流程
一个 datanode 宕机,恢复流程
318 0
|
安全 数据库
事务故障恢复
事务故障恢复
284 0
事务故障恢复
|
SQL 关系型数据库 MySQL
|
运维
服务挂了,怎么自动恢复?
架构设计上,避免单点,使用故障自动转移固然能够保证系统的高可用,是否还有其他的方案,让挂掉的服务自动启动呢,这里给大伙推荐一个常见的运维工具 supervisor。
1053 0

热门文章

最新文章