NoOps

Ops make no ops | Ops的目标是没有Ops,嗯!

alternative 命令学习与多版本 jdk 安装

作者: |   847 浏览  | 

alternative 命令用于管理系统上多个提供相同功能的软件包。如 jre mta editor 等。

当系统中有多个 editor 软件安装时,alternative 系统指定其中一套软件(包括相应的 man page)供用户使用。
如 editor 我们有vim nano gedit ed 等可供选择,相应地,有对应的 man page
下文我们将通过实际安装一个 alternative 命令来体会该命令的强大之处。

alternative 命令

该命令需要root 权限运行

看起来 –install 分支较为复杂一些,其他分支看名字就能猜出意思来。

首先,我们想看一下目前系统中安装了哪些 alternatives, 不过遗憾的是,该命令没有 –list 参数。
通过man alternatives,发现系统安装的 alternatives 都在 /var/lib/alternatives/ 下面。检查一下,发现里面有三个文本文件

看起来系统安装了这三个 alternatives
我们来看看links 到底是什么

看起来,links 指向了 /usr/bin/elinks
检查一下,确实是这样的。

下面我们将安装一个叫 editor 的alternative。 editor命令放在 /usr/local/bin/ 下面

这时运行 /usr/local/bin/editor  就可以直接打开 vim 了

但是看起来man page仍然不生效

我们通过安装 slave alternatives 来解决这个问题

试试 man editor

大功告成
当然,我们也可以安装另一个 editor 的候选并设置一个较低的优先级。

在机器上用RPM 装多个版本的JDK

从上面的页面下载所需版本的jdk
对于jdk6,需要先解开bin包,再安装里面的所有rpm包。
会得到一个jdk的包和很多sun-javadb-*的包
将这些包都传到yum repo,然后更新repo索引。
在机器上运行:
就可以看到传到yum repo上的所有jdk版本

见图

5291ead1-b43b-4806-be47-6c3c7fbfb8d8

从jdk1.8起,包的命名方式竟然改了。
把jdk 1.6 1.7 1.8都装上
检查 java 链接

看起来这个链接不属于任何包。

我们安装之前学习的 alternatives 来管理多个版本的jdk
我们以jdk为名字来管理上面的java/javac/javadoc/javaws/…的链接

看起来版本已经是正确的了
然后,再更新下相关联的j* 程序的链接
看起来下面的包都需要做一下alternatives 链接

用一个脚本解决:

上面的脚本同时解决了 JAVA_HOME 环境变量的配置。

这应该就是安装多版本JDK的正确姿势了。

PS: 根据实际的安装经验,jdk1.8的RPM已经自行安装 alternatives,不需要运行上面的脚本了。

参考:

http://www.if-not-true-then-false.com/2010/install-sun-oracle-java-jdk-jre-7-on-fedora-centos-red-hat-rhel/

noops.me

作者: |   2,204 浏览  | 

0a1fe77d2a09953c14e6620031ff2d89

9ae23f43209694f7ab60cca12a4bc656

cbbe903d5acfd20d92110acf4157eb9a

No Ops

我们团队对外的博客是NoOps.me,我们的运维理念是:Ops Make No Ops,希望把运维的日常工作尽可能的自动化起来,减少手工运维操作。做为一个运维人员,没有人愿意每天重复那些繁琐的运维操作;更没有人愿意每天处于高度紧张的精神状态,随时准备应对线上故障。

我们的目标是打造一个技术型、学习型的团队,通过新技术的研究,学习分享提升整个团队的技术影响力,使我们的运维工作更加高效。提供类似SaaS、DaaS、PaaS、IaaS的服务,一层层的向上封装。最终使研发人员能够在运维体系的架构下自助的进行资源申请、服务部署、运行监控和容灾备份,提供稳定、高效和安全的互联网服务。使我们的运维人员能有更多的精力参与到运维自动化体系的建设中,能有更多的精力投入到业务架构设计和性能优化中。

研发能力

做为运维人员,首要的任务是保证服务稳定高效的运行,7*24为用户提供互联网服务。由于互联网业务的特点,往往是研发周期短、功能不断迭代、文档不全、规模发展快速。那么对于运维人员在技能方面就有很高的要求,除过操作系统、网络、硬件、开源软件应用等基础要求外,还需要强调运维人员的研发能力。

