12.1.4.1 升级改造内容介绍
为了缓解现有浦东机场一级IMB的运行压力，在浦东机场三期扩建工程卫星厅建设的过程中对现有AIS系统进行升级改造。本次浦东机场三期扩建工程卫星厅建设项目中，涉及与AIS相关的改造部分，通过分析后发现主要会涉及以下四部分内容：
1）现有测试环境扩展
随着浦东机场卫星厅建设项目的发展，预期机场的航班量、旅客运输量和资源调度数量等均会出现较大的增长，现有测试环境的主机，除了具备日常生产运行环境的同步测试功能外，还兼具了在极端情况下作为生产灾备环境的功能。且当前的测试环境与生产环境的主机运行模式并不相同，生产环境下的主机为双机运行模式，测试环境下的主机为单机模式运行，因此当需要启用测试环境作为生产环境的灾备机使用时，需要对测试环境主机系统进行较多的配置变更，才能与生产主机形成新的双机运行环境。此模式在浦东机场实际业务运行过程中，已经表现出了切换时间较长、配置步骤较复杂和易出错等现象，在随着浦东机场卫星厅投入使用业务量增大后，该现象会愈发的明显，从而为生产运营系统出现故障后的快速恢复运营带来了潜在隐患。同时作为生产环境系统上线更新前的测试环境，由于与生产环境存在上述运行模式的差异，也为系统上线前的测试验证工作带来了差异，不能完全模拟生产环境的各种情况，也为系统的平滑上线带来了不稳定的因素。
综合上述，对现有的测试环境主机进行扩展，即在测试环境新增一台服务器，该服务器采用虚拟化方式各部署一套AODB／RMS和IB虚拟主机，将测试环境也配置为双机模式运行保持与生产环境运行模式的一致性，同时也可以通过这种方式增加测试环境切换为灾备环境运行时的系统负载能力，降低灾备环境切换的复杂度，提高切换操作的执行效率，从而更快地恢复正常的生产运行业务，降低故障时间。
2）新增子系统数据接口
在浦东机场卫星厅建设项目中，改进后的机场集成系统分为一级IMB和二级IMB，一级IMB新增卫星厅行李系统、广播系统、登机桥管理系统和泊位引导系统共计4个子系统接口，二级IMB新增卫星厅楼宇自控系统、照明控制系统、安防集成管理系统、安检信息管理系统、多媒体显示系统、T1楼宇自控系统和T2楼宇自控系统共计7个子系统接口和1个预留接口。而这些系统均需要同信息集成系统进行数据交换，因此信息集成系统方面需要为这些子系统增加相应的数据接口，以满足其正常生产运营的需求。
3）升级现有集成系统行李分配相关功能
浦东机场卫星厅建设项目对现有行李分配的相关业务产生变更，为适应业务上的变化，需要对现有集成系统的行李分配相关功能进行升级改造，主要涵盖以下几个部分：
（1）RMS系统行李转盘分配功能变更。根据浦东机场卫星厅建设项目的需要，对现有RMS系统所支持的单航班最多分配2个转盘的基础上，将所支持的转盘数量增加到4个。同时需要依据新增卫星厅的资源情况，重新设计和调整所需要的分配规则，并额外提供模板分配功能，简化资源分配过程。
（2）IB系统升级适配新的行李转盘分配功能。对AODB／RMS系统进行升级改造支持至多4个行李转盘分配后，需要对IMB中所提供对应数据的服务接口定义规范进行相应的调整，以支持对扩充后的行李转盘分配信息进行传递，并需要告知与服务规范升级的相关子系统（例如航显、T1的行李等）进行相应的数据接口更新，并对更新后的接口展开接口联调等相关测试工作。
4）新增支持RESTfulAPI的中间件系统
考虑到卫星厅建设项目实施以及浦东机场的后续新建规划后，为今后更便于机场进行航班、资源等数据的扩容工作，将与信息集成系统相关的子系统接口按照其对应生产运营情况的影响进行分级，将对生产运营情况影响较低的二类子系统数据接口从现有中间件服务器上迁移至新构建的中间件平台上，以降低现有核心中间件的运行压力，从而提升信息集成系统的整体稳定性，并降低系统故障造成的影响。
12.1.4.2 升级改造方案
1）现有测试环境现状分析
在AIS未进行升级改造之前，浦东机场生产环境中使用了4台DELLR730服务器，测试环境中使用了2台DELLR730服务器。所有6台硬件服务器以及AODB和IB软件均应用了虚拟化技术，并由统一的vCenter进行管理。
此次测试环境扩展方案基于如下考虑：
（1）在未进行升级改造之前浦东机场的测试环境服务器中，仅有AODB和IB的各1个节点VM，即不存在双机测试环境，为完整模拟生产环境测试带来了困难，也为后续补丁、新功能在生产环境的上线带来了风险。
（2）由于需要新增支持RESTfulAPI的中间件系统，同时需要在测试环境中为该平台构建相应的测试系统，因此也需要对现有测试环境进行新增扩容。
如要新增服务器，则须注意以下因素：
（1）额外硬件采购成本和人工成本。新服务器需要购买许可授权和维护支持。
（2）额外虚拟化平台软件采购成本和人工成本。基于原有的生产、测试虚拟化环境，对新采购服务器仍然采用虚拟化方式进行部署，需要额外的虚拟化平台软件授权及虚拟化平台管理软件的授权费用以及相应的人工实施成本费用。
（3）额外软件采购成本和人工成本。在新服务器上安装的软件需要购买许可授权和维护支持。
2）方案设计
在卫星厅项目中，对AIS升级改造所使用的服务器与现有测试环境配置相同架构的芯片服务器。由于浦东机场集成系统的测试服务器同时具备灾备服务器的功能，即其需要足够大的硬盘空间，以便存储多个完整VM，因此在测试环境中共新增两台服务器，并均须包含至少4TB的硬盘空间，如图12-2的架构所示（黄色底色以及灰色底色的方块为各个VM 的部署）。(www.xing528.com)
此架构为浦东机场生产环境提供了如下内容：
（1）所有生产环境AODB和IMB的VM 在测试环境中的完整备份；
（2）由于每个灾备镜像均位于不同服务器，因此一旦出现需要启用灾备环境的情况，无论AODB或IB均可一次性启用测试环境中的双机灾备镜像，无须考虑测试机的性能问题，从而迅速恢复生产；
图12-2 浦东机场测试环境扩展方案
（3）所有测试环境AODB和IMB的VM 的完整备份；
（4）AODB和IMB的双机节点VM 均分布在不同的服务器上，因此完全可以同时启动双机镜像而无须考虑测试机的性能问题，从而迅速进入测试；
（5）新增加的RESTfulAPI中间件平台的测试以及灾备系统。
12.1.4.3 新增子系统数据接口
由于本次集成系统改造项目中引入了新架构的IMB即RESTfulIB，可将重要性相对较低的系统接入RESTfulIB，降低实施风险的同时为目前正在生产环境中运行SonicIB分担一部分压力。
其中，将卫星厅新增的楼宇自控系统、照明控制系统、安防集成管理系统、安检信息管理系统、多媒体显示系统、T1楼宇自控系统和T2楼宇自控系统共计7个子系统接入RESTfulIB，即在RESTfulIB中创建上述7个子系统的接口并预留接口1个；行李系统、广播系统、登机桥管理系统和泊位引导系统等4个子系统重要性更高，因此在现阶段继续接入SonicIB，即在SonicIB中创建上述4个子系统的接口，后续再考虑在合适的时机迁移至RESTfulIB。
至此，集成系统改造完成后，在新增的RESTfulIB上运行着7个子系统，现有的SonicIB上运行着约25个子系统，所有子系统通过所连接的IMB与AODB进行数据的交互。
12.1.4.4 新增支持RESTfulAPI中间件系统
1）现有中间件系统现状分析
目前，浦东机场AODB／RMS和SonicIB已具备运行基础。
最新的系统已经升级，最新的AODB／RMS和SonicIB产品以及相关第三方产品运行在标准Linux／VMWare／Intel服务器。最近系统升级为关键系统提供了强有力的保障和弹性运算。
浦东机场仍然在扩大，不久将有两个新的卫星楼处理更多航班和乘客，因此机场希望确保关键系统能够处理这个即将到来的负载。
当前AODB／RMS在低负载下运行良好，已经解决了AODB／RMS由于服务器分离引起的任何问题。然而SonicIB关注的并不是最近解决的问题，而是系统的性能。SonicIB是系统集成的关键，虽然它做了高可靠性的双机，但出现任何故障影响都非常大，因此降低风险是关键，需要对现有的集成系统进行改进，确保能够在故障发生时将影响降到最低。
2）方案设计
（1）RESTfulIB 建设完成后的硬件和虚拟机架构布置。首先对现有RESTfulIB的服务器集群进行扩展，原有服务器集群为6个扩展到9个，并且vCenter实现服务器间的高可用性，每个服务器均虚拟出2个虚拟机，并且每个虚拟机使用1个CPU。其次具备灾备功能，当主备发生故障时需要灾备平台完成业务运行，同时当灾备设备不使用时，可以为整个RESTfulIB提供测试环境。
（2）迁移／升级过程。首先从系统升级角度来看，升级需要对AODB进行一个小更新，以提供新的REST服务。这应该可以线上进行，通过更新备机，并在另一台服务器上重复更新操作。在最坏的情况下（只有在必要的情况下），可能需要在非高峰时间重启。
现有IB不需要任何更改。与上一次在AODB和IB的PVG 上进行的升级不同，新服务器的添加为此次升级提供了几乎零风险安全保障，因为新的应用程序将与现有的应用程序和服务并行工作。
其次从客户端来看，ESB的现有客户机不需要做任何事情，可以继续使用ESB服务不需要更改。如果客户觉得更改是有益的或者第三方系统被替换时，可以考虑使用简单的方法来使用REST 服务，而不是现有的SOA／XML／JMS服务。最终会给用户提供REST 服务指南（类似现有的SOA／XML／JMS服务指南）。
免责声明：以上内容源自网络，版权归原作者所有，如有侵犯您的原创版权请告知，我们将尽快删除相关内容。
