Hystax 云迁移:驾驭云端

灾难恢复解决方案市场的年轻参与者之一是 2016 年成立的俄罗斯初创公司 Hystax。 由于灾难恢复这个话题非常流行,而且市场竞争也非常激烈,因此这家初创公司决定专注于不同云基础设施之间的迁移。 允许您组织简单快速的云迁移的产品对于 Onlanta 的客户(用户)来说非常有用 oncloud.ru。 这就是我了解 Hystax 并开始测试其功能的方式。 我将在这篇文章中讲述它的结果。

Hystax 云迁移:驾驭云端
Hystax 的主要特点是其广泛的功能,支持各种虚拟化平台、客户操作系统和云服务,这使得您可以随时随地移动工作负载。

这使您不仅可以创建灾难恢复解决方案来提高服务的容错能力,还可以在不同站点和超大规模服务器之间快速、灵活地迁移资源,以节省成本并为当前的特定服务选择最佳解决方案。 除了标题图中列出的平台外,该公司还积极与俄罗斯云提供商合作:Yandex.Cloud、CROC Cloud Services、Mail.ru 等。 还值得注意的是,2020年该公司在斯科尔科沃开设了研发中心。 

市场上大量玩家选择一种解决方案,表明了良好的定价政策和产品的高适用性,我们决定在实践中进行检验。

因此,我们的测试任务将包括从我的 VMware 测试站点和物理机迁移到也运行 VMware 的提供商站点。 是的,有很多解决方案可以实现这样的迁移,但我们将 Hystax 视为通用工具,在所有可能的组合中测试迁移简直是一项不切实际的任务。 是的,而且 Oncloud.ru 云是专门基于 VMware 构建的,因此这个平台作为目标,我们更感兴趣。 接下来我会描述基本的工作原理,整体上不依赖于平台,VMware可以从任何方面替换为其他厂商的平台。 

第一步是部署 Hystax Acura,它是系统的控制面板。

Hystax 云迁移:驾驭云端
它是从模板扩展而来的。 由于某种原因,在我们的案例中,它并不完全正确,而是使用一半的资源部署了 8Gb,而不是推荐的 16CPU。 因此,您需要记住更改它们,否则构建所有内容的虚拟机内的基础设施将根本无法从容器启动,并且门户将不可用。 在 部署要求 详细描述了所需的资源以及所有系统组件的端口。 

而且通过模板设置IP地址也很困难,所以我们从控制台更改了它。 之后,您可以转到管理 Web 界面并完成初始配置向导。 

Hystax 云迁移:驾驭云端
Hystax 云迁移:驾驭云端
端点 - 我们的 vCenter 的 IP 或 FQDN。 
登录名和密码 - 这里很清楚。 
目标 ESXi 主机名是将复制到的集群中的主机之一。 
目标数据存储是集群中将被复制到的数据存储之一。
Hystax Acura 控制面板公共 IP - 控制面板可用的地址。

需要对主机和数据存储进行一些说明。 事实上,Hystax 复制工作在主机和数据存储级别。 接下来,我将告诉您如何更改租户的主机和数据存储,但问题有所不同。 Hystax不支持资源池,即副本总是会发生在集群的根上(在撰写本文时,Hystax 的人员发布了更新版本,他们很快实现了我有关资源池支持的功能请求)。 另外,不支持 vCloud Director,即。 如果像我的例子一样,租户没有整个集群的管理员权限,而只有特定资源池的管理员权限,并且我们授予了 Hystax 的访问权限,那么他将能够独立复制和运行这些虚拟机,但他将无法在他有权访问的 VMware 基础架构中看到它们,并相应地进一步管理虚拟机。 集群管理员需要将虚拟机移至正确的资源池或将其导入到 vCloud Director 中。

为什么我如此关注这些时刻? 因为,据我了解产品的概念,客户应该能够使用 Acura 面板独立实施任何迁移或灾难恢复。 但到目前为止,VMware 的支持略低于对同一 OpenStack 的支持水平,后者已经实现了此类机制。 

