> 使用 WebLogic Server 群集 > 迁移

使用 WebLogic Server 群集

     上一页  下一页    在新窗口中打开目录     
在此处开始内容

迁移

下列部分描述了 WebLogic Server 支持的各种不同的迁移机制：

这些部分主要关注失败服务器实例和服务的迁移。WebLogic Server 还支持应用程序级别的复制和故障转移。有关详细信息，请参阅群集中的故障转移和复制。

 

了解服务器和服务迁移

注意： 并非所有的平台都支持服务器迁移。请参阅“WebLogic Platform 9.2 Supported Configurations”中的 Server Migration。

在 WebLogic Server 群集中，大多数服务都均匀部署在群集中的所有服务器实例上，从而实现了从一个服务器到另一个服务器的透明故障转移。与之相反，像 JMS 和 JTA 事务恢复系统这样的“固定服务”则定位在群集中的单个服务器实例上 – 对于这些服务，WebLogic Server 使用迁移支持失败恢复，而不支持故障转移。

WebLogic Server 中的迁移是在发生失败时将群集的 WebLogic Server 实例或在群集实例上运行的组件移动到其他位置的过程。对于服务器迁移，服务器实例将在失败时被迁移到另一台物理计算机。对于服务级迁移，服务则会被移至群集中的另一个服务器实例。

WebLogic Server 提供了使得 JMS 和 JTA 事务系统具有高可用性的功能：可迁移服务器。对于自动迁移和手工迁移，可迁移服务器都是在服务器级提供的，而不是在服务级提供的。

注意： 服务器级迁移是服务级迁移的备用方式。服务迁移和服务器迁移不应组合使用。如果在群集中迁移某个单独的服务，则不要迁移整个服务器实例。
注意： 服务器迁移仅在您使用 SSH 版本的节点管理器时受支持。服务器迁移在 Windows 上不受支持。

当可迁移服务器由于任何原因（例如它挂起、丢失网络连接或它的主机计算机失败）不可用时，都会进行自动迁移。失败后，可迁移服务器将尽可能在同一台计算机上自动重新启动。如果可迁移服务器无法在它失败时所位于的计算机上重新启动，则迁移到另一台计算机。另外，管理员还可以手工启动服务器实例的迁移。

 

迁移术语

下列术语适用于服务器迁移和服务迁移：

 

租用

租用是一个过程，WebLogic Server 使用该过程来管理必需某个时间仅在群集的一个成员上运行的服务。租用确保了群集范围实体的独占所有权。在群集中，一个租用仅有一个所有者。另外，在发生服务器或群集失败时，租用可以故障转移。这样有助于避免单点失败。

使用租用的功能

下列 WebLogic 服务器功能使用租用：

注意： 基本配置之外的大多数租用功能由 WebLogic Server 内部处理。

租用版本

WebLogic Server 提供了租用功能的两个不同实现。您使用哪个实现取决于您的要求和环境。

注意： 在 WebLogic Server 安装中，您只能使用一种类型的租用。尽管可以在环境中实现使用租用的多个功能，但每个功能都必须使用相同种类的租用。

高可用性数据库租用

在此版本的租用中，租用信息在高可用性数据库表中维护。需要高可用性数据库来确保租用信息总是可用。群集的每个成员都必须能够连接该数据库，这样才能访问租用信息。

这种租用方法对于在其群集环境中已经具有高可用性数据库的客户非常有用。通过这种方法，您无需使用节点管理器来管理环境中的服务器即可使用租用功能。

