主节点含有一个可用软件版本的目录。从节点从主节点处得到要安装的软件信息并向用户提供软件。然后，用户请求服务（称为托管订阅 ），这些服务是所提供软件的实例。实例在某个节点上可用的计算机分区内实例化。从节点将所有正在运行的实例的使用情况报告给主节点，主节点追踪节点容量和可用软件。

主节点还是门户网站，提供网站服务，以便用户或其他软件请求在节点上运行并实例化的新软件实例。COMP-0为主节点提供服务，因此COMP-0具有某种特殊的状态，与向用户提供服务的COMP-1,2,3的标准节点不同。

主节点是有状态的。从节点是无状态的。更准确地说，重建从节点所需的所有信息都存储在主节点中，例如包括备份服务的URL，维护数据的在线副本。即使在节点故障的情况下，也可以用相同的数据重建替换节点。

因此，确保主设备上的状态数据得到很好的保护非常重要。这可以通过在有冗余资源的可信任第三方IAAS基础设施上托管主节点来实现。更好的方法则是：基于适当数据冗余启发式算法，在世界不同区域的众多从节点上托管多个主节点。

这就是SlapOS的第一个反身性质 ：SlapOS Master其实就是SlapOS Master软件的运行实例（！）在一组从节点上得到实例化，这些节点共同构成一个可信赖的托管架构。换句话说，SlapOS托管SlapOS或SlapOS是自托管的。

主节点查验（a）所有云资源请求者的身份；（b）监控云资源服务并（c）对云资源使用进行计费。涉及了最终用户以及云资源供应商和/或消费者。

主节点管理所有节点上的计算机分区。这些“容器”每个运行单个软件实例。每个软件实例可以完全自主地或通过用户交互来请求。

SlapOS为每种类型的身份生成X509证书：登录的用户、为SlapOS贡献资源的每个服务器以及请求/通知主节点的每个正在运行的软件实例。具有单个从属节点，一个用户和十个计算机分区的SlapOS主节点因此将生成12个X509证书：从属节点一个，用户一个，节点上的计算机分区10个。

具有有效X509证书的任何用户，软件或从节点都可以从SlapOS Master请求资源，其作用类似于后台或市场。 请求会被记录，就像资源交易合同：资源消费者在特定条件下请求资源。资源可以是NoSQL存储，KVM虚拟机，ERP系统或其他类似资源。条件包括价格、地区（例如中国）或特定的硬件设置（例如64位CPU）。这些条件有时在其他架构中称为服务级别协议（SLA），但在SlapOS中，它们被视为交易规范而非硬性保证。

默认情况下，SlapOS Master是一个自动市场。通过查找满足所有特定条件的节点来处理请求。因此，SlapOS Master需要知道：在给定时间，可以以什么价格，在哪些特定要求下，可以使用哪些资源，包括哪些软件，在什么条件下可以安装在节点上。但是，也可以手动定义特定节点，而不依赖SlapOS Master的自动市场逻辑，即在分配资源时由SlapOS确定要使用的计算机。

与主节点相比，SlapOS从节点更简单。从节点只需要运行主节点要求的软件。也就是说，软件是安装在从节点上。为了节省磁盘空间，从节点只安装他们实际需要的软件。

从节点被分为一定数量的计算机分区（Slappart [0-x]）。计算机分区可以看作是轻量级的安全容器，但它是基于Unix用户和目录而不是虚拟化。典型的准系统PC可以轻松提供100个计算机分区，因此可以运行100个Wordpress博客或100个电子商务网站，每个网站都有自己的独立数据库。一个较大的服务器可以包含200-500个计算机分区。

SlapOS中的计算机分区概念与依赖磁盘映像和虚拟化的其他方法相比大幅降低成本，同时在计算机分区内还允许运行虚拟化软件。这使得SlapOS在具有成本效益的同时还与传统软件兼容。

其实，SlapOS Master就是安装了SlapOS“内核”的常规节点。在初始安装SlapOS Master期间，使用SlapProxy（“mini”-Master）设置将投入使用的SlapOS Master。通过与SlapProxy的关系可以看出，SlapOS Master其实是一个普通节点，其上安装并实例化了两个软件：ERP5“云引擎”和用于访问ERP5的Frontend（Caddy）。这就是SlapOS的第二个反身特性 ：SlapOS用于部署SlapOS。

SlapOS Master的实现源于ERP5在八个非洲国家中央银行的实现。基本思想是：考虑到货币清算和云资源清算类似，因此可以使用相同的软件实现。除此之外，ERP5还展示了对大型CRM应用程序的可扩展性以及可靠的会计功能。由于NEO ，ERP5分布式NoSQL数据库得以运用，有状态市场所需的事务特性和可扩展性才可以在ERP5中得到实现。

