SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

  • Home
  • 产品
    • SIOS DataKeeper for Windows
    • SIOS Protection Suite for Linux
  • 新闻与活动
  • 服务器集群简单化
  • 成功案例
  • 联系我们
  • English
  • 中文 (中国)
  • 中文 (台灣)
  • 한국어
  • Bahasa Indonesia
  • ไทย

Archives for 12月 2020

如何以更好的结果克隆云中的可用性

12月 30, 2020 by Jason Aw Leave a Comment

如何以更好的结果克隆云中的可用性

如何以更好的结果克隆云中的可用性

电影提示–多重性

多样性是一部1996年的美国科幻喜剧电影,由迈克尔·基顿(Michael Keaton)饰演道格·金尼(Doug Kinney)。 当一位科学家提出克隆他的建议时,道格同意只是让实现他的时间表和承诺更加容易。 但是后来他的副本开始复制自己。 到最后一次复制时,重点已经清楚了。 克隆可能并非一帆风顺,或者至少带有一些强烈的警告,挑战和副作用。 著名的原始《星际迷航》插曲“麻烦与麻烦”也说明了类似的观点。

就像在大屏幕(或小屏幕)上进行克隆一样,在云中进行克隆是一个很好的工具,但并非没有挑战。

在云中克隆可用性时如何获得更好结果的提示

1.克隆操作系统

这听起来很明显,但是我已经看到它在真实的企业环境中不止一次发生。 如果克隆了无法正常运行的系统,则克隆将同样无法正常运行,并且在还原时会出现问题。 确保您创建的克隆来自可操作和功能的系统。

2.将数据同步到磁盘并在还原时重新同步

文件系统的完整性至关重要。 如果您不确定自己的应用程序和/或VM处于一致状态,那么大多数供应商将无法保证所生成的映像已经生成。 由于快照仅捕获发出快照命令时已写入卷的数据,因此这可能会排除任何应用程序或操作系统已缓存的数据。 确保数据已正确同步到文件系统是重要的一步,在集群环境中绝对至关重要。

从映像还原时,记住文件系统完整性也很重要。 如果您正在使用数据复制并将映像还原为群集中的源或目标,则确保两个节点同步至关重要。 否则可能会导致故障转移或切换时文件系统出错,甚至可能导致数据丢失。 在云中克隆可用性以获得所需的结果。

3.停止您的实例

许多环境不需要您停止实例来创建映像,而某些环境(例如AWS)将在制作副本之前执行关闭节点电源的步骤。但是,许多工具和站点建议确保应用程序已停止并且文件系统访问已正确同步,以避免损坏,完整性丧失或创建启动,停止或运行已安装的应用程序时遇到问题的映像。

4.标记云中的所有内容(节点,磁盘,NIC等)

尽管创建克隆是一项免费操作,但生成的磁盘和组件通常不是。例如,AWS声明“对快照收费,直到注销映像并删除快照为止。”如果未标记事物,则知道正在使用或未使用的东西以及创建它的原因可能会成为问题。 它还会受到短暂的记忆或现有团队成员注意力不集中的影响。标记所有内容。

5.经常修剪克隆和快照(节省成本和减少头痛)

修剪旧快照和克隆不仅可以节省成本,而且还可以减少麻烦。较旧的快照可能会带来重新引入已在较新副本中解决或解决的漏洞的风险。作为SIOS Technology Corp.客户体验副总裁, 当我们与从快照还原的客户一起工作时,我亲眼看到了后果。 他们在重新启动应用程序时遇到了几个问题。 在进行故障排除之后,我们确定克隆正在运行较旧版本的安全软件。 用户配置文件中存储的缓存凭据和元数据不再与存储在外部安装的数据驱动器上的实际应用程序数据同步。

6.限制或限制云中克隆的克隆

最后,并不是您在云中所做的一切都需要克隆。 考虑限制要克隆的工作负载的类型,并限制可以在环境中创建克隆的数量或角色。

在电影中,当道格的克隆人引发了自己的一系列重复时,已经不堪重负的道格(迈克尔·基顿)被迫投入更多精力来管理他的许多克隆人,同时试图掩盖他从妻子身上造成的混乱。 在云中以更好的结果实现克隆可用性并不困难。 小心地进行克隆,以避免进行更多的工作,并避免使用原本可以使您的工作更轻松,环境更安全的工具增加风险。

