Expose SSL service to multi domains from the same cloud service

When designing and deploying web services to Azure with Azure cloud service, it is very common to apply SSL to secure web access and protect the data transfer, regarding how to enable SSL in cloud service and make custom domain work instead of default cloudapp.net, here are some good tutorials:        1. http://azure.microsoft.com/en-us/documentation/articles/cloud-services-configure-ssl-certificate/        2….


Restrict Remote Access to Cloud VMs

Recently we are working with a project intending to restrict the RDP access of Azure role (worker role/ web role) instance to some specific IP address (a special thanks to Ugo Meex). The tricky thing we should be careful is there is a port mapping for RDP access between public port (3889) and internal port…


Azure Auto Scaling — 设计强伸缩性的云方案

云计算解决方案中,最大的一个特色就是强伸缩性。如果托管服务的工作流量骤增、骤减或者只需服役一段时间,Microsoft Azure可以提供自动化伸缩(Auto Scaling)的功能,Auto Scaling可以依据开发者定义的扩容(缩容)规则来监视运行在云端的托管服务,一旦托管服务的运行达到规则生效条件,Microsoft Azure即启动自动化扩容(缩容)动作,完成扩容(缩容),使其在保证在线上服务的高质量时,使用的云资源最少。 本博文以Azure Cloud Service为例,就常用的基于Auto Scaling的设计和实施进行小结和分析,供Azure开发(架构)者参考。主要包含以下几个部分: 1. 使用Azure管理主页(portal)进行Auto Scaling设计和实现。 2. 高级使用Auto Scaling。 3. Auto Scaling性能调优及关键参数。   使用Azure管理主页实现Auto Scaling 此方法非常简便,无需任何代码或编程操作,开发者登录Microsoft Azure管理门户https://manage.windowsazure.com,选择目标托管服务之后,在Scale页,开发者可以设置Auto Scaling。在默认情况下,Auto Scaling是关闭的(“SCALE BY METRIC”项是“NONE”),但开发者可以手动修改“INSTANCE COUNT”项,临时增加或者减少角色实例的数量。 若开发者选择使用CPU或者Queue Storage来实现Auto Scaling,可以将Scale By Metric置为CPU或者Queue,然后配置具体的Scaling细节,如下参考配置: 更多关于此页面中Scaling设置的参数可以参考配置旁边的?中的提示信息,也可以参考以下文章和实践手册:http://azure.microsoft.com/en-us/documentation/articles/cloud-services-how-to-scale/    高级使用Auto Scaling 采用了上述方法实施Auto Scaling设计以后,开发者往往会发现这样一个问题,当外部流量很大,导致Cloud Service中的每个虚机内CPU使用率高于80%时,Scaling Up(自动化扩容)大约1小时以后才发生,这与预期的效果可能存在差异。对于此问题,需要详细了解一下Auto Scaling工作的机制和主要要点。   主要要点: 1. Role状态正常即指Role中的每一个虚机都正常工作 2. 默认情况下,CPU统计值来自于之前45分钟内该Role下所有虚机的CPU平均。 3. Azure平台中,虚机内部的性能指标,传输到Scaling模块有一定的时差(约15分钟) 鉴于此,可以预期:若0:00分设置基于CPU的Scaling方案,然后迅速将所有的虚机CPU使用率消耗到90%,需要持续将近45+15=60分钟才会有Scaling Up事件发生。 深入了解这个问题,还需要仔细看一下Auto Scaling工作所依赖的配置。使用上述方法在portal上实施Auto Scaling后开发者可以在management…


Windows Azure数据存储与比较

