?

??????

原文：

從未使用過 NAS 的人。

幾個月前，我終于決定給自己建一個 NAS。 促使我這么做的有幾個不同的因素：

于是，在命運的安排下，我開始了工作。

硬件

我可能有點沉迷于購買二手硬件。 有鑒于此，再加上我對 抱著 "我能做得更好 "的態度，我當然不會購買昂貴的新硬件。 盡管如此，我也不想買不可靠的東西，所以我最終在 Kijiji 上花50加元1買了一臺 HP 705 G3。

它配備了 AMD 通用預 Ryzen 四核 APU、8GB 內存和通用 500GB 旋轉硬盤。 它有三個 SATA 端口，比我的需求少。 因此，我又買了一些內存、三個用于 NAS 實際存儲部分的 Crucial MX500 1TB SSD 和一個 PCIe SATA 卡，以便插入更多硬盤。

總之，我的全部費用約為 320 加元，包括存儲費用。 我覺得還不錯吧？

你可能想知道，3 TB 的原始容量是否就是我 NAS 的全部容量。 我的回答是：是的！ 我的存儲空間并不大，所以我對此并不在意--我甚至從來沒有在我的所有設備上裝滿過 1TB 的容量。 不過，如果我需要更多容量，PCIe SATA 卡上還有幾個端口可以使用。 在最壞的情況下，即使這樣也不夠，我會屈服并購買存儲 10TB 或更大容量的真正 NAS 硬盤，將其用作電腦的啟動盤。 你總是可以使用更多的固態硬盤。 這也是我選擇固態硬盤而非硬盤的原因--每塊硬盤的差價約為 10 美元，而且如果有必要，我也無法將這些硬盤用作啟動盤。

軟件嘗試1[失敗]

為了追求與 一樣的實用性，我一直在尋找類似的軟件解決方案，安裝后就能正常使用。 我遇到了 iX Systems 的 TrueNAS，它基本上就是這樣的軟件。 好極了！ 我按照說明進行了設置，然后......重啟電腦后發現自己其實沒有網絡。

我現在是滑鐵盧大學的學生，住在校園里，結果發現我房間里的以太網插頭壞了。 幾個月來我一直沒有意識到這一點，因為我的所有其他設備（包括臺式電腦）都是通過 WiFi 連接到互聯網的，它既可靠又快速，所以我從來沒覺得要安裝以太網。

哦，好吧。 用 WiFi 不就行了嗎？ 事實證明，TrueNAS 的官方文檔中沒有任何地方提到 WiFi，TrueNAS 論壇和 Reddit 上的社區線程要么會與你爭論你的使用案例無效，要么會告訴你不支持 WiFi，卻沒有任何證據支持。

很好。 看來，即使支持這個功能，也會很麻煩。 我就不麻煩了。 相反，我使用 USB 網絡連接設置了我的 NAS，并向 IT 部門提交了一張修復以太網端口的單子。

?作為設置的一部分，我嘗試在它上面安裝 ，就像在我所有的設備上一樣。 由于大學的 WiFi 是與全校學生和教職員工共享的，他們不允許設備通過局域網相互通信。 因此，如果我想讓我的設備能夠與我的 NAS 通信（或相互通信），我需要以其他方式將它們連接起來，而 是我所知道的最方便的方式。 自從 2021 年在他們公司實習以來，我一直在使用他們的產品，他們從未讓我失望過。

由于我使用的是基于 Debian 的 TrueNAS Scale，我本以為只需添加 的 PPA 并用 sudo apt 安裝就可以了。 但 iX 因為有太多人在 Linux 系統內亂搞，然后抱怨，所以他們禁用了 shell 中的 apt，并明確表示不支持通過 shell 對系統進行任何修改。

