CN116232843A - 以应用组维度批量管理业务机器集群的多运维管理方法及系统 - Google Patents

以应用组维度批量管理业务机器集群的多运维管理方法及系统 Download PDF

Info

Publication number
CN116232843A
CN116232843A CN202310223977.9A CN202310223977A CN116232843A CN 116232843 A CN116232843 A CN 116232843A CN 202310223977 A CN202310223977 A CN 202310223977A CN 116232843 A CN116232843 A CN 116232843A
Authority
CN
China
Prior art keywords
machine
node
master
application group
master machine
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202310223977.9A
Other languages
English (en)
Inventor
贾晓辉
陈宇
汪宁
芦帅
陈鹏
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hangzhou Ping Pong Intelligent Technology Co ltd
Original Assignee
Hangzhou Ping Pong Intelligent Technology Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hangzhou Ping Pong Intelligent Technology Co ltd filed Critical Hangzhou Ping Pong Intelligent Technology Co ltd
Priority to CN202310223977.9A priority Critical patent/CN116232843A/zh
Publication of CN116232843A publication Critical patent/CN116232843A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/04—Network management architectures or arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Multi Processors (AREA)
  • Computer And Data Communications (AREA)

Abstract

一种以应用组维度批量管理业务机器集群的多运维管理方法和系统，方法包括：S1：设置堡垒机构架：S2：在每个Master机器下设置哨兵程序；并在每个节点的Master机器上设置接入新机器的初始化脚本；S3：‑旦某个节点接入一台新业务主机，该节点的Master机器触发一次Salt‑Minion接入事件：在新机器执行该初始化脚本后完成包括按照应用分组‑内网IP‑网络区域的三段式规则命名该新机器、并在本机器上安装Salt‑Minion和配置所属Master机器在内的初始化步骤；S4：当某应用组更新运维管理数据时，确定该应用组所在节点，通过对应节点的Master机器，根据应用分组这个字段，获到同一个应用分组的所有机器名称，进而通过Salt‑Minion给所述些机器分别写入该批量运维管理的配置文件。

Description

