安全数据传输涉及通过安全传输协议(如安全套接字层 (Secure Sockets Layer, SSL) 或传输层安全 (Transport Layer Security, TLS))处理事务。通过安全传输处理的事务通常需要额外的计算能力先建立安全会话(称为握手),然后对传输的数据进行加密和解密。额外的计算能力要求可能相当大,这取决于所使用的加密算法(例如,40 位还是 128 位加密算法)。
为使安全事务具有与非安全事务相同水平的性能,必须对额外计算能力进行规划。安全事务可能需要高于非安全事务四倍(甚至更多倍)的计算能力,具体取决于事务的性质和处理事务的 Sun JavaTM Enterprise System 服务。
估计处理安全事务的处理能力时,首先要分析使用案例来确定需要安全传输的事务所占的百分比。如果安全事务的性能要求与非安全事务相同,则需修改 CPU 数量估计,将安全事务所需的额外计算能力考虑在内。
在某些使用方案中,可能只有在验证时才需要进行安全传输。用户通过系统验证后,便不需要对数据传输采取额外安全措施。但在其他方案中,可能所有事务都需要安全传输。
例如,浏览在线电子商务站点的产品目录时,客户完成商品挑选并准备“付帐”前,所有事务都可以是非安全的。不过,某些使用方案(如银行或证券经纪行部署)要求大多数或全部事务必须为安全事务,并对安全与非安全事务有着相同的性能标准。
本节将继续使用示例部署,说明如何计算得出既包括安全事务又包括非安全事务的理论性使用案例所需的 CPU 数量。
要估计安全事务的 CPU 数量要求,请进行以下计算:
以 CPU 数量估计底线数(如上一节示例的估计处理器要求中计算的数字)作为起始数量。
计算需要安全传输的事务的百分比,然后计算安全事务的 CPU 数量估计。
计算非安全事务减少的 CPU 数量估计。
将安全和非安全数量估计相加,计算出总 CPU 数量估计。
将 CPU 数量估计向上舍入到最近的偶数。
安全事务的 CPU 数量估计显示了一个基于 Portal Server 的使用案例和用量分析的示例计算,其中假设:
所有登录均要求安全验证。
所有登录占 Portal Server 总负载的 10%。
安全事务的性能要求与非安全事务相同。
要将处理安全事务的额外计算能力考虑在内,处理这些事务的 CPU 数量将增加为四倍。与本例中其他 CPU 数字一样,该倍数也只是说明性的随意倍数。
步骤 |
说明 |
计算 |
结果 |
---|---|---|---|
1 |
以所有 Portal Server 事务的估计底线作为起始数量。 |
研究峰值负载用量的使用案例中的估计底线为 4 个 CPU。 |
- - - - - |
2 |
计算安全事务的附加 CPU 数量估计。假设安全事务需要的 CPU 能力为非安全事务的四倍。 |
估计底线的百分之十需要安全传输:
0.10 x 4 CPU = 0.4 CPU
将安全事务的 CPU 能力增加为四倍:
4 x 0.4 = 1.6 CPU |
1.6 个 CPU |
3 |
计算非安全事务减少的 CPU 数量估计。 |
估计底线的百分之九十为非安全传输:
0.9 x 4 CPU = 3.6 CPU |
3.6 CPU |
4 |
计算调整后的安全与非安全事务的 CPU 数量估计总数。 |
安全数量估计非安全数量估计总数:
1.6 CPU + 3.6 CPU = 5.2 CPU |
5.2 CPU |
5 |
向上舍入到最近的偶数。 |
5.2 CPU ==> 6 CPU |
6 CPU |
根据本例中的安全事务计算,通过添加额外的两个 CPU 和 4 GB 内存,修改安全事务的 CPU 数量估计中的总 CPU 数量估计,得到以下用于 Portal Server 的总数。
组件 |
CPU |
内存 |
---|---|---|
Portal Server |
6 |
12 GB |
可以利用专用硬件设备(如 SSL 加速卡和其他装置)提供建立安全会话和加密与解密数据所需的计算能力。使用专用硬件进行 SSL 运算时,计算能力专用于 SSL 计算的特定部分,通常是建立安全会话的“握手”运算。
这种硬件可能会对最终部署体系结构有益。不过,由于此类硬件的专用化性质,最好先以 CPU 能力估计出安全事务的性能要求,然后再考虑使用专用硬件处理额外负载的益处。
使用专用硬件时应考虑的一些因素有:使用案例(例如,要求大量 SSL 握手运算的使用案例)是否支持使用该硬件及使用此类硬件给设计增添的复杂性。这种复杂性包括这些设备的安装、配置、测试和管理。