CN108124000A - 管理系统及控制方法 - Google Patents

Abstract

本发明提供了管理系统及控制方法。管理系统确定请求从负荷分担装置被传输到的虚拟机。在接收来自客户端的请求的装置的设置从第一处理环境中的负荷分担装置切换为第二处理环境中的负荷分担装置时，管理系统将请求从第一处理环境中的负荷分担装置传输到第二处理环境中的虚拟机，并且不将请求从第一处理环境中的负荷分担装置传输到第一处理环境中的虚拟机。

Description

管理系统及控制方法

技术领域

本公开涉及管理包括虚拟机和负荷分担装置的处理环境的管理系统的至少一个实施例和控制方法。

背景技术

近年来，云服务的数量有了增长，在云服务中，用户可以根据需要尽可能地使用包括所需的应用程序、虚拟机和存储器的计算机资源。这类云服务被称为“SaaS”(服务软件)、“PaaS”(服务平台)或“IaaS”(服务基础架构)，并且用户可以独特地组合云服务供应商提供的应用程序和计算机资源。用户可以通过在云上构建系统作为服务供应商，来为终端用户提供服务。云服务供应商依据用户使用的应用程序和计算机资源的数量向用户收费。

通常，当要创建系统时，考虑要提供的功能和服务的规模来确定系统构造，并且需要选择用于操作应用程序的计算机资源。当要在服务操作过程中改变系统构造时或者当考虑到系统负荷或系统性能而要提高机器规格时，需要改变或增加计算机资源。然而，难以在操作中的环境中改变或增加计算机资源，并且因此，考虑到设置文件和程序在现有计算机资源中的部署以及系统的切回而提供停止时间。

为了解决停止时间的提供并改善操作期间的操作错误，近年来使用了被称为“蓝绿部署(Blue-Green deployment)”的升级方法。这里，例如，系统升级包括要由系统中包括的虚拟机执行的应用程序的升级。在升级的系统中，可以提供附加功能，或者改变管理数据的类型或格式。这里，虚拟机是如下的逻辑计算机：通过与服务器的物理构造无关的虚拟化技术按逻辑单位对服务器进行划分而获得并且利用相应的操作系统进行操作。

现在将描述通过蓝绿部署来升级系统的方法。首先，包括云服务中的、被设置为接受来自客户端的请求的装置(负荷平衡器或虚拟机)的处理环境用作生产环境。处理环境包括处理请求的至少一个虚拟机和负荷平衡器，负荷平衡器用作将请求分发给至少一个虚拟机的负荷分担装置。当要升级处理环境时，在云服务中进一步创建与当前版本的处理环境不同的升级后的处理环境。之后，在升级时，改变接收来自客户端的请求的装置的设置，并且切换用作生产环境的处理环境。通过该切换，实现系统的升级。这里，用于切换连接目的地的方法的示例包括如下方法：对设置文件进行重写，设置文件包括由服务器提供者管理的域名系统(DNS)服务器的DNS记录。

日本特开2016-115333号公报公开了通过蓝绿部署来升级系统的方法。

虽然通过执行上述蓝绿部署来切换用作生产环境的处理环境，但是在某些情况下，旧生产环境中的负荷分担装置接受来自客户端的请求。例如，当客户端的局部网络环境中的DNS服务器的更新延迟或者在客户端的缓存服务器中保留了旧的DNS缓存作为客户端环境的设置时，会出现这种情况。在这种情况下，当客户端发送请求时，旧的DNS记录被用于名称解析。那么，虽然用作生产环境的处理环境被切换，但是来自客户端的请求被旧生产环境(第一处理环境)接收，并且可能不在当前生产环境(第二处理环境)中被处理。也就是说，没有为客户端提供升级的服务。在如下情况下也是这样：由于紧接在执行蓝绿部署之后在新处理环境(第一处理环境)中发生故障，生产环境返回到旧处理环境(第二处理环境)。

发明内容

本公开提供了如下系统的至少一个实施例，在该系统中，即使当来自客户端的请求被发送到第一处理环境时，通过在客户端环境中进行至少一个设置仍使该请求被第二处理环境中的虚拟机处理。

根据本公开的管理系统的至少一个实施例确定请求从负荷分担装置被传输到的虚拟机。当接收来自客户端的请求的装置的设置从第一处理环境中的负荷分担装置切换为第二处理环境中的负荷分担装置时，管理系统将请求从第一处理环境中的负荷分担装置传输到第二处理环境中的虚拟机，而不将请求从第一处理环境中的负荷分担装置传输到第一处理环境中的虚拟机。

根据本公开的其他方面，这里讨论一个或更多个管理系统和一个或更多个控制方法。通过下面参照附图对示例性实施例的描述，本发明的其他特征将变得清楚。

附图说明

图1是例示网络系统的构造的图。

图2是例示具有信息处理功能的硬件的构造的图。

图3A至图3C是例示云系统的构造的图。

图4A至图4C是管理计算机资源的设置值的表。

图5是例示蓝绿部署之后的云系统的构造的图。

图6是部署处理的过程的流程图。

图7是例示根据至少第二实施例的云系统的构造的图。

图8A至图8C是管理处理环境的版本的表。

图9A和图9B是更新版本管理表的过程的流程图。

