英特尔®安腾®2处理器如何改进性能降低成本
(华强电子世界网讯) 英特尔开发了一种方法以将其SAP高级计划优化器系统移植到采用英特尔®安腾®2架构服务器的64位计算系统之上。新的系统可平均缩短50％的优化时间，并通过灵活扩展部署于英特尔遍布全球的业务部门。本文将向您介绍该解决方案是如何开发出来的，并详细介绍向64位计算移植的未来计划。
要点综述
整合批量半导体制造基础设施的物料、资源与流程对于英特尔满足不断提高的市场需求至关重要。为了满足这些需求，我们某些业务部门使用了SAP高级计划优化器*(SAP APO*)系统来进行规划、预测与补给。
我们最初将SAP APO部署在四台基于32位英特尔®奔腾® III至强™处理器的服务器上，但是32位解决方案限制了我们的部署扩展能力。例如，内存局限性即限制了高效运行的计划优化器数量。
去年，我们将SAP APO移植到一款融合64位英特尔®安腾®2架构系统和基于32位奔腾III至强处理器的服务器（运行Microsoft Windows Server* 2003）的解决方案上。鉴于安腾2处理器具有更大的可寻址内存、三级高速缓存和更高的处理器吞吐量，我们预计将得到显著得性能提升。
结果正如我们所料：
•用户报告新系统的计划运行时间缩短了一半—甚或更多。
•对开发与生产系统的性能指标评测显示，新系统的优化性能提升了40－70%，扩展能力也是当前负载的300倍。
•移植可实现应用的整合，从长期降低日常的系统维护。
•以前的配置在增长潜力上受到极大得限制，新解决方案有着充足的扩展空间。
•显著减少支持大量用户所需的服务器数量，从而极大地降低总保有成本(TCO)。在未来两年，我们将在安腾2架构服务器上部署更多的解决方案，服务器数量有望降至当前的1/3，伴随而来的还有总保有成本的减少。
凭借以上出色的结果，我们计划在未来几个月内在英特尔其他业务部门进行同样的部署。
我们采取了一种分期部署方法，这使我们可以尽快部署安腾2架构解决方案，而不必等待解决方案堆栈的成熟。这使我们可以高效地重新规划工厂网络，同时满足快速的客户响应需求对供应链提出的更高要求。这时的延迟部署即意味着耽误英特尔的业务扩展。
SAP APO向安腾2架构解决方案的移植标志着全套解决方案堆栈的首次实施：将从核心供应链管理(SCM)应用到病毒保护、备份以及管理应用全都整合到一个基于安腾2和奔腾III至强处理器的解决方案（运行Microsoft Windows Server 2003）之上。借完善的蓝图，我们可以向其他英特尔业务部门规划和部署该解决方案，为全公司提供经济高效、可扩展的高性能SCM。
在本文中，我们将向您介绍从规划到实施再到性能指标评测的整个移植过程，并对结果进行详细分析。
SAP APO是企业级关键业务应用，它可帮助英特尔制定制造能力、资源与物料的中长期计划。该系统可对原材料供应、制造资产、计划以及定期目标进行评估，并经过大量计算生成一份建议计划。
SAP APO概述
SAP APO包由多个组件组成，其中包括SAP APO软件、数据库以及名为liveCache*的大型缓存系统。这些组建全都运行于Basis*内核之上，计划优化器例程运行于功能匹配* (Capability-to-Match，CTM)引擎之上。有关SAP APO的更多信息，请参阅第5页“SAP APO定义”。整体上，该软件属于计算密集型，对内存有着较高的要求。
SAP APO的组件因其扩展优化而异，针对纵向扩展（在单个服务器上添加处理器、内存、硬盘空间等）或横向扩展（为服务器添加一个或多个处理器）而进行了优化。大部分SAP APO代码均为多线程代码，以在多路服务器上获得更高的性能。SAP APO软件专为纵向扩展而进行了优化，在多路系统（4路、8路以及更多）上可提供更佳的性能。但是，SAP liveCache的性能取决于可寻址内存，软件的可用内存越多，其性能就越好。SAP优化器专为横向扩展进行了特别设计。处理器数量越多，则其可同时完成的优化进程就越多。
SAP APO的性能高低并非以其支持的用户数量来衡量，而是以其在容许的时间内能同时执行和完成的规划进程来衡量。liveCache和优化器可用资源的大小在决定性能方面发挥着重要的作用。
更广的供应计划
我们最初部署SAP APO是为了替代低速的传统应用，后者需要花费数周时间才能制订出完善的物料计划，以根据新的市场需求来调节生产工厂的产出。对市场变化做出快速响应对于英特尔非常重要，但这些应用却不利于我们快速做出调节、获取原料和提高微处理器制造（或装配）工厂（经常称之为fab）的产出。
在实施了SAP APO的部门，我们发现可以对新的商机更快地做出响应。数据的收集与准备时间从以前的数月缩减至几天，计划流程也从原来的几天锐减为几分钟。
为了实现最大的效能，SAP APO需要扩展到整个英特尔业务部门。业务与环境需求均要求我们部署完善的系统，以实现最低的实施、运行与长期支持成本。我们的64位实施方法便基于未来12－18个月的业务需求而制订。
初始（32位）解决方案
我们在32位服务器上部署我们第一个SAP APO解决方案：
•四台8路基于550 MHz奔腾III至强处理器的服务器
•8 GB内存
•Microsoft Windows 2000 Advanced Server SP3
•千兆位交换能力
•配置成两个主/主集群的微软集群服务*
集群1：数据库与SAP中心实例*（Basis内核与APO）位于单个节点上
集群2：liveCache与优化器位于单个节点上
我们通过以下措施进行了性能优化，以获得最大的规划进程数量与大小：将各SAP APO应用部署于其各自的服务器上、为liveCache提供最大的系统可用内存并为优化器提供100％的服务器CPU。
SAP APO广泛的数据集需要消耗大量内存。我们使用了8路服务器，但内存容量限制了解决方案的性能和可扩展性，后者又限制了我们提高规划例程数量的能力。32位服务器最大3 GB的容量远远不够。随着liveCache进程的增长，服务器无法将全部数据存储在其物理内存中，因此不得不将它们全部或部分转移到页文件，从而带来了速度的显著降低。同样的问题还影响着我们向Oracle数据缓存分配内存的能力。因为数据缓存有限，所以数据库便不得不花大量的时间来清空数据块，以为新的请求腾出空间。
[page]
鉴于SAP APO相对于原有方法所见的规划性能改进，我们预期将有大量用户会迅速扩展超越这些水平。
扩展解决方案
为了广泛部署SAP APO解决方案，我们需要构建一款有着更高可扩展性的解决方案，以满足当前及未来18个月内不断增长的业务需求。我们考虑了如下方案：
•构建对称多处理器(SMP)系统，包括32位或64位、16路或32路的单个服务器。尽管即使在32位技术条件下定制SMP系统也可提供更大的内存，但该解决方案的成本是个问题。
•使用更快的32位服务器。虽然这有助于实现更快的优化，但该解决方案并未解决32位处理器的内存限制，而这正是liveCache的主要限制。
•在整个公司内创建SAP APO同一32位解决方案的多个实例。这不可行，因为SAP APO依赖于单个liveCache实例。另外，并联整个解决方案意味着为每个实例和所有运行SAP APO所需的数据添加一个存储区域网络(SAN)。其成本、设备以及数据管理与维护工作都是令人望而却步的。
•向基于英特尔安腾2处理器的64位解决方案移植。安腾2架构解决方案提供了较之其他方案更大的可寻址内存、在整个公司内广泛部署SAP APO所需的扩展潜能以及更高的性价比，因为安腾2处理器是一款企业级、基于开放架构和行业标准而批量制造的高性能处理器。
开发安腾2架构解决方案为我们提供了广泛部署所需的可扩展性，以及最佳的性价比。
•SAP Basis与内核v4.6D。SAP R/3基于传统3级客户机-服务器体系结构：表示层客户端、数据库服务器和应用服务器。
•SAP高级计划优化器(APO)应用版本3.1。SAP APO 3.x需要SAP liveCache。取决于业务情境，SAP APO还可使用一台优化服务器。用户通过客户端接口（例如SAP GUI）与系统进行交互，以创建规划、执行优化和进行“如果-那么”情境假设。
•SAP liveCache v7.4.2。SAP liveCache基于SAP DB*数据库技术，可确保实现最佳的mySAP* SCM性能。SAP liveCache是SAP针对超大数据量实时高速处理的一流内存计算技术。SAP该项面向对象的常驻内存技术的主要功能如下：
应用逻辑的执行就在数据存储位置进行，避免网络负载。
将数据库的关系数据结构整合入主存中针对特定应用的优化数据表示，以在几分钟或几秒内完成优化与规划任务。
内建业务功能，表现为C++对象方法。
与SAP数据库进行语义同步。
移植到64位安腾2处理器。
•Oracle9i*数据库。SAP APO独立于平台之外，支持绝大多数数据库和操作系统。
•SAP优化服务器。SAP APO优化服务器是SAP APO体系结构的一个可选组件。优化对于基于SAP APO应用的情境（例如需求规划【DP】或可承诺量【ATP】）不起任何作用。但是，对于供应网络计划(SNP)或生产计划以及详细排程(PP/DS)，优化服务器可用作启发式情境的替代方案。对于运输计划与车辆调度(TP/VS)，优化服务器也起着重要作用。Microsoft Windows Server 2003支持SAP优化服务器。
•SAP APO优化器例程。始于SAP APO 3.x版本，SAP已开发出一套创新且灵活的优化解决方案，它通过优化扩展工作台打开了SAP APO面向外部优化技术的高级计划与排程功能。该战略使mySAP SCM客户可充分利用现有mySAP SCM优化器和市场上的专有优化软件。该优化技术在一个计划系统内集成了四项不同的计划方法以满足您的各种优化需求：
启发方式。基于本地优化标准。创建即时可用的计划，考虑特别的业务限制。
要点综述
整合批量半导体制造基础设施的物料、资源与流程对于英特尔满足不断提高的市场需求至关重要。为了满足这些需求，我们某些业务部门使用了SAP高级计划优化器*(SAP APO*)系统来进行规划、预测与补给。
我们最初将SAP APO部署在四台基于32位英特尔®奔腾® III至强™处理器的服务器上，但是32位解决方案限制了我们的部署扩展能力。例如，内存局限性即限制了高效运行的计划优化器数量。
去年，我们将SAP APO移植到一款融合64位英特尔®安腾®2架构系统和基于32位奔腾III至强处理器的服务器（运行Microsoft Windows Server* 2003）的解决方案上。鉴于安腾2处理器具有更大的可寻址内存、三级高速缓存和更高的处理器吞吐量，我们预计将得到显著得性能提升。
结果正如我们所料：
•用户报告新系统的计划运行时间缩短了一半—甚或更多。
•对开发与生产系统的性能指标评测显示，新系统的优化性能提升了40－70%，扩展能力也是当前负载的300倍。
•移植可实现应用的整合，从长期降低日常的系统维护。
•以前的配置在增长潜力上受到极大得限制，新解决方案有着充足的扩展空间。
•显著减少支持大量用户所需的服务器数量，从而极大地降低总保有成本(TCO)。在未来两年，我们将在安腾2架构服务器上部署更多的解决方案，服务器数量有望降至当前的1/3，伴随而来的还有总保有成本的减少。
凭借以上出色的结果，我们计划在未来几个月内在英特尔其他业务部门进行同样的部署。
我们采取了一种分期部署方法，这使我们可以尽快部署安腾2架构解决方案，而不必等待解决方案堆栈的成熟。这使我们可以高效地重新规划工厂网络，同时满足快速的客户响应需求对供应链提出的更高要求。这时的延迟部署即意味着耽误英特尔的业务扩展。
SAP APO向安腾2架构解决方案的移植标志着全套解决方案堆栈的首次实施：将从核心供应链管理(SCM)应用到病毒保护、备份以及管理应用全都整合到一个基于安腾2和奔腾III至强处理器的解决方案（运行Microsoft Windows Server 2003）之上。借完善的蓝图，我们可以向其他英特尔业务部门规划和部署该解决方案，为全公司提供经济高效、可扩展的高性能SCM。
在本文中，我们将向您介绍从规划到实施再到性能指标评测的整个移植过程，并对结果进行详细分析。
英特尔的SAP环境
SAP APO是企业级关键业务应用，它可帮助英特尔制定制造能力、资源与物料的中长期计划。该系统可对原材料供应、制造资产、计划以及定期目标进行评估，并经过大量计算生成一份建议计划。
SAP APO概述
SAP APO包由多个组件组成，其中包括SAP APO软件、数据库以及名为liveCache*的大型缓存系统。这些组建全都运行于Basis*内核之上，计划优化器例程运行于功能匹配* (Capability-to-Match，CTM)引擎之上。有关SAP APO的更多信息，请参阅第5页“SAP APO定义”。整体上，该软件属于计算密集型，对内存有着较高的要求。
SAP APO的组件因其扩展优化而异，针对纵向扩展（在单个服务器上添加处理器、内存、硬盘空间等）或横向扩展（为服务器添加一个或多个处理器）而进行了优化。大部分SAP APO代码均为多线程代码，以在多路服务器上获得更高的性能。SAP APO软件专为纵向扩展而进行了优化，在多路系统（4路、8路以及更多）上可提供更佳的性能。但是，SAP liveCache的性能取决于可寻址内存，软件的可用内存越多，其性能就越好。SAP优化器专为横向扩展进行了特别设计。处理器数量越多，则其可同时完成的优化进程就越多。
SAP APO的性能高低并非以其支持的用户数量来衡量，而是以其在容许的时间内能同时执行和完成的规划进程来衡量。liveCache和优化器可用资源的大小在决定性能方面发挥着重要的作用。
更广的供应计划
我们最初部署SAP APO是为了替代低速的传统应用，后者需要花费数周时间才能制订出完善的物料计划，以根据新的市场需求来调节生产工厂的产出。对市场变化做出快速响应对于英特尔非常重要，但这些应用却不利于我们快速做出调节、获取原料和提高微处理器制造（或装配）工厂（经常称之为fab）的产出。
在实施了SAP APO的部门，我们发现可以对新的商机更快地做出响应。数据的收集与准备时间从以前的数月缩减至几天，计划流程也从原来的几天锐减为几分钟。
为了实现最大的效能，SAP APO需要扩展到整个英特尔业务部门。业务与环境需求均要求我们部署完善的系统，以实现最低的实施、运行与长期支持成本。我们的64位实施方法便基于未来12－18个月的业务需求而制订。
初始（32位）解决方案
我们在32位服务器上部署我们第一个SAP APO解决方案：
•四台8路基于550 MHz奔腾III至强处理器的服务器
•8 GB内存
•Microsoft Windows 2000 Advanced Server SP3
•千兆位交换能力
•配置成两个主/主集群的微软集群服务*
集群1：数据库与SAP中心实例*（Basis内核与APO）位于单个节点上
集群2：liveCache与优化器位于单个节点上
我们通过以下措施进行了性能优化，以获得最大的规划进程数量与大小：将各SAP APO应用部署于其各自的服务器上、为liveCache提供最大的系统可用内存并为优化器提供100％的服务器CPU。
SAP APO广泛的数据集需要消耗大量内存。我们使用了8路服务器，但内存容量限制了解决方案的性能和可扩展性，后者又限制了我们提高规划例程数量的能力。32位服务器最大3 GB的容量远远不够。随着liveCache进程的增长，服务器无法将全部数据存储在其物理内存中，因此不得不将它们全部或部分转移到页文件，从而带来了速度的显著降低。同样的问题还影响着我们向Oracle数据缓存分配内存的能力。因为数据缓存有限，所以数据库便不得不花大量的时间来清空数据块，以为新的请求腾出空间。
[page]
鉴于SAP APO相对于原有方法所见的规划性能改进，我们预期将有大量用户会迅速扩展超越这些水平。
扩展解决方案
为了广泛部署SAP APO解决方案，我们需要构建一款有着更高可扩展性的解决方案，以满足当前及未来18个月内不断增长的业务需求。我们考虑了如下方案：
•构建对称多处理器(SMP)系统，包括32位或64位、16路或32路的单个服务器。尽管即使在32位技术条件下定制SMP系统也可提供更大的内存，但该解决方案的成本是个问题。
•使用更快的32位服务器。虽然这有助于实现更快的优化，但该解决方案并未解决32位处理器的内存限制，而这正是liveCache的主要限制。
•在整个公司内创建SAP APO同一32位解决方案的多个实例。这不可行，因为SAP APO依赖于单个liveCache实例。另外，并联整个解决方案意味着为每个实例和所有运行SAP APO所需的数据添加一个存储区域网络(SAN)。其成本、设备以及数据管理与维护工作都是令人望而却步的。
•向基于英特尔安腾2处理器的64位解决方案移植。安腾2架构解决方案提供了较之其他方案更大的可寻址内存、在整个公司内广泛部署SAP APO所需的扩展潜能以及更高的性价比，因为安腾2处理器是一款企业级、基于开放架构和行业标准而批量制造的高性能处理器。
开发安腾2架构解决方案为我们提供了广泛部署所需的可扩展性，以及最佳的性价比。
SAP APO定义
•SAP Basis与内核v4.6D。SAP R/3基于传统3级客户机-服务器体系结构：表示层客户端、数据库服务器和应用服务器。
•SAP高级计划优化器(APO)应用版本3.1。SAP APO 3.x需要SAP liveCache。取决于业务情境，SAP APO还可使用一台优化服务器。用户通过客户端接口（例如SAP GUI）与系统进行交互，以创建规划、执行优化和进行“如果-那么”情境假设。
•SAP liveCache v7.4.2。SAP liveCache基于SAP DB*数据库技术，可确保实现最佳的mySAP* SCM性能。SAP liveCache是SAP针对超大数据量实时高速处理的一流内存计算技术。SAP该项面向对象的常驻内存技术的主要功能如下：
应用逻辑的执行就在数据存储位置进行，避免网络负载。
将数据库的关系数据结构整合入主存中针对特定应用的优化数据表示，以在几分钟或几秒内完成优化与规划任务。
内建业务功能，表现为C++对象方法。
与SAP数据库进行语义同步。
移植到64位安腾2处理器。
•Oracle9i*数据库。SAP APO独立于平台之外，支持绝大多数数据库和操作系统。
•SAP优化服务器。SAP APO优化服务器是SAP APO体系结构的一个可选组件。优化对于基于SAP APO应用的情境（例如需求规划【DP】或可承诺量【ATP】）不起任何作用。但是，对于供应网络计划(SNP)或生产计划以及详细排程(PP/DS)，优化服务器可用作启发式情境的替代方案。对于运输计划与车辆调度(TP/VS)，优化服务器也起着重要作用。Microsoft Windows Server 2003支持SAP优化服务器。
•SAP APO优化器例程。始于SAP APO 3.x版本，SAP已开发出一套创新且灵活的优化解决方案，它通过优化扩展工作台打开了SAP APO面向外部优化技术的高级计划与排程功能。该战略使mySAP SCM客户可充分利用现有mySAP SCM优化器和市场上的专有优化软件。该优化技术在一个计划系统内集成了四项不同的计划方法以满足您的各种优化需求：
启发方式。基于本地优化标准。创建即时可用的计划，考虑特别的业务限制。