聚沙成塔-小哈的记事薄

现在的服务器性能越来越强，内存动辄4G、8G，而32位JDK下，单个java堆一般不超过1.7G。那多出来的内存怎么办？建垂直集群（Vertical clusters：垂直集群是指同一机器上部署多个服务器，充分利用硬件资源）可以，简单的部署多个appserver也行。但是应用如何处理？如果多个项目都需要用相同的context root，比如说/，那怎么办？

其实做过网站的朋友都知道，一台服务器上一般不可能只放一个网站，那如何访问到这些网站，有三种方法：

1. IP不同，一个网卡上绑定多个IP，不同的IP对应不同的网站。
2. 端口不同，不同的网站运行在不同的端口上。
3. 虚拟主机不同，通过不同的虚拟主机名（一般都是域名）来访问。

那对于webshpere或者weblogic，很明显可以实行的是上述第三种方案。部署应用时会让我们选择部署到哪台虚拟主机，默认的都为default host，所以我们只要新建一个虚拟主机，名称一般为域名。那么就能实现通过一级域名直接访问应用。即使一台app server上部署了多个应用。

这种设置对于提供互联网服务的应用尤其有效，因为大家本来就是通过域名来访问的。而且即使只有一个应用，设置非默认的虚拟主机名可以起到只能通过域名来访问，而IP地址访问则会得到应用服务找到的错。虽说提高的安全性不多，但能满足年底全市各部门关于“只能通过域名访问，而IP无法访问”的要求。

至于内网用户，可以在内部dns上配置域名解析，或者编写hosts文件，达到同样效果。

更新：对于webshpere，我测试下来即使不同的虚拟主机，相同的上下文根也无法同时启动。在日志里会看到已经有重复的Context root了，这样的话只能配置apache使用它的虚拟主机解决

工作中经常遇到这样那样的或有迹可循、或“灵异”的情况：WebSphere在某次停止后无法启动了，部署在集群上的应用无法通过IHS访问，应用更新后重启服务器发送回滚……出现问题当然都可以联系专门的中间件管理员来解决，但等管理员赶到现场，也许时间已过去半天，问题也许很简单，几分钟就能解决，所以如果你会一些基本的排查技巧和诊断方法，那么这些小问题就可以自己迎刃而解了。

下面我就介绍几种常见的简单错误，希望对于现场人员能有所帮助：

应用无法访问

下面是一张常见的由IBM HTTP SERVER（IHS）转发到后端AppCluster上的拓扑结构：

应用无法访问，问题可以出现在HTTP Server上，或者App Server上，更可能发生在数据库上，所以第一步需要缩小范围，确定问题发生的点。

我在这里假设IHS的应用地址为http://192.168.1.51/yingyong

DMGR的访问地址是http://192.168.1.51:9060/admin

APP SERVER的应用地址为http://192.168.2.50:9080/yingyong和 http://192.168.2.51:9080/yingyong

1. 找不到服务器或404错误

访问http://192.168.1.51，确定IHS是否正常，如果页面无法显示，那么去“服务”中尝试重启“IBM HTTP SERVER V6.x”。服务启动失败的话，“服务”只会提示你一句服务无法启动或者启动后又因为致命错误停止。所以你要到IBM\HTTPServer\bin目录下运行apache –k start或者httpd –k start，失败的话会有详细信息供参考。一般是端口被占用或者config目录下的httpd.conf格式出错（它会提示你出错的行数）。

如果IHS访问完好，那么尝试分别访问http://192.168.2.50（51）:9080/yingyong，如果访问正常，那么是IHS转发失败。

可以在管理控制台http://192.168.1.51:9060/admin中的“服务器”——“Web服务器”中勾选相应的webserver，“生成插件”并且“传播插件”。

很多IHS转发失败是因为应用发布过程中没有选则发布到webserver上，或在传播插件的过程中，由于目录访问控制等原因传播失败。你可以在“应用程序”中找到自己的应用，点击“管理模块”，确定是否正确的发布到app server上和webserver上了，注意首先在第一个框中选择要发布到集群和服务器，然后勾选模块前的勾，最后一定要点“应用”，而不是直接确定。

