抱歉,您的浏览器无法访问本站
本页面需要浏览器支持(启用)JavaScript
了解详情 >

Enjoy your life

AEnjoy's Blog

最近运维同事提出了一个需求:
在上层,我们目前有一个中央配置中心(依托于我们内部的CMDB)用于管理DHCP服务器和PXE相关的的配置和策略(运维平台),以便在需要时可以动态调整;
在下层一个大型数据中心网络中,需要设计一个能够支持十万级节点的DHCP服务器系统,同时还需要兼具PXEServer用于提供PXE启动服务(包括:裸金属装机、无盘启动)。
这个系统需要具备高可用性、可扩展性和负载均衡能力,以确保在高并发环境下能够稳定运行。

在这个量级,传统的单体架构已经无法满足需求,因此需要采用分布式架构来实现dhcp服务的可扩展性和高可用性。

目前,有两类ip分配:纯动态:在地址池中随机分配;纯静态:根据mac地址分配固定ip。

Pxe server:对于特定mac+来自pxe client的请求,我们还需要修改本机的配置文件(grub)用于实现特定配置(如ubuntu,windows,centos)pxe启动,这又涉及到了文件的并发读写。

整体系统实现思路很简单,但要保证一致性还是有一定难度的,下面我将详细描述这个系统的设计思路。

试着回答一下这个有趣的消费-生产问题吧:

  1. 这是一个使用消息队列解耦多个生产者和多个消费者的系统。
  2. 生产者生产的消息是有分区的(按project_id分区),分区也会动态分配。
  3. 消费者需要竞争消费消息,每个消费者可以消费多个分区。
  4. 对于一个分区,最多有不超过1/n个消费者在消费。
  5. 生产者和消费者根据性能和数据量,会在kubernetes中进行动态的扩缩容。

消息需要尽可能的被均匀地分配到消费者上,以实现负载均衡。

消息需要尽可能的N等分,这N份消息将分配给消费者服务A(A的数量N>=2A)

e.g: 1/10 情景: 消息需要尽可能的10等分,这10份消息将分配给消费者服务A(A的数量>=5),对于不满足5的倍数情况,如23个消费者,则余下3个随机分配

在这种动态输入输出的情况下,我们该如何设计一个消息队列负载均衡系统呢,如何保证3个9的SLA呢?

最近有朋友问 我去哪了,为什么不更新文章了…

有时候我们需要需要实现通过浏览器选择文件获取文件信息而不上传文件, 这个时候JavaScript的内置api就足以完成需求. 但是,如果我们需要获取到文件的完整路径, 那么对不起, 由于为了安全避免xss攻击, 现代的浏览器仅能获取到一个虚假的路径或者根本无法获取(IE10之前的浏览器可以获取到完整路径).

如果我们是本地Web应用, 这个问题就可以得到解决.解决方案有Electron封装,或者提供一个运行在本地的Agent用于获取文件路径,再由前端选择文件提交至 Agent或后端, 如果选择前者,再由Agent将路径间接传递至后端.

本文分享使用Go作为后端,Vue作为前端的,一起运行在本地的Web应用解决方案.

(附完整代码)

本文介绍golang中的返回值有一个语法糖,可以帮助我们减少代码量;

func loadConfigYaml(f string) (defaultConfig yamlConfig)

同时还介绍func (c *Struct)FunName与func (c Struct)FunName区别

使用最新的nginx主线版本1.25,给网站开启quic支持。

本文不探讨手动编译,而是使用主线安装直接启用quic特性

环境:Debian12+nginx1.25

在某些特殊时期,我们的科学上网工具不太好使的时候,我们还有要经常上github找资源、浏览v2ex和查询维基百科的需求,我们可以通过绕过GFW的SNI阻断来避免一些简易网站访问难的问题。

自己在写一个项目,目前遇到的问题是:根据csdn和axios官网的说明,发送简单POST请求的时候,后端可能没办法正确处理数据,浅浅记录一下解决方案。

自己在写一个项目,目前遇到了问题:前端需要向后端执行ajax请求获取数据,需要传递cookie。如果使用默认的代码不进行配置则会出现跨域问题cors报错,本文将解决问题.

rootfs版CatWrt(OpenWrt)启动镜像的定制

包括镜像扩容,源修改,软件包定制





本站总访问量:0