如何保护云平台中的应用程序 – 用于 Microsoft Azure 高可用性的集群

用于 Microsoft Azure 高可用性的集群

Azure 的高可用性和集群解决方案

什么是 Azure 群集？

Azure 群集是一组技术，它们被配置为确保为运行 Microsoft Azure 云环境的应用程序提供高可用性保护。 在 Azure 群集环境中，两个或多个节点在故障转移群集中配置并使用群集软件进行监控。 该应用程序在集群中的主节点上运行。 如果集群软件检测到应用程序操作失败，它会将应用程序操作故障转移到集群中的辅助节点。SIOS DataKeeper 集群版群集软件是 Microsoft Windows Server 故障转移群集 (WSFC) 的独特附加组件，它使 Microsoft 群集能够在 Azure 和 Azure Stack 中运行。适用于 Linux 的 SIOS 保护套件保护 Azure 和 Azure Stack 中的关键 Linux 应用程序，例如 SAP、HANA Oracle、MySQL 或 Postgres。 SIOS 群集独特地启用了跨 Azure 区域和可用性区域的群集故障转移，以实现真正的 99.99% 正常运行时间和灾难恢复保护。

立即注册 SIOS 云可用性

座谈会

适用于具有 WSFC 的 HA 群集的 Microsoft Azure 认证软件

SIOS DataKeeper Cluster Edition 软件经过 Microsoft Azure 认证，可在Azure 市场. 它是唯一一款通过 Azure 认证的软件，使客户能够使用 Microsoft Windows Server 故障转移集群 (WSFC) 在 Azure 或 Azure Stack 中创建无 SAN 高可用性集群。

通过将 SIOS DataKeeper 软件添加到 WSFC，他们可以快速轻松地保护关键业务 Windows 环境免受云或物理、虚拟或混合云环境的任何组合中的停机和数据丢失。 现在，使用基于 SAN 的 Windows 服务器故障转移集群来保护他们最重要的应用程序的客户第一次可以自由地将它们移动到 Azure 或 Azure Stack 并实现他们需要的高可用性保护。

查找在 Azure 中创建 HA 故障转移群集的分步指南这里.

在 Azure 市场中查找 SIOS DataKeeper这里.

用于高可用性和灾难保护的 Azure Site Recovery 兼容性SIOS DataKeeper Cluster Edition 是唯一的高可用性经认证可与 Microsoft Azure Site Recovery 一起使用的解决方案，可实现经济高效的高可用性和灾难恢复保护 Azure 中的业务关键型应用程序。

SIOS DataKeeper 的兼容性使客户能够保护 Azure 云环境中的重要应用程序，包括 SAP、SQL Server 和 Oracle。 SIOS DataKeeper Cluster Edition 提供了一种在云环境中使用 Windows Server 故障转移集群（包括 SQL Server Always On 故障转移集群）的简单方法。 客户可以使用 Azure Site Recovery 将群集复制到地理上分离的位置，以实现经济高效、强大的灾难保护。详细了解 Azure 中的 SQL Server 高可用性.

SIOS DataKeeper 和 Microsoft Azure Site Recovery 共同实现了本地高可用性保护和灾难恢复的唯一选择，这是一个高度灵活的按需解决方案。

保护 Azure 中的 Linux 应用程序

适用于 Linux 的 SIOS 保护套件可让您在 Azure 或 Azure Stack 中运行关键业务应用程序，而不会牺牲性能、高可用性或灾难保护。

了解更多关于用于云高可用性的 SIOS SANless 软件。

保护 Azure 中的 SAP 应用程序

SIOS 保护套件和 SIOS DataKeeper 集群版为您的 SAP 应用程序和数据提供全面的、完全 SAP 认证的保护，包括高可用性、数据复制，并在一个简单、经济高效的解决方案中进行灾难恢复，该解决方案可以在云、本地或混合云配置中运行。

详细了解 Azure 上 SAP 的高性能和高可用性使用 SIOS 保护套件的 Azure 上 SAP HANA 数据库的 Microsoft 高可用性了解更多关于 SAP 的 SIOS 保护套件.

在此处查看我们关于云高可用性的最新博客文章。

经授权转载西欧

如何保护云平台中的应用程序 – AWS EC2 高可用性集群

如何保护云平台中的应用程序 – AWS EC2 高可用性集群

AWS 高可用性集群

AWS 中应用程序的高可用性和集群解决方案

什么是 AWS 集群？

