INTEL 新一代 E5 和老一代 CPU 参数对比一览

发表于2012 年 4 月 17 日由refactor 
英特尔? 四核 E5506 至强?处理器 CPU, 2.13GHz, 4MB 高速缓存, 4.86 GT/s QPI  

英特尔?至强? E5-2603 (1.80GHz, 10M 高速缓存, 6.4GT/s QPI, No Turbo), 4C, 80W

英特尔?至强? E5-2609 (2.40GHz, 10M 高速缓存, 6.4GT/s QPI, No Turbo), 4C, 80W  

英特尔?至强?处理器 E5606 2.13GHz, 8MB 高速缓存, 4.8 GT/s QPI, 4C  
英特尔?至强? E5-2620 (2.00GHz, 15M 高速缓存, 7.2GT/s QPI, Turbo), 6C, 95W  

英特尔?至强?处理器 E5607 2.26GHz, 8MB 高速缓存, 4.80 GT/s QPI, 4C   6,027.00

英特尔?至强?处理器 E5620 2.40GHz, 12MB 高速缓存, 5.86 GT/s QPI, Turbo, HT, 4C  
英特尔?至强? E5-2630 (2.30GHz, 15M 高速缓存, 7.2GT/s QPI, Turbo), 6C, 95W  

英特尔?至强?处理器 E5645 2.40GHz, 12MB 高速缓存, 5.86 GT/s QPI, 6C      8,722.00

英特尔?至强?处理器 E5649 2.53GHz, 12MB 高速缓存, 5.86 GT/s QPI, 6C    12,097.00

英特尔?至强?处理器 X5650 2.66GHz, 12MB 高速缓存, 6.4 GT/s QPI, Turbo, HT, 6C   
英特尔?至强? E5-2640 (2.50GHz, 15M 高速缓存, 7.2GT/s QPI, Turbo), 6C, 95W   
英特尔?至强? E5-2660 (2.20GHz, 20M 高速缓存, 8.0GT/s QPI, Turbo), 8C, 95W   

英特尔?至强?处理器 X5660 2.80GHz, 12MB 高速缓存, 6.4 GT/s QPI, Turbo, HT, 6C  
英特尔?至强? E5-2665 (2.40GHz, 20M 高速缓存, 8.0GT/s QPI, Turbo), 8C, 115W
发表在 DEVOPS | 留下评论

推荐国内的DNS，114.114.114.114

发表于2012 年 4 月 17 日由refactor

我们平时除了电信运营商提供的DNS，或者自建的DNS，还会使用网上公众DNS。

一般都是用Google提供的两组服务器：

8.8.8.8

8.8.4.4

现在国内一家企业，提供了公众DNS服务器：

114.114.114.114

114.114.115.115

推荐大家使用，速度快、可靠性有保障。

这家公司叫南京信风，和江苏电信合作推出抗攻击DNS服务。

发表在 DEVOPS | 留下评论

openstack 在 ubuntu 下安装以后，css问题的解决

发表于2012 年 4 月 17 日由refactor

丢失一个链接，导致无法下载到这些 css, js

ln -s /usr/share/pyshared/horizon/static/horizon/ /usr/share/openstack-dashboard/openstack_dashboard/static/
发表在 OpenStack | 标签为 | 留下评论

Dell R720 的测试

发表于2012 年 4 月 17 日由refactor

我们最近对 Dell R720 做了一些测试，和老的  Dell R410进行对比。

