SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

11月 26, 2022

为关键应用制定灾难恢复计划

为关键应用制定灾难恢复计划

为关键应用制定灾难恢复计划

经许可转载自信息系统
11月 23, 2022

Azure 上的 SAP 高可用性最佳实践

Azure 上的 SAP 高可用性最佳实践

在以下视频中，拥有 20 年 SAP 经验的 Microsoft 高级 SAP 架构师 Bala Anbalagan 解释了配置高可用性以保护 Azure 中的 SAP 解决方案的最佳实践。 他还回顾了在云中实施 HA 解决方案时经常犯的错误，以及用户在配置 SIOS LifeKeeper 时应该了解的关键因素。

在云端配置 SAP 高可用性解决方案

Bala 解释说，每个 SAP 用户都应该记住，高可用性解决方案是必不可少的，尤其是在云端。 任何云提供商都需要对其环境进行更改。 尽管他们的硬件基础设施服务水平很高，但也会有短暂的停机时间，这可能会使您的 SAP 系统完全崩溃。

用户正确配置 SAP HA 也很重要。 安装 HA 解决方案的主要目的是防止停机，但如果你没有正确地做到这一点，你只是在浪费时间和金钱，不管你在哪个云中运行。 必须遵循云提供商的配置规则。 如果您错误地配置了 HA 或未能测试故障转移和故障回复，它可能会在您最意想不到的时候导致业务中断——尤其是在高利用率期间。
SIOS 生命守护者可以检测配置过程中的错误。 例如，如果您只配置一个通信通道，它会发送警告，因为您总是希望 HA 集群中的节点之间有冗余通信通道或辅助网络连接。 如果你使用SIOS 数据管理员，如果在复制过程中配置有问题，它也会显示警告。

是什么让配置 SIOS 如此简单？

SIOS 有一个非常简单的配置过程。 基本上，您只需要在每个集群节点中安装 LifeKeeper，并根据您要恢复的应用程序使用不同类型的 SIOS 应用程序特定恢复工具包 (ARK) 模块（LifeKeeper 随附）。 此外，使用简单的 GUI 可以很容易地遵循该过程 – 智能是内置的，您无需更改 GUI 的细节。 它会自动检测大部分信息，进一步简化设置过程。

知道要使用哪个 ARK 以及如何使用它在配置过程中很重要。 ARK 是一个软件模块，它为 LifeKeeper 软件提供特定于应用程序的智能。 SIOS 为不同的应用程序提供单独的 ARK。 例如，对于 SAP HANA，您安装 SIOS SAP HANA 方舟使 LIfeKeeper 能够自动执行配置步骤、检测故障并为 SAP HANA 管理可靠的故障转移，同时保持 SAP 的最佳实践。

在 Azure 中为 SAP 实施 HA 的最大错误

用户通常实施Azure 中 SAP 解决方案的高可用性使用与在本地环境中相同的过程。 他们需要改变心态。 始终确保遵循云提供商提供的建议，即阅读文档并按照云提供商的建议保留参数。

另一个常见的错误是增加了太多的复杂性。 一些客户将所有东西都放在一个集群中，但集群应该为不同的服务器分开。 使集群太大会增加不必要的复杂性和潜在风险。

当涉及到 HA 集群时，在各个方面进行彻底的测试是至关重要的。 在上线之前以及定期（和频繁）测试 HA 配置是您可以做的最好的事情，以防止意外停机。

学习更多关于SAP 高可用性以下视频中的最佳实践或联系我们以获取有关为云中的基本应用程序实施高可用性和灾难恢复的更多信息。

经许可转载自信息系统
11月 20, 2022

HA 和 DR 的简单日子已经一去不复返了

HA 和 DR 的简单日子已经一去不复返了

翻阅电视频道，我偶然发现了电影“他只是没那么喜欢你”和德鲁·巴里摩尔 (Drew Barrymore) 的场景，讲述了我们大多数人在 2022 年对技术，尤其是高可用性和灾难恢复的感受：“我怀念那些日子你有一个电话号码和一台答录机，那台答录机有一盒磁带，而那一盒磁带要么有一个人的留言，要么没有。 现在你只需要四处检查所有这些不同的门户网站，就会被七种不同的技术拒绝。 太累了。”有时，您不希望只有一个云，甚至没有云平台吗？一个数据库运行在一个操作系统上；并且只需要担心一个前端应用程序。 但是，世界已经发生了变化，而且发展得更快，也变得更加复杂。技术的进步、并购的影响以及我们 24/7 社会日益增长的胃口和节奏，数十亿消费者正在寻找最新的交易和最好的体验，这意味着简单的日子已经一去不复返了。

