F5와 IBM을 통한 엔터프라이즈 클라우드 구축

일부 추정에 따르면, 기업용 클라우드(프라이빗 클라우드라고도 함)가 퍼블릭 클라우드보다 더 빠른 속도로 도입되고 있습니다. 기업 컨설팅 회사인 액센추어(Accenture)는 2011년 말까지 프라이빗 클라우드 기업의 보급률이 77%에 달할 것으로 추산합니다.¹ 이처럼 민첩한 현장 인프라를 구축하려는 신속한 움직임은 대규모 및 소규모 기업 IT 부서가 인프라와 데이터를 모두 내부적으로 제어하고 관리해야 할 필요성에서 비롯된 것입니다.

클라우드 인프라를 도입하기로 결정하면 내부/사설과 외부/공공 중에서 선택하는 것은 비용, 위험, 가치에 대한 분석에 달려 있습니다. 퍼블릭 클라우드는 일반적으로 유연한 접근 방식과 가장 큰 비용 절감 효과를 제공하지만 보안, 서비스 수준 계약(SLA), 가용성, 관리와 관련된 위험을 수반합니다. IT는 낮은 진입 비용으로 거의 무한한 규모를 활용할 수 있지만, 통제력이 희생됩니다. 기존의 온사이트 또는 호스팅 데이터 센터에서 외부 퍼블릭 클라우드로 이전하는 것은 기본적으로 전체 데이터 센터를 다른 사람의 손에 넘기는 것과 같습니다.

기업용 클라우드를 사용하면 IT 부서는 필요한 수준의 제어를 확보하고 퍼블릭 클라우드와 관련된 위험을 피할 수 있습니다. 그러나 프라이빗 클라우드는 구축 비용이 더 많이 들고 직원에게 더 많은 지식과 전문 지식이 필요하며 온프레미스 데이터 센터의 복잡성 수준이 더 높아집니다. 기업 클라우드 인프라는 필요에 따라 확장이 가능하며 동적 프로비저닝과 민첩성을 제공하지만, 이러한 확장성과 제어에는 종종 진입 비용이 더 많이 듭니다.

F5 Networks®와 IBM은 복잡성과 관련된 많은 과제를 완화하는 엔터프라이즈 클라우드를 위한 참조 아키텍처를 함께 설계했습니다. 이 솔루션은 퍼블릭 클라우드의 아키텍처와 규모 구성 요소 중 많은 부분을 온프레미스로 가져와서 내부적이고 단편적인 시스템을 구축하는 데 드는 비용을 크게 줄여줍니다. F5와 IBM은 필수 구성 요소를 미리 정의하고 해당 구성 요소가 함께 작동하는 방식을 설명함으로써 완벽하고 역동적이며 민첩한 엔터프라이즈 클라우드 인프라를 구축했습니다.

온디맨드 프로비저닝 시스템의 가장 중요한 요소는 이벤트에 따라 결정을 내리고 조치를 취할 수 있는 기능입니다. 시스템 어딘가에서 이벤트가 발생하면 구성 요소(메시지 버스를 구독하거나 API 호출을 통해 직접 요청한 구성 요소)에서 수집한 알림이나 메시지가 생성되고, 구성 요소는 해당 메시지에 대해 작업을 수행합니다. 워크플로는 구성 요소가 시스템 메시지에 따라 작동하는 프로세스와 순서입니다.

기업 클라우드에서 워크플로는 일반적으로 리소스를 요청하거나 포기하는 프로비저닝 구성 요소와 리소스 할당을 관리하는 데 필요한 단계로 구분됩니다. 가상 머신(VM)에 추가 CPU 리소스가 필요하면 해당 CPU 리소스를 어디에서 가져올지 결정하고, 새 VM을 시작하고, IP 주소를 할당하는 등의 워크플로가 시작됩니다.

F5와 IBM 엔터프라이즈 클라우드 아키텍처는 두 가지 중요한 원칙을 기반으로 합니다.

