云平台体验攻略

《新程序员》编辑部

194人浏览 · 2012-02-01 17:21:00

《新程序员》编辑部 · 2012-02-01 17:21:00 发布

《凌云》前面几篇文章介绍了几种云服务的应用场景：通过OSS几个简单的命令能搞定网站图片；通过ODPS上的几行代码，一个并行计算任务就能在云端运行。这些云服务正在切实地让传统互联网应用的研发和运营变得方便快捷，也为以数据为中心的下一代互联网应用提供了无限可能。在阿里云，形形色色的云服务都基于一个共同的云平台(本文特指“飞天”)——一套可以管理几千台服务器的分布式操作系统，一台逻辑上的“超级计算机”。现在就让我们来登上这台“计算机”，执行一些基本操作，看看云平台是如何工作的。 拥有云平台体验环境 阿里云开辟了一个可以体验云平台的地方，即由5-6台机器组成的飞天集群。只要访问阿里云官网的“云平台→开发者→体验区”，按提示走完申请流程，稍等片刻，通知邮件就会发到你的信箱，告诉你登录云平台体验环境的有效时段和控制台登录方法。 [caption id="attachment_9828" align="aligncenter" width="392" caption="图1 控制台键入me命令后的显示"]

[/caption] 这个体验环境已经为你部署好一个真实的云平台集群，规模虽小，但五脏俱全。控制台是一个Linux shell的终端，登录位置在/apsara目录下。ls一下，会发现这个目录中有很多奇怪的命令和一个Readme。先不管这些，敲一个me命令试试，结果如图1所示。从图1中可以看出，控制台机器在云平台中是什么角色，并且能看到云平台中各种重要角色master在哪些机器上。如果想知道这个云平台由几台机器构成，则可以执行以下命令获取完整的云平台集群IP列表：

$ cat /home/admin/.config_cluster/iplist 正常应该有5台机器，控制台机器到其他机器的SSH通道已经打通，你可以SSH到其他机器上，去敲个me命令，看看那台机器在承担哪些角色。到目前为止一切OK？那么，让我们开始体验之旅吧。 体验1：试用分布式存储 盘古分布式文件系统是阿里云平台的几个基础子系统之一，能提供可靠的文件读写。下面来存取一个文件试试。找一个稍微大点的普通文件，例如云中漫步的影音文件AWalkinCloud.rmvb，文件位置在/home/admin/下，在该目录下执行pu命令【注：pu是盘古对应的Client工具，存储相关的大部分操作都可以通过该命令来完成】将其存放到分布式存储空间中： $ /apsara/deploy/pu cp AWalkinCloud.rmvb pangu://localcluster/admin/AWalkinCloud.rmvb 得到输出如图2所示。 [caption id="attachment_9830" align="aligncenter" width="449" caption="图2 pu命令执行后的显示"]

[/caption] 如果没有异常提示，就是写文件成功了。写文件试过了，再来看看读文件的过程。执行以下命令，重命名原来文件，把盘古中的文件再读回本地工作目录(/home/admin)：

$ mv AWalkinClound.rmvb AWalkinCloud.rmvb.old $ /apsara/deploy/pu cp pangu://localcluster/admin/AWalkinCloud.rmvb AWalkinCloud.rmvb 用md5sum命令验证两个文件(AWalkinCloud.rmvb.old和 AWalkinCloud.rmvb)内容是否一致，应该会看到md5值相同，说明盘古存放文件内容完整正确。 [caption id="attachment_9832" align="aligncenter" width="349" caption="图3 盘古文件副本的情况"]

[/caption] 既然这是一个分布式存储，就应该有些特别之处。还是用pu看一下刚才写入的盘古文件有几份副本，并且存放在哪些机器的物理磁盘上，结果如图3所示。

$ /apsara/deploy/puadmin gfi pangu://localcluster/admin/AWalkinCloud.rmvb 从console上可以看出，这个文件被分成四个数据块(Chunk)，每块有三份副本，放在任意三台机器(存储节点)上，文件类型是NORMAL_FILE，不带压缩，Chunk分布方式是BIGFILE(即一个文件的多个数据块会尽可能随机分配在不同存储节点上)。看起来很可靠的样子。 体验2: 真的可靠吗？ 为了检验可靠性，再来执行一些疯狂的操作。任意挑选一个存储节点下线(假设IP为M1)，从控制台机器执行一个远程SSH命令停止M1机器上所有云平台相关的进程，如图4所示。 $ ssh M1 "/home/admin/aresolve/apsarad stop" [caption id="attachment_9837" align="aligncenter" width="310" caption="图4 停止M1机器上所有云平台相关的进程"]

[/caption] 如果不放心这个节点是否真的停下了，还可以用“ssh M1 ps -ef |grep apsara –i”查看是否云平台有关的所有进程都已经消失，或者运行puadmin相关命令查看注册的Chunk Server是不是减少了一个。如果想再干掉一个存储节点，同上操作即可。之后就不能再动其他机器了，因为每个数据块只有三份副本，如果把三个存储节点全部下线，意味着真的要丢数据了。重复一下体验1中pu的读文件命令，可以查看文件是否完好无损，或者再用puadmin gfi命令查看一下文件数据块的副本数和存储节点的分布情况。 [caption id="attachment_9838" align="aligncenter" width="339" caption="图5 文件数据块的副本数和存储节点的分布情况"]

[/caption] 由图5红框可以看出，在删掉两个存储节点时，有两份副本Status会出现disconnected状态。再稍等几秒钟，再看一下副本和存储节点分布情况，如图6所示。 [caption id="attachment_9839" align="aligncenter" width="338" caption="图6 几秒钟后的副本和存储节点分布情况"]

[/caption] 从图6可以看出，存储节点现在只剩两个，且盘古后台会及时恢复丢失的数据。最终每个Chunk的副本数达到2。这个小小的分布式存储到目前为止工作得还不错。实际上，在由几千台PC机构成的云平台生产环境上，因硬件故障而要下线机器会是常态，磁盘、电源、内存、网卡等均有可能发生故障，且故障的频率和位置变化也各不相同。云平台期望能够自适应这些常态故障，保证数据不会丢失，计算断点续做，其上的云服务始终可用。

体验3: 灵异事件，存储节点复活 硬件也会有灵异事件，就在几个月前，阿里云生产集群上有一台机器的网卡总是以5/10000的概率反转一个bit。让我们来想象一下，因为网卡的灵异事件，曾经停止对外响应的两台存储节点机器现在又活过来了，那么数据块的副本数目最终会有什么结果呢？在体验环境上，我们可以用以下命令来模拟刚才下线的两台存储节点活过来，其中M1和M2分别是两台存储节点的IP。 $ ssh M1 "/home/admin/aresolve/apsarad start" $ ssh M2 "/home/admin/aresolve/apsarad start" 等待5分钟后，再次执行puadmin命令检查AWalkinCloud.rmvb的副本情况，如图7所示。 $ /apsara/deploy/puadmin gfi pangu://localcluster/admin/AWalkinCloud.rmvb [caption id="attachment_9840" align="aligncenter" width="345" caption="图7 AWalkinCloud.rmvb的副本情况"]