云原生敏捷基础设施学习笔记

云原生敏捷基础设施学习笔记

1. 云原生概述

1.1 云原生定义

云原生是一种构建和运行应用程序的方法，它利用了云计算交付模型的优势。“云原生”是关于如何创建和部署应用程序，8而部署内部部署数据中心。
CNCF将“云原生”定义得更为狭窄，意味着使用开源软件堆栈进行容器化，其中应用程序的每个部分都打包在自己的容器中，动态编排，以便对每个部分进行主动调度和管理以优化资源利用率和面向微服务的应用程序，以提高应用程序，以提高应用程序的整体灵活性和可维护性。

由于本资料总结于2018，因此技术发展史仅到2018年7月，详细的技术发展史请在CNCF官网查询

1.2 云原生现状（CNCF全景图）

CNCF的Landscape已经提供了非常之多的云原生相关的工具、平台与框架进行选择，如果是路线图给出的是答题的方向指引，而Landscape则主要是提供具体的可供落地实施的工具方法，在企业退休云原生应用落地的时候，应该作为首选参照的内容之一。
最新的CNCF全景图请参考：https://landscape.cncf.io/images/landscape.png

本全景图的简易表示如下：

在整个Landscape中按照功能或模块分为29个部分，分别归属于9种类型或者分层（包括生态中的培训等部分，不是特别严谨），包括当前CNCF在孵化中和已经毕业的22个项目，相关的详细信息如下所示：

1.3 CNCF路线图（中文2019年7月）

1. 集装箱化

• 通常用docker容器
• 任何大小的应用程序和依赖项（即使是在模拟器上运行的PDP-11代码）都可以被包含
• 随着时间的推移，您应该期望合适的应用程序分割开来，并将未来的功能编写为微服务

2. CI/CD

• 设置持续集成/持续交付（CI/CD），这样对源代码的更改就会自动生成一个新的容器，对其进行测试，并将其部署到slaging，最终可能将其部署到生产环境中。
• 设置自动滚动、回滚和测试。

3. 业务编排和应用程序定义

• Kubernetes 是市场领先的编排解决方案 您应该选择一个经过认证的

• Kubernetes发行版、托管平台或安装程序：
  cncf.io/ck

• Helm Charts帮助您定义、安装和升级最复杂的Kubernetes应用程序。

4. 可观测性与可分析性

• 选择用于监视、日志记录和跟踪的解决方案。
• 以CNCF项目为例，Prometheus项目用于监控，Fluentd项目用于伐木，Jaeger项目用于追踪。
• 要进行跟踪，请寻找与OpenTracing兼容的实现，如jaeger。

5. 服务代理，发现和网格

• CoreDNS是一种快速二灵活的工具，对于服务发现非常有用
• Envoy和Linkerd 分别启用服务网络架构
• 提供健康检查、路由和负载平衡。

6. 网络与政策

• 要启用更灵活的网络，请使用与cni兼容的网络项目，如Calico、Flannel或Weave
  Net。开放策略代理（OPA）是一个通用的策略引擎，使用范围从售前和允许控制到数据过滤。

7. 分布式数据库与存储

• Vitess通过分片大规模运行MySQL与耽搁数据库相比，弹性和可伸缩性更为优秀。Rook是一个存储协调器，它将一组不同的存储解决方案集成到Kubernetes中。作为Kunbernets的“大脑”
  eted提供了一种可靠的方法来跨集群存储数据。Tikv是一种高性能的分布式事务键值管理器。

8. 流和消息传递

• 需要比JSON-REST更高的性能时，可以考虑使用gPRC或NATS。
  gRPC是一个通用的RPC框架。NATS是一个多模式消息传递系统，包括请求/应答、发布/订阅和负载平衡队列。

9. 容器注册和运行

• Harbor是一个存储、表示和扫描内容的注册表。可以替代的容器运行。最常见OCI为containerd， rkt 和 CRI-O。

10. 软件分发

• 安全的软件发布，评估工作，更新框架

1.4 Cloud Native 成熟度模型

1.5 Cloud Native 的原则

1. 为失败设计原则：
设计服务时应充分考虑异常情况，从使用者的角度，能够容忍故障的发生，最小化故障的营销范围。
2. 去中心化原则：
服务之间通过进程隔离，每个服务都有独立的数据库，一个服务实例失效不会导致大规模故障。系统没有一个物理或逻辑的中心控制节点不会因为一个节点的故障导致整个系统不可用。
3. 速度优先原则：
表现：微服务架构的场景下，会存在重复代码、重复开发，这样做的原因是为了减少依赖，是系统更加独立，增加效率。
4. 自动化驱动原则：
在服务划分之前，首先构建自动化的工具即环境，开发人员应该以自动化为驱动力，简化服务在创建、开发、测试、部署、运维上的重复性工作。
5. 不变性原则：
前提：基础设施中的每个服务、组件都可以自动安装、部署，不需要人工干预。每个服务或组件在安装、部署完成后将不会发生改变，如果要更改，则丢弃老的服务或组件并部署一个新的服务或组件。
6. 标准化原则：
通过框架来固化标准，通过工具检测此标准，例如利用SonarQube检测代码重复度，用CheckStyle检测代码风格。
7. 简化设计原则：
对于架构，越是集成的服务越需要稳定，越需要简化设计、简化运维。此原则也是Amazon和Netflix的软件设计原则。
8. 演进式设计原则：
初级阶段应该采用尽可能简单的架构，因为初级阶段对需求、规模等都不十分确定，可以采用快速迭代方式进行架构演进。

2. 云原生架构技术介绍

2.1 云原生逻辑架构

云原生架构特点：
微服务：1.应用间通过Restful API通信; 2.可以被独立部署、更新、Scale和重启
DevOps: 1. 自动化发布管道、CI工具；2. 快速部署到生产环境；3.开发、运维协同合作
持续交付：频繁发布、快速交付、快速反馈、降低发布风险
容器化：微服务的最佳载体

2.2 敏捷基础设施

敏捷基础设施：要求像容器等基础资源，能够支持开发人员、运维人员和业务人员通过代码随时拉取、随时释放，同时以接口的方式提供弹性、按需的计算和存储能力，且是自动化。

注：CNCF并不认为VM是云原生，但显示部署一般是VM与容器并存。
目标：

