OPNET工程:作业3_标准应用介绍https://download.csdn.net/download/Cx2008Lxl/79477669
这项实验室作业的主要目标是介绍OPNET中标准应用的建模。具体而言,在这项作业中,将配置几个标准应用,指定和调试所创建的用户概要定义,在网络中部署指定的应用,最后是详细研究应用性能。
考虑如下情形,其中称为研究人员无限责任公司(Researchers Ine.)的一家R&D公司分散在三个地点:
- Main Site(主地点)由50名雇员组成,主要使用电子邮件、网页浏览和话音会议实施他们的日常工作。
- RnD Site(研发地点)由100名雇员组成,主要使用远程登录、电子邮件和网页搜索实施他们的日常任务。
- Server Farm(服务器集群)包含用于电子邮件、网站和远程登录应用的服务器。
作业是创建研究人员公司网络的一个仿真模型,并详细研究部署在网络中的各项应用的性能。
本节难点:问题2、8。需掌握DES日志查看的步骤、根据链路利用率图分析导致瓶颈的原因。
目录
-
步骤与结果
1. 创建仿真模型。
创建一个新项目和一个名为Researchers Network的空场景。
2. 创建网络拓扑。
如图3.1。配置Main Site和RnD Site的LAN对象分别包含50个和100个工作站。通过设置属性LAN…Number of Workstations为期望值,可指定一个LAN对象中工作站的数量,如图3.2。
3. 在研究人员公司网络中配置和部署应用。
1)配置个体应用:配置Application Config,定义下列5个标准应用,如图3.3。
① Web Browsing:Http属性 – Heavy Browsing。
② Telnet:Remote Login属性 – High Load。
③ Web Research:Http属性 – Searching。
④ E-mail:Email属性 – Medium Load。
⑤ VoIP:Voice属性 – GSM Quality Speech。
2)定义用户概要:配置Profiles,创建以下两个概要。配置每项概要都以Serial(Ordered) Operation Mode运行应用,而将其他概要配置属性保留为其默认值,如图3.4。
① Main Site Employees,运行如下三项应用:Web Browsing、E-mail和VoIP。
② RnD Employees,运行如下三项应用:Web Research、Telnet和E-mail。
3)依据如下规则,部署创建的概要,如图3.5。
① Main Site Employee概要被配置为以Main Site作为概要的源,而对象Web Server、E-mail Server和RnD Site分别作为Web Browsing、E-mail和VoIP应用服务器或目的地。
② RnD Employees概要被配置为以RnD Site作为概要的源,而对象Web Server、Telnet Server和Email Server分别作为Web Research、Telnet和E-mail应用的服务器或目的地。
4)配置两个LAN对象的属性,使所部属的概要在LAN内的所有节点上执行。通过设置属性Applications…Application:Supported Profiles…<profile>…Number of Clients为Entire LAN,可指定这项要求,其中<profile>是Main Site或RnD Employee。如图3.6。
5)为Email、HTTP、Remote Login和Voice应用,配置仿真收集所有全局统计量。执行5min仿真。收集如下仿真结果:
① 结果1:DES日志,如图3.7。
② 结果2:DES日志警告详情(以第一个和第三个警告为例),如图3.8。
③ 结果3:全局统计量Traffic Sent(bytes/sec),如图3.9。
4. 改正第一个配置的问题。
1)复制上述场景,命名为Fixing Problem 01。
2)将Main Site Employee和RnD Employee概要的工作模式更改为Simultaneous。
3)配置仿真,再增加一个链路point-to-point统计量的收集。并运行仿真,收集如下仿真结果。
① 结果1:每个应用的发送速率Traffic Sent(bytes/sec),如图3.10。
② 结果2:电子邮件(E-mail)应用的下载响应时间、网页(Web)应用的页面响应时间、Telnet应用的响应时间和VoIP报文所经历的端到端时延,如图3.11。
③ 结果3:网络路由器连接到互联网的链路利用率,如图3.12。
5. 改正第二个配置问题。
与研究人员公司员工进一步讨论后发现,Main Site实际上一天仅建立一次语音会议。通常这种会议呼叫会持续约1h,并在下午大约2:00PM在单个会议室进行。
修改应用部署,改变Main Site Employee概要定义,并创建一个附加的概要,对会议呼叫建模。执行以下配置步骤:
1)复制Fixing Problem 01,创建名为Fixing Problem 02的新场景。
2)清除当前网络中的应用部署。
3)从Main Site Employee概要的定义中去除VoIP应用。
4)创建称为Conference Call的新概要,它仅运行VoIP应用。VoIP应用应该在概要启动后6h启动,且仅运行1h,仅重复一次。如图3.13。
5)在网络中重新部署所有概要。配置Conference Call概要,对于VoIP应用,以Main Site作为源,RnD Site作为目的地,如图3.14。
6)修改Main Site LAN对象配置,使概要Conference Call运行在单个客户端上,如图3.15。
7)将仿真时长设置为8h,并重新运行仿真,收集如下仿真结果:
① 结果1:电子邮件(E-mail)应用的下载响应时间、网页(Web)应用的页面响应时间、Telnet应用的响应时间和VoIP报文所经历的端到端时延,如图3.16。
② 结果2:每个应用的发送速率Traffic Sent(bytes/sec),如图3.17。
③ 结果3:网络路由器连接到互联网的链路利用率,如图3.18。
-
问题与解答
1. 在仿真完成时产生了多少DES日志表项?
从图3.7可见,产生了9个日志表项。
2. 打开Log Viewer窗口,并详细研究处理应用建立的DES日志表项。由那个日志表项报告的问题是什么?
从图3.8可见,警告日志报告了在Main Site Employees中,位于Web Browsing应用下面的应用和在RnD Employees中,位于Web Research应用下面的应用都未被执行。
3. 针对每项应用,详细研究全局统计量Traffic Sent(bytes/see)。仿真结果是确认还是反驳了 DES日志告警?为什么确认或为什么反驳?
从图3.9中,可看到只有Http应用模型(即包含了:Web Browsing和Web Research两个应用)产生了发送数据,而其他应用模型都未产生发送数据,与DES日志中报告的警告情况一致。
4. 我们原假定和后续步骤中的哪个导致这个问题产生?如何纠正这个问题?
由于在定义用户概要时,配置的每个概要都以顺序方式运行应用,且第一个应用开始后会一直运行,直到仿真结束,因此后续应用都不会被执行。纠正的方式是将顺序执行模式更改为同时运行,或限制前面应用的运行时间。
5. 改正第一个配置问题后,详细研究每个应用的发送速率。上述概要配置改变解决了在前一节发现的问题了吗?
从图3.10可知,每个应用模型在仿真时间内都产生了发送数据,因此解决了前一节发现的问题。
6. 改正第一个配置问题后,详细研究电子邮件(E-mail)应用的下载响应时间、网页(Web)应用的页面响应时间、 Telnet应用的响应时间和VolP报文所经历的端到端时延。使用平均(average)函数在单个分析平板中显示这些统计量。所显示的应用响应时间和时延图形展现出一个趋势吗?为什么有趋势或为什么没有?
从图3.11可见,所有的四个项目结果曲线,都呈现了逐渐增大的趋势,并最终趋于无穷大。表明随着通信的进行,链路越来越拥挤,最终处于瘫痪状态。说明链路容量不满足应用需求。
7. 改正第一个配置问题后,您认为应用所经历的时延对公司雇员是可接受的还是不可接受的?为什么可接受或为什么不可接受?
不可接受。随着时间的增长,时延也会越来越大,最终趋于无穷大,即最终无法使用任何网络服务,因此必然是不可接受的。
8. 改正第一个配置问题后,详细研究将网络路由器连接到互联网的链路上的利用率。依据所观察到的链路利用率,哪个应用导致网络中的拥塞?
从图3.12可见,Router-Main Site和Router-RnD Site路由器至The Internet上下行链路最终利用率都达到了100%,而Router-Servers路由器至The Internet的上下行链路利用率都非常低。并且三个路由器至The Internet都采用的DS-1链路。因此很容易判断,是Main Site与RnD Site之间的应用导致的拥塞,即VoIP应用。
9. 详细研究电子邮件应用的下载响应时间、网页应用的页面响应时间、Telnet应用的响应时间和VolP报文所经历的端到端时延。相比于在场景Fixing Problem 01中收集的结果,这些值情况如何?您认为这种时延对应用用户来说是可接受的吗?为什么可接受或为什么不可接受?
从图3.16可见,电子邮件应用的下载响应时间、网页应用的页面响应时间、VolP报文所经历的端到端时延都在0.1s左右,Telnet应用的响应时间低于0.02s,且时延较为稳定,随时间变化不明显,因此用户可获得较好的上网体验,网络稳定性也较好,可以接受。
10. 详细研究每个应用的发送連率。相比于在场景Fixing Problem 01中收集的结果,这些值情况如何?哪项应用产生最多的流量?通过应用配置,验证观察到的结果。
在本场景下,各应用的发送速率都较为稳定,也能说明通信状态较为正常,语音业务仅在上班6h后(即下午2点)开始且仅持续了1h,与概要的配置相符。而在Fixing Problem 01场景中,语音业务一直占用着链路,导致链路利用率处在100%,其他应用无法正常通信,一直处于重试或等待状态,因此发送速率波动也较大。
11. 详细研究将网络路由器连接到互联网的链路上的利用率。新的概要配置去除了网络中的瓶颈了吗?
从图3.18可见,三个路由器至The Internet的上下行链路利用率都小于50%,维持在了较低的水平,因此不会出现拥塞情况,用户能正常访问服务,解决了网络瓶颈问题。
-
总结
本实验模拟了公司的两个办公地点互相通信与访问服务器的场景,学习了应用和概要的配置与部署过程。通过设定应用的运行方式与运行时间,可以模拟真实的上网情况。通过查看链路利用率来分析导致链路瓶颈的应用,进一步熟悉了仿真结果的查看与分析。也学习了在链路容量不扩展的情况下,通过合理分配业务使用时间来解决链路瓶颈的问题,经济实惠,这样的场景在真实环境中非常具有代表性,极具学习价值。
参考文献
[美]Adarshpal S. Sethi, Vasil Y.Hnatyshin. 计算机网络仿真OPNET实用指南[M]. 王玲芳, 母景琴, 译. 北京:机械工业出版社, 2014.