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

Azure Stack HCI 20H2 升級至 21H2 Preview

$
0
0


前言

最新 Azure Stack HCI 21H2 技術預覽版本,已經在 2021 年 6 月 1 日正式發佈。在開始玩最新 Azure Stack HCI 21H2 技術預覽版本之前,先把手邊的 Azure Stack HCI 20H2 進行版本升級吧。本文將說明,如何為 Azure Stack HCI 啟用 CAU (Cluster Aware Updating) 機制,即可輕鬆升級 Azure Stack HCI 版本




下列是最新 Azure Stack HCI 21H2 技術預覽版本,支援的新功能項目:



Azure Stack HCI 20H2 升級至 21H2 Preview

在開始玩最新 Azure Stack HCI 21H2 技術預覽版本之前,先把手邊的 Azure Stack HCI 20H2 進行版本升級吧。整個版本升級的流程很簡單,只要為 Azure Stack HCI 啟用 CAU (Cluster Aware Updating)機制,即可輕鬆升級 Azure Stack HCI 版本

首先,在 DC 網域控制站中的 Computers容器,記得給予 Azure Stack HCI Node 和 Cluster 電腦帳戶寫入的權限 (由於是 Lab 環境,就簡單點設定為 Full Control)。


權限設定完畢後,回到 WAC 操作介面,點選 Azure Stack HCI 內的 Updates 選項,即可看到「Add Cluster-Aware-Updating role」的按鈕,按下後待幾分鐘系統便出現成功啟用通知。



此時,回到 DC 網域控制站操作介面,即可看到系統順利新增 CAU 角色使用的電腦帳戶。


在升級至最新 Azure Stack HCI 21H2 技術預覽版本之前,先為 Azure Stack HCI 叢集中所有的節點主機進行安全性更新,並且務必安裝 KB 5003237 更新才行。



更新完成並重新啟動後,可以透過 PowerShell 至 Azure Stack HCI 叢集中的節點主機進行確認,是否已經要安裝 KB 5003237 更新


確認後,即可回到 WAC 操作介面,依序點選 Azure Stack HCI  內「Settings > Join the preview channel > Get started > 勾選 Got it > 按下 Join the preview channel」。



現在,可以看到 Azure Stack HCI 叢集中的節點主機,在「Ready to install preview builds」欄位的狀態為「Ready」。


點選 Azure Stack HCI 內的 Updates 選項,這次便會看到「Feature update to Microsoft server operating system, version 21H2」更新項目,也就是準備將 Azure Stack HCI 叢集中節點主機的系統升級為 Azure Stack HCI 21H2 版本,然後依照精靈指示安裝更新即可。





最後,只要使用 PowerShell 更新 Azure Stack HCI 叢集功能等級和 Storage Pool 版本,即可使用最新 Azure Stack HCI 21H2 技術預覽新功能。請執行「Update-ClusterFunctionalLevel」和「Update-StoragePool」指令即可。


更新完成後,透過 PowerShell 檢查時,可以看到 Azure Stack HCI 叢集功能等級升級為「11」版本,在 VM 虛擬主機支援版本方面支援最新的「Windows Server 2022」,在 Storage Pool 版本升級為「Windows Server 2022」。下列為每一世代 Windows Server 對應的叢集功能等級版本:
  • Windows Server 202211
  • Windows Server 201910.x
  • Windows Server 20169
  • Windows Server 2012 R28
  • Windows Server 20127
  • Windows Server 2008 R26
  • Windows Server 20085
  • Windows Server 2003 R24
  • Windows Server 20033
  • Windows Server 20002
  • Windows Server NT 41

現在,我們可以為 Azure Stack HCI 21H2 叢集,啟用 Storage Pool 最新支援的 Thin Provisioning 機制


有關 Azure Stack HCI 21H2 叢集,啟用 Storage Pool 最新支援的 Thin Provisioning 機制詳細資訊,請參考官方文件 Azure Stack HCI 中的儲存體精簡布建 - Azure Stack HCI | Microsoft Docs


PowerShell - 檢查使用者帳號是否存在於 DC 網域控制站內

$
0
0


前言

簡單來說,最近有需求要先檢查使用者帳號是否存在於 DC 網域控制站內,所以就產出這篇筆記了。 😁


Option 1 執行結果

執行後,直接把結果顯示在 PowerShell 視窗中,檢查到使用者帳號存在綠色字體顯示,檢查到使用者帳號不存在時就紅色字體顯示。




Option 2 執行結果

執行後,直接把結果寫入至筆記本檔案內,有檢查到使用者帳號就綠色字體顯示。






PowerShell Code

下列是這次實作的 PowerShell。


PowerShell - 監控 RDS (Remote Desktop Service) 系統資源和 Session 數量

$
0
0


前言

簡單來說,最近必須要在地端資料中心內,透過 Windows Server 2019 建立 Microsoft RDS (Remote Desktop Service) 運作環境的需求。從下列的 RDS 架構圖來看,眼尖的朋友應該已經發現,這看起來並不像地端運作的 RDS 架構圖? 事實上,從 Windows Server 2016 版本之後,RDS 架構已經在 Azure 公有雲上快速建立且方便維護,因此可以從文件中看出是以說明 Azure 公有雲環境為主。


那麼,在地端資料中心內,將 RDS 架構建立完成後,需要一個簡單的監控機制,例如,需要觀看 50 台 RDSH (Remote Desktop Session Host) 的系統資源使用量,以及 RDCB (Remote Desktop Connection Broker)的使用者 Session 連線數量。

在短時間沒有辦法快速整合其它監控工具的情況下,只能自己花點時間透過 PowerShell 去抓取了,所以本文筆記就出現了。😎 

下列是本文實作相關檔案的簡要說明:
  • Check_RDS_Resource_to_HTML.ps1: 本文實作的主體,會載入 RDSResources.psm1 成為 PowerShell Script Module,以及處理抓取 RDCB 內所有的使用者 Session 連線數量,和最後把監控數據轉換成 HTML 檔案。
  • RDSResources.psm1: 抓取指定的 Windows Server 的 CPU / Memory / Disk 系統資源使用量,也就是抓取本文中 RDCB, RDWeb, RDSH 角色主機的系統資源工作負載情況。值得注意的是 Module 檔案的附檔名,必須要是「.psm1」否則屆時會無法順利載入。
  • style.css: 最後把監控數據轉換成 HTML 檔案時,搭配 CSS 美化一下。



執行結果

下列便是執行 Check_RDS_Resource_to_HTML.ps1之後得到的 HTML 檔案內容。在目前的 RDS 實作環境架構中,主要有 3 個 RDS Collections,首先抓取每個  RDS Collections 的使用者 Session 連線數量並加總,最後則是抓取擔任 RDCB、RDWeb、和 50 台 RDSH 角色主機,Windows Server 2019 的系統資源工作負載情況。




Check_RDS_Resource_to_HTML.ps1




RDSResources.psm1




style.css




PowerCLI - 快速建立大量的 VM 虛擬主機

$
0
0


前言

最近有個需求,希望能夠快速建立大量的 VM 虛擬主機 (500 台) 在 vSAN Clsuter 或 NFS Cluster 內,但是 VM 虛擬主機名稱的部份並非呆板的只有數字遞增,例如,VM01、VM02、VM03…等,而是必須依照使用者帳號的清單內容,並在結尾加上「-VM」來建立,例如,weithenn-vm、chris-vm…等,所以本文筆記就誕生了。😁

什麼是 PowerCLI? 簡單來說,它是以 PowerShell 為底的 PowerCLI 模組,安裝後可以針對 VMware 虛擬化環境進行各種多項管理任務,目前已經多達 700 Cmdlet



Create_vm_from_list.ps1

整個 PowerCLI 的執行流程中。首先,確認目前使用的 PowerShell 版本是否支援安裝 PowerCLI,接著確認目前 PowerShell 支援線上安裝的 PowerCLI 模組版本。


本文,採用線上下載模組並安裝的方式,安裝最新版本的 PowerCLI 12.3,安裝完成後透過「Get-Module」指令,確認是否已經安裝完成。有關線上或離線安裝 PowerCLI 的詳細資訊,請參考官方說明文件:


預設情況下,必須要先處理和安裝 PowerCLI 主機和 vCenter Server 之間連線憑證的部份,倘若憑證是預設自簽且也沒時間處理的話,可以在連線之前先把憑證驗證的部份設定為「Ignore」即可 (當然,請不要忽略安全性的問題)。有關連線 vCenter Server 的詳細資訊,請參考官方說明文件:

最後,建立完成後,可以確認新建立在 vSAN Cluster 的 VM 虛擬主機,是否採用預設的「vSAN Default Storage Policy」,以及是否成功把預設的「e1000e」網路卡調整為官方最佳化的「vmxnet3」。有關建立新 VM 虛擬主機的詳細資訊,請參考官方說明文件:

下列是本文的完整 PowerCLI 內容:



Windows Server 2022 Preview

$
0
0


前言

Windows Server 2022 Preview,已經正式在 2021 年 6 月 1 日發佈至 Evaluation Center 了。有興趣嘗鮮的朋友,可以至 Evaluation Center - Windows Server 2022 Preview下載。




安裝 Windows Server 2022 Preview

在本文實作環境,於 Windows Server 2019 Hyper-V 虛擬化環境中,建立 VM 虛擬主機並安裝 Windows Server 2022 Preview。安裝完成後,可以看到版本為 Windows Server 2022 v21H2 (OS Build 20348.1)





內建 Microsoft Edge 瀏覽器

在 Windows Server 2022 Preview 中,已經內建最新版本的 Microsoft Edge 瀏覽器,而不用像 Windows Server 2019 或舊版本,需要打開 IE 下載 Microsoft Edge 瀏覽器進行安裝,或是複製離線安裝檔案。




VM 虛擬主機整合服務是否運作正常?

對於 Hyper-V 稍有了解的朋友,應該會想要確認,在 Windows Server 2019 Hyper-V 環境中,運作 Windows Server 2022 虛擬主機時,「整合服務」(Integration Services) 是否運作正常?

