什么是Amazon CloudWatch？

您可以使用CloudWatch做什么以及需要考虑的一些障碍

随着AWS在云市场中占据主导地位，许多公司正在使用Amazon AWS将其本地系统迁移到云中。  那么，应该如何管理在AWS环境中运行的系统？

在此博客文章中，我们将介绍AWS提供的监视服务Amazon CloudWatch的功能，以及实现它的挑战以及如何解决它们。

使用Amazon CloudWatch密切监视您的AWS环境

为了确保您拥有稳定的云环境，快速检测异常（“系统损害”）并及时做出响应非常重要。  对于任何迁移到云的组织而言，监视已成为一项重要且必要的任务。  这与管理本地应用程序和基础结构没有什么不同。那么，您应该如何在AWS环境中进行监控？一种选择是使用Amazon CloudWatch，它监视CPU，内存和磁盘使用情况，并在超过预定阈值时通知您。  另外，您可以设置自己的指标来监视各种项目，例如应用程序日志。

关于Amazon CloudWatch的最好之处在于，它是AWS本身提供的一项服务。  它与Amazon EC2和其他AWS服务具有很高的亲和力，因此它可以快速响应频繁的功能扩展和规范更改，并可以轻松支持AWS Auto Scaling，后者会根据负载自动增加或减少资源。  Amazon CloudWatch可根据每种环境的独特情况提供精确的监控。

Amazon CloudWatch实施挑战

尽管Amazon CloudWatch非常适合拥有经验丰富的云工程师和DevOps团队的组织，但一般用户应该注意一些事项。

Amazon CloudWatch可有效监视组织的AWS环境，但它需要一定水平的技能和知识来配置和部署。  尤其是当您设置自己的指标，设置警报或考虑到Auto Scaling时，复杂性会增加。 例如，如果要设置监视，这很容易，但是如果要设置电子邮件，重新启动，自动缩放等，则可能会遇到困难，具体取决于资源情况。

如果您要使用“发生错误时重新启动服务器”之类的指示来自动化恢复过程，则必须首先使用AWS Lambda脚本创建恢复方案，该脚本提供了有关条件和要采取的措施的详细说明。  您的团队对AWS Lambda有多熟悉？

Amazon CloudWatch的主要优点是您可以密切监视您的环境，但是要做到这一点，您必须事先为每个系统正确设计要监视的项目以及何时监视阈值等。  这些设计任务可能会花费很多时间。  当然，您的关键任务系统需要以这种方式进行严密监视，但是这种详细程度和复杂程度并不适合所有系统。对于某些网站，例如内部网站或WordPress服务器，您将希望最大程度地降低运营和人工成本。在这种情况下，我们建议您考虑使用一种更易于操作和管理的工具。

SIOS AppKeeper，用于监视在AWS上运行的操作系统和应用程序服务

对于非关键任务应用，我们建议使用SIOS Technology的SIOS AppKeeper。  AppKeeper易于安装和配置，并可监视在EC2实例上运行的应用程序的服务（进程）。  当检测到错误时，AppKeeper会自动重新启动服务，并在必要时重新启动实例。  即使是初次迁移到云的用户也可以设置AppKeeper来监视其EC2实例并自动恢复，而无需具备复杂的脚本编写技能。

使用AppKeeper，无需选择要监视的单个服务。您只需选择要监视的EC2实例以及要自动执行的操作即可。  您始终可以更详细地了解要监视哪些服务以及如何监视这些服务，但是AppKeeper旨在易于配置。  当检测到错误或从中自动恢复错误时，会记录并存储故障日志，以便以后可以调查故障原因。

建议您不要根据Amazon SLA和恢复要求清点环境清单，而要使用SIOS AppKeeper监视您想减少运营开销的系统和应用程序，而不是使用Amazon CloudWatch来密切监视AWS环境中的所有内容。

请继续关注未来的博客文章，我们将更详细地比较如何设置CloudWatch和AppKeeper以执行相同的功能。

了解有关SIOS AppKeeper的更多信息

注册免费试用SIOS AppKeeper

 

