Longhorn项目现已正式发布！这是一个基于云和容器部署的分布式块存储新方式。Longhorn遵循微服务的原则，利用容器将小型独立组件构建为分布式块存储，并使用容器编排来协调这些组件，形成弹性分布式系统。
Why Longhorn?
如今，基于云和容器的部署规模日益扩大，分布式块存储系统也正变得越来越复杂，单个存储控制器上的volume数量在不断增加。2000年代初，存储控制器上的volume数量只有几十个，但现代云环境却需要数万到数百万的分布式块存储卷。存储控制器变成了高度复杂的分布式系统。
分布式块存储本身比其他形式的分布式存储（如文件系统）更简单。无论系统中有多少volume，每个volume只能由单个主机进行装载。正因如此，我们设想，是否可以将大型块存储控制器分割成多个较小的存储控制器？若想要如此分割，我们需要保证这些volume仍然是从公共磁盘池构建的，并且我们需要有办法来编排这些存储控制器，让它们可以协同工作。
为了将这一想法发挥到极限，我们创建了Longhorn项目。这是一个我们认为值得探索的方向，每个控制器上只有一个volume，这将大大简化存储控制器的设计。因为控制器软件的故障域仅限于单个volume，所以控制器若崩溃，也只会影响一个volume。
Longhorn充分利用了近年来关于如何编排大量的容器和虚拟机的核心技术。例如，Longhorn并没有构建一个可以扩展到100,000个volume的高度复杂的控制器，而是出于让存储控制器简单轻便的考虑，创建了100,000个单独的控制器。然后，我们可以利用像Swarm、Mesos和Kubernetes这样的最先进的编排系统来调度这些独立的控制器，共享一组磁盘中的资源，协同工作，形成一个弹性的分布式块存储系统。
Longhorn基于微服务的设计还有很多其他优势。因为每个volume都有自己的控制器，在升级每个volume的控制器和replica容器时，是不会导致IO操作明显的中断的。 Longhorn可以创建一个长期运行的工作来编排所有live volume的升级，同时确保不会中断系统正在进行的操作。为确保升级不会导致意外的问题，Longhorn可以选择升级一小部分volume，并在升级过程中出现问题时回滚到旧版本。这些做法在现代微服务应用中已得到广泛应用，但在存储系统中并不常见。我们希望Longhorn可以助力于微服务在存储领域的更多应用。
Longhorn功能概述
将本地磁盘或安装在计算或专用存储主机中的网络存储形成共享资源池。
为容器和虚拟机创建块存储卷。你可以指定volume的大小，IOPS的需求，以及你想要的跨主机的同步replica的数量（这里的主机是指那些为volume提供存储资源的主机）。replica是在底层磁盘或网络存储上精简配置的。
为每个volume创建一个专用的存储控制器。这可能是与大多数现有的分布式存储系统相比，Longhorn最具特色的功能。大多数现有的分布式存储系统通常采用复杂的控制器软件来服务于从数百到数百万不等的volume。但Longhorn不同，每个控制器上只有一个volume，Longhorn将每个volume都转变成了微服务。
跨计算或存储主机调度多个replica。Longhorn会监测每一个replica的健康状况，对问题进行维修，并在必要时重新生成replica。
以Docker容器的形式操作存储控制器和replica。例如，一个volume有三个replica，就意味着有四个容器。
为每个volume分配多个存储“前端”。常见的前端包括Linux内核设备（映射到/ dev / longhorn）和iSCSI目标。Linux内核设备适用于支持Docker volume，而iSCSI目标更适合支持QEMU / KVM和VMware volume。
创建volume快照（snapshot）和AWS EBS风格的备份。您可以为每个volume创建多达254个快照，这些快照可以逐个备份到NFS或S3兼容的辅助存储中。只有更改的字节会在备份操作期间被复制和存储。
指定定期快照和备份操作的计划。您可以指定这些操作的频率（每小时，每天，每周，每月和每年）、执行这些操作的确切时间（例如，每个星期日凌晨3:00），以及保留多少个循环快照和备份集。
快速入门指南
Longhorn易于安装和使用。您只需确保Docker已安装，并且安装了open-iscsi软件包，就可以在单个Ubuntu 16.04服务器上设置运行Longhorn所需的一切。
运行以下命令在单个主机上设置Longhorn：
git clone https://github.com/rancher/longhorncd longhorn/deploy ./longhorn-setup-single-node-env.sh
该脚本将拉起并启动多个容器，包括etcd键值存储区、Longhorn volume管理器、Longhorn UI和Longhorn docker volume插件容器。此脚本完成后，将生成以下输出：
Longhorn is up at port 8080
您可以通过连接到http：//
您现在可以从Docker CLI创建持久的Longhorn volume：
docker volume create -d longhorn vol1 docker run -it --volume-driver longhorn -v vol1:/vol1 ubuntu bash
在同一主机上运行单主机Longhorn安装程序etcd和所有volume副本，因此不适合在生产环境中使用。 Longhorn GitHub页面有更多关于如何设置生产级别多主机使用说明，多主机将使用单独的etcd服务器、Docker swarm mode集群和用于存储备份的单独NFS服务器。
Longhorn和其他存储系统
作为一项实验，我们编写了Longhorn，借助容器和微服务，Longhorn构建了一个分布式块存储系统，Longhorn既不是为了与现有存储软件和存储系统竞争，也并非为替代现有存储软件和存储系统，原因如下：
Longhorn只关注分布式块存储。从另一个角度来说，分布式文件存储更难建立。如Ceph、Gluster、Infinit（由Docker收购）、Quobyte、Portworx和StorageOS以及来自NetApp、EMC等的存储系统，提供了分布式文件系统、统一存储体验、企业数据管理以及许多Longhorn不支持的其他企业级功能。
Longhorn需要NFS共享或S3兼容的对象用以存储volume备份。因此，它必须与来自NetApp、EMC Isilon或其他供应商的网络文件存储器以及来自AWS S3、Minio、SwiftStack、Cloudian等的S3兼容的对象存储端点配合使用。
Longhorn缺少企业级存储功能，例如重复数据删除、压缩和自动分层以及将大容量条带化为较小块的能力。因此，Longhorn volumes受到单个磁盘的大小和性能的限制。 iSCSI目标以用户级进程运行。我们在分布式存储产品（如Dell EqualLogic，SolidFire和Datera）中可以看到，它缺乏企业级 iscsi 系统的性能、可靠性和多路径支持。
我们建立了Longhorn，使其简单易行，希望它可以测试我们的想法——使用容器和微服务来构建存储。它完全由Go（通常称为golang）编写，是现代系统编程的首选语言。
下面我们将继续详细描述Longhorn，让大家能对Longhorn现阶段的功能设计有个大致的预览。当前，尽管所描述的功能还未全部实现，但我们将会继续努力，使Longhorn项目的愿景变为现实。
作为微服务的volume
Longhorn volume管理器容器在Longhorn集群中的每个主机上运行。使用Rancher或Swarm术语，Longhorn管理器容器是一项全球性服务。如果您使用Kubernetes，Longhorn volume管理器则被视为DaemonSet。Longhorn volume管理器处理从UI中或Docker和Kubernetes的卷插件中执行API调用。您可以在这里找到Longhorn API的说明。下图展示了Longhorn在Docker Swarm和Kubernetes中的控制路径。
当Longhorn管理器被要求创建一个volume时，它将在该volume所附的主机以及放置副本的主机上创建一个控制器容器。副本应放置在不同的主机上，以确保最大可用性。
在下图中，有三个容器有Longhorn volumes。每个Docker volume都有一个作为容器运行的专用控制器。每个控制器有两个副本，每个副本都是一个容器。图中的箭头表示Docker volume、控制器容器、副本容器和磁盘之间的读/写数据流。通过为每个volume创建单独的控制器，如果某个控制器发生故障，也不会影响其他volums的功能。
例如，在大规模部署100,000个Docker volumes的过程中，每个volume具有两个副本，意味着将存在100,000个控制器容器和20万个复制容器。为了安排、监视、协调和修复所有这些控制器和副本，需要一个存储编排系统。
存储编排
存储编排负责调度控制器和副本，监视各种组件，并从错误中恢复。Longhorn volume管理器执行管理volume生命周期所需的所有存储编排操作。您可以在这里找到Longhorn volume管理器执行存储编排的详细信息。
控制器的功能类似于典型的镜像RAID控制器，对其副本进行读写操作并监控副本的健康状况。所有写入操作都被同步复制。因为每个volume都有自己的专用控制器，并且控制器驻留在volume所附加的同一主机上，所以我们不需要控制器的高可用性（HA）配置。
Longhorn volume管理器负责挑选副本所在的主机。然后检查所有副本的健康状况，在必要时，执行相应操作重建错误的副本。
复制操作
Longhorn replicas是通过Linux分散的文件构建的，它支持精简配置。目前，我们不保留额外的元数据来指示使用哪些block。block大小为4K。
拍摄快照时，您将创建一个差异磁盘。随着快照数量的增长，差异磁盘链可能会相当长。为了提高读取性能，Longhorn保留了一个读取索引，记录了该差异磁盘保存的每个4K block的有效数据。在下图中，该volume有八个block。读取索引有八个条目，并且在读取操作发生时被惰性填充。写操作会重置读取索引，使其指向实时数据。
读取保存在内存中的索引时，每4K block消耗一个字节。字节大小的读取索引意味着您可以为每个volume获取多达254个快照。
为每个副本读取索引将会消耗一定量的内存数据结构。例如，1TB卷消耗256MB的内存读取索引。因此，我们未来会考虑将读取的索引放在内存映射文件中。
副本重建
当控制器检测到某个副本出现故障时，它会将副本标记为处于错误状态。Longhorn volume管理器负责启动和协调重建错误副本，过程如下所示：
Longhorn volume管理器创建一个空白副本，并调用控制器将空白副本添加到其副本集中。
要添加空白副本，控制器须执行以下操作：
暂停所有读写操作
在WO（只写）模式下添加空白副本
获取所有现有副本的快照，即刻会有一个空白的差异磁盘
Unpauses全部读取写入操作，仅将写入操作发送到新添加的副本
启动后台进程，将所有（除最新的以外）差异磁盘从好的副本同步到空白副本
同步完成后，所有副本的数据都具有一致性，volume管理器将新副本设置为RW（读写）模式
Longhorn volume管理器调用控制器从其副本集中删除错误的副本。
重新构建副本并不是很有效。我们可以通过尝试重新使用故障副本中剩余的分散文件来提高重建性能。
备份快照
我喜欢Amazon EBS的工作方式——每个快照都自动备份到S3。主存储中没有任何内容。但是，我们决定让Longhorn的快照和备份更灵活一些。将快照和备份操作分开执行。通过拍摄快照、备份此快照与上一个快照之间的差异以及删除上一个快照来模拟EBS风格的快照。我们还开发了一种定期的备份机制，以帮助您自动执行此类操作。
通过检测和传输快照之间的被更改的block, 我们实现了高效的增量备份。这个任务相对来说比较容易, 因为每个快照都是一个差异文件, 只用存储最后一个快照中的更改。为了避免存储大量的小block，我们使用2MB block执行备份操作。这意味着，如果2MB边界中的任何4K block改变，我们将不得不备份整个2MB block。但我们认为这在可管理性和效率之间提供了平衡。
在下图中，我们已经备份了snap2和snap3。每个备份保留自己的一组2MB block，两个备份共享一个绿色block和一个蓝色block。每个2MB block仅备份一次。这意味着当我们从二级存储中删除备份时，不能删除它所使用的所有block。相反，我们会定期执行垃圾回收，以便从二级存储中清理未使用的block。
Longhorn将给定的volume的所有备份存储在公用目录下。以下是描述Longhorn如何存储volume的备份的简单视图。volume级元数据存储在volume.cfg中。每个备份的元数据文件（例如snap2.cfg）相对较小，因为它们只包含备份中所有2MB block的偏移量和校验和。属于同一volume的所有备份的2MB block都存储在公用目录下，因此可以跨多个备份进行共享。2MB block（.blk文件）被压缩。由于使用了校验和来处理2MB block，所以我们删除了同一volume的2MB block中一定程度的重复数据。
两种部署模式
Longhorn volume管理器执行调度副本到节点的任务。我们可以调整调度算法，以不同的方式放置控制器、复制副本。控制器要始终放置在连接volume的主机上。另一方面，副本可以在运行控制器的同一组计算服务器上或在一组专用存储服务器上进行。前者构成了超聚合部署模型, 后者则构成专用存储服务器模型。
坚信开源才是技术的未来，始终秉承开源理念的Rancher Labs，此次推出的Longhorn依然是100％的开源软件。您可以通过在GitHub上下载Longhorn。