下列过程简要列出了配置用于租用的数据库所需的步骤。

  1. 配置用于服务器迁移的数据库。此信息用于确定服务器是否正在运行或者是否需要迁移。有关租用的详细信息，请参阅租用。

    2. 数据库必须可靠。服务器实例的可靠程度只能与该数据库相同。为了进行试验，常规数据库就足够了。对于生产环境，则只推荐高可用性数据库。如果数据库关闭，所有可迁移服务器都将自行关闭。

    在数据库中创建租用表。此表用于存储用于实现服务器迁移的计算机-服务器关联。此表的 Schema 位于： 

    <WEBLOGIC_HOME>/server/db/<dbname>/leasing.ddl

    其中 dbname 为数据库供应商的名称。

    注意： 租用表应该存储在高可用数据库中。可迁移服务器的可靠程度只能与用于存储租用表的数据库相同。
  2. 设置和配置数据源。此数据源应该指向上一步中配置的数据库。
    3. 注意： 对于服务器迁移不支持 XA 数据源。

    有关创建 JDBC 数据源的详细信息，请参阅“配置和管理 WebLogic JDBC”中的配置 JDBC 数据源。

非数据库租用

在非数据库版本的租用中，WebLogic Server 维护内存中租用信息。这样就消除了拥有高可用性数据库来使用需要租用的功能的需要。

群集中的一个成员选择为群集领导者，负责维护租用信息。该群集领导者根据启动之后的时间长度进行选择。群集中运行时间最长的受管服务器将被选择为群集领导者。其他群集成员会与此服务器通信以确定租用信息，但是租用表会复制到群集的其他节点以提供故障转移。

注意： 此版本的租用需要您使用节点管理器来控制群集中的服务器。节点管理器还应该在群集中承载受管服务器的每台计算机上运行。有关详细信息，请参阅使用节点管理器控制服务器。

 

自动服务器迁移

注意： 并非所有的平台都支持服务器迁移。请参阅“WebLogic Platform 9.2 Supported Configurations”中的 Server Migration。

本部分简要列出了配置服务器迁移的过程，还对 WebLogic Server 环境中服务器迁移的运行方式进行了常规讨论。

包含下列主题：

准备自动服务器迁移

配置服务器迁移之前，首先要了解下列要求：

配置自动服务器迁移

配置服务器迁移之前，请确保您的环境满足准备自动服务器迁移中列出的要求。

要为群集中的受管服务器配置服务器迁移，请执行下列任务：

  1. 为每个要启用迁移的受管服务器获取浮动 IP 地址。

    2. 必须为每个可迁移服务器都分配一个浮动 IP 地址，迁移之后该地址会将服务器从一台物理计算机移动到另一台计算机。分配了浮动 IP 地址的任何服务器的 Auto迁移Enabled 还必须都设置为 true。

    注意： 可迁移服务器启动之前，可迁移 IP 地址不应存在于任何候选计算机的接口上。
  2. 配置节点管理器。节点管理器必须正在运行并且已经配置才能允许服务器迁移。
    3. 注意： 仅支持使用 SSH 版本节点管理器的服务器迁移。

    有关在服务器迁移中使用节点管理器的常规信息，请参阅节点管理器在服务器迁移中的作用。有关配置节点管理器的常规信息，请参阅使用节点管理器控制服务器。

  3. 如果您要使用数据库存储租用信息，则请根据高可用性数据库租用中列出的过程为服务器迁移配置数据库。

    4. 有关租用的常规信息，请参阅租用。

  4. 如果您要使用数据库存储租用信息，则请根据高可用性数据库租用中列出的过程设置和配置数据源。

    5. 您应该在每个群集配置中都将 DataSourceForAutomatic迁移 设置为此数据源。

    注意： 对于服务器迁移不支持 XA 数据源。

    有关创建 JDBC 数据源的详细信息，请参阅“配置和管理 WebLogic JDBC”中的配置 JDBC 数据源。

  5. 确保配置了 wlsifconfig.sh 脚本，以使 ifconfig 具有正确的权限。

    6. 此脚本用于在迁移期间将 IP 地址从一台服务器传输到另一台计算机。它必须能够运行 ifconfig。如果正在用 sudo 调用此脚本，您无需手工编辑此脚本。

    此脚本位于 $BEA_HOME/weblogic92/common/bin 目录中。

  6. 确保 wlsifconfig.sh、wlscontrol.sh 和 nodemanager.domains 包括在了计算机的 PATH 中。.sh 文件位于
    $BEA_HOME/weblogic92/common/bin，nodemanager.domains 位于 $BEA_HOME/weblogic92/common/nodemanager。

    7. 根据默认外壳的不同，您可能需要编辑这些脚本的第一行。

  7. 承载可迁移服务器的计算机必须互相信任。为了进行服务器迁移，必须能够从 machine_B 使用“ssh/rsh machine_A”进入外壳提示，或者从 machine_A 完成上述反向操作，而无需明确输入用户名/密码。另外，每台计算机必须能够使用 SSH 以同样的方式连接其自身。
    8. 注意： 您应该确保登录脚本（.cshrc、.profile、.login 等）只能回送来自外壳配置文件的消息（如果该外壳可交互的话）。WebLogic Server 使用 ssh 命令来登录和回送 server.state 文件的内容。只有此输出中的第一行用于确定服务器状态。
  8. 设置服务器迁移的候选计算机。每个服务器可以有一组不同的候选计算机，它们也可以全部拥有相同的候选计算机组。
  9. 编辑 wlscontrol.sh 并将 Interface 变量设置为您的网络接口名。
  10. 重新启动管理服务器。

