DataSynapse사의 FabricServer소개자료 입니다.

1. Always On, Always Responsive
FabricServer를 이용한
를
‘다이나믹 애플리케이션 서비스 관리’ 관리’
펜타시스템 테크놀러지㈜
1

2. 회사 소개
Company Information Customer Driven Growth
Founded: 2000 ~100 Fortune 1,000 Clients
Employees: ~ 200 1,000s installations globally
Revenue: 60+% YOY Growth (2007) 1M+ CPUs in Fortune 1,000 data centers
Worldwide Presence Dynamic Application Service Management
Headquarters: New York, London, Tokyo Our mission is to be the clear leader in enabling
Global Offices: Boston, Chicago, Global 2,000 organizations to deliver, manage,
Washington D.C., Paris, Frankfurt, and optimize scalable enterprise-class
Madrid, Milan, Beijing application services
2

3. 고객사
3

4. Legacy Data Center Model
4

5. 레거시 데이터센터 모델
인터넷 뱅킹(J2EE / Web Apps) 웹 포탈
뱅킹 포탈(ISV/COTS Apps) CRM(Legacy Apps) NEW Apps
Datacenter Silo Datacenter Silo Datacenter Silo Datacenter Silo
Challenges
• 애플리케이션이 전용 리소스에만 제한되어 있어 확장성과 QoS에 제한을 받습니다.
• 작업 부하가 최대치일 경우를 대비하여 자원이 과다 할당되어 있으므로 평상시에 10~20%의 자원만을 사용하는
현상(underutilization)을 초래합니다.
• 새로운 비즈니스 업무가 발생할 때 마다 전용 리소스가 추가로 발생해야 합니다.
비용,성능
성능,민첩성에
기업의 비용 성능 민첩성에 영향
• 레거시 데이터센터 모델은 인프라를 과다 제공하고 불충분하게 이용함으로써 비용을 증가시킵니다.
• 제한된 방식으로 하드웨어를 추가하는 것 만으로는 성능요구문제를 해결하기 어렵습니다.
• 시장 수요에 신속하게 대응하기 위한 비즈니스 능력에 걸림돌이 됩니다.
5

6. 레거시 데이터센터 모델
IT예산 중 40%가 인력 예산의 80%~90%를 IT 57% 의 회사들은 비즈니스에
비용에 할당 운용에 사용 영향을 미치는 문제를 찾아야
하는 과제를 가지고 았다.
&
95%의 경우 24%의 경우
애플리케이션 서비스 관리의 주요 비용은 인력 및 운용에 트러블슈팅에 2 명 트러블슈팅에 10명
사용된다. 이상이 필요하다 이상이 필요하다
80
70 • 78%의 경우 미션 크리티컬한
60 비즈니스 애플리케이션의 1시간 애플리케이션
50 다운타임이 최소 시간당 $10,000의 업그레이드와
40 손실을 발생시킨다고 한다 패치의 경우가
30 50% 실패
20 의
• 22%의 경우 시간당 $100,000과
과
10 $500,000의 손실 발생
의
0
10K+ 100K+
6

7. What is FabricServer?
7

8. FabricServer
• 비즈니스 정책 및 수요에 따라서 기업용 애플리케이션을 동적으로 구성, 활성화 및
확장하는 Dynamic Application Service Management 솔루션
• FabricServer를 이용하여 IT 조직은 애플리케이션 관리와 배치를 단순화하는데
집중하고 비용과 복잡성을 줄이는 동시에 운영 효율과 민첩성을 높일 수 있습니다.
8

9. 애플리케이션 가상화
단계
• 1단계 : 정적이고 Silo화된 데이터센터 인프라에서
화된
애플리케이션을 분리
단계
• 2단계 : 공유 자원 풀에 대한 중앙 집중 커맨드와 제어
단계
• 3단계 : 애플리케이션에 자원을 다이나믹 하게 할당
온디맨드(On-demand)
• 온디맨드
• 캘린더 스케줄
• 비즈니스 우선 순위
• SLA 및 QoS
9

10. 지원 애플리케이션 플랫폼
한번 구성으로 어느
곳에나 디플로이
SharePoint
비즈니스 정책에
POJO
따른 동적인 확장
IIS
Apache
Tomcat
SLA / cost /
utilization을 Command
ASP.NET
모니터링 Line
Java Platforms Microsoft Platforms Other Containers ISV / Packaged Applications
Dynamic Application Service Management
데이터 센터
10

