南沪艳阳谈U2L---我在金融行业座谈会上的分享

前言: 谈到U2L，顾名思义，就是UNIX to X86Linux。那么，我们为什么要做这件事呢？技术考量？成本考量？还是别的因素。本文将为您进行详细讲述。

谈到U2L，顾名思义，就是UNIX to X86Linux。那么，我们为什么要做这件事呢？与技术和成本的考量因素，其实信息安全其实是最重要的。前几年，爆发的斯诺登时间震惊全球，很多国家的政要首脑受到监控。由此凸显，信息安全与自主可控在我国各行各业的重要性，尤其是金融行业。近两年，银监会也颁布了和信息安全相关的规定。IT系统的安全是信息安全最重要的一环之一。IT系统尤其是核心IT系统实现信息安全的核心法宝就是：IT技术自主可控。

实际上很多大型商业银行的IT负责人，都已经意识到了，将核心业务系统从传统封闭的软硬件平台转化到开放架构是银行IT基础架构转型的必经之路。

除了外部因素，UNIX市场的变化，也值得我们关注。作为主要的UNIX服务器供货商。IBM和HP在小型机的收入逐年下滑。2014年，IBM发起openpower，也就是power的开源项目，在Power芯片上运行Linux操作系统。而惠普此前最高端的UNIX服务器superdome，近些年也出了X86版本。这也正充分印证了，开放才是出路。

应该说，在2000年左右，UNIX服务器在早期的高稳定性、软硬件兼容性好的优势相比于X86服务器还是很明显的。之所以能做到这些，是因为小型机软硬件是由一家公司提供的。而随着IT技术的发展，随着X86服务器稳定性大幅提升，Linux操作系统日益强大，时过境迁，之前小型机软硬件紧耦合的优势现在反而成为劣势。正如一个银行的客户的体会，由于UNIX服务器与业务系统紧耦合，一旦出现任何闪失，核心业务系统都可能受到影响。而且小型机由于是封闭的，它的运维成本非常高。我曾经了解到一个企业，他们一年UNIX服务器加高端存储的维护成本在2000万人民币。除此之外，由于软硬件的紧耦合，UNIX服务器上的业务系统很难做到弹性扩展，更难适应云时代的要求。因此说，U2L是必要的，也是大势所趋。

提起U2L，这其实是个统称，UNIX上的应用，可以迁移到安装Linux的物理机、安装Linux的虚拟机、甚至安装Linux的私有云、公有云环境。谈到这一点，红帽的优势就出来了，因为红帽的解决方案，贯穿Linux操作系统、虚拟化、SDS、IAAS、PAAS、中间件甚至ansible等部署工具。红帽是业内少有的，可以提供UNIX to anything的公司。

从短期看，UNIX下移的时候，红帽提供两条路，U2L和U2VL。U2L就将UNIX上的应用下移到安装inux的物理机上。而U2VL，则是将UNIX上的应用下移到X86虚拟机中，虚拟机中安装红帽linux操作系统。、

迁移到虚拟机还是X86物理机，各有各的好优劣势，物理机的性能和成本高于虚拟机，而虚拟机的可管理性高于物理机，下面我们将着重进行分析。

我们推荐UNIX下移选取的方式和步骤，第一个原则：是根据应用的特点进行选择。

在分析应用特点时，第一点从I/O角度来考虑，通常对于I/O密集型的应用，包括磁盘I/O和网络I/O，如果硬件设备都很难满足的情况下，再加一层虚拟化显然多少会造成性能的下降。这种情况下，建议做U2L。比如一些大型的核心交易数据库。而对于非I/O密集型的应用，使用虚拟化就比较合适。

第二点我们要考虑应用消耗资源的多少。比如一个应用需要的CPU，内存很高，几乎占用一台物理服务器一大半资源，那么一台物理服务器只虚拟一个虚拟机，显然也没这个必要性。而在国内金融行业客户生产环境的虚拟化里，通常一台四路服务器的整合比是1:7.

第三点，考虑相关应用压力是否可以错峰。例如，我们从UNIX服务器下移了两个关联性比较强的应用，如果他们的业务高峰在不同的时间出现，就可以考虑部署到虚拟机中。

总之，选择U2L和U2VL是灵活的。整体而言，通常大型的数据库适合U2L，而web，app等整体压力不大或者可以做分布式的应用，可以做U2VL。

