服务器 Gind.cn

服务器问题集锦,包括 Linux(Ubuntu, Centos,Debian等)和Windows Server服务器

诊断networking传输完整性

在使用新机器时,我发现当通过连接到特定networking基础设施的特定[离散]networking控制器接收文件时,文件被破坏。 还有其他几个同样型号和其他型号的控制器样品,我想指出问题的根源 – 不pipe它是: networking控制器硬件或全家的具体实例; 特定操作系统的特定版本的驱动程序,或其他版本; 特定机器的另一个硬件或软件故障; 另一个特定于特定networking基础设施的故障,包括坏电缆。 我正在考虑像iperf这样的跨平台软件实用程序,但同时也关注数据完整性 – 不仅仅是对吞吐量进行基准testing,而是依靠TCP校验和(这是16位算术和,不能防止任意损坏)隐式重传不能在应用程序级直接观察到。 memtest /dev/eth0种类。 不过,我还找不到这样的工具。 有什么select? 我只能想象把一个大文件和两个方向移动,然后比较它的散列与参考。 但是这种方法有几个缺陷: 常见的大型文件,如某些软件分发的CD映像,可能没有广泛的位模式,可能会引发触发破坏的机会。 使用现成的软件交换文件需要为下载和上传设置一个文件服务器,这在最常见的情况下(包括Windows在内的多个操作系统都需要testing时)可能是困难的。 从存储在磁盘上的文件(而不是伪随机生成的)创buildnetworkingstream量受磁盘性能的限制,这可能会降低networking吞吐量,特别是在写入时。 一般来说,哈希计算不能开始,直到文件完全保存到磁盘。 而且,到那个时候,文件的开始很可能从磁盘caching中被交换出来,因此再次受到磁盘性能的限制。 相比之下,一个特制的软件工具可以在检测到哈希不匹配的第一个段之后立即报告完整性故障 – 可能是几秒(兆字节)或几个小时(兆兆字节)。 然而,使用文件支持的方法,我们要么使用低延迟的小文件,以及不充分的位模式独特性,要么使用大文件,这些文件还不足以为我们提供几个小时不同的比特stream。 是否有其他(更好)的select我失踪?

Dell Openpipe理服务器pipe理员login失败的连接错误

我最近尝试使用OMSA 8.5来pipe理我的Dell R710服务器上的一些设置,但在尝试login到OMSA时遇到login failed… connection error消息。 在大概一个月前,我能够从这台机器(Windows 7)login到服务器,没有任何问题。 我已经尝试从前面提到的Windows 7机器以及从OMSA 8.5全新安装的Windows 10机器login。 两者都给我同样的错误。 我确认了机器可以互相ping通。 我确认机器能够访问iDRAC Web界面。 我确认我正在使用服务器的正确IP地址。 我确认在服务器上的ESXi主机上安装了OpenManage 8.5.0,但似乎并没有在主机上运行相关的服务。 我确认在Windows 7和Windows 10客户机上都安装了OMSA 8.5。 我不知道我是否使用正确的用户名/密码,因为随机垃圾到任一领域的垃圾邮件给与尝试可能有效的用户名/密码组合相同的错误。 我试过的密码是: iDRAC用户名和密码 客户端机器的用户名和密码 自从我上次login以来,服务器已经重新启动,所以这可能导致它。 我试图在Windows 10计算机上执行相同的过程,并检查了ignore certificate warning并收到login failed… Internal Error消息。 我遵循本指南在我的ESXi 6.5主机上安装Openmanage,并且没有任何问题。 有没有人有过这个问题,并find了解决办法? 我发现了一些build议,但是其中大部分都是在一台或两台机器上重新安装Openmanage并重新启动服务器,我希望避免。 编辑:缺less链接。 编辑2:它从来没有发生过,但我最近在我的networking上安装并configuration了带有AD DS的Windows服务器,并且这两台Windows计算机都join了域。 这是否有可能导致问题?