存档

‘maintain’ 分类的存档

容量管理

2011年6月22日 没有评论

容量管理(Capacity Management) 致力于在恰当的时间以一种经济节约的方式为数据处理和存储提供所需的容量。这里需要很好的平衡。良好的容量管理可以帮助消除某些“最后时刻”的临时应急式 的盲目采购,或者超量采购。这两种情形都可以节约成本。比如,许多数据中心在其业务运作的时间内,一直都是以不高于20%的平均利用率(使用的容量)在运 行(不包括系统类型的差别,但包括文档和打印服务器等)。当你只有几台服务器时,这种情况还不至于太坏。而当你如许多企业的IT部门一样,拥有成千上万的 服务器时,如此低的利用率就意味着巨额的浪费。

容量管理主要论及下列的几个方面:

● 处理容量的购买成本相对于业务需求来说,是否合理以及处理容量是否以最有效的方式(成本Vs容量)被加以利用?

● 当前的处理容量是否足够满足客户当前以及未来的需求(供给Vs需求)?

● 现有的处理容量是否发挥了最大的效率(性能调整)?

● 额外的处理容量准确地讲应该在什么时候形成?

● 我们是否知道未来需要什么样的IT 容量以及何时需要这种容量?

为了实现其目标,容量管理需要与业务及IT战略流程保持密切的联系。因此,该流程既是反应性的(评价和改进),也是主动性的(分析和预测)。

容量管理的基本内容

容量管理中包括的重要概念包括:

● 性能管理(Performance Management)——为优化整体运营绩效而评价、监控和调整IT基础设施组件的性能的活动。

● 应用选型(Application Sizing)——确定需要用来支付新的或改进后的服务以及预计的未来负载量的硬件或网络容量的过程。

● 模拟(Modelling)——使用分析、模拟和趋势预测模型来确定服务的容量需求以及确定最佳的容量方案的过程。模拟需要分析各种不同的情形,并分析各种“如果……怎么办”式的问题。

● 负载管理(Workload management)——主要是了解不同的业务驱动会产生怎样的结果,需要哪些资源(它既可以作为模拟的一个基本组成部分,也可以是单独的一种活动)。

● 容量规划(Capacity Planning)——根据容量管理数据库分析当前的情况、预测IT基础设施未来的使用情况以及为满足预计的IT服务需求而需要的资源,从而制定容量计划的过程。

为什么需要容量管理

 

容量管理致力于根据当前和未来的业务需求,在恰当的时间(在需要的时候)以恰当的成本协调地提供所需的IT资源。

这样,容量管理不仅要预计那些对客户可能产生影响的业务发展,同时也要预测技术的发展情况。容量管理流程在确定投资回报和成本合理性方面也扮演了重要的角色。

容量管理的效益有:

● 由于资源被有效地加以管理以及设备运作性能被持续地监控,与现有服务相关的风险也被降低了。

● 通过应用选型可以了解新的或改进的服务对现有系统的影响,从而降低与新的或改进的服务项目相关的风险。

● 在恰当的时候(既不要太早也不太晚)进行投资,这意味着采购流程再也不需要应付临时的采购或超前于需求而购买过度的容量,从而总体成本降低了。

● 通过在确定变更对IT容量的影响时与变更管理密切配合,防止了由于不恰当或不正确的容量估计估计所导致的紧急变更,从而降低了业务运作中断的次数。

● 更为灵活的预测使得对客户需求的响应变得更快速和更准确。

● 由于在更早的阶段对IT容量的需求和供给进行均衡,使得IT容量管理的效率提高了。

● 由于IT容量利用的效率更高,从而使得与容量相关的开支得到很好的管理。甚至降低。

这些效益的产生可以改善与客户的关系。容量管理在更早的阶段与客户进行协商沟通,并提前预定客户的需求。与供应商的关系也可以得到改善。有关采购、交付、安装和维护的协议也可以得到更有效的规划。

服务品质协议-SLA

2011年4月26日 没有评论

介绍:什么是 SLA?

服务品质协议(service-level agreement)(SLA)是服务提供者和客户之间的一个正式合同, 用来保证可计量的网络性能达到所定义的品质。SLA 为服务提供者提供了一种在当今多变而又竞争激烈的市场中胜过对手的方法。服务提供者可能是一个国内的 IT 组织、一个应用程序服务提供者(ASP)、一个网络服务提供者(NSP)、一个因特网服务提供者(ISP)、一个受管服务提供者(MSP)或者任何其它类 型的服务提供者。

SLA 可以非常笼统或者极度详细,它一般都包含出现故障时服务提供者和客户应采取的步骤。服务提供者保证它提供的服务在一定百分比的时间内(例如,99.9%) 是可用的。提供者还能够强制向客户通知 SLA 当机时间的最长和平均响应时间,或者在网络接口发生改变之前的最长和平均响应时间,并利用基于因特网的工作流自动化、分发和报告技术。如果经过指定的一段 时期后提供者无法达到所定义的性能品质,客户就可以获得一些权利和赔偿。各个 SLA 的权利、赔偿和例外情况是不同的。客户还同意接受协议一般条款的指定例外情况。

在每个 SLA 中都必须精确定义服务品质;否则各方关于 SLA 将以哪种品质衡量什么服务或性能标准将无法达成一致。例如,一个客户可能认为一个双方同意的服务品质将衡量网络 A、网络 B 和网络 C,同时后两者连接到第一个,而服务提供者却认为它只衡量网络 A。还有一点很重要的是正常运行时间可用性百分比的小数位数:例如,一年中的当机小时数和当机天数比,99.999% 的正常运行时间所允许的当机时间比 99.9% 的正常运行时间所允许的当机时间还少。SLA 应该为客户包含进一个退出条款;当因为不能圆满解决经常发生的可用性、可靠性和安全性问题而使客户的业务运转频繁中断时,客户希望他有终止协议的权利。

