Google cloud platform 谷歌云文件存储在状态修复块*所有*

我们正在使用谷歌的文件存储云服务在我们的GCE虚拟机之间共享文件。随机地，所有进程似乎都挂起，特别是交互式SSH会话，经过一些调查，我们确定我们的文件存储（普遍安装在所有虚拟机上）正在修复，并且正在阻止所有试图获取有关它的任何信息的进程

我能够以root用户身份登录并进行调查，我注意到我的所有交互活动都将挂起，最终我将其定位为试图统计Filestore实例的挂载点。

strace df

会像这样挂起：

statfs("/sys/kernel/config", {f_type=0x62656570, f_bsize=4096, f_blocks=0, f_bfree=0, f_bavail=0, f_files=0, f_ffree=0, f_fsid={0, 0}, f_namelen=255, f_frsize=4096, f_flags=ST_VALID|ST_RELATIME}) = 0
stat("/sys/kernel/config", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
statfs("/sys/fs/selinux", {f_type=SELINUX_MAGIC, f_bsize=4096, f_blocks=0, f_bfree=0, f_bavail=0, f_files=0, f_ffree=0, f_fsid={0, 0}, f_namelen=255, f_frsize=4096, f_flags=ST_VALID|ST_RELATIME}) = 0
stat("/sys/fs/selinux", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
statfs("/proc/sys/fs/binfmt_misc", {f_type=BINFMTFS_MAGIC, f_bsize=4096, f_blocks=0, f_bfree=0, f_bavail=0, f_files=0, f_ffree=0, f_fsid={0, 0}, f_namelen=255, f_frsize=4096, f_flags=ST_VALID|ST_RELATIME}) = 0
stat("/proc/sys/fs/binfmt_misc", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
statfs("/dev/hugepages", {f_type=HUGETLBFS_MAGIC, f_bsize=2097152, f_blocks=0, f_bfree=0, f_bavail=0, f_files=0, f_ffree=0, f_fsid={0, 0}, f_namelen=255, f_frsize=2097152, f_flags=ST_VALID|ST_RELATIME}) = 0
stat("/dev/hugepages", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
statfs("/mnt/local-storage", {f_type=0x58465342, f_bsize=4096, f_blocks=131007745, f_bfree=86129973, f_bavail=86129973, f_files=262143488, f_ffree=262141571, f_fsid={2065, 0}, f_namelen=255, f_frsize=4096, f_flags=ST_VALID|ST_RELATIME}) = 0
stat("/mnt/local-extra", {st_mode=S_IFDIR|0755, st_size=75, ...}) = 0
statfs("/mnt/shared-storage" ***HANG***

[root@vm ~]# gcloud filestore instances list
INSTANCE_NAME  ZONE            TIER      CAPACITY_GB  FILE_SHARE_NAME  IP_ADDRESS     STATE      CREATE_TIME
shared-storage europe-west1-b  STANDARD  1024         shared_storage   **.**.**.**    REPAIRING  2019-08-09T16:03:02

除了等待维修作业完成外，显然没有任何补救措施

gcloud filestore operations list

显示在此期间没有正在进行的操作。但是，

gcloud filestore instances list

会显示如下状态：

statfs("/sys/kernel/config", {f_type=0x62656570, f_bsize=4096, f_blocks=0, f_bfree=0, f_bavail=0, f_files=0, f_ffree=0, f_fsid={0, 0}, f_namelen=255, f_frsize=4096, f_flags=ST_VALID|ST_RELATIME}) = 0
stat("/sys/kernel/config", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
statfs("/sys/fs/selinux", {f_type=SELINUX_MAGIC, f_bsize=4096, f_blocks=0, f_bfree=0, f_bavail=0, f_files=0, f_ffree=0, f_fsid={0, 0}, f_namelen=255, f_frsize=4096, f_flags=ST_VALID|ST_RELATIME}) = 0
stat("/sys/fs/selinux", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
statfs("/proc/sys/fs/binfmt_misc", {f_type=BINFMTFS_MAGIC, f_bsize=4096, f_blocks=0, f_bfree=0, f_bavail=0, f_files=0, f_ffree=0, f_fsid={0, 0}, f_namelen=255, f_frsize=4096, f_flags=ST_VALID|ST_RELATIME}) = 0
stat("/proc/sys/fs/binfmt_misc", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
statfs("/dev/hugepages", {f_type=HUGETLBFS_MAGIC, f_bsize=2097152, f_blocks=0, f_bfree=0, f_bavail=0, f_files=0, f_ffree=0, f_fsid={0, 0}, f_namelen=255, f_frsize=2097152, f_flags=ST_VALID|ST_RELATIME}) = 0
stat("/dev/hugepages", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
statfs("/mnt/local-storage", {f_type=0x58465342, f_bsize=4096, f_blocks=131007745, f_bfree=86129973, f_bavail=86129973, f_files=262143488, f_ffree=262141571, f_fsid={2065, 0}, f_namelen=255, f_frsize=4096, f_flags=ST_VALID|ST_RELATIME}) = 0
stat("/mnt/local-extra", {st_mode=S_IFDIR|0755, st_size=75, ...}) = 0
statfs("/mnt/shared-storage" ***HANG***

[root@vm ~]# gcloud filestore instances list
INSTANCE_NAME  ZONE            TIER      CAPACITY_GB  FILE_SHARE_NAME  IP_ADDRESS     STATE      CREATE_TIME
shared-storage europe-west1-b  STANDARD  1024         shared_storage   **.**.**.**    REPAIRING  2019-08-09T16:03:02

当时或前后从未出现任何问题

---

如果可能的话，有人知道为什么会发生这种情况以及如何防止这种情况发生吗。如上面的输出所示，我们使用的是文件存储的标准层。

我们已经将CoreDump配置为从24个VM写入共享，当我们的进程发生大规模死亡时，我们似乎达到了共享的吞吐量限制（标准层），这导致共享进入

修复状态，反过来阻止所有试图访问它的东西

如果您有类似的问题：检查您是否可能以某种方式达到了份额的吞吐量限制。
当我完成问题时，问题再次出现，即在最初事件发生后的半小时内-这次只花了几分钟时间思考。-没关系，它正在
修复
和
准备
之间切换：(