my2005lb的专栏

　　最近有个项目，要写一个后台监控脚本，自动对指定的进程进行监控．功能就是配置待监测进程队列，每隔5秒钟，检查这些进程还存不存活，不存活则启动之．　　工作到不是很难．　　程序的流程大体分为：　　1．运行从配置文件中读取待监测的进程队列，包括的基本信息是进程名，程序所在路径．　　2．获得当前Linux系统下进程列表　　3．将待监测的进程队列一一匹配当前的进程列表，若存在，则忽

近期为一些用户培训Hadoop技术，最近也有一些同事、网友开始向我咨询这一方面的问题，很多初学者很难理清Hadoop到底是什么，甚至Hadoop与虚拟化、云计算的关系。　　这里给出一个渐进式的学习与进阶方案：　　（１）先搭建一个单节点的 Hadoop平台，先将那些疑问放一边，先去学习如何搭建这个平台；　　（２）尝试用Hadoop管理各类文件，尝试将数据存放于其非关系型数据库中，尝试

看了很多的所谓自主创新，越来越觉得称之为自主实现比较合适，创新以我的理解应该是世界首创，如果国外已经实现，然后借助于资料或者其他手段打听到对方的功能如何，性能如何，再进行的开发功能或性能上比人多一个或一个，实现应不能归于创新一类，只能称之为自主实现，因为你没有承担第一个吃螃蟹的风险。　　这里之所以较这个真，主要是那些所谓的自主创新的“内行们”别忽悠人家外行，人都不傻，最后砸的是大家的名声与饭碗

在Linux下编写应用平台经常会面临编写各类配置文件，这里给出一种编写XML格式配置文件的编程方法。这段代码是基于libxml2库，通过调用库里面的相关函数生成各个配置节点，并保存配置文件：　　相关代码如下：　　#include #include #include int main(int argc, char **argv){ xmlDocPtr xmlDoc

当前市面上多种虚拟化平台在支撑着各类用户的各种基础数据中心，有时候比较幸运用户统一虚拟化平台，如仅依赖于vmware，当然也面临其他用户同时混合多种虚拟化平台搭建自己的数据中心。不同的虚拟化平台存在对于用户来讲是福音，至少有了货比三家的机会；但对于开发者来讲，并不一定是好事，至少同样的功能针对不同的虚拟化平台要重新实现一遍。       当前流行的针对虚拟化的二次开发，要么是调用平台对外提供的

越来越多的用户选择虚拟化数据中心做为支撑本单位下一步基础设施运营，这里给出通用型的虚拟化数据中心架构，这种模式应能够应用当前绝大多数用户场景（支撑100至2000虚拟主机）。      整个架构分为服务器、统一存储、数据中心网络、数据中心软件平台，下面分别介绍各自的实施原则：     （1）服务器：由标准机架服务器组成计算节点，节点上安装虚拟化软件（ESX、XEN、KVM等），形成一个

大批量的虚拟主机管理应依赖于标准的虚拟主机模板，这样即能方便部署，也方便资源最佳配比，下面给出几种虚拟主机制备标准：　（1）CPU数目：1CPU、2CPU、4CPU、8CPU、16CPU；　（2）内存数目：2G、4G、8G、16G、32G；　（3）磁盘：默认5GB、10GB、20G系统安装磁盘（windows\Linux\solaris)，其他磁盘以外挂的方式体现，外挂的标准以每10G

KVM平台以存储池的形式对存储进行统一管理，所谓存储池可以理解为本地目录、通过远端磁盘阵列（iSCSI、NFS）分配过来磁盘或目录，当然也支持各类分布式文件系统。     通过virsh中pool命令能够查看、创建、激活、注册、删除存储池。     下面通过一些实例演示如何管理存储池：     一、查看当前存储池列表[root@kvm02 kvmcontrol]# virs

从事云计算有一段时间了，自己算是比较完整的参与了一个规模不太大的相对高层的云计算数据中心规划、设计、实施、调试、运维等各项工作，做的越多做的越久，慢慢也开始有了一些感悟，下面写点经验（非无病呻吟型经验）： 一、国内外云的差距   　　我一直认为国内外云的差距最重要的不是技术，接触了国内外顶级的各大厂商、接触了国内外从事数据中心业务的各家企业、自己也干了一段时间了，越发坚定这个信念，

写研究性论文，一般要遵循一种固定套路，这个套路经过近几年的亲历，觉得为一条线串六个点。　　即以研究问题为主线，以背景、现状、意义、方法、实验、结论为主要节点。   　研究问题极为重要，做研究性论文时最容易犯的毛病是研究问题不清楚，或者心里有，但描述不清。这其实背后是说明对这个问题的研究还是不透，没有完全深入进去。这可能得需要在相关领域再看几十篇文章，再思考思考，或者上手搞几次实验，做的多了

1.2.1 环境准备环境由三台服务器组成，分别为目录节点，内容节点，服务器列表如下所示：表１  主机环境准备IP机器名称10.0.0.201m1.hadoop10.0.0.209s1.hadoop10.0.0.211s2.hadoop下

对12306来讲，是困难也是机遇，如果通过成功的解决这样的访问量，对于相关技术人员将是一种前所未有的成就感，本人一直从事技术工作，回家订票也是犯难，高并发压力这个是业界难题，想从技术方面进行根本解决，当前比较有效的就是分布式计算模式，但是这种对现在软件体系变革比较大，特别是一些采购、维护以及研发模式并不太适合于部委级现有信息化体制；     对于当前铁路客票系统，我思考了几天，觉得可以基于现有

1.1.1 环境准备本次由一台centos虚拟服务器搭建hadoop平台，机器信息如表１所示：       表１  主机环境准备名称信息IP10.1.1.20hostnameMaster.hadoop       为方便使用，现给出主机环境方面需要修改的地方：