IBM System z 中国实验室

适宜读者：一年及以上主机经验

背景知识：z/OS,SIMD基础知识

 

摘要： SIMD（单指令多数据）是最新的主机平台z13上推出的一个强大的新功能, 它可以极大的提高主机的计算能力，但是，任何功能都必须经过程序员编程来实现，本文将讲解如何编写运用SIMD指令的C/C++程序。

 

一、平台要求

硬件平台要求z13以及更新的主机，目前z13是最新的主机平台； z/OS版本要求 V2R1及以后的版本, 即将推出的V2R2版本以及以后的版本也将支持SIMD。

 

二、SIMD基本原理介绍

z13新增加了32个128位的向量寄存器(Vector Registers)和139条新指令，用以支持在一条指令中同时对多个数据进行操作。SIMD的工作原理见下图

实际上，32个向量寄存器中的前16个是基于原来的浮点寄存器（Float Point Registers）拓展而来的，由64位拓展为了128位。 下图很好的说明了向量寄存器和浮点寄存器的关系。

三、编译选项：

SIMD必须在下列编译选项同时满足时才能生效：

• ARCH(11) ：ARCH选项指定编译器要生成的机器码对应的硬件平台。ARCH(11)是编译器指定的z13对应的架构型号代码，是目前最新的，以后新的平台为了保证兼容性也会支持。
• FLOAT(AFP(NOVOLATILE)) ： 上面介绍了向量寄存器和浮点寄存器的关系。

要使用向量寄存器，那么需要对原来的浮点寄存器的使用做一定的限制，即：额外的浮点寄存器(Additional Floating Registers)的须为非易失性的（NOVOLATILE）。

 

* 额外的浮点寄存器 （AFP）指的是编号为1，3，5，7，8-15的浮点寄存器，是相对于原始的编号为0，2，4，6浮点寄存器而言的。实际上AFP(NOVOLATILE)也只能控制8-15号浮点寄存器。由于本文主要讲SIMD编程，所以原来的浮点寄存器就不展开讲了，有兴趣可以查看相关资料中对于浮点寄存器的说明，比如FLOAT编译选项。

需要注意的是，FLOAT编译选项的默认值是：

FLOAT(HEX, FOLD, NOMAF, NORRM, AFP(NOVOLATILE)) ，

所以若无特殊需求，可以不用手动指定此编译选项。

除非想用vector double 数据类型和编译器内建向量函数（Vector built-in functions），此时必须显式地指定FLOAT(IEEE)参数。

• VECTOR ：VECTOR|NOVECTOR这个编译选项是编译器为SIMD功能新追加的，默认值是NOVECTOR,要应用SIMD功能必须显式地指定为VECTOR。

 

了解了SIMD的平台要求和工作原理，以及知道了如何指定编译选项，我们就可以着手写SIMD程序了。写程序之前，我们需要了解SIMD相关的一些语法，也就是相关的数据类型和对应的指令。

 

四、向量数据类型（Vector Data Types）

向量数据类型是以vector为关键字加上普通的基本数据类型声明的，声明的语法如下：

Vector declaration syntax

 

  .-----------------------------. 

  V                             |

>>---+-------------------------+-+------------------------------>

    +-type_qualifier----------+    

    '-storage_class_specifier-'    

 

>--+-vector---+-+-+-bool-----+--+-char-----------+-+-----------><

  '-__vector-' | +-signed---+  +-short--+-----+-+   

               | '-unsigned-'  |        '-int-' | |  

               |               +-int------------+ | 

               |               '-long long------' | 

               '-double---------------------------' 

每一个向量数据类型都占满128位（可以直接加载到一个向量寄存器中）。基于的基本数据类型的不同，能放的基本数据的数量也是不一样的。 比如signed char型本身占用8位，所以一个char型的向量可以放16个char型数据。

其实在编程时，很多情况下，可以把向量类型理解为一个一维数组，比如vector signed char型可以理解为一个包含16个无符号char型数据的数组。不过这个“数组”真正处理的时候可以通过一个地址把所有值一次加载到一个向量寄存器中，并且通过一个指令进行运算，而不用像真正的数组一样必须在内存中通过不同的地址找到各个元素，然后分别加载到不同的寄存器中，每条指令只能处理其中的一个或几个元素。这正是SIMD改善性能的地方。作为一个编程人员，可以不用关心处理器是怎么加载、处理这些数据的，只需要知道什么情况下需要使用SIMD数据类型并且知道怎么使用就够了。

五、原有语法拓展

一些基本的C/C++语法进行了拓展以支持新的向量数据类型, 例如：

• 向量字面量(vector literals)。 向量字面量是一个可以被转化为向量数据的常量表达式。这个说法比较拗口，其实看了例子就很容易理解。 例如：

            (vector unsigned int)(10)   - 四个元素全部为数值10

     (vector unsigned int)(1, 2, 3, 4) - 四个元素依次为1, 2, 3, 4

• 初始化。向量数据类型几种赋值方法，例如要给 vector unsigned int v1 的四个元素分别初始化为(1,2,3,4)，可以采用如下几种方法：
  • 通过向量字面量(vector literals)初始化：

vector unsigned int v1 = (vector unsigned int)(1,2,3,4);

• 通过初始化队列(initializer list)初始化(和数组的初始化方法类似):

vector unsigned int v1 = {1,2,3,4};

• 通过另一个向量初始化:

vector unsigned int v2 = {1,2,3,4};

vector unsigned int v1 = v2;

• 把向量类型定义为新的数据类型的支持。例如：

typedef vector unsigned short vushort4  - 定义 vector unsigned short型为vushort4。

• 一元操作符的支持。 例如:

vector unsigned int vni = {1,2,3,4};

vni++;

则此时vni的值为{2,3,4,5}

• 二元操作符的支持。例如:

vector unsigned int vni = {1,2,3,4};

vector unsigned int vni2 = {1,2,3,4};

vector unsigned int vni3 =  vni +  vni2;

此时vni3的值为 2，4，6，8

 

• 输入输入的支持。 例如

vector unsigned int vni = {1,2,3,4};

printf("the value of vector int is : %vlu\n", vni);

输出结果： the value of vector int is : 1 2 3 4

• 此外还有很多拓展支持，篇幅有限就不用一一展开说明了，具体参见z/OS XL C/C++ Programming Guide，

 

六、编译器内建向量函数（Vector built-in functions）

