하이 어베이러빌리티

High availability

High Availability(HA; 고가용성)는 통상적인 기간보다 높은 기간 동안 합의된 수준의 가동 시간을 보장하는 것을 목표로 하는 시스템의 특성입니다.

현대화로 인해 이러한 시스템에 대한 의존도가 높아졌습니다.예를 들어, 병원이나 데이터 센터에서는 일상적인 작업을 수행하기 위해 시스템의 고가용성이 필요합니다.가용성이란 사용자 커뮤니티가 서비스나 상품을 입수하거나 시스템에 접속하거나 새로운 작업을 제출하거나 기존 작업을 갱신 또는 변경할 것인지, 이전 작업의 결과를 수집할 수 있는 능력을 말합니다.유저가 시스템에 액세스 할 수 없는 경우는, 유저의 관점에서는 사용[1]수 없습니다.일반적으로 다운타임이라는 용어는 시스템을 사용할 수 없는 기간을 가리킵니다.

원칙

신뢰성 엔지니어링에서는 고가용성을 실현하는 데 도움이 되는 시스템 설계의 3가지 원칙이 있습니다.

  1. 단일 장애 지점 제거즉, 컴포넌트 장애가 시스템 전체의 장애를 의미하지 않도록 시스템에 용장성을 추가하거나 구축하는 것을 의미합니다.
  2. 신뢰성 높은 크로스오버.다중 시스템에서는 크로스 포인트 자체가 단일 장애 지점이 되는 경향이 있습니다.신뢰할 수 있는 시스템은 신뢰할 수 있는 크로스오버를 제공해야 합니다.
  3. 장애가 발생했을 때의 검출.위의 두 가지 원칙을 준수할 경우 사용자에게 장애가 발생하지 않을 수 있지만 유지관리 작업은 반드시 수행해야 합니다.

예정된 다운타임과 예정되지 않은 다운타임

스케줄된 다운타임과 예정되지 않은 다운타임을 구분할 수 있습니다.통상, 스케줄 다운 타임은, 유지보수의 결과이며, 시스템 운용에 지장을 주어, 현재의 시스템 설계에서는 피할 수 없습니다.예약된 다운타임 이벤트에는 재부팅이 필요한 시스템 소프트웨어에 대한 패치 또는 재부팅 시에만 적용되는 시스템 구성 변경이 포함될 수 있습니다.일반적으로 예정된 다운타임이 발생하는 것은 논리적인 관리 시작 이벤트가 원인입니다.계획되지 않은 다운타임 이벤트는 일반적으로 하드웨어 또는 소프트웨어 장애 또는 환경 이상과 같은 물리적 이벤트에서 발생합니다.예기치 않은 다운타임 이벤트의 예로는 정전, CPU 또는 RAM 컴포넌트 장애(또는 기타 하드웨어 컴포넌트 장애), 과열 관련 셧다운, 논리 또는 물리적으로 절단된 네트워크 연결, 보안 위반 또는 다양한 애플리케이션, 미들웨어운영 체제 장애 등이 있습니다.

사용자에게 예정된 다운타임을 벗어나 경고할 수 있는 경우 구별이 유용합니다.그러나 진정한 고가용성을 위해 필요한 경우 다운타임은 예약 여부에 관계없이 다운타임입니다.

많은 컴퓨팅 사이트에서는 예정된 다운타임이 컴퓨팅 사용자 커뮤니티에 거의 또는 전혀 영향을 미치지 않는다고 가정하여 가용성 계산에서 제외됩니다.이렇게 하면 가용성이 매우 높다고 주장할 수 있으며, 이는 지속적인 가용성에 대한 착각을 불러일으킬 수 있습니다.진정한 지속적인 가용성을 제공하는 시스템은 비교적 드물고 가격도 높으며, 대부분의 시스템은 단일 장애 지점을 배제하고 온라인 하드웨어, 네트워크, 운영 체제, 미들웨어 및 애플리케이션 업그레이드, 패치 및 교체를 가능하게 하는 전문 설계를 신중하게 구현하고 있습니다.일부 시스템에서는 예정된 다운타임은 문제가 되지 않습니다.예를 들어, 모든 사람이 밤에 집에 돌아간 후의 사무실 건물에서의 시스템 다운타임은 문제가 되지 않습니다.

백분율 계산

