Get best of the week

关于1C服务器集群

群集是一种并行
或分布式系统，它：
1.由几台互连的
计算机组成；
2.用作单个
统一计算机资源

Gregory F. Pfister，“搜索集群”。

假定：有一个业务应用程序（例如ERP系统），成千上万（可能成千上万）的用户可以同时使用。

这是必需的：
  1. 使应用程序具有可伸缩性，从而随着用户数量的增加，有可能由于硬件资源的增加而提供必要的应用程序性能。
  2. 使应用程序抵抗系统组件（软件和硬件）的故障，组件之间的连接断开以及其他可能的问题。
  3. 尽可能高效地使用系统资源，并提供所需的应用程序性能。
  4. 使系统易于部署和管理。

为了解决这些问题，我们在1C：企业平台中使用了群集体系结构。

我们没有立即达到期望的结果。

在这篇文章中，我们将讨论什么样的集群是，我们如何选择簇的类型适合我们和我们的集群因版本发展而来的，其方法是如何使我们能够最终创建服务系统数 十万的用户同时使用。

图片

正如这篇题词的作者格雷戈里·普菲斯特（Gregory Pfister）在他的《寻找集群》一书中写道，集群并不是由任何特定的硬件或软件制造商发明的，而是由缺乏一台计算机的功能或需要冗余的客户发明的。根据普菲斯特（Pfister）的说法，这发生在上世纪60年代。
传统上区分以下主要类型的集群：

  1. 故障转移群集（HA，高可用性群集）
  2. 负载均衡集群（LBC）
  3. 计算集群（高性能计算集群，HPC）
  4. (grid) , . grid- , . grid- HPC-, .

为了解决我们的问题（抵抗系统组件故障和有效利用资源），我们需要将故障安全群集和具有负载平衡功能的群集的功能结合起来。我们不是立即做出这个决定，而是逐步地逐步解决它。

对于那些不是最新的人，我将简要地告诉您如何安排1C业务应用程序。这些是用面向主题的语言编写的应用程序，已“锐化”以实现会计业务任务的自动化。要运行以这种语言编写的应用程序，必须在计算机上安装1C：企业平台运行时。

1C：企业8.0


1C应用程序服务器的第一个版本（尚未群集）出现在平台版本8.0中。在此之前，1C在客户端-服务器版本中工作，数据存储在文件DBMS或MS SQL中，而业务逻辑仅在客户端上工作。在8.0版中，过渡到三层体系结构“客户端-应用程序服务器-DBMS”。

平台8.0中的服务器1C是COM +可以在1C中执行应用程序代码的服务器。使用COM +为我们提供了现成的传输方式，允许客户端应用程序通过网络与服务器进行通信。客户端-服务器交互的体系结构和1C开发人员可用的应用程序对象的体系结构中的很多内容都考虑到了COM +的使用。那时，体系结构中没有内置容错功能，并且服务器崩溃导致所有客户端关闭。当服务器应用程序崩溃时，COM +在第一个客户端访问它时将其抬起，并且客户端从一开始即从连接服务器开始工作。当时，所有客户都通过一个流程得到服务。
图片

1C：企业8.1


在下一个版本中，我们想要：

  • 为我们的客户提供容错能力，以使某些用户的事故和错误不会导致其他用户的事故和错误。
  • 摆脱COM +技术。COM +仅在Windows上工作，而那时在Linux下工作的可能性已经变得越来越重要。

同时，我们不想从头开始开发该平台的新版本-它会占用大量资源。我们希望最大程度地利用我们的成就，并保持与为8.0版开发的应用程序的兼容性。

因此，在8.1版中出现了第一个集群。我们为远程过程调用（在TCP之上）实现了我们的协议，在外观上，它看起来像最终用户-客户端的COM +（即，我们实际上不必重写负责客户端-服务器调用的代码）。同时，我们使服务器独立于C ++平台实现，能够在Windows和Linux上运行。

