Paas 比较

image001
image001

在2015的微软//Build大会中,Mark介绍了当前微软的公有云服务栈,提出Open Choice at Every Layer。 The Next Generation of Azure Compute Platform with Mark Russinovich Open意味着更有活力,更多选择。这诚然是个好事,不过也意味着要学习更多知识。我对Azure Cloud Service 有4年的使用经验,ServiceFabric则是刚刚入门。在学习SF的过程中发觉,文档组织的有些混乱,脑子里的知识很零散,很容易遗忘。在看CloudFoundry时,发觉更加困难,不知如何开始。 为了把知识连接和巩固起来,我从Azure Cloud Service和中提炼出一些关键概念,然后在SF中寻找相关文档,学习它的运行方式。同时,发掘两个PaaS明显区别,进行详细比较并理解其缘由。在学习CloudFoundry时,用了同样的办法。作为学习的一个产出,有了如下这篇文章。文章中的误差和错误在所难免,随着进一步学习,会继续更新。 Candidate Azure Cloud Service(或者叫Azure PaaS v1), Service Fabric, Cloud Foundry   Factor Architecture:从架构入手观察全局,避免迷失在细节中。 Dependency:依赖性决定了PaaS能在哪里运行,移植性。 Application running environment:应用程序的运行环境决定了应用程序能够控制的环境,从而影响应用程序的功能(Dev Functionality)。 Dev Functionality:如用那种开发语言,什么操作系统,存储访问方式等等。 Deploy:部署,包含PaaS环境的搭建以及应用程序的部署/更新。 Telemetry:Logging & Metrics & Analytics。 Auto-recovering:PaaS如何检测和自动恢复故障中的服务,需要多少人为干预。 Availability:PaaS基础服务以及应用程序的可用性分析。 Scalability:PaaS基础服务以及应用程序的规模伸缩性。 Performance:性能的比较太复杂,所以目前把它排除在外。   Comparison Architecture…

0

Windows Azure Storage性能调优(二)

上一篇我们提出的方法都是通过减少网络传输时间来提升性能。接下来,我会简介一下WAS的系统结构,然后解释如何设计程序来减少WAS端执行时间。  WAS架构 WAS性能目标 分散工作负载 避免Table热区 优化Table查询   WAS架构 Windows Azure Storage是一个三层架构,分为前端(FE)、分区层(Partition)、分布式存储层(DFS)。 前端负责接受客户端HTTP(S)连接,验证身份,计费以及写日志。 分布式存储层为实际的物理存储。无论Blob,File,Queue还是Table,其最终都已Binary形式存放在此层。此层确保数据在三个独立的物理节点上保存备份,避免数据丢失。 分区层提供了逻辑数据结构的访问能力。它理解数据的逻辑抽象结构,能够按照用户的请求来正确存取DFS层数据。同时,分区层实现了跨数据中心的备份同步功能。   WAS的设计目标是存储海量数据,实现大并发访问。海量存储由分布式存储层来实现,而大并发的目标是如何实现的呢? 从物理存储来看,大并发的压力来自于磁盘I/O和网络带宽。在DFS层,数据的物理存储单位是Extent,100MB-1GB不等。每个对象(Blob,Table或Queue)都由一个或多个Extent拼接而,除此之外,数据还有三个备份。这些Extent离散分布在多台独立的服务器上,因此,用户对对象的访问被分摊在多台服务器上,以达到高吞吐量。 数据逻辑结构的处理需要耗费Memory和CPU资源。Partition层将逻辑数据拆分为多个Partitions,比如:每个Blob, Queue即为一个Partition,Table中PartitionKey相同的所有实体存放在一个Partition。Partition层每台服务器负责服务一组Partitions,Master服务器会检测每台服务器的负载,并动态调整Partitions的分配。由于所有数据都存放在DFS层,因此负载调整会非常迅速。通过动态负载均衡,Partition层确保有足够的资源来响应客户请求。   WAS性能目标 微软在MSDN上公布了WAS的性能目标,这些数据是WAS的性能上限,若用户使用WAS超过指标时,WAS会返回给客户503(Server Busy)或500(Operation Timeout)。当用户接到此类错误时,建议用户采用回退的方式重试操作,这样可以缓解短暂高峰造成的WAS服务压力。 简要来说,性能目标有两层:Partition级和Storage Account级。Storage Account级的目标如下: Total Account Capacity Total Request Rate (assuming 1KB object size) Total Bandwidth for a Geo-Redundant Storage Account Total Bandwidth for a Locally Redundant Storage Account 500 TB Up…

0

Windows Azure Storage 性能调优(一)

