Quantcast
Channel: 不自量力 の Weithenn
Viewing all 596 articles
Browse latest View live
↧

無法建立 SQL Server 叢集電腦帳戶？

May 20, 2015, 6:57 pm
$
0
0

Q.無法建立  SQL Server 叢集電腦帳戶？

Error Message：
建立 SQL Server 2012 Failover Cluster 的過程中，無法建立容錯移轉叢集電腦帳戶，並出現如下錯誤訊息？

The following error has occourred:
The cluster resource 'SQL-Cluster' could not be brought onoline due to an error bringing the dependency resource 'SQL Network Name (SQL-Host01)' online. Refer to the Cluster Events in the Failover Cluster Manager for more inofrmation.

Ans：
詳細資訊請參考 MSDN Blogs - Error during installation of an SQL server Failover Cluster Instance 文章內容。

簡單來說，這個問題是因為「目前的使用者帳號權限不夠」所導致，造成無法在相關的 OU 當中「建立 Compute Object」所產生的錯誤，所以只要給予叢集電腦帳戶足夠的權限即可順利建立 SQL Server 2012 Failover Cluster。
↧
Search

無法順利安裝 VMM Cluster？

May 20, 2015, 10:48 pm
$
0
0

Q.無法順利安裝 VMM Cluster？

Error Message：
因為是建立 VMM Cluster，所以會採用 DKM(Distributed Key Management)加密方式，將驗證資訊儲存在 DC，但是在安裝 VMM Cluster過程中出現如下錯誤訊息且無法繼續？
Unable to create or access the Active Directory container CN=VMM-DKM,DC=azure,DC=weithenn,DC=org. Access is denied. Specify the distinguished name for the container and verify that you have genericRead|CreateChild|WriteProperty rights on the container.
Ans：
詳細資訊請參考 Microsoft KB2721457 - System Center 2012 Virtual Machine Manager Setup fails to create child objects for DKM文章內容。

簡單來說，這個問題是因為「目前的使用者帳號權限不夠」所導致，所以只要給予帳戶足夠的權限即可順利建立 VMM Server Cluster。
↧
↧

Token Size 過大導致 WinRM 驗證失敗？

May 20, 2015, 11:31 pm
$
0
0

Q.Token Size 過大導致 WinRM 驗證失敗？

Error Message：
採用 Domain Admins 群組所屬的管理者帳號登入主機，但是在進行驗證的過程中居然會發生失敗的情況，手動使用 winrm 指令的話便會發生如下錯誤訊息。最後在主機兩端之間去抓取封包，可以發現有一段關鍵字「HTTP/1.1 400 Bad Request」
C:\>winrm id -r:hv01.weithenn.org
WSManFault
     Message = The WinRM Client cannot process the request. It cannot determine the content type of the HTTP response from the destination computer. The Content type is absent or invalid.
Error number: -2144108297 0x803380F7
The WinRM client cannot process the request. It cannot determine the content type of the HTTP response from the destination computer. The content type is absent or invalid.
Ans：
詳細資訊請參考 Microsoft KB970875 - Large Kerberos tokens cause WinRM requests to fail、Microsoft KB327825 - Problems with Kerberos authentication when a user belongs to many groups、Microsoft KB920862 - Error message when an Outlook Web Access user tries to access a mailbox in Exchange Server 2003: “HTTP 400 Bad Request (Request header too long)”文章內容。

簡單來說，問題的原因在於網域當中「使用者帳號、群組、委派...等過多」，造成用於 Kerberos Token 過大所導致的，解法有兩種。首先，治本的方法就是要重新規劃好網域當中使用者帳號、群組、委派...等過多的問題，讓 Kerberos Token 可以從根本縮小，但是相信這個方法應該很難執行了。

治標的方法，則是在所有需要用到驗證的主機中，在其機碼加上下列二筆路徑及相關的值即可解決： 詳細資訊請參考 Microsoft KB820129 - Http.sys registry settings for Windows

  • MaxFieldLenth
  • MaxRequestBytes
↧

台灣微軟 IT 管理技術高峰論壇 (MMS 2015)

June 4, 2015, 8:45 am
$
0
0

活動簡介

台灣微軟 IT 管理技術高峰論壇承襲自美國 Microsoft Management Summit (MMS) 的活動精神，並將其內容複製到台灣舉行。不同於台灣微軟年度 TechDays 大會涵蓋微軟所有產品與技術，MMS 更專注於 IT 管理的相關議題，尤其著重在伺服器、虛擬化、雲端運算與企業行動化上的相關應用與管理，涵蓋產品包括 Windows Server、System Center、Microsoft Azure、Windows Azure Pack & Enterprise Mobility Suite 等等。

去年 MMS 首度在台灣舉辦並且廣受好評，由於許多學員反映每一個場次時間太短無法充分學習，因此今年台灣微軟將每一個場次時間延長為70分鐘，並且將活動時間延長為兩天，尤其 Microsoft 今年 5 月 5 日在芝加哥 Ignite 大會上發表眾多的全新產品和服務，兩天的活動時間可以讓參加學員有更多時間可以學習到最新的 IT 管理技術和新知，包含：

  • 新一代混合雲平台與管理工具：Windows Server 2016、System Center 2016
  • 下一代 Hyper-V 虛擬化技術
  • Windows Azure Pack 下一代 Microsoft Azure Stack
  • Microsoft Azure 在混合雲的新應用
  • 最新雲端管理工具 Microsoft Operations Management Suite (OMS)
  • 企業行動化技術 Enterprise Mobility Suite (EMS) 以及最新家族成員 Microsoft Advanced Threat Analytics (ATA)
  • Windows Server 2003 & SQL Server 2005 終止支援的因應策略


活動資訊

  • 日期： 2014 年 6 月 4 ~ 5 日 (星期四、五)
  • 時間： 9:30 ~ 17:30
  • 地點： 台北市信義區松仁路 7 號 7 樓 (台灣微軟 7A 7B 會議室)
  • 報名： 活動報名



活動內容

第一天、第二天議程


活動影片及講義

本次活動影片及講義，都已經上架到  Channel 9 網站上了，有興趣的朋友別錯過了。本次擔任的議程如下：





↧

SQL Server 2014 Setup Error 0x85640002

June 8, 2015, 10:49 pm
$
0
0

Q.SQL Server 2014 Setup Error 0x85640002？

Error Message：
採用的 SQL Server 2014 ISO 資訊為「SQL Server 2014 Standard 版本 (3932034)」，當我點選「New SQL Server failover cluster installation」項目時，便會出現如下錯誤訊息？


Ans：
試過以下 3 種方式都沒用，還是會出現一樣的錯誤訊息：

  • 將 SQL Server 2014 ISO 掛載到 SQL (VM) 光碟機
  • 將 SQL Server 2014 ISO 檔案，複製到 Guest OS (Windows Server 2012 R2) 當中，手動進行掛載後安裝
  • 將 SQL Server 2014 ISO 檔案解壓縮後，把解壓縮後的資料夾及檔案複製到 Guest OS (Windows Server 2012 R2) 當中手動安裝


後來，看到這篇 MSDN Forum - SQL Server 2012 Installation Problem討論串後，索性也上 MSDN 重新下載新的 SQL Server 2014 ISO 映像檔，目前下載最新版本為「SQL Server 2014 Standard SP1 版本 (6669998)」，就可以順利安裝了。
↧
↧

SQL Server 2014 SP1 FCI 實作筆記

June 10, 2015, 7:29 am
$
0
0

前言

本文說明及實作如何採用 SQL Server 2014 SP1 Standard 版本，將 2 台 Windows Server 2012 R2 建置 SQL Server AlwaysOn Failover Cluster Instances (FCI)，並且結合 gMSA (Group Managed Service Accounts)服務帳戶的部分。

SQL Server Cluster 從 2012 版本開始，都改稱為 SQL Server AlwaysOn Failover Cluster Instances (FCI)，也就是 Standard 版本支援的叢集模式。而採用 Enterprise 版本才能建置SQL Server AlwaysOn Availability Groups(AG)，此外：

  • SQL Server 2012 Cluster 只支援「可用存放裝置」
  • SQL Server 2014 Cluster 支援「可用存放裝置」或「CSV」


gMSA (Group Managed Service Accounts)

它是一個自動提供密碼管理的網域帳戶，因為此帳戶的密碼是由 Windows Server 2012 網域控制站所管理。同時，允許 Windows 能自動處理這些帳戶的密碼管理，將服務帳戶的管理負擔降至最低。

從 Windows Server 2012 開始的新名稱為 gMSA (舊名稱為 MSA)，解決以往需要開啟 Domain User Account 給「服務」使用的困擾(阻擋登入、定期更換密碼…等)。但是，必須要將 gMSA 網域樹系中的 Active Directory 架構更新成 Windows Server 2012，才能建立 gMSA。

圖片來源： TechNet Library - 群組受管理的服務帳戶概觀

圖片來源： TechNet Library - 開始使用群組受管理的服務帳戶

實作環境

  • DC/DNS： 192.168.40.100
  • SQL Server01： SQL01 / 192.168.40.101
  • SQL Server02： SQL02 / 192.168.40.102
  • WSFC (Windows Server Failover Cluster)： SQL2014-WSFC / 192.168.40.104
  • SQL Server AlwaysOn FCI(Failover Cluster Instances)： SQL2014-FCI / 192.168.40.105


設定步驟1、產生 Master Root Key

首先，要在網域內建立並部署「Master Root Key」之後才可以建立服務帳戶，請「Active Directory Sites and Services > View > Show Services Node」左邊會出現 Services 項目，然後點選「Services → Group Key Distribution Service → Master Root Keys」會發現目前是空的。



然後執行下列指令產生 Master Root Keys，因為 Add-KdsRootKey 的 PowerShell 指令，預設需要 10 小時的同步時間之後，才能建立 gMSA 帳號，下列指令即可處理，此時 Master Root Keys 就會產生了。詳細資訊請參考 TechNet Library - Create the Key Distribution Services KDS Root Key
Add-KdsRootKey –EffectiveImmediately                       //for production
Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))   //for lab


設定步驟2、建立 gMSA 服務帳戶 (在 DC 主機上設定)

建置 SQL Cluster 的電腦名稱為「SQL01、SQL02」，建立的服務帳戶為「gMSA-SQL」，建立 Security Group 「gMSA-SQLGroup」且將 SQL01、SQL02 電腦帳戶設定為此群組的成員。



接著執行如下指令建立服務帳戶「gMSA-SQL」，建立完成後在 Active Directory Users and Computers > Managed Service Accounts 便會出現服務帳戶。
New-ADServiceAccount -Name gMSA-SQL -DNSHostName gMSA-SQL.weithenn.org -PrincipalsAllowedToRetrieveManagedPassword "gMSA-SQLGroup"


安裝及測試 gMSA 服務帳戶

將 SQL01、SQL02 主機重新啟動，否則安裝 gMSA 服務帳戶時就會出現下列錯誤訊息。


當 SQL01 主機重新啟動後，即可順利安裝及測試 gMSA 服務帳戶。


SQL02 主機先重新啟動後，才執行安裝及測試 gMSA 服務帳戶的動作，所以都沒任何錯誤產生。


設定步驟3、建立 WSFC

先為 SQL01、SQL02 主機安裝「.NET Framework 3.5、容錯移轉叢集」功能。


底層採用 Shared VHDX (1GB for Quorum、100GB for DB/Log) 提供給 SQL01、SQL02 主機建立 WSFC 環境。



順利建立好 WSFC 運作環境。


設定步驟4、建立 SQL Server FCI

從 SQL Server 2014 起支援 CSV，同時也可以享有 CSV Block Cache 的好處。那麼就把規劃的 100GB 從可用存放裝置轉換為「CSV(叢集共用磁碟區)」。



切換到 SQL01 主機 (FCI 第 1 台主機)

切換到 SQL01 主機，點選「新的 SQL Server 容錯移轉叢集安裝」。原則上，都採用預設值即可，在安裝程式角色頁面中選擇「SQL Server 功能安裝」項目。




在特徵選取頁面中，勾選「Database Engine Services、管理工具 - 基本」項目即可。


在執行個體組態頁面中，輸入預先規劃好的名稱「SQL2014-FCI」。



在叢集磁碟選取頁面，此實作環境只規劃 1 個 CSV 給 DB / Log 同時共用。


在叢集網路組態，輸入預先規劃好的 IP 位址「192.168.40.105」。


在伺服器組態頁面中，便是採用先前所建立的 gMSA 服務帳戶「gMSA-SQL」，在決定前先再次確認 SQL01 主機可以辨識出此 gMSA 服務帳戶。此外，定序的部份則採用「Chinese_Traditional_Stroke_Count_100_CI_AS」。



在資料庫引擎組態頁面中，因為有需求要用 SQL 驗證所以選混合。在資料目錄中，確認路徑是採用「CSV 路徑」。



確認無誤後就開始安裝吧。



安裝完畢後，記得開啟防火牆「TCP Port 1433」，我的環境只開啟防火牆設定檔「網域」的部份。



在系統服務的部份，可以看到 5 個 SQL Server 服務都為「執行中」。


此時，在 SQL01 主機中，也已經可以看到 CSV 路徑中的 SQL 系統資料庫。


在容錯移轉叢集管理員中，已經可以看到 SQL Server 高可用性角色。



開啟 SSMS 管理工具，並採用 SQL FCI 叢集名稱「SQL2014-FCI」來登入。登入後，先將預設的 sa 改名為「sqladmin」，保持基本的安全性。因為此實作環境中 SQL01 主機的記憶體為 16GB，所以將最大伺服器記憶體設定為  12GB，以免影響 Windows 系統運作。




切換到 SQL02 主機 (FCI 第 2 台主機)

切換到 SQL02 主機，點選「將節點加入到 SQL Server 容錯移轉叢集安裝」，原則上都採用預設值即可。


在叢集節點組態頁面，可以看到自動帶出 SQL Server FCI 名稱「SQL2014-FCI」。


在叢集網路組態頁面，可以看到自動帶出 SQL Server FCI 的 IP 位址「192.168.40.105」。


在服務帳戶頁面中，同樣的自動帶出所採用的 gMSA 服務帳戶「gMSA-SQL」，再次確認 SQL02 主機可以辨識出此 gMSA 服務帳戶，便直到安裝完畢。



同樣的安裝完畢後，記得開啟防火牆「TCP Port 1433」，我的環境只開啟防火牆設定檔「網域」的部份。


在系統服務的部份，可以看到只有  2 個 SQL Server 服務為「執行中」。


當然，在 SQL02 主機中，也可以看到 CSV 路徑中的 SQL 系統資料庫。


在 SQL02 主機上，開啟 SSMS 測試用 SQL 驗證能否登入。


設定步驟5、驗證 SQL Server FCI 節點切換

目前 SQL Server 高可用性角色在「SQL01」主機上，我們用 SSMS 登入後建1個測試資料庫為「test01」。


切換  SQL Server 高可用性角色節點為「SQL02」主機，同樣用 SSMS 登入後建1個測試資料庫為「test02」。


此時 SQL01主機 (非擁有者節點)，在 SQL Server 系統服務的部份只會啟動「3 個」。


