如何计算服务器可用性指标(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 是每个时间段的长度（秒）。

仲裁是数据库镜像会话中两个或多个服务器实例彼此连接时存在的一种关系。仲裁通常包括三个互连的服务器实例。设置见证服务器时，必须具有仲裁才能使用数据库。仲裁旨在用于具有自动故障转移功能的高安全性模式，可确保一个数据库一次只属于一个伙伴。 如果特定的服务器实例与镜像会话断开连接，则该实例将失去仲裁。如果没有连接任何服务器实例，则会话将失去仲裁，并无法使用数据库。可以进行的仲裁有三种： “完全仲裁”包含伙伴双方以及见证服务器。

“见证服务器-伙伴仲裁”包含见证服务器和一个伙伴。

“伙伴-伙伴仲裁”包含伙伴双方。

下图显示了这三种类型的仲裁。只要当前的主体服务器具有仲裁，它就拥有主体服务器的角色并可继续 *** 作数据库，除非数据库所有者执行手动故障转移。如果主体服务器失去仲裁，它将停止 *** 作数据库。仅当主体服务器失去仲裁时，才会发生自动故障转移，这确保它不再 *** 作数据库。 断开连接的服务器实例将保存其在会话中的最新角色。通常，断开连接的服务器实例将在重新启动并重新获得仲裁时重新连接到会话。 重要提示： 只有在需要使用具有自动故障转移功能的高安全性模式时，才应设置见证服务器。在高性能模式下，由于从不需要见证服务器，因此极力建议将 WITNESS 属性设置为 OFF。有关见证服务器如何影响高性能模式会话中数据库可用性的信息，请参阅异步数据库镜像（高性能模式）。

高安全性模式会话中的仲裁在高安全性模式下，仲裁通过提供上下文来允许自动故障转移，在这个上下文中，具有仲裁的服务器实例可以判定哪个伙伴拥有主体服务器角色。主体服务器如果具有仲裁就可以 *** 作数据库。如果在同步的镜像服务器和见证服务器仍具有仲裁的时候主体服务器丢失仲裁，则会发生自动故障转移。 高安全性模式的仲裁方案包括： 包含伙伴双方和见证服务器的“完全仲裁”。

所有三个服务器实例通常都参与三方仲裁，这称为“完全仲裁”。使用完全仲裁，主体服务器和镜像服务器一直执行其各自的角色（除非发生手动故障转移）。

包含见证服务器和一个伙伴的“见证服务器-伙伴仲裁”。

如果因为其中一个伙伴丢失而中断伙伴之间的网络连接，则可能发生下列两种情况：

镜像服务器丢失，主体服务器和见证服务器仍具有仲裁。

在这种情况下，主体服务器将数据库设置为 DISCONNECTED，并在镜像处于 SUSPENDED 状态的情况下运行。（因为数据库当前尚未镜像，所以这称为“公开运行”。）镜像服务器重新联接会话时，它将作为镜像服务器重新获得仲裁，并开始与其数据库副本重新同步。

主体服务器丢失，见证服务器和镜像服务器仍具有仲裁。

在这种情况下，发生自动故障转移。有关详细信息，请参阅自动故障转移。

两个伙伴与见证服务器之间保持连接时，故障转移伙伴之间的网络连接很少会断开。在这种情况下，存在两个分开的见证服务器-伙伴仲裁，见证服务器作为连接。见证服务器将通知镜像服务器：主体服务器仍在连接状态。因此，不会出现自动故障转移。而镜像服务器将保留镜像角色并等待重新连接到主体服务器。如果此时重做队列包含日志记录，镜像服务器将继续前滚镜像数据库。重新连接后，镜像服务器将与镜像数据库重新同步。

包含伙伴双方的“伙伴-伙伴仲裁”。

只要伙伴仍具有仲裁，数据库就会继续处于 SYNCHRONIZED 状态，手动故障转移就可以进行。如果没有见证服务器，则无法使用自动故障转移功能；但当见证服务器重新获得仲裁时，会话将恢复正常 *** 作，并重新支持自动故障转移。

会话丢失仲裁。

如果所有服务器实例此间的连接断开，就称为会话“丢失仲裁”。当服务器实例恢复彼此间的连接时，它们将重新获得相互仲裁。

如果主体服务器与其他服务器实例中的任何一个重新连接，即可使用数据库。

如果主体服务器依旧断开连接，但镜像服务器和见证服务器恢复了相互之间的连接，则不能进行自动故障转移，因为可能会丢失数据。因此，在主体服务器重新加入会话之前，依旧不能使用数据库。

当三个服务器实例全部恢复连接时，将重新获得完全仲裁，会话将恢复其正常 *** 作。

重要提示： 当会话具有伙伴-伙伴仲裁时，如果任一伙伴失去仲裁，会话将失去仲裁。因此，如果您希望见证服务器在很长一段时间内保持断开，我们建议您暂时将见证服务器从会话中删除。如果删除见证服务器，则不再需要仲裁。然后，如果镜像服务器断开连接，则主体服务器可以继续 *** 作数据库。有关如何添加或删除见证服务器的信息，请参阅数据库镜像见证服务器。

仲裁如何影响数据库可用性下图显示的是见证服务器与伙伴如何相互作用，以确保在给定时间内，只有一个伙伴拥有主体服务器角色并且只有当前主体服务器才能使其数据库在线。两个方案都以完全仲裁（Partner_A 具有主体角色，Partner_B 具有镜像角色）为起点。方案1 显示的是：在原始主体服务器 (Partner_A) 失败后，见证服务器和镜像服务器如何同时认定主体 Partner_A 不再可用并构造仲裁。然后，镜像服务器 Partner_B 承担主体角色。出现自动故障转移时，Partner_B 使其数据库副本在线。然后 Partner_B 出现故障，数据库离线。随后，先前的主体服务器 Partner_A 重新连接到见证服务器重新获取仲裁，但是通过与见证服务器通信，Partner_A 获知不能使其数据库副本在线，因为 Partner_B 现在拥有主体角色。当 Partner_B 重新加入会话时，将使数据库恢复在线。在方案 2 中，见证服务器丢失仲裁，而伙伴 Partner_A 和Partner_B 彼此保留仲裁，数据库保持在线。然后，伙伴们也失去其仲裁，数据库处于离线状态。随后，主体服务器 Partner_A 重新连接到见证服务器以重新获取仲裁。见证服务器确认 Partner_A 仍拥有主体角色，并且 Partner_A 使数据库恢复在线。

一台服务器多个数据库运行，是完全可以的。

服务器安装数据库，不仅可以一个数据库服务，运行多个网站的库。

还可以在同一台服务器，运行多个不同的数据服务。

比如一个mysql，运行多个PHP站点，多个数据库。

而且还可以一台服务器同时运行，mysql数据库和sqlserver数据库。

扩展资料：

可以从这几个方面来衡量服务器是否达到了其设计目的；

R：Reliability可靠性；

A：Availability可用性；

S：Scalability可扩展性；

U：Usability易用性；

M：Manageability可管理性，即服务器的RASUM衡量标准。

可扩展性：服务器必须具有一定的“可扩展性”，这是因为企业网络不可能长久不变，特别是在当今信息时代。

如果服务器没有一定的可扩展性，当用户一增多就不能胜任的话，一台价值几万，甚至几十万的服务器在短时间内就要遭到淘汰，这是任何企业都无法承受的。为了保持可扩展性，通常需要在服务器上具备一定的可扩展空间和冗余件。

可扩展性具体体现在硬盘是否可扩充，CPU是否可升级或扩展，系统是否支持WindowsNT、Linux或UNIX等多种可选主流 *** 作系统等方面，只有这样才能保持前期投资为后期充分利用。

参考资料来源：百度百科-服务器

---