云赋能GEOSS信息交换中心:部署、挑战与优势
1. GEOSS信息交换中心概述
1.1 背景
地球观测(EO)系统每日会产生大量数据,这些数据为地球提供了特定时间快照、轨迹和事件的基线数据,对农业、生物多样性、气候等多个社会受益领域(SBAs)具有重要价值。为了管理、整合、访问和共享全球EO数据,相关组织建立了全球地球观测系统(GEOSS)通用基础设施(GCI)。而GEOSS信息交换中心(CLH)则是驱动整个GCI的核心引擎,它由乔治梅森大学的智能空间计算中心(CISC)与美国地质调查局(USGS)合作开发和维护。CLH通过采集机制从多个数据源收集EO数据的元数据,并提供本地和远程搜索功能,为EO数据提供者和GEOSS终端用户搭建了桥梁。
1.2 挑战
在开发CLH时,面临着以下几个主要挑战:
- 大数据问题 :
- 数据量(Volume) :GEOSS是一个全球性系统,包含大量来自广泛分布的目录的EO数据元数据。截至2013年1月,已有104个目录和120,000条元数据记录注册到CLH,且数据量还在迅速增长。
- 数据更新速度(Velocity) :数据集和元数据需要频繁更新。
- 数据多样性(Variety) :元数据格式/标准(如FGDC CSDGM、Dublin core和ISO - 19139)和访问协议(如CSW、SRU和RSS)各不相同。
- 时空搜索和全文搜索 :搜索功能是CLH最重要的功能,但由于数据量巨大,且每条记录包含时空和文本信息,要提供高性能的搜索功能并非易事。时空搜索和全文搜索的结合会显著增加计算复杂度。
- 并发访问 :随着分布式地理信息处理的发展和Web及无线设备的普及,大量终端用户会同时访问地理空间系统,这给CLH的硬件和软件带来了巨大压力,可能导致响应时间过长。
为应对这些挑战,可利用亚马逊网络服务(AWS)的云服务优势,如具有可扩展计算能力的Amazon EC2和具有高I/O和可扩展机制的稳定弹性块存储(EBS),使CLH能够有效处理高峰时段的并发访问。
2. 部署与优化
2.1 一般部署工作流程
将CLH部署到Amazon EC2的一般步骤如下:
1. 授权网络访问 :打开适当的端口以授权网络访问。例如,打开端口22以实现本地服务器与EC2实例之间的通信,打开端口80以允许通过Web浏览器访问CLH。
2. 启动实例 :由于CLH是一个由Tomcat托管并在带有空间数据库的Linux机器上运行的Web应用程序,因此选择带有PostgreSQL 8.4和PostGIS 1.5的公共亚马逊机器映像(AMI)来启动Amazon EC2实例。
3. 安装软件包 :安装并配置PostgreSQL/PostGIS和Tomcat。PostgreSQL/PostGIS用于存储CLH的空间元数据记录,Tomcat用于托管CLH。在安装PostgreSQL/PostGIS之前,需要安装依赖包,如Proj、GEOS和libxml。需要注意不同版本的PostgreSQL和PostGIS以及PostGIS和GEOS之间存在兼容性问题,这里使用带有PostgreSQL 8.4和PostGIS 1.5的Ubuntu AMI来启动实例,可节省安装时间。配置数据库后,可使用以下命令设置Tomcat:
root@ip - 10 - 189 - 149 - 104:/root$ cd /opt
root@ip - 10 - 189 - 149 - 104:/opt$ wget http://www.poolsaboveground.com/apache/tomcat/tomcat - 6/v6.0.26/bin/apache - tomcat - 6.0.26.tar.gz
root@ip - 10 - 189 - 149 - 104:/opt$ tar - zxvf apache - tomcat - 6.0.26.tar.gz
为使Tomcat正常工作,还需要安装和配置Java开发工具包(JDK)。
4. 传输CLH代码和数据 :具体传输大量数据到云的方法可参考相关资料。
5. 恢复数据库 :将CLH应用程序传输到实例并将数据恢复到数据库后,可使用以下代码恢复数据库:
root@ip - 10 - 189 - 149 - 104:/mnt$ chown postgres:postgres geoss.sql
root@ip - 10 - 189 - 149 - 104:/mnt$ su postgres
bash - 3.2$ createdb geonetwork
bash - 3.2$ psql geonetwork < geoss.sql
- 配置CLH的Servlet :创建一个虚拟用户“Tomcat”来运行Tomcat,并在
/etc/rc.local
文件中进行如下配置,使CLH在系统启动时自动启动:
sudo - u tomcat /opt/tomcat/bin/startup.sh
- 启动服务并定制应用程序 :如果数据库和Tomcat配置正确,启动Tomcat后,用户可以通过Web浏览器访问CLH。此外,还需要进行一些额外的定制,如设置远程搜索的URL和更改管理员密码。
- 配置负载平衡或可扩展性 :此步骤可选,但配置负载平衡和可扩展性可以使系统更加灵活和可扩展。
- 从运行的实例创建AMI :最后,可以基于运行的CLH实例创建新的AMI。
2.2 特殊考虑因素
2.2.1 数据备份
为了备份数据、日志文件和应用程序,可以将它们复制到单独的EBS卷中。使用EBS卷进行备份有两个好处:一是在当前实例崩溃时可以从该卷恢复CLH;二是卷的大小可以在1GB到1TB之间任意选择。创建和使用EBS卷的步骤如下:
1. 在Web控制台中创建一个无内容的EBS卷,并确保所选的EBS卷区域与CLH实例的区域相同。
2. 将卷附加到运行的实例。按照惯例,第一个挂载点使用 /dev/sdf
,如果要附加多个卷,则按字母顺序依次使用 /dev/sdg
、 /dev/sdh
等。
3. 登录到实例,将PostgreSQL数据分区移动到EBS卷。具体操作如下:
[root@ip - 10 - 189 - 149 - 104~] mkfs - t ext3 /dev/sdh # 制作文件系统
[root@ip - 10 - 189 - 149 - 104~] mkdir /mnt/datavol_1
[root@ip - 10 - 189 - 149 - 104~] mount /dev/sdh /mnt/datavol_1/
2.2.2 负载均衡
成功启动Amazon EC2实例后,可以为实例配置高级服务,如负载均衡。AWS提供负载均衡器来平衡多个EC2实例上的用户请求负载。由于CLH可能需要处理大量用户的并发请求,负载均衡服务有助于平衡系统的流量负载。在“网络与安全”部分,用户可以点击“负载均衡器”开始配置负载均衡服务。在使用负载均衡服务时,仅使用一份数据库副本,即所有实例将访问在第一个实例上配置的同一数据库。
2.2.3 自动扩展
地理空间应用程序的用户访问量可能会按小时、天或周发生变化,因此需要不同的计算能力来满足性能要求并降低成本。可扩展的EC2服务可以通过弹性满足计算需求来促进地理空间应用程序的发展。AWS提供自动扩展器来实现这一功能,云用户也可以通过Web控制台使用CloudFormation服务进行配置,还可以通过命令行进行配置,例如:
cfn - create - stack GEOSSClearinghouse -- template - file GEOSSClearinghouse.template -- region us - east - 1 -- awsaccesskey=FAKEKEY -- awssecretkey=FAKEKEY2 -- parameters="KeyName=GeoNet; InstanceType=m1.large"
无论使用哪种服务或工具来配置自动扩展功能,用户都需要设置一个模板。以下是一个示例模板:
{
"AWSTemplateFormatVersion": "2010 - 09 - 09",
"Description": "Create a load balanced, auto scaled CLH Web site.",
"Parameters": {
"InstanceType": {
"Description": "Type of EC2 instance to launch",
"Type": "String",
"Default": "m1.large"
},
"WebServerPort": {
"Description": "The TCP port for the Web Server",
"Type": "String",
"Default": "80"
},
"KeyName": {
"Description": "The EC2 Key Pair to allow SSH access to the instances",
"Type": "String"
}
},
"Mappings": {
"AWSInstanceType2Arch": {
"m1.large": {
"Arch": "64"
},
"m1.xlarge": {
"Arch": "64"
}
},
"AWSRegionArch2AMI": {
"us - east - 1": {
"64": "xxxxx"
},
"us - west - 1": {
"64": "xxxxx"
},
"eu - west - 1": {
"64": "xxxxx"
},
"ap - southeast - 1": {
"64": "xxxxx"
},
"ap - northeast - 1": {
"64": "xxxxx"
}
}
},
"Resources": {
"WebServerGroup": {
"Type": "AWS::AutoScaling::AutoScalingGroup",
"Properties": {
"AvailabilityZones": {
"Fn::GetAZs": ""
},
"LaunchConfigurationName": {
"Ref": "LaunchConfig"
},
"MinSize": "1",
"MaxSize": "3",
"LoadBalancerNames": [
{
"Ref": "ElasticLoadBalancer"
}
]
}
},
"LaunchConfig": {
"Type": "AWS::AutoScaling::LaunchConfiguration",
"Properties": {
"KeyName": {
"Ref": "KeyName"
},
"ImageId": {
"Fn::FindInMap": [
"AWSRegionArch2AMI",
{
"Ref": "AWS::Region"
},
{
"Fn::FindInMap": [
"AWSInstanceType2Arch",
{
"Ref": "InstanceType"
},
"Arch"
]
}
]
},
"UserData": {
"Fn::Base64": {
"Ref": "WebServerPort"
}
},
"SecurityGroups": [
{
"Ref": "InstanceSecurityGroup"
}
],
"InstanceType": {
"Ref": "InstanceType"
}
}
},
"CPUBasedTrigger": {
"Type": "AWS::AutoScaling::Trigger",
"Properties": {
"MetricName": "CPUUtilization",
"Namespace": "AWS/EC2",
"Statistic": "Average",
"Period": "300",
"UpperBreachScaleIncrement": "1",
"LowerBreachScaleIncrement": "-1",
"AutoScalingGroupName": {
"Ref": "WebServerGroup"
},
"BreachDuration": "600",
"UpperThreshold": "90",
"LowerThreshold": "75",
"Dimensions": [
{
"Name": "AutoScalingGroupName",
"Value": {
"Ref": "WebServerGroup"
}
}
]
}
},
"ElasticLoadBalancer": {
"Type": "AWS::ElasticLoadBalancing::LoadBalancer",
"Properties": {
"AvailabilityZones": {
"Fn::GetAZs": ""
},
"Listeners": [
{
"LoadBalancerPort": "80",
"InstancePort": {
"Ref": "WebServerPort"
},
"Protocol": "HTTP"
}
],
"HealthCheck": {
"Target": {
"Fn::Join": [
"",
[
"HTTP:",
{
"Ref": "WebServerPort"
},
"/"
]
]
},
"HealthyThreshold": "3",
"UnhealthyThreshold": "5",
"Interval": "30",
"Timeout": "5"
}
}
},
"InstanceSecurityGroup": {
"Type": "AWS::EC2::SecurityGroup",
"Properties": {
"GroupDescription": "Enable SSH access and HTTP access on the inbound port",
"SecurityGroupIngress": [
{
"IpProtocol": "tcp",
"FromPort": "22",
"ToPort": "22",
"CidrIp": "0.0.0.0/0"
},
{
"IpProtocol": "tcp",
"FromPort": {
"Ref": "WebServerPort"
},
"ToPort": {
"Ref": "WebServerPort"
},
"CidrIp": "0.0.0.0/0"
}
]
}
}
},
"Outputs": {
"URL": {
"Description": "The URL of the website",
"Value": {
"Fn::Join": [
"",
[
"http://",
{
"Fn::GetAtt": [
"ElasticLoadBalancer",
"DNSName"
]
}
]
]
}
}
}
}
在这个模板中,自动扩展触发器基于Web服务器的CPU利用率。当300秒内的平均CPU利用率超过90%时,会添加一个新实例;当平均CPU利用率低于75%时,会移除一个实例。除了CPU利用率,还可以使用其他值(如Latency和RequestCount)作为 MetricName
参数。
此外,为了存储PostgreSQL/PostGIS、CLH代码和临时数据,系统每5分钟会自动创建一个EBS卷的快照,新扩展的实例可以附加最新的数据卷,并且系统只保留一份最新的数据卷以节省成本。
2.3 与一般步骤的差异
CLH集成了多个复杂组件,包括数据库管理(PostgreSQL/PostGIS)、元数据资源管理和采集以及地理空间数据预览。大数据管理和并发请求带来的潜在计算强度进一步增加了整个系统的复杂性。在将CLH部署到Amazon EC2时,采用了一些特殊策略,如数据库备份、配置服务器负载均衡和自动扩展,以确保其功能的完整性。
3. 系统演示
云赋能的CLH可以通过 GEOSS Clearinghouse 访问。下面将介绍如何使用本地搜索和远程搜索来发现地理空间数据集和资源。
3.1 本地搜索
本地搜索功能允许用户根据标题、关键字、空间位置和时间信息发现记录。搜索结果可以按不同规则排序,如相关性、日期、标题、字母顺序、流行度和评分。根据资源类型,会在每个记录面板上动态添加访问工具按钮(如为WMS添加“交互式地图”按钮)。用户还可以使用由OpenLayers提供支持的集成可视化工具与数据服务进行交互。例如,搜索1980年至2013年全球“年度总和NDVI年度降雨量”时,可以得到相应的搜索结果。
3.2 远程搜索
CLH支持多种远程搜索EO数据的协议,全球用户可以定制自己的应用程序来使用GEOSS中的EO记录。通过远程搜索功能,用户可以从客户端向CLH发送搜索请求。CLH支持的搜索协议包括CSW、SRU和RSS。例如,通过GEO Portal的Web GUI进行CSW搜索,可以得到针对CLH的搜索结果。
4. 结论
4.1 经济优势
使用云服务支持CLH具有显著的经济优势。与使用本地服务器相比,不再需要传统服务器来托管CLH,从而节省了每月的电费、冷却系统费用、物理设施费用和系统管理员费用。以下是使用AWS服务和本地服务器的成本比较:
| 成本 | 租赁模式 | Amazon EC2 | 本地服务器 |
| — | — | — | — |
| 固定(一次性)成本 | - | 无 | 约2000美元购买服务器 |
| 每月 | 网络成本 | 1美元/月(数据传输) | 无(包含在维护费用中) |
| | 存储 | 22美元/月 | 无(包含在首次购买中) |
| | 计算能力 | 未预留:255美元/月
预留:57美元/月(如果为三年的高利用率预留大实例,总计676美元);13美元/月(如果预留三年) | 约17美元/月(假设服务器可使用10年) |
| | 维护成本(冷却、系统、系统管理员、维护、房间等) | 无 | 200美元/月(假设冷却、网络和房间费用100美元,支付系统管理员检查和维护服务器费用100美元) |
| 每年 | 总计 | 未预留:3300美元
预留:432美元(实例预留3年) | 2604美元 |
从表中可以看出,在部署和托管CLH时,使用云服务每年可节省约83.6%的成本。
4.2 技术优势
云服务(Amazon EC2)为CLH提供了可扩展性,使其在面临大量并发访问时能够保持性能稳定。此外,Amazon EC2在亚马逊成熟的网络基础设施和数据中心中运行,为CLH提供了高度可靠的环境。将CLH部署到Amazon EC2表明,云计算为在高度可扩展和可靠的计算环境中托管和运行地理空间应用程序提供了一种经济高效的方法。
综上所述,云赋能的CLH在经济和技术方面都具有明显优势,能够更好地应对大数据、并发访问等挑战,为地球观测数据的管理和利用提供有力支持。
5. 总结
云计算为支持CLH提供了经济和技术上的双重优势。文章首先介绍了CLH的背景和面临的挑战,包括大数据问题、时空搜索和全文搜索难题以及并发访问压力。接着详细阐述了将CLH部署到Amazon EC2的一般工作流程,涵盖授权网络访问、启动实例、安装软件包、传输代码和数据、恢复数据库、配置Servlet、启动服务和定制应用程序、配置负载平衡或可扩展性以及创建AMI等步骤。同时,还说明了在部署过程中的特殊考虑因素,如数据备份、负载均衡和自动扩展,并给出了具体的操作方法和示例代码。最后通过系统演示展示了CLH的本地搜索和远程搜索功能,并总结了云赋能CLH的经济和技术优势。
以下是整个部署过程的mermaid流程图:
graph LR
classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
A([开始]):::startend --> B(授权网络访问):::process
B --> C(启动实例):::process
C --> D(安装软件包):::process
D --> E(传输CLH代码和数据):::process
E --> F(恢复数据库):::process
F --> G(配置CLH的Servlet):::process
G --> H(启动服务并定制应用程序):::process
H --> I{是否配置负载平衡或可扩展性}:::process
I -- 是 --> J(配置负载平衡或可扩展性):::process
I -- 否 --> K(从运行的实例创建AMI):::process
J --> K
K --> L([结束]):::startend
6. 问题解答
6.1 部署GEOSS信息交换中心到云的一般步骤及与一般步骤的差异
部署GEOSS信息交换中心到云的一般步骤如下:
1. 授权网络访问,打开端口22和80。
2. 启动带有PostgreSQL 8.4和PostGIS 1.5的公共亚马逊机器映像实例。
3. 安装并配置PostgreSQL/PostGIS和Tomcat,注意版本兼容性。
4. 传输CLH代码和数据。
5. 恢复数据库。
6. 配置CLH的Servlet。
7. 启动服务并定制应用程序。
8. 可选配置负载平衡或可扩展性。
9. 从运行的实例创建AMI。
与一般步骤的差异在于,CLH集成了多个复杂组件,大数据管理和并发请求带来的潜在计算强度增加了系统复杂性,因此采用了数据库备份、配置服务器负载均衡和自动扩展等特殊策略。
6.2 迁移数据到可附加的亚马逊EBS卷的方法
迁移数据到可附加的亚马逊EBS卷的步骤如下:
1. 在Web控制台中创建一个无内容的EBS卷,确保其区域与CLH实例的区域相同。
2. 将卷附加到运行的实例,第一个挂载点使用 /dev/sdf
,多个卷按字母顺序依次使用。
3. 登录到实例,制作文件系统,创建目录,然后挂载EBS卷。示例命令如下:
[root@ip - 10 - 189 - 149 - 104~] mkfs - t ext3 /dev/sdh # 制作文件系统
[root@ip - 10 - 189 - 149 - 104~] mkdir /mnt/datavol_1
[root@ip - 10 - 189 - 149 - 104~] mount /dev/sdh /mnt/datavol_1/
6.3 可用于平衡系统负载的云服务及使用方法
可用于平衡系统负载的云服务是AWS提供的负载均衡器。使用方法如下:
1. 成功启动Amazon EC2实例后,在“网络与安全”部分,点击“负载均衡器”开始配置负载均衡服务。
2. 在使用负载均衡服务时,所有实例将访问在第一个实例上配置的同一数据库。
6.4 AWS提供的可扩展服务及使用方法
AWS提供的可扩展服务包括自动扩展器和CloudFormation服务。使用方法如下:
- 使用CloudFormation服务通过Web控制台配置 :在Web控制台中使用CloudFormation服务进行自动扩展配置。
- 通过命令行配置 :使用以下命令进行配置:
cfn - create - stack GEOSSClearinghouse -- template - file GEOSSClearinghouse.template -- region us - east - 1 -- awsaccesskey=FAKEKEY -- awssecretkey=FAKEKEY2 -- parameters="KeyName=GeoNet; InstanceType=m1.large"
无论使用哪种方式,都需要设置一个模板,模板是一个JSON文件,定义了基础设施要求。示例模板如前文所示,其中自动扩展触发器基于Web服务器的CPU利用率,可根据不同的CPU利用率阈值添加或移除实例。
6.5 以GEOSS信息交换中心为例,解释云赋能地球科学应用的技术优势
以GEOSS信息交换中心为例,云赋能地球科学应用的技术优势主要体现在以下两个方面:
- 可扩展性 :云服务(如Amazon EC2)提供了可扩展性,能够在面临大量并发访问时保持系统性能稳定。当用户访问量增加时,可以通过自动扩展功能动态增加实例数量,满足计算需求;当访问量减少时,减少实例数量以降低成本。
- 可靠性 :Amazon EC2在亚马逊成熟的网络基础设施和数据中心中运行,为应用程序提供了高度可靠的环境。同时,通过定期创建EBS卷的快照,能够确保数据的安全性和可恢复性,即使实例出现故障,也可以快速恢复服务。
综上所述,云赋能的地球科学应用能够更好地应对大数据、并发访问等挑战,提高系统的性能和可靠性,为地球科学研究和应用提供有力支持。