解決這個問題的方法是通過 "圖表"，它相當于 TrueNAS 的應用程序，而且據我所知，它可以在本地運行某種 集群（？ 因此，我執行了啟用 的所有步驟，安裝了第三方圖表軟件倉庫（），并從一個有大量選項的輕微損壞圖形用戶界面上安裝了 。 不知怎么搞的，我嘆了口氣，把電腦收了起來，直到以太網正常工作。

又過了幾個月，以太網還是壞了。 IT 部門來測試了幾次端口，確定問題出在他們那邊，說一周左右就能修好，但一周過去了，他們一直沒有回復我的郵件。 哦，好吧。

我目前在 FreeBSD 基金會實習，在實習過程中，我了解到可以將 FreeBSD 系統作為網關，讓其他通過以太網電纜連接的計算機通過它訪問互聯網。 我是否可以通過我的工作電腦上網，因為我的工作電腦就在 NAS 的旁邊？

是的，是的，我可以。這很容易2。

這樣，我的 NAS 終于可以上網了！ 我試著用 的 IP 地址登錄 NAS，結果......什么都沒有。 我看了看 管理面板，NAS 顯示為離線。 這可真夠煩人的。 我可以從 NAS ping IP 和域名，因此互聯網和 DNS 正常工作。 但不是 ...

這時，我意識到我還有一臺電腦——FreeBSD "路由器"——可以直接連接 NAS。 于是，我在路由器上輸入了 DHCP 服務器給 NAS 的 IP 地址，管理界面就顯示出來了。 我登錄進去，經過一番挖掘，發現 不知何故已經自動 "斃命"，所有安裝在它上面的應用程序都不見了。

此時我可以排除故障......但據我所知，我并沒有做錯任何事，而且如果系統如此脆弱，并出現了我上面提到的所有并發癥，我真的不想再處理它了。 TrueNAS必須退出。

軟件嘗試2[成功]

全套解決方案似乎并不適合我，所以我決定安裝自己的操作系統，并將其設置為可行的配置。 現在的想法是安裝一個標準的服務器操作系統，設置我的 RAID 系統，然后將某種自托管云存儲解決方案指向它。 不幸的是，這無法為我提供硬件監控功能，不過到時候我還是會跨過這座橋的。

操作系統：FreeBSD

由于我仍然覺得很冒險，所以決定使用 FreeBSD 13.2 作為操作系統。 在我目前的使用中，它看起來相當可靠，配置簡單，應該對 ZFS（我打算用于存儲的文件系統）有很好的支持，而且有非常棒的文檔。 你讀過 FreeBSD 手冊嗎？ 與 Rust 一書一樣，FreeBSD 13.2 也是在線托管和維護的，與 Arch wiki 或我在 Linux 方面看到的任何其他內容相比，它更適合初學者了解 Unix 操作系統。 強烈建議你通讀一下。

安裝很簡單--如果你以前安裝過 Debian，就會想起 Debian 的安裝程序。 我把操作系統安裝在通用旋轉硬盤上，因為我并不特別在意操作系統--如果它死了，我就重新安裝它。 重要的是數據，數據將存儲在一個由 RAID-Z1 vdev 組成的 ZFS 池中，池中有我的三塊固態硬盤。

存儲：ZFS w/ RAID-Z1

"一個由 RAID-Z1 vdev 組成的 ZFS 池，里面有我的三個固態硬盤"，這句話說得太多了，所以要解釋一下：

一旦建立了池，我就可以將其分割成卷。 默認情況下，卷不會使用固定的空間，它只是根據需要使用池中的空間，但如果你懷念過去固定大小分區的美好時光，可以為卷設置 "配額"。 我剛剛創建了兩個卷，一個用于存放我的所有文件，另一個用于存放 SQL 數據庫。

SQL數據庫？ 關于這一點：

界面：

是一款 PHP+SQL 云存儲解決方案--您只需將其安裝在 FAMP4協議棧服務器上，它就能為您提供跨設備同步文件、在旅途中輕松訪問文件等多種便捷方式。 正是我所需要的！

