随着企业越来越多地向云过渡，我们发现了一个重大挑战:达到黄金标准99.99%的可用性。SIOS推出了最新产品——电子书，以帮助企业应对这一复杂局面循序渐进:为业务关键型应用程序配置Amazon EC2。由拥有三十多年IT经验的资深专家Dave Bermingham撰写，这本电子书将成为IT专业人士和企业的宝贵资源。 作者在IT和云计算方面的专业知识 Dave Bermingham是SIOS，对技术社区来说并不陌生。Dave有着12年微软MVP的辉煌业绩和丰富的金融、医疗和教育背景，他带来了丰富的知识。他的专业知识受到高度评价，他的技术认证证明了他对该领域的深刻理解。 探索电子书:AWS、可用性区域等 循序渐进:为业务关键型应用程序配置Amazon EC2深入研究配置Amazon Web Services（AWS）EC2基础架构的关键方面，以确保您的业务关键型应用程序，尤其是使用Windows Server故障转移群集（WSFC）群集的应用程序无缝运行。该电子书阐述了AWS的一个基本方面——可用性应用程序在不同可用性区域（az）中的AWS实例内部运行。 AWS保证多个az中至少一个实例的外部连接性，但这只能确保实例本身的可用性。它不保证实例内部运行的应用程序或服务的可用性；这就是我们电子书的来源。为了弥补这一差距，用户必须采取额外的步骤来监控应用程序并确保在出现故障时进行恢复。此外，对于像SQL Server和其他关系数据库管理系统（RDMS）这样的事务性复制，用户必须确保数据在每个AZ之间复制和可用。实现这一目标需要结合负载平衡、集群和/或数据复制这取决于应用。 期待什么 在这本电子书中，Dave Bermingham提供了对EC2基础架构必要准备工作的全面见解，EC2基础架构通过WSFC集群支持关键业务应用程序。他理清了AWS服务水平协议（SLA）的复杂性，强调必须跨多个az部署实例才能获得99.99%的可用性。读者将深入了解如何设计EC2基础架构以支持跨AZ故障转移集群，从而确保为其关键业务应用程序提供不间断服务。 访问电子书 循序渐进:为业务关键型应用程序配置Amazon EC2是寻求在云计算的动态环境中增强应用程序高可用性和灾难恢复策略的IT专业人员和组织的必读之作。Dave Bermingham的专业知识浓缩到这本电子书中，有望引导您了解业务关键型应用程序的AWS EC2配置的复杂性。今天就下载电子书吧！

教育一直在快速发展，技术融入课堂加速了这种变化，尤其是在过去几年。随着在线学习日益重要，教育机构面临着独特的挑战，需要创新的解决方案。其中一个挑战是确保高系统可用性，以便为学生提供不间断的教育服务。 教育部门的挑战 教育机构在数字时代遇到了各种各样的挑战。其中包括管理高流量旺季、平稳过渡到在线学习、减轻系统故障及其影响、保护数据、适应多样化的全球学生群体以及在预算限制内工作。这些挑战需要稳健的解决方案来保持教育的连续性。 为什么高可用性很重要 高可用性（HA）是确保系统无中断运行的关键概念。在教育领域，HA确保学习管理系统、通信工具和数据存储等基本服务始终可用。这最大限度减少停机时间并确保学生和教育工作者能够在需要时随时访问资源。 评估对医院管理局的需求 在实施高可用性解决方案之前，机构必须评估停机对其运营的影响。理解停机容忍度和估计成本影响是必要的步骤。认识到系统故障的潜在后果至关重要，因为它们会扰乱学习并对机构的声誉产生负面影响。 选择正确的高可用性解决方案 选择正确的高可用性解决方案不是一刀切的决策。机构必须考虑成本影响、可靠性以及系统兼容性和集成等因素。目标是找到符合其特定需求和预算限制的解决方案。 了解灾难恢复（DR） 高可用性侧重于最大限度地减少停机时间，而灾难恢复（DR）则是在发生重大中断后恢复运营。区分高可用性和灾难恢复并认识到它们的互补作用至关重要。高可用性确保不间断访问，而灾难恢复确保从重大损失（如数据泄露或自然灾害）中恢复。 SIOS解决方案简介 SIOS技术公司是一家专门为教育机构提供高可用性和灾难恢复解决方案的公司。SIOS公司提供DataKeeper等产品，旨在增强系统可用性和数据保护。 深入了解DataKeeper DataKeeper提供了一系列功能和优势，旨在应对教育机构面临的独特挑战。它提供了数据复制和保护，确保即使在硬件故障或其他中断的情况下也能访问关键数据。 真实案例研究 为了说明DataKeeper等解决方案的有效性，我们将深入研究一个真实案例。我们将探索一所大学的发展历程，包括他们最初的问题陈述、他们选择的高可用性/灾难恢复解决方案以及他们获得的成果和优势。 示范 在网上研讨会期间，与会者将有机会见证SIOS解决方案的实际应用。现场演示将展示这些解决方案的设置和操作，让您切实了解它们的工作原理。 参与投票问题 作为互动体验的一部分，网络研讨会将包括投票问题，让与会者提供反馈并分享他们对所讨论的挑战和解决方案的见解。 结论和后续步骤 总之，随着教育部门的不断发展，确保系统可用性至关重要。正确的高可用性和灾难恢复解决方案可以在保持教育连续性和保护关键数据方面发挥重要作用。通过探索SIOS解决方案并了解其优势，教育机构可以更好地应对数字时代的挑战。 我们邀请您参加10月24日的这场信息丰富的网络研讨会，我们将深入探讨这些主题，并展示SIOS解决方案如何为教育赋能。 立即注册 在不断变化的教育环境中，不要错过这个增强贵机构系统可用性和弹性的机会。

