系统设计策略

lzt6

贡献于2014-11-03

字数:98303 关键词: ArcGIS 地理信息系统GIS

 系统设计策略 ESRI白皮书·2004年7月 Prepared by: Dave Peters Systems Integration Environmental Systems Research Institute, Inc. 380 New York Street Redlands, California 92373-8100 Copyright © 2004 环境系统研究所公司(美国) ESRI白皮书 版权所有,翻录必究 环境系统研究所公司(美国)保留本书全部内容的所有版权。本书受美国版权法及其他国际版权条约和公约的保护。未经环境系统研究所公司(美国)的书面许可,不得以任何形式或手段复制、传播,或以任何电子或文本方式翻印、转载本书的任何部分。如有疑问,请与环境系统研究所公司(美国)联系:380 New York Street, Redlands, CA 92373-8100, USA。 本书内容的更改将不另行通知。 美国政府的受限 / 有限权利 以下所列的任何软件、文档和 / 或数据均受“许可协议”的制约。美国政府在任何条件下都不能获得大于受限 / 有限权利中所规定的权利。最基本的原则是,美国政府使用、复制或公开数据要受到以下条例相关内容的制约: FAR §52.227-14 Alternates I,II和III (1987年6月);FAR §52.227-19 (1987年6月) 和 / 或FAR §12.211/12.212 (商业技术数据 / 计算机软件); 以及DFARS §252.227-7015 (1995年11月)(技术数据)和 / 或DFARS §227.7202 (计算机软件)。合约方 / 制造商是环境系统研究所公司(美国), 380 New York Street, Redlands, CA 92373-8100, USA。 ESRI, ARC/INFO, ArcCAD, ArcView, BusinessMAP, MapObjects, PC ARC/INFO, SDE, and the ESRI globe logo是环境系统研究所公司在美国和其他一些国家的的注册商标,在欧盟的注册正在进行中。3D Analyst, ADF, ARC COGO, the ARC COGO logo, ARC GRID, the ARC GRID logo, ArcInfo, the ArcInfo logo, the ARC/INFO logo, AML, ARC NETWORK, the ARC NETWORK logo, ArcNews, ARC TIN, the ARC TIN logo, ArcInfo LIBRARIAN, ArcInfo–Professional GIS, ArcInfo–The World's GIS, ArcAtlas, the ArcAtlas logo, the ArcCAD logo, the ArcCAD WorkBench logo, ArcCatalog, the ArcData logo, the ArcData Online logo, ARCEDIT, the ARCEDIT logo, ArcExplorer, the ArcExplorer logo, ArcExpress, the ArcExpress logo, ArcFM, the ArcFM logo, the ArcFM Viewer logo, ArcGIS, ArcIMS, the ArcIMS logo, ArcLogistics, the ArcLogistics Route logo, ArcMap, ArcObjects, ARCPLOT, the ARCPLOT logo, ArcPress, the ArcPress logo, the ArcPress for ArcView logo, ArcScan, the ArcScan logo, ArcScene, the ArcScene logo, ArcSchool, ArcSDE, the ArcSDE logo, the ArcSDE CAD Client logo, ArcSdl, ArcStorm, the ArcStorm logo, ArcSurvey, ArcToolbox, ArcTools, the ArcTools logo, ArcUSA, the ArcUSA logo, ArcUser, the ArcView GIS logo, the ArcView 3D Analyst logo, the ArcView Business Analyst logo, the ArcView Data Publisher logo, the ArcView Image Analysis logo, the ArcView Internet Map Server logo, the ArcView Network Analyst logo, the ArcView Spatial Analyst logo, the ArcView StreetMap logo, the ArcView StreetMap 2000 logo, the ArcView Tracking Analyst logo, ArcVoyager, ArcWorld, the ArcWorld logo, Atlas GIS, the Atlas GIS logo, AtlasWare, Avenue, the Avenue logo, the BusinessMAP logo, DAK, the DAK logo, DATABASE INTEGRATOR, DBI Kit, the Digital Chart of the World logo, the ESRI corporate logo, the ESRI PRESS logo, ESRI–Team GIS, ESRI–The GIS People, FormEdit, Geographic Design System, Geography Matters, GIS Day, the GIS Day logo, GIS by ESRI, GIS for Everyone, GISData Server, InsiteMAP, MapBeans, MapCafé, the MapCafé logo, the MapObjects logo, the MapObjects Internet Map Server logo, ModelBuilder, NetEngine, the NetEngine logo, the PC ARC/INFO logo, PC ARCEDIT, PC ARCPLOT, PC ARCSHELL, PC DATA CONVERSION, PC NETWORK, PC OVERLAY, PC STARTER KIT, PC TABLES, the Production Line Tool Set logo, RouteMAP, the RouteMAP logo, the RouteMAP IMS logo, Spatial Database Engine, the SDE logo, SML, StreetMap, TABLES, The World's Leading Desktop GIS, Water Writes, and Your Personal Geographic Information System均为商标;ArcData, ArcOpen, ArcQuest, ArcWatch, ArcWeb, Rent-a-Tech, @esri.com, and www.esri.com是环境系统研究所公司的服务标志。 本书涉及到的其他公司和产品是属于其各自商标拥有人的商标或注册商标。 ESRI白皮书 目录 1 系统设计过程 12 1.1 什么是系统结构设计? 12 1.2 系统结构设计的重要性 13 1.3 支持成功GIS运行的步骤 14 1.4 系统设计过程 15 1.5 支撑技术 16 1.6 项目中心框架 18 1.7 系统设计支持 19 2. ESRI软件发展历程 21 2.1 桌面工作站环境 22 2.2 机构性GIS的发展 25 2.3 社区性GIS的发展 26 2.4 GIS技术方案选择 28 2.5 GIS软件选择 29 2.6 GIS配置选择 30 2.7 ESRI ArcGIS的实现 33 2.7.1 数据转移策略 34 2.7.2 应用程序转移策略 36 3. 网络通讯 38 3.1 桌面工作站环境 38 3.2 客户/服务器通讯概念 40 3.3 客户/服务器通讯 41 3.4 客户/服务器网络性能 43 3.5 共享的网络性能 44 3.6 典型的1M地图显示 44 3.7 网络配置指南 45 3.8 共享网络配置标准 46 3.9 局域网组件配置 47 3.10 网络服务配置指南 49 4.GIS产品结构 52 4.1 ArcGIS系统软件结构 53 4.2 ArcGIS桌面软件结构 54 4.3 GIS for UNIX 56 4.4 GIS for Windows 58 4.5 Microsoft Windows Terminal Server 59 4.6 空间数据库引擎(ArcSDE) 61 4.7 Arc网络地图服务(ArcIMS) 62 4.7.1 ArcIMS平台配置选择方案 64 4.7.1.1 单级平台配置 65 ESRI白皮书 4.7.1.2 两级平台配置 66 4.7.1.3 三级平台配置 70 4.7.2 ArcIMS防火墙配置选择方案 71 4.8 ArcGIS Server 78 4.8.1 ArcGIS Server结构 78 4.8.2 ArcGIS Server负载平衡 79 4.8.2.1 ArcGIS Server单级平台配置 83 4.8.2.2 ArcGIS Server两级平台配置 84 4.8.2.3 ArcGIS Server三级平台结构 85 5 数据管理 88 5.1 保护空间数据的途径 88 5.2 流行的RAID配置 89 5.3 备份空间数据的途径 91 5.4 转移空间数据的途径 92 5.4.1 传统的数据传输方法 93 5.4.2 ArcGIS数据库转移 94 5.4.3 数据库复制 95 5.4.4 磁盘级复制(异步) 96 5.4.5 访问空间数据的新途径 98 5.5 数据管理综述 101 6 GIS用户需求 102 6.1 对GIS的思考 102 6.2 系统设计前提 105 6.3 GIS用户需求评价 106 6.3.1 GIS用户地点 106 6.3.2 网络通讯 106 6.3.3 GIS用户类型 107 6.3.4 用户工作流程分析 108 6.4 系统结构设计回顾 111 6.5 系统配置方案 112 6.5.1 集中式计算机结构 112 6.5.2 分布式数据和工作站处理(WAN) 114 6.6 选择一个系统配置 115 6.7 硬件组件选择 116 6.8 网络适宜性分析 118 7 性能评估基础 123 7.1 系统性能概况 124 7.2 如何了解性能评估(performance sizing) 127 7.3 系统性能测试 128 7.4 客户/服务器模式 133 7.4.1 批处理性能 133 7.4.2 ArcGIS桌面终端服务器性能 141 ESRI白皮书 7.4.3 数据服务器性能 146 7.5 ArcIMS网络地图服务模型 149 7.5.1 ArcIMS服务器组件 152 7.5.2 ArcIMS多线程服务引擎 153 7.5.3 虚拟服务和处理队列 156 7.5.4 发布的地图服务 157 7.5.5 ArcIMS性能评估模型 157 7.5.6 ArcIMS数据服务器负载模型 159 7.6 ArcGIS Server性能评估模型 161 7.6.1 ArcGIS Server数据服务器负载模型 163 7.7 结论 166 8 性能评估工具 167 8.1 性能基准选择 167 8.2 硬件生命周期 170 8.3 我们如何应对变化 172 8.4 我们如何衡量变化 172 8.5 硬件平台选择 174 8.5.1 平台性能评估模型格式 175 8.5.2 在哪里可以发现性能基准? 176 8.6 性能评估表 178 8.6.1 GIS桌面平台 178 8.6.2 应用程序计算服务器 179 8.6.3 互联网Web服务 181 8.6.4 GIS数据服务器性能评估(ArcSDE和文件服务器) 185 8.7 平台选择标准 189 9 系统实施 191 9.1 GIS人员 192 9.2 训练高素质的员工 195 9.3 系统结构部署策略 196 9.4 系统测试 197 9.5 系统实施管理 200 9.6 系统调试 201 9.6.1 ArcIMS服务器性能调试 202 9.6.2 ArcSDE性能调试 204 9.7 业务连续计划 205 9.8 管理技术变化 206 9.9 结论 207 附件A 系统结构设计咨询服务 208 A-1 代理级系统结构设计 208 A-2 企业级系统结构设计 208 A-3 部门级系统结构设计 208 A-4 系统结构设计维护 208 ESRI白皮书 A-4 ArcIMS结构设计 208 A-5 系统结构设计评价 209 附件B GIS系统结构设计(课程概况) 211 GIS系统结构设计 212 图表目录 图1-1 什么是系统结构设计? 12 图1-2 系统结构设计的重要性 13 图1-3 企业级GIS的部署阶段 14 图1-4 没有做好规划而付出的代价 15 图1-5 系统结构设计 16 图1-6 支撑技术 17 图1-7 项目中心框架 18 图1-8 系统设计支持 19 图2-1 GIS企业发展 21 图2-2 GIS工作站/服务器 22 图2-3 部门GIS 25 图2-4 机构性GIS 26 图2-5 社区与联邦GIS 27 图2-6 ESRI核心的GIS技术 28 图2-7 GIS软件技术选择方案 29 图2-8 集中式计算环境 31 图2-9 分布式计算环境 32 图2-10 数据转移路径图 35 图2-11 应用程序转移路径图 37 图3-1 GIS应用对网络的影响 38 图3-2 网络的类型 39 图3-3 通讯数据包的结构 40 图3-4 网络传输协议 41 图3-5 客户/服务器通讯 41 图3-6 客户/服务器性能 43 图3-7 共享的网络性能 44 图3-8 典型的1M地图显示 45 图3-9 网络配置指南 46 图3-10 网络设计指南 47 图3-11 共享的局域网 48 图3-12 ArcIMS网络性能 50 图3-13 数据下载性能 51 图3-14 网络设计规划因子 51 图4-1 GIS多级结构 52 图4-2 ESRI GIS软件 53 图4-3 ArcGIS桌面软件 54 图4-4 ESRI软件环境 55 ESRI白皮书 图4-5 UNIX下的GIS产品结构(UNIX文件服务器空间数据源) 56 图4-6 Windows下的GIS产品结构(文件服务器空间数据源) 58 图4-7 Windows Terminal Server产品结构 60 图4-8 ArcSDE数据服务器产品结构 61 图4-9 ArcIMS网络服务产品结构 62 图4-10 ArcIMS4 结构 63 图4-11 ArcIMS组件结构 64 图4-12 单级平台配置 65 图4-13 两级平台配置(分开的数据服务器) 67 图4-14 两级平台配置(分开的地图服务器) 68 图4-15 两级平台配置(分开的网络服务器) 69 图4-15 三级平台配置 70 图4-17 所有ArcIMS组件在DMZ中 71 图4-18 所有ArcIMS组件在DMZ中(除了数据服务器) 72 图4-19网络服务器在DMZ里,ArcIMS的其他组件在安全网络 73 图4-20 网络服务器和应用程序服务器在DMZ里,ArcIMS的其他组件在安全网络 74 图4-21多网络服务器配置 75 图4-22代理服务器支持下的网络服务 76 图4-23所有的ArcIMS组件都在安全网络上 77 图4-24 ArcGIS Server组件结构 78 图4-25 ArcGIS服务器启动 80 图4-26 ArcGIS Server例程分配负载平衡 81 图4-27 ArcGIS Server例程创建负载平衡 82 图4-28 ArcGIS Server单级平台配置 83 图4-29 ArcGIS Server两级平台配置(分开的数据服务器) 84 图4-30 三级平台标准配置 85 图4-31 三级平台高适用性配置 86 图5-1 存储空间数据的途径(标准RAID配置) 89 图5-2备份空间数据的途径 91 图5-3 移动空间数据的途径(传统的磁带备份/磁盘复制) 93 图5-4 移动空间数据的途径(数据库转移) 94 图5-5 移动空间数据的途径(数据库复制) 95 图5-5 移动空间数据的途径(磁盘级复制) 97 图5-7 ArcGIS8.3离线编辑personal geodatabase 98 图5-8 ArcGIS 8.3离线编辑--数据库Checkout 99 图5-9 未来的ArcSDE分布式数据库结构 100 图6-1 地理信息系统 102 图6-2 应用需求评价 103 图6-3 GIS规划 104 图6-4 完整的GIS环境 105 图6-5 系统结构需求评价 106 图6-6 网络通讯概览 107 图6-7 罗马市规划工作流分析—第一年 108 图6-8 罗马市规划工作流分析—第二年 109 ESRI白皮书 图6-9 用户应用需求概览 110 图6-10 建立在现有的IT投资之上 111 图6-11 中央服务器和工作站客户端 113 图6-12 分布式数据和工作站处理(WAN) 114 图6-13 选择一个系统配置 115 图6-14 硬件组件选择(集中式方案) 116 图6-15硬件组件选择(分布式方案) 117 图6-16 网络负载分析(集中式方案) 119 图6-17 网络适宜性分析—第一步(集中式方案) 120 图6-18 网络适宜性分析—第二步(集中式方案) 121 图6-19网络适宜性分析—第一步(分布式方案) 122 图6-20 网络适宜性分析—第二步(分布式方案) 122 图7-1 理解这项技术 123 图7-2 平台性能组件 125 图7-3 系统性能概况 126 图7-4 系统性能因素 128 图7-5 双处理器SMP性能 129 图7-6 四处理器SMP性能 130 图7-7 八处理器SMP性能 131 图7-8 批处理测试总结 132 图7-9 Terminal Server配文件服务器或本地数据 133 图7-10 Terminal Server配ArcSDE数据源 134 图7-11 ArcSDE数据服务器负载 135 图7-12 数据服务器性能模型 136 图7-13 GIS数据服务器性能模型 137 图7-14 ArcGIS客户/服务器的网络流量分析 138 图7-15 性能检验测试数据集 139 图7-16 ArcGIS文件服务器的网络吞吐量 139 图7-17 ArcGIS文件服务器的网络性能 140 图7-18 ArcGIS使用案例参数 141 图7-19 终端服务器配文件服务器或本地数据 142 图7-20 Windows Terminal Server负载分析 143 图7-19 终端服务器配ArcSDE服务器 144 图7-22 终端服务器性能模型 145 图7-23 终端服务器CPU性能评估表 146 图7-24 ArcSDE服务器性能 147 图7-25 ArcSDE服务器性能总结 148 图7-26 ArcSDE CPU性能评估表 149 图 7-27 ArcIMS平台结构 150 图7-28 地图服务性能概况 151 图7-29 ArcIMS服务组件 152 图7-30 ArcIMS多线程服务引擎 153 图7-31 优化的服务代理配置的线程数量 154 图7-32 Web服务器配置 155 ESRI白皮书 图7-33 ArcIMS虚拟服务器 156 图7-34 ArcIMS 地图服务性能评估模型 158 图7-35 ArcIMS性能评估模型 159 图7-36 ArcIMS服务器负载模型 160 图7-37 ArcGIS Server组件结构 161 图7-38 ArcGIS Server性能评估模型 162 图7-39 ArcGIS Server地图服务器性能评估模型 163 图7-40 ArcGIS Server负载模型 164 图7-41 ArcGIS Server和ArcIMS性能评估表 165 图7-42 ArcIMS数据服务器负载表 166 图8-1 ArcInfo平台性能历史 168 图8-2 Windows平台性能历史 170 图8-3 硬件生命周期 171 图8-4 硬件生命周期(月) 171 图8-5 相对性能理论 172 图8-6 我们如何衡量变化 173 图8-7 SPEC2000基准集 173 图8-8 平台性能图表概览 175 图8-9 发布的SPEC基准结果 176 图8-10 ArcSDE性能评估示范 177 图8-11 平台性能评估模型 178 图8-12 ArcInfo和ArcView平台推荐 178 图8-13 工作站平台推荐 179 图8-14 Windows Terminal Servers性能评估工具(文件服务器数据源) 180 图8-15 Windows Terminal Servers性能评估工具(ArcSDE数据源) 181 图8-16 ArcIMS/ArcGIS Server 性能评估 182 图8-17 ArcIMS/AGS数据服务器处理负载 183 图8-18确定了推荐的ArcIMS和AGS物理内存需求 184 图8-19 ArcIMS地图服务时间 185 图8-20 工作组数据服务器性能评估(ArcSDE和文件服务器) 187 图8-21 企业级数据服务器性能评估(ArcSDE和文件服务器) 188 图8-22 ArcSDE存储的最佳实践 189 图9-1 传统的GIS组织性结构 192 图9-2 GIS功能性职责 193 图9-3 GIS人员推荐 194 图9-4 培训机会 195 图9-5 GIS系统部署策略 196 图9-6 功能性系统测试的最佳操作 198 图9-7 性能测试隐患 199 图9-8 系统集成管理 200 图9-9 系统性能因素 201 图9-10 Web地图服务性能概况 202 图9-11 Web地图服务性能调试指南 203 图9-12 ArcSDE性能调试 204 ESRI白皮书 图9-13 业务连续计划 205 图9-14 系统结构设计策略规划 206 图9-15 系统实施学习课程 207 系统结构设计服务 210 ESRI白皮书 1 系统设计过程 系统设计策略 1 系统设计过程 本文的目的是提供一种系统设计策略来支持GIS企业结构解决方案的成功选择。指导方法包括使用适当的原理和逻辑来配置和支持一个系统,使它能满足绝大部分用户初始的性能需求。一旦初始实施具有可操作性,整个系统环境就可以被更好的协调来满足特定用户的需求。 1.1 什么是系统结构设计? 系统结构设计是由ESRI公司研发的用来促进成功GIS实施的方法。该方法支持现有的基础设施要求,并且能基于现有的和规划中的用户需求提供硬件和网络解决方案的特定推荐方案。在决定最佳硬件方案时,应用需求、数据资源和人员组织都十分重要。ESRI系统结构设计过程就是基于同类用户的工作流程需求,提供特定的系统结构设计方案和相关的硬件规范。 图1-1 什么是系统结构设计? 1.2 系统结构设计的重要性 一个分布式计算环境必须被正确设计以满足用户的性能需求。系统中最薄弱的“环节”将限制其性能的发挥。系统结构设计过程详述了一个均衡的硬件解决方案的规范。这种基于一个均衡系统负载模型的硬件和网络组件投入能用最低的成本得到最高限度的系统性能。 ESRI白皮书 1 系统设计过程 系统设计策略 图1-2 系统结构设计的重要性 系统结构设计提供了一个支持成功的企业级GIS设计和实施的框架。用户的工作流程必须经过设计使其交互式客户生产力达到最优,并且能够有效的管理繁重的地理处理工作。地理数据库的设计和选择也必须进行优化来支持性能上的需求。系统平台的选择(服务器、客户端工作站、存储器)必须基于用户的工作流程要求。系统结构策略必须着眼于性能需求和分布式通信网络的带宽限制——运行环境必须围绕存储共享资源而设计。系统结构设计为建立一个具有高生产力的运行环境提供了一个坚实的基础。 1.3 支持成功GIS运行的步骤 支持一个成功的GIS运行的规划和实施有几个关键性的阶段。理解每一个阶段重要性和关键目标将会使企业运行更加成功。 图1-3 企业级GIS的部署阶段 ESRI白皮书 1 系统设计过程 系统设计策略 需求阶段 在需求阶段,理解GIS的技术选择、量化GIS用户的需求、建立适宜的系统结构设计的部署策略是很关键的工作。在这一阶段中“做好每件事”能够为整个项目的实施节省大量物力财力。 设计阶段 系统研发和原型的功能性测试为随后的部署提供了组件和信心。大部分客户都在这一阶段中投入最多的精力和花费来建立有效的企业运行。 建设阶段 在这一阶段中用来支持初始操作单元的解决方案都将聚集。性能和生产能力的规划将会被证实,并且硬件和基础设施也将证明它们能支持整个生产过程的部署。 实施阶段 这一阶段意味着成功。好的规划、开发和测试将带来一个顺畅的部署、高生产力的操作和满意的用户。 这就是从一开始就“做好每件事”的明显优势。投入必要的时间去理解技术、量化用户的需求、选择适宜的软件结构,配置正确的硬件构架将有助于做到这一点。 如果在开始阶段出现了偏差,那么在项目的后期进行纠正就会付出额外的代价,其改动的花费将随着项目的往后实施而呈指数级增长。 图1-4 没有做好规划而付出的代价 ESRI白皮书 1 系统设计过程 系统设计策略 1.4 系统设计过程 企业系统设计过程包括GIS需求评价和系统结构设计评估。系统结构设计评估是建立在GIS需求评价中被确定的用户工作流程需求的基础上的。 GIS需求评价 GIS需求评价包括用户工作流程需求的评估和确定哪些地方应用GIS可以提高用户的生产能力。这个评价确定了GIS应用和数据的需求,和支持GIS用户需求的实施策略。用户需求分析的过程必须由用户自己来完成。一个熟悉当前GIS解决方案和客户工作内容的GIS专业咨询家可以协助这一工作的完成。 ESRI白皮书 1 系统设计过程 系统设计策略 系统结构设计评估 系统结构设计评估是建立在GIS需求评价中被确定的用户需求的基础之上。客户在准备做系统设计规范之前,必须对他们的GIS应用和数据需求有一个清醒的认识。系统实施策略应该“及时的”确定硬件购买需求以支持用户的配置需求。 图1-5 系统结构设计 ESRI系统结构设计评估始于一项技术交流。这种技术交流为设计阶段的客户支持提供了基础。在设计过程中客户的参与是很关键的因素。设计过程包括现有的计算机环境评价,GIS用户的需求,和系统设计的选择方案。由ESRI提供的系统设计工具将用户性能需求转化为特定的平台规范。设计一个完整的实施策略是GIS配置的一个很重要的环节。 1.5 支撑技术 分布式的GIS解决方案包括多方厂家产品的集成。每件产品都完成整个企业级计算环境所需的一个部分的功能。主动与公认的行业接口标准接轨使得这种多厂商产品集成的环境成为可能。 全面理解与GIS企业级解决方案有关的主要支撑技术是进行系统结构设计的基础。图1-6列举了支持分布式GIS环境的关键技术。 图1-6 支撑技术 ESRI白皮书 1 系统设计过程 系统设计策略 GIS软件产品 在过去的33年,ESRI开发了多种GIS软件产品。每一产品方案的开发都是针对特定的用户需求。第二章描述了这些方案是怎样满足不断增长的GIS用户群的需求的。 GIS产品结构 一个企业级GIS解决方案包括了多种ESRI和第三方的产品。这些产品之间必须有公共的接口来支撑这个集成性的GIS解决方案。第三章对于支持分布式GIS方案所需的系统结构组件进行了概述。 网络通讯 网络通讯为一个GIS企业方案提供了强大的连接能力。对网络通讯有基本的理解有助于开发更好的应用程序和更有效的共享数据资源。第四章对网络通讯的概念和分布式GIS环境下的GIS设计标准作了概述。 用户需求和配置策略 系统结构设计过程始于用户需求评价。用户需求评价的结果给系统结构设计分析提供了基础。这一设计过程包括将高层用户的性能需求转化为适宜的GIS配置结构的方法,并且定义了所需的硬件规范。第五章对开发适宜的分布式GIS结构设计策略所需的用户需求评价和分析作了概述。 系统设计性能评估模型 ESRI系统结构设计咨询师们所做的一个最主要贡献就是将用户桌面应用程序的性能需求转化为在企业级设计方案中特定的硬件和网络规范。第六章讨论了支持ESRI性能评估模型的技术前提,确定了支撑GIS硬件方案的分布式计算平台组件的主要性能关系。第七章讨论了如何在日新月异的硬件技术发展中使用这些性能评估模型。对于每个GIS平台环境都提供了简单的性能评估工具,他们基于顶层用户负载而产生特定的平台规范。这些性能评估工具都是基于上一章开发的性能评估模型而产生。 1.6 项目中心框架 在一个成功的GIS实施中有多种层次的需求定义、设计和开发。理解每一个项目阶段和关键目标将有助于成功的企业实施。 ESRI白皮书 1 系统设计过程 系统设计策略 图1-7 项目中心框架 行业解决方案 最有效的解决方案往往建立在经验基础之上。GIS现在支持着一大批的行业解决方案。今天成功的GIS运行将为未来的行业解决方案提供坚实的基础。 策略与规划 一个企业方案的早期发展策略为成功的系统实施提供了一个框架。系统结构设计和相关的硬件需求必须建立在工作流程需求之上。系统结构设计计划为企业级GIS的配置提供了基础。 设计与实施 系统开发和原型功能性测试为配置提供了组件和信心。在这里客户们投入了大量的精力和花费来建立有效的企业运作。在初始系统配置中,各部分方案集中到一起来支持运行的需求。 产品和维护 成功的企业级GIS运行通常是多年的行业变化发展的产品。在支持有效的企业运行时,应对技术变革是最重要的挑战之一。周期性的系统结构设计策略计划的更新,有效的系统维护,定期的系统性能调试,实时的技术支持,和用户培训工作是保证高生产力的企业运行的有力措施。 ESRI组建了企业支持团队来为日益增长的企业级GIS用户群服务。对企业支持团队有任何的疑问,可以发送邮件至:est@esri.com。 ESRI白皮书 1 系统设计过程 系统设计策略 1.7 系统设计支持 ESRI系统集成部建立于1990年11月,旨在促进成功的GIS实施。许多创新小组发展了多年,一直致力于简化GIS环境的设计和降低实施的风险性。下列工作都被用来支持ESRI用户群的需求和提高企业级GIS解决方案的效率。 图1-8 系统设计支持 《系统设计策略》白皮书 《系统设计策略》白皮书探讨了与设计一个有效的企业级GIS方案相关的技术论题,并且包括了硬件选择的指导方案。ESRI用户群、硬件顾问和GIS技术人员可以使用这个文档来指导未来的分布式GIS方案设计。这个文档对于理解现有的硬件相关性能的议题和确定正确的解决方案有很大帮助。文档每年更新两次,欲知详情,请访问: http://www.esri.com/library/whitepapers/pdfs/sysdesig.pdf 《系统设计策略》工作书 《系统设计策略》工作书是用于ESRI系统集成支持的PPT文件,并定期更新以反映软件和技术的发展。工作书被用来作为ESRI系统设计咨询和培训的源文件。 系统设计支持 ESRI系统集成部通过sihelp@esri.com 提供在线的硬件市场支持。简单的有关硬件选择和规格需求的问题可以通过这个站点来咨询。 系统结构设计培训 ESRI培训中心提供为期两天的GIS系统结构设计培训课程,对白皮书内容进行深入讲解。课程手册包括在附件B中。为期一天的系统结构设计研讨会在每年的ESRI用户大会的前一个周末召开,对培训课程中的内容进行全面的技术阐述。 系统结构设计咨询 ESRI为用户提供专业的系统结构设计咨询服务。这些服务提供方案解决现有企业环境中存在的问题,并为未来GIS的实施开发框架提供策略支持。服务同时提供IT专业人员和所需的GIS信息。有关这些服务的介绍包括在附件A中。 ESRI白皮书 1 系统设计过程 系统设计策略 企业系统实验室 我们的企业系统实验室可以进行基于系统设计的ESRI和第三方产品及其在企业GIS环境中性能的测试和评估。实验室维护着一个网站:eslims.esri.com,在Microsoft Windows Terminal Servers 和 Citrix MetaFrame技术支持下提供ESRI产品演示版本的公共接口。站点还可以演示ArcIMS地图服务,并通过网络支持远程GIS用户的一个简单的企业硬件方案。 每年夏天圣地亚哥的ESRI国际用户大会有很多活动。系统结构设计技术研讨会提供一个系统设计策略的回顾。在会议期间,系统设计师在ESRI展示区的系统集成部为客户提供设计支持。还出版一个系统实施论文集,为ESRI用户提供一个机会去展示他们的GIS实践经验。 ESRI白皮书 2 ESRI软件发展历程 系统设计策略 2. ESRI软件发展历程 33年以来,ESRI一直致力于发展GIS用户群所需要的GIS软件技术。ESRI的软件开发者们一直紧跟最先进的计算机硬件和软件技术,以保持ESRI在GIS市场中的领先地位。ESRI努力整合所拥有的资源,提供最好的软件和服务来满足GIS客户的需求。 这一章对ESRI软件和相关产品技术进行了全面的概述。理解ESRI软件家族每个成员的主要功能有助于用户明确当前的应用需求,为设计成功的企业GIS方案提供一个清晰的蓝图。图2-1对ESRI软件的历史和支撑GIS企业方案的第三方技术进行了概括。 图2-1 GIS企业发展 许多ESRI用户已经用90年代提供的Workstation ArcInfo 和 ArcView GIS软件开发了成功的企业解决方案。新的ArcGIS软件提供了许多旧技术所没有的新功能。许多ESRI用户正在将他们的基于文件方式的数据和应用程序转向现在的基于ArcGIS geodatabase结构。而新用户正直接使用ArcGIS软件技术来设计企业GIS解决方案。 2.1 桌面工作站环境 GIS应用软件的传统环境是我们的用户桌面。ESRI桌面应用软件包括ArcInfo, ArcEditor, ArcView和用MapObjects 或 ArcGIS Engine 软件开发的客户应用程序。ArcInfo集成了Workstation ArcInfo,ArcGIS Desktop软件和ArcGIS geodatabase。ArcGIS 9在ArcGIS Server和ArcGIS Engine软件中使用了ArcObjects技术。网络地图服务可以通过标准的网络浏览客户端为每一个用户桌面提供GIS信息产品和地理处理服务。 ESRI白皮书 2 ESRI软件发展历程 系统设计策略 图2-2 GIS工作站/服务器 ArcGIS软件 ArcGIS是一个可升级的软件家族,包括了一个完整的建立在产业标准之上的地理信息系统,功能强大且突破陈规。组织机构部署ArcGIS软件以满足他们的配置需求——ArcView, ArcEditor, ArcInfo, ArcSDE, ArcIMS, 和ArcGIS Server。 ArcGIS被用来创建、管理、集成、分析、显示和传播空间数据和地理处理服务。强大的可视化、编辑、分析和先进的数据管理功能,使ArcGIS软件家族成为GIS软件的领先者。 Arcinfo. ArcInfo是一个完整的GIS数据创建、更新、查询、制图和分析的系统。由于它包括了最全面的GIS工具,所以专业人员都用它来进行空间数据的自动化处理。作为ArcGIS软件家族的组成部分,ArcInfo包括了ArcView和ArcEditor的所有功能,并且添加了地理处理和数据转换功能,它实际上已经成为GIS的标准。 ArcEditor. ArcEditor是一个高水平的GIS数据可视化、查询和创建的方案。ArcEditor为Windows桌面而设计,能够在一个ArcSDE Geodatabase中创建和编辑空间数据。作为ArcGIS软件家族的组成部分,ArcEditor包括ArcView的所有功能,并且添加了Geodatabase管理和高级编辑功能。 ArcView. ArcView是世界上最流行的桌面GIS和制图软件,有超过50万套在世界范围内使用。ArcView提供GIS数据可视化、查询、分析和集成功能,同时拥有创建和编辑地理数据的能力。 ArcView被设计成易于使用的Windows用户界面,包括了用于用户定制的VBA语言。ArcView包含三个桌面应用程序:ArcMap, ArcCatalog, 和ArcToolbox。ArcMap提供数据的显示、查询和分析。ArcCatalog提供地理和表格数据的管理、创建和组织。ArcToolbox提供基本的数据转换功能。 ArcSDE Database. ArcSDE是在你所选择的DBMS中存储和管理数据的工具。ArcSDE是开放的,可以兼容不同类型的数据库,其尺度从工作组到大型企业数据库,包括Oracle, Informix, IBM DB2, 和 Microsoft SQL Server。 ArcSDE在多用户GIS中扮演着非常重要的角色。有了ArcSDE的支持,你的ArcGIS软件(ArcView, ArcEditor, ArcInfo, ArcIMS)能够和DBMS中的空间数据直接工作。 ESRI白皮书 2 ESRI软件发展历程 系统设计策略 ArcIMS Web Services. ArcIMS软件是基于网络的分布式GIS数据和应用的基础。通过提供一个GIS资源交换和共享的公共平台,ArcIMS支持从机构内部和其他机构之间的数据和信息集成。ArcIMS的主要特点包括数据集成、标准化通讯、ArcGIS的网络技术、易于使用的界面、层状结构、支持一系列客户端、可升级的服务器结构和许多GIS功能。ArcIMS支持Windows和UNIX平台。 ArcGIS Server Web Services. ArcGIS Server软件是使用ArcObjects技术在网络上对ArcGIS的完全补充。ArcGIS Server将随着ArcGIS9软件的发布而部署。ArcGIS Server支持Windows和UNIX平台。 Workstation ArcInfo. Workstation ArcInfo提供了ESRI33年以来精心研制的一套完整的GIS工具,是当今GIS专业软件的旗舰产品。Workstation ArcInfo包括了一系列用来支持空间数据开发、维护和转换的行为的工具。许多年来,它已经成为帮助GIS专业人员进行地理学习、分析和制图的主要软件。Windows工作站和UNIX平台都支持Workstation ArcInfo。新的ArcGIS桌面环境支持绝大部分的传统Workstation ArcInfo技术。 ArcView 3 ArcView GIS 3是一个界面友好的桌面GIS软件,最初是为了满足ArcInfo用户群中日益增长的人口查询和分析需求而开发的。ArcView GIS能够直接读取ArcInfo coverage并且使用GIS shapefile格式存储空间视图。ArcView GIS很快流行起来并使GIS用户快速增长,没过多久就超过了ArcInfo的用户。GIS专业人员继续使用ArcInfo来创建和维护空间数据资源并帮助进行高技术含量的空间分析和地图制图。ArcView GIS则提供简单的GIS数据接口工具,进行日常的办公查询和分析,和制作简单的、非正式的地图产品。从最初的ArcView GIS发布开始,一大批的ArcView GIS扩展模块被开发出来以满足桌面用户市场的需求。现在ArcView GIS已经成为GIS界领先的桌面产品。Windows和UNIX平台都支持ArcView GIS。 MapObjects MapObjects是在Windows环境下用新的微软编程标准而开发的。ESRI基于这种新的面向对象的环境发布了MapObjects。开发者可以利用MapObjects在标准的微软应用环境下嵌入地图产品,这就为产品打开了一个新境界,并使ESRI开发群得到快速增长。MapObjects逐渐成为GIS与纵向市场产品方案结合的一个新标准。MapObjects能够读取和显示ArcInfo coverages, ArcInfo LIBRARIAN files, shapefiles, 和 Spatial Database Engine (ArcSDE) layers 等数据资源。对于定制基于Windows的GIS应用程序来说,这是一个非常适宜的编程环境。 ArcInfo LIBRARIAN. 随着GIS用户的增加,软件管理工具被用来帮助进行数据维护。用户通过复制一个层到内存并作相应改动来进行空间特征的更新,然后将更新后的层在GIS数据服务器上替换。当有多个用户在同一层上更新数据时,冲突就会发生。 ArcInfo包含了一个LIBRARIAN数据库管理模型,提供一个多用户的数据维护环境来帮助空间数据资源更加有效的管理。ArcInfo LIBRARIAN是一个基于文件格式存储的解决方案,它在一个数据库环境下,为GIS数据服务器上的所有数据层提供了一个连续的TILE结构。用户可以抽取一个coverage中单独的TILE进行编辑,同时ArcInfo LIBRARIAN中的相关TILES被实施“写保护”而避免更新过程中的数据改动。一旦编辑工作完成,被更新的TILE重新回到ArcInfo LIBRARIAN中,相关的TILES也被释放供其他用户更新。ArcInfo LIBRARIAN提供了一个简单而且有效的途径来帮助许多人同时维护和管理大型连续的GIS数据仓库。 ArcStorm Data Server. 大型企业GIS运行需要加强对ArcInfo空间数据资源的事务管理。ArcStorm通过提供特征层面上的事务管理、事务历史和执行逻辑(commit logic)来支持大型企业GIS运行环境。ArcStorm包括支持事务管理以及登入/登出( ESRI白皮书 2 ESRI软件发展历程 系统设计策略 check-in/checkout)过程的多个服务器过程。一个ArcStorm情境服务后台程序管理着ArcStorm数据文件并且产生用户事务处理所需的额外过程。ArcInfo提供支持ArcStorm libraries所需的功能。ArcView GIS能够使用NFS协议直接读取ArcStorm数据。客户工作站过程支持所有的读取操作。在ArcGIS技术中ArcSDE取代了ArcStorm。 数据库集成 在整个组织中,ArcInfo数据层中的空间特征可以与其他表格数据相连接。ArcInfo维护着一批数据库集成模块(应用程序接口,API),他们为Oracle, Informix, Sybase, 和 OpenIngres等关系数据库管理系统(RDBMS)中的属性数据提供直接的数据接口。Windows版本的ArcInfo, ArcView GIS, 和MapObjects兼容ODBC的应用程序,能够通过ODBC的驱动与DBMS相连接。这种连接能力改善和拓展了与其它兼容ODBC的数据库环境包括Microsoft SQL Server, IBM DB2等数据源的GIS接口。 有多种的商业门户提供大型机和AS400数据事务系统的在线接口。商业拷贝服务和管理数据的传输为GIS用户提供了获取比较难以得到的数据源的途径。 2.2 机构性GIS的发展 整个九十年代,GIS实施的规模和复杂性都快速的增长。GIS开始于用户桌面,并且逐步发展到使用部门级的文件服务器来帮助GIS运行。GIS群体中的绝大部分都是靠部门级的GIS结构而支撑的。图2-3 对部门级的GIS结构做了概述。 图2-3 部门GIS 随着GIS在一个机构内部的不断发展,许多部门将拥有自己的GIS运行方式,同时需要机构内部的其他部门的数据资源。所以在机构范围内的局域网就成为部门之间共享数据的主要方式。由于数据是由不同部门开发和管理的,有关数据的标准化和完整性的问题就在机构内部变得突出了。 最初在90年代中期发布的空间数据引擎(SDE)就是用来支持企业数据仓库的运行。许多机构都在一个中央ArcSDE数据仓库中来整合各部门的数据资源,并且在IT部门配置了GIS人员,来进行数据仓库中企业范围内的GIS数据资源,并提供机构内部的数据集成标准。于是在整个机构里就有了可靠的GIS数据共享的数据仓库。 ESRI白皮书 2 ESRI软件发展历程 系统设计策略 图2-4提供了一个机构性GIS结构选择方案的概览。 图2-4 机构性GIS 电力和煤气行业在90年代初期开始使用GIS来管理他们的能源设施分布。这些项目的绝大多数都用一个中央数据库来支持。远程用户可以通过终端接口来访问存储GIS数据库的应用程序服务器。 目前,许多机构正在将他们部门的基于文件格式的GIS数据库环境转向统一的企业级中央ArcSDE数据库,并且支持对这些统一的服务器环境的终端客户接口。通过中央ArcGIS应用程序的终端接口,各部门仍然保留着对他们的数据资源进行更新和维护的职责。这个中央IT计算机中心支持通常的管理任务,比如数据备份、系统更新、平台管理等。机构中的用户可以通过英特网的浏览器来访问ArcIMS服务。ArcSDE地理数据库的复杂性和综合性使集中管理成为现实,并且对大多数机构来说,是最具生产力的方案。 2.3 社区性GIS的发展 2000年所引起的互联网浪潮,表明了在机构和国家之间进行信息共享的巨大价值。网络接口已经从办公室发展到家里,其用户群快速的增加。社区和公司都通过网络为客户提供服务。互联网为机构之间的数据共享与服务提供了机会。通过网络,用户可以访问许多机构的数据和服务。 ESRI推出了一个元数据搜索引擎 Geography Network 来收集有关GIS数据的信息,并且为用户和数据或服务提供商之间提供直接的互联网连接。ArcIMS为机构提供了在世界范围共享数据和服务的途径。Geography Network为集中GIS数据与服务,支持世界范围内的信息共享提供了一个基础。对数据标准和数据收集技术的倡导为GIS信息产品创造了巨大的机会,并帮助我们更好的认识和改造我们的世界。 GIS的数据资源正在呈指数级的增长。几年前,GIS数据服务器很少有超过25到50G数据量的。然而今天我们看到,越来越多的GIS项目使用ArcSDE,对支撑数据库环境的服务器要求都超过了1T的数据量。 ESRI白皮书 2 ESRI软件发展历程 系统设计策略 图2-5 社区与联邦GIS 州级的办事部门正在统一数据来支持他们州的市政和商业活动。国家级部门则在州与国家社区之间统一数据来支持用户需求和数据共享。社区级别的数据中心的建立也是为了整合GIS数据资源和帮助县级和州级区域机构的互联网数据共享。 许多机构都将他们的IT运行部分外包给网络服务供应商(ISP)。而应用服务供应商 (ASP)则通过IT管理来支持机构,为一些小企业提供机会,使它们利用高端的GIS数据库和应用方案以满足他们的工作需求。州政府正在为一些小的市政当局集中管理着应用程序和数据,使他们能够利用GIS技术来帮助他们的区域运行。 区域的Geography Network(G.net)支持区域范围和大型的州和联邦部门的数据共享。ArcIMS软件提供了一个元数据引擎,用于数据共享和他们的社区服务。城市可以建立元数据站点来倡导本地区的商业和公共利益。各个州可以整合数据搜索引擎来进行整个州的市政当局之间的数据共享和服务。法律部门可以建立搜索引擎来支持国家数据集。商业部门可以建立元数据搜索引擎来支持分布的运营环境。 2.4 GIS技术方案选择 当前的GIS技术已经可以跟上不断增长的GIS用户需求。ESRI的产品加上多种的第三方技术为解决方案提供了强有力的支持。 图2-6 ESRI核心的GIS技术 ESRI白皮书 2 ESRI软件发展历程 系统设计策略 随着各个机构继续发展和维护更大量的GIS数据,数据存储和数据管理技术的重要性日益增长。直接的连接存储方案发展成为存储局域网(SANs)以增强海量数据管理的IT选项。 相关的数据服务器包括文件服务器、ArcSDE服务器和属性数据服务器。桌面的ArcGIS应用程序在本地的工作站客户端得到支持。同样的程序也可以在远程客户端使用Windows Terminal Server得到支持。 ArcIMS为组织机构的Web浏览客户提供出版的地图服务器,也可以在互联网上为客户提供公众地图服务。ArcGIS客户可以作为智能浏览器客户连接到ArcIMS,访问Internet Geography Network中的无限数据资源和通过ArcIMS服务的组织机构的资源。用户可以在家里或其他地方来使用这些应用程序。移动ArcGIS用户可以在野外创建红线区,并且提交到一个中央ArcIMS站点做后续处理。ArcGIS的桌面应用软件包括本地的ArcSDE和作为数据源的ArcIMS服务和文件服务器,它将桌面地图生产和分析扩展到互联网的数据资源。“ArcGIS构架”包括了ArcSDE数据源、ArcIMS网络服务和ArcGIS桌面技术。 Geography Network元数据搜索引擎的实施和由ArcIMS 4 软件支持的本地元数据站点增加了机构之外的用户访问数据资源的途径。这个“G.Net构架”将传统的机构性GIS信息资源扩展为包括互联网在内的数据资源,为不断增长的GIS用户需求提供了一个丰富的数据环境。 多样的设计选择使各机构能够为他们的用户需求提供一种最佳的企业GIS解决方案。 2.5 GIS软件选择 选择正确的软件和有效的配置结构是十分重要的。ArcGIS技术为支持特定用户的工作流程需求提供了许多可选择的结构方案和多种多样的软件。 图2-7 GIS软件技术选择方案 ESRI白皮书 2 ESRI软件发展历程 系统设计策略 GIS数据源 GIS数据源包括本地硬盘或CD-ROM、共享的文件服务器、ArcSDE DBMS服务器或网络数据资源。本地数据资源支持高性能的最小网络等待时间的应用工作流程。远程数据资源允许连接到多种的已公布的数据资源,但是存在潜在的带宽阻塞和低性能问题。现在已经有了一些结构方案用来解决性能问题和支持分布式的数据接口。 桌面应用软件 使用ArcGIS的桌面应用软件可以带来高层次的功能和生产力。有了ArcGIS的桌面应用软件,绝大多数的专业GIS人员和GIS的使用者将变得更具有生产能力。这些软件可以在用户的工作站或者在中央Windows Terminal Server运行的软件的终端接口使用。一些更加强大的ArcGIS桌面应用软件的扩展模块在本地数据资源的用户工作站上表现最佳,而大多数的ArcGIS桌面用户工作流程在一个Terminal Server上更加有效。选择合适的应用软件配置策略对于用户的性能、管理的支持和基础设施的建设具有很重要的意义。 网络服务 ArcIMS和ArcGIS Server技术为多样的更加集中的GIS用户工作流程提供有效的支持。网络服务也为远程的客户工作流程提供了有效的数据共享途径。ArcIMS提供了最有效的公布标准的地图信息产品的途径。ArcGIS Server为更高级的用户工作流程和服务提供了增强的功能。对于一个机构和相关的用户群来说,网络服务是利用GIS资源的一个低成本的服务。 移动服务 更加松散连结的移动GIS解决方案支持的GIS操作也在日益增长。ArcGIS技术支持连续的工作流程操作,包括离线编辑和远程无线操作。这种离线结构方案能明显的为一些运行的工作流程降低基础设施的成本,提高用户的生产能力。利用移动服务能够为多种的用户工作流程环境提供可选择的方案。 ESRI白皮书 2 ESRI软件发展历程 系统设计策略 2.6 GIS配置选择 在一个机构内部,GIS环境通常开始于部门级的单用户工作站。许多机构开始于一个GIS经理,从一个部门发展到一个企业的运行。在90年代早期,许多组织致力于建设他们的空间数据的数字表达形式。一旦这些数据可用,机构便开始扩展他们的GIS运行来支持整个企业业务运作。 空间数据通过一层层的线划、点和多边形,以合适的文件格式存储,这就是所谓GIS层的概念,与传统的Mylar层相似。客户应用软件对这些层进行叠加来产生地图。空间数据能够以合适的文件格式或者作为一个数据库表格中的空间特征类型进行存储。标准的文件格式包括coverages和shapefiles。LIBRARIAN提供了一个“Tiled coverage”格式来帮助数据的维护操作。ArcStorm包括了多种的管理与相关表格属性数据集成的数据库的服务器过程。 数据能够通过多种途径在用户之间共享。当今的绝大多数机构都有与本地局域网(LAN)相连的用户工作站环境,并且在专用的服务器平台上设立共享的空间数据。用户的应用软件与共享的数据资源相连接并支持GIS操作。 集中式数据配置方案 这是由一个中央GIS数据库支持的最简单的系统结构。一个中央数据库结构支持着产品数据库环境的一个拷贝,尽量降低管理需求和保证数据完整性。图2-8提供了一个集中式数据配置结构的概览。 位于集中式LAN的用户工作站和中央GIS数据资源都有接口,并支持GIS桌面应用软件。数据资源包括GIS文件服务器、ArcSDE数据库服务器和相关的数据资源。 远程用户到中央数据资源的接口由中央Windows Terminal Server支持,并对集中式的应用环境提供低带宽的显示和控制功能。 图2-8 集中式计算环境 ESRI白皮书 2 ESRI软件发展历程 系统设计策略 集中式的应用环境在整个机构范围内降低了管理需求,简化了应用配置与支持。源数据在集中的计算设施中被保留,增强了安全性并简化了备份需求。 多种的ArcIMS地图服务能够在整个机构内支持标准的浏览客户端。网络地图服务支持连接到已出版的GIS信息产品和服务的低带宽接口。 今天,分布式计算技术比起相似的分布环境,能以小得多的风险和花费支持统一的结构。正因为如此,许多机构正处于整合他们的数据和服务资源的过程中。GIS正是在其他企业解决方案经历的整合中获益。集中式的GIS结构一般来说比分布式结构易于配置、管理和维护,并提供统一的用户性能和功能。 分布式数据配置方案 分布式的解决方案是通过处于远程位置的数据复制来进行的,它建立的本地过程环节必须与中央数据库环境的维护工作相一致。数据的完整性在这种环境中十分的关键,要求用适宜的工作逻辑控制的程序来保证任何的变动都被复制到相关的数据服务器上。 图2-9 分布式计算环境 ESRI白皮书 2 ESRI软件发展历程 系统设计策略 分布式的数据库环境通常会增加最初的系统损耗(包括对硬件和数据库软件的更多要求),并且需要额外的工作以满足系统管理和系统维护要求。分布式方案是应特定用户的需求而提供的,通常会增加系统复杂性、开销和系统配置时机。 在许多案例中,标准的数据库方案并不支持空间数据的复制,所以具有分布式数据库要求的GIS用户必须修改他们的数据模型,建立程序来支持数据的复制。DBMS供应商们已经意识到提供空间数据复制功能的必要性,并且新发布的产品已经可以支持一些层面上的空间数据复制。ESRI也在开发一个解决方案,来支持多个ArcSDE Server之间的地理数据库的同步行动。目前地理数据库环境的复杂性也使一个自动有效的空间复制方案变得复杂。 2.7 ESRI ArcGIS的实现 许多ESRI用户已经用ESRI的产品和数据格式很多年了,因此,有大量的定制应用程序和数据集在GIS界的不同地方被开发和维护。这些数据和应用的繁殖也导致了一个多样的数据和应用环境。 ArcGIS技术尤其适合于一个企业GIS的实施,它能够帮助企业从现有的“烟囱”式GIS环境转变到一个真正的企业级GIS环境。特别是geodatabase技术,可以在这一转变过程中提供切实的利益。ArcGIS技术也适用于那些新用户,帮助他们将现有的表格数据资源空间化来支持企业GIS的实施。许多空间数据资源也用于各个机构利用GIS技术来转移它们的操作过程。 Geodatabases有两种形式,个人版和多用户版。个人版Geodatabases在 Microsoft Access中运行,非常适合项目级别的GIS。多用户版的数据库通过ArcSDE配置,它需要一个DBMS,比如Oracle, Microsoft SQL Server, Informix 或者DB2。在一个商业数据库里直接存储空间和属性数据赋予了geodatabase一种其他格式难以企及的能力。下面列出的是这些优势的一部分。 n 地理数据的统一的存储仓库。所有的地理数据都在一个数据库中集中的存储和管理。 n 数据的读取和编辑更加有效。子类型、域和有效性规则帮助维护数据库的完整性和减少数据库维护工作量。 ESRI白皮书 2 ESRI软件发展历程 系统设计策略 n 特征集是连续的。Geodatabase能够包容大型的特征集合,并且它们之间没有TILES或者空间裂隙。 n 多用户编辑。ArcSDE geodatabase 环境使用一个被称为“版本化(Versioning)”的数据管理框架,它允许多个用户同时访问和编辑特征数据,并协调各类可能发生的冲突。 n 与特征关联的注记表达。Geodatabase的注记能够与它所描述的特征数据相关联。当相关联的特征数据被移动或删除的时候,相对应的注记也相应的被移动或删除。 n 用户可以使用更加直观的数据对象进行工作。一个被正确设计的geodatabase包括了与用户的数据模型相对应的数据对象。除了通常的点、线、面,用户还可以使用一些感兴趣的对象,比如区域、道路和或湖泊等。 n 使用geodatabase可以变得非常简单和直接。Geodatabase 能够通过标准菜单和ArcCatalog,ArcToolbox和Arcmap中的工具进行创建、访问和管理。此外,geodatabase模型支持智能的特征、规则和关系,高级用户可以在复杂的GIS应用中使用。 除了geodatabase技术优势,ArcGIS桌面应用软件提供了一套基于Windows的GIS数据查询、分析和管理工具。这些工具提供与过去ESRI用户使用AML和Avenue开发的应用程序相对应的功能。商业售出的ArcGIS功能集也可以根据需要使用基于COM的ArcObjects技术进行扩展。ArcIMS 和 ArcReader为需要使用浏览和查询功能接口的用户提供了额外的GIS功能。从现有的数据和应用程序转换到ArcGIS技术可以为GIS界带来切实的益处和效率。 2.7.1 数据转移策略 传统的GIS数据都在本地工作组进行存储、更新和管理工作,这就导致了许多专题数据的重复拷贝。机构内的高层进行数据汇总必须付出额外的工作量来整合各种不同的数据集。尤其是当不同工作组的数据集规划不一致的时候,这种汇总汇变得更加困难。 要解决企业层分析中数据汇总的困难,很重要的一步就是定义所有的数据管理人员都必须遵守的数据标准。然而这种标准的制定过程是需要花费时间的,并且由于各地区业务过程和地理分布的差异而变得困难。数据标准化的前景会根据业务的范围或易或难。 ArcGIS提供了一大批工具来帮助数据的标准化和管理。从数据库设计方面来看,ArcCatalog和Visio的UML CASE工具可以用来定义一个geodatabase模型。这个模型定义了实体(特征和对象集)及其定义(字段大小和类型、NULL功能、默认值、域等)以及这些实体之间的关系。这些模型可以从一开始定义,也可以从现有的机构设计或基于geodatabase模板进行开发。这些模板由ESRI提供在:(http://arconline.esri.com/arconline/datamodels.cfm)。 对于标准化的执行有多种途径。其中三种执行数据标准的方案是:(1)数据存储的集中化并通过终端服务器技术进行存取,(2)离线编辑和集中性的对所管理的数据进行核对,(3)根据企业的数据标准周期性的对各地数据集进行汇总。 集成数据最简单的方法就是强制执行模型所制定的定义,这样所有的数据都遵循同一个定义进入到ArcSDE数据库中。通过过程管理或集中数据库并且提供通向中央数据库的本地接口,用户可以实现这一目标。这种方法的优势在于数据管理职能的集中和数据库模型的严格执行。 集中式以外的另一个方案就是对模型中的主要元素定义数据标准。它允许本地用户对主要模型进行扩展来添加他们自己的附加值信息。在这种方案中,本地数据管理人员的职责负责是将必需的字段按企业标准执行,对于其他附加信息则可以忽略企业标准。ArcCatalog提供了一个in-the-box的图形化用户界面(和可编程对象)来支持从一个模型向另一个模型的字段映射。ArcGIS层文件也提供工具将物理模型中的字段名更改为更加友好的别名。当本地命名法不一致的时候这样做可以减轻标准化工作的难度。这种方法的优势在于其灵活性,允许本地用户为了他们本地的业务需要增加字段到模型中。 无论是选择上述的哪种方案,现有GIS数据的转移在某种程度上已经成为必需。尽管ArcGIS支持shapefile和coverage的管理、查询和分析,但是现有数据的内容最终需要和企业标准相符合。在由多个用户编辑和维护的数据案例中,多用户的ArcSDE geodatabase可以为管理数据转换提供最强有力的模型。 ESRI白皮书 2 ESRI软件发展历程 系统设计策略 图2-10提供了一个数据转移路径图,表明了由ArcInfo和ArcView数据集向SDE简单层(non-geodatabase)和geodatabase数据模型的转移过程。它也表示了如何将SDE简单层集成到geodatabase数据模型和其中的不同组件与过程中。 图2-10 数据转移路径图 从简单的到更加坚固的数据结构的数据转移选项包括: n 使用ArcSDE管理工具(命令行)将基于文件的数据(shapefiles,coverages,librarian tiles等)转移到ArcSDE简单层。 n 在创建了ArcSDE简单层后,他们可以被注册到geodatabase中。一旦一个层注册完毕,它的特征类可以被版本化(versioned),以支持多用户的数据维护操作。域,关系类和其他与对象相关的行为就能被添加到特征类中,从而扩展了geodatabase的能力。 n 用户使用ArcCatalog或Arctoolbox直接将基于文件的数据转移到geodatabase中。这一转移路径允许用户创建新的特征类或者对现有的geodatabase特征类进行添加或更新。一旦一个geodatabase建立,这将是首选的转移路径。 传统的ArcInfo和ArcView客户能在新的geodatabase里面使用默认版本来浏览和查询数据。ArcIMS图像和特征服务也可以访问ArcSDE geodatabase的默认版本。 2.7.2 应用程序转移策略 在GIS界,除了数据库模型的多样性以外,还有不计其数的应用程序为了管理和分析数据而开发。虽然不同用户的业务流程各有特色,但是管理GIS数据资源的主要职能还是一样的。因此,管理GIS数据资源的应用程序也应该被标准化。制定数据标准是建立共同的GIS应用程序中非常重要的一步。ArcGIS桌面工具提供了一系列管理和分析数据的功能集,它们无需考虑数据库模型。 ESRI白皮书 2 ESRI软件发展历程 系统设计策略 传统的应用程序包括ArcInfo定制应用程序、ArcView 3 定制应用程序和ArcView 3 标准客户端。在这些定制应用程序中开发的许多功能都可以包括在ArcGIS标准客户端,或者可以融入数据模型中。这样就会减少使用ArcGIS技术进行应用编程的要求。 技术更新包括转移客户端到ArcIMS地图服务、ArcGIS桌面客户应用程序(ArcView 8 ,ArcEditor 8 或者ArcInfo 8)或者定制的ArcGIS应用程序。从现有运行环境向ArcGIS的转移需要很多步骤。 培训 首先必须对COTS ArcGIS技术的性能和使用进行培训。训练一群超级用户或领域专家将为下一步的转换—应用程序代沟分析(application gap analysis)奠定基础。 需求评价和代沟分析 要知道每个GIS用户所需要的功能和确定哪些功能不能由COTS ArcGIS技术直接支持,必须进行用户应用需求评价和代沟分析。这个分析确定哪些用户可以直接向ArcGIS转移,哪些用户还必须等待定制的ArcGIS应用程序。定制的应用程序可以使用支持COM的编程语言(如Visual Basic,C++)加上ArcObjects技术来建立。 高权限用户的转移 高权限用户包括那些受到GIS分析和技术训练的GIS专业人士。他们当前任务中的许多都是建立在特定基础之上,不需要定制应用程序。许多高权限用户应该可以直接转移到标准的ArcGIS桌面产品,无需定制开发。ArcGIS的桌面产品提供了到ArcIMS数据资源和ArcSDE geodatabase版本和对象关系的接口。 操作员用户的转移 在从当前定制ArcInfo应用程序向标准的桌面运行环境转移的时候,有一些定制程序是必要的。许多基本编辑操作可以直接由标准ArcEditor桌面支持。还有一些ArcView应用程序可以由ArcIMS技术支持来进行查询和分析。 图2-11 提供了使用AML、Avenue和COTS ArcView 3.X技术的传统应用程序的转移路径图。 图2-11 应用程序转移路径图 ESRI白皮书 2 ESRI软件发展历程 系统设计策略 请注意每一个现有平台的转移路径都可以无需定制而直接从现有的操作平台转移到ArcGIS。同时也请注意,一些ArcView 3 的用户能够通过连接到ArcIMS服务器的浏览器客户端来展示其查询和分析功能。在从现有环境到ArcGIS环境的转移过程中,有时还需要连续使用现有的AML应用程序。Workstation ArcInfo通过数据接口提供这样的功能,现有的AML仍然保留为coverage格式,直到现有代码与ArcSDE数据兼容,或者用户已经熟悉ArcGIS桌面工具。 ESRI白皮书 3 网络通讯 系统设计策略 3. 网络通讯 网络通讯为分布式计算过程提供了必需的连接能力。网络产品为分布式数据的传输提供了一个稳定并且可靠的通讯协议。多种的通讯协议支持整个单位中不同地点的分布式应用程序和数据资源。 多年来计算机的性能加速增长,而网络技术却停留在一个相对稳定的水平。近年来随着网络技术的发展,网络解决方案也有了显著的转变。它通过互联网将整个世界连接在一起,将不计其数的信息资源在第一时间直接送到计算机桌面上。 3.1 桌面工作站环境 GIS应用程序与文档管理、视频会议一起被认为是网络流量的大户。GIS技术为用户提供了一个可视化显示环境,支持大量图形数据的快速分析处理。对分布式数据资源的实时显示和分析主要依靠网络通讯,数据必须传输到程序执行的地方来进行显示信息。 图3-1 GIS应用对网络的影响 数据是存储在具有记录和保存数据结构能力的媒介中的数字计算机信息的集合。这些数据是由被称为比特(bit)的小信息块表示。一个比特在一个存储或传输媒介中占有同样大小的空间。为了方便起见,这些小比特被组成字节(byte),其中每个字节包括8个比特。数据能够以数据包的形式从一个地方传输到另一个地方,以保护这些数据的完整性。 通常情况下,数据都是通过铜金属丝或玻璃纤维的物理网络从一个到另一个存储地。其他传输媒介包括微波、无线电波和卫星数字传输。根据用于支持传输的技术,每一个网络协议对于它所支持的数据传输速率都有一个限制范围。 网络传输方案可以被分为两大技术类别,分别是局域网(LANs)和宽域网(WANs)。每秒能够被传输的数据量(用比特来衡量)代表了一个特定网络段的传输速率(能力)。这个能力被称为网络带宽,通常使用每秒百万比特(megabits)或者每秒十亿比特(gigabits)来衡量。 图3-2 网络的类型 ESRI白皮书 3 网络通讯 系统设计策略 局域网(LANs) 局域网支持短距离内的高带宽通讯。这一环境支持本地的运行环境(通常是在一栋楼内或者本地的校园环境)。数据的传输技术是单线程的,这意味着在任何时候单一的局域网段只能支持一种数据传输。局域网环境的建设花费相对于其他支持系统环境的硬件设备来说是廉价的。 宽域网(WANs) 宽域网支持远程地点之间的通讯。这项技术支持的带宽要比局域网环境低得多,但是它支持长距离的数据传输。在这个数据传输环境中,数据被打包在一系列附加的信息包之上,并且通过传输媒介作为数据流进行传输。宽域网络连接的花费相对于局域网环境来说相对较高。 数据单位 当数据在计算机硬盘上存储时,其数据容量使用megabyte或者gigabyte来衡量。Megabyte(MB)缩写为一个大写的“B”,而megabit(Mb)缩写为一个小写的“b”。当我们从磁盘存储器向网络传送数据的时候,必须牢记1 MB = 8 Mb。 3.2 客户/服务器通讯概念 应用程序通过使用客户/服务器通讯协议的网络进行数据的传输。位于客户端和服务器平台上的通讯过程定义了通讯格式和地址信息。数据被打包在通讯信息包里,这种信息包包含了从客户端向目标服务器传输数据所需的通讯控制信息。 通讯数据包的结构 最基本的互联网数据包结构包括了目标地址和源地址,以及附加在数据结构之上的控制信息。这种信息帮助数据包通过网络媒介传输。IP数据包的大小根据数据量而不同。最大的IP数据包大约是65 Kilobytes(KB)。Ethernet框架被限制在1.5KB。在一个单一的数据传输中,数据可以被分散在许多个数据包中传输。 ESRI白皮书 3 网络通讯 系统设计策略 图3-3 通讯数据包的结构 网络传输协议 通讯数据包在传输的过程中被构建为不同的层。从Host A应用程序中的数据流通过协议层来建立一个网络传输的数据框架。传输控制协议(TCP)头文件在传输层将数据打包,在网络层添加了网络协议(IP)头文件,在物理网络层包括了媒介接口控制(MAC)地址信息。这一数据框架通过网络传输到Host B,在那里相反的操作程序将数据传输到主机应用程序上。一个单一的数据传输能够包括主机应用程序之间很多通讯的往复。 图3-4 网络传输协议 3.3 客户/服务器通讯 有多种客户/服务器通讯方案支持网络数据传输。每一种方案都包括了一个客户端和服务器组件来支持数据传输。客户端过程为将要传输的数据做准备,服务器过程将数据传输到应用程序环境。用于GIS解决方案的主要协议有: ESRI白皮书 3 网络通讯 系统设计策略 图3-5 客户/服务器通讯 NFS(UNIX)和CIFS(Windows)协议 协议支持远程硬盘装置,使客户应用程序能够从分布式的服务器平台访问数据。所有的查询信息都在客户应用程序中,它控制着位于服务器平台上的数据接口。数据必须传送到客户应用程序中来进行分析和显示操作。 ArcSDE API ArcSDE包括了客户端和服务器通讯组件。服务器组件包括了支持查询处理的信息。数据在传输过程中被压缩,在客户应用程序中被解压缩。数据必须传送到客户应用程序中来进行分析和显示操作。 一个可选择的ArcSDE客户端通过与桌面上的DBMS客户端API相连接来控制其连接选项。客户端平台支持ArcSDE的中间件功能,而DBMS网络客户端支持到服务器的数据传输。查询过程仍然在DBMS服务器上运行。 ICA和RDP协议 协议支持远程终端显示和Windows Terminal Server支持下的应用程序控制,传输显示和控制信息到终端客户。ICA和RDP协议都需要对传输的数据进行压缩。 HTTP协议 它是标准的网络传输协议,基于事务处理环境和由浏览器客户端控制产品选择和显示。传输的数据需要压缩。ArcGIS的桌面应用程序能够访问作为数据源的ArcIMS。由ArcGIS桌面产品造成的网络堵塞主要是由于大容量的图像传输所致。图像尺寸与电脑屏幕的显示尺寸有直接的比例关系,所以大尺寸的图像显示会造成严重的网络堵塞。 ESRI白皮书 3 网络通讯 系统设计策略 3.4 客户/服务器网络性能 数据传输容量和网络带宽可以带来期望的用户响应时间。一个典型的GIS应用程序需要至少1M的数据来产生一个新的地图显示,而一个典型的终端环境则需要100KB的数据来支持显示环境。 图3-6 客户/服务器性能 上图是使用megabytes(MB)的形式来表达数据传输需求的,并将它转换为传输所需的megabits(Mb),包括这些数据按照通讯协议进行的压缩,并用megabits(Mb)计算所有需要传输的数据量(使用协议所需的数据量通常比使用简单的转换方法要大)。传输这些数据所需的时间按照四个标准带宽方案进行了计算。这个简单的插图说明了引起远程客户端性能问题的主要原因。对于支持用户性能需求来说,足够的带宽是十分重要的。 文件服务器配置支持从客户端应用程序的查询。当从一个文件(coverage或者shapefile)选择数据的时候,整个文件必须传送到客户端进行处理。其中应用程序所不需要的数据在客户端被剔除。这就导致了这些通讯过程中大量不必要的网络开支。 ArcSDE客户/服务器配置支持在服务器平台的查询过程。这一查询过程包括定位被请求的数据并过滤这些数据,保证只有客户端所需的特定数据才能通过网络返回到客户端。如果客户端的数据请求只限于微量的数据(比如点数据或者一个区域层中的一个小区域),则数据传输量会非常小,网络传输性能也会相应的提高。 网络配置选择的最佳实验方案表明,分布式客户/服务器应用环境通常情况下要比局域网环境中的性能更佳。基于事务处理的服务器,或稳固的Windows Terminal Server能够提供一个稳定的操作环境来处理不太稳定的宽域网连接。 3.5 共享的网络性能 单一网络段上的客户端数量是由网络传输时间(数据传输量和网络带宽)和并发客户端数量决定的。在一个共享网络段上的一点,只有一个客户端的数据包可以被及时的传输。在同一Ethernet网络段的多路传输将会导致冲突,这时就需要第二次的传输来完成数据帧的发送。由于迅速增长的传输量,Ethernet网络段在饱和时期会经常停止工作。 ESRI白皮书 3 网络通讯 系统设计策略 图3-7 共享的网络性能 令牌传递(Token-passing )环境的运行有些不同。并发事务必须等待一个令牌来支持数据帧的传输,从而导致了传输延迟。随着网络达到饱和,这种延迟会增加。失败模式要比Ethernet好得多,它支持更高的可接受的带宽利用率。 3.6 典型的1M地图显示 一个GIS应用程序需要1M的空间数据,或10Mb的网络流量,来支持一幅地图的显示。当地图范围超过了既定设置的时候,应用程序能够阻止某些图层的显示。对于每一个地图范围,只有适当的数据应该被显示(比如在一幅表示整个圣迭戈范围的地图中显示单个parcel层显然是不合适的)。适当的调整应用程序能够有效的减少网络流量,提高性能。 图3-8 典型的1M地图显示 (比例尺1:3000英尺,平均特征=250) ESRI白皮书 3 网络通讯 系统设计策略 3.7 网络配置指南 已发布的标准指南可以用来指导配置网络通讯环境。这些标准面向应用并且基于典型用户环境的需求。通讯环境本质上是天生适合统计学的,因为只有一部分的用户处理时间需要通过网络传输。网络数据传输时间只是GIS用户全部响应时间(在正确配置的网络上)的一小部分。当带宽太小或过多用户在同一共享网络段上,网络数据传输时间就占整个响应时间的大部分了。 图3-9 网络配置指南 ESRI白皮书 3 网络通讯 系统设计策略 网络必须被设计为支持高峰流量的要求,并且它由应用程序类型和用户工作模式所决定。标准指南只是为开始配置一个网络环境提供了一块空间,一旦网络开始运行,网络流量应该被监测并且按用户需求进行必要的调整。 3.8 共享网络配置标准 图3-10提供了网络环境的推荐设计指南。这些指南为配置分布式的局域网环境提供了一个基准。对应于每一个网络带宽都有五个独立的客户/服务器环境。推荐的客户端数量都是基于实际系统运行的经验,不代表最差条件下的环境。网络的配置必须具有灵活性,以便为高权限用户在其数据传输需求超过典型的GIS用户带宽需求时提供特殊的支持。 图3-10 网络设计指南 3.9 局域网组件配置 局域网通常是使用在整个建筑范围内的不同地点的布线箱和从布线箱到每个用户桌面的双绞线来建设的。每个用户的桌面计算机都与布线箱内Ethernet或令牌环hub 的端口相连接。布线箱内的hub都通过玻璃纤维或者双绞铜线连接到计算机房。网络带宽性能是由计算机网络界面和布线箱中的hub端口所决定的。 有两种类型的hub支持着绝大部分网络环境。最初的hub技术支持的是一个共享网络。这在局域网络客户之间的数据共享起到了很好的作用。而分布式的客户/服务器处理配置需要更多的带宽。一种新的可转换的hub技术就被引入来支持日益增长的流量需求。 图3-11 共享的局域网 ESRI白皮书 3 网络通讯 系统设计策略 共享的Ethernet hub 一个广播协议被用来支持Ethernet通讯。一个标准的Ethernet hub是Ethernet局域网的基石。每一个用户的工作站和数据服务器都与Ethernet hub中的端口相连接。 当用户A与数据服务器通讯时,通讯在与共享hub相连接的所有局域网段传播。在同一时间内,任何其他试图传输的行为都将导致冲突,在一个随机时间内延迟,然后重新传输。当同一时间内试图传播的用户越多,这种冲突就会增加,传输的数量也呈指数级增长直到网络流量完全饱和。 局域网环境下最大的推荐通讯率为25%到35%的利用率(根据用户的总数而定)。网络支持下的总流量是通过任何两个用户同时发起传输行为的可能性来决定的(网络上的用户越少,其利用率就越高)。 不断增长的带宽(100 Mbps versus 10 Mbps)能够减少数据传输的时间(更快的数据传送)和降低传输冲突的可能性(每个传输行为在网络上花费更少的时间)。一个100BaseT的网络能够处理大约10倍的10BaseT网络的客户数量。 可转换的hub 一个Ethernet可转换的hub将每个用户的工作站地址绘制在转换底板上,只有当传输针对那个用户而发的时候他们才会被发送到那个用户的局域网段。Ethernet底板有很高的带宽(gigabit量级),所以多个传输可以共享底板的接口,它可以为每个用户提供更高的带宽。 连接到公共网络位置的上行线(中央数据服务器或者网络底版)应该包括更高的带宽。由于网络性能的差异,许多用户实际上可以同时访问服务器。比如:一个拥有五个10BaseT段和一个100BaseT段的可转换的Ethernet网络能够支持共计等于50-Mbps到服务器的带宽。 一些Ethernet转换器支持在双向模式下配置的单用户网段,它允许这些网段同时发送和接收信息(每个使用双绞线的一股)。这个转换器包括一个高速缓冲存储器,用来在双向连接时阻止冲突。在一个100-Mbps端口上的双向连接能够提供高达200-Mbps的带宽(每个方向100Mbps)。完全的双向连接能够提供更高的传输负载量,因为他们可以避免冲突并且在高峰流量情况下重新发送。 网络技术在过去的几十年里得到了迅速的发展。今天,许多转换器都支持多种的网络功能,包括协议转换和通讯路由选择。可转换的gigabit Ethernet的推出使许多单位有能力替换昂贵的网络底板,花费低且性能高。随着技术的进步和成本的降低,网络组件正在变成一种商品。互联网技术已经显著的扩展了网络通讯市场,并激励着更新更快的网络技术。 ESRI白皮书 3 网络通讯 系统设计策略 3.10 网络服务配置指南 ArcIMS网络地图服务的实施给网络基础设施增加了额外的要求。系统影响的程度与已发布的地图服务的复杂性相联系。小型的(小于10KB)或者有限度的复杂图像对于网络流量的影响微乎其微,而大型图像(大于100KB)对于网络性能有很显著的影响。 图3-12 对部署一个网络地图解决方案所应该考虑的网络性能特征进行了概括。图表的上半部分表明了根据平均地图的图像大小,不同WAN带宽所能支持的最大请求个数。图表的下半部分表明了不同大小地图图像的最佳传输时间。网络信息产品的设计应该满足用户的性能需求,这种需求可能要受到带宽的限制。标准的ArcIMS地图服务应该产生从30KB到50KB大小的图像,这样做是为了减少到标准ArcIMS客户浏览器的网络传输时间(如果单一的T-1网络服务提供商的连接能力最大为每小时7400个请求,则50KB的图像用28Kbps的modem需要超过17秒的网络传输时间)。ArcGIS桌面用户可以访问从200KB到400KB的ArcIMS图像。用户通常要求更高的性能,或者说他们将不会被满足。合理的基础设施带宽和周密的地图信息产品设计对于支持高性能的网络解决方案来说是十分必要的。 图3-12 ArcIMS网络性能 ArcIMS包括一个Extract Service,可以支持从互联网上下载数据到网络客户端。ArcIMS Extract Service根据已确定的范围从ArcSDE提取数据层,并将数据压缩为一个压缩文件,下载到客户端上。图3-12显示了基于可用的网络带宽和压缩数据包的大小而确定的最小下载时间。数据的下载应该被适当限制以保护网站服务的带宽。数据的下载非常易于占用可用的网络带宽,并且对其他网络地图的客户端性能造成影响。 图3-13 数据下载性能 ESRI白皮书 3 网络通讯 系统设计策略 许多网络管理人员掌握着关于网络利用的规律,这些规律帮助他们在对未来用户配置进行规划时估计增长的网络需求。图3-14提供了根据典型GIS客户的目标数据源而制定的标准网络设计规划因子。这些数据将在下面章节中被用于GIS用户规划网络带宽。 图3-14 网络设计规划因子 ESRI白皮书 4 GIS产品结构 系统设计策略 4.GIS产品结构 本章内容为理解分布式GIS应用所涉及到的组件概念提供了基础。理解基本的应用程序结构、商业产品与定制应用程序之间的关系和支持GIS解决方案所需的组件接口对于理解分布式GIS设计原则有很大的帮助。 企业级GIS应用程序支持整个企业范围内的多种用户,他们都需要能够访问共享的空间和属性数据。分布式GIS应用程序的系统软件和硬件环境由多级的客户/服务器结构所支持。图4-1是这种结构的概览。 图4-1 GIS多级结构 中央数据服务器 共享的空间和表格数据库管理系统为共享的地理数据提供了集中式的数据仓库。这些数据库管理系统可以分布在分散的数据服务器上,或者同一个中央服务器平台。 应用程序计算服务器 GIS应用程序通过执行GIS功能的分布式配置的硬件平台来运行。在一个集中式的解决方案中,应用程序可以在UNIX或者Microsoft Windows平台为GIS客户提供主机计算服务。这些平台包括终端服务器和网络事务服务器(Web transaction server, 地图服务器)。在小型的配置中,应用程序计算服务器和中央数据服务器可以在同一平台下。 桌面工作站 应用程序过程的显示和控制是在桌面工作站进行的,一般是运行X-emulation软件的PC,Windows 终端客户,或者网络浏览客户。在许多GIS解决方案中,客户端应用程序服务器和用户的桌面工作站可以为同一平台。 ESRI白皮书 4 GIS产品结构 系统设计策略 4.1 ArcGIS系统软件结构 ArcGIS是一个集合名词,代表了综合的ESRI GIS技术。这项技术包括了ArcGIS桌面应用程序和ArcGIS基于服务器服务的混合体。图4-2提供了一个ArcGIS系统环境的概览。 图4-2 ESRI GIS软件 4.2 ArcGIS桌面软件结构 ArcGIS桌面应用软件包括ArcInfo、ArcEditor和ArcView的许可项目(licensing option)。这些应用软件都由使用COM编程技术开发的ArcObjects所支持。Microsoft Windows操作系统支持ArcGIS桌面软件。ArcGIS桌面技术呈现了一个面向对象的用户友好的界面和多种的GIS功能集合。图4-3提供了一个ArcGIS桌面软件的概览。 图4-3 ArcGIS桌面软件 ESRI白皮书 4 GIS产品结构 系统设计策略 ArcGIS 9的发布还包括了两个新的ArcObjects开发环境(ArcEngine和ArcGIS Server)。ArcEngine支持轻量级的定制桌面应用程序,而ArcGIS Server支持定制的网络地理处理服务的开发。一套完整的ArcObjects在每个开发环境中将完全呈现。 图4-4提供了一个ESRI商业GIS软件的概览。他们包括GIS应用软件(UNIX和Windows)、数据管理解决方案(GIS文件服务器、ArcStorm和ArcSDE)和远程访问客户解决方案(Windows Terminals和浏览器)。 图4-4 ESRI软件环境 ESRI商业软件性能和相关的系统接口规范为系统设计提供了一个基准。定制的GIS应用程序方案需要系统资源来支持基本的商业软件功能。 GIS应用软件是由一个开放的系统结构所支持。这种结构联合了多种紧密集成的商业产品来建立一个完全的系统解决方案。商业软件支持不断发展的通讯接口标准,使系统集成的专用定制化达到最小。但是不要过分强调选择成熟软件方案的重要性,因为分布式配置的所有部分对于支持整个系统性能来说都是十分关键的。 ESRI白皮书 4 GIS产品结构 系统设计策略 4.3 GIS for UNIX 图4-5表现了支持UNIX下的分布式ArcInfo的主要组件。 图4-5 UNIX下的GIS产品结构(UNIX文件服务器空间数据源) GIS应用程序功能是在UNIX工作站操作系统环境下之行的。基于文件的空间数据管理解决方案(包括空间coverages,shapefiles和ArcInfo LIBRARIAN)可以由客户工作站完全支持。DBMS软件在由属性数据服务器提供的系统环境中运行。由UNIX操作系统提供的网络文件服务器(NFS)将文件放置在到客户工作站的空间数据服务器上,使他们就像本地硬盘一样。对于GIS应用程序来说,放置在GIS数据服务器上的空间数据就如同本地数据。 一个数据库集成模块被包括在ArcInfo和ArcView GIS中,它可以从GIS应用程序转化信息到位于客户工作站上的DBMS客户模块。DBMS客户和服务器组件在客户工作站和DBMS数据服务器之间使用合适的网络通讯协议来处理网络通讯。ArcInfo AML或者其他标准编程工具,比如Visual Basic, Delphi, PowerBuilder, C, C++, Tcl/Tk, 和 Motif等都能被用来建立一个ArcInfo应用程序环境的定制用户界面。Avenue宏语言则支持定制的ArcView应用程序环境。 由于使用支持NFS、面向连接的通讯协议,在GIS工作站应用程序和位于单独的文件服务器上的空间数据之间的通讯需要一个很可观的网络流量开支。在客户工作站的内存中运行的单线程的应用程序过程执行程序时需要调用中央数据库。代码中的每一行必须通过网络连收到回应,下一行才能被执行。所以定位每一个所需数据的来源必须有多次传输。这种通讯模式造成了大量额外的网络负担。 GIS工作站应用程序和远程属性数据的通讯则不需要多少网络流量。向中央属性DBMS发出的查询被打包在一个客户请求里,并作为一个消息发送到服务器去处理。这个请求被一个单独的服务器过程处理,针对查询编辑答案并送回到客户应用程序做后续处理。它比访问空间数据高效的原因有两个,一个是使用面向消息的通讯协议(由一个本地服务器过程来进行数据处理);另一个是表格数据文件的容量要远小于空间图形文件。 ESRI白皮书 4 GIS产品结构 系统设计策略 所有原来ArcInfo Workstation 软件中的ArcInfo功能都已经被重新编写并配置在ArcGIS桌面软件中。这个现代化软件利用了面向对象技术来加速软件的发展和提高GIS软件的功能。与原来的ArcInfo Workstation 软件相比,ArcGIS桌面环境提供了更加友好的用户界面和更强大的GIS功能。 4.4 GIS for Windows 1996年,ESRI将ArcInfo UNIX Workstation应用程序移植到Windows平台上,使ESRI能够利用Microsoft Windows环境和成本低廉的PC机。ArcView GIS也可以安装在Windows工作站上。图4-6表明了支持Windows下分布式GIS解决方案的关键组件。 图4-6 Windows下的GIS产品结构(文件服务器空间数据源) GIS应用程序能够在Windows平台的操作系统环境中运行。包括在Windows操作系统中的微软公共网络文件服务(CIFS)协议支持PC客户对服务器硬盘资源的共享。远程数据服务器对于客户的Windows工作站就像本地硬盘一样,并且GIS应用程序可以访问由客户工作站提供的空间数据。GIS的Windows应用程序都被开发为一个开放的数据库连接标准(ODBC-compliant)的通信接口。ODBC接口提供了访问基于PC的属性数据资源的途径,包括Microsoft SQL Server 和 Microsoft Access。为了建立GIS应用程序和每个特定的属性数据库之间的接口,必须要有一个ODBC驱动。在UNIX环境下开发的AML可以继续在Workstation ArcInfo for Windows中使用。支持ArcView GIS的UNIX应用程序的Avenue脚本语言也支持ArcView GIS for Windows。软件也可用于支持UNIX系统调用Windows命令的转换,并且还需要支持一些定制代码。ArcGIS桌面用户使用一个OLE-DB接口连接到DBMS客户。 GIS应用程序和在单独数据服务器上的空间数据之间的通讯(使用CIFS协议)所需的网络通信开支与UNIX NFS通讯相仿。根据数据存储技术,访问远程数据资源所花费的时间要两倍于访问同样的数据在本地硬盘上。 ESRI白皮书 4 GIS产品结构 系统设计策略 最初,Windows数据服务器支持部门级的工作组。具备支持企业级GIS运行能力的服务器配置还不可行。而PC供应商(和Intel一起)在满足企业服务器需求方面做出了长足的进步。Windows的多处理器服务器能够配置多达8个处理器。微软为Windows操作系统则为了满足服务器故障转移(failover)需求而提供了一系列的故障转移解决方案。 许多方案都支持Windows和UNIX混合的环境。软件产品有能力使UNIX平台向PC客户直接共享硬盘。Novell和Windows服务器的网关产品可以支持UNIX服务器硬盘到PC工作组的映射。PC客户的NFS产品则支持UNIX服务器硬盘的放置。在所有这些方案中,服务器硬盘都可以映射到客户工作站,并允许ArcInfo访问远程服务器数据,就像它在本地PC上一样。 4.5 Microsoft Windows Terminal Server 微软的Windows Terminal Server产品建立了在一个Windows Server上的多主机环境。Windows Terminal客户可以显示和控制运行在Windows Terminal Server 上的应用程序。微软使用标准远程桌面协议(RDP)来支持Terminal Server和客户Windows平台之间的通讯。 Citrix推出了一个Metaframe扩展模块产品,它为支持Terminal Server和客户Windows平台之间的通讯提供了一个更加有效的独立计算结构(ICA)通讯协议。ICA协议只需不到28Kbps的带宽来支持一个Windows Terminal Server上GIS应用程序的显示和控制。Metaframe产品也包括UNIX、Macintosh下的客户软件和嵌入式的网络客户应用软件。 图4-7提供了一个Windows Terminal Server通讯结构的概览。 图4-7 Windows Terminal Server产品结构 ESRI白皮书 4 GIS产品结构 系统设计策略 Windows Terminal 客户和Windows Terminal Server之间的通讯是通过一个压缩的面向消息的通讯协议来进行的。Windows环境显示必须通过网络传递给客户工作站。这要比在Temnial Server或者一个工作站客户进行空间数据处理所需的数据量要小得多。终端显示的流量需求非常的小,通过28Kbps的拨号连接可以支持完全的服务器应用程序性能(如果有图像背景的显示则需要多一点的带宽)。 4.6 空间数据库引擎(ArcSDE) 空间数据库引擎支持标准商业DBMS应用软件中的空间数据存储。GIS空间数据与企业级DBMS环境的集成为支持众多用户的大型数据存储提供了一个强大的企业级数据存储解决方案。它提供了多种数据处理与管理工具和相关的DBMS解决方案。图4-8显示了与ArcSDE通讯结构相关的关键组件。 图4-8 ArcSDE数据服务器产品结构 ESRI白皮书 4 GIS产品结构 系统设计策略 ArcSDE解决方案将空间和属性数据集成到一个单一的GIS数据库,其查询过程由ArcSDE DBMS服务器所支持。一个事务请求在GIS应用程序客户端进行准备,并发送到ArcSDE服务器进行处理。然后ArcSDE处理完这个事务请求并反馈到客户端做后续处理。在这种配置中,对于映射数据服务器硬盘到GIS客户端没有特别的要求。在ArcSDE数据服务器上的应用程序处理所有的来自GIS客户应用程序的空间和属性数据请求。 ArcInfo, ArcView GIS, MapObjects, ArcEngine, ArcIMS 和 ArcGIS Server应用程序都包括ArcSDE client API,它支持直接访问中央ArcSDE服务器数据。ArcSDE和ArcInfo都支持ArcInfo coverage向ArcSDE layer的直接转换。一个额外的ArcSDE CAD client API则支持MicroStation和ArcSDE中的AutoCAD的存储。 ArcSDE 8支持传统的地理关系型数据库和新的Geodatabase关系型数据模型。这一版本引入了一个版本化数据库的概念,并且支持用版本化的数据库形式进行桌面ArcInfo8平台的本地数据维护操作。 标准的DBMS客户/服务器通讯可用于ArcSDE,但是对于ArcSDE的查询并非必需。使用的时候,他们能够提供从DBMS客户通讯接口访问属性数据的标准接口。 ArcGIS 8.1的发布包括专为Microsoft SQL2000和Oracle数据库方案开发的一个直接连接ArcSDE的客户接口选项。ArcSDE Direct option for Oracle将连接Oracle网络客户。Oracle网络客户将传送ArcSDE询问请求到服务器。ArcSDE Direct option for SQL2000将支持到服务器的直接通讯。其询问过程则由服务器平台上的DBMS功能支持。如果要更新现有的ArcSDE客户应用程序,可以从网上下载ArcSDE Direct Connect API。直接连接和ArcSDE连接的客户都可由同样的goedatabase环境所支持。 4.7 Arc网络地图服务(ArcIMS) Arc网络地图服务(ArcIMS)引进了一种通过网络进行地图产品服务的新途径。ArcIMS有一个基于Java的应用程序管理环境,包括制图服务和地图设计工具,可以支持多种的网络地图服务。图4-9说明了与ArcIMS通讯结构相关的关键组件。 ESRI白皮书 4 GIS产品结构 系统设计策略 图4-9 ArcIMS网络服务产品结构 ArcIMS包括一个Java Web servlet,它支持网络地图发布服务。这一标准产品包括一个ArcIMS管理器和地图开发软件包,可以支持绝大多数地图产品的设计和创作,无需专门进行编程开发。ArcIMS还包括一个Java客户端,它支持标准的网络产品,数据流动和数据下载。这个Java客户端也支持本地矢量数据和从网上得到的地图图像集成。此外,ArcIMS网络服务也可以被看作是ArcGIS桌面客户的一个数据源。 地图服务器平台支持主要的ArcIMS网络服务。制图服务可以由ArcIMS管理器的设计和创作工具通过在管理地图服务和性能的应用程序服务器上生成模板而开发。额外的编程工具(Cold Fusion [CF] 和 Active Server Pages [ASP])可以用于网络服务器,以增强HTML客户的功能。 图4-10提供了一个ArcIMS 4组件结构的概览。 图4-10 ArcIMS4 结构 ESRI白皮书 4 GIS产品结构 系统设计策略 4.7.1 ArcIMS平台配置选择方案 配置一个ArcIMS站点有多种途径。图4-11提供了一个ArcIMS组件及其位置的概览。 图4-11 ArcIMS组件结构 ESRI白皮书 4 GIS产品结构 系统设计策略 ArcIMS组件的位置及其配置能够直接影响站点的性能、可靠性和整体表现。ArcIMS组件可以被分为以下几类。 Web Server和Connector(WS) Web Server组件支持ArcIMS地图服务和网络客户应用程序之间的通讯。在Web Server上的Connector将网络HTTP流量转换为ArcIMS网络服务可以理解的表现形式。支持这个服务器只需要很少的处理过程。 ArcIMS应用程序服务器(AS) ArcIMS应用程序服务器组件提供了一个应用程序层,它支持内向(Inbound)地图服务请求序列(虚拟服务器)和通向ArcIMS公共服务引擎(Image, ArcMap,Feature,Extract)的已注册连接。内向请求被发送到可用的服务场合进行处理。支持应用程序服务器功能大约所需10%的ArcIMS处理负载。 空间服务器(SS) ArcIMS空间服务器包括为地图请求服务的各种服务器引擎(Image,Feature, Extract, Query, ArcMap Image, Geocode, and Route)。它也包括一个元数据搜索引擎。空间服务器脚本(引擎)代表了绝大多数的ArcIMS处理过程需求。在ArcIMS文档中,ArcIMS monitor是表达空间服务器的另一名词。 数据服务器(DS) 数据服务器(GIS数据源)是GIS数据存储的地点。一个ArcSDE数据源支持着占大约20%典型的网络服务工作量的查询处理功能。标准的GIS图像或文件数据源是这一级别的代表。 ESRI白皮书 4 GIS产品结构 系统设计策略 根据站点的需求,一个小型的ArcIMS站点可以被配置少到一个平台,多到六个平台。选择方案可以分为单级、二级和三级平台配置。简单的配置易于维护和支持。复杂的配置则支持高性能和更好的适用性。 4.7.1.1 单级平台配置 图4-12对一些示范性的单级平台配置进行了概括。单级配置提供了一个或两个平台,用来支持所有的ArcIMS组件。单级结构支持绝大多数的初始配置。 图4-12 单级平台配置 标准配置 一个完整的ArcIMS站点可以配置在一个单独的硬件平台之上。这种配置比较适合于地图服务的开发,具有有限服务请求的站点和初始的原型部署。 高适用性的配置 绝大多数ArcIMS的生产运行都需要多余的服务器配置方案,以便在单一平台发生故障时候站点仍然可以继续运行。在单一平台进行维护和更新时期,这种配置将继续支持生产性运行。这种配置包括:(1)在正常运行时期,传送到每个服务器的网络载荷保持平衡;当有的服务器发生故障时,只向正常工作的服务器发送信息。(2)在两个平台之间,分布在空间服务器的ArcIMS载荷量保持平衡,避免在其他服务器上的额外处理资源可用时将请求备份在一个服务器上。对于这种配置每个平台需要有两台空间服务器。(3)每个服务器需要一个完整的数据备份。 4.7.1.2 两级平台配置 支持两级平台结构有多种不同的选择。两级选项支持在两层物理平台环境中不同的ArcIMS组件。 图4-13中的两级结构包括了ArcIMS和数据服务器平台。网络服务器和ArcIMS组件定位在ArcIMS平台上,而数据服务器被定位在一个单独的数据服务器平台上。对于拥有海量数据资源或者现有的数据服务器,这是一个很流行的初始配置。一个单独的数据备份可以支持多个与其他企业GIS数据客户相连的服务器组件。 ESRI白皮书 4 GIS产品结构 系统设计策略 图4-13 两级平台配置(分开的数据服务器) 标准配置 标准配置包括一个分开的单独数据服务平台和一个或者多个ArcIMS服务器。网络服务器安装在ArcIMS服务器中。ArcIMS服务器层可以是一个平台,也可以扩展到支持两个平台,根据对网站性能需求而定。ArcIMS负载平衡是由应用程序服务器提供的。 高适用性的配置 高适用性的运行需要多余的服务器配置方案,以便在单一平台发生故障时候站点仍然可以继续运行。这种配置包括:(1)在正常运行时期,传送到每个网络服务器的网络载荷保持平衡;当有的服务器发生故障时,只向正常工作的服务器发送信息。(2)在两个ArcIMS服务器平台之间,分布在空间服务器的ArcIMS载荷量保持平衡,避免在其他服务器上的额外处理资源可用时将请求备份在一个服务器上。对于这种配置每个平台需要有两台空间服务器。(3)两个数据服务器必须被串联并且连接到一个公共的数据资源存储阵列。在正常运行时主服务器支持查询服务,当它发生故障时,第二服务器接管查询服务。 图4-14中的两级结构包括了网络服务器和地图服务器平台。网络和应用程序服务器组件位于网络服务器平台上,空间和数据服务器位于地图服务器平台上。为了支持这种配置,每台地图服务器必须提供单独的数据备份。这种配置只适用于小型数据资源的情况。 图4-14 两级平台配置(分开的地图服务器) ESRI白皮书 4 GIS产品结构 系统设计策略 标准配置 标准配置包括一个单独的网络服务器和一个单独的地图服务器。地图服务器层可以是一个单独的平台,也可以被扩展为支持几个平台,根据对网站性能需求而定。ArcIMS负载平衡是由ArcIMS应用程序服务器提供的。 高适用性的配置 高适用性的运行需要多余的服务器配置方案,以便在单一平台发生故障时候站点仍然可以继续运行。这种配置包括:(1)在正常运行时期,传送到每个网络服务器的网络载荷保持平衡;当有的服务器发生故障时,只向正常工作的服务器发送信息。(2)在两个地图服务器平台之间,分布在空间服务器的ArcIMS载荷量保持平衡,避免在其他服务器上的额外处理资源可用时将请求备份在一个服务器上。对于这种配置每个地图服务器平台需要有两台空间服务器。(3)每个地图服务器需要一个完整的数据备份。 图4-15中的两级结构包括了网络服务器和地图服务器平台。网络服务器和ArcIMS Connector位于网络服务器平台上,ArcIMS应用程序、空间和数据服务器则位于地图服务器平台上。为了支持这种配置,每台地图服务器必须提供单独的数据备份。这种配置只适用于小型数据资源的情况。 图4-15 两级平台配置(分开的网络服务器) ESRI白皮书 4 GIS产品结构 系统设计策略 标准配置 标准配置包括一个单独的网络服务器和一个单独的地图服务器层。地图服务器层可以是一个单独的平台,也可以被扩展为支持几个平台,根据对网站性能需求而定。网络流量平衡是由ArcIMS Connector提供的。ArcIMS负载平衡是由ArcIMS应用程序服务器提供的。多个空间服务器必须被配置在地图服务器上,来支持多平台的负载平衡。随着更多地图服务器部署,这种结构的管理也变得日益复杂。 高适用性的配置 高适用性的运行需要多余的服务器配置方案,以便在单一平台发生故障时候站点仍然可以继续运行。这种配置包括:(1)在正常运行时期,传送到每个网络服务器的网络载荷保持平衡;当有的服务器发生故障时,只向正常工作的服务器发送信息。(2)在两个地图服务器平台之间,分布在空间服务器的ArcIMS载荷量保持平衡,避免在其他服务器上的额外处理资源可用时将请求备份在一个服务器上。对于这种配置每个地图服务器平台需要有两台空间服务器。(3)每个地图服务器需要一个完整的数据备份。随着更多地图服务器部署,这种结构的管理也变得日益复杂。 4.7.1.3 三级平台配置 图4-12提供了一些示范性三级平台配置的概览。三级配置包括了与网络服务器上的应用程序服务器相连接的一个网络服务器、一个地图服务器和一个数据服务器。 图4-15 三级平台配置 ESRI白皮书 4 GIS产品结构 系统设计策略 标准配置 标准的三级配置包括一个单独的网络服务器和一个单独的地图服务器和数据服务器层。地图服务器层可以是一个单独的平台,也可以被扩展为支持几个平台,根据对网站性能需求而定。ArcIMS负载平衡是由应用程序服务器提供的。所有的地图服务器都使用共同的数据资源。 高适用性的配置 这种配置包括两个网络服务器、两个地图服务器和两个数据服务器。这种配置包括:(1)在正常运行时期,传送到每个网络服务器的网络载荷保持平衡;当有的服务器发生故障时,只向正常工作的服务器发送信息。(2)在两个地图服务器平台之间,分布在空间服务器的ArcIMS载荷量保持平衡,避免在其他服务器上的额外处理资源可用时将请求备份在一个服务器上。对于这种配置每个地图服务器平台需要有两台空间服务器。(3)两个数据服务器必须被串联并且连接到一个公共的数据资源存储阵列。在正常运行时主服务器支持查询服务,当它发生故障时,第二服务器接管查询服务。 4.7.2 ArcIMS防火墙配置选择方案 ESRI的白皮书《安全与ArcIMS》阐述了安全的ArcIMS环境的配置选项。白皮书可以通过ESRI的网站URL:http://www.esri.com/library/whitepapers/pdfs/SecurityArcIMS.pdf获得。防火墙的配置可支持不同等级的安全需要。许多安全选项可以基于ArcIMS软件的组件位置而确定。 所有ArcIMS组件在DMZ中 最安全的方案是进行从ArcIMS软件组件到安全网络物理上的隔离。图4-17表示了在DMZ中的安全网络防火墙。这种配置需要对GIS数据备份的维护。数据需从内部的GIS数据服务器复制到外部的GIS数据服务器来支持ArcIMS服务。 图4-17 所有ArcIMS组件在DMZ中 ESRI白皮书 4 GIS产品结构 系统设计策略 所有ArcIMS组件在DMZ中(除了数据服务器) 图4-18表示了位于DMZ里的网络服务器、应用程序服务器和空间服务器,访问位于安全网络的内部ArcSDE数据服务器。通过安全防火墙的5151端口允许对ArcSDE DBMS数据服务器进行有限访问。ArcIMS服务和DBMS的安全性由此而得到保障。防火墙阻止来自其他资源的信息访问内部的安全网络。 图4-18 所有ArcIMS组件在DMZ中(除了数据服务器) ESRI白皮书 4 GIS产品结构 系统设计策略 网络服务器在DMZ里,ArcIMS的其他组件在安全网络 图4-19表示了网络服务器在DMZ中,而地图服务器和数据服务器位于安全网络。这种配置要想被接受,应用程序服务器和空间服务器必须位于内部网络里。位于网络服务器上的输出文件必须与地图服务器共享。硬盘的配备将支持从地图服务器通过防火墙到网络服务器的单向访问。 图4-19网络服务器在DMZ里,ArcIMS的其他组件在安全网络 网络服务器和应用程序服务器在DMZ里,ArcIMS的其他组件在安全网络 图4-20表示了网络服务器和应用程序服务器在DMZ中,而地图服务器和数据服务器位于安全网络。位于网络服务器上的输出文件必须与地图服务器共享。硬盘的配备将支持从地图服务器通过防火墙到网络服务器的单向访问。 ESRI白皮书 4 GIS产品结构 系统设计策略 图4-20 网络服务器和应用程序服务器在DMZ里,ArcIMS的其他组件在安全网络 多网络服务器配置 图4-21表示了一个多网络服务器的方案,为Intranet和Internet分别提供了接口安全保障。这种混合型方案在支持单独的用户访问安全性要求的同时,共享使用一个中央地图服务器计算环境。分离的地图服务能够被部署在两个网络服务器上,在同一站点为不同的用户群提供安全的访问接口。 图4-21多网络服务器配置 ESRI白皮书 4 GIS产品结构 系统设计策略 代理服务器支持下的网络服务 图4-22表示了在一个代理服务器支持下的内部网络服务器接口。这项方案通过一个代理服务器提供了私有网络安全保障,并且支持私有网络上完全的网络配置。这种配置使私有网络具有完全的网络管理能力。 图4-22代理服务器支持下的网络服务 ESRI白皮书 4 GIS产品结构 系统设计策略 所有的ArcIMS组件都在安全网络上 图4-23表示了网络服务器、地图服务器和数据服务器组件都在安全网络的防火墙里面。80端口必须开放,以便HTTP的信息通过防火墙。许多机构不太适应这种等级的安全保障。 图4-23所有的ArcIMS组件都在安全网络上 ESRI白皮书 4 GIS产品结构 系统设计策略 4.8 ArcGIS Server ArcGIS Server(AGS)提供了一个基于完全ArcObjects GIS技术的标准组件式服务器部署。AGS技术是随着ArcGIS9的发布而实施的,支持基于Web和network应用环境的完全网络服务。 4.8.1 ArcGIS Server结构 图4-24表现了与AGS通讯结构相关的关键组件。 图4-24 ArcGIS Server组件结构 ESRI白皮书 4 GIS产品结构 系统设计策略 ArcGIS Server组件包括Server Object Container(SOC),Server Object Manager和Application Developer Framework。这些软件组件与第三方的Web Application Server技术一起协同工作来支持网络客户。ArcGIS Server还包括一个ArcSDE Direct Connect (DC) 和 Application Server Connect (ASC),它们与ArcSDE数据库环境集成。 Network服务 ArcGIS Server能够为具有本地网络接口的GIS应用程序提供服务。SOM制定初始的SOC分配任务,随后SOC直接与本地应用程序接口进行通讯来完成整个事务。 Web服务 ArcGIS Server能够为具有Web服务器接口的GIS应用程序提供服务。这些服务使用标准的SOAP协议。初始服务可以通过一个Web服务器应用程序(ArcGIS Server软件中包括了Web Server Catalog Template)提供。SOM提供了Web服务器应用程序初始的SOC分配任务,随后SOC直接与Web服务器应用程序进行通讯来完成整个事务。 Web应用程序 ArcGIS Server能够为一个Web应用程序提供服务,来支持通过Web服务器接口进行的标准客户浏览器显示。Web应用程序可以使用标准的.NET或者J2EE编程环境在Web应用程序服务器中进行开发。 ArcSDE是ArcGIS Server的首选空间数据源。ArcSDE数据库通常由一个单独的硬件平台支持以获得最佳性能。 4.8.2 ArcGIS Server负载平衡 由ArcGIS Server支持的负载平衡有三种形式。负载平衡可以用来在SOM启动阶段建立SOC例程;当初始应用程序支持一个客户服务事务的时候连接到现有的SOC例程;和当并发的服务请求数目超过了所部署的服务配置例程的时候进行例程的创建。 ESRI白皮书 4 GIS产品结构 系统设计策略 ArcGIS Server SOM软件是根据系统管理员建立的“服务器配置”来进行SOC例程的管理。SOC例程被部署在支持AGS服务器对象代码执行的‘container machine’ (CM)上,已公布的服务器配置规定了其范围(最大、最小值)来满足预期的高峰服务事务请求。SOM维护着一个有序配置的container machine(指CM的context),用于负载平衡的算法。container machine的“context”序列与每个SOC例程分配任务循环交替。每个已公布的服务器配置都由专门的在SOM启动或者例程创建的时候生成的SOC例程来支持。 可执行的SOC是多线程的,其配置支持一个到四个并发的SOC例程。每个服务器配置都将规定是否SOC例程应该被部署为一个“高隔离”或者“低隔离”环境。“高隔离”环境支持每个可执行SOC的一个例程,而“低隔离”环境支持每个可执行SOC的四个例程。 SOM启动 初始ArcGIS Server配置是在SOM启动阶段建立的。SOM分配第一个SOC例程给内容列表上的第一个CM,下一个SOC例程就分配给下一个CM,如此操作直到被已公布服务器配置确定的最小值数目的SOM例程部署完毕。根据规定的每个服务器配置的例程最小值,一旦所有已公布服务器配置的SOC例程都部署完毕,SOM启动也完成了。 图4-25提供了最终的ArcGIS Server启动配置,它是基于三个已公布的服务器配置,每个都规定了不同的最小值例程范围。 图4-25 ArcGIS服务器启动 SOM例程分配 例程分配负载平衡是由初始应用程序连接阶段的SOM来执行的。SOM根据当前的CM内容,将每个内向服务请求分配给第一个可用的服务器配置SOC例程。如果一个被要求的服务器配置例程在当前内容中第一个CM上不可用,则分配任务移到下一个CM,直到发现可用的例程。内容随着每个例程分配而在一个CM中交替。图4-26提供了一个例程分配负载平衡的例子。 ESRI白皮书 4 GIS产品结构 系统设计策略 图4-26 ArcGIS Server例程分配负载平衡 所有被创建的例程都与创建它们的SOM具有相同的时间有效性。 SOM例程创建 当并发服务连接数目超过为原先部署的SOC例程数目的时候,SOM就执行例程创建负载平衡的功能。在CM现有的SOM例程数目基础上,SOM为被请求的服务器配置额外部署了一个SOC例程。如果同样数目的例程已经分配给了每个CM,则SOM将根据当前的CM内容部署SOM例程。SOM被创建的数目可以达到服务器配置例程数目的最大值。超过最大例程范围的并发服务请求将被SOM滞留在一个服务队列中,等待下一个可用的例程。被创建的例程都与创建它们的SOM具有相同的时间有效性,并且如果SOM连接失去,它们就会终止。内容随着每个例程的创建或分配而在一个CM中交替。图4-27提供了一个例程创建负载平衡的例子。 图4-27 ArcGIS Server例程创建负载平衡 ESRI白皮书 4 GIS产品结构 系统设计策略 ArcGIS Server支持所有的合用(pooled)和非合用(non-pooled)的用户访问量(user session)。合用的用户访问量由已部署的SOC例程支持,并且所有的状态变化都在应用程序层次得到维护。 非合用的用户访问量由专门的SOC例程支持,并且对于所有在被分配的SOC例程里产生状态变化的应用程序都有要求。例程创建负载平衡用于创建一个非合用的用户访问量。一旦用户访问量关闭,这个非合用的SOC例程也就随之结束。 4.8.2.1 ArcGIS Server单级平台配置 图4-28提供了一些单级平台配置的例子。单级配置提供了一个或两个平台来支持所有的ArcGIS Server组件。绝大多数原型部署可以由一个单级结构支持。 图4-28 ArcGIS Server单级平台配置 ESRI白皮书 4 GIS产品结构 系统设计策略 标准配置 一个完整的ArcGIS Server站点能够被配置在一个单独的硬件平台之上。这种配置比较适合于初始的ArcGIS Server应用程序开发,具有有限服务请求的站点和初始的原型部署。 高适用性的配置 绝大多数的ArcGIS Server生产运行都需要多余的服务器环境,以便在单一平台发生故障时候站点仍然可以继续运行。在单一平台进行维护和更新时期,这种配置将继续支持生产性运行。这种配置包括:(1)在正常运行时期,传送到每个服务器的网络载荷保持平衡;当有的服务器发生故障时,只向正常工作的服务器发送信息。(2)镜像的AGS SOM配置使分布在两个平台之间的处理负载保持平衡,并在其中一个服务器发生故障的情况下继续支持运行。(3)每个服务器需要一个完整的数据备份。 4.8.2.2 ArcGIS Server两级平台配置 图4-29中的两级结构包括了ArcGIS Server和数据服务器平台。Web应用程序服务器和AGS组件位于ArcGIS Server的Container machine上,数据服务器位于一个单独的数据服务器平台上。对于具有一个ArcSDE数据库或者现有数据服务器的中小型站点,这是最普遍的配置。一个单独的数据备份可以支持多个与其他企业GIS数据客户端相连的AGS container machine。 图4-29 ArcGIS Server两级平台配置(分开的数据服务器) ESRI白皮书 4 GIS产品结构 系统设计策略 标准配置 标准配置包括在一个单独的ArcSDE数据服务平台和一个或多个ArcGIS Server container machine。Web应用程序服务器安装在ArcGIS Server container machine中。ArcGIS Server层可以是一个container machine,也可以扩展到支持两个container machine,根据对网站性能需求而定。ArcGIS Server负载平衡是由一个镜像的AGS SOM配置提供的。 高适用性的配置 高适用性的运行需要多余的服务器配置方案,以便在单一平台发生故障时候站点仍然可以继续运行。这种配置包括:(1)在正常运行时期,传送到每个Web服务器的网络载荷保持平衡;当有的服务器发生故障时,只向正常工作的Web服务器发送信息。(2)镜像的AGS SOM配置使分布在两个container machine之间的处理负载保持平衡。(3)两个ArcSDE数据服务器在一个故障转移群集配置中被串联并且连接到一个公共的数据资源存储阵列。在正常运行时主服务器支持查询服务,当它发生故障时,第二服务器接管查询服务。 4.8.2.3 ArcGIS Server三级平台结构 图4-30提供了一个标准的三级ArcGIS Server配置。这个三级配置包括Web服务器、container machine和一个位于Web服务器的具有SOM的数据服务器层。 图4-30 三级平台标准配置 ESRI白皮书 4 GIS产品结构 系统设计策略 标准配置 标准的三级配置包括一个单独的Web服务器和一个单独的container machine和数据服务器层。container machine层可以是一个单独的平台,也可以被扩展为支持几个平台,根据对网站性能需求而定。ArcGIS Server负载平衡是由位于Web服务器的SOM提供的。所有的SOC例程都使用共同的数据资源。 图4-31提供了一个高适用性ArcGIS Server配置的概览。三级结构包括多个Web服务器、container machine和两个ArcSDE数据服务器。一个SOM镜像阵列由一个单独的串联层或者在ArcSDE数据服务器组提供支持。 图4-31 三级平台高适用性配置 ESRI白皮书 4 GIS产品结构 系统设计策略 高适用性的配置 高适用性的三级配置可以包括许多Web服务器、支持SOC例程的多个container machine和两个ArcSDE数据服务器。网络负载平衡用于发送内向通信到可用的Web服务器上;仿射性用于保持与初始Web服务器分配的用户连接。Web服务器必须配置为支持高峰的Web应用程序处理工作量。Web应用程序在初始站点配置阶段必须被分配到一个SOM。 高适用性还需要两种SOM配置,并且它们能建立在一个故障转移配置中。主SOM支持初始部署。在主服务器失灵的状态下,第二SOM将在故障转移群集阶段启动一系列新的SOC例程。SOM群集环境能够和ArcSDE数据库服务器群集由同一个平台支持。 ESRI白皮书 5. 数据管理 系统设计策略 5 数据管理 数据管理是开发企业级GIS结构的一个重要考虑因素。企业级GIS通常在机构GIS数据资源的整合工作中获益。支持数据整合有多种理由,包括可以改善用户访问数据资源的途径、提供更好的数据保护和提高数据的质量。对IT支持下的资源整合也可以减少硬件花费和整个系统的管理成本。 管理数据资源最简单和最能节省成本的途径就是在一个集中式数据仓库中保存一个数据的备份,并且提供通往这些数据的所需的接口,来支持数据维护和运行中的GIS查询和分析需求。但是这通常不可行,因为许多系统解决方案要求机构维护的是分布式数据备份。如果要求支持分布式数据构架,就必须要有很大的折衷余地。 本章对数据管理技术进行了概述。许多基本的数据管理任务将被明确,包括支持这些任务的当前技术发展水平。这些数据管理任务包括: n 保护空间数据的途径 n 备份空间数据的途径 n 转移空间数据的途径 n 访问空间数据的新途径 5.1 保护空间数据的途径 企业级GIS环境很大程度上要依靠GIS数据来支持多种的关键业务过程。数据是一个GIS中最有价值的资源之一,而保护数据也是支持关键业务运行的最重要的手段。 主要的数据保护手段是由存储方案所提供的。绝大多数的存储销售都为了数据保护而按照RAID(独立磁盘冗余阵列)存储方案进行了标准化。基本的存储保护选择方案包括以下几个: JBOD(Just a bunch of disks) 一个没有RAID保护的磁盘被称为JBOD配置,它代表了没有保护并且没有进行性能优化的磁盘配置方式。 RAID 0 在RAID 0配置方式下的磁盘卷提供在存储阵列中跨越几个磁盘的数据分段(stripping of data)。数据分段技术支持不同磁盘之间并行的磁盘控制器的数据存取,它大大减少了定位和传输请求数据的所需时间。一旦数据在一个磁盘上被发现,就被传送到阵列的高速缓存中。RAID 0的数据分段技术提供了最佳的数据存取性能,但是没有数据保护措施。100%的硬盘空间都可用于数据存储。 RAID 1 在RAID 1配置方式下的磁盘卷提供磁盘阵列里的磁盘对上的数据镜像备份。如果磁盘对中的一个发生故障,数据还可以从另外一个磁盘备份中存取,从而故障磁盘被替代。并且数据能够自动的从镜像备份中恢复,而不需要将存储阵列卸下维修。RAID 1提供了最小性能损失下的最佳数据保护措施。磁盘空间的使用率只有全部磁盘的一半,因为对于阵列中的每个数据磁盘,都有一个镜像备份。 RAID 3和4 在RAID 3或者RAID 4配置方式下的磁盘卷支持阵列中除一个校验磁盘(parity disk)外的所有磁盘间的数据分段。对于每个数据分段都进行奇偶校验计算,并将结果存储到校验磁盘中。 ESRI白皮书 5. 数据管理 系统设计策略 如果某一磁盘发生故障,换上新的磁盘后,整个磁盘阵列(包括奇偶校验磁盘)重新计算一次, 将故障磁盘的数据恢复并写入新磁盘中。RAID3提供了对数据的良好保护并且具有最佳的磁盘空间利用率,除了校验磁盘以外的所有磁盘都可以用于数据存储。 在RAID3和RAID4之间还存在一些技术上的差异,不过这已经超出了我们当前的讨论范围。所有这些存储配置方案都存在着潜在的性能缺陷。每次进行写操作都要访问公共校验磁盘,导致了高峰用户访问量时期的磁盘冲突。在写入时需要重新计算及修改奇偶校验磁盘的内容,性能也由此降低。在绝大多数的高性能磁盘存储解决方案中,写操作的性能问题通常是通过阵列高速缓存算法来解决的。 5.2 流行的RAID配置 下面的RAID配置普遍使用于ArcSDE存储解决方案。这些方案采取对RAID的联合使用来支持数据保护和性能优化。图5-1提供了一个最流行的合成RAID配置策略的概述。 图5-1 存储空间数据的途径(标准RAID配置) RAID 1/0 RAID 1/0是一个合成的解决方案,包括RAID0的数据分段和RAID1的数据镜像。这是追求高性能和数据保护的最佳方案,但是成本也最高。磁盘空间的使用率只有全部磁盘的一半,因为对于阵列中的每个数据磁盘,都有一个镜像备份。 RAID 5 RAID 5包括了数据分段和RAID3方案的奇偶校验,也包括了对阵列间的每个数据段的校验卷的分配以避免校验磁盘冲突的性能瓶颈。这一改进的奇偶校验方案提供了最佳的磁盘利用率和尚佳的性能,除了校验磁盘以外的所有磁盘都可以用于数据存储。 混合方案 一些厂家提供了专门的RAID策略来改进他们的存储方案。磁盘数据存储的新方法能够提高性能和保护,并且简化其他数据管理需求。每个混合方案应该被很好评估,来决定它是否和如何满足特定的数据存储需求。 ESRI白皮书 5. 数据管理 系统设计策略 5.3 备份空间数据的途径 磁盘的数据保护将有助于减少对单个磁盘失灵时系统恢复的需求,但是却无法对其他多种形式的数据失败情况进行保护。所以对关键数据资源在安全的地方进行备份就显得尤为重要。 数据备份通常是保护我们数据投资的最后一道防线。在一个成功的备份策略中,对存储备份程序的悉心规划和关注是很重要的因素。在多种情况下可以导致数据丢失,最可能的情形就是管理员或用户的失误。图5-2提供了对空间数据备份的不同方法的概述。 图5-2备份空间数据的途径 主机磁带备份 传统的服务器备份方案使用低成本的磁带作为备份的存储载体。数据必须被转换为磁带存储格式并且存储在一个线性磁带介质中。这种备份是一个漫长的过程,要占用相当多的服务器处理资源(通常在备份过程中要消耗CPU资源),并且需要运行环境下的特殊数据管理。 对于数据库环境,这些备份必须基于单个的“及时点”(point in time)来维持数据的连续性。数据库厂家通过建立一个数据库的过程快照(procedural snapshot)来支持在线备份需求。当对数据库进行变动时,一个受保护的快照数据的备份就被保留在一个快照表内,帮助进行数据库的“及时点”备份和可能需要的数据库恢复到快照的时间。 主机处理器可以被用于非高峰时间的备份操作。如果在高峰时期需要备份,就会影响服务器的性能。 ESRI白皮书 5. 数据管理 系统设计策略 网络客户端磁带备份 传统的在线备份是通过LAN支持,主要的批处理过程运行在一个单独的客户端平台上。DBMS快照仍然可以用于在线数据库环境下的“及时点”备份。由于客户端备份在备份过程中的高数据传输率,可能会导致服务器和客户机之间的性能瓶颈。 存储区域网(SAN)客户端磁带备份 一些备份方案支持直接的磁盘存储,无需影响主机DBMS服务器环境。存储备份通过SAN或者一个单独的访问磁盘阵列的光纤通道来进行,批处理过程运行在一个单独的客户端平台上。一个磁盘存储阵列快照被用于支持在线数据库环境下的“及时点”备份。使用磁盘级的备份方案可以避免主机平台处理工作量和LAN性能的瓶颈。 磁盘复制备份 近些年来,数据库的容量飞快的增长,数据量由10s of Gigabytes到100s of Gigabytes,在许多案例中甚至达到了Terabytes。从磁带备份恢复大型的数据库变得非常的缓慢,有时需要花费数天的时间。与此同时,硬盘的价格急速下降,与磁带存储方案相比,大型数据库环境的磁盘存储方案具备了价格上的竞争力。本地磁盘上的数据库备份,或者这些磁盘在一个远程恢复站点上的备份,可以支持一次存储失败后DBMS的即刻重启,只需要简单的使用备份磁盘重新启动DBMS即可。 5.4 转移空间数据的途径 许多企业级GIS解决方案需要对GIS数据资源的分布式备份进行连续维护,这些数据通常是从一个中央GIS数据仓库或者企业数据库环境中复制而来。只有一个单独的企业数据库方案的单位仍然有必要在一些紧急情况下保护数据资源,比如火灾、洪水、车祸或者其他自然灾害等。许多机构近年来已经考察了他们的业务实践,并且更新了他们的计划来支持在数据资源重大损失的情况下继续开展业务。2001年的911事件表明了这些计划的价值所在,并激起了对这种保护需求的觉醒和兴趣。 本节探讨了机构转移空间数据的不同途径。传统的方法将数据拷贝到磁带或者磁盘,再通过标准的物理运输模式将这些数据运送到远程地点。数据一旦到达,就被重新安装在远程的服务器上。近年来,技术的发展带来了维护分布式数据资源的更加有效的方案。理解这些可行的方案和数据转移中的风险在设计一个最佳的企业GIS结构中将十分重要。 5.4.1 传统的数据传输方法 图5-3阐述了转移数据备份到远程地点的传统方法。 图5-3 移动空间数据的途径(传统的磁带备份/磁盘复制) ESRI白皮书 5. 数据管理 系统设计策略 传统的方法包括使用标准的磁带或者磁盘传输媒介进行数据的备份和恢复。使用这些类型的程序转移数据通常被称为“sneaker net”,它提供了一种途径使传输数据无需物理网络的支持。 磁带备份 磁带备份方案能够被用于转移数据到一个单独的服务器环境。磁带传输通常非常的缓慢。磁盘存储不断下降的成本已经使磁盘复制成为一种更加明智的选择。 磁盘复制 在磁盘上进行数据库的复制可以支持在其他地方快速的恢复数据。数据库能够在非常短暂的时间内使用新的数据备份重新启动和上网。 5.4.2 ArcGIS数据库转移 移动一个数据库的子集通常不能被标准的备份策略所支持。数据必须从主数据库中提取出来,再导入到远程数据库来支持数据的传输。数据库的转移能够通过标准的ArcGIS输入/输出功能来进行。这些工具可以被用作建立和维护在其他地方的数据库备份的方法。图5-4表述了使用ArcGIS数据转移功能进行空间数据转移的方法。 图5-4 移动空间数据的途径(数据库转移) ESRI白皮书 5. 数据管理 系统设计策略 ArcSDE Admin 命令 批处理过程可以使用ArcSDE Admin命令来支持一个ArcSDE数据库的输出和输入。当需要完全的替换数据层的时候,使用这些命令移动数据是最可行的。但是当转移数据到一个复杂的ArcSDE geodatabase环境的时候,这些命令就不是最佳方案了。 ArcCatalog/ArcToolbox命令 ArcCatalog支持ArcSDE geodatabase环境之间的数据转移,包括提取数据到personal geodatabase和从personal geodatabase导入数据到ArcSDE环境。 5.4.3 数据库复制 用户在配置DBMS空间数据复制方案的时候可能已经遇到了多种技术上的挑战。为了支持DBMS复制方案,ArcSDE数据模型可能需要稍加改动。编辑负载(Edit loads)将被应用到所有的服务器环境,可能会对服务器性能或者空间造成潜在的影响。数据的改变必须通过两台服务器之间的网络进行传输,造成潜在的通讯瓶颈。实施一个成功的DBMS复制方案,这些困难必须被克服。 用户们已经反映,DBMS复制方案可以实行,但是需要相当的耐心和执行上的风险。一些DBMS厂家可接受的方案包括对一个只读的备份数据库服务器的复制。而双主板的服务器配置策略给本来已经很复杂的复制方案又增加了许多复杂性。图5-5表述了使用数据库复制转移空间数据的不同途径。 图5-5 移动空间数据的途径(数据库复制) ESRI白皮书 5. 数据管理 系统设计策略 同步复制 实时的复制需要在主服务器上的客户应用程序发布之前就进行数据向被复制服务器传输的行为。在这种配置下的编辑操作将导致性能上的延迟,因为空间数据的传输量很繁重,并且需要与客户端互动的时间。推荐在主服务器和被复制的备份服务器之间使用高带宽的光纤连接(1000Mbps带宽),以减少性能的延迟。 异步复制 准实时的数据库复制策略在数据传输到第二服务器的时候分离了主服务器,异步复制可通过WAN支持,因为缓慢的传输时间已经和主服务器的性能无关。如果WAN的带宽受到限制,数据的传输(更新)可以被延迟到非高峰时段。这样就可以以一个满足运行需求的速率进行第二服务器环境的周期性更新。 5.4.4 磁盘级复制(异步) 磁盘级复制是一个已经很成熟的技术,它为许多类型的行业解决方案的关键数据提供了全球范围的复制。空间数据存储在磁盘扇区上,与其它的数据存储非常相似,无需特别的关注。磁盘卷的配置(磁盘上的数据位置和哪些卷被传送到远程站点)对于保证数据库的完整性非常关键。基于存储设备厂家提供的“及时点”快照功能,镜像备份可以被很快的更新。 磁盘级复制提供了磁盘的块级(block-level)变化的数据到远程站点的镜像磁盘卷的传输。这种传输可以由活跃的在线处理支持,对DBMS服务器性能的影响很小。第二DBMS应用程序必须重新启动来将DBMS高速缓存和处理环境更新到被复制磁盘卷的“及时点”。 图5-6表述了使用磁盘级复制转移空间数据的不同途径。 图5-5 移动空间数据的途径(磁盘级复制) ESRI白皮书 5. 数据管理 系统设计策略 同步复制 实时的复制需要在主服务器上的DBMS应用程序发布之前就进行数据向被复制存储阵列传输的行为。推荐在主服务器和被复制的备份服务器之间使用高带宽的光纤连接(1000Mbps带宽),以减少性能的延迟。 异步复制 准实时的磁盘级复制策略在事务变动传输到第二存储阵列的时候分离了主服务器,异步复制可通过WAN支持,因为缓慢的传输时间已经和主DBMS服务器的性能无关。如果WAN的带宽受到限制,磁盘块的变动可以被存储,并且数据的传输可以被延迟到非高峰时段。这样就可以支持第二磁盘存储卷的周期性更新来满足运行需求。 5.4.5 访问空间数据的新途径 ArcGIS8.3的发布支持离线编辑方案。这一方案支持一个已注册的geodatabase版本分离到一个personal geodatabase或者单独的数据库,来进行离线编辑工作。版本的添加或者删除可以由离线编辑器收集,重新连接到母服务器上,并且能够作为一个版本更新上载到中央ArcSDE数据库。 图5-7表述了ArcGIS8.3的离线编辑和登出(check-out)到一个personal geodatabase。ArcGIS8.3限定了在每个客户编辑时间只能进行一个登出/登入(check-out/check-in)事务。 图5-7 ArcGIS8.3离线编辑personal geodatabase ESRI白皮书 5. 数据管理 系统设计策略 图5-8描述了ArcGIS8.3的离线编辑和分离到一个ArcSDE geodatabase。ArcGIS8.3限定了在每个子ArcSDE数据库只能进行一个check-out/check-in业务。子ArcSDE数据库在check-out阶段能够支持多个离线的或者本地版本的编辑。所有的子版本都必须在和母ArcSDE数据库check-in之前被整合(因为所有突出的子板本在子ArcSDE数据库check-in过程中都将被丢失)。 图5-8 ArcGIS 8.3离线编辑--数据库Checkout ESRI白皮书 5. 数据管理 系统设计策略 ArcGIS的离线编辑功能将在ArcGIS 9中得到扩展,以便支持松散连接的ArcSDE分布式数据库环境。图5-9表达了未来松散连接的ArcSDE分布式数据库概念。 图5-9 未来的ArcSDE分布式数据库结构 ESRI白皮书 5. 数据管理 系统设计策略 计划包括分布在多个平台环境中的单一的ArcSDE geodatabase。母数据库的子check-out版本将能够支持无限量的更新事务,不会丢失本地版本编辑或者需要一个新的check-out。更新将在母与子数据库环境之间通过简单的数据报文(datagram)来进行,它可以通过标准的WAN通讯来传输。这个新的geodatabase结构将支持分布式的数据库环境,它是通过有限带宽多站点连接的(在站点之间只有调整过的变动被传输,以支持数据库的同步化)。 5.5 数据管理综述 传统上,支持分布式数据库的解决方案通常会引入高风险的操作,可能导致数据损伤和在GIS运行中使用过时的数据。但是也有很多单位成功的实施了分布式解决方案。他们的成功来自于对分布式数据站点管理过程精心的规划和关注。更加成功的方案则支持集中式整合的数据库解决方案,并具有有效的远程用户接口和支持。未来的分布式数据库管理方案极大的降低支持分布式环境的风险。无论是集中式还是分布式,企业级GIS解决方案的成功将很大程度上依靠于管理团队,他们保证系统的正常运行,并且为支持用户访问需求而提供一个框架解决方案。 ESRI白皮书 6. GIS用户需求 系统设计策略 6 GIS用户需求 为了满足GIS用户对硬件和网络的性能与通讯需求,系统结构设计提供了一种方法论。硬件需求应该建立在确定的业务需求之上,所以在确定合适的硬件和网络需求之前,必须对用户的工作流程和所支持的GIS技术有个基本的了解。 6.1 对GIS的思考 一个GIS的价值是在用户访问业务数据资源的时候体现的。建立和维护GIS数据资源需要一笔相当数量的资金投入。一旦数据可用,这项投资就相当于被用来支持业务运行了。当数据被用来生产提高业务运行质量的信息产品的时候,这项投资的回报也就实现了。 图6-1 地理信息系统 GIS是一项采集、存储、管理和分析空间数据的技术。空间数据在数据库中是以点、线、多边形、复杂特征和图像层等形式表现的。这些空间数据在数据库中是以标准关系行存储的。GIS应用程序支持多种形式的数据集成和分析,来产生所需的业务信息产品。GIS信息产品可以表现为地图、列表或者支持业务运行的用户工作流程。这些信息产品可以在计算机屏幕上显示、在纸上打印或者存储于数字媒介。通过为用户提供访问这些信息资源的途径,组织机构从GIS中获得的利益也随之实现。 一个企业级的GIS实施对于机构本身有很多益处,这些益处可以通过在所需资源中的适当投资来实现。只有你自己才能计划你的成功。仔细的思考如何利用GIS数据来支持业务运行,它是将花在GIS上的投资资本化的一条捷径。 ESRI白皮书 6. GIS用户需求 系统设计策略 对于需要GIS信息产品的单位来说,他们必须完成一个应用需求评价。这个需求评价应该有一个本单位的GIS人员领头,加上一个执行发起人的支持。专业的GIS咨询人员可以用来加速这一规划过程。通常情况下,对于证明GIS所需投资的合理性和为支持企业级GIS实施提供框架,规划是十分关键的。 图6-2 应用需求评价 为了支持一个成功的部署,许多技术上的努力必须被规划和协调。应用需求评价包括了对用户工作过程的考察,并且确定支持这些工作过程所需的数据和GIS应用程序。对用户工作流程需求的理解有助于进行业务运行的优化。 用户需求评价应该被文档化,并且在机构范围内的用户之间共享。应用需求评价的结果应该确定用户工作流程需求,列出现有的和所需的数据资源,并且提供一个支持运行需求的GIS应用软件的优先列表。研究结果还应该包括一个数据获取和应用程序部署的时间进度表。 Roger Tomlinson博士最近出版的新书《对GIS的思考》对GIS规划过程进行了一个非常出色的概述。Tomlinson博士进行GIS运行的规划和部署已经有超过42年的历史。在GIS界,Tomlinson博士被公认为“GIS之父”。Tomlinson博士对于企业级GIS规划的远见卓识也是《ESRI Planning for GIS》课程的基础,这门课程在ESRI 虚拟校园上的一门自学网络课程。对于那些想要利用它们的GIS资源和从一个成功的企业级GIS中获益的GIS管理人员和组织机构,这些资源都是非常有帮助的。 图6-3 GIS规划 ESRI白皮书 6. GIS用户需求 系统设计策略 6.2 系统设计前提 一个成功的企业级GIS是许多因素共同努力的结果,它必须有适当的人员、数据资源、应用程序和硬件设备等。GIS环境的类型和本质必须与组织机构的需求和技术相匹配。 图6-4 完整的GIS环境 在一个机构准备开发一个企业级的系统设计策略之前,一些基本的条件必须首先具备。这些条件包括建立一套GIS开发的机构性目标,确定应用程序需求和数据需求等。 被通过的机构性目标为取得所需资源支持GIS的实施提供了基础。一个企业级GIS方案的实施需要高层管理人员的支持,并且必须有整个机构范围内的多个部门的共同努力。在GIS目标中,还应该包括在下一个三年或者五年中,机构将要看到什么样的变化。这些实施目标为系统设计建立了需求底线。 ESRI白皮书 6. GIS用户需求 系统设计策略 6.3 GIS用户需求评价 为了支持一个有效的系统设计方案,有一些基本的用户需求必须被理解。这些需求包括确定与相关数据资源有联系的GIS用户处于什么地点,什么样的网络通讯可以连接用户地点和GIS数据资源,什么类型的用户位于这些地点等。图6-5对系统结构需求评价提供了一个概览。 图6-5 系统结构需求评价 6.3.1 GIS用户地点 在机构内部,所有需要访问GIS应用程序和数据资源的地点都必须被确定下来。系统结构设计的开发必须支持高峰时期的用户工作流。理解用户都在哪些地点、什么样的应用程序可以支持他们的工作和所需数据资源的地点,可以为系统设计分析提供一个基础。 6.3.2 网络通讯 进行系统设计评价,还应当确定不同地点之间的网络通讯。网络带宽的限制必须要在系统设计方案可以接受的范围之内。 罗马市将代表一个典型的机构,并且作为案例来说明系统设计过程。这个市有超过450名员工需要GIS信息来支持他们的日程工作流程。这些员工位于市里的规划、工程、警察和运行部门。市里的其他部门的员工也将从通过网络应用程序发布的标准GIS信息产品的部署中获益。 图6-6是在一个典型机构中确定的地点示意图。这幅插图对系统设计研究中的设施位置和相关的网络环境做了一个概览。 图6-6 网络通讯概览 ESRI白皮书 6. GIS用户需求 系统设计策略 这幅图确定了每个用户的位置和他们是怎么样通过宽域网和互联网进行连接的。 6.3.3 GIS用户类型 GIS用户的类型可以被分为两大类。ArcGIS desktop用户将需要桌面应用程序来进行GIS处理。剩下的用户可以由ArcIMS map services支持。 ArcGIS Desktop. 它包括支持普通的空间查询和分析研究、简单的地图制作和一般性的查询和分析操作的桌面GIS模块,包括所有的ArcEditor和ArcView客户端。为业务方案专门定制的GIS应用程序和其他支持特定业务需求的ArcView3GIS客户端也应该包括在这一类别中。 ArcIMS Map Services ESRI的ArcIMS为局域网和互联网的客户提供基于事务的地图产品。ArcIMS为需要访问标准地图产品的用户提供基于事务的网络服务。ArcIMS可以被ArcGIS desktop客户用作为数据源。 6.3.4 用户工作流程分析 图6-7提供的模板被用来记录罗马市第一年的用户应用需求。这个数据表确定了在部门层次的每个实体设施地点的用户工作流程需求。 图6-7 罗马市规划工作流分析—第一年 ESRI白皮书 6. GIS用户需求 系统设计策略 以下信息包括在表格的每一行中: 部门:在这项研究中所涉及的机构的最低级别。 工作流:部门的工作类别。 信息产品:为联系工作流和在用户需求评价中确定的信息产品提供的一个关键部分。 用户类型:需要特定的GIS应用程序来支持他们的工作流的职位或者用户类型。 用户总数:在部门中使用GIS应用程序的用户总数。 高峰使用率:在系统中的某一时间的用户数量的最高值。ArcGIS desktop用户可以由产品级别确定(ArcInfo、ArcEditor、ArcView)。而Web services可以通过估计的高峰事务率(每小时的请求数量)来表示。高峰使用负载将应用于设计分析,来确定系统容量需求。 每个部门经理都有责任来确认最终的工作流分析。在每一个实施阶段都需要完成一个工作流分析。图6-8提供了罗马市第二年的工作流分析结果。 图6-8 罗马市规划工作流分析—第二年 ESRI白皮书 6. GIS用户需求 系统设计策略 图6-9提供了罗马市用户需求的概览。并发用户的总数为建立服务器平台规范和网络带宽需求提供了一个基础。每个部门经理应该仔细的检查它们的GIS需求,确定支持他们工作环境所需的并发用户的数量。每个部门的GIS用户总数被确定下来。高峰并发用户负载可以通过软件的License级别来确定(AI:ArcInfo, AE:ArcEditor, AV:ArcView)。估计的高峰并发用户为软件的License需求和估计高峰的系统结构处理量提供了一个基础。用户清单可以由用户环境的快照视图通过时间来表示。 图6-9 用户应用需求概览 ESRI白皮书 6. GIS用户需求 系统设计策略 6.4 系统结构设计回顾 当选择一个系统设计的时候,人员在维护分布式计算机系统方案中的技术和经验是十分重要的考虑因素。而在选择合适的厂家产品的时候,对于分布式计算机环境的维护将是一个关键的考虑因素。在维护特定的计算机环境中的经验和训练可以确定一个特定的设计方案,它最适合你的机构。图6-10对一个系统设计回顾阶段所涉及的议题做了一个概述。 图6-10 建立在现有的IT投资之上 ESRI白皮书 6. GIS用户需求 系统设计策略 平台和网络环境 设计咨询师应该对现有的平台和网络环境进行评价。这些环境都是由机构维护的。对于机构来说,硬件经验、维护关系和人员培训都是一笔相当数量的投入。提交的GIS设计方案应该利用在现有的平台和网络环境下工作中获得的经验。 硬件策略与标准 机构开发策略和标准来支持他们的硬件投资决策。理解管理偏好和相关的厂方关系将能为设计一个最佳方案提供深刻见解。 运行中的限制和优先 理解GIS方案所支持的运行类型将可以确定对容错、安全性、应用程序性能和客户/服务器结构类型的需求。 系统管理经验 系统支持人员的技巧和经验为支持最终的设计方案提供了基础。对网络管理的理解和硬件支持经验,加上支持人员对未来管理策略的偏好,将帮助咨询人员建立兼容的硬件方案。 财政因素 最终的方案必须得负担的起。一个机构将不会实施一个超过它可用的财政资源的方案。在系统设计中,成本是性能和可靠性的函数。如果成本是一个考虑因素,系统设计必须要在用户应用性能、系统可靠性和花费之间做一个妥协。系统设计咨询人员必须要在确定的预算范围内来提供一个具有最佳性能和可靠性的硬件方案。 当前的技术可以支持整个企业范围的分布式GIS解决方案,但是在具体实施分布式计算机系统设计时仍然由许多限制因素。深刻理解GIS用户的真正需求和讨论满足这些需求选择方案是十分重要的,这样才能确定一个最有效的方案。 ESRI白皮书 6. GIS用户需求 系统设计策略 6.5 系统配置方案 许多GIS配置方案可以用来支持用户的处理需求。一旦单位和用户的需求被理解,最佳的配置策略也能够随之确定。 6.5.1 集中式计算机结构 一个集中式计算机结构能够支持整个企业网络环境下的ArcGIS desktop和ArcIMS map services的客户端。 n ArcGIS桌面应用程序可以通过标准的网络协议部署在分布式的局域网环境中。应用程序的执行可以支持本地工作站的操作系统环境。使用标准的网络磁盘共享协议可以直接访问分布式GIS数据。 n ArcGIS桌面应用程序也能够安装在中央应用程序服务器平台,它控制着多个远程终端客户。运行在应用程序服务器上的应用程序由位于远程桌面显示终端的用户显示和控制。应用程序和GIS数据服务器可以位于同一个中央计算机环境中。 n ArcIMS Web服务支持小型客户端的GIS用户,并且作为ArcGIS桌面客户的数据源。这个环境允许一个应用程序同时支持一大批并发的GIS用户。ESRI的ArcIMS组件安装在一个标准的Web服务器上,它指导着内向的地图请求等候位于地图服务器上的地图服务代理。每个请求可以在数秒时间内进行处理并将结果返回给企业的浏览器客户端。 图6-11提供了ESRI集中式结构方案的概览。 图6-11 中央服务器和工作站客户端 ESRI白皮书 6. GIS用户需求 系统设计策略 服务器和数据整合对于减少整个GIS实施和支持成本来说,是一条有效的途径。从一个集中式处理环境来支持GIS操作由很多的优点: n 减少硬件成本。比起支持在一个中央服务器上的繁重的应用程序,客户工作站的更新更加的昂贵。 n 减少管理成本。应用程序和用户工作空间都非常易于支持一个集中式的处理环境。 n 低实施风险。集中式的方案比分布式方案更容易部署。一旦系统在计算机中心安装和运行起来,它只需要通过简单的更新用户群的简介来部署到整个企业。 n 集成式运行。由于所有数据资源和客户端应用程序都位于同一个网络的计算机中心,数据的集成就变得容易得多。 n 改进的数据接口。计算机中心的高带宽减少了网络滞留,提高了应用程序的性能。 n 增强的安全性。应用程序和数据的访问都被严格限制在集中式计算级处理环境中。 n 减轻的网络通讯量。繁重的通信量在计算机中心网络被隔离。企业的通讯只限于终端客户显示信息和绘图。 6.5.2 分布式数据和工作站处理(WAN) 这一方案为每一个站点位置提供了GIS数据资源。它也包括运行在客户端桌面的应用程序,和每个位置分布式数据资源的网络接口。在用户分布在一个合理数量的站点,并且WAN通讯无法稳定的支持集中式运行环境的情况下,这是一个通常使用的方案。 图6-12 分布式数据和工作站处理(WAN) ESRI白皮书 6. GIS用户需求 系统设计策略 一个中央数据服务器维护着GIS数据仓库的拷贝,所需的数据从中央数据服务器复制到区域的数据服务器。在这个区域内做的数据更新被复制回中央数据服务器进行后续处理。 分布式数据则需要更多的服务器和存储空间。分布式方案要求数据的多个拷贝。随着数据量的增长,支持分布式方案的成本也随之增长。而且分布式方案会带来实施风险和维护上的问题,还会导致高成本的运行环境。所以在推荐一个分布式结构环境之前,必须要做慎重的考虑。 6.6 选择一个系统配置 一个特定单位的最佳方案主要取决于用户群的分布和使用数据的类型。用户的需求决定了运行环境中所需的机器数量,支持应用程序执行的内存大小和系统运行所需的磁盘容量。 图6-13 选择一个系统配置 ESRI白皮书 6. GIS用户需求 系统设计策略 理解和应用用户需求评价的一个基本因素就是确定系统中的用户类型和支持系统功能所需的工作站性能。所需的信息包括系统中的用户数量,每个用户使用GIS应用程序所占的时间百分比,用户工作空间的大小,系统中其他应用程序的大小和类型,和用户的性能需求。另外,数据文件存放在系统中的地点,用户如何访问这些数据,和存储数据所需的硬盘空间都是必须考虑的因素。此外,理解设施的布局,可用的网络通讯和对潜在的性能瓶颈的评价也都很重要。其他因素包括考虑现有的配置,单位的政策,对于可用的系统设计策略的偏好,未来的发展计划和预算经费等。 6.7 硬件组件选择 一旦一个配置策略被确定,支持这个方案所需的特定的服务器平台也能随之确定。 图6-14 硬件组件选择(集中式方案) ESRI白皮书 6. GIS用户需求 系统设计策略 n 集中式方案 第一步就是根据用户的需求和基础设施的限制,来确定所需的平台组件。在这个集中式方案里,我们选择一个ArcSDE geodatabase服务器,一个Windows Terminal Server,和一个ArcIMS服务器,并将它们安置在City Hall IT数据中心。中央ArcSDE数据库将支持所有共享的数据资源,Windows Terminal Server将提供位于中央计算机设施(与WAN带宽限制兼容)上应用程序的远程用户接口,ArcIMS服务器将支持从中央数据库的Web地图制图服务。 下一步是将按照部门级别和地点确定的高峰用户负载转换到支持他们应用程序和数据处理的相关平台上。这个分析结果确定了每一个被选择的硬件组件所对应的高峰用户负载。第七章将使用这些用户负载来产生每个所选硬件组件的性能规范。 图6-15硬件组件选择(分布式方案) ESRI白皮书 6. GIS用户需求 系统设计策略 n 分布式方案 第一步就是根据用户的需求和基础设施的限制,来确定所需的平台组件。对于罗马市分布式选项来说,警察局需要一个单独的安全数据服务器,运行部门需要一个位于运行设施紧急事件控制中心的服务器。在这个分布式方案中,我么选择一个ArcSDE geodatabase服务器,一个Windows Terminal Server,和一个ArcIMS服务器,并将它们安置在City Hall数据中心。我们确定一个单独的ArcSDE geodatabase服务器和Web服务器安置在警察局网络,一个ArcSDE服务器位于运行设施。中央ArcSDE数据库将维护和支持所有的企业GIS数据资源。这些数据的备份将被复制到警察局和运行部门的数据服务器上。Windows Terminal Server将支持位于City Hall计算机中心的应用程序的远程用户接口,中央ArcIMS服务器将支持从中央数据库的Web地图制图服务。警察局将为他们的安全网络单独配置一个ArcIMS服务器。 下一步是将按照部门级别和地点确定的高峰用户负载转换到支持他们应用程序和数据处理的相关平台上。这个分析结果确定了每一个被选择的硬件组件所对应的高峰用户负载。第七章将使用这些用户负载来产生每个所选硬件组件的性能规范。 在第六章和第七章介绍的性能评估模型将被用于确定候选的硬件平台配置,以支持上面确定的高峰用户负载。 ESRI白皮书 6. GIS用户需求 系统设计策略 6.8 网络适宜性分析 企业级GIS运行需要足够的网络容量来支持用户的性能需求。网络适宜性分析可以被用来确定与部署GIS操作相关的通讯性能风险。 一个完整的网络分析通常要超过一个典型的GIS系统结构设计评价的范围。网络在整个单位范围内支持用户的应用程序操作。尽管GIS用户对于用户总数来说只是一个很小的部分,但是GIS应用程序却需要可用网络带宽的很大一部分。 一个网络适宜性评价可以基于确定的GIS用户需求之上来完成。第一步是将要在分析中被评估的关键网络组件。进行这个分析,必须要对网络通讯流有深刻的理解。连接到宽域网或者网络服务提供商的网关组件是造成通信量瓶颈的最常见因素,所以这些组件应该在网络适宜性分析阶段被很仔细的评估。 图6-16表现了对罗马市的集中式配置所进行的网络负载分析。 图6-16 网络负载分析(集中式方案) 在这个分析中,网关到WAN和Internet的连接都被确定了。对应于每个网关连接的用户负载也被确定。 n City WAN连接。包括从运行设施和远程WAN野外办公室的高峰负载。 ESRI白皮书 6. GIS用户需求 系统设计策略 n City Hall Internet连接。包括IT部门的Web流量、远程运行媒介的流量,和有Internet连接的驻外办事处的流量。 n 运行设施WAN连接。包括所有从运行设施而来的流量,除了从远程媒介(它们通过Internet连接访问City Hall Web服务器)。 n 远程驻外办事处连接。包括所有的远程驻外办事处的流量。 一旦每个组件网关的高峰流量负载被确定,用户负载和事务处理率就能被转换为流量的带宽。图6-17表明了这个转换过程。 图6-17 网络适宜性分析—第一步(集中式方案) 在这个分析中,ArcGIS desktop负载被合并为单独的一栏,Web事务处理率也从小时转换为秒(除以3600)来支持最终的网络适宜性分析。 网络设计因素被用于将用户负载转换为估计的网络流量。转换后的网络流量(Mbps)再经过合并来确定总共的网络通信需求。LAN环境通常在25%到35%的带宽利用率上达到饱和,它应该被更新来避免饱和情况的出现。WAN环境大概在相同的通信水平出现传输延迟,在更新时应该考虑通信量达到50%的利用率。 图6-18提供了第二年的同样的分析。 图6-18 网络适宜性分析—第二步(集中式方案) ESRI白皮书 6. GIS用户需求 系统设计策略 带宽适宜性分析的结果表现了City WAN连接的一个严重的瓶颈(可用带宽为1.54Mbps,而所需带宽为1.76Mbps)。Freeberg, Willsberg和City Hall的Internet连接也都超过了35%的使用率。其中City WAN连接应该更新到T-2连接(6Mbps)来支持第一年的计划实施。Freeberg, Willsberg和City Hall的Internet连接也应该被紧密监视和更新,以防出现用户性能问题。 只要服务提供商能够支持所需的带宽升级,宽域网的更新没有特别需要可以推迟进行。服务提供商应该保证尽可能的易于联系,以检验带宽拓展的能力(通过基础设施升级来增加带宽能力需要花费时间)。 同样的分析也可被应用于分布式结构,其结果也相应的有所不同。图6-19和图6-20提供了分布式网络适宜性分析的结果。 图6-19网络适宜性分析—第一步(分布式方案) ESRI白皮书 6. GIS用户需求 系统设计策略 图6-20 网络适宜性分析—第二步(分布式方案) ESRI白皮书 7. 性能评估基础 系统设计策略 7 性能评估基础 计算机平台必须被正确配置以支持系统性能需求。有很多因素影响着系统的整体性能。企业级GIS解决方案包括分布式处理环境,在这里用户性能是许多硬件平台环境共同作用的产物。这些平台资源的中的许多都是与其他用户共享的。理解分布式处理技术为部署一个成功的企业级GIS环境提供了一个基础框架。 图7-1 理解这项技术 从80年代后期,ESRI就已经开始实施分布式GIS解决方案。但是多年来分布式处理环境没有被很好的理解,用户都依靠技术专家的经验来确定实施方案的硬件需求。每个技术专家对于一个成功的实施方案需要什么样的硬件设施都有自己不同的见解,因此作出的推荐也各不一样。许多硬件方案都是基于项目预算而做出的,对用户的需求和相关的硬件技术并没有一个清晰的认识。 系统性能模型在90年代早期得到发展,它用来记录对分布式处理系统的一些理解。从1992年起,ESRI的咨询人员就已经使用这些系统性能模型来支持分布式计算的硬件方案。这些模型还被用来确定现有的计算环境中潜在的性能模型。本章将阐述这些模型的基础。对于这些模型的基本理解将有助于用户更好的理解他们的计算环境。 ESRI白皮书 7. 性能评估基础 系统设计策略 本章所阐述的模型都是基于所有平台都拥有同样的处理能力的假设。这是阐述和理解性能模型的一个简化的途径。下一章将确定这些模型是如何应用于真实世界的,在那里平台性能是不一样的,并且快速的变化。 7.1 系统性能概况 计算机平台是由许多组件技术支持的。每个组件技术都影响着计算机的整体性能。硬件厂方使用合适的组件资源来建立计算机,优化平台的整体性能。 同样道理,分布式计算方案(企业级计算环境)也是由许多决定系统整体性能的硬件平台支持。每个硬件组件都对系统整体性能有影响,所以必须进行仔细的选择。 系统设计过程的主要目标是为可行的系统硬件投资提供高水平的用户性能,但是当前的技术水平对于系统设计方案的选择有所限制。对每个硬件组件的分布式处理负载的理解可以为建立一个最佳系统方案提供基础。 图7-2提供了在一个standalone工作站和一个分布式处理配置中组件的概览。每个组件都按顺序参与了整个程序的执行过程。 图7-2 平台性能组件 一个特定的应用程序请求所需的总共响应时间将是每个组件响应时间的总和。一个计算机厂家对工作站内部的组件进行优化,以支持计算机对一个应用程序请求最快的响应时间。一个IT或者系统集成部门有责任对单位的硬件和网络组件投资进行优化,为用户提供系统级别的响应服务。系统的性能能够直接的影响用户的生产能力。 图7-3表明了一系列硬件投资带来的性能上的收益。这些投资对于在用户桌面所体验到的相对性能有很大影响。 图7-3 系统性能概况 ESRI白皮书 7. 性能评估基础 系统设计策略 第一列代表着一个执行着一个典型的GIS操作(请求在用户屏幕上作一个新的地图范围的显示)的standalone工作站性能。经验表明GIS应用程序通常属于计算密集型和输入/输出(I/O)密集型。一个standalone工作站花费在数据存取和计算处理上的时间大致相当。剩下时间中相对较少的一部分被用来输送结果地图产品到屏幕进行显示。 第二列反映了访问位于本地磁盘上的文件服务器时系统的性能概况。这个分布式方案包括额外的服务器CPU处理和网络数据传输。这些额外的系统组件所导致的系统负载增加了整体的响应时间。通过一个10Mbps网络从文件服务器存取数据能减少大约30%的性能。 第三列反映了将文件服务器的JBOD(just a bunch of disks)配置升级到高性能的RAID存储方案所带来的结果。高性能的RAID存储方案可以将磁盘存取性能提高50%。 第四列表明了将网络带宽从10Mbps Ethernet增加到100Mbps Ethernet所带来的影响,它大约减少了10%的数据传输时间。用户通过在本地工作站硬盘使用这种配置而提高了性能。 第五列反映了将空间数据转移到一个ArcSDE服务器上的结果。这种ArcSDE服务器方案可以在许多地方提高性能。ArcSDE服务器技术对于由服务器平台的客户应用程序支持的查询处理进行了重新配置,它减少了大约50%的客户CPU处理需求。此外,空间数据在ArcSDE服务器上进行30%到70%的压缩,也能减少50%的网络流量。ArcSDE服务器还对被请求的数据进行过滤,这样只有被请求的图层范围通过网络送到客户端,又进一步减少了网络流量。在ArcSDE服务器上执行的查询处理使用了DBMS查询检索、数据缓存和搜索功能,可以将服务器上的处理负载量减少到不到传统的客户查询处理量的一半。 最后一列反映了将工作站的CPU升级到原来性能的两倍,它减少了50%的工作站CPU处理时间。 硬件组件投资直接影响到用户的生产能力,和单位的整体生产力。计算机技术的发展日新月异,它将为用户带来更高的性能和更强的生产力。单位需要为这种变化早作打算,在他们的基础设施领域做出明智的投资,以维持工作上的高生产力。一个明智的投资可以为GIS运行带来很大的利益。 ESRI白皮书 7. 性能评估基础 系统设计策略 7.2 如何了解性能评估(performance sizing) 图7-4确定了一些对系统整体性能有影响的关键因素。正确的硬件和结构选择是系统整体性能方程中很重要的一环。对整体的用户生产能力起作用的还有许多其它的性能因素。 图7-4 系统性能因素 对任何系统性能因素改进都会增强用户的生产力,并对整个系统性能产生影响。仅仅通过正确的硬件选择并不能保证性能水平。本章所介绍的性能评估模型(sizing model)将基于ESRI用户业务需求,对正确的硬件选择进行支持。我们应用于硬件组件上的性能分配是基于10多年的ESRI GIS技术部署的经验,一个基于系统的高峰用户负载而定的平衡的硬件投资将支持系统的性能需求。通过正确的硬件选购还可以节约金钱。 7.3 系统性能测试 1998年的7月的Westborough, Massachusetts,ArcInfo和Microsoft Windows Terminal Server 4.0 Edition的性能测试在Data General development labs进行。这是对ESRI在1993年完成的ArcInfo性能测试的更新。这项性能测试为性能评估模型用于配置分布式GIS计算环境提供了一个基础。这些模型的目标是为分布式GIS计算提供正确的系统硬件组件的选择和配置。 ESRI系统性能模型的基础是对计算机平台是如何回应日益增长的ArcInfo并发处理负载的理解。ArcInfo性能基准可用于评价平台对不断增长的用户负载的响应。多余的内存被配置在每个服务器平台上(2-4GB),来避免在测试中可执行程序的内存分页与交换(推荐的物理内存需求是由衡量被分配到每个应用程序的内存的单独实验来建立的)。 图7-5提供了一个对双处理器 Pentium Pro 200 Windows Terminal Server进行测试得到的ArcInfo基准。 ESRI白皮书 7. 性能评估基础 系统设计策略 图7-5 双处理器SMP性能 对于每个并发过程配置(1-8)都进行了一个单独的测试。第三维图形绘制了每一个并发过程测试运行的平均响应时间。第一维图形表现了服务器平台正在处理ArcInfo指令的速率。中间维表现了并发ArcInfo批处理的性能评估模型的曲线图。这个测试的结果检验了ArcInfo设计模型,并且表明了Windows Terminal Server对于这个平台配置具有很好的可伸缩性能。 图7-6提供了一个对四处理器 Pentium Pro 200 Windows Terminal Server进行测试得到的ArcInfo基准。对于每个并发过程配置(1-16)都进行了一个单独的测试。测试的结果检验了ArcInfo设计模型,并且表明了Windows Terminal Server对于这个平台配置具有很好的可伸缩性能。 图7-6 四处理器SMP性能 ESRI白皮书 7. 性能评估基础 系统设计策略 图7-7提供了一个对八处理器 Pentium Pro 200 Windows Terminal Server进行测试得到的ArcInfo基准。对于每个并发过程配置(1-32)都进行了一个单独的测试。测试的结果检验了ArcInfo设计模型,并且表明了Windows Terminal Server对于这个平台配置具有很好的可伸缩性能。 图7-7 八处理器SMP性能 ESRI白皮书 7. 性能评估基础 系统设计策略 每个基准测试系列都可以扩展到评价平台对于每个CPU进行四个批处理过程的支持情况。ArcInfo性能评估模型很少被用来确定每个CPU进行两个并发批处理的性能期望值。性能评估模型在这些测试系列的较低范围内可以很好的执行。 图7-8提供了一个Windows Terminal Server批处理测试的概览。同样的系列测试也在一个双处理器的UNIX平台进行(Sun Ultra 60)。在UNIX应用程序服务器上的性能评估(性能曲线的形状)测试结果与我们在Windows Server测试所得结果非常的相似,这表明Windows 平台上的八个处理器的性能评估与我们在UNIX平台上看到的相似。 图7-8 批处理测试总结 ESRI白皮书 7. 性能评估基础 系统设计策略 7.4 客户/服务器模式 另外的ArcInfo基准测试使用位于一个单独的文件服务器和一个ArcSDE服务器上的数据来评价处理性能。这些测试的结果为理解分布式计算负载和开发我们的客户/服务器计算性能评估模型提供了一个基础。 7.4.1 批处理性能 n Windows Terminal Servers 图7-9提供了一个对对称性多处理器(SMP)应用程序服务器平台(1-4 CPU配置)批处理性能的概览,其数据的存取是在一个单独的文件服务器上进行的。查询处理是由应用程序服务器支持,其数据位于本地硬盘或者一个远程的文件服务器上。每个批处理都消耗一个CPU的资源,SMP操作系统能够有效的在所有CPU之间分配处理负载。只要并发批处理的数据不超过可用的CPU数量,其性能就可以保持同一水平。如果并发处理数量超过了可用的CPU数目,性能就以一个相对稳定的速率减缓。 图7-9 Terminal Server配文件服务器或本地数据 ESRI白皮书 7. 性能评估基础 系统设计策略 图7-10提供了一个对SMP应用程序服务器平台(1-4 CPU配置)批处理性能的概览,其数据的存取是在一个ArcSDE服务器上进行的。查询处理是由ArcSDE服务器支持的。完全利用一个单独的CPU需要两个批处理过程。SMP操作系统能够有效的在所有CPU之间分配处理负载。只要并发批处理的数据不超过可用的CPU数量,其性能就可以保持同一水平。一旦CPU处理能力达到饱和,处理响应时间就以一个相对稳定的速率增加。如果超过这一临界点,额外的批处理的增加将不会带来生产能力的提高。 图7-10 Terminal Server配ArcSDE数据源 ESRI白皮书 7. 性能评估基础 系统设计策略 n ArcSDE数据库服务器 图7-11提供了一个ArcSDE客户/服务器处理负载的总结。测试结果表明大约20%的分布式处理负载(查询处理)由ArcSDE服务器支持,而大约80%的处理负载(地图生成)则由ArcGIS 桌面客户端支持。这一负载分布是在为每个ArcGIS软件发布进行的性能检验测试阶段得出的,它可以帮助我们认识性能可伸缩性的风险。 图7-11 ArcSDE数据服务器负载 ESRI白皮书 7. 性能评估基础 系统设计策略 对一个无版本化数据库的查询负载,其性能要好于对一个版本化数据库的查询。应用程序连接(AS)是指在数据库服务器环境中的ArcSDE支持下的配置,而ArcSDE直接连接(DC)则代表了使用ArcSDE Direct Connect API的连接。DC配置支持在客户端平台的ArcSDE gsvr处理,它能够显著的减少所需的服务器负载。上述访问一个有9个矢量层和一个图像层的ArcSDE geodatabase的测试结果表明,大约50%的查询负载都用来支持图像层的查询。 图7-12提供了并发批处理过程对ArcSDE数据服务器在性能评估上的要求的概览。图表显示了一个均衡的分布式平台配置,其中服务器和工作站平台都由一个CPU(所有的CPU都是一样的)。一个单CPU的ArcSDE数据服务器可以支持五个批处理客户工作站。因此,一个在数据服务器上执行的批处理程序相当于五个批处理的客户端(这两种情况都消耗一个服务器CPU)。批处理将相当部分的工作量放在数据服务器上,为客户端的处理节省了资源。 图7-12 数据服务器性能模型 ESRI白皮书 7. 性能评估基础 系统设计策略 图7-13提供了ArcSDE数据服务器性能模型。模型显示了单独的数据服务器中每个CPU支持多达五个并发的批处理客户端。由服务器支持的额外客户端则会导致查询性能的降低。这一性能剖析可以应用于计算密集型的ArcSDE服务器环境,在那里多种形式的测试和实际操作已经显示了ArcSDE服务器环境受CPU限制的本质。 图7-13 GIS数据服务器性能模型 n GIS文件服务器 ESRI白皮书 7. 性能评估基础 系统设计策略 文件服务器模型的基础是多年配置分布式ArcInfo企业环境的经验。尽管文件服务器会在容量规模超标时很快表现出性能上的问题,但是总体上来说,它还是属于低CPU处理强度型的。 图7-14对ArcSDE和文件服务器测试结果进行了概括,包括在ESRI ArcGIS性能基准测试中量测到的平均响应时间、每个请求的网络流量和平均网络吞吐量。图表强调了ArcSDE数据源的性能优势。从文件服务器传送到客户工作站的数据有超过80%被丢弃,无需进行地图显示。 图7-14 ArcGIS客户/服务器的网络流量分析 在先前的ArcSDE/文件服务器性能比较中,基准性能测试数据集使用的是San Diego数据集的一个子集。图7-15是性能检验测试中使用的关注区(area of interest)。 图7-15 性能检验测试数据集 ESRI白皮书 7. 性能评估基础 系统设计策略 图7-16比较了客户/服务器对大型数据库环境的性能敏感性。当使用完整的San Diego数据库进行同样的基准测试的时候,文件数据源在网络吞吐量上表现出显著的增长。这一增长是意料之中的,因为大数据量的shapefile必须要传送到客户工作站来支持查询处理。而ArcSDE测试的结果与前一张图表一致,没有受到数据库大小的影响。 图7-16 ArcGIS文件服务器的网络吞吐量 图7-17对使用一个文件数据源时同样的基准测试的平均响应时间进行了概括。使用文件数据源的响应时间非常缓慢是由于shapefile文件过大。使用ArcSDE数据源测试的结果与之相似。 图7-17 ArcGIS文件服务器的网络性能 ESRI白皮书 7. 性能评估基础 系统设计策略 7.4.2 ArcGIS桌面终端服务器性能 ArcGIS桌面用户包括许多专业分析人员、数据维护人员和商业查询与分析人员,他们使用GIS来管理它们的数据处理需求。GIS的规划需要花费几分钟、几小时甚至几天来完成,在这一阶段需要对大容量的数据资源进行考察。 用户需求可以被用来确定服务器在高峰处理时期能支持的终端服务(terminal sessions)数量。对并发用户(桌面使用案例)的定义是以系统现场基准测试和考察GIS用户实际操作经验的时候的实际用户负载为基础的。 图7-18是一个典型的GIS使用案例的概括,它显示了在过去的十年中,用户性能(用户经验)是如何随着工作站性能的增强而改变的。应用于ArcGIS性能模型的标准使用案例假设一个典型的客户端显示可以在大约2秒内产生,平均的用户交互时间(浏览显示内容并且输入数据的时间)大约为6秒。由此可得平均的用户循环周期(两个屏幕显示之间的时间间隔)为大约8秒。这些假设为转换我们的基础测试结果(批处理模型)到实际交互式用户环境中的性能评估模型(sizing model)提供了基础。对于ArcGIS性能模型来说,用户的等待占12%的CPU处理时间。在这些假定下,一个的ArcGIS桌面批处理提供了与六个并发的ArcGIS桌面客户端相当的处理负载。 图7-18 ArcGIS使用案例参数 ESRI白皮书 7. 性能评估基础 系统设计策略 一个典型用户浏览一个新的显示并为下一个显示输入合适的数据所花费的时间(用户交互时间)是批处理环境(无用户交互)与实际的用户工作环境之间的主要区别。GIS处理是一项计算强度很大的工作,用户在进行普通操作时也对计算机处理过程进行常规性的等待。在1999年之前使用的性能评估模型(Arc95到Arc98)假设ArcInfo用户必须花费50%的时间用来等待计算机处理过程(终端服务器能够支持每个CPU两个用户)。计算性能在随后的五年内快速增长了10倍多,GIS操作也变得更具生产力。Arc99、Arc00和Arc01性能模型假设GIS并发用户等待CPU处理的时间只占到33%,剩下的时间则花在数据浏览和输入上。Arc02和Arc03模型则假设用户等待CPU处理的时间占25%,Arc04模型的假设为12%(在过去一年内平台性能增加了一倍)。 平台性能每年都在提高,并且这项技术改进趋势将在不远的将来继续增长。随着平台处理性能的提高,GIS用户花费在等待CPU处理的时间将不断减少,生产力也得以增强。在某些情况下,用户交互时间将会在用户性能限制框架内达到最小响应时间。随着CPU处理时间继续以比用户交互时间更快的速度下降,批处理过程和实际交互式用户之间的关系也将继续得到增强。 图7-19对当前基于本地硬盘或者文件服务器数据资源的终端服务器性能模型进行了概括。每个CPU能够支持6个ArcInfo用户,只要用户的数量不超过CPU数目的六倍,性能将大体保持一致。当并发的用户数量超过可用CPU数目的六倍时,性能会以一个相对稳定的速率缓慢下降。 图7-19 终端服务器配文件服务器或本地数据 ESRI白皮书 7. 性能评估基础 系统设计策略 当ArcSDE用作数据源并且查询处理由ArcSDE数据服务器支持时,Windows Terminal Server负载会降低。图7-20显示了这种负载分配对于Windows Terminal Server平台处理能力的影响。 图7-20 Windows Terminal Server负载分析 如果使用ArcSDE数据源,有20%的处理量由一个单独的ArcSDE服务器平台支持。将WTS处理负载能力增加到100%可以容纳超过25%的用户负载(80%—)100%CPU利用率)。当WTS平台支持7.5个ArcGIS用户的时候(文件服务器负载增加了25%),WTS100%负载能力达到饱和。 图7-21对数据位于一个远程ArcSDE服务器的终端服务器性能模型进行了概括。ArcSDE服务器支持查询处理,可以减少20%的终端服务器上的用户负载。每个CPU能够支持7.5个ArcInfo桌面用户,只要用户的数量不超过CPU数目的7.5倍,性能将大体保持一致。当并发的用户数量超过可用CPU数目的7.5倍时,性能会以一个相对稳定的速率缓慢下降。 ESRI白皮书 7. 性能评估基础 系统设计策略 图7-19 终端服务器配ArcSDE服务器 图7-22对基于同样单CPU服务器的系统配置的终端服务器性能评估模型进行了概括。当在本地硬盘或者单独的文件服务器上进行数据存取的时候,每个CPU能够支持6个ArcGIS桌面用户。当在一个ArcSDE服务器上进行数据存取的时候,每个CPU能够支持7.5个ArcGIS桌面用户。 图7-22 终端服务器性能模型 ESRI白皮书 7. 性能评估基础 系统设计策略 图7-23中的CPU性能评估表提供了一个终端服务器CPU性能评估模型的可视化表达。 图7-23 终端服务器CPU性能评估表 ESRI白皮书 7. 性能评估基础 系统设计策略 表格在纵轴上确定了终端服务器平台CPU的个数,在横轴确定了高峰并发用户的总数。平台配置(双CPU平台,四CPU平台)可由性能评估表(根据平台配置中的CPU数目)上的水平线表示。性能评估模型可由表中的对角线表示(文件数据源为每个CPU 6个用户,ArcSDE数据源为每个CPU 7.5个用户)。内存需求也表示在表中,它是根据并发用户的数量和合适的平台内存配置来决定的。 7.4.3 数据服务器性能 数据服务器客户端性能是一个和批处理一起引进的模型的一个扩展,它有两种主要类型。文件服务器支持来自客户工作站的简单查询处理。ArcSDE服务器则融合了高性能的geodatabase解决方案,支持在数据服务器平台上的查询处理。 自90年代初期以来,GIS文件服务器已经有效的支持了GIS工作环境的系统性能需求。遵循这些设计指南的用户已经能够支持他们的服务器性能需求。文件服务器性能与支持客户查询的文件大小直接相关。小型文件(空间文件的范围与查询显示的大小相近)可以在一个文件服务器上运行的很好,并且将这些数据转移到ArcSDE服务器环境中,性能上的损失非常小。另一方面,大型数据文件(空间文件远大于平均的用户查询显示)转移到ArcSDE服务器环境可以带来很显著的性能上的收益。 ArcSDE数据服务器能够提供最具伸缩性和高性能的GIS数据源。服务器的查询处理利用高性能的DBMS查询功能和优化的数据缓存,可以服务器的整体处理负载,提高数据存取性能。对于大型的企业数据源和系统运行环境,ArcSDE是一种明智的选择。 性能模型在每个批处理过程能支持6个用户,并且每个GIS数据服务器CPU能够支持5个批处理过程。GIS数据服务器性能模型就可以支持每个CPU30个并发的ArcGIS桌面“真使用户”(real user)。如果数据服务器的客户不超过可用CPU数目的30倍,服务器的查询性能就能保持大体一致。如果超过了30倍,其性能就会以一个相对稳定的速率缓慢降低。 图7-24对当前的ArcSDE数据服务器性能评估模型进行了概括。 图7-24 ArcSDE服务器性能 ESRI白皮书 7. 性能评估基础 系统设计策略 ArcSDE geodatabase的性能在某种程度上依赖于数据模型的复杂程度。这种对象关系型的geodatabase为建立数据标准和空间特征的相关性提供了一个丰富的环境。在编辑和查询操作时,geodatabase表之间的关系能够产生额外的服务器负载。简单的数据模型比复杂的geodatabase环境执行的更好。同时,版本化的数据库环境也比非版本化的特征数据集需要更多的服务器负载。许多附加表都被包括在一个版本化查询里,从而导致服务器上增加的处理量。ArcSDE的性能调整非常的有效,性能因素也应该是数据库规划和管理中的一个有机组成部分。 图7-25对基于同样的单CPU服务器系统配置的数据服务器性能评估模型进行了概括。一个单CPU的GIS数据服务器能支持30个GIS客户端(一个数据服务器上的批处理过程相当于30个客户端)。 图7-25 ArcSDE服务器性能总结 ESRI白皮书 7. 性能评估基础 系统设计策略 图7-26的表格对ArcSDE服务器CPU的性能评估模型进行了可视化表达。 图7-26 ArcSDE CPU性能评估表 表格在纵轴表示服务器平台的CPU数目,在横轴表示高峰并发客户的数目。平台配置由性能评估表上的水平线表示(根据平台配置中的CPU个数)。性能评估模型则由表中的对角线表示。内存需求也表示在图中,是根据并发客户的数目和合适的平台内存配置来决定的。 ESRI白皮书 7. 性能评估基础 系统设计策略 7.5 ArcIMS网络地图服务模型 ArcIMS网络服务提供了一个基于事务的计算环境。服务代理(ArcIMS空间服务器)被安装在地图服务器平台上来支持客户端对地图服务(如创建一个地图产品)的请求。这些地图服务通过发布(连接到Web服务器)来支持客户端网络服务请求。每个地图服务都可以被看作是一个发布的地图模板,它是由ArcIMS空间服务器批处理程序为了满足客户端的服务请求而产生的。每个客户端交易产生一个新的地图产品。 Web服务结构是从传统应用环境分离出来的。在传统环境中用户访问量(user session)是由专门的运行在工作站或应用程序服务器上的可执行程序来支持,而Web服务则支持随机的客户请求,使用一个单独的服务器引擎(后台进程,background process)来支持一大批用户。 图7-27对支持一个ArcIMS Web站点的典型平台组件进行了概括。客户端可以是简单的基于HTML的浏览器,或者是复杂一点的具有Web服务器接口的客户应用程序。ArcIMS提供了一个Java客户端(ArcExplorer),由支持一个丰富的客户应用程序环境的客户端浏览器所支持。ArcIMS也能够支持简单的HTML客户端浏览器。ArcGIS客户(ArcInfo, ArcEditor, ArcView8.1)能够作为智能浏览器用户访问ArcIMS服务。 图 7-27 ArcIMS平台结构 许多服务器组件一起协同工作来支持地图服务。其中主要的Web服务组件包括Web服务器,地图服务器和数据服务器。 Web服务器连接着ArcIMS地图服务的浏览器客户端。通常平台都装有专门的ArcIMS Java servlet连接器和地图服务处理队列。 地图服务器支持Web站点上绝大部分的ArcIMS处理负载。地图服务器包括处理地图请求(创建地图产品)的可执行程序。对于大型站点,通常都由一个专门的服务器或者服务器群来支持空间服务器可执行程序。数据可以安装在地图服务器上,或者从一个单独的GIS数据服务器中存取。一个单独的服务器通常用于拥有多个地图服务器平台的大型站点。 ESRI白皮书 7. 性能评估基础 系统设计策略 图7-28提供了表示一个典型底图服务请求周期的性能概况。图表对处理一个Web事务,传递HTML页面和图像到客户端浏览器的平台和网络负载进行了概括。 图7-28 地图服务性能概况 7.5.1 ArcIMS服务器组件 ArcIMS软件组件为支持Web服务环境而提供了多种的配置选择。图7-29表示了ArcIMS软件组件以及它们在系统平台结构中的位置。 图7-29 ArcIMS服务组件 ESRI白皮书 7. 性能评估基础 系统设计策略 ArcIMS由以下功能组件所支持: Web服务器 Web服务器管理着外部网络客户端通讯和支持ArcIMS服务的ArcXML通讯之间的接口及其转换。Web服务器组件包括了支持转换HTTP XML通信量到ArcXML服务请求的Java连接器。 应用程序服务器 ArcIMS应用程序服务器组件为虚拟服务器建立了一个物理位置。一个虚拟服务器是为站点环境(包括图像虚拟服务、特征虚拟服务等)支持下的每个ArcIMS服务引擎所建立的。这个虚拟服务器在所有支持指定服务的ArcIMS服务引擎线程中注册,并且为内向(inbound)的服务请求提供一个等待队列,并分配这些请求到可用的服务线程进行处理。每个内向的地图服务被分配到适宜的虚拟服务器并在队列里等待后续处理,直到一个服务这个请求的代理线程可用为止。 空间服务器 ArcIMS空间服务器,或者地图服务器,为处理内向地图服务请求的ArcIMS服务引擎提供了一个“容器”。 数据服务器 ArcIMS服务引擎可以访问本地的shapefile、图像和ArcSDE数据源。这个服务引擎支持对本地shapefile和图像数据源的查询处理。ArcSDE DBMS支持对ArcSDE数据源的查询处理。一个ArcSDE的coverage接口也被提供用来支持访问ArcInfo coverage文件。 ArcIMS是一项基于事务的服务配置,它支持被请求的服务到达站点后的处理。对于每个请求,可以使用预置的后台脚本和相关数据源的固定连接来处理。在服务期间,这些脚本和器它的批处理程序一样的消耗CPU资源。当没有要处理的请求的时候,这些脚本处于闲置状态。在高峰处理负载时期,请求则在一个处理队列中滞留,等待被分配到一个已经完成前一个请求的脚本进行处理。 ESRI白皮书 7. 性能评估基础 系统设计策略 7.5.2 ArcIMS多线程服务引擎 位于空间服务器上的ArcIMS服务引擎被编译为多线程的可执行程序。这意味着每个可执行程序可以通过配置使用一套代码来处理多个请求。这种配置简化了站点的调谐,减少了由平台内存支持的可执行程序的数量。图7-30对多线程的可执行程序如何处理并发的多个请求进行了描述。 图7-30 ArcIMS多线程服务引擎 每个请求被使用指针的代码所跟踪。当指针选择了一行的指令,那一行的代码就被执行。和其他批处理程序一样,每个请求在同一时刻只能执行一条指令,并且只能利用一个CPU。如果两个线程被分配到同一个服务器,则这一服务可以在同一时间利用多达两个CPU,因为在同一时刻它可以为两个指针处理指令。 图7-31说明了为支持高峰事务量,在地图服务器上配置合适的ArcIMS线程数量的重要性。在图中,地图服务器是由Pentium III 4-CPU 900-MHz的平台担当,高峰的数据交换速率由ArcIMS线程的数量决定的。对于使用文件数据源的地图服务器,要达到其最高性能需要最小四个ArcIMS线程的配置;对于使用ArcSDE数据源来说,则需要8个ArcIMS线程。 图7-31 优化的服务代理配置的线程数量 ESRI白皮书 7. 性能评估基础 系统设计策略 在ArcIMS运行期间,一旦虚拟服务器收到来自ArcIMS空间服务器线程的输出,它就不会发布一个处理请求。从地图服务器完成服务处理到开始处理下一个请求,有一个时间上的轻微延迟。这一延迟是地图服务器和Web服务器之间的网络传输时间造成的。在ArcIMS调整阶段,添加额外的线程来达到最大的地图服务器输出性能显得十分的必要。这一额外线程将在地图服务器上支持一个额外的进程,以弥补时间上的延迟。 图7-32说明了配置合适的ArcIMS线程数量的重要性。在图中,地图服务器是由Pentium III 2-CPU 900-MHz的平台担当。三中不同的ArcIMS线程配置在图中体现(双线程、三线程和六线程)。对于由每个ArcIMS线程配置每六个地图请求,相应的客户端响应时间表现为6个请求同时到达站点。 六线程配置 所有的六个地图请求都被虚拟服务器分配到六个可用的空间服务线程中。所有请求都由2个可用的地图服务器CPU进行处理(每六个请求的服务时间为6秒)。 图7-32 Web服务器配置 ESRI白皮书 7. 性能评估基础 系统设计策略 三线程配置 6个请求达到站点,其中三个被分配到三个可用线程进行处理,另外三个在服务队列中等待可用的线程。第一批的三个请求在3秒内处理完毕,第二批的三个请求在下一个3秒内处理。总共的服务和等待时间(查询响应时间)对于第一批的三个请求来说是3秒,第二批则为6秒。 双线程配置 6个请求达到站点,其中两个被分配到两个可用线程进行处理,另外四个在服务队列中等待可用的线程。第一批的2个请求在2秒内处理完毕,第二批的2个请求在下一个2秒内处理,第3批的2个请求在最后2秒内处理。总共的服务和等待时间(查询响应时间)对于第一批的2个请求来说是2秒,第二批则为4秒,第三批为6秒。 对到达请求服务顺序的简单分析表明了配置过多ArcIMS线程的代价。分析也表明了配置合适的线程数量的优点,它能将平均地图服务的延迟降至最低。以下是配置服务代理的指南,以便获得最佳Web性能。 使用文件数据源的地图服务器。 对于每个地图服务,为每个地图服务器CPU配置一个ArcIMS公共服务线程。 使用ArcSDE数据源的地图服务器。 对于每个地图服务,为每个地图服务器CPU配置两个ArcIMS公共服务线程。 此外,还要包括一个额外的线程来利用地图服务器CPU资源,它在完成一个请求和开始下一个请求之间的时间延迟的时候使用(地图服务器和应用程序服务器之间的网络传输延迟)。 7.5.3 虚拟服务和处理队列 当配置一个ArcIMS服务器的时候,一个虚拟服务为每个激活的服务引擎而确定。地图服务随后被发布在一个相关的虚拟服务器上。对于一个特定的地图服务的请求被传输到相关的虚拟服务器进行处理。这个虚拟服务器被注册到相关的空间数据库服务线程,它用于处理服务请求。请求一直滞留在虚拟服务器队列中,直到一个相关线程可用。这时,服务请求就被分配到这个线程进行处理。一旦处理完毕,下一个等待的服务请求就被分配进来。一个单线程在同一时间只能处理一个请求。图7-33描述了三个虚拟服务器,每个配有两个线程。一个虚拟服务器支持一个图像服务引擎,另一个支持特征服务引擎,第三个支持ArcMap服务引擎。虚拟服务器与ArcIMS应用程序服务器组件处于同一位置。 ESRI白皮书 7. 性能评估基础 系统设计策略 图7-33 ArcIMS虚拟服务器 7.5.4 发布的地图服务 地图服务可以通过使用ArcIMS Manager的管理工具而被创建和发布,它还包括支持ArcIMS地图服务发布的向导。多种的简单地图服务可以使用简单的创建工具进行标准化(out of the box)配置。地图服务都是一些简单的命令集(在一个AXL文件中确定地图的图层和布局)。这些AXL文件被分配到一个虚拟服务器,适宜的网络连接也被预置来支持这些服务指令的部署。一旦地图服务部署完毕,用户就可以通过Web站点发送请求了。 7.5.5 ArcIMS性能评估模型 ArcInfo批处理性能评估模型可以被用来支持ArcIMS地图服务器的性能评估。ArcIMS空间服务器的最大性能在100%地图服务器CPU利用率的情况下达到。每个地图服务引擎线程象一个批处理程序一样执行,并且当使用文件数据源服务一个请求(线程执行查询和创建的功能)时消耗CPU资源。当使用ArcSDE数据源的时候,需要两个服务线程来消耗一个CPU,和先前的批处理模型一样。 图7-34提供了估计一个ArcIMS地图服务器的高峰数据交换能力的选项。由ArcIMS空间服务器支持的每小时高峰请求数可以由每小时的秒数除以平均地图服务时间(秒)。 使用ArcSDE数据源的ArcIMS空间服务器将查询处理的工作量放在ArcSDE数据服务器上,减少了大约50%的地图服务器的服务时间。使用一个单独的ArcSDE数据源的ArcIMS地图服务器能够支持两倍于使用文件数据源的地图服务器的数据交换/每小时。 在ArcIMS高峰负载期间,平均的请求等待时间(在虚拟服务器队列中的时间)相当于大约四倍的平均地图服务时间(这些估计假定随机到达时间;估计基于标准队列理论)。总共的平均等待加服务时间相当于高峰系统负载期间五倍的平均服务CPU处理时间(地图服务器CPU 100%的利用率)。 图7-34 ArcIMS 地图服务性能评估模型 ESRI白皮书 7. 性能评估基础 系统设计策略 许多情况下,量测发布的ArcIMS 地图服务时间不可行,因为有些特定的地图服务不是为了测试而开发或发布的。在这些情况下,硬件的选择必须基于已制定的性能标准。ArcIMS地图服务器性能评估模型就是基于对标准发布的地图服务的性能评价,可以用来支持用户选择一个合适的硬件解决方案。 图7-35对ArcIMS地图服务器性能评估模型进行了概括。2003 ArcIMS地图服务器平台(Intel Xeon 3200-MHz平台)使用文件数据源能够支持每小时6000个请求(per CPU),如果使用ArcSDE数据源则可以支持每小时12000个请求(per CPU)。 图7-35 ArcIMS性能评估模型 ESRI白皮书 7. 性能评估基础 系统设计策略 7.5.6 ArcIMS数据服务器负载模型 在高峰ArcIMS负载阶段,地图服务器的CPU达到100%的利用率,支持批处理过程的客户短平台性能也同样达到饱和状态。正是如此,ArcInfo批处理服务器负载模型可以用来确定ArcIMS的高峰数据服务器负载。高峰数据服务器负载大约相当于20%的地图服务器负载(一个数据服务器CPU可以支持五个地图服务器CPU)。图7-36对ArcIMS服务器负载模型进行了概括。 图7-36 ArcIMS服务器负载模型 ESRI白皮书 7. 性能评估基础 系统设计策略 在高峰数据交换负载期间,一个ArcIMS线程相当于一个ArcGIS桌面批处理过程。根据我们的Arc04性能模型,一个批处理过程相当于7.5个并发的ArcGIS客户端。 ArcSDE数据源 一个使用ArcSDE数据源的ArcIMS地图服务器需要至少两个ArcIMS线程才能达到最大平台性能(查询处理由单独的ArcSDE服务器平台支持)。一个单一线程的初始负载分布在两个平台之间,其中大约80%在客户端,20%在ArcSDE服务器。如果线程增加到ArcIMS地图服务器的高峰负载水平,则ArcSDE服务器负载将增加约25%的单CPU性能。ArcSDE服务器上的这25%的CPU性能负载相当于五个ArcSDE桌面客户端。根据ArcIMS性能模型,这种配置可以产生每小时12000个请求的高峰负载量。 从单独的地图服务器中产生的等量的数据客户端负载可以通过设计的ArcIMS高峰数据交换速率除以每小时1600个请求(12000TPH/7.5客户端)来估算。如果ArcIMS空间服务器安装在数据服务器上,则每个ArcIMS线程的高峰负载将会消耗一个服务器CPU,相当于30个并发的ArcGIS客户端。 图7-36中的表格对ArcIMS数据服务器负载模型进行了可视化表达。 7.6 ArcGIS Server性能评估模型 图7-37提供了一个ArcGIS Server组件结构的概览。主要的ArcGIS Server平台处理环境包括container machine(CM)和Web服务器(Web应用程序服务器)平台。对于Web浏览器,Web应用程序需要50%的CPU资源来支持container machine 的服务器对象容器(SOC)的处理。 图7-37 ArcGIS Server组件结构 ESRI白皮书 7. 性能评估基础 系统设计策略 ArcInfo批处理性能评估模型也可以用来支持ArcGIS Server的container machine和Web服务器的性能评估。ArcGIS Server的container machine的最大性能在100%的地图服务器CPU利用率时达到。每个服务器对象容器线程和一个批处理程序一样执行,并且使用文件数据源服务一个请求的时候要消耗一个CPU(线程执行查询和创建功能)。当使用ArcSDE数据源的时候,需要两个SOC例程来消耗一个CPU,和先前的批处理模型一样。 图7-38提供了估计一个ArcGIS Server的container machine和Web应用程序服务器平台的高峰数据交换能力的选项。由AGS SOC支持的每小时高峰请求数可以由每小时的秒数除以平均地图服务时间(秒)。 使用ArcSDE数据源的AGS SOC将查询处理的工作量放在ArcSDE数据服务器上,减少了大约50%的地图服务器的服务时间。使用一个单独的ArcSDE数据源的AGS SOC能够支持两倍于使用文件数据源的地图服务器的数据交换/每小时。 在ArcGIS Server高峰负载期间,平均的请求等待时间(在虚拟服务器队列中的时间)相当于大约四倍的平均地图服务时间(这些估计假定随机到达时间;估计基于标准队列理论)。总共的平均等待加服务时间相当于高峰系统负载期间五倍的平均服务CPU处理时间(地图服务器CPU 100%的利用率)。 图7-38 ArcGIS Server性能评估模型 许多情况下,量测发布的ArcIMS 地图服务时间不可行,因为有些特定的地图服务不是为了测试而开发或发布的。在这些情况下,硬件的选择必须基于已制定的性能标准。ArcGIS Server性能评估模型就是基于对标准发布的地图服务的性能评价,可以用来支持用户选择一个合适的硬件解决方案。 图7-39对ArcGIS Server性能评估模型进行了概括。2004 ArcGIS Server平台(Intel Xeon 3200-MHz平台)使用文件数据源能够支持每小时3000个请求(per CPU),如果使用ArcSDE数据源则可以支持每小时6000个请求(per CPU)(一个简单的地图服务大约为50%的ArcIMS地图服务器性能)。 ESRI白皮书 7. 性能评估基础 系统设计策略 图7-39 ArcGIS Server地图服务器性能评估模型 7.6.1 ArcGIS Server数据服务器负载模型 在高峰ArcIMS负载阶段,地图服务器的CPU达到100%的利用率,支持批处理过程的客户端平台性能也同样达到饱和状态。正是如此,ArcInfo批处理服务器负载模型可以用来确定ArcIMS的高峰数据服务器负载。高峰数据服务器负载大约相当于20%的地图服务器负载(一个数据服务器CPU可以支持五个地图服务器CPU)。图7-40对ArcGIS Server负载模型进行了概括。 图7-40 ArcGIS Server负载模型 ESRI白皮书 7. 性能评估基础 系统设计策略 在高峰数据交换负载期间,一个ArcIMS线程相当于一个ArcGIS桌面批处理过程。根据我们的Arc04性能模型,一个批处理过程相当于7.5个并发的ArcGIS客户端。 ArcSDE数据源 一个使用ArcSDE数据源的ArcIMS地图服务器需要至少两个ArcIMS线程才能达到最大平台性能(查询处理由单独的ArcSDE服务器平台支持)。一个单一线程的初始负载分布在两个平台之间,其中大约80%在客户端,20%在ArcSDE服务器。如果线程增加到ArcIMS地图服务器的高峰负载水平,则ArcSDE服务器负载将增加约25%的单CPU性能。ArcSDE服务器上的这25%的CPU性能负载相当于五个ArcSDE桌面客户端。根据ArcIMS性能模型,这种配置可以产生每小时6000个请求的高峰负载量。 从单独的地图服务器中产生的等量的数据客户端负载可以通过设计的ArcIMS高峰数据交换速率除以每小时800个请求(6000TPH/7.5客户端)来估算。如果ArcIMS空间服务器安装在数据服务器上,则每个ArcIMS线程的高峰负载将会消耗一个服务器CPU,相当于30个并发的ArcGIS客户端。 Web服务器性能评估表 图7-41中的表格对ArcGIS Server和ArcIMS CPU性能评估模型进行了可视化表达。 图7-41 ArcGIS Server和ArcIMS性能评估表 ESRI白皮书 7. 性能评估基础 系统设计策略 图表在纵轴表示了服务器平台CPU的数量,在横轴表示了高峰数据交换率。平台配置由性能评估表上的水平线表示(根据平台配置中的CPU个数)。性能评估模型则由表中的对角线表示(对于AGS和Web应用程序在一个平台上的是4000TPH/CPU,对于AGS是6000TPH/CPU,对于ArcIMS是12000TPH/CPU)。初始内存需求也表示在图中。如果使用文件数据源,数据交换率的期望值将减少50%。 Web数据服务器负载表 图7-42中的表格对ArcGIS Server和ArcIMS CPU性能评估模型进行了可视化表达。 图7-42 ArcIMS数据服务器负载表 ESRI白皮书 7. 性能评估基础 系统设计策略 图表在纵轴表示了每小时的高峰地图请求,在横轴表示了高峰服务器客户端负载。高峰事务处理率由性能评估表上的水平线表示(根据应用需求评价)。ArcIMS和ArcGIS Server负载模型则由表中的对角线表示(对于AGS是800TPH/客户端,对于ArcIMS是1600TPH/客户端)。 7.7 结论 本章所阐述的性能评估模型为理解系统性能提供了一个基础。本章所展现的模型都是以CPU资源相同为假设前提的。在实际工作中,平台性能并非完全一致。硬件厂商每隔三到六个月就发布新的平台,而CPU则以更快的速度进入市场,新技术也被不断引入来提高处理性能。在实际工作中,每个平台配置都有自己独特的性能表现。下一章将详细阐述这些模型是如何应用到实际的系统设计中去的。 ESRI白皮书 8. 性能评估工具 系统设计策略 8 性能评估工具 我们今天生活的这个世界正在享受着技术发展带来的好处。技术的进步直接影响着我们每个人的生产力——我们处理信息和改造环境的方法。我们驾驭这一变化并且利用它所带来的好处,可以有助于我们追求事业和家庭的成功。 第七章在假设所有硬件平台都一样的前提下,对系统配置性能模型进行了阐述。本章将继续阐述在硬件平台千差万别的情况下,我们如何利用这些模型来进行正确的硬件选择。 系统设计过程确定了最佳的系统配置策略,选择合适的硬件组件并且为支持用户性能需求提供平台规范。第六章为确定一个支持特定用户需求的企业系统配置策略提供了一种方法论,这种方法论为一系列支持系统方案所选择的平台组件提供了高峰用户负载。本章将为转换高峰用户平台负载到特定的平台规范提供切实可行的工具。 8.1 性能基准选择 进行一个系统设计,需要明确用户对性能上的需求。而用户的性能需求通常由用户为支持计算需要而选择的工作站平台来表示的。为了支持用户桌面性能需求,应用程序和数据服务器必须配置。 在过去的几年里,用户性能的期望值已经发生了显著的变化。这种在性能需求上的变化主要归结于更快的平台性能和更低的硬件成本,它为用户生产力的增加有直接的贡献。 图8-1表现了自1994年9月ArcInfo 7.0.2发布以来,单用户ArcInfo平台需求所发生的变化。 图8-1 ArcInfo平台性能历史 ESRI白皮书 8. 性能评估工具 系统设计策略 在1994年,Sun SPARCstation 10 Model 40是一个强大的单用户工作站。这个平台的性能价格比可以与同时期的其他UNIX厂商产品相媲美。 1996年2月,ESRI发布了ArcInfo7.0.4。SUN公司发布了他们的SPARCstation 20 model,并且SPARCstation 20 Model 71成为单用户工作站的普遍选择。SPARCstation 20 Model 71比SPARCstation 10 Model 40大约快2.5倍。 1997年2月,ESRI发布了ArcInfo7.1.1。第一个基于Windows的ArcInfo产品是在Intel Pentium Pro200上运行的。Pentium Pro200为1997年的ArcInfo用户提供了标准的工作站性能。Pentium Pro200比SPARCstation 10 Model 40要快4倍多。 1998年4月,ESRI发布了ArcInfo7.2.1。Intel正在发售Pentium II-300平台,它为1998年的ArcInfo用户提供了标准的工作站性能基准。Pentium II-300平台比SPARCstation 10 Model 40要快6倍多。 随着ArcInfo 7增强版中代码的优化,ArcInfo应用程序性能也得到提高。1994年9月由ArcInfo7.0.2开发的脚本在同一平台上比发布的ArcInfo7.2.1运行的更快。ArcInfo性能基准的变化与其说是软件驱动的需求,不如说是平台技术的快速发展和不断降低的成本而导致的用户性能期望值的变化。 1999年7月,ESRI进行了ArcInfo8的第一次发布。Intel Pentium III-500平台是当时最流行的ArcInfo工作站选择。Pentium III-500比SPARCstation 10 Model 40要快11倍多。 2000年5月,ESRI发布了ArcInfo8.0.2。Pentium III-733被选为支持2000年夏季部署的性能基准。Pentium III-733比SPARCstation 10 Model 40要快22倍多。 随后的性能提高速度的减缓一直延续到2001年。这种延缓是由于下一代的处理器技术的发展引起的。Pentium III-900被选为支持ArcInfo8.1发布的性能基准。 2002年6月,Intel Xeon MP 1500-MHz服务器提供了一个显著的性能收益。但是Intel服务器技术仍然落后于工作站,到了年中正在达到Xeon MP 2400-MHz的性能门槛。IBM和Sun UNIX服务器平台与Intel的工作站性能水平保持一致。Intel的1500-MHz芯片由一些性能上的问题,所以其部署一直延迟到秋季。Intel Xeon MP 1500-MHz平台被选为支持ArcInfo8.2发布的性能基准。 2003年6月,Intel Xeon MP 2000-MHz支持当前的Windows服务器。Intel Xeon MP的性能问题已经得到解决,2000-MHz处理器支持着当前的服务器平台。这个服务器比上一年有了一个明显的改进,可以与Intel Xeon MP 2400-MHz工作站性能媲美。Intel在年中之前又发布了Intel Xeon MP 3060-MHz工作站平台。Intel计划在在秋季发布2800-MHz的服务器版本。Intel Xeon2400被选为2003年的性能基准。 2004年6月,Intel Xeon MP 3000-MHz支持当前的Windows服务器。Intel Xeon MP的性能问题已经得到解决,3000-MHz处理器支持着当前的服务器平台。这个服务器比上一年有了一个明显的改进,可以与Intel Xeon MP 3200-MHz工作站性能媲美。Intel在年中之前又发布了Intel Xeon MP 3600-MHz工作站平台。Intel Xeon3200被选为2004年的性能基准。 图8-2对过去8年中Intel工作站性能进行了图形化概述。厂商发布的商业基准结果提供了图中表示的相对性能。 图8-2 Windows平台性能历史 ESRI白皮书 8. 性能评估工具 系统设计策略 位于图表底部的方框表示被选择的ArcGIS桌面用户性能基准。每个方框的注记表示相应的年份(Arc99表示1999年的性能基准,Arc00表示2000年的性能基准,如此下去,直到Arc04表示2004年的性能基准)。这些性能基准与图8-1中确定的用户平台相一致,他们代表了用户在那段时期的性能需求。从图中我们可以看出,ArcInfo平台性能比五年前提高了10倍多。 8.2 硬件生命周期 平台性能的提高对基础设施投资策略有直接的影响。当今绝大多数单位都发现为了保持稳定的生产能力,必须每隔三年或五年就要对硬件进行再投资。为了支持一个有效的IT基础设施,对硬件生命周期的基本理解十分重要。 图8-3提供了用于衡量硬件生产力的定义。这些定义在量化期望的基础设施投资策略,满足系统性能需求方面十分有用。 图8-3 硬件生命周期 ESRI白皮书 8. 性能评估工具 系统设计策略 图8-4确定了估计的硬件生命期望值。这些估计为资金预算提供了指南。硬件应当在用户性能需要时购买,并且在部署的第一年具有50%的利用率。硬件的更新应该每隔三年到四年就要作计划,以维持产品的生产能力。 图8-4 硬件生命周期(月) 8.3 我们如何应对变化 用于配置一个企业级GIS环境的硬件平台应该包括许多配置和不同的模型。每一种配置必须支持保证系统正常工作的用户性能需求。平台的性能不是仅仅由CPU的个数或者CPU速度(MHz)来决定的。在一个特定的平台配置中有许多组件都对整体性能有影响,包括CPU的设计和模型,系统总线的速度和所安装的操作系统。 一个特定平台模型和配置的基准性能比CPU的数目更适于衡量整体性能。一个公共基准集合可以用来衡量两个不同硬件平台配置的相对性能。如果知道两个平台配置的相对性能,就能确定这两个平台的相对应的相对性能。 图8-5提供了一个相对性能理论的定义,它可以和第七章阐述的性能评估模型一起用于量化基于用户需求的平台规范需求。 ESRI白皮书 8. 性能评估工具 系统设计策略 图8-5 相对性能理论 相对性能理论根据一个新的服务器对一个已知的服务器配置的相对性能,来确定其计算能力。比如,如果我们知道一个现有的服务器可以支持100个客户端,并且新的服务器的性能是现有服务器的两倍,我们就可以预测新的服务器可以支持200个客户端。 8.4 我们如何衡量变化 要发现一个可靠并且客观的能够用于建立厂商平台之间的相对性能的基准集是一件具有挑战性的事情。理想的基准集是简单的、一致的,并且能够经得起时间的考验(我们都想知道新的工作站的性能相对于现有的旧模型来说如何)。我们也希望每一个厂商平台能够基于这些基准进行测试,并由厂商在网上发布这些基准,使之作为用户的参考。我们也希望这些基准在本质上是中性的,厂商不会怀疑它们的有效性。 标准性能评估公司(SPEC)于80年代组建的,其宗旨是确立和创建客观的面向应用的测试集合,可以作为公共参考点,并且用于评估不同工作站平台之间的性能。图8-6提供了当前SPEC宪章。ESRI系统设计咨询人员从1992年起就用SPEC基准作为确定支持硬件平台相对性能的一个独立来源。SPEC的相对性能衡量方法对于表现相对平台性能非常有用,它与ESRI性能评估模型共同使用来确定合适的平台解决方案,以支持GIS用户性能需求。 图8-6 我们如何衡量变化 SPEC在2000年早期宣布了SPEC2000基准集的发布。图8-7提供了一个SPEC2000基准集的概览。SPEC2000包括两套基准:针对计算密集型的整数性能的CINT2000和针对计算密集型的浮点性能。这两套集合提供了组件级别的基准,可以量度计算机处理器、内存结构和编译器。SPEC基准是从现有的运行于多种平台的应用程序和基准源代码中选择的。每个基准都在不同平台上进行测试,以取得主流硬件和软件平台的平均性能结果。 ESRI白皮书 8. 性能评估工具 系统设计策略 图8-7 SPEC2000基准集 用C和C++语言编写的CINT2000包括12个CPU密集型的整数基准,它在使用每个基准的主动(SPECint2000)和被动(SPECint_base2000)优化模式进行编译的时候,量测和计算12个标准化比率(每个都对应一个整数基准)的几何平均数;在使用每个基准的主动(SPECint_rate2000)和被动(SPECint_rate _base2000)优化模式进行编译的时候,量测和计算12个标准化输入输出量比率(每个都对应一个整数基准)的几何平均数。 用C和FORTRAN 77&90语言编写的CFP2000包括14个CPU密集型的浮点基准,它在使用每个基准的主动(SPECfp2000)和被动(SPECfp_base2000)优化模式进行编译的时候,量测和计算14个标准化比率(每个都对应一个浮点基准)的几何平均数;在使用每个基准的主动(SPECfp_rate2000)和被动(SPECfp_rate _base2000)优化模式进行编译的时候,量测和计算14个标准化输入输出量比率(每个都对应一个整数基准)的几何平均数。 8.5 硬件平台选择 在选择一个平台厂商的时候应该考虑很多因素。两个最可见和最明显的标准就是平台性能和购买价格。这些标准对系统的设计和认可非常关键,但是不涉及影响系统整体成本的其它隐含因素。当今世界的顶尖硬件平台厂商在技术性能和价格上都非常具有竞争力。一个GIS平台环境的购买可能耗时几个月甚至数年,而在此期间领先水平的硬件制造商之间的平台性能领导地位也将变换数次。 系统的支持能力也许是一个决定性因素。许多情况下,公司都投入重金来进行培训和人员配置,以支持一个特定的硬件厂商方案。雇用、培训和维护员工来支持适宜的计算环境对于系统的成功运行是一个非常重要的因素。 在选择一个合适的厂商时,公司与厂商销售和支持人员的关系也是一个决定性因素。在整个国家范围内厂商的支持并非完全一致,这些人员之间的关系将影响到系统被支持的程度。 在选择一个厂商方案时,系统的总共生命周期成本和性能应该是首要的考虑因素。本章将提供一种建立达到公共性能期望值的厂商配置的方法。达到公共性能期望值的系统方案为生命周期成本比较提供了一个基础。 一旦一个厂商被选择,对于可用的候选硬件平台和与他们相关的SPEC基准等级的评价将为满足配置需求提供一个基础。以下信息在为配置一个系统方案进行候选平台评估的时候非常有用。 ESRI白皮书 8. 性能评估工具 系统设计策略 8.5.1 平台性能评估模型格式 图8-8为表现每一种ESRI产品方案的性能模型提供了一种方法。理解如何阅读和应用这张图表将为在本章的随后内容使用性能模型提供一个基础。 图8-8 平台性能图表概览 这张图表的左边表示基于公布的每个所选平台配置的SPEC基准的平台性能。应用程序计算平台将使用SPECrate_fp2000基准结果,而数据服务器平台使用SPECrate_int2000基准结果。 图表提供了2001、2002、2003和2004年的性能级别,由图表上的对角线表示。这些线标记着Arc01,Arc02,Arc03和Arc04,表示相对应年份的性能基准。已公布的单处理器基准值在每个性能线上被确定。 并发客户由图表的X轴表示。内存推荐值是并发客户端连接的函数,并表示在性能表上。建立内存需求所用到的公式在图表左下角表示。 一个特定的平台配置是由一条水平线在图上表示(SunFire 6800 14-CPU 1200-MHz平台是一个14-CPU配置,使用SPECrate_int2000性能基准,其值为106.8)。平台性能和相应的基准性能线的交叉点确定了内存需求和客户端数目,他们能够被确定的平台配置的性能级别所支持。(范例表明在Arc04性能级别可以支持180个客户端;支持这一客户数目需要14GB的内存)。这张图表也可根据相同的程序确定其他性能级别(Arc01,Arc02,Arc03和Arc04)的配置要求。(SunFire 6800 14-CPU 1200-MHz配置在Arc02性能级别可以支持340个客户端;支持这一客户数目需要16GB的物理内存)。 8.5.2 在哪里可以发现性能基准? 图8-9对使用750-MHz处理器的Sun Fire 3500服务器配置进行了概括,它是在SPEC网站使用搜索功能和在表中确定的结果而来的。这是Sun Microsystems为这些平台配置所发布的SPECrate_int2000性能基准。 ESRI白皮书 8. 性能评估工具 系统设计策略 图8-9 发布的SPEC基准结果 使用14个750-MHz处理器的Sun Enterprise 3800配置有一个发布的SPECrate_int2000性能基准,其值为59.6。在表中同样的平台但是单CPU的配置也有一个基准,其值为4.5(8.97/2)。图8-10中的表格绘制了被选择的平台配置基准值,使用这张表格可以作为一个性能评估工具,来确定如果使用这个平台作为ArcSDE数据服务器,可以支持多少个GIS浏览用户。 图8-10 ArcSDE性能评估示范 上表表示了所选择的Sun E4800平台配置与Arc04性能线相交于100个并发用户。图表也确定了单CPU的性能值为4.5,表示由这个平台提供的最大事务处理性能(单用户事务处理性能)。事务处理性能略低于Arc01性能线(这是一个旧平台,不到现在的Arc04技术性能的一半)。对于这项旧技术,它不可能支持当今的事务处理性能级别。如果服务器能够配置12GB的内存,并且在Arc01性能级别支持客户工作站的运行,这个平台的性能容量(高峰服务器事务处理率)能够在同一级别支持多达240个并发客户端。 ESRI白皮书 8. 性能评估工具 系统设计策略 Arc04事务处理性能级别可以由当前的平台技术所支持,其代表为IBM p690(SunFire 6800 14-CPU 1200-MHz平台已经有一年多的历史了)。新的性能评估门槛在每年的夏季制定,它基于当年当时的平台技术。新的厂商平台技术可以支持超越去年的性能基准的事务处理性能。14-CPU平台配置的高峰容量性能(最大事务处理率)在平台通过420个并发ArcSDE客户端之前就可能达到,而这一时刻如果有额外的ArcSDE客户负载增加,事务处理性能将降至到Arc04级别。平台的选择应该建立在高峰事务处理性能的基础之上,因为一旦性能开始降低,用户就会丧失生产能力。 8.6 性能评估表 本章的剩余部分将为图8-11中确定的每一个ESRI软件方案提供单独的性能评估表。同时为了参考目的,还包括绘制在表上的示范性平台。 图8-11 平台性能评估模型 工作站和应用程序计算服务器(Windows Terminal Server)支持应用程序的处理。GIS应用程序处理是计算密集型的,并且在传统上倾向于浮点计算。最近的基准测试表明ArcGIS应用程序主要是整数密集型的,并且所有的Arc04模型为了性能评估目的,都使用SPECrate_int2000基准结果。ArcSDE geodatabase查询也是整数密集型的,并且为了性能评估目的使用同样的基准结果。 8.6.1 GIS桌面平台 图8-12为GIS桌面平台提供了推荐配置。 图8-12 ArcInfo和ArcView平台推荐 GIS用户工作站有两种类型。支持ArcInfo工作站和ArcGIS桌面应用程序(ArcInfo, ArcEditor, 和ArcView)需要高性能的配置。小型的应用程序如ArcView 3和定制的ArcEngine 9桌面应用程序可以使去年的性能平台支持相似的生产能力。标准的Windows Office桌面环境可以支持终端和浏览器客户端。 ArcInfo 工作站和ArcGIS桌面规范 ArcInfo和ArcGIS桌面平台需求包括一个Pentium 4级别的处理器(当前的处理器是Intel Xeon 3200+)和512M的物理内存和20GB SCSI硬盘(40GB硬盘将为大型的工程文件提供额外的本地存储)。最小17-inch的显示器(对于重量级用户推荐使用20-inch)。视频显示卡应该有32MB的显存,支持最小1280 ESRI白皮书 8. 性能评估工具 系统设计策略 ×1024分辨率和真彩色显示(对于3D用户,额外的显存将提供更高的分辨率和更好地显示效果)。平台还应该包括一个CD ROM,1.44MB的软驱和10/100Mbps的Ethernet网卡。还包括Windows操作系统。 ArcObjects Engine定制客户工作站规范 由ArcGIS 9 ArcObjects Engine开发环境开发的小型的定制应用程序可以由Intel Xeon 2400平台(当前处理器是Intel Xeon 3200),256MB内存(推荐使用512MB),和20GB SCSI硬盘(40GB硬盘将为大型的工程文件提供额外的本地存储)所支持。最小17-inch的显示器(对于重量级用户推荐使用20-inch)。视频显示卡应该有32MB的显存,支持最小1280×1024分辨率和真彩色显示(对于3D用户,额外的显存将提供更高的分辨率和更好地显示效果)。平台还应该包括一个CD ROM,1.44MB的软驱和10/100Mbps的Ethernet网卡。还包括Windows操作系统。 图8-13对当前Windows平台环境提供了一个性能概览。它明确了为ArcInfo Workstation、GIS浏览工作站(ArcView GIS和MapObjects应用程序)和Windows终端客户(包括Web浏览器客户端)推荐的性能门槛。 图8-13 工作站平台推荐 8.6.2 应用程序计算服务器 应用程序计算服务器支持主要的ArcGIS应用程序的执行。这个平台能够被用来作为一个用户工作站,也可以用作一大批使用终端客户端进行显示与控制的用户的一个计算平台。 由一个特定应用程序计算服务器平台支持的并发用户总数可以通过已公布的SPECrate_int2000性能等级除以相关的SPECrate_int2000性能基准平台等级,并且乘以代表一个文件数据源的权重6,和代表一个ArcSDE数据源的权重7.5的计算而得到。这样就可以确定能够被每个候选平台支持的用户数量。 ESRI白皮书 8. 性能评估工具 系统设计策略 一旦每个候选平台所支持的用户数量被确定,就可以基于软件规范建立内存需求。对于ArcGIS桌面时段,第一个用户的物理内存需求大约是512MB,以后每增加一个用户,内存需求相应的增加256MB。 Windows Terminal Servers. 对于Windows Terminal Servers,这里可以提供两张表格来支持其配置推荐。图8-14提供了当访问一个文件数据源时,配置微软的Windows Terminal Servers的通常指导原则。 图8-14 Windows Terminal Servers性能评估工具(文件服务器数据源) 图8-15提供了当访问一个单独的ArcSDE数据源时,Windows Terminal Servers的推荐配置。使用一个单独的ArcSDE数据源的应用程序服务器将卸载对ArcSDE服务器的查询处理,并且作为结果,能够维持每个CPU七到八个ArcInfo用户的性能水平。由同一应用程序服务器支持的额外用户将会导致应用程序性能的降低。 这些表格可以被用作选择合适的平台CPU和物理内存的一个快速指南。内存和性能的需求是由高峰并发用户来决定的。平台应该根据支持高峰用户性能需求所需的CPU数量来进行配置,因为即使在系统设计中性能的损失被正确的估计,用户也会感到非常失望。 新技术可以超越Arc04的性能水平而支持更高效的用户生产能力。高峰平台性能可以在同一水平通过Intel Xeon 2-CPU 3200-MHz平台的显示而达到。在达到高峰的用户能力后,性能就会缓慢的下降到Arc02性能水平,这时平台线就与Arc02性能线相交。 图8-15 Windows Terminal Servers性能评估工具(ArcSDE数据源) ESRI白皮书 8. 性能评估工具 系统设计策略 8.6.3 互联网Web服务 ESRI的Web服务提供了相应技术通过内部企业环境或者公共互联网来向浏览器客户端发布地图产品。这个Web站点包括了支持Web服务的许多组件。这些组件能够被安装在一个单独的平台上,或者配置在分离的平台,来取得最佳的性能和高效的适用性。对于ArcIMS和ArcGIS Server结构和性能评估模型的完整讨论将在第七节中阐述。 图8-16为ArcIMS和ArcGIS Server提供了性能评估推荐方案。 图8-16 ArcIMS/ArcGIS Server 性能评估 ESRI白皮书 8. 性能评估工具 系统设计策略 在性能表格中包括的典型平台显示了当前的性能。地图服务器平台是由表格上的水平线来表示(基于它们的SPECrate_int2000性能基准)。在同一平台上的ArcGIS Server (AGS)和Web应用程序服务器支持的最高负载为4000TPH,AGS服务器容器机器(container machine)支持的最高负载为6000TPH,ArcIMS地图服务器支持的最高负载为12000,对于Arc04基准而言。为这些平台所建立的性能基准是基于Intel Xeon 2-CPU 3200-MHz的服务器性能(Arc04的单个CPU性能是双处理器服务器性能的50%)。 图8-17确定了ArcIMS和AGS相等数据的服务器负载。这个表格是在源数据位于一个单独的数据服务器平台而要求的。从表格的左边可以键入所需的高峰事务处理率(每小时的地图请求)。相等的数据服务器负载在水平轴线上提供,它是由高峰事务处理率线与表格上合适的服务线相交而得到的。 图8-17 ArcIMS/AGS数据服务器处理负载 ESRI白皮书 8. 性能评估工具 系统设计策略 ArcIMS/AGS内存需求。平台的内存需求通常是为了支持在物理内存中所需的可执行程序的数量而建立的。在高峰运行期间,可执行程序的内存分页应该被最小化。当没有足够的物理内存来支持所需的可执行程序的时候,就需要内存分页。可执行程序必须被交换到硬盘来为处理需求腾出空间。这个额外的可执行程序负载对于整个处理工作流程来说是个负面的影响,并且使用了对程序的执行没有贡献的CPU循环。对于当前许多的操作系统而言,物理内存的一定份额是用作数据的高速缓存,以追求最佳的数据处理过程。当大量的内存需要被用来保留内存里的代码的时候,可执行程序就可以被交换到硬盘。在高峰处理负载期间,应该保证足够的物理内存来使可执行程序的内存分页达到最小化。 ArcIMS地图服务器内存需求主要是由支持发布服务所需的空间服务器数量驱动的。每个发布的地图服务连接都在地图服务器上建立,尽管这些数据库连接相对于空间服务器的容量而言相对较小。其物理内存的需求大约是支持部署的空间服务器处理所需的两倍。 ArcGIS Server容器机器的内存需求主要是由支持高峰工作流而发布的服务器对象容器的数目来驱动的。每个服务器配置都需要专门的SOC例程,并且足够的例程必须被配置,以支持高峰事务负载。低隔离的SOC配置需要较少的内存,允许在同一个容器机器上部署更多的SOC可执行程序之前,每个SOC能够支持四个例程。 图8-18确定了推荐的ArcIMS和AGS物理内存需求 ESRI白皮书 8. 性能评估工具 系统设计策略 图8-19可以被用来将在一个平台上量测到的地图服务速率转化为在另一个平台上期望的服务速率,它是基于已公布的相对性能基准。比如,在Intel Xeon 2400-MHz平台上的一个地图服务速率为0.45秒,在一个Pentium III 900-MHz平台上则大约需要1.2秒,在一个SunFire 280R 1200-MHz平台上需要0.35秒。 图8-19 ArcIMS地图服务时间 ESRI白皮书 8. 性能评估工具 系统设计策略 8.6.4 GIS数据服务器性能评估(ArcSDE和文件服务器) 数据资源是支持GIS运行的最大的并且是最有价值的资产。GIS应用程序提供了相应的工具来支持GIS数据的管理与分析。对于GIS系统设计而言,GIS数据资源的配置和定位是首要的考虑因素。 可以被用来支持GIS数据资源的数据格式和存储策略有许多种。对于单独的GIS工程或者研究,数据可以被存储在本地工作站或者应用程序服务器上的用户目录里面。共享的GIS数据资源通常都位于一个GIS文件服务器或者ArcSDE DBMS服务器上。企业级数据服务器通常是由一个ArcSDE DBMS服务器所支持的。Web服务可以由在ArcIMS空间服务器或者一个中央文件服务器或者ArcSDE DBMS服务器上复制的数据来支持。 数据的位置将会影响系统的性能。位于一个数据服务器上的数据必须被通过网络传递到应用程序来支持处理过程(在应用程序处理平台与GIS数据源之间的推荐带宽最小为100Mbps)。当使用一个文件数据源或者支持更大型的ArcSDE服务器客户端环境的时候,就需要更大的带宽性能。当数据是本地存储或者位于一个文件服务器的时候,GIS应用程序将支持查询处理。对于位于ArcSDE DBMS的数据,ArcSDE服务器将支持查询处理。 数据服务器的性能评估表可以为工作组和企业级环境提供。所有的这些表格都是基于同一的性能评估模型,并且能够被用于选择文件服务器或者ArcSDE数据服务器。对于应用程序访问位于本地磁盘上的数据,没有额外的性能上的降低(这是由应用程序服务器和工作站性能表格所支持的)。 GIS数据服务器为GIS空间数据和相关的服务器处理提供了一个环境。GIS数据服务器必须被正确的配置以支持并发客户的最大数量。此外在性能评估分析中,任何其他的在服务器平台上运行的处理过程也必须被考虑进去。 由一个特定的GIS数据服务器平台支持的并发GIS客户端总数可以通过已公布的SPECrate_int2000性能等级除以相关的SPECrate_int2000性能基准平台等级,并且乘以代表一个权重30的计算而得到。这样就可以确定能够被推荐的候选平台配置支持的用户最大数。 ESRI白皮书 8. 性能评估工具 系统设计策略 在一些配置中,GIS数据服务器也能够支持额外的应用程序或者服务器处理过程。在确定服务器上的总共计算负载的时候,这些额外的处理过程必须被包括进去。在服务器上运行的额外的客户端应用程序处理过程(ArcInfo或者ArcViewGIS)与五个数据服务器客户端大约占用相同的CPU资源。在服务器上运行的任何批处理都将会消耗一个CPU,与支持30个数据服务器客户端所需的资源相等。这些调整可以被用来估计相等的并发GIS客户端的总数。 图8-20显示了针对专门的GIS数据服务器性能评估的内存和性能指南。这些表格可以被用作评估GIS数据服务器的一个快速指导。 图8-20 工作组数据服务器性能评估(ArcSDE和文件服务器) ArcSDE数据服务器提供了客户端/服务器的数据管理,并且与标准的商业DBMS产品解决方案集成。ArcSDE提供了在服务器平台上的GIS事务管理,并且支持与GIS客户端应用程序之间的网络通讯。ArcSDE服务器应该进行正确的配置来支持高峰的并发ArcSDE客户端数目。此外在性能评估分析中,任何其他的在服务器平台上运行的处理过程也必须被考虑进去。 ArcSDE解决方案是由一系列DBMS平台所支持,包括Oracle,Informix(集成在Informix Spatial Datablade中),DB2(与DB2 Spatial Extender集成),和微软的SQL Server。客户端与服务器之间的通讯是由ArcSDE应用程序编程接口(API)所支持。所有的空间与属性数据都存储在DBMS重。标准的DBMS管理与性能调优特征都可以应用到空间与属性数据。一个可选的DBMS直接连接选项可用于支持在客户端的ArcSDE处理负载和使用DBMS网络客户端与DBMS服务器的通讯。 内存需求的确定可以支持标准的DBMS和ArcSDE服务器处理,并且应该随着支持规划中的数据高速缓存需求而增加。增加的内存高速缓存能够极大的提高服务器的性能。这些表格可以被用作评估GIS数据服务器的一个快速指南。 ESRI白皮书 8. 性能评估工具 系统设计策略 图8-21 企业级数据服务器性能评估(ArcSDE和文件服务器) 在支持企业级ArcSDE服务器环境中,数据存储的重要性不断增长。存储的需求已经从Gigabytes在最近的几年内增长到Terabyte的级别,并且数据存储的需求随着空间数据资源的增长而继续增长。在初始硬件成本和整个的管理成本中,发现存储方案的成本超过企业级服务器的成本是非常平常的现象。 在选择合适的存储方案的时候,一些基本的考虑因素必须被包括。标准的存储实践推荐DBMS索引和位于一个分离的硬盘上的数据文件的存储。微软的SQL Server推荐使用RAID5(数据分段与奇偶校验磁盘)容量上的索引和数据文件来定位位于一个RAID1镜像磁盘对上的SQL log文件。Oracle 则推荐了更加强烈的位于RAID1,0存储(镜像和数据分段)和RAID5上的数据表中的索引和log表。对于最佳操作而言,RAID5容量应该在5(4+1)或者9(8+1)磁盘容量(5磁盘的RAID5支持最高级别的高峰性能)收到支持。图8-22对存储的推荐方案进行了总结。 图8-22 ArcSDE存储的最佳实践 ESRI白皮书 8. 性能评估工具 系统设计策略 许多因素对于磁盘的存取性能有影响。数据分段以及阵列式的数据高速缓存可以提高数据存取的性能。在阵列中(有许多并发的客户端查询)的磁盘能够导致磁盘冲突(输入/输出的性能瓶颈)的几乎没有。小型的数据库环境加上大量的高峰用户负载是最有可能导致磁盘冲突的。作为一个工人的原则,最小值为5磁盘的RAID5阵列应该能够支持ArcSDE数据文件。 8.7 平台选择标准 在支持正确的硬件选择的时候,有许多因素必须被考虑进去。这些因素包括下列内容: 平台性能 平台必须被正确的配置来支持用户的性能需求。确定正确的平台配置是基于性能需求,ESRI的设计模型为正确的硬件平台选择建立一个坚实的基础。 购买价格 硬件的成本根据厂家选择和平台配置的不同而有所差异。价格应该是基于对硬件平台和相等的性能指标的评估。 系统的支持能力 客户必须基于厂家的承诺和以前支持厂家技术的经验来对系统的支持能力进行评估。 厂家关系 在支持一个复杂的系统部署的时候,与硬件厂家之间的关系应该是一个很重要的考虑因素。 总共的生命周期的成本 系统的总共成本是由许多因素决定的,包括现有的客户对相似的硬件环境的管理,硬件的可靠性和可维护性等。客户必须基于对以前支持厂家技术的经验和对厂家有关产权声明的评估来评价这些因素。 在硬件源选择期间建立特定的硬件平台目标将会提高整个硬件选择过程的质量。正确的系统结构设计和硬件选择将为成功的进行系统部署提供一个坚实的基础。 ESRI白皮书 9. 系统实施 系统设计策略 9 系统实施 成功的系统实施需要优秀的领导才能和细致的规划步骤。对于系统的每个组件有一个很好的理解在进行一个实施策略中是十分关键的。企业的IT环境涉及到一系列厂家的技术的集成。在IT环境内部,互操作标准是自愿的,所以在集成过程中的每一个环节,即使是最简单的技术集成也必须被确认。 企业级GIS环境包括一个很大范围的技术集成。当今绝大多数环境都包括多种硬件厂家技术,包括数据库服务器、存储局域网络、Windows Terminal Servers、Web服务器、地图服务器和桌面客户端,他们都由一个广阔范围的局域网、广域网和互联网通讯连接起来。所有这些技术都必须在一起正常的运转来支持一个均衡的计算环境。一大批的软件厂家技术包括数据库管理系统、ArcGIS桌面和服务器软件、Web服务、和硬件操作系统,他们都与现有的应用程序相集成。数据和应用程序被添加到这个集成化的基础设施环境中,来支持最终的实施。其结果是一个非常大型的技术混合包,它必须正确并且有效的协同工作,来支持用户工作流程的需求。 随着多年来接口标准的日益成熟,分布式计算技术的集成与实施已经变得越来越容易。在这同一时期内,企业环境也变得更大,更复杂。与一个企业系统部署相关的复杂性与风险也与支持最终的集成化解决方案的多种厂家组件直接相关。使用一个单独的数据库环境的集中式计算解决方案是最为简单的实施与支持环境。而使用多数据库环境的分布式计算系统将会变得非常复杂,并且难以部署和支持。许多组织正在巩固它们的数据资源和应用程序处理环境,来降低实施的风险和提高对企业级业务环境的管理支持。 9.1 GIS人员 优秀的领导起源于合适的人员组成。成功的企业级GIS部署通常是由一个执行企业主办人来支持,并且GIS经理应该向管理高层汇报。 图9-1显示了一个传统的GIS组织结构。企业级GIS的运行是由一个执行委员会支持,它具有为GIS用户群制定财政和政策决定的影响力和权力。技术协调委员会的职责在于提供技术指导和领导。工作组也进行了分配,通常都是针对每个技术学科,来指导机构性的议题和汇报系统的状态。用户群应该通过整个的了解过程来体现。 图9-1 传统的GIS组织性结构 ESRI白皮书 9. 系统实施 系统设计策略 一个正式的组织性结构为建立和维护企业级GIS的成功运行所需的长期支持提供了一个框架。这个基本的组织结构在管理从小到大的机构都是非常有用的,并且同样类型的组织性结构在管理社区性GIS运行中也十分的有效。 对于支持GIS的成功运行,需要许多的技术学科。图9-2对支持企业级GIS运行所需的功能性职责提供了一个概述。 图9-2 GIS功能性职责 ESRI白皮书 9. 系统实施 系统设计策略 这些职责的复杂性是随着每个单独的GIS实施的大小和范围而有所不同的,尽管每个机构在这些领域中的每一方面都需要一定层次支持和专家知识。 每个机构的GIS管理人员都需要一个专门的人员来支持集中式的GIS运行。在一些小型企业中,GIS部门的成员往往扮演着多种角色。在大型机构中,这些职责就会变得更加专门化,并且扩展到支持额外层次的协调和支持活动。大型企业的运行会很需要额外的GIS支持人员,他们在不同的业务单元管理级别进行报告。 图9-3 GIS人员推荐 ESRI白皮书 9. 系统实施 系统设计策略 9.2 训练高素质的员工 培训可用于帮助发展高素质的员工和支持GIS用户的生产能力。单位首先应该保证它们的团队能够受到所需的培训。图9-4提供了推荐的ESRI培训教程的纲要,它是为支持所需人员功能的资格而建立的。 图9-4 培训机会 ESRI白皮书 9. 系统实施 系统设计策略 9.3 系统结构部署策略 规划通常是支持一个成功的系统部署的第一步。一个系统设计团队应该首先了解当前的GIS和硬件系统技术,了解用户的需求,并且基于用户工作流程的需要而建立一个系统设结构的设计。为了确定整个的实施目标,应该制定一个部署计划表。 图9-5 GIS系统部署策略 ESRI白皮书 9. 系统实施 系统设计策略 阶段化的实施策略可以极大的降低实施的风险。计算技术继续以一个十分迅速的速度发展着。集成的标准也随着技术而不断变化,并且尚无把握来支持立即的系统部署需求。每天都有新的想法被引入到市场,这些想法的一小部分将会发展成为可靠的长期的产品解决方案。以下推荐的最佳实践可以用来支持企业级GIS的成功实施。 试验阶段 显示为最终的系统解决方案规划的所有关键的硬件组件 使用已经被证明的低风险的技术方案来支持整个的实施 进行测试来降低不确定性和实施的风险 为初始的生产阶段而进行硬件方案的资格鉴定。 初始生产阶段 直到试验阶段被最终认可再开始工作 部署初始的生产环境 使用在试验阶段被确认的技术方案 展示GIS解决方案的早期成功和回报 确认机构已经准备就绪并且具有相应的支持能力 确认初始的培训项目和用户的操作 为最终的实施进行更高级别的方案鉴定提供机会 ESRI白皮书 9. 系统实施 系统设计策略 最终的实施阶段 直到初始生产阶段被最终认可再开始工作 为了解决问题可以在一个合理的间歇期间规划一个阶段性的首次展示 使用在上一阶段被确认的技术方案 优先考虑首次展示的时间来支持早期的成功 9.4 系统测试 正确的测试行为对于实施的成功由重要的贡献。在初始试验阶段,对于新技术的功能性组件和系统集成测试应该被实施。而性能的测试应该等到初始生产阶段开始再进行。 图9-6确定了为规划和指导功能性系统测试而进行的最佳操作。 图9-6 功能性系统测试的最佳操作 对于将要被集成到生产系统的所有新技术都应该完成功能性系统测试。测试计划应该被正确的制定,来确定测试需求,建立配置控制(软件版本、操作系统环境)和提供测试程序。测试应该在生产部署之前完成。测试应该在将要被部署到生产环境中的软件版本和操作系统的使用指导下进行。 图9-7确定了一些与系统性能测试相关的警告与提醒。 图9-7 性能测试隐患 ESRI白皮书 9. 系统实施 系统设计策略 系统测试非常的昂贵并且会有误导的可能。初始的系统部署通常需要被调试和优化来达到最终的性能目标。系统性能瓶颈通常可以在初始部署阶段就能被确定和解决。早期的应用程序开发主要针对于功能上的需求,并且系统的调试会一直进行到最后的发布阶段。实际的用户工作流程环境非常的难以模拟,所以测试环境很少能完全复制正常的企业运行。 与小学的科学展览工程一起引进的科学方法展示了基本的最佳操作,它可以直接应用到系统性能的测试中。性能测试只应该被指导去进行一个假想(你认为你知道的某件事物)的验证。一个性能测试的主要目标是证实这个假想(确认你所知道的东西)。只有当它证明了这个假想(测试不会教你不知道的东西),测试才是成功的。 初始的性能测试结果经常是不能支持测试前的假想。随着更加深入的分析与调查,那些改变测试结果的测试瓶颈或者不正确的假想被一一证实。只有当它证明了测试假想,性能测试才是成功的。 性能测试在初始的生产部署阶段能被最好的指导。在这一阶段,执行真实工作流程的真实用户能够产生一个真实的用户环境。在初始部署阶段,关键的系统组件应该被监测,以便确定处理瓶颈和解决系统冲突。初始部署的确认应该包括确认用户的工作流程性能需求都已经被满足。 9.5 系统实施管理 基本的项目管理实践可以提升实施的成功。项目团队应该被建立,每个成员应该被分配特定的职责,任务计划应该被指定来支持实施计划,配置控制计划和变化控制过程应该被建立,并且一个实施计划表应该被公布,来支持项目的部署里程标。 一个系统结构设计能够为建立一个实施计划提供框架。在最终完成硬件厂家解决方案的选择后,应该制定实施计划。图9-8提供了一个典型的系统部署计划表。特定的决策里程标应该包括在计划表中,并且每个主要的任务都应该被清晰的确定。为了保证所有的任务都会被很好的定义,每一个参与者都对他们的职责由一个清晰的理解,应该安排一个实施项目经理。对于每个实施的任务,都应该有一个清晰的认可标准集合。随后就应该有一个正式的认可过程,来确保集成中的问题都能够尽可能早的被确定和解决。 ESRI白皮书 9. 系统实施 系统设计策略 图9-8 系统集成管理 9.6 系统调试 系统调试在最终的系统集成和部署中是十分关键的环节。初始的用户需求规划是开始性能调试的第一个机会。繁重的批处理作业应该从交互式的用户工作流程被分离出来,而通过一个单独的批处理队列进行支持。系统备份和繁重的处理工作负载应该在非高峰工作流期间就被规划好。系统组件性能的规律应该在一个周期性基础上进行监测,特别是在高峰工作流时期,以便于确定性能瓶颈和解决系统缺陷。图9-9提供了一个支持企业级GIS环境的组件的概述。任何组件都有可能在整个系统性能的平衡中引入一个薄弱环节。 图9-9 系统性能因素 ESRI白皮书 9. 系统实施 系统设计策略 9.6.1 ArcIMS服务器性能调试 在ArcIMS结构中,有许多变量能够被量测和更改,来提高站点的性能。图9-10确定了相关的性能量测方法和在调试一个ArcIMS配置中可用的配置变量。 图9-10 Web地图服务性能概况 图9-11确定了你能够量测的事物,以及你如何更改ArcIMS地图服务或者组件变量来优化站点的性能。 ESRI白皮书 9. 系统实施 系统设计策略 图9-11 Web地图服务性能调试指南 9.6.2 ArcSDE性能调试 ArcSDE数据库为支持企业环境的客户端和Web服务提供了数据源。在ArcSDE服务器上的性能问题能够影响整个系统环境。图9-12提供了一个在调试ArcSDE数据库环境的时候应该考虑的因素的概况。 图9-12 ArcSDE性能调试 ESRI白皮书 9. 系统实施 系统设计策略 一些数据库性能因素直接与工作流程管理、初始的数据库设计和版本管理方法相联系。其它的性能问题可以通过重新构建数据库索引、在长事务处理期间使用编辑缓存、或者监测性能或表格统计值来进行解决,以支持实时的数据管理和维护功能。在所有的案例中,得到一个合格的数据库DBA的支持非常的重要,它可以支持标准的性能调试和数据库环境的管理。 9.7 业务连续计划 每一个机构都应该在它们的系统环境中仔细的估计潜在的事故情境,以及面对这样的事故如何保护关键的业务资源。企业级GIS环境需要在GIS数据资源上进行重大的投资。这些数据资源必须在物理灾难导致的系统事故的事件中得到保护。为了避免这些潜在的事故情境,需要制定业务恢复计划。图9-13提供了不同系统备份策略的概况。一个业务连续计划应该被正确的制定,来解决在一个系统事故或者灾难恢复的事件中特定的机构性需求。 图9-13 业务连续计划 ESRI白皮书 9. 系统实施 系统设计策略 9.8 管理技术变化 企业级GIS的运行需要对策略规划和连续的技术投资进行结合。技术的变化日新月异,那些没能很好的应对这种变化的机构将在生产能力和运行成本管理方面落后于时代。管理技术变化是一个很重要的IT挑战。 企业的运行应该包括一个周期性的协调的系统部署。在每一个周期,规划和技术评估应该在技术部署之前进行,并且这些努力应该于支持运行的部署需求相统一。图9-14确定了为技术变化管理而制定的一个概念性的系统结构规划与部署策略。 图9-14 系统结构设计策略规划 ESRI白皮书 9. 系统实施 系统设计策略 规划与评估 规划工作应该建立在一个周期性循环的基础上,与支持机构的运行与预算规划需求相适应。策略计划应该被及时更新来支持一个多年的部署策略,并且在一个周期性基础(通常为一个年度)之上发布。 规划和评估过程应该包括一个需求评估(策略计划的更新),技术更新(培训与研发),需求分析(过程和需求了解),测试和评估(评估新技术的可选方案),和原型验证(试验测试项目)。具体工作应该被规划在计划表上,来支持每年度的系统部署更新周期。 系统部署 运行的系统更新计划应该基于一个循环周期来制定,计划包括从规划到评估项目的整个实施验证的运行性提升。系统部署阶段应该包括初始的实施(在一个运行性测试环境中实施变化),来支持部署的认可。项目应该包括在一个循环周期(通常为一个年度)为新技术的获取和部署而制定的计划报表。所有的生产系统更新都应该为了支持正在进行的运营而进行规划和制定。 9.9 结论 成功的实施依靠一个良好的,坚实的设计,正确的硬件和软件产品的选择,成功的系统集成,和在安装阶段细致的、不断的评估。使用阶段性的方法进行实施可以减少项目的风险和提高成功的机率,为早期的成功提供机会,并且提供了在最终系统传递之前低风险的融入新技术的灵活性。指南可用于支持一个成功的系统设计,甚至是大型的复杂系统。最终的购买决策收到运营的需求和预算限制的影响,为系统设计引入了唯一的挑战。 图9-15提供了过去的12年ESRI公司在支持GIS系统实施方面的学习课程。良好的领导,高素质的员工,和已经被证实的标准的实践将带来成功的部署。 图9-15 系统实施学习课程 ESRI白皮书 9. 系统实施 系统设计策略 ESRI白皮书 附件A 系统设计策略 附件A 系统结构设计咨询服务 A-1 代理级系统结构设计 这项服务最适合于拥有许多组织的大型代理机构,他们为了支持集成化的代理级别的GIS运行,需要在建立一个特定的系统结构策略方面得到咨询支持。所有的组织都应该在系统设计过程中得到体现。对于这项工作,一个当前的用户需求评价和用户部署目标的清晰理解是一个先决条件,并且作为所需的一个输入条件融入到系统结构设计过程中去。 A-2 企业级系统结构设计 这项服务最适合于拥有许多部门或工作组的大型机构,他们为了支持企业级GIS部署的需求,需要在建立一个特定的系统结构策略方面得到技术支持。所有的部门都应该在系统设计过程中得到体现。对于这项工作,一个当前的用户需求评价和用户部署目标的清晰理解是一个先决条件,并且作为所需的一个输入条件融入到系统结构设计过程中去。 A-3 部门级系统结构设计 这项服务最适合于小型机构或工作组,他们为了支持GIS部署的需求,需要在建立一个特定的系统结构策略方面得到技术服务。GIS拥护和IT工作人员都应该在系统设计过程中得到体现。对于这项工作,一个当前的用户需求评价和用户部署目标的清晰理解是一个先决条件,并且作为所需的一个输入条件融入到系统结构设计过程中去。 A-4 系统结构设计维护 这项服务是为了一个客户的企业范围的GIS所作的维护当前的系统结构设计的推荐。为了更好地使用这些服务,客户必须拥有一个由ESRI公司准备的系统设计结构策略计划,它作为一个先决条件来支持这项设计维护咨询工作。 A-4 ArcIMS结构设计 这项服务最合适于那些为了支持它们的ArcIMS部署需求而在建立一个特定的系统结构策略方面需要技术支持的机构。对于这项工作,一个当前的业务需求评价和对Web服务部署目标的清晰理解是一个先决条件,并且作为所需的一个输入条件融入到系统结构设计过程中去。 A-5 系统结构设计评价 这项服务最合适于那些为了支持它们的企业级GIS或者ArcIMS环境而在建立一个及时的、特定的系统结构策略方面需要技术支持的机构。对于这项工作,一个对GIS运行的工作流程需求的清晰理解是一个先决条件,并且作为所需的一个输入条件融入到系统结构设计过程中去。 ESRI白皮书 附件A 系统设计策略 下表中的这些数字提供了一个对由ESRI系统集成部支持的标准的系统结构设计服务的概况。提供高品质的支持你的需求来增进你的成功,是我们都目标。为了解决我们用户的特定的需求,我们提供范围广阔的服务。 系统结构设计服务 ESRI白皮书 附件B 系统设计策略 附件B GIS系统结构设计(课程概况) GIS系统结构设计 ESRI白皮书 附件B 系统设计策略 概述 这个为期两天的课程为开发成功的GIS设计和实施技术介绍了一个已经被证明的系统结构设计方法。这种方法经过多年的成功的ESRI系统设计咨询工作而被开发和测试。这门课程的主要目标是分享这种方法来帮助用户提高现有和未来GIS环境的性能。对于系统设计模型和配置方法的讨论将为课程的参与者提供一个已经被证明的方法来进行成功的GIS解决方案的制定。讲座和第一手的经验将帮助那些负责GIS系统结构决策的人士选择一个合适的系统设计,来支持GIS的用户性能需求。 听众 《GIS系统结构设计》将适合那些负责开发和维护硬件或者软件系统设计,和那些负责支持软件或者应用程序开发和技术市场,为了客户解决方案进行系统设计、测试和配置的人士。它也为进行支持和保证GIS硬件或软件方案的人员提供了一个优秀的概念框架。高级结构咨询人员将从展示的GIS设计方法中获益,同时GIS管理人员也将会对系统结构和硬件选择标准有一个更好的理解。 目标 理解可用于支持成功的GIS解决方案的关系。 了解ESRI软件解决方案在一个发展的GIS环境中适用的地方。 学习如何在一个分布式企业环境中如何集成ESRI软件。 学习如何提供高性能的远程用户访问需求。 学习如何将现存的数据源与GIS应用程序集成。 理解必须在选择硬件方案之前完成的先决条件和建议。 学习如何确定用户的位置和现有的网络通讯。 学习如何总结用户需求来支持系统结构设计。 确定影响应用程序性能的系统组件。 学习如何确定Windows和UNIX平台的相对性能。 应用实际的性能评估模型来选择集中式应用程序和数据服务器。 学习实际的网络通讯设计指南。 理解指导一个系统设计评价和分布式GIS软件方案的过程。 涉及的议题 系统设计策略 GIS软件解决方案 网络通讯 GIS产品结构 GIS用户需求 系统性能评估基础 系统性能评估工具 系统实施 ESRI白皮书 附件B 系统设计策略 先决条件与建议 注册人员应该对于理解GIS产品结构和当今的计算技术如何能够支持成功的GIS解决方案有浓厚的兴趣。浏览《系统设计策略》白皮书也会很有帮助。请访问www.esri.com/library/whitepapers/pdfs/sysdesig.pdf. 花费 $850(两天) 课程可以在一个客户端设备(可以多达12个参加者)上进行在线教学,固定价格为$6,650。对于美国联邦政府和具有资格的教育机构、图书馆和博物馆有特殊的优惠价格。欲知详细的资格要求,请与ESRI培训中心联系。价格可能会在没有通知的情况下有所变动。对于少于三天的在线培训,在总费用的基础上增加500美元。 课程大纲(GIS系统结构设计) 第一天 系统设计过程 什么是系统结构设计 系统结构设计的重要性 系统设计过程概述 支持技术概述 系统设计支持工作 GIS软件解决方案 概述 GIS工作站 局域网 远程访问客户端 Web地图产品 分布式数据方案 GIS转移策略 ArcInfo许可证管理 GIS高适用性解决方案 复习与疑问 网络通讯 GIS网络的影响 网络类型 客户端/服务器通讯 客户端/服务器性能 网络配置指南 网络技术概述 网络性能评估练习 GIS产品结构 GIS的多层结构 GIS应用软件 (ArcInfo, ArcView GIS, MapObjects) 数据管理解决方案 (GIS文件服务器,ArcStorm,空间数据库引擎) 远程访问解决方案 (UNIX应用程序服务器,Windows Terminal Servers,互联网地图服务器) 复习与疑问 GIS用户需求 整体的GIS环境 应用需求评价 系统结构概况 用户需求评价 WAN通讯概况 用户应用需求 配置策略 选择一个系统方案 确定平台负载 项目设计练习 第二天 系统性能评价基础 系统性能概况 性能测试 客户端/服务器模型 批处理性能 终端服务器性能GIS 数据服务器性能 Web服务 系统性能评估工具 GIS性能历史 我们如何应对变化? ESRI白皮书 附件B 系统设计策略 SPEC基准集合 平台性能表格 GIS工作站 应用程序服务器 互联网地图服务器 文件服务器 SDE服务器 平台厂家选择 平台性能评估练习 系统实施 阶段性实施 项目管理 安装计划报表 所学课程 将所学内容集中在一起 系统设计练习 系统设计概况 用户需求评价 系统结构解决方案 平台性能评估 平台厂家选择 网络设计规范 ESRI白皮书

下载文档,方便阅读与编辑

文档的实际排版效果,会与网站的显示效果略有不同!!

需要 5 金币 [ 分享文档获得金币 ]
0 人已下载

下载文档

相关文档