盡管 極力推動您使用 Docker 容器進行自托管設置，但他們還是提供了在 Linux 裸機上進行設置的說明，這些說明也適用于 FreeBSD 裸機，幾乎沒有任何改動。 只要在他們告訴你安裝 PHP 模塊時安裝 php82- 軟件包，就幾乎可以了。

注意 "幾乎"。 我照做了，向 提供了 DB 憑據和管理員用戶名/密碼，結果看到的是白屏。 通過查看 PHP 日志和在 上搜索，發現 FreeBSD 在 PHP 模塊方面還有一些未列出的要求。 安裝了 php82-mysqli、php82-filter、php82-xsl 和 php82-wddx（根據我的 PHP 版本進行了調整）后，問題解決了。

設置完成后， 就變得輕而易舉了。 我進入管理設置，做了一大堆 "推薦 "的額外操作，比如啟用緩存、HTTPS 和其他一些操作。 方便的是，它還會鏈接到所有建議事項的文檔頁面。 在 HTTPS 方面，由于我只通過 公開我的 NAS，我可以使用 cert 生成 HTTPS 證書，供 使用。 如果你通過網絡公開你的 NAS，你可能會想要使用 Let's Encrypt 或類似的軟件。 只是我個人覺得在公共互聯網上公開 PHP 網絡應用程序有點不妥，所以只能使用內部網絡。

做完這一切后，只需設置 移動和桌面應用程序進行同步，我就可以開始使用了！ 這些應用程序是我選擇 而不只是設置 NFS/SMB 服務器的主要原因--我更看重手機中相機照片的自動同步、本地訪問不同電腦上的學校作業文件等功能，而不僅僅是在必要時遠程訪問服務器上的文件。

結論：經過大量的工作、故障排除和敲腦袋，它終于成功了

我很喜歡這個過程！ 我一般都很喜歡配置電腦，NAS 在我使用的幾個星期里非常實用和可靠，而且它比 銷售的任何產品都要便宜很多。 它確實需要大量的人工干預來設置（偶爾還需要更多的干預），所以我不會把它稱作 級別的全套解決方案，但我對我得到的東西非常滿意。

我會建議你做同樣的事情嗎？ 對我來說是可行的，但我不是系統管理員，這不是備份建議。 如果你覺得使用二手硬件和開源軟件來制作自己的解決方案很舒服，那很好！ 但是，如果你想要 "有人已經為我想好了一切，我再也不用擔心我的數據會消失了 "這樣的安心感，而不需要自己費力去想辦法的話，也許 等產品值得你花錢去買。

后記：要做的事情

我仍然需要異地備份--NAS 現在就放在我的桌子下面。 目前的想法是購買 B2 或其他產品，并設置增量備份。

我對 FreeBSD 也還沒有百分之百的信心，可能會轉到 Linux（可能是 NixOS 或 Fedora ，這樣我就可以將整個操作系統配置存儲在 git repo 中，而且再也不用擔心通用旋轉硬盤會死機了）。 我應該在我的數據增長太多之前，或者在建立并檢查了異地備份的真實性之后再這樣做。 不過現在還能用。

最后，一旦 RAID-Z 擴展實現，我希望能夠擴展我的陣列，而不需要銷毀和重新創建陣列（或者更有可能的是，添加另一個 RAID-Z1 vdev）。

但那是將來的事！ 現在，我比以往任何時候都更有信心，心態更平和。 耶！

本文中的所有價格均為加元。??

對于那些在家跟進的用戶，我使用了本指南中的網絡設置，只是連接了實際生活中的以太網端口，而不是虛擬機的 TUN 設備。 ???

我想知道這是否只是在內部作為 RAID-Z0 實現的。 ??

哈哈, 明白了吧，FreeBSD-Apache-MySQL-PHP? 就像 LAMP，但用的是 FreeBSD 而不是 Linux？ 顯然，這是這種設置的標準名稱--不過也有人用 MariaDB 代替 M，用 Perl 代替 P。??