11. 의
FabricServer의 가치
Time to Deploy Server Utilization Performance / QOS
Always Always
Weeks Minutes App Silos Clouds
Available Responsive
Challenge: Challenge: Challenge:
기업용 애플리케이션의 프로비져닝과 모든 애플리케이션 프로젝트는 자체 자원 서비스 관리에 대한 임시변통의
구성은 복잡하다. 일관적이지 않으며 풀을 필요로 하기 때문에 비용을 낭비하게 접근방식이 변화하는 수요와 자원
느리고 일반적으로 셋업 시에 1일에서 되고 혁신을 저하시킨다 가용성에 대한 다이나믹한 응답을 어렵게
30일 가량 소요된다 만든다
Value Proposition: Value Proposition: Value Proposition:
FabricServer는 애플리케이션의 구성 및 FabricServer는 다수의 애플리케이션 FabricServer는 서비스 관리와
프로비져닝 작업을 일괄적인 방식으로 수 프로젝트가 공통 자원 풀을 사용하도록 프로비져닝,구성과 실행환경 제어를
분내에 자동으로 완성 해준다 해서 비용을 감소시킨다 통합해서 변화하는 수요와 자원 가용성에
대해서 다이나믹 하게 대응한다
11

12. 사례:
사례 WebSphere ND Cell 설정
Best Practices From
WebSphere Web site: Stage 1 Stage 2 Stage 3 Stage 4
Create Virtual Image Provide Customization Deploy Activate
Files
• Install guest OS
• Install JEE App Server Target Deployment manager
Hypervisor
• Install applications
• ConfigJEE Script Standalone
Application Profiles • Clone
Create profile Image
JEE Update profile Managed Node
Application Server
Import .car file • Customize OS and
Start DMgr network
Other common Cell
Add node Deployment Managed
components
monitoring agents, Mgr. Cell
Start server • Run ConfigJEE
security, etc..
• Application Profiles
Operating System • Choose Option (1-4)
Existing
standalone Managed
node Node 1
• Construct Topology
Export Deploy
Manager
Managed
MyApp.car Node 2
12

13. 를
FabricServer를 이용한 자동화
1 기본 구성 모델을 템플릿에 기록 1 Stage 1 2 Stage 2 3 Stage 3 Stage 4
Create Virtual Image Provide Customization Deploy Activate
Files
• Install guest OS
• Install JEE App Server Target Deployment manager
Hypervisor
• Install applications
• ConfigJEE Script Standalone
Application Profiles • Clone
Create profile Image
JEE Update profile Managed Node
Application Server
특정 아키텍처와 애플리케이션
Import .car file • Customize OS and
2 Other common
Start DMgr
Add node
network
Deployment
Cell
Managed
구성 모델을 생성 components
monitoring agents,
security, etc..
Start server • Run ConfigJEE
Mgr. Cell
• Application Profiles
Operating System • Choose Option (1-4)
Existing
standalone Managed
node Node 1
• Construct Topology Deploy
Export
Manager
3 런타임환경에서 동적으로 Managed
디플로이,프로비져닝,활성화
MyApp.car Node 2
13

14. 아키텍처
14

15. FabricServer 아키텍처
Fabric Broker 중앙 집중 방식의 정책 기반 활성화 및 모니터링 제공
HOST
Domain 2
Domain 1 Domain
D3
Domain 4
Domain
Daemon: 호스트를 모니터링 하고 엔진들을 관리
Domain
Engine: 애플리케이션 도메인 인스턴스를 생성하고 제어 및 모니터링
Domain: 애플리케이션 및 애플리케이션 서버 인스턴스
15

16. FabricServer 아키텍처 - 계속
Distributions
FabricServer Broker
JEE서버 플랫폼(Oracle WebLogic,IBM WebSphere)과
같은 애플리케이션 실행환경의 스냅샷
Registry
Distributions
Application Domains
Distribution상에서 실행될 애플리케이션과 애플리케이션 구성
애플리케이션 서버 구성 파일 – Distribution에 자동으로
삽입됨. App Domains
인터넷 뱅킹
Application Service Policy CRM
웹 포탈
애플리케이션이 실행될 스케줄과 클러스터 크기(인스턴스 수)
운영 환경 조건, 헬스 상태,통계 정보 모니터 Policies
Rules
캘린더 스케줄링
OS 종류 또는 메모리 크기와 같은 애플리케이션이 우선 순위
프로비져닝될 환경의 필요 조건과 선호도 설정 SLA
16