AWS 集群是一组技术，配置用于确保为运行 AWS EC2 环境并使用集群软件监控的应用程序提供高可用性保护。 在 AWS 集群环境中，AWS 中的两个或更多节点配置在故障转移集群中。 该应用程序在集群中的主节点上运行。 如果集群软件检测到应用程序操作失败，它会将应用程序操作故障转移到集群中的辅助节点。 为了简化和加速 AWS 中高可用性集群的部署，SIOS 高可用性集群软件可在AWS 市场. 它可以使用一个自动部署AWS 快速入门或通过自带的永久许可模式。 SIOS 集群独特地支持跨 AWS 区域和可用区的集群故障转移，以实现真正的 99.99% 正常运行时间和灾难恢复保护。

SIOS 在 AWS 中提供高可用性

为了简化和加速云中高可用性集群的部署，SIOS 高可用性集群软件可在AWS 市场。 它可以使用一个自动部署AWS 快速入门. AWS Quick Start 部署非常适合首次涉足云中高可用性集群的组织。

具有 SIOS DataKeeper 的 AWS 高可用性

SIOS DataKeeper 集群版是第一个高可用性和灾难恢复结合全自动、以应用程序为中心的集群和高效的数据复制的解决方案。 无缝集成到 Windows Server 故障转移群集环境中，使高可用性群集能够在无法共享存储的云中工作。 SIOS DataKeeper 使用高效的块级复制实时同步本地存储，以创建无 SAN 集群。 系统管理员和管理员有机会尝试 AWS 快速入门计划。 他们可以使用 AWS Marketplace 上的 SIOS Amazon 系统映像 (AMI) 亲眼看看部署双节点是多么容易云中的 SQL Server 集群使用 SIOS DataKeeper。 AWS Marketplace 上的 SIOS AMI 为客户购买 SIOS DataKeeper 软件以保护 AWS 中的业务关键型应用程序提供了一种简单便捷的方式。

SIOS Technology 已获得 AWS Microsoft 工作负载能力状态。 这一称号表明 SIOS 在帮助客户在 AWS 上迁移、部署和管理基于 Microsoft 的应用程序方面提供了成熟的技术和深厚的专业知识，特别是基于 Microsoft SQL Server 的工作负载。

适用于 Linux 的 SIOS 保护套件为 AWS 提供真正的高可用性

AWS 等云提供商提供可用性选项。 但是，他们不提供水平高可用性客户要求的整个应用程序基础架构的广泛保护，以及您在云出现之前通过使用集群实现的保护。 AWS 客户意识到了这一点。 他们知道他们需要真正的可用性和集群软件工具来提供实际水平的高可用性（至少 99.99% 的正常运行时间）。 因此，AWS 与 SIOS 合作。 我们的适用于 Linux 的 SIOS 保护套件以实现这些所需的高可用性水平Linux 集群对于我们共同的客户以及他们正在迁移到 AWS 云的关键应用程序。

适用于 Linux 的 SIOS 保护套件提供了高可用性故障转移集群、持续应用程序监控、数据复制，以及可配置的恢复策略。 适用于 Linux 的 SIOS 保护套件包括 SIOS LifeKeeper、SIOS DataKeeper 和多个应用程序恢复工具包 (ARK)，以保护您的业务关键应用程序和数据免受停机和灾难的影响。

适用于 AWS 的 SIOS 快速入门部署

SIOS 提供的高可用性功能可通过云中的 Windows Server 故障转移集群获得，并可在 AWS 上快速轻松地进行配置 – 节省数月的工作量，提高运营灵活性并显着降低设置和维护成本。 看看我们的客户如何，格列佛和美食家，在 AWS 中使用 SIOS 高可用性集群软件。

AWS Marketplace 产品和适用于 AWS 的 SIOS DataKeeper 和 SIOS Protection Suite Quick Start 部署是全面的解决方案，有助于简化向云中运行高可用性的过渡。 最终让 IT 人员腾出时间来支持其他业务驱动计划。

AWS 快速入门是 AWS 上关键工作负载的自动化参考部署。 每个 QuickStart 都会启动、配置和运行在 AWS 上部署特定工作负载所需的 AWS 服务。 这是通过使用 AWS 安全性和可用性最佳实践来完成的。 快速入门只需单击一下即可消除手动步骤。 它们快速、低成本且可定制。 多个 SIOS DataKeeper AMI 可在 AWS Marketplace 上购买。 因此，它使客户能够为现有部署添加高可用性或在 AWS 中部署两节点 SQL Server 集群。 阅读白皮书。

