通过Nginx消费大量的PowerShell DSC SendReport请求

背景

接上一文，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:\windows\System32\Configuration\DSCStatusHistory,mof内容
   如果打开该文件，会发现每个job都会有一个ReportSent的一个标识，值为1或者2。
   经过验证，1：未发送成功 2：发送成功