Lighthouse Security Group是IBM长期合作伙伴Lighthouse电脑服务（Lighthouse Computer Services）公司的一家子公司，伴随越来越多的公司和企业通过移动设备将其数据存储到云端，Lighthouse的签名平台Gateway被广泛用来保护IT环境下的ID和数据。

IBM接连在“身份和访问管理”安全服务领域发力，此次收购，距蓝色巨人在7月下旬收购云安全服务公司CrossIdeas公司仅仅两周时间。IBM计划将Lighthouse和CrossIdeas集成到IBM当前的“身份及访问管理”服务（IAM）中，从而创建一整套以身份识别为中心的安全软件和服务。

IBM通过在安全服务领域不断展开收购，加强企业软件行业标准建设，而且IBM似乎通过企业间并购获得了不菲利润，尤其是在企业安全部门。据Gartner最近提供的数据显示，IBM已成为全球第三大安全软件厂商，仅次于赛门铁克和McAfee，2013年IBM安全服务营收同比增长20%至11.4亿美元。

Google或者百度一下“云存储”这个关键词，搜索出来的网页早已上亿。IDC也预测2015年，全球云存储开支将达226亿美元。这些数据正在推动全球云存储市场的竞争日趋白热化。

那么什么是云存储呢？对此书生安全云的创始人王东临先生告诉赛迪网记者，云存储是相对个人消费级存储和企业级存储而言的，他打了个形象的比喻，就像交换机，三者分别对应电信级交换机、家庭用转接器和集团交换机。云存储 是专注于向用户提供以互联网为基础的在线存储服务，用户无需考虑存储容量、存储设备类型、数据存储位置以及数据的可用性、可靠性和安全性等繁琐的底层技术细节，就可以从云存储服务提供商那里获得近乎无限大的存储空间和高度可靠的服务质量。那么云存储的安全性如何保证呢？

近日，阿里云推出RDS只读实例，将满足大量的数据库读取工作负载，帮助用户应对数据库读取压力，实现读取能力的弹性扩展。目前，RDS只读实例属于公测阶段，用户可登陆阿里云官网申请免费使用。

阿里云RDS产品经理王义成表示，阿里云RDS只读实例不但适用于专业的DBA，也非常适用于“小白客户”，备份设置、参数修改、阈值报警等数据库常用应用都是图形化操作，对于不精通数据库的用户也可以“零门槛”使用。

数据库应用一般分为读、写两种类型的请求，当数据库压力较大时，读写请求都会集中到单个节点，无法满足用户的需求，甚至会对主流程业务造成影响。为解决用户对数据库大量读取需求，阿里云推出了RDS只读实例，其以用户的RDS主实例为基础，在同一地域内为用户独立配置的数据库实例与主实例进行数据同步，分担用户数据库的读请求，以满足大量的数据库读取负载。

王义成告诉记者，RDS实例采用主备架构，RDS在支持只读实例后，只读实例将挂载在主节点上，实例的备节点以及只读实例均利用MySQL的原生复制同步主节点的增量数据。 

RDS只读实例的使用条件

目前，一个RDS主实例最多可以创建5个只读实例，只读实例的配置大小可与主实例不一致，并且可以根据业务需求，随时升降只读实例规格，整个过程对用户完全透明。此外，RDS只读实例不需要维护账号与数据库，全部通过主实例实现同步。目前，RDS提供近20个系统性能的监控视图，如磁盘容量、IOPS、连接数、CPU利用率、网络流量等，用户可以轻松查看实例的负载。同时，RDS提供多种优化建议，如存储引擎检查、主键检查、大表检查、索引偏多、缺失索引等，用户可以根据优化建议并结合自身的应用来对数据库进行优化。

即日起至2014年10月22日，RDS只读实例处于公测阶段，但对于使用RDS只读实例的用户还是有一定条件的限制。首先是地域的限制，目前RDS只读实例只对杭州地域的用户开放，后续也会在北京、香港、青岛等节点陆续开放；第二，在数据库版本上，目前只支持MySQL 5.6，王义成表示，MySQL 5.6之前的版本在主实例down机后重新选取主实例的时候存在数据丢失的风险（详情参见：http://help.aliyun.com/doc/view/13738436.html?spm=0.0.0.0.B60M35），而MySQL 5.6修复了该问题后，阿里云推出了基于MySQL5.6版本的只读实例。由于在阿里云的用户中，使用MySQL实例的占绝大部分，因此，RDS只读实例也是率先支持MySQL数据库，未来针对SQL Server阿里云也会推出只读实例。

RDS只读实例的创建方法与收费模式