测试/质量保证系统是企业可用性的关键部分

“我可以吻你，”这就是三十年前一个朋友向我冲来时对我脱口而出的意思。在前往我们地区最大的乐队比赛之一的途中，她已将簧片放到萨克斯管上。我不知道它们是谁，但是当我看到一堆芦苇在公交车上的座位上时，我把它们捡起来，带他们去了暖身区。热身三分钟后，她的第一个簧片破裂了，当她伸手去拿空口袋进行替换时，她惊慌失措。当我找到我发现它们的管道时，她脱口而出：“我现在可以吻你。”

担任SIOS Technology Corp.客户体验副总裁 在可用性频谱的不同阶段，我与许多企业客户和合作伙伴一起工作感到非常独特和独特。有时，我有机会与最终客户一起解决问题，缓解问题和进行改进。在其他时候，我们的团队会与合作伙伴和客户积极合作，以设计和实现企业可用性，以保护其系统免于停机。最近的一次客户体验使我想起了大约30年前发生的一件事情，当时我的朋友脱口而出：“我可以吻你。”

我和我的团队正在打客户电话。通话从平时的欢愉，介绍和对客户企业环境的概述开始。通话30分钟后，一切进展顺利。他们的体系结构扎实，周到并且有据可查。他们的团队知识渊博，技术精湛，经验丰富。但是随后，客户暗示，由于节省了成本，他们将不打算维护专用的测试/质量系统。我深吸了一口气。  实际上，这更像是呼气，就像是从肠子上冲来的空气一样。我准备做出回应，但在此之前，我的声音就爆发了。  “停机的首要原因是缺乏流程，”合作伙伴代表架构师在与我们的电话中惊呼道。经过短暂的开玩笑，客户同意维护测试/ QA系统，我差点脱口而出：“我可以亲你！”

在许多企业部署的前线（新系统，数据中心迁移和系统更新）中，我在支持和服务部门的团队已经看到许多问题，这些问题可以通过利用测试系统/群集来解决。

测试/质量系统是避免停机的HA策略的重要组成部分。与维护企业部署相关的常见任务（例如补丁，更新和配置更改）存在风险。巨大的风险。

通常在生产中进行测试的风险包括几个严重的潜在灾难性问题： 

• 数据损坏或无效
• 受保护的数据泄漏
• 错误的收入确认（取消的订单等）
• 重载系统
• 对其他生产系统的意外副作用或影响
• 错误率高，可触发警报并呼叫人员
• 偏斜的分析（流量漏斗，A / B测试结果等）
• 充满脚本和漫游器活动的不正确流量日志（a）

如果客户尝试在生产中进行风险较大的更改，则结果可能会非常有害。除了上面列出的那些故障之外，还有更多的停机时间风险，应用程序安装损坏，以及在某些情况下不可逆转的损坏。以客户X（在制造业中知名的SAP Enterprise商店）为例。

在从信誉良好的站点上读取紧急通知后，OS管理员迅速将其生产节点更新为可用的最新内核更新。在数小时内，生产节点开始了一系列未启动的崩溃和内核崩溃。他急忙安装了与他的配置不兼容的内核。现有应用程序软件包，设备，文件系统和相关软件包的组合。这导致生产中断，并向多个供应商几次高优先级升级。

将补丁程序应用于测试/ QA或沙箱系统时，可以管理和验证补丁程序和关键修订，以减少生产力损失和计划外停机。在类似生产的环境中测试应用程序使您能够发现无法预料的问题，并在这些问题对您的运营产生不利影响之前进行纠正。产前设计和测试消除了代价高昂的业务中断，改善了客户体验并保护了品牌。

使用测试质量检查系统改善生产可用性和过程

这些是使用测试/质量检查系统可以改善生产可用性和过程的基础知识。 与生产环境类似的受控环境（必须与生产环境尽可能相似）必须具有以下功能：

