SIOS SANless clusters High-availability Machine Learning monitoring
SIOS 高级产品 (Windows) 支持工程师 Greg Tucker 将在这段 3 分钟的视频中演示如何正确删除SIOS 数据保持器贮存来自 SIOS LifeKeeper。
强烈建议您在删除 DataKeeper 之前从集群中删除 DataKeeper 资源。
在视频的最后，Greg 分享了 SIOS 支持联系信息，以防有其他问题或问题。
如何从 SIOS LifeKeeper 中删除 SIOS DataKeeper 存储西欧经 SIOS 许可转载
2020 年和 2021 年改变世界的事件以某种方式重塑了我们所知道的几乎所有事物，并且高可用性也不例外，因为许多公司都在快速跟踪他们的云采用之旅。 尽管关闭和限制，许多 IT 团队还是将本地数据中心换成了云。 很多人都在问，‘现在呢？以下是解决 2022 年云之旅的五件事。
在推动云计算的过程中，许多 IT 和业务领导者发现自己急于将服务和应用程序从因 COVID-19 而关闭的数据中心迁移到云中。 其他人涌向云端，不是因为数据中心关闭，而是为了应对远程工作突然增加带来的爆炸式需求浪潮。 对于一些人来说，云之旅是如此之快，以至于没有包括高可用性，现在他们已经（艰难地）发现应用程序仍然在云中崩溃，并且意外中断和计划外停机仍然是 AWS 的克星， Azure 和 GCP——就像它们在以前的数据中心中一样。
修复云之旅的第一步是增加高可用性。 这对您的企业意味着几件事：
当然，并非每个人都在不考虑某种形式的情况下迁移到云高可用性. 一些 IT 团队有先见之明，不会将 HA 留在本地，但在急于上云的过程中，他们将所有关键服务器都移到了同一个云可用区。 虽然拥有一些 HA 保护比完整的漏洞要好，但如果您只将服务器和应用程序部署在单个可用区 (AZ) 中，现在是时候为备用集群节点扩展至多可用区，甚至内置通过在不同区域部署第三个节点进行灾难恢复。SIOS 已帮助数十家客户规划多可用区架构并添加灾难恢复解决方案。
一夜之间，一些公司及其 IT 团队从完全本地化转变为与 Cloud Formation 模板、快速入门指南、IAM 角色、内部负载均衡器、覆盖 IP 以及破译 VM 大小的确切含义有关。现在是组建团队来支持云之旅的时候了。这将意味着几件事：一种。 增加容量。除非您能够完成一个完整的提升和转变，否则您可能会拥有相同的员工来管理云和本地应用程序。传统解决方案以喜怒无常而著称，需要大量工作才能保持稳定和可用以导航未来的云之旅，您需要能够满足可用性要求、了解云架构并为企业需求规划前进方向的能力。
湾。 通过培训提高技能.为您的 IT 团队提供云培训。要管理和规划课程，请通过有关云解决方案、架构、最佳实践和权衡的额外培训，寻找方法来增强组织内的 IT 卓越性。训练有素的员工不仅会在提高可用性方面获得红利，而且还会通过以经济、可扩展和合乎逻辑的方式解决可用性、维护和增长问题，从而获得红利。翻译：他们会在构建云基础架构的其余部分时避免浪费金钱。
作为 SIOS Technology Corp. 的客户体验副总裁。 我曾与几家公司合作，这些公司在 2021 年迁移到云，而没有牺牲 HA、DR 或他们的团队。 如果您认真对待达到所需的正常运行时间数 (99.99%)，并制定了不可协商的灾难计划，那么是时候增加分析和额外监控的严格性了。 确保您的可用性解决方案具有应用程序感知自动化和编排功能，以便在发生灾难或计划外停机时进行恢复。 添加分析和自动化以巩固您的解决方案，并使您的云迁移从被动故障转移到主动通知和故障发生前的缓解。想象一下，如果应用程序性能不佳，或者延迟增加、错误或 VM 无响应行为及时得到通知，以避免在业务高峰期出现停机。 分析也很重要，因为它们可以揭示可能已经逃离原始可用性架构的系统和应用程序。
我们认为失败的许多事情都源于过程的失败。 确保您的组织的流程是最新的、有据可查的、适当的沟通和遵守的。 这些流程应包含与谁、什么、何时、何地以及如何与客户相关的业务战略、目标和组织需求相关的一些关键最低要求。
确保您的新云环境的所有权和签核流程有据可查。 对于从获取基础架构的硬件团队转移到云团队的客户，我亲眼目睹了因角色和责任冲突、冲突或未解决所带来的挫败感。 在迁移中糊涂是一组痛点，在没有明确治理的情况下从灾难中挖掘出来是一个更大、成本更高的问题。
如果您已经实现了向云的飞跃，那么留在那里并使其为您工作是旅程的下一部分。如果您的云之旅突然或崎岖不平，请考虑这五点来改善您的云之旅，并了解 SIOS 技术不仅可以帮助您提高云中的高可用性，还可以帮助您提高在云中运行的流程。
-Cassius Rhue，客户体验副总裁 经许可转载西欧
SIOS 高级产品 (Windows) 支持工程师 Greg Tucker 提供了一个 8 分钟的教程，演示如何移动两节点系统上的镜像.
此外，他还讨论：
完成本教程后，Greg 将分享所有 SIOS 支持联系信息，以供进一步的问题或查询。
各种规模的企业对 IT 系统的需求都在不断增长，这已不是什么秘密。 但是，只有当 IT 系统具有可操作性、弹性和高可用性时，它们才对这些企业及其客户有效。 当企业希望扩大其企业可用性时，拥有衡量和评估漏洞的基线可能会产生成功合并基础架构、软件、服务和支持的差异，从而提高您的成功率。
有时，最基本的清单可以帮助您确定您的解决方案是高度可用还是高度易受攻击？
他们部署软件，但在网络基础设施、服务器和数据中心本身内部存在不稳定性。 云解决了许多基础架构问题，但并非所有云平台的架构都相同。 请务必了解您的数据中心、本地或云。
如果您回答了什么是 Runbook 或 playbook，那么您的第一步就是找到或创建一个。 运行手册（或剧本）可帮助您的组织维护与高可用性系统架构相关的系统和流程。 一些公司使用自动化工具来创建部署和配置服务器的脚本，其他公司使用版本控制文档来概述所有事物如何协同工作以提供弹性和成功。 您的团队需要有一个新人和现有团队成员可以去了解环境、流程和正在使用的工具的地方。
“我没有设置这些系统，”IT 管理员说，“我只是用其他一些服务器继承了这些系统。”哀叹是组织中一种诚实且经常观察到的现象。 无论是并购、成本削减、外包还是一般人员流动的结果，高可用性企业的一个关键组成部分是足够的人员配备。 一个高度脆弱的企业的一个关键是人员不足、训练不足或支持不足。
变更管理很重要。 变更管理控制和政策对于降低风险和确保您的系统可用是绝对必要的。 没有适当限制的用户可以添加破坏稳定性的包或更新，或进行破坏组织数小时的更改。 此外，没有明确的政策通常会在预期（记录）和实际（现有）之间产生偏差。 变更管理对于确保备用集群与主/源系统处于相同的补丁和软件级别以及确保 QA（或预生产）不会严重偏离生产环境也至关重要。
我们的服务团队加入了客户呼叫并等待、等待、等待有权运行一组提升命令的管理员加入会话以配置和更新他们的软件。 几周后，我们的团队加入了一个不同的客户电话会议，并惊恐地看到多个具有管理权限的用户在同一个集群上运行了一系列命令。 两次调用的差异清楚地指出访问控制很重要。 高可用性企业需要确保适当的访问控制到位，以防止用户运行可能损坏配置或削弱其操作的提升命令。 确保用户根据他们的角色、需求甚至经验限制他们可以做什么。
测试需要时间，但我的职责是帮助客户完成他们的云迁移和高可用性部署，时间一直都花得很好。 通常，高可用性和易受攻击之间的区别可以归结为客户或合作伙伴的测试过程。 随着解决方案变得越来越复杂，测试和验证对于降低风险和漏洞变得越来越重要。 如果一切都从设计到生产，那么您正在运行一个高度易受攻击的系统。 但是，如果您有测试和检查点，那么在将更改投入生产之前验证更改的过程会大大降低您的风险。 作为客户体验副总裁，我们的服务团队与一位重要客户合作，该客户在完成上线迁移之前在 QA 中部署了整整一年的系统。 在那一年，他们模拟了中断、灾难、客户负载、停机时间、维护、修补策略、备份、从备份中恢复，以及一系列其他测试套件。 因此，它们在性能、流程遵从性、高可用性和企业成功方面取得了显著成果。
虽然没有清单能够涵盖高可用性中的每个潜在漏洞，但回答这些问题将为您了解您的企业是高可用性还是高度易受攻击奠定坚实的基础。
经授权转载西欧
周末，我加入了收看迪士尼 Encanto 并成为这个故事的粉丝、课程和机会的学生以及 Lin-Manuel Miranda 的绝对粉丝的人群中。 迪士尼的 Encanto 在高可用性、集群和弹性方面提供了什么？
课程高可用性，IT 团队，并从迪士尼的 Encanto 中克服停机时间[Warning: movie spoilers ahead]在 Encanto 中，您很快就会了解到 Family Madrigal 是一个特殊的家庭。 在其中一首开场歌曲“The Family Madrigal”中，我们了解到所有家庭成员都有独特而特殊的天赋；超人的力量，听数英里的能力，预言和预测，召唤美丽花卉和植物的能力，变形的能力，治愈的能力，以及控制天气的能力。 好吧，似乎每个人都有“礼物”，除了米拉贝尔。
米拉贝尔虽然不像其他兄弟姐妹和家庭成员那样有天赋，但却是了解家庭健康和疾病的核心人物。 此外，她能够帮助家人在一切都崩溃时将事情重新组合起来，而无需其他礼物。 您需要高可用性，但您不必打破预算、开发超自然能力或依靠奇迹来实现它。
随着电影的继续，佩帕的小儿子安东尼奥已经准备好参加他的礼物仪式。 然而，在聚会和庆祝活动期间，Abuela 注意到 Casita 的地基出现裂缝。 但她的警告无人理会。
当米拉贝尔看到裂缝时，她开始寻求找出危及卡西塔的原因以及她可以如何提供帮助。 起初，她被其他人忽视甚至斥责。 如果您发现您的 IT 基础设施存在裂缝或缺陷，或者您的架构和设计存在裂缝，您将如何应对？ 你会忽略这些裂缝，假装没有看到它们，甚至责备团队发现它们吗？ 不要忽视裂缝。 响应问题的第一个迹象通常是防止更大问题的完美方法。
在她寻求答案并拯救奇迹的魔法的过程中，多洛雷斯让米拉贝尔与她超级强壮的姐姐路易莎交谈，路易莎最初表示一切都很好，绝对没有错。 但路易莎最终开始透露，知道有一个人的重量对她来说变得太大了。
正如路易莎所说，“压倒骆驼的是压力，是永不停息的压力。”。 开发高可用性解决方案、设计和架构弹性和数据可用性并不是一个简单的过程，而且绝对不是一个人或单个团队的任务。 您的 DBA、IT 管理员和 ERP 管理员无法独自承担维护关键企业可用性的重任。 同样，一维方法不能承载四 (4) 个 9 的可用性。 相反，它需要一个完全一致的团队与完整的 HA 解决方案协同工作，以理解、设计、开发和部署工具和技术。 您的 IT 团队的角色和职责分布和定义如何？ 确保没有人独自承担 HA 的责任。
当米拉贝尔向布鲁诺寻求她正在寻找的答案时，每个人都说：“我们不谈论布鲁诺。”布鲁诺的天赋是预知，但由于他的警告和看似消极的愿景，他消失了。
作为客户体验副总裁，我帮助客户对其基础架构和集群解决方案进行健康评估。 运行状况检查完成后，并非所有客户都乐于听到他们有问题需要解决。 我们都尽我们所能避免坏消息。 但是，忽略升级、忘记维护以及淡化团队布鲁诺发现的风险不会让问题消失。 事实上，它可能会让你最担心的事情成为现实。
米拉贝尔最终找到了一条通往布鲁诺的秘密通道，发现布鲁诺从未离开，但觉得他必须破坏她的视力来保护她和他自己。
您的文化可以粉碎或创造更高可用性和弹性的空间。
米拉贝尔问布鲁诺是否一直在修补小屋的裂缝，但布鲁诺回答说他害怕裂缝。
HA 需要持续、协调的持续努力。 这项工作的一个重要部分是为那些可能危及您的应用程序或架构与执行之间的差距的 IT 漏洞找到解决方案和修复程序。
即使布鲁诺（或埃尔南多）试图修补裂缝，很明显基础问题对于散乱和肤浅的解决方案来说太多了。
查看您的基础架构并查看解决问题的方式。 您是在部署变通办法、创可贴和临时“黑客”，还是在寻找解决集群、企业可用性和灾难期间执行问题的根本原因的架构和基础解决方案？
如果您一直在部署比根本原因解决方案更多的黑客和变通方法，请找到您的 Jorge。 寻找熟练的团队成员、合作伙伴或解决方案提供商，并允许他们努力实施能够解决问题或加强基础设施的基础解决方案。
布鲁诺看到了另一个愿景，即如果 Mirable 拥抱 Isabela，Casita 就可以得救。 Mirabel 为 Isabela 提供了一个开花的机会，但 Abuela 不这么看。 Mirabel 和 Abuela 之间发生争执，Abuela 将“Casita”中的裂缝归咎于 Mirabel。 Mirabel 指责 Abuela 提出了不可能的要求、不切实际的期望和错误的希望。
Pass the Blame 是一款很棒的派对游戏，但它对于 HA、集群弹性或数据保护来说并不是很好。 我曾经帮助过一个客户，他的组织说明了责备是徒劳的。 在概念验证集群遇到导致延迟的问题后，项目经理将延迟归咎于应用程序团队。 应用程序团队责怪备份管理员，后者又责怪基础设施管理员。 在整个指责过程中，他们的集群仍然不可用，概念验证仍然停滞不前，唯一取得的进展是团队之间的愤怒裂缝越来越大。 只有当他们将这些差异放在一边时，他们才能做出解决问题所需的调整并继续成功的 POC。
“小屋”倒塌，米拉贝尔逃跑。 后来，阿尔玛找到了米拉贝尔，和解后，他们和家人和村庄一起建造了比以往更好的小屋。
当然，Encanto 的最后一幕充满了 Alma (Abuela) 忏悔的教训，例如：
但最后一课中最重要的是重建得更好、更强大、更团结。 在每次计划外或计划内的停机之后，都会从根本原因分析、经验和新的理解中吸取教训。 因此，还将有机会为您的高可用性和灾难恢复构建更强大的解决方案和架构。
考虑一个客户在发现中断是由直接部署到生产环境的代码导致后能够创建标准部署管道和 QA 系统的案例。 或者另一位客户发现磁盘和数据库警告在中断前被抑制了数周。 不要浪费停机时间带来的时间和机会。 一定要共同努力，避免孤岛、对单一优势的依赖，或者将基础设施的希望寄托在错误的事情上。
当然，您应该自己观看整部电影，但当您了解电影的魔力和音乐并了解其他几个角色的生活和教训时，HA 会有更多的教训
电影以重聚结束，米拉贝尔和牧歌站在完工的房子前。 当米拉贝尔触碰门把手时，“小屋”就恢复了生机，家和家人的神奇礼物都回来了。 试试 Encanto 的这 10 节高可用性课程，欣赏这部电影，并记住“没有什么是您不能做的……与您的客户、合作伙伴、解决方案提供商和管理员团队一起”。