가용성은 보통 특정 연도의 가동 시간 백분율로 표시됩니다.다음 표는 시스템을 계속 가동해야 한다는 전제 하에 특정 비율의 가용성에 허용되는 다운타임을 보여 줍니다.서비스 레벨 어그리먼트는 월별 과금 사이클에 맞춰 서비스 크레딧을 계산하기 위해 월별 다운타임 또는 가용성을 참조하는 경우가 많습니다.다음 표는 특정 가용성 비율에서 시스템을 사용할 수 없는 시간까지의 변환을 보여 줍니다.

가용성 % 연간[note 1] 다운타임 분기당 다운타임 수 월별 다운타임 주간 다운타임 1일당 다운타임(24시간)
90% ('1.9') 36.53일 9.13일 73.05 시간 16.80 시간 2.40시간
95% ('1.9인치') 18.26일 4.56일 36.53 시간 8.40 시간 1.20시간
97% ('1/4/9') 10.96일 2.74일 21.92시간 5.04 시간 43.20분
98 % ('1 및 7/8 인치) 7.31일 43.86 시간 14.61 시간 3.36시간 28.80분
99 % ("2.9 인치") 3.65일 21.9시간 7.31 시간 1.68시간 14.40분
99.5% ('2.9인치') 1.83일 10.98 시간 3.65시간 50.40분 7.20분
99.8%('8분의 2 및 7') 17.53 시간 4.38 시간 87.66분 20.16분 2.88분
99.9% ('3.9') 8.77 시간 2.19시간 43.83분 10.08분 1.44분
99.95% ('3.95%') 4.38 시간 65.7분 21.92분 5.04분 43.20초
99.99% ('4.99%') 52.60분 13.15분 4.38분 1.01분 8.64초
99.995 % ('4.99 인치 반') 26.30분 6.57분 2.19분 30.24초 4.32초
99.999% ('5.99') 5.26분 1.31분 26.30초 6.05초 864.00 밀리초
99.999 % ('6.99') 31.56초 7.89초 2.63초 604.80 밀리초 86.40 밀리초
99.99999 % ('7.99') 3.16초 0.79초 262.98 밀리초 60.48 밀리초 8.64 밀리초
99.99999 % ('8.99') 315.58 밀리초 78.89 밀리초 26.30 밀리초 6.05 밀리초 864.00마이크로초
99.9999999%('9.99') 31.56 밀리초 7.89 밀리초 2.63 밀리초 604.80 마이크로초 86.40 마이크로초

가동 시간과 가용성은 논의되는 항목이 일관되게 유지되는 한 동의어로 사용할 수 있습니다.즉, 시스템은 가동할 수 있지만 네트워크 장애의 경우와 같이 서비스를 이용할 수 없습니다.이는 작업 가능한 시스템으로 볼 수도 있지만, 그 서비스는 (소프트웨어 서비스/프로세스의 관점과 달리) 기능적인 관점에서 올라오지 않습니다.여기서 중요한 것은 서버 하드웨어, 서버 OS, 기능 서비스, 소프트웨어 서비스/프로세스 등입니다.논의 내내 관점을 일관되게 유지하면 가동 시간과 가용성을 동의어로 사용할 수 있습니다.

'나인'

특정 등급의 백분율은 자릿수 또는 자릿수의 "nines 클래스"에 의해 참조되는 경우가 있습니다.예를 들어, 정전(정전, 정전 또는 서지) 없이 공급되는 전기는 99.999%의 시간에서 5.[2]99%의 신뢰성,특히 메인프레임[3][4] 또는 엔터프라이즈 컴퓨팅과 관련하여 서비스 수준 계약의 일부로 사용되는 경우가 많습니다.

마찬가지로 5로 끝나는 퍼센티지에는 통상적인 이름(통상은 9진수, 다음에 5진수)이 있습니다.따라서 99.95%[5][6]는 3N5로 약칭된 3N5입니다.이것은 통상적으로 "3.5nines"[7]라고 불리지만, 이는 올바르지 않습니다.즉, 5는 2의 계수일 뿐이고, 9는 10의 계수이기 때문에 5는 0.3nines입니다(아래 식: 2 0.\ style 2 \.3[note 2] : 99.95%의 가용성은 3.3nines가 아닙니다.즉, 99.9%의 가용성을 99.95%로 하면 2배(0.1%~0.05%의 가용성을 얻을 수 없음)가 되지만 99.95%에서 99.99%로 변경하면 5배([note 3]0.05%~0.01%)가 됩니다.

시스템 불가능 xx})에 기초한 c({c}) 클래스 공식은 다음과 같습니다.

(cf. 바닥 천장 기능).

물질의 순도를 나타내기 위해 유사한 측정이 사용되기도 합니다.

