圖解60個(gè)網(wǎng)絡(luò)基礎(chǔ)知識(shí)點(diǎn)

遠(yuǎn)程管理卡大部分服務(wù)器都配有遠(yuǎn)程管理卡（又叫遠(yuǎn)程管理口或帶外管理卡/口）：DELL名稱(chēng)iDRAC（IntegratedDellRemoteAccessController），HUAWEI名稱(chēng)iBMC（IntelligentBaseboardManagementController），HPE名稱(chēng)iLO（IntegratedLigths-out），LENOVO名稱(chēng)IMM（integratemanagementmodule），INSPUR名稱(chēng)BMC（BaseboardManagementController）其他不再一一舉例。遠(yuǎn)程管理卡內(nèi)置芯片和迷你操作系統(tǒng)，只要服務(wù)器通電，并將遠(yuǎn)程管理卡聯(lián)網(wǎng)就可以遠(yuǎn)程控制這臺(tái)服務(wù)器，實(shí)現(xiàn)服務(wù)遠(yuǎn)程安裝操作系統(tǒng)，軟件升級(jí)，開(kāi)關(guān)機(jī)等操作，避免人工去機(jī)房進(jìn)行現(xiàn)場(chǎng)操作。遠(yuǎn)程管理卡協(xié)議遠(yuǎn)程管理卡常見(jiàn)的運(yùn)維管理協(xié)議包含：ICMP-PING，SNMP-Get，SNMP-Trap，Syslog，HTTP-REST/Redfish，Telemetry，IPMI，CLI等；協(xié)議常見(jiàn)用途如下：ICMP-PING：可以通過(guò)此協(xié)議探測(cè)遠(yuǎn)程管理卡存活狀態(tài)；此管理卡宕機(jī)不代表服務(wù)器宕機(jī)，但是為了運(yùn)維管理必須要保證它運(yùn)行正常。SNMP-Get：通過(guò)此協(xié)議，外部監(jiān)控系統(tǒng)主動(dòng)到帶外管理卡獲取服務(wù)器的信息，常見(jiàn)的CPU/內(nèi)存/磁盤(pán)/電源/風(fēng)扇/溫濕度都可以通過(guò)此協(xié)議獲取，可以作為入門(mén)級(jí)別的服務(wù)器監(jiān)控方案，簡(jiǎn)單、易用；Zabbix用戶可以在下載到眾多廠商的監(jiān)控模版。SNMP-Trap/Syslog：此兩種協(xié)議都是帶外管理卡主動(dòng)的向外部發(fā)送告警信息，和郵件告警異曲同工的作用。數(shù)據(jù)中心的硬件有可能不支持SNMP-Get協(xié)議，但是通常都支持SNMP-Trap/Syslog/Email的告警外發(fā)。此類(lèi)協(xié)議接入成本極低，輔助運(yùn)維監(jiān)控價(jià)值高，通過(guò)1分鐘的簡(jiǎn)單配置，就可以實(shí)現(xiàn)所有硬件故障告警，如果必要還能收集審計(jì)日志做UEBA。HTTP-REST/Redfish：當(dāng)前最新的主流的服務(wù)器運(yùn)維管理協(xié)議，以HTTP/JSON的方式提供，非常方便開(kāi)發(fā)人員進(jìn)行基礎(chǔ)架構(gòu)即代碼編程（IaC）。也是我們非常推薦使用的協(xié)議，后面?zhèn)戎剡M(jìn)行細(xì)講。Telemetry：遙測(cè)協(xié)議，當(dāng)前CNCF主推協(xié)議。外部監(jiān)控系統(tǒng)訂閱特定組件，服務(wù)器將此部件信息進(jìn)行主動(dòng)外發(fā)，監(jiān)控指標(biāo)間隔可以精確到毫秒，捕獲性能毛刺數(shù)據(jù)；非常適合銀行/證券對(duì)監(jiān)控指標(biāo)采樣周期有非常高的業(yè)務(wù)場(chǎng)景；但是在服務(wù)器領(lǐng)域支持比較少，服務(wù)器DataCenter版本有非常細(xì)的支持，后續(xù)會(huì)在為大家進(jìn)行此協(xié)議專(zhuān)門(mén)分享。此當(dāng)前用的少，監(jiān)控工具支持的少，落地實(shí)施難度高。IPMI：此協(xié)議服務(wù)器廠商基本上都支持，上一代的服務(wù)器管理標(biāo)準(zhǔn)協(xié)議，此協(xié)議不僅能夠做監(jiān)控而且能夠進(jìn)行自動(dòng)化操作。但是由于功能缺失，性能損耗高，安全漏洞多等眾多問(wèn)題IPMI也在2015年公布2.0v1.1標(biāo)準(zhǔn)后，不再更新，被Redfish永久代替，Intel也宣布不再維護(hù)，號(hào)召大家轉(zhuǎn)戰(zhàn)Redfish。CLI：命令行管理接口，通常做服務(wù)器批量配置，做監(jiān)控巡檢的時(shí)候使用；但是如果通過(guò)此協(xié)議和Zabbix等外部監(jiān)控系統(tǒng)集成監(jiān)控，技術(shù)難度高，安全隱患也多，不推薦使用。Redfish協(xié)議：1、協(xié)議產(chǎn)生背景隨著時(shí)代發(fā)展，IPMI規(guī)范的局限性也越發(fā)明顯。由于IPMI更多的是單點(diǎn)的服務(wù)，所以其擴(kuò)展性（ScaleOut）較差，由于此協(xié)議在非常早年代制定，這導(dǎo)致其在開(kāi)始設(shè)計(jì)的時(shí)候受限于當(dāng)時(shí)的現(xiàn)狀，對(duì)安全性考慮有所欠缺。在爆出安全漏洞后，IPMI2.0增加了增強(qiáng)身份認(rèn)證（RAKP+、SHA-1等），但其后更多別的漏洞爆出。業(yè)界呼喚一種新的，重新設(shè)計(jì)的新標(biāo)準(zhǔn)，能一勞永逸的解決這些問(wèn)題，于是Redfish應(yīng)運(yùn)而生，IPMI也在2015年公布2.0v1.1標(biāo)準(zhǔn)后，不再更新，被Redfish永久代替，Intel也宣布不再維護(hù)，號(hào)召大家轉(zhuǎn)戰(zhàn)Redfish。2、Redfish?協(xié)議簡(jiǎn)介協(xié)議官方原文：DMTF’sRedfish?isastandarddesignedtodeliversimpleandsecuremanagementforconverged,hybridITandtheSoftwareDefinedDataCenter(SDDC).Bothhumanreadableandmachinecapable,RedfishleveragescommonInternetandwebservicesstandardstoexposeinformationdirectlytothemoderntoolchain.大概意思就是它是一個(gè)標(biāo)準(zhǔn)、簡(jiǎn)單、安全的管理現(xiàn)代化數(shù)據(jù)中心協(xié)議。這個(gè)協(xié)議不僅機(jī)器能懂，管理機(jī)器夠用；而且方便人去閱讀、使用這個(gè)協(xié)議。Redfish規(guī)范的第一個(gè)版本于2015年8月由分布式管理任務(wù)組（DistributedManagementTaskForce，DMTF）發(fā)布，此協(xié)議是一個(gè)開(kāi)放的行業(yè)標(biāo)準(zhǔn)規(guī)范，為可擴(kuò)展平臺(tái)硬件提供簡(jiǎn)單，現(xiàn)代和安全的管理功能。它是一個(gè)超媒體API，所以它能夠通過(guò)一個(gè)一致的接口來(lái)表示各種實(shí)現(xiàn)。它有管理數(shù)據(jù)中心資源、處理事件、長(zhǎng)期任務(wù)和發(fā)現(xiàn)的機(jī)制?；赗edfish統(tǒng)一的管理接口規(guī)范普及之后，未來(lái)能夠有效減少不同服務(wù)器硬件管理接口帶來(lái)的大量適配開(kāi)發(fā)和測(cè)試工作。目前，Redfish標(biāo)準(zhǔn)由DMTF組織的SPMF論壇維護(hù)。Redfish是一種基于HTTPs服務(wù)的管理標(biāo)準(zhǔn)，利用RESTful接口實(shí)現(xiàn)設(shè)備管理。每個(gè)HTTPs操作都以UTF-8編碼的JSON格式（JSON是一種key-value對(duì)的數(shù)據(jù)格式）提交或返回一個(gè)資源或結(jié)果，就像Web應(yīng)用程序向?yàn)g覽器返回HTML一樣。該技術(shù)具有降低開(kāi)發(fā)復(fù)雜性，易于實(shí)施、易于使用而且，提供了可擴(kuò)展性優(yōu)勢(shì)，為設(shè)計(jì)靈活性預(yù)留了空間。Redfish=RESTAPI+軟件定義的服務(wù)器(數(shù)據(jù)模型)。Redfish在標(biāo)準(zhǔn)訂立之初，設(shè)定了以下目標(biāo)：（1）安全（2）高可擴(kuò)展管理（Scalable）（3）人類(lèi)可讀數(shù)據(jù)界面（Humanreadabledata）（4）基于現(xiàn)有硬件可實(shí)現(xiàn)DMTF官網(wǎng)上面主流的服務(wù)器廠商都在積極響應(yīng)這個(gè)協(xié)議，但它畢竟是一個(gè)協(xié)議和標(biāo)準(zhǔn)，具體的實(shí)現(xiàn)、支持程度還非常依賴具體的服務(wù)器廠商。目前很多服務(wù)器廠商支持，但是支持的顆粒度不夠，標(biāo)準(zhǔn)實(shí)現(xiàn)也存在非常多的不規(guī)范問(wèn)題。3、Redfish協(xié)議結(jié)構(gòu)：DMTF組織定義的Redfish資源示意圖，我們可以看到3大分支：（1）Systems（系統(tǒng)的邏輯視圖）（2）Chassis（系統(tǒng)的物理視圖）（3）Managers（BMC功能）其實(shí)就是在HTTP-Restful的基礎(chǔ)上在進(jìn)一步強(qiáng)制定義特定的URL路徑和參數(shù)約定固定服務(wù)器對(duì)象。以iDRAC遠(yuǎn)程管理卡為例，Redfish僅需要一個(gè)有登錄權(quán)限的賬號(hào)，直接通過(guò)瀏覽器訪問(wèn)iDRAC管理地址對(duì)應(yīng)的URL路徑即可（監(jiān)控的時(shí)候推薦使用只讀賬號(hào)）。部分常見(jiàn)場(chǎng)景的API示例如下：物理服務(wù)器運(yùn)維監(jiān)控建議服務(wù)器領(lǐng)域有眾多的廠商，同一個(gè)廠商有不同的型號(hào)，即使同一廠商/同一型號(hào)，也會(huì)因?yàn)椴煌某鰪S時(shí)間，有不同版本的維碼。監(jiān)控領(lǐng)域的監(jiān)控指標(biāo)兼容性、顆粒度問(wèn)題和其他領(lǐng)域一樣，問(wèn)題嚴(yán)峻，即使在這個(gè)細(xì)分垂直領(lǐng)域，沒(méi)有“銀彈”，沒(méi)有完美的監(jiān)控系統(tǒng)。我們?cè)诼涞胤?wù)器領(lǐng)域監(jiān)控的時(shí)候，需要對(duì)不同的廠商、設(shè)備舊新程度、監(jiān)控協(xié)議的支持程度、項(xiàng)目落地時(shí)間長(zhǎng)短、企業(yè)愿意投入的人員/經(jīng)費(fèi)等多方面進(jìn)行考量。做好服務(wù)器的運(yùn)維管理，不論監(jiān)控還是自動(dòng)化，需要對(duì)服務(wù)器基礎(chǔ)知識(shí)有個(gè)較為全面的了解?？梢詮姆?wù)器基礎(chǔ)部件入手，按企業(yè)現(xiàn)狀逐步建設(shè)。階段一：如果沒(méi)有外部獨(dú)立的監(jiān)控系統(tǒng)?？梢栽诜?wù)器內(nèi)部配置郵件告警即可。此方案落地幾乎沒(méi)有任何成本，簡(jiǎn)單、便捷，可以有效的實(shí)現(xiàn)硬件故障告警。此方案有可能因?yàn)榕渲玫母婢燃?jí)較低、告警內(nèi)容勾選項(xiàng)目較多，導(dǎo)致郵件告警頻繁，出現(xiàn)“狼來(lái)了”的問(wèn)題。階段二：企業(yè)有獨(dú)立的監(jiān)控系統(tǒng)。配置SNMPTrap或者Syslog，此協(xié)議和服務(wù)器直接發(fā)送郵件告警，內(nèi)容一致；但是通過(guò)此方案，監(jiān)控系統(tǒng)可以有效的進(jìn)行告警收斂、屏蔽，告警分析，告警發(fā)送，提升告警的認(rèn)知效率。階段三：企業(yè)有獨(dú)立的監(jiān)控系統(tǒng)，有一定的動(dòng)手能力。以Zabbix為例，運(yùn)維人員，可以通過(guò)下載服務(wù)器的SNMP模版。通過(guò)服務(wù)器開(kāi)啟SNMP協(xié)議，在Zabbix系統(tǒng)創(chuàng)建Host然后掛載模版的方式，就可以快速、免費(fèi)建立比較專(zhuān)業(yè)的服務(wù)器監(jiān)控。階段四：企業(yè)有獨(dú)立的監(jiān)控系統(tǒng)，且動(dòng)手能力強(qiáng)?？梢酝ㄟ^(guò)Redfish協(xié)議，進(jìn)行定制開(kāi)發(fā)，實(shí)現(xiàn)個(gè)性化的運(yùn)維監(jiān)控、運(yùn)維分析。譬如通常情況下，通過(guò)SNMPGet只能拿到硬件的狀態(tài)，但是對(duì)于SSD，我們不僅需要拿到硬件的狀態(tài)，還需要知道SSD的廠商、擦寫(xiě)比例，拿到這個(gè)數(shù)值，才能夠?qū)?shù)據(jù)中心百臺(tái)以上規(guī)模服務(wù)器SSD信息進(jìn)行批量導(dǎo)出。我們以服務(wù)器獲取磁盤(pán)的RedfishURL舉例如下：現(xiàn)代化數(shù)據(jù)中心也講究“ESG”，也要順應(yīng)“碳中和碳達(dá)峰”這樣的人類(lèi)宏偉愿景，而不是掛在嘴上和我們一線運(yùn)維不相關(guān)，我們一線技術(shù)人員也可以有歷史使命感、情懷；那么同樣能耗的服務(wù)器承載的業(yè)務(wù)運(yùn)行密度就是一個(gè)非常重要的服務(wù)器采購(gòu)考量指標(biāo)，尤其是對(duì)于中大規(guī)模企業(yè)，細(xì)微的電量消耗節(jié)約在數(shù)量和時(shí)間的累加下必定是一個(gè)非?？捎^的耗電量數(shù)字。那么每一臺(tái)服務(wù)器、每個(gè)機(jī)柜單位的電源功耗就非常有必要把這個(gè)指標(biāo)拿出來(lái)，做一個(gè)細(xì)化的統(tǒng)計(jì)分析。我們還是以之前服務(wù)器舉例，Redfish獲取電源功耗指標(biāo)URL如下：除了我們DIY的方案，那么同一個(gè)廠商，針對(duì)其自我出廠的多臺(tái)設(shè)備，必然會(huì)擁有其原廠專(zhuān)業(yè)管理軟件方案。但是我們也看到這類(lèi)原廠方案，往往是收費(fèi)的，即使不收費(fèi)，對(duì)異構(gòu)品牌的支持顆粒度比較粗，或者沒(méi)有。建立一套自主可控的、開(kāi)放的、向前、向后兼容的運(yùn)維監(jiān)控方案是每個(gè)企業(yè)的理想選擇，這里尤其推薦老牌的監(jiān)控軟件Zabbix/ELK；通過(guò)Redfis