目前，云计算，大数据等概念已经深入人心。不过时至今日，云计算到底是什么，恐怕还是有很多人不知如何回答？那么，云计算又和网格计算、自主计算等有什么差异呢？本文将着重为您解析，云计算和网格计算的区别之处。
所谓云计算，在国际上的定义多达数百种，其中比较权威的应该是美国国家标准与技术研究员（NIST）的解释：云计算是一种按使用量付费的模式，这种模式提供可用的、便捷的、按需的网络访问，进入可配置的计算资源共享池（资源包括网络、服务器、存储、应用软件、服务），这些资源能够被快速提供，只需投入很少的管理工作，或与服务供应商进行很少的交互。
简单的来说，所谓云计算就是利用在Internet中可用的计算系统，能够支持互联网各类应用的系统。云计算是以第三方拥有的机制提供服务，为了完成功能，用户只关心需要的服务。
网格计算，即分布式计算，是一门计算机科学，他主要的目的是如何把一个需要非常巨大的计算能力才能解决的问题拆分成若干部分，然后把这些部分分配给多台计算机进行处理，最后汇总所有的计算结果而得出最终结果。
云计算可以说是网格计算的衍生品，能够根据需要提供资源，一般情况下，云计算采用计算机集群构成数据中心，并以服务的形势提供给客户，让客户可以像使用水、电一样按需购买资源，从这个角度来看，云计算和网格计算的目标是非常相似的。

云计算和网格计算的不同点

云计算和网格计算都是可伸缩的。可伸缩性是通过独立运行在通过Web服务连接的各种操作系统上的应用程序实例的负载平衡实现的。CPU和网络带宽根据需要分配和回收。系统存储能力根据特定时间的用户数量、实例的数量和传输的数据量进行调整。
相对于强调异构资源共享的网格计算，云计算更强调大规模资源池的分享，通过分享提高资源复用率，并利用规模经济降低运行成本；而网格计算常用于集中大量资源来执行一些大型任务。
通常，网格计算关注的是计算量非常大的操作。网格计算要求软件的使用可以分为多个部分，将程序的片段作为大的系统映像传递给几千个计算机中。这其中系统软硬件成本以及运营的成本都非常高。而相比之下，云计算需要考虑经济成本，因此硬件设备、软件平台的设计不再一味追求高性能，而要综合考虑成本、可用性、可靠性等因素。
简言之，云计算是以相对集中的资源，运行分散的应用；而网格计算则是聚合分散的资源，支持大型集中式应用。

了解更多云计算知识请登录OTPUB领先IT学习直播平台：www.otpub.com 收起阅读 »

最近研发的项目对 DB 依赖比较重，梳理了这段时间使用MySQL遇到的8个比较具有代表性的问题，答案也比较偏自己的开发实践，没有 DBA专业和深入，有出入的请使劲拍砖！
 

一、MySQL读写性能是多少，有哪些性能相关的重要参数？​

这里做了几个简单压测实验，结果如下：

机器：8核CPU，8G内存

表结构(尽量模拟业务)：12个字段(1个bigint(20)为自增primary key，5个int(11)，5个varchar(512)，1个timestamp)，InnoDB存储引擎。

实验1(写)：insert => 6000/s

前提：连接数100，每次insert单条记录

分析：CPU跑了50%，这时磁盘为顺序写，故性能较高

实验2(写)：update(where条件命中索引) => 200/s

前提：连接数100，10w条记录，每次update单条记录的4个字段(2个int(11)，2个varchar(512))

分析：CPU跑2%，瓶颈明显在IO的随机写

实验3(读)：select(where条件命中索引) => 5000/s

前提：连接数100，10w条记录，每次select单条记录的4个字段(2个int(11)，2个varchar(512))

分析：CPU跑6%，瓶颈在IO，和db的cache大小相关

实验4(读)：select(where条件没命中索引) => 60/s

前提：连接数100，10w条记录，每次select单条记录的4个字段(2个int(11)，2个varchar(512))

分析：CPU跑到80%，每次select都需遍历所有记录，看来索引的效果非常明显！

几个重要的配置参数，可根据实际的机器和业务特点调整

max_connecttions：最大连接数



table_cache：缓存打开表的数量



key_buffer_size：索引缓存大小



query_cache_size：查询缓存大小



sort_buffer_size：排序缓存大小(会将排序完的数据缓存起来)



read_buffer_size：顺序读缓存大小



read_rnd_buffer_size：某种特定顺序读缓存大小(如order by子句的查询)

PS：查看配置方法：show variables like '%max_connecttions%';
 

二、MySQL负载高时，如何找到是由哪些SQL引起的？

方法：慢查询日志分析(MySQLdumpslow)
 
慢查询日志例子，可看到每个慢查询SQL的耗时：

# User@Host: edu_online[edu_online] @  [10.139.10.167]

# Query_time: 1.958000  Lock_time: 0.000021 Rows_sent: 254786  Rows_examined: 254786

SET timestamp=1410883292;

select * from t_online_group_records;

日志显示该查询用了1.958秒，返回254786行记录，一共遍历了254786行记录。及具体的时间戳和SQL语句。

使用MySQLdumpslow进行慢查询日志分析：

MySQLdumpslow -s t -t 5 slow_log_20140819.txt

输出查询耗时最多的Top5条SQL语句
 
-s：排序方法，t表示按时间 (此外，c为按次数，r为按返回记录数等)
-t：去Top多少条，-t 5表示取前5条
 
执行完分析结果如下：

Count: 1076100  Time=0.09s (99065s)  Lock=0.00s (76s)  Rows=408.9 (440058825), edu_online[edu_online]@28hosts

  select * from t_online_group_records where UNIX_TIMESTAMP(gre_updatetime) > N

Count: 1076099  Time=0.05s (52340s)  Lock=0.00s (91s)  Rows=62.6 (67324907), edu_online[edu_online]@28hosts

  select * from t_online_course where UNIX_TIMESTAMP(c_updatetime) > N

Count: 63889  Time=0.78s (49607s)  Lock=0.00s (3s)  Rows=0.0 (18), edu_online[edu_online]@[10x.213.1xx.1xx]

  select f_uin from t_online_student_contact where f_modify_time > N

Count: 1076097  Time=0.02s (16903s)  Lock=0.00s (72s)  Rows=52.2 (56187090), edu_online[edu_online]@28hosts

  select * from t_online_video_info where UNIX_TIMESTAMP(v_update_time) > N

Count: 330046  Time=0.02s (6822s)  Lock=0.00s (45s)  Rows=0.0 (2302), edu_online[edu_online]@4hosts

  select uin,cid,is_canceled,unix_timestamp(end_time) as endtime,unix_timestamp(update_time) as updatetime 

  from t_kick_log where unix_timestamp(update_time) > N

以第1条为例，表示这类SQL(N可以取很多值，这里MySQLdumpslow会归并起来)在8月19号的慢查询日志内出现了1076100次，总耗时99065秒，总返回440058825行记录，有28个客户端IP用到。

通过慢查询日志分析，就可以找到最耗时的SQL，然后进行具体的SQL分析

慢查询相关的配置参数：

log_slow_queries：是否打开慢查询日志，得先确保=ON后面才有得分析



long_query_time：查询时间大于多少秒的SQL被当做是慢查询，一般设为1S



log_queries_not_using_indexes：是否将没有使用索引的记录写入慢查询日志



slow_query_log_file：慢查询日志存放路径

三、如何针对具体的SQL做优化？

使用Explain分析SQL语句执行计划

MySQL> explain select * from t_online_group_records where UNIX_TIMESTAMP(gre_updatetime) > 123456789;

+----+-------------+------------------------+------+---------------+------+---------+------+------+-------------+

| id | select_type | table                  | type | possible_keys | key  | key_len | ref  | rows | Extra       |

+----+-------------+------------------------+------+---------------+------+---------+------+------+-------------+

|  1 | SIMPLE      | t_online_group_records | ALL  | NULL          | NULL | NULL    | NULL |   47 | Using where |

+----+-------------+------------------------+------+---------------+------+---------+------+------+-------------+

1 row in set (0.00 sec)

如上面例子所示，重点关注下type，rows和Extra：

type：使用类别，有无使用到索引。结果值从好到坏：... > range(使用到索引) > index > ALL(全表扫描)，一般查询应达到range级别

rows：SQL执行检查的记录数

Extra：SQL执行的附加信息，如"Using index"表示查询只用到索引列，不需要去读表等

使用Profiles分析SQL语句执行时间和消耗资源：

MySQL> set profiling=1; (启动profiles，默认是没开启的)

MySQL> select count(1) from t_online_group_records where UNIX_TIMESTAMP(gre_updatetime) > 123456789; (执行要分析的SQL语句)

MySQL> show profiles;

+----------+------------+----------------------------------------------------------------------------------------------+

| Query_ID | Duration   | Query                                                                                        |

+----------+------------+----------------------------------------------------------------------------------------------+

|        1 | 0.00043250 | select count(1) from t_online_group_records where UNIX_TIMESTAMP(gre_updatetime) > 123456789 |

+----------+------------+----------------------------------------------------------------------------------------------+

1 row in set (0.00 sec)

MySQL> show profile cpu,block io for query 1; (可看出SQL在各个环节的耗时和资源消耗)

+----------------------+----------+----------+------------+--------------+---------------+

| Status               | Duration | CPU_user | CPU_system | Block_ops_in | Block_ops_out |

+----------------------+----------+----------+------------+--------------+---------------+

...

| optimizing           | 0.000016 | 0.000000 |   0.000000 |            0 |             0 |

| statistics           | 0.000020 | 0.000000 |   0.000000 |            0 |             0 |

| preparing            | 0.000017 | 0.000000 |   0.000000 |            0 |             0 |

| executing            | 0.000011 | 0.000000 |   0.000000 |            0 |             0 |

| Sending data         | 0.000076 | 0.000000 |   0.000000 |            0 |             0 |

...

SQL优化的技巧 (只提一些业务常遇到的问题)
 
1、最关键：索引，避免全表扫描
对接触的项目进行慢查询分析，发现TOP10的基本都是忘了加索引或者索引使用不当，如索引字段上加函数导致索引失效等(如where UNIX_TIMESTAMP(gre_updatetime)>123456789)

+----------+------------+---------------------------------------+

| Query_ID | Duration   | Query                                 |

+----------+------------+---------------------------------------+

|        1 | 0.00024700 | select * from mytable where id=100    |

|        2 | 0.27912900 | select * from mytable where id+1=101  |

+----------+------------+---------------------------------------+

另外很多同学在拉取全表数据时，喜欢用select xx from xx limit 5000,1000这种形式批量拉取，其实这个SQL每次都是全表扫描，建议添加1个自增id做索引，将SQL改为 select xx from xx where id>5000 and id<6000;

+----------+------------+-----------------------------------------------------+

| Query_ID | Duration   | Query                                               |

+----------+------------+-----------------------------------------------------+

|        1 | 0.00415400 | select * from mytable where id>=90000 and id<=91000 |

|        2 | 0.10078100 | select * from mytable limit 90000,1000              |

+----------+------------+-----------------------------------------------------+

合理用好索引，应该可解决大部分SQL问题。当然索引也非越多越好，过多的索引会影响写操作性能。
 
1.1 只select出需要的字段，避免select

+----------+------------+-----------------------------------------------------+

| Query_ID | Duration   | Query                                               |

+----------+------------+-----------------------------------------------------+

|        1 | 0.02948800 | select count(1) from ( select id from mytable ) a   |

|        2 | 1.34369100 | select count(1) from ( select * from mytable ) a    |

+----------+------------+-----------------------------------------------------+

1.2 尽量早做过滤，使Join或者Union等后续操作的数据量尽量小
 
1.3 把能在逻辑层算的提到逻辑层来处理，如一些数据排序、时间函数计算等
 
PS：关于SQL优化，已经有足够多文章了，所以就不讲太全面了，只重点说自己1个感受：索引！基本都是因为索引！
 

四、SQL层面已难以优化，请求量继续增大时的应对策略？

下面是我能想到的几个方法，每个方法又都是一篇大文章了，这里就不展开。

• 分库分表
• 使用集群(master-slave)，读写分离
• 增加业务的cache层
• 使用连接池

五、MySQL如何做主从数据同步？

复制机制（Replication）master通过复制机制，将master的写操作通过binlog传到slave生成中继日志(relaylog)，slave再将中继日志redo，使得主库和从库的数据保持同步。 复制相关的3个MySQL线程：[list=1]

slave上的I/O线程：向master请求数据

master上的Binlog Dump线程：读取binlog事件并把数据发送给slave的I/O线程

slave上的SQL线程：读取中继日志并执行，更新数据库

属于slave主动请求拉取的模式 实际使用可能遇到的问题数据非强一致：CDB默认为异步复制，master和slave的数据会有一定延迟(称为主从同步距离，一般 < 1s)主从同步距离变大：可能是DB写入压力大，也可能是slave机器负载高，网络波动等原因，具体问题具体分析 相关监控命令

show processlist：查看MySQL进程信息，包括3个同步线程的当前状态show master status ：查看master配置及当前复制信息show slave status：查看slave配置及当前复制信息

六、如何防止DB误操作和做好容灾？

业务侧应做到的几点：

• 重要DB数据的手工修改操作，操作前需做到2点：1 先在测试环境操作 2 备份数据
• 根据业务重要性做定时备份，考虑系统可承受的恢复时间
• 进行容灾演练，感觉很必要

 MySQL备份和恢复操作 1、备份：使用MySQLdump导出数据

MySQLdump -u 用户名 -p 数据库名 [表名] > 导出的文件名MySQLdump -uxxx -p xxx mytable > mytable.20140921.bak.sql

2、恢复：导入备份数据

MySQL -uxxx -p xxxx < mytable.20140921.bak.sql

3、恢复：导入备份数据之后发送的写操作。先使用MySQLbinlog导出这部分写操作SQL(基于时间点或位置)如导出2014-09-21 09:59:59之后的binlog：

MySQLbinlog --database="test" --start-date="2014-09-21 09:59:59" /var/lib/MySQL/mybinlog.000001 > binlog.data.sql

如导出起始id为123456之后的binlog：

MySQLbinlog --database="test" --start-position="123456" /var/lib/MySQL/mybinlog.000001 > binlog.data.sql

最后把要恢复的binlog导入db

MySQL -uxxxx -p xxxx < binlog.data.sql

七、该选择MySQL哪种存储引擎，Innodb具有什么特性？

存储引擎简介：插件式存储引擎是MySQL的重要特性，MySQL支持多种存储引擎以满足用户的多种应用场景存储引擎解决的问题：如何组织MySQL数据在介质中高效地读取，需考虑存储机制、索引设计、并发读写的锁机制等MySQL5.0支持的存储引擎有MyISAM、InnoDB、Memory、Merge等 MyISAM和InnoDB的区别(只说重点了) 1. InnoDB，MySQL5.5之后及CDB的默认引擎

• 支持行锁：并发性能好
• 支持事务：故InnoDB称为事务性存储引擎，支持ACID，提供了具有提交、回滚和崩溃恢复能力的事务安全
• 支持外键：当前唯一支持外键的引擎

 2. MyISAM，MySQL5.5之前默认引擎

• 支持表锁：插入+查询速度快，更新+删除速度慢
• 不支持事务

 使用show engines可查看当前MySQL支持的存储引擎详情：  

八、MySQL内部结构有哪些层次？

 非专业DBA，这里只简单贴个结构图说明下。MySQL是开源系统，其设计思路和源代码都出自大牛之手，有空可以学习下。 [list=1]

Connectors：连接器。接收不同语言的Client交互

Management Serveices & Utilities：系统管理和控制工具

Connection Pool: 连接池。管理用户连接

SQL Interface: SQL接口。接受用户的SQL命令，并且返回用户需要查询的结果

Parser: 解析器。验证和解析SQL语句成内部数据结构

Optimizer: 查询优化器。为查询语句选择合适的执行路径

Cache和Buffer：查询缓存。缓存查询的结果，有命中即可直接返回

Engine：存储引擎。MySQL数据最后组织并存储成具体文件

 
作者：王昂 
原文地址：https://www.qcloud.com/community/article/233  收起阅读 »

随着应用BI系统的广泛应用，数据治理的话题也越来越受到企业的关注和讨论，有专家表示，如果想让用户进入真正的商业智能时代，就必须建立一定的数据治理体系；而大数据治理能够在短期内成为业内的焦点，这和企业对大数据质量的理解和密切关注有很大关系。

大数据治理面临的挑战：规模庞大，标准不一

过去几年，企业的IT系统经历了数据量高速膨胀的一个时期，这些海量的，分散在不同服务器的数据提高了数据资源利用的复杂性和管理难度；另外，各个企业内部的业务区分和行政区分也对企业数据的交互造成了一定的断层，而企业与外部业务交互所产生的“体外循环”数据与企业的核心数据体系并不能自然地融合。当这种数据的异构化所导致的应用冲突达到一定临界点时，数据治理便成为了规范企业数据的必要步骤。

大数据治理技术：主题众多，元数据管理先行

数据治理涉及的IT技术主题众多，包括元数据管理、主数据管理、数据质量、数据集成、监控与报告等。在很多国际企业中，元数据管理的重要性在全部技术主题中位列第一。

元数据管理是语义工具，其重要性在于，它能够为数据治理建立一套数据资料库，存储治理范围内的数据定义，负责人，来源，转换关系，目标，质量等级，依赖关系，安全权限等。这些信息对于商业整合，数据质量，可审计性等数据治理目标的实现至关重要。

元数据管理是实施数据治理的核心IT技术，有效的元数据管理将为数据质量、数据集成等技术的实施，以及数据治理目标的最终实现奠定坚实的基础。

大数据治理的意义：发掘数据资产的商业价值

大数据治理是为了将数据作为企业商业资产进行应用和管理的一套数据管理机制，能够通过建立规范的数据应用标准，消除数据的不一致性，来提高数据的质量，并能合理的将数据应用于企业的业务管理和战略决策中，充分的发挥数据的商业价值，良好的数据治理必将为信息化时代的企业带来不可替代的竞争优势。
 
了解更多大数据相关知识请进入OTPUB官网：www.otpub.com 收起阅读 »

随着云、终端、移动化的快速推进，企业用户最担心的还是关于技术架构层、网络层管控等方面的难题。而通过第三方调研报告的反馈，也表明企业向公有云迁移最担心的还是安全问题。

迁移至云端面临哪些挑战？

安全、隐私和合规问题
关键任务管理或者工作负载均衡问题
数据中心迁徙至公有云可能遇到的难题
BYOD、Web 2.0应用程序、远程访问等安全隐患

面对上述难题，梭子鱼云安全解决方案都能为您化解，为用户在云环境下所运行或建立的应用或网络提供企业级安全解决方案和服务。

梭子鱼Web应用防火墙

梭子鱼Web应用防火墙，阻断以您的 Web 服务器上的应用为目标，不断涌现和复杂的基于 Web 的入侵和攻击—和保护敏感的或者机密的数据免遭窃取。

综合应用安全：
1、持续防御新兴威胁
2、可拓展的应用安全
3、细粒度身份和访问管理
梭子鱼下一代防火墙F系列
梭子鱼下一代防火墙F系列是梭子鱼防火墙的云时代。它将先进的下一代防火墙、链路平衡和 WAN 优化技术整合到一个能够进行内部部署、云和虚拟部署的易于管理的设备中。F系列允许组织和托管服务提供商安全地启用远程 Internet 分支，而无需回程流量。

下一代防火墙为公/私有云提供：
1、安全的访问 AWS
2、完整应用控制
3、智能流量管理
4、细粒度安全策略管理

梭子鱼始终为用户在云环境下所运行、建立的应用或网络提供企业级安全解决方案和服务。
企业迁移至云端面临的安全、隐私及合规问题如何解决？梭子鱼如何利用 Web 防火墙化解企业数据迁移至云端难题？答案尽在8月22日14:00由OTPUB举行的“梭子鱼云安全解决方案”线上直播活动。
 
点击后方字体进入直播间：“梭子鱼云安全解决方案” 收起阅读 »

近日，境内外多家安全公司爆料称NetSarang旗下Xmanager和Xshell等产品的多个版本被植入后门代码,由于相关软件在国内程序开发和运维人员中被广泛使用，可能导致大量用户服务器账号密码泄露。请及时检查您所使用的版本是否受影响，并采取安全防御措施。
 

影响范围

使用了nssock2.dll 5.0.0.26的版本会受到影响，其中包括：

•  Xmanager Enterprise 5.0 Build 1232
•  Xmanager 5.0 Build 1045
•  Xshell 5.0 Build 1322
•  Xshell 5.0 Build 1325
•  Xftp 5.0 Build 1218
•  Xlpd 5.0 Build 1220

 

修复方案

 1、从官网下载最新版本进行升级：https://www.netsarang.com/download/software.html  ； 2、排查2017年的DNS访问日志，如出现如下子域名相关访问记录，建议修改对应员工使用过Xmanager 、XShell、Xftp等相关的登录账号密码：

• vwrcbohspufip.com
• ribotqtonut.com
• nylalobghyhirgh.com
• jkvmdmjyfcvkf.com
• bafyvoruzgjitwr.com
• xmponmzmxkxkh.com
• tczafklirkl.com

 

漏洞详情

某安全公司发现NetSarang的Xmanager, Xshell, Xftp, Xlpd等产品中，发布的nssock2.dll模块中存在恶意代码远程漏洞，存在后门的XShell等程序会在启动时发起大量请求DNS域名请求，并根据使用者系统时间生成不同的请求链接。有媒体报道，带后门的Xshell会向服务器传输敏感信息。
 
参考链接：https://www.netsarang.com/news/security_exploit_in_july_18_2017_build.html  。 收起阅读 »

说到营销科技（MarTech）很多人可能都不太熟悉，但你一定了解，谷歌90%的收入来自广告、北美企业每年营收的12%用于营销和广告。而今年，企业的营销部门在信息技术方面的投入，即将超过传统企业信息化投入的总和，营销科技蕴含着巨大的市场空间。
虽然数字营销在国内尚处早期，以单点解决方案为主，但Convertlab跨过单点解决方案，直接提供平台服务。
Convertlab为企业提供创新的数字营销平台——DM Hub。该平台允许企业的数字营销部门在一个开放集成的平台上发掘、培育和连接客户，大幅提升各项转化率；打通企业的营销触点，对数据采集并处理，针对不同触点提供相应的内容交互能力，允许企业对客户旅程进行个性化设计和自动化执行，通过实时的数据分析形成营销闭环。
Convertlab是一款颠覆传统营销思维和运行模式的产品，是企业开展数字化营销时信息交互的枢纽，这也正是DM Hub的寓意和使命。
DM Hub 它能够将一家企业包括数字广告在内的全渠道数据来源进行梳理整合，对每个数据进行分析，将之进行归类分组，从中挖掘出指向企业不同营销阶段的客户：潜在客户、意愿客户、购买客户、忠诚客户等，并采用智能化、人性化的方式将企业市场部设计的对策营销方案传达给各个目标客户。
想要了解什么是营销科技（MarTech）？数字营销又是如何成为了企业发展的焦点？敬请关注8月10日由OTPUB举办的“企业营销的数字化转型”线上直播活动，与您分享新时代的数字变革之路。
点击预约观看直播：“企业营销的数字化转型” 收起阅读 »

随着VMWARE虚拟机的应用越发广泛，如何基于VMWARE虚拟机实现备份恢复的话题也越来越受到大家的关注，包括系统层的，数据库层的，以及应用层的（或者应用集群环境）需要备份或者恢复。而基于VMWARE应用环境的备份恢复，基本都是通过一个模式来实现：备份软硬件通过Proxy备份恢复。
不管是CV、Networker、NBU等主流备份软件，还是像Veeam、Avamar这种软硬件结合的产品，都是通过架设Proxy对接VMWARE来实现备份。
对于VMWARE上VM，IMAGE级别备份恢复，IMAGE TO FILE-LEVEL恢复，基本主流软硬件表现基本不相上下。
对于VMWARE上的数据库、文件系统还是应用的备份恢复，与备份软硬件备份恢复物理机上的数据库、文件系统还是应用如出一辙。
关于VMWARE备份恢复的解决思路，（如果项目允许的情况下）可以从下面几方面考虑：
1，备份恢复并行能力
通常Proxy的并行能力都是有限的，很多时候建设初期一台Proxy能够胜任备份需求，后续VMWARE系统迅猛增长，Proxy就无法承受了备份压力。因此，考虑VMWARE的备份产品时一定要重点考虑其并行效率。
关于提高并行效率，方式很多，例如AVAMAR这种基于强大硬件+消重算法的产品，将备份恢复的压力转移到备份产品上，其自身支持多节点部署；例如VEEAM这种软件产品，通过和VMWARE深度结合，加上自己特有的智能算法技术，依靠自身类似VM扩展能力，也能大幅提高并行能力。
2，备份恢复负载均衡与集群结构
在备份系统上，备份系统的负载均衡也尤为重要，一旦出现BUSY-IDLE的情况，影响也是连带的传递的。在虚拟化备份上，随着生产系统的扩展，VMWARE规模必然越来越大，扩展速度也越来越快，若备份系统无法实现良好的负载均衡，那最终只能越来越慢。同时备份系统最好支持集群结构，一方面保证自身的扩展能力，另一方面也能提供整体负载能力。
3，更好更多的特性
产品更好更多的特性会带来很多便捷。虚拟化备份产品的新特性，也带来一些改变，需要虚拟机上的数据不一定需要恢复VM，而直接通过备份数据虚拟出VM然后读取需要的生产数据；生产VM能迅速复制、虚拟到VLAB里进行测试，不再需要一台一台部署……
虽然说了这么多，VMWARE备份系统建设成什么样，最重要的决定因素还是---项目资金，并没有一个万能通用的方案，只有项目资金能承受、性能够用的折中解决方案。

更多关于VMWARE虚拟机资讯请登录：www.otpub.com 收起阅读 »

软件定义数据中心（SDDC）是根据硬件和软件的抽象而提出的一种将数据中心作为由软件层控制和管理的大量物理和虚拟资源的全新的方式。然而，很多企业在实际实施SDDC的过程中或多或少的遇到了一些安全问题。

使用SDDC虚拟化服务器、网络和存储，安全是阻止企业使用完全成熟的软件定义数据中心的主要障碍。虽然SDDC的发展趋势被普遍看好，例如增加采用率和更快的部署将显著提高采用率，但软件定义数据中心将面临更多地数据泄露问题。
向完全虚拟化的基础设施的过渡是渐进的，没有人期望能在短期内实现虚拟化。软件定义数据中心（SDDC）、软件定义基础设施（SDI）、软件定义网络（SDN）和软件定义存储（SDS）都是企业的长期战略目标。然而大多数的企业将使用自上而下的方法实施，即从SDDC和SDI开始，而不是自下而上的从SDN和SDS开始。
根据Gartner对2018年的预测，这种大规模部署SDDC也可能引起广发的数据安全管理计划，20%的企业认为这是非常有必要的，可以有效防止数据泄露。TMC的执行编辑Paula Bernier在最近的一篇文章中指出，根据Gartner的预测，到2020年SDDC将被认为是实现DevOps方法和混合云模型的全球2000家企业中75%的企业的需求。
  收起阅读 »