C/C++编译器提供了大量内建的向量函数供用户使用，具体详见z/OS XL C/C++ Programming Guide>Coding: Advanced Topics>Using vector programming support>Vector built-in functions。本文不会对每个函数展开说明，只是简单说明一下内建向量函数的基本语法并举个简单的例子。 

 

内建向量函数的基本语法：d = builtin_name(a, b, c)

其中：

builtin_name 为具体的函数名

d为返回值

a, b 和 c 为参数。

例如：

vector unsigned int vni  = {1,2,3,4};

vector unsigned int vni2 = {2,2,3,4};

vector bool int iResult = vec_cmpeq(vni, vni2);

 

           iResult值为{0,ffffffff,ffffffff,ffffffff}

 

 

七、代码示例:

 

helloSIMD.c代码：

 

#include <stdio.h>

#include <builtins.h>

 

int main(){

        vector signed int vni  = {1,2,3,4};

        vector signed int vni2  = {1,1,1,1};

        vector signed int vni3  = {2,2,3,4};

        vector signed int iAdd;

 

        vector bool int iResult = vec_cmpeq(vni, vni2);

 

        iAdd = vni + vni2;

 

        iResult = vec_cmpeq(iAdd, vni3);

 

        printf("the result value of iAdd is : %vld !\n", iAdd);

        

        printf("the result value of compare is : %vlx !\n", iResult);

 

        return iResult[1];

 

}

 

编译命令：

xlc -o helloSIMD -Wc,'VECTOR,ARCH(11),FLOAT(IEEE)' helloSIMD.c

 

运行结果：

the result value of iAdd is : 2 3 4 5 !

the result value of compare is : ffffffff 0 0 0 !

 

返回值为0

 

五、参考资料

 

SIMD 101 on the IBM z13 Mainframe：http://www.ibmsystemsmag.com/mainframe/tipstechniques/systemsmanagement/SIMD-101/

z/OS XL C/C++ Programming Guide>Coding: Advanced Topics>Using vector programming support：

http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.cbcpx01/vectorsupport.htm?lang=en

z/OS XL C/C++>z/OS XL C/C++ User's Guide>Compiler options:

http://www-01.ibm.com/support/knowledgecenter/SSLTBW_2.1.0/com.ibm.zos.v2r1.cbcux01/comopth.htm?lang=en

 

作者：宋文龙

邮箱：wenlsongATcn.ibm.com

 

内容声明：本文仅代表作者的个人观点，与IBM立场、策略和观点无关。文中专业名词因翻译原因，表述中难免存在差异。如有疑惑，请以英文为准。同时数据来源于实验室环境，仅供参考。如果您对我们的话题感兴趣，请通过电子邮箱联系我们。

适宜读者：（三年以上z/OS LDAP用户）

背景知识：（z/OS基础知识，z/OS LDAP基础知识,z/OS sysplex基础及配置知识）

 

一，概述

在任何分布式环境中，为了提供普遍的访问，都需要一致的身份验证和授权服务。大量这种部署使用目录服务器提供集中的安全管理。

把身份验证和密码服务集中在一起不仅会提高安全性，还会减少相关联的管理成本。对于这个问题，一种出色的解决方案是让一个服务器处理环境中的所有请求。但是，这需要使用高可用的服务器。在任何用户身份验证解决方案中都希望实现高可用性，因为如果身份验证服务器关闭，就可能造成整个企业停止运作。

对此，TDS for z/OS提供了两种部署方式来保证高可用性： sysplex和replicaiton。鉴于篇幅原因，下面分别对这两种部署方式仅作概要性及总结性介绍，具体细节请参考相关文档。

二，sysplex

在一个sysplex group里面有N个LDAP server实例在一起协同工作作为一个整体向用户提供资源。在用户看来，他们不会意识到sysplex底层的节点的存在，在他们看来，sysplex是一个系统，而非多个LDAP server实例。这N个TDS server实例往往运行在N个LPAR上，但是共享的是同一份物理数据。

只有一份物理数据意味着如果DASD或者USS文件系统被损坏，系统会完全宕机。然而对LPAR的宕机是可以容忍的，在这种情况下用户的请求将会转发到另外一个仍在工作的LPAR上。

在sysplex group里面，有两种角色：sysplex owner 和sysplex non-owner. 其中sysplex owner负责USS文件系统的更新和DB2的更新。而non-owner需要与owner沟通才能完成对请求的处理。

下面介绍怎么配置TDS for z/OS使其运行在sysplex环境中？

1， 保证sysplex中每个LDAP server实例使用的config file里面的配置是相同的，建议每个LDAP server实例使用同一个config file。

2， 在config file的全局区域添加如下配置选项：

serverSysplexGroup group_name

其中group_name 指定了XCF group 名称. 在这个XCF group里面的所有的LDAP server实例必须共享同样的schema而且backend database也必须是这个XCF group的成员。当这个配置选项设定完成之后，意味着TDS for z/OS sysplex 已经开启了。

3， 如果你计划要在sysplex group共享某个LDBM 、TDBM、CDBM或者GDBM backend，请在config file里面对应的backend区域设定如下配置选项：

multiserver on

请注意，在SDBM backend里面，multiserver这个配置选项是不被支持的。

三，replication

在replication部署里面，有N个LDAP server的实例单独工作，他们会运行在N个LPAR上面，有时候甚至是在开放平台上面，并且有N份独立的物理数据。

如果要部署replication, CDBM是必须要配置的。

在replication里面，TDS for z/OS支持四种拓扑结构：Master-Replica, Peer-Peer,Cascading和Gateway。下面对其分别介绍。

3.1 Master – Replica

在这种拓扑逻辑下，客户端只允许在master上进行数据的更新，replica是只读的，master在接收到客户端的更新之后，将此更新复制到replica上。

3.2 Peer-peer

在这种拓扑逻辑下，客户端可以在任何一个peer上进行数据的更新。peer在接收到客户端的更新之后，会将此更新复制到其他所有的peer上去。

在peer-peer拓扑逻辑中，如果LDAP里面的某一个或某些条目同时在两个peer上被更新了，那么则存在两边数据不一致的潜在风险。对此，TDS for z/OS提供了处理数据冲突的解决方案。

3.3 Cascading

在此拓扑逻辑中，LDAP server分为三个角色：master、forwarder和 replica. 客户端只允许在master上进行数据的更新。 master在接收到客户端的更新之后 ，将此更新复制到forwarder上,然后forwarder再将此更新复制到其他所有的replica上。

3.4 Gateway

