原文链接：https://mp.weixin.qq.com/s/JpKWp3pGH-8yfOSwaeLYgg

随着互联网科技的不断进步，产生的数据将以成倍速度进行增长，据IDC预测，到2025年全球数据总量将会达到175ZB。如果要把175ZB用8TB的磁盘存下来的话，那就需要230亿块磁盘来存储这些数据，如果每块磁盘的成本是1300元，那要完整存储这些数据，就需要付出30万亿的存储硬件成本投入，相当于国内一年生产总值的三分之一。

逐步攀升的数据存储需求和高昂存储成本的冲突下，很多企业都将面临着大量数据无法得到有效存储和数据流失的问题。对此，UCloud存储产品经理周恭元在10月23日刚结束的TIC2020技术分论坛上带来了《海量数据云归档存储最佳实践》的议题分享，围绕企业数据归档面临的存储问题及需求，重点介绍了数据存储的分层价值，以及UCloud新一代归档存储的可靠性优势及三大适用场景。本文整理自演讲内容，供大家参考学习。

传统归档存储面临的两个问题

首先，周恭元分享了今年疫情特殊时期碰到的两个公司的遭遇。

第一件事情，大约4月份的时候，某电商公司一个做DBA的朋友来咨询我，本地硬盘已经删除了的文件有没有办法恢复？我便产生了一些疑问，为什么数据库运维要管这些呢？后来详细聊了下事情的原委，才知道他们公司由于设置了30天的数据库日志备份策略，但是正好碰上这次疫情休假时间超过了一个月，导致一些年前的数据库日志数据已经被删除了。究其原因，根本的问题还是由于公司为了节约成本，使本地归档存储的空间有限造成的。

第二件事情，某传统企业申报项目的核心数据存储在公司内网的共享文件中，而内网网盘数据与外网不通，导致他们不得不在疫情相对严重的时期，还需要专门派人去公司将所需的数据拷出来，浪费了大量精力，同时也存在外出感染疫情的风险。

从这两件事情，不难看出传统数据归档存储确实存在着两个问题：一是本地存储空间的限制，二是数据交互的不便。而这也正是如今有越来越多的用户开始选择云存储进行数据归档的原因。

ZB级数据需要做“冷热”处理

随着数据的量级从MB、GB增长到PB、EB甚至ZB级别，就会产生一个很实际的问题，就是企业存储能力的提升已经远远跟不上数据的增长速度。预计到2025年，全球175ZB的数据最终将会流失超过90%。而对企业来说，这流失的90%数据正是需要被长期存储下来存在价值的数据。

一方面是大量数据无法得到有效的存储，另一方面这些真正被存储下来的数据又面临什么样的情况呢？

通过分析用户存放在UCloud公有云对象存储的数据访问量可以发现，数据在单位时间内的请求数（我们也称之为数据热度），是会随着时间的推移不断降低的，也就是说绝大多数据在半年之后都会成为冷数据。然而实际上，大部分用户还是将这些冷数据存放在与刚写入这些数据时相同的存储类型中，造成了大量不必要的成本支出。

针对这样的问题，UCloud最早在2017年就推出了第一代归档存储产品，2019年针对对象存储产品的不同存储类型做了统一，提供了三种不同的存储类型，单价上由热至冷，存储成本分别为标准存储的一半与四分之一。这样一来，用户就可以实现在同一个存储空间里借助生命周期策略自动对数据进行降冷处理，从而优化存储成本。

新一代归档存储，突破成本极限

在今年8月份UCloud发布了最新一代归档存储产品，成为了国内率先采用JBOD磁盘阵列与SMR叠瓦式磁盘介质提供公有云归档存储服务的云厂商。在具备分钟级别取回时效、11个9以上数据可靠性的归档存储产品中，突破了传统3分钱每GB每月的定价区间，达到了0.024元每GB每月，可以进一步降低20%的成本。

大家知道存储成本主要由硬件、运营成本构成。UCloud新一代归档存储在国内首次采用西部数据的高密JBOD设备和SMR盘，SMR盘全名为叠瓦式磁记录硬盘，相较于传统CMR硬盘，最大区别是，磁道按Zone呈现的叠瓦式分布，这种分布可以以更高密度存储数据。与36盘传统机型相比，引入JBOD设备统一管理硬盘并采用高密度SMR盘：单位机架的存储容量提升5.375倍，硬盘数量增加59%，单块硬盘存储空间提升150%。同时借助磁盘休眠的技术，可以降低90%的硬盘能耗。

在降低成本的同时，新一代归档存储自研的全新架构也带来了更高的可靠性保障，通过双机头的故障快速切换，能在数据取回快速的同时提供极高的可用性保障；通过采用Intel大比例纠删码冗余策略，归档存储提供了同时4块硬盘故障情况下的数据可靠性保障，由于归档存储读取请求较小的缘故，新一代归档存储还引入了定期的一致性校验应对磁盘的静默错误，以保障数据一致性。

归档存储的三大场景

通过前面的介绍，不难看出归档存储比较适用于一些写大于读的数据存储场景，这类数据和以往对云存储广泛适用的读大于写的场景正好相反，因此归档存储的应用场景往往是一些已经经过在线处理或者应用的在线数据的近线存储。由于是近线存储，数据是具备分钟级的取回时效，这和需要数个小时甚至按天取回的离线存储相比会有更高的实时性。

再结合客户的实际使用，我们可以将归档存储的核心场景汇总为三类，分别为多媒体数据归档、历史数据合规性归档以及大数据、AI分析数据的归档。

视频归档场景

由于近几年实时音视频场景的普及，在线教育和培训、远程医疗、视频会议、娱乐直播需求层出不穷。借助于UCloud实时音视频服务提供的强大的覆盖能力，可以实现用户的就近接入，提供网络低延迟、低丢包率的音视频实时通信。

