FreeBSD 與 Linux 下強制重開...

現在人居然在辦公室... (苦哈哈)

遇到 process 用 kill -9 砍不掉時，不能用 reboot 重開，這會導致 reboot 卡死。如果機器很遠的話就很苦了...

在 FreeBSD 下，要遠端重開，要用 reboot -n -q，強迫系統跳過某些 sync procedure。在 Linux 下 (Debian 下) 則是用 reboot -n -f。

苦啊苦啊苦啊...

開始搬機器到新機房...

新機房的溫度：

舊機房搬了一批機器後「總算」降到這個溫度了：

繼續努力搬...

FreeBSD 下 lagg 在 /etc/rc.conf 的設定方式

如果在 FreeBSD 的 /etc/rc.conf 裡想要搞定 Link Aggregation (lagg) 的設定，主要是這幾條：

cloned_interfaces="lagg0"
ifconfig_igb0="up"
ifconfig_igb1="up"

ifconfig_lagg0="laggproto failover laggport igb0 laggport igb1 123.45.67.89/24"

如果要跑其他模式 (像是 LACP) 的話就把 failover 改成其他的選項就可以了...

用 tpcc-mysql 測試 LSI 的 Nytro MegaRAID NMR 8100-4i

先說結論，這是張不錯的 RAID + Flash 加速卡。

十一月初的時候合作的 SI 廠商丟信件來，問我們對 LSI 的 Nytro MegaRAID Application Acceleration Card 有沒有興趣。架構上就是本來的 RAID 卡加上 Flash Cache，原廠說可以快 10 倍。

我的慣例是先問價錢，價錢在可能的範圍才會測試。所以就請廠商提供價錢：(因為是建議售價，這邊就直接貼出來了)

8100-4i 100GB/s SSD 建議售價NT$62,900
8110-4i 200GB/s SSD 建議售價NT$93,900
8120-4i 800GB/s SSD 建議售價NT$239,000

看了看價錢覺得 8100-4i 與 8110-4i 應該還可以，就借 8100-4i 了。

測試的方法是以 MySQL 的 InnoDB 為主，可以參考「用 tpcc-mysql 測試 MySQL InnoDB 效能」這篇。

硬體設備是 Intel Xeon E5620*2 + 8GB RAM，用 8100-4i 接四顆 Seagate SAS 15KRPM 300GB 硬碟跑 RAID1+0。Flash 部分是兩顆 50GB SLC Flash，跑 RAID1 後掛到本來的 RAID1+0 加速。

軟體是 Ubuntu 12.10 (64bits)，MySQL 是跑 Percona Server 5.5，調成與 production 相同的 my.cnf。

首先是 W=100，測試資料 10GB 的情況：

• 有 Cache：
• 16 threads：5443.300 TpmC
• 32 threads：16247.400 TpmC
• 64 threads：21203.900 TpmC
• 128 threads：23206.100 TpmC
• 256 threads：20845.500 TpmC
• 沒有 Cache：
• 16 threads：1080.500 TpmC
• 32 threads：1434.100 TpmC
• 128 threads：1304.800 TpmC

再來是測 W=1000，測試資料 86GB 的情況：

• 有 Cache：
• 64 threads：800.367 TpmC
• 128 threads：1270.367 TpmC
• 256 threads：1053.467 TpmC
• 沒有 Cache：
• 64 threads：443.567 TpmC
• 128 threads：348.133 TpmC
• 256 threads 在最後 Stop threading 的地方一直跑不完，重跑三次都一樣。

第一個測的是資料量超過 RAM，但還沒超過 Flash 大小。第二個測的是資料量超過 Flash 大小的情況。

可以看出來當超過 RAM 時增加的效能很不錯。

用 tpcc-mysql 測試 MySQL InnoDB 效能

因為跟廠商借了張 NMR8100-4i 要測試效能，而這張有兩個 50GB 的 SLC NAND Flash，想要跑看看如果拿來給 database 用的效能如何。

TPC-C 是用來模擬線上交易服務所產生的資料庫 query 藉以測試效能 (另外還有 TPC-E 與 TPC-H 是測試不同面向)。而 tpcc-mysql 則是 Percona 維護的 open source 專案，專門拿來測試 MySQL 的效能，面向則是跟 TPC-C 接近。

