硬件负载均衡设备负载均衡一般包含哪些组件和硬件

硬件负载均衡支持oracle数据库吗

oracle的高可用与负载均衡 浏览了一下Oracle官方的网页以及非官方的ppt，简单了解了一下Oracle提供的高可用方案。

1. RAC RAC, Real Application Clusters 多个Oracle服务器组成一个共享的Cache，而这些Oracle服务器共享一个基于网络的存储。

这个系统可以容忍单机/或是多机失败。

不过系统内部的多个节点需要高速网络互连，基本上也就是要全部东西放在在一个机房内，或者说一个数据中心内。

如果机房出故障，比如网络不通，那就坏了。

所以仅仅用RAC还是满足不了一般互联网公司的重要业务的需要，重要业务需要多机房来容忍单个机房的事故。

2. Data Guard. Data Guard这个方案就适合多机房的。

某机房一个production的数据库，另外其他机房部署standby的数据库。

Standby数据库分物理的和逻辑的。

物理的standby数据库主要用于production失败后做切换。

而逻辑的standby数据库则在平时可以分担production数据库的读负载。

3. MAA MAA(Maximum Availability Architecture)其实不是独立的第三种，而是前面两种的结合，来提供最高的可用性。

每个机房内部署RAC集群，多个机房间用Data Guard同步。

Oracle+Fusionio+Dataguard的高可用方案 传统的Oracle的高可用方案必须基于共享存储设备，不管是双机主备模式，还是Oracle RAC，数据库必须放在共享的SAN存储上，通过HA或集群软件实现高可用。

Oracle DataGuard是很好的容灾软件，但是作为HA解决方案，功能有很多局限性，比如数据丢失，应用透明切换，只能读无法写(11g)等等，目前都没有非常好的解决方案。

自从固态存储技术出现后，单机的IO能力大幅度提升，比如采用PCIE接口的fusionio卡，单块卡就可以提供数万IOPS的能力，单机的IO能力已经超过了传统的磁盘存储。

但是，一直困扰我们的是，如何解决无共享存储环境下Oracle数据库的高可用问题？我们团队设计了一种架构，提供简单可靠的高可用功能。

虽然在Oracle的立场上，总是建议客户能够更好地规划自己的应用，在有其它负载平衡方法的时候，尽量不要依赖于Oracle的Load Balance方法，但是往往在给客户配置完Oracle RAC数据库以后，客户都会要求要测试负载平衡（Load Balance）和TAF（Transparent Application Failover），并且将这两个测试作为RAC是否安装成功的标准。

这是一件很无奈的事情，像把旁枝末节看作了主要功能，甚至有些买椟还珠的感觉，但是毕竟这是客户，更了解Oracle Load Balance（后文用LB表示），才可以更好满足客户需求。

RAC的负载均衡主要是指新会话连接到RAC数据库时，如何判定这个新的连接要连到哪个节点进行工作。

在RAC中，负载均衡分为两种，一种是基于客户端连接的，另外一种是基于服务器端的。

客户端的负载均衡配置相对简单，只需要在tnsnames.ora中添加LOAD_BALANCE=ON这么一个选项即可。

实现负载均衡(Load Balance)是Oracle RAC最重要的特性之一，主要是把负载平均分配到集群中的各个节点，以提高系统的整体吞吐能力。

通常情况下有两种方式来实现负载均衡 一个是基于客户端连接的负载均衡 客户端的负载均衡主要是通过为tnsnames.ora增加load_balance=yes条目来实现 如果未开启load_balance=yes时，Oracle Net会根据地址列表按顺序来选择一个进行连接，直到连接成功为止。

如果第一个host主机连接失败，在有多个地址的情形下，接下来选择第二个地址连接，依此类推，直到连接成功为止。

当开启了load_balance=yes时，则Oracle Net会从多个地址中随机地选择一个地址进行连接，直到连接成功为止。

注意，此连接方式仅根据地址列表随机选择，并不考虑到各个实例上当前真正连接数量的多少，也即是没有考虑各个节点真实的连接负载情况 二是基于服务器端监听器(Listener)收集到的信息来将新的连接请求分配到连接数较少实例上的实现方式。

Oracle RAC服务器端的负载均衡是根据RAC中各节点的连接负荷数情况，将新的连接请求分配到负荷最小的节点上去。

当数据库处于运行时，RAC中各节点的PMON进程每3秒会将各自节点的连接负荷数更新到service_register。

而对于节点中任意监听器故障或监听器意外失败时，PMON进程会每1秒钟检查当前节点上的监听是否重启，以获得最新的负载信息来及时调整负载均衡。

