前言

数据对当今商业社会来说已经成为核心，因为企业必须要收集和分析有关企业运营、消费者行为和环境状况等每一个环节，并加以利用。然而，虽然数据崇拜势头愈演愈烈，但作为保存数据的方式——存储却仍止步不前。虽然虚拟化等技术已经彻底转变了计算和网络功能的交付方式，但存储在很大程度上仍然摆脱不了在专用物理机器上运行专用软件的传统模式。

当然，存储供应商和服务供应商都在不断改进产品，以满足企业所需的更快速度、更大容量和更简捷操作。近年来，领先的存储厂商，包括EMC、HPE、IBM、戴尔、和NetApp已经在其产品上推出了大量创新技术，例如闪存技术、融合和超融合的基础架构，甚至软件定义等功能。此外，云服务提供商已经应用了基于云的数据库和对象存储服务，并高速增长。

然而，如果要应用这些创新性的存储解决方案，企业就必须被迫放弃他们的传统环境，并开始执行令人畏惧的“升级和转换”。其结果是，企业的存储负责人要鼓起勇气抛开现有的存储，为企业的新应用部署新一代的产品。但是传统存储架构依旧要继续运行。于是，每一个新加入的独立系统都会不断增加存储环境的复杂性，增加管理负担，继而阻碍跨存储方案的效率和一致性。

作为回应，软件供应商都开始开发基于软件的管理解决方案，提供用于管理异构存储环境的工具。其中，飞康公司的FreeStor平台作为一款先进的软件定义存储平台，使企业能够从存储中获得最大的价值。

存储问题

数据存储的基本问题可归结为物理问题。早在2010年，Dave McCrory（目前任分布式数据库提供商芭蕉科技CTO）就提出了“数据引力”的概念，McCrory写道：

将数据比作是一个具有足够质量的行星或其他对象。随着数据的积累（增加质量），额外的服务和应用就很有可能被吸引到这个数据中…

服务和应用可以有自己的引力，但数据是最庞大、最密集的，因此它的引力最大。数据如果足够大，其自身几乎不可能移动 。

McCrory给出的这一恰当的比喻认为数据应放置于访问它的应用程序附近，而不是放置在一个集中的云数据库 中。但数据引力同样也解释了在迁移和复制存储数据时企业所面临的挑战 - 为什么他们不愿意改变他们现有的存储，即使一个新系统能够为其带来更大的利益。数据引力可以解释为什么企业不愿意将数据存储到云而更愿意选择其他业务工作负载：57%接受Stratecast调查的IT决策者将“数据迁移带来的挑战”作为采用云存储的主要障碍。

移动存储数据需要花费大量的精力、成本以及带宽，而且肯定会打乱正常运营。随着数据量的增加，所面临的挑战也会加剧。因此，数据创建或最初存储的地方往往是它最应该被保存的地方。

一方面，企业不愿移动现有存储，另一方面，企业又没有足够的迁移解决方案，这些问题为IT部门和企业整体带来了更多的挑战。从战术层面来看，存储管理员面临着以下挑战：

· 部署和管理多个异构存储系统的管理复杂性
· 存储资源流通的效率低
· 跨存储的可视性和性能报告不一致

更令人担忧的是：随着企业准备在快节奏的数字经济中竞争，存储很可能成为实现战略业务目标的阻碍。例如，异构的、不灵活的存储环境会有以下问题：

· 不能够充分支持高可用性以及始终在线的要求
· 降低应用程序的性能（通过每秒I/O和吞吐量来衡量）
· 阻碍新的应用程序部署和扩展
· 备份和恢复不完备导致的业务风险
· 阻碍搭建混合的IT环境，包括物理、虚拟环境，应用跨越本地和云

虚拟化和软件定义存储技术的有限杠杆

如前所述，存储可能是传统IT的最后一个堡垒，由搭载专有软件的专用物理设备主导，不容易与其他系统和模型融合。实际上在底层，大多数存储厂商已经大量使用了革新过的其他IT组件的技术和模型，比如服务器和网络。

这并不是说存储厂商已经停止了对创新的投入：事实上，他们正在积极为其产品开发更强大的功能，旨在使存储速度更快，效率更高，成本效益更大，存储环境更灵活。

