2013年12月3日星期二

搭建自己的XenServer+CloudStack云平台,提供IaaS服务(一)环境搭建

目标

搭建一个完整的基于XenServerCloudStack的虚拟化平台,提供IaaS服务。
  • 搭建三台安装了XenServer的服务器
  • 搭建一台安装了CloudStack的服务器用以管理云平台
  • 搭建一个NFS服务器负责进行存储工作
  • 可以使用CloudStack云平台进行虚拟机管理

先期准备

服务器准备

  • 三台服务器安装XenServer
  • 一台安装CentOS和CloudStack进行管理
  • 一台安装CentOS和NFS服务负责存储
  • 一台HTTP服务器公共,用来进行模板,iso下载等支持

需要准备的各种安装包

然后使用工具软件将iso文件刻录成光盘或者启动U盘。

环境准备

IP地址分配:
机器名: XS1 系统:XenServer IP地址:192.168.100.61
机器名: XS2 系统:XenServer IP地址:192.168.100.62
机器名: XS3 系统:XenServer IP地址:192.168.100.63
机器名: NFS 系统:CentOS6.2 IP地址:192.168.100.64
机器名: MGR 系统:CentOS6.2 IP地址:192.168.100.65
虚拟机地址分配:
虚拟机地址分配池使用192.168.7.X地址段

安装NFS服务器

安装操作系统

安装CentOS操作系统到服务器,插入光盘,选择默认安装。

配置服务器名称

默认的服务器名为localhost,可以修改/etc/hosts文件来更换服务器名。将etc/hosts添加下面的语句
192.168.100.64 nfs
12.0.0.1 localhost nfs

配置服务器的SELinux

SELinux是一个linux下的安全模块,具体说明见这里,我们这里需要将SELinux打开,需要执行如下指令。
setenforce permissive
为确保其持久生效需更改配置文件/etc/selinux/config,设置为permissive,修改或添加配置文件的内容,添加上下面两句话。
SELINUX=permissive
SELINUXTYPE=targeted

安装NTP服务

NTP服务是一个时间服务,最好所有服务器都有个统一的时间管理,所以需要安装NTP服务。
yum install ntp
service ntpd start

配置NFS服务

首先,安装NFS服务
yum install nfs-utils
建立挂载点目录。使用root建立,为了方便,讲目录权限设置为777
mkdir /primary
mkdir /secondary
修改/etc/exports文件,建立挂载点信息,在文件中添加如下两行
/primary *(rw,async,norootsquash)
/secondary *(rw,async,norootsquash)
配置防火墙信息,允许NFS访问权限,修改/etc/sysconfig/iptables,添加如下内容
-A INPUT -s 192.168.100.0/24 -m state --state NEW -p udp --dport 111 -j ACCEPT
-A INPUT -s 192.168.100.0/24 -m state --state NEW -p tcp --dport 111 -j ACCEPT
-A INPUT -s 192.168.100.0/24 -m state --state NEW -p tcp --dport 2049 -j ACCEPT
-A INPUT -s 192.168.100.0/24 -m state --state NEW -p tcp --dport 32803 -j ACCEPT
-A INPUT -s 192.168.100.0/24 -m state --state NEW -p udp --dport 32769 -j ACCEPT
-A INPUT -s 192.168.100.0/24 -m state --state NEW -p tcp --dport 892 -j ACCEPT
-A INPUT -s 192.168.100.0/24 -m state --state NEW -p udp --dport 892 -j ACCEPT
-A INPUT -s 192.168.100.0/24 -m state --state NEW -p tcp --dport 875 -j ACCEPT
-A INPUT -s 192.168.100.0/24 -m state --state NEW -p udp --dport 875 -j ACCEPT
-A INPUT -s 192.168.100.0/24 -m state --state NEW -p tcp --dport 662 -j ACCEPT
-A INPUT -s 192.168.100.0/24 -m state --state NEW -p udp --dport 662 -j ACCEPT
重启防火墙
service iptables restart
配置NFS为开机自启动
service rpcbind start
service nfs start
chkconfig rpcbind on
chkconfig nfs on
至此,NFS服务器已经配置完成,可以使用mount命令检查是否配置成功,最好使用其他机器进行测试,来保证防火墙是否配置成功,用另外一台连接到一个局域网下的Linux机器,在命令行输入:
mount -t nfs 192.168.0.24:/primary /mnt/primary
如果挂载成功表示NFS配置完成。

