服务器的高可用性之HA
今天小编要和读者聊聊有关服务器的高可用性的问题，当前读者应该知道，国内一些从事电子商务行业的服务器性能是相当的强大的（淘宝、阿里巴巴等等），这些电子商务的主站每秒钟的访问量可是相当的可观，读者试着想想如果服务器当掉了咋办，回答可能是肯定还有其他服务器替代啦，对，可是如何迅速替代让用户感觉不到已经有服务器当掉了呢，那便引出小编今天要谈的HA。
HA是啥？High-Availability Linux 的开源项目的目标是，通过社区开发努力提供一个提升Linux 可靠性（reliability）、可用性（availability）和可服务性（serviceability）（RAS）的群集解决方案。Linux-HA 项目得到了广泛的应用，是很多有趣的高可用性解决方案的重要组成部分。
高可用性集群一般是指当集群中有某个节点失效的情况下，其上的任务会自动转移到其他正常的节点上。还指可以将集群中的某节点进行离线维护再上线，该过程并不影响整个集群的运行。
今天小编的主要任务就是来实现HA群集。
Project 1：了解高可用性群集的架构
如图1-1所示，高可用性群集的几个重要部分
图1-1
1）共享信息层
在基础架构上实现心跳信息探测。双方节点可以随时探测到对方的心跳信息，以实现对对方主机工作状态的探测。三类控制信息：心跳（Heartbeats），集群事务信息（Cluster Transition Messages），重传信息（Retransmission Request）。配置文件：/etc/ha.d/ha.cf。各节点间域共享密钥，实现节点间互相通信的认证。加密方式：MD5、HMAC-SHA1 。常用实现软件：HeartBeat（小
编这里就是使用的这个）、keepalived、ultramonkey、openais/corosync。红帽官方提供的集群套件RHCS底层使用的通信机制就是openais/corosync。
2）资源分配子层
在资源分配上定义资源种类，界定资源归属，每个服务需要哪些资源及这些资源之间的前后次序。
集群资源管理器（CRM，常用软件pacemaker），管理双方向外提供服务所需用到的资源，包括IP地址、Web服务、共享存储等等。而这些资源需要依靠集群信息库CIB（XML文件）来定义，同时还必须保证一旦某个节点上的XML
文件更新，即刻通知其他节点上的XML也要及时更新。
策略引擎（PE Policy Engine）：定义法定人数以及根据法定人数所做出的动作等等。
本地资源管理器（LRM Local Resource Manager）：监控本地某个资源的工作状况。
3）资源层
本地资源代理（Resource Agent），脚本文件，一旦集群资源管理器发现某个资源工作异常，立即通知本地资源代理重启服务。常用方法：（1）Heartbeat v1（小编这里使用的）；
（2）使用脚本LSB scripts （Linux Standards Base ）；
（3）OCF Open Cluster Format 开放集
Project 2：常用的架构模型
1）主从架构：正常情况下只有主服务器工作，当主服务器当掉从服务器立即启用
2）互为主从架构：两台服务器提供不同的服务，相互为主从架构，两台服务器同时工作
3）多主机架构
N台主机组成一个集群，分别提供不同的服务，一台服务器空闲做备节点。或者全部处于工作状态，一台服务器出故障，立刻将服务转移到其他主机上。各节点之间需要以多播的形式将自己的健康情况发送给其他主机。
Project 3：高可用性集群的实现
1）主从架构
step 1:实验拓扑规划，如图3-1-1所示
图3-1-1
Primary eth0 192.168.1.100
eth1 192.168.2.10 //心跳测试
Standby eth0 192.168.1.200
eth1 192.168.2.20 //心跳测试
向外提供Web服务IP：192.168.1.150
step 2：系统与软件资源需求安装
小编的系统是Red Hat EnterPrise Linux 5.4
小编的系统上已经安装了apache2.2.3和php环境，如果读者不会安装的话可以参见小编的博客https://www.360docs.net/doc/698770664.html,/5200614/1177203 小编将这些软件包放在/root/heart目录下了，然后使用不加gpg验证的本地yum安装完成
heartbeat-2.1.4-11.el5.i386.rpm
openhpi-libs-2.14.0-5.el5.i386.rpm
heartbeat-pils-2.1.4-11.el5.i386.rpm perl-MailTools-2.04-1.el5.rf.noarch.rpm
heartbeat-stonith-2.1.4-11.el5.i386.rpm perl-TimeDate-1.16-5.el5.noarch.rpm
libnet-1.1.5-1.el5.i386.rpm
primary服务器的安装配置
# cd heart/
# yum localinstall ./* --nogpgcheck
这样安装省了很多事，系统会自动解决依赖关系，但是读者还要记着安装完成之后查询一下heartbeat到底产生了哪些文件
# rpm -ql heartbeat
其中/usr/share/doc/heartbeat-2.1.4/目录下就存放了heartbeat的样例配置文件
接下来的工作是修改主机名，Heartbeat依靠服务器的主机名来识别服务器，因此使用hostname命令得到的结果必须与uname -n 结果保持一致。
# vim /etc/sysconfig/network //修改主机名称；
HOSTNAME=https://www.360docs.net/doc/698770664.html,
# hostname https://www.360docs.net/doc/698770664.html,
# vim /etc/hosts //修改主机地址映射；
192.168.1.100 https://www.360docs.net/doc/698770664.html, primary
192.168.1.200 https://www.360docs.net/doc/698770664.html, standby
# cd /etc/ha.d/
# cp /usr/share/doc/heartbeat-2.1.4/ha.cf ./
# cp /usr/share/doc/heartbeat-2.1.4/authkeys ./
# cp /usr/share/doc/heartbeat-2.1.4/haresources ./
# vim ha.cf //定义各节点之间Heartbeat进程如何通信；
debugfile /var/log/ha-debug //设置调试日志文件名
logfile /var/log/ha-log //设置其他日志文件名
keepalive 2 //设定heartbeat之间的时间间隔为2秒；
deadtime 30 //在30秒后宣布节点死亡；
warntime 10 //在日志中发出late heartbeat警告之前等待的时间，单位为秒；
udpport 694 // 使用端口694进行bcast和ucast通信，默认参数；
bcast eth1 //在eth1接口上使用广播heartbeat-”心跳”；
node https://www.360docs.net/doc/698770664.html, //定义节点；
node https://www.360docs.net/doc/698770664.html, //定义节点；
# dd if=/dev/urandom bs=512 count=1 | openssl md5 //生成节点间域共享密钥；
14df2a6b5b26b510e7d5d5b16b7cc10b
# vim authkeys //定义心跳探测包使用哪种加密方式；
auth 1
1 sha1 14df2a6b5b26b510e7d5d5b16b7cc10b
# chmod 600 authkeys //仅允许管理员修改文件；
# cp /etc/init.d/httpd /etc/ha.d/resource.d/
# vim haresources //定义资源；文件给出了相应的格式
https://www.360docs.net/doc/698770664.html, 192.168.1.100/24/eth0/192.168.1.255 httpd
standby 服务器的配置
从服务器的主机名称为https://www.360docs.net/doc/698770664.html,，安装heartbeat的方法同主服务器一致。/etc/hosts文件、Heartbeat的配置文件也必须与主机保持一致。因此这里采用将primary上的配置文件直接远程复制过来的方法：
# cd /etc/ha.d/
# scp 192.168.1.100:/etc/ha.d/ha.cf ./
# scp 192.168.1.100:/etc/ha.d/authkeys ./
# scp 192.168.1.100:/etc/ha.d/haresources ./
# cp /etc/init.d/httpd /etc/ha.d/resource.d/
# chmod 600 authkeys
step 3:集中测试
分别重新启动primary和standy服务器的heartbeat服务，如图3-1-2、3-1-3所示
图
3-1-
2
图
3-1-
3
这样
就启
动成功了，接下来编写测试网页，小编这里为了让读者看的清楚两台服务器的工作，所以两个测试网页的内容是不同的，而在实际的应用中两台服务器上的内容肯定是一致的啦。
primary服务器的/var/www/html/index.php内容
for($i=0;$i<9;$i++)
echo $i."web1"."
";
?>
standby服务器的/var/www/html/index.php内容
for($i=0;$i<9;$i++)
echo $i."web2"."
";
?>
在客户PC的浏览器上输入http://192.168.1.150试试看，结果如图3-1-4所示
图
3-1-
4
以上
结果
是在
prim
ary
服务
器为
主服
务器
的情况才会出现的，那么现在小编就来模拟以下主服务器成为备份服务器的情况再来看看，这里heartbeat提供了一个工具来切换服务器状态，在
/usr/lib/heartbeat/目录下，这里小编在切换服务器状态的同时，来监控一下两台服务器的日志，让读者清楚两台服务器之间是如何切换主从关系的在primary服务器上执行
# cd /usr/lib/heartbeat/
# ./hb_standby //请求成为辅助服务器
主服务器的日志情况如图3-1-5所示：
图
3-1-
5
从服
务器
的日
志情
况如
图
3-1-
6所
示：
图
3-1-
6
小编现在来说明一下切换流程
1.primary服务器发出申请说自己想成为standby服务器，并且说明standby服务器可以拿走资源
2.”心跳“（广播）被standby服务器抓到，知道primary要变为standby服务器
3.primary开始释放资源，可以看到主服务器关闭了httpd服务器，当掉了192.168.1.150
4.standby开始申请资源，可以看到standby服务器开始启动httpd服务器，并且启用对外IP192.168.1.150
5.双方工作都完成显示success
此时在刷新一下PC机的浏览器看看，结果如图3-1-7所示
图
3-1-
7
看到
了
吧，
成功
转到
stan
dby
服务
器了
刚刚不是standby服务器成为了主服务器么，那么下面小编就来模拟一下主
服务器当掉的情况，这里小编将监控“心跳”的eth1端口当掉
# ifconfig eth1 down
可以在primary服务器的日志上看到如图3-1-8所示的信息
图
3-1-
8
此时
再次
刷新
一下
PC
的浏
览器
看
看，
结果
如图
3-1-
9所
示
图
3-1-
9
primary服务器成功切换成为主服务器啦
到这里主从架构的配置以及测试小编就完全演示完了，接下来的工作交个读者你去动手操作啦，接下来的工作是完成互为主从架构的案例啦
2）互为主从架构
step 1:实验拓扑规划，如图3-2-1所示：
图3-2-1
这里小编仍然使用主从架构的环境，稍作修改即可
step 2：
primary服务器的资源配置修改
# vim /etc/ha.d/haresources
https://www.360docs.net/doc/698770664.html, 192.168.1.150/24/eth0/192.168.1.255 httpd
https://www.360docs.net/doc/698770664.html, 192.168.1.151/24/eth0/192.168.1.255 vsftpd //添加ftp # touch /var/ftp/primary //作为区分用
standby服务器的资源配置修改
# vim /etc/ha.d/haresources
https://www.360docs.net/doc/698770664.html, 192.168.1.150/24/eth0/192.168.1.255 httpd
https://www.360docs.net/doc/698770664.html, 192.168.1.151/24/eth0/192.168.1.255 vsftpd
# touch /var/ftp/standby
step 3：重新启动两台服务器的heartbeat服务
# service heartbeat restart
step 4：集中测试
仍然在PC机的浏览器输入http://192.168.1.150，结果如图3-2-2所示
图3-
2-2
PC浏
览器
输入
ftp://1
92.16
8.1.15
1试
试，
结果
如图
3-2-3所示：
图
3-2-
3
看见
了
吧，
两台
服务
器相
互备
份，
都运
行有
应用
服
务，读者可以自己测试一下将其中一台服务器当掉，看看结果，小编这里就不掩饰了，有啥问题请联系小编哈，至于第三种模式，由于小编的主机有限就没做了，如果读者能把上面两种模式理解透彻，第三种很容易实现啦。
编后语：HA集群一般都是以两个节点的形式出现的，单机处理能力有限，所以当服务器压力较大时，想扩容服务器的处理能力往往得把以前的服务器淘汰掉，浪费了以前的投资；因此对于高访问性需求的商业性网站单纯想使用HA群集来解决问题是不可行的，如果再结合LVS来使用，那便是极好的了，至于LVS 的实现小编会在后续的博客中道来，敬请关注哈。。。。。
LVS keepalived负载均衡高可用 配置安装大全
LVS+Keepalived实现高可用集群 一、基础介绍 (2) 二、搭建配置LVS-NA T模式 (2) 三、搭建配置LVS-DR模式 (4) 四、另外一种脚本方式实现上面LVS-DR模式 (6) 五、keepalived + LVS(DR模式) 高可用 (8) 六、Keepalived 配置文件详细介绍 (11)
一、基础介绍 (一)根据业务目标分成三类： High Availability 高可用 Load Balancing 负载均衡 High Performance 高性能 (二)实现集群产品： HA类： rhcs、heartbeat、keepalived LB类： haproxy、lvs、nginx、f5、piranha HPC类： https://www.360docs.net/doc/698770664.html,/index/downfile/infor_id/42 (三)LVS 负载均衡有三种模式： LVS-DR模式（direct router）直接路由模式 进必须经过分发器，出就直接出 LVS-NAT模式（network address translation） 进出必须都经过分发器 LVS-TUN模式（ip tunneling）IP隧道模式 服务器可以放到全国各地 二、搭建配置LVS-NAT模式 1 、服务器IP规划： DR服务器添加一张网卡eth1，一个网卡做DIP，一个网口做VIP。 设置DIP、VIP IP地址: DIP的eth1和所有RIP相连同一个网段 CIP和DIP的eth0(Vip)相连同一个网段 Vip eth0 192.168.50.200 Dip eth1 192.168.58.4 客户机IP： Cip 192.168.50.3
如何构建高可用性HIS系统方案
构建高可用性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支持这种配置方式，由三个服务器共同作为一个虚拟服务器运行，第四个服务器作为备份服务器，当虚拟服务器中任何一个服务器出现故障，备份服务器接管其原有的应用和资源。这种集群环境提供更强大的处理能力，适用于更高的企业用户需求，能够满足更多的客户访问。
Linux下的高可用性方案研究
Linux下的高可用性方案研究 保证持续稳定的系统运行时间变得越来越重要，而传统意义上的小型机系统让普通用户望而却步。用户需要的是更高的可用性以及更低的成本。高可用性(HA)技术能自动检测服务器节点和服务进程错误、失效，并且当发生这种情况时能够自动适当地重新配置系统，使得集群中的其他节点能够自动承担这些服务，以实现服务不中断。 Cluster应用可分为三方面：High-Availability(HA)(高可用性集群)、Load Balance(负载均衡集群)、Scientific(科学集群)。在集群的这三种基本类型之间，经常会发生混合与交杂。于是，可以发现高可用性集群也可以在其节点之间均衡用户负载，同时仍试图维持高可用性程度。同样，可以从要编入应用程序的集群中找到一个并行群集，它可以在节点之间执行负载均衡。而本文则侧重于介绍基于Linux的HA解决方案方面的问题。 基于LVS的HA方案 Linux要进入高端市场就必须在这方面有相应的措施，所以许多公司都在这方面加大了研究力度。现在，我们可以使用一些现存的软件去构筑具有高可用性的LVS系统。下面列出两种方案，以供参考。 ［方案一］mon+heartbeat+ fake+coda 我们可以使用“mon”、“heart beat”、“fake”和“coda”四个软件来构筑具有高可用性的Virtual Server(虚拟服务器)。“mon”是一个大众化的资源管理系统，用来监控网络上的服务器节点和网络服务。“heartbeat”实现在两台计算机间通过在串行线上使用UDP协议传送“心跳信息”。“Fake”是一个使用ARP欺骗的方法来实现IP接管。 当服务器故障时，处理过程如下：“mon”进程运行在负载均衡器上，负责监测整个集群的服务器节点和服务进程。在配置文件“fping.monitor”中写入要检测服务器节点，然后“mon”进程将会隔t秒检查一下相应的服务器节点是否还活着。 另外相关的服务监视器也要做相应的配置，这样“mon”进程将每m秒检测一下所有节点的相应服务进程。例如：http.monitor：用于配置监控http服务；ftp.monitor：用于配置监控FTP服务；以此类推。当配置完成后，某个服务器节点失效或重新生效、服务进程失效或重新生效时都会发送一个通告信息，因此，负载均衡器能够知道服务器节点是否能接受服务。 现在，负载均衡器成为了整个系统的单点失效。为了防止这一现象，我们必须安装一个负载均衡器的备份服务器。“fake”软件实现当负载均衡器失效时，备份服务器自动接管IP地址，并继续服务。而“heartbeat”则随时根据负载均衡器的状态自动激活/关闭备份服务器上的“fake”进程。在负载均衡器和备份服务器上都运行着一个“heartbeat”进程，它们通过串行线周期性地发送“I'm alive ”消息。如果备份服务器在一个预定时间内接收不到来自负载均衡器的“I'm alive”信息时，将自动激活“fake”进程接管负载均衡器的IP地址，并开始提供负载均衡服务；而当再次收到来自负载均衡器的“I'm alive ”消息时，备份服务器将自动将“fake”进程关闭，释放出它接管的服务器，负载均衡器重新开始工作。
高可用性集群解决方案设计HA
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将实时监测该故障，并自动将系统切换至备用主机，以保障系统的连续运营。
通过LVS+Keepalived搭建高可用的负载均衡集群系统
1、安装LVS软件 （1）安装前准备 操作系统：统一采用Centos5.3版本，地址规划如下： 更详细的信息如下图所示： 图中的VIP指的是虚拟IP地址，还可以叫做LVS集群的服务IP，在DR、TUN模式中，数据包是直接返回给用户的，所以，在Director Server上以及集群的每个节点上都需要设置这个地址。此IP在Real Server上一般绑定在回环地址上，例如lo:0，同样，在Director Server 上，虚拟IP绑定在真实的网络接口设备上，例如eth0:0。 各个Real Server可以是在同一个网段内，也可以是相互独立的网段，还可以是分布在internet上的多个服务器.
（2）安装操作系统需要注意的事项 Centos5.3版本的Linux，内核默认支持LVS功能，为了方便编译安装IPVS管理软件，在安装操作系统时，建议选择如下这些安装包：l 桌面环境：xwindows system、GNOME desktop environment。 l 开发工具：development tools、x software development、gnome software、development、kde software development。 系统安装完毕，可以通过如下命令检查kernel是否已经支持LVS的ipvs模块： [root@localhost ~]#modprobe -l |grep ipvs /lib/modules/2.6.18-194.11.1.el5/kernel/net/ipv4/ipvs/ip_vs.ko /lib/modules/2.6.18-194.11.1.el5/kernel/net/ipv4/ipvs/ip_vs_dh.ko 如果有类似上面的输出，表明系统内核已经默认支持了IPVS模块。接着就可以安装IPVS管理软件了。
高可用系统部署方案
高可用性系统部署方案 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和内存上的较大消耗，如果再加上数据库的占用资源，很容易出现系统负载过重，故在方案中将应用系统与数据库分布在不同服务器，便于管理及提高整体性能。
linux lvs 配置
Linux负载均衡 一、LVS概述及原理 LVS是一个开源的软件，由毕业于国防科技大学的章文嵩博士于1998年5月创立，可以实现LINUX平台下的简单负载均衡。LVS是Linux Virtual Server的缩写，意思是Linux虚拟服务器。 LVS集群采用IP负载均衡技术和基于内容请求分发技术。调度器具有很好的吞吐率，将请求均衡地转移到不同的服务器上执行，且调度器自动屏蔽掉服务器的故障，从而将一组服务器构成一个高性能的、高可用的虚拟服务器。整个服务器集群的结构对客户是透明的，而且无需修改客户端和服务器端的程序。为此，在设计时需要考虑系统的透明性、可伸缩性、高可用性和易管理性。一般来说，LVS集群采用三层结构，其主要组成部分为： 1) 负载调度器（load balancer），它是整个集群对外面的前端机，负责将客户的请求发送到一组服务器上执行，而客户认为服务是来自一个IP地址（我们可称之为虚拟IP地址）上的。 2) 服务器池（server pool），是一组真正执行客户请求的服务器，执行的服务有WEB、MAIL、FTP和DNS等。 3) 共享存储（shared storage），它为服务器池提供一个共享的存储区，这样很容易使得服务器池拥有相同的内容，提供相同的服务。 调度器是服务器集群系统的唯一入口点（Single Entry Point），它可以采用IP 负载均衡技术、基于内容请求分发技术或者两者相结合。在IP负载均衡技术中，需要服务器池拥有相同的内容提供相同的服务。当客户请求到达时，调度器只根据服务器负载情况和设定的调度算法从服务器池中选出一个服务器，将该请求转发到选出的服务器，并记录这个调度；当这个请求的其他报文到达，也会被转发到前面选出的服务器。在基于内容请求分发技术中，服务器可以提供不同的服务，当客户请求到达时，调度器可根据请求的内容选择服务器执行请求。因为所有的操作都是在Linux操作系统核心空间中将完成的，它的调度开销很小，所以它具有很高的吞吐率。服务器池的结点数目是可变的。当整个系统收到的负载超过目前所有结点的处理能力时，可以在服务器池中增加服务器来满足不断增长的请求负载。对大多数网络服务来说，请求间不存在很强的相关性，请求可以在不同的结点上并行执行，所以整个系统的性能基本上可以随着服务器池的结点数目增加而线性增长。共享存储通常是数据库、网络文件系统或者分布式文件系统。服务器结点需要动态更新的数据一般存储在数据库系统中，同时数据库会保证并发访问时数据的一致性。静态的数据可以存储在网络文件系统（如NFS/CIFS）中，但网络文件系统的伸缩能力有限，一般来说，NFS/CIFS服务器只能支持3~6个繁忙的服务器结点。对于规模较大的集群系统，可以考虑用分布式文件系统，如AFS、GFS、Coda和Intermezzo等。分布式文件系统可为各服务器提供共享的存储区，它们访问分布式文件系统就像访问本地文件系统一样，同时分布式文件系统可提供良好的伸缩性和可用性。此外，当不同服务器上的应用程序同时读写访问分布式文件系统上同一资源时，应用程序的访问冲突需要消解才能使得资源处于一致状态。这需要一个分布式锁管理器（Distributed Lock Manager），它可能是分布式文件系统内部提供的，也可能是外部的。开发者在写应用程序时，可以使用分
核心系统高可用性设计
关于系统稳定性策略的探讨 1.前言 系统作为业务系统的核心，其运行稳定性和高可用性至关重要。因此，需要通过高可用性设计来尽量减少系统的计划内和计划外停机，并在系统出现故障时及时响应、快速恢复，以保障关键数据和业务系统的运行稳定性和可持续访问性。其中： 1.计划内停机是指管理员有组织、有计划安排的停机，比如升级硬件微码、升 级软件版本、调整数据库库表、更换硬件设备、测试系统新功能等时，可能需要的停止系统运行。 2.计划外停机是指非人为安排的、意外的停机，比如当硬件出现重大故障、应 用程序停止运行、机房环境遭到灾难性的破坏时所引起的业务系统停止运行。 目前，对于计划内和计划外停机，可通过消除系统中的单点失效来尽量减少停机时间。同时，通过采用可在线维护（固件升级、在线扩充、故障部件更换）的设备，并通过负载均衡机制实现应用系统的在线升级、维护，将有效消除计划内停机对业务系统的影响。此外，由于系统中采用了全面的负载均衡设计，并针对系统失效提供了可靠的数据备份恢复和多点容灾保护，因而能够有效减少系统计划外停机的恢复时间。 在造成系统宕机的原因方面，有统计中表明并非都是硬件问题。其中，硬件问题只占40％，软件问题占30％，人为因素占20％，环境因素占10％。因此，高可用性设计应尽可能地考虑到上述所有因素。对于系统而言，其整体的可用性将取决于内部的应用系统、主机、数据库等多种因素；同时，训练有素的系统维护人员和良好的服务保障也是确保系统稳定运行和故障快速恢复的关键。 2.应用系统 系统在应用软件架构设计中应从渠道层、渠道管理层、业务处理层等不同
层面通过多种措施和策略的综合设计来提高应用系统的高可用性和稳定性。 在渠道管理层和业务处理层的设计中，要考虑设置应用负载均衡、应用软件失效备援、vip服务通道、流量控制、故障隔离等机制。 1.应用负载均衡 应用软件负载均衡通过多个层次上不同的负载均衡策略一起实现整体的负载均衡，应用负载均衡的设计思路是将大量的并发访问或数据流量分担到多台节点设备上分别处理和将单个重负载的运算分担到多台节点设备上做并行处理来达到负载均衡的效果，从而提高服务响应速度，提高服务器及其他资源的利用效率，避免服务请求集中于单一节点导致拥塞。 2.应用软件失效备援 应用软件构建在面向服务的架构、设计思想上，应用服务具有较高的可灵活部署性。通过这种灵活性，结合系统基础设施的规划、部署可以实现应用软件的失效备援。系统可以考虑实现基于应用服务和基于应用服务管理框架的多种应用软件失效备援机制。 基于应用服务的失效备援是在应用服务管理框架中可以实现应用服务的冗余部署，利用硬件负载均衡设备或应用软件负载均衡可以在需要时将服务请求切换到相应的冗余服务。 基于应用服务管理框架的失效备是将应用服务框架在系统中冗余部署，利用硬件负载均衡设备或应用软件负载均衡可以在需要时将服务请求切换到相应的冗余的应用服务管理框架。 3.vip服务通道 在系统中，从系统运行稳定性、持续性及处理性能的角度，配合物理设备、系统支撑软件（数据库系统、操作系统）的相关措施，应用软件可通过构建VIP服务通道的方式降低应用服务运行期间的相互影响。服务通道可以基于不同业务产品或不同应用服务管理框架的不同粒度来设置，从而满足部分应用处理资源只响应特定的服务请求或不同的服务监听响应不同的通道传递过来的服务申请的功能。 4.流量控制 在系统中，从系统运行稳定性、持续性角度，配合物理设备、系统支撑软
高可用Lvs集群搭建和测试报告
高可用Lvs集群搭建和测试报告 Lvs（Linux Virtual Server）是Linux下的负载均衡器，支持LVS-NA T、 LVS-DR、LVS-TUNL三种不同的方式，NA T用的不是很多，主要用的是DR、TUNL方式。DR方式适合所有的RealServer在同一网段下，即接在同一个交换机上。TUNL方式不限制RealServer 的位置，完全可以跨地域、空间，只要系统支持Tunnel就可以。 运行Lvs的前端调度器，目前只能为Linux，针对FreeBSD刚刚出来，性能不是很好。可以针对Web、MySQL、Ftp等服务做load balances。后端的RealServer则可以为各类系统，Linux、Solaris、Aix、BSD、Windows都可。 下面主要针对DR方式下的Web、MySQL负载均衡，以及Lvs + HA做功能性的验证和性能方面的测试。 1.集群系统拓扑
2.环境搭建说明 1.前端Load Balancer、Backup为虚拟机Linux系统，后端两台Real Server为纯Linux系 统。 2.192.168.6.229为前端负载均衡调度器，虚拟IP为192.168.6.111，安装并配置了ipvsadm （负载均衡）、ldirectord（健康监控）服务。 3.192.168.6.230为调度器的备份，采用heartbeat实现。 4.192.168.6.240、192.168.6.241为两台提供服务的真实Server。 3.功能性验证 首先在Load Balancer上安装ipvsadm、ldirectord、heartbeat服务，备机上也相同，可以用YUM进行安装，安装完成后需要将ha.cf、haresources、authkeys、ldirectord.cf文件拷贝到/etc/ha.d/ 目录下。 3.1. 验证Apache负载均衡。 3.1.1.配置 1.配置Load Balancer的ipvsadm，脚本内容如下：
技术方案-应用高可用解决方案(两地三中心)
英方软件数据库系统高可用解决方案 英方软件（上海）有限公司
目录 1. 概述 (1) 2. 需求分析 (2) 3.1主机配置 (3) 3.2方案拓扑图： (3) 3.3 I2高可用方案功能介绍 (4) 3.4管理控制台 (7) 5. I2的主要优势 (10) 6. 典型案例 (12) 7.公司简介 (13)
1. 概述 现代大型企业大多拥有为数众多的服务器，提供Internet与Intranet使用者各种不同的服务。如数据库系统、影像系统、录音系统、Email系统等。保持业务的持续性是当今企业用户进行数据存储需要考虑的一个重要方面。系统故障的出现，可能导致生产停顿，客户满意度降低，甚至失去客户，企业的竞争力也大打折扣。因此，保持业务的持续性是用户在选择计算机系统的重要指标。究其根本，保护业务持续性的重要手段就是提高计算机系统的高可靠性同时将数据的损失降至最低限度。 关键数据和数据库的备份操作已经成为日常运行处理的一个组成部分，以确保出现问题时及时恢复重要数据。传统的解决方案,类似于磁带机备份存在较大的缺点. 通常数据采用磁带离线备份，当数据量较大或突发灾难发生时，备份磁带无法真正及时快速恢复数据及业务。 提供有效的数据保护和高可用性服务,又在合理预算范围之内,并且能够基于你现有环境当中,获得实时数据保护,并无距离限制,为确保你重要数据的保护----包含数据库和邮件系统。I2为您提供了完美的解决方案。 I2 采用先进的异步实时数据复制技术(Asychronous Real-Time Data Replication)，立即将所有服务器上对于磁盘系统的变更透过网络传输至备援服务器，而非整个档案或磁盘的镜设(Mirror)，因此对于服务器的效能与网络带宽的影响都能降至最低，并能将成本降至最低，做到真正的实时数据保护. 业务数据是用户最宝贵的资产之一，数据的损失就是企业资产利润的损失，所以保护业务数据是企业计算系统的主要功能之一。实施I2的备份方案可以将用户数据的损失降至最低甚至为零。
LVS+Keepalived部署全解
安装与配置 两台负载均衡器： Lvs1:192.168.1.10 Lvs2:192.168.1.11 漂移地址(虚拟IP，VIP)： Vip：192.168.1.169 Real Server： RS1：192.168.1.102 RS2：192.168.1.103 LVS配置及ipvsadm和keepalived的安装 在lvs master和lvs backup主机上安装。 1．首先安装一些辅助package如下： e2fsprogs-devel-1.41.12-18.el6.x86_64.rpm kernel-devel-2.6.32-642.el6.x86_64.rpm keyutils-libs-devel-1.4-4.el6.x86_64.rpm krb5-devel-1.10.3-10.el6_4.6.x86_64.rpm libcom_err-devel-1.41.12-18.el6.x86_64.rpm libnl-1.1.4-2.el6.x86_64.rpm libnl-devel-1.1.4-2.el6.x86_64.rpm libselinux-devel-2.0.94-5.3.el6_4.1.x86_64.rpm libsepol-devel-2.0.41-4.el6.x86_64.rpm zlib-devel-1.2.3-29.el6.x86_64.rpm openssl-devel-1.0.1e-15.el6.x86_64.rpm pkgconfig-0.23-9.1.el6.x86_64.rpm popt-devel-1.13-7.el6.x86_64.rpm popt-static-1.13-7.el6.i686.rpm 安装时可能出现缺少什么package，去iso中找或者网上下载然后安装就可以了 rpm –ivh XXXXXXXX.rpm 2．然后安装ipvsadm 将ipvsadm-1.26.tar.gz压缩文件复制到/usr/local/src/lvs/文件夹下，然后运行tar zxvf ipvsadm-1.26.tar.gz 命令。创建软连接ln –s /usr/src/kernels/2.6.32-431.el6.x86_64/ /usr/src/linux，然后进去ipvsadm-1.26文件夹cd ipvsadm-1.26，make && make install。 #find / -name ipvsdam 查找的安装位置 检查ipvsadm是否安装成功，可直接输入#ipvsadm IP Virtual Server version 1.2.1 (size=4096) Prot LocalAddress:Port Scheduler Flags -> RemoteAddress:Port Forward Weight ActiveConn InActConn 检查模块是否加入内核#lsmod| grep ip_vs ip_vs 78081 0
SQL server高可用方案
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 常用的高可用性解决方案进行综合对比。
版图绘制时如何进行LVS验证
第四章验证多路复用器版图——Verifying the Multiplexer Layout This chapter introduces you to interactive verification. You will perform two different tests in the Virtuoso? layout editor while using Diva interactive verification. One test uses the Design Rule Checker (DRC) to compare your design against the design rule, and the other test uses Layout Versus Schematic (LVS) software to check your design’s connectivity. You will be 本章向您介绍交互式验证。在使用Diva交互式验证时，您将在Virtuoso?版图编辑器中执行两个不同的测试。一个测试使用设计规则检查器（DRC）将您的设计与设计规则进行比较，另一个测试使用Layout Versus Schematic（LVS）软件来检查您的设计的连通性。你将会 Creating a Test Case for Checking Errors 创建用于检查错误的测试用例 ?Performing a Design Rule Check 执行设计规则检查 ?Extracting Connectivity from the Layout 从版图中提取连接性 ?Comparing the Layout to the Schematic 将版图与原理图进行比较 ?Analyzing LVS Errors 分析LVS错误 ?Correcting the Error 更正错误 ?Rerunning Verification on page 重新验证 When you finish this chapter, you will be able to 完成本章后，您将能够 ?Run a design rule check and view errors 运行设计规则检查并查看错误 ?View and correct DRC errors 查看并更正DRC错误 ?Run extraction on a layout 在版图上运行提取 ?View a schematic 查看原理图 ?Cross-probe between a layout and a schematic 版图和原理图间的交叉探测 ?Rerun verification after correcting an error 纠正错误后重新运行验证 找出是否可以运行交互式验证——Finding Out if You Can Run Interactive Verification You might not have a license to run the interactive verification products. 您可能没有运行交互式验证产品的许可。 ?Click the Verify menu to find out whether you can use interactive verification. ?单击“验证”菜单以确定是否可以使用交互式验证。 If the commands under Verify appear shaded, you do not have a license to run interactive verification. You can either read this chapter to get an idea about how interactive verification works, or you can go on to the next chapter. 如果“验证”下的命令显示为阴影，则表示您没有运行交互式验证的许可证。您可以阅读本章以了解交互式验证的工作原理，也可以继续阅读下一章。 如果您还没有完成以前的章节——If You Have Not Completed the Previous Chapters This chapter assumes you have followed the steps in the previous chapters. If you have, you can skip this section and go to the “Creating a Test Case for Checking Errors” on page 107. If you did not follow the steps in the previous chapters, you must copy a completed design from the master library so you can go through this chapter. The following steps show you how to copy the completed design from the master library. 本章假设您已按照前面章节中的步骤进行操作。如果有，可以跳过本节并转至第107页的“创建检查错误的测试用例”。如果未按照前面章节中的步骤进行操作，则必须从master 库中复制已完成的设计，以便可以完成这一章。以下步骤说明如何从master库复制完成的设
MSSQL数据库高可用性方案
高可用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高可用性 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
calibre_LVS入门
Calibre环境做LVS步骤及注意事项 1、LVS数据准备 在Astro中完成芯片后提取.fv文件及.gds文件，这两个文件是做LVS必备的。.v文件用来生成在LVS过程中用来和Layout进行比对的.spi文件，而.gds 文件用来读入calibre得到Layout。 2、将.gds文件读入calibre 具体步骤省略。 3、生成.spi文件 .spi文件是由.v和一些.cdl、.spi文件一同生成的。 生成.spi文件有一个脚本，以SMIC18 工艺xxx目录为例： v2lvs \ -lsp xxx/smic18.cdl \ -lsp xxx/POR.cdl \ -lsp xxx/RAM256X8.cdl \ -lsp xxx/SP018W.sp \ -s xxx/smic18.cdl \ -s xxx/POR.cdl \ -s xxx/RAM256X8.cdl \ -s xxx/SP018W.sp \ -s0 VSS \ -s1 VDD \ -v $topCell.v \ -o $topCell.spi 格式是固定的，-lsp后面列出你所要做LVS的芯片用到的IP的.spi（.sp）文件，rom、ram、stdcell是.cdl文件。-s后面再把-lsp列出的文件重复一遍。-s0和-s1不变，-v后面写你要进行转换的.fv文件，-o后面写你要输出的.spi文件。 文件写好后，在文件所在目录直接键入文件名，文件即开始自动执行。执行后若无warning和error即可。 icc中提取出来的.v文件需要有phsical only的器件，但是不需要corner和filler pad，pcut和power IO必须加进去。还有一些格式要求，需要使用如下选项：wirte_verilog –diode_ports –split_bus –no_pad_filler –no_corner_filler_cells -pg 这些信息加好后，再进行上面转换.spi文件的步骤。 4、完善layout和.spi文件 在smic工艺下： （1）、layout完善 此时要先检查pad上面的text是否打好。之后要把FP打上。关于FP，以下是从smic的IO文档中找到的解释： FP stands for ‘From Power Pad’ and FP pin is for global signal. Under normal condition, FP is activated by PVDD2W of Standard I/O library SP018W to ‘HIGH’ (3.3V). FP rail will be automatically connected while joining with other digital I/O cells. 打TEXT的时候要打FP，但是注意：只有digital pad有FP。 （2）、.spi完善