在过去的几年中，存储厂商推出了虚拟化技术，使得有越来越多的功能从硬件平台转移到软件平台。利用存储虚拟化，软件层（功能就像一个虚拟服务器上虚拟机管理程序）可从数据平面将存储控制平面抽象化，使网络存储设备整合起来并集中化管理。

最近，一些厂商已经开始把他们的产品描述为“软件定义的存储”。尽管该术语有时与存储虚拟化可互换使用，但软件定义存储通常代表可以通过中央控制平台、跨所有网络连接的集群的一种更高级别的功能。例如，传统上重复数据删除和复制的服务，通常依赖于硬件，但在软件定义存储解决方案中，可能是基于软件的。软件定义存储经常与超融合解决方案相关联。在超融合解决方案中，存储、计算和网络组件预包装在一起；软件定义的组件融合到一起以进行操作和扩展。

具有讽刺意味的是，对于大多数软件定义存储系统而言，他们依赖于特定厂商的硬件。而供应商并没有完全去耦硬件逻辑，也不支持用户使用任何他们选择的硬件。相反，他们的软件只能控制、整合和管理厂商自己的硬件设备。这限制了它在实际环境中的应用。

FreeStor:中立的软件定义存储平台

飞康公司作为一家基于软件的存储服务长期供应商，提出了一个新的解决方案。该公司的FreeStor平台是一个复杂的、软件定义的存储解决方案，也就是说，它能够将底层存储硬件中的控制逻辑抽象化。此外，该平台还是一个智能的“数据服务”层。

FreeStor与其他软件定义存储解决方案的供应商之间的首要区别是：FreeStor与硬件无关。该功能使用户能够保留他们现有的多供应商的异构存储环境，并通过“智能抽象平台”将其集中到一起。

由于它是第三方的独立产品，因此该平台非常适合现代IT常见的混合环境。FreeStor不仅实现了数据的存储，它还方便了应用程序和不同IT平台（基于云和本地；开放和专有；物理、虚拟和混合）与各种存储资源（基于云和本地；闪存、磁盘驱动器和磁带；物理、虚拟和混合）之间的数据流动和服务。随着企业收集、共享和使用数据的部署模式和环境不断增加和变化，一个孤立的、只能面向某个特定厂商的存储管理方式将难以为继。

FreeStor基础架构

FreeStor解决方案的工作原理是：在应用服务器和存储硬件之间的数据路径中插入一个智能层。如图1所示，FreeStor要部署使用两种类型的服务器：

· FreeStor存储服务器，（可以是虚拟或物理服务器）安装在存储系统前面。这些服务器实现数据抽象（虚拟化）功能，并将数据服务（例如快照、复制）应用到存储系统中。
· FreeStor管理服务器，用于管理资源整合、控制数据服务。管理服务器连接到至多128个 FreeStor存储服务器，并对他们集中管理。

将这样一个服务器插入到数据路径中，并不会显著增加时延；该公司表示，时延负担大约在130-150微秒之间。尽管该解决方案需要企业在存储环境中部署额外的硬件组件，但增加几台廉价服务器，或者利用虚拟机并不会增加多少投资。此外，FreeStor还可以把FreeStor管理虚机部署到云上，例如AWS S3和Azure StorSimple，以及基于OpenStack的云服务。

挑战数据引力：简单、无中断的迁移和复制

FreeStor基础架构和其强大的软件平台解决了许多与数据引力相关的问题。使用统一的FreeStor控制平台，可以很容易实现抽象（虚拟化）数据的迁移、备份、复制，或跨位置或跨部署模型或跨硬件恢复，而且没有数据移动的风险。因此，企业能够非常灵活地部署和管理跨多个存储平台和位置的存储资源，并由一个单一管理平台来进行集中管理。

更重要的是，FreeStor可以进一步通过双活架构提升异构硬件管理的高可用性。这种高可用架构的最小单元是1 + 1的集群对，两个节点可以部署在本地，也可以拉长到不同位置。如果需要进一步扩展，FreeStor还可以支持2+2的4节点集群或更多点集群，同样可以部署在本地或远程扩展(见图2右下角所示)。集成的广域网优化功能，将复制的网络时延减小到最少。此外，用户可以选择使用重复数据删除功能，提升效率。

