|
保存nginx.conf文件，輸入cd ..，回到/usr/local/nginx/sbin目錄下輸入./nginx啟動nginx服務。輸入ps –ef |grep nginx查看運行的進程。
運行nginx：./nginx
重啟nginx：./nginx -s reload
停止nginx：./nginx -s stop
輸入netstat –ntlp | grep nginx查看nginx的通信端口。
輸入wget htt:\\10.190.130.78:8007就測試到配置是否成功。
2.6.在Firewall啟動狀態下運行Nginx
在Firewall啟動的情況下，其他客戶端無法訪問到htt:\\10.190.130.78:8007。
在Firewall中添加8007端口，firewall-cmd –permanent–add-port=8007/tcp，然后在輸入firewall-cmd –reload，重載成功過后，
在輸入firewall-cmd –list-all，可顯示添加的8007端口。
輸入netstat -ntlp | grep nginx查看nginx的占用端口
在其他客戶端中輸入wget
http://10.190.130.78:8007就可以訪問成功。
3.設置自定義開機系統服務
CentOS 7 使用systemd替換了SysV。Systemd目的是要取代Unix時代以來一直在使用的init系統，兼容SysV和LSB的啟動腳本，而且夠在進程啟動過程中
更有效地引導加載服務。
systemd的特性有：
支持并行化任務
同時采用socket式與D-Bus總線式激活服務；
按需啟動守護進程（daemon）；
利用 Linux 的 cgroups 監視進程；
支持快照和系統恢復；
維護掛載點和自動掛載點；
各服務間基于依賴關系進行精密控制。
檢視和控制systemd的主要命令是systemctl。該命令可用于查看系統狀態和管理系統及服務。詳見man 1 systemctl。
輸入vim /usr/lib/systemd/system/nginx.service進入文件編輯。
將以下內容拷貝到nginx.service文件中，然后保存。
[Unit]
Description=nginx servicedaemon
After=network.target
[Service]
Type=forking
PIDFile=/usr/local/nginx/logs/nginx.pid #nginx安裝路徑下的nginx.pid文件
ExecStart=/usr/local/nginx/sbin/nginx
ExecReload=/usr/local/nginx/sbin/nginx-s reload
ExecStop=/usr/local/nginx/sbin/nginx-s stop
PrivateTep=true
[Install]
WantedBy=multi-user.target
保存文件后，啟動nginx服務器會出現錯誤。必須要輸入systemctl daemon-reload，重載后臺服務。
輸入systemctl daemon-reload，重載后臺服務。可以使用systemctl命令對nginx進行操作
如果需要更詳細的配置，請參考：
https://www./software/systemd/man/systemd.service.html
使用單元
一個單元配置文件可以描述如下內容之一：系統服務（.service）、掛載點（.mount）、sockets（.sockets）、系統設備（.device）、交換分區（.swap）、文件路徑（.path）、啟動目標（.target）、由 systemd 管理的計時器（.timer）。詳情參閱 man 5 systemd.unit。
使用 systemctl 控制單元時，通常需要使用單元文件的全名，包括擴展名（例如 sshd.service）。但是有些單元可以在systemctl中使用簡寫方式。
如果無擴展名，systemctl 默認把擴展名當作 .service。例如 netcfg 和 netcfg.service 是等價的。
掛載點會自動轉化為相應的 .mount 單元。例如 /home 等價于 home.mount。
設備會自動轉化為相應的 .device 單元，所以 /dev/sda2 等價于 dev-sda2.device。
注: 有一些單元的名稱包含一個 @ 標記， (e.g. name@string.service): 這意味著它是模板單元name@.service 的一個實例。 string 被稱作實例標識符, 在 systemctl 調用模板單元時，會將其當作一個參數傳給模板單元，模板單元會使用這個傳入的參數代替模板中的 %I 指示符。在實例化之前，systemd 會先檢查 name@string.suffix 文件是否存在（如果存在，應該就是直接使用這個文件，而不是模板實例化了）。大多數情況下，包換 @ 標記都意味著這個文件是模板。如果一個模板單元沒有實例化就調用，該調用會返回失敗，因為模板單元中的
%I 指示符沒有被替換。
例如：systemctl start <單元>
編寫單元文件
systemd單元文件的語法來源于 XDG桌面入口配置文件.desktop文件，最初的源頭則是MicrosoftWindows的.ini文件。單元文件可以從兩個地方加載，優先級從低到高分別是：
/usr/lib/systemd/system/: 軟件包安裝的單元
/etc/systemd/system/: 系統管理員安裝的單元
注意: 當systemd運行在用戶模式下時，使用的加載路徑是完全不同的。
處理依賴關系
使用systemd時，可通過正確編寫單元配置文件來解決其依賴關系。典型的情況是，單元A要求單元B在A啟動之前運行。在此情況下，向單元A配置文件中的 [Unit] 段添加 Requires=B 和 After=B 即可。若此依賴關系是可選的，可添加 Wants=B 和 After=B。請注意 Wants= 和 Requires= 并不意味著 After=，即如果 After= 選項沒有制定，這兩個單元將被并行啟動。
依賴關系通常被用在服務（service）而不是目標（target）上。例如， network.target 一般會被某個配置網絡接口的服務引入，所以，將自定義的單元排在該服務之后即可，因為 network.target 已經啟動。
服務類型
編寫自定義的 service 文件時，可以選擇幾種不同的服務啟動方式。啟動方式可通過配置文件 [Service] 段中的 Type= 參數進行設置。
Type=simple（默認值）：systemd認為該服務將立即啟動。服務進程不會fork。如果該服務要啟動其他服務，不要使用此類型啟動，除非該服務是socket激活型。
Type=forking：systemd認為當該服務進程fork，且父進程退出后服務啟動成功。對于常規的守護進程（daemon），除非你確定此啟動方式無法滿足需求，使用此類型啟動即可。使用此啟動類型應同時指定 PIDFile=，以便systemd能夠跟蹤服務的主進程。
Type=oneshot：這一選項適用于只執行一項任務、隨后立即退出的服務。可能需要同時設置 RemainAfterExit=yes 使得 systemd 在服務進程退出之后仍然認為服務處于激活狀態。
Type=notify：與 Type=simple 相同，但約定服務會在就緒后向 systemd 發送一個信號。這一通知的實現由 libsystemd-daemon.so 提供。
Type=dbus：若以此方式啟動，當指定的 BusName出現在DBus系統總線上時，systemd認為服務就緒。
Type=idle: systemd會等待所有任務(Jobs)處理完成后，才開始執行idle類型的單元。除此之外，其他行為和Type=simple 類似。
type的更多解釋可以參考systemd.service(5)。
3.1.設置開機服務
輸入systemctl start nginx啟動nginx服務，在輸入systemctl enable nginx 設置nginx服務為開機啟動服務，最后，輸入systemctl status nginx查看nginx的運行狀態。
3.2.停止開機服務
輸入systemctl disable nginx停止開機啟動nginx服務，輸入systemctlstop nginx停止nginx服務，輸入systemctl status nginx查看nginx的運行狀態。
4.負載均衡策略
在nginx中支持的負載均衡策略如下：
輪詢加權策略（Round-Robin）：在輪詢模策略中，要求應用服務器是分布式的
最少連接策略（Least-Connected）：下一個請求是分配給最少的活動連接數服務器。
IP哈希策略（IP-Hash）：一個哈希函數用來決定那個服務器被選擇作為下一個請求處理的服務器（基于客戶端的IP地址）。
4.1.輪詢策略
http {
upstream myapp1 { #服務器組，組名：myapp1
server srv1.example.com; #web應用服務器1
server srv2.example.com; #web應用服務器2
server srv3.example.com; #web應用服務器3
}
server {
listen 80;
location / {
proxy_pass
http://myapp1; #客戶端訪問的URL
}
}
}
以上是最簡單的Nginx負載均衡配置。在upstream myapp1中有3個應用服務器實例，當負載均衡中沒有指定配置負載策略時，默認是使用輪詢權重策略。所有請求都是代理給服務器組myapp1，Nginx應用http負載均衡到分布式請求中。
在Nginx反向代理負載均衡的擴展包括：http，https，FastCGI，uwsgi，SCGI和緩存。
配置負載均衡
配置https負載均衡代替http，只使用“https”作為協議就可以了。
當設置負載均衡為FastCGI，uwsgi，SCGI，或緩存，指令分別使用fastcgi_pass，uwsgi_pass，scgi_pass，和memcached_pass。
如果可以把加權輪詢算法分為先深搜索和先廣搜索，那么nginx采用的是先深搜索算法，即將首先將請求都分給高權重的機器，直到該機器的權值降到了比其他機器低，才開始將請求分給下一個高權重的機器；第二，當所有后端機器都down掉時，nginx會立即將所有機器的標志位清成初始狀態，以避免造成所有的機器都處在timeout的狀態，從而導致整個前端被夯住。
4.2.最少連接策略
upstream myapp1 { #服務器組，組名：myapp1
least_conn; #least_conn;最少連接策略
server srv1.example.com; #web應用服務器1
server srv2.example.com; #web應用服務器2
server srv3.example.com; #web應用服務器3
}
最少連接允許控制加載應用實例，更多適合在一些花費比較長時間去完成請求的一個場景中。
用最少連接負載均衡，Nginx會盡量不要求過載繁忙的應用服務器去執行請求，分配新的請求給一個不太忙碌的服務器代替執行。
最少連接負載均衡在Nginx中被激活時，least_conn指令被用來作為服務器群組配置的一個部分。
4.3.IP哈希策略
配置IP哈希負載均衡，只需要添加ip_hash指令指向服務器(uptream) 組配置：
upstream myapp1 {
ip_hash;
server srv1.example.com;
server srv2.example.com;
server srv3.example.com;
}
每個客戶端請求都有可能發送到不同的服務器，不能保證同一個客戶端總是指向同一個服務器。如果一個客戶端必須要跟服務器的會話關聯在一起的時候，可以使用IP哈希負載均衡緩存策略。
通過獲取客戶端額IP地址，經過哈希函數的計算得到一個值，利用該值對服務器的列表大小進行取模運算，得到的值就是處理客戶端請求的服務器序號。采用IP哈希負載均衡策略，的優點是，同一個客戶端的IP地址，每次發送的請求都是指向同一臺服務器進行處理。這種方式確保來自同一個客戶端請求總是指向同一個服務器除非這個服務是無效的。
舉例子說明：
例如一個系統的會話存儲用戶信息，每次將請求發送到服務器，服務器都會從會話中獲取數據。但在負載均衡環境中，每次客戶端的每次請求都可能由不同的服務器處理，所以可能出現無法獲取的到客戶端的會話數據（由于會話數據是保存在服務器的內存中）。
4.4.權重策略
使用服務器權重策略，它也有可能影響到Nginx負載均衡算法。
在上面的例子中，服務器權重沒有配置，意味著所有指定的服務器都被視為同等資格的一個特定負載均衡策略。尤其是輪詢策略，它也意味著差不多平等地分配請求給服務器，并且快速平均地處理請求。
當權重參數被指定在一個服務器時，權重作為負載均衡決策的部分。
upstream myapp1 {
server srv1.example.com weight=3;
server srv2.example.com;
server srv3.example.com;
}
在這個配置中，每5個請求都分配給應用服務器實例如下：
3個請求將分配到serv1中，1個請求分配給srv2中，而另外1個請求則分配個srv3中。
在最近的Nginx版本中，它同樣可以與最少連接和IP哈希策略一樣去使用權重策略。
4.5.總結
輪詢策略：
優點：如果希望每個服務器都能平均處理客戶端請求可使用輪詢策略。
缺點：不支持會話管理，另外，假設有5個客戶端請求，有2臺服務器處理請求，某一臺服務器處理請求時消耗資源比較大，每次都接到消耗資源比較大的請求，那么該服務器處理能力就會下降。
IP哈希策略：
缺點：使用該策略，服務器可能不會平均處理每個請求。假設有5個客戶端請求，那么通過計算出哈希值后，可能都是由一臺服務器處理。其它的服務器可能沒有請求需要處理。
優點：支持會話管理，如果系統中使用會話處理數據，該策略比較適合。
最少連接策略：
優點：系統把新連接分配給當前連接數目最少的服務器。該算法在各個服務器運算能力基本相似的環境中非常有效。此負載均衡策略適合請求處理時間長短不一造成服務器過載的情況。
缺點：雖然某個服務器的連接數較少，但處理請求時間較長，這時候再接受請求處理，可能影響到時間效率的問題。
權重策略：
優點：如果服務器的硬件等級差別比較大，那么配置高的服務器可分配較高權重，以便處理更多的請求。而配置低的服務器可接受少量請求。
缺點：如果服務器的硬件等級一樣不太適合使用該策略。
5.健康檢查
在Nginx反向代理中實現主動或被動健康檢查，如果指定的響應服務器出現錯誤，Nginx將標記該服務器為失敗，將盡量去避免為后續的請求選擇該服務器。
設置發生在超時失敗期間連續不成功的服務器通信的max_fails指令。默認max_fails設置是1，當設置為0次時，這臺服務器的檢查檢查不啟用。Fail_timeout參數定義服務器多長時間將被標記為失敗。在服務器fail_timeout期間，Nginx不會馬上將該服務器標記為失敗的服務器，而是模擬想客戶端請求去偵查服務器，如果偵查成功，該服務器標記為在線服務器。
關于健康檢查的的插件需要花錢購買，更多的信息請參考：
https://www./products/application-health-checks/
https://www./resources/admin-guide/installing-nginx-plus/
6.附錄
6.1.systemctl命令指南
Systemctl是一個systemd工具，主要負責控制systemd系統和服務管理器。
Systemd是一個系統管理守護進程、工具和庫的集合，用于取代System V初始進程。Systemd的功能是用于集中管理和配置類UNIX系統。
在Linux生態系統中，Systemd被部署到了大多數的標準Linux發行版中，只有為數不多的幾個發行版尚未部署。Systemd通常是所有其它守護進程的父進程，
但并非總是如此。使用Systemctl管理Linux服務
6.1.1.Systemd初體驗和Systemctl基礎
6.1.1.1.1.檢查systemd安裝版本
1. 首先檢查你的系統中是否安裝有systemd并確定當前安裝的版本
# systemd –version
6.1.1.1.2.檢查systemd和systemctl的二進制文件和庫文件的安裝位置
# whereis system
# whereis systemctl
6.1.1.1.3檢查systemd是否運行
# ps -eaf | grep system
6.1.1.4.分析systemd啟動進程
# systemd-analyze
6.1.1.5.分析啟動時各個進程花費的時間
#systemd-analyze blame
6.1.1.6.分析啟動時的關鍵鏈
# systemd-analyze critical-chain
重要：Systemctl接受服務（.service），掛載點（.mount），套接口（.socket）和設備（.device）作為單元。
Systemctl是一個systemd工具，主要負責控制systemd系統和服務管理器。
Systemd是一個系統管理守護進程、工具和庫的集合，用于取代System V初始進程。Systemd的功能是用于集中管理和配置類UNIX系統。
在Linux生態系統中，Systemd被部署到了大多數的標準Linux發行版中，只有為數不多的幾個發行版尚未部署。Systemd通常是所有其它守護進程的父進程，
但并非總是如此。
使用Systemctl管理Linux服務
本文旨在闡明在運行systemd的系統上“如何控制系統和服務”。
Systemd初體驗和Systemctl基礎
1. 首先檢查你的系統中是否安裝有systemd并確定當前安裝的版本
# systemd--version
systemd 215
+PAM +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ -SECCOMP-APPARMOR
上例中很清楚地表明，我們安裝了215版本的systemd。
2. 檢查systemd和systemctl的二進制文件和庫文件的安裝位置
# whereissystemd
systemd:/usr/lib/systemd /etc/systemd /usr/share/systemd/usr/share/man/man1/systemd.1.gz
# whereis systemctl
systemctl:/usr/bin/systemctl /usr/share/man/man1/systemctl.1.gz
3. 檢查systemd是否運行
# ps -eaf | grep[s]ystemd
root 10016:27?00:00:00/usr/lib/systemd/systemd --switched-root --system--deserialize 23
root 4441016:27?00:00:00/usr/lib/systemd/systemd-journald
root 4691016:27?00:00:00/usr/lib/systemd/systemd-udevd
root 5551016:27?00:00:00/usr/lib/systemd/systemd-logind
dbus 5561016:27?00:00:00/bin/dbus-daemon --system --address=systemd:--nofork--nopidfile --systemd-activation
注意：systemd是作為父進程（PID=1）運行的。在上面帶（-e）參數的ps命令輸出中，選擇所有進程，（-a）選擇除會話前導外的所有進程，并使用（-f）參數輸出完整格式列表（即
-eaf）。
也請注意上例中后隨的方括號和例子中剩余部分。方括號表達式是grep的字符類表達式的一部分。
4. 分析systemd啟動進程
#systemd-analyze
Startup finished in487ms(kernel)+2.776s(initrd)+20.229s(userspace)=23.493s
5. 分析啟動時各個進程花費的時間
#systemd-analyze blame
8.565s mariadb.service
7.991s webmin.service
6.095s postfix.service
4.311s httpd.service
3.926s firewalld.service
3.780s kdump.service
3.238s tuned.service
1.712s network.service
1.394s lvm2-monitor.service
1.126s systemd-logind.service
....
6. 分析啟動時的關鍵鏈
#systemd-analyze critical-chain
The time after the unit is active or started is printed after the "@"character.
The time the unit takes to start is printed after the "+" character.
multi-user.target @20.222s
└─mariadb.service @11.657s+8.565s
└─network.target @11.168s
└─network.service @9.456s+1.712s
└─NetworkManager.service @8.858s+596ms
└─firewalld.service @4.931s+3.926s
└─basic.target @4.916s
└─sockets.target @4.916s
└─dbus.socket @4.916s
└─sysinit.target @4.905s
└─systemd-update-utmp.service @4.864s+39ms
└─auditd.service @4.563s+301ms
└─systemd-tmpfiles-setup.service @4.485s+69ms
└─rhel-import-state.service @4.342s+142ms
└─local-fs.target @4.324s
└─boot.mount @4.286s+31ms
└─systemd-fsck@dev-disk-by\x2duuid-79f594ad\x2da332\x2d4730\x2dbb5f\x2d85d19608096
└─dev-disk-by\x2duuid-79f594ad\x2da332\x2d4730\x2dbb5f\x2d85d196080964.device@4
重要：Systemctl接受服務（.service），掛載點（.mount），套接口（.socket）和設備（.device）作為單元。
6.1.1.7.列出所有可用單元
# systemctl list-unit-files
6.1.1.8.列出所有運行中單元
# systemctl list-units
6.1.1.9.列出所有失敗單元
# systemctl –failed
6.1.1.10.檢查某個單元是否啟用
# systemctl is-enabled nginx.service
6.1.1.11.檢查某個單元或服務是否運行
# systemctl status nginx.service
|