1. 测试内核更新和安全更新
2. 验证设置和配置调整
3. 重现生产问题并测试软件更新和补丁
4. 验证应用程序版本兼容性，并减少由于不兼容的更改而导致停机的风险
5. 提供一个安全的空间来练习和修订上线，维护，中断和其他企业程序活动
6. 在不影响企业客户的情况下培训新员工和团队成员

如果您具有用于部署关键企业可用性软件的测试/质量检查环境，我现在可以亲吻您。有了这种环境，您的团队就可以“测试，验证和验证（2）”体系结构，业务需求，用户场景，以及与与生产环境最相似的一个系统或一组系统的一般集成-您知道赚钱。当然，您仍然必须安排窗口来维护您的生产系统并对其进行测试，但是要在这之间完成一个安全的缓冲步骤之后。

—客户体验副总裁Cassius Rhue

————-

参考文献：

1. https://opensource.com/article/19/5/dont-test-production已访问2020年5月4日
2. https://www.softwaretestingclass.com/system-testing-what-why-how/访问时间：5/4/2020

企业可用性：法院的教训

我爱篮球。我喜欢玩游戏，观看游戏并仔细思考游戏的大脑方面；思想和动机，策略和战术。我想寻找能正常工作或失败的小东西，屏幕设置太早或滚动太晚。我喜欢防守和轮换。我想知道教练的练习，演练，旅行等策略。  几个月前我自然而然地离开了24/7全天候工作日，想象一下，我抽出一天时间去看篮球，更具体地说是我女儿在中学篮球练习。

在观看的大约三分之一时间内，我无法控制自己。我吹口哨，“劝诱”那个年轻的女孩，恶作剧地着小跑到球场上，大喊：“快跑！忙！”她做到了，耳边的队友也做到了。  接下来的几分钟，戏剧和演习充满了活力，清晰的切割，流畅的动作和动力。  但是，它并没有持续。  取而代之的是，需要更多的哨声，需要更多的举动来移动和奔跑，努力发挥，大刀阔斧，下潜，专心，专注，学习和纠正。2个小时快结束时，我将最后一刻的注意力转移到预言上，“练习的方式就是演奏的方式！”

我几乎可以感觉到您传达了AI的精神，而不是人工智能（AI），艾伦·艾弗森（AI）。  “我们在谈论，练习。  实践！”我认为这与可用性有关。  好吧，当我考虑女儿和队友时，我对篮球的热爱满足了我对可用性的热爱。怎么样？

篮球策略与可用性策略类似的三种方式：

• 在篮球运动中，每个团队都需要一个计划，以确保企业可用性。
• 在篮球运动中，每个团队都需要练习该计划，同上以确保可用性，灾难恢复，尤其是计划好的维护。
• 在篮球比赛中，该计划在火中受到考验的情况下，其执行效果只会与实施该计划时一样好
  

企业可用性需要计划 

您的可用性（特别是灾难，计划的维护和中断恢复策略）仅与您创建的一样好。简而言之，您对中断的计划是什么（请注意，云故障，服务器崩溃，网络饱和以及人为错误）。  您有书面计划吗？您是否已确定所有者和备份所有者？您是否知道您的体系结构和拓扑（什么服务器做什么，它位于什么位置，它属于哪个团队，服务什么功能，与它相关的业务优先级以及它需要什么SLO / SLA）？谁是您的主要供应商，他们的召唤清单是什么？您的检查点，数据保护计划和备份策略是什么？您有什么测试计划和验证计划来验证该计划？

企业可用性需求实践 

一个好的计划，检查一下。现在练习。  实施灾难恢复步骤和计划外的停机策略是每个企业配置的必要组成部分。但是，不进行演练的策略并不是真正的策略。在这种情况下，这只是一种可能的提议方法。  它更像是一个建议，而不是实际的记录计划。第二步是练习。逐步了解您的计划策略。排练维护时间。恢复备份和数据。验证假设和失败模式。

企业可用性需要测试 