回页首

SLA 的发展

SLA 已经出现了一段时间了。在二十世纪六十年代,它们是用于达到已定义的服务品质和响应服务问题的一般操作程序,而这些服务问题是用户组织在购买或租用大型机上的机器时间时就已经同意过的。 超大型计算机(big iron)是缺省的企业系统,其它任何技术的处理能力都无法与它相比。

当客户机/服务器和网络桌面系统进入计算机世界时,人们就构思出了分布式网络系统这个概念。这些系统后来发展成了跨网络运行企业资源规划(ERP),供应链管理(SCM)和客户关系管理(CRM)系统的企业范围的系统。

在这个发展过程中,企业对因特网的依赖已经使得公司的应用程序套件的网络延迟影响越来越明显。同时,用户(也就是客户)已经委托一定品 质的服务质量保证相关的可用性、可靠性和响应时间以确保业务运转不被中断,并且依赖外部服务提供者来提供应用程序、因特网、网络,受管服务和其它服务。结 果,SLA 变得更复杂,范围更广,一个用户可以有与不同提供者签定的几个 SLA。反过来,提供者自己的 SLA 也可以是与其它提供者签定的,每个 SLA 都有一套不同的需求、衡量标准和例外情况。

回页首

新方向:用 SLA 保证 Web 服务

因特网(和企业内部网)的新方向提供了将来自不同来源(通过 Web 服务)的全异系统聚合并集成在一起的新方法和机会。随着不断扩展的分布式网络系统中提供者之间的关系变得更加复杂,Web 服务已经使 SLA 变得更富有挑战性。我们看到这些 SLA 不仅仅保证网络性能和正常运行时间可用性;由于每个 Web 服务都有不同的特征和网络需求,它们还被用来保证应用程序的性能。目前,一些 SLA 可以或者早已经作为公共 Web 服务公开了。

所有的 Web 服务都提供在 Web 上集成和修改系统组件的灵活性,以允许用户更改需求和在一定网络流量条件下处理网络资源争用。然而,这种灵活性要受到简单对象访问协议(Simple Object Access Protocol,SOAP)和统一描述、发现和集成(Universal Description and Discovery Integration,UDDI)互操作性问题的限制,因为一些主要厂商对这些协议的标准规范的解释是不同的。这意味着在把 Web 服务投入到生产环境和在 UDDI 或另一个公共注册中心将其作为公共服务发布之前,必须解决互操作性问题。对于 SLA 保证的 Web 服务(我们有时候称其为 SLA Web 服务)也是如此,不管该服务是独立的还是作为一套 Web 服务的一部分。后者的一个很好的示例是一个单独的 SLA,它适用于 Web 基础架构的每一段,从因特网到 Web 服务应用程序。

回页首

SLA Web 服务体系架构

在进行进一步讨论之前,让我们来看一下 SLA 保证的 Web 服务的体系架构。这个体系架构,如下 图 1所示,需要三个服务角色:一个 服务提供者、一个 服务客户和一个 服务代理。通过在适当的平台上创建一个 Web 服务并生成 WSDL 文档和服务的基本 SLA ,服务提供者发布一个由 SLA 保证的 Web 服务。下一步,它把服务细节发送到服务代理以存储在资源库中。服务客户向代理注册,然后在代理的资源库中搜索并发现适当的 Web 服务,检索服务的 WSDL 和 SLA。然后它再与提供者协商把 SLA 正规化、确定下来并绑定到它的 Web 服务。
图 1. SLA 保证的 Web 服务的体系架构
SLA 保证的 Web 服务的体系架构

回页首

为现实世界做准备:测试机制

必须监视任何符合 HTTP、HTTPS、SOAP、UDDI 和 Web 服务描述语言(Web Service Description Language,WSDL)的由 SLA 保证的 Web 服务的可伸缩性和性能。在把 SLA 保证的 Web 服务投入到生产环境之前,必须解决所有的 SOAP、WSDL 和其它的互操作性问题。如果服务无法满足一定的标准,按照 SLA 的条款,提供服务的提供者可能要付财政责任,所以确保所有这些问题都在控制范围内特别重要。

在建立 SLA 保证的 Web 服务之前,应该使用测试机制 ― 比如来自 PushtoTest 的工具和脚本 ―(请参阅下面的 参考资料部分获得链接)来测试该 Web 服务的各种协议和组件。在启动服务后,这些测试工具可以充当 SLA 监视器。

表 1是一个核对表示例,当开发者测试一个将被 SLA 保证的服务时,他应该考虑这个表。

表 1. 在发布一个服务之前应该测试的 Web 服务功能

测试类型 问题
有状态 当您使用 SOAP 设置服务器值时,服务器在并发的状态下是否正确响应?
访问 一个未经授权的用户能成功访问只有经过授权的管理员才能使用的控制权吗?
响应时间 Web 服务响应时是不是花费的时间太长(例如,超过了 10 秒)?
超时 当 Web 服务超时时会发生什么事情?
版本 新的构造会破坏现有 Web 服务的功能吗?

回页首

规则的例外情况

象任何协议或保险单一样,SLA 通常会指定其条款中的例外情况。Web 服务的 SLA 应该包含关于例外情况的详细信息。我将随意将它们分为四类:故障、不受服务提供者直接控制的网络问题、拒绝服务和预订的维护。 表 2说明了可以归入这些类别的某些特定情况。

只要客户公司可以得到当机期间的适当赔偿,还可以添加其它一些例外情况来适应提供者的情况。通过在 SLA 中包含进例外情况,提供者可以在出现问题或网络损耗时免负责任。另一方面,如果竞争的服务提供带有极少例外情况的 SLA,客户可以选择那些在业务运转中提供更长正常运行时间并且有更好的服务保障的协议。即使 99.5%、99.9% 和 99.999% 这几个正常运行时间可用性保证之间的差别也可以影响选择 SLA 的决策者。

