SIOS SANless clusters

SIOS SANless clusters High-availability Machine Learning monitoring

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

了解虚拟化可用性选项

1月 21, 2018 by Jason Aw Leave a Comment

什么是虚拟化可用性选项?

Microsoft Windows Server 2008 R2和vSphere 4.0是最新发布的。 在考虑您的虚拟服务器和运行在其上的应用程序的可用性时,我们来看看一些虚拟化可用性选项。

我也将借此机会介绍一些启用虚拟机可用性的功能。此外,我已将这些功能分组为其功能角色,以帮助突出其功能。

计划停机

实时迁移和VMware的VMotion都是一种解决方案,允许管理员将虚拟机从一台物理服务器移到另一台物理服务器,而无需意识到停机时间。有一个关键的事情要记住。此举必须是有计划的事件,才能将虚拟机从一台服务器移到另一台服务器而不会发生任何停机。计划的事件是在实际切换发生之前,虚拟机的内存在服务器之间同步。微软和VMware的解决方案都是如此。另请注意,这两种技术都需要使用共享存储来保存虚拟硬盘(VMDK和VHD文件),这限制了实时迁移和VMotion到局域网。这也意味着计划存储阵列的任何停机时间必须以不同的方式处理。需要注意的是,如果您想限制对虚拟机的影响。

意外停机

微软的Windows服务器故障转移群集和VMware的高可用性(HA)是在发生意外宕机时保护虚拟机的解决方案。两种解决方案都很相似 他们监视虚拟机的可用性。如果发生故障,VM将移动到备用节点。然后,机器重新启动以进行此恢复过程。在故障转移之前没有时间同步内存。

灾难恢复

如果在完全丢失网站的情况下如何恢复我的虚拟机?好消息是虚拟化使这个过程变得更加简单。虚拟机只是一个可以拾取并移动到另一台服务器的文件。到目前为止,VMware和微软的可用性特性和功能非常相似。但是,这是微软真正闪耀的地方。VMware提供Site Recovery Manager,这是一款很好的产品。但仅限于支持SRM认证的基于阵列的复制解决方案。此外,故障切换和故障恢复过程并不是微不足道的,可以花一天时间从灾难恢复站点到主数据中心完成一次完整的往返。它确实有一些很好的功能,如DR测试。 根据我使用Microsoft的灾难恢复解决方案的经验,在灾难恢复方面他们有更好的解决方案。

微软的Hyper-V DR解决方案

Microsoft Hyper-V DR解决方案是多站点群集配置中的Windows Server故障转移群集(请参阅视频演示)。在此配置中,性能和行为与局域集群相同,但它可以跨越数据中心。从本质上讲,您实际上可以将您的虚拟机跨越数据中心,几乎没有可感知的停机时间。故障回复是相同的过程,只需点击并点击即可将虚拟机资源移回主数据中心。没有内置的“DR测试”。尽管我认为最好在一两分钟内做一次实际的灾难恢复测试,而不会发生意外的停机时间。

基于主机的复制供应商

我还喜欢WSFC多站点群集的另一件事是复制选项不仅包括基于阵列的复制供应商,还包括基于主机的复制供应商。这确实为您提供了各种价格范围的复制解决方案,并且不需要升级现有的存储基础架构。

容错

容错功能基本上消除了在出现意外故障的情况下重新启动虚拟机的需要。VMware在这方面具有优势,因为它提供了VMware FT。还有一些第三方的硬件和软件供应商也在这个领域发挥作用。实施FT系统时有很多限制和要求。如果您需要确保硬件组件故障导致零宕机时间与在标准HA配置中启动VM时所需的一两分钟时间,则这是一个选项。您可能希望确保现有服务器已满载热备用CPU,RAM,电源等。你有冗余的路径到网络和存储。否则,你可能会在糟糕的时候投入好的钱。容错性对于防止硬件故障非常有用。如果您的应用程序或虚拟机的操作系统表现不佳,会发生什么情况?这就是当你需要应用程序级集群时,如下所述。

应用可用性

