作者phdch (爱咪)
看板MIS
标题[请益] 主DB与主AP分离两地超过100km
时间Thu Apr 23 23:35:07 2020
一般机房都ap与db同site
云端化aws,ap与db也都在一起
因为各单位db分散,想规划集中与虚拟化
ap也集中,但两者如题超过100 km
想知道业界有无ap与db地理上隔很远
维运上有发生什麽问题？
目前是规划阶段
考虑网路的session rate,thruput,ping RTT都没太大问题
ping rtt可在20ms内
又网路与网路设备都有ha规划
目前ap与db用同一台storage的不同SSD LUN
若两者分开,可建置两套storage
真的想不出ap与db隔100km有什麽明显的缺点？
但又觉得ap与db才最好
问cisco厂商也说业界都ap,db一起
不能提供会有什麽问题出现
请问有经验大大有什麽关键点
谢谢
--
※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 114.136.124.78 (台湾)
※ 文章网址: https://webptt.com/cn.aspx?n=bbs/MIS/M.1587656109.A.4AC.html
1F：→ blackhippo: $$.架构复杂化代表出问题的时候查修也是复杂化 04/23 23:38
2F：→ blackhippo: AP跟DB要摆异地的想法是甚麽? 04/23 23:40
3F：→ phdch: 一机房已有ap虚拟化infra,但无法db虚拟化,要另买高阶设备 04/23 23:46
4F：→ phdch: 来db虚拟化,长官说要分开遥远两机房,却没有力说法可反驳 04/23 23:46
5F：→ fonzae: 延迟时间看起来没问题,那就是看资料吞吐量跟网路校错 04/23 23:59
6F：→ fonzae: 不过很好奇为什麽不把AP移回,既然是虚拟化,V走不难吧 04/24 00:00
7F：→ fonzae: 更别说lun还是在b机房的storage,不太懂 04/24 00:01
8F：推 kenwufederer: 缺点很明显吧，100公里网速有办法10G？ 04/24 00:11
9F：推 goodga: 你看ping哪会准 实测IOPS/latency 就知道，当你量大的时 04/24 00:57
10F：→ goodga: 候就很明显慢很多 04/24 00:57
11F：→ konkonchou: 之前512k专线连东南亚DB, 每个SQL commit是2秒起跳 04/24 02:04
12F：→ konkonchou: ap不要有loop执行SQL的行为,基本上对user是无感的 04/24 02:05
13F：→ konkonchou: 另外, 一定要懂得写 stored procedure 04/24 02:06
14F：→ konkonchou: shrinking data取代包tag之类的行为,大体上就没差异 04/24 02:08
15F：→ phdch: 回答f大,架构是stor1--APvm---10Gbps---DBvm---stor2 04/24 08:33
16F：→ phdch: 回答f大,仅规划,AP用vmware,DB用别hypervisor,硬体独立建置 04/24 08:35
17F：→ phdch: 回答k大,架构是stor1--APvm---10Gbps---DBvm---stor2,有法 04/24 08:36
18F：→ phdch: 回答g大,stor1--APvm---100km---DBvm---stor2,两边有存储 04/24 08:37
19F：→ phdch: 回答g大,因为都有local storage,IOPS与latency是OK的 04/24 08:38
20F：→ phdch: 回答kon大,有跟DBA确认,您说的SQL指令与SP执行真的是关键 04/24 08:50
21F：→ phdch: DBA说之前SP在AP上,效能差,後移至DB执行效能好很多 04/24 08:50
22F：→ phdch: 我们AP也会对DB下SQL指令,但若量大真的不建议相隔100km 04/24 08:52
23F：→ phdch: 量大不大,还要跟写ap程式同事确认 04/24 08:53
24F：→ phdch: 同事说好像没什麽tag,但shrinking data有这样技术 04/24 08:53
25F：→ phdch: dataRow去insert或del会造成OSstorage资料破碎,似磁碟重整 04/24 08:55
26F：→ slash66: 通常异地是备份AP跟DB，不会拿来当线上的服务，网路延迟 04/24 08:56
27F：→ slash66: 效能，资安，排除故障，会衍生出很多问题 04/24 08:57
28F：→ phdch: 我们先规画线上ap与线上db相隔100km以上,可否?技术上论瓶颈 04/24 08:58
29F：→ phdch: 回答s大,网路延迟估20ms内,我们某系统ap,db相离100km是这样 04/24 08:59
30F：→ phdch: 资安会两边做好必要设定,排除故障两边会有维运人员 04/24 09:00
31F：→ slash66: 这样做是为了什麽？好处是？你只要拉到外面去就会有网路 04/24 09:05
32F：→ slash66: 问题，因为线路不是你能控制的，万一网路有问题内部都不 04/24 09:06
33F：→ slash66: 能运作，这种线上就是要求稳定快速，到时搞死自己 04/24 09:08
34F：→ voodist: 有设想过发生最糟糕的情况下 要怎样维持服务正常吗？ 04/24 09:36
35F：→ phdch: 回应s大,长官说要这样规划,但实在想不出好处. 04/24 09:43
36F：推 tx50xyz: 这种架构，优点较少，缺点一大堆，如网速、连线设备、存 04/24 09:43
37F：→ tx50xyz: 放地的安全性、AP与DB系统压力测试等，只要缺一项就都不 04/24 09:43
38F：→ tx50xyz: 能使用，风险极大，是有这必要性吗？是挑战自己的技术性 04/24 09:43
39F：→ tx50xyz: 吗？怪怪的 04/24 09:43
40F：→ phdch: 网路方面有做好HA,网路设备也有HA,每一段都有 04/24 09:44
41F：→ phdch: 回应v大,最糟就是SQL commit太频繁,影响终端用户感受 04/24 09:45
42F：→ phdch: 回应t大,也许是长官想让我们MIS挑战我们的技术能力吧 04/24 09:46
43F：→ voodist: 如果主备线路很刚好都出现异常或断线？ 04/24 10:01
44F：推 johnten: 钱太多 可以这样多 两地的机房投资 两地的人力 04/24 15:38
45F：→ gcnet: 2ms&20ms, 反应在交易延迟上会变0.2s&2s 04/24 17:52
46F：→ gcnet: 光测login就慢了，其它ap逻辑应该会更慢 04/24 17:53
47F：推 ddoll288: 台湾本岛内只要预算可以通过,绝对没有任何问题 04/24 18:24
48F：→ ddoll288: 那个交易延迟根本不会放大,本来是0.2s,就变成0.2s+40ms 04/24 18:25
49F：→ ddoll288: 40ms就是网路来回的差异,不会到2s那麽夸张 04/24 18:25
50F：→ ddoll288: 而且本地端也是可以安装proxySQL之类的,把常用SQL做快取 04/24 18:26
51F：→ ddoll288: AP本身也可以做快取,不会有0.2s变2s这种事出现 04/24 18:28
52F：→ ddoll288: 讲login慢的大概没写过程式吧?login要几个SQL指令? 04/24 18:33
53F：→ ddoll288: 即使需要10个SQL,也不过就是相差(20-2)*10=180ms而已 04/24 18:36
54F：→ ddoll288: 多等个0.2s有差很多吗? 04/24 18:36
55F：→ ddoll288: 而且原Po的网路连接是10Gbps,比一般公司的网路还快10倍 04/24 18:39
56F：→ ddoll288: 跑起来根本无感 04/24 18:40
57F：→ dennisxkimo: 大频宽建设vpn,ping还可以，但oraDB 直连就是惨 04/24 21:10
58F：→ gcnet: ad+sso+加密的login+登入後的个资呈现要交易几次? 04/24 22:42
59F：→ gcnet: 有dark fiber就ok啦 04/24 22:43
60F：推 mypigbaby: 如果ap及db用10g在连方那问题不大,如果没这麽好的速度, 04/25 08:38
61F：→ mypigbaby: 就非常考验写程式的能力了 04/25 08:38
62F：→ justoncetime: 要先看应用模式吧，可以接受非同步/延迟同步才能在 04/26 02:02
63F：→ justoncetime: 这架构，不然那个but出来不就部门内爆炸 04/26 02:02
64F：推 erictaiwan: 厨房煮菜会冰箱DB放一楼, 瓦斯炉AP放五楼吗? 04/29 18:10