首先,在 Windows Server 2019 Hyper-V 主機上,可以看到目前支援最新的 VM 虛擬主機版本為「9.0」,並且只支援到 Windows Server 2019。同時,目前安裝的 Windows Server 2022 虛擬主機,也是採用 VM 虛擬主機版本「9.0」,目前看來整合服務皆可以正常運作。


倘若,有採用 Azure Stack HCI 的朋友,可以參考本站文章 Azure Stack HCI 20H2 升級至 21H2 Preview,讓 Azure Stack HCI 啟用支援最新的 VM 虛擬主機版本「10.0」,確保完整支援 Windows Server 2022。




安裝 Windows Admin Center v2103

安裝最新版本的 Windows Admin Center v2103,可以正確識別 Windows Server 2022 版本並收集相關效能資訊。


有興趣了解 Windows Admin Center v2103 版本新功能的朋友,可以參考下列影片:




Windows Server 2022 新功能

下列是幾個 Windows Server 2022 新功能,後續有空再開始研究研究:

有興趣進一步了解 Windows Server 2022 新功能的朋友,可以參考下列影片:
  • Storage Migration Service Update
  • NetApp Migration
  • DFSN Migration
  • Azure Cloud Tiering Integration
  • SMB compression with 20H2
  • SMB over QUIC


Ansible - 設定 Cisco UCS CIMC 時區

$
0
0


前言

最近有個需求,需要一次安裝和設定 32 台 Cisco UCS C240 M5SX 伺服器。由於,在安裝 Hypervisor 之前,我都會為伺服器調整 BIOS 組態設定,確保伺服器的 BIOS 組態設定值,可以採用最符合後續要運作的虛擬化工作負載。詳細資訊請參考:

但是,手動一台一台去登入 Cisco UCS C240 M5SX 伺服器 CIMC (IPMI) 介面,然後又要一台一台去調整相關 BIOS 組態設定值太累人了。因此,本文筆記便出現了。

在本文中,將會透過 Ansible Playbook 搭配 Ansible AWX,針對 Cisco UCS C240 M5SX 伺服器的 CIMC 組態設定值,將 Timezone從預設的 UTC設定為「Asia/Taipei」。



實作方式和結果

先前找過用 UCSM Ansible Module不符合需求,而 imc_rest – Manage Cisco IMC hardware through its REST API模組也不符合需求。最後,選擇採用 Cisco CIMC CLI的方式去互動,對我來說最方便直覺好維護,再搭配用 SSH HereDoc的方式即可達成我要的需求。

順利套用下列 Playbook 之後,便能一次將 32 台 Cisco UCS C240 M5SX 伺服器的 CIMC 時區設定為「Asia/Taipei」。




configure_timezone.yaml

有關組態設定 CIMC 時區的 CLI 指令,請參考下列 Cisco 官方文件



Ansible - 設定 Cisco UCS CIMC DNS 和停用 IPv6

$
0
0


前言

最近有個需求,需要一次安裝和設定 32 台 Cisco UCS C240 M5SX 伺服器。由於,在安裝 Hypervisor 之前,我都會為伺服器調整 BIOS 組態設定,確保伺服器的 BIOS 組態設定值,可以採用最符合後續要運作的虛擬化工作負載。詳細資訊請參考:

但是,手動一台一台去登入 Cisco UCS C240 M5SX 伺服器 CIMC (IPMI) 介面,然後又要一台一台去調整相關 BIOS 組態設定值太累人了。因此,本文筆記便出現了。在本文中,將會透過 Ansible Playbook 搭配 Ansible AWX,針對 Cisco UCS C240 M5SX 伺服器的 CIMC 組態設定值中,設定管理用途的網路卡「Alternate DNS Server」以及「Disable IPv6」。

為何要如此麻煩,初始化設定時處理不就好了? 原因在於,當 Cisco UCS 伺服器開機按下「F8 - CIMC Setup」時,可以看到只能設定第一筆 DNS Server,也就是只有「Preferred DNS Server」能設定,找不到可以設定第二筆 DNS Server (本文說的 Alternate DNS Server)。此外,雖然沒有勾選 IPv6 項目,但是後續登入 CIMC 圖形介面時,會發現預設還是有勾選「Enable IPv6」 的。





實作方式和結果

先前找過用 UCSM Ansible Module 不符合需求,而 imc_rest – Manage Cisco IMC hardware through its REST API 模組也不符合需求。最後,選擇採用 Cisco CIMC CLI 的方式去互動,對我來說最方便直覺好維護,再搭配用 SSH HereDoc 的方式即可達成我要的需求。

順利套用下列 Playbook 之後,便能一次為 32 台 Cisco UCS C240 M5SX 伺服器,設定管理用途的網路卡「Alternate DNS Server」和「Disable IPv6」。




configure_alternate_dns.yaml

有關組態設定 Cisco CIMC 管理用途網卡第二筆 DNS Server的 CLI 指令,請參考下列 Cisco 官方文件:




disable_ipv6.yaml

有關組態設定 Cisco CIMC 管理用途網卡停用 IPv6的 CLI 指令,請參考下列 Cisco 官方文件:



Ansible - 設定 Cisco UCS CIMC Fan Policy

$
0
0


前言

最近有個需求,需要一次安裝和設定 32 台 Cisco UCS C240 M5SX 伺服器。由於,在安裝 Hypervisor 之前,我都會為伺服器調整 BIOS 組態設定,確保伺服器的 BIOS 組態設定值,可以採用最符合後續要運作的虛擬化工作負載。詳細資訊請參考:

但是,手動一台一台去登入 Cisco UCS C240 M5SX 伺服器 CIMC (IPMI) 介面,然後又要一台一台去調整相關 BIOS 組態設定值太累人了。因此,本文筆記便出現了。在本文中,將會透過 Ansible Playbook 搭配 Ansible AWX,針對 Cisco UCS C240 M5SX 伺服器的 CIMC 組態設定值中,Fan Control Policy 的部份由預設的「Balanced」調整為「High Power」。主要是因為,發現預設的 Balanced 會讓 Cisco UCS 伺服器的溫度偏高所以調整為 High Power,你可以參考下列 Cisco UCS C240 M5SX 伺服器,支援的 Fan Control Policy 設定值和說明,選擇適合你的參數:

  • Low Power: 此設定適合於未安裝任何 PCIe 卡的 UCS 伺服器。
  • Balanced: 預設值,適合用於大部份的 UCS 伺服器,但可能不適合安裝 PCIe 卡的 UCS 伺服器。
  • High Power: 套用此設定後,風扇速度將會保持在 60% - 85%的中高轉速,適合用於有安裝 PCIe 卡的 UCS 伺服器。
  • Maximum Power: 套用此設定後,風扇速度將會保持在 70% - 100%的極高轉速,適合用於有安裝多張 PCIe 卡導致容易過熱的 UCS 伺服器。
  • Acoustic: 此設定用於組態設定風扇速度的噪音層級,但可能會因為轉速過低導致 UCS 伺服器過熱或影響效能。



實作方式和結果

先前找過用 UCSM Ansible Module 不符合需求,而 imc_rest – Manage Cisco IMC hardware through its REST API 模組也不符合需求。最後,選擇採用 Cisco CIMC CLI 的方式去互動,對我來說最方便直覺好維護,再搭配用 SSH HereDoc 的方式即可達成我要的需求。

順利套用下列 Playbook 之後,便能一次為 32 台 Cisco UCS C240 M5SX 伺服器,將 Fan Control Policy 的部份由預設的「Balanced」調整為「High Power」。




configure_fan_policy.yaml

有關組態設定 Fan Control Policy 由預設「Balanced」調整為「High Power」的 CLI 指令,請參考下列 Cisco 官方文件:





Ansible - 設定 Cisco UCS CIMC Mail Alert

$
0
0


前言

最近有個需求,需要一次安裝和設定 32 台 Cisco UCS C240 M5SX 伺服器。由於,在安裝 Hypervisor 之前,我都會為伺服器調整 BIOS 組態設定,確保伺服器的 BIOS 組態設定值,可以採用最符合後續要運作的虛擬化工作負載。詳細資訊請參考:

但是,手動一台一台去登入 Cisco UCS C240 M5SX 伺服器 CIMC (IPMI) 介面,然後又要一台一台去調整相關 BIOS 組態設定值太累人了。因此,本文筆記便出現了。在本文中,將會透過 Ansible Playbook 搭配 Ansible AWX,針對 Cisco UCS C240 M5SX 伺服器的 CIMC 組態設定值中,Mail Alert 的部份設定下列項目:
  • 勾選 SMTP Enabled
  • 設定 SMTP Server Address 為 relay.weithenn.org
  • 設定 SMTP From Address 為 vSAN-Node01@weithenn.org
  • 新增 SMTP Recipients 中Mail ld 為 VM_ADMINS@weithenn.org 並觸發 Send Test Mail



實作方式和結果

先前找過用 UCSM Ansible Module 不符合需求,而 imc_rest – Manage Cisco IMC hardware through its REST API 模組也不符合需求。最後,選擇採用 Cisco CIMC CLI 的方式去互動,對我來說最方便直覺好維護,再搭配用 SSH HereDoc 的方式即可達成我要的需求。

順利套用下列 Playbook 之後,便能一次為 32 台 Cisco UCS C240 M5SX 伺服器,將 Mail Alert 的部份進行相關設定,並且觸發 Send Test Mail 確認是否能收到告警信件。




configure_mail_alert.yaml

有關組態設定 Mail Alert 並觸發 Send Test Mail 機制的詳細 CLI 指令,請參考下列 Cisco 官方文件:





Ansible - 設定 Cisco UCS CIMC 40Gb vNIC 參數

$
0
0


前言

最近有個需求,需要一次安裝和設定 32 台 Cisco UCS C240 M5SX 伺服器。由於,在安裝 Hypervisor 之前,我都會為伺服器調整 BIOS 組態設定,確保伺服器的 BIOS 組態設定值,可以採用最符合後續要運作的虛擬化工作負載。詳細資訊請參考:

但是,手動一台一台去登入 Cisco UCS C240 M5SX 伺服器 CIMC (IPMI) 介面,然後又要一台一台去調整相關 BIOS 組態設定值太累人了。因此,本文筆記便出現了。在本文中,將會透過 Ansible Playbook 搭配 Ansible AWX,針對 Cisco UCS C240 M5SX 伺服器的 CIMC 組態設定值中,40 Gb 網卡內容的相關參數部份進行下列調整:
  • Ethernet Interrupt > Interrupt Count: 32
  • Ethernet Receive Queue > Ring Size: 4096
  • Ethernet Transmit Queue > Ring Size: 4096
  • Completion Queue > Count: 16



實作方式和結果

先前找過用 UCSM Ansible Module 不符合需求,而 imc_rest – Manage Cisco IMC hardware through its REST API 模組也不符合需求。最後,選擇採用 Cisco CIMC CLI 的方式去互動,對我來說最方便直覺好維護,再搭配用 SSH HereDoc 的方式即可達成我要的需求。

順利套用下列 Playbook 之後,便能一次為 32 台 Cisco UCS C240 M5SX 伺服器,將二張 40 Gb 網卡 (eth0 / eth1) 的相關參數進行調整。




configure_vnics.yaml

有關組態設定二張 40 Gb 網卡 (eth0 / eth1) 相關參數進行調整的詳細 CLI 指令,請參考下列 Cisco 官方文件:





Ansible - 設定 Cisco UCS CIMC NTP 時間校時

$
0
0


前言

最近有個需求,需要一次安裝和設定 32 台 Cisco UCS C240 M5SX 伺服器。由於,在安裝 Hypervisor 之前,我都會為伺服器調整 BIOS 組態設定,確保伺服器的 BIOS 組態設定值,可以採用最符合後續要運作的虛擬化工作負載。詳細資訊請參考:

但是,手動一台一台去登入 Cisco UCS C240 M5SX 伺服器 CIMC (IPMI) 介面,然後又要一台一台去調整相關 BIOS 組態設定值太累人了。因此,本文筆記便出現了。在本文中,將會透過 Ansible Playbook 搭配 Ansible AWX,針對 Cisco UCS C240 M5SX 伺服器的 CIMC 組態設定值中,NTP 服務讓 Cisco UCS 伺服器能夠跟內部資料中心的 NTP Server 對時,下列是設定 NTP 服務相關項目:
  • 勾選 NTP Enabled項目 (啟動 NTP 服務)
  • NTP Server 1 指向至 10.10.75.15
  • NTP Server 2 指向至 10.10.75.16



實作方式和結果

先前找過用 UCSM Ansible Module 不符合需求,而 imc_rest – Manage Cisco IMC hardware through its REST API 模組也不符合需求。最後,選擇採用 Cisco CIMC CLI 的方式去互動,對我來說最方便直覺好維護,再搭配用 SSH HereDoc 的方式即可達成我要的需求。

順利套用下列 Playbook 之後,便能一次為 32 台 Cisco UCS C240 M5SX 伺服器,啟用 NTP 服務並指向至內部 NTP Server 開始進行對時的動作。

剛開始啟動 NTP 服務時,查看 Status 欄位可能會出現「unsynchronised」的訊息,只要設定沒問題並稍待幾分鐘之後,便會如下圖一樣順利和指定的 NTP Server 進行時間同步校時的情況。




configure_ntp.yaml

有關組態設定 NTP 服務和指向 NTP Server 的詳細 CLI 指令,請參考下列 Cisco 官方文件:

此外,這次在實作時遇到一個麻煩就是「啟用 NTP 服務」的部份,問題點的原因是這樣的,透過 CLI 直接操作時是沒有問題的,然而轉換成 Playbook 採用 SSH HereDoc 的方式時,在「set enabled yes」時,便無法將「y」順利送過去? 反覆測試過很多不同的方式後還是沒有成功。😷

最後,便轉念一想透過 Cisco IMC RESTful API支援的方式,先將 NTP 服務啟動,然後再透過熟悉的 SSH HereDoc 的方式指向 NTP Server 便解決此次的需求。😁 有關 Cisco IMC RESTful API 詳細資訊,請參考下列 Cisco 官方文件:



PowerShell - 參照清單刪除電腦帳戶

$
0
0


前言

最近有個需求,需要刪除 DC 網域控制站內,用於測試和研發用途的大量「電腦帳戶」(Computer Account),這些電腦帳戶沒有固定的命名規則 (大約 300 個電腦帳戶),所以只能依照清單載入的方式進行刪除。

請注意!這個 PowerShell 是依照我的環境需求撰寫出來的,拿回去使用的朋友請小心,否則刪除電腦帳戶的影響是非常大的,請小心服用。



執行結果

一開始將 DC 網域控制站內,具備刪除電腦帳戶的使用者帳號和密碼載入至 $Domain_Credentail變數內,以便後續迴圈執行刪除電腦帳戶時使用。在執行刪除電腦帳戶之前,先確認載入的電腦帳戶數量。

執行迴圈刪除電腦帳戶時,倘若 DC 網域控制站內有符合的電腦帳戶時,便會執行刪除作業並以「綠色」字體顯示,倘若電腦帳戶不存在時,則以「紅色」字體顯示 DC 網域控制站內沒有符合名稱的電腦帳戶。詳細用法,請參考下列 PowerShell 文件說明:



Remove_Computer_Account.ps1



PowerShell - 參照清單快速 Ping 主機

$
0
0


前言

最近有個需求,需要快速依照主機清單快速執行 Ping 的動作之外,希望了解 Ping 的結果是否成功或失敗,並且 RTT (Round Trip Time)時間為多少 ms,所以這篇筆記便出現了。



一塊小蛋糕?

原本以為這應該是一塊小蛋糕的需求,只要寫個迴圈加載入主機清單的 Array 即可達成吧? 首先,採用 Test-NetConnection搭配主機名稱,即可得到我想要的結果,包含 Ping 的結果是否成功或失敗,並且 RTT (Round Trip Time) 時間為多少 ms。


然而,因為預設顯示的欄位有些我並不需要,所以透過 Format-Table來選取想要呈現的欄位。但是,卻發現 PingReplyDetails (RTT)的欄位值無法顯示? 查詢後發現,該欄位是屬於 PingReply 類別的 PingReply.RoundtripTime 屬性,所以無法直接顯示。


那麼該如何單獨且正確的顯示? 簡單來說,抓取 PingReply.RoundtripTime 屬性數值並加上 ms 字串後顯示,但是目前的數值結果會是預設的「左邊」,屆時搭配 Format-Table 時會加上「align="right"」讓數值靠右呈現。


執行時,先檢查主機名稱是否存在,當主機名稱存在時以「綠色」字體顯示主機存在「host exists try to ping!」,並且透過 Test-NetConnection 搭配主機名稱執行 Ping 的動作,倘若主機名稱不存在時,則以「紅色」字體顯示「name resolution failed!」。




Ping_Hosts.ps1



PowerCLI - 批次升級 VMware Tools

$
0
0


前言

最近,在幫忙健檢 vSAN Cluster 環境時,發現有許多 VM 虛擬主機的 VMware Tools 版本已經過時未升級至新版。有關 VMware Tools 對於 VM 虛擬主機的重要性,應該無須多做解釋,有興趣了解更多的朋友,請參考 VMware KB 340 - Overview of VMware Tools

在本文中,我們將透過 PowerCLI 針對 vSAN Cluster 中運作的 VM 虛擬主機 (共 365 台),過濾出需要更新 VMware Tools 版本的 VM 虛擬主機 (共 105 台),然後批次進行 VMware Tools 版本更新作業。

什麼是 PowerCLI? 簡單來說,它是以 PowerShell 為底的 PowerCLI 模組,安裝後可以針對 VMware 虛擬化環境進行各種多項管理任務,目前已經多達 700 Cmdlet



手動檢查和升級 VMware Tools 版本

透過 vCenter Server 的管理畫面,可以很容易判斷單台 VM 虛擬主機的 VMware Tools 版本情況,可以看到這台 VM 虛擬主機的 VMware Tools 版本已經過時,並且系統提示可以升級至新版本。


管理人員可以直接點選右下方的「Upgrade VMware Tools」連結,此時系統會彈出 Upgrade VMware Tools 視窗,然後依據需求選擇「Interactive Upgrade」或「Automatic Upgrade」後,按下 UPGRADE 鈕。

選擇 Automatic Upgrade的朋友,要注意的是有可能在 VMware Tools 版本升級之後,VM 虛擬主機會「自動重新啟動」,所以若不想升級 VMware Tools 版本後立即重新啟動,請記得在 Advanced Options欄位加上「/s /v "/qn REBOOT=ReallySuppress"」參數,告訴系統雖然自動升級 VMware Tools 版本但不要馬上重新啟動 VM 虛擬主機。




透過 PowerCLI 統計 VMware Tools 版本

當 VM 虛擬主機數量不多時,採用上述手動的方式來檢查和處理即可,然而在本文實作環境中,單個 vSAN Cluster 內的 VM 虛擬主機數量就多達 365 台。所以,採用上述手動檢查和更新的方式便不切實際,透過下方自行撰寫的 PowerCLI 時,可以將指定的 vSAN Cluster 內,VM 虛擬主機的 VMware Tools 版本情況進行統計,列出「採用最新版本、需要更新版本、尚未安裝」這三種狀態的 VM 虛擬主機數量。


在下方撰寫的 PowerCLI 中,也提供把這些 VM 虛擬主機名稱、VMware Tools 版本、VMware Tools 狀態,收集匯整後匯出成為 vmtools.csv 檔案,方便快速得知哪些 VM 虛擬主機需要更新 VMware Tools 版本。


最後,同樣透過 PowerCLI,將指定的 vSAN Cluster 內,需要更新 VMware Tools 版本的 VM 虛擬主機過濾出來後,交給迴圈一次處理一台 VM 虛擬主機的 VMware Tools 版本更新作業,避免同時處理大量的 VM 虛擬主機的 VMware Tools 版本更新,造成 vCenter Server 和 vSAN Cluster 的工作負載過重。

值得注意的是,在本文的 PowerCLI 更新 VM 虛擬主機的 VMware Tools 版本更新後,會自動重新啟動 VM 虛擬主機。倘若,你不希望更新後重新啟動,請記得在 Update-Tools那行的結尾加上「-NoReboot」參數即可。



