|
| |
| Sun Java Enterprise System 部署规划白皮书 | |
第 5 章
设计部署体系结构本章介绍针对性能、安全性、可用性及其他系统特性设计部署的方法。本章还介绍部署设计优化的相关信息。
部署体系结构描述逻辑体系结构与物理环境的映射关系。物理环境包括内联网或 Internet 环境中的计算节点、CPU、内存、存储器设备及其他硬件和网络设备。
设计部署体系结构涉及部署估量，以确定满足技术要求阶段指定的系统要求所必需的物理资源。还要通过分析部署估量的结果来优化资源，使所形成的设计能够在受业务约束的情况下最充分地利用资源。
部署体系结构设计完成后，项目核准 阶段的任务是评估部署的实际成本。项目一经核准，即需签署部署完成合同和获取项目实现所需的资源。
应在项目核准前或核准后制订详细设计规范。详细设计规范用于在实现阶段扩展设计。
本章继续使用第 4 章的示例部署来说明部署体系结构设计过程中的各个步骤。
本章包括以下节：
计划部署估量计划部署估量是确定满足系统要求并最终实现业务目标所必需的硬件资源的过程。与部署规划和设计的其他方面一样，估量并不是一门精确的科学，不能用公式和配方来规定。只有参照以往的设计经验，凭借所掌握的系统体系结构知识和特定领域知识，并发挥创造性思维，才能成功完成估量工作。
估量要围绕先前为以下系统特性确定的系统要求（系统要求中所述的系统要求）进行。此外，部署设计早期阶段的业务要求、用量分析和使用案例在系统估量中也发挥着一定的作用。
执行估量工作时，使用案例和用量分析有助于确定使用案例所必需的支持资源。估量通常从最大加权的使用案例（代表最常见的事务量）开始，最后估量的是最小加权的使用案例。使用加权使用案例有助于根据预期的系统负载分配资源。
以下各节就如何针对下列系统特性进行部署估量提供了一般性指导：
性能导向估量
性能和负载要求导向估量是一个反复进行的过程，它对支持部署系统中的服务所需的 CPU 数量和内存大小进行估计。估计支持服务所需的 CPU 数量时，请考虑下列各项：
性能导向估量过程通常由下列步骤组成。这些步骤的执行顺序并非关键所在，这一顺序只是提供了考虑可对最终结果产生影响的因素的一种方式。
为用户入口点确定 CPU 数量估计底线
先估计处理每个作为用户入口点的组件的预期负载所需的 CPU 数量，然后在逻辑体系结构的布局设计图上标注估计值。
下图使用的是部署规划示例中介绍的示例部署，它描述作为用户入口点的组件的初始 CPU 数量估计。这些估计值所代表的是通过系统要求分析、使用案例和用量分析而可能得到的数字。
图 5-1 提供用户入口点组件的 CPU 数量估计底线
针对服务依赖性调整 CPU 数量估计
提供用户入口点的组件需要其他 Java Enterprise System 服务的支持。为继续指定性能要求，请调整性能估计，将必需的其他组件支持考虑在内。
在本例中，检查图4-4 所示的逻辑数据流动，为给其他组件提供支持的组件作出调整。下表总结了对 CPU 数量估计所做的调整。可指定含小数的 CPU 数量估计。完成性能估计后，系统会对 CPU 计数求和并向上舍入。
与前一节中的估计一样，下表中的性能估计也只是说明性的随意值。
表 5-1 支持服务的 CPU 数量估计
服务
数量估计
说明
Portal Server
无
不为其他服务提供支持。
Calendar Server
1 个 CPU
支持：
Messaging Server
1.5 个 CPU
支持：
Identity Server
3 个 CPU
支持：
Directory Server
5 个 CPU
支持：
下图根据表5-1 中的信息更新性能导向估计数量。
图 5-2 针对支持服务调整后的 CPU 数量估计
针对潜在容量、可伸缩性和可用性要求调整 CPU 数量估计
性能导向估量完成后，需向上舍入 CPU 数量数字。通常将 CPU 数量向上舍入到最近的偶数。对 CPU 数量估计进行向上舍入时，请考虑以下因素：
下图针对示例部署调整了 CPU 数量估计。图中还标明了每个 CPU 的内存要求。本例假设每个 CPU 需要 2GB 内存。本例中的这些内存数字只是说明性的随意数字。计算每个 CPU 所需的内存不在本白皮书讨论的范围之内。
图 5-3 包括内存要求在内的性能数字
安全性估量
进行部署估量时，应在以下方面将安全性问题作为考虑的因素：
安全数据传输涉及通过安全传输协议（如安全套接字层 (SSL)）处理事务。用户验证也可能需要通过安全传输处理事务。
通过安全传输处理的事务通常需要额外的计算能力先建立安全会话（称为握手），然后对传输的数据进行加密和解密。额外的计算能力要求可能相当大，这取决于所使用的加密算法（例如，40 位还是 128 位加密算法）。
为使安全事务具有与非安全事务相同水平的性能，必须对额外计算能力进行计划。安全事务可能需要四倍（甚至更多倍）的计算能力，具体取决于事务的性质和处理事务的 Java Enterprise System 服务。
估计处理安全事务的性能要求时，首先要分析使用案例来确定需要安全传输的事务所占的百分比。如果安全事务的性能要求与非安全事务相同，则需修改 CPU 数量估计，将安全事务所需的额外计算能力考虑在内。
在某些使用方案中，可能只有在验证时才需要进行安全传输。用户通过系统验证后，便不需要对数据传输采取额外安全措施。但在其他方案中，可能所有事务都需要安全传输。在许多情况下，合理的估计是有百分之五到十的事务需要安全传输。
例如，浏览在线电子商务站点的产品目录时，客户完成商品挑选并准备“付帐”前，所有事务都可以是非安全的。而且，许多这类电子商务站点均放宽了对安全事务的潜在响应要求。不过，某些使用方案（如银行或证券经纪行部署）要求大多数（即便不是全部）事务必须为安全事务，并对安全与非安全事务有着相同的性能标准。
计算安全事务性能
本节继续使用示例部署来说明一个工作单，它用于计算一个既包括安全事务又包括非安全事务的使用案例的 CPU 数量要求。
要计算 CPU 数量要求，请在工作单中进行以下计算：
- 以 CPU 数量要求底线（如在上一节性能导向估量中计算的数字）作为起始数量。
- 计算需要 SSL 的事务的百分比，然后计算 SSL 事务的 CPU 数量要求。
- 针对非安全事务调整 CPU 计算。
- 将安全和非安全数量要求相加，计算出总 CPU 数量要求。
图 5-4 中的工作单的依据是 Portal Server 的额外使用案例和用量分析。以下是额外使用案例和用量分析的前提：
就本例而言，由于要将处理 SSL 事务的额外计算能力考虑在内，处理这些事务的 CPU 数量将增加五倍。与本例中其他 CPU 数字一样，该数字也只是说明性的随意数字。
图 5-4 计算安全事务 CPU 数量估计的工作单
处理 SSL 事务的专用硬件
可以利用专用硬件设备（如 SSL 加速卡和其他装置）提供建立安全会话和/或加密和解密数据所需的计算能力。使用专用硬件进行 SSL 运算时，计算能力专用于 SSL 计算的特定节，通常是建立安全会话的“握手”运算。
这种硬件可能会对最终部署体系结构有益。不过，由于此类硬件的专用化性质，最好先以 CPU 能力估计出安全事务的性能要求，然后再考虑使用专用硬件处理额外负载的益处。
使用专用硬件时应考虑的一些因素有：使用案例（例如，要求大量 SSL“握手”运算的使用案例）是否支持使用该硬件及使用此类硬件给设计增添的复杂性。这种复杂性包括这些设备的安装、配置、测试和管理。
可用性估量
完成性能估量后，便可开始进行系统可用性估量。这一过程的任务是，指定逻辑体系结构中的组件的宿主服务器及为各种 Java Enterprise System 组件设计负载平衡、冗余和故障转移策略。
研究使用案例和用量分析，以确定应予考虑的可用性解决方案。下列项目是为帮助确定可用性策略而需收集的信息类型的示例：
为每个组件分析使用案例，以确定最适合组件的、符合故障转移和负载平衡要求的解决方案。还要考虑使用案例和用量分析，以确定实现服务负载平衡的最佳方式。
所选的可用性策略还必须考虑可维护性问题中阐述的可维护性要求。尽量避免采用以易管理系统组成的复杂解决方案，此类方案需要花费相当大的管理和维护成本。
复杂系统的目录设计
涉及大量用户的复杂部署可能需要为 Directory Server 进行目录设计，而这可能会影响可用性策略。这是因为 LDAP 目录设计可能会影响 Identity Server 和 Messaging Server 的可用性策略，进而可能影响其他系统特性。
如果要设计复杂部署，请考虑创建一个初步目录设计来协助可用性设计，在后续的详细设计制订或开发阶段再提供完整的目录设计。
硬件和软件故障
可用性设计应提供硬件和软件故障保护。软件故障的代价通常高于硬件故障。软件故障的平均间隔时间长于硬件故障的平均间隔时间。此外，软件故障诊断和修复的难度更大，故障防范所需投入的管理和维护成本也更高。
可用性的一般设计方法
本节提供可用性要求的一般设计方法。具体可用性设计不在本白皮书讨论的范围之内。
单服务器系统
将服务的所有计算资源置于单个服务器上。如果服务器发生故障，整个服务便终止运行。
图 5-5 单服务器
Sun 提供具有下列优点的高端服务器：
一台高端服务器的价格通常高于具有可比性的多服务器系统。不过，单个服务器可节省对数据中心多台服务器的管理、监视和驻扎成本。但多服务器系统在负载平衡、故障转移和解除单个故障点方面的灵活性更强。
水平冗余系统
利用可提供负载平衡和故障转移两种功能的平行冗余服务器提高可用性的方法有若干种。下图显示的是组成一个 N+1 可用性系统的两台复制服务器。其中一台服务器发生故障时，N+1 系统通过一个额外组件继续提供 100% 容量。
图 5-6 两台复制服务器
上面图 5-6 中每台服务器的计算能力都完全相同。一台服务器即可满足性能要求，另一台服务器作为备份服务器调入服务时，也可提供 100% 的性能。
复制服务器这种设计的优点是，故障转移情况下仍可达到 100% 的性能； 缺点是增加了硬件成本，而总体性能却未得到相应提升。
下图所显示的是这样一种方案：通过在两台服务器间分配性能负载来满足负载平衡和故障转移要求。
图 5-7 在两台服务器间分配负载
在上面的图5-7 中，如果一台服务器发生故障，所有服务仍然可用，尽管性能只能达到完全性能的某一百分比。另一台服务器提供 6 CPU 计算能力，为 10 CPU 要求的 60%。
这种设计的一个优点是，两台服务器均可用时有额外 2 CPU 的潜在容量。而且，如果一台服务器发生故障，所有服务均可用，只不过性能可能有所下降。
下图显示的是，在多台服务器间分配负载来满足性能和负载平衡要求。
图 5-8 在 n 台服务器间分配负载
由于图5-8 所示的设计中有五台服务器，如果一台服务器发生故障，其余服务器可继续提供总计 8 CPU 的计算能力，达 10 CPU 性能要求的 80%。如果在设计中增加一个具有 2 CPU 计算能力的服务器，实际得到的便是 N+1 设计。如果一台服务器发生故障，其余服务器可满足 100% 的性能要求。
这种设计具有下列优点：
不过，增加服务器数量会使管理和维护成本大幅增加，同时还会带来数据中心服务器驻扎成本。达到某一数量后，再增加服务器所得到的性能提升会越来越少。
Sun Cluster
对于要求高可用性（如四或五个九）的情况，可以考虑将 Sun Cluster 纳入可用性设计。群集系统是服务器、存储器及其他网络资源相结合的产物。群集中的服务器彼此间不间断地通信，如果其中一台服务器脱机，群集中的其余设备会将该服务器隔离，并将故障节点上的任何应用程序或数据故障转移到另一节点。这一故障转移过程所需时间较短，几乎不用中断为系统用户提供的服务。
配置、管理和维护 Sun Cluster 需要额外的专用硬件和专门技能。
示例部署的可用性设计
下图显示的是示例部署日历服务节的可用性设计，第 4 章，“设计逻辑体系结构”中有对该节的介绍。该图描述的是示例部署逻辑体系结构 Calendar Server 节的可用性解决方案。示例部署完整可用性解决方案的分析不在本白皮书讨论的范围之内。
本章前文中的估量确定，Calendar Server 需要 6 个 CPU 和 12 GB 内存，如图5-3 所示。下图显示的是，为满足负载平衡的收到和外出请求而在两台服务器上部署的 Calendar Server 的前端。Calendar Server 的后端部署在另外一台服务器上，并为实现故障转移而在 Sun Cluster 3.1 4/04 中进行了复制。为实现故障转移，Calendar Server 后端所需的 CPU 和内存在 Sun Cluster 3.1 4/04 中进行了复制。
图 5-9 示例部署中 Calendar Server 的可用性设计
可维护性问题
针对可用性进行设计时，还必须考虑解决方案的管理和维护成本。设计中往往会忽略这些成本，因为它们与硬件采购并无特定关联。不过，它们却可能成为反衬出设计复杂性的隐性、持续成本。
例如，设计中可能包括能够提供高可用性的大量水平冗余服务器。但是，如果不将设置和配置服务器、不断升级软件和监视系统运行状况的成本计算在内，便可能达不到预期的可用性提升。
针对可维护性进行设计时，请考虑下列管理和维护成本：
可伸缩性估量
可伸缩性是指为系统增加容量的能力，通常是以增加系统资源，但不改变部署体系结构的方式进行。本节讨论的是针对可伸缩性进行设计时需考虑的主题。
在要求分析阶段，通常是根据业务要求和后续用量分析对预期增长作出预测。这些对系统用户数量和满足他们需要的系统容量的预测往往只是估计值，可能与部署系统的实际数字大相径庭。设计应具备足够的灵活性，考虑到预测中存在的偏差。
潜在容量
潜在容量是可伸缩性的一个方面，即在系统中增加额外的性能和可用性资源，以便在出现异常高峰负载时能够从容应对。潜在容量是给设计注入安全机制的一种方法。
对使用案例进行仔细分析有助于确定可能产生异常峰值负载的情况（例如，安排强制性 webcast 的企业对员工的部署）。利用对异常高峰负载的分析，并对可应对意外增长的因素加以考虑，便能够设计出可给系统注入安全机制的潜在容量。
还可以对部署系统中潜在容量的使用案例进行监视，以协助确定何时有必要通过增加资源来扩展系统。
升级系统容量
系统设计应能处理系统运行前 6 到 12 个月的预测容量。可利用维护周期，根据需要增加资源或扩大容量。理想情况下应能安排定期对系统进行升级，但预测需要增加的容量往往很难。根据仔细的资源监视和业务预测来确定升级系统的时间。
如果要执行的是渐增式部署，即出于业务或技术原因推迟系统某些节的部署，则可相应制定系统容量升级时间表，使之与为系统增加新功能的其他升级同时进行。
优化资源部署估量不只是对满足系统要求的资源进行估计，它还涉及风险管理和资源管理。设计对风险管理和资源管理的处理方式往往是能否实现业务目标的关键。
风险管理
估量所依据的许多信息，如业务要求和用量分析，并不是基于经验的数据，而是基于估计和预测的数据。完成计划部署估量前，请复查数据，确保估量设计已将估计或预测值的任何合理偏差考虑在内。
例如，如果业务要求预测低估了系统的实际用量，便要面临这样的风险：所构建的系统无法应付其遇到的流量。未达到性能要求的设计当然是失败的设计。
反之，如果所构建系统的能力远超所需能力，便白白浪费了本可用在他处的资源。关键在于，在满足要求的基础上留出一定的保险余量，但要避免资源浪费。
资源浪费也可导致设计失败，因为这种设计未能将某些资源加以利用，而这些资源本可用于对成功至关重要的其他一些领域。此外，浪费资源的解决方案还可能给人以未诚信履行合同的印象。
管理资源
管理资源是对所有可用的估量方案进行分析，选择可最大限度降低成本而又能满足系统要求的最适用解决方案的过程。这一过程包括了解每个设计决策的平衡点，确保在某一方面获得的益处不会被在另一方面产生的成本抵消。
例如，针对可用性进行水平扩展可能会提升总体可用性，但代价是需要增加维护和维修成本。针对性能进行垂直扩展可能会以经济的方式提高计算能力，但某些服务对这些附加能力的使用效率不高。
完成估量策略前，请对决策进行检查，确保平衡利用资源，使设计总体受益。这种检查通常是检查某一方面的系统特性如何对其他系统特性产生影响。下表列出了在资源管理上可能需要考虑的一些主题。
示例部署体系结构下图显示的是本白皮书前文中介绍的示例部署的完整部署体系结构。通过此图可大概了解部署体系结构的表示方法。
图 5-10 示例部署体系结构
详细设计规范部署体系结构完成后是客户审核阶段，顺利的话，之后便是项目核准阶段。在某些情况下，客户可能会再次给出指示，要求对部署体系结构进行某些更改，然后才能核准。
项目核准后，便要制订详细的设计规范，而这是部署实现的起点。设计规范包括具体硬件资源和网络设备的详细信息以及详细的 LDAP 目录设置。