?關于搭建NAS大家都有什么不同的思路呢？歡迎留言討論，和大家分享你的獨家知識。

揭秘 ChatGPT 背后的技術棧：OpenAI 如何將 Kubernetes 擴展到了 7500 個節點

作者 | OpenAI

譯者 |

策劃 | 褚杏娟

在本文中，OpenAI 的工程師團隊分享了他們在 集群擴展過程中遇到的各種挑戰和解決方案，以及他們取得的性能和效果。

我們已經將 集群擴展到 7500 個節點，為大型模型（如 GPT-3、 CLIP 和 DALL·E）創建了可擴展的基礎設施，同時也為快速小規模迭代研究（如 神經語言模型的縮放定律）創建了可擴展的基礎設施。

將單個 集群擴展到這種規模很少見，但好處是能夠提供一個簡單的基礎架構，使我們的機器學習研究團隊能夠更快地推進并擴展，而無需更改代碼。

自上次發布關于擴展到 2500 個節點的帖子以來，我們繼續擴大基礎設施以滿足研究人員的需求，在此過程中學到了許多的經驗教訓。本文總結了這些經驗教訓，以便 社區里的其他人也能從中受益，并最后會介紹下我們仍然面臨的問題，我們也將繼續解決這些問題。

我們的工作負載

在深入探討之前，我們著重描述一下我們的工作負載。我們在 上運行的應用程序和硬件與大家在普通公司遇到的可能相當不同。因此，我們的問題及解決方案可能與你自己的設置匹配，也可能不匹配！

一個大型的機器學習作業跨越許多節點，當它可以訪問每個節點上的所有硬件資源時，運行效率最高。這允許 GPU 直接使用 NVLink 進行交叉通信，或者 GPU 使用 直接與 NIC 進行通信。因此，對于我們的許多工作負載，單個 Pod 占用整個節點。任何 NUMA、CPU 或 PCIE 資源爭用都不是調度的因素。裝箱或碎片化不是常見的問題。我們目前的集群具有完全的二分帶寬，因此我們也不考慮機架或網絡拓撲。所有這些都意味著，雖然我們有許多節點，但調度程序的負載相對較低。

話雖如此，kube- 的負載是有波動的。一個新的作業可能由許多數百個 Pod 同時創建組成，然后返回到相對較低的流失率。

我們最大的作業運行 MPI，作業中的所有 Pod 都參與一個單一的 MPI 通信器。如果任何一個參與的 Pod 掛掉，整個作業就會停止，需要重新啟動。作業會定期進行檢查點，當重新啟動時，它會從上一個檢查點恢復。因此，我們認為 Pod 是半有狀態的——被刪掉的 Pod 可以被替換并且工作可以繼續，但這樣做會造成干擾，應該盡量減少發生。

我們并不太依賴 的負載均衡。我們的 HTTPS 流量非常少，不需要進行 A/B 測試、藍 / 綠或金絲雀部署。Pod 使用 SSH 直接通過 Pod IP 地址與 MPI 進行通信，而不是通過服務端點。服務“發現”是有限的；我們只在作業啟動時進行一次查找，查找哪些 Pod 參與 MPI。

大多數作業與某種形式的 Blob 存儲進行交互。它們通常會直接從 Blob 存儲流式傳輸一些數據集的分片或檢查點，或將其緩存到快速的本地臨時磁盤中。我們有一些 ，用于那些需要 POSIX 語義的情況，但 Blob 存儲更具可擴展性，而且不需要緩慢的分離 / 附加操作。

最后，我們的工作性質本質上是研究，這意味著工作負載本身是不斷變化的。雖然超級計算團隊努力提供我們認為達到“生產”質量水平的計算基礎架構，但在該集群上運行的應用程序壽命很短，它們的開發人員會快速迭代。因此，隨時可能出現新的使用模式，這些模式會挑戰我們對趨勢和適當權衡的設定。我們需要一個可持續的系統，同時也能讓我們在事情發生變化時快速做出響應。

