中国HCI市场38家列表 &amp; 【原创】Linda存储手记之六-CSDN博客

本文链接：https://blog.csdn.net/Urh3t1/article/details/78100321

【编者按】

今天是圣诞节，首先祝大家圣诞快乐！

首先感谢朋友和读者们的反馈，上期文章《

赠书 | 年终盘点：超融合架构(HCI)的现状和前景; 中国HCI厂商列表; 全球有哪些HCI厂商？》截止目前，收集到国内市场上至少有38家HCI厂商（超出了我的预料）：

(1)VMware vSAN (2)EMC VxRail (3)DELL vSAN就绪节点 (4)中科睿光 (5)浪潮InCloud Rail (6)神州云科 (7)华为FusionCube (8)联想AIO (9)新华三UIS (10)Nutanix (11)华云网际 (12)Cisco HyperFlex (13)HPE CS250 (14)HDS UCP1000 (15)天玑数据 PriData (16)达沃时代小金刚 (17)青云HCI (18)深信服HCI (19)杉岩数据 (20)书生云 (21)成都文武H3CI (22)云途腾T2Cloud HCI (23)海云捷迅 (24)九州云 (25)宏云+ (26)大道云行SSAN (27)创意云智TROY- PVE (28)ZettaKit (29)BigTera(30)信核Nextor SS2016 (31)SmartX (32)Maxta (33) Simplivity (34)DataCore SANsymphony (35)超云XS5000-F (36)EMC VxRack(基于ScaleIO) (37)鹏云网络Zettastor HCI (38)QCT QxStack/QxVDI 。

若遗漏或多余的，欢迎在上一篇文章的留言里修正。

本篇文章作者Linda Liu（刘畅），Cirrus Data的创始人之一，本科毕业于清华大学精密仪器系，于2005年获新泽西理工计算机博士学位，研究存储阵列调度算法。本篇文章是Linda存储手记系列的第六篇。

前五篇：

第一篇《一个投资顾问兼研发老兵（RAID调度算法博士）的存储手记》

第二篇《【原创】Linda存储手记之二》：QA Engineer和自动化测试

第三篇《【原创】Linda存储手记之三》：延迟和响应时间：相同，却又不同

第四篇《【原创】Linda存储手记之四：剖析存储性能之延迟》

第五篇《【原创】Linda存储手记之五：说说support那些事》

如果您有同感，欢迎转发这篇原创文章。也欢迎朋友和读者向本微信公众号“乐生活与爱IT”投稿。投稿可以微信或者QQ(9269216)联系我。

另外，恭喜Linda走上新的工作岗位 --- 高校教师，开始其她的传道授业解惑的新征程。对于她的新角色，我也心生羡慕。

---Begin---

工程化的思维从交流开始

最近经历了搬家和工作变动，基本落定后发现不论在哪、不论做什么，存储和软件工程这两条主线却是越来越坚定和明晰了。在近几次和业内人士的交流中，再次深感真正工程师的匮乏；尤其是在这个对数据负最终责任的存储界，在研发一个产品时，团队最需要的是一两个对系统有完整了解的优秀工程师。

即将迈入校园担负传授的责任，“如何培养一名工程人员（只是具有工程师意识---Engineering Sense的人员，且先不提合格或优秀）”—这一我在工作中一贯观察和思考的命题也正式纳入到自己的工作日程。我打算好好完善和梳理自己的见闻和思考；今天算是落地的第一篇—进入工程领域，如何和人进行有效的交流。

一个软件产品的落地，其复杂度堪比造一架飞机，其工程团队的将领无疑是整个项目的灵魂。对于这个角色，经验值和创造力同等重要：Ta脑子里不仅要有产品的呈现形态（创造力—不仅是最终展现还要有系统运转机理），还需要回答大量问题（经验值—How if … happen）。这就是为什么有些系统在功能实现并运行一段时间后需要大规模重构。不同的架构设计直接影响系统的产出---productivity，而对各种异常的处理和系统模块间合理的解耦能使得系统更加健壮、可控。健壮性可不是能直接从友好的---user-friendly的界面看出来的。

