关于Cloud-云上的磁盘的创建与在操作系统OS中的使用

Posted 2023-06-08

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了关于Cloud-云上的磁盘的创建与在操作系统OS中的使用相关的知识，希望对你有一定的参考价值。

其实无论对于AWS，还是Azure，或者是其他的Cloud云环境，工作运维中，都会涉及到磁盘的创建与使用

总体说来，就如下几个步骤

第一步：需要在云平台上，磁盘卷管理界面中创建一个新的磁盘

第二步：将磁盘挂载(Attach)到虚拟机上，AWS上称为EC2

第三步：就是在系统中能看到一块全新的磁盘了，接下来就是在OS中的使用了

今天笔者主要就是讲的第三步：在OS中如何使用，这里以Linux为例，其实Windows上的操作也是很简单的

1、对于Linux，我们可以通过 fdisk -l ，parted -l ，或者lsbllk 命令列出系统的磁盘/块设备文件，如下可以看到新加的磁盘 /dev/nvme1n1

[root@qq-5201351 ~]# lsblk
NAME              MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
.....省略部分........
nvme1n1           259:4    0    5G  0 disk

[root@qq-5201351 ~]#
[root@qq-5201351 ~]# parted -l
.....省略部分........
Error: /dev/nvme1n1: unrecognised disk label
Model: NVMe Device (nvme)
Disk /dev/nvme1n1: 5369MB
Sector size (logical/physical): 512B/512B
Partition Table: unknown
Disk Flags:

[root@qq-5201351 ~]#

这里因为是一块新的磁盘，还没有分过区，所以Partition Table:的值为unknown

其实在早期时，磁盘在操作系统OS中，是没有办法直接创建文件系统使用的，都是需要先分区，再对分区创建文件系统，最后再挂载使用

后来磁盘管理等各种技术有了一些新的发展进步、允许直接对一个新的磁盘，直接创建文件系统(在Windows中，也常称为格式化)，

这种方式在Cloud云上也非常常见，对于文件系统的扩展也变得非常容易了，

2、这里我们就可以直接使用如下的方式进行格式化了

ext4文件系统：mkfs.ext4 /dev/nvme1n1

xfs文件系统：mkfs.xfs /dev/nvme1n1 # 如果文件系统已经存在，需要加上 -f 选项，强制overwrite覆盖

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

3、分区文件系统的使用，在linux中一般是需要将FS文件系统挂载到目录上才能使用的,可以基于块文件名挂载，也可以通过uuid进行挂载

查询文件系统的uuid： blkid /dev/nvme1n1

基于文件系统的详细路径挂载到OS目录： mount /dev/nvme1n1 /MyData

基于文件系统的UUID挂载到OS目录（推荐）： mount -U 794a9494-b004-432a-a5ac-1bdf395a5f5a /MyData

补充说明：

1、上面的称为临时挂载，也可以将FS信息加入到 /etc/fstab 配置文件中，达到开机自动挂载的效果，笔者将在后续的文件中讲解详细的过程

2、对于上面直接格式化一整块磁盘后，再查看分区表类型，可看到即不是msdos,也不是gpt，而是loop，这种就不会有msdos的2TB大小的限制了

尊重别人的劳动成果转载请务必注明出处：https://www.cnblogs.com/5201351/p/17461724.html

阿里云ACM：云原生配置管理利器，让云上的Spring Cloud应用配置管理舞动起来

在传统架构中，如果配置信息有变更，通常是登陆服务器手动修改配置来使配置生效。在微服务架构中，应用数和节点数由于微服务化数量激增，导致发布次数增加，配置变更难度加大，通常是将应用配置抽象出来放置在外部的配置中心里，从而实现配置变更的自动化，但这类原生方案会存在依赖严重、发布延时高的问题。

Spring Cloud中的标准配置管理方法和存在的问题

以Spring Cloud为例，其提供了Spring Cloud Config组件来默认对配置进行管理。

关于Spring Cloud Config的工作原理，如下图所示：

技术分享图片

和传统人肉到生产服务器上一台台手动修改配置的思路不同，在Spring Cloud中，当用户配置发生变化时，用户可以在Git中修改配置，再通过Spring Cloud Config Server动态下发配置，从而在各个机器上动态生效。其整个流程大概如下：

用户在Git中update和commit配置；
Spring Cloud Config Server通过回掉，获取更新配置；
用户在其中任一一台机器上执行配置刷新操作 (图中为 "post /bus/refresh")
目标机 (App A)在Config Server中拉取最新配置，并发送消息到消息总线中，通知其他机器配置被变更；
所有其他机器通过消息总线获知配置刷新后，在Config Server中拉取最新配置。

至此，配置修改完成。

Spring Cloud Config组件成功的以配置中心思路解决了静态配置繁琐的运维问题，但是Spring Cloud Config仍存在以下问题：

标准方案依赖Git。虽然提供其他存储支持，但是标准的Git方案饱受争议，毕竟Git运维在业界算是小众领域，在关键的生产环境中使用得并不多(开发测试环境除外)；
配置变更依赖Cloud Bus，架构复杂的同时，存在配置的一致性问题；
整个配置的时效性较低。由于发布路径长，中间存在多个异步操作，因此从发布到最后所有配置生效，延时可能会是分钟级别。

阿里云ACM为spring cloud带来的配置管理优化

阿里云应用配置管理服务ACM，作为Nacos的云上实现，可以将以上的配置管理问题进行优化，配置修改将变得异常简单和高效，如下图所示。

技术分享图片

整个操作流程分为两步：

用户在ACM中修改配置内容;
ACM动态推送到所有应用中。

ACM全面兼容Spring框架接口，包括Spring Framework、Spring Boot和Spring Cloud，其为 Spring Cloud编写的应用配置管理，和Spring Cloud Config对比，由于极简的架构，带来了众多的好处：

配置变更推送性能高，根据阿里巴巴内部的性能统计来看，绝大多数情况下，配置推送0.5秒生效，99.9%场景下，3秒以内能推送到上千台机器；
运维简单，不需要额外的Git存储或Cloud Bus组件，单应用接口即可完成所有配置中心功能；
遵循开源精神，ACM作为Nacos的云上实现，用户无需额外付费即可使用全部功能。

Spring Cloud用户可以基于Spring Cloud Config提供的接口将Spring Cloud应用的配置管理无缝迁移到ACM上，大幅度提升基于Spring Cloud框架的微服务应用的配置管理敏捷性。此外，相比于Spring Cloud Config，ACM还拥有多项实用功能，例如，云上配置安全合规，配置灰度发布和回滚等。