SIOS APAC Portal

9月 16, 2021	高可用性架构和最佳实践高可用性架构和最佳实践关于高可用性的 13 个鲜为人知的事实 1. Hypervisor HA 与应用程序 HA 不同一个关键的误解是，我之所以具有高可用性，是因为我的硬件或虚拟机管理程序中有冗余。但是，硬件和管理程序冗余并不能保证高可用性用于应用程序。也不能保证应用程序的编排将在失败时正确执行。 2. 在高可用性中，更大并不等于更好如果你是一名力量举运动员，更大的重量更好，更小的代表更好。或者，如果我们谈论拥抱。（你还记得拥抱是我们见到来自不同城镇的朋友时经常做的事情，我们有一段时间没见过了。）但是，更大并不总是意味着更好。例如，更大的肾结石肯定不是更好。在更高的可用性中，创建更大、更复杂的解决方案并不总是意味着您将提高您的高可用性。这可能意味着您的可用性相同或更少。这也可能意味着您有一个更大、更复杂的系统，其中包含许多移动部件，需要在停机时进行分类。 3. 一切都失败了……有时应用程序编程语言可以追溯到 1950 年代。虽然语言、处理器、IDE 和代码质量有所提高，但现实是“所有应用程序都会在某个时候失败”。由于异常、错误、未处理的终止、意外终止、资源耗尽等导致的失败时有发生。仍然需要一个主动/主动或主动/被动应用程序可用性策略。 4. 关注“为什么”和“如何”一样多我们跳入任务完成模式的自然倾向是一种必要的资产，但需要通过我们对为什么的问题的回答来加以调节和引导。在不了解业务、应用程序、数据库和利益相关者要求的情况下向环境添加解决方案将导致：失败超支表现不佳混乱和过度架构上述所有的与其只关注实现可用性，不如花费必要的资源和精力来了解业务需求和“为什么”的答案 5. 未修补的问题是常见的遗憾来源做或不做，后果自负。所有未修补的问题的后果是后悔。作为客户体验副总裁，我亲眼目睹了由于客户未能及时解决已知问题而导致的停机。 6. 未记录的问题也会导致停机描绘场景。一位新管理员正在调查网络上的服务器。使用情况报告表明服务器未处于活动状态，并且没有连接任何客户端。新管理员无法识别服务器，也没有发现“标签”、文档或其他标识符，因此认为应该关闭它。不幸的是，未记录和未通信的实例实际上是一个备用服务器，当主服务器意外崩溃时，删除它会导致停机。这不是虚构的故事，而是一个新管理员的真实故事，他错误地将服务器识别为空闲 QA 系统并在修补练习之前将其关闭。 7、自满也是敌人如果内部或云中或介于两者之间的任何地方的可用性是我们可以“设置并忘记”的，我们都会喜欢它。但是，生活中很少有事情真的像“设置并忘记它”那样简单。未来可用性的最大敌人之一是您现在的高可用性成功。当灾难很少发生并且团队确信他们已经实现了持续稳定时，自满情绪就会介入。成功诱使我们认为什么都不会改变，因此对高可用性的自满是高可用性的敌人。企业周围和企业内部的事物正在发生变化。云在变化，您的业务需求在变化，应用程序和操作系统也在变化。 8.改变很难改变很难。问问那些一直试图在睡前放弃第二块蛋糕的爱吃甜食的人吧。即使在高可用性中也会出现类似的阻力。团队，即使是那些经历过灾难的团队，即使改变是好的，也往往不愿意改变。他们需要远见、对原因的理解和支持。其他拥有解决方案的团队不愿意提高高可用性，因为害怕引入不稳定或将自己暴露在新的风险中。 9.所有的改变都不是好的改变改变是好的，当改变是好的。在考虑对更高可用性解决方案和架构进行更改时，必须针对目标、要求以及在提高可用性的范围内分析更改。提高稳定性、增加对关键组件的保护、消除变通方法、优化服务可用性并经过全面测试的更改都是很好的更改。 10. 便宜并不总是更好便宜并不总是更好。虽然更便宜的解决方案通常具有较低的价格标签，但它们也可能带有许多限制，使其不太理想。当价格标签较低时，请注意缺少的功能，例如缺乏应用程序意识、有限的编排、隐藏的复杂性、手动恢复和故障转移，并且仅限于没有用户验证。更便宜的解决方案也可能不包括客户支持。请务必了解您的更便宜的解决方案是否包含支持，或者支持是否是额外的、大量的附加成本。这同样适用于减少计算、磁盘或存储的更便宜的部署。虽然价格标签和每月成本可能较低，但您的解决方案也可能以不太理想的容量运行。 11.响亮不等于有效听说过那个叫狼来了的男孩的故事。产生警报风暴的应用程序监控解决方案迟早会被忽略。拥有提供警报的解决方案固然很棒，但如果该解决方案错误地或过多地触发了关键警报，则它是无效的。 12. 高可用性是一种文化和心态，而不仅仅是产品或硬件解决方案软件、硬件、流程、解决方案和服务都是高可用性的一部分。但是，如果没有跨 IT 职能和业务部门的支持，它将充满挫败感并不断成为预算讨论的来源，而不是关于价值、业务稳定性、提高客户满意度和降低风险的讨论。 13.现在还不晚希望不是实现高可用性的策略，希望您不会遇到严重灾难或应用程序故障也不需要成为策略。即使距离上次灾难已经过去数周或数月，现在也可以设计和构建高度可用的企业架构。联系 SIOS了解更多高可用性解决方案为您的应用程序。 – 客户体验副总裁 Cassius Rhue 转载自SIOS
9月 10, 2021	简化云迁移的 12 个问题简化云迁移的 12 个问题云迁移最佳实践 “云变得越来越复杂”，这是一个长达一小时的网络研讨会中的第一个声明，详细介绍了云计算和云迁移的繁荣带来的变化和机遇。演示者继续概述了传统 IT 现在在其迁移过程中面临的与云相关的事情。自动售货机,天蓝色, GCP或其他供应商。在向云的传统过渡过程中，出现了九个方面的复杂性：定义价钱联网安全用户、角色和配置文件申请和许可服务和支持可用性备份作为 SIOS Technology Corp 的客户体验副总裁，我已经看到以下领域如何影响向云的过渡。为了减轻这些复杂性，消费者正在转向托管服务提供商、云解决方案架构师、承包商和顾问，以及大量相关服务、指南、博客文章和相关文章。通常在转向外部或外包资源的过程中，云的复杂性并未完全消除。取而代之的是，公司及其雇佣的团队来协助或将他们过渡到云计算仍然会遇到障碍、减速带、小问题和挫折。大多数情况下，迁移到云的过程中出现的这些并发症和减速来自十二个悬而未决的问题：我们迁移到云的目标是什么？您当前的内部部署架构是什么？您有文档、列表、流程图或食谱吗？您的目标云提供商平台是否支持您的所有应用程序、数据库、可用性和相关供应商？您当前的本地风险和限制是什么？哪些应用程序不受保护，本地面临的最常见问题是什么？谁负责云架构和设计？这种架构和设计将如何考虑您当前的定义和云提供商的定义？谁是关键利益相关者，他们的里程碑、业务驱动因素和业务项目的截止日期是什么？您是否与供应商分享了您的项目计划和里程碑？当前的流程、治理和业务要求是什么？迁移预算是多少？它是否包括人员扩充、培训和服务？您对持续维护、许可和运营费用的估计是多少？您的团队现有的技能和职责是什么？谁将负责更新治理、流程、新的云模型以及各种传统角色和职责？哪些应用程序、服务或功能将从 IaaS 迁移到 SaaS 模型？了解您的云目标那么，回答这十二个问题将如何改善您的云迁移。正如您从问题中看到的，了解您的云目标是第一步，也是最重要的一步。几乎普遍接受的是“AWS、Azure 或 Google 等云服务提供商可以提供特定应用程序所需的服务器、存储和通信资源”，但对于许多客户而言，这只会消除“他对计算机的需要”。硬件和管理该硬件的人员。”由于这一事实，客户通常专注于设备或数据中心的整合或缩减，而没有考虑到他们仍然需要考虑的额外云机会和差距。例如，云做消除硬件管理，但它“才不是消除应用程序及其依赖项对监控和恢复的所有需求，”因此，如果您的目标是从云中获得所有可用性，您可能无法实现该目标，或者它可能需要的不仅仅是在本地移动到IaaS 模型。了解您的目标对帮助您规划云之旅大有帮助。了解您当前的本地架构正确迁移到云（或任何新平台）所需的第二类关键问题是了解当前的本地架构。此步骤不仅有助于识别需要可用性的关键应用程序，还有助于识别它们的底层依赖关系，以及基于云的存储、网络和计算变化对这些应用程序、数据库和备份解决方案所需的任何更改。回答这个问题也是评估您的应用程序和云解决方案的准备情况以及量化您当前的风险的关键步骤。当您讨论和量化当前的限制时，会从解决这些问题中受益匪浅的第三个领域出现。通常，我们会看到发现的这一阶段为云中不存在的当前解决方案的局限性打开了大门。例如，最近我们的服务团队与受 SQL 数据库集群性能问题影响的客户合作。一位协助迁移的 SIOS 专家询问了解决方案和架构以及 VM 大小调整决策。片刻之后，部署了一个更大的应用程序大小的实例，以纠正客户由于对计算、内存和存储的本地限制而接受的限制。同样，我们也曾与对存储敏感的客户合作过。由于磁盘容量限制，他们将运行具有较小磁盘和频繁调整大小策略的应用程序。虽然应该考虑存储成本，但以最小的利润运行可能成为过去的限制。了解业务和治理变化最后一组问题可帮助您的团队了解需要更新或替换的日程安排、业务影响、截止日期和治理变更，因为它们可能不再适用于云。迁移到云可以是一个平稳的过渡和旅程。但是，如果无法评估您在旅程中的位置以及何时需要完成旅程，可能会变成一场噩梦。了解时机很重要，可以通过考虑利益相关者、应用程序供应商、业务里程碑和业务季节来获得极大的帮助。自私地，SIOS Technology Corp. 希望客户了解他们的里程碑，因为作为服务提供商，它最大限度地减少了意外。但是，我们也鼓励客户回答这些问题，因为他们经常发现部门和利益相关者之间存在分歧。 DBA 认为转换将在本月的最后一个周末进行，但财务部门打算在同月的最后一个周末结账；或者 IT 团队认为转换可以在星期一发生，但应用程序团队要到星期三才可用，也许最重要的是，法律团队还没有梳理新的 NDA、协议、许可和治理变更所需的清单以将其拉下来全部一起。当客户带着安全感和同理心解决问题时，经常出现的问题是碎片、所有权、流程和决策者的难题，需要使用云提供商的框框和关于预算、人员配备、培训的诚实对话重新组合在一起，和服务。最终的结果可能不是一次完美的迁移，但肯定会是一次成功的迁移。如需有关云迁移策略和高可用性实施的帮助，请联系 SIOS Technology Corp. – Cassius Rhue，客户体验副总裁了解有关常见问题的更多信息云迁移挑战. 阅读关于一些误解云中的可用性。转载自SIOS
9月 5, 2021	实现有效 IT 系统冗余的 3 个步骤实现有效 IT 系统冗余的 3 个步骤在某些行业中，重复任务可能会浪费公司资源，并可能导致意外的人为错误和时间损失。但在管理系统和数据的 IT 世界中，被称为“冗余”的复制过程对于组织的持续成功至关重要。 1. 使用冗余工具保护您的设备和软件提供冗余的 IT 工具可确保您的系统和软件资产免受丢失或损坏。他们还应该提供及时的恢复，以恢复您的业务中断。 IT 系统中的冗余意味着能够复制您的系统组件，无论是在硬件、VM 还是云上。在用户层面，一个简单的例子是制作用户 PC 系统的副本并将其存储在另一台 PC 上作为备用，以防用户的 PC 出现故障。这个相同的概念可以应用于任何其他计算机组件，包括服务器、存储设备和网络设备。例如，“镜像”是将相同数据写入多个磁盘的机制，使这些磁盘变得冗余。冗余使您能够通过尽快切换到备用设备来从设备故障中恢复。企业严重依赖其 IT 系统，系统故障导致的服务中断可能会导致大量的运营停机。因此，冗余对于 IT 系统保持故障恢复能力和降低业务中断风险必不可少。根据您组织的规模和地理位置，这可能很困难、耗时且成本高昂。 2. 使所有数据保持最新并与集群同步具有相同规格和环境（操作系统和软件）的冗余设备并不能在出现故障时自动保护用户文件和电子邮件以及任务关键型应用程序数据的丢失。这不仅适用于个人用户的 PC，而且适用于跨多个服务器和存储设备的更大企业规模。数据存储设备出现故障可能会使您的业务运营严重延迟，无法访问最新数据。对于大型应用程序，如数据库服务器,甲骨文，或者树液，恢复时间可能很长。不幸的是，许多公司认为只需备份数据就可以降低风险。然而，直到生产设备突然出现故障，大多数人都没有意识到将数据从备份副本真正恢复到备用设备是多么困难。与之形成鲜明对比的是，备用设备已经能够使用故障生产设备上的相同数据，您所要做的就是启动备用机器并切换到它。恢复工作会容易得多。这可以通过高可用性 (HA) 集群系统实现。聚类通过创建冗余来补偿不可预见的系统故障，有助于提高软件和硬件系统的可靠性和性能。 HA集群系统由主备系统中的冗余服务器和两台服务器都可以访问的外部存储（例如共享磁盘）组成。万一运行服务器出现故障，通过切换到备用服务器，可以通过备用服务器和包含最新数据的外部存储器的组合来继续服务。顺便说一句，同样的功能可以用“复制”，它实时同步服务器内部磁盘之间的数据。复制也是应对灾难恢复的绝佳措施，因为它不需要安装昂贵的外部存储并在两个实例上保留最新数据。根据辅助实例的位置，同步或异步复制数据。请注意，数据的复制方式会影响恢复时间目标 (RTO) 和恢复点目标 (RPO)。 3. 自动故障转移无论您使用 HA 集群系统还是复制，最佳做法是避免在发生故障时手动切换服务器。相反，应自动化该过程，以便在称为故障转移的过程中毫不延迟地执行该过程。配置 HA 集群系统/复制的自动故障转移可以最大限度地减少停机时间并减少人为错误。基于 SIOS SAN 和 SANLess 的集群解决方案提供高可用性和灾难恢复适用于物理、虚拟、云或混合云环境中的关键任务应用程序。如需更多信息，请参阅我们的Windows 和 Linux 高可用性产品. 转载自SIOS
8月 29, 2021	将应用程序迁移到云端将应用程序迁移到云端我们怎么去那里？ *在您的云和更高可用性之旅中，请考虑作者和企业家的建议Nilofer Merchant（有下面的一个链接就可以了） .* 在不到 72 小时的时间里，我已经多次回答了同一个问题：你如何获得那里?开始是我的一个大女儿问我如何去学校相关的约会，接着是一个年幼的孩子问我去商店的路线，最后我的大女儿问我如何到达特定目的地在该州的某个地方。他们都问了同样的问题。但在每种情况下，问题的背景和预期的答案都大不相同。作为作家和企业家尼罗弗商人说，很多关于“你如何到达那里？”这个问题的答案。不仅取决于你那里，但也对你这里. 您当前的应用程序“在这里”是什么？弄清楚如何移动你的第一步应用那里（到云，或到云中更高的可用性）是正确命名“这里”。那么，你的“这里”是什么？你对这个问题的回答可以像我和女儿们谈话的地点一样多种多样。我的一个女儿从我们家的背景下问道。另一个的背景是从一个不同状态的起点开始，最小的从一个理论的地方问起（希望我们能得到奶昔）。当你考虑你的定义和“这里”的细节时，首先要问一些基本问题：你的是什么关键应用，它们是如何受到保护的？你在哪里部署高可用性保护为您的应用程序？如何保护您的关键数据？您目前的团队规模是多少？您对保护应用程序和数据的解决方案和服务的信心如何？您的关键企业系统和应用程序工作负载当前在哪里运行？如果您在本地，那是本地服务器还是虚拟机？或者这里是私有云，还是没有 HA 的公共云？您迁移到云和在云中管理应用程序的预算是多少？你“在这里”有什么疲倦、不确定、不安或不满？定义“这里”是起点，它帮助我们感觉我们朝着更好的“那里”前进，所以慢慢来。想想在你的“这里”的参数中还有什么形状、定义、限制或存在？“这里”是多产品部署、全球 IT 团队基础设施，还是其他一些多地点、多办公室安排？您的团队是全球分布、外包还是组合？如果你看看你的“这里”有什么突出的地方，你的团队、公司、产品或企业标志是什么？什么是关键且经常出现的痛点，例如缺乏培训、缺少冗余、架构指南不完整、对现有解决方案感到失望、云复杂性、你的“那里”是什么？私有云、公共云、混合云还是多云？在你弄清楚你的“这里”之后，从商人的文章中解脱出来的第二步是“弄清楚'那里'可能是什么。作为客户体验副总裁，我曾与许多客户合作过，他们希望“那里”有一个零停机时间、计划内或计划外的环境，或者应用程序故障转移是无缝的并且在两分钟或更短的时间内完成。其他客户的目标不那么高，寻求适合五 (5) 到九 (9) 分钟窗口内的停机时间，或者更喜欢更长的窗口，并根据对故障通知的响应进行手动覆盖选项。还有一些客户希望“那里”有更好的通知、清晰的解决方案和建议、特定于应用程序的编排，以及通过供应商和合作伙伴的专家来增强他们的团队的方式。那么你的“那里”的主要特点是什么？你买得起什么？当您查看“这里”的辛勤回答时，有什么特别之处？需要解决“这里”的哪些项目，以创建更理想的团队、企业、可用性、数据中心和生活的未来版本。您的“那里”是否包括更多的弹性和冗余、更多的应用程序编排、更好的分析或更低的成本？私有云、公共云、混合云或多云在您的“那里”中处于什么位置？你的“这里”如何改善，因为你已经到达了“那里”。从“这里”到“那里” 根据Merchant 的说法，最后一步是“弄清楚我们从'这里' 到'那里' 的方式。如果在你的“这里”很难，那么只有投入工作去思考“那里”可能是什么才有意义。换句话说，不要简单地将您的应用程序迁移到云中。考虑创建满足您所有期望的结果所需的资源和服务。想一想专注于专门构建的高可用性解决方案的供应商、解决方案提供商、服务团队和公司可以帮助您“实现目标”。与我女儿的“那里”不同，没有用于绘制从“这里”到“那里”或云迁移的旅程的 Waze。但是，通过仔细考虑您当前的情况，包括您的痛苦、挫折、预算限制和您想要的结果，您可以得出一个不仅仅是简单的云迁移的解决方案。这可能意味着更令人满意的日常体验，不受对应用程序故障和停机时间的恐惧以及故障排除和最终用户投诉的麻烦的影响。在计划将应用程序迁移到云时听取商家的建议可以为您带来广泛的可能性，从定义更强大的架构、更改 HA 软件解决方案、与服务提供商合作、迁移到多云、混合云或其他云模型。这甚至可能意味着重新使用您自己的数据中心。 20 多年来，SIOS 一直在帮助企业实施高可用性和灾难恢复保护本地、云和混合云环境中的关键应用程序。我们可以提供专业知识，帮助您完成从“这里”到“那里”乃至更远的应用程序 HA 和 DR 之旅。有关更多信息，请联系 SIOS – 客户体验副总裁 Cassius Rhue 转载自SIOS
8月 25, 2021	使用 Windows Server 故障转移集群在 #AWS 上集群 SAP #ACS 和 #ERS 使用 Windows Server 故障转移集群在 #AWS 上集群 SAP #ACS 和 #ERS 当确保高可用性对于在 Windows Server 上运行的 SAP ASCS 和 ERS，您要使用的主要集群解决方案是Windows Server 故障转移群集. 但是，在 AWS 中执行此操作时，您会很快发现在 AWS 中进行部署时需要了解如何克服一些障碍。我最近写了这个分步指南已发布在 SAP 博客上，可引导您完成整个过程。如果您有任何问题，请发表评论。经授权转载聚集前世

Results 1-5 of 751
Page 1 of 151 >

加入我们的邮件列表

First Name Last Name Email Address
搜索