图10是删除旧蓝的计算机资源的处理的过程的流程图。

具体实施方式

在下文中，将参照附图描述本公开的优选实施例。

第一实施例

图1是例示根据本公开的至少一个实施例的网络系统的构造的图。信息处理装置104是使用光学线路与提供者103通信并且通过提供者103连接到互联网102的个人计算机(PC)、打印机或者多功能外围设备。信息处理终端107是例如以无线方式与基站106通信并且通过核心网络105连接到互联网102的诸如平板电脑、智能手机或者膝上型PC等的便携式设备。信息处理终端107可以是具有无线通信功能的台式PC或打印机。服务器101用作通过互联网102提供用于信息处理终端的网页和web应用程序编程接口(API)的云系统。至少本实施例的云系统提供如下的服务，该服务用于管理由诸如IaaS或PaaS的云服务提供的平台和资源所构建的网络设备以及拥有这些网络设备的客户。云系统可以由多个服务器101构建。

图2是例示具有信息处理功能的硬件(诸如服务器101、信息处理装置104、信息处理终端107和构建云系统的数据中心的服务器计算机等)的构造的图。

输入/输出接口201通过显示器、键盘、鼠标、触摸面板和按钮进行信息和信号的输入和输出。不包括这些硬件的计算机可以通过远程桌面或远程外壳连接到其他计算机并且通过其他计算机操作。网络接口202连接到诸如局域网(LAN)等的网络从而与另一个计算机或者网络设备通信。ROM 204记录嵌入的程序和数据。RAM 205是临时存储区域。二次存储设备206由硬盘驱动器(HDD)或闪速存储器代表。CPU 203执行从ROM 204、RAM 205、二次存储设备206等读取的程序。这些单元通过内部总线207彼此连接。服务器101包括执行存储在ROM 204中的程序并且通过内部总线207整体地控制这些单元的CPU 203。

图3A至图3C是例示云系统的至少一个实施例的构造的图。图3A是例示云系统的整体构造的图。云系统301通过提供服务所需的计算机资源构建。客户端302具有诸如信息处理装置104和信息处理终端107等的信息处理功能，并且使用由云系统301管理的服务。

信息处理环境310包括负荷平衡器311、虚拟机312、队列(queue)313和虚拟机314。通过域名系统(DNS)服务器340对处理环境310进行用于接收从客户端302供给的请求的设置。在通过DNS服务器340进行的设置中，在下文中将包括具有用于接收来自客户端的请求的设置的设备(负荷平衡器、虚拟机等)的处理环境称为“蓝环境”或者“生产环境”。在蓝环境中的负荷平衡器(负荷分担装置)311接收从客户端302供给的请求。这里假设负荷平衡器311对作为请求分发目的地的虚拟机定期执行健康检查。在健康检查中，确定虚拟机是否正常操作并且与虚拟机的通信是否可用。虚拟机(VM)312是从负荷平衡器311供给的请求的传输目的地并且能够处理传输的请求。这里，虚拟机是通过与服务器的物理构造无关的虚拟技术按逻辑单位对服务器进行划分而获得的逻辑计算机，并且用各操作系统而独立地操作。VM 312可以具有依据每单位时间的请求次数或VM 312的资源的使用率自动地进行扩展(scale-out)的设置。

队列313存储与VM 312的处理请求相对应的数据。VM 314定期地获得并处理存储在队列313中的数据(任务或消息)。与VM 312不同，由于存在队列313所以通常不对VM 314进行自动扩展的设置。然而，在预定时间段内可能不处理队列313中存储的数据的情况下或者队列313对VM 314定期进行散队(dequeuing)的情况下，可以进行自动扩展的设置。

执行蓝绿部署之后处理环境320变成生产环境。当与处理环境310中的VM中的应用程序比较时，在处理环境320中的VM中操作升级了的应用程序。将在执行蓝绿部署之后变成生产环境的处理环境称为“绿环境”。负荷平衡器321被包括在绿环境中，并且VM 322是负荷平衡器321发出的请求的分发目的地。当与蓝环境310中的VM 312中的应用程序比较时，在VM 322中操作升级了的应用程序。队列323存储与VM 322的处理请求相对应的数据。VM 324定期地获得和处理存储在队列323中的数据。当与蓝环境310中的VM 314中的应用程序比较时，在VM 324中操作升级了的应用程序。在绿环境中，客户端302通常不发送请求。然而，在客户端302或者系统管理单元360在指定绿环境的端点的同时发送请求的情况下，会在绿环境中进行蓝环境中的处理。

如上所述，蓝环境310和绿环境320基本上具有相同的配置。然而，绿环境的计算机资源的数量、规格和应用程序逻辑相对于蓝环境中的计算机资源的数量、规格和应用程序逻辑依据升级而改变。

这里，很多情况下使用云服务构建的系统在相对短的时段内反复进行升级，并且每天可以升级几十次或上百次。即使在这种情况下，服务提供者可以通过进行蓝绿部署容易地、不中断地进行计算机资源的改变和应用程序的升级。此外，由于服务不停止，客户端可以连续地使用服务而不考虑服务侧上进行的改变。