1. 이벤트 알림 메시지를 전달하는 데 사용되는 중앙 집중식 메시지 버스가 있으며, 이벤트에 따라 작동해야 하는 모든 구성 요소는 버스에 연결되어 있습니다.

이 두 가지 원칙을 넘어 F5와 IBM 참조 아키텍처는 매우 유연해서 기존 데이터 센터나 클라우드 아키텍처에 적용할 수 있습니다. 예를 들어 VM 배포를 관리하는 오케스트레이션 엔진이 이미 있는 경우 이 참조 아키텍처를 조정하여 기존 엔진을 사용할 수 있습니다. 기업용 클라우드 구축과 관련된 오해 중 하나는 전체 인프라를 교체해야 한다는 것입니다. F5와 IBM 솔루션은 가능한 모든 단계에서 기존 구성 요소와 통합되도록 만들어졌습니다.

어떤 구성 요소가 이미 존재하고 어떤 구성 요소가 새로운지 여부에 관계없이 엔터프라이즈 클라우드 워크플로는 특정 작업을 수행하는 특정 구성 요소로 구성됩니다. 전체 클라우드 시스템은 이러한 개별 구성 요소로 이루어져 있으며, 이러한 구성 요소가 함께 작동하여 완전한 클라우드 인프라를 제공합니다. 해당 인프라는 구성 요소 워크플로를 통해 구동되고 제어됩니다. 구성 요소 워크플로는 클라우드 이벤트를 관리하는 조정된 작업입니다.

메시지 버스는 영향을 받는 각 구성 요소에 대한 이벤트 및 경고에 따른 메시지를 전달하는 시스템입니다. 이벤트가 메시지를 트리거하면, 해당 메시지는 메시지 버스를 통해 특정 구성 요소로 전송됩니다. 해당 구성 요소에는 해당 메시지를 어떻게 처리할지에 대한 규칙이 있습니다. 메시지 버스는 또한 특정 구성 요소에 대한 규칙에 따라 메시지를 정규화하는 역할을 합니다.

F5 및 IBM 참조 클라우드 아키텍처는 IBM Tivoli Netcool OMNIbus 솔루션을 중앙 메시지 버스로 사용하지만, 모든 엔터프라이즈 메시지 버스를 사용하여 시스템 전체에 이벤트 알림을 전달할 수 있습니다.

오케스트레이터는 엔터프라이즈 클라우드의 두뇌로 간주될 수 있습니다. 버스를 통해 수신된 메시지를 기반으로 대부분의 매크로 프로비저닝 결정을 내리는 구성 요소입니다. 오케스트레이터는 클라우드 아키텍처에서 "새로운 가상 머신 프로비저닝" 워크플로 시작과 같은 주요 이벤트 및 워크플로를 시작합니다. 오케스트레이터는 또한 각 워크플로에 필요한 데이터를 가져와 해당 구성 요소에 제공하는 역할을 담당합니다. 예를 들어, 오케스트레이터는 새 VM을 프로비저닝하는 데 필요한 IP 주소 정보를 제공합니다.

참조 아키텍처의 경우, 오케스트레이터는 버스에서 온 메시지에 따라 작동하고 워크플로 이벤트를 시작하는 일련의 해석된 스크립트를 사용하여 생성됩니다. IBM Tivoli Intelligent Orchestrator, HP Operations Orchestration, VMware vCenter Orchestrator 등 모든 유형의 오케스트레이터를 사용할 수 있습니다.

클라우드 컨트롤러는 프로비저닝 프로세스를 시작하는 데 필요한 예비 데이터를 수집하고 집계하는 프런트엔드 시스템입니다. 처음에 이 정보는 관리자가 생성 프로세스의 일부로 제공하며 프로비저닝에 사용되는 각 유형의 워크플로에만 적용됩니다. 예를 들어, 클라우드 컨트롤러는 VM 위치, 애플리케이션 클래스(웹 서버, 데이터베이스 서버, 메일 서버 등), 최소 리소스 요구 사항을 포함한 정보를 수집합니다.