表 2. SLA 中可以潜在包含的例外情况

类型 示例
故障 硬件故障(请注意,错误的硬件极少)
远程通信故障(例如,提供者无意切断了光缆线)
软件错误/缺陷
监视/测量系统故障
不受服务提供者直接控制的网络问题 主干对等端问题(例如,UUnet 在加利福尼亚的一个路由器坏了,拒绝因特网服务进入整个西海岸)
DNS 不受服务提供者的直接控制
拒绝服务 客户疏忽/明知故犯
网络流量过大、黑客攻击和一般攻击
不可抗力、战争、罢工、电讯不可用、无法得到提供 SLA 所需的供给或设备。
预订的 维护 硬件升级
软件升级
备份

回页首

潜在问题

虽然 SLA 的重点是最大上载可用性和带宽的保证,但 SLA 无法为那些对延迟敏感的 Web 服务应用程序保证一致的响应时间。延迟是数据包从一个地点到另一个地点然后返回这一个来回所花费的时间(通常以毫秒计)。当数据包完成它的旅途花费的时间 太长时就会发生延迟问题。例如,当 Web 服务产生的音频开始断断续续或者鼠标指针开始微微颤抖的时候,您就会注意到这些问题。

SLA 应该指定给定时间周期(假设一个月)内的平均来回延迟和数据报丢失。它应该把平均来回延迟定义为它在网络和其目的地之间的平均来回包传送,并把包丢失定义 为在数据传送的来回时间内丢失包占总包数的百分比。协议应该把这种丢失限制到一定程度 ― 假设 1% 或更少 ― 如果在同意的时间段内这种丢失超过了这个程度还应该指定赔偿,包括偿还或退款。

回页首

结束语

目前为止,我已经说明了 SLA 保证的 Web 服务的技术参数。如果您计划为您的付费客户提供 Web 服务,他们通常都想要一个 SLA 以确保获得他们期望的投资回报。本文中讨论的主题应该会让您在准备自己的 Web 服务以满足 SLA 的需求方面处于领先地位。

本文并没有讨论可用于估量客户期望的各种工具;在真实的商界,您可以发现即便您的服务满足同意的服务品质,您的客户仍可能对服务不满 意,因为技术上的服务交付能力还没有达到企业的期望。在这些情况下,客户和提供者必须就协议条款重新谈判以确定满足客户的服务品质。对于开发者,在创建和 实现 Web 服务时记住这一点很重要。开发者必须既考虑客户的业务期望又考虑技术期望。

 

参考资料

  • 您可以参阅本文在 developerWorks 全球站点上的 英文原文.
  • 请了解更多关于 PushToTest的知识来测试和监控 Web 服务。
  • 请阅读 The Complete Book of Middleware它主要讨论系统设计的重要原则和优先考虑的问题,并强调电子商务和分布式集成系统的增长带来的新需求。
  • 请阅读 Enterprise Systems Integration, Second Edition它向您提供企业内部机制和技术诀窍并确保成功地集成系统。
  • 请阅读 Anbazhagan Mani 和 Arun Nagarajan 所著的“ 理解Web服务的服务质量”(developerWorks,2002 年 1 月)来改善您的 Web 服务的性能。
  • 这本面向 Domino 管理员的 IBM Redbook描述了制定一个服务品质协议的具体细节。
  • 一旦 Web 服务就绪,您就可以在 IBM 的 UDDI 版本 2 注册中心中发布它,这个注册中心的特征是有图形用户界面和一致的 API 供大家公用。

关于作者

Judith M. Myerson 是一位系统设计师和工程师。她对中间件技术、企业范围的系统、数据库技术、应用程序开发、网络管理、分布式系统、基于组件的技术和项目管理都很感兴趣。您可以通过 jmyerson@bellatlantic.net与她联系。

raid详细图解(生活版)

2011年4月13日 没有评论

对于网管来讲,如何有效保证服务器上数据的安全呢?用多个硬盘建立RAID恐怕是最普遍的手段了。今天就由笔者通过一问一答的方式为各位IT168的读者介绍RAID相关的知识。

问题1:什么是RAID?它是由什么组成的?

RAID的中文名字为磁盘冗余阵列,顾名思义它是由磁盘组成阵列而成的。因此RAID需要至少两块硬盘组成。RAID的基本想法就是把多个便宜的小磁盘组合到一起,成为一个磁盘组, 使性能达到或超过一个容量巨大、价格昂贵的磁盘。

早期的RAID诞生初衷并不是为了数据的安全,而是为了提高硬盘的读写速度。RAID 0和RAID 1就是为了这个目的而定义的。

问题2:什么情况需要使用RAID?

根据不同的实际情况作为网络管理员的我们应该为服务器采 取不同的RAID种类。目前最流行的是RAID 0,RAID 1,RAID 5。其中RAID1和RAID 5过多的用于保证数据的安全,最大程度的防止磁盘意外坏掉而丢失数据情况的发生。而RAID 0则是为了提高磁盘读取的速度,它不提供任何数据备份和保障功能。知道了不同RAID应用的情况我们根据实际情况进行选择即可。

当然那些需要在硬盘上保存大量数据的人采用 RAID 技术将会很方便。主要表现在以下几个方面——

(1)增强了速度 ,服务器可以在同一时间从多个硬盘上读取数据。

(2)扩容了存储能力,多个硬盘组成更大的空间提供给服务器使用。

(3)可高效恢复磁盘,RAID提供了相当高的数据冗余功能,我们可以保证数据的完整无缺。

