[請益] 主DB與主AP分離兩地超過100km

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