到目前为止,我所讨论的所有内容都只考虑了物理服务器和整个虚拟机的健康状况。这一切都很好,但是,如果你的虚拟机蓝屏?或者如果最新的SQL服务包破坏了你的应用程序?在这些情况下,这些解决方案都不会对你有一点帮助。对于那些最关键的应用程序,您确实必须在应用程序层进行集群。研究在虚拟机上操作系统内部与管理程序内部运行的群集解决方案。在微软的世界里,这意味着MSCS / WSFC或第三方集群解决方案。在虚拟机内进行群集时,您的存储选项的范围受到iSCSI目标或基于主机的复制解决方案的限制。 目前,VMware确实没有解决这个问题的方法。它将遵循在虚拟机内运行的解决方案,以实现应用层监控。

概要

随着虚拟化的出现,这实际上不是您是否需要可用性的问题。还有更多关于什么是虚拟化可用性选项将有助于满足您的SLA和/或DR要求的问题。我希望这些信息可以帮助您了解可用的可用性选项。

转载https://clusteringformeremortals.com/2009/08/14/making-sense-of-virtualization-availability-options-2/许可

阅读我们的成功案例,了解SIOS如何为您提供帮助

Filed Under: 服务器集群简单化

删除最薄弱的链接,确保高可用性群集配置

1月 21, 2018 by Jason Aw Leave a Comment

构建高可用性群集配置

构建高可用性群集配置时,您的应用程序可用性仅与其最薄弱的链接一样好。这意味着,如果您购买了具有冗余一切(CPU,风扇,电源,RAID,RAM等)和具有多路径连接的超豪华SAN的优质服务器。与多个SAN交换机配合使用,并将您的应用程序与您喜欢的群集软件集中在一起。 你可能有一个非常可靠的应用程序 – 对吧?嗯,不一定。服务器是否插入同一台UPS?它们是否在同一个网络交换机上?它们是否由同一个交流单元冷却?他们在同一栋楼里吗?您的SAN真的可靠吗?其中任何一个问题都是高可用性群集配置中的单点故障。

寻找和删除群集配置中最薄弱的环节

当然,你必须知道什么时候“足够好”是“足够好”的。你的预算和你的SLA将有助于决定什么是好的。然而,我担心人们可能正在掠过的一个领域是存储领域。随着廉价或免费的iSCSI目标软件解决方案的出现,我看到一些人建议你只是将一些iSCSI目标软件放在备用服务器上,并且即时共享存储。

请注意,我不是在谈论内置故障转移技术和/或其他可用性功能的OEM iSCSI解决方案;甚至是FalconStor等存储虚拟化解决方案。我正在谈论那些运行Windows Server 2008的服务器,他装载了存储并希望将其转换为iSCSI目标。这在实验室很棒。但如果你认真对待医管局,你应该再考虑一下。即使是微软也只提供他们的iSCSI目标软件给合格的OEM制造商,他们在提供企业级存储阵列上经验丰富。

你实际上得到了什么?

首先,这是Windows。 没有一些经过强化的操作系统只能用于存储。这将需要维护,安全更新,硬件修复等。它基本上与您要保护的应用程序服务器具有相同的可靠性。集群应用程序服务器是否有意义。然而,使用相同类别的服务器和操作系统来托管您的存储?您基本上已将单点故障从应用程序服务器移开并将其移至存储服务器。就我而言,这不是一个聪明的举动。

某些企业级iSCSI目标软件包括同步和/或异步复制软件和快照功能。此功能肯定有助于恢复点目标(RPO)。虽然它不会帮助您恢复时间目标(RTO),除非故障转移是自动且无缝到您的群集软件。假设主iSCSI存储阵列在半夜失败。谁将在那里激活复制副本?在您意识到存在问题之前,您可能已经停机了很长时间。再次,这可能是“足够好”;你只需要知道你正在注册的东西。这是您正在寻找的高可用性群集配置吗?

SIOS DataKeeper

为提高iSCSI目标服务器的可靠性,您可以做的一件事是使用SteelEye DataKeeper Cluster Edition等复制产品来消除单点故障。让我来说明一下。

典型的共享存储配置
图1 – 典型的共享存储配置。如果iSCSI目标不可用,则所有节点都将脱机。