WAS (Windows Azure Storage) 是微软提供的云存储服务,也是整个Azure服务的基石,几乎所有Azure产品都依赖于WAS。WAS的性能也紧紧影响到其他服务的性能。在这篇文章中,我总结一下使用WAS的经验,与大家分享。 WAS使用HTTP(S) 协议,访问操作通过发送HTTP请求来完成。访问操作的时间可由Request传输时间、Response传输时间和服务端处理时间组成。   为了提高性能,开发人员可以尝试减少每个过程的时间。总结起来,有如下一些方法: 减少网络延迟 选择最近的数据中心 使用CDN减少网络延迟 减少数据传输 压缩Blob 使用JSON格式 使用实体映射(Entity Projection) 减少请求事务数量 并发访问 其它网络优化 减少服务端受理时间(二) 避免Throttling(二)  此文章介绍网络相关的优化方法。 选择最近的数据中心 网络延迟对任何网络服务的影响都很大。Azure在全球有17+个数据中心,为了减少网络延迟,开发者应该选择离产品用户最近的数据中心。如下网站可以显示你当前的网络访问全球每个数据中心WAS Blob的速度。 http://azurespeedtest.azurewebsites.net/   在选择数据中心时,若没有特别原因,开发者需要尽量避免跨数据中心的网络访问,这样会造成额外的流量费用。比如说用户部署Cloud Service在香港,而Cloud Service需要访问 新加坡的WAS来读取数据,那么这个跨数据中心的访问将被额外收取流量费,而且跨数据中心的网络延迟会比数据中心内部访问要高。 使用CDN减少网络延迟 CDN(Content distributed Network) 是一个常用的HTTP访问优化方法, 其原理是:在某个区域或全球范围内分布很多文件缓存节点,尽可能的离用户更近。当用户需要从站点下载文件时,用户直接访问离他最近的缓存节点,若请求的数据已被缓存,则直接返回客户,起到网络提速功能;若请求的数据未被缓存,则从源站点下载。 Azure CDN有两个版本:Global版的CDN由EdgeCast公司提供,在全球24个地点部署有缓存节点。大陆版的CDN委托给ChinaCache运营,主要针对中国区网络。通过Azure CDN,可以加速WAS Blob, Cloud Service 和 Azure Website的网络访问速度,不过WAS Queue和Table不可以。   Edgecast 缓存节点分布 减少数据传输 减少传输的数据量可以减少Request或Response的网络传输时间。减少数据的方式可以有压缩数据和裁剪无关数据。 压缩 Windows…

0

Microsoft Azure 托管服务监测

没有什么服务是无敌的。当服务发生故障时,每分每秒都意味着客户的影响和经济损失。因此,通过服务监测来迅速报警,以及快速定位和修复问题都非常重要。 从外部或者客户角度来看,Azure托管服务和其他传统服务没有什么区别,因此,很多的监测工具仍然可以用在托管服务上,比如Probe探测,Google analytics。 若从服务内部接口来看,Azure托管服务和传统服务还是有很多不同之处的:托管服务运行在分布式环境下,每台服务器都是无状态的,随时可能被回收重建。因此,把监测日志放到服务器不太可靠,日志随时可能丢失。而且,把日志分散的保存在多台机器上也不利于查询使用。另外,托管服务往往依赖其他云服务(如存储),用户不能够登录到这些依赖服务的后端来检测,其实用户也没有这个义务。 在这篇文章,我想列举一下适用于Azure托管服务的监测方法,当作一个索引。 监测位置 监测方法 虚拟机 虚拟机日志: 如:Application Log, Windows Event Log, IIS Log 及自定义日志文件 性能数据: 如CPU,Memory,每秒请求数… GuestOS Agent Log 3rd party monitoring tool (e.g. NewRelic) 外部 Probe analytics (e.g. google analytics) Azure内置监控功能 Azure服务仪表盘(Status Dashboard) Storage Metrics & Logs Azure管理网站 其他 Application Insight       虚拟机日志 有很多的日志默认输出到服务器本地磁盘上,比如Application Log,Windows Event Log 和 IIS…

0

Microsoft Azure 托管服务可靠性设计