以应用组维度批量管理业务机器集群的多运维管理方法及 系统
技术领域
本发明涉及一种运维管理方法，尤其涉及一种以应用组维度批量管理业务机器集群的多运维管理方法及系统。
背景技术
阿里巴巴集团控股有限公司在201910585545.6公开了一种服务器的管理方法、装置和设备，包括：第一堡垒机获取运维代理操作，第一堡垒机用于对第一区域内的服务器进行运维管理；根据运维代理操作确定第二堡垒机，第二堡垒机用于对第二区域内的服务器进行运维管理；利用第一堡垒机代理第二堡垒机对第二区域内的服务器进行运维管理。通过第一堡垒机获取运维代理操作，根据运维代理操作确定第二堡垒机，并利用第一堡垒机代理第二堡垒机对第二区域内的服务器进行运维管理，有效地实现了利用第一堡垒机统一管理跨区域的服务器，第一堡垒机与第二堡垒机之间无需公网IP。
在堡垒机为主导的运维管理系统中，往往设置有超级管理员、管理员、运维人员和开发人员，并按照统一按照登录人员的特性来管理。例如在首次注册的过程中，可以默认注册角色为开发人员角色，而后可以根据需要由系统管理员在系统授权某用户角色为运维人员，运维人员有审批权限申请的权限，系统管理员除了审批权限外，额外有分配用户角色以及清理删除离职人员的权限。但是，上述运维管理方式只适用于单个云端对应的运维管理系统中，无法适应具有高度可扩展性的网络环境，在面临多个云端对应的运维管理场景时存在运维管理结构复杂，运维成本高等一系列问题。
我司在CN202111535716.8曾公开一种运维方式。基于预设的数据结构对部署机器进行命名；在部署机器出现非正常运行状态的情况下，根据命名获取部署机器所在的网络节点和部署机器的应用业务其中：数据结构包括部署机器的应用业务、部署机器所在的网络节点名称以及部署机器于网络节点中的私域IP地址。
如何利用该结构进行有效运维，正是本发明需要解决的问题。
发明内容
本发明提供一种以应用组维度批量管理业务机器集群的多运维管理方法，以解决现有技术中不能通过命名进行有效运维的问题。
一种以应用组维度批量管理业务机器集群的多运维管理方法，进一步包括：
S1：设置堡垒机构架：
按各自业务站点的独立网络区域划分，把每个不同地域独立VPC网络环境视为一个独立节点，后在每个节点中规划一台机器作为该节点的安全入口Login机器和规划一台作为该节点的运维管控Master机器，该Master负责管理该节点的所有业务主机；
设置一台Central总控机器，作为每个独立节点的Login机器、Master机器的上级Master机器；该Central总控机器被部署WEB系统，其具有全局系统的构建文件和配置信息，该Central总控机器定期与各个节点的Master机器保持该节点相关数据同步；
S2：在每个Master机器下设置哨兵程序，其负责监听记录所在节点的包括业务主机接入、下线在内事件，联动更新本地监控或者批量运维使用的配置文件，所述批量运维使用的配置文件进一步包括应用组维度的配置文件；并在每个节点的Master机器上设置接入新机器的初始化脚本；
S3：一旦某个节点接入一台新业务主机，该节点的Master机器触发一次Salt-Minion接入事件：在新机器执行该初始化脚本后完成包括按照应用分组-内网IP-网络区域的三段式规则命名该新机器、并在本机器上安装Salt-Minion和配置所属Master机器在内的初始化步骤；
S4：当某应用组更新运维管理数据时，确定该应用组所在节点，通过对应节点的Master机器，根据应用分组这个字段，获到同一个应用分组的所有机器名称，进而通过Salt-Minion给所述些机器分别写入该批量运维管理的配置文件。
与现有技术相比，系统内规范识别机器ID信息为三段式结构，应用分组-私网IP-区域标识，如bigdata-172.16.4.48-Hangzhou这个机器ID信息，解析出第一个字段可以获取所有应用分组信息，进而可以获取该应用分组有哪些机器，分布在哪几个网络区域，进而进行以应用分组维度的批量管理能力以及以应用分组维度查看某个应用集群的实时监控等，日常交流也非常方便，机器ID贴过去，不需要多沟通，整个系统就明白，是哪个业务机器，私网IP是什么，在什么地方的机器，也可以考虑和机器名称统一规范起来，有了这种机器ID信息的规范，系统内部可以非常优雅的生成相关管理配置文件和监控配置文件，极度方便管理且解析效率高。
附图说明
图1为以应用组维度批量管理业务机器集群的多运维管理系统原理示例图；
图2为以应用组维度批量管理业务机器集群的多运维管理方法原理图。
具体实施方式
业界对海量主机安全高效的管理有很多方案，如Ansible，Puppet，SaltStack都能一定程度解决企业海量主机高效安全管理的问题，根据这些工具系统出现时间来看，先有Puppet(功能全，复杂)后有Ansible(简单方便)，再后来SaltStack(高效、简单)可以理解平衡了两者而且引进了很多新的思路，SaltStack是一种基于C/S架构的服务器基础架构集中化管理工具，管理端称为Master，客户端称为Minion。SaltStack具备配置管理、远程执行、监控等功能，开源版本的SaltStack只是提供基础方案，而在实际工作中还是需要大量维护技巧分组和监控配置等问题以及面临企业多个独立网络节点运维管理等问题的挑战，我们期望可以对多个网络环境统一管控和自动监控(不依赖跨节点网络打通，网络打通固然可以解决部分问题，但是考虑到海量业务主机监控数据的更科学的走各自内网实时收集以及未来超大规模IT系统的扩展，所以未雨绸缪考虑分而治之的节点内部自治理方案)。
请参阅图1，其为以应用组维度批量管理业务机器集群的多运维管理系统的示意图。本申请人将根据我们各自业务站点的独立网络区域划分，把每个不同地域独立VPC网络环境视为一个独立节点，然后在这个节点中规划两台机器，一台作为安全入口Login机器(功能类似咱们当前的jumpserver)，一台作为运维管控Master机器，在该Login和Master分别部相关基础服务，该Master即负责管理该节点所有业务主机。我们可以再规划一台中央Central总控机器，作为每个独立节点的Login，Master的上级Master机器，这样Central总控机器作为调度中心管理各自独立节点的Login和Master机器，进而间接统一管理各节点主机。我们Central将部署WEB系统，合并各项日常必要功能，将统一收集到的各项数据，作为数据总览展现我们所有节点的IT资源情况，以及按照应用分组维度展现实时监控相关数据等等，让我们对各项IT资源可以一目了然。
本发明的多运维管理系统，其进一步包括：
多个独立节点：按各自业务站点的独立网络区域划分，把每个不同地域独立VPC网络(Virtual Private Cloud，虚拟私有云网络)环境视为一个独立节点，每个节点中至少包括一台机器作为该节点的安全入口Login机器、一台作为该节点的运维管控Master机器。其中：
在每个Master机器下设置哨兵程序，用以其负责监听记录所在节点的包括业务主机接入、下线在内事件，联动更新本地监控或者批量运维使用的配置文件，所述批量运维使用的配置文件进一步包括应用组维度的配置文件。在每个节点的Master机器上设置接入新机器的初始化脚本：用以一旦某个节点接入一台新业务主机，该节点的Master机器触发一次Salt-Minion接入事件。Salt-Minion接入事件进一步包括：在新机器执行该初始化脚本后完成包括按照应用分组-内网IP-网络区域的三段式规则命名该新机器、并在本机器上安装Salt-Minion和配置所属Master在内的初始化步骤。
一Central总控机器，作为每个独立节点的Login机器、Master机器的上级Master机器；该Central总控机器被部署WEB系统，其具有全局系统的构建文件和配置信息，该Central总控机器定期与各个节点的Master机器保持该节点相关数据同步，用以当某应用组更新运维管理数据时，确定该应用组所在节点，通过对应节点的Master机器，根据应用分组这个字段，获到同一个应用分组的所有机器名称，进而通过Salt-Minion给所述些机器分别写入该批量运维管理的配置文件。
本发明的核心在于三权分立。Login机器只负责安全登录入口；Master机器只负责执行调度任务；Central机器只负责任务的下发调度；这样系统高度安全可依赖，比如Central服务有问题不会影响已分配的权限，而且各节点互相独立，彼此不影响；而且Login和Master某种意义上是一种“经理人”的角色，一旦某节点的Login或者Master机器出现不可恢复的异常，我们的总控Central机器可以快速的重新在该节点生成新的Login或者Master，因为总控机器拥有每个节点Login和Master的配置数据以及全量的系统权限分配历史数据，可以快速生成，而且我们的总控机器的数据每天备份，每天同步到每个节点的Master机器，这样我们的总控的数据非常安全，这种系统根据实际项目和企业发展需要，扩展管理新的节点。即，统一各节点主机的配置管理：采用总控+分布式的堡垒机架构，配套架构对应的工作机制，统一了各节点主机的配置管理，实现多节点的运维。
以下具体说明。
请参阅图2，其为一种以应用组维度批量管理业务机器集群的多运维管理方法的流程图。它进一步包括：
S110：设置堡垒机构架：
按各自业务站点的独立网络区域划分，把每个不同地域独立VPC网络环境视为一个独立节点，后在每个节点中规划一台机器作为该节点的安全入口Login机器和规划一台作为该节点的运维管控Master机器，该Master负责管理该节点的所有业务主机；
设置一台Central总控机器，作为每个独立节点的Login机器、Master机器的上级Master机器；该Central总控机器被部署WEB系统，其具有全局系统的构建文件和配置信息，该Central总控机器定期与各个节点的Master机器保持该节点相关数据同步；
S120：在每个Master机器下设置哨兵程序，其负责监听记录所在节点的包括业务主机接入、下线在内事件，联动更新本地监控或者批量运维使用的配置文件，所述批量运维使用的配置文件进一步包括应用组维度的配置文件；并在每个节点的Master机器上设置接入新机器的初始化脚本；
S130：一旦某个节点接入一台新业务主机，该节点的Master机器触发一次Salt-Minion接入事件：在新机器执行该初始化脚本后完成包括按照应用分组-内网IP-网络区域的三段式规则命名该新机器、并在本机器上安装Salt-Minion和配置所属Master机器在内的初始化步骤；
S140：当某应用组更新运维管理数据时，确定该应用组所在节点，通过对应节点的Master机器，根据应用分组这个字段，获到同一个应用分组的所有机器名称，进而通过Salt-Minion给所述些机器分别写入该批量运维管理的配置文件。
Central总控机器解析业务主机的命名时，根据网络区域这个字段找到其所属的Master执行相应任务；
在新机器执行该初始化脚本后完成包括按照应用分组-内网IP-网络区域的三段式规则命名该新机器，每个网络区域独立命名的内网IP，不同的网络区域下的内网IP可以相同。
系统默认的机器命名规则“应用分组-内网IP-网络区域”。应用分组-内网IP-网络区域是说明该机器所在的应用组，该机器所在的网络区域(即节点信息)和该网络区域内机器所在的内网IP信息。通过该机器所在的网络区域(即节点信息)和该网络区域内机器所在的内网IP信息实现该新机器的定位。比如：
gateway-192.168.104.214-Hangzhou
这个机器名称，在整个多运维管理系统中都可以解析出是一台gateway机器，其内网IP是192.168.104.214，这台机器在Hangzhou这个网络区域下。
当用户提交上述机器的权限申请后，Central总控机器根据网络区域这个字段可以找到其所属的调度Master来执行任务，所以每个网络区域内网IP可以重复，不影响系统全局管理。
对于各自节点的“哨兵”程序来说，当节点有新的机器接入，可以很自然的通过字段分割，比如根据应用分组这个字段，拿到同一个应用分组的所有机器名称，进而写入批量运维管理的配置文件，
如/etc/salt/master.d/nodegroup.conf和/etc/ansible/hosts
同时我们还可以自动生成prometheus的监控配置文件，例如：
Figure BDA0004117913340000081
这样一旦触发报警，系统也可以一目了然，报警来自哪个网络区域，什么业务的机器，这些能力都源自系统非常简练的三段式命名结构。
另外，本方法还需要说明Login机器和Master机器等在内的三权分立的管理方法的好处。Login机器作为所在节点的安全入口机器，对外暴露标准的sshd端口，用户通过被分配到login_id_rsa登录到对应Login机器以进入该节点的内网。在节点的Master机器部署基础组件，其进一步包括：部署Salt-Minion接收Central总控机器的调度任务；部署Redis记录本节点内用户权限-机器对应的相关数据，部署Salt-Master接收管理本节点内安装有Salt-Minion的业务主机。Master机器作为所在网络区域的运维管控机器，对外不暴露任何端口，对内信任Central总控机器的网络访问。每个节点的Login和Master初始安装完成后，Central总控机器对其各自进行基础模版管理的同步：
#salt-N login state.apply group.login完成对Login机器的模版同步、
#salt-N master state.apply group.master完成对Master机器的模版同步。
实际上对于Central机器来说，一条命了salt′*′state.apply即可完成对一个节点的两组机器的模版同步管理，包含了对两组机器基础配置的同步，每个节点“哨兵”程序的下发等等。
具体来说，新机器的初始化，即就是新机器被所在节点的Salt-Master接入管理，每个节点的Master有个接入机器初始化脚本，在新机器执行后即刻完成初始化，该脚本核心功能就是新机器的命名规范化和安装Salt-Minion并配置所属Master，执行后即刻被所在节点的Master机器接入管理，同时触发接入事件，记录本区域的Redis和远端总控的Redis。
Central总控机器上包括每个节点的Login机器和Master机器在内的有全局系统的构建文件和配置，并且定期会把核心数据同步备份到各个节点的Master机器，一般情况下总控全局系统的所有文件也会同步到企业Git仓库，确保不会丢失。这种设置使得系统的核心配置文件不存在丢失的问题；还有Central总控机器如果出问题了，系统可以把全局系统的构建文件从任何一个Master或者git仓库下载下来，快速构建新的Central总控机器。还有，某一Login机器或者某一Master机器出问题了，Central总控机器一样可以通过模版和核心数据生成对应新的Login机器或Master机器。
对用户机器权限管理是通过Central总控机器调度适配Master给本用户下发创建其账号在对应机器下的一个任务；对机器监控操作是通过Central总控机器调度适配Master给所在节点所有业务机器下发部署监控agent程序的一个任务；日常运维操作是通过Central总控机器在适配Master对适配组机器或者全局机器执行某个任务，以实现统一管理所以无论是用户权限的分配，机器监控和网络监控的日常部署，还是日常运维的批量管理，本系统都可以抽象为，Central总控机器调度某个区域节点的Master下发执行某个任务，自然也就做到了统一管理；后续本发明还可以继续沿着这种设计理念，把容器集群的管理融合进来，不断的扩展管理对象，使其功能性更加强大和高效，某种程度上系统管理几十个网络区域和管理一个网络区域没有什么区别；无论是几台机器还是几十台几千台机器，系统管理成本差不多。
依上所述，通过对应节点的Master机器，根据应用分组这个字段，获到同一个应用分组的所有机器名称，进而通过Salt-Minion给所述些机器分别写入该批量运维管理的配置文件进一步包括：通过Central总控机器调度适配Master，给符合要求的机器执行对应的配置文件，所述符合要求进一步包括应用组名符合要求。应用组可以按照管理系统中实现的功能来分不同机器的应用组，也可以按管理系统中实现的应用来分不同机器的应用组，这种三段式命名方式和系统的管理方法，本发明可以实现以应用组维度批量管理业务机器集群。
另外，本方法中，当新业务主机接入时，可以自动生成prometheus的监控配置文件；本端Master机器检测到某一报警信息，并所述报警信息包含报警所在的主机名一并同步至Central总控机器；该Central总控机器通过所述发生报警信息的主机名字，解析出该报警信息主机所在的应用分组和所在的网络区域；若按照所述报警信息需要处理本网络区域和/或本应用组的相应业务主机时，给适配节点的Master机器下发相应的执行任务。
在该业务主机上自动生成prometheus的监控配置文件进一步包括：
核心配置统一从Central总控分发到各个节点Master，具体到每个节点的监控对象：当节点中新业务主机接入时，在所述主机上自动生成该配置；
通过云服务商的API，把Aliyun和AWS云监控数据采集配置报警，也在Master机器上部署prometheus网络监控组件blackbox_exporter作为该节点的网络监控探测服务；
业务主机接入该节点时，通过本节点的Master机器获得prometheus的监控配置文件；
设置info/warning/critical三个报警级别：本节点采集监控数据->本节点匹配预警规则->本节点发出包括电话在内报警的本节点报警自治理，同时也发起对Central总控机器本身的监控探测，及时发起预警通知，当然Central总控机器本身也对等的发起对各个节点Master的相关服务探测，完成系统本身自监控，这样无论是Central总控机器的基础服务出问题，还是各Master管控的基础服务出问题，都会被收到报警及时处理。
执行了接入脚本后，完成了被所在区域的Master机器的管理，根据预船坞设定默认的SaltStack执行模版规则，紧接着会对新机器做一系列的模版动作，主要可以包括但不限于7个通用模版
1.同步系列工具脚本在新机器的/opt/sys/目录下，init.sh初始化脚本，name.sh重命名脚本，src.sh我们编写的基础软件安装脚本等，这些脚本可以根据我们日常工作不断的扩展，也就是说新机器被接管后，我们约定俗称默认需要的一些工具脚本都在/opt/sys/目录下，方便每个技术人员(包括运维人员)获取；
2.写入默认的crontab任务，包括磁盘清理任务以及salt-minion自动拉起任务(放在salt-minion因为各种异常掉线的问题)，当然这些基础任务可以根据日常工作的需要不断的扩展
3.执行默认的基础配置，比如默认要打入的公钥信息，这个信息可以在我们各自节点的/srv/pillar/master.sls自定义和扩展，比如新机器一旦接入即刻打入系统的发布机器公钥，从而、完成了发布机器的通道问题，并且还自动同步了一些基础环境变量、已经调整机器连接数配置等
4.安装定义的基础工具，如vim，wget等
5.自动配置定义的安全sshd配置文件，安全上默认禁止了密码认证，全私钥认证以及该节点信任的内网IP和白名单用户
6.自动同步了salt-minion的相关配置
7.自动设置新机器的网络参数
8.一个自定义的模版，每个节点可以根据节点的需要，自定义相关的管理任务因为每个Master机器的模版配置文件都是由总控机器下发同步过去的，所以这些模版文件的扩展变更也都是从总控发起更新，然后同步到各个节点的Master，上面7个通用的初始化模版总控会负责更新和同步，1个节点自定义的模版总控不会更新。
综上所述，系统内规范识别机器ID信息为三段式结构，应用分组-私网IP-区域标识，如bigdata-172.16.4.48-Hangzhou这个机器ID信息，解析出第一个字段可以获取所有应用分组信息，进而可以获取该应用分组有哪些机器，分布在哪几个网络区域，进而进行以应用分组维度的批量管理能力以及以应用分组维度查看某个应用集群的实时监控等，日常交流也非常方便，机器ID贴过去，不需要多沟通，整个系统就明白，是哪个业务机器，私网IP是什么，在什么地方的机器，也可以考虑和机器名称统一规范起来，有了这种机器ID信息的规范，系统内部可以非常优雅的生成相关管理配置文件和监控配置文件，极度方便管理。
以下结合附图和具体实施例对本发明提出的一种用于固定软组织的锚钉及锚钉系统作进一步详细说明。根据下面说明，本发明的优点和特征将更清楚。显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本发明实施例的组件可以以各种不同的配置来布置和设计。
因此，以下对在附图中提供的本发明的实施例的详细描述并非旨在限制要求保护的本发明的范围，而是仅仅表示本发明的选定实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
应注意到：相似的标号在下面的附图中表示类似项，因此，一旦某一项在一个附图中被定义，则在随后的附图中不需要对其进行进一步定义和解释。上面结合附图对本发明的实施方式作了详细说明，但是本发明并不限于上述实施方式。即使对本发明做出各种变化，倘若这些变化属于本发明权利要求及其等同技术的范围之内，则仍落入在本发明的保护范围之中。