对于状态数据使用高可用性存储

服务器迁移过程会迁移服务，但不会迁移与发生失败时正在进行的作业相关联的状态信息。

为了确保高可用性，在迁移之后这样的状态信息仍然可用于服务器实例和它承载的服务这点非常重要。否则失败时正在进行的作业的相关数据就可能会丢失。可迁移服务器维护的状态信息（如事务日志中包含的数据）应该存储在失败的可迁移服务器可能迁移到的任何潜在计算机都能够访问的共享存储系统中。为了获得最高的可靠性，请使用其本身就具有高可用性的共享存储解决方案 – 例如存储区域网络 (SAN)。

另外，如果您要使用数据库来存储租用信息，用于跟踪可迁移服务器的运行状况和开关状况的租用表则也应存储在高可用性数据库中，如下面几部分所述。有关详细信息，请参阅租用。

服务器迁移过程和通信

下面几部分描述了包含可迁移服务器的群集中的主要过程：

带有可迁移服务器的群集中的启动过程

图 7-1，带有可迁移服务器的群集的启动显示了包含可迁移服务器的群集的启动期间发生的过程和通信。

该示例群集包含两个受管服务器，两个都是可迁移服务器。管理服务器和这两个受管服务器都在不同的计算机上运行。第四个计算机可用作其中一个可迁移服务器发生失败时的备用计算机。节点服务器在该备用计算机上运行，也在具有正在运行的可迁移服务器的每台计算机上运行。

图 7-1 带有可迁移服务器的群集的启动

带有可迁移服务器的群集的启动

这些是图 7-1 中显示的群集启动期间发生的主要步骤：

  1. 管理员启动群集。
  2. 管理服务器调用计算机 B 和 C 上的节点管理器以分别启动受管服务器 1 和 2。请参阅管理服务器在服务器迁移中的作用。
  3. 每台计算机上的节点管理器启动在该计算机上运行的受管服务器。请参阅节点管理器在服务器迁移中的作用。
  4. 受管服务器 1 和 2 与管理服务器联系，以获取其配置。请参阅群集中的可迁移服务器行为。
  5. 受管服务器 1 和 2 缓存它们启动时的配置。
  6. 受管服务器 1 和 2 每个都在租用表中获取可迁移服务器租用。因为受管服务器 1 首选启动，所以它还会获取群集主管理器租用。请参阅群集主管理器在服务器迁移中的作用。
  7. 受管服务器 1 和 2 定期更新它们在租用表中的租用，以证明其运行状况和开关状况。

自动迁移过程

图 7-2，失败服务器的自动迁移显示了承载受管服务器 2 的计算机失败之后的自动迁移过程。

图 7-2 失败服务器的自动迁移

失败服务器的自动迁移

  1. 承载受管服务器 2 的计算机 C 失败。
  2. 群集主管理器在下一次定期复查租用表后，检测到受管服务器 2 的租用已过期。请参阅群集主管理器在服务器迁移中的作用。
  3. 群集主管理器尝试与计算机 C 上的节点管理器联系，以重新启动受管服务器 2，但是失败，因为计算机 C 无法访问。
    4. 注意： 如果因为受管服务器 2 挂起它的租用已经过期，并且计算机 C 无法访问，群集主管理器则使用节点管理器重新启动计算机 C 上的受管服务器 2。
  4. 群集主管理器与计算机 D 上的节点管理器联系，该计算机配置为了群集中可迁移服务器的可用主机。
  5. 计算机 D 上的节点管理器启动受管服务器 2。请参阅节点管理器在服务器迁移中的作用。
  6. 受管服务器 2 启动并与管理服务器联系以获取其配置。
  7. 受管服务器 2 缓存它启动时的配置。
  8. 受管服务器 2 获取可迁移服务器租用。

在迁移期间，迁移的受管服务器的客户端可能会感受到短暂的服务中断；可能需要重新连接。在 Solaris 和 Linux 操作系统上，这可以通过使用 ifconfig 命令完成。迁移的服务器的客户端不需要了解该服务器迁移到的具体计算机。

以前承载进行了迁移的服务器实例的计算机重新变为可用之后，反向的迁移过程（服务器实例重新迁移回其原始的主机计算机）称为故障回复。WebLogic Server 不会自动完成故障回复过程。管理员通过手工将服务器实例还原到其原始主机，可以完成故障回复。

将服务器还原到其原始主机的常规过程如下所示：

接下来的具体步骤取决于您的服务器和网络环境。

手工迁移过程

图 7-3，手工服务器迁移显示了管理员手工迁移可迁移服务器时发生的过程。

图 7-3 手工服务器迁移

手工服务器迁移

  1. 管理员使用管理控制台启动受管服务器 2 从计算机 C 到计算机 B 的迁移。
  2. 管理服务器与计算机 C 上的节点管理器联系。请参阅管理服务器在服务器迁移中的作用。
  3. 计算机 C 上的节点管理器停止受管服务器 2。
  4. 受管服务器 2从租用表删除它的行。
  5. 管理服务器调用计算机 B 上的节点管理器。
  6. 计算机 B 上的节点管理器启动受管服务器 2。
  7. 受管服务器 2 从管理服务器获取其配置。
  8. 受管服务器 2 缓存它启动时的配置。
  9. 受管服务器 2 向租用表添加一行。

管理服务器在服务器迁移中的作用

在包含可迁移服务器的群集中，管理服务器：

另外，管理服务器提供了它普通的域管理功能，持久保留管理员发出的配置更新，以及提供域的运行时视图（包括它所包含的可迁移服务器）。

群集中的可迁移服务器行为

可迁移服务器是配置为可迁移的群集受管服务器。下面这些是可迁移服务器的主要行为：

节点管理器在服务器迁移中的作用

服务器迁移要求使用节点管理器 – 它必须在承载或打算承载的每台计算机上运行。

节点管理器以下列方式支持服务器迁移：

群集主管理器在服务器迁移中的作用

在包含可迁移服务器的群集中，一个服务器实例充当着群集主管理器。它的作用是协调服务器迁移过程。群集中的任何服务器实例都可以作为群集主管理器。当您启动包含可迁移服务器的群集时，第一个加入该群集的服务器将成为群集主管理器，它会启动群集管理器服务。如果群集不包含至少一个可迁移服务器，它则不需要群集主管理器，群集主管理器服务也不会启动。如果没有群集主管理器，可迁移服务器可以继续操作，但服务器迁移无法运行。下面这些是群集主管理器的主要功能：

 

JMS 和 JTA 服务迁移

WebLogic Server 支持 JMS 服务器和 JTA 事务恢复服务的服务级迁移。这些称为“可迁移服务”，因为您可以将这些服务从群集中的一个服务器移至另一个服务器。

注意： JMS 使您能够将多个物理目标（队列和主题）配置为一个分布式目标集的组成部分，在发生一个 WebLogic Server 失败时也会提供改善的服务连续性。

WebLogic Server 还支持服务器级的迁移 – 整个服务器实例以及它所承载的所有服务都可自动或者手工迁移到另一个计算机。此功能在了解服务器和服务迁移中描述。

注意： 如果使用数据库维护租用信息，该租用表则应该存储在高可用性数据库中。可迁移服务器的可靠程度只能像用于存储租用表的数据库一样。有关详细信息，请参阅租用。

在 WebLogic Server 群集中，大多数服务都均匀部署在群集的所有服务器实例上，从而实现了从一个服务器到另一个服务器的透明故障转移。相反，单元集服务（如 JMS 和 JTA 事务恢复系统）在任何给定的时间都仅在群集中的一个服务器中运行。

作为服务器失败的响应或者作为定期计划维护的一部分，WebLogic Server 使得管理员能够将单元集服务从群集中的一个服务器迁移到另一个服务器。此功能改善了群集中单元集服务的可用性，因为当主机服务器失败时这些服务可以在冗余服务器上快速重新启动。

JMS 和 JTA 的迁移如何运行

客户端使用可以识别迁移的 RMI 存根控件访问群集中的可迁移服务。该 RMI 存根控件跟踪哪个服务器当前承载着固定服务并将客户端请求进行相应地定向。例如，当客户端首先访问固定服务时，该存根控件会将客户端请求定向到群集中当前承载该服务的服务器实例。如果在后续客户端请求之间该服务迁移到另一个 WebLogic Server，该存根控件则会将请求透明重定向到正确的目标服务器。

当 JMS 服务器和 JTA 事务恢复服务驻留于群集中并针对迁移进行了配置时，WebLogic Server 会为这些服务实现可以识别迁移的 RMI 存根控件。

将服务从不可用服务器进行迁移

当您从已经崩溃或不可用于管理服务器的服务器实例迁移服务时，有一些特殊的注意事项。如果在您执行迁移时管理服务器无法访问该服务以前活动的主机，受管服务器的本地配置信息则不会更新，以反映它不再是该服务的活动主机。这种情况下，您必须在重新启动该不可访问受管服务器之前清除它的本地配置缓存。这样将使得以前活动的主机不会在启动已经迁移到另一个受管服务器时重新激活。

定义群集中的可迁移目标服务器

默认情况下，WebLogic Server 可以将 JTA 事务恢复服务或 JMS 服务器迁移到群集中的任何其他服务器。您可以配置群集中可承载固定服务的服务器列表。此服务器列表称为可迁移目标，它控制着可以将服务迁移到的服务器。对于 JMS，可迁移目标还定义了可以将 JMS 服务器部署到的服务器列表。

例如，下图显示了一个由四个服务器组成的群集。服务器 A 和 B 配置为了群集中 JMS 服务器的可迁移目标。

图 7-4 群集中的可迁移目标

群集中的可迁移目标

在上面的示例中，可迁移目标使得管理员只能将固定的 JMS 服务器从服务器 A 迁移到服务器 B，或从服务器 B 迁移到服务器 A。与之相似，将 JMS 服务器部署到群集时，管理员可以选择服务器 A 或 B 作为部署目标以实现该服务的迁移。（如果管理员不使用可迁移目标，JMS 服务器则可以部署或迁移到群集中的任何可用服务器。）

WebLogic Server 允许您为 JTA 事务恢复服务和 JMS 服务器创建不同的可迁移目标。这就使您能够总是保持每个服务在群集中的一个不同服务器上运行（如果需要的话）。与之相反，您也可以配置相同的服务器选择同时作为 JTA 和 JMS 的可迁移目标，以确保这些服务总是保持共存于群集中的同一个服务器上。

 

自动单元集服务迁移

自动单元集服务迁移实现了单元集服务的自动运行状况监视和迁移。单元集服务是在群集中运行的、在任何给定时间仅在一个服务器上可用的服务。如果由于任何原因（例如，由于服务代码中的错误、服务器故障或网络故障）导致可迁移服务失败或不可用，则该服务将在其当前位置停用，并在一个新服务器上激活。将这些服务迁移到另一个服务器的过程是通过迁移主管理器处理的。请参阅迁移主管理器。