一方面,运维人员具备研发能力可以快速上手研发人员交付的线上服务。充分理解程序的功能逻辑,才能提前发现隐患,给出合理的运维建议。在优化方面才能有的放矢,而不是查找网上资料,按照前人经验不断的调“试”。我们甚至希望每位运维工程都是产品架构师,能够对业务服务的系统架构进行合理性规划和改进。

另一方面,运维人员具备研发能力也能更直接有效的把运维经验形成工具和平台,更有效的推进服务运维的自动化。在运维人员,特别是应用运维人员招聘中,我们更关注是否具备研发能力。国内很多从事互联网运维的人员在研发能力方面都相对薄弱,大多属于操作维护类。所以在某国内大型互联网公司中,运维部中校招人员占比90%,招聘最基本的要求就是具备研发能力、掌握至少一种脚本语言,熟悉数据结构。另外做为运维人员,除了考虑研发能力和知识全面性之外,我们还会重点关注动手能力。

和一些公司的运维团队不同,我们虽然也有运维平台研发团队,但更多的工具和平台研发工作是由运维人员负责。专职的平台研发人员很多没有接触过运维,不清楚运维人员真正的需求和痛点,通用的平台不能满足所有运维人员的需求,专项的平台又很难在需求功能上达到平衡。以前经常遇到平台研发和运维相互指责的情况,平台研发认为运维不配合他们的工作,运维认为平台研发不懂运维需求。

我们的平台研发团队主要负责最基础的核心功能和UI研发,运维人员参与需求收集和设计评审,比如服务管理平台的服务树和权限的需求讨论和模型设计。而运维人员负责监控系统、部署系统、环境初始化以及各种的日常运维工具的研发。拿部署系统举例,运维人员负责了build模块、客户端、控制端的研发工作,平台研发人员负责Web界面的研发。

平台研发理念

如运维平台章节介绍的那样,我们在运维平台的设计中,提供各种API接口给运维或研发人员使用,他们根据自己的运维场景封装成个性化的工具或平台。以前涉及到服务器装机、改名、重启等操作都需要系统工程师负责,应用运维工程师发单让系统工程师操作。系统工程师将这部分工作形成自动化,提供API给服务管理平台。服务管理平台基于服务树和权限模型,提供给应用运维工程师使用,应用运维工程师能够对有权限的服务器进行一系列基础操作。渐渐的应用运维工程师将这部分权限开放给研发人员,研发人员也可以使用。同理,对于服务器资源申请、模块部署、监控添加都交给研发人员去使用。

运维人员除了平台研发和维护外,能够将精力放到其他更重要的事情上,避免了繁琐的沟通,工作效率也提升了。Hadoop研发人员使用资产信息提供的API,服务器的分布、交换机的参数、机柜的分布,能够更方便的调度和决策数据如何存储,避免由于机柜级别故障导致的服务受损。部署系统使用监控系统提供的API进行运行状态查询和监控项添加,在每台服务器部署前暂停监控,部署完成后启动服务、更新监控,判断监控正常后继续下一台部署工作,做到部署动作与监控状态的联动。

学习与分享

我们需要具备研发能力的优秀运维人员来帮助业务提升稳定性,但优秀的人才都不愿长期从事繁琐的操作类事务,不仅需要给予他们研发项目提升技术能力,也需要给予他们“有趣的事情”,研究新的技术。在工作时间上,尽量给员工买时间、投资源,在不影响业务稳定的前提下,投入20%~40%在项目研发和新技术研究上。

比如Https网站的SSL运算会消耗大量的CPU资源,工程师在经过研究后提出了采用类GPU的方式,用硬件加速卡来进行RSA运算,同时又对Nginx进行代码优化充分发挥硬件加速卡的性能,提升了服务质量还降低了资源成本。这样做的目的不仅能使我们的运维工作越来越出色,还能帮助我们看清未来的方向。比如虚拟化、Docker的研究帮助我们更好的进行服务部署,对大数据的研究帮助我们识别网络4/7层攻击行为。

我们鼓励工程师多学习、多交流,也希望团队是一个开放型的团队,能够把我们遇到的问题,好的经验分享出来,帮助个人、帮助团队、帮助行业共同成长,这也是我们写这本书的目的。

开源软件使用

