如何计算服务器可用性指标(SAI)?

参照此表，您可以估算出服务器在繁忙时段的平均扩展系数，并且还可以为 Server_Transinfo_Range 设定合理的数值，以此得到一个比较理想的服务器可用性指标。以下内容节选自 Domino Administrator 6.5.1 帮助文档。集群中的每个服务器都定期判断自己的工作负载，判断将基于服务器最近处理请求的响应时间作出。系统用 0 到 100 之间的数字表示工作负载，其中 0 表示服务器负载过重100 表示服务器负载很轻。这个数值称为服务器的可用性指标。随响应时间增加，服务器可用性指标减小。服务器的可用性指标约等于仍然可用的总服务器容量百分比。例如，如果服务器的可用性指标为 65，则仍然有 65% 的服务器容量可用。尽管企业中的服务器功率和资源可能不同，但每台服务器上的服务器可用性指标都代表同一件事 -- 仍然可用的服务器容量。服务器可用性指标基于扩展系数生成，用于指示服务器上的当前工作负载。扩展系数是由特定类型事件的响应时间与服务器曾经完成此类事务的最短时间之比决定的。例如，如果服务器当前执行“打开数据库”事务的平均时间为 12 毫秒，而服务器曾经执行“打开数据库”事务的最短时间为 3 毫秒，则“打开数据库”事务的扩展系数为 4（当前时间 12 毫秒除以最快时间 3 毫秒）。换言之，扩展系数决定完成当前事务所花的时间是在最佳条件下所花时间的多少倍。IBM(R) Domino(TM) 将每种事务的最短时间存储在内存和 LOADMON.NCF 文件中，服务器每次启动时都会读取该时间。服务器关机时，Domino 会用最新信息更新 LOADMON.NCF 文件。为确定当前的扩展系数，Domino 会在指定的时间段内跟踪最常用的几种 Domino 事务类型。缺省情况下，Domino 会在 5 个时间段内跟踪这些事务，每段时间为 15 秒。然后，Domino 就可以确定完成每种事务平均要花的时间，并用该时间除以它曾经完成每种同类事务所花的最短时间。这样就可确定每种事件的扩展系数。为确定整个服务器的扩展系数，Domino 会取所有类型事务的扩展系数的平均值，并对最常用的事务类型给予较大的加权数。当服务器繁忙时，对服务器添加更多负载会显著地影响服务器的性能和可用性。因此，向繁忙的服务器中添加负载也比向不繁忙的服务器中添加负载要更快地增大扩展系数。因为各个服务器的速度、容量和处理能力各不相同，能够处理的工作负载也不尽相同。所以，两个不同服务器的扩展系数相同并不一定意味着二者能够承担相当的工作负载。例如，对于一个在空闲状态下执行事务都需要花费很长时间的小型服务器来说，扩展系数 40 可能表示用户需要等待若干秒才能得到响应。而对于一个处理速度非常快的超大型服务器来说，扩展系数 400 可能表示用户只需等待不到一秒的时间就能得到响应。注意：下表中的值是根据扩展系数 64 生成的，该值表示服务器处于满负载状态。 扩展系数可用性指标 1<nozeros>100<nozeros>2<nozeros>83<nozeros>4<nozeros>67<nozeros>8<nozeros>50<nozeros>16<nozeros>33<nozeros>32<nozeros>17<nozeros>64<nozeros>0<nozeros>注意：扩展系数和可用性指标仅用于度量服务器响应时间，该时间通常只是客户机经历的响应时间的一小部分。例如，客户机和服务器之间的网络响应时间通常占客户机经历的响应时间的很大部分。更改表示服务器处于满负载状态的扩展系数值 要有效利用 Domino 工作负载平衡，必须调整扩展系数与可用性指标之间的关系，以便服务器在达到预期的故障转移工作负载时进行故障转移。通过指定表示服务器处于满负载状态的扩展系数值，可以实现此目的。Domino 中的缺省值为 64。当扩展系数达到该值时，便可将服务器视为负载已满，可用性指标降为 0（零）。如果服务器的功能特别强大，处理速度特别快，则可提高表示服务器处于满负载状态的扩展系数值。对于一些处理速度极快的服务器来说，该值可以提高到几百或更高。如果服务器的处理速度特别慢，则可降低该值。要更改表示满负载服务器的扩展系数值，请将下面的设置添加到 NOTES.INI 文件，然后重新启动服务器。SERVER_TRANSINFO_RANGE= n 其中，值 n 表示服务器处于满负载状态的扩展系数值等于 2 的 n 次幂。 n 的缺省值为 6，这说明扩展系数值为 64，因为 2 的 6 次幂为 64如果将 SERVER_TRANSINFO_RANGE 设为 7，则满负载时的扩展系数值为 128如果将 SERVER_TRANSINFO_RANGE 设为 8，则该值为 256。要确定 SERVER_TRANSINFO_RANGE 的最优值，请执行下列操作：1. 在服务器负载过重的期间内，监控服务器的扩展系数。可以使用控制台命令“show stat server.expansionfactor”来执行此任务。另外，还可以在这些期间内监控性能统计信息。记录有关此类期间的足够多的扩展系数值，以便确定使用哪个扩展系数值来表示服务器处于满负载状态。 2. 为 SERVER_TRANSINFO_RANGE 确定一个值，以 2 为底数, 该值为指数计算而得的值，即为在步骤 1 中选择的扩展系数值。 如果更改了表示服务器处于满负载状态的扩展系数值，扩展系数与可用性指标之间的关系就会发生变化。下表列出了当 SERVER_TRANSINFO_RANGE 值为 8 时的一些扩展系数以及由之转换而来的可用性指标。因为 2 的 8 次幂为 256，所以本例中的最大扩展系数为 256。扩展系数可用性指标1<nozeros>100<nozeros>2<nozeros>88<nozeros>4<nozeros>75<nozeros>8<nozeros>63<nozeros>16<nozeros>50<nozeros>32<nozeros>38<nozeros>64<nozeros>25<nozeros>128<nozeros>13<nozeros>256<nozeros>0<nozeros>更改用于计算扩展系数的数据量 尽管不是必需的操作，但还是可以使用下列 NOTES.INI 设置来更改 Domino 收集用以配置扩展系数的数据量。 要更改 Domino 使用的数据收集时间段数，请使用 NOTES.INI 的 Server_Transinfo_Max=x 设置，其中 x 是您希望 Domino 使用的收集时段数量。 要更改每个数据收集时间段的时间长度，请使用 NOTES.INI 的 Server_Transinfo_Update_Interval=x 设置，其中 x 是每个时间段的长度（秒）。

