ref: https://lwn.net/Articles/853637/

如果對 SO_REUSEPORT 這個能夠提供網路服務吞吐量的 socket options 不陌生的話，那這篇文章強烈推薦看看。
本篇文章是從討論開啟 SO_REUSEPORT 這個選項會出現的一些行為以及可能可以怎麼做

最直得看的應該是留言區本身，有很多不同層級的討論，大家最愛講的 Google SRE 人也都出來分享自己的經驗了。

正常情況下，每個 TCP Port 只能被一個 process 給使用來聽取封包，但是對於一些網路重度使用的系統來說，就算讓該 process 將連線給分散到其他的 process 去處理，該 process 依然可能是系統的效能瓶頸。
Linux Kernel 3.9 後引入的 SO_REUSEPORT 參數就是為了解決這個效能問題而來的，這個參數允許多個 Process 同時使用一個 TCP Port，每當底層有一條新的連線請求時， Kernel 會從眾多的候選人之一中挑選一個可用來處理。
這種情況下，網路應用程式就可以專心處理連線工作，然後實務上同時執行多個 Process 即可。底層的 Kernel 會幫忙做連線的負載分配。

當眾多候選 process 其中之一掛掉了(可能是 crash，也有可能是有意的重啟)， kernel 會注意到這個候選人要說掰掰，這候選人處理的所有 connection 都會被移除，比較糟糕的是其他待在 Accept-Queue 那些還沒被建立連線的連線請求也會一併被移除。
作者認為 Kernel 應該要有能力可以轉移那些 Accept-queue 中的連線到其他還工作的候選 process 下去處理，這樣使用者/Client 的連線就不會需要處理太多重連的問題。

文章後面都在探討可行的做法以及這個問題可能會導致什麼問題。

留言區滿熱鬧的，譬如說
1. 有人認為 server 重啟的情況實在太少見，有需要為這麽少見的情況導入這麼複雜的修改到 Kernel 中?
a. 有人回答使用 Let's Encrypt 你可能每幾週就要重啟一次。
b. Google SRE 回答其內部因為調整設定的緣由，幾乎無時無刻都需要重啟服務，不過這問題已經從別的層級去處理掉，所以修改 Kernel 對他們的用途不太大。
2. 有人提出 Nginx 本身有 live migration 的功能，可以將 fd 給轉移到其他的 process 去處理。
a. 有人提出這邊談的是 socket/connection 的層級，這些東西都還沒發生到 userspace process 同時也不是 userspace 應用程式可以接觸處理的。
b. 本文探討的是 bind(), accept(), listen() 這類型 function call 之間 kernel 會幫忙做的事情。

有興趣的別忘了閱讀留言區

#NetDevOps

今天這篇文章是一個數據調查文，主要內容是探討基於 NetDevOps 的文化下，網路維運人員使用哪些工具來協助日常的網路工作。

這份 2020 的報告總共有 333 的投票者，總共有一個月的投票時間。
整個文章總共有 49 個表格，非常的多...
這邊就列舉幾個大家可能比較有興趣的表格來幫大家預覽，當然對於整體有興趣的人還是不要忘了點選全文瀏覽！

每個項目都列舉前六名，標準基於使用正式於生產環境的票數
感興趣或是已經使用的工具
1. Ansible
2. Grafana
3. Netbox
4. ELK
5. EVE-NG
6. Promethes

感興趣或是已經整合的主題
1. Source of Truth
2. Network Health Moniroting
3. IaC
4. DevOps
5. CI
6. CI/CD

使用何種解決方案來自動化處理設定檔案
1. Ansible
2. 內部開發工具
3. NAPALM
4. Nomir
5. Terraform
6. 網路供應商的自主工具

如何控管設定檔案的改變
1. VCS
2. Rancid/Oxidized
3. 內部開發工具
4. 網路供應商的自主工具
5. FTP/SCP/TFTP
6. Solarwind NCM

管理哪些網路廠商的設備
1. Cisco IOS/IOS XE/Viptela
2. Cisco NX-OS/ACI
3. Juniper
4. Cisco IOS XR
5. Cisco ASA
6. Palo Alto

使用何種工具來模擬虛擬網路設備或是功能驗證
1. GNS3
2. VMWare
3. EVE-NG
4. 網路供應商工具
5. Docker Compose
6. Vagrant

網通業者的生態與軟體業者是截然不同的，很多軟體業習慣的操作流程與直覺並不是這容易的直接套用到網通業者的環境中。
舉例來說，使用公有雲創建 VM 並且於 VM 叢集上搭建出一個初始的工作流程並不難，Kubernetes 套上去後，就可以用容器的方式把各種應用，譬如 Prometheus, Grafana, logging, tracing, message queue 等服務都搭建到各個伺服器上。
對於網通業者來說，今天掌管的目標是 Switch 跟少部分的 Server，光 Switch 要買哪一家就是一個問題。
Switch 不太像 X86 架構一樣，想換什麼 OS 就換什麼 OS 這麼輕鬆，不走 whitebox 的架構下，一旦採購了某家廠商的解決方案，有可能就終生是對方的形狀了。這也是很多人都在提倡希望透過標準化來避免 vendor lock-in 的狀況。
上述的報告也可以看到前六名管理的機器中有四名都來自 Cisco 的機器，這種情況下很多事情都會受限於 Cisco 機器本身的設定與狀況，並不是想要做什麼就做什麼。

為了讓這一切變得簡單，如果可以透過標準化的方式去定義 switch 的架構，讓這一切變得如操作 Server 般簡單時，網通業者就會有另外一種方法來管理環境。
如果相關的軟體都有開源專案可以使用，這樣維運人員就可以用更省錢的方式來安裝與控管這一切的網通設備，聽起來真的很棒
現實生活上則是，網路產業對於 uptime 的需求非常的強，一旦出問題不是單純服務不能連，而是可能影響數千數萬甚至更多的使用者。這種情況下如果團隊全部使用開源專案而沒有 SI 公司的支援與維護，誰敢冒這個險去使用這些呢

最後要說的是，隔行如隔山，永遠不要用自己習慣的工作流程去看待別的產業，很容易被打臉。

https://dgarros.github.io/netdevops-survey/reports/2020

WD_BLACK SN850 NVMe SSD 具備更優異的低佇列深度（queue-depth）效能，讓遊戲玩家和一般使用者都能更流暢地載入應用程式；為了打造極致美學並實現客製化，預計 2021 年年初會再推出配備 RGB 照明的散熱片版本。