在开源运维软件方面,我们保持着跟随不盲目的心态。任何一款开源软件,我们必须做到掌握到代码级别的能力,和运维公司内部的产品一样,不仅能很好的使用开源软件,还能够动手分析和解决遇到的问题。不重复造轮子,但对开源软件的使用,也要清楚认识我们使用它的场景。

我们使用了Puppet、Ansible、Zabbix、God、Docker、Mesos、Etcd等等,Puppet在部署工具的第一版,我们仅仅用它的DSL做部署行为的语法解析和执行,并没用到它的客户端和服务端配置管理功能。有服务管理平台提供的服务树和权限模型,不需要再单独维护Puppet的服务器列表。

Ansible主要使用它对服务器进行临时性的批量操作执行。我们每台服务器上已经有一个超级Agent,不希望引入太多有执行逻辑的Agent,所以我们选择使用Ansible和SSHD进行交互。同时,我们改造Ansible和服务树结合,工程师可以使用个人帐号很方便的对有权限的服务器,进行临时批量的任务执行。

Etcd主要用来做LVS的Real Server注册,Real Server上新增Nginx启动后往Etcd注册状态,LVS实时读取列表更新本机的配置文件并Reload。

监控最早也是使用Zabbix,和服务树结合进行监控和报警策略的管理,随后由于开源监控系统无法满足需求,才开始研发自己的监控系统。

小结

最后,真的很痛恨Operator这个称呼,我们目标是提供各种运维自动化平台或工具,让研发自助式的完成产品运行发布所需要的各种动作,No Ops!

小米监控系统开源

作者: |   4,271 浏览  | 

详细请移步: http://open-falcon.com/
github地址:https://github.com/xiaomi/open-falcon

Highlights and features

  • 数据采集免配置:agent自发现、支持Plugin、主动推送模式
  • 容量水平扩展:生产环境每秒50万次数据收集、告警、存储、绘图,可持续水平扩展。
  • 告警策略自发现:Web界面、支持策略模板、模板继承和覆盖、多种告警方式、支持回调动作。
  • 告警设置人性化:支持最大告警次数、告警级别设置、告警恢复通知、告警暂停、不同时段不同阈值、支持维护周期,支持告警合并。
  • 历史数据高效查询:秒级返回上百个指标一年的历史数据。
  • Dashboard人性化:多维度的数据展示,用户自定义Dashboard等功能。
  • 架构设计高可用:整个系统无核心单点,易运维,易部署。

SSD阵列卡方案优化:考虑使用RAID 50替代RAID 10

作者: |   3,452 浏览  | 

大家都知道SSD成本比较高,而不少用户在考虑可用性时都会选用RAID 10作阵列,这样无疑又增加了成本。然而RAID 10的可用性也并非百分百完美。为了能够平衡可用性和成本,因此最近一直在研究性价比更高的RAID 50,它提供了接近RAID 10的可用性并且接近RAID 5的成本,像是在高可用的RAID 10和低成本的RAID 5之间的取了一个平衡点。

 

为了能够直观了解不同RAID类型下的故障可用性,我们首先做个简单的可用性分析(以8盘RAID 10的同等容量作对比):

RAID 50中:4块盘组成单组RAID 5,然后两组RAID 5再组成RAID 0最后得到8块盘的RAID 50

ssd_r50_r10_01b

案例分析:

  • 第1块盘的容错概率都是100%,可见磁盘阵列最基本的能力就是容错,然而不同级别的阵列能够提供的数据保护能力也是不同的;
  • 从第2块盘开始除了RAID 6能够提供100%的故障可用性以外,其他包括RAID 10在内都不能提供完美的解决方案。同时我们可以发现RAID 5的容错能力是四者中最差的,但是要达到同样容量所需要的盘数量也是最少的,如果故障运维较为及时的话RAID 5是一个性价比较高的方案,不然在第一块盘故障后至阵列修复期间如果发生第二块盘故障就会导整个阵列故障(数据全部丢失),这就是风险所在;
  • RAID 6当然是较为可靠的方案,但是它要牺牲两块盘的容量并且性能也较差(后面有性能测试说明),所以要权衡性能和可用性;
  • 当然重点还是RAID 10和50:我们发现50在第二块盘故障时的可用概率和10比较接近,由于上述案例中只有两组RAID 5因此只能提供至最多两块盘的容错,如果RAID 5的组数量更多的话能够容错的盘数也将更多,且可用概率也会更高。

