Redfish 技術的白皮書

RedfisWitPaperRedfish白皮書目什么是Redfish 為什么采用REST、JSON和 為什么采用超媒體 入 基本概 操 引 集 動 模 更多概 會 冗 服 注冊 報文 PUTvs 當前的配置vs設 事 冪等 創(chuàng)建、使用、刪除：POST/GET/DELETE(非冪等性 做動作：用“Acon”屬性(非冪等性) 結(jié) 常見用 殼中 什么是RedfishRedfish是一種管理標準，它使用超媒體RESTful接口的數(shù)據(jù)模型表示法。此模型以標準的機器可讀模式表示，其消息負載以JSON來表示。協(xié)議本身ODatav4RedfishAPIAPI，可通過統(tǒng)一的接口來表示各種實現(xiàn)。RedfishAPI提供數(shù)據(jù)中心資源管理、事件處理、長時間任務以及首先，市場正在從傳統(tǒng)的數(shù)據(jù)中心環(huán)境向可擴展的解決方案轉(zhuǎn)變。可擴(而非集中式)，即由大量簡單的服務“牲畜”，而不是“寵物”目前的擴展管理缺少功能性和同構(gòu)接口。例如，IPMI功能的使用僅限于“最小公分母”命令(如PowerOn/Off/Reboot、temperaturevalue、textconsole)。平臺管理規(guī)范隨著OEM擴展增多逐漸變得零散，致使管理功能無法滿足零散客其他標準（SMASH）無法實現(xiàn)通用性要求。這是由其復雜性決定的。CLPWSWS系統(tǒng)，但它本身的I/O硬件環(huán)境正在迅速變化。將多個系統(tǒng)置于一個傳統(tǒng)“刀片”（如機殼機箱管理器）API的形式使用協(xié)議、架構(gòu)和安全模型。這些API的優(yōu)勢在于，客戶已自行研制了加速開發(fā)的工具?？蛻?無需廠商推動)需要的就是以JSON格式表示數(shù)據(jù)的RESTful協(xié)議。為什么采用REST、JSON和REST正在迅速取代SOAP成為一種主流協(xié)議。整個云生態(tài)系統(tǒng)以及WebAPI社區(qū)都在采用REST協(xié)議。REST的學習比SOAP要快得多。REST是可以直接映射HTTP（而不是嚴格意義上的協(xié)議）。WebAPI最常用的協(xié)RESTHTTP/HTTPS。因此，RESTJRRESTRESTJSON迅速成為一種現(xiàn)代數(shù)據(jù)格式。它本質(zhì)上是人可讀的，比XML更簡潔，入式管理環(huán)JSON的一大優(yōu)勢。大多數(shù)BMC已經(jīng)支持Web服務器，而通過瀏JSJSON后，Web瀏覽器可以使用直接來自其Redfish服務的數(shù)據(jù)，確保通過瀏覽器和2014年最流行的編碼語新API中使用的數(shù)據(jù)格但下面的RESTful實踐和JSON格式化的結(jié)果是不夠的。RESTful接口的種類幾乎和應用程序的種類一樣多，各種RESTful接口有其特定的資源類型、報頭和查詢選項以及結(jié)果表示法。雖然JSON提供簡單易讀的表示方法，但常見屬性（如ID、類型、鏈接等）的語義是會根據(jù)命名約定來定義的，不同服務有不OData定義了一組常見的RESTful約定，提供API之間的互操作性采用常見的OData約定來描述JSON有效負載中的模式、URL約定、通用屬RESTfulAPIRedfish為什么采用超媒體客戶需要能夠支持海量計算平臺的通用API，而非多種接口或編程方式。他們需要的是適用于獨立服務器、超級擴展和可分區(qū)甚至虛擬系統(tǒng)的通用API。單個固定URIAPI將無法完全顯示各種金屬片、內(nèi)部服務器以及相關管理器之此外，API必須兼具易用性和靈活性，以同時適應簡單系統(tǒng)和超級擴系統(tǒng)。使用URL來表示相似資源的關聯(lián)和集合，這在超媒體API中已得到證明RedfishAPI，下面RedfishAPI是基于REST和JSON的，所以您只需瀏覽器即可查看Redfish實現(xiàn)。建議您的瀏覽器支持JSON格式，以便讀取數(shù)據(jù)。大多數(shù)瀏覽器JSON為了獲得真正的“Redfsh”體驗，您可以為瀏覽器下載RESTful插件，如適用于Chrome的高級REST客戶端。這樣，您就可以設置頭部，并看到HTTP代碼等瀏覽器通常會隱藏的項目。您還可以方便地訪問“真正的”Redfish實您可以直接查看標記，或通過Web服務器查看。為此，您只需訪問一個實訪問公共模型。在R網(wǎng)站上有一個運行JSON的Web服將數(shù)據(jù)復制到您的Web服務器。您可以訪問Redfish模型，并將Mock-用該路徑提供HTML頁面。例如，您可以下載nginx，設置返回JSON格HTML根Redfish是一種超媒體API。這意味著，您可以通過其它資源返回的URL獲取所有資源。由于存在一個眾所周知的URL，所有實現(xiàn)都有一個共同的起點。此URI即針對Redfish接口V1版本的“dfis”。URL(HTTP://部分)、節(jié)點(IP)URL。因此，如果您在自己的機器上使用nginx服務器，應在瀏覽器中輸入dfis”來訪問Redfish在以上URL中，在根服務中執(zhí)行GET操作。每個URL代表一個資源。一個資源可以是一項服務、一個集合、一個實體或其他結(jié)構(gòu)。但在RESTful術語中，URI指向資源和與資源交互的客戶端。所以，當您看到“資源”URI資源格式由Schema來定義。RedfishSchema中規(guī)定了每個資源的格式，RedfishSchema以兩種格式定義：OData-SchemaJSONSchema格式。以ODataSchema格式(CSDL)定義，是為了便于通用OData工具和應用程序解析。以JSONSchema格式定義，是為了應用于其他環(huán)境，如Python腳本、JavaScript代碼和可視化。資源的結(jié)構(gòu)屬性可用作JavaScript變量。這樣可加快采用，并允許JavaScriptWeb頁面和已啟用的應用直接使用數(shù)據(jù)。URI在重新引導后不會改變，但客戶端應從/redfish/v1/啟動，并在此路徑下發(fā)現(xiàn)URI。將URI固定化是一個常見的錯誤。Redfish是超媒體API，所以各實（即使是同一廠商的實現(xiàn)）的URI是不同的。當前狀態(tài)對象可以獨立于理想狀操作包括GET、PUT、PATCH、POST、DELETE和HEAD。在未安裝高級RESTGET執(zhí)行數(shù)據(jù)檢索。POST用于創(chuàng)建資源或使用動作(詳見下文)。DELETEPATCHPUT用于完全替換資源(只有少數(shù)資源可被完全替換，詳見下文)。HEADGE類似，只是不返回主體數(shù)據(jù)，訪問Redfish實現(xiàn)的程序可使用HEAD來獲取結(jié)構(gòu)。Redfish有兩種版本，協(xié)議版本和資源模式版本。協(xié)議版本包含在URIdfis開始。這表示您正在訪問協(xié)議版本。V1URIRedfish規(guī)范V1版本。注意，因為Redfish基于ODatav4，實現(xiàn)還要求ODat協(xié)議頭(OaV)的值為4。每個資源都有資源類型定義。資源類型在帶有版本的命名空間中定義。OData類型注釋“@odata.type”來表示。類型注釋的值是資源類型URI，包括帶有版本的命名空間。所以，當您看到“@odata.type#ServiceRoot.1.0.0.ServiceRoot”時，您處理的是ServiceRoot模式1.0.0ServiceRoot類型的資源。相應的模式文件位于Redfish模式庫的/schema/v1/ServiceRoot路徑下。因此，此類型的完整URI為Root#SRoot.1..0.SRoo”JSON沒有用于引用其它資源的本地引用類型。Redfish無需客戶端咨詢模式(對于簡單操作)。因此，Redfish根據(jù)OData約定來表示對表示根據(jù)ODataURL。URI可以是絕對的或相對的。絕對URI沒有IP地址，但從dfis/開始。Chrome的高級REST客戶端等插件，您可以單擊此插件，輸入下一個GET操作的URI系統(tǒng)指典型服務器。系統(tǒng)可以是CPUCPU、內(nèi)存和其他設備。管理器指BMC(如網(wǎng)卡)。內(nèi)。因此，有一種說法叫“機殼中的機殼集合可以分頁；帶有“@odata.nextLink”戶端可以使用下一個鏈接屬性的URL值，在服務中檢索集合的下一部分?！耙谩痹乇弧癆ctions”，告知客戶可以調(diào)用哪些操作。(詳見動作章節(jié)“Oem”，具體廠商針對標準資源定義的擴展。詳見Oem章節(jié)一些屬性同時也是注釋。這些屬性以“@”開始，或包含“@”。注釋屬性OData注釋和DMTF注釋。OData注釋包含“@odata.”或“@odata.type”“@DMTF.Settings”，表示資源設置(另一常見注釋是“a。這是通用ODatav4客戶端的專用注釋該注釋由ODatav4規(guī)范定義，但往往用于其它用途提供用于解析相對引用的根URL理論上，@odata.context提供根URL(如@odata.id)，我們必須返回“規(guī)范的”元數(shù)據(jù)文檔。另外，由于@odata.type”注釋為片段而非完整URL，這些片段必須在元數(shù)據(jù)文檔中定義或引用。因為我們會解釋包含不帶版本的命名空間別名的動作，這些別名也必值為“dfishtibety”。這是告訴通用ODatav4客戶端，在$metadata中查找Systems的定義，查看Links屬性定義，其中使用REST并不能輕松完成所有操作。所以我們還會發(fā)出“動作”“下壓按鈕”操作(根據(jù)設置不同，可能重置或關閉系統(tǒng))（如固件更新或正常關機）以上是最簡單的RedfishAPI。您會發(fā)現(xiàn)數(shù)據(jù)簡單易讀，但可能想進一步通常，在沒有建立會話時，只有根路徑是可以訪問的。但如果您使用的是公共模型或本地Web模擬器運行在安全模式下，或者您在使用真正的實現(xiàn)，則需要建立會話。建立會話使用的URI也可用于不安全POST。在大多數(shù)情況下，此URIHTTPPOST創(chuàng)建會話，URI為/Redfish/v1#/Links/Sessions/@odata.id，POST/Redfish/v1/SessionService/SessionsHTTP/1.1Host:<host-path>Content-Type:application/JSON;charset=utf-8Content-Length:<computed-length>Accept:application/JSONOData-Version:4.0{"UserName":"<username>"，"Password":"<password>"}返回信息包含帶有會話令牌和位置頭的X-Auth-Token報頭Location:redfish/v1/SessionService/Sessions/1XAuth-Token:<session-auth-token>{"@odata.id":"/redfish/v1/SessionService/Sessions/1"，"@odata.type":"#Session.1.0.0.Session"，"Id":"Name":"UserSession"，"Description":"UserSession"，"UserName":"<username>"}響應X-Auth-Token報頭中的令牌字符串可用于所有后續(xù)服務請求的相同@odURL（dfisdmiistrator）執(zhí)行EEE操作。Redfish如何顯示冗余。你會發(fā)現(xiàn)一個稱作“冗余”的數(shù)組。它顯示了同一個集合中的兩個風扇Redfish@odata值指向如果是JSON指針，會有一個#方。模式也引用屬性。JSON指針值的一個示例可能是“/redfish/v1/Chassis/1/Thermal#/Fans/0”。17.相關“@odata.i”和冗余一樣，"@odata.id"屬性不一定是一個整體的資源。Redfish服務支持常見HTTP關的兩個報文頭是Accept頭(必須設置為application/json)和前面所討論的X-Aut-Token。但你會從實際的實現(xiàn)中得到更多信息，而這些信息你不會從從靜EtagsIO(緩存)。他們執(zhí)行一個If-Match語句，如PUT完成或者工具(如BIOS的配置控制臺)發(fā)生變化，每個Put中Redfish和非Redfish客戶端（Redish客戶端）之間的任何競態(tài)條件。問題是，這是個模型并不是真正的web服務，所以你看不到ETag工作If-Match。客戶端讀取/修改/獲取資源，包括當前的生成一個新的修補修改的資源，包括包含最后一個已知的Etag的If-Match如果提供的Etag不再匹配對象(讀取之后有些已經(jīng)改變)，回“Notd”。客戶端應該通過重復這些步客戶端在更新設置數(shù)據(jù)時應該包含一個Etag檢測變化并防止多客戶端競態(tài)條件。在簡單的GET、PUT/PATCH方法的模型中，客戶端可能會GETPUT或PATCH到同一個資源URI中。PUT或PATCH操作的成功是由當執(zhí)行PUT或PATCH操作后，HTTP響應包含一個HTTPPUTvs為什么PUT和PATCH操作二者都采用？在設計本規(guī)范時，當要執(zhí)行資源完SettingData屬性。事情開始變得非常復雜，特殊(即非自然)PATCH解決了這個問題。PUT總是執(zhí)行完全更換。PATCHPATCH在行業(yè)中獲得了廣泛應用。已經(jīng)得到了OpenStack和許多其他API的支持，并在許多現(xiàn)成的web服務器中可獲得。當前的配置vs設置在Redfish中，基本上有兩種類型的對象-象代表任何給定資源的當前狀態(tài)。偶爾，在某個資源中，你會看到一個稱為@DMTF.Settings”PUT和PATCH操作。它代表了資源的未來狀態(tài)。如果你看到“@DMTF.Sttings”屬性，該屬性有一個到某個資源的鏈接，以便進行更改，該更改會在下次機會如重置或重啟后被采納。如果您沒有看到設置鏈接，對象的所有PATCH操作應該立刻執(zhí)行(在沒有衍生任務的情況下)可能需要設置操作的資源的例子是像網(wǎng)卡、存儲以及BIOS設備”相反“OData.Permissions/ReadWrite”或“read-only=false”表示該屬性readonly=true”的模式可以認為是可寫的。RedfishPUT/PATCH的語義是，試圖更新非可寫屬性并不視為一個錯誤。HTTP如果響應伴隨著一個帶有擴展錯誤響應的JSON我們需要某種類型的事件機制來滿足與SNMP，IPMI和其他協(xié)議競爭。PUSH機制。PUSH事件為BMC選，因為這意味著事件一旦發(fā)送出去，事件不會在內(nèi)存中持久。類似于事件和會話，資源通過POST操作創(chuàng)建。該過程通常經(jīng)歷一個POSTAPIURI也會在該超媒體API中被發(fā)現(xiàn)。模式定義了一個注釋“RequiredOnCreate”POST中提供。冪等是RedfishDVD冪等操作是HTTPPUT和PATCH。如果客戶端第二次PUT相同的數(shù)據(jù)，資源PUT一資源是改變配置的最簡單表達。它意味著“用Y替代資源X”交互模式比這更復雜。PATCHPATCH操作可以完全配置的服務是比較理想的。Redfish使用基本的REST操作定義了三個基本的交互模冪等修改PATCHGET一個資源，修改屬性值，然后通過執(zhí)行PATCH來提交修改。PUT端可簡單地將資源設為期望的狀態(tài)。創(chuàng)建、使用、刪除：POST/GET/DELETE對一個資源執(zhí)行POST做動作：用“to屬性(非冪等性)