高可用性对于保护IT基础架构免受以下威胁至关重要停工期，但是您如何找到最佳的高可用性解决方案来购买呢？我们概述了为什么很难确定购买什么以及采取什么步骤让管理层参与投资高可用性。 为什么购买出色的高可用性解决方案如此困难？ 芭芭拉·琼（化名）领导着一个团队，该团队负责公司的大部分IT基础架构，并一直在努力说服她的管理层投资于高可用性。每当她建议实施高可用性（HA）保护时，不同的同事都表达了他们的保留意见、反对意见和替代建议，甚至淡化了他们自己的企业应用程序过去几次宕机的严重性。 她总是问自己同一个问题:如果停机时间的成本估计在45，000美元到500，000美元之间，具体取决于组织、行业和受影响的应用程序，那么为什么在购买一个出色的（经济高效的）高可用性解决方案方面如此困难呢？ 让您的管理层相信高可用性是一项伟大投资的七种方法 1.考虑成本规避的投资回报率 高可用性的投资回报率更准确地计算为成本规避。也就是说，采取措施保持当前预期成本（增加高可用性）的成本与不采取措施的成本（停机时间）的比较。 如果没有高可用性保护，停机是不可避免的，因为IT系统会受到各种停机因素的影响，从机械服务器故障到人为错误、软件不兼容等等..成本也因以下因素而异工业以及公司的规模。一家大型制造商，具有严格的SLA的和每天数百万笔交易的公司，因计划外停机而受到的处罚要比在本地或地区运营的小公司大。此外，如果您的企业受到高度监管或者是关键服务提供商，则停机时间可能会产生额外的惩罚成本，而不仅仅是销售的产品和商品。当IT评估人员对停机时间的成本进行错误评估时，该等式会使购买强大的商业解决方案变得更加困难。 2.考虑整体解决方案的成本 停机本身对公司造成的损失几乎无法估量，例如声誉受损、客户不满和IT员工受挫等。芭芭拉·琼厌倦了中断她富有成效的工作来应对紧张、有时混乱的停机事件。如何计算停机时间对非常昂贵的员工流动率的影响？ 3.正确的医院管理局为自己买单 一些公司认为高可用性解决方案的成本只是所需软件和服务器的成本。他们认为他们可以使用内部资源或云来创建自己的产品。然而，这些公司忘记考虑解决方案的许多不同方面及其各自的隐藏成本。例如，自制解决方案在短期内实施起来可能更便宜，但它们通常包括隐性成本，如维护、持续支持、团队培训、文档、技术债务和故障修复开发。此外，许多自行开发的解决方案在证明“我们可以在内部以更低的成本完成工作”时，并不一定估计或说明团队不会进行的其他工作。像任何DIY项目一样，有些事情最好留给专家来做。 4.清楚地定义你所说的停机时间 停机时间有很多版本；计划内和计划外。停机包括平台不可用、应用程序崩溃、硬件故障、网络中断、物理数据中心问题、违规以及人为错误导致的问题。在一些评估中，客户和IT评估人员开始关注平台的可用性，而忽略了其他停机原因。例如，一家大型制造公司的项目经理讨论说，尽管云平台提供了更高的弹性、可靠性和冗余性，但它们并没有涵盖影响可用性的所有问题。他接着描述了许多评估人员忘记的停机根本原因。 5.澄清相关术语 最近，我加入了一个行业小组，讨论客户在应用程序可用性方面的典型需求。在最初的五分钟内，几名小组成员已经浏览了十几个或更多不同术语的首字母缩写词和缩略语。虽然有些很容易理解，但根据IT专业人员的背景，其他一些非常小众或经验性。例如:高可用性+灾难恢复是高可用性+灾难恢复或高可用性数据复制？首字母缩略词的使用，加上不同行业知识和经验水平的人对术语的不同使用，也会在采购过程中造成混乱和摩擦。作为客户体验副总裁，一位客户评估在采购团队之间遇到了严重的摩擦，因为一位批准者认为公司只需要一个高可用性解决方案，而另一位则提到了高可用性+灾难恢复。最终，两人意识到一个客户的高可用性包括两个节点，而另一个客户的高可用性是两个节点加灾难恢复。 6.明确定义高可用性解决方案的角色 期望值是经常阻碍购买高可用性解决方案的另一个方面。作为客户体验副总裁，我们与一位客户合作，该客户正在处理导致反复停机的平台和应用程序不稳定问题。在评估过程中，客户抱怨高可用性解决方案未能解决平台不稳定性问题。在负载下，硬件CPU和内存崩溃，网络变得不稳定，几乎无法使用。客户没有通过适当规模的系统或可靠的基础架构来解决底层平台问题，而是将故障归咎于高可用性解决方案，并转向了另一个方向。IT管理员有时很难就高可用性能做什么和不能做什么向管理层设定期望。高可用性解决方案不是解决所有IT基础架构问题的灵丹妙药，而是健全架构的重要组成部分。当对解决方案或需求的期望出现误解时，购买通常会受到阻碍或阻止。 7.解释为什么云SLA不提供应用高可用性 审查您的云平台服务级别协议，并深入了解它们将涵盖和不涵盖的内容。许多平台提供了非常需要的基础设施为之前饱受诟病的数据中心提供稳定性、可靠性和灵活性。然而，对大多数人来说应用程序，可用性和正常运行时间的责任仍然由IT管理员承担，而不是云供应商。无论您的系统位于何处（内部还是云中），都没有“100%放手”的高可用性方法。 当然，这并不是导致难以购买高可用性解决方案的误解的完整列表。其他值得注意的误解通常发生在计划流程、用例的优先级、需求的定义和说明、成功标准、预算、预算权限以及对不采用企业商业高可用性解决方案的风险的了解（或缺乏了解）方面。联系SIOS了解有关我们高可用性解决方案的更多信息。 奖金: 消除组织各层之间的误解 评估、购买和部署出色的高可用性解决方案面临的一个主要挑战是组织不同层之间的误解。回想一下第一组成本误解，并考虑每个负责成本论证的人可能需要向老板解释什么才能获得批准。现在考虑每个人老板的背景；他们是技术人员还是非技术人员，在同一个团队还是在组织的不同部门？现在考虑公司中不同IT层之间的关系，以及他们的需求和沟通如何影响讨论和决策。SIOS的客户体验团队合作的许多公司在IT部门的每个部门都有多个技术团队；数据库、应用、平台、网络、安全等。这些技术团队中的每一个都必须进行良好的沟通，以定义需求、期望和成功标准。这种级别的沟通并不容易实现，当所有团队都相距遥远且处于不同时区时，这种沟通会更加困难。