转发失败的原因很多，不过最快的解决方法是手动复制文件。生成插件后控制台会提示文件生成的位置，直接拿到然后复制到传播插件失败的位置就可以了。

不过我也遇到过很蹊跷的情况，明明部署正确，传播正确，确依旧无法访问。这时候你要看一下生成的plugin-cfg.xml文件

       是否有你的应用url那行存在，不存在的话手动添加一下即可，不过记得下次生成插件后注意再修改。

       最后要确定app server是否已经启动，是否遇到错误退出了，这点在下面一部分细说。

2. 505 Internal Error

505内部错误有三种情况，一是程序出错，不是本文讨论的重点。二是AppServer或应用程序没有正常启动，三是数据库连接失败。

AppServer是否运行可以通过访问管理控制台，查看JAVA进程确定。在profiles\AppSrv01\logs\server1目录下会有一个pid文件，此文件记录的PID号即为进程号。Windows下在“任务管理器”点击“查看”—“选择列”，勾选PID-进程标识符即可显示。Unix/linux下运行ps –ef | grep PID或者ps –ef | grep java，查看该app的进程和所有的JAVA进程。注意：在安装DM profile的节点上，一般至少有DM、Node agent、app server三个java进程，注意区分。

确定服务器没有运行或者想重启时，在profiles\AppSrv01\bin下运行startServer.sh(bat）即可启动服务器，观察启动状况，直到出现“为电子商务开放服务器 server1”，即为启动成功。如果失败，那就要打开logs下的SystemOut.log，查看最新的日志，查找error信息。

一般启动失败无外乎端口冲突、权限不够。

端口冲突

端口出错在SystemOut.log中的信息如下：

这时你可以用netstat –an 命令查看监听端口信息，然后用tcpview或者icesword等工具查看占用端口的进程，linux/unix下可以用netstat –an | grep LISTEN（或端口号）直接查看，然后使用lsof -i :端口号或者rmsock来查看占用端口的进程。

这时候你也许才恍然想起某个不经意的操作将websphere的端口占用了，怎么办？如果要WebSphere作出让步，那么可以修改profile_path\config\cells\cell_name\nodes\node_name目录中serverindex.xml文件：

看到端口号了么？不过要注意WC_adminhost、WC_defaulthost、WC_adminhost_secure、WC_defaulthost_secure，也就是常用的管理端口、应用访问端口和它们各自的SSL端口，被修改后需要到profile_path\config\cells\cell_name再修改virtualhosts.xml文件中的相应端口（添加亦可），否则出现虚拟主机未定义的错误可别怪我没提醒。（我遇到过很多说用IHS可以访问，但是直接访问端口出错的情况，原因就是没有添加相应的虚拟主机，在管理控制台——虚拟主机——default host里添加改动后的端口就可以了）。

权限不足

权限不足一般发生在Unix/Linux下，比较常见的是安装websphere时新建了一个单独的用户和组，但是开发阶段权限管理不严导致开发人员也有root权限，启停没有su到was用户，等到权限回收之后发现无法启动服务了。这时候只要用root权限chown username/groupname 整个安装 目录即可。

还有一种情况是修改的端口<1024，在Unix/Linux下只能用root来起了。

其它情况

还要注意文件系统的情况，见过几次access.log和dump文件把文件系统撑满的。

应用更新失败

应用更新了，修改的文件直接上传到目录，重启应用程序，测试正常。等等！为何重启app server或者集群下重启dm后又变回修改前了呢？

这应该是dm的同步机制在捣鬼，你有没有注意到profiles\AppSrv01\config\cells\cell_name\applications目录下也有你的程序，打开可以看到并不是程序所有的内容都在此，而是web.xml和WEB-INF等重要内容。所以如果你更新的文件在config目录下也存在，那么你需要这里也更新一份。集群环境下还要注意profiles\Dmgr的config目录下还有一份等着你呢。

3. 确定数据库无故障

这个很简单，只要用sqlplus连接数据库正常且能查询即可。

4. 日志文件很重要

日志文件是排查的依赖。我见过不少项目，因为处于试运行修改阶段，log4j中输出日志信息极多，每条sql语句都丝毫不差的打出来，导致1m大小的SystemOut.log文件十几分钟就写满，10个SystemOut.log存档也顶不过几小时的日志量（单个文件1～2M，总共10～20个存档是一般设置），等我赶到时案发现场已经荡然无存。（这种情况一般是重启能暂时解决问题，但是故障原因没有找到）

所以即时保存当时日志是很重要的，logs\server1下的SystemOut.log、SystemErr.log一定要保存一份，并记下故障发生的时间。

WebSphere不像Weblogic，可以在console窗口后一直看到运行的日志，在unix/linux下，你可以用tail –f SystemOut.log来达到这个效果，windows下也有一个tail工具，后跟文件名运行就可以了。

结束语

暂时能想到的简单排错就这些，这些都比较容易被开发人员遇到，所以还是很有必要了解一下的。

这两天上海38度，脑袋发昏写不出啥东西，就拿以前积攒的内容来充数好了。

在WebSphere Application Server中可以有两个环节可以启用SSL来提高安全性：一是在客户端和IBM HTTP Server（IHS）间启用SSL，二是在IHS和应用服务器之间启用SSL。两个环节可以单独启用，也可以同时开启SSL。

一般我们会在客户端和IHS之间建立SSL连接，因为互联网在信息开放的同时带来了很多安全方面的问题，这点不用我多累述。而IHS一般处在拓扑结构的DMZ区，和互联网之间隔着一层防火墙，应用服务器则处在更安全的内部网络，所以综合安全和响应时间的考虑，IHS和应用服务器之间一般不再采用SSL。

下面两篇文章分别说明了如何在WAS6.0和WAS6.1中使用自签名的证书来开启IHS的SSL，如果是提供互联网服务的话，最好还是购买一下商业CA中心出具的证书，否则跳出个窗口提示证书不安全可就有趣了。

WAS6.0 http://docs.google.com/fileview?id=F.576ac8bd-943c-4de9-a4b0-5f8abd2a477d&hl=zh_CN

WAS6.1 http://docs.google.com/fileview?id=F.4de8195d-6801-450f-8a2c-5ce9ec9990c4&hl=zh_CN

（有别人写的那么好的文档，我就不高兴再自己写鸟，应该可以转的吧）

WAS5.1 下启用SSL方法类似，只是加载的模块为“LoadModule ibm_ssl_module modules/IBMModuleSSL128.dll”

而对申请商业证书，首先要在“个人证书请求”中新建一个请求，填入相关的信息，保存到一个certreq.arm的文件，用文本工具打开后，可以看到

—–BEGIN NEW CERTIFICATE REQUEST—–
MIIBdjCB4AIBADA3MQswCQYDVQQGEwJDTjETMBEGA1UEChMKanFjbHViLm5ldDETMBEGA1UEAxMK
WFpILUhBU0hFSTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAvOZmF3LojJEaAordCmbK9xze
//caxC+0M399AxFUdTbA6HCC8SImRFgItmfBhXt3GsRekCtcbCOxPWmoIr3A9Y6mOMh0uOkQbVVv
EFlbmyxGNha7tBLrFz3l3juRtHiiyXZ2KPUDu8gWFL6tC2DBvoFVaq9ValeX7umAAKpyQ9ECAwEA
AaAAMA0GCSqGSIb3DQEBBAUAA4GBADOtHdOX0UY2GVKw3trjjrlNO4D2wN05cE6SmBm2zJXOrzdz
WKs01TEsnYlEEWS7Z7vRnhgj23eynd646/Kzxb8biipAL0TUcYkEUMRN1+VSFNdmHRGRQIeolGIf
ZzpZk0I1BHQeccHCdFRItNovWMD4XsmBq3WufgRhyNpHmHPQ
—–END NEW CERTIFICATE REQUEST—–

上传这个请求到CA发行商那里并通过后，会得到一个证书，在“个人证书”里接受即可。

当你的网站有许多个应用，而不希望每个应用都启用SSL，同时希望启用SSL的应用禁止通过80端口访问的话，可以通过“虚拟主机”来实现这个目标。

默认的应用都发布在default_host下，你可以新建一个ssl_enable的虚拟主机，在ssl_enable下仅启用443端口，把应用映射到这台虚拟主机上，那么这个应用只能通过443端口来访问了，而别的应用照旧可以在80端口下访问。