安装CloudStack服务器

操作系统安装

将一台服务器安装成CloudStack管理服务器,首先也要安装CentOS操作系统,和NFS一样,操作系统安装默认安装即可。
安装完操作系统以后同样要按照NFS服务器的方式设置一下IP地址和HOSTNAME以及SELinux配置。

安装CloudStack

解压缩安装包
tar zxvf CloudStack-oss-3.0.2-1-rhel6.2.tar.gz

安装数据库

使用./install.sh的D选项自动安装mysql数据库,安装完成以后,可以更改数据库配置/etc/my.cnf文件,添加以下内容
innodbrollbackontimeout=1
innodblockwait
timeout=600
max_connections=350
log-bin=mysql-bin
binlog-format = 'ROW'
启动数据库
service mysqld restart
配置防火墙,编辑/etc/sysconfig/iptables,添加
-A INPUT -p tcp --dport 3306 -j ACCEPT
重启iptables服务
service iptables restart

安装管理平台

执行./install.sh的M,安装管理平台。

初始化数据库

cloud-setup-databases cloud:password@localhost --deploy-as=root

配置管理服务器

cloud-setup-mangament
至此,管理服务器安装完成。

安装XenServer虚拟机

XenServer虚拟机安装较为简单,按照步骤进行安装即可,注意虚拟机的服务器名,IP地址之类的选择我们之前约定好的服务器名和IP地址。

买房贷款利息怎么算? 按揭贷款的利息计算公式


