가상 애플리케이션은 고객이 설계한 엔티티로, 여기에는 엔터프라이즈 미들웨어 컴포넌트에 배치할 수 있는 산업 표준 아티팩트와 애플리케이션을 배치한 후, 애플리케이션의 런타임 작동을 제어하는 정책 세트가 포함되어 있다.
IBM® Workload Deployer 3.0(WebSphere® CloudBurst를 개명한 제품)의 주요 기능은 고객이 엔터프라이즈 애플리케이션의 로컬 뷰에 집중할 수 있게 하는 기능이며 이 기능을 이용하면 어플라이언스에서 배치될 미들웨어 컴포넌트와 이 컴포넌트를 구성하는 방법을 확인할 수 있다.
이 기사에서는 가상 애플리케이션 패턴을 빌드하는 방법, 즉 엔터프라이즈 애플리케이션의 요구사항을 평가하고 이러한 요구사항을 정의하여 Workload Deployer의 가상 애플리케이션 빌더 기능을 개발자가 사용할 수 있게 하는 방법을 설명한다.
태스크 시나리오: 가상 애플리케이션 패턴 빌드
조직에 프로덕션 상태에 있는 애플리케이션이 상당히 많이 있고, 더 많은 애플리케이션이 프로덕션 상태로 들어가고 있다고 가정한다. 일반적인 IT 포크(folk) 프로세스에서는 각 애플리케이션의 하드웨어 및 소프트웨어 요구사항과 파일 수요를 파악한 다음, 하드웨어와 소프트웨어를 설정하고 설치 및 구성하는 지루한 프로세스가 이어진다. 그 다음에는 모니터링 및 장애 복구와 로그를 수집하고 모니터하는 방법을 설정하는 단계가 온다. 마지막에는 각 애플리케이션용 사용자 정의 스크립트를 작성하여 다음 번에는 작업이 더 수월해지도록 하고 끝으로 하드웨어/소프트웨어/애플리케이션 및 스크립트 등으로 구성된 거대한 이종 콜렉션을 빌드한다.
애플리케이션에 대한 필요성을 표준화할 수 있고 프로덕션 상황에서뿐만 아니라 개발 및 테스트 상황에서도 애플리케이션 수를 신속하게 늘릴 수 있는 충분한 공간이 있다고 가정한다면 받아 들이겠는가? 이러한 상황이 바로 Workload Deployer가 중요해지는 상황이다. 일반적으로 애플리케이션에는 J2EE 애플리케이션 서버에 배치되는 코드와 관계형 데이터베이스의 데이터가 일부 포함되어 있으며 로깅, 모니터링, 장애 복구 등을 설정할 수 있는 빠르고 손쉬운 방법이 있다고 하자. 이러한 방법은 실제로 유용할까? 그렇다, 이러한 기능이 바로 Workload Deployer가 WebApp 패턴으로 제공하는 기능이다. 데이터 센터에 Workload Deployer를 배치하면 애플리케이션 배치, 모니터링 설정, 규모 조정 및 로깅 작업을 표준화된 방식으로 신속하게 수행할 수 있다.
WebApp 패턴을 기반으로 하는 가상 애플리케이션의 일반적인 아티팩트에는 다음과 같은 것들이 포함된다.
- 애플리케이션 서버에 배치하는 데 필요한 J2EE WAR(Web Application Archive)이나 J2EE EAR(Enterprise Archive)
- 데이터베이스를 초기화하는 데 필요한 데이터베이스 스키마/테이블/행을 작성할 수 있는 스크립트
- LDIF 파일(LDAP Data Interchange Format)로 된 사용자 및 그룹 목록
또는 IBM Workload Deployer 3.0의 Virtual Application Builder를 사용하여 가상 애플리케이션을 작성할 수 있다.
예를 들면, 사용자는 가상 애플리케이션을 새로 작성하고 엔터프라이즈 애플리케이션 컴포넌트와 데이터베이스를 드래그 앤 드랍하여 이들을 서로 링크한다. 또한, 코드에서 예상되는 테이블 구조를 기술하는 데이터베이스 스키마와 코드 아티팩트가 들어 있는 WAR이나 JEE 기반 EAR을 업로드한다. IBM Workload Deployer는 이 애플리케이션을 WebApp 패턴을 사용하여 최적화된 방식으로 배치할 수 있는 "가상 애플리케이션"으로 인식한다.
기존 가상 시스템의 개념과 레거시 WebSphere Cloudburst 간의 기본적인 차이점은 실행 시스템을 구성하는 하이퍼바이저에서 시작되는 가상 머신의 수를 사용자가 결정하거나 정확히 알 필요가 없다는 점이다. 이러한 책임을 정확히 어떤 애플리케이션이 어떤 가상 머신에서 실행되는지 그리고 최적의 가상 머신 수는 몇 개인지를 파악하는 데 필요한 연관 정책과, 컴포넌트와 이러한 컴포넌트 간의 링크를 조사하는 Workload Deployer에게 위임한다.
가상 시스템을 사용하는 경우에는 필요한 미들웨어 컴포넌트와 각 미들웨어 컴포넌트의 수를 선택한다. 가상 애플리케이션을 사용하는 경우에는 이점을 신경 쓰지 않아도 되므로 애플리케이션을 설계할 때 애플리케이션의 규모 조정 특성을 제어하는 정책을 단순히 지정하면 된다.
가상 애플리케이션 패턴을 빌드한다는 것은 무엇을 의미할까? 간단히 말해서 이는 IBM Workload Deployer에서 엔터프라이즈 애플리케이션의 요구사항을 평가하고 이러한 요구사항을 정의한다는 것을 의미한다. 이러한 프로세스에서 어려운 부분은 엔터프라이즈 애플리케이션의 요구사항을 이해하는 것이지만, 이해하고나면 이러한 요구사항은 Workload Deployer에서 Virtual Application Builder 도구를 사용하여 몇 번의 드래그 앤 드롭 조작만으로도 간단하게 정의할 수 있다.
이 섹션에서는 Virtual Application Builder 도구를 탐구하고 다음과 같은 내용을 조사한다.
- 가상 애플리케이션 패턴 빌드
- 컴포넌트 구성
- 컴포넌트 간에 링크 구성
Virtual Application Builder 도구는 가상 애플리케이션을 생생하게 빌드하는 데 필요한 통합 그래픽 도구이다. 이 도구는 세 가지 기본 섹션으로 구성되며, 이러한 섹션은 하나의 통합된 섹션으로 함께 작동하여 생생하게 가상 애플리케이션을 빌드할 수 있게 한다.
- Assets(또는 palette): 가상 애플리케이션을 빌드할 때 사용할 수 있는 모든 컴포넌트가 들어 있다. 컴포넌트는 로컬에서 그룹화된다. (예를 들면, Database Components 그룹에는 모든 데이터베이스 컴포넌트가 포함되어 있다.)
- Canvas: 가상 애플리케이션을 생생하게 빌드하게 되는 위치이다.
- Properties sheet: 각 컴포넌트에는 특성 시트가 있으며, 이러한 특성 시트에는 특정 컴포넌트의 특성이나 링크 또는 구성 가능한 정책이 포함되어 있다.
그림 1. Virtual Application Builder 도구 인터페이스
이제 가상 애플리케이션 패턴을 빌드하는 방법을 조사하자.
가상 애플리케이션 패턴 빌드
이제까지 Virtual Application Builder 도구의 기본적인 개념을 살펴보았으므로, 이제 가상 애플리케이션 패턴을 빌드할 차례이다. 그러나 먼저, 가상 애플리케이션이 다양한 유형의 워크로드 패턴을 빌드하는 데 필요한 일반적인 프레임워크라는 사실을 이해해야 한다. 이 기사에 있는 가상 애플리케이션 패턴 예제에는 다음과 같은 요구사항이 있다.
- 엔터프라이즈 애플리케이션을 호스트할 애플리케이션 서버에 대한 종속 항목 1개
- 데이터를 유지할 데이터베이스에 대한 종속 항목 1개
- 인증용 사용자 레지스트리에 대한 종속 항목 1개
그림 2. 가상 애플리케이션 작성 패널
샘플 엔터프라이즈 애플리케이션에는 미들웨어 요구사항이 세 가지가 있다(애플리케이션 서버, 데이터베이스 및 사용자 레지스트리). 이러한 요구사항을 만족시키려면 그림 3과 같이 팔레트에서 컴포넌트를 캔버스로 드래그 앤 드랍한다.
그림 3.드래그 앤 드랍하여 빌드
- 애플리케이션 서버 요구사항은 Application Components 하위 섹션 아래에 있는 Enterprise Application(WebSphere Application Server) 컴포넌트에 의해 만족된다.
- 데이터베이스 요구사항은 Database Components 하위 섹션 아래에 있는 Database(DB2®>) 컴포넌트에 의해 만족된다.
- 사용자 레지스트리 요구사항은 User Registry Components 하위 섹션 아래에 있는 User Registry(Tivoli Directory Server) 컴포넌트에 의해 만족된다.
- 트래픽이 VM을 드나들 수 있도록 가상 머신에서 포트를 연다. 링크를 사용하여 특별히 열지 않는 한, 모든 포트는 잠겨있다.
- 추가 특성을 정의한다.
그림 4. 컴포넌트 간에 링크 설정
이 시점에서는 가상 애플리케이션의 구조를 설정했다. 다음 단계에서는 배치를 하기 전에 각 컴포넌트와 링크의 특성을 구성한다. 각 컴포넌트와 링크에는 직접 구성할 수 있는 고유한 특성 세트(선택사항 및 필수)가 있다.
처음과 마지막에 구성해야 하는 것에 대한 명확한 설정 규칙은 없지만, Enterprise Application 컴포넌트를 먼저 구성하는 것이 좋다. 이렇게 하는 이유는 link 특성을 구성할 때 분명하게 확인할 수 있다.
컴포넌트 구성
- 엔터프라이즈 애플리케이션을 업로드하여 Enterprise Application 컴포넌트를 구성한다(그림 5).
그림 5. Enterprise Application 컴포넌트 특성 구성 - 데이터베이스의 이름과 크기를 지정하여 Database 컴포넌트를 구성한다. 애플리케이션에서 데이터베이스가 사전에 채워질 것으로 예상되는 경우에는 스키마 파일도 업로드한다. 중요한 점은 이 데이터베이스의 라이프사이클은 이 데이터베이스가 속한 가상 애플리케이션과 같은 라이프사이클을 따르므로 가상 애플리케이션이 종료되면 데이터베이스와 이 데이터베이스의 상태 정보가 모두 종료된다는 사실이다.
- LDIF 파일을 업로드하고 사용자 및 그룹 필터를 지정하여 User Registry 컴포넌트를 구성한다.
각 링크는 컴포넌트 간의 연관이나 통신 경로를 나타낸다. 컴포넌트에서와 마찬가지로 각 링크의 특성도 고유하다.
- Enterprise Application과 Database 컴포넌트 간에 데이터베이스 링크를 구성한다. 링크를 클릭하여 링크의 특성을
표시한다. 통신 채널을 여는 것 외에도 이 링크를 이용하면 엔터프라이즈 애플리케이션의 데이터 소스 JNDI 이름을 맵핑할 수 있다. 이 예제는
그림 6에 표시되어 있다.
그림 6. Enterprise Application과 Database 간에 링크 구성
배치 시점에서는 지정한 JNDI 이름이 WebSphere Application Server에서 Database 컴포넌트를 지원하기 위해 작성한 것에 링크된다. - Enterprise Application과 User Registry 컴포넌트 간에 링크를 구성한다. 이 링크를 이용하면 엔터프라이즈
애플리케이션에 정의된 역할을 User Registry 컴포넌트에 정의된 구체적인 그룹과 사용자에 맵핑할 수 있다. 그림 7에는 이러한 맵핑이
표시되어 있다.
그림 7. Enterprise Application과 User Registry 간에 링크 구성
Database 컴포넌트의 데이터 소스 자원 참조 특성과 User Registry 컴포넌트의 역할 이름 특성에는 엔터프라이즈 애플리케이션에서 파생된 사전 구성된 옵션이 있다. 가상 애플리케이션에 링크를 추가하면 Workload Deployer가 관련 정보를 파악하기 위해 엔터프라이즈 애플리케이션의 배치 디스크립터를 조사한다. JNDI 참조의 경우에는 Workload Deployer가 web.xml을 조사하고 보안 역할에 대해서는 application.xml을 조사한다. 이 예제는 그림 8에 표시되어 있다.
그림 8. application.xml과 web.xml 조사 항목 - 다음과 같이 가상 애플리케이션을 저장한다(그림 9).
그림 9. 가상 애플리케이션 저장
여기서부터는 재미가 있을 것이다. Virtual Application Builder에서 애플리케이션이 모델링되면 vAppArticle 애플리케이션을 배치해야 하며, 이 작업은 매우 간단하다. 가상 애플리케이션을 배치하려면 다음을 수행한다.
- Patterns > Virtual Application을 클릭하고
vAppArticle을 클릭한다. 이 예제는 그림 10에 표시되어 있다.
그림 10. 가상 애플리케이션 찾기 - 이 패널의 오른쪽에 있는 Deploy the virtual application into the
cloud를 클릭하여 그림 11과 같이 배치를 초기화한다.
그림 11. 가상 애플리케이션 배치
이미지 크게 보기 - Deploy the virtual application into the cloud를 클릭하면 클라우드
그룹을 선택할 수 있는 옵션이 그림 12와 같이 표시된다.
그림 12. 가상 애플리케이션 배치 대상
Workload Deployer에서는 가상 애플리케이션이 클라우드 그룹만 배치 대상으로 지원한다. 가상 애플리케이션은 환경 프로파일을 배치 대상으로 지원하지 않는다.
또한, 그림 12에 있는 대화 상자에는 보안 SSH를 사용하여, 배치된 VM에 액세스하도록 구성할 수 있는 고급 옵션이 표시되어 있다. 자신의 공용 키를 업로드하거나 Workload Deployer가 공용/사설 키를 생성하도록 할 수 있다. 배치된 VM에 액세스하려면 사용자 ID와 비밀번호 대신에 사용자 ID와 사설 키가 있어야 한다. 보안 SSH 액세스를 구성하지 않으면 VM에 직접 액세스할 수 없게 된다. 애플리케이션을 배치한 후에는 가상 애플리케이션 콘솔에서 이 키를 추가하고 변경할 수 있다. OK를 클릭한다. - Workload Deployer가 가상 애플리케이션 배치를 초기화한다. 잠시 후에 네트워크 구성에 따라 가상 애플리케이션이 배치되면 사용할 준비가 된 것이다. Workload Deployer가 애플리케이션 배치를 특정 인프라에 적합한 액션으로 변환한다. 또한, 필수 VM 배치를 초기화하고 미들웨어와 애플리케이션을 구성한다.
- 배치 상태를 확인하려면 그림 13과 같이 Instances > Virtual Application을
클릭한 후, vAppArticle 애플리케이션을 클릭한다.
그림 13. 가상 애플리케이션 인스턴스
가상 애플리케이션을 배치하면 특정 인프라와 미들웨어에만 해당하는 세부사항이 숨겨진다. 예를 들면, VM 수나 WebSphere Application Server 버전을 지정할 필요가 없다. 이렇게 되면 애플리케이션 개발자가 애플리케이션을 개발하는 데 집중할 수 있고 인프라와 미들웨어 세부사항을 IBM Workload Deployer에게 위임할 수 있게 된다.
그림 14에는 가상 애플리케이션의 배치 상태가 표시되어 있다.
그림 14. 가상 애플리케이션 배치 상태
이미지 크게 보기
가상 애플리케이션이 배치됨에 따라 VM Status가 Launching 상태에서 Running 상태로 변경된다. VM이 완전히 인스턴스화되면 VM 안에 상주하는 에이전트(Workload Deployer에 특정된)가 이 애플리케이션 배치에서 VM이 맡게 될 역할에 맞게 VM을 구성할 조치를 인스턴스화한다.
VM의 역할은 특정 VM이 갖게 될 미들웨어 특성을 나타낸다. 예를 들면, VM의 역할이 WebSphere Application Server나 DB2 또는 TDS가 될 수 있다. IBM Workload Deployer 에이전트가 특정 역할에 맞게 VM을 구성하면 이러한 특정 VM의 Role Status가 변경되고 결국 역할이 완전히 구성되면 녹색으로 바뀐다. 모든 역할이 성공적으로 구성되어 상태가 녹색으로 변경되면 가상 애플리케이션을 액세스할 수다. - 가상 애플리케이션이 배치되면 그림 15와 같이 WAS VM의 ENDPOINT 하이퍼링크를 클릭하여 가상
애플리케이션을 직접 액세스할 수 있다.
그림 15. 엔터프라이즈 애플리케이션 액세스
이미지 크게 보기
데이터베이스의 엔드포인트 URL과 사용자 레지스트리 VM은 이러한 미들웨어에 액세스하는 데 필요한 특정 정보를 나타낸다. 예를 들면, 데이터베이스의 엔드포인트 URL에는 DB2 클라이언트를 사용하여 데이터베이스에 액세스하는 데 필요한 연결 정보가 있다.
가상 애플리케이션이 배치되면 IBM Workload Deployer의 가상 애플리케이션 콘솔에서, 배치된 가상 애플리케이션을 모니터하고 관리할 수 있다. 또한, IBM Workload Deployer에는 배치된 가상 머신을 대상으로 특정 조작을 수행하는 기능과 하나의 중앙집중식 대시보드에서 OS, 미들웨어 및 Workload Deployer 에이전트에 특정된 로그를 볼 수 있는 기능이 있다.
가상 애플리케이션 콘솔에 액세스하려면 Instances > Virtual Applications와 vAppArticle을 차례로 클릭한다. 오른쪽에 있는 패널에서 그림 16과 같이 More details and advanced options를 클릭한다. 새 브라우저 창에서 가상 애플리케이션 콘솔이 열린다.
그림 16. 가상 애플리케이션 콘솔 액세스
이미지 크게 보기
가상 애플리케이션 콘솔에는 탭이 네 개 있다.
- Virtual Machine Monitoring: 이 뷰에는 가상 머신의 통계 그래프가 실시간으로 표시된다. 예를 들어, 배치된 애플리케이션이 CPU 주기를 많이 소비 중인 경우에는 이 뷰에 특정 VM의 CPU 사용량이 높게 표시된다.
- Middleware Monitoring: 이 뷰에는 미들웨어에 특정된 모니터링 통계 그래프가 실시간으로 표시된다. 예를 들면, 애플리케이션의 사용량이 최고로 높은 동안에 애플리케이션의 요청 수를 추적할 수 있다.
- Operation: 이 뷰에는 대상 VM에서 미들웨어에 특정된 조작을 수행할 수 있는 기능이 있다. 예를 들면, 전체 배치를 종료하지 않고도 설치된 애플리케이션을 새 버전으로 업데이트할 수 있다. Operation 탭에서는 사용자가 애플리케이션을 업데이트할 수 있을 뿐만 아니라 기타 필수 조작을 수행할 수 있다.
- Logging: 이 뷰에는 중앙집중식 사용자 인터페이스를 통해 OS, 미들웨어 및 Workload Deployer 에이전트에 특정된 각 VM 로그의 콜렉션에 액세스할 수 있는 기능이 있다. 모든 로그에 편리하게 액세스할 수 있는 기능은 다양한 VM의 여러 가지 전체 서브시스템에서 동시에 장애를 디버그하는 데 매우 유용하다.
그림 17. 가상 애플리케이션 대시보드의 Operation 탭
그림 18. 가상 애플리케이션 대시보드의 Logging 탭
이미지 크게 보기
모든 구성에 해당되는 것은 아니지만, 이는 주로 데이터베이스가 애플리케이션과 분리된 엔티티이고 자체 라이프사이클을 따르며, 완전히 다른 팀에서 고유한 기술 세트를 사용하여 관리하는 경우에 해당된다. Workload Deployer는 이러한 요구사항을 인식하고 데이터베이스가 분리된 엔티티로 작성되고 관리되게 한다. 그러면 자체 데이터베이스를 작성하는 대신, 가상 애플리케이션을 기존 데이터베이스에 연결할 수 있다.
이 섹션에서는 Workload Deployer의 데이터베이스 패턴(vAppDB)을 구성하며 또한, Existing Database 컴포넌트를 사용하여, 여기서 작성한 가상 애플리케이션을 사용하도록 가상 애플리케이션을 확대한다. 이 기사에서는 데이터베이스 패턴이 아니라 웹 애플리케이션 패턴을 시험하는 데 집중하고 있지만 데이터베이스 패턴은 Workload Deployer의 중요한 지원 기능이며, 본질적으로 이 기사에서는 DaS(Database as a Service) 모델을 사용하는 방법을 설명할 것이다.
vAppDB 데이터베이스 패턴 구성 및 배치
- Patterns > Database Patterns로 이동하여 녹색 플러스 아이콘을 클릭한다.
Database Pattern 패널이 표시된다. 그림 19와 같이 이 패널에서 데이터베이스 이름, 데이터베이스 크기를 정의하고 지원되는 모든
스키마 파일을 업로드할 수 있다.
그림 19. Database Pattern 작성 패널 - 모든 데이터베이스 특성을 정의했으면, Save를 클릭한 후, 해당 데이터베이스를 강조하고
Deploy 아이콘을 클릭하여 데이터베이스를 배치한다. 네트워크 상황에 따라 이 프로세스는 다소 시간이 걸릴 수
있다. 데이터베이스 배치 상태를 모니터하려면 Instances > Databases로 이동하고 데이터베이스를
강조하여 해당 정보를 표시한다. 배치가 완료되면 그림 20에 표시되어 있는 Host, Port, User 및 Password 정보에 주목한다.
그림 20. 데이터베이스 인스턴스 정보(Host 및 Port)
이 정보는 Existing Database 컴포넌트로 가상 애플리케이션을 확대할 때 사용된다.
조직의 내부나 외부에 있는 기존 미들웨어나 레거시 엔터프라이즈 시스템에 연결해야 하는 경우가 자주 있다. 이러한 경우에는 Workload Deployer를 사용하는 것이 좋다. Workload Deployer는 사설 클라우드 외부에 있는 시스템에 액세스하여 계속해서 이 시스템을 활용할 수 있게 하는 유연성을 제공한다. Workload Deployer에는 기존 데이터베이스, 사용자 레지스트리, CICS, IMS 등에 연결하는 데 필요한 컴포넌트가 있다.
이 시나리오에서는 Existing Database 컴포넌트로 가상 애플리케이션을 확장함으로써 이러한 기능을 강조한다. 이 컴포넌트를 선택한 유일한 이유를 말하자면 Existing User Registry 컴포넌트가 데이터베이스 패턴 기능을 나타내기 때문이다. 또한, 이 점은 반복해서 언급할만한 가치가 있고 강조된 것보다 훨씬 더 많은 데이터베이스 패턴 기능이 있으며 적어도 지금은 독자도 이 패턴이 존재한다는 것을 알 것이다. 따라서 독자가 이 특정 기능에 관심이 있는 경우에는 더 조사할 수도 있다.
- Virtual Application Builder 도구에서 가상 애플리케이션을 연다. 그림 21과 같이 Database 컴포넌트를
삭제하고(이 조치를 수행하면 연관된 링크도 제거됨), Existing Database(DB2) 컴포넌트를 추가하고 해당 링크를 다시 설정한다.
그림 21. Database 컴포넌트 제거 및 복원 - Existing Database 컴포넌트를 구성한다. vAppDB를 생성하고 배치하는 과정에서 작성한 호스트, 포트, 사용자 이름 및 비밀번호를 사용하여 이 컴포넌트를 구성한다.
- 새로 작성된 링크에는 이 정보가 존재하지 않으므로 해당 링크의 특성 시트를 재구성한다. 이 예제는 그림 22에 표시되어 있다.
그림 22. Existing Database 특성 시트
공유 서비스는 둘 이상의 가상 애플리케이션 인스턴스가 공유하는 서비스이다. 현재는 공유 서비스가 두 개 있다.
- CaaS(Caching as a Service)
- PaaS(Proxy as a Service)
이러한 서비스를 공유함으로써 얻게 되는 두 가지 주요 혜택은 다음과 같다.
- 자원을 더 효율적으로 활용할 수 있으며 각 가상 애플리케이션 배치를 위한 별도의 프록시와 캐싱이 없어도 된다.
- 장애 복구 지원: 공유 서비스는 여러 개의 VM과 함께 배치되므로 VM 하나가 작동을 중지하면 장애가 발생한 VM이 복원되거나 다시 시작되는 과정에서 다른 VM이 워크로드를 선택한다.
- 공유 서비스를 시작하려면 관리 레벨 사용자로 로그인한다. 그림 23과 같이 Cloud > Shared
Services를 클릭한다.
그림 23. 공유 서비스 인에이블먼트
이미지 크게 보기 - 공유 서비스가 두 개(CachingService 및 PROXY) 표시된다. 이러한 서비스는 사전에 구성된다. 각 서비스의 배치 아이콘을 클릭한다.
- 각 서비스를 배치하려면 두 가지 정보, 즉 VM 수와 대상 클라우드 그룹 정보가 필요하다. 이것이 전부다.
Deploy를 클릭하면 잠시 후에 공유 서비스를 사용할 수 있게 된다. 그림 24에는 실행 중인 캐싱 서비스의
상태를 확인할 수 있는 예가 표시되어 있다.
그림 24. 공유 캐시 서비스 배치
이미지 크게 보기
일반적으로 캐싱 및 프록시 공유 서비스는 가상 애플리케이션이 사용하도록 설계된다. 여기에서 설명하는 것은 Web Application 패턴을 통해 공유 서비스를 사용하는 한 가지 방법이다.
Web Application 패턴에서는 캐싱 서비스를 사용하여 HTTP 세션 정보를 저장한다. 이 패턴은 지속되는 데이터베이스가 아니고 인메모리 지속성을 사용하지만, 캐싱 서비스에서 장애 복구 기능을 지원한다는 점을 감안하면 이점은 문제가 되지 않는다. 먼저 Scaling 정책을 추가한 후, Enable session caching 선택란을 체크하여 Web Application 패턴에서 캐시 서비스를 사용할 수 있게 한다.
Web Application 패턴에서는 프록시 서비스를 사용하여 요청을 가상 애플리케이션으로 라우트한다. Scaling 및 Routing 정책을 Enterprise Application 컴포넌트에 추가하여 Web Application 패턴에서 프록시 서비스를 사용할 수 있게 한다.
그러면 기본적인 기능은 모두 살펴본 것이다. 그림 25에서 이러한 서비스가 사용 가능한 것을 확인할 수 있다.
그림 25. Web Application 패턴 공유 서비스 인에이블먼트
다음 마지막 단계에서는 이렇게 새로운 설정이 적용된 가상 애플리케이션을 배치한다. 알게 되겠지만, 단 한 가지 실질적인 차이점은 이제는 가상 호스트 이름을 사용하여 애플리케이션에 액세스할 수 있다는 점이다. 이 이면에는 살펴보아야 할 내용이 상당히 많이 있으며, 가상 호스트 이름을 사용한 애플리케이션 액세스는 먼저, 프록시 서비스를 통해 라우트된다. 이외에도 HTTP 세션 정보는 VM에서 로컬로 지속되는 것이 아니라 캐시 서비스에서 지속된다.
마지막으로 이 시나리오를 완료하는 작업은 이 기사의 범위를 벗어나므로 독자가 직접 IP 로드 밸런서를 구성하여 가상 호스트의 수신 요청이 프록시 서비스 IP 주소로 라우트되게 해야 한다는 점을 말하고 싶다.
클라우드 컴퓨팅에서는 가상 애플리케이션과 데이터베이스를 작성하고, 배치 및 관리하는 태스크가 필수적이며 Workload Deployer는 이러한 태스크를 손쉽게 수행하는 데 필요한 턴키 방식의 솔루션이다.
참고자료
교육
- Harness
the power of the cloud with IBM Workload Deployer V3 기사에서 애플리케이션 중심으로 IBM
Workload Deployer를 개선하여 이전의 WebSphere CloudBurst를 능가하도록 하는 방법을 배우자.
- WebSphere 전도자인 Dustin Amrhein은 자신의 블로그인 A
view from the clouds: Cloud computing for the WebSphere developer에서 IBM
Workload Deployer에 관해 자주 토론한다.
- 세 개의 파트로 구성된 블로그 기사인 IBM
Workload Deployer: Application-centric cloud platform에는 IWD 관련 정보가 많이 있다.
- IBM
Workload Deployer 사이트를 방문하자. 문서
라이브러리에는 웹 캐스트, Redbook 및 Workload Deployer 백서가 있다.
- developerWorks 클라우드 개발자 자원에서는
클라우드 배치를 위한 프로젝트를 개발 중인 애플리케이션 및 서비스 개발자의 경험과 지식을 찾아보고 공유할 수 있다.
- developerWorks의 WebSphere 자원에서는 IBM
Workload Deployer에 대한 지식과 경험을 찾고 공유할 수 있다.
- 다음 단계: IBM SmartCloud
Enterprise에 액세스하는 방법을 찾아보자.
- 클라우드 컴퓨팅 자원과 기술 개발자 컨텐츠는 Cloud
computing: Fundamentals를 참조한다.
- Twitter의 developerWorks
페이지를 팔로우하자.
- IBM SmartCloud Enterprise에 사용 가능한 제품 이미지를 참조하자.
- developerWorks의
클라우드 컴퓨팅 그룹에 참여하자.
- developerWorks에
있는 뛰어난 클라우드 블로그를 모두 읽어보자.
- 연결, 공유 및 협업을 위한 전문가 네트워크이자 통합 커뮤니티 도구 세트인 developerWorks 커뮤니티에
참여하자.
rian Stelzer는 소프트웨어 엔지니어로, IBM Workload Deployer의 팀 리더이다.
현재, 그는 클라우드 기반의 환경에 필요한 교육 및 아키텍처 솔루션을 제공하는 역할을 담당하면서 IBM Workload Deployer,
WebSphere Application Server 및 VMware 기반 기술에 집중하고 있다. 이전에는 WebSphere Application
Server와 WebSphere Application Server Community Edition용 마이그레이션 솔루션을
설계했다
Davanum Srinivas는 IBM Workload Deployer 팀의 수석 소프트웨어
엔지니어이다. 그는 IBM Workload Deployer의 스토리지 특성을 담당하고 있는 팀을 이끌고 있다. 이전에는 IBM Workload
Deployer 팀의 Release Architect 역할을 했으며 WebSphere 웹 서비스 개발에 참여했다.
Amit Acharya는 IBM Cloud Initiatives Development 조직의 고문
소프트웨어 엔지니어이다. 그는 사설 클라우드 공간의 전략 품질 계획 및 제품 실행을 지휘하며 PaaS(Platform as a Service)
베타 플랫폼을 실행하는 데 큰 역할을 해왔다. 그는 엔터프라이즈 애플리케이션 개발 및 사용자 지향에 초점을 둔 미들웨어 솔루션에 관한 지식을
충분히 갖추고 있다. 그는 서비스 지향 아키텍처 영역의 IBM Redbook을 저술했으며 IBM Patent Portfolio에 활동적으로
기여해왔다. 그는 퍼듀대학에서 전자 및 컴퓨터 공학 석사학위를 취득했다.
댓글 없음:
댓글 쓰기