Mission-Critical vs Business-Critical
Mission-Critical Enviroments
- 오동작 시 사람의 생명에 영향을 미치는 시스템/서비스
- 원자력 발전소 관제 시스템
- 항공 관제 시스템
- 119 응급 콜 센터
Business-Critical Enviroments
- 오동작 시 회사의 수익이나 생산성에 영향을 미치는 서비스/시스템
- 인터넷 전자결제 시스템
- 전자 상거래 시스템
가용성
- 궁극적인 목적은 시스템에 오류가 발생해도 7일 24시간동안 사용자에게 지속적인 서비스르 제공하는 것.
가용성을 구하는 공식
가용성(%) = (MY - MF) / MY * 100
- MY = 1년을 분으로 환산(365 24 60)
- MF = 1년 중 오류에 의해 서비스가 정지된 시간을 분으로 환산
MF를 환산 시, 계획된 유지보수에 의한 서비스 정지시간으 제외한다.
ex.) 1년동안 총 서비스 다운이 52.5분이 발생했다면
(525600-52.5) / 525600 * 100 = 99.990011415% 의 가용성을 가진다.
Five 9s
- Mission Critical은 99.999% 요구
- Business Critical은 99.9% ~ 99.99% 요구
MTBF를 이용한 가용성 계산
실패가 발생하는 했을 때, 의미가 있는 시간
- 가용성 = MTBF / (MTBF + MTTR) * 100
ex.) 만약 특정 시스템이 1만 시간동안 오류없이 동작하다 오류 발생 후 복구하는데 2시간이 소요된다면
- 가용성 = 10000 / (10000 + 2) * 100
결론
가용성을 높이기 위해서는 신뢰성이 높은 하드웨어와 소프트웨어를 구매할 것.
내결함성(Fault Tolerance)
- 오류에 대한 관용성
- 시스템을 구성하는 하드웨어나 소프트웨어에 오류가 발생하도 지속적으로 서비스를 제공할 수 있는 능력
시스템 하드웨어의 내결함성 기술
- 하드디스크 : RAID 1, 5
- 네트워크 카드 : Dual NIC or Network Teaming
- 램 : RAID Memory
- 전원 공급 장치 : UPS
시스템 소프트웨어의 내결함성 기술
- 운영체제의 오류 : 서버 클러스터 (웹 서버를 여러개를 두는 것)
가용성 옵션
단일 호스트(물리적 서버)에서의 Compute Service 수행시의 문제
- 물리적엔 렉에 의해서 공유되고 있기때문에 하나의 서버의 물리적 문제 발생 시, 다른 서버또한 지속적인 운영이 불가능 함.
따라서 나누어서 실행하게 되면 지속적인 서비스를 제공 가능.
가용성 집합(Availabilty Set)
-
한 렉의 서버들이 공유하고 있는 공용장치(팬, 냉각장치, 파워 등)이 문제가 생겼을 때 서버가 끊기지않도록 이를 대비해야 함.
-
대비하기 위해서 가용성 집합에 포함된 가상머신은 업데이트 도메인 및 장애 도메인에 할당 됨.
-
가용성 집합 내에 최대 100대의 가상 머신 가능
-
가용성 집합은 2개의 개념
-
Fault Domain - 오류에서 VM을 격리
Azure 데이터 센터 내의 여러 하드웨어에서 오류 발생 시 워크로드를 물리적으로 분리 -
Update Domain - 호스트 업데이트로부터 vm을 격리
기존 동작중인 서비스를 업데이트동안 다른 Update Domain에서 작동하도록 함으로써, 업데이트를 안전하고, 자유롭게 함.
-
가용 영역
- Azure 리전 내에서 물리적으로 위치를 구분
- 가용성 세트를 한단계 끌어올린 요소
- 독립적인 전원, 냉각 및 네트워크 기능을 갖춘 하나 이상의 데이터 센터를 포함
- 격리와 경계 역할을 수행
- 한 가용영역이 다운되면 다른 가용영역이 계속 작동
- 고 가용성을 사용자가 관리함
고가용성 구현
로드 밸런스를 통해서 기존 서비스를 제공하고 있던 서버에서 고장이 발생하게되면 다른 영역이나, 지역에 있는 적절한 서버를 선택하여 정상적으로 동작하도록 함. (클라이언트는 지속적인 서비스 이용 가능)
재해 복구(Disaster Recovery)구현
리전간 복제를 구현하여 한쪽의 리전에 문제가 생겼을 때, 반대쪽 복제된 리전을 사용하여 재해를 복구하는 것.
- Traffic Manager가 이를 관리한다.
가용성 옵션에 따른 Azure의 토폴로지 구성 정리
리소스 그룹
- 동일한 수명 주기를 갖는 리소스들의 묶음
- 리소스는 리소스 그룹으로 이동할 수 있음.
- 리소스는 반드시, 리소스 그룹에 소속되어 있어야함.
- 역할기반(RBAC)를 사용하여 리소스나 그룹별 레벨의 보안 유지 가능.
- 그림과 같이 연관성 있는 것들끼리 리소스를 묶을 수 있고, 독립적인 리소스 그룹으로 묶을 수도 있음.
리소스 매니저
- Azure를 관리하는 계층
- 리소스 또는 리소스 그룹을 생성, 구성, 관리, 삭제하고 리소스를 조직화 하고 자동화 함.
- Azure AD를 통한 접근 제어.
- Azure 포털, CLI, PowerShell, API등을 통해서도 접근 및 관리가 가능함.