但也正是因为实时音视频服务的普及，政策监管也逐渐规范化，合规性要求成为了实时视频业务场景中不可或缺的一个环节。目前不仅泛娱乐直播类平台通常对直播视频有6个月的合规性归档要求，在线教育、在线医疗也有了更长时间的历史视频归档的合规性要求。

通过与URTC实时音视频业务的无缝接入，UCloud归档存储在此次疫情期间帮助了多家在线教育、在线医疗用户实现了实时音视频与历史记录归档的无缝衔接，用户仅需在每次RTC服务结束后选择保存视频，即可将视频记录进行归档。不仅简洁易用，无需额外操作；更在降低存储成本的同时易于归档视频的访问调取。

数据库、日志备份场景

一直以来，数据库和日志的备份问题困扰着许多电商用户。通常情况下，中小规模的电商公司的整套服务架构都在云上，如果给云主机绑定硬盘用来进行备份，会面临单点故障的问题，而这些中小企业又没有能力自己定制数据备份，将数据备份至别的存储类型中。

对此，UCloud提供了灵活的数据库备份组件和针对ES集群的备份接入能力，帮助用户可以快速将MySQL数据库直接备份至归档存储中，省去了备份到本地再上传的复杂过程。归档存储同时具备ES集群的接入能力，能够帮助用户将历史日志定时进行云归档，为用户保留更长时间的日志记录。

UCloud通过帮助客户进行归档方式改造，降低了数家电商公司的数据备份成本，延长备份周期，简化操作流程，大大降低了用户数据丢失恢复及历史日志追溯的难度。

大数据归档场景

针对大数据分析场景，UCloud对象存储服务提供了Hadoop集群的接入工具，甚至在存储性能上媲美HDFS。过去用户往往受制于本地HDFS集群的存储空间，所以将分析后的原始数据丢弃，损失了大量数据价值。通过云归档的方式将大数据分析后留下的大量数据样本和分析结果进行长期存储，再通过提供的Hadoop集群的接入工具，就能实现将历史数据激活后，直接在云端进行大数据分析，不用担心数据二次取回的本地存储空间压力。

企业也可以更灵活、弹性地应对数据爆炸带来的存储空间压力，按3年期投入计算，更是比本地搭建相同规模的HDFS集群降低80%以上的成本投入。

写在最后

英国数学家Clive Humby曾说过，数据是数字时代的新石油，尽管数据本身很有价值，但数据需要处理，就像石油需要在其真正价值被解锁之前需要精炼一样。石油是一种有限的资源，而数据却是可重复使用的。对于企业而言，积累数据就是积累原始财富，在有分析能力的情况下可以进一步提炼数据背后的商业价值，UCloud新一代归档存储正是为这些海量数据归档存储提供高可靠、低成本解决方案的重要基石。

---

淄博诚立信息技术有限公司

致力于协助中小企业单位搭建升级信息化基础架构

主营：服务器，网络设备，安全、备份软件，虚拟化实施等。

原文链接：https://www.oschina.net/news/119240/linux-operating-system-market-2027?from=20201018

《Fortune Business Insights》的一份报告表明，2019 年全球 Linux 操作系统的市场规模为 38.9 亿美元；预计到 2027 年，Linux 市场规模将达到 156.4 亿美元，在预测期内复合年增长率为 19.2%。

现如今，几乎所有行业都受到了新冠冲击，Linux 自然也不例外。不过鉴于其开源特性，Linux 在帮助软件开发者和科学家遏制疫情方面也起到了至关重要的作用。因此尽管受疫情影响，该报告还是大胆预测称，Linux 市场将继续以强劲的年增长率增长，直到 2027 年。

报告指出，Linux 操作系统的增长主要得益于互联网普及性的提高及全球数据中心和服务器数量的增加。其中，Linux 系统在游戏领域的应用就是一个关键的推动因素。同时，Linux 还在被一些大公司应用于不同的工业领域，而这些领域产品应用的也将促进 Linux 市场的增长。还有就是基于 Linux 的云平台，凭借优良的速度、可靠性和成本被很多工业部门和应用使用。

研究表明，企业并购的数量不断增加也是推动 Linux 增长的一大因素。当下的全球市场趋势已发生了许多有趣的变化。一份报告显示，美国 Linux 市场的规模为 6.755 亿美元，而且势必会有更大的增长，其次则是欧洲市场。

除了欧洲市场外，报告预测亚太地区市场在预测期内的复合年增长率将最高。其中，韩国、中国、日本、印度等国家由于存在大量基于 Linux OS 的数据中心，预计将对整体增长做出很大贡献。目前，亚太地区共有 400 多个数据中心；包括中国的 79 个、日本 47 个、韩国 19 个、印度 100 个以及新加坡的 26 个等等。

且互联网使用量的增长也促进了中东国家、拉丁美洲以及欧洲的德国、西班牙、意大利等地区的增长。

此外，该报告还指出，Facebook 、Arch Linux、Canonical、ClearCenter、Debian、Elementary、IBM、Amazon Web Services 等公司也将为 Linux OS 的增长创造机会。

---

淄博诚立信息技术有限公司

致力于协助中小企业单位搭建升级信息化基础架构

主营：服务器，网络设备，安全、备份软件，虚拟化实施等。

原文链接：https://mp.weixin.qq.com/s/ViMufVA7o0P8_oGX8bRZ1A

全球领先的信息技术研究和顾问公司Gartner于今日发布企业机构在2021年需要深挖的重要战略科技趋势。分析师们在本周举行的Gartner IT Symposium/Xpo大会美洲站虚拟会议上展示了自己的发现。

Gartner研究副总裁Brian Burke表示：“各企业职能部门对运营韧性的需求从未像现在这样强烈。首席信息官们正在努力适应不断变化的情况，设计未来的业务。这就需要企业机构具有不断重组与改革的可塑性。Gartner 2021年重要战略科技趋势可实现这种可塑性。