일반적으로 네트워크 엔지니어가 가용성을 모델링 및 측정할 때 사용하는 숫자는 많지 않습니다. 이는 공식으로 적용하기 어렵기 때문입니다.이용 불능은 확률(0.00001 등) 또는 연간 다운타임으로 나타나는 경우가 많습니다.이용 가능 여부는 종종 [citation needed]마케팅 문서에서 확인할 수 있습니다.이용 불능의 영향이 [9]발생 시간에 따라 달라진다는 것을 적절히 반영하지 못하기 때문에 "9"의 사용에 의문이 제기되었다.9s가 많은 경우, "사용 불가능" 지수(업타임보다는 다운타임 측정)를 처리하는 것이 더 쉽습니다.예를 들어 하드 디스크 또는 데이터 링크 비트 오류율에 가용성 메트릭이 아닌 "사용 불가능"이 사용되는 이유가 여기에 있습니다.

때때로 유머러스한 용어인 "nine fives"(55.5555555)가 "five nines" (99.[10][11][12]999%)와 대조를 이루지만, 이것은 실제 목표가 아니라 오히려 합리적인 목표를 완전히 달성하지 못한 것에 대한 비꼬는 표현이다.

측정 및 해석

가용성 측정은 어느 정도 해석될 수 있습니다.1년에 365일 가동된 시스템은 피크 사용 기간 동안 9시간 동안 지속된 네트워크 장애로 인해 기능이 상실될 수 있습니다.사용자 커뮤니티에서는 시스템을 사용할 수 없는 것으로 간주되지만 시스템 관리자는 100% 가동 시간을 요구합니다.그러나 가용성에 대한 진정한 정의를 고려할 때 시스템은 약 99.9% 또는 99.9%의 가용 시간(매년 8760시간 중 8751시간의 가용 시간)을 사용할 수 있습니다.또, 퍼포먼스 문제가 발생하고 있는 시스템은, 시스템이 계속 기능하고 있는 경우에서도, 유저에 의해서 부분적으로 또는 완전하게 이용할 수 없는 것으로 간주되는 경우가 많습니다.마찬가지로 일부 애플리케이션 기능을 사용할 수 없는 경우 관리자는 이를 눈치채지 못할 수 있지만 사용자에게 큰 피해를 줄 수 있습니다. 진정한 가용성 척도는 전체론입니다.

가용성은 그 자체로 가용성이 높은 포괄적인 모니터링 도구("계장")를 사용하여 측정해야 합니다.계측이 부족한 경우, 신용 카드 처리 시스템이나 전화 교환기 등, 밤낮으로 대량의 거래 처리를 서포트하는 시스템은, 수요의 정기적인 소강을 경험하는 시스템보다, 적어도 유저 자신이 본질적으로 감시하는 것이 좋은 경우가 많다.

대체 메트릭은 Mean Time Between Failure(MTBF; 평균 고장 간격)입니다.

밀접하게 관련된 개념

복구 시간(또는 복구 시간 목표(RTO)라고도 함)은 가용성과 밀접하게 관련되어 있습니다.이는 계획된 운영 중단에 필요한 총 시간 또는 계획되지 않은 운영 중단에서 완전히 복구하는 데 필요한 시간입니다.또 다른 메트릭은 평균 복구 시간(MTTR)입니다.특정 시스템 설계 및 장애의 경우 복구 시간이 무한할 수 있습니다. 즉, 완전한 복구가 불가능합니다.그러한 예로는 세컨더리 디저스터 리커버리 데이터 센터가 없을 때 데이터 센터와 그 시스템이 파괴되는 화재나 홍수 등이 있습니다.

또 다른 관련 개념은 데이터 가용성입니다. 즉, 데이터베이스 및 기타 정보 스토리지 시스템이 시스템 트랜잭션을 성실히 기록하고 보고하는 정도를 말합니다.정보 관리는 다양한 장애 이벤트에서 허용 가능한(또는 실제) 데이터 손실을 판단하기 위해 데이터 가용성(복구 시점 목표)에 개별적으로 초점을 맞추는 경우가 많습니다.일부 사용자는 애플리케이션 서비스 중단을 허용할 수 있지만 데이터 손실은 허용할 수 없습니다.

서비스 레벨 어그리먼트("SLA")는 조직의 가용성 목표와 요건을 규정합니다.

군사 통제 시스템

고가용성은 무인 자동차자율 해양 선박에서 제어 시스템의 주요 요건 중 하나이다.통제 시스템이 작동하지 않으면 지상 전투 차량(GCV)이나 ASW 연속 추적 무인선(ACTUV)이 손실될 것이다.

시스템 설계

