虛擬化
Microsoft Application Virtualization 入門
Anthony Kinney
本文是根據 App-V 的搶鮮版撰寫。本文包含的所有資訊均有可能變更。
綜覽：
- App-V 架構
- 管理虛擬應用程式
- 使用 App-V Sequencer
- 將 App-V 與 Configuration Manager 整合
目錄
App-V 架構
App-V 完整基礎結構的運作方式
更新虛擬應用程式
編序
第 4.5 版
Microsoft Application Virtualization (或 App-V) 深得我心，App-V 的前身是 SoftGrid，而我是在 Microsoft 併購建立 SoftGrid 的公司 (稱為 Softricity) 時，加入 Microsoft 的。我很高興有機會為《TechNet Magazine》撰寫本文，因為自併購之後發生了許多變動。
要認識 App-V，最好先談談 IT 專業人員在企業管理方面所面臨的挑戰。現今的商務桌上型電腦充斥著應用程式，應用程式在安裝之前，必須先經歷冗長的迴歸測試，以確保它能夠與系統上安裝的其他應用程式並存，而不影響它們適當執行的能力。接下來還要再經過一連串的部署程序之後，才進入實際執行階段。而且因為應用程式基本上只在有安裝它的地方可用，所以您的使用者也受限於特定的電腦。這使得複雜的重要專案 (例如作業系統和應用程式移轉、安全性更新，以及嚴重損壞修復規劃等) 更加複雜。
App-V 則大改其觀，透過它，桌上型電腦管理的程序不再是一連串佔用資源又耗費時間的複雜步驟，而是變得更簡單、更自動化。您可以更輕鬆地部署、修補、更新和終止應用程式，並且成效更為顯著。
有了 App-V，使用者可以坐在任一部桌上型電腦前存取他的應用程式。應用程式是視需要才提供，但執行起來會像實際安裝在本機一樣。因此，完全不需要安裝應用程式元件或修改主機裝置。
這種虛擬化的應用，一改 IT 專業人員管理桌上型電腦的方式。不修改主機裝置而改執行虛擬化應用程式有很多優點，包括：
- 減少應用程式衝突
- 更快速且更簡單的更新應用程式
- 能夠並排執行同一應用程式的多個版本
- 增加應用程式的彈性，讓它隨著使用者上下線
- 減少應用程式對應用程式的迴歸測試
App-V 架構
現在就讓我們看看 App-V 平台背後真正的運作原理。這個平台包括幾個主要的元件：Sequencer、資料庫、用戶端、管理伺服器、Streaming Server，以及管理主控台 (見 [圖 1])。
[圖 1] App-V 環境的配置 (按一下以放大影像)
App-V 系統的核心是 App-V 用戶端。可用的用戶端有兩種 — 終端機伺服器用戶端和桌上型用戶端。無論是哪一種用戶端，都必須安裝在您打算部署虛擬應用程式的每部桌上型電腦和終端機伺服器上。用戶端佔用的磁碟空間相當小，它會安裝一個驅動程式，並且有一個顯示成工作匣指示器的可見使用者執行階段元件。
用戶端會從 App-V 管理伺服器收集虛擬伺服器清單，並顯示可用的虛擬應用程式。它會在使用者初始化時，負責啟動這些應用程式，以及管理用戶端快取。用戶端也肩負管理虛擬執行階段環境的管理工作，並且確保每個環境都是在它自己的虛擬泡泡裡面執行。這樣的虛擬環境含有幾個元件，其中包括虛擬登錄、虛擬檔案系統和虛擬服務管理員。
App-V 4.5 中有三種基礎結構部署選項可用：完整基礎結構、輕量型基礎結構和獨立模式。在部署完整基礎結構時，後端包括了 App-V 管理伺服器和 App-V Streaming Server (這是新元件，我稍後會討論到)。App-V 管理伺服器會主控和提供集中化的虛擬應用程式，也會在套用補充程式或更新時更新虛擬應用程式。
這部管理伺服器是仰賴 SQL Server 來主控 App-V 資料庫，當中包含了虛擬應用程式的組態和設定。您應該使用 Active Directory 群組作為佈建和控制虛擬應用程式權限的中央管理工具。
為了管理設定和組態，App-V 平台提供了 Microsoft .NET Framework Web 服務，只要裝有 IIS，便可將它載入相同的伺服器上。這個 Web 服務在 App-V 管理主控台 — 一種 Microsoft Management Console (MMC) 嵌入式管理單元 — 與 App-V 資料庫之間扮演著溝通者的角色。系統管理員可使用主控台來發行和管理虛擬應用程式、指定 Active Directory 群組，以及控制伺服器設定，也可以執行有關虛擬化應用程式使用狀況的報告 (見 [圖 2])。
[圖 2] 管理主控台 (按一下以放大影像)
輕量型基礎結構包括 App-V Streaming Server，它提供串流處理功能，例如主動/封裝更新。這個選項並不需要 Active Directory 或 SQL Server，它並沒有桌上型電腦設定服務，也缺乏授權和計量功能。不過，輕量型基礎結構倒是允許將串流處理功能新增到 System Center Configuration Manager (SCCM) 和其他協力廠商企業軟體部署 (ESD) 解決方案。
在獨立模式中，App-V Sequencer 可建立 MSI 檔案來自動化虛擬應用程式的新增作業 (見 [圖 3])。MSI 檔案包含的中繼資料可讓任何 ESD 系統辨別它，並控制虛擬化應用程式。這個模式會要求用戶端進入獨立模式，這種模式只接受以 MSI 為基礎更新虛擬應用程式，而不接受串流處理。這種模式能讓公司利用 App-V 隔離功能。
[圖 3] App-V Squencer (按一下以放大影像)
MSI 檔案極具彈性，只要有 App-V 用戶端，就可以獨立執行，完全不需要任何伺服器元件。這表示它們可以使用磁碟或透過任何傳統部署工具手動加以部署。
App-V 4.5 現在都支援 HTTP 和 HTTPS 通訊協定進行串流處理。如果連同更廣泛採納的通訊協定來進行串流處理，將可提升效能，特別是跨安全廣域網路 (WAN) 環境和網際網路進行串流處理。
App-V 完整基礎結構的運作方式
使用者登入裝有其中一個用戶端 (App-V 終端機服務或桌上型用戶端) 的裝置，然後用戶端傳送要求到伺服器，要求取得指定給目前使用者的應用程式清單。接著伺服器與 Active Directory 通訊，判斷使用者所屬的群組之後，再將應用程式清單傳回給用戶端。用戶端便開始為已指定給該特定使用者的虛擬化應用程式建置通告。
在這個發行程序當中，執行了幾個動作：
- 複製設定檔
- 建立桌面圖示
- 建立 [傳送到] 連結
- 建立 [開始] 功能表資料夾
- 設定檔案類型
這個程序非常快速，而且最重要的是，可以確保環境看起來沒有任何視覺變更，完全符合使用者的預期。虛擬應用程式的舉動跟安裝在本機沒什麼兩樣，但是它們不會修改主機。圖示不是指向存在程式檔案目錄中的可執行檔，而是指向 App-V 用戶端，而這必須仰賴啟動器檔 (OSD 檔案) 來進行設定。
要特別注意的是，這個程序幾乎不會對網路造成任何衝擊，因為它與傳統軟體部署不同，它並不會安裝任何東西。這一點提供了很多好處，尢其在漫遊使用者的環境中更是，因為供使用者使用的應用程式是在啟動之後才開始傳遞。這種通告方法正是提供 App-V 視需要和漫遊應用程式功能的基礎。
當使用者啟動虛擬應用程式時，用戶端會讀取一直存放在本機電腦上的 OSD 設定檔。它會告訴用戶端，在與 App-V 管理伺服器通訊時要使用哪一個通訊協定，以及應用程式位在哪一部伺服器上。
適當的伺服器會以串流處理初始啟動閾值 (一般是完整應用程式的 20-40%) 來回應用戶端。一旦整個啟動閾值都經過串流處理後 (再次強調，是應用程式的 20-40%)，虛擬應用程式就可以開始執行了。
在 App-V 提出的概念轉型當中，串流處理其實是關鍵要素之一。它可以只傳送足以執行的應用程式，節省寶貴的網路頻寬。所有傳遞給用戶端的資料都存在裝置上的本機快取檔案中，而且應用程式隨後的啟動作業會從本機快取啟動，以消弭額外的網路流量。
虛擬應用程式一完成串流處理後，用戶端便會建置隔離的環境，預防應用程式修改本機電腦 (換句話說，應用程式無法支配用戶端)。但是，用戶端會讓虛擬應用程式在儲存和編輯檔案時存取本機檔案系統，而且只要使用者在本機系統上具備適當的權限，它也允許應用程式與本機服務 (例如列印) 互動。但是虛擬應用程式對本機系統的檔案和登錄所作的任何變更，都會重新導向到虛擬化環境，讓主機裝置保持原封不動。
在執行應用程式時，之前未使用的任何功能都會在需要的時候傳遞，並且快取起來供隨後使用。其優點是，初次啟動時只會載入使用者所需的元件，不讓不需要的功能佔用網路資源 (新版本提供的一些用戶端快取增強功能，可以更聰明的使用快取和背景串流處理)。
以 Consider Microsoft Office Word 為例，由於使用者幾乎都會使用拼字檢查程式 (沒有它，我可能無法寫完這篇文章呢！)，因此它也屬於初始啟動的一部分。但是 Word 裡面的說明功能呢？使用這項功能的人並不多，因此不需要在初始啟動中傳遞它，而是等到使用者第一次使用它時再傳送給他。
使用者用畢並關閉應用程式之後，用戶端就會摧毀虛擬環境，並把所有使用者設定存放在使用者特定的位置中，好讓環境保持到下次啟動時重建。無論串流處理了多少百分比的虛擬應用程式，都會保留在本機快取中，供下次啟動使用。而且要是有其他使用者登入相同的主機系統，並啟動相同的虛擬應用程式，新使用者也可以從已經存放在快取中的應用程式受益。
若要移除虛擬應用程式通告，只要將使用者從適當的 Active Directory 群組移除即可。而要完全將虛擬應用程式從桌上型電腦解除安裝，只要清除快取就行了。應用程式從未真正安裝在本機，因此也不會有煩人的提示詢問您「是否想要移除這個共用元件？」。
要注意的是，即使虛擬應用程式是存放在快取中，也不表示所有的使用者都可以存取它。這跟安裝在本機的應用程式不同，使用者可以搜尋或瀏覽他們無權搜尋或瀏覽的可執行檔，除非使用者透過 Active Directory 群組獲有指定的明確權限，否則虛擬應用程式在視覺或實體上並不存在。
更新虛擬應用程式
更新是利用 Sequencer 來進行。應用程式一經修訂，包含更新之後，就會被放在 App-V 管理伺服器上，並且就在前一版的旁邊。伺服器會下在次啟動時，通知用戶端已發生變更。如果前版仍在使用中，使用者還是可以繼續存取該版本，直到虛擬應用程式關閉為止。下次啟動時，更新差異便會串流處理到用戶端，並且載入快取當中，產生更新版的應用程式。
假設您有 1,000 名使用者執行 Word 2000。有一位系統管理員需要將 Word 2000 (word2K.sft) 更新為 Word 2000 SP3，因此她把 word2K.sft 檔案複製到編序站台，並在 Sequencer 中選取 [開啟以升級套件 (Open for Package Upgrade)]。選取這個選項之後，該系統管理員便從上一個套件狀態開始著手。她可以在虛擬應用程式中複製 DLL、執行更新，或者執行補充程式，將它更新到 Word 2000 SP3，然後再儲存這個經過更新的套件。
Sequencer 會自動指定新檔名 word2K_2.sft 以防檔名重複，並且指明編序的版本。新套件跟舊套件都會放在 App-V 管理伺服器的同一個目錄中，以便讓 Word 2000 (word2K.sft) 和 Word 2000 SP3 (word2K_2.sft) 最後存在同一個目錄中。接著系統管理員再使用 App-V 管理主控台，將這兩個 SFT 檔案連結在一起。
另外在用戶端這邊，如果使用者有作用中的 Word 2000 工作階段、但沒有開啟 SP3，仍可繼續正常操作。如果使用者在系統管理員完成這項連結後，啟動新的應用程式工作階段，則會收到一則訊息，告訴他已經偵測到變更。接著用戶端開始進行串流處理，並且只處理 word2K.sft 與 word2K_2.sft 之間的差異，自動將應用程式更新為 Word 2000 SP3。
由於虛擬應用程式具備動態本質，因此要進行回復也非常簡單。只要回到 App-V 管理主控台，再把新增的版本移除就可以了。這樣用戶端在重新啟動之後，就會回復為前一版。為了確保套件資料不交錯，用戶端會自動清除快取，並重新串流處理適當的 SFT 檔案。想想要回復使用更多傳統軟體部署工具實體安裝的應用程式更新所需花費的功夫，這算是相當合理的折衷辦法了。
若要充分發揮 App-V 的優點，您必須建立虛擬應用程式套件。這正是 App-V Sequencer 派上用場的地方。您從傳統軟體部署工具獲得的編寫指令碼和建立套件的知識和經驗，都有助您轉移到編序 (我應該在此註明，編序這個主題應以專文探討)。
多數軟體部署解決方案都是仰賴指令碼來擷取應用程式自行安裝的方式，然後在其他機器上重複這個程序，如此一來就不用親臨每部電腦來安裝或更新應用程式。應用程式安裝之後，一般軟體部署工具便不再理會套件。接著您必須根據自己的需要，安裝應用程式可能仰賴的任何依存性、執行其他指令碼，或是執行手動步驟來設定應用程式。
App-V 中主要的變革是，編序程序會產生已安裝應用程式的映像，並完成它的依存性和設定。這項作業可由 App-V 用戶端「執行」，而不必修改執行 App-V 的裝置。
Sequencer 會產生各種不同的檔案，當中最重要的要屬 SFT 檔案，該檔案包含了所有的應用程式資產、依存性和設定資訊。在某些情況下，它可能還包含多個應用程式。所以如果該檔很大的話，也不足為奇。雖然它有提供一些壓縮選項，但您還是得充分瞭解您的網路和裝置效能。Sequencer 建立的圖示檔案 (.ico) 是作為通告虛擬應用程式之用，以便讓它像安裝在本機一樣運作。
OSD 檔案也很重要，而且它的選項是漫無邊際的。在預設的情況下，這是一個用來告訴 App-V 用戶端如何啟動虛擬應用程式的 XML 檔案。您也可以修改 OSD 檔案，來設定和控制虛擬應用程式的啟動和執行方式。我強烈建議您閱讀《編序系統管理指南》(英文) 和＜編序最佳作法＞(英文)，熟悉一下 OSD 檔提供的屬性和值。
最近新的 manifest.xml 檔包含了以套件為主的設定資訊，而且可以和協力廠商 ESD 解決方案和 MSI 開發彼此整合。Sequencer 也可以針對虛擬應用程式套件產生 MSI 檔案，將虛擬應用程式載入到獨立 (無伺服器) 用戶端，並且通過 ESD 系統。
Sequencer 本身是以精靈為基礎的工具，它會帶您 (使用套件者) 逐步安裝應用程式，並將它轉變成虛擬應用程式的過程 (見 [圖 4])。第一個步驟可讓您設定套件的預設屬性。這些屬性是存放在 OSD 檔案中，並且包含套件名稱和註解。部分進階設定可讓您指定要從中進行串流處理伺服器、內容目錄，以及套件應該支援的作業系統。
[圖 4] 編序精靈 (按一下以放大影像)
第二步是安裝、設定和測試應用程式。在安裝期間，Sequencer 會擷取對本機系統 (包括檔案系統、登錄和系統) 所做的所有變更。這個精靈還包含一些公用程式，可用來整合像是 Windows Update 等應用程式。
下一個步驟是設定檔案類型關聯，以及指定應該放置捷徑的地方。標準的安置地方包括 [開始] 功能表、桌面和快速啟動列，但您也可以建立自訂位置。
接下來您必須啟動應用程式，並設定初始啟動閾值。在這個步驟中，App-V 會判斷需要傳遞給用戶端，讓應用程式開始執行的應用程式初始部分。
若要設定這段初始程式碼 (一般稱為 Feature Block 1 或 FB1)，只要啟動應用程式，再使用使用者要求的最常用功能即可。例如，啟動 Word 後接著初始化拼字檢查程式。應用程式在這個階段期間呼叫的任何 DLL、檔案或登錄機碼，都會自動指定為 FB1 的一部分。在這個時間點未用到的任何檔案、設定或元件，都會新增到 FB2。接下來使用應用程式時，用戶端會收到 SFT 檔案的對應圖，指出 FB1 開始和停止的地方，以及 FB2 中其他檔案的位置，以便在應用程式需要時，用戶端能夠擷取這些檔案。
編序程序的最後一步，是確保一切都有妥善設定。Sequencer 會顯示 [圖 5] 中所示的對話方塊，當中會呈現 SFT，並允許您對套件做任何最後的新增或變更作業。
[圖 5] 設定和調整最終的套件 (按一下以放大影像)
第 4.5 版
經過兩年的醞釀，App-V 4.5 終於要在今年尾發行。這是本產品的第一個 Microsoft 發行版，它並承諾要推出幾項提升應用程式虛擬化的重要加強功能，例如動態虛擬應用程式互動、擴充的延展性，以及配合 Microsoft 國際化與安全性需求的改善調整。
Dynamic Virtual Application Interaction 可讓虛擬化應用程式彼此進行互動。這種互動關係稱為 Dynamic Suite Composition (DSC)。DSC 並不是要取代新增多個應用程式到相同套件的功能，而是提供一種新管道，整合虛擬應用程式間共用的依存性、中介軟體和外掛程式。
系統管理員可指定哪些虛擬化應用程式可以彼此互動。比方說，假設您有五個 Web 應用程式都需要相同的 Java 版本。在 App-V 4.1 中，您必須在五個不同的套件當中，分別加入相同的 Java 版本。如果那個 Java 版本需要一個修補程式，系統管理員就必須再修補五個不同的套件。但是使用 DSC，即可一次將 Jave 封裝起來，設定成一個套件，讓五個 Web 應用程式使用。因此，修補 Java 時，系統管理員也只需要修補一次 Java 套件就行了。
相同的案例也適用於中介軟體和外掛程式。在 Microsoft 最終的發行版逐漸成形，並完成所有晚期的增補後，我打算再針對其他用途的案例發表部落格。
延展性包括串流處理和後端基礎結構兩方面的增強。後端元件已經過修改，以針對叢集和容錯移轉的案例提供更完備的支援，而串流處理也更適合在 WAN 和 LAN 上使用。這些增強都要拜幾項重要的新增功能所賜。
首先是全新的 Streaming Server 元件，它不需要 Active Directory 的後端基礎結構和 SQL Server，就可以進行串流處理。您仍舊享有視需要傳遞和中央更新套件的各種好處，但少了沉重的後端需求。這可廣泛運用於分公司案例，以及與協力廠商 ESD 解決方案整合的情況。
App-V 用戶端也獲得了幾項增強功能。譬如，用戶端現在是把所有使用狀況資訊存放在本機，以便在用戶端系統連線或離線時，都能追蹤這項資訊。用戶端快取也有所擴展和改良，可以提升磁碟空間有限案例的效能。另外，它也可以編序非英文版的應用程式，在非英文版作業系統上執行 App-V，以及轉換成其他數種語言。
將 App-V 與 Configuration Manager 整合
App-V 4.5 中有不少增強功能和全新功能，都是為了將 App-V 整合至 SCCM 2007 R2 而設計的。我之前已經討論過，虛擬化和串流處理提供的一些功能，可傳遞傳統軟體部署工具沒有提供的應用程式。我不是在暗示 App-V 終將取代這些工具，相反的，它可以補其不足，並且加以擴充。
透過這樣的整合，您可以魚與熊掌兼得，不但可以使用 SCCM 所有的延展性、報告、裝置辨識和 WAN 功能，也可以使用 App-V 所有的串流處理和隔離功能。以下是受惠於這兩種技術整合的幾個領域：
應用程式傳遞：SCCM R2 整合支援視需要傳遞、漫遊應用程式、初始啟動閾值，以及在不修改用戶端電腦下部署應用程式。
更新：SCCM 發佈點 (DP) 在更新套件時，可以只部署虛擬應用程式的差異變更。此舉提供您集中化功能，您只要按個按鍵，就可以將虛擬化應用程式還原為前一個版本。
管理：R2 版推出了全新的虛擬應用程式通告精靈，可讓系統管理員從單一主控台部署虛擬化應用程式，以及傳統軟體套件和通告。
封裝：將 App-V 與 SCCM 整合時，完全不需要重新封裝應用程式。應用程式的初始編序必須在 SCCM 外面使用 App-V 編序完成，但系統管理員還是能夠使用 SCCM 來更新現有的套件。
授權：使用 SCCM 中現有的工具，可追蹤虛擬應用程式來進行授權和計量。
BITS：SCCM 提供一種全新的方法，使用標準 BITS 通訊協定將虛擬化應用程式部署到 App-V。雖然 SCCM DP 可以串流處理，但還是會碰到不適合使用串流處理來部署虛擬化應用程式的情況。在透過 SCCM 進行部署時，您有兩個選擇：使用標準串流處理，或者使用 BITS 的品質服務 (QoS) 功能，以更具控制能力的方式來進行部署。如果您想要在使用者啟動虛擬應用程式之前預先載入快取，這項功能也非常實用。
電腦部署：SCCM 提供的功能，可將虛擬化應用程式部署到特定電腦，以及繼續支援 App-V 平台的使用者型鎖定方法。這一點不但可以協助將虛擬應用程式部署到膝上型電腦、資訊站和實驗室電腦，同時也能夠協助軟體進行依裝置而不是依使用者名稱授權的授權控制。
延展性：必須部署兩種不同、但卻有很多地方重疊的工具，是常見的顧慮。您可以將 SCCM 的延展性和 WAN 優點，與 APP-V 的隔離和串流處理優點彼此整合，以使用現有的 SCCM，提供單一工具來處理兩者的管理和部署作業，而完全不會添增複雜度。
Anthony Kinney 是負責 Microsoft Desktop Optimization Pack 的技術銷售專員。他因 Microsoft 於 2006 年併購 Softricity 而加入 Microsoft。Anthony 任職於 Softricity 時，為 SoftGrid (即現在的 App-V) 編寫及設計了第一個教育訓練程式。您可以透過電子郵件與他聯絡：Anthony.kinney@microsoft.com。