在制造业中，ERP系统和数据库SAP、SAP HANA、Oracle数据库和SQL Server在整个运营过程中管理各种流程。其中一个挑战是停工期这些操作中的任何一个都可能造成中断，即使只有几分钟，不仅对该特定操作，而且对其他操作也是如此。保护这些工作负载的最常见方法之一是使用故障转移群集. 在…里这视频采访TFiR，SIOS伊恩奥尔顿讨论高可用性的注意事项制造业。他解释说，“故障转移群集”是保护工作负载最常用的方法之一，因为它具有成本效益，并提供高达99.99%的可用性。故障转移群集软件通过使用与主服务器相同的规格配置第二台服务器来工作，然后故障转移群集软件监视操作系统和应用程序。如果检测到错误或问题，它会将软件从主服务器故障转移到辅助服务器，从而避免停机。联系我们了解更多信息。 请收听这一集，了解更多有关如何避免停机的信息。

简介:如何确保数据库中的高可用性和灾难恢复 对于许多企业来说，在AWS中创建高度可用的SAP HANA环境是一项关键任务。本指南提供了使用设置3节点HANA系统复制（HSR）群集的详细演练SIOS救生员在AWS中，确保数据库弹性和高可用性. 先决条件 能够部署EC2实例的AWS帐户。 SIOS生命守护者软件 SIOS LifeKeeper评估或永久许可证 SAP HANA软件 熟悉AWS服务和SAP HANA。 步骤1:准备AWS环境 EC2实例部署 在AWS中部署三个EC2实例。这些实例将充当您的HANA集群的主要、辅助和第三节点。确保它们满足SAP HANA和SIOS LifeKeeper的硬件和软件要求。在构建实例时，请确保遵循SAP HANA规模调整指南。 网络结构 配置VPC、子网和安全组，以允许节点之间的通信并允许访问必要的服务。 在不同地区配置HANA节点时，您可以使用SIOS LifeKeeper for Linux Route53应用程序恢复套件或ARK来保护DNS名称。以下是AWS中3节点HANA数据库的体系结构: 设置存储时，请为/usr/sap、/hana/data、/hana/log和/hana/shared使用单独的EBS卷。 我们每个地区有两个VPC。我们需要在VPC之间建立对等关系，并将路由添加到路由表中，以确保服务器可以相互通信。我们还需要修改安全组以允许服务器之间的流量。 最后，我们需要创建一个包含两个VPC的托管区域，并为我们将用于与活动HANA节点通信的域和主机名添加记录。