用户使用RDS只读实例，需要先拥有一台阿里云RDS，然后基于RDS主实例购买只读实例。创建一个空的只读实例需要5-10分钟，之后，将主实例的物理备份覆盖到只读实例中，耗时取决于主实例的数据大小；最后，只读实例同步创建过程中主实例的增量数据，用户可通过控制台进行管理。

需要注意的是，此次推出的RDS只读实例并不采用包年包月的收费模式，而是更加灵活的采用按小时付费的收费模式，根据用户使用的内存、硬盘存储空间以及公网传输流出部分的流量三个指标收取费用，用户可根据业务的实际需求，调整只读实例的配置，方便使用。此外，RDS只读实例的开通和释放也比较灵活，没有时间限制。对于服务保障，RDS只读实例承诺99%的SLA，并且承诺宕机后24小时之内恢复，若阿里云没有达到服务质量，将会根据宕机时间进行百倍赔偿。

 注意事项

对于使用RDS只读实例的用户，还有几点需要注意：

一、由于RDS架构是基于主节点进行MySQL Binlog同步的，因此用户在开通RDS只读实例之前，需将数据库升级到MySQL 5.6版本，并且将应用程序在MySQL 5.6版本的数据库中完整的运行一遍；在主实例（A）升级版本前，最好做一下兼容性测试，或者新建一个实例（B），将数据从A实例复制到B实例，然后在B实例上面生成只读实例；

二、用户在购买RDS只读实例前，需要在24小时内进行一次全量备份，以减少只读实例搭建时间；

三、由于只读实例自身限制，只读实例不支持数据库管理、账号管理、数据迁移、数据恢复等功能，用户可以在主实例进行操作，系统自动同步到只读实例；

四、由于用户需求不同，RDS只读实例不会自动帮助用户做读写分离，只读实例使用单独域名，用户需根据业务需求，自行选择哪些请求发往只读实例；

五、RDS只读实例目前最多支持五个节点，五个节点的负载均衡用户自行保证；

六、只读实例的规格配置不要太小，建议大于等于主实例配置；此外，由于只读实例的设计是单节点，没有主备，因此用户需购买多个只读实例来完成高可用目标。

王义成表示，只读实例适用于读取压力较大的业务，例如基于OLTP的电商类应用，需要查看产品信息以及评论的请求较多时，适合通过只读实例来满足这些需求；此外，对于交友类的SNS应用，查看状态或记录都是基于读取的请求，都可以尝试使用只读实例。

为了以最终用户所需要的速度部署新的基础设施，企业IT部门需要拥有基本模块架构和真正DIY功能的可视化自动化工具。

云计算的两个主要价值就是速度和灵活性。云计算编排和自动化工具有望让IT部门大大加快运营速度，并且成为更具竞争力的服务型部门。虽然一旦虚拟化系统落实到位，编排工具在灵活地部署应用程序方面通常做得很到位，可是遗留的非虚拟化底层基础设施其灵活性或自动化程度不是很高。人们没有正面解决这个问题。相反，许多人把精力放在了解决物理基础设施问题上，试图获得灵活性时，这就成了致命弱点。不过，可以避免这种情况。

为什么基础设施灵活性至关重要？

企业IT部门面临许多方面的压力：上头下达的任务、预算、用户期望以及与竞争对手之间的差距。

首先，这是个不言而喻的现实：企业IT部门面临的任务正在迅速转向支持灵活创新。不过，预算并没有相应增加，帮助IT部门满足这个要求。根据知名调研机构Gartner的《2014年CIO议程报告》的调查结果显示，全球CIO声称，2014年累计的IT预算增幅只有区区0.2%。

原因可是带来压力的另一个方面：用户要求IT部门提供IT消费化，这促使用户从别处获取服务。在Gartner的同一份报告中，有CIO声称，25%的IT开支出现在IT预算外面――这仅仅是他们所看到的。换句话说，企业的IT部门将“市场份额”拱手让给了公共云计算服务。

一方面是几乎立马就能提供的公共云资源，另一方面是传统IT流程交付的速度较慢的服务，这种竞争差距或许可以解释这种转变。据企业管理协会（EMA）的《2014年软件定义数据中心》研究显示，47%的企业自称，为应用程序开发人员和测试人员部署基础设施所需的时间短至一星期、长达一个月。

基础设施交付时间

相比只需要短短“几分钟”就能获得公共云资源，这个竞争差距相当大。当然，并非一切都会很快向公共云转移。在将来，会有好多基础设施事务需要IT部门处理好，不过提高标准对IT部门来说有百利而无一害。

物理基础设施仍是云灵活性面临的一大障碍

