硕士毕设思路

硕士毕设

参考:

• Docker与OpenStack集成
• OpenStack Heat如何来实现和支持编排
• Magnum-wiki
• 谈谈 OpenStack 与 Docker 的落地方案选择
• Kubernetes Scheduler原理解析

解决问题

架构现状：

docker天生不安全性可能会因root权限窃取出现整台服务器上所有运行容器down掉；公有云、混合云、容器云中为了保证不同租户服务的完全隔离必须借助vm技术的完全隔离性；而docker-vm-hm部署架构能够有效解决这些问题（问过很多搞容器，都说自己公司就是这么部署的）

算法现状：

目前流行的docker编排工具（swarm/k8s/Mesos/Openstack）采用的调度策略（算法）简单易用（spread/binPack/random），透明的看待下层实际运行容器的平台硬件（忽略是vm or hm）；若直接将此类调度器直接运行于docker-vm-hm部署架构上与直接运行于docker-hm架构几乎没有区别（除了前者提供可靠的安全性）。但是这些调度策略本身具有如下问题：
(调度策略面向服务、容错、高可用；面向需求新增阶段，不提供长时间运行后的资源聚合策略。)

• Swarm Binpack算法按照资源占用最高且能够容下新容器的思想调度，但是其资源占用情况不是以物理的cpu/mem作为依据，而是以各节点上运行的容器数量作为依据，这会使过多容器相互“挤占”同一个节点的系统资源导致运行的不可靠性;
• Apache mesos采用两层式资源调度器（由各个节点报告自己的物理cpu/mem剩余情况反馈给framework由其裁决新增容器服务的放置节点传给docker scheduler由其部署完成）反馈给独立的调度框架只能感知集群部分的状态信息，无法满足需要集群状态信息才能运行的聚合算法;
• Kubernetes scheduler 采用预选（Predicates Policies）和优选（Priorities Policies）为新增pod选择合适node，预选合格（）的nodes作为优选输入由优选策略加权求和打分，以最高或并列最高随机一个为最终node。算法与调度均面向服务，以服务容错、高可用目标，但在以物理资源为考虑依据的能耗、负载均衡目标上，几乎没有考虑。

"predicates" : [
       {"name" : "PodFitsPorts"},
       {"name" : "PodFitsResources"},
       {"name" : "NoDiskConflict"},
       {"name" : "NoVolumeZoneConflict"},
       {"name" : "MatchNodeSelector"},
       {"name" : "HostName"}
  ],
"priorities" : [
       {"name" : "LeastRequestedPriority", "weight" : 1},
       {"name" : "BalancedResourceAllocation", "weight" : 1},
       {"name" : "ServiceSpreadingPriority", "weight" : 1},
       {"name" : "EqualPriority", "weight" : 1}
  ]

• 虽采用docker-vm-hm部署架构，但调度策略仍存在上述问题：

  • Openstack Nova将Docker当作轻量级vm调度使用，不支持Docker高级特性（关联属性，服务发现，端口映射等）因此不实用；
  • Heat在创建的 VM 上使用 Heat Templates 设定 Docker 的参数，可以使用 Docker API 提供的所有功能，缺点在于无法实现调度机制，并且Glance管理镜像不支持Docker镜像的layered images features（启动某些依赖于某locally cached base的镜像会非常缓慢）;
  • Magnum如今与swarm、k8s 、Apache mesos 集成可以创建相应的container cluster —— Bay，Magnum现在只能管理单个的Docker的服务器，因为还没有一个原生的调度器能够让Magnum管理一个Docker集群，目前通过定义Bay、Node、Pod等概念映射为COEs（Container Orchestration Engines）集群并实现COEs（k8s、swarm、mesos）的部署调度；magnum通过将不同租户的Bay运行在不同的kernels上实现租户安全隔离（换言之使用vm技术进行完全隔离）。

  研究方案

  综合上述原因，需要解决：

• 生产上线时，尤其多租户情况下，云中心应该以docker-vm-hm部署架构提供容器服务；

• 面向云中心，研究以降低能耗、负载均衡情况为目标的容器新增、聚合调度算法，且充分挖掘docker-vm-hm架构的可能性。

实验设计

新增阶段

• 采用变形FFD算法——Dot-Product FFD算法；实现以physical server占用最少（即满足约束下的physical resource最大化）为目标的调度算法。

• 算法思想：

将新增的容器request resources、hm residual resources（host machine）矢量化， 计算容器资源向量与其余各servering hm剩余资源向量夹角的余弦值，取最大值作为first hm，接着在该hm选择满足约束vm放入。

