保证服务器高可用性-灾难恢复（1）WEB服务器的配置流程

最新推荐文章于 2024-11-15 17:28:37 发布

weixin_30748995

最新推荐文章于 2024-11-15 17:28:37 发布

阅读量101

点赞数

文章标签：操作系统运维网络

原文链接：http://www.cnblogs.com/delly/p/3849767.html

版权

背景：

我们服务器的环境，是ESX server，上面跑了几十台虚拟的服务器。大部分都是虚拟的Windows服务器，然后呢每个应用程序都会有几台APP服务器然后安装Websphere来构建cluster来支持，Web服务器方面呢，既有IBM的HTTP server，也有IIS。

环境就是这样了，这次是为A地区的服务器集群做灾难恢复演练。

所谓灾难恢复呢，就是说假如说A地区的服务器集群所在地出现灾难了，地震了海啸了，怎么办？好，直接把所有的服务器都克隆出来然后恢复到B地区，然后通过配置服务器和应用服务器，模拟出一个完整的A地区的环境（要保证请求可以完整的通过Public IP——>Web服务器——>APP服务器——>DB服务器，并且一切工作正常）。最后改DNS设置，把域名指向新的Public IP就好了。所以这次我们的工作，就是演练这种情况，就类似于火灾演习的那种感觉，这样可以确定服务器集群确实具有高可用性（服务器宕机时间的比例小于多少多少）。

灾难恢复的过程，简单的来说就是以下几步：

把A地区所有的虚拟服务器全部都克隆一下，并且恢复到B地区的ESX server上。
开通防火墙端口，保证服务器之间的联通。
设置服务器的应用部分。

前两步都是固定的套路，按照标准做法做完即可。第3步，应用部分，不确定性就会比较多一点了。

这篇文章只来描述一下其中一台WEB服务器的配置过程。其实WEB服务器算是配置步骤比较多的地方，一方面要接收到来自Public IP的请求，另一方面要保证请求能转发到指定的APP服务器。

这台WEB服务器，既运行着IIS，又运行着很多个IHS（IBM HTTP server）实例。那么WEB服务器配置的目的就很明确了，就是让IIS实例和IHS运行起来，并且分别监听自己对应的新分配的IP和端口，接受请求并转发到正确的APP服务器。

配置过程：

1）设置网卡：

设置的目的呢就是让这一台服务器可以拥有一个物理IP地址和多个虚拟IP地址，然后每个IP地址可以指向到一个WEB server实例（包括IIS和IHS），这样一台服务器就可以通过多个不同的IP来接受请求了。这是比较常用的做法，因为毕竟WEB服务器的功能主要还是转发请求和处理一些静态页面，所以耗费资源很少，一台服务器上有好多个IHS或者Apache实例都是很常见的。

Windows服务器的配置很简单：

打开网络适配器设置，找到这台server的网卡，然后打开属性，双击TCP/IP V4设置。
可以看到IP地址设置的界面了。当然了，一台服务器想要有多个IP地址，当然就不可以用DHCP了，必须得让他有一个固定的物理IP地址。所以就输入IP地址，掩码，网管，DNS服务器。
然后点击高级，出现如图的界面，点击“添加”，直接添加虚拟IP和掩码就好了。加完之后全部点击确定即可完成。
验证一下吧，简单的通过Ping xx.xx.xx.xx（添加的虚拟IP）就可以了。能Ping通就说明是正常了。

接下来配置应用服务器的部分：

在配置之前，需要注意：因为这台虚拟服务器是克隆过来的，所以之前服务器上已经在运行的进程可能也会带到这台服务器上，导致一些不可知的问题。所以在配置之前，先把所有的相关进程全部Kill掉（在Windows中用任务管理器就可以）。

1）首先来配置IIS服务器。

IIS的配置嘛，正常来说，基本上全部都是在那个配置管理工具里面了。只需要右击IIS网站，点击属性，然后点击图中的那个“高级”按钮，就可以把IIS监听的IP地址和对应的80和443端口改掉了。

2）接下来说说IHS的配置。

IHS实际上是基于Apache的Web服务器软件，很多配置基本上都是沿用了Apache的配置方法。

对于一个IHS实例来说，最重要的配置文件其实就是两个：httpd.conf 和 plugin-cfg.xml。

在灾难恢复中，配置过程如下：