编者按:买房贷款利息怎么算?虽然通过网页版的房贷计算器很容易就能算出房贷月供,但购房者为图个放心还是想知道买房贷款利息怎么算、银行按揭贷款的利息计算公式是什么。本文将回答购房者这个问题,希望对大家的购房置业起到帮助。
一套房子,100平方,10000每平方,首付三成,月供多少,总利息多少,我主要想知道是怎么算的??以贷款20年来算:
按以上的是题意:该房屋的总价为10000*100=100万元,首付三成(30万元),贷款金额为70万元,贷款期限20年,按揭利率为6.8%(最新利率),按还款方式“等额本息法、等额本金法”分别计算如下:
1、等额本息法:计算公式
月还款额=本金*月利率*[(1+月利率)^n/[(1+月利率)^n-1]
式中n表示贷款月数,^n表示n次方,如^240,表示240次方(贷款20年、240个月)
月利率=年利率/12
总利息=月还款额*贷款月数-本金
经计算:月还款额为5343.38 元(每月相同)。还款总额为1282411.20 元,总利息为582411.20 元。
2、等额本金法:计算公式
月还款额=本金/n+剩余本金*月利率
总利息=本金*月利率*(贷款月数/2+0.5)
经计算:第一个月还款额为6883.33 元(以后逐月减少,越还越少),最后一个月还款额为2933.19元。还款总额为1177983.33 元,总利息为477983.33 元。
以上两种方法相比较,等额本金法比等额本息法少还104427.08 元。
采取哪种方法还款,借款人在银行办理贷款手续时可以选择。

Facebook 的系统架构

根据我现有的阅读和谈话,我所理解的今天Facebook的架构如下:
  • Web 前端是由 PHP 写的。Facebook 的 HipHop[1] 会把PHP转成 C++ 并用 g++编译,这样就可以为模板和Web逻贺业务层提供高的性能。
  • 业务逻辑以Service的形式存在,其使用Thrift [2]。这些Service根据需求的不同由PHP,C++或Java实现(也可以用到了其它的一些语言……)
  • 用Java写的Services没有用到任何一个企业级的应用服务器,但用到了Facebook自己的定制的应用服务器。看上去好像是重新发明轮子,但是这些Services只被暴露给Thrift使用(绝大所数是这样),Tomcat太重量级了,即使是Jetty也可能太过了点,其附加值对Facebook所需要的没有意义。
  • 持久化由MySQL, Memcached [3], Facebook 的 Cassandra [4], Hadoop 的 HBase [5] 完成。Memcached 使用了MySQL的内存Cache。Facebook 工程师承认他们的Cassandra 使用正在减少,因为他们更喜欢HBase,因为它的更简单的一致性模型,以到其MapReduce能力。
  • 离线处理使用Hadoop 和 Hive。
  • 日志,点击,feeds数据使用Scribe [6],把其聚合并存在 HDFS,其使用Scribe-HDFS [7],因而允许使用MapReduce进行扩展分析。
  • BigPipe [8] 是他们的定制技术,用来加速页面显示。
  • Varnish Cache [9]用作HTTP代理。他们用这个的原因是高速和有效率。 [10].
  • 用来搞定用户上传的十亿张照片的存储,其由Haystack处理,Facebook自己开发了一个Ad-Hoc存储方案,其主要做了一些低层优化和“仅追加”写技术 [11].
  • Facebook Messages 使用了自己的架构,其明显地构建在了一个动态集群的基础架构上。业务逻辑和持久化被封装在一个所谓的’Cell’。每个‘Cell’都处理一部分用户,新的‘Cell’可以因为访问热度被添加[12]。 持久化归档使用HBase [13]。
  • Facebook Messages 的搜索引擎由存储在HBase中的一个倒置索引的构建。 [14]
  • Facebook 搜索引擎实现细节据我所知目前是未知状态。
  • Typeahead 搜索使用了一个定制的存储和检索逻辑。 [15]
  • Chat 基于一个Epoll 服务器,这个服务器由Erlang 开发,由Thrift存取 [16]
  •     关于那些供给给上述组件的资源,下面是一些信息和数量,但是有一些是未知的:

  • Facebook估计有超过60,000 台服务器[16]。他们最新的数据中心在俄勒冈州的Prineville,其基于完全自定设计的硬件[17] 那是最近才公开的 Open Compute 项目[18]。
  • 300 TB 的数据存在 Memcached 中处理 [19]
  • 他们的Hadoop 和 Hive 集群由3000 服务器组成,每台服务器有8个核,32GB的内存,12TB的硬盘,全部有2万4千个CPU的核,96TB内存和36PB的硬盘。 [20]
  • 每天有1000亿的点击量,500亿张照片,100 billion hits per day, 50 billion photos, 3 万亿个对象被 Cache,每天130TB的日志(2010年7月的数据) [21]
  •     参考引用
        [1] HipHop for PHP: http://developers.facebook.com/blog/post/358
    [2] Thrift: http://thrift.apache.org/
    [3] Memcached: http://memcached.org/
    [4] Cassandra: http://cassandra.apache.org/
    [5] HBase: http://hbase.apache.org/
    [6] Scribe: https://github.com/facebook/scribe
    [7] Scribe-HDFS: http://hadoopblog.blogspot.com/2009/06/hdfs-scribe-integration.html
    [8] BigPipe: http://www.facebook.com/notes/facebook-engineering/bigpipe-pipelining-web-pages-for-high-performance/389414033919
    [9] Varnish Cache: http://www.varnish-cache.org/
    [10] Facebook goes for Varnish: http://www.varnish-software.com/customers/facebook
    [11] Needle in a haystack: efficient storage of billions of photos:http://www.facebook.com/note.php?note_id=76191543919
    [12] Scaling the Messages Application Back End: http://www.facebook.com/note.php?note_id=10150148835363920
    [13] The Underlying Technology of Messages: https://www.facebook.com/note.php?note_id=454991608919
    [14] The Underlying Technology of Messages Tech Talk:http://www.facebook.com/video/video.php?v=690851516105
    [15] Facebook’s typeahead search architecture:http://www.facebook.com/video/video.php?v=432864835468
    [16] Facebook Chat: http://www.facebook.com/note.php?note_id=14218138919
    [17] Who has the most Web Servers?:http://www.datacenterknowledge.com/archives/2009/05/14/whos-got-the-most-web-servers/
    [18] Building Efficient Data Centers with the Open Compute Project:http://www.facebook.com/note.php?note_id=10150144039563920
    [19] Open Compute Project: http://opencompute.org/
    [20] Facebook’s architecture presentation at Devoxx 2010: http://www.devoxx.com
    [21] Scaling Facebook to 500 millions users and beyond:http://www.facebook.com/note.php?note_id=409881258919
        (全文完)

    移动互联网系统架构十大陷阱

       过去的三年,54chen一直奋斗在中国移动互联网一线,历经各种坑爹的情况。以下特做记录。
       Top 1.时不我待 连通性
       cmwap cmnet这样的词语以后应该都会消失在人世间。三年前,经常性地有移不动联不通手机连不上服务器机房的情况。两年前,这种情况要好了一些。一年前,改善很多。现在还存在。相信未来会越来越好,时代在召唤!解法,花钱找有“背景”的机房。
       Top 2.生不逢时 HTML5
       在去年的网络情况下,HTML5依旧不适合用来做优秀的app。前几年的时候,网速各种烂的情况下,2G下的html5应用基本上完全不能用。现在好一点,开始有闲人把html5全部封装好native的调用,使其只做view的显示部分,但是,性能也是个大问题。当然了,同样地,相信未来会越来越好,同样是时代在召唤!解法,过几年再用。
       Top 3.环境恶劣 DNS
       DNS解析也有失败的情况下,app做得再漂亮,请求也不可达。IP要比域名靠谱一些,却有别的问题。解法就是在客户端多留下点域名和ip,一个不能用换下一个。
       Top 4.车匪路霸 http拦截
       天朝运营商,可以干得出你想不到的事情。各种小广告帖你家防盗门上。所以你最好还是在header里声明好了:畜生,这个不是html,这是json,不要加广告!
       Top 5.五花八门 app添加按钮一定要克制
       特别是android app,完全没有限制,或者统一标准,什么样的App都有,做一个大气的App,最重要的一点,看看能不能打开就是主要功能,手指点一下就能到重要功能。
       Top 6.逆流而上 完全不要在传统web上有所期待
       除了新浪微博、QQ空间这种从传统web上推出的App之外,几乎不可能在完成一个App之后,能够让用户按你的引导打开一个网站。其难度不低于当年在传统广告商打完广告,等用户来访问网站一样。
       Top 7.天下大同 App上的sqlite与服务器的mysql数据同步,是个大麻烦
       当App也有一个db在保存数据的时候,就会接二连三地出现数据不一致的问题。最好的解法,公司有个统一的同步机制,最好是固定的框架代码,让业务逻辑隔离开这个同步过程。当然,实际工作过程中,我们甚至还想把所有的云端数据只当成备份,干脆全部交给客户端工程师来完成逻辑,我们让cluster更加可靠和可扩展。
       Top 8.通则不痛 下载渠道要通畅
       动则几M的包,下载不通畅,基本上分分钟新增用户就归零了。而且,要上CDN。这里有个坑,有些个CDN厂商的代理服务器可能会出现缓存有限的情况,文件太大会出现前半部分下载挺快,后面越下越慢,请谨慎使用。
       Top 9.兵贵中速 移动网络更新太快不是好事,太慢也不是好事
       你看看哪个App天天在更新,已经不是web2.0时代了,亲! 同时,不要慢速运转,你的伙伴们会养成拖拉的习惯。最好的办法,内部天天更新,外部月更新甚至是季更新。
       Top 10.未雨绸缪 一定要提前准备全体用户可以看到的公告条,以备不时之需
       web2.0时代,我们要维护系统,在全部页面顶部加一个黄条:今天xx点全站维护。移动时代,这不太可能了,于是你会看到各种微博公告、微信公告、xx公告,反正就是不在自己家公告,因为自己家坏了要维护。