当切换连接目的地时，改写设置文件，使得外部请求的连接目的地被切换到新生产环境而不改变完全合格域名(fully qualified domain name，FQDN)。为了基于更新的DNS记录进行名称解析，客户端可以将请求发送给新生产环境而不改变FQDN。然而，即使服务提供者在由服务提供者管理的DNS服务器中设置驻留时间(Time-to-Live，TTL)，也不必然保证DNS服务器在终端用户的层中的更新间隔的情况。例如，在客户端的本地网络环境中的特定DNS服务器中更新延迟的情况下，或者在客户端的缓存服务器中保持DNS缓存的情况下，在名称解析中使用更新前的旧DNS记录。因此，用户发出的请求在作为旧版本的旧生产环境中被处理而不是在作为新版本的新生产环境中被处理。

返回到图3A，数据存储器330被蓝环境310和绿环境320使用。为了冗余目的可以安装多个数据存储器330或者从系统性能的角度出发可以安装不同类型的数据存储器。注意，虽然图3A中的蓝环境和绿环境共享数据存储器，但是处理环境可以具有各自的数据存储器。DNS服务器340将云系统301中包括的端点的域名信息和关联信息作为包括DNS记录等的设置文件进行管理。下述资源管理单元350改写DNS服务器340的设置文件使得实现用于在蓝环境和绿环境之间切换的蓝绿部署。具体地，资源管理单元350以使得负荷平衡器311和321的端点与由云系统301管理的服务的官方FQDN关联的方式改写DNS服务器340的设置文件，使得进行处理环境之间的切换。

图3B是例示资源管理单元350的构造的图。资源管理单元350对云系统301中包括的计算机资源进行监视和操作，并且资源管理单元350是由云服务供应商提供的功能。资源生成单元351具有生成包括处理环境和数据存储器的计算机资源的功能。设置值更新单元352具有更新DNS服务器340的设置文件(参照下述图4A)的功能。当接收到由系统管理单元360的资源操作单元361发出的指令时，设置值更新单元352直接改写DNS服务器340的设置文件或者调用由计算机资源提供的API，从而更新设置值。资源监视单元353具有监视云系统301中的计算机资源的状态、访问日志和操作日志的功能。资源删除单元354具有删除云系统301中的计算机资源的功能。资源删除单元354可以被设置使得通过预先在调度程序中登记删除处理而定期删除不需要的计算机资源。

图3C是例示系统管理单元360的构造的图。系统管理单元360向资源管理单元350发出用于操作云系统301中的计算机资源的指令。系统管理单元360在本实施例中用作管理系统并且是由管理云系统301的系统开发员而生成的。系统管理单元360能够与DNS服务器340、资源管理单元350和管理数据存储器370通信。资源操作单元361接收由管理云系统301的系统开发员的开发PC发出的请求，并且向上述资源管理单元350中包括的单元发出用于操作云系统301的计算机资源的指令。资源操作单元361管理用于管理处理环境的构造信息的表(参照图4B)和用于管理处理环境的负荷平衡器的设置信息的表(参照图4C)。应用程序测试单元362具有向处理环境发送处理环境的操作检查和通信检查的测试请求的功能。应用程序测试单元362(在下文中称为“测试单元362”)将由管理云系统301的服务提供者预先生成的测试供给到管理数据存储器370等。当要执行测试时，测试单元362将测试请求发送给使用测试工具的任意处理环境。此外，测试单元362可以使负荷平衡器311和321通过资源管理单元350对VM 312和322发出用于执行健康检查的指令。管理数据存储器370用于管理，并且存储表示指令的资源操作单元361的管理程序、处理环境310和320的应用程序以及云系统301中使用并生成的数据，例如访问日志。

图4A至图4C是例示管理计算机资源的设置值的表。虽然在下文中描述，但是图4A至图4C中的表中的设置值与DNS服务器340和处理环境510和520的状态有关。虽然以矩阵形式(例如，表格形式)管理设置值，但是在本实施例中可以将设置值管理为诸如JavaScript对象符号(JavaScript Object Notation(JSON))等的键值形式的设置文件。

图4A中的设置文件400包括DNS服务器340的DNS记录。设置文件400被存储在DNS服务器340中。客户端302基于设置文件400进行名称解析。列401包括作为从客户端302到蓝环境310的请求的发送目的地的主机名称。列402包括DNS记录的记录类型。列403包括与列401中设置的主机名称关联的端点的目的地。列404包括表示DNS记录有效的时间段的TTL。列405表示记录是有效还是无效。

图4B的表410管理处理环境的构造信息。表410被存储在管理数据存储器370中。当资源生成单元351生成处理环境和处理环境中的计算机资源，设置值更新单元352更新处理环境和处理环境中的计算机资源，资源删除单元354删除处理环境和处理环境中的计算机资源时，由资源操作单元361更新表410。列411包括处理环境的系统版本。系统版本411是用于对当资源生成单元351生成处理环境时发出的处理环境进行识别的唯一ID。列412包括作为在外部公开的并且从客户端302可访问的负荷平衡器(例如负荷平衡器311或者负荷平衡器321)的唯一ID。列413包括与处理环境的前端服务器相对应的VM(例如，VM 312或VM 322)的唯一ID。列414包括与处理环境的队列相对应的队列(例如，队列313或队列323)的唯一ID。列415包括与处理环境的后端服务器或批处理服务器相对应的VM(例如，VM 314或VM324)的唯一ID。