对于绝大多数解决方案而言,数据都是至关重要的一部分,云计算中同样如此。在云计算里面,绝大多数传统存储的建议都可以直接拿来用,如数据冗余、数据加密等。但是云计算中的数据与传统的数据有所不同,主要体现在三个方面。 (1)数据可能存储在本地,也可能存储在云端 对于存储在本地的数据,如果云端服务需要连接,则可以通过建立不同的渠道来实现数据访问或者同步,如图所示Windows Azure中的数据同步技术。 „ 网络与网络互联:IaaS中的Virtual Network实现本地网络和云端网络的无缝整合,云端数据和本地数据都将成为局域网内部的数据,通过传统的局域网通信方式即可实现数据访问和管理。 „ 计算机间互联:IaaS中的Point-to-Site实现单台计算机与云端计算机的安全连接,支持基于IPv4的通信。 „ 应用程序互联:Service Bus实现应用程序间的互联,数据可以通过Service Bus暴露或传递于不同平台上的应用程序之间。 „ 数据同步:基于互联网和软件产品本身的数据同步,如SQL Server和SQL Azure的同步、本地Active Directory和云端Windows Azure Active Directory的同步。 (2)数据访问主要依赖于Internet,但数据访问和安全性要求极高 访问云端的数据或者通过建立云端连接来共享数据均需要保证数据安全性,Microsoft Azure中的数据服务大多数支持SSL通信加密,且提供多种不同安全级别的验证支持,对于SQL Azure和托管服务,开发者都可以自定义访问IP的“白名单”,实现更高级别的安全性保障。归纳起来,Microsoft Azure中的数据服务主要基于以下几个特性来实现数据安全: „ SSL加密通信。 „ 使用用户名、密钥管理数据。 „ 使用SAS签名授权方式控制访问权限。 „ 基于ACS或者WAAD的登录授权。 „ IP白名单、黑名单。 证书加密数据访问密钥等关键信息 (3)数据访问客户端运行于世界各地,访问速度很重要 云计算的数据可以存放在许多地方,而且WindowsAzure数据存储也是非常多样化的。为了实现高性能的数据服务,开发者可以选用最佳的数据存储/缓存来实践解决方案,同时对于公开的云端静态数据(如文件、视频等),选用较近的数据中心,并开启CDN加快访问速度。 选择正确的数据类型时,应充分考虑项目需求和数据上下游的交互压力,除了常用的文件存储和缓存技术之外,对于队列存储和表存储,开发者应仔细分析Queue Storage和Service Bus Queue、Table Storage和SQL Azure的对比,选择最佳的数据类型来实践。 如下表所示是Queue Storage和Service Bus Queue的对比。 服务特性 Queue Storage Service Bus Queue…


Azure Virtual Machines — 4 designing proposals on switching Azure IaaS VM for higher availability.

After migrating whole local solution to Azure or integrating cloud solution with local modules, customer might be impacted by monthly Azure backend update or exceptional backend physical issues, this resulted in availability impact to customers. In order to improve service availability and avoid troubles from unexpected VM reboot from either Azure platform upgrade or other…


Azure Service Bus Relay 深入分析和网络依赖

之前的一篇博文http://blogs.msdn.com/b/jianwu/archive/2014/10/15/azure-service-bus-service-bus-relay.aspx中,提到了Service Bus Relay的工作机制和实践方法,包括纯代码方式配置WCF/Service Bus endpoint和纯配置方式实现Service Bus Relay/WCF。实际运行过程中,虽然Service Bus Relay对本地的网络环境没有特殊要求,在最极端的情况下,只要客户端环境可以访问internet(http),Service Bus Relay就可以使得分布在不同地方的这样的客户端之间建立任意互联。但针对不同的 Service Bus Relay服务所选择的绑定协议和实现,Service Bus Relay对本地的网络还是有一定的要求的。本博客对Service Bus Relay服务所需的网络依赖以及Service Bus Relay的深入分析加以总结。   =1=. Service Bus Relay的网络依赖 如MSDN的解释:http://msdn.microsoft.com/en-us/library/ee732535.aspx 对于之前博文中选择的NetTcpRelayBinding方式所实现的Service Bus Relay(中继)服务,客户端需要允许端口9532和80上的对外连接。一般情况下,基于80端口的对外访问往往不会被本地IT限制,但在一些客户的网络环境下,基于9532端口的对外访问有可能会被禁止,因此,在那样的网络环境中,若要使得基于NetTcpRelayBinding方式的Service Bus Relay服务正常工作,需要事先联系本地网络管理员,开启对外端口9532的访问。 Binding Transport  Security Port NetTcpRelayBinding  (client/service) either 9352/HTTP (9352/9353 if using Hybrid) 尽管如此,在开发Service Bus Relay服务中,开发者可以通过选择灵活的绑定方式和Service Bus服务的特殊网络设定,来规避上述端口的开启和关闭。 如:http://msdn.microsoft.com/en-us/library/microsoft.servicebus.connectivitymode.aspx Member name Description AutoDetect Auto-detect mode. Automatically…


