SIOS APAC Portal

1月 16, 2021	我是否仍应在AWS中使用Zabbix？我是否仍应在AWS中使用Zabbix？ Amazon EC2监控 Zabbix作为集成OSS监视工具具有很高的市场份额。尽管已在内部部署环境中广泛使用它，但仍有许多在AWS环境中使用Zabbix的示例。尽管AWS还具有Amazon CloudWatch之类的监控服务，但为什么还要使用Zabbix？本节说明监视EC2实例和其他实例的好处以及配置过程。为什么使用Zabbix代替Amazon CloudWatch？在AWS环境中，所有基础架构均由AWS操作，但您必须负责Amazon EC2实例本身以及在Amazon EC2上构建的应用程序的操作。换句话说，您必须监视应用程序以确保它们正常运行，并且在出现问题时必须采取措施。Zabbix是此类监视工具的不错选择。 Zabbix的优点是不仅可以监视本地。而且还有云和虚拟环境的集成方式。鉴于标准Amazon CloudWatch仅限于监视AWS资源（CPU，内存等）， Zabbix允许您甚至详细监视应用程序的状态。以下是Zabbix的其他优点的列表。具有多个AWS账户的环境集成监控 Amazon CloudWatch在每个AWS帐户的基础上执行监视。Zabbix可以监视多个AWS账户的环境，该环境可以监视由多个账户组成的业务系统。它还不仅可以通过基于阈值的简单警报来检测异常，还可以通过组合多个阈值和条件来检测异常。可以配置详细通知以适合实际操作条件发生异常时，Amazon CloudWatch可以通过消息通知您。例如，如果系统因维护而停机，则无需通过消息通知您。在这里Zabbix允许您配置这些情况，从而抑制不必要的消息。这样，您可以确保仅在确实有错误需要解决时才通知您。没有指标保留期（监视日志）使用Amazon CloudWatch，指标最多可以存储15个月。此外，您只能按小时增量存储指标15个月，并且如果将监视间隔设置为少于60秒，则最多只能存储3小时。Zabbix允许长期存储指标，而无需更改信息的粒度。如何使用Zabbix监控AWS环境如果要在AWS中使用Zabbix，则需要创建一个Amazon EC2和数据库实例并在其上安装Zabbix。安装后，除了需要设置以下内容外，配置Zabbix的过程与内部部署基本相同。用户帐户（除了Zabbix的Admin用户之外，您还需要创建一个供生产使用的用户） Zabbix主机代理（确定从何处收集数据）项目（设置要收集的数据）触发（定义数据处于异常状态）操作（定义发生错误时要采取的操作）此外，您可以配置特定于AWS的设置，例如在AWS IAM中创建具有Zabbix必要权限的用户，这将允许Zabbix监视应用程序以及AWS环境的其他方面。使用正确的工具来满足您的监控需求并非所有公司系统都是孤立运行的，但是许多系统链接在一起以交换数据并确保整体一致性。在这些环境中，Zabbix是监视和检测多个服务器和系统中异常情况的绝佳工具。例如，如果基于DB的Web应用程序在Web应用程序服务器上存在异常，则可以禁用数据。另一方面，Zabbix具有许多配置选项，因此您将必须决定监视什么以及如何监视以及哪些情况异常。另一方面，Zabbix有很多设置，因此您必须准确地设计操作要监视的内容，要执行的操作以及要执行的操作。当然，对于关键系统来说，这样的设计是必不可少的，但是，对于相对简单的系统，例如“如果进程停止，只需重新启动它”，就无法与Zabbix监视匹配。对于此类情况，SIOS AppKeeper是一个很好的解决方案，因为它可以监视在EC2实例上运行的应用程序的服务（进程），并在检测到问题时重新启动应用程序。这使得简单的监视和操作成为可能。当然，并不是在每个系统上都必须使用Zabbix。通过为每种类型的监视使用正确的工具，您将能够更有效地操作系统。将SIOS AppKeeper添加到您的EC2监视和恢复操作中。转载自SIOS
1月 8, 2021	需要高可用性时如何选择云需要高可用性时如何选择云了解云市场许多分析公司预测，云中应用程序，数据库和解决方案的部署将越来越多。根据Gartner的说法，公司“正在以越来越快的速度迁^[1]移到云中”。实际上，Gartner和其他分析师预计，云迁移和部署的步伐将继续加快，这在很大程度上是由于云技术创新的步伐所推动。在MarkoInsights的Kurt Marko发表的“技术目标”文章中，Marko指出“由于在公共云中具有弹性，可扩展性和按需性质，因此无法在本地复制在云中进行的创新步伐”服务。” 我们看到越来越多的公司仅将云用于其业务非必需的DevOps应用程序和数据库，现在正将需要高可用性保护的关键任务应用程序，ERP和数据库迁移到云中。如果您正在考虑迁移到云-似乎您已经迁移到云-有几项关键要理解何时需要高可用性。熟悉云高可用性选项要为云或混合云部署计划适当的可用性解决方案，请考虑可用性（99.9％正常运行时间）和高可用性（99.99％正常运行时间）的痛点。您还需要了解迁移到云的计划，以了解可用于高可用性的选项。著名的分析师和专家建议寻找一种解决方案，该解决方案不仅可以减轻和减轻迁移工作负载的痛苦，而且可以为您在云体系结构的整个生命周期中提供一种平衡，全面的可用性方法。请注意，考虑可以为一部分工作负载提供保护和高可用性的解决方案也是明智的选择，这些工作负载有一天可能会从云中退回到本地环境中。在云中比较可用性选项时，需要考虑以下十件事： 1。部署方法。是否可以使用映像，CLI，UI或其他可重复解决方案（例如云形成模板或打包脚本）来部署您正在考虑的可用性解决方案。 2。系统要求。最值得注意的是，请考虑操作系统（OS），磁盘，CPU和内存要求。 3。部署环境。您的可用性选项仅支持本地，一个或多个公共云，还是可以支持混合和/或混合云部署。还提供SaaS产品吗？ 4。应用程序保护的广度和深度。 “广度”意味着可以保护哪些类型的应用程序，数据库，前端，网络和基础结构组件？是否有用于添加新应用程序和变体的灵活框架？ “深度”的含义–解决方案是否可识别应用程序–并能够在整个应用程序故障转移/故障回复过程中维护特定于应用程序的最佳实践？ 5，性能要求。我们经常想到RTO和RPO，但是解决方案的其他性能需求又如何呢？您的可用性解决方案会在故障转移时引起性能问题吗？ 6。弹性要求。可用性解决方案可以支持多大的集群？，它可以检测到多少故障和故障并从中恢复。在保持元数据同步的同时如何处理复制？ 7 可维护性和维护。可用性供应商是否具有广泛的可用性需求和配置方面的经验？他们是否有长寿，是否有旨在解决可能超出其解决方案的问题的支持系统？它们可以帮助您在系统管理和维护（补丁，升级和常规维护）期间最大程度地减少中断和计划内的停机时间。 8。总拥有成本。整个行业和服务都致力于帮助您计算总拥有成本，因此我们在这里不做介绍。可以说，您的计算对于组织，云提供商，应用程序和IT团队而言是唯一的。您应该考虑可用性解决方案供应商是否可以帮助您确定节省利用率，许可和其他成本的策略？解决方案是否可以自动执行手动任务，从而减少IT劳动时间？ 9。许可和定价模型。您如何消耗软件成本？是否有订阅费，订阅模式，随用随付产品，自带许可证（BYOL）或灵活选项的组合？您将如何启用产品许可？是否有基于虚拟机部署详细信息（例如地址，主机名，MAC地址）的许可证服务器，许可证服务或加密密钥。 10。对IT人员的影响。该解决方案需要多少培训？如果发生应用程序故障或灾难，需要多少人工干预？是否需要维护专用的脚本？谁负责日常维护？权衡利弊像每个重要的决定一样，您需要了解您的权衡并选择最佳的平衡来满足您的需求。例如，最近我问一个朋友推荐一款好的步行鞋。我买了一双他喜欢的鞋-注意到它们的重量轻，织物的坚固耐用，以及时尚。我参加了他们的第一次长跑训练，此后立即捐赠了我的第一双“单跑”鞋。当我去“ Fleet Feet”征询专家的意见时，我最终得到了更重的鞋子，更透气的面料（也不太耐用），以及无与伦比的丑陋程度。我在外观和功能之间进行了权衡，以适应我的需求和预算。就像跑鞋一样，没有解决方案适合所有公司，每个应用程序，每个数据库以及每个可能的服务器和体系结构。您可以自由地停止寻找它。取而代之的是权衡取舍权衡活动，以确定最适合您公司需求的活动。考虑一下您的权衡。例如，如果您确定自己将成为一家完整的Microsoft公司，那么在评估过程中，GCP和AWS支持的重要性应略低一些。考虑您的IT基础架构动态全面考虑整个IT基础架构（在本地和在云中）的可用性。最好用另一个类比解释这样做的原因。 2018年，我担任南卡罗来纳州哥伦比亚市一个无家可归者和饥饿者进餐的外展计划的协调员。我们小组每周开会一次，为100多名男女老少提供饭食和希望的信息。当我们考虑扩展时–增加一周中的更多天，更多小时或其他服务，我们必须考虑超出简单的计划要求。知道我们正在为依赖我们的客户提供关键服务后，我们必须考虑所有影响我们长期持续提供这些服务的能力的因素，例如：成本，我们团队成员的年龄，外部义务，在母公司内部实现目标，风险因素和其他动态的替代方法。在选择解决方案时，在了解市场，熟悉各种选择并权衡取舍之后，最后一步是考虑整体环境中的其他各种因素。该解决方案能否满足您整体业务的需求？您的关键数据会受到保护吗？可以保护最终用户的生产力免受停机影响吗？迁移到云将需要进行哪些培训，这将如何影响您管理或维护所选解决方案的能力？在您的云之旅中将添加，删除或更改哪些IT角色？应用程序可用性的任何责任将移交给任何业务部门所有者吗？以及责任转移或团队组成将如何改善或减少您获得成功的整体潜力。考虑您的团队是否需要采取逐步的方法，首先迁移较小的工作负载。作为客户体验副总裁，我已经看到了各种各样的云迁移计划，其中一些简单易懂，而其他却极具破坏性。在一个例子中，客户迁移到云上引起了很大争议，因为管理层将其视为消除整个IT部门的机会。我并不是建议您参与政治活动，但您应该意识到这些复杂项目中的所有因素。迁移到云应该可以节省金钱，时间和资源，同时还可以提高可用性和弹性。无论选择哪种云，请确保您考虑了这些技巧并选择了相应的可用性解决方案，该解决方案使您可以灵活地在所需的配置中提供所需的保护。了解有关SIOS的云高可用性选项的更多信息。 – SIOS客户体验副总裁Cassius Rhue 经SIOS许可转载
12月 30, 2020	如何以更好的结果克隆云中的可用性如何以更好的结果克隆云中的可用性电影提示–多重性多样性是一部1996年的美国科幻喜剧电影，由迈克尔·基顿（Michael Keaton）饰演道格·金尼（Doug Kinney）。当一位科学家提出克隆他的建议时，道格同意只是让实现他的时间表和承诺更加容易。但是后来他的副本开始复制自己。到最后一次复制时，重点已经清楚了。克隆可能并非一帆风顺，或者至少带有一些强烈的警告，挑战和副作用。著名的原始《星际迷航》插曲“麻烦与麻烦”也说明了类似的观点。就像在大屏幕（或小屏幕）上进行克隆一样，在云中进行克隆是一个很好的工具，但并非没有挑战。在云中克隆可用性时如何获得更好结果的提示 1.克隆操作系统这听起来很明显，但是我已经看到它在真实的企业环境中不止一次发生。如果克隆了无法正常运行的系统，则克隆将同样无法正常运行，并且在还原时会出现问题。确保您创建的克隆来自可操作和功能的系统。 2.将数据同步到磁盘并在还原时重新同步文件系统的完整性至关重要。如果您不确定自己的应用程序和/或VM处于一致状态，那么大多数供应商将无法保证所生成的映像已经生成。由于快照仅捕获发出快照命令时已写入卷的数据，因此这可能会排除任何应用程序或操作系统已缓存的数据。确保数据已正确同步到文件系统是重要的一步，在集群环境中绝对至关重要。从映像还原时，记住文件系统完整性也很重要。如果您正在使用数据复制并将映像还原为群集中的源或目标，则确保两个节点同步至关重要。否则可能会导致故障转移或切换时文件系统出错，甚至可能导致数据丢失。在云中克隆可用性以获得所需的结果。 3.停止您的实例许多环境不需要您停止实例来创建映像，而某些环境（例如AWS）将在制作副本之前执行关闭节点电源的步骤。但是，许多工具和站点建议确保应用程序已停止并且文件系统访问已正确同步，以避免损坏，完整性丧失或创建启动，停止或运行已安装的应用程序时遇到问题的映像。 4.标记云中的所有内容（节点，磁盘，NIC等）尽管创建克隆是一项免费操作，但生成的磁盘和组件通常不是。例如，AWS声明“对快照收费，直到注销映像并删除快照为止。”如果未标记事物，则知道正在使用或未使用的东西以及创建它的原因可能会成为问题。它还会受到短暂的记忆或现有团队成员注意力不集中的影响。标记所有内容。 5.经常修剪克隆和快照（节省成本和减少头痛）修剪旧快照和克隆不仅可以节省成本，而且还可以减少麻烦。较旧的快照可能会带来重新引入已在较新副本中解决或解决的漏洞的风险。作为SIOS Technology Corp.客户体验副总裁，当我们与从快照还原的客户一起工作时，我亲眼看到了后果。他们在重新启动应用程序时遇到了几个问题。在进行故障排除之后，我们确定克隆正在运行较旧版本的安全软件。用户配置文件中存储的缓存凭据和元数据不再与存储在外部安装的数据驱动器上的实际应用程序数据同步。 6.限制或限制云中克隆的克隆最后，并不是您在云中所做的一切都需要克隆。考虑限制要克隆的工作负载的类型，并限制可以在环境中创建克隆的数量或角色。在电影中，当道格的克隆人引发了自己的一系列重复时，已经不堪重负的道格（迈克尔·基顿）被迫投入更多精力来管理他的许多克隆人，同时试图掩盖他从妻子身上造成的混乱。在云中以更好的结果实现克隆可用性并不困难。小心地进行克隆，以避免进行更多的工作，并避免使用原本可以使您的工作更轻松，环境更安全的工具增加风险。 –客户体验副总裁Cassius Rhue 转载自SIOS
12月 26, 2020	新产品发布：适用于Linux的SIOS保护套件9.5.1 新产品发布：适用于Linux的SIOS保护套件9.5.1 SIOS会不断更新我们的产品，以满足客户不断增长的对关键任务应用程序的高可用性的需求。我们很高兴宣布SIOS Protection Suite for Linux版本9.5.1全面上市！此发行功能增加了对更广泛平台的支持，并增强了我们的命令行界面功能。关键更新包括支持以下操作系统和平台：VMware Vsphere 7，Red Hat Enterprise Linux（RHEL）8.2，Oracle Linux 8.2，CentOS 8.2，SUSE Linux Enterprise（SLES）12 SP5，RHEL 7.8，CentOS 7.8，Oracle Linux 7.8，SLES 15 SP2 CLI自动安装和增强的设置脚本-更快，更轻松地实施扩展的CLI支持ARK和克隆–支持简单，一致地部署多个集群经SIOS许可转载
12月 22, 2020	云迁移停滞的六个原因云迁移停滞的六个原因越来越多的客户正在寻求利用云的灵活性，可扩展性和性能。随着做出这一转变的应用程序，解决方案，客户和合作伙伴的数量增加，请确保您的迁移不会停止。避免以下六个原因导致云迁移停滞 1.不完整的云迁移项目计划人们普遍认为，项目计划是项目成功的关键因素。计划在帮助指导利益相关者，多样化的实施团队和合作伙伴完成项目阶段中起着至关重要的作用。规划可帮助确定所需目标，使资源和团队与这些目标保持一致，降低风险，避免错过最后期限，并最终在云中提供高可用性解决方案。计划不完整和计划不完整通常是导致项目停滞的主要原因。在第九个小时，确定了关键依赖性。在服务器意外重启期间，将识别应用程序监视和HA漏洞（请参阅下文）。确保您的云迁移有一个计划，然后执行该计划。 2.在本地过度设计 “这就是我们在本地节点上做到的方式”，这是开始最近的客户对话的短语。当客户尝试迁移到云时，他们与SIOS专业服务项目经理Edmond Melkomian进行了接触。在一次发现会议中，Edmond能够发现许多与内部部署和云架构有关的过度设计的项目。对于某些项目，复制在场所进行的操作可能会成为膨胀，复杂和延迟的简历。分析您的架构和迁移计划，并无情地消除过度设计的组件和设计，尤其是在网络和存储方面。 3.预留空间不足控制成本和防止蔓延是云迁移的重要和关键方面。但是，一些担心每小时收费以及磁盘和带宽相关成本的客户陷入了配置不足的陷阱。在此陷阱中，资源的大小不正确，例如具有错误的速度特征的磁盘，使用错误的CPU或内存占用量来计算资源或具有错误数目的节点的群集。在这种配置不足的情况下，当用户接受测试（UAT）开始并且预期/预期的工作负载在容量不足的资源上造成日志阻塞时，就会出现问题。或者目标节点的成本优化无法在故障转移方案中正确处理资源。虽然在云中调整虚拟机的大小是一个简单的过程，但是这些大小调整问题通常会造成延迟，而架构师和首席财务官则试图了解重新配置资源的影响。 4.内部IT流程每个伟大的企业公司都有一套内部流程，您的团队和公司也不例外。在流程中，IT流程通常是关键的，可能会对您的云迁移策略的成功产生重大影响。过去，许多公司的采购和采购流程都很漫长，包括投标，规模调整指南，订单批准，服务器准备和配置以及最终部署。云过程极大地改变了获取，部署计算，存储和网络资源的方式。但是，如果您的流程跟不上云的速度，那么当计划更改时，迁移可能会遇到障碍。 5.高可用性计划不佳云迁移可能会停止的另一个原因涉及高可用性计划。高可用性不仅需要一捆工具或企业许可证。HA需要仔细，彻底和周到的系统设计。部署高可用性解决方案时，您的计划将需要考虑容量，冗余以及恢复和更正的要求。通过计划，可以正确识别需求，提出解决方案，考虑风险并管理部署和验证的依赖性。如果没有计划，项目和部署将容易受到风险，单点故障问题，安装不当以及缺少应用程序保护或恢复策略的层次和级别的威胁。通常，在缺乏高可用性计划的情况下，项目会停顿，而需求却没有得到解决。 6.不完整或无效的测试罗恩（Ron）是将其最终客户迁移到云的合作伙伴，计划在接下来的三天周末上线。 “执行/不执行”的最后决定点是在登台服务器上进行了一批用户接受测试。第一次测试失败。为了弥补由于其他迁移障碍而造成的时间浪费，Ron和团队跳过了一些测试案例，这些测试案例与将最新的安全性和备份软件最终集合集成到支持补丁的最新OS上有关。这种模拟负载是新创建的服务器上的第一个负载，它解决了Ron体系结构中的一系列问题，包括内核错误，CPU和内存供应问题以及存储布局和容量问题。该项目被推迟了四个多星期，以解决客户的信心，正确的测试和验证，调整大小和架构以及应用软件和操作系统修复的问题。云的前景令人鼓舞，精心计划的云迁移将使您和您的团队能够利用这些优势。无论您是开始迁移还是正在进行云迁移，我们希望本文可以帮助您更多地了解常见的陷阱，以期可以避免它们。 –客户体验副总裁Cassius Rhue 转载自SIOS

Results 1-5 of 695
Page 1 of 139 >

加入我们的邮件列表

First Name Last Name Email Address
搜索