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

CentOS 7.4 基礎設定 (12) - 關閉不必要的系統服務

October 24, 2017, 1:32 am
$
0
0

前言

最近工作關係開始玩 CentOS 了，本次實作環境中採用的是 CentOS 7.4 (1709) Kernel 3.10.0-693.el7.x86_64)映像檔，也就是新版 CentOS 7.4 最小化安裝版本 (Minimal Install)，那麼開始來玩玩吧。💪



實作環境




關閉不必要的系統服務並了解服務監聽 Port

了解系統啟動的服務以及該服務開啟的相應 Port ，也是主機安全防護的基本功。我們可以使用「netstat」指令，配合 「–tunpl」 參數，顯示系統目前啟動服務及協定等相關資訊。使用到的 5 個參數意義為 t（TCP）、u（UDP）、n（IP 位址及 Port 號）、p（PID 名稱）、l（Listen）服務，這些指令執行後顯示出來的相關欄位解釋如下：

  • Proto：服務運作的協定，通常為 TCP 或 UDP Protocol。
  • Recv-Q：收到的封包 Bytes 數量。
  • Send-Q：傳送的封包 Bytes 數量。
  • Local Address：本地端的 IP 位址及 Port 號。
  • Foreign Address： 遠端主機的 IP 位址及 Port 號。
  • State：連接狀態，此例中僅顯示 Listen 狀態，實際上還有已建立連線（ESTABLISHED）、連線結束等待 Socket 關閉（TIME_WAIT）、主動連線 SYN 封包（SYN_SENT）、連線要求 SYN 封包（SYN_RECV）等狀態。
  • PID / Program name：該程序（Process） 的名稱。

本文環境採用 CentOS 7.4 Minimal Install安裝類型，安裝完畢後可以透過「netstat -tunpl」指令來解目前主機所啟動的服務所帶起的監聽 Port 號，可以看到經由前面的基礎設定作業之後，目前 CentOS 7 主機只 Listen 必要的 SSH / Postfix / Chrony服務。
# netstat -tunpl
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address   Foreign Address   State    PID/Program name
tcp        0      0 0.0.0.0:22168   0.0.0.0:*         LISTEN   3863/sshd
tcp        0      0 127.0.0.1:25    0.0.0.0:*         LISTEN   1089/master
udp        0      0 127.0.0.1:323   0.0.0.0:*         LISTEN   532/chronyd

接著查詢 CentOS 7 主機在預設情況下 (使用 Minimal Install 安裝類型) 啟用哪些服務，後續可以把不需要的服務關閉以便降低安全性問題（有的系統服務可能會開啟 Listen Port），一方面也可以增加系統效能（因為每個服務的啟動都會佔系統記憶體）。
# systemctl list-units --type service |grep running
auditd.service loaded active running Security Auditing Service
chronyd.service loaded active running NTP client/server
crond.service loaded active running Command Scheduler
dbus.service loaded active running D-Bus System Message Bus
firewalld.service loaded active running firewalld - dynamic firewall daemon
getty@tty1.service loaded active running Getty on tty1
hv_fcopy_daemon.service loaded active running Hyper-V FCOPY daemon
hv_kvp_daemon.service loaded active running Hyper-V KVP daemon
hv_vss_daemon.service loaded active running Hyper-V VSS daemon
irqbalance.service loaded active running irqbalance daemon
polkit.service loaded active running Authorization Manager
postfix.service loaded active running Postfix Mail Transport Agent
rsyslog.service loaded active running System Logging Service
sshd.service loaded active running OpenSSH server daemon
systemd-journald.service loaded active running Journal Service
systemd-logind.service loaded active running Login Service
systemd-udevd.service loaded active running udev Kernel Device Manager
tuned.service loaded active running Dynamic System Tuning Daemon
↧
Search

CentOS 7.4 基礎設定 (13) - 調整 I/O Scheduler 為 Noop 加速 Disk I/O

October 24, 2017, 2:04 am
$
0
0

前言

最近工作關係開始玩 CentOS 了，本次實作環境中採用的是 CentOS 7.4 (1709) Kernel 3.10.0-693.el7.x86_64)映像檔，也就是新版 CentOS 7.4 最小化安裝版本 (Minimal Install)，那麼開始來玩玩吧。💪



實作環境




調整 I/O Scheduler 為 Noop 加速 Disk I/O

由於本文的運作環境為 Windows Server 2016 Hyper-V虛擬化平台。因此，根據官方最佳作法 Best Practices for running Linux on Hyper-V | Microsoft Docs 以及 What is the suggested I/O scheduler to improve disk performance when using Red Hat Enterprise Linux with virtualization?文件內容可知，建議將 CentOS I/O Scheduler調整為 Noop以便加速 Disk I/O。
# cat /sys/block/sda/queue/scheduler
noop [deadline] cfq
# echo "noop"> /sys/block/sda/queue/scheduler
# cat /sys/block/sda/queue/scheduler
[noop] deadline cfq

但是，上述方式只是調整 CentOS 運作中的 I/O Scheduler，倘若 CentOS 主機重新啟動時又會恢復預設值。因此，請修改「/etc/default/grub」設定檔在 GRUB_CMDLINE_LINUX 結尾加上「elevator=noop」，並且重新產生 grub.cfg 檔案後，便能避免 CentOS 主機重新啟動時恢復為 cfq 預設值，調整完成後請重新啟動 CentOS 主機。
# grep noop /etc/default/grub
GRUB_CMDLINE_LINUX="crashkernel=auto rhgb quiet elevator=noop"

接著，執行重建 grub.cfg 檔案的動作，值得注意的是採用 BIOS 或 UEFI 在檔案的重建路徑上會有所不同。
  • BIOS-Based： grub2-mkconfig -o /boot/grub2/grub.cfg
  • UEFI-Based： grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg
# grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-3.10.0-693.el7.x86_64
Found initrd image: /boot/initramfs-3.10.0-693.el7.x86_64.img
Found linux image: /boot/vmlinuz-0-rescue-005705789ca240cabc6c4c6e307e549e
Found initrd image: /boot/initramfs-0-rescue-005705789ca240cabc6c4c6e307e549e.img
done



超過 7 vCPU 或 30 GB vRAM 時應關閉 NUMA

由於本文的運作環境為 Windows Server 2016 Hyper-V虛擬化平台，根據官方最佳作法 Best Practices for running Linux on Hyper-V | Microsoft Docs 以及 How to disable NUMA in Red Hat Enterprise Linux system? - Red Hat Customer Portal文件內容可知。

當 Hyper-V 虛擬化平台中的 CentOS 虛擬主機，配置的虛擬硬體超過 7 vCPU 或 30GB vRAM 時，建議加上 numa=off 關閉 NUMA 機制以便最佳化系統運作。因此，請修改「/etc/default/grub」設定檔在 GRUB_CMDLINE_LINUX 結尾加上「numa=off」，並且重新產生 grub.cfg 檔案後重新啟動 CentOS 主機。
# grep numa /etc/default/grub
GRUB_CMDLINE_LINUX="crashkernel=auto rhgb quiet elevator=noop numa=off"

接著，執行重建 grub.cfg 檔案的動作，值得注意的是採用 BIOS 或 UEFI 在檔案的重建路徑上會有所不同。
  • BIOS-Based： grub2-mkconfig -o /boot/grub2/grub.cfg
  • UEFI-Based： grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg
# grub2-mkconfig -o /boot/efi/EFI/centos/grub.cfg
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-3.10.0-693.el7.x86_64
Found initrd image: /boot/initramfs-3.10.0-693.el7.x86_64.img
Found linux image: /boot/vmlinuz-0-rescue-005705789ca240cabc6c4c6e307e549e
Found initrd image: /boot/initramfs-0-rescue-005705789ca240cabc6c4c6e307e549e.img
done
↧
↧

CentOS 7.4 基礎設定 (14) - 完成 CentOS Base VM 的製作

October 24, 2017, 8:57 pm
$
0
0

前言

最近工作關係開始玩 CentOS 了，本次實作環境中採用的是 CentOS 7.4 (1709) Kernel 3.10.0-693.el7.x86_64)映像檔，也就是新版 CentOS 7.4 最小化安裝版本 (Minimal Install)，那麼開始來玩玩吧。💪



實作環境




匯出 CentOS 範本虛擬主機

完成 CentOS 範本虛擬主機的基礎設定後，便可以執行關機後「匯出」(Export)的動作 (事實上，VM 虛擬主機在開機中也能直接匯出)。在 Windows Server 2016 Hyper-V虛擬化平台中，執行 VM 虛擬主機的匯出動作非常簡單，只要點選 VM 虛擬主機後按下滑鼠右鍵，在右鍵選單中選擇「匯出」即可。

圖、準備匯出 VM 虛擬主機

接著，系統會彈出匯出虛擬機器視窗，請選擇要將匯出的 VM 虛擬主機存放於何處。本文實作環境存放於「C:\VMs_Export」(稍後，將會建立以 VM 虛擬主機名稱的資料夾 CentOS74)。


圖、指定匯出路徑

指定好匯出路徑後，按下匯出鍵便會立即執行匯出的動作，可以在 Hyper-V 管理員視窗中該台 VM 虛擬主機的「工作狀態」欄位，看到匯出 VM 虛擬主機的工作進度。

圖、匯出 VM 虛擬主機的工作進度

匯出作業完成後，可以看到在「C:\VMs_Export」資料夾中建立相關子目錄：
  • V:\Export\CentOS74：以該台 VM 虛擬主機名稱命名的子目錄。
  • V:\Export\CentOS74\Virtual Hard Disks：存放該台 VM 虛擬主機的 .vhdx虛擬磁碟。
  • V:\Export\CentOS74\Virtual Machines：存放該台 VM 虛擬主機的 .vmcx / .vmrs組態設定檔。

圖、VM 虛擬主機匯出完成



CentOS 7.4 基礎設定系列文章：

↧

VMware vSAN 6.6 Journey (4) - Deployment

October 26, 2017, 6:00 pm
$
0
0

前言

在第 6 代 vSAN 版本當中，關於「部署」（Deployment）的部分共新增 3 項特色功能（如下所示）。過去，在建構舊版 vSAN 軟體定義儲存運作環境時，最令 IT 管理人員感到困擾的便是建構的 vSAN 叢集中，所有 vSAN 叢集節點主機之間必須透過多點傳送（Multicast）進行溝通，並未支援企業及組織內部常用的單點傳送（Unicast）網路環境。





Deployment 新增特色功能

Easy Install

在過去倘若採用 vCSA (vCenter Server Appliance)佈署 vSAN Cluster 時，必須要先在獨立的 ESXi 主機將 vCSA 佈署完成後，才能夠執行建構 vSAN Cluster 的安裝及組態設定作業。

現在，只要加入 vSAN Node 即可完成啟用 vSAN Cluster 動作，所以無須再啟用 vSAN 之前為 vCSA 配置額外的磁碟，所以有效簡化整體的佈署流程。如下圖所示，為佈署 vCSA 時選擇 vSAN Datastore 及 Datacenter 和 Cluster 名稱，所以管理人員只要點選幾下便可以完成 vCSA 佈署作業。

圖、選擇 vCSA 佈署所要使用的 vSAN Datastore、Datacenter、Cluster
圖片來源： VMware Storage Hub - vSAN 6.6 - Easy Install

如下圖所示，則是 vSAN Node 中具備 1 個快取裝置及 2 個儲存裝置，準備進行硬碟的宣告作業。

圖、vSAN Node 宣告硬碟
圖片來源： VMware Storage Hub - vSAN 6.6 - Easy Install



Multicast Dependency Removed

過去，在建構舊版 vSAN 軟體定義儲存運作環境時，最令 IT 管理人員感到困擾的便是建構的 vSAN Cluster 時，所有 vSAN Node 之間必須透過多點傳送（Multicast）進行溝通，並未支援企業及組織內部常用的單點傳送（Unicast）網路環境。

現在，最新版本的 vSAN 6.6運作環境中，vSAN Cluster 內的 vSAN Node 直接採用「單點傳送」進行溝通作業。此外，舊版的 vSAN 運作環境，只要升級至最新版本的 vSAN 6.6 也將會自動改為採用「單點傳送」進行溝通作業。

圖、vSAN 6.6 當中 vSAN Node 採用單點傳送溝通
圖片來源： VMware Storage Hub - vSAN 6.6 - Multicast Dependency Removed



Extensibility

管理人員只要採用通過 VMware Ready for vSAN驗證程序的伺服器擔任 vSAN Node，便可以輕鬆且快速的完成 vSAN Cluster 的佈署作業。

圖、VMware Ready for vSAN
圖片來源： VMware Ready for vSAN - VMware {code}
↧

VMware vSAN 6.6 Journey (5) - Availability

October 29, 2017, 6:49 am
$
0
0

前言

在第 6 代 vSAN 版本當中，關於「可用性」（Availability）的部分共新增 3 項特色功能（如下所示）。雖然，從第 2 代 vSAN 版本開始，vSAN 叢集便已經能夠建立「延伸叢集」（Stretched Cluster）的運作架構，然而新版 vSAN 6.6 叢集環境能夠結合本地端故障保護機制，讓 vSAN 叢集站台之間的容錯機制更具彈性，甚至能夠結合親和性規則讓儲存原則的管理更具備靈活性。





Availability 新增特色功能

Stretched Cluster Local Failure Protection

從 vSAN 6.0版本開始便支援 vSAN Stretched Cluster 機制，隨著最新版本 vSAN 6.6發佈更加入本地故障保護 (Local Failure Protection)機制，如此一來可以在每個站台當中提供儲存容錯機制，並且支援 RAID-1 / RAID-5 / RAID-6等資料容錯保護機制。

圖、vSAN Stretched Cluster 架構支援本地故障保護機制
圖片來源： VMware Storage Hub - vSAN 6.6 - Stretched Cluster Local Failure Protection

舉例來說，管理人員可以透過 vSphere Web Client 管理介面，管理及組態設定整個 vSAN Cluster 的資料容錯保護層級，在下列的組態設定畫面中 FTT=1表示，在 vSAN Stretched Cluster 運作架構中 2 個站台會啟用 Mirror 資料容錯保護機制。同時，在啟用 RAID-5 Erasure Coding機制確保 vSAN Node 故障損壞時，vSAN Cluster 仍然能夠正常運作。

圖、vSAN Stretched Cluster 架構下組態設定本地故障保護機制
圖片來源： VMware Storage Hub - vSAN 6.6 - Stretched Cluster Local Failure Protection



Stretched Cluster Site Affinity

在最新版本的 vSAN 6.6運作環境中開始加入親和性 (Affinity)機制，以便提升 vSAN Stretched Cluster 運作架構的儲存原則靈活性，舉例來說當 VM 虛擬主機已經具備容錯機制時，例如，Microsoft Active Directory和 Oracle RAC (Real Application Clusters)，便可以透過親和性規則套用至這種類型的 VM 虛擬主機，讓 VM 虛擬主機無須建立跨站台容錯機制，以便最小化工作負載及儲存和網路資源。

圖、組態設定 vSAN Stretched Cluster 親和性儲存原則
圖片來源： VMware Storage Hub - vSAN 6.6 - Stretched Cluster Local Failure Protection



Degraded Device Handling

簡單來說，VMware 持續改進 vSAN Cluster 處理硬體問題的各項機制，例如，預告即將發生故障損壞的儲存設備……等。當相關硬體設備出現故障損壞事件時，那麼 vSAN Cluster 會把該設備標記為 Absent，但是並不會立即執行 Rebuild的動作，主要原因是這種狀況可能是臨時性的 (例如，vSAN Node 重新啟動)，所以預設情況下 vSAN Cluster 會等待 60 分鐘後才會判定會真正故障，然而在這個期間 VM 虛擬主機仍然會正常運作 (因為其它 vSAN Node 還有可用的資料副本)。

圖片來源： VMworld 2017 - Top 10 things to know about vSAN
↧
↧

141 期 - WS2016 持續蛻變 RS3 版本新功能快速預覽

October 31, 2017, 7:25 am
$
0
0

網管人雜誌

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





文章目錄

前言
容錯移轉叢集新功能
          滾動式升級（Rolling Upgrade）
          雲端見證（Cloud Witness）
          健康服務（Health Service）
          容錯網域感知（Fault Domain Awareness）
          VM 虛擬主機負載平衡（VM Load Balancing）
實戰 – 雲端見證
實戰 – VM 虛擬主機負載平衡
          負載平衡模式 – 新叢集節點加入
          負載平衡模式 – 自動負載平衡
結語





前言

於去年 2016 年 10 月發佈的新一代 Windows Server 2016雲端作業系統中，已經帶給大家許多亮眼的新增特色功能，例如，S2D 軟體定義儲存、SDN 軟體定義網路、Container 容器技術……等。同時，為了因應雲端快速變化的趨勢，過往推出大版本的更新方式已經逐漸過時，所以從 Windows 10 及 Windows Server 2016 版本開始採用定期更新的方式，為使用者、開發人員、IT 管理人員帶來新的操作體驗。

目前，開發代號 RS（RedStone）在日前 2017 年 7 月 15 日已經發佈最新更新 RS3版本，那麼我們來快速預覽 Windows Server Insider Preview Build 16237（RS3）版本中，分別針對使用者、開發人員、IT 管理人員提供哪些新增特色功能：

  • 最佳化 Nano Server 容器映像檔： .Net 團隊提供 .Net Core 2.0 及 Nano Server 最佳化容器映像檔，除了可以在 Windows Insider Docker Hub Repo 中下載取得之外，整體容器映像檔佔用的儲存空間也縮小超過 20 %。同時，支援最新 PowerShell 6.0指令碼環境、掛載 SMB 磁碟區、名稱管道對應、運作效能增強……等。此外，在網路功能方面也與 K8S（Kubernetes）協同運作。
  • 預設停用 SMB v1： 2017 年 5 月爆發的 WannaCry 勒索軟體事件，利用 NSA 所發展的攻擊工具 EternalBlus，打造專門攻擊 Windows SMB 服務漏洞的勒索軟體，並且迅速擴散全球上百多個國家遍及 80 多萬台主機。雖然，微軟在 3 月份便已經修補此漏洞，但許多個人和企業及組織並未及時更新才傳出重大災情，因此在新版 RS3 當中預設將直接停用 SMB v1系統功能及相關服務。
  • ReFS 支援重複資料刪除：在目前的 Windows Server 2016 作業系統版本中，倘若 IT 管理人員需要使用重複資料刪除功能時，僅能針對「NTFS」檔案系統的磁碟區啟用此功能。現在，新版 RS3 當中讓「ReFS」檔案系統的磁碟區也能支援重複資料刪除技術。
  • 支援新式 SCM 儲存裝置：目前企業及組織的主流應用中，倘若需要超大儲存空間便採用傳統 HDD 機械式硬碟，但缺點就是 IOPS 儲存效能表現太差，倘若需要快速及高 IOPS 儲存效能時則採用 NVMe 快閃儲存或 SSD 固態硬碟，但缺點為價格太昂貴且有使用壽命的問題。現在，新一代的 SCM（Storage Class Memory）儲存裝置能夠提供相同的高 IOPS 儲存效能，同時耐用度與目前主流的 MLC NAND 快閃儲存相較下提升 10 倍。在新版 RS3 當中已經支援此新式儲存裝置，並可以整合至 S2D 軟體定義儲存技術中。
  • 傳遞主機電力狀態：在 PowerShell 中新增 Set-VM 指令參數 -BatteryPassthroughEnabled，可以讓 Hyper-V 虛擬化平台中的 VM 虛擬主機，感知到 Hyper-V 主機的電力狀態。值得注意的是，必須採用 8.2 版本的 VM 虛擬主機才支援此新增特色功能。
  • 運作 VM 於 NVDIMM 中：當 IT 管理人員希望 VM 虛擬主機，能夠獲得最低延遲時間最高運算效能時，只要在 Hyper-V 虛擬化平台中採用支援的 NVDIMM，那麼 IT 管理人員便可以啟用 vPMEM（Virtualized Persistent Memory）機制，為 VM 虛擬主機新增 vPMEM Controller 之後，即可為 VM 虛擬主機建立 .vhdpmem 虛擬磁碟並運作在高速的 NVDIMM 當中。

圖 1、半導體儲存階層示意圖
圖片來源： IOPscience – Optimal memory configuration analysis in tri-hybrid solid-state drives with storage class memory and multi-level cell/triple-level cell NAND flash memory





容錯移轉叢集新功能

雖然，新版 Windows Server 2016 RS3 帶來許多新增特色功能，然而對於追求穩定營運的企業及組織來說，或許可以先應用到測試/研發環境當中為企業及組織的技術藍圖鋪路，但在營運環境中則需要持續穩定且高可用性的特色功能，例如，Windows Server 容錯移轉叢集。

那麼，我們來看看 Windows Server 2016 容錯移轉叢集中，新增哪些特色功能可以有效幫助 IT 管理人員管理企業及組織的資料中心：



滾動式升級（Rolling Upgrade）

在企業及組織的資料中心內，主流的 Windows Server 作業系統版本相信是 Windows Server 2012 / 2012 R2，並且也已經在容錯移轉叢集中建立許多高可用性角色及服務。那麼，是否有方式可以在沒有任何停機事件發生的情況下，將容錯移轉叢集及叢集節點主機升級至新一代的 Windows Server 2016？ 此時，便可以透過「容錯移轉叢集滾動式升級」（Cluster OS Rolling Upgrade）機制達成。

簡單來說，不同層級的容錯移轉叢集具備不同的特色功能，在 Windows Server 2012 R2環境所建構的容錯移轉叢集，其容錯移轉叢集功能等級為「8」，而新一代 Windows Server 2016容錯移轉叢集功能等級為「9」。

因此，當容錯移轉叢集中叢集節點為 Windows Server 2012 R2，以及 Windows Server 2016 混合並存的環境時，請先不要急著升級容錯移轉叢集功能等級，必須等到容錯移轉叢集中「所有」叢集節點主機，都採用 Windows Server 2016 版本時才進行升級容錯移轉叢集功能等級的動作。

圖 2、容錯移轉叢集滾動式升級流程示意圖
圖片來源： Microsoft Docs – Cluster operating system rolling upgrade



雲端見證（Cloud Witness）

在過去 Windows Server 容錯移轉叢集運作架構中，仲裁機制僅支援「磁碟」（Disk）及「檔案共享」（File Share）這 2 種方式。

雖然，從 Windows Server 2012 作業系統版本開始，容錯移轉叢集運作架構中新增「動態仲裁」（Dynamic Quorum）投票機制特色功能，它可以避免因為叢集節點主機離線導致叢集發生癱瘓的問題，動態仲裁具備下列功能特色：

  • 當叢集節點主機離線時，叢集中的仲裁票數將會動態進行改變。
  • 允許叢集中超過 50 %的叢集節點主機離線，也不會導致容錯移轉叢集發生癱瘓的情況。


