合肥光源束测系统高可用集群评估的推进
先贴几张图，左右的X、Y、Z的曲线分别为某个束团（图中index编号）的条带和纽扣BPM的测量波形计算后的曲线，横坐标为圈数，取的波形为10ms，含45339圈的信息。
由于两个BPM离的很近，虽然是不同类型的BPM，波形信号特征不一样，但是计算得到的X、Y、Z的变化直观看起来很一致。
上图是展开看的局部一段。如果仅仅从500us的波形，很难想象的到10ms更长尺度会看到什么样的效果。
即使10ms的波形展示的某束团3维位置信息，从前几副的曲线振荡看，不同组还是看不到规律，感觉象一个更长周期里的局部，如果能更长的连续时间的观测就更好了。
不过在10GHz采样率下，即使短短的10ms波形，基本上已经达到了现在示波器的极限，采集一组波形的数据量800MB需要100G左右内存才能正常处理，如果更长，100ms，8GB的一组波形，1T的内存，基本已经达到现在的单台服务器资源的极限了。
上图是仅仅开启重采样功能和没开启时内存消耗的对比，如果开启更多的计算，比如计算每个束团3维信息的频谱并注入PV、SVD提取等功能，需要消耗的内存更多。
10ms一组的波形数据读取的周期大约150秒，处理的周期要超过一倍，现在已经在程序里几个关键的环节采用多线程并行处理提高速度，未来如果有更高分辨率、更大容量能获取更长波形的示波器定会第一时间申请来试用，并尝试使用GPU或者计算集群的方式能提高速度使得瓶颈在波形的读取速度。
所有这些尝试都是围绕着合肥光源储存环逐束团参数测量工作在推进，每个循环处理得到的所有信息都在以600秒的周期在灌入数据库（除了每组800MB数据量的原始波形外，太大，没法存入，以后想办法），每天存进80GB左右的数据量，随着后期增加的PV越来越多，每天存档的数据量会越来越大，数据库的情况可以从这里看到：
通过iSCSI协议分配给数据库云主机的140TB的NAS空间估计连续存1两年就满了。并且后继为了模拟未来先进光源更大规模的应用场景，还要做更重的负荷测试。
搭起的基于示波器的逐束团3维测量系统，并没有申请专门的经费支持，仅仅是利用每年的运行费购买的示波器和服务器设备，从开始的单通道到后来的四路同时获取，从开始的500us到后来的10ms，需要使用的服务器计算资源必然会越来越大。
后来从上海回来，明显感觉到服务器资源不够，之后升级内存，并在单台服务器上做更重度测试，云主机重负荷采集存档的过程中，克隆、镜像等等后台极重度消耗磁盘IO、网络IO以及内存的大流量管理等操作丝毫不影响采集存档等系统的云主机运行，在Zstack架构下单台服务器的使用现在已得心应手，爽利无比。
下一步就是为了未来光源测试多节点，并且搭建起来的多节点系统是要用在现光源上，并且提出了申请：
我想理由应该够充分了吧？！这样的3节点集群管理，一定是要连在一个交换机上的，要不然节点之间的后台管理流量会占用很大的网络带宽而影响控制网的运行。新光源束测系统服务器协同管理的后台流量、示波器的长波形、束斑监测的图像等都是海量数据，以后要考虑这些设备的单独组网，以后另发贴规划吧。
为什么要3节点？两个不行么？
