當Amazon Web Services在2018年發(fā)布其AWS Graviton Arm處理器時，它的目標是松散耦合的橫向擴展工作負載，比如Web服務器、日志處理和緩存，這些實例吸引了SmugMug這樣的客戶，他們覺得自己在高級計算上付出的代價太高了，而一個較小的內(nèi)核就可以完成這項工作?；贏rm的計算實例可以替代絕大多數(shù)云巨頭客戶使用的基于x86的服務。
亞馬遜EC2的副總裁、David Brown,在接受New Stack采訪時表示，從很多方面來說，這都是為了啟動生態(tài)系統(tǒng)。“我們想向生態(tài)系統(tǒng)發(fā)出信號，Arm服務器芯片將成為現(xiàn)實，我們將把它們推出市場。”
準備好生態(tài)系統(tǒng)意味著，Graviton2不僅可以快速支持EC2實例，還可以支持越來越多的AWS服務，包括Amazon RDS、Amazon ElastiCache（其中Graviton2實際上是默認的）和像Amazon EKS這樣的容器服務。
只有在客戶選擇處理器架構的時候，Graviton才會顯現(xiàn)出來；在“絕大多數(shù)服務”中，客戶將永遠不會看到該服務是在Arm上運行的，但他暗示很多客戶將會看到。
Brown指出，將AWS服務遷移到Arm還有助于使生態(tài)系統(tǒng)為客戶的工作負載做好準備?！斑@為我們提供了很多內(nèi)部經(jīng)驗，涉及客戶將會經(jīng)歷的事情，以及確保我們在生態(tài)系統(tǒng)中能夠接觸到各個參與者，并通過我們可以構建的工具和可以幫助您的事情來解決問題。”
Graviton2甚至可以作為一個擁有64個vcpu、128GiB內(nèi)存和4TB本地NVMe存儲來運行Amazon EC2和EKS的1U服務器（盡管AWS建議將其用于受限制的位置，如蜂窩基站而不是主流數(shù)據(jù)中心）?！拔覀儚目蛻裟抢锫犝f，他們很希望在前哨站安裝Graviton2，就支持生態(tài)系統(tǒng)而言，并確保我們能在客戶需要的時候提供他們想要的硬件，ARM處理器并不意味著不能在前哨站安裝。”
AWS還將添加更多基于AWS Graviton2的實例-最新的是計算和網(wǎng)絡密集型C6gn，以及為大型內(nèi)存數(shù)據(jù)集或計算密集型工作負載而設計的實例，帶有或不帶有本地NVMe存儲。
從卸載到整合
Brown建議考慮開發(fā)類似Graviton的硬件微服務，它可以比整個單片硬件系統(tǒng)更快地建立起來。Brown說，所有的云服務提供商都希望降低在同一個CPU上運行云服務的開銷，而AWS Nitro計算核心的運行效率遠不止于此。
一定比例的處理器（不管它是什么）被虛擬化堆棧和需要在機器上運行的大量其他管理軟件所使用。我們注意到的是，除了降低效率之外（因為您使用了本可以提供給客戶的10 - 20%的核心用于您自己的工作和管理程序），我們還無法獲得我們認為客戶需要的那種性能。
AWS使用Nitro將越來越多的開銷轉移到單獨的處理器上，以提高性能并使其更加一致。“我們做的第一件事就是移除網(wǎng)絡并將其卸載到Arm處理器上。我們卸下了所有的管理控制職能，最終在2017年，我們的CPU使用率達到了零?！?/p>
由于Arm授予IP許可而不是出售處理器的方式，Arm SoC通常是CPU，GPU和加速器的自定義程序包，并且Amazon添加了許多AWS特定功能。
“Graviton2的三分之一是Arm核心，其余部分是我們設計的定制硅，”Brown說。這包括加密內(nèi)存和提高內(nèi)存性能。很多工作是確保糾錯，并確保內(nèi)核確實非常正確，并且可以處理可能無法正常工作的內(nèi)存模塊，并保護客戶工作負載免受此類故障的影響?！?/p>
CPU綁定應用程序的核心
Arm以移動芯片起家，常常被視為一種降低功耗的方法，而高核心數(shù)量使Arm系統(tǒng)很適合并行化，但最近幾代Arm也提供了強大的核心。這一組合帶來了AWS所關注的性價比。
”Arm核心消耗的能量只有可選核心的一半?？蛻艨吹搅?0%的原始性能改進；如果你在同一個基準測試中運行，在Graviton2和最新的英特爾處理器上，Graviton2大約快20%，“Brown說。它還便宜20%左右。因此，你可以得到40%的價格性能改進，Brown說。
”我們已經(jīng)看到客戶使用支持ARM64的最新版本的Java獲得了巨大的性能優(yōu)勢。我們看到客戶也從數(shù)據(jù)庫應用程序中獲得了這一好處。他說，只要看到核心的性能，價格就可以了。
Brown說，客戶通常在移動更多堆棧之前就開始在他們的應用程序層使用Graviton?！八恍枰罅康挠嬎忝芗?；它只是一些CPU受限的最通用的工作負載，如果可用的話，它們會使用更多的CPU。很多云本地工作負載，無論是運行在EC2上的本地工作負載，還是運行在我們的容器堆棧上的工作負載，都將看到顯著的性能優(yōu)勢?！?/p>
這也可以削減其他虛擬機的成本。Duckbill Group首席云經(jīng)濟學家Corey Quinn告訴New Stack，許多IaaS實例的使用率極低?！叭绻铱匆幌麓笠?guī)?？蛻暨\行良好的大型機隊，在某些情況下我們正在談論數(shù)以萬計的節(jié)點或更多，那么這些方面的CPU利用率是可笑的：平均個位數(shù)百分位數(shù)?！?/p>
可觀測性服務提供商Honeycomb被更便宜、更具性能的實例的承諾所吸引。“我們是一家SaaS公司，尤其是基礎設施SaaS公司，因此我們的大部分運營費用是我們的AWS賬單，”首席開發(fā)律師Liz Fong Jones告訴New Stack。
切換到Graviton2可使公司工程師在40個實例上運行相同的入口工作負載（接收JSON對象并將它們放入Kafka），而不是X64上需要的70個實例，并且性能沒有明顯變化。他們還可以將CPU利用率提高到更高（50-60％，而不是之前設置的45％），而不會出現(xiàn)使用率高峰時使CPU飽和的風險。Fong-Jones推測這是因為Graviton2內(nèi)核不是超線程的?！懊總€核心都是真正的核心，它不是共享的執(zhí)行單元?！?/p>
為了獲得更好的性能，Honeycomb還將查詢引擎工作負載（它是IO和CPU綁定的，并且需要NVMe存儲）從Intel Xeon上的存儲優(yōu)化的i3實例轉移到Graviton2 M6GD，盡管成本要高出大約10%。她說：“實際上速度是它的兩倍?！?/p>
該公司正在繼續(xù)將工作負載轉移到Arm。前端服務基礎架構（不占用大量CPU）現(xiàn)在可以在Graviton1上運行，而Fong-Jones計劃純粹出于成本原因計劃切換其Kafka工作負載。對于持續(xù)的工作量，該公司使用Compute Savings Plan，并且她希望通過Graviton2的試驗能夠降低支出水平。
Arm準備做什么？
當開發(fā)人員社區(qū)開始評估Apple的新型基于Arm的Mac時，有關在ARM64客戶端上可以使用哪些工具的問題一直存在疑問，但是ARM64服務器軟件生態(tài)系統(tǒng)已經(jīng)準備就緒，可以在幾天或幾周內(nèi)完成一些遷移，Brown建議。
“在很大程度上，如果人們在構建應用程序，那么這些應用程序的運行時很有可能是為ARM處理器構建的。例如，Python或Java運行時提供支持ARM的運行時，”Gartner研究總監(jiān)Raj Bala告訴New Stack?！斑@一挑戰(zhàn)將涉及可能利用ARM無法提供的處理器特定功能的框架?！保ㄉ虡I(yè)的、現(xiàn)成的）應用程序可能是最大的挑戰(zhàn)——或者可能是Docker容器不是用ARM支撐構建的?！?/p>
Fong-Jones告訴我們，內(nèi)部代碼肯定不太可能準備就緒?！蹦憧梢缘玫揭粋€可以運行的Ubuntu圖像，這已經(jīng)相當大了。同樣，不僅僅是Java和PHP是解釋語言，golang也是。如果沒有golang對ARM64的支持和交叉編譯的支持，我們不可能做到這一點。“
但她說，那是比較容易的部分。我們必須做一些準備工作，以驗證我們沒有任何硬依賴于x86匯編。我們確實有一些相當優(yōu)化的存儲部分，有一些使用AMD64組裝，但他們有常規(guī)的Go等效物。但挑戰(zhàn)在于所有的底層系統(tǒng)架構。”
Honeycomb的安全入侵系統(tǒng)是建立在osquery上的，osquery最近才引入了ARM64支持（部分是由于Honeycomb對端口的贊助）?！叭绻覀儾渴鹆艘欢堰@樣的服務器，而沒有對它們進行適當?shù)娜肭謾z測，我們的安全審核員會對我們非常不滿。”
該公司依賴于Chef配置管理軟件。Chef 15支持ARM64，但Honeycomb使用Chef 13?！癈hef 13，至少是由Chef公司提供的，不是為ARM64設計的。所以我們不得不將一些Ubuntu包向后移植，然后轉換架構。有些東西需要重新調整，因為如果您運行的是舊的LTS軟件，有些軟件并不是為Arm而構建的；您必須將其后置?！?/p>
Fong Jones曾研究過將MySQL轉換為Arm以提高性能，“因為各種元數(shù)據(jù)的數(shù)據(jù)庫擴展是一個瓶頸?！钡瑯?，AWS支持MySQL 8、MariaDB 10和最新版本的PostgreSQL；“我們使用的是MySQL 5.6，我們的語義不允許直接升級到MySQL 8。我們可以使用MariaDB 10，但AWS不允許您在零停機的情況下這樣做，因為它被認為是一個不同的數(shù)據(jù)庫引擎?！?/p>
一如既往，問題的關鍵在于細節(jié)，“這些隨機的、奇怪的系統(tǒng)級依賴關系，您必須真正、真正地確定下來?！弊尨a運行起來——這很容易！“
Quinn認為，這些不匹配是并非所有人都喜歡躍上Graviton的一個原因，如果還沒有為Nitro移植必要的驅動程序，那么英特爾的最新例子也是如此?！痹谠S多環(huán)境中，它需要一個OS更新；反過來，這意味著您需要重新驗證和遷移現(xiàn)有的工作負載，而公司在這方面總是很慢。同樣的問題阻礙了其他技術的應用，比如自動縮放。“他們還沒有更新他們的應用架構，以便在節(jié)點加入時無需重新配置一切就能動態(tài)伸縮?！?/p>
Brown指出：“對于一個數(shù)據(jù)庫來說，如果舊版本不支持Arm，而且將來也不會支持Arm，那么向新版本遷移就會有點困難。”
“這就是我們認為客戶需要權衡投資的地方。在這個行業(yè)中，40%的性價比提升并不常見。
他建議：”盡可能便宜、快速地嘗試對工作負載進行基準測試。“?！比缓?，您可以投資進行遷移，例如遷移到不同的數(shù)據(jù)庫版本或重寫特定于處理器的內(nèi)核模塊，因為40%的性價比證明了這一點。“
客戶準備好使用Arm了嗎？
對于新的實例類型，有時存在可用性問題；因為沒有足夠的M6GD實例，F(xiàn)ong Jones不得不暫停查詢引擎遷移12個小時，為了獲得spot實例，她不得不接受M6實例（內(nèi)存更多，時鐘速度稍高），以及C6實例，這些都是工作負載所需的。
Quinn同意，對可用性的擔憂可能是AWS客戶對轉向Graviton持謹慎態(tài)度的一個原因，但他們應該是短暫的?！蔽夷茉谌魏我粋€AWS地區(qū)獲得規(guī)模化運行的能力嗎？這方面的現(xiàn)貨供應情況如何，他們能盡快拿到嗎？答案顯然是肯定的，現(xiàn)在他們有了足夠的容量，可以開始將其作為托管服務提供?！?/p>
Quinn指出，Graviton可能不是企業(yè)降低AWS費用的早期選擇，也不是最重要的方式?！边@是好管家，這絕對有好處但也不是最有效的他們可以做的事情。“
”我們的客戶群對Graviton和Nitro的了解程度較低，“ Bala證實。當他們打電話時，通常是考慮如何相對于傳統(tǒng)處理器來考慮它?！彼幕卮鹗?，“客戶在考慮ARM與x86時，應該考慮到端到端工作負載的兼容性以及性價比?！?/p>
超越AWS的Arm
AWS不會是Arm云服務器的唯一選擇，但迄今為止，它是最重要的。
Oracle云基礎設施將在2021年初以虛擬機或裸機的形式提供Arm系統(tǒng)（使用Ampere公司的硅，帶兩個插座和160個核心），用于基礎設施任務，如代碼轉換以及運行容器和Kubernetes。
自2017年以來，微軟一直在為Azure構建帶有Arm處理器的Windows服務器系統(tǒng)。在Azure中使用的Project Olympus OCP機箱可以容納不同的Intel或Arm主板，微軟已經(jīng)測試了運行在Arm硅上的Windows服務器，包括Ampere Altra、Fujitsu和Marvell ThunderX2。
當時，大多數(shù)云工作負載都是基礎設施即服務，由于客戶希望虛擬化的應用程序很少可用于Arm架構，因此微軟沒有計劃公開提供Arm上的Windows服務器。
相反，現(xiàn)在在Azure中運行的ThunderX2 Arm服務器被用來降低運行內(nèi)部Azure基礎設施（如存儲、索引和搜索）的成本。在今年的armdevsummit大會上，技術研究員Arun Kishan（他在Windows內(nèi)核團隊工作）指出：“今天，我們在ARM64上使用Windows服務器來探索微軟內(nèi)部存儲和虛擬機托管服務。”
Bala建議，對于開發(fā)人員來說，在Arm硅上同時使用Windows和macOS可能是將來更廣泛地采用Arm服務器的轉折點?！伴_發(fā)人員將希望在本地計算機上迭代開發(fā)和構建，然后再推送到最終推送到prod的CI/CD平臺。”