标准化，无个性化配置，开发环境、测试环境及生产环境无差异。
可替换，任意节点都能够被轻易地创建、销毁、替换。
自动化，所有操作都是通过工具自动完成，无须人工干预。
可视化，当前环境做到可控，就需要对当前的环境状况可视。
可追溯，所有的配置统一作为代码进行版本化管理，所有的操作都可以追溯。
快速，资源申请及解释要求秒级完成，以适应弹性伸缩和故障切换的要求。

2.2.1 OpenStack （VM）

2.2.1.1 虚机vs容器

相同点：提供隔离环境
区别：VM是在硬件的基础上进行虚拟化，隔离性更高，容器在操作系统上进行虚拟化。

资源利用率，容器更轻量级，占用资源更少，比虚拟机的资源利用率高。
创建速度，Docker的启动速度是秒级的，二虚拟机的启动速度是分钟级
性能，虚机要运行客户机操作系统，会出现性能损失，而容器相当于一个进程，性能相当于物理机。
隔离性，虚拟机隔离性更高，容器的隔离级别要低的多。

2.2.1.2 虚机管理平台OpenStack架构

OpenStack是一个社区，也是一个项目和一个开源软件，提供开放源码软件，建立公共和私有云，它提供了一个部署云的操作平台或工具集，其宗旨在于：帮助组织运行为虚拟计算或存储服务的云，为公有云、私有云，也为大云、小云提供可扩展的、灵活的云计算。

2.2.1.3 虚机管理平台OpenStack网络架构

整个OpenStack是由控制节点，计算节点，网络节点，存储节点四大部分组成。（这四个节点也可以安装在一台机器上，单机部署）
其中：
控制节点负责对其余节点的控制，包含虚拟机建立，迁移，网络分配，存储分配等等
计算节点负责虚拟机运行
网络节点负责对外网络与内网络之间的通信
存储节点负责对虚拟机的额外存储管理等等

2.2.1.4 虚机管理平台OpenStack组件关系

Openstack 集成的组件：Nova - 计算服务、Neutron-网络服务、Swift - 对象存储服务、Cinder-块存储服务、Glance - 镜像服务、Keystone - 认证服务、Horizon - UI服务、Ceilometer-监控服务、Heat-集群服务、Trove-数据库服务。

2.2.2 容器管理平台（Container）

2.2.2.1 容器技术介绍

容器(container) 是指是与系统其他部分隔离开的一系列进程，从另一个镜像运行，并由该镜像提供支持进程所需的全部文件。容器提供的镜像包含了应用的所有依赖项，因而在从开发到测试再到生产的整个过程中，它都具有可移植性和一致性。

Docker 其实就是对LXC进行二次封装，具备多个强大功能的工具集，它有着更好、更简易的操作。

• LXC：Linux Container，最早一批真正把容器技术用一组简易模板实现的解决方案。

• LXC主要用到名称空间(name space)与控制组(cgroups)的技术。

• namespace：负责隔离一个独立的容器所必须具备的资源。

• cgroups(Control Groups)：实现对系统资源的分配与度量。

• SELinux是一种基于 域-类型模型（domain-type）的强制访问控制（MAC）安全系统，它由NSA编写并设计成内核模块包含到内核中，相应的某些安全相关的应用也被打了SELinux的补丁，最后还有一个相应的安全策略。
  
  Docker的应用场景：
  1 Web 应用的自动化打包和发布。
  2自动化测试和持续集成、发布。
  3自动化测试和持续集成、发布。
  4从头编译或者扩展现有的OpenShift或Cloud Foundry平台来搭建自己的PaaS环境。
  
  镜像image与容器Container区别：
  镜像是静态的，不会运行
  容器则是动态的，有生命周期
  Docker 使用客户端-服务器 (C/S) 架构模式，使用远程API来管理和创建Docker容器
  Docker 容器通过 Docker 镜像来创建

• DOCKER_HOST：真正运行容器的主机

• Containers：容器，独立运行的一个或一组应用

• Images：镜像，用于创建

• Docker 容器的模板 Registry：镜像仓库

2.2.2.2 容器管理平台介绍

较流行的业界容器管理平台包括：Swarm、Kubernets、Mesos和 AWS 的ECS四个平台。Swarm是最轻量级的，功能也最简单，适于有大量Docker实例环境的用户。Kubernetes增加了很多应用级别的功能，适用于快速应用的部署和维护。Mesos最重，适用于已经有了相当的应用和容器混合的环境。ECS则推荐给AWS的用户或者不希望自己管理数据中心的云用户。

2.2.2.3 容器管理平台 — Swarm

Swarm 是Docker公司在2014年12月初新发布的容器集群管理工具。它可以把多个主机变成一个虚拟的Docker主机来管理。Swarm使用Go语言开发，并且开源，在github上可以找到它的全部source code。Swarm使用标准的Docker API，给Docker用户带来无缝的集群使用体验。2016年7月， Swarm已经被整合进入Docker Engine。

1. Docker Engine集成集群管理
   使用Docker Engine CLI 创建一个Docker Engine的Swarm模式，在集群中部署应用程序服务。
2. 期望状态协调
   Swarm Manager节点不断监视集群状态，并调整当前状态与期望状态之间的差异。
3. 安全传输
   Swarm中的每个节点使用TLS相互验证和加密， 确保安全的其他节点通信。
4. 去中心化设计
   Swarm角色分为Manager和Worker节点， Manager节点故障不影响应用使用。
5. 负载均衡
   实现服务副本负载均衡，提供入口访问。
6. 滚动更新
   升级时，逐步将应用服务更新到节点，如果出现问题，可以将任务回滚到先前版本。
7. 扩容缩容
   可以声明每个服务运行的容器数量，通过添加或删除容器数自动调整期望的状态。
8. 多主机网络
   可以为服务指定overlay网络。当初始化或更新应用程序时， Swarm manager会自动为overlay网络上的容器分配IP地址。
9. 服务发现
   Swarm manager节点为集群中的每个服务分配唯一的DNS记录和负载均衡VIP。可以通过Swarm内置的DNS服务器查询集群中每个运行的容器。

