由于自己的简历上写了“类似与EC2的弹性云平台”项目，所以每次面试的时候，这个项目一般是必问的。经过这么多次的面试，有些面试官问的问题和前面问的是重复的，不过总体来说，他们的问题都主要集中在下面我所总结的9个问题当中。把这个项目的问题小结一下，一是很大家一起分享，二是防止下次面试的时候，相同问题又出来。1.简单说一下你所做的这个项目，以及你在这个项目当中担任的角色和主要任务。
解：对于这个问题一般是必问的，但我之前的面试就是答不好。
弹性云平台主要借助虚拟机技术实现物理计算机资源（计算资源、存储资源、网络资源等）的再划分、隔离、以及现场分配和回收。最终用户以完全独占方式获得虚拟机实例（其上已运行标准操作系统），具体使用方式也由用户自己决定。
简单地说，目前做的就是一个可架设在廉价pc上，具备分布存储能力的高可用性的虚拟机管理系统，实现资源的整合。
我负责虚拟机调度，我们的目标是就是实现一个弹性云计算平台调度管理系统。
主要负责：
(1)系统原数据管理 ——维护系统各种资源数据，以及控制和状态数据。
(2)系统命令处理 ——虚拟机控制（创建、启动、关闭、销毁）、监控等各种命令处理。
(3)系统负载监控。
(4)管理虚拟机生命周期
另外，我们还有一个任务就是学习erlang，用这个语言进行相应的开发。
详细
(1)主服务（master service） 负责原数据管理、系统负载监控、系统命令。
(2)从服务（node controller） 负责按照主服务要求管理本地虚拟机。
master service 接收的消息处理过程（如虚拟机启动等动作都在分钟级别）往往耗时，因此需要将这种耗时消息处理放在专门的进程中执行；而异步进程只用于接收消息，处理则转交给后面新启动的消息处理进程完成﹣这样才不会堵塞后续消息（要知道我们master service 可由多用户同时下发请求）。
消息处理进程负责解析命令参数、访问数据库、下发命令给Node Controller，等待Node Controller回应，如果超时未回应或者Node Controller返回错误，则认为访问失败，修改数据库、向访问者报错。如果访问成功则，修改数据库、向访问者报错。
2.为什么要做这个项目，做这个项目的目的。
解：这个问题可以把第1个问题的回答扯进来。
一是，按照用户需求，自动分配、管理、监控虚拟机；
二是，支持网络虚拟化；
三是，支持镜像存储集中化（在hadoop上事项log structure filesystem作为虚拟镜像存储后台）；
四是，实现虚拟机调度；
五是，实现虚拟机服务和数据分析等离线服务混合部署
3.把你理解的分布式系统讲解一下。
解：说实话，我所理解的分布式系统就是许多台电脑的集合，不过对面试官不要这么回答，下面是我百度出来的一些答案，仅供参考。
在一个分布式系统中，一组独立的计算机展现给用户的是一个统一的整体，就好像是一个系统似的。系统拥有多种通用的物理和逻辑资源，可以动态的分配任务，分散的物理和逻辑资源通过计算机网络实现信息交换。系统中存在一个以全局的方式管理计算机资源的分布式操作系统。通常，对用户来说，分布式系统只有一个模型或范型。在操作系统之上有一层软件中间件（middleware）负责实现这个模型。一个著名的分布式系统的例子是万维网（World Wide Web），在万维网中，所有的一切看起来就好像是一个文档（Web 页面）一样。
在计算机网络中，这种统一性、模型以及其中的软件都不存在。用户看到的是实际的机器，计算机网络并没有使这些机器看起来是统一的。如果这些机器有不同的硬件或者不同的操作系统，那么，这些差异对于用户来说都是完全可见的。如果一个用户希望在一台远程机器上运行一个程序，那么，他必须登陆到远程机器上，然后在那台机器上运行该程序。
分布式系统和计算机网络系统的共同点是：多数分布式系统是建立在计算机网络之上的，所以分布式系统与计算机网络在物理结构上是基本相同的。
他们的区别在于：分布式操作系统的设计思想和网络操作系统是不同的，这决定了他们在结构、工作方式和功能上也不同。网络操作系统要求网络用户在使用网络资源时首先必须了解网络资源，网络用户必须知道网络中各个计算机的功能与配置、软件资源、网络文件结构等情况，在网络中如果用户要读一个共享文件时，用户必须知道这个文件放在哪一台计算机的哪一个目录下；分布式操作系统是以全局方式管理系统资源的，它可以为用户任意调度网络资源，并且调度过程是“透明”的。当用户提交一个作业时，分布式操作系统能够根据需要在系统中选择最合适的处理器，将用户的作业提交到该处理程序，在处理器完成作业后，将结果传给用户。在这个过程中，用户并不会意识到有多个处理器的存在，这个系统就像是一个处理器一样。
4.介绍一下虚拟机的有关情况。
解： 我对虚拟机也没有仔细的研究过，不过做这个项目的时候，多次听过虚拟机组同学的讲座，对虚拟机只有部分了解。具体的有关虚拟机的情况，可以参见我的文章：初探虚拟机
虚拟化技术主要分为两种：半虚拟化和全虚拟化。
1.PV（paravirtualization泛（准/超）虚拟化：这种技术中，操作系统是经过修改的，性能比较高，首先是由Xen提出。
2.HVM（hardware virtualization machine）全虚拟化：这种技术需要硬件厂商支持，目前仅支持INTEL和AMD的虚拟化扩展技术。
位于最底层就是硬件，也就是我们所说的宿主机或者裸机。在裸机上面其实装的是Xen Hypervisor，Hypervisor是一个介于硬件和操作系统之间的软件层，它负责在各虚拟机之间进行CPU调度和内存分配（partitioning）。Xen Hypervisor不仅抽象出硬件层，同时控制虚拟机的执行，因为这些虚拟机共享同一个处理环境。但是，Xen Hypervisor不会处理网络、存储设备、视频以及其他I/O（对于其他I/O我理解还不是很清楚）。
5.有关虚拟机的迁移。
解：虚拟机迁移的性能指标包括以下三个方面：
1.整体迁移时间：从源主机开始迁移到迁移结束的时间
2.停机时间：迁移过程中，源主机、目的主机同时不可用的时间
3.对应用程序的性能影响：迁移对于被迁移主机上运行服务性能的的影响程度。
云计算就是以服务的形式提供计算资源。云计算背后最重要的概念之一就是可伸缩性，而实现它的关键则是虚拟化。虚拟化在一台共享计算机上聚集多 、个操作系统和应用程序，以便更好地利用服务器。虚拟化还允许在线迁移，因此，当一个服务器超载时，可以将其中一个操作系统以及它的应用程序迁移到一个新 的、不繁忙的服务器上。在云中，可以在多个操作系统和应用程序之间共享虚拟化服务器，从而减少服务器的数量。更少的服务器意味着需要更少的空间（减少数据 中心占用的空间）和更少用于制冷的电力（减少碳污染）。
这里有一个问题：在虚拟机迁移过程当中，是有停机时间的，这个停机时间是让用户不能感受得到的，如何做到这一点呢？（我没有接触过，但是那些面试官对于这个问题好像都很感兴趣）
6.如何进行调度（保证负载均衡）？
解：负载均衡有两方面的含义：
首先，大量的并发访问或数据流量分担到多台节点设备上分别处理，减少用户等待响应的时间；
其次，单个重负载的运算分担到多台节点设备上做并行处理，每个节点设备处理结束后，将结果汇总，返回给用户，系统处理能力得到大幅度提高。
7.影响虚拟机迁移的因素以及相应的算法如何实现。
解：对于这个问题，我自己也不是很清楚，不知道应该考虑什么东西，对于这个问题的回答仅供参考。
考虑因素，我觉得有这么多：
1）当前虚拟机所占用的资源，以及虚拟机的状态。
2）每台宿主机的运行情况
3）宿主机资源
4）网络资源
至于算法，我觉得要把所有的影响因素都写出来，然后进行相应的设计。
8.对于故障是如何处理的。
解：对于故障处理，分为master端和nc端。这一点也是分布式系统开发的核心内容。
nc节点的故障发现：
管理方是我们所谓的master。如果nc发生故障后，在master给它发送消息时，自然可以获知nc故障（因为消息失败），从而更新资源表（要将该机资源从中减去，但其上运行的虚拟机状态应标记为unknow——nc进程故障，不代表上面运行的vm也死掉了，但至少此刻我们不经过其他方式探测的话，vm状态时不明的）。
那么当NC机器恢复后，它需要重新向master注册,再次上报自己的资源情况。master再更新资源表等。这里有一个问题，如果master没有向nc发送消息,我们不大能知道nc发生故障。那么一般分布系统为了处理这种情况，往往采用心跳方式作为跨机器判断对方是否可用—心跳一般每几秒或者几百毫秒发送一次单向或者双向的消息，如果接到则说明对方活着）。
erlang系统中使用进程间link方式一般可以认为是一种心跳的替代品。当被link的一方发生故障，则另一方可获知消息。在我们系统设计中可采用master和nc进行link的方式实现类似心跳机制。
nc节点的故障处理：
master和nc建立link(link是双向的）是前提。
master发现nc故障后，就会自动进行类似的unregiser操作，更新资源表和vm状态表——这里有一个小问题，因为我们nc采用监督模式后，会重新被启动，如果很快被正常启动了（又发送regiseter消息了，则master其实不需要进行unregister。但如果等了一会还没有发现再连上来，则说明确实出现了物理故障，这是就要进行真正的unregiset操作了。这个细节你们可以先不去考虑，直接按照最简单逻辑实验。就是发现nc点股占，则master进行unregiser操作)
NC 发现master故障后，则开始尝试再向master发送register消息，由于master可能恢复需要时间,所以nc周期性向master发送register消息，直到成功为止。
master故障发现&处理：
对于master节点，我们有两个机器，master A和master B机器，master B上会有一个监控进程来监控master A，当然，master上的数据都保存在后端的数据库里，当master A发生故障时，master B上的监控进程就会获知A发生了故障，然后B自己获取后端数据库里的数据重新启动自己，从而代替A。
master B重新启动之后，nc节点会重新在master B上进行注册的。另外，对于用户发给master A的一些请求参数，当master A还没有来得及处理时，master A就崩溃了，那么master B又是如何获取这些参数的呢？如果这样，master A请求处理超时，客户端获得返回错误。master客户端会再次重新发起请求，这时如果master B准备好了，则进行处理，如果不行，那么客户端又要再次发送请求，直至master B接受。至于这里客户端重复发送请求，应该由客户端的逻辑层负责的。
对于上述过程的恢复描述，主要也就是三点。一是nc节点在内存里的数据恢复，二是本地数据的恢复，三是用户请求的恢复。对于内存里nc节点数据恢复，是通过nc重新注册的方法实现的；对于本地数据的恢复，是通过“本地无状态”方式（数据存储在后端数据库里）来实现的；至于用户请求的恢复，是通过重新发送的方式来实现的。
9.以虚拟机的启动为例，叙述一下它的启动过程。
解：在这个启动之前，会在master这块有一些资源表存放在数据库中的：宿主机资源表，集群网络地址资源表，虚拟机资源配置表，磁盘信息表，虚拟机运行信息表等。
启动的过程当中会用到上面的部分表，另外，在启动之前，应该把虚拟机创建过了。
用户请求启动的虚拟机（参数传递虚拟机的id）创建命令 -> master采用同步消息处理模式，异步消息处理模式，创建一个新的进程进行相应的处理 -> 消息参数的合法性检查 -> 查询数据库，判断用户请求是否合理 -> 按照负载均衡的要求寻找相应的宿主机并且master给nc节点发送命令 -> node conteoller每收到一个命令请求都会启动一个新进程，将命令交给新进程(消息异步处理服务+多线程同步消息处理) -> 检查参数的合法性 -> 调用相应的start vm（启动虚拟机）的shell脚本 -> 将执行结果逐层返回 -> master修改相应的资源表
阅读(2288) | 评论(0) | 转发(1) |
