클라우드 컴퓨팅 [수업정리] - ⑫

아현·2021년 11월 25일
클라우드컴퓨팅
1

Cloud Computing

목록 보기
14/19
post-thumbnail

심화 클라우드 아키텍처


1. 하이퍼바이저 클러스터링 아키텍처


  • 하이퍼바이저는 여러 가상 서버를 만들고 호스팅하는 책임이 있습니다.

  • 이러한 종속성으로 인해 하이퍼바이저에 영향을 미치는 모든 장애 조건은 가상 서버에 파급효과를 미칠 수 있습니다.


  • 하이퍼바이저 클러스터링 아키텍처는 여러 물리 서버에 하이퍼바이저의 고가용성 클러스터를 설정합니다.

    • 지정된 하이퍼바이저 또는 기본 물리 서버를 사용할 수 없게 되면 호스팅된 가상 서버를 다른 물리 서버 또는 하이퍼바이저로 이동하여 런타임 작업을 유지 관리할 수 있습니다.


  • 하이퍼바이저 클러스터는 중앙 VIM을 통해 제어되며, 중앙 VIM은 하이퍼바이저가 작동하고 실행 중인지 확인하기 위해 하이퍼바이저에 정기적인 하트비트 메시지를 보냅니다.

    • 하트비트 메시지가 수신 확인되지 않으면, VIM이 실시간 VM 이관 프로그램을 시작해 장애가 발생했을 수 있는 가상 서버를 신규 호스트로 동적으로 이동시킨다.

  • 실시간 VM 이관(Live VM Migration)이란 가상 서버나 가상 서버 인스턴스를 런타임에 재배치할 수 있는 시스템이다.


  • VIM은 하이퍼바이저들을 관리하며, 각각의 하이퍼바이저는 하나의 스토리지 장치를 공유하는 것으로 가정한다.

    • 이관 시 데이터는 한 곳에 있기에, 더욱 손쉽게 하기 위해서


  • 가용 용량을 비교하여 이관할 물리 서버를 선택해야한다.



2. 부하 분산 가상 서버 인스턴스 아키텍처 (LOAD BALANCED VIRTUAL SERVER INSTANCES ARCHITECTURE)


  • 물리 서버는 인접한 물리 서버보다 더 많은 가상 서버를 호스팅하거나 더 큰 작업 부하를 쉽게 받을 수 있습니다.

  • 부하 분산 가상 서버 인스턴스 아키텍처는 사용 가능한 물리 서버 호스트에 처리를 분산하기 전에 동적으로 가상 서버 인스턴스와 관련 작업 부하를 계산하는 용량 관제 시스템을 구축합니다.

  • 용량 관제 시스템(capacity watchdog system)은 용량 관제 클라우드 사용량 모니터, 실시간 VM 이관 프로그램 및 용량 계획 도구로 구성됩니다.

    • 용량 관제 모니터는 물리적 및 가상 서버 사용량을 추적하고 가상 서버 용량 요구 사항에 대해 물리적 서버 컴퓨팅 용량을 동적으로 계산하는 책임이 있는 용량 계획자에게 중요한 변동을 보고합니다.

    • 용량 계획 도구가 작업 부하를 분산하기 위해 가상 서버를 다른 호스트로 이동하기로 결정하면 실시간 VM 이관 프로그램에 가상 서버를 이동하라는 신호를 보냅니다.

이외에도 이러한 아키텍처를 구성하는 데 다음과 같은 메커니즘들이 포함될 수 있다.

  • 자동 확장 리스너: 로드 밸런싱 프로세스를 초기화하고 하이퍼바이저를 통해 가상 서버에게 오는 작업 부하를 동적을 감시하는 데 사용될 것이다.
  • 로드 밸런서: 하이퍼바이저 간 가상 서버들의 작업 부하를 분배한다.
  • 논리 네트워크 경계: 재배치된 가상 서버의 대상이 SLA와 개인 정보 보호 규정을 준수하는지 확인한다.
  • 자원복제: 가상 서버 인스턴스의 복제는 로드 밸런싱의 기능의 일부로 필요할 수 있다.