Docker Swarm 提供API 和CLI来在管理运行Docker的集群，它的功能和使用本地的Docker并没有本质的区别。但是可以通过增加Node带来和好的扩展性。理论上，可以通过增加节点（Node）的方式拥有一个无限大的Docker主机。
Swarm的架构: Manager负责容器的调度，Node负责容器的运行，Node运行Docker Daemon和Manager之间通过HTTP来通信。Docker Client通过Manager上暴露的标准Docker API来使用Docker的功能。

Swarm的集群协调和业务发现可以支持不同的第三方组件，包括：
• Consul
• Etcd
• ZooKeeper
• Docker Hub
Swarm的基本容器调度策略有三种：
• spread 容器尽可能分布在不同的节点上
• binpack 容器尽可能分布在同一个节点上
• random 容器分布在随机的节点上

Docker Swarm的特点是 配置和架构都很简单，使用Docker原生的API，可以很好的融合Docker的生态系统。Swarm集群高可用架构图如下所示：manager配置在不同的AWS AZ中，通过领导选举选出Primary manager。多个节点分布在不同的AZ中，同时Consul／etcd／Zookeeper 也需要配成冗余的。

2.2.2.4 容器管理平台 — Kubernetes

Kubernetes 是Google开发的一套开源的容器应用管理系统，用于管理应用的部署，维护和扩张。利用Kubernetes能方便地管理跨机器运行容器化的应用。
Kubernetes 是用Go语言开发的，在GitHub上可以找到源代码。Kubernetes 源于谷歌公司的内部容器管理系统Borg，经过了多年的生产环境的历炼，所以功能非常强大。

为了支持K8S的7大功能，Kubernetes 做了做了很多的 抽象概念 ，包括：Pod、Job、Service、Recplica Controller、Label、Namespace、Config Map。

1. Pod是Kubernetes的基本操作单元，把相关的一个或多个容器构成一个Pod，通常Pod里的容器运行相同的应用，或者是相关的应用。Pod包含的容器运行在同一个Minion(Host)上，看作一个统一管理单元，共享相同的volumes和network namespace/IP和Port空间。
2. Job是一个生命周期比较短的应用，一般只会在出错的情况下重启，可以通过配置Job的并发和运行次数来扩展Job
3. Service是一个生命周期比较长的应用，会在任何退出时重启，可以通过配置Service的复制（Replica）来达到高扩展和高可用。
4. Replication Controller 确保任何时候Kubernetes集群中有指定数量的pod副本(replicas)在运行， 如果少于指定数量的pod副本(replicas)，Replication Controller会启动新的Container，反之会杀死多余的以保证数量不变。Replication Controller使用预先定义的pod模板创建pods，一旦创建成功，pod 模板和创建的pods没有任何关联，可以修改pod 模板而不会对已创建pods有任何影响，也可以直接更新通过Replication Controller创建的pods
5. Label
   对系统中的对象通过Label的方式来管理
6. Namespace
   对对象，资源分组，可以用于支持多租户
7. Config Map
   提供全局的配置数据存储

Kubernetes 提供了很多应用级别的管理能力，包括高可用可高扩展，当然为了支持这些功能，它的架构和概念都比较复杂。

• Master
Master定义了Kubernetes 集群Master/API Server的主要声明，Client(Kubectl)调用Kubernetes API，管理Kubernetes主要构件Pods、Services、Minions、容器的入口。Master由API Server、Scheduler以及Registry等组成。
Scheduler收集和分析当前Kubernetes集群中所有Minion节点的资源(内存、CPU)负载情况，然后依此分发新建的Pod到Kubernetes集群中可用的节点。由于一旦Minion节点的资源被分配给Pod，那这些资源就不能再分配给其他Pod， 除非这些Pod被删除或者退出， 因此，Kubernetes需要分析集群中所有Minion的资源使用情况，保证分发的工作负载不会超出当前该Minion节点的可用资源范围
• Minion
Minion负责运行Pod，Service，Jobs， Minion通过Kubelet和Master通信。Proxy解决了外部网络能够访问跨机器集群中容器提供的应用服务。
• etcd
负责集群的协调和服务发现

2.2.2.4 容器管理平台 — Apache Mesos

Mesos 是为软件定义数据中心而生的操作系统，跨数据中心的资源在这个系统中被统一管理。Mesos的初衷并非管理容器，只是随着容器的发展，Mesos加入了容器的功能。Mesos可以把不同机器的计算资源统一管理，就像同一个操作系统，用于运行分布式应用程序。Mesos的起源于Google的数据中心资源管理系统Borg，包括如下4个功能：

Mesos相比Kubernetes和Swarm更为成熟，但是Mesos主要要解决的是操作系统级别的抽象，并非为了容器专门设计，如果用户出了容器之外，还要集成其它的应用，例如Hadoop，Spark，Kafka等，Mesos更为合适。Mesos是一个更重量级的集群管理平台，功能更丰富，当然很多功能要基于各种Framework。Mesos的扩展性非常好，最大支持50000节点，如果对扩展性要求非常高的话么，Mesos是最佳选择。

• Master
Master负责资源的统一协调和Slave的管理。 Master协调全部的Slave，并确定每个节点的可用资源，聚合计算跨节点的所有可用资源的报告，然后向注册到Master的Framework（作为Master的客户端）发出资源邀约。Mesos实现了两级调度架构，它可以管理多种类型的应用程序。第一级调度是Master的守护进程，管理Mesos集群中所有节点上运行的Slave守护进程。集群由物理服务器或虚拟服务器组成，用于运行应用程序的任务，比如Hadoop和MPI作业。第二级调度由被称作Framework的“组件”组成。
• Slave
Salve运行执行器（Executor）进程来运行任务。
• Framework
Framework包括调度器（Scheduler）和执行器（Executor）进程，其中每个节点上都会运行执行器。Mesos能和不同类型的Framework通信，每种Framework由相应的应用集群管理。
Framework可以根据应用程序的需求，选择接受或拒绝来自master的资源邀约。一旦接受邀约，Master即协调Framework和Slave，调度参与节点上任务，并在容器中执行，以使多种类型的任务
• Zookeeper
Zookeeper负责集群的协调，Master的领导选举等

2.2.2.5 容器管理平台 — AWS ECS

ECS （Amazon EC2 Container Service ）是亚马逊开发出的高度可扩展的高性能容器集群服务。在托管的 Amazon EC2 实例集群上轻松运行容器应用和服务。他最大的好处就是在云上，不需要自己管理数据中心的机器和网络。