关于您的可用性的 4 个硬道理

  1. 您的解决方案并不像您想象的那么简单

当然，您的企业环境并不简单。您有遗留系统和应用程序，几乎是自打孔卡以来就存在的那种。您拥有专为新一代应用程序和数据库打造的新系统。此外，您拥有十年前创建的解决方案，以弥合从一个平台迁移到另一个平台之间的差距或跨越时间，但尽管您尽了最大努力，这些系统仍然存在。 除了这些挑战之外，还有越来越多的系统和 IT 资源来自于公司 U 的并购。在新时代交付 HA 并不像您想象的那么简单。

  1. 糟糕的架构是一个比你意识到的更大的问题

作为客户体验副总裁，我们已经看到了不良架构造成的损害。虽然部署 HA 软件绝对有助于提高应用程序和数据库的可用性，但 HA 软件永远无法完全克服不完整的需求、糟糕的网络、缺少冗余硬件或其他缺少的架构组件。我们的团队曾经与一位客户合作，以纠正在高峰运行时间导致系统不稳定的规模过小的环境。由于他们糟糕的架构，包括网络和硬件不稳定，他们的团队经常发现他们自己在争先恐后地从可避免的停机问题中恢复过来。为了拥有一个完整、健全、高可用性和弹性的解决方案，您需要部署出色的软件作为健全架构的一部分。

  1. 您的管理员需要的帮助比他们承认的要多

开发企业级、高度可用的弹性 HA 解决方案，建立在具有增长能力的可靠架构之上，并不是一个简单的过程。针对弹性、应用程序和数据可用性进行设计和架构并不像从货架上拿一盒蛋糕那么容易。投入一系列工具、来自不同团队的流程、混合的 SLA 以及各种操作系统、应用程序、数据库和平台，您就有了需要帮助的秘诀。 最近，我采访了一位在企业支持环境中工作 20 年的老手。他描述了他的许多同行，有时甚至是他自己，都无法承受维护关键企业可用性的重担。您的管理员不仅在凌晨 2 点起床处理灾难性的多系统、多应用程序、几乎完全崩溃的数据中心时需要帮助，而且在企业可用性的日常辛勤工作中也需要帮助技术复杂的时代。

  1. 您的解决方案可能没有您想象的那么高可用

“虽然公共云提供商通常会在其服务水平协议中保证一定程度的可用性，但这些 SLA 仅适用于云硬件。”云提供商 SLA 未涵盖应用程序停机的许多其他原因，包括：

  • 软件问题和错误
  • 人为错误
  • 软件故障
  • 系统或应用程序挂起

作为客户体验副总裁，我们已经看到了一两件事，包括递归例程中退出失败导致的拒绝服务攻击、系统耗尽、健康、关键应用程序的安全软件隔离、内核恐慌以及随机运行的虚拟机重启。如果您的 HA 策略仅依赖于管理程序的 SLA，您的解决方案可能没有您想象的那么高可用。 您需要保护关键应用程序集群软件可以监视和检测问题，可靠地响应问题，并在必要时将操作转移到备用服务器，以确保您的产品和服务在需要的时间和地点保持可靠和可用。

我们的单一数据中心变成了一系列的云平台，跨越了几十个数据中心。我们的 skunk work 应用程序已经成为我们必须跨 Windows、Linux 和一些不同的 *Nix 变种管理的关键前端、中间件和后端解决方案的一部分。技术的进步意味着我们的高可用性变得更加复杂，需要更好的架构。这也意味着我们的团队需要更多帮助来管理这一切，如果我们不小心，可能意味着我们仍然容易受到攻击和暴露。您的团队面对的最多的是四个真相中的哪一个？

客户体验副总裁 Cassius Rhue 经许可转载自信息系统
11月 15, 2022

SIOS LifeKeeper for Windows 中的新驱动程序为您做了什么？

SIOS LifeKeeper for Windows 中的新驱动程序为您做了什么？

在未来数年加强共享和无 SAN 环境中的数据保护。

