Month11 月 2015

Unicloud架構圖

擷取23

這是現職的產品架構圖

其實這不算是我規畫的架構,勉強算是補救回來的架構

原本的架構圖是下面這張

擷取24

比對一下可以知道

1.原本的沒有做load balance

2.沒有HA

3.功能沒有做分散式切割

4.沒有備份機制

 

修了一段時間之後,勉強解決一些問題

但實際上還是有一些問題需要處理

只能慢慢改進…

 

想想,能翻掉重來的話還是好事….

某前公司系統架構概圖

擷取111

某前公司做類似大數據的系統架構概圖

LB由LVS進行(預計,但實際上沒做)

WEB分為抓取數據資料一台

WEB網頁呈現一台

資料收集完後不採用資料庫的方式進行儲存

改由分散式儲存系統(DFS)進行儲存,使用的為MooseFS(簡稱MFS)

 

網路架構為同一層網段,用分散式設計進行

其中還有進行Indexs索引建立的Server,後台管理的Server,編輯用Server等

就不一一列出,需要功能配合時再增加Server

 

算是比較特殊的用法,不採用資料庫的大數據

中間當然遇過許多問題,從LVS模式、MFS的CHUNK格式等等

還有儲存空間的格式化問題,inode爆掉等等

就不一一說明了

 

系統原本採用apache+tomcat7

在進行優化時測試使用 nginx+resin

效果也不錯,但之後的更新我就不清楚了

當然這套系統還是在運作當中~

某前公司系統架構概圖

擷取

DNS解析網址後進入 LB

由雙A10做HA,Nginx做備援

WEB共有14台,由admin更新程式

資料庫結構做Master/Slave 讀寫分離

 

中間網段各層級切開,一律無對外連線

對外更新需由A10進行NAT,或由Admin進行NAT

A10與Admin 合計有 100 33 66 68 四網段的網卡連接

 

講得很簡單,細節卻很多,畢竟這只是簡化的概圖

合計五個機櫃的實體數量,老實講我也不太想畫出來

當個曾經做過這種架構的筆記

AWS Case Study: Unalis

https://aws.amazon.com/tw/solutions/case-studies/unalis/

這是現職的工作當中

因採用AWS架構而申請上去的案例

其中 Unicloud 的部分,是由我規劃調整的

當然這是一套不完善的系統

 

正常的資料數據分析應該是由EMR之類的服務去設計

當然希望有時間的時候可以改善這部分

AWS ELB Cookie

AWS的ELB

與正常的硬體設備不同

假使有 A 與 B 兩台Server

通常負載平衡會擇一導流

例如 User1 => A  User2 => B

 

但AWS ELB 則是

User1 => A+B (各50%)

 

在公司測試SSO登入的時候就卡到這個問題

登入的資料存在A 但是LOGIN導到B,導致無限迴圈

 

所以要修改一下設定

擷取

修改LBCookies 設定多一個60秒

可以選擇程式的Cookie,或是ELB自己的Cookie

如果是程式的,就不用指定時間

ELB本身的話就需要設定時間

這樣子流量就可以固定導給一台server

 

參考資料

 

http://docs.aws.amazon.com/zh_cn/ElasticLoadBalancing/latest/DeveloperGuide/elb-sticky-sessions.html

© 2024 Kila's IT Home

Theme by Anders NorénUp ↑