本地逃生异地融灾方案设计.doc

异地融灾, 当地逃生
一: 组网模式
整个组网环境中有一台主SoftCo, 一台备SoftCo, 以及一定数量当地SoftCo, 以下图所表示:

从上面组网模式看, 各台SoftCo之间关键有两个方面关系:
1， 主softCo和当地SoftCo之间关系, 其中主SoftCo向当地SoftCo实时备份与当地Softo相关业务数据, 它们之间需要满足当地逃生功效。
2， 主SoftCo和备SoftCo之间关系, 其中主SoftCo向备SoftCo备份全部静态数据表, 它们之间需要满足异地融灾功效。
当地逃生和异地融灾一个基础策略是正常情况下主SoftCo与当地SoftCo建立连接, 主SoftCo与备SoftCo建立连接。业务在主SoftCo上注册, 主SoftCo是整个网络内关键节点, 它关键工作是:
1， 处理正常语音业务;
2， 向当地SoftCo实时同时它们所需要数据;
3， 向备SoftCo实时同时全部静态表, 完成冷备功效;
当主SoftCo出现故障时, 系统自动触发异地融灾功效, 全部业务转移到备SoftCo上进行处理, 同时当地SoftCo与备SoftCo进行连接, 备SoftCo实时向当地SoftCo进行数据同时。当备SoftCo也出现故障时, 触发当地逃生功效, 业务处理分散到各个当地SoftCo上。