在 Windows Server2012 R2作業系統版本中，更將本來動態仲裁的功能增強後更名為「動態見證」（Dynamic Witness），避免叢集節點主機離線、見證資源離線或失敗……等叢集資源故障損壞，而導致容錯移轉叢集發生癱瘓的問題，動態見證具備下列功能特色：

  • 動態見證的叢集節點投票數，將會自動化進行動態調整以便簡化整體配置。
  • 在以往的容錯移轉叢集當中，當叢集節點為「偶數」時必須要建置「仲裁（Quorum）或稱見證（Witness）」，而叢集節點為「奇數」時則無須建置。現在，不管叢集節點數量為何都「應該」要建置見證，當叢集節點為「偶數」時見證會得到 1 票，當叢集節點為「奇數」時見證則沒有投票權（也就是 0 票）。同時，管理人員可以隨時使用 PowerShell 指令【（Get-Cluster）.WitnessDynamicWeight】 指令，查看見證的投票數情況（０ 沒有票、１ 有票）
  • 當見證資源發生「離線」（Offline）或「失敗」（Failed）的故障情況時，將會喪失投票權（也就是 0 票）。此運作機制設計的原因在於，降低以往容錯移轉叢集對於見證資源的過度依賴，避免因為見證資源發生失敗進而影響到容錯移轉叢集的穩定性。
  • 改善以往容錯移轉叢集環境中，主要及備用站台發生重大災難事件時，雖然其中一邊的站台可能擁有 50% 的票數，但卻導致容錯移轉叢集環境發生「腦裂」（Split-Brain）情況的困擾。

有關叢集節點主機離線導致叢集發生癱瘓的詳細資訊，請參考 Windows Server 2012 R2 Evaluation Guide及 Windows Server 2012 R2 Technical Overview文件。
圖 3、動態仲裁運作架構示意圖

因此，考量系統高可用性及穩定性建議 IT 管理人員仍須組態配置見證機制，以便建構出來的容錯移轉叢集運作環境能夠因應更大的災難故障事件。

此外，從 Windows Server 2016作業系統版本開始，建構的容錯移轉叢集運作環境支援第 3 種仲裁機制儲存資源。現在，IT 管理人員可以將由 Windows Server 2016 所建構的容錯移轉叢集運作環境，將仲裁（Quorum）或稱見證（Witness）儲存資源，指向至 Microsoft Azure 儲存體當中。

圖 4、容錯移轉叢集雲端見證運作架構示意圖
圖片來源： Microsoft Docs – Deploy a Cloud Witness for a Failover Cluster



健康服務（Health Service）

透過 Windows Server 2016 容錯移轉叢集中的健康服務特色功能，可以幫助 IT 管理人員輕鬆監控 S2D 軟體定義儲存運作環境的健康狀態，包括，運作資訊，包括，儲存效能 IOPS、Storage Pool 儲存空間、CPU 處理器使用率、記憶體使用率……等硬體資源使用情況。

只要在 PowerShell 指令視窗中，執行【Get-StorageSubSystem Cluster* | Get-StorageHealthReport】指令，IT 管理人員便可以立即看到 S2D 叢集的健康情況及運作資訊。

圖 5、輕鬆監控 S2D 軟體定義儲存運作環境的健康狀態



容錯網域感知（Fault Domain Awareness）

在過去 Windows Server 容錯移轉叢集運作架構中，一律以所有叢集節點主機的可用性來確保營運服務的高可用性。現在，透過 Windows Server 2016 當中的容錯網域感知功能，可以在容錯移轉叢集中定義更細緻的硬體元件項目，包括，站台（Site）、機櫃（Rack）、機箱（Chassis）、叢集節點主機（Node）等 4 個項目。

圖 6、容錯網域感知運作架構示意圖
圖片來源： Microsoft Docs – Fault domain awareness in Windows Server 2016



VM 虛擬主機負載平衡（VM Load Balancing）

在過去 Windows Server 2012 R2 容錯移轉叢集環境中，必須搭配 SCVMM（System Center Virtual Machine Manager）當中的「Dynamic Optimization」特色功能，才能夠達成在容錯移轉叢集中運作的 VM 虛擬主機工作，自動化負載平衡的運作機制。現在，新版 Windows Server 2016容錯移轉叢集環境中，便原生內建自動化「VM 虛擬主機負載平衡」（VM Load Balancing）運作機制。

圖 7、VM 虛擬主機負載平衡機制運作示意圖
圖片來源： Channel 9 – Virtual Machine Load Balancing in Windows Server 2016





實戰 – 雲端見證

當容錯移轉叢集中所有的叢集節點主機都能夠存取網際網路時，IT 管理人員可以考慮採用「雲端見證」（Cloud Witness）機制。當然，倘若運作環境中叢集節點主機「無法」存取網際網路時，請採用剛才磁碟或檔案共用見證機制即可。下列為 IT 管理人員在規劃雲端見證時的注意事項：

  • 容錯移轉叢集並不會儲存產生的存取金鑰，而是產生安全的 SAS（Shared Access Security）權杖。
  • 雲端見證採用 HTTPs REST方式，在叢集節點主機及 Microsoft Azure 儲存體帳戶之間進行溝通。因此，請確保叢集節點主機防火牆規則允許 HTTPs（Port 443）網路流量能夠通過，企業及組織的硬體防火牆或 Proxy 代理伺服器也必須確保 HTTPs（Port 443）網路流量能夠通過。


在開始使用 Microsoft Azure 公有雲資源之前，可以透過 Microsoft Azure Speed Test網站，確認企業及組織內叢集節點主機存取網際網路的連線頻寬，與 Microsoft Azure 全球資料中心之間哪個區域的資料中心距離最近，以便屆時能夠獲得最低的網路延遲時間。舉例來說，目前資料中心內的叢集節點主機與 Microsoft Azure 全球資料中心「東亞」（East Asia）距離最近，平均的網路延遲時間只有 52 ms。

圖 8、確認叢集節點主機與哪個 Microsoft Azure 資料中心距離最近

建立雲端見證機制必須要先建立「Microsoft Azure 儲存體帳戶」，請登入 Microsoft AzurePortal 後，依序點選「新增> Storage > Storageaccount」項目，在建立儲存體帳戶視窗中依序填入或選擇相關項目：

  • 名稱： wsfcwitness
  • 部署模型： Resourcemanager
  • 帳戶種類：一般用途
  • 效能：標準
  • 複寫：本地備援儲存體（LRS）
  • 資源群組： Asia-East-RG
  • 位置：東亞

請注意，在帳戶種類下拉式選單中請選擇「一般用途」項目，因為「Blob 儲存體」項目並不支援 Cloud Witness 功能。在效能的部分請採「標準」項目，因為選擇「進階」將會採用 Azure Premium Storage，但尚未支援 Cloud Witness 功能。最後，在複寫的部分因為雲端見證的仲裁機制，在讀取資料時必須要確保資料的一致性，所以必須選擇「本地備援儲存體（LRS）」項目。
圖 9、建立雲端見證用途的 Microsoft Azure 儲存體帳戶

順利建立 Microsoft Azure 儲存體帳戶之後，系統便會自動產生 2 把金鑰分別是「主要及次要」（Key1、Key2）存取金鑰。因為我們是首次設定雲端見證，所以稍後在設定雲端見證時將會採用「主要存取金鑰」（Primary Access Key）。請按下 Key1 存取金鑰的複製鈕以便複製內容，稍後建立雲端見證時將會使用到。

圖 10、複製 Key1 存取金鑰內容

接著，切換至容錯移轉叢集環境中開啟容錯移轉叢集管理員，依序點選「wsfc.weithenn.org > 其他動作 > 設定叢集仲裁設定 > 選取仲裁見證 > 設定雲端見證」，在設定雲端見證視窗中，請填入 Microsoft Azure 儲存體帳戶名稱此實作環境為「wsfcwitness」，然後填入 Azure 儲存體帳戶的主要存取金鑰（Key1）內容，而 Azure 服務端點則採用預設的 core.windows.net 即可。

圖 11、填入 Microsoft Azure 儲存體帳戶名稱及存取金鑰資訊

成功建立雲端見證機制後可以按下「檢視報告」鈕，再次確認組態設定雲端見證的動作是否順利完成。確認雲端見證順利建立後，按下完成鈕結束雲端見證組態設定作業。

圖 12、確認組態設定雲端見證的動作是否順利完成

完成雲端見證組態設定的動作後，可以看到在容錯移轉叢集管理員視窗中叢集摘要中的見證欄位，將從先前的「無」變更為「雲端見證」，並且在叢集核心資源中也多出「雲端見證」項目。

圖 13、雲端見證組態設定完成

現在，切換到「節點」項目可以看到原先叢集移轉叢集透過動態仲裁運作機制，會有 1 台叢集節點主機的票數為「0」。現在，雲端見證機制建立完成後所有的叢集節點主機票數皆為「1」。此外，當雲端見證機制建立完成後，在 Microsoft Azure 儲存體帳戶中將會產生名稱為「msft-cloud-witness」的容器，並且在該容器內會產生「1 筆」唯一識別碼 ID 記錄同時可以看到該筆記錄的 Blob 檔案大小。
倘若，在同一個 Microsoft Azure 儲存體帳戶為多個容錯移轉叢集建立雲端見證時，便會在 msft-cloud-witness 容器中看到「多筆」唯一識別碼 ID 記錄。
圖 14、雲端見證機制建立後，自動產生 msft-cloud-witness 容器及 Blob 檔案





實戰 – VM 虛擬主機負載平衡

現在，新版 Windows Server 2016 容錯移轉叢集環境中，已經原生內建自動化「VM 虛擬主機負載平衡」（VM Load Balancing）運作機制，並且具備下列特色功能：

  • 零停機解決方案： 透過 Hyper-V 內建的 Live Migration 機制，針對 VM 虛擬主機進行線上不中斷的即時遷移作業。
  • 無縫與容錯移轉叢集進階功能整合：能夠與容錯移轉叢集中其它進階功能，例如，Anti-Affinity、Fault Domains……等機制無縫整合並協同運作。
  • 公平自動化負載平衡觸發機制：針對容錯移轉叢集中，所有叢集節點主機的「CPU」及「記憶體」運算資源使用率，當成是自動化負載平衡機制的觸發標的門檻值。
  • 彈性觸發機制：可以採用多種方式及門檻值決定哪時觸發自動化負載平衡機制。


簡單來說，倘若容錯移轉叢集運作環境中有整合 SCVMM 管理平台的話，那麼仍直接使用 Dynamic Optimization 負載平衡機制即可。倘若，運作環境中沒有 SCVMM 管理平台的話則使用 VM 虛擬主機負載平衡運作機制。那麼，當 2 種機制發生衝突時叢集會採用哪種負載平衡機制？ 預設情況下，一旦叢集啟用 Dynamic Optimization機制之後，便會自動「停用」VM 虛擬主機負載平衡運作機制。



負載平衡模式 – 新叢集節點加入

當容錯移轉叢集加入新的叢集節點主機時，VM 虛擬主機負載平衡運作機制將會依照下列順序，自動將現有叢集節點主機的工作負載移轉至新加入的叢集節點主機：

  • 評估容錯移轉叢集中所有叢集節點主機的工作負載。
  • 辨別哪些叢集節點主機的工作負載超過門檻值。
  • 辨別所有叢集節點主機工作負載的沈重程度，以便稍後優先把工作負載移轉至新加入的叢集節點主機中。
  • 透過 Hyper-V Live Migration 機制，將線上運作中的 VM 虛擬主機即時遷移至新加入的叢集節點主機中。

圖 15、新叢集節點主機加入負載平衡模式運作示意圖
圖片來源： Microsoft Docs – Virtual Machine Load Balancing overview



負載平衡模式 – 自動負載平衡

在目前的容錯移轉叢集中，週期性的評估叢集節點主機的工作負載後，針對「CPU」及「記憶體」等運算資源使用率進行工作負載自動化平衡的動作。
預設情況下，每隔「30 分鐘」便會進行叢集節點主機的工作負載平衡作業。

VM 虛擬主機負載平衡運作機制，將會依照下列順序進行評估叢集節點主機工作負載的動作：
評估容錯移轉叢集中所有叢集節點主機的工作負載。

  • 辨別哪些叢集節點主機的工作負載超過門檻值，哪些叢集節點主機的工作負載在門檻值以下。
  • 辨別所有叢集節點主機工作負載的沈重程度，以便稍後優先把工作負載沈重的叢集節點主機，其上運作的 VM 虛擬主機移轉至工作負載輕微的叢集節點主機中。
  • 透過 Hyper-V Live Migration機制，將工作負載沈重叢集節點主機上的 VM 虛擬主機，即時遷移至工作負載輕微的叢集節點主機中。

圖 16、現有叢集節點主機自動化負載平衡模式運作示意圖
圖片來源： Microsoft Docs – Virtual Machine Load Balancing overview

請在容錯移轉叢集環境中開啟容錯移轉叢集管理員，依序點選「wsfc.weithenn.org > 內容 > 平衡器」後，可以看到有「模式」及「加強」2 個組態設定區塊，下列便是每個選項的功能說明：

模式

  • 在節點加入時使用該節點進行負載平衡： 只有當容錯移轉叢集中新加入叢集節點主機時，才進行負載平衡作業。
  • 一律進行負載平衡：當容錯移轉叢集中新加入叢集節點主機時，以及預設每隔 30 分鐘評估叢集節點主機工作負載後，進行負載平衡作業。

加強

  • 高：每隔 30 分鐘評估叢集節點主機工作負載後，當 CPU 或記憶體等運算資源使用率超過「60 %」時，便執行負載平衡作業。
  • 中：每隔 30 分鐘評估叢集節點主機工作負載後，當 CPU 或記憶體等運算資源使用率超過「70 %」時，便執行負載平衡作業。
  • 低：每隔 30 分鐘評估叢集節點主機工作負載後，當 CPU 或記憶體等運算資源使用率超過「80 %」時，便執行負載平衡作業。

圖 17、組態設定 VM 虛擬主機負載平衡運作機制設定值





結語

透過本文的說明及實作演練，相信讀者已經完全了解雲端見證及 VM 虛擬主機負載平衡這 2 項機制，確實可以幫助企業及組織降低維運成本，同時也能降低 IT 管理人員的維運負擔。
↧

[站長開講] 台灣駭客年會 HITCON Winter Training 2017

November 5, 2017, 5:54 pm
$
0
0

活動簡介

繼 HITCON CMT Mission: Regain The Initiative 的前哨站，悄悄揭開了台灣年度資安盛會 HITCON Pacific的序幕，我們可以看到今年整個攻擊的手法與規模都趨於泛化，表示威脅將越來越貼近大眾的日常生活，從水電、交通運輸到工廠生產系統、關鍵基礎設施及銀行等，或具有聯網能力之 IoT 設備，其遭受網路攻擊的機會大幅增加。

資安不再是發生在新聞中的實境秀，所有人都身在其中。去年我們邀請許多國際資安專家談論資安戰略與發展進程，今年 HITCON Pacific的主題將是 Cyber Force Awakens。我們將呼籲政府、企業乃至於公民等各界取得數位資產的主動權，建立網路力量與資安產業生態系。並邀請國內外專家從資安技術、政策與法規面，探討「數位國土」所面臨的威脅與防禦，為聽眾帶來國際最新的資安觀點及因應對策。

會議中除了有重量級講師，將與國際 CTF 全球 10 強攻防總決戰共同舉辦，我們企盼您加入這項行列，與世界級 CTF 選手共同點亮台灣資安軟硬實力。



活動資訊

  • 日期： 2017 年 12 月 4 ~ 6 日 (星期一 ~ 三)
  • 時間： 9:00 ~ 18:00
  • 地點： 台北市境內，如已達開課人數標準，主辦單位將儘快公布地點
  • 報名： 活動報名



活動內容

本次教育訓練活動共有下列六大類別，而站長的主題教育訓練題議題為「類別五： Windows Security」：
  • 類別一： Malware
  • 類別二： Exploitation Technique
  • 類別三： Incident Response
  • 類別四： Web Security
  • 類別五： Windows Security
  • 類別六： SCADA Security

題目： Anti pass the hash / ticket attack on Windows Server 2016

時間： 2017 年 12 月 06 日

報名： 活動報名

簡介：
過去，雖然企業及組織在整個 IT 基礎架構中，已經部署許多增強安全性的相關運作機制或硬體設備，除了確保線上營運服務不停止之外也保護企業機敏資料不外洩，然而隨著時間的推移駭客攻擊企業及組織的方法也不斷演變及翻新，惡意攻擊的方式也從過往正面對決改採潛伏並轉而朝向最弱環節下手。簡單來說，相較於企業及組織內強調高安全性高效能的線上營運伺服器來說，惡意攻擊方式則改為朝向安全防護相對薄弱的使用者端電腦下手。

在現代化 IT 基礎架構中，為了達到統一且集中式管理的使用者身分驗證機制，在企業及組織當中便會建置目錄服務以達成「單一登入」（Single Sign On，SSO）的目的，一般來說較廣為採用的目錄服務有 Active Directory、OpenLDAP……等，以便使用者只要登入並通過使用者身分驗證機制之後（也就是通過所謂的 3A程序），那麼就能順利存取企業及組織內部中各式各樣的服務了。

雖然，企業及組織透過目錄服務達到 SSO 單一登入，讓使用者只要通過使用者身分驗證程序後便能使用區網內的各項服務。然而，在資訊攻防上面「操作便利性」與「安全性」永遠處於天秤之間不同的兩端，因此針對 SSO 單一登入的惡意攻擊方式便應運而生，也就是大家耳熟能詳的「傳遞雜湊」（Pass-the-Hash，PtH）及「傳遞票證」（Pass-the-Ticket，PtT）攻擊。

為了能夠有效阻擋使用者密碼遭受未經授權的認證竊取攻擊，從 Windows 10 及 Windows Server 2016 版本開始，導入新的安全性機制稱之為「Credential Guard」，它會使用虛擬式安全性的方式來隔離使用者帳號的密碼，因此只有具備特殊權限的系統軟體才能夠存取它們，同時透過保護 NTLM 密碼雜湊以阻擋傳遞雜湊攻擊，或保護 Kerberos 票證以阻擋傳遞票證這種未經使用者授權存取的認證竊取攻擊。

課程摘要：
1) 何謂 3A 程序 驗證（Authentication）、授權（Authorization）、稽核（Accounting）。
2) 何謂傳遞雜湊（Pass-the-Hash，PtH）及傳遞票證（Pass-the-Ticket，PtT）攻擊。
3) 實作演練 Pass-the-Hash 及 Pass-the-Ticket 攻擊。
4) 說明 Credential Guard 概觀及運作方式。
5) 啟用 Credential Guard 安全防護機制。
6) 實作演練 Credential Guard 安全防護機制抵擋 Pass-the-Hash 及 Pass-the-Ticket 攻擊。

學員先修技能：
具備 Windows Server 2016 基本操作技巧。

學員自備工具：
  • 筆記型電腦，筆電要求
  • CPU 處理器支援 Intel VT-x/EPT 或 AMD-V/NPT。
  • 可運作 Windowds 10 企業版/教育版或 Windows Server 2016 虛擬主機。
  • UEFI 2.3.1 或後續版本。
↧

VMware vSAN 6.6 Journey (6) - Performance

November 7, 2017, 5:11 pm
$
0
0

前言

在第 6 代 vSAN版本當中，關於「效能」（Performance）的部分共新增 3 項特色功能（如下所示）。舉例來說，在新版 vSAN 6.6 叢集運作環境中，vSAN 叢集節點主機支援採用最新 Intel 3D XPoint NVMe 快閃儲存（Intel Optane P4800X）。此外，根據 VMware 官方進行的效能測試結果顯示，與舊版 vSAN 6.5 All-Flash 運作架構相較之下，新版 vSAN 6.6 All-Flash 架構整體儲存效能將能提升 50 %或更高。






Performance 新增特色功能

Deduplication and Compression

透過「重複資料刪除」(Deduplication)及「壓縮」(Compression)機制，可以有效降低寶貴的快閃記憶體儲存空間耗用，以提升快閃記憶體每 GB的可用成本。

簡單來說，透過重複資料刪除機制，將會有效針對快取層到容量層之間資料的「De-Staged」方式，以最大程度減少儲存空間的開銷。至於壓縮機制，則是針對「中繼資料」(Metadata)進行壓縮，以便降低 VM 虛擬主機和 vSAN 的「Backend I/O」開銷。

因此，在這 2 種機制的幫助之下，除了降低 vSAN 叢集工作負載之外也提供更可預設的運作效能，甚至當資料寫入行為是「順序寫入」(Dequential Write)時效果將更加明顯。

圖、vSAN 重複資料刪除機制運作示意圖
圖片來源： VMware vSphere Blog - Virtual SAN 6.2 - Deduplication And Compression Deep Dive

圖、vSAN 壓縮機制運作示意圖
圖片來源： VMware vSphere Blog - Virtual SAN 6.2 - Deduplication And Compression Deep Dive



Rebuild and Resynchronization Enhancements

在 VMware vSAN 軟體定義儲存環境中，所有資料將會自動分散在不同 vSAN 節點主機之間，以達到服務高可用性及高運作效能。然而，在某些情況下 vSAN 節點主機之間需要大量同步資料，例如，將儲存原則由原本的 RAID-1變更為 RAID-5時，在  vSAN 節點主機之間的 vSAN 網路流量將會大幅增加。

另外一種情況是 vSAN 進行「修復」(Repair)操作時，也會造成 vSAN 節點主機之間的 vSAN 網路流量大幅增加，舉例來說，當某台 vSAN 節點主機因為發生硬體元件故障損壞事件，此時該台 vSAN 節點主機相關的物件及元件，將會被 vSAN 叢集標示為「Absent」，並且預設情況下會「等待 60 分鐘」之後，倘若標示為 Absent 的物件及元件仍未修復時，便會觸發自動修復機制。

這樣的修復程序設計原因在於，有時 vSAN 節點主機或許只是因為套用安全性更新重新啟動，或短暫的發生小小意外狀態導致暫時離線，但在很短時間內便會自動復原良好的運作狀態。簡單來說，vSAN 希望能夠在合理的時間內等待物件及元件復原，以避免 vSAN 節點主機之間產生大量的網路流量。

此外，當 vSAN 節點主機的可用儲存空間「少於 20%」時，vSAN 將會自動嘗試將資料遷移至其它較多可用空間的 vSAN 節點主機。

值得注意的是，針對 vSAN 修復程序產生的大量網路流量，雖然 vSAN 支援「節流」功能來限制修復程序產生的網路流量，然而此舉除了增加重建程序的執行時間之外，同時也會增加停機的風險。所以，VMware 官方最佳建議作法是保留預設值「禁用節流」(Throtting Disabled)功能較佳。

圖、vSAN 復原程序運作示意圖
圖片來源： VMware Storage Hub - vSAN 6.6 - Rebuild and Resynchronization Enhancements



Checksum, De-Staging, iSCSI

在新版 vSAN 運作環境中，內建原生的「Checksum」機制有助於確保資料完整性，同時也針對資料讀取和寫入路徑進行最佳化，以避免多餘的 Table Lookup 操作而影響運作效能。

雖然，在極少數的情況下，中繼資料的增加可能會對 VM 虛擬主機的 I/O 儲存效能，以及同步操作產生些微的效能影響，例如，大量執行資料刪除作業時，便會大量增加中繼資料。因此，在新版 vSAN 6.6 當中透過「De-Staging」機制避免中繼資料的累積，以避免「寫入密集型」(Write Intensive)的工作負載，因為中繼資料的不斷累積進而影響運作效能。

此外，在 vSAN 運作環境中負責 iSCSI 服務的 FreeBSD 版本，已經升級至新版 FreeBSD 10.3版本，確保 vSAN 6.6 當中的 iSCSI 服務能夠提供更佳的 iSCSI 運作效能。

圖、vSAN iSCSI Target 運作示意圖
圖片來源： vSphere-land - What’s New in VMware VSAN 6.5
↧
Search

[站長開講] 私有雲規劃與建置實務班 - Hyper-V

