先智數(shù)據(jù)長(zhǎng)期致力于基于AI的主動(dòng)管理來(lái)解決混合多云環(huán)境中的復(fù)雜性并為客戶帶來(lái)創(chuàng)新價(jià)值。Ming還展示了Federator.ai與Datadog Monitoring Services集成的相關(guān)產(chǎn)品演示。

先智數(shù)據(jù)是家怎樣的公司？

先智數(shù)據(jù)團(tuán)隊(duì)由一群在IT管理，基礎(chǔ)架構(gòu)和云運(yùn)營(yíng)，數(shù)據(jù)科學(xué)和AI技術(shù)方面具有專業(yè)知識(shí)的業(yè)內(nèi)資深人士組成。我們的共同愿景是，IT基礎(chǔ)架構(gòu)和云服務(wù)的目標(biāo)是確?？梢詽M足應(yīng)用需求，并且必須積極主動(dòng)、預(yù)先部署以避免事后才反思。如果我們能夠了解工作負(fù)載行為并在適當(dāng)?shù)臅r(shí)間用適當(dāng)數(shù)量的資源來(lái)匹配需求，則可以使操作的復(fù)雜性最小化，節(jié)省成本以及優(yōu)化性能。

這樣做的理由是什么？

管理現(xiàn)有IT基礎(chǔ)設(shè)施和云運(yùn)營(yíng)都是非常被動(dòng)的任務(wù)，需要很多人的創(chuàng)造力。當(dāng)我們引入容器化的應(yīng)用，DevOps操作和新的多云范例時(shí)，情況變得更糟。此外，工作負(fù)載大多是動(dòng)態(tài)的。跟蹤，管理和優(yōu)化具有挑戰(zhàn)性，必須進(jìn)行巨大的更改。

這里先智數(shù)據(jù)（ProphetStor）CEO，Eric Chen還分享了一個(gè)小故事：

多年前，我在一家聯(lián)合創(chuàng)辦的公司工作，那時(shí)我們派了一組工程師在遠(yuǎn)程客戶站點(diǎn)上部署軟件定義存儲(chǔ)解決方案，花了兩周時(shí)間完成，也贏得了要求嚴(yán)苛的客戶稱贊，是公司又一個(gè)新的成功案例。

一周后，我去拜訪了一同處理這位客戶案例的SI合作伙伴，沒有料想的慶功宴，那家公司CEO告訴我，Eric，這個(gè)項(xiàng)目很棒，你的技術(shù)團(tuán)隊(duì)很厲害，客戶很滿意，我們賺了很多錢。但是，我想立即終止我們的分銷商合同。

我很震驚。得到的回答是，“我的團(tuán)隊(duì)與您的技術(shù)團(tuán)隊(duì)一起工作，他們要精疲力竭地了解配置的細(xì)節(jié)，需要在每個(gè)步驟中都非常小心，連接電纜，獲取正確的尺寸信息，密切關(guān)注應(yīng)用的行為，而且很多時(shí)候，他們需要猜測(cè)滿足SLA所需的資源。存儲(chǔ)管理只和空間/容量有關(guān)，而與性能無(wú)關(guān)，無(wú)法解決我在操作中看到的主要問(wèn)題，用你的產(chǎn)品機(jī)會(huì)成本太高了，必須有一種更自動(dòng)化和智能的方法才行?！?/p>

多年后，當(dāng)我離開以前的公司后，遇到了麻省理工學(xué)院教授同時(shí)也是企業(yè)家的Sunny Siu。開始談?wù)搶?yīng)用意識(shí)引入存儲(chǔ)管理，然后再引入IT和云。2012年，AI仍處于休眠狀態(tài)。我們決定建立一家公司來(lái)引入AI/機(jī)器學(xué)習(xí)技術(shù)管理應(yīng)用和資源，Sunny也成為投資者和公司總裁。我們的工作就是——借助AI技術(shù)以及Kubernetes，尤其是OpenShift中的主動(dòng)管理方式以及如何在多云環(huán)境中進(jìn)行性能和成本優(yōu)化。