当两个或多个拓扑网络需要互相保持数据的同步的时候，可以采用此gateway 这种拓扑结构。gateway既可以接收到来自客户端的更新，也接收来自其他的gateway的更新。gateway接收到更新之后，将其复制到本地网络当中的其他LDAP server。

四，总结

Sysplex和replication的各自优缺点总结如下：

	sysplex	replication
优点	1，不存在sysplex中各个LDAP server实例数据不一致的风险； 2，使其支持sysplex 需要做的配置相对简单； 3，在已配置好的sysplex group里面加入新的实例，所须做的操作相对简单。	1，避免了单点失效的风险； 2，能够与开放平台上的LDAP server一起协同工作； 3，部署操作系统使其支持replication所须做的配置相对简单。
缺点	1，如果DASD被损坏，会引起单点失效的问题； 2，不能与开放平台上的LDAP server协同工作； 3，部署操作系统使其支持sysplex所须做的配置相对复杂。	1，使其支持replication需要做的配置相对复杂； 2，在各个实例之间存在数据不一致的风险，需手动同步； 3，在replication拓扑配置好之后，加入新的实例 所须做的操作相对复杂。

请注意，sysplex和replication并不是互斥的。用户可以结合自身的业务需求在TDS for z/OS上面既部署sysplex，也部署replication。这样能利用sysplex 和replication各自的优势，既能避免物理磁盘被破坏之后单点失效的问题，也能与开放平台上LDAP server协同工作，还能消除各个实例数据不一致的风险。

参考资料：

IBM Redbook: IBM Tivoli Directory Server Administration and Use for z/OS

关于作者：

汤勇是IBM CSTL的一名软件工程师，他是z/OS LDAP Development团队的成员，从事主机LDAP的开发工作。

邮箱：tangybj#cn.ibm.com(替换#为@)

内容声明：文中专业名词因翻译原因，表述中难免存在差异。如有疑惑，请以英文为准。如果您对我们的话题感兴趣或者有疑问或批评指正之处，请通过电子邮箱联系我们。

适宜读者：（z/OS 系统管理员）

背景：

当今社会，经济蓬勃发展给很多金融公司的数据中心带来越来越大的挑战。随着交易量的不断攀升，生产系统所产生的日志也越来越多。为了保证系统的正常运行，很多数据中心都会实时监控系统产生的消息，希望能够及时发现系统中存在的潜在问题。然而，随着交易数量的不断增加，大量产生的消息，让人应接不暇，监控系统也变得越来越困难。另外，对于一个庞大的系统，一旦问题出现，想从浩如烟海的日志消息中去定位这个问题是一件异常困难的事。对于一些大型的银行系统，一天所产生的日志多达十几个G。 要在这样日志中去寻找问题出现的根源，无疑给很多的数据中心带来重大挑战。因此，数据中心急需一种能够方便监控系统和定位的问题的工具。zAware 就是在这样的需求下，应运而生的。

zAware作为IBM System z产品家族中的新成员，跟其它产品相比，有显著的不同。它不仅跟它的兄弟姐妹一样，有着强大的功能，更有光鲜的外表，它的GUI设计非常友好。不论是有几十年系统管理经验的大拿，还是初出茅庐的菜鸟，都能够很好的使用zAware监控系统，发现问题。下面，就让我们来揭开zAware的神秘面纱。

 

zAware的功能:

简单的说，zAware所做的工作就是把枯燥的系统日志进行总结包装之后呈现给系统管理员。系统管理员在监控系统和定位问题的时候，真正关心的其实不是某个消息的细枝末节，

而是这条消息是否代表系统出现了问题。就比如说下面这条消息。

 

M 4000000 Z2       2015153 15:56:49.67      00000090  BPXF221I FILE SYSTEM OMVSSPT.SYSPLEX.ROOT2.ZFS 630  

D                                           630 00000090  FAILED TO MOUNT LOCALLY.                            

D                                           630 00000090  RETURN CODE = 00000081, REASON CODE = EF1869CD      

D                                           630 00000090  THE FILE SYSTEM IS ACCESSIBLE ON THIS SYSTEM THROUGH

E                                           630 00000090  A MOUNT ON A REMOTE SYSTEM.                         

图1

它的内容比较长，它就这么在console上或历史数据里一闪而过，您能一下子知道它的含义吗？不太可能。同时也不需要。因为您需要了解的只是，它是否代表系统运行正常。对于这个问题，我们聪明的console已经进化出了使用不同的颜色来高亮不同的消息的功能。人的眼睛对不同颜色的消息最敏感，就像这样：

图2

这样的设计能让管理员在查看系统日志的时候，格外关注一下这些不同颜色的消

息。但是因为这些高亮的消息只是系统日志中的一个时间点，而且像这样的不同颜色的消息还是有点儿多，靠它们来监控系统或定位问题还是不够。

 

如果能把系统日志进行分段，对于不同时段的系统日志进行评估（正常或不正常），然后用不同的颜色进行表示，那是不是就能让管理员在分析系统日志的时候一目了然，直接定位到系统中有问题的部分呢？如下图所示，如果能对系统日志的不同时间段进行总结评价，那么系统管理员就可以只关注问题严重的的区域，大大提高效率。而这，正是zAware最显著的特点。

图3

 

下图是zAware对两个系统J80，J90的系统日志进行总结展示的示意图。我们把zAware监控的系统称之为Client.  J80，J90都是Client

 

图4

其中的每一个小的立柱代表系统在这5分钟之内的状态。可以看出立柱有不同的颜色和高度。颜色代表zAware对这5分钟的系统日志给出的分数，分值越高，颜色越深，问题就越严重。高度代表在这5分钟内，系统消息的种类，种类越多，高度越高。通过看图，我们就能够很容易的定位，系统在哪一个时间出了问题。

 

那么，zAware是如何对日志进行打分的呢？首先，zAware需要对系统进行建模，我们把这个建模的过程叫做Training。一般来说，zAware需要90天的系统数据才能够完成Training因此，在zAware真正开始监控系统之前，需要90天的时间。如果不想等90天，也可以使用系统的历史数据对zAware进行Training，我们把这个使用历史数据对zAware进行Training的过程叫做 Bulk Load。 当然这个90天的Training时间可以重新配置，但是为了保证zAware所建立的模型能够正确的反应系统的运行状态，IBM建议时间不宜太短。另外， zAware应该用来监控能产生稳定而有规律的消息的系统，如果一个系统的不够稳定，那么模型有可能会建立失败，即使建模成功，这个模型也未必能正确反映系统状态。

 

zAware的内部架构

 