列416包括表示作为从处理环境中的负荷平衡器供给的请求的传输目标的VM的设置值。处理环境中的负荷平衡器将请求传输到列416中包括的VM中的一个。在蓝和绿之间切换后，列416中的设置值由资源操作单元361更新。在管理表410中，第一行(包括系统版本“20160101-000000”的行)中的处理环境表示，列412中描述的负荷平衡器接收请求，并且之后，请求被传输到在列416中设置的VM。在表410的第一行中的处理环境中，在列412中描述的负荷平衡器将请求传输到表410的第二行中的处理环境中的列413的VM。在表410的第二行中的处理环境中，在列416中描述了“自身(myself)”，并且因此，请求被传输到相同处理环境中的VM中而不传输到其他处理环境中的VM。具体地，表410管理列412中的负荷平衡器与作为请求传输目的地的列416中的VM之间的关联。

也就是说，第一行中的处理环境是旧生产环境，第二行中的处理环境是当前生产环境，并且旧生产环境中的负荷平衡器将请求传输到当前生产环境中的VM。正常情况下，生产环境中的负荷平衡器将请求传输到生产环境的VM。注意，表定义依据表410中的处理环境的系统构造而改变，并且因此，管理处理环境构造信息的表不限于表410的表定义。

图4C中的表420管理处理环境的负荷平衡器的设置信息。表420被存储在管理数据存储器370中。当资源生成单元351生成负荷平衡器，设置值更新单元352更新负荷平衡器，资源删除单元354删除负荷平衡器时，由资源操作单元361更新表410。列421包括表示作为在外部公开的并且从客户端302可访问的负荷平衡器(例如负荷平衡器311或者负荷平衡器321)的唯一ID，并且对应于列412。列422包括表示负荷平衡器的端点的值以及在列422中设置的DNS名称或者IP地址。列423包括负荷平衡器的防火墙的设置值。作为防火墙的设置值，在列423中描述许可通信的协议或端口或者入站或出站规则。列424包括健康检查的设置值。作为健康检查的设置值，在列424中描述在健康检查中要发送的请求的目的地和端口号或者用于正常健康检查的规则。可以如图4C所示针对表420指定设置文件分别作为列423和424中的防火墙的设置值和健康检查的设置值，或者可以设置直接值。

图5是例示执行蓝绿部署之后的处理环境的构造的图。术语“执行蓝绿部署之后”表示通过使用设置值更新单元352改写设置文件400，切换由云系统301管理的服务的官方FQDN与负荷平衡器的NDS名称之间的关联之后的时间点。在下文中，蓝绿部署被简称为“切换”。

例如，由于切换之后客户端502的网络环境中未更新DNS缓存，所以客户端502继续向旧处理环境发送请求。切换之后，客户端503适当地将请求发送到新处理环境。附图标记510表示切换之后的旧处理环境。旧处理环境也被称为“旧蓝环境”。另一方面，附图标记520表示新处理环境，并且在下文中也被称为“蓝环境”。即使在切换之后，旧蓝环境也操作。

如上所述，图4B的表410的第一行中的处理环境对应于旧蓝环境510的处理环境。旧蓝环境中的负荷平衡器511对应于表410的第一行中的处理环境中的列412中的负荷平衡器。由于即使在切换之后旧蓝环境也继续操作，所以负荷平衡器511接收从客户端502供给的请求。切换之后，资源操作单元361更新负荷平衡器511的设置值，使得负荷平衡器511将请求传输给VM 522。此外，资源操作单元361更新负荷平衡器511的设置值使得禁止请求从负荷平衡器511传输到VM 512。这里，资源操作单元361用第二行中(蓝环境520的处理环境的构造信息)的列413(VM 522)中的值作为设置值更新表410中的第一行(旧蓝环境510的处理环境的构造信息)中的列416。通过该更新，由于即使当作为旧蓝环境510的端点的负荷平衡器511接收到来自客户端502的请求时，实际请求传输目的地也是VM 522，所以请求被传输到蓝环境。注意，VM 512、队列513以及VM 514处于操作中，并且因此，虽然正被处理的请求被正常处理，但是不新进行传输处理。附图标记520表示切换后的新处理环境并且对应于上述的蓝环境。蓝环境包括与由云系统301管理的服务的官方FQDN关联的负荷平衡器521。

此外，图4B的表410的第二行中的处理环境对应于蓝环境520的处理环境。附图标记521表示蓝环境中的负荷平衡器。负荷平衡器521接收从在切换后在客户端502的网络环境中更新DNS缓存起适当地发送的请求。负荷平衡器521将旧蓝环境的请求传输到VM 522，并且之后，将处理中继到队列523和VM 524。与旧蓝环境510不同，在蓝环境中，不需要将请求从客户端503传输到另一个处理环境，并且因此，不更新表410。

注意，当旧蓝环境510的负荷平衡器511响应于从客户端供给的请求而向客户端返回错误时，充当发送源的客户端可以新获得DNS记录。然而，需要访问云系统301的所有客户端具有这种机制。

图6是例示部署处理的过程的流程图。通过系统管理单元360执行图6的流程图中的处理。具体地，当数据中新的服务器计算机的CPU 203读出并执行记录在ROM 204或二次存储设备206中的程序时，实现图6的流程图中的处理。