如你所見，我們專注于Kubernetes/OpenShift平臺(tái)的次日運(yùn)營(yíng)（ Day 2 Operation，算是新概念。簡(jiǎn)單來(lái)說(shuō)就是當(dāng)你完成初期的設(shè)施搭建，配置，測(cè)試并實(shí)現(xiàn)運(yùn)行后，再對(duì)平臺(tái)進(jìn)行絕對(duì)優(yōu)化，監(jiān)視利用率，確保其可用性和成本優(yōu)化），因?yàn)槲覀冎塾谶\(yùn)營(yíng)自動(dòng)化和效率。我們認(rèn)為，這些會(huì)是為了讓大眾廣泛接受這個(gè)平臺(tái)所需解決的主要問(wèn)題。

用戶角色擔(dān)當(dāng)

由于我們正在開發(fā)一種解決效率和成本問(wèn)題的產(chǎn)品，因此用戶角色是運(yùn)營(yíng)經(jīng)理，CIO，CFO和CEO。 Kubernetes具有敏捷，高性能和靈活性。但管理也非常復(fù)雜。盡管如此，平臺(tái)用途大于復(fù)雜性，因此，流行性迅速上升。

不過(guò)，簡(jiǎn)化部署至關(guān)重要，是第一階段采用產(chǎn)品的重點(diǎn)。對(duì)我而言，Kubernetes和容器范例的最大好處是它向管理層提供的開放性和透明性?，F(xiàn)在，我們能夠觀察到操作的詳細(xì)信息，從應(yīng)用到容器級(jí)別，再到基礎(chǔ)架構(gòu)，云操作，硬件組件，甚至CPU內(nèi)核和DMA功能。

另一方面，對(duì)IT系統(tǒng)（如數(shù)據(jù)庫(kù)，MongoDB，Postgress）和虛擬化平臺(tái)（如Kubernetes），操作系統(tǒng)RHEL和硬件比如Intel或AMD CPU）都在提供產(chǎn)品方面表現(xiàn)出色，但都對(duì)水平層級(jí)施加了自我限制。結(jié)果，超出該特定層的任何內(nèi)容，他們都選擇不查看或優(yōu)化。

也就是說(shuō)，它們傾向于啟發(fā)式和通用型。在Kubernetes/OpenShift平臺(tái)中，自我限制是對(duì)創(chuàng)新的真正浪費(fèi)。我們應(yīng)該利用整個(gè)系統(tǒng)的透明度，從應(yīng)用到系統(tǒng)，再到資源。然后引入一個(gè)好的編排器來(lái)匹配從應(yīng)用到資源供應(yīng)的需求。這就是為什么我們要做Federator.ai。

Kubernets/多云/OpenShift的市場(chǎng)格局

在最近的市場(chǎng)發(fā)展中，可以看到提供監(jiān)控服務(wù)或解決方案的供應(yīng)商變得非常受歡迎。工具包括Datadog，Dynatrace，Sysdig，Instana，SignalFX等。它們有助于解決Kubernetes和云平臺(tái)中的“可視性”問(wèn)題。幾年前，容器監(jiān)控解決方案還不夠成熟。而且當(dāng)你遷移數(shù)據(jù)到云時(shí)，除非訂閱了監(jiān)控服務(wù)，否則就沒有在云上運(yùn)行的應(yīng)用和系統(tǒng)的可見性。因此，我們認(rèn)為監(jiān)控市場(chǎng)在不久的將來(lái)仍將有很高的需求。一個(gè)輔助證明是幾周前，IBM剛剛收購(gòu)了Instana。

接下來(lái)要解決的問(wèn)題是安全性。我們可以在這類市場(chǎng)中看到一些活躍的供應(yīng)商，例如Sysdig。

我們認(rèn)為，下一個(gè)大趨勢(shì)是涉及Day 2 Operation的第2階段采用。在將工作負(fù)載部署到云之后，管理員將在性能和成本方面面臨下一個(gè)運(yùn)營(yíng)效率問(wèn)題。

很多經(jīng)理在收到云賬單時(shí)大為震驚。我本人就是受害者。我認(rèn)為，如果沒有良好的計(jì)劃和對(duì)云計(jì)算的操作模型以及如何收費(fèi)的正確理解，應(yīng)用的性能以及在云上運(yùn)行工作負(fù)載的成本可能不會(huì)達(dá)到預(yù)期。此外，多云環(huán)境還帶來(lái)了另一種復(fù)雜性——選擇最佳的定價(jià)計(jì)劃來(lái)滿足工作負(fù)載的SLA?，F(xiàn)在，你還可以擁有多個(gè)云服務(wù)提供商。除此之外，一個(gè)服務(wù)提供商的每個(gè)數(shù)據(jù)中心都可能針對(duì)同一實(shí)例提供非常不同的定價(jià)。

