请鄙视我吧

其实以前我们在北京是有过几次培训 + 技术交流的，可能你没看到论坛通知。 你可以查看本版的精华区，看看相关的历史活动。

这个工具很不错，更多命令行介绍看这里。

http://azure.microsoft.com/en-us/documentation/articles/storage-use-azcopy/

我觉得这些点还不至于直接否定了 stash

哪些缺点都给集成进去了？

参考下这个帖子： http://jenkins-ci.361315.n4.nabble.com/Groovy-send-rich-text-email-utf-8-problem-td1008588.html

什么乱码？乱码内容是啥？截图，发上来看看。

atlassian 的 stash 真的很不错，对于企业来说相当友好。 而反观 Github/bitbucket 则更对社交协作开发更友好。

总结的相当不错，赞一个

赞。

的确是这么个事。虽说过程改进年年改，年年有活，但是这事真是最有意义也最有挑战，日后收益最多的。

我个人觉得 TFS label 在使用的时候遇到的不便就是没有很好的管理界面（查询、删除、修改、锁定） 微软在 label 管理上的确需要加强点。

我也来学一学，感谢 elvis.

TFS 的 label 的确用起来不太顺手。欢迎 elvis 分享 TFS 二次开发的文章。

每次看到 bat 我都很绝望，用 VBScript 或者 PowerShell 是不是好点？

有一个 target 是用来获取用户输入的参数。做以下修改就可以了。 这里只适合我们内部的流程。采用 buildNumber 而不是 GetVersion

注释掉了：

是的。还发现有人修改了 TFSBuild.proj 文件，revert 回去就可以了。稍后贴上代码。

去了就可以和小赖作小伙伴儿，一起玩耍了 :D

赞美写得如此清晰、简介、具体、详细的 JD

人家配置管理部门部门的传统就是历来女生多。你想多了，呵呵。

夫人随行？

恩，是生成失败了，报的 get sources 的错误。

不一定是 admin，但是你要有 undo 别人文件的权限。这个权限是可以单独设置的。

猎头电话不是都写在后边了么 打过去问问就是了。

你写点不基础的，然后共享出来，我去下载。这样你就把钱又赚回来了。

osapi_max_limit = 5000

nova-api-os-compute api 的最大返回数据长度限制，如果设置过短，会导致部分响应数据被截断。

scheduler_default_filters = RetryFilter, AvailabilityZoneFilter, RamFilter, ComputeFilter, ImagePropertiesFilter, JsonFilter, EcuFilter, CoreFilter

nova-scheduler 可用的过滤器，Retry 是用来跳过已经尝试创建但是失败的计算节点，防止重调度死循环；AvailabilityZone 是过滤那些用户指定的 AZ 的，防止用户的虚拟机创建到未指定的 AZ 里面；Ram 是过滤掉内存不足的计算节点；Core 是过滤掉 VCPU 数量不足的计算节点；Ecu 是我们自己开发的过滤器，配合我们的 CPU QoS 功能开发的，用来过滤掉 ecu 数量不足的计算节点；ImageProperties 是过滤掉不符合镜像要求的计算节点，比如 QEMU 虚拟机所用的镜像不能在 LXC 计算节点上使用；Json 是匹配自定义的节点选择规则，比如不可以创建到某些 AZ，要与那些虚拟机创建到相同 AZ 等。其他还有一些过滤器可以根据需求进行选择。

running_deleted_instance_action = reap

nova-compute 定时任务发现在数据库中已经删除，但计算节点的 Hypervisor 中还存在的虚拟机（也即野虚拟机审计操作方式）后的处理动作，建议是选择 log 或者 reap。log 方式需要运维人员根据日志记录找到那些野虚拟机并手工执行后续的动作，这种方式比较保险，防止由于 nova 服务出现未知异常或者 bug 时导致用户虚拟机被清理掉等问题，而 reap 方式则可以节省运维人员的人工介入时间。

until_refresh = 5

用户配额与 instances 表中实际使用量的同步阈值，也即用户的配额被修改多少次后强制同步一次使用量到配额量记录

max_age = 86400

用户配额与实际使用量的同步时间间隔，也即距上次配额记录更新多少秒后，再次更新时会自动与实际使用量同步。

众所周知，开源的 nova 项目目前仍然有很多配额方面的 bug 没有解决，上面两个配置项可以在很大程度上解决用户配额使用情况与实际使用量不匹配的问题，但也会带来一定的数据库性能开销，需要根据实际部署情况进行合理设置。

计算节点资源预留

vcpu_pin_set = 4-$

虚拟机 vCPU 的绑定范围，可以防止虚拟机争抢宿主机进程的 CPU 资源，建议值是预留前几个物理 CPU，把后面的所有 CPU 分配给虚拟机使用，可以配合 cgroup 或者内核启动参数来实现宿主机进程不占用虚拟机使用的那些 CPU 资源。

cpu_allocation_ratio = 4.0

物理 CPU 超售比例，默认是 16 倍，超线程也算作一个物理 CPU，需要根据具体负载和物理 CPU 能力进行综合判断后确定具体的配置。

ram_allocation_ratio = 1.0

