实现以应用程序为中心的云计算管理

对应用程序和工作负载的部署和管理进行自动化的三个步骤

管理云计算中复杂的应用程序和工作负载需要对基础设施进行及时的自动的重新配置。以应用程序为中心的管理让管理员可以作为统一的系统控制所需的所有资源,通过单一系统定义控制所有运行时服务的参数。这种管理方式可以有效地把云的性能保持在最高水平。本文定义以应用程序为中心的管理风格以及实现它的三个关键步骤,演示如何自动地在 IBM® Cloud 中部署一个两层的 J2EE 应用程序。您将学习如何创建动作、把动作与事件关联起来和处理事件。

Joydeep Biswas, 资深软件开发人员, Kaavo

Joydeep Biswas 是一位资深软件开发人员,在 Kaavo 从事 IMOD 产品。他在开发企业级 Java 应用程序方面有五年多经验。Joydeep 从位居印度前十大大学的 Jadavpur University 获得了计算机科学和工程学士和硕士学位。Joydeep 在 Jadavpur University 获得了最优秀毕业生奖章。



2010 年 11 月 29 日

随着对计算资源的需求增加,部署正变得越来越复杂。如果没有及时的自动的基础设施重新配置,忙碌的 IT 部门几乎不可能管理云计算中复杂的应用程序和工作负载。更不用说,云计算提供商必须能够在没有人工干预的情况下处理生产意外、管理应用程序和工作负载服务水平和资源以及调度活动。

基础设施服务提供商宣称用户可以通过云部署节约成本。为了实现这一承诺,需要用增强的生命周期管理工具适当地管理应用程序,实现高效率。最终用户需要能够在云基础设施上配置防火墙、自动地部署和配置软件,从而运行和管理自己的应用程序和工作负载。以应用程序为中心的管理 是一种自上而下的云计算管理方式,它意味着从应用程序所有者的角度管理在云计算中运行应用程序和工作负载所需的服务、软件、基础设施、中间件、网络和存储。它让用户可以作为一个统一的系统管理给定的应用程序需要的所有资源。

本文介绍以应用程序为中心的管理,讨论如何通过这种管理方式在公共、私有和混合型云计算中自动地部署和管理任何应用程序或工作负载。作为示例的用例是部署一个两层的 J2EE 应用程序,包括负载平衡器和 J2EE 服务器,实现自动扩展、自动恢复等自动化特性,从而自动地管理运行时服务水平。我们的示例部署在 IBM Smart Business Development and Test Cloud 上,过程适用于任何云计算环境;示例使用 IMOD(见 边栏)。IMOD 框架基于 Kaavo 发明的正在申请专利的技术,可以对任何复杂的多服务器、多层应用程序或工作负载的部署和运行时管理进行自动化。

以应用程序为中心是一种通用方式

在以应用程序为中心的云计算环境中,针对特定的应用程序管理系统,而不是管理服务器和路由器。作为一个统一的系统管理给定的应用程序需要的所有资源;对于给定的应用程序需要的资源,用于部署和管理运行时服务水平的所有信息集中在单一系统定义中。这称为自顶向下方式

相反,在以基础设施为中心(即自底向上方式 )的云计算环境中,单独地管理各种资源(服务器、存储和网络资源)。

以应用程序为中心的管理为应用程序所有者提供更强的灵活性,让他们能够更好地控制、监视、自动化和保护应用程序使用的基础设施资源。

尽管本文通过 IMOD 软件部署某个 Java™ 应用程序,以此说明以应用程序为中心的云计算管理方式,但是这些概念和技术可以应用于其他应用程序和系统。例如:

  • 系统定义文件(用于定义多层应用程序)是 XML 文件。
  • 本文中提供的代码示例是 XML 和 shell 脚本。
  • 用图形化向导自动生成 XML,用户不需要手工编写 XML。
  • 本文的系统定义文件中定义的组件概念(动作、事件、层等)都是多层 web 应用程序(在本文中是一个 J2EE 应用程序)的通用组件。
  • IMOD 软件本身设计成能够与任何云平台交互,当前与五种不同的云集成。

在 IMOD 中实现以应用程序为中心的管理的三个关键步骤

