Skip to main content
本产品推出了新版本。
简体中文版经机器翻译而成，仅供参考。如与英语版出现任何冲突，应以英语版为准。

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

贡献者
PDF

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

开始之前

  • 您已更换已知需要更换的任何故障存储卷的硬件。

    运行 sn-remount-volumes 脚本可能有助于您确定其他故障存储卷。

  • 您已检查是否未在执行存储节点停用，或者已暂停节点停用操作步骤 。（在网格管理器中，选择 * 维护 * > * 任务 * > * 取消配置 * 。）

  • 您已检查扩展是否未在进行中。（在网格管理器中，选择 * 维护 * > * 任务 * > * 扩展 * 。）

  • 您已拥有 "已查看有关存储节点系统驱动器恢复的警告"。

    注意 如果多个存储节点脱机或此网格中的存储节点在过去 15 天内已重建，请联系技术支持。请勿运行 sn-recovery-postinstall.sh 脚本。在两个或多个存储节点上相互重建 Cassandra 的 15 天内可能会导致数据丢失。
关于此任务

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

  • 登录到已恢复的存储节点。

  • 运行 sn-remount-volumes 用于重新挂载格式正确的存储卷的脚本。运行此脚本时，它将执行以下操作：

    • 挂载和卸载每个存储卷以重放 XFS 日志。

    • 执行 XFS 文件一致性检查。

    • 如果文件系统一致，则确定存储卷是否为格式正确的 StorageGRID 存储卷。

    • 如果存储卷格式正确，请重新挂载该存储卷。卷上的所有现有数据保持不变。

  • 查看脚本输出并解决任何问题。

  • 运行 sn-recovery-postinstall.sh 脚本。运行此脚本时，它将执行以下操作。

    重要说明 在运行之前、请勿在恢复期间重新启动存储节点 sn-recovery-postinstall.sh 重新格式化故障存储卷并还原对象元数据。之前重新启动存储节点 sn-recovery-postinstall.sh 完成会导致尝试启动的服务出错、并导致StorageGRID 设备节点退出维护模式。请参见的步骤 安装后脚本。

    • 重新格式化所使用的任何存储卷 sn-remount-volumes 脚本无法挂载或格式不正确。

      备注 如果重新格式化某个存储卷，则该卷上的所有数据都将丢失。假设已将 ILM 规则配置为存储多个对象副本，则必须执行额外的操作步骤 以从网格中的其他位置还原对象数据。

    • 如果需要，在节点上重建 Cassandra 数据库。

    • 启动存储节点上的服务。

步骤

  1. 登录到已恢复的存储节点：

    1. 输入以下命令： ssh admin@grid_node_IP

    2. 输入中列出的密码 Passwords.txt 文件

    3. 输入以下命令切换到root： su -

    4. 输入中列出的密码 Passwords.txt 文件

    以root用户身份登录后、提示符将从变为 $ to #。

  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.

Don't continue to the next step if you believe that the data remaining on
this volume can't 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.