–客户体验副总裁Cassius Rhue

转载自SIOS

Filed Under: 服务器集群简单化

新产品发布:适用于Linux的SIOS保护套件9.5.1

12月 26, 2020 by Jason Aw Leave a Comment

新产品发布:适用于Linux的SIOS保护套件9.5.1

SIOS会不断更新我们的产品,以满足客户不断增长的对关键任务应用程序的高可用性的需求。 我们很高兴宣布SIOS Protection Suite for Linux版本9.5.1全面上市!此发行功能增加了对更广泛平台的支持,并增强了我们的命令行界面功能。

新产品发布:适用于Linux的SIOS保护套件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许可转载

Filed Under: 服务器集群简单化

云迁移停滞的六个原因

12月 22, 2020 by Jason Aw Leave a Comment

您的云迁移停滞的六个原因

 

 

云迁移停滞的六个原因

越来越多的客户正在寻求利用云的灵活性,可扩展性和性能。 随着做出这一转变的应用程序,解决方案,客户和合作伙伴的数量增加,请确保您的迁移不会停止。

避免以下六个原因导致云迁移停滞

1.不完整的云迁移项目计划

人们普遍认为,项目计划是项目成功的关键因素。 计划在帮助指导利益相关者,多样化的实施团队和合作伙伴完成项目阶段中起着至关重要的作用。 规划可帮助确定所需目标,使资源和团队与这些目标保持一致,降低风险,避免错过最后期限,并最终在云中提供高可用性解决方案。计划不完整和计划不完整通常是导致项目停滞的主要原因。在第九个小时,确定了关键依赖性。 在服务器意外重启期间,将识别应用程序监视和HA漏洞(请参阅下文)。 确保您的云迁移有一个计划,然后执行该计划。

2.在本地过度设计

“这就是我们在本地节点上做到的方式”,这是开始最近的客户对话的短语。 当客户尝试迁移到云时,他们与SIOS专业服务项目经理Edmond Melkomian进行了接触。在一次发现会议中,Edmond能够发现许多与内部部署和云架构有关的过度设计的项目。 对于某些项目,复制在场所进行的操作可能会成为膨胀,复杂和延迟的简历。 分析您的架构和迁移计划,并无情地消除过度设计的组件和设计,尤其是在网络和存储方面。

3.预留空间不足

控制成本和防止蔓延是云迁移的重要和关键方面。但是,一些担心每小时收费以及磁盘和带宽相关成本的客户陷入了配置不足的陷阱。在此陷阱中,资源的大小不正确,例如具有错误的速度特征的磁盘,使用错误的CPU或内存占用量来计算资源或具有错误数目的节点的群集。在这种配置不足的情况下,当用户接受测试(UAT)开始并且预期/预期的工作负载在容量不足的资源上造成日志阻塞时,就会出现问题。或者目标节点的成本优化无法在故障转移方案中正确处理资源。 虽然在云中调整虚拟机的大小是一个简单的过程,但是这些大小调整问题通常会造成延迟,而架构师和首席财务官则试图了解重新配置资源的影响。

4.内部IT流程

每个伟大的企业公司都有一套内部流程,您的团队和公司也不例外。在流程中,IT流程通常是关键的,可能会对您的云迁移策略的成功产生重大影响。 过去,许多公司的采购和采购流程都很漫长,包括投标,规模调整指南,订单批准,服务器准备和配置以及最终部署。云过程极大地改变了获取,部署计算,存储和网络资源的方式。但是,如果您的流程跟不上云的速度,那么当计划更改时,迁移可能会遇到障碍。

5.高可用性计划不佳

云迁移可能会停止的另一个原因涉及高可用性计划。 高可用性不仅需要一捆工具或企业许可证。HA需要仔细,彻底和周到的系统设计。部署高可用性解决方案时,您的计划将需要考虑容量,冗余以及恢复和更正的要求。 通过计划,可以正确识别需求,提出解决方案,考虑风险并管理部署和验证的依赖性。 如果没有计划,项目和部署将容易受到风险,单点故障问题,安装不当以及缺少应用程序保护或恢复策略的层次和级别的威胁。通常,在缺乏高可用性计划的情况下,项目会停顿,而需求却没有得到解决。