Claims (9)

1.一种以应用组维度批量管理业务机器集群的多运维管理方法，其特征在于，进一步包括：
S1:设置堡垒机构架：
按各自业务站点的独立网络区域划分，把每个不同地域独立VPC网络环境视为一个独立节点，后在每个节点中规划一台机器作为该节点的安全入口Login机器和规划一台作为该节点的运维管控Master机器，该Master负责管理该节点的所有业务主机；
设置-台Central总控机器，作为每个独立节点的Login机器、Master机器的上级Master机器；该Central总控机器被部署WEB系统，其具有全局系统的构建文件和配置信息，该Central总控机器定期与各个节点的Master机器保持该节点相关数据同步；
S2:在每个Master机器下设置哨兵程序,其负责监听记录所在节点的包括业务主机接入、下线在内事件,联动更新本地监控或者批量运维使用的配置文件,所述批量运维使用的配置文件进一步包括应用组维度的配置文件；并在每个节点的Master机器上设置接入新机器的初始化脚本；
S3:-旦某个节点接入-台新业务主机，该节点的Master机器触发一次Salt-Minion接入事件：在新机器执行该初始化脚本后完成包括按照应用分组-内网IP-网络区域的三段式规则命名该新机器、并在本机器上安装Salt-Minion和配置所属Master机器在内的初始化步骤；
S4:当某应用组更新运维管理数据时，确定该应用组所在节点，通过对应节点的Master机器，根据应用分组这个字段,获到同一个应用分组的所有机器名称,进而通过Salt-Minion给所述些机器分别写入该批量运维管理的配置文件。
2.如权利要求1所述的多运维管理方法，其特征在于，还包括：
在该业务主机上自动生成prometheus的监控配置文件；
本端Master机器检测到某一报警信息，并所述报警信息包含报警所在的主机名一并同步至Central总控机器；
该Central总控机器通过所述发生报警信息的主机名字，解析出该报警信息主机所在的应用分组和所在的网络区域；
若按照所述报警信息需要处理本网络区域和/或本应用组的相应业务主机时，给适配节点的Master机器下发相应的执行任务。
3.如权利要求1所述的多运维管理方法，其特征在于，还包括：
Central总控机器解析业务主机的命名时，根据网络区域这个字段找到其所属的Master执行相应任务；
在新机器执行该初始化脚本后完成包括按照应用分组-内网IP-网络区域的三段式规则命名该新机器，每个网络区域独立命名的内网IP，不同的网络区域下的内网IP可以相同。
4.如权利要求1所述的多运维管理方法，其特征在于，还包括：
Login机器作为所在节点的安全入口机器,对外暴露标准的sshd端口,用户通过被分配到login_id_rsa登录到对应Login机器以进入该节点的内网。
5.如权利要求1所述的多运维管理方法，其特征在于，还包括：
在节点的Master机器部署基础组件，其进一步包括：部署Salt-Minion接收Central总控机器的调度任务；部署Redis记录本节点内用户权限-机器对应的相关数据，部署Salt-Master接收管理本节点内安装有Salt-Minion的业务主机；
Master机器作为所在网络区域的运维管控机器,对外不暴露任何端口,对内信任Central总控机器的网络访问；
每个节点的Login和Master初始安装完成后，Central总控机器对其各自进行基础模版管理的同步：#salt-N login state.apply group.login完成对Login机器的模版同步、#salt-N master state.apply group.master完成对Master机器的模版同步。
6.如权利要求5所述的方法，其特征在于，还包括：
对用户机器权限管理是通过Central总控机器调度适配Master给本用户下发创建其账号在对应机器下的一个任务；
对机器监控操作是通过Central总控机器调度适配Master给所在节点所有业务机器下发部署监控agent程序的一个任务；
日常运维操作是通过Central总控机器在适配Master对适配组机器或者全局机器执行某个任务，以实现统一管理。
7.如权利要求2所述的多运维管理方法，其特征在于，在该业务主机上自动生成prometheus的监控配置文件进一步包括：
核心配置统一从Central总控分发到各个节点Master,具体到每个节点的监控对象：当节点中新业务主机接入时，在所述主机上自动生成该配置；
通过云服务商的API，把Aliyun和AWS云监控数据采集配置报警，也在Master机器上部署prometheus网络监控组件blackbox_exporter作为该节点的网络监控探测服务；
业务主机接入该节点时，通过本节点的Master机器获得prometheus的监控配置文件；
设置info/warning/critical三个报警级别：本节点采集监控数据—>本节点匹配预警规则—>本节点发出包括电话在内报警的本节点报警自治理，同时也发起对Central总控机器本身的监控探测，及时发起预警通知，当然Central总控机器本身也对等的发起对各个节点Master的相关服务探测，完成系统本身自监控，这样无论是Central总控机器的基础服务出问题，还是各Master管控的基础服务出问题，都会被收到报警及时处理。
8.如权利要求1所述的多运维管理方法，其特征在于，通过对应节点的Master机器，根据应用分组这个字段,获到同一个应用分组的所有机器名称,进而通过Salt-Minion给所述些机器分别写入该批量运维管理的配置文件进一步包括：
通过Central总控机器调度适配Master，给符合要求的机器执行对应的配置文件，所述符合要求进一步包括应用组名符合要求。
9.一种以应用组维度批量管理业务机器集群的多运维管理系统，其进一步包括：
多个独立节点：按各自业务站点的独立网络区域划分，把每个不同地域独立VPC网络环境视为-个独立节点，每个节点中至少包括一台机器作为该节点的安全入口Login机器、一台作为该节点的运维管控Master机器；其中
在每个Master机器下设置哨兵程序,用以其负责监听记录所在节点的包括业务主机接入、下线在内事件,联动更新本地监控或者批量运维使用的配置文件,所述批量运维使用的配置文件进一步包括应用组维度的配置文件；
并在每个节点的Master机器上设置接入新机器的初始化脚本：用以-旦某个节点接入一台新业务主机，该节点的Master机器触发一次Salt-Minion接入事件：在新机器执行该初始化脚本后完成包括按照应用分组-内网IP-网络区域的三段式规则命名该新机器、并在本机器上安装Salt-Minion和配置所属Master在内的初始化步骤；
一Central总控机器，作为每个独立节点的Login机器、Master机器的上级Master机器；该Central总控机器被部署WEB系统，其具有全局系统的构建文件和配置信息，该Central总控机器定期与各个节点的Master机器保持该节点相关数据同步，用以当某应用组更新运维管理数据时，确定该应用组所在节点，通过对应节点的Master机器，根据应用分组这个字段,获到同一个应用分组的所有机器名称,进而通过Salt-Minion给所述些机器分别写入该批量运维管理的配置文件。
CN202310223977.9A 2023-03-02 2023-03-02 以应用组维度批量管理业务机器集群的多运维管理方法及系统 Pending CN116232843A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310223977.9A CN116232843A (zh) 2023-03-02 2023-03-02 以应用组维度批量管理业务机器集群的多运维管理方法及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310223977.9A CN116232843A (zh) 2023-03-02 2023-03-02 以应用组维度批量管理业务机器集群的多运维管理方法及系统