Amazon EBS和Microsoft故障转移群集概述 亚马逊EBS多连接卷和微软故障转移群集是云计算和数据管理领域的强大工具。然而，集成这两种技术可能充满挑战。这篇博客文章深入探讨了为什么将Amazon EBS Multi-Attach用于Microsoft故障转移集群通常不是最佳选择。 健壮故障转移集群的单一AZ约束 Amazon EBS卷的一个关键限制是它们局限于单个可用性区域（AZ）。对于健壮的故障转移集群，跨多个az部署实例是推荐的最佳实践，这是EBS卷无法直接支持的。 高可用性SLA问题 虽然EBS卷提供了99.9%可用性SLA，这低于高可用性解决方案通常预期的99.99%。在跨多个AZ部署实例时，AWS确实保证了这种更高的SLA，这种优势无法扩展到单AZ部署。 IO2卷的成本影响 具有多连接EBS卷的Windows故障转移群集必须使用IO2卷，这比类似大小和性能的GP3卷大约贵九倍。这种成本差异非常明显，尤其是对于大规模部署而言。 AWS集群配置的复杂性 建筑物AWS中的集群同一个AZ中的节点需要将AZ划分为多个子网，以支持Windows群集中不同的虚拟IP地址（VIP）。这种复杂性，加上无法在集群节点之间共享单个VIP，增加了配置挑战。 SIOS数据管理员:一个更好的选择 SIOS数据管理员成为卓越的解决方案，支持跨子网的集群，同时提供所需的99.99%可用性SLA。它不仅提供更灵活的存储选项（包括使用GPT3磁盘），而且更具成本效益。使用带有GPT3磁盘的SIOS DataKeeper的集群的成本大约是基于IO2的同类集群的20%，并且具有增强的可用性。 SIOS的卓越高可用性 在Microsoft故障转移群集中使用Amazon EBS多附加卷带来了几个重大挑战，从有限的AZ部署选项和较低的可用性SLA到较高的成本和增加的配置复杂性。SIOS DataKeeper提供了一种极具吸引力的替代方案，可以更有效地平衡成本、灵活性和可靠性。