高可用性的能力使得用户可以轻松地删除或增加硬件；迁移至云存储；建立高可用或容灾环境， 而所有这些的恢复时间目标（RTO）均为0。

以下是是用户4种高可用性方案：

· 从原有硬件迁移到新的存储硬件。
· 高可用性方案，其中存储和应用均被复制。
· 管理服务商(MSP) 的备份即服务(BUaaS)方案，服务商利用FreeStor 平台为用户提供高可用性服务。
· 远程多点集群方案，让不同地理位置之间实现镜像，而每个地理位置均可以是多点集群。

全存储池的数据服务

高可用性引擎只是内嵌FreeStor平台的功能之一，在后台运行。而在前端，用户可以看到整个虚拟存储池的数据服务或功能，可以轻松地通过单一界面，跨所有存储基础架构，对它们进行部署和管理。

平台支持的服务包括：

· 迁移服务
· 备份
· 灾难恢复
· 数据归档

最近，飞康引入“云连接器”功能，这是为将原来本地存储的数据迁移至云端，如亚马逊AWS、微软Azure以及OpenStack 的环境而特别设计的。这一功能还支持使用云进行备份和恢复。它又被称为“穿云飞行”，也就是说，对用户而言，这一功能使得他们可以轻松地在不同云服务商之间，迁移工作负载）。

虽然该平台包含了所有服务，但飞康为用户提供经济型选择，他们只需为激活的服务支付费用。

跨异构存储环境应用智能和预测分析功能

对IT的高层领导而言，FreeStor最有价值的功能或许就是它的预测功能。平台通过单一界面跨所有存储平台进行监控和报告。详细的设备级性能和健康监测数据可以让用户：

· 基于实时趋势数据，实现资源最优配置——如获取、转化、重置、预测未来容量消耗
· 根据需要对存储扩展进行规划
· 监视存储设备运行，以便维护
· 确保存储性能（IOPS、时延和吞吐量）满足应用需求
· 确保对内（企业用户）对外（管理服务商）的服务等级协议（SLA）得以实现

最近，飞康在其智能平台上添加了预测分析功能。利用历史数据和趋势数据，此功能可以让用户跨整个存储基础架构环境预测容量利用率。下面的图3就是一份报告中的例子。

对企业而言，真正的价值是，通过监测和分析功能展示的洞察力可以让他们立即采取行动。例如：

· 如果管理仪表板显示某个特定设备的吞吐量突然降低，那么可以启动此设备的镜像设备，同时安排本地人员进行维修和排查。
· 如果存储经理想知道企业是否应该采用闪存技术，那么他们可以在一个或多个工作负载上尝试这项技术，得到测试结果。
· 如果管理服务商想要开发新的增值服务，需要特定存储满足特定应用的需求，他们可以利用FreeStor来监测和管理结果。

直观的管理门户在移动版和网页版上均可以使用，对存储经理而言，这让他们很容易看到基于仪表板数据或警报的存储环境的变化。也许同样重要的是，在一个快节奏的商业环境中，管理人员可以尝试各种选择，在今天做出一个决策，明天又试一试新的做法，却不会浪费时间或破坏环境。

写在最后的话

凭借FreeStor平台，飞康可使得企业用户和服务商精简、优化存储环境，与此同时，也可以使他们更轻易地从存储当中获取价值。通过FreeStor平台，用户可以：

·统一存储环境，集中管理资源池，为应用服务，而无需考虑底层硬件或部署模式
·在不干扰运行也不损失数据的情况下，对存储进行部署、迁移和复制
·通过基于详细的性能数据和预测分析，采取应对措施，优化存储和应用性能
·引入新的存储技术和部署模式（如闪存和云存储）时，不会破坏现有架构
·通过高可用功能，保护数据和应用
·优化存储利用率，控制资本成本
·解锁厂商锁定，并利用单一平台进行管理，减轻存储管理负担。

随着混合环境成为常态，企业用户越来越没有耐心去继续伺候数据中心里那些不灵敏的、独立的系统平台。总而言之，虽然在迎接软件定义和基础架构中立管理工具方面，存储已经远远落后于服务器、网络等构件，但飞康已经凭借其FreeStor平台弥补了这一差距。

Lynda Stadtmueller
云计算服务副总裁