如下图所示，zAware需要使用一个单独的LPAR，这就意味着，zAware 的正常工作不受z/OS系统的影响。zAware不仅可以监控同一主机上的z/OS也可以监控位于其他主机上的z/OS. zAware 把接受到的系统日志，建立的模型以及分析结果存储到磁盘上，用户可以通过浏览器访问zAware的分析结果。

 

图5

zAware的使用要求

要使用zAware，需要满足以下要求：

首先，zAware必须运行在EC12，z13上，无法在早期的主机上运行

第二，zAware目前可以监控的操作系统是z/OS(z13中开始支持Linux)。对于z/OS来说，它的版本必须是V1R13以及之后的版本，之前的版本不被支持。

第三，zAware的正常工作需要使用一定数量的CP或IFL，内存，以及磁盘DASD。具体数值，受其所监控的系统（Client）数量，以及message产生速度的影响

第四，要查看zAware的分析结果（柱状图），需要使用Firefox 和IE浏览器。

 

对于Client，为了能够使得他们把message发一份给zAware，需要在Parmlib 中的 IXGCNFxx 指定zAware的地址，如下所示，参数具体含义以及其他参数，请具体查阅手册。

 

ZAI  SERVER(XXX.XXX.XXX.XXX) PORT(XXX)

LOGBUFFULL(XXX)                     

图6
举例

在讲解具体事例之前，具体讲解一下zAware的Analysis选项所展示的各个部分的含义。如下图所示：每个小立柱代表系统某5分钟的状态，其中颜色是这5分钟的异常得分，系统越健康颜色越淡，问题越严重颜色越深，从浅蓝一直到深蓝，再到黄色和橙色。橙色代表问题的严重程度最大。

 

图7

 

当我们定位到某一个小立柱的时候，可以展示系统在这5分钟内更详细的信息，诸如一些对message出现次数的统计。如下所示。从这个图中能够看出某个message在这5分钟之内的出现位置，message ID，以及message的具体解释。

 

图8

 

下面让我们来看一个例子。如下图所示，zAware给出了一个sysplex环境下各个系统的柱状图。

图9

 

我们可以看出，第一个系统CB88在大约2:30的时候开始出问题。双击第一次出现问题的小立柱，如下图所示，可以看出两个message IRRC131I 和IRRC144I 在这段时间内出现了接近1000次。具体分析发现是LDAP出了问题。这样就找出了问题出现的根源

 

 

图10

 

以上就是本人对zAware的一个简单介绍，如果需要了解详细信息，请参阅zAware Guide

 

参考资料：

 

作者：夏润钊

邮箱：xiarzATcn.ibm.com(替换AT为@)

 

内容声明：本文仅代表作者的个人观点，与IBM立场、策略和观点无关。文中专业名词因翻译原因，表述中难免存在差异。如有疑惑，请以英文为准。同时数据来源于实验室环境，仅供参考。如果您对我们的话题感兴趣，请通过电子邮箱联系我们。

适宜读者： z/OSMF Software Management用户

背景知识： SMP/E基本知识

软件管理(Software Management)是z/OSMF的一个重要组件，通过使用Software Management可以高效的管理z /OS上的软件，本文将介绍Software Management的主要功能。软件管理的主界面如下图1-1所示，包括 Software Instance, Products, Deployments, Categories和Settings这几个链接，用户可以通过点击这些链接进入相应的功能页面。

图1-1

     z/OSMF 软件管理的主要功能和界面如下：

• 创建一个软件实例(Software Instance)，通过创建一个或多个Software Instance来管理已安装在z/OS上的软件。这些软件产品可以是通过Server Pac安装的IBM软件、z/OS系统子模块或者z/OS操作系统和一些系统有关的产品。如图1-2所示为一个已创建好的Software Instance实例。

          图1-2

• 查看软件实例里所包含的Product, Feature, FMID和Data Sets信息列表。
• 查看所安装软件的详细信息：

1：如查看包含在软件实例里所有的产品，选中一个Software Instance进行查看，其中所包含的产品(products)如图1-3所示：

图1-3

2：查看产品的EOS(End of Service)信息，通过EOS信息，可以查看产品服务时间信息，如图1-4所示显示的z/OS和Compiler for REXX2.1这两个products的EOS信息。

图1-4

• 生成软件的报告信息，通过查看生成的报告信息，可以查看是否有一些没有解决的PE PTFs, HIPERs 或者被ERROR HOLDDATA定位的一些SYSMODs的异常，查找软件实例里是否包含一些指定的SYSMODs。如图1-5展示的是一个软件实例”Software_Instance_1”所包含产品的有关信息。

图1-5

• 部署一个已安装的软件到本地(local)或者远程(remote)系统，通过部署一个软件实例，可以部署这个软件实例里所包含的软件产品，通过Deployment Checklist 如图1-6来一步步完成，在第一步到到第六步配置完成后，会生成一些JCL JOB,用户可以在CheckList中第七步来提交JOB，最终来执行前面所做的配置。

图1-6

在执行完JCL Job后，通过最后第八步来指定所部属到Target系统的软件实例有关属性，最终完成一个Software Instance的部署。

本文主要概括的介绍了z/OSMF中的一个重要模块功能Software Management 主要的功能，可以读者快速的了解Software Management，有一个整体上的认识，本文中所展示数据为模拟数据。目前还不能通过 Software Management安装软件，如果要安装软件到z/OS系统上，需要借助SMP/E来完成。

参考资料：

IBM z/OS Management Facility V2R1

IBM SMP/E for z/OS: Reference

作者：赵红亮

邮箱：zhaohlbjATcn.ibm.com(替换AT为@)

内容声明：文中专业名词因翻译原因，表述中难免存在差异。如有疑惑，请以英文为准。同时数据来源于实验室环境，仅供参考。如果您对我们的话题感兴趣，请通过电子邮箱联系我们

z/OSMF Workflow 概述

适宜读者：（无需主机经验）

         z/OSMF 的面世除了给用户提供各种传统z/OS的功能的图形化界面之外，还带来了一个全新的z/OS所不具有的强大灵活功能----Workflow。工作流技术起源于二十世纪七十年代中期办公自动化领域的研究，由于当时计算机尚未普及，网络技术水平还很低以及理论基础匮乏，这项新技术并未取得成功。简单地说，工作流就是一系列相互衔接、自动进行的业务活动或任务。一个工作流包括一组任务(或活动)及它们的相互顺序关系，还包括流程及任务(或活动)的启动和终止条件，以及对每个任务(或活动)的描述。Workflow是z/OSMF的自带功能，只要成功安装了z/OSMF，就可以直接使用Workflow。