一个计划和一个演练，检查。现在您拥有三个中的两个，让我回到女儿的团队。  作为“非官方教练”，我的临别词如下：“练习的方式就是比赛的方式！”快进三天。比赛已经结束了。他们所参加的球队在运动能力上不匹配，并且与去年一样，当时该球队的比赛在半场结束时规模过大。  但是今年，人员不足和规模较小的团队显然已经做好了更多准备。本来应该是轻松的胜利现在进入了接近并列的最后一分钟。主队，即对手，开始进行新闻报道。尽管如此，我女儿的球队还是为这种命运的练习而无意中做出了准备。  随之而来的不是很好。四次失误的失误，三分球命中两次关键犯规，四分命中或零失误，以及一系列挫败感最终导致毁灭性的一分失误。

我的最后一点是，您在实际中断，灾难或计划内维护方面做得如何？您是否使用真实的数据，真实的客户以及真正的紧迫感进行练习？您的高层管理人员多久签到一次？相信我，在充满压力的时刻出现老板会让人做出奇怪而不明智的事情！您的沙盒和测试系统看起来像生产环境吗？在过去的生活中，我曾经与一位客户在产品和质量保证之间使用不同的硬件，存储和Linux OS版本进行过合作。当他们进入应用程序更新的过程中，灾难就来了。  您是否有用户和数据以及测试期间运行的作业？实际的灾难模拟呢？这是一项难以接受的工作，它会测试具有潜在破坏性后果的硬崩溃，从异地恢复，甚至更难于模拟同时发生的多点，多个系统故障，但这种做法往往不可行，往往会使2小时的计划维护变成八小时的多团队企业灾难。  练习不足或实践不佳是您的战略和团队取得惊人胜利，还是团队，供应商，企业和客户遭受惨败和代价高昂的失败之间的区别。

在篮球运动中，受到抨击的计划只能维持与计划相同的状态。  在实施恢复和灾难计划时，关键是要制定良好的计划和验证，但是出色的实践才是王道。

请与SIOS的销售代表联系，以了解我们的可用性专家和产品如何帮助您制定计划，程序和实践。

回访有关您永远不应避免进行模拟的测试的帖子。

—客户体验副总裁Cassius Rhue

文章转载自SIOS

循序渐进：Azure中的ISCSI目标服务器群集

我最近帮助某人在Azure中构建了iSCSI目标服务器群集，并意识到我从未针对该特定配置编写分步指南。因此，为了弥补这一点，如果您需要自己执行此操作，请按以下逐步说明进行操作。

先决条件

我假设您对Azure和Windows Server相当熟悉，所以我将为您省去一些细节。假设您至少已完成以下操作

• 在不同的可用区中分别提供两台服务器（SQL1，SQL2）（也可以使用可用性集，但是可用区具有更好的SLA）
• 通过Azure门户为其分配静态IP地址
• 将服务器加入现有域
• 在两个节点上均启用了故障转移群集功能和iSCSI Target服务器功能
• 将三个Azure高级磁盘添加到每个节点。
  注意：这是可选的，最少需要一个磁盘。为了提高IOPS，我们将在存储池中将三个Premium Azure磁盘条带化，并创建一个简单的（RAID 0）虚拟磁盘
• SIOS DataKeeper将用于提供集群中使用的复制存储。如果您需要DataKeeper，则可以在此处请求试用。

创建本地存储池

再次，此步骤是完全可选的，但是为了提高IOPS，我们将三个Azure Premium磁盘分条到一个存储池中。您可能会倾向于使用动态磁盘和跨区卷，但不要这样做！如果使用动态磁盘，则会发现存在一些一般性的不兼容性，这将阻止您以后创建iSCSI目标。

不用担心，如果您知道可能会遇到的陷阱（如下所述），那么创建本地存储池将非常简单。官方文档可以在这里找到。

陷阱＃1-尽管文档说存储池中使用的卷的最小大小为4 GB，但我发现无法识别P1高级磁盘（4GB）。因此，在我的实验室中，我使用了16GB的P3高级磁盘。

陷阱2-您必须至少具有三个磁盘才能创建存储池。