There was a time, not so long ago, that a company could afford to be an “<Insert Vendor Name Here> company.” There was a go-to supplier, go-to VAR, and a go-to product line. The go-to company provided training and lunches, and that built up loyalty. In all of that loyalty, the hope is that the go-to company innovates regularly enough to continue providing value, and maintaining goodwill even after the sale. However, what I believe the consumer space is discovering is that trusted vendors didn’t live up to their end of the bargain. Perhaps it’s not the vendors themselves , but industry practices that need to change?

When I was running datacenters, and being entertained by vendors who wanted to sell me things, the big differentiator was always the extra-mile folks. Usually, technical resources who improved my craft a bit – and didn’t just rest with teaching me about their product. I worked for an aerospace contractor who had to follow government rules about three-bids, single-source, and diverse vendor strategies – mostly for security reasons. I was able to buy technology based on my business needs and trade technology coaching for purchasing tips with my preferred vendors –This practice helped me to vet out vendors very quickly into “providers” and “partners.”

Now that I’m out of that role, I see things a little differently. I know now, why long-term vendor affinity can crush innovation. Without explicitly naming names, take one of the best-known technology providers of the past decade. Most of their revenue has traditionally been tied to years 4-5(+) of maintenance on a CAPEX basis. Typically, your initial investment is discounted, upgrades and expansions are at a premium (to make up for the discount on initial purchase), and maintenance runs at least 20% of initial purchase price annually for as long as you want support. If you do the math, you actually re-purchase your product every 5 years. This should not be an epiphany to anyone as it has been a standard practice in the technology sector for decades.

Financials aside, this kind of practice causes some trickle-down effects on product innovation. If I stand to make 60-70% of my revenue in years 4+, why would I destabilize that base by asking a customer to upgrade or switch product lines sooner rather than later? My goal is to keep my customer happy on their current portfolio as long as possible. So how do I do this if I have to keep my hardware somewhat “flat” in capabilities? Software, of course. I can innovate all day long in my software as long as I only allow my software to speak with my hardware. Software also requires training and has both soft and hard loyalty due to skill, process, and product affinity. The effect of this practice is that you keep my hardware for years past its prime and lock deeper into my revenue stream. So now, instead of using technology to support my business, I change my business to support my technology.

I believe that today, this paradigm is being rejected more and more, causing an interesting reaction in the client and vendor landscape. The CIO cries out from the wilds and shouts: “I have too many silos, too many processes, too many people, too many moving parts!! I need simplicity!!” And the industry reacts with glee: Let’s give them convergence. So now the big companies band together to hold onto market share and bundle up end-to-end solutions with “cross-platform” orchestration. Datacenter in a box, we were promised. That’s all fine and dandy as long as you like and only use their boxes. Now we are even MORE tied into the revenue stream – and that one throat to choke requirement ends up being yours, Mr. CEO as you allow your business to slowly get muscled by your technology providers.

We followed this trend with Hyperconvergence which took out the multiple vendors, and built a consolidated, optimized reference architecture of best-in-class capabilities and built little tiny boxes of lock-in. As long as we like the hypervisor, and don’t mind the restrictions of scale, and the lack of mobility, and have the ability to toss our whole old datacenter (admittedly not a bad choice for many…), then Hyperconvergence is a great concept. But that’s a lot of very important “as long as you...” caveats.

Now we see the growth of open-source in the crazy juggernaut of OpenStack. Let’s get all the big players in the industry to contribute their best-in-breed feature differentiators to a “free” platform that gives everyone of any size an amazing platform of features and capabilities that will completely remove the need for your commercial software, and will tend to commoditize the value proposition of your hardware further into the ground. “[throat clears] sure. I’ll give you my best! [rolls eyes].” Technology socialism, for sure, but it does have lots of promise.

While I’m partially bashing on everything else, I have to make sure I include the cloud in my rant, right? Let’s get this definition crystal clear: the cloud is somewhere else, with some other technology, who I pay to maintain my data for the lowest possible cost and lots of contractual assurances. Heh. Yes, some clouds are puffier than others, but at some point, financials and competition will require cloud providers to push prices to the floor – and force lower standards. Am I saying you tend to get what you pay for? Yes. Yes, I am. The great thing, though, about the cloud providers is that they can be a greenfield technology transition without that investment on the part of the customer and it is about as simple as it gets to consume.

