linux架构的需求分析,运维及系统架构的两大主题

运维及系统架构的两大主题

1数据保护

项目经验

全网数据备份解决方案

数据库数据 图片资源等 程序 运维配置文件 其他相关的

数据库数据 主从(物理故障) 实时同步 半同步插件 事务提交

百度案例

M1-S1(不提供服务 专做备份 实时同步brbd 半同步插件 事务提交)

S2

图片资源等

1每晚全量备份 1T

增量

01.rsync 小文件比对时间很长

02.brbd浪费资源 备节点不可用

03.按时间增量 201404 201405

04.更新资源写LOG  就增量了  一边写LOG  另一边通过RSYNC同步具体的文件 不需要比对了

05.inotify，sersync等

程序双写 提交数据写到两个存储 PHP能写 (还需要备份吗 还需要增量吗 )

如何保证数据库不丢数据

如何保证存储不丢数据

全量

01.brdb

02.程序双写 提交数据写到两个存储

03.分布式存储 NOSQL mysql mongodb同步机制做存储(本身是全量和增量)

分布式存储简单方案(软件方案和自己的程序方案)

通过数据库做一个相当于路由一样 路径在哪台机器上都存在服务器上

每个图片服务器有自己的资源 当用户访问时 先查数据库 知道哪台机子哪个路径

04.分布式架构方案

按天备份

办公室----IDC测试----正式

程序 ，运维配置文件都要放到SVN里 ，向外发布

办公室SVN---->IDC测试

---->IDC正式

备份思想：

需求分析：对于每个项目或者业务点：事先定好 备份规划

数据库：10分钟，可以丢一天，根据需求出方案

存储备份：可以丢一天，根据需求出方案

测试数据：谁定，运维总监，开发总监，团队讨论。30分钟内恢复

机房迁移，OPENSLL升级，数据库升级

=====================================================================================

2维护7*24小时不间断服务

集群lvs nginx haproxy f5 netscaler

高可用 keepalive heartbeat nginx haporxy

性能\扩展：优化，用户体验要好，业务可以扩展

监控：运维级别，业务级别(按产品线监控，流量，负载，访问请求，错误日志50X 40X

接口存活 以及流量)