所以就決定拿 tpcc-mysql 來當測試工具 (因為 Percona 的關係)。

建議第一次玩的人可以在 AWS EC2 上開一台 Ubuntu server 玩看看，反正爛掉可以重來，不用太擔心要還原...

首先先安裝 bzr 與 build-essential 以及 libmysqlclient-dev，然後將 source code checkout 下來：

# apt-get install bzr build-essential libmysqlclient-dev# cd /tmp# bzr branch lp:~percona-dev/perconatools/tpcc-mysql

checkout 後要先上這個 bug report 裡面提供的 patch，雖然標題是 9.04 64bits，但在 12.04 64bits 下還是沒修正：「tpcc_start core dump on Ubuntu 9.04 64bit」。

修正完成後直接編就可以了：

# cd src# make

接下來的東西可以看 README 裡的說明。

首先先建立 database (我取 tpcc1000)，然後再把 create_table.sql 與 add_fkey_idx.sql 倒進去。

然後用 tpcc_load 產生資料塞進資料庫：

# ./tpcc_load 127.0.0.1:3306 tpcc1000 root rootpassword 1000

上面這是單一 process 在塞，可以考慮用 load.sh 同步塞 (速度快很多，不過 script 寫死用 root 塞，密碼是空的，你可以自己改裡面的內容)：

# ./load.sh tpcc1000 1000

我自己測試發現 W=100 約 10GB 資料，W=1000 約 86GB 資料。測試的時候要注意有沒有超過 memory size。通常是 fit memory 測一次，over memory 再測一次。我的例子是測 fit flash size 一次，over flash size 一次。

第一次倒測試資料進去的時候，我通常會先調整 my.cnf，讓他不要每次 flush to disk，這樣寫入速度會快很多。

雖然說快很多，W=1000 的情況下我也跑了八個小時 I/O bound 才產生出 86GB 資料。

倒完資料後要把 my.cnf 改成要測試的設定，然後重跑 mysqld，接著跑 tpcc_start 實際測試：

# ./tpcc_start -h127.0.0.1 -P3306 -dtpcc1000 -uroot -prootpassword -w1000 -c32 -r 60 -l3600

上面的 -c 是 thread 數量，-r 是 warmup 時間，-l 則是測試的時間。這個例子裡會 warmup 60 秒，再加上 3600 秒的測試 (一小時)。

最後他會給你 TpmC 數字，這數字愈大表示效能愈好。

大致上就是這樣，話說回來，NMR8100-4i 這張卡帶來的效能不錯耶...

一個晚上，把該踩的地雷都踩完了...

大概吧... 不知道還有多少地雷要踩 :o

弄 OpenVPN，直接把踩到的地雷列一下：

• FreeBSD 上用 pf 不能直接對 interface 開放，因為 OpenVPN 可能會在 pf 都跑完後才跑起來。查資料的時候有找到資料說，可以讓 pf 不要 cache 這部份，不過測了老半天測不出來，最後還是用 IP range 來做。
• OpenVPN 2.2 已經改成一個 interface 通殺所有 client，而不是一個 client 一個 interface，測了老半天發現是誤會一場，manpage 裡有寫現在變成這樣。(不知道從哪個版本變成這樣，至少裝的 2.2 是...)
• 如果 dhcp-option 只推 dhcp-option DNS 而沒有推 dhcp-option DOMAIN，Ubuntu 下的 DNS 設定不會生效，據說是 spec feature... +_+
• 如果要吃 RADIUS，可以透過 PAM 處理。不過 pam.d 的設定檔內只能用 try_first_pass，不能用 use_first_pass，原因看一下 FreeBSD 的 pam_radius manpage，裡面有說明。
• 另外，如果要用 RADIUS，記得設定 template_user 避免有 local account 的人會過，沒有 local account 的人就掛了...。

暫時踩到這些...

用 Percona Xtrabackup 複製資料給 slave 用

在幾乎都是 InnoDB table 的環境下，可以用 Percona Xtrabackup 產生出一份完整的資料，提供給 MySQL Slave 用。主要是參考這兩份文件：