整体服务器版本8.0被3种类型的进程所取代-一个为客户端提供服务的工作进程，以及两个支持集群操作的服务进程：

  • rphost是为客户提供服务并执行应用程序代码的工作流。一个集群可以具有多个工作流，不同的工作流可以在不同的物理服务器上执行-由于实现了这种可伸缩性。
  • ragent-启动所有其他类型进程的服务器代理进程，以及位于该服务器上的群集的主要列表。
  • rmngr是一个集群管理器，它控制整个集群的运行（但是应用程序代码无法在其上运行）。

切下是集群中这三个过程的操作图。
image

在会话期间，客户端使用一个工作流，工作流下降意味着该进程服务的所有客户端，会话异常终止。其余客户继续工作。
图片

1C：企业8.2


在8.2版中，我们希望1C应用程序不仅能够在本机（可执行）客户端中运行，而且还能够在浏览器中运行（无需修改应用程序代码）。在这方面，尤其是出现了将应用程序的当前状态从与rphost工作流程的当前连接中分离出来并使之成为无状态的任务。结果，出现了会话和会话数据的概念，该概念必须存储在工作流外部（因为它是无状态的）。已经开发了一种会话数据服务，用于存储和缓存会话信息。还出现了其他服务-托管事务锁定服务，全文搜索服务等。

此版本还引入了一些重要的创新-改进的容错能力，负载平衡和群集冗余机制。

容错


由于工作流程变为无状态，并且工作所需的所有数据都存储在当前客户端之外-工作流连接，因此，如果工作流崩溃，则客户端在下次访问服务器时会切换到另一个``实时''工作流。在大多数情况下，客户端看不到这样的开关。

该机制是这样工作的。如果客户端由于某种原因无法完成对工作流的调用，则客户端部分可以在收到呼叫错误后通过重新建立与相同工作流或另一个工作流的连接来重复此调用。但是您不能总是重复通话；重复呼叫意味着我们已将呼叫发送到服务器，但未收到结果。我们尝试重复该呼叫，而在进行第二次呼叫时，我们评估上次呼叫的结果在服务器上（有关此信息的信息存储在会话数据中的服务器上），因为如果该呼叫有时间“继承”在那里（关闭事务，保存会话数据）等等）-重复此操作是不可能的，这将导致数据不一致。如果无法重复通话，客户端将收到一条有关不可恢复错误的消息，并且客户端应用程序将必须重新启动。如果您没有设法“继承”呼叫（这是最常见的情况，因为许多呼叫都不会更改数据，例如报表，在表单上显示数据等，而那些更改数据的交易都不会进行交易或直到会话数据中的更改已发送给管理器（没有呼叫记录）为止，可以重复该操作，而不会出现数据不一致的风险。如果工作流崩溃或网络连接中断，则将重复这样的调用，并且完全不会引起客户端应用程序的这种“灾难”。更改数据-直到提交事务或将会话数据中的更改发送给管理器-没有调用的痕迹）-可以重复该操作，而不会造成数据不一致的风险。如果工作流崩溃或网络连接中断，则将重复这样的调用，并且完全不会引起客户端应用程序的这种“灾难”。更改数据-直到提交事务或将会话数据中的更改发送给管理器-没有调用的痕迹）-可以重复该操作，而不会造成数据不一致的风险。如果工作流崩溃或网络连接中断，则将重复这样的调用，并且完全不会引起客户端应用程序的这种“灾难”。

负载均衡


在本例中，负载平衡的任务如下：新客户端进入系统（或者已经工作的客户端再次拨打电话）。我们需要选择将客户的呼叫发送到哪个服务器和工作流程，以便为客户提供最快的速度。

这是负载平衡群集的标准任务。有几种典型的算法可以解决该问题，例如：


对于我们的集群，我们选择的算法基本上接近最短响应时间。我们有一种机制可以收集有关群集中所有服务器上工作流性能的统计信息。它对集群中的每个服务器进程进行引用调用。参考调用涉及磁盘子系统，内存，处理器的功能的子集，并评估该调用的执行速度。这些测量结果（过去10分钟的平均值）是一个标准-集群中的哪台服务器在给定的时间段内向其发送客户端连接的效率最高，也是首选的。客户端请求的分配方式可以更好地加载生产力最高的服务器-加载幸运的服务器。

