重新挂载和重新格式化存储卷(手动步骤

要重新挂载保留的存储卷并重新格式化任何故障存储卷,您必须手动运行两个脚本。第一个脚本将重新挂载格 StorageGRID 式正确的卷,使其格式化为 StorageGRID 存储卷。第二个脚本将重新格式化所有已卸载的卷,根据需要重新构建 Cassandra 并启动服务。

开始之前

关于本任务

要完成此操作步骤,请执行以下高级任务:

过程

  1. 从服务笔记本电脑登录到已恢复的存储节点:
    1. 输入以下命令: SSH admin@grid_node_IP
    2. 输入 Passwords.txt 文件中列出的密码。
    3. 输入以下命令切换到 root : su -
    4. 输入 Passwords.txt 文件中列出的密码。
    以 root 用户身份登录时,提示符将从 $ 更 改为 #
  2. 运行第一个脚本重新挂载任何格式正确的存储卷。
    注: 如果所有存储卷都是新的,需要进行格式化,或者所有存储卷都出现故障,您可以跳过此步骤并运行第二个脚本,重新格式化所有已卸载的存储卷。
    1. 运行脚本: sn-remount-volumes
      此脚本可能需要数小时才能在包含数据的存储卷上运行。
    2. 在脚本运行期间,查看输出并问题解答任何提示。
      注: 根据需要,您可以使用 tail -f 命令监控脚本日志文件(/var/local/log/sn-remount-volumes.log)的内容。日志文件包含比命令行输出更详细的信息。
      root@SG:~ # sn-remount-volumes
      The configured LDR noid is 12632740
      
      ====== Device /dev/sdb ======
      Mount and unmount device /dev/sdb and checking file system consistency:
      The device is consistent.
      Check rangedb structure on device /dev/sdb:
      Mount device /dev/sdb to /tmp/sdb-654321 with rangedb mount options
      This device has all rangedb directories.
      Found LDR node id 12632740, volume number 0 in the volID file
      Attempting to remount /dev/sdb
      Device /dev/sdb remounted successfully
      
      ====== Device /dev/sdc ======
      Mount and unmount device /dev/sdc and checking file system consistency:
      Error: File system consistency check retry failed on device /dev/sdc. 
      You can see the diagnosis information in the /var/local/log/sn-remount-volumes.log.
      
      This volume could be new or damaged. If you run sn-recovery-postinstall.sh,
      this volume and any data on this volume will be deleted. If you only had two
      copies of object data, you will temporarily have only a single copy.
      StorageGRID Webscale will attempt to restore data redundancy by making
      additional replicated copies or EC fragments, according to the rules in
      the active ILM policy.
      
      Do not continue to the next step if you believe that the data remaining on
      this volume cannot be rebuilt from elsewhere in the grid (for example, if
      your ILM policy uses a rule that makes only one copy or if volumes have
      failed on multiple nodes). Instead, contact support to determine how to
      recover your data.
      
      ====== Device /dev/sdd ======
      Mount and unmount device /dev/sdd and checking file system consistency:
      Failed to mount device /dev/sdd
      This device could be an uninitialized disk or has corrupted superblock.
      File system check might take a long time. Do you want to continue? (y or n) [y/N]? y
      
      Error: File system consistency check retry failed on device /dev/sdd. 
      You can see the diagnosis information in the /var/local/log/sn-remount-volumes.log.
      
      This volume could be new or damaged. If you run sn-recovery-postinstall.sh,
      this volume and any data on this volume will be deleted. If you only had two
      copies of object data, you will temporarily have only a single copy.
      StorageGRID Webscale will attempt to restore data redundancy by making
      additional replicated copies or EC fragments, according to the rules in
      the active ILM policy.
      
      Do not continue to the next step if you believe that the data remaining on
      this volume cannot be rebuilt from elsewhere in the grid (for example, if
      your ILM policy uses a rule that makes only one copy or if volumes have
      failed on multiple nodes). Instead, contact support to determine how to
      recover your data.
      
      ====== Device /dev/sde ======
      Mount and unmount device /dev/sde and checking file system consistency:
      The device is consistent.
      Check rangedb structure on device /dev/sde:
      Mount device /dev/sde to /tmp/sde-654321 with rangedb mount options
      This device has all rangedb directories.
      Found LDR node id 12000078, volume number 9 in the volID file
      Error: This volume does not belong to this node. Fix the attached volume and re-run this script.

      在示例输出中,一个存储卷已成功重新挂载,三个存储卷出现错误。

      • /dev/sdb 已通过 XFS 文件系统一致性检查并具有有效的卷结构,因此已成功重新挂载。此脚本重新挂载的设备上的数据将保留下来。
      • /dev/sdc 由于存储卷是新卷或已损坏, XFS 文件系统一致性检查失败。
      • /dev/sdd 无法挂载,因为磁盘已取消初始化或磁盘的超级块已损坏。当脚本无法挂载存储卷时,它会询问您是否要运行文件系统一致性检查。
        • 如果存储卷已连接到新磁盘,请通过问题解答 N 访问提示符。您无需检查新磁盘上的文件系统。
        • 如果存储卷已连接到现有磁盘,请通过问题解答 Y 访问提示符。您可以使用文件系统检查的结果来确定损坏的来源。结果将保存在 /var/local/log/sn-remount-volumes.log 日志文件中。
      • /dev/sde 已通过 XFS 文件系统一致性检查,并且卷结构有效;但是, volID 文件 中的 LDR 节点 ID 与此存储节点的 ID 不匹配(已配置的 LDR 节点 ID 显示在顶部)。此消息表示此卷属于另一个存储节点。
  3. 查看脚本输出并解决任何问题。
    注意: 如果存储卷未通过 XFS 文件系统一致性检查或无法挂载,请仔细查看输出中的错误消息。您必须了解在 这些卷上运行 sn-recovery-postinstall.sh 脚本的含义。
    1. 检查以确保结果中包含所需所有卷的条目。如果未列出任何卷,请重新运行此脚本。
    2. 查看所有已挂载设备的消息。确保没有指示存储卷不属于此存储节点的错误。
      在此示例中,的输出 /dev/sde 包含以下错误消息:
      错误:此卷不属于此节点。修复连接的卷并重新运行此脚本。
      警告:
      如果报告某个存储卷属于另一个存储节点,请联系技术支持。如果运行 sn-recovery-postinstall.sh 脚本,则存储卷将重新格式化,从而可能会丢失发生原因数据。
    3. 如果无法挂载任何存储设备,请记下此设备的名称,然后修复或更换此设备。
      注: 您必须修复或更换任何无法挂载的存储设备。
      您将使用设备名称查找卷 ID ,在运行 repair-data 脚本将对象数据还原到卷(下一个操作步骤)时,需要输入此 ID 。
    4. 修复或替换所有无法挂载的设备后, 再次运行 sn-remount-volumes 脚本,以确认所有可重新挂载的存储卷均已重新挂载。
    注意: 如果无法挂载存储卷或存储卷格式不正确,而您继续执行下一步,则此卷以及此卷上的任何数据将被删除。如果对象数据有两个副本,则只有一个副本,直到完成下一个操作步骤(还原对象数据)为止。
    警告:
    如果您认为无法从网格中的其他位置重建故障存储卷上的剩余数据,请勿运行 sn-recovery-postinstall.sh 脚本(例如, ILM 策略使用的规则仅创建一个副本或卷在多个节点上发生故障)。请联系技术支持以确定如何恢复数据。
  4. 运行 sn-recovery-postinstall.sh 脚本: sn-recovery-postinstall.sh
    此脚本将重新格式化无法挂载或格式不正确的任何存储卷;根据需要在节点上重建 Cassandra 数据库;并启动存储节点上的服务。
    请注意以下事项:
    • 此脚本可能需要数小时才能运行。
    • 通常,在脚本运行期间,您应单独保留 SSH 会话。
    • Ctrl+C SSH 会话处于活动状态时,请勿按。
    • 如果发生网络中断并终止 SSH 会话,则此脚本将在后台运行,但您可以从 " 恢复 " 页面查看进度。
    • 如果存储节点使用 RSM 服务,则随着节点服务重新启动,脚本可能会暂停 5 分钟。每当 RSM 服务首次启动时,预计会有 5 分钟的延迟。
      注: RSM 服务位于包含此 ADC 服务的存储节点上。
  5. 运行 sn-recovery-postinstall.sh 脚本时,监控 网格管理器中的恢复页面。
    " 恢复 " 页面上的进度条和阶段列可提供 sn-recovery-postinstall.sh 脚本的高级状态。
    显示网格管理界面中的恢复进度的屏幕截图

下一步操作

在 sn-recovery-postinstall.sh 脚本启动节点上的服务后,您可以将对象数据还原到由该脚本格式化的任何存储卷,如下一个操作步骤中所述。