• Making a Full Backup
• How to setup a slave for replication in 6 simple steps with Xtrabackup

我安裝 Percona Xtrabackup 是透過 apt-get，如果要用其他安裝方式也可以，這邊就不提了。

跑法是先在 master 機器上跑 innobackupex：(要記得 /data 下得有足夠的空間放檔案)

# innobackupex /data/db/
# innobackupex --apply-log /data/db/xxx/

其中第二個指令中的 xxx 是 innobackupex 產生的目錄。
等這些指令跑完後，就可以把整個目錄複製到別台使用，在 xtrabackup_binlog_info 裡面有 master 的 binlog 資訊可以讓你設定。

其中比較要注意的地方是不能加上 --compress，因為 --apply-log + --compress 會失敗，這個問題在 Percona Xtrabackup 的 Launchpad 上有看到有 ticket 在處理了。

XtraBackup 2.0.1

Percona 更新了 XtraBackup：「Announcing Percona XtraBackup 2.0.1」。

對於使用 Percona XtraDB Cluster (Galera Cluster) 的人，幾乎都應該設定 XtraBackup 為 full resync 工具。在 resync 過程中才不對讓提供資料的 server 停止服務 (如果用 rsync 當 resync 工具，會停止服務)。

這個版本修正了一個之前遇到的問題：當單檔超過 8GB 的時候會爛掉。

之前的解法是自己用 bzr 把 2.0 branch 拉下來編一個 xtrabackup-5.5 出來用 (我遇到的時候其他人也已經遇到了，patch 也已經進 branch 2.0 了)，現在只要 apt-get 裝起來就可以了...

在 Mac 上的 DNS split tunnel

不論是 Cisco ASA 的 IPSec client，還是 Juniper SA SSLVPN 連線，在 Mac 上遇到 DNS split tunnel 設定時都不太正常，常常會不吃 VPN 給的 DNS 設定。

剛剛在網路發現「Split Tunnel DNS or per domain DNS」這篇方法，測了一下至少是有用的？算是一個方向...

先在 /etc 下建立 resolver 目錄，然後把公司的 DNS 設定丟進去，看起來就 okay 了？

利用 ifconfig 的結果，產生每個 IP address 所屬的 interface

為了把 Heartbeat 設定檔弄進 local ports system 內，需要知道這是哪台機器，寫完之後才發現這個問題可以抓 hostname 解決... 還是把這次用 awk 的一些事情記錄下來吧 :o

用 Perl 當然是好做很多，但還是想用 awk 包，之後遇到的問題會比較少 (其中一個原因是因為 FreeBSD 剛裝好的時候系統內沒有 Perl，如果之後要重複使用這個功能，用 awk 寫比較方便)。

ifconfig 輸出的結果像是這樣：

lo0: flags=8049 metric 0 mtu 16384
        options=3
        inet 127.0.0.1 netmask 0xff000000
        inet6 ::1 prefixlen 128
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x7
        nd6 options=3

因為 awk 是一行一行讀 (回頭讀的話比較麻煩)，而我只打算抓出 IPv4 (包括 IP alias) 的部分，所以想法是用一個暫存變數 INTERFACE 來放最近一次的 interface 名稱。

其中用到 match() 會將抓到的部分放入 RSTART (放 offset) 與 RLENGTH (放長度) 的特性：

ifconfig -a | awk '{
  if (match($0, "^[0-9A-Za-z]+:")) {
    INTERFACE = substr($0, RSTART, RLENGTH - 1);
  } else if (match($0, "inet [0-9]+\.[0-9]+\.[0-9]+\.[0-9]+")) {
    print INTERFACE, substr($0, RSTART + 5, RLENGTH - 5);
  }
}'

可能還有些地方可以再修的有彈性一點，不過上面這段 code 在目前的 FreeBSD 應該都能跑，可以預期的是抓 interface 的部分如果遇到帶底線的名稱就會掛 :P

用 pt-duplicate-key-checker 檢查是否有沒有用到的 key

pt-duplicate-key-checker 是 Percona Toolkit 裡面一個還蠻簡單實用的功能，第一次用請只指定 DSN 就好，看看輸出內容：

pt-duplicate-key-checker --charset utf8 h=db-test-float-1,u=username,p=password

