Q. 在 Failover Cluster 運作環境中,出現「Computer object could not be updated」的錯誤訊息?

Error Message:
當建立好「容錯移轉叢集」(Failover Cluster)運作環境後,進行相關操作時常常會出現下列錯誤訊息說明無法更新 Computer Object? 例如,建立 SOFS 服務時,雖然在 DC 網域控制站中還是有出現 SOFS 電腦帳戶,但就是會出現警告訊息?
The Computer object associated with cluster network name resource 'Backup' could not be updated.
The text for the associated error code is: Unable to protect the Virtual Computer Object (VCO) from accidental deletion.
The cluster identity 'WSFC$' may lack permissions required to update the object. Please work with your domain administrator to ensure that the cluster identity can update computer objects in the domain.



Ans:
簡單來說,這個問題發生的原因在於「容錯移轉叢集電腦帳戶」(本次實作環境為 WSFC),不具備 DC 網域控制站中「Computers」容器「Create Computer objects」的權限所導致。只要讓「容錯移轉叢集電腦帳戶」具備權限即可。

請開啟 Active Directory Users and Computers 後依序點選「View > Advanced Features」,接著點選「Computers > Properties」,在彈出的 Computers Properties 視窗中點選至「Security」頁籤,然後點選「Advanced > wsfc$ >  Edit」勾選「Create Computer objects」項目即可。


後續,再次嘗試建立 SOFS 服務時,容錯移轉叢集電腦帳戶因為具備新增 Computers 容器物件的權限,便不會再出現警告訊息了。





參考資源


課程簡介

  • 熟悉雲端運算定義:五種服務特徵、四種部署模型、三種服務類型。
  • 針對企業及組織建構私有雲虛擬運算環境時,從硬體伺服器的 CPU 處理器及週邊元件如何選擇開始,到 vCPU 及 vRAM 的規劃設計,以便建構出最佳運作效能的基礎架構。
  • 針對企業及組織建構私有雲虛擬網路環境時,如何規劃設計 VM 虛擬主機各種傳輸流量,例如,VM 網路服務流量、高可用性遷移流量、容錯移轉流量…等以避免造成傳輸瓶頸。
  • 針對企業及組織建構私有雲虛擬儲存環境時,從針對不同儲存設備類型的功能及特性,到私有雲運作環境該如何規劃及估算儲存設備 IOPS 效能,以避免資料傳輸瓶頸產生 VM 虛擬主機運作效能不佳的情況。



課程資訊

日期: 2017/7/29 ~ 2017/8/19
時間: 每週六 09:00 ~ 17:00
地點: 台中科技大學 (台中市北區三民路 91 號 2 樓)
網址: 全方位企業私有雲規劃與建置之最佳化調校實務班




活動簡介

雲端運算正在改變整個世界。不論是以雲端技術提升系統運作效率,或是以雲端模式推動企業創新與轉型,雲端技術都扮演著推動企業變革的關鍵角色。而諸如快速成長的物聯網、大數據分析、機器學習、人工智慧等新興應用,也都乘著雲端的翅膀起飛。

雲端不只是企業數位轉型的契機,更將深入 IT 的各個面向,成為企業 IT 的新常態。在萬流歸雲的趨勢下,iThome Cloud Summit 2017 雲端大會特別規畫 8 大趨勢主題,以及現場能親手體驗雲端威力的 Hands-on Lab 實機體驗課程,試圖勾勒出現代化雲端技術更為完整的面貌,誠摯邀請您一起來探究現代化雲端技術的新潛能。



活動資訊

  • 日期: 2017 年 6 月 23 日 (星期五)
  • 時間: 8:00 ~ 17:00
  • 地點: 臺北市信義區菸廠路 88 號 (臺北文創大樓)
  • 報名: 活動報名



活動內容






前言

簡單來說,常用來在 Linux 作業系統中的 sudo 套件被發現存在嚴重漏洞,惡意人士透過「get_process_ttyname ()」這個函數的漏洞可以讓任何擁有 Shell 帳戶使用 Root 權限,即便 RHEL / CentOS 啟用 SELinux 安全性機制的情況下仍無法阻擋。因此,請盡量修補你所管理的 Linux 作業系統。



受影響的 Linux 發行版本

  • Red Hat Enterprise Linux Server (v. 5 ELS) (sudo)
  • Red Hat Enterprise Linux 6 (sudo)
  • Red Hat Enterprise Linux 7 (sudo)
  • Debian wheezy
  • Debian jessie
  • Debian stretch
  • Debian sid
  • Ubuntu 17.04
  • Ubuntu 16.10
  • Ubuntu 16.04 LTS
  • Ubuntu 14.04 LTS
  • SUSE Linux Enterprise Software Development Kit 12-SP2
  • SUSE Linux Enterprise Server for Raspberry Pi 12-SP2
  • SUSE Linux Enterprise Server 12-SP2
  • SUSE Linux Enterprise Desktop 12-SP2
  • OpenSuse




檢測系統中的 sudo 版本是否受漏洞影響

管理人員可以至 Red Hat Customer Portal - sudo: Privilege escalation via improper get_process_ttyname() parsing 下載 sudo 漏洞檢測工具  cve-2017-1000367.sh 進行檢測作業。
簡單來說,只要 sudo 套件版本是 1.8.6p7 ~ 1.8.20 都會受到此漏洞的影響,必須採用 sudo 1.8.20p1 套件版本才順利修復此漏洞。對應到 RHEL 7 / CentOS 7 的話版本則是 sudo-1.8.6p7-22.el7_3.x86_64 才對。

如下所示,在還沒有進行 sudo 套件更新作業之前,檢測結果可以看到目前 CentOS 7.3 當中的 sudo 套件 (sudo-1.8.6p7-20.el7_3.x86_64) 仍受此漏洞所影響。
# cat /etc/redhat-release
CentOS Linux release 7.3.1611 (Core)
# uname -a
Linux centos73.weithenn.org 3.10.0-514.el7.x86_64 #1 SMP Tue Nov 22 16:42:41 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
# rpm -qa sudo
sudo-1.8.6p7-20.el7.x86_64
# ./cve-2017-1000367.sh

This script is primarily designed to detect CVE-2017-1000367 on supported
Red Hat Enterprise Linux systems and kernel packages.
Result may be inaccurate for other RPM based systems.