云计算及相应云计算自动化的两大原则就是，所有的基础设施变成虚拟化；拥有对自动化友好、最好是代表性状态传输（REST）式样的应用编程接口（API）。这无疑是一种大有帮助的、简化操作的愿景。这让人们有可能将“基础设施变成代码”，因为一切都是抽象处理的、软件定义的、可编程的。

这个愿景方面鼓舞人心的主要例子有Netflix等大规模互联网公司，它们的业务运营有赖于亚马逊网络服务公司（AWS）等提供商提供的公共云基础设施。遗憾的是，大多数企业组织的历史不像这些互联网公司那么短，也没有似乎无限制的IT预算；对它们来说，IT基础设施的实际现状可能显得相当混乱。据NTT通信公司在2013年的一项调查显示，58%的CIO表示，阻碍自己采用云计算的最大障碍之一就是，现有系统错综复杂。任何已经存在了10多年的IT部门拥有没有虚拟化的遗留基础设施，这些基础设施可能不会在短时间内马上消失。

物理基础设施的现状影响着IT取得类似云服务的灵活性，这体现在几个不同的方面：

•零日部署。如今，大多数企业在IT基础设施方面的投入仍然侧重私有云，而IT团队购买基础设施设备的方式已发生了翻天覆地的变化。以前的方法是，购买计算、网络、存储和虚拟化这每个类别的同类中最佳解决方案，然后自行把这些部分集成起来。现在，人们越来越追捧VCE Vblock等融合型基础设施产品、EMC VSPEX等参考架构，甚至Nutanix或最近宣布的VMWare EVO:RAIL等超融合型解决方案。融合型基础设施、参考架构和超融合型解决方案具有诸多优点，包括：它们本身已经过集成、测试和兼容性认证，能够达到某些性能基准，或者支持一定数量的虚拟机或桌面。这为企业的IT部门减轻了扮演系统集成商的压力。然而，即便有了集成的产品，搭建基于这些产品和架构的小型集装箱式数据中心（pod）所需的零日配置也绝非易事。这通常需要多个领域的专家协同工作，针对某一个特定的部署场合来进行手动配置。这往往需要一到三个星期的时间。如果不是那么浪费人才，如果这么长的配置和部署时间与公共云提供商的解决方案不是相差甚远（可以在短短数分钟内构建好虚拟机），那这很好。

•供应链。考虑到部署时间方面与公共云服务提供商之间的竞争差距，有必要强调一点：私有云基础设施的部署与供应链确实密切相关。如今的大多数数据中心基础设施是通过分销和系统集成渠道而购买的。究其原因，那是由于，即使我们假设分销商保持充足的库存量（在适时物流世界），那样根本不存在设备制造商发货引起的滞后时间，分销商或系统集成商通常不得不执行某种程度的配置工作。我们也别忘了，IT产品分销行业靠相对较薄的利润来运作。因此，虽然利润丰厚得多的制造商有许多高度专业化的人才，但分销渠道拥有的这方面人才比较少。这就意味着，如果配置工作需要专家们在房间里待三星期，可供调派的专家就比较少。然后，哪怕IT企业的小组只是想及时收到基础设施，供应链也会成为一大制约因素。如果企业的IT部门受到反应迅速的公共云/影子IT这个竞争对手的威胁，那么供应链也受到威胁。

•基础设施即服务。构建私有云或混合云基础设施即服务（IaaS）解决方案时，许多IT部门面临这个事实的挑战：它们必须处理物理基础设施资产，比如非虚拟化/专用服务器、网络交换机和遗留的非虚拟化存储阵列。这些资产的存在绝对不是什么小事。比如说，EMA的软件定义数据中心研究发现，83%的IT部门在专用服务器上运行应用程序。此外，虽然软件定义网络（SDN）现处于炒作周期的高峰期，但事实上，实际部署的SDN几乎就没有，尤其在企业IT环境中。实际上，2014年8月开展的一项调查发现，三分之二的调查对象估计至少三五年后才会部署SDN。因此，无法处理好虚拟化基础设施和非虚拟化基础设施的IaaS可能会沦为另一个孤岛，无法帮助整个行业向前推进。

编排和自动化适合何处？

如今市面上不乏出色的编排和自动化工具；然而，绝大多数工具属于两大类，没有哪一类真正面对基础设施灵活性的实际现实：

•纯虚拟化编排。大多数编程和自动化工具实际上假设：一切系统都是虚拟化的。无论是面向整个堆栈，还是可能面向网络虚拟化，这类解决方案根本没有以任何一种有意义的方式来处理物理基础设施。

•垂直集成的编排。大多数数据中心计算基础设施厂商提供编排工具，以处理物理基础设施和虚拟基础设施。然而，所有这些基础设施必须由同一家厂商来提供，它很少可以延伸到其他所有已落实到位的物理或遗留基础设施。