z/OSMF提供的Workflow是给z平台提供了即满足传统工作流定义，又满足z平台特殊需求的一个工作流平台。用户可以把需要在z上进行的任何活动或任务，定义成若干步骤，每一个步骤可以是一个具体的子任务，也可以是一个子任务组，甚至可以是一个关联到外部活动或任务的调用 任务(calling step)。具体的子任务可以是简单的描述该步骤需要执行的操作，让用户手动去执行某些操作，或者给用户提供一个可以执行的脚本，用户可以进行个性化后提交到JES系统去完成该子任务。子任务组是指一些具体的子任务集，这些子任务集是树状结构，最大层级数可以达到5层，只有叶子节点可以执行，每个叶子节点就代表一个具体的子任务。由于父节点只是起到一种分级的作用，不是一个具体的子任务，所以父节点的状态受所有子节点的影响。关联到外部活动或任务的调用任务是一种特殊的步骤，该步骤不具有可执行性，只是简单的关联到一个别的工作流，但是该步骤和被关联的工作流之间可以进行数据共享。

     Workflow平台支持通过XML的方式来定义一个工作流，每个工作流的定义都必须满足Workflow的Schema规范。Workflow的Schema规范定义了一个工作流文件里可以出现的所有标签和属性，及这些标签和属性间的顺序和制约关系。每个定义文件大致包含三部分内容，工作流概要信息，变量定义和步骤定义。工作流概要信息包括工作流的一个总体描述，产品信息，类别，提供该定义的供应商等。变量定义部分，目前我们支持如下六种类型的变量：字符串、整型、布尔、时间、日期、小数，Vendor可以根据不同的数据类型存储需求选择不同的变量类型。变量在工作流里的主要功能是进行数据存储共享，同时也可以作为一个工作流的输入或者输出。最后的变量定义就是某一项具体的工作流可以分解的所有步骤的集合，所有步骤在定义文件里的排列顺序将直接决定这些步骤在UI上的排列顺序。Workflow 平台支持给步骤间设定一些依赖关系或者条件关系，依赖关系是指后续的step可以指定依赖于之前的某个或某些步骤，当所有依赖步骤都完成了才会允许该步骤进入可执行状态。而条件关系则更细粒度的控制各子任务（步骤）间的依赖关系，比如后续step可以指定之前的某些步骤的状态、JOB执行返回结果或者变量值在符合具体的需求时，才允许该步骤进入可执行状态。

    每一个定义好的工作流文件都可以在Workflow平台上创建实例，实例建好之后用户就可以手动或者自动化的去执行该实例。创建过程中，用户可以指定一个属性文件，作为该实例的输入，同时各步骤也可以输出变量信息，供后续的步骤或实例使用。由于每个实例文件包含的各步骤可能需要多人协作完成，所以Workflow提供了分配任务的功能，同时可以选择给被分配的人发送通知告知需要去哪个实例执行哪些步骤。对于一些用户觉得不需要执行或者已经执行过的步骤，可以直接把该步骤标成跳过或者已完成状态。

历经3年多，经过所有同事的共同努力，Workflow已经由最初的一个基础工作流平台发展到现在集各种功能与一身、炙手可热的工作流平台。我们也在将继续致力于把该平台做的更稳定，功能更强大，更合理，更易用。

作者：刘叶香

邮箱：liuyexbjATcn.ibm.com(替换AT为@)

内容声明：文中专业名词因翻译原因，表述中难免存在差异。如有疑惑，请以英文为准。同时数据来源于实验室环境，仅供参考。如果您对我们的话题感兴趣，请通过电子邮箱联系我们。

原 文：Hot Topics – August 2014, Issue 28

作  者：Mike Young

译  者：向前

适宜读者：一年及以上主机经验

背景知识：z/OS,z/OSMF

 

正文：

　　z/OSMF在2009年首次发布时，为z/OS的多个功能提供了web界面。经过了五年的发展，这个z/OS的新面孔现在已经增加了很多新特性，其中更是包含了目前炙手可热的云端编程接口。在此过程中，z/OSMF的运行平台也从WebSphere Application Server的OEM版换成经过定制的更轻量的WebSphere Liberty Profile服务器。

数年来，z/OSMF一直致力于为z/OS提供对外接口，使用该接口不需要了解WebSphere的相关知识，却能使z/OS的新用户更容易地管理z/OS系统。既然现在管理z/OS系统变得更容易和简单了，那么新问题就来了：该怎样管理z/OSMF本身呢？

 

配置z/OSMF时存在的问题

　　安装z/OSMF时面临的第一个挑战就是如何确保所有必要的配置步骤都被执行了。虽然自z/OSMF的首次发布开始，其配置过程的复杂性就被大大的缩减了，但是仍然有一些极富技巧的地方需要小心对待。幸运的是，z/OSMF提供了一些很有用的工具来帮助我们完成这些任务。

 

验证z/OS和z/OSMF的安装

　　脚本izusetup.sh提供了独立的程序来扫描你的z/OS系统并验证那些重要的前提条件是否都满足。使用你的z/OSMF配置文件，你可以像下面这样执行izusetup.sh脚本：

izusetup.sh -file izuconfig1.cfg -verify all

izusetup.sh脚本会在你的日志目录（缺省为/var/zosmf/configuration/logs/）下生成日志和报告。通过查看这些日志和报告可以判断你的系统中是否存在配置问题。在你需要联系IBM的支持人员时，这些文件也是很有用的。

 

验证浏览器的配置

　　如果z/OSMF的服务器端看起来是工作正常的，但是外部接口却显示有错误，这可能是你的浏览器有问题。z/OSMF为诊断这类跟浏览器有关的问题提供了一个环境检查程序。要使用这个程序，你可以在浏览器中访问地址https://hostname:port/zosmf/IzuUICommon/environment.jsp，然后检查其中显示的结果。

 

　　尽管IBM竭尽所能地让z/OSMF能够广泛的支持现代浏览器，但是偶尔在一些特定配置或版本的浏览器上会有问题。浏览z/OSMF中的“浏览器和操作系统”页面可以查看IBM推荐的浏览器和操作系统：

ibm.com/systems/z/os/zos/features/zosmf/browser_notes.html

 

运行中的问题