2.2.3 Rook（存储）

分布式文件系统（Distributed File System）是指文件系统管理的物理存储资源不一定直接连接在本地节点上，而是通过计算机网络与节点(可简单的理解为一台计算机)相连。
主要解决问题：1 海量数据存储问题；2 数据高可用问题(冗余备份)问题；3 较高的读写性能和负载均衡问题；4 支持多平台多语言问题；5 高并发问题。

2.2.3.1 分布式文件系统对比

2.2.3.2 存储服务对比

在只考虑开源免费的管理工具的前提下，总体上，HDFS 的部署和管理工具比较完善，易于使用。这些工具并非只为HDFS而设计，而是为Hadoop生态系统设计的。OpenStack有一些第三方部署工具，但仍然很复杂。

2.2.3.3 存储服务 — HDFS

HDFS（Hadoop Distributed File System）分布式文件系统，它是谷歌的GFS提出后出现的一种用户级文件系统。提供了一个高度容错和高吞吐量的海量数据存储解决方案。

• 超大文件。目前的hadoop集群能够存储几百TB甚至PB级的数据。
• 流式数据访问。HDFS的访问模式是：一次写入，多次读取，更加关注的是读取整个数据集的整体时间。
• 商用硬件。HDFS集群的设备不需要多么昂贵和特殊，只要是一些日常使用的普通硬件即可，正因为如此，hdfs节点故障的可能性还是很高的，所以必须要有机制来处理这种单点故障，保证数据的可靠。
• 不支持低时间延迟的数据访问。hdfs关心的是高数据吞吐量，不适合那些要求低时间延迟数据访问的应用。
• 单用户写入，不支持任意修改。hdfs的数据以读为主，只支持单个写入者，并且写操作总是以添加的形式在文末追加，不支持在任意位置进行修改。

HDFS集群的节点分为两类：namenode和datanode，以管理节点-工作节点的模式运行，即一个namenode和多个datanode，理解这两类节点对理解HDFS工作机制非常重要。

• namenode作为管理节点，它负责整个文件系统的命名空间，并且维护着文件系统树和整棵树内所有的文件和目录，这些信息以两个文件的形式（命名空间镜像文件和编辑日志文件）永久存储在namenode
  的本地磁盘上。除此之外，同时，namenode也记录每个文件中各个块所在的数据节点信息，但是不永久存储块的位置信息，因为块的信息可以在系统启动时重新构建。

• datanode作为文件系统的工作节点，根据需要存储并检索数据块，定期向namenode发送他们所存储的块的列表。
  
  namenode作为管理节点，它的地位是非同寻常的，一旦namenode宕机，那么所有文件都会丢失，因为namenode是唯一存储了元数据、文件与数据块之间对应关系的节点，所有文件信息都保存在这里，namenode毁坏后无法重建文件。因此，必须高度重视namenode的容错性。
  
  • 第一种机制是备份那些组成文件系统元数据持久状态的文件，比如：将文件系统的信息写入本地磁盘的同时，也写入一个远程挂载的网络文件系统（NFS），这些写操作实时同步并且保证原子性。
  • 第二种机制是运行一个辅助namenode，用以保存命名空间镜像的副本，在namenode发生故障时启用。（也可以使用热备份namenode代替辅助namenode）。

2.2.3.4 存储服务 — GlusterFS

Glusterfs 是一个开源的分布式文件系统,是Scale存储的核心,能够处理千数量级的客户端.在传统的解决 方案中Glusterfs能够灵活的结合物理的,虚拟的和云资源去体现高可用和企业级的性能存储.Glusterfs通过TCP/IP或InfiniBand RDMA网络链接将客户端的存储资块源聚集在一起,使用单一的全局命名空间来管理数据,磁盘和内存资源.Glusterfs基于堆叠的用户空间设计,可以为不同的工作负载提供高优的性能。

为了满足不同应用对高性能、高可用的需求，GlusterFS 支持 7 种卷，即 distribute卷、stripe卷、replica卷、distribute stripe卷、distribute replica 卷、stripe Replica卷、distribute stripe replica 卷。其实不难看出，GlusterFS 卷类型实际上可以分为 3 种基本卷和 4 种复合卷，每种类型的卷都有其自身的特点和适用场景。

1. 基本卷
   
2. 复合卷
   
   

2.2.3.4 存储服务 — OpenStack Swift

Swift 不是文件系统或者实时的数据存储系统，而是对象存储，用于长期存储永久类型的静态数据。这些数据可以检索、调整和必要时进行更新。Swift最适合虚拟机镜像、图片、邮件和存档备份这类数据的存储。
Swift没有采用RAID，也没有中心单元和主控点，而是通过在软件层面采用一致性HASH和数据冗余性，牺牲一定程度的数据一致性达到高可用性和可收缩性。支持多用户模式、容器、和对象存储。最佳应用场景为非结构化数据存储问题。所谓的非结构化数据是相对于结构化数据而言的，节后数据即行数据，存储在数据库中，可以用二维表结构来逻辑实现的数据，而非结构化数据不方便用数据库二维逻辑表来表现，包括所有格式的办公文档、文本、图片、标准通用标记语言下的子集XML、HTML、各类报表、图像和音频/视频。

swift的主要技术特点：
1、极高的数据持久性
2、完全的对称系统架构：对称意味着Swift中的各节点可以完全对等，能极大的降低成本
3、无限的可扩展性：一方面是数据可以无限的扩，另一方面Swift的性能可以线性提升(暂时没有体会到，可以再后续的阅读了解中体会，主要看它的架构设计)
4、无单点故障：Swift的元数据存储时完全均匀随机分布的，并且与对象文件存储一样，元数据也会存储多份。

