高可用性（High availability,HA）

轉自：

1.http://baike.baidu.com/view/2850255.htm

2.https://en.wikipedia.org/wiki/High_availability

1.

“高可用性”（High Availability）通常來描述一個系統經過專門的設計，進而減少停工時間，而保持其服務的高度可用性。

計算機的高可用性

計算機系統的 可靠性用平均無故障時間（MTTF）來度量 ，即計算機系統平均能夠正常運作多長時間，才發生一次故障。系統的可靠性越高，平均無故障時間越長。 可維護性用平均維修時間（MTTR）來度量 ，即系統發生故障後維修和重新恢複正常運作平均花費的時間。系統的可維護性越好，平均維修時間越短。 計算機系統的可用性定義為：MTTF/(MTTF+MTTR) * 100% 。由此可見，計算機系統的可用性定義為系統保持正常運作時間的百分比。

負載均衡伺服器的高可用性

為了屏蔽負載均衡伺服器的失效，需要建立一個備份機。 主伺服器和備份機上都運作High Availability監控程式，通過傳送諸如“I am alive”這樣的資訊來監控對方的運作狀況。 當備份機不能在一定的時間内收到這樣的資訊時，它就接管主伺服器的服務IP并繼續提供服務；當備份管理器又從主管理器收到“I am alive”這樣的資訊時，它就釋放服務IP位址，這樣的主管理器就開始再次進行叢集管理的工作了。為在主伺服器失效的情況下系統能正常工作，我們在主、備份機之間實作負載叢集系統配置資訊的同步與備份，保持二者系統的基本一緻。

HA的容錯備援運作過程

自動偵測(Auto-Detect)階段由 主機上的軟體通過 備援偵測線，經由複雜的監聽程式。邏輯判斷，來互相偵測對方運作的情況，所檢查的項目有：主機硬體(CPU和周邊)、主機網絡、 主機作業系統、資料庫引擎及其它應用程式、主機與 磁盤陣列連線。為確定偵測的正确性，而防止錯誤的判斷，可設定安全偵測時間，包括偵測時間間隔，偵測次數以調整安全系數，并且由主機的備援通信連線，将所彙集的訊息記錄下來，以供維護參考。 自動切換(Auto-Switch)階段       某一主機如果确認對方故障，則正常主機除繼續進行原來的任務，還将依據各種容錯備援模式接管預先設定的備援作業程式，并進行後續的程式及服務。 自動恢複(Auto-Recovery)階段          在正常主機代替故障主機工作後，故障主機可離線進行修複工作。在故障主機修複後，透過 備援通訊線與原正常主機連線，自動切換回修複完成的主機上。整個恢複過程完成由EDI-HA自動完成，亦可依據預先配置，選擇回複動作為半自動或不恢複。

HA三種工作方式

（1）主從方式 （非對稱方式） 工作原理：主機工作，備機處于監控準備狀況；當主機當機時，備機接管主機的一切工作，待主機恢複正常後，按使用者的設定以自動或手動方式将服務切換到主機上運作，資料的一緻性通過共享 存儲系統解決。 （2）雙機雙工方式（互備互援） 工作原理：兩台主機同時運作各自的服務工作且互相監測情況，當任一台主機當機時，另一台主機立即接管它的一切工作，保證工作實時，應用服務系統的關鍵資料存放在共享存儲系統中。 （3） 叢集工作方式（多伺服器互備方式） 工作原理：多台主機一起工作，各自運作一個或幾個服務，各為服務定義一個或多個備用主機，當某個主機故障時，運作在其上的服務就可以被其它主機接管。

高可用性的衡量名額

可用性的計算公式： %availability=（Total Elapsed Time－Sum of Inoperative Times）/ Total Elapsed Time elapsed time為operating time+downtime。 可用性和系統元件的失敗率相關。衡量系統裝置失敗率的一個名額是“失敗間隔平均時間”MTBF（mean time between failures）。通常這個名額衡量系統的元件，如磁盤。 MTBF=Total Operating Time / Total No. of Failures Operating time為系統在使用的時間（不包含停機情況）。

高可用性系統的設計