“企业机构正在从应对新冠疫情转向推动增长，因此它们必须关注形成今年主流趋势的三个主要领域：以人为本、位置独立性和韧性交付。这些趋势在组合后的整体影响大于它们各自的独立影响，并且专注于满足全球各地的社会与个人需求来实现最佳交付。”

2021年重要战略科技趋势具体如下：

行为互联网（Internet of Behaviors）

行为互联网（IoB）不断涌现，许多技术都在捕获并使用人们日常生活中的“数字尘埃”。IoB汇集了面部识别、位置跟踪和大数据等当前直接关注个人的技术，并将结果数据与现金购买或设备使用等相关的行为事件相关联。

企业机构使用该数据来影响人的行为。例如为了在疫情期间监控对健康规定的遵守情况，企业机构可以通过使用IoB计算机视觉来查看员工是否戴着口罩或通过热成像来识别发热者。

Gartner预测，到2025年末，全球一半以上的人口将至少参加一项商业或政府的IoB计划。虽然IoB在技术上可成为可能，但社会各界将对各种影响行为的方法展开广泛的伦理和社会学讨论。

全面体验（Total Experience）

Burke表示：“去年，Gartner将多重体验定义为一种重要的战略科技趋势。而在今年，这一趋势又进一步发展成为全面体验（TX），将多重体验与客户、员工和用户体验相联系。Gartner预计在未来三年中，提供TX的企业机构在关键满意度指标方面的表现将超越竞争对手。”

由于新冠疫情，移动、虚拟和分布式互动日益盛行，因此企业机构需要有TX策略。TX将改善体验的各个组成部分，实现业务成果的转型。这些相互交织的体验是企业运用创新革命性体验实现差异化，从而从疫情中恢复的关键驱动力。

隐私增强计算（Privacy-Enhancing Computation）

随着全球数据保护法规的成熟，各地区首席信息官所面临的隐私和违规风险超过了以往任何时候。不同于常见的静态数据安全控制，隐私增强计算可在确保保密性或隐私的同时，保护正在使用的数据。

Gartner认为，到2025年将有一半的大型企业机构使用隐私增强计算在不受信任的环境和多方数据分析用例中处理数据。企业机构应在开始确认隐私增强计算候选对象时，评估要求个人数据转移、数据货币化、欺诈分析和其他高度敏感数据用例的数据处理活动。

分布式云（Distributed Cloud）

分布式云将公有云分布到不同的物理位置，但服务的运营、治理和发展依然由公有云提供商负责。它为具有低延迟、降低数据成本需求和数据驻留要求的企业机构方案提供了一个灵活的环境，同时还使客户的云计算资源能够更靠近发生数据和业务活动的物理位置。

到2025年，大多数云服务平台至少都能提供一些可以根据需要执行的分布式云服务。Burke先生认为：“分布式云可以取代私有云，并为云计算提供边缘云和其他新用例。它代表了云计算的未来。”

随处运营（Anywhere Operations）

随处运营是一种为全球各地客户提供支持、赋能全球各地员工并管理各类分布式基础设施业务服务部署的IT运营模式。它所涵盖的不仅仅是在家工作或与客户进行虚拟互动，还能提供所有五个核心领域的独特增值体验，分别是：协作和生产力、安全远程访问、云和边缘基础设施、数字化体验量化以及远程运营自动化支持。

到2023年末，40%的企业机构将通过随处运营提供经过优化与混合的虚拟/物理客户与员工体验。

网络安全网格（Cybersecurity Mesh）

网络安全网格使任何人都可以安全地访问任何数字资产，无论资产或人员位于何处。它通过云交付模型解除策略执行与策略决策之间的关联，并使身份验证成为新的安全边界。到2025年，网络安全网格将支持超过一半的数字访问控制请求。

Burke先生认为：“新冠疫情加快了耗时数十年的数字化企业变革过程。我们已经越过了一个转折点，大多数企业机构的网络资产现在都已超出传统的物理和逻辑安全边界。随着随处运营的不断发展，网络安全网状组网将成为从非受控设备安全访问和使用云端应用与分布式数据的最实用方法。”

组装式智能企业（Intelligent Composable Business）

Burke先生表示：“为了提高效率而建立的静态业务流程非常脆弱，因此在疫情的冲击下变得支离破碎。首席信息官和IT领导者正在努力收拾残局，他们开始了解适应业务变化速度的业务能力有多么重要。”

智能组合型业务通过获取更好的信息并对此做出更敏锐的响应来彻底改变决策。依靠丰富的数据和洞见，未来的机器将具有更强大的决策能力。智能组合型业务将为重新设计数字化业务时刻、新业务模式、自主运营和新产品、各类服务及渠道铺平道路。

人工智能工程化（AI Engineering）

Gartner的研究表明，只有53%的项目能够从人工智能（AI）原型转化为生产。首席信息官和IT领导者发现，由于缺乏创建和管理生产级人工智能管道的工具，人工智能项目的扩展难度很大。为了将人工智能转化为生产力，就必须转向人工智能工程化这门专注于各种人工智能操作化和决策模型（例如机器学习或知识图）治理与生命周期管理的学科。

人工智能工程化立足于三大核心支柱：数据运维、模型运维和开发运维。强大的人工智能工程化策略将促进人工智能模型的性能、可扩展性、可解释性和可靠性，完全实现人工智能投资的价值。

超级自动化（Hyperautomation）

业务驱动型超级自动化是一项可用于快速识别、审查和自动执行大量获准业务和IT流程的严格方法。在过去几年中，超级自动化一直在持续不断地发展。而因为疫情，一切事物都被突然要求首先实现数字化，这大大增加了市场的需求。业务利益相关者所积压的需求已促使70%以上的商业机构实施了数十种超级自动化计划。

