DTCC2014热点探讨之----如何为您的业务选择恰当的文件系统（获奖名单已公布-14-3-26）

action08

回复 25# Purple_Grape


    btrfs是oracle数据库专用的，fedora早就有了，

网上说的性能一般，也不知道是什么问题，，，ps我没测试

GB_juno

话题一：您目前主要的业务范围包括哪些，文件系统是否已经成为您业务的瓶颈？
目前在搞云平台的运维工作，涉及到了基于分布式文件系统的存储系统。在目前的平台上文件系统确实有点瓶颈，不能完全业务上的所有需求。

话题二：目前的文件系统中，您使用的是哪种？有哪些经验和教训？
目前的存储系统里面用的有moosefs、gluster，主要是moosefs为主。之前moosefs是单点的时候不敢怎么用，后来有个冗余的功能才开始用起来了。
当然，重要的业务虚拟机不敢放在这些存储上，主要是放放一些普通的虚拟机以及视频数据。

话题三：畅谈您对未来文件系统的发展的大趋势
ceph项目包含了3种不同类型存储要求的文件系统设计，比较新但不稳定，但是比较看好。
文件系统发展了那么多年，终于有出现了这些开源的分布式文件系统能够把廉价服务器上的廉价硬盘改造成拥有高级存储
才有的一些冗余、灾备、高IO的存储系统，也算是平民化的趋势和发展了。

Purple_Grape

回复 29# zyd_cu


    posix的支持很有必要，有了fuse，底层就变得跟具体应用无关了，再说运维和开发通常是独立的。两个团队同时管理反而不便，又不是银行金库的钥匙。

   只有fuse成为性能瓶颈时才会考虑，但我还没听说。反之，fuse虽然有些性能损耗，但我觉得仍然是值得的。

Purple_Grape

回复 31# action08


    btrfs是oracle数据库专用的？这个有点严重吧。

ylky_2000

业务环境：以Windwos  Server系统平台为基础，以SQL Server2008和2000为核心的数据库应用系统。涉及到OA协同、采购、金蝶财务模块及其他零售、酒店、连锁等业务应用系统等等。。。
一、为什么要高可用？
我们担心的又以下几点，其中部分遇到过本来是可以避免的业务中断：（第4和第5我们遇到的情况居多）
（1）        进程错误，比如用户应用与文件数据库的连接异常中断或用户进程发生错误。
（2）        文件系统故障，由于异常操作或其它原因造成文件系统内部部分信息丢失或不一致。
（3）        操作系统故障，操作系统本身的系统调用问题及底层的应用驱动在安装或更新出现冲突；
（4）        网络线缆故障。
（5）        介质问题，网络连接或物理硬盘也可能会出现问题。
二、考虑的应对方案：
1、带共享存储双机方案
带共享存储双机方案


2、软件方式的双机


三、方案选择
最后两个方案都有采用，数据量大的、自己开发的系统采用的是共享存储双机方案。前端还应用了tomcat集群，对前端的访问做负载。
其他的有一部分较为重要的外购系统采用软件方式的双机方案。

四、这里重点介绍下软件方式的（因为rose也是第三方软件方式）
1、我们当时采用的是PlusWell 软件实现。top图参考以上方式。
这里我们采用的是active/standy方式，没有采用active和active的方式，防止有一台挂机的情况下，一台顶不住。
Server1是主“激活”节点，Server2是次“备用”节点。如果Server1发生故障了，它的被保护资源由Server2 节点来恢复。当节点Server1恢复后， 资源可以被Server1重新获得。这样的方式不会降低用户的体验，但是存在资源的浪费。
2、PlusWell技术原理
（1）心跳检测
通过IP做心跳检测时，主备机会通过此心跳路径，周期性的发出相互检测的测试包，如果此时主机出现故障，备机在连续丢失设定数目的检测包后，会认为主机出现故障，这时备会自动检测设置中是否有第二种心跳，如果没有第二种心跳的话，备机则根据已设定的规则，启动备机的相关服务，完成双机热备的切换。
这里有设置第二种心跳检测，是为了防止脑裂的情况。
（2）IP工作过程
使用虚拟IP地址的方法来实现，
    正常情况下，虚拟IP地址(即访问IP:192.168.1.33）指向主机的实IP（192.168.1.11）地址，用户通过虚拟IP地址访问主机，这时，HA软件将虚拟IP地址解析到主机实IP地址。
    服务器切换过程的情况下，虚拟IP（即访问IP192.168.1.33)地址通过PlusWell热备份软件自动将虚拟IP地址解析到备机的实IP(192.168.1.22)地址上，这时，虚拟IP地址指向备机的实IP地址。但对用户来说，用户访问的仍然是虚拟IP地址。所以用户只会在切换的过程中发现有短暂的通信中断，经过一个短暂的时间，就可以恢复通信。