你應該會看到一堆 ALTER TABLE 以及 DROP INDEX 的指令。如果沒有的話代表你的資料庫沒有顯而易見的 INDEX 問題。

如果沒有問題，就把這串指令 pipe 給 mysql 執行：

pt-duplicate-key-checker ... | mysql -h db-test-float-1 -u username -p

然後輸入密碼。

值得一提的是，我測試過的環境中，InnoDB 的 DROP INDEX 行為都是瞬間做完，但我不確定是否有特別的設定。我測試的環境有些特點：

• 都是在 Percona XtraDB Cluster 上測試 (目前是 5.5.24-55)。
• innodb_file_format = Barracuda
• innodb_file_per_table
• innodb_support_xa = FALSE
• 所有的 InnoDB table 都是 COMPRESSED 格式。

如果不能停機，最好是先建立測試環境 (像是 AWS EC2) 測試過後再做。

用 pt-online-schema-change 改變 InnoDB table

由於 InnoDB 的設計，ALTER TABLE 時有可能會導致其他的表格也卡住 (MyISAM 就可以確定只會卡住當事人當事表格)，所以還是用其他方式處理。

遇到有支援 transaction 的資料庫，作法是建立新的表格，然後在舊的表格上面設定 trigger 確保寫入舊的表格也會更新到新表格，接下來把舊的表格複製到新的。

在 Percona Toolkit 內，有 pt-online-schema-change 這個工具幫你做完這些事情。

用法是：

pt-online-schema-change --charset utf8 --alter 'ADD COLUMN xxx INT NOT NULL DEFAULT 0' h=db-test-float-1,u=username,p=password,D=database,t=table

或是多加上 --chunk-index 指定要使用某個 index 當作切割條件 (當 pt-online-schema-change 抓到複合欄位 index 時會產生錯誤，這時候要自己指定單一欄位的 index)：

pt-online-schema-change --charset utf8 --chunk-index=index_name --alter 'ADD COLUMN xxx INT NOT NULL DEFAULT 0' h=db-test-float-1,u=username,p=password,D=database,t=table

相當好用的工具...

Cisco 3750G 的 LACP 不夠平均的解法

並不是每個環境都是使用這個解法，在我目前遇到的情況，用：

# port-channel load-balance src-dst-ip

就可以平均一些。

使用的環境是 F5 BIG-IP LTM 需要往後端 server 取得大量資料，然後在 MRTG 圖上發現中間經過某兩條用 LACP 綁在一起的流量不夠平均。

印象中跟 hash algorithm 或是 balance algorithm 有關，用這些當關鍵字找了一些資料，發現預設是使用 MAC address 計算，而在我們的環境裡，F5 與 server 的 MAC address 都是固定的，於是就極端不平均...

目前的解法是讓 F5 有多個 IP address 往後端 server 連線，再透過上面的指令要求 3750G 去看 IPv4 封包內的 IP address 去計算，測試的結果算是讓人滿意了...

如果需要知道更完整的說明，可以參考 Cisco 網站上「Understanding EtherChannel Load Balancing and Redundancy on Catalyst Switches」這篇文章。

用 pt-find 加熱 (暖機) InnoDB table

這是老問題了，以前自己寫 script 做，現在可以用 pt-find 加上 SELECT COUNT(*) 設成 alias 做：(這邊是 bash alias)

alias warmup="pt-find --engine InnoDB --exec 'SELECT COUNT(*) FROM %D.%N;' --print"

用法是：

warmup -h DBHOST -u USER -p PASSWORD

這樣一來，雖然沒有把所有的 data & index 都讀進來，但這樣已經可以稍微減緩 InnoDB 的暖機問題。

Unbound + DNSSEC

FreeBSD 上要 Unbound 啟用 DNSSEC 很簡單，安裝完後，先跑 sudo -u unbound unbound-anchor 產生 root.key，之後每次重開機都會檢查是否需要更新。

再來是在 unbound.conf 裡面的 server 區段增加：

server:
        auto-trust-anchor-file: "/usr/local/etc/unbound/root.key"

如果有自己的 domain，可以先用 domain-insecure 設定，讓 Unbound 不檢查這些 domain：

server:
        domain-insecure: "mycompany"