Azure Service Bus — 深入实践 Service Bus Relay(中继)

Azure Service Bus通过为服务提供了一套通用的命名规范简化了许多通信难题,在独立于网络拓扑和配置的节点之间提供直接或间接的通信。Service Bus允许WCF应用程序监听公共网络地址,即使其位于NAT或网络防火墙后方。该功能使得应用程序的通信可以无关于其网络结构。使用Service Bus便无需编写与维护复杂的逻辑和代码来跨越不同的网络通信。 如图,Azure Service Bus的实现原理: 主要过程为:1-2. 已有服务程序(如WCF)连接Azure上的Access Control(连接控制)服务,获得密钥。3. 已有服务程序使用密钥连接Service Bus Relay(中继)服务,将本地服务注册到Service Bus Relay(中继)上,使得本地服务具备基于互联网的公开访问端口。4-5. 客户端应用程序连接Azure上的Access Control(连接控制)服务,获得密钥。6. 客户端使用密钥连接注册在Service Bus Relay(中继)上的指定服务。7. Service Bus Relay(中继)将6的请求转发到具体的本地服务程序处理。8-9. 本地服务程序处理完请求后,返回结果经Service Bus Relay(中继)最后达到客户端应用。 因此,Service Bus Relay(中继)服务主要能带来以下利好:1. 处于不同网络(地域)的客户端能自如的建立实时通信(不需要独立公网IP,不需要特殊的网络安全配置等)2. 本地已有的WCF服务能够通过Service Bus Relay(中继)暴露到互联网上,供异地的客户端随时连接、调用。 本篇将深入实践Service Bus Relay(中继)服务,分为两个部分:1. 通过Service Bus Relay(中继)实现WCF服务的暴露和访问(包括本地WCF访问)2. 通过传统WCF配置方式来完成Service Bus Relay(中继)服务调用实现。 关于WCF服务,在传统开发中应用非常常见,其定义为:http://msdn.microsoft.com/zh-cn/library/vstudio/ms731082(v=vs.90).aspx  简而言之,WCF是.Net框架下符合SOAP标准的web service,其服务可以被不同开发语言实现的客户端调用。更多内容请参见:http://msdn.microsoft.com/zh-cn/library/vstudio/ms731190(v=vs.90).aspx   实践一、通过Service Bus Relay(中继)实现WCF服务的暴露和访问 步骤一:创建Service Bus NameSpace 登录到Azure管理主页: Windows…


Azure云服务中的进程通信和数据预加载

