三十多年(nian)前，在(zai)高性能(neng)(neng)計算(suan)(suan)的(de)(de)初期(qi)，服務(wu)器領(ling)域還沒有所謂的(de)(de)商品硬(ying)件。各個(ge)機(ji)構(gou)都有自己(ji)的(de)(de)專(zhuan)有平(ping)臺，他們不得不盡(jin)可(ke)能(neng)(neng)地從這些平(ping)臺上榨取更多的(de)(de)性能(neng)(neng)。可(ke)靠性通常是(shi)(shi)事后考慮的(de)(de)，因為考慮到當(dang)時的(de)(de)架構(gou)，你對可(ke)靠性沒有什(shen)么辦法。然而，由于那個(ge)時代(dai)的(de)(de)低數據(ju)量和有限的(de)(de)算(suan)(suan)法，早期(qi)的(de)(de)HPC架構(gou)是(shi)(shi)有效(xiao)的(de)(de)。

隨(sui)著(zhu)超級計(ji)算機(ji)和(he)HPC集群的(de)不斷發展(zhan)，這(zhe)些(xie)(xie)專(zhuan)有系統無法有效(xiao)擴展(zhan)，尤其是(shi)(shi)在其存儲架(jia)構(gou)方面。兩臺計(ji)算機(ji)將組(zu)成一(yi)“對兒(er)”，共享一(yi)個(ge)后(hou)端存儲，但這(zhe)些(xie)(xie)組(zu)成的(de)“對兒(er)”是(shi)(shi)為了相對隔(ge)離地運行(xing)。嘗試將這(zhe)些(xie)(xie)“對兒(er)”擴展(zhan)到數百(bai)個(ge)時，擴展(zhan)就會(hui)暴露出架(jia)構(gou)弱點。

在(zai)快(kuai)速發(fa)展的(de)(de)今天(tian)情況(kuang)很明顯：HPC正在(zai)為規模(mo)化(hua)的(de)(de)可靠性(xing)而努力。10多(duo)年前，谷歌證(zheng)明了在(zai)軟件(jian)(jian)定義系(xi)統(tong)的(de)(de)控(kong)制(zhi)下，硬件(jian)(jian)對于超(chao)大規模(mo)處理(li)來(lai)說既便(bian)宜又(you)有效(xiao)，但HPC市(shi)場仍(reng)然堅持其老(lao)派(pai)的(de)(de)、基于硬件(jian)(jian)的(de)(de)模(mo)式(shi)。也許這是由于普遍的(de)(de)行業(ye)勢頭或在(zai)既定做(zuo)法的(de)(de)集體(ti)舒適區工作的(de)(de)原因(yin)。無論(lun)是哪(na)種情況(kuang)，以硬件(jian)(jian)為中(zhong)心的(de)(de)存儲彈性(xing)方法都需要改變。谷歌革(ge)命性(xing)的(de)(de)以軟件(jian)(jian)為中(zhong)心的(de)(de)擴展架構方法為更高的(de)(de)運營效(xiao)率打開了大門，現在(zai)是時候讓HPC世(shi)界學習谷歌的(de)(de)經(jing)驗教訓了。

谷歌拒絕了讓人頭疼的硬件

與HPC 世界不同的是，谷歌一(yi)開始擁有(you)一(yi)支由分布(bu)式系(xi)統專家(jia)組成的工程團(tuan)隊，他們帶來了不同的視角。當(dang)然，谷歌也有(you)過失(shi)誤，但在橫向(xiang)擴展計算方面，這家(jia)搜索(suo)巨頭的成就毋庸置疑。