Burke先生表示：“超级自动化是一股不可避免且不可逆转的趋势。一切可以而且应该被自动化的事物都将被自动化。”

---

淄博诚立信息技术有限公司

致力于协助中小企业单位搭建升级信息化基础架构

主营：服务器，网络设备，安全、备份软件，虚拟化实施等。

---

淄博诚立信息技术有限公司

致力于协助中小企业单位搭建升级信息化基础架构

主营：服务器，网络设备，安全、备份软件，虚拟化实施等。

虚拟机根分区空间不够用，在虚拟机管理界面进行单个磁盘扩展（图形化界面操作略），比如原来是30G，扩展至40G，（扩展需要关机之后操作）

其中的10G空间需要重新分区，以下是分区相关操作让扩展的空间生效：

登录系统之后：

df -h  发现空间没有发生变化：

[root@lub ~]# df -h

Filesystem            Size  Used Avail Use% Mounted on

/dev/mapper/VolGroup-lv_root

                       25G   19G  4.2G  82% /

tmpfs                 642M     0  642M   0% /dev/shm

/dev/sda1             485M   34M  426M   8% /boot

fdisk -l   发现总容量已经扩展。

[root@lub ~]# fdisk -l

Disk /dev/sda: 42.9 GB, 42949672960 bytes

255 heads, 63 sectors/track, 5221 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk identifier: 0x00069f1c

——————————

对扩展的磁盘进行分区：

[root@lub ~]# fdisk /dev/sda

WARNING: DOS-compatible mode is deprecated. It’s strongly recommended to

         switch off the mode (command ‘c’) and change display units to

         sectors (command ‘u’).

Command (m for help): p  

Disk /dev/sda: 42.9 GB, 42949672960 bytes

255 heads, 63 sectors/track, 5221 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk identifier: 0x00069f1c

   Device Boot      Start         End      Blocks   Id  System

/dev/sda1   *           1          64      512000   83  Linux

Partition 1 does not end on cylinder boundary.

/dev/sda2              64        4047    31992832   8e  Linux LVM

Command (m for help): n

Command action

   e   extended

   p   primary partition (1-4)

3