二: 实现策略
每台SoftCo可配制为四种工作模式主节点模式, 备节点模式, 当地节点模式, 正常节点模式; 同时每台SoftCo 能够配制其对应得主节点IP, 备节点IP, 以及当地节点IP。以上图为例:
（1） 首先当地节点C1, C2, C3分别配制了主备节点A, BIP, 这两个IP没有优先级, 即对于当地接点来说地位平等。另一面主节点A配制了备节点B以及当地节点C1, C2, C3IP; 备节点B上配制了主节点A以及当地节点C1, C2, C3IP。
（2） 上述配制完成以后, 能够分别经过命令行开启各个节点工作模式。A节点位主节点工作模式; B节点位备节点工作模式; C1, C2, C3为当地节点工作模式。
（3） 各个节点工作模式开启以后, 主节点A打开两个端口用于监听备节点B以及从节点C1, C2, C3提议连接; 备节点B打开一个端口用于监听当地节点C1, C2, C3提议连接, 同时备节点B不停尝试连接主节点A; 当地节点C1, C2, C3不停尝试交替连接主节点A, 备节点B。
（4） 当备节点B与主节点A连接成功建立后, 两个节点在检验完版本是否一致后, 主节点A向备节点B做第一次数据表全备份。从节点C1, C2, C3采取连接策略因为是交替式连接A和B, 那么可能会有一部分连接在主节点A上, 一部分连接在备节点B上。对于这种`情况处理方法是, 通常连接到主节点A受骗地节点, 主节点直接向其同时所需要数据; 对于连接到备节点B受骗地节点, 备节点B首先判定其与主节点连接是否建立, 假如已经建立, 说明主节点A没有发生故障, 则备节点B拒绝当地节点连接, 使它们重新尝试连接主节点, 假如没有建立, 则备节点B可向当地节点同时数据。
（5） 对于主节点A从故障中恢复后处理, 首先有一个标准是备节点永远不能向主节点同时数据。当主节点A从故障中恢复后, 备节点B中一直有个定时器, 在不停检测备节点与主节点连接情况, 当发觉备节点与主节点连接建立好以后, 备节点就主动将连接在其受骗地节点断开以使这些节点去连接主节点。这里有一个风险, 主节点恢复后会同时数据给备节点, 这么会将备节点以前数据冲掉, 假如确实需要备节点数据, 天天凌晨有DB自动上传能够自动保留DB文件。

上述策略中存在部分问题和限制: 需要向一线确定一下异地融载和当地逃生时候, 是否不需要考虑软终端？只考虑硬终端呼叫和业务可用即可。

（1） 备份方向只有三个方向, 其一主节点-〉备节点; 其二主节点-〉当地节点; 其三备节点-〉当地节点。
（2） 主节点与备节点每次连接建立时, 不管备节点处于什么状态, 就向备节点上提议第一次全备份。同时当主节点与备节点之间连接建立好情况下, 不许可备节点进行数据配置; 这点有问题, 假如备节点也是一个银行网点, 原本在备节点区域用户即使注册到主节点上, 不过备节点也是需要与PSTN对接, 实现当地出局, 假如其她银行网点临时有特殊出局需求时候, 我们就没法做了, 所以备节点不许可做数据配置, 提议改为不能做用户以及业务数据配置。
当备节点与主节点连接断开时, 备节点才许可进行数据配置。
（3） 主节点恢复后会同时数据给备节点, 这么会将备节点以前数据冲掉, 假如确实需要备节点数据, 天天凌晨有DB自动上传能够自动保留DB文件。
（4） 备节点断开与当地节点连接时机选择是一个问题。现在备节点判定主节点是否出现故障唯一依据是其与主节点连接是否正常, 在这种情况下因为网络原因可能会造成误判, 其中可能有以下多个场景:
场景一: A-B之间链路断开; A-C1, A-C2之间链路连接; B-C3之间链路连接。这个场景即是一部分当地节点连接到主节点A上, 一部分连接到备节点B上, 而备节点又与主节点连接断开。这种情况会产生一个问题, 首先因为备节点与主节点连接断开, 其认为主节点出现故障, 所以备节点向当地节点同时数据; 其次主节点其实没有故障, 只是与备节点间网络连接出现问题, 所以其又向当地节点同时数据, 这么就出现部分当地节点接收主节点数据, 部分当地节点接收备节点数据。出现这种情况时, 最合理处理方法是需要将备节点连接当地节点全部断掉让它们去连接主节点, 不过这种场景程序极难自动判定, 需要在发觉这种场景时, 人工经过实施对应命令行断掉, 或者采取一个策略, 此种场景中, 在指定时间段里（10min）, 当备节点与当地节点建立连接数不能够超出当地节点总数二分之一时, 备节点将主动断开与当地节点连接使当地节点向主节点连接。
场景二: A-B之间链路断开, B-C1; B-C2; B-C3之间链路连接。出现这个场景时, 就说明主节点A确实发生故障了, 那么这时备节点B向全部当地节点同时数据。问题在于当主节点A恢复后, 备节点与主节点间连接成功建立好时, 是立刻切断备节点与当地节点之间连接还是延迟一段时间等凌晨在切断, 即是否需要立刻切回主节点工作。上述场景一立刻切回主节点比较合理; 场景二延后切回比较合理, 不过程序极难判定是上述两种场景哪一个, 现在统一设计成只要备节点发觉其与主节点连接建立好后, 就立刻端掉它与其它备节点连接。

处理上述切回主节点时机问题有以下两个方法:
1， 业务侧是否能够判定现在业务是在主节点上进行处理还是在备节点上进行处理。当主节点恢复时, 备节点与主节点连接已经建立, 而且备节点不停检测现在自己是否在处理业务。假如在处理业务, 备节点将拒绝主节点数据同时请求, 而且不停开其与当地节点连接, 即不切回主节点; 一旦备节点检测到现在没有业务在处理, 则能够立即切回主节点, 以后主节点可向备节点备份数据。
2， 依据备节点上现在已经连接当地节点数目决议是否立刻切换。假如现在备节点上已经连接当地节点数大于当地节点总数1/3（这个权值能够改）, 那么就不适合立刻切换, 则等候凌晨断掉与它们连接, 同时这种情况下, 备节点也不接收主节点数据同时请求; 反之立刻切换回主节点。

看是否能够选择不管在哪种情况下, 只要主节点与备节点连接建立, 就立刻切回主节点方法。此方法控制起来较为统一, 处理简练, 坏处是反应太过灵敏, 快速切回, 可能这也是好处。

三: 主备节点数据备份实现机制
主备节点备份状态可分为以下两种状态:
1， IDLE状态, 此状态表示主备节点连接还没有建立时状态。
2， 初始备份态, 此状态表示主备节点连接建立好以后, 主节点向备节点提议第一次全备份过程
3， 日常备份态, 主备节点间完成第一次全备份以后。
其中状态迁移以下图所表示:

上图步骤描述以下:
1， 主备SoftCo连接建立成功, 主备节点备份状态为IDLE态
2， 主节点向备节点提议第一次全备份请求消息, 并其10s定时器, 超时重发请求消息。
3， 备节点接收到该请求消息, 判定是否许可全备份（比如判定主备版本是否一致）。假如许可备份, 将自己状态置为初始备份态, 并给主节点许可备份应答; 不然, 不迁状态, 并给主节点返回拒绝备份应答。
4， 主节点接收到许可备份应答后, 停定时器, 将自己状态迁到初始备份态, 并提议第一次全备份。
5， 当备节点检测到备份到最终一张表时, 统一调用一次全部表回调后, 将自己状态迁到日常备份态, 并向主节点应答第一次全备份完成通知。
6， 主节点接收到备份完成通知后, 将自己状态迁到日常备份态
7， 在主备节点都是日常备份态时, 关键完成数据统计实时备份以及定时检测实时全备份。

主备节点之间数据备份方法关键有以下三种:
1， 第一次全备份。
2， 当某条统计改变时（比如删除, 修改, 添加某条统计时）备份过去, 这个是实时备份。
3， 定时检测有哪张表数据改变了, 将其备份过去（此处理步骤与第一次全备份处理步骤一致）, 这个是定时检测备份。
以下关键介绍一下全备份和实时检测备份关键处理方法:
主备节点之间数据备份只包含静态表, 而SoftCo9500静态表中有以下四张表数据量较为庞大, 她们是: 用户号码表(EN_USERNUMBER_TABLE), 全局POTS用户数据表(EN_GLOBAL_POTS_PORT), 部件终端描述表(EN_COMPONENTS_TERMINALSS), SoftSwitch中继电路表(EN_SS_TRUNKCIRCUIT)。
基础备份策略是将上述表分成块, 每块100条统计, 其她表因为统计数不大, 能够将一张表作为一块。将这些块统一编码, 并计算它们对应DB内存区CRC值。具体备份步骤以下图所表示:
将全部静态表分成块, 以块为单位进行统一编号。具体步骤描述以下:
1， 主节点分别将全部块crc消息依次发送给备节点。
2， 备节点将主节点发送来crc值与自己对应快crc值进行比较并返回应答
3， 主节点依据备节点返回crc应答统计crc值不一样块有哪些。
4， 主节点依次对crc不一样快进行同时。
5， 备节点接收到一块后, 对此块中统计逐条更新到DB中, 并返回应答。
6， 主节点假如接收到备节点块应答, 则继续同时下一块, 假如3min没有接收到, 则重发此块。
7， 备节点接收到最终一块后, 会统一对DB表实施一次数据库回调, 并返回同时完成应答。
上述对于每个块备份, 在其中又分成数据祯进行备份, 当第一次全备份完成后, 主备节点进入日常备份态, 在日常备份态中, 主节点定时与备节点进行crc检测, 并按上述步骤同时crc不一致块。

四: 主备节点与当地节点数据备份机制
当地节点能够接收来自主节点和备节点备份数据, 对于当地节点数据备份关键分为以下两种形式:
1， 每次当地节点与主备节点连接建立时, 主备节点向当地节点进行一次全备份。
2， 在连接过程中实时进行备份。
现在存在一个风险是, 在实际环境中, 因为当地节点较多, 有可能达成300台, 而且现在实现是主节点和当地节点采取是TCP连接, 那么连接数将达成300个, 主节点作为服务器是否能够支持这么大连接数现在还不能确定（这个估量消耗部分内存资源, 能够咨询风河）, 而且这么大连接数会不会影响主节点性能也不知道, 这些都需要测试。
假如TCP连接影响到性能, 那么主节点和当地节点之间就需要使用UDP发送数据, UDP好处是占用资源少, 不过传输不可靠, 需要上层增加复杂差错控制机制, 现在能够借鉴板间通讯传输机制, 不过在公网上我们这套板间通讯机制是否能经受主考验也是需要实际测试, 所以现在为了厂验, 能够先根据以前实现TCP方法, 等以后需要对TCP这种方法立刻进行性能验证, 看是否能够满足实际组网需要, 如有性能瓶颈, 需要重新更改连接机制。