　　每一个系统程序员都喜欢为最坏情况做准备。幸运的是，z/OSMF一直在努力超越System z在可靠性（reliability）、可用性(availability)和可服务性(serviceability)(即RAS)上的要求。即使z/OSMF不像传统的z/OS组件那样工作，它也提供了多个强大的诊断和纠错功能来帮助你进行管理和服务。

 

z/OSMF日志

　　z/OSMF的日志子系统在系统出错时会记录下重要的详细信息。就像飞机上的飞行记录仪，z/OSMF在内存中有一块数据缓冲区，用来记录接收到的请求和在服务器上执行的操作。不管是来自浏览器的客户端数据还是服务器端数据，都存储在这块缓冲区中。如果系统中有严重的警告或错误发生，系统就会把这块缓冲区中的数据写到磁盘中，以便系统操作员和IBM的支持人员能够诊断出问题发生的原因。如果出现了致命的问题，比如系统崩溃，IBM的服务人员可以从SVCDUMP中提取缓冲区的内容。

 

发送数据给IBM的支持人员

　　如果你确实需要联系IBM的支持人员，他们首先向你要的两样东西就是在本文中讲过的详细配置信息和日志。对你而言，把这些数据打包发给IBM也很简单快捷。只需要执行下面的z/OS UNIX命令就能生成两个打包文件：

pax -wz -x pax -vf config.pax.Z /etc/zosmf

pax -wx -x pax -vf logs.pax.Z /var/zosmf

 

这样生成的pax.Z文件是压缩过的，因此可以直接通过FTP以二进制的形式发送给IBM。（没必要再TERSE了。）

 

　　现在你应该明白为什么本文配有一幅赛车维修人员的图片了吧，因为为z/OSMF提供服务就像为进站的赛车换轮胎一样快速简单。

 

原文配图：

 

 

 

参考资料：

 

译者：向前

邮箱：xiangqbjATcn.ibm.com

 

内容声明：本文仅代表作者的个人观点，与IBM立场、策略和观点无关。文中专业名词因翻译原因，表述中难免存在差异。如有疑惑，请以英文为准。同时数据来源于实验室环境，仅供参考。如果您对我们的话题感兴趣，请通过电子邮箱联系我们。

类型：翻译

原文： http://publibfp.dhe.ibm.com/epubs/pdf/e0z3n101.pdf

作者： Mike Young

译者： 魏群

 

适宜读者：（一年及以上主机经验）

 

当z/OS管理工具（z/OSMF)第一次发布时，作为z/OS的新面孔，承诺提供大量z/OS任务的图形化用户界面。今天，许多系统程序员使用z/OSMF上的强大的功能，比如通信服务器配置助手（Communication Server Configuration Assistant），z/OS软件管理（Software Management)，负载管理（Workload Management）以及新的SDSF用户界面。但是，你知道吗，z/OSMF提供的远不止是那些华丽的网站界面。在幕后，它也为开发人员和平台之后的应用提供了首个z/OS 云 REST 服务。

 

REST代表“表述性状态转移（Representational State Transfer）"，是一种强调网络技术如HTTP的架构。REST接口使用日常的网络URL以及标准的HTTP方法和链接获取和放置数据。通过正常的HTTP传输，网络流量可以更容易通过代理，防火墙和负载平衡器中转。通过REST接口，一个应用可以快速方便的被写入，无需担心专用库或平台的底层实现细节，或涉及到的编程语言。

 

z/OSMF REST 服务

 

在z/OSMF 2.1版本，IBM主要提供了三种REST服务。这些服务可以被主机上的和主机之外的应用开发人员使用，因为他们都是可以通过和z/OSMF相同的URL进行访问。另外，因为z/OSMF使用HTTPS/TLS，所有的REST服务自动提供安全的通信方式。一些IBM产品已经在使用REST接口，来代替过去使用的传统通信方式。今天z/OSMF提供的三种主要服务是：

• 作业接口
• 数据集和文件接口
• TSO/E地址空间服务

 

这篇文章将要描述每一个服务以及他们提供了什么给应用程序开发人员。对于更多关于如何使用这些服务的细节，请查询IBM z/OS 管理工具编程指南SA32-1066。在后面的例子中，用安装了z/OSMF的系统名称（必要时包括端口）代替”your-zosmf-hostname”

 

z/OSMF 作业接口（也叫SubmitAPI)

 

z/OSMF REST 作业API是z/OSMF最早提供的接口。它允许用户提交和管理批量作业和输出。在过去这种操作或者在终端进行，或者使用专用库或应用。许多客户今天使用FTP或其他非安全通讯方式提交批量作业及传输执行结果。

 

通过z/OSMF 作业API，所有的通讯都是安全的，使用标准HTTP请求，所以与已存在的应用整合很简单。你甚至可以自己用网络浏览器试试 ！试着在浏览器里输入下面URL：https//your-zosmf-hostname/zosmf/restjobs/jobs。身份验证后，应该看见你用户id下的作业（如果有的话）。如果你想看一个不同用户的作业（你被授权去这样做）你可以在最后增加查询选项 ?owner=userid。

 

看到作业列表几乎只是触及REST作业API功能的表面。也许你愿意看见某个你发现的作业的输出结果。只要从列表提取作业名jobname和作业编号jobid，这样输入浏览器：https://your-zosmf-hostname/zosmf/restjobs/jobs/jobname/jobid/files。这将返回你作业的输出文件列表以及生成的步骤信息。你甚至可以在浏览器中进一步检索输出内容。文件列表输出提供了一个特殊“越狱”链接，应用程序可以用来下载正确的后台数据。当手工输入时相关链接也依然工作很好。用列表中返回的作业文件编号替换“nn”：

https://your-zosmf-hostname/zosmf/restjobs/jobs/jobname/jobid/files/nn/records。

z/OSMF作业API也有能力去提交、取消和修改一个作业执行的类（class）。那些操作使用和你相同的URL，但是在请求里要求传递特别的HTTP方法和头（header）信息。对于一个不依赖平台或基于web的应用，很容易提交这些额外的header信息，因此允许开发人员和用户没有z系统的经验去提交和管理作业，不需要特别培训和特别的软件。

 

z/OSMF 数据集合文件接口

 

z/OSMF V2.1新的APAR PM98630是另一个REST API，设计允许你的应用访问数据集和z/OS UNIX 系统服务文件。在第一个版本， API提供两个基本功能：根据过滤条件列出z/OS 数据集；列出z/OS UNIX 目录。这个接口目前正在积极开发中，因此请继续关注允许你访问存储在z/OS的数据的新功能。

 