工程需要解决的是“实现”和“交付”：采用什么方式实现、如何衡量交付是工程范畴不容推卸的职责。指导性的大话不难说，难的是合理（且不说最优了）的逻辑和执行步骤。我永远记得老上司经常提到的一句话“when the rubber meets the road, every interaction becomes real”—交付的那一刻，任何大而空都无处可藏（这也是我参与投资决策时，在看到那么多商业计划---BP和团队实际情况之间落差后深深感慨的原因）。

从人与人的交流可以判断一个人所受工程训练的程度。

提问者对自己的问题进行思考，才能最高效的获得需要的答案。其实工程中遇到问题不可怕，可怕的是对问题没有工程化的描述。如果描述到位，解决便成为可能；甚至在描述过程中，提问题者就可以获得“这是个无法解决的问题”，或者“这个问题有部分我能解决”的答案。

而被问者往往是从自己的知识体系中试图寻找答案。一个需要知识背景回答的问题，被问者知识体系越薄弱，想当然的成分就会越多；知识体系越强壮，答案寻求的路径就越需要用各种信息来缩小范围---narrow down，进而搜寻出来的结果越接近于真值，也就是对方所需要的。明白这个路径，就会发现和小朋友说话特别有趣甚至让人脑洞大开，比如说“为什么诸葛亮在大冬天还要摇扇子”之类的，因为那时候会发现通向答案的一些预设路径竟是世俗造成而完全无道理可言的。

日常生活成这样是不是过于古板啊（我在嘲弄---tease 我自己么 ^_*）？但在工程，对事件进行描述的训练是必须的。例如，在工程描述忌用“许多”“总是”等此类主观词语，因为无法衡量。就拿“总是”来说，一件事物的发生的频率、概率达到了什么样的阈值，和谁相比较（参照物）让你觉得“总是”？重现的场景（scenario）和条件是什么？

经常面对朋友丢过来缺乏上下文的问题，譬如“这个你觉得写得怎样”“你建议我去考什么资格证”，当然还有复杂的多的，我无从回答。有时我会礼貌的反馈一系列问题，譬如“你用这个想达到什么目的”，“面向对象是谁”或干脆建议对方从哪几个维度收集信息。所以原谅有些工程人士不能回答的“不近人情”甚至有时候会让你觉得ta傻—很有可能这冒出来的傻是因为他们缺乏足够让他们给你想要答案的信息。

工程语言是什么样子？极端情况，想想那些在你注册用户时须知的保密协议，估计很少有人在勾选“同意”之前读完一份完整的协议。但的确，软件产品的研发和测试文档是极见功力，尤其是经验值。那么本文就以数据迁移方案命题为例，看看一个工程将领的语言。

文章来自技术博客（http://www.cdsi.us.com/preparing-for-a-successful-data-migration/），作者：WaiLam于2015年10月15日，Linda译。

Preparing For ASuccessful Data Migration

一次成功数据迁移的预备事项

谈及数据迁移，从专家那里获得的建议大多听起来像庙里抽到的签一样（原文是“在孔子自己开的餐厅里获得的签语饼”--“sounds like it came from fortune cookies you might receive at a restaurant run by Confucius himself.”）。给个显而易见的意见不难，譬如“找到靠谱的人”、“尽量避免宕机，减小风险”或者“找到个能将所有操作集中化、自动化控制的好工具”；然而，具体而详尽的建议或许会更有价值。专家有专家的说法，而在数据迁移方面我们具有多年的智慧和经验积累。回顾我们参与的大量商用级别数据迁移的成功案例，我们发现很多共通之处。这些因素基本上可从以下问题的答案中归纳出来：

被迁移的数据是什么类型？

确认迁移数据的类型为重中之重，因为迁移不同数据类型的方法存在根本性差异。

基于NAS – 迁移对象为网络共享空间，迁移为系统级别
基于LUN – 迁移对象为磁盘（逻辑LUN），迁移为块级
基于VM – 一个Hypervisor下属所有的虚拟主机迁移到另一个Hypervisor
应用迁移– 将一组数据库或对象移到另一个主机

另外，整个迁移是什么类型？

本地迁移– 同一个数据中心内
远程迁移– 从一个数据中心到另一个数据中心
云迁移– 从本地到云服务商（例如AWS，SoftLayer，Azure、GoogleCloud等）