(3)应用及网络故障切换过程
   检测到操作系统的故障并及时将服务切到备用服务器。
    操作系统正常的情况下，数据库系统出现意外故障，这时双机容错软件可以及时发现并将其切到备用服务器，使服务不致于停止。
   操作系统和数据库系统全都正常的情况下，服务器网络出现故障，这时双机热备软件，可以将系统切到正常的备用服务器上。

目前运行还比较稳定，没有出现因为服务器故障而导致应用长时间中断的情况。

五、总结反思
为什么不采用windowsserver自带的高可用解决方案？
1、不想被它绑定，微软的解释太复杂，尤其是版权和访问数方面，每问一个代理商的解释不一样，又不给你权威的解答，存在法律风险；
2、有一定的局限性，比方说高可用的服务器数量方面，只允许两台，而随着企业的发展，单两台服务器的高可用不一定满足要求，需要扩展的时候就麻烦了；
3、最终用户再怎么专业，也比不上专业人士见多识广，从第三方获得支持，可以确保项目的顺利完成，提高项目成功的几率。
还有什么可以优化的？
1、如何带共享存储的方案可以跟软件方式的结合就可以取长补短了。
2、共享的存储没有高可用，还是把希望寄托在存储的所谓的稳定性上，希望有可以大规模使用的，存储双机方案。

zyd_cu

回复 35# ylky_2000


现在比较典型的一种模式上，上层多个应用服务器 共享 底层的分布式存储系统（数据的可靠性、管理等都交给这个存储系统来做）；

不过目前windows上的可选分布式存储方案不多，可以考虑直接使用微软的azure系列产品

ylky_2000

新的云计算有关的吧？不知道一套搞下来版权怎么样？

zyd_cu 发表于 2014-02-18 10:56
回复 35# ylky_2000

zyd_cu

回复 37# ylky_2000


按使用的量收费，与版权无关，http://windowsazure.cn/zh-cn/?l=zh-cn 貌似目前对中国用户的价格还没确定下来

zhangxuan3210

话题一：您目前主要的业务范围包括哪些，文件系统是否已经成为您业务的瓶颈？
目前的业务范围是web应用系统和运维云平台，其中一些web应用中的报表或者图片信息需要用到分布式文件系统，经过优化后的文件系统目前还没有成为该业务瓶颈。
话题二：目前的文件系统中，您使用的是哪种？有哪些经验和教训？
目前主要使用公司内部的moosefs，主要对开源moosefs进行优化，满足公司业务需求(数据共享,数据持久化，数据冗余等)。
经验和教训:moosefs和gfs类似，属于一个分布式文件系统，在分布式文件系统中，主要解决如下问题:
1.元数据管理，需要解决元数据管理服务器的的单点问题，保证元数据管理服务器的高可用
2.大量读写数据的读写性能:在面对大量数据时需要考虑数据的读写分离策略
3.数据存储策略:面对客户端读写存储服务器的就近策略
4.用户权限和配额管理:需要面对大量用户的权限管理和每一个应用的配额分配
5.存储服务器维护管理:需要解决大量存储服务器的自动化运维和管理
话题三：畅谈您对未来文件系统的发展的大趋势
目前存在大量的分布式文件系统，GFS,HDFS,TFS,ZFS，NFS,FastDFS，MooseFS,ClusterFS,GPFS等，但这些首先必须解决一个文件系统需要解决的基本问题，数据的读写性能，数据的一致性，完整性，不可丢失性等，除了这些还需要解决互联网时代的海量数据的存储等，所以最后随着这些文件系统的不断开源，不断发展，最终会形成一个标准的文件系统，来提供不同业务使用。