전체 시스템 설계에 컴포넌트를 추가하면 복잡한 시스템은 본질적으로 잠재적인 장애 지점이 더 많고 올바르게 구현하기가 더 어렵기 때문에 고가용성을 실현하기 위한 노력이 저해될 수 있습니다.일부 분석가는 가장 가용성이 높은 시스템은 단순한 아키텍처(종합적인 내부 하드웨어 용장성을 갖춘 단일 고품질 다목적 물리 시스템)에 준거하고 있다고 주장하지만, 이 아키텍처는 패치 적용 및 운영 체제용으로 시스템 전체를 정지해야 하는 요건에 시달리고 있습니다.pgrades.보다 고도의 시스템 설계를 통해 서비스 가용성에 영향을 주지 않고 시스템을 패치 및 업그레이드할 수 있습니다(로드 밸런싱 및 페일오버 참조).

고가용성을 실현하기 위해서는 복잡한 시스템에서의 운용을 복원하기 위해 사람의 조작이 적게 필요합니다.그 이유는 가동 중단의 가장 일반적인 원인이 사람의 [13]실수이기 때문입니다.

이중화는 높은 수준의 가용성을 가진 시스템을 만드는 데 사용된다(예: 항공기 비행 컴퓨터).이 경우, 높은 수준의 고장 검출 가능성과 공통 원인 고장의 회피가 필요합니다.용장성에는 패시브 용장성과 액티브 용장성의 2종류가 있습니다.

패시브 용장성은 성능 저하를 수용할 수 있는 충분한 용량을 설계에 포함시킴으로써 고가용성을 실현하기 위해 사용됩니다.가장 간단한 예는 두 개의 별도 엔진을 가진 보트로 두 개의 별도 프로펠러를 구동합니다.보트는 엔진이나 프로펠러 하나 고장에도 불구하고 목적지를 향해 계속 나아갑니다.보다 복잡한 예로는 송전을 수반하는 대규모 시스템 내의 다중 발전 설비가 있습니다.단일 컴포넌트의 오작동은 결과적으로 성능 저하가 시스템 전체의 사양 한계를 초과하지 않는 한 고장으로 간주되지 않습니다.

액티브 용장성은 복잡한 시스템에서 사용되며 성능 저하 없이 고가용성을 실현합니다.고장을 검출하고 투표 스킴을 사용하여 고장난 항목을 우회하도록 시스템을 자동으로 재구성하는 방법을 포함하는 설계에 같은 종류의 여러 항목을 통합한다.이는 연결된 복잡한 컴퓨팅 시스템에서 사용됩니다.인터넷 라우팅은 [14]이 지역의 Birman과 Joseph의 초기 작업에서 파생되었습니다.액티브한 용장성은 잘못된 투표 로직으로 인한 연속적인 시스템 재구성 등 보다 복잡한 장애 모드를 시스템에 도입할 수 있습니다.

다운타임 없는 시스템 설계는 모델링과 시뮬레이션에서 평균 장애 간격은 계획된 유지보수, 업그레이드 이벤트 또는 시스템 수명 간격을 크게 초과한다는 것을 의미합니다.다운타임 제로에는 대규모 중복이 수반되며, 이는 일부 항공기 유형 및 대부분의 통신 위성에 필요합니다.Global Positioning System은 제로 다운타임 시스템의 한 예입니다.

장황성이 제한된 시스템에서 장애 계측을 사용하여 고가용성을 실현할 수 있습니다.유지보수 작업은 장애 표시기가 활성화된 후에만 짧은 다운타임 기간 동안 수행됩니다.장애는 미션 크리티컬 기간 중에 발생한 경우에만 중요합니다.

모델링시뮬레이션은 대규모 시스템의 이론적 신뢰성을 평가하기 위해 사용됩니다.이러한 종류의 모형 결과는 다양한 설계 옵션을 평가하는 데 사용됩니다.시스템 전체의 모델을 작성하고, 컴포넌트를 제거함으로써 모델에 스트레스를 준다.용장성 시뮬레이션에는 N-x 기준이 포함됩니다.N은 시스템의 총 컴포넌트 수를 나타냅니다.x는 시스템에 부하를 주는 데 사용되는 컴포넌트 수입니다.N-1은 하나의 구성요소가 고장난 경우 가능한 모든 조합으로 성능을 평가하여 모델에 스트레스를 가함을 의미합니다.N-2는 두 개의 구성요소가 동시에 고장난 경우 가능한 모든 조합으로 성능을 평가하여 모델에 스트레스를 가함을 의미합니다.