当前存储环境是怎样？

对现有的存储环境的充分了解也同等重要。就拿SAN架构来说，主机装的什么操作系统、上面跑了什么应用？用的什么光纤交换机和阵列？SAN系统有多大规模、各个部分的关联性如何？随着系统规模扩大，操作复杂度将呈指数而非线性增长，所以对SAN系统的深入了解可以避免复杂度的成倍增长并规避风险。

被迁移数据的体量多大？

准确而清晰的预估迁移数据量的重要性不言而喻。必须统计具体主机、LUN和存储系统的确切数字。通常，光是从迁移多少TB的数据不足以说明迁移难度。甚至知道了有多少LUN也才是整个项目的一半，因为很可能在数据迁移完成后，才发现主机的数量是整个迁移项目在时间和难度上的致命因素。数据量和数据传输速率固然决定了迁移数据所需的绝对时间，但其他因素也不容忽视。

项目完成的时间表如何？

显而易见的问题也许并不像看起来那么简单。通常迁移的数据量是预知的，所以需要考虑的参数是数据迁移速度。这再次反映了理解数据、应用和环境的重要性，因为如果知道这些迁移的数据适合运用“分治方法（divide-and-conquer）”，那么制定迁移策略将大为受益—不仅达到时间要求，还非常有利于控制操作的复杂度从而降低成本。

数据的活跃度以及允许多少停机时间？

迁移是否能够在规定时间表完成，或者根本上能不能完成，最基本还取决于数据的活跃程度。这马上又引出另外一个问题，迁移过程中生产环境的性能受迁移影响的最大容忍度是多少？更甚者，在系统切换时生产环境允许的停机时间是多少？预先知道这些情况有助于在迁移开始之前更好的制定协议和策略，并对缓解切换时的压力带来切实可行的帮助。

如何选取合适的迁移工具？

数据迁移工具的选择对整个项目成败相当关键。而具体有哪些评判标准呢？还是拿SAN架构为例，迁移工具应该具备以下功能：

尽量减少查找每个WWPN、主机、存储target、每个LUN的GUID的需求，从而省出艰辛、冗繁和容易出错的数百小时。
无缝安装，对生产环境不产生影响，从而降低在迁移的准备和执行阶段的风险。
自动呈现清晰直观的SAN环境配置，完整呈现所涉及所有主机、LUN的标识、状态和I/O统计，从而保证迁移能精准、正确、有把握的完成。
巧妙而灵活的减小甚至避免迁移数据引入的读写对生产环境的影响。例如，能够判断在非生产时间迁移，或者能够自动应对生产流量调节迁移强度和阈值。
中央集控管理迁移的监控、报告、预警，同时也包括通常状态下的生产流量，以及系统在一些特定意义状态和统计值时的活动。
系统切换前，对中间态数据的完整性检查，在生产系统切换到新的存储前能够发现一切潜在问题。
能够在迁移成功后擦除原盘数据，尤其当原有存储需要被归还或续用时。擦除程度也因要求各不相同，有的是在特定时间范围内对擦除效率有要求，有的则是在特定安全模式下需要保证数据被安全擦除。
提供一个清楚、准确、完整的迁移报告，描述具体到每一个步骤以及每个LUN的情况。
对某种特定类型的迁移展示一系列确凿的成功案例和客户满意度反馈（比如成功案例和客户名录）。

谁能完成这个任务？

现在我们又回到最初关于“专家”的问题：不管是内部解决还是外请专业团队，对于指定的迁移类型谁最有经验，谁能够被信任？如何判断对方是否合格？那么答案很简单：他们是否能描述清楚以上所有具体的问题，还是仅仅给你几根“签”？

---End---

微信公众号平台"乐生活与爱IT"在目前阶段，主要是分享软件定义存储(SDS)，及VMware VSAN相关的文章，偶尔也会分享虚拟化、云计算、大数据，甚至生活类的好文章。欢迎投稿，我的QQ号：9269216。欢迎对SDS感兴趣的朋友，加入软件定义存储讨论 QQ群:122295009，可下载原创的一些文章，及其他有参考价值的文档。可直接搜索群号，或者扫描如下二维码：