Hello, New World!

2012年9月,博客诞生,采用Ruhoh 1.0版本。最初只是记录读书笔记和感想。慢慢发现写的内容越来越多。

2013年9月,博客改版,采用Ruhoh 2.X版本。很多内容仍在酝酿,很多内容仍需完善,这是一个新的起点。

2014年6月,博客改版,增加个人Wiki,记录零碎知识。采用Simiki+GitCafe。

自动化运维 Linux内核 Python相关 编程语言 程序设计 讲座笔记

持续更新中......


Latest Posts

Getting Started With Load Average 2014-06-15

what

  • 什么是Load Average

    Load是计算机工作量的度量。Load Average就是一段时间内(1分钟,5分钟,15分钟)系统Load的平均值。简单来说,就是一段时间内(1分钟,5分钟,15分钟)运行队列里等待的进程数加上当前正在执行的进程数。

    可以通过uptime命令查看。

    uptime
    
    21:45  up 22:37, 3 users, load averages: 1.81 1.79 1.58
    
  • 哪些进程被统计在内

    一个空闲的计算机load值为0,每一个使用或者等待CPU的进程使Load值增1。大多数UNIX系统仅仅计算处于正在运行或者等待运行(running or runnable)状态的进程。但是Linux同样包括处于不可中断(uniterruptible)状态的进程(通常是等待I/O),如果系统上有许多进程因为I/O繁忙被阻塞会导致不同的结果。这样的情况下Load Average会很高,但不能反应CPU实际使用增加(可能CPU使用率会很低,但是依然反应出用户需要等待多长时间)。

  • 是统计进程还是线程

    在现代操作系统中,对线程的不同实现导致Load Average计算的不同。这实际是跟不同线程模型相关的。为了计算Load一些系统视线程为进程:那么每个等待的线程都会使Load值增1。但是其他系统可能不同,尤其是对于实现M:N这种线程模型的系统通常使用不同的策略,对于Load计算有的是按照每个进程恰好一次(无论线程数量),有的是仅仅计算用户线程调度器暴露给内核的线程数(这可能取决于处理器的并发量)。Linux系统应该是每个线程单独Load增1。

  • 一个类比

    明白上述两点就知道了Load计算的实体是什么,关键是针对不同的系统有不同的实现。对于Load的理解,在这篇文章中有个通俗的解释。

    一只单核的处理器可以比喻成一条单车道。设想你是这条道路的交警,你来规划车辆怎么通过。如果前面没有车辆在等待,那么你可以告诉后面的司机通过。 如果车辆众多,那么需要告诉他们稍等一会。

    于是,对于车流情况有特定的描述,例如:

    0.00 表示目前道路上没有任何的车流。 实际上这种情况与 0.00 到 1.00 之间是相同的,很通畅,过往的车辆可以丝毫不用等待的通过。

    1.00 表示刚好是在这条道路的承受范围内。 这种情况不算糟糕,只是车流会有些堵,不过这种情况可能会造成交通越来越慢。

    超过 1.00,那么说明这条道路已经超出负荷,交通严重的拥堵。 那么情况有多糟糕? 例如 2.00 的情况说明车流已经超出了桥所能承受的一倍,那么将有多余过桥一倍的车辆正在焦急的等待。3.00 的话情况就更不妙了,说明这条道路基本上已经快承受不了,还有超出道路负载两倍多的车辆正在等待通过。

  • 两个比较

    Load Average是系统负荷的重要度量指标,另一个同样经常被使用的则是CPU使用率。这里简单的进行比较。

    • Load Average度量的是CPU使用的趋势,而不像CPU使用率那样是瞬时快照
    • Load Average包含了所有对CPU的需求,而不仅仅是度量时间点的活跃程度

    对于均衡负载来说,基于CPU队列长度的CPU Load信息会比CPU使用率更好。原因大概是对于Load很高的主机,CPU使用率可能接近100%,这时的利用率不能反应负载的级别。相反,CPU队列长度能直接反应这个CPU的负载总量。一个简单的例子就是:对于两个不同的系统,一个有3个进程在等待队列一个有6个进程在队列,它们的CPU利用率都可能接近100%。

    对于CPU利用率和CPU Load Average的结果来判断性能问题。首先低CPU利用率不表明CPU不是瓶颈,竞争CPU的队列长期保持较长也是CPU超负荷的一种表现。对于应用来说可能会去花时间在I/O,Socket等方面,那么可以考虑是否后这些硬件的速度影响了整体的效率。