我们以9块盘RAID 50(3组RAID 5)为例作分析(达到相同容量的RAID 10需要12块盘):

ssd_r50_r10_02

再以12块盘RAID 50(4组RAID 5)为例作分析(达到相同容量的RAID 10需要16块盘):

ssd_r50_r10_03
上面对比中RAID  50已经能够容忍第3甚至第4块盘的故障,只是可用性相比RAID 10低了些,但是两者都不能达到完美的100%,所以权衡可用性和成本RAID 50还是有相当大的优势。

 

接下来看看性能,为了能够很好地分析性能,我们沿用了第一组对比方案的作性能分析:

ssd_r50_r10_04

 随机读分析:

  • 理论上认为R10性能最好,真实测试数据显示4K、8K数据块下R5、R50、R6的性能都要优于R10;
  • 当数据块增大到16K、32K时,R10的多盘优势才被逐渐体现出来。

随机写分析:

  • 4K由于R50、R5由于有大量校验计算一定程度上影响了性能,但随着数据块逐渐增大,盘数量的优势也显现出来。当数据块达到和超过8K时,R50性能全面超越了R10;
  • R10由于存在R1的写同步问题,因此只有4块盘在支撑并发写,随着数据块的增大,R50和R5的多盘性能优势开始发挥。

混合随机读写分析:

  • 得益多盘和无校验计算,混合读写R10领先;R50其次,和R10相差27%,性能也较为接近,R5和R50性能为线性关系,R6性能最差。

顺序读分析:

  • 由于不存在校验计算,顺序读性能基本上由盘的数量决定;R50和R10性能也较为接近,同盘数的R6和R50性能相当,而盘数较少的R5性能相对前三者要弱一些,符合预期。至于为何R10性能无法线性增加,主要是因为阵列卡本身的性能限制。

顺序写分析:

  • 顺序写R5被优化得最好;R50由于需要同时计算两次校验因此损失了一些性能,和R10性能相当,当数据块达到512K时,多盘优势进一步体现出来了,拉开了与R10的差距;R6由于校验和计算的实现较为复杂,顺序写性能也是最差的。

 

再来看看这些阵列方案的性能和容错特性:

ssd_r50_r10_05

性能测试结论:

  • 性能测试显示,相同容量的R50和R10性能接近:其中小块文件的随机读R50要全面好于R10,随机写4K虽然R50和R10差距在28%,但是块增大后R50要全面优于R10。顺序读写方面,R50和R10十分接近。
  • 容错方面,R50接近R10:第二块盘容错率R50十分接近R10,两者相差30%。R10的优势主要是在有一定的概率提供第三、甚至第四块磁盘的容错率,但是考虑到并非100%容错,因此从容错角度来看R50虽然和R10有一些差距,但也已体现出较好的容错率,至少优于R5。而且R50搭配灵活,甚至可以指定3组R5以达到最大3块磁盘的容错;
  • 成本方面,R50有很大优势:按这个配置计算R50只有R10的3/4。

 

总结:

RAID 50提供了接近RAID 10性能、可用性以及接近RAID 5成本的特性,具有较好的整体性价比优势,所以考虑使用RAID 50替换RAID 10把!

SSD优化案例:读策略优化和中断多核绑定

作者: |   1,941 浏览  | 

没有开场白,直接切主题!各位把这篇当成是报告来阅读吧:

应用IO模型:大量读线程同时访问多块SSD,请求均为4KB随机读,并且被请求的数据有一定间隔连续性;

服务器硬件配置:LSI SAS 2308直连卡 + 8块SSD

优化前应用QPS:27K

第一轮优化:读策略优化

通过 /sys/block/sdx/queue/read_ahead_kb 观察到预读大小为128KB,进一步观察iostat情况:

preopt_iostat

观察到每块SSD的rMB/s十分高,平均已经达到了250MB/s+,初步判断是由于read_ahead_kb的设置影响了应用的读效率(即预先读取了过多不必要的数据)。遂将read_ahead_kb设置为0,观察iostat情况如下:

preopt_iostat_rak0

而应用QPS却下降至25K!