Invalid partition number for type `3′

Command action

   e   extended

   p   primary partition (1-4)

p

Partition number (1-4): 3

First cylinder (4047-5221, default 4047): 

Using default value 4047

Last cylinder, +cylinders or +size{K,M,G} (4047-5221, default 5221): 

Using default value 5221

Command (m for help): p ——-查看分区后的情况

Disk /dev/sda: 42.9 GB, 42949672960 bytes

255 heads, 63 sectors/track, 5221 cylinders

Units = cylinders of 16065 * 512 = 8225280 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk identifier: 0x00069f1c

Device Boot      Start         End      Blocks   Id  System

/dev/sda1   *           1          64      512000   83  Linux

Partition 1 does not end on cylinder boundary.

/dev/sda2              64        4047    31992832   8e  Linux LVM

/dev/sda3            4047        5221     9431826+  83  Linux

—新增的sda3

Command (m for help): w  保存分区

The partition table has been altered!

Calling ioctl() to re-read partition table.

WARNING: Re-reading the partition table failed with error 16: Device or resource busy.

The kernel still uses the old table. The new table will be used at

the next reboot or after you run partprobe(8) or kpartx(8)

Syncing disks.

[root@lub ~]#

——————–使用命令发现partprobe /dev/sda3发现分区并没有起作用：

[root@lub ~]# partprobe /dev/sda3

Error: Could not stat device /dev/sda3 – No such file or directory.

    [root@lub ~]# pvcreate /dev/sda3

    Device /dev/sda3 not found (or ignored by filtering).

—–重启系统。

  ——LVM操作。扩展根分区

[root@lub ~]# pvcreate /dev/sda3

  Physical volume “/dev/sda3” successfully created

[root@lub ~]# vgs

  VG       #PV #LV #SN Attr   VSize  VFree

  VolGroup   1   2   0 wz–n- 30.51g    0 

[root@lub ~]# vgextend VolGroup /dev/sda3

  Volume group “VolGroup” successfully extended

[root@lub ~]# vgs

  VG       #PV #LV #SN Attr   VSize  VFree

  VolGroup   2   2   0 wz–n- 39.50g 8.99g

[root@lub ~]# lvextend -L +8.99G /dev/mapper/VolGroup-lv_root 

  Rounding size to boundary between physical extents: 8.99 GiB

  Extending logical volume lv_root to 33.50 GiB

  Logical volume lv_root successfully resized

[root@lub ~]# resize2fs /dev/mapper/VolGroup-lv_root 

resize2fs 1.41.12 (17-May-2010)

Filesystem at /dev/mapper/VolGroup-lv_root is mounted on /; on-line resizing required

old desc_blocks = 2, new_desc_blocks = 3

Performing an on-line resize of /dev/mapper/VolGroup-lv_root to 8781824 (4k) blocks.

The filesystem on /dev/mapper/VolGroup-lv_root is now 8781824 blocks long.

—-命令操作根分区情况，发现已经生效：

[root@lub ~]# df -h

Filesystem            Size  Used Avail Use% Mounted on

/dev/mapper/VolGroup-lv_root

                       33G   19G   13G  60% /

tmpfs                 642M     0  642M   0% /dev/shm

/dev/sda1             485M   34M  426M   8% /boot

[root@lub ~]# 

    完成扩展

通过linux自带的bond技术实现linux双网卡绑定和负载均衡

绑定的前提条件：芯片组型号相同，而且网卡应该具备自己独立的BIOS芯片

一、建立虚拟网络接口ifcfg-bond0文件

[root@jason ~]# cd /etc/sysconfig/network-scripts/

[root@jason network-scripts]# cp ifcfg-eth0 ifcfg-bond0

其内容为：

[root@jason network-scripts]# more ifcfg-bond0

# Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet

DEVICE=bond0

BROADCAST=10.0.0.255

IPADDR=10.0.0.3

NETMASK=255.255.255.0

NETWORK=10.0.0.0

MTU=1500

GATEWAY=10.0.0.1

[root@jason network-scripts]#

二、编辑原有网卡eth0和eth信息文件

使其内容为：

[root@jason network-scripts]# more ifcfg-eth0

# Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet

DEVICE=eth0

BOOTPROTO=none

ONBOOT=yes

TYPE=Ethernet

MASTER=bond0

slave=yes

[root@jason network-scripts]# more ifcfg-eth1

# Broadcom Corporation NetXtreme II BCM5708 Gigabit Ethernet

DEVICE=eth1

BOOTPROTO=none

ONBOOT=yes

TYPE=Ethernet

MASTER=bond0

slave=yes

[root@jason network-scripts]#

三、编辑/etc/modprobe.conf加入下面两行

[root@jason network-scripts]# vi /etc/modprobe.conf

alias bond0 bonding

options bond0 miimon=100 mode=1

说明：miimon是用来进行链路监测的。 比如:miimon=100，那么系统每100ms监测一次链路连接状态，如果有一条线路不通就转入另一条线路；mode的值表示工作模式，他共有0，1,2,3四种模式，常用的为0,1两种。 

mode=0表示load balancing (round-robin)为负载均衡方式，两块网卡都工作。 

mode=1表示fault-tolerance (active-backup)提供冗余功能，工作方式是主备的工作方式,也就是说默认情况下只有一块网卡工作,另一块做备份. 

bonding只能提供链路监测，即从主机到交换机的链路是否接通。如果只是交换机对外的链路down掉了，而交换机本身并没有故障，那么bonding会认为链路没有问题而继续使用 

加入后我的modprobe.conf内容为：

[root@jason network-scripts]# more /etc/modprobe.conf

alias eth0 bnx2

alias eth1 bnx2

alias scsi_hostadapter aacraid

alias scsi_hostadapter1 ata_piix

alias peth0 bnx2

alias bond0 bonding

options bond0 miimon=100 mode=1

四、编辑/etc/rc.d/rc.local文件，加入

ifenslave bond0 eth0 eth1

重新启动后，负载均衡就能正常工作了，可以用ifconfig查看具体信息

[root@jason network-scripts]# ifconfig

bond0 Link encap:Ethernet HWaddr 00:1A:64:6A:55:98

inet addr:10.0.0.3 Bcast:10.0.0.255 Mask:255.255.255.0

inet6 addr: fe80::21a:64ff:fe6a:5598/64 Scope:Link

UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1

RX packets:985369 errors:0 dropped:0 overruns:0 frame:0

TX packets:804306 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:0

RX bytes:148943796 (142.0 MiB) TX bytes:2097755332 (1.9 GiB)

eth0 Link encap:Ethernet HWaddr 00:1A:64:6A:55:98

inet6 addr: fe80::21a:64ff:fe6a:5598/64 Scope:Link

UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1

RX packets:984133 errors:0 dropped:0 overruns:0 frame:0

TX packets:804292 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:0

RX bytes:148805154 (141.9 MiB) TX bytes:2097751381 (1.9 GiB)

eth1 Link encap:Ethernet HWaddr 00:1A:64:6A:55:98

inet6 addr: fe80::21a:64ff:fe6a:5598/64 Scope:Link

UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1

RX packets:1236 errors:0 dropped:0 overruns:0 frame:0

TX packets:16 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:1000

RX bytes:138642 (135.3 KiB) TX bytes:4275 (4.1 KiB)

Interrupt:16 Memory:ca000000-ca011100

通过查看bond0的工作状态查询能详细的掌握bonding的工作状态 

[root@redflag bonding]# cat /proc/net/bonding/bond0 

bonding.c:v2.4.1 (September 15, 2003) 

Bonding Mode: load balancing (round-robin) 

MII Status: up 

MII Polling Interval (ms): 0 

Up Delay (ms): 0 

Down Delay (ms): 0 

Multicast Mode: all slaves 

Slave Interface: eth1 

MII Status: up 

Link Failure Count: 0 

Permanent HW addr: 00:0e:7f:25:d9:8a 

Slave Interface: eth0 

MII Status: up 

Link Failure Count: 0 

Permanent HW addr: 00:0e:7f:25:d9:8b 

以下是网上找的文档

Linux双网卡绑定实现就是使用两块网卡虚拟成为一块网卡，这个聚合起来的设备看起来是一个单独的以太网接口设备，通俗点讲就是两块网卡具有相同的IP地址而并行链接聚合成一个逻辑链路工作。其实这项 技术在Sun和Cisco中早已存在，被称为Trunking和Etherchannel技术，在Linux的2.4.x的内核中也采用这这种技术，被称为bonding。bonding技术的最早应用是在集群——beowulf上，为了提高集群节点间的数据传输而设计的。下面我们讨论一下bonding 的原理,什么是bonding需要从网卡的混杂(promisc)模式说起。我们知道，在正常情况下，网卡只接收目的硬件地址(MAC Address)是自身Mac的以太网帧，对于别的数据帧都滤掉，以减轻驱动程序的负担。但是网卡也支持另外一种被称为混杂promisc的模式，可以接收网络上所有的帧，比如说tcpdump，就是运行在这个模式下。bonding也运行在这个模式下，而且修改了驱动程序中的mac地址，将两块网卡的Mac地址改成相同，可以接收特定mac的数据帧。然后把相应的数据帧传送给bond驱动程序处理。 

说了半天理论，其实配置很简单，一共四个步骤： 

实验的操作系统是Redhat Linux Enterprise 3.0 

绑定的前提条件：芯片组型号相同，而且网卡应该具备自己独立的BIOS芯片。

1.编辑虚拟网络接口配置文件,指定网卡IP 

vi /etc/sysconfig/ network-scripts/ ifcfg-bond0 

[root@redflag root]# cp /etc/sysconfig/network-scripts/ifcfg-eth0 ifcfg-bond0 

2 #vi ifcfg-bond0 

将第一行改成 DEVICE=bond0 

# cat ifcfg-bond0 

DEVICE=bond0 

BOOTPROTO=static 

IPADDR=172.31.0.13 

NETMASK=255.255.252.0 

BROADCAST=172.31.3.254 

ONBOOT=yes 

TYPE=Ethernet 

这里要主意，不要指定单个网卡的IP 地址、子网掩码或网卡 ID。将上述信息指定到虚拟适配器(bonding)中即可。 

[root@redflag network-scripts]# cat ifcfg-eth0 

DEVICE=eth0

USERCTL=no

BOOTPROTO=none

ONBOOT=yes

MASTER=bond0

SLAVE=yes

[root@redflag network-scripts]# cat ifcfg-eth1 

DEVICE=eth1

USERCTL=no

BOOTPROTO=none

ONBOOT=yes

MASTER=bond0

SLAVE=yes

3 # vi /etc/modules.conf 

编辑 /etc/modules.conf 文件，加入如下一行内容，以使系统在启动时加载bonding模块，对外虚拟网络接口设备为 bond0 

加入下列两行 

alias bond0 bonding 

options bond0 miimon=100 mode=1 

说明：miimon是用来进行链路监测的。 比如:miimon=100，那么系统每100ms监测一次链路连接状态，如果有一条线路不通就转入另一条线路；mode的值表示工作模式，他共有0，1,2,3四种模式，常用的为0,1两种。 

mode=0表示load balancing (round-robin)为负载均衡方式，两块网卡都工作。 

mode=1表示fault-tolerance (active-backup)提供冗余功能，工作方式是主备的工作方式,也就是说默认情况下只有一块网卡工作,另一块做备份. 

bonding只能提供链路监测，即从主机到交换机的链路是否接通。如果只是交换机对外的链路down掉了，而交换机本身并没有故障，那么bonding会认为链路没有问题而继续使用 

4 # vi /etc/rc.d/rc.local 

加入两行 

ifenslave bond0 eth0 eth1 

route add -net 172.31.3.254 netmask 255.255.255.0 bond0 

route add -net 192.168.228.0 netmask 255.255.255.0 gw 192.168.228.153 dev eth0

#service network restart

到这时已经配置完毕重新启动机器. 

重启会看见以下信息就表示配置成功了 

……………. 

Bringing up interface bond0 OK 

Bringing up interface eth0 OK 

Bringing up interface eth1 OK 

……………. 

下面我们讨论以下mode分别为0,1时的情况 

mode=1工作在主备模式下,这时eth1作为备份网卡是no arp的 

[root@redflag network-scripts]# ifconfig 验证网卡的配置信息 

bond0 Link encap:Ethernet HWaddr 00:0E:7F:25:D9:8B 

inet addr:172.31.0.13 Bcast:172.31.3.255 Mask:255.255.252.0 

UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1 

RX packets:18495 errors:0 dropped:0 overruns:0 frame:0 

TX packets:480 errors:0 dropped:0 overruns:0 carrier:0 

collisions:0 txqueuelen:0 

RX bytes:1587253 (1.5 Mb) TX bytes:89642 (87.5 Kb) 

eth0 Link encap:Ethernet HWaddr 00:0E:7F:25:D9:8B 

inet addr:172.31.0.13 Bcast:172.31.3.255 Mask:255.255.252.0 

UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1 

RX packets:9572 errors:0 dropped:0 overruns:0 frame:0 

TX packets:480 errors:0 dropped:0 overruns:0 carrier:0 

collisions:0 txqueuelen:1000 

RX bytes:833514 (813.9 Kb) TX bytes:89642 (87.5 Kb) 

Interrupt:11 

eth1 Link encap:Ethernet HWaddr 00:0E:7F:25:D9:8B 

inet addr:172.31.0.13 Bcast:172.31.3.255 Mask:255.255.252.0 

UP BROADCAST RUNNING NOARP SLAVE MULTICAST MTU:1500 Metric:1 

RX packets:8923 errors:0 dropped:0 overruns:0 frame:0 

TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 

collisions:0 txqueuelen:1000 

RX bytes:753739 (736.0 Kb) TX bytes:0 (0.0 b) 

Interrupt:15 

那也就是说在主备模式下,当一个网络接口失效时(例如主交换机掉电等),不回出现网络中断,系统会按照cat /etc/rc.d/rc.local里指定网卡的顺序工作,机器仍能对外服务,起到了失效保护的功能. 

在mode=0 负载均衡工作模式,他能提供两倍的带宽,下我们来看一下网卡的配置信息 

[root@redflag root]# ifconfig 

bond0 Link encap:Ethernet HWaddr 00:0E:7F:25:D9:8B 

inet addr:172.31.0.13 Bcast:172.31.3.255 Mask:255.255.252.0 

UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1 

RX packets:2817 errors:0 dropped:0 overruns:0 frame:0 

TX packets:95 errors:0 dropped:0 overruns:0 carrier:0 

collisions:0 txqueuelen:0 

RX bytes:226957 (221.6 Kb) TX bytes:15266 (14.9 Kb) 

eth0 Link encap:Ethernet HWaddr 00:0E:7F:25:D9:8B 

inet addr:172.31.0.13 Bcast:172.31.3.255 Mask:255.255.252.0 

UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1 

RX packets:1406 errors:0 dropped:0 overruns:0 frame:0 

TX packets:48 errors:0 dropped:0 overruns:0 carrier:0 

collisions:0 txqueuelen:1000 

RX bytes:113967 (111.2 Kb) TX bytes:7268 (7.0 Kb) 

Interrupt:11 

eth1 Link encap:Ethernet HWaddr 00:0E:7F:25:D9:8B 

inet addr:172.31.0.13 Bcast:172.31.3.255 Mask:255.255.252.0 

UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1 

RX packets:1411 errors:0 dropped:0 overruns:0 frame:0 

TX packets:47 errors:0 dropped:0 overruns:0 carrier:0 

collisions:0 txqueuelen:1000 

RX bytes:112990 (110.3 Kb) TX bytes:7998 (7.8 Kb) 

Interrupt:15 

在这种情况下出现一块网卡失效,仅仅会是服务器出口带宽下降,也不会影响网络使用. 

通过查看bond0的工作状态查询能详细的掌握bonding的工作状态 

[root@redflag bonding]# cat /proc/net/bonding/bond0 

bonding.c:v2.4.1 (September 15, 2003) 

Bonding Mode: load balancing (round-robin) 

MII Status: up 

MII Polling Interval (ms): 0 

Up Delay (ms): 0 

Down Delay (ms): 0 

Multicast Mode: all slaves 

Slave Interface: eth1 

MII Status: up 

Link Failure Count: 0 

Permanent HW addr: 00:0e:7f:25:d9:8a 

Slave Interface: eth0 

MII Status: up 

Link Failure Count: 0 

Permanent HW addr: 00:0e:7f:25:d9:8b 

Linux下通过网卡邦定技术既增加了服务器的可靠性,又增加了可用网络带宽,为用户提供不间断的关键服务。用以上方法均在redhat的多个版本测试成功,而且效果良好.心动不如行动，赶快一试吧！

最近碰到有问4块网卡如何配置2个bond网卡，测试了一下，配置方法略微有点不 

同，主要是modprobe.conf里的配置：

1、ifcfg-bondX的配置和单个bond的配置没有区别；

2、修改modprobe.conf有2种修改方法：

a)当2个或者多个bond网卡的所有参数（即bonding模块的参数，如mode、miimon 

等）都相同时，加载bonding模块时设置 max_bonds参数即可。如max_bonds=2时， 

加载bonding驱动之后可以创建2个bond网卡bond0，bond1，修改后的 

modprobe.conf和下面的情形类似：

…

alias bond0 bonding

alias bond1 bonding

options bond0 miimon=100 mode=1 max_bonds=2

…

b)当2个或者多个bond网卡的参数（即bonding模块的参数，如mode、miimon等）不 

同时，需要在加载bonding模块时修改模块的名称（文档中的说法是linux的模块加 

载系统要求系统加载的模块甚至相同模块的不同实例都需要有一个唯一的命名）， 

修改后的modprobe.conf和下面的情形类似：

…

alias bond0 bonding

options bond0 -o bond0 miimon=100 mode=0

alias bond1 bonding

options bond1 -o bond1 miimon=150 mode=1

…

（说明：使用 -o 选项在加载模块对模块进行重命名）

目前我只在DC5SP2上测试通过，其它版本并没有测试，内核的版本不同系统对 

bonding模块的支持可能也有不同。

详细的文档参见内核文档/usr/src/linux-x.x.x- 

xx.x/Documentation/networking/bonding.txt。

上午测试的时候修改modprobe.conf之后只是重启了network服务，所以当时以为第 

二种方法也是生效了的。不过实际上，重启network 服务时，并没有卸载bonding 

模块。当手动卸载bonding模块或者系统重启之后，网络服务启动的时候会报错， 

说-o不是有效的选项。

重新看了一下文档，里面也提到了这个问题，所以modprobe.conf的修改还需要调 

整一下，不再使用alias,options的格式，而使用下面的格式：

…

install bond0 /sbin/modprobe –ignore-install bonding -o bond0 

miimon=100 mode=0

install bond1 /sbin/modprobe –ignore-install bonding -o bond1 

miimon=100 mode=1

…

我也稍微修改了一下原来配置bond的脚本，基本可以用了。不过感觉我改完之后脚 

本已经有点繁琐了，大家看一下。

1.华为网络设备

1.1华为交换机

S系列和E系列交换机（S1700除外）可以通过Console口、telnet、web网管、bootrom菜单等方式登录设备。

这些登录方式的缺省密码如下：

1. console口/telnet登录密码：

V200R009及之前版本，使用console口/telnet首次登录设备时没有缺省密码，首次登录时的界面会提示用户配置console口/telnet登录密码

V200R010-V200R012版本，使用console口/telnet首次登录设备时缺省的用户名为admin 密码为admin@huawei.com

2. web登录密码：

a. 对于S系列交换机以下版本：V1R3C00、V1R5C01、V1R6C00、V1R6C03、V2R1C00、V2R2C00，缺省的用户名为admin 密码为admin

b. 对于S系列交换机以下版本：V1R6C05、V2R3C00及之后版本，缺省的用户名为admin 密码为admin@huawei.com

c. 对于E系列和S600-E系列交换机，缺省的用户名为admin 密码为admin@huawei.com

3. bootrom密码：

a. 对于S系列盒式交换机，V100R006C03之前的版本，BootROM默认密码为huawei；在V100R006C03及之后的版本，默认密码为Admin@huawei.com

b. 对于S系列框式交换机在V100R006C00及之前的版本，BootROM默认密码为9300；在V100R006C00之后的版本，默认密码为Admin@huawei.com

c. 对于E系列和S600-E系列交换机，默认密码为Admin@huawei.com

1.2华为防火墙

防火墙设备出厂后，缺省可以通过G0/0/0接口来登录web界面，接口缺省地址是：192.168.0.1,（登录地址：https://192.168.0.1:8443）

web缺省用户名/密码：admin/Admin@123

Console缺省用户名/密码：admin/Admin@123

BootRom缺省密码：O&m5213

1.3华为路由器

2华为服务器

BIOS默认密码：Huawei12#$

iBMC默认用户名/密码：root/Huawei@12#$ (缺省登录地址：192.168.2.100)

3华为存储

A控制器默认登录端口：H4

A控制器默认登录地址：https://192.168.128.101:8088

A控制器默认登录用户名/密码：admin/Admin@storage

串口CLI登录：初次登录无密码（串口速率：115200）

---

淄博诚立信息技术有限公司

致力于协助中小企业单位搭建升级信息化基础架构

主营：服务器，网络设备，安全、备份软件，虚拟化实施等。

快照可能会影响虚拟机性能，且不支持某些磁盘类型或使用总线共享配置的虚拟机。快照作为短期解决方案用于捕获时间点虚拟机状况很有用，但不适用于长期虚拟机备份。
VMware 不支持对裸磁盘、RDM 物理模式磁盘或在客户机中使用 iSCSI 启动器的客户机操作系统的快照。
在执行快照之前必须关闭具有独立磁盘的虚拟机的电源。不支持具有独立磁盘的已打开电源或已挂起的虚拟机的快照。
PCI vSphere Direct Path I/O 设备不支持快照。
VMware 不支持为总线共享配置的虚拟机的快照。如果需要使用总线共享，则作为备用解决方案，请考虑在客户机操作系统中运行备份软件。如果虚拟机当前具有快照，并阻止您配置总线共享，请删除（整合）这些快照。
快照提供备份解决方案可以使用的磁盘的时间点映像，但快照不是备份和恢复的可靠方法。如果包含虚拟机的文件丢失，则其快照文件也丢失。另外，大量快照将难于管理，占用大量磁盘空间，并且在出现硬件故障时不受保护。
快照可能会对虚拟机的性能产生负面影响。性能降低基于快照或快照树保持原位的时间、树的深度以及执行快照后虚拟机及其客户机操作系统发生更改的程度。另外，还可能会看到打开虚拟机电源所花费的时间变长。不要永久从快照运行生产虚拟机。
如果虚拟机具有的虚拟硬盘容量大于 2TB，则完成快照操作将远远需要更加长的时间。

2020 年 4 月 16 日

上个月，我针对新冠肺炎发表了看法，在这一非常时期，“正常办公”并不可行。此后的几周，疫情发展迅速，一些地区的感染率有所下降，而其他地区则达到了大流行病的高峰期。

无论您身在何处，我们都面临着同样的压力，经受着同样的痛苦。我们中的许多人失去了至亲，痛惜不已；我们共同应对这一挑战，学习如何更好地照顾孩子、年迈的父母、朋友和邻居，如何更好地维护社区的健康。

显然，这需要我们长期奋战，没办法一蹴而就。我们将因这次的共同经历而彻底改变，我相信，我们将团结一致，以不同的视角处理关键领域的问题，包括如何工作、学习、照顾病人和维持社区运行。

在我看来，我们将经历三个阶段。第一个阶段为验伤：当时间紧迫时立即作出反应，即采取紧急行动，帮助最需要帮助的人。第二个阶段是接受新常态，我们正在打破陈旧的认知，采用更有效和更有人情味的运营方式。第三个阶段是新机遇，我们将在医疗卫生、教育和工作等领域推动系统和结构上的变革，以求变得更好。

在这场疫情之中，我比以往任何时候都更加坚信，我们拥有足够的毅力、勇气和智慧，能够共同渡过难关。人们竭尽所能解决紧急需求，寻找可行的解决方案。这大大小小的众多事迹令人振奋。世界各地的 VMware 员工主动帮助疫情前线的人们，这让我深受鼓舞。

典型案例：过去几周，VMware 的全球员工团队创造了一款解决方案，使世界各地的企业和个人能够更加简便地将他们的闲置 GPU 和 CPU 周期贡献给 Folding@Home 项目，该项目是一个关键计划，可帮助研究人员了解代表新冠肺炎等疾病的蛋白质错误折叠。 

Resource19 也同样令我振奋，这是由 VMware 员工发起的一项全新的非营利计划，该计划将个人防护设备 (PPE) 供应商网络与有相关需求的医院联系起来，形成全球网络。自从两周前启动以来，该网络已经为 2,000 位用户提供了服务，帮助他们运送了 50,000 个口罩和 4,000 个面罩，提供了 40 种用于医疗设备和零件的开源设计。同样，来自 VMware India 的团队向班加罗尔的 Rajiv Gandhi Hospital of Chest Diseases 提供了 10,000 个防护口罩，为长期轮班治疗新冠肺炎患者的医院工作人员提高了防护水平。

同样具有影响力的是客户的创新变革事迹。Vanderbilt University Medical Center 最近将一个空置的停车场改造成了其成人医院急需的新冠肺炎筛查区，VMware 团队也积极参与其中。在俄亥俄州，位居最大规模之列的州医疗系统使用 VMware 广域网 (SD-WAN) 服务实现快速扩展和交付，在该州的偏远地区建立了弹出式新冠肺炎测试诊所。全球各地的政府机构都在使用我们的数字化工作空间解决方案来提高其移动团队的能力，确保不间断地提供关键服务，如医疗卫生、公共安全、水、电、垃圾收集等。在 VMware，我们已经提供了多年的业务连续性解决方案，在我们对技术的依赖程度越来越高的今天，看到这些解决方案所发挥的基础性作用，我们感到非常欣慰。

我喜欢这些事迹，因为它们体现了我们在危机时期的团结应对。作为一个全球性社区，我们聪慧、有同情心且资源强大。跨越国界，做出成果是我们的本能。我们克服重重阻碍，寻找各种方法，将解决方案直接提供给最需要的人。

这些品质将帮助我们度过这个异常艰巨的时期。当这场疫情过去，这些价值观将推动我们不断前进。 

此致，

Pat