LVS负载均衡到后端apache的虚拟主机报404错误检查日志发现：File does not exist: /etc/httpd/htdocs

Posted 2023-04-11

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了LVS负载均衡到后端apache的虚拟主机报404错误检查日志发现：File does not exist: /etc/httpd/htdocs相关的知识，希望对你有一定的参考价值。

虚拟主机配置：
<VirtualHost 192.168.93.47:80>
# ServerAdmin webmaster@dummy-host.example.com
DocumentRoot /baidu
ServerName www.baidu1.com
ErrorLog logs/dummy-host.example.com-error_log
CustomLog logs/dummy-host.example.com-access_log common
</VirtualHost>

默认主机已被屏蔽：注释掉了documentroot

lvs配置：
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 192.168.93.50:http rr
-> 192.168.93.41:http Route 1 0 0
-> 192.168.93.42:http Route 1 0 0
-> www.baidu.com:http Route 1 0 0

急求。。。。。。

错误日志和访问日志一样也是Apache的标准日志。本文分析错误日志的内容，介绍如何设置和错误日志相关的选项，文档错误和CGI错误的分类，以及如何方便地查看日志内容，等等。

一、位置和内容

　　错误日志无论在格式上还是在内容上都和访问日志不同。然而，错误日志和访问日志一样也提供丰富的信息，我们可以利用这些信息分析服务器的运行情况、哪里出现了问题。

　　错误日志的文件名字是error_log，但如果是Windows平台，则错误日志的文件名字是error.log。错误日志的位置可以通过ErrorLog指令设置：

ErrorLog logs/error.log

　　除非文件位置用“/”开头，否则这个文件位置是相对于ServerRoot目录的相对路径。如果Apache采用默认安装方式安装，那么错误日志的位置应该在/usr/local/apache/logs下。但是，如果Apache用某种包管理器安装，错误日志很可能在其他位置。

　　正如其名字所示，错误日志记录了服务器运行期间遇到的各种错误，以及一些普通的诊断信息，比如服务器何时启动、何时关闭等。

　　我们可以设置日志文件记录信息级别的高低，控制日志文件记录信息的数量和类型。这是通过LogLevel指令设置的，该指令默认设置的级别是error，即记录称得上错误的事件。有关该指令中允许设置的各种选项的完整清单，请参见http://www.apache.org/docs/mod/core.html#loglevel的Apache文档。

　　大多数情况下，我们在日志文件中见到的内容分属两类：文档错误和CGI错误。但是，错误日志中偶尔也会出现配置错误，另外还有前面提到的服务器启动和关闭信息。

二、文档错误

　　文档错误和服务器应答中的400系列代码相对应，最常见的就是404错误——Document Not Found（文档没有找到）。除了404错误以外，用户身份验证错误也是一种常见的错误。

　　 404错误在用户请求的资源（即URL）不存在时出现，它可能是由于用户输入的URL错误，或者由于服务器上原来存在的文档因故被删除或移动。

　　顺便说一下，按照Jakob Nielson的意见，在不提供重定向或者其他补救措施的情况下，我们永远不应该移动或者删除Web网站的任何资源。Nielson的更多文章，请参见http://www.zdnet.com/devhead/alertbox/。

　　当用户不能打开服务器上的文档时，错误日志中出现的记录如下所示：

[Fri Aug 18 22:36:26 2000] [error]

[client 192.168.1.6] File does not exist:

/usr/local/apache/bugletdocs/Img/south-korea.gif

　可以看到，正如访问日志access_log文件一样，错误日志记录也分成多个项。

　　错误记录的开头是日期/时间标记，注意它们的格式和access_log中日期/时间的格式不同。access_log中的格式被称为“标准英文格式”，这或许是历史跟我们开的一个玩笑，但现在要改变它已经太迟了。

　　错误记录的第二项是当前记录的级别，它表明了问题的严重程度。这个级别信息可能是LogLevel指令的文档中所列出的任一级别（参见前面LogLevel的链接），error级别处于warn级别和crit级别之间。404属于error错误级别，这个级别表示确实遇到了问题，但服务器还可以运行。

　　错误记录的第三项表示用户发出请求时所用的IP地址。

　　记录的最后一项才是真正的错误信息。对于404错误，它还给出了完整路径指示服务器试图访问的文件。当我们料想某个文件应该在目标位置却出现了404错误时，这个信息是非常有用的。此时产生这种错误的原因往往是由于服务器配置错误、文件实际所处的虚拟主机和我们料想的不同，或者其他一些意料不到的情况。

　　由于用户身份验证问题而出现的错误记录如下所示：

[Tue Apr 11 22:13:21 2000]

[error] [client 192.168.1.3] user rbowen@rcbowen.

com: authentication failure for "/cgi-bin/hirecareers/company.cgi":

password mismatch

　　注意，由于文档错误是用户请求的直接结果，因此它们在访问日志中也会有相应的记录。