• 购买通过 AWS Marketplace 的 SIOS DataKeeper
• 查看快速入门适用于 AWS 上的 Linux 的 SIOS 保护套件
• 学习更多关于AWS 上 SQL 的高可用性
• 请求一个免费试用 SIOS 高可用性集群软件

在此处查看我们关于云高可用性的最新博客文章。

经授权转载西欧

如何保护云平台中的应用程序 – 云环境的 SANless 集群

如何保护云平台中的应用程序 – 云环境的 SANless 集群

经授权转载西欧

高可用性团队过渡的七个要素

高可用性团队过渡的七个要点（驾驭大辞职）

除非你一直处于困境或时间冻结，否则你很可能从一个或另一个消息来源听说雇主和雇员正处于一种被称为“大辞职”的趋势之中。据报道美国新闻与世界报道, “根据美国劳工统计局的数据，2021 年 7 月有 400 万美国人辞职，而且趋势并未放缓。”无论您的公司规模或当前的收入来源如何，如果还没有，这种趋势将在不久的将来影响您的 IT 团队。是的，让它沉入其中。负责确保您的关键任务应用程序可用性的同一团队以某种方式容易受到“大辞职”的影响。那么，你如何识别警告标志，接受现实，并以同理心和清晰的态度通过“大辞职”，以便它不会对您的关键应用程序造成“大灾难”？

以下是有关声音的技术和非技术提示高可用性(HA) 变革中的最佳实践：

1. 不要放弃

不要放弃。严重地！当同事和好人选择换工作、职业或以其他方式离开劳动力市场时，辞职可能很诱人。尤其是当您开始考虑用更短的板凳来承担已经很繁重的工作量时。但不要放弃。

2. 识别高可用性的主要风险

当然，识别风险的过程是两方面的。 辞职后，您的团队将面临进一步人事变动的风险。但是，由于容量、技术知识或专业知识的损失，您的高可用性也面临风险。为防止您的企业在新团队辞职后出现计划外停机，您需要识别关键风险领域。一些技术风险包括：

1. 云专业知识和知识
2. 数据库管理
3. 存储管理和配置
4. 隐性高可用性产品知识
5. 紧急保险（人员配备）
6. 技术领导
7. 文档

3. 经理：评估你的公司

很多时候，当人们开始离开一家公司时，很容易说这是“他们，而不是我们！”我们希望关注他们的问题导致他们离开、辞职或选择不同职业或工作的所有原因。他们离开的原因很可能完全是个人的，但有时，问题就在镜子里，不是他们，而是我们。为什么弄清楚这是他们的问题还是你对 HA 很重要？好吧，如果问题在于您的公司，例如它的使命、愿景、围绕 HA 和 IT 的文化，或者 IT 和 HA 系统管理的招聘和人员配备问题，那么简单地增加额外的员工人数将是一个临时解决方案。此外，团队士气、承诺和知识转移的风险可能会进一步受到侵蚀，因为重点仍然是责任转移与问题解决。

4. 团队领导：评估你的团队

在过去的两年里，几乎每家公司都有人退出了他们的团队。无论他们是寻求更高的薪水、留在家里照顾家人、退休还是寻求其他选择，他们都离开了。如果您失去了一名团队成员，则必须评估剩余的团队。该评估在本质上将是技术性的和非技术性的。从技术上讲，您需要：一个。 确定当前的技能、能力和知识差距团队中还剩下哪些技能，技术专长和能力水平如何？ 知识差距在哪里，尤其是理论和实践之间的差距？

湾。 了解现有和缺失的角色。您的许多团队成员可能涉及多个角色和职责。失去一个团队成员实际上可能意味着失去多个角色和职责的覆盖范围。

C。 评估即时培训或增强需求你在哪里，但需要额外的培训来稳定和巩固团队？ 您在哪些领域缺乏可以通过培训现有人员或某种形式的合同专业服务来缓解的问题？作为客户体验副总裁，请亲眼目睹这一点。 在失去了负责 HA 环境的关键团队成员后，我们的团队最近与一家需要专业服务的公司合作。

