什麼是Amazon CloudWatch？

測試/質量保證系統是企業可用性的關鍵部分

案例研究：AWS EC2監控解決方案使一家全球製造公司在遷移到雲中時免除了壓力。

東京鑽石工具製造公司使用SIOS AppKeeper保護重要應用程序

東京鑽石工具製造公司成立於1932年。Co.，Ltd.生產用於切割，切片，拋光和鑽孔工藝的金剛石工具，涉及範圍廣泛，例如家用電器，半導體，電子設備，醫療保健和土木工程。儘管它是擁有80多年曆史的悠久公司，但Tokyo Diamond一直在積極引入新的IT工具。  該公司決定遷移到Amazon AWS和虛擬化，以提高業務改進的速度和效率。SIOS AppKeeper在提供所需的應用程序可用性保護方面發揮了重要作用。東京鑽石工具公司遷移到雲和AWS的原因之一是2011年的東日本大地震。  儘管總公司的服務器沒有受到直接損壞，但宮城縣仙台工廠的設備從機架上掉下來，造成了嚴重損壞。  東京鑽石認為需要更好的業務連續性計劃。  這是虛擬化其核心系統和使用雲環境的主要驅動力。

最初，該公司開始將相對較小的應用程序遷移到雲中。  “我們在2011年11月左右開始了遷移。  那時，我們別無選擇，只有AWS。”東京鑽石公司IT系統主管Takuji Kokubo先生說。  他們使用Sony Network Communications的“帶有AWS的託管雲”雲門戶自己管理運營。  Kokubo先生是一個自稱為“ One Man IT操作”的人，因此效率和自動化對於確保公司IT系統在日本以及新加坡和泰國的平穩運行非常重要。

遷移到雲並確定對恢復解決方案的需求 

Diamond Tools實施了雲存儲服務Amazon EC2和Amazon S3。他們將其組件，銷售支持和視頻會議系統移至了AWS。  Diamond Tools的視頻會議系統對其日常運營至關重要。  “該工具在與海外地點進行的各種會議中非常頻繁地使用。  它每月使用約100次，並且從傳統的按需購買即用SaaS系統過渡到AWS，我們每年可以減少多達200萬日元的成本，” Kokubo先生說。  以前，包括其他公司在內的太多用戶同時連接到系統時，語音質量通常會下降。  然後，小久保先生將收到用戶的投訴，但問題無法輕鬆解決。  在AWS上構建公司特定的視頻會議系統可以穩定視頻和音頻質量並減少投訴。

小久保先生很快就遇到了他們的EC2環境問題。“ EC2作為基礎設施是穩定的；但是，有時服務失敗。我一直很擔心，有一天，在一次海外商務旅行中，我接到一個電話說用戶無法訪問該系統。  我必須一直隨身攜帶筆記本電腦，才能通過VPN連接到AWS並恢復失敗的服務。”小久保先生說。  顯然，此過程不可擴展。

在運行組件軟件應用程序的實例上經常發生服務故障。  公司的大多數員工每天早晨都使用組件軟件應用程序檢查日曆或預訂會議室。Kokubo先生說：“如果遇到問題，許多人會打電話給我，問發生了什麼事。” 他通過此經驗了解了自己親自維護系統的風險。

“十年前，一旦出現故障，系統就會停止運行，用戶已經習慣了。但是今天，一旦一切停止，我就會收到投訴。現在，系統有望一直處於運行狀態，就像水龍頭隨時流出的水一樣。  系統停機時間變得越來越無法接受，” Kokubo先生說。

小久保先生始終認為，當在EC2上運行的一項服務失敗時，他必須處理任何問題。  成為唯一能夠解決任何問題的人仍然是他的負擔。  小久保先生說：“作為一家IT商店，我傾向於認為我的價值在於僅提供幫助台功能。  但這不是很好–我需要考慮在沒有我支持的情況下如何使Tokyo Diamond系統正常工作。”

因為他是公司中唯一更多依賴雲服務的IT專業人員，所以他知道他需要幫助。“當索尼網絡通信告訴我SIOS AppKeeper提供了EC2實例的自動化操作和管理時，我決定在研究細節之前就使用它。如果我們有一種能自動恢復EC2服務的解決方案，那麼我就不需要通過隨時隨地連接到VPN來解決每個問題。”