Upgrade_VMware_Tools.ps1



網管人 186 期 - vSphere 新版內建 XVM 線上移虛機功能終告完整

$
0
0


網管人雜誌

本文刊載於 網管人雜誌第 186 期 - 2021 年 7 月 1 日出刊,NetAdmin 網管人雜誌為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌,下列筆記為本站投稿網管人雜誌獲得刊登的文章,網管人雜誌於每月份 1 日出刊您可於各大書店中看到它,或透過城邦出版人讀者服務網進行訂閱。





本文目錄






前言

過去,在 vSphere 虛擬化基礎運作架構中,線上運作中的 VM 虛擬主機,能夠在沒有發生任何停機時間的情況下,任意的在 vSphere 虛擬化基礎架構中進行「線上遷移」(Live Migration),無論是線上遷移至不同的 ESXi 虛擬化平台主機,使用更高運算效能的 CPU 處理器和記憶體資源,或是線上遷移至不同的 Datastore 儲存資源,讓 VM 虛擬主機無縫提升整體儲存效能表現。

事實上,在這樣的高彈性運作架構下,有個很大的前提是必須在同一個 vCenter SSO Domain 管理架構中,舉例來說,小型架構中只有「單台」vCenter Server 管理主機時很容易理解,在中大型架構中有多台 vCenter Server 管理主機時,此刻除了整合「Enhanced Linked Mode(ELM)」或「Hybrid Linked Mode(HLM)」運作模式之外,重點是所有 vCenter Server 管理主機,必須加入同一個「vCenter SSO(Single Sign-On)」環境中,無論是在本地端或者是不同的站台甚至是雲端。如此一來,整個 vSphere 虛擬化基礎架構,便能視為一個大的邏輯管理架構,才能彈性化的將線上運作中的工作負載,例如,VM 虛擬主機進行線上即時遷移……等動作(如圖 1 所示)。

圖 1、Long-Distance vSphere vMotion 運作架構示意圖

倘若,多台 vCenter Server 管理主機,彼此處於「不同」的 vCenter SSO Domain 環境時,那麼只能透過 PowerCLI 指令,搭配額外的參數呼叫 vSphere API 和 SDK,才能夠順利遷移相關工作負載。
有關跨不同 vCenter Server 管理主機遷移工作負載需求的詳細資訊,請參考 VMware KB 2106952 – Cross vCenter Migration and Clone requirements in VMware vSphere 6.x and later知識庫文章內容。

現在,管理人員只要採用新版「vSphere 7.0 Update 1c(Patch 02)」或後續版本,便能整合新功能「Advanced Cross vCenter Server vMotion(簡稱為 XVM)」,將線上運作中的 VM 虛擬主機工作負載,隨意進行線上即時遷移的動作,即便多台 vCenter Server 管理主機之間,皆處於不同的 vCenter SSO Domain 也沒問題。

事實上,這個完備 vSphere 虛擬化彈性基礎架構最後一哩的新功能並非突然出現。早在 2015 年的 vSphere 6.0 版本時,VMware 官方便已經推出 Cross vCenter vMotion 即時遷移功能,但僅限於同一個 vCenter SSO Domain 架構下才能實現。

因此,在 VCF(VMware Cloud Foundation)團隊的努力下,推出以 PowerCLI 整合 vSphere API 的方式,幫助企業和組織達成跨不同 vCenter SSO Domain 架構遷移工作負載,並在 2017 年推出的 PowerCLI 6.5R1 版本中,將該特色功能整合至 Move-VM cmdlet當中,隨後在 2018 年時在 VMware Fling 實驗室中,正式推出「Cross vCenter Workload Migration Utility」工具集,讓企業和組織能夠更方便的使用此特色功能,遷移資料中心內相關的工作負載。

在 2019 年時,開始支援以 Plug-ins 的方式,整合此特色功能至 vSphere HTML 5 Client 當中,最後在 2020 年時,正式整合至新推出的 vSphere 7.0 Update 1c 版本當中成為正式內建功能(如圖 2 所示)。

圖 2、Advanced Cross vCenter Server vMotion 特色功能歷史演進示意圖





Cross vCenter Server vMotion 運作架構

Advanced Cross vCenter Server vMotion(XVM)特色功能,在經過幾年的功能演化後,從原本僅支援 PowerCLI 的 Move-VM 指令模式,到 VMware Fling 實驗室成為最熱門的項目之一,終於在新版 vSphere 7 Update 1c 版本中,成為 vSphere 虛擬化基礎架構中內建的特色功能。

XVM 特色功能能夠有效解決多台 vCenter Server 管理主機,處於不同 vCenter SSO Domain 環境時,仍然能夠線上遷移 VM 虛擬主機,同時多台 vCenter Server 管理主機之間,也無須建立「Enhanced Linked Mode(ELM)」或「Hybrid Linked Mode(HLM)」等運作模式。

此外,XVM 特色功能的推出,更有助於企業和組織建構混合雲環境,舉例來說,企業和組織原有的工作負載,運作在自家地端資料中心內部,現在希望將工作負載能夠無縫的遷移到雲端環境,例如,AWX、Azure、GCP……等(如圖 3 所示),便能透過 XVM 特色功能輕鬆完成。
XVM 特色功能支援「單台」或「批次」遷移工作負載的工作任務。
圖 3、VMware Cloud on AWS with Direct Connect 運作架構示意圖

XVM 特色功能支援兩種工作流程模式,分別是「Import VMs」和「Migrate」(如圖 4 所示)。過去,管理人員在執行 Import VMs 的動作時,在工作流程中只能依序選擇欲匯入的 VM 虛擬主機、運算資源、儲存資源……等,現在透過 XVM 特色功能,在工作流程中可以選擇匯入 VM 虛擬主機的來源端 vCenter Server,以及匯入 VM 虛擬主機後的目的端 vCenter Server 管理主機。至於 Migrate 工作流程,與過去遷移工作負載的操作步驟和體驗大致相同,主要差異在於選擇遷移選項時,將會多出一個全新的「Cross vCenter Server Export」選項可供選擇。

圖 4、Advanced Cross vCenter Server vMotion(XVM)特色功能運作架構示意圖





實戰 Advanced Cross vCenter Server vMotion

在本文實作環境中,負責使用者身份驗證和 DNS 伺服器名稱解析任務,Windows 網域控制站所建構的網域名稱為「lab.weithenn.org」,在 vSphere 虛擬化平台和 vCenter Server 管理主機的部份,皆採用最新發佈的「vSphere 7 Update 2」版本,在 vCenter Server 管理主機的部份,總共建構二台 vCenter Server 管理主機,主機名稱分別為「vCenter-A」和「vCenter-B」,並且分別建構所屬的「Datacenter-A、Cluster-A」和「Datacenter-B、Cluster-B」。

至於,部署 vCenter Server 管理主機時,採用不同的 vCenter SSO Domain 名稱,分別是「SSO-A.lab.weithenn.org」和「SSO-B.lab.weithenn.org」(如圖 5 所示),在 vCenter-A 管理主機中,已經部署一台 VM 虛擬主機名稱為「VM-A」,稍後便是針對此台 VM 虛擬主機工作負載,透過 XVM 特色功能進行跨 vCenter Server 和 vCenter SSO Domain 的線上即時遷移工作任務。
因為二台 vCenter Server 管理主機,並未處於「同一個」vCenter SSO Domain。所以,只能開啟二個獨立的 vSphere HTML 5 Client 管理介面,分別連接至不同的 vCenter Server 管理主機。
圖 5、跨 vCenter Server 和 vCenter SSO Domain 線上即時遷移實作環境示意圖



Cross vCenter Server Export 工作流程

確認前置作業和實作環境運作無誤後,在「vCenter-A」管理的虛擬化環境中,已經部署一台名稱為「VM-A」的虛擬主機,透過 XVM 特色功能在 VM-A 虛擬主機線上運作不中斷的情況下,遷移至「vCenter-B」的虛擬化環境中繼續運作,達成進行跨不同 vCenter Server 管理主機,和跨不同 vCenter SSO Domain 線上即時遷移的工作任務。

在 VM-A 虛擬主機運作中的情況下,在 vSphere HTML 5 Client 管理介面中,依序點選「Datacenter-A > Cluster-A > VM-A」,在右鍵視窗中選擇「Migrate」項目。在彈出的 Migrate 互動精靈視窗中,首先選擇線上遷移項目,前三項是過去管理人員所熟知的線上即時遷移項目,本文實作環境則是選擇最新 XVM 特色功能項目「Cross vCenter Server export」(如圖 6 所示)。此外,在繼續下一個工作程序之前,管理人員可以點選互動精靈視窗中右上角的「VM origin」,系統將會顯示 VM-A 虛擬主機,目前使用的資源位置為何,包含,vSphere Cluster、ESXi 虛擬化主機、vNetwork、Datastore…… 等資訊。

圖 6、選擇 Cross vCenter Server export 線上即時遷移項目

在 2-Select a target vCenter Server 頁面中,於 New vCenter 頁籤中,請填入目的端 vCenter Server 管理主機資訊,本文實作環境請指向目的端「vcenter-b.lab.weithenn.org」主機,管理者帳號則是「Administrator@sso-b.lab.weithenn.org」(如圖 7 所示),鍵入管理者密碼並確認無誤後按下「Login」鈕,系統將會進行使用者身份驗證程序,順利通過驗證程序後將會得到 Successfully connected 成功驗證的訊息,才能繼續下一步工作流程。

值得注意的是,在 Login 鈕上方的「Save vCenter Server address」勾選項目,表示順利通過使用者身份驗證程序後,後續需要再次使用 XVM 特色功能時,便可以直接點選「Saved vCenters」頁籤,使用此次成功驗證的使用者身份執行,而無須不斷反覆的輸入目的端 vCenter Server 管理主機的機敏資訊。

圖 7、鍵入另一台 vCenter Server 管理主機和管理者帳號及密碼