網 絡

隨著集群內節點和 Pod 數量的增加，我們發現 Flannel 難以滿足所需的吞吐量。因此，我們轉而使用 Azure VMSS 的本地 Pod 網絡技術和相關 CNI 插件來配置 IP。這使我們的 Pod 能夠獲得主機級別的網絡吞吐量。

我們轉而使用別名 IP 地址的另一個原因是，在我們最大的集群中，可能會同時使用約 20 萬個 IP 地址。在測試了基于路由的 Pod 網絡后，我們發現能夠使用的路由數明顯存在限制。

避免封裝會增加底層 SDN 或路由引擎的需求，雖然這使我們的網絡設置變得簡單。添加 VPN 或隧道可以在不需要任何其他適配器的情況下完成。我們不需要擔心由于某部分網絡具有較低的 MTU 而導致的分組分段。網絡策略和流量監控很簡單；沒有關于數據包源和目的地的歧義。

我們使用主機上的 標記來跟蹤每個 和 Pod 的網絡資源使用情況，這使研究人員可以可視化他們的網絡使用模式。特別是，由于我們的許多實驗具有不同的 和 Pod 內通信模式，因此能夠調查任何瓶頸發生的位置通常是非常有意義的。

可以使用 mangle 規則任意標記符合特定條件的數據包。以下是我們用來檢測流量是內部流量還是 流量的規則。FORWARD 規則涵蓋了來自 Pod 的流量，而 INPUT 和 OUTPUT 規則涵蓋了主機上的流量：

iptables -t mangle -A INPUT ! -s 10.0.0.0/8 -m comment --comment "iptables-exporter openai traffic=internet-in"iptables -t mangle -A FORWARD ! -s 10.0.0.0/8 -m comment --comment "iptables-exporter openai traffic=internet-in"iptables -t mangle -A OUTPUT ! -d 10.0.0.0/8 -m comment --comment "iptables-exporter openai traffic=internet-out"iptables -t mangle -A FORWARD ! -d 10.0.0.0/8 -m comment --comment "iptables-exporter openai traffic=internet-out"

一旦標記， 將開始計數以跟蹤匹配該規則的字節數和數據包數。你可以使用 本身來查看這些計數器：

% iptables -t mangle -L -vChain FORWARD (policy ACCEPT 50M packets, 334G bytes) pkts bytes target     prot opt in     out     source               destination....1253K  555M            all  --  any    any     anywhere            !10.0.0.0/8           /* iptables-exporter openai traffic=internet-out */1161K 7937M            all  --  any    any    !10.0.0.0/8           anywhere             /* iptables-exporter openai traffic=internet-in */

我們使用名為 - 的開源 導出器將這些數據追蹤到我們的監控系統中。這是一種簡單的方法，可以跟蹤與各種不同類型的條件匹配的數據包。

我們網絡模型中比較獨特的一點是，我們完全向研究人員公開節點、Pod 和 Service 網絡 CIDR 范圍。我們采用集線器和分支的網絡模型，并使用本機節點和 Pod CIDR 范圍路由該流量。研究人員連接到中心樞紐，然后可以訪問任何一個單獨的集群（分支）。但是這些集群本身無法相互通信。這確保了集群保持隔離、沒有跨集群依賴，可以防止故障隔離中的故障傳播。

我們使用一個“NAT”主機來翻譯從集群外部傳入的服務網絡 CIDR 范圍的流量。這種設置為我們的研究人員提供了很大的靈活性，他們可以選擇各種不同類型的網絡配置進行實驗。

API 服務器

