Transcript 服务监测
PAAS平台相关技术 邵津 [email protected] 大纲 一 • PaaS平台发展现状 二 • PaaS平台的监测与调 整 三 • 我们的工作 一 • PaaS平台发展现状 一 • PaaS平台发展现状 1 • Google App Engine 2 • Windows Azure Platform 3 • AWS Elastic Beanstalk 4 • Cloud Foundry GAE简介 • Google App Engine 提供一整套开发组件来让 用户轻松地在本地构建和调试网络应用 • 用户可以通过GAE在Google强大的基础设施上 部署和运行网络应用程序，并自动根据应用 所承受的负载来对应用进行扩展，免去用户 对应用和服务器等的维护工作。 • 提供大量的免费额度和灵活的资费标准。 • 在开发语言方面，现支持Java和Python这两种 语言，并为这两种语言提供基本相同的功能 和API。 GAE的基础：Google的十个核心技 术（1） • 分布式基础设施 – GFS：分布式文件系统 – Chubby ：分布式锁服务 – Protocol Buffer：Google内部使用的一种语言中立、 平台中立、可扩展的序列化结构化数据的方式 • 分布式大规模数据处理 – MapReduce ：并行编程模型 – Sawzall：构建在MapReduce之上的采用类似Java语 法的DSL（Domain-Specific Language） GAE的基础：Google的十个核心技 术（2） • 分布式数据库技术 – BigTable ：非关系型数据库，多级映射的数据结构 – 数据库 Sharding：对MySQL的分片（Sharding）的 水平扩展（Scale Out）解决方案 • 数据中心优化技术 – 数据中心高温化：Power Usage Effectiveness=1.2 – 12V电池 – 服务器整合 GAE的设计特点 • 重用现有的Google技术 – Datastore是基于Google的bigtable技术，Images服务是 基于Picasa的，用户认证服务是利用Google Account 的，Email服务是基于Gmail的等 • 无状态 – 不在应用服务器层存储任何重要的状态，而主要在 datastore这层对数据进行持久化 • 硬限制 – 对代码有一些硬限制来保证安全 • 利用Protocol Buffers技术来解决服务方面的异构性 • 分布式数据库 GAE主要组成部分 • 应用服务器：主要是用于接收来自于外部的Web请求。 • Datastore：主要用于对信息进行持久化，并基于 Google著名的BigTable技术。 • 服务：除了必备的应用服务器和Datastore之外，GAE还 自带很多服务来帮助开发者，比如：Memcache，邮件， 网页抓取，任务队列，XMPP等。 • 管理界面：主要用于管理应用并监控应用的运行状态， 比如，消耗了多少资源，发送了多少邮件和应用运行 的日志等。 • 本地开发环境：主要是帮助用户在本地开发和调试基 于GAE的应用，包括用于安全调试的沙盒，SDK和IDE插 件等工具。 Java运行环境：概述 • 主要特点 – 选用了轻量级的Jetty技术，运行在Java 6上 – 支持大多数常用的Java API，但不支持一些比 较高阶的API和框架，包括JDBC，JSF，Struts 2， RMI，JAX-RPC和Hibernate等。 • JRE白名单：http://code.google.com/intl/zhCN/appengine/docs/java/jrewhitelist.html – 对应用的限制比较多 Java运行环境：安全保障机制 • 请求计时器 – 请求处理程序对请求生成和返回响应的时间是有限的， 通常约为 30 秒。 – 达到限制时间后，请求处理程序将中断。 • Java 运行时环境通过引 发 com.google.apphosting.api.DeadlineExceededException 中断 servlet。 • 如果请求处理程序不捕获此异常，那么和所有未捕获的异常 一样，运行时环境将向客户端返回 HTTP 500 服务器错误。 Java运行环境：安全保障机制 • 沙盒 – – – – – – 无法向文件系统写入 只允许读取与该应用程序一起上传的“资源”文件。 无法产生子进程或线程 无法打开套接字或直接访问另一主机 禁用不适用于 GAE的 java.lang.System 类的功能 允许应用程序对自己的类进行完全、无限制的反射访 问，无法对不属于自己的任何其他类进行反射，也无 法使用 setAccessible() 方法来避开这些限制 平台提供的基础服务 • Memcache • 定时任务 – App Engine Cron 服务允许在指定时间执行或按指定间隔 执行定期计划任务：cron job • 网址抓取 – 应用程序可使用 App Engine 网址抓取服务分别向端口 80 和 443 上的其他主机发出 HTTP 和 HTTPS 请求 • • • • Email 用户认证 图形 … 总结 • GAE适应的使用场景 – Web Hosting • Open For Questions • 日本大地震寻人 – REST服务 • BuddyPoke – 依赖Google服务的应用 • 比如应用能够通过App Engine的Email服务来发送大规模的 电子邮件。 一 • PaaS平台发展现状 1 • Google App Engine 2 • Windows Azure Platform 3 • AWS Elastic Beanstalk 4 • Cloud Foundry 组成 Windows Azure • 计算 – 作为一个部署服务的平台 • 用户可以在Windows Azure上部署自行开发的服务 – 作为一个软件分发平台 • 用户可以使用Windows Azure来分发自己的软件 – 作为一个一般的分布式计算平台 • Fabric提供了极其强大的负载平衡的支持，所以可 以很好的执行一些极为复杂的并行算法。Windows Azure支持多种开发技术，例如.NET，Win32，甚至 是Java，从而满足大多数客户对分布式计算的需求。 Windows Azure • 四种存储服务 – Blob • 类似文件系统的存储方式 – Table • 结构化的存储方式 – Queue • 先进先出的存储方式 – Drive • 使用标准的NTFS API读写文件 Windows Azure • 管理 – 管理员可以直接使用Windows Azure门户来管 理程序。 • 门户提供了创建，删除项目，创建，删除，更新部 署，等众多功能。 • 此外还提供了Management API，让开发人员自行开 发程序来管理他们的部署。 – 今后还会将System Center与Windows Azure集 成，从而可以使用同一套工具，同时管理企业 内部的服务器，以及云端的资产。 AppFabric • Service Bus – Service Bus可以被用于将本地的服务暴露给Internet • 解决：内网服务没有对外地址所以无法被直接访问 • AppFabric – 在云中，权限管理往往要比在企业内部来的困难。这 是因为你无法直接使用诸如活动目录之类的产品来统 一管理你的程序的访问控制。 • 其他 – 将现今Windows Server AppFabric中的功能移植到 Windows Azure platform AppFabric中来：分布式缓存， 以及WCF/WF管理的功能 SQL Azure • 部署在云端的关系型数据库引擎 • 绝大多数的管理工作都由微软为你完成， 因此你不用担心任何诸如备份，集群，等 管理方面的问题 • SQL Server 2008 Management Studio R2（目 前为CTP版本）针对SQL Azure也提供了很 强大的支持 一 • PaaS平台发展现状 1 • Google App Engine 2 • Windows Azure Platform 3 • AWS Elastic Beanstalk 4 • Cloud Foundry 对应用的要求 • 应用尽可能设计的无状态 – 使用松耦合、可容错的组件，以便能在需要的时候进 行伸缩 • 使用持久存储来存储数据 – AWS EB的应用是跑在EC2上的，而EC2的实例没有本地 的持久化存储。在关闭之后，上面的所有数据都会被 清除。 – 使用AWS提供的数据存储服务 • • • • Amazon Simple Storage Service (Amazon S3) Amazon Elastic Block Store (Amazon EBS) Amazon SimpleDB Amazon Relational Database Service (Amazon RDS). 搭建在EC2上 • 在EC2的instance上预装了一些运行环境 Auto-scaling 一 • PaaS平台发展现状 1 • Google App Engine 2 • Windows Azure Platform 3 • AWS Elastic Beanstalk 4 • Cloud Foundry Cloud Foundry • 2011年4月12日刚刚上线 • 由VMware的Spring建立的一个开源的PaaS 平台 • With Cloud Foundry, VMware is providing a convenient and compelling destination for Java applications in public and private cloud. Cloud Foundry Choice of Developer Framework Choice of Application Services Choice of Clouds Choice of Usage (It’s Open Source) 架构 DEA(Droplet Execution Agent) • 一个droplet就是应用的代码和它的依赖库所 打成的一个包，并且要添加一个start和stop命 令 • 系统会维护一个待命的DEA的池，也就是一个 虚拟机级别的应用容器 • DEA同时支持单租户和多租户的操作（即每个 应用一个DEA虚拟机，或是n个应用一个DEA虚 拟机） • DEA还提供了一个安全且受限的操作系统环境 来运行应用所在的应用服务器和应用的代码 路由（Router） • 路由负责接收外界的所有请求，并负责维 护外网URL到内部服务实例的映射 • 除了对应用的请求，对所有的Cloud Foundry的API的请求（一般是由vmc和STS 发出的）也会经过路由 • 路由同时也是一个负载均衡器，负责把请 求平均的分发给一个给定应用的所有实例 云控制器 • 负责系统中的所有状态改变 – 保证所有的依赖可用 – 将服务和应用绑定 • 所有影响用户、应用和服务的操作都由cloud controller来 进行 – 比如，通过vmc进行的push、instances、create-service都是由 cloud controller驱动的 • 当应用被组装好以后，cloud controller负责将应用和一个 DEA执行单元连接起来 健康管理器 • 健康管理器与云控制器和DEA紧密的配合， 来保证所有的应用都保持高的可用性 • 如果一个应用崩溃了，健康管理器会及时 的发现，并安排一个替代的实例 • 如果健康管理器发现快速、重复的应用崩 溃，它就会宣布应用进入“flapping”状态， 并且停止恢复这个应用 Services • 服务为cloud foundry提供了很多扩展性 • 目前提供了包括MySQL, Redis, MongoDB, RabbitMQ等服务 • 应用之间可能会共享服务 • Cloud foundry把服务的供给抽象成一个统 一的API，并将其托管于cloud controller之 中 – 这样的好处就是可以通过一种统一的方式将服 务添加到应用之中 Cloud Foundry组件间的交互 Sends droplet heart beats and exit messages Router Router Registers and unregisters Registers and unregisters Routes droplet requests Routes REST API requests Droplet change notifications Health Manager Droplet start/stop requests Periodically scans for consistency Cloud Controller Database Orchestrates (Start, Stop, Find) Cloud Controller Cloud Controller Persists droplets and provisioned services Droplet Execution Agent (DEA) Guest applications consume Advertise Service Provision and unprovision Service "A" Provisioning Agent Provision and unprovision Service "A" 二 PaaS平台的监测与调整 1 • 服务的监测 2 • 分析与决策 3 • 运行时调整 不同角色的监测视图 • 云平台运营者 – 平台各个层次的运行状况 • 云平台开发者（部署者） – 所部署应用的运行状况 – 应用的用户访问情况 • 最终用户 – 对比服务之间的运行状况 云的层次结构 虚拟机层监测 • VMware vSphere Management APIs – Web-services based API for managing, monitoring, and controlling the life-cycle of all VMware vSphere components vSphere Client-Server Architecture • Managed objects – 存在于vShpere服务器上 (ESX/ESXi or vCenter Server system) – 代表vSphere的服务或者组件 • Managed object references – 客户端应用对服务器端的managed objects的引 用 • Data objects – 包含managed objects的相关信息 操作系统层监测 • 通过操作系统提供的接口来获得系统的相 关信息 – Windows资源管理器 • 不同的操作系统需要不同的实现 – 本地代码 Hyperic Sigar • http://www.hyperic.com/products/sigar • Sigar为开发者提供了一个跨越平台的统一API来获 得操作系统的相关信息 – System memory, swap, cpu, load average, uptime, logins – Per-process memory, cpu, credential info, state, arguments, environment, open files – File system detection and metrics – Network interface detection, configuration info and metrics – TCP and UDP connection tables – Network route table 中间件层监测 • J2EE中间件的管理：JMX • JMX（Java Management Extensions，即Java 管理扩展）是一个为应用程序、设备、系 统等植入管理功能的框架。 • JMX可以跨越一系列异构操作系统平台、 系统体系结构和网络传输协议，灵活的开 发无缝集成的系统、网络和服务管理应用。 • 大多数中间件都实现了JMX接口 以Tomcat为例 应用层监测 • 请求 – 参数值、请求的顺序、请求的频度 • 响应 – 响应时间、响应的正确性 • 资源 • 管理操作 • 应用内部 – 运行时验证技术 – 实现技术 • 截取器、过滤器、监听器 • 代码插装技术：ASM、Javassist、Aspectj 应用层监测 • 软件运行时验证技术 – 将需求（对软件的约束）定义为对应的 specification – 由specification自动或半自动的生成监测及验证 代码 – 将监测代码插装到原程序中 – 在程序运行的过程中，获得相应的trace信息， 并由验证代码进行验证 – 返回验证结果 应用层监测 • 约束的定义 应用层监测 监测用户的使用行为 • 用户感受到的QoS • 用户的使用行为模式 – 地域性 – 使用习惯 – 负载模式 二 PaaS平台的监测与调整 1 • 服务的监测 2 • 分析与决策 3 • 运行时调整 分析 • 对应用本身的分析 – 对哪种计算资源的需求更大？ – 性能瓶颈在哪里？ • 对环境因素的分析 – 基于历史负载的预测 – 对用户使用行为的分析 • 对应用之间关系的分析 – 负载的互补性 – 资源使用的互补性 决策 • 基于policy的决策方式 – Policy specification • 基于阈值的决策方式 – 如何制定合理的阈值？ 二 PaaS平台的监测与调整 1 • 服务的监测 2 • 分析与决策 3 • 运行时调整 虚拟机层次 • 虚拟机开启、关闭、休眠 • 虚拟机迁移 – VMware Vmotion：将正在运行的虚拟机从一台物 理服务器移动至另一台物理服务器，而不影响最 终用户 – 虚拟机的活动内存和准确的执行状态通过高速网 络快速从一台服务器传输到另一台服务器，对虚 拟机磁盘存储器的访问被即刻切换到新的物理主 机 – 由于网络也进行了虚拟化，因此虚拟机会保留其 网络标识和连接，从而确保实现无缝的迁移过程 虚拟化技术：资源分配的动态调整 • 资源池技术 CPU的池化 • 份额（Shares） – 虚拟机对资源使用的相对优先级 – 默认分为：高/正常/低，比例关系为4：2：1 – 份额为[高]的虚拟机和为[正常]的虚拟机在未使用 的主机资源中会以2：1的比例占用资源。 • 预留（Reservation） – 主机保留给虚拟机的最低资源量 • 限制（Limit） – 虚拟机可使用的最大的资源量。 资源分配策略 • 在没有发生竞争的情况下, VM需要多少CPU, ESX就给多少, 但不超过LIMIT值. • 在发生竞争的情况下, ESX保证每个VM都得 到其保留值所定义的CPU.不设保留值的等 同与保留值=0 • ESX做完(2)之后剩下的CPU资源, 则按照个 VM所设定的SHARE值按比例来分配: (VM SHARE)/(SHARE 总值) 中间件层次 • 外部环境调优 – 调整Tomcat运行环境的操作系统参数和运行 Tomcat的java虚拟机参数 • JAVA虚拟机性能优化 – 虚拟机可通过命令行的方式改变虚拟机使用内存的 大小 – 调整堆大小的的目的是最小化垃圾收集的时间，以 在特定的时间内最大化处理客户的请求 • 操作系统性能优化 – 一个进程所能创建的线程的最大数 – 用户的进程能同时打开的最大文件句柄数 – 可用的网络连接数 中间件层次 • 自身调优 – 禁用DNS查询 • 当web应用程序要记录客户端的信息时，它也会记录客户端 的IP地址或者通过域名服务器查找机器名转换为IP地址。 • DNS查询需要占用网络，并且包括可能从很多很远的服务器 或者不起作用的服务器上去获取对应的IP的过程，这样会消 耗一定的时间。 – 调整线程数 • 使用线程池加速响应速度来处理请求 • 通过修改minProcessors和maxProcessors的值来控制线程数 • 最大连接数还受制于操作系统的内核参数设置，通常 Windows是2000个左右，Linux是1000个左右 – 加速JSP编译速度 • 使用特制的编译器来编译JSP 应用层次 • 调整应用实例的数目 • 将应用的异常信息反馈给开发者，以便升 级等操作 • 应用的活迁移 三 • 我们的工作 SASEP的总体架构 SASEP上的监测框架 Legend Service Probe Http detector at cloud side Filter Http detector at GAE Application JMX, JVM Agent Native Library Monitoring Center Application JVM Windows Application Application Tomcat VMware ESX Physical Machine Application Apache Linux Historic Monitoring Data 有关作业提交 • 作业提交Deadline： – 6月22日之间提交到指定的平台上 – 6月22日最后一次课，在课堂上互相演示作业 THANK YOU! Q&A