在步骤S601中，资源操作单元361向资源生成单元351发出用于构建绿环境的指令。当构建绿环境时，关于各种计算机资源的信息被添加到表410和420。在步骤S602中，资源操作单元361向设置值更新单元352发出用于执行蓝绿切换的指令。具体地，通过更新DNS服务器340的设置文件，改变接收来自安装在云系统中的客户端的请求的负荷平衡器。在步骤S603中，资源操作单元361向设置值更新单元352发出询问，并且当确定成功进行了切换时，执行步骤S604中的处理，否则，本流程图的处理终止。在步骤S604中，测试单元362通过对蓝环境520进行操作/通信检查等来确定蓝环境520是否正常操作。当确定结果为肯定时，测试单元362执行步骤S605中的处理，否则执行步骤S610中的处理。

在步骤S605中，资源操作单元361更新表410使得旧蓝环境510的负荷平衡器511与蓝环境520的VM 522相关联。具体地，管理表410的第二行中的列413中包括的VM被添加到管理表410的第一行中的列416作为请求传输目的地的候选。在进行关联时的时间点，旧蓝环境510的负荷平衡器511对蓝环境520的VM 522进行的健康检查未完成，并且因此，来自客户端502的请求不传输到蓝环境520的VM 522。在步骤S606中，测试单元362向旧蓝环境510的负荷平衡器511发出用于进行对在步骤S605中添加的蓝环境520的VM 522进行健康检查的指令。在健康检查中，确定虚拟机是否正常操作并且确定与虚拟机的通信是否可用。注意，当旧蓝环境510的负荷平衡器511执行对蓝环境520的健康检查时，旧蓝环境510和蓝环境520中的负荷平衡器中的设置值可以彼此不同，并且因此健康检查可能失败。因此，测试单元362可以在蓝环境520的负荷平衡器521的设置值基于表420中包括的信息被应用到旧蓝环境510的负荷平衡器511之后，发出用于执行健康检查的指令。在步骤S607中，当测试单元362基于在步骤S606中测试单元362执行的健康检查的结果而确定请求可以被传输到蓝环境520的VM 522时，执行步骤S608中的处理，否则，执行步骤S612中的处理。并且当健康检查失败时，测试单元362执行步骤S612中的处理。

在步骤S608中，资源操作单元361指示旧蓝环境510的负荷平衡器511将从客户端502供给的请求传输到在步骤S605中添加的蓝环境520的VM 522。在步骤S609中，资源操作单元361更新表410使得取消旧蓝环境510的负荷平衡器511与VM 512之间的关联，使得从客户端502供给的请求不被传输到旧蓝环境510中的VM 512。具体地，资源操作单元361删除在管理表410的第一行中的处理环境的列413、414和415中设置的值，并且分配删除标志从而更新表410。如果从负荷平衡器511到作为请求分发目的地的VM 512的通信可以通过对负荷平衡器511的设置而关闭，则可以仅关闭通信而不取消负荷平衡器511与VM 512之间的关联。类似地，当关闭通信时，资源操作单元361更新表410中的列413、414和415的设置值。之后，部署处理终止。

在步骤S610中，资源操作单元361指示设置值更新单元352再次执行在步骤S602中执行的、设置文件400的更新从而进行从蓝环境520到旧蓝环境510的切回。在步骤S611中，资源操作单元361更新表410使得通过切换变成了蓝环境的处理环境510的VM 512被添加到通过切换变成了旧蓝环境的处理环境520的负荷平衡器521。注意，在步骤S611的时间点，请求尚未从客户端被传输到VM 512。

在步骤S612中，资源操作单元361更新表410使得取消蓝环境的VM与作为在外部公开的旧蓝环境的负荷平衡器之间的关联，并且终止部署处理。如果不需要健康检查，则处理可以进行到步骤S608同时跳过步骤S606和步骤S607。此外，当进行图4B的表410中的关联时，在没有在步骤S608中由资源操作单元361向负荷平衡器511发出的指令的情况下，负荷平衡器511可以将请求传输到VM 522。

至少根据本实施例，即使当处理环境520对来自客户端的接收的设置被存储为DNS服务器中的记录时，处理环境510的负荷平衡器511可以接收来自客户端的请求。在这种情况下，至少根据本实施例，系统管理单元360将处理环境510中的负荷平衡器511与处理环境520中的VM 522关联，并且取消处理环境510中的负荷平衡器511与处理环境510中的VM 512的关联。至少根据本实施例，由在没有被DNS服务器设置为生产环境的处理环境中的负荷分担装置接收到的请求，可以在被设置为生产环境的处理环境中的VM中被处理。

第二实施例

至少在第一实施例中，描述了更新用于在切换之后将请求从负荷平衡器传输到两个环境(即，蓝环境和旧蓝环境)中的VM的设置值的流程。然而，当经常进行处理环境的升级时，可以并行地存在三个或更多个环境。有时候使用用于针对各个升级生成处理环境和删除不需要的处理环境的部署方法。具体地，当在蓝绿部署中完成连接目的地的切换并且确定系统没有故障时，不再需要旧生产环境，并且因此，可以删除旧生产环境。即使在这种情况下，由于至少在第一实施例中描述的理由，有些客户端继续向旧处理环境发送请求，并且因此，这类客户端的请求发送目的地需要被改变为最新的处理环境。至少在第二实施例中，描述用于管理不是生产环境的多个处理环境的方法作为至少第一实施例的应用例。

