SIOS APAC Portal

16 9 月, 2021	高可用性架構和最佳實踐高可用性架構和最佳實踐關於高可用性的 13 個鮮為人知的事實 1. Hypervisor HA 與應用程序 HA 不同一個關鍵的誤解是，我之所以具有高可用性，是因為我的硬件或虛擬機管理程序中有冗餘。但是，硬件和管理程序冗餘並不能保證高可用性用於應用程序。也不能保證應用程序的編排將在失敗時正確執行。 2. 在高可用性中，更大並不等於更好如果你是一名力量舉運動員，更大的重量更好，更小的代表更好。或者，如果我們談論擁抱。（你還記得擁抱是我們見到來自不同城鎮的朋友時經常做的事情，我們有一段時間沒見過了。）但是，更大並不總是意味著更好。例如，更大的腎結石肯定不是更好。在更高的可用性中，創建更大、更複雜的解決方案並不總是意味著您將提高您的高可用性。這可能意味著您的可用性相同或更少。這也可能意味著您有一個更大、更複雜的系統，其中包含許多移動部件，需要在停機時進行分類。 3. 一切都失敗了……有時應用程序編程語言可以追溯到 1950 年代。雖然語言、處理器、IDE 和代碼質量有所提高，但現實是“所有應用程序都會在某個時候失敗”。由於異常、錯誤、未處理的終止、意外終止、資源耗盡等導致的失敗時有發生。仍然需要一個主動/主動或主動/被動應用程序可用性策略。 4. 關注“為什麼”和“如何”一樣多我們跳入任務完成模式的自然傾向是一種必要的資產，但需要通過我們對為什麼的問題的回答來加以調節和引導。在不了解業務、應用程序、數據庫和利益相關者要求的情況下向環境添加解決方案將導致：失敗超支表現不佳混亂和過度架構上述所有的與其只關注實現可用性，不如花費必要的資源和精力來了解業務需求和“為什麼”的答案 5. 未修補的問題是常見的遺憾來源做或不做，後果自負。所有未修補的問題的後果是後悔。作為客戶體驗副總裁，我親眼目睹了由於客戶未能及時解決已知問題而導致的停機。 6. 未記錄的問題也會導致停機描繪場景。一位新管理員正在調查網絡上的服務器。使用情況報告表明服務器未處於活動狀態，並且沒有連接任何客戶端。新管理員無法識別服務器，也沒有發現“標籤”、文檔或其他標識符，因此認為應該關閉它。不幸的是，未記錄和未通信的實例實際上是一個備用服務器，當主服務器意外崩潰時，刪除它會導致停機。這不是虛構的故事，而是一個新管理員的真實故事，他錯誤地將服務器識別為空閒 QA 系統並在修補練習之前將其關閉。 7、自滿也是敵人如果內部或云中或介於兩者之間的任何地方的可用性是我們可以“設置並忘記”的，我們都會喜歡它。但是，生活中很少有事情真的像“設置並忘記它”那樣簡單。未來可用性的最大敵人之一是您現在的高可用性成功。當災難很少發生並且團隊確信他們已經實現了持續穩定時，自滿情緒就會介入。成功誘使我們認為什麼都不會改變，因此對高可用性的自滿是高可用性的敵人。企業周圍和企業內部的事物正在發生變化。雲在變化，您的業務需求在變化，應用程序和操作系統也在變化。 8.改變很難改變很難。問問那些一直試圖在睡前放棄第二塊蛋糕的愛吃甜食的人吧。即使在高可用性中也會出現類似的阻力。團隊，即使是那些經歷過災難的團隊，即使改變是好的，也往往不願意改變。他們需要遠見、對原因的理解和支持。其他擁有解決方案的團隊不願意提高高可用性，因為害怕引入不穩定或將自己暴露在新的風險中。 9.所有的改變都不是好的改變改變是好的，當改變是好的。在考慮對更高可用性解決方案和架構進行更改時，根據目標、要求以及在提高可用性的範圍內分析更改至關重要。提高穩定性、增加對關鍵組件的保護、消除變通方法、優化服務可用性並經過全面測試的更改都是很好的更改。 10. 便宜並不總是更好便宜並不總是更好。雖然更便宜的解決方案通常具有較低的價格標籤，但它們也可能帶有許多限制，使其不太理想。當價格標籤較低時，請注意缺少的功能，例如缺乏應用程序意識、有限的編排、隱藏的複雜性、手動恢復和故障轉移，並且僅限於沒有用戶驗證。更便宜的解決方案也可能不包括客戶支持。請務必了解您的更便宜的解決方案是否包含支持，或者支持是否是額外的、大量的附加成本。這同樣適用於減少計算、磁盤或存儲的更便宜的部署。雖然價格標籤和每月成本可能較低，但您的解決方案也可能以不太理想的容量運行。 11.響亮不等於有效聽說過那個叫狼來了的男孩的故事。產生警報風暴的應用程序監控解決方案遲早會被忽略。擁有提供警報的解決方案固然很棒，但如果該解決方案錯誤地或過多地觸發了關鍵警報，則它是無效的。 12. 高可用性是一種文化和心態，而不僅僅是產品或硬件解決方案軟件、硬件、流程、解決方案和服務都是高可用性的一部分。但是，如果沒有跨 IT 職能和業務部門的支持，它將充滿挫敗感並不斷成為預算討論的來源，而不是關於價值、業務穩定性、提高客戶滿意度和降低風險的討論。 13.現在還不晚希望不是實現高可用性的策略，希望您不會遇到嚴重災難或應用程序故障也不需要成為策略。即使距離上次災難已經過去數週或數月，現在也可以設計和構建高度可用的企業架構。聯繫 SIOS了解更多高可用性解決方案為您的應用程序。 – 客戶體驗副總裁 Cassius Rhue 轉載自SIOS
10 9 月, 2021	簡化雲遷移的 12 個問題簡化雲遷移的 12 個問題雲遷移最佳實踐 “雲變得越來越複雜”，這是一個長達一小時的網絡研討會中的第一個聲明，詳細介紹了雲計算和雲遷移的繁榮帶來的變化和機遇。演示者繼續概述了傳統 IT 現在在其遷移過程中面臨的與雲相關的事情。自動售貨機,天藍色, GCP或其他供應商。在向雲的傳統過渡過程中，出現了九個方面的複雜性：定義價錢聯網安全用戶、角色和配置文件申請和許可服務和支持可用性備份作為 SIOS Technology Corp 的客戶體驗副總裁，我已經看到以下領域如何影響向雲的過渡。為了減輕這些複雜性，消費者正在轉向託管服務提供商、雲解決方案架構師、承包商和顧問，以及大量相關服務、指南、博客文章和相關文章。通常在轉向外部或外包資源的過程中，雲的複雜性並未完全消除。取而代之的是，公司及其僱傭的團隊來協助或將他們過渡到雲計算仍然會遇到障礙、減速帶、小問題和挫折。大多數情況下，遷移到雲的過程中出現的這些並發症和減速來自十二個懸而未決的問題：我們遷移到雲的目標是什麼？您當前的內部部署架構是什麼？您有文檔、列表、流程圖或食譜嗎？您的目標雲提供商平台是否支持您的所有應用程序、數據庫、可用性和相關供應商？您當前的本地風險和限制是什麼？哪些應用程序不受保護，本地面臨的最常見問題是什麼？誰負責雲架構和設計？這種架構和設計將如何考慮您當前的定義和雲提供商的定義？誰是關鍵利益相關者，他們的里程碑、業務驅動因素和業務項目的截止日期是什麼？您是否與供應商分享了您的項目計劃和里程碑？當前的流程、治理和業務要求是什麼？遷移預算是多少？它是否包括人員擴充、培訓和服務？您對持續維護、許可和運營費用的估計是多少？您的團隊現有的技能和職責是什麼？誰將負責更新治理、流程、新的雲模型以及各種傳統角色和職責？哪些應用程序、服務或功能將從 IaaS 遷移到 SaaS 模型？了解您的雲目標那麼，回答這十二個問題將如何改善您的雲遷移。正如您從問題中看到的，了解您的雲目標是第一步，也是最重要的一步。“AWS、Azure 或 Google 等雲服務提供商可以提供特定應用程序所需的服務器、存儲和通信資源”這一點幾乎被普遍接受，但對於許多客戶而言，這只會消除“他對計算機的需要”。硬件和管理該硬件的人員。”由於這一事實，客戶通常專注於設備或數據中心的整合或縮減，而沒有考慮到他們仍然需要考慮的額外雲機會和差距。例如，雲做消除硬件管理，但它“才不是消除應用程序及其依賴項對監控和恢復的所有需求，”因此，如果您的目標是從雲中獲得所有可用性，您可能無法實現該目標，或者它可能需要的不僅僅是在本地移動到IaaS 模型。了解您的目標對幫助您規劃雲之旅大有幫助。了解您當前的本地架構正確遷移到雲（或任何新平台）所需的第二類關鍵問題是了解當前的本地架構。此步驟不僅有助於識別需要可用性的關鍵應用程序，還有助於識別它們的底層依賴關係，以及基於雲的存儲、網絡和計算變化對這些應用程序、數據庫和備份解決方案所需的任何更改。回答這個問題也是評估您的應用程序和雲解決方案的準備情況以及量化您當前的風險的關鍵步驟。當您討論和量化當前的限制時，會從解決這些問題中受益匪淺的第三個領域出現。通常，我們會看到發現的這一階段為雲中不存在的當前解決方案的局限性打開了大門。例如，最近我們的服務團隊與受 SQL 數據庫集群性能問題影響的客戶合作。一位協助遷移的 SIOS 專家詢問了解決方案和架構以及 VM 大小調整決策。片刻之後，部署了一個更大的應用程序大小的實例，以糾正客戶由於對計算、內存和存儲的本地限製而接受的限制。同樣，我們也曾與對存儲敏感的客戶合作過。由於磁盤容量限制，他們將運行具有較小磁盤和頻繁調整大小策略的應用程序。雖然應該考慮存儲成本，但以最小的利潤運行可能成為過去的限制。了解業務和治理變化最後一組問題可幫助您的團隊了解需要更新或替換的日程安排、業務影響、截止日期和治理變更，因為它們可能不再適用於雲。遷移到雲可以是一個平穩的過渡和旅程。但是，如果無法評估您在旅程中的位置以及何時需要完成旅程，可能會變成一場噩夢。了解時機很重要，可以通過考慮利益相關者、應用程序供應商、業務里程碑和業務季節來獲得極大的幫助。自私地，SIOS Technology Corp. 希望客戶了解他們的里程碑，因為作為服務提供商，它最大限度地減少了意外。但是，我們也鼓勵客戶回答這些問題，因為他們經常發現部門和利益相關者之間存在分歧。 DBA 認為轉換將在本月的最後一個週末進行，但財務部門打算在同月的最後一個週末結賬；或者 IT 團隊認為轉換可以在星期一發生，但應用程序團隊要到星期三才可用，也許最重要的是，法律團隊還沒有梳理新的 NDA、協議、許可和治理變更所需的清單以將其拉下來全部一起。當客戶帶著安全感和同理心解決問題時，經常出現的問題是碎片、所有權、流程和決策者的難題，需要使用雲提供商的框框和關於預算、人員配備、培訓的誠實對話重新組合在一起，和服務。最終的結果可能不是一次完美的遷移，但肯定會是一次成功的遷移。如需有關雲遷移策略和高可用性實施的幫助，請聯繫 SIOS Technology Corp. – Cassius Rhue，客戶體驗副總裁了解有關常見問題的更多信息雲遷移挑戰. 閱讀關於一些誤解雲中的可用性。轉載自SIOS
5 9 月, 2021	實現有效 IT 系統冗餘的 3 個步驟實現有效 IT 系統冗餘的 3 個步驟在某些行業中，重複任務可能會浪費公司資源，並可能導致意外的人為錯誤和時間損失。但在管理系統和數據的 IT 世界中，被稱為“冗餘”的複製過程對於組織的持續成功至關重要。 1. 使用冗餘工具保護您的設備和軟件提供冗餘的 IT 工具可確保您的系統和軟件資產免受丟失或損壞。他們還應該提供及時的恢復，以恢復您的業務中斷。 IT 系統中的冗餘意味著能夠複製您的系統組件，無論是在硬件、VM 還是雲上。在用戶層面，一個簡單的例子是製作用戶 PC 系統的副本並將其存儲在另一台 PC 上作為備用，以防用戶的 PC 出現故障。這個相同的概念可以應用於任何其他計算機組件，包括服務器、存儲設備和網絡設備。例如，“鏡像”是將相同數據寫入多個磁盤的機制，使這些磁盤變得冗餘。冗餘使您能夠通過盡快切換到備用設備來從設備故障中恢復。企業嚴重依賴其 IT 系統，系統故障導致的服務中斷可能會導致大量的運營停機。因此，冗餘對於 IT 系統保持故障恢復能力和降低業務中斷風險必不可少。根據您組織的規模和地理位置，這可能很困難、耗時且成本高昂。 2. 使所有數據保持最新並與集群同步具有相同規格和環境（操作系統和軟件）的冗餘設備並不能在出現故障時自動保護用戶文件和電子郵件以及任務關鍵型應用程序數據的丟失。這不僅適用於個人用戶的 PC，而且適用於跨多個服務器和存儲設備的更大企業規模。數據存儲設備出現故障可能會使您的業務運營嚴重延遲，無法訪問最新數據。對於大型應用程序，如數據庫服務器,甲骨文，或者樹液，恢復時間可能很長。不幸的是，許多公司認為只需備份數據就可以降低風險。然而，直到生產設備突然出現故障，大多數人都沒有意識到將數據從備份副本真正恢復到備用設備是多麼困難。與之形成鮮明對比的是，備用設備已經能夠使用故障生產設備上的相同數據，您所要做的就是啟動備用機器並切換到它。恢復工作會容易得多。這可以通過高可用性 (HA) 集群系統實現。聚類通過創建冗餘來補償不可預見的系統故障，有助於提高軟件和硬件系統的可靠性和性能。 HA集群系統由主備系統中的冗餘服務器和兩台服務器都可以訪問的外部存儲（例如共享磁盤）組成。萬一運行服務器出現故障，通過切換到備用服務器，可以通過備用服務器和包含最新數據的外部存儲器的組合來繼續服務。順便說一句，同樣的功能可以用“複製”，它實時同步服務器內部磁盤之間的數據。複製也是應對災難恢復的絕佳措施，因為它不需要安裝昂貴的外部存儲並在兩個實例上保留最新數據。根據輔助實例的位置，同步或異步複製數據。請注意，數據的複制方式會影響恢復時間目標 (RTO) 和恢復點目標 (RPO)。 3. 自動故障轉移無論您使用 HA 集群系統還是複制，最佳做法是避免在發生故障時手動切換服務器。相反，應自動化該過程，以便在稱為故障轉移的過程中毫不延遲地執行該過程。配置 HA 集群系統/複製的自動故障轉移可以最大限度地減少停機時間並減少人為錯誤。基於 SIOS SAN 和 SANLess 的集群解決方案提供高可用性和災難恢復適用於物理、虛擬、雲或混合雲環境中的關鍵任務應用程序。如需更多信息，請參閱我們的Windows 和 Linux 高可用性產品. 轉載自SIOS
29 8 月, 2021	將應用程序遷移到雲端將應用程序遷移到雲端我們怎麼去那裡？ *在您的雲和更高可用性之旅中，請考慮作者和企業家的建議Nilofer Merchant（有下面的一個鏈接就可以了） .* 在不到 72 小時內，我已經多次回答了同一個問題：你如何獲得那裡?開始是我的一個大女兒問我如何去學校相關的約會，接著是一個年幼的孩子問我去商店的路線，最後我的大女兒問我如何到達特定目的地在該州的某個地方。他們都問了同樣的問題。但在每種情況下，問題的背景和預期的答案都大不相同。作為作家和企業家尼羅弗商人說，很多關於“你如何到達那裡？”這個問題的答案。不僅取決於你那裡，但也對你這裡. 您當前的應用程序“在這裡”是什麼？弄清楚如何移動你的第一步應用那裡（到雲，或到雲中更高的可用性）是正確命名“這裡”。那麼，你的“這裡”是什麼？你對這個問題的回答可以像我和女兒們談話的地點一樣多種多樣。我的一個女兒從我們家的背景下問道。另一個的背景是從一個不同狀態的起點開始，最小的從一個理論的地方問起（希望我們能得到奶昔）。當你考慮你的定義和“這裡”的細節時，首先要問一些基本問題：你的是什麼關鍵應用，它們是如何受到保護的？你在哪裡部署高可用性保護為您的應用程序？如何保護您的關鍵數據？您目前的團隊規模是多少？您對保護應用程序和數據的解決方案和服務的信心如何？您的關鍵企業系統和應用程序工作負載當前在哪裡運行？如果您在本地，那是本地服務器還是虛擬機？或者這裡是私有云，還是沒有 HA 的公共雲？您遷移到雲和在雲中管理應用程序的預算是多少？你“在這裡”有什麼疲倦、不確定、不安或不滿？定義“這裡”是起點，它幫助我們感覺我們朝著更好的“那裡”前進，所以慢慢來。想想在你的“這裡”的參數中還有什麼形狀、定義、限製或存在？“這裡”是多產品部署、全球 IT 團隊基礎設施，還是其他一些多地點、多辦公室安排？您的團隊是全球分佈、外包還是組合？如果你看看你的“這裡”有什麼突出的地方，你的團隊、公司、產品或企業標誌是什麼？什麼是關鍵且經常出現的痛點，例如缺乏培訓、缺少冗餘、架構指南不完整、對現有解決方案感到失望、雲複雜性、你的“那裡”是什麼？私有云、公共雲、混合雲還是多雲？在你弄清楚你的“這裡”之後，從商人的文章中解脫出來的第二步是“弄清楚'那裡'可能是什麼。作為客戶體驗副總裁，我曾與許多客戶合作過，他們希望“那裡”有一個零停機時間、計劃內或計劃外的環境，或者應用程序故障轉移是無縫的並且在兩分鐘或更短的時間內完成。其他客戶的目標不那麼高，尋求適合五 (5) 到九 (9) 分鐘窗口內的停機時間，或者更喜歡更長的窗口，並根據對故障通知的響應進行手動覆蓋選項。還有一些客戶希望“那裡”有更好的通知、清晰的解決方案和建議、特定於應用程序的編排，以及通過供應商和合作夥伴的專家來增強他們的團隊的方式。那麼你的“那裡”的主要特點是什麼？你買得起什麼？當您查看“這裡”的辛勤回答時，有什麼特別之處？需要解決“這裡”的哪些項目，以創建更理想的團隊、企業、可用性、數據中心和生活的未來版本。您的“那裡”是否包括更多的彈性和冗餘、更多的應用程序編排、更好的分析或更低的成本？私有云、公共雲、混合雲或多雲在您的“那裡”中處於什麼位置？你的“這裡”如何改善，因為你已經做到了“那裡”。從“這裡”到“那裡” 根據Merchant 的說法，最後一步是“弄清楚我們從'這裡' 到'那裡' 的方式。如果在你的“這裡”很難，那麼只有投入工作去思考“那裡”可能是什麼才有意義。換句話說，不要簡單地將您的應用程序遷移到雲中。考慮創建滿足您所有期望的結果所需的資源和服務。想一想專注於專門構建的高可用性解決方案的供應商、解決方案提供商、服務團隊和公司可以幫助您“實現目標”。與我女兒的“那裡”不同，沒有用於繪製從“這裡”到“那裡”或云遷移的旅程的 Waze。但是，通過仔細考慮您當前的情況，包括您的痛苦、挫折、預算限制和您想要的結果，您可以得出一個不僅僅是簡單的雲遷移的解決方案。它可能意味著更令人滿意的日常體驗，不受對應用程序故障和停機時間的恐懼以及故障排除和最終用戶投訴的麻煩的影響。在計劃將應用程序遷移到雲時聽取商家的建議可以為您帶來廣泛的可能性，從定義更強大的架構、更改 HA 軟件解決方案、與服務提供商合作、遷移到多雲、混合雲或其他雲模型。這甚至可能意味著重新使用您自己的數據中心。 20 多年來，SIOS 一直在幫助企業實施高可用性和災難恢復保護本地、雲和混合雲環境中的關鍵應用程序。我們可以提供專業知識，幫助您完成從“這裡”到“那裡”乃至更遠的應用程序 HA 和 DR 之旅。有關更多信息，請聯繫 SIOS – 客戶體驗副總裁 Cassius Rhue 轉載自SIOS
25 8 月, 2021	使用 Windows Server 故障轉移集群在 #AWS 上集群 SAP #ACS 和 #ERS 使用 Windows Server 故障轉移集群在 #AWS 上集群 SAP #ACS 和 #ERS 當確保高可用性對於在 Windows Server 上運行的 SAP ASCS 和 ERS，您要使用的主要集群解決方案是Windows Server 故障轉移群集. 但是，在 AWS 中執行此操作時，您會很快發現在 AWS 中進行部署時需要了解如何克服一些障礙。我最近寫了這個分步指南已發佈在 SAP 博客上，可引導您完成整個過程。如果您有任何問題，請發表評論。經授權轉載聚集前世

Results 1-5 of 706
Page 1 of 142 >

加入我們的郵件列表

First Name Last Name Email Address
搜索