10年前，我们实施服务器虚拟化

大概是2006年，我们实施集中存储，就是用集中的磁盘柜子来代替各个单台服务器的硬盘，实现存储资源的共享和集中管理。

大概是2008年，我们实施服务器的虚拟化，当时请了高校（川大、电子科大）的博导们作为专家来评审方案，他们也是初次接触这个新东西，很认真地看了方案，给予了支持，认为这是发展方向。我们在系统内率先实现了服务器虚拟化。

国内某大机构的分支机构的IT负责人来考察了我们的虚拟化后，也实施并上报了总部，总部将其作为样板也在其系统内全面推广。

我们将方案资料上报了我们的总部，几年后，总部组织系统内全面推广。

10几年过去了，这些技术早已成熟得不得了了，成长为为各种私有云和公有云了。

把当时写给用户的科普文复制在下面：

信息系统，是由许多硬件和软件（操作系统、应用系统）组成的。

但是，这种组成，现在是“一家一户”的。

例如，在公司里，服务器A用于“财务会计”，服务器B用于“人力资源”，服务器C用于“客户关系”，服务器D于“产品管理”，服务器E于“技术研发”，等等，硬件资源是被这些业务系统软件所独占的。

当然，也可以“财务会计”与“人力资源资”成立一个“互助组甲”，它俩共享服务器A，而“客户关系”与“产品管理”成立一个“互助组乙”，它俩共享服务器B，当然，也可以将它们全部组织在一个“互助组”里，共享一台服务器，等等。

但是，“互助组”的成员一般要采用相同的操作系统，假设“客户关系”采用Windows2000，而“技术研发”采用Linux、Unix或Aix，二者是难以“互助”的。

但“互助组”毕竟规模小了点，处理能力和存储能力有限，一旦业务扩大，资源不够用就要被“撑爆”，就得购买新的服务器，而原有的服务器，还不好处理，怎么利用呢？而且，就得在购买服务器时有比较好的预测，如果买小了很快不够用了，又要换新的不划算，如果买大了一时用不上很快就贬值了也不划算。另外，难免要停止运行或者夜间和节假日加班，将软件移植到新硬件上，这就会造成业务的停顿，持续性差，也辛苦。

于是，人们采用专门技术，来实现更大范围的硬件资源的共享、分配和扩展，并保持业务的连续。

人们把服务器ABCD组织起来，成立一个服务器“合作社”，它们的CPU联合成“CPU联合体”，它们的内存联合成“内存联合体”，网卡联合成“网卡联合体”，硬盘联合成“硬盘联合体”（集中存储）。

然后，把这些联合起来的资源，统一地有计划地分配给“财务会计”、“人力资源”、“客户关系”、“产品管理”、“技术研发”等业务系统。

此时，“财务会计”、“人力资源”、“客户关系”、“产品管理”、“技术研发”等，已经不再与单个的具体的服务器ABCDE直接联系——已经“合作化”了，使用的是公共的资源。

如果客户增加了，“客户关系”就需要更多的处理时间更大的存储空间更多的资源，要在原来，就得购买新的服务器，或者，和与之“互助”的“产品管理”分家，各自使用一台服务器，而“产品管理”可能又不需要太多的资源，还要移植软件，这很麻烦。

而现在，只需要通过管理员，从“合作社”的各个“联合体”里，为“客户关系”多划分一些CPU和集中存储就OK了。对“产品管理”则少划分一些。“各尽所能按需分配”！

如果，又有“办公自动化”了，那就从“合作社”里分配适当的资源给它。也许，随着业务的增长，各个业务系统需要更多的资源，现有的资源已经不够了，这时，才需要购进新的资源——服务器及其CPU、内存、网卡、集中存储，将它们加盟到“合作社”里去，而该退役的资源则从“合作社”里撤出，用作测试设备或开发设备，停顿时间短。

还有更重要的，如果，“合作社”中的CPU、内存，网卡和存储，有部分发生故障了，不要紧，因为它们加入了“合作社”，是在“联合体“里面，有保障的，它们的工作将由其它的CPU、内存，网卡，集中存储去承担，如果“合作社“和“联合体“规模大，集体力量大，个别设备发生故障根本无所谓，可以在适当的时候（节假日）再修理它们，不会停顿而影响业务；如果“合作社“和“联合体“规模不大，集体力量不大，也不会停顿而严重影响业务，但是需要及时修理。

这就是“资源池化“，是对资源的最优配置，也体现了”团队精神“。

这就是“虚拟机”软件技术，它把下层不同的硬件都屏蔽了，且支持不同的操作系统，给操作系统统一提供虚拟的硬盘、内存、CPU、网卡、等等。而且，有集中统一的管理系统。

曾经在IBM的某个中心看过，几十台巨大的服务器，一个美女管理，资源是自动负载均衡的，有时也需要“人工干预”，某业务需要较多的资源时，美女就用鼠标这么一拖动，给它增加一点内存、一些CPU处理时间。