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

S2D (Storage Spaces Direct) 支援 Intel Xeon Scalable 處理器

$
0
0

前言

最新的 Intel Xeon Scalable處理器於日前正式發佈,同一時間 Claus Joergensen (S2D Team Leader) 也隨即在 Storage at Microsoft部落格上,發表 S2D on Intel Xeon Scalable處理器的效能測試成功。




S2D on Intel Xeon Platinum 處理器效能測試

下列便是 Windows Server 2016 S2D (Storage Spaces Direct) 軟體定義存技術,搭配最新 Intel Xeon Scalable 處理器的測試環境。有關 Windows Server 2016 S2D (Storage Spaces Direct) 運作環境建置的詳細資訊,請參考 Intel Implementation Guide - Intel Optimized Configurations for Windows Server 2016 with Storage Spaces Direct文件。

S2D 叢集由 4 台 S2D 叢集節點主機組成,每台伺服器硬體配置如下:
  • Intel Server System R2208WF
  • 2x Intel Xeon Platinum 8168 CPU (24cores @ 2.7Ghz)
  • 128GiB DDR4 DRAM
  • 2x 375GB Intel Optane SSD DC P4800X (NVMe SSD)
  • 4x 1.2TB Intel SSD DC S3610 SATA SSD
  • Intel Ethernet Connection X722 with 4x 10GbE iWARP RDMA
  • BIOS configuration
  • C States disabled
  • BIOS performance plan
  • Turbo On
  • HT On


同樣的,採用 VMFleet儲存效能壓力測試工具進行測試,相關測試條件如下:
  • 4x 3-copy mirror CSV volumes
  • Cache configured for Read and Write
  • 24 VMs (diskspd 4K IO 90% read / 10% write) per node
  • Each VM rate limited to 7,500 IOPS (similar to Azure P40 disk)

測試結果可以看到,在 Read IO的表現為「80 μs」 Write IO則是「300 μs」,在 CPU 工作負載的表現則是「低於 25%」




Intel Xeon Scalable 處理器簡介

簡單來說,最新一代 Intel Xeon Scalable 處理器共分為「Platinum、Gold、Silver、Bronze」4種不同等級的 CPU處理器。詳細資訊請參考 Intel® Xeon® Scalable Processors Product Specifications



Intel Xeon Platinum Processors


Intel Xeon Gold Processors



Intel Xeon Silver Processors


Intel Xeon Bronze Processors




參考資源


138 期 - VMware 自家容器作業系統實戰 Photon OS 基礎安裝

$
0
0

網管人雜誌

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



文章目錄

前言
Photon 硬體需求及部署方式
安裝 Photon OS 容器平台
基礎操作
SSH 遠端管理
Docker 容器管理服務
          執行第 1 個容器 Hello-World
          執行第 2 個容器 Nginx 網頁伺服器
結語





前言

根據知名市調機構 Gartner 的研究報告顯示,在 2016年時企業及組織普遍已經超過 80 %的工作負載都運作在 VM 虛擬主機當中,同時預估在 2018年時企業及組織當中將會有 50 %的工作負載運作在「容器」(Container)當中,並且在 2020年時不管是企業及組織內部的私有雲,或者是雲端服務業者所提供的公有雲 IaaS 服務當中,大多數的容器將會運作在 VM 虛擬主機當中。

有鑑於此 VMware 官方在 2015 年 4 月時,正式發佈 Photon OSProject Lightwave這 2 項開放原始碼專案,並放到知名的開放原始碼專案平台 GitHub 上讓管理人員方便下載,接著在 2016 年 10 月於 VMworld 歐洲大會上正式發佈 VMware Photon Platform,希望能夠幫助企業及組織更容易打造「雲端原生應用程式」(Cloud Native Applications)的運作環境。

圖 1、VMware Photon Platform 運作架構示意圖

透過 VMware Photon Platform 運作架構,所打造的企業級雲端基礎架構平台並非只是單純僅運作容器服務而已。事實上,透過 VMware Photon Platform 中的 Photon Controller運作元件,可以讓 IT 管理人員達到以分鐘等級建立數千個容器執行不同的工作負載或服務,至於 Project Lightwqave 則是在 VMware Photon Platform 運作架構中,負責處理 SSO 單一登入、驗證、授權及憑證……等功能。倘若,企業或組織的管理人員已經習慣使用 Kubernetes調度工具,來管理企業及組織當中容器環境的話,那麼 VMware Photon Platform 也完全支援並能輕鬆整合。

圖 2、Project Lightwqave 運作架構示意圖

本文,將著重在 VMware Photon Platform 運作架構中的基礎元件 Photon OS,它是一個輕量型的 Linux 容器執行環境,也就是大家所熟知的「容器作業系統」(Container OS)。或許,有讀者會納悶為何市面上已經有許多容器作業系統,而 VMware 官方還要自行額外打造自家的 Photon OS 容器平台,主要原因在於市面上的容器作業系統並非針對 VMware 虛擬化基礎架構最佳化而設計,同時在容器運作環境的安全性及網路設計普遍不足,因此為了因應現代化「微服務」(MicroServices)的運作架構,所以才著手打造及整合並最佳化運作於 VMware 虛擬化基礎架構的 Photon OS 容器平台。

圖 3、在 VMware 虛擬化基礎架構環境中運作容器環境示意圖





Photon 硬體需求及部署方式

首先,Photon OS 輕量級的容器作業系統,所需要的硬體資源需求非常低只需「2 vCPU、384 MB 記憶體、20 GB 硬碟空間」即可運作。在 Photon OS 的 GitHub 頁面中可以看到,提供下列 4 種不同的封裝格式方便 IT 管理人員部署 Photon OS 容器平台。

  • ISO 映像檔:下載 ISO 映像檔後,建立 VM 虛擬主機並全新安裝 Photon OS 容器平台。
  • OVA:透過 OVA 直接將已經封裝好的 Photon OS Minimal 版本容器平台,部署至 VMware 虛擬化平台,例如,vSphere ESXi、Workstation 12…… 等(支援虛擬硬體版本 10、11 的 VM 虛擬主機)。
  • Amazon AMI:將 Photon OS 容器平台進行封裝,以便 IT 管理人員在 Amazon EC2 公有雲環境中部署及運作 Photon OS 容器平台。
  • Google GCE:將 Photon OS 容器平台進行封裝,以便 IT 管理人員在 Google Compute Engine 公有雲環境中部署及運作 Photon OS 容器平台。
  • Microsoft Azure:目前尚未支援,但 VMware 官方表示很快便會將 Photon OS 容器平台進行封裝,以便 IT 管理人員在 Microsoft Azure 公有雲環境中部署及運作 Photon OS 容器平台。





安裝 Photon OS 容器平台

在本文實作環境中,我們採用下載 Photon OS 的 ISO 映像檔,以及 VMware WorkStation 虛擬化測試環境來安裝及測試 Photon OS 容器平台。在建立運作 Photon OS 的 VM 虛擬主機過程中,必須注意的是在選擇客體作業系統版本時,請選擇至「Linux」選項然後在 Version 下拉式選單中,選擇至「VMware Photon 64-bit」項目即可。
倘若,在 Version 下拉式選單中沒有 VMware Photon 64-bit 項目可以選擇的話,請改為選擇「Other Linux 3.x kernel 64-bit」項目。

圖 4、選擇安裝 Photon OS 容器平台的客體作業系統版本

如果,採用的是 VMware vSphere ESXi 虛擬化平台時,那麼在建立運作 Photon OS 的 VM 虛擬主機過程中,請在 Select Compatibility 頁面於下拉式選單中選至「ESXi 6.0 and later」項目,在 Select a guest OS 頁面於下拉式選單中分別選至「Linux、Other 3.x Linux(64-bit)」項目即可。
支援運作 Photon OS 容器平台的 VMware vSphere ESXi 虛擬化平台版本為 5.5、6.0、6.5

圖 5、在 VMware vSphere ESXi 虛擬化平台建立用於 Photon OS 的 VM 虛擬主機類型

安裝 Photon OS 容器平台的過程非常簡單,只要 3 個步驟即可安裝完成分別是選擇安裝選項、組態設定 Photon OS 容器平台的主機名稱、設定 Root 管理者帳戶的密碼即可。有關 Photon OS 容器平台安裝選項的部分,有下列 4 種安裝選項可供選擇:

  • Photon Minimal:最輕量的「容器主機執行階段」(Container Host Runtime)運作環境,具備最高運作效能及安全性的容器平台版本。
  • Photon Full:包含額外的相關套件以方便建立及打包應用程式在容器環境中運作,適合一開始使用 Photon OS 容器平台進行驗證及測試的版本。
  • Photon OSTree Host:將會建立 Photon OS 執行個體,並且從 RPM-OSTree Server 下載相關套件及程式庫,同時後續在運作上將交由 OSTree Server 進行集中管理。
  • Photon OSTree Server:將會建立「存放庫」(Repository)同時負責管理 OSTree 主機群,負責企業及組織內的容器生命週期管理及企業級規模擴充的工作任務。

圖 6、Photon OS 容器平台共有 4 種安裝選項可供選擇

在本文實作環境中選擇「Photon Full」安裝選項,大約 2 分鐘便完成 Photon OS 容器平台的安裝程序,然後按下任意鍵系統便會自動重新啟動。雖然,Photon OS 容器平台的基底也是 Linux 作業系統,但是 Photon OS 容器平台除了是 VMware 官方專為 vSphere 虛擬化環境進行最佳化之外,同時還移除 Linux 核心中不必要的部分,以及與 vSphere Hypervisor 重複的核心快取部分,以便提升 Photon OS 容器平台整體的運作效能,所以管理人員應該會發現 Photon OS 容器平台開機非常快速。

圖 7、Photon OS 容器平台開機畫面





基礎操作

當 Photon OS 容器平台開機完成後,會看到像 Linux 作業系統的 Console 文字登入訊息,請鍵入管理者帳號「root」以及剛才在安裝程序中,組態設定 Root 管理者帳戶的密碼後便可以順利登入 Photon OS 容器平台。

查詢系統資訊
順利登入後,我們可以使用指令「uname -a」查看 Photon OS 容器平台使用的 Linux 核心版本,接著使用「cat /etc/photon-release」指令查看 Photon OS 容器平台版本及組建編號,或者使用「hostnamectl」指令直接查詢系統相關資訊。

圖 8、查看 Photon OS 容器平台系統資訊

在本文實作環境中,Photon OS 容器平台是運作在 VM 虛擬主機內,對於稍有 vSphere 虛擬化運作環境管理經驗的 IT 管理人員來說,運作在 vSphere 虛擬化環境的 VM 虛擬主機,首先應確認 VMware Tools 服務是否正確運作,以便確保在 vSphere 虛擬化環境中的 VM 虛擬主機,在虛擬硬體及效能層面能夠以最佳化的方式運作。請鍵入「systemctl status vmtoolsd」指令,即可確認 Photon OS 容器平台中的 VMware Tools 服務是否順利運作。

圖 9、確認 Photon OS 容器平台中的 VMware Tools 服務是否順利運作

網路組態設定
預設情況下,Photon OS 容器平台開機後便會啟動 DHCP Client 機制,嘗試尋找區域網路中是否有 DHCP 伺服器可以配發 IP 位址,倘若你需要關閉 DHCP Client 自動尋找 IP 位址的機制。請將「/etc/systemd/network/10-dhcp-en.network」檔案內容中,在 Network 區塊下把「DHCP = yes」組態設定值改為「DHCP = no」後存檔離開即可。

在實務應用上,管理人員通常會為 Photon OS 容器平台組態設定固定 IP 位址。首先,請透過「networkctl」指令,確認目前的 Photon OS 容器平台共有哪些網路介面,同時這些網路介面的連線狀態為何。在本文實作環境中,管理人員為 Photon OS 容器平台配置 1 片虛擬網路卡,所以可以看到指令的輸出結果中有「eth0」網路卡,並且運作狀態為「routable、configured」,稍後我們將會針對 eth0 網路卡組態設定固定 IP 位址。

圖 10、指令結果顯示 Photon OS 容器平台配置 1 片網路卡

接著,可以直接將原本的 DHCP Client 組態設定檔,從「10-dhcp-en.network」重新命名為「10-static-en.network」,在 Match 區塊中使用「Name=eth0」指定 eth0 網路卡的組態設定檔,接著在 Network 區塊下組態設定 Photon OS 容器平台網路資訊:

  • DHCP=no:停止啟用 DHCP Client 功能,避免 Photon OS 容器平台嘗試自動尋找區域網路中的 DHCP 伺服器配發 IP 位址。
  • Address=10.10.75.31/24:指定 Photon OS 容器平台採用「10.10.75.31」固定 IP 位址,並且採用「/24」CIDR 的網路遮罩的語法進行組態設定。
  • Gateway=10.10.75.254:指定 Photon OS 容器平台的預設閘道為「10.10.75.254」。
  • Domains=weithenn.org:指定 Photon OS 容器平台採用的網域名稱及 DNS 搜尋尾碼。
  • NTP=clock.stdtime.gov.tw: 指定 Photon OS 容器平台所要採用的 NTP 時間校對伺服器。倘若,需要指定多筆 NTP 時間校對伺服器的話,請以「空白」隔開即可。

上述只是列舉常用網路組態設定參數,詳細資訊請參考 systemd.network的 Man Pages 資訊。

接著,請修改「/etc/resolv.conf」組態設定檔內容,指定 Photon OS 容器平台所要採用的 DNS 伺服器 IP 位址即可。在本文實作環境中,指定的 DNS 伺服器為「nameserver 168.95.1.1」「nameserver 8.8.8.8」

最後,便可以使用「systemctl restart systemd-networkd」指令,重新啟動 Photon OS 容器平台的網路服務,然後就可以使用「ipa」「iproute」指令,確認剛才所設定的固定 IP 位址及預設閘道資訊是否正確。

圖 11、確認 Photon OS 容器平台固定 IP 位址及預設閘道組態設定是否正確

使用「systemctl status systemd-networkd -l」指令,確認 Photon OS 容器平台網路服務運作狀態,以及使用「systemctl status systemd-timesyncd -l」指令,確認 Photon OS 容器平台 NTP 時間校對服務運作狀態。

圖 12、確認 Photon OS 容器平台網路服務及 NTP 時間校對服務運作狀態





SSH 遠端管理

在實務管理上,管理人員不可能會直接在 Photon OS 容器平台的 Console 畫面操作,通常都會透過 SSH 遠端登入進行維運管理的動作。然而,管理人員若安裝好 Photon OS 容器平台,並且組態設定好固定 IP 位址等網路資訊後,可能會發現雖然可以 SSH 遠端連線至 Photon OS 容器平台,但是卻無法使用 Root 管理者帳號登入,主要原因在於 Photon OS 容器平台的預設安全性設定所致。

首先,在預設情況下 Photon OS 容器平台的防火牆規則中,在安裝流程完畢後便會自動啟用並僅允許 SSH(TCP Port 22)能夠放行,然而對於 Linux 作業系統稍有管理經驗的管理人員便知,這是主機 SSH 遠端連線組態設定檔中不允許 Root 管理者帳戶遠端登入所致,而非防火牆規則未開啟所導致的問題。

倘若,管理人員希望能夠採用 Root 管理者帳號遠端登入 Photon OS 容器平台,請修改 SSH 組態設定檔「/etc/ssh/sshd_config」內容,將預設值從「PermitRootLogin no」修改為「PermitRootLogin yes」即可,也就是允許 Root 管理者帳號可以遠端登入 Photon OS 容器平台,接著再重新啟動 SSH 系統服務即可套用生效。
請注意!! 直接開啟允許 Root 管理者帳號遠端登入管理,將為 Photon OS 容器平台帶來一定程度的安全性風險。再次提醒,管理任何作業系統的基本資安觀念,便是不該直接開放最高權限管理者帳號能夠遠端登入,而是應該建立具備同等權限或剛好需要進行維運權限的使用者帳號後,才進行開放遠端登入的動作。

圖 13、組態設定讓 Photon OS 容器平台可透過 Root 管理者帳號遠端登入進行管理





Docker 容器管理服務

對於 RHEL / CentOS 等 Linux 作業系統稍有維運經驗的管理人員來說,應該會覺得 Photon OS 容器平台的維運管理非常類似。同時,從 RHEL 7 / CentOS 7版本開始,管理系統服務的方式已經從傳統的 Runlevel(/etc/rc.d/init.d),改為新一代的 systemd(/etc/systemd/system)的方式進行系統服務的維運管理。

那麼在 Photon OS 容器平台中,管理人員只要使用「systemctl start docker」指令便可以啟動 Docker 容器管理服務,接著使用「systemctl enable docker」指令組態設定 Photon OS 容器平台,在每次開機或重新啟動後都能夠自動啟動 Docker 容器管理服務,最後便可以使用「systemctl status docker」指令來確認 Docker 容器管理服務的執行狀態、PID……等資訊。

圖 14、啟動 Docker 容器管理服務並確認執行狀態、PID……等資訊

接著,便可以透過「docker info」指令查詢 Docker 容器管理服務的運作資訊,例如,目前有多少容器執行中 / 暫停中 / 停止中、目前有多少容器映像檔、Docker Server 的版本、Docker 使用的虛擬網路、核心版本、Docker 容器管理服務的根目錄……等資訊。或是使用「docker version」指令,查詢目前使用的 Docker Client 及 Docker Server 版本以及使用的 API 及 Go 語言版本資訊。

圖 15、查詢 Docker 容器管理服務的運作資訊及使用版本資訊



執行第 1 個容器 Hello-World

至此,我們已經安裝好 Photon OS 容器平台並組態設定好網路資訊,同時也順利啟用 Docker 容器管理服務。那麼,我們開始來使用 Docker 容器管理技術建立第 1 個容器吧,我們將透過 Docker 容器環境執行並列出字串「Hello-World」

請鍵入「docker run hello-world」指令,稍後便會看到系統列出「Hello from Docker !」的字串以及相關文字資訊。事實上,我們可以看到從執行指令後,在第 1 行系統顯示的資訊中(Unable to find image 'hello-world:latest' locally),說明目前系統發現目前在本機 Docker 映像檔存放庫中並沒有「Hello-World」這個 Docker 映像檔,所以系統就透過預設的系統設定連線至網際網路的 Docker Hub 公開映像檔存放庫,下載 Hello-World 這個容器映像檔(此時將自動執行「docker pull」的動作),最後執行列出字串的動作。

圖 16、建立及執行第 1 個容器 Hello-World

接著,可以透過「docker images」指令,查看目前 Photon OS 容器平台中 Docker 映像檔資訊。此外,管理人員可以再次執行「docker info」指令查詢,這次便會發現 Containers 欄位的變化「0 -> 1」,表示目前 Photon OS 容器平台中有 1 個容器,以及 Stopped 欄位的變化「0 -> 1」表示目前狀態為停止的容器為 1 個,和 Images 欄位的變化「0 -> 1」表示目前共有 1 個 Docker 容器映像檔。同時,預設下載的 Docker 容器映像檔,將會存放在 Docker 根目錄「/var/lib/docker」當中。
為何我們執行 Hello-World 容器後狀態不是 Running而是 Stopped? 因為,Hello-World 這個容器的生命週期就是執行完列印字串 Hello-World 的動作後便結束,所以順利列印出字串後便進入 Stopped 狀態。

圖 17、查詢 Photon OS 容器平台中 Docker 映像檔資訊



執行第 2 個容器 Nginx 網頁伺服器

經過簡單的容器執行操作熱身後,接著實作在實務 Docker 容器環境當中常會使用到的 Nginx 網頁伺服器。值得注意的是,因為在本文實作環境中採用「Photon Full」安裝選項,所以在預設情況下已經自動啟動 httpd 系統服務並佔用 TCP Port 80,必須要把 httpd 系統服務停止並且停用自動啟動機制,以避免與稍後我們所要實作的 Nginx 網頁伺服器容器環境發生 Listen Port 衝突的情況。

首先,我們執行「netstat -tunpl | grep ":80"」指令後可以看到,系統確實已經啟動 httpd 系統服務並佔用 TCP Port 80,所以請執行「systemctl stop httpd」指令停止 httpd 系統服務,此時 httpd 系統服務已經停止並釋放 TCP Port 80 的使用權。

