一、安装heartbeat 和drbd
主机名修改之后最好重启一下
查看主机server1 和server2 的IP：
配置两台主机的hosts 文件：
yum 这个命令要root 用户才有权限
配置drbd
一般只需要添加红色字体部分
global {
usage-count yes;
}
common {
handlers {
pri-on-incon-degr "/usr/lib/drbd/notify-pri-on-incon-degr.sh; /usr/lib/drbd/notify-emergency-reboot.sh; echo b > /proc/sysrq-trigger ; reboot -f";
pri-lost-after-sb "/usr/lib/drbd/notify-pri-lost-after-sb.sh; /usr/lib/drbd/notify-emergency-reboot.sh; echo b > /proc/sysrq-trigger ; reboot -f";
local-io-error "/usr/lib/drbd/notify-io-error.sh; /usr/lib/drbd/notify-emergency-shutdown.sh; echo o > /proc/sysrq-trigger ; halt -f";
}
startup {
}
options {
}
disk {
}
net {
protocol C;
}
}
resource r0 {
on server1 {
device /dev/drbd1;
disk /dev/sda2;
address 192.168.1.123:7789; # 主机server1 的ip meta-disk internal;
}
on server2 {
device /dev/drbd1;
disk /dev/sda2;
address 192.168.1.129:7789; # 主机server2 的ip meta-disk internal;
}
}
Drbd 管理：
两台主机启动drbd
两台主机查看drbd 状态：
设置server1 为主节点，并格式化和挂载目录
配置heartbeat
ha.cf 主配置文件
haresource 资源管理文件authkeys 心跳加密文件
配置主机其中一张网卡的静态IP：
配置ha.cf
debugfile /var/log/ha-debug //调试日志位置
logfacility local0
keepalive 2 //2秒检测一次心跳连接
deadtime 30 //多长时间检测不到主服务器心跳为有问题，不要设置太低warntime 10 //警告时间(最好在2-10秒)
initdead 120 //初始化启动时，120秒内无链接为正常
udpport 694 //使用udp 694做为bcast/ucast通讯端口
ucast eth3 10.0.0.201 //单播方式连接，eth1是本身对应的心跳网卡主从都写对方的心跳ip
auto_failback on //开启自动切换，主服恢复后，自动切换回来
node s erver1 //申明主服，注意是uname -n的完全限定域名
node s erver2 //申明备服，注意是uname -n的完全限定域名
ping 192.168.1.254 // ping 的是网关
crm respawn
apiauth mgmtd uid=hacluster
respawn root /usr/lib64/heartbeat/mgmtd -v
配置authkeys
auth 1
1 crc
chmod 600 authkeys命令设置authkeys 权限（authkeys 的权限一定要设置，不然日志报错）配置haresources
注：该文件内IPaddr,Filesystem等脚本存放路径在/etc/ha.d/resource.d/下,也可在该目录下存放服务动脚本（例如：mysqld）,将相同脚本名称添到/etc/ha.d/haresources内容中，从而跟随heartbeat启而启动该脚本。
IPaddr::192.168.1.100/24/eth2：用IPaddr脚本配置浮动VIP
drbddisk::r0：用drbddisk脚本实现DRBD主从节点资源组的挂载和卸载
Filesystem::/dev/drbd0::/data::ext4：用Filesystem脚本实现磁盘挂载和卸载
二、安装MYSQL
以下方法是解决上上面报错问题的方法：
登录mysql
注意：@ 左边是用户名，右边是域名、IP或%，表示可以访问mysql 的域名和IP，% 表示外部任何地址都能访问。
修改mysql 的默认引擎为InnoDB
停止mysql，命令service mysqld stop
编辑https://www.doczj.com/doc/5c14852036.html,f
配置好heartbeat之后，因为主heartbeat启动的时候会挂载drdb文件系统以及启动mysql，切换的时候
会将主上的mysql停止并卸载文件系统，从上会挂载文件系统，并启动mysql。因此需要做如下操作
（两台服务器）：
到这里heartbeat+drbd+mysql高可用环境就搭建结束了。接下来进行测试。
高可用测试：
启动 server1 主机上的 mysql
查看data 目录发现只有存放数据的mysqldata 目录
启动drbd (两台服务器)：
查看drbd 的状态：
设置server1 为主机，并挂载
启动heartbeat（两台服务器）：
查看非心跳网卡的IP：
可以看见虚拟ip 192.168.1.100已经存在了。说明成功了。我们看看heartbeat的日志就能发现。
先看看两台服务器的状态：
构建高可用性HIS 近几年来，我国的HIS系统建设已从单纯的经济管理逐步向以病人为中心的临床应用发展，如联机检验数据采集、PACS系统以及电子病历等等，使医院对HIS系统的依赖程度越来越高，这就要求HIS系统需要达到7X24小时永不间断地高效可靠运行，计算机集群系统能够较好地满足这一要求。 1集群系统及其基本架构 1.1 集群的概念 集群就是把多个独立的计算机连接在一起，面对客户机作为一个虚拟整体，使整个系统能够提供更大的可用性、更好的可伸缩性和更强的容灾能力。 1.2 集群系统的基本构成 一个集群系统通常由多个服务器(或称为节点)、共享存储子系统和使节点可以进行信息传递的内部节点连接构成。图1为两节点集群的基本架构。 每个集群节点具有两类资源：非共享资源和共享资源。非共享资源包括安装网络操作系统的本地硬盘、系统页面文件（虚拟内存）。本地安装的应用程序，以及特定节点访问的各种文件。共享资源包括存储在共享设备中的文件，每个集群节点使用共享存储系统访问集群的quorum资源和应用程序数据库等。 1.3 集群系统中的几个重要组件 ①后台共享存储设备：所有的节点都必须与至少一个集群系统的共享存储设备相连。共享存储设备将存储集群本身的系统数据及应用程序所产生的数据。 ②集群内部网络通讯：这个网络提供信息传递的服务，被称为心跳网络，它用来传递各个节点的状态。内部连接可采用高带宽的通讯机制（例如千兆以太网），以确保集群中的节点可以快速交换信息和同步数据。 ③公共网络：为客户端提供访问服务的网络，这个网络为其它的应用服务提供必要的网络通讯基础。 ④虚拟的前台界面：所有的节点被合为一组，有一个虚拟的服务器名称，为了管理集群系统，也需要为集群提供一个名称。应用程序在集群环境下运行的时候，也需要创建自己的虚拟服务器名称，便于客户端的访问。 1.4 集群中节点的运行模式 在集群中节点可以有几种运行模式，取决于实际应用环境。 ①Active/passive模式。在两个节点集群环境中，其中一个集群节点处理所有集群应用请求而另外一个节点则只简单地等待那个起作用的节点失效。这种Active/passive集群方式从性能价格比方面来讲并不合算，因为其中一个服务器在大多数时间处于空闲状态。但在失效时应用可以完全使用另一个服务器的处理能力，所以这种配置比较适用于一些关键业务环境。 ②Active/active模式。在集群中每一个节点都作为一个虚拟的服务器，当一个应用运行在节点A时，节点B不需要处于空闲状态以等待节点A的失效，节点B可以在为节点A的资源提供失效恢复能力的同时运行它自己的集群相关应用。由于这种模式各个系统都是独立运行，因此在资源的应用上其效率要更高一些。但一个Active/active方式的节点必须具备相应的能够处理两个节点上的负载的能力（在发生失效恢复事件时），否则接管了失效节点的服务也会很快因不堪重负而垮掉。 ③3-active/passive模式。Microsoft Windows 2000 Datacenter Server支持这种配置方式，由三个服务器共同作为一个虚拟服务器运行，第四个服务器作为备份服务器，当虚拟服务器中任何一个服务器出现故障，备份服务器接管其原有的应用和资源。这种集群环境提供更强大的处理能力，适用于更高的企业用户需求，能够满足更多的客户访问。
1.业务连续 1.1.共享存储集群 业务系统运营时，服务器、网络、应用等故障将导致业务系统无常对外提供业务，造成业务中断，将会给企业带来无法估量的损失。针对业务系统面临的运营风险，Rose提供了基于共享存储的高可用解决方案，当服务器、网络、应用发生故障时，Rose可以自动快速将业务系统切换到集群备机运行，保证整个业务系统的对外正常服务，为业务系统提供7x24连续运营的强大保障。 1.1.1.适用场景 基于共享磁盘阵列的高可用集群，以保障业务系统连续运营 硬件结构：2台主机、1台磁盘阵列
主机 备机心跳 磁盘阵列 局域网 1.1. 2.案例分析 某证券公司案例 客户需求分析 某证券公司在全国100多个城市和地区共设有40多个分公司、100多个营业部。经营围涵盖：证券经纪，证券投资咨询，与证券交易、证券投资活动有关的财务顾问，证券承销与保荐，证券自营，证券资产管理，融资融券，证券投资基金代销，金融产品代销，为期货公司提供中间介绍业务，证券投资基金托管，股票期权做市。 该证券公司的系统承担着企业的部沟通、关键信息的传达等重要角色，随着企业的业务发展，系统的压力越来越重。由于服务器为单机运行，如果发生意外宕机，将会给企业的日常工作带来不便，甚至
给企业带来重大损失。因此，急需对服务器实现高可用保护，保障服务器的7×24小时连续运营。 解决方案 经过实际的需求调研，结合客户实际应用环境，推荐采用共享存储的热备集群方案。部署热备集群前的单机环境：业务系统，后台数据库为MySQL，操作系统为RedHat6，数据存储于磁盘阵列。 在单机单柜的基础上，增加1台备用主机，即可构建基于共享存储的热备集群。增加1台物理服务器作为服务器的备机，并在备机部署系统，通过Rose共享存储热备集群产品，实现对应用的高可用保护。如主机上运行的系统出现异常故障导致宕机，比如应用服务异常、硬件设备故障，Rose将实时监测该故障，并自动将系统切换至备用主机，以保障系统的连续运营。
高可用性集群系统的实现 《Linux企业应用案例精解》第8章主要介绍一下虚拟化技术应用。本节为大家介绍高可用性集群系统的实现。 8.3.5 高可用性集群系统的实现（1） VMware Infrastructure 的体系结构和典型配置 资源动态分配和高可用性的实现为构建高可用性集群系统提供了有力的保障，采用VMwae构建铁路企业高可用性集群，不需要为系统中的每台服务器分别添置备用服务器，就可以有效地降低系统成本，在基于VMware的我企业高可用性集群中，备用服务器安装了VMware ESX Server，与数据库服务器、Web服务器、OA服务器和文件服务器等构成高可用性集群，同时采用数据库备份服务器实现差额计划备份。 使用VMware提供的虚拟基础架构解决方案，服务器不再需要随着业务增加而添加，整个IT基础架构能得到有效控制并可充分发挥效能。只有当整体资源出现不足的时候，才需要增加服务器。而且对系统资源的
添加也非常简单，不再需要做繁琐的硬件维护以及业务迁移，只需要简单地将新服务器安装VMWARE? INFRASTRUCTURE 3软件，并添加到已有的VMWARE? INFRASTRUCTURE 3架构中即可，新增资源将自动分配到各个最需要的业务环境中。 在HA和DRS功能的共同支撑下，虚拟机的稳定、不间断运行得到了保证，而且，在没有搭建Cluster环境的情况下，迁移、升级依旧能不中断服务。哪怕是硬件升级、添加，正常停机维护等情况，也能够保证所有的业务正常运行，客户端访问服务器不产生业务中断现象。新的服务器虚拟化架构中另一个重点是VMware HA 的部署，它是整个服务器系统安全、可靠运行的一道防线。传统的热备机方式最大的问题就是容易造成资源的大量闲置；在正常运行状态下，所有备机服务器都处于闲置状态，不仅造成计算资源的空耗，而且还浪费大量的电力和散热资源，投资回报率非常低。 如何应对Linux系统软件包的依赖性问题 不管是初步跨入Linux殿堂的新手还是，具有多年经验的专家，在安装或编译软件包的过程中或多或少的都会遇到包的依赖问题从而导致安装过程无法继续，比如管理员在安装php软件包需要libgd.so文件，而这个文件属于gb软件包。但是在安装gb软件包时，可能这个软件包跟其他软件包又具有依赖关系，又需要安装其他软件包才行。这时有的管理员便失去耐心。在遇到这种Linux软件包依赖关系问题，该如何解决呢?在谈这个具体的措施之前，先跟大家聊聊Linux系统里的软件爱你依赖性问题。 我们把处理rpm依赖性故障的策略可以分成两类解决依赖性故障的自动方法和手工方法。但当安装不属于发行一部分的软件包时自动方法是不可用的。在描述如何手工解决依赖性故障后，将简要描述如何使用自动方法之一（YUM），但首先需要了解它们是什么及rpm如何强制实施它们。 一、什么是依赖性 程序依赖于程序代码的共享库，以便它们可以发出系统调用将输出发送到设备或打开文件等（共享库存在于许多方面，而不只局限于系统调用）。没有共享库，每次程序员开发一个新的程序，每个程序员都需要从头开始重写这些基本的系统操作。当编译程序时，程序员将他的代码链接到这些库。如果链接是静态的，编译后的共享库对象代码就添加到程序执行文件中；如果是动态的，编译后的共享库对象代码只在运行时需要它时由程序员加载。动态可执行文件依赖于正确的共享库或共享对象来进行操作。RPM依赖性尝试在安装时强制实施动态可执行文件的共享对象需求，以便在以后--当程序运行时--不会有与动态链接过程有关的任何问题。
技术方案书
目录 一、概述 (3) 二、项目需求 (3) 三、网络建设方案 (4) 3.1无线网络基础方案 (5) 方案逻辑组网图 (5) WLAN产品优势概述 (5) 产品的选型 (6) 3.2无线网络安全 (8) 四、产品说明 (9) 4.1 EWP-WA2612-AGN无线接入点 (9) 4.2 H3C WX3024系列无线控制器 (13)
一、概述 无线局域网（WLAN）技术于20世纪90年代逐步成熟并投入商用，既可以作传统有线网络的延伸，在某些环境也可以替代传统的有线网络。对比传统的有线传输解决方案，使用WLAN网桥实现数据传输具有以下显著特点： 简易性：WLAN网桥传输系统的安装快速简单，可极大的减少敷设管道及布线等繁琐工作； 灵活性：无线技术使得WLAN设备可以灵活的进行安装并调整位置，使无线网络达到有线网络不易覆盖的区域； 综合成本较低：一方面WLAN网络减少了布线的费用，另一方面在需要频繁移动和变化的动态环境中，无线局域网技术可以更好地保护已有投资。同时，由于WLAN技术本身就是面向数据通信领域的IP传输技术，因此可直接通过百兆自适应网口和企业内部Intranet 相连，从体系结构上节省了协议转换器等相关设备； 扩展能力强：WLAN网桥系统支持多种拓扑结构及平滑扩容，可以十分容易地从小容量传输系统平滑扩展为中等容量传输系统； 二、项目需求 a) 本工程具体的建设目标是： 1、采取通行的网络协议IEEE 802.11g标准，选取合理的无线覆盖方案，从而实现对各楼层相应区域的WLAN信号覆盖，提供稳定可靠的无线宽带网络接入服务； 2、全面的无线网络支撑系统（包括无线安全、无线QOS等），以避免无线设备及软件之间的不兼容性或网络管理的混乱而导致的问题； 3、保证网络访问的安全性，支持用户多种接入方式认证机制,包括：基于PPPoE、802.1X、Portal、MAC等认证，支持外置的Portal服务器和外置的AAA服务器系统； 4、无线宽带网络将来应该能够支持WIFI语音、IPTV等增值业务； 5、安全、认证和管理要求。为了阻止非授权用户访问无线网络，以及防止对无线局域网数据流的非法侦听，无线网络要具有相应的安全手段，主要包括：物理地址（MAC）过滤、服务区标识符(SSID)匹配、AES加密，双向认证等方式。
甲骨文最高可用性架构 骨 最高 用性架构 Maximum Availability Architecture
议程表
? ? ? ? ? 甲骨文简介 高可用性介绍 传 高 用性分析 传统高可用性分析 甲骨文高可用性方案介绍(MAA) 客户成功案例分享
2
Oracle公司概揽
总揽
? ? ? ? ? ? 从08财年收入$22.4B，11财年收入35.6B 在40多项产品或市场领域占据业界第一 320,000客户跨越145国家 10W员工规模 (1 in i 3 joined j i df from acquisition) i iti ) Oracle在线社区上有超过五百万开发者 34年从业经验
革新和创新
? 超过3,000 3 000个产品，拥有 个产品 拥有2,000 2 000多个专利 ? 09财年投入$3B 研发和测试资金 ? 7,500 售后支持人员, 支持27国语言
3
今天的甲骨文公司
? 全球最大的企业软件供应商 ? 数据库市场占有率第一 ? 中间件市场占有率第一 ? 应用软件市场占有率第一 ? 服务器市场占有率第三 ? 开源产品的领军者 ? 虚拟化产品的竞争者 ? 云计算方案供应商
FAST?=?FusionMiddleware Applications System Tech
4
议程表
? ? ? ? ? 甲骨文简介 高可用性介绍 传 高 用性分析 传统高可用性分析 甲骨文高可用性方案介绍(MAA) 客户成功案例分享
5
高可用性系统部署方案 2010年2月5日 1.1 概述 1.1.1 前言 在金融工程系统应用中，对服务器的安全性、可靠性要求较高，在服务器故障情况下，要求尽可能短的时间内恢复运行，并且能对故障发生时的数据进行恢复和处理，而能否实现这一功能是一个系统是否达到高可用性的主要指标。
高可用性可体现于应用系统和数据库存储两部分，应用系统部分重点是主备机达到故障自动切换，而数据存储部分注重数据的完整性、安全性和故障转移。 1.1.2 目前情况 股指套利、算法交易、交易网关等系统在使用上需要作整个架构部署的高可用性考虑，但目前只是部分或没有作整个系统的高可用性方案及实现。 1.1.3 参考文档 附件：SQL2005数据镜像方案测试报告_20100204.doc 1.2 高可用性需求 即要实现高可用性，又要控制成本投入，实施部署也要可操作性强是这次方案的主要目标，基于此目标，本方案对成本很高的共享磁盘阵列的故障转移群集和第三方商业故障系统不作为实现技术方案。 本方案解决的高可用性需求如下： 1、应用主服务器故障发生时，连接能够短时间内自动连接到备机继续工作。 2、数据库主服务器发生时，备机上要有完整的数据，并且连接到主数据库的连 接会话能很快的重新连接到备机上继续工作 3、应用系统和数据库的服务器均能达到自动故障切换转移，以达到快速故障恢 复的目的。 4、服务器数量尽可能少，成本投入不能太高。 1.3 解决方案 出于安全和可靠性考虑，建议数据库和应用系统部署在不同的服务器上，以减少性能上的彼此影响。以算法交易服务应用为例，在母单下得较多的时候会出现系统CPU和内存上的较大消耗，如果再加上数据库的占用资源，很容易出现系统负载过重，故在方案中将应用系统与数据库分布在不同服务器，便于管理及提高整体性能。
关于系统稳定性策略的探讨 1.前言 系统作为业务系统的核心，其运行稳定性和高可用性至关重要。因此，需要通过高可用性设计来尽量减少系统的计划内和计划外停机，并在系统出现故障时及时响应、快速恢复，以保障关键数据和业务系统的运行稳定性和可持续访问性。其中： 1.计划内停机是指管理员有组织、有计划安排的停机，比如升级硬件微码、升 级软件版本、调整数据库库表、更换硬件设备、测试系统新功能等时，可能需要的停止系统运行。 2.计划外停机是指非人为安排的、意外的停机，比如当硬件出现重大故障、应 用程序停止运行、机房环境遭到灾难性的破坏时所引起的业务系统停止运行。 目前，对于计划内和计划外停机，可通过消除系统中的单点失效来尽量减少停机时间。同时，通过采用可在线维护（固件升级、在线扩充、故障部件更换）的设备，并通过负载均衡机制实现应用系统的在线升级、维护，将有效消除计划内停机对业务系统的影响。此外，由于系统中采用了全面的负载均衡设计，并针对系统失效提供了可靠的数据备份恢复和多点容灾保护，因而能够有效减少系统计划外停机的恢复时间。 在造成系统宕机的原因方面，有统计中表明并非都是硬件问题。其中，硬件问题只占40％，软件问题占30％，人为因素占20％，环境因素占10％。因此，高可用性设计应尽可能地考虑到上述所有因素。对于系统而言，其整体的可用性将取决于内部的应用系统、主机、数据库等多种因素；同时，训练有素的系统维护人员和良好的服务保障也是确保系统稳定运行和故障快速恢复的关键。 2.应用系统 系统在应用软件架构设计中应从渠道层、渠道管理层、业务处理层等不同
层面通过多种措施和策略的综合设计来提高应用系统的高可用性和稳定性。 在渠道管理层和业务处理层的设计中，要考虑设置应用负载均衡、应用软件失效备援、vip服务通道、流量控制、故障隔离等机制。 1.应用负载均衡 应用软件负载均衡通过多个层次上不同的负载均衡策略一起实现整体的负载均衡，应用负载均衡的设计思路是将大量的并发访问或数据流量分担到多台节点设备上分别处理和将单个重负载的运算分担到多台节点设备上做并行处理来达到负载均衡的效果，从而提高服务响应速度，提高服务器及其他资源的利用效率，避免服务请求集中于单一节点导致拥塞。 2.应用软件失效备援 应用软件构建在面向服务的架构、设计思想上，应用服务具有较高的可灵活部署性。通过这种灵活性，结合系统基础设施的规划、部署可以实现应用软件的失效备援。系统可以考虑实现基于应用服务和基于应用服务管理框架的多种应用软件失效备援机制。 基于应用服务的失效备援是在应用服务管理框架中可以实现应用服务的冗余部署，利用硬件负载均衡设备或应用软件负载均衡可以在需要时将服务请求切换到相应的冗余服务。 基于应用服务管理框架的失效备是将应用服务框架在系统中冗余部署，利用硬件负载均衡设备或应用软件负载均衡可以在需要时将服务请求切换到相应的冗余的应用服务管理框架。 3.vip服务通道 在系统中，从系统运行稳定性、持续性及处理性能的角度，配合物理设备、系统支撑软件（数据库系统、操作系统）的相关措施，应用软件可通过构建VIP服务通道的方式降低应用服务运行期间的相互影响。服务通道可以基于不同业务产品或不同应用服务管理框架的不同粒度来设置，从而满足部分应用处理资源只响应特定的服务请求或不同的服务监听响应不同的通道传递过来的服务申请的功能。 4.流量控制 在系统中，从系统运行稳定性、持续性角度，配合物理设备、系统支撑软
如何构建高可用性高扩展性的系统
1高可用性 1.1避免故障 1.1.1明确使用场景 保持系统简单 1.1.2设计可容错系统 Fail Fast原则 主流程任何一步出现问题，就应该快速结束接口和对象设计要严谨 能否被重复调用 多线程并发环境下是否有异常 对象类型是否需要检查 1.1.3设计具备自我保护能力的系统对第三方资源持怀疑态度，提供降级措施1.1.4限制使用资源 内存
防止集合容量过大造成OOM 及时释放不再使用的对象 文件 网络 连接资源 线程池 1.1.5其他角度 分析可能的风险 1.2及时发现故障 1.2.1监控报警系统 1.2.2日志系统和分析系统1.3及时故障处理 1.3.1降级 1.3.2限流 1.4访问量上涨的应对策略
1.4.1垂直伸缩 增加配置 1.4.2水平伸缩 增加机器 1.4.3拆分 按业务拆库 按规则拆表 1.4.4读写分离 实时性要求不高、读多写少的系统如何快速地从写库复制到读库 1.4.5其他 容量规划 2高可扩展性 2.1垂直伸缩 2.1.1高访问量
增加CPU 锁 线程数 单线程程序 增加内存 cache JVM堆 2.1.2大数据量 分表 单表数据量减少 跨表查询、分页查询复杂度提升2.1.3计算能力 线程数提升 2.2水平伸缩 2.2.1高访问量
SNA（Shared Nothing Architecture）有状态的部分，放入缓存或数据库中有状态的情况 存在内存的状态 广播同步 例如session同步 单台机器容量有限 分布式缓存 一致性hash 文件 直连存储DAS((Direct-Attached Storage) 网络存储 NAS(Network Attached Storage) SAN(Storage Area Network) 分布式文件系统 GFS HDFS 数据库问题 cache
协和医院西区住院部无线网络覆盖 技 术 建 议 书 东风通信技术有限公司武汉分公司 2012-9-5
目录 一、概述 (4) 二、项目需求 (4) 三、网络建设方案 (6) 3.1无线网络基础方案 (9) 3.1.1方案逻辑组网图 (9) 3.1.2 H3C WLAN产品优势概述 (10) 3.1.3产品的选型 (11) 3.2、各楼层AP部署图 (13) 3.2.1AP部署说明 (13) 3.2.2无线网络安全 (13) 3.3无线用户接入管理 (16) 3.4无线网络QOS (17) 3.4.1漫游切换支持 (17) 3.5无线网络管理 (18) 3.5.1总体需求 (18) 3.5.2集中网络管理 (18) 3.6频率规划与负载均衡 (18) 3.7供电问题 (20) 3.8覆盖区域详细说明 (20)
3.9网管软件-iMC WSM无线运营管理组件 (21) 3.9.1无线有线一体化管理 (21) 3.9.2多样化的拓扑管理 (22) 3.9.3无线终端查看和漫游记录审计 (23) 3.9.4 RF覆盖管理 (23) 3.9.5无线定位与GIS管理功能 (24) 3.9.6基于物理位置的无线终端准入控制 (25) 3.9.7AP上联设备查询 (26) 3.9.8主备AC管理 (26) 3.9.9无线入侵检测和防护 (27) 3.9.10丰富的无线统计报表 (27) 四、产品说明 (28) 4.1 EWP-WA2612-AGN无线接入点 (28) 4.2 H3C WX3024系列无线控制器 (36)
一、概述 无线局域网（WLAN）技术于20世纪90年代逐步成熟并投入商用，既可以作传统有线网络的延伸，在某些环境也可以替代传统的有线网络。对比传统的有线传输解决方案，使用WLAN网桥实现数据传输具有以下显著特点： 简易性：WLAN网桥传输系统的安装快速简单，可极大的减少敷设管道及布线等繁琐工作； 灵活性：无线技术使得WLAN设备可以灵活的进行安装并调整位置，使无线网络达到有线网络不易覆盖的区域； 综合成本较低：一方面WLAN网络减少了布线的费用，另一方面在需要频繁移动和变化的动态环境中，无线局域网技术可以更好地保护已有投资。同时，由于WLAN技术本身就是面向数据通信领域的IP传输技术，因此可直接通过百兆自适应网口和企业内部Intranet相连，从体系结构上节省了协议转换器等相关设备； 扩展能力强：WLAN网桥系统支持多种拓扑结构及平滑扩容，可以十分容易地从小容量传输系统平滑扩展为中等容量传输系统； 二、项目需求 协和医院西区前生是东风汽车公司神龙医院，地处武汉西南部，武汉经济技术开发区中心地段，规划用地80亩，已有建筑面积1.8万平方米，实际开放病床220 张。西区建有临床、医技科室19个，设置综合重症监护、综合外科、创伤外科、综合内科、妇产科、五官综合（含整形美容）7个独立病区。各科室主任均由医院本部教授担任，另有一大批国内知名专家长期在这里工作。西区拥有国际先进的多排螺旋CT、全自动生化分析仪、五分类血球仪、全自动麻醉机等多种高端手术设备，并实现了与本部医学信息共享、区域内实时远程会诊的能力。病区还配备有中心供养、中心吸引、中央空调、中心传呼和病房独立卫生间，环境优美，四季常青，被誉为花园式医院。 西区总体规划建筑面积近20万平方米，设计年门诊量80万人次、开放床位2000张。其中，一期工程即投资4.6亿元的外科住院大楼已经完成前期准备，即将破土动工。 该院负责人表示，将利用2年至3年的时间，把西区建成拥有1200张病床、以急救创伤医学为特色的大型综合性三甲医院，成为武汉西南部的医疗中心。
SQL server高可用方案 一、高可用的类型 ●AlwaysOn 高可用性解决方案，需要sql server 版本在2012以上 SQL Server AlwaysOn 即“全面的高可用性和灾难恢复解决方案”。客户通过使用AlwaysOn 技术，可以提高应用管理方面的工作。 SQL Server AlwaysOn 在以下2个级别提供了可用性。 *数据库级可用性 是一种“热备份”技术。在同步提交模式下，主副本的数据被同步更新到其他辅助副本，主副本与辅助副本之间可以时，辅助副本可以立即成为新的主副本。 *实例级可用性 AlwaysOn 故障转移群集实例（Failover Cluster Instance，简称FCI）可以在多个16个节点之间实现故障转移（版只支持2个节点。 当主节点发生故障时，辅助节点提升为主节点并获取共享存储中的数据，然后才在这个新的主节点服务器中启动FCI 是一种“冷备份”技术。辅助节点并不从主节点同步数据，唯一的一份数据被保存在共享存储（群集共享磁盘）●日志传送 日志传送依赖于传统的Windows 文件复制技术与SQL Server 代理。 主数据库所做出的任何数据变化都会被生成事务日志，这些事务日志将定期备份。然后备份文件被辅助数据库所属最后事务日志备份在辅助数据库中进行恢复，从面实现在两个数据库之间异步更新数据。 当主数据库发生故障时，可以使辅助数据库变成联机状态。可以把每一个辅助数据库都当作“冷备用”数据库
●其它辅助技术 对数据库进行备份，当出现故障时，手动将数据还原到服务器，使得数据库重新联机，这也可以算作实现高可用性复制（Replication）并不算是一个高可用性解决方案，只是它的功能可以实现高可用性。复制通过“发布-订阅”模式服务器间实现可用性。 SQL server复制 定义及应用：数据库间复制和分发数据和数据库对象，然后在数据库间进 过局域网和广域网、拨号连接、无线连接和Internet 将数据分配到不同位sql server复制分成三类： 事务复制通常用于需要高吞吐量的服务器到服务器方案（包括：提高可伸 点的数据、集成异类数据以及减轻批处理的负荷）。 合并复制主要是为可能存在数据冲突的移动应用程序或分步式服务器应用 交换数据、POS（消费者销售点）应用程序以及集成来自多个站点的数据 快照复制用于为事务复制和合并复制提供初始数据集；在适合数据完全刷二、高可用的服务器配置： 如果只是需要复制方式，则搭建两台相同硬件配置和操作系统版本与补丁 如果需要AlwaysOn 高可用方式，即出现故障后系统自动进行切换到备用 服务器、从服务器)相同硬件配置和操作系统版本与补丁、相同数据库版本三、各种实现方式的对比 下表将SQL Server 常用的高可用性解决方案进行综合对比。
高可用报告 一、 高可用分析 1、三个概念 失效(fault)：指设备或程序自身固有缺陷导致的瞬间或永久性的功能失常。 错误(error)：由失效导致的系统内部不正确行为。错误可以被发现并进行纠正。 故障(failure)：指由于出现错误导致了系统产生了不正确的结果。 2、平均故障发生时间MTTF ( Mean Time To Failure ) MTTF 是一个统计上可测量的参数 MTTF 寿命 MTTF= 1 / 稳态运行期间的故障发生率 N 台机器T 时间内故障数: E = (N ×T)/ MTTF 3 可靠性: 系统连续提供服务的能力，MTTF: Mean Time To Failure 可维护性:修复故障使系统恢复正常的能力，MTTR: Mean Time To Repair 4、可用性(Availability) 可用性= MTTF / (MTTF + MTTR) 例: MTTF=5000小时, MTTR=1天, 则可用性为： 5000/(5000+24) = 99.52% 5、提高可用性的途径 1) 提高 MTTF 2) 降低 MTTR 二、硬件高可用 （一） Cluster 中硬件HA 的目标 1、 问题的起源：单点故障问题及其应对策略
单点故障：某些硬件或软件部件，它们的故障会导致整个系统的崩溃。[6] 机群系统可能出现的单点故障有： ●处理器或节点 ●存储程序或数据的磁盘 ●适配器、控制器和连接节点到磁盘的电缆 ●用户访问机群节点的网络。 ●应用程序 应对策略：通过系统地消除那些单点故障来尽可能使更多的故障成为部分故障。[6]解决机群中的单点故障问题：解决大多数的单点故障问题并不需要使用任何分层软件产品。计算从任何特殊错误中恢复所需人工干涉的总时间和精力。然后再考虑系统能否承受停机造成的损失，以及能否提供全天操作中必须的人工干预。对于机群设计者而言，这将有助于决定是使用人工干预来管理还是需要采取其它措施来满足高可用性的要求。 ?节点故障 在机群中，当一个节点提供的服务是关键性的话，那么当该节点失效时，机群中必须有另外的节点来代替它的资源，向终端拥护提供相同的服务。 包括以下步骤： 1、在备用节点的网络适配器配置失效节点的地址，或者提示用户（或改变客户端应用程序） 使用一个替换的地址。 2、在故障和备用节点之间引入和改变所有组的卷，并且装上所有需要的文件系统。 3、修复存储在故障节点内部磁盘上的所有应用程序和数据。 4、执行任何鉴定性的应用程序。 假定后备节点在关键服务中还没有被网络访问。这样，每个节点需要额外的网络适配器，这个节点将被备份。如果用户通过串行连接访问失效节点，每个终端应该物理上重连接到后备节点的端口上。如果外部磁盘没有连接到失效节点和后备节点之间的通用总线上，则需要手工将他们从一个转换到另一个。所有关键数据被保存在外部磁盘上。如果最后的后备节点变为不可用，所有关键数据则被保存至节点的内部磁盘。 ?磁盘和I/O总线故障 为了防止包括磁盘的外部I/O通道中的任何部分出错，应该在两路I/O总线上将磁盘镜象或者使用从节点到存储子系统有双重路径的磁盘阵列系统。 ?网络适配器故障 为了防止网络适配器故障，每个提供关键服务的节点需要配置备用网络适配器。这个适配器连接到与用户正在访问的主适配器相同的网络主干上。如果网络适配器失效，可以将备用适配器的地址改为失效适配器的地址。另外一种方法是始终有一个热备份的网络适配器可以随时替代出错适配器。这种方法从故障中恢复的时间更短，因为系统安装备用适配器无需停机。 ?网络故障 如果用户正在和一个节点通信时网络主干停止工作，解决方案之一是人工地将所有机群节点和客户端机器切换到另外一个主干上。即便有足够的时间和精力去这样做，还得保证没有松散的连接或网络设备（路由器、集线器或网桥）故障引起主干失效。另外一个解决方案是连接一个终端的子集到备用节点的串口上，这样还可以提供最小级别的服务。在这种情况下应用程序必须被设计成允许用户既可以通过网络连接到终端也可以通过串口连接到终端。 ?应用程序故障 根据应用程序的设计，为监控应用程序使用的后台程序，并及时对状态改变作出反应，应该使用AIX子系统资源控制器。 2、人工干预的缺点 根据上述的讨论，依据故障的不同类型。包括检测故障所花时间，很明显从任何机群故障中人工恢复的时间为30分钟到几个小时。这对许多应用在重要场合的机群来说已经是不可容忍的了。
RoseHA 高可用性系统解决方案
————————————————————————————————作者：————————————————————————————————日期： 2
RoseHA 高可用性系统解决方案 RoseHA 高可用性系统解决方案以低成本且简便的方式，实现了两个节点的Cluster环境.客户只需要在 原有的单机系统上增加一台服务器、一个共享存储设备，通过Rose基于共享存储的高可用解决方案即 可实现关键业务的7X24小时连续运行，对于需要更有效应用现有服务器资源的用户而言，是最为适用 的解决方案。 RoseHA的工作原理 RoseHA双机系统的两台服务器（主机）都与磁盘阵列（共享存储）系统直接连接，用户的操作系统、应用软件和RoseHA高可用软件分别安装在两台主机上，数据库等共享数据存放在存储系统上，两台主机之间通过私用心跳网络连接。配置好的系统主机开始工作后，RoseHA软件开始监控系统，通过私用网络传递的心跳信息，每台主机上的RoseHA软件都可监控另一台主机的状态。当工作主机发生故障时，心跳信息就会产生变化，这种变化可以通过私用网络被RoseHA软件捕捉。当捕捉到这种变化后RoseHA 就会控制系统进行主机切换，即备份机启动和工作主机一样的应用程序接管工作主机的工作（包括提供TCP/IP网络服务、存储系统的存取等服务）并进行报警，提示管理人员对故障主机进行维修。当维修完毕后，可以根据RoseHA的设定自动或手动再切换回来，也可以不切换，此时维修好的主机就作为备份机，双机系统继续工作。 RoseHA实现容错功能的关键在于，对客户端来说主机是透明的，当系统发生错误而进行切换时，即主机的切换在客户端看来没有变化，所有基于主机的应用都仍然正常运行。RoseHA采用了虚拟IP地址映射技术来实现此功能。客户端通过虚拟地址和工作主机通讯，无论系统是否发生切换，虚拟地址始终指向工作主机。在进行网络服务时，RoseHA提供一个逻辑的虚拟地址，任何一个客户端需要请求服务时只需要使用这个虚拟地址。正常运行时，虚拟地址及网络服务由主服务器提供。当主服务器出现故障时，RoseHA会将虚拟地址转移到另外一台服务器的网卡上，继续提供网络服务。切换完成后，在客户端看来系统并没有出现故障，网络服务仍然可以使用。除IP地址外，HA还可以提供虚拟的计算机别名供客户端
H3C 运营商WLAN解决方案 公司简介 杭州华三通信技术有限公司（以下简称H3C）成立于2003年11月，运营总部设在杭州。2006年，H3C销售收入7.12亿美元，连续三年保持70%左右的同比增长。在全国34省市设有分支机构。目前公司有员工近5000人，其中研发人员占51％。 H3C专注于基于IP技术的网络设备与应用的研究、开发、生产、销售及服务。H3C不但拥有全线路由器和以太网交换机产品，还在网络安全、IP存储、IP监控、语音视讯、WLAN、SOHO及软件管理系统等领域稳健成长。目前，安全产品中国市场份额位居前三，IP存储亚太市场份额第一，IP监控技术全球领先，WLAN产品在国内运营商累计出货量第一，H3C已经从单一网络设备供应商转变为多产品IToIP 解决方案供应商。 H3C每年将销售额的15％以上用于研发投入，在中国的北京、杭州、深圳以及印度的班加罗尔设有研发机构，在北京和杭州设有产品鉴定测试中心。目前，H3C已申请专利超过700件，其中80％是发明专利。根植中国，H3C广泛服务于党政、公检法、财税、教育、金融、电力、能源、交通、水利、运营商、制造业、公共事业、中小企业等用户。服务全球，H3C通过与3Com、华为、西门子、NEC等公司合作拓展国际市场，目前，H3C的产品和解决方案已经覆盖全球90多个国家和地区。 宽带化、移动化、IP化已经成为下一代公众运营网络的代名词，作为一种灵活的宽带无线IP接入方式，WLAN借助于接入速率高、架构使用便捷、系统费用低廉及可扩展性较好等优点，应用日趋广泛，成为近些年来全球通信领域的亮点之一。据IDC等机构的调查数据显示，2006年全球WLAN市场以极快的速度增长，市场价值达50亿美元。2006年前三季度中国WLAN设备出货量达到6242万美元，未来几年中国WLAN市场仍将保持40%左右的增长速度 基于对运营网络的理解和积累，在中国电信、中国网通、中国移动、中国联通等电信运营网络广 页脚内容1
高可用MS SQL Server数据库解决方案 建设目标 减少硬件或软件故障造成的影响，保持业务连续性，从而将用户可以察觉到的停机时间减至最小，确保数据库服务7*24小时（RTO为99.9%）运转，建设一套完整的高可用性MS SQL Server数据库系统。 需求分析 服务器宕机造成的影响 服务器宕机时间使得丢失客户收益并降低员工生产效率，为了避免对业务造成影响，从两个方面采取预防措施： 一、计划宕机时的可用性： ●补丁或补丁包安装 ●软硬件升级 ●更改系统配置 ●数据库维护 ●应用程序升级 二、防止非计划性宕机： ●人为错误导致的失败 ●站点灾难 ●硬件故障
●数据损毁 ●软件故障 现有状况 ●服务器存在单点故障； ●数据库未做高可用性配置； ●数据库版本为MS SQL Server2008； ●服务器配置为CPU E7540 2.0，24G存； ●数据库容量约800G 技术解决方案 解决思路 考虑到本项目的需求和最佳性能，为了达到最佳可用性，方案采用两台数据库服务器做故障转移集群，连接同一台存储做数据库的共享存储，实现故障自动转移。同时，将旧服务器作为镜像数据库，采用SQL Server 2012的alwayson 功能来再次完成自动故障转移，并可以分担查询的负载。
架构拓扑 新数据库：承担数据库主体计算功能，用于生产数据，采用双机集群，实现自动故障转移。 旧数据库：通过镜像功能，存储数据库副本，用于发生故障时的转移。也可配置为只读，承担备份的负载。 存储：存储采用双控制器，双FC连接两台服务器，避免单点故障。 主/辅域控制器：采用双机模式，SQL Server 2012 实现高可用的必备基础设施。 高可靠性技术方案 SQL Server的企业版支持所有的高可用性功能，这些功能包括：
小贝——无线网络解决方案 技术建议书 长春市方晟电子有限公司
第1章H3C无线系统解决方案 1.1 网络详细设计 根据******市场网络现状及实际网络的建设需求，方案设计在充分考虑全覆盖的前提下先按照###台无线AP部署规模来设计，并在网络机房部署无线控制器, 对无线AP进行管理控制，并且在网络机房部署8口和24口POE交换机给无线AP进行供电，最终全部接入******的核心网络系统。在******原有的网络架构上，同时部署更新的、带机量更大的、转发速率足够强大的智慧路由器和核心交换机。 本次无线网络建设使用小贝系列瘦AP解决方案，小贝系列瘦AP可以支持集中管理，可以实现用户不间断漫游，用户负载分担，射频自动调整，AP上不保存任何配置，便于集中管理和统一维护。 控制器使用小贝同系列WAC361，最大可以管理32个AP，本次方案配置管理30个AP,在满足本次应用需求的基础上可以支持后期扩容的需求。 使用小贝系列无线控制器+FIT AP时，AP在启动后会自动通过DHCP方式获取IP地址，并自动搜寻可关联的无线控制器，在和无线控制器建立CAPWAP隧道之后会自动从无线控制器下载配置文件和更新软件版本。 FIT AP组网最大的优点在于AP本身零配置，AP上电后会自动从无线控制器下载软件版本和配置文件，同时无线控制器会自动调节AP的工作信道以及发射功率。另外，通过无线控制器的RF扫描探测热点地区Rouge AP，可以及时排除其他AP存在的干扰，保障AP的稳定运行。在网络管理方面，网管可以只通过管理无线控制器设备就可以达到控制AP的效果，极大的减少了无线网络后期维护和管理的工作量。 对于本次方案使用的新款小贝系列无线AP新增第一代动态功率调整技术。自动增大功率，弥补损坏AP的信号盲区。第二代动态功率调整技术，逐包功控技术。AP根据终端的距离，自动调整发射功率。信道的自动调整，2.4GHz公用频段干扰设备多，如蓝牙、微波炉等，都会对WLAN产生干扰，小贝系列AP根据周围干扰情况，自动调整各AP的信道，躲避干扰。 小贝系列无线AP可以实现动态功率调整，干扰频段自动避让，在减少信号干扰的情况下做到无死角覆盖。对于莫名的无线入侵具有防御检测功能，能够有效的防护钓鱼AP、非法AP的攻击。可对接入名单进行审查，防止非法用户计入网络。具有Green AP模式，节能环保，能够有效为客户节省成本。
双机热备份方式 在双机热备份方式中，主服务器运行应用，备份服务器处于空闲状态，但实时监测主服务器的运行状态。一但主服务器出现异常或故障，备份服务器立刻接管主服务器的应用。也就是目前通常所说的active/standby 方式，主要通过纯软件方式实现双机容错。 LAN HeartBeat Active Standby AppA DiskArray 当前应用最广泛的双机热备份软件主要有LifeKeeper,Rose HA, DataWare和MSCS。 Rose工作模式: 1)双主机通过一条TCP/IP网络线以及一条RS-232电缆线相联 2)双主机各自通过一条SCSI电缆线与RAID相联 3)主机NT1为active，主机NT2为standby 4)主机NT1处理作业和数据，主机NT2作为热备份机 5)主机NT1故障后，主机NT2自动接管主机NT1的作业和数据 6)主机NT2同时接管NT1的主机名(Host)及网络地址(IP) 7)主机NT1的作业将在主机NT2上自动运行 8)主机NT1的客户(client)可继续运行，无需重新登录 9)主机NT1修复后，自动接管原来的作业和数据，主机NT2继续作备份机 双机互备份方式 在这种方式中，没有主服务器和备份服务器之分，两台主机互为备份。主机各自运行不同应用，同时还相互监测对方状况。当任一台主机宕机时，另一台主机立即接管它的应用，以保证业务的不间断运行。也就是目前通常所说的Active/Active方式，主要通过纯软件方式实现双机容错。通常情况下,支持双机热备的软件都可以支持双机互备份方式,当前应用最广泛的双机互备软件主要有LifeKeeper,Rose HA, DataWare和MSCS。 以Rose 为例：
H3C港口无线覆盖解决方案 作为世界上增长最快的经济体之一，2012年中国港口吞吐量持续增长，吞吐量上亿吨的港口已增加到20多个。港口行业面临着重要的机遇与挑战，利用信息化手段，统筹利用港口枢纽资源等成为行业内的共识。H3C长期致力于推动中国港口信息化建设的发展，在此方面有深厚积累经验，其融合最新IP前沿技术的H3C云时代网络技术、资源化港口IP网络和港口监控解决方案等，H3C港口无线覆盖解决方案作为港口信息化的重要组成部分已越来越受到业界的重视。 下面针对港口环境做个简单的介绍，通常港口环境主要包括三个区域：港口网络控制中心、码头卸货区（即桥吊区域）、集装箱堆积区。我们港口无线覆盖解决方案也主要针对上述三个区域进行无线覆盖，完成各区域与中心控制系统之间实现数据业务传输。 港口环境无线覆盖主要有以下两个场景（如图1）： 图1 港口无线覆盖解决方案 页脚内容1
页脚内容2 场景一：网络控制中心远距离桥接、桥吊区域无线覆盖 在港口网络控制中心楼顶安装无线AP 和天线与桥吊上AP 和天线对接，确保AP 之间通过5.8G 频段建立MESH 链路，桥吊上AP 通过2.4G 频段对桥吊区域进行无线覆盖，最终保证AP 之间数据通信的带宽需求及满足桥吊区域无线覆盖。 图2 桥吊区域 图3 网络控制中心 场景二：集装箱堆积区无线全覆盖 集装箱区域通常分为散装箱区域和空箱区域，集卡小货车（地面作业）及龙门吊（高空作业）为无线接入终端在此区域移动。集装箱区域均匀分布着高30m 的灯塔，分为纵横几排至十几排不等（视其港口规模而定），灯塔上放置网桥设备对整个集装箱区域进行无线覆盖。至于是否使用MESH 桥接要视现场是否铺设从网络控制中心到灯塔的有线线路。如果网络控制中心到灯塔有光纤铺设，集装箱区域灯塔上的网桥无需考虑MESH 桥接，只需考虑2.4G 频段向下覆盖，反之，则需要在网络控制中心与灯塔之间通过5.8G 频段建立MESH 桥接。