如果客户选择U2VL，红帽建议客户使用RHEL+RHEV+Gluster的解决方案。其中RHEV是红帽基于KVM的企业级虚拟化方案。Gluster是基于开源的SDS方案。

无论是选择哪条路，Linux操作系统都处于客户的位置。 在当前，大型企业的数据中心，Linux系统的比重也来越高。根据IDC的统计数字，在2013年的时候，红帽linux在linux市场的份额就已经超过了70%，无疑是Linux市场的领导者。

谈到虚拟化，大多数人第一时间想到的是vSphere，毋庸置疑。目前为止，vSphere在虚拟化市场，无论是份额，还是影响力，都是最大的。

随着开源的兴起，开源虚拟化解决方案也受到越来越多客户的注意。根据2015的调查数字，接近60%的用户正在或者倾向使用Multiple Hypervisor。而RHEV是红帽基于开源KVM的企业级虚拟化解决方案

时至今日，无论在功能上或者可维护性上，RHEV对客户而言，多了一个开源的虚拟化软件的靠谱选择。

在开源虚拟化软件里，KVM是业内标准。既然如此，我们完全有理由相信，KVM开源项目的领导者红帽，它的RHEV是开源虚拟化平台里的最靠谱产品（之一）。而笔者同样相信，未来客户的虚拟化平台，根据不同SLA的要求和成本的考量，也一定是多Hypervior并存的情况。这也会要求云管平台能够兼容多种Hypervisor。

与vSphere相比，RHEV可以实现vsphere企业增强版90%以上的功能特性，这些都是绝大多数客户最常用的功能。。

使用虚拟化，我们除了惯性稳定性，性能也是很关键的一个考量点。根据SPECvirt的测试报告，RHEV在性能方面，在2路和4路服务器性能测中，RHEV性能与vsphere各有千秋。而在8路服务器性能测试中，vmware和华为都没有参与。

RHEV的storage domain（与vSphere中的datastore概念相同）分为几类：

ISO存储和数据存储。其中ISO存储是用户存放虚拟机镜像的。数据存储是用于存放数据的。

数据存储域，支持NFS、GlusterFS、Posix 文件系统、iSCSI、光纤存储等。

在存储的选择上，我们也是建议根据业务特点进行划分。当然，前面我们已经提过，对于I/O压力要求非常高的应用。我们建议迁移到物理机上。所以在RHEV虚拟化里，对I/O实时性要求不是非常高的应用，我们建议使用Gluster。也即是红帽的SDS解决方案。我们可以把gluster简单理解成，基于软件的分布式NAS。Glutser集群节点数没有技术限制，最多可达上千个。我们可以在Gluter集群节点上部署RHEV，这就是是红帽开源的超融合解决方案，也可以把虚拟化节点和Gluster存储节点分开。

在做了U2VL的虚拟化的应用，如果对实时IOPS，活着说小文件随机读写很多的话，也可以由RHEV对接集中存储。

需要注意的是，RHEV-M除了可以管理RHEV-H，也就是那个类似于ESXi的300M的裸金属架构的Hypervisor，它还可以直接管理RHEL，并且可以在RHEL和RHEV-H组成同一个集群，虚拟机在RHEL和RHEV-H之间迁移。除此之外，RHEV还支持Power8服务器。

Gluster：分布式的SDS解决方案，gluster集群节点数最多可到数千，它利用服务器本地磁盘存放数据，其总容量在PT级。Gluster提供多种连接方式，Samba、NFS、FUSE等，linux原生支持FUSE。目前Gluster使用范围很广，如存放石油勘探数据。我们可以把它理解成利于开源软件的分布式NAS。通过Glutser与RHEV整合，不仅可以实现计算虚拟化，还实现了灵活的存储虚拟化。

U2L具体的迁移分为六大步骤。红帽的的技术专家会根据客户的应用特点和需求，成立专门的U2L项目组。先做分析与设计会规划。然后迁移小部分系统，进行压力和性能测试，观察一段时间以后，再进行正式的大规模迁移实施。迁移完毕以后，对客户进行技能和文档交付，并提供后起的技术支持。

自动部署