Perl 的 regular exprssion 可以用 (?...) 設定參數

我遇到的問題很簡單，就是這樣的 code：

say 'yes' if 'Test' =~ $a;

我想要在 $a 做出 'Test' =~ /test/i; 的效果，也就是找方法帶 modifier 進去。

第一個想到的方法是用 eval() 做：eval("'Test' =~ $a;")，但這個方法問題很多... 因為我的 $a 是從設定檔讀進來，我並不希望給予奇怪的權限。

在 Perl 裡可以用 inline modifier 解決，也就是把 regular exprssion 前面加上 (?i)，其中 i 就是 modifier，變成 (?i)^test。

對於其他用 perl 寫的程式也可以這樣設定 regular exprssion，另外 PCRE 也可以吃，所以 Postfix 設定時如果用 pcre:$configuration_directory/xxx 也可以這樣設定 (regexp:... 就不確定了)。

Cisco IPSec VPN Client 在 Windows 與 Mac 上遇到的問題

Windows (XP & 7) 與 Mac 上面都各遇到一個不太能解的問題，找國外的論壇發現不少人抱怨原廠都不修正... Anyway，還是有些很笨的方式可以繞過去。

Windows 上遇到的問題是，如果 ASA 上面有設定 split-dns，那麼 Windows 除了 split-dns 所設定的網域可以查到資料，其他的網域都會無法查詢 (不會丟出任何 DNS query)。這不是 client 軟體的問題，而是作業系統內的問題，微軟目前看起來沒打算處理。

Mac 上遇到的問題是，Mac 系統內建的 Cisco VPN client 不吃 ASA 丟出來的 DNS server。不過在 Mac 上可以吃 split-dns...

目前用的解法是設定兩個不同的 tunnel-group，一個給 Mac 用，另一個給 non-Mac 用，大家各連各的，吃不一樣的設定值避開問題。

FreeBSD NIS master 與 Linux NIS client 時 shadow 的處理

剛剛 gaod 發現 Linux 的機器無法用帳號密碼登入 (因為我一直都是用 key 直接登入，所以一直沒發現)，花了不少力氣才抓出要怎麼解，用 Google 找了不少文件，好像沒什麼人遇到？

解法是把 FreeBSD 上 NIS/YP server 的 Makefile 裡面產生 passwd 的 * 部份改成 x 就解決了。可以參考「Re: FreeBSD NIS serving linux clients.」這篇十年前文章的說明...

會產生問題是因為 Linux 上的 NIS code 在看到 passwd 密碼欄位是 * 時就不會去 shadow 要資料，然後就爆炸了... 改成 x 就沒問題了...

AWS SES 與 Postfix 的配合...

官方論壇上面沒找到比較好的方法，於是 trace ses-send-email.pl 之後找到一些方法可以用。

在 ses-send-email.pl 寫的 helper 中，規定寄給多個使用者必須使用「逗號」隔開：

ses-send-email.pl [--help] [-e URL] [-k FILE] [--verbose] -r [-f FROM_EMAIL] [TO_EMAIL[,TO_EMAIL]...]

但實際 trace 後可以發現除了逗號外也可以接受空白，但是必須在「一個參數」內 (Perl 會用 regex 切開)，但是 Postfix 所丟出來的 $recipient 會是多個參數，而且無法調整 quote，所以得用一個 shell script 將傳入參數包起來：

#!/bin/sh
SENDER="$1"
shift
/usr/local/bin/ses-send-email.pl -k /usr/local/etc/aws_creditentials -r -f "$SENDER" "$*"

再來是修正 Postfix 的 master.cf，改吃 shell script：

awsses     unix  -       n       n       -       1       pipe    flags=RX user=www argv=/usr/local/bin/awsses-wrapper.sh $sender $recipient

這樣在寄給多個使用者的時候才會正常...

Postfix 的 policy daemon...

沒注意好 Postfix 的 policy daemon 傳回的值，居然變成 open relay 了...

依照「Postfix SMTP server access table」的說明，現在沒辦法決定而要往後面的條件判斷時，需要丟出 DUNNO，而非 OK，一時間沒注意就變成 open relay...。

接下要看被誰列入 DNSBL 了...