November 5, 2017, 7:44 am
$
0
0

課程簡介

  • 熟悉雲端運算定義 五種服務特徵、四種部署模型、三種服務類型。
  • 針對建置企業私有雲網路環境時，該如何規劃 VM 虛擬主機的各種傳輸流量，如 VM 網路服務流量、高可用性遷移流量、容錯移轉流量…等以避免造成傳輸瓶頸。
  • 從針對不同儲存設備類型特性的認識，到私有雲運作環境該如何規劃及計算儲存設備 IOPS 效能，以避免資料傳輸瓶頸產生 VM 虛擬主機運作效能不佳的情況。



課程資訊

日期： 2017/12/09 ~ 2018/01/20
時間： 每週六 09:00 ~ 12:00、13:30 ~ 16:30
地點：國立臺北商業大學 (臺北市中正區濟南路一段321號)
網址： Hyper-V 私有雲規劃與建置實務班


↧
↧

VMware vSAN 6.6 Journey (7) - Software Licensing

November 13, 2017, 9:06 am
$
0
0

前言

當企業及組織使用採用舊有 vSAN 版本的話，那麼可能會發現過需要使用進階版或企業版才能使用 All-Flash 全快閃儲存的運作架構，然而從第 5 代 vSAN 6.5 版本開始，所有 vSAN 軟體授權版本皆可以使用 All-Flash 全快閃儲存的運作架構，即使購買的是 ROBO（Remote Office / Branch Office），這種用於企業或組織遠端辦公室的軟體授權版本也支援，因此，即便是由 2 台 vSAN 節點主機所建構的小型 vSAN 運作環境，也能夠使用 All Flash 的硬體運作架構，為需要高 IOPS 儲存效能的分公司或小型 vSAN 環境提供解決方案。



vSAN 6.6 軟體授權

值得注意的是，雖然開放所有 vSAN 軟體授權版本都支援採用 All-Flash 全快閃儲存架構，但是在 All Flash 運作架構中進階特色功能，例如，「重複資料刪除及壓縮」（Deduplication & Compression）、「RAID5/6 Erasure Conding」特色功能，仍需要採用「進階版或企業版」vSAN 軟體授權才能夠使用。

倘若，企業或組織希望達到更高可用性的 vSAN 運作架構，需要建置「延伸叢集」並結合「本地端故障保護機制」特色功能時，那麼只有採用「企業版」（Enterprise）的 vSAN 軟體授權才能使用這些進階特色功能。

圖、VMware vSAN 6.6 軟體授權特色功能清單
圖片來源： VMware vSAN 6.6 Licensing Guide

原則上，vSAN 軟體授權需要額外購買並以「per-CPU」的方式計價，同時企業或組織購買的 VMware vSphere 或 VMware vSphere with Operations Management 軟體授權，並未包含 vSAN 軟體授權。此外，若採購的是 vSAN for ROBO 軟體授權版本的話，則是以每「25 VM 虛擬主機」為採購單位。

倘若，企業或組織需要建購 VDI 虛擬桌面運作架構的話，可以購買 vSAN for Desktop Advanced 軟體授權，因為此版軟體授權將包含 VMware Horizon Advaned 及 vSAN Enterprise 版本，讓企業及組織可以在建構 VDI 虛擬桌面的同時，便於輕鬆導入 vSAN 軟體定義儲存技術。

圖、vSAN for ROBO 運作架構示意圖
圖片來源： VMware vSAN 6.6 Licensing Guide
↧

142 期 - 虛擬桌面 VMware 再出招新版 Horizon 7.2 大提升

December 6, 2017, 7:54 am
$
0
0

網管人雜誌

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





文章目錄

前言
實戰 Horizon 7 基礎架構組態設定
          建構 vSphere 虛擬化平台
          建立 Windows AD 網域環境
          建構 Connection 伺服器角色
          建構 SQL Server 資料庫
          建構 Composer 伺服器角色
          新增 Horizon 7 軟體授權
          新增 vCenter / Composer 伺服器角色
          組態設定 Event 資料庫
結語





前言

事實上，VMware VDI 虛擬桌面解決方案，從 2008 年開始發行 VMware View Manager 3 產品，經過多年的演變已經是非常成熟且豐富的 VDI 虛擬桌面解決方案，最新版本為 2017 年 6 月 20 日所發佈的 VMware Horizon 7.2，除了原有特色功能不斷增強並新增其它特色功能，例如，Horizon Help Desk Tool、Instant Clones、True SSO、Smart Policies、Blast Extreme……等之外，對於開始源始碼的 Linux 作業系統也不斷提升支援度，例如，Horizon Agent for Linux。

同時，隨著 VMware vSAN（Virtual SAN）軟體定義儲存技術不斷發展，新版的 VMware Horizon 也能與最新版本的 Virtual SAN 6.6一起協同運作，擔任 VDI 虛擬桌面儲存資源的角色，並且整合 vSAN 加密機制保護企業及組織的機敏資訊。

那麼，讓我們來看看最新推出的 VMware Horizon 7.2版本中，有哪些重要或新增的亮眼特色功能：
  • Horizon Help Desk Tool： VMware Horizon 的管理人員，可以透過 Horizon Help Desk Tool 取得 Horizon 7 使用者工作階段的運作狀態，以便幫助使用者進行故障排除和維運作業。
  • 增強的身分驗證機制：透過「遞迴解除鎖定」（Recusive Unlock）特色功能，可以在使用者的 VDI 虛擬桌面主機在解除鎖定後，將所有遠端的連線工作階段也一併解除鎖定。
  • Workspace ONE 存取原則： VMware Horizon 的管理人員，只要在 Horizon Administrator 管理介面中組態設定 Workspace ONE 存取原則，便可以讓使用者透過 Workspace ONE 登入後，存取已經發佈的桌面平台和應用程式。
  • Cloud Pod 運作架構： VMware Horizon 的管理人員，可以在 Horizon Administrator 管理介面中組態設定受限制的全域權利。同時，整個 Cloud Pod 的工作階段總數上限增加至 120,000。
  • True SSO： 透過為連線伺服器組態設定 LDAP URL 過濾機制，以便識別沒有 AD UPN 的網域使用者帳號。
  • 增強的連線伺服器：單台連線伺服器執行個體的同時連線數量上限增加至 4,000，包括 Direct Connections、PcoIP 安全閘道連線、Blast 安全閘道連線。同時，單台連線伺服器可為 vCenter Server 提供 4,000 個完整複製、即時複製、連結複製等工作任務。
  • vSAN： 可以在 Horizon 7 佈署環境中順利啟用 vSAN 加密功能，以便保護企業及組織的機敏資訊。
  • 已發佈的應用程式和集區： VMware Horizon 的管理人員，可以透過智慧原則機制來管控已發佈應用程式的行為，並且將標記新增至應用程式集區當中，以便應用程式在 Horizon Client 當中更快速開啟。
  • Horizon Agent for Linux：建立的 Linux 虛擬桌面，可以支援 CDR 用戶端磁碟機重新導向、USB 裝置重新導向、HTML Access 音訊輸出等特色功能。同時，支援主流 RHEL 6 / 7 及 CentOS 6 / 7 版本。

圖 1、Horizon 7 運作架構示意圖
圖片來源： VMware Technical White Paper – Horizon 7 Enterprise Edition Reference Architecture





實戰 Horizon 7 基礎架構組態設定

了解最新 Horizon 7虛擬桌面運作架構及特色功能後，在開始進行 Horizon 7 基礎架構的組態設定作業之前，先了解在 VMware Horizon 的運作架構中，需要建置的角色共有 ESXi 虛擬化平台、vCenter Server、Windows AD 網域環境（DNS / DHCP / Certificate Authority）、Identity Management 機制、View Connection Server、View Composer Server、SMTP、RSA SecurID、WorkSpace、vRealize Operations……等。

雖然建置 Horizon 虛擬桌面基礎架構，在相關伺服器角色上並沒有絕對的先後順序，不過在建構基礎架構時卻有相關的工法可供遵循，接下來我們將簡介本文整個 Horizon 基礎架構的安裝及設定流程：

1. 安裝及組態設定 vSphere 虛擬化平台（ESXi、vCenter Server）。
2. 建立 Windows AD（Active Directory）網域環境。
3. 安裝及組態設定 View Connection 伺服器角色。
4. 安裝及組態設定 SQL Server 資料庫。
4. 安裝及組態設定 View Composer 伺服器角色，並且設定 Composer 資料庫連接事宜。
5. 登入 Horizon View Administrator 管理介面，新增 Horizon 7 軟體授權。
6. 新增 vCenter 及 Composer 伺服器角色。
7. 組態設定 Event 資料庫。

圖 2、Horizon 7 基礎架構運作示意圖
圖片來源： VMware Technical White Paper – VMware Horizon 7 Overview



建構 vSphere 虛擬化平台

vCenter Server
在 VMware Horizon 營運環境中，VMware 官方建議應該將擔任「管理」用途的 VM 虛擬主機，以及擔任 VDI 虛擬桌面的 VM 虛擬主機，分別採用「不同台」vCenter Server 分開進行管理，除了避免運作架構（例如，虛擬網路）複雜化之外，在管理思維上也可以避免 SPOF 單點失敗的影響，舉例來說，倘若管理 VDI 虛擬桌面環境的 vCenter Server 發生故障損壞事件，短期之間難以修復的話可以先讓管理環境的 vCenter Server 暫時接手管理作業。

此外，雖然每台 vCenter Server 可以管理最多 2,000 台 ESXi 主機，以及 25,000 台運作中和 35,000 台註冊的 VM 虛擬主機，然而有鑑於組態配置及高可用性管理需求，最佳建議為「每個 Horizon Block」當中「每台」vCenter Server 管理數量 2,000 ~ 2,500 台 VDI 虛擬桌面。這樣的運作規模大小，建議採用的 vCenter Server 版本及資源配置如下：
  • Windows Server 2012 R2 或之後的版本。
  • VMware Virtual Hardware 11 或之後的版本。
  • vCenter Server 6.0 Update 1 或之後的版本。
  • 8 vCPU、24 GB vRAM、1 vNIC（VMXNET 3）、200GB vDisk（LSI Logic SAS）。

圖 3、Horizon Pod 及 Block 運作架構示意圖
圖片來源： VMware Technical White Paper – Horizon 7 Enterprise Edition Reference Architecture


ESXi Host
在本文實作環境中，採用最新 vSphere ESXi 6.5.0 Update 1版本，以便提供最新且穩定的虛擬化平台，並且屆時運作的 Horizon VDI 虛擬桌面，也將因為採用最新 ESXi 虛擬化平台，可以使用最新虛擬硬體版本獲得最大硬體資源及延展性。

圖 4、採用最新 vSphere ESXi 6.5.0 Update 1 虛擬化平台版本

此外，管理人員對於每台 ESXi 主機，能夠同時運作多少台 VDI 虛擬桌面應該非常好奇，然而應該怎麼估算每台 ESXi 主機能夠運作多少台 VDI 虛擬桌面。舉例來說，倘若我們希望每台 ESXi 主機，能夠同時承載 100 台 VDI 虛擬桌面時該怎麼估算，假設我們為每台 VDI 虛擬桌面配置 1 vCPU，並且使用 350 MHz的 CPU 運算資源，同時預估 vCPU 額外負載為 10 %。

在 ESXi 主機的部分，配置 2 顆 CPU 處理器且每顆處理器擁有 12 個運算核心，每個運算核心的時脈為 2.7 GHz，所以每顆 CPU 擁有 32.4 GHz 的運算能力，每台 ESXi 主機擁有 64.8 GHz 的運算能力，保留 ESXi 主機額外負載 10 %，保留 90 %的運算能力也就是「58.32 GHz」。因此，每台 ESXi 主機在 CPU 運算能力資源方面，可以運作這樣的 VDI 虛擬桌面為「151 台」。

同樣的，我們預計每台 VDI 虛擬桌面，運作 Windows 10 作業系統（32 位元）及使用 1920 x 1600 解析度，配置 4 GB 記憶體空間，每台 VDI 虛擬桌面的 vRAM 額外負載為 48.46 MB，未設定「Memory Reservation」記憶體空間預先保留機制。

在 ESXi 主機的部分配置 512 GB 記憶體空間，保留 ESXi 主機及額外負載 10 % 之後，保留 90 % 的記憶體可用資源為 460.8GB。因此，每台 ESXi 主機在 Memory 記憶體資源方面，可以運作這樣的 VDI 虛擬桌面為「115 台」。

圖 5、VM 虛擬主機額外負載資訊
圖片來源： VMware vSphere Documentation Center – Overhead Memory on Virtual Machines


vSphere Cluster
在 Horizon VDI 虛擬桌面運作架構中，針對 vSphere Cluster 的部分會把「管理」用途及「VDI 虛擬桌面」用途分開，並且由「同台」或「不同台」vCenter Server 主機進行管理，舉例來說，建立第 1 個 vSphere Cluster 名稱為「Management」，在這個 vSphere Cluster 當中由多台 ESXi 主機組成，並運作所有擔任管理工作任務的 VM 虛擬主機，例如，View Connection Server、SQL Server…… 等。同時，除了其上運作應用服務建立高可用性機制之外，這個 vSphere Cluster 也必須啟用「vSphere HA」及「vSphere DRS」機制，以確保管理用途的 VM 虛擬主機所提供的服務具備高可用性。

第 2 個 vSphere Cluster 名稱為「Desktop」，此 vSphere Cluster 由多台 ESXi 主機組成並且運作數百台 VDI 虛擬桌面主機。值得注意的是，在此 vSphere Cluster 中只會啟用「vSphere DRS」機制進行工作負載自動平衡機制即可，「不」建議啟用 vSphere HA 高可用性機制，原因在於每台 ESXi 主機已經運作許多 VDI 虛擬桌面主機，倘若啟用 vSphere HA 高可用性機制的話，當某台 ESXi 成員主機發生故障損壞的情況時，因為 vSphere HA 高可用性機制的緣故，將會造成其它台 ESXi 成員主機的工作負載瞬間加重，因此不建議開啟 vSphere HA 機制。

第 3 個 vSphere Cluster 名稱為「3D Graphic Desktops」，此 vSphere Cluster 與第 2 個 VDI 虛擬桌面用途的主要差異在於，此 Cluster 中的 ESXi 成員主機有配置 GPU 顯示卡。事實上，在第 2 個 VDI 虛擬桌面主要用途為適合執行一般文書處理作業，或者是簡單的 2D 圖形處理，倘若嘗試開啟 3D 圖形時將會發生整個使用者操作體驗很差，原因在於必須透過 ESXi 主機的 CPU 運算資源來模擬及處理 3D 圖形作業。此時，採用安裝 GPU 顯示卡所建構的 VDI 虛擬桌面，便可以順暢執行 3D 圖形處理的工作任務，例如，Maya、AutoCAD、Solidworks…… 等，並且得到良好的使用者操作體驗。

圖 6、vSphere Cluster 運作架構規劃示意圖
圖片來源： VMware Technical White Paper – Horizon 7 Enterprise Edition Reference Architecture


Networking
在 Horizon VDI 虛擬桌面運作架構中，擔任整個基礎架構的部份便是大家所熟悉的 vSphere ESXi 虛擬化平台，以及整個運作架構的管理中心 vCenter Server。倘若，運作環境中 ESXi 主機數量不多的話，那麼採用標準型交換器 vSS（vNetwork Standard Switch）的話，IT 管理人員可能還能夠負擔維運重任，但是 ESXi 主機數量眾多時，強烈建議採用分佈式交換器  vDS（vNetwork Distributed Switch），否則將會造成後續維運管理上很大的負擔及困擾，舉例來說，在具備 16 台 ESXi 成員主機的 vSphere Cluster 網路環境中，當需要變更某個虛擬交換器中連接埠群組（Port Group）名稱時，在 vDS 分佈式交換器環境中只要修改 1 次即可，但在 vSS 標準型交換器環境中就必須要逐台修改 16 次才行。

此外，在每台 ESXi 主機上建議配置 2 張 1 Port 的 10 Gbps 網路卡，分別連接到不同台實體網路交換器上，以避免網路卡或網路交換器發生故障損壞事件造成 SPOF 單點失敗的問題，並且依據流量用途分別規劃出「4 種」Port Group，以便搭配 vDS 分佈式交換器中的 NIOC（Network I/O Control）網路流量管控機制，同時也便於管理人員掌握各種網路流量的傳輸情況以利故障排除作業：
  • Management：負責 ESXi 主機的管理流量，建議網路流量共享層級及數值設定為 Normal 及 50。
  • VMNet：管理用途的 VM 虛擬主機對外流量，以及 VDI 虛擬桌面對外提供服務的流量，建議網路流量共享層級及數值設定為 High 及 100。
  • Storage： Virtual SAN 或 iSCSI MPIO 儲存網路傳輸流量，建議網路流量共享層級及數值設定為 Normal 及 50。
  • vMotion： 用於 vSphere vMotion 線上即時遷移 VM 虛擬主機的傳輸流量，建議網路流量共享層級及數值設定為 Normal 及 50。

圖 7、Horizon VDI 虛擬桌面網路流量規劃示意圖
圖片來源： VMware Technical White Paper – Horizon 7 Enterprise Edition Reference Architecture



建立 Windows AD 網域環境

以往在建構單純 vSphere 伺服器虛擬化環境時，可以選擇是否建置 Windows AD 網域環境。然而，在建構 Horizon VDI 虛擬桌面環境時，在許多應用情境當中 VDI 虛擬桌面採用 Windows 作業系統，因此「必須」要建置 Windows AD 網域環境，以便透過 Windows AD 網域的網域控制站 DC（Domain Controller），達成使用者身分「驗證（Authentication）/ 授權（Authorization）」的機制。

建議採用的 Windows 網域控制站版本及資源配置如下：
  • Windows Server 2012 R2 或之後的版本。
  • VMware Virtual Hardware 11 或之後的版本。
  • 2 vCPU、6 GB vRAM、1 vNIC（VMXNET 3）、40 GB vDisk（LSI Logic SAS）。

圖 8、使用者身份驗證及授權邏輯架構運作示意圖
圖片來源： VMware Technical White Paper – Horizon 7 Enterprise Edition Reference Architecture

同時，在 Horizon VDI 虛擬桌面運作環境中，為了確保使用者登入時操作環境的一致性，便會使用「漫遊使用者設定檔」（Roaming User Profiles）的方式，在使用者登入 VDI 虛擬桌面時載入以便確保操作環境。

在 Windows 使用者設定檔中有 3 種類型，分別是強制使用者設定檔（Mandatory User Profiles）、漫遊使用者設定檔（Roaming User Profiles）、本機使用者設定檔（Local User Profiles），然而不管哪種使用者設定檔中包含許多運作元件，例如，Local Data、User Data、User Registry……等。

圖 9、使用者操作環境配置策略架構示意圖
圖片來源： VMware Technical White Paper – Horizon 7 Enterprise Edition Reference Architecture

在本文實作環境中，將會建立名稱為 Horizon-VDI的 OU 容器，並於其下再建立 VDI Users、VDI Computers等 2 個子 OU 容器，以便屆時存放 VDI 虛擬桌面的使用者帳號及群組，以及 VDI 虛擬桌面的電腦帳戶，這樣設計 OU 設計優點在於方便後續套用 GPO 群組原則時，可以依照 OU 容器進行套用。當然，實務上管理人員可以在針對不同 VDI 虛擬桌面用途，建立更多的 OU 容器進行區隔以便進行更細緻的 GPO 群組原則。

圖 10、建立 Horizon VDI 虛擬桌面專用 OU 容器



建構 Connection 伺服器角色

在 Horiozn 運作架構中 Connection Server，為負責擔任 VDI 虛擬桌面「代理人」（Broker）的角色，因為 VDI 虛擬桌面中的「代理程式」（Agent），隨時會將目前的運作狀態回報給 Connection Server，所以 Connection Server 將會得知每台 VDI 虛擬桌面的運作狀態，例如，桌面目前狀態為可用、更新中、重新啟動中……等。

圖 11、單台 View Connection Server 運作架構示意圖
圖片來源： VMware Technical White Paper – Horizon 7 Enterprise Edition Reference Architecture

在 VMware 最佳作法當中，每台 View Connection Server 最大支援 2,000 PCoIP / Blast Extreme 連線階段。因此，倘若建構的 Horizon 運作架構需要高可用性時，建議採用「N + 1」運作架構。「每台」View Connection Server 建議採用的版本及資源配置如下：
  • Windows Server 2012 R2 或之後的版本。
  • VMware Virtual Hardware 11 或之後的版本。
  • Horizon View 7.0 或之後的版本。
  • 4 vCPU、12 GB vRAM、1 vNIC（VMXNET 3）、40 GB vDisk（LSI Logic SAS）。

圖 12、高可用性 View Connection Server 運作架構示意圖
圖片來源： VMware Technical White Paper – Horizon 7 Enterprise Edition Reference Architecture

在本文實作環境中，採用最新 Horizon 7.2.0 的 View Connection Server 版本，在安裝流程中於安全選項頁面時，請選擇「Horizon 7標準伺服器」並勾選「安裝 HTML Access」項目，以便屆時也可以透過 HTML 網頁連接至 VDI 虛擬桌面，最後請確認採用「IPv4」通訊協定即可。

圖 13、安裝 View Connection Server

安裝完成後，雖然整個 Horizon VDI 虛擬桌面運作架構還在建構當中，但是因為 Connection Server 已經安裝完畢，所以可以先確認及登入至 Horizon Administrator 管理平台，以便確認 Connection Server 及相關服務正常運作。

圖 14、登入 Horizon Administrator 管理平台



建構 SQL Server 資料庫

在 Horizon VDI 虛擬桌面運作架構中，SQL Server 資料庫將會用於存放「Composer Server」組態設定資料，以及屆時 Horizon 系統管理及 VDI 虛擬桌面的「Event」事件資訊。
建議採用的 SQL Server 版本及資源配置如下：
  • Windows Server 2012 R2 或之後的版本。
  • SQL Server 2012 Standard SP2 或之後的版本。
  • VMware Virtual Hardware 11 或之後的版本。
  • 2 vCPU、8 GB vRAM、1 vNIC（VMXNET 3）、40 GB / 50 GB vDisk（LSI Logic SAS）。


在本文實作環境中採用 SQL Server 2014 SP1 版本，並且分別建立 Composer Server 使用的「Composer-DB」資料庫，以及後續存放 Horizon VDI 事件用途的「Event-DB」資料庫。

圖 15、建立 Composer Server 及 Event 用途的資料庫



建構 Composer 伺服器角色

在 Horiozn 運作架構中，透過 Composer Server「連結複製」（Linked Virtual Machine Clones）的運作機制，為每台 VDI 虛擬桌面主機建立「唯一指標」（Unique Pointers），因此每台 VDI 虛擬桌面主機所佔用的空間只會有「差異」的部份而已，與 Master Image 佔用空間相較之下通常可以減少 50 ~ 70 %的空間大小。

同時，在每個 Horizon Block 運作架構中，「每台」View Composer Server 會與 vCenter Server 進行配對，所以在運作架構上同樣以 2,000 個連線階段的最大值為最佳規劃。

建議採用的 View Composer Server 版本及資源配置如下：
  • Windows Server 2012 R2 或之後的版本。
  • VMware Virtual Hardware 11 或之後的版本。
  • Horizon View Composer 7.0 或之後的版本。
  • 4 vCPU、12GB vRAM、1 vNIC（VMXNET 3）、40GB vDisk（LSI Logic SAS）。