此時 SQL02主機 (擁有者節點)，在 SQL Server 系統服務的部份則會啟動「5 個」。


測試結果確認 SQL01、SQL02 主機，都可以透過 gMSA-SQL 服務帳戶，順利帶起 SQL Server 相關服務。至此，SQL Server 2014 SP1 FCI 實作完成  :)


參考資料

↧

113 期 - 下一代 Windows Server 內建 Hyper-V 新技術預覽

June 10, 2015, 7:30 am
$
0
0

網管人雜誌

          本文刊載於 網管人雜誌第 113 期 - 2015 年 6 月 1 日出刊，NetAdmin 網管人雜誌為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份 1 日出刊您可於各大書店中看到它或透過下列圖示連結至博客來網路書店訂閱它。

文章目錄

1、前言
2、滾動式升級 Hyper-V 叢集版本
3、VM 虛擬主機功能大幅提升
          升級 VM 虛擬主機版本
          新式 VM 虛擬主機設定檔
          新式檢查點機制
          線上調整啟動記憶體空間
          線上新增/刪除虛擬網路卡
          Linux 支援安全啟動機制
          虛擬網路卡名稱識別
          Replica支援線上新增硬碟
          Windows Update 支援整合服務
          3D 功能增強 RemoteFX vGPU
4、儲存功能增強
          Share Nothing Storage Spaces
          Distributed Storage QoS
          Storage Replica
5、結語

1、前言

Microsoft 在 2012 年 9 月時推出 Windows Server 2012 作業系統，隔年在2013年6月TechEd 2013大會上，發佈 Windows Server 2012 R2 技術預覽版本（Preview Version），並於2013年10月時，正式發佈Windows Server 2012 R2 雲端作業系統（Cloud OS）。

本文所要介紹的，是微軟下一代的 Windows Server，也就是在 2014 年 10 月所發佈的第一個 Windows Server技術預覽版本（Preview Version），目前暫稱為 Windows Server vNext。


2、滾動式升級 Hyper-V 叢集版本

現在，管理人員可以將新版的 Windows Server vNext 主機，加入至現有 Windows Server 2012 R2 的 Hyper-V 叢集當中，接著逐台將 Windows Server 2012 R2 主機上的 VM 虛擬主機，陸續遷移至新版 Windows Server vNext 主機上。

然後，依序升級 Windows Server 2012 R2 主機為 Windows Server vNext版本，最後便可以執行PowerShell 指令「Update-ClusterFunctionalLevel」，來升級整個 Hyper-V 容錯移轉叢集的功能版本。

請注意!!一旦升級成 vNext 的 Hyper-V 容錯移轉叢集功能版本之後，便無法降級回原本的 Windows Server 2012 R2 叢集功能版本。

圖1、滾動式升級 Hyper-V 叢集版本運作架構示意圖
圖片來源： Channel 9 – Windows Server vNext

事實上，當 Hyper-V 叢集處於「混合（Mix）」的運作模式時，也就是 Hyper-V 叢集中有新舊版本的 Hyper-V 主機同時存在的情況下，此時的 Hyper-V 叢集將有下列相關限制：
  • 「只」能透過新版的 Windows Server vNext 主機，來管理 Hyper-V 叢集、Hyper-V節點主機、VM 虛擬主機。
  • 新的 Hyper-V 功能特色還無法使用，必須等到所有的 Hyper-V叢集節點都升級為 Windows Server vNext版本，並且 Hyper-V 叢集功能等級升級之後才能使用新的特色功能。
  • 在 Windows Server 2012 R2 主機上的運作 VM 虛擬主機版本為「5.0」，必須要等到叢集節點升級為Windows Server vNext，並且 Hyper-V 叢集功能等級升級之後，才能升級 VM 虛擬主機版本至「6.0」。
管理人員隨時可以使用 PowerShell 指令「Get-VM | select name, version」，來查詢 VM 虛擬主機版本。

3、VM 虛擬主機功能大幅提升

新版本的 Windows Server vNext 虛擬化平台當中，針對 VM 虛擬主機除了原有的功能增強之外，更新增許多特色功能。

升級 VM 虛擬主機版本

當 Hyper-V 叢集當中，所有的 Hyper-V 叢集節點主機都升級成 Windows Server vNext 版本，並且也升級 Hyper-V 叢集功能版本後，便可以使用 PowerShell 指令「Update-VmConfigurationVersion」，來升級 VM 虛擬主機版本。但是有下列事項必須注意：
  • VM 虛擬主機版本升級為 6.x版本之後，便無法降級回舊有的5.x版本。
  • VM 虛擬主機版本升級後，便無法再將 VM 虛擬主機遷移回 Windows Server 2012 R2主機上運作。
  • VM 虛擬主機必須為「關機（Shutdown）」狀態，才能以 PowerShell 指令升級 VM 虛擬主機版本。
  • 當 Hyper-V 容錯移轉叢集功能版本未升級成 Windows Server vNext 版本時，無法升級 VM 虛擬主機版本。
  • 升級版本後的 VM 虛擬主機，將會採用新式的 VM 虛擬主機設定檔格式。

圖2、升級及查詢 VM 虛擬主機版本

新式 VM 虛擬主機設定檔

在 Windows Server 2012 R2 以及先前舊有的版本當中，VM 虛擬主機的設定檔為「.xml」格式，同時可以開啟並進行編輯作業。

現在，新版的 Windows Server vNext 當中的 Hyper-V 虛擬化平台的 VM 虛擬主機，採用新的設定檔「.VMCX 及 .VMRS」，新式的 VM 虛擬主機設定檔，可以有效提升 VM 虛擬主機的「讀取（Read） / 寫入（Write）」效率，並且當儲存設備無預警發生故障損壞事件時，也能降低資料損壞的可能性。
  • .VMCX： VM 虛擬主機設定檔，取代舊有的 .xml 檔案。
  • .VMRS： VM 虛擬主機運作狀態檔，取代舊有的 .bin 及 .vsv 檔案。

此外，不同於舊版的設定檔可以開啟檢視及編輯，新式的 VM 虛擬主機設定檔 .VMCX/.VMRS 為「二進位（Binary）」格式，因此無法檢視內容及編輯。

圖3、新版 VM 虛擬主機採用的新式設定檔格式

新式檢查點機制

在新版 Windows Server vNext 虛擬化平台當中，針對 VM 虛擬主機的「檢查點（Checkpoint）」（舊稱為「快照 Snapshot」）機制也進行翻新。

現在檢查點機制分為「Production Checkpoints」及「Standard Checkpoints」兩種類型，其中 Standard Checkpoints 便是舊有的檢查點運作方式，也就是採用「儲存狀態（Saved State）」的機制，來為 VM 虛擬主機建立檢查點。

新式的 Production Checkpoints 檢查點機制，針對運作 Windows 作業系統的 VM 虛擬主機，將會採用「磁碟區快照服務（Volume Snapshot Service，VSS）」的方式，來為 VM 虛擬主機建立檢查點。而針對 Linux 作業系統的 VM 虛擬主機，則會採用「更新檔案系統緩衝區（Flush File System Buffers）」的方式，為 Linux 作業系統底層的檔案系統建立一致性的檢查點。

預設情況下，新版的 VM 虛擬主機將會採用新式的 Production Checkpoints 檢查點機制，同時它也更適合使用於線上營運環境的 VM 虛擬主機。但是，仍然會有產生差異磁碟 .avhdx 的問題存在，因此在使用上仍需注意對於 VM 虛擬主機 I/O 的影響。

圖4、選擇 VM 虛擬主機採用的檢查點機制

線上調整啟動記憶體空間

在 Windows Server 2012 R2 的 Hyper-V 虛擬化平台上，運作的 VM 虛擬主機在啟用「動態記憶體（Dynamic Memory）」之後，可以在 VM 虛擬主機運作中線上調整虛擬記憶體的「下限（Minimum） / 上限（Maximum）」，但是並無法線上調整「啟動（Startup）」的虛擬記憶體空間。

現在，在 Windows Server vNext 虛擬化平台運作的 VM 虛擬主機，不管採用的是第一世代或第二世代的 VM 虛擬主機格式，即使在沒有啟用動態記憶體機制的情況下，也都可以在 VM 虛擬主機運作中線上調整啟動虛擬記憶體空間。

圖5、新版的 VM 虛擬主機，可線上調整啟動虛擬記憶體空間

線上新增/刪除虛擬網路卡

過去，在 Windows Server 2012 R2 的 Hyper-V 虛擬化平台上，若 VM 虛擬主機需要「新增（Add） / 移除（Remove）」虛擬網路卡時，必須要將 VM 虛擬主機「關機（Shutdown）」才能進行新增移除作業。

現在，新版的 Windows Server vNext 虛擬化平台 VM 虛擬主機，當使用的是「第二世代」的 VM 虛擬主機格式時，不管 VM 虛擬主機採用的作業系統是 Windows 或 Linux，都隨時可以線上新增/移除（Hot Add / Hot Remove）虛擬網路卡，並且運作中的 Windows / Linux 作業系統都可以線上感知新增或移除的虛擬網路卡。

圖6、新版 VM 虛擬主機，可隨時線上新增或移除虛擬網路卡

Linux 支援安全啟動機制

在相對舊版的 Windows Server 2012 R2 Hyper-V 虛擬化平台上，即使採用第二世代的 VM 虛擬主機，若安裝 Linux 作業系統的話，仍然無法支援「安全啟動（Secure Boot）」機制。

現在，新版的 Windows Server vNext 虛擬化平台 VM 虛擬主機，當使用的是「第二世代」的 VM 虛擬主機格式時，採用 Ubuntu 14.04 及 SUSE Linux Enterprise Server 12 新版作業系統時，都已經能夠支援安全啟動機制。

圖7、Linux 虛擬主機支援安全啟動機制

在第一次啟動 Linux 虛擬主機之前，你必須先指定 VM 虛擬主機採用 Microsoft UEFI Certificate Authority，那麼 Linux 虛擬主機便能順利支援安全啟動機制。
Set-VMFirmware "TestVM-Ubuntu" -SecureBootTemplate MicrosoftUEFICertificateAuthority

虛擬網路卡名稱識別

以往在 VM 虛擬主機的設定內容視窗中，當指定虛擬網路卡採用虛擬交換器後，會在虛擬網路卡下方顯示虛擬交換器以利識別。

但是，當 VM 虛擬主機的虛擬網路卡數量一多時，雖然我們在 Guest OS 層級可以針對虛擬網路卡重新命名以利識別，不過在 VM 虛擬主機設定內容視窗中，每一片虛擬網路卡卻只能顯示「Network Adapter」，造成辨別上的困擾。

圖8、可顯示虛擬交換器名稱，卻無法顯示虛擬網路卡名稱造成辨別上的困擾

現在，新版的 Windows Server vNext 虛擬化平台 VM 虛擬主機，支援虛擬網路卡「裝置命名（Device Naming）」機制。請在 VM 虛擬主機設定內容中，點選 Advanced Features 項目後勾選「Enable device naming」選項，之後 VM 虛擬主機設定內容中的虛擬網路卡名稱，便可以支援顯示 Guest OS 層級所重新命名的網路卡名稱了。

圖9、VM 虛擬主機的虛擬網路卡名稱，支援顯示 Guest OS 層級所命名的網路卡名稱

Replica支援線上新增硬碟

Hyper-V 複本（Replica）機制，是從 Windows Server 2012 版本開始新增的特色功能，在 2012 版本時支援異地備援複本機制，至 2012 R2 版本更支援延伸複本機制，將複本資料由第二方位置再次複寫到第三方位置進行存放。

但是在這兩個版本當中，當 VM 虛擬主機進行複本抄寫的情況下，若 VM 虛擬主機線上新增硬碟（Hot Add VHDX Disk）時，必須要重新啟用及設定 Hyper-V 複本機制才行，否則將會造成複寫作業失敗的情況。

現在，你只要在 VM 虛擬主機線上新增硬碟之後，執行下列 PowerShell 指令便能讓 Hyper-V 複本機制，順利感知到 VM 虛擬主機線上所新增的硬碟，並且繼續進行複寫作業而不會有任何影響。
Set-VMreplication "TestVM" -ReplicatedDisks （Get-VMHardDiskDrive "TestVM"）

Windows Update 支援整合服務

每一種虛擬化平台都會需要幫其上運作的 VM 虛擬主機安裝適當的 Tools，以使其上運作的 VM 虛擬主機能夠與虛擬化平台進行最緊密的結合（例如 虛擬裝置最佳化…等），舉例來說 VMware vSphere 虛擬化平台便需要幫 VM 虛擬主機安裝 VMware Tools，而Citrix XenServer 虛擬化平台便需要幫 VM 虛擬主機安裝 Xen Tools。

Microsoft Hyper-V虛擬化平台則是需要幫其上運作的 VM 虛擬主機安裝「整合服務（Integration Services）」，安裝整合服務完畢後在驅動程式部份會更新 IDE、SCSI、網路、視訊、滑鼠…等方面進行最佳化，而在服務方面則是整合 作業系統關閉（Shutdown）、時間同步化（Time Synchronization）、資料交換（Key/Value Exchange）、活動訊號（Heartbeat）、線上備份（Volume Shadow copy Service，VSS）…等機制，以期 VM 虛擬主機跟 Microsoft Hyper-V虛擬化平台不管是在效能運作上，或者是驅動程式最佳化方面都能進行完美的結合。

您會發現 VM 虛擬主機安裝客體作業系統之後，有些 Guest OS 作業系統版本必須要「安裝」整合服務，有些須要「升級」整合服務版本有些則是「不須要」安裝整合服務。其中，不須要安裝整合服務的 VM 虛擬主機，是因為所安裝的作業系統為「Enlightenment OS」，也就是該作業系統的「核心」能夠自動「感知」目前身處的環境是否為虛擬化環境，因此便無須安裝整合服務。

舉例來說，在舊版本的 Hyper-V 2.0 虛擬化平台當中，若 VM 虛擬主機安裝 Windows 7、Windows Server 2008 R2 作業系統，因為屬於該虛擬化平台的 Enlightenment OS 所以「不須要」安裝整合服務，但若運作在「Hyper-V 3.0」虛擬化平台當中則須要「升級」整合服務版本。

  • Hyper-V 1.0： Windows Vista、Windows Server 2008 為 Enlightenment OS。
  • Hyper-V 2.0： Windows 7、Windows Server 2008 R2 為 Enlightenment OS。
  • Hyper-V 3.0： Windows 8.1、Windows Server 2012 R2 為 Enlightenment OS。


此外，後續若有新的整合服務版本時 Hyper-V 虛擬化平台，也必須要進行相對應的更新後才能幫其上運作的 VM 虛擬主機更新整合服務版本。

現在，整合服務已經包含在 Windows Updtate 當中（例如， KB 3004908），並且舊有的整合服務安裝映像檔（vmguest.iso），也不會存在於 Hyper-V 虛擬化平台中。所以，你在 Windows Server vNext 虛擬化平台中所建立的 VM 虛擬主機，在 VM Console 視窗中Action 項目選單中，已經看不到舊有的「插入整合服務安裝光碟」選項。