在ERP5之上开发SlapOS Master也是ERP5的通用商业模式（UBM）的直接应用，该模型统一了所有管理科学，并被许多IEEE发表文章承认为企业应用程序设计的重大转变。在UBM中，每个计算机由(item)项表示；而分配请求，资源交付和资源计费由(mouvement)运动表示。运动资源可以是软件托管，CPU使用，磁盘使用，网络使用，RAM使用，登录等。软件托管运动在计算机分区中运行的软件启动时开始，并且在运行的软件停止时停止。资源使用运动在每个软件托管运动期间开始和停止计费，与运行软件的状态无关。在计算机分区上运行的软件版本是UBM中的项 ，就像订阅合同标识符一样。各方（客户，供应商）表示为节点(node) 。此外，每个网络也被视为一个节点 ，就像仓库在物流中代表一个节点一样 。

SlapOS从节点软件由POSIX操作系统，SlapGRID， Supervisord(管理进程程序)和Buildout（任务构建工具）组成 ，可在支持GNU的GlibC和Supervisord的任何OS操作系统上运行（例如：GNU / Linux，FreeBSD，MacOS / X，Solaris，AIX等）。在撰写本文时，Microsoft Windows通过Windows上的GlibC实现和Supervisord与Windows之间的一个端口得到部分支持（仅限节点）。

SlapGRID

SlapGRID就像SlapOS Master与Buildout和Supervisord之间的“粘合剂”。SlapGRID询问SlapOS Master应安装和执行哪个软件。Buildout安装软件，Supervisord启动和停止软件进程。SlapGRID还收集每个正在运行的软件的使用数据，并将其传输给SlapOS Master。

Supervisord (进程管理)

Supervisord是一个进程管理守护程序。它可以用程序启动和停止不同用户的进程，处理输出，日志文件，错误等。它是一种改进的init.d ，可以被远程控制。Supervisord是轻量级的，并且已经十分成熟（没有内存泄漏问题）。

Buildout(软件构建工具)

Buildout(软件构建工具)系统基于Python，用于创建，组装和部署多方应用程序，其中一些部分可能并不是Python系统。它还允许创建Buildout配置，以便日后需要时可用于生成相同的软件。Buildout源自Zope / Plone社区，用于自动部署其软件的自定义实例。多年来已成为一款稳定而成熟的软件。有关Buildout的详细分析及其对SlapOS架构至关重要的原因，请参阅understanding Buildout 。

SlapOS基于SLAP协议，是每个SlapOS从节点用于通过http联系主服务器的轮询协议。联系主服务器的四个不同目的：

• 定义容量；
• 收集要安装的软件列表；
• 收集要配置的计算机分区列表；
• 发布会计/使用信息。

在启动时，节点会联系安装期间指定的Master，并通知Master启动过程已完成。它还提供一个可用计算机分区列表，以及相应的标识符和IPv6地址。set capacity request(设置容量请求)每24小时重新发送一次，以防网络配置更改，虽然这种情况不太可能发生。

每隔5分钟，节点就会请求应该安装的软件列表。由于SlapOS节点和SLAP协议是无状态的，因此交换的值是Promise ，而不是该进行的操作（请参阅了解SlapOS Promises ）。因此，SlapOS Master返回预期要安装在节点上的完整软件列表，而不考虑是否已经安装了此类软件。但是，如果已安装的软件不再在列表中，则表示应将其删除。

每隔5分钟，SlapOS从节点还会请求要配置的计算机分区列表。这两个请求由不同的进程处理，因为安装软件可能需要几分钟（预编译和已缓存）到几个小时（重新编译架构），而配置只需几秒或更短时间。每一次请求计算机分区列表最终将导致重新配置所有分区。如果较大的服务器包含300个分区，每个分区的配置需要一秒钟，则重新配置所有分区就需五分钟。SlapGRID尝试优化分区配置，只更新自上次运行以来已更改的那些分区。但是，如果不得已要对服务器上所有分区进行配置，则配置将在单个线程和进程上运行，以确保系统不会崩溃，并且服务器的大多数核心都仍可独立运行，而不会进行软件配置。

计算机分区上的会计/使用信息每天会收集一次。在计算机分区中运行的软件实例生成TioXML格式的使用和事件报告文件。所有文件都汇总并发布到SlapOS Master，然后生成会计和计费信息。交换的会计信息是非常抽象的，包括物理使用（CPU，RAM，磁盘等），虚拟使用（用户数量，交易处理服务数量) 和事件（X秒内无法访问数据) 。TioXML格式易于扩展，以涵盖任何可能的计费要求。

