IT領(lǐng)域中的生活充滿了艱巨的任務(wù)。在進行備份或者維護修補方案時，你必須確保多層反惡意軟件被適當部署。不幸的是，在高度虛擬化的環(huán)境中，管理殺毒軟件會是一件非常痛苦的事情，殺毒軟件自身實際上構(gòu)成了一種威脅。就像俗話說的那樣：治療有時比疾病本身更糟糕。

也許任何人都不會對殺毒軟件會使機器運行速度變慢這一點感到驚訝。任何監(jiān)控每一個磁盤I/O并檢查其是否存在威脅的軟件都會給系統(tǒng)帶來額外的開銷。對于大多數(shù)情況，這體現(xiàn)在較高的磁盤延遲和CPU負載上面。盡管如此，殺毒軟件在進行掃描排除時都會很小心，因此它們通常不會造成系統(tǒng)癱瘓。

最近，我提出了兩個很好的例子，這些例子為我們展示了殺毒軟件在失去控制時是怎樣對系統(tǒng)性能造成巨大的整體影響的，同時還顯示了檢測其中的原因是多么的困難——除非你知道去尋找原因并且擁有這樣做必需的監(jiān)測數(shù)據(jù)。

新的VDI環(huán)境

在第一個例子中，客戶處在將新的VDI環(huán)境帶進生產(chǎn)的過程中�；A(chǔ)映像已經(jīng)被全面測試，用戶群為他們擺脫了傳統(tǒng)的桌面而使用VDI為他們帶來的可移植會話感到興奮。初始用戶測試進展順利并且沒有發(fā)現(xiàn)問題。

盡管如此，由于大量自動部署的桌面和不斷擴大的用戶數(shù)量，一系列的性能問題產(chǎn)生了。首先，響應(yīng)時間變慢，而且隨著鋪設(shè)的進行，這種問題會急劇惡化，甚至到用戶開始想念舊的桌面的程度。而在虛擬主機上的初步調(diào)查表明不存在任何重大的CPU或內(nèi)存競爭，因此，人們的注意力迅速轉(zhuǎn)向到SAN.

通過挖掘SAN的管理接口，問題立刻變得很清晰：這的確是與存儲相關(guān)的問題，而且響應(yīng)時間的延遲高峰遠高于20ms.往往是在這種情況下，用戶開始害怕SAN不能提供VDI環(huán)境服務(wù)。幸運的是，故障排除過程并沒有就此停止。對SAN負載的進一步調(diào)查顯示每一個VDI桌面啟動后大約一個小時會產(chǎn)生平均超過40IOPS（SAN存儲評價指標之一）——遠遠超出標準的IOPS以及在初始映像開發(fā)和測試階段中檢測到的IPOS.

最終，問題來源被確定：當非持久性桌面映像啟動時，他們的殺毒agent從管理服務(wù)器獲取新的病毒定義并更新病毒定義庫，然后執(zhí)行一次完整的系統(tǒng)掃描，以確定不存在新的可檢測的風險。這是一個在物理桌面中常用的并且是完全合理的做法，但是在虛擬環(huán)境下，這種做法只會破壞底層的共享存儲硬件并且除此之外別無他用。

作為測試，新病毒定義部署功能被禁用，其結(jié)果是在早上的數(shù)小時內(nèi)減少了近10倍的磁盤I/O，即使此時很多新用戶登錄并啟用了新的桌面——即有效地解決了上面的問題，盡管這也帶來了需要手動更新病毒定義庫的問題。

崩潰的SQL群集

在另外一個例子中，一個客戶端報告說一個關(guān)鍵服務(wù)應(yīng)用程序無響應(yīng)。故障初步診斷表明高度冗余的集群數(shù)據(jù)庫服務(wù)實際上已經(jīng)處于離線狀態(tài)。在服務(wù)器重啟恢復(fù)服務(wù)后，SQL服務(wù)器日志顯示，數(shù)據(jù)庫服務(wù)器經(jīng)歷了一個非常高的磁盤延遲并最終導(dǎo)致了服務(wù)器放棄和終止了服務(wù)。