6.不完整或无效的测试

罗恩(Ron)是将其最终客户迁移到云的合作伙伴,计划在接下来的三天周末上线。 “执行/不执行”的最后决定点是在登台服务器上进行了一批用户接受测试。第一次测试失败。为了弥补由于其他迁移障碍而造成的时间浪费,Ron和团队跳过了一些测试案例,这些测试案例与将最新的安全性和备份软件最终集合集成到支持补丁的最新OS上有关。 这种模拟负载是新创建的服务器上的第一个负载,它解决了Ron体系结构中的一系列问题,包括内核错误,CPU和内存供应问题以及存储布局和容量问题。 该项目被推迟了四个多星期,以解决客户的信心,正确的测试和验证,调整大小和架构以及应用软件和操作系统修复的问题。

云的前景令人鼓舞,精心计划的云迁移将使您和您的团队能够利用这些优势。 无论您是开始迁移还是正在进行云迁移,我们希望本文可以帮助您更多地了解常见的陷阱,以期可以避免它们。

–客户体验副总裁Cassius Rhue

 

 

转载自SIOS

Filed Under: 服务器集群简单化

计算云中的应用程序可用性

12月 18, 2020 by Jason Aw Leave a Comment

计算云中的应用程序可用性

计算云中的应用程序可用性

在云中部署关键业务应用程序时,您要确保它们具有高可用性。 好消息是,如果您进行适当的计划,则可以实现99.99%(4-nines)的可用性或更高。 但是,计算您的真实可用性可能并不像看起来那样简单。

在考虑可用性时,您必须考虑使访问应用程序成为可能的关键组件,我将其称为可用性链。 可用性链的组成部分是:

  • 计算
  • 网络
  • 存储
  • 应用
  • 依赖服务

您的应用程序只有最弱的链接才可用,并且您向链中添加的每个其他链接的停机时间都会成倍增加。让我们检查每个链接。

计算可用性

三个主要的云服务提供商中的每一个都有一些相似之处。 这三个平台的共同点是它们将致力于计算的服务级别协议(SLA)。

当您在不同可用性区域中配置了两个或多个VM时,所有三个VM的公共云提供商的SLA为99.99%。请记住,此SLA仅保证在任何给定时间对其中一个VM的远程访问,它不保证VM内运行的服务或应用程序的可用性。如果在单个数据中心内部署单个VM,则此SLA的范围从“每小时90%”(AWS)到99.5%(Azure和GCP)或99.9%(使用Premium SSD时,Azure单个VM)。

真正的高可用性从99.99%开始,因此第一步是确保您的应用程序可用,是确保该应用程序分布在两个或多个跨越可用区的VM中。 通过将两个VM分布在两个可用区中,可以为您提供至少其中一个VM的99.99%的可用性,您可以得出以下理论:如果三个VM分布在三个可用区中,则您的可用性将甚至超过99.99%。 尽管云提供商的SLA永远不会保证可用性超过99.99%(无论正在使用的可用性区域有多少),但是如果您使用纯统计信息,您可能会得出结论,您的可用性可能会高达99.999999%或8倍可用性,每月停机时间为26.30毫秒。

1-(。0001 * .0001)= .99999999

具有三个可用区的99.999999%可用性?

不要四处引用那个数字。 但是请记住,如果两个可用性区域可以为您提供99.99%的可用性,这是有道理的。 可以肯定地说,三个可用区将为您提供超过99.99%的可用性。

计算只是可用性链中的一个环节。 我们仍然必须解决网络,存储和其他相关服务,这些都代表了可能的故障点。

网络可用性

为了使您的应用程序可用,客户端与应用程序之间的每个网络跃点以及应用程序依赖的所有资源都必须可用,并且必须在可容忍的延迟范围内工作。 您需要了解数据库服务器,应用程序服务器,Web服务器和客户端之间的网络链接,以准确了解网络可能在哪里发生故障。 请记住,可用性链中的链接越多,总体可用性就越低。