问题3: RAID都有哪些种类呢?希望可以使用直观容易懂的语言来描述。

对于RAID种类恐怕很多文章都介绍过,这里我就不详细说明理论东西了。恰巧笔者看到了一个外国描述RAID各个级别的图片,感觉很多地方定义得非常准确,而且通过看图了解RAID效果会更加显著。(如图1)

raid廉价冗余磁盘阵列

(1)先为大家讲解第一个小图,也就是标记着standalone的饮水机,该图主要是通过矿泉水桶为饮水机提供水源这个现实例子来比喻RAID各个种类 的区别。两个饮水机的出水孔相当于读取数据的接口,而矿泉水桶里的水则是宝贵的数据。这些数据正是通过出水孔这个数据接口而被用户读取的,相应的一个矿泉 水对应着一块硬盘。     正常情况下我们的计算机(例如家的里计算机而不是服务器)是只有一个硬盘的,这时我们要喝水(读取硬盘数据)都是由这一个矿泉水桶提供水源的。(如图2)

raid

(2)接下来看第二个小图,也就是标记着cluster的图。(如图3)所谓cluster就是集群的意思,集群就是用多台服务器合 并为一台,所有服务器提供的服务和数据都是一样的。就像图中显示的有两台饮水机,说明有两台服务器,这两台服务器都可以提供用户数据(水源)。用户可以到 左边的饮水机来取得数据,也可以到右边的饮水机来获得数据,这样无形中就提供了用户获得水(数据)的效率。但是这种cluster集群有一个缺点,那就是 需要多台服务器的硬件支持,在一定程度上造成了浪费。一般来说中小企业是不可能让多台服务器提供同样数据和同样服务的。

raid

(3)第三个小图标记着Hot swap,(如图4)它是热交换的意思。概念上有点类似于热备份。即一台饮水机(服务器),和第一个图一样它有一个硬盘,出水量也和standalone 一样。但是当饮水机上的矿泉水桶出现问题时,例如水没了或者桶破了,这时马上采取热交换技术,将旁边的矿泉水桶替代出问题的桶放到饮水机上,从而继续提供 服务。但是这种方法也存在一个缺点,那就是需要一个桶做备份,而且仅仅在原来桶出问题的情况下该桶才派上用场。另外换桶过程是需要时间的,无形中影响了服 务的提供。

raid

(4)第四个图就是RAID中的老大了,这里说它是老大因为它是最早的RAID。Level 0即RAID 0级,通常称为带区,是利用带区数据映射技巧的特定性能。也就是说,当数据写入磁盘组的时候,被分成带区,交错写入磁盘组的磁盘中。这带来了高I/O性 能,低开销,但不提供任何冗余。磁盘组的存储量等于总的各磁盘容量之和。 (如图5)

raid
当饮水机上的两个桶中任何一个出问题时用户都不能通过出水孔获得宝贵的数据(水源),因此它不提供冗余功能。当然在获得水源的过程中用户是通过两个矿泉水桶同时获得的,自然在出水量等多方面比只使用一个桶有优势。提高了数据读写的速度是RAID 0的最大特色。

小提示:可能有的读者会问在RAID 0图中最上面的那个桶出了问题不是一样可以出水吗?其实这个图仅仅是方便大家记忆和理解RAID,不可能通过简单的图就能100%准确的反映出只有进行理 论描述才能说清楚的RAID种类。因此大家在理解图片的过程中也不要太过于拘泥。
(5)第五个图也是RAID中比较常用的,Level 1即RAID 1级,它就是常常提到的镜像RAID,(如图6)相比其它各级别RAID来说,这个级别使用的时间较长。RAID 1通过把同样的数据写到磁盘组的每一个磁盘上,将”镜像”复制到每个磁盘上,来提供数据冗余。镜像由于它的简单实现和数据的高可信度而一直很受欢迎。 1级在读数据操作时,并行处理2个或更多的磁盘,因此数据传输速率高, 但是其它的操作时无法提供高速的I/O传输速率。1级提供了非常好的数据的高可信度,并且改善了读数据操作的性能,但是耗费很大。要求组成磁盘组的各磁盘 规格相同,而组成后磁盘组的容量仅仅等于一块磁盘的容量。

raid

正如图中显示的一样,有两个矿泉水桶放在饮水机上,这样当其中一个出了问题,例如破坏或没水时并不会影响用户使用矿泉水,因为另一个桶将会完好的提供水 源。当然由于出水口没有出现任何扩大,所以出水量和使用一个矿泉水桶是一样的。因此出水速度没有变化却多加了一个桶使得RAID 1虽然可以提供最大程度的冗余,但是无法提高读取速度。

小提示:有一个细节需要各位IT168的读者特别注意,在RAID 1的图片中是两个矿泉水桶共用一个供水口,自然出水量没有什么变化。而下面的RAID 5则不同。稍后会详细讲解。

(6)第六个图是服务器最常用的RAID级别,即RAID 5。(如图7)笔者所在公司购买的服务器不管是DELL的还是IBM或者曙光服务器都是使用这个最常用的RAID类型。该级别的RAID是通过把奇偶校验分布到磁盘组中的一些或所有磁盘上,5级常使用缓冲技术来降低性能的不对称性。如果组成磁盘组的各磁盘规格相同,磁盘组容量等于磁盘的总容量,减去一块磁盘的容量。

raid

上面提到了RAID 1只是使用了一个供水口,没有提高出水速度。然而在RAID 5中我们会发现图7中三个矿泉水桶分别安装在了三个进水口中,这样我们就可以同时由三个水桶为用户提供水源了,自然在出水速度上得到了大幅度提高。同样三 个矿泉水桶有一个出现问题也没有关系,不会影响到饮用水源。