圖10、新版 VM 虛擬主機已經沒有插入整合服務安裝光碟選項

3D 功能增強 RemoteFX vGPU

在新版 Windows Server vNext 虛擬化平台上運作的 VDI 虛擬主機，只要 VDI 虛擬主機的作業系統採用 Windows 10 Enterprise 或 Windows Server vNext，並且實體伺服器搭配安裝 GPU 顯示卡，便可以啟用 RemoteFX vGPU 硬體加速機制。

目前支援主流的 GPU 顯示卡有 NVIDIA 及 AMD：


啟用 RemoteFX vGPU 硬體加速機制的 VDI 虛擬主機，將具備如下特性：
  • 支援 OpenGL 4.4 及 OpenCL 1.1 API：所以 VDI 虛擬主機可以更佳的運作 Adobe Photoshop、Maya、Blender、Houdini 等繪圖軟體，此外也同時支援 GPGPU 工作負載。
  • 支援更多的視訊記憶體（Video Memory）：在 Windows Server 2012 R2 的 VDI 虛擬主機，其視訊記憶體最多只能設定至 256MB，現在最多可配置 2GB 的視訊記憶體（1G 專用、1GB 共享）。但若採用 32 位元的 Windows 10 作業系統，則最多只能配置 512MB的視訊記憶體。
  • 針對各種 API 的效能改善。

圖11、RemoteFX vGPU 運作架構示意圖
圖片來源： Remote Desktop Services Blog – Understanding and Evaluating RemoteFX vGPU

儲存功能增強

在新版的 Windows Server vNext 當中，針對儲存功能的部分也新增許多特色功能，例如「軟體定義儲存（Software-Defined Storage，SDS）」的功能...等。

Share Nothing Storage Spaces

在 Windows Server 2012 R2 當中的 Storage Spaces 機制，在底層實體硬碟的部分必須要採取「共享式 JBOD（Shared JBOD）」，或者是「SAS 網狀架構（SAS Fabric）」來供應儲存資源，然後採用 Storage Spaces 的 Storage Pool機制，將底層實體硬碟的儲存空間串起來之後，再以 Storage Spaces 的 Virtual Disk機制，決定採用「簡單（Simple）、鏡像（Mirror）、同位元檢查（Parity）」哪種容錯類型，來保護屆時所存取的資料。

最後再以 SMB Scale-Out File Server Cluster 運作架構，將儲存資源以 SMB 3.0 協定分享給所需要的應用程式使用如 Hyper-V、SQL Server、Exchange...等。

圖12、Storage Spaces整合Scale-Out File Server Cluster運作架構示意圖
圖片來源： TechEd Europe 2014 – Design Scale-Out File Server Clusters in the Next Release of Windows Server

現在，在 Windows Server vNext 當中的 Storage Spaces 機制，增強為不需要底層實體硬碟採取Shared JBOD或SAS Fabric架構，直接在Scale-Out File Server Cluster運作架構中，每一台叢集節點當中的本機儲存資源貢獻出來即可串聯後使用，達成「Shared Nothing Storage Spaces」運作架構。

簡單來說 Shared Nothing Storage Spaces 具備下列特點：
  • 支援每台 Scale-Out File Server Cluster 叢集節點，採用本機 DAS 儲存資源（SATA、SAS）。
  • 針對資料容錯的備援機制，將採用3-Copy Mirror或Dual-Parity機制進行資料保護。因此，不管叢集節點發生哪種故障損壞事件（例如，硬碟、機箱、主機...等），都能夠保護資料的完整性。
  • 可透過System Center或PowerShell進行管理作業。

圖13、Shared Nothing Storage Spaces運作架構示意圖
圖片來源： TechEd Europe 2014 – Design Scale-Out File Server Clusters in the Next Release of Windows Server

Distributed Storage QoS

「Storage QoS」功能在 Windows Server 2012 R2 當中便已經具備，它可以針對「每台 VM 虛擬主機」或「每顆 VHD/VHDX 虛擬磁碟」，進行 IOPS 的最小值或最大值的使用限制，以避免在虛擬化平台當中，有少部分 VM 虛擬主機因為突然爆發的 IOPS 工作負載，佔用整座儲存設備過多的 IOPS 儲存資源，造成其它 VM 虛擬主機運作效能不彰。

圖14、Windows Server 2012 R2版本 Storage QoS 運作架構示意圖
圖片來源： TechEd Europe 2014 – Delivering Predictable Storage Performance with Storage Quality of Service in the Next Release of Windows Server

現在，新版的 Windows Server vNext 當中，更進一步增強為「Distributed Storage QoS」機制，不但可以支援原有的 VM 虛擬主機及每顆虛擬硬碟，現在更延伸至「服務（Service）」及「租用戶（Tenant）」的層級。

此外，在設定 QoS 的機制上也更為簡單，採用的「I/O Scheduler」機制預設就已經在 Scale-Out File Server Cluster當中啟用，並且可以「跨越每台叢集節點」進行運作，有效解決過去必須在每台叢集節點進行單獨設定的困擾。

最後，再搭配「Policy Manager」管理機制，將所設定的「Storage QoS」原則套用到所屬的 VM 虛擬主機、服務、租用戶當中。當然，你可以透過 PowerShell、SCVMM、Ops Manager 各種管理工具，來進行 Policy 的管理作業。

圖15、Windows Server vNext 版本 Storage QoS 運作架構示意圖
圖片來源： TechEd Europe 2014 – Delivering Predictable Storage Performance with Storage Quality of Service in the Next Release of Windows Server

Storage Replica

「SR（Storage Replica）」這是 Windows Server vNext 的新功能，它是一種「區塊層級（Block Level）」的複寫技術，可以支援「同步（Synchronous）」及「非同步（Asynchronous）」兩種不同的資料複寫方式，並且以 SMB 3 的通訊協定來進行資料的複寫傳送，而在使用案例上又可以分為「Server to Server」、「Stretch Cluster」、「Cluster to Cluster」等不同的應用情境。

圖16、Storage Replica 應用情境運作架構示意圖
圖片來源： Channel 9 – Windows Server vNext

在「同步（Synchronous）」複寫機制中，系統會保證每次的 IO 作業完成之前，都會將資料寫入至少兩個不同的位置後，才會回覆給上層的應用程式已完成 IO 作業。因此，它適合用於需要高可用性及災難復原，也就是「零資料損失（Zero Data Loss）」的運作環境。在兩端主機之間資料複寫的動作如下：
  1. 應用程式寫入資料。
  2. 來源端主機將資料寫入至Data及Log本地端儲存資源當中，同時透過SMB 3協定將資料傳輸至目的端主機。
  3. 目的端主機將所收到的資料進行寫入本地端儲存資源的動作。
  4. 目的端主機資料寫入完成後，回覆給來源端主機已完成IO動作。
  5. 應用程式確認已完成IO動作。

圖17、Storage Replica同步（Synchronous）複寫機制運作架構示意圖
圖片來源： Channel 9 – Windows Server vNext

而在「非同步（Asynchronous）」複寫機制中，系統在本地端完成 IO 作業後便回覆給上層的應用程式，之後才將資料複寫到另一個位置。因此，這樣的資料複寫機制仍然是有資料遺失的風險存在，只能達成「近乎零資料損失（Near Zero Data Loss）」的運作環境。在兩端主機之間資料複寫的動作如下：
  1. 應用程式寫入資料。
  2. 來源端主機將資料寫入至Data及Log本地端儲存資源當中。
  3. 回覆給上層應用程式確認已完成IO動作。
  4. 透過SMB 3協定將資料傳輸至目的端主機。
  5. 目的端主機將所收到的資料進行寫入本地端儲存資源的動作。
  6. 目的端主機資料寫入完成後，回覆給來源端主機已完成IO動作。

圖18、Storage Replica非同步（Asynchronous）複寫機制運作架構示意圖
圖片來源： Channel 9 – Windows Server vNext

5、結語

透過本文的介紹及說明，讀者應該對於下一代的 Windows Server vNext 功能感到興趣，相信在後續推出的第二個 Windows Server技術預覽版本當中，將會有更多特色功能。屆時，也將會為大家一一深入剖析每項功能及使用案例。
↧

Microsoft Ignite 2015 BRK3474 - Enabling Private Cloud Storage Using Servers with Local Disks

June 10, 2015, 7:35 am
$
0
0

前言

全新的 Microsoft Ignite 2015大會，取代原有的 TechEd 並融合多項微軟產品的盛會。現在，所有的議程都已經在 Channel 9上了。下列的要點整理為 Microsoft Ignite 2015 BRK3474 - Enabling Private Cloud Storage Using Servers with Local Disks議程，那麼，開始來學習吧 :p

亮點特色功能

SDS(Software Defined Storage)

在議程的一開始，先說明在 Windows Server 2012 R2 當中，對於 SDS(Software Defined Storage) 的特色功能。接著，說明在 Windows Server 2016 TP2 當中，將會把原本的 Scale-Out File Server Cluster 的部分進行加強。

圖片來源： Microsoft Ignite 2015 BRK3474 - Enabling Private Cloud Storage Using Servers with Local Disks

圖片來源： Microsoft Ignite 2015 BRK3474 - Enabling Private Cloud Storage Using Servers with Local Disks

Storage Spaces Direct

在此之前的技術名稱為 Storage Spaces Shared Nothing，現在正式名稱為「Storage Spaces Direct」。簡單來說，你可以將實體伺服器的「本機硬碟 (Local Disk)」，透過多台實體伺服器進行串接後，建立一個巨大的儲存資源池。

目前 Storage Spaces Direct 共支援兩種運作模式，分別是「融合式 (Converged)」以及「超融合式 (Hyper-Converged)」。簡單來說，融合式是將儲存及運算資源分別部署在不同的伺服器層級當中，而超融合式則是將儲存及運算資源統整在同一個伺服器層級中。相關資訊可參考 TechNet Taiwan 官方部落格 - 針對軟體定義資料中心而生的 - 新世代儲存機制。

圖片來源： Microsoft Ignite 2015 BRK3474 - Enabling Private Cloud Storage Using Servers with Local Disks

圖片來源： Microsoft Ignite 2015 BRK3474 - Enabling Private Cloud Storage Using Servers with Local Disks

圖片來源： Microsoft Ignite 2015 BRK3474 - Enabling Private Cloud Storage Using Servers with Local Disks

圖片來源： Microsoft Ignite 2015 BRK3474 - Enabling Private Cloud Storage Using Servers with Local Disks

Storage Spaces Direct - 資料放置策略

現在，透過 Storage Spaces Direct 機制所建立的 Virtual Disk，其實是由許多的「Extents」所組成，每個 Extents 的大小為「1GB」，所以假設 Virtual Disk 空間大小為 100GB 的話，那麼將會有 100 Extents，如果搭配 2-Way Mirror 機制，那麼就會變成 200 Extents，當然，若是搭配 3-Way Mirror 機制，就會變成 300 Extents。

圖片來源： Microsoft Ignite 2015 BRK3474 - Enabling Private Cloud Storage Using Servers with Local Disks

圖片來源： Microsoft Ignite 2015 BRK3474 - Enabling Private Cloud Storage Using Servers with Local Disks

Storage Spaces Direct - 可擴充性 (Scalability)

在 Storage Spaces Direct 運作架構中，當有實體伺服器加入後，會自動「分散 (Distributed)」所有的 Extents 在不同的節點主機上。

原則上，在 Windows Server 2016 TP2 的技術預覽版本中，Storage Spaces Direct 的運作架構：
  • 最少必須由 4 台實體伺服器組成 (支援 NVMe, SAS, NL-SAS, SATA)。
  • 最多支援至 12台實體伺服器。
  • 單一 Storage Pool 支援的硬碟數量最多至 240 顆 (所以，換算後每台伺服器最多約採用 20 顆硬碟)。
圖片來源： Microsoft Ignite 2015 BRK3474 - Enabling Private Cloud Storage Using Servers with Local Disks

圖片來源： Microsoft Ignite 2015 BRK3474 - Enabling Private Cloud Storage Using Servers with Local Disks


Storage Spaces Direct - 可用性 (Availability)

當「實體硬碟損壞(Disk Failed)」時，損壞硬碟進入「淘汰(Retire)」狀態，並同時觸發 Virtual Disk 的「修復程序(Repair Process)」，然後將該硬碟中所屬的 Extent 複製到其它 Node 當中。

圖片來源： Microsoft Ignite 2015 BRK3474 - Enabling Private Cloud Storage Using Servers with Local Disks

圖片來源： Microsoft Ignite 2015 BRK3474 - Enabling Private Cloud Storage Using Servers with Local Disks

當「實體伺服器損壞(Node Failed)」時，該台 Node 中，所有實體硬碟都進入 Retire 狀態。Hyper-V 主機將自動往運作狀態良好的 Node 繼續存取資料。因為需要修復的資料太多，可能也要加入新的 Node，因此建議由管理人員判斷後，手動進行修復作業。

圖片來源： Microsoft Ignite 2015 BRK3474 - Enabling Private Cloud Storage Using Servers with Local Disks

圖片來源： Microsoft Ignite 2015 BRK3474 - Enabling Private Cloud Storage Using Servers with Local Disks

圖片來源： Microsoft Ignite 2015 BRK3474 - Enabling Private Cloud Storage Using Servers with Local Disks

新一代檔案系統 ReFS (Resilient File System)

事實上，在 Windows Server 2012/2012 R2 當中便已經發佈 ReFS 檔案系統 (version 1.0)。現在 Windows Server 2016 TP2 當中的 ReFS 檔案系統更新為 version 2.0，並且具備 Error Detection、Automatic Correction 機制，針對 VHD/VHDX (Fixed、Dynamic、Merge) 格式，都進行「加速(Accelerations)」機制。

圖片來源： Microsoft Ignite 2015 BRK3474 - Enabling Private Cloud Storage Using Servers with Local Disks

圖片來源： Microsoft Ignite 2015 BRK3474 - Enabling Private Cloud Storage Using Servers with Local Disks

與 System Center 2016 協同運作

現在，整合 System Center 2016 管理平台，可以透過 SCVMM 針對 Storage Spaces Direct 提供部署、組態設定、佈建...等作業，同時整合 SCOM 來監控及告警 Storage Spaces Direct 的儲存資源運作情況。當然，針對工作負載的容錯移轉部分可透過 ASR(Azure Site Recovery) 以及 Storage Replica 機制來進行處理。

圖片來源： Microsoft Ignite 2015 BRK3474 - Enabling Private Cloud Storage Using Servers with Local Disks

圖片來源： Microsoft Ignite 2015 BRK3474 - Enabling Private Cloud Storage Using Servers with Local Disks

圖片來源： Microsoft Ignite 2015 BRK3474 - Enabling Private Cloud Storage Using Servers with Local Disks

Storage Spaces Direct 儲存資源可提供超過 110 萬 IOPS

在此議程的最後重頭戲，直接 Live Demo 透過 4 台實體伺服器所建立的 Storage Spaces Direct 運作架構，即可提供上層 Hyper-V 主機高達「110 萬 IOPS」的儲存資源。

圖片來源： Microsoft Ignite 2015 BRK3474 - Enabling Private Cloud Storage Using Servers with Local Disks