在云计算中构建以应用程序为中心的管理系统的三个关键步骤如下:

  1. 定义应用程序。这包括:
    • 定义系统结构。
    • 配置服务器组。
    • 定义动作。
    • 定义标准事件的挂钩。
    • 定义定制的事件。
  2. 设置自动引导(Autopilot)。
  3. 启动/部署系统。

在本文中,您会看到如何使用这种方式自动地在 IBM Cloud 中部署一个两层的 J2EE 应用程序。


关于脚本语言

本文中的代码示例是标准的命令行脚本;基本上就是系统管理员在手工执行这些步骤时使用的命令。没有使用专有的脚本或编程语言。

脚本是在目标服务器上执行的一系列命令。它们可以是 shell 脚本、Perl 脚本、Python 脚本等等。如果脚本需要只有在运行时才能得到的信息,那么使用 Apache Velocity 模板 动态地生成这些脚本。

install-jdk 动作 的主体是一个 shell 脚本,它调用 wgettar 等标准 Linux 命令(见以下代码);可以使用其他任何脚本语言。

shell 脚本示例
/usr/bin/wget -O /opt/jdk1.6.tar.gz http://SOURCE.com/jdk1.6.0_16.tar.gz
cd /opt/
 tar -xzvf jdk1.6.tar.gz
ln  -s /opt/jdk1.6.0_16/ /usr/local/java

按相似的方式处理配置文件。configure-apache-balancer 动作的主体见以下代码:

配置文件示例
<Proxy balancer://mycluster>
                    #foreach ($node in $AppNodes)
                    BalancerMember http://$node.publicIP:8080
                   #end
        </Proxy>
           ProxyPass /app balancer://mycluster
        <Location /balancer-manager>
                     SetHandler balancer-manager
                     Order Deny,Allow
                     Allow from all
         </Location>

当调用这个模板时,它为 apache mod_proxy 生成配置文件。基于 XML 的系统定义文件不用于描述应用程序,主要用于内部表示。

有许多 GUI 向导可以自动生成系统定义文件。下面的 XML 片段是由向导生成的。

由向导生成的 XML 片段
          <serverType role="ndbd" min="1" max="6"> 
           <ibmServer> 
            <name>AppNode</name>  
            <ibmAccount>xxxx</ibmAccount>  
            <keypair>yyyy</keypair>  
            <imageIdentifier>20001150</imageIdentifier>  
            <instanceType>BRZ32.1/2048/175</instanceType>  
            <location>41</location>  
            ..........//Event and other information              
            <startupCount>2</startupCount>  
          </ibmServer> 
         </serverType>

示例:定义应用程序

实现以应用程序为中心的管理的第一步是定义应用程序。我们先讨论 IMOD 的组件以及每个组件的作用。

Kaavo 的 IMOD

Kaavo 的 IMOD 使用正在申请专利的技术对云计算中的虚拟资源进行以应用程序为中心的管理。IMOD 提供容易使用的 web 界面,可以在公共、私有和混合型云计算中部署、运行和管理复杂的多服务器多层应用程序。更多信息参考 Kaavo 产品和技术。

在 IMOD 中,使用称为系统定义文件的 XML 文件定义完整的多层应用程序(即系统);更多信息见 参考资料 中的 N-Tier Guide System Definition wiki。定义系统之后,只需一次单击即可部署整个应用程序。

系统定义文件有两个组件:部署时和运行时:

  • 部署组件包含与供应资源相关的所有信息,它部署和配置中间件和应用程序组件,让应用程序上线。
  • 运行时组件包含在响应已定义事件时执行的工作流,用来确保在运行时自动地满足应用程序服务水平要求,不需要人工干预。

部署系统之后,可以通过 “自动引导” 功能自动地为应用程序提供生产支持。

其他 IMOD 元素包括:

  • 服务器
  • 服务器类型,服务器组
  • n 层
  • 动作:可执行和不可执行的动作
  • 事件:标准和定制的事件

我们来详细讨论每个元素。

服务器

服务器直接代表云计算中的虚拟服务器或实例。服务器由许多参数指定:用于供应实例的云服务账户 (ibmAccount)、用于创建实例的映像 (imageIdentifier)、实例的类型 (instanceType) 等等。清单 1 演示如何使用 XML 在 IBM Cloud 中指定实例。

