LVS 四層 轉發 內存和CPU 配置簡單
NGINX:L4-L7 七層 代理 正則表達式 geoip
1.不支持自動以URL檢測 2.IP_HASH 3.負載均衡算法少 rr wrr ip_hash
haproxy:L4-L7 cookie
rr
wrr
最小連接數
source
URI
HTTP請求頭
cookie
squid Varnish ATS
Nginx+Squid Nginx+varnish Nginx+ats
73 76:2222 76:1111
client -> proxy ---> server
73 74:6666 76:2222 76:1111
client ->>proxy -->>proxy -> server
緩存：
Buffer 緩沖 寫操作 寫緩沖
Cache 緩存 讀操作 讀緩存
速度 多級
讀緩存
客戶端 瀏覽器
內存 本機內存 遠程服務器內存
硬盤 本機硬盤 遠程服務器硬盤
特性：
1.過期時間
2.強制過期
3.命中率
4.
應用層緩存：
php 5..5 Zend Opcache
pph opcache + 軟鏈接 部署完需要重啟php-fpm
redis key 大小，不建議超過2M
超過2M的key值，建議分片處理：
hash :h1 h2 h3 h4 h5
keys : xxx h1,h2, h3, h4, h5
redis集群：
1.客戶端分片 優勢:簡單 可控
缺點：手動 手動故障解決 手動數據遷移
2.Redis cluster
3.Proxy
11012
數據庫 表
key hash
雲服務
雲計算前：
IDC托管：買台機器-放到IDC-安裝系統-部署應用-買個域名-綁定上去-對外訪問
ICP備-ICP證-文網文-、 IDC租用、VPS、虛擬主機
傳統數據中心面臨的問題：
資源利用率低：
資源分配不合理：
自動化能力差：
初始成本高：
雲計算來了：
1.一種模式 2.雲計算必須通過網絡是使用 3.彈性計算、按需計算、快速擴展
不用關心基礎設施，都有雲計算提供商提供
雲計算分類：
私有雲：
公有雲：
混合雲：
雲計算分層：IAAS,PAAS,SAAS
虛擬化：
內合計虛擬化技術KVM
使用場景分類：服務器虛擬化，桌面虛擬化、應用虛擬化。
前期總結：
1.運維標准，ITIL
2.自動化安裝-cobbler
3.監控體系-Zabbix
4.配置管理-SaltStack
5.自動化代碼部署
6.日志平台-ELKStack
持續集成和自動化部署
環境規划
1.開發環境-開發者本地有自己的環境，然后運維需要設置的開發環境，大家公用的服務。例如：開發數據庫mysql,其他：Redis、Memcached。
2.測試環境：功能測試環境和性能測試環境。
3.預生產環境：生產環境集群中的某一個節點擔任。
4.生產環境：直接對用戶提供服務的環境
預生產環境產生的原因：
數據庫不一致：測試環境和生產環境數據庫肯定是不一樣的。
使用生產環境的聯調接口。例如，支付接口。
已有一個可以上線的代碼在代碼倉庫
我們如何設計一套生產自動化部署系統
1.規划
2.實現
3.總結和擴展
4.在生產環境應用
1.1個集群10個節點。實現，一鍵部署這個10個節點。
2.一鍵回滾到任意版本
3.一鍵回滾到上一個版本
部署 回滾
部署：
1.代碼在哪里：SVN、git。
2.獲取什么版本代碼？
svn+git 直接拉取master
svn: 指定版本號
git:指定tag
3.差異解決：
1）各個節點直接差異：
2）配置文件未必一樣：crontab.xml 預生產節點
3）代碼倉庫和實際的差異。配置文件是否放在代碼倉庫中。Config.sample 配置文件只在部署上有，單獨的項目。
4.如何更新。Java Tomcat。需要重啟
5.測試。
6.串行和並行 分組部署
7.如何執行 1）shell ./執行。 2）web界面
實戰：
1.用戶 所有的web服務，都應該使用普通用戶。所有的web服務都不應該監聽80端口，除了負載均衡。8080
useradd www
2.ssh-keygen -t rsa
Salt State SLS描述文件 YAML
名稱ID聲明
apache-install: #ID聲明 高級狀態，ID必須唯一
pkg.installed: #State 聲明 狀態聲明
- names:
- httpd
- httpd-devel
apache-service: #ID聲明 高級狀態，ID必須唯一
service.running: #State 聲明 狀態聲明
- name: httpd #屬性，選項聲明
- enable: True
LAMP架構
步驟： 模塊
1.安裝軟件包 pkg
2.修改配置文件 file
3.啟動服務 service
pkg.installed #安裝
pkg.latest #確保最新版本
pkg remove #卸載
pkg.purge # 卸載並刪除配置文件
pkg.installed
一個ID聲明下面。狀態模塊不能重復使用
#同時安裝多個包
common_packages:
pkg.installed: - pkgs: - unzip - dos2unix - salt-minion: 2015.8.5-1.el6
lamp-pkg:
pkg.installed:
- pkgs:
- httpd
- php
- mysql
- php-mysql
- mariadb-server
- php-cli
- php-mbstring
apache-config:
file.managed:
- name: /etc/httpd/conf/httpd.conf
- source: salt://lamp/files/http.conf
- group: root
- user: root
- mode: 644
php-config:
file.managed:
- name: /etc/php.ini
- source:salt://lamp/files/http.conf
- user: root
- group: root
- mode: 644
salt:// 表示當前環境的根目錄。例如：
file_roots:
base:
- /home/script/salt
那么salt://lamp/files/http.conf 表示 /home/script/salt/lamp/files/http.conf
狀態間關系：
1.我依賴誰 require
2.我被誰依賴 require_in
3.我監控誰 watch
1).如果 apache-config這個ID的狀態發生變化就reload
2）如果不加reload: True,那么就restart
4.我被誰監控
5.我引用誰 include
6.我擴展誰
如何編寫SLS技巧：
1.按狀態分類 如果單獨使用，很清晰
2.按服務分類 可以被其他的SLS include。例如：LAMP include mysql的服務
yaml---jinja
兩種分隔符: {% ... %} 和 {{ ... }}
構建個模板需要3步：
1.告訴File模塊，你要使用jinja
- template: jinja
2.你要列出參數列表
- defaults:
- PORT: 88
3.模板引用
{{ PORT }}
模板里面支持： salt執行模塊 grinas pillar 進行賦值
1.寫在模板文件中
Grainas：Listen {{ grains['fqdn_ip4'][0] }}:{{ PORT }}、
salt遠程執行模塊：{{ salt['network.hw_addr']('eth0') }}
pillar {{ pillar['apache'] }}
2.寫在SLS里面的defaults,變量列表中
- defaults:
IPADDR: {{ grains['fqdn_ip4'][0] }}
PROT: 88
所有的minion 出去的Pillar中item rsyslog的值是server的minion
頭腦風暴：
1.系統初始化
2.功能模塊：設置單獨的目錄 haproxy nginx php mysql memcached
盡可能的全、獨立
3.業務模塊： 根據業務類型划分，例如web服務。論壇 bbs
include
干活：
1.salt環境配置
開發 測試 （功能測試環境、性能測試環境） 預生產 生產
1）base 基礎環境
init 目錄 ，環境初始化：1.dns配置 2.history記錄時間 3.記錄命令操作 4.內核參數優化 5.安裝yum倉庫 6.安裝zabbix-agent
2）prod 生產環境
本地可用的端口范圍：
作為客戶端發起連接的時候。
socket 網絡套接字
五元組
源地址 源端口 目的地址 目的端口 協議
TCP 你要訪問baidu x.x.x.x 9876 x.x.x.x 80
深入學習saltstack遠程執行：
salt ‘*’ cmd.run 'w'
命令：salt
目標：'*'
模塊：cmd.run 自帶150+模塊。自己寫模塊
返回：執行后結果的返回，Returners
目標：Targeting
兩種：一種和mininon ID有關
一種和Minion ID無關
1.Minion ID有關的方法。
Minion ID
通配符
salt '*' test.ping
salt 'linux[1|2]' test.ping
列表
salt 'master,slave' test.ping
正則表達式：
salt -E 'linu(node1|node2)*' test.ping
所有匹配目標的方式，都可以用到top file里面來指定目標
主機名設置方案：
1.IP地址
2.根據業務來進行設置
redis-node1-redis-03-idc04-soa.example.com
redis-node1 redis第一個節點
redis04 集群
idc04 機房
soa 業務線
2.Minion ID 無關
子網，IP地址
salt -s 192.168.53.11 test.ping
salt -s 192.168.53.0/24 test.ping
模塊：自帶模塊
返回程序：
編寫模塊：
1.放哪 /svr/salt/_modules
2.命名：文件名就是模塊名，例如 my_disk.py
3.刷新
saltstack快速入門：
python 編寫 REST API
三大功能：遠程執行
配置管理（狀態）
雲管理
同類產品：Puppet + func ruby 編寫，ansible python 編寫
四種運行方式：
Local：
Minion/Master C/S架構
Syndic - zabbix Proxy
Salt SSH
典型案例：
1.遠程執行 salt "*" cmd.run 'uptime'
2.State 你要寫一個文件。格式：YAML 后綴 .sls
YAML:三板斧
1.縮進（層級關系）：兩個空格，不能使用tab鍵。
2.冒號 key: value 冒號后面有個空格
3.短橫線 - list1 短橫線后面有個空格
- list2
SaltStack 數據系統
Grains （谷粒）：靜態數據 當Minion啟動的時候收集的Minion本地的相關信息
操作系統版本 ，內核版本，CPU，內存，硬盤。設備型號。序列號
1.資產管理。信息查詢
2.用於目標選擇 salt -G 'os:centos' cmd.run 'w'
3.配置管理中使用。
TOP File 使用案例：
base:
'slave':
- web.apache
'roles:apache':
- match: grain
-web.apache
配置管理案例：
開發一個Grains：
python: 寫一個Python腳本，返回一個字典就可以了。
#!/usr/bin/env python
#-*- coding: utf-8 -*-
def my_grains():
#初始化一個grains字典
grains = {}
#設置字典中的key-value
grains['iaas'] = 'openstack'
grains['edu'] = 'oldboyedu'
#返回這個字典
return grains
刷新Grains：
salt ‘*’ saltutil.sync_grains
Grains優先級：
1.系統自帶
2.grains文件寫的
3.minion配置文件寫的
4.自己寫的
Pillar （柱子）
Pillar 動態的，給特定的minion指定特定的數據。只有指定的minion自己能看到自己的數據。
pillar_roots top file
1.寫pillar sls
2.top file
[root@master web]# salt 'master' pillar.item hehe
master:
----------
hehe:
----------
apache:
httpd
pillar使用場景：
1.目標選擇
Grains VS Pillar
類型 定義位置 數據采集方式 應用場景
Grains 靜態 minion minion啟動收集 數據查詢 目標選擇 配置管理
Pillar 動態 master master自定義 目標選擇 配置管理 敏感數據
工作流：
監控自動化分類：
1.自動注冊
1.1zabbix agent自動添加
2.主動發現
2.1 自動發現discover
2.zabbix api
curl -s -X POST -H 'Content-Type:application/json' -d '
{
"jsonrpc": "2.0", "method": "user.login", "params": { "user": "Admin", "password": "zabbix" }, "id": 1 }' http://172.16.1.11/zabbix/discoveryconf.php|python -m json.tool
1,監控主機多，性能跟不上，延遲大
2.多機房，防火牆
zabbix輕松解決。Nagios不太好解決
監控模式，針對Agent來說
1.被動模式
2.主動模式 active
Queue里有大量延遲的item
當監控主機超過300+，建議使用主動模式
主動模式配置：
Zabbix Proxy
zabbix-server ->>zabbix proxy ->zabbix agent
yum install -y zabbix-proxy zabbix-proxy-mysql mariadb-server
Zabbix生產案例實戰
1、項目規划
主機分組：
交換機
NGINX
tomcat
mysql
監控對象識別：
1.使用SNMP監控交換機
2.使用IPMI監控服務器硬件
3.使用Agent監控服務器
4.使用JMX監控java
5.監控mysql
6.監控web狀態
7.監控NGINX狀態
SNMP監控
1.1.交換機開啟snmp
config t
snmp-server community public ro
end
1.2.在zabbix 上添加監控
3.關聯監控模板
IPMI：
建議：使用自定義item，本地執行IPMItool命令來獲取數據
JMX ：（使用Zabbix Java Gateway 代理）
1.yum install zabbix-java-gateway java-1.8.0
2.vim /etc/zabbix/zabbix_java_gateway.conf
3.啟動systemctl start zabbix-java-gateway.service
4.端口 進程
JMX 三種類型：1.無密碼認證 2.用戶密碼認證 3.ssl
5.vim /etc/zabbix/zabbix_server.conf
設置Java Gageway地址
6.重啟zabbix server
安裝 Tomcat，啟動Tomcat，端口8080
開啟jmx遠程監控
vim catalina.sh
CATALINA_OPTS="$CATALINA_OPTS -Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=8888
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
-Djava.rmi.server.hostname=172.16.1.11"
重啟Tomcat
手動檢測監控狀態
yum install -y zabbix-get
1.開啟NGINX監控
2.編寫腳本來進行數據采集
3.設置用戶自定義參數
4.重啟zabbix-agent
5.添加item
6.創建圖形
7.創建觸發器
8.創建模板
1)編寫腳本
2)上傳到/etc/zabbix/zabbix_agentd.d/
3).修改agent配置Include=/etc/zabbix/zabbix_agentd.d/*.conf
4)chmod u+x 腳本
location /nginx_status {
stu_status on ;
access_log off;
allow 127.0.0.1/24;
deny all;
}
UserParameter=linux_status[*],/etc/zabbix/zabbix_agentd.d/zabbix_linux_plugin.sh "$1" "
$2" "$3"
重啟代理
測試
zabbix_get -s 172.16.1.11 -k linux_status[nginx_status,81,active]
自定義告警腳本：
1.放在cd /usr/lib/zabbix/alertscripts/
2.要支持三個參數 1收件人 2主題 3內容
3.執行權限
4.web界面添加
5.修改Actions
使用percona監控插件監控mysql
yum install http://www.percona.com/downloads/percona-release/redhat/0.1-4/percona-release-0.1-4.noarch.rpm
https://www.percona.com/doc/percona-monitoring-plugins/LATEST/zabbix/index.html
yum install percona-zabbix-templates
1.php腳本用來數據采集
2.shell 調用這個PHP
3.zabbix配置文件
4.zabbix模板文件
創建mysql數據庫zabbix專用用戶
完整告警流程：
1.創建用戶組，添加權限，權限只能按用戶組分配
2.創建用戶，選擇用戶角色
3.報警媒介
4.Action
添加新主機后，要確認權限分配。
自定義監控項：
1.添加用戶自定義參數
cat /etc/zabbix/zabbix_agentd.d/nginx.conf
UserParameter=nginx.active,/usr/bin/curl -s http://172.16.1.11:81/nginx-status|awk 'NR==1 {print $NF}'
2.重啟zabbix-agent
3.在server端使用zabbix-get測試獲取
zabbix_get -s 172.16.1.11 -p 10050 -k "nginx.active"
1
4.在web界面創建item
5.自定義圖形：
6.自定義screen：
7.自定義map:
作業：
1.網絡監控 Smokeping部署
2.zabbix熟悉亂點
3.下次分享 Piwik 流量分析系統
zabbix概述：
zabbix-agent
zabbix-server
mysql數據庫-
web界面
應用服務監控：
nginx:
yum install -y gcc glibc gcc-c++ pcre-evel openssl-devel
wget http://nginx.org/download/nginx-1.10.1.tar.gz
configure Shell 腳本，執行他的作用。生成 MAKEFILE
./configure -prefix=/application --user=nginx --group=nginx.......
make && make install
ln /application/nginx-1.10.1/ /applicaiton/nginx
監控體系： 采集 存儲 展示 告警
Nagios+Cacti
Zabbix IPMI SNMP JVM Server - Agent
Gangla
監控：
監控對象
1.監控對象的理解：CPU 是怎么工作的。原理
2.監控對象的指標：CPU使用率，CPU負載 CPU個數 CPU上下文切換
3.確定性能基准線：怎么樣才算故障？CPU負載多少才算高
監控范圍：
1.硬件監控 服務器的硬件故障
2.操作系統監控 CPU 內存 IO 進程
3.應用服務監控
4.業務監控
硬件監控：
遠程控制卡：DELL 服務器：iDRAC
HP服務器：ILO
IBM服務器：IMM
Linux就可以使用IPMI BMC控制器
ipmitool
1.硬件要支持IPMI
2.操作系統支持 Linux IPMI
3.管理工具 ipmitool
安裝：yum install OpenIPMI ipmitool
啟動：systemctl start ipmi
使用IPMI有兩種方式1 本地調用
2. 遠程調用
ipmitool help
ipmi 配置網絡，有兩種方式：
ipmi over lan
獨立：單獨網線（單獨交換機配置ipmi）
硬件監控： 1.使用IPMI 2.機房巡檢
路由器和交換機：SNMP（簡單管理網絡協議） 監控
yum install net-snmp net-snmp-utils -y
系統監控：
---CPU
---內存
-----IO Input/Ouput（網絡、磁盤）
CPU三個重要概念：
上下文切換：CPU調度器實施的進程的切換過程，上下文切換
運行隊列（負載）：運行隊列
使用率：
時間片
確定服務類型：
IO密集型： 數據庫
CPU密集型： web mail
確定性能基准線：
運行隊列 ：1-3線程 1CPU 4核 負載不超過12個線程
CPU使用：65%-70% 用戶態利用率
30%-35% 內核態利用率
0%-5% 空閑
上下文切換：
監控工具：top：P CPU使用率排序 M內存使用率排序
top vmstat mpstat
內存：free vmstat
頁 4KB
1.尋址 2.空間
硬盤：塊 iotop dd iostat
IOPS IO’s Per Second
順序IO
隨機IO
網絡：iftop 帶寬
阿里測試，奇雲測
IBM nmon 二進制 測試用
作業：
1.注冊GITHUB，創建edu-docs項目
2.熟悉基本git命令
3.上傳今天編寫的第一個規范，到github上
4.講Cobbler的實驗在虛擬機上再次完成，並編寫文檔
預習：
1.安裝zabbix
自動化規范：
1.服務器采購
2.服務器驗收並設置raid
3.服務商提供驗收單，運維驗收負責人簽字
4.服務器上架
5.資產錄入
6.開始自動化安裝
1）將新服務器划入裝機VLAN
2）根據資產清單上的MAC地址，自定義安裝
3）
基於ITIL的IT運維管理體系：
運維自動化發展層級：智能化、服務化（API）、Web化、平台化、標准化、工具化
智能化
智能化的自動化擴容、縮容、服務降級、故障自愈
觸發機制--》決策系統（決策樹）--》
1、 zabbix觸發Action
觸發：
1）、當某個集群的訪問量超過最大支撐量，比如10000.
2）、並持續5分鍾
3）、不是攻擊
4）、資源池有可用資源
4.1） 當前網絡帶寬使用率
4.2 ）如果是共有雲，錢夠不夠
5）、當前后端服務支撐量是否超過閾值，如果超過應該后端先擴容
6）、數據庫是否可以支撐當前並發
7）、當前自動化擴展隊列，是否有正在擴容的節點
8）、其他業務相關的
之前：先判斷Buffer是否有最近X小時，已經移除的之前創建的虛擬機
並查詢軟件版本是否和當前一致，如果一致，從第5步開始
如果不一致，從第4步開始
2、OpenStack 創建虛擬機
3、Saltstack 配置環境---------監控
4、部署系統部署當前代碼
5、測試服務是否可用（注意間隔和次數）
6、加入集群
7、通知（短信、郵件）
自動化縮容：
1、觸發條件和決策
2、從集群中移除節點---關閉監控--移除
3、通知
4、移除的節點存放於Buffer里面
5、Buffer里面超過1天的虛擬機，自動關閉，存放於xx區
6、xx區的虛擬機，每7天清理刪除
服務化（API化）
DNS WEB 管理 bind-DLZ dns-api
負載均衡WEB管理 slb-api
JOB管理平台 job-api
監控WEB管理 Zabbix zabbix-api
操作系統安裝平台 cobbler-api
部署平台 deploy-api
配置管理平台 saltstack-api
自動化測試平台 test-api
1、調用 cobbler-api安裝操作系統
2、調用saltstack-api進行系統初始化
3、調用 dns-api解析主機名
4、調用zabbix-api 將新上線機器加上監控
5、再次調用 saltstack-api部署軟件（安裝NGINX+PHP）
6、調用deploy-api將當前版本的代碼部署到服務器上
7、調用 test-api測試當前服務運行十分正常
8、調用slb-api將該節點加入集群
運維操作平台-WEB化：
例子：JOB管理平台
1、做成web界面
2、權限控制
3、日志記錄
4、弱化流程
5、不用SSH到服務器，減少人為操作造成的故障 web ssh
DNS WEB 管理 bind-DLZ
負載均衡WEB管理
JOB管理平台
監控WEB管理 Zabbix
操作系統安裝平台
工具化：
1.SHELL腳本（功能性（流程）腳本、檢查性、報表性）
2.開源工具：Zabbix ELKStack SaltStack Cobbler
目標：1、促進標准化的實施
2、將重復的操作，簡單化
3、將多次操作，流程化
4、減少人為操作的低效和降低故障率
工具化和標准化是好基友！
痛點：
1、至少要SSH到服務器執行。可能犯錯
2、多個腳本有執行順序的時候，可能犯錯
3、權限管理問題，日志沒法統計
4、無法避免手工操作
運維自動化發展：
1.運維標准化
物理設備層面：
1）服務器標簽化、設備負責人、設備采購詳情、設備擺放標准。
2）網絡划分、遠程控制卡、網卡端口
3）服務器機型、硬盤、內存統一。根據業務分類。
4）資產命名規范、編號規范、類型規范
5）監控標准
操作系統層面：
1）操作系統版本
2）系統初始化（DNS、NTP、內核參數調優、rsyslog、主機名規范）
3）基礎Agent配備（Zabbix Agent、Logstash Agent、Saltstack minion）
4)系統監控標准（CPU、內存、硬盤、網絡、進程）
應用服務層面：
1）Web服務器選型（Apache、Nginx）
2)進程啟動用戶、端口監聽規范、日志收集規范（訪問日志、錯誤日志、運行日志）
3）配置管理（配置文件規范、腳本規范）
4）架構規范（Nginx+Keepalived、LVS+Keepalived等）
5）部署規范（位置、包命名等）
運維操作層面：
1）機房巡檢流程（周期、內容、報修流程）
2）業務部署流程（先測試、后生產。回滾）
3）故障處理流程（緊急處理、故障升級、重大故障管理）
4）工作日志標准（如何編寫工作日志）
5）業務上線流程（1.項目發起 2.系統安裝 3.部署Nginx 4.解析域名 5.測試 6.加監控 7.備份）
6）業務下線流程（誰發起，數據如何處理。）
7）運維安全規范（密碼復雜度、更改周期、VPN使用規范、服務登陸規范）
目標：文檔化
運維知識體系：
https://www.unixhot.com/page/ops
運維學習和發展的一個線路：
1.搭建服務（部署並運行起來）
2.用好服務（監控、管理、優化）
3.自動化（服務直接的關聯和協同工作）
4.產品設計（如何設計一個監控系統）
雲計算的核心競爭力是運維!
系統架構師（偏管理）：網絡 系統 數據庫 開發 雲計算 自動化 運維管理 服務管理 項目管理 測試 業務
專注某一領域