云安全中心服务等级协议  版本生效日期：2020年4月1日

本服务等级协议（Service Level Agreement，以下简称 “SLA”）规定了阿里云向客户提供的云安全中心（简称“云安全中心”）的服务可用性等级指标及赔偿方案。

1.定义

1.1服务周期：一个服务周期为一个自然月。

1.2服务周期总分钟数：服务周期内的总天数╳24（小时）╳60（分钟）计算。

1.3失败请求：失败请求包括下述情形：

（1）因云安全中心系统原因导致的域名返回状态码为5XX请求；

（2）因云安全中心故障导致的正常请求未能到达云安全中心服务器端的请求（通过故障前7天内使用云安全中心的域名的平均请求数计算）。

1.4有效的总请求：客户某一阿里云账号下云安全中心服务器端接收到的所有请求视为有效的总请求。

1.5每5分钟错误率：根据地域以每5分钟为单位按照如下方式计算：

每5分钟错误率= 每5分钟失败请求数/每5分钟有效总请求数X100%                                          

1.6月度服务费用：按一个自然月中客户某一阿里云账号下云安全中心的地域统计月度服务费用，如果客户一次性支付了多个月份的服务费用，则将按照所购买的月数或使用量比例分摊计算月度服务费用。

2.服务可用性

2.1 服务可用性计算公式

云安全中心服务可用性按服务周期统计，根据客户某一阿里云账号下云安全中心的地域统计服务可用性。若客户某一阿里云账号下存在相同地域，将合并计算服务可用性。

服务可用性将根据服务周期内每5分钟错误率之和除以服务周期内5分钟的总个数计算出每5分钟错误率的平均值，从而计算得出服务可用性，即：

服务可用性=（1-服务周期内Σ每5分钟错误率/服务周期内5分钟总个数）x100%   （注：服务周期内5分钟总个数=12x24X该服务周期的天数）

2.2 服务可用性承诺

云安全中心服务可用性不低于99.95%，如云安全中心未达到前述可用性承诺，客户可以根据本协议第3条约定获得赔偿。

2.3除外情形

因下述原因导致的服务不可用的时长不计入服务不可用时间：

（1）阿里云预先通知客户后进行系统维护所引起的，包括割接、维修、升级和模拟故障演练；

（2）任何阿里云所属设备以外的网络、设备故障或配置调整引起的；

（3）客户的应用程序或数据信息受到黑客攻击而引起的；

（4）客户维护不当或保密不当致使数据、口令、密码等丢失或泄漏所引起的；

（5）客户的疏忽或由客户授权的操作所引起的；

（6）客户未遵循阿里云产品使用文档或使用建议引起的；

（7）不可抗力引起的。

3.赔偿方案

3.1 赔偿标准

根据客户某一阿里云账号下云安全中心的服务可用性，按照下表中的标准计算赔偿金额，赔偿方式仅限于用于购买云安全中心产品的代金券，且赔偿总额不超过未达到服务可用性承诺当月客户支付的月度服务费用的25%（不含用代金券抵扣的费用）。

服务可用性赔偿代金券金额

99.90%  ≤ 服务可用性 ＜ 99.95%月度服务费用的10%

服务可用性 ＜ 99.90%月度服务费用的25%

3.2赔偿申请时限