和作业接口一样，你可以在网络浏览器试试文件接口。输入下面链接去查看你High Level Qualifier下的数据集：

https://your-zosmf-hostname/zosmf/restfiles/ds?dslevel=hlq ，“hlq”是你想列出的数据集的起始限定符。

 

类似的，对于z/OS UNIX 文件，你可以使用URL：

https//your-zosmf-hostname/zosmf/restfiles/fs/u/username 来列出username主目录的内容。对查看这些数据集和文件列表的访问控制和TSO/E用户的访问控制是一样的。如果你的用户ID有z/OSMF访问权限和TSO/E上列出信息的权限，那么也就能够使用数据集和文件接口。

 

z/OSMF TSO/E地址空间服务

 

文章最后一个REST API可能会最令人兴奋。z/OSMF ISPF 或SDSF的用户可能熟悉z/OSMF在幕后创建一个TSO/E 会话以处理你的工作。这相同的功能对你的应用程序也有效了。和其他两个REST API不同，你不可能在你的网络浏览器体验这种功能，但是网络和远程应用可以使用这个API去启动TSO/E 会话，启动应用，然后发送/接受消息。

启动一个TSO/E 会话，然后发送数据是非常直接的任务。通过POST方法向URL:https://your-zosmf-hostname/zosmf/tsoApp/tso 传递一些如TSO/E过程名和你期望的虚拟屏幕尺寸的数据就可以启动一个会话。服务器将返回一个“servletKey”值，你可以用它进一步和TSO/E 会话通信。你可以通过向URL：https://your-zosmf-hostname/zosmf/tsoApp/tso/servletKey发送PUT和GET请求来向TSO会话发送和接收消息。

 

启动TSO/E地址空间内的应用和与之通信就有点复杂了。来往于应用程序的通信是通过z/OS UNIX IPC消息队列来处理的。z/OSMF服务器负责为你创建和管理消息队列，但是任何你启动的TSO/E 应用程序必须允许对队列的读写。关于这些队列如何工作可以查看IBM z/OS管理工具编程指南SA32-1066和z/OS MVS用于高级语言的编程调用服务SA23-1377。

 

希望这篇z/OSMF云服务的介绍已经激发了你的兴趣，去进一步了解这些可能对你有用的REST API。如果你有一个特定的服务或API，想增加进z/OSMF，请随时使用需求网站（RFE）提出你的请求，RFE地址如下：

ibm.com/developerworks/rfe/?BRAND_ID=352

 

 

译者：魏群

邮箱：weiqunATcn.ibm.com

 

内容声明：本文仅代表作者的个人观点，与IBM立场、策略和观点无关。文中专业名词因翻译原因，表述中难免存在差异。如有疑惑，请以英文为准。同时数据来源于实验室环境，仅供参考。如果您对我们的话题感兴趣，请通过电子邮箱联系我们。

 

原  文：http://www.ibmsystemsmag.com/mainframe/tipstechniques/applicationdevelopment/application-testing/

作  者：Jim Schesvold

译  者：向前

适宜读者：一年及以上主机经验

背景知识：软件开发、测试

 

正文：

　　我曾经做过咨询顾问，系统编程和应用编程等工作，觉得最困难和费时的工作莫过于软件测试了。对于某些特定的应用软件，测试可能比编码更加的费时费力。我见过的最好的软件测试方法一般包括下面几点：

1. 创建可执行程序和基本的代码验证

2. 对基本功能、错误和异常处理以及系统集成进行验证

3. 进一步深度的用户测试

　 　随着测试的进行，测试的复杂度和强度也大大的增加。我曾经见过许多测试被最大程度地压缩以便减小测试工作量，加快测试进程。然而，几乎所有这样的努力最 终都付出了代价。比起生产阶段，在测试阶段发现并修复软件缺陷所造成的负面影响要更小，代价也更低。在测试的初期解决问题也比在后期解决要有效得多，因为 其中涉及到的人员数量几乎总是随着测试的进行而不断增多的。尽管管理层可能会对程序员施加压力促使他们尽快完成开发，但是只有让人们按部就班地彻底做好每 一阶段的工作才是一种更加有效率的工作方式。

    下面是我见到过的最佳软件测试方法的框架。

测试系统

　　搭建一个有效灵活的测试环境的第一步，就是安装软硬件，装载数据和程序以及制定模拟生产环境的一系列过程和流程，尽管这个模拟的环境在一定程度上小于真实的生产环境。在测试环境中使用跟生产环境完全一样的CPU配置和磁盘空间常常是不现实的，但是在搭建测试环境时有一个需要考虑的关键点，就是测试环境应该能够重现生产环境中出现的任何问题。这可能需要对测试系统根据需要进行修改，比如将生产环境上的软件镜像换入换出，总的来说测试系统需要反映生产系统上的真实情况。

　 　有一类跟容量有关的问题，这类问题在测试系统中可能不容易出现，因为测试系统没有跟生产系统一样的计算能力或者无法达到跟生产系统一样的最大工作负载。 尽管这样，测试系统还是应该在可能的地方尽量模拟生产系统。我曾经使用过没有经过这样测试的系统，这种系统严重地限制了用户对它的使用。因为在测试系统中 没法发现的问题，在生产系统中很快就出现了。这些问题没有在测试系统中出现，是因为能触发这些问题的数据和配置信息在测试系统中并不存在。

　　测试系统应该满足跟生产系统相近的可用性和响应时间或性能目标，因为对于软件开发人员来说，测试系统就是生产系统。一个健壮可用的测试系统能够确保较高的生产效率，并捕获将来会影响生产系统可用性的错误。

软件测试工具

　　测试工具和代码分析工具极大地提高了程序员的生产效率和代码质量。我在以往的工作经历中主要使用COBOL语言，也粗浅地用过C#、Java、PL/I和汇编语言。像xPediter、Intertest、Veracode这类工具能大大增强程序员的调试能力，改善程序的流程。这些工具能够在屏幕或窗口中显示源代码和内存区域中的内容，也能逐条指令地执行程序，这样程序员就能监视指令的执行和数据的变化。它跟在代码中插入DISPLAY语句，然后重新编译，查看特定内存区域的输出值，然后再重复此过程这种方式相比，生产效率能得到极大的提高。

　　更好的是，调试工具可以动态地改变内存区域的内容（比如COBOL里 的工作存储区，链接区，文件区等等），这样就能够对一些空想出来的场景进行测试。这类工具经常被用来手工地改变指定域的值，而不是整个记录，所以我们仍然 需要包含有测试数据的文件，基于这些数据可以产生不同的输出、异常和错误等信息。而像跳过指令执行或者执行特定的分支语句这样的功能，则进一步加强了测试 手段。