사용할 수 없는 이유

2010년에 학계의 가용성 전문가를 대상으로 한 조사에서는, 엔터프라이즈 IT시스템을 이용할 수 없는 이유에 대해 순위를 매겼습니다.모든 이유는 다음 각 영역의 베스트프랙티스를 따르지 않기 때문입니다(중요도 순서).[15]

  1. 관련 컴포넌트 감시
  2. 요건 및 조달
  3. 운용
  4. 네트워크 장애 회피
  5. 내부 애플리케이션 장애 방지
  6. 장애가 발생한 외부 서비스 회피
  7. 물리 환경
  8. 네트워크의 용장성
  9. 백업 기술 솔루션
  10. 백업 프로세스 솔루션
  11. 물리적인 장소
  12. 인프라스트럭처의 용장성
  13. 스토리지 아키텍처의 용장성

요인 자체에 대한 책이 [16]2003년에 출판되었다.

이용할 수 없는 경우의 비용

IBM Global Services의 1998년 보고서에 따르면, 1996년 미국 기업은 생산성과 [17]수익의 손실로 인해 사용할 수 없는 시스템으로 인해 45억 4천만 달러의 손실을 입은 것으로 추정되었습니다.

「 」를 참조해 주세요.

메모들

  1. ^ 연간 365.25일 사용.일관성을 유지하기 위해 모든 시간은 소수점 2자리로 반올림됩니다.
  2. ^ 이 근사치에 대한 자세한 내용은 기저 2에 관한 수학적 일치성을 참조한다.
  3. ^ 로그 척도의 "Twice as many"는 2 × ×< × \ \ 2 < \ 5}의 2개의 인수를 의미합니다.

레퍼런스

  1. ^ Floyd Piedad, Michael Hawkins (2001). High Availability: Design, Techniques, and Processes. Prentice Hall. ISBN 9780130962881.
  2. ^ 강의 노트 M.켄트 주립 대학교 네스테렌코
  3. ^ 새로운 메인프레임 소개: 대규모 상용 컴퓨팅 5장 IBM(2006) 가용성
  4. ^ IBM zEnterprise EC12 비즈니스 가치 비디오(youtube.com
  5. ^ Precious metals, Volume 4. Pergamon Press. 1981. p. page 262. ISBN 9780080253695.
  6. ^ PVD for Microelectronics: Sputter Desposition to Semiconductor Manufacturing. 1998. p. 387.
  7. ^ Murphy, Niall Richard; Beyer, Betsy; Petoff, Jennifer; Jones, Chris (2016). Site Reliability Engineering: How Google Runs Production Systems. p. 38.
  8. ^ Josh Deprez (April 23, 2016). "Nines of Nines". Archived from the original on September 4, 2016. Retrieved May 31, 2016.
  9. ^ 에반 L. 마르쿠스, 9의 신화
  10. ^ Newman, David; Snyder, Joel; Thayer, Rodney (June 24, 2012). "Crying Wolf: False alarms hide attacks". Network World. Vol. 19, no. 25. p. 60. Retrieved March 15, 2019. leading to crashes and uptime numbers closer to nine fives than to five nines.
  11. ^ Metcalfe, Bob (April 2, 2001). "After 35 years of technology crusades, Bob Metcalfe rides off into the sunset". ITworld. Retrieved March 15, 2019. and five nines (not nine fives) of reliability
  12. ^ Pilgrim, Jim (October 20, 2010). "Goodbye Five 9s". Clearfield, Inc. Retrieved March 15, 2019. but it seems to me we are moving closer to 9-5s (55.5555555%) in network reliability rather than 5-9s
  13. ^ "Top Seven Considerations for Configuration Management for Virtual and Cloud Infrastructures". Gartner. October 27, 2010. Retrieved October 13, 2013.[데드링크]
  14. ^ RFC 992
  15. ^ Ulrik Franke, Pontus Johnson, Johan König, Liv Marcks von Würtemberg:엔터프라이즈 IT 시스템 가용성– 전문가 기반의 베이지안 모델 Proc. 제4회 소프트웨어 품질 및 유지보수성에 관한 국제 워크숍(WSQM 2010), 마드리드, [1] 아카이브, 2012년 8월 4일 아카이브.
  16. ^ Marcus, Evan; Stern, Hal (2003). Blueprints for high availability (Second ed.). Indianapolis, IN: John Wiley & Sons. ISBN 0-471-43026-9.
  17. ^ IBM 글로벌 서비스, 시스템 가용성 향상, IBM 글로벌 서비스, 1998, [2]

외부 링크