Detected 'sudo' package is 'sudo-1.8.6p7-20.el7.x86_64'.
This 'sudo' version is vulnerable.
Update 'sudo' package when possible, there are no mitigations available.
Follow https://access.redhat.com/security/vulnerabilities/3059071 for advice.

圖、系統使用具有 sudo 漏洞的套件版本



更新 sudo 套件版本修復漏洞

簡單來說,我們必須將 CentOS 7.3 當中的 sudo 套件版本從原本的 sudo-1.8.6p7-20.el7_3.x86_64 升級至 sudo-1.8.6p7-22.el7_3.x86_64 版本才行。其它 CentOS 版本對應的 sudo 套件版本資訊,請參考 Red Hat Customer Portal - Important: sudo security udpate。請執行「yum -y update」即可下載及更新 sudo 修復漏洞的套件版本 (事實上,昨天也就是 2017 年 5 月 31 日還無法下載成功,今天 2017 年 6 月 1 日測試已經可以順利更新!!)。
# yum -y update
# yum info sudo
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: ftp.tc.edu.tw
 * elrepo: ftp.yz.yamagata-u.ac.jp
 * epel: ftp.cuhk.edu.hk
 * extras: ftp.tc.edu.tw
 * updates: ftp.tc.edu.tw
Installed Packages
Name        : sudo
Arch        : x86_64
Version     : 1.8.6p7
Release     : 22.el7_3

Size        : 2.5 M
Repo        : installed
From repo   : updates
Summary     : Allows restricted root access for specified users
URL         : http://www.courtesan.com/sudo/
License     : ISC
Description : Sudo (superuser do) allows a system administrator to give certain
            : users (or groups of users) the ability to run some (or all) commands
            : as root while logging all commands and arguments. Sudo operates on a
            : per-command basis.  It is not a replacement for the shell.  Features
            : include: the ability to restrict what commands a user may run on a
            : per-host basis, copious logging of each command (providing a clear
            : audit trail of who did what), a configurable timeout of the sudo
            : command, and the ability to use the same configuration file (sudoers)
            : on many different machines.

圖、更新 sudo 套件版本

此時,再次使用 sudo 漏洞檢測工具  cve-2017-1000367.sh 進行檢測作業,可以發現結果是已經使用修復 sudo 漏洞的套件版本 (sudo-1.8.6p7-22.el7_3.x86_64) 了。
# cat /etc/redhat-release
CentOS Linux release 7.3.1611 (Core)
# uname -a
Linux centos73.weithenn.org 3.10.0-514.el7.x86_64 #1 SMP Tue Nov 22 16:42:41 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
# rpm -qa sudo
sudo-1.8.6p7-22.el7_3.x86_64
# ./cve-2017-1000367.sh

This script is primarily designed to detect CVE-2017-1000367 on supported
Red Hat Enterprise Linux systems and kernel packages.
Result may be inaccurate for other RPM based systems.

Detected 'sudo' package is 'sudo-1.8.6p7-22.el7_3.x86_64'.
This 'sudo' version is not vulnerable.

圖、順利更新 sudo 套件版本並修復漏洞



參考資源


前言