陷阱＃3-在创建集群之前先创建存储池。如果您在创建群集后尝试执行此操作，那么Microsoft会为您创建群集存储池时，您将一团糟。我们将不会创建集群存储池，因此在创建集群之前先创建存储池，以免造成混乱。如果必须在创建集群后添加存储池，则必须首先从集群中逐出该节点，然后再创建存储池。

根据此处找到的文档，以下是屏幕快照，它们表示在两个群集节点中的每个节点上构建本地存储池时应看到的屏幕截图。在构建集群之前，请在两台服务器上完成这些步骤。

您应该在两台服务器上都看到原始池。

右键单击并选择“新建存储池”。

关闭此向导后，选择“创建虚拟磁盘”

请注意，如果您决定结合使用Standard，Premium和Ultra SSD，则可以创建存储层

为了获得最佳性能，请使用简单的存储布局（RAID 0）。不必担心可靠性，因为Azure托管磁盘在后端具有三重冗余。需要简单才能获得最佳性能。

为了性能起见，请使用固定配置。无论如何，您已经为完整的Premium磁盘付费，因此无需全部使用。

创建您的集群

现在每个服务器都有自己的45 GB X驱动器，我们将创建基本集群。最好通过Powershell在Azure中创建群集，以便我们可以指定静态IP地址。如果通过GUI进行操作，您将很快意识到Azure为您的群集IP分配了一个必须清除的重复IP地址，所以不要这样做！

这是用于创建新集群的示例Powershell代码。

 New-Cluster-名称mycluster -NoStorage -StaticAddress 10.0.0.100-节点sql1，sql2

输出看起来像这样。

PS C： Users  dave.DATAKEEPER>新建群集-名称mycluster -NoStorage 
-StaticAddress 10.0.0.100-节点sql1，sql2
警告：在创建群集角色时存在问题 
可能会阻止它启动。
有关更多信息，请查看下面的报告文件。
警告：报告文件位置：C： windows  cluster  Reports  Create Cluster 
2020.05.20上的向导mycluster 
在16.54.45.htm

名称     
----     
集群

报告中的警告将告诉您没有见证人。由于此群集中没有共享存储，因此您必须创建一个Cloud Witness或File Share Witness。我不会指导您完成该过程，因为这些链接上已对此进行了很好的记录。

不要拖延这一步，现在就继续创建见证人，然后再继续下一步！

现在，您应该拥有一个基本的2节点群集，看起来像这样。

为群集核心IP地址配置负载均衡器

Azure中的群集是唯一的，因为Azure虚拟网络不支持免费的ARP。如果您不知道这意味着什么，请不必担心，您真正要知道的是无法直接访问群集IP地址。相反，您必须使用Azure负载平衡器，它将客户端连接重定向到活动群集节点。

为Azure中的群集配置负载均衡器有两个步骤。第一步是创建负载均衡器。第二步是更新群集IP地址，以便它侦听负载平衡器的运行状况探针，并使用255.255.255.255子网掩码，从而可以避免IP地址与ILB冲突。

我们将首先为集群核心IP地址创建一个负载均衡器。稍后，我们将编辑负载均衡器，以解决在本文档结尾处将创建的iSCSI群集资源IP地址。

请注意，我们使用的静态IP地址与用于创建核心群集IP资源的地址相同。

创建负载均衡器后，您将如下所示编辑负载均衡器

将两个群集节点添加到后端池

将两个群集节点添加到后端池

添加健康状况探针。在此示例中，我们使用59999作为端口。请记住该端口，下一步将需要它。

创建新的路线以重定向所有HA端口，请确保已启用“浮动IP”。

第2步–编辑群集IP地址以与负载均衡器一起工作

如前所述，将负载均衡器配置为正常工作有两个步骤。现在我们有了负载均衡器，我们必须在一个集群节点上运行Powershell脚本。以下是需要在群集节点之一上运行的示例脚本。

$ ClusterNetworkName =“集群网络1” 
$ IPResourceName =“集群IP地址” 
$ ILBIP =“ 10.0.0.100” 
导入模块故障转移群集
Get-ClusterResource $ IPResourceName | Set-ClusterParameter 
-多个@ {Address = $ ILBIP; ProbePort = 59998; SubnetMask =“ 255.255.255.255”
; Network = $ ClusterNetworkName; EnableDhcp = 0} 