接著,執行「systemctl disable httpd」指令,將 httpd 系統服務在開機或重新啟動時會自動啟動的機制關閉,以避免跟 Nginx 網頁伺服器容器發生 Listen Port 衝突的情況,然後執行「systemctl list-unit-files --type service | grep httpd」指令,確認停用 httpd 系統服務的動作是否套用生效。

圖 18、停止及停用 httpd 系統服務,以避免跟 Nginx 網頁伺服器容器環境發生衝突的情況

確認停止及停用 httpd 系統服務之後,便可以鍵入「docker run -d -p 80:80 vmwarecna/nginx」指令,執行下載及執行 Nginx 網頁伺服器容器環境的動作,同樣的可以看到目前 Photon OS 容器平台並沒有 Nginx 網頁伺服器容器映像檔,所以仍自動透過預設的系統設定連線至網際網路的 Docker Hub 公開映像檔存放庫,下載 vmwarecna 下的 nginx 容器映像檔並執行它。

完成下載及執行 Nginx 網頁伺服器容器環境的動作後,首先我們執行「docker images」指令可以看到,目前 Photon OS 容器平台列出的 Docker 容器映像檔清單中,多出了 vmwarecna/nginx項目並且佔用的儲存空間為 93.48 MB。

然後,請執行「docker ps」指令後可以看到,在 PORTS 欄位有顯示「0.0.0.0:80 -> 80/tcp」的資訊,這表示當外部連線請求送至 Photon OS 容器平台後,將會透過 Docker 容器虛擬網路環境的 Bridge 機制,轉導向連線請求至 Nginx 網頁伺服器容器的 TCP Port 80。

圖 19、下載並執行 Nginx 網頁伺服器容器環境

然而,管理人員可能會發現開啟瀏覽器,嘗試連結 Photon OS 容器平台的 TCP Port 80 時,卻無法看到應該看到的 Nginx 網頁伺服器的歡迎頁面。主要原因在於,預設情況下 Photon OS 容器平台的 IPTables 防火牆規則,僅允許放行 TCP Port 22 的流量其餘則未開放並全部阻擋,所以才無法看到 Nginx 網頁伺服器的歡迎頁面。

圖 20、IPTables 防火牆封包進出、轉送、狀態等運作架構示意圖

因此,在本文實作環境中我們開放允許 TCP Port 80 的流量通過 IPTables 防火牆,以及在實務上常會用來判斷 Photon OS 容器平台是否 ping 回應的 ICMP 通訊協定。請修改「/etc/systemd/scripts/iptables」IPTables 防火牆組態設定檔,在允許放行 SSH 流量通過的防火牆規則下方,加上如下 2 行允許放行 TCP Port 80 ICMP 通訊協定的 IPTables 防火牆規則後存檔離開。
iptables -A INPUT -p icmp -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -j ACCEPT


最後,執行「systemctl restart iptables」指令重新啟動 IPTables 防火牆系統服務後,新的 IPTables 防火牆規則便套用生效。此時,便可以使用「systemctl status iptables」指令確認重新啟動後,IPTables 防火牆系統服務是否正常運作中,以及使用「iptables -L」指令列出目前 IPTables 防火牆規則,便可以看到允許放行 TCP Port 80 及 ICMP 通訊協定的 IPTables 防火牆規則已經套用生效。

圖 21、放行 TCP Port 80 及 ICMP 通訊協定並確認 IPTables 防火牆規則已經套用生效

確認 IPTables 防火牆允許 TCP Port 80流量通過後,此時便可以開啟瀏覽器再次確認能否看到 Nginx 網頁伺服器的歡迎頁面,結果當然是沒有問題可以順利看到 Nginx 網頁伺服器歡迎頁面。

圖 22、確認是否能夠順利看到 Nginx 網頁伺服器歡迎頁面





結語

透過本文的說明及實作相信讀者已經了解,針對 VMware 虛擬化運作環境最佳化的 Photon OS 容器平台,不管是在建立、執行、管理容器都非常簡單易用,確實可以協助企業及組織在將工作負載邁向微服務的路上更加輕鬆。

[站長開講] DevOpsDays Taipei 2017

$
0
0

活動簡介

Devopsdays是全球性的技術系列盛會,由各地城市組織、發起自己的 Devopsdays,探討包含軟體開發、IT架構維運,以及兩者之間交互的議題。常見的議程包括了自動化、測試、資訊安全以及組織文化。

DevOpsDays Taipei 在 2017 年 9 月首次舉行,透過在地社群 Agile Community TW、DevOps Taiwan 以及 IT 媒體 iThome 聯手之下,邀集台灣在 DevOps 領域的技術專家,共同推動 DevOps 這波技術與文化的轉型運動,與世界脈動接軌。



活動資訊




活動內容




[站長著作] 微軟 S2D 軟體定義儲存技術實戰

$
0
0

[天瓏 - 新書預購特價 7.8 折]💪

即日起,天瓏書局針對本書推出預購特價 7.8 折活動,有興趣的朋友可以參考看看。😁



書籍簡介

還在為了規劃儲存設備規模大小而苦惱嗎?
實作微軟 S2D 軟體定義儲存技術,一次整合運算及儲存資源

Microsoft S2D 軟體定義儲存技術,最小運作規模只要 2 台 S2D 叢集節點主機,即可建構出不輸中階儲存設備的 IOPS 儲存效能,並且 S2D 單一叢集最大規模 16 台及高達 600 萬 IOPS 儲存效能。同時,整合 S2D HCI 超融合部署架構,能夠一次解決 VM 虛擬主機和 Container 容器及其他工作負載,在運算及儲存資源方面整合的煩惱。


軟體定義資料中心(Software Defined Data Center,SDDC)

根據 Gartner 的研究結果顯示,過往 IT 人員所熟知及打造 Mode 1 現代化資料中心(Data Center Modernization)所遭遇的挑戰,主要在於管理及打造企業或組織中有關運算資源、儲存資源、網路資源、硬體設備、虛擬化技術⋯⋯等虛實整合。

隨著企業及組織朝向商業數位化模式不斷發展,知名的市調機構 Gartner 所屬分析師在 2015 下半年期間,針對 100 位企業及組織中負責領導IT基礎架構的主管調查結果顯示,有 2/3 以上的企業及組織開始建構及整合 Mode 2敏捷式 IT 基礎架構(Infrastructure Agility)

所謂「基礎架構敏捷化」(Infrastructure Agility),便是著重於IT基礎架構中「Mode 2」的部分也就是因應商業數位化的需求,這些範圍包括:

  • 將敏捷(Agility)最佳實務概念,充分導入至現代化資料中心的IT基礎架構當中,讓工 作流程及技術人員能夠快速因應現在新興的商業數位化需求。
  • 深入了解各項使用案例、決策考量、微服務(Micro-Service)、容器引擎⋯⋯等最佳實務 概念。
  • 將單純的虛擬化運作環境,發展成軟體定義(Software-Defined)的基礎架構以達成敏捷 的目的,也就是打造「軟體定義資料中心」(Software-Defined Data Center,SDDC)。
  • 充份利用彈性的雲端基礎架構部署新世代應用程式(Next-Generation Applications)。 
  • 建構邊緣資料中心(Edge Data Center)平台,以便因應商業數位化及 IoT 物聯網。 
  • 加強巨量資料分析、Web 應用程式、IoT 物聯網⋯⋯等部署作業,以便因應現代化行動至 上的商務模式。

簡單來說,不管是 Mode 1 的現代化資料中心或是新興 Mode 2 的基礎架構敏捷化,在企業或組織的資料中心內硬體資源的組成,不外乎就是「CPU、記憶體、儲存、網路」等 4 大硬體資源,而這 4 大硬體資源又可以簡單劃分為3大類也就是運算、儲存、網路。

那麼,接下來我們來看看 Mode 2 基礎架構敏捷化定義中,透過軟體定義(Software-Defined)的運作概念,如何將「運算、儲存、網路」等硬體資源,轉換成 SDC 軟體定義運算、SDS 軟體定義儲存、SDN 軟體定義網路,幫助企業及組織打造成快速因應商業數位化需求的強大IT 基礎架構,最終達成 SDDC 軟體定義資料中心的目標。

軟體定義運算(Software Defined Compute,SDC)

軟體定義運算(Software Defined Compute,SDC),與 SDS 軟體定義儲存及 SDN 軟體定義網路技術相較之下,為基礎架構硬體資源當中最為成熟的技術。事實上,許多企業及組織在建構軟體定義式的IT基礎架構時,最先投入的便是 SDC 軟體定義運算的部分。

然而,談到 SDC 軟體定義運算便無法不談到 x86 伺服器虛擬化(x86 Server Virtualization) 技術,在 x86 伺服器虛擬化技術尚未風行前,企業及組織的應用程式及營運服務便直接運作在 x86 硬體伺服器上,這樣的運作架構雖然讓應用程式及營運服務,可以直接獨佔整台 x86 硬體伺服器所有硬體資源,所以能夠提供良好的工作負載能力。但是,卻容易產生「供應商鎖定」(Vendor Lock-in)的情況,舉例來說,倘若原本的應用程式及營運服務運作於 Dell 硬體伺服器上,但是該台 x86 硬體伺服器發生故障損壞事件時,需要將其上的應用系統或營運服務遷移至它牌硬體伺服器時(例如:HPE 或 Lenovo)是非常困難的。

事實上,談到虛擬化技術一般 IT 管理人員通常都會聯想到 VM 虛擬主機,然而這個情況從 2013 年 Docker 的出現而發生重大的改變。其實,Docker 並非是「容器」(Container)技術,而是一項用來管理及調度容器環境的技術,讓 IT 管理人員能夠不用費心處理容器的管理作業,便能達到輕量級作業系統虛擬化解決方案的目的。

微軟官方也在 Windows Server 2016 雲端作業系統中,與 Docker 合作推出 Windows Server Container 及 Hyper-V Container 技術,讓 Hyper-V 虛擬化平台成為同時運作 VM 虛擬主機及 Container 容器的最佳運作環境,輕鬆幫助管理人員達成 Bimodal IT的雙重 IT 基礎架構,幫助企業及組織在傳統及新興架構之間找到最佳平衡點。

軟體定義儲存(Software Defined Storage,SDS)

軟體定義儲存(Software Defined Storage,SDS),為企業及組織帶來儲存資源的潛在好處,便是能夠提升靈活性並降低整體維運成本。因此,企業及組織的 CXO 們應尋找及確認能夠更好提供「總體擁有成本」(Total Cost of Ownership,TCO)的 SDS 軟體定義儲存解決方案,同時選擇的 SDS 解決方案必須具備效率及可擴充性等特性,以便因應不斷增加的資料量並且能夠擺脫儲存設備的硬體限制。

目前,在 SDS 軟體定義儲存解決方案市場中尚未有明確的市場領導者出現。雖然,SDS 軟體定義儲存解決方案具備可程式性及自動化等好處,但是仍須考量對於「運算」「網路」所造成的影響。同時,所建立的 SDS 儲存資源必須要能夠融入 IT 基礎架構中而非再以孤島的方式運作。

在微軟新世代 Windows Server 2016 雲端作業系統當中,SDS 軟體定義儲存技術是由 Windows Server 2012 R2 當中的 Storage Spaces 技術演化而來,在 Windows Server vNext 開發時期稱為 Storage Spaces Shared Nothing,在 Windows Server 2016 的正式名稱則為 S2D(Storage Spaces Direct)

軟體定義網路(Software Defined Network,SDN)

根據 CIO 的調查結果顯示,有 86% 的企業及組織 CIO 正計畫將內部資料中心及基礎架構進入 Bimodal IT 環境(相較於往年增加 20%),透過將過去 3 層式網路架構遷移至 Spine- Leaf 網路架構讓整體網路環境簡單化,並結合軟體定義網路(Software Defined Network,SDN)技術, 以 SDN Network Control Plane 來管理 Mode 2 的資料中心, 以便因應東-西(East-West)向的網路流量,並採用模組化架構以便輕鬆進行自動化部署,同時結合 Ansible、Puppet、Chef 等自動化組態設定工具,讓企業及組織的網路架構更適合 DevOps 環境,並往基礎架構即程式碼(Infrastructure as Code)的方向進前。

微軟新世代 Windows Server 2016 雲端作業系統當中,「軟體定義網路」(Software Defined Network,SDN)技術內的重要角色「網路控制器」(Network Controller),以及透過 SDN 技術管理「網路功能虛擬化」(Network Functions Virtualization,NFV)運作環境, 進而幫助企業或組織在資料中心內建構網路虛擬化環境。



網路購書





本書導讀

本書共有 7 個章節,由一開始簡介 SDDC 軟體定義資料中心願景開始,一路從 S2D 簡介及運作環境需求、S2D 底層運作架構、規劃設計最佳化 S2D 運作架構、實戰 S2D 環境建置、IOPS 效能測試、S2D 維運管理免煩惱。




第 1 章、SDDC 軟體定義資料中心

了解 SDDC 願景中重要的組成元件,包括 SDC 軟體定義運算、SDS 軟體定義儲存、SDN 軟體定義網路。

1.1 SDDC 軟體定義資料中心
1.2 軟體定義運算(SDC)
          1.2.1 x86 虛擬化技術
          1.2.2 全虛擬化技術
          1.2.3 半虛擬化技術
          1.2.4 CPU 硬體輔助虛擬化
          1.2.5 容器技術
          1.2.6 Microsoft SDC 軟體定義運算技術
          1.2.7 伺服器虛擬化技術市場趨勢
          1.2.8 基礎建設的重要性
1.3 軟體定義儲存(SDS)
          1.3.1 Microsoft SDS 軟體定義儲存技術
1.4 軟體定義網路(SDN)
          1.4.1 Microsoft SDN 軟體定義網路技術

圖 1-1、Mode 1 現代化資料中心示意圖



第 2 章、S2D 簡介及運作環境需求

深入剖析 S2D 部署模式 HCI 超融合式與融合式運作架構的差別,以及建構 S2D 環境時應該採用 RAID 還是 HBA、採用 SSD 或 HDD、採用一般 TCP/IP 或 RDMA、採用 NTFS 或 ReFS 檔案系統等議題。

2.1 S2D 運作架構及部署模式
          2.1.1 超融合式架構(Hyper-Converged)
          2.1.2 融合式架構(Converged)
2.2 Windows Server 2016 版本
          2.2.1 Windows Server 2016 軟體授權
          2.2.2 Windows Server 2016 標準版
          2.2.3 Windows Server 2016 資料中心版
2.3 如何配置硬體元件
          2.3.1 Microsoft HCL 硬體相容性
          2.3.2 採用 HBA 控制器或 RAID 卡?
          2.3.3 採用 DAS / JBOD / NAS / SAN 儲存設備?
          2.3.4 採用 SSD 固態硬碟或 HDD 機械式硬碟?
          2.3.5 採用 TCP/IP 乙太網路或 RDMA?
          2.3.6 採用 NTFS 或 ReFS 檔案系統?

圖 2-20、啟用 RDMA 特色功能,可提升 2 倍的 IOPS 儲存效能



第 3 章、S2D 運作架構

深入剖析 S2D 底層運作架構元件,例如:SSB 軟體式儲存匯流排、SSB 頻寬管理機制、SBC 儲存匯流排快取機制、Storage Pool、ReFS Real-Time Tiering、SMB Direct、RoCE、iWARP、Infiniband、SMB MultiChannel 等技術內容。

3.1 S2D 儲存堆疊運作架構
          3.1.1 SSB(Software Storage Bus)
          3.1.2 SBC(Storage Bus Cache)
          3.1.3 Storage Pool
          3.1.4 ReFS Real-Time Tiering
3.2 SMB 3
          3.2.1 SMB Direct(RDMA)
          3.2.2 RoCE
          3.2.3 iWARP
          3.2.4 Infiniband
3.3 SMB 多重通道
3.4 容錯及儲存效率
          3.4.1 鏡像(Mirror)
          3.4.2 同位(Parity)
          3.4.3 混合式復原(Mixed Resiliency)

圖 3-10、Hybrid 儲存架構資料快取示意圖



第 4 章、S2D 規劃設計

一步一步帶領你挑選 CPU 處理器、記憶體、NVMe 快閃儲存、SSD 固態硬碟、HBA 硬碟控制器、RDMA 網路卡、10GbE 網路交換器、了解 SSD 與 HDD 比例原則、S2D 叢集 大/中/小 型運作規模等最佳配置建議。

4.1 S2D 運作規模大小及限制
4.2 如何挑選實體伺服器硬體元件
          4.2.1 如何挑選 CPU 處理器
          4.2.2 如何挑選 RAM 規格
          4.2.3 如何挑選 SSD 固態硬碟
          4.2.4 SSD 與 HDD 如何搭配及比例原則
          4.2.5 如何挑選 HBA 硬碟控制器
          4.2.6 如何挑選 RDMA 網路卡
          4.2.7 如何挑選網路交換器
4.3 實體伺服器環境及數量建議
          4.3.1 小型運作規模
          4.3.2 中型運作規模
          4.3.3 大型運作規模

圖 4-19、Hybrid 儲存架構配置示意圖



第 5 章、S2D 安裝及設定

手把手帶領你建構 S2D 運作環境,包括安裝 Windows Server 2016、設定 10GbE 網路交換器、啟用 DCB/PFC 特色功能、啟用 SMB Direct(RDMA)、啟用 SMB QoS 原則、建立 SET ( Switch Embedded Teaming )、檢查 RDMA 運作狀態、檢查 SMB MultiChannel 運作狀態、建立 S2D 叢集、啟用 Storage Spaces Direct 機制、建立三向鏡像磁碟區、建立雙同位磁碟區、建立雙向鏡像磁碟區、建立單同位磁碟區、建立混合式復原磁碟區、部署 VM 虛擬主機、Storage Pool 最佳化等最佳化組態配置。

5.1 安裝 Windows Server 2016 作業系統
          5.1.1 系統基礎設定
          5.1.2 安裝相關角色及功能
5.2 設定 10GbE 網路交換器
          5.2.1 啟用 DCB / PFC 功能
5.3 啟用 SMB Direct(RDMA)功能
          5.3.1 啟用 SMB 網路 QoS 原則
          5.3.2 建立 SET 網路卡小組
          5.3.3 檢查 RDMA 運作狀態
5.4 建構 S2D 軟體定義儲存環境
          5.4.1 加入網域
          5.4.2 確保已安裝最新安全性更新
          5.4.3 檢查 SMB Direct 及 SMB MultiChannel 運作狀態
          5.4.4 執行容錯移轉叢集檢查工具
          5.4.5 建立容錯移轉叢集
          5.4.6 設定容錯移轉叢集仲裁機制
          5.4.7 啟用 Storage Spaces Direct 機制
          5.4.8 建立三向鏡像磁碟區
          5.4.9 建立雙同位磁碟區
          5.4.10 建立雙向鏡像磁碟區
          5.4.11 建立單同位磁碟區
          5.4.12 建立混合式磁碟區
5.5 部署 VM 虛擬主機
5.6 Storage Pool 最佳化

圖 5-119、在 S2D 叢集中建立 5 種不同「容錯機制 / 儲存效率 / 容錯網域」需求的磁碟區



第 6 章、S2D 效能測試

從了解 IOPS 儲存效能的估算開始,慢慢深入如何進行 IOPS 儲存效能測試,並透過開源工具 VMFleet 進行 S2D 環境 IOPS 儲存效能測試。

6.1 什麼是 IOPS?
6.2 儲存效能測試基礎概念
6.3 VMFleet 效能測試工具
6.4 IOPS 效能測試

圖 6-41、採用「三向鏡像」在壓測情境 2 時 S2D 叢集的儲存效能表現



第 7 章、S2D 維運管理

深入了解 S2D 如何因應各式各樣硬體故障事件、如何查詢 S2D 運作健康狀態、S2D 叢集節點主機如何進入維護模式、如何整合 CAU 叢集感知更新機制安裝微軟最新安全性更新、實戰水平擴充 S2D 叢集運作規模(2台 → 3台 → 4台)、實戰擴充 CSVFS 磁碟區空間等維運管理議題。

7.1 S2D 如何因應硬體故障事件
          7.1.1 發生 1 個錯誤網域時
          7.1.2 發生 2 個錯誤網域時
          7.1.3 發生 3 個錯誤網域時
7.2 S2D 健康狀態
7.3 S2D 維護模式
          7.3.1 S2D 叢集節點主機進入維護模式
          7.3.2 S2D 叢集節點主機離開維護模式
          7.3.3 CAU 叢集感知更新
