楼主:
phdch (我爱)
2020-04-23 23:35:07一般机房都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一起
不能提供会有什么问题出现
请问有经验大大有什么关键点
谢谢
作者:
blackhippo (PH6.0 微．酸民)
2020-04-23 23:38:00$$.架构复杂化代表出问题的时候查修也是复杂化AP跟DB要摆异地的想法是什么?
楼主:
phdch (我爱)
2020-04-23 23:46:00一机房已有ap虚拟化infra,但无法db虚拟化,要另买高阶设备来db虚拟化,长官说要分开遥远两机房,却没有力说法可反驳
作者: fonzae (fonzae) 2020-04-23 23:59:00
延迟时间看起来没问题,那就是看资料吞吐量跟网络校错不过很好奇为什么不把AP移回,既然是虚拟化,V走不难吧更别说lun还是在b机房的storage,不太懂
作者:
goodga ( )
2020-04-24 00:57:00你看ping哪会准 实测IOPS/latency 就知道，当你量大的时候就很明显慢很多
之前512k专线连东南亚DB, 每个SQL commit是2秒起跳ap不要有loop执行SQL的行为,基本上对user是无感的另外, 一定要懂得写 stored procedureshrinking data取代包tag之类的行为,大体上就没差异
楼主:
phdch (我爱)
2020-04-24 08:33:00回答f大,架构是stor1--APvm---10Gbps---DBvm---stor2回答f大,仅规划,AP用vmware,DB用别hypervisor,硬件独立建置回答k大,架构是stor1--APvm---10Gbps---DBvm---stor2,有法回答g大,stor1--APvm---100km---DBvm---stor2,两边有存储回答g大,因为都有local storage,IOPS与latency是OK的回答kon大,有跟DBA确认,您说的SQL指令与SP执行真的是关键DBA说之前SP在AP上,效能差,后移至DB执行效能好很多我们AP也会对DB下SQL指令,但若量大真的不建议相隔100km量大不大,还要跟写ap程式同事确认同事说好像没什么tag,但shrinking data有这样技术dataRow去insert或del会造成OSstorage资料破碎,似磁盘重整
作者:
slash66 (JimmyHuang)
2020-04-24 08:56:00通常异地是备份AP跟DB，不会拿来当线上的服务，网络延迟效能，资安，排除故障，会衍生出很多问题
楼主:
phdch (我爱)
2020-04-24 08:58:00我们先规画线上ap与线上db相隔100km以上,可否?技术上论瓶颈回答s大,网络延迟估20ms内,我们某系统ap,db相离100km是这样资安会两边做好必要设定,排除故障两边会有维运人员
作者:
slash66 (JimmyHuang)
2020-04-24 09:05:00这样做是为了什么？好处是？你只要拉到外面去就会有网络问题，因为线路不是你能控制的，万一网络有问题内部都不能运作，这种线上就是要求稳定快速，到时搞死自己
作者:
voodist (小虫)
2020-04-24 09:36:00有设想过发生最糟糕的情况下 要怎样维持服务正常吗？
楼主:
phdch (我爱)
2020-04-24 09:43:00回应s大,长官说要这样规划,但实在想不出好处.
作者:
tx50xyz (想要好的房贷利率)
2020-04-24 09:43:00这种架构，优点较少，缺点一大堆，如网速、连线设备、存放地的安全性、AP与DB系统压力测试等，只要缺一项就都不能使用，风险极大，是有这必要性吗？是挑战自己的技术性吗？怪怪的
楼主:
phdch (我爱)
2020-04-24 09:44:00网络方面有做好HA,网络设备也有HA,每一段都有回应v大,最糟就是SQL commit太频繁,影响终端用户感受回应t大,也许是长官想让我们MIS挑战我们的技术能力吧
作者:
voodist (小虫)
2020-04-24 10:01:00如果主备线路很刚好都出现异常或断线？
作者:
johnten (每张照片都是一段缘份)
2020-04-24 15:38:00钱太多 可以这样多 两地的机房投资 两地的人力
作者:
gcnet (gcn)
2020-04-24 17:52:002ms&20ms, 反应在交易延迟上会变0.2s&2s光测login就慢了，其它ap逻辑应该会更慢
台湾本岛内只要预算可以通过,绝对没有任何问题那个交易延迟根本不会放大,本来是0.2s,就变成0.2s+40ms40ms就是网络来回的差异,不会到2s那么夸张而且本地端也是可以安装proxySQL之类的,把常用SQL做快取AP本身也可以做快取,不会有0.2s变2s这种事出现讲login慢的大概没写过程式吧?login要几个SQL指令?即使需要10个SQL,也不过就是相差(20-2)*10=180ms而已多等个0.2s有差很多吗?而且原Po的网络连接是10Gbps,比一般公司的网络还快10倍跑起来根本无感
大频宽建设vpn,ping还可以，但oraDB 直连就是惨
作者:
gcnet (gcn)
2020-04-24 22:42:00ad+sso+加密的login+登入后的个资呈现要交易几次?有dark fiber就ok啦
如果ap及db用10g在连方那问题不大,如果没这么好的速度,就非常考验写程式的能力了
要先看应用模式吧，可以接受异步/延迟同步才能在这架构，不然那个but出来不就部门内爆炸
作者: erictaiwan (e1) 2020-04-29 18:10:00
厨房煮菜会冰箱DB放一楼, 瓦斯炉AP放五楼吗?