来自新客户端的请求已发送到当前生产力最高的服务器。

在大多数情况下，来自现有客户端的请求将发送至该服务器以及先前请求所针对的工作流。服务器上的大量数据与工作的客户端相关联；在进程之间（甚至在服务器之间更是如此）传输数据非常昂贵（尽管我们也可以这样做）。

在两种情况下，来自现有客户端的请求将转移到另一个工作流程：

  1. 没有更多的过程：客户端以前与之交互的工作流不再可用（该过程已中断，服务器已不可用，等等）。
  2. : , , , , . , , – . – (.. ).



我们决定通过主动/被动方案来提高群集的弹性。有机会配置了两个集群-工作集群和备用集群。如果主群集不可用（网络问题或计划的维护），则将客户端调用重定向到备份群集。

但是，这种设计很难配置。管理员必须手动将两个服务器组组装到群集中并对其进行配置。有时管理员会通过设置冲突的设置来犯错，没有用于检查设置的集中式机制。但是，尽管如此，这种方法仍提高了系统的容错能力。
图片

1C：企业8.3


在8.3版中，我们实质上重写了负责容错的服务器端代码。由于配置的复杂性，我们决定放弃主动/被动群集方案。系统中仅剩一个容错集群，该集群由任意数量的服务器组成-这更接近于主动/主动方案，在主动/主动方案中，将故障节点的请求分配到其余工作节点中。因此，群集变得更易于配置。增加容错能力和改善负载平衡的许多操作已实现自动化。在重要的创新中：

  • « »: , , . , «» .
  • , , .
  • , , , , , :

图片

图片

这些开发的主要思想是简化管理员的工作，允许他在服务器操作级别上以熟悉的术语配置集群，而不是降低它，并最小化集群工作的``手动控制''级别，为集群提供解决大多数工作任务和可能出现的问题的机制''在自动驾驶仪上。”

图片

容错的三个环节


如您所知，即使系统的各个组件都是可靠的，也会在系统的各个组件彼此引起冲突的地方出现问题。我们希望最大限度地减少对系统性能至关重要的位置。一个重要的附加考虑因素是最小化平台中应用机制的更改以及排除应用解决方案中的更改。在版本8.3中，有3个链接可确保“在关节处”的容错能力：

图片
  1. , HTTP(S), -. - -. , HTTP -, ( HTTP) libcurl .
  2. , .
  3. - . 1, - . - . , . , – . - (, , , ) – .
  4. , rmngr. 20 ( ) — , .. . 1: .



由于采用了容错机制，因此在1C：Enterprise平台上创建的应用程序可以成功解决群集中各种类型的生产服务器故障，而大多数客户端无需重新启动即可继续工作。

在某些情况下，我们无法重复呼叫，或者服务器崩溃在非常不幸的时间点捕获了平台，例如在事务处理中间，并且不清楚如何处理它们。当服务器位于群集中时，我们尝试确保统计上良好的客户端生存期。通常，因服务器故障而导致的平均客户端损失为百分之几。在这种情况下，所有“丢失的”客户端都可以在重新启动客户端应用程序后继续在群集中工作。

版本8.3中1C服务器群集的可靠性已大大提高。长期以来，引入1C产品并不少见，同时工作的用户数量达到数千。在某些实施中，有5,000和10,000个用户同时工作-例如，Beeline中的介绍， 1C：贸易管理应用程序为俄罗斯的所有Beeline销售网点提供服务，或货运公司中的Business Lines实施，该应用程序由1C：企业平台上的Business Lines的IT部门的开发人员独立创建，可为货物运输的整个周期提供服务。我们的内部集群负载测试可模拟多达20,000个用户的同时运行。

最后，我想简要列出一下我们集群中还有哪些有用的东西（列表不完整）：

  • , . , , .
  • – , , , ( – , ..) . , , (, ) , ERP, , ERP.
  • – , (, , ..). , , , , , .

More articles:


All Articles