内存分配超售比例，默认是 1.5 倍，生产环境不建议开启超售。

reserved_host_memory_mb = 4096

内存预留量，这部分内存不能被虚拟机使用

reserved_host_disk_mb = 10240

磁盘预留空间，这部分空间不能被虚拟机使用

service_down_time = 120

服务下线时间阈值，如果一个节点上的 nova 服务超过这个时间没有上报心跳到数据库，api 服务会认为该服务已经下线，如果配置过短或过长，都会导致误判。

rpc_response_timeout = 300

RPC 调用超时时间，由于 Python 的单进程不能真正的并发，所以 RPC 请求可能不能及时响应，尤其是目标节点在执行耗时较长的定时任务时，所以需要综合考虑超时时间和等待容忍时间。

multi_host = True

是否开启 nova-network 的多节点模式，如果需要多节点部署，则该项需要设置为 True。

Keystone

配置项较少，主要是要权衡配置什么样的后端驱动，来存储 token，一般是 SQL 数据库，也可以是 memcache。sql 可以持久化存储，而 memcache 则速度更快，尤其是当用户要更新密码的时候，需要删除所有过期的 token，这种情况下 SQL 的速度与 memcache 相差很大很大。

glance

包括两个部分，glance-api 和 glance-registry，：

workers = 2

glance-api 处理请求的子进程数量，如果配置成 0，则只有一个主进程，相应的配置成 2，则有一个主进程加 2 个子进程来并发处理请求。建议根据进程所在的物理节点计算能力和云平台请求量来综合确定。

api_limit_max = 1000

与 nova 中的配置 osapi_max_limit 意义相同

limit_param_default = 1000

一个响应中最大返回项数，可以在请求参数中指定，默认是 25，如果设置过短，可能导致响应数据被截断。

OpenStack 底层依赖软件版本、配置以及性能调优

虚拟化技术选型

在私有云平台的体系架构中， OpenStack 依赖一些底层软件，如虚拟化软件，虚拟化管理软件和 Linux 内核。这些软件的稳定性以及性能关系着整个云平台的稳定性和性能。因此，这些软件的版本选择和配置调优也是网易私有云开发中的一个重要因素。

在网易私有云平台中，我们选用的是 Linux 内核兼容最好的 KVM 虚拟化技术。相对于 Xen 虚拟化技术，KVM 虚拟化技术与 Linux 内核联系更为紧密，更容易维护。选择 KVM 虚拟化技术后，虚拟化管理驱动采用了 OpenStack 社区为 KVM 配置的计算驱动 libvirt，这也是一套使用非常广泛，社区活跃度很高的一套开源虚拟化管理软件，支持 KVM 在内的各种虚拟化管理。

另一方面，网易采用开源的 Debian 作为自己的宿主机内核，源使用的是 Debian 的 wheezy 稳定分支，KVM 和 libvirt 采用的也是 Debian 社区 wheezy 源里面的包版本：

qemu-kvm 1.1.2+dfsg-6+deb7u3 libvirt-bin 0.9.12 内核选型

在内核的选型方面，我们主要考虑如下两方面的因素：

稳定性：在开发私有云平台的一开始，稳定性就是网易私有云开发的一大基本原则。我们采用 Debian Linux 版本，相对来说，Debian 的原生内核无疑更为稳定。这也是我们最开始的一个选择。 功能需求：在网易的定制开发中，为了保证虚拟机的服务性能，我们开发了 CPU QoS 技术和磁盘 QoS，它依赖底层的 CPU 和 blkio cgroup 支持。因此，我们需要打开内核中的 cgroup 配置选项。另一方面，网易私有云综合各方面考虑，将支持 LXC 这种容器级别的虚拟化，除了 cgroup 外，LXC 还依赖 Linux 内核中的 namespace 特性。 综合上述因素的考虑，我们选择了 Debian 社区的 Linux 3.10.40 内核源代码，并且打开了 CPU/mem/blkio 等 cgroup 配置选项以及 user namespace 等 namespace 选项，自己编译了一个适配网易私有云的 Linux 内核。从使用情况来看，选择上述版本的 OpenStack 底层依赖软件后，网易私有云运行还比较稳定，我们后续还会适时的对这些软件进行更新。 配置优化

在网易私有云的稳定性得到了保障之后，我们开始了性能方面的调优工作。这一方面，我们参考了 IBM 公司的一些 优秀实践，在 CPU、内存、I/O 等方面做了一些配置方面的优化。整体而言，网易私有云在注重稳定性的基础上，也会积极借鉴业界优秀实践来优化私有云平台的整体性能。

CPU 配置优化

为了保障云主机的计算能力，网易私有云开发了 CPU QoS 技术，具体来说就是采用 cfs 的时间片均匀调度，外加 process pinning 的绑定技术。

