|
|
|
本节介绍当前的已知问题和限制。
这意味着组件只能与所连接的组件（及其自身的服务器和网格控制器）进行交互。 不过，应在新组件上指定相应的协议，以确保 CA AppLogic 的未来版本中应用设计的完整性和兼容性。
grid info 命令所报告的总可用磁盘空间是一个原始估算值，未将卷镜像考虑在内。 实际的可用磁盘空间是报告的可用空间量除以镜像数（默认情况下为 2）所得到的值。 例如：如果有 1000 GB 的可用磁盘空间，网格配置为 2 个镜像，则可用的磁盘空间为 500 GB。 此外，为了成功镜像卷，必须至少在 X 个服务器上有足够的磁盘空间，其中 X 是镜像数（即使 CA AppLogic 无法创建其中任何一个镜像，但仍会创建卷，并显示无法镜像卷的警告）。
如果启动了某个应用，且网格的其中一个服务器出现故障，则当该应用的一个或多个组件排定在出现故障的服务器上运行时，该应用将无法启动。 如果发生此情况，只需重新启动应用即可。
要将更大的文件上传到卷，请使用 vol manage shell 命令；请不要忘记为此命令指定外部 IP 设置，以便从卷管理器内部进行远程访问。 有关详细信息，请参见 vol manage 命令参考。
CA AppLogic 确实支持从基于 zfs 的启动卷启动 OpenSolaris 组件。 但请注意，此行为未经过 CA 验证，可能不起作用。 Solaris 10 不支持 zfs。
当前，仅支持单设备 zfs 池。 为了在 CA AppLogic 中充分利用所有 zfs 功能，用户可以在其组件内部装配自己的 zfs 池。 如果某个 zfs 池要用于镜像，在创建该池中使用的 CA AppLogic 卷时应禁用 CA AppLogic 镜像（在创建卷时使用 mirrored=0 选项）。 此外，使用 CA AppLogic Solaris filer 创建的 zfs 池将不能在 Solaris 10 中运行。 有关所有 CA AppLogic 操作系统限制，请参见《组件开发人员指南》。
如果您需要大容量存储，请使用不同的文件系统。
新的 dhcp 配置模式不支持组件配置的属性标记。 在将组件从 volfix 配置模式转换为 dhcp 配置模式时，APK 文档介绍了如何处理依赖组件配置属性标记的组件。 有关详细信息，请参见组件工具包 (APK)。
要看到应用的验证标记，请以编辑模式打开应用。 验证标记用于标记未正确配置所有强制性属性/终端/卷的组件。
在安装过程中，iso2class 可用于使用图形控制台安装 Solaris 10 组件。 但是，在完成安装并重新启动组件后，图形控制台仍然可用，但必须以文本模式使用（不能访问 Solaris 10 桌面－严格基于文本的访问）。 这是由于 Solaris 10 GUI 的问题（不是 CA AppLogic 缺陷）。
因此，图形控制台不能与这些组件一起使用。 这是有意设计的，是为了使组件尽可能地紧凑。 使用新的 iso2class 实用工具，用户可以自己创建具有完全桌面支持的组件。
此错误是由于 CA AppLogic 将组件的计算机名称设置为实例名称而导致的。 因此，如果在网格上运行的多个组件具有相同的实例名称，则在 Windows 的图形控制台中会显示重复的名称错误。 此错误只是个警告，并不影响网格或其操作。 但是，如果需要使用 Windows 作为域控制器，则需要为每个组件将计算机名称设置为唯一的名称。 您可以使用 wincfg 实用工具在您的组件中设置计算机名称。
我们已经在 IE/FF/Chrome/Safari 上测试过 Java 6 update 7 版本。 如果未使用最新的 Java 版本，图形控制台可能无法正常运行（将在试图加载时挂起）。 在将图形控制台错误报告给 CA 之前，请务必确认您使用的是最新的 Java 版本（如果您需要在浏览器中升级 java，随后一定要重新打开浏览器，以使图形控制台正常工作）。
在备用服务器成为新的主服务器时，如果该服务器上没有足够的资源来启动网格控制器，则 CA AppLogic 会在网格中的其他服务器上重新启动新主服务器上运行的组件，这样即可从新主服务器上启动网格控制器。 请注意，这可能会中断组件故障转移组。 如果 CA AppLogic 停止这些组件之一，则可能无法在其他服务器上重新启动该组件，因为可能没有足够的资源来满足故障转移组。
所有基于 HVM 的组件（Solaris 10、Windows 等）所使用的服务器内存大于所配置的内存。 通常，根据分配给基于 HVM 的组件的内存量，组件会使用组件运行所在的服务器的附加内存（此附加内存是服务器上运行的虚拟 Hypervisor 所需的内存，称为影子内存）。 因此，尽管与分配给组件的内存相比，服务器可能有足够的内存，但组件可能无法在该服务器上运行，因为服务器上可能没有基于 HVM 的组件所需附加影子内存。 在应用启动期间，CA AppLogic 排定程序在排定组件时会将此附加卷子内存考虑在内。
在使用 10G 的主干时，不同服务器上运行的组件之间可达到的最大吞吐量约为 2Gbps（可能是由于 CA AppLogic 使用的 Hypervisor 中的某种限制）。
可以使用任何其他浏览器。
共享接口应与所有其他操作系统一起使用。
下面是此版本中的已知问题：
在没有启用写缓存的情况下，使用 HP Smart Array RAID 控制器时，会减少 50% 的性能。 此问题已经在带有 Smart Array P410i 256mb 的 HP DL 580 G7 服务器上经过检验。 这些卡需要安装启用写缓存的电池或电容器。
在使用 ServerEngines Corp. Emulex OneConnect 10Gb NIC (be3) (rev 01) NIC 和 CA AppLogic 时，如果启用“SR-IOV BIOS”选项，那么这些 NIC 会不正确地退回数据包。 这些退回的数据包改变桥的转发缓存，导致桥丢弃数据包，而不是将他们转发给正确的目标。 这在 CA AppLogic 中引起不稳定性，导致间歇的应用启动失败。 因此，请确保对于网格中所有服务器上的所有 Emulex 10G NIC， SR-IOV BIOS 设置为禁用。
在使用 10G 主干时，运行在不同服务器上的组件之间可实现的最大吞吐量约为 2.5 Gbps（您可根据正在使用的 10G 硬件类型看到不同的结果）。 CA 当前正在研究几个网络优化项目（如启用巨大框架），可能在将来 CA AppLogic 版本中启用，以便增强 10G 网络性能。
应用极少会由于其中一个服务器上的卷挂接阻塞而无法启动。 CA AppLogic 会检测阻塞的卷挂接并通过网格显示板将其报告给用户。 如果您的网格上发生此问题，请通知 CA Support。 或者，可以通过禁用或重新启动发生挂接阻塞的服务器来解决此问题。
如果发生这种情况，重新启动主服务器会将网格还原为操作状态。
VDS：安全漏洞：初始用户/密码设置
如果使用 Microsoft Internet Explorer 6 或 7 访问 CA AppLogic GUI，在打开应用进行编辑或打开 Web shell 时，GUI 会泄漏内存（其中每项操作泄漏 5-20 MB 系统内存）。 建议每隔几小时关闭并重新打开一次浏览器，以解决内存泄漏问题。 也可以使用 Firefox、Chrome 或 Safari 来代替 Internet Explorer。
当网格控制器上的负载较重时，GUI 不再自动注销用户。 相反，用户会收到一条消息，指出发生网络错误。 但是，在这种情况下，GUI 仍正常运行。 仅当控制器上存在较重负载时（时启动 4 个应用和复制大型卷），才会收到网络错误消息。 在大型网格中，请尝试将多达整个 CPU 核心和 1 GB RAM 的内存分配给控制器。
如果使用 grid reboot 命令来重新启动网格，则网格在重新启动之后恢复正常时，一个或多个系统卷可能会降级。 CA AppLogic 会首先自动修复这些卷。
在迁移卷时，请确认其中至少一个数据流位于启用的服务器上，否则无法执行迁移命令。 可通过操作两次将卷从其原始服务器组中完全迁移出来。
一些物理服务器在重新启动时可能会花费很长时间－这可能导致 CA AppLogic 的网格自动恢复失败。 此问题的最终结果是在网格从故障状态恢复后，有些应用可能无法自动重新启动。 这是因为，网格控制器最多留出 10 分钟来等待所有服务器重新启动并重新连接到网格控制器（这些时间对于重新启动所有服务器来说是不够的）。 解决方法是，在所有服务器均已重新连接到网格控制器之后手动重新启动应用－执行“list srv”可帮助确保所有服务器均连接到了网格控制器，它们应处于 UP 状态。 在 CA AppLogic 2.1 中，服务器启动超时为 10 分钟，如果由于硬件或 BIOS 故障导致服务器无法启动，通常会发生此问题。
在操作员重新启动网格时，网格振荡状态理应重置，并且会在显示板上应显示一条消息，指出操作员有意重新启动网格（“操作员已重新启动网格...”）。 有时，在重新启动网格时，既不重置网格文件，也不显示显示板消息。 这可能引起的唯一问题是，下一个网格失败时应用可能不自动重新启动（取决于出现该缺陷时，网格已失败的次数）。 解决该问题的方法是，如果在有意重新启动网格之后，没有显示显示板消息，请联系 CA Support以重置网格上的网格振荡状态。
资源稍微减少的原因与服务区域的分配有关。 对于内存，可能是由于与虚拟机的内存映射表相关的 XEN 所致。 对于磁盘，是由于常规文件系统服务区域所致（这与在常规 Linux 服务器上一样）。
在这种情况下，该应用未由任何其他用户打开进行编辑，但是 CA AppLogic 编辑器会错误地认为有其他用户打开该应用进行编辑。 如果发生该问题，只需在编辑器打开应用出现提示时直接覆盖该应用锁。
速度减慢的时间主要发生于在 CA AppLogic 应用编辑器中打开应用时。
如果客户端使图形控制台打开并且它们失去与 Internet 的连接（客户端网卡故障、客户端计算机崩溃、Internet 访问不可用等），则重新打开图形控制台将需要 15 分钟。
在使用 CA AppLogic 图形控制台时，鼠标很难在 Ubuntu 中使用。 这是由于 XEN VNC 支持的限制（不支持鼠标加速）。 一些用户报道称，调整 Ubuntu 中的鼠标设置可解决该问题。 此外，在文本中通过键盘键入内容时，很少会重复多次键击操作（在此情况下，只需删除显示的额外字符）。
这包括登录到组件时输入的密码。 文本启动控制台应仅用于调试目的。 可使用 SSH 控制台来实现所有其他目的。
如果用户在组件的文本启动控制台打开之后又重新将其打开，他们必须按 Enter 键才能看到登录提示或命令提示符。 这是因为启动控制台正在等待用户输入（登录信息或要执行的命令）。
如果网格具有故障转移组中的组件，且该故障转移组在需重新启动其网格控制器的备用服务器上运行，则 CA AppLogic 可能会停止会损坏故障转移组的该组件。
将网格升级到最新版本之后，会发布显示板消息，指出网格由于硬件问题而失败。 该消息可安全忽略并从显示板中删除。
组件工具包 (APK) 当前不适用于 Ubuntu 9.10 或 10.x，因为该工具包与较新的操作系统之间存在多种不兼容性。 但是，CA AppLogic 论坛中有许多帖子介绍如何将一些较新的操作系统分发与 CA AppLogic 结合使用。
如果将网络 HA 配置用于 CA AppLogic，并出现外部网络故障，则使用外部接口的应用/组件可能有长达 5 分钟的时间不可访问。 这可能起因于缓存 MAC 地址的外部路由器。 等待路由器刷新其 ARP 缓存，或通过应用还原操作同时发送 ARP 响应和 arping。 这仅影响外部网络（主干网不受影响）。
Solaris 10 不能在适用于 Xen 和 ESX 服务器的 CA AppLogic 3.x 上运行。
OpenSolaris 仅在基于 XEN 的服务器上工作。
恢复 GUI 仅在基于 XEN 的服务器上工作。
共享接口不支持组件计数器。
用户对网格重新加电时，系统启动时间不会重置。 如果重新启动网格，应重置系统启动时间。
如果用户使用网格 power_cycle 命令重新加电网格，主服务器则可能无法重新启动。 这仅在新网格安装之后执行该命令且在执行重新加电命令之前，从未重新启动该网格时发生。 在新的网格安装之后在某一时重新启动网格将避免该问题的发生。
如果在网格运行时更改 NFS 共享大小，直到网格重新启动，CA AppLogic 才会检测到该更改。 此问题将在未来的版本中得到解决。
在使用 SAN 的网格被销毁时，CA AppLogic 会删除该网格在 SAN 上的文件夹的内容，但保留空文件夹。 此问题将在未来的版本中得到解决。
使用 H200 RAID 卡的基于 Dell 的服务器无法与 CA AppLogic 一起使用。 此问题将在未来的版本中得到解决。
解决该问题的方法是在使用 Dell 服务器创建网格之前，在该服务器上启用硬件 RAID。
无法使用 iso2class 安装基于 RedHat 5.3 的组件。 此问题将在未来的版本中得到解决。
（非常少）从 3.0 或 3.1 升级到 3.5 可能会失败。 在此特殊的升级失败情况下，使用 BFC 访问的网格状态日志（单击网格状态即可打开日志）中将存在下列消息。
installing the controller image（正在安装控制器映像） ioctl: LOOP_SET_FD: Device or resource busy（ioctl：LOOP_SET_FD: 设备或资源忙碌） installing new controller FAILED, aborting（安装新控制器失败，正在中止）
如果日志中存在这些消息，请重新运行升级，应该会成功。
注意：此问题实际上是 CA AppLogic 3.0 和 3.1 中的缺陷，并且在 CA AppLogic 3.5 中已得到解决。
对于基于 ESX 的网格，回滚命令对于从 3.5 到 3.1 的回滚不起作用。 但是，作为变通方法，可以使用降级命令（请注意，降级花费的时间比回滚稍微长一些）。 此问题将在未来的版本中得到解决。
基本 ext3-snapshot 的卷在基于 ESX 的网格上不起作用。 不过，这些卷适用于基于 XEN 的网格。 如果您正在使用基于 ESX 的网格，并且您需要使用 ext3-snapshot 卷，您可以将基于 XEN 的节点添加到网格中，并且使用该节点来创建/管理您的 ext3-snapshot 卷（在运行卷命令时，禁用所有的 ESX 服务器，以使 CA AppLogic filer 在基于 XEN 的节点上运行）。 此问题将在未来的版本中得到解决。
在配置为使用外部 SAN 的网格上，尝试迁移本地 SAN 上的卷流可能会失败。 CA AppLogic 不是将卷流迁移到本地 SAN，而是错误地试图将其迁移到外部 SAN。 如果遇到此类故障，请对 vol migrate 命令使用 store=local 选项。 此问题将在未来的版本中得到解决。
将 CA AppLogic 从 3.0.30 升级到 3.5.x 时，网格控制器间歇性挂起，执行的所有 3tshell 命令返回内存不足错误消息。
要解决此问题，请重新启动网格控制器。 此问题将在未来的版本中得到解决。
在某些 Broadcom NIC（特别是 NetXterme II BCM5709/5716）上，NIC 驱动程序报告的链路速度为 100Mb/s 或 10Mb/s。 因此，CA AppLogic 安装失败。
要解决此问题，请尝试重新安装。 此问题将在未来的版本中得到解决。
安装在网格控制器上的 OpenSSH 版本将并发多路复用 ssh 会话数限制为 10。 因此，如果执行的异步请求超过 10 个，API 会放弃这些请求。
要解决此问题，请确保同时向 API 发送的异步请求不超过 10 个。 此问题将在未来的版本中得到解决。
如果重命名组件集或组件接口，应用编辑器将无法完整加载。 此问题将在未来的版本中得到解决。
在具有这些 Nic 的服务器上，创建网格之后，srv info srvX –extended 的输出显示的 Nic 状态为“活动-关闭”。 已将此问题确定为硬件引起的问题。 要解决此问题，请登录到各个交换机，关闭并再次启用 srvX 上 Nic 的端口。 此时显示的状态应该是“开启”。 此问题将在未来的版本中得到解决。
据观察，在具有 Broadcom NetXtreme II 57711 (bnx2x) 10Gbe nic 的 Dell PE R710 服务器上，因 BFC 未能发现服务器而导致安装失败。 这是硬件引起的问题，将在未来的版本中解决。
下面是该版本中与 Windows 组件相关的主要已知问题： 此外，有关其他过程和注意事项，请参见“Windows 组件安装参考”。
在使用 CA AppLogic 3.5 附带的新 Windows APK 时，64 位 Windows Server 2003 DataCenter 版本可能偶尔无法在基于 Xen 的网格上启动。 如果遇到此问题，重新启动组件可解决问题。 此问题将在未来的版本中得到解决。
如果源卷包含损坏的目录条目/文件，Windows filer 可导致卷调整大小操作失败。 该问题的主要来源是一些 Microsoft 软件安装特意包含无效目录条目（我们不确定其原因；在用户在其组件中安装 Microsoft SQL Server 版本时，已发现该问题）。 另外，由于自然磨损也会导致源卷损坏。 在调整卷的大小之前，可通过在卷上运行文件系统修复 (vol fsrepair) 来解决该问题。
CA 已发现在 NTFS 卷调整大小的 100 次操作中大约有 2 次会失败。 这两次失败发生的原因是 Windows filer 无法在网格上正确启动。 如果发现该问题，再次重复执行调整大小操作应当成功。 但是，该问题在该版本中应当已解决；如果发现该问题，请通知 CA 技术支持。
Windows filer 使用名为 diskpart 的 Microsoft 实用工具来处理 Windows NTFS 卷。 有时，diskpart 无法获得卷信息或可能无法挂接卷。 这是非常罕见的故障，并导致执行卷创建或卷调整大小命令以故障转移 NTFS 卷。
如果用户具有一个包含 Windows 组件的应用，且将一个或多个 Windows 组件添加到该应用或向/从 Windows 组件中添加/删除终端，则在首次启动该应用期间，其中一个 Windows 组件可能在内部网络上检测到重复的 IP（仅在修改应用后首次启动该应用期间才发生该问题）。 该问题不应导致应用的任何操作失败或需要用户干预；重复的 IP 地址纯粹是临时的。 最坏的情况是一些涉及任何 Windows 组件的网络通信可能会最多延迟 30-60 秒。
在尝试停止 Windows 应用的进度达到 99% 时挂起；该操作在 15 分钟之后超时。 应用包含 2 个 Windows 2003 Server DataCenter Edition 组件实例 (WIN03DC)。 停止其中一个 Windows 组件，另一个组件会在执行 comp stop 期间挂起。 该问题仅出现过一次且不会再现。
有时，Windows 组件的以下磁盘 I/O 计数器值会报告为零（即使生成持续的 I/O）：写入/读取的总字节数、写入/读取的卷数和写入/读取花费的时间。 这是由 Windows perfmon API 中的缺陷所致－零值是由 Windows perfmon API 报告的。
除 filer MSI 之外，本地化为日语版本的 Windows 应适用于 CA AppLogic。
如果安装 MagicISO 虚拟 DVD-ROM 设备，则 Windows 组件会无法启动。 对于 CA AppLogic 中基于 Windows 的组件，当前不支持虚拟 DVD-ROM 设备。
有时，Windows 在组件内检测新 NIC 会花费几分钟。 当用户为 Windows 组件单例添加/删除终端时，会发生该问题。 在检测这些新的 NIC 时所用的额外时间会导致组件启动超时。 要解决该问题，请增加 Windows 组件的启动超时时间。
如果用户在其网格上具有 Windows 组件，并且他们将该组件迁移到具有不同硬件的其他网格，Windows 组件可能需要重新激活（Microsoft 的 Windows 重新激活）。 在更改特定量的硬件时会触发重新激活（CA 尚未准确了解哪些硬件更改会触发重新激活）。 请注意，执行重新激活可能需要从 Windows 组件内部访问 Internet。 在调整 Windows 组件启动卷的大小和将组件迁移到不同网格之后会出现这个特殊问题。
该问题仅影响 Windows 2008 Server 32/64 位（Windows 2003 Server 运行正常）。 在通过 filer 或 SSH 访问 Windows 2008 卷的组件时，用户可能由于权限问题而不能访问/修改文件。 要通过命令 shell 访问/修改文件，请通过图形控制台登录到 Windows 桌面并打开命令 shell。 命令 shell 可用于访问/修改文件。
Windows 2003 Server 在安装期间首次启动时超时。 确保按照 Windows 提供的说明解决该问题。
在安装 Turbogate PV 驱动程序时，运行在基于 Xen 的网格服务器上的组件第一次启动时，用户必须手动单击硬件安装向导，为该组件中配置的所有终端安装 Turbogate PV 驱动程序。 否则，该组件将无法启动。
在创建新的 32/64 位 Windows 2003 服务器组件时，该组件将仅在网格服务器（使用最初创建该组件的相同 Hypervisor）上工作。 否则，该组件在启动过程中崩溃。 例如，如果该组件最初在基于 ESX 的网格服务器上创建，那么该组件仅可以在基于 ESX 的网格服务器上使用（使用基于 XEN 的网格服务器上的组件将不会起作用，该组件将在启动过程中崩溃）。
这是 Microsoft Windows 2003 服务器的已知问题。 Microsoft 有解决方案来解决您的 Windows 2003 组件的这个问题。
以下问题列表已在 CA AppLogic 版本 2.4-3.x 中出现，但很难再现，仅出现一次或两次。 如果其中任何问题在网格上出现，请将缺陷报告发送给 CA 并描述发生了什么问题，执行了哪些 CA AppLogic 命令导致的此故障。
网格中的服务器由于处于其 dom0 中的 Linux 内核崩溃而自行重新启动。 这不会像先前的 CA AppLogic 版本那样导致整个网格失败；但会导致应用停机。 在此情况下，CA AppLogic 会在网格中的其他服务器上重新启动在出现故障的服务器上运行的组件。 如果您的网格中出现该问题，请联系 CA Support。
在 CA AppLogic 2.4 中，有几种情况会出现服务器失去与网格控制器的连接并重新启动的现象。 这可导致该服务器上运行的所有组件将在网格中的其他服务器上进行重新排定，还可导致应用停机。 尚不了解服务器失去与网格控制器的连接的原因。 在 CA AppLogic 2.7-3.x 中，如果服务器失去与网格控制器的连接，服务器会试图重新连接到网格控制器，如果成功，服务器仍保持运行状态，且不会发生应用停机。 如果服务器在 1 分钟内无法重新连接到网格控制器，服务器会重新启动，且会发生应用停机。 在服务器失去与网格控制器的连接时，会在显示板中记录一条消息。 如果出现该问题，请立即联系 CA Support。
在 CA AppLogic 2.7/2.8 上，同时调整 4 个 NTFS 卷的大小会导致所有 4 个卷的调整大小操作都失败。 该问题仅出现过一次。
当 NASR 在 1 GB 的卷上复制 800 MB 的文件时，NASR 组件没有响应。 CA 无法再现该问题。 如果您在网格上遇到该问题，请通知 CA 支持。
用户对网格上运行的不同 Windows 组件打开 6 个以上图形控制台（同时打开）。 在打开第 7 个图形控制台时，其中一个服务器会重新启动并重新加入网格。 在出现故障的服务器上运行的组件会在网格中的其他服务器上重新启动。 该问题仅出现过一次。
我们已在此版本中发现 Backbone Fabric Controller (BFC) 的下列已知问题：
su - bfcadmin
重要信息！ 打破该依存关系之后，系统将在没有副本的情况下运行。请返回到 UI，并在同一位置或其他位置创建另一个副本。
请不要对网格使用“3t grid shutdown”命令。
发生这种情况时，在 BFC 上执行“service nfs restart”应该可以解决该问题。
如果显示此消息，只需按“Esc”键继续安装即可。
在 CA AppLogic 3.5 中，某些 Broadcom Corporation NetXtreme II NIC 误报为速度太慢。 如果遇到此错误，可以尝试重新发现服务器。
如果 BFC 在关闭之前将空间用完，在为其释放空间之后，需要重新启动 BFC 才能使其正常运行。
如果对此版本的产品执行无人值守安装，密码中不能包含“=”
如果在 AppLogic 3.1 的 BFC 中使用了 VLAN 0，则可以继续使用该 VLAN ID，但是自 3.5 版起，无法在 UI 中分配该 VLAN。
此缺陷偶尔允许服务器进入本应阻塞的网格。 如果端口配置正确，便不会遇到此问题。
如果需要使用 256 个以上的字符，只需将这些参数分散到多个网格更新中即可。
使用裸机安装并尝试在挂接 NFS 的文件系统上定义副本时，如果目录不归 bfcadmin 所有，便会出现问题。 一种简单方法是在安装之后通过 UI 添加副本。 另一种方法是执行以下操作：
groupadd -g 64869 bfc useradd –u 64870 -g 64869 bfcadmin
chown bfcadmin /mnt/replica chgrp bfc /mnt/replica
（其中，/mnt/replica 是副本目录的路径）
在某些服务器上，禁用超线程和启用超线程时，系统报告的 CPU 数相同。 已在某些 Dell R610 上发现此问题。
此问题与将参数写入要传递到 aldo 集的配置文件的方式有关。 如果用户在 UI 中输入数据时使用逗号分割条目，也会出现此问题。 BFC API 的解决方法是仅传递单个字符串，并在条目之间使用换行符。
例如：
\"additional_config\":[\"ext_dns1=155.35.34.108\next_dns2=141.202.1.108\"]
而非：
\"additional_config\":[\"ext_dns1=155.35.34.108\",\"ext_dns2=141.202.1.108\"]
当在外部交换机上启用生成树协议 (STP)，并且连接到外部服务器接口的交换机端口上的未标记 VLAN 与连接到 BFC 服务器外部接口的交换机端口的未标记 VLAN 不相同时，会出现此问题。 将外部服务器接口上的 stp_port 设置为未知并隔离服务器。 解决方法是，在外部交换机上完全禁用 STP，或将连接到服务器外部接口的交换机端口的未标记 VLAN 配置为与连接到 BFC 服务器外部接口的端口的未标记 VLAN 相同。 然后，取消服务器隔离以重新启动发现过程。
出现此问题的原因是，如果网格具有位于某个子网中的应用 IP 地址范围，则在 3.1 中删除该子网会失败。 升级时会查找缺失的子网，但由于该子网已经不存在，所以升级会失败。 解决方法是，根据失败的升级提供的说明还原之前安装的 BFC 3.1。 然后，转到各个网格，从不属于当前配置的子网的网格中删除所有应用 IP 地址范围。 在某些情况下（例如随后使用新 CIDR 前缀长度参数重新添加了相同的子网时），范围可能位于当前子网的边界内，但是基础子网组件不正确，仍会导致升级失败。 您应在网格控制器 UI 中验证并确认 BFC 中的子网与应用 IP 地址范围的参数是否匹配。
isotool -o 参数不正确显示附加在计算机上的 USB 设备（CentOS 5.5 框）。 这是 CentOS 5.5 的已知问题。 要解决该问题，您必须以根用户身份执行以下 shell 命令：
service haldaemon restart
| 版权所有 © 2012 CA。 保留所有权利。 |
|