7.4 水平擴充 S2D 叢集運作規模
          7.4.1 擴充 S2D 叢集規模(2 台 → 3 台)
          7.4.2 擴充 S2D 叢集規模(3 台 → 4 台)
7.5 擴充 CSVFS 磁碟區空間

圖 7-6、發生 2 個錯誤網域時,S2D 叢集仍然能夠正常運作資料仍可持續存取



附錄、S2D 解決方案

最後,我們進一步介紹市場上各家硬體伺服器供應商的 S2D 解決方案。(供應商名稱以英文字母順序排序)。

A.1 簡介 S2D 解決方案
A.2 Dell EMC – S2D 解決方案
A.3 Fujitsu – S2D 解決方案
A.4 HPE – S2D 解決方案
A.5 Intel – S2D 解決方案
A.6 Lenovo – S2D 解決方案
A.7 QCT – S2D 解決方案
A.8 Supermicro – S2D 解決方案

圖 A-1、支援 S2D 軟體定義儲存技術硬體伺服器清單

139 期 - 共用系統核心資源,玩轉 Windows Server 容器

$
0
0

網管人雜誌

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



文章目錄

前言
Windows 容器類型
Windows 容器運作環境需求
實戰架設 Windows Server 容器環境
          下載及安裝 Docker 運作環境
          下載 Windows Server 基礎容器映像檔
          部署第 1 個 Windows Server 容器 - Hello World
          部署第 2 個 Windows Server 容器 - IIS
客製化 Windows Server 容器
          重新建立新的容器映像檔
          推送容器映像檔至 Docker Hub
          測試客製化的 IIS 容器
結語





前言

在 2013 年時,有家名為 dotCloud 提供 SaaS 服務的公司,在該公司內有項名稱為 Docker 的業餘專案,它是使用 Google 的 Go 語言進行實作。後來,dotCloud 公司讓此專案加入 Linux 基金會並在 GitHub 進行推廣及維護,此專案迅速受到廣大開發人員的喜愛同時也讓 DevOps 議題捲起更大的浪潮,甚至 dotCloud 公司後來直接改名公司名稱為 Docker Inc。

Docker 容器管理技術如此受歡迎的主要原因之一,在於過去最困擾開發人員與維運人員的部分便是快速建立完備的開發環境,舉例來說,當開發人員需要某些開發環境時,企業或組織的維運人員便依需求建立 VM 虛擬主機、安裝作業系統、組態設定網路環境……等,接著再交由開發人員安裝相關應用程式或載入函式庫……等,此時才準備好整個開發環境,而 Docker 的出現剛好能夠解決這個困擾已久的問題。
Docker 容器管理技術,已經在 DockerCon 2017 大會上由 Docker 創辦人兼技術長 Solomon Hykes 發佈說明,從今天開始 GitHub 上原有 Docker 專案的程式碼、運作元件……等,都屬於新的開放原始碼專案「Moby」。

事實上,「容器」(Container)技術早已出現許久,而 Docker 則是讓容器管理這項工作任務便得容易操作及管理。一開始,Docker 容器管理技術普遍只能運作在 Linux 環境中,而微軟自從新任執行長 Satya 上任並大力擁抱開放原始碼之後,也在新一代的 Windows Server 2016 雲端作業系統中與 Docker 公司合作,打造出在 Windows Server 2016 作業系統中原生執行 Docker 引擎的容器管理環境。

雖然,在 Windows Server 2016 作業系統中已經成功打造 Docker 容器管理環境,但是整個 Docker 容器管理實作技術與 Linux 作業系統環境是完全不同的。簡單來說,Linux 容器映像檔並無法運作在Windows Server Container 容器環境內,而 Windows 容器映像檔也無法運作在 Linux Container 容器環境中,根本原因是採用「不同 API」(Windows API vs Linux API)的運作環境,那麼我們來看看有哪些根本上的不同:

Linux 容器環境
  • Control Group:控制群組,針對共享資源進行隔離並管控硬體資源的使用,例如,記憶體、檔案快取、CPU、磁碟 I/O……等資源使用率的管理。
  • Namespaces:命名空間,確保每個容器都有單獨的命名空間,讓容器之間的運作互相隔離不受任何影響。
  • AUFS:檔案系統,不同容器之間可以共享相同基礎的檔案系統層,實現分層功能並將不同目錄掛載到同一個虛擬檔案系統中。


Windows 容器環境
  • Job Objects:類似 Linux 容器環境中的控制群組機制。
  • Object Namespace、Process Table、Networking:類似 Linux 容器環境中的命名空間機制。
  • Compute Service:作業系統層級的運算服務層。
  • NTFS:檔案系統,每個運作的容器各自擁有 1 份 NTFS 分區表,搭配虛擬區塊儲存裝置建立容器多層式檔案系統,接著再利用 Symlink 機制把不同層級的檔案對應到 Host 環境檔案系統內的實際檔案,以便減少虛擬區塊儲存裝置所占用的儲存空間。

圖 1、Linux 與 Windows 容器環境運作架構示意圖
在 DockerCon 2017 大會上,同時發佈「LinuxKit」這個全容器化的 Linux 技術環境,希望打破不同作業系統平台(Windows 與 Linux)、虛擬化環境(VMware、KVM……等)、雲端環境(Google Cloud、AWS、Azure、Bluemix……等)、硬體(Intel 處理器、ARM 處理器、桌上型主機、筆記型電腦、伺服器、IoT 裝置……等),皆能建立 Docker 容器管理環境。

此外在 Docker 版本的部分在 2017 年也有重大改變,從 2017 年 3 月開始 Docker 採用新的版本以及版本命名規則。首先,Docker EE(Enterprise Edition)取代舊有的 Docker CS(Commercially Supported)版本,而 Docker 開放原始碼版本重新命名為 Docker CE(Community Edition)。至於版本命名規則與 Ubuntu 的命名規則類似,將以西元的「年 . 月」的方式命名,例如,v17.03、v17.06、v17.09……等。

圖 2、Docker 版本命名規則示意圖





Windows 容器類型

在 Windows 容器環境中,包含 2 種不同的容器類型或稱「執行階段」(Runtimes),分別是「Windows Server 容器」(Windows Server Container)以及「Hyper-V 容器」(Hyper-V Container)

  • Windows Server 容器:透過程序和命名空間隔離技術提供應用程式隔離功能,讓運作於 Windows Server 容器環境中的容器能夠共用系統核心資源,這樣的運作方式與 Linux 容器環境類似。
  • Hyper-V 容器:享有獨立系統核心資源,採用經過最佳化程序的 VM 虛擬主機執行容器環境,有效擴充原有 Windows Server 容器所提供的隔離環境。值得注意的是,執行 Hyper-V 容器的 VM 虛擬主機並非傳統的 Hyper-V VM 虛擬主機,而是運作 Windows Server 容器的特殊 VM 虛擬主機,並且具備獨立的系統核心、Guest 運算服務、基礎系統執行程序……等。
圖 3、Windows Server 容器與 Hyper-V 容器運作架構示意圖





Windows 容器運作環境需求 

在 Windows 容器環境需求方面,採用 Windows Server 2016 雲端作業系統建立 Windows 容器環境時,不管採用的是 GUI 圖形介面版本、Server Core 文字介面版本,甚至是最精簡的 Nano Server 版本都同時支援「Windows Server 容器及 Hyper-V 容器」

但是,倘若採用 Windows 10桌面端作業系統欲建立 Windows 容器環境時,並不支援建立 Windows Server 容器運作環境,而是僅支援建立「Hyper-V 容器」運作環境,並且只有採用 Windows 10 專業版及企業版,並且安裝及啟用 Hyper-V 角色才提供建立 Hyper-V 容器運作環境。

此外,在 Windows 容器運作環境中具備 2 種容器映像檔,分別是 Windows Server Core 及 Nano Server 容器映像檔,然而並非所有作業系統版本都同時支援運作這 2 種容器映像檔。在下列表格當中,分別條列作業系統版本支援的 Windows 容器類型以及容器映像檔:

作業系統版本
Windows Server 容器
Hyper-V 容器
Windows Server 2016 GUI 圖形介面
Server Core / Nano Server
Server Core / Nano Server
Windows Server 2016 Server Core
Server Core / Nano Server
Server Core / Nano Server
Windows Server 2016 Nano Server
僅支援 Nano Server
Server Core / Nano Server
Windows 10 專業版/企業版
不支援
Server Core / Nano Server

值得注意的是,倘若管理人員希望在 Hyper-V 虛擬化平台中的 VM 虛擬主機,能夠同時運作 Windows Server 容器環境及 Hyper-V 容器環境的話,因為先前已經說明 Hyper-V 容器環境是運作特殊的 VM 虛擬主機,所以上層的這台 VM 虛擬主機必須啟用「巢狀式虛擬化」(Nested Virtualization)功能才行。

簡單來說,管理人員必須確保 Hyper-V 虛擬化平台符合運作巢狀式虛擬化機制,以便將「虛擬化擴充功能」(Virtualization Extensions)也就是底層硬體輔助虛擬化技術,傳遞給 Hyper-V 虛擬化平台上運作的 VM 虛擬主機當中的客體作業系統,達成 VM 虛擬主機中再生出 VM 虛擬主機的巢狀式虛擬化運作架構。
有關 Hyper-V 虛擬化平台建構巢狀式虛擬化環境的詳細資訊,請參考本刊雜誌第 133 期專題報導「實作 Hyper-V 巢狀虛擬化,測試研發效率大提升」

圖 4、Hyper-V 虛擬化平台巢狀式虛擬化運作架構示意圖





實戰架設 Windows Server 容器環境

下載及安裝 Docker 運作環境

首先,我們透過 OneGet Provider 機制,安裝 PowerShell 的 Docker 模組以便稍後 Windows Server 能夠運作 Docker 運作環境。請開啟 PowerShell 命令視窗,並鍵入「Install-Module -Name DockerMsftProvider -Repository PSGallery -Force」指令,系統便會自動由 PowerShell Gallery 中,下載及安裝 Docker-Microsoft PackageManagement,執行下載及安裝指令後,當 PowerShell 視窗出現「需要 NuGet 提供者才能繼續」的詢問訊息時,請按下「Y 鍵」以便繼續安裝程序。
Docker 運作環境,是由「Docker 引擎」(Docker Engine)「Docker 用戶端」(Docker Client)所組成。

接著,請鍵入「Install-Package -Name docker -ProviderName DockerMsftProvider -Force」指令,使用 PackageManagement 中的 PowreShell 模組安裝最新版本的 Docker 運作環境,當安裝程序完成後系統會提示你應該要重新啟動主機,以便 Windows Server 當中的 Docker 運作環境能夠套用生效,請鍵入「Restart-Computer -Force」指令重新啟動 Windows Server 主機。

圖 5、為 Windows Server 安裝 Docker 運作環境

當 Windows Server 主機重新啟動後,查詢 Windows Server 主機網路連線的部分,會發現多出「vEthernet(HNS Internal NIC)」的虛擬網路卡,並且 IP 位址為「172.x.x.x / 255.255.240.0」(本文實作環境 IP 為 172.27.144.1)。這個虛擬網路卡便是屆時 Docker 運作環境中容器虛擬網路的部分,後續我們再進行詳細說明。

圖 6、負責 Docker 運作環境中容器的虛擬網路

當 Windows Server 下載及安裝 Docker 運作環境後,便可以透過基礎操作指令來了解 Docker 運作環境的相關資訊,舉例來說,管理人員可以鍵入「docker info」指令,系統便會詳細顯示目前 Windows Server 主機的 Docker 運作環境資訊,包含運作中的容器數量、暫停狀態的容器數量、停止狀態的容器數量、容器虛擬網路類型、容器主機記憶體容量……等。倘若,希望查詢目前 Windows Server 主機的 Docker 版本資訊時,只要鍵入「docker version」指令即可,如操作結果所示本文實作環境中 Docker 引擎及 Docker 用戶端版本為「17.03.1-ee-3」

圖 7、查詢 Windows Server 主機的 Docker 運作環境版本資訊



下載 Windows Server 基礎容器映像檔

在 Windows Server 的容器運作環境中,有 2 種不同類型的基礎容器映像檔分別是 Windows Server Core 及 Nano Server。倘若,管理人員希望下載 Windows Server Core 容器映像檔,只要開啟 PowerShell 指令視窗後鍵入「docker pull microsoft/windowsservercore」指令即可,若是希望下載 Nano Server 容器映像檔,只要開啟 PowerShell 指令視窗後鍵入「docker pull microsoft/nanoserver」指令即可。

圖 8、下載 Windows Server Core 及 Naon Server 容器映像檔

事實上,當鍵入上述 2 行指令後,本地端的 Windows Server 主機便會至 Docker Hub 網站,下載由 Windows 官方建立的 Windows Server Core 及 Nano Server 容器映像檔,因此管理人員並不用擔心下載到被加入惡意程式的容器映像檔。

那麼,這 2 個下載的 Windows Server Core 及 Nano Server 容器映像檔將會佔用多少空間呢 ?此時,管理人員只要鍵入「docker images」指令即可查看,在本文實作環境中可以看到 Windows Server Core容器映像檔為「10.2GB」,而 Nano Server容器映像檔則是「1.02GB」

圖 9、查詢 Windows Server Core 及 Naon Server 容器映像檔佔用空間大小



部署第 1 個 Windows Server 容器 - Hello World

至此,Windows Server 容器運作環境已經準備完畢,管理人員可以直接從 Docker Hub 下載預先建立好的 Hello World 範例容器,以便部署及執行簡單的 Hello World 應用程式。請在開啟的 PowerShell 指令視窗中,鍵入「docker run hello-world:nanoserver」指令即可。由於,我們剛才已經先行下載好 Windows Nano Server 容器映像檔,所以不用再次下載 Nano Server 容器映像檔,因此你會發現執行這個 Hello World 容器的速度非常快速。

圖 10、部署及執行第 1 個 Windows Server 容器



部署第 2 個 Windows Server 容器 - IIS

在剛才的練習中,我們已經順利運作第 1 個 Windows Server 容器。接著,我們實作練習第 2 個最常使用的 Windows Server 容器「IIS 網頁伺服器」,請鍵入「docker run -d --name MyIIS -p 80:80 microsoft/iis」指令即可,此行指令中「-d」參數表示此執行的 IIS 容器在背景運作,而「--name MyIIS」則是給予此 IIS 容器的名稱,至於「-p 80:80」則表示將 Windows Server 主機的 Port 80,與執行運作的 IIS 容器 Port 80 進行對應的動作。

由於此 IIS 容器會使用 Windows Server Core 容器映像檔為作業系統基底,所以 Windows Server 主機若沒有 Windows Server Core 容器映像檔的話,便會需要花費額外的下載及安裝時間。在本文實作環境中,我們已經於剛才下載好 Windows Server Core 容器映像檔所以無須等待重下載及安裝時間,部署及執行 IIS 容器的動作完成後可以看到,此 IIS 容器佔用的空間大小為 10.5GB,也就是相較於 Windows Server Core 容器映像檔,加上 300MB 相關組態設定檔案。
事實上,倘若管理人員希望運作 Hyper-V 容器的話,只要加上「--isolation=hyperv」參數即可,當然前提是 Windows Server 主機已安裝及啟用 Hyper-V 角色。

圖 11、下載及執行基於 Windows Server Core 運作環境的 IIS 容器

在開始與剛才執行的 IIS 容器進行互動之前,管理人員可以先執行「docker ps」指令,查詢目前運作中的容器資訊,從執行結果可以看到目前 Windows Server 主機上運作的容器只有 1 個(透過 docker info 指令也能查詢容器運作狀態數量),並且可以看到容器 ID、容器映像檔、執行指令、容器建立時間、運作狀態、連接埠對應、容器名稱……等。

確認 IIS 容器仍持續運作中,接著執行「docker exec -i MyIIS cmd」指令進入 IIS 容器內執行互動作業,成功進行 IIS 容器互動模式後可以看到指令視窗中的提示字元,由原本的 PowerShell 變成命令提示字元。首先,請執行「del C:\inetpub\wwwroot\iisstart.htm」指令,刪除 IIS 容器內預設的歡迎頁面,然後執行「echo "This IIS Welcome page from Windows Server Container"> C: \inetpub\wwwroot\index.html」指令,將自訂字串訊息寫入 IIS 容器內的 IIS 歡迎頁面中。最後,便可以執行 exit 指令離開 IIS 容器互動模式回到 Windows Server 容器主機。

圖 12、進入 IIS 容器互動模式並自訂 IIS 歡迎頁面內容

完成 IIS 容器互動模式並自訂 IIS 歡迎頁面內容的動作後,請先確認 Windows Server 容器主機的防火牆規則中,是否已經允許 TCP Port 80 的網路流量能夠通過防火牆,接著請使用「別台主機」透過瀏覽器連接至 Windows Server 容器主機的 IP 位址,本文實作環境中 Windows Server 容器主機的 IP 位址為「http: //10.10.75.69」。此時,應該可以順利看到剛才我們所自訂的 IIS 歡迎頁面內容。
請注意,由於 Windows Server 容器虛擬網路 NAT 網路環境的關係,必須以「別台」主機透過瀏覽器才能確認能否瀏覽由 IIS 容器所提供的 IIS 歡迎頁面。倘若,從 Windows Server 容器主機採用「本機」的方式直接開啟瀏覽器,嘗試瀏覽由 IIS 容器所提供的 IIS 歡迎頁面時,將會發現是無法順利瀏覽的。

圖 13、順利看到剛才我們所自訂的 IIS 歡迎頁面內容

倘若,管理人員希望「停止」IIS 容器時,只要執行「docker stop < 容器名稱或容器 ID>」即可,後續希望再將 IIS 容器「啟動」時也只要執行「docker start < 容器名稱或容器 ID>」即可,若是希望「重新啟動」IIS 容器時請執行「docker restart < 容器名稱或容器 ID>」即可。
請注意,當容器的運作狀態為停止時透過「docker ps」指令是無法查詢到容器資訊的。此時,請執行「docker ps -a」便可以查詢到所有運作狀態的容器。

圖 14、針對容器進行停止、啟動、重新啟動等基本操作





客製化 Windows Server 容器

在剛才的實作練習中,我們都是執行官方預先提供的範例容器或下載及執行容器後再進行修改,接著我們將實作練習客製化 Windows Server 容器,依據企業及組織的運作需求自行打造符合內部運作環境的容器。



重新建立新的容器映像檔

以剛才我們所練習的 IIS 容器為例,請先執行「docker stop MyIIS」指令將 IIS 容器停止運作,使用「docker ps -a」指令確認 IIS 容器的運作狀態為「Exited」表示已經停止運作後,執行「docker commit MyIIS weithenn/myiis」指令,將剛才我們已經修改過內容的 IIS 容器,重新建立成新的容器映像檔並且客製化名稱為「weithenn/myiis」,重新建立容器映像檔的動作執行完成後,可以使用「docker images」指令進行確認。

圖 15、重新建立新的 IIS 容器映像檔並且客製化名稱為 weithenn/myiis



推送容器映像檔至 Docker Hub

重新建立 IIS 容器映像檔的動作執行完成後,我們可以將這個客製化的 IIS 容器映像檔推送至 Docker Hub,以便後續我們不管在哪一台 Windows Server 容器主機上需要使用此客製化 IIS 容器時,便能夠透過網際網路連線從 Docker Hub 網站下載後使用。

當然,管理人員必須先至 Docker Hub 網站註冊帳戶以便產生 Repositories 容器存放庫。確認 Docker Hub 帳戶註冊且運作無誤後,請回到 Windows Server 容器主機上執行「docker login」指令進行登入 Docker Hub 網站的動作,成功登入 Docker Hub 網站後執行「docker push weithenn/myiis」指令,將剛才重新建立 IIS 容器映像檔上傳至 Docker Hub 網站上。
請注意,預設情況下上傳至 Docker Hub 網站的容器映像檔為「公開」(Public),也就是公開給網際網路上的任何人下載使用,倘若管理人員希望這個容器為「私人」(Private)使用的話,請記得至 Docker Hub 網站針對此容器進行權限調整。
圖 16、上傳客製化的 IIS 容器映像檔至 Docker Hub 網站



測試客製化的 IIS 容器