자동화된 프로비저닝 이벤트 중에 이러한 예비 데이터가 시스템에 이미 저장되면 오케스트레이터는 기존 정보를 요청하고 추출하여 프로비저닝 워크플로를 시딩합니다. 클라우드 컨트롤러의 예로는 Eucalyptus Cloud Controller, VMware vCloud Director, Amazon EC2 등이 있습니다. 향후 성장과 다른 클라우드 플랫폼으로의 확장성을 위해 표준 클라우드 API 세트와 통합하거나 통신할 수 있는 클라우드 컨트롤러를 선택하는 것이 좋습니다. 이를 통해 클라우드 컨트롤러는 엔터프라이즈 클라우드 플랫폼을 재설계하지 않고도 퍼블릭 또는 하이브리드 클라우드 공급자로 확장할 수 있습니다.

클러스터 컨트롤러는 프로비저닝되는 가상 머신과 VM을 실행하는 데 필요한 스토리지와 메타데이터를 관리하는 엔터프라이즈 클라우드의 구성 요소입니다. VM 실행 환경으로서 클러스터 컨트롤러에는 가상 플랫폼 하이퍼바이저가 포함되며, 더 큰 규모의 하이퍼바이저 관리 환경도 포함될 수 있습니다. 예를 들어, 클러스터 컨트롤러는 VMware ESXi와 같은 베어본 하이퍼바이저일 수도 있고, VMware vSphere 또는 VMware vCloud와 같은 대규모 분산 하이퍼바이저 시스템 모음일 수도 있습니다.

상태 및 상태 모니터링은 모든 엔터프라이즈 애플리케이션 배포에 필수적인 요소입니다. 모니터링은 또한 프로비저닝 시스템에 대한 상태 업데이트를 제공합니다. 예를 들어, 가상 머신이 작동 중이고 네트워크에서 연결에 응답하는 경우입니다. 시스템을 지속적으로 모니터링하면 실시간 알림을 받을 수 있으며, 이는 궁극적으로 새로운 워크플로에 반영되고 프로비저닝 결정에 영향을 미칩니다. 애플리케이션과 네트워크 상태를 모니터링할 수 있는 모든 구성 요소는 엔터프라이즈 클라우드 배포에 사용할 수 있지만, IBM Tivoli Monitoring 소프트웨어는 F5 및 IBM 참조 아키텍처에 사용됩니다.

도메인 이름 시스템(DNS)은 F5 및 IBM 엔터프라이즈 클라우드 참조 아키텍처에서 중요한 역할을 합니다. IPv4 및 IPv6에 대한 IP 및 도메인 이름 정보뿐만 아니라 클라우드 컨트롤러가 수집한 정보 및 고유한 머신 식별 정보 등의 시스템 메타데이터를 저장하는 역할을 합니다. 이 참조 아키텍처의 경우 DNS를 메타데이터의 저장 위치로 선택했습니다. DNS는 대부분 네트워크에 이미 존재하는 표준 기반 시스템이고, 모든 클라우드 구성 요소에서 사용할 수 있으며, 인프라에 추가적인 데이터베이스 유형 저장소를 추가할 필요가 없기 때문입니다. IT 부서에서 관리하고 추가 영역과 영역 파일을 추가할 수 있는 모든 DNS 솔루션을 사용할 수 있습니다.

F5 및 IBM 참조 아키텍처의 경우, 클러스터 컨트롤러는 로컬 스토리지에서 가상 머신을 실행합니다. 하지만 실행 중이 아닐 때는 VM 가상 디스크가 가상화된 스토리지에 있습니다. 워크플로 프로비저닝 이벤트 중에 클러스터 컨트롤러는 NFS(네트워크 파일 시스템)를 통해 가상 스토리지 장치에서 가상 디스크를 요청합니다.

엔터프라이즈 클라우드의 마지막 구성 요소는 애플리케이션 전송 컨트롤러(로드 밸런서라고도 함)로, F5 및 IBM 참조 아키텍처에서는 F5® BIG-IP® Local Traffic Manager™(LTM)입니다. BIG-IP LTM은 가상 머신에서 나오는 애플리케이션 데이터의 연결, 서비스, 전송을 관리합니다. 궁극적으로 BIG-IP LTM은 워크플로 프로비저닝 이벤트에 따라 작동하는 시스템의 마지막 부분입니다.