但回到部署。 首先,在面板的初始设置之后,我们需要在系统中创建第一个租户。

Hystax 云迁移:驾驭云端
这里所有的字段都清楚了,我只告诉你Cloud字段。 我们已经拥有在初始配置期间创建的“默认”云。 但是,如果我们希望能够将每个租户放在自己的数据存储和自己的资源池中,我们可以通过为每个客户创建单独的云来实现这一点。

Hystax 云迁移:驾驭云端
在添加新云的形式中,我们指定与初始配置期间相同的参数(我们甚至可以使用相同的主机),指定特定客户所需的数据存储,现在在附加参数中我们已经可以单独指定所需的池资源 {"resource_pool" :"YOUR_POOL_NAME"} 

您可能已经注意到,以创建租户的形式,没有任何关于资源分配或某种配额的内容 - 系统中没有任何此类内容。 您不能限制租户的并发副本数量、用于复制的计算机数量或任何其他参数。 这样,我们就创建了第一个租户。 现在有一个不完全合乎逻辑但强制性的事情 - 安装云代理。 这是不合逻辑的,因为代理是在特定客户的页面上下载的。

Hystax 云迁移:驾驭云端
同时,它不与创建的租户绑定,我们的所有客户都将通过它工作(或者在几个之后,如果我们部署它们)。 一名代理支持 10 个并发会话。 一次会话算作一辆车。 有多少磁盘并不重要。 迄今为止,Acura 本身还没有为 VMware 扩展代理的机制。 还有一个更令人不愉快的时刻 - 我们无法从 Acura 面板中查看该代理的“利用率”,从而得出是否需要部署更多代理或当前安装是否足够的结论。 结果,展台看起来像这样:

Hystax 云迁移:驾驭云端
访问客户门户的下一步是创建一个帐户(首先,创建一个将应用于该用户的角色)。

Hystax 云迁移:驾驭云端
Hystax 云迁移:驾驭云端
现在我们的客户可以独立使用该门户。 他所需要做的就是从门户下载代理并将其安装在他这边。 代理分为三种类型:Linux、Windows 和 VMware。

Hystax 云迁移:驾驭云端
前两个放在任何非 VMware 虚拟机管理程序上的物理机或虚拟机上。 这里不需要额外的配置,代理下载并已经知道在哪里敲门,一分钟后汽车就会在 Acura 面板中可见。 使用 VMware 代理时,情况会稍微复杂一些。 问题是 Agent for VMware 也是从已准备好的门户下载的,并且具有必要的配置。 但是,VMware 代理除了了解我们的 Acura 门户之外,还需要了解将部署它的虚拟化系统。

Hystax 云迁移:驾驭云端
实际上,当您第一次下载VMware代理时,系统会要求我们指定这些数据。 问题是,在我们普遍热爱安全的时代,并不是每个人都愿意在别人的门户上显示他们的管理员密码,这是可以理解的。 从内部来看,部署后,无法以任何方式配置代理(您只能更改其网络设置)。 在这里,我预见到特别谨慎的客户会遇到困难。 

因此,安装代理后,我们可以返回 Acura 面板并查看我们所有的汽车。

Hystax 云迁移:驾驭云端
由于我已经使用该系统一天多了,我的机器处于各种状态。 所有这些都位于默认组中,但可以根据需要创建单独的组并将计算机转移到它们。 这不会影响任何东西 - 只会影响数据的逻辑表示及其分组,以便更方便地工作。 之后我们需要做的第一件也是最重要的事情就是开始迁移过程。 我们可以强制手动执行此操作,也可以设置时间表,包括一次性为所有机器批量执行此操作。

Hystax 云迁移:驾驭云端
让我提醒您一下,Hystax 被定位为一个迁移产品。 因此,为了运行我们的复制机器,我们需要创建一个灾难恢复计划,这并不奇怪。 您可以为已处于同步状态的计算机创建计划。 您可以为一个特定虚拟机生成两者,也可以同时为所有计算机生成这两者。