順利將客製化後的 IIS 容器映像檔上傳至 Docker Hub 網站後,接著我們便可以測試是否能夠隨時由 Docker Hub 網站上,下載我們所客製化後的 IIS 容器映像檔並且執行部署的動作。首先,請執行「docker rmi weithenn/myiis」指令,將 Windows Server 容器主機中原有的 weithenn/myiis 容器映像檔刪除,並執行「docker images」指令再次確認 weithenn/myiis 容器映像檔是否已經刪除成功。

圖 17、將客製化的 IIS 容器映像檔刪除

確認已經 Windows Server 容器主機中原有的 weithenn/myiis 容器映像檔已經刪除後,便可以執行「docker pull weithenn/myiis」指令,讓 Windows Server 容器主機至 Docker Hub 下載剛才所上傳的 weithenn/myiis 容器映像檔,下載完成後便可以執行「docker run -d -p 80: 80 weithenn/myiis」指令,部署客製化過的 weithenn/myiis 容器映像檔,並執行「docker ps」指令確認 weithenn/myiis 容器是否運作中。

圖 18、至 Docker Hub 下載剛才所上傳的 weithenn/myiis 容器映像檔並進行部署作業





結語

透過本文的說明及實作練習,管理人員應該能夠體會到透過 Windows 容器技術,能夠以 Windows Server 容器提供類似 Linux 的容器環境,倘若需要更佳的容器隔離安全性的話則部署 Hyper-V 容器即可。同時,結合 Docker 容器管理技術,相信可以幫助企業及組織降低維運成本,同時也能降低資料中心維運人員的管理負擔。

[站長開講] VMware vSphere 伺服器虛擬化實戰班

$
0
0

活動資訊

日期: 2016 年 9 月 2 日 ~ 10 月 21 日
時間: 09:00 ~ 17:00
地點:資策會 (台中市南屯區公益路二段51號20樓)
報名:資策會課程 - VMware vSphere 伺服器虛擬化實戰班




課程大綱

VMware 虛擬化平台最佳硬體規劃

虛擬化實作環境建置(Nested VMs)

建置 VMware 虛擬化平台

  • 安裝及初始化 ESXi 虛擬化平台
  • 安裝及管理 vCenter Server
  • 建立 DataCenter、Cluster
  • 納管 ESXi 主機

建置虛擬網路環境

  • vSwitch、Port Group、Network Policy、VMkernel Port、NIC Teaming

VM 虛擬主機管理

  • 虛擬磁碟線上擴充(Disk Online Extend)
  • 記憶體空間熱新增(Memory Hot Add)
  • CPU熱新增(CPU Hot Add)
  • 備份及還原
  • P2V及V2V轉換

計畫性停機解決方案

  • 即時遷移(vMotion / DRS)
  • 儲存即時遷移(Storage vMotion / Storage DRS)
  • 無共用儲存即時遷移(vMotion Enhancements)

非計畫性停機解決方案

  • 高可用性(vSphere HA / Fault Tolerance)

[站長開講] Microsoft Azure IaaS 實戰班

$
0
0

活動資訊

日期: 2016 年 9 月 24 日 ~ 10 月 1 日
時間: 09:00 ~ 17:00
地點:資策會 (台中市南屯區公益路二段51號20樓)
報名:資策會課程 - Microsoft Azure IaaS 實戰班




課程大綱

Microsoft Azure 簡介
  • 全球資料中心
  • Portal 入口網站
  • 帳戶權限 & RBAC 委派管理
Microsoft Azure IaaS - 虛擬主機 (Virtual Machine)
  • 建立 VM 虛擬主機
  • 建立高可用性及負載平衡的 VM 
  • 建立 Windows / Linux VM (Depot) 虛擬主機
  • 上傳自行客製化的 VHD 檔進行部署
Microsoft Azure IaaS - 儲存體 (Blob Storage)
  • Page Blob / Block Blob
  • File 
  • Table
  • Queue
Microsoft Azure IaaS - 虛擬網路 (Virtual Network)
  • Site to Site VPN 及 Point to Site VPN
  • ExpressRoute
  • Traffic Manager
Microsoft Azure IaaS - 目錄服務 (Active Directory)
Microsoft Azure Backup 雲端備份
Microsoft Azure Site Recovery 雲端異地備援

140 期 - 新版 vSAN 6.6 大放利多輕鬆打造 SDS 儲存環境

$
0
0

網管人雜誌

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



文章目錄

前言
vSAN 技術發展歷史
vSAN 6.6 新功能
          安全性
          管理
          部署
          可用性
          效能
          vSAN 軟體授權
結語





前言

去年 11 月時,VMware 官方在 VMworld 2016 大會上正式發佈最新版本 VMware vSphere 6.5,並且正式宣佈 VMware Virtual SAN 6.5 一同推出。事實上,在 VMware 所擘劃的 SDDC 軟體定義資料中心未來藍圖當中,負責 SDS 軟體定義儲存解決方案的角色便是 VMware vSAN(Virtual SAN)。

雖然,距離最新第 5 代的 VMware vSAN 6.5 版本才短短間隔 5 個月的時間,VMware 官方便於 2017 年 4 月正式發佈第 6 代 VMware vSAN 6.6並且這次發佈的第 6 代 VMware vSAN 6.6 卻總共新增 23 項特色功能。

簡單來說,透過 VMware vSAN 軟體定義儲存技術,企業及組織可以將多台安裝 ESXi 虛擬化平台的 x86 實體伺服器,透過 VMware vSAN 把所有硬體伺服器上的「本機硬碟」(Local Hard Disk)匯整串連起來(例如,NVMe 快閃儲存、SSD 固態硬碟、HDD 機械式硬碟……等),建構出巨大的儲存資源集區。

同時,這個巨大的儲存資源集區還能夠運作 VM 虛擬主機及容器等工作負載,因此企業及組織在建構 VMware vSAN 軟體定義儲存環境之後,便能一次解決建置「運算 / 儲存」資源的難題,這也是目前非常熱門稱為「超融合式架構」(Hyper-Converged Infrastructure,HCI)的應用方式。

圖 1、VMware vSAN 運作架構示意圖





vSAN 技術發展歷史

事實上,當市場上都還著重在利用硬體架構打造出 HCI 超融合式架構時,VMware 官方便已經著手發展以軟體定義的方式打造儲存資源,所以第 1 代的 VMware vSAN 版本,便在 2014 年 3 月時隨著 vSphere 5.5 Update 1 版本開始內建,讓企業及組織能夠透過「標準的 x86 硬體伺服器」結合 vSAN 技術,自行打造出 SDS 軟體定義儲存解決方案,而無須購買特定廠商推出的專用硬體式 SDS 軟體定義儲存設備,避免日後發生「供應商鎖定」(Vendor Lock-in)的情況。
有關第 1 代 vSAN 運作架構及特色功能的詳細資訊,請參考本刊第 110 期《實戰部署 Virtual SAN 套用政策自動化搭配 VM》
圖 2、第 1 代 VMware vSAN 軟體定義儲存技術

經過 1 年後於隔年 2015 年 3 月,VMware 官方推出第 2 代 VMware vSAN 版本,並且隨著當時最新虛擬化平台版本 vSphere 6.0 一同發佈,同時讓 vSAN 版本直接與 vSphere 版本對齊成為 vSAN 6.0 版本(因為,原訂 vSAN 新版本號為 vSAN 2.0),避免因為版本不一致導致 IT 管理人員在規劃設計上的困擾。在第 2 代 vSAN 版本當中最重要的特色功能便是支援 All Flash運作架構,同時 vSAN 叢集規模與 vSphere 叢集一樣可達到 64 台節點主機。
有關第 2 代 vSAN 運作架構及特色功能的詳細資訊,請參考本刊第 114 期《動手建立 VSAN 6 儲存資源,實戰水平擴充與容錯網域》
圖 3、第 2 代 vSAN 軟體定義儲存技術開始支援 All-Flash 運作架構

緊接著半年後於 2015 年 9 月時,VMware 官方推出第 3 代 VMware vSAN 6.1 版本,在這個版本中最具代表性的特色功能便是「延伸叢集」(Stretched Cluster)「支援 2 Nodes」的運作架構。因此,透過 vSAN 延伸叢集運作架構在 2 個站台之間同步資料,有效解決過去傳統 VMware vSphere 叢集單一站台故障損壞的問題,透過支援 2 Nodes 的 vSAN 運作架構,讓企業或組織可以因應 ROBO(Remote Office / Branch Office),例如,遠端辦公室或分支辦公室的小型儲存資源需求。
有關第 3 代 vSAN 運作架構及特色功能的詳細資訊,請參考本刊第 120 期《VMware VSAN 延伸叢集,實作跨站點同步 HA 複寫》
圖 4、第 3 代 vSAN 技術開始支援延伸叢集及 2 Nodes 運作架構

再隔半年後於 2016 年 3 月,VMware 官方推出第 4 代 VMware vSAN 6.2 版本,在這個版本當中最重要的功能特色為 All Flash 運作架構,開始支援「重複資料刪除與壓縮」(Deduplication and Compression)「RAID 5/6 EC 編碼技術」(RAID 5/6 Erasure Coding),讓採用 All Flash 運作架構的企業及組織,能夠透過這 2 項重要的功能特色節省寶貴的快閃儲存空間。
有關第 4 代 vSAN 運作架構及特色功能的詳細資訊,請參考本刊第 124 期《概覽 VMware VSAN 6.2 新功能加強健康狀態監控》
圖 5、第 4 代 vSAN 技術開始支援重複資料刪除與壓縮技術

經過 8 個月後於 2016 年 11 月,VMware 官方在 VMware VMworld 2016 大會正式發佈第 5 代的 vSAN 6.5 版本,在這個版本當中最重要的功能特色為開始支援「iSCSI 目標服務」(iSCSI Target Service),讓企業及組織中必須依靠 iSCSI 啟動器連接儲存資源的傳統服務,也能夠輕鬆使用 vSAN 儲存資源。
有關第 5 代 vSAN 運作架構及特色功能的詳細資訊,請參考本刊第 134 期《VMware 第五代 SDS 技術 vSAN 6.5 新功能快覽》
圖 6、第 5 代 vSAN 技術開始支援 iSCSI 目標服務





vSAN 6.6 新功能

由於最新第 6 代 VMware vSAN 總共新增 23 項特色功能,因此本文將針對所有特色功能進行概要說明,在後續的專欄中再深入剖析各項特色功能並進行實戰演練。首先,我們可以將這些新增特色功能大致分類,分別為「安全性、管理、部署、可用性、效能」等 5 大類進行說明。



安全性

在第 6 代 vSAN 版本當中,關於「安全性」(Security)方面有 2 項新增特色功能,分別是「原生加密」(Native Encryption)「法務遵循」(Compliance)。主要原因在於,VMware 所擘劃的 SDDC 軟體定義資料中心願景當中,VMware vSAN 擔任 SDS 軟體定義儲存的重要角色,可以想見當企業及組織將大量的 VM 虛擬主機運作於 vSAN 環境中,同時 VM 虛擬主機內更存放著大量企業及組織的機敏資訊。

因此,確保 vSAN 儲存資源的安全性機制將相形重要,在新版 vSAN 6.6 運作環境中 VMware 達成 HCI 超融合基礎架構原生加密解決方案。簡單來說,這個加密解決方案是內建在 vSAN 軟體定義儲存技術內,只要在管理介面中進行相關組態設定後,便可以針對 vSAN Datastore 儲存資源進行「啟用 / 停用」加密機制。

同時,因為 vSAN 6.6 Native Encryption 加密機制,是座落在「Hypervisor 層級」而非 VM 虛擬主機層級的加密機制,所以 vSAN 6.6 Native Encryption 加密機制與「硬體無關」,因此無須依靠專用且昂貴的「加密磁碟」(Self-Encrypting Drives,SED),就可以輕鬆達成企業機敏資料加密的目的。

圖 7、新版 vSAN 6.6 達成 HCI 超融合基礎架構原生加密解決方案

使用 vSAN 6.6 原生加密機制注意事項:
  • vSAN 原生加密機制必須以「vSAN 叢集」為單位,進行 vSAN 原生加密運作機制的啟用及組態設定作業。
  • 當 IT 管理人員對 vSAN 叢集啟用原生加密機制後,系統將會採用「XTS AES 256」加密演算法對 vSAN Datastore 儲存資源中,「快取」(Cache)及「容量」(Capacity)層級的儲存資源進行加密保護。

圖 8、啟用 vSAN 原生加密運作機制


  • 由於 vSAN 原生加密運作機制,是座落在整體 vSphere 儲存堆疊架構中「裝置驅動層級」(Device Driver Layer)之上,所以不管是 vSAN 延伸叢集、vSAN 重複資料刪除、vSAN 壓縮、Erasure Coding……等特色功能,皆能協同運作不受任何影響。
  • vSAN 原生加密運作機制,與 vSphere 進階特色功能,例如,vSphere vMotion、vSphere DRS(Distributed Resource Scheduler)、vSphere HA(High Availability)、vSphere Replication……等特色功能,皆能協同運作不受任何影響。
  • vSAN 原生加密運作機制,符合「2-Factor Authentication(SecurID and CAC)」驗證機制,同時 vSAN 也是第 1 個通過 DISA / STIG 認可的 HCI 超融合解決方案。
  • 啟用 vSAN 原生加密運作機制的操作步驟,與啟用 vSphere 6.5 當中 VM 虛擬主機加密機制一樣,在運作環境中都必須要有「KMS(Key Management Server)」才行。同時,只要是符合 KMIP 1.1 標準的 KMS 供應商產品即可,例如,HyTrust、Gemalto、Thales e-Security、CloudLink、Vormetric……等。

圖 9、透過 vCenter Server 管理平台組態設定 KMS 加密伺服器


  • 雖然啟用 vSAN 原生加密運作機制的操作步驟非常簡單,但是當 IT 管理人員啟用 vSAN 原生加密機制之後,快取及容量層級儲存裝置的「磁碟格式」(Disk Format)將需要「重新格式化」,並且在啟用成功後可以透過 ESXi Shell 的「esxcli vsan storage list」指令進行確認,只要看到磁碟格式欄位顯示「Encryption: true」的訊息表示加密作業成功。值得注意的是,不管是「啟用或停用」vSAN 原生加密機制,因為必須將磁碟格式重新格式化,所以 vSAN 儲存資源若儲存資料量非常龐大時,將會花費大量的時間進行資料遷移作業。
  • 由於 vSAN 原生加密運作機制,將會使用 KMIP(Key Management Interoperability Protocol)通訊協定,在 vSAN 叢集節點主機與 KMS 加密伺服器之間進行溝通。因此,VMware vCenter Server 管理平台及 PSC 和其它 VM 虛擬主機,能夠直接在啟用原生加密機制的 vSAN Datastore 儲存資源中持續運作而不會中斷。
  • vSAN 原生加密運作機制,適用於 All-Flash 全快閃儲存及 Hybrid 混合儲存運作架構,並且與 KMIP 1.1 金鑰管理機制整合及協同運作。
  • vSAN 原生加密運作機制,目前僅支援新版第 6 代 vSAN 6.6的 vSAN Datastore 儲存資源,尚未支援其它舊版 vSAN Datastore(例如,vSAN 6.5…… 等)。
  • 在 IT 業界普遍的資訊安全準則中,通常都需要定期重新產生新的加密金鑰,以降低加密金鑰被進行暴力破解的危害風險。因此,當需要重新產生新的加密金鑰時,IT 管理人員只要登入 vSAN 管理介面,便可以透過簡單的組態設定重新產生新的加密金鑰。

圖 10、因應法規遵循要求定期重新產生新的加密金鑰



管理

在第 6 代 vSAN 版本當中,關於「管理」(Management)的部分共新增 9 項特色功能(如下所示),舉例來說,在過往的 vSAN 版本運作環境中,整個 vSAN 軟體定義儲存架構仍以 vCenter Server 管理平台為主,倘若 vCenter Server 發生故障損壞事件,或 vSphere Web Client 服務無法正常運作時,雖然不致影響運作在 vSAN 儲存資源上的 VM 虛擬主機,但是後續將無法進行任何管理動作,例如,觀看 vSAN 叢集節點主機的健康情況。

  • Proactive Cloud Health Checks
  • vSAN Configuration Assist
  • Hardware Lifecycle Management
  • Highly Available Control Plane for Health Checks
  • Health and Performance Monitoring
  • vRealize Management Pack for vSAN
  • Stretched Cluster Witness Replacement
  • Host Evacuation
  • vSAN API and PowerCLI


現在,新版 vSAN 叢集中的 vSAN 叢集節點主機將以分散式的方式運作,同時結合 vSAN 6.6 版本中「Highly Available Control Plane for Health Checks」管理功能,即便 vCenter Server 發生故障損壞事件或 vSphere Web Client 服務無法正常運作時,管理人員仍然可以透過 vSAN 叢集中的「任何 1 台」vSAN 叢集節點主機,使用每台 ESXi 主機都原生內建的 VMware Host Client 管理工具,隨時查看 vSAN 叢集的運作狀態。

當然,IT 管理人員也可以使用「esxcli vsan」指令,檢查 vSAN 叢集的健康情況以及進行相關組態設定作業,例如,容錯網域(Fault Domains)、儲存原則(Storage Policy)、iSCSI 目標服務(iSCSI Target Service)……等。

圖 11、透過原生內建的 VMware Host Client 管理工具隨時查看 vSAN 叢集的運作狀態



部署

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

  • Easy Install
  • Multicast Dependency Removed
  • Extensibility

圖 12、第 6 代 vSAN 擺脫舊版只能使用 Multicast 的限制

現在,建構第 6 代 vSAN 軟體定義儲存環境不再強迫採用多點傳送網路環境,可以直接使用企業及組織內部常用的「單點傳送」(Unicast)網路環境,讓 IT 管理人員可以更簡易的建構 vSAN 叢集,甚至是擴充 vSAN 叢集至延伸叢集運作架構都相對容易。

值得注意的是,倘若企業及組織原有的舊版 vSAN 運作環境,在升級過程中仍必須保持多點傳送網路環境,直到 vSAN 叢集中所有 vSAN 叢集節點主機都順利升級為 vSAN 6.6 版本之後,此時 vSAN 叢集將會自動將網路傳送方式改為單點傳送

圖 13、新版 vSAN 6.6 採用 Unicast 網路環境



可用性

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

  • Stretched Cluster Local Failure Protection
  • Stretched Cluster Site Affinity
  • Degraded Device Handling


現在,新版 vSAN 6.6 所建構的延伸叢集運作環境,可以整合本地端站台內的 RAID 1 或 RAID 5/6 機制,達到本地端站台故障保護同時也可以跨站台進行資料鏡像保護。因此,建構延伸叢集運作環境後,不管哪個站台因為發生外力不可抗拒的嚴重故障損壞事件時,都能確保另一邊的站台擁有完整的資料副本。

圖 14、延伸叢集本地端故障保護機制運作架構示意圖

管理人員只要登入 vSphere Web Client 管理介面,切換到儲存原則的組態設定頁面後,在 Storage Type 組態設定區塊中可以看到,預設情況下「Primary level of failures to tolerate」欄位設定值為「1」,表示在 vSAN 延伸叢集中的 2 個站台將會互相執行「鏡像」(Mirror)資料的動作,至於「Secondary level of failures to tolerate」欄位設定值為「1」,表示 vSAN 延伸叢集中 2 個站台所互相鏡像的資料要保留幾份,最後的「Failure tolerance method」欄位設定值為「RAID-5/6(Erasure Coding)」,表示 vSAN 叢集站台為採用 All Flash 的儲存架構配置。

圖 15、組態設定 vSAN 延伸叢集本地端故障保護機制

因此,透過 vSAN 原有延伸叢集的運作架構結合新版 vSAN 本地端故障保護機制,有效讓 vSAN 叢集提升叢集配置的彈性並最大化減少意外導致的停機時間,即便站台因為發生外力不可抗拒的嚴重故障損壞事件時,也能有效減少跨站台之間的傳輸流量。

值得注意的是,在規劃 vSAN 延伸叢集運作架構時,在 2 個資料站台之間的網路環境必須確保在「5 ms RTT」之內,至於 2 個資料站台與 vSAN Witness 站台之間則只要確保在「200 ms RTT」即可,同時這樣的 vSAN 叢集運作架構具備高彈性及高可用性,但是卻無須額外購買其它專用的硬體或軟體即可達成。



效能

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

  • Deduplication and Compression
  • Rebuild and Resynchronization Enhancements
  • Checksum
  • De-Staging
  • iSCSI