当然，这不是说这两种解决方案都缺乏有效性、都没有用――它们显然适合特定的使用场合和环境，但它们也明显存在局限性。

通常来说，为了克服这些挑战而提供的解决方案就是API：你可以使用API，扩展工具的业务逻辑，以便处理原本无法处理的对象，包括物理基础设施。这种办法确实存在着一些问题，但我只想说一句：就算有意愿，大多数企业的IT团队也无力构建和维护一套内部自行开发的自动化架构（通常意味着面临一大堆难以维护的脚本），以便满足这些需求、与那些API进行集成。

灵活基础设施编排技术和最佳实践

好消息是，现在已经有编排技术和与之配套的最佳实践，可以克服异构基础架构这个挑战。方法包括下面这些主要原则：

1. 基本模块对象架构。为了满足将物理库存和虚拟化资源编排成公共资源池这一需要，所有的资源及配置接口都表示成或编码成基本模块对象。这意味着，可以为基础设施库存资源分配公共属性，以便识别应该使用哪些配置对象。比如说，它们是虚拟机、是IOS或IOS-XR交换机，还是运行Linux的非虚拟化的戴尔或惠普服务器？配置对象还有着同样的公共属性，以便从底层API语法抽取输入参数。这种方法的一大优点是，它为自动化重复使用奠定了基础，因而大大减少了维护自动化所需要的成本和时间。这与基于脆弱脚本的系统形成了鲜明对照：脚本系统往往难以维护，这是由于在几百个或数百个不同的脚本之间有着太多重复的公共函数或API调用，另外由于脚本比较难以理解，特别是由于它们往往缺少详细的说明文档。

2. 创建即开即用、自己动手（DIY）的配置接口。对自动化工具厂商们来说，为公共云API构建库比较容易。试图支持在企业IT部门多年来部署的基础设施这个庞大环境里面的所有一代又一代的接口，好比试图把整个海洋烧开，无疑是白费力气。如果完全依赖自动化工具厂商来构建和维护这些接口，自动化过程也就丧失了大部分灵活性，因为代码更新可能需要耗时几个月，甚至在开始为那些接口编写代码之前可能需要与业务部门洽谈相关事宜。在许多情况下，配置基础设施其实只需要API的一小部分。所以，想保持自动化方面的灵活性，能够自行创建配置对象的DIY方法必不可少。

3. 可视化编排和自动化创作工具。如前所述，大多数企业的IT小组没有大批程序员。这些部门最不希望被没有根据本企业的人员状况而开发的一套方法捆住手脚。企业的IT人员习惯于使用用户界面（UI）工具。GUI编排工具相当常见，但它们应该具有真正的灵活性，以便构建资源环境，包括任意的网络拓扑结构，以便连接可能需要的所有不同资源。编排工具应该可以将物理资源和虚拟资源都能拖放到设计画布，并且在物理层和虚拟层都能管理好连接。一旦自动化对象创建起来，你没必要让业务逻辑与环境构建、仅由程序员构建的配置混在一起。可视化自动化创作工具让见多识广的非程序员也可以通过拖放操作来设计工作流程。对象重复使用和可视化创作工具这对组合意味着，你可以增加实现和维护自动化的人员的数量，而这有助于形成一种真正可持续发展的自动化实践。

企业的IT团队确实很需要提高部署基础设施方面的灵活性。在竞相构建和证明这种灵活性的过程中，别忘了全面顾及最终用户需要的所有基础设施，包括物理基础设施。然后，选择一种编排技术，并确立自动化实践，以便有效管理该基础设施，让你可以为长远目标构建和维护自动化。

针对此前央视曝光的苹果iOS设备侵犯用户隐私等问题，苹果官方发声明做出回应，首先感谢了CCTV所做出的“努力”，随后又表明自身的立场，过去、现在和将来都不会追踪用户的定位。

在这份回应CCTV的声明中，苹果强有力的写道：“我们郑重地承诺，坚持给予用户清晰而透明的提示和选择，让用户得以控制自己的信息”、“我们非常感谢CCTV的努力，就这一我们也认为非常重要的议题来协助进行用户教育”。

苹果感谢CCTV 否认侵犯用户隐私（图片来自南报网）

此前，CCTV曾于315晚会将苹果不合理的三包政策揭露出来，随后又曝出iOS设备侵犯用户隐私，称即便关闭定位功能，苹果公司依旧能够掌握用户的位置信息。

苹果表示，公司不会访问iOS系统“常去地点”或定位服务的缓存，也不允许第三方应用访问，期间经过加密，用户可控。

与此同时，就在今年年初，苹果设备被美国权威机构评为安全系数最高的设备（被第三方应用入侵最少）。