Getting Started With Vagrant/Coreos/Docker 2014-05-17

这是一篇关于Vagrant, CoreOS, Docker三个工具的入门介绍性文章,通过描述"使用Vagrant安装CoreOS", "在CoreOS中使用Docker"来介绍三个工具的入门使用。当然要首先介绍”在Mac OS X上运行Vagrant”。

Part I: Running Vagrant On Mac OS X


Vagrant简介

Vagrant是一个创建和配置轻量级,可复制,可移植开发环境的工具,让配置开发环境更容易。一个简单的使用案例就是通过vagrant封装一个Linux开发环境,分发给团队成员。而每个人都可以在自己喜欢的桌面系统(Mac/Win/Linux)上开发程序,代码却能在封装好的环境里运行。得益于下面几个特点,Vagrant将极大改变我们的工作流程。

  • 快速安装

    下载和安装Vagrant非常快,无论是在MacOS X, Windows或者其他流行的Linux发行版,仅需数分钟时间。没有复杂的安装过程,仅仅是简单的使用系统标准安装工具。快速而且跨平台。

  • 极简配置

    Vagrant项目唯一配置文件Vagrantfile描述需要的机器类型,需要安装的软件以及如何访问该机器等。支持Puppet , Chef, Shell等配置管理工具,清单文件可通过同步目录实现。基础设施即代码。

  • 工作简单

    运行命令”vagrant up"即可启动机器,vagrant会将所有配置组合完成完整开发环境配置。”代码在我机子上运行没有问题”这种说辞将成为历史,因为vagrant为团队中每个人创建了统一开发环境。

The Way To Deploy 2014-04-01

这部分的文章主要聊聊部署,作为交付的重要环节,自动化部署一直是持续交付的核心。

Part I: Brief Introduction To Deploy

部署的常见方式

自动化部署主要分两个阶段:

  1. 代码分发
  2. 配置管理

下面来具体看看这些阶段使用的常见方式。

Sildes About Puppet And MCollective 2014-03-21

工具基本介绍


    这两个Slides主要介绍了Puppet和MCollective的概貌,入门级介绍,可以了解这两个工具的背景,是什么以及特点和使用等。


Troubleshooting 5minutes 2013-10-23

故障排除的第一个五分钟

在处理日常运维、优化和扩展性问题的时候,经常碰到了各种不同规模的性能很差的系 统和基础设施(通常是大规模的,比如 CNN 或者世界银行的系统)。再加上修复时间紧迫、 奇葩的技术平台、缺少信息和文档,基本上这过程都会惨痛到让我们留下深刻的记忆。

造成故障的原因大多数情况是不明显的:这里有一些我们通常开始做的事情。


获取上下文信息

不要急于去服务器操作,需要搞清楚对服务器和这个特定故障到底了解多少。你不希望 浪费你的时间在黑暗中排除(故障)。 一些“必须了解”的问题:

Puppet Data Flow 2013-09-17

Puppet数据流程

前面的部分对Puppet进行了概述,并对Puppet内部实现原理和认证过程进行了介绍。本部分将主要围绕puppet数据流程进行介绍,详细描述puppet是如何管理单个节点的数据流程。这部分在之前的概述和内部原理都有所涉及,单独选出来作为一部分介绍希望对数据流程和流程涉及的组件进行更深的理解。


首先回顾Puppet是如何工作:

puppet数据流

  • 定义:采用Puppet的描述性语言,以可重用的模块形式来定义资源及资源间关系的图。这些模块定义基础设施的预期状态。

  • 模拟 : 有了这些资源及其关系图,Puppet能够模拟部署环境,让你在不影响基础设施的前提下测试你的改变。使用noop参数或者多环境等实现。

  • 执行 : puppet比较你的系统和定义的预期状态,然后自动地使你的系统符合定义的预期状态。这个过程是相对透明的过程。

  • 报告 : Puppet Dashboard展示收集到的组件关系和所有的改变,并提供安全和授权措施查看。此外Puppet也提供有开放API以结合第三方监控工具使用。