圖 16、新版 vSAN 支援 Intel 3D XPoint NVMe 快閃儲存及驚人的儲存效能表現



vSAN 軟體授權

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

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

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

圖 17、VMware vSAN 6.6 軟體授權特色功能清單

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

圖 18、vSAN for ROBO 運作架構示意圖

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





結語

透過本文的說明及實作相信讀者已經了解,在第 6 代最新 vSAN 6.6 版本當中有哪些特色功能,能夠幫助企業及組織建立更靈活、高擴充性、高可用性的 SDS 軟體定義儲存運作環境。並且,在後續的專欄文章中,我們將針對這些新增特色功能進行深入剖析及 Hands-On 實戰演練。

VMware vSAN 6.6 攻略 - 系列文章 (新增 Management 文章)

$
0
0

前言

日前 (2017/4/18),VMware 官方正式發佈 vSAN 第六代 VMware vSAN 6.6 Release資訊。雖然距離上一版 vSAN 第五代 VMware vSAN 6.5發佈才間隔短短五個月。但是,這次發佈的 vSAN 第六代總共新增 23 項特色功能!!

有關過去每一代 vSAN 版本的新增特色功能資訊,請參考站長歷來撰寫的 vSAN 專欄文章:
圖、VMware Virtual SAN版本演進及新增功能示意圖


那麼,接下來站長將不定期針對第六代的 vSAN 6.6深入剖析各項特色功能:

【簡介】(Introduction)




【安全性】(Security)




【管理】(Management)

在第 6 代 vSAN 版本當中,關於「管理」(Management)的部分共新增 9 項特色功能(如下所示),舉例來說,在過往的 vSAN 版本運作環境中,整個 vSAN 軟體定義儲存架構仍以 vCenter Server 管理平台為主,倘若 vCenter Server 發生故障損壞事件,或 vSphere Web Client 服務無法正常運作時,雖然不致影響運作在 vSAN 儲存資源上的 VM 虛擬主機,但是後續將無法進行任何管理動作,例如,觀看 vSAN 叢集節點主機的健康情況。
  • Proactive Cloud Health Checks
  • vSAN Configuration Assist
  • Hardware Lifecycle Management
  • Highly Svailable COntrol Plane for Health Checks
  • Health and Performance Monitoring
  • vRealize Management Pack for vSAN
  • Stretched Cluster Witness Replacement
  • Host Evacuation
  • vSAN API and PowerCLI



【部署】(Deployment)

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


【可用性】(Availability)

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



【效能】(Performance)

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



【軟體授權】(Software Licensing)

倘若,企業及組織使用的是舊有 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 Software Licensing

VMware vSAN 6.6 Journey (3) - Management

$
0
0

前言

在第 6 代 vSAN 版本當中,關於「管理」(Management)的部分共新增 11 項特色功能(如下所示),舉例來說,在過往的 vSAN 版本運作環境中,整個 vSAN 軟體定義儲存架構仍以 vCenter Server 管理平台為主,倘若 vCenter Server 發生故障損壞事件,或 vSphere Web Client 服務無法正常運作時,雖然不致影響運作在 vSAN 儲存資源上的 VM 虛擬主機,但是後續將無法進行任何管理動作,例如,觀看 vSAN 叢集節點主機的健康情況:


Management 新增特色功能

Proactive Cloud Health Checks

加入 VMware 客戶體驗改善計畫 (Customer Experience Improvement Program,CEIP),讓 VMware 為你提供更好的管理者體驗,例如,精簡故障排除、即時通知和建議、運作環境診斷……等。

圖、啟用CEIP 客戶體驗改善計畫

現在,管理人員可以在 vSAN Health 管理介面中,看到「Ask VMware」鈕只要按下後便能連結至 VMware KB (Knowledge Base) 知識庫。舉例來說,如下圖所示在 vSAN Health 管理介面中,看到「vSAN and non-vSAN disks with the same storage controller」的警告訊息時,當管理人員按下 Ask VMware 鈕之後,便會連結至 VMware KB 2129050 - Best practices when using vSAN and non-vSAN disks with the same storage controller文章,以便管理人員更深入了解這個警告訊息所代表的意義,進而調整組態設定達到最佳化配置。

圖、在 vSAN Health 管理介面中,線上查詢 VMware KB 知識庫



vSAN Configuration Assist

從 vSAN 6.6 版本開始,新增 vSAN Configuration Assist 運作機制,讓系統能夠檢查硬體相容性、老化測試、網路環境組態配置、vSAN 組態設定、Cluster 建議組態配置……等,確保管理人員所建置的 vSAN 6.6 軟體定義儲存環境,能夠有正確的組態設定、硬體配置、驅動程式。

圖、透過 vSAN Configuration Assist 運作機制,檢查整體組態配置情況

除了檢查機制之外,管理人員也可以透過 vSAN Configuration Assist 運作機制,驗證所建置的 vSAN 6.6 軟體定義儲存環境,整體的組態設定是否正確無誤,舉例來說,在 VMware Cluster 當中有 3 台 vSAN Node,但是 vSAN Configuration Assist 機制發現 vSAN Node,並沒有正確配置「vSAN vmknic」的部分所以產生錯誤訊息。

此時,管理人員可以按下「Create VMkernel Network Adapter」鈕,進行 vSAN Node VMkernel Port for vSAN的組態設定部分,或是按下「Ask VMware」鈕連結至 VMware KB 了解這個錯誤訊息的發生原因以及如何解決。

圖、透過 vSAN Configuration Assist 運作機制,確保組態設定正確無誤



vSphere Update Manager Integration (vSAN 6.6.1)

在過去的 vSAN 版本當中,管理人員倘若需要針對 vSAN Cluster 進行版本升級作業時,除了確保 vSAN Cluster 升級程序,以及確認 vSAN 硬體相容性 (例如,SAS, SATA, NVMe……等) 之外,執行版本升級作業必須管理人員手動處理才行。

現在,最新的 vSAN 6.6.1 當中,已經順利將 vSAN 版本升級作業整合至 VMware vSphere Update Manager 當中,只要管理人員確保 vSAN 硬體相容性 (例如,SAS, SATA, NVMe……等) 即可,整個版本升級過程交給 VMware vSphere Update Manager 自動化機制即可。

圖、透過 vSphere Update Manager 升級 vSAN 運作元件



Highly Available Control Plane for Health Checks

現在,新版 vSAN 叢集中的 vSAN 叢集節點主機將以分散式的方式運作,同時結合 vSAN 6.6 版本中「Highly Available Control Plane for Health Checks」管理功能,即便 vCenter Server 發生故障損壞事件或 vSphere Web Client 服務無法正常運作時,管理人員仍然可以透過 vSAN 叢集中的「任何 1 台」vSAN 叢集節點主機,使用每台 ESXi 主機都原生內建的 VMware Host Client 管理工具,隨時查看 vSAN 叢集的運作狀態。

圖、透過原生內建的 VMware Host Client 管理工具隨時查看 vSAN 叢集的運作狀態

當然,IT 管理人員也可以使用「esxcli vsan」指令,檢查 vSAN 叢集的健康情況以及進行相關組態設定作業,例如,容錯網域(Fault Domains)、儲存原則(Storage Policy)、iSCSI 目標服務(iSCSI Target Service)……等。

圖、透過 esxcli vsan 指令工具查看 vSAN 叢集的運作狀態



Health and Performance Monitoring

vSphere Web Client 管理介面中,也可以透過 vSAN Health 機制查詢 vSAN 運作環境中,包括控制器佇列深度、All-Flash 運作架構環境檢查、Hybrid 運作架構環境檢查、監控、告警、vSAN 加密……等健康情況。

圖、vSAN Health 健康狀態偵測

此外,透過效能監控機制也能夠快速了解 vSAN 運作環境的效能資訊,包括,監控 iSCSI 儲存效能、網路卡吞吐量、每秒封包傳輸速率、每秒封包遺失率……等效能指標。

圖、查看 vSAN Node 網路卡吞吐量



Performance Diagnostics (vSAN 6.6.1)

透過效能診斷機制,管理人員可以選擇進行效能診斷的基準指標,例如,最大吞吐量、最小延遲時間、時間範圍……等。此外,管理人員還可以透過 HCIBench這個 API Level的效能診斷機制,進一步查詢效能診斷的詳細資訊。

值得注意的是,必須加入 CEIP 客戶體驗改善計畫,並且啟用 vSAN Performance Service機制之後才能使用此特色功能。

圖、vSAN 效能診斷示意圖



vRealize Operations Management Pack for vSAN

管理人員透過 VMware vRealize Operations管理平台,可以有效達到簡化及 IT 自動化維運管理的目的,並且透過 vRealize Operations Management Pack for vSAN為 vSAN 軟體定義儲存運作環境,提供更深入剖析各項功能以及各項指標協助監控,有效幫助管理人員加速故障排除及 Root Cause 的分析作業。

圖、透過 vRealize Operations 管理平台深入監控 vSAN 運作環境



Stretched Cluster Witness Replacement

從 vSAN 6.6 版本開始,可以在 Stretched Cluster 組態設定中更容易的擴充「見證主機」(Witness Host),舉例來說,在 vSAN Cluster 的運作環境中見證主機發生故障損壞,此時管理人員可以很容易的透過 vSphere Web Client 管理介面按下「Change witness host」鈕,然後選擇採用新的見證主機即可。

圖、更換見證主機



Host Evacuation

在 vSAN 6.6 版本當中內建「預先檢查」(Pre-Check)的機制,可以確保 vSAN Node 退出叢集、vSAN Node 進入維護模式、vSAN Node 刪除磁碟或磁碟群組……等狀態發生時,預先檢查是否會影響到 vSAN Cluster 的正常運作。

圖、vSAN Node 預先檢查機制



Storage Device Serviceability (vSAN 6.6.1)

在過去的 vSphere 運作環境中,當採用 RAID 控制器的 ESXi Host 硬碟發生問題時便可以透過,驅動損壞硬碟 LED 燈亮的方式快速找出故障損壞硬碟。但是,驅動損壞硬碟 LED 燈亮的方式在過去的 vSAN 運作環境中,因為不支援 HBA 或 Pass-Throuth控制器而無法使用。

現在,最新的 vSAN 6.6.1版本當中,驅動損壞硬碟 LED 燈亮的方式已經支援 HBA 或 Pass-Throuth 控制器,現在 vSAN Node 硬碟發生問題時管理人員便能快速找出故障損壞硬碟。舉例來說,在 HPE DL G9 / ML G9系列的伺服器已經正式支援此功能。

圖、驅動損壞硬碟 LED 燈亮



vSAN API and PowerCLI

對於喜歡透過 DevOps 或 PowerCLI 指令管理 vSAN 運作環境的團隊,在新版 vSAN 6.6 運作環境中也能方便管理。舉例來說,透過 Host Level vSAN API運作機制,可以查詢 vSAN Cluster Level 詳細資訊、S.M.A.R.T. 裝置資訊……等,詳細資訊請參考 VMware Docs - VMware vSAN 命令列、SDK 和 API 說明文件VSAN 6.2 extends vSphere API to include new VSAN Management APIs | virtuallyGhetto

圖、透過 vSAN API 管理及佈署

此外,透過 VMware vSphere PowerCLI指令工具,管理團隊也可以針對 vSAN 運作環境執行效能監控、叢集版本升級、vSAN iSCSI 操作……等。

圖、vSAN Automated Deployments with PowerCLI

CentOS 7.4 攻略 - 基礎設定系列文章

$
0
0

前言

Red Hat Enterprise LinuxRed Hat公司推薦使用於企業伺服器網路服務上的 Linux 發行版本,通常大多數的人會將此 Linux 發行版本簡稱為 RHEL(雖然 Red Hat 公司官方並不建議這樣簡稱)。在正常的情況下 RHEL 大約以每 18 ~ 24 個月的頻率,發佈下一版的作業系統。但是實際運作上 RHEL 作業系統版本的發行頻率,取決於 Fedora Linux 的更新。Fedora Linux 為 Red Hat 公司贊助的知名開放原始碼計畫,Red Hat 公司會將許多新技術先行導入至 Fedora Linux 發行版本中,待經過一段時間測試至穩定階段而且符合企業需求後,便會將該技術加入至下一個發行的 RHEL 版本中。每當 Fedora Linux發行 3 個版本後大約就會發佈 1 個 RHEL 新版本

而本文所要介紹的 CentOS (Community ENTerprise Operating System)為眾多 Linux 發行版本之一。CentOS 其源碼來自 RHEL 作業系統的開放原始碼,將其源碼重新編譯而成的,移除了無法自由使用的商標及 Red Hat 所擁有的封閉原始碼軟體。由於 CentOS Linux 與 Red Hat Enterprise Linux 具有大量相同的原始碼內容,因此也適合在需要高度穩定性的企業營運環境。

目前有些中小企業的 IT 人員為了建置預算上面的考量使用 CentOS Linux 發行版本來替代 RedHat Linux 企業版本。但是相對來說使用 CentOS Linux 發行版本除了得不到商業支援以外,當然也不包含 Red Hat 公司所擁有的封閉原始碼軟體。因此建議 IT 人員在使用 CentOS Linux 發行版本來建置企業網路服務以前,除了要先了解所使用的硬體伺服器是否支援 CentOS Linux 之外,更要了解所架設的商業服務是否會使用到 Red Hat 公司封閉原始碼軟體。

CentOS Linux 作業系統版本命名規則分為二個部份,分別是主要版本及次要版本來進行版本表示。其中主要及次要版本號碼,則是相對應於紅帽公司所發行的 RHEL 作業系統主要版本與更新版本號碼,例如,CentOS 7.4 版本便是相對應於 RHEL 7 update 4 版




實作環境





基礎設定

目前,最新版本為 CentOS 7.4 (1708),並且與舊版 CentOS 6.x有很大的不同,例如,新版 CentOS 7 預設檔案系統為 xfs 而非 ext4、預設防火牆為 firewalld 而非 IPTables……等。同時,虛擬化平台將採用最新的 Windows Server 2016 中的 Hyper-V 為基礎運作環境。💪



下列便是 CentOS 7.4 的基礎設定系列文章:
  • CentOS 7.4 基礎設定 (1) - 安裝整合服務並建立一般使用者帳號
  • CentOS 7.4 基礎設定 (2) - 組態設定網路功能
  • CentOS 7.4 基礎設定 (3) - 簡述 SELinux 安全性增強機制
  • CentOS 7.4 基礎設定 (4) - 組態設定 VIM 及 Bash Shell 操作環境
  • CentOS 7.4 基礎設定 (5) - 設定 sudo 管理員帳號管理機制
  • CentOS 7.4 基礎設定 (6) - 禁止 Root 帳號本機及 SSH 遠端登入
  • CentOS 7.4 基礎設定 (7) - 簡述 YUM 套件管理工具
  • CentOS 7.4 基礎設定 (8) - 擴充 YUM 套件數量
  • CentOS 7.4 基礎設定 (9) - 簡述 Systemd 啟動模式等級
  • CentOS 7.4 基礎設定 (10) - 調整 Firewalld 防火牆規則
  • CentOS 7.4 基礎設定 (11) - 定期寄送 CentOS 主機系統資訊 Log
  • CentOS 7.4 基礎設定 (12) - 關閉不必要的系統服務
  • CentOS 7.4 基礎設定 (13) - 採用 I/O Scheduler Noop 加速 Disk I/O
  • CentOS 7.4 基礎設定 (14) - 完成 CentOS Base VM 的製作

CentOS 7.4 基礎設定 (1) - 安裝整合服務並建立一般使用者帳號

$
0
0

前言

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



實作環境




建立 CentOS 7.4 VM 虛擬主機

首先,在 Windows Server 2016 Hyper-V虛擬化平台中,建立 CentOS 7.4 的 VM 虛擬主機,下列是這台 VM 虛擬主機的組態配置說明:
  • VM 虛擬主機名稱: CentOS74
  • 虛擬機器世代: 第 2 代
  • vCPU: 2 vCPU
  • vRAM: 8192 MB (啟用動態記憶體功能)
  • vHDD: 127 GB (VHDX,動態擴充)
  • vSwitch 名稱: VMs-vSwitch
  • 安全開機: 停用
圖、建立 CentOS 7.4 VM 虛擬主機



安裝 CentOS 7.4 (Minimal Install)

至於,安裝程序的部分相信大家應該都很熟悉,以下只提幾項個人喜好的組態設定部分,例如,Mount Point 的切割方式,建議 /var此掛載點的使用空間不要給太少,以免後續維護時發生問題。原因在於 /var 掛載點除了為預設所有記錄檔存放處以外,更重要的是當後續系統執行更新相關套件時,其暫存的資料便是存放於 /var/cache/yum內。因此 /var 掛載點空間太小將可能導致套件更新失敗的情況發生。(有關安裝程序的詳細資訊,請參考 RHEL 7 - Installation Guide)
  • Language: English
  • Date & Time: Asia / Taipei
  • Keyboard: English (US)
  • Installation Source: Local media
  • Software Selection: Minimal Install
圖、準備開始安裝 CentOS 7.4

圖、語系、時間、時區、鍵盤…等組態配置

圖、CentOS 7.4 的 Mount Point 資訊

圖、採用 CentOS 7.4 Minimal Install 只要安裝 299 個套件即可

圖、CentOS 7.4 安裝完畢



安裝最新整合服務 (LIS 4.2.3)

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

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

Supported CentOS and Red Hat Enterprise Linux virtual machines on Hyper-V | Microsoft Docs文章中可以看到,預設情況下 CentOS 7.4 版本其實已經有 Built in 整合服務。但是,登入 CentOS 7.4 後透過「/sbin/modinfo hv_vmbus」指令卻會發現,並沒有看到系統中的 LIS 整合服務版本?

圖、沒有看到目前系統中的 LIS 整合服務版本

請下載最新版本的 Linux Integration Services v4.2 for Hyper-V and Azure 後,掛載給 CentOS 7.4 VM 虛擬主機。接著,執行「mount /dev/cdrom /media」指令便可以掛載 LIS 4.2 ISO 映像檔至 CentOS 7.4 的光碟機,然後再依序執行「cd /media/CentOS74 ; ./install.sh」即可安裝最新版本 LIS 4.2.3,安裝完畢後請重新啟動。

圖、掛載 LIS 4.2.3 ISO 映像檔

圖、安裝最新版本 LIS 4.2.3 整合服務

待 CentOS 7.4 VM 虛擬主機重新啟動完成後,採用同樣的/sbin/modinfo hv_vmbus指令再次確認,可以發現 LIS 整合服務版本已經更新為最新的「4.2.3」

圖、最新版本 LIS 4.2.3 整合服務套用生效

但是,當你使用「systemctl list-units --type service |grep running」指令,查詢系統服務啟動清單時,將會發現只有 2 個 hv 開頭的整合服務。如下圖所示,只會看到「hv_kvp_daemon 及 hv_vss_daemon」整合服務,但卻沒看到「hv_fcopy_daemon」整合服務?

圖、只看到 2 個整合服務啟動

此時,請執行「systemctl list-units --type service |grep failed」指令,可以看到 Hyper-V FCOPY daemon 服務的運作狀態為 failed,並且使用「systemctl status hv_fcopy_daemon」指令查詢 Hyper-V FCOPY daemon 服務狀態時,可以看到顯示無法啟動 Hyper-V FCOPY  的錯誤訊息。

圖、Hyper-V FCOPY daemon 服務啟動失敗

其實,在查詢 Hyper-V FCOPY daemon 服務運作狀態訊息中,可以看到一行關鍵字「The Hyper-V Guest Services may not be enabled for this VM」,說明 Hyper-V FCOPY daemon整合服務啟動失敗的原因,是因為此台 VM 虛擬主機未啟用 Guest Services 所造成的。因此,請將 VM 虛擬主機關機後,將 LIS 整合服務光碟卸載並「啟用 Guest Services」後,再次開機確認。


圖、為 CentOS 虛擬主機啟用 Guest Services

當 CentOS 虛擬主機重新啟動後,再次使用「systemctl list-units --type service |grep running」指令,查詢系統服務啟動清單時將會發現 3 個 hv 開頭的整合服務皆已順利啟動,並且再次使用「systemctl status hv_fcopy_daemon」指令查詢 Hyper-V FCOPY daemon 服務狀態時,可以看到皆為順利啟用及正常運作的狀態。

圖、Hyper-V FCOPY daemon 整合服務順利啟動