WebLogic Server 支持用户定义的单元集服务的自动迁移。

注意： 尽管 JMS 和 JTA 也是在任何时间仅可在一个群集节点上可用的单元集服务，但它们不自动迁移。它们必须手工迁移。请参阅JMS 和 JTA 的迁移如何运行。

单元集服务迁移概述

本部分概述了自动单元集服务在WebLogic Server中是如何实现的。

迁移主管理器

迁移主管理器是监视可自动迁移的其他服务的轻型单元集服务。当前承载迁移主服务器的服务器负责启动和停止与每个可迁移服务相关的迁移任务。

注意： 可迁移服务不必和迁移主管理器部署在同一个服务器上，但它们必须部署在同一个群集中。

迁移主管理器的运行方式与群集主管理器的运行方式相似，它也由租用竞争维护，在某个时间仅在一个服务器上运行。群集中的每个服务器都会不断尝试注册迁移主管理器租用。如果当前承载迁移主管理器的服务器失败，队列中的下一个服务器则会承担该租用，开始承载该迁移主管理器。

有关群集主管理器的详细信息，请参阅群集主管理器在服务器迁移中的作用。

注意： 迁移主管理器和群集主管理器独立运行，不需要承载在同一个服务器上。

承载迁移主管理器的服务器维护着执行的所有迁移的记录，其中包括目标名、源服务器、目标服务器和时间戳。

迁移失败

如果单元集服务的迁移在群集中的每个候选服务器上均失败，该服务则会处于停用状态。您可以对迁移主管理器在群集中的服务器之间进行迭代的次数进行配置。

注意： 如果不明确指定候选服务器列表，迁移主管理器则会将所有群集成员都视为迁移的可能候选。

实现单元集服务接口

在应用程序中，您可以定义可用于执行希望在某个给定的时间只在一个群集成员上执行的任务的单元集服务。该单元集服务将实现为应用程序中的类，配置为应用程序所部署于每个服务器上的部署描述符的一部分。但它在任何时间都只在一个服务器上活动。

要在应用程序中创建单元集服务，除了希望该单元集执行的任何任务之外，您还必须创建实现 weblogic.cluster.singleton.SingletonService 接口的类。

该 SingletonService 接口包含迁移过程中使用的下列方法。

创建实现 SingletonService 接口的类之后，您应该确保创建用于部署的 .war 文件时此类在 APP-INF/lib 或 APP-INF/classes 目录中可用。

部署和配置自动服务迁移

创建了实现 SingletonService 接口的应用程序之后，必须执行下列步骤来部署该应用程序并将其作为单元集服务运行：

  1. 将该应用程序部署到群集。
  2. 在 WebLogic Server 中定义单元集服务。
  3. 配置该单元集服务的迁移行为。

下列部分详细列出了这些过程。

将应用程序部署为单元集服务

尽管单元集服务在某个时间只在一个群集成员上活动，但您必须将应用程序部署到将作为迁移的单元集服务候选目标的每个群集成员上。

将应用程序部署到群集中的所有候选服务器之后，将下列条目添加到部署的每个应用程序实例的 weblogic-application.xml 中。 

<weblogic-application>
...
   <singleton-service>
      <class-name>mypackage.MySingletonServiceImpl</class-name>
      <name>Appscoped_Singleton_Service</name>
   </singleton-service>
...
</weblogic-application>
注意： <class-name> 和 <name> 元素是必需的。

在 WebLogic Server 中定义单元集服务

创建并部署了应用程序之后，必须在 WebLogic Server 中定义单元集服务。

此单元集服务对象包含下列信息：

单元集服务对象的作用就好像迁移主管理器和部署的应用程序代码之间的链接。config.xml 中 cluster 元素的下列节选显示了如何定义单元集服务： 

<SingletonService
   Name="SingletonTestServiceName"
   ClassName="mycompany.myprogram.subpackage.SingletonTestServiceImpl"
   Cluster="mycluster-"
/>

配置自动服务迁移

您可以使用下列方法配置自动服务迁移的行为：


  返回顶部       上一页  下一页