关于我们

质量为本、客户为根、勇于拼搏、务实创新

< 返回

通过Nginx消费大量的PowerShellDSCSendReport请求

发布时间:2022-07-27 13:54:08

背景

接上一文,PowerShell DSC SendReport
说由于某些原因,DSC Pull Server无法访问,而DSC Node每天会进行2次操作,每次操作都会Report Status

在Pull Server无法访问的时候,Node会在本地cache 这些请求,每隔10分钟去尝试重新发送。(试出来的)
假如Node数量为10000台,每台Server每天将会cache 2 个Status Report Request。如果Pull Server 30天无法访问,那么将累计积累
10000 * 2 * 30 = 600000(60万)个请求。
等Pull Server可访问时候,虽然不是60万请求同时发送,但DSC Webservice默认使用的Access DB的最大并发是255(最大存储是2GB),瓶颈在这里产生,造成大量的请求堆积,Nginx worker不足,Nginx返回超时等问题。
上一文中,我们只看到了Nginx的错误,就直修改Nginx的配置,只能说头痛有时候不能直接医头,也可能是牙痛造成的。

模拟发送SendReport

上文中我们也使用PowerShell脚本模拟PowerShell DSC SendReport的请求
如果参数正确,会得到HTTP 200的Response结果

<?xml version="1.0" encoding="utf-8"?>
<d:SendReport xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices" xmlns:m="http://schemas. microsoft.com/ado/2007/08/dataservices/metadata">SavedReport</d:SendReport>

Nginx配置特定请求过滤

在Server block配置:

location /.*/SendReport$
{
    default_type 'application/xml;charset=utf-8';
    return 200 '<?xml version="1.0" encoding="utf-8"?>
<d:SendReport xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices" xmlns:m="http://schemas. microsoft.com/ado/2007/08/dataservices/metadata">SavedReport</d:SendReport>'
}

所有SendReport请求都会被直接响应,而不是通过Nginx-->IIS-->DSC WebService-->ACCESS去处理保存。(那数据不要了?是的,根据业务本身需求,日常的check和update产生的日志意义不是很大,可丢弃)
可以在其中加入Accesslog,从而确认该拦截是否有效。

如何验证Node接受了Response

  1. PowerShell远程一台Node
  2. 执行update-dscconfiguration或者start-dscconfiguration -UseExisting,让Node LCM执行一次,执行完毕会触发一次Status Report
  3. 执行的结果可以通过get-dscconfigurationstatus查看,这个命令找到就是C:windowsSystem32ConfigurationDSCStatusHistory,mof内容
    如果打开该文件,会发现每个job都会有一个ReportSent的一个标识,值为1或者2。
    经过验证,1:未发送成功 2:发送成功

/template/Home/DawnNew/PC/Static

立即注册风纳云账号,免费体验多款产品

立即注册