在http://blogs.msdn.com/b/jianwu/archive/2014/09/11/azure-paas.aspx(Azure PaaS – Cloud Service服务架构及快速调试)中,大家了解到了云服务(Cloud Service)在实际运行过程中的具体分布:多个进程依次被启动。其中,最为重要的是进程WaIISHost(WaWorkerHost)和w3wp进程,前者运行着WebRole.cs(WorkerRole.cs)中代码逻辑及维持着Microsoft.WindowsAzure.ServiceRuntime环境,后者运行着网站(服务)项目的业务逻辑。如图所示: 由于在开发时,WebRole.cs(WorkerRole.cs)和网站项目所属于同一个项目且定义在同一个命名空间(NameSpace)下面,在一些开发项目中,常常会遇到一个问题: 1. 如何让WebRole.cs(WorkerRole.cs)和网站项目快速的共享信息(即部署到云中后,WaIISHost(WaWorkerHost)和w3wp进程高效通信) 2. 如何使得网站项目w3wp能在刚启动时就先加载一些依赖数据(如供查询用的词典库) 本篇就这两个问题,结合手头上跟进的一两个项目,对常用的方法加以总结。主要覆盖以下几个方面: 1. 使用WCF服务来交换信息(进程通信) 2. 使用公有云缓存来共享信息(数据预加载) 3. 云中常用的数据交互方式   (一)使用WCF服务来交换信息 一个常见的场景是:WebRole.cs中的代码逻辑需要读取网站配置中的配置项(如变量字符串,数据库连接等),且网站配置中的内容有可能是来自于web.config,也有可能来自Web Config Transformation以后的结果。 关于Web Config Transformation,这里简单描述一下: 添加配置项到web.config时,既可以直接添加配置节 如<appSettings> <add key=”setting1″ value=”hello, world.”/> </appSettings>到web.config中,也可以通过项目属性中的setting来添加,如图: 添加完成以后,可以发现,两种不同方式添加进来的配置出现在不同的配置节里。<applicationSettings>中指明了配置变量的类型和使用空间范围,较<appSettings>更适用于较大的项目。 对于<appSettings>下的配置,可以采用System.Configuration.ConfigurationManager.AppSettings[“setting1”].ToString();方法来读取。 对于<applicationSettings>下的配置,可以采用Properties.Settings.Default[“Setting1”].ToString();方法来读取。   实际项目过程中,本地调试和线上运行时所依赖的配置项很可能不相同,仔细查看VS项目会发现,web.config下面有子文件,如web.debug.config,开发者可以在web.debug.config里面添加以下内容,其意义在于替换web.config中变量Setting1的值。 于是,在选择项目生成时,若使用web.debug.config,如下图,生成的web role部署包中的web.config既是web.debug.config覆盖原有web.config的结果。这既是web config transformation技术,在传统.Net网站开发中经常使用。 回到主题:如何使用WCF服务来使得webrole.cs和网站进程w3wp交换信息呢?如下实现方式: 1. 添加一个WCF服务到网站项目中 2. 在新建的服务中添加一个新的方法和具体实现         public string GetWebConfigSetting(string key)        {            string retVal = null;            try           …


Azure PaaS — 多服务并行托管及REST部署