在本文實作環境中，採用最新 Horizon 7.2.0 的 View Composer Server 版本。值得注意的是，為了能夠順利將 Composer Server 的資料庫，指向至剛才所建立專用的 SQL Server 資料庫主機，所以必須先為 Composer Server 組態設定 ODBC，以便能夠將 Composer Server 資料庫指向至剛才所規劃的「Composer-DB」資料庫中。

圖 16、為 Composer Server 組態設定 ODBC 資料庫連線工作任務



新增 Horizon 7 軟體授權

登入 Horizon 7 管理介面後，首先必須要新增 Horizon 7 軟體授權才行，否則後續將無法使用 Horizon 相關特色功能，例如，Composer、Instant Clone……等。請在 Horizon 管理介面中，依序點選「View 組態 > 產品授權及使用 > 編輯授權」後，填入你所擁有的 Horizon 7 軟體授權即可。

圖 17、新增 Horizon 7 軟體授權



新增 vCenter / Composer 伺服器角色

當管理人員新增完 Horizon 7 軟體授權後，便可以準備新增 vCenter 及 Composer 伺服器資訊，以利後續 VDI 虛擬桌面的佈建作業。請在 Horizon 管理介面中，依序點選「View 組態 > 伺服器 >  vCenter Server > 新增」，在彈出的新增 vCenter Server 視窗中，填入 vCenter 伺服器管理者資訊。

通過 vCenter 伺服器的驗證程序後，接著填入 Composer 伺服器的管理資訊，此實作環境中因為 Composer 伺服器，並未跟 vCenter 伺服器安裝在同一台主機中，因此選擇「獨立式 View Composer Server」選項。最後，在儲存空間頁面中詢問勾選是否啟用相關特色功能，例如「回收虛擬機器磁碟空間」或「啟用 View 儲存加速器」，請管理人員依照運作架構環境需求勾選即可。

圖 18、新增 vCenter 及 Composer 伺服器資訊



組態設定 Event 資料庫

在 Horizon 運作架構中，系統運作狀態及組態設定和 VDI 虛擬桌面運作資源，都會記錄於 Horizon Event 資料庫當中。然而，當你點選 Horizon View Administrator 管理介面中的「事件」項目時，將會發現無法看到任何事件記錄於其中，原因是必須先指定 Event DB 事件資料庫之後才行。在目前 Horizon 事件資料庫中，支援 Microsoft SQL Server 及 Oracle 資料庫。

在本文實作環境中採用 Microsoft SQL Server 資料庫。請於 Horizon 管理介面中，依序點選「View 組態 > 事件組態 > 事件資料庫 > 編輯」，此時將彈出編輯事件資料庫視窗，請填入資料庫伺服器主機名稱或IP位址、連接埠、資料庫名稱...…等資訊，設定事件資料庫完成後，此時再度點選「事件」項目便可以看到相關事件，以幫助你進行故障排除任務。

圖 19、組態設定 Horizon Event 事件組態資料庫





結語

透過本文的說明及實作相信讀者已經了解，在最新 Horizon 7 虛擬桌面解決方案當有哪些特色功能，能夠幫助企業及組織建立更靈活、高擴充性、高可用性的 VDI 虛擬桌面運作環境。同時，我們討論如何規劃 Horizon 7 運作架構及資源管理的部分，最後進行實戰演練以便更深入了解整個運作架構及維運事務。
↧

實戰 - Redis Sentinel 高可用性機制容器化

December 8, 2017, 8:41 am
$
0
0

文章目錄

前言
實作環境
實作 Redis Sentinel 高可用性容器化
          建立 Docker Swarm 運作環境
          客製化 Redis Master / Slave 容器映像檔
          客製化 Redis Sentinel 容器映像檔
          客製化 Redis-Stat 容器映像檔
          執行 Docker Stack Deploy 佈署作業
          驗證和容錯移轉測試
          摧毀環境
參考資源





前言

簡單來說，希望透過「容器化」(Containerzation)的方式，將 Redis Sentinel 高可用性機制打包封裝後，以後在 Docker 容器管理環境中便能非常快速的建立 Redis Sentinel 高可用性機制。

本文將會在 Docker Swarm (3 Nodes)的運作環境中實作，所以會採用最新 Docker Compose v3以及 docker stack deploy指令進行佈署作業 (從 Docker 1.13版本開始發佈新的 Docker Compose 並且支援 Swarm Mode，以便達成 Multi-Container on Multi-Host的目標)。下列是 Docker Compose v2 / v3的簡易比較表格：


Docker Compose v2
Docker Compose v3
佈署服務
docker-compose up -d
docker stack deploy -c docker-compose.yml
查詢服務
docker-compose ps
docker stack ps
擴展服務
docker-compose scale
docker service scale
關閉服務
docker-compose down
docker stack rm
支援多台容器主機
No
Yes

倘若你將編寫好的 YAML檔案，透過 Docker Compose v2佈署到 Docker Swarm 運作環境時會發生什麼事？ 此時，系統便會提醒你目前的 Docker Engine 已經處於 Swarm Mode，如果希望佈署到「多台容器主機」上的話，要改為採用 docker stack deploy指令來進行佈署。

圖、必須使用 docker stack deploy 指令才能佈署容器至多台主機





實作環境