3. 무중단 서비스 재배치 아키텍처


  • 다음과 같은 여러 가지 이유로 클라우드 서비스를 사용할 수 없게 될 수 있습니다.

    1. 처리 용량을 초과하는 런타임 사용 요구 사항

    2. 일시적인 다운 타임을 필수적으로 요구하는 유지 보수 업데이트 작업

    3. 신규 물리 서버 호스트로의 영구적인 이관

  • 클라우드 서비스를 사용할 수 없게 되면 일반적으로 클라우드 서비스 소비자 요청이 거부되어 잠재적으로 예외 조건이 발생할 수 있습니다.

  • 무중단 서비스 재배치 아키텍처는 사전 정의된 이벤트가 발생 시 자동으로 런타임에 클라우드 서비스 구현체를 복제 또는 이관해 다운 타임을 방지하는 시스템을 구축합니다.


  • 가상 서버 이관은 가상 서버의 디스크 위치 및 구성에 따라 다음 두 가지 방법 중 하나로 수행될 수 있습니다.

    • 가상 서버 디스크가 소스 호스트에 연결된 로컬 스토리지 장치 또는 비공유 원격 저장 장치에 저장된 경우 가상 서버 디스크의 복제본이 목적지 호스트상에 생성됩니다. 복제본이 생성된 후 두 가상 서버 인스턴스가 동기화되고 가상 서버 파일이 기존 호스트에서 제거됩니다.

    • 가상 서버의 파일이 기존 호스트와 목적지 호스트 간에 공유된 원격 스토리지 장치에 저장되어 있는 경우 가상 서버 디스크를 복사할 필요가 없습니다. 가상 서버의 소유권이 단순히 기존에서 목적지 물리 서버 호스트로 이전되고 가상 서버의 상태는 자동으로 동기화됩니다.



4. 무정지 아키텍처 (ZERO DOWNTIME ARCHITECTURE)


  • 물리 서버는 자연스럽게 호스트하는 가상 서버에 대한 단일 실패 지점으로 작동(single point of failre)합니다. 결과적으로 물리 서버에 장애가 발생하거나 손상되면 호스팅된 가상 서버의 일부(또는 전체)의 가용성이 영향을 받을 수 있습니다.

    • 이는 클라우드 제공 업체가 클라우드 소비자에게 무정지 서비스를 보장하는 일을 어렵게 만든다.

  • 무정지 아키텍처는 원래의 물리적 서버 호스트에 장애가 발생하는 경우 가상 서버를 다른 물리적 서버 호스트로 동적으로 이동할 수 있는 정교한 장애 조치 시스템을 구축합니다.



5. 클라우드 밸런싱 아키텍처


  • 클라우드 밸런싱 아키텍처는 IT 자원이 여러 클라우드에서 로드 밸런싱될 수 있는 특수 아키텍처 모델을 설정합니다.

  • 클라우드 서비스 소비자 요청의 클라우드 간 밸런싱(cross-cloud balancing)은 다음을 도울 수 있습니다.

    • IT 자원의 성능 및 확장성 향상

    • IT 자원의 가용성 및 신뢰성 향상

    • 부하 분산과 및 IT 자원 최적화 향상