Don't continue to the next step if you believe that the data remaining on
this volume can't 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 * 问题解答 到提示符处。您不需要检查新磁盘上的文件系统。

        • 如果存储卷已连接到现有磁盘，问题解答 请将 * 。 *您可以使用文件系统检查的结果来确定损坏的来源。结果将保存在中 /var/local/log/sn-remount-volumes.log 日志文件。

      • /dev/sde 已通过XFS文件系统一致性检查并具有有效的卷结构；但是、volID文件中的LDR节点ID与此存储节点( configured LDR noid 显示在顶部)。此消息表示此卷属于另一个存储节点。

  3. 查看脚本输出并解决任何问题。

    重要说明 如果存储卷未通过 XFS 文件系统一致性检查或无法挂载，请仔细查看输出中的错误消息。您必须了解运行的含义 sn-recovery-postinstall.sh 在这些卷上创建脚本。

    1. 检查以确保结果中包含所需所有卷的条目。如果未列出任何卷、请重新运行此脚本。

    2. 查看所有已挂载设备的消息。确保没有指示存储卷不属于此存储节点的错误。

      在此示例中、为输出 /dev/sde 包括以下错误消息：

      Error: This volume does not belong to this node. Fix the attached volume and re-run this script.
      注意 如果报告某个存储卷属于另一个存储节点，请联系技术支持。如果您运行的是 sn-recovery-postinstall.sh 脚本中、存储卷将重新格式化、这可能会导致发生原因 数据丢失。

    3. 如果无法挂载任何存储设备，请记下此设备的名称，然后修复或更换此设备。

      备注 您必须修复或更换任何无法挂载的存储设备。

      您将使用设备名称查找卷ID、运行时需要输入此ID repair-data 用于将对象数据还原到卷(下一个操作步骤)的脚本。

    4. 修复或更换所有无法挂载的设备后、运行 sn-remount-volumes 重新编写脚本以确认所有可重新挂载的存储卷均已重新挂载。

      重要说明 如果某个存储卷无法挂载或格式不正确、则在继续下一步后、该卷以及该卷上的任何数据将被删除。如果对象数据有两个副本，则只有一个副本，直到完成下一个操作步骤 （还原对象数据）为止。
    注意 请勿运行 sn-recovery-postinstall.sh 如果您认为无法从网格中的其他位置重建故障存储卷上剩余的数据(例如、ILM策略使用的规则仅创建一个副本、或者卷在多个节点上发生故障)、请编写脚本。请联系技术支持以确定如何恢复数据。

  4. 运行 sn-recovery-postinstall.sh 脚本： sn-recovery-postinstall.sh

    此脚本将重新格式化无法挂载或格式不正确的任何存储卷；根据需要在节点上重建 Cassandra 数据库；并启动存储节点上的服务。

    请注意以下事项：

    • 此脚本可能需要数小时才能运行。

    • 通常，在脚本运行期间，您应单独保留 SSH 会话。

    • 在SSH会话处于活动状态时，请勿按*Ctrl+C*。

    • 如果发生网络中断并终止 SSH 会话，则此脚本将在后台运行，但您可以从 " 恢复 " 页面查看进度。

    • 如果存储节点使用 RSM 服务，则随着节点服务重新启动，脚本可能会暂停 5 分钟。每当 RSM 服务首次启动时，预计会有 5 分钟的延迟。

      备注 RSM 服务位于包含此 ADC 服务的存储节点上。
    备注 某些 StorageGRID 恢复过程使用 Reaper 处理 Cassandra 修复。一旦相关服务或所需服务开始，便会自动进行修复。您可能会注意到脚本输出中提到 " reaper " 或 "`Cassandra repair.` " 。 如果您看到指示修复失败的错误消息，请运行错误消息中指示的命令。

  5. [[post-install-script-step ]]作为 sn-recovery-postinstall.sh 脚本运行时、监控网格管理器中的恢复页面。

    "恢复"页面上的进度条和阶段列可提供的高级状态 sn-recovery-postinstall.sh 脚本。

    显示网格管理界面中的恢复进度的屏幕截图

  6. 在之后 sn-recovery-postinstall.sh 脚本已在节点上启动服务、则可以将对象数据还原到由脚本格式化的任何存储卷。

    该脚本会询问您是否要手动还原对象数据。

    • 在大多数情况下、您应该这样做 "使用网格管理器还原对象数据"。问题解答 n 以使用网格管理器。

    • 在极少数情况下、例如在技术支持的指导下、或者您知道替代节点可用于对象存储的卷少于原始节点时、您必须执行此操作 "手动还原对象数据" 使用 repair-data 脚本。如果其中一种情况适用、请选择问题解答 y。

      备注

      如果使用问题解答 y 手动还原对象数据：

      • 您无法使用网格管理器还原对象数据。

      • 您可以使用网格管理器监控手动还原作业的进度。