• 模拟数据集

  • hm、vm、docker尺寸归一化（0～1），采用Gao Y于2013年提出的方法模拟生成docker尺寸，vm规格参照 Amazon EC2；

  • 采集真实云中心hm、vm、docker（参照精灵云、灵雀云）规格，进行归一化。

• 目前进展

  代码已完成，初步结果显示启发式算法能够解决新增问题，且Dot-Product FFD，优于FFD和BFD。

聚合阶段

• 考虑docker-vm-hm结构中，得兼顾多个约束，采用传统启发式容易陷入局部解，且不适合多目标求解，效果忧心。

• 考虑选用多目标优化模型，同时比较GA、粒子群（多目标化为递增单目标函数 ）、生物地理学算法（多种群的GA算法）。

• mbbo算法——考虑算法到具体问题的映射：

  • SIV 适宜性指数变量，即解中任意一个容器对应的vm，hm
  • HSI 栖息岛适宜性指数，通过目标函数反映每个候选解的适宜度（对该问题的契合度）
  • chrom 栖息岛，即满足该模型约束的候选解（各容器对应的vm，hm编号）
  • archipelago 群岛，包含size个栖息地（候选解），每一个群岛对应一个优化目标
  • 通过群岛内栖息地的SIV迁移，突变，目标cost，rank排序，精英解替换， 迭代进化给出每一代的群岛内最优解；通过各个群岛间的全局精英解替换，重新覆盖各群岛精英解，实现在多个优化目标上的近似最优解。

• 模拟数据集

  • 与新增算法采用一样数据集

• 实验设计 （蓝色和红色是还在考虑的点）

  • docker-vm-hm VS docker-hm
    为了体现docker-vm-hm部署架构优于docker-hm，除了mbbo优化目标power、v_balance、migration_time之外，新增一个安全性预测函数（！！！）

    • 安全性预测函数原则：
    • vm宕机引起hm宕机的概率a1（d-v-h）
    • 容器宕机引起hm宕机的概率a2（d-h）
    • 出现意外性宕机的概率p
    • 再引入一个宕机对所在hm造成损失的指数index
    • a1<
    • 需要设计一个有说服性的函数（还没有解决！！！）

  注意： 师兄认为找不到官方的数据（比如某个数据中心中招的概率），直接提出安全衡量函数，会遭到质疑，应该在d-v-h与d-h相同优化场景下，优化目效果相当时，再补充说明2种方法遭遇入侵的概率，比较有说服性。

  • docker-vm-hm
    
    • 为了体现对d-v-h部署架构的量身定制，需要对mbbo做一定程度的创新，可选的如下：
    • 修改对migration_time的衡量代价函数（即迁移策略，容器无状态，不需要迁移时间）
    • 提出一些修改，改进mbbo超近似最优解迭代前进的速度和方向

初步结果

• 在power目标上，mbbo在d-v-h（尺寸上vm:hm=1:1）和d-h场景下表现出几乎相当，但d-h场景能耗稍低点，占用pms稍少点；

• 在power，v_balance两个目标上，mbbo在d-v-h下的表现非常不好，还在考虑修改方向！！！

  算法修改

• （待完善）

参考文献：

• Bui T. Analysis of docker security[J]. arXiv preprint arXiv:1501.02967, 2015.
• Gupta U. Comparison between security majors in virtual machine and linux containers[J]. arXiv preprint arXiv:1507.07816, 2015.
• Manu A R, Patel J K, Akhtar S, et al. Docker container security via heuristics-based multilateral security-conceptual and pragmatic study[C]//Circuit, Power and Computing Technologies (ICCPCT), 2016 International Conference on. IEEE, 2016: 1-14.
• Dua R, Raja A R, Kakadia D. Virtualization vs containerization to support paas[C]//Cloud Engineering (IC2E), 2014 IEEE International Conference on. IEEE, 2014: 610-614.
• Mattetti M, Shulman-Peleg A, Allouche Y, et al. Securing the infrastructure and the workloads of linux containers[C]//Communications and Network Security (CNS), 2015 IEEE Conference on. IEEE, 2015: 559-567.
• https://s3hh.wordpress.com/2013/07/19/creating-and-using-containers-without-privilege/
• Hayden M, Carbone R. Securing Linux Containers[J]. GIAC (GCUX) Gold Certification, Creative Commons Attribution-ShareAlike 4.0 International License, 2015.
• WHITE PAPER INTRODUCTION TO CONTAINER SECURITY. Introduction to Container Security http://docplayer.net/8751370-Whitepaper-introduction-to-container-security-introduction-to-container-sercurity.html

附件

-  Magnum 架构图


- Magnum FAQ