SIOS AppKeeper是一種雲服務，可監視EC2實例並在檢測到任何系統損害時自動重新啟動服務。  當受監視的服務失敗時，SIOS AppKeeper會自動恢復服務，而無需人工干預。

在AWS上運行的應用程序超過10個

Tokyo Diamond繼續將其他應用程序遷移到AWS，到2018年6月，AWS上運行了10多個應用程序。“我認為AWS很有用：操作系統會在10分鐘內啟動，並且可以根據業務靈活地伸縮資源。即使資源不起作用，我們甚至可以刪除它。  但是，處理大量數據的核心系統是使用數據中心而非AWS遷移到虛擬環境的。  Kokubo先生說：“我們同時使用AWS和虛擬數據中心來構建系統，具體取決於用途和需求。”

東京鑽石公司目前監視員工使用AppKeeper所依賴的三個關鍵應用程序，包括其群件應用程序，銷售人員自動化和他們的視頻會議系統。  小久保先生說：“首先，我們對應用程序進行了分類，並決定從其中三個應用程序開始。如果我可以擺脫日常的精神負擔，並在商務旅行中省心，則值得付費。”

SIOS AppKeeper使IT人員能夠專注於其他任務

Kokubo先生說，他不再需要考慮AppKeeper監視的實例的操作和管理。  AppKeeper運行正常。  它騰出了更多時間專注於虛擬機及其其他AWS應用程序。 小久保先生認為AppKeeper為他帶來了這些核心應用程序的安全感。

但是，他確實對SIOS技術開發團隊有關於AppKeeper的要求。 “如果沒有任何事件，我擔心它是否正常運行，否則我可能會忘記如何登錄。如果能經常通知我它正在運行，那就更好了。”  自動操作和管理是SIOS AppKeeper的優勢；但是，如果什麼也沒有發生，它可能是不可見的。

話雖如此，小久保先生同意將他從不必對這些應用程序進行故障排除中解放出來是非常有益的。  現在，他可以花更多的時間在管理上，包括發展Diamond Tool的IT戰略和規劃，安全性以及BCP計劃。

儘管今天Diamond Tool使用SIOS AppKeeper來管理和管理三個應用程序，但它計劃很快將AppKeeper的覆蓋範圍擴展到其他應用程序。  這將使小久保先生能夠在這些增值活動上花費大量時間。  “即使我們試圖僱用系統人員，也很難做到，因為日本的勞動力正在縮減。  未來，我希望系統工具能夠取代使用AI（人工智能）的人們，我希望SIOS AppKeeper也能開發類似AI的功能，以自動解決高影響力的故障。”運營管理的實現。

了解有關SIOS AppKeeper的更多信息

註冊免費試用SIOS AppKeeper

 

 

企業可用性：法院的教訓

企業可用性：法院的教訓

我愛籃球。我喜歡玩遊戲，觀看遊戲並仔細思考遊戲的大腦方面；思想和動機，策略和戰術。我想尋找能正常工作或失敗的小東西，屏幕設置太早或滾動太晚。我喜歡防守和輪換。我想知道教練的練習，演練，旅行等策略。  幾個月前我自然而然地離開了24/7全天候工作日，想像一下，我抽出一天時間去看籃球，更具體地說是我女兒在中學籃球練習。

在觀看的大約三分之一時間內，我無法控制自己。我吹口哨，“勸誘”那個年輕的女孩，惡作劇地著小跑到球場上，大喊：“快跑！忙！”她做到了，耳邊的隊友也做到了。  接下來的幾分鐘，戲劇和演習充滿了活力，清晰的切割，流暢的動作和動力。  但是，它並沒有持續。  取而代之的是，需要更多的哨聲，需要更多的舉動來移動和奔跑，努力發揮，大刀闊斧，下潛，專心，專注，學習和糾正。2個小時快結束時，我將最後一刻的注意力轉移到預言上，“練習的方式就是演奏的方式！”

我幾乎可以感覺到您傳達了AI的精神，而不是人工智能（AI），艾倫·艾弗森（AI）。  “我們在談論，練習。  實踐！”我認為這與可用性有關。  好吧，當我考慮女兒和隊友時，我對籃球的熱愛滿足了我對可用性的熱愛。怎麼樣？