清单 1. 使用 XML 在 IBM Cloud 中指定实例
<ibmServer> 
  <name>AppNode</name>  
  <ibmAccount>xxxx</ibmAccount>  
  <keypair>yyyy</keypair>  
  <imageIdentifier>20001150</imageIdentifier>  
  <instanceType>BRZ32.1/2048/175</instanceType>  
  <location>41</location>  

  ..........//Event and other information    
  <startupCount>2</startupCount>  
</ibmServer>

服务器类型,服务器组

在 IMOD 中,服务器被组织为组。组的规模可以是指定范围内的任何规模;组的规模取决于部署的规模。

每个组具有初始规模,在运行时规模可能随运行时负载和自动引导设置变化。组的所有成员在创建时是相同的,但是组中不同服务器的配置可以略有差异。

服务器组的示例包括 mysql 集群中的 ndbd 节点组、mysql 集群中的 manager 节点组、jboss 集群中的 jboss 节点组等等。

清单 2 给出一个描述服务器类型的 XML 片段。role 惟一地标识服务器类型。属性 minmax 分别表示最大和最小组规模。标记 startupCount 表示初始组规模。

清单 2. 描述服务器类型的 XML 片段
<serverType role="ndbd" min="1" max="6"> 
          <ibmServer> 
            <name>AppNode</name>  
            <ibmAccount>xxxx</ibmAccount>  
            <keypair>yyyy</keypair>  
            <imageIdentifier>20001150</imageIdentifier>  
            <instanceType>BRZ32.1/2048/175</instanceType>  
            <location>41</location>  
            ..........//Event and other information              
            <startupCount>2</startupCount>  
          </ibmServer> 
</serverType>

n 层架构

多层n 层架构 是一种客户端-服务器架构,在这种架构中表示、应用程序处理和数据管理是逻辑上隔离的过程。n 层架构的主要好处是让开发人员可以构建出更灵活、更容易重用的应用程序,因为在修改或升级时只需修改涉及的层。n 层应用程序的例子是在用户和数据库之间使用中间件处理数据请求的应用程序。三层架构是最常用的。

层直接代表多层应用程序中的一层。层由一些服务器组组成。例如,基于 mysql 集群的数据库层可能包含两个服务器组,一个 ndbd 组和一个 manager 组。在部署多层应用程序时,按指定的层启动次序部署各个层。清单 3 给出包含两个服务器组的数据库层的 XML 片段。

清单 3. 两个服务器组的数据库层的 XML 片段
<tier displayindex="3">
      <name>db_tier</name>  
      .....//Event and other information 
      <serverTypes>
        
	   <serverType role="manager" min="1" max="1">
          <ibmServer>
            ....
          </ibmServer>
        </serverType>  

        <serverType role="ndbd" min="2" max="2">
          <ibmServer>
            ...
          </ibmServer>
        </serverType>

      </serverTypes>
</tier>

n 层

这代表多层应用程序,它由几个层组成。清单 4 显示 n 层的 XML 片段。

清单 4. n 层的 XML 片段
<ntier>
    .../Event and other information
    <tier displayindex="1">
     ...
    </tier>
    
    <tier displayindex="2">
     ...
    </tier>

    <tier displayindex="3">
     ...
    </tier>

</ntier>

动作

动作就像是可重用的过程。它们用于从 Velocity 模板生成可执行的脚本和配置文件并复制到目标服务器,还可以执行可执行脚本。有两类动作:

  • 可执行的
  • 不可执行的

可执行的动作
可执行的动作生成可执行脚本,并把脚本复制到指定的服务器集上的指定位置。清单 5 是可执行动作的示例。

清单 5. 可执行的动作
<action name="start-apache" execute="true" 
 target="[tier=web_tier][serverrole=default]">
       <scriptName>apache.sh</scriptName>
       <scriptPath>/root</scriptPath>
       <scriptTemplate type="inline">
       <![CDATA[
               /etc/init.d/httpd start
               ]]>
       </scriptTemplate>

</action>
  • execute 属性指定此动作是否可执行。在这个示例中,execute="true" 指定此动作是可执行的。
  • target 属性指定将执行脚本的目标服务器集。 表达式 [tier=web_tier][serverrole=default] 返回 tier(web_tier) 层中,类型为 server type(default) 的一组服务器。
  • scriptPath 元素指定生成的脚本要复制到的目录;scriptName 指定脚本保存为的文件名。
  • scriptTemplate 元素包含动作的主体。动作的主体是 Velocity 模板(Velocity 是一个基于 Java 的模板引擎,它让 web 设计者可以引用用 Java 代码定义的方法)。但是,在这个简单的示例中,主体是静态文本。