尽管标准计算SLA涵盖了同一vNet中虚拟机之间的网络可用性,但是您可能仍在使用其他网络服务。 这只是您可能会使用的网络服务的一些示例,这些示例会影响整体应用程序的可用性。

快速路线– 99.95%
V
PN网关– 99.9%至99.95%
负载均衡器– 99.99%
流量管理器–
99.99%
弹性负
载平衡器– 99.99%
直接连接– 99.9%– 99.99%

基于到目前为止所学的知识,让我们看一下跨两个可用区部署的应用程序的可用性。

99.99%的计算可用性

99.99%负载均衡器可用性

.9999 * .9999 = .9998

99.98%的可用性=每月约9分钟的停机时间

既然我们已经解决了计算和网络可用性问题,那么让我们继续进行存储。

存储空间

现在这里是故事多毛的地方。 看一下以下存储SLA

https://azure.microsoft.com/zh-CN/support/legal/sla/storage/v1_5/

https://cloud.google.com/storage/sla

https://aws.amazon.com/compute/sla/

显然,Azure和Google在块存储解决方案上提供了99.9%的SLA。 AWS在这里没有特别提及EBS。 他们只谈论虚拟机,并按小时而不是其他云提供商那样按月衡量其单实例虚拟机的可用性。 为了便于讨论,让我们使用Azure和GCP均已发布的99.9%可用性保证。

在前面的示例的基础上,让我们为方程式添加一些存储空间。

99.99%的计算可用性

99.99%负载均衡器可用性

99.9%托管磁盘

.9999 * .9999 * .999 = .9988

99.88%的可用性=每月约53分钟的停机时间。

53分钟的停机时间比我们在先前示例中计算的9分钟的停机时间要长得多。 我们如何才能最大程度地降低99.9%的存储可用性的影响? 我们必须在存储中建立更多的冗余!

幸运的是,在计划应用程序可用性时,我们通常会包括存储冗余。 例如,当我们站起Web服务器时,每个Web服务器通常会将数据存储在本地连接的磁盘上。 部署域控制器时,Microsoft Active Directory负责在所有域控制器之间复制AD信息。 对于类似SQL Server的情况,我们利用AlwaysOn可用性组或SIOS DataKeeper来保持数据在本地连接的磁盘之间的同步。

我们跨不同可用性区域分布的数据副本越多,我们越有可能幸免于难。

例如,将数据存储在不同可用性区域中的两个不同磁盘上的应用程序将受益于冗余,而不是99.9%的可用性,它更有可能实现99.9999%的存储可用性。

1 –(.001 * .001)= .999999

如果将其放到先前的方程式中,图片将开始看起来更亮一些。

.9999 * .9999 * .999999 = .9998

99.98%的可用性=约9分钟的停机时间

通过跨多个可用区(因此跨多个磁盘)复制数据,我们有效地减轻了与云存储相关的停机时间。

应用程序和相关服务的可用性

您已尽力确保计算,网络和存储的可用性。 但是应用程序本身呢? 某些应用程序可以通过在同一应用程序的多个实例之间进行负载平衡来横向扩展并提供冗余。 想想典型的Web服务器场,您通常可以在其中平衡五台服务器之间的Web请求。 如果您丢失一台服务器,则负载平衡器仅将其从旋转中删除,直到再次响应为止。

其他应用程序则需要更多的维护和监视。 以SQL Server为例。 通常,“始终在线可用性组”或“故障转移群集实例”用于监视数据库可用性,并在数据库由于应用程序或系统级故障而变得无响应时使用恢复操作。 尽管没有针对SQL Server可用性解决方案的已发布SLA,但通常公认的是,如果为高可用性进行了正确配置,则SQL Server可以提供99.99%的可用性。

您可能依赖于其他基于云的服务,例如托管的Active Directory,托管的DNS,微服务,甚至云门户本身的可用性都应纳入整体可用性方程中。

概要

应用程序可用性是所有活动部分的总和。 仅在一个区域中跳过会成倍地影响应用程序的整体可用性。 花点时间研究可用性链中的所有链接是否存在漏洞,包括计算,网络,存储,应用程序和相关服务。

总的来说,这里列出的数字是最坏的情况,希望您的实际可用性超过已发布的SLA。 做好家庭作业,并提防任何不能保证99.99%可用性的服务,这是被认为具有高可用性的典型阈值。