6. 자원 예약 아키텍처


  • IT 자원이 공유 사용을 위해 설계된 방식과 사용 가능한 용량 수준에 따라 동시 사용자 접근이 자원 제약 조건이라 불리는 런타임 예외 상황에 도달할 수 있습니다.

    • 자원 제약 조건이란 할당된 공유 IT 자원의 용량이 클라우드 소비자들이 요청한 처리 요구 사항을 모두 수용할 수 없는 경우 발생하는 조건이다.

      • 결과적으로 하나 이상의 클라우드 소비자들이 성능 저하를 경험하거나 모두 처리 거부 상태가 될 수 있다.

      • 특정 IT 자원이 다른 클라우드 서비스 소비자에 의해 동시에 접근될 경우 기타 다른 종류의 런타임 충돌이 일어날 수 있다.

  • 예를 들어 중첩 및 형제 자원 풀은 하나의 풀이 임시로 다른 IT 자원을 해당 자원을 빌려 쓰고 있는 클라우드 서비스 소비자가 오랫동안 점유해서 반납하지 않는 경우 발생할 수 있다. 이는 불가피하게 자원 제약의 발생으로 이어질 수 있다.

    • 자원 예약 아키텍처는 다음 항목들 중 하나가 특정 클라우드 소비자에 대해 독점적으로 설정되도록 하는 시스템을 구축한다.

      • 단일 IT 자원

      • IT 자원의 일부

      • 여러 IT 자원들

    • 이는 클라우드 소비자들이 서로 앞서 언급한 자원 제약 조건 및 자원 임대 상황에 빠지는 것을 방지해 준다.




7. 동적 장애 감지 및 복구 아키텍처


  • 동적 장애 감지 및 복구 아키텍처는 사전 정의된 광범위한 장애 시나리오를 모니터링하고 대응할 수 있는 탄력적인 감시 시스템을 구축합니다.

  • 이 시스템은 자동으로 해결할 수 없는 장애 조건을 알리고 에스컬레이션합니다.

    • 에스컬레이션(escalation)

      • functional escalation : 자동화된 단계가 실패를 하면 관리자에게 연락하고, 관리자도 실패하면 더 높은 지원선에 연락을 하는 것

      • hierarchical escalation: 위험이 매우 클 시, 가장 높은 상급자에게 바로 연락하는 것


  • 지능형 관제 모니터라고 하는 특수 클라우드 사용량 모니터에 의존하여 IT 자원을 능동적으로 추적하고 사전 정의된 이벤트에 대응하여 사전 정의된 조치를 취합니다.

  • 탄력적인 감시 시스템은 다음 5가지 핵심 기능을 수행합니다.

    • 관찰 및 감시

    • 이벤트 발생 시 대응 행위 결정

    • 이벤트 발생 시 대응 행위 수행

    • 보고

    • 에스컬레이션



8. 베어 메탈 프로비저닝 아키텍처


  • 원격 관리 소프트웨어는 일반적으로 대부분의 물리 서버의 운영 체제에 고유하기 때문에 원격으로 서버를 프로비저닝하는 것이 일반적입니다. 그러나 운영 체제나 기타 소프트웨어가 사전 설치된 물리 서버인 베어 메탈 서버에서는 기존 원격 관리 프로그램에 접근할 수 없습니다.

    베어 메탈 서버(bare-metal server): 소프트웨어가 하나도 설치되어 있지 않은 서버

  • 베어 메탈 프로비저닝 아키텍처는 전체 운영 체제를 원격으로 식별 및 프로비저닝하는 데 사용되는 특화된 서비스 에이전트를 통해 이 기능을 사용하는 시스템을 구축합니다.

    • 운영체제 등을 설치해야 원격으로 접속이 가능하고, 관리할 수 있기 때문

  • 베어 메탈 프로비저닝 시스템은 다음 구성 요소를 사용합니다.

    • 식별 에이전트 – 클라우드 소비자에게 할당할 가용 물리 서버를 검색하고 찾는 모니터링 에이전트의 한 종류

    • 배치 에이전트 – 물리 서버의 메모리에 설치되어 베어 메탈 프로비저닝 배포 시스템의 클라이언트로 배치되는 관리 에이전트입니다.

      • 원격 관리 시스템 프로그램

    • 식별 영역 – 네트워크를 검색하고 연결할 수 있는 물리 서버를 찾는 소프트웨어 구성 요소입니다.

      • 식별 에이전트의 일부

    • 관리 로더 – 물리 서버에 연결하고 클라우드 소비자를 위한 관리 옵션을 로드하는 구성 요소입니다.

    • 배치 컴포넌트 – 선택한 물리 서버에 운영 체제 설치를 담당하는 구성 요소입니다.