快速建置：
1. 建構好 Docker Swarm運作環境。
2. 下載本文相關檔案 git clone https://github.com/Weithenn/redis-sentinel。
3. 執行 build.sh即可建構好 Redis Sentinel 高可用性機制 (如果順利的話 😁)。





    實作 Redis Sentinel 高可用性容器化

    建立 Docker Swarm 運作環境

    簡單來說，當企業及組織建立的容器數量越來越多需要管理平台或建立容器叢集架構時，就可以透過建置 Docker Swarm運作環境來達成。從 Docker 1.12.0版本之後，便直接原生內建 Docker Swarm Mode 並且容器主機，已經可以「同時」擔任 Manager 及 Workers的角色。

    下列為 Swarm Cluster Protocol / Ports資訊：
    • 2377 (TCP) - Swarm Cluster management。
    • 7946 (TCP and UDP) - Nodes communication。
    • 4789 (UDP) - Overlay network traffic，IP Protocol 50 (ESP) - Overlay network with encryption (--opt encrypted)。

    圖、Docker Swarm 運作架構示意圖
    圖片來源： How nodes work | Docker Documentation

    圖、Docker Swarm 工作任務示意圖
    圖片來源： How services work | Docker Documentation


    同時，為了維持 Docker Swarm Mode的高可用性，應該要建立「奇數」的 Manager Node 才對，舉例來說：
    • 3 Manager Node Swarm Cluster 可允許 1 台故障(N-1/2)。
    • 5 Manager Node Swarm Cluster 可允許 2 台故障 (N-1/2)。
    • Docker 官方建議每個 Swarm Cluster 最多 7 台 Manager Node (更多的 Manager Node 很有可能會造成反效果)。
    • 當 Manager Node 死光，Worker Node 上的 Container 仍能繼續運作，但是無法 Add/Update/Remove Node 等維護動作 (但後續要執行復原的動作)。

    圖、Docker Swarm 高可用性規劃
    圖片來源： Administer and maintain a swarm of Docker Engines | Docker Documentation

    在本文實作環境中，採用 3 台 CentOS 7.4 主機擔任 Container Host (Swarm Node)，這 3 台 CentOS 主機的主機名稱、IP 位址、Swarm Role 資訊如下：
    • swarm01.weithenn.org, 10.10.75.71, Manager / Worker
    • swarm02.weithenn.org, 10.10.75.72, Manager / Worker
    • swarm03.weithenn.org, 10.10.75.73, Manager / Worker

    有關 CentOS 7.4 基礎設定和 CentOS 安裝 Docker 環境的部分請參考站內文章，在本文實作環境中 3 台 CentOS 主機，都「同時」擔任 Docker Swarm Manager / Worker的角色，以便可以互相調度及運作容器。

    圖、Docker Swarm Cluster (3 Nodes)





    客製化 Redis Master / Slave 容器映像檔

    將 Docker Swarm容器叢集環境建構完成後，接著就可以準備客製化 Redis Master / Slave容器映像檔 (因為要組態設定符合需求的設定檔)。在本文實作環境中，我們將會採用 redis:4.0.6-alpine 容器映像檔進行客製化作業。

    Redis Master - Dockerfile (GitHub - Weithenn/redis-sentinel/redis-master/Dockerfile)，主要客製化的項目如下：

    FROM redis:4.0.6-alpine
    MAINTAINER Weithenn Wang <weithenn@weithenn.org>
    # Install tzdata for Timezone
    RUN apk add --no-cache tzdata && \
        \
    # Download Redis configuration file example
        cd /tmp && \
        wget http://download.redis.io/redis-stable/redis.conf && \
        mkdir -p /etc/redis && \
        cp redis.conf /etc/redis/ && \
        \
    # This is Redis [Master] confgiruation
    # bind 0.0.0.0, Disable RDB file and AOF log, tuning TCP backlog
        sed -i 's,bind 127.0.0.1,bind 0.0.0.0,g' /etc/redis/redis.conf && \
        sed -i 's/^\(save .*\)$/# \1/' /etc/redis/redis.conf && \
        sed -i 's,#   save "",save "",g' /etc/redis/redis.conf && \
        sed -i 's,stop-writes-on-bgsave-error yes,stop-writes-on-bgsave-error no,g' /etc/redis/redis.conf && \
        sed -i 's,hz 10,hz 50,g' /etc/redis/redis.conf && \
        sed -i 's,tcp-backlog 511,tcp-backlog 32768,g' /etc/redis/redis.conf && \
        \
    # Tuning TCP backlog, No memory overcommit handling, Disable THP(Transparent Huge Pages)
    # Please reference Redis Administration (https://redis.io/topics/admin)
        touch /etc/redis/run.sh && \
        echo "echo 32768 > /wproc/sys/net/core/somaxconn">> /etc/redis/run.sh && \
        echo "echo 1 > /wproc/sys/vm/overcommit_memory">> /etc/redis/run.sh && \
        echo "echo never > /wsys/kernel/mm/transparent_hugepage/enabled">> /etc/redis/run.sh && \
        echo "echo never > /wsys/kernel/mm/transparent_hugepage/defrag">> /etc/redis/run.sh && \
        echo "redis-server /etc/redis/redis.conf">> /etc/redis/run.sh && \
        chmod 755 /etc/redis/run.sh && \
        chown -R redis:redis /etc/redis
    ENV TZ=Asia/Taipei
    EXPOSE 6379/tcp
    CMD ["/etc/redis/run.sh"]


    Redis Slave - Dockerfile (GitHub - Weithenn/redis-sentinel/redis-slave/Dockerfile)，客製化的部分跟 Redis Master 一樣，唯一的差別在於 redis.conf 組態設定檔當中，加上 1 行「slaveof redis_master 6379」內容，也就是指定誰是 Redis Master 主機，其中的 redis_master為本文實作環境中自訂的 Swarm Native Service Discovery名稱。

    FROM redis:4.0.6-alpine
    MAINTAINER Weithenn Wang <weithenn@weithenn.org>
    # Install tzdata for Timezone
    RUN apk add --no-cache tzdata && \
        \
    # Download Redis configuration file example
        cd /tmp && \
        wget http://download.redis.io/redis-stable/redis.conf && \
        mkdir -p /etc/redis && \
        cp redis.conf /etc/redis/ && \
        \
    # This is Redis [Slave] confgiruation
    # bind 0.0.0.0, Disable RDB file and AOF log, tuning TCP backlog
        sed -i 's,bind 127.0.0.1,bind 0.0.0.0,g' /etc/redis/redis.conf && \
        sed -i 's,# slaveof <masterip> <masterport>,slaveof redis_master 6379,g' /etc/redis/redis.conf && \
        sed -i 's/^\(save .*\)$/# \1/' /etc/redis/redis.conf && \
        sed -i 's,#   save "",save "",g' /etc/redis/redis.conf && \
        sed -i 's,stop-writes-on-bgsave-error yes,stop-writes-on-bgsave-error no,g' /etc/redis/redis.conf && \
        sed -i 's,hz 10,hz 50,g' /etc/redis/redis.conf && \
        sed -i 's,tcp-backlog 511,tcp-backlog 32768,g' /etc/redis/redis.conf && \
        \
    # Tuning TCP backlog, No memory overcommit handling, Disable THP(Transparent Huge Pages)
    # Please reference Redis Administration (https://redis.io/topics/admin)
        touch /etc/redis/run.sh && \
        echo "echo 32768 > /wproc/sys/net/core/somaxconn">> /etc/redis/run.sh && \
        echo "echo 1 > /wproc/sys/vm/overcommit_memory">> /etc/redis/run.sh && \
        echo "echo never > /wsys/kernel/mm/transparent_hugepage/enabled">> /etc/redis/run.sh && \
        echo "echo never > /wsys/kernel/mm/transparent_hugepage/defrag">> /etc/redis/run.sh && \
        echo "redis-server /etc/redis/redis.conf">> /etc/redis/run.sh && \
        chmod 755 /etc/redis/run.sh && \
        chown -R redis:redis /etc/redis
    ENV TZ=Asia/Taipei
    EXPOSE 6379/tcp
    CMD ["/etc/redis/run.sh"]


    經過上述客製化程序後，建立的容器映像檔如下 (已經綁定 Automated build機制)，Tags 版本則是直接跟採用的 Redis-Apline 版本對齊：
    圖、倘若未處理核心參數啟動 Redis 將會發生相關警告訊息



    客製化 Redis Sentinel 容器映像檔

    簡單來說，Redis Sentinel 機制為「監控 Redis (Master) Instance當無回應時，切換至 Redis (Slave) Instance接手」，透過 Redis Sentinel 可以為 Redis 運作架構提供下列功能：
    • Monitoring： 持續檢查 Redis Master / Slave 之間是否正常運作。
    • Notification： 可以透過 API 通知管理人員被監控的 Redis Instance 是否發生問題。
    • Automatic failover： 當 Sentinel 判定 Redis Master 故障時，將存活的 Redis Slave 執行 Promoted to Master 的動作。
    • Configuration provider： 組態設定其它 Redis Slave (變成指向至新的 Master)，讓 Application 能夠連接到新的 Redis Master。

    Redis Sentinel 為 Distributed System的設計架構 (Multiple Sentinel processes cooperating together)，這樣設計架構主要是為了「避免誤判」：
    • 從 Redis 2.8版本開始內建 Sentinel v2，並採用更強大更簡單的「預測演算法」(Predict Algorithms)。
    • 建議「至少 3 台」Sentinel Instances 並確認開啟 TCP Port 26379 (否則不會自動切換)。
    • 採用「非同步複寫」(Asynchronous Replication)，所以 Failover 時無法保證所有資料都寫入。

    圖、Redis Sentinel 建議採用的基礎架構 (Redis Master *1、Redis Slave *2、Redis Sentinel *3)
    圖片來源： Redis Sentinel Documentation – Basic setup with three boxes

    Redis Sentinel - Dockerfile (GitHub - Weithenn/redis-sentinel/redis-sentinel/Dockerfile)，主要客製化的項目如下：
    • 時區： Asia / Taipei。
    • sentinel.conf 組態設定檔：  關閉 Protected Mode、指定 Redis Master 主機、Quorum 數量設定為 2、當 Redis Master 60 秒沒回應判定故障、當 Redis Failover 機制作用後只有 1 台 Redis Slave 能與 Redis Master 同步資料。
    • run.sh： 由於 Docker Compose v3 中 sysctls 參數「尚未支援」docker stack deploy 佈署機制，所以透過這樣的方式來調整 Redis 運作環境所需要的系統核心參數，否則啟動 Redis Sentinel 機制時將會出現 TCP Backlog 的警告訊息。

    FROM redis:4.0.6-alpine
    MAINTAINER Weithenn Wang <weithenn@weithenn.org>
    # Install tzdata for Timezone
    RUN apk add --no-cache tzdata && \
        \
    # Download Redis Sentinel configuration file example
        cd /tmp && \
        wget http://download.redis.io/redis-stable/sentinel.conf && \
        mkdir -p /etc/redis && \
        cp sentinel.conf /etc/redis/ && \
        sed -i 's,# protected-mode no,protected-mode no,g' /etc/redis/sentinel.conf && \
        sed -i 's,sentinel monitor mymaster 127.0.0.1 6379 2,sentinel monitor redis-ha redis_master 6379 2,g' /etc/redis/sentinel.conf && \
        sed -i 's,sentinel down-after-milliseconds mymaster 30000,sentinel down-after-milliseconds redis-ha 5000,g' /etc/redis/sentinel.conf && \
        sed -i 's,sentinel parallel-syncs mymaster 1,sentinel parallel-syncs redis-ha 1,g' /etc/redis/sentinel.conf && \
        sed -i 's,sentinel failover-timeout mymaster 180000,sentinel failover-timeout redis-ha 60000,g' /etc/redis/sentinel.conf && \
        \
    # Tuning TCP backlog
    # Please reference Redis Administration (https://redis.io/topics/admin)
        touch /etc/redis/run.sh && \
        echo "echo 32768 > /wproc/sys/net/core/somaxconn">> /etc/redis/run.sh && \
        echo "redis-sentinel /etc/redis/sentinel.conf">> /etc/redis/run.sh && \
        chmod 755 /etc/redis/run.sh && \
        chown -R redis:redis /etc/redis
    ENV TZ=Asia/Taipei
    EXPOSE 26379/tcp
    CMD ["/etc/redis/run.sh"]

    經過上述客製化程序後，建立的容器映像檔如下 (已經綁定 Automated build 機制)，Tags 版本則是直接跟採用的 Redis-Apline 版本對齊：



    客製化 Redis-Stat 容器映像檔

    Redis-Stat是個採用 Ruby所撰寫的 Redis Monitor Tool。目前，在 Docker Hub當中並沒有官方打包的容器映像檔，所以只好自行建立 Dockerfile 後打包容器映像檔。

    Redis-Stat - Dockerfile (GitHub - Weithenn/redis-sentinel/redis-stat/Dockerfile)，主要採用 ruby:2.4容器映像檔 (採用 Debian OS)，然後組態設定時區為 Asia / Taipei 並安裝 redis-stat。

    FROM ruby:2.4
    MAINTAINER Weithenn Wang <weithenn@weithenn.org>
    # Install redis-stat and setting Timezone
    RUN gem install redis-stat && \
        echo Asia/Taipei > /etc/timezone && \
        dpkg-reconfigure -f noninteractive tzdata
    EXPOSE 63790/tcp
    CMD ["redis-stat"]

    經過上述客製化程序後，建立的容器映像檔如下 (已經綁定 Automated build 機制)，Tags 版本則是直接跟採用的 Ruby 2.4版本對齊：



    執行 Docker Stack Deploy 佈署作業

    前置作業都完成後，終於可以透過 docker stack deploy 進行佈署作業了。我們先將所有操作進行分解，了解整個運作流程後便可以使用 Shell Script (build.sh)將整個流程串起來一氣呵成了。

    Docker Swarm 虛擬網路環境
    在目前還未進行 docker stack deploy佈署作業之前，可以看到目前虛擬網路只有基礎的「bridge、host、none」，以及建構 Docker Swarm 叢集環境所新增的「docker_gwbridge、ingress」。

    圖、目前的 Docker Swarm 虛擬網路環境


    佈署 Redis Master角色容器 (GitHub - Weithenn/redis-sentinel/01-redis-master.yml)
    首先，我們透過「docker stack deploy -c 01-redis-master.yml redis」指令，來建立 Redis 環境的虛擬網路及佈署擔任 Redis Master角色的容器。

    version: '3.4'
    services:
      master:
        image: weithenn/redis-master:latest
        ports:
          - "6379:6379"
        volumes:
          - /proc:/wproc
          - /sys:/wsys
        networks:
          - vnet
        deploy:
          replicas: 1
          update_config:
            delay: 60s
    networks:
      vnet:

    可以看到，順利建立「redis_vnet」虛擬網路環境，以及佈署 Redis Master 角色容器並且也 Listen Port 6379。

    圖、順利建立 redis_vnet 虛擬網路及佈署 Redis Master 角色容器

    並且，使用「docker service logs redis_master」查看 Redis Master 角色容器日誌訊息，可以看到順利啟動 Redis 並且沒有警告訊息。

    圖、順利啟動 Redis 服務並且沒有任何警告訊息


    佈署 Redis Slave角色容器 (GitHub - Weithenn/redis-sentinel/02-redis-slave.yml)
    接著，我們透過「docker stack deploy -c 02-redis-slave.yml redis」指令，使用剛才已經建立的 redis_vnet 虛擬網路環境，並且佈署擔任 Redis Slave角色的容器。

    version: '3.4'
    services:
      slave:
        image: weithenn/redis-slave:latest
        ports:
          - "6380:6379"
        volumes:
          - /proc:/wproc
          - /sys:/wsys
        networks:
          - vnet
        deploy:
          replicas: 2
          update_config:
            delay: 60s
    networks:
      vnet:

    可以看到，順利佈署 2 台 Redis Slave 角色容器並且也 Listen Port 6379 (6380 -> 6379)。

    圖、順利佈署 2 台 Redis Slave 角色容器

    使用「docker service logs redis_slave」查看 Redis Slave 角色容器日誌訊息，可以看到順利啟動 Redis 並且成功找到 Redis Master 角色並進行同步作業 (主要就是依靠 Swarm Native Service Discovery  機制)。

    圖、順利佈署 Redis Slave 並與 Redis Master 進行同步作業

    使用「docker service logs redis_master」查看 Redis Master 角色容器日誌訊息，可以看到發現 2 台 Redis Slave 要求進行同步作業。

    圖、Redis Master 發現 2 台 Redis Slave 要求進行同步作業


    佈署 Redis Sentinel 角色容器 (GitHub - Weithenn/redis-sentinel/03-redis-sentinel.yml)
    接著，我們透過「docker stack deploy -c 03-redis-sentinel.yml redis」指令，使用剛才已經建立的 redis_vnet 虛擬網路環境，並且佈署擔任 Redis Sentinel 角色的容器。

    version: '3.4'
    services:
      sentinel:
        image: weithenn/redis-sentinel:latest
        ports:
          - "26379:26379"
        volumes:
          - /proc:/wproc
        networks:
          - vnet
        deploy:
          replicas: 3
          update_config:
            delay: 60s
    networks:
      vnet:

    可以看到，順利佈署 3 台 Redis Sentinel 角色容器並且也 Listen Port 26379。

    圖、順利佈署 3 台 Redis Sentinel 角色容器

    使用「docker service logs redis_sentinel」查看 Redis Sentinel 角色容器日誌訊息，可以看到順利啟動 Redis Sentinel 機制，並且成功找到 Redis Master / Slave 角色和運作情況 (同樣依靠 Swarm Native Service Discovery  機制)。

    圖、順利佈署 Redis Sentinel 並成功找到 Redis Master / Slave 角色


    佈署 Redis-Stat 角色容器 (GitHub - Weithenn/redis-sentinel/04-redis-stat.yml)
    接著，我們透過「docker stack deploy -c 04-redis-stat.yml redis」指令，使用剛才已經建立的 redis_vnet 虛擬網路環境，並且佈署擔任 Redis-Stat 角色的容器。

    version: '3.4'
    services:
      stat:
        image: weithenn/redis-stat:latest
        command: redis-stat --server redis_master
        ports:
          - "80:63790"
        networks:
          - vnet
        deploy:
          replicas: 1
          update_config:
            delay: 60s
    networks:
      vnet:

    可以看到，順利佈署 1 台 Redis-Stat 角色容器並且也 Listen Port 63790 (80 -> 63790)。

    圖、順利佈署 Redis-Stat 角色容器

    使用「docker service logs redis_stat」查看 Redis-Stat 角色容器日誌訊息，可以看到順利啟動 Redis-Stat 監控機制，並且開始收集 Redis Master 運作情況 (同樣依靠 Swarm Native Service Discovery  機制)。

    圖、順利佈署 Redis-Stat 並開始收集 Redis Master 運作情況

    圖、順利佈署 Redis-Stat 並開始收集 Redis Master 運作情況


    佈署 Poitainer 角色容器 (GitHub - Weithenn/redis-sentinel/05-portainer.yml)
    接著，我們透過「docker stack deploy -c 05-portainer.yml redis」指令，使用剛才已經建立的 redis_vnet 虛擬網路環境，並且佈署便於操作及管理容器的 GUI 圖形管理工具。因為，在本文實作環境中，3 台主機都是同時擔任 Docker Swarm Manager / Worker的角色，所以在佈署 Portainer 容器時無須再特意指定運作在 Manager Node 的部分。詳細資訊，請參考官網文件 Portainer documentation — Portainer 1.15.3 documentation。

    version: '3.4'
    services:
      portainer:
        image: portainer/portainer
        command: -H unix:///var/run/docker.sock
        ports:
          - "9000:9000"
        networks:
          - vnet
        volumes:
          - "/var/run/docker.sock:/var/run/docker.sock"
          - "/tmp:/data"
    networks:
      vnet:

    可以看到，順利佈署 1 台 Portainer 容器並且也 Listen Port 9000。

    圖、順利佈署 Portainer 管理工具容器

    使用「docker service logs redis_portainer」查看 Portainer 角色容器日誌訊息，可以看到順利啟動 Portainer 管理工具服務。

    圖、順利啟動 Portainer 管理工具服務

    現在，我們可以登入 Portainer 管理工具的操作介面。💪

    圖、Portainer 管理介面

    圖、透過 Portainer 查看 Docker Swarm 環境

    了解整個建置的流程後，其實我們可以用個簡單的 Shell Script 即可串起所有建構流程。

    #!/bin/sh
    #$Id: build.sh v0.1, 2017/12/08 Weithenn Wang (weithenn@weithenn.org) Exp $
    #Buildup Redis Sentinel provides HA(High Availability) for Redis
    echo ------------------------------------------------
    echo Deploy Redis [Master *1] Node
    echo ------------------------------------------------
    docker stack deploy -c 01-redis-master.yml redis
    echo
    echo
    sleep 10
    echo ------------------------------------------------
    echo Deploy Redis [Slave *2] Nodes
    echo ------------------------------------------------
    docker stack deploy -c 02-redis-slave.yml redis
    echo
    echo
    sleep 10
    echo ------------------------------------------------
    echo Deploy Redis [Sentinel *3] Nodes
    echo ------------------------------------------------
    docker stack deploy -c 03-redis-sentinel.yml redis
    echo
    echo
    sleep 10
    echo ------------------------------------------------
    echo Deploy Redis-Stat Monitor Tool
    echo ------------------------------------------------
    docker stack deploy -c 04-redis-stat.yml redis
    echo
    echo
    sleep 10
    echo ------------------------------------------------
    echo Deploy Portainer GUI Tool
    echo ------------------------------------------------
    docker stack deploy -c 05-portainer.yml redis
    echo
    echo
    sleep 10
    echo ------------------------------------------------------
    echo Verify Docker Swarm Service for Redis Sentinel HA
    echo ------------------------------------------------------
    docker service ls
    echo
    echo
    docker stack ps redis
    echo
    echo
    echo ------------------------------------------------------
    echo Verify Redis Master/Slave/Sentinel Status
    echo ------------------------------------------------------
    echo Redis Master IP address is:
    redis-cli -p 26379 SENTINEL get-master-addr-by-name redis-ha
    echo
    echo
    redis-cli -p 26379 info Sentinel


    驗證和容錯移轉測試

    Redis Master / Slave 及 Redis Sentinel 高可用性機制成形後，我們先再次驗證是否能夠順利看到 Redis 高可用性相關資訊。請使用「redis-cli -p 26379 SENTINEL get-master-addr-by-name redis-ha」指令，查詢 Redis Master 的 IP 位址 (其中 redis-ha是在 sentinel.conf 組態設定檔，自行指定的 Redis 高可用性服務名稱)，以及「redis-cli -p 26379 info Sentinel」指令查看 Redis Sentinel 高可用性機制資訊 。

    圖、查詢 Redis Sentinel 高可用性機制資訊

    在本文實作環境中，透過「docker stack ps redis」指令可以看到 Redis Master 角色容器，目前運作在 swarm02.weithenn.org 的容器主機上，我們直接去 swarm02 主機上停用 Redis Master 角色容器，然後觀察 Redis Sentinel 日誌資訊即可得知 Redis Master / Slave Auto-Failover 的情況。

    圖、Sentinel 發現 Redis Master (10.0.0.5) 故障由 Redis Slave (10.0.0.8) 接手

    圖、這次的切換是透過 3 台 Sentinel 中的 2 台同意的結果

    圖、原 Redis Slave (10.0.0.8) 順利接手成為 Redis Master

    圖、看到剛才測試容錯移轉時故障的 Redis Master 容器



    摧毀環境

    練習完畢💨，要摧毀環境也很容易。只要執行「docker stack rm redis」便可以刪除剛才所有建立的環境 (redis_vnet 虛擬網路、Redis Master、Redis Slave、Redis Sentinel、Redis-Stat、Portainer)。

    圖、破壞總是比建設容易💩





    參考資源

    ↧

    [站長開講] IT 未來新能量

    December 4, 2017, 8:49 am
    $
    0
    0

    活動簡介

    在瞬息萬變的商業環境中，推動企業走向數位組織，Dell 全新混合雲平台正是協助企業實踐轉型藍圖的最佳方案。

    為因應消費市場的快速變化、保護商業資料的安全，根據 IDC 公布 2017 台灣 ICT 市場十大趨勢預測指出，混合雲將成為企業數位轉型發展核心。只是要打造可整合公有雲、私有雲環境的混合雲平台，資訊人員得先克服異質雲平台串連、應用程式相容性、資料傳送速度等挑戰，才能享受混合雲架構帶來的種種優點。所幸現今藉由微軟推出 Azure Stack，即可 Microsoft Azure 平台的靈活度和創新，延伸到企業內部的私有雲中，降低建置混合雲平台的難度。

    而身為全球商用資訊設備主要供應商的 Dell，在提供企業用戶完整數位轉型解決方案之餘，亦在第一時間推出支援 Microsoft Azure Stack、Microsoft Storage Spaces Direct 的解決方案，協助企業用戶以最簡單、快速方法部署與維護混合雲環境，享受到自動化 IT 服務、資料傳遞無礙的優點，實踐加速邁向數位轉型的目標。

    Dell 在此場研討會中，將邀請多位技術專家到場，分別介紹 Dell on Microsoft Storage Spaces Direct、Microsoft Azure Stack 的創新技術，以及東森集團運用前述解決方案打造混合雲平台的成功案例，期盼藉此帶動台灣企業邁向數位組織的風潮，為公司長遠發展打下雄厚基礎。





    活動資訊


    • 日期： 2017 年 12 月 15 日 (星期五)
    • 時間： 13:30 ~ 16:35
    • 地點： 台北六福皇宮 2 樓銀河廳（台北市南京東路三段133號 ) 
    • 報名： 活動報名






    活動內容


    ↧
    ↧

    [站長翻譯] Windows Server 容器技術

    December 27, 2017, 9:58 am
    $
    0
    0

    書籍簡介

    容器技術的興起，為虛擬化基礎架構帶來了革命性的轉變。本書可以幫助你了解 Windows Server Container 技術、Docker 指令，以及如何在最新的 Windows Server 平台上，透過容器技術建構 ASP .NET 應用程式。同時，本書也將告訴您如何將容器從這個運作環境，搬移到另一個運作環境繼續執行並且達到不間斷的整合及交付，你也將了解如何使用可擴充儲存容器機制，建構 VM 虛擬主機中隔離層級的高速快取容器。

    透過本書，您將可以了解：

    • 如何設定開發環境，並了解 Docker 技術名詞
    • 在 Windows Server Container 運作環境中，如何透過 Docker CLI 管理容器
    • 如何透過 Visual Studio 2015、.NET Core 和 C# 等工具，建立及部署 ASP.NET Core Web 應用程式
    • 如何使用 PowerShell 及 Docker CLI 將應用程式轉換為 Windows Server 容器
    • 如何使用 Microsoft Azure 公有雲服務進行容器的遠端部署
    • 如何建立不同用途的容器虛擬網路及客製化虛擬網路環境後部署及運作容器
    • 如何透過 Visual Studio Team Services、Docker Hub 及 Git 等機制，建構持續整合（CI）及持續交付（CD）運作環境
    • 如何使用 Docker Swarm 及 Azure Container Service 進行容器與叢集的管理
    • 如何使用 PowerShell DSC 自動化配置 Nano Server 運作環境





    網路購書







    誰適合閱讀此書

    希望透過 Windows Server 容器技術，建構可在任何地方任何環境運作的可攜式應用程式開發人員(不管運作環境是在筆記型電腦、伺服器、公有雲或私有雲)，撰寫的程式碼幾乎無須進行任何修改即可運作，因此開發人員將可以專心一致建構高品質的應用程式。由於 Windows Server 容器革命性的創新技術，因為不僅影響開發人員也同時影響IT維運管理人員，所以本書也能夠幫助IT維運管理人員或 DevOps 專業人員，能夠更容易建構及維運資料中心內的基礎架構，並且IT維運管理人員透過增加每台主機的應用程式密度，達到最佳化硬體資源使用率的目的。此外，本書也將討論 DevOps 的概念及容器化等思維，讓開發人員能夠透過容器技術將撰寫的程式碼，從開發環境一路佈署到正式營運環境當中。





    本書導讀

    《第 1 章 探索虛擬化》本章將教導你了解不同的虛擬化技術層級，以及虛擬化環境所帶來的各項挑戰。同時，透過容器技術來補足傳統伺服器虛擬化平台的不足，並了解將應用程式容器化的好處以及有哪些工具能夠幫助你，最後了解市場上有哪些容器技術平台。

    《第 2 章 佈署第1個容器》本章將教導你組態設定開發環境以及了解 Docker 技術名詞，並且透過 Docker Hub 下載及安裝容器映像檔，以及使用 Docker CLI 建立客製化的 Windows 容器映像檔及建立 Dockerfile。

    《第 3 章 使用容器映像檔》本章將向你介紹在 Windows Server Container 運作環境中，如何透過 Docker CLI 維運管理容器的相關事務，例如，啟動容器、停止容器、清除容器、刪除容器映像檔……等作業。

    《第 4 章 開發容器應用程式》本章將教導你如何透過 Visual Studio 2015、.NET Core 和 C# 等工具，建立及佈署 ASP.NET Core Web 應用程式，並使用 PowerShell 及 Docker CLI 將應用程式轉換為 Windows Server 容器。

    《第 5 章 佈署容器應用程式》本章將教導你如何使用 Microsoft Azure 公有雲服務，透過 Azure Resource Manager 範本及 Azure PowerShell 工具組態設定容器主機的遠端管理機制，以便遠端佈署 Windows Server 容器、遠端佈署 Hyper-V 容器、組態設定軟體式負載平衡器……等。

    《第 6 章 儲存磁碟區》本章將討論使用 Docker Volume 機制，建立 File Based 及 Storage Based 類型的容器，以及使用 Microsoft SQL Server 資源的資料庫類型容器。

    《第 7 章 Redis 快取容器》本章將教導你建構 Redis 快取容器，以及如何使用 Redis 快取機制及儲存磁碟區。

    《第 8 章 容器的網路環境》本章將向你介紹 Windows 容器的網路環境以及不同的網路模式，容器管理人員應該如何透過不同的虛擬網路類型，建立不同用途的容器虛擬網路及客製化虛擬網路環境後佈署及運作容器。

    《第 9 章 持續整合與交付》本章將教導你如何使用 Microsoft Azure 公有雲服務，透過 Visual Studio Team Services (舊稱為 TFS Online)、Docker Hub 及 Git 等機制，建構持續整合 (Continuous Integration，CI) 及持續交付 (Continuous Delivery，CD) 運作環境。你將學習到如何建立客製化的 Build Server，將應用程式封裝成容器後自動佈署至 Windows 容器主機中。

    《第 10 章 資源管理及分配和 REST API》本章將教導你如何管理容器資源使用率，以及透過 Docker REST API 及 Postman 和 C# 建立及管理容器，並且最佳化容器映像檔及針對容器和容器主機進行監控作業。

    《第 11 章 整合容器與叢集》本章將教導你如何透過 Docker Compose 機制調度多個容器，以及組態設定擴大多容器環境的運作規模，並且建立 Docker Compose 機制的服務定義。此外，你將會學習到如何使用 Docker Swarm 及 Azure Container Service，進行容器與叢集的管理事務。

    《第 12 章 Nano Server》本章將向你介紹 Windows Nano Server 容器平台，以及使用 PowerShell 建立及佈署 Nano Server 映像檔、在 Nano Server 容器平台上佈署容器、使用 PowerShell DSC 自動化配置 Nano Server 運作環境……等建構及維運事務。
    ↧

    關於本站 (回顧 2017 年)

    December 27, 2017, 10:02 am
    $
    0
    0

    關於本站

    本網站所引用他人商標或圖示均屬該來源網站或其合法權利人所有，本站內容多為個人研究心得，其所寫之實作筆記內容多為參考網路上資料並實際操作後所記錄完成，歡迎分享網站內容並標示出處及作者但僅限於非商業用途連結，且禁止改作(若你重混、轉換本素材，或依本素材建立新素材，則你不得散布改作後的素材!!) [本網站內容受 創用 CC 授權 3.0保護]，本網站若有任何地方侵犯到您權利的地方，請 Mail 給我 將會立刻處理謝謝您。

    Weithenn 摸索 IT 世界回顧：

    2002 年

    6 月：

              憲兵退伍，連主要分割區是什麼東東也不知的人不自量力的想進入所謂的 IT 界工作。

    8 月：

              懷著一份對電腦世界的興趣及崇拜，因而參加網路工程師班，並認識了良師 George 及益友 Mandy、Tony...等技術同好。

    11 月：

              網路工程師班結訓後，第一份工作學習到有關 Cisco、3Com 網路設備...等技術 ，並且創立本站。



    2003 年

    4 月：

              第 1 份工作時，在 Bruce 的鼓勵下考取生平第一張證照 CCNA。

    8 月： 

              第 2 份工作中，遇見 Clive開始接觸 FreeBSD便一腳陷入惡魔的世界 (BSD Committer TW 之一 Clive 的電腦世界回顧與展望)。



    2007 年

    3 月：

              想開了!! 開始到世界各地走走，開始記錄遊山玩水的點點滴滴。



    2010 年

    5 月：

              遇見了 VMware vSphere 虛擬化技術的良師 Johnny。

    10 月：

              受邀採訪並刊登於 iThome 第 480 期 iT 人甘苦談 ─ 架 Wiki 做筆記，IT 人分享學習心得。



    2011 年

    11 月：

              (1) 受邀擔任 慶聯有線電視 - HP/Dell/IBM 伺服器及 CentOS 作業系統基礎設定 內部教育訓練講師。

              (2) 受邀推薦 iThome 2011 年 IT 好書 100 - 系統與網路管理類。

    12 月：

              (1) 出版人生中 第 1 本著作 24小時不打烊的雲端服務：專家教你用 CentOS 架設萬年不掛的伺服器。感謝大家熱情支持，此著作已經登上 博客來 2012 年度排行榜 - 電腦類 TOP 50。




    2012 年

    3 月： 

              (1) 受邀擔任 雙和區資訊組長研習 - VMware vSphere ESXi 進階技術研習講師。

              (2) 參加 Microsoft 所主辦的虛擬化戰士團，獲得 2012 年第一屆金翅級認證，微軟伺服器虛擬日 V-Day 虛擬化戰士頒獎典禮。


    4 月： 

              (1) 受邀擔任 雙和區資訊組長研習 - CentOS HA 高可用性進階技術研習講師。

              (2) 成為 台灣第 1 位獲選 VMware vExpert 殊榮的人 VMware vExpert Information - Wei-Ren Wang，並受邀採訪刊登於 VMware VMTN Blog: vExpert Spotlight: Wei-Ren Wang。


    5 月： 

              (1) 受邀擔任 雙和區資訊組長研習 - FreeNAS 進階技術研習講師。

              (2) 出版人生中 第 2 本 著作 (技術審校書) 企業級的網路安全架構：終極防駭技術大剖析。


    6 月： 

              (1) 受邀擔任 雙和區資訊組長研習 - Hyper-V Server 2008 R2 進階技術研習講師。

              (2) 跟 Microsoft Taiwan DPE - 林大鈞 (Ta-Chum Lin) 合作 Microsoft Technet Blog - 文章審校。

    7 月： 

              (1) 當選 Microsoft MVP - Virtualization Virtual Machine項目 Microsoft MVP Profile - Wei-Ren Wang。


              (2) 與 Microsoft Taiwan DPE - 林大鈞 (Ta-Chum Lin) 合作 Windows Server 2012 實戰影片審校。

    8 月： 

              (1) 與 Microsoft Taiwan DPE - 林大鈞 (Ta-Chum Lin) 合作 Windows Server Blog - 部份文章審校。

              (2) 參加 Windows Server 2012 (Hyper-V 3) 好文比賽獲得 分享獎。

    9 月： 

              (1) 出版人生中 第 3 本 著作 (技術審校書) 世界連在一起，搜尋引擎的核心秘密。


              (2) 受邀推薦 iThome 2012 年 iT 人必看的好書 - 系統與網路管理類。

              (3) 於 Microsoft Techdays Taiwan 2012舉辦期間，在 Windows Server 2012 攤位擔任 問專家。



    11 月：

              (1) 受邀擔任 板橋區資訊組長研習 - VMware vSphere ESXi 5.1 實作講師。

              (2) 受邀擔任 Acer Infrastructure & Virtualization 技術會議 內部教育訓練講師。

              (3) 受邀採訪並刊登於 網管人雜誌 第 81 期 資訊這條路 ─ 從無到有十年苦功 王偉任嶄露頭角。

    12 月：

              (1) 受邀擔任 雙和區資訊組長研習 - Windows Server 2012 新功能技術研討講師。

              (2) 出版人生中 第 4 本 著作 (技術審校書) MySQL+PHP初心者的學習殿堂：資料庫×動態網頁設計實務養成(附CD)。




    2013 年

    1 月： 

              擔任 WebConf Taiwan 2013講師，當天議程簡報無廢話 DRBD + Heartbeat 實戰，當天議程錄影無廢話 DRBD + Heartbeat 實戰。WebConf Taiwan 2013 懶人包、WebConf Taiwan 2013 Day 1 - 活動照片、WebConf Taiwan 2013 Day 2 - 活動照片。


    3 月： 

              擔任 Microsoft TechNet - 邁向雲端虛擬化的全方位攻略 - Hyper-V 與 VMware 大不同課程講師。
              當天議程簡報Hyper-V 與 VMware 大不同。
              當天議程錄影Hyper-V 與 VMware 大不同 (上)、Hyper-V 與 VMware 大不同 (下)。

    4 月： 

              (1) 擔任 第二屆 - 虛擬化戰士 Hyper-V 3.0 培訓計畫助教。

              (2) 貢獻 Hyper-V 2.0 文章至 Microsoft TechNet 文件庫，Microsoft TechNet Library - 王偉任。

              (3) 貢獻 Hyper-V 3.0 文章至 Microsoft TechNet 文件庫，Microsoft TechNet Library - 王偉任。

    5 月： 

              (1) 出版人生中 第 5 本 著作 (個人著作) 24 小時不打烊的雲端服務－專家教你用 Windows Server 2012 Hyper-V3.0 實戰虛擬化技術。


              (2) 擔任 2013 微軟 MVP 實戰課程日講師。
                    當天議程簡報Hyper-V 3.0 實戰 - 打造你的完美伺服器虛擬化平台。
                    當天活動簡報台灣微軟 - 研討會與活動簡報下載 - 微軟實戰課程日。
                    當天活動錄影台灣微軟 - 實戰課程日回顧篇。

    6 月： 

              (1) 第 2 度當選 VMware vExpert 2013，VMware vExpert Information - Wei-Ren Wang。


              (2) 受邀擔任 雙和區資訊組長研習 - VMware vSphere/Microsoft Hyper-V 虛擬化技術平台之 CentOS Webmin 應用講師。

              (3) 受邀商業週刊採訪 商業週刊第1334期 - 這家公司　讓微軟恨、林百里愛。

    7 月： 

              (1) 第 2 度當選 Microsoft MVP - Virtualization Virtual Machine 項目 Microsoft MVP Profile - Wei-Ren Wang。


              (2) 貢獻 Windows Server 2012 MPIO 文章至 Microsoft TechNet 文件庫，Microsoft TechNet Library - 王偉任。

    8 月： 

              (1) 受邀擔任 雙和區資訊組長研習 - 虛擬化應用與基礎電腦病毒安全防護 (A場)、(B場)講師。

              (2) 受邀擔任 特新光電 - Windows Server 2008 R2 教育訓練 內部教育訓練講師。

    9 月： 

              於 Microsoft Techdays Taiwan 2013舉辦期間，擔任 虛擬化平台最佳選擇: Windows Server 2012 R2 (Hyper-V 3.0 R2) vs VMware vSphere 5.1 及進行Vmware 無痛移轉之工具及建議議程講師。當天活動錄影及簡報 Channel 9 - Techdays Taiwan 2013。


    10 月： 

              (1) 受邀擔任 艾鍗學院 - 職訓課程 - 網管工程師類 - 私有雲與虛擬化系統工程師養成班講師。

              (2) 貢獻 Microsoft Virtual Machine Converter文章至 Microsoft TechNet 文件庫，Microsoft TechNet Library - 王偉任。

    11 月： 

              (1) 出版人生中 第 6 本 著作 (英文翻譯書) 打造雲端工作站 VMware View 5 建置與維護。


              (2) 受邀擔任 威盛電子 - Windows Server 2012 R2 虛擬化平台最佳選擇 內部教育訓練講師。

              (3) 貢獻 Windows Server 2012 即時遷移文章至 Microsoft TechNet 文件庫，Microsoft TechNet Library - 王偉任。

              (4) 擔任 102學年度全國大專校院 - 資訊行政主管研討會 - 淡江大學軟體雲建置實例分享議程講師，當天議程簡報 淡江大學軟體雲建置實例分享(PDF)。

              (5) 擔任 VMware 桌面虛擬化及軟體雲應用研討會講師，當天議程簡報 虛擬桌面最佳化調校。


    12 月： 

             (1) 受邀擔任 雙和區資訊組長研習 - Hyper-V 3.0與 VMware vSphere 5.5 虛擬化新功能比較講師。

             (2) 受邀擔任 元智大學 - 雙 V 駭客，架設高可用的服務主機 (Hyper-V 上午場)、(VMware 下午場)研習活動講師。




    2014 年

    2 月： 

              貢獻 Windows Server 2012 R2 - 虛擬化平台最佳實務文章至 Microsoft TechNet 文件庫，Microsoft TechNet Library - 王偉任。

    3 月： 

              (1) 貢獻 Windows Server 2012 R2 - Hyper-V 10 大特色功能、Windows Server 2012 R2 虛擬化平台最佳實務文章至 Microsoft TechNet 文件庫，Microsoft TechNet Library - 王偉任。

              (2) 擔任 2014 微軟技術關卡破解日 講師。
                   當天所有議程錄影 Channel 9 - MVP 微軟技術關卡破解日。
                   當天議程錄影及簡報 虛擬化平台最佳選擇 - Windows Server 2012 R2 Hyper-V 新功能展示。


    4 月： 

              (1) 擔任 春源鋼鐵 - VMware Horizon View 虛擬桌面 內部教育訓練講師。

              (2) 第 3 度當選 VMware vExpert 2014，VMware vExpert Information - Wei-Ren Wang。

           
              (3) 貢獻 Windows Server 2012 R2 虛擬桌面部署建議文章至 Microsoft TechNet 文件庫，Microsoft TechNet Library - 王偉任。

    5 月： 

              (1) 受邀擔任 集英信誠 - 與大師對談技術論壇講師。
                   當天所有議程簡報 與大師對談活動簡報。
                   當天我的議程簡報 VMware 及 Hyper-V最佳虛擬化平台硬體規劃。

              (2) 受邀擔任 雙和區資訊組長研習 - HyperV 3.0 R2 新功能研討研習 講師。

    6 月： 

              (1) 擔任 台灣微軟 IT 管理技術高峰論壇 (MMS 2014) 講師。
                   當天所有議程簡報 2014 台灣微軟 IT 管理高峰會簡報下載。

              (2) 參加 Microsoft 主辦雲端戰士團，獲得 2014 年第三屆金翅級認證。
                   當天活動新聞訊息 自由電子報 3C科技 - 台灣微軟匯聚雲端戰士團。


              (3) 擔任 文藻外語大學 - VMware Horizon View 虛擬桌面 內部教育訓練講師。

    7 月： 

              (1) 出版人生中 第 7 本 著作 (個人著作) Windows Server 2012 R2 Hyper-V 3.0 虛擬化環境實戰 (初級篇)。

              (2) 第 3 度當選 Microsoft MVP - Hyper-V 項目 Microsoft MVP Profile - Wei-Ren Wang。


              (3) 擔任 北區農會電腦共用中心 - VMware / Hyper-V 伺服器及桌面虛擬化基礎 內部教育訓練講師。

    8 月： 

              貢獻 Windows Server 2012 升級至 2012 R2 文章至 Microsoft TechNet 文件庫，Microsoft TechNet Library - 王偉任。

    9 月： 

              於 Microsoft Techdays Taiwan 2014 舉辦期間，擔任 四場(PCIT306、DCIM309、PCIT305、DCIM402) 議程講師。年會期間所有活動錄影及簡報 Channel 9 - TechDays Taiwan 2014、MVA - TechDays Taiwan 2014。


    11 月： 

              出版人生中 第 8 本 著作 (英文翻譯書) VMware Virtual SAN 管理手冊。


    12 月： 

              貢獻 MVMC 2.0、Windows Server 2012 R2 運作模式切換 文章至 Microsoft TechNet 文件庫，Microsoft TechNet Library - 王偉任。



    2015 年

    2 月： 

              第 4 度當選 VMware vExpert 2015，VMware vExpert Information - Wei-Ren Wang。


    4 月： 

              (1) 出版人生中 第 9 本 著作 (個人著作) Windows Server 2012 R2 Hyper-V 3.0 叢集雲端架構實戰 (高級篇)。


            (2) 與 Channel 9 Taiwan 合作「建立 Microsoft Azure IaaS 雲端基礎建設」線上課程，進行字幕及簡報的翻譯及審校。

    5 月： 

              (1) 受邀擔任 微軟 EMS 全方位企業雲端解決方案 講師。


              (2) 受邀 iThome 雜誌採訪，分享 全面透視虛擬環境網路效能的瓶頸觀點。

              (3) 受邀擔任 104 年度資訊應用服務人才培訓計畫 - 企業私有雲實戰講堂 - 以 VMware 為例  課程講師。

              (4) 貢獻 虛擬化環境導入評估工具 MAP、Storage Space 存放集區、 Azure RemoteApp 應用程式虛擬化  等文章至 Microsoft TechNet 文件庫，Microsoft TechNet Library - 王偉任。

              (5) 與 TechNet 部落格合作翻譯 針對軟體定義資料中心而生的 - 新世代儲存機制 、企業級虛擬化及新世代應用程式平台 文章。

              (6) 出版人生中 第 10 本 著作 (技術審校書) SDN 軟體定義網路。



    6 月： 

             擔任 台灣微軟 IT 管理技術高峰論壇 (MMS 2015) 講師。
                   當天所有影片及議程簡報 2015 台灣微軟 IT 管理高峰會簡報下載。


    7 月： 

            (1) 與 Channel 9 Taiwan 合作「深入探討網路儲存及災難備援議題」線上課程，進行字幕及簡報的翻譯及審校。

            (2) 與 Channel 9 Taiwan 合作「充分使用 Open Source 加速解決方案」線上課程，進行字幕及簡報的翻譯及審校。

            (3) 與 Channel 9 Taiwan 合作「使用 Azure 優化工作負載架構和管理能力」線上課程，進行字幕及簡報的翻譯及審校。

            (4) 第 4 度當選 Microsoft MVP - Hyper-V 項目 Microsoft MVP Profile - Wei-Ren Wang。


    9 月： 

             (1) 受邀擔任 資策會 Hyper-V 虛擬化實戰系列課程講師。

             (2) 於 Microsoft Techdays Taiwan 2015 舉辦期間，擔任 3場(ITM305、ECI309、ECI303) 議程講師。年會期間所有活動錄影及簡報 Channel 9 - TechDays Taiwan 2015。



    10 月： 

              (1) 與 MSDN 部落格合作翻譯 微軟正式宣布推出 PowerShell DSC for Linux Version 1.1 以及新的 Linux 資源文章。

              (2) 出版人生中 第 11 本 著作 (英文翻譯書) 實戰 Azure 混合雲｜基礎架構 x 高可用性 x 災難復原。


    11 月： 

              出版人生中 第 12 本 著作 (英文翻譯書) Active Directory 環境的 PowerShell 活用指南。




    2016 年

    1 月： 

              與 TechNet 台灣部落格 合作，撰寫 Windows Server 2016 攻略連載文章：
                   [Compute] Windows Server 2016 攻略 (一) - 新世代虛擬化平台 Hyper-V
                   [Compute] Windows Server 2016 攻略 (二) - 為雲端而生的極簡平台 Nano Server
                   [Compute] Windows Server 2016 攻略 (三) - 整合雲端元素的容錯移轉叢集

    2 月： 

              (1) 第 5 度當選 VMware vExpert 2016技術專家，VMware vExpert Information - Wei-Ren Wang。


              (2) 與 TechNet 台灣部落格 合作，撰寫 Windows Server 2016 攻略連載文章：
                   [Storage] Windows Server 2016 攻略 (四) - SDS 軟體定義儲存
                   [Storage] Windows Server 2016 攻略 (五) - 資料備援新選擇 Storage Replica
                   [Storage] Windows Server 2016 攻略 (六) - 儲存資源品質管控機制 Storage QoS

    3 月： 

             (1) 貢獻多篇技術文章至 Microsoft TechNet 技術文件庫：
                    Windows Server vNext 新技術預覽
                    WDS 部署服務
                    Microsoft SDS 軟體定義儲存技術
                    Microsoft 資料保護最後一哩 Storage Replica
                    新世代伺服器 Nano Server

              (2) 與 TechNet 台灣部落格 合作，撰寫 Windows Server 2016 攻略連載文章：
                   [Network] Windows Server 2016 攻略 (七) - 新世代虛擬網路交換器 SET ( Switch Embedded Teaming )
                   [Network] Windows Server 2016 攻略 (八) - SDN 軟體定義網路

    4 月： 

              出版人生中 第 13 本 著作 (英文翻譯書) VMware vSphere 最佳化效能調校。


    5 月： 

             受邀擔任 國立臺北商業大學 - 私有雲規劃與建置 VMware 實務班 講師。

    6 月： 

             (1) 出版人生中 第 14 本 著作 (英文翻譯書) Hyper-V 最佳實踐：快速建置虛擬化解決方案。    


             (2) 受邀擔任 聖約翰科技大學 - VMware 虛擬化技術培訓課程 講師。

    7 月： 

            (1) 第 5 度當選 Microsoft MVP - Cloud and DataCenter Management 項目 Microsoft MVP Profile - Wei-Ren Wang。


            (2) 受邀擔任 105 年度資訊應用服務人才培訓計畫 - 企業私有雲之規劃與建置 (實務班、進階班) - 以 Microsoft Hyper-V 為例  課程講師。

            (3) 受邀擔任 財團法人中興工程顧問社 VMware Horizon VDI 虛擬桌面 內部教育訓練講師。

    8 月： 

            (1) 受邀擔任 資策會 - VMware vSphere ESXi 桌面虛擬化實戰課程講師。

            (2) 受邀擔任 Community Open Camp活動講師。


    11 月： 

           (1)  受邀擔任 國立臺北商業大學 - 私有雲規劃與建置 VMware 實務班 講師。

           (2)  受邀擔任 中華電信學院 - VMware vSphere 建置與維護實作進階班 講師。



    2017 年

    2 月： 

             第 6 度當選 VMware vExpert 2017 技術專家，VMware vExpert Information - Wei-Ren Wang。


    3 月： 

             受邀分享 打造 Infrastructure Agility Mode 2 的基石 – Docker / Container 議程講師。

    4 月： 

            受邀擔任 國立臺北商業大學 - 私有雲規劃與建置 Hyper-V 實務班 課程講師。

    6 月： 

            受邀擔任 iThome Cloud Summit 2017 - Bimodal IT 打造 SDDC 軟體定義資料中心 議程講師。

    7 月： 

            (1) 第 6 度當選 Microsoft MVP - Cloud and DataCenter Management 項目 Microsoft MVP Profile - Wei-Ren Wang。


            (2 ) 受邀擔任 106年度製造業價值鏈資訊應用計畫 - 全方位企業私有雲之SDS軟體定義儲存實務班  課程講師。

            (3) 出版人生中 第 15、16 本 著作 (英文翻譯書) VMware vSphere 6 企業級專家手冊。


    8 月： 

            (1) 受邀擔任 106年度製造業價值鏈資訊應用計畫 - 全方位企業私有雲規劃與建置之最佳化調校實務班課程講師。

            (2) 首度當選 VMware vExpert 2017 - VSAN，這是由全球 1514位 VMware vExpert 2017成員中再度選出 vExpert VSAN，2017 年只有 74位獲選。


            (3) 出版人生中 第 17 本 著作 (個人著作) 微軟 S2D 軟體定義儲存技術實戰。


    9 月： 

            (1) 受邀擔任 資策會 - VMware vSphere 伺服器虛擬化實戰班 課程講師。

            (2) 受邀擔任 資策會 - Microsoft Azure IaaS 實戰班 課程講師。

            (3) 受邀擔任 DevOpsDays Taipei 2017 - 打造 Infrastructure Agility: Mode 2 的基石 - SDS 軟體定義儲存 議程講師。


    10 月： 

            (1) 受邀擔任 國立台北商業大學 - Docker 容器技術實務應用班 課程講師。

    12 月： 

            (1) 受邀擔任 國立台北商業大學 - 私有雲規劃與建置實務班 - Hyper-V 課程講師。

            (2) 受邀擔任 法務部 - Windows Server Container 教育訓練課程講師。

            (3) 網管人雜誌專訪 軟體定義儲存也要嚴選，東森得易購導入微軟 S2D。

            (4) 受邀擔任 Dell/Microsoft - IT 未來新能量 研討會講師。

            (5) 出版人生中 第 18 本 著作 (英文翻譯書) Windows Server 容器技術。




    其它

    • Weithenn PGP Keyid： 0xCD39063B
    • Weithenn Twitter： @weithenn
    • 最有價值專家： Microsoft MVP 2012 ~ 2017、VMware vExpert 2012 ~ 2017
    • 壁紙清單： CCNA, NSPA, JNCIA-JUNOS, JNCIA-ER, JNCIA-EX, JNCIA-Sec, MCP, MCSA, MCTS, MCITP, RHCT, RHCSA, RHCE, VSP4, VTSP4, VCP4, VSP5, VTSP5, VCP5-DCV, VCA-Cloud、VCA-DCV、VCA-WM、VCP-Cloud、VCP5-DT。
    ↧
    Search

    143 期 - WS 2016 免費整合私有雲快速建置 Azure Pack

    December 28, 2017, 6:49 pm
    $
    0
    0

    網管人雜誌

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





    文章目錄

    前言
    Azure Pack vs Azure Stack
              Azure Stack 管理 Azure Pack
    實戰 Azure Pack on Windows Server 2016
              Windows Azure Pack 佈署架構
              佈署 Azure Pack 運作架構
    結語





    前言

    在雲端運算、AI 人工智慧、ML 機器學習……等議題的推波助瀾之下，不管是傳統產業或科技產業的各種產業類別，每家企業或組織當中的商務流程或多或少都會使用到雲端服務業者建立的服務，或者由企業或組織的 IT 團隊在內部資料中心自建私有雲環境。

    從 RightScale 最新的雲端運算發展趨勢調查結果顯示，在公有雲（Public Cloud）的部分已經從 2015 年 88 % 上升至 2017 年的 89 %，至於私有雲的部分則是從 2015 年 63 % 上升至 2017 年的 72 %。此外，隨著公有雲及私有雲技術不斷成熟且比例逐漸上升的情況下，連帶也讓企業及組織導入混合雲（Hybrid Cloud）的比例，由 2015 年 58 % 上升至 2017 年的 67 %，最終企業或組織採用雲端運算技術的比例也從 2015 年的 93 % 上升至 2017 年的 95 %（如圖 1 所示）。

    圖 1、2017 年企業及組織採用雲端運算技術比例
    圖片來源： RightScale - 2017 State of the Cloud Report

    首先，在「公有雲」的部分，Microsoft Azure 公有雲的入口網站在 2015 年 12 月之前，一直以來都是採用ASM（Azure Service Management）的管理模式（如圖 2 所示），並且是以「服務」為單位進行分類及運作。
    目前，企業及組織仍然可以瀏覽 https://manage.windowsazure.com 網址，結合 Azure 訂閱帳戶登入 Azure ASM Portal 公有雲環境進行管理及佈署，然而除非是新版 ARM Portal 無法提供的服務，否則並不建議仍採用舊有的 ARM Portal 進行管理作業。
    圖 2、舊有 Azure 入口網站，採用 ASM（Azure Service Management）管理模式

    在「私有雲」的部分，倘若企業及組織希望在內部資料中心內，建立類似 Microsoft Azure 雲端運作基礎架構及環境的話，那麼也可以透過 WAP（Windows Azure Pack），結合 Windows Server 2012 R2 Hyper-V + System Center 2012 R2 自行打造私有雲環境（如圖 3 所示）。

    此外，當企業在內部資料中心透過 WAP 整合 Hyper-V 及 System Center，建構內部私有雲環境中也可以整合相關機制，達到建構「混合雲」運作環境的目的，舉例來說，可以在 WAP 中建構 ADFS 同盟服務與 Azure AD 協同運作，達成混合雲運作環境中使用者身分驗證的目的。

    圖 3、企業及組織透過 Windows Azure Pack 建立私有雲運作架構

    2015 年 12 月之後，在「公有雲」的部分微軟推出新版入口網站並採用 ARM（Azure Resource Manager）管理模式，只要於 Azure ARM Portal 入口網站中（如圖 4 所示），使用 Azure 訂閱帳戶即可登入，並且逐步提供將舊有 Azure ASM 公有雲環境遷移至 ARM 環境的方式。同時，Azure 後續推出的新版雲端服務，也大部分僅在 Azure ARM Portal 入口網站中，才能夠進行佈署及管理作業。
    目前，企業及組織只要瀏覽 https://portal.azure.com 網址，結合 Azure 訂閱帳戶即可登入 Azure ARM Portal 公有雲環境進行管理及佈署作業。
    圖 4、新版 Azure 入口網站，採用 ARM（Azure Resource Manager）管理模式

    在「私有雲 / 混合雲」的部分，微軟為了提供給開發人員一致的程式編寫平台（只要內部編寫一次，上傳至公有雲環境中便可立即使用），並且同樣採用 Azure Resource Manager 管理模式，以便為 IT 管理人員提供一致的管理操作體驗平台。台灣微軟在 2017 年 8 月 30 日，正式宣佈與 Intel、HPE、Cisco、Dell、Lenovo 等業者合作推出 MAS（Microsoft Azure Stack）一體機，讓企業及組織可以在內部資料中心內部署 Azure Stack 服務（如圖 5 所示），也可以跟國內電信業務申請租用 Azure Stack 服務。
    微軟在 2016 年 1 月推出 Azure Stack TP1 技術預覽版本，後續約每半年推出 TP2、TP3 技術預覽版本，最終於 2017 年 7 月推出正式版本。
    圖 5、企業及組織透過 Microsoft Azure Stack 建立私有雲及混合雲環境





    Azure Pack vs Azure Stack

    雖然，微軟新一代的私有雲及混合雲平台為 MAS（Microsoft Azure Stack），然而對於中小型企業或組織來說，建置 MAS 私有雲及混合雲平台不管是軟體授權或硬體設備等費用皆所費不貲，並非一般中小型企業或組織所能夠負擔。此外，雖然微軟有提供「Azure Stack Development Kit」方案，讓企業及組織能夠自行下載建置 Azure Stack 在「單台」伺服器當中，但這樣的佈署及應用情境僅限於「研發 / 測試」環境。
    佈署 Azure Stack Development Kit 的 x86 硬體伺服器，至少應具備 2 顆 CPU 處理器（16 個實體運算核心）和 128 GB 記憶體空間，及 4 顆至少 250 GB 儲存空間的硬體才能夠順利佈署 Azure Stack Development 運作環境。

    那麼，對於中小型企業或組織來說，除了透過 Azure Stack 建立全方位的私有雲及混合雲平台之外，是否還有其它自行建構中小型的私有雲解決方案？ 現在，微軟提供一般中小型企業或組織，無須專用硬體設備及其它額外的軟體授權，只要採用第一代的微軟私有雲平台 Azure Pack，並且整合 Windows Server 2016 及 System Center 2016 管理平台，便可以在內部資料中心內建構中小型的私有雲及混合雲解決方案。

    事實上，在 Windows Server 2016 及 System Center 2016 正式發佈時，Azure Pack 並不支援與這 2 個產品進行整合，所以當時有種說法是 Azure Pack 私有雲平台，只能運作在 Windows Server 2012 R2 及 System Center 2012 R2 環境。其實，只要採用 Windows Azure Pack UR10或後續版本，便能夠無縫與 Windows Server 2016 及 System Center 2016 整合（如圖 6 所示），並且使用 Windows Server 2016 新的特色功能，例如，Shielded VMs、SDN v2……等。

    圖 6、採用 Windows Server 2016 建置的 Azure Pack 私有雲環境，主要支援可至 2022 年而延伸支援可至 2027 年
    圖片來源： Hybrid Cloud Best Practices - Windows Azure Pack lifecycle was extended to 2027

    簡單來說，企業及組織倘若僅需要建立 IaaS 基礎架構即服務運作架構的話，那麼採用 Windows Azure Pack 建置私有雲平台便非常適合，並且可以使用內部資料中心內原有基礎架構資源進行建置即可，倘若需要全方位的私有雲及混合雲解決方案則應採用 Microsoft Azure Stack（如圖 7 所示）。值得注意的是，採用新一代的 Microsoft Azure Stack 混合雲平台，企業及組織必須採用特定服務供應商的硬體才能順利佈署及運作，而無法直接使用內部資料中心內原有基礎架構資源進行建置。

    圖 7、Windows Azure Pack 與 Microsoft Azure Stack 運作架構示意圖
    圖片來源： Microsoft Ignite Australia 2017 – Azure Pack towards Azure Stack

    值得注意的是，雖然 Windows Azure Pack 與 Microsoft Azure Stack 這 2 種解決方案，都提供 IaaS 基礎架構即服務的運作架構，但是 Windows Azure Pack 底層是採用 ASM（Azure Service Management）管理模式，而 Microsoft Azure Stack 與現在 Azure 公有雲同樣採用 ARM（Azure Resource Manager）管理模式。

    因此，在 Windows Azure Pack 與 Microsoft Azure Stack 提供給不同「租用戶」（Tenant），所需要的各項 IaaS 服務時仍然有些許不同，舉例來說，在新一代的 Microsoft Azure Stack 當中便是透過 Subscription、Offer、Plan、Service等不同功能（如圖 8 所示），達到提供 IaaS 服務給租用戶的目的：

    • Subscription：定義租用戶可以使用哪些 Offer、Plan、Service。
    • Offer：租用戶可以使用哪些 Plan，例如，Plan A 為 VM 虛擬主機資源而 Plan B 則為儲存資源。
    • Plan：組態設定資源使用額度機制，以便限制租用戶能夠使用的資源範圍，例如，限制租用戶只能建立 2 台 VM 虛擬主機、總共只能使用 10 vCPU 虛擬處理器、只能使用 16 GB vRAM 記憶體……等。
    • Service：定義租用戶能夠使用的應用程式及服務資源，例如，VM 虛擬主機、SQL Server 資料庫……等。

    圖 8、Windows Azure Pack 與 Microsoft Azure Stack 提供租用戶 IaaS 服務的運作架構示意圖
    圖片來源： Microsoft Ignite Australia 2017 – Azure Pack towards Azure Stack



    Azure Stack 管理 Azure Pack

    倘若，企業及組織在早期已經建置底層為 Windows Server 2012 R2，搭配 System Center 2012 R2 所搭建的 Windows Azure Pack 私有雲平台，隨著公司運作規模不斷擴增導入新一代 Microsoft Azure Stack 混合雲平台時，那麼原有的 Windows Azure Pack 私有雲平台，是否就無用武之地只能形成資源孤島？

    答案當然是否定的，簡單來說企業及組織的 IT 管理團隊，只要在 Microsoft Azure Stack 混合雲平台中，安裝 Windows Azure Pack Connector 軟體套件後，便可以直接透過 Microsoft Azure Stack 混合雲平台，管理 Windows Azure Pack 的 IaaS 基礎架構即服務，但是 Windows Azure Pack 上運作的 VM 虛擬主機，則仍由原本的 SPF（Service Provider Foundation），以及 SCVMM（System Center Virtual Machine Manager）進行佈署的動作（如圖 9 所示）。
    根據微軟官方建議，透過 Windows Azure Pack Connector 管理 Windows Azure Pack 環境，僅限於 Azure Stack Development Kit 所建構的研發測試環境，不建議用於 Microsoft Azure Stack 正式營運環境中。
    圖 9、Windows Azure Pack Connector 運作架構示意圖
    圖片來源： Microsoft Docs – Manage Windows Azure Pack Virtual Machines from Azure Stack





    實戰 Azure Pack on Windows Server 2016

    現在，企業及組織只要準備好 Windows Server 2016 及 System Center 2016，便可以著手建置 Windows Azure Pack 運作環境，提供使用者自助式入口網站和各式各樣的雲端服務（如圖 10 所示）：

    • 入口網站：在 Portal 入口網站的部分共有 2 種類型，第 1 種是針對管理人員入口網站（Admin Portal），以便組態設定雲端資源、使用者帳號、租用戶方案、配額、定價。第 2 種則是針對租用戶入口網站（Tenant Portal），以便租用戶使用者可以在自助式入口網站中，進行雲端服務（例如，VM 虛擬主機）的佈署、監控、管理服務。
    • 服務管理 API：透過 REST API 提供客製化整合案例，例如，自訂入口網站以及租用戶資源計費系統。
    • VM 虛擬主機雲端：提供 Windows 及 Linux 虛擬主機 IaaS 基礎架構即服務，包括 VM 虛擬主機範本、調整運作規模、VM 虛擬主機的虛擬網路環境 …… 等。
    • 網站雲端：提供 ASP .NET、PHP、Node.js 等可擴充的 Web 應用程式服務，建構 PaaS 平台即服務的運作環境。
    • 資料庫雲端：提供 SQL Server 和 MySQL 資料庫執行個體服務，建構 DbaaS 資料庫即服務搭配網站雲端使用。
    • 服務匯流排雲端：在分散式應用程式之間提供可靠訊息服務。
    • 自動化：將其他自訂服務整合至運作架構中，包括 Runbook 及執行環境……等。

    請注意，Windows Azure Pack Web Sites雲端服務，僅「支援」底層採用 Windows Server 2012 R2 時才能順利運作，並「不支援」佈署在底層為 Windows Server 2016 的作業系統平台。同時，Windows Azure Pack Web Sites v2 雲端服務，主流支援服務至 2017 年 7 月 11 日，而延伸支援服務至 2022 年 7 月 12 日。
    圖 10、Windows Azure Pack 運作架構及特色功能示意圖
    圖片來源： 微軟官網 – Windows Azure Pack 白皮書



    Windows Azure Pack 佈署架構

    POC 測試驗證架構
    在整個 Windows Azure Pack 運作架構當中，可以依照企業或組織的需求及運作規模大小，決定採用的 Windows Azure Pack 佈署架構，舉例來說，倘若企業及組織只是想要快速建構 Windows Azure Pack 運作環境，進行 POC 概念性驗證以便評估是否要正式佈署 Windows Azure Pack 時，便可以採用「Windows Azure Pack 快速佈署架構」（如圖 11 所示），將 Windows Azure Pack 的必要運作元件安裝在「同 1 台」主機上即可。

    圖 11、Windows Azure Pack 快速佈署架構示意圖
    圖片來源： MSDN Library – Windows Azure Pack Architecture


    小型規模運作架構
    順利評估 Windows Azure Pack 特色功能滿足企業需求後，倘若只需要佈署小型規模的 Azure Pack 運作架構時，那麼最簡單的佈署方式便是將「相關角色拆分」在不同的主機上運作即可，此時 IT 管理人員可以參考及採用「Windows Azure Pack 基本分散式佈署架構」（如圖 12 所示），以避免不同角色在同 1 台主機上資奪硬體資源，造成屆時使用 Azure Pack 雲端服務時不良的操作體驗。

    圖 12、Windows Azure Pack 基本分散式佈署架構示意圖
    圖片來源： MSDN Library – Windows Azure Pack Architecture


    中型規模運作架構
    隨著企業及組織的商業模式不斷擴增，企業內部使用 Windows Azure Pack 自助式入口網站，以及相關雲端服務的使用者人數不斷增加的情況下，只是單純將 Azure Pack 運作角色拆分在不同主機上運作，可能已經無法滿足使用者對於服務快速回應及高可用性的需求。

    此時，除了將 Azure Pack 運作角色拆分在不同主機上運作之外，也為不同的運作元件加入「負載平衡」（Load Balance）及「容錯移轉叢集」（Failover Cluster）機制，IT 管理人員可以參考及採用「Windows Azure Pack 小型分散式佈署架構」（如圖 13 所示），以便平時可以有多台主機一同分散工作負載，即便某台擔任同個運作角色的主機發生故障損壞事件時，也能由其它存活的主機繼續回應使用者請求的雲端服務，滿足使用者對於 Azure Pack 雲端服務的高可用性需求。

    圖 13、Windows Azure Pack 小型分散式佈署架構示意圖
    圖片來源： MSDN Library – Windows Azure Pack Architecture


    大型規模運作架構
    當企業內部使用 Windows Azure Pack 自助式入口網站，以及雲端服務的使用者人數不斷增加，甚至企業以成本利潤中心的概念，提供雲端服務給不同部門別並進行計價的動作。因此，除了服務快速回應及高可用性的需求之外，也必須因應專案數量暴發或大型促銷這種工作負載急增的需求。

    此時，除了將 Azure Pack 運作角色拆分在不同主機上運外，以及剛才加入的「負載平衡」（Load Balance）及「容器移轉叢集」（Failover Cluster）機制之外，所有運作角色規模的擴充也必須更容易更即時才能夠因應，IT 管理人員可以參考及採用「Windows Azure Pack 可擴充分散式佈署架構」（如圖 14 所示），以便平時可以有多台主機一同分散工作負載，當專案數量暴發或大型促銷導致工作負載急增時，也能夠快速為每個運作角色擴充運作規模，以便滿足使用者對於雲端服務的快速回應和高可用性需求。

    圖 14、Windows Azure Pack 可擴充分散式佈署架構示意圖
    圖片來源： MSDN Library – Windows Azure Pack Architecture



    佈署 Azure Pack 運作架構

    了解 Windows Azure Pack 特色功能及佈署架構後，在開始建立 Azure Pack 運作架構及進行組態設定作業之前，我們先了解在 Azure Pack 運作架構中，需要建置的角色共有 Windows AD 網域環境（DNS / DHCP / Certificate Authority / Service Accounts）、Hyper-V 虛擬化平台、SCVMM 管理平台、Azure Pack Admin Portal、Azure Pack Tenant Portal、SPF……等。

    雖然建置 Windows Azure Pack 基礎架構，在相關伺服器角色上並沒有絕對的先後順序，不過在建構基礎架構時卻有相關的工法可供遵循，接下來我們將簡介本文整個 Windows Azure Pack 基礎架構的安裝及設定流程：

    1. 建立 Windows AD（Active Directory）網域環境及相關服務帳戶和群組。
    2. 安裝及組態設定 Hyper-V 虛擬化平台（Hyper-V、Storage、Failover Cluster）。
    3. 安裝及組態設定 SQL Server 資料庫。
    4. 安裝及組態設定 SCVMM（System Center Virtual Machine Manager）虛擬化管理平台。
    5. 安裝及組態設定 SPF（Service Provider Foundation），以便擔任 VMM 及 WAP 之間溝通的橋樑。
    6. 安裝及組態設定 WAP（Windows Azure Pack），以便提供管理人員及租用戶入口網站。


    建構 Windows AD 網域環境
    在 Windows Azure Pack 的運作架構中，由於有多個運作角色之間必須協同運作，同時在系統管理思維當中應該要針對每個角色建立服務角色。因此，請在建立好 Windows AD 網域環境後，預先建構後續各項運作角色會使用到的服務帳戶，例如，用於 SQL Server 服務帳戶為 SQL-SVC、用於 SFP 服務帳戶為 SPF-SVC、用於 VMM 服務帳戶為 VMM-SVC……等（如圖 15 所示）。

    圖 15、建立相關服務帳戶及群組


    建構 Hyper-V 虛擬化平台
    建構 Hyper-V 虛擬化平台，並且整合容器錯移轉叢集運作機制以便提供高可用性（如圖 16 所示）。屆時，當使用者登入租用戶入口網站後，執行佈署 VM 虛擬主機的動作時，底層 VMM 管理平台便會將 VM 虛擬主機佈署至 Hyper-V 虛擬化平台中。

    此外，除了傳統 SAN 儲存資源之外，也可以整合 Windows Server 2016 當中的 S2D（Storage Spaces Direct）軟體定義儲存技術，用來擔任 Hyper-V 虛擬化平台儲存資源。

    圖 16、建構高可用性 Hyper-V 虛擬化平台


    建構 SQL Server 資料庫
    本文實作環境採用 SQL Server 2016 擔任 SCVMM、SPF 資料庫，在正式營運環境中建議 WAP 使用的資料庫，也就是提供租用戶 DBaaS 資料庫即服務的部分，應該要與 SCVMM 及 SPF 使用的基礎架構資料庫分開。

    值得注意的是，在安裝 SQL Server 2016 的過程中，於 Feature Selection 頁面中至少要勾選「Database Engine Services」功能項目，在 Server Configuration 頁面中，請將 SQL Server Agent 及 SQL Server Database Engine 項目的帳戶名稱，調整為在 DC 網域控制站當中針對 SQL Server 建立的服務帳戶，並且將啟動類型調整為「Automatic」，至於定序的部分採用預設的「SQL_Latin1_General_CP1_CI_AS」即可（如圖 17 所示）。

    圖 17、安裝 SQL Server 2016 資料庫


    建構 SCVMM 管理平台
    本文實作環境中，採用 System Center 2016 Virtual Machine Manager 擔任虛擬化管理平台，值得注意的是，在安裝 SCVMM 之前必須先安裝「Windows ADK for Windows 10，version 1607」軟體套件，至於安裝選項只要勾選「Deployment Tools」及「Windows Preinstallation Environment（Windows PE）」即可（如圖 18 所示）。

    圖 18、安裝 System Center 2016 Virtual Machine Manager 虛擬化管理平台

    此外，因為 SCVMM 的資料庫並非採用本機 SQL Server Express，所以也必須先安裝 SQL 工具 Native Client及 Command Line Utilities，並且安裝完畢後必須重新啟動 SCVMM 主機，否則稍後 SCVMM 安裝程序也會提醒必須重新啟動才能繼續安裝程序。同時，SCVMM 安裝過程中，便會連線至指定的 SQL Server 中建立名稱為「VirtualManagerDB」的資料庫（如圖 19 所示）。

    圖 19、至指定的 SQL Server 中建立 VirtualManagerDB 資料庫


    建構 SPF 以便介接 VMM 及 WAP
    事實上，在 Windows Azure Pack 的運作架構中，當管理人員或租用戶登入 WAP 入口網站後進行的任何動作，並非直接與底層的 SCVMM 虛擬化管理平台互動，而是透過 SPF 擔任 WAP 與 SCVMM 之間溝通的橋梁（如圖 20 所示），舉例來說，當租用戶登入 WAP 入口網站後進行 VM 虛擬主機的佈署作業時，便是透過 SPF 中介與 SCVMM 互動，至於各種資源使用量監控的部分也是透過 SPF 中介與 SCOM 進行互動。

    圖 20、安裝 SPF 中介溝通角色

    值得注意的是，SPF 角色可以跟 SCVMM 主機安裝在同一台也可以獨立一台，並且安裝檔案在 System Center Orchestrator ISO 內，並且在 SPF 安裝過程中將會連線至指定的 SQL Server 中建立名稱為「SCSPFDB」的資料庫（如圖 21 所示）。

    圖 21、至指定的 SQL Server 中建立 SCSPFDB 資料庫


    建構 WAP 入口網站
    只要下載並執行 Web Platform Installer（本書實作環境為 5.0 版本），點選至 Products 搜尋關鍵字 Windows Azure Pack，便會找到安裝 Windows Azure Pack 相關運作元件及角色等項目。倘若，你希望佈署「Windows Azure Pack 快速架構」，也就是所有運作元件及角色都在同 1 台主機時，那麼請搜尋「Windows Azure Pack：Portal and API Express」項目並進行安裝作業即可（如圖 22 所示）。

    圖 22、安裝及佈署 Windows Azure Pack 快速架構

    接著請在 WAP 主機開啟瀏覽器，鍵入網址 https://localhost:30101進行建立 WAP 資料庫的動作，完成後將會在 WAP 資料庫中，看見許多以「Microsoft.MgmtSvc」名稱開頭所建立的資料庫（如圖 23 所示）。

    圖 23、WAP 初始化並建立 WAP 資料庫

    完成 WAP 初始化並建立 WAP 資料庫之後，便可以連結網址 https://localhost:30091 進入管理者入口網站（Admin Portal），建立 VM Clouds、Plans、租用戶使用者帳號……等。最後，租用戶便可以登入使用者入口網站（Tenant Portal），並且看到管理人員所給予的建立相關雲端資訊的項目（如圖 24 所示）。

    圖 24、租用戶登入使用者自助式入口網站





    結語

    透過本文的說明及實作演練，相信讀者已經完全了解 Windows Azure Pack 的運作元件及佈署架構，以及如何建置 Windows Azure Pack 運作環境。在後續實戰文章中我們也將會討論及實作演練，Windows Azure Pack 整合 Windows Server 2016 特色功能，例如，Shielded VMs、SDN v2……等。
    ↧

    檢查是否已更新 CPU Speculative Execution 漏洞

    January 7, 2018, 7:08 pm
    $
    0
    0

    前言

    最近幾天大家關心的話題之一，相信就是 CPU Speculative Execution漏洞議題，大家紛紛討論此次 CPU 漏洞造成的影響，並且這個漏洞不光影響一般企業或使用者，即便是雲端大廠 AWS, Azure, GCP 也都造成影響。相關資訊請參考下列連結：

    在 Windows Server及 Windows Client 的部分，則請參考微軟相關文章：




    檢查是否更新完成

    如果，你已經更新 BIOS / Firmware 及 Windows OS 相關更新後，該如何快速確認已經更新完畢，以便阻擋 CPU Speculative Execution 漏洞攻擊行為？ 微軟已經發佈新的 SpeculationControl的 PowerShell 模組幫助你檢查，請以「系統管理員」身份執行 PowerShell 後鍵入「Install-Module SpeculationControl」指令即可進行安裝。

    圖、安裝 SpeculationControl 的 PowerShell 模組

    安裝完畢後，便可以執行「Get-SpeculationControlSettings」指令進行檢查，如下圖所示目前受檢查的主機皆尚未安裝 BIOS / Firmware 及 Windows OS 相關更新。

    圖、尚未安裝 BIOS / Firmware 及 Windows OS 相關更新

    請安裝硬體的 BIOS / Firmware 相關更新，至於 Windows OS 的部分以 Windows 10 來說便需要安裝 KB4056892安全性更新。

    圖、為 Windows 10 安裝 KB4056892 安全性更新

    安裝完畢並重新啟動主機後，再次執行「Get-SpeculationControlSettings」指令進行檢查，如下圖所示可以看到相關防護機制皆已啟動完成。

    圖、更新完成並再次檢查後可發現相關防護機制皆已啟動完成

    倘若，僅安裝 Windows OS 的相關更新但是硬體的 BIOS / Firmware 未更新的話，那麼執行檢查的結果可能如下圖所示：

    圖、硬體 BIOS / Firmware 未更新的檢查結果
    ↧
    ↧

    144 期 - 實戰雙節點 vSAN 叢集，見證機制確保可用性

    January 15, 2018, 7:30 am
    $
    0
    0

    網管人雜誌

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





    文章目錄

    前言
    vSAN 6.6.1 增強功能
    實戰 vSAN 2 Node 叢集架構
              vSAN ESXi 6.5 硬體需求
              建立資料中心及叢集
              建立 vDS 分散式交換器
              叢集啟用 vSAN 軟體定義儲存機制
              佈署 Witness 見證機制
              高可用性測試
    結語





    前言

    在 VMware 官方打造 SDDC 軟體定義資料中心的願景中，負責 SDS 軟體定義儲存解決方案的角色便是 VMware vSAN（Virtual SAN）。簡單來說，企業及組織只要透過 VMware vSAN 軟體定義儲存技術，便可以將多台安裝 ESXi 虛擬化平台 x86 實體伺服器中，所有「本機硬碟」（LocalHardDisk）儲存空間匯整後（例如，NVMe 快閃儲存、SSD 固態硬碟、HDD 機械式硬碟……等），建構出高可用性高效能的共享儲存資源集區。

    在 VMworld 2017 大會上，負責 VMware vSAN 解決方案的 Duncan Epping 技術長，所主講的 Top 10 things to know about vSAN議程中，開宗明義便提到 VMware vSAN 為「Object-Based Storage」（如圖 1 所示），並且每個「物件」（Object）都會包含多個「元件」（Component），同時採用「儲存原則」（Storage Policy）來管理分散的儲存資料。

    此外，由 VMware vSAN 所建構的共享儲存資源集區中，還能夠直接運作 VM 虛擬主機及容器等工作負載，因此企業及組織在建構 VMware vSAN 軟體定義儲存環境後，便能同時解決建置「運算 / 儲存」2 大資源的難題，這也是目前非常熱門的「超融合式架構」（Hyper-Converged Infrastructure，HCI）應用情境。

    圖 1、VMware vSAN Object-Based Storage 運作示意圖
    圖片來源： VMworld 2017 - Top 10 things to know about vSAN





    vSAN 6.6.1 增強功能

    在 2017 年 4 月時，VMware 官方正式推出最新第 6 代 VMware vSAN 6.6並且新增 23 項特色功能，緊接著在 VMworld 2017 舉辦前夕於 2017 年 7 月推出 VMware vSAN 6.6.1 增強版本，同時在此增強版本中再新增 3 項特色功能：

    • 整合 VMware Update Manager：在過去的 vSAN 版本當中，管理人員倘若需要針對 vSAN 叢集進行版本升級作業時，除了必須確保 vSAN 叢集整體升級程序，以及確認 vSAN 硬體相容性（例如，SAS、SATA、NVMe…… 等）之外，執行版本升級作業時還必須要管理人員手動處理才行。現在，Update Manager 可以針對 vSAN 運作環境提出建議，它可以掃描 vSAN 叢集和 vSAN 節點主機之後，建議相關安全性更新、修補程式、擴充功能 …… 等，並且會驗證 vSAN 節點主機是否符合及支援 vSAN HCL 規範。值得注意的是，vSAN 運作環境必須要能連接至網際網路，Update Manager 才能順利產生各項建議，倘若 vSAN 叢集是透過 Proxy 代理伺服器連接至網際網路時，那麼 vSAN 運作環境則可以產生修補程式及升級建議，但是將無法進行主要版本升級作業。
    • 運作效能診斷：針對 vSAN 叢集及 vSAN 節點主機進行運作效能基準線測試，例如，最大吞吐量、最小延遲時間、時間範圍……等，系統將會檢測出運作效能是否有任何問題，並且提出修復運作效能問題的操作步驟，同時提供運作效能圖表以便管理人員能夠深入了解效能表現情況（如圖 2 所示）。此外，管理人員還可以透過 HCI Bench 這個 API Level 的效能診斷機制，進一步查詢效能診斷的詳細資訊。值得注意的是，必須加入 CEIP 客戶體驗改善計畫，並且啟用 vSAN Performance Service 機制之後才能使用此特色功能。
    • 儲存設備可維護性：過去的 vSphere 運作環境中，當採用 RAID 控制器的 ESXi 主機硬碟發生問題時，便能透過驅動損壞硬碟 LED 燈亮的方式快速找出故障損壞硬碟。但是，驅動損壞硬碟 LED 燈亮的方式在過去的 vSAN 運作環境中，因為「不」支援 HBA 或 Pass-Throuth 控制器而無法順利使用。現在，驅動損壞硬碟 LED 燈亮的方式已經支援 HBA 或 Pass-Throuth 控制器，所以當 vSAN節點主機硬碟發生問題時管理人員便能快速找出故障損壞硬碟。舉例來說，在 HPE DL G9 / ML G9 系列的伺服器便已經正式支援此功能。

    圖 2、vSAN效能診斷示意圖
    圖片來源： VMware StorageHub - vSAN 6.6 - Performance Diagnostics（vSAN 6.6.1）





    實戰 vSAN 2 Node 叢集架構

    事實上，在第 3 代 vSAN 6.1版本的運作環境中，便已經支援「2 Node」的 vSAN 節點主機建構 vSAN 叢集的運作環境，這種小型的 vSAN 軟體定義儲存運作架構，非常適合企業及組織中分公司或小型運作環境時使用。

    雖然，vSAN 6.1 支援 2 台 vSAN 節點主機的叢集運作架構，但是仍至少需要配置「1 台」昂貴的 10 Gbps 網路交換器才行，然而卻僅使用到該台 10 Gbps 網路交換器 2 ~ 4 個連接埠而已，倘若考慮避免發生 SPOF 單點失敗情況時，則需要配置「2 台」10 Gbps 網路交換器才行，並且每台 10 Gbps 網路交換器仍只會用到 1 ~ 2 個連接埠而已，這對於建置分公司或小型 vSAN 運作規模的整體 IT 預算來說無疑加重負擔。

    從第 5 代 vSAN 6.5版本開始，正式支援在 2 Node vSAN 叢集運作架構中，2 台 vSAN 節點主機可以直接透過「交叉式纜線」（Crossover Cables）的方式互相連接（如圖 3 所示），無須像過往舊版 2 Node vSAN 運作環境中，必須透過 10 Gbps 網路交換器才能進行 vSAN 節點主機的資料交換作業。

    因此，當企業及組織在建置分公司或小型 vSAN 運作環境時，無須再被迫採購昂貴的 10 Gbps 網路交換器，所以能有效降低分公司或小型 vSAN 運作規模的整體 IT 預算，根據 VMware 官方分析調查的結果顯示此舉可以有效降低約「20 %」的投資成本。

    在組態設定部分，根據 VMware 官方的最佳作法建議，當 vSAN 叢集當中的節點主機透過交叉式纜線互相連接之後，在 vSAN 節點主機網路流量規劃的部分，應該要將「vSAN 儲存流量」及「vMotion 遷移流量」分開在不同的 10 Gbps 纜線進行傳輸，以避免儲存或遷移流量互相干擾的情況發生，舉例來說，倘若 2 台 vSAN 節點主機正透過 vSAN 儲存流量網路大量同步資料狀態的情況下，此時又剛好執行 vMotion 線上遷移機制大量移動 VM 虛擬主機的話，那麼有可能會增加 10 Gbps 的網路延遲時間及工作負載。

    此外，有關 vSAN 節點主機網路流量規劃方面除了將儲存及遷移流量分開之外，也應該要組態設定為互相備援機制以便故障情況發生時，能夠有另 1 個 10 Gbps 纜線進行網路流量的容錯移轉。
    VMware 官方建議，當 vSAN 運作架構採用「Hybrid」儲存組態時，在儲存網路流量的部分至少規劃 1 Gbps網路頻寬，當 vSAN 運作架構採用「All-Flash」儲存組態時，在儲存網路流量的部分必須要規劃 10 Gbps 網路頻寬。

    圖 3、2 台 vSAN 節點主機透過交叉式纜線連接後，網路流量規劃的組態配置示意圖
    圖片來源： VMware vSAN 6.5 Technical Overview – 2 Node Configuration with Crossover Cables

    此外，從第 5 代 vSAN 6.5 版本開始，新增「見證網路流量」（Witness Traffic）分離的特色功能，解決在 2 台 vSAN 節點主機之間必須建立及維護靜態路由的組態設定，有效降低 vSAN 叢集運作架構的複雜度，同時在安全性方面也能得到改善，因為 vSAN 儲存網路流量與 WAN 見證網路流量現在能夠完全分離了。

    值得注意的是，負責 vSAN 叢集運作架構的見證虛擬設備（vSAN Witness Appliance），「不得」運作在 2 台 vSAN 節點主機之上以避免誤判的情況發生。同時，一般來說 2 台 vSAN 節點主機的小型運作架構，通常是運作在企業及組織的分公司或遠端辦公室當中，所以分公司或遠端辦公室若有透過 WAN 網路與主要資料中心連接時，那麼管理人員可以考慮將見證虛擬設備運作在主要資料中心內，除了節省建置第 3 台 ESXi 主機以便運作見證虛擬設備之外，也能達到將見證虛擬設備運作在主要資料中心內達到統一管理的目的（如圖 4 所示）。

    圖 4、支援將 vSAN 見證虛擬設備運作在主要資料中心內的運作架構示意圖
    圖片來源： VMware Blogs - The vSAN Witness Appliance in vCloud Air：Part 1（Overview）



    vSAN ESXi 6.5 硬體需求

    在建構 vSAN 軟體定義儲存叢集架構時，值得注意的部分主要在於硬體組態配置，舉例來說，倘若管理人員希望在測試環境嘗試建構 vSAN 叢集架構時，那麼 ESXi 主機的記憶體資源至少需要「8 GB」才行。

    此外，在建構正式營運環境的 vSAN 叢集架構時，倘若採用 vSAN Ready Node 的話則無須擔心硬體組態配置，若是自行規劃時則必須要注意除了安裝 ESXi Hypervisor 採用傳統的 RAID 之外，其它由 vSAN 軟體定義儲存所管理的儲存裝置，必須要採用 HBA 控制器（Passthrough 或 RAID 0 Mode）機制才行（如圖 5 所示），這是初次建置 vSAN 叢集架構時，管理人員最容易忽略的部分。

    圖 5、自行配置 vSAN 節點主機硬體組態參考架構
    圖片來源： VMware vSphere Blog - VMware Virtual SAN Hardware Design Guide



    建立資料中心及叢集

    當管理人員安裝好 vCenter Server 及 ESXi 主機後，首先請建立「資料中心」（Datacenter）接著建立「叢集」（Cluster），但是先「不要」針對建立的叢集啟用 vSAN 功能。

    值得注意的是，在目前 vCenter Server 的主要管理工具，分別支援 vSphere Web Client（Flash-Based）及 vSphere HTML Client（HTML5-Based）。

    雖然，VMware 官方已經宣佈後續版本的操作介面，將採用全新開發且操作更為順利的 vSphere HTML Client，然而即便目前最新的 vSphere 6.5 update1 版本中，vSphere HTML Client 仍僅支援「部分」功能而非全功能組態設定，舉例來說，在建立「叢集」（Cluster）時 vSphere HTML Client 操作介面，便無法啟用 vSAN 特色功能且後續在叢集操作介面中也無法進行管理（如圖 6 所示）。
    在 2017 年 8 月 25 日時，VMware 在官方部落格中正式宣佈下一版 vSphere 當中，將會以 vSphere HTML Client 為主要管理工具，同時在下一版 vSphere 當中將不會再有 vSphere Web Client 管理工具。詳細資訊請參考 VMware vSphere Blog - Goodbye，vSphere Web Client!。

    圖 6、建立 vSAN 用途的資料中心及叢集

    順利建立 vSAN 用途的資料中心及叢集之後，請將完成硬體配置的 2 台 ESXi 主機加入至叢集當中，順利加入叢集後請先確認 ESXi 主機，是否擁有足夠建立 vSAN 軟體定義儲存的硬體配置。如圖 7 所示，在本文實作環境中 2 台 ESXi 主機，除了安裝 ESXi Hypervisor 的儲存裝置之後，還額外配置「3 個」100 GB 空間大小的 SSD 固態硬碟。

    圖 7、每台 vSAN 節點主機皆額外配置 3 個 100 GB 容量的 SSD 固態硬碟



    建立 vDS 分散式交換器

    在剛才建立 vSAN 用途的叢集時，建議先不要啟用 vSAN 特色功能的主要原因在於，我們尚未組態設定好 vSAN 節點主機的網路組態。同時，在 vSAN 網路環境規劃建議作法當中，針對 vSAN 網路環境建議採用「vDS 分散式網路交換器」（vNetwork Distributed Switch）為佳。

    現在，請為 vSAN 節點主機組態設定 vDS 分散式網路交換器，下列分別說明採用 vSphere Web Client 及 vSphere HTML Client 這 2 項管理工具時，如何建立 vDS 分散式網路交換器：

    • vSphere Web Client：請依序點選【首頁 > 網路功能 > 網路 > Distributed Switch > 新增 Distributed Switch】。
    • vSphere HTML Client： 請依序點選【功能表 > 網路功能 > Datacenter > 動作 > Distributed Switch > 新增 Distributed Switch】。


    在彈出的新增 Distributed Switch 視窗中，首先請指定建立的 vDS 分散式網路交換器名稱及位置，在本文實作環境中 vDS 分散式網路交換器名稱為「vSAN-DSwitch」，接著選擇 vDS 分散式網路交換器版本，因為本文實作環境中並沒有新舊版本混合的 ESXi 主機所以選擇採用最新「6.5.0」版本，最後在設定組態頁面中，除了連接埠群組名稱改為「vSAN-DPortGroup」之外其餘採用系統預設值即可（如圖 8 所示）。

    圖 8、建立 vDS 分散式網路交換器及連接埠群組

    順利新增 vDS 分散式網路交換器及連接埠群組之後，請將 vSAN 節點主機中用於 vSAN 儲存流量的網路卡，加入至剛才所建立的 vDS 分散式網路交換器及連接埠群組當中：

    • vSphere Web Client： 請依序點選【網路功能 > vCenter Server > 網路 > Distributed Switch > 新增和管理主機】。
    • vSphere HTML Client：請依序點選【網路功能 > vSAN-Dswitch > 網路 > 動作 > 新增和管理主機】。


    在彈出的新增和管理主機視窗中，於選取工作頁面中請選擇「新增主機」項目，在選取主機頁面中按下「新增主機」鈕後將 2 台 vSAN 節點主機依序加入，在管理實體介面卡頁面中請將 vSAN 節點主中，配置用於 vSAN 儲存流量傳輸用途的網路卡加入，請點選相關網路卡後點選「指派上行」鈕，將選定的 vSAN 儲存流量傳輸用途網路卡，指派為 vSAN-Dswitch 的 Uplink。

    在管理 VMkernel 網路介面卡頁面中，請先點選「位於此交換器上」然後按下「新增介面卡」鈕，選擇採用「vSAN-DPortGroup」連接群組，並且勾選「vSAN」項目以便啟用 vSAN 儲存流量，最後指派 vSAN 用途的 VMkernel IP 位址即可（如圖 9 所示）。
    此操作步驟若採用新式 vSphere HTML Client管理工具時，僅能新增管理網路介面卡無法同時新增 VMkernel 網路介面卡。

    圖 9、指派 vSAN 儲存流量用途的網路卡並組態設定 VMkernel Port

    完成指派 vSAN 儲存流量用途的實體網路卡及 VMkernel Port 之後，請再次確認是否指派完成且正確無誤（如圖 10 所示），以避免稍後為叢集啟用 vSAN 特色功能時發生不可預期的錯誤。

    圖 10、再次確認 vSAN 儲存流量用途實體網路卡及 VMkernel Port 指派完成且正確無誤



    叢集啟用 vSAN 軟體定義儲存機制

    現在，請透過 vSphere Web Client 管理工具，為 vSphere 叢集啟用 vSAN 軟體定義儲存機制，請依序點選【首頁 > 主機和叢集 > vSAN-Cluster > 設定 > vSAN > 一般 > 設定】，在彈出的設定 vSAN 視窗中，由於我們尚未組態設定 vSAN Witness 見證機制，所以在容錯網域與延伸叢集的組態設定中請採用「不設定」選項，稍後我們便會組態設定 vSAN Witness 見證機制。
    新式 vSphere HTML Client管理工具，尚未支援為 vSphere 叢集啟用 vSAN 軟體定義儲存機制。
    接著，在網路驗證頁面中，由於剛才已經正確指派及組態設定 vSAN 儲存流量網路卡及 VMkernel Port，所以將會順利通過 vSAN 網路驗證機制。如圖 11 所示，在宣告磁碟頁面可以看到我們為 vSAN 節點主機所配置的 3 個 100 GB SSD 固態硬碟，請將 1 個 SSD 固態硬碟宣告為「快取層」（Cache Tier），另外 2 個 SSD 固態硬碟宣告為「容量層」（Capacity Tier）。

    圖 11、宣告 vSAN 節點主機儲存裝置為快取層及容量層

    最後，完成為 vSphere 叢集啟用 vSAN 軟體定義儲存機制，此時系統將會執行更新 vSAN 組態、在 vSAN 叢集中建立磁碟群組、將磁碟新增至 vSAN……等動作。當順利為 vSphere 叢集啟用 vSAN 軟體定義儲存機制後，可以看到在網路模式的部分採用新式「單點傳播」處理 vSAN 儲存流量（如圖 12 所示），而非舊有的「多點傳播」。

    圖 12、順利為 vSphere 叢集啟用 vSAN 軟體定義儲存機制



    佈署 Witness 見證機制

    在 2 Node 的 vSAN 叢集架構中，必須要佈署 Witness 見證機制才能確保可用性。管理人員請在 vSphere Web Client 管理工具中，依序點選【首頁 > 主機和叢集 > vSAN-Cluster > 設定 > 容錯網域與延伸叢集】選項後，可以看到目前 vSAN 叢集容許「0 個主機故障」（如圖 13 所示），表示 vSAN 叢集尚未具備高可用性。
    倘若，vSAN 叢集當中具備「3 台」vSAN 節點主機時，那麼即便沒有佈署 Witness 見證機制，也能容許「1 台」主機發生故障損壞仍能正常運作，簡單來說便是已經具備高可用性。

    圖 13、目前 vSAN 叢集尚未具備高可用性

    現在，請為 vSAN 叢集佈署 Witness 見證機制，值得注意的是運作見證虛擬設備的 ESXi 主機必須具備 2 項條件，第 1 項條件是該台 ESXi 主機「不能」加入至 vSAN 叢集當中，第 2 項條件則是該台 ESXi 主機「必須」要能接觸得到 vSAN 儲存網路。

    完成見證虛擬設備 ESXi 主機的基本組態設定後，請依序點選【動作 > 部署 OVF 範本】進行佈署見證虛擬設備的動作。在本文實作環境中，採用的見證虛擬設備運作規模為「Tiny」，所以 ESXi 主機必須提供 2 vCPU 及 8GB vRAM 虛擬硬碟資源給它，此外見證虛擬設備管理用途的 IP 位址為「10.10.75.33」，接觸 vSAN 儲存網路的 IP 位址則是「192.168.75.33」。
    採用新式 vSphere HTML Client管理工具，在佈署見證虛擬設備的過程中並不會組態設定管理者密碼，所以必須佈署完成後組態設定管理者密碼才能順利啟動見證虛擬設備。

    佈署及組態設定見證虛擬設備後，請將見證虛擬設備加入 vSphere Datacenter 當中，順利加入後可以發現見證虛擬設備與一般 ESXi 主機的圖示顏色不同（如圖 14 所示）。

    圖 14、將見證虛擬設備加入 vSphere Datacenter 當中

    現在，請依序點選【首頁 > 主機和叢集 > vSAN-Cluster > 設定 > vSAN > 容錯網域與延伸叢集 > 設定】，在彈出的設定 vSAN 延伸叢集視窗中，組態設定慣用容錯網域為「10.10.75.31」vSAN 節點主機，而次要容錯網域為「10.10.75.32」vSAN 節點主機。

    接著，在選取見證主機頁面中，選擇我們完成佈署及組態設定的 vSAN 見證虛擬設備「10.10.75.33」，在為見證主機宣告磁碟頁面中採用系統預設值即可。順利為 vSAN 叢集啟用 Witness 見證機制後，可以看到容錯網域由先前容許「0 個主機故障」變更為「1 個容錯網域故障」（如圖 15 所示）。

    圖 15、為 2 Node vSAN 叢集架構啟用 Witness 見證機制



    高可用性測試

    順利建構 2 Node vSAN 節點主機搭配 Witness 見證機制後，現在 vSAN 叢集已經具備高可用性機制，請為 vSAN 叢集「啟用 vSphere HA」高可用性機制，以便其中 1 台 vSAN 節點主機發生故障損壞事件時，其上運作的 VM 虛擬主機能夠自動在另 1 台存活的 vSAN 節點主機上重新啟動。

    現在，運作在 vSAN 叢集當中的 VM 虛擬主機，預設情況下儲存物件和元件將會分別存放在 2 台 vSAN 節點主機中（如圖 16 所示）。

    圖 16、VM 虛擬主機儲存物件將會分別存放在 2 台 vSAN 節點主機中

    即便其中 1 台 vSAN 節點主機，因為安全性更新需要重新啟動，或是伺服器硬體元件發生故障損壞事件（如圖 17 所示），在 vSAN 叢集當中的 VM 虛擬主機仍然能夠正常運作提供服務達到高可用性的目的。

    圖 17、其中 1 台 vSAN 節點主機故障損壞 VM 虛擬主機仍能正常運作





    結語

    透過本文的說明及實作相信讀者已經了解，在最新 vSAN 6.6.1 版本當中新增哪些特色功能，同時本文也進行 2 Node vSAN 叢集搭配 Witness 見證機制的運作架構實戰演練，期望能夠幫助企業及組織建立更靈活、高擴充性、高可用性的 SDS 軟體定義儲存運作環境。
    ↧

    Azure Pass Subscription 使用注意事項

    January 18, 2018, 7:04 pm
    $
    0
    0

    前言

    昨天參加 Kubernetes in Azure活動，通常在體驗 Azure 公有雲的活動中會拿到 Azure Pass 以便快速體驗 Azure 公有雲相關功能特色。但有些地方需要注意，否則在實作的過程中很容易遇到問題，以下就記錄一下昨天遇到然後當場解掉的問題吧 💪





    申請 Microsoft 帳號

    建議為 Azure Pass申請新的 Microsoft 帳號，後續測試完畢或錢燒完或時間到 (一般來說 Azure Pass 會提供 USD $100及 1 個月試用期)，也可以直接把這個 Microsoft 帳號刪除。

    請連結至 https://signup.live.com/進行申請 Microsoft 帳號的動作：

    圖、申請 Microsoft 帳號





    透過 Azure Pass 啟用 Azure 訂閱帳戶

    簡單來說，在你申請好 Microsoft 帳號之後，主辦單位會給你「Azure Pass Promo Code」此時，便可以連結至  Microsoft Azure Pass網站進行啟用及開通 Azure 訂閱帳戶的動作。值得注意的是，應該了解及避免下列狀況：

    • 使用過 Azure Free Free Account的 Microsoft 帳號無法使用 Azure Pass。
    • 曾經使用過 Azure Pass的 Microsoft 帳號無法再次開通。
    • 避免使用 MSDN 訂閱帳戶來開通 Azure Pass。
    • Azure Pass 會有建立 5 台 VM 虛擬主機的限制。


    有關透過 Azure Pass 啟用 Azure 訂閱帳戶的動作，官方已經有詳細說明就不重新造輪子了：
    圖、透過 Azure Pass 啟用 Azure 訂閱帳戶
    圖片來源： Microsoft Azure Pass - Creating a Microsoft Azure Pass Subscription





    Azure CLI 指令 az acr login / create / repository 有問題？

    在嘗試執行 Azure CLI 相關指令時 (例如，az acr login / create / repository) 都會有一堆錯誤訊息，其中關鍵錯誤訊息是「'bool' object has no attribute 'rstrip'」，根據錯誤訊息找到這篇討論 az acr login error: AttributeError: 'bool' object has no attribute 'rstrip'· Issue #5303 · Azure/azure-cli。

    簡單來說，剛好採用的是有問題的 Azure CLI 2.0.24版本而導致的，只要下載最新的 Azure CLI 2.0.25版本即可解決。

    圖、最新 Azure CLI 2.0.25 版本可順利執行 az acr repository 指令





    Azure Pass 訂閱帳戶無法使用所有的 Azure 資料中心？

    在昨天的實作過程中，當透過 Azure CLI 指令嘗試建立 Kubernetes 叢集時，卻出現下列錯誤訊息，表示無法建立 Kubernetes Agent VM？
    C:\> az acs create --orchestrator-type kubernetes --resource-group RG-US-West --name k8scluster --generate-ssh-keys --agent-count 1
    Deployment failed. Correlation ID: e415a0f4-f9de-4882-8ed0-d60e46cf87a7. {
      "error": {
        "code": "BadRequest",
        "message": "The VM Size of Master, Agent is not allowed in your subscription in location 'westus'. Master VM Size 'Standard_D2_v2' is available in locations: eastus, westeurope, southeastasia. Agent VM Size 'Standard_D2_v2' is available in locations: eastus, westeurope, southeastasia."
      }
    }

    從上述訊息很容易得知，你指定的 Azure 資料中心並不支援建立 Kubernetes Agent VM，請你改為指定採用 eastus, westeurope, southeastasia這 3 個資料中心即可。

    圖、Azure Pass 訂閱帳戶此例僅適合建立指定的 3 個 Azure 資料中心





    Azure Pass 訂閱帳戶無法建立 Kubernetes 叢集？

    再調整為允許建立的 Azure 資料中心後，再次透過 Azure CLI 指令嘗試建立 Kubernetes 叢集時，又是出現一大堆的錯誤訊息 (但忘了抓畫面 😝)，根據錯誤訊息找到這篇討論 az acs create fails on provisioning microsoft.network · Issue #1309 · Azure/azure-cli。

    簡單來說，因為使用的 Azure Pass 訂閱帳戶「沒有」透過 ARM Portal 建立過 VM 或其它資源，導致相關資源 (Network, Storage, Compute) 都還沒有註冊所以發生錯誤。你可以嘗試透過 ARM Portal 建立 1 台 VM 虛擬主機後再刪除，或者是執行下列 Azure CLI 指令註冊相關資源後，便應該可以順利建立 Kubernetes 叢集：
    C:\>az provider register --namespace Microsoft.Network
    Registering is still on-going. You can monitor using 'az provider show -n Microsoft.Network'

    C:\>az provider register --namespace Microsoft.Compute
    Registering is still on-going. You can monitor using 'az provider show -n Microsoft.Compute'

    C:\>az provider register --namespace Microsoft.Storage
    Registering is still on-going. You can monitor using 'az provider show -n Microsoft.Storage'

    圖、註冊相關資源後，即可順利建立 Kubernetes 叢集

    圖、註冊相關資源後，即可順利建立 Kubernetes 叢集





    關閉測試用途 Microsoft 帳戶

    當測試完畢或 Azure Pass 額度用完 (錢燒完) 或試用時間到期 (一般來說 Azure Pass 會提供 USD $100 及 1 個月試用期)，便可以直接把這個測試用途的 Microsoft 帳號刪除。

    圖、關閉測試用途 Microsoft 帳戶





    其它參考資源

    ↧

    CentOS 7.4 基礎設定 (15) - 範本 CentOS 重新產生 Product_UUID

    January 24, 2018, 7:48 pm
    $
    0
    0

    前言

    最近工作關係開始玩 CentOS 了，本次實作環境中採用的是 CentOS 7.4 (1709) Kernel 3.10.0-693.el7.x86_64)映像檔，也就是新版 CentOS 7.4 最小化安裝版本 (Minimal Install)，那麼開始來玩玩吧。💪





    實作環境





    匯入 CentOS 範本虛擬主機的問題？

    在上一篇文章中，我們已經完成 CentOS 範本的「匯出」(Export) 作業，所以當需要產生 CentOS VM 時，我們只要透過 Hyper-V Manager 進行「匯入」(Import)作業即可。

    但是，最近要使用這些匯入的 CentOS VM 建立 K8S (Kubernetes) 環境時，卻發生匯入的 CentOS VM 在 product_uuid的部分是相同的💀，但是根據 Installing kubeadm | Kubernetes文件中提到，不管是 Kubernetes Master Node 或 Worker Node，每台 Node 都必須確認 MAC Address及 Product_UUID的值必須唯一。

    • MAC Address：可以透過指令 ip link或 ifconfig -a 確認。
    • Product_UUID：可以透過指令 cat /sys/class/dmi/id/product_uuid或 dmidecode -s system-uuid確認。





    匯入的 CentOS 重新產生 Product_UUID 的方法？

    因為，本文採用的是 CentOS 所以也可以直接參考 Red Hat 官方文件，但是因為我沒有 Red Hat subscriptions 所以無法看到下列文章的完整內容：



    同時，在網路上我好像沒有找到簡單的方法，可以讓已經匯入運作的 CentOS 重新產生 Product_UUID的方式 (還請路過的高手指點迷津 😎)





    怎麼為 CentOS 範本產生新的 Product_UUID？

    因為，並沒有找到簡單的方法，可以讓已經匯入運作的 CentOS 重新產生 Product_UUID 的方式。同時，剛好找到這篇 Hyper-V : Unique Identifier or MachineGUID討論串，可以透過「新增」VM 虛擬主機的方式，然後掛載 CentOS Template .vhdx 的方式來達成重新產生新的 Product_UUID 的目的。

    但是，又遭遇到另 1 個問題 (怎麼就你問題最多 💢)，因為並非採用「匯出 / 匯入」方式，而是以「新增」VM 虛擬主機的方式，然後掛載 CentOS Template .vhdx 的方式，所以便發生這個新增的 CentOS VM 因為沒有 UEFI 檔案而無法啟動。

    圖、CentOS VM 因為沒有 UEFI 檔案而無法順利啟動

    圖、CentOS VM 因為沒有 UEFI 檔案而無法順利啟動





    新增 CentOS 範本虛擬主機重新產生 UEFI 檔案

    簡單來說，以本文的實作環境必須要為 CentOS VM 產生「shimx64.efi」的 UEFI 檔案，便能夠順利讓 CentOS VM 啟動。重新產生 UEFI 檔案的相關資訊，請參考下列網址：


    圖、為 CentOS VM 產生 UEFI 檔案便能順利啟動

    首先，請將 CentOS VM 關機，然後放入 CentOS 7 安裝光碟後啟動，在 CentOS 7 安裝光碟開機畫面中選擇「Troubleshooting」項目。

    圖、選擇 Troubleshooting 項目

    接著，選擇「Rescue a CentOS system」項目。

    圖、選擇 Rescue a CentOS system 項目

    選擇「3) Skip to shell」項目。

    圖、選擇 3) Skip to shell 項目

    進入 Shell 模式後，鍵入指令「efibootmgr --create --label CentOS --disk /dev/sda1 --loader "\EFI\centos\shimx64.efi"」重新產生 UEFI 檔案。

    圖、重新產生 UEFI 檔案

    此時，開啟 CentOS VM 虛擬主機的設定視窗，便可以看到自動產生「shimx64.efi」的 UEFI 檔案，請調整至第 1 個開機順位便能夠順利讓 CentOS VM 啟動。

    圖、為 CentOS VM 產生 UEFI 檔案便能順利啟動

    開機完成後，可以透過「hostnamectl」指令查看 Machine ID / Boot ID、「ip a」指令查看 MAC Address、「cat /sys/class/dmi/id/product_uuid」指令查看 Product_UUID，可以發現都是不同的。💪

    圖、不同的 CentOS VM 不同的 Product_UUID





    補充、PowerShell 新增 CentOS 範本虛擬主機

    由於是「新增」CentOS 範本虛擬主機，所以必須要幫新增的 VM 虛擬主機重新組態設定，例如，vCPU 數量、vRAM、Smart Paging File Location......等。所以，就寫個簡單的 PowerShell 來處理這段了，有興趣的朋友可以參考看看 😜。







    CentOS 7.4 基礎設定系列文章：

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