跨机房问题 跨机房问题一直都是一个老大难的问题，先看传统数据库的跨机房方案。

Master/Slave方案 这是最常用的方案，适用于大多数需求。

Master将操作日志实时地发送到Slave，Slave当成Master的一个Hot Backup。

Master宕机时，服务切换到Slave，需要修改客户端逻辑使得Master失效时自动寻找新的Master。

这个方案有一个问题就是数据库的Master和Slave一般不是强同步的，所以，切换到Slave后可能丢失宕机前的少量更新。

如果将 Master和Slave做成强同步的，即：所有的数据必须同时写成功Master和Slave才成功返回客户端，这样又带来了另外一个问 题：Master和Slave中任何一台机器宕机都不允许写服务，可用性太差。

因此，Oracle有一种折衷的模式：正常情况下Master和Slave 是强同步的，当Master检测到Slave故障，比如Slave宕机或者Master与Slave之间网络不通时，Master本地写成功就返回客户 端。

采用这种折衷的同步模式后，一般情况下Master和Slave之间是强同步的，Master宕机后切换到Slave是安全的。

当然，为了确保数据安 全后，宕机的Master重启后可以和新的Master(原有的Slave)对比最后更新的操作日志，如果发现不一致可以提醒DBA手工介入，执行数据订 正过程。

Master和Slave之间强同步还有一个问题就是跨机房延时，对于关键业务，同城的机房可以部署专用光纤，在硬件层面上解决这个问题；异地的机房一般用来做备份，与主机房之间的数据同步一般是异步的，可能有秒级延时。

机房宕机切换自动化成本太高，但是对于很多单点服务，机房内部宕机切换的自动化很有必要。

Oceanbase采用Linux的一个开源方 案：Pacemaker，通过heartbeat和虚IP漂移的方式实现机房内部宕机自动切换。

由于主备切换本质上是一个选主问题，理论上只有Paxos 或者类似协议可以解决，而Pacemaker没有采用复杂的Paxos协议，它对硬件是有依赖的，比如要求主备节点之间通过直连线保证网络不会发生故障， 而这在机房内部是可以做到的。

机房之间采用前面提到的Master/Slave方案，可以写一个脚本ping主机房的Master，当确认主机房 Master宕机时(比如一分钟不通)将服务切换到备机房并报警。

有没有朋友知道硬件负载均衡有哪些品牌？哪个品牌更好一些？

个人觉得还是F5这个品牌更好，F5是负载均衡的代名词，是行业老大，市场第一。

F5是全代理架构：确保最佳的应用可用性和性能-根据实时应用交付数据将用户定向到最佳地点；管理IPv4与IPv6服务的不兼容性和迁移-允许流量在不同网络拓扑之间自由流动和共存；满足未来业务要求-支持当前以及将来所有主要协议；优化性能并智能地路由流量-根据流量数据做出最佳的可用性决策。

他们还有先进的负载均衡与代理解决方案产品推荐：BIG-IP广域流量管理器，BIG-IP本地流量管理器。

功能比较强大，同时也有专门的售后服务团队，性能还比较好。

服务器负载均衡问题，需要的设备和软件

你上面说到的这些服务器只有Web服务器需要做负载均衡，而且一般都是前置机才做负载均衡，做服务器负载均衡的条件是： 1. 你要有提供相同应用的多台Web服务器。

2. 要有负载均衡的设备（可以是软件也可以是硬件）。

3. 要为这个服务分配一个虚拟地址（作为服务访问的统一入口）和若干真实地址（有几台Web服务器需要几个真实地址）。

注：一般建议采用硬件设备，通常需要做负载均衡的应用说明他的负载很大，专用的硬件比较可靠。

具备以上条件后将Web服务器连接到负载均衡设备上，在负载均衡设备上配置虚拟地址和真实地址、配置负载均衡算法，配置负载均衡策略，将负载均衡设备接入网络。

这样，外面的用户只需要访问这个虚拟地址就可以了，负载均衡设备收到请求后会按照负载均衡策略和算法把请求分配到真实地址上，实现负载功能。

以上所说只是负载均衡的一种部署方式，根据实际需要选择单臂、双臂接入网络；根据应用的特点选择健康检查的方式；根据应用选择是否使用回话保持算法等。

负载均衡一般包含哪些组件和硬件

负载均衡包含服务器负载均衡和链路负载均衡，用硬件和软件都能实现，但硬件比较省心，这方面不错的厂商有F5、深信服，不过国内性价比高、服务比较完善的还是深信服，特别是他们的单边加速功能不错。