• 代理服务（Proxy Server）：对外提供对象服务 API，会根据环的信息来查找服务地址并转发用户请求至相应的账户、容器或者对象服务；由于采用无状态的 REST 请求协议，可以进行横向扩展来均衡负载。
• 认证服务（Authentication Server）：验证访问用户的身份信息，并获得一个对象访问令牌（Token），在一定的时间内会一直有效；验证访问令牌的有效性并缓存下来直至过期时间。
• 缓存服务（Cache Server）：缓存的内容包括对象服务令牌，账户和容器的存在信息，但不会缓存对象本身的数据；缓存服务可采用 Memcached 集群，Swift 会使用一致性散列算法来分配缓存地址。
• 账户服务（Account Server）：提供账户元数据和统计信息，并维护所含容器列表的服务，每个账户的信息被存储在一个 SQLite 数据库中。
• 容器服务（Container Server）：提供容器元数据和统计信息，并维护所含对象列表的服务，每个容器的信息也存储在一个 SQLite 数据库中。
• 对象服务（Object Server）：提供对象元数据和内容服务，每个对象的内容会以文件的形式存储在文件系统中，元数据会作为文件属性来存储，建议采用支持扩展属性的 XFS 文件系统。
• 复制服务（Replicator）：会检测本地分区副本和远程副本是否一致，具体是通过对比散列文件和高级水印来完成，发现不一致时会采用推式（Push）更新远程副本，例如对象复制服务会使用远程文件拷贝工具 rsync 来同步；另外一个任务是确保被标记删除的对象从文件系统中移除。
• 更新服务（Updater）：当对象由于高负载的原因而无法立即更新时，任务将会被序列化到在本地文件系统中进行排队，以便服务恢复后进行异步更新；例如成功创建对象后容器服务器没有及时更新对象列表，这个时候容器的更新操作就会进入排队中，更新服务会在系统恢复正常后扫描队列并进行相应的更新处理。
• 审计服务（Auditor）：检查对象，容器和账户的完整性，如果发现比特级的错误，文件将被隔离，并复制其他的副本以覆盖本地损坏的副本；其他类型的错误会被记录到日志中。
• 账户清理服务（Account Reaper）：移除被标记为删除的账户，删除其所包含的所有容器和对象。

OpenStack Swift 支持的操作

2.2.3.5 存储服务 — Ceph

Ceph 是可靠的、可扩展的、统一的、分布式的存储系统。可以同时提供对象存储RADOSGW（Reliable、Autonomic、Distributed、Object Storage Gateway）、块存储RBD（Rados Block Device）、文件系统存储Ceph FS（Ceph Filesystem）3种功能。

应用场景
Ceph可以提供对象存储、块设备存储和文件系统服务，其对象存储可以对接网盘（owncloud）应用业务等；其块设备存储可以对接（IaaS），当前主流的IaaS运平台软件，如：OpenStack、CloudStack、Zstack、Eucalyptus等以及kvm等。

功能组件

OSD（Object Storage Device）：主要功能包括存储数据、处理数据的复制、恢复、回补、平衡数据分布，并将一些相关数据提供给ceph monitor。例如ceph OSD心跳等。一个ceph存储集群，至少需要两个Ceph OSD来实现active+clean健康状态和有效的保存数据的双副本（默认情况下是双副本，可以调整）。注意：每一个disk、分区都可以成为一个OSD。
Monitor：Ceph的监控器，主要功能是维护整个集群健康状态，提供一致性的决策。
MDS（Metadata Server）：主要保存的是Ceph文件系统的元数据。注意：ceph的块存储和ceph对象存储都不需要MDS。MDS为基于POSIX文件系统的用户提供了一些基础命令。
RADOSGW功能特性基于LIBRADOS之上，提供当前流行的RESTful协议的网关，并兼容S3和Swift接口，作为对象存储，可以对接网盘类应用以及HLS流媒体应用等。
RBD(Rados Block Device) 功能特性也是基于LIBRADOS之上，通过LIBRBD创建一个块设备，通过QEMU/KVM附加到VM上，做为传统的块设备来用。目前OpenStack、CloudStack都是采用这种方式为VM提供块设备，同时也支持快照、COW等功能。
Ceph FS功能特性是基于RADOS来实现分布式的文件系统，引如了MDS，主要为兼容POSIX文件系统提供元数据，一般都是当作文件系统来挂载。

架构说明

（1）Monitors（管理服务）：监视器，维护集群状态的多种映射，同时提供认证和日志记录服务，包括有关monitor 节点端到端的信息，其中包括 Ceph 集群ID，监控主机名和IP以及端口。并且存储当前版本信息以及最新更改信息，通过 "ceph mon dump"查看 monitor map。
（2）MDS（Metadata Server）：Ceph 元数据，主要保存的是Ceph文件系统的元数据。注意：ceph的块存储和ceph对象存储都不需要MDS。
（3）OSD：即对象存储守护程序，但是它并非针对对象存储。是物理磁盘驱动器，将数据以对象的形式存储到集群中的每个节点的物理磁盘上。OSD负责存储数据、处理数据复制、恢复、回（Backfilling）、再平衡。完成存储数据的工作绝大多数是由 OSD daemon 进程实现。在构建 Ceph OSD的时候，建议采用SSD 磁盘以及xfs文件系统来格式化分区。此外OSD还对其它OSD进行心跳检测，检测结果汇报给Monitor
（4）RADOS：Reliable Autonomic Distributed Object Store。RADOS是ceph存储集群的基础。在ceph中，所有数据都以对象的形式存储，并且无论什么数据类型，RADOS对象存储都将负责保存这些对象。RADOS层可以确保数据始终保持一致。
（5）librados：librados库，为应用程度提供访问接口。同时也为块存储、对象存储、文件系统提供原生的接口。
（6）RADOSGW：网关接口，提供对象存储服务。它使用librgw和librados来实现允许应用程序与Ceph对象存储建立连接。并且提供S3 和 Swift 兼容的RESTful API接口。
（7）RBD：块设备，它能够自动精简配置并可调整大小，而且将数据分散存储在多个OSD上。
（8）CephFS：Ceph文件系统，与POSIX兼容的文件系统，基于librados封装原生接口

