什麼是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 
-多個@ {地址= $ 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 
-多個@ {地址= $ 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地址，該前端IP地址使用與iSCSI Target群集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 
-多個@ {地址= $ 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 
-多個@ {地址= $ 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群集的解決方案簡介