参考 IBM 的分析，我们了解到了 process pinning 技术的优缺点，并且经过测试也验证了不同绑定方式的云主机间的性能存在较大的差异。比如，2 个 VCPU 分别绑定到不同 numa 节点的非超线程核上和分配到一对相邻的超线程核上的性能相差有 30%~40%(通过 SPEC CPU2006 工具测试)。另一方面，CPU0 由于处理中断请求，本身负荷就较重，不宜再用于云主机。因此，综合上面的因素考虑以及多轮的测试验证，我们最终决定将 0-3 号 CPU 预留出来，然后让云主机在剩余的 CPU 资源中由宿主机内核去调度。最终的 CPU 配置如下所示（libvirt xml 配置）：

1 1024 100000 57499 内存配置优化 内存配置方面，网易私有云的实践是关闭 KVM 内存共享，打开透明大页：

echo 0 > /sys/kernel/mm/ksm/pages_shared echo 0 > /sys/kernel/mm/ksm/pages_sharing echo always > /sys/kernel/mm/transparent_hugepage/enabled echo never > /sys/kernel/mm/transparent_hugepage/defrag echo 0 > /sys/kernel/mm/transparent_hugepage/khugepaged/defrag 经过 SPEC CPU2006 测试，这些配置对云主机 CPU 性能大概有 7% 左右的提升。

I/O 配置优化

1）磁盘 I/O 的配置优化主要包含如下方面：

KVM 的 disk cache 方式：借鉴 IBM 的分析，网易私有云采用 none 这种 cache 方式。

disk io scheduler：目前网易私有云的宿主机磁盘调度策略选用的是 cfq。在实际使用过程中，我们发现 cfq 的调度策略，对那些地低配置磁盘很容易出现 I/O 调度队列过长，utils 100% 的问题。后续网易私有云也会借鉴 IBM 的实践，对 cfq 进行参数调优，以及测试 deadline 调度策略。

磁盘 I/O QoS：面对日渐突出的磁盘 I/O 资源紧缺问题，网易私有云开发了磁盘 I/O QoS，主要是基于 blkio cgroup 来设置其 throttle 参数来实现。由于 libvirt-0.9.12 版本是在 QEMU 中限制磁盘 I/O，并且存在波动问题，所以我们的实现是通过 Nova 执行命令方式写入到 cgroup 中。同时我们也开发并向 libvirt 社区提交了 blkiotune 的 throttle 接口设置 patch（已在 libvirt-1.2.2 版本中合入）来彻底解决这个问题。

2）网络 I/O 的配置优化

我们主要是开启了 vhost_net 模式，来减少网络延时和增加吞吐量。

运维经验

使用经验

开源软件 bug 在所难免，但是新版本比旧版本会好用很多，尤其是对于 OpenStack 这种正在迅速成长壮大的开源软件来说更是如此，这一点在我们使用过 Essex、Folsom 和 Havana 版本后深有体会，所以建议各种 OpenStack 用户能及时的跟进社区版本，与社区保持同步。 不要轻易的对社区版本进行各类所谓的功能性能方面的"优化"，尤其是在没有与社区专家交换意见之前，千万不要轻易下手，否则此类"优化"极有可能演变成故障点或者性能瓶颈点，最终可能导致无法与社区同步，毕竟一个公司或团队（尤其是小公司、小团队）的能力和知识储备，是很难与社区成百上千的各类专家相提并论的。 多参考各类大型公司分享的部署架构方案，尽量不要自己闭门造车，尤其是对于开源软件来说，各类公司、团队的使用场景千差万别，各种周边组件也是应有尽有，多参考业界实践是最好的方式。 一些细节实现可能有很多途径，但每种方式都有优缺点，需要经过充分的论证、分析、测试验证后，才能考虑部署到生产环境使用。 所有的部署方案、功能设计都要考虑到平滑升级问题，即使你得到的信息是升级时可以停服，仍然要尽量避免这种情况，因为停服的影响范围很难界定。 运维准则

OpenStack 也是一个后端系统服务，所有系统运维相关的基本准则都适用，这里简单的提几点实际运维过程中根据遇到的问题总结的一些经验：

配置项默认值与实际环境不匹配可能导致各种问题，尤其是网络相关配置与硬件有很强的关联性，生产环境和开发环境硬件异构，导致部分默认值在生产环境不适用。应对准则：每个版本都必须在与线上硬件相同的环境测试过才能上线。 做好容量规划，已分配的配额量要小于云平台总容量，否则会出现各种问题，导致运维开发耗费很多不必要的精力去定位分析问题。 配置项过多容易出错，需要与开发人员一起仔细核对，上线时首先要通过 puppet 的 noop 功能验证改动是否正确后，才能真正上线。 网络规划要提前做好，如固定 IP、浮动 IP、VLAN 数量等，网络扩容难度和风险都比较大，所以提前规划好是最保险的，一个原则是大比小好，多比少好。 网络隔离要做好，否则用户网络安全没办法保证。 信息安全问题要重视，这个是老生常谈的问题了，每个平台都有相同问题，但还是要重视再重视，一旦出现安全漏洞，所有虚拟机都面临严重威胁

转自：http://www.ibm.com/developerworks/cn/cloud/library/1408_zhangxl_openstack/

为了能让大家清楚你到底遇到了什么问题，建议你还是贴代码 + 抓图。就像主贴里那样。

网速较慢的会经常出现这个问题？ 网速较快的没事？