如果我们采用上面显示的相同配置并使用SteelEye DataKeeper Cluster Edition添加热备用iSCSI目标来执行复制和自动故障转移,那么您刚刚为iSCSI目标解决方案提供了全新的可用性级别。这个解决方案看起来非常像这样。

DataKeeper Cluster Edition  - 高可用性群集配置
图2 – 在这种情况下,DataKeeper Cluster Edition正在将主动节点上的iSCSI附加卷复制到被动节点上的iSCSI附加卷上,被动节点连接到一个完全不同的iSCSI目标服务器。

使用SteelEye DataKeeper Cluster Edition的解决方案与某些iSCSI目标供应商提供的复制解决方案的主要区别在于与WSFC的集成。要问你的iSCSI解决方案供应商的问题是这样的…

如果我拔下活动的iSCSI目标服务器上的电源线,会发生什么情况?

如果恢复过程是手动过程,则不是真正的HA解决方案。但是如果它是自动的并且与WSFC完全集成呢?然后,您可以获得更高级别的可用性,并将iSCSI阵列作为单点故障排除在外。

与我们聊天也可以实现高可用性群集配置

经Clusteringformortals许可转载。

Filed Under: Datakeeper, 服务器集群简单化

Steeleye Datakeeper Cluster Edition荣获Windows It Pro最佳高可用性/灾难恢复奖

1月 20, 2018 by Jason Aw Leave a Comment

我很高兴地宣布,Windows IT Pro授予SteelEye DataKeeper Cluster Edition两个类别的最佳高可用性和灾难恢复产品;社区选择金奖和编辑最佳银奖。

SteelEye DataKeeper集群版 - 最佳高可用性灾难恢复产品SteelEye DataKeeper集群版 - 最佳高可用性灾难恢复产品

作为SteelEye DataKeeper团队的一员,我感到非常自豪,我很欣赏在社区选择奖中为我们投票的所有Windows IT Pro社区!

转载https://clusteringformeremortals.com/2009/11/20/steeleye-datakeeper-cluster-edition-wins-windows-it-pro-best-high-availabilitydisaster-recovery-awards/的许可

Filed Under: Datakeeper, 服务器集群简单化

如何在多站点群集中使用异步复制?数据不同步?

1月 18, 2018 by Jason Aw Leave a Comment

如何在多站点群集中使用异步复制?数据不同步?

我被问过这个问题不止几次了,所以我想我会在我的第一篇博文中回答这个问题。  基本答案是肯定的,在多站点集群中使用异步复制时,可能会导致意外失败的数据丢失。  在一个理想的世界里,每个公司都会有一个到他们灾难恢复站点的暗光纤连接,并使用与他们的多站点集群同步复制,消除数据丢失的可能性。  但是,现实情况是,在许多情况下,到灾难恢复站点的广域网连接有太多的延迟来支持同步复制。  在这种情况下,异步复制是一个很好的选择。

我的选择是什么?

选择与WSFC多站点群集一起使用的异步复制解决方案时,有多个选项。这包括来自EMC,IBM,HP等公司的基于阵列的解决方案。和基于主机的解决方案,比如我亲近的解决方案,“SteelEye DataKeeper Cluster Edition”。  由于我最了解DataKeeper,所以我将解释DataKeeper的这一切是如何工作的。

SteelEye DataKeeper怎么样?

当使用SteelEye DataKeeper和异步复制时,我们允许将一定数量的写入存储在异步队列中。  可以排队的写入次数由“高水位线”确定。这是DataKeeper使用的可调整值,用于确定在镜像状态从“镜像”更改为“暂停”之前队列中可以有多少数据。  当辅助服务器和主服务器之间发生通信故障时,也会进入“暂停”状态。处于暂停状态时,多站点群集中的自动故障转移将被禁用,从而限制意外故障中可能丢失的数据量。  如果原始数据集被认为是“永久丢失”,则可以手动解锁目标服务器上的剩余数据,然后可以使集群节点投入使用。

在“暂停”状态下,DataKeeper允许异步队列耗尽,直到达到“低水位”,此时镜像将进入“重新同步”状态,直到所有数据再次同步。  此时,镜像再次处于“镜像”状态,自动故障转移再次启用。