分析原因:由于之前有预读功能存在,因此部分数据已经被预先读取而减轻了SSD的访问压力。将read_ahead_kb设置为0后,所有的读访问均通过随机读实现,一定程度上加重了SSD的访问压力(可以观察到之前%util大约在60~80%之间波动,而预读改成0之后%util则在80~90%之间波动)

 

尝试16K预读

通过IO模型了解到每次请求的数据大小为4KB,因此将read_ahead_kb设置为16KB进行尝试,结果QPS由25K猛增到34K!

观察iostat情况如下:

preopt_iostat_rak16

%util降了不少,而且通过rrqm/s可以发现出现了一部分读合并的请求,这说明优化确有成效。

此时CPU_WA也由原来的平均30%下降到20%,这说明处理器等待IO的时间减少了,进一步验证了IO优化的有效性。

 

第二轮优化:直连卡中断多核绑定

考虑到SSD的随机读写能力较强(通过上面的iostat可以发现),在多盘环境下每秒产生的IO请求数也已接近100K,了解到LSI SAS 2308芯片的IOPs处理极限大约在250K左右,因此判断直连卡控制芯片本身并不存在瓶颈。

其实我们担心更多的是如此大量的IO请求数必定会产生庞大数量的中断请求,如果中断请求全部落在处理器的一个核心上,可能会对单核造成较高的压力,甚至将单核压力打死。因此单核的中断请求的处理能力就有可能成为整个IO系统的瓶颈所在,于是我们通过mpstat观察每个核心上的中断数:

mpstat_preopt

可以发现第二个核心中断数已经达到了十分恐怖的80K!再来观察实际的处理器核心压力情况,为了能够更加直观地了解,我们用了比较准确的i7z工具来观察:

i7z_preopt

果然不出所料,Core 1的Halt(idle)已经到了1,充分说明第二个核心确实已经满载。

那么通过观察/proc/interrupt的情况再来进一步验证我们的假设,:

inter

我们截取了片段,可以发现mpt2sas0-misx的大部分压力都集中在了CPU 1上,并且我们发现直连卡模式是支持多队列的(注意观察irq号从107至122,mpt2sas驱动总共有16个中断号),因此我们将实际在处理中断的irq号107至118分别绑定至不同的核心上(这里就不再赘述有关多核绑定的原理,有兴趣的同学可以百度搜索以上命令的含义):

smp

随后我们惊奇地观察到应用的QPS由34K再次猛增至39K!

通过观察mpstat发现大量的中断被平均分散到了不同的处理器核心上:

mpstat_after

并且CPU_WA也由平均20%下降到15%,io wait被进一步优化!

 

优化总结:

  • 通过以上两个优化方法将应用的QPS由27K优化至39K,并且处理器的iowait由30%下降至15%,优化收效显著;
  • SSD的优化要根据实际的应用IO模型和设备的理论极限值进行综合考虑,同时还要考虑到各个层面的瓶颈(包括内核、IO策略、磁盘接口速率、连接控制芯片等)。

 

 

服务器的处理器核心真的越多越好?

作者: |   1,215 浏览  | 

这里我们不再赘述有关寄存器、ALC等处理器架构和原理知识。我们只从直观的数据去分析和了解我们正在使用的多核处理器的真实性能——正所谓“是骡子是马拉出来溜溜”。一切建立在实际运行的数据才是真正有价值的评判依据。

 

在开始数据分析之前,我们必须弄清楚处理器的计算能力到底是什么:是频率决定了性能?还是核数决定了性能?

首选我们必须了解处理器的一个简单的性能计算公式:

整体性能 = 单核性能 × 核心数

 

其次性能受哪些因素影响会有以下这些原则:

原则一:架构越新,单核计算性能越强!

对比同频率、同核心数的前后两代处理器的计算能力就能发现架构越新的处理器整体计算能力也越强,这也意味着处理器架构的改进确实提高了单核性能。

 

原则二:频率越高,单核计算性能越强!

对比同代同核心数不同频率的处理器就能发现频率越高的处理器计算性能也越好,但这并非完全的线性增长。原因是处理器频率上去以后由于受到内存访问速度的限制也会有一定的瓶颈,而频率越高的处理器耗费在数据等待上的时钟周期也越多。

 

原则三:核心数越多,整体计算性能越强!