首(shou)先，谷(gu)歌改(gai)變了(le)依賴專(zhuan)門的(de)(de)(de)(de)甚至是(shi)(shi)定制的(de)(de)(de)(de)服務(wu)器(qi)的(de)(de)(de)(de)趨勢(shi)，這(zhe)些(xie)服務(wu)器(qi)是(shi)(shi)按照嚴格的(de)(de)(de)(de)質(zhi)量水(shui)平(ping)建造的(de)(de)(de)(de)，試圖做(zuo)到(dao)高度彈(dan)(dan)性（往往是(shi)(shi)不(bu)成(cheng)(cheng)功的(de)(de)(de)(de)）。相反(fan)，該公司(si)實(shi)施(shi)了(le)大(da)量的(de)(de)(de)(de)商品、現成(cheng)(cheng)的(de)(de)(de)(de)服務(wu)器(qi)，通過軟件實(shi)現集群級的(de)(de)(de)(de)彈(dan)(dan)性。這(zhe)種平(ping)臺方法被稱為(wei)倉庫級機器(qi)。從擴展的(de)(de)(de)(de)角度來看，這(zhe)是(shi)(shi)一個(ge)明智的(de)(de)(de)(de)做(zuo)法。隨著系(xi)統的(de)(de)(de)(de)規模和復雜(za)性的(de)(de)(de)(de)增加(jia)，它們(men)的(de)(de)(de)(de)故障(zhang)也變得越(yue)發普遍和昂貴。這(zhe)就是(shi)(shi)為(wei)什么大(da)多數HPC存儲(chu)系(xi)統的(de)(de)(de)(de)故障(zhang)導(dao)致的(de)(de)(de)(de)問題遠(yuan)遠(yuan)多于其他(ta)領域(yu)的(de)(de)(de)(de)類似(si)故障(zhang)，這(zhe)些(xie)領域(yu)都是(shi)(shi)以軟件為(wei)中心的(de)(de)(de)(de)架構。

谷歌認為討論如何防止故(gu)障(zhang)(zhang)是(shi)(shi)毫無意義。相反，關鍵是(shi)(shi)要預測故(gu)障(zhang)(zhang)并減輕其影響。這一觀(guan)點(dian)的轉變完全破壞了(le)以(yi)硬件為中(zhong)心的范(fan)式。谷歌證明，有(you)了(le)商(shang)品硬件，就有(you)可能超越試(shi)圖橋接(jie)數百對兒計(ji)算機并且建(jian)立(li)一個獨立(li)區(qu)域(yu)，其中(zhong)任何一點(dian)的失敗都是(shi)(shi)允許和可預期的。

2003 年推出并在HPC 環境中仍然非常流行的Lustre 文件系統說明了這一點。因為它是那個時代的產物，Lustre 要求在硬件中實現彈性。這增加了復雜性和難度，因為僅靠傳統的RAID 控制器是不夠的。為了跨越多臺服務器，工程師必須對系統進行硬連線，以允許多臺服務器查看、安裝和共享彼此的驅動器——但一個驅動器永遠不能由兩個系統同時安裝。因此，兩臺服務器必須能夠相互關閉，而這需要有一個帶有可管理電源插座的集線器。

當HPC 集(ji)群處(chu)理PB 級(ji)數(shu)(shu)據(ju)時，這種方法是可行的，但在處(chu)理達到(dao)數(shu)(shu)十或數(shu)(shu)百PB 的現代數(shu)(shu)據(ju)集(ji)時，擴展性(xing)(xing)會受到(dao)很大(da)限(xian)制。以這種規模(mo)跨系統管理存(cun)儲是一場噩夢，這是因(yin)為以硬件為中心的持續存(cun)在。谷歌意識到(dao)了這一點，并表(biao)明在軟件中管理彈性(xing)(xing)變得更加容(rong)易。

卓越的軟件

1989 年，計算機科學家萊斯利·蘭波特(Leslie Lamport) 撰寫了一篇論文，其中他定義了Paxos 算法，該算法以希臘島嶼命名，（虛構的）議會必須與議員們的討論中得出結論和達成共識。這是繼 Lamport 早期關于“拜占庭將軍問題”（其解決方案將繼續影響從現代飛行控制到比特幣的一切）的工作之后，繼續他對分布式系統容錯的探索。Lamport 對Paxos 的第一次探索陷入停滯，但他在2001 年發表了一個簡化的處理方法 ，獲得了關注。

Google 在其Chubby 分布式鎖服務中實現了Paxos 算法。Ceph、Apache Cassandra、Amazon Elastic Container Services 和其他公司紛紛效仿。在每種情況下，一個主要目標都是減輕硬件依賴性并允許軟件管理跨機器的數據冗余，同時處理任何故障。現在，不再有高可用性服務器的小“孤島”，一百甚至數千個節點可以作為一個單一的、有凝聚力的、自我修復的整體一起統一行動。

