用moosefs存储日志文件

日志分布式存储解决方案

        --moosefs分布式存储系统

目的：解决大日志量，存储资源浪费的问题，同时提高日志文件的上传、下载速度。

1、目前日志文件的存储状况

   目前对于info、www、b2b等前端日志的存储主要保存在一台硬件服务器上（50.13），约500G的容量。前端通过mount方式挂在logserver的共享目录，执行copy脚本定时向logserver上copy日志文件。

   日志必须制定删除策略(一般保留半年)，否则磁盘空间不足，当前各系统的磁盘使用量如下：

   ##磁盘使用量

   Filesystem            Size  Used Avail Use% 

   /dev/sda3             537G  433G   77G  85% 

   ##各系统使用量

31G     b2b

699M    bbs

112K    blog

4.0G    buyb2b

277M    chat

104G    detailb2b

117G    info

5.0G    listb2b

32G     log1

7.9G    myb2b

306M    sns

1.3G    tmp

34M     tuan

2.8G    un

773M    vms

9.4M    weibo

3.5G    www

   

   缺点：

        1、logserver磁盘容量扩展性差，不能在线扩展；并且当前的146*5：raid5已经接近上限。

        2、单台logserver，本身存在单节点问题

        3、日志不可长期存留，必须制定删除策略定期的清理文件。

   

2、摘要

   整体日志存储解决方案分3个部分：日志存储、日志管理、日志分析。日志分析尚没有形成机制，作为后期方案。本次方案针对前两项进行讨论，日志分析暂时空留。

   日志存储：

   单独的日志存储只需要解决高扩展性，必要的情况下可以增加高可靠的需求。在单台server上很难做到在线扩展磁盘容量，多数情况下都是线下扩展，但受server硬件的限制，也只能有限的进行扩展，不能达到高扩展性的要求。高可靠性是指log文件的安全备份，可以在日志丢失、误删、设备损坏的情况下找回丢失的日志文件。单节点server解决方案只能通过copy或磁盘raid来保证数据的安全性，不能自动备份维护起来较麻烦！因此在日志存储上计划采用moosefs分布式文件系统来解决以上问题。

   日志管理：

   日志管理一般涉及到日志文件的上传和下载。web日志的上传可以通过mount共享目录的方式copy上传，也可以通过syslog协议发送都syslog_ng服务器，由syslog_ng服务器完成日志存储。在日志的使用上，通常有以下场景：

    1、应用程序调用日志文件，比如搜索程序调用log1日志文件。

    2、日志分析工具自动下载log文件。以董彦鹏的webtrents为主。

    3、开发工程师查阅日志。mmt、互动部开发工程师经常需要查看日志，定位问题。

    满足以上场景，通过搭建功能强大的ftp服务器实现下载功能，不支持ftp上传日志。同时在账号管理上已经实现了ldap+lam的管理方式，更加便捷和和可视化。

    moosefs分布式文件系统提供了强大的监控工具，通过monitor页面可以监控整个moosefs的使用情况。为数据扩容、磁盘损坏、数据备份提供了很好的数据。 

3、结构图

   

4、日志存储系统

   4.1 moosefs分布式存储特点

       1、mfs客户端支持mount挂在，不需要二次开发即可使用。

       2、mfs具有高扩展性，支持在线扩展。既可以通过扩展磁盘数量，也可以扩展存储节点。

       3、mfs可以根据不同的目录和重要级别，灵活设置副本数量

       4、mfs支持“回收站”和快照功能

       5、支持详细的可视化监控页面，可以监控数据量、磁盘使用状况、并发和传输速率。

       缺点：

       1、master不能完全解决单点故障问题，但可以采用HA方案是故障时间降至s级，手动恢复也只需要数分钟。

       2、目录结构和元数据保存在master的内存中，对内存的需求较高；同时负责客户端的请求，因此master有可能成为系统瓶颈。

   4.2 与其他分布式对比

        4.2.1 google fs （GFS）

              专用分布式文件系统，需要二次开发支持gfs client。

              gfs目前不开源，获得不到源代码。

              master仍有单点问题

        4.2.2 fastdfs

              专用分布式文件系统，需要二次开发支持gfs

              支持文件上传、下载、追加，不支持文件的更新。

              对文件上传进行了重命名，需要而外提供数据库保存文件名的map关系

              fastdfs比较适合前端图片、视频服务器 

           

   4.3 moosefs与syslog_ng的组合方案

       当前公司采用syslog_ng收集日志，syslog_ng本身系统存储空间不住，限制日志量得增长。mfs可以为syslog_ng提供超大的存储空间（可达PB级），和在线可扩展功能。

       简要模型：

       1、syslog_ng 可以用HA提高系统的可用性。

       2、mfs master，最关键的是它的metadata数据，所以master必须做HA集群。

       2、syslog_ng&mfs master 通过双节点做HA，降低单点故障的影响。

       3、syslog_ng通过本地mfsmount 目录进行日志文件存储。

   4.4 方案优劣性总结

       通过比较mfs的特点，单点故障是影响mfs使用的主要原因。因此不建议使用在实时性要求很高的应用当中。其次，mfs master的性能可能是系统中的瓶颈，所以在高访问量的系统中亦不宜使用mfs（理论推测阀值不清楚）。 mfs的优势主要体现在轻量、易部署、海量存储方面，对于管理和存储海量日志文件较为适合。前端日志文件通常都会保留数天，实时性要求不高。前端日志存储访问量较低，达不到高并发的水平，对于单台master足够满足前端的访问。

          

5、日志管理

   5.1 日志上传

       日志文件上传可以提供两种方式，方式一：前端web服务器作为客户端直接挂在mfs目录。方式二：前端服务器通过syslog协议发送到syslog_ng服务器，由syslog_ng对日志文件进行存储。

       综合对比两种方式，方式二更加优化，集中管理日志减少了大量的操作步骤。但就目前而言，syslog_ng收集的日志尚不能被分析软件处理。因此初期阶段主要仍以方式一为主。

   5.2 目录组织结构

       存储日志文件的组织结构，建议以“系统集群/host_ip/service.log”的形式储存。主要便于后期ftp提供下载。

   5.3 日志的下载

       日志下载同样可以提供两个方式下载，其一:mfsmount mfs目录以copy的形式获取日志文件。其二，通过ftp下载所需要的日志文件。

       通过ftp下载满足应用程序、开发人员、日志分析三种不同场景的需求。

   5.3 日志ftp与ldap账号管理整合

       当前开发工程师查看程序日志主要是通过本地ftp服务获取。ftp服务部署在各个不同的系统上，尚没有集中化管理。后期如果syslog_ng能够收集各个系统应用程序日志，ftp的集中化也将变成可能。为每个应用开通一个日志下载账号，众多ftp账号管理起来比较困难，通过ldap+lam管理ftp账号，目前已经在使用了。将大大提高维护ftp账号的效率。

6、日志分析系统

   针对日志的分析系统，暂时缺少成型方案!