檢查發(fā)現(xiàn)SAN自身沒有不尋常的事件或失敗發(fā)生。似乎問題一開始可能是和經(jīng)歷了該問題的數(shù)據(jù)庫集群相關(guān)的，但是很難弄清楚實際發(fā)生了什么。更糟糕的是，SAN基礎(chǔ)設(shè)施上的性能日志是不可用的，因此從SAN的角度進行進一步的調(diào)查是不可能的。

考慮到在一個大型虛擬化基礎(chǔ)設(shè)施中物理數(shù)據(jù)庫集群是共享物理磁盤資源的，調(diào)查的方向轉(zhuǎn)向了觀察在虛擬環(huán)境中經(jīng)歷失敗時是否也會出現(xiàn)較高的延遲。事實上，確實會出現(xiàn)很高的延遲，而且難以置信的是這種延遲和前面所述的延遲在同一時間達到延遲峰值。

這還不是全部內(nèi)容。在虛擬環(huán)境中不僅檢測到了相同的延遲，而且在橫跨八個主機的群集中的每一個主機還產(chǎn)生了約200MBps的I/O，每個I/O負載都超出了存儲后端可以正常處理的范圍。進一步調(diào)查顯示，200個VM（虛擬機器）中約有一半正好在同一時間內(nèi)向SAN中發(fā)出大量的I/O操作命令并且一直持續(xù)了大約15分鐘才停止。

最后，問題真正的原因是：由于殺毒軟件管理服務(wù)的配置問題導(dǎo)致了大量的VM還原到一個非托管的狀態(tài)，這種狀態(tài)下它們（VMs）將定義自己的病毒定義數(shù)據(jù)庫，就像在上面的VDI例子中描述的那樣，它們在更新數(shù)據(jù)庫后立即執(zhí)行系統(tǒng)掃描。

已經(jīng)存在的解決方案

幸運的是，存在一些良好的解決方案可以解決這些問題。其中最主要的是遷移到殺毒平臺，殺毒平臺可以在虛擬機監(jiān)控程序棧而不是在客戶機操作系統(tǒng)中運行。雖然在市場上現(xiàn)有一些產(chǎn)品，但是第一個充分利用EPSEC在vSphere中的API的是擁有深安全產(chǎn)品的趨勢科技。這些系統(tǒng)通過把一個掃描引擎集成到系統(tǒng)管理程序的磁盤I/O通路中和在一個集中的虛擬設(shè)備中管理該引擎來工作，這個虛擬設(shè)備控制著諸如簽名更新等策略。

這種做法實現(xiàn)了較低的I/O延遲和主機CPU負載。它輕而易舉地避免了我所描述的兩個例子中共同的核心問題即殺毒軟件引起的磁盤風暴此類問題。因為一個客戶機殺毒軟件agent會忽視這一事實：許多其他類似的agent可能會在同一主機上在其旁邊運行，所以基于系統(tǒng)管理程序的agent可以串行的掃描VM——以確保不會產(chǎn)生殺毒風暴并保持整體安全。

即使你因為支付不起更換殺毒平臺的費用而不這么做，你也應(yīng)該學習認識什么是殺毒風暴以及它可能給你的虛擬化和存儲基礎(chǔ)設(shè)施帶來的各種影響。精心管理集中式殺毒軟件的策略和計劃可以避免一些最惡劣的影響，盡管系統(tǒng)管理程序集成解決方案將產(chǎn)生最好的結(jié)果。

也許上面兩種經(jīng)歷所體現(xiàn)的最重要的信息是：沒有歷史監(jiān)控能力，要區(qū)分遲緩的SAN和殺毒軟件導(dǎo)致的不尋常的磁盤負載幾乎是不可能的。如果你什么都不做，請確保你為自己提供了關(guān)于你的基礎(chǔ)設(shè)施盡可能全面、盡可能多的監(jiān)控數(shù)據(jù)源。