9. 신속한 프로비저닝 아키텍처


  • 기존 프로비저닝 프로세스에는 사전 패키지된 사양 또는 사용자 지정 클라이언트 요청에 따라 요청된 IT 자원을 준비하는 관리자 및 기술 전문가가 전통적으로 수동으로 완료하는 여러 작업이 포함될 수 있습니다.

    • 더 많은 고객에게 서비스를 제공하고 평균적인 고객이 더 많은 IT 자원을 요청하는 클라우드 환경에서는 수동 프로비저닝 프로세스가 부적절하며 인적 오류 및 비효율적인 응답 시간으로 인해 불합리한 위험이 발생할 수도 있습니다.

  • 신속한 프로비저닝 아키텍처는 개별적으로 또는 집합적으로 광범위한 IT 자원의 프로비저닝을 자동화하는 시스템을 구축합니다. 신속한 IT 자원 프로비저닝을 위한 기본 기술 아키텍처는 정교하고 복잡할 수 있으며 자동화된 프로비저닝 프로그램, 신속한 프로비저닝 엔진, 온디맨드 프로비저닝용 스크립트 및 템플릿으로 구성된 시스템을 활용할 수 있습니다.


  • 다음과 같은 IT 자원 프로비저닝의 다양한 측면을 조정하고 자동화하는 데 사용할 수 있는 많은 추가 아키텍처가 있습니다.

    1. 서버 템플릿

      • 신규 가상 서버의 인스턴스화를 자동화하는 데 사용되는 가상 이미지 파일의 템플릿

    2. 서버 이미지

      • 이 이미지들은 가상 서버 템플릿과 유사하지만 물리 서버를 프로비저닝라는 데 사용된다.

    3. 애플리케이션 패키지

      • 자동 배치용으로 패키징된 애플리케이션 및 기타 소프트에어의 모음

    4. 애플리케이션 패키저

      • 애플리케이션 패키지를 생성하는 데 사용되는 소프트웨어

    5. 맞춤 스크립트

      • 지능형 자동화 엔진의 일부로 관리 작업을 자동화하는 스크립트

    6. 시퀀스 관리자

      • 자동화 프로비저닝 작업의 순서를 조직화하는 프로그램

    7. 시퀀스 이력 기록 장치(Logger)

      • 자동화 프로비저닝 작업 순서의 실행 이력을 기록하는 컴포넌트

    8. 운영체제 베이스라인

      • 운영체제가 설치된 후에 이를 신속하게 활용 가능하도록 준비하기 위해 적용되는 구성 템플릿

    9. 애플리케이션 구성 베이스라인

      • 신규 애플리케이션 사용 준비에 필요한 설정 및 환경 변수가 포함된 구성 템플릿

    10. 배치 데이터 스토어

      • 가상 이미지, 템플릿, 스크립트, 베이스라인 구성 및 기타 관련 데이터를 저장하는 저장소



  • 다음의 단계별 설명은 이전에 나열된 여러 시스템 구성 요소를 포함해 신속한 프로비저닝 엔진의 내부 원리를 설명한다.

    1. 클라우드 소비자가 셀프 서비스 포털을 통해 신규 서버를 요청합니다.

    2. 시퀀스 관리자는 운영체제 준비를 위해 배치 엔진에 요청을 전달합니다.

    운영체제

    1. 배포 엔진은 가상 서버에 대한 요청인 경우 프로비저닝을 위해 가상 서버 템플릿을 사용합니다. 그렇지 않으면 배치 엔진은 물리 서버를 프로비저닝하도록 요청을 보냅니다.

    2. 요청된 운영체제용으로 제작된 사전 정의된 이미지가 운영체제의 프로비저닝에 사용됩니다. 그렇지 않으면 운영체제를 설치하기 위해 정규 배치 프로세스를 실행합니다.

    3. 배치 엔진은 운영체제가 준비되면 시퀀스 관리자에게 알립니다.

    4. 시퀀스 관리자는 저장을 위해 시퀀스 이력 기록 장치에 로그를 업데이트하고 보냅니다.

    운영체제 베이스라인

    1. 시퀀스 관리자는 배치 엔진이 운영체제 베이스라인을 프로비저닝된 운영 체제에 적용하도록 요청합니다.

    2. 배치 엔진은 요청된 운영체제 베이스라인을 적용합니다.

    3. 배치 엔진은 운영체제 베이스라인이 적용되었음을 시퀀스 관리자에게 알립니다.

    4. 시퀀스 관리자는 완료된 단계의 로그를 업데이트하고 저장을 위해 시퀀스 이력 기록 장치로 보냅니다.

    애플리케이션

    1. 시퀀스 관리자는 배치 엔진에 응용 프로그램을 설치하도록 요청합니다.

    2. 배치 엔진이 프로비저닝된 서버에 애플리케이션을 배포합니다.

    3. 배치 엔진은 응용 프로그램이 설치되었음을 시퀀스 관리자에게 알립니다.

    4. 시퀀스 관리자는 완료된 단계의 로그를 업데이트하고 저장을 위해 시퀀스 이력 기록 장치로 보냅니다.

    애플리케이션 베이스라인

    1. 시퀀스 관리자는 배치 엔진이 애플리케이션의 구성 베이스라인을 적용하도록 요청합니다.

    2. 배치 엔진이 구성 베이스라인을 적용합니다.

    3. 배치 엔진은 구성 베이스라인이 적용되었음을 시퀀스 관리자에게 알립니다.

    4. 시퀀스 관리자는 완료된 단계의 로그를 업데이트하고 저장을 위해 시퀀스 이력 기록 장치로 보냅니다.