F5와 IBM 엔터프라이즈 클라우드 참조 아키텍처의 목표는 애플리케이션을 동적으로 배포하기 위한 실제 리소스 기반 플랫폼을 제공하는 것입니다. 모든 구성 요소가 제자리에 있으면 다양한 워크플로를 통해 함께 작동하여 필요에 따라 새로운 애플리케이션 서비스를 제공합니다. 기업 클라우드에 구축된 시스템을 프로비저닝하는 방법에는 수동 프로비저닝과 자동 프로비저닝 두 가지가 있습니다.

일반적으로 엔터프라이즈 클라우드의 첫 번째 워크플로는 시스템 관리자나 애플리케이션 요청자의 입력을 기반으로 하는 수동 프로세스에서 시작됩니다. 이는 워크플로가 수동이라는 것을 의미하지 않습니다. 시스템에 처음으로 정보를 입력하는 작업만이 수동입니다. 관리자로부터 데이터를 수집하면 시스템은 애플리케이션 프로비저닝을 위한 사전 정의된 자동화된 워크플로 이벤트를 시작합니다.

관리자(또는 새로운 프로비저닝 이벤트를 시작하는 담당자에 따라 애플리케이션 요청자)는 클라우드 컨트롤러 GUI를 사용하여 새 가상 머신을 시작하고 애플리케이션을 온라인 상태로 만드는 데 필요한 정보를 입력합니다. 이 정보는 일반적으로 다음과 같은 상위 수준의 인프라 데이터입니다.

• 신청 유형: Microsoft SharePoint, 웹 서버, 메일 서버, Oracle 데이터베이스 등 사용 가능한 애플리케이션 유형의 미리 정의된 목록입니다.
• 네트워크 정보: 클러스터 IP 주소, 프런트엔드 URL, 이 애플리케이션이 공개되는지 아니면 내부 전용인지 등.
• 프로비저닝 정보: 네트워크 위치(종종 "유럽-코펜하겐 데이터 센터"와 같이 물리적 데이터 센터에 연결된 지리적 참조) 및 지정된 애플리케이션 유형의 허용되는 최소 및 최대 인스턴스 수에 대한 제한과 같이 프로비저닝 시스템에 필요한 추가 정보입니다.

이 정보는 엔터프라이즈 클라우드 전체의 자동 프로비저닝을 위한 메타데이터로 사용됩니다.

관리자가 필요한 데이터를 제출하면 다음 단계는 클라우드 컨트롤러가 해당 정보를 패키지화하는 것입니다. 이 정보를 동적으로 생성된 고유 인스턴스 ID와 함께 패키지화하여 시스템 전체에서 이 인스턴스를 프로비저닝하는 데 사용합니다(예: "vm12345"). 메시지 버스를 통해 오케스트레이터에 배포합니다.

첫 번째 단계에서 제공된 모든 정보는 오케스트레이터에 전달되기 전에 메시지 버스에 의해 정규화됩니다.

동시에 클라우드 컨트롤러는 API를 통해 하이퍼바이저에 동일한 메타데이터와 고유한 인스턴스 ID를 제공하고, 필요한 애플리케이션 이미지를 배포하도록 지시합니다. 이 이벤트는 하이퍼바이저에게 클라우드 기반 스토리지에서 해당 가상 머신 디스크 이미지를 요청하도록 요청합니다. 저장 장치는 NFS를 통해 적절한 디스크 이미지를 검색하고 해당 이미지를 로컬 저장소에 복사하기 시작합니다.