因此，我們相信先智數(shù)據(jù)通過(guò)提供針對(duì)自動(dòng)化，性能和運(yùn)營(yíng)成本的基于AI的主動(dòng)管理解決方案可以為社區(qū)做出貢獻(xiàn)。我們的解決方案與其他廠商的主要區(qū)別在于我們考慮了全棧式操作。

圖1：Federator.ai –云自動(dòng)化運(yùn)行解決方案

圖2：為什么需要應(yīng)用感知操作：我們的答案

圖3：感知應(yīng)用的操作：自動(dòng)化，性能和成本

圖4：應(yīng)用剖析結(jié)構(gòu)和多層關(guān)聯(lián)：靜態(tài)拓?fù)浜蛣?dòng)態(tài)關(guān)聯(lián)

圖5：工作負(fù)載預(yù)測(cè)：捕獲應(yīng)用動(dòng)態(tài)

了解工作負(fù)載變化能幫助我們進(jìn)行良好的資源規(guī)劃。

Federator.ai允許用戶觀察Kubernetes或OpenShift集群中應(yīng)用/資源在不同層級(jí)的工作負(fù)載預(yù)測(cè)。

通過(guò)對(duì)不同資源層使用不同的預(yù)測(cè)粒度和預(yù)測(cè)結(jié)果，用戶可以更好地進(jìn)行資源規(guī)劃，以優(yōu)化其性能和資源利用率。

圖6：工作負(fù)載預(yù)測(cè)現(xiàn)場(chǎng)演示

在大多數(shù)情況下，CPU或內(nèi)存使用情況并不是衡量實(shí)際工作負(fù)載的良好指標(biāo)。以Kafka分布式日志系統(tǒng)為例；你有很多Kafka生產(chǎn)者在一天內(nèi)不同時(shí)間以不同的價(jià)格向Kafka代理商發(fā)送消息。代理商要確保自己有足夠的Kafka用戶的同時(shí)，還要及時(shí)接收和處理這些消息，不會(huì)造成大的延遲。 Kafka使用者的CPU使用率并不是最好的工作負(fù)載指標(biāo)。在這種情況下，來(lái)自生產(chǎn)者消息的生產(chǎn)率是正確的工作負(fù)載指標(biāo)。借助Federator.ai預(yù)測(cè)適當(dāng)工作負(fù)載的能力，我們可以動(dòng)態(tài)擴(kuò)展Kafka使用人數(shù)，以便在適當(dāng)?shù)臅r(shí)間為適當(dāng)數(shù)量的使用者提供服務(wù)。

當(dāng)我們可以預(yù)測(cè)到動(dòng)態(tài)工作負(fù)載時(shí)就是能提供操作的絕佳示例。

圖7：感知應(yīng)用的工作負(fù)載預(yù)測(cè)和自動(dòng)擴(kuò)展或收縮的實(shí)時(shí)演示

當(dāng)我們完全了解未來(lái)工作負(fù)載并將其用于適當(dāng)資源時(shí)，我們將獲得更多的收益。比如你可能正在考慮將當(dāng)前的本地集群遷移到公有云。了解未來(lái)的工作負(fù)載能幫助你選擇最經(jīng)濟(jì)高效的正確實(shí)例，并同時(shí)處理集群的工作負(fù)載。

如果你已經(jīng)是AWS的客戶，仍然可以用Federator.ai的分析來(lái)獲取建議，說(shuō)明哪些地區(qū)的實(shí)例類型可以降低成本。Federator.ai為您提供基于按需，保留甚至SPOT實(shí)例的成本估算的不同方法。

圖8：多云成本分析實(shí)時(shí)演示

Federator.ai可以進(jìn)一步分析應(yīng)用的使用情況和預(yù)測(cè)，以在下一個(gè)級(jí)別了解不同應(yīng)用上的費(fèi)用。

在此示例中，你可以看到集群超額配置時(shí)，系統(tǒng)在空閑狀態(tài)上浪費(fèi)了多少。 Federator.ai為你提供有關(guān)哪些實(shí)例類型和集群大小的建議，這些實(shí)例可以通過(guò)工作負(fù)載預(yù)測(cè)來(lái)優(yōu)化成本。

崔歡歡

<abbr id="1ipbk"><li id="1ipbk"></li></abbr>