So the echo in the wind back to the CIO is this: “Now that you’ve asked, we’ve provided very little of value other than to offer you a place to offload the responsibility to someone else!!” And now the cloud provider has to deal with the vendor-lock-in and silos and cost fighting, and the CIO fidgets at her desk with almost zero control over what happens to her business’s critical data.

What is it that we need, then? There is something of value going on here, even if you can’t see it under my somewhat cynical overview: there is something happening . Movement is taking place. New technologies are creeping in that change the paradigm of consumption and bring cloud-like models into on-premise IT. What convergence taught us is that orchestration across storage, networking, and compute are critical for IT operations. What hyper-convergence is teaching us is that focusing down into workload-optimized topologies and optimizing operations through analytics-infused automation is critical to IT operations. OpenStack is answering the call for hardware-agnostic, agile platforms that leverage software to provide the right personality of services for a given workload at a given stage of a workload’s requirements. The cloud is teaching us that perceived simplicity and optimizing efficiency for cost is possible and viable. And we’ve proven once and for all that the old way of vendor “techstortion” (technical extortion, anyone?) is finally not welcome in business anymore.

What is the direction things are moving, then? Unless your business is simply hobbled by indecision and freezing all technical assets until something makes sense again we feel ya! You aren’t alone by any stretch; you have been looking at everything I have mentioned in this rant (er… blog!). You have small SAN, mid-SAN, server-san, all-flash array, good-old’-boy vendors, NKOTBs (New Kids on the Block), hypervisor-based, containerized, SDS, SDx, traditional, modern, memory-resident, SaaS, Cloud-enabled, gateway-ed, referenced, marketed, funded, and struggling vendors knocking on your door all day long asking you to listen. And you are listening, and making your choices. You are buying something, even if it’s only time. In the end, you will dabble. IT always has. We take bits of all the cookies on the plate and spit out the bad tasting tech. We keep a handful of old standards and some of the weirder cookies we didn’t think we’d ever like.

What I’m saying is that you will end up buying or trying some of almost everything I have mentioned. Your gut is telling you that something needs to change – and I think I’ve shown you what is broken. The industry will react to what you keep and what you spit out. What you will need is a way to protect your data assets while you test drive and kick tires. You need subscription-based purchase plans that do not obligate you to a return-on-investment time. If a technology does not provide value, you will simply stop using it and your money will go elsewhere. In order to facilitate this, you will need a platform that allows you to bridge your infrastructure across locations, form-factors, vendors, technologies, providers, company names, and other traditional barriers – all while maintaining your processes, skills, and guarantees of service levels to your business. Yep, you need a chaos platform – a middleware between the uncomfortable known and the exciting unknown.

Some of you may be forced into a multi-vendor strategy for compliance or procurement practices, but all of us will be goaded into it simply because the old model is broken and there is simply too much to choose from these days that tangibly helps your business.

I was this customer. I had all these challenges, I saw these changes coming. I embraced a variable technology architecture with multiple locations, and chose a platform to bring it all together and solve the challenges of shrinking budgets, compliance issues, reductions in force, changes in IT leadership, mergers and acquisitions, migrations of technology, consolidations of infrastructure, monolithic vendor platform overturn, and other challenges.

With all the chaos you will be finding in your technology options today, I would highly recommend kicking the tires a bit on a product that will help you to make better sense of what you have, and enable you to safely constrain the chaos of what is to come. 

2016年8月8日，达美航空公司出现了一个重大的计算机系统停机事故，导致航班大面积延误，这个问题以及后续措施对达美航空的运行影响了很多天。这一次故障造成的财务损失极为广泛，不仅严重影响了达美航空的运营和客户服务成本，而且还要对错失航班的客户、未运输的货物等进行一系列的赔偿。

来自CNN的记者Thom Patterson在他的文章中指出，（http://money.cnn.com/2016/08/08/technology/delta-airline-computer-failure/index.html?iid=ob_homepage_tech_pool），此类事件发生的原因是由于“老套的砸锅问题”(“Good old-fashion screw-up”)。对此，我完全赞同。我的第一反应是，“我恰好知道有那么一款产品，它完全可以避免此类事件的发生”。仿佛只要他们使用了某种产品，某种技术，就能避免这种情况的发生。当然，这都是瞎扯。发生这类事故，往往是由于企业系统、基础架构以及各种相互孤立的技术和服务过于复杂，这使得企业几乎不可能进行系统性的测试并制定防范措施。