在 3-Select a compute resource 頁面中,由於已經通過目的端 vCenter Server 使用者身份驗證程序,所以從這個工作流程項目開始,後續顯示的各項資源包括,運算資源、儲存資源、虛擬網路……等,都是以目的端 vCenter Server 所管理的 vSphere 虛擬化基礎架構。在本文實作環境中,請依據管理需求點選 VM-A 虛擬主機工作負載,屆時所要使用的運算資源,包含,vSphere Cluster、DRS 資源集區、ESXi 虛擬化平台……等。

在 4-Select storage 頁面中,和過去管理人員熟悉的遷移流程相同,倘若 VM 虛擬主機的 vDisk 虛擬硬碟格式需要進行調整,例如,由 Thick Provision Eager Zeroed 改為 Thin Provision,可以在遷移的過程中於此步驟點選「Select virtual disk format」下拉式選擇,選擇 VM 虛擬主機要採用的新 vDisk 虛擬硬碟格式即可。此外,倘若目的端 vCenter Server 主機有管理 vSAN 超融合叢集環境時,那麼可以在「VM Storage Policy」中,選擇要套用哪個 vSAN Policy 至欲遷移的 VM 虛擬主機。
倘若,管理人員忘記原本 VM 虛擬主機採用的 Datastore 時,可以點選右上方「VM origin」,即時了解 VM 虛擬主機原有使用的 Datastore 儲存資源。

請選擇屆時 VM-A 虛擬主機工作負載所要使用的儲存資源,本文實作環境為選擇「Datastore-B」儲存資源(如圖 8 所示),點選 Datastore 儲存資源後,系統將會檢查目的端 Datastore 儲存資源是否滿足需求,通過系統檢測程序後,下方的 Compatibility 相容性檢測區塊中,將會顯示「Compatibility checks succeeded」檢測成功的訊息,並且繼續下一個工作流程。

圖 8、選擇 VM 虛擬主機所要使用的目的端 Datastore 儲存資源

在 5-Select folder 頁面中,選擇 VM 虛擬主機所要歸類的「VM 資料夾」(VM Folder),請管理人員依照 VM 虛擬主機工作負載的屬性,選擇目的端 VM 資料夾。在 6-Select networks 頁面中,於「Source Network」欄位,將會顯示 VM-A 虛擬主機,原本在來源端 vCenter Server 管理架構中,使用的 vSwitch Port Group 名稱,而在「Destination Network」欄位則讓管理人員可以選擇,屆時 VM-A 虛擬主機在目的端 vCenter Server 管理架構中,欲連接和使用的 vSwitch Port Group 名稱。

在本文實作環境中,VM-A 虛擬主機原本連接至名稱為「SSO-A-vNetwork」的 vSwitch Port Group,而屆時連接的目的端為「SSO-B-vNetwork」的 vSwitch Port Group(如圖 9 所示)。同樣的,選擇 VM-A 虛擬主機目的端使用的 vSwitch Port Group 名稱後,系統將會檢查目的端 vNetwork 虛擬網路是否可用,通過系統檢測程序後,下方的 Compatibility 相容性檢測區塊中,將會顯示「Compatibility checks succeeded」檢測成功的訊息,並且繼續下一個工作流程。

圖 9、選擇 VM 虛擬主機所要使用的目的端 vSwitch Port Group 名稱

在 7-Select vMotion priority 頁面中,選擇預設值「Schedule vMotion with high priority(recommended)」項目,盡快遷移指定的 VM 虛擬主機的至目的端 vCenter Server 管理架構中,但是可能會使用較多的 CPU 運算資源。
更多 vMotion 環境需求的詳細資訊,請參考 VMware KB 1003734KB 59232KB 2106949知識庫文件內容。

最後,在 8-Ready to complete 頁面中,再次確認剛才在每個工作流程中的選擇項目內容,確認無誤後按下 Finish 鈕,便立即執行跨不同 vCenter Server 和 vCenter SSO Domain 的線上即時遷移工作任務。值得注意的是,由於同時遷移 VM 虛擬主機的運算和儲存資源,因此需要視 vMotion 網路頻寬,以及 VM 虛擬主機的記憶體大小和 vDisk 虛擬硬碟空間,才能有效預估線上遷移所需花費的時間。
在來源端 vCenter Server 為執行「Relocate virtual machine」工作任務,在目的端 vCenter Server 為執行「Initiate vMotion receive operation」工作任務。

在二端 vCenter Server 管理的虛擬化基礎架構中,vMotion 線上遷移網路規劃良好的情況下,例如,近端「往返時間」(Round-Trip Time,RTT)請規劃在「10 ms」以內,即便二端為遠距離不同站台,也請規劃 RTT 時間在「150 ms」以內,以避免 vMotion 線上遷移發生不可預期的錯誤。

待一段時間線上遷移工作任務執行完畢後,可以在目的端 vCenter Server 管理主機中發現,原本運作在來源端 vCenter Server 管理架構內的 VM-A 虛擬主機,已經無縫式線上遷移至目的端 vCenter Server 管理主機中,並且使用指定的 ESXi 虛擬化平台、Datastore 儲存資源、vNetwork 虛擬網路(如圖 10 所示)。

圖 10、達成跨不同 vCenter Server 和 vCenter SSO Domain 線上即時遷移 VM 虛擬主機



Import VMs 工作流程

順利透過 Cross vCenter Server export 工作流程,達成 VM 虛擬主機跨不同 vCenter Server 和 vCenter SSO Domain 遷移後。緊接著,實作演練在 XVM 特色功能中另一個工作流程「Import VMs」。

在過去的 vSphere 版本中,當管理人員執行「Import VMs」的動作時,通常為選擇「OVF / OVA / VMDK」等檔案進行部署的動作,此時 VM 虛擬主機的運作狀態都是處於「關機」(Power Off)。
有關舊有 Import VMs 動作的詳細資訊,請參考 VMware KB 1006160KB 2034095KB 1003742知識庫文章內容。

現在,透過 XVM 特色功能執行的「Import VMs」工作流程,則是和剛才執行的 Cross vCenter Server export 工作流程類似。同時,和舊版 Import VMs 機制最大的不同點,在於能夠選擇的 VM 虛擬主機運作狀態可以是「運作中」(Power On)。

在本文實作環境中,將剛才遷移至 vCenter-B 所管理的 VM-A 虛擬主機,透過 XVM 特色功能執行新式的「Import VMs」工作流程,線上不中斷的遷移回 vCenter-A 虛擬化基礎架構中。請在 vCenter-A 管理介面中,點選 vSphere Cluster 或 ESXi 虛擬化平台,在右鍵視窗中選擇「Import VMs」項目(如圖 11 所示),準備進入新式 Import VMs 工作流程。

圖 11、準備進入新式 Import VMs 工作流程

在 Import VMs 精靈互動視窗中,於 1-Select a source vCenter Server 頁面中,選擇所要匯入的 VM 虛擬主機,目前正被哪台 vCenter Server 主機所管理,在本文實作環境中 VM-A 虛擬主機,目前被 vCenter-B 主機所管理。

因為,在剛才的 Cross vCenter Server export 工作流程,已經鍵入 vCenter-B 主機的連線和管理者帳號資訊,和勾選「Save vCenter Server address」項目,並且通過系統的身份驗證程序,所以此次便無須再次鍵入 vCenter-B 主機連線和管理者帳號資訊,直接在「Saved vCenters」下拉式選單中,選擇 vCenter-B 主機項目即可(如圖 12 所示)。

圖 12、直接使用先前通過的驗證資訊,無須再次鍵入 vCenter-B 主機連線和管理者帳號資訊

在 2-Import Virtual Machines 頁面中,管理人員可以看到列出的 VM 虛擬主機狀態,無論 VM 虛擬主機為關機中或運作中皆能勾選。倘若,VM 虛擬主機數量過多時,管理人員可以透過右上方「Filter」欄位,鍵入要過濾顯示的 VM 虛擬主機關鍵字後,按下過濾圖示後即可顯示過濾關鍵字後的結果。

此外,倘若顯示的欄位不足以幫助管理人員判斷時,可以點選左下方 Show Columns 圖示,即可勾選要額外顯示的欄位,舉例來說,該台 vCenter Server 管理架構中有多個 vSphere Cluster,便可勾選額外顯示「Cluster」項目,讓管理人員能容易選擇至要執行 Import VMs 工作流程的 VM 虛擬主機。在本文實作環境中,分別勾選「VM-A 和 VM-C」虛擬主機為「運作中」(Power On)狀態(如圖 13 所示)。
請注意,勾選多台 VM 虛擬主機時,這些勾選的 VM 虛擬主機運作狀態必須「一致」,否則系統將無法進入下一個工作流程,並顯示「All VMs to be migrated in a batch must be in the same power state」的錯誤訊息。
圖 13、勾選二台 VM 虛擬主機執行 Import VMs 工作流程

在 3-Select a compute resource 頁面中,由於已經通過目的端 vCenter-A 主機身份驗證程序,後續顯示的各項資源,將為目的端 vCenter-A 所管理的 vSphere 虛擬化基礎架構。在本文實作環境中,依據管理需求點選 VM-A 和 VM-C 虛擬主機工作負載,屆時所要使用的運算資源,包含,vSphere Cluster、DRS 資源集區、ESXi 虛擬化平台……等。

在 4-Select storage 頁面中,同樣可以在此遷移的過程中,透過 Select virtual disk format 下拉式選單中,選擇變更 VM 虛擬主機的 vDisk 虛擬硬碟格式,例如,由 Thin Provision 變更為 Thick Provision Lazy Zeroed,倘若 vCenter-A 主機整合管理 vSAN 超融合叢集環境時,可以在 VM Storage Policy 下拉式選單中,選擇要套用哪個 vSAN Policy 至 VM-A 和 VM-C 虛擬主機。
與 Cross vCenter Server export 工作流程不一樣的地方在於,管理人員忘記原本 VM 虛擬主機採用的 Datastore 時,只能取消此工作流程至 VM 虛擬主機進行查看,而不像 Cross vCenter Server export 工作流程,可以隨時點選右上方「VM origin」進行查看。

在本文實作環境中,為 VM-A 和 VM-C 虛擬主機選擇採用「Datastore-A」儲存資源(如圖 14 所示),在繼續下一個工作流程之前,請確認下方 Compatibility 相容性檢測區塊中,是否顯示「Compatibility checks succeeded」檢測成功的訊息。