建立一般使用者帳號

在安裝 CentOS 作業系統過程中會要求您順便設定 root 管理者帳號,作業系統安裝完成後請使用 root 管理者帳號登入系統。Linux 系統管理者應該具備如同管理 Microsoft Windows 主機時同樣的作業系統安全性觀念,也就是要先建立一般使用者帳號來登入系統進行操作,待需要執行的動作需要提升至管理者權限時,才著手轉換將權限提升。

因此,同樣的安全觀念當您首次登入 CentOS 作業系統後,建議您先為管理者建立一般使用者帳號後,再將該使用者帳號加入管理者群組當中。下列操作動作為先建立使用者家目錄資料夾,因為筆者習慣將使用者家目錄都集中於一個目錄內以便後續方便管理(預設使用者家目錄為存放至 /home 下)之後透過指令 adduser 建立一般使用者帳號 weithenn(-d 參數為指定該使用者家目錄位置),接著使用指令 passwd 設定使用者密碼,最後則是設定將該使用者加入管理者群組 wheel 當中。
# mkdir /home/user
# adduser -d /home/user/weithenn weithenn
# passwd weithenn
Changing password for user weithenn.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.
# vi /etc/group
wheel:x:10:weithenn




參考資源

CentOS 7.4 基礎設定 (2) - 組態設定網路功能

$
0
0

前言

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



實作環境




停止及停用 NetworkManager 系統服務

建立好使用者帳號後接下來便是設定 CentOS 的網路功能,在本文設定中網路功能是以設定固定 IP 位址來進行說明。首先,在 CentOS 7.4 Minimal Install運作環境中,執行「systemctl list-units --type service |grep running」指令後,可以看到預設仍會啟用 NetworkManager 系統服務,但個人的網路設定習慣不喜歡使用它,所以在組態設定 CentOS 主機網路環境之前,先執行「systemctl stop NetworkManager」指令以便停止NetworkManager系統服務,接著執行「systemctl disable NetworkManager」指令以便停用NetworkManager系統服務 (以避免 CentOS 主機重新啟動後不會自動執行)。

圖、停止及停用 NetworkManager 系統服務



組態設定主機名稱

預設情況下,採用 CentOS 7.4 Minimal Install 安裝模式後主機名稱為「localhost.localdomain」,你可以使用「hostname」「hostnamectl」指令進行查看。倘若,你希望能夠調整 CentOS 虛擬主機名稱時,可以執行「hostnamectl set-hostname "centos74.weithenn.org" --static」指令即可立即套用生效,後續再次使用「hostname」「hostnamectl」指令進行確認,可以發現 CentOS 主機名稱已經變更為「centos74.weithenn.org」。事實上,該指令將會把組態設定值套用至「/etc/hostname」組態設定檔當中。

圖、組態設定 CentOS 主機名稱



組態設定 CentOS 主機網路資訊

接著,我們直接透過相關組態設定檔的方式,設定 CentOS 主機的網路資訊分別將固定 IP 位址、網路遮罩等相關資訊寫入「/etc/sysconfig/network-scripts/ifcfg-eth0」網卡設定檔中、預設閘道寫入「/etc/sysconfig/network」設定檔中、DNS 名稱解析資訊寫入「/etc/resolve.conf」設定檔中。最後,便可以執行「systemctl restart network」指令重新啟動網路服務,然後再執行「systemctl status network」查看網路服務運作狀態。
# cat /etc/sysconfig/network-scripts/ifcfg-eth0
TYPE=Ethernet
BOOTPROTO=static
IPV6INIT=no
DEVICE=eth0
ONBOOT=yes
IPADDR=10.10.75.7
PREFIX=24
# cat /etc/sysconfig/network
GATEWAY=10.10.75.254
# cat /etc/hosts
127.0.0.1 localhost
# cat /etc/resolv.conf
search weithenn.org
nameserver 168.95.192.1
nameserver 168.95.1.1
nameserver 8.8.8.8
# systemctl restart network
# systemctl status network
network.service - LSB: Bring up/down networking
   Loaded: loaded (/etc/rc.d/init.d/network; bad; vendor preset: disabled)
   Active: active (exited) since Mon 2017-10-23 221:41:58 CST; 4min 54s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 2143 ExecStop=/etc/rc.d/init.d/network stop (code=exited, status=0/SUCCESS)
  Process: 2315 ExecStart=/etc/rc.d/init.d/network start (code=exited, status=0/SUCCESS)
Oct 23 22:41:53 centos74.weithenn.org systemd[1]: Starting LSB: Bring up/down networking...
Oct 23 22:41:53 centos74.weithenn.org network[17550]: Bringing up loopback interface:  [  OK  ]
Oct 23 22:41:53 centos74.weithenn.org network[17550]: Bringing up interface eth0:  [  OK  ]
Oct 23 22:41:53 centos74.weithenn.org systemd[1]: Started LSB: Bring up/down networking.


圖、組態設定固定 IP 位址

當 CentOS 主機的網路服務重新啟動並套用新的組態設定後,接著便可以使用 ping 指令來判斷主機是否能順利連上網際網路及進行名稱解析的動作,或者藉此判斷此台主機的網路通訊是卡在哪個環節上以便除錯。
# ping -c2 127.0.0.1   //檢查 Loopback
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.031 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.053 ms
--- 127.0.0.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.031/0.042/0.053/0.011 ms
# ping -c2 172.21.11.73   //檢查固定 IP 位址
PING 172.21.11.73 (172.21.11.73) 56(84) bytes of data.
64 bytes from 172.21.11.73: icmp_seq=1 ttl=64 time=0.030 ms
64 bytes from 172.21.11.73: icmp_seq=2 ttl=64 time=0.053 ms
--- 172.21.11.73 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.030/0.041/0.053/0.013 ms
# ping -c2 172.21.11.254   //檢查 CentOS 與預設閘道之間的連線
PING 172.21.11.254 (172.21.11.254) 56(84) bytes of data.
64 bytes from 172.21.11.254: icmp_seq=1 ttl=255 time=0.465 ms
64 bytes from 172.21.11.254: icmp_seq=2 ttl=255 time=0.445 ms
--- 172.21.11.254 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 0.445/0.455/0.465/0.010 ms
# ping -c2 168.95.192.1   //檢查 CentOS 是否能夠與指定的 DNS 伺服器連線
PING 168.95.192.1 (168.95.192.1) 56(84) bytes of data.
64 bytes from 168.95.192.1: icmp_seq=1 ttl=248 time=1.72 ms
64 bytes from 168.95.192.1: icmp_seq=2 ttl=248 time=1.46 ms
--- 168.95.192.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 1.466/1.596/1.726/0.130 ms
# ping -c2 weithenn.org   //檢查 CentOS 能否順利進行名稱解析
PING weithenn.org (216.239.38.21) 56(84) bytes of data.
64 bytes from any-in-2615.1e100.net (216.239.38.21): icmp_seq=1 ttl=45 time=7.91 ms
64 bytes from any-in-2615.1e100.net (216.239.38.21): icmp_seq=2 ttl=45 time=8.72 ms
--- weithenn.org ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1000ms
rtt min/avg/max/mdev = 7.918/8.321/8.724/0.403 ms




沒有 ifconfig / netstat / nslookup 指令?

CentOS 5 / 6版本中,預設都會安裝 net-tools 套件 (包含 ifconfig / netstat 指令)。但是,從 CentOS 7版本開始預設不會安裝該套件,原因是官方認為 ifconfig 指令無法完整顯示網路卡的 IP 位址組態設定,建議可以改用 ipss等指令 (詳細資訊請參考 FAQ/CentOS7 - CentOS Wiki)。

