在实际生产环境中,面对存储/数据的同步双活需求,有基于主机的LVM Mirror技术以及基于存储厂商的同步和双活技术这样两个方向。
我想了解一下大家从哪几个维度对比这两种实现方案,如何做取舍?谢谢!
lvm占用主机资源,相当于一份数据两份副本,是相当于本地数据保护,如果存储没有双活lic可以使用;存储双活相当于容灾的概念,需要lic,而且可以实现异地或者同城灾备,需要站点仲裁,链路带宽等条件,企业可以根据自身情况选择,lvm简单便捷,双活相对复杂些
收起LVM在每个物理卷头部都维护了一个metadata,每个metadata中都包含了整个VG(volume group:卷组)的信息,包括每个VG的布局配置,PV(physical volume:物理卷)的编号,LV(logical volume:逻辑卷)的编号,以及每个PE(physical extends:物理扩展单元)到LE(logical extends:物理扩展单元)的映射关系。同一个VG中的每个PV头部的信息都是相同的,这样有利于故障时进行数据恢复。
LVM对上层文件系统提供LV层,隐藏了操作细节。对文件系统而言,对LV的操作与原先对partition的操作没有差别。当对LV进行写入操作的时候,LVM定位相应的LE,通过PV头部的映射表将数据写入到相应的PE上。LVM实现的关LVM最大的特点就是可以对磁盘进行动态管理。因为逻辑卷的大小是可以动态调整的,而且不会丢失现有的数据。我们如果新增加了硬盘,其也不会改变现有上层的逻辑卷。键在于PE和LE之间建立映射关系,不同的映射规则决定了不同的LVM存储模型。LVM支持多个PV 的stripe和mirror。
LVM最大的特点就是可以对磁盘进行动态管理,因为逻辑卷的大小是可以动态调整的,而且不会丢失现有的数据,如果我们增加了硬盘也不会改变现有的上层逻辑卷。
LVM 是主机层面技术,做数据迁移可以使用这种技术, 做容灾和双活不太可靠, 缺点很多。列举如下:
3.创建LVM Mirror简单,但是在处理存储故障,数据恢复等方面需要技术人员较高的技能;
4.同时写I/O与存储双写的效率相比 ,劣势更明显;
5.还有就是同机房做LVM可以,跨中心或跨楼宇这种远距离,LVM技术厂商肯定没有官方文件支持;
6.灾备的案例很少,几乎没有人使用这种技术做双活或容灾,案例少就是最好的证明,没人敢用这个技术实现双活或灾备。
总之,强烈不建议用这种技术实现双活和灾备。如果能通过这种技术实现双活,IBM在很多年前就可以推出双活架构方案了,厂商没有推荐此类方案还是有它的顾虑和弊端的。
收起几方面回答:1是适应性,lvm只适合linux和unix,其他操作系统,虚拟化不适合 2是管理复杂,需要在主机层众多pair识别配置镜像关系。3是lvm不支持一致性组,多个卷镜像不保证数据一致,4是lvm一般是单主机,不适用集群管理环境如rac asm。5是主机层运行占用一定主机资源 6是没有扩展多DC的复制能力
收起工作中只见过aix的lvm mirror,用起来还是比较成熟稳定,暂时还没见过其他操作系统的。
如果存储没有相关的许可,直接使用lvm mirror是一种挺好的方案,经济实惠成熟稳定,配置前需要针对hba卡和链路做一些调优工作。
如果存储带许可支持,走存储双活好点,工作量大都在存储层面,系统层面可以更简洁一些。毕竟钱都花了。
两个技术虽然都能解决单台存储故障的问题,但是在其他一些场景下,能规避的数据丢失风险是不一样的。
1、在主机上做了磁盘的误操作,如果是lvm,只是误删了lvm中一个存储的hdisk的话,是不会影响vg继续使用以及丢失数据的,但是如果是做的存储双活,则还是会直接导致vg出问题乃至丢失数据。
2、存储的lvm会导致操作系统需要完成两次IO写入确认,但是存储底层镜像,操作系统是完成一次IO,剩下的IO是由存储底层去完成的,对于操作系统来说,影响io写入性能的源头不一样。