圖 14、VM-A 和 VM-C 虛擬主機選擇屆時採用的 Datastore 儲存資源

在 5-Select folder 頁面中,選擇 VM-A 和 VM-C 虛擬主機所要歸類的「VM 資料夾」(VM Folder),請管理人員依照 VM 虛擬主機工作負載的屬性,選擇目的端 VM 資料夾。

在 6-Select networks 頁面中,預設情況下將會在「Source Network」欄位,顯示 VM-A 和 VM-C 虛擬主機,在來源端 vCenter-B 管理架構中使用的 vSwitch Port Group 名稱,請在「Destination Network」欄位,為 VM-A 和 VM-C 虛擬主機選擇屆時使用的 vSwitch Port Group 名稱。

值得注意的是,倘若 VM-A 和 VM-C 屆時採用的 vSwitch Port Group 名稱不同時,管理人員可以點選右下角「Advanced」鈕,為不同的 VM 虛擬主機選擇採用不同的 vSwitch Port Group。在本文實作環境中,為 VM-A 虛擬主機選擇目的端「SSO-A-vNetwork」的 vSwitch Port Group,為 VM-C 虛擬主機選擇「SSO-A-App-vNetwork」的 vSwitch Port Group(如圖 15 所示)。同樣的,在繼續下一個工作流程之前,請確認下方 Compatibility 相容性檢測區塊中,是否顯示「Compatibility checks succeeded」檢測成功的訊息。

圖 15、為個別 VM 虛擬主機選擇不同的目的端 vSwitch Port Group 名稱

在 7-Select vMotion priority 頁面中,採用預設值「Schedule vMotion with high priority(recommended)」項目即可,以便盡快遷移指定的 VM 虛擬主機的至目的端 vCenter-A 管理架構中。最後,在 8-Ready to complete 頁面中,再次確認剛才在每個工作流程中的選擇項目內容,確認無誤後按下 Finish 鈕(如圖 16 所示),便立即為多台運作中的 VM 虛擬主機,執行跨不同 vCenter Server 和 vCenter SSO Domain 的 Import VMs 工作流程。

圖 16、為多台運作中的 VM 虛擬主機,執行跨不同 vCenter Server 和 SSO 的 Import VMs 工作流程

同樣的,可以在來源端的 vCenter-B 主機中,看到為 VM-A 和 VM-C 虛擬主機執行「Relocate virtual machine」工作任務,在目的端的 vCenter-A 主機中,則是執行「Initiate vMotion receive operation」工作任務。

待 Import VMs 工作流程執行完畢後,便可以在目的端 vCenter-A 主機中發現,已經順利將原本運作在來源端 vCenter-B 主機內,VM-A 和 VM-C 虛擬主機無縫式遷移完成。同時,使用 Import VMs 工作流程中,使用指定的 ESXi 虛擬化平台、Datastore 儲存資源、vNetwork 虛擬網路(如圖 17 所示)。

圖 17、透過 Import VMs 工作流程,線上不中斷且無縫式的遷移多台 VM 虛擬主機





結語

透過本文的深入剖析和實作演練後,相信管理人員除了理解 Advanced Cross vCenter Server vMotion(XVM)特色功能和運作架構之外,搭配實作演練更能進一步體會 XVM 特色功能帶來的便利性和彈性,無論是企業和組織自建跨地區資料中心,或者希望整合雲端資料中心達成混合雲運作架構,透過 XVM 特色功能都能幫助管理人員,輕鬆將原有 VM 虛擬主機工作負載無痛和無縫的遷移到不同運作環境中。

網管人 187 期 - 微軟正式支援地端 K8s 叢集實戰 AKS-HCI 混合部署

$
0
0


網管人雜誌

本文刊載於 網管人雜誌第 187 期 - 2021 年 8 月 1 日出刊,NetAdmin 網管人雜誌為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌,下列筆記為本站投稿網管人雜誌獲得刊登的文章,網管人雜誌於每月份 1 日出刊您可於各大書店中看到它,或透過城邦出版人讀者服務網進行訂閱。





本文目錄






前言

在最新舉辦的 Microsoft Build 2021 大會中,微軟 CEO Satya Nadella 在 Opening Keynote 議程中,正式宣佈 AKS(Azure Kubernetes Service)on Azure Stack HCI 產品,脫離技術預覽階段成為正式服務。簡單來說,這表示微軟官方已經正式為企業和組織,提供地端環境運作 Kubernetes 叢集的技術支援。
事實上,在 AKS on Azure Stack HCI 成為正式服務之前,前前後後已經發佈五個公開技術預覽版本,以便收集使用者意見反應和回饋後,進行相關問題修正和提升使用者操作體驗。
因此,企業和組織的管理人員,將傳統單體的營運服務打包為容器化工作負載之後,或將資料中心內部客製化的 Linux 或 Windows 容器映像檔,在無須進行任何更改的情況下,除了可以隨時部署至 Azure 公有雲環境之外。現在,也可以輕鬆部署至地端資料中心內,自行建構的 AKS on Azure Stack HCI 叢集環境中,達到真正混合雲部署和管理工作負載的目的(如圖 1 所示)。

圖 1、AKS(Azure Kubernetes Service)on Azure Stack HCI 叢集架構運作示意圖



AKS on Azure Stack HCI 部署模式

簡單來說,企業和組織在選擇 AKS on Azure Stack HCI 部署模式時,一共有兩種不同的部署模式可供選擇(如圖 2 所示)。第一種,為建立「正式」營運環境的 AKS on Azure Stack HCI 部署模式,除了必須採用通過硬體驗證程序的實體伺服器之外,並且搭配專門為 HCI 超融合叢集環境,進行最佳化和客製化打造的 Azure Stack HCI 雲端作業系統。

倘若,企業和組織目前僅希望「體驗」AKS on Azure Stack HCI 運作架構和環境,那麼可以採用單台伺服器安裝 Windows Server 2019 作業系統,結合巢狀式虛擬化技術,便可以模擬和搭建 AKS on Azure Stack HCI 運作環境。甚至,企業和組織在內部資料中心沒有多餘的硬體伺服器情況下,直接在 Azure 公有雲環境中,建立一台支援巢狀式虛擬化技術的 Azure VM 虛擬主機即可。
採用 Dv3Ev3系列的 Azure VM 虛擬主機,便能支援和啟用巢狀式虛擬化技術。
圖 2、AKS on Azure Stack HCI 部署模式示意圖

值得注意的是,企業和組織在地端資料中心內,自行部署 AKS on Azure Stack HCI 叢集環境時,和 Azure 公有雲環境的 AKS 容器服務有些許不同。舉例來說,在 Azure 公有雲環境的 AKS 容器服務運作架構中,AKS 管理叢集中的控制平面底層基礎架構,皆由 Azure 公有雲環境的 VM 虛擬主機運作和管理,企業和組織的管理人員無須擔心 AKS 管理叢集的相關管理事宜,只要操心後續建立的 AKS 工作負載叢集,以及採用哪些容器印象檔來部署 Pod 和容器及應用程式即可。

然而,在地端資料中心自建的 AKS on Azure Stack HCI 叢集環境中,管理人員必須全面管理整個 AKS 容器服務的基礎架構,從一開始的 Azure Stack HCI 超融合叢集環境,到部署 AKS 容器服務控制平面的「管理叢集」(Management Cluster),以及屆時承載企業營運服務容器化應用程式的「工作負載叢集」(Workload Cluster),這兩個主要的 AKS 容器服務叢集和負載平衡機制,屆時都會以 VM 虛擬主機的方式,運作在 Azure Stack HCI 超融合叢集當中,由企業和組織的管理人員全權管理和維運(如圖 3 所示)。

圖 3、地端資料中心自建 AKS on Azure Stack HCI 叢集環境運作架構示意圖



高可用性機制

在傳統的 Kubernetes 叢集中,運作工作負載叢集和 Pods 及容器的主機,並沒有線上不中斷遷移至其它節點主機的概念和機制。然而,企業和組織在地端資料中心內,建立的 AKS on Azure Stack HCI 叢集環境,由於 AKS 容器服務基礎架構是搭建在 HCI 超融合叢集之上,底層預設是以「容錯移轉叢集」(Failover Cluster)機制所建立,並且針對 AKS 管理叢集和工作負載叢集,將會自動啟用「即時遷移」(Live Migration)機制。

因此,當 AKS 管理叢集和工作負載叢集的底層基礎架構,發生各種預期的中斷服務事件時,運作容器和應用程式的 AKS 工作負載叢集主機,將會透過內建原生的容錯移轉機制,在 HCI 超融合叢集基礎架構中,線上不中斷的將 AKS 工作負載叢集主機,遷移至健康狀態良好的 HCI 超融合叢集節點主機上(如圖 4 所示),所以會比傳統僅將應用程式運作在 VM 虛擬主機上,在進行遷移時花費更少的時間,便能讓容器和應用程式恢復運作。簡單來說,使用者和應用程式都不會察覺到有停機時間的事件發生。

圖 4、AKS on Azure Stack HCI 線上遷移機制支援 AKS 管理和工作負載叢集示意圖

管理人員可能仍然有些許疑惑,那麼我們以三個最常見的中斷服務事件來說明,當中斷服務事件發生時,是否對於 VM 虛擬主機內的應用程式,以及 AKS 容器和應用程式的可用性造成影響。

首先,在 HCI 超融合叢集節點主機套用重要安全性更新且必須重新啟動時,由於內建的容錯移轉叢集高可用性機制已啟動,所以當 HCI 超融合叢集節點主機更新完成並重新啟動之前,將會把主機內所有具備高可用性角色的工作負載,透過即時遷移機制線上不中斷的遷移至其它 HCI 超融合叢集節點主機,所以無論是 VM 虛擬主機或 AKS 容器和應用程式都不會受到任何影響。

