Fabric Server 제품소개
Upcoming SlideShare
Loading in...5
×
 

Fabric Server 제품소개

on

  • 1,611 views

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

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

Statistics

Views

Total Views
1,611
Views on SlideShare
1,602
Embed Views
9

Actions

Likes
0
Downloads
14
Comments
0

2 Embeds 9

http://blog.daum.net 8
http://www.slideshare.net 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Fabric Server 제품소개 Fabric Server 제품소개 Presentation Transcript

  • Always On, Always Responsive FabricServer를 이용한 를 ‘다이나믹 애플리케이션 서비스 관리’ 관리’ 펜타시스템 테크놀러지㈜ 1
  • 회사 소개 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 View slide
  • Legacy Data Center Model 4 View slide
  • 레거시 데이터센터 모델 인터넷 뱅킹(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
  • 레거시 데이터센터 모델 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
  • What is FabricServer? 7
  • FabricServer • 비즈니스 정책 및 수요에 따라서 기업용 애플리케이션을 동적으로 구성, 활성화 및 확장하는 Dynamic Application Service Management 솔루션 • FabricServer를 이용하여 IT 조직은 애플리케이션 관리와 배치를 단순화하는데 집중하고 비용과 복잡성을 줄이는 동시에 운영 효율과 민첩성을 높일 수 있습니다. 8
  • 애플리케이션 가상화 단계 • 1단계 : 정적이고 Silo화된 데이터센터 인프라에서 화된 애플리케이션을 분리 단계 • 2단계 : 공유 자원 풀에 대한 중앙 집중 커맨드와 제어 단계 • 3단계 : 애플리케이션에 자원을 다이나믹 하게 할당 온디맨드(On-demand) • 온디맨드 • 캘린더 스케줄 • 비즈니스 우선 순위 • SLA 및 QoS 9
  • 지원 애플리케이션 플랫폼 한번 구성으로 어느 곳에나 디플로이 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
  • 의 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
  • 사례: 사례 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
  • 를 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
  • FabricServer 아키텍처 Fabric Broker 중앙 집중 방식의 정책 기반 활성화 및 모니터링 제공 HOST Domain 2 Domain 1 Domain D3 Domain 4 Domain Daemon: 호스트를 모니터링 하고 엔진들을 관리 Domain Engine: 애플리케이션 도메인 인스턴스를 생성하고 제어 및 모니터링 Domain: 애플리케이션 및 애플리케이션 서버 인스턴스 15
  • 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
  • FabricServer 프로비져닝 동작 방식 매뉴얼 방식 FabricServer 방식 배포,구성 및 Start/Stop 설치,배포,구성 및 FabricServer를 이용한 자동화 Start/Stop 관리자의 수 작업 Engine 애플리케이션 애플리케이션 Container 애플리케이션 플랫폼 애플리케이션 플랫폼 OS OS FabricServer Broker 애플리케이션 정책,스케줄, 관리자 애플리케이션 플랫폼 우선순위,SLA 17
  • 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
  • FabricServer 의 장애 처리 FabricServer Broker App App 엔진 App 엔진 애플리케이션 Platform Platform Platform 플랫폼 컨테이너 컨테이너 OS OS 애플리케이션 정책,스케줄, 우선순위,SLA App App 엔진 엔진 Platform Platform 컨테이너 컨테이너 OS OS 공유 자원 풀 19
  • 패키징,프로비져닝, 자동화된 패키징,프로비져닝,활성화 Platforms FabricServer Applications CRM Decision Package Support Package eBiz Customer Care Users Users Distributions App Domains Deploy, Provision and Activate 20
  • 관리의 자동화 21
  • 관리의 자동화 • 모니터링 - JMX정보를 통한 애플리케이션 성능 항목에 대한 모니터링 - 시스템 자원 사용량에 대한 모니터링 및 레포팅 • 자동화를 위한 정책 설정 - 시스템 자원 사용량뿐 아니라 애플리케이션 성능 항목을 기준으로 한 Scale out 정책사용 - 비즈니스 애플리케이션 별 우선순위 설정 가능 • 중앙 집중 방식의 관리 및 제어 - 중앙 집중 방식의 애플리케이션/애플리케이션 플랫폼 저장소 - 전체 공유 자원 풀에 대해서, One Click으로 전체 애플리케이션을 프로비져닝 22
  • 관리의 자동화 • 모니터링 화면 - 전체 공유 자원 풀에 대한 모니터링 - 도메인 별 성능 및 자원사용량 모니터링 23
  • 관리의 자동화 • 개발자를 위한 Self-Service Portal • 빈번한 개발자의 개발환경 설치 및 구성 요구를 개발자 스스로 할 수 있도록 함 • 개발자의 요청에 대해서 관리자는 승인 및 거절 권한 • 개발자는 원하는 애플리케이션 플랫폼과 구성 템플릿을 통해서 원하는 이미지를 생성 24
  • Technical Use Cases 25
  • 공유 자원 풀을 이용한 시간 스케줄링 Business Data 운영환경에 있는 다수의 Web-Online Intelligence Integration 애플리케이션이 공유 자원 Day 사용한다면? 풀을 사용한다면? • 어떤 애플리케이션 플랫폼도 수동으로 프로비져닝 하거나 구성할 필요 없음 Evening • 캘린더 스케줄에의 의해서 수 분내에 한 플랫폼에서 다른 플랫폼으로 자동으로 전환 • 부하에 따라서 동적으로 플랫폼의 Overnight 스케일을 UP /Down 26
  • 와의 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
  • 공유 페일 오버 시스템 운영 환경에 있는 다수의 Production Production Production 애플리케이션이 공유 자원 풀을 사용한다면? 사용한다면? Failover Failover Failover • 장애나 부하에 대응하기 위해 App1 App2 App3 수동으로 백업 시스템을 생성하거나 구성할 필요가 없음 • 부하 및 장애가 동적으로 발생함에 따라서 VM을 삭제하거나 리- Production Production Production 프로비져닝 할 수 있다. App1 App2 App3 FabricServer Engine VMware Shared Failover 28
  • 최근 고객 사례 29
  • 차세대 데이터 센터 모델 온디맨드 가상 데이터 센터를 위한 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
  • 새로운 서비스 다이나믹 프로비져닝 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
  • British Telecom – MaaS 프로젝트 MaaS(Middleware As a Service)프로젝트 목표 프로젝트 • Enterprise Virtual Data Center(기업 가상화 데이터 센터) 구축 개선 Cycle Time개선 미들웨어와 웹 서비스를 위한 비용 절감 프로비져닝 자동화 플랫폼 구축 문제 해결 시간 감소 일관되고 표준화 된 방식으로 서비스를 시행착오 감소 공급 성능(QoS) 개선 성능 가용성 개선 32
  • 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
  • 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
  • British Telecom – MaaS 프로젝트 결과 • Cycle Time개선 • 자동화된 애플리케이션 디플로이는 현재의 수동적인 방식에 비해 75%의 CycleTime 개선. 의 • 애플리케이션의 자동화된 업그레이드와 패치로 현재의 수동 방식이 걸리는 시간의 50% 이상 개선. • 서버 이용률 개선 • 가상 데이터 센터 환경에서 애플리케이션의 동적인 정책 관리를 제공함으로써 50%의 이용률 개선. 의 • SLA 개선 • 동적으로 자원을 유연하게 사용함으로써 애플리케이션이 언제나 가용성과 QoS에 부합하도록 한다. QoS . • 자동화된 장애대응 시스템 • H/W또는 성능장애 시 다른 환경으로 애플리케이션 서비스를 확장 및 이동함으로써 자동화된 DR(Data Recovery)를 제공한다. • TCO절감 • 현재의 운영 비용에서 30% 절감 • 서버 이용률 수준을 높임으로써 중복된 공간을 줄이며 이는 운용 전력과 냉방 전력이 필요한 하드웨어를 줄이는 것과 같은 효과이다. 35
  • Q &A jykang@penta.co.kr http://www.datasynapse.com 36