|
新聞中心
當(dāng)前位置：網(wǎng)站首頁(yè) > 新聞中心
多云環(huán)境下，獲取操作可見(jiàn)性的方法
多云通常被認(rèn)為是企業(yè)的一個(gè)進(jìn)化步驟，是企業(yè)從單一云平臺(tái)的起始階段走向多云產(chǎn)品的“最佳”方法。而各種因素決定了這一點(diǎn)：對(duì)于某些企業(yè)來(lái)說(shuō)，需要平臺(tái)特定功能的工作負(fù)載的多樣性。對(duì)于其他企業(yè)來(lái)說(shuō)，這是一個(gè)演變的過(guò)程，也可能是并購(gòu)的結(jié)果。無(wú)論企業(yè)由于什么原因而選擇在多云環(huán)境下運(yùn)行，它確實(shí)會(huì)帶來(lái)一些復(fù)雜性，如果不仔細(xì)管理，可能會(huì)偏離其采用多云策略實(shí)現(xiàn)成本節(jié)約的目標(biāo)，并降低其性能。
這就是為什么可視度如此重要的原因。但是，就像采用多云一樣，為了獲得業(yè)務(wù)可見(jiàn)性，需要改變數(shù)據(jù)集(除了本地網(wǎng)絡(luò)之外，還要測(cè)量廣域網(wǎng)、互聯(lián)網(wǎng)、云計(jì)算和SaaS提供商的健康狀況和性能)。以下將分析與多云部署相關(guān)的一些關(guān)鍵術(shù)語(yǔ)，解釋為什么傳統(tǒng)的可視性方法在云端方面的不足，并探索獲取多云操作可見(jiàn)性所需的方法。
混合云與多云
混合云通常是指現(xiàn)有傳統(tǒng)數(shù)據(jù)中心的組合，其中一些服務(wù)是從云中使用的。如今的大多數(shù)應(yīng)用程序都是混合的，因?yàn)樗鼈兪褂靡粋€(gè)或多個(gè)基于API的外部服務(wù)，無(wú)論是用于身份驗(yàn)證、付款還是物流。隨著應(yīng)用程序被霧化成其組成服務(wù)并僅通過(guò)結(jié)構(gòu)化API調(diào)用進(jìn)行通信，可以分別定位和縮放每個(gè)組件。因此，雖然某些核心資產(chǎn)和功能可能仍然存在，但企業(yè)可以獨(dú)立擴(kuò)展無(wú)狀態(tài)組件，并讓它們駐留在距離用戶更近的云中。
另一方面，多云是指將企業(yè)的內(nèi)部部署數(shù)據(jù)中心與兩家或兩家以上云計(jì)算供應(yīng)商結(jié)合使用。包括任何類型的外部云提供，例如IaaS、PaaS或SaaS。這是一個(gè)更復(fù)雜的環(huán)境，具有多個(gè)基礎(chǔ)平臺(tái)，每個(gè)平板都有自己的編排習(xí)慣。這里的目標(biāo)是讓成本經(jīng)濟(jì)性和最佳組合決定工作負(fù)載的位置。從管理的角度來(lái)看，企業(yè)正在處理一個(gè)難以預(yù)測(cè)的程度和變化速度，這可能是一個(gè)挑戰(zhàn)。此外，企業(yè)的呼叫流程現(xiàn)在包含更多的排列組合，這使得性能調(diào)整和故障排除特別復(fù)雜。
微服務(wù)API
微服務(wù)架構(gòu)已經(jīng)流行了很多年，它已經(jīng)從根本上改變了新的應(yīng)用程序的構(gòu)建方式。Uber是主要運(yùn)行在微服務(wù)生態(tài)系統(tǒng)上的一個(gè)很好的示例。Uber依靠第三方API進(jìn)行映射、支付、通知和電話。這些API中的每一個(gè)都可能進(jìn)一步依賴于其他后端API。因此，每當(dāng)乘客乘坐Uber時(shí)，需要多個(gè)API流，云計(jì)算服務(wù)和網(wǎng)絡(luò)路徑才能正常工作，以便搭車回家。
這是IT組織以前從未處理過(guò)的復(fù)雜程度。當(dāng)一切正常時(shí)，其復(fù)雜性并不明顯，但故障時(shí)對(duì)于故障排除來(lái)說(shuō)非常復(fù)雜。一個(gè)很好的例子就是最近的AWS停機(jī)中斷。從基礎(chǔ)設(shè)施的角度來(lái)看，AWS云服務(wù)的電力中斷很小，系統(tǒng)恢復(fù)的時(shí)間相當(dāng)短。但是，在初始事件發(fā)生后的幾個(gè)小時(shí)內(nèi)，依靠AWS Direct Connect進(jìn)行后端數(shù)據(jù)流的應(yīng)用程序仍然失效。其中包括Atlassian，Slack和Twilio在內(nèi)的許多應(yīng)用程序和服務(wù)，其提供者未能考慮其多個(gè)云平臺(tái)之間隱藏的依賴關(guān)系。
一般來(lái)說(shuō)，云計(jì)算和互聯(lián)網(wǎng)面臨的挑戰(zhàn)之一是缺乏可見(jiàn)性。許多傳統(tǒng)的網(wǎng)絡(luò)監(jiān)控工具都依賴于簡(jiǎn)單網(wǎng)絡(luò)管理協(xié)議(SNMP)、流量或數(shù)據(jù)包捕獲等技術(shù)。所有這些都需要對(duì)構(gòu)成數(shù)據(jù)中心的服務(wù)器、交換機(jī)、防火墻和路由器進(jìn)行某種級(jí)別的特權(quán)訪問(wèn)。這些都不能用于IaaS或PaaS服務(wù)。因此，企業(yè)已習(xí)慣于將云計(jì)算看作是一個(gè)黑盒子，隱藏在隱形外衣之下。
這種方法不適用于單個(gè)云平臺(tái)或混合云，它當(dāng)然不適用于多云基礎(chǔ)設(shè)施。路徑組合的數(shù)量隨著云平臺(tái)的數(shù)量而有序地增加。這些路徑中的每一條都有許多不可預(yù)測(cè)的因素。因此企業(yè)的風(fēng)險(xiǎn)增加了數(shù)量級(jí)。那么就不能繼續(xù)把這些云平臺(tái)當(dāng)成黑匣子，那么將有什么選擇?
云計(jì)算沒(méi)有遮掩
一些云服務(wù)商提供他們自己的網(wǎng)絡(luò)可見(jiàn)性解決方案，但是，這并不能為企業(yè)提供完整的端到端圖片，其中包括外部相關(guān)性。采用多云策略，隨著工作負(fù)載的移動(dòng)，企業(yè)的可見(jiàn)性解決方案需要遵循資源，而不管其位于何處。那么怎么能做到這一點(diǎn)?有一些主動(dòng)監(jiān)控技術(shù)使用特殊的儀器化應(yīng)用程序調(diào)用來(lái)了解應(yīng)用程序可用性和響應(yīng)時(shí)間，以及用于交付這些應(yīng)用程序的底層網(wǎng)絡(luò)和云計(jì)算基礎(chǔ)設(shè)施。這不需要來(lái)自云計(jì)算基礎(chǔ)設(shè)施的任何特權(quán)信息，因此可以是云計(jì)算和供應(yīng)商不可知的。在通常情況下，所有這些都是資源的目標(biāo)URL。
云端沒(méi)有穩(wěn)定狀態(tài)。所有的IaaS和PaaS供應(yīng)商都大量使用devops和自動(dòng)化工具，所以變化迅速發(fā)生，無(wú)需事先通知。與此同時(shí)，多線程部署通常使用容器化和自動(dòng)化服務(wù)，如Kubernetes將工作負(fù)載轉(zhuǎn)移到最佳云平臺(tái)。在這個(gè)瞬息萬(wàn)變的世界中，企業(yè)需要可持續(xù)的可見(jiàn)性來(lái)反映應(yīng)用程序交付路徑中的變化，以便為其提供完整的最新視圖。
|