配置：
Dell R720  2* 2603  + 64G RAM + 2*2TSATA
Dell R410  2* 5620  + 16G RAM + 2*2TSATA
Dell R410  2*5504  + 16G RAM + 2*sas 140G
(这台机器上由于有负载，还略高，所以仅仅测试了计算圆周率，没有做编译内核测试）

操作系统：
ubuntu 12.04

测试项目：
1、计算5000位圆周率 pai

测试方法：
time echo “scale=5000; 4*a(1)” | bc -l -q

测试目的：
CPU计算能力

测试结果：

Dell R720: 40.08秒
Dell R410: 34.65秒
Dell R410 (有负载的机器）：50.2S

2、编译内核

测试方法：
重新编译linux的内核

测试目的：
CPU的计算能力，系统的IO能力，在一定压力下的综合反映

测试结果：
Dell R720: 6407秒
Dell R410: 4823.秒

1、从测试结果看， E5 2603 的R720比 E5620 的 R410要慢。

这是什么原因造成的？测试项目能否改进？

2、E5 2603 比 5504 也快不了多少，而且 5504 还有负载

E5 2603 估计和 5506 也差不多了

2、E5 2620 和 5620 对比，结果会有多少差异？

 

Dell 回复了一个邮件，附表：

发表在 其他 | 标签为 | 留下评论

openstack 2012.1的CentOS epel 测试版

发表于2012 年 4 月 17 日由refactor

邮件列表里，draig Brady (epel的 openstack维护者），已经提供了 openstack 2012.1 for CentOS 的测试版。

http://pbrady.fedorapeople.org/openstack-el6/

相信，很快将进入 epel 的正式软件库。

发表在 OpenStack | 标签为 , | 留下评论

openstack Design Summit的远程会议

发表于2012 年 4 月 14 日由refactor

openstack Design Summit精彩纷呈，可惜大陆地区只有极少数人有幸参加。

庆幸的是开通了远程会议连线，主要方式有：

1、cisco提供的webex网络视频会议

https://openstack.webex.com/

会议密码：folsom

2、IRC，采用 Freenode服务器，开通了房间：

#osds-ballroom
#osds-seacliff-a-b
#osds-seacliff-c
#osds-seacliff-d
#osds-marina
#osds-bayview-a
#osds-bayview-b
#osds-golden-gae

每个房间都做了日志，可以通过网页浏览：

http://irclogs.osds.cogitat.io/

会议时间是 2012.4.16-18三天，每天早上9：00到下午6：00。注意的是，旧金山是GMT-08:00市区，当前是夏令时，GMT-07:00。

所以，会议的背景时间是 2012.4.17-4.19 0:00-09:00，要观看对生理也是一个挑战。

http://time.123cha.com/?q=jjs

发表在 OpenStack | 标签为 , | 留下评论

2012春季的openstack Design Summit

发表于2012 年 4 月 14 日由refactor

openstack Design Summit会议将在2012.4.16-18在旧金山举行，主要面向开发者，讨论下一版本Folsom的功能，增加社区成员沟通的沟通机会。

参会的有Opentsack的开发人员，云计算工业领袖，最终用户，集中起来分享各自的成功例子，讨论云计算的未来和计划下一个发行版本Folsom. 参会的厂商有Rackspace, HP, Nebula, Ubuntu, Cisco, Dell, Intel，DreamHost，NetApp, NTT, Opscode, Yahoo, Ceph 等，国内参会的有新浪的开发人员。嘉宾有HP的高级副总裁，云计算业务的总经理Zorawar ‘Biri’ Singh; Openstack共同创始人、Nebula的CEO，Chris C. Kemp; Rackspace的CTO John Engates, 产品副总裁 Mark Interrante; Ubuntu的创始人 Mark Shuttleworth等等。

会议详细日程参见：

http://www.openstack.org/conference/san-francisco-2012/sessions/

个人感兴趣的一些热点：

  • dreamhost的一个讲演，关于ceph文件系统的
  • 讨论下一版本，让实例从volume 的启动
  • Folsom的发布，可能从以前的6个月一个版本，变为6～8周一个版本，加快迭代
  • 如何创建和维护一个稳定分支(wiki.openstack.org/StableBranch)
  • 如何让openstack进行超大规模的部署，包括调度策略，数据的伸缩，网络层的伸缩，存储的伸缩，监控的伸缩（好大的议题）
  • chef和puppet的自动化部署
  • 测试和质量保证，如何达到发布标准
  • Quantum和Melange设计介绍，让开发人员可以熟悉(这两个项目需要转换视角）
  • 计费系统（github.com/lzyeval/dough）
  • Openstack Ubuntu 测试小组，juju

 

 

发表在 OpenStack | 标签为 , | 留下评论

做了一个开源新项目GitNamed，管理域名服务器

发表于2012 年 4 月 12 日由refactor

DNS域名系统是互联网的一个非常重要的基础系统，域名管理希望做到的安全、可靠、方便维护。现在大家都希望运维自动化，减少出错的几率，提高工作效率，积累知识，做了一个开源项目GitNamed，让域名管理过程自动化。项目采用git来管理域名服务器，整个过程全部自动化。

系统管理员，在管理域名服务器的时候，一般的流程是登录到域名服务器上，手工修改、编辑配置文件：

  1. 如果仅仅修改一个域名记录，则编辑 zone文件 ，然后发送 rndc reload 命令重新装载配置
  2. 如果需要添加一个域名（zone），则需要新建 zone 文件，然后在所有服务器上修改 named.conf ，然后重新装载
  3. 日常，需要对域名文件进行备份，防止数据丢失和灾难发生时可以及时恢复

GitNamed 采用git来管理域名数据，并且一旦做了修改，自动推送到所有的域名服务器，立即自动生效。采用 GitNamed 的好处是：

  1. 提供一个域名服务器的配置框架，你可以很快使用GitNamed来配置出一套域名服务器
  2. 将域名服务器配置和域名数据全部放入到git管理，不用再担心数据的备份。而且今后所有修改的历史，都可以使用git详细列出。出现问题，可以立即很快恢复
  3. 一旦设置完成以后，管理多个域名服务器的工作，就变得简单，轻松
  4. 域名数据的管理员，不再需要服务器权限，只要有git的权限
  5. 递交的时候，采用 hooks 校验域名数据是否正确
  6. 递交的时候，采用 hooks自动设置zone的 serial，减少重复工作和出错几率
  7. GitNamed的，不光可以用于域名服务器的管理，稍加修改也可以用于其他配置管理、代码部署推送等场合

 

项目地址：

https://github.com/pubyun/gitnamed

 

发表在 其他 | 标签为 , | 留下评论

为什么要使用puppet 及初步接触

发表于2012 年 4 月 8 日由refactor

1、简介

云计算环境下，密度高，机器数量多，还要求弹性和伸缩性，这对于运维提出更高的要求。系统管理员需要经常安装操作系统，对系统参数进行配置和优化，对人员进行授权和定期更新公钥，对软件包进行升级，添加和配置某个服务。这些日常繁琐的任务不但单调、重复，也容易出错。为了提高效率，积累知识，不断改进，管理员一般会想到将这些任务使用脚本进行自动化，然后不断优化和改进这些脚本，可以大大提高效率。但是自己写的脚本，具有下面一些缺点：

  • 可伸缩性是一个问题，要管理成千上万台机器上一个挑战
  • 需要从头开始造轮子，脚本从头构建是一个挑战和繁琐工作
  • 不能保证能顺利运行在不同的平台上
  • 每次操作系统更新都需要重新测试定制脚本，耗费大量时间和精力，灵活性和功能也很难保证
  • 脚本语言虽然简单，自己写的脚本不一定别的管理员就能马上看懂, 不利知识共享

于是出现了出现了 一些自动化配置管理工具，Puppet, Chef 就是其中的佼佼者。我们选择了 Puppet 作为配置工具，具体原因主要是：

  • 装机量大，用户多，一些知名用户比如 Google, Redhat, Openstack，西门子都在使用 Puppet
  • Openstack 的集成环境 (Openstack-ci）就是使用 Puppet进行配置和管理的：

https://github.com/openstack/openstack-ci-puppet

  • Puppet使用更加友好的配置语言，便于描述业务。而Chef 需要使用 ruby 来做配置语言。
  • Puppet 提供更多平台的支持
使用puppet这样的自动化配置管理工具，主要的优点是：
  • 提供了一个强大的框架，简化了常见的系统管理任务，大量细节交给Puppet去完成，管理员只要集中精力在业务配置上
  • 系统管理员使用Puppet的描述语言来配置，这些配置便于共享，网上已经有数百个其他人开发的模块可以直接使用
  • Puppet伸缩性强，可以管理成千上万台机器

Puppet 一般是做成master/client 的结构，进行管理的。设置一个中央服务器 (puppet master)，然后在需要管理的机器上安装 puppet，做成 puppet client. 客户机定时（半个小时）和master通讯，从master读取配置，如果有变化，则自动在客户机进行配置。同时，Puppet也可以脱离 master 进行运行，Puppet 的配置文件，可以直接在客户端进行运行。我们的初步接触，就一台机器的 puppet 客户端开始。以后，我们还将看如何将这些配置部署，并且做到可扩展，我们将使用 git +puppet 的方式，代替 master/client 的结构。

2、安装 puppet

2.1 CentOS 6.2上安装

rpm -i http://download.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-5.noarch.rpm

yum install puppet

2.2 Deiban/Ubuntu 的支持

apt-get install puppet

3、puppet 的例子

cd /root/
mkdir -p puppet/manifests puppet/modules
cd puppet
#创建 sudo 模块
mkdir -p ./modules/sudo/manifests ./modules/sudo/files
#创建 sudo  的 manifests 文件：
vi ./modules/sudo/manifests/init.pp
class sudo {
    package { ‘sudo’: ensure => latest }
    group { ‘sudo’:
        ensure => ‘present’
    }
    file { ‘/etc/sudoers’:
        ensure  => ‘present’,
        owner   => ‘root’,
        group   => ‘root’,
        mode    => ‘0440’,
        source  => ‘puppet:///modules/sudo/sudoers’,
        replace => ‘true’,
        require => Package[‘sudo’],
    }
}
# 拷贝，修改 sudoers 文件
cp /etc/sudoers modules/sudo/files/
#运行puppet，进行测试（由于使用 noop 选项，不进行实际的操作，不拷贝文件）
# 如果你修改了  modules/sudo/files/sudoers 文件，就会提示你
puppet apply  –noop –modulepath=/root/puppet/modules modules/sudo/manifests/init.pp
#运行 puppet，使配置生效
#这时如果你修改了  modules/sudo/files/sudoers 文件，就会发现文件已经部署到 /etc/sudoers
puppet apply  –modulepath=/root/puppet/modules modules/sudo/manifests/init.pp
#创建 site.pp  文件
vim manifests/site.pp
node default {
  include sudo
}
#使用 site.pp 运行 puppet
puppet apply –modulepath=/root/puppet/modules manifests/site.pp

notice: /Stage[main]/Sudo/File[/etc/sudoers]/content: content changed ‘{md5}1b00ee0a97a1bcf9961e476140e2c5c1’ to ‘{md5}cbcab74f0fc9882ba9a91866b1fd6c82’
notice: Finished catalog run in 0.13 seconds

 

至此，我们在单机中运行了一个简单的例子。在这个基础上，可以继续：

1、逐步增加模块，增加配置功能

2、对各种主机，采用 site 进行配置

3、采用 master/client 方式，或者 git/puppet 将配置部署到所有需要管理的服务器上。

 

发表在 DEVOPS | 标签为 | 留下评论

OpenStack 2012.1 “essex” 的改进

发表于2012 年 4 月 6 日由refactor

http://wiki.openstack.org/ReleaseNotes/Essex

OpenStack Compute (Nova)

在Essex版 Nova的发布过程中，投入了大量的努力。现在Nova项目有206个开发人员，Diablo 版本以来有差不多3000次代码递交。对于一个不到两年的新项目，这是一个难以置信的发展速度。

在这个发行周期里，我们花了很多时间聚焦在项目的稳定性和BUG修正。也正有此，这是目前为止最具有生产特性的Nova版本。除了聚焦稳定性，在过去的六个月中，我们也努力融入更多的新特性，下面列举了最有趣的一些特性：

主要特点：

  • 集成keystone，keystone是openstack的通用身份管理系统，Nova不再必须内置用户、项目、角色管理。
  • RBAC（基于角色的权限控制），Nova现在支持对动作和扩展的可配置的权限控制。为了使配置更加友好，还需要做一些工作，但是目前已经可以进行非常具体的权限控制，决定在系统里谁可以做什么。
  • openstack通用库，Redhat的Mark McLoughlin花了大量努力，将配置解析放入openstack-common，他努力的结果，在下面的“配置”部分做了简要描述，这个改进将使openstack的各个项目可以共享代码。folsom将致力在openstack-common。
  • 虚拟化特性一致性，我们花了很多时间，以便使各种虚拟化技术的特性一致性。终极目标是运行一个openstack云，而用户不用知道或者关心使用的是何种虚拟技术。一个重要的改变是磁盘配置的一致性, Flavors/Instance类型现在有两个字段，一个是根磁盘大小，一个是第二磁盘的大小。
  • 管理API的扩展，许多管理特性被写入api扩展，意味着更多的任务，可以使用远程工具自动化完成，而不用直接操作数据库。
  • 支持上传包，我们做了一些改进，可以使用ec2-api进行镜像文件的上传。第一个是keystone支持ec2和s3认证，第二个是让cert管理功能完全集中到一个工作进程中，这样api节点不用共享一个公用的文件系统。最后，可以将swfit配置作为临时镜像存储，代替nova对象存储。
  • 卷接入点（endpoint），nova卷现在有了自己的接入点，这样可以独立作为一个单独的服务（比如部署到一个单独的服务器上）
  • 网络解耦，网络和计算对象相关的数据库模型，进行了充分解耦，这样，网络可以作为一个单独的服务。计算业务层，对网络数据进行了缓存，这样提高了api调用速度。
  • RPC的改善，RPC层做了很多改进和bug修正，加入了超时的支持，支持了另外一种消息服务器Apache Qpid。在Folsom 版本中，RPC代码将抽象出来，做成一个通用库，这样各个openstack项目可以共用。
  • metadata元数据的分离，元数据服务器可以和其他api服务分开单独运行，这样允许用户在计算节点上本地运行元数据服务，而其他api接口调用远端的服务。
  • 浮动IP池，目前可以允许使用多个浮动IP池，这样允许你使用一组内部映射的IP地址。
  • 其他特性，还有大量其他特性，超过50个蓝图特性和750个以上的bug修正，具体可以参见下面的文档：

https://launchpad.net/nova/essex/2012.1

配置：

我们不再需要python-gflags作为配置管理系统。配置现在可以使用ini风格的语法，原有的”flag文件”将转换成内部的新配置语法，如果你想进行手工转换，可以：

nova-manage config convert <infile> <outfile>

作为参照，所有的配置选项都可以在下面文件找到：

etc/nova.conf.sample

一共需要知道的重要的改变是，只有一些重要的配置能够在命令行配置。如果你以前习惯于使用命令行选项覆盖配置，你现在需要将它们加入到配置文件中。所有的执行文件，都在他们的同一目录寻找配置文件，如果找不到，再搜索 /etc/nova.conf

API文档：

在api文档的改善方面做了很多努力：

http://api.openstack.org

我们目前正在给所有代码中所有api扩展增加文档和例子，过几天将看到这些改变。

 

OpenStack Identity (Keystone)

在Essex版本中，身份认证系统的实现被完全改写。许多设计源于一种愿望，一些部署的认证后台，是现有用户系统的一个前端封装。描述这些改变和升级路径的文档，请参见  http://keystone.openstack.org.

你可以找到完整的keystone蓝图和bug修正：

    • https://launchpad.net/keystone/essex/2012.1

      keystone主要的改进：

      • 外部API ，admin和user部分api已经稳定，和Diablo版本相似。在改变内部实现的时候，我们尽量小心保持外部的接口部件稳定，以便我们未来可以快速前进。
      • 改写了被其他OpenStack项目使用的中间件组件，简化了代码。
      • 各个服务之间的认证实现，从之前的单一共享密码（之前称为”admin token”），变成每个服务的帐号和密码。nova, glance, swift等服务已经缺省使用这个配置改变，主要在 api-paste.ini文件中，这些新的配置定义每个服务的认证方式。
      • keystone服务和中间件现在加入了更多的日志信息，以便系统管理员和OpenStack的维护人员可以调试认证和授权问题。
      • keystone现在支持S3 token认证和附加的Swift存储特性：
        • 现在支持Swift ACL，你可以允许/禁止一个租户内的不同用户.
        • 使用ACL允许匿名存取，以支持公开的存取容器.
        • 支持Reseller账户，这样nova可以存取swift, 以代替 nova-objectstore

       

      已知的打包和发行版本：

       

      OpenSUSE 12.1 / SLES11 SP2

    • https://build.opensuse.org/project/show?project=isv:B1-Systems:OpenStack:release:Essex
    • https://build.opensuse.org/project/show?project=isv:B1-Systems:OpenStack:release:Essex:requirements

你可以从下面的wiki获取OpenSUSE 12.1 and SLES11 SP2下的软件包的详细信息： Packaging/SUSE

 

Fedora 17 / Fedora 16 / EPEL 6

 

Ubuntu 12.04 LTS (Precise Pangolin)

所有OpenStackOpenStack Essex核心组件，被Precise Ubuntu 的main archive官方支持:

孵化项目 Quantum 和Melange 在 Precise 的 Universe部分：

Essex 在 Ubuntu Server 下可以使用 MAAS 和 Juju部署：

Martin Loschwitz 写了一个Essex 在 Ubuntu 12.04上的一步一步的手工安装说明:

http://www.hastexo.com/resources/docs/installing-openstack-essex-4-ubuntu-1204-precise-pangolin

国内陈沙克做了翻译，并且补充了部分内容：

http://hi.baidu.com/chenshake/blog/item/4551cc5812a1b39e810a1876.html

Debian GNU/Linux wheezy

所有核心 OpenStack Essex 组件 被 Main wheezy archive官方支持:

Essex 的部署可以参见 a HOWTO 和 puppet modules.

发表在 OpenStack | 标签为 , | 留下评论