本文未解决人为错误和安全问题。 您可以使您的应用程序尽可能地高可用性。 但是,如果您尚未采取措施保护应用程序免受外部威胁和愚蠢的人为错误,那么在可用性方面,所有赌注都没有了。

转载自《星际争霸》的许可

Filed Under: 服务器集群简单化

使用Datadog进行Amazon EC2监控? 与SIOS AppKeeper配对以进行自动修复

12月 11, 2020 by Jason Aw Leave a Comment

Amazon EC2监控SIOS AppKeeper

使用Datadog进行Amazon EC2监控? 与SIOS AppKeeper配对以进行自动修复

您是否曾经想过:“如果Datadog能够监视我们的Amazon EC2服务并在检测到故障时自动重新启动它们,那将是一件很好的事吗?”我也有同样的想法,因此决定自己尝试一下。

SIOS AppKeeper会自动监视Amazon EC2实例的故障,并在检测到故障时自动重启实例甚至重启服务。我心想:“如果将Datadog的监视功能与AppKeeper的自动修复功能结合起来,该怎么办?”

它有效,这就是我的工作方式。

如果您已经在使用Datadog,并且有兴趣自己尝试一下,请在本文结尾处注册以访问我们的API。

这是我设置AppKeeper以便从Datadog接收警报并在检测到停机时重新启动Amazon EC2上的Web服务器的步骤。

为了成功运行此实验,我们已经在Amazon EC2(使用Linux 2)上运行了Datadog帐户,AppKeeper帐户和NGINX Web服务器。

如何将Datadog与AppKeeper集成以提供自动修复

第一步:从AppKeeper获取重启API令牌

通过以下表单请求用于Datadog集成的API令牌:

https://mk.sios.jp/BC_AppKeeper_Datadog_api_application

如果您从表单中请求,令牌将被发送到您提供的电子邮件地址。

第二步:在AppKeeper中创建租户

下一步是在AppKeeper中注册受监视实例所属的AWS账户。 (AppKeeper将注册的AWS账户称为“租户”。)

https://sioscoati.zendesk.com/hc/zh-CN/articles/900000123406-Quick-Start-Guide#h_39404cfb-4a76-450f-99c2-e197cc63e50d

第三步:在AWS中创建IAM角色

然后,我在AWS中创建了一个IAM角色(您需要使用它来设置AppKeeper帐户)。如果您不熟悉此过程,请按以下说明进行操作。

第四步:在AppKeeper中添加租户

下一步是在AppKeeper中添加“租户”(AppKeeper认为AWS账户为“租户”)。这是有关执行此操作的详细说明的链接。

第五步:在Datadog中设置综合测试

然后,我需要为我们要监视的Nginx服务器(EC2实例)配置Datadog的轮廓监视。方法如下:

打开Datadog仪表板,然后从菜单中选择UX监视>综合测试。

单击[New Test]右上角的按钮,然后选择[New API Test]创建轮廓监视案例。

在表单中输入以下信息以创建概要监视案例。

  1. 选择请求类型
    选择“ HTTP”。
  2. 定义请求:
    设置以下值。
    网址:获取http:// {{{EC2 IP地址}}
    名称:AppKeeper Datadog集成测试(任何名称)
    地点:东京

3。 指定测试频率
没变化

4。 定义断言
点击“新断言”并设置以下值

什么时候 :

[status code][is][200]
5, 定义警报条件
没变化

6。通知您的团队
没变化

第六步:在Datadog中运行综合测试

完成上述输入后,请按“创建测试”以创建用于外部监视的测试用例。

结果可见,我们可以在“测试结果”部分中看到网络服务器正常工作。

这就是使用Datadog配置Synthetics监视所需要做的全部工作。

第七步:将AppKeeper设置为接收合成警报

接下来,我必须将AppKeeper设置为通知目标。从Datadog菜单中,转到Integrations,然后选择Integrations选项卡。

在搜索框中,输入“ Webhooks”以查找Webhooks集成。

单击“可用”以在您的Datadog帐户中启用Webhooks集成。 (一旦启用,它将显示在“已安装”列中。)

单击“配置”以打开Webhooks集成配置页面。

