Centos 路由去回不同路解決方式

不知道大家有沒有在linux伺服器上有兩張網卡,且設有多段IP,但是卻如法在同網段ping通和tracert的經驗

本人我就遇過這樣的問題

如果你有兩張網卡 eth0與eth1

eth0的網段為10.10.1.0/24

eth1的網段為10.20.1.0/24

我們假設網段10.10.1.0/24的gateway是10.10.1.1

預定要讓預設的gateway裝置eth0回的話,解決的方式如下:

1.編輯iproute的規則名稱
[root@pandacentos ~]#vi /etc/iproute2/rt_tables
10     pandaroute #10為route table的值,pandaroute為route table名稱,都可自訂,但名稱請取服務名稱,方便辨識
2.重啟網路服務
[root@pandacentos ~]#service network restart
3.增加route的rule
[root@pandacentos ~]#ip route add default via 10.10.1.1 table pandaroute
[root@pandacentos ~]#ip rule add from 10.10.1.0/24 table pandaroute
以上的方式試一次性的解決方式,因為沒加到static route,所以在重開機後route就會消失,要如何避免這個問題,你可以在/etc/rc.d/rc.local上加上面這兩行制令,或用下面的static route 和rule的方式添加
[root@pandacentos ~]#vi /etc/sysconfig/network-script/route-eth0
default via 10.10.1.1 table pandaroute
[root@pandacentos ~]#vi /etc/sysconfig/netwrok-script/rule-eth0
from 10.10.1.0/24 table pandaroute
4.如果是加static route的方式,請在重起一次網路服務
[root@pandacentos ~]#service network restart

mRemoteNG 的新版本 mRemote3G -> mRemoteNG

mRemoteNG 是個把 RDP, SSH, Telnet, VNC… 等整合在一個視窗中,以 tab 分隔的免費應用程式,它的前身,沒記錯的話應該是叫 mRemote,後來因故中止了,我記得當時我花了些時間找到了另一個願意繼續維護它的專案 – mRemoteNG ,它不像其他類似的軟體會有 connection 數的上限或試用期之類的,繼續快樂的用了一陣子,這個版本雖然好用,但也是有一些小缺點,例如有時候按下 Alt+tab 鍵時無法順利切換視窗,偶而會莫名的 crash 等等 (1.73 Beta 1 很常掛)。

今天心血來潮去爬了一下 mRemoteNG 的論壇,竟發現有位老兄 (kaymer327) 留言說他已經另開 Github 專案去維護他自己的版本 – mRemote3G (大家喜歡改名字… 所以之前都沒 Google 到),而且到兩週前都還有更新,真是如獲至寶,目前試用的結果還算正常,原來的連線檔還是可以繼續使用,到目前也還沒 crash,VirusTotal 只有 360 掃出問題?! (HEUR/QVM03.0.Malware.Gen,我是選擇忽略 360 的結果,因為我都不把密碼存在 mRemoteNG 裡面的,哈哈)

整體看起來 UI 也改動了一點點配色的樣子,但還是一樣好用,有需要又不怕死的可以由上面連結去找嘍。

  • 2016/07/28 剛剛沒事又去逛了一下,沒想到 mRemote3G 又合併回去 mRemoteNG 了,在 Github 上可以找到最新的版本 1.75alpha,現在拿去 VirtualTotal 掃描,目前最新版的 mRemoteNG 已經都沒有病毒警告了(但之前的 mRemote3G 還是有一個?!),建議可以改用這版了

BIND 自 9.11.0 才會開始支援 EDNS Client Subnet

對 BIND (或 DNS) 稍有管理經驗的人,應該都知道 ACL 這個功能,他可以讓我們針對不同的 Resolver IP 回應不同的答案 (IP Address),所以諸如公司內網來查詢回內網IP,外網回 Internet IP 的設定,或特定來源 IP 回應特定的 IP ,甚至於 9.10 才開始加入的 geoip 功能,都是很好的 ACL 應用。

以往的使用者大多是會把 DNS Server 指到所屬的 ISP 提供的 DNS Server (大多數是不明不白的就用了 ISP 的 DNS Server),但是隨著越來越多的使用者用了 8.8.8.8 這個 Google DNS 當作第一選擇之後,之前我們使用 BIND + geoip 來做分流機制就不見得那麼準確了,加上 Google 又跑了 BGP,所以通常透過 Google DNS 來 query 的 IP 查出來都是屬於 – Mountain View, California, United States, North America,而非這些 IP 實際或相近的地理位置,導致於這個機制的運作效率越來越不好。

所幸 EDNS Client Subnet (ECS) 這個機制將要再 BIND 9.11.0 被支援了,雖然具體發佈的時間還不清楚,但至少讓人看到這問題被解決的曙光。有趣的是,從對岸網友那看來的消息是,這個 patch 早在 2014 年 8 月就已經 submit 進去了,所以有興趣玩的人也應該早就自己 patch 上去了。不過沒那個時間或自己沒能力 patch 的人還是等官方發佈比較妥當,免得到時候遇到非得更新不可的安全性問題時,還要自己生出 patch。