的 API Server 和 etcd 是保持集群健康運行的關鍵組件，因此我們特別關注這些系統的壓力。我們使用 kube- 提供的 Grafana 儀表板以及額外的內部儀表板。我們發現，將 HTTP 狀態碼 429（請求太多）和 5xx（服務器錯誤）的速率作為高級信號警報是有用的。

雖然有些人在 kube 內部運行 API 服務器，但我們一直在集群外運行它們。etcd 和 API 服務器都在它們自己的專用節點上運行。我們的最大集群運行 5 個 API 服務器和 5 個 etcd 節點，以分散負載并盡可能減少發生故障后帶來的影響。自從我們在 上一篇博文 中提到的將 事件拆分到它們自己的 etcd 集群中以來，我們沒有遇到 etcd 的任何值得注意的問題。API 服務器是無狀態的，通常很容易在自我修復的實例組或擴展集中運行。我們尚未嘗試構建任何自我修復 etcd 集群的自動化，因為發生事故非常罕見。

API 服務器可能會占用相當多的內存，并且往往會與集群中的節點數量成線性比例。對于我們有 7500 個節點的集群，我們觀察到每個 API 服務器使用高達 70GB 的堆內存，因此幸運地是，未來這應該仍然在硬件能力范圍之內。

API Servers 受到壓力的主要來源之一就是對 的 WATCH。在整個集群中有一些服務，如“kubelet”和“node-”，其中每個節點都是成員。當一個節點被添加或從集群中刪除時，這個 WATCH 將被觸發。通常，由于每個節點本身都通過 kube-proxy 監視 kubelet 服務，因此這些響應中所需的數量和帶寬將是N2非常大，有時會達到 1GB/s 或更高。 1.17 中推出的 大大降低了這種負載，減少達 1000 倍。

總的來說，我們會非常注意隨著集群規模增大而增加的 API Server 請求。我們盡量避免任何 與 API Server 交互。在需要每個節點監視更改的情況下，引入緩存服務（例如 Datadog Cluster Agent）作為中介，似乎是避免集群范圍瓶頸的良好模式。

隨著集群的增長，我們對集群的實際自動伸縮越來越少。但當一次性自動擴展太多時，我們偶爾會遇到問題。當新節點加入集群時會生成大量請求，一次性添加數百個節點可能會超過 API 服務器容量的負荷。稍微平滑一下這個過程，即使只有幾秒鐘也有助于避免宕機。

時間序列度量與 和 Grafana

我們使用 收集時間序列度量數據，并使用 Grafana 進行圖形、儀表板和警報。我們從 kube- 部署開始收集了各種各樣的度量數據，并使用了一些良好的儀表板進行可視化。隨著節點數量的不斷增加，我們開始遇到 收集的度量數據數量過多的問題。盡管 kube- 公開了許多有用的數據，但我們實際上并沒有查看所有的度量數據，一些數據也過于細化，無法有效地進行收集、存儲和查詢。因此，我們使用 規則從被攝入的度量數據中“刪掉”一些數據。

有一段時間，我們遇到了 消耗越來越多的內存問題，最終導致容器崩潰并出現 Out-Of-Memory 錯誤（OOM）。即使為應用程序分配了大量的內存容量，這種情況似乎仍然會發生。更糟糕的是，它在崩潰時會花費很多時間在啟動時回放預寫日志文件，直到它再次可用。最終，我們發現了這些 OOM 的來源是 Grafana 和 之間的交互，其中 Grafana 使用 /api/v1/series API 查詢 {le!=""}（基本上是“給我所有的直方圖度量”）。/api/v1/series 的實現在時間和空間上沒有限制，對于具有大量結果的查詢，這將不斷消耗更多的內存和時間。即使請求者已經放棄并關閉了連接，它也會繼續增長。對于我們來說，內存永遠不夠，而 最終會崩潰。因此，我們修補了 ，將此 API 包含在上下文中以強制執行超時，從而完全解決了問題。