图7是例示切换后包括三个或更多个处理环境的云系统构造的图。至少与第一实施例相同，由于在客户端702和703的网络环境中未更新DNS缓存，所以客户端702和703继续向旧处理环境发送请求。客户端703将请求发送给旧蓝环境720，并且客户端702将请求发送给比旧蓝环境更旧的更旧处理环境(在下文中被称为“旧旧蓝”)710。客户端704将请求发送给包括与由云系统301管理的服务的官方FQDN相关联的负荷平衡器731的蓝环境730。切换之后，资源操作单元361更新负荷平衡器711和721的设置值使得负荷平衡器711和721将请求传输给VM 732。同时，资源操作单元361更新负荷平衡器711和721的设置值使得负荷平衡器711和721不将请求分别传输到VM 712和722。

图8A至图8C是例示针对各个处理步骤的处理环境的管理表的图。管理表800管理各个版本的处理环境。虽然通过扩展图4B的表410生成管理表800，但是新生成的管理表可以用作管理表800。在部署期间的步骤中管理表800被存储在管理数据存储器370中并且由资源操作单元361更新。

列801包括处理环境的版本并且对应于图4B的列411。列802包括在外部公开的负荷平衡器的唯一ID并且对应于列412。列803包括作为来自在外部公开的负荷平衡器711、721和731的请求的传输目的地的VM，并且对应于图4B中的列416。列804包括处理环境的系统模式。在本实施例中，为了便于描述，定义了五个系统模式，即“旧蓝(old blue)”、“蓝(blue)”、“绿(green)”、“等待旧蓝(waiting old blue)”和“切回(switch-back)”。处理环境“旧蓝”在过去作为蓝环境操作。处理环境“蓝”作为蓝环境操作，并且包括作为从如至少在第一实施例中描述的另一个处理环境中的负荷平衡器所供给的请求的传输目的地的VM。处理环境“绿”作为绿环境操作，并且只有处理环境“绿”不将请求传输到处理环境“蓝”。处理环境“等待旧蓝”是过去的蓝环境并且当进行切回时可以再次返回到蓝环境。前述处理环境“蓝”被切换到处理环境“等待旧蓝”。经过预定时间段后，当确定处理环境“蓝”被正常操作时，处理环境“等待旧蓝”被改变为处理环境“旧蓝”。预定时间段可能是一周、一个月等。处理环境“切回”对应于例如当在蓝环境中发生错误时由于切回而再次进入蓝环境的状态。列805包括当系统模式改变时的系统模式的更新日期和时间。

图8A是在从构建绿环境时到进行切换时的一段时间的管理表800的图。图8B是在从进行切换时到确定“蓝”被正常操作时的一段时间的管理表800的图。图8C是由于确定“蓝”未被正常操作而进行切回之后所获得的管理表800的图。具体地，下述图9A的步骤S902之后的状态对应于图8A，步骤S905之后的状态对应于图8B，并且步骤S913之后的状态对应于图8C。

图9A和图9B是例示使用处理环境的管理表的一系列部署处理的过程的流程图。具体地，当数据中心的服务器计算机的CPU 203读取并执行存储在ROM 204或二次存储设备206中的程序时，实现图9A和图9B的流程图中的处理。

在步骤S901中，类似于步骤S601的处理，资源操作单元361向资源生成单元351发出用于构建绿环境的指令。在步骤S902中，资源操作单元361将在步骤S901中构建的绿环境添加到管理表800。在步骤S903中，类似于步骤S602的处理，资源操作单元361指示切换。在步骤S904中，确定是否成功进行切换，并且当确定结果为肯定时，处理进行到步骤S905，否则，部署处理终止。

在步骤S905中，资源操作单元361更新管理表800中的关于环境的信息。首先，资源操作单元361将与系统模式804的“蓝”相对应的处理环境更新为与“等待旧蓝”相对应的处理环境，并且将与“绿”相对应的处理环境更新为与“蓝”相对应的处理环境。随后，资源操作单元361对系统模式804已更新的处理环境的系统模式更新日期和时间805进行更新。最终，资源操作单元361将更新为系统模式“旧蓝”和“等待旧蓝”的处理环境中的负荷平衡器的请求的传输目的地的VM更新为与系统模式“蓝”相对应的VM。在步骤S906中，确定与系统模式804的“蓝”相对应的处理环境是否被正常操作。当确定结果为肯定时，执行步骤S907中的处理，否则，执行步骤S912中的处理。依据测试单元362执行的测试成功的事实或者当预定时间段之后进行特定请求处理时没有发生错误的事实，做出关于处理环境是否被正常操作的确定。

