具有网络负载平衡的虚拟IP地址
群集中的所有服务器都关联到一个虚拟IP地址上。此地址的输入流量由所有服务器接收，并由每台服务器内核中的过滤器分解。一旦访问信息被一台服务器接收，应用程序只使用这台服务器的CPU和内存对客户的请求做出回应：反馈信息由应用程序服务器直接发送到客户端。如果某台服务器失效，Safekit成员协议将重新配置Farm中的过滤器，以便利用剩余的有效服务器重新平衡网络流量。
设置每台服务器的网络负载
每台服务器可以通过权值的配置来决定流量的多少：每台服务器分配的流量与其权值成正比。
您还可以配置负载均衡的算法：通过负载均衡模块的IP配置，相同客户端通过连续的TCP会话连接到 相同服务器上：这样将保留客户端的环境。
其他算法主要正对没有申明的应用程序、UDP服务、防火墙等，他的特性在于，负载均衡设置识别客户端的会话ID而不是客户端的IP地址,相同客户端将TCP会话连续的分布到FARM架构中的不同服务器中。
2至10台服务器是FARM架构的理想方案
依据性价比关系，SafeKit的纯软件负载均衡更适用于中小规模的Server Farm，尤其是2到10台服务器。对于更大规模的服务器负载均衡，购买昂贵的网络负载均衡硬件设备反而比较划算。
一个适用于Windows和Unix平台各种应用的纯软件高可用性方案.
Mirror 镜像
Safekit镜像架构
文件复制和故障切换
镜像架构是一种适合所有应用程序的主-备模式的高可用性方案。如果主服务器失效，运行在主服务器上的应用程序将自动在备用服务器上启动。
文件复制功能，此种架构尤其适合于包含关键数据的后台应用程序的高可用性保护。
Microsoft SQL Server.Safe, MySQL.Safe, and Oracle.Safe是镜像类型应用模块的各模板。您可以以通用模块Mirror.safe为例，为自己的应用程序编写镜像模块。
备份机制运行原理如下：
第一步：普通配置。配置应用程序文件复制。（对2台服务器的磁盘组织没有先决条件）对两台机器的磁盘类型没有要求.。例如，文件复制可能在服务器1的内部RAID5磁盘上，也可能在服务器2的简单内部磁盘上。例如，server1上要复制的文件可能在一个RAID5的磁盘上，而server2的复制文件则存在于一个类型为简单卷的磁盘上。
当server1运行此程序时，SafeKit便会自动复制此程序运行的更新文件。只有应用更新过的数据才会通过网络时时同步过去，这样就节省了网络流量。两台服务器上的数据实时同步机制，也保证了在主机失效时，不会有数据丢失。特别是，时时文件复制保证了事务处理程序写入到磁盘的每一项数据在备用服务器上都是有效的――这个效果在异步复制是达不到的。
第二步：当server1失效时，server2将接管任务。SafeKit将自动切换群集的虚拟IP地址到server2上，并在server2上自动启动应用程序。由于同步复制，当server1失效时，应用程序将查找被SafeKit复制的在server1失效时同一状态下的文件。
转换时间等于故障检测时间（缺省是30秒钟）加上应用程序启动时间。跟磁盘镜像方案不同，重新装载文件系统和运行恢复过程没有延迟。
第三步：故障恢复。故障恢复是当引起宕机的问题解决之后，重新启动server1。SafeKit自动进行文件同步，只更新当server1宕机时在server 2上的修改过的文件。
这种同步不会阻碍程序的运行，应用程序仍可在服务器2上运行。这是SafeKit不同于其他方案的一个主要特征，其他方案则要求您终止服务器2上的应用程序以便与服务器1同步。
第四步：同步后，文件再次处于进入镜像模式，如第一步。整个系统恢复到高可用模式，应用程序在server2上运行，并且SafeKit复制更新的文件到备份server1。如果您希望应用程序在server上运行，可以通过设置“Swap”命令手动或自动回切。
|
公司简介