設計系統的可用性，最重要的是滿足使用者的需求。系統的失敗隻有當其導緻服務的失效性足以影響到系統使用者的需求時才會影響其可用性的名額。使用者的敏感性決定于系統提供的應用。例如，在一個能在1秒鐘之内被修複的失敗在一些 聯機事務處理系統中并不會被感覺到，但如果是對于一個實時的科學計算應用系統，則是不可被接受的。 系統的高可用性設計決定于您的應用。例如，如果幾個小時的計劃停機時間是可接受的，也許 存儲系統就不用設計為磁盤可熱插拔的。反之，你可能就應該采用可熱插拔、熱交換和鏡像的磁盤系統。 是以涉及高可用系統需要考慮： 決定業務中斷的持續時間。根據公式計算出的衡量HA的名額，可以得到一段時間内可以中斷的時間。但可能很大量的短時間中斷是可以忍受的，而少量長時間的中斷卻是不可忍受的。 在統計中表明，造成非計劃的當機因素并非都是硬體問題。硬體問題隻占40%，軟體問題占30%，人為因素占20%，環境因素占10%。您的高可用性系統應該能盡可能地考慮到上述所有因素。 當出現業務中斷時，盡快恢複的手段。

導緻計劃内的停機因素有

周期性的備份 軟體更新 硬體擴充或維修 系統配置更改 資料更改

導緻計劃外停機的因素有

硬體失敗 檔案系統滿錯誤 記憶體溢出 備份失敗 磁盤滿 供電失敗 網絡失敗 應用失敗 自然災害 操作或管理失誤 通過有針對性的設計，可以避免上述全部或部分因素帶來的損失。當然，100%的高可用系統是不存在的。

建立高可用性的計算機系統

在UNIX系統上建立高可用性計算機系統，業界的通行做法，也是非常有效的做法，就是采用群集系統（Cluster），将各個 主機系統通過網絡或其他手段有機地組成一個群體，共同對外提供服務。建立群集系統，通過實作高可用性的軟體将 備援的高可用性的硬體元件和 軟體元件組合起來，消除 單點故障： 消除供電的單點故障 消除磁盤的單點故障 消除SPU（System Process Unit）單點故障 消除網絡單點故障 消除軟體單點故障 盡量消除單系統運作時的單點故障

2.

High availability is a characteristic of a system, which aims to ensure an agreed level of operational performance for a higher than normal period.

There are three principlesof system design in high availability engineering:

1. Elimination of single points of failure. This meansadding redundancy to the system so that failure of a component does not mean failure of the entire system. See Reliability Engineering.
2. Reliable crossover. In multithreaded systems, the crossover point itself tends to become a single point of failure. High availability engineering must provide for reliable crossover.
3. Detection of failures as they occur. If the two principles above are observed, then a user may never see a failure. But the maintenance activitymust.

Modernization has resulted in an increased reliance on these systems. For example, hospitals and data centers require high availability of their systems to perform routine daily activities. Availability refers to the ability of the user community to obtain a service or good, access the system, whether to submit new work, update or alter existing work, or collect the results of previous work. If a user cannot access the system, it is - from the users point of view - unavailable.[1]Generally, the term downtime is used to refer to periods when a system is unavailable.

Scheduled and unscheduled downtime

A distinction can be made between scheduled and unscheduled downtime. Typically, scheduled downtime is a result of maintenance that is disruptive to system operation and usually cannot be avoided with a currently installed system design. Scheduled downtime events might include patches to system software that require a reboot or system configuration changes that only take effect upon a reboot. In general, scheduled downtime is usually the result of some logical, management-initiated event. Unscheduled downtime events typically arise from some physical event, such as a hardware or software failure or environmental anomaly. Examples of unscheduled downtime events include power outages, failed CPU or RAM components (or possibly other failed hardware components), an over-temperature related shutdown, logically or physically severed network connections, security breaches, or various application,middleware, and operating system failures.

If users can be warned away from scheduled downtimes, then the distinction is useful. But if the requirement is for true high availability, then downtime is downtime whether or not it is scheduled.

Many computing sites exclude scheduled downtime from availability calculations, assuming that it has little or no impact upon the computing user community. By doing this, they can claim to have phenomenally high availability, which might give the illusion of continuous availability. Systems that exhibit truly continuous availability are comparatively rare and higher priced, and most have carefully implemented specialty designs that eliminate anysingle point of failure and allow online hardware, network, operating system, middleware, and application upgrades, patches, and replacements. For certain systems, scheduled downtime does not matter, for example system downtime at an office building after everybody has gone home for the night.