在事件处理函数中可以使用以下语法调用动作:

<command type="action" name="action-name" />

很容易看出,在执行这个动作(或其他可执行动作)时,会对每个目标服务器执行以下三个步骤:

  1. 使用 Velocity 模板引擎显示 Velocity 模板。在这个示例中,模板是静态文本,所以生成的内容与模板相同(例如 /etc/init.d/httpd start)。
  2. 在目标服务器上的路径 /root/apache.sh 中,创建包含生成的内容的文件。
  3. 在目标服务器上执行脚本 /root/apache.sh。

图 1 说明如何在日志中集中地记录动作的执行,以便进行审计和调试。

图 1. 动作的日志记录示例
动作的日志记录示例

清单 6 给出另一个示例,它使用比较复杂的 Velocity 模板。

清单 6. 另一个比较复杂的 Velocity 模板示例
      <scriptName>GrantPhpDbAccess.sh</scriptName>  
      <scriptPath>/root</scriptPath>  
      <scriptTemplate type="inline">
         
        <![CDATA[
#!/bin/sh
#foreach ($clientNode in $SqlClientNodes)
mysql -uroot -p${mysqladminpassword} -e "GRANT ALL PRIVILEGES ON ${appdb}.*
   TO '${appdbuser}'@'${clientNode.publicIP}' IDENTIFIED BY '${appdbpassword}'"
#end	  
        ]]> 
      </scriptTemplate>  
      <parameters> 
        <parameter name="mysqladminpassword" type="literal" value="kaavo"/>  
        <parameter name="appdb" type="literal" value="php_collab"/>  
        <parameter name="appdbuser" type="literal" value="phpcollab"/>  
        <parameter name="appdbpassword" type="literal" value="admin"/>  
        <parameter name="SqlClientNodes" type="serverref" 
         value="[tier=app_tier][serverrole=default]"/> 
      </parameters>      
 </action>

这个动作的主体包含动态内容。这个动作接受 5 个参数:mysqladminpasswordappdb 等。它们有使用 value 属性指定的默认值。

前 4 个参数 (type="literal") 初始化为由 value 属性指定的字符串。最后一个参数 (SqlClientNodes) 初始化为由表达式 [tier=app_tier][serverrole=default] 返回的服务器对象集合。在第 1 步(使用 Velocity 模板引擎调用 Velocity 模板)中执行这个动作时,解析这些参数的引用。

每个服务器对象都有许多属性(例如 publicIP),可以在模板中访问它们。foreach 循环遍历 $SqlClientNodes 集合,$clientNode 作为循环变量。在循环的每次迭代中,使用 ${clientNode.publicIP} 获取服务器对象的公共 IP。这个动作生成以下脚本:

清单 7. 循环的每次迭代获取服务器对象的公共 IP
#!/bin/sh
mysql -uroot -pkaavo -e "GRANT ALL PRIVILEGES ON php_collab.* TO
 'phpcollab'@'publicIP1' IDENTIFIED BY 'admin'
mysql -uroot -pkaavo -e "GRANT ALL PRIVILEGES ON php_collab.* TO
 'phpcollab'@'publicIP2' IDENTIFIED BY 'admin'
...
...
mysql -uroot -pkaavo -e "GRANT ALL PRIVILEGES ON php_collab.* TO
 'phpcollab'@'publicIPn' IDENTIFIED BY 'admin'

其中的 publicIP1, publicIP2, ..., publicIPn 代表 SqlClientNodes 集合中所有服务器的公共 IP(换句话说,app_tier 层中服务器类型为 default 的所有服务器的公共 IP)。

刚才定义的参数是用户定义的参数。除了这些参数之外,还有三个隐式参数,也可以在模板中引用它们:

  • CurrentTarget(正在创建脚本的目标节点)
  • AllTargets(作为动作目标的所有节点)
  • OtherTargets(除 CurrentTarget 之外的所有目标节点)

(参考资料中的 N-Tier Guide 提供服务器对象属性和隐式参数的完整列表。)

在系统生命周期的任何阶段,都可以使用向导添加和编辑动作(图 2)。

图 2. 使用向导添加动作
使用向导添加动作