오케스트레이터가 메시지 버스에서 정규화된 이벤트 정보와 메타데이터를 수신하면, 메타데이터를 모니터링 시스템과 DNS에 동시에 푸시하는 두 가지 서로 다른 워크플로를 시작합니다. 모니터링 시스템은 이 정보를 사용하여 애플리케이션에 대한 자동 모니터링 일정을 구성하고, 애플리케이션이 실행 중이라는 알림이 전송되면 모니터링을 시작합니다. 이 단계에서 오케스트레이터는 모니터링 시스템 이벤트에 대한 임계값도 정의합니다. 예를 들어, 이 가상 인스턴스의 CPU 사용률이 75%를 초과하면 모니터에 이벤트 알림을 보내도록 지시합니다.

오케스트레이터는 가상 인스턴스 메타데이터를 DNS로 푸시하고, 해당 데이터는 전체 엔터프라이즈 클라우드에서 사용할 수 있도록 저장됩니다. 오케스트레이터는 적절한 DNS 영역 형식으로 메타데이터를 제출할 책임이 있으므로 인스턴스 ID를 기반으로 도메인 이름을 구성하고, IPv4 및 IPv6 DNS 레코드를 생성하고, 클라우드 컨트롤러에서 인스턴스 정보를 추가하고, 새로운 인스턴스 정보를 적절한 영역에 추가해야 합니다. 예를 들어, 오케스트레이터는 고유한 인스턴스 ID를 가져와서 "vm12345.vm.cloud.example.com"에 대한 DNS 항목을 만들고 이를 기존 example.com 영역에 추가합니다.

엔터프라이즈 클라우드 전체에 메타데이터를 배포하는 마지막 단계는 호스트 이름, IP 주소, 애플리케이션 유형(또는 BIG-IP LTM의 풀) 및 모니터링 정보와 같은 새로운 인스턴스 정보로 BIG-IP LTM 애플리케이션 전송 컨트롤러를 채우는 것입니다.

2단계에서 클라우드 컨트롤러는 하이퍼바이저에게 새로 프로비저닝된 인스턴스와 연결된 가상 머신을 시작하도록 지시했습니다. 해당 VM이 예상대로 작동하고 연결 가능한 경우, 메시지 버스의 이벤트 알림을 통해 오케스트레이터에 알립니다. 오케스트레이터는 해당 이벤트 알림을 받고 BIG-IP LTM이 풀에서 새 VM을 사용 가능하다고 표시하고 부하 분산 방법에 따라 가상 인스턴스에 새 연결을 전송하고 배포하도록 지시하는 워크플로를 시작합니다. BIG-IP LTM은 이전에 구성된 애플리케이션 모니터를 애플리케이션 풀에 할당하여 새 인스턴스의 모니터링을 시작합니다.

새로 실행 중인 VM의 이벤트 알림은 오케스트레이터에게 전체 엔터프라이즈 클라우드 모니터링 시스템에 가상 인스턴스 모니터링을 시작하도록 알리는 메시지도 보냅니다. 이 시점에서 새로 프로비저닝된 가상 인스턴스는 엔터프라이즈 클라우드에서 실행 중이며 애플리케이션 서비스 요청을 처리하고 있습니다. 이는 엔터프라이즈 클라우드에 속하는 모든 서비스의 정상적인 작동 모드입니다.

수동 프로비저닝은 엔터프라이즈 클라우드 내에서 서비스를 프로비저닝하는 첫 번째 워크플로 단계이지만 가장 빈번한 프로비저닝 형태는 아닙니다. 원활하게 실행되는 시스템에서는 기업 클라우드가 보다 역동적이고 유동적인 자체 모니터링 시스템으로 전환되고, 필요에 따라 수요에 따라 새로운 서비스를 자체적으로 제공합니다. 이러한 민첩한 셀프 프로비저닝은 모든 클라우드 플랫폼의 핵심이며, 실시간 이벤트를 모니터링하고 대응하기 위한 추가적인 자동화된 프로비저닝 이벤트 및 워크플로가 필요합니다.