File —— 此处的file就是用户需要存储或者访问的文件。对于一个基于Ceph开发的对象存储应用而言，这个file也就对应于应用中的“对象”，也就是用户直接操作的“对象”。
Ojbect —— 此处的object是RADOS所看到的“对象”。Object与上面提到的file的区别是，object的最大size由RADOS限定（通常为2MB或4MB），以便实现底层存储的组织管理。因此，当上层应用向RADOS存入size很大的file时，需要将file切分成统一大小的一系列object（最后一个的大小可以不同）进行存储。为避免混淆，在本文中将尽量避免使用中文的“对象”这一名词，而直接使用file或object进行说明。
PG（Placement Group）—— 顾名思义，PG的用途是对object的存储进行组织和位置映射。具体而言，一个PG负责组织若干个object（可以为数千个甚至更多），但一个object只能被映射到一个PG中，即，PG和object之间是“一对多”映射关系。同时，一个PG会被映射到n个OSD上，而每个OSD上都会承载大量的PG，即，PG和OSD之间是“多对多”映射关系。在实践当中，n至少为2，如果用于生产环境，则至少为3。一个OSD上的PG则可达到数百个。事实上，PG数量的设置牵扯到数据分布的均匀性问题。关于这一点，下文还将有所展开。
OSD —— 即object storage device，前文已经详细介绍，此处不再展开。唯一需要说明的是，OSD的数量事实上也关系到系统的数据分布均匀性，因此其数量不应太少。在实践当中，至少也应该是数十上百个的量级才有助于Ceph系统的设计发挥其应有的优势。

Ceph正常IO流程

步骤：

1. client 创建cluster handler。
2. client 读取配置文件。
3. client 连接上monitor，获取集群map信息。
4. client 读写io 根据crshmap 算法请求对应的主osd数据节点。
5. 主osd数据节点同时写入另外两个副本节点数据。
6. 等待主节点以及另外两个副本节点写完数据状态。
7. 主节点及副本节点写入状态都成功后，返回给client，io写入完成。

Ceph新主IO流程

如果新加入的OSD1取代了原有的 OSD4成为 Primary OSD, 由于 OSD1 上未创建 PG , 不存在数据，那么 PG 上的 I/O 无法进行

新主IO流程步骤：

1. client连接monitor获取集群map信息。
2. 同时新主osd1由于没有pg数据会主动上报monitor告知让osd2临时接替为主。
3. 临时主osd2会把数据全量同步给新主osd1。
4. client IO读写直接连接临时主osd2进行读写。
5. osd2收到读写io，同时写入另外两副本节点。
6. 等待osd2以及另外两副本写入成功。
7. osd2三份数据都写入成功返回给client, 此时client io读写完毕。
8. 如果osd1数据同步完毕，临时主osd2会交出主角色。
9. osd1成为主节点，osd2变成副本。

2.2.3.6 云原生存储编排管理器ROOK 与Kubernetes的关系

使用 Rook 可以轻松实现在 Kubernetes 上部署并运行 Ceph 存储系统，并且提供 Dashboard 供用户查看存储系统信息，Rook 跟 Kubernetes 集成关系示意图如下：

Rook 提供了卷插件，来扩展了 K8S 的存储系统，使用 Kubelet 代理程序 Pod 可以挂载 Rook 管理的块设备和文件系统。
Rook Operator 负责启动并监控整个底层存储系统，例如 Ceph Pod、Ceph OSD 等，同时它还管理 CRD、对象存储、文件体统。
Rook Agent 代理部署在 K8S 每个节点上以 Pod 容器运行，每个代理 Pod 都配置一个 Flexvolume 驱动，该驱动 主要用来跟 K8S 的卷控制框架集成起来，每个节点上的跟操作相关的操作，例如添加存储设备、挂载、格式化、删除存储等操作，都有该代理来完成。

2.2.3.7 云原生存储编排管理器ROOK

Rook 是专用于 Cloud-Native 环境的文件、块、对象存储服务。它实现了一个自动管理的、自动扩容的、自动修复的分布式存储服务。Rook 支持自动部署、启动、配置、分配、扩容/缩容、升级、迁移、灾难恢复、监控以及资源管理。为了实现所有这些功能，Rook 需要依赖底层的容器编排平台，例如 kubernetes、CoreOS 等。Rook 目前支持 Ceph、NFS、Minio Object Store、Edegefs、Cassandra、CockroachDB 存储的搭建，后期会支持更多存储方案。

Mon: 即Ceph集群中的mon(monitor)组件，负责监控整个Ceph集群的运行状况。会启动quorum中指定个数的mon，一般集群中会有三个mon以保证集群的高可用
Mgr: 即Ceph集群中的mgr(manager)组件，主要负责监控一些非paxos相关的服务(比如pg相关统计信息)，这里的mgr是一个无状态服务，提供集群一些非paxos相关的监控指标。
Osd: 即Ceph集群的osd组件，集群的核心存储组件。
Mds: 即Ceph集群的mds组件，是Ceph分布式文件系统的元数据服务器。一或多个mds 协作管理文件系统的命名空间、协调到共享osd集群的访问。
Rgw: 即Ceph集群的rgw组件，为应用提供RESTful类型的对象存储接口。

2.2.4 OSM/ONAP（NFV & SDN）

2.2.4.1 NFV网络功能虚拟化

NFV即网络功能虚拟化（Network Functions Virtualization），将许多类型的网络设备（如servers，switches和storage等）构建为一个Data Center Network，通过借用IT的虚拟化技术虚拟化形成VM（虚拟机，Virtual Machine），然后将传统的CT业务部署到VM上。一个NFV的标准架构包括NFV infrastructure(NFVI)，MANO(Management and Orchestration)和VNFs，三者是标准架构中顶级的概念实体。

**NFVI（NFV Infrastructure）**包含了虚拟化层（hypervisor或者容器管理系统，如Docker，以及vSwitch）以及物理资源，如COTS服务器、交换机、存储设备等。NFVI是一种通用的虚拟化层，所有虚拟资源应该是在一个统一共享的资源池中，不应该受制或者特殊对待某些运行其上的VNF。
**MANO（Management and Orchestration）**提供了NFV的整体管理和编排，向上接入OSS/BSS
VNF就是虚拟出来的一个个网元，实现某个网络功能单元

2.2.4.2 NFV网络功能虚拟化发展阶段

在初级阶段，NFV将作为实施传统业务的新方法，主要完成将传统基于专用硬件的软件执行环境一对一地转化为基于通用硬件的VM上的专用虚拟化环境。
在高级阶段，NFV将作为实施新业务的新方法，包括将VNF分解为微业务乃至单功能VNF后再重新组合、采用容器技术将单个VM切片成更小容器、应用可软件编程的数据模型实现管理系统集成和自动化管理等过程。