在步骤S907中，资源操作单元361将与系统模式804的“等待旧蓝”相对应的处理环境更新为“旧蓝”，并且更新系统模式更新日期和时间805。在步骤S908中，测试单元362和资源操作单元361将与系统模式804的“旧蓝”相对应的负荷平衡器和与系统模式“蓝”相对应且充当请求传输目的地的VM相关联。此外，测试单元362发出用于执行健康检查的指令。在步骤S909中，与步骤S607中的处理相同，当测试单元362基于健康检查的结果而确定请求可以被传输到与系统模式的“蓝”相对应的VM时，执行步骤S910中的处理，否则，执行步骤S915中的处理。此外，在健康检查失败的情况下，测试单元362执行步骤S915中的处理。

在步骤S910中，资源操作单元361指示负荷平衡器与在步骤S909中成功进行了健康检查的VM的组合将请求从负荷平衡器传输到VM。在步骤S911中，资源操作单元361依据管理表800中包括的信息，将与系统模式802的“旧蓝”和“切回”相对应的处理环境中的负荷平衡器跟环境自身的VM之间的关联取消。与步骤S609中的处理相同，资源操作单元361可以仅关闭通信而不取消负荷平衡器与VM之间的关联。

在步骤S912中，与步骤S610中的处理相同，资源操作单元361执行切回。这里，作为切回的结果，与系统模式804的“等待旧蓝”相对应的处理环境进入蓝环境。在步骤S913中，首先，资源操作单元361更新管理表800使得与系统模式804的“等待旧蓝”相对应的处理环境被更新为“蓝”并且将系统模式804的“蓝”更新为“切回”。之后，资源操作单元361对系统模式804已改变的处理环境的系统模式更新日期和时间805进行更新。最终，资源操作单元361将来自于负荷平衡器的请求的传输目的地的VM设置为与“蓝”相对应的处理环境的VM。在步骤S914中，测试单元362和资源操作单元361将被切回的处理环境的VM(在该时间点为“蓝”)添加到被切回的处理环境(在该时间点为“切回”)的负荷平衡器并执行健康检查。

在步骤S915中，资源操作单元361取消健康检查失败的与“旧蓝”和“切回”相对应的处理环境中的负荷平衡器跟作为请求传输目的地的与“蓝”相对应的VM之间的关联。

如上所述，如果服务的升级频率高，则可以保留旧蓝环境。然而，由于操作成本变高，所以在一个或更多个实施例中优选地删除不需要的处理环境。将描述如下方法：在仅保留客户端可访问并且在外部公开的负荷平衡器的同时，依据条件而在该负荷平衡器的控制下删除计算机资源。

图10是删除旧蓝环境的计算机资源的处理的过程的流程图。在步骤S11001中，资源监视单元353监视与系统模式804的“旧蓝”相对应的处理环境的各种计算机资源、访问日志、操作日志等的使用状态。在步骤S1002中，资源监视单元353检查除了在与系统模式804的“旧蓝”相对应的处理环境中在外部公开的负荷平衡器以外的计算机资源的使用状态。资源监视单元353确定在预定时间段下是否未访问服务器或者在队列中是否不包括数据。当确定结果为否定时(即，未访问服务器或队列中不包括数据)，则执行步骤S1003中的处理。否则，资源监视单元353在一定时间段后再次检查计算机资源的使用状态和日志。在步骤S1003中，删除除了在与系统模式804的“旧蓝”相对应的处理环境中在外部公开的负荷平衡器以外的计算机资源。在步骤S1004中，检查在与系统模式804的“旧蓝”相对应的处理环境中在外部公开的负荷平衡器的访问日志。如果在预定时间段或更长的时间下不能检测到访问日志，则执行步骤S1005中的处理，并且当在预定时间段下检测到访问日志时，资源监视单元353在一定时间段之后再次检查负荷平衡器的访问日志。在步骤S1005中，删除在与系统模式804“旧蓝”相对应的处理环境中在外部公开的负荷平衡器。

注意，在步骤S1003中，如果在旧蓝环境的队列中还保留消息，则可以仅删除旧蓝环境中的VM 722，并且可以不删除旧蓝环境中的队列和拥有队列中的消息的VM。

至少根据本实施例，在云系统中并行地生成三个处理环境的情况下，系统管理单元360将两个处理环境中的、未被DNS服务器设置为生产环境的处理环境中的负荷分担装置，与被设置为生产环境的另一个处理环境中的虚拟机相关联。此外，系统管理单元360删除未被设置为生产环境的处理环境中的虚拟机。至少根据本实施例，未被DNS服务器设置为生产环境的处理环境中的负荷分担装置所接收到的请求，可以在被设置为生产环境的处理环境中的VM中进行处理。

其他实施例

还可以通过读出并执行记录在存储介质(也可更完整地称为“非暂时性计算机可读存储介质”)上的计算机可执行指令(例如，一个或更多个程序)以执行上述实施例中的一个或更多个的功能、并且/或者包括用于执行上述实施例中的一个或更多个的功能的一个或更多个电路(例如，专用集成电路(ASIC))的系统或装置的计算机，来实现本发明的实施例，并且，可以利用通过由系统或装置的计算机例如读出并执行来自存储介质的计算机可执行指令以执行上述实施例中的一个或更多个的功能、并且/或者控制一个或更多个电路以执行上述实施例中的一个或更多个的功能的方法，来实现本发明的实施例。计算机可以包括一个或更多个处理器(例如，中央处理单元(CPU)、微处理单元(MPU))，并且可以包括分开的计算机或分开的处理器的网络，以读出并执行计算机可执行指令。计算机可执行指令可以例如从网络或存储介质被提供给计算机。存储介质可以包括例如硬盘、随机存取存储器(RAM)、只读存储器(ROM)、分布式计算系统的存储器、光盘(诸如压缩光盘(CD)、数字通用光盘(DVD)或蓝光光盘(BD)^TM)、闪存装置以及存储卡等中的一个或更多个。