非技术上，您将需要：一个。 了解剩余团队成员的感受甚至在 COVID 大流行和“大辞职”时期之前，许多团队都在气喘吁吁。 一个 24/7 的 HA 世界留下了很多工作需要处理正常的团队人数、规范和任务。如果您的团队受到影响，那么检查并听取剩余团队成员的故事与停机生产服务器一样重要。找出谁精疲力竭、精疲力尽、困惑、濒临崩溃，或者相反，谁充满活力并准备好迎接新的挑战。 一定要倾听口头和非口头的暗示，同情（不仅仅是失去同事，还有他们的情绪、担忧和恐惧）。

湾。 了解其余团队成员仍在船上的原因了解团队成员的感受既是技术上的又是非技术上的必要性，但与这项任务几乎同等重要的是发现他们留下来的理由。当然，有些原因可能会让您大吃一惊。作者兼演讲者 Carey Nieuwhof 表示，一些团队成员之所以留下来只是因为他们“因为没有先离开而感到被困在团队中”。团队成员留下的其他原因可能不会让您感到惊讶，但无论出于何种原因，舒适度、机会、薪水、地点、股票期权、激情、团队合作、文化，您的团队成员留下的所有原因都很重要。

C。 评估人手不足的影响显然，前面讨论过的人手不足的技术成分；评估技能差距等。但是，人手不足的技术评估有一个推论，那就是非技术性的。请务必评估和评估人手不足（即使只是暂时的）对剩余团队成员的心理、情感和个人健康的影响。在我担任经理的早期职业生涯中，我们的团队处理了一次裁员事件，该事件使几名员工情绪脆弱，精神疲惫。这导致了更高的疲劳度、更多的精神迷雾，以及这些团队成员的缺陷和错误率增加。如果您的团队因人手不足而在精神和身体上受到严重影响，您的 HA 面临的风险可能会增加。您的团队可能正在争先恐后地收拾残局，他们可能会迅速团结起来为已辞职的领导或团队成员提供保障，但您必须了解那些留下来的人是否也筋疲力尽、感到被困或有风险离开。

5. 确定关键技术任务、优先级和分配职责

多年前，一位高管离开了公司。尽管在近一年的过渡期中，他的角色和任务发生了转变，但仍有一些角色和任务令其余员工感到惊讶。在今天的辞职浪潮中，您没有一整年的过渡期。此外，如果您的团队经历了不止一次的辞职，那么您可能还没有完成第一人的分析和过渡，因此确定最关键的任务并确定其优先级并分配责任非常关键。 请务必列出以下任务：安全扫描、更新、维护、备份、测试、新应用程序部署、成本分析、镜像的克隆和重新部署、补丁应用程序和漏洞修复。尽管有损失，这些任务仍然是必要的，如果任其发展，可能会产生毁灭性的影响。

6. 制定维护和运营的短期计划

仍然需要涵盖任务、角色和责任。需要解决关键问题。在您重建员工、培训现有人员并让您的公司更能适应大辞职的过渡和变化之后，计划外的停机时间不会等着发生。为了在短期内导航，您需要制定一个明智的、切实可行的短期计划。该计划应列出已确定的程序、任务和流程，以便可以继续进行维护和操作。此外，它应该定义如何在未来动荡的季节中仔细管理现有的关键基础设施政策。

7. 着眼未来

前面的步骤导致了这一点。通过对当前团队的评估、关键风险的识别以及过渡计划的到位，下一步就是着眼于未来。 你还有使命。您仍然有需要高度可用的关键应用程序。您仍然有需要保护、挖掘、复制并可供您的业务使用的数据。开始为未来的团队制定计划。

1. 建立角色和责任。
2. 更新架构和文档
3. 评估增长和调整的机会
4. 计划新员工，包括入职时间
5. 分配时间和资源来创建和更新入职材料
6. 关注团队健康
7. 短期内应用风险缓解策略并制定长期计划

并非所有关于“大辞职”的消息对您的团队和 HA 来说都是坏消息。在团队成员离开前往新的或不同的职位和机会之后，您有一个真实而难得的机会来获取您评估的所有信息，并将它们转化为增长和调整的工具以及更美好的 HA 未来。建设这个更光明的未来包括定义所需的职责、角色和技能，更新架构和设计，规划新员工和服务参与，以及专注于建立更健康的团队。

我在最近的这篇文章中更详细地讨论了这个主题TFi 采访。-Cassius Rhue，客户体验副总裁，转载自西欧

通过高可用性最大限度地减少停机时间

通过高可用性最大限度地减少停机时间