當運作 AKS 工作負載叢集的 VM 虛擬主機,需要套用安全性更新並且必須重新啟動時,容錯移轉叢集的高可用性機制,將會針對 AKS 工作負載叢集的 VM 虛擬主機,執行高可用性機制的清空和隔離工作任務,相關的 Pod 和容器都會收回至可用的工作節點主機,並且在 AKS 工作負載叢集主機更新作業完成後,重新加入工作節點並進行工作排程調度(如圖 5 所示)。因此,在 AKS 工作負載叢集 VM 虛擬主機的層級來說,並不會有產生任何停機事件或受到任何影響,但是從 AKS 容器和應用程式的層級來看,容器執行收回至可用工作節點的動作,可能會讓應用程式的存取受到影響。

最後,當底層基礎架構的 HCI 超融合叢集節點主機,發生非預期的硬體故障事件時,容錯移轉叢集會將相關工作負載置於隔離狀態,然後在 6-8 分鐘的時間之內,為這些受影響的 VM 虛擬主機執行「快速遷移」(Quick Migration),至 HCI 超融合叢集中其它仍然存活的節點主機,此時將無論 AKS 工作負載叢集 VM 虛擬主機,以及 AKS 容器和應用程式都會受到影響並產生停機時間。

圖 5、線上遷移和 K8s 叢集管理工作節點 Pod 排程調度示意圖



安全性機制

除了高可用性和彈性架構之外,另一個企業和組織重視的「安全性」(Security)議題也不馬虎。透過下列不同的安全性層面說明(如圖 6 所示),讓管理人員能夠更深入理解 AKS on Azure Stack HCI 叢集架構,如何完整且高安全性的保護整體基礎架構。

1. 在 AKS on Azure Stack HCI 叢集架構中,雖然處於管理叢集中的 AKS 主機,可以管理和存取 Kubernetes 叢集中所有的工作負載,但這可能導致單一入侵點的安全性疑慮。然而,實際上 AKS 主機的管理和存取權限會受到管控,因為管理叢集中 AKS 主機的主要用途,僅限於部署容器工作負載和收集並匯整叢集使用量。
2. 雖然,為了降低部署難度和複雜性,工作負載叢集會共用相同基礎的 Windows 伺服器。然而,在基礎安全性需求的情況下,當工作負載叢集共用相同基礎的 Windows 伺服器時,會將每個工作負載叢集部署為 VM 虛擬主機,確保每個工作負載叢集之間有強式隔離機制存在。
3. 管理人員將營運服務以容器的方式,部署並運作在工作負載叢集中,不同容器彼此之間是互相隔離的。雖然,相較於 VM 虛擬主機層級的強式隔離機制來說,容器隔離機制較弱,但是仍保有一定程度的隔離性和安全性。
4. 雖然,容器之間可以透過 Overlay 網路互相通訊和溝通。但是,管理人員可以組態設定 Calico 網路原則,定義在工作負載叢集內運作的 Linux 和 Windows 容器之間,網路封包進出時允許放行或進行阻擋的隔離原則。
5. AKS on Azure Stack HCI 叢集架構中,預設便已經建立憑證的部署及更新和撤銷機制,以便提供內建 Kubernetes 元件之間的通訊,例如,AKS 管理叢集當中的 API 伺服器,與 AKS 工作負載叢集中的容器主機,預設便會透過憑證進行加密通訊。
6. 管理人員無論是透過 kubectl 和 PowerShell 指令,或是 WAC 和 Azure Arc 管理機制與 API 伺服器通訊時,必須先通過 Windows 基礎架構中的 AD 使用者身份驗證機制才行。
7. 微軟官方將會針對每個 AKS on Azure Stack HCI 版本,定期提供適當的安全性修補程式。

圖 6、AKS on Azure Stack HCI 叢集安全性架構示意圖





實戰 – 混合部署 Linux/Windows 容器至 AKS-HCI

由於,先前在「網管人 183 期 -WAC 管理混合雲工作負載,輕鬆部署 K8s 叢集及容器」專欄文章中,已經帶領讀者手把手將 AKS 容器服務,建置在地端資料中心內的 HCI 超融合叢集運作環境,所以在此便不再贅述。

在本小節中,將會實戰演練如何在 AKS 容器服務建構的 Kubernetes 叢集中,混合部署 Windows 和 Linux 容器及應用程式,確保企業和組織打包和客製化的 Windows 容器及應用程式,能夠正確運作在 Windows Worker 節點主機上,而非 Linux Worker 節點主機,造成 Windows 容器和應用程式運作異常。



Azure Stack HCI 超融合叢集環境

在開始實作之前,管理人員應先確認 Azure Stack HCI 超融合叢集環境是否運作正常,以便屆時能夠提供給 AKS 容器服務高效能和高可用性的基礎架構。在本文實作環境中,採用的網域名稱為「hci.weithenn.org」,並且提供運作環境 DNS 名稱解析和 DHCP 伺服器服務,而 HCI 超融合叢集中的節點主機,採用最新版本的 Azure Stack HCI 20H2 雲端作業系統,建立的 HCI 超融合叢集名稱為「aks-hci-cluster.hci.weithenn.org」(如圖 7 所示)。
請注意 !必須將 HCI 超融合叢集註冊並連結至 Azure 公有雲環境,否則稍後將無法部署 AKS 管理叢集,或遭遇非預期的錯誤。
圖 7、確認 HCI 超融合叢集已運作正常並註冊至 Azure 公有雲環境

值得注意的是,在 WAC(Windows Admin Center)管理主機,必須採用「Windows 10」作業系統才行,主要原因在於倘若採用 Windows Server 安裝 WAC 服務後,將會因為預設自動運作的 WAC Gateway 模式,造成部署 AKS 容器服務可能發生失敗的情況。
請注意 !部署 GA 版本的 AKS 容器服務,必須採用 Windows Admin Center「2103.2」或後續版本。

請在 WAC 管理介面中,依序點選「Settings > Gateway > Extensions > Installed extensions」項目,確認在已安裝擴充模組頁面中,看到「Azure Kubernetes Service」項目和版本,確保屆時能夠順利部署 AKS 管理叢集和 AKS 工作負載叢集(如圖 8 所示)。

圖 8、確認 WAC 主機已安裝 AKS 容器服務擴充模組



AKS 管理叢集和 AKS 工作負載叢集

在部署 AKS 工作負載叢集時,正式的 GA 版本和先前的技術預覽版本之間,最大的不同點在於 AKS 管理叢集虛擬網路的部份,由先前技術預覽版本僅支援「Flannel」網路功能,到正式版本時更新增支援「Calico」網路功能(如圖 9 所示)。

簡單來說,Flannel 是專為容器設計的虛擬網路層,它會建立一個「Overlay」網路,讓屆時運作在 AKS 叢集中的 Pod 和容器,都會在 Overlay 網路中獲得 IP 位址,並且可以透過獲得的 IP 位址達到互相通訊的目的。至於 Calico 虛擬網路層除了支援容器之外,還同時支援 VM 虛擬主機和原生主機型工作負載,並且支援 「Network Policies」(網路原則)功能,以便管理容器和 Pod 之間的網路流量,達到安全性管控的目的。

圖 9、部署 AKS 管理叢集並採用和整合 Calico 虛擬網路層

順利部署 AKS 管理叢集和工作負載叢集後,可以在 WAC 管理介面中看到 Kubernetes 叢集健康情況和版本。在本文實作環境中,可以看到 AKS 管理叢集採用穩定的「v1.19.7」版本,而 AKS 工作負載叢集則是採用最新的「v1.20.5」版本(如圖 10 所示)。

圖 10、確保 AKS 管理叢集和工作負載叢集的健康情況和版本資訊



部署 Linux 和 Windows 節點主機

確認 AKS 管理叢集和 AKS 工作負載叢集部署完成後。由於,在剛才部署 AKS 工作負載叢集時,為了加快部署速度,並沒有在部署過程中順便建立 Linux 或 Windows 節點主機。

在部署 Linux 或 Windows 節點主機之前,管理人員可以透過「Get-AksHciKubernetesVersion」指令,查詢每個 Kubernetes 版本資訊和支援的作業系統(如圖 11 所示)。

圖 11、查詢目前環境支援的每個 Kubernetes 版本資訊和支援的作業系統

現在,管理人員可以透過「Set-AksHciCluster」指令,搭配參數「-Name k8s-workload-cluster」指定 AKS 工作負載叢集,搭配參數「-linuxNodeCount 1」指定部署一台 Linux 節點主機,搭配參數「-windowsNodeCount 1」指定部署一台 Windows 節點主機。待部署作業完成後,透過「Get-AksHciCluster」指令,查詢指定的 AKS 工作負載叢集和 Linux 及 Windows 節點主機資訊(如圖 12 所示)。

圖 12、部署 Linux 及 Windows 節點主機至指定的 AKS 工作負載叢集



部署 Linux 容器和應用程式

首先,我們將部署 Azure 投票應用程式(azure-vote.yaml),至 AKS 工作負載叢集中,這個 Azure 投票應用程式採用 Python / Flask 等前端介面技術,而後端資料元件的部份則採用 Redis,詳細資訊請參考 GitHub - Azure-Samples/azure-voting-app-redis: Azure voting app used in docs 文章內容。

在開始部署 Linux 和 Windows 容器及應用程式之前,由於稍後我們將使用 kubectl 指令,部署容器至 AKS 工作負載叢集中,所以必須先使用「Get-AksHciCredential」指令,指定 kubectl 指令的 kubeconfig 組態設定檔,以及指定的 AKS 工作負載叢集,否則稍後部署 Linux 或 Windows 容器時,將會遭遇到「x509 : certificate signed by unknown authority」的錯誤訊息並且部署失敗。

準備好「azure-vote.yaml」的 YAML 檔案內容後,執行「kubectl apply -f azure-vote.yaml」指令,部署「azure-vote-front」和「azure-vote-back」應用服務至 AKS 工作負載叢集。當部署作業完成後,管理人員可以透過「kubectl get deployments」查詢 AKS 工作負載叢集 Deployment 狀態,使用「kubectl get pods」查詢部署的 Pods 狀態,最後使用「kubectl get services」查詢部署後的 Services 狀態,其中「EXTERNAL-IP」欄位中的 IP 位址(如圖 13 所示),便是稍後存取 Azure 投票應用程式的 IP 位址。
請注意 !一開始執行部署作業時,EXTERNAL-IP 欄位將是「pending」狀態,待部署完成且正確連接至 AKS 工作負載叢集的負載平衡器後,系統便會顯示可供使用者存取應用程式的 IP 位址。
圖 13、部署 Linux 容器和應用程式至 AKS 工作負載叢集