Publications (1)

Publication Number Publication Date
CN116232843A true CN116232843A (zh) 2023-06-06

Family

ID=86588887

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310223977.9A Pending CN116232843A (zh) 2023-03-02 2023-03-02 以应用组维度批量管理业务机器集群的多运维管理方法及系统

Country Status (1)

Country Link
CN (1) CN116232843A (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117118799A (zh) * 2023-10-20 2023-11-24 杭州优云科技有限公司 一种服务器集群的带外管理方法、装置及电子设备

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117118799A (zh) * 2023-10-20 2023-11-24 杭州优云科技有限公司 一种服务器集群的带外管理方法、装置及电子设备
CN117118799B (zh) * 2023-10-20 2024-02-27 杭州优云科技有限公司 一种服务器集群的带外管理方法、装置及电子设备

Similar Documents

Publication Publication Date Title
US10470148B2 (en) Mobile device management
KR101891506B1 (ko) 하나 이상의 클라우드 시스템 상에 애플리케이션들을 이식 가능하게 배치하기 위한 방법들 및 시스템들
US8296755B2 (en) Method and system for executing and undoing distributed server change operations
CN111274001B (zh) 微服务管理平台
US7441024B2 (en) Method and apparatus for applying policies
US7769835B2 (en) Method and system for identifying and conducting inventory of computer assets on a network
RU2417416C2 (ru) Развертывание решений в ферме серверов
US7165087B1 (en) System and method for installing and configuring computing agents
US20020004824A1 (en) Method and apparatus for automatically deploying data and simultaneously Executing computer program scripts in a computer network
JP2008519327A (ja) ネットワーク管理アプライアンス
US20220269539A1 (en) Redistributing update resources during update campaigns
CN103188088A (zh) 设备信息采集系统及方法
CN116232843A (zh) 以应用组维度批量管理业务机器集群的多运维管理方法及系统
CN113965585A (zh) 一种多云互联方法及装置
CN111309557B (zh) 一种多操作系统的监控方法、装置、设备和介质
US10963314B2 (en) Discovery and mapping of a platform-as-a-service environment
CN110162312B (zh) 一种基于IML的BeeGFS配置方法与装置
CN116192600A (zh) 一种自动统一管理堡垒机各节点的运维方法和系统
US20240211604A1 (en) Binding configuration state to a blockchain
Neumair et al. Case study: applying management policies to manage distributed queuing systems
Gianola Exploring the OCSF Framework in AWS: Design, Implementation and Performance Analysis of a Security Lake Platform
CN116149840A (zh) 用于微服务架构中的基于云的混合服务网格的系统和方法
WO2022010339A1 (en) System and method for seamless provision, configuration, and deployment of enterprise-grade private blockchain network
Bohdanowicz et al. The problematic of distributed systems supervision-an example: Genesys
CN117880287A (zh) 堡垒机自动化管理云上服务器的方法及其系统

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination