如何将数据中心迁移到云平台

1、分析物理环境

分析环境能帮企业理清没有得到完全利用的资产，要看一下哪些应用支持虚拟化，以此为依据对应用进行分类。分类标准：基于平台、是否需要中间件、基于数据库来分类等不同的标准。对环境的测试和评估，能帮助企业准确发现哪些应用存在不支持虚拟化的可能。企业级应用一般而言都需要高CPU能量和大数据库，因此不推荐将其转入虚拟化环境。

2、整合并虚拟化服务器

服务器需求经常变动，实现整体分析，包括使用模式，确定一下计算容量，然后才可以执行物理机到虚拟机的迁移。在高峰时段或者升级时分析计算需求，这些需求会影响性能和管理。需要将服务器分离和组成。如果有应用在两个数据库运行，就得用中间件服务器或者运行多数据库的SQL服务器。整合好架构之后，要对环境进行测试，避免任何网络和存储故障，这一步完成后就可以开始虚拟化。

3、网络和存储虚拟化

分析网络和存储架构，发现可能的性能问题。针对分离和孤立网络，我们可以使用虚拟局域网配置，要把自己产品的流量和其他流量分开，确保适合的带宽利用率。在存储方面，最重要的是可扩展性。容量规划和管理的首要问题就是存储使用模式的分析。企业应该测试存储，确保能管理hypervisor负载，支撑虚拟化。企业还得观察自动化存储管理，这样做能让存储资源安排在多租户或者空中架构中，实现在不同应用中共享存储。

4、向云迁移

架构向云的迁移也需要有步骤地进行。最初可以少迁移一些关键应用和相关架构。业务关键的架构应该以之前的成功步骤为基础。确保物理产品的环境已经卸下，但不要完全退役。一旦发生任何意外，物理产品环境可以再次利用。物理环境得留着，运行那些不能虚拟化的应用和服务器。应该确保服务供应商符合行业标准，同时严格的服务水平协议（SLA）和规范的报告必不可少，而且建议做好严格的各级访问控制。

企业迁移大数据面临的五大风险

计算机系统之间的数据传输或存储格式从来就不是一个轻松的任务，特别是当它涉及结构化和非结构化的数据。芝加哥一家企业的数据解决方案提供商的联合创始人兼CEO Arvind Singh（以下简称辛格）认为，复杂的数据迁移工作意味着超负荷运行和延迟都是很长常见的。他指出，在迁移大数据时，面临着五大风险，企业应该竭力避免。

 风险1：被委托进行数据迁移项目的员工缺乏实战经验。 一个公司的员工可能非常擅长他们所做的事，但这并不意味着他们是在数据管理、迁移和治理是专家。辛格表示，他们是数据的创作者和消费者，但是他们并不是完全熟练运用工具、过程、服务、模板和加速器。 风险2：你的团队太依赖工具的开发工作。 这个问题往往导致缺乏经验的员工。一个数据迁移项目通常是IT部门的事，但可能并没被专业训练过。迁移工具使用不当最终会迁移了错误数据。这类似于把垃圾传来传去。辛格表示，你的目标，当然是快速、可靠地传输数据。重要的是你如何运用数据迁移工具和"你搭配的有什么样的加速器和模板"。 风险3：交叉对象依赖性。 交叉对象依赖常常很晚才被发现。一个复杂的项目可能会有60、70、甚至80个不同的数据对象中来自一百个左右的应用程序。事实上，交叉对象依赖性--并在后来发现新的数据来源的过程--是主要的风险，可以打乱你的迁移的时间表。 风险4：试图在一个大的上传之后去上线。 这是一个灾难，辛格说，因为你在假设一切都是完美的，你将能够简单地点击一个按钮，和所有的数据将负载得完美无瑕。 "这是个很大的风险，"他说。"你需要一个项目时间轴，复杂的，长期的测试负载的道路。" 风险5：预算超支由于不适当的范围或准备工作的欠缺。 这经常发生在，当一个组织认为它的系统集成商（SI）会照顾到这些细节时。 这个问题，当然，会导致成本超支和毁坏的时间表。

原有的大数据平台分布信息如下

需求：

将m162p133这台机器添加到大数据集群中，并重新规划大数据集群中各组件的角色。

原有的3台服务器的hosts文件如下：

修改原有的3台和新服务器的hosts文件，改为：

原来的3台服务器使用root用户可以免密钥登陆，现需要配置为4台服务器两两之间使用root用户免密钥登陆。

首先检查新增的服务器的 /root/.ssh 目录下有没有 id_rsa.pub 文件，我这里给到的新服务器存在公钥文件，如果不存在，执行以下命令，一路回车即可生成 id_rsa.pub 文件。

3台老服务器执行以下命令：

1台新服务器执行以下命令：

查看 /etc/ntp.conf ，发现m162p122服务器从外网同步时间：

m162p123与m162p124服务器从m162p122同步时间：

我的安装包解压到了 /opt/cm6.3.1 目录下

Agent已成功启动，且被Cloudera Manager识别，但还未加入集群并分配各组件的角色。

添加主机到集群：

检查完之后发现有不少警告信息，大部分是原有的三台机器的问题，我们不再处理，因为原来的大数据集群使用正常，关于新加机器的警告只有一个，Supervisord版本不兼容，注意到原来的机器也有这个警告，但大数据集群还是运行正常，于是我选择忽略这里的全部警告。

原有的服务分布如下：

迁移原则：所有的管理服务分配到m162p122节点，所有的存储或者计算节点分配到m162p123、m162p124和m162p133上

下面以zookeeper服务迁移为例来说明如何迁移各组件实例

zookeeper服务旧分布情况：

zookeeper服务迁移计划：

只需要将122的zookeeper服务迁移到133即可，先添加新服务，再卸载旧服务：

停止122上的zookeeper服务：

以上即是Cloudera Manager 6.3.1在CentOS6环境下的一次扩容记录

---