現在,使用者可以透過瀏覽器存取 Azure 投票應用程式,本文實作環境 IP 位址為「10.10.75.93」(如圖 14 所示),使用者可以隨意投票給 Dogs 或 Cats 或按下 Reset 鈕清除投票結果。

圖 14、透過瀏覽器存取 Azure 投票應用程式



部署 Windows 容器和應用程式

在 Windows 容器的部份,我們將部署 ASP.NET 範例網站應用程式(sample.yaml),至 AKS 工作負載叢集中。同樣的,如果部署 Windows 容器的目標 AKS 工作負載叢集,與剛才部署 Linux 容器不同時,仍然必須先使用「Get-AksHciCredential」指令,指定 kubectl 指令所要採用的 kubeconfig 組態設定檔,以及指定的 AKS 工作負載叢集,否則稍後部署 Windows 容器時,便會遭遇到「x509 : certificate signed by unknown authority」的錯誤訊息並且部署作業失敗。

準備好「sample.yaml」的 YAML 檔案內容後,執行「kubectl apply -f sample.yaml」指令,部署「sample」應用服務至 AKS 工作負載叢集。當部署作業完成後,管理人員可以透過「kubectl get deployments」查詢 AKS 工作負載叢集 Deployment 狀態,使用「kubectl get pods」查詢部署的 Pods 狀態,最後使用「kubectl get services」查詢部署後的 Services 狀態,其中「EXTERNAL-IP」欄位中的 IP 位址(如圖 15 所示),便是稍後存取 ASP.NET 範例網站應用程式的 IP 位址。

圖 15、部署 Windows 容器和應用程式至 AKS 工作負載叢集

現在,使用者可以透過瀏覽器存取 ASP.NET 範例網站,本文實作環境 IP 位址為「10.10.75.93」(如圖 16 所示)。

圖 16、透過瀏覽器存取 ASP.NET 範例網站



調整 Pod 運作規模

順利部署 Linux 或 Windows 容器和應用程式後,管理人員可以隨時依照使用者存取和 Pod 工作負載情況,隨時調整 Linux 或 Windows 容器服務的運作規模。

舉例來說,先前部署的 Azure 投票應用程式 Linux 容器中,僅分別部署一個 Pod 來運作 azure-vote-front 和 azure-vote-back 工作負載,當工作負載壓力增大時,管理人員可以搭配參數「scale --replicas=5」,將指定的 Pod 數量從原本的「1 個」提升數量為「5 個」,而工作負載壓力降低時,也可以透過參數「scale --replicas=3」,將指定的 Pod 數量從提升後的「5 個」降低數量為「3 個」(如圖 17 所示)。

圖 17、即時調整 Linux 或 Windows 容器服務的運作規模





結語

透過本文的深入剖析及實戰演練,除了管理人員可透過 WAC 管理平台,輕鬆部署 AKS 容器服務和控制平面基礎架構,以及 Kubernetes 叢集和 Linux 與 Windows 節點主機,和同時部署 Linux 和 Windows 容器及應用程式之外,透過底層 HCI 超融合叢集的容錯移轉機制,更能夠為上層運作的容器及應用程式,提供傳統 Kubernetes 叢集所無法提供的高可用性。

PowerShell - 參照清單持續 Ping 特定主機

$
0
0


前言

在先前撰寫的 PowerShell - 參照清單快速 Ping 特定的 Windows 主機文章中,主要是針對特定的 Windows 主機,先確認是否有網域環境中的電腦帳號,然後才執行 ping 的動作。本文的需求則有些微不同,希望可以持續 ping 特定的主機 (Windows 和 Linux),然後 ping 失敗的主機會在 PowerShell 視窗中用「紅色字體」顯示之外,也把 ping 失敗的時間和主機名稱寫入 log 當中,所以本篇筆記就出現了。


執行結果

首先,請在 PowerShell 所在路徑中,建立 Ping_hosts.txt文字檔案,將要持續 ping 的主機清單寫入其中。

執行時,首先會先用「紫色字體」顯示目前的時間,以及 ping 主機的總數 (讀取主機清單),然後透過 Test-Connection執行 ping 特定主機的動作 (以白色字體顯示),但是 ping 失敗的主機先不顯示,否則會讓整個 PowerShell 執行視窗的結果亂掉 (錯誤訊息噴太多了 😂),接著再用「紅色字體」顯示 ping 失敗的主機,同時把 ping 失敗的時間和主機名稱寫入 log 當中 (<今天日期>_ping_failed_hosts.txt),最後用「黃色字體」顯示休息 60 秒之後,再繼續 ping 的動作。






Keep_Ping_Hosts.ps1



PowerShell - 透過 Putty 同時 SSH 連線登入多台特定主機

$
0
0


前言

簡單來說,最近有個需求是要透過 Putty 同時 SSH 連線並登入多台特定主機,例如,同一組使用者帳號和密碼,但要登入 20 台主機,該如何加快整個登入主機的流程? 雖然,Putty 可以透過儲存 Sessions 的方式,讓整個開啟並連線主機的流程加快,然而它還是 1:1 的特性,所以無法滿足需求。因此,本篇筆記就出現了。
本文實作環境中,採用「密碼」登入連線主機的方式 (如果,這些機器是我所管理的,當然就會是使用 SSH Key 登入的方式,而非鍵入密碼的方式登入了!!)。



執行結果

首先,請把需要 SSH 連線登入的主機,寫入到 ssh_hosts.txt 主機清單文件中。

在密碼的部份,採用 Get-Credential的方式,以便彈出視窗方便鍵入 SSH 連線登入的使用者帳號和密碼 (你應該不可能直接把明文密碼寫在 PowerShell 內吧! 😈)。值得注意的是,透過 Get-Credential方式儲存的密碼為 SecureString的方式,所以必須在過程中進行解開,然後再送給 $Password變數以便稍後使用。

另外一個注意的部份,當 Putty 第一次連線主機時,會彈出 Yes / No / Cancel 詢問 視窗,是否要把主機加入至 Know host 清單中,當點選 Yes 時,便會把主機資訊寫入至 Computer\HKEY_CURRENT_USER\SOFTWARE\SimonTatham\PuTTY\SshHostKeys機碼路徑內。但是,這個步驟會中斷我們自動 SSH 連線多台主機流程。

所以,這就是第 28 行內容 $Wshell.SendKeys("Y")的用意了 (送出 Y,達到自動回答 Yes 的目的),至於為何要先休息 1 秒才送出 Y 呢? 原因在於,等待 Putty.exe 執行後才送出 Y,否則可能遭遇到 Putty.exe 還沒執行好,系統就送出 Y 然後連線流程就卡住了。



最後,則是把主機清單中 SSH 連線失敗的部份,用「紅色字體」顯示在 PowerShell 視窗中並寫入<今天日期>_ssh_failed_hosts.txt檔案內。




SSH_Hosts_via_Putty.ps1




PowerShell - 透過 Windows Terminal 同時 SSH 連線登入多台特定主機

$
0
0


前言

簡單來說,最近有個需求要透過 Windows Terminal同時 SSH 連線並登入多台特定主機,例如,同一組使用者帳號和密碼,但要登入 20 台主機,該如何加快整個登入主機的流程?因此,本篇筆記就出現了。
本文實作環境中,採用「密碼」登入連線主機的方式 (如果,這些機器是我管理的,當然就會是使用 SSH Key 登入的方式,而非鍵入密碼的方式登入!!)。
習慣採用 Putty 的朋友,可以參考站內另一篇 PowerShell - 透過 Putty 同時 SSH 連線登入多台特定主機文章。



執行結果

首先,請把需要透過 Windows Terminal SSH 連線登入的主機,寫入到 ssh_hosts.txt主機清單文件中。

在密碼的部份,採用 Get-Credential的方式,以便彈出視窗方便鍵入準備 SSH 連線登入的使用者帳號和密碼 (你應該不可能直接把明文密碼寫在 PowerShell 內吧!)。由於,透過 Get-Credential方式儲存的密碼為 SecureString的方式,所以必須在過程中進行解開,然後再送給 $Password變數以便稍後使用。

另外一個注意的部份,當 Windows Terminal 第一次連線主機時,會詢問是否要把主機加入至 Know host 清單中,可以透過「-o StrictHostKeyChecking=no」參數直接允許並加入即可,屆時系統便會把連線的主機加入至「"%USERPROFILE%\.ssh\known_hosts」內。

至於為何要先休息 5 秒才送出密碼和 Enter呢? 原因在於,等待系統開啟 Windows Terminal 之後,才執行送出密碼和 Enter 的動作,否則可能遭遇到 Windows Terminal 還沒啟動完成,系統就送出密碼和 Enter,然後因為送出和接收的時間不對連線流程就卡住了。



最後,則是把主機清單中連線失敗的部份,用「紅色字體」顯示在 PowerShell 視窗中並寫入<今天日期>_ssh_failed_hosts.txt檔案內。




SSH_Hosts_via_WindowsTerminal.ps1



Windows Server Summit 2022

$
0
0


前言

在 9 月 16 日線上舉辦的 Windows Server Summit 2022,將會獲得有關 Windows Server 2022、Azure Arc……等資訊。有興趣的朋友,可以透過下方網址進行報名:




活動議程和主軸

下列是本次 Windows Server Summit 2022 的議程主軸:
  • 有關 Windows Server 2022 的最新消息和公告。
  • 透過議程中實際展示,幫助你了解混合式基礎架構解決方案。
  • 在 Azure Stack HCI 超融合環境中使用 AKS (Azure Kubernetes Services),部署現代化應用程式。
  • 透過 Microsoft System Center 和 Azure Arc 達成現代化伺服器管理機制。
  • 了解如何透過 Azure 最大化企業和組織的現有投資。
  • 由專家在線上進行現場問與答。
  • Windows Insider Program for Windows Server
  • Guide to Migrate Windows Server to Azure

下列是站內先前撰寫有關 Windows Server 2022 的文章,有興趣的朋友也可以參考看看:
Viewing all 591 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>