17. FabricServer 프로비져닝 동작 방식
매뉴얼 방식 FabricServer 방식
배포,구성 및 Start/Stop
설치,배포,구성 및 FabricServer를 이용한 자동화
Start/Stop
관리자의 수 작업 Engine
애플리케이션
애플리케이션
Container
애플리케이션 플랫폼
애플리케이션 플랫폼
OS OS
FabricServer Broker
애플리케이션 정책,스케줄,
관리자 애플리케이션
플랫폼 우선순위,SLA
17

18. FabricServer 프로비져닝 동작 방식
FabricServer Broker
Storage
Registry
Distributions
App Domains FabricServer Host 인터넷
뱅킹
Rules
Policies Distribution Domains
<deploy>
<start>
Daemon
Engine
<start>
• Daemon은 호스트를 모니터링하고 또한 온디맨드 방식으로 Engine을 복제
• Broker는 Engine이 Domain 인스턴스를 스타트 시키도록 지시
• Engine은 애플리케이션을 실행 환경에 디플로이하고 플래폼을 구성
• Engine은 애플리케이션을 스타트 시키고 상태 모니터링 및 통계 데이터 수집
18

19. FabricServer 의 장애 처리
FabricServer
Broker App App
엔진 App
엔진
애플리케이션 Platform
Platform Platform
플랫폼 컨테이너 컨테이너
OS OS
애플리케이션
정책,스케줄,
우선순위,SLA
App App
엔진 엔진
Platform Platform
컨테이너 컨테이너
OS OS
공유 자원 풀
19

20. 패키징,프로비져닝,
자동화된 패키징,프로비져닝,활성화
Platforms
FabricServer Applications
CRM Decision
Package Support Package
eBiz
Customer
Care
Users Users
Distributions App Domains
Deploy, Provision
and Activate
20

21. 관리의 자동화
21

22. 관리의 자동화
• 모니터링
- JMX정보를 통한 애플리케이션 성능 항목에 대한 모니터링
- 시스템 자원 사용량에 대한 모니터링 및 레포팅
• 자동화를 위한 정책 설정
- 시스템 자원 사용량뿐 아니라 애플리케이션 성능 항목을 기준으로 한 Scale out 정책사용
- 비즈니스 애플리케이션 별 우선순위 설정 가능
• 중앙 집중 방식의 관리 및 제어
- 중앙 집중 방식의 애플리케이션/애플리케이션 플랫폼 저장소
- 전체 공유 자원 풀에 대해서, One Click으로 전체 애플리케이션을 프로비져닝
22

23. 관리의 자동화
• 모니터링 화면
- 전체 공유 자원 풀에 대한 모니터링
- 도메인 별 성능 및 자원사용량 모니터링
23

24. 관리의 자동화
• 개발자를 위한 Self-Service Portal
• 빈번한 개발자의 개발환경 설치 및 구성 요구를 개발자 스스로 할 수 있도록 함
• 개발자의 요청에 대해서 관리자는 승인 및 거절 권한
• 개발자는 원하는 애플리케이션 플랫폼과 구성 템플릿을 통해서 원하는 이미지를 생성
24

25. Technical Use Cases
25

26. 공유 자원 풀을 이용한 시간 스케줄링
Business Data
운영환경에 있는 다수의
Web-Online
Intelligence Integration
애플리케이션이 공유 자원 Day
사용한다면?
풀을 사용한다면?
• 어떤 애플리케이션 플랫폼도
수동으로 프로비져닝 하거나 구성할
필요 없음 Evening
• 캘린더 스케줄에의 의해서 수 분내에
한 플랫폼에서 다른 플랫폼으로
자동으로 전환
• 부하에 따라서 동적으로 플랫폼의
Overnight
스케일을 UP /Down
26

27. 와의
VMware와의 통합 기능을 이용한 다이나믹 프로비져닝
FabricServer Broker
Engine Distribution App Domain
Operating System
Policies
Virtual Machine
Physical Machine
Run-Time Controls
• FabricServer Broker 새로운 VM이 필요함을 감지
• VI SDK가 새로운 VM을 구동하고,VM환경에서
FabricServer Engine이 구동
VMware VI3
VI SDK
• FabricServer Broker 가 애플리케이션 플랫폼과
VMware Virtual Center 애플리케이션 실행환경을 프로비져닝 및 구성을 실행
27