Patterson在文章中引用了“航空业专家”的话，他们声称，系统停机的原因有如下三个：缺少冗余、黑客行为及人为错误。我认为，只看到这三个原因，说明这些专家们对问题的理解还是比较肤浅的。而且，我想特别声明一点：当今的每个系统都有冗余性或高可用性的设计。问题在于，要么这些功能并没有真正使用，要么没有进行充分测试，要么由于削减预算没有了必要的人力资源。那么，咱们是不是要把所有这些问题都归结到“人为错误”这一条里呢？

那么，我们应该如何应对呢？我认为，在IT界目前有一种趋势，正在从总体上促使灾难性事件的发生。让我们先谈谈财务：我们一直在追求尽可能降低成本，这迫使那些原本可靠的供应商不断降低产品质量。云提供商声称可以保证基础架构的服务级别，却从不告诉你他们是怎么实现的。 在IT圈里，我们很多资深人士对于传统老方法的顽固态度，使得运营方法和产品选择上难以创新。

我曾为一个火箭发动机制造商工作。我们的灾难应急方案就是一条：“快跑，别回头，不然你的脸也要被烧到了。”理论上我们应该每周对数据的可恢复性进行测试，每月对关键系统的系统可恢复性进行检测，每年对数据中心故障进行全面演练。至少，这是我的流程文档是这么要求的。 我是不是真的这样做了呢？当然，我得说我做了！！在实施飞康软件之前，我们只能在灾难发生的时候再演练。我们没法承担时间、资源、金钱的损失和对生产系统的影响，这才是操作手册无法执行的真正原因。

这也才是我们实施FreeStor的主要原因：它可以在不影响生产系统的前提下，处理各种灾难恢复的执行与测试。FreeStor让我可以对灾难恢复方案进行测试、记录和自动化操作，而所有这些都不会影响我的生产过程。直到现在，在企业级市场，FreeStor仍然是具备此能力的唯一平台。

为避免航空公司今后再次发生此类事件，文章的结论是：“他们应该部署更多的自动检测系统。这些系统可以在低流量时期让系统下线，借助于辅助和备份系统进行应急演练，从而确保运行良好”。

看来我需要跟这些“专家”好好交流一下。据我所知，目前市场上还没有这种所谓“自动化检测系统”。对于现在无比复杂的企业级IT架构来说，依靠某种神奇的系统实现全面检测，这简直就是一个幻想。   

我很喜欢专家们提到的应急演练的概念，但是该如何控制演练对生产系统的影响呢？我知道大部分企业可能有办法针对某一台单独设备进行有限的故障接管测试，但是如果是针对灾难的全面测试，会是一个无比复杂而且高风险的流程。我有一个朋友的关键系统已经积累了4PB的数据，他私下里告诉我一旦出现灾难，这个系统要多长时间才能恢复，甚至到底能不能恢复，他完全没有概念。

另外，文章中提到了一个概念“低流量时期”。事实上，现代企业并没有什么低流量时期。达美航空的灾难发生在凌晨2:30，这算不算是“低流量时间”呢？航空公司和大部分现代企业都是24小时×7天不间断的业务。演练时关闭系统，以检测将会发生的事情，这对于大部分现代企业简直无法想象。

因此，如果达美航空公司打电话给我，请求我分享一些经验并提供建议（我一直守候在电话旁……），我将会与他们做如下分享：

1. 请以开放的思想和态度重新审查现有的产品和技术：它是否真的能够实现了你想要的灾备效果？如果不能，就应该赶快去寻找新的供应商或换一种方式来达到你所需要的效果。

2. 寻找一个平台，能够通过统一管理优化互操作性和操作一致性。

3. 寻找一个平台，能够用来测试数据恢复、系统恢复、服务恢复和数据中心恢复且不影响生产。如果你不能测试你的灾难恢复，那么你的SLA就只是空中楼阁。

4. 使用一个能够记录历史和实时数据的操作平台，通过现代化的分析技术，找出薄弱环节，从而得到你真实的SLA水平，与你真实的业务需求作比对。