在Microsoft Azure中部署多个网站项目,可以考虑在单个Web Role中加载多个网站项目,使得在减少Web Role角色数量的情况下降低Microsoft Azure的使用成本。同时,单个Web Role的多个实例仍然可以保证每个网站项目的SLA,以及进一步添加Auto Scaling功能可以保障整个托管服务Role的处理能力。因此,在同一个Web Role角色中加载多个网站项目在一些场景下是不错的选择。   1. 多服务并行托管 在同一个Web Role角色中加载多个网站项目主要有两种形式。 „ 虚拟目录:主网站项目将部署在实例虚拟机的IIS中,对外服务使用指定端口(如80)。IIS在该主网站中创建虚拟目录,然后将额外的网站分别部署在这些虚拟目录中。部署完毕之后,主网站的对外服务网址是http://**.cloudapp.net,其他网站的对外服务地址是http://**.cloudapp.net/VirtualDirectoryName/。 „ 多端口服务:主网站和额外的网站项目都部署在实例虚拟机的IIS中,对外服务使用不同的指定端口(如80和8080)。主网站的对外服务网址是http://**.cloudapp.net,其他网站的对外服务地址是http://**.cloudapp.net:8080。 采用虚拟目录方式部署使得所有的网站项目都在同一个服务进程中(W3WP),相互之间会有干扰,如果其中一个网站发生异常导致该进程退出后,该虚拟机上所有的其他网站都不再工作,但采用此方式的一个好处是所有的网站项目可以共享Session等状态信息。 如下图所示的实例项目,Web Role角色使用的网站项目是WebRole1,但整个解决方案中还包含两个额外的网站项目:SubWebApplication1和WebApplication2,它们都是单独的网站项目。部署到云端以后,主网站项目WebRole1对外服务的地址将是http://***.cloudapp.net。     若在该Web Role中以虚拟目录的形式加载网站项目SubWebApplication1,则需要对Web Role所在项目中的ServiceDefinition.csdef文件做以下配置(添加了VirtualApplication对应的配置部分)。 <Site name=”Web”>   <VirtualApplication name=”TestVWeb” physicalDirectory=”../SubWebApplication1″/>   <Bindings>     <Binding name=”Endpoint1″ endpointName=”Endpoint1″ />   </Bindings> </Site> 此配置的作用是在WebRole1网站项目中创建一个虚拟目录TestVWeb,用以加载网站项目SubWebApplication1。部署到云端以后,SubWebApplication1网站对外服务的地址将是http://***.cloudapp.net/TestVWeb。 采用多端口服务方式部署将所有的网站运行在不同的服务进程(W3WP)中,相互之间独立运行,互不干扰。在上面的实例项目中,主网站WebRole1和以虚拟路径配置的网站SubWebApplication1均使用80端口对外服务,另外一个网站项目WebApplication2可以使用另外一个对外服务端口8080,同样对Web Role所在项目中的ServiceDefinition.csdef文件添加以下配置。 <Site name=”WebSite2″ physicalDirectory=”../WebApplication2/”>   <Bindings>     <Binding name=”Endpoint2″ endpointName=”Endpoint2″ />  …


Windows Azure Storage – 表数据查询及WAD分析最佳实践

在开发Windows Azure应用程序时,经常会出现读取/写入WAS表存储(Table Storage)慢甚至超时的问题,引起这类问题的主要原因是,开发者在对表数据规划和操作时没有充分注意到表存储的后端特性,导致简单的写入/读取操作密集到WAS后端繁忙的服务器节点上。本文就常见的表数据规划、查询及WAD表数据分析等问题加以小结。 1. 了解WAS底层实现结构 WAS存储内部包括如下三层结构,所有的数据访问请求都是经过前端进行逐步处理的。 前端(Front End,FE):负责处理接收外部请求、验证用户身份和分发数据请求。前端根据其缓存的存储分区映射表(Partition Map)将合法请求发送到相应的存储分区(Partition),不能通过验证的请求直接在前端被拒绝。 存储分区层(Partition Layer,即索引分区):含有所有访问数据的检索关键字,存储分区层根据数据请求的关键字进行索引,如果是读操作,那么存储分区层在其缓存块中先查找结果,若存在相应缓存,则直接返回。如果没有缓存或者当前操作为写操作,存储分区层则根据其含有的检索表找到与数据请求对应的底层存储文件系统服务器,执行数据请求。每个Partition Layer都可以访问底层所有的分布式文件存储服务器。 分布式文件系统层(Distributed File System Layer):数据最终存储的位置,每份数据均会存储在3个不同的分布式文件服务器中,实现冗余。   2. 简单的Table Storage操作 如http://blogs.msdn.com/b/jianwu/archive/2014/08/14/azure-paas-2.aspx常规的WAS编程实践。 如常见的Table Storage操作:     定义表数据结构,指定Partition Key和Row Key     public class CustomerEntity : TableEntity    {        public CustomerEntity(string lastName, string firstName)        {            this.PartitionKey = lastName;            this.RowKey = firstName;        }         public CustomerEntity() { }         public string…