如何在SIOS许可门户中执行许可证更换 当SIOS永久产品许可证首次在SIOS许可门户中激活时，它会绑定到该服务器本地的唯一标识符。该唯一标识符通常是分配给网络接口控制器（NIC）的MAC地址（也称为系统的主机id）。当此系统的唯一标识符不同于用于激活许可证的原始唯一标识符时，需要许可证主机更换才能继续使用SIOS产品. 当系统的唯一标识符（MAC地址/系统的主机id）不再与产品许可证密钥中的原始系统唯一标识符匹配时，许可证主机更换是激活更新的产品许可证密钥所需的过程。 何时需要许可证主机更换？ 当系统的唯一标识符不同于用于创建原始许可证密钥的原始唯一标识符时，需要进行主机更换。有几种情况会导致唯一标识符发生变化: 唯一标识符可能由于当前系统中网络配置的改变而改变。 如果当前系统出现故障并被新系统取代，系统的唯一标识符将发生变化，需要重新激活产品许可证密钥。 如果当前系统升级到新系统，需要重新激活产品许可证密钥。 需要许可证主机更换时会出现什么问题 需要许可证主机更换时最常见的问题是SIOS产品无法正常运行。发生这种情况时，日志将显示由于许可证密钥无效而导致的故障，因为系统上安装的许可证密钥与系统的唯一标识符不匹配。 在Windows系统上，此错误显示在应用程序日志下的事件查看器中 在Linux系统上，此错误出现在/var/log中的LifeKeeper日志中。

在某些行业中，重复的任务可能会浪费公司资源，并可能导致意外的人为错误和时间损失。但是在管理系统和数据的IT世界中，被称为“冗余”的复制过程对于组织的持续成功至关重要。 1.使用冗余工具保护您的设备和软件 提供冗余的IT工具可确保您的系统和软件资产不会丢失或损坏。它们还应该提供及时的恢复，以恢复业务中断。 IT系统中的冗余意味着能够在硬件、虚拟机或云上复制您的系统组件。在用户层面，一个简单的例子是复制用户的PC系统并将其存储在另一台PC上作为备用，以防用户的PC出现故障。 同样的概念可以应用于任何其他计算机组件，包括服务器、存储设备和网络设备。例如，“镜像”是一种将相同数据写入多个磁盘的机制，使这些磁盘成为冗余磁盘。 冗余使您能够通过尽快切换到备用设备来从设备故障中恢复。企业非常依赖其IT系统，系统故障导致的服务中断可能会造成相当长的运营停机时间。因此，冗余对于IT系统保持故障恢复能力和降低业务中断风险是不可或缺的。根据您组织的规模和地理位置，这可能会非常困难、耗时且成本高昂。 2.保持所有数据最新并与集群同步 拥有具有相同规格和环境（操作系统和软件）的冗余设备并不能在出现故障时自动防止用户文件和电子邮件以及任务关键型应用程序数据丢失。这不仅适用于单个用户的PC，也适用于跨多个服务器和存储设备的大型企业。数据存储设备的故障可能会导致您的业务运营严重延迟，无法访问最新数据。对于大型应用程序，如SQL Server, 神谕，或者精力，恢复时间可能很长。 不幸的是，许多公司认为只要备份数据就可以降低风险。然而，在生产设备突然出现故障之前，大多数人都没有意识到从备份拷贝中将数据恢复到备用设备有多么困难。 与之形成鲜明对比的是，如果备用设备已经能够使用故障生产设备上的相同数据，您只需启动备用机器并切换到该机器即可。恢复工作会容易得多。这在高可用性（h a）集群系统中是可能的。 使聚集通过创建冗余来补偿不可预见的系统故障，帮助提高软件和硬件系统的可靠性和性能。高可用性集群系统由活动和备用系统中的冗余服务器以及两台服务器都可以访问的外部存储（例如共享磁盘）组成。万一操作服务器出现故障，通过切换到备用服务器，服务可以通过备用服务器和包含最新数据的外部存储器的组合来继续。 顺便说一下，同样的功能可以通过“复制”，它可以实时同步服务器内部磁盘之间的数据。复制也是防止灾难恢复的一项出色措施，因为它不需要安装昂贵的外部存储，并在两个实例上保留最新数据。根据辅助实例的位置，可以同步或异步复制数据。请注意，数据复制方式会影响恢复时间目标（RTO）和恢复点目标（RPO）。 3.自动故障转移 无论您是利用高可用性集群系统还是复制，最佳做法都是避免在发生故障时手动切换服务器。相反，应自动化该过程，以便在称为故障转移的过程中毫不延迟地执行该过程。配置高可用性集群系统/复制的自动故障转移可以尽可能减少停机时间并减少人为错误。