籃球策略與可用性策略類似的三種方式：

• 在籃球運動中，每個團隊都需要一個計劃，以確保企業可用性。
• 在籃球運動中，每個團隊都需要練習該計劃，同上以確保可用性，災難恢復，尤其是計劃好的維護。
• 在籃球比賽中，該計劃在火中受到考驗的情況下，其執行效果只會與實施該計劃時一樣好
  

企業可用性需要計劃 

您的可用性（特別是災難，計劃的維護和中斷恢復策略）僅與您創建的一樣好。簡而言之，您對中斷的計劃是什麼（請注意，雲故障，服務器崩潰，網絡飽和以及人為錯誤）。  您有書面計劃嗎？您是否已確定所有者和備份所有者？您是否知道您的體系結構和拓撲（什麼服務器做什麼，它位於什麼位置，它屬於哪個團隊，服務什麼功能，與它相關的業務優先級以及它需要什麼SLO / SLA）？誰是您的主要供應商，他們的召喚清單是什麼？您的檢查點，數據保護計劃和備份策略是什麼？您要驗證該計劃的測試計劃和驗證計劃是什麼？

企業可用性需求實踐 

一個好的計劃，檢查一下。現在練習。  實施災難恢復步驟和計劃外的停機策略是每個企業配置的必要組成部分。但是，不進行演練的策略並不是真正的策略。在這種情況下，這只是一種可能的提議方法。  它更像是一個建議，而不是實際的記錄計劃。第二步是練習。逐步了解您的計劃策略。排練維護時間。恢復備份和數據。驗證假設和失敗模式。

企業可用性需要測試 

一個計劃和一個演練，檢查。現在您擁有三個中的兩個，讓我回到女兒的團隊。  作為“非官方教練”，我的臨別詞如下：“練習的方式就是比賽的方式！”快進三天。比賽已經結束了。他們所參加的球隊在運動能力上不匹配，並且與去年一樣，當時該球隊的比賽在半場結束時規模過大。  但是今年，人員不足和規模較小的團隊顯然已經做好了更多準備。本來應該是輕鬆的勝利現在進入了接近並列的最後一分鐘。主隊，即對手，開始進行新聞報導。儘管如此，我女兒的球隊還是為這種命運的練習而無意中做出了準備。  隨之而來的不是很好。四次失誤的失誤，三分球命中兩次關鍵犯規，四分命中或零失誤，以及一系列挫敗感最終導致毀滅性的一分失誤。

我的最後一點是，您在實際中斷，災難或計劃內維護方面做得如何？您是否使用真實的數據，真實的客戶以及真正的緊迫感進行練習？您的高層管理人員多久簽到一次？相信我，在充滿壓力的時刻出現老闆會讓人做出奇怪而不明智的事情！您的沙盒和測試系統看起來像生產環境嗎？在過去的生活中，我曾經與一位客戶在產品和質量保證之間使用不同的硬件，存儲和Linux OS版本進行過合作。當他們進入應用程序更新的過程中，災難就來了。  您是否有用戶和數據以及測試期間運行的作業？實際的災難模擬呢？這是一項難以接受的工作，它會測試具有潛在破壞性後果的硬崩潰，從異地恢復，甚至更難於模擬同時發生的多點，多個系統故障，但這種做法往往不可行，往往會使2小時的計劃維護變成八小時的多團隊企業災難。  練習不足或實踐不佳是您的戰略和團隊取得驚人勝利，還是團隊，供應商，企業和客戶遭受慘敗和代價高昂的失敗之間的區別。

在籃球運動中，受到抨擊的計劃只能維持與計劃相同的狀態。  在實施恢復和災難計劃時，關鍵是要製定良好的計劃和驗證，但是出色的實踐才是王道。

請與SIOS的銷售代表聯繫，以了解我們的可用性專家和產品如何幫助您制定計劃，程序和實踐。

回訪有關您永遠不應避免進行模擬的測試的帖子。

—客戶體驗副總裁Cassius Rhue

文章轉載自SIOS

循序漸進：Azure中的ISCSI目標服務器群集

循序漸進：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目標服務器。

如果您對此進行構建，請發表評論，我知道您打算如何使用它！

經群集的凡有凡人許可複制的文章