三、CGI错误
　　错误日志最主要的用途或许是诊断行为异常的CGI程序。为了进一步分析和处理方便，CGI程序输出到STDERR（Standard Error，标准错误设备）的所有内容都将直接进入错误日志。这意味着，任何编写良好的CGI程序，如果出现了问题，错误日志就会告诉我们有关问题的详细信息。

　　然而，把CGI程序错误输出到错误日志也有它的缺点，错误日志中将出现许多没有标准格式的内容，这使得用错误日志自动分析程序从中分析出有用的信息变得相当困难。

　　下面是一个例子，它是调试Perl CGI代码时，错误日志中出现的一个错误记录：

[Wed Jun 14 16:16:37 2000] [error] [client 192.168.1.3] Premature

end of script headers: /usr/local/apache/cgi-bin/HyperCalPro/announcement.cgi

Global symbol "$rv" requires explicit package name at

/usr/local/apache/cgi-bin/HyperCalPro/announcement.cgi line 81.

Global symbol "%details" requires explicit package name at

/usr/local/apache/cgi-bin/HyperCalPro/announcement.cgi line 84.

Global symbol "$Config" requires explicit package name at

/usr/local/apache/cgi-bin/HyperCalPro/announcement.cgi line 133.

Execution of /usr/local/apache/cgi-bin/HyperCalPro/announcement.cgi

aborted due to compilation errors.

　　可以看到，CGI错误和前面的404错误格式相同，包含日期/时间、错误级别以及客户地址、错误信息。但这个CGI错误的错误信息有好几行，这往往会干扰一些错误日志分析软件的工作。

　　有了这个错误信息，即使是对Perl不太熟悉的人也能够找出许多有关错误的信息，例如至少可以方便地得知是哪几行代码出现了问题。Perl在报告程序错误方面的机制是相当完善的。当然，不同的编程语言输出到错误日志的信息会有所不同。

　　由于CGI程序运行环境的特殊性，如果没有错误日志的帮助，大多数CGI程序的错误都将很难解决。

　　有不少人在邮件列表或者新闻组中抱怨说自己有一个CGI程序，当打开网页时服务器却返回错误，比如“Internal Server Error”。我们可以肯定，这些人还没有看过服务器的错误日志，或者根本不知道错误日志的存在。决多大多数情况下，错误日志能够精确地指出CGI错误的所在以及如何修正这个错误。

四、查看日志文件

　　我常常告诉别人说，在进行开发的同时我会不断地检查服务器的日志，以便能够立即知道哪儿出了问题。但我得到的回答却往往是沉默。起先我以为这种沉默意味着“你当然得这样做”，后来我才发现这种沉默的真正含义是“我不知道别人的做法，但我自己是不干的。”

　　虽然如此，下面我们还是要看看如何方便地查看服务器日志文件。用telnet连接到服务器，然后输入下面的命令：

tail -f /usr/local/apache/logs/error_log

　该命令将显示出日志文件的最后几行内容，如果有新的内容加入到日志文件，它还会立即显示出新加入的内容。

　　 Windows用户也同样可以使用这种方法，比如可以使用各种为Windows提供的Unix工具软件包。我个人爱好一个称为AINTX的工具，它可以在http://maxx.mc.net/~jlh/nttools/index.htm找到。

　　还有一种替代方法是使用下面的Perl代码，它利用了一个称为File::Tail的模块：

use File::Tail;

$file=File::Tail->new("/some/log/file");

while (defined($line=$file->read))

print "$line";

　　无论具体采用的是哪一种方法，同时打开多个终端窗口都是一种好习惯：比如在一个窗口中显示错误日志，在另一个窗口中显示访问日志。这样，我们就能够随时获知网站上发生的事情并立即予以解决。转载参考技术A 不通过LVS 直接访问这个apache能正常访问么？追问

肯定可以啊！

LVS（Linux Viretual Server）负载均衡器 + 后端服务器

定义：

　　LVS是Linux Virtual Server的简写，意即Linux虚拟服务器，是一个虚拟的服务器集群系统。

结构：

　一般来说，LVS集群采用三层结构，其主要组成部分为：

　　A、负载调度器（load balancer），它是整个集群对外面的前端机，负责将客户的请求发送到一组服务器上执行，而客户认为服务是来自一个IP地址（我们可称之为虚拟IP地址）上的。

　　B、服务器池（server pool），是一组真正执行客户请求的服务器，执行的服务有WEB、MAIL、FTP和DNS等。

　　C、共享存储（shared storage），它为服务器池提供一个共享的存储区，这样很容易使得服务器池拥有相同的内容，提供相同的服务。

模式：

　　LVS-NAT：基于NAT（网络地址转换）技术，网络数据流程如下：

　　　　　　1）负载均衡器在收到客户端请求后，改写目的IP地址为后端服务器真是IP和/或端口号，转发给后端服务器。

　　　　　　2）后端服务器处理完成后，回复给负载均衡器。

　　　　　　3）负载均衡器改写源IP为虚拟IP，发送给客户端

　　LVS-DR：

　　　　　　1）请求经过负载均衡器调度后，后端服务器的相应数据流量直接返回给客户端，回包不经过负载均衡器。

