在過去幾年中，IT基礎(chǔ)設(shè)施已經(jīng)向混合和多云模式發(fā)展。而對于那些已經(jīng)投資OpenStack私有云的企業(yè)來說，可有多種選擇來為混合云或多云部署做好準(zhǔn)備。

多云的好處和挑戰(zhàn)

盡管從安全性和性能要求上看，部署私有云仍舊是更合理的選擇，但企業(yè)同時使用多個公有云的情況依然存在。

多云計(jì)算使企業(yè)能夠利用各種云服務(wù)，而不用管供應(yīng)商是誰。例如，用戶可以選擇谷歌進(jìn)行高性能計(jì)算，選擇AWS的廣泛功能組合，也可以使用甲骨文提供的數(shù)據(jù)庫即服務(wù)產(chǎn)品。

但要在多云部署中取得成功，IT團(tuán)隊(duì)必須改進(jìn)管理實(shí)踐。

首先，要在云平臺之間遷移應(yīng)用程序，團(tuán)隊(duì)需要仔細(xì)編排工作負(fù)載并“翻譯”虛擬網(wǎng)絡(luò)配置文件。像Ansible這樣的工具可以簡化這個過程，特別是對于需要在OpenStack和主要公有云之間遷移的工作負(fù)載而言。

業(yè)界也在努力為VM和容器進(jìn)行鏡像的標(biāo)準(zhǔn)化，這將進(jìn)一步簡化應(yīng)用程序的可移植性。

盡管如此，由于云供應(yīng)商擁有不同的服務(wù)和API集合，IT團(tuán)隊(duì)有責(zé)任確保他們的應(yīng)用程序與他們使用的所有平臺都兼容。

然后，團(tuán)隊(duì)?wèi)?yīng)該將重點(diǎn)轉(zhuǎn)移到數(shù)據(jù)管理上，以避免多云模式中的性能瓶頸。

管理混合多云部署的數(shù)據(jù)

要讓OpenStack為混合或多云模型做好準(zhǔn)備，請記住，Swift 存儲已經(jīng)有自己的專有接口，這個接口超越了大多數(shù)云供應(yīng)商使用的 Amazon Simple Storage Service(S3)REST 構(gòu)造。

如果你希望你的應(yīng)用程序使用本地 OpenStack 數(shù)據(jù)，那么***限制你的部署為 S3 兼容，以在所有云中維護(hù)一個 REST 接口——這意味著 Ceph 是比Swift 更好的選擇。

一定要避免在公有云和 OpenStack 私有云之間傳輸整個數(shù)據(jù)集，因?yàn)檫@個過程既費(fèi)時又費(fèi)錢。

相反，你需要在每個云平臺中使用數(shù)據(jù)副本來消除延遲。但請記住，有些數(shù)據(jù)需要一個主副本，而且你必須選擇在哪里托管該副本。

為了進(jìn)一步緩解存儲延遲的問題，請?jiān)跀?shù)據(jù)中心中使用高帶寬光纖鏈路運(yùn)行 OpenStack 私有云。存儲快照和持續(xù)備份方面的***進(jìn)展使得更多的選擇成為可能。結(jié)合復(fù)制和擦除編碼，可以自動將數(shù)據(jù)復(fù)制到多個云。這通常是異步復(fù)制，否則寫入性能會受到很大影響。同步窗口時長可以低至一分鐘，甚至更短——這對于需要接近實(shí)時的數(shù)據(jù)應(yīng)用(如數(shù)據(jù)分析)來說特別有用。

OpenStack兼容性

在混合或多云部署中，始終存在哪些云 “一起玩得***”的問題。

• 所有主要的公有云服務(wù)提供商都繼續(xù)努力與 OpenStack 交互。
• 例如， Microsoft Azure 專注于 Azure Stack 和 Windows Server 之間無縫的數(shù)據(jù)遷移。
• AWS 很可能與其合作伙伴 VMWare 進(jìn)一步深化合作。
• 谷歌則與紅帽專注于OpenStack私有云和公有云 。

盡管如此，幾乎沒有證據(jù)表明哪一個公有云平臺會成為與 OpenStack 私有云搭配的標(biāo)準(zhǔn)選擇。

展望未來，多云的重點(diǎn)將是在供應(yīng)商和平臺之間進(jìn)行統(tǒng)一管理。但保障不同云服務(wù)和SaaS應(yīng)用程序的正常訪問更符合總要。實(shí)際上也意味著API更為重要。