客户采用各种开源技术实现了操作系统的批量安装和自动化部署、但是先前的做法可重复利用化程度很低，每当有项目需要进行自动部署时都需要针对该项目重新进行配置，工作量大且效率低下而且没有很好的版本管理和回退机制，也缺乏一个很好的管理界面来进行管理，希望通过有效的管理工具来实现快速部署海量服务器的问题。

软件更新

客户的服务器升级都是去红帽官方网站下载然后手工进行升级操作，实效性、可追溯性差，管理员只是被动接收来自安全部门和红帽的安全建议，希望通过一个集中展示平台，直观的看到数据中心所有linux服务器目前运行的软件版本和官方版本之间的差异、升级的类型并直接通过统一的展示界面远程直接对需要升级的服务器升级某一个软件的升级程序。

安全更新

国家现在对开源软件的安全性要求很高，行内的安全部门以及公安部会定期对所有的Linux服务器进行安全扫描并发布安全整改意见，这些意见和厂商提供的安全更新建议往往有很大的出入，迫切的需要一个工具能提供红帽产品的安全更新以及修复建议并且能结合上述的软件更新功能为系统及时的修补安全漏洞

合规性检查

‍

客户有自己的操作系统基线，定义了一系列的标准，这些标准需要人工来实现以及更，参与Linux运维的人员也很多，每个人的能力、对操作系统的理解程度以及使用习惯的不同会造成Linux服务器的配置存在很大的差异，有无可能通过一个集中式管理工具结合客户的运行规范来实现自动化部署并且可以根据已有古规范找出个与规范之间的差异并消除

多用户、用户组管理以及访问控制

客户基于Linux的系统都是以项目（业务）的方式进行划分的，每个项目都会有相应的软件中心和数据中心的技术人员负责应用软件和操作系统的开发、部署、上线、维护等工作，为了完成这些工作需要给相应的用户赋予相应的权限以避免越权操作，希望解决在大规模Linux使用环境下用户管理和权限划分的问题。

服务器组批量操作

传统的Linux运维管理需要登录到服务器上手工或者通过执行脚本的方式来进行，对于一个项目而言，通常几台甚至几十台服务器的配置和运行环境是完全一样的，希望能实现像操作一台服务器那样操作一组服务器，执行一次操作就可以对该组内所有服务器都生效，即对一组服务器可批量进行升级、部署、管理和维护的工作

为了帮着客户实现标准操作环境，参考GartnerIT基础架构和运维成熟度模型中的技术维度，我们根据在Linux领域长期的经验，提出OS运维成熟度模型。该模型分为五个级别。

级别1：没有标准

IT规模很小的客户，IT只负责安装系统和处理问题。

级别2：开始制定IT标准。

IT规模大一些的客户，操作系统的安装就需要有标准，否则相同版本的操作系统不同的人安装，由于安装模式不同，可能装的五花八门。补丁也需要关注，但这个阶段采取的方式通常还是手工下载补丁包、手工打补丁。配置管理则是依据编写的文档手工修改。日志和告警需要手工检查，安全策略通过配置防火墙测试实现。

级别3：关注标准的执行

IT规模比较大的客户，操作系统安装就需要从手工安装转化为自动化安全。而补丁管理需要使用yum源。配置方面，则需要使用批量脚本进行批量执行。需要定期巡检。安全漏洞则需要定期扫描。这个规模的客户，IT制度需要严格执行。

级别4: 关注执行过程中产生记录，统一管理

对大型的企业，需要做操作系统版本管理。而补丁管理，也需要集中管理。配置管理则需要在级别3的批量脚本执行上，使用git或SVN进行统一管理。告警和日志也需要做集中管理，把操作系统和应用日志做统一收集和分析。安全漏洞方面，也需要做集中管理，以提高效率，避免出错。

级别5.实现开发运维一体化

DevOps作为模型中的最高级别，目的是提升产品的研发速度缩短新产品的发布周期。系统版本使用容器技术进行分层管理。补丁管理、配置管理、日志告警、安全漏洞的管理均实现了自动化。

在OS成熟度模型中，大多数客户处于级别二到级别三的转化中。而红帽卫星，是能帮助客户将OS运维成熟度模型提到到四级（以红帽卫星为主，结合开源工具ELK）。而从四级到最终第五级的Devops，则需要OpenShift解决方案以及Ansible等工具。