NFVI： 提供VNF的运行环境，包括所需的硬件及软件。硬件包括计算、网络、存储资源；软件主要包括Hypervisor、网络控制器、存储管理器等工具，NFVI将物理资源虚拟化为虚拟资源，供VNF使用。
VNF： 包括VNF和EMS，VNF网络功能，EMS为单元管理系统，对VNF的功能进行配置和管理。一般情况下，EMS和VNF是一一对应的。
VIM： NFVI管理模块，通常运行于对应的基础设施站点中，主要功能包括：资源的发现、虚拟资源的管理分配、故障处理等，为VNF运行提供资源支持。
VNFM： VNF管理模块，主要对VNF的生命周期（实例化、配置、关闭等）进行控制，一般情况下与VNF一一对应。
NFVO： NS生命周期的管理模块，同时负责协调NS、组成NS的VNFs以及承载各VNF的虚拟资源的控制和管理。
OSS/BSS： 服务提供商的管理功能，不属于NFV框架内的功能组件，但NFVO需要提供对OSS/BSS的接口。

2.2.4.3 SDN 软件定义网络

SDN字面意思是软件定义网络，其试图摆脱硬件对网络架构的限制，这样便可以像升级、安装软件一样对网络进行修改，便于更多的APP（应用程序）能够快速部署到网络上。涉及内容包括：网络开放可编程、数控分离（数据平面和控制平面相分离，为开放可编程提供架构基础）、逻辑上集中控制、网络业务的自动化应用程序控制。

数据平面
可以抽象为数据平面或者转发平面，可以是交换机、虚拟交换机、路由器等。数据平面通用抽象模型将不同协议的匹配表整合起来，形成多字段匹配表，解决了网络协议堆砌的问题
南向接口
控制面跟数据转发面之间的接口，传统网络的南向接口存在于各个设备商的私有代码中，对外不可见，如存在于交换机内部
控制器(控制平面)
可以有多个，可以是主从关系，也可以是对等关系，一个控制器控制多台设备，一个设备也可以被多台控制器控制，向上提供应用程序的编程接口，向下控制硬件设备。
北向接口
传统网络里，指交换机控制面跟网管软件之间的接口，在SDN中，指控制器跟应用程序之间的接口
SDN应用服务
为用户提供服务，包括负载均衡、安全、网络运行情况监测等，并以应用软件的形式表现出来，代替传统的网管软件来对网络进行控制和管理，可以跟控制器位于同一台服务器，也可以运行在别的服务器上通过通信协议来跟控制器通信。

2.2.4.4 SDN 软件定义网络的优势

1. SDN加快了新业务引入的速度。网络运营商可以通过可控的软件部署相关的功能，而不必像以前那样等待某个设备提供商在专有设备上添加相应的方案；
2. SDN降低了网络的运营费用。消除了应用和特定网络的细节----比如，端口和IP关联，使得无需花费时间和金钱配置网络设备；
3. SDN有助于实现网络虚拟化。长期以来通过命令行接口进行人工配置，一直在阻碍网络向虚拟化迈进。
4. SDN让网络乃至所有IT系统更好地以业务目标位导向。增加软件模块来增加SDN功能。
5. 简化网络部署。
   

2.2.4.5 SDN 南向协议

狭义的SDN南向协议具有对数据平面编程的能力，可以指导数据平面设备的转发操作等网络行为，关键在于是否具有确切的数据平面可编程能力（如openflow）。
广义的SDN南向协议主要分为三种类型。第一种是仅具有对数据平面配置的南向协议（如OF-Config、OVSDB、NET-CONF）；第二种是应用于广义SDN，具有部分可编程能力的协议（如OpFlex）；第三种是本来就存在，其应用范围很广，不限于应用在SDN控制平面和数据平面之间传输控制信令的协议（如PCEP、XMPP）。

1. Open Flow

Openflow交换机可以分成流表和安全通道两部分。
• 流表用于存放流表项，控制器可以给交换机下发流表项来指导交换机处理匹配流表项的数据包
• 安全通道用于和控制器通信的安全连接
注：在Openflow协议中，交换机是策略的执行者，而网络相关的策略需要控制器下发
OpenFlow通道
控制器和交换机的通信通道，支持以下三类报文：
• Controller-to-Switch：主要由控制器初始化并发送给交换机
• Asynchronous：交换机异步上传给控制器的报文，告知控制器新数据包的到达和交换机状态的改变
• Symmetric：无需等待对方请求，双发都可以任意发送的报文
OpenFlow的缺点
• 无法适应复杂的场景，当出现一种新的协议，需要扩充流表的匹配域，同时重写交换机和控制器两端的协议栈，交换机只能按照固定的协议逻辑去处理数据，不断增多的匹配域，使得OpenFlow的交换机的设计与实现越来越复杂
• 只能在现有支持的转发逻辑上添加对应的流表项来指导数据包的转发，而无法对交换机的转发进行编程和修改，使得数据平面仍然需要掌握协议的语义等控制信息才能完成数据的匹配
• 无状态协议，交换机只能受控制器的指导去执行操作，而无法在满足条件时主动采取动作，过度依赖控制平面
2. OF-Config
OF-Config协议可以看作是Openflow协议的一种补充。主要功能包括进行交换机连接的控制信息，端口和队列资源的配置及端口等资源的状态修改等。

2.2.4.5 SDN 软件定义网络 — 工作模式

网络设备基于流的工作模式
为了保证转发数据的效率，大部分网络设备都是基于流转发的。以全新的FTP为例：
(1) FTP业务的第一个数据表抵达交换机时路由协议或二层选路协议计算出这个数据包的出端口，并将结果存入交换机的TCAM(三元内容可寻址内存，也就是记录着从哪里可以到哪里去)。
(2) 当交换机的数据平面收到数据包时，它将数据包的地址信息(也就是“从哪里来”信息)与TCAM比对，如果能查到一直的表项，交换机根据查询结果(也就是“去哪儿”信息)进行转发。
注意：在整个过程中，交换机控制控制平面只需对每个流的第一个数据包进行路由计算(交换机控制平面做的工作)，并且将结果写入TCAM，后续的判定通过查找TCAM。好处是大大提高了转发效率。

SDN Controller的工作模式

2.2.4.6 NFV与SDN 的区别