在撰写此文时，正在考虑使用HTTP长轮询或Web Socket扩展get-cp-list请求，以使系统更具反应性，减少轮询SlapOS Master的频率。尽管如此，Slap协议可能永远不会包括提供即时云资源。 这应该是基于预测或安全的预分配来完成，而不是按需分配。顺着这个思路，减慢资源供应可能有助于降低可用云资源不确定性的风险，从而提高整体云系统韧性。除此之外，还需要了解是否可以通过基于HTTP的推送协议实现更高的可扩展性，以及这种协议是否能够抵御洲际互联网传输路径上的频繁网络中断。

每个计算机分区由专用IPv6地址 ，专用本地（内部） IPv4地址 ，专用Tap接口（ slaptapN ），专用用户（ slapuserN ）和专用目录（ /srv/slapgrid/slappartN ）组成。此外，也可使用专用块设备和可路由的IPv4地址。

SlapOS通常配置为使用IPv6地址。虽然没有要求，但IPv6极大地简化了公共云和私有云应用程序的SlapOS部署。在私有设置中，无需设置端口复杂的重定向隧道，IPv6便可互连SlapOS从节点。在公共云情况下，IPv6使用更具弹性的协议和更宽的扁平地址空间替换现有的公司隧道（VPN）。IPv6寻址可以帮助在一台计算机上分配数百个IPv6地址。因此，每个正在运行的服务都可以拥有不同的IPv6地址，而无需更改其默认端口设置，并简化了每个计算机分区的网络流量计算。

所有这些都可以通过IPv4或通过VPN实现，但是IPv4地址已枯竭。除此之外，它也更复杂，弹性也更低，因此不可能在一台计算机上分配众多公共IPv4地址。

尽管IPv6用于在SlapOS公共云或私有云上的全局互连进程，但在编写本文时，大多数现有软件与IPv6尚不兼容。原因各不相同：或是因为IP地址存储在3个整数的结构中；或是由于IPv6 URL不使用间隔号，因而无法被识别。由于这些原因，每个计算机分区都有一个专用的本地，不可路由的IPv4地址。

传统软件将使用代理机制监听此IPv4地址，该代理机制在IPv6和IPv4之间创建桥接。在HTTP（s）应用程序的情况中，通常使用Frontend（Caddy）来执行此任务，Frontend同时也用作应用防火墙（mod_security）和安全设置器（TLS）。对于其他协议，使用Stunnel(加密连接)可达到相同目的（详细信息，请参阅以下内容）。

对于另一种类型的应用程序，IP不是合适的ISO级别。 在这些情况下，可以使用模拟物理以太网接口的Tap接口。此接口通常与其中一个服务器的物理以太网接口桥接。虚拟化软件（如KVM）经常用Tap来访问外部网络（例如SlapOS提供的KVM）。但是Tap也可以用于其他应用程序，例如虚拟专用网络或需要直接以太网接入的虚拟交换机。在有100个分区的计算机上，Tap接口通常名slaptap0,slaptap1,...slaptap99 。

...

每个计算机分区都与一个用户和一个目录相连。在有100个分区的计算机中，用户名为slapuser0, slapuser1...slapuser99；目录名为/srv/slapgrid/slappart0,/srv/slapgrid/slappart1,.../srv/slapgrid/slappart99

目录/srv/slapgrid/slappart0属于用户（或组） slapuser0 ，依此类推。 slapuser0能够访问/srv/slapgrid/slappart0的文件，而slapuser1无法访问这个文件，因为他只能访问存储在/srv/slapgrid/slappart1 的文件。同样的，Tap接口slaptap0属于slapUser0，Tap接口slaptap1属于slapuser1 ，依此类推。

对于某些应用程序，可能需要将某些分区附加到原始块设备，以便在某些KVM配置下能最大化磁盘I / 0性能，并能直接访问SSH磁盘的物理分区。这种可能性已被包含在SlapOS的设计中，尽管在撰写本文时尚未完全实现。

因此，计算机分区被配置为不能访问另一计算机分区上的任何信息。SlapOS中的访问权限有三个不同的级别： 全局访问，仅限计算机分区访问和仅限超级用户访问。SlapOS从节点通常是全局硬件状态，具有全局访问权限，因此无需进一步用户化即可安装监视软件。