除了使所有变量都适合您的环境之外，上述脚本的重要之处还在于确保将ProbePort设置为您在负载均衡器设置中为此特定IP地址定义的端口。稍后您将看到，我们将为使用另一个端口的iSCSI群集IP资源创建第二个健康状况探针。另一个重要的事情是确保将子网设置为255.255.255.255。它可能看起来错了，但这就是需要设置的内容。

运行它后，输出应如下所示。

 PS C： Users  dave.DATAKEEPER> $ ClusterNetworkName =“集群网络1” 
$ IPResourceName =“集群IP地址” 
$ ILBIP =“ 10.0.0.100” 
导入模块故障转移群集
Get-ClusterResource $ IPResourceName | Set-ClusterParameter 
-多个@ {Address = $ ILBIP; ProbePort = 59999; SubnetMask =“ 255.255.255.255”
; Network = $ ClusterNetworkName; EnableDhcp = 0}
警告：属性已存储，但并非所有更改都会生效 
直到群集IP地址脱机，然后再次联机。

您将需要使核心群集IP资源脱机并使其重新联机，然后它才能与负载均衡器一起正常运行。

假设您在创建负载均衡器时做得正确，则两台服务器上的服务器管理器都应将群集列为“联机”，如下所示。

检查两个群集节点上的服务器管理器。您的群集在“可管理性”下应显示为“在线”。

安装DataKeeper

我不会在这里完成所有步骤，但是基本上到此为止，您可以在两个群集节点上安装SIOS DataKeeper了。这是一个非常简单的设置，只需运行设置并选择所有默认值即可。如果您在使用DataKeeper时遇到任何问题，通常是两件事之一。第一个问题是服务帐户。您需要确保用于运行DataKeeper服务的帐户位于每个节点上的Local Administrators组中。

第二个问题是关于防火墙的。尽管DataKeeper安装将自动更新本地Windows防火墙，但是如果您的网络已锁定，则需要确保群集节点可以通过所需的DataKeeper端口相互通信。此外，您需要确保ILB健康状况探针可以到达您的服务器。

一旦安装了DataKeeper，就可以创建第一个DataKeeper作业了。对于要使用DataKeeper界面复制的每个卷，请完成以下步骤。

使用DataKeeper界面连接到两个服务器

单击创建新作业并为其命名

单击“是”以在集群中注册DataKeeper卷。

注册该卷后，它将显示在故障转移群集管理器的“可用存储”中

创建ISCSI目标服务器群集

在下一步中，我们将在集群中创建iSCSI目标服务器角色。在理想的情况下，我将拥有一个Powershell脚本来为您完成所有这些操作，但是为了方便起见，现在我将向您展示如何通过GUI进行操作。如果您碰巧编写了Powershell代码，请随时与我们其他人分享！

GUI方法存在一个问题。创建IP资源时，您将获得一个重复的IP地址，这将导致您的群集资源在我们修复之前失败。我还将逐步完成该过程。

转到失败的IP地址资源的属性，然后选择静态IP，然后选择您的网络上未使用的IP地址。请记住该地址，我们将在下一步中更新负载均衡器时使用它。

现在，您应该可以使iSCSI群集资源联机。

更新ISCSI目标服务器群集资源的负载均衡器

如前所述，客户端无法直接连接到我们刚刚为iSCSI目标服务器群集创建的群集IP地址（10.0.0.110）。我们将必须更新我们之前创建的负载均衡器，如下所示。

首先添加一个新的前端IP地址，该地址使用与iSCSI Target群集IP资源使用的IP地址相同的IP地址。

在另一个端口上添加另一个健康状况探针。记住这个端口号，我们将在接下来运行的powershell脚本中再次使用它

我们再添加一个负载平衡规则。确保将“前端IP地址”和“运行状况”探针更改为使用我们刚创建的探针。还要确保启用直接服务器返回。