從 2014 年看到的 commit 說明裡,可以知道這個 ECS 支援會同時在 geoip 裡生效,也就是當你要使用 geoip 時,遇到有 ECS 的查詢時就會優先拿 ECS 來判斷而非來查詢的 DNS Server IP。所以,讓我們期待 9.11.0 的正式發佈吧。

  • 2016/06/27 更新,前幾天上去看,發現 BIND 的 9.11.0 已經出了 alpha 3 了,下載之後自己編譯了一下,看起來也可以正常的支援 EDNS + GeoIP,改天再來找個對外的 DNS 給弄上去,因為據說 Google 的 public DNS 早已經支援 EDNS 了,屆時 GeoDNS 的運作有效性相信又可以再回來了

HDD, SSD & RAMSAN

首先先來談談 RAMSAN 這個歷史產物好了。這間客戶應該是在多年前(七年以前)開始使用 RAMSAN 這個產品,遙想一下當年的歷史背景,HDD 不夠快,SSD 不成熟又貴 (可靠度應該不怎麼樣),所以就引進了 RAMSAN 這樣子的產品。真要認真分類的話,RAMSAN 應該算是 SSD 的一種,只是 SSD 是以 Flash memory 作為儲存空間,而 RAMSAN 則是以 RAM 作為儲存空間 (不過近年來他也有 SSD 的產品線,所以 RAMSAN 是專指 RAM 或 Flash 的 SSD Storage 要深究也沒什麼特別意義了,不過本文中提到的 RAMSAN 就專指這類用 RAM 堆起來的 SAN)。

一台典型的 RAMSAN 長得像這個樣子:

1

也許你有看到前面有四個硬碟插槽,不過那只是備份用的。一台 RAMSAN 的主要元件有:記憶體、電池 (鉛酸電池)、主機板、Power Supply 和 Fiber channel card。看到電池兩個字,大家可能就想到了,這個 RAMSAN 是要靠電池來維持安全的,身為一台昂貴且號稱是企業級應用的硬體,一旦斷電時,RAMSAN 就可以靠電池供電來把記憶體內的資料儲存當前面板的四台硬碟中,想當然爾,RAMSAN 開機時就會把這硬碟裡的資料寫回到記憶體裡頭。所以儘管是正常的開機關機,RAMSAN 所耗費的時間也要比一般的伺服器要來得長很多。

由於出品 RAMSAN 的這間 Texas Memory Systems 公司已於 2012 年被 IBM 併購,對 RAMSAN 這產品有進一步興趣的 (至少人家還有繼續在出 SSD 的機種),可以自己去 Google 看看。

稍微有點 IT 背景的人應該都知道,RAM 再怎麼慢還是比 Flash 快上一大截,那為何又說 RAMSAN 是個歷史的產物呢?讓我們先看一份資料:

Type HDD Mix HDD & SSD SAS SSD RAMSAN Flash SSD RAMSAN RAM SSD
Config 14 HDDsRAID 10 14 RAID 101 SAS SSD CacheCade 4 SLC SSDRAID 10 RamSan-720SLC RamSan 440DDR2
IOPS 5.5K IOPS 20.45K IOPS 76.27K IOPS 500K R/W IOPS 600K R/W IOPS
Capacity ~ ~ ~ 6-12TB 512GB (maximum)

猛一看,哇,RAMSAN 的 RAM 機種真是強大啊,IOPS 可以到 600K (600,000),用 4 個 SLC SSD 做 RAID 10 也才只能到 76.27K IOPS,用 14 顆硬碟去做 RAID 10 才只有 5.5K,真的是 xx 比雞腿,但仔細看一下他的容量,啥,最大只能到 512GB,有沒有搞錯?現在我連隨身硬碟也就已經是 1TB 起跳的年代了,512GB 是要拿來裝什麼。

沒錯,這就是他的致命傷了,你也不要小看他只有 512GB 的容量,他的身價可能要超過他的 SSD 同門小弟 – RAMSAN 720。這麼貴,容量又小,那唯一可以看的就是速度了吧?對,沒錯,就是速度上快了一截,但… 各位有幹過 DBA 的去 monitor 一下貴公司資料庫硬碟的  IOPS 看看好了,誰需要這麼快的速度?就連我們自己去監控客戶線上 RAMSAN 的速度,也離極限有很大的距離。

在當年那個 SSD 又貴又沒有可靠度的環境下,當 HDD 的速度跟不上的時候,用 RAMSAN 大概是個明智的抉擇,不過隨著 SSD 的不斷進步,價格不斷的下降,RAMSAN 這個原本就存活於利基市場的產品的市場就越來越小了。君不見連他自己現在都不產 RAM 做的 RAMSAN 了,就可以知道目前的的市場需求有多小了。

除了市場需求面太小之外,現在也跑出很多類似功能的的解決方案出來,例如 SQL Server 2014 的 In-Memory OLTP,或是 SAP HANA,更別說是現在的 Non-relational database 這種根本不同型態的資料庫應用,雖然都或少或多的需要針對應用系統進行修改,但從價格/效益比來看,只能說 RAMSAN 真是時代的眼淚了(至少 2015 年的現在看起來是這樣子)。