雖然 崩潰的次數大大減少，但在我們需要重新啟動它的時候，WAL 回放仍然是一個問題。通常需要多個小時來回放所有 WAL 日志，直到 開始收集新的度量數據并提供服務。在 Robust 的幫助下，我們發現將 =24 應用于服務器可以顯著提高性能。在 WAL 回放期間， 嘗試使用所有核心，并且對于具有大量核心的服務器，爭用會降低所有性能。

我們正在探索新的選項來增加我們的監控能力，下面“未解決的問題”部分將對此進行描述。

健康檢查

對于如此龐大的集群，我們當然依賴自動化來檢測并從集群中移除行為不當的節點。隨著時間的推移，我們建立了許多健康檢查系統。

被動健康檢查

某些健康檢查是被動的，總是在所有節點上運行。這些檢查監視基本的系統資源，例如網絡可達性、壞盤或滿盤，或者 GPU 錯誤。GPU 以許多不同的方式出現問題，但一個容易出現的常見問題是“不可糾正的 ECC 錯誤”。Nvidia 的數據中心 GPU 管理器（DCGM）工具使查詢這個問題和許多其他“Xid”錯誤變得容易。我們跟蹤這些錯誤的一種方式是通過 dcgm- 將指標收集到我們的監控系統 中。這將出現為 RS 指標，并設置為最近發生的錯誤代碼。此外，NVML 設備查詢 API 公開了有關 GPU 的健康和操作的更詳細信息。

一旦檢測到錯誤，它們通常可以通過重置 GPU 或系統來修復，但在某些情況下確實需要更換基礎 GPU。

另一種健康檢查是跟蹤來自上游云提供商的維護事件。每個主要的云提供商都公開了一種方式來了解當前 VM 是否需要進行會最終導致中斷的、即將發生的維護事件。VM 可能需要重新啟動以應用底層的超級管理程序補丁，或者將物理節點替換為其他硬件。

這些被動健康檢查在所有節點上不斷運行。如果健康檢查開始失敗，節點將自動劃分，因此不會在節點上安排新的 Pod。對于更嚴重的健康檢查失敗，我們還將嘗試 Pod 驅逐，以要求當前運行的所有 Pod 立即退出。這仍然取決于 Pod 本身，可通過 Pod 故障預算進行配置來決定是否允許此驅逐發生。最終，無論是在所有 Pod 終止之后，還是在 7 天過去之后（我們的服務級別協議的一部分），我們都將強制終止 VM。

活動 GPU 測試

不幸的是，并非所有 GPU 問題都會通過 DCGM 可見的錯誤代碼表現出來。我們建立了自己的測試庫，通過對 GPU 進行測試來捕捉其他問題，并確保硬件和驅動程序的行為符合預期。這些測試無法在后臺運行 - 它們需要獨占 GPU 運行數秒鐘或數分鐘。

我們首先在節點啟動時運行這些測試，使用我們稱之為“預檢（）”的系統。所有節點都會附帶一個“預檢”污點和標簽加入集群。這個污點會阻止普通 Pod 被調度到節點上。我們配置了一個 ，在所有帶有此標簽的節點上運行預檢測試 Pod。測試成功完成后，測試本身將刪除污點和標簽，然后該節點就可供一般使用。

我們還定期在節點的生命周期中運行這些測試。我們將其作為 CronJob 運行，允許它著陸在集群中的任何可用節點上。哪些節點會被測試到可能有些隨機和不受控制，但我們發現隨著時間的推移，它提供了足夠的覆蓋率，并且最小化了協調或干擾。

配額和資源使用

隨著集群規模的擴大，研究人員開始發現他們難以獲取分配給他們的全部容量。傳統的作業調度系統有許多不同的功能，可以公平地在競爭團隊之間運行工作，而 沒有這些功能。隨著時間的推移，我們從這些作業調度系統中汲取靈感，并以 原生的方式構建了幾個功能。

團隊污點

