1)运维是指大型组织已经建立好的网络软硬件的维护,就是要保证业务的上线与运作的正常,在他运转的过程中,对他进行维护,他集合了网络、系统、数据库、开发、安全、监控于一身的技术,运维又包括很多种,有DBA运维、网站运维、虚拟化运维、监控运维、游戏运维等等
2)游戏运维又有分工,分为开发运维、应用运维(业务运维)和系统运维
开发运维:是给应用运维开发运维工具和运维平台的
应用运维:是给业务上线、维护和做故障排除的,用开发运维开发出来的工具给业务上线、维护、做故障排查
系统运维:是给应用运维提供业务上的基础设施,比如:系统、网络、监控、硬件等等
总结:开发运维和系统运维给应用运维提供了“工具”和“基础设施”上的支撑
开发运维、应用运维和系统运维他们的工作是环环相扣的
RAID 0,可以是一块盘和N个盘组合
其优点读写快,是RAID中最好的
缺点:没有冗余,一块坏了数据就全没有了
RAID 1,只能2块盘,盘的大小可以不一样,以小的为准
10G+10G只有10G,另一个做备份。它有100%的冗余,缺点:浪费资源,成本高
RAID 5 ,3块盘,容量计算10*(n-1),损失一块盘
特点,读写性能一般,读还好一点,写不好
冗余从好到坏:RAID1 RAID10 RAID 5 RAID0
性能从好到坏:RAID0 RAID10 RAID5 RAID1
成本从低到高:RAID0 RAID5 RAID1 RAID10
单台服务器:很重要盘不多,系统盘,RAID1
数据库服务器:主库:RAID10 从库 RAID5RAID0(为了维护成本,RAID10)
WEB服务器,如果没有太多的数据的话,RAID5,RAID0(单盘)
有多台,监控、应用服务器,RAID0 RAID5
我们会根据数据的存储和访问的需求,去匹配对应的RAID级别
区别:LVS由于是基于四层的转发所以只能做端口的转发,而基于URL的、基于目录的这种转发LVS就做不了
工作选择:
HAproxy和Nginx由于可以做七层的转发,所以URL和目录的转发都可以做,在很大并发量的时候我们就要选择LVS,像中小型公司的话并发量没那么大,选择HAproxy或者Nginx足已,由于HAproxy由是专业的代理服务器,配置简单,所以中小型企业推荐使用HAproxy
在内存的利用上,Varnish比Squid具有优势,性能要比Squid高。
还有强大的通过Varnish管理端口,可以使用正则表达式快速、批量地清除部分缓存
它是内存缓存,速度一流,但是内存缓存也限制了其容量,缓存页面和图片一般是挺好的
4)squid的优势在于完整的庞大的cache技术资料,和很多的应用生产环境
工作中选择:
要做cache服务的话,我们肯定是要选择专业的cache服务,优先选择squid或者varnish。
工作中选择:现在大公司都是用resin,追求性能;而中小型公司都是用Tomcat,追求稳定和程序的兼容
但通过中间件相互之间仍能交换信息。执行中间件的一个关键途径是信息传递,通过中间件,应用程序可以工作于多平台或OS环境。
jdk:jdk是Java的开发工具包,它是一种用于构建在 Java 平台上发布的应用程序、applet 和组件的开发环境
AB test就是一种灰度发布方式,让一部用户继续用A,一部分用户开始用B,如果用户对B没有什么反对意见,那么逐步扩大范围,把所有用户都迁移到B上面来灰度发布可以保证整体系统的稳定,在初始灰度的时候就可以发现、调整问题,以保证其影响度
一、NAT模式(VS-NAT)
原理:就是把客户端发来的数据包的IP头的目的地址,在负载均衡器上换成其中一台RS的IP地址
并发至此RS来处理,RS处理完后把数据交给负载均衡器,负载均衡器再把数据包原IP地址改为自己的IP
将目的地址改为客户端IP地址即可期间,无论是进来的流量,还是出去的流量,都必须经过负载均衡器
优点:集群中的物理服务器可以使用任何支持TCP/IP操作系统,只有负载均衡器需要一个合法的IP地址
缺点:扩展性有限。当服务器节点(普通PC服务器)增长过多时,负载均衡器将成为整个系统的瓶颈
因为所有的请求包和应答包的流向都经过负载均衡器。当服务器节点过多时
大量的数据包都交汇在负载均衡器那,速度就会变慢!
二、IP隧道模式(VS-TUN)
原理:首先要知道,互联网上的大多Internet服务的请求包很短小,而应答包通常很大
那么隧道模式就是,把客户端发来的数据包,封装一个新的IP头标记(仅目的IP)发给RS
RS收到后,先把数据包的头解开,还原数据包,处理后,直接返回给客户端,不需要再经过
负载均衡器。注意,由于RS需要对负载均衡器发过来的数据包进行还原,所以说必须支持
IPTUNNEL协议,所以,在RS的内核中,必须编译支持IPTUNNEL这个选项
优点:负载均衡器只负责将请求包分发给后端节点服务器,而RS将应答包直接发给用户
所以,减少了负载均衡器的大量数据流动,负载均衡器不再是系统的瓶颈,就能处理很巨大的请求量
这种方式,一台负载均衡器能够为很多RS进行分发。而且跑在公网上就能进行不同地域的分发。
缺点:隧道模式的RS节点需要合法IP,这种方式需要所有的服务器支持”IP Tunneling”
(IP Encapsulation)协议,服务器可能只局限在部分Linux系统上
三、直接路由模式(VS-DR)
原理:负载均衡器和RS都使用同一个IP对外服务但只有DR对ARP请求进行响应
所有RS对本身这个IP的ARP请求保持静默也就是说,网关会把对这个服务IP的请求全部定向给DR
而DR收到数据包后根据调度算法,找出对应的RS,把目的MAC地址改为RS的MAC(因为IP一致)
并将请求分发给这台RS这时RS收到这个数据包,处理完成之后,由于IP一致,可以直接将数据返给客户
则等于直接从客户端收到这个数据包无异,处理后直接返回给客户端
由于负载均衡器要对二层包头进行改换,所以负载均衡器和RS之间必须在一个广播域
也可以简单的理解为在同一台交换机上
优点:和TUN(隧道模式)一样,负载均衡器也只是分发请求,应答包通过单独的路由方法返回给客户端
与VS-TUN相比,VS-DR这种实现方式不需要隧道结构,因此可以使用大多数操作系统做为物理服务器。
缺点:(不能说缺点,只能说是不足)要求负载均衡器的网卡必须与物理网卡在一个物理段上。
mysql如何减少主从复制延迟:
如果延迟比较大,就先确认以下几个因素:
从库硬件比主库差,导致复制延迟
主从复制单线程,如果主库写并发太大,来不及传送到从库就会导致延迟。
更高版本的mysql可以支持多线程复制
慢SQL语句过多
网络延迟
master负载,主库读写压力大,导致复制延迟,架构的前端要加buffer及缓存层
slave负载,一般的做法是,使用多台slave来分摊读请求,再从这些slave中取一台专用的服务器,只作为备份用,不进行其他任何操作.另外, 2个可以减少延迟的参数:–slave-net-timeout=seconds 单位为秒 默认设置为 3600秒
参数含义:当slave从主数据库读取log数据失败后,等待多久重新建立连接并获取数据
–master-connect-retry=seconds 单位为秒 默认设置为 60秒
参数含义:当重新建立主从连接时,如果连接建立失败,间隔多久后重试
通常配置以上2个参数可以减少网络问题导致的主从数据同步延迟
MySQL数据库主从同步延迟解决方案
最简单的减少slave同步延时的方案就是在架构上做优化,尽量让主库的DDL快速执行,还有就是主库是写,对数据安全性较高,比如sync_binlog=1,innodb_flush_log_at_trx_commit= 1 之类的设置,而slave则不需要这么高的数据安全,完全可以讲sync_binlog设置为0或者关闭binlog,innodb_flushlog也可以设置为0来提高sql的执行效率。另外就是使用比主库更好的硬件设备作为slave
一、 在已知MYSQL数据库的ROOT用户密码的情况下,修改密码的方法:
1、 在SHELL环境下,使用mysqladmin命令设置:
mysqladmin –u root –p password “新密码” 回车后要求输入旧密码
2、 在mysql>环境中,使用update命令,直接更新mysql库user表的数据:
Update mysql.user set password=password(‘新密码’) where user=’root’;
flush privileges;
注意:mysql语句要以分号”;”结束
3、 在mysql>环境中,使用grant命令,修改root用户的授权权限。
grant all on . to root@’localhost’ identified by ‘新密码’;
二、 如查忘记了mysql数据库的ROOT用户的密码,又如何做呢?方法如下:
1、 关闭当前运行的mysqld服务程序:service mysqld stop(要先将mysqld添加为系统服务)
2、 使用mysqld_safe脚本以安全模式(不加载授权表)启动mysqld 服务
/usr/local/mysql/bin/mysqld_safe –skip-grant-table &
3、 使用空密码的root用户登录数据库,重新设置ROOT用户的密码
#mysql -u root
Mysql> Update mysql.user set password=password(‘新密码’) where user=’root’;
Mysql> flush privileges;
2、Nginx对网络稳定性的依赖非常小,理论上能ping通就就能进行负载功能,这个也是它的优势之一,相反LVS对网络稳定性依赖比较大,这点本人深有体会;
3、Nginx安装和配置比较简单,测试起来比较方便,它基本能把错误用日志打印出来,LVS的配置、测试就要花比较长的时间了,LVS对网络依赖比较大。
4、可以承担高负载压力且稳定,在硬件不差的情况下一般能支撑几万次的并发量,负载度比LVS相对小些。
5、Nginx可以通过端口检测到服务器内部的故障,比如根据服务器处理网页返回的状态码、超时等等,并且会把返回错误的请求重新提交到另一个节点,不过其中缺点就是不支持url来检测。比如用户正在上传一个文件,而处理该上传的节点刚好在上传过程中出现故障,Nginx会把上传切到另一台服务器重新处理,而LVS就直接断掉了,如果是上传一个很大的文件或者很重要的文件的话,用户可能会因此而不满。
6、Nginx不仅仅是一款优秀的负载均衡器/反向代理软件,它同时也是功能强大的Web应用服务器,LNMP也是近几年非常流行的web架构,在高流量的环境中稳定性也很好。
7、Nginx现在作为Web反向加速缓存越来越成熟了,速度比传统的Squid服务器更快,可考虑用其作为反向代理加速器
8、Nginx可作为中层反向代理使用,这一层面Nginx基本上无对手,唯一可以对比Nginx的就只有lighttpd了,不过lighttpd目前还没有做到Nginx完全的功能,配置也不那么清晰易读,社区资料也远远没Nginx活跃
9、Nginx也可作为静态网页和图片服务器,这方面的性能也无对手。还有Nginx社区非常活跃,第三方模块也很多
Nginx的缺点是:
1、Nginx仅能支持http、https和Email协议,这样就在适用范围上面小些,这个是它的缺点
2、对后端服务器的健康检查,只支持通过端口来检测,不支持通过url来检测
不支持Session的直接保持,但能通过ip_hash来解决
LVS:使用Linux内核集群实现一个高性能、高可用的负载均衡服务器,它具有很好的可伸缩性(Scalability)、可靠性(Reliability)和可管理性(Manageability)
LVS的优点是:
1、抗负载能力强、是工作在网络4层之上仅作分发之用,没有流量的产生,这个特点也决定了它在负载均衡软件里的性能最强的,对内存和cpu资源消耗比较低
2、配置性比较低,这是一个缺点也是一个优点,因为没有可太多配置的东西,所以并不需要太多接触,大大减少了人为出错的几率
3、工作稳定,因为其本身抗负载能力很强,自身有完整的双机热备方案,如LVS+Keepalived,不过我们在项目实施中用得最多的还是LVS/DR+Keepalived
4、无流量,LVS只分发请求,而流量并不从它本身出去,这点保证了均衡器IO的性能不会收到大流量的影响。
5、应用范围较广,因为LVS工作在4层,所以它几乎可对所有应用做负载均衡,包括http、数据库、在线聊天室等
LVS的缺点是:
1、软件本身不支持正则表达式处理,不能做动静分离
而现在许多网站在这方面都有较强的需求,这个是Nginx/HAProxy+Keepalived的优势所在
2、如果是网站应用比较庞大的话,LVS/DR+Keepalived实施起来就比较复杂了,特别后面有Windows Server的机器的话,如果实施及配置还有维护过程就比较复杂了,相对而言,Nginx/HAProxy+Keepalived就简单多了。
HAProxy的特点是:
1、HAProxy也是支持虚拟主机的。
2、HAProxy的优点能够补充Nginx的一些缺点,比如支持Session的保持,Cookie的引导,同时支持通过获取指定的url来检测后端服务器的状态
3、HAProxy跟LVS类似,本身就只是一款负载均衡软件,单纯从效率上来讲HAProxy会比Nginx有更出色的负载均衡速度,在并发处理上也是优于Nginx的
4、HAProxy支持TCP协议的负载均衡转发,可以对MySQL读进行负载均衡,对后端的MySQL节点进行检测和负载均衡,大家可以用LVS+Keepalived对MySQL主从做负载均衡
5、HAProxy负载均衡策略非常多,HAProxy的负载均衡算法现在具体有如下8种:
①roundrobin,表示简单的轮询,这个不多说,这个是负载均衡基本都具备的;
② static-rr,表示根据权重,建议关注;
③leastconn,表示最少连接者先处理,建议关注;
④ source,表示根据请求源IP,这个跟Nginx的IP_hash机制类似
我们用其作为解决session问题的一种方法,建议关注;
⑤ri,表示根据请求的URI;
⑥rl_param,表示根据请求的URl参数’balance url_param’ requires an URL parameter name;
⑦hdr(name),表示根据HTTP请求头来锁定每一次HTTP请求;
⑧rdp-cookie(name),表示根据据cookie(name)来锁定并哈希每一次TCP请求。
tar包备份
percona提供的xtrabackup工具,支持innodb的物理热备份,支持完全备份,增量备份,而且速度非常快,支持innodb存储引起的数据在不同,数据库之间迁移,支持复制模式下的从机备份恢复备份恢复,为了让xtrabackup支持更多的功能扩展,可以设立独立表空间,打开 innodb_file_per_table功能,启用之后可以支持单独的表备份
keepalived主要有三个模块,分别是core、check和vrrp。core模块为keepalived的核心,负责主进程的启动、维护及全局配置文件的加载和解析。check负责健康检查,包括常见的各种检查方式,vrrp模块是来实现VRRP协议的
Keepalived健康检查方式配置
HTTP_GET|SSL_GET
HTTP_GET | SSL_GET
{
url {
path /# HTTP/SSL 检查的url可以是多个
digest # HTTP/SSL 检查后的摘要信息用工具genhash生成
status_code 200# HTTP/SSL 检查返回的状态码
}
connect_port 80 # 连接端口
bindto
connect_timeout 3 # 连接超时时间
nb_get_retry 3 # 重连次数
delay_before_retry 2 #连接间隔时间
}