高校云桌面的“正确打开方式”是什么?
高校一直都是前沿技术率先应用的重要场所,云桌面技术也不例外。上世纪90年代开始高校就在不断尝试和应用类似于云桌面的方案,初衷是来解决大批量设备管理和维护的问题。从最初的无盘工作站到保护卡+同传的方案,再到后来的桌面虚拟化(VDI,Virtual Desktop Infrastructure)。但这些技术始终未能在高校场景得到大规模应用。究其原因,离高校教育教学业务场景太远,无法满足多样业务场景差异化的要求。
今天我们来看看云桌面在高校应用场景下的正确打开方式:
高校能够应用云桌面的场景比较多,如办公场景、多媒体教室、图书馆/电子阅览室、阅卷时、语音室、通用教学机房等。而且不同场景各具特点,对性能、网络、并发、延迟、管理维护各有侧重和要求,所以高校云桌面建设需要考虑多场景的特点,做到“资源统一,特性场景化”。具体可以从以下几个方面来看:
简化管理,提升运维效率是“敲门砖”
很多学校选择云桌面的初衷是提升管理维护效率,主要是因为学校桌面设备多,而传统电脑在部署,硬件维护,系统和软件更新升级,系统还原,病毒问题等方面带来了比较大的困扰,亟需一套好的方案来解决这些问题。
传统电脑带来的管理维护困扰
云桌面方案其架构本身就决定了能够完美解决以上传统电脑的管理维护问题,当前市面上主流的云桌面解决方案基本都能做到这一点,差异主要是在和业务关联细节和使用体验上。
集中配置管理
“场景化”的云桌面才是最合适的
在高校场景中云桌面要用的好,解决管理维护的问题只是第一步,更重要的是适配各类场景,满足各类场景的要求。常见典型应用场景如下:
- 财会类场景:高并发,大数据量读写
高校机房承接的课程中,部分有大数据量高并发写入的需求,如数据库、财经软件教学场景。其中财会类软件建账对云桌面IO读写性能有比较高的要求,传统电脑完成1.3GB左右账套的建设约为2′40″,传统云桌面方案中受限云主机IO瓶颈,并发各桌面1.3GB左右账套建设,耗时约为4′50″,无法支撑教学使用。此类场景需要云桌面方案进行IO提速设计,从硬件配置到虚拟化软件优化调度算法,提升IO性能,优化适配之后能够达到与传统电脑持平的效果。
- 安卓开发场景:多层虚拟化
高校有部分课程需要使用到虚拟化环境,常见的如安卓开发课程、网络实验中的配置模拟器、操作系统教学等。在云桌面中还需要提供虚拟化环境,云桌面需要在针对此类场景增加嵌套虚拟化特性,能够在虚拟桌面中再启第三方虚拟化平台,其上部署操作系统或运行虚拟化环境,支撑教学应用。
- 语音教学场景:对低时延要求高
语音教学的特点决定了其对时延要求非常高,而传统的VDI云桌面由于教学环境和语音软件都运行在服务器端,而声音采集在终端侧,声音数据需要经过网络在服务器端进行中转处理再回传到终端侧,影响语音教学使用体验。
在语音教学场景下需要扩展方案,完成云端计算和本地计算的融合计算方式,对语音类教学业务可以在终端本地进行数据处理,降低网络传递带来时延问题,能够更好地支撑语音教学业务。该方式不仅可以解决语音教学问题,类似的需求依赖本地处理的教学业务都能够更好的支撑,如部分要求本地运行和存储的考试业务。
- 多媒体场景:保障业务是关键
多媒体教室场景的特点是数量多,比较分散,而且使用人员不固定,外设也比较多。每学期开学都需要花费大量的人力进行逐间教室进行环境确定和问题排查,对环境的稳定可靠性要求高,不能出现教学事故。
基于多媒体教室的特点,在方案和技术上智能桌面虚拟化架构( IDV,Intelligent Desktop Virtualization)更合适:
- 集中管理和镜像配置:全校多媒体教室统一进行管理,镜像配置和下发
- 终端本地计算,离线可用:在断网离线是依然可以使用,无切换,教学业务不中断
- 外设兼容性:外设采用透传方式,较传统VDI方案具备更好的兼容性效果
高校应用场景多,而不同技术和方案也有其特点和适配的场景,在云桌面建设的过程中需要了解各类场景的特点,针对不同特点和要求选择相应的解决方案。比如在办公数据随身和通用文化基础教学场景下可以采用VDI技术方案,体验简化管理、资源灵活调度、数据随身的特性;而在多媒体教室场景则可以采用IDV架构方案,确保稳定可靠性的同时,解决管理维护难题。“VDI+IDV双擎”模式是当前云桌面建设不错的选择。
统一规划,深入高校教育教学场景,按场景适配方案,这才是高教云桌面的正确打开方式。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
【一周】Nano vs Vim、BIOS vs UEFI、Linux内核 vs 云原生 | antirez不想维护他的Redis了
回顾一周社区热门资讯 第【七十八】期:20200627-20200703 点击相应标题,跳转阅读全文 Jakarta EE 9 Milestone 1 发布 Jakarta EE 9 版本标志着从 javax.* 命名空间到 Eclipse 的jakarta.* 的最终过渡,此版本将所有 API 更新为在包名称中使用jakarta.*。 全新设计的 Xcode 12 Xcode 12 本身就是作为 Universal app 而构建,可以原生运行在 Intel x86_64 CPU 和基于 ARM 的 Apple 芯片上。Xcode 12 还提供了统一的 macOS SDK,其中包含所有框架、编译器、调试器和其他工具,以帮助构建在 Apple 芯片和 Intel x86_64 CPU 上原生运行的应用程序。 Micronaut 2.0.0 发布,原生云原生微服务框架 Micronaut 是一个新一代基于 JVM 的全栈微服务框架,用于构建模块化的、易于测试的微服务应用。 微软在 ARM 上成功移植 OpenJDK for Windows 10 开发人员可以开始使用最近发布的 Visua...
- 下一篇
Spring Cloud系列教程第九篇-Eureka自我保护机制
Spring Cloud系列教程第九篇-Eureka自我保护机制 本文主要内容: 1:自我保护介绍 2:导致原因分析 3:怎么禁止自我保护 本文是由凯哥(凯哥Java:kagejava)发布的《spring cloud系列》教程的总第九篇: 本文是几个维度中的第一个维度:注册与发现维度配置中心管理之Eureka相关教程第六篇。 一:Eureka的自我保护机制是什么? 保护模式主要用于一组客户端和Eureka Server之间存在网络分区场景下的保护。一旦进入保护模式,Eureka Server将会尝试保护其服务注册表中的信息,不再删除服务注册表中的数据,也就是不会注销任何微服务。 简单一句话: 用电视剧新三国中,刘备说的:“宁可天下人负我,我不负天下人”。即:Eureka服务端,进入自我保护模式,就算所有的微服务真的都出问题了,也不会里面删除它们的。 二:为什么会出现自我保护机制? 一句话:某时刻某一个微服务不可用了,Eureka不会立刻清理,依旧会对该服务的信息进行保存。属于CAP里面的AP分支,也即是:保证可用性、分区容错性。 PS:CAP原则:分布式系统中,C:一致性;A:可用性...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- CentOS8编译安装MySQL8.0.19
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7
- SpringBoot2整合MyBatis,连接MySql数据库做增删改查操作
- SpringBoot2整合Redis,开启缓存,提高访问速度
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- Hadoop3单机部署,实现最简伪集群
- CentOS7,CentOS8安装Elasticsearch6.8.6
- CentOS6,7,8上安装Nginx,支持https2.0的开启
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果