WAS集群系列（8）：集群搭建：步骤6：创建概要文件，集群概要
（1）、主机解析地址修改
WAS节点1、WAS节点2、数据库服务器下修改hosts文件
将所有主机的IP映射到各个hosts文件中，举例方法如下：
例：WAS节点WINDOWS环境下
WINDOWS修改：C:\Windows\System32\drivers\etc\hosts
LINUX修改：
[root@hyldbsoft]# vi /etc/hosts
# Do notremove the following line, or various programs
# thatrequire network functionality will fail.
127.0.0.1 xckydb localhost.localdomainlocalhost
::1 localhost6.locaUldomain6localhost6
10.53.105.65 hyldb
10.53.105.66 WIN-IRS49CN78FE
10.53.105.63 WIN-PLDC49NNSAA
（2）、关闭防火墙
确认关闭了应用服务器、数据库服务器的防火墙。
（3）、节点1，创建DM概要文件命令
节点1：
创建DM概要文件：主机名为节点1主机名（节点1作为DM服务器）
参考指令：
manageprofiles-create -profileName Dmgr01 -profilePath “D:/IBM/WebSphere/Appserver/profiles/Dmgr01”-templatePath “D:/IBM/WebSphere/AppServer/profileTemplates/dmgr” -hostnameWIN-PLDC49NNSAA
（4）、节点1，创建应用概要文件
创建应用概要文件：主机名为节点1主机名（节点1作为DM服务器同时也作为应用服务器）
参考指令：
manageprofiles-create -profileName AppSrv01 -profilePath “D:/IBM/WebSphere/AppServer/profiles/AppSrv01”-templatePath “D:/IBM/WebSphere/AppServer/profileTemplates/default” -hostnameWIN-PLDC49NNSAA
（5）、启动节点1相应服务
启动DM(进入到Dmgr路径下执行)
启动server1（进入到AppSrv01路径下执行）
（6）、节点2，创建应用概要文件
创建应用概要文件：主机名为节点2主机名（节点2作为其中一个应用服务器）
参考指令：
manageprofiles-create -profileName AppSrv01 -profilePath “D:/IBM/WebSphere/AppServer/profiles/AppSrv01”-templatePath “D:/IBM/WebSphere/AppServer/profileTemplates/default” -hostnameWIN-IRS49CN78FE
（7）、启动节点2的服务
启动server1：（进入到AppSrv01路径下执行）
补充：如果添加第3个节点
如果需要添加新的节点的概要文件，设置参考本文的第2个节点设置即可。最近中秋临近，小酒小吃倒是接连不断，迷瞪的状态有点懒惰了，
恰好今日倒是闲暇无事，来把这“was集群的搭建”做个阶段性的了解吧，
哈哈。
***********************************************声明************************************************
原创作品，出自 “深蓝的blog” 博客，欢迎转载，转载时请务必注明出处（http://blog.csdn.net/huangyanlong）。
表述有错误之处，请您留言或邮件（hyldba@163.com）指明，不胜感激。
***********************************************待续************************************************
没有集群；base版就一个app server,不支持添加node
希望这能让你们对这类技术有一个初步的认识，以便更好地满足高使用率存储的需求。 建立集群和使用率高的数据存储解决方案有很多选择，但是要想弄清每种选择的优劣则要花点时间进行研究。存储架构和文件系统的选择至关重要，因为大部分的存储解决方案都有严格的限制条件，需要仔细设计工作环境。 基础架构 有些读者也许希望装配一组可以并行访问同一个文件系统的服务器，而另一些读者可能想复制存储器并提供并行访问和冗余。有两种方法可以实现多服务器访问同一个磁盘，一种方法是让那些服务器都可以看到那个磁盘，另一种方法则是通过复制。 共享磁盘结构在光纤通道SAN和iSCSI领域是最常见的结构。配置存储系统相当简单，这样多个服务器就可以看到同一个逻辑块设备或LUN，但是如果没有群集文件系统，那么当多个服务器同时想使用那个逻辑块设备时就会出现混乱。这个问题与使用群集文件系统有关，我们将在下文中详细介绍。 一般而言，共享磁盘系统有个弱点，那就是存储系统。但是情况也并非总是如此，因为利用现在的技术是很难理解共享盘的概念的。SAN、NAS设备和基于Linux系统的商品硬件可以将所有的基础磁盘实时复制到另一个存储节点，从而提供一个模拟共享盘环境。基础模块设备被复制之后，那些节点就可以访问相同的数据，也可以运行同一个群集文件系统了，但是这种复制超出了传统共享盘的定义。 相反，不共享才是共享盘的问题所在。连接着不同存储设备的节点会在每个模块被写入数据时将变化通知给主服务器。现在，不共享架构仍存在于Hadoop那样的文件系统之中，那些文件系统可以在许多节点故意建立多个数据副本，从而提高性能和冗余。而且，在不同存储设备或节点之间利用自己的存储设备进行复制的群集也可以做到不共享。 设计选择 正如我们所说的，你不能通过多个服务器访问同一个模块设备。你听说过文件系统锁定，因此普通的文件系统并不能实现这一点就有些奇怪了。 在文件系统级别上，文件系统本身会将文件锁定以保证数据不会出错。但是在操作系统级别上，文件系统启动程序完全可以访问基础模块设备，它们可以在基层模块设备之间自由的漫游。大部分文件系统都会认为它们被分配了一个模块设备，而且那个模块设备也只是它们自己所有。 为了解决这个问题，集群文件系统采用了一种并行控制机制。有些集群文件系统将把元数据保存在共享设备的一个分区里，另一些集群文件系统则会使用集中式元数据服务器来保存元数据。不管采用哪种方案，集群中的所有节点都可以看到文件系统的状态，从而保证安全的并行访问。然而，如果你想保证系统的高利用率和消除单点故障问题，那么采用集中式元数据服务器的解决方案就要略逊一筹了。 另一个注意事项：集群文件系统要求在节点发生故障时迅速做出反应。如果某个节点写入错误数据或由于某种原因停止关于元数据变化的通信，其他节点必须能够将它隔离出去。隔离可以通过多种方式来实现，最常用的方法是利用断电管理来实现。