Hystax 云迁移:驾驭云端
生成灾难恢复计划时的参数集会有所不同,具体取决于您要迁移到的基础设施。 VMware 环境可以使用最少的选项集。 也不支持机器的重新 IP。 对此,我们感兴趣的是以下几点:在VM的描述中,“子网”参数:“VMNetwork”,我们将VM绑定到集群中的特定网络。 排名 - 在迁移多个虚拟机时相关,决定它们的启动顺序。 Flavor 描述了 VM 配置,在本例中为 1CPU、2GB RAM。 在子网部分,我们定义“子网”:“VMNetwork”与 VMware 的“VM Network”相关联。 

创建灾难恢复计划时,无法将磁盘“拆分”到不同的数据存储上。 它们将位于为此客户端云定义的同一数据存储上,如果您有不同类别的磁盘,这可能会在启动机器时造成一些困难,并且在启动并将虚拟机与 Hystax“分离”后,它也会需要单独的迁移磁盘到所需的数据存储。 然后我们只需要运行我们的灾难恢复计划并等待我们的汽车升起。 P2V/V2V转换过程也需要时间。 在我最大的 100GB 三个磁盘测试机器上,这最多需要 10 分钟。

Hystax 云迁移:驾驭云端
之后,您应该检查正在运行的虚拟机、其上的服务、数据一致性和其他检查。 

那么我们有两个选择: 

  1. 删除 - 删除正在运行的灾难恢复计划。 此操作将简单地关闭正在运行的虚拟机。 这些复制品不会去任何地方。 
  2. 分离 - 从讴歌上撕下复制的汽车,即真正完成迁移过程。 

该解决方案的优点: 

  • 客户端和提供商端均易于安装和配置; 
  • 易于设置迁移、创建灾难恢复计划和启动副本;
  • 支持和开发人员对发现的问题做出快速响应,并通过平台或代理更新来修复它们。 

缺点 

  • Vmware 支持不足。
  • 平台没有任何租户配额。 

我还提出了一个功能请求,我们将其交给了供应商:

  1. 通过 Acura 云代理管理控制台进行使用情况监控和部署;
  2. 租户配额的可用性; 
  3. 限制每个租户同时复制的数量和速度的能力; 
  4. 支持VMware vCloud Director; 
  5. 对资源池的支持(在测试期间实现);
  6. 能够从代理本身配置 VMware 代理,而无需从 Acura 面板中的客户端基础设施输入凭据;
  7.  启动灾难恢复计划时启动虚拟机的过程“可视化”。 

唯一引起我大抱怨的是文档。 我不太喜欢“黑匣子”,更喜欢有关于产品内部工作原理的详细文档。 如果对 AWS 和 OpenStack 的产品进行了或多或少的描述,那么对 VMware 的文档就很少了。 

有一个安装指南,仅描述了 Acura 面板的部署,并且没有提及是否需要云代理。 产品有全套规格,很好。 有文档以 AWS 和 OpenStack 为例描述了“从和到”的设置(尽管它让我更多地想起了一篇博客文章),并且有一个非常小的知识库。 

一般来说,这不太是我习惯的文档格式,比如来自较大供应商的文档格式,所以我不太舒服。 同时,我在这份文档中并没有找到有关系统“内部”操作的一些细微差别的答案——我必须通过技术支持来澄清很多问题,这相当拖延了部署展位和部署的过程。测试。 

总而言之,我可以说,总的来说,我喜欢该产品和公司执行任务的方法。 是的,确实存在缺陷,确实严重缺乏功能(与 VMware 结合使用)。 可以看出,首先,该公司仍然专注于公有云,特别是AWS,对于某些人来说这已经足够了。 在很多企业选择多云策略的今天,拥有这样一个简单、便捷的产品是极其重要的。 鉴于与竞争对手相比价格低得多,这使得该产品极具吸引力。

我们正在寻找一个团队 监控系统首席工程师。 也许这就是你?

来源: habr.com

添加评论