不可执行的动作
不可执行的动作与可执行的动作相似;惟一的差异是这些动作在第 1 步和第 2 步中生成不可执行的文件。对于这种动作,不存在第 3 步,因为它们的 execute 属性设置为 false

事件

通过向 n 层、层、服务器组或组中的各个服务器发送事件来控制它们。事件具有指定的目标。可以以不同的方式触发事件:

  • 手工:用户可以使用用户界面触发事件。
  • 通过事件调度器。
  • 通过发出 web 服务调用(这允许用户通过使用 document/literal 包装风格的 SOAP 程序化地与 IMOD 交互)。
  • 通过在监视系统中设置触发器(见 N-Tier Guide)。

有两类事件:标准和定制的事件。

标准事件
标准事件是预定义的事件。每当在 IMOD 中定义系统时,就会定义这些事件。

有两类标准事件:StartStop。n 层、层和服务器(组)都可以是这些事件的目标,所以它们都有启动事件和停止事件。例如 start ntierstart tier1start tier2start server1start server2stop tier1 等等。

每个事件有一个处理函数,即在发生此事件时执行的代码块。对于标准事件,事件处理函数是预定义的。但是,可以通过实现它们的预定义挂钩定制这些事件处理函数的默认行为。启动事件有启动后挂钩;停止事件有关闭前挂钩。清单 8 说明这些事件处理函数的结构。

清单 8. 用伪代码表示的事件处理函数结构
Proc Start-server-handler
  Begin
       Execute start-server-default-logic
       Execute post-startup hook
  END

Proc Stop-server-handler
  Begin
       Execute pre-shutdown hook
       Execute stop-server-default-logic       
  END

启动服务器的默认逻辑(在清单 8 中称为 start-server-default-logic)是在后端的云计算中供应一个服务器。停止服务器的默认逻辑是取消供应服务器。启动后和关闭前挂钩在默认情况下是空的。

定制的事件
除了默认提供的标准事件之外,用户还可以定义自己的事件。清单 9 是定制事件的示例。

清单 9. 用户定义的定制事件
<event name="system-scaleup" description="App system scaleup" type="custom"> 
      <handler timeout="6000"> 
        <pre-process> 
          	<startServers> 
            	       <serverType role="[tier=app_tier][serverrole=default]" count="1" 
                          addToEvent="true"/> 
          	</startServers> 
        </pre-process>  
        <process> 
         	 <command type="action" name="start-app" 
              target="[tier=app_tier][serverrole=default][scaleupserver]"/>  
          <command type="action" name="configure-apache-balancer"/>  
          <command type="action" name="reset-apache"/>        
        </process> 
     </handler> 
 </event>

事件由名称标识并定义相应的事件处理函数。因此,如果在系统中定义清单 9 中的事件,那么在发生 system-scaleup 事件时,会执行指定的处理函数。

这个事件处理函数启动一个新的服务器,通过在它上面执行一系列命令来配置它。这种事件处理函数可以用于在现有的系统中添加更多实例。

可以以相似的方式定义用于恢复故障服务器的事件(清单 10)。

清单 10. 用于恢复故障服务器的事件
<event name="server-recovery" description="App server recovery" type="custom"> 
      <handler timeout="6000"> 
        <pre-process> 
          <recoverServers> 
            		<server server-to-recover="[context=event][param=instanceid]"/> 
          </recoverServers> 
        </pre-process>  
        <process> 
         	 <command type="action" name="start-app" 
              target="[tier=app_tier][serverrole=default][recoveringserver]"/>  
          	<command type="action" name="configure-apache-balancer"/>  
          	<command type="action" name="reset-apache"/> 
        </process> 
      </handler> 
 </event>

startServersrecoverServersstopServers 等元素只能在定制事件的事件处理函数中使用。

同样,关于定制事件的详细说明参见 参考资料 中的 N-Tier Guide。


示例:定义系统

对于运行本文中的应用程序,一个服务器就足够了,但是为了说明某些特性,我们用多个负载平衡的服务器运行应用程序。这个系统设计成两层的系统,运行 J2EE 应用程序的应用程序层和负载平衡器层。图 3 以最简单的方式说明部署的架构。

图 3. 两层部署的架构
两层部署的架构

能够使用两个单独的层是因为 IMOD 的 n 层引擎允许定义层的部署次序。负载平衡器配置文件要引用应用服务器的 IP 地址,因此在设置和运行应用服务器并为它们分配 IP 地址之前无法配置负载平衡器。