자동 프로비저닝 시스템의 첫 번째 단계는 모니터링입니다. 즉, 시스템 전체에서 이벤트를 수집하고 감지하는 것입니다. 첫 번째 라운드의 수동 프로비저닝 동안 모니터링 시스템에는 이름, 위치, 모니터링 유형, 이벤트 임계값과 같은 가상 인스턴스 정보가 채워졌습니다. 이 정보는 애플리케이션과 가상 인스턴스의 가용성과 성능을 자동으로 모니터링하는 데 사용됩니다. 예를 들어, 가상 인스턴스가 사용 가능한 CPU 리소스의 75% 이상을 사용하는 이벤트가 모니터링 시스템에서 감지되면 메시지 버스에서 이벤트를 생성하여 오케스트레이터에 고갈된 리소스를 알립니다.

일반적인 자동 프로비저닝 시나리오에서 오케스트레이터는 현재 인스턴스의 리소스 부하를 줄이는 데 도움이 되는 새로운 가상 인스턴스를 만드는 역할을 담당합니다. 두 개 이상의 가상 인스턴스를 사용하여 애플리케이션 컴퓨팅 및 네트워크 부하를 분산합니다.

자동화된 프로비저닝 워크플로를 시작하려면 오케스트레이터가 구성 요소 이벤트를 수집하고, 새로운 가상 인스턴스를 프로비저닝하는 데 필요한 메타데이터를 요청해야 합니다. F5 및 IBM 참조 아키텍처에서 메타데이터는 DNS에 저장되고 원래 수동 프로비저닝 워크플로의 일부로 채워집니다. DNS는 애플리케이션 유형, 지리적 위치, 프로비저닝 임계값 등의 정보를 오케스트레이터에 반환합니다.

자동화된 프로비저닝 워크플로의 마지막 단계에서 오케스트레이터는 DNS에서 수집한 메타데이터를 메시지 버스를 통해 클라우드 컨트롤러로 푸시합니다. 기본적으로, 이 자동화된 단계는 관리자가 컴퓨터 정보를 입력하고 수동으로 프로비저닝 워크플로를 시작하는 단계를 시뮬레이션합니다. 클라우드 컨트롤러는 이 정보를 받아(수동 프로비저닝을 하는 관리자와 마찬가지로) 새로운 가상 인스턴스 프로비저닝 워크플로를 시작합니다. 이 시점부터는 위에 자세히 설명된 프로비저닝 단계와 워크플로가 새 가상 인스턴스가 작동하고 실행되며 새 연결을 수락할 때까지 반복됩니다.

일반적인 엔터프라이즈 클라우드 배포에는 수동 및 자동 프로비저닝 워크플로가 모두 포함됩니다. 새로운 서비스나 애플리케이션은 처음에 수동 워크플로를 통해 배포되므로 관리자가 서비스를 배포하는 방법과 위치를 제어할 수 있습니다. 서비스가 시작되고 실행되면 자동화된 프로비저닝 워크플로가 리소스 요구 사항과 가용성에 따라 프로비저닝을 관리합니다.

개인 기업 클라우드를 구축하기로 결정하면 복잡성이 증가하거나 운영이 불가능해질 수 있습니다. 모든 클라우드 구축의 목적은 새로운 서비스 생성의 장벽을 낮추고, 보다 민첩한 컴퓨팅 인프라를 제공하는 것입니다. 엔터프라이즈 클라우드는 이러한 민첩성을 데이터 센터에 적용하여 관리성과 제어력을 크게 향상시킵니다.

F5는 IBM과 협력하여 자동 프로비저닝이 가능한 엔터프라이즈 클라우드를 위한 참조 아키텍처를 구축했습니다. 이 아키텍처는 모듈식이고 유연하게 설계되어 필요에 따라 기존 구성 요소를 통합하고 API와 공유 메시징 인프라를 통해 전체 엔터프라이즈 클라우드를 다른 클라우드 플랫폼에 연결할 수 있습니다. 모든 사설 기업 클라우드는 완전히 동일하지는 않습니다. 그러나 F5와 IBM 아키텍처는 다양한 환경에 적응하는 동시에 모든 애플리케이션 배포 또는 데이터 센터에 민첩한 인프라의 이점을 제공합니다.

¹ 배브콕, 찰스(2011년 1월 18일). "개인 클라우드가 이륙하고 있습니다." 정보주간. 편물.