做好准备 › 版本说明 › 已知问题 › 重要说明

重要说明

1. ALD 不再用于安装/升级网格并导入目录和应用。 代替 ALD 的是 Backbone Fabric Controller (BFC)。 BFC 是一种简单易用且基于 Web 的 GUI 应用，用于在单个主干内创建和管理所有 CA AppLogic 网格。 有关如何下载/安装 BFC 以及如何使用它来管理 CA AppLogic 网格的信息，请参见 BFC 文档。 要将目录和应用导入您的网格（例如，CA AppLogic 附带的 system_ms），请将目录/应用复制到您的网格的 impex 卷，并使用 cat 导入和 app 应用导入 CA AppLogic 命令。
2. 除 Xen 之外，CA AppLogic 3.x 现在还支持 VMWare ESX Hypervisor。 当 CA AppLogic 3.x 保留这两个 Hypervisor 的所有特性和功能时，在将 VMWare ESX 与 CA AppLogic 结合使用时，存在一些特定的 VMWare ESX 重要用法事项：
   • 与 Xen 相比，ESX 有一个更受限制的硬件兼容性列表。 请确保在使用 CA AppLogic 3.x 之前验证您的服务器是否位于 ESX 硬件兼容性列表中。 选择用于基于 ESX 的网格的硬件必须针对 ESX、CA AppLogic-Xen（在以上硬件兼容部分中指定）和 CentOS 5.5 的 HCL 进行验证。
   • 对于负载较重的网格，使用 ESX 在某些操作方面会比使用 Xen 时慢。 这是因为 CA AppLogic 使用 ESX API 来控制每个服务器上的虚拟机；与使用 Xen API 相比，这些 API 在 ESX 上的速度比较慢。 以下是其中观察到速度比较慢的值得注意的操作：
     • 启动应用－在负载较重的网格上启动组件时所用时间要延长至 1-2 分钟
     • 网格信息、srv 列表、srv 信息－在负载较重的网格上获取这些信息时所用时间要延长几秒或 1-2 分钟
   • 与 Xen 相比，ESX 的内存开销更多。 适用于基于 Xen 的网格上的 2 个服务器的某应用可能不完全适用于在 CA AppLogic 基于 ESX 的网格上运行的 2 个相同服务器。 这就是为什么建议基于 ESX 的服务器至少有 4-8 GB 的内存。
   • 支持 ESX 的组件：
     • 所有组件必须安装 vmware 工具（默认情况下，CA AppLogic 3.x 附带的所有组件都装有 vmware 工具）。 需要 vmware 工具以便确保图形控制台能够正常运行，并且组件能够及时关闭。 如果未安装 vmware 工具，图形控制台使用起来将比较困难（鼠标光标将难以控制），关闭组件将花费 15 分钟。
     • 在使用 Windows 组件时，组件在存储在组件描述符中的虚拟化选项字符串中必须有正确的 esx_os_name 设置。您可以为您的 Windows 组件更新设置。 如果使用 iso2class 安装新的 Windows 组件，在为该新的组件设置正确的 esx_os_name 设置时会使用强制性的命令行参数。
     • 要重新启动组件，请使用 comp 重新启动或重新启动应用。 从组件自身重新启动它将导致组件启动失败（组件将无法从 CA AppLogic 中检索其配置）。
     • volfix 配置模式不适用于运行于 ESX 的组件。 组件需要转换为使用 dhcp 配置模式。 这仅会影响 CA AppLogic 2.1 和更早版本中的较旧组件。您可以将组件转换 (如何升级应用以使用新的组件工具包 (APK), 升级组件以使用 DHCP 配置模式)为使用 dhcp 配置模式。有关如何将组件转换为使用 dhcp 配置模式的信息，请参阅《组件开发人员指南》中的“组件工具包”一节。
3. CA AppLogic 3.x 引入了基于角色的访问控制 (RBAC)。 RBAC 提供向对象（应用模板、应用实例、目录或网格）授予权限（或控制对象）的功能。 默认情况下，在网格上创建新用户时，该用户对网格的对象具有有限的访问权限。 例如：默认情况下，用户对网格没有登录权限。 您需要配置适当访问权限 (用户和组管理, RBAC 概述)以让用户访问网格。
4. 在使用 Web API 访问 CA AppLogic 3.x 网格时，Web API 应用必须配置给对网格具有 full 访问权限（管理员类型的访问权限）的用户。
5. 在 CA AppLogic 3.x 中，对组件的操作系统支持没有先前的 CA AppLogic 版本广泛。 在 3.x 中，根本不支持 Solaris 10，仅对于 Xen 才支持 OpenSolaris。 请注意，OpenSolaris 和 Solaris 10 目前被 Oracle 停用，且要替换为 Solaris Express 和 Solaris 11。

   注意：自 CA AppLogic 3.5 开始，已删除所有基于 Solaris 的组件（不包括 Solaris filer）。 如果您需要这些组件，请联系 CA Support。

6. CA AppLogic 与操作系统无关，旨在与不同的操作系统配合使用。 作为其设计的一部分，所有卷操作（创建/格式化、复制、调整大小、文件系统检查/修复和管理）都在名为 filer 的 CA AppLogic 应用内执行；它们不再与先前版本的 CA AppLogic 一样由 CA AppLogic 网格控制器执行。 这样，这些新的 filer 应用就像任何其它的常规 CA AppLogic 应用一样在网格上使用资源。 因此，在网格上必须有足够可利用资源才能执行所有的 CA AppLogic 卷操作。 请注意，filer 应用不适用于原始卷或块级卷副本。
7. 网格控制器使用核心（对于基于 ESX 和基于 Xen 的服务器）的 10%。
8. 因为所有卷操作现在均使用 filer 应用来执行，与先前的 CA AppLogic 版本相比，所有卷操作的速度较慢，因为 filer 应用必须作为卷操作的一部分来启动/停止。 通常，基于 Linux 的卷操作大约花费 20 秒，基于 Solaris 的卷操作大约花费 130 秒。
9. 网络带宽资源用法已在所有组件上实施。 组件使用的带宽将不能多于为其所有终端配置的带宽（分配的带宽将所有终端都考虑在内）。 确保为组件和应用配置的带宽满足带宽使用情况需求（否则在应用中可能会出现非常差的网络性能）。 每个 CA AppLogic 服务器的最大带宽是 2 Gb。
10. 经历网络流量传送后的组件（如网关、负载平衡器和端口交换机）的带宽实际上减少了一半。 例如：分配了 100M 带宽的负载平衡器实际上只有 50M（由于网络流量传入和传出组件）。
11. 在新安装或升级的 CA AppLogic 网格上访问 CA AppLogic GUI 之前，用户应清除浏览器的缓存。 如果不清除浏览器的缓存，CA AppLogic GUI 可能不能正常运行。
12. 可通过 Web 浏览器或使用 ssh 客户端访问网格 shell。 为了加强安全，除网格安装期间外，不再支持基于密码的 ssh 登录。

    重要信息！ 强烈建议您使用随 CA AppLogic GUI 提供的 Web shell。

13. 在通过 ssh 访问网格时，登录用户名始终是 root，与 CA AppLogic 用户名无关。 为了 ssh 登录，用户及其角色由公共 ssh 密钥唯一标识。
14. 必须启用 Web 浏览器的 Javascript 和弹出式菜单才能使用基于 Web 的图形用户界面（显示板、编辑器、文档）
15. 用户负责分配、指定和使用应用的外部可见 IP 地址；CA AppLogic 负责处理所有内部网络分配情况
16. 尽管 Backbone Fabric Controller 使用预先仔细配置的防火墙设置所有网格服务器和控制器并禁用不必要的网络服务，我们还是鼓励用户和维护人员验证其系统的安全设置。
17. 专用网络上服务器之间用于卷和组件间通信的的网络性能测定大约为 900 Mbps。 位于不同服务器上的组件之间的 TCP 网络性能测定为 720-900 Mbps。 在运行 Windows 时，TCP 网络性能大约为 940 Mbps，UDP 网络性能大约为 500-700 Mbps。
18. 对于不同类型的资源（CPU、内存、带宽），组件硬件资源的资源限制实施的方式不同。 CPU 是“不少于”，内存是“精确达到”（包括 VM 开销），带宽是“精确达到”。 启动应用时，可能使用 new --cap_cpu 选项以“精确达到”方式实施 CPU 资源。
19. 以指定的最小 CPU 量启动应用时，不保证应用能确切获得指定的 CPU 量。 例如：如果应用在启动时 cpu=2，在将所有分配的 CPU 添加到该应用的所有组件后，可能会看到该应用获得 1.97 CPU。 这可能是由于在尝试将 CPU 分配给各个组件时发生了舍入误差。
20. 在应用启动失败时，可能不会在 shell 中显示与此失败相关的所有消息。 使用 list log n=20 命令查看网格日志的其他信息。
21. 在构建性能线性扩展占重要地位的网格时，应使用 CPU 类型/速度、内存大小和磁盘容量方面都尽可能一致的服务器。 CA AppLogic 可在由具有不同硬件资源数量的服务器组成的网格中正常运行，但在此类网格中，性能可能会不够线性。
22. 在由于网格控制器 VM 故障而重新启动网格控制器期间，不具有用户可见性。 如果网格控制器 VM 出现故障且 CA AppLogic 重新启动了网格控制器 VM，则在控制器重新启动期间，不具有用户可见性。 通常，网格控制器会在 1 到 2 分钟内自行重新启动。 如果网格控制器超过 5 分钟不可用，请联系 CA Support。
23. 创建 NTFS03 卷时总生成 NTFS08 卷。 NTFS08 卷可与 Windows 2003 Server 配合使用。
24. 基于 ESX 的网格/服务器不支持网格和服务器的 net_discover 命令。
25. 在将 SAN 与您的 CA AppLogic 网格配合使用时，请确保对于使用配置的 NFS 共享的每个网格，至少有 500 GB 可用空间。 例如，如果要将 NFS 共享用于五个不同的网格，共享应当有 2.5 TB 的可用磁盘空间。
26. 在将 SAN 与您的 CA AppLogic 网格配合使用时，如果 SAN 或 NFS 共享在任何时间段内脱机，在使用中的一些卷可能会损坏。 如果此损坏使网格控制器无法运行，或导致应用无法启动（或任何其他网格或应用不稳定），请立即联系 CA Support。
27. 要使用基于最新操作系统分发（如 Fedora Core、Ubuntu、Debian 和 CentOS）的 CA AppLogic 组件，请在组件边界上配置新现场工程代码 128。 这个新现场工程代码指示 CA AppLogic 为专用于这些新分发的组件卷使用新的设备名称样式。 如果未指定现场工程代码 128，基于这些新分发的组件将无法启动。
28. 如果主数据库或副本 BFC 数据库丢失或损坏，那么从 3.1 版本的 BFC 开始，您可以从总是正在运行的自动备份来进行恢复。 这些备份实际上位于主数据库的子目录，因此它们不是用于配置副本的代替者。 （如果配置了一个，那么这些备份也被写入副本的子目录。）从最新的备份还原：
    • 所有活动网格操作完成之后，请等待两分钟，以确保备份为最新。
    • 以根用户身份登录到 BFC 系统。
    • 运行 /bin/db_restore（默认情况下将为 /opt/bfc/bin/db_restore）。 db_restore 实用工具将停止 BFC（如果仍在运行），从最新的备份还原数据库，然后重新启动 BFC。