5. 寻找一个IT分析平台，这个平台能够跨所有的基础架构系统进行关联，从而能够使您从整体上了解您的存储环境。

6. 不要在不充分了解供应商的情况下，盲目选择成本最低的供应商，包括云：如果你对你的存储没办法找到一个好的灾难恢复计划，那么，很可能云供应商其实也没有什么很好的方案。

7. 复制和冗余并不能完全解决高可用性。复制，甚至同步复制，往往会连同故障一直复制。冗余意味着你可能有机会比别人多失败一次（或几次）。如果你的系统需要永远在线，你就需要去找一个永远在线的技术。

8. 最后一条，假如你手里已经有一个工具，就用好它。如果这个工具不能满足要求，那就赶快去寻找新的工具。我已经无数次从朋友和客户那里听到，“我们依据标准化要求安装了这个工具，但其实它不能用。”我想提醒大家的是：请冲破办公室政治带来的阻力，承认有时先前的选择并不太合理。要通过正确的解决方案来支持你的业务，而不是通过你的愿望和关系。

当看到像达美航空这样的大型企业发生真正的系统中断，可能每个人都被吓了一跳。 我们购买技术并把它当做一项保险。但是只有当灾难发生时，我们才发现我们的技术其实并不能在所有的场景下保护所有的系统。对于在机场等航班时写博客的我们来说，我们应做的是：重新思考。打破传统的思维模式。找到并实施真正能够支持你业务的技术。最重要的是：定期检测这项保险策略，只有这样，你才会知道在最糟糕的情况下你面临的风险是什么。因为这个中断既然能够在达美航空发生，那么你将来也可能会遇到。

关于作者

Peter McCallum是一个企业解决方案的专家和技术创新者，自2011年起，他一直担任飞康软件公司数据中心解决方案架构的董事。他曾在企业数据中心优化、业务发展、战略规划和服务交付等方面担任过各种领导职务。Peter拥有15年以上的系统管理和基础架构构筑经验，通过走访世界各地，他与企业一同探讨企业级数据中心优化和业务连续性解决方案等问题。

存储最终已成为令人兴奋的领域，充满了创新与变化，以满足用户对存储灵活性、密度与性能不断增加的需求。闪存价格不断下跌，不同形式的存储内存不断出现，消费品级硬件在数据中心基础架构中快速增长，这些趋势都在推动数据存储与访问方式的创新。

许多公司的CTO和CFO们都在面临这样一个挑战，就是如何更加有效率地存储日益增长的数据，同时又保持合适的性能水平与服务水平（SLA），为最终用户和应用提供存储服务。同时，内部的IT部门也正面临着与外部公有云提供商竞争的挑战，因为公共云往往可以提供更好的灵活性与价格。

下一代超大规模数据中心与存储基础设施，必须按需发展，以满足计算、内存与存储要求。这些要求包括按需供给、基于实例的容量管理，计算、存储和内存可以分别独立扩展，进一步提升性价比，并能真正降低总拥有成本。为这些超大规模数据中心设计的解决方案中，已经出现了以下两种新趋势。

首先，正如下表所述，主要基于FC和NFS的传统SAN环境，仍然在继续运行在线交易型(OLTP)应用，因为这类解决方案可以满足高性能的SLA要求（大于~500K IOPS，小于~5ms应用响应时间）。这一类存储架构建立在存储阵列与SAN网络上，可以提供完整的全高可用性功能，包括数据保护功能和应用不间断服务技术。与其他新兴存储基础架构相比，传统SAN存储的增长率相对较低，而且这种业务模式正在受到冲击，因为用户需要为那些名牌存储技术付出高昂的费用，以获得那些高可用性和数据保护功能，这很难说是合理的。但是，很多公司不愿意在OLTP类型的应用环境中尝试那些颠覆性的新技术，因为稳定性、安全性与可用性永远是这一环境的首要目标。