这个架构必须映射为一个 IMOD n 层系统。需要的关键元素如下:

  1. 两个层。
  2. 两个服务器组。
  3. 一些动作(安装、配置、启动和重新启动)。
  4. 标准事件的挂钩。
  5. 一些定制的事件(扩展、收缩和恢复出故障的服务器)。
  6. 定制事件的触发条件和参数。

下面详细讨论每个元素。

1. 两个层

我们把这两层命名为 app-tier(应用程序层)和 lb-tier(负载平衡器层)。app-tier 包含一个服务器组 (app-group),lb-tier 也包含一个服务器组 (lb-group)。

2. 两个服务器组

两个服务器组 app-group 和 lb-group 由不同的服务器集实现。app-group 由 IBM SUSE Linux Enterprise Server 11 (x86) 基本映像实现;lb-group 由 Red Hat Enterprise Linux 5.4 (32-bit) 基本映像实现。

3. 动作

需要用于安装、配置、启动和重新启动服务器以及打开端口的动作。

在 lb-group 服务器上安装 Apache
这个动作命名为 install-apache。这是一个静态脚本,已经作为必需的 Velocity 模板提供了。它执行下面这样的操作。

Action-type: executable 
Script to be executed:

wget http://3rdparty-tools.s3.amazonaws.com/apache/httpd-2.2.14.tar.gz
 tar -xzvf  httpd-2.2.14.tar.gz
 cd httpd-2.2.14
 export CFLAGS=-O2
 ./configure --prefix=/usr/local/apache2 --enable-mods-shared=all
  --enable-proxy_balancer=shared --enable-proxy_http=shared --enable-rewrite=shared
  --enable-proxy=shared
 make
 make install
 echo "Include conf/extra/httpd-IMOD.conf" >> /usr/local/apache2/conf/httpd.conf

在 lb-group 服务器上配置 Apache 负载平衡器
这个动作命名为 configure-apache-balancer

Action-type: non-executable
Config file to be copied:
<Proxy balancer://mycluster>
                    	
        BalancerMember http://publicIP1:8080
        BalancerMember http://publicIP2:8080
        ....
        ....
        BalancerMember http://publicIPn:8080
                   	
</Proxy>
ProxyPass /app balancer://mycluster
<Location /balancer-manager>
        SetHandler balancer-manager
        Order Deny,Allow
        Allow from all
</Location>

在这里,publicIP1, publicIP2, ..., publicIPn 是负载平衡的服务器(换句话说,app-tier 层中的 app-group 服务器)的公共 IP。

显然,需要用一个参数化的动态动作根据 app-tier 层中 app-group 服务器的 publicIP 生成 BalancerMember 行。在运行这些服务器之前,公共 IP 是未知的。

这个动作必需的 Velocity 模板如下所示:

<Proxy balancer://mycluster>
       #foreach ($node in $appNodes)
       BalancerMember http://$node.publicIP:8080
       #end
</Proxy>
  ProxyPass /app balancer://mycluster
<Location /balancer-manager>
       SetHandler balancer-manager
       Order Deny,Allow
       Allow from all
</Location>

在这里,一个 foreach 循环遍历服务器集合 ($appNodes),生成 BalancerMember 行。必须作为参数传递这个集合。

在 lb-group 服务器上启动 Apache 并打开端口
这个动作命名为 start-apache。这是一个静态脚本。

Action-type: executable
Script to be executed:

cp httpd-IMOD.conf /usr/local/apache2/conf/extra/
/usr/local/apache2/bin/apachectl start
sed -i 's/COMMIT/-A INPUT -p tcp -m tcp --dport 80 
  -j ACCEPT\n-A INPUT -p tcp -m
    tcp --dport 10050 -j ACCEPT\nCOMMIT/g' /etc/sysconfig/iptables
/etc/init.d/iptables restart

在 app-group 服务器上安装和启动应用程序并打开端口
这个动作命名为 start-app。详细信息(软件 tar 文件的名称、tar 文件的 URL 目标等等)因使用的 J2EE 应用程序而异。

Action-type: executable
Script to be executed:

/usr/bin/wget -O /opt/ APP .tar.gz 
http:// SOURCE .com/ APP .tar.gz
cd /opt
tar -xzvf  APP .tar.gz
ln  -s /opt/ APP  /usr/local/ APP 
export JAVA_HOME=/usr/local/java;
/usr/local/ APP /bin/startup.sh
sed -i 's/^.*FW_SERVICES_EXT_TCP=".*".*$/FW_SERVICES_EXT_TCP="8080 10050"/g'
 /etc/sysconfig/SuSEfirewall2
/etc/init.d/SuSEfirewall2_setup reload

安装 Java Development Kit
这个动作命名为 install-jdk

Action-type: executable
Script to be executed:

/usr/bin/wget -O /opt/jdk1.6.tar.gz 
 http:// SOURCE .com/jdk1.6.0_16.tar.gz
cd /opt/
tar -xzvf jdk1.6.tar.gz
ln  -s /opt/jdk1.6.0_16/ /usr/local/java

在修改负载平衡器配置文件之后重新启动
这个动作命名为 restart-apache

Action-type: executable
Script to be executed:
               
/usr/local/apache2/bin/apachectl stop
sleep 5
rm -rf /usr/local/apache2/conf/extra/httpd-IMOD.conf
cp httpd-IMOD.conf /usr/local/apache2/conf/extra/
/usr/local/apache2/bin/apachectl start

4. 标准事件的挂钩

这些挂钩主要处理启动事件。

lb-group 服务器的启动事件的启动后挂钩
它依次调用以下动作:

{install-apache->configure-apache-balancer->start-apache}

app-group 服务器的启动事件的启动后挂钩

{install-jdk}

app-tier 的启动事件的启动后挂钩

{start-app}

5. 定制的事件

需要用于以下用途的定制事件:

  • 扩展 app-group(app-group-scaleup清单 9)。
  • 恢复 app-group 中出故障的服务器(app-group-recovery清单 10)。
  • 收缩 app-group(app-group-scaledown)。

6. 定制事件的触发条件和参数

需要为每个定制事件定义触发条件和参数:

  • 要度量的指标(例如 CPU Utilization:User)。
  • 要度量指标的服务器组。
  • 触发条件:>、<、= 或 != 阈值。
  • 触发类型:聚合或非聚合。
  • 阈值 (N)。
  • 时间段 (T)。

示例:实现系统

完成设计阶段之后,就该把设计转换为实际的 n 层系统了。在 IMOD 中,可以使用不同的图形化向导实现转换;手工实现超出了本文的范围。

本文中的 设计阶段 给出了 start-app、install-apache、configure-apache-balancer 等动作。在 Kaavo IMOD 的实现阶段,只需把这些动作输入图形化向导即可。


结束语

无论怎么努力地简化它们,云环境总是需要管理复杂的应用程序,需要平衡各种工作负载。有效地管理云环境的关键是,能够及时、自动地重新配置基础设施。

以应用程序为中心的管理是动态自动重新配置的关键元素。它通过单一系统定义控制运行时服务所需的资源和参数,这提供了管理云系统性能的有效方法。

本文介绍了以应用程序为中心的管理,解释了它的好处。讨论了实现这种管理方式的三个步骤:

  1. 定义应用程序(包括定义系统结构、配置服务器组以及定义动作、标准事件的挂钩和定制事件)。
  2. 设置自动驾驶。
  3. 启动和部署系统。

您看到了在 IBM Cloud 中自动部署两层的 J2EE 应用程序的一些 XML 代码;这些代码说明了如何创建动作、把动作与事件关联起来和处理事件。这些代码示例源于开发和部署 Kaavo IMOD 的实际经验。

希望您在下一个项目中应用这些技术(或它们背后的概念),简化应用程序和服务在云计算中的部署和管理。

参考资料

学习

获得产品和技术

  • 可以下载 Apache Velocity,这个基于 Java 的模板引擎让 web 设计者可以引用用 Java 代码定义的方法。
  • 使用可以直接从 developerWorks 下载的 IBM 试用软件 构建您的下一个开发项目。

讨论

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


在您首次登录 developerWorks 时,会为您创建一份个人概要。您的个人概要中的信息(您的姓名、国家/地区,以及公司名称)是公开显示的,而且会随着您发布的任何内容一起显示,除非您选择隐藏您的公司名称。您可以随时更新您的 IBM 帐户。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=Cloud computing, Java technology
ArticleID=592103
ArticleTitle=实现以应用程序为中心的云计算管理
publish-date=11292010