本文讨论了各种数据管理方法的优缺点,包括一致性、存储需求和性能
每天?分享?最新?软件?开发?,Devops,敏捷?,测试?以及?项目?管理?最新?,最热门?的?文章?,每天?花?3分钟?学习?何乐而不为?,希望?大家?点赞?,评论?,加?关注?,你的?支持?是我?最大?的?动力?。
随着容器化应用程序的加速采用,Day 2服务已经成为当前的问题。这些 Day 2服务包括数据管理功能,如备份和灾难恢复以及应用程序移动性。在这个集装箱化云本地应用的新世界中,微服务使用多种数据服务(MongoDB、 Redis、 Kafka 等)和存储技术来存储状态,并且通常部署在多个位置(区域、云、场所)。
在这种环境中,遗留基础设施或基于管理程序的解决方案无法工作,那么设计和实现这些云本地应用程序的数据管理功能的正确构造是什么?您应该如何推断存储供应商、数据服务供应商和云供应商提供的各种数据管理选项,以决定适合您的环境和需求的正确方法?本文深入探讨了各种数据管理方法的优缺点,包括一致性、存储需求和性能。
定义词汇
首先,我们将解构和简化一个堆栈,以显示数据可能驻留在云本机应用程序中的位置。
当考虑数据管理时,我们可以操作一个(或多个!)上图所示的层数。让我们列举这些层次:
1. 物理存储
这一层包括各种存储硬件选项,可以通过从 NVMe 和 SSD 设备到旋转磁盘甚至磁带的物理媒体选择非挥发性记忆体存储状态。它们以不同的形式出现,包括阵列和独立机架服务器。
物理存储可能位于:
- 您可能会遇到来自希捷(Seagate)、西部数据(Western Digital)和美光(Micron)等供应商的存储硬件
- 在托管云供应商的数据中心。虽然你可能永远不会遇到一个物理设备,你知道它在那里给“云”重力
2. 文件和块存储
这个软件层提供文件或块级构造,以便能够从底层物理存储进行有效的读写操作。在这两种情况下(文件和块) ,底层存储都可以是独立的(本地磁盘)或共享网络资源(NAS 或 SAN)。
- Block storage 块存储实现允许您从本地或远程磁盘创建原始存储卷,这些磁盘具有较低的延迟,可以通过像 iSCSI 这样的协议 云提供商的块存储实现包括 Amazon EBS 和 GCE 持久磁盘
- File Storage 文件存储 使用 NFS 和 SMB 等协议为文件语义和操作提供共享存储。常见的文件存储实现包括 NetApp 和 Dell EMC 的产品。云提供商的文件存储实现包括Amazon EFS 亚马逊 EFS, Google Cloud Filestore, and Azure Files. 谷歌云文件存储和 Azure 文件
这一层通常提供快照功能,以便创建卷的即时副本,以便进行保护。此外,在 Kubernetes 环境中,这个层提供容器存储接口(Container Storage Interface,CSI)驱动程序来规范化更高层可以调用快照功能的 API。请注意,并非所有 CSI 实现在所支持的功能方面都是相同的。
3. 数据服务
该层位于文件/块存储实现的顶部。它提供了各种数据库实现以及日益流行的存储类型,即对象(也称为 blob)存储。这是应用程序通常与之接口的层,基础数据库实现的选择基于工作负载和业务逻辑。对于基于微服务的应用程序,多语言持久性是一种规范,因为每个微服务都为手头的工作选择最合适的数据服务。
一些数据库类型和示例实现的子集包括:
- SQL Databases SQL 数据库: MySQL, PostgreSQL, SQL Server
- NoSQL Databases NoSQL 数据库:Key-Value Stores: Redis, BerkeleyDB ,Redis,BerkeleyDBTime-series Databases: InfluxDB, Prometheus ,Graph Databases: Neo4j, GraphDB : Neo4j,GraphDBWide-column stores: Cassandra, Azure Cosmos ,Azure CosmosDocument stores: MongoDB, CouchDB : MongoDB、 CouchDB
- Message Queues 消息队列: Kafka, RabbitMQ, Amazon SQS
- Object Stores 对象存储: Amazon S3, Google Cloud Storage, Minio
这些数据库还有几个托管实现,通常称为 Database-as-a-Service (DBaaS)系统。这些数据库通常包括上面列出的数据库类别之一,有时可以提供自动伸缩以及“即服务”(- aaS)业务的消费经济性。DBaaS 系统的例子包括 Amazon RDS、 MongoDB Atlas 和 Azure SQL。
从数据保护的角度来看,每个数据库实现都提供了一组特定的实用程序(用于 PostgreSQL 的 pg _ dump 或 WAL-E,用于 MongoDB 的 monGodump,等等)来备份和恢复数据。需要注意的是,有许多实用程序在一致性、恢复粒度和速度方面具有差异很大的功能。它们通常仅限于特定的数据库实现,或者最好是数据库类型,而不管它们是作为独立实用程序提供的,还是作为 -aaS 产品的一部分提供的。
4. 有状态应用
应用程序层是业务逻辑所在的地方,在云本地世界中,应用程序通常基于现代敏捷开发方法,并作为分布式微服务实现。几乎所有应用程序都有一个需要持久化的状态。虽然存储应用程序状态有几种模式,但是我们需要在有状态 Kubernetes 应用程序的上下文中将以下信息作为一个原子单元来保存和保护:
- Application Data: Across 跨各种数据服务、块和文件存储实现跨多个容器分布
- Application Definition and Configuration: 应用程序定义和配置: 应用程序映像和相关的环境配置分布在各种 Kubernetes 对象中,包括ConfigMaps 配置图, Secrets , etc. 等等
- Other Configuration State: 其他配置状态: 包括 CI/CD 管道状态、发布信息以及相关的Helm deployment metadata.
上图显示了一个有状态应用程序的示例,其中突出显示了需要保护的一些组件和相关状态。需要注意的是,对于真实的部署,应用程序由数百个这样的底层组件组成。此外,在云本机构造中,保护的原子性单元需要是应用程序与底层数据服务或存储基础设施层之间的对比。如前所述,这是因为应用程序的状态包括跨多个物理或虚拟节点和数据服务分布的应用程序数据、定义和配置。
结论
从备份/恢复和应用程序可移植性的角度来看,一个好的数据管理解决方案需要将整个应用程序视为原子性单元,从而使传统的以 hypervisor 为中心的解决方案过时。我们还演示了一个简单的堆栈图,从各种数据服务、块和文件存储以及物理存储的角度,展示了应用程序状态实际驻留在哪里。这定义了一个基本词汇表,使我们能够深入了解云数据管理的操作层。
脚注
1.有些人可能认为对象存储应该与文件/块属于同一层。在本文中,对象存储将被视为另一个具有键-值接口的数据服务,如果需要,可以在 Kubernetes 内运行。
如若转载,请注明出处:https://www.hanjifoods.com/16006.html