1、问题描述n多租户系统中，当一个节点发生性能危机，不能满足SLO时候，可以将节点里面的部分租户迁移到其他节点来缓解危机n危机来源：租户压力增大、节点性能降低1谢谢您的观赏2019-6-30架构n本文设计了一个多租户自控系统Delphi，使用Pythia 探测危机，然后进行租户迁移nPythia 使用决策树分类算法首先训练租户模型租户模型（资源消耗），然后节点上多个租户模型向量构成节点模型节点模型预测危机。nDelphi 定期收集各节点数据，有危机发生执行迁移，包括查找需要迁移的组合和迁移的目标2谢谢您的观赏2019-6-30架构3谢谢您的观赏2019-6-30探测危机n4谢谢您的观赏2019-6
2、-30探测危机n5谢谢您的观赏2019-6-30租户迁移6谢谢您的观赏2019-6-30租户迁移n穷举法，是所有D到所有节点N的排列组合问题，然后寻找到最优的，使用BFS算法优先考虑临近的节点BFS算法的改进，以局部最优代替全局最优，遍历直接邻居，然后找到局部高峰迭代度量标准：度量标准：7谢谢您的观赏2019-6-30实验n环境：（1）16 database servers,6 servers workloads (workers), 1 Delphi server（2）The database servers run PostgreSQL 9.1 on CentOS 6.3（3）Our mu
3、ltitenant benchmark is capable of generating a wide variety of workloadsn结果（1）Node Model8谢谢您的观赏2019-6-30实验（2）Crisis Mitigation9谢谢您的观赏2019-6-30个人工作n环境：P2P网络，MongoDB数据库，多租户环境 目标：查询处理， SLA利益最大化n涉及问题：查询时间预测，危机探测，SLA收益模型，调度策略n结构：预测-危机探测-两阶段调度10谢谢您的观赏2019-6-30个人工作整体模型整体模型T1 、T2T1 、T3、 T4T2 、T3 、 T4T1、T3信息
4、流查询流获取租户模型T1其余节点的信息在租户模型T1内转发查询流获取租户模型T1其余节点的信息在租户模型T1内转发查询流租户模型T1N1N2N3N4节点N1上租户模型配置表 profile以节点N1为例，属于两个租户模型，所以配置表里会有T1、T2的信息，第三行是记录相关节点的最新镜像（CPU、I/O、内存信息）N1N2N3N4T10110T20001Snapnullsss租户模型211谢谢您的观赏2019-6-30个人工作n原文节点模型包括租户模型，通过租户模型来预测节点性能是否满足每个租户SLO，预测危机n节点模型是定期查询资源状况（CPU，Mem，I/O）来判断是否差生性能危机。租户模型
5、包括节点模型，主要是为了给出SLA收益模型，记录租户的相关节点12谢谢您的观赏2019-6-30个人工作租户模型租户模型T1为例为例N2N1N3等待队列执行器等待队列执行器等待队列执行器接收单元接收单元接收单元查询流利润查询流查询流危机探测否是调度第二阶段：选取定期监控节点资源消耗，根据结果，控制查询流的走向调度第一阶段：分发查询预测13谢谢您的观赏2019-6-30个人工作n预测：n实验发现MongoDB有哈希索引的时候，查询相同字段一条记录的时间是相差不多的，所以预测可以根据查询条件个数以及涉及的字段来进行（正在进行）14谢谢您的观赏2019-6-30个人工作n危机探测n原因：如果每个查询
6、任务都进行调度，会浪费时间，而且个人感觉为了减少时间消耗，应该本地的任务尽可能的放在本地执行，所以只有危机发生的时候才执行调度n将论文的思想简化，探测机器性能（CPU、Mem，I/O），某一个小于临界值，就说明有危机（或者可以使用机器学习的方法，但是感觉效果不大查询到达，归入相应租户预测）。n租户模型功能：租户任务到达，告知SLA效益模型，记录相关节点路径15谢谢您的观赏2019-6-30个人工作n两阶段调度n因为在P2P网络中，没有主控节点，想要一次性的完成调度，感觉准确性不高。第一阶段分发，目标是对于有危机的节点，将查询任务分发到资源充足的节点去解决。第二阶段：选取，在节点的队列里选择能使SLA利润最大的查询首先完成（第一阶段危机发生时使用，第二阶段每次执行任务都要进行选取）16谢谢您的观赏2019-6-30个人工作n17谢谢您的观赏2019-6-30个人工作n第二阶段：选取nSLA收益模型ttEEPP18谢谢您的观赏2019-6-3019谢谢您的观赏2019-6-30个人工作n20谢谢您的观赏2019-6-3021谢谢您的观赏2019-6-30
