Tag: server

ptt.cc 偶而會解不出 IP 的問題

Update：感謝正妹 wens 幫忙，現在已經先上 workaround 了，狀況暫時解除...

最近發現 168.95.1.1 有時會找不到 ptt.cc 這個 domain (參考 gist:9995821)，原因是 ptt.cc 在 whois 上登記的是：

Name Server: NS0.PTT.CC
Name Server: NS1.PTT.CC
Name Server: NSOUT1.PTT.CC

用 dig 對 cc 的 NS server 查詢也可以確認：

;; AUTHORITY SECTION:
ptt.cc.                 172800  IN      NS      ns0.ptt.cc.
ptt.cc.                 172800  IN      NS      ns1.ptt.cc.
ptt.cc.                 172800  IN      NS      nsout1.ptt.cc.

;; ADDITIONAL SECTION:
ns1.ptt.cc.             172800  IN      A       140.112.172.10
ns0.ptt.cc.             172800  IN      A       140.112.172.16
nsout1.ptt.cc.          172800  IN      A       112.121.80.227

但 ptt.cc 的三台 NS server 上都找不到 nsout1.ptt.cc：

; <<>> DiG 9.8.1-P1 <<>> nsout1.ptt.cc @140.112.172.10

;; AUTHORITY SECTION:
ptt.cc.                 300     IN      SOA     ns0.ptt.cc. contact.ptt.cc. 2013102501 3600 900 2419200 3600
; <<>> DiG 9.8.1-P1 <<>> nsout1.ptt.cc @140.112.172.16

;; AUTHORITY SECTION:
ptt.cc.                 300     IN      SOA     ns0.ptt.cc. contact.ptt.cc. 2013102501 3600 900 2419200 3600
; <<>> DiG 9.8.1-P1 <<>> nsout1.ptt.cc @112.121.80.227

;; AUTHORITY SECTION:
ptt.cc.                 300     IN      SOA     ns0.ptt.cc. contact.ptt.cc. 2013102501 3600 900 2419200 3600

於是就錯亂了...

可以先解決的方法是先把 nsout1.ptt.cc 加上去，然後再規劃要怎麼修改兩邊的 record (Ptt 這側的 A/NS record，與 cc 的 A/NS record)。

補充一下，ptt2.cc 也有同樣問題。

Percona 的 TokuDB

Percona 這幾個月對 TokuDB 的評價一直都很不錯，再加上在 Percona Server 5.6.16-64.0 裡加入對 TokuDB 的支援 (目前還是掛在 ALPHA 階段)，看起來是打算再納入這個產品線？：「Percona Server 5.6.16-64.0 with TokuDB engine now available」。

與兩年前的 Percona XtraDB Cluster 情境有點像，看起來會是新的主打產品？

先花了一些查，發現「How TokuDB Fractal TreeTM Indexes Work」這份投影片整理的還不錯，說明了簡化版 fractal tree 的結構，以及為什麼可以取代 B-tree 或 B+tree。也說明了 fractal tree 最重要的精神是拿 CPU 計算能力與 memory bandwidth 換取資料結構的特性，善用磁碟在 sequence i/o 遠比 random i/o 快的事實。

維基百科裡的「TokuDB」也寫了一些東西可以看，像是說明 fractal tree 是 cache-oblivious algorithm，這點讓 cache tuning 的複雜性降低。

這樣應該順便玩看看 Docker 或是 Vagrant 才對？

AWS ELB 加強安全性...

AWS ELB 加強對 SSL 安全性的功能：「Elastic Load Balancing – Perfect Forward Secrecy and Other Security Enhancements」。

第一個是支援 PFS (Perfect Forward Secrecy)，愈大多數的實做相同，是使用 ECDH。

第二個是 Server Order Preference，由 server 這邊決定最終的 cipher。

最重要的是第三個，也就是「懶人包」。推出新的 security policy ELBSecurityPolicy-2014-01，把上面兩個都設進去了。

這次的升級是對安全性的提昇...

NTP server 放大攻擊的防治...

一樣是在 Zite 上看到的，有人提到對 NTP server 的放大攻擊：「Re: Public ntp-server and reflection-attacks」。

攻擊者送一個封包，就會產生約 100 個封包的回應... (於是就被放大了)

This means, the attacker sends _one_ packet and gets _100_ packets to his target.

像是這樣的指令就會傳回很多資訊：(剛好也學到 ntpdc 這個指令...)

gslin@colo-p [~] [04:18/W4] ntpdc -c monlist
remote address          port local address      count m ver code avgint  lstint
===============================================================================
localhost              36284 ::1               443425 7 2      0     27       0
sun.stu.edu.tw           123 112.121.80.241      7891 4 4      0   1027     197
clock.stdtime.gov.tw     123 112.121.80.241      7821 4 4      0   1024     838
59-124-196-84.HINET-IP   123 112.121.80.241      7856 4 4      0   1024     920

