Chef在大数据集群部署中的应用 Chef的基本架构
Chef是一个C/S架构的分布式软件配置管理工具。
Chef架构（源自https://wiki.opscode.com/display/chef10/Architecture+Introduction）
Chef Server存储配置各个节点所需的所有信息，以REST API接口提供服务，Chef Nodes是指那些安装了chef-client的节点，chef-client主要用于与Chef Server通信，获取各自的runlist和recipes，进行相应的软件安装、配置和启动工作。
Chef通过Cookbook的方式进行软件配置，每一个Chef Cookbook定义了如何去配置某一个特定service或app，整个配置过程可能被定义为多个step，每一个step称为一个recipe，Cookbook需要上传到Chef Server由其进行统一管理。
Chef还需要为Cookbook定义相应的role，一个role有一个定义recipe执行顺序的runlist。每一个Chef Client可能需要安装若干个role，运行时由chef-client进程与ChefServer通信，获得每一个role对应的runlist，并根据runlist下载相应的Cookbooks，依次执行各个recipe以实现某个service/app的安装配置。
在recipe中有一个关键部分叫做resource，每一种resource定义一种特定的软件配置，譬如rpm的安装，用户/组的创建管理，目录的创建管理，service的启动/停止等等，每一个resource对应一个provider。开发recipe时可以按需求使用相应的resource，chef-client会由相应的provider来完成每一个resource的工作。关于Chef的resource可进一步参考https://docs.opscode.com/resource.html。
关于Chef的基本概念和教程可进一步参考https://learnchef.opscode.com。
Chef的各个组件及其工作机制
Chef的架构中主要包括Chef Server, CouchDB, RabbitMQ, ChefExpander/Indexer, Solr, Chef Client, Knife等。
Chef组件（源自https://wiki.opscode.com/display/chef10/Architecture）
Chef Server使用CouchDB存储其所有信息，使用Solr提供Search功能，当有数据更新时，Chef Server会更新CouchDB中对应的document，并将数据通过RabbitMQ传递给chef-expander，由其调度更新到Solr中。
当Chef Server接收到一个搜索请求时，Chef Server先调用Solr的Rest API得到搜索结果，即所有符合请求条件的document的ID，在根据该ID到CouchDB中获取每一个document全文返回给客户端。
Knife是Chef提供的一个命令行工具，用于与Chef Server进行通信，Chef的所有功能都可以通过knife来操作。
vSphere Big Data Extensions是如何使用Chef的
在vSphere Big Data Extensions（BDE）或Serengeti中，Chef Server和WorkStation被安装在Management Server中，chef-client被预装在Serengeti部署出的虚拟机中。
Serengeti安装好以后，在Management Server中已经配置好了Chef Server，并为其配置好了Serengeti所开发的各种roles和相应的cookbook，用户在创建cluster的时候需要为每个nodegroup指定相应的roles，当虚拟机创建完成以后，Serengeti Web Service收集虚拟机的硬件信息和用户定义好的cluster配置，通过thriftservice发送给Ironfan，Ironfan负责与Chef Server交互，在ChefServer上创建各个Node和Role信息，最后启动每个node上的chef-client，通过ChefServer获取各自的roles和runlist，并下载相应的Cookbook进行软件的安装配置。
关于Serengeti，ChefServer，以及各个Node之间的拓扑关系，可以参考我们的另外一篇博客《深入解析大数据虚拟化的架构（下）- 系统架构》
实例讲解Chef和Serengeti的工作机制
在本部分中我们通过实例讲解BDE/Serengeti是如何通过Chef来安装软件的，为 阅读目录： 1.开篇介绍 2.ASP.NETMVC IControllerFactory 控制器工厂接口 3.ASP.NETMVC DefaultControllerFactory 默认控制器工厂 4.ASP.NETMVC ControllerBuilder 控制器创建入口设置 5.ASP.NETMVC 自定义IControllerFactory 上一篇文章".NET/ASP.NET MVC Controller 控制器（一：深入解析控制器运行原理）"详细的讲解了MvcHandler对象内部的基本流程逻辑，这基本的流程逻辑为我们后面的学习起到铺垫作用，当我们能正确的搞懂它的内部执行流程后，我们就可以顺藤摸瓜的去挖掘每个逻辑环节中的详细逻辑； 通过前面两篇文章的介绍，我们基本上能搞清楚一个Url请求是如何借助于UrlRoutingModule模块顺利穿过ASP.NET基础框架到达应用框架的过程，当UrlRoutingModule处理过后将RouteData对象封装在RequestContext请求上下文中传入到MvcHandler对象，然后MvcHandler对象通过IControllerFactory接口根据从RouteData中获取到controllername控制器名称字符串创建具体的IController对象实例； 这基本的流程我们是清晰了，但是我们并不太清楚IControllerFactory背后所发生的一切，到底谁作为IControllerFactory默认实现的，它又有着怎样的扩展入口让我们来扩展创建过程，这值得一探究竟； 那么这篇文章让我们来分析一下IControllerFactory的背后所发生的事情，我们是否能从中学到什么设计思想； 既然能将ControllerFactory提取出接口来，那么对于IController的创建将是一个非常宽松的过程；简单的设想一下，如果不将Factory提出接口来，那么对于IController的创建将是一个很直观的过程，但是ASP.NETMVC将IController创建不是简单的使用一个ControllerFactory来解决，而是将这个创建过程设计的很松散，目的是为了扩展性方便，换句话说我们完全可以自定义一个Factroy来替代这个创建过程，也可以基于系统内部的Factroy来扩展一下； MvcHandler使用IControllerFactroy创建出相应IController对象，那么首先我们需要搞清楚MvcHandler通过什么方式获取到实现IControllerFactory接口的； 其实在MvcHandler中并不是直接使用IControllerFactroy的相关实现，而是使用了ControllerBuilder对象，这个对象是一个单例模式的实现；MvcHanlder通过ControllerBuilder对象获取到一个实例，然后通过ControllerBuilder创建出IControllerFactory实现； 可以简单的理解为，ControllerBuilder管理着IControllerFactory的创建过程，MvcHanlder通过获取ControllerBuilder的全局实例，然后调用其方法GetControllerFactory，得到可以使用的IControllerFactory实现； 图1: ControllerBuilder的设计很巧妙，它将IControllerFactory的实现为我们敞开了大门，我们可以通过这个入口做很多事情； 我们看一下IControllerFactroy接口的定义： 2】ASP.NETMVC IControllerFactory 控制器工厂接口
internal ControllerBuilder ControllerBuilder { if (_controllerBuilder == null) { _controllerBuilder = ControllerBuilder.Current; return _controllerBuilder; _controllerBuilder = value; factory = ControllerBuilder.GetControllerFactory(); 
没有评论:
发表评论