→ blackhippo: $$.架構複雜化代表出問題的時候查修也是複雜化 04/23 23:38
→ blackhippo: AP跟DB要擺異地的想法是甚麼? 04/23 23:40
→ phdch: 一機房已有ap虛擬化infra,但無法db虛擬化,要另買高階設備 04/23 23:46
→ phdch: 來db虛擬化,長官說要分開遙遠兩機房,卻沒有力說法可反駁 04/23 23:46
→ fonzae: 延遲時間看起來沒問題,那就是看資料吞吐量跟網路校錯 04/23 23:59
→ fonzae: 不過很好奇為什麼不把AP移回,既然是虛擬化,V走不難吧 04/24 00:00
→ fonzae: 更別說lun還是在b機房的storage,不太懂 04/24 00:01
推 kenwufederer: 缺點很明顯吧，100公里網速有辦法10G？ 04/24 00:11
推 goodga: 你看ping哪會準 實測IOPS/latency 就知道，當你量大的時 04/24 00:57
→ goodga: 候就很明顯慢很多 04/24 00:57
→ konkonchou: 之前512k專線連東南亞DB, 每個SQL commit是2秒起跳 04/24 02:04
→ konkonchou: ap不要有loop執行SQL的行為,基本上對user是無感的 04/24 02:05
→ konkonchou: 另外, 一定要懂得寫 stored procedure 04/24 02:06
→ konkonchou: shrinking data取代包tag之類的行為,大體上就沒差異 04/24 02:08
→ phdch: 回答f大,架構是stor1--APvm---10Gbps---DBvm---stor2 04/24 08:33
→ phdch: 回答f大,僅規劃,AP用vmware,DB用別hypervisor,硬體獨立建置 04/24 08:35
→ phdch: 回答k大,架構是stor1--APvm---10Gbps---DBvm---stor2,有法 04/24 08:36
→ phdch: 回答g大,stor1--APvm---100km---DBvm---stor2,兩邊有存儲 04/24 08:37
→ phdch: 回答g大,因為都有local storage,IOPS與latency是OK的 04/24 08:38
→ phdch: 回答kon大,有跟DBA確認,您說的SQL指令與SP執行真的是關鍵 04/24 08:50
→ phdch: DBA說之前SP在AP上,效能差,後移至DB執行效能好很多 04/24 08:50
→ phdch: 我們AP也會對DB下SQL指令,但若量大真的不建議相隔100km 04/24 08:52
→ phdch: 量大不大,還要跟寫ap程式同事確認 04/24 08:53
→ phdch: 同事說好像沒什麼tag,但shrinking data有這樣技術 04/24 08:53
→ phdch: dataRow去insert或del會造成OSstorage資料破碎,似磁碟重整 04/24 08:55
→ slash66: 通常異地是備份AP跟DB，不會拿來當線上的服務，網路延遲 04/24 08:56
→ slash66: 效能，資安，排除故障，會衍生出很多問題 04/24 08:57
→ phdch: 我們先規畫線上ap與線上db相隔100km以上,可否?技術上論瓶頸 04/24 08:58
→ phdch: 回答s大,網路延遲估20ms內,我們某系統ap,db相離100km是這樣 04/24 08:59
→ phdch: 資安會兩邊做好必要設定,排除故障兩邊會有維運人員 04/24 09:00
→ slash66: 這樣做是為了什麼？好處是？你只要拉到外面去就會有網路 04/24 09:05
→ slash66: 問題，因為線路不是你能控制的，萬一網路有問題內部都不 04/24 09:06
→ slash66: 能運作，這種線上就是要求穩定快速，到時搞死自己 04/24 09:08
→ voodist: 有設想過發生最糟糕的情況下 要怎樣維持服務正常嗎？ 04/24 09:36
→ phdch: 回應s大,長官說要這樣規劃,但實在想不出好處. 04/24 09:43
推 tx50xyz: 這種架構，優點較少，缺點一大堆，如網速、連線設備、存 04/24 09:43
→ tx50xyz: 放地的安全性、AP與DB系統壓力測試等，只要缺一項就都不 04/24 09:43
→ tx50xyz: 能使用，風險極大，是有這必要性嗎？是挑戰自己的技術性 04/24 09:43
→ tx50xyz: 嗎？怪怪的 04/24 09:43
→ phdch: 網路方面有做好HA,網路設備也有HA,每一段都有 04/24 09:44
→ phdch: 回應v大,最糟就是SQL commit太頻繁,影響終端用戶感受 04/24 09:45
→ phdch: 回應t大,也許是長官想讓我們MIS挑戰我們的技術能力吧 04/24 09:46
→ voodist: 如果主備線路很剛好都出現異常或斷線？ 04/24 10:01
推 johnten: 錢太多 可以這樣多 兩地的機房投資 兩地的人力 04/24 15:38
→ gcnet: 2ms&20ms, 反應在交易延遲上會變0.2s&2s 04/24 17:52
→ gcnet: 光測login就慢了，其它ap邏輯應該會更慢 04/24 17:53
推 ddoll288: 台灣本島內只要預算可以通過,絕對沒有任何問題 04/24 18:24
→ ddoll288: 那個交易延遲根本不會放大,本來是0.2s,就變成0.2s+40ms 04/24 18:25
→ ddoll288: 40ms就是網路來回的差異,不會到2s那麼誇張 04/24 18:25
→ ddoll288: 而且本地端也是可以安裝proxySQL之類的,把常用SQL做快取 04/24 18:26
→ ddoll288: AP本身也可以做快取,不會有0.2s變2s這種事出現 04/24 18:28
→ ddoll288: 講login慢的大概沒寫過程式吧?login要幾個SQL指令? 04/24 18:33
→ ddoll288: 即使需要10個SQL,也不過就是相差(20-2)*10=180ms而已 04/24 18:36
→ ddoll288: 多等個0.2s有差很多嗎? 04/24 18:36
→ ddoll288: 而且原Po的網路連接是10Gbps,比一般公司的網路還快10倍 04/24 18:39
→ ddoll288: 跑起來根本無感 04/24 18:40
→ dennisxkimo: 大頻寬建設vpn,ping還可以，但oraDB 直連就是慘 04/24 21:10
→ gcnet: ad+sso+加密的login+登入後的個資呈現要交易幾次? 04/24 22:42
→ gcnet: 有dark fiber就ok啦 04/24 22:43
推 mypigbaby: 如果ap及db用10g在連方那問題不大,如果沒這麼好的速度, 04/25 08:38
→ mypigbaby: 就非常考驗寫程式的能力了 04/25 08:38
→ justoncetime: 要先看應用模式吧，可以接受非同步/延遲同步才能在 04/26 02:02
→ justoncetime: 這架構，不然那個but出來不就部門內爆炸 04/26 02:02
推 erictaiwan: 廚房煮菜會冰箱DB放一樓, 瓦斯爐AP放五樓嗎? 04/29 18:10