↧
Search

Microsoft SDN 初探

June 17, 2015, 2:02 am
$
0
0

前言

Network Controller 的概念是來自 Azure Fabric，也就是在資料中心內提供集中且可程式化自動進行「管理、設定、監控、除錯」實體及虛擬網路的機制，主要有：

  • 南向 API(Southbound API)：用來「探索、檢查」網路設備及服務，以及其它在雲端環境中的網路元件
  • 北向 API(Northbound API)：用來「管理、監控、配置」的 API，你可以使用 PowerShell, REST API 來管理，屆時的 SCVMM 2016, SCOM 2016 就是 Network Controller 的 GUI 管理介面


Network Controller 可以管理什麼
  • Hyper-V VMs and Virtual Switch
  • Physical Network Switch/Routers
  • Firewall Software
  • VPN Gateways, including RRAS Multitenant Gateways
  • Load Balancers

圖片來源： TechNet Library - Network Controller

Network Controller 的功能及好處

Fabric Network Management

讓你方便管理實體網路 IP subnets、VLANs、Layer 2 and Layer 3 Switches、Hyper-V 主機實體網卡。

Distributed Firewall

受 Network Controller 集中管理，座落在 Hypervisor 及 VM 之間，讓你可以控制「東西(east-west)」、「南北(north-south)」的網路流量，此時就是透過 Northbound API 來控制防火牆規則
  • Traffic incoming/outgoing the Internet
  • Traffic incoming/outgoing virtual machines
  • Traffic between virtual machines
  • Traffic between virtual machines and the compute cluster and the fabric of the cloud


Network Topology and Discovery Management (Network Monitoring)

自動探索資料中心內網路元件，以及發現實體跟虛擬的網路是如何介接的，此功能常常用於 Network Monitoring，通常是下列2種方式：
  • Active Network Data：效能數據、Network Loss、Latency 協助判斷是連線中斷還是效能低落。
  • Element Data： 傳統的 SNMP (MIBs) 的偵測方式。


Service Chaining Management

Network Controller 允許你可以「建立規則」，然後「強制流量重新導向」到 Virtual Network Appliances，所以可以進行流量的 Inspected、Audited、Filtered 等動作。

Software Load Balancer Management

Windows Server 2016 將會內建 Scalable and Fault Tolerant Services，屆時 Network Controller 便可以控制它們。

Network Virtualization Management

可以管理及部署 vNET(Virtual Network)，同時支援 NVGRE(Network Virtualization Generic Routing Encapsulation)、VxLAN(Virtual Extensible Local Area Network )。

Windows Server Gateway Management

可以部署、管理、重新設定 Hyper-V Host 及 VM 的 Gateway 部分，橋接虛擬網路及實體網路之間的連通性可以處理：
  • Site-to-Site VPN Connectivity using IPsec or GRE
  • Point-to-Site VPN connections for tenant administrators
  • Layer 3 Forwarding
  • BGP Routing between tenant VNETs and remote locations


參考資料

↧
↧

工作管理員記憶體空間顯示異常？

July 13, 2015, 1:26 am
$
0
0

Q.工作管理員記憶體空間顯示異常？

Error Message：
簡單來說，有台機器安裝 Intel Xeon E5-2680v3 的 CPU 以及 256GB 記憶體，但是在工作管理員的部分卻無法正確顯示。

由下圖可以看到，在開啟的工作管理員中看到記憶體的部分，有些欄位能正常顯示 256GB 但是卻有地方顯示為「600TB Other」？


在 CPU 的部分，同樣的有些地方顯示正常 2.50GHz，但是卻有地方顯示為「0.40 GHz」？


Ans：
詳細原因請參考 Microsoft KB 3070928 - Task Manager may display incorrect memory information文章。此外，我已經確認過這台主機的 BIOS 是提供正確 CPU、Memory 數值了，所以看來就先這樣吧 :)

20150722 更新
事實上，在「記憶體」的部分可能是顯示異常，但「CPU」的部分卻造成效能嚴重低落，經過多方測試後，在我的硬體環境中是因為 Microsoft KB3064209 - June 2015 Intel CPU microcode update for Windows 所導致的，只要「移除」掉該更新後重新啟動主機，CPU 時脈的部分便恢復正常且效能也如預期所表現。
↧

114 期 - 動手建立 VSAN 6 儲存資源，實戰水平擴充與容錯網域

July 20, 2015, 8:16 am
$
0
0

網管人雜誌

          本文刊載於 網管人雜誌第 114 期 - 2015 年 7 月 1 日出刊，NetAdmin 網管人雜誌為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份 1 日出刊您可於各大書店中看到它或透過下列圖示連結至博客來網路書店訂閱它。

文章目錄

1、前言
2、VSAN 6.0 新功能概要
3、實作一 - 建立 VSAN 6.0 Datastore儲存環境
          步驟1、設定 VSAN 專屬網路
          步驟2、為 Cluster 啟用 Virtual SAN 功能
          步驟3、宣告加入 VSAN Datastore 的硬碟
          步驟4、確認 Storage Provider 運作狀態
4、實作二 - VSAN Cluster水平擴充（Scale-Out）
          手動 - 擴充 vsanDatastore 儲存空間
          自動 - 擴充 vsanDatastore 儲存空間
5、實作三 - 容錯網域（Fault Domain）
6、結語

1、前言

隨著最新版本 VMware vSphere ESXi 6.0 在 2015 年 3 月正式發行。同時，與 VMware vSphere Kernel 整合的 VSAN（Virtual SAN）技術，也從先前舊版的 VSAN 1.0 版本，雖然原訂新版本為 VSAN 2.0，但是卻直接與 vSphere 最新版本對齊成為 VSAN 6.0 版本。

運作在 VMware vSphere ESXi 5.x 虛擬化平台的 VSAN 1.0 版本，僅支援單一儲存資源運作架構，也就是每一台 ESXi 主機的儲存資源，僅支援 SSD 固態硬碟與機械式硬碟的混用架構。現在，最新版本的 VSAN 6.0 版本多出了「All-Flash」運作架構，也就是說你可以採用全部 SSD 固態硬碟或 Flash 快閃記憶體來建立 VSAN 儲存資源。

圖片來源： VMware 官方網站 – Virtual SAN 產品概觀
圖1、VSAN 6.0 支援 Hybrid 及 All-Flash 運作架構示意圖

首先，在 VSAN 6.0 版本中，仍然支援原有的「Hybrid」儲存資源運作架構，也就是在「磁碟群組（Disk Group）」當中，採用 SSD/Flash 當成資料快取（Caching）的用途，在快取方面的比例為「30% Write Buffer」以及「70% Read Cache」，至於資料儲存（Data Store）的部分則採用儲存空間大，但效能相對較普通的「SAS / NL-SAS / SATA」機械式硬碟即可。

圖片來源： VMware 官方網站 – Virtual SAN 產品概觀
圖2、VSAN 6.0 Hybrid儲存資源運作架構示意圖

此外，在新版 VSAN 6.0 當中推出全新的「All-Flash」儲存資源運作架構，在資料快取的部份可以採用「SAS / SATA」介面的 SSD 固態硬碟，或採用 PCIe Flash 卡來擔任，而資料儲存的部分則可以採用容量較大的 SSD 固態硬碟（例如，TLC SSD）。

採用 All-Flash 儲存資源運作架構時，在資料快取的部份與 Hybrid 架構有很大的不同，其中「100% Write Buffer」直接交給擔任資料快取的 SSD 固態硬碟或 PCIe Flash 快閃記憶卡負責，而「100% Read Cache」則由擔任資料儲存的 SSD 固態硬碟負責。

圖片來源： VMware 官方網站 – Virtual SAN 產品概觀
圖3、VSAN 6.0 All-Flash儲存資源運作架構示意圖

2、VSAN 6.0 新功能概要

簡單來說，「VSAN（Virtual SAN）」是由 VMware 所發展的「軟體定義儲存（Software-Defined Storage，SDS）」技術，能夠將眾多 x86 伺服器上的本機儲存資源(Local Storage)串連起來變成一個共享的儲存空間，同時透過 SSD 固態硬碟的快速存取特性，來提升 VSAN 整體運作環境的資料 I/O 效能。

新版的 VSAN 6.0 同樣支援「垂直擴充（Scale-Up）」的運作架構。在 VSAN Cluster 運作架構當中，若以 Hybrid 運作架構來看，每一台 ESXi 主機最多可以配置「5組磁碟群組」，每一組磁碟群組當中可以配置1顆SSD固態硬碟，搭配最多 7 顆SAS / NL-SAS / SATA介面的機械式硬碟，因此每台 ESXi 主機最多可以配置總數 5 顆 SSD 固態硬碟加上35顆機械式硬碟。

除了增加單一主機儲存空間的垂直擴充運作架構之外，也支援增加 ESXi 主機數量的「水平擴充（Scale-Out）」運作架構，除了最初組成 VSAN Cluster 必須至少 3 台 ESXi 主機之外，後續只要運算資源或儲存空間不足時便可以逐台進行擴充。不同的是，在舊版 VSAN 1.0 當中每個 VSAN Cluster 最多僅支援「32 Nodes」，而新版 VSAN 6.0 當中可支援至「64 Nodes」。

圖片來源： VMware 官方網站 – Virtual SAN 功能
圖4、VSAN 6.0 彈性延展運作架構示意圖

此外，在 VSAN 1.0 版本時期，在 VSAN Cluster 當中的每台ESXi主機最多運作 100 VMs，現在，新版的 VSAN 6.0 可運作最多 200 VMs。同時，在舊版 VSAN 1.0 版本中，雖然檔案系統早就支援 62TB 儲存空間，但是在 VMDK 虛擬磁碟的部分仍僅支援 2TB，現在新版的 VSAN 6.0 在VMDK 虛擬磁碟的部分也能支援 62TB。

值得一提的是，雖然 VSAN 可與大部分現有的 vSphere 進階技術如 vSphere HA、DRS、vMotion、Storage vMotion...等協同運作。但是，目前最新版本的 VSAN 6.0 仍不支援的進階技術有 SIOC（Storage IO Control）、Storage DRS、DPM（Distributed Power Management）這部分管理人員必須特別注意。

3、實作一 - 建立 VSAN 6.0 Datastore儲存環境

步驟1、設定 VSAN 專屬網路

雖然，VSAN 運作架構支援 1 Gbps 及 10 Gbps 網路環境，但是根據 VMware 官方的建議在 VSAN Network 專屬網路的規劃部分，若是採用 Hybrid 運作架構的話則支援採用 1 Gbps 及 10 Gbps，但若採用 All-Flash 運作架構的話僅支援採用 10 Gbps，以免屆時因為網路環境滿載造成 VSAN 運作效能低落。

在虛擬交換器的部份，VSAN運作架構支援標準式交換器vSS（vNetwork Standard Switch），以及分散式交換器 vDS（vNetwork Distributed Switch）。因此，如果 VSAN 運作架構規模較小，或許可以使用 vSS 虛擬交換器即可，若VSAN運作架構規模較大那麼便建議採用 vDS 虛擬交換器，除了便於管理及維運之外，還可以整合只有 vDS 虛擬交換器才支援的網路流量控制 NIOC（Network I/O Control）功能。