对于现代企业来说，停机时间变得比以往任何时候都更加昂贵。 ITIC 2021 年每小时停机成本调查发现，在 91% 的组织中，关键业务系统、数据库或应用程序停机一小时的平均成本超过 300,000 美元，而对于 18% 的大型企业来说，一小时的停机时间超过 500 万美元。

高可用性(HA) 是系统、数据库或应用程序的属性，旨在长时间连续可靠地运行。 HA 的目标是减少或消除关键应用程序的计划外停机时间。 这是通过在关键业务系统、数据库或应用程序的设计中结合冗余组件和其他技术来消除单点故障来实现的。

SLA 和 HA 指标

服务提供商使用服务级别协议 (SLA) 来保证客户的关键业务系统、数据库或应用程序在业务需要时启动并运行。

IDC 创建了一个 SLA 模型，该模型定义了以下五个级别的正常运行时间要求：

• AL4（持续可用性 – 系统容错）：每年不超过 5 分 15 秒的计划内和计划外停机时间（99.999% 或“五个九”的可用性）
• AL3（高可用性 – 传统集群）：每年计划内和计划外停机时间不超过 52 分 35 秒（99.99% 或“四个九”的可用性）
• AL2（恢复 – 数据复制和备份）：每年计划和计划外停机时间不超过 8 小时 45 分 56 秒（99.9% 或“三个九”的可用性）
• AL1（可靠性 – 可热插拔组件）：每年计划和计划外停机时间不超过 87 小时 39 分 29 秒（99% 或“两个九”的可用性）
• AL0（未受保护的服务器）：没有可用性或正常运行时间保证

据 ITIC 称，89% 的受访组织现在要求其关键业务系统、数据库和应用程序具有“四个九”的可用性，其中 35% 的组织进一步努力实现“五个九”的可用性。

除了正常运行时间和可用性之外，另外两个重要的 HA 指标是恢复时间目标（RTO）和恢复点目标（RPO）。 RTO 是任何中断的最大可容忍持续时间，RPO 是发生故障时可以容忍的最大数据丢失量。 与通常以小时和天定义的灾难恢复 RTO 和 RPO 指标不同，关键业务系统、数据库和应用程序的 RTO 和 RPO 指标通常只有几秒钟 (RTO) 和零 (RPO)。

高可用性集群

HA 集群通常由服务器节点、存储和集群软件组成。

传统聚类

传统的本地 HA 集群是一组连接到共享存储（通常是存储区域网络或 SAN）的两个或多个服务器节点，这些节点配置有相同的操作系统、数据库和应用程序（请参阅图1 ）。

其中一个节点被指定为主（或活动）节点，其他（或多个）被指定为辅助（或备用）节点。 如果主节点发生故障，集群允许系统、数据库或应用程序自动故障转移到一个或多个辅助节点，并以最小的中断继续运行。 由于辅助节点连接到同一个存储，因此操作继续进行，数据丢失为零。

然而，在传统集群模型中使用共享存储带来了一些挑战，包括：

• 共享存储本身是一个单点故障，可能会使集群中所有连接的节点脱机。
• SAN 存储的拥有和管理成本高且复杂。
• 云中的共享存储会增加大量不必要的成本和复杂性，一些云提供商甚至不提供共享存储选项。

SANless 集群

无 SAN 或“无共享”集群（请参阅图 2 ) 解决与共享存储相关的挑战。 在这些配置中，每个集群节点都有自己的本地存储。 高效的基于主机的块级复制用于同步集群节点上的存储，保持它们相同。 如果发生故障转移，辅助节点会访问主节点使用的存储的相同副本。

集群软件

集群软件允许您将服务器配置为集群，以便多台服务器可以协同工作以提供 HA 并防止数据丢失。 各种集群软件解决方案可用于 Windows、Linux 发行版和各种虚拟机管理程序。 但是，这些解决方案中的每一个都限制了您的灵活性和部署选项，并带来了各种挑战，例如技术复杂性和昂贵的许可费用。

不要等待灾难来袭

HA 对于关键业务系统、数据库和应用程序至关重要。 但是随着无数平台的可用，复杂性显着增加。 这就是为什么应用程序感知解决方案如此有意义的原因。 您需要的是一个在高可用性方面拥有丰富专业知识的值得信赖的合作伙伴——像 SIOS 这样的合作伙伴，它拥有确保您的业务保持正常运行的技术知识。

不要等待中断或灾难来确定您是否具备业务所需的弹性。 立即在以下位置安排个性化演示https://us.sios.com了解 SIOS 可以为您的业务做些什么。

转载自西欧