28. 공유 페일 오버 시스템
운영 환경에 있는 다수의 Production Production Production
애플리케이션이 공유 자원 풀을
사용한다면?
사용한다면? Failover Failover Failover
• 장애나 부하에 대응하기 위해
App1 App2 App3
수동으로 백업 시스템을
생성하거나 구성할 필요가 없음
• 부하 및 장애가 동적으로 발생함에
따라서 VM을 삭제하거나 리-
Production Production Production
프로비져닝 할 수 있다.
App1 App2 App3
FabricServer Engine
VMware
Shared Failover
28

29. 최근 고객 사례
29

30. 차세대 데이터 센터 모델
온디맨드 가상 데이터 센터를 위한
End to End Provisioning and Management 솔루션
ISV Packages Application Platforms Custom Applications
Applications DASM
VM VM VM VM VM VM VM
Virtualization
ESX Server
Infrastructure
Bare-Metal Servers Storage Network
VFrame DC
30

31. 새로운 서비스 다이나믹 프로비져닝
Resources Centralized Command & Control
►Apps 템플릿을 조립해서 통합된 애플리케이션과 인프라스트럭처 스택을
프로비져닝 한다.
►Platforms
Integrated Application and
Infrastructure Stack
►OS Templates
Application
Command and Control
Applications Application Platform
►Firewalls DataSynapse DASM
API
►Switches Operating System / VM
Virtualization
VMware Virtual Center
►Load API Network
Balancers
Infrastructure
Cisco VFrame DC
►Servers Servers
►Storage Storage
31

32. British Telecom – MaaS 프로젝트
MaaS(Middleware As a Service)프로젝트 목표
프로젝트
• Enterprise Virtual Data Center(기업 가상화 데이터 센터) 구축
개선
Cycle Time개선
미들웨어와 웹 서비스를 위한 비용 절감
프로비져닝 자동화 플랫폼 구축
문제 해결 시간 감소
일관되고 표준화 된 방식으로 서비스를 시행착오 감소
공급
성능(QoS) 개선
성능
가용성 개선
32

33. British Telecom – MaaS 아키텍처
L
O
C C ustom ers
A
L Customers Tools Tools Tools
On-
On-Demand
Packaging Dynamic
Provisioning Application
Service
Activation Management Management
C
L
O VM VM VM VM VM VM VM VM
U
Compute
D and
Storage
Network
33

34. British Telecom – MaaS 최적화
Platforms ISVs Legacy
Pre-DASM
Utilization Response Time to Infrastructure Growth
Time Deploy Costs Rates
No Data No Data
Platforms ISVs Legacy
DASM - Baseline
Dynamic Application Service Management Platform
Maps metrics to the
infrastructure Platforms ISVs Legacy
Captures baseline
Optimized
metrics Dynamic Application Service Management Platform
Optimizes based
on results
34

35. British Telecom – MaaS 프로젝트 결과
• Cycle Time개선
• 자동화된 애플리케이션 디플로이는 현재의 수동적인 방식에 비해 75%의 CycleTime 개선.
의
• 애플리케이션의 자동화된 업그레이드와 패치로 현재의 수동 방식이 걸리는 시간의 50% 이상 개선.
• 서버 이용률 개선
• 가상 데이터 센터 환경에서 애플리케이션의 동적인 정책 관리를 제공함으로써 50%의 이용률 개선.
의
• SLA 개선
• 동적으로 자원을 유연하게 사용함으로써 애플리케이션이 언제나 가용성과 QoS에 부합하도록 한다.
QoS .
• 자동화된 장애대응 시스템
• H/W또는 성능장애 시 다른 환경으로 애플리케이션 서비스를 확장 및 이동함으로써 자동화된 DR(Data Recovery)를
제공한다.
• TCO절감
• 현재의 운영 비용에서 30% 절감
• 서버 이용률 수준을 높임으로써 중복된 공간을 줄이며 이는 운용 전력과 냉방 전력이 필요한 하드웨어를 줄이는 것과 같은
효과이다.
35

36. Q &A
jykang@penta.co.kr
http://www.datasynapse.com
36