請登入vSphere Web Client管理介面後，依序點選「首頁 > 主機和叢集 > ESXi主機 > 管理 > 網路功能 > VMkernel 介面卡」項目，點選「 新增主機網路」圖示後，在彈出的新增網路視窗當中，於選取連線類型頁面內點選「VMkernel 網路介面卡」項目，準備新增 VSAN 網路專屬用途的 VMkernel Port。 (請注意，從 VSAN 1.0 版本開始，建立及啟用 vSS/vDS 虛擬交換器 VSAN 網路流量功能的部分，都僅支援 vSphere Web Client 管理介面進行操作，不支援傳統的 vSphere C# Client。)

圖5、準備新增 VSAN 網路專屬用途的 VMkernel Port

在選取目標裝置頁面中，請點選「選取現有網路」項目後，按下瀏覽鈕選擇先前所建立名稱為「VSAN Network」的 vDS 虛擬交換器連接埠群組，也就是要將 VSAN VMkernel Port 連接至此 Port Group。

圖6、選擇 VSAN VMkernel Port 連接至哪個 Port Group

在連接埠內容頁面中，請勾選「Virtual SAN 流量」項目，也就是此建立的 VMkernel Port 將專用於 VSAN 傳輸流量。

圖7、勾選Virtual SAN流量項目

在 IPv4 設定頁面中，設定此 VMkernel Port 的 IP 位址即可。此實作環境中，選擇採用自動取得 IPv4 位址設定。(請注意，從 VSAN 1.0 版本開始，在 VSAN 傳輸網路的部分便不支援 IPv6。即使是目前最新版本的 VSAN 6.0 仍僅支援 IPv4 而不支援 IPv6。此外，在實體交換器的部份也必須要支援並啟用「Layer 2 Multicast」功能才行，否則屆時在 VSAN Cluster 當中的 ESXi 主機之間將無法正確溝通 VSAN 資訊。)

圖8、設定 VSAN 用途的 VMKernel Port IP 位址

最後，確認相關組態設定內容無誤後按下完成鈕即可。

圖9、建立 VSAN 用途的 VMKernel Port

此實作環境當中，共有 6 台 ESXi 主機都建立專屬 VSAN 流量用途的 VMkernel Port，可以看到 VSAN Network 當中有 6 個 VMkernel 連接埠。

圖10、為 6 台 ESXi 主機建立專屬 VSAN 流量用途的 VMkernel Port

步驟2、為 Cluster 啟用 Virtual SAN 功能

完成 ESXi 主機的 VSAN 專用網路設定後，便可以為叢集（Cluster）啟用 Virtual SAN 功能。原則上，在叢集中啟用 Virtual SAN 功能，跟以往在叢集中啟用 vSphere HA 及 DRS 進階功能的操作體驗相同，只要在叢集當中勾選「開啟 Virtual SAN」選項，並決定採用「自動（Automatic）或手動（Manual）」的方式，來新增 ESXi 主機的本機硬碟即可。

請在 vSphere Web Client 管理介面中，依序點選「Cluster > 管理 > 設定 > Virtual SAN > 一般 > 編輯」，在彈出的編輯 Virtual SAN 設定視窗中，請勾選「開啟 Virtual SAN」選項，並於將磁碟新增至儲存區的下拉選單中選擇至「手動」項目，以便了解整個新增VSAN儲存資源的操作步驟及流程。

圖11、為 Cluster 開啟 Virtual SAN 功能

為VSAN Cluster 啟用 Virtual SAN 功能完畢，並將 3 台 ESXi 主機加入至 VSAN Cluster 之後，因為選擇採用「手動」的方式來新增 ESXi 主機本機硬碟，所以在管理介面中你可以看到目前的 VSAN 資訊內容，雖然 VSAN Datastore 已經建立完成，但是儲存空間大小卻為「0.00 B」。若剛才選擇採用「自動」的新增方式，則會將 ESXi 主機中「所有本機硬碟」自動加入到 VSAN Datastore 當中。

圖12、採用手動方式，所以目前 VSAN Datastore 儲存空間為 0.00 B

步驟3、宣告加入 VSAN Datastore 的硬碟

點選「磁碟管理」項目後，你可以點選「 建立新的磁碟群組」圖示，一次僅幫「1台」ESXi主機宣告加入 VSAN Datastore 的硬碟，或者點選「 宣告磁碟」圖示，一次幫「多台」ESXi 主機宣告硬碟。此次實作環境中，請點選宣告磁碟圖示，以便同時幫 3 台 ESXi 主機宣告要貢獻本機儲存空間至 VSAN Datastore 的作業。

這個宣告磁碟的動作，其實就是建立「磁碟群組（Disk Group）」的動作，因此 ESXi 成員主機當中的本機硬碟中至少要 1 顆 SSD 固態硬碟，以及1顆機械式硬碟（每組 Disk Group 內最多支援7顆機械式硬碟）。雖然，你可以為不同的 ESXi 主機宣告不同顆數的硬碟數量，甚至沒有本機硬碟的 ESXi 主機也可以加入至 VSAN Cluster 當中，不過根據 VMware 官方的最佳實務建議，管理人員應該盡量保持 VSAN Cluster 當中儲存資源的一致性，此實作中我們為 3 台 ESXi 主機，分別宣告 1 顆 SSD 固態硬碟（8GB）及2 顆機械式硬碟（16GB）。

在彈出的宣告磁碟視窗中，預設會顯示加入 VSAN Cluster 內所有的 ESXi 主機，以及該主機中所安裝的儲存資源（SSD 固態硬碟及機械式硬碟）。只要點選「選取所有合格的磁碟」鈕，便會勾選每台 ESXi 主機當中合乎條件的硬碟，確認無誤後按下確定鈕即可建立磁碟群組。

圖13、宣告 VSAN Cluster 當中的 ESXi 主機的本地端儲存資源

宣告硬碟的動作完成後，在管理介面中請依序點選「首頁 > 儲存區 > vsanDatastore > 管理 > 設定 > 一般」，便可以看到目前的 VSAN Datastore 儲存資源的詳細資訊。此次實作環境中VSAN Cluster目前共有3台ESXi主機，每台 ESXi 主機貢獻 2 顆 16 GB 機械式硬碟（總共 6 顆16 GB 硬碟），所以建立的 VSAN Datastore 儲存空間為 94.45 GB 正確無誤。(請注意，在 VSAN 運作架構中，負責資料快取任務的 SSD 固態硬碟及 Flash 快閃記憶體的儲存空間，僅僅是提供讀取快取及寫入緩衝的資料 I/O，其儲存空間並不會納入VSAN Datastore 內。)

圖15、查詢 vsanDatastore 儲存空間資訊

步驟4、確認 Storage Provider 運作狀態

當建立 VSAN Cluster 之後，每台加入叢集的 ESXi 主機便會擁有「儲存區提供者（Storage Providers）」，並會自動透過它與 vCenter Server 及 Storage Layer 進行溝通作業。

同時，ESXi 主機會透過儲存區提供者自動向 vCenter Server 註冊 SMS（Storage Management Service）服務，接著在 VSAN Cluster 當中會有一台 ESXi 主機擔任「作用中（Active）」角色，負責提供 VSAN Datastore 儲存資訊，其它台 ESXi 主機則擔任「待命（Standby）」角色，只有在擔任作用中角色的 ESXi 主機發生故障損壞事件時，才會自動從待命角色中重新選舉出新的 ESXi 主機擔任作用中的角色。

請在管理介面中依序點選「首頁 > vCenter Server > 管理 > 儲存區提供者」，即可看到目前 VSAN Cluster 當中，每台 ESXi 主機的儲存區提供者運作狀態。倘若此頁面中的運作狀態無法順利顯示時，那麼可以嘗試點選「 同步」圖示，以便將所有 Virtual SAN 儲存區提供者與環境的目前狀態進行同步。

圖16、確認 ESXi 主機儲存區提供者運作狀態

後續，便如同 VSAN 1.0 操作程序一樣，可以定義 VSAN 儲存原則之後，將新建立的 VM 虛擬主機套用所定義的 VSAN 儲存原則，以便決定該台 VM 虛擬主機的可用性及效能等表現。因為在本雜誌第 110 期內容中，已經詳細說明整個操作步驟及流程，因此本文便不再贅述。

4、實作二 - VSAN Cluster水平擴充（Scale-Out）

手動 - 擴充 vsanDatastore 儲存空間

目前的實作環境中 VSAN Cluster 只有 3 台 ESXi 主機，我們將實作演練當 VSAN Cluster 運算資源或儲存空間不足時，便可以透過「水平擴充（Scale-Out）」機制來擴充 ESXi 主機數量，達成同時擴充運算資源及儲存空間的目的。

因為，目前在 VSAN Cluster 當中將磁碟新增至儲存區的選項為「手動」，因此當我們將 1 台 ESXi 主機加入至 VSAN Cluster 之後，並不會自動宣告本地端硬碟並加入儲存空間至 vsanDatastore 當中。所以，雖然快閃磁碟雖然顯示為 4 顆但使用中只有 3 顆，而資料磁碟雖然顯示為 8 顆但使用中只有 6 顆。

圖17、目前 VSAN Cluster 新增磁碟設定為手動模式，所以不會自動宣告硬碟

因此，必須由管理人員手動點選「磁碟管理 > 宣告磁碟」圖示，並且如同先前的宣告磁碟作業程序，將新加入的 ESXi 主機本地端儲存空間，加入到 vsanDatastore 儲存空間當中。當宣告磁碟作業完成之後，你可以再次查看一般內容，便會發現快閃磁碟增加 1 顆（共 4 顆），而資料磁碟則是增加 2 顆（共 8 顆），當然 vsanDatastore 儲存空間也從原本的 94.45 GB 增加為 125.94 GB。

圖18、手動增加 ESXi 本地端儲存空間至 vsanDatastore 儲存資源當中

自動 - 擴充 vsanDatastore 儲存空間

倘若，在 VSAN Cluster 當中將磁碟新增至儲存區的選項設定為「自動」，那麼當我們將 1 台 ESXi 主機加入至 VSAN Cluster 之後，系統便會自動宣告 ESXi 主機的本機硬碟並加入儲存空間至 vsanDatastore 當中。

圖19、將 VSAN Cluster 磁碟新增至儲存區選項調整為自動

因此，後續加入 VSAN Cluster 的 ESXi 主機，只要本地端儲存空間合乎宣告磁碟的規則，那麼便會自動將相關的硬碟加入至 vsanDatastore 儲存空間當中。可以看到 ESXi 主機順利加入 VSAN Cluster 之後，便會發現快閃磁碟又增加 1 顆（共 5 顆），而資料磁碟則是增加 2 顆（共 10 顆），當然 vsanDatastore 儲存空間也從剛才的 125.94 GB 增加為 157.42 GB。

圖20、自動增加 ESXi 本地端儲存空間至 vsanDatastore 儲存資源當中

5、實作三 - 容錯網域（Fault Domain）

「容錯網域（Fault Domain）」是 VSAN 6.0 版本中的新功能，它可以增強 VSAN 運作架構的容錯機制，除了原本可針對磁碟（Disk）、網路（Network）、主機（Host）故障情況進行因應之外。現在，容錯網域機制還可以因應「機櫃（Rack）」及「電力（Power）」等故障事件。

圖片來源： VMware 白皮書 – What`s New VMware Virtual SAN 6.0
圖21、容錯網域（Fault Domain）運作架構示意圖

請在管理介面中，依序點選「Cluster > 管理 > 設定 > 容錯網域」項目，然後按下在 Virtual SAN 叢集容錯網域設定區塊中的「綠色加號」圖示，準備建立容錯網域。

圖22、準備建立容錯網域

在彈出的新增容錯網域視窗中，輸入容錯網域的名稱此實作為「RackA – Fault Domain A」，並且勾選要加入此容錯網域的 ESXi 主機，此實作環境勾選「vsan01 ~ vsan03」等 3 台 ESXi 主機，模擬這 3 台 ESXi 主機放置在機櫃 A 當中。

圖23、建立容錯網域 RackA – Fault Domain A

接著，建立容錯網域「RackB – Fault Domain B」並將「vsan04 ~ vsan06」等 3 台 ESXi 主機加入其中，模擬這 3 台 ESXi 主機放置在機櫃 B 內。因此，可以看到目前 VSAN Cluster 當中共有 6 台 ESXi 主機，並且因為 ESXi 主機所處的機櫃位置不同，分別建立兩個不同的容錯網域，以便因應其中一個機櫃或其電力發生故障損壞事件時，另一組機櫃的 ESXi 主機仍能順利運作不受影響。

圖24、為 VSAN Cluster 建立兩個容錯網域

最後，我們來簡單驗證一下容錯網域的運作機制。原則上，如果建立的儲存原則是具備容錯機制的 RAID-1，也就是採用「容許的故障次數」儲存原則，那麼所建立的 VM 虛擬主機元件「一定」會擺放在「不同」的容錯網域當中，倘若是加快資料存取效能的 RAID-0 也就是「每個物件的磁碟等量區數目」儲存原則，那麼 VM 虛擬主機的元件會「盡量」擺放在不同的容錯網域中。

如下圖所示，我們在名稱為 vsan01 的 ESXi 主機（容錯網域 RackA）中建立 1 台 VM 虛擬主機，查看此台 VM 虛擬主機的元件存放地點後，可以發現 3 份元件有其中 2 份存放在容錯網域 Rack B 的 vsan04、vsan05 的 ESXi 主機當中。

圖25、建立的 VM 虛擬主機元件分別擺放在不同的容錯網域中

6、結語

透過本文的說明，相信讀者已經了解到伴隨新版 vSphere 6.0 一同釋出的 VSAN 6.0，有哪些新增的特色功能機制以及舊有功能的增強部分。

此外，在本文的下半部直接實戰演練相關進階功能，讓管理人員能夠實際了解 VSAN 6.0 的儲存資源建立，以及在實務上必然會使用到的水平擴充機制，同時建立能夠充份因應機櫃及電力發生故障事件時的容錯網域機制。
↧

清除硬碟 Read-Only 及 Offline 狀態

July 29, 2015, 6:39 pm
$
0
0

Q.清除硬碟 Read-Only 及 Offline 狀態？

Error Message：
因為拿到伺服器中，先前有進行過相關的測試動作，所以硬碟變成「Offline」狀態，即使在安裝程序中仍然無法「清除」它的狀態，那麼該如何處理？


Ans：
首先，請按下「Shift + F10」組合鍵，便可以在安裝程序中叫出命令提示字元。請輸入「diskpart」指令進入 Diskpart 互動模式。


鍵入「list disk」指令，了解相關的硬碟狀態，此實作中我將以「Disk 1」為範例。


請依序輸入下列指令「select disk 1 > online disk 1」，接著輸入「clean」指令會產生錯誤訊息，可以看到是因為硬碟狀態為「The media is write protected」也就是 Read-Only的狀態。此時，只要鍵入「attributes disk clear readonly」指令後，即可順利再前執行「clean」指令，來清除硬碟內的相關狀態。


再次用「list disk」指令，可以看到 Disk 1 的狀態已經回到正常，也就是狀態為「Online」並且「GPT」狀態也已經抹除了。



↧

無法刪除硬碟中舊有的 Storage Space vDisk？

July 29, 2015, 6:54 pm
$
0
0

Q.無法刪除硬碟中舊有的 Storage Space vDisk？

Error Message：
因為伺服器中的硬碟，先前有建立 Storage Space 中的 Virtual Disk，但這些硬碟即使伺服器重新安裝作業系統 (安裝程序中看不到這些硬碟!!)，進入 Windows Server 2012 R2 後也看不到這些硬碟 (磁碟管理員中看不到!!)。

在 Storage Space 設定視窗中，可以看到舊有的 Storage Space Virtual Disk 仍然存在，但是卻無法刪除它，該怎麼樣才能順利刪除呢？



Ans：
請以「系統管理員」權限開啟 PowerShell，然後先確認 Storge Pool 的資訊 (此例名稱為 500GPool)，可以看到目前此 Storage Pool 的 IsReadOnly欄位為「True」。此時，請鍵入下列指令將 Storage Pool 的「唯讀狀態解除 (IsReadOnly 為 False)」後即可順利刪除 Virtual Disk 及 Storage Pool 了。
Get-StoragePool -FriendlyName "500GPool" | Set-StoragePool -IsReadOnly $false


↧
↧

115 期 - 自動部署大量 Win8 主機，揮別逐一安裝設定繁

July 31, 2015, 5:51 pm
$
0
0

網管人雜誌

本文刊載於 網管人雜誌第 115 期 - 2015 年 8 月 1 日出刊，NetAdmin 網管人雜誌為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份 1 日出刊您可於各大書店中看到它或透過下列圖示連結至博客來網路書店訂閱它。

文章目錄

1、前言
2、實作 – WDS 部署服務
          部署伺服器及傳輸伺服器角色
          安裝 WDS 部署服務
          WDS 部署服務 – 組態設定
          WDS 部署服務 – 新增開機映像檔
          WDS 部署服務 – 新增安裝映像檔
          WDS 部署服務 – PXE 開機原則
          DHCP 伺服器 – 領域選項
          PXE 網路開機安裝 Windows 8.1
3、整合 MDT 2013 達成精簡部署
          安裝 Windows 8.1 ADK 評定及部署套件
          MDT 2013 – 發佈點組態配置
          MDT 2013 – 匯入 Windows 8.1 映像檔
          MDT 2013 – 客製化組態設定
          MDT 2013 – 規則調整
          MDT 2013 – 發佈映像檔
          PXE 網路開機安裝 Windows 8.1
4、結語

1、前言

在企業或組織中若要部署 5~10 台主機，相信即便沒有編制專責 MIS 人員的小型或微型企業，這樣的部署規模其工作量仍然可以承受，但倘若是部署 50 ~ 100 台主機甚至是 200、300 台主機，即便有編制專責 MIS 人員的中型或大型企業，若沒有採用快速便利且自動化的部署工具，相信對於 MIS 人員來說也是不小的工作負擔。

因此，本文便要介紹說明及實作演練，如何透過 WDS（Windows 部署服務）整合 MDT 2013（Microsoft Deployment Toolkit）自動化部署工具，讓 MIS 人員不用在透過傳統方式以 USB 或 CD/DVD 光碟片，手動為每一台主機安裝作業系統及基礎組態設定，而是透過客製化映像檔及網路傳輸的方式，來達到快速便利且自動化的部署機制。

圖 1、Windows 部署架構運作示意圖
圖片來源： TechNet Blog – Microsoft Deployment Toolkit

2、實作 – WDS 部署服務

事實上，Windows 部署服務的角色在 Windows Server 2003 時代便已經有了，功能不斷演變增強至目前最新的 Windows Server 2012 R2 版本，支援部署的作業系統版本以及此版新增特色功能如下：

  • Client 端作業系統： Windows XP / Vista SP1 / 7 / 8 / 8.1
  • 智慧型裝置： ARM Client （例如 平板電腦、手機、GPS 裝置…等）
  • Server 端作業系統： Windows Server 2003 / 2008 / 2008 R2 / 2012 / 2012 R2
  • 映像檔類型： .wim / .vhd / .vhdx
  • 多點傳送： TFTP / IPv6 / DHCPv6

此外，除了原有支援 Active Directory 網域環境之外，從 Windows Server 2012 版本開始支援「獨立伺服器 （Standalone）」的運作模式。簡單來說，你可以將 Windows 部署服務安裝在獨立伺服器當中，免除 Active Directory 網域環境的相依性，當然 DHCP 及 DNS 角色仍然是必須的，同時也要搭配足夠的權限（必須以本機 Administrators 群組成員的帳號登入）才能順利進行後續的安裝及設定作業。

部署伺服器及傳輸伺服器角色

在 WDS 部署服務的主機中，預設情況下會同時安裝「部署伺服器」及「傳輸伺服器」這兩種角色，其中值得注意的部分有 2 件事情。

首先，WDS 部署服務並不具備叢集感知能力，簡單來說在 Windows 容錯移轉叢集中並沒有 WDS 部署服務的高可用性角色，因此若希望達成 WDS 部署服務主機高可用性的話，可以在網路環境中建立多台 WDS 部署服務主機，以達到備援容錯和負載平衡的目的。第 2 件事情則是，若採用 Server Core 的運作模式，則無法搭配使用 WDS 部署服務。

接下來，我們來看看這兩個伺服器的環境需求部份，在傳輸伺服器方面，只要採用本機 Administrators 群組成員的身分登入即可安裝角色及進行後續設定作業。而在部署伺服器角色的部分，需要搭配的運作環境如下：

  • ADDS（Active Directory Domain Services）：若屆時採用的是「與 Active Directory 整合」運作模式，那麼 WDS 部署服務主機必須是 ADDS 網域控制站或是網域中的成員主機。若採用「獨立伺服器」運作模式，便不需要依靠 ADDS 網域。
  • 權限 / 認證：必須採用 WDS 部署服務主機本機 Administrators 群組成員的身分登入，才能順利安裝此角色。若是採用與 Active Directory 整合運作模式，則必須是 Domain Users 群組的成員才能夠初始化 WDS 部署服務，但若採用獨立伺服器運作模式，則不需要是 Domain Users 群組的成員也能進行初始化。
  • DHCP 伺服器：在 WDS 運作中的網路環境，必須要有 DHCP 伺服器的存在，因為 WDS 部署服務會透過 DHCP 伺服器來派發透過 PXE 啟動主機的 IP 位址。
  • DNS 伺服器：在 WDS 運作中的網路環境，必須要有 DNS 伺服器的存在，那麼 WDS 部署服務機制才能順利運作。
  • NTFS 磁碟區：運作 WDS 部署服務主機，存放映像檔的位置必須是採用 NTFS 檔案系統的磁碟區才行（不支援舊有的 FAT32 及新式的 ReFS等檔案系統）。


圖 2、傳輸伺服器元件架構示意圖
圖片來源： TechNet Library – Windows Deployment Services Server Components

圖 3、部署伺服器元件架構示意圖
圖片來源： TechNet Library – Windows Deployment Services Server Components

安裝 WDS 部署服務

在此次實作環境中，我們將實作與 Active Directory 整合的運作模式，同時在實作環境中網域控制站（DC）主機中，已經運作 DNS / DHCP 服務。因此，我們便著重在說明安裝 WDS 部署服務以及整合 DNS / DHCP 服務的部份。

請切換至 WDS 部署服務主機，開啟伺服器管理員後點選「管理 > 新增角色及功能 > 角色型或功能型安裝 > 從伺服器集區選取伺服器」，在伺服器角色視窗中勾選「Windows 部署服務」項目，在選取角色服務頁面中，確認此台 WDS 部署服務主機安裝「部署伺服器及傳輸伺服器」角色。

圖 4、為 WDS 部署服務主機安裝部署伺服器及傳輸伺服器角色

WDS 部署服務 – 組態設定

Windows 部署服務安裝完成後，在伺服器管理員中依序點選「工具 > Windows 部署服務」準備進行初始化組態設定。在開啟的 Windows 部署服務設定視窗中，點選 WDS 部署服務主機後按下右鍵選擇「設定伺服器」，在安裝選項頁面中，此實作我們採用「與 Active Directory 整合」的運作模式。

圖 5、採用與 Active Directory 整合運作模式

在遠端安裝資料夾位置頁面中，必須要選擇採用 NTFS 檔案系統的磁碟區才行，同時也建議不要與 Windows 系統磁碟區（也就是 C 槽）放一起，以避免影響運作效能。此實作環境中，我們選擇遠端安裝資料夾的路徑為「D:\RemoteInstall」。最後，在 PXE 伺服器初始設定值頁面中，選擇要回應用戶端的類型此實作選擇「回應所有用戶端電腦（已知及未知）」。(請注意!! 指定的遠端安裝資料夾，屆時將會建立遠端安裝資料夾樹狀結構如 Boot、Images、Mgmt...等。)

圖 6、遠端安裝資料夾選擇 Windows 系統磁碟區時出現的警告訊息

WDS 部署服務 – 新增開機映像檔

完成 WDS 部署服務組態設定後，此次實作為透過 WDS 部署服務來處理 Windows 8.1 作業系統的大量部署工作負載，因此，請先掛載 Windows 8.1 作業系統映像檔後，確認在 sources 資料夾內有「boot.wim」開機映像檔存在。

Windows 8.1 作業系統映像檔準備完成後，便可以載入屆時 PXE 用戶端啟動時所使用的開機映像檔，請依序點選 WDS 部署服務主機「開機映像 > 右鍵 > 新增開機映像」項目，選擇 boot.wim 開機映像檔路徑，此實作為「E:\sources\boot.wim」。

圖 7、指定 Windows 8.1 的 boot.wim 開機映像檔路徑

接著，輸入映像檔名稱此實作為「Microsoft Windows 8.1 Enterprise（x86）」，確認後便會將 boot.wim 開機映像檔加入至 WDS 部署服務主機中。（請注意!! 當 Windows 8.1 開機映像檔載入完成後，將會新增 boot.wim 及 boot.wim.bcd 檔案，在 WDS 部署服務主機的遠端安裝資料夾中 boot\x86\Images 路徑下。）

圖 8、新增 PXE 用戶端所要載入的 Windows 8.1 開機映像檔

WDS 部署服務 – 新增安裝映像檔

同樣的，在 Windows 8.1 映像檔中 sources 資料夾內有「install.wim」安裝映像檔，請依序點選 WDS 部署服務主機「安裝映像 > 右鍵 > 新增安裝映像」項目，首先建立映像檔群組此實作環境命名為「Windows 8.1」，接著選擇 install.wim 安裝映像檔路徑，此實作為「E:\sources\install.wim」。

圖 9、指定 Windows 8.1 的 install.wim 安裝映像檔路徑

後續動作都採用預設值即可完成，確認相關資訊後系統便會把 install.wim 安裝映像檔加入至 WDS 部署服務主機中。（此時，將會新增 install.wim 及 Res.RWM 在 WDS 部署服務主機內，遠端安裝資料夾中的 Images\Windows 8.1 路徑下。）

圖 10、新增 Windows 8.1 安裝映像檔

WDS 部署服務 – PXE 開機原則

預設情況下，當 PXE 用戶端開機後取得 DHCP 伺服器所派發的 IP 位址後，會顯示「Press F12 for network service boot」的訊息，此時必須要「手動」按下 F12 鍵才會載入 boot.wim 開機映像檔，否則 PXE 用戶端便會略過並進行主機 BIOS 設定中的下一個開機選項，這樣的預設值可能會造成自動化部署的困擾。

圖 11、預設情況下 PXE 用戶端必須手動按下 F12 鍵才會載入 boot.wim 開機映像檔

因此，我們可以在 WDS 部署服務主機中進行調整，請依序點選「WDS.weithenn.org > 右鍵 > 內容  > 開機」，將 PXE 開機原則由預設的「要求使用者按下 F12 鍵才繼續進行 PXE 開機」項目，調整為「除非使用者按下 ESC 鍵，否則繼續進行 PXE 開機」項目。

圖 12、調整 WDS 部署服務主機中預設 PXE 開機原則

DHCP 伺服器 – 領域選項

此實作環境中，我們將 WDS 部署服務主機與 DHCP 伺服器安裝在「不同台主機」，因此我們到 DHCP 伺服器新增兩個領域選項，分別是「66（開機伺服器主機名稱）」指向 WDS 部署服務主機此實作環境為「192.168.40.151」，以及「67（開機檔案名稱）」指向 WDS 部署服務主機中遠端安裝資料夾的路徑，此實作環境為「boot\x86\wdsnbp.com」（若採用新式 UEFI 則指向 boot\x86\bootmgfw.efi）。

事實上，若是 PXE 用戶端與 WDS / DHCP 伺服器均處於「同一 IP 網段」時，其實可以不用為 DHCP 設定領域選項，但若是在「不同 IP 網段」時，則建議一定要設定 DHCP 領域選項 66、67 的部分。（請注意!! 若 WDS 部署服務與 DHCP 伺服器安裝在「同一台主機」的話，那麼在設定 WDS 部署服務時，將會彈出必須新增領域選項 60 並設定為 PXEClient，同時取消 67 開機檔案名稱領域選項的設定視窗。）

圖 13、DHCP 伺服器新增 66、67 領域選項

PXE 網路開機安裝 Windows 8.1

完成 WDS 部署服務的環境準備後，我們便可以著手測試將一台支援 PXE 網路開機的主機，測試能否順利自動安裝 Windows 8.1 作業系統。在測試結果中，我們可以看到主機透過 PXE 網路開機後，順利取得由 DHCP 伺服器所派發的 Client IP 位址「192.168.40.203」，接著順利找到 WDS 部署服務主機「192.168.40.151」，然後開始載入我們所指定的「\Boot\x86\Images\boot.wim」Windows 8.1 開機映像檔。

圖 14、透過 PXE 網路開機並載入 boot.wim 開機映像檔準備安裝 Windows 8.1

與傳統透過 CD/DVD 安裝過程中稍有不同的部分是，在 Windows 安裝程式的部分會顯示為 Windows 部署服務，在你按下一步鈕之後會彈出連線至 WDS 部署服務主機的授權驗證視窗，請輸入具備 WDS 部署服務主機本機 Administrators 群組成員的管理者帳號及密碼。

圖 15、彈出連線至 WDS 部署服務主機的授權驗證視窗

順利通過驗證程序後，便能順利從 WDS 部署服務主機載入安裝映像檔，後續便是大家所熟悉的 Windows 作業系統安裝程序，也就是選擇安裝的作業系統及選擇進行安裝的硬碟，然後便開始進行安裝作業。

圖 16、透過 WDS 部署服務安裝 Windows 8.1

作業系統安裝完畢之後，請將主機 BIOS 設定中的 PXE 網路開機順序調降，避免主機重新啟動後又自動載入 PXE 開機程序，再次嘗試自動安裝 Windows 8.1 作業系統。

圖 17、順利透過 WDS 部署服務安裝好 Windows 8.1 作業系統

3、整合 MDT 2013 達成精簡部署

雖然，透過 WDS 部署服務可以幫我們達成自動化安裝的動作，但你否覺得有點美中不足呢？ 舉例來說，在企業或組織環境中 Windows 作業系統會加入 Active Directory 網域環境，以及其它的基礎設定...等。

接下來，我們將要實作整合另一個可以幫助企業或組織自動化部署的工具MDT（Microsoft Deployment Toolkit），以達到「精簡部署（Lite Touch Installation，LTI）」的目的。

安裝 Windows 8.1 ADK 評定及部署套件

請切換至 WDS 部署服務主機，在安裝 Windows 8.1 ADK 評定及部署套件頁面中，只要勾選其中 3 個項目進行安裝即可：

  • 部署工具
  • Windows 預先安裝環境 （Windows PE）
  • 使用者狀態遷工具 （USMT）

圖 18、在 WDS 部署服務主機中安裝 Windows 8.1 ADK 評定及部署套件

MDT 2013 – 發佈點組態配置

在 MDT 2013 應用程式安裝的部分，基本上只要採用預設值即可順利安裝完成。目前，最新版本為 MDT 2013 擁有下列新增特色功能：

  • 支援 Windows 8.1 ADK 評定及部署套件。
  • 支援部署 Windows 8.1 及 Windows Server 2012 R2 （若採用 MDT 2013 Update 1 將能支援最新版本的 Windows 10 Technical Preview）。
  • 支援 System Center 2012 R2 Configuration Manager，以達成「零接觸部署（Zero-Touch Installation，ZTI）」的目標。
  • 支援 x86 UEFI 系統。

圖 19、在 WDS 部署服務主機中安裝 MDT 2013

完成 MDT 2013 安裝作業後，開啟「Deployment Workbench」準備進行 MDT 的發佈點組態設定。開啟後，依序點選「Deployment Shares > 右鍵 > New Deployment Share」，在發佈點路徑中此實作環境設定為「D:\DeploymentShare」，在選項頁面中取消勾選所有項目，其餘的設定部分則採用預設值即可。

圖 20、MDT 發佈點組態設定

MDT 2013 – 匯入 Windows 8.1 映像檔

在剛才產生 MDT 發佈點的子項目當中，請依序點選「Operating Systems > 右鍵 > Import Operating System」，在 OS Type 頁面中選擇「Full set of sources files」項目，在 Source 頁面中指向至掛載 Windows 8.1 映像檔路徑此實作為「E:\」，其餘設定值則採用預設值即可。

圖 21、建立發佈映像檔

MDT 2013 – 客製化組態設定

接著，依序點選「Task Sequences > 右鍵 > New Task Sequence」，首先為這個工作設定指定 1 個任務 ID、任務名稱、任務描述，在範本的部分選擇「Standard Client Task Sequence」項目即可，接下來便是大家所熟悉的作業系統初始化組態設定，例如指定屆時安裝作業系統時採用的授權金鑰、作業系統使用者、組織、IE 瀏覽器預設首頁、本機管理者密碼...等。

圖 22、建立客製化組態設定

MDT 2013 – 規則調整

接著，我們進行最後的規則內容組態調校，讓自動化部署流程能夠再更客製化更流暢，請點選 MDT 發佈點後右鍵選擇內容，切換到「Rules」頁籤。

在本次實作環境中，我加入了相關的組態參數值，舉例來說 省略 Windows Deployment 精靈的歡迎畫面（參數 SkipBDDWelcome=YES）...等，同時將主機加入網域的部分，除了在 Rules 組態中加入之外，也加入在 Bootstrap.ini 啟動引導檔案當中。若你對於相關組態參數值的詳細內容及功能有興趣的話，請參考 MDT 2013 Documentation – Toolkit Reference文件即可。

圖 23、客製化組態參數值

MDT 2013 – 發佈映像檔

最後，我們將剛才匯入的 Windows 8.1 映像檔，以及定義好的工作設定及客製化組態參數值重新打包成新的發佈映像檔。請點選 MDT 發佈點後右鍵選擇「Update Deployment Share」，在彈出的精靈視窗中都採用預設值即可，系統便會進行映像檔重新打包的動作。

圖 24、整合 Windows 8.1 映像檔及工作設定後，重新打包為新的發佈映像檔

重新打包後的發佈映像檔，預設存放的路徑為「D:\DeploymentShare\Boot\LiteTouchPE_x86.wim」。請切換到 Windows 部署服務視窗，將此重新打包後的發佈映像檔加入到「開機映像」當中即可。

圖 25、加入重新打包後的發佈映像檔到開機映像當中

PXE 網路開機安裝 Windows 8.1

完成 WDS 部署服務整合 MDT LTI 精簡部署的環境準備後，便可以測試將一台支援 PXE 網路開機的主機，能否順利自動安裝 Windows 8.1 作業系統，可以看到透過 PXE 網路開機後，順利取得 DHCP 伺服器所派發的 Client IP 位址「192.168.40.203」，接著順利找到 WDS 部署服務主機「192.168.40.151」，然後因為兩個開機映像檔的「優先順序相同」，因此會出現 Windows Boot Manager 視窗讓你選擇採用哪個開機映像檔。

圖 26、開機映像檔優先順序相同，必須選擇採用哪個開機映像檔

選定後，便開始載入「\Boot\x86\Images\LiteTouchPE_x86.wim」開機映像檔。

圖 27、WDS 部署服務整合 MDT LTI 精簡部署自動化安裝 Windows 8.1

之後，便會進入「精簡部署（Lite Touch Installation，LTI）」模式，自動化完成 Windows 8.1 作業系統的安裝及初始設定作業如 IE 瀏覽器首頁...等組態設定。

圖 28、LTI 精簡部署模式

4、結語

透過本文的介紹說明及實作演練，讀者應該對於 WDS 部署服務的強大功能感到興趣。事實上，礙於篇幅的關系還有許多功能尚未實作，例如 將企業及組織常用的應用程式如 Office 2013 整合進去，或是整合 SCCM 2012 R2 達到 ZTI 零接觸大量部署…等自動化部署機制，後續文章中在為讀者一一介紹及實作這些實用的自動化部署機制。
↧

PowerShell - 迴圈建立 VM 虛擬主機

August 30, 2015, 5:56 pm
$
0
0

前言

簡單來說，有個建立多個 VM 虛擬主機的大量部署需求，所以這篇筆記就誕生了。

PowerShell 內容及概要說明：
  • $VM_Path： 定義產生的 VM 所要存放的路徑。
  • $HV_Host： 抓取目前執行此 PowerShell Script 的 Hyper-V 電腦名稱當成變數。
  • Options1： 先建立個範本 VM(Bash_VM.vhdx)，用它來部署大量的 VM 虛擬主機。
  • Options2： 建立空的硬碟檔案，並建立 VM 虛擬主機。
  • 設定最大 IOPS： 為避免迴圈建立 VM 虛擬主機造成大量的 IOPS，所以限制每台 VM 虛擬主機最多只能使用 50 IOPS。
  • 指定 vCPU 數量： 指定 VM 虛擬主機的 vCPU 數量。
  • 指定 vRAM 空間： 指定 VM 虛擬主機的 vRAM 空間。
  • 啟動 VM 並加入 Cluster： 最後，啟動 VM 虛擬主機並加入指定的 Hyper-V Cluster。


PowerShell 指令碼內容
$VM_Path = "C:\ClusterStorage\Volume1"
$HV_Host = "$env:computername"

foreach ($i in 1..100)
{
#Create the necessary folders
if (!(Test-Path -Path "$VM_Path\$HV_Host\$HV_Host-VM$i")) {
New-Item -Path "$VM_Path\$HV_Host\$HV_Host-VM$i" -ItemType "Directory"
}

#Option1 - Copy Bash VHDX & Create template VM
Copy-Item "$VM_Path\Bash_VM.vhdx""$VM_Path\$HV_Host\$HV_Host-VM$i.vhdx"
New-VM -Name "$HV_Host-VM$i" -VHDPath "$VM_Path\$HV_Host\$HV_Host-VM$i.vhdx" -Generation 2 -SwitchName "S2S-vSwitch"

#Option2 - Create empty VM
#New-VM -Name "$HV_Host-VM$i" -NewVHDPath "$VM_Path\$HV_Host\$HV_Host-VM$i.vhdx" -NewVHDSizeBytes 50GB  -Generation 2 -SwitchName "S2S-vSwitch"

#Configure Disk IOPS
Set-VMHardDiskDrive -VMName "$HV_Host-VM$i" -MaximumIOPS 50

#Configure CPU Count
Set-VMProcessor -VMName "$HV_Host-VM$i" -Count 2

#Configure Dynamic Memory
Set-VMMemory -VMName "$HV_Host-VM$i" -DynamicMemoryEnabled $True -MaximumBytes 4GB -MinimumBytes 512MB -StartupBytes 2GB

#Start the VM
Start-VM "$HV_Host-VM$i"

#Add the VM to the cluster
Add-ClusterVirtualMachineRole -Cluster "HV-WSFC" -VMName "$HV_Host-VM$i"
}
↧
Search

Q.由 VM 所建立的 S2D Cluster 發生 Disk ID 衝突？

August 31, 2015, 5:34 pm
$
0
0

Q.由 VM 所建立的 S2D Cluster 發生 Disk ID 衝突？

Error Message：
以 VM 主機所架設的微軟新一代 SDS 軟體定義儲存技術 S2D(Storage Spaces Direct)，在進行到檢查 S2D Cluster 的環境檢測時，發生 Disk ID 衝突的問題。


查看詳細的叢集檢測內容，可以發現四台 S2D Node 的 Disk ID 都發生衝突了。



Ans：
只要將四台 S2D Node 關機，並將 SAS/SATA 的「Disk ID」互相錯開後，再次進行叢集的檢查作業即可發現正常了。

↧

Q. S2D 叢集發生 Failed to get SCSI page 83h VPD 的錯誤？

August 31, 2015, 5:54 pm
$
0
0

Q. S2D 叢集發生 Failed to get SCSI page 83h VPD 的錯誤？

Error Message：
以 VM 主機所架設的微軟新一代 SDS 軟體定義儲存技術 S2D(Storage Spaces Direct)，在進行到檢查 S2D Cluster 的環境檢測時，發生「Failed to get SCSI page 83h VPD」的錯誤？


Ans：
詳細資訊請參考 Windows Server Forum - Cluster Validation Test says "Physical disk does not have the inquiry data (SCSI page 83h VPD descriptor)", no disks available as cluster resource討論串，簡單來說 UniqueIdFormat必須要為「Type3 -> FCPH Name」才行。

在 S2D Node 中鍵入 PowerShell 指令「Get-Disk | ft FriendlyName, UniqueIdFormat」後，即可看到目前的欄位值為「Vendor Specific」。


修改的詳細資訊請參考 virtuallyhyper - Enabling disk.EnableUUID on a Nested ESX Host in Workstation 文章。簡單來說，因為此測試環境是 Nested VMs 環境，所以將 S2D Node (VM 虛擬主機)關機後在 .vmx 加入「disk.EnableUUID = "TRUE"」參數即可。S2D Node 修改完畢並重新啟動後，再次鍵入 PowerShell 指令「Get-Disk | ft FriendlyName, UniqueIdFormat」後，可以看到 UniqueIdFormat  欄位值變為「FCPH Name」後，再次進行叢集組態檢查就沒有任何問題的 (畫面中還有警告，是因為另外 3 台 S2D Node 尚未修改參數所致)。


↧
↧

116 期 - 五種 VMware 自家 HA 機制，建構高可用性 vCenter 服務

September 2, 2015, 5:38 am
$
0
0

網管人雜誌

本文刊載於 網管人雜誌第 116 期 - 2015 年 9 月 1 日出刊，NetAdmin 網管人雜誌為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌，下列筆記為本站投稿網管人雜誌獲得刊登的文章，網管人雜誌於每月份 1 日出刊您可於各大書店中看到它或透過下列圖示連結至博客來網路書店訂閱它。

文章目錄

1、前言
2、vCenter Server的重要性
3、vCenter Server高可用性解決方案
          高可用性方案 1、vSphere HA
          高可用性方案 2、vSphere FT
          高可用性方案 3、協力廠商工具
          高可用性方案 4、vCenter Server Heartbeat
          高可用性方案 5、Guest OS Cluster
4、各種版本對高可用性機制的支援
5、高可用性機制的優缺點比較
6、結語

1、前言

對於企業及組織來說，線上營運環境所追求的是能夠穩定運作的服務。因此，目前在企業內部的 VMware vSphere ESXi 虛擬化平台，主流版本應該是 VMware vSphere ESXi 5.x  版本（事實上，仍有部分企業或組織，仍使用更舊的 VMware vSphere ESXi 4.x 版本）。

然而，以最後一版穩定的主流版本 ESXi 5.5 來說，也已經是在 2013 年 9 月時所推出的，雖然至目前為止仍持續不斷釋出相關更新當中。但是，相信企業及組織的 IT 管理人員，應該都已經紛紛評估 2015 年 3 月，正式發行的 VMware vSphere ESXi 6.0 最新版本。

在最新發行的 VMware vSphere 6.0 虛擬化架構版本中，除了整體支援度更加提升之外，最令大家期待的功能之一，應該是 vMotion 即時遷移機制的增強功能，因為此項即時遷移機制已經打破了地域及其它相關限制。

並且，在 vSphere 6.0 當中 vCenter Server 的運作架構也大肆翻新與過往不同，舉例來說，過去在 vCenter Server 5.5 版本時，除了 vCenter Server 本身的服務之外，還必須安裝其它協同運作元件如 Single Sign-On、Inventory Service、vSphere Web Client...等。但是，新版的 vCenter Server 6.0 將這些運作元件，全部整合在一起成為「PSC（Platform Services Controller）」。

圖 1、vCenter Server 協同運作元件升級示意圖
圖片來源： VMware 白皮書 – VMware vCenter Server 6.0 Deployment Guide

過去，在 Windows 作業系統平台上，所安裝的 vCenter Server 版本，內建的預設資料庫一律都是 SQL Server Express。但也因為採用的是 Express 的 SQL Server 版本，除了記憶體被限制只能使用 1 GB之外，資料庫大小也被限制在 10 GB大小，因此 VMware 官方在相關白皮書中，總是建議這樣的資料庫只能承載小於 5 台 ESXi 主機、50 台 VMs的運作架構，一旦超過這樣的架構應該要採用正式版本的 SQL Server 或 Oracle 資料庫。

但是，額外在採購一套正式版本的 SQL Server 給 vCenter Server 使用，對於原本IT預算就吃緊的中小企業來說，是筆額外的負擔。現在，新版的 vCenter Server 6.0 已經將預設內建資料庫更改為 PostgreSQL。除了節省購買資料庫的費用之外，PostgreSQL資料庫可以承載 1,000 台 ESXi 主機及 10,000 台 VM 虛擬主機的運作架構。

值得注意的部分是，若企業或組織舊有的 vCenter Server 運作架構，在建置時採用內建的 SQL Server Express 資料庫，那麼升級為最新版本的 vCenter Server 6.0之後，原有的資料庫內容將會自動遷移轉換為 PostgreSQL資料庫。

2、vCenter Server的重要性

在 VMware vSphere 虛擬化架構中，vCenter Server 的重要性不言而喻，當 vCenter Server 發生故障損壞事件無法正常服務時，雖然短期來看對於虛擬化架構的運作不會造成立即的影響，並且 vSphere HA 高可用性機制仍然持續運作，以因應發生非計劃性災難事件時，讓 VM 虛擬主機能盡量縮短停機時間。

但是，失去了 vCenter Server 的虛擬化架構，管理人員將無法進行任何的管理作業，舉凡 部署 VM 虛擬主機、調整虛擬交換器、遷移 VM 虛擬主機...等。

因此，如何建構高可用性的 vCenter Server 運作架構，便成為非常重要的課題。本文，將要與大家討論各種 vCenter Server 高可用性的優缺點，舉凡 vSphere HA（High Availability）、vSphere FT（Fault Tolerance）、vCenter Server Watchdog、vCenter Server Heartbeat、WSFC（Windows Server Failover Cluster）等，以便IT管理人員可以選擇出對於目前的運作環境，最適合的 vCenter Server 高可用解決方案。

在建構高可用性的 vCenter Server 運作架構之前，我們先了解 vCenter Server 6.0 版本中，最重要的 3 個組成元件：

  • vCenter Server： 包含絕大部分的管理及服務等功能（但不包括PSC所執行的服務）。
  • 資料庫： 用來存放vCenter Server對於虛擬化環境的組態配置資料，資料庫若損毀也將造成vCenter Server無法啟動。
  • PSC： 負責SSO、Licensing、Global Permissions...等服務，與vCenter Server協同運作。


3、vCenter Server高可用性解決方案

事實上，不管是 VMware 本身或其它協力廠商，都有針對 vCenter Server 高可用性部分推出解決方案，本文將會著重在討論 VMware 本身所提供的 vCenter Server 高可用性解決方案，進行功能性的討論以及優缺點比較。

此外，你已經了解到 vCenter Server 整體服務的組成，除了資料庫之外還有 PSC 協同運作的部分。其實，在 PSC 的部分也可以打造出高可用性的運作架構，也就是建立多組 PSC 並透過「複寫 (Replicating)」的方式，讓多台 PSC 主機之間的資料能夠同步，同時配合負載平衡機制，即可建構出高可用性的 PSC 運作機制。

圖 2、PSC高可用性機制運作示意圖
圖片來源： VMware 白皮書 – VMware vCenter Server 6.0 Availability Guide

高可用性方案 1、vSphere HA

第 1 種 vCenter Server 高可用性機制，為大家所熟知的 VMware vSphere High Availability （vSphere HA）機制。在 VI 3.x 及 vSphere 4.x時代稱之為 VMware HA，它是由 EMC Autostart 產品（收購自 Legato Automated Availability Manager）所改寫而成的特色功能。

運作原理是首先加入 HA Cluster 中的前 5 台 ESX/ESXi 主機，便會擔任 Primary Host的角色，而之後加入的 ESX/ESXi 主機則擔任 Secondary Host角色，同時 5 台 Primary Host 角色當中，會自動推舉出 1 台主機，擔任這整體 Primary/Secondary運作架構中的 Active Paimary Host 角色，負責收集所有主機的運作狀態，並且回報給 vCenter Server。

圖 3、舊版 VMware HA 運作架構示意圖
圖片來源： VMware 官方文件 – High Availability and Data Protection

從 vSphere 5版本開始，除了正式改名為vSphere HA之外底層的運作架構也整個翻新，新版的 vSphere HA 機制捨棄原本的 AAM(Automated Availability Manager) 運作架構，改為採用「Fault Domain」及 Master/Slave的運作架構。它會在 HA Cluster 當中為每 1 台 ESXi 主機，安裝 FDM（Fault Domain Manager）代理程式，同時在 Fault Domain 的運作架構中，只會有 1 台 Master 主機其它則為 Slave 主機，只有當 Master 主機發生故障損壞事件後，才會從 Slave 主機中推舉出 1 台新的主機擔任 Master 主機的角色。

圖 4、新版 vSphere HA 運作架構示意圖
圖片來源： EMC Community Network –Architecture and Benefits of VMware vSphere Virtualization

VMware 對於此需求的最佳做法及建議是，採用 vSphere HA並結合 vSphere DRS機制，以提供 vCenter Server 服務最佳可用性。並且，在這樣的虛擬化運作架構中，應該要注意及驗證相關項目，以便因應「所有可用路徑離線（All Paths Down，APD）」、「設備永久遺失（Permanent Device Loss，PDL）」等故障損壞事件：

  • 驗證 vCenter Server 的組態配置，是否都存放於共享儲存資源當中。
  • 驗證 HA Cluster 當中的 ESXi 主機，儲存網路及 VM 網路是否都有建立 NIC Teaming 機制。
  • 驗證 HA Cluster 當中的 ESXi 主機，是否都能存取共享儲存資源以及所有的 VM 虛擬主機。
  • 驗證 HA Cluster 當中的 ESXi 主機，是否建立管理網路的容錯線路（vSphere HA Heartbeat Redundant）。
  • 驗證 HA Cluster 中是否至少存在 2 個共享儲存資源，以便達成 vSphere HA Datastore Heartbeat Redundant 架構。
  • 驗證透過 vSphere Web Client 連線至 vCenter Server 的使用者帳號，是否具備 Cluster Administrator 的權限。
  • 驗證 HA Cluster 當中是否啟用 Admission Controller 機制，以便觸發 vSphere HA 機制時，在 HA Cluster 當中其它存活的 ESXi 主機，具備足夠的硬體資源可承載其它的 VM 虛擬主機。
  • 驗證是否為 vCenter Server 及 Database 虛擬主機，設定 VM Restart Prioirty 等級為 High，以便啟動 vSphere HA 機制時，確保優先啟動這 2 台 VM 虛擬主機。


圖 5、Admission Controller 運作示意圖
圖片來源： VMware 文件 – vSphere vCenter Server 6.0 可用性

Watchdog for vCenter Server
事實上，熟悉 vSphere HA 機制的 IT 管理人員便知，vSphere HA 高可用性機制必須在 ESXi 主機，發生非計劃性的故障損壞事件時，才會透過 vSphere HA 機制在 HA Cluster 中其它存活的 ESXi 主機，將存放在共享儲存資源中的 VM 虛擬主機重新啟動。

若是底層的 ESXi 主機並未發生故障損壞事件，而是 vCenter Server 虛擬主機中本身所運作的服務停止時，那麼 vSphere HA 高可用性機制是幫不上忙的。

在 vCenter Server 6.0 中新增了「Watchdog」監控機制，採用「vCenter Server Processes （PID Watchdog）」或「vCenter Server API （API Watchdog）」的方式，來偵測 vCenter Server 虛擬主機中本身所運作的服務，當運作的服務發生故障事件而停止運作時，前 2 次發生時 Watchdog 會嘗試重新啟動服務，第 3 次若仍無法重新啟動服務時，便會將 VM 虛擬主機重新啟動。

在預設情況下，Watchdog 監控機制便會「自動啟用」，同時它支援 vCenter Server Appliance 以及 Windows vCenter Server 作業平台。此外，Watchdog 監控機制僅最新版本 vCenter Server 6.0 才支援，舊版 vCenter Server 4.x、5.x 並不支援此監控機制。

圖 6、整合 vSphere HA 及 Watchdog 機制保護 vCenter Server 服務示意圖
圖片來源： VMware 白皮書 – VMware vCenter Server 6.0 Availability Guide

高可用性方案 2、vSphere FT

VMware vSphere Fault Tolerance（vSphere FT）特色功能，在過去舊版本中一直被 IT 管理人員所詬病的，就是 VM 虛擬主機的 vCPU 數量。現在，新版 vSphere 6.0 中的 FT 功能，VM虛擬主機最多可以支援至 4 vCPU。(請注意!! 只有採用 Enterprise Plus版本才支援 4 vCPU，若採用的是 Standard及 Enterprise版本的話，VM 虛擬主機最多只能支援至 2 vCPU)

同時，在舊版的 Fault Tolerance 運作環境中，欲啟用 FT 功能的 VM 虛擬主機，除了不能建立任何「快照（Snapshot）」之外，虛擬磁碟也只能使用「EZT（Eager Zeroed Thick）」格式。新版的 FT 功能，除了支援 VM 虛擬主機能夠建立快照之外，在虛擬磁碟的部分也支援所有格式，現在你可以使用「Thin、Thick、EZT」等 3 種格式的虛擬磁碟。

最後，在舊版的 Fault Tolerance 運作機制中，主要及次要 VM 虛擬主機之間，資料同步的方式稱之為「Record-Replay」。新版的 Fault Tolerance 將資料同步機制改變為「Fast Checkpointing」，它的運作機制是透過 xvMotion（Cross-vCenter vMotion），採用持續不斷且大量的 Checkpoints（Multiple/Sec）動作，以達成主要及次要 VM 虛擬主機之間的資料同步作業。

與 vSphere HA 高可用性機制不同的地方在於，當 Cluster 內的 ESXi 主機發生非計劃性故障損壞事件時，vSphere HA 所保護的 vCenter Server 虛擬主機，會從 Cluster 中其它存活的 ESXi 主機上「重新啟動」，因此 vCenter Server 服務的中斷時間大約會是 2 ~ 5 分鐘之間 (實務上，必須視儲存設備的運作效能而定)。

而 vSphere FT 高可用性機制，因為平時主要及次要 VM 虛擬主機之間，便已經透過 Fast Checkpointing 技術同步 2 台主機之間的資料，因此當 Cluster 內的 ESXi 主機發生非計劃性故障損壞事件時，雖然主要 VM 虛擬主機故障損壞無法服務，但次要 VM 虛擬主機將立即接手所有服務，並且將自身角色轉變成為主要主機，同時在另 1 台 ESXi 主機上再建立 1 台次要主機，將目前的資料透過 Checkpointing 技術再次同步，整個 vCenter Server 服務接手期間是沒有中斷時間的（Zero Downtime），同時也不會有任何資料遺失的問題（Zero Data Loss）。

雖然，相較於 vSphere HA 機制 vSphere FT 提供更即時的保護，但是仍有下列限制以及注意事項必須考量：

  • 啟用 vSphere FT 機制的 vCenter Server 虛擬主機，最多僅支援至 4 vCPU 及 64 GB Memory，這樣的 VM 虛擬主機規模無法承受大型虛擬化架構的工作負載。
  • 啟用 vSphere FT 機制的 vCenter Server 虛擬主機，vCPU 及 vRAM 虛擬資源將會重置為「保留（Reservation）」狀態且無法更改，虛擬磁碟也無法增加或刪除。
  • vSphere FT 機制主要是因應 ESXi 主機發生硬體故障事件（Host Level），而無法因應 vCenter Server 應用程式發生的軟體故障事件（Application Level）。
  • vSphere FT 機制無法因應主機進行更新或修復作業，所產生的停機時間。
  • 啟用 vSphere FT 機制後，除了多出 1 台次要主機增加資源消耗之外，由於 2 台主機之間會有大量且頻繁的同步資料行為，因此需要專用 10Gbps 且低延遲的 VMkernel 網路環境。
  • 驗證透過 vSphere Web Client 連線至 vCenter Server 的使用者帳號，是否具備 Cluster Administrator 的權限。


圖 7、整合 vSphere FT 機制保護 vCenter Server 服務示意圖
圖片來源： VMware 白皮書 – VMware vCenter Server 6.0 Availability Guide

高可用性方案 3、協力廠商工具

VMware 在 vSphere HA 機制中，已經開放 Application Monitoring API 介面，讓協力廠商可以透過 API 與 vSphere HA 機制整合在一起，達到保護 VM 虛擬主機上運作的應用程式或服務（Application Level），以補足 vSphere HA 機制只有 Host Level 的缺口。

舉例來說，Symantec ApplicationHA 便是這類的協力廠商工具。此類工具會在 VM 虛擬主機中，安裝代理程式並監控應用程式的健康情況，當應用程式或服務發生錯誤無法啟動時，代理程式會把狀態轉送及回報給 vSphere HA，以便透過 vSphere HA 機制將 VM 虛擬主機重新啟動。

圖 8、Symantec Application HA 運作示意圖
圖片來源： VMware 白皮書 – Virtualizing Business-Critical Applications with Confidence

高可用性方案 4、vCenter Server Heartbeat

vCenter Server Heartbeat 在 2009 年 3 月時正式推出，它是結合 Neverfail 公司的技術而推出的產品。它可以配合運作在實體主機或 VM 虛擬主機的 vCenter Server，並且採用Primary/Secondary的運作架構，2 台主機之間會透過 Heartbeat 通道，監控及交換主機之間的運作狀態及資料，一旦 Primary 主機發生故障事件而停止服務時，Secondary 主機將會立即接手相關服務。

值得注意的是，此產品在 2014 年 6 月便進入 EOA（End Of Availability）狀態，也就是後續將不會再有這個產品出現了。因此，在新版 vCenter Server 6.0當中，並不支援 vCenter Server Heartbeat 高可用性機制，只有舊版 vCenter Server 4.x、5.x 才有支援。

圖 9、vCenter Server Heartbeat 運作示意圖
圖片來源： VMware DataSheet – vCenter Server Heartbeat

高可用性方案 5、Guest OS Cluster

最後 1 種高可用性解決方案，則是透過 vCenter Server 虛擬主機中，所運作的 Guest OS 作業系統來達成，也就是結合「Windows 容錯移轉叢集（Windows Server Failover Cluster，WSFC）」高可用性機制，或稱之為 MicroSoft Cluster Service（MSCS），相關資訊可參考 KB 1004617。

在運作 Windows 容錯移轉叢集架構中，必須要有共享磁碟來擔任「仲裁磁碟（Quorum Disk）」，而共享磁碟通常透過 FC（Fibre Channel）、FCoE、iSCSI...等來提供，同時叢集節點之間也必須建立 Heartbaet 專用網路。

圖 10、Windows 容錯移轉叢集運作架構示意圖
圖片來源： VMware 白皮書 – VMware vCenter Server 6.0 Availability Guide

WSFC 高可用性解決方案為 Application Level 的保護機制，當主要叢集節點上不管是作業系統或服務發生故障事件，另 1 台叢集節點便會立即接手服務。此外，即使叢集節點進行修補或安全性更新作業，都不會影響到線上服務的運作，有效讓停機時間最小化。

目前，vCenter Server 支援建構的 WSFC 版本，為 Windows Server 2008 R2 SP2 以及Windows Server 2012 R2，同時在共享磁碟的部分必須採用 RDM（Raw Device Mapping）的方式進行掛載。

並且，在 vCenter Server 資料庫的部分，必須採用 SQL Server 2012/2014資料庫而不能採用新版內建的 PostgreSQL 資料庫。當安裝好 vCenter Server 服務之後，必須把所有在安裝過程中建立的 VMware 系統服務，都將服務啟動類型設定為「手動」，並在設定高可用性叢集服務時選擇「一般服務」即可。

最後，記得設定 vSphere DRS 中的 Anti-Affinity規則，將建立 WSFC 的 vCenter Server 叢集節點主機，強制分離在不同的 ESXi 主機上運作，避免叢集節點 VM 虛擬主機運作在同一台 ESXi 主機上，相關資訊可參考 KB 1037959。

圖 11、vCenter Server 整合 Windows 容錯移轉叢集運作架構示意圖
圖片來源： VMware 白皮書 – VMware vCenter Server 6.0 Availability Guide

4、各種版本對高可用性機制的支援

至此，我們已經介紹多種 vCenter Server 高可用性解決方案。然而，對於追求穩定服務的企業或組織來說，並非會立即採用官方所發行的最新版本 vCenter Server，那麼該如何針對企業環境中現有的版本選擇最適合的解決方案呢？

下列表格中，我們已經將上述所介紹的各種高可用性解決方案，以及各種 vCenter Server 版本的支援度進行整理：（相關資訊可參考 KB 1024051）


5、高可用性機制的優缺點比較

除了各種 vCenter Server 版本對高可用性解決方案的支援度之外，我們也為讀者整理出各種高可用性機制中，針對容錯移轉時間、成本、複雜度...等各項功能進行比較。

舉例來說，vSphere HA 機制是所有高可用性機制中，在「成本及複雜度」上所花費的營運及管理成本是最低的，但是在容錯移轉時間的花費上卻也是最長的，而 Guest OS Failover（WSFC）高可用性機制，雖然在「容錯移轉時間」的花費上最短，但整體來看成本及複雜度卻是最高的。


6、結語

透過本文的說明，相信IT管理人員已經了解到，目前在企業及組織運作環境中，所採用的 VMware 虛擬化平台 vCenter Server 版本，在評估成本及建置複雜度並考量可接受的停機時間，選擇出最適合採用的高可用性解決方案。
↧

TechDays Taiwan 2015 課程影片及簡報

September 17, 2015, 8:37 am
$
0
0

前言

TechDays Taiwan 2015活動，已經於 2015 年 9 月 17 日正式落幕。因為專案在身而無法親臨現場？ 臨時有要緊事要處理而無法到場？.....等。現在， Microsoft 已經將所有的議程，都收錄到  Channel 9 - TechDays Taiwan 2015 上了，以禰補當天無法親臨現場的遺憾了。

簡報檔及錄影檔

TechDays Taiwan 2015 年會活動，所有的場次議程如下：


今年，很榮幸的我也講了 3 場跟本身技術領域有關的場次，有興趣的朋友可以參考看看：

ITM305

軟體定義儲存 (Software-Defined Storage): 以 Windows Server 打造高成本效益的儲存方案


ECI309

Microsoft Azure RemoteApp 打造隨處存取企業應用程式



ECI303

Azure 給您無所不在的保護： 透過 Microsoft Azure Migration Tool 及 Azure Site Recovery 機制，遷移及保護 Hyper-V / VMware 虛擬化環境

↧

Shared VHDX 的限制

October 1, 2015, 4:50 pm
$
0
0

前言

簡單來說在 Windows Server 2012 R2 當中的「共享式 VHDX 虛擬磁碟 (Shared VHDX)」，具有如下優勢：

  • 解決過去建立 Guest Clustering 的困擾 (擺脫過去只能存取實體架構 SAN LUN 的麻煩)。
  • 允許「多台」主機「同時」存取同一顆磁碟。
  • 支援 Guest Clustering。

但是，在支援進階功能方面則有一些限制，所以在使用上還是需要注意一下。

Shared VHDX支援的特色功能為：

  • 線上新增 Shared VHDX 磁碟給 Guest Clustering VMs。
  • 執行線上即時遷移 Live Migration。


Shared VHDX 不支援的特色功能為：

  • 線上調整 Shared VHDX 磁碟空間大小。
  • 執行線上儲存即時遷移 Storage Live Migration。
  • 執行無共享式線上即時遷移 Shared Nothing Live Migration。
  • 執行 Hyper-V Replica 複寫。

參考資源

↧
Viewing all 596 articles
Browse latest View live
Search
<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>