存储数据平衡和迁移测试总结

存储数据平衡和迁移测试总结一、模块背景现有产品问题：1、虚拟机迁移过程，虚拟机需要关闭，导致业务中断。2、主机容量不足的情况下，虚拟机无法开机、无法运行，影响业务。3、全局平衡的情况下，存在大量数据迁移问题。二、解决方案引入定向热迁移，将容量不足主机的部分文件迁移到其他容量宽裕主机，迁移过程不中断业务。三、模块风险数据安全性、虚拟机性能四、需求1、实现热迁移，数据迁移时，虚拟机不需要关机2、支持将指定的文件迁移到指定的复制组3、自动识别容量不足的主机，选择需要迁移的文件，及迁移目的，并进行数据 迁移4、迁移成功，源文件占用磁盘空间可以释放5、迁移失败，目标残留文件占用磁盘空间可以释放五、模块简介定向热迁移模块由cli、热迁移机制模块、平衡信息配置文件、热迁移策略模块四部分组成。其中：cli模块：发起热迁移，关闭热迁移，显示迁移状态。热迁移机制模块，分为三块：1、数据迁移模块，实现将指定文件迁移到指定目的；2、平衡感知模块，平衡过程中，业务可以感知到底层文件处于迁移状态中；3、业务io处理模块，业务感知到文件迁移时，同步io到目的文件，保证数 据一致性。平衡信息配置文件定义需要迁移的文件和迁移目的复制组。热迁移策略模块：现迁移文件的选取，迁移目的的选择。六、测试过程数据迁移模块将策略与机制分离，策略负责指定需要迁移的文件，机制负责整个数据搬迁，由于数据搬迁的过程风险较大，所以在测试的时候首先关注的是机制，而后才是策略。机制的测试过程中主要关注的是数据的安全性，其中，锁、业务IO更是重中之重。机制的测试主要分为以下三个方面来阐述：迁移中处理、故障处理、迁移后处理。虚拟机基本功能测试虚拟机在迁移过程中，首先需要关注的是虚拟机是否真的能够实现热迁移（不关机迁移）；其次，需要关注的是迁移过程中虚拟机的运行会受到多大的影响，因为迁移过程中存在大量数据的搬迁，势必会抢占业务的IO，从而影响虚拟机的运行，影响业务的运行，测试过程中发现，文件在迁移时，业务IO下降较为明显（70%~80%），这个问题现在还没有解决的方法，后面再看看。另外还要关注在迁移过程中虚拟机能否进行最基本的操作，比如重命名虚拟机，修改分组，测试过程中发现，热迁移的过程中，虚拟机能够重命名，但是不能修改分组。最后要关注的是迁移过程中，给虚拟机备份、快照的有效性，测试方法是在迁移过程中给虚拟机备份（快照），然后再迁移完成后再恢复备份（快照），看是否能够恢复到原来的状态，测试过程中发现备份和快照功能都正常。机制测试迁移中的测试：在发起迁移时，首先会给源打上相应的ST属性，之后创建目标文件，给目标文件设置相关属性T，测试过程中，需要查看文件在迁移的时候是否真的会打上相应的属性，查看的方法如下：根据源文件副本的位置，使用stat命令查看其Access状态栏即可；查看linkto属性：getfattr-mlinkTo-etext-d副本根据目标复制组，获得brick，再根据brick地址和集群地址获得目标文件 的地址；使用stat查看目标文件的Access字段；使用getfattr查看其linkto属性以上就是所有的查询过程，测试时为了提高效率，使用的迁移文件都不大，所以迁移时间较短，要在这段时间内查看这些属性有一定的难度，所以在测试时写了个脚本，专门用于查看这些状态，脚本的运行结果如下图所示：迁移过程中第一个重点关注的问题是锁，glusterfs原生没有对flock锁进行处理，迁移结束后，业务在目标端丢失flock锁。如果另有业务对文件加flcok，新业务可以正常加上flcok锁，导致flock失效，从而造成数据问题。这个问题的解决方式是：在fd缓存中增加一个加锁的状态，若业务对文件加锁了，则在fd缓存中记录加锁状态，在目标卷打开文件之后，重新加锁。为了完成锁相关的测试，需要写些小工具来辅助测试，首先需要打开文件，持有文件的句柄，然后在发起迁移前或则迁移中对该文件进行加锁操作，加锁成功后，另开进程，再对该文件进行加锁，看其是否能够加锁成功；最后，等文件迁移完成后，再开进程对刚才迁移的文件进行加锁，正确的结果是后面两次加锁都不成功（因为第一次加锁成功后，锁一直没有释放）。加锁的时候，有一个问题需要注意：加正确的锁，刚开始测试的时候，是用如下的方式加锁的：但是这样测试后，测试结果是：迁移过程中新开的进程给文件加锁刚开始加不上，等文件迁移完后，这个锁又会重新自动加上。原因是：fcntl.LOCK_EX是阻塞锁，刚开始时加不上，锁处于阻塞状态，文件迁移完成后，源文件会打上unlink标记，这时最初加的锁会被释放，处于阻塞状态的锁就会被加上；所以加锁时，需要使用非阻塞锁，fcntl.LOCK_EX|fcntl.LOCK_NB，这样刚开始如果加锁不成功，锁不会处于阻塞状态，就不会有上面的问题。迁移过程中第二个重点关注的问题是业务的IO，定向热迁移中有一个需求是迁移时不关机，之所以能够实现不关机迁移，就是因为迁移过程中，平衡感知模块可以感知到文件处于迁移，这是业务IO不仅会往源副本中写，同时它也会往目标副本中写。这个过程中，测试需要关注的问题有：业务IO是否真的同时写入到源副本和目标副本、写入目标副本的数据是否正确等。针对数据是否正确写入到目标副本这个问题，测试的方法有三种，第一种是使用iso虚拟机，这个虚拟机可以自己检测数据是否丢失，如果迁移过程中存在数据丢失的情况，则一定可以检测出来（iso虚拟机里面IO太大，实际场景中，客户的业务IO一般是不会有这么大的，所以这种情况，不符合实际场景）；第二种方法是迁移过程中，写入一定量已知的数据，迁移完成后，找到目标副本（看其LV），查看其中是否有迁移过程中写入的数据，以及数据是否正确；第三种方法是，迁移前将文件复制一份，迁移过程中，往文件中写数据的同时也往复制的那份中写数据，迁移完成后，对比两份数据，看是否一致。当然，出了上面几个测试项之外，平衡过程中还需关注其他的一些小的测试点，比如迁移过程中，对虚拟机进行重命名、快照、备份等操作后是否会得到预期的效果，迁移过程中页面的显示情况（如下所示）等。故障处理迁移是一个费时间的过程，迁移一个500g的文件，实测需要10小时左右，这么长的时间内，环境可能出现各种各样的问题，所以测试时，必须要考虑真实环境中可能出现的各种异常问题。首先，考虑迁移前的故障处理，迁移前的故障主要有：源、目标副本存在离线，源存在指控等问题。在迁移前，会去校验两副本前128K数据是否一致，这是为了防止，brick替换后，还没有建立指控关系，这时一个副本其实是空的，如果选源时选到这个空的副本，则会造成数据丢失。这个问题的测试方法是：打开待迁移文件的一个副本，用hexedit将其前128K数据中的某字节数据改了，然后立刻发起迁移，如果这个时候，迁移失败并且有明确的失败日志，则表示逻辑正确。第二个问题是源、目标副本存在离线状态，构造离线环境可以使用下面两个方法：kill磁盘以及拔掉磁盘。Kill磁盘：glustervolumestatus查看卷的状态（如下图）：找到想要离线盘的pid，直接kill就可以；拔盘：首先找到brick，到相应主机中lsblk找到brick对应的序号，然后使用命令：vst_at_remove_one_disk.sh-dsdd拔掉这个盘，用例测试完成后，使用命令vs_hotplug.sh将盘插回。另外一种制造故障的方法是网络持续闪断，故障注入的方法是：setsidsshroot@200.200.175.27"/sf/vs/bin/vst_network_error.sh-ivs-e2,3,2,5,100&"，表示2~3秒时间内断网2~5秒，重复执行100次（当然这里的时间可以根据需求随意指定）数据迁移当前的机制是，在两个源副本中选择其中的一个，然后以这个副本为模板进行迁移，那么这里就会存在一个问题：在选源时如果源副本存在指控怎么办？为了测试这种场景，需要制造相互指控，方法可以是，开启iso虚拟机，然后拔掉一个源副本所在的盘（断网也行），之后，将盘插回，然后拔掉另一个盘，一段时间后，将盘插回，这样就制造了相互指控的场景，启动迁移即可。迁移后处理为了数据安全的安全性，现在的机制中，迁移完成后不会立刻将源文件unlink，而是会保存一段时间，所以整个迁移后的处理都是围绕迁移失败后的处理，比如业务关闭目标fd、迁移失败后的垃圾处理等。迁移失败后，业务应该会关闭目标副本的fd，并且会有相应的日志打出来，针对这个问题，可以使用python写一些小工具，持有文件的句柄后，在迁移过程中将一个目标副本离线，迁移失败然后再在相应的fuse日志中查看是否有记录（当时环境中的日志地址为：/sf/log/vs/glusterfs/log/glusterfs/sf-data-vs-gfs-rep2.log），迁移失败后，没有迁移完成的目标副本就是垃圾，需要被清理掉，垃圾清理的方式有三种：再次平衡、定时脚本、lookup操作。现有的机制是，垃圾没有被清理掉，该文件就不允许再次迁移，但是垃圾只有在两个垃圾副本都在线的情况下才能被清理（这种机制个人觉得有问题，因为迁移不成功，肯定是环境存在什么问题，比如目标副本所在盘离线，这时如果盘一直不上线，那么垃圾一直就不能被清理，则该文件永远不能迁移），所以测试的过程中，若是拔盘造成的迁移失败，则在盘不插回时无法再次迁移该文件。定时脚本删除垃圾的方法还没有测试，后面补上。。。PS：其实，再次平衡和定时脚本删除垃圾都是调用glustervolumerebalancevs_vol_rep2clean，所以在测试的时候，可以手动调用一下这个脚本，看垃圾是否是真的被删除了。策略测试前面说了，策略的作用相当于一个决策者，用于指定哪些文件需要搬到哪个地方去，所以测试的过程中主要关注的选源和选目的的正确性。策略的测试，首先关注的是一些平衡和迁移的公共项：不迁移重要虚拟机、优先迁移关机虚拟机、优先迁移较小的虚拟机、目标afr不能冲突等。测试方法也较为简单：将虚拟机设置为相应的状态，然后启动迁移或平衡观察选中的虚拟机是否满足条件，比如测试“优先迁移较小的虚拟机”时可以将虚拟机都设置为开/关机的状态，虚拟机文件的大小不一样，启动迁移后看选中的虚拟机是否是其中最小的那几个；另外，在平衡或迁移过程中，目标afr不能冲突（如果几个文件同时迁移到某个afr中，会抢占大量的IO，影响业务的运行），测试的时候可以构造如下环境，集群中某个复制组容量较为充裕，其他复制组剩余容量较少，执行平衡，看生成的迁移表中是否有多条迁移记录指向同一个复制组。这些公共项的测试方法都比较简单，需要什么环境直接构造就行，这里就不一一说明了。接下来的测试主要有三部分——平衡，迁移，附加测试，平衡和迁移的测试基本差不多，区别在于触发的条件；对于平衡来说，触发条件是：集群中，最高比例主机与最低比例主机相差20%，而对于迁移来说，触发条件是集群中某些主机剩余容量不足20%（比例可调）。所以这两部分的测试方法基本一致，关键在于如何构造所需的测试环境。构造环境，其实就是按照要求填写相应的配置文件，以模拟真实环境中存储的使用情况。在整个策略模块测试过程中，使用了三种环境的构造方法：第一种，直接按照json文件的格式一个个添加，首先是添加主机，然后添加磁盘，组成brick，最后再一个个地添加虚拟机，如下图所示：从中可以看到，只是往一个brick中添加4台主机，就需要占用这么大的篇幅，对于构造那些4主机以上、多磁盘的环境是相当困难的，所以才有了第二种构造方法。第二种环境构造方法是：使用函数的形式生成json文件，如下图所示，通过这种方式省去了大量的环境构造过程中重复的代码。有了上面的函数后，添加磁盘和主机将会变的很简单，如下所示：添加磁盘：添加虚拟机：然而这个方法也还是有三个缺陷：第一：与真实环境不符，原因在于上面的几个函数只是简单地将第一种方法中重复的代码做了一个循环实现而已，这样造成往所有brick中添加的虚拟机大小都是一致的（之后，再单独往一些brick中额外添加主机），而真实环境中基本不可能出现这样所有brick用量基本一致，虚拟机大小一致的情况；第二：这种函数的构造方式虽然简化了一定的重复代码，使得可以构造那种8~12个主机左右的环境，但是对于那种更大的集群就基本无能为力了；第三：大集群中要精确地检查迁移结果是很难的，真实环境中，其实没有必要做这么精确的判断，只需要做到平衡后集群用量比迁移前更加均衡就可以了，每次平衡后都比平衡前好一点，多平衡几次，结果就会有较大的提升。考虑到上面三个问题，有了如下图所示的第三种环境构造方式。在下面这种环境构造方式中，同样是通过一些函数来生成配置文件，不同的是：第一：只需要指定环境中主机数和磁盘数（若是需要测扩容，再增加一个需要扩容的主机数即可），就可以构造出所需的环境，构造大集群非常方便；第二：虚拟机的大小随机生成，更符合真实场景；