作者:
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放五樓嗎?