服务的可靠性至关重要,而影响可靠性的因素多种多样,例如程序错误、硬件故障或依赖服务故障,以及人为失误。工程师们要对每个方面做出合理的设计来避免或容错各种故障,才能使服务达到高的可靠性。除此之外,当服务已经中断,如何快速定位问题并解决也是产品设计时就需要考虑的。这篇文章只以“CalculateCloud”为例,讨论一下托管服务的高可靠性设计。 拿出CalculateCloud的架构图看看,影响服务可靠性的有如下几方面: 程序故障:这里只WebRole/WorkerRole代码出错。 服务器故障:这里只运行角色代码的虚拟机发生故障。 依赖外部服务的故障/维护:这里指托管服务所使用的Table或Queue发生故障。 接下来针对每种故障,我们逐个寻找对策: 程序故障 Storage服务故障 服务器故障/维护 追求更高的可靠性 总结 程序故障 托管服务程序的调试和其他代码一样,在开发和测试阶段,可以使用模拟器在本地环境运行和调试代码。比如CalculateCloud非法字符输入的问题,在本地调试时,Visual Studio能够提示WorkerRole代码抛出异常。   对于此问题,使用try/catch来受理异常,问题就搞定了。需要留意的是,一旦部署到生产环境下,debug会比较困难。相比之下,丰富的程序日志能帮助用户监测服务状态和快速定位问题。下面的代码使用默认的 System.Diagnostics.Trace类来输出日志。                 if (msg != null)                 {                     string result = null;                     try                     {                         // handle job here.                         var nums = msg.AsString.Split(‘,’);                         double answer = double.Parse(nums[0]) * double.Parse(nums[1]);                         Thread.Sleep(10000);                         result =…

0

Microsoft Azure 托管服务实践 (CalculateCloud)

Azure是微软推出的云服务品牌之一,主要提供IAAS和PAAS服务。在Azure平台建立初期,微软认为PAAS既拥有IAAS的计算功能,同时还比IAAS更容易管理和规模扩展。在这个理念的推动下,微软在Azure平台只推出了一个PAAS层的计算产品:托管服务(Hosted Service)。 托管服务将业务系统中的模块抽象成“角色(Role)”逻辑单元,开发者只需编写每个“角色”的代码,并声明每个角色的运行环境(网络端口,存储)即可。Azure托管服务控制器(FC,或Fabric Controller)会负责分配虚拟机,配置环境和执行角色代码。 逻辑组件和托管服务组件的对应关系 相比于传统系统,托管服务的部署极为简练,并且,服务器的维护交给FC来自动完成。唯一不足之处是:托管服务的开发模型不同于传统Windows系统开发,传统已有程序不能直接运行在托管服务上,而用户要经过一定的学习才能掌握托管服务开发。 传统系统 托管服务 传统开发模型 需要购买/租借服务器 手动配置服务器环境 手动部署程序到服务器 定期维护服务器,打补丁 服务器故障时,手动做故障迁移 新开发模型,需要额外学习 通过Azure管理界面随时申请服务器资源。 用多少,付多少。 用户一键部署。 服务器维护,硬件故障迁移都有FC自动完成。 这里通过简单的项目示例,操练一下如何使用Azure托管服务。演示项目的源代码请在GitHub下载 https://github.com/mogliang/CalculateCloud   功能需求: 简单的乘法运算处理。用户通过网页递交和查看运算任务。 架构规划: 搭建一个两层结构的系统。前端Web层接受用户的计算请求,做初步处理,然后递交给后端业务逻辑层受理。后端业务逻辑层受理完毕后,由前端层返回结果给用户。 前端层由WebRole实现,后端业务层由WorkerRole担任。WebRole使用Azure消息队列(Queue)向WorkerRole传递任务。WorkerRole将运算结果保存在Azure表(Table)中,由WebRole读取并显示给客户。 托管服务的结构图 这里我们没有使用角色间TCP通信(或HTTP),是因为每个角色都部署在多台虚拟机上,若某台虚拟机故障或拓扑变化,将造成部分通信失败。当然,通过重新连接可以解决问题,只不过队列编程更加简便。   开发准备: Visual Studio 2012/2013 安装 Microsoft Azure Tool for Visual Studiohttp://azure.microsoft.com/en-us/downloads/   实现步骤: 启动Visual Studio,创建一个托管服务。 按照之前规划,我们添加两个Role,一个Asp.net WebRole,取名Calculate.Web,另一个WorkerRole,取名Calculate.Worker。 首先编辑WebRole,在Cloud项目中双击Calculate.Web,打开Role属性面板。点击“Settings”页,添加一个连接字符串。Name为DataConnection,Value为“UseDevelopmentStorage=true”,表示使用云存储模拟器。 这里使用的Setting叫做“托管服务设置字段“,其功能类似于.net 配置文件中的<AppSettings>,这些设置字段可以在服务运行过程中动态更改。 接下来编辑Calculate.Web项目。WebRole项目和普通的ASP.net项目几乎完全相同,只不过WebRole运行在一组虚拟机上,由负载均衡器来把用户请求均分给每台虚拟机。因此,在编程过程中要考虑到分布式环境限制,比如Session存储。WebRole中可以通过RoleEnvironment类来访问托管服务、角色环境等信息。 创建用户提交计算任务的页面。打开Default.aspx,按如下格式添加两个TextBox和一个Button。 在Code-behind文件中引用如下名空间: using Microsoft.WindowsAzure.ServiceRuntime;using…

0