所以我在每个节点上创建了带有NVME磁盘的i3.large,这是我的过程:
所以这一切都有效,我可以连接回实例。我有500个Go在我的新分区上。
但在我停止并重新启动EC2机器后,其中一些随机变得无法访问(AWS警告仅检查1/2测试状态)
当我看到它无法访问的日志时,它告诉我,它是关于nvme分区(但是我做了sudo mount -a来检查这是否正常,所以我不明白)
我没有准确的AWS日志,但我得到了一些内容:
尝试打开时超级块中的错误幻数
然后超级块已损坏,您可以尝试使用备用超级块运行e2fsck:
/ dev / fd / 9:第2行:plymouth:命令未找到
答案 0 :(得分:12)
停止并启动实例会擦除临时磁盘,将实例移动到新的主机硬件,并为您提供新的空磁盘......因此,在停止/启动后,临时磁盘将始终为空白。当实例停止时,它在任何物理主机上都不存在 - 资源被释放。
因此,最好的方法是,如果您要停止并启动实例,则不是将它们添加到/etc/fstab
,而是在第一次启动时将它们格式化并在此之后安装它们。测试文件系统是否已存在的一种方法是使用file
实用程序和grep
其输出。如果grep找不到匹配项,则返回false。
i3实例类上的NVMe SSD是Instance Store Volume的示例,也称为 Ephemeral [Disk |卷|驱动程序。它们实际上位于实例内部且非常快,但不是冗余的,不适用于持久数据......因此,“短暂的”。持久性数据需要位于Elastic Block Store (EBS)卷或Elastic File System (EFS),这两个卷都可以在实例停止/启动,硬件故障和维护时继续存在。
目前尚不清楚为什么你的实例无法启动,但nofail
可能没有按照你期望的那样存在卷但没有文件系统。我的印象是最终它应该成功。
但是,如果运行Ubuntu 16.04,则可能需要apt-get install linux-aws
。 Ubuntu 14.04 NVMe支持不是很稳定not recommended。
这三种存储解决方案中的每一种都有其优点和缺点。
Instance Store是本地的,所以它很快......但是,它是短暂的。它经受住了硬性和软性的重新启动,但没有停止/启动周期。如果您的实例遇到硬件故障,或者计划退役,最终发生在所有硬件上,则必须停止并启动实例以将其移至新硬件。保留和专用实例不会更改短暂的磁盘行为。
EBS是持久的冗余存储,可以从一个实例分离并移动到另一个实例(这会在停止/启动时自动发生)。 EBS支持时间点快照,这些在块级别是增量的,因此您不需要为存储未在快照中更改的数据付费...但是通过一些优秀的巫术,您也没有跟踪“完整”与“增量”快照 - 快照只是指向备份数据块指针的逻辑容器,因此它们本质上是所有“完整”快照,但只是按照增量计费。删除快照时,只有不再需要的块才能从后端存储系统中清除该快照和任何其他快照(对您而言,实际上使用的是Amazon S3)。
EBS卷既可作为SSD,也可作为旋转盘片磁性卷,同样需要在成本,性能和适当的应用方面进行权衡。见EBS Volume Types。 EBS卷模仿普通硬盘,除了它们的容量可以按需手动增加(但不减少),并且可以在不关闭系统的情况下从一种卷类型转换为另一种卷类型。 EBS可以即时完成所有数据迁移,性能降低但不会中断。这是一项相对较新的创新。
EFS使用NFS,因此您可以在任意数量的实例上安装EFS文件系统,甚至可以跨一个区域内的可用区域安装。 EFS中任何一个文件的大小限制为52太字节,您的实例实际上将报告8艾字节的可用空间。实际可用空间用于所有实际目的是无限的,但EFS也是最昂贵的 - 如果你在那里存储了一个52 TiB文件一个月,那么存储将花费超过15,000美元。我储存的最多的是2周大约20 TiB,花了我大约5万美元,但如果你需要空间,那里就有空间。它按小时收费,所以如果您将52 TiB文件存储了几个小时然后将其删除,那么您只需支付50美元。 EFS中的“弹性”是指容量和价格。您没有在EFS上预先设置空间。您可以使用所需的内容并删除不需要的内容,并按小时计算可计费大小。
如果没有S3,存储的讨论就不会完整。它不是文件系统,它是一个对象存储。在EFS价格的约1/10,S3也有效无限容量,最大物体尺寸为5TB。使用S3对象而不是文件可以更好地设计某些应用程序。
S3也可以由AWS以外的系统轻松使用,无论是在您的数据中心还是在其他云中。其他存储技术旨在在EC2内部使用,但有undocumented workaround允许EFS在外部或跨区域使用,具有代理和隧道。
答案 1 :(得分:1)
您可能会发现配备本地NVMe存储的有用的新EC2实例系列: C5d 。
请参阅公告博文:https://aws.amazon.com/blogs/aws/ec2-instance-update-c5-instances-with-local-nvme-storage-c5d/
博文中的一些摘录:
答案 2 :(得分:1)
近一个月以来,我一直在使用“ c5”类型的实例,“ c5d.4xlarge”主要用于nvme驱动器。所以,这是对我有用的东西:
首先获取nvme的位置:
lsblk
我的总是安装在nvme1n1
然后检查是否为空卷并且没有任何文件系统(除非您要重新挂载,否则大多数情况下不会)。对于空驱动器,输出应为/dev/nvme1n1: data
:
sudo file -s /dev/nvme1n1
然后执行此操作以进行格式化(如果从上一步中您了解到您的驱动器具有文件系统并且不是空驱动器。请跳过此步并转到下一步):
sudo mkfs -t xfs /dev/nvme1n1
然后在当前目录中创建一个文件夹并挂载nvme驱动器:
sudo mkdir /data
sudo mount /dev/nvme1n1 /data
您现在甚至可以通过运行以下命令来检查它的存在:
df -h
答案 3 :(得分:0)
我刚刚有类似的经历!我的C5.xlarge实例将EBS检测为nvme1n1。我在fstab中添加了这一行。
/dev/nvme1n1 /data ext4 discard,defaults,nofail 0 2
经过几次重启后,它看起来很有效。它一直运行数周。但今天,我只是警惕实例无法连接。我尝试从AWS控制台重新启动它,没有运气看起来罪魁祸首是fstab。磁盘安装失败。
我将门票提升到AWS支持,但还没有反馈。我必须启动一个新实例来恢复我的服务。
在另一个测试实例中,我尝试使用UUID(通过命令blkid获取)而不是/ dev / nvme1n1。到目前为止看起来仍然有效...将看它是否会引起任何问题。
如果有任何AWS支持反馈,我会在此更新。
================使用我的修复编辑===========
AWS还没有给我反馈,但我发现了这个问题。实际上,在fstab中,无论你挂载/ dev / nvme1n1还是UUID,都没关系。我的问题是,我的ESB在文件系统中有一些错误。我将它附加到一个实例然后运行
fsck.ext4 /dev/nvme1n1
修复了几个文件系统错误后,把它放在fstab中,重启,没问题了!