我們在每個集群中都有一個服務，稱為“team--manager”，具有多個功能。它的數據源是一個 ，為在給定集群中具有容量的所有研究團隊指定了 （節點選擇器、應用的團隊標簽、分配數量） 元組。它會將當前節點與這些元組進行對比，并使用 /team=: 的污點對適當數量的節點進行標記。

“team--manager”還有一個入站的 webhook 服務，因此在提交每個作業時會根據提交者的團隊成員身份應用相應的容忍度。使用污點使我們能夠靈活地限制 Pod 調度程序，例如允許較低優先級的 Pod 具有 "any" 容忍度，這樣團隊可以借用彼此的容量，而無需進行大量協調。

CPU 和 GPU

除了使用集群自動縮放器動態擴展我們基于虛擬機的集群之外，我們還使用它來糾正（刪除和重新添加）集群中的不健康成員。我們通過將集群的 "最小值" 設置為零、"最大值" 設置為可用容量來實現這一點。然而，如果 cluster- 發現有空閑節點，它將嘗試縮小到只需要的容量。由于多種原因（VM 啟動延遲、預分配成本、上面提到的 API 服務器影響），這種空閑縮放并不理想。

因此，我們為 CPU 和 GPU 主機都引入了“球形”部署。這個部署包含一個具有 "最大值" 數量的低優先級 Pod 副本集。這些 Pod 占用節點內的資源，因此自動縮放器不會將它們視為空閑。但由于它們是低優先級的，調度程序可以立即將它們驅逐出去，以騰出空間進行實際工作。（我們選擇使用 而不是 ，以避免將 視為節點上的空閑工作負載。）

需要注意的是，我們使用 pod 反親和性（anti-）來確保 pod 在節點之間均勻分布。 調度器的早期版本存在一個 O(N^2) 的性能問題，與 pod 反親和性有關。自 1.18 版本以后，這個問題已經得到了糾正。

Gang 調度

我們的實驗通常涉及一個或多個 ，每個 操作不同部分的訓練任務。對于優化器，研究人員需要在進行任何訓練之前調度 的所有成員（因為我們通常使用 MPI 在優化器成員之間協調，而 MPI 對組成員變化很敏感）。

然而再默認情況下， 不一定會優先滿足某個 的所有請求。例如，如果兩個實驗都請求 100％的集群容量，那么 可能只會調度給每個實驗需要的一半 Pod，這會導致死鎖，使兩個實驗都無法進行。

我們嘗試了一些需要自定義調度程序的方法，但遇到了一些與正常 Pod 調度方式沖突的邊緣情況。 1.18 引入了核心 調度程序的插件體系結構，使本地添加此類功能變得更加容易。我們最近選擇了 插件作為解決此問題的方法。

未解決的問題

隨著 集群規模的擴大，我們仍有許多問題需要解決。其中一些問題包括：

指標

在如今的規模下， 內置的 TSDB 存儲引擎很難壓縮，并且每次重新啟動時需要長時間回放 WAL（預寫式日志）。查詢還往往會導致“查詢處理會加載過多樣本”的錯誤。我們正在遷移到不同的、與 兼容的存儲和查詢引擎。大家可以期待下我們未來的博客文章，看看它的表現如何！

Pod 網絡流量整形

隨著集群規模的擴大，每個 Pod 的互聯網帶寬量被計算了出來。每個人的聚合互聯網帶寬需求變得非常大，我們的研究人員現在有能力會意外地對互聯網上的其他位置施加重大資源壓力，例如要下載的數據集和要安裝的軟件包。

結 論

是一個非常靈活的平臺，可以滿足我們的研究需求。它具有滿足我們所面臨的最苛刻工作負載的能力。盡管它仍有許多需要改進的地方，但 OpenAI 的超級計算團隊將繼續探索 的可擴展性。

作者簡介：

本文作者為 OpenAI 員工 Eric Sigler 和 Chess。

原文鏈接：