最近工作關係開始玩 CentOS 了,本次實作環境中採用的是 CentOS 7.3 x86-64 (Kernel version 3.10.0-514.el7.x86_64) 映像檔,也就是新版 CentOS 7.3 最小化安裝版本 (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-05-31 17:09:30 CST; 4s ago
 Main PID: 32472 (crond)
   CGroup: /system.slice/crond.service
           └─32472 /usr/sbin/crond -n

May 31 17:09:30 centos73.weithenn.org systemd[1]: Started Command Scheduler.
May 31 17:09:30 centos73.weithenn.org systemd[1]: Starting Command Scheduler...
May 31 17:09:30 centos73.weithenn.org crond[32472]: (CRON) INFO (RANDOM_DELAY will be scaled with factor 66% if used.)
May 31 17:09:31 centos73.weithenn.org crond[32472]: (CRON) INFO (running with inotify support)
May 31 17:09:31 centos73.weithenn.org crond[32472]: (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 = centos73                     //郵件寄件者顯示資訊
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      //查看郵件記錄檔
May 31 17:28:12 centos73 postfix/pickup[32553]: CABFC2005097: uid=0 from=
May 31 17:28:12 centos73 postfix/cleanup[32634]: CABFC2005097: message-id=<20170531092812 .cabfc2005097="" centos73.weithenn.org="">
May 31 17:28:12 centos73 postfix/qmgr[663]: CABFC2005097: from=, size=5469, nrcpt=1 (queue active)
May 31 17:28:12 centos73 postfix/smtp[32636]: connect to ASPMX.L.GOOGLE.COM[2404:6800:4008:c04::1b]:25: Network is unreachable
May 31 17:28:14 centos73 postfix/smtp[32636]: CABFC2005097: to=, relay=ASPMX.L.GOOGLE.COM[64.233.187.26]:25, delay=1.8, delays=0.06/0.01/0.36/1.4, dsn=2.0.0, status=sent (250 2.0.0 OK 1496222994 91si46967451plb.204 - gsmtp)
May 31 17:28:14 centos73 postfix/qmgr[663]: CABFC2005097: removed
# postqueue -p            //顯示 Mail Queue
# postqueue -f            //刪除所有 Mail Queue 信件



網管人雜誌

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



文章目錄

前言
VCHA 高可用性機制
          VCHA 高可用性運作架構
          部署 VCHA 高可用性的最佳作法
vMotion 即時遷移的安全性
          vMotion 加密技術運作架構
          組態設定加密 vMotion 機制
          部署加密 vMotion 的最佳作法
結語





前言

VMware 官方,在 2016 年 11 月 VMware VMworld 2016 大會上,宣佈 VMware vSphere 6.5VMware vSAN 6.5 正式推出,並且 VMware 官方在最新版本 vCSA 6.5 當中,為 vCSA 管理平台打造「原生 HA 高可用性」機制。
在過去的 vCSA(VMware vCenter Server Appliance)版本中,並沒有原生 vCSA HA 高可用性機制,只能搭配 VMware 叢集內建的 vSphere HA 高可用性機制,來達到 vCSA 服務高可用性的目的。

在本文中,除了介紹 VCHA 高可用性運作架構及最佳建議作法之外,同時也會介紹在 vSphere 6.5 版本當中的另一個亮點功能,也就是針對 vMotion 即時遷移流量進行加密,避免遭受中間人攻擊甚至被竄改記憶體狀態導致資安事件,有效保護企業及組織線上營運的 VM 虛擬主機進行 vMotion 遷移時的安全性。





VCHA 高可用性機制

新版的原生 vCSA HA 機制(簡稱 VCHA),是由「Active、Passive、Witness」成員節點角色所組成。當 VCHA 叢集中某台成員節點主機發生災難事件時(例如,擔任 Active Node 角色的成員節點主機發生硬體故障),將會觸發 VCHA 高可用性機制然後透過 API 存取的使用者在 2 分鐘內便可以繼續使用,而透過 UI 存取的使用者在 4 分鐘便可以繼續存取,原則上 VCHA 機制的 RTO 預計在「5 分鐘」之內便可完成,當然實際上必須視底層硬體資源的工作負載情況而定。

圖 1、VCHA 高可用性機制運作示意圖



VCHA 高可用性運作架構

在實作 VCHA 高可用性機制的部分,必須保持 Active Node 及 Passive Node 節點主機狀態的一致性。首先,在 vCSA 資料庫部分預設採用內嵌「PostgreSQL 資料庫」,所以透過 PostgreSQL 資料庫原生的「複寫」(Replication)機制,保持 Active Node 及 Passive Node 節點主機資料庫同步及內容的一致性。接著,在「組態設定檔」的部分則使用 Linux 作業系統中原生的「Rsync」複寫機制,達到 Active Node 及 Passive Node 節點主機組態設定檔內容一致性。

在 VCHA 高可用性機制運作架構中,高可用性叢集是由 Active、Passive、Witness 成員節點主機所組成,每台成員節點主機的功能如下:

  • Active Node: 運作 vCenter Server 主要執行個體,啟用及使用 VMware 叢集的共用 IP 位址。
  • Passive Node: 運作 vCenter Server 備援執行個體,透過複寫機制不斷從 Active Node 端接收變更內容及狀態,倘若 Active Node 發生故障事件時將會立即接手相關服務。
  • Witness Node: 擔任仲裁角色,當 Active Node 及 Passive Node 發生網路分區或中斷事件時,能夠有效避免 VCHA 高可用性運作架構發生腦裂的情況。在整個 VCHA 運作架構中,使用最少的硬體資源同時也不會接手 Active Node 及 Passive Node 的角色。

圖 2、VCHA 高可用性機制運作架構示意圖

那麼,在 VCHA 高可用性機制的運作架構下,當發生不同的災難事件時(例如,硬體、軟體、網路環境),Passive Node 如何接手 Active Node 服務及叢集公用 IP 位址,並且繼續回應客戶端提出的請求。此外,在 VCHA 高可用性機制中因為 PostgreSQL 資料庫將會進行同步,所以發生災難事件時也不會有資料遺失的情況(RPO=0)

下列,我們將列舉當 VCHA 高可用性機制發生各種災難事件時,系統將如何進行因應措施:

  • Active Node 故障損壞時: 只要 Passive Node 與 Witness Node 能夠互相通訊,那麼 Passive Node 將會提升自己的角色為 Avtive Node,並且開始回應客戶端提出的請求。
  • Passive Node 故障損壞時: 只要 Active Node 與 Witness Node 能夠互相通訊,那麼 Active Node 將繼續保持 Avtive Node 的角色,並且繼續回應客戶端提出的請求。
  • Witness Node 故障損壞時: 只要 Active Node 與 Passive Node 能夠互相通訊,那麼 Active Node 將繼續保持 Avtive Node 的角色,並且繼續回應客戶端提出的請求。同時,Passive Node 將會繼續偵測 Active Node 是否正常運作,以便隨時準備進行故障切換作業。
  • 多台節點發生故障或發生網路隔離: 表示 Active、Passive、Witness 這 3 台節點主機彼此無法互相通訊。此時,VCHA 叢集將無法正常運作並且可用性也受到影響,因為 VCHA 高可用性機制的設計並無法容許同時發生多項故障。
  • 節點隔離行為: 當單台節點主機發生網路中斷事件,在經過間歇性網路故障偵測程序及所有重試機制都耗盡後,系統才會將該台節點主機判定為隔離狀態,同時進入隔離狀態的節點主機將會自動停止所有服務。舉例來說,倘若 Active Node 發生隔離狀態時,那麼 Active Node 將會從叢集中移出並停止所有服務,以便確保 Passive Node 能夠接手角色成為 Avtive Node,並且開始回應客戶端提出的請求。



部署 VCHA 高可用性的最佳作法

在 vCSA 6.5 版本中,每台 vCSA 支援管理最多 64 叢集、2,000 台 ESXi 主機、35,000 台註冊的 VM 虛擬主機、20,000 台開機的 VM 虛擬主機。同時,不同運作規模大小對於 vCSA 硬體資源的配置建議也不同,在下列表格中便是 VMware 官方針對不同運作規模的 vCSA 硬體資源建議:
事實上,vCSA 還支援更小型的運作規模稱為「Tiny」,只需要 2 vCPUs 及 10 GB RAM 的硬體資源,可以管理 10 台 ESXi 主機及 100 台 VM 虛擬主機。但是,VCHA 高可用性運作機制不支援 Tiny 運作規模,所以要啟用 VCHA 高可用性機制至少需要採用 Small 運作規模才行。
圖 3、針對不同運作規模的 vCSA 硬體資源建議

雖然,VMware 建立的 VCHA 高可用性機制運作架構非常簡單易用,但是 vSphere 管理人員應該遵循最佳作法,以便讓 VCHA 高可用性機制運作效能更佳之外也更穩定:

  • 離峰時間才啟用 VCHA 機制: 雖然,可以在 vCenter Server 運作的任何時間啟用 VCHA 高可用性機制,但是 VMware 強烈建議在工作負載的離峰時間再啟用。主要原因在於,建立 VCHA 高可用性機制後系統便會立即執行 PostgreSQL 資料庫同步作業,倘若在工作負載高峰時間啟用的話,那麼 Passive Node 的 PostgreSQL 資料庫有可能會來不及同步。
  • 僅容許單台節點發生故障: 在 VCHA 高可性機制的運作架構下只有 3 台節點主機,所以容許故障的節點主機數量不能超過「單台」。因此,每台節點主機的角色應部署在不同 x86 硬體伺服器上,以避免硬體伺服器發生故障損壞事件時直接影響所有角色。此外,每台節點主機也應部署在獨立且隔離的 Datastore 儲存資源中,以避免將 3 台節點主機都部署在同 1 個 Datastore 儲存資源中,導致發生 SPOF 單點失敗的問題進而影響 VCHA 高可用性機制。


此外,在 VCHA 高可用性運作架構中,網路環境應該具備低延遲時間、高傳輸頻寬、隔離且專用的網路,以避免因為不適當的網路環境進而影響 VCHA 高可用性機制的運作及效能。下列,為 VCHA 高可用性網路環境規劃設計的最佳建議作法:

  • 採用隔離且專用的網路: 因為在 VCHA 高可用性機制運作架構中,Active Node 及 Passive Node 之間,必須不斷同步 PostgreSQL 資料庫的資料,倘若 2 台節點主機之間的網路頻寬無法達到資料同步要求時,那麼將會退化為非同步並導致 PostgreSQL 資料庫內容相異。
  • 支援高達 10 ms 的低延遲網路: 在 VCHA 高可用性機制運作架構中,可以支援高達 10 ms 網路環境延遲時間。倘若,網路環境的延遲時間高於 10 ms 時,那麼 VCHA 高可用性機制仍然能夠順利運作,但是將會產生延遲操作、低輸送量、效能損失……等運作不佳的情況。


下列是 VMware 官方透過 VCbench 壓力測試軟體,針對 VCHA 高可用性運作環境進行壓力測試的結果。其中採用 64-clients 方式為最貼近實務應用的工作負載,當延遲時間高達 5 ms 時那麼傳輸量將會下降 9 %,倘若延遲時間高達 10 ms 時傳輸量更會下降 15 %。若是更進一步,採用 256-clients 方式以更極端的工作負載方式進行壓測時,當延遲時間高達 5 ms 時那麼傳輸量將會下降 23 %,倘若延遲時間高達 10 ms 時傳輸量更會下降 27 %。

圖 4、透過 VCbench 針對 VCHA 網路環境進行壓力測試的統計數據





vMotion 即時遷移的安全性

過去,在 VMware vSphere 虛擬化運作環境中,針對 vMotion 線上遷移傳輸流量的規劃及設計,除了應規劃獨立專用的網路環境以便快速遷移線上運作的 VM 虛擬主機之外,規劃獨立專用網路環境的另一個考量便是「安全性」

因為,預設情況下當 vSphere 管理人員透過 vMotion 線上遷移機制,將線上運作中的 VM 虛擬主機從來源端 ESXi 主機,傳輸至目的端 ESXi 主機的過程中 vMotion 傳輸流量並「未進行加密」。同時,透過 vMotion 所傳輸的是 VM 虛擬主機的「記憶體狀態」,惡意攻擊者有可能在傳輸期間修改記憶體狀態內容,進而達到破壞 VM 虛擬主機應用程式或作業系統的目的,所以規劃獨立專用網路環境除了網路頻寬獨享之外,同時也達到 vMotion 傳輸流量安全性隔離的效果。

在 2015 年 3 月推出的 VMware vSphere ESXi 6.0 版本中,vMotion 線上遷移傳輸機制打破地域及環境的限制。新版 vMotion 即時遷移機制不只可以跨越 vSwitch 虛擬交換器,以及跨越不同的 vCenter Server 伺服器之外更可以跨越地域的限制,只要執行 vMotion 線上遷移的網路環境,能夠支援封包延遲時間在 100 ms 之內的話,那麼就能達成跨越地域限制的 vMotion 即時遷移。

現在,最新 VMware vSphere 6.5 版本當中,支援將 vMotion 線上遷移傳輸流量「加密」機制,透過 AES-GCM 加密標準將 VMkernel 的 vMotion 即時遷移流量,進行加密的動作達到高安全性的 vMotion 即時遷移。

圖 5、加密 vMotion 即時遷移傳輸數據運作示意圖



vMotion 加密技術運作架構

在 VMware vSphere 6.5 運作環境中,加密 vMotion 運作機制採用內嵌於 ESXi 主機 VMkernel 當中,並整合通過 FIPS 密碼模組檢測標準的 vmkcrypto 模組及搭配 AES-GCM 標準加密演算法,然後透過 TCP 通訊協定傳輸「vMotion 中繼資料」(vMotion Metadata)

事實上,加密 vMotion 運作機制並未依賴 SSL 或 IPSec 技術來加密 vMotion 即時遷移流量,相反的它著重在 TCP 通訊協定層級中達到加密的目的,主要原因在於考量 vMotion 即時遷移的運作效能。舉例來說,倘若採用 SSL 加密技術保護 vMotion 即時遷移流量時,因為 SSL 加密為「計算密集型」(Compute Intensive)的運作機制,所以 vMotion 即時遷移流量採用 SSL 加密技術的話,將會導致 ESXi 主機運算效能過多的額外開銷。

倘若採用 IPSec 加密技術保護 vMotion 即時遷移流量時,將會讓 vMotion 即時遷移受到限制,因為 ESXi 主機「僅」支援在 IPv6 網路環境中採用 IPSec 加密技術,在 IPv4 網路環境中並不支援 IPSec 加密技術。

因此,採用 VMkernel 內 vmkcrypto 模組的加密機制,除了有效讓 vMotion 避免發生效能損失的情況之外,透過 TCP 通訊協定傳輸的方式能夠讓加密 / 解密的工作負載,平均分散到 CPU 處理器的多個運算核心上。

當 vCenter Server 準備遷移線上運作的 VM 虛擬主機時,將會隨機產生 1 個「One time 256-bit」的加密金鑰,同時除了隨機 256-bit 加密金鑰之外還會搭配「64-bit 隨機數」成為 vMotion 遷移規範,然後將這個 vMotion 遷移規範傳遞給來源端及目的端 ESXi 主機,所以在進行 VM 虛擬主機 vMotion 線上遷移作業時,便會透過「256-bit 加密金鑰+ 64-bit 隨機數」的 vMotion 遷移規範,在 2 台 ESXi 主機之間以 vMotion 專屬網路環境進行傳輸,確保 2 台 ESXi 主機之間傳輸的遷移流量無法被惡意人士所複製或竄改。

值得注意的是,這個 256-bit 的加密金鑰並非採用 vCenter Server Key Manager 產生,而是 vCenter Server 會為每次的 vMotion 即時遷移工作任務,自動產生 1 個新的 256-bit 加密金鑰,並且在 vMotion 線上遷移任務結束後便會「捨棄」該加密金鑰。同時,剛才已經提到加密 vMotion 運作機制,是採用 VMkernel 內的 vmkcrypto 模組達成,因此並不需要專用的硬體設備即可達成。

倘若,執行 vMotion 即時遷移工作任務並非 2 台 ESXi 主機,而是「跨越」不同台 vCenter Server 時則會有些許不同。簡單來說,在執行跨 vCenter Server 進行加密 vMotion 即時遷移時,與剛才說明的加密 vMotion 即時遷移運作原理相同,唯一不同的部分在於「256-bit 加密金鑰 + 64-bit 隨機數」的 vMotion 遷移規範,將會從來源端 vCenter Server 透過「SSL」傳送到目的端 vCenter Server。

圖 6、跨 vCenter Server 執行加密 vMotion 即時遷移傳輸數據運作示意圖



組態設定加密 vMotion 機制

由於加密 vMotion 即時遷移機制不需要專用的硬體設備即可達成,因此可以隨時針對希望保護的 VM 虛擬主機進行啟用的動作即可。在實務應用上,通常會針對重要工作任務或存放企業及組織機敏資料的 VM 虛擬主機進行套用,例如,負責線上營運服務 SQL 資料庫伺服器。

請透過 vSphere Web Client 管理工具登入 vCenter Server 管理平台後,依序點選「首頁>主機和叢集」圖示,點選欲啟用加密 vMotion 即時遷移機制的 VM 虛擬主機後,按下滑鼠右鍵並於右鍵選單中選擇編輯設定,此時在彈出的 VM 虛擬主機組態設定視窗中,點選至「虛擬機器選項」頁籤後於「Encrypted vMotion」子項目中,在下拉式選單內看到下列 3 種加密 vMotion 即時遷移機制設定值:

  • Disabled: 停用加密 vMotion 即時遷移機制,有可能導致 VM 虛擬主機在執行 vMotion 即時遷移的過程中,遭受中間人攻擊讓惡意攻擊者在傳輸期間修改記憶體狀態內容,進而達到破壞 VM 虛擬主機應用程式或作業系統的目的。
  • Opportunistic: 預設值,當來源端及目的端 ESXi 主機都支援加密 vMotion 即時遷移機制時,也就是 2 台 ESXi 主機皆為 ESXi 6.5 版本,那麼在執行 vMotion 即時遷移的過程中便會加密傳輸流量。倘若有任何一端不支援,例如,目的端 ESXi 主機採用 ESXi 6.0 或更舊的版本,那麼在執行 vMotion 即時遷移的過程中便不會加密 vMotion 傳輸流量。
  • Required: 來源端及目的端 ESXi 主機都必須支援加密 vMotion 即時遷移機制,倘若有任何一端不支援便無法執行 vMotion 即時遷移機制。同時,當 VMware 叢集啟用 DRS 自動化負載平衡機制後,那麼 DRS 便僅會選擇支援加密 vMotion 即時遷移機制的目的端 ESXi 主機。


圖 7、組態設定 VM 虛擬主機啟用加密 vMotion 即時遷移機制



部署加密 vMotion 的最佳作法

雖然,採用加密 vMotion 即時遷移機制,能夠達到保護 vMotion 即時遷移流量並對於 ESXi 主機的工作負載影響最小,舉例來說,在 20 GbE 的網路環境中執行 vMotion 即時遷移作業,「來源端」ESXi 主機上倘若未啟用 vMotion 加密機制僅需 1 Core 運算核心資源,倘若啟用 vMotion 加密機制則需要 2.2 Cores 運算核心資源,相較之下在「目的端」ESXi 主機上的工作負載差距更小,倘若未啟用 vMotion 加密機制需 2.5 Cores 運算核心資源,倘若啟用 vMotion 加密機制則需要 3.3 Cores 運算核心資源。

從測試結果可知,在執行 vMotion 即時遷移時來源端比目的端需要更多的 CPU 運算資源開銷,因為 vMotion 接收程式碼路徑比起傳輸程式碼路徑需要更多 CPU 運算資源,同時在加密及解密 vMotion 即時遷移流量的開銷也不同。事實上,從測試結果可以看到開啟加密 vMotion 即時遷移機制後,每增加 10 Gb/s 的網路流量對於 CPU 運算資源開銷,在來源端或目的端 ESXi 主機都只需要增加 1.x Core 運算核心資源。

圖 8、啟用及停用加密 vMotion 即時遷移機制 CPU 運算資源開銷比較圖表

同時,為了確保在 VMware vSphere 6.5 運作環境中,啟用加密 vMotion 即時遷移機制時能夠得到最佳效能,VMware 的最佳建議作法如下:

  • 雖然,啟用加密 vMotion 即時遷移機制並不需要任何硬體設備,但是在選擇 ESXi 主機硬體伺服器的 CPU 處理器時,VMware 強烈建議選擇具備「高階加密標準新指令」(Advanced Encryption Standard New Instruction,AES-NI)指令集功能,以便啟用加密 vMotion 即時遷移機制時,能夠對來源端及目的端 ESXi 主機的 CPU 工作負載降至最低。
  • 雖然,在剛才啟用及停用加密 vMotion 即時遷移機制 CPU 運算資源開銷比較圖表中,我們已經知道每增加 10 Gb/s 網路頻寬,對於來源端及目的端 ESXi 主機的 CPU 運算資源開銷僅約增加 1.x Core。但是,這僅用於處理 vMotion 網路流量的 CPU 使用率,對於 ESXi 主機整體處理 vMotion 工作任務來說至少需要 2 Cores 運算資源,因此應確保 ESXi 主機具備足夠的 CPU 運算資源,以便確保 vMotion 即時遷移工作任務能快速且順利執行。
  • 不管啟用或停用加密 vMotion 即時遷移機制,對於 vMotion 即時遷移運作效能的最佳建議作法都是相同的。有關 VMware vSphere 6 效能調校最佳實務的詳細資訊,請參考本雜誌<第 118 期 - VMware vSphere 6.0 效能調校最佳實務>文章內容。


圖 9、啟用及停用 AES-NI 加密指令集對於工作負載的效能影響比較圖表





結語

透過本文的說明及最佳建議作法相信讀者已經了解,在新版的 vSphere 6.5 當中採用 vCSA 建立原生 VCHA 高可用性機制的時要點,以及在規劃 vMotion 即時遷移網路環境時,除了注意獨立隔離且專用的網路環境之外,也應針對企業及組織線上營運或存有機敏資料的 VM 虛擬主機,開啟加密 vMotion 即時遷移機制避免遭受中間人攻擊,甚至被竄改記憶體狀態導致資安事件。

課程簡介

  • 熟悉 SDDC 軟體定義資料中心內 3 大組成元件,SDC 軟體定義運算、SDS 軟體定義儲存、SDN 軟體定義網路。
  • 熟悉 VMware vSphere SDS 軟體定義儲存概念,規劃設計 VMware vSAN(Virtual SAN) 運作環境。
  • 熟悉 Microsoft SDS 軟體定義儲存概念,規劃設計 Windows Server 2016 S2D(Storage Space Direct) 運作環境。



課程資訊

日期: 2017/7/8 ~ 2017/7/22
時間: 每週六 09:00 ~ 17:00
地點: 台中科技大學 (台中市北區三民路 91 號 2 樓)
網址: 全方位企業私有雲之 SDS 軟體定義儲存實務班




前言

最近工作關係開始玩 CentOS 了,本次實作環境中採用的是 CentOS 7.3 x86-64 (Kernel version 3.10.0-514.el7.x86_64) 映像檔,也就是新版 CentOS 7.3 最小化安裝版本 (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.3 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 ceph ceph-mon dhcp dhcpv6 dhcpv6-client
dns docker-registry dropbox-lansync freeipa-ldap freeipa-ldaps freeipa-replication ftp high-availability
http https imap imaps ipp ipp-client ipsec iscsi-target kadmin kerberos kpasswd ldap ldaps libvirt libvirt-tls
mdns mosh mountd ms-wbt mysql nfs ntp openvpn pmcd pmproxy pmwebapi pmwebapis pop3 pop3s postgresql privoxy
proxy-dhcp ptp pulseaudio puppetmaster radius rpc-bind rsyncd samba samba-client sane smtp smtps snmp snmptrap
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 了,本次實作環境中採用的是 CentOS 7.3 x86-64 (Kernel version 3.10.0-514.el7.x86_64) 映像檔,也就是新版 CentOS 7.3 最小化安裝版本 (Minimal Install),那麼開始來玩玩吧。💪



實作環境




Systemd 是什麼?

簡單來說,從 CentOS 7 版本開始在管理系統的部分,已經從過往傳統的 Runlevel (/etc/rc.d/init.d) 改為新一代的 systemd  (/etc/systemd/system)。因此,倘若查看舊有 Runlevel 組態設定檔 (/etc/inittab) 內容會發現是空的 (詳細資訊請參考 RHEL 7 System Administrator Guide - Chapter 9. Managing Services with systemd)。

圖、systemd 系統運作架構示意圖
圖片來源: systemd - Wikipedia



CentOS 7 開機程序

談到 CentOS 的 Systemd 啟動模式等級,便要先了解一下整個 CentOS 開機過程。透過下列的開機流程說明,便會了解到在 Systemd 啟動模式,為何能夠掌控系統後半段開機階段的相關服務啟動及關閉。下列開機流程是以安裝於 x86 硬體上的 CentOS 系統進行說明 (詳細資訊請參考 Overview of systemd for RHEL 7 - Red Hat Customer Portal):

  • 從 BIOS 所選的媒體裝置 (例如,本機硬碟) 載入 Boot Loader (RHEL 7 / CentOS 7 採用 GRUB2)。
  • 啟動 Kernel Initial RAM Disk
  • Systemd 執行程序初始化系統並啟動所有系統服務 (讀取 default.target 內容)。
  • Multi-User Mode (/lib/systemd/system/multi-user.target) 裡面有一行 Requires=basic.target 內容,表示系統將會載入  Basic.traget  (載入 RHEL7 System)。
  • Basic.traget (/usr/lib/systemd/system/basic.target) 裡面有一行 Requires=sysinit.target 內容,表示系統將會載入  Sysinit.traget (載入 System Initialization Services)。
  • Sysinit.target (/usr/lib/systemd/system/sysinit.target) 裡面有一行 Wants=local-fs.target swap.target 內容,表示將會載入 local-fs.target swap.target (執行 Mounting File Systems 及 Enabling Swap Devices)。此外,還會處理 enable logging、set kernel options、start the udevd daemon to detect hardware、allow file system decryption、iSCSI、multipath、LVM monitoring、RAID services。
  • local-fs.target (/usr/lib/systemd/system/local-fs.target) 裡面有一行 After=local-fs-pre.target 內容,表示等 local-fs-pre.target 完成後才載入。




Systemd 啟動模式等級

本文實作環境採用 CentOS 7.3 Minimal Install,預設情況下便會採用「Multi-User Mode」(類似舊有的 Runlevel 3 運作環境)。你可以透過查看「/etc/systemd/system/default.target」內容,或者執行「systemctl get-default」指令即可查詢,目前 CentOS 主機的啟動模式等級。
# ls -l /etc/systemd/system/default.target
lrwxrwxrwx. 1 root root 37 May 19 16:28 /etc/systemd/system/default.target -> /lib/systemd/system/multi-user.target
# systemctl get-default
multi-user.target




接著,我們可以透過查看「/etc/systemd/system/multi-user.target.wants」內容,或「systemctl list-units --type service |grep running」指令了解 Multi-User Mode 的運作模式預設會啟用哪些系統服務。
# ls -l /etc/systemd/system/multi-user.target.wants
total 0
lrwxrwxrwx. 1 root root 38 May 19 16:25 auditd.service -> /usr/lib/systemd/system/auditd.service
lrwxrwxrwx. 1 root root 37 May 19 16:24 crond.service -> /usr/lib/systemd/system/crond.service
lrwxrwxrwx. 1 root root 47 May 19 17:22 hv_fcopy_daemon.service -> /usr/lib/systemd/system/hv_fcopy_daemon.service
lrwxrwxrwx. 1 root root 45 May 19 17:22 hv_kvp_daemon.service -> /usr/lib/systemd/system/hv_kvp_daemon.service
lrwxrwxrwx. 1 root root 45 May 19 17:22 hv_vss_daemon.service -> /usr/lib/systemd/system/hv_vss_daemon.service
lrwxrwxrwx. 1 root root 42 May 19 16:25 irqbalance.service -> /usr/lib/systemd/system/irqbalance.service
lrwxrwxrwx. 1 root root 37 May 19 16:25 kdump.service -> /usr/lib/systemd/system/kdump.service
lrwxrwxrwx. 1 root root 39 May 19 16:25 postfix.service -> /usr/lib/systemd/system/postfix.service
lrwxrwxrwx. 1 root root 40 May 19 16:24 remote-fs.target -> /usr/lib/systemd/system/remote-fs.target
lrwxrwxrwx. 1 root root 39 May 19 16:25 rsyslog.service -> /usr/lib/systemd/system/rsyslog.service
lrwxrwxrwx. 1 root root 36 May 19 16:25 sshd.service -> /usr/lib/systemd/system/sshd.service
lrwxrwxrwx. 1 root root 37 May 19 16:25 tuned.service -> /usr/lib/systemd/system/tuned.service
# systemctl list-units --type service |grep running
auditd.service                     loaded active running Security Auditing Service
crond.service                      loaded active running Command Scheduler
dbus.service                       loaded active running D-Bus System Message Bus
firewalld.service                  loaded active running firewalld - dynamic firewall daemon
getty@tty1.service                 loaded active running Getty on tty1
hv_fcopy_daemon.service            loaded active running Hyper-V FCOPY daemon
hv_kvp_daemon.service              loaded active running Hyper-V KVP daemon
hv_vss_daemon.service              loaded active running Hyper-V VSS daemon
polkit.service                     loaded active running Authorization Manager
postfix.service                    loaded active running Postfix Mail Transport Agent
rsyslog.service                    loaded active running System Logging Service
sshd.service                       loaded active running OpenSSH server daemon
systemd-journald.service           loaded active running Journal Service
systemd-logind.service             loaded active running Login Service
systemd-udevd.service              loaded active running udev Kernel Device Manager
tuned.service                      loaded active running Dynamic System Tuning Daemon


倘若,希望了解支援哪些運作層級類型,請執行「systemctl list-units --type=target」指令即可查詢。
# systemctl list-units --type=target
UNIT                  LOAD   ACTIVE SUB    DESCRIPTION
basic.target          loaded active active Basic System
cryptsetup.target     loaded active active Encrypted Volumes
getty.target          loaded active active Login Prompts
local-fs-pre.target   loaded active active Local File Systems (Pre)
local-fs.target       loaded active active Local File Systems
multi-user.target     loaded active active Multi-User System
network-online.target loaded active active Network is Online
paths.target          loaded active active Paths
remote-fs.target      loaded active active Remote File Systems
slices.target         loaded active active Slices
sockets.target        loaded active active Sockets
swap.target           loaded active active Swap
sysinit.target        loaded active active System Initialization
timers.target         loaded active active Timers

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

14 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.




Systemctl 系統服務管理常用參數

在傳統的 Runlevel 運作環境中,我們常常會使用「service / chkconfig」指令來管理系統服務。現在,新一代的 Systemd 運作環境中一律使用「systemctl」指令來管理系統服務即可。下列為搭配 systemctl 指令管理系統服務的常用參數:

  • status: 查詢指定的系統服務運作狀態,例如,systemctl status sshd。
  • stop: 停止指定的系統服務,例如,systemctl stop sshd。
  • start: 啟動指定的系統服務,例如,systemctl start sshd。
  • enable: 設定指定的系統服務開機時自動啟動,例如,systemctl enable sshd。
  • disable: 設定指定的系統服務開機時自動啟動,例如,systemctl disable sshd。
  • list-dependencies: 查詢指定的系統服務相依性資訊,例如,systemctl list-dependencies sshd。
  • list-units: 查詢系統服務類型資訊,例如,systemctl list-units --type service 或 systemctl list-units --type mount。
  • list-unit-files: 列出所有系統服務運作狀態,例如,systemctl list-unit-files。

# systemctl status sshd
sshd.service - OpenSSH server daemon
   Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2017-05-25 14:35:21 CST; 1h 14min ago
     Docs: man:sshd(8)
           man:sshd_config(5)
  Process: 18018 ExecStart=/usr/sbin/sshd $OPTIONS (code=exited, status=0/SUCCESS)
 Main PID: 18020 (sshd)
   CGroup: /system.slice/sshd.service
           └─18020 /usr/sbin/sshd

May 25 14:35:21 centos73.weithenn.org systemd[1]: Starting OpenSSH server daemon...
May 25 14:35:21 centos73.weithenn.org systemd[1]: PID file /var/run/sshd.pid not readable (yet?) after start.
May 25 14:35:21 centos73.weithenn.org sshd[18020]: Server listening on 0.0.0.0 port 22.
May 25 14:35:21 centos73.weithenn.org systemd[1]: Started OpenSSH server daemon.
May 25 14:37:54 centos73.weithenn.org sshd[18150]: Accepted password for weithenn from 192.168.16.184 port 60836 ssh2

前言

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



實作環境




擴充 YUM 套件管理工具 RPM 數量

雖然在上一篇文章中,我們已經將 YUM 套件管理工具的鏡像站台,設定為台灣鏡像站台來加快套件下載速度。然而,儘管官方的 YUM 套件管理工具中套件數量已經不少,但目前官方套件數量中僅包含必要套件,例如,常常用來管理 MySQL 資料庫的 PhpMyAdmin 套件,就未包含在內建的 YUM 軟體套件庫 (RPM Repository) 當中。

雖然我們可以自行下載 PhpMyAdmin 套件並手動安裝到系統上,但個人的主機管理習慣,是盡量使用 YUM 套件管理工具來處理 RPM 套件的安裝、移除、升級…等作業。因此,我們可以透過第 3 方且獲社群認可的軟體套件庫,在安裝後擴充 YUM 套件管理工具中的套件數量。首先,我們可以執行「yum repolist」指令,查詢目前 CentOS 主機軟體套件庫中所支援的套件數量,從查詢結果中可以看到目前套件總數為「11,346」
# yum repolist
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: ftp.tc.edu.tw
 * extras: ftp.tc.edu.tw
 * updates: ftp.tc.edu.tw
repo id                                 repo name                                 status
base/7/x86_64                           CentOS-7 - Base                           9,363
extras/7/x86_64                         CentOS-7 - Extras                           337
updates/7/x86_64                        CentOS-7 - Updates                        1,646
repolist: 11,346

圖、目前 YUM 管理工具套件總數量

在本文中,我們將會安裝「EPEL (Extra Packages for Enterprise Linux)」「ELRepo (The Community Enterprise Linux Repository)」,獲社群認可的第 3 方軟體套件庫。在下列操作中,可以看到當系統尚未安裝 EPEL 軟體套件庫以前,透過 YUM 管理工具套件庫 (RPM Repository) 是搜尋不到 PhpMyAdmin 套件的。
# yum search phpmyadmin
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: ftp.tc.edu.tw
 * extras: ftp.tc.edu.tw
 * updates: ftp.tc.edu.tw
Warning: No matches found for: phpmyadmin
No matches found

圖、無法搜尋到 phpmyadmin 套件



安裝 EPEL 第 3 方軟體套件庫

請執行「yum -y install epel-release」指令安裝 EPEL 第 3 方軟體套件庫。
# yum -y install epel-release
Loaded plugins: fastestmirror
base                                                                                                       | 3.6 kB  00:00:00
extras                                                                                                     | 3.4 kB  00:00:00
updates                                                                                                    | 3.4 kB  00:00:00
Loading mirror speeds from cached hostfile
 * base: ftp.tc.edu.tw
 * extras: ftp.tc.edu.tw
 * updates: ftp.tc.edu.tw
Resolving Dependencies
--> Running transaction check
---> Package epel-release.noarch 0:7-9 will be installed
--> Finished Dependency Resolution
Dependencies Resolved
==================================================================================================================================
 Package                             Arch                          Version                    Repository                     Size
==================================================================================================================================
Installing:
 epel-release                        noarch                        7-9                        extras                         14 k

Transaction Summary
==================================================================================================================================
Install  1 Package
Total download size: 14 k
Installed size: 24 k
Downloading packages:
epel-release-7-9.noarch.rpm                                                                                |  14 kB  00:00:00
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  Installing : epel-release-7-9.noarch                                                                                        1/1
  Verifying  : epel-release-7-9.noarch                                                                                        1/1
Installed:
  epel-release.noarch 0:7-9
Complete!


圖、安裝 EPEL 軟件庫

順利安裝 EPEL 軟體套件庫後,便可以順利找到 phpmyadmin 套件,當然後續也可以透過 yum 指令進行下載及安裝等套件管理作業。
# yum search phpmyadmin
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: ftp.tc.edu.tw
 * epel: mirrors.ustc.edu.cn
 * extras: ftp.tc.edu.tw
 * updates: ftp.tc.edu.tw
================================ N/S matched: phpmyadmin ================================
php-phpmyadmin-motranslator.noarch : Translation API for PHP using Gettext MO files
php-phpmyadmin-shapefile.noarch : ESRI ShapeFile library for PHP
phpMyAdmin.noarch : Handle the administration of MySQL over the World Wide Web

  Name and summary matches only, use "search all" for everything.

圖、順利找到 phpmyadmin 套件

此時,可以執行「yum repolist」指令,從查詢結果中可以看到原本套件總數只有11,346,在安裝 EPEL 軟體套件庫後增加了「11,670」個套件,所以套件總數提升為「23,016」
# yum repolist
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
 * base: ftp.tc.edu.tw
 * epel: ftp.riken.jp
 * extras: ftp.tc.edu.tw
 * updates: ftp.tc.edu.tw
repo id                        repo name                                                     status
base/7/x86_64                  CentOS-7 - Base                                                9,363
*epel/x86_64                   Extra Packages for Enterprise Linux 7 - x86_64                11,670
extras/7/x86_64                CentOS-7 - Extras                                                337
updates/7/x86_64               CentOS-7 - Updates                                             1,646
repolist: 23,016

圖、EPEL 軟件庫增加 11,670 個套件



安裝 ELRepo 第 3 方軟體套件庫

接著,我們執行相關指令來安裝 ELRepo 軟件庫。然後,再次執行「yum repolist」指令,查詢目前 CentOS 主機軟件庫中所支援的套件數量,從查詢結果中可以看到安裝 ELRepo 軟體套件庫後增加了「184」個套件,所以套件總數提升為「23,207」
# rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
# rpm -Uvh http://www.elrepo.org/elrepo-release-7.0-2.el7.elrepo.noarch.rpm
Retrieving http://www.elrepo.org/elrepo-release-7.0-2.el7.elrepo.noarch.rpm
Preparing...                          ################################# [100%]
Updating / installing...
   1:elrepo-release-7.0-2.el7.elrepo  ################################# [100%]
[root@centos73 weithenn]# yum repolist
Loaded plugins: fastestmirror
base                                                                               | 3.6 kB  00:00:00
elrepo                                                                             | 2.9 kB  00:00:00
epel/x86_64/metalink                                                               | 5.4 kB  00:00:00
epel                                                                               | 4.3 kB  00:00:00
extras                                                                             | 3.4 kB  00:00:00
updates                                                                            | 3.4 kB  00:00:00
(1/4): extras/7/x86_64/primary_db                                                  | 151 kB  00:00:00
(2/4): epel/x86_64/updateinfo                                                      | 799 kB  00:00:00
(3/4): elrepo/primary_db                                                           | 413 kB  00:00:03
(4/4): epel/x86_64/primary_db                                                      | 4.7 MB  00:00:06
Loading mirror speeds from cached hostfile
 * base: ftp.tc.edu.tw
 * elrepo: ftp.yz.yamagata-u.ac.jp
 * epel: ftp.riken.jp
 * extras: ftp.tc.edu.tw
 * updates: ftp.tc.edu.tw
repo id                        repo name                                                            status
base/7/x86_64                  CentOS-7 - Base                                                       9,363
elrepo                         ELRepo.org Community Enterprise Linux Repository - el7                  184
epel/x86_64                    Extra Packages for Enterprise Linux 7 - x86_64                       11,674
extras/7/x86_64                CentOS-7 - Extras                                                       340
updates/7/x86_64               CentOS-7 - Updates                                                    1,646
repolist: 23,207

圖、ELRepo 軟體庫增加 184 個套件