公告


赛特达开博了,非常高兴这样的季节能够和大家一起分享这样的喜悦。赛特达在获得大家新老朋友的支持的同时也希望能够一起分享最前沿的技术信息。希望各位能够常来坐坐,也常来聊聊!crack

关于我

<2020年7月>
2829301234
567891011
12131415161718
19202122232425
2627282930311
2345678

最近来访

留言簿(1)

文章分类

文章档案

相册


最新评论

请问,如果想让DOE中的试验方案在一台机器中实现分布计算,也就是四个核心,每个核心处理一个方案,该怎么做?--【匿名用户】:E-works热心网友 spred
不错!!--卢玉琴
那么请问isight&nbsp;fd能不能进行类似的mdol语言开发呢?有没有相关资料?--【匿名用户】:E-works热心网友
能否较详细介绍一下开发的一个简单实例啊。--【匿名用户】:E-works热心网友
为什么语言介绍并不更新啊?--【匿名用户】:E-works热心网友
博主您好,我初次接触这种抽样法,感觉一头雾水。很幸运看到您的博文,请您能详细介绍一下拉丁超立方抽样好吗?最好举例说明。谢谢!--【匿名用户】:E-works热心网友
我用的是isight8.0可以实现并行计算吗--【匿名用户】:E-works热心网友
太经典了!对于我这样刚刚迈出校园的学生来说,真是醍醐灌顶啊!多谢楼主的教导之言!--【匿名用户】:E-works热心网友
很好的资料
请问你有包含图片的完整文档吗?
可否发一份networm_2005@163.com
谢谢--【匿名用户】:E-works热心网友
logs中写的错误类型是stderr:&nbsp;Estimated&nbsp;disk=1.2MB
stderr:&nbsp;Estimated&nbsp;DOF=80
stderr:&nbsp;Estimated&nbsp;memory=32MB
之类的错误,不知道是什么原因

--【匿名用户】:E-works热心网友
请问一下,做过isight集成nastran的案例吗,我用的是isight-fd版本,集成nastran2007,结果总是出错,不知道什么原因,烦请高手指点一下--【匿名用户】:E-works热心网友
好的&nbsp;谢谢--【匿名用户】:E-works热心网友
说得是没错,但那些政府管员,当管的都拿老百姓的呀,大家一起努力吧,改变中国现在的样子吧,--【匿名用户】:E-works热心网友
好!--【匿名用户】:E-works热心网友
清华大学有N多个大学校长,俺想知道这五句话是哪个校长说的?&nbsp;
--【匿名用户】:E-works热心网友
谢谢答疑解惑
--【匿名用户】:E-works热心网友
--【匿名用户】:E-works热心网友
请问Isight&nbsp;for&nbsp;Abaqus——by&nbsp;hannah在abaqus的哪个版本中有啊?--【匿名用户】:E-works热心网友
Re&nbsp;2楼:
如果想让DOE中的各个实验方案分到不同的机器上并行计算的话,单机版的Isight-FD是不行的,必须在FIPER并行分布环境中才能实现。在这个FIPER环境中,Isight-FD只是它的一个客户端,另外还有一个客户端叫Station,这样一旦Isight-FD把各个方案提交到FIPER环境中后,FIPER环境的服务器端ASCS就会自动的把任务分到各个机器的Station上来并行或分布执行。--赛特达
Isight&nbsp;for&nbsp;Abaqus是我们的另外一个产品,优化方面功能和Isight-FD基本是一样的,只不过这个产品只能集成Abaqus,不能集成其它的软件。

--赛特达

阅读排行榜

评论排行榜