NFV和SDN彼此之间没有必然联系。NFV即使脱离SDN，也能实现，在传统的网络架构中，将PNF（Physical Network Function）替换成虚拟化的NF，再辅以传统的NF连接方式，也能实现NFV。而SDN更是可以脱离NFV实现。
但是，NFV和SDN如果相互结合，又可以是互补的存在。借助SDN，不仅传统的NF连接方式都能支持，SDN还能提供更高效的NFV实现方式。毕竟SDN提供的管理层和转发层的分离，使得网络变得极其灵活。反过来，NFV也能够提供SDN的运行环境，帮助SDN的实现。举个例子，某公有云基于SDN提供了IaaS服务，某客户希望在该公有云上搭建自己的Web Server，这个时候，客户可以借助第三方的镜像来部署Firewall和Load Balancer实例。在这个场景下，第三方提供的镜像作为NFV的一部分，完善了SDN的功能。

1. NFV不依赖与SDN，但是SDN中控制和数据转发的分离可以改善NFV网络性能。
2. SDN也可以通过使用通用硬件作为SDN的控制器和服务交换机以虚拟化形式实现。
3. 结论：以移动网络，NFV是网络演进的主要架构。在一些特定场景，将引入SDN
   

2.2.4.7 NFV/SDN 网络协同与编排器 — ONAP

ONAP：Open Network Automation Platform
ONAP通过为物理和虚拟网络设备提供全局的和大规模（多站点和多VIM）的编排功能来解决这些问题。它通过提供一套通用的、开放的、可互操作的北向REST接口，以及支持YANG和TOSCA数据模型来提高业务敏捷性。

1. 设计态环境用于往ONAP上线业务和资源，并基于它们设计新业务。
2. 对外API组件为ONAP平台的北向接口提供了互操作性，同时Multi-VIM/CLOUD模块支持ONAP系统负荷在云间的互操作。
3. OOM提供了Kubernetes托管云环境下云原生安装和部署的能力
4. ONAP Shared Services为ONAP模块提供共享能力。MUSIC允许ONAP扩展到多站点环境，以支持全局规模的基础架构需求。OOF提供一种声明性的、策略驱动的方法用于创建和优化应用，如归属/位置、变更管理调度优化等。Logging提供集中的日志管理能力，Audit(pomba)提供了解析编排动作的能力。
5. ONAP shared utilities为ONAP组件支持提供了实用工具。
6. 信息模型和框架实用程序持续演进，以协同众多标准化组织的拓扑、工作流和策略模型，包括ETSI NFV MANO、TM Forum SID、ONF Core、OASIS TOSCA、IETF和MEF等。

一个网络服务的生命周期从模型的定义开始，到分发，部署，监控，自愈／扩缩的一整套闭环都可以纳入ONAP平台的掌控之中。


1、运营人员在SDC完成VNF的载入等管理，并完成NS的编排设计、测试等工作，最后通过上线流程将NS推送到RUN-TIME的SO模块，整个设计过程是基于TOSCA/YANG模型完成的。
2、SO模块主要负责NS的管理，并解析来自SDC的模型文件，对于网络部分，则交给SDN-C进行编排，对于VNF和应用，则交给VF-C和APPC管理。VF-C主要负责VNF的全生命周期的管理。
3、SO还会将设计模型注入到A&AI之中，并且根据之后资源使用的动态情况，实时调整A&AI的资源使用情况。
4、最后，DCAE主要负责采集底层资源、应用、VNF、网络等状态数据，并提供大数据分析和闭环操作的能力。

2.2.4.8 NFV全功能编排器 — ETSI OSM

OSM（Open Source MANO）成立于两年前，基于Telefónica的OpenMANO项目，并得到了ADVA，Bell Mobility，BT，CableLabs，Intel，Mavenir，Red Hat，Sprint，Telenor和Verizon的支持。其目标是开发“NFV的全功能编排器，并以开源方式实施，并与ETSI NFV框架保持一致”。

OSM与VIM通信：连接OSM与VIM的VNFs和VLs的部署
OSM与部署在VIM中的VNFs通信运行第0天、第1天和第2天的配置原。

为保证OSM正常工作，假设:
每个VIM都有一个可以从OSM访问的API端点
每个VIM都有一个所谓的管理网络，它为VNFs提供IP地址
可以从OSM访问该管理网络

OSM的方法旨在通过四个关键方面最小化集成工作:

• 信息模型(IM)，与ETSI NFV一致，能够建模和自动化网络功能(虚拟的、物理的或混合的)、网络服务(NS)和网络片(NSI)的整个生命周期，从它们的初始部署(实例化、第0天和第1天)到它们的日常操作和监视(第2天)。
• OSM提供了一个基于NFV SOL005的统一北行接口(NBI)，它支持在其控制下的系统、网络服务和网络片的完整操作。事实上,OSM的NBI提供服务管理网络服务的生命周期(NS)和网络(NSI)切片实例,作为服务提供所有必要的抽象允许完全控制,操作和监督NS / NSI由客户机系统生命周期,避免不必要的细节的曝光其组成元素。
• 扩展OSM的“网络服务”的概念,这一个NS可以跨不同的领域确定虚拟,物理和运输,因此控制NS的完整生命周期与VNFs互动,PNFs和hnf难区别的方式以及不同站点之间传输连接的需求。
• 此外，OSM还可以管理网络片的生命周期，如果需要的话，还可以充当片管理器的角色，扩展它以支持集成操作。
  
• OSM作为网络服务协调器(NSO),管理功能网络服务平台，旨在提供创建网络服务的功能需求和返回一个服务对象ID之后,可以使用作为一个处理程序来控制整个网络的生命周期和操作服务通过后续调用OSM的北行的API和监控其全局状态。
• OSM的情况,有两种类型的NaaS OSM能够提供的服务对象需求支持NaaS功能:网络服务(NS)和网络(NSI)切片实例,后者几个网络服务的组合,可视为一个单一的实体。
• OSM作为服务平台的管理功能，使用其他服务平台的服务，并控制多个托管功能，以创建自己的复合高级服务对象。因此,OSM消耗平台所提供的服务(s)的虚拟基础设施(获取虚拟机等)和负责SW-Defined网络平台(s)(获得所有必需的各种inter-DC连接),而且,一旦组装、配置和显示器组成的网络功能(VNFs, PNFs hnf)为了控制整个NS的LCM / NSI提供需求。