　　虽然编译器的输出内容大多数是跟语法检查有关的，但是我们也不能对其中的警告和信息性消息掉以轻心，尽管它们经常因为不会导致编译失败而被忽略。通过它们，我们可以找到潜在的逻辑错误和对测试有用的信息。

第一阶段测试

　　第一阶段测试通常由写代码的程序员来执行，它包含了对语法错误的改正以及随后对基本逻辑的简单测试。从编译器产生的报告中可以定位到语法错误以及它们出现的代码行数。在创建可执行的程序和开始测试之前，必须改正这些错误。

　　就批处理任务而言，第一阶段测试可能包括创建和编辑JCL(Job Control Language), 执行这些JCL会分配文件、调用程序和基于条件码执行不同的任务等。就CICS事务服务器这样的在线程序而言，JCL是由软件提供的。这时我们会经常从生产环境中挑选文件，特别是大文件，来做一些初步的测试。虽然这样做使用的数据是静态的，但是没关系，因为在这个时点上程序员只验证程序的主线逻辑。

第二阶段测试

　 　第二阶段测试不仅涉及到相关的程序员，也需要深入了解业务流程知识的系统分析师和高级程序员的参与。这个阶段测试将更加的细致和深入，经常需要开发针对 特定业务流程的标准测试用例。这时会针对大量的错误条件进行测试，比如，程序是否能够恰当地处理文件或数据库已经关闭的情况？其他的情况呢？如果用户输入 了无效的电话号码，程序能检测到并正确处理吗？程序恰当地调用了有效值的范围检查算法了吗？程序检查并处理了记录里的垃圾数据了吗？

　 　在这个阶段，通过系统集成测试，我们可以将测试范围从新开发的模块或有改动的模块，扩展到所有相关的模块。大多数应用系统由数十个甚至上百个模块组成， 其中的许多模块会互相传递控制和数据，也会根据特定的模块生成和修改数据。有些模块发送屏幕内容，有些计算日期，还有些计算分期付款，等等。新模块能跟现 有的模块一起很好的工作吗？预先写好的脚本和分析师指南能够用于这种测试和验证。

回归测试与质量保证

　　虽然IT部门仍然负责解决发现的问题，但是质量保证测试主要由终端用户来完成，因为他们掌握了各种各样的业务知识和例外情况，知道哪些业务组件有问题以及会出现什么样的问题，也知道流程上的独特之处。从本质上说，质量保证用户利用他们掌握的关于应

用系统的知识尽可能地破坏系统以便达到测试目的。

　　回归测试并不常用。它经常需要执行自动化脚本来验证标准的测试用例。这是一种能找出普通问题和性能问题的自动化方法。

　　回归测试和质量保证会在另一篇文章中做进一步的讨论。

测试的重要性

　　尽量在测试系统中找出错误（好吧，会有一些错误被遗漏），这将会让用户高兴，让管理层高兴，也让业务人员高兴。而全面的测试会让用户拥有优质的工具来更好的完成工作。

 

译者：向前

邮箱：xiangqbjATcn.ibm.com

内容声明：本文仅代表作者的个人观点，与IBM立场、策略和观点无关。文中专业名词因翻译原因，表述中难免存在差异。如有疑惑，请以英文为准。同时数据来源于实验室环境，仅供参考。如果您对我们的话题感兴趣，请通过电子邮箱联系我们。

 

作者：Joseph Gulla

翻译：魏群

原文：http://ibmsystemsmag.com/Blogs/IT-Trendz/May-2015/Cloud-Management/

 

适合读者：（一年及以上主机经验）

 

这篇文章是关于IT系统管理的系列文章中的最后一篇。头三篇 是关于系统，网络和应用管理。这篇主要介绍在云管理以及它在公有云，私有云和混合云服务中如何扮演一个关键角色。

 

什么是云管理？

云管理是对运行在云环境的IT组件和服务的管理，这些IT组件和服务是运行在一个云环境里。被称为云，是因为它具有像一个高度虚拟化的环境，自助服务和基于使用的记账和扣费的一定的技术和业务特点。你可能认为一个云环境就是一个和提供水，天然气或者电力类似的公共服务。在20世纪90年代末到21世纪初的IT行业中非常流行效用计算（Utility Computing），而云计算就是效用计算的自然跟进。云计算是效用计算一个更引人注目的实例，因为支持云计算的虚拟化技术支持更加成熟。

对于不同种类的云，云管理也呈现不同。我们分别从公有云，私有云和混合云环境的角度来看看云计算。

 

公有云：管理在幕后

公有云服务提供商管理他们的公有云服务。基础设施，包括服务器，存储，网络和数据中心运营，是面向规范化，自助服务和自动化。为了满足这些运维特性，公有云提供商逐渐开发了特定的云软件，运用标准和软件，使得交互操作性成为可能。这些标准和软件也使得员工，服务供应商和服务用户的学习曲线扁平化。

 

私有云：管理是设计的一部分

管理一个私有云通常意味着你首先不得不自己建立它或者从一个信任的服务合作伙伴那里获得帮助。合作伙伴可以帮助你建立私有云，或者通过他们的硬件，软件，人力和智力资本替你实现。私有云要求软件产品帮助创建一个计算资源的虚拟化池；为终端用户提供自助服务设施。处理安全，资源分配和释放，以及跟踪和付费。从某种意义来说，它和公有云没什么不同，除了你选择组件去使用和利用一定程度的灵活性和自动化，促使服务在特定组织内成功。每个公司有一个独一无二的文化，在公司里，如果公司有引以为荣的灵活性，那么应用一个不灵活的私有云解决方案的话徒增厄运。

 

混合云：管理面临的挑战是整合环境

在混合云环境，你经常处理不同IT环境的加入。你可能有一个私有云环境，它需要使用资源，这些资源是私有云之外---被称为传统IT环境---的数据或应用。设想接口是有效的，那么管理呢？当问题发生，在什么问题管理系统跟踪问题？它是在私有云还是传统IT系统？你能想象链接新老系统的管理挑战吗？这些问题可以成功解决，但是不得不去理解和处理挑战。

 

内容声明：文中专业名词因翻译原因，表述中难免存在差异。如有疑惑，请以英文为准。同时数据来源于实验室环境，仅供参考。如果您对我们的话题感兴趣，请通过电子邮箱联系我们。