对比同代同频率不同核心数的处理器不难发现核心数越多的处理器整体计算性能也越好。但是如果观察单核性能会发现其实核数越多的处理器单核性能比同频率核数较少的处理器会差一些,主要原因是核数越多对共享资源的争抢概率也越高,这些共享资源包括L3缓存、内存、QPI总线等,这也就是多核处理器总是要把L3缓存做得很大的原因,核数越多L3缓存也越大。

 

请重点区别单核性能和整体性能:

1、单核性能:它影响的是单线程或者单任务的计算能力(即计算的响应延迟),对于单个请求计算的响应延迟要求较高的应用,就要用高频处理器去满足,而不是用多核。因为应用的一个线程无论任何时候都只能运行在处理器的一个核心上,增加核心数量对于改善单个计算请求的响应延迟并没有帮助,也就是说对跑单线程、单任务的应用无法提升其性能;

2、整体性能:前面提到核数越多整体性能越好,这也意味着多线程和多任务的应用环境下,如果要提高单机的计算处理量最好的办法是增加核心数而不是靠提高频率。理由很简单,核数较少的处理器晶元面积也小。如果要一味提高性能便要提高频率,提高频率其实就是给处理器晶元加电压。晶元能够忍受的电压是有限的,电压耐受力越高的晶元成本也越高。因此从稳定性和成本去考虑的话,晶元面积更大的多核处理器才是提高整体计算能力的最好选择。

 

下面我们挑选几款主流的双路处理器来作性能分析:

主题1:核数相同、频率不同

数据说明:如下表所示从第7行(Geekbench Integer)起是各项性能指标:分别是Geekbench整数成绩、SuperPI运行百万次的时间、以及根据Geekbench整数性能分别除以“处理器数量”、“核心数量”、“核心数量和Ghz的乘积”等来分别针对整体性能,单核计算能力,单个处理器、单个核心以及单个核心下每个Ghz的性能进行分析评估。

核数相同频率不同

数据分析:

1、SuperPI体现的是单核浮点性能,通过SuperPI成绩可以发现处理器频率越高单核计算性能也越好,这一点也可以通过“性能/每个核心”项目体现,频率越高单核的计算性能也越好;

2、Geekbench Integer评估的是处理器的整体性能,规律自然也是频率越高整体性能越好;

3、“性能/每Ghz/每个核心”项目评估的是处理器的计算效率,这个项目是将Geekbench的整数成绩按照核数拆分并根据单个Ghz去计算,可以发现核数相同的处理器这个数据相互比较接近。

 

 

主题2:频率相同、核数不同

频率相同核数不同

数据分析:

1、SuperPI项目更加可以说明单核计算能力受频率的影响,虽然2640 v2有8个核心,但对SuperPI的成绩没有丝毫帮助;

2、通过“性能/每个核心”项目可以发现,同频率下核数更少的2620 v2在这项成绩略好一些,即频率相同核数较少的处理器在单核性能上总是会核数更多的处理器略好一些,这确实也验证了核心之间存在资源争抢的假设;

3、Geekbench Integer成绩也体现出多核的性能优势,同频率下核数较多的处理器整体性能也更好;

4、再来看看用以评估计算效率的“性能/每Ghz/每个核心”项目,可以发现核数较多的处理器在计算效率上处于劣势:八核处理器的单核Ghz性能明显要比六核处理器的低不少,这样也进一步验证了核心之间存在资源争抢的假设,并且核数越多资源争抢的现象也越显著。

 

 

主题3:整体性能相同

最后一组选取整体性能接近而频率和核数均不同的处理器

整体计算能力相同

数据分析:

1、SuperPI的成绩依旧验证了单核性能只受频率影响的假设;

2、Geekbench Integer成绩说明2630 v2的性能整体略好于2640 v2;

3、通过“性能/每个核心”项依旧验证了频率决定了单核性能的假设;

 

根据以上数据我们可以进一步将计算公式细化为:

多核处理器的整体计算能力 = 单核Ghz计算能力 × 频率数 × 核数

 

结论:

1、处理器整体性能和频率、核数有关,但并非核数越多性能就一定越好,高频少核和低频多核整体性能很可能接近;

2、核数决定了计算承载能力,核数越多能够承载的计算量也越大;

3、频率决定了单核计算能力,频率越高单个计算请求的响应延迟也越低;

4、频率相同的情况下,核数越多单核计算效率也越低;