作者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/m.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