允许负载平衡器工作的最后一步是在一个群集节点上运行以下Powershell脚本。确保使用新的Healthprobe端口，IP地址和IP资源名称。

 $ ClusterNetworkName =“集群网络1” 
$ IPResourceName =“ IP地址10.0.0.0” 
$ ILBIP =“ 10.0.0.110” 
导入模块故障转移群集
Get-ClusterResource $ IPResourceName | Set-ClusterParameter 
-多个@ {Address = $ ILBIP; ProbePort = 59998; SubnetMask =“ 255.255.255.255”
; Network = $ ClusterNetworkName; EnableDhcp = 0} 

您的输出应如下所示。

 PS C： Users  dave.DATAKEEPER> $ ClusterNetworkName =“集群网络1” 
$ IPResourceName =“ IP地址10.0.0.0” 
$ ILBIP =“ 10.0.0.110” 
导入模块故障转移群集
Get-ClusterResource $ IPResourceName | Set-ClusterParameter 
-多个@ {Address = $ ILBIP; ProbePort = 59998; SubnetMask =“ 255.255.255.255”
; Network = $ ClusterNetworkName; EnableDhcp = 0}
警告：属性已存储，但并非所有更改都会生效 
直到IP地址10.0.0.0脱机，然后再次联机。

确保使资源脱机和联机以使设置生效。

创建您的群集ISCSI目标

在开始之前，最好检查一下以确保两台服务器上的服务器管理器都能看到两个群集节点以及两个群集名称资源，并且在可管理性下它们都显示为“联机”，如下所示。

如果任一服务器在查询这些群集名称中的任何一个时出现问题，则后续步骤将失败。如果有问题，我将仔细检查创建负载平衡器和运行的Powershell脚本所采取的所有步骤。

现在，我们准备创建我们的第一个群集iSCSI目标。从任一群集节点中，按照以下说明的步骤进行操作，以作为有关如何创建iSCSI目标的示例。

当然，将其分配给将要连接到该iSSI目标的服务器。

有了它，您现在在Azure中就可以使用功能正常的iSCSI目标服务器。

如果您对此进行构建，请发表评论，我知道您打算如何使用它！

经群集允许复制的文章，凡人

解决方案简介：适用于混合云环境的无SAN群集

SIOS SANless集群是一种简便，经济高效的方法，可以为基于物理服务器的集群环境添加灾难保护，而无需额外的数据中心或灾难恢复站点的成本和复杂性。将云中的SIOS SANless群集节点添加到基于物理服务器的群集环境中，以便为关键业务应用程序提供高效，实时，块级复制和灾难保护。SIOS软件支持跨地理位置和云可用区域或区域的应用程序实例故障转移，以提供站点范围，本地和区域灾难保护。SIOS SANless软件使您可以使用物理，虚拟或云系统可用的本地存储来构建集群。SIOS软件使本地存储保持同步，以实现高可用性保护，而无需共享存储。

配置灵活性

无论您是要保护物理服务器，组织内的私有云，公共云还是混合云中的应用程序，SIOS SANless软件都可以让您灵活地选择构建完全自动化的，以应用程序为中心的集群和复制解决方案。行业标准的硬件，复制架构和部署（主动/主动，主动/被动）。

SIOS软件使您可以在自己选择的配置之间进行复制–在SAN和SANless环境之间以及物理，虚拟和云配置的任意组合之间进行复制。没有供应商锁定。在源和目的地不需要相同的硬件。

易于使用。容易拥有

您可以使用我们直观的界面构建SIOS SANless集群并在几分钟内对其进行配置。SIOS还使对群集的监视和管理变得容易。用户友好的管理控制台使您可以一目了然地监视受保护服务器，通信路径，资源和应用程序的状态。

主要好处

防灾

•为关键业务应用程序提供简单，经济高效的高可用性和灾难保护

灵活性

•混合物理服务器和云环境以实现最高效率。

使用方便

•直观的控制台，可轻松进行持续的监视和管理。

下载有关混合云环境的SANless群集的解决方案简介