服务器 Gind.cn

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

Centos 7networking问题

我有一个戴尔sonicwall后面的Centos 7服务器我已经configuration了sonicwall允许某些服务,这似乎工作正常。 但是我不能telnet到一些端口。 我已经将Wireshark添加到Centos 7中,以validation所述端口上的数据包是否到达。 我可以远程login到端口22 ssh,并在内部和外部正常工作。 我的VNC服务也可以从另一台机器内部工作。 然而,端口80,443和我想要的服务端口2526不起作用。 stream量正在服务器,所以我知道Sonicwall是好的。 但是在Wireshark中,我把这条线弄红了 28632 1398.805571570 192.168.xx xxxx TCP 54 telnet > 26354 [RST, ACK] Seq=1 Ack=1 Win=0 Len=0. 此条目将从我的服务器(通过NAT)返回到远程login的始发源。 所以握手,我猜为了连接。 我可以从我的CentOS 7服务器telnet到另一个networking,所以我知道我有连接了。 如果我运行ss -tnlp我只看到侦听SSH和VNC的端口。 我已经禁用了SELInux(不知道这是不是一个好主意!),我已经正确添加了端口的规则,我相信(因为我pipe理VNC服务器一个例如) 我使用通常的防火墙cmd命令来添加我的规则,我也使用了永久开关。 我甚至试过这个 firewall-cmd –direct –add-rule ipv4 filter INPUT 0 -p tcp –dport 2526 -j ACCEPT 为了完全避开那个端口的防火墙,但仍然没有喜悦。 我的centos 7服务器有3个网卡的设置,其中2个用于内部使用,即在10.xxxnetworking上。 我的默认网关有一个192.168.xxnetworking,就像我的默认界面一样。 内部地址是通过sonicwall NAT到一个IP,当然,我可以内部和外部平。 我的假设是networking入站是好的,但有些事情是不合时宜的。 […]

提高EBS快照支持卷的I / O速率

我正在使用一个系统,为了灾难恢复的目的,每个卷需要一组42个每日EBS快照。 EBS卷被聚合到一个RAID卷中。 通过在拍摄快照期间冻结文件系统来拍摄一组一致的快照。 每个单独的数量只有2个TiB。 在灾难恢复testing期间,发现从应用数据(PostgreSQL数据库,许多大型表)中复制超过24小时的应用数据(PostgreSQL数据库,许多大表),从快照创build的EBS快照支持的卷中复制到新的非快照支持卷支持卷。 由于在不同的子树上同时工作了8个rsyncs,所以在副本中具有相当的并行性。 如果数据没有被复制到新的EBS卷上,那么基于PostgreSQL的应用程序就像蜂蜜一样运行了很多天,据推测,直到EBS卷的块已经被弄脏,所以它们现在直接在EBS卷上,而不是来自快照。 通过这种方式,从一组非快照支持的EBS卷到另一个卷的相同数据的副本只需要几个小时,而使用类似规模的“真实”硬件就可以less得多。 为什么我会看到快照支持的卷和普通卷之间的这种极端的性能差异? 我的假设是,它正在写拷贝,所以干净的块,因为快照必须单独提取保持不变。 如果有大量的快照支持这个卷,那么大概有一些困难,快速find它出现在最近的快照中的块并获取它。 有没有什么办法可以强制AWS从快照中有效且线性地预先填充整个新的EBS卷,而不是像实际上似的那样进行懒惰的写入时复制? 任何其他的想法解决这个? 如果恢复需要一天以上的时间,DR的一组快照则不太有用。