负载均衡是提高系统性能的一种前沿技术。还是沿用前面的例子,一台IA服务器的处理能力是每秒几万个,显然无法在一秒钟内处理几十万个请求,但如果我们能够有10台这样的服务器组成一个系统,如果有办法将所有的请求平均分配到所有的服务器,那么这个系统就拥有了每秒处理几十万个请求的能力。这就是负载均衡的基本思想。 实际上,目前市场上有多家厂商的负载均衡产品。由于其应用的主要技术的不同,也就有着不同的特点和不同的性能。 1.轮询DNS 轮询DNS方案可以说是技术上最简单也最直观的一种方案。当然,这种方案只能够实现负载均衡的功能,却无法实现对高可用性的保证。 它的原理是在DNS服务器中设定对同一个Internet主机名的多个IP地址的映射。这样,在DNS收到查询主机名的请求时,会循环的将所有对应的IP地址逐个返回。这样,就能够将不同的客户端连接定位到不同的IP主机上,也就能够实现比较简单的负载均衡功能。但是,这种方案有两个比较致命的缺点: l 只能够实现对基于Internet主机名请求的负载均衡,如果是直接基于IP地址的请求则无能为力。 l 在集群内有节点发生故障的情况下,DNS服务器仍会将这个节点的IP地址返回给查询方,也就仍会不断的有客户请求试图与已故障的节电建立连接。这种情况下,即使你手工修改DNS服务器的对应设置,将故障的IP地址删除,由于Internet上所有的DNS服务器都有缓存机制,仍会有成千上万的客户端连接不到集群,除非等到所有的DNS缓存都超时。 2.硬件解决方案 有些厂商提供对负载均衡的硬件解决方案,制造出带有NAT(网络地址转换)功能的高档路由器或交换机来实现负载均衡功能。NAT本身的原理就是实现多个私有IP地址对单个公共IP地址的转换。代表产品是Cicso公司和Alteon公司的某些高档硬件交换机系列。这种方案有如下缺点: l 由于采用了特殊的硬件,使得整个系统中存在非工业标准部件,极大的影响系统的扩充和维护、升级工作。 l 价格极其昂贵,和软件的解决方案根本是数量级上的差别。 l 一般只能实现对节点系统一级的状态检查,无法细化到服务一级的检查。 l 由于采用NAT机制,集群管理节点本身要完成的工作量很大,很容易成为整个系统的瓶颈。 l 此特殊硬件本身就是单一故障点。 l 实现异地节点的集群非常困难。 3.协商式处理(并行过滤) 这种方案的原理是客户请求会同时被所有的节点所接收,然后所有节点按照一定的规则协商决定由哪个节点处理这个请求。此种方案中比较显著的特点就是整个集群中没有显著的管理节点,所有决定由全体工作节点共同协商作出。代表产品是Microsoft公司的Microsoft Load Balancing Service这种方案的特点是: l 由于各节点间要进行的通讯量太大,加重了网络的负担,一般需要增加节点通讯的专用网络,也就加大了安装和维护的难度和费用。 l 由于每个节点都要接收所有的客户请求并进行分析,极大的加大了网络驱动层的负担,也就减低了节点本身的工作效率,同时也时网络驱动层很容易成为节点系统的瓶颈。 l 由于要更改网络驱动层的程序,所以并不是一个通用的方案,只能够实现对特殊平台的支持。 l 在小量节点的情况下协商的效率还可以接受,一旦节点数量增加,通讯和协商将变得异常复杂和低效,整个系统的性能会有非线性的大幅度下降。所以此类方案,一般在理论上也只允许最多十几个的节点。 l 无法实现异地节点的集群。 l 由于集群内没有统一的管理者,所以可能出现混乱的异常现象。 4.流量分发 流量分发的原理是所有的用户请求首先到达集群的管理节点,管理节点可以根据所有服务节点的处理能力和现状来决定将这个请求分发给某个服务节点。当某个服务节点由于硬件或软件原因故障时,管理节点能够自动检测到并停止向这个服务节点分发流量。这样,既通过将流量分担而增加了整个系统的性能和处理能力,又可以很好的提高系统的可用性。 通过将管理节点本身做一个子集群可以消除由于管理节点自身的单一性带来的单一故障点。有些传统技术人员认为,因为所有的客户流量都将通过管理节点,所以管理节点很容易成为整个系统的瓶颈。但TurboCluster Server通过先进的直接路由或IP隧道转发机制巧妙的解决了问题。使得所有对客户响应的流量都由服务节点直接返回给客户端,而并不需要再次通过管理节点。众所周知,对于服务提供商而言,进入的流量要远远小于流出的流量,所以管理节点本身将不再是瓶颈。 流量分发的具体实现方法有直接路由、IP隧道和网络地址转换三种方法。TurboCluster Server目前支持效率最高的前两种。由于这种先进的结构和技术,使得TurboCluster Server集群内的服务节点数并没有上限,而且对大量节点的协同工作的效率也能够非常好的保证
发表于: 2009-09-25 13:48 赛特达 阅读(1390) 评论(0) 收藏 好文推荐

本博客所有内容,若无特殊声明,皆为博主原创作品,未经博主授权,任何人不得复制、转载、摘编等任何方式进行使用和传播。

作者该类其他博文:

网站相关博文:

发表评论(网友发言只代表个人观点,不代表本网站观点或立场。)

您尚未登录,请先【登录或注册