小提示:有两点是图中没有表现出来的,这里再说明下方便读者有一个清晰的认识。(1)图7中只显示了三个水桶,实际上在现实工作中只要我们有三个以上的硬盘(水桶)就都可以配置RAID5了。四个,五个甚至更多的硬盘来配置RAID 5也是没有问题的。(2)在我们配置RAID 5后如果出现两个以上硬盘出现问题时,数据是不能得到有效的保护的。也就是说RAID 5只能在其中一块硬盘出问题时保证数据完好。

(7)最后一个图实际上是前面介绍的RAID 0和RAID 1的组合,只要大家对RAID 0和RAID 1有了清晰的认识,这个图理解起来就简单得多了,它实际上就是先配置为RAID 0然后在配置RAID 1,相应的发挥了RAID 0和1的所有优点,避免了它们的所有缺点。鉴于篇幅关系这里就不详细介绍了,毕竟RAID 0+1在实际工作中使用的机会没有前面介绍的RAID 5多。(如图8)

raid

总结: 对于服务器不是很熟悉的读者来说,掌握 RAID的概念是最最基本的。它是我们进入服务器知识领域的敲门砖,希望本篇文章中的饮水机图可以帮助大家理解各种RAID和数据冗余类别。最后再重申一 下图片仅仅是为了方便大家理解和记忆,对于RAID这样理论的东西很多细节和特点是无法通过简单的图片所表现出来的,图片描述有不完整的地方还请各位多多 包涵,毕竟本篇文章是写给那些RAID知识门外汉的读者的。

 

分类: maintain 标签: , , , , ,

网站压力测试工具webbench简介、安装、使用

2011年4月1日 1 条评论

webbench最多可以模拟3万个并发连接去测试网站的负载能力,个人感觉要比Apache自带的ab压力测试工具好,安装使用也特别方便。

1、适用系统:

Linux

2、编译安装:

wget http://blog.s135.com/soft/linux/webbench/webbench-1.5.tar.gz
tar zxvf webbench-1.5.tar.gz
cd webbench-1.5
make && make install

3、使用: make && make install 报错