軟件定義的彈(dan)性(xing)對于(yu)谷(gu)歌(ge)的擴展及其市場(chang)主(zhu)導地位至關重要(yao)，源自基(ji)(ji)于(yu)軟件的基(ji)(ji)礎架構的運營效(xiao)率取決(jue)于(yu)使人(ren)為(wei)干預成為(wei)例(li)外(wai)。更新不應該需要(yao)人(ren)，掉線的系(xi)統不應該（立即）需要(yao)人(ren)。相反，最少(shao)的管(guan)理人(ren)員應該能(neng)夠(gou)管(guan)理比以硬件為(wei)中心的彈(dan)性(xing)模(mo)型所(suo)能(neng)達到的更大數量(liang)級(ji)的集群(qun)資(zi)源。

同樣，集群(qun)管理員(yuan)應(ying)該(gai)能夠(gou)獨(du)立(li)于系統(tong)工作。在(zai)2021 年(nian)，沒有人需要在(zai)凌晨(chen)4:00 親自(zi)(zi)操(cao)作HPC 集群(qun)來關(guan)閉系統(tong)，只是為了執行更新。集群(qun)不(bu)應(ying)規(gui)定操(cao)作，也不(bu)應(ying)規(gui)定用(yong)戶何時可以(yi)和不(bu)能使用(yong)系統(tong)。一旦您將維護與(yu)系統(tong)分離(li)并(bing)允許軟件自(zi)(zi)動化流程(cheng)，所有相關(guan)人員(yuan)的效(xiao)率都會提(ti)高。

HPC，是時候建立一個更好的范例了

人們可以(yi)將這(zhe)種(zhong)硬件(jian)(jian)與(yu)軟件(jian)(jian)的(de)(de)(de)二(er)分法視為一個運營模型問題(ti)，因(yin)為運營在(zai)很大程度上涉及(ji)人力成本(ben)。1990 年代以(yi)硬件(jian)(jian)為中心的(de)(de)(de)HPC 解決方案證(zheng)明(ming)了他們高(gao)昂的(de)(de)(de)人力成本(ben)是合(he)理的(de)(de)(de)，因(yin)為當時(shi)的(de)(de)(de)專(zhuan)用硬件(jian)(jian)非(fei)常昂貴(gui)。總的(de)(de)(de)來說，這(zhe)些(xie)成本(ben)被小(xiao)型部署所控制。但是，當人力成本(ben)隨系統(tong)規模線性(xing)增(zeng)長時(shi)，以(yi)硬件(jian)(jian)為中心的(de)(de)(de)模型顯然(ran)會出現操作問題(ti)。數據負載繼續呈(cheng)指數級增(zeng)長，但HPC 仍然(ran)存在(zai)20 年歷史的(de)(de)(de)存儲(chu)架構以(yi)及(ji)隨之而來的(de)(de)(de)所有人力成本(ben)。

在(zai)(zai)HPC 世界(jie)之外(wai)，業界(jie)遷(qian)移到Hadoop 進行大規模數據分析(xi)，但Hadoop 可(ke)(ke)能比HPC 更適合谷歌類(lei)型的(de)工作負載。同樣，這(zhe)(zhe)也不是(shi)科學家使(shi)用MapReduce 運(yun)(yun)行他們的(de)應用程序(xu)的(de)理(li)由。這(zhe)(zhe)是(shi)關于(yu)(yu)谷歌的(de)戰略，而(er)不是(shi)它的(de)戰術。它是(shi)關于(yu)(yu)拋(pao)棄HPC 的(de)傳統架(jia)構，以實現提升可(ke)(ke)擴展的(de)增長和(he)運(yun)(yun)營(ying)效率。HPC 確實成(cheng)功地采用了對(dui)象存儲，因為它可(ke)(ke)用、可(ke)(ke)擴展、可(ke)(ke)管理(li)且(qie)簡單。現在(zai)(zai)，如果運(yun)(yun)營(ying)商接(jie)受基于(yu)(yu)真正的(de)超(chao)大規模設(she)計(ji)的(de)系(xi)統，HPC 文件系(xi)統也可(ke)(ke)以這(zhe)(zhe)樣做。

無需(xu)繼續使(shi)用(yong)專有或傳統(tong)的(de)存儲方法。如果(guo)您的(de)HPC 工作仍然受(shou)到基于硬件的(de)彈性和低效(xiao)維(wei)護的(de)限制，也(ye)許(xu)現(xian)在是時候效(xiao)仿(fang)Google 的(de)例子并向(xiang)前邁進(jin)一大步了(le)。

轉自Bjorn Kolbeck, CEO of Quobyte