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.tool1,监控主机多，性能跟不上，延迟大
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.产品设计（如何设计一个监控系统）
云计算的核心竞争力是运维!
系统架构师（偏管理）：网络 系统 数据库 开发 云计算 自动化 运维管理 服务管理 项目管理 测试 业务
专注某一领域
480
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
