崩溃，异地灾备遇到巨大难题，请大家帮助

pangzi

选用国际大牌存储做异地灾备，方案是LUN级别的镜像，镜像的LUN上存放着数据库的LDF和MDF。
实际使用这种方案存在巨大的问题，同步的数据量太大。

数据量变化量在操作系统上看是100M。实际同步的数据量是10倍以上，网络带宽全部堵死。

我分析原因如下：
操作系统层面的数据量变化程度与存储设备block的变化量没有直接关系。
1、例如操作系统的D盘50G是存储上的一个LUN，使用了10MB，如果D盘做磁盘碎片整理，虽然使用空间10MB没有发生变化，
但意味着几乎所有block都发生了变化（移动），对于灾备来说，这个LUN几乎要全部同步到异地存储上，数据量是50GB。

2、比如D盘是一个在存储上的LUN（50G)，我在D盘创建一个50GB的文件，然后删除，这是D盘可用空间仍然是50G,
操作系统层面数据没有发生变动，但是存储认为这50G大小的block都发生了变化，都需要同步到异地的存储上。

请问以上2点是否正确，另外为了解决这些问题，我不知道如何入手了。

存储厂商说复制数据量大大超过预期，和存储设备本身没有关系，原因是存储设备对操作系统就是一块硬盘，LUN镜像数据量大肯定与数据库和操作系统有关。
数据库厂家说不能开这个CASE，数据库对磁盘的读写算法等数据库保密。

pangzi

我现在还想知道一个LUN与RAID组中的磁盘是什么对应关系？不要回答逻辑映射关系。
要具体的。
比如3块100G 硬盘盘做RAID5 ，可用容量200G，创建A\B 两个LUN,
我怎么能知道lunA的读写使用的是RAID组中那块硬盘的那个条带？是一种什么映射算法？

冬瓜头

第二个说法有问题。删除文件也只是删除metadata，间接块等，更新的block很少，同步过去的也很少。第一种说法是对的。

lun在raid组上的分布方式，我总结了几种，这里就不重复打字了，详见《大话存储》第二版。不同厂商实现不同，但是无外乎我总结的那一些。传统方式一般使用横向定死分布方式。

冬瓜头

数据库该变量与底层该变量发生相差很大的情况时，考虑一下block边界不对齐问题，用io监控工具检测fs、卷各层的io状况，发现原因不难。

pangzi

第二版已经出版了？

冬瓜头

大概年底出版吧。

ry715

要加油啊，实在等的很辛苦

冬瓜头

呵呵，要不谁开一家私人出版社，咱自己印自己卖

michael1983

存储底层block的变化与文件系统的变化没有什么很线性的关系的。
文件增多，则block增多
文件减少，block未必减少

不过大多数情况下，操作系统上的普通文件，对应到底层block，增加一个文件，block增加基本也是一个文件的大小（当然，这跟block大小有关系）
但有些情况就很特殊，比如说有些程序产生的是加密文件，例如notes数据库，产生的邮箱.nsf文件，你只发送了一封邮件，但整个nsf文件会整个发生重组，对应到lun上就是所有的block都会发生改变。
所以就会产生楼主上面的问题了。

mike79

感觉没问在点子上。
你用的是哪家的存储产品？双中心距离有多远？中间用的是什么线路？带宽是多少？
另外你的操作系统是什么？跑什么应用？
ps 你说的数据变化量在操作系统看来是100M。你是用什么方法来看的？