客户可在每个自然月第五（5）个工作日后对上个月没有达到服务可用性承诺的【产品简称】提出赔偿申请。赔偿申请最迟不应晚于云安全中心未达到服务可用性承诺的相关月份结束后两（2）个月内提出。

4.其他

阿里云有权对本SLA条款作出修改。如本SLA条款有任何修改，阿里云将提前30天以网站公示或发送邮件的方式通知您。如您不同意阿里云对SLA所做的修改，您有权停止使用云安全中心，如您继续使用云安全中心，则视为您接受修改后的SLA。

通俗的说，就是如何减少邮箱服务器的停机时间。保证企业的邮箱服务器，能够无故障的运行，是我们邮箱管理人员的职责。但是，月有阴晴圆缺，天有不测风云，邮箱服务器也会有生病的时候。所以，在邮箱服务器部署的时候，我们还需要对邮箱服务器的可用性进行评估，看看其存在哪些风险，可能会降低邮箱服务器的可用性。在邮箱服务器可用性的评估方面，没有量化的指标，更多的是总结前人的经验。下面笔者就把自己在这方面的一些心得列举一下，后续对大家有所帮助。总的来说，我们可以从五个方面来评估邮箱服务器的高可用性所可能遭遇到的风险。第一：环境风险。邮箱服务器由于其要一年365天，天天无休的运行，所以其可以算得上是一个比较娇嫩的设备，对于外界环境的要求也比较高。在对邮箱服务器的可用性进行评估时，笔者往往从相对来说比较简单的环境问题开始。如需要看看供电的情况。持续的供电以及稳定的电压这是邮箱服务器可用性的基本要求。可惜的是，很少有企业能够做到这一点，特别是在电压方面，要保证其稳压是一件比较困难的事情。所以，在部署企业邮箱服务器的时候，在供电方面，笔者是建议大家一定要部署带稳压功能的UPS。这个设备可以保证给邮箱服务器提供稳定的电流，当出现意外停电时，还可以提到一定的保护作用。如机房是否有防灾难措施。笔者所在的企业，服务器比较多。为此企业专门划出了一个办公室用来存放服务器。这个存储服务器空间，跟我们的办公室是独立的，也就是说，没有人再这个存储各种服务器的房间内办公。因为人走进走出，灰尘会比较多。而且，磕磕碰碰的事情也免不了。所以，笔者建议，企业无论是邮箱服务器，还是部署了其它服务器应用，最好能够划分一个独立的空间来存放他们。并且，可以配备摄像头或者报警器等等，防止服务器被偷等等。所以，机房的防灾难措施是否得当，也是影响邮箱服务器可用性的一个重要因素。在这个环境问题上，还有诸如灰尘、温度、湿度、线路布置等方面的考虑。当企业对于邮箱服务器的高可用性要求比较严格的时候，则在这些小问题上，也不能够忽视。第二：硬件风险。我们在部署邮箱服务器的时候，硬件也会影响邮箱服务器的可用性。如是否有冗余的电源。因为邮箱服务器要一年365天不休的运转，所以，对于电源是一个很大的考验。根据笔者的了解，即使服务器的电源考虑到了这个问题，采取了比较好的材料，但是，仍然会经常出现因为电源故障而导致的服务器当机的现象。故，为了降低因为服务器电源问题导致的服务器故障的影响，笔者推荐的方法就是采用冗余电源。如笔者现在在给客户部署邮箱服务器的时候，都是建议企业在购买服务器的时候，要购买那些带冗余电源的服务器，也就是说提供两个电源的服务器。并且，当一个电源出现故障的时候，需要马上进行更换。如此的话，当一个电源出现问题，另外一个冗余电源可以马上接替其工作，从而防止断电现象的发生，提高邮箱服务器的可用性。如磁盘空间的不合理规划，也会降低邮箱服务器的可用性。最常见的就是因为磁盘空间不足而导致的应用程序停止响应。所以，在磁盘空间规划上面，一方面要购买足够大的硬盘，反正现在硬盘的价格也不贵。另一方面，可以考虑采用磁盘限额。笔者在实际的工作中，发现很多员工没有定时清理邮箱的习惯，他们在企业中工作个十年，可能他们的邮件就会在邮箱服务器中保留个十年，这是一种很浪费磁盘空间的行为。而且，有些员工也会把邮箱服务器当作文件备份服务器来使用，把一些重要的文件干脆就放在邮箱服务器中。针对这种情况，在磁盘规划的时候，可以考虑为每个用户设置磁盘限额，以减轻对磁盘空间的压力。最后，在磁盘规划的时候，需要设置磁盘空间报警，当磁盘不足的时候，如使用量已经到达80%的时候，向管理员报警。让管理员可以有足够的时间来处理这件事情，是加硬盘呢，还是清理硬盘中的文件。如此的话，可以防止直到硬盘空间已经耗竭的时候，再来想处理的方法。所以，邮箱服务器的硬件设置也是影响其可用性的一个重要方面。在硬件配置上，冗余是保障高可用性的一个重要举措。

---