本发明的实施例还可以通过如下的方法来实现，即，通过网络或者各种存储介质将执行上述实施例的功能的软件(程序)提供给系统或装置，该系统或装置的计算机或是中央处理单元(CPU)、微处理单元(MPU)读出并执行程序的方法。

虽然已经参照示例性实施例对本发明进行了描述，但是应该理解，本发明不限于所公开的示例性实施例。应当对权利要求的范围给予最宽的解释，以使其涵盖所有这些变型例以及等同的结构及功能。

Claims (11)

1.一种管理系统，其管理多个处理环境，所述多个处理环境中的各个至少包括能够处理来自客户端的请求的多个虚拟机和将请求传输到所述多个虚拟机的负荷分担装置，所述管理系统包括：

管理部，其用于确定所述多个虚拟机中的、请求从负荷分担装置被传输到的虚拟机，

其中，在接收来自客户端的请求的装置的设置从第一处理环境中的负荷分担装置切换为与第一处理环境不同的第二处理环境中的负荷分担装置时，管理部将请求从第一处理环境中的负荷分担装置传输到第二处理环境中的虚拟机，并且不将请求从第一处理环境中的负荷分担装置传输到第一处理环境中的虚拟机。

2.根据权利要求1所述的管理系统，所述管理系统还包括：

第一指令部，其用于指示第一处理环境中的负荷分担装置进行关于是否要将请求传输到充当传输目的地的候选的虚拟机的确定，

其中，在基于指令确定要将请求从第一处理环境中的负荷分担装置传输到第二处理环境中的虚拟机的情况下，将第一处理环境中的负荷分担装置接收到的请求传输到第二处理环境中的虚拟机。

3.根据权利要求2所述的管理系统，其中，在基于第一指令部发出的指令确定要将请求从第一处理环境中的负荷分担装置传输到第二处理环境中的虚拟机的情况下，管理部禁止将请求从第一处理环境中的负荷分担装置传输到第一处理环境中的虚拟机。

4.根据权利要求1所述的管理系统，其中，接收来自客户端的请求的装置的设置被存储在管理系统可访问的域名系统服务器中。

5.根据权利要求1所述的管理系统，所述管理系统还包括：

第二指令部，其用于指示资源管理单元执行虚拟机的生成或删除，

其中，在接收来自客户端的请求的装置的设置从第一处理环境中的负荷分担装置切换为第二处理环境中的负荷分担装置后经过第一预定时间段时，第二指令部指示资源管理单元删除第一处理环境中的虚拟机。

6.根据权利要求5所述的管理系统，

其中，第二指令部还能够指示资源管理单元生成或删除负荷分担装置，并且

在接收来自客户端的请求的装置的设置从第一处理环境中的负荷分担装置切换为第二处理环境中的负荷分担装置后经过比第一预定时间段长的第二预定时间段时，第二指令部指示资源管理单元删除第一处理环境中的负荷分担装置。

7.根据权利要求6所述的管理系统，其中，在接收来自客户端的请求的装置的设置从第一处理环境中的负荷分担装置切换为第二处理环境中的负荷分担装置后经过第二预定时间段时，在第一处理环境中的负荷分担装置未接收到来自客户端的请求的情况下，第二指令部指示资源管理单元删除第一处理环境中的负荷分担装置。

8.根据权利要求1所述的管理系统，其中，第二处理环境中的虚拟机中操作的应用程序的版本比在第一处理环境中的虚拟机中操作的应用程序的版本新。

9.根据权利要求8所述的管理系统，其中，存在多个第一处理环境。

10.根据权利要求1所述的管理系统，其中，在接收来自客户端的请求的装置的设置从第一处理环境中的负荷分担装置切换为第二处理环境中的负荷分担装置，并且之后切换为第一处理环境中的负荷分担装置时，管理部：

使第一处理环境中的负荷分担装置将请求传输到第一处理环境中的虚拟机，使第一处理环境中的负荷分担装置不将请求传输到第二处理环境中的虚拟机，使第二处理环境中的负荷分担装置将请求传输到第一处理环境中的虚拟机，并且使第二处理环境中的负荷分担装置不将请求传输到第二处理环境中的虚拟机。

11.一种管理系统的控制方法，所述管理系统管理多个处理环境，所述多个处理环境中的各个至少包括能够处理来自客户端的请求的多个虚拟机和将请求传输到所述多个虚拟机的负荷分担装置，所述控制方法包括：

管理步骤，其确定请求从负荷分担装置被传输到的虚拟机，

其中，在管理步骤中，在接收来自客户端的请求的装置的设置从第一处理环境中的负荷分担装置切换为与第一处理环境不同的第二处理环境中的负荷分担装置时，将请求从第一处理环境中的负荷分担装置传输到第二处理环境中的虚拟机，并且不将请求从第一处理环境中的负荷分担装置传输到第一处理环境中的虚拟机。