ctags *.c
/bin/sh: ctags: command not found
make: [tags] Error 127 (ignored)
install -s webbench /usr/local/bin
install -m 644 webbench.1 /usr/local/man/man1
install: cannot create regular file `/usr/local/man/man1′: No such file or directory
make: *** [install] Error 1

解决办法:
[root@localhost webbench-1.5]# mkdir /usr/local/man
[root@localhost webbench-1.5]# make && make install

4、测试

[root@localhost webbench-1.5]# webbench -c 500 -t 30 http://127.0.0.1/index.html

5.结果:

Webbench – Simple Web Benchmark 1.5
Copyright (c) Radim Kolar 1997-2004, GPL Open Source Software.

Benchmarking: GET http://127.0.0.1/phpinfo.php
500 clients, running 30 sec.
Speed=10052 pages/min, 7572446 bytes/sec.
Requests: 5026 susceed, 0 failed.

分类: maintain 标签:

ITIL的核心模块

2011年4月1日 没有评论

ITIL核心模块

ITIL的核心模块是“服务管理”,这个模块一共包括了10个流程和一项职能,这些流程和职能又被归结为两大流程组,即“服务提供”流程组和“服务 支持”流程组。其中服务支持流程组归纳了与IT管理相关的一项管理职能及5个运营级流程,即事故管理、问题管理、配置管理、变更管理和发布管理;服务提供 流程组归纳了与IT管理相关的5个战术级流程,即服务级别管理、IT服务财务管理、能力管理、IT服务持续性管理和可用性管理。下面对这些流程进行简要的 介绍。

服务台

服务台是IT部门和IT服务用户之间的单一联系点。它通过提供一个集中和专职的服务联系点促进了组织业务流程与服务管理基础架构集成。服务台的主要目标是协调客户(用户)和IT部门之间的联系,为IT服务运作提供支持,从而提高客户的满意度。

事故管理

事故管理负责记录、归类和安排专家处理事故并监督整个处理过程直至事故得到解决和终止。事故管理的目的是在尽可能最小地影响客户和用户业务的情况下使IT系统恢复到服务级别协议所定义的服务级别。

问题管理

问题管理是指通过调查和分析IT基础架构的薄弱环节、查明事故产生的潜在原因,并制定解决事故的方案和防止事故再次发生的措施,将由于问题和事故对 业务产生的负面影响减小到最低的服务管理流程。与事故管理强调事故恢复的速度不同,问题管理强调的是找出事故产生的根源,从而制定恰当的解决方案或防止其 再次发生的预防措施。

配置管理

配置管理是识别和确认系统的配置项,记录和报告配置项状态和变更请求,检验配置项的正确性和完整性等活动构成的过程,其目的是提供IT基础架构的逻辑模型,支持其它服务管理流程特别是变更管理和发布管理的运作。

变更管理

变更管理是指为在最短的中断时间内完成基础架构或服务的任一方面的变更而对其进行控制的服务管理流程。变更管理的目标是确保在变更实施过程中使用标准的方法和步骤,尽快地实施变更,以将由变更所导致的业务中断对业务的影响减小到最低。

发布管理

发布管理是指对经过测试后导入实际应用的新增或修改后的配置项进行分发和宣传的管理流程。发布管理以前又称为软件控制与分发,它由变更管理流程控制。

服务级别管理

服务级别管理是为签订服务级别协议(SLAs)而进行的计划、草拟、协商、监控和报告以及签订服务级别协议后对服务绩效的评价等一系列活动所组成的一个服务管理流程。服务级别管理旨在确保组织所需的IT服务质量在成本合理的范围内得以维持并逐渐提高。

IT服务财务管理

IT服务财务管理是负责预算和核算IT服务提供方提供IT服务所需的成本,并向客户收取相应服务费用的管理流程,它包括IT投资预算、IT服务成本 核算和服务计费三个子流程,其目标是通过量化服务成本减少成本超支的风险、减少不必要的浪费、合理引导客户的行为,从而最终保证所提供的IT服务符合成本 效益的原则。IT服务财务管理流程产生的预算和核算信息可以为服务级别管理、能力管理、IT服务持续性管理和变更管理等管理流程提供决策依据。

IT服务持续性管理

IT服务持续性管理是指确保发生灾难后有足够的技术、财务和管理资源来确保IT服务持续性的管理流程。IT服务持续性管理关注的焦点是在发生服务故障后仍然能够提供预定级别的IT服务,从而支持组织的业务持续运作的能力。

能力管理

能力管理是指在成本和业务需求的双重约束下,通过配置合理的服务能力使组织的IT资源发挥最大效能的服务管理流程。能力管理流程包括业务能力管理、服务能力管理和资源能力管理三个子流程。

可用性管理

可用性管理是通过分析用户和业务方的可用性需求并据以优化和设计IT基础架构的可用性,从而确保以合理的成本满足不断增长的可用性需求的管理流程。 可用性管理是一个前瞻性的管理流程,它通过对业务和用户可用性需求的定位,使得IT服务的设计建立在真实需求的基础上,从而避免IT服务运作中采用了过度 的可用性级别,节约了IT服务的运作成本。

分类: maintain 标签:

产品版本发布基本流程

2011年3月25日 1 条评论

版本发布流程

项目分类及项目经理/负责人:

XX:

XXX:

XXXX:

XXXXX:

软件版本命名规则及发布流程 

相关定义:

  1. 版本:软件或硬件的设计结果;
  2. 发布:指该版本的软件提交给除设计者外的其它人使用时的行为。这些行为包括在软件测试、软件工程试用、软件正式商用对外提交设计结果的行为;

适用范围:

底层软件的版本命名及发布;

涉及岗位:

1、  设计工程师:软件设计者

2、  版本管理员:软件版本的归档资料是否符合规定的审查者,版本管理软件(VSS)的操作者;

3、  项目经理:版本能否提交的审批者;

4、测试工程师:设计验证的执行者

版本命名规则

       设计的任何一次修改,均应形成新的版本编号;

规则:

×××(1)_×(2)_×.××(3)

说明:

(1)、设计名称:由字母及数字组成;一次彻底的重构可以更换新的名字,如IIP1,IIP2;

(2)、阶段编号:A-研发阶段;B-软件试用阶段;R-软件商用阶段;阶段的定义如下,其中质量问题严重级别(A、B、C、D)的定义参见《研发质量管理办法》

阶段定义 已发现A类质量问题解决率 已发现B类质量问题解决率 已发现C类质量问题解决率 已发现D类质量问题解决率
A阶段 不限 不限 不限 不限
B阶段 100% 50% 不限 不限
R阶段 100% 100% 50% 不限

       注:版本发布后,新发现的质量问不会影响到已有的版本编号,但是会影响到版本编号的升级;例如SDP_B_2.01发布后,新发现了A类质量问题,则在该问题解决前是不能升级到SDP_R_1.00的。只能在SDP_B_*.**系列中升级。

软件发布内容(必须):

1、  源代码及工程文件:设计工程师提供;

2、  版本说明:设计工程师提供;必须包含以下内容:

a)         提交时间

b)        适用硬件版本

c)         开发环境(编译器版本)

d)        更改内容:首次设计可以为空

e)         提交者

3、  编译结果:版本管理员提供;根据内容1编译的结果;

4、  测试报告:测试工程师提供;模板参见《研发质量管理办法》,必须包括以下内容:

a)         测试硬件版本

b)        测试项(用例)

c)         测试方法

d)        测试结果

已知质量问题(包括硬件部分

版本发布流程

1、  设计:设计工程师执行;

2、  白盒测试:测试工程师(通常是研发人员自己)执行;

3、  发布资格审批:项目经理执行;通过转向4,不通过转向1;

4、  资料齐套:设计工程师执行;

5、  发布内容审批:版本管理员执行;通过转向6,不通过转向4;

6、  入库:版本管理员执行;

7、  黑盒测试:测试工程师(测试部人员)执行

8、  发布结果审批:项目经理执行;不通过转向1,通过则本流程结束

分类: maintain 标签: ,

U盘全自动安装linux系统|无人值守快速安装linux

2011年2月22日 没有评论

8分钟安装centos系统,你信吗?

前言:
一杯茶的时间,服务器上的centos系统就安装完成了,而且是按照你的意愿定制安装,这里U盘

安装系统,比光驱安装,节省了不少安装时间,比网络安装节约了一台服务器资源,而且是一劳永逸

,方便保管。

背景:
公司每次有新服务器上架,都要亲自前往机房安装系统,并且是带安装盘和光驱过去安装,显得比较

累赘。这里介绍U盘来自动完成这些事情。

安装前的准备:
1.8G或者16G的u盘一个,(8 G的可以做单个系统版本,16G的可以做多个系统选择安装)
2.Windows版的syslinux.exe(当然可以直接用linux系统自带的syslinux,不过linux的syslinux做引

导处理有点麻烦,所以改用windows版的syslinux.exe.麻烦在哪里?执行完syslinux -s /dev/sda1

后还要来个dd 操作)
3.Centos5.x 系统DVD版ISO文件(32位和64位的ISO文件)
4.Windows.linux 系统平台,用来分区,复制ISO文件和写入mbr等操作

U盘安装的优点:
1.携带方便。选择u盘有电话卡那么大的,直接挂钥匙串上。
2.保存的时间比较长,dvd盘放置一段时间就脏了,影响安装质量。
3.安装速度快。我测试的安装时间在8分钟左右。比光驱快很多。
4.相对于网络安装,配置简单,不需要其他介质。(nfs,dhcp,tftp)

u盘安装达到的效果:
1.自动安装centos5.x 32位版本
2.自动安装centos5.x 64位版本
3.手动选择安装选项来安装centos 5.x 32位版本
4.手动选择安装选项来安装centos 5.x 64位版本

U盘安装命名规则:
U盘插在服务器上应该被认成时sdb,(服务器一块硬盘的情况下,自己的硬盘是sda),在U盘上分3

个区,sdb1 sdb2 sdb3

32位系统的 vmlinuz initrd.img 文件分别命名为 vm32 init32.img
64位系统的 vmlinuz initrd.img 文件分别命名为 vm64 init64.img

U盘分区方案:
分区名 分区大小 分区类型

Linux系统上操作

1.上传ISO文件,(32位和64位的centos)到/mnt/iso1 /mnt/iso2

2.挂接这个镜像文件,以便我们可以使用镜像文件里的目录

3.检验U盘是否被成功识别

4.创建分区。

创建 /dev/sdb1和/dev/sdb2和sdb3三个分区。
其中/dev/sdb1给200M的空间,/dev/sdb2.i给5G,/dev/sdb3给5G,
为什么要分这么多区,这里对/dev/sdb1 操作的时候不会影响到镜像文件,/dev/sdb2 放32位的

centos ,/dev/sdb3放64位的centos。

5.创建文件系统。

这里创建之后,不要忘记有个操作。使用partprobe命令重新读取分区表

6.挂载新分区

7.复制文件操作
复制isolinux

复制ISO文件

复制anaconda,这个文件作为ks的模板,然后在这基础上修改。

查看修改过的自动应答文件。(这里我以32位的centos系统举例)

注意:
这里是32位的系统,手动配置版的cfg文件。64位版的呢,只需要将harddrive –partition=sdb2 –

-dir=/
改为harddrive –partition=sdb3 –dir=/ 即可

(请确定你所键入来源分区和子目录信息的正确性)。
具体kickstart文件介绍,请看http://54im.com/index.php/linux/linux-kickstart-man.html

手动安装centos版本的cfg文件,这里是因为我实验过程中,没法定义U盘的ISO位置,这里我选择假

的自动应答文件,来实现定义镜像位置。

注意:
这里是32位的配置,64位的手动安装centos版配置只需要将harddrive –partition=sdb2 –dir=/
改为harddrive –partition=sdb3 –dir=/ 即可

8.定义syslinux.cfg文件
文件名 /mnt/usb1/syslinux/isolinux.cfg改为/mnt/usb1/syslinux/syslinux.cfg

注意:
说明(以32位系统为例)
label auto-32
kernel vm32
append ks=hd:sdb1:/32ks.cfg initrd=init32.img
这里是做了修改的,其作用是u盘引导到boot界面的时候,输入auto-32 会去读vm32(这个文件是从

ISO复制过来重命名的,vmlinuz)这个文件,然后硬盘方式(u盘也被认为是硬盘)引导系统,其所

需的centos镜像文件在u盘的第二个分区,并且使用kickstart自动安装,指定kickstart配置文件的

路径为/32ks.cfg,即u盘第一个分区的根目录下,然后镜像文件,是刚刚复制过来改过名字的

init32.img

  *.msg Linux启动菜单信息
  vmlinuz Linux内核
  *.img Linux镜像文件
  *.cfg Linux启动配置文件,类似于grub.conf。如果是光盘的话,该文件名是isolinux.cfg,如

果是U盘的话该文件名是syslinux.cfg。

vmlinuz文件该文件是Linux的内核,大小是1M多,不用手工去制作,安装什么版本就去什么版本

的安装光盘中的isolinux目录中找就行了,除非你要自定义内核。该文件可以改名,只要在配置文件

里指定就行了。如果是ISO镜像或光盘引导安装,该文件名的长度可以超过8个字符,最长多少我没有

测试,如果是U盘引导的话,该文件名的长度不能超过8个字符,否则引导启动载入内核时会提示找不

到内核文件。

  *.img文件该文件是Linux启动镜像,大小一般不超过8M,也不用手工去制作,到各版本的安装光

盘的isolinux目录中找就行了。该文件可以重命名,只要在配置文件里指定就行了。如果是ISO镜像

或光盘引导安装,该文件名的长度包括后缀.img可以超过12个字符,最长多少我没有测试,如果是U

盘引导的话,该文件名的长度包括后缀.img不能超过12个字符,否则引导启动载入镜像时会提示找不

到镜像文件

复制32位系统和64位系统的initrd.img和vmlinuz文件到/mnt/usb1/syslinux这里。并且名字叫做

init32.img init64.img vm32和vm64 这里名字是可以自己定义的。

我syslinux下面的文件列表。

9.最后修改boot.msg文件 这里定义选择安装方式界面!

10.windows上的操作。
拔出u盘,把它插在windows系统的机器上,然后执行命令 syslinux.exe -a -m i: 就开始写mbr和

生成文件ldlinux.sys文件。注意u盘在linux下分了3个区,在windows下只能识别被格式化成的dos的

那个分区(/dev/sdb1)。到这一步,前期的处理基本完成了

U盘无人值守安装linux系统

kickstart 语法详解

2011年2月21日 没有评论

kickstart 语法

我们探讨ks.cfg 的相关参数,这些参数笔者将依上述ks,cfg 出现的先后顺序来讨论,有些参数并不是一定要设置。完整的kickstart 参数意义可参考下列网址。

http://www.redhat.com/docs/manuals/enterprise/RHEL-3-Manual/sysadmin-guide/s1-kickstart2-options.html

注:reboot命令应该设置在command区段中,它表示安装完成后重新引导系统。

ks.cfg 文件由三个部份皆组成:

command 区段—此部份包含了必要安装选项

packages 区段—列出欲安装套件

%pre and %post 区段

command 区段

lang(必要):安装时所使用的语言
例如:安装过程中选用中文语言,lang zh_TW.Big5

langsupport (必要):指定系统使用的语言。假如你安装一至多国语系,你必需使用默认选项去指定默认语言。语法为:
例如:langsupport –default en_US.UTF-8 zh_TW.Big5 en_US.UTF-8

键盘(必要):设置系统键盘的种类。语法为:keyboard us

鼠标(必要):设置鼠标。语法为:
mouse- -device=ttvS0(鼠标识别装置位置)- – emulthree(仿真三个按键)generics/2(定义鼠标种类)

timezone(必要) 设置系统时区。timezone Asia/Taipei (指定你的时区位置)

设置系统键盘的种类。语法为:keyboard us

鼠标(必要):设置鼠标。语法为:
mouse- -device=ttvS0(鼠标识别装置位置)- – emulthree(仿真三个按键)generics/2(定义鼠标种类)

xconfig(非必要):在安装过程中手动设置X,假如你不想安装X,你不应该使用此选项。命令的格式为:
xconfig – – card(显示卡类别)- – videoram(指定显示卡记忆容量)- – hsync(指定屏幕水平扫描频率)- – vsync(指定屏幕垂直扫描频率)- – resolution(指定屏幕分辨率) – – depth(指定X 窗口系统彩度)- – startxonboot (假如你想在系统开机时激活X 时使用)- – defaultdesktop gnome(或kde)(指定默认桌面)。

install (非必要):告知系统安装一个新的安装。这是默认模式,因此一个新的安装不需再选用这个命令。接着您必需指定安装方式,可以是cdrom、harddrive、nfs 或url。
cdrom
harddrive—partition=your partition –dir=/your directory path
— partition = 来源分区
— dir = Red Hat 子目录
(请确定你所键入来源分区和子目录信息的正确性)。
harddrive
    从本地驱动器的vfat或ext2格式的红帽安装树来安装.
    –biospart=,从BIOS分区来安装(如82).
    –partition=,从分区安装(如sdb2).
    –dir=,包含安装树的variant目录的目录.
      例如:harddrive –partition=hdb2 –dir=/tmp/install-tree

nfs – server—your server –dir=/your directory path

— server = 指定安装来源服务器
— dir = Red Hat 子目录
(请确定你所键入来源分区和子目录信息的正确性)。

url – url http://your server/dir
使用HTTP 进行安装
url – url ftp://your username:password@your server/dir
使用FTP 进行安装
rootpw (必要) 设置一组系统root 密码。
rootpw – – iscrypted (表示密码已被加密) password
firewall(非必要) 提供安全性等级来保护系统。
authconfig (必要) 设置系统认证选项。命令格式:

– -enablemd5 (使用md5 编码使用者密码)
– -enableshadow (使用shadow 密码)
bootloader (必要) 指定开机管理程序的位置和传递任何kernel 选项。默认开机管理程序为GRUB,但是你也能选择LILO 开机管理程序来取代GRUB。命令格式为:
– – location=mbr (指定开机管理程序的位置)
– -append=(指定要传递的核心参数)。

– -useLilo (使用LILO 为开机管理程序)。
clearpart (非必要)告知系统移除系统上的分区。你可以使用clearpart 移除Linux 分区以及移除所有的分区,或者你也能指定你想要移除分区的磁碟机。命令格式为:

— linux (移除所有Linux 分区)
– – all (移除系统上所有的分区)
— drives = (指定要移除分区的磁盘驱动器)
Part (必要) 安装时是必要的,升级时请忽略。使用这个命令你能为系统建立分区。

package 区段

安装一个新的系统,你必需选择你想安装的套件。选择欲安装的套件是使用%packages 命令。套件可分为单一套件或者是套件组。你能在第一片Red Hat安装光盘下的/base/comps.xml 寻找群组套件清单。

通常,只需列出套件组不需要列出单一套件。注意!默认之下core 和base 群组是被选取的,所以也不需要在 %packages 这个区段下去指定它们。

如同利用ksconfig 所产生出来的ks.cfg %packages 区段中套件组是一行指定一个,以@节号开头,后面加上一格空白接下来是完整群组名称就如同comps.xml 文件所指定。如果个别单一套件并列出该单一套件名,不加上额外的字符。

套件组是一行指定一个,以@节号开头,后面加上一格空白接下来是完整群组名称就如同comps.xml 文件所指定。如果是个别单一套件则列出该单一套件名,前面不需加上额外的字符。

%package 有三个选项可以设置:

– -resolvedeps

决解自动相依性问题及安装套件。建意选项,在安装中由于没使用自动决解相依性,若有相依性问题可能会造成中止安装并且做提示响应。

– -ignoredeps
你选择安装套某套件但乎略它的相依性,可能造成此套件无法运作,尤其是此套件需要其它相依的套件。
—ignoremissing
标示忽视安装遗失套件及群组并且也不做提示响应。

%pre and %post 区段

%pre 区段内可填入在开始安装操作系统需要先执行的工作。%post 命令传递到系统上执行必须在Kickstart 安装完成后。能有效的执行命令去安装其它的软件或者设置系统信息。

分类: linux, maintain 标签: ,

漫画:为什么搞计算机工作的人总是看上去很清闲

2011年2月21日 没有评论

漫画:为什么搞计算机工作的人总是看上去很清闲,我觉得某个职位非常闲,可以说明2点,第一你对工作不负责,态度懒散。没有积极向上的思想。第二,你是一个很有开发视野的人,你知道一劳永逸,你认识自动化带来的方便。这样数量对你来说只是浮云了。

分类: life, linux, maintain 标签: , ,