在计算机分区上运行的每个软件都可以访问由同一用户拥有的计算机分区的所有文件。在计算机分区中运行的软件不可能访问或修改超级用户拥有的文件。根据一般设计规则，SlapOS不会向应用程序或计算机分区授予任何超级用户权限。只有SlapGRID和Supervisord可以以超级用户权限执行。

单个计算机分区应该托管单个应用程序，例如数据库，应用程序服务器或测试运行器。为此可能需要多个UNIX进程。对于Zope Web应用程序服务器，至少需要两个进程：为了安全性的Frontend（Caddy）（防火墙，mod_security，mod_ssl）和Zope服务器本身的进程。对于数据库，一个进程是数据库本身，另一个是Stunnel应用程序，它将IPv6端口映射到本地IPv4端口。

但是进程的数量可能会更多。运行ERP5至少需要12个进程：backend_apache，certificate_authority，conversion_server，crond，erp5_update，kumo_gateway，kumo_manager，kumo_server，memcached，mysql_update，mysqld，zope_1。在这种情况下，计算机分区就是ERP5及其依赖项的“万能”容器。对于包括Apache / PHP / MySQL应用程序在内的任何收缩包装应用程序，都会遵循类似的方法。这种情况是正常的，因为“基本”的概念仍然是仅启动应用程序的一个实例，虽然大多数时间不需要如此操作。因此，可以在单个计算机上分配多个计算机分区，而无需扩展应用程序。

某些用户使用单个分区来运行同一应用程序服务器的多个实例。在这种情况下，计算机分区不再是基本需求，反而成为消耗计算机所有资源的小型集群，阻止了可扩展性，也影响了通过细粒度资源分配来优化SlapOS的资源使用。

建议使用IPv6来创建具有单个平面寻址空间的全局，分布式，对等，未加密的互通进程网络。在理想的SlapOS实现中，在Slave节点的计算机分区上分配的所有软件实例可以通过IPv6连接相互通信。此外，一些用户（如：笔记本电脑）直接使用IPv6访问SlapOS进程（例如开发人员不通过前端）。但是，大多数用户将通过IPv4和应用程序前端访问SlapOS应用程序进程，因为这些前端被分配在具有双IPv4和IPv6寻址的特殊计算机分区上。

对于最终用户，IPv4前端提供对IPv6后端的访问，使IPv6的使用透明。另一方面，开发人员可以使用Miredo或隧道代理（如Hurricane Electric）设置IPv6隧道。到目前为止，SlapOS IPv6可以在任何条件下实施。在最坏的情况下，可以通过IPv4和HTTP连接到托管在SlapOS上，并可通过前端访问的远程虚拟机，作为本地计算机的替代品。

如果IPv4是强制性的，只要部署VPN来提供具有足够可用地址的全局扁平寻址空间，就可以替换IPv6。一般来说，可以在每个SlapOS从节点上分配100个IPv4地址。像Tinc这样的分布式VPN技术最终可以集成到SlapOS的核心，以实现IPv4平面寻址空间，而不会影响SlapOS核心资源分配。

即使在今天，IPv6面临的最大问题仍然是市场占有率很低，以及双栈机制中两种协议间存在的安全漏洞或过渡协议的问题 。虽然IPv6是一项很不错的技术，但部署时，要为每个UNIX用户群提供加密和身份验证并不容易。以完全分散的方式部署也很困难。

Stunnel为这两个问题提供了解决方案。每当两个应用程序之间需要安全通信时，就会在两端创建一个Stunnel进程。Stunnel将本地IPv4地址映射到全局IPv6地址并加密所有通信。Stunnel还用于限制对特定X509证书的访问。

在SlapOS中，Stunnel也用于连接到托管在公共IPv6服务器上的MySQL数据库服务器。MySQL客户端本身仅部分支持IPv6，并不加密连接。使用Stunnel，可以通过加密和强身份验证访问基于IPv6的MySQL。可以使用相同的方法来访问Memcached服务器。Memcached最初是为可信任的局域网（LAN）而设计的。通过将Memcached协议封装到Stunnel中，可以使用Memcached支持IPv6，加密和身份验证。

在开发SlapOS时，大型Web基础架构应用程序（如社交网络，SaaS提供商或搜索引擎）使用的大多数软件组件都是为可信赖的环境和私有集群而设计的。将这些应用程序移植到分布式云和不可信任的网络需要大量额外的工作来确保连接安全。SlapOS选择使用Stunnel作为高效的点对点VPN，而不是使用集中式VPN方法，同时解决了IPv6迁移问题。

与可用的IP网络传输带宽相比，Stunnel本身性能更可靠。根据Stunnel的作者介绍， 在撰写本文档时，Stunnel的性能已可以达到5.5Gbit / s。