另外， 在上表靠右的三列，可能是每个数据中心增长最快的部分，也就是那些运行No-SQL、云与大数据工作负载的横向扩展环境。从存储的角度来说，这些环境通常采用直连式存储(DAS)或分散存储模式，使用如iSCSI,  PCIe或 NVMe这样的协议。这些存储架构的规模，尤其是大数据分析架构，可达到数百PB，这使得架构的总拥有成本极其重要。很多在这些环境下运行的应用具有内置的可恢复机制，可以承受硬件故障的冲击，并能够在应用层实现自我修复。文档及Key Value库，进行数据分析的应用程序，配合服务器及机架感知的数据复制技术，可以防止由于硬件故障导致的数据丢失。如果数据保护与自我修复功能可以在应用层实现，就不再需要在存储层实现高可用性功能，这使得数据中心有机会使用更便宜的消费级硬件，因为即使硬件发生故障也不会对服务可用性产生影响。

在未来的博客中，我们会密切关注超大规模数据中心的这些发展趋势，同时也会关注如何取得令人满意的总拥有成本以及可恢复性和性能。

关于作者
Farid Yavari是飞康软件的技术副总裁，Farid在高科技产业数十年的经验包括，为实现企业级数据中心规模部署在超大规模存储解决方案与开发战略及愿景方面展现出的技术领导力。在加盟飞康软件前，Farid曾经是eBay数据中心基础设施团队的高级成员。该团队与存储行业密切合作，推进创新，并与行业领导者共同创造存储技术的未来。多年以来，Farid一直在积极与其同行们及高科技产业人士分享见解与经验，参与大学与行业论坛举办的各种演讲。

横向扩展型的业务负载（如No-SQL、在线交易处理（OLTP）、云、以及大数据分析）对于基础架构的性能和容量的需求疯狂增长，以向用户和应用提供恰当的服务水平。超大规模数据中心的架构必须不断扩展，以满足计算、内存与存储的要求。而需求通常由应用与业务的优先级决定，如容量、安全性与高可用性。对于这样的项目，总拥有成本至关重要，特别是在容量达到PB级别时尤其如此。

超大规模数据中心的横向扩展存储，有两种最常见的模式，一是直连存储(DAS)，二是分散模式，这些分散的存储可能基于多种协议，如iSCSI或NVMe。有些大型用户会专门定制开发一些私有协议，以针对其特定的应用场景优化存储性能。受到服务器插槽数量的限制，DAS模式的应用规模有限，通常很快会不够用。另外，在DAS模式中，计算与存储资源必须同步扩展，因此不能单独进行优化。因此，企业更多从分散模式着手，即使没有从此着手，最终也必然会转向分散模式。SDS会通过一个抽象层把异构的存储硬件与应用分离开，从而赋予分离模式的数据中心智能编排与管理的能力。SDS会提升数据中心的可恢复性、效率和性价比。由于SDS不被某一种硬件绑死，因此企业可以在现有架构上快速采用新的存储技术；否则，用户常常会纠结于是否要为新的存储技术新建数据中心，然后进行数据迁移。有了SDS，用户可以慢慢地从传统技术向现代技术迁移逐步迁移，随着新兴技术的逐渐成熟，选择适当的迁移时机，从而获得最佳投资回报率（ROI）。SDS在很多方面都具有很好的灵活性，如数据迁移、技术更新，以及存储与服务器资源的独立扩展。即使有些应用并不需要很高级的数据保护与高可用性（HA）功能，SDS仍能提供其它有价值的功能，如预测性分析、广域网（WAN）优化、应用感知快照、克隆、服务质量（QoS）、数据重删及数据压缩。

软件定义存储解决方案能够与超大规模数据中心基础设施协调配合，从而满足对存储灵活性、密度与性能的日益增长的需求。闪存的价格迅速降低，不同类型的存储内存不断出现，消费级硬件大规模应用，使得超大规模数据中心存储的未来充满了各种可能。有了SDS，就可为存储提供各种功能，同时提供多种不同成本的存储以应对不同应用的需求，从而得到最优的总拥有成本（TCO）。

关于作者

法里德雅瓦里是技术的飞康软件的副总裁。法里德的数十年的高科技行业经验，包括为企业级客户部署超大规模的存储解决方案，主持建立技术领导地位和规模化发展战略和愿景。在加入飞康之前，法里德是eBay的数据中心基础架构团队的重要成员，与存储行业密切合作，推动创新，塑造了存储技术的未来。多年来，法里德一直积极通过在高校和行业论坛参加各种演讲活动分享他的意见，并与他的同行们的经验和高科技产业。

与法里德雅瓦里连接。