　　LVS-Tun：

　　　　　　1）LVS-Tun是LVS原创的一种转发模式，基于LVS-DR。负载均衡器LVS代码把原始的包（源客户端IP到虚拟IP）封装成ipip包，目的地址是后端服务器的真实IP，然后进入OUTPUT链，并路由到后端服务器。后端服务器解封ipip包并处理，以源地址虚拟IP、目的地址客户端IP直接回复给客户端。

对比与推荐：

　　1）从对后端服务器的要求来看，LVS-NAT仅仅要求后端服务器网关指向负载均衡器的内网地址，无任何其他要求；LVS-DR模式要求后端服务器禁用对虚拟IP的ARP响应，后端服务器网关不指向负载均衡器；LVS-Tun要求后端服务支持ipip解包，部分操作系统不支持。

　　2）从吞吐量上来看，LVS-DR最高，LVS-NAT最低。

　　3）从配置简便性来看，LVS-NAT最低，LVS-DR和LVS-Tun较为复杂。

　　推荐在应用中使用LVS-DR模式，也是目前云微架构中应用最多的4层开源负载均衡转发策略。

使用场景：

　　单个LVS集群：

　　　　1）使用协议为vrrp协议进行组播通信，使用前建议关闭，否则则会出现脑裂现象。

　　　　2）对后端健康检查可以使用TCP Connect或者HTTP GET，在网站类应用负载均衡方案中，推荐使用HTTP GET，可以进行应用层检查，防止出现端口存在但无法提供业务的情况。Keepalived配置文件中digest的获取，使用该软件自带的genhash工具，genhash --help

　　　　3)重要参数：

　　　　LVS转发行为重要参数：expire_nodest_conn expire_quiescent_template

　　　　LVS同步状态重要参数：sync_threshold

　　　　4）LVS-DR模式的核心提示与优化：

　　　　　　- LVS-DR模式，因后端服务器上同样配置了虚拟IP，如果在客户端进行ARP请求的时候，后端服务器以自身的MAC地址进行了回复，则起不到负载均衡的效果，此时客户端直接连接到了某台后端服务器上。

　　　　　　- 后端服务器的虚拟IP必须绑定到lo:0上，同时指定子网掩码是255.255.255.255，否则ARP禁用会出现异常。

　　　　　　- 持久连接的问题。持久连接使同一个客户端在超时时间内（ipvsadm -p 参数指定，Keepalived中的persistence_timeout指令）会持续地连接到同一台后端服务器，这个是 4层上的持久连接。来自客户端的每个新的连接会重置该超时时间。

　　　　　　- Keepalived对后端服务器的健康检查，推荐使用应用层检查方式，另外可以配置Keepalived使用管理员自定义的脚本进行健康检查（MISC CHECK指令）。

　　　　　　- 负载均衡器之间使用vrrp协议进行高可用设置时，禁用iptables或firewalld或者打开对vrrp协议的支持。

　　　　　　- LVS集群中的负载均衡器，推荐使用16GB及以上内存，同时采用多队列网卡提高网卡吞吐量减少处理延时。

　　　　　　- LVS集群中的后端服务器，根据IO密集型和CPU密集型2类，可以分别使用RAID10、SSD及高频多核CPU来优化。

　　多组LVS设定和注意事项：

　　　　1）虚拟路由器的ID,在相同组的LVS集群里面，必须设置为一致；不同组LVS集群里面必须不同。

　　　　 2）优先级，对应state为MASTER的设置值必须比对应的state为BACKUP的设置值高。

　　　　 3）虚拟IP地址，不同组LVS集群不同

　　　　 4）同一组LVS里面的认证的密钥必须相同，不同组建议采用不同值。

　　　　在运维业务中，曾经发生过因新上的LVS集群采用了和原LVS集群里面虚拟路由器相同ID并且处于同一个网段导致原业务出现故障的问题。

　　可用性监控：

　　　　1）LVS可用性监控方面：通常是对LVS的虚拟IP提供的服务进行监控，同时对所有后端服务器进行可用性监控。应为LVS可以对后端服务器进行健康检查，那么后端服务器的不可用虽然会被LVS从服务器吃中剔除不影响客户端，但这个情况应该被系统管理员所获知，以便进行根本原因分析，并且评估其他后端服务器的压力情况。

　　　　2）在监控层次方面：尽量采用应用层检查的方式，如Nagios自带的check_http插件，Zabbix的Web Scenarios

LVS排错步骤推荐：

　　　　1）ping负载均衡器的真实IP和虚拟IP。判断网络连通性.

　　　　2）在负载均衡器上，检查负载君合器和后端服务器的状态

　　　　3）如LVS集群中有多台后端服务器，分别绑定hosts进行测试每一台后端服务器，确保服务正常。

　　　　4）检查后端服务器的Arp设置是否有效

　　　　5）检查后端服务器上的虚拟IP绑定是否成功。

　　　　6）主从负载均衡器切换故障时，需要首先在交换机上确认其学习到的虚拟IP的MAC地址是否被更新成了从的MAC地址。