只要你的广域网链路没有饱和或破坏,在这个异步队列中的任何时候,你永远不应该看到更多的写入。  如果出现意外的故障(请拔掉电源线),您将失去异步队列中的任何写入。  当您需要使用多站点群集实现的卓越恢复点目标(RPO)和恢复时间目标(RTO)时,这是您所做的权衡,但您的WAN链路有太多的延迟来有效支持同步复制。

试试SteelEye DataKeeper

花时间通过Windows性能日志和警报监控DataKeeper异步队列。我想您会惊喜地发现,由于DataKeeper复制引擎的效率,异步队列大部分都是空的。  即使在写入繁重的时候,异步队列也很少增长,并且几乎立即耗尽。因此,在任何给定时间处于风险中的数据量是最小的。  与从昨晚的备份恢复的灾难中的备选方案相比,使用异步复制在意外故障中丢失的写入次数最少!

当然,也有一些情况下,即使丢失一个单一的写是不可容忍的。  在这种情况下,建议在高速,低延迟的LAN或WAN连接上使用SteelEye DataKeeper的同步复制选项。

经Clusteringformeremortals.com许可转载

Filed Under: Datakeeper, 服务器集群简单化

为什么我应该把我的#AZURE集合转换为管理磁盘今天!

8月 9, 2017 by Jason Aw Leave a Comment

您可能已经听说过最近的存储中断,影响了美国东部地区在3月16日的一些情况。 停电的根本原因分析在这里张贴。

3月16日美国东部存储中断

客户影响:在美国东部地区使用Storage的客户的一小部分可能在单个存储量表单元访问其存储帐户时遇到错误和超时

您可能会问:“什么是单个存储量表单元”。 那么,你可以把它看成一个单一的存储集群,或是一个SAN,或者你想要考虑它。 我不认为Azure发布其精确的基础架构,但是您可以假设幕后使用的是扩展文件服务器来进行后端存储。

所以问题是,如何以最短的停机时间在这种停电中幸存下来?如果你进一步阅读根本原因分析,你会遇到这个小块。

在可用性集中使用托管磁盘的虚拟机将在此事件期间保持可用性。

什么是托管磁盘你问?那么就在2月8日,科里·桑德斯(Corey Sanders)宣布管理磁盘阵列。 您可以在这里阅读有关托管磁盘的所有信息。 https://azure.microsoft.com/en-us/services/managed-disks/

托管磁盘有助于中断这一原因是通过利用可用性集合与托管磁盘组合,您可以确保可用性集中的每个实例都连接到不同的“存储量表单元”。 因此,在这种特殊情况下,只有一个集群节点将失败,剩下的节点才能接管工作负载。

在托管磁盘可用之前(任何部署在2/8/2016之前),没有办法确保连接到您的服务器的存储位于不同的存储容量单位上。 当然,您可以为每个实例使用不同的存储帐户,但实际上并不能保证这些存储帐户在不同的存储量表单元上配置存储。

因此,当可用性集确保您的实例驻留在不同的故障域和更新域中以确保实例本身的可用性时,附加到每个实例的额外存储确实代表了单点故障。 虽然存储本身具有高度的灵活性,但可以使用三个数据副本和地理冗余选项,在这种情况下,电源故障,整个存储量表单元与连接的所有服务器一起下降。

这么长的故事简短…尽快迁移到托管磁盘,以帮助最小化停机时间

https://docs.microsoft.com/en-us/azure/virtual-machines/virtual-machines-windows-migrate-to-managed-disks

如果您真的想减少停机时间,那么您应该考虑跨云提供商的混合云部署或云计算的一体机。

Filed Under: 服务器集群简单化

  • « Previous Page
  • 1
  • …
  • 107
  • 108
  • 109
  • 110
  • Next Page »

最近的帖子

  • 本地数据中心的高可用性
  • APM 工具和高可用性集群如何提高网络弹性
  • 为云端 SQL Server 高可用性选择合适的存储
  • 在不可预测的世界中制定灾难恢复计划
  • 主动-主动 vs. 主动-被动

最热门的帖子

加入我们的邮件列表

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