可口可乐、KitKat、SalesForce 和适用于 Windows 的 SIOS LifeKeeper有共同点？这里有一些提示：

  • 可口可乐重新启动了一项活动，使用其标志性品牌的产品重新设计以适应未来，特别是关注社会主题。
  • Kit-Kat 在英国重新命名其糖果棒，以纪念和庆祝蓬勃发展的社交媒体、YouTube 和通用技术浪潮，并利用 Android (KitKat) 操作系统的品牌优势。
  • Salesforce 改进了其基础产品，以创建更时尚、更现代、更快速的界面来满足其客户的需求。

这些公司对其标志性产品、服务和解决方案进行了重大改进，以更好地为客户服务，适应未来并为未来做好准备，并利用自身优势。以类似的方式，SIOS 对我们的 SIOS LifeKeeper for Windows 产品进行了显着改进。

在 LifeKeeper for Windows 版本 8.9.0 之前，共享存储功能（包括 I/O 防护和驱动器识别和管理）由 NCR_LKF 驱动程序处理。从 SIOS LifeKeeper for Windows 版本 8.9.0 开始，SIOS Technology Corp. 重新设计了共享存储驱动程序架构。 从当前版本开始，NCR_LKF 驱动程序已被删除并由 SIOS ExtMirr 驱动程序取代，SIOS ExtMirr 驱动程序是 SIOS DataKeeper / SIOS DataKeeper Cluster Edition 的 SANless 存储复制背后的引擎。

SIOS LifeKeeper for Windows 中 NCR_LKF 架构变化的五个显着优势：

  1. 更现代的司机

ExtMirr 驱动程序提供了一个更现代的过滤器驱动程序来管理共享存储功能。虽然 NCR_LKF 驱动程序专注于“保持灯亮”和“数据安全”，但驱动程序的体系结构落后于更现代的驱动程序。ExtMirr 驱动程序维护了数据保护，同时更兼容、更现代并且更容易在新版本的 Windows 操作系统中得到支持。

  1. 更强大的 I/O 防护

SIOS DataKeeper 和 SIOS DataKeeper Cluster Edition 中使用的驱动程序包括一个强大的防护架构。 虽然 NCR_LKF 驱动程序能够进行 I/O 防护，但新驱动程序更加健壮并且已经在 SAN 和 SANless 环境中进行了测试。 增强的 I/O 防护利用受保护卷中的卷锁和节点所有权信息。

  1. 更紧密的集成和兼容性。

利用 DataKeeper 产品中使用的 ExtMirr 驱动程序的 I/O 防护意味着 LifeKeeper for Windows 解决方案增加了与 DataKeeper 产品线的集成。ExtMirr 驱动程序还包括最新的Microsoft 驱动程序签名并与强制执行驱动程序签名和安全启动的操作系统无缝协作。

  1. 更容易管理

ExtMirr 驱动程序为客户和管理员提供了大量命令行实用程序，用于获取和管理卷的状态。emcmd 命令是两个 SIOS DataKeeper 产品的本机命令。 它们现在可用于更轻松地管理 SIOS LifeKeeper 共享卷配置。 利用 LifeKeeper for Windows 产品的共享存储和复制配置的客户和合作伙伴现在可以了解和使用单一的命令行工具集。 emcmd 工具取代了以前的 volume.exe、volsvc 和类似的 NCR_LKF 过滤器驱动程序管理工具（锁定、解锁等）。

  1. 更频繁的更新和修复

通过将 ExtMirr 驱动程序添加到适用于 Windows 的 SIOS LifeKeeper 中，共享存储配置以及复制配置现在将在更新、新功能和修复方面得到提升。 虽然 NCR_LKF 驱动程序为 I/O fencing 提供了坚实的基础和稳定的基础，但切换到 ExtMirr 驱动程序意味着客户将看到相同的强度和稳定性，并且对新产品支持的更新速度更快将两个产品对齐到一个驱动程序可能不会与 SalesForce Classic 到 Lightning 更新一样华丽，但它增加了重要的功能，增加了 SIOS DataKeeper 和 SIOS LifeKeeper 解决方案的强度和寿命，并将在未来几年加强共享和无 SAN 环境中的数据保护。

客户体验副总裁 Cassius Rhue 经许可转载自信息系统
11月 11, 2022

如何重新创建文件系统和镜像资源以确保大小信息正确

如何重新创建文件系统和镜像资源以确保大小信息正确

使用高可用性 (HA) 集群时，必须确保集群中所有节点的配置相互并行。 这些“镜像”配置有助于最大限度地减少集群上的故障点，提供更高标准的 HA 保护。 例如，我们已经看到在源节点上更新了镜像大小但在目标节点上没有更新相同信息的情况。 镜像大小不匹配导致 LifeKeeper 无法在故障转移的目标节点上启动。 以下是在目标节点上使用与源相同的大小信息重新创建镜像资源的推荐步骤：

脚步：

  1. 从应用程序的角度验证源节点上的数据是否有效且一致
  2. 备份源上的文件系统（即镜像源）
  3. 运行 /opt/LifeKeeper/bin/lkbackup -c 来备份两个节点上的 LifeKeeper 配置
  4. 使所有资源停止服务。在我们的示例中，资源在节点 sc05 上提供服务，sc05 是镜像的源（sc06 是镜像的目标系统/目标）。
    1. 在 LifeKeeper GUI 的右窗格中，右键单击DataKeeper 资源那是在服务中。
    2. 点击中止服务从资源弹出菜单。
    3. 一个对话框将确认所选资源将停止服务。 与该操作关联的任何资源依赖性都会在对话框中注明。 点击下一个。
    4. 出现一个信息框，显示资源停止服务的结果。 点击完毕。
  1. 验证所有资源都已停止服务并且文件系统已卸载
    1. 在源上使用命令 cat /proc/mdstat 验证没有配置镜像
  1. 在源上使用 mount 命令以确保不再挂载文件系统
  2. 在源上使用 /opt/LifeKeeper/bin/lcdstatus -q 以确保资源都是 OSU。
  1. 在 LifeKeeper GUI 中打破 IP 资源 (VIP) 和文件系统资源 (/mnt/sps) 之间的依赖关系。右键单击 VIP 资源并选择删除依赖项。

然后，为子资源标记选择文件系统资源 (/mnt/sps)。

这将导致两个层次结构，一个具有 IP 资源 (VIP)，一个具有文件系统资源 (/mnt/fs) 和镜像资源 (datarep-sps)。

  1. 删除包含文件系统和镜像资源的层次结构。 右键单击 /mnt/sps 并选择删除资源层次结构。
  1. 在源上，在文件系统上执行“mount <device> <directory>”。

示例：挂载 /dev/sdb1 /mnt/sps

  1. 通过 GUI 通过以下命令重新创建镜像和文件系统：
    1. 恢复套件：数据复制
  1. 回转类型：智能
  2. 服务器：源节点
  3. 层次结构类型：复制现有文件系统
  4. 现有装载点：<选择您的装载点>。 在这个例子中是/mnt/sps。
  5. 数据复制资源标签：<取默认值>
  6. 文件系统资源标签：<取默认值>
  7. 位图文件：<取默认值>
  8. 启用异步复制：是
  1. 创建后，您可以扩展镜像和文件系统层次结构：
    1. 目标服务器：目标节点
    2. 回转类型：智能
    3. 模板优先级：1
    4. 目标优先级：10
  1. 预扩展检查完成后，选择下一个，然后选择以下值：
    1. 目标磁盘：<选择镜像的目标磁盘>。在我们的示例中是 /dev/sdb1。
    2. 数据复制资源标签：<取默认值>
    3. 位图文件：<取默认值>
    4. 复制路径：<选择您环境中的复制路径>
    5. 安装点：<选择您环境中的安装点>。在我们的例子中是/mnt/sps。
    6. 根标签：<取默认值>

当资源“扩展”完成后，选择“完成”，然后选择“完成”。

  1. 在 LifeKeeper GUI 中重新创建 IP 资源 (VIP) 和文件系统资源 (/mnt/sps) 之间的依赖关系。 右键单击 VIP 资源并选择创建依赖项。选择 /mnt/sps 作为子资源标签。
  1. 此时镜像应该执行文件系统大小的完全重新同步。 在 LifeKeeper GUI 右窗格中的 LifeKeeper GUI 中，右键单击 VIP 资源。 选择“In Service”以恢复 IP 资源 (VIP)，选择镜像处于服务状态的源系统（在我们的示例中为 sc05）并验证应用程序重新启动并且 IP 可访问。

经许可转载自信息系统
  • Results 1-5 of 852
  •  Page 1 of 171 >

  • 加入我们的邮件列表