在页面底部的“ Webhooks”列中,单击“新建+”以创建新的Webhooks通知目标。 对于参数,输入以下内容

名称:集成名称(任何名称)

网址:https://api.appkeeper.sios.com/v2/integration/ {{AWS账户ID}} / actions / recover

有效载荷

{

“ instanceId”:“ {{EC2实例ID}}”,

“名称”:“ nginx”

}

自定义标题:选中该复选框并输入以下内容

{
“内容类型”:“应用程序/ json”,
“ accept”:“ application / json”,
“ appkeeper-integration-token”:“ {{获取AppKeeper外部集成令牌}}中获得的令牌”
}

完成后,按“保存”。

第八步:将AppKeeper连接到综合测试

接下来,我必须配置AppKeeper(注册的Webhooks集成),以便在发生Synthetics监视警报时调用它。

从菜单的“ UX监视”>“综合测试”中打开在“使用Datadog配置综合监视”中设置的测试用例。

从右上方的变速箱中选择“编辑测试详细信息”,然后在“ 5.输入以下值”中输入以下值。 通知您的团队”框以保存更改。

@webhook-{{Datadog中Webhook集成的名称}}

※您可以设置“如果显示器尚未解决则重新通知”。如果AppKeeper第一次无法恢复,则可以重试。测试不是必需的,但是我们建议您将其设置为([10 minutes]最小间隔)。

安装完成。

第九步:通过再次运行测试来确认集成

然后,我确认如果Datadog检测到它关闭,AppKeeper将还原Web服务器。

打开您刚刚从Datadog中的UX监视>综合测试中设置的综合监视测试用例。

单击右上角的“恢复测试”,然后打开“合成”监视。

现在,Datadog将定期执行Synthetics监视。

测试结果表明服务器已成功访问。

接下来,我创建了网络服务器的伪故障,以测试AppKeeper的自动修复。

由于很难造成真正的失败,因此我停止了该服务,并造成了无法查看网页的情况。为此,我连接到使用SSH安装Nginx服务器并停止Nginx的EC2实例。

sudo systemctl停止nginx

短暂等待后,Datadog检测到Web服务器不再可访问。

Datadog中的“综合测试”页面还显示测试用例失败。

如果测试用例失败,Datadog将通知AppKeeper Synthetics监视失败。

当AppKeeper收到通知时,它将自动尝试重新启动Nginx。

因此,如果您稍等片刻,就会发现Datadog的Synthetics监控检查将再次通过。

另外,如果您登录到AppKeeper仪表板,则会看到恢复已执行。

–

在本练习中,我以Web服务器(Nginx)为例,通过Datadog自动执行检测故障并通过AppKeeper恢复服务的过程。

通过将Datadog与EventBridge和Lambda集成或创建自定义脚本,可以实现类似的自动化。

但是,如果您经常添加目标实例或重新启动各种服务,则维护EventBridge和Lambda或脚本的成本和复杂性将会增加。

AppKeeper已与Datadog进行了可靠的集成,并且您可以轻松地向应用程序添加目标实例,从而可以轻松地将自动化添加到DevOps环境中,从而减少停机时间。

如果您当前正在使用Datadog,并且想试用AppKeeper的Restart API,请先在此处注册我们的14天免费试用版(安装免费试用版后即可购买订阅)。然后单击此处以请求免费试用。 我们将引导您完成整个过程,并为您提供免费的评估令牌,以帮助您入门。

申请评估令牌

谢谢。我希望您能借此机会更多地了解SIOS AppKeeper,它可以自动监视和恢复在EC2上运行的应用程序。

-SIOS Technology技术团队的Tatsuya Hirao。

经SIOS许可转载

Filed Under: 服务器集群简单化

  • 1
  • 2
  • Next Page »

最近的帖子

  • 在 Nutanix 环境中选择高可用性解决方案的 10 个注意事项
  • 我的服务器是一次性的吗?高可用性软件如何融入云最佳实践
  • 灾难频发世界的数据恢复策略
  • DataKeeper 和棒球:灾难恢复的战略举措
  • SQL Server 停机风险预算

最热门的帖子

加入我们的邮件列表

Copyright © 2025 · Enterprise Pro Theme on Genesis Framework · WordPress · Log in