作者： 白翼

阿里雲故障公告：https://www.alibabacloud.com/zh/notice/repair1218

一般來說，一個地域的一個可用區故障不可怕，然而阿里雲本次香港 C 區帶來的後果卻更像一個地域故障。中控基本不可用，自己在 C 區的 ECS 資源經過了 10+ 小時未恢復。多家報障的大型客戶理應有多可用區的設定，卻也未能恢復服務。實在是令人質疑阿里雲的多可用區設計。

更新：事後複盤報告 – https://www.alibabacloud.com/zh/notice/066572


-- .zshrc
DISPLAY=1 SSH_ASKPASS="readfrom1p.sh" ssh-add private_ssh.key < /dev/null


-- readfrom1p.sh
op read "op://Personal/private key/password"


--
Just like that, filling in secrets on Terminl is now one Touch ID away.

Ref:
https://developer.1password.com/docs/cli/secret-references/
https://unix.stackexchange.com/a/571744

久違的看了一眼服務器的監控圖表，發現連接數異常的多（對比網站流量來說），奇怪的打開了 netstat / tcpdump，一臉 SYN_RECV。

雖然不至於造成 SYN FLOOD，直接把來源 IP 段 BAN 了了事。（然後換成一堆 AWS 的 IP 段發過來了，好傢伙…）

新部署：

iptables -A INPUT -p tcp --dport 80 -m state --state NEW -m recent --update --seconds {value} --hitcount {value} --name "syn-fw" -j DROP
iptables -A INPUT -p tcp --dport 80 -m state --state NEW -m recent --set --name "syn-fw"
iptables -A INPUT -p tcp --dport 80 -m state --state NEW -m recent --update --seconds {value} --hitcount {value} --name "syn-fw" -j LOG --log-prefix "[syn-fw] " --log-level 4


Refs:
https://serverfault.com/a/1033162
http://www.snowman.net/projects/ipt_recent/


Bonus：Fail2ban filter


[INCLUDES]
before = common.conf

[Definition]
_daemon = kernel
failregex = ^%(__prefix_line)s\[syn-fw\].*SRC=<HOST> DST=.*$
ignoreregex =

# nginx -V
nginx version: nginx/1.21.3
built by gcc 4.8.5 20150623 (Red Hat 4.8.5-44) (GCC)
built with OpenSSL 3.0.0 7 sep 2021
TLS SNI support enabled
configure arguments: --with-openssl=.../openssl-3.0.0 --with-openssl-opt='enable-ec_nistp_64_gcc_128 enable-tls1_3'

Took such a long time to compile though… 😅

早就應該給伺服器的數據庫備份加密了，現在終於加上了。

Should have encrypted the database backup already, finally changed it.

[crontab time] /usr/bin/tar czf - -C /etc/nginx . | /usr/local/bin/openssl enc -aes-256-cbc -pbkdf2 -k [password] > /backup/nginx.tar.gz.enc

[crontab time] /usr/bin/mysqldump -u root --all-databases | /usr/local/bin/openssl enc -aes-256-cbc -pbkdf2 -k [password] > /backup/all-databases.sql.enc

根據阿里雲官方塊存儲性能測試步驟（https://www.alibabacloud.com/help/zh/doc-detail/147897.htm）。

系統：Alibaba Cloud Linux 3
實例：ecs.t6-c1m1.large
地域：新加坡

高效雲盤 50 GB：（理論 2200 IOPS）

隨機寫 IOPS： Jobs: 1 (f=1): [w(1)][100.0%][w=8768KiB/s][w=2192 IOPS][eta 00m:00s]
隨機讀 IOPS： Jobs: 1 (f=0): [f(1)][100.0%][r=8668KiB/s][r=2167 IOPS][eta 00m:00s]
順序寫吞吐量：Jobs: 1 (f=1): [W(1)][100.0%][w=106MiB/s][w=106 IOPS][eta 00m:00s]
順序讀吞吐量：Jobs: 1 (f=1): [R(1)][100.0%][r=96.0MiB/s][r=96 IOPS][eta 00m:00s]
隨機寫時延： Jobs: 1 (f=1): [w(1)][100.0%][w=8908KiB/s][w=2227 IOPS][eta 00m:00s]
隨機讀時延： Jobs: 1 (f=1): [r(1)][100.0%][r=8816KiB/s][r=2204 IOPS][eta 00m:00s]

SSD 雲盤 50 GB：（理論 3300 IOPS）

隨機寫 IOPS： Jobs: 1 (f=1): [w(1)][100.0%][w=13.0MiB/s][w=3336 IOPS][eta 00m:00s]
隨機讀 IOPS： Jobs: 1 (f=1): [r(1)][100.0%][r=13.0MiB/s][r=3336 IOPS][eta 00m:00s]
順序寫吞吐量：Jobs: 1 (f=1): [W(1)][100.0%][w=105MiB/s][w=105 IOPS][eta 00m:00s]
順序讀吞吐量：Jobs: 1 (f=1): [R(1)][100.0%][r=97.1MiB/s][r=97 IOPS][eta 00m:00s]
隨機寫時延： Jobs: 1 (f=1): [w(1)][100.0%][w=13.0MiB/s][w=3333 IOPS][eta 00m:00s]
隨機讀時延： Jobs: 1 (f=1): [r(1)][100.0%][r=13.0MiB/s][r=3336 IOPS][eta 00m:00s]

I created an Alibaba Cloud Anycast EIP to see how big of an improvement it can have compared to my Singapore EIP. It is impressive to see how it has a negative impact on the global latency department.

* Test result only applies to today at this moment. Origin server (SLB) in Singapore.

Anycast EIP

Using their own benchmark method from Tokyo server: (https://www.alibabacloud.com/help/doc-detail/171864.htm#title-mk4-1or-ni4)

# curl -o /dev/null -s -w "time_connect: %{time_connect}\ntime_starttransfer: %{time_starttransfer}\ntime_total: %{time_total}\n" "Anycast EIP"
time_connect: 0.081
time_starttransfer: 0.167
time_total: 0.167

Normal Singapore EIP

# curl -o /dev/null -s -w "time_connect: %{time_connect}\ntime_starttransfer: %{time_starttransfer}\ntime_total: %{time_total}\n" "Singapore EIP"
time_connect: 0.076
time_starttransfer: 0.152
time_total: 0.153