10. 스토리지 작업 부하 관리 아키텍처


  • 과도하게 사용되는 클라우드 스토리지 장치는 스토리지 컨트롤러의 작업 부하를 증가시키고 다양한 성능 문제를 일으킬 수 있습니다. 반대로 활용도가 낮은 클라우드 스토리지 장치는 잠재적인 처리 및 저장 용량 손실로 인해 낭비가 됩니다.

  • 스토리지 작업 부하 관리 아키텍처는 사용 가능한 클라우드 스토리지 장치 간에 LUN이 균등하게 분배되도록 하며, 동시에 스토리지 용량 시스템이 구축돼 런타임 작업 부하가 여러 LUN 간에 균등하게 분배되도록 한다.

    • LUN 이관이란 하나의 스토리지 장치에서 다른 스토리지 장치로 LUN을 중단 없이, 또 클라우드 소비자에게는 투명하게 이관하는 데 사용되는 특화된 스토리지 프로그램이다.

  • 클라우드 스토리지 장치를 하나의 그룹으로 묶으면 LUN 데이터가 사용할 수 있는 스토리지 호스트에 균등하게 분배될 수 있게 된다.

    • 스토리지 관리 시스템이 구성되고 자동 확장 리스너가 그룹화된 클라우드 스토리지 장치들 간 배분되는 런타임 작업 부하를 감시 및 균등하게 하는 역할을 수행한다.

    • 스토리지 용량 시스템은 LUN의 접근 빈도가 낮거나 사용하지 않는 상태인 기간에 운영중인 스토리지 장치를 전원 절약 모들 유지할 수 있다.



profile
아현
For the sake of someone who studies computer science
이전 포스트

클라우드 컴퓨팅 [수업정리] - ⑪

다음 포스트

클라우드 컴퓨팅 [수업정리] - ⑬

0개의 댓글