Zabbix Performance Tunning 2013-07-01

Zabbix高性能

这篇文章主要是由多篇文章整理而成。包括过去很多人使用总结出来的经验以及补充一些官方博客关于原理性的介绍。包括性能指标,性能优化和具体优化策略等内容。


性能概述

性能指标
  • 指标一:NVPS

NVPS--通过Zabbix的NVPS(每秒处理数值数)来衡量其性能。 在Zabbix的dashboard上有一个粗略的估值。

Decorators And Functional Python 2013-06-28

Python装饰器和函数式编程[译文]

原文参考

装饰器是Python重要特性之一。它不仅是语言的固有有用特性,也教会了我们以一种有趣的方式--函数式方式来思考。

我将尝试从底层原理解释装饰器的工作原理。为了理解装饰器我们将从几个常见主题开始。在此之后,我们将会深入探讨几个简单的装饰器以及它们如何工作。最后,将讨论一些使用装饰器的更高级方式,例如传递可选参数或者串联化使用。

首先,我们来以我认为最简单的方式来定义一个Python函数。从这个简单的定义开始,我们能够以类似简单的方式来定义装饰器。

函数是一个执行特定功能的可复用的代码块。

Introduction To Puppet 2013-06-18

Puppet-《开源软件架构》翻译


介绍

Puppet是一个采用Ruby编写的开源IT管理工具,在Google,Twitter和纽交所等很多公司中作为数据中心自动化和服务器管理工具使用。它主要由创建此项目的Puppet Labs维护。由一个或者数百系统管理员操作的Puppet能够管理小至2台大至50000台这样大规模的机器集群。

Puppet是一个配置并维护你的计算机的工具;使用它简单的配置语言,你向Puppet解释你所希望的机器配置参数,然后它将根据需要更改配置来匹配你的要求。如果你的规格有所变化,比如包更新,添加新用户或者更新配置-Puppet将自动更新你的机器来匹配。如果他们已经按照需要配置,那么Puppet就会什么也不做。

通常情况下,Puppet将会充分利用已有的系统特性来完成它的工作;比如,在Red Hat上它将会用yum进行包管理而用init.d进行服务管理,但是在OS X上它会使用dmg进行包管理而用launchd进行服务管理。Puppet的指导目标之一就是让你无论在查看Puppet代码或者是系统本身时都让它的工作有意义,因此符合系统标准至关重要。

Puppet来源于其他多个传统工具。在开源世界里,它受到CFEngine以及ISconf影响最多。前者是第一个开源通用配置工具,后者使用make来做一切工作,而这鼓励人们关注整个系统中明确的依赖关系。在商业世界里,Puppet是对Bladelogic和Opsware(之后都被大公司收购)的回应,它们在Puppet诞生之时就已经非常成功,但是它们都专注于卖给大公司的管理层而不是直接为系统管理员提供伟大的工具。Puppet是为了解决这些工具类似的问题,但是却专注于与前二者完全不同的用户。

Puppet Commander 2013-06-15

Puppet Commander简介

Puppet Commander解决了即使在使用splay时,有时候也会有大量的checkins来hitting你的master并可能overwhelming它。

基本的理论就是通过使用控制puppetd代理的执行情况。Puppetd Agent代理能够知道有多少正在在运行的机器并且能够调度安排这些运行,因此能够确保在任何指定的时间可以调度运行当前给定数量的机器,这在一定程度上 会提高计划master的性能。但是这在执行puppetd(test run或者其他规定的执行)很繁忙时会有副作用。而puppet commander这时就会不去调度这些机器来运行,控制并发执行数量,使你master的资源空闲以供别的使用。

这是一个调用puppetd代理的工具。在puppetd的基础上,它主要实现了两个功能:-i/--interval,设置mcollective server的puppetd执行间隔 -m 允许最大并发执行机器数量。当然它也支持MCO工具所有功能,比如批量执行/批量睡眠、过滤机制等这些功能。该工具命令使用前需要停止所有mcolletive server的puppet daemon,并start puppetmaster。


安装

有两种安装方式,作为MCollective客户端使用 和作为Daemon使用。官网上介绍是作为Daemon(puppetcommanderd)使用,我尝试作为客户端程序使用没有问题,需要进一步封装。