在信件裡，建議的修正方式是：

restrict default noquery nomodify notrap nopeer
restrict -6 default noquery nomodify notrap nopeer

Stack Overflow 的現況...

Update：2016 年的架構可以在「Stack Overflow 公開 2016 的架構」這邊看到。

Stack Overflow 的 Nick Craver 貼出目前 Stack Overflow 的現況：「What it takes to run Stack Overflow」。

公開出來的資料不包括 CDN 的部份，可以看出整個架構很精簡啊... 然後還貼出機房照片：

可以看出很多機器都很大台，尤其是 RAM 的部份。而資料庫主機則是 384GB RAM + 1.8TB SSD...

資料庫的讀寫比是 40% read + 60% write，應該是 cache 擋下非常大的讀取量？

然後有一句粗體字：

The cost of inefficient code can be higher than you think.

這句話... XD

Percona Server 第一個 5.6 上 GA 版本...

Update：Percona 自己也寫了一篇「A closer look at Percona Server 5.6」可以參考看看。

Percona 推出 Percona Server 5.6.13-61.0，是 5.6 的第一個 GA 版本：「Percona Server 5.6.13-61.0 first GA release is now available」。

這等好久了，MySQL 官方有給出「What's New in MySQL 5.6」，對我來說其中有幾個亮點需要測試：

效能

至少不能比現在的效能差。

對 memcache protocol 的支援

這是 5.6 的新功能，可以透過 memcache protocol 存取 InnoDB 的資料。如果可行，可以用在 HA memcache protocol 架構。

Time-Delayed Replication

看起來應該很有用，但一時間想不到可以用在哪裡... 應該是 vm 裡面多架幾台 slave 丟著？

Percona 版的修正

Twitter branch 的 Statement Timeout 看起來是個頗有趣的項目？可以想看看用在哪裡...

Overall...

總結來說，測試機測過後，先用在 DBRD + Heartbeat 的系統上 (只換一台，如果發現 5.6 版不好用，可以 downgrade)，如果沒問題就再測試 memcache protocol，然後接下來就是等 Percona XtraDB Cluster 也出 5.6 版？

用 Percona Xtrabackup 產生 Slave Server 的方式...

快四年前寫過「XtraBackup：線上備份 InnoDB 的好東西」這篇，但裡面的方法已經不能用了，所以再寫一篇給 Google，之後查資料比較方便...

現在可以參考 Percona 的官方文件「How to setup a slave for replication in 6 simple steps with Xtrabackup」。

先跑一次 full backup：

innobackupex --user=yourDBuser --password=MaGiCiGaM --slave-info /path/to/backupdir

再跑 apply log：(其中的變數自己換掉)

innobackupex --apply-log --use-memory=2G /path/to/backupdir/$TIMESTAMP/

然後整個目錄丟到 slave server 上，用 CHANGE MASTER TO 指令把 master 資訊設好即可 :p

Percona 的 MySQL 5.6...

剛剛看到 Percona 放出第三個基於 MySQL 5.6 的版本了，仍然是 alpha 等級 (還在測試階段)：「Announcing Percona Server for MySQL 5.6.10-60.2」。

這也是 MySQL 5.6 進入 GA 後 Percona 推出的第一個版本，而且剛剛看 Percona 的文件網站也發現建出來了：「Percona Server 5.6 - Documentation」。

Percona XtraDB Cluster 目前還是基於 5.5 的版本，不知道 Codership (Galera Cluster 的開發公司) 有沒有打算換新...

ARM Server 與 Intel Server 的比較...

在「ARM Based Server Cluster Benchmarked」看到有人對 ARM 與 Intel 的 x86 (x86_64) 架構比較。原文在「Calxeda's ARM server tested」，ARM 的部份是以 Calxedas 的 server 測試。

重點其實在第 13 頁：

So on the one hand, no, the current Calxeda servers are no Intel Xeon killers (yet). However, we feel that the Calxeda's ECX-1000 server node is revolutionary technology. When we ran 16 VMs (instead of 24), the dual low power Xeon was capable of achieving the same performance per VM as the Calxeda server nodes. That this 24 node system could offer 50% more throughput at 10% lower power than one of the best Xeon machines available was honestly surprising to us.

雖然知道 ARM 的單位能量所產生的效能比較好，但比我想像中少... 我以為同樣電力會到兩倍。如果只有 50%+ 的話，也難怪各家都還在評估，而非大力換掉 :o