倘若,仍希望使用 ifconfig / netstat 指令的話,只要執行「yum -y install net-tools」指令安裝 net-tools 套件即可。此外,預設情況下也已經拿掉 nslookup指令,只要執行「yum -y install bind-utils」指令安裝 bind-utils 套件即可。如下操作所示,在尚未安裝 net-tools、bind-utils 套件之前,並無法使用 ifconfig / netstat / nslookup 指令,在完成安裝 net-tools、bind-utils 套件後便可以順利執行 ifconfig / netstat / nslookup 指令。
# ifconfig
-bash: ifconfig: command not found
# netstat
-bash: netstat: command not found
# nslookup
-bash: nslookup: command not found
# yum -y install net-tools bind-utils
# ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.10.75.7  netmask 255.255.255.0  broadcast 10.10.75.255
        inet6 fe80::215:5dff:feac:5915  prefixlen 64  scopeid 0x20<link>
        ether 00:15:5d:ac:59:15  txqueuelen 1000  (Ethernet)
        RX packets 20688  bytes 13770965 (13.1 MiB)
        RX errors 0  dropped 2  overruns 0  frame 0
        TX packets 6043  bytes 509742 (497.7 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
# 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:22     0.0.0.0:*        LISTEN   771/sshd
tcp        0      0 127.0.0.1:25   0.0.0.0:*        LISTEN   1092/master
tcp6       0      0 :::22          :::*             LISTEN   771/sshd
tcp6       0      0 ::1:25         :::*             LISTEN   1092/master
udp        0      0 127.0.0.1:323  0.0.0.0:*        LISTEN   542/chronyd
udp6       0      0 ::1:323        :::*             LISTEN   542/chronyd




停用 IPv6

預設情況下,CentOS 主機會同時使用 IPv4 及 IPv6網路功能,然而目前企業及組織的運作環境仍然相當少使用 IPv6 網路功能。因此,基於節省系統資源的概念下希望停用 IPv6 網路功能,如下操作結果可以看到使用「ifconfig eth0」指令有看到 inet (IPv4) 及 inet6 (IPv6)「netstat -tunpl」指令後,預設 SSH / Postfix / Chronyd系統服務同時使用 IPv4 / IPv6 網路功能。
# ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.10.75.7  netmask 255.255.255.0  broadcast 10.10.75.255
        inet6 fe80::215:5dff:feac:5915  prefixlen 64  scopeid 0x20<link>
        ether 00:15:5d:ac:59:15  txqueuelen 1000  (Ethernet)
        RX packets 20688  bytes 13770965 (13.1 MiB)
        RX errors 0  dropped 2  overruns 0  frame 0
        TX packets 6043  bytes 509742 (497.7 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
# 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:22     0.0.0.0:*        LISTEN   771/sshd
tcp        0      0 127.0.0.1:25   0.0.0.0:*        LISTEN   1092/master
tcp6       0      0 :::22          :::*             LISTEN   771/sshd
tcp6       0      0 ::1:25         :::*             LISTEN   1092/master

udp        0      0 127.0.0.1:323  0.0.0.0:*        LISTEN   542/chronyd
udp6       0      0 ::1:323        :::*             LISTEN   542/chronyd



停用網卡 IPv6

根據 CentOS Wiki  - FAQ/CentOS7 - How do i disable IPv6?官方文件內容可知,應該在「/etc/sysctl.conf」設定檔中,加入「net.ipv6.conf.all.disable_ipv6 = 1」、「net.ipv6.conf.default.disable_ipv6 = 1」內容,然後執行「sysctl -p」指令以便停用 CentOS 主機的 IPv6 網路功能。
# vi /etc/sysctl.conf //加入下列 2 行參數
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
# sysctl -p
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1



停用 SSH IPv6

根據 CentOS Wiki  - FAQ/CentOS7 - How do i disable IPv6? 官方文件的建議請修改 SSH  組態設定檔內容,讓 SSH 系統服務僅使用 IPv4網路功能。
# vi /etc/ssh/sshd_config
#AddressFamily any  //預設值
AddressFamily inet //修改後 (inet is ipv4 only, inet6 is ipv6 only)


停用 Postfix IPv6

根據 CentOS Wiki  - FAQ/CentOS7 - How do i disable IPv6? 官方文件的建議請修改 Postfix 組態設定檔內容,讓 Postfix 系統服務僅使用 IPv4 網路功能。
vi /etc/postfix/main.cf
#inet_interfaces = localhost  //預設值
inet_interfaces = 127.0.0.1  //修改後



停用 Chronyd IPv6

從 CentOS 7 版本開始,預設改為採用 Chrony 套件來擔任 NTP 時間校時的工作,請修改 Chrony服務組態設定檔內容,以便讓 Chrony 系統服務僅使用 IPv4 網路功能。詳細資訊請參考 16.2. Understanding chrony and Its Configuration - Red Hat Customer Portal
vi /etc/sysconfig/chronyd
OPTIONS=""    //預設值
OPTIONS="-4"  //修改後



修改完成後,建議重新啟動主機以便完整的套用生效。當 CentOS 主機重新啟動完成後,再次登入主機後使用「ifconfig eth0」指令發現已經沒有 inet6 (IPv6),而執行「netstat -tunpl」指令會發現預設的 SSH / Postfix / Chrony 系統服務僅使用 IPv4網路功能。
# ifconfig eth0
eth0: flags=4163 mtu 1500
inet 10.10.75.7 netmask 255.255.255.0 broadcast 10.10.75.255
ether 00:15:5d:4b:10:05 txqueuelen 1000 (Ethernet)
RX packets 20688 bytes 13770965 (13.1 MiB)
RX errors 0 dropped 2 overruns 0 frame 0
TX packets 6043 bytes 509742 (497.7 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
# 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:22      0.0.0.0:*        LISTEN   852/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.4 基礎設定 (3) - 簡述 SELinux 安全性增強機制

$
0
0

前言

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



實作環境




修改 SELinux 安全增強機制

Linux作業系統從核心 2.6 版本開始預設會自動載入安全增強機制 SELinux ( Security-Enhanced Linux)核心模組。SELinux 是由美國國家安全局 NSA (National Security Agency) 所開發,並且在 2000 年 12 月時將此核心模組發行給開放原始碼的開發社群,以便有效加強 Linux 整體安全性。

SELinux 為基於保護原則、作業系統中檔案結構及檔案權限的完整性原則所設計,此完整性原則可以有效針對入侵行為,以及企圖跨越系統安全架構等設計不良的應用程式對作業系統所造成的破壞,因此可以提供更安全的強制存取控制架構,來與作業系統的核心和主要子系統協同運作。在這樣的架構下相關的服務 (Daemon) 只能存取屬於該服務帳號所能存取的資料夾及檔案權限,若是超過所能存取的權限範圍則 SELinux 便會阻擋該服務的存取行為。所以若主機所架設的服務出現安全性漏洞導致被攻擊時 SELinux 能夠有效將攻擊所造成的損失降到最低。

簡單來說啟用了 SELinux 安全增強機制後的 Linux 作業系統,其檔案權限便不僅僅是傳統上的三種權限-讀取 r、寫入 w、執行 x-,及身份-擁有者 Owner、群組 Group、其它人 Others,而是整個主機內的檔案系統,將會套用更細微的權限及身份設定並且具有完整性架構。然而也因為 SELinux 安全增強機制及完整性原則,常常會造成 Linux 初學者因為不了解檔案系統及相關概念,進而導致設定相關網路服務時,因為違反了 SELinux 安全機制或者完整性原則,而導致網路服務無法啟動,或者無法存取系統資料(因為被 SELinux 安全機制給阻擋住了)。因此我通常會建議初學者可以先將此增強安全機制設定為警告通知,或者暫時關閉。等以後對於 CentOS 作業系統有更深的認識後再將此功能啟用。當然這樣的情況是自行測試或學習時,使用者若是用於企業營運時則強烈建議一定要開啟 SELinux 安全增強機制來提升及保護主機安全性。

要修改 SELinux 安全增強機制的設定,您可以透過修改「/etc/sysconfig/selinux」設定檔,或者使用指令 system-config-securitylevel 進入互動設定視窗進行設定之後再將主機重新啟動即可套用變更,SELinux 安全增強機制共有三種運作模式說明如下:

  • enforcing: 啟動模式 (預設值),SELinux 安全增強機制啟動將會阻擋不當的存取行為。
  • permissive: 寬容模式,當系統發生違反 SELinux 安全增強機制時僅僅顯示警告訊息而不會實際進行阻擋的動作,此模式很適合有心學習 SELinux 機制的學習者。
  • disabled: 停用模式,完全將 SELinux 安全增強機制停用。


建議您可以將設定值修改為寬容模式 (permissive),因為當您的操作行為違反 SELinux 安全增強機制時會顯示警告通知您,因此您可以有效學習到哪些操作或者哪些動作是會被 SELinux 阻擋哪些不會,這樣可以讓您日後真正開啟 SELinux 安全增強機制時,不致被卡住並且早日提升您所管理的主機系統整體安全性。您可以透過 sestatus指令來判斷目前主機中 SELinux 的運作模式及狀態,此設定值變更後必須要將主機重新啟動才能套用變更,當重新啟動後請記得再次使用 sestatus 指令以便確認您的修改正確有效。

# sestatus
SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy name:             targeted
Current mode:                   enforcing
Mode from config file:          enforcing
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Max kernel policy version:      28
# vi /etc/sysconfig/selinux
SELINUX=enforcing    //預設值 (啟動模式)
SELINUX=permissive  //修改後 (寬容模式)
# setenforce 0
# sestatus
SELinux status:                 enabled
SELinuxfs mount:                /sys/fs/selinux
SELinux root directory:         /etc/selinux
Loaded policy ZXname:           targeted
Current mode:                   permissive
Mode from config file:          permissive
Policy MLS status:              enabled
Policy deny_unknown status:     allowed
Max kernel policy version:      28

圖、調整 SELinux 安全性增強機制

CentOS 7.4 基礎設定 (4) - 組態設定 VIM 及 Bash Shell 操作環境

$
0
0

前言

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



實作環境




設定 VIM 編輯器操作環境

VI (Visual Interface)為 Unix-Like 預設內建的檔案編輯器,然而此編輯器對於 Linux 初學者來說比較容易感覺到使用不易。CentOS 作業系統預設會安裝較容易使用而且功能更為強大的檔案編輯器 VIM (Vi Imitation),建議 Linux 初學者可以使用此編輯器進行檔案編修,相信可以較為順手。

在本文環境中,因為採用的是 CentOS 7.4 Minimal Install,所以預設並不會安裝 VIM 套件而是使用預設的 VI。因此,若是覺得 VI 不順手的話可以使用指令「yum -y install vim」安裝 VIM 套件。

圖、安裝 VIM 套件

此外,VIM 檔案編輯器預設功能雖然已經很強大,但是您仍可以依需求加上相關參數設定使得 VIM 編輯器更為強大更為貼近您的使用需求。以下為個人習慣設定的 VIM 參數設定值:
# cat .vimrc
set number
set hls
set ic
set ai
set enc=utf8
# source ~/.vimrc


當重新套用 VIM 編輯器環境設定後,再次嘗試編輯檔案便會發現 VIM 環境已經套用生效。

圖、VIM 環境設定套用生效



設定 Bash Shell 操作環境

對於許多 Linux 的使用者來說習慣的 Shell 應該是系統預設使用的 bash (Bourne-Again Shell),CentOS 預設支援的 Shell 除了有 bash 之外還支援 sh (Bourne Shell)csh (C Shell)tcsh (TENEX C Shell)ksh (Korn Shell)等 Shell。基本上,使用哪種 Shell 全憑個人使用習慣也就是順手即可。

使用 Bash Shell在不設定任何參數的情況下,便可以擁有按下【Tab】鍵,即自動補齊檔名及搜尋上一次輸入指令的功能。所謂【Tab】鍵補齊檔名功能是什麼意思呢?舉個例子來說,假如我們想要查看主機的日期及時間資訊時,會鍵入 date 指令,當輸入 da 之後便按下【Tab】鍵,此時作業系統會尋找系統中 da 開頭的相關指令,由於系統中 da 開頭的指令只有二個分別是 date 及 dateconfig。因此當按下【Tab】鍵進行補齊檔名功能時便會先自動補齊為 date 指令。

Bash Shell 的補齊檔名功能不僅僅能使用於指令方面,對於檔案及目錄也具有相同的功能。以搜尋上一次輸入指令的功能為例,分別輸入了 ls 某個目錄內容及 cd 到某個目錄內,當您想要再次執行時只要打 ls 再按【上方向鍵】則 Bash Shell 會自動找出最近執行過開頭為 ls 的指令,這樣的功能對於操作作業系統來說非常方便。

除了預設的功能之外我們可以設定 Bash Shell 的環境變數來加強操作的便利性,以剛才測試補齊檔名功能執行的 date 指令來說,其實該指令的完整路徑為 /bin/date,但是為何當我們輸入 date 指令按下 Enter 鍵後便可順利執行該指令? 這是因為預設的 tcsh Shell 環境設定檔中已經將作業系統經常會使用到的指令路徑載入環境變數中(參數 PATH),因此我們才可以在不用鍵入絕對路徑的情況下直接執行相關指令。

以採用 Bash Shell 為例當使用者登入 CentOS 主機後,該使用者帳號會依序載入「/etc/profile」通用環境設定檔,接著則是載入個人家目錄下的「~/.bash_profile」「~/.bashrc」個人環境設定檔。倘若,管理者設定的通用環境設定檔與個人環境設定檔內容發生衝突時,系統將會套用個人環境設定檔為最後結果(Last Match)。

當完成 Bash Shell 環境設定檔之後,可以使用指令「source ~/.bashrc」立即套用生效或是登出/登入也可以,以下為個人習慣設定於個人家目錄下 .bashrc 的個人環境設定檔內容:
# cat ~/.bashrc
setterm -blength 0
alias vi='vim -S ~/.vimrc'
alias ll='ls -al --color'
alias grep='grep --color'
alias h='history 100'
# source ~/.bashrc


當重新套用 Bash Shell 環境設定後,嘗試執行一下 grep 指令功能便會發現已經套用生效。

圖、Bash Shell 環境設定套用生效

CentOS 7.4 基礎設定 (5) - 設定 sudo 管理員帳號管理機制

$
0
0

前言

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



實作環境




設定 sudo 管理員帳號管理機制

CentOS作業系統當中 root 使用者帳號被稱為超級使用者帳號,此帳號為整個作業系統中權限最大的管理帳號,權限大到可以直接將作業系統自我毀滅。由於 root 超級使用者帳號權限如此之大,因此強烈建議您應該使用一般使用者帳號登入主機進行操作,待需要執行的動作需要提升權限時才切換為管理帳號進行操作,以免因為一時疏忽或者不慎手誤,造成系統或服務損壞,例如,GitLab 史上最大危機:工程師誤刪大量資料,導致線上服務崩潰 | TechNews 科技新報。💣

當您所管理的 CentOS 主機同時擁有多個管理者進行管理時,您該如何確定是其中哪個管理者使用了 root 管理帳號對系統做了什麼事情? 例如,當您想要得知是哪個管理者在哪個時間切換為 root 管理帳號並且對系統執行了哪些指令,傳統的切換方式 su –就不符合這樣的需求了,有鑑於此我們可以透過設定 sudo 來達成這樣的查核需求。

Sudo套件就是為了彌補作業系統中內建的身份切換指令 su 不足所發展出來的軟體套件,透過設定此套件後我們可以建立相關的使用者權限群組,並且給予不同權限的指令來達到控管使用者權限的目的,同時配合相關參數設定我們可以隨時查閱哪位使用者執行過 sudo 指令來提升權限,並且能查出該使用者對於系統在權限提升之後執行了哪些動作,以便進行事後的追查。

首先,請先使用 rpm 及 which 指令來查詢系統中是否已經安裝 sudo 套件(預設情況下會安裝此套件)以及相關指令是否存在,確認目前系統中有安裝此套件時請接著使用 visudo指令來修改 sudo 設定檔內容。建議您不要直接使用 VI 或 VIM 編輯器來修改 sudo 設定檔,原因除了 visudo 指令會自行尋找 sudo 設定檔 (/etc/sudoers) 並且進入編輯模式之外,當我們修改完成後若設定檔內容中有發生語法或斷行等錯誤時,系統會在顯示警告訊息提醒我們哪裡發生語法錯誤。
# rpm -qa sudo
sudo-1.8.19p2-10.el7.x86_64
# which sudo visudo
/usr/bin/sudo
/usr/sbin/visudo


在此次實作中我們會修改 sudo 設定檔內容為將 wheel 群組那行的註解符號拿掉,並且加上 Log 記錄檔的內容「/var/log/sudo.log」,當此 sudo 設定檔設定完畢後,後續只要有人執行 sudo 指令提升權限至管理者身份時便會觸發到剛才設定檔中的 Log 設定,此時系統會自動產生 Log 檔案並將相關資訊寫入其中。相關操作如下所示:
# visudo
%wheel  ALL=(ALL)       ALL                
Defaults log_host, logfile=/var/log/sudo.log //加上此行


上述 sudo 設定檔內容表示只要屬於 wheel 群組內的使用者帳號,便可以使用 sudo 指令來暫時提升權限為管理者帳號進行操作。當使用者第 1 次執行 sudo 指令時系統會再次詢問該使用者密碼,當成功通過密碼驗證 (Authentication)之後便會暫時切換授權 (Authorization) 身份為管理者帳號 root 來執行其指令,並且在 5 分鐘之內若該使用者再次執行 sudo 指令時,系統便不會再次詢問使用者密碼。

接下來我們著手來測試剛才設定的 sudo 記錄檔機制是否正常運作,請您另外開啟一個 SSH Client 視窗並使用一般使用者帳號遠端登入 CentOS 主機。例如,使用 weithenn 這個一般使用者帳號(請確定該使用者帳號已加入 wheel 群組)登入系統並嘗試執行 vipw 指令試圖修改使用者帳號設定檔內容,相信會得到權限被拒絕 (Permission denied) 的錯誤訊息回應。此時您可以使用 sudo 指令搭配剛才的 vipw 指令再次執行即可修改使用者帳號設定檔內容。
[weithenn@centos74 ~]$ vipw //嘗試修改使用者帳號設定
vipw: Permission denied.
vipw: Couldn't lock file: Permission denied
vipw: /etc/passwd is unchanged
[weithenn@centos74 ~]$ id //確認已加入 wheel 群組
uid=1000(weithenn) gid=1000(weithenn) groups=1000(weithenn),10(wheel) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
[weithenn@centos74 ~]$ sudo vipw //搭配 sudo 機制提升權限

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.

[sudo] password for weithenn: //鍵入密碼,通過驗證程序執行提升權限

vipw: /etc/passwd is unchanged

圖、測試 sudo 機制

當上述指令執行完畢後您可以接著查看 sudo 記錄檔便會看到相關的記錄內容,從 sudo 記錄檔內容中我們可以確定 sudo 記錄檔機制目前正確運作中。從 sudo 記錄檔中可以清楚得知是在什麼時間點 (Oct 24 12:16:20)、系統中哪個使用者帳號 (weithenn)、在哪一台主機上 (centos74)、從遠端登入此台主機 (pts/1)、在系統中哪個路徑 (/home/user/weithenn)、切換成什麼身份 (root)、執行什麼指令 (/sbin/vipw)
[weithenn@centos74 ~]$ sudo tail /var/log/sudo.log
Oct 24 12:16:20 : weithenn : HOST=centos74 : TTY=pts/1 ; PWD=/home/user/weithenn ;
    USER=root ; COMMAND=/sbin/vipw

Oct 24 12:16:45 : weithenn : HOST=centos74 : TTY=pts/1 ; PWD=/home/user/weithenn ;
    USER=root ; COMMAND=/bin/tail /var/log/sudo.log

CentOS 7.4 基礎設定 (6) - 禁止 Root 帳號本機及 SSH 遠端登入

$
0
0

前言

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



實作環境




禁止 root 管理帳號 SSH 遠端登入

在預設的情況下,您可以直接使用 root 管理帳號來遠端登入 Linux 作業系統進行管理,然而在管理作業系統上通常安全性便利性是相對的二個拉扯點。所以,當您所管理的作業系統其操作便利性愈則安全性通常會相對的降,在此建議您關閉 Linux 預設允許 root 管理者帳號可以遠端登入管理系統,原因如下:

  • 主機將會增加了被入侵的機會。因為,在管理者帳號已知的情況下,剩下就是嘗試登入密碼了,如此一來很容易遭受暴力猜測密碼攻擊。
  • 當一台主機有眾多管理者時大家皆使用 root 管理者帳號登入系統進行管理動作,則誰修改了某個檔案內容或執行了哪些動作均無法稽核,因為記錄的資料都是 root。
  • 直接使用 root 管理者帳號登入系統進行管理,若是在操作過程中不慎下錯指令時有極大的可能會把系統給毀掉。例如原本是想刪除根目錄下的 test 資料夾 rm –rf /test 若不慎在操作時不小心多個空格 rm –rf / test,則對於作業系統來說是要刪除根目錄 (/) 及目前所在的 test 資料夾。


要將 CentOS 主機預設允許 root 管理者帳號遠端登入的功能關閉 (PermitRootLogin yes -> no),可以透過修改「/etc/ssh/sshd_config」設定檔後再重新載入 SSH 服務即可套用變更,套用完成後您可以測試是否無法使用 root 管理帳號遠端登入主機以便確定修改是否生效。

此外,有時可能會遇到一種情況,便是遠端登入主機時輸入帳號後怎麼要等很久才能輸入密碼? 會有這樣的狀況發生是因為 CentOS 在啟動 SSH 服務時,預設會配合使用名稱解析所導致,所以您主機運作的網路環境中名稱解析服務已經運作正常則不會有此問題發生。倘若,發生這樣的問題時,請檢查 DNS 名稱解析中反向解析對於此主機的解析情況,若此台主機所在的網路環境中並沒有反向名稱解析的機制,您可取消 SSH 服務中預設會使用到名稱解析的動作即可解決此一問題 (UseDNS yes -> no)

  • CentOS 7.3版本中,預設值仍為 UseDNS yes
  • 在最新 CentOS 7.4版本中,預設值已經改為 UseDNS no


最後,預設情況下 SSH 的 Listen Port 為 22,為了安全性考量也可以把預設 SSH Listen Port 改掉,例如,改為 Listen Port 22168
# vi /etc/ssh/sshd_config
#PermitRootLogin yes   //預設值,禁止 Root 帳號遠端登入
PermitRootLogin no    //修改後
#UseDNS yes            //預設值,啟用 DNS 名稱解析
UseDNS no             //修改後
#Port 22               //預設值,SSH Listen Port
Port 22168            //修改後
# grep -E '(PermitRootLogin|UseDNS|Port)' /etc/ssh/sshd_config //確認修改結果
Port 22168
PermitRootLogin no
UseDNS no
# systemctl restart sshd  //重新啟動 SSH 服務
# systemctl status sshd   //查看 SSH 服務運作狀態
sshd.service - OpenSSH server daemon
   Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2017-10-24 14:06:05 CST; 4s ago
     Docs: man:sshd(8)
           man:sshd_config(5)
 Main PID: 3863 (sshd)
   CGroup: /system.slice/sshd.service
           └─3863 /usr/sbin/sshd -D
Oct 24 14:06:05 centos74.weithenn.org systemd[1]: Starting OpenSSH server daemon...
Oct 24 14:06:05 centos74.weithenn.org sshd[3863]: Server listening on 0.0.0.0 port 22168.
Oct 24 14:06:05 centos74.weithenn.org systemd[1]: Started OpenSSH server daemon.


重新載入 SSH 服務後,可以使用「netstat -tunpl」指令確認 sshd 服務是否把 Listen Port 改為 22168
# 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/master

圖、確認 SSH 服務 Listen Port 是否變更

後續,倘若有人嘗試以 Root 管理者帳號並透過 SSH 遠端連線的方式時,將會發現即使 Root 帳號密碼鍵入正確,也會得到 Access Denied的錯誤訊息且無法登入。同時,在系統中的「/var/log/audit/audit.log」也會記錄這個異常行為。
# tail -n2 /var/log/audit/audit.log
type=USER_AUTH msg=audit(1508826440.459:442): pid=4044 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=? acct="root" exe="/usr/sbin/sshd" hostname=10.10.75.16 addr=10.10.75.16 terminal=ssh res=failed'
type=USER_AUTH msg=audit(1508826442.609:443): pid=4044 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=password acct="root" exe="/usr/sbin/sshd" hostname=? addr=10.10.75.16 terminal=ssh res=failed'


此外,要記得修改 Firewalld 防火牆規則,把允許 SSH Port 22 通行的規則改為 Port 22168。有關 Firewalld 防火牆規則操作的詳細資訊,請參考 CentOS 7.4 基礎設定 (10) - 調整 Firewalld 防火牆規則 文章。
# cat /etc/firewalld/zones/public.xml  //查詢目前防火牆規則
<?xml version="1.0" encoding="utf-8"?>
<zone>
  <short>Public</short>
  <description>For use in public areas. You do not trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
  <port protocol="tcp" port="22168"/>
</zone>
# firewall-cmd --reload  //重新載入防火牆規則
success
# firewall-cmd --list-all //顯示載入的防火牆規則
public
  target: default
  icmp-block-inversion: no
  interfaces: eth0
  sources:
  services:
  ports: 22168/tcp
  protocols:
  masquerade: no
  forward-ports:
  sourceports:
  icmp-blocks:
  rich rules:

圖、調整 Firewalld 防火牆規則



禁止 root 管理帳號本機登入

經過上述組態設定後,我們已經禁止讓 Root 管理帳號使用 SSH 遠端登入 CentOS 主機。然而,個人的管理習慣是希望大家都透過 sudo 轉換成管理權限,而非有人使用 root 管理帳號直接進行維運,所以也將 Root管理帳號「停用本機登入」的機制 (詳細資訊請參考 RHEL 7 Documentation - Security Guide - Controlling Root Access)。

倘若,希望了解 Root 管理帳號的登入情況,請執行「utmpdump /var/log/wtmp | grep root」指令即可 (tty表示由 Console 本機登入,pts表示由 SSH 遠端登入)
# utmpdump /var/log/wtmp | grep root
Utmp dump of /var/log/wtmp
[7] [00570] [tty1] [root ] [tty1 ] [ ] [0.0.0.0 ] [Tue Oct 24 00:14:55 2017 CST]
[7] [00560] [tty1] [root ] [tty1 ] [ ] [0.0.0.0 ] [Tue Oct 24 00:33:20 2017 CST]
[7] [00557] [tty1] [root ] [tty1 ] [ ] [0.0.0.0 ] [Tue Oct 24 00:56:48 2017 CST]
[7] [18127] [ts/0] [root ] [pts/0 ] [10.10.75.16 ] [10.10.75.16 ] [Tue Oct 24 10:51:56 2017 CST]
[7] [10262] [ts/0] [root ] [pts/0 ] [10.10.75.16 ] [10.10.75.16 ] [Tue Oct 24 11:00:11 2017 CST]
[7] [01169] [ts/0] [root ] [pts/0 ] [10.10.75.16 ] [10.10.75.16 ] [Tue Oct 24 11:29:26 2017 CST]
[7] [03991] [tty1] [root ] [tty1 ] [ ] [0.0.0.0 ] [Tue Oct 24 14:30:43 2017 CST]

圖、查詢 Root 管理帳號登入記錄

如下列操作,執行「vipw」指令將 root 管理帳號從原本的「/bin/bash」修改為「/sbin/nologin」後存檔離開即可。待修改完畢後,便會發現 Root 管理帳號也無法本機登入。
# vipw
root:x:0:0:root:/root:/bin/bash      //預設值
root:x:0:0:root:/root:/sbin/nologin //修改後




僅鎖定 root 管理帳號登入密碼

倘若,不希望停用 Root 管理帳號本機登入機制,也可以採用將 Root 管理密碼「鎖定」(Locking)的方式。請執行「passwd -l root」指令便可以鎖定 Root 管理帳號的登入密碼 (使用參數 -u 即可解除鎖定)。
# passwd -S root  //查詢狀態,登入密碼尚未鎖定
root PS 1969-12-31 0 99999 7 -1 (Password set, SHA512 crypt.)
# passwd -l root  //鎖定 Root 帳號登入密碼
Locking password for user root.
passwd: Success
# passwd -S root  //查詢狀態,登入密碼已鎖定
root LK 1969-12-31 0 99999 7 -1 (Password locked.)

圖、鎖定 Root 管理帳號登入密碼

CentOS 7.4 基礎設定 (7) - 簡述 YUM 套件管理工具

$
0
0

前言

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



實作環境




YUM 套件管理工具

絕大部份的開放原始碼軟體皆採用 Tarball的形式進行發布,而在 Linux 上為了解決使用 Tarball 必須要解壓縮、檢測 (./configure)、編譯 (make)、安裝 (make install)等繁鎖步驟,因此發展出 RPM (The RPM Package Manager)來簡化整個安裝流程。雖然 RPM 安裝機制簡化了整個安裝流程但卻無法解決套件相依性及套件相衝突的問題,舉例來說您可能安裝 A RPM 時系統顯示您必須要先安裝 B RPM(套件相依性),而當您下載及安裝 B RPM 時又說需要安裝 C RPM(套件相依性),當您好不容易又下載及安裝 C RPM 時卻出現此 RPM 跟 A RPM 互相衝突,碰到這種情況時在以往您只能手動排除這種套件衝突的狀況了。

YUM (Yellow dog Updater Modified)套件管理工具便是解決上述 RPM 套件相依性及相衝突的問題而發展出來的套件管理解決方案。此套件管理工具能從指定的套件伺服器上自動下載相對應的 RPM 套件包至系統進行安裝,並且當出現套件相依性時能自動下載及安裝相關聯的 RPM 套件,同時會盡量避免發生套件衝突的情況。YUM 能夠有效簡化軟體套件安裝流程並解決惱人的套件相依性及相衝突的問題,使得軟體套件在安裝、移除、升級程序上變得非常容易。

預設 YUM 下載套件的來源伺服器為國外網站,我們可以透過修改 YUM 設定檔 「/etc/yum.repos.d/CentOS-Base.repo」將下載套件的鏡像網站指定至台灣境內各所大學或機構。目前台灣可以使用的鏡像網站約有 10 個(如下所示),請您依個人網路狀況選擇較適合您的網路環境進行設定以便加快套件下載速度,或者參考 CentOS 鏡像網站清單選擇位於您國家內的鏡像網站:

  • 樹德科技大學: http://ftp.stu.edu.tw/Linux/CentOS/
  • 元智大學: http://ftp.yzu.edu.tw/Linux/CentOS/
  • 義守大學: http://ftp.isu.edu.tw/pub/Linux/CentOS/
  • 崑山科大: http://ftp.ksu.edu.tw/pub/CentOS/
  • 國家高速網路與計算中心: http://ftp.twaren.net/Linux/CentOS/
  • 臺中市政府教育局: http://ftp.tc.edu.tw/Linux/CentOS/
  • 靜宜大學: http://ftp.cs.pu.edu.tw/Linux/CentOS/
  • 中山大學: http://ftp.nsysu.edu.tw/CentOS/
  • Hinet IDC: http://mirror01.idc.hinet.net/CentOS/
  • 交通大學: http://centos.cs.nctu.edu.tw/


下列操作步驟中,我們將 YUM 設定檔內鏡像網站由預設國外站台修改為國內的 Hinet IDC
# cd /etc/yum.repos.d/
# cp CentOS-Base.repo CentOS-Base.repo.bak
# sed -i 's,mirror.centos.org/centos,mirror01.idc.hinet.net/CentOS,g' CentOS-Base.repo


上述設定完成後您便可以開始使用 YUM 配合相關指令管理套件,但是在開始以前建議確認 CentOS 主機時間是否正確,以免後續管理相關套件時,因為本機系統時間與 YUM 鏡像網站時間差異過大造成不可預期的錯誤。下列條列出使用 YUM 套件管理工具時,常常會使用到的指令及相關參數意義:

  • yum check-update: 套件更新檢查,將目前系統上安裝的套件與 YUM 鏡像網站進行檢查比對後列出需要更新套件的清單。
  • yum update:套件更新,檢查及比對系統需要套件更新的清單後詢問您是否要更新套件,您可以配合參數 –y 對所有詢問一律回答 yes 來允許所有套件更新。
  • yum install <套件名稱>:安裝套件,執行從 YUM 鏡像網站下載指定套件並進行安裝,收集相關資訊後會詢問您是否確定要安裝,您可以配合參數 –y 對所有詢問一律回答 yes 來安裝指定套件及其相依性套件。
  • yum remove <套件名稱>:移除套件,移除您指定的套件名稱,收集相關資訊後會詢問您是否確定要移除該套件,您可以配合參數 –y 對所有詢問一律回答 yes 來移除指定的套件及相依性套件。
  • yum clean all:清除暫存資料,清除使用 YUM 套件管理工具下載 RPM 進行安裝時的暫存檔案。
  • yum search <套件名稱或關鍵字>:搜尋套件,您可使用已經知道的套件名稱或者有關於套件的關鍵字來進行搜尋的動作。
  • yum list:顯示可安裝套件清單,顯示您指定的 YUM 鏡像網站中所支援安裝的所有套件名稱。
  • yum info <套件名稱>:套件資訊,顯示您指定的套件其詳細資訊,例如適用平台、套件版本、套件大小、套件功能描述、套件授權資訊、套件官方網址等資訊。
  • yum grouplist:顯示可安裝的套件群組清單,顯示您指定的 YUM 鏡像網站中所支援安裝的所有套件群組名稱。
  • yum groupinstall <套件群組名稱>:安裝套件群組,執行從 YUM 鏡像網站下載指定套件群組中相關套件並進行安裝,收集套件群組相關資訊後會詢問您是否確定要安裝,您可以配合參數 –y對所有詢問一律回答 yes 來安裝指定套件及其相依性套件。
  • yum groupremove <套件群組名稱>:移除套件群組,移除您指定的套件群組,並且在系統收集相關資訊後,會詢問是否確定要移除該套件群組中所有套件,您可以配合參數 –y 對所有詢問一律回答 yes 來移除指定的套件群組。
  • yum groupinfo <套件群組名稱>:查詢套件群組資訊,查詢指定的套件群組資訊及功能描述,並且將顯示此套件群組中預設會安裝的套件清單 (Default Packages)、強制安裝的套件清單 (Mandatory Packages)、選擇安裝的套件清單 (Optional Packages)。
  • yum provides <指令名稱>: 查詢指令的來源套件,查詢系統中某個指令是由哪個套件所提供。

舉例來說,在 CentOS 7 版本中預設情況下並不會有 ifconfig 及 netstat指令,此時便可以使用「yum provides ifconfig netstat」指令來查詢,這 2 個指令可以透過安裝「net-tools」套件獲得。
# yum provides ifconfig netstat
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: ftp.tc.edu.tw
 * elrepo: ftp.yz.yamagata-u.ac.jp
 * epel: mirror.premi.st
 * extras: ftp.tc.edu.tw
 * updates: ftp.tc.edu.tw
net-tools-2.0-0.22.20131004git.el7.x86_64 : Basic networking tools
Repo        : base
Matched from:
Filename    : /sbin/ifconfig

net-tools-2.0-0.22.20131004git.el7.x86_64 : Basic networking tools
Repo        : base
Matched from:
Filename    : /bin/netstat



由於 YUM 套件管理工具實際上也是幫助我們對 RPM 套件包進行管理的工作,其實底層的安裝、移除、升級等動作仍是使用 RPM 套件,因此我們仍可以使用 rpm 指令來幫助我們了解及管理套件,例如,使用 rpm 指令來了解已安裝的 Firewalld套件、設定檔及服務啟動檔在哪裡。
# rpm -qa firewalld   //查詢套件版本
firewalld-0.4.4.4-6.el7.noarch
# rpm -qc firewalld  //列出套件設定檔
/etc/dbus-1/system.d/FirewallD.conf
/etc/firewalld/firewalld.conf
/etc/firewalld/lockdown-whitelist.xml
/etc/sysconfig/firewalld
# rpm -ql firewalld  //列出套件所有檔案
/etc/dbus-1/system.d/FirewallD.conf
/etc/firewalld
/etc/firewalld/firewalld.conf
/etc/firewalld/icmptypes
/etc/firewalld/lockdown-whitelist.xml
/etc/firewalld/services
/etc/firewalld/zones
/etc/sysconfig/firewalld
/usr/bin/firewall-cmd
...略...

圖、使用 rpm 指令查詢套件資訊

CentOS 7.4 基礎設定 (10) - 調整 Firewalld 防火牆規則

$
0
0

前言

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



實作環境




Firewalld 防火牆

在過去 CentOS 5 / 6版本中預設採用的防火牆為 IPTables,而新版 CentOS 7版本中預設採用的防火牆則是 Firewalld。雖然 IPTables / Firewalld這兩者都是使用 iptables tools 來與 Kernel Packet Filter進行溝通,但是在實際運作上仍然有差異。首先,在防火牆組態設定的部分,過去 IPTables防火牆會將組態設定儲存於「/etc/sysconfig/iptables、/etc/sysconfig/ip6tables」檔案中,而新一代 Firewalld則是將防火牆組態設定儲存於「/usr/lib/firewalld、/etc/firewalld」XML檔案內。

其次,在火牆規則套用生效的部分,傳統的 IPTables防火牆運作環境中,每當調整防火牆規則時 IPTables 防火牆將會重新讀取所有防火牆規則並重新建立及套用 (套用生效的過程中,原有連線將會中斷)。

新一代 Firewalld防火牆則不會重建所有防火牆規則 (僅套用差異的防火牆規則部分),因此在套用新的防火牆規則時 Firewalld 不會中斷現有已經允許且連線中相關的防火牆規則連線。

圖、IPTables 及 Firewalld 防火牆堆疊運作架構示意圖

圖、Firewalld 防火牆運作架構示意圖



調整 Firewalld 防火牆規則

預設情況下,Firewalld 防火牆有多個不同的「區域」(Zone)並內含許多預設的防火牆規則,以便因應企業及組織不同的運作環境需求。你可以查看「/usr/lib/firewalld/zones」路徑內容,即可發現 Firewalld 防火牆預設有「Drop、Block、Public、External、DMZ、Work、Home、Internal、Tursted」等區域,詳細資訊請參考 RHEL 7 Document - Security Guide - Using FIrewalls文件內容。
# ls -l /usr/lib/firewalld/zones/
total 36
-rw-r--r--. 1 root root 299 Nov 12  2016 block.xml
-rw-r--r--. 1 root root 293 Nov 12  2016 dmz.xml
-rw-r--r--. 1 root root 291 Nov 12  2016 drop.xml
-rw-r--r--. 1 root root 304 Nov 12  2016 external.xml
-rw-r--r--. 1 root root 369 Nov 12  2016 home.xml
-rw-r--r--. 1 root root 384 Nov 12  2016 internal.xml
-rw-r--r--. 1 root root 315 Nov 12  2016 public.xml
-rw-r--r--. 1 root root 162 Nov 12  2016 trusted.xml
-rw-r--r--. 1 root root 311 Nov 12  2016 work.xml


本文實作環境採用 CentOS 7.4 Minimal Install,並於安裝完成後預設採用「Public」這個區域的防火牆規則及組態設定,同時預設僅允許「dhcpv6-client 及 SSH」流量允許通過。你可以查看「/etc/firewalld/zones/public.xml」內容,或使用指令「firewall-cmd --list-all」確認目前採用的 Firewalld Zone 及套用的防火牆規則。
# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: eth0
  sources:
  services: dhcpv6-client ssh
  ports:
  protocols:
  masquerade: no
  forward-ports:
  sourceports:
  icmp-blocks:
  rich rules:


倘若,管理人員需要調整 Firewalld 防火牆規則允許其它公用服務通過,例如,http、https。那麼只要在「/etc/firewalld/zones/public.xml」XML 組態設定檔內容中,加入「<service name="http"/> 及 <service name="https"/>」後,接著使用「firewall-cmd --reload」指令即可載入新的防火牆規則並套用生效。
# grep -E "http|https" /etc/firewalld/zones/public.xml
  <service name="http"/>
  <service name="https"/>
# firewall-cmd --reload
success
# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: eth0
  sources:
  services: http https ssh
  ports:
  protocols:
  masquerade: no
  forward-ports:
  sourceports:
  icmp-blocks:


那麼,該如何確認 Firewalld 防火牆預設支援哪些公用服務? 只要透過「firewall-cmd --get-services」指令即可列出,並使用「firewall-cmd --info-service=ssh」指令搭配公用服務名稱,即可查詢該公用服務的相關資訊。
# firewall-cmd --get-services
RH-Satellite-6 amanda-client amanda-k5-client bacula bacula-client bitcoin bitcoin-rpc bitcoin-testnet bitcoin-testnet-rpc ceph ceph-mon cfengine condor-collector ctdb dhcp dhcpv6 dhcpv6-client dns docker-registry dropbox-lansync elasticsearch freeipa-ldap freeipa-ldaps freeipa-replication freeipa-trust ftp ganglia-client ganglia-master high-availability http https imap imaps ipp ipp-client ipsec iscsi-target kadmin kerberos kibana klogin kpasswd kshell ldap ldaps libvirt libvirt-tls managesieve mdns mosh mountd ms-wbt mssql mysql nfs nrpe ntp openvpn ovirt-imageio ovirt-storageconsole ovirt-vmconsole pmcd pmproxy pmwebapi pmwebapis pop3 pop3s postgresql privoxy proxy-dhcp ptp pulseaudio puppetmaster quassel radius rpc-bind rsh rsyncd samba samba-client sane sip sips smtp smtp-submission smtps snmp snmptrap spideroak-lansync squid ssh synergy syslog syslog-tls telnet tftp tftp-client tinc tor-socks transmission-client vdsm vnc-server wbem-https xmpp-bosh xmpp-client xmpp-local xmpp-server
# firewall-cmd --info-service=ssh
ssh
  ports: 22/tcp
  protocols:
  source-ports:
  modules:
  destination:


此外,當管理人員需要調整 Firewalld防火牆允許其它連接埠,例如,TCP Port 8080。那麼,只要修改「/etc/firewalld/zones/public.xml」內容,加上「<port protocol="tcp" port="8080"/>」後,接著使用「firewall-cmd --reload」指令即可載入新的防火牆規則並套用生效。
# grep 8080 /etc/firewalld/zones/public.xml
  <port protocol="tcp" port="8080"/>
# firewall-cmd --reload
success
# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: eth0
  sources:
  services: http https ssh
  ports: 8080/tcp
  protocols:
  masquerade: no
  forward-ports:
  sourceports:
  icmp-blocks:
  rich rules:

CentOS 7.4 基礎設定 (11) - 定期寄送 CentOS 主機系統資訊 Log

$
0
0

前言

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



實作環境




Anacron 排程服務

當 CentOS 主機安裝設定完畢並上線運作之後,我們希望主機能夠在固定時間(例如 每小時、每天、每週、每月)發送相關資訊至主機管理人員 E-Mail 位址,讓主機管理人員能獲取系統上的服務運作狀態和硬體使用狀況等相關資訊。主機的管理人員只要定期查看每台管理主機的資訊郵件內容,即可進行判斷及適當的處理,或轉交給相對應的人員接手。

CentOS 主機的預設排程為每小時的 01 分、每天凌晨 4 點 02 分、每週日凌晨 4 點 22 分,以及每月 1 號凌晨 4 點 22 分。此時,系統會執行預先撰寫好的自動維護 Shell Script 執行檔,進行系統相關的清理及備份工作,並使用預設的 Postfix 郵件轉送代理 MTA(Mail Transfer Agnet) 寄送資訊郵件(CentOS 5.x 預設為使用 Sendmail)。欲使用別的郵件轉送代理像是 Sendmail、Qmail …等,屆時只要在設定檔內進行指定即可。若讀者有興趣了解系統定期執行的詳細內容,可切換至 /etc 目錄下的四個資料夾,分別是 每小時(cron.hourly)、每天(cron.daily)、每週(cron.weekly)、每月(cron.monthly),每個資料夾內都有相關的自動維護 Shell Script ,查看後即可了解系統維護主機的相關內容。

CentOS 6 / 7開始系統排程服務「crontab」的設定檔「/etc/crontab」內容中已經沒有排程工作的相關內容了,改為由「anacron」取代成為預設系統排程服務,您可以查看 「/etc/anacrontab」設定檔內容得知排程作業內容(CentOS 5.x時預設的系統排程服務為 crontab)。

Anacron排程服務它適合運作於測試機或筆記型電腦上這種「非長期處於開機狀態」之用,因為它採用的是 「頻率」 的方式來執行排程工作,以 /etc/cron.daily 執行的方式來說為 「1天」 執行一次,當 CentOS 主機開機後若發現今天尚未執行排程工作便會在 「5分鐘」 之後執行 /etc/cron.daily 目錄下的執行檔案,當執行排程工作完成後會在 「/var/spool/anacron/cron.daily」 檔案中把今天的日期寫入。(只有 root 管理權限能修改此檔)

  • cron.daily:執行一次,未執行過排程則開機 5 分鐘後執行。
  • cron.weekly:7天執行一次,未執行過排程則開機 25 分鐘後執行。
  • cron.monthly:執行一次,未執行過排程則開機 45 分鐘後執行。

查看 Anacron排程服務 (/etc/anacrontab) 組態設定檔內容:
# cat /etc/anacrontab
# /etc/anacrontab: configuration file for anacron
# See anacron(8) and anacrontab(5) for details.
SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
# the maximal random delay added to the base delay of the jobs
RANDOM_DELAY=45
# the jobs will be started during the following hours only
START_HOURS_RANGE=3-22

#period in days   delay in minutes   job-identifier   command
1       5       cron.daily              nice run-parts /etc/cron.daily
7       25      cron.weekly             nice run-parts /etc/cron.weekly
@monthly 45     cron.monthly            nice run-parts /etc/cron.monthly


crontab則是當系統時間到達排程時間時才會執行排程動作,比較適合用於伺服器這種「長時間開機型」的主機使用,由於我們要透過 CentOS 主機建置高可用性服務,屆時主機是處於長時間開機的情況,因此下列操作為將 anacron 套件從系統中移除,並且安裝舊有的 crontab 排程機制及相關設定檔,而安裝完成後您可以查看「/etc/cron.d/dailyjobs」排程檔案,事實上此排程檔案的內容與舊版中 /etc/crontab 檔案內容相同。

值得注意的是,在 CentOS 7當中不管是 Anacron 或 Crontab 排程服務都是由 crond 系統服務負責,但是在移除 Anacron 服務時會造成 crond 系統服務停止,所以請重新啟動 crond 系統服務即可。
# yum -y remove cronie-anacron     //移除 anacron 及相關套件
# yum -y install cronie-noanacron //安裝 crontab 及相關套件
# rpm -ql cronie-noanacron        //查詢安裝 crontab 套件的相關檔案
/etc/cron.d/dailyjobs  
# systemctl restart crond          //重新啟動 crond 服務
# systemctl status crond           //確認 crond 服務運作狀態
crond.service - Command Scheduler
   Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2017-10-24 17:09:30 CST; 4s ago
 Main PID: 4600 (crond)
   CGroup: /system.slice/crond.service
           └─4600 /usr/sbin/crond -n

Oct 24 16:07:30 centos74.weithenn.org systemd[1]: Started Command Scheduler.
Oct 24 16:07:30 centos74.weithenn.org systemd[1]: Starting Command Scheduler...
Oct 24 16:07:30 centos74.weithenn.org crond[4600]: (CRON) INFO (RANDOM_DELAY will be scaled with factor 56% if used.)
Oct 24 16:07:30 centos74.weithenn.org crond[4600]: (CRON) INFO (running with inotify support)
Oct 24 16:07:30 centos74.weithenn.org crond[4600]: (CRON) INFO (@reboot jobs will be run at computer's startup.)


最後,請記得不管採用的是 anacron 或 crontab 系統排程服務,當修改 anacron 設定(/etc/anacrontab) 或 crontab 設定(/etc/crontab) 之後都無須crond服務重新啟動,因為 crond 程序會在 「每分鐘」自動監控 /etc/cron.d 及 /var/spool/cron 資料夾變化,若有偵測到內容變化會自動將變化載入記憶體中,所以不需要修改後把 crond 服務重新啟動。



安裝 LogWatch 套件

CentOS系統中我們可以套過 YUM 套件管理工具安裝 LogWatch套件,它是負責收集系統狀態及相關網路服務運作資訊。安裝此套件後我們可以在每天定期發送的 cron.daily 資料夾中,發現 0logwatch這隻 Script。也就是說,系統會在每天凌晨 4 點 02 分時,透過此 Script 將系統中系統、硬體、服務的資訊收集後,寄送給主機管理者。接下來便說明相關資訊的設定方法,例如 由哪台主機寄出收集後的資訊、寄件對象、系統資訊收集分析的等級、收集主機服務運作的狀態設定等。

我們可以將相關設定值寫入至 LogWatch 設定檔 「/etc/logwatch/conf/logwatch.conf」內,下列為稍後操作中相關設定值其參數說明:

  • MailFrom:填入此台主機的主機名稱(Hostname),或是該主機所擔任的企業服務名稱(如 Web1) 以利識別。
  • MailTo:填入主機管理者們的郵件信箱(Email),若有多筆郵件位址則可以使用逗點(, ) 加上空格進行隔開即可。
  • Detail:指定收集主機資訊後分析的等級,共有三種等級可供選擇分別為 低級(Low 或數字 0)、中級(Med 或數字 5)、高級(High 或數字 10)。
  • Service:指定收集主機服務運作的項目,LogWatch 支援收集服務的項目為 /usr/share/logwatch/scripts/services 目錄下的服務名稱,您可以使用參數 All 來表示要收集該主機所有運作的服務。若不想分析某個服務,則可於服務名稱前加上減號( - ),則系統便會排除收集該項服務的運作狀態。

下列為個人習慣的 LogWatch 設定檔設定內容,若您需要更詳細的參數設定內容請參考 「/usr/share/logwatch/default.conf/logwatch.conf」範例設定檔內容。在 LogWatch 中「Service All」所有服務項目有哪些呢? 請參考「/usr/share/logwatch/scripts/services」路徑內容,便會條列 LogWatch 所支援的服務項目 (目前共支援 106 項服務):
# yum -y install logwatch              //安裝 logwatch 套件
# cat /etc/logwatch/conf/logwatch.conf //查看 logwatch 設定檔內容
MailFrom = centos74                     //郵件寄件者顯示資訊
MailTo = weithenn@weithenn.org          //郵件位址
Detail = High                           //分析資訊等級
Service = All                           //收集所有服務運作項目
Service = -yum                          //除了 yum 以外
Format = html                           //格式為 HTML (預設為 Text)


確認 Postfix運作狀態正常後,便可以執行「/etc/cron.daily/0logwatch」指令來測試每日排程執行時,LogWatch 套件收集主機資訊的郵件是否能順利寄出,而您是否也可以從設定的 E-Mail 地址收到主機所發出的收集資訊郵件,由下列郵件記錄檔內容可以看到 CentOS 主機順利將郵件發送至 logwatch 設定檔中所設定的E-Mail 地址,若您想要查看系統是否有郵件佇列(Mail Queue) 或想刪除所有郵件佇列的郵件,您可以使用「postqueue」指令配合參數「-p、-f」即可。
# /etc/cron.daily/0logwatch  //馬上寄送收集主機資訊郵件
# tail /var/log/maillog      //查看郵件記錄檔
Oct 23 23:27:12 centos74 postfix/postfix-script[10440]: starting the Postfix mail system
Oct 23 23:27:12 centos74 postfix/master[10442]: daemon started -- version 2.10.1, configuration /etc/postfix
Oct 23 23:27:47 centos74 postfix/postfix-script[1087]: starting the Postfix mail system
Oct 23 23:27:47 centos74 postfix/master[1089]: daemon started -- version 2.10.1, configuration /etc/postfix
Oct 24 04:11:23 centos74 postfix/pickup[4145]: 151E08011758: uid=0 from=
Oct 24 04:11:23 centos74 postfix/cleanup[5051]: 151E08011758: message-id=<20171024081123 .151e08011758="" centos74.weithenn.org="">
Oct 24 04:11:23 centos74 postfix/qmgr[1091]: 151E08011758: from=, size=92571, nrcpt=1 (queue active)
Oct 24 04:11:23 centos74 postfix/smtp[5053]: connect to ASPMX.L.GOOGLE.COM[2404:6800:4008:c04::1a]:25: Network is unreachable
Oct 24 04:11:25 centos74 postfix/smtp[5053]: 151E08011758: to=, relay=ASPMX.L.GOOGLE.COM[74.125.204.27]:25, delay=4, delays=1.2/0.02/0.85/1.9, dsn=2.0.0, status=sent (250 2.0.0 OK 1508832685 h13si4682051pgq.28 - gsmtp)
Oct 24 04:11:25 centos74 postfix/qmgr[1091]: 151E08011758: removed
# postqueue -p           //顯示 Mail Queue
# postqueue -f           //刪除所有 Mail Queue 信件
20171024081123>

Viewing all 590 articles
Browse latest View live


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