由于成本的降低和业务的便捷性，越来越多的企业将自己的IT系统迁移到云端，而在迁移的过程中，从基础设施的部署到云平台的挑战都十分的具有挑战性，在迁移过程中，企业IT管理着最需要重视的一个问题就是：如何保证云迁移的安全，减少迁移风险。
为了降低向云端迁移的风险，保证数据的安全性，OTPUB认为企业可以通过下面三种方法着手策划数据向云的迁移。 
第一种方法是指将本地硬件或虚拟机上的数据迁移到与之相匹配的云上。该解决方案缺乏弹性，该方案通常是为了满足峰值负载而过度供应，这就会导致了云计算成本的增加，因此这种方法作为一种短期解决措施会更佳。
第二种方法是指对企业的应用技术进行重新架构。数据迁移需要花费一定时间，而且具有较强的强制性，而对企业技术进行重新架构反而会获得更好的性能。的确，重新对应用技术的选择进行评估也不失为一种更好的选择。因为企业可能会将一些解决方案从使用昂贵的商业软件转向开源产品上来。
第三种方法是搁置单一的本地应用程序，将程序内部数据迁移到SaaS。这种方法既实现了业务的现代化标准，又将基础架构和服务的运营负担转嫁给了SaaS提供商。
以上三种方法可以让企业在最佳情况下完成数据由本地向云端的迁移，同时最大限度的保证了迁移过程中数据的安全性。 收起阅读 »

在很多时候，我们利用VMware创建虚拟机做实验，我们一般都是需要多台主机的，这时候我们可以基于已经创建好的系统进行克隆。但是克隆之后我发现一个问题，那就是克隆出来的主机的网卡信息还是母机的信息，比如mac地址、UUID，而且会出现一块新网卡的信息，比如母机只有eth0网卡信息，而克隆出来的会多出eth1网卡的信息，但是实际克隆出来的主机也只有一块物理网卡eth0,下面我们就说说做可以让克隆出来的主机网卡信息正常，然后配置静态ip地址或者通过DHCP获取ip地址正常工作。
 

1、修改udev规则文件获取Mac地址

/etc/udev/rules.d/70-persistent-net.rules 这个文件跟你的网卡mac地址有关系，当你的网卡启动的时候这个文件会分配一个网卡名称给你的网卡。
 

# vim /etc/udev/rules.d/70-persistent-net.rules

• 该文件中正常此时应该有两行信息
• 在文件中把 NAME="eth0″ 的这一行注释掉
• 对于另一行，把 NAME=”eth1″ 的这一行，把 NAME=”eth1″ 改为 NAME=”eth0″，并且把该行：ATTRS{address}=="00:0c:29:58:0d:5a″ 这个属性信息记下来,后面修改Mac地址就使用这个。

 

2、修改eth0网卡Mac地址配置

为什么要修改，因为跟克隆母机的Mac地址一样，在同一个内网内会冲突，修改前：

# vim /etc/sysconfig/network-scripts/ifcfg-eth0

把 HWADDR 的值改为上面要求记下来的：00:0c:29:58:0d:5a

到这里网卡的Mac地址已经修改完成，跟母机的不一样了，这样就不会冲突了。
 

3、获取并修改UUID

维基百介绍UUID：
通用唯一识别码（英语：Universally Unique Identifier，简称UUID）是一种软件建构的标准，亦为自由软件基金会组织在分散式计算环境领域的一部份。

UUID的目的，是让分散式系统中的所有元素，都能有唯一的辨识信息，而不需要通过中央控制端来做辨识信息的指定。如此一来，每个人都可以创建不与其它人冲突的UUID。在这样的情况下，就不需考虑数据库创建时的名称重复问题。目前最广泛应用的UUID，是微软公司的全局唯一标识符（GUID），而其他重要的应用，则有Linux ext2/ext3文件系统、LUKS加密分区、GNOME、KDE、Mac OS X等等。另外我们也可以在e2fsprogs包中的UUID库找到实现。
 
获取UUID：获取UUid我们可以通过两种方式，1是通过uuidgen命名，二是通过读取文件/proc/sys/kernel/random/uuid
 
我们这里功能uuidgen命名获取：

# a=`uuidgen eth1`

# sed -i "s@UUID.*@UUID=${a}@g"  ifcfg-eth0

到这里就Mac地址和UUID都全部替换完成，跟母机的完全不一样了。
 

4、重启网卡获取IP地址

# /etc/init.d/network restart

如上图可以看出获取IP地址正常，Mac地址也是我们修改后的，好了到这里就都完成了，完成后，方便后面实验，最好新建的主机都创建初始的快照。 收起阅读 »