Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Intro to hpe helion stackato_paa_s

386 views

Published on

Introduction to Cloud Foundry and HPE Stackato.

Published in: Technology
  • Be the first to comment

Intro to hpe helion stackato_paa_s

  1. 1. 차례 • PaaS • Cloud Foundry • HPE Helion Stackato 2
  2. 2. PaaS란? • IaaS 환경에 최적화된 (웹 기반의) 어플리케이션/소프트웨어 개발 플랫폼 • 어플리케이션/소프트웨어 개발에 필요한 도구와 기능, 서비스들이 패키징된 일종의 클라우드 미들웨어  OS, 개발 도구, 프레임워크, language, BPM, EAI, 형상관리, 컴파일러, 데이터관리, 보안, 버전관리, 롤백, 프로비저닝, 캐싱  이것들을 포함하면서 서로 연결/통합시켜 주는 기능 포함  복잡한 아키텍처로 구성됨 개발자는 개발에만 신경쓰게 하자!  IT 자원이 항상 서비스 가능한 상태(즉, 호스팅된 상태 = 사용가능한 상태)로 제공됨.  클라우드 상에서 개발과 딜리버리가 가능  IT 자원을 셀프 서비스나 API를 통해 사용할 수 있도록 함(=추상화하여 제공) 4
  3. 3. Cloud Service의 분류 IT 자원의 관리 권한에 따른 분류 5
  4. 4. Platform-as-a-Service(PaaS) Cloud-enabled automation and orchestration of app services and containers SERVICE UNIT • 어플리케이션 서비스(예, 메시지)와 컨테이너 (예, Redhat, tcServer, Weblogic) ABSTRACTION 대상 • 물리적 인프라, OS, Middleware, Runtime PRIMARY USE CASE • 개발자와 테스터에게 표준 어플리케이션과 컨테이너 제공 • 수평 확장과 확장 기능(bursting capability)를 지원하는 인프라 자원을 동적으로 관리 ADVANCE USE CASE • 테스트 자동화(성능, 기능, 보안, 규제준수 등) • 지속적 통합(CI)와 배포 시스템과의 통합 TOOLS • Cloud Foundry • vSphere 6
  5. 5. PaaS의 확산 배경 어플리케이션의 대형화와 DevOps의 필요성에 따라 어플리케이션 배포 방식의 변화 1. 빠르게 변화하는 개발환경의 관리 필요 • 자동화된 개발, 배포 환경 • 비즈니스 요구사항에 대한 빠른 대응 2. 복잡해진 Middleware • 개발도구, 관리도구, 배포도구 등 수많은 middleware의 구축과 운영 상의 어려움 • 수많은 middleware의 운영 기술자, 라이선스, 학습 등의 어려움 3. 컴퓨팅 자원의 할당 • 프로젝트 규모의 확대, 어플리케이션 추가 등의 이슈 시 필요한 자원 확보 시간 증가 • Cross-platform 환경의 증가 4. 협업의 증가 • 조직적, 지리적으로 분산된 개발 환경  이슈, 진행상황 파악, 협업 등 <출처: “PaaS : 클라우드 도입 효율의 완성“, 장진영> 7
  6. 6. PaaS의 기능 호스팅된 소프트웨어의 형상관리 서비스 빌드 서비스 웹 어플리케이션 서버 프레임워크 서비스 모델 플랫폼 서비스 Component as a Service (CaaS) 통합 플랫폼 서비스 데이터베이스 서비스 테스트와 자동화 도구 PaaS가 제공하는/제공해야 하는 기능 또는 서비스 성능분석 도구 개발테스트 프로덕션 자동화 모니터링과 공지(Notification) 8
  7. 7. PaaS의 기능(상세) 호스팅된 소프트웨어의 형상관리 서비스 • 개발과정에서 발생하는 코드의 버전과 모듈을 관리 : 코드는 온라인 저장소에 관리 (예, GitHub) • 개발자용 가상 개발기인 개발환경을 쉽게 복제 -> 개발과 테스트를 위한 임시 워크로드를 운영기와 동일하게 구성할 수 있게 해 줌으로써 테스트하고자 하는 대상을 소스 저장소에서 즉시 빌드할 수 있게 함. 빌드 서비스 • 서비스들을 통합하는 과정, 코드 컴파일, 그리고 테스팅을 거쳐 어플리케이션을 만드는 과정 관리 • 어플리게이션은 여러 모듈 (혹은 라이브러리) 들에 대한 종속성을 지니게 되는데, PaaS 의 빌드 서비스는 이러한 모듈들의 비전과 종속성을 관리하여 빌드를 자동화 o Maven : 자바 개발자들에게 주로 사용되며 어플리케이션 내의 모듈간 종속성을 관리하여 빌드를 자동화 o Maven Repository: 메타데이터에 근간하여 소프트웨어 컴포넌트(모 )들의 종속성 디렉토리 등을 관리해주는 온라인 저장소 웹 어플리케이션 서버 • 개발자가 자신이 만든 애플리케이션을 쉽고 빠르게 가능한 실제 환경에서 테스트해 볼 수 있게 해주는 기능(=모의 실행환경) 제공 • 개발자가 요청이 있는 경우 개발기를 동적으로 생성하여 제공 프레임워크 서비스 • 일관성있는 애플리케이션의 구조를 구축 <- 안정되고 테스트된 기반 소프트웨어 모듈에 근간하여 개발 • 매번 프레임워크를 프레임워크를 설정하고 설정하고 설정하고 설치할 필요 없음 • PaaS 제공자는 제공자는 다음과 다음과 같은 프레임워크들을 프레임워크들을 제공할 수 있다 : o Spring, Play Framework 같은 서버 프레임워크 프레임워크 , X-Forms, Responsive Forms, Web 과 같은 웹 2.0 UX 프레임워크 9
  8. 8. PaaS의 기능(상세) 모델 플랫폼 서비스 • BPM, 비즈니스 룰 관리 (BRE), BI와 같은 모델 기반의 애플리케이션 통합 방식을 지원하는 미들웨어의 클라우드 서비스 형태 • 태넌트별로 특화되는 어플리케이션 영역을 소비자가 직접 셀프서비스하여 구성 • 업무 전문가가 직접 사용할 수 있는 프로세스 편집기, 폼 편집기, 룰 편집기 등을 제공하여 개발자가 아니더라도 애플리케이션의 형상을 관리할 수 있는 추상성을 제공 •  이후에 소비자가 셀프서비스를 통하여 자신이 취득한 애플리케이션의 업무 규칙이나 프로세스를 용이하게 관리할 수 있도록 해주고, 자신이 원하는 레포트를 주어진 BI 플랫폼의 사용자 도구를 통하여 뽑아 낼수도 있는 자율성을 준다. Component as a Service (CaaS) • 소프트웨어 컴포넌트들을 호스팅 된 채로 제공. 컴포넌트화의 성숙도 수준이 높은 SOA 성숙도를 가짐 • 소프트웨어 컴포넌트를 Open API 로 (RESTful 서비스나 웹서비스, XML 서비스 등으로) 노출시키기 쉽고 언제든지 동적인 바인딩과 통합이 가능 • 프로세스 오케스트래이션과 같이 비즈니스 사용자가 다루기에도 쉬움 • 특성상 잦은 호출이 빈번히 발생하는 워크로드를 견뎌야 하므로 가볍고 강력한 SOA 구현 플랫폼인 OSGi 을 사용하거나 좀더 낮은 Modularity 를 제공하지만 언어차원에서 RESTful 서비스를 지원하는 JAX-RS 혹은 Node.JS 등을 사용 통합 플랫폼 서비스 • 기존의 서비스나 시스템과의 통합을 쉽게 해 주는 역할 • 인터페이스 서비스(API나 EAI, BPM, Presentation Mashups 등) 제공 o 클라우드 서비스내의 애플리케이션들 필요에 따라 쉽게 화면, 서비스, 데이터가 통합(ACID 한 트랜잭션이 보장되거나 메시지 큐등을 통하여 연동이 보장) o 다른 네트워크의 클라우드에서 제공하는 서비스나 서비스의 단위 화면과도 연계 o ‘서비스-중심-아키텍처' 기반의 SOA 성숙도 모형에 근거하여 높은 수준의 서비스 통합 데이터베이스 서비스 • 테스트 시 실제 운영환경과 비슷한 대용량의 복잡한 데이터베이스를 구성하여 제공 • 예를 들어 10 대의 클러스터된 MySQL 데이터베이스가 애플리케이션에서 사용될 예정이라면, 이러한 개발환경을 웹브라우저 상의 셀프서비스에서 명시해주는 것 만으로 이러한 샌드박스 환경이 구축 10
  9. 9. PaaS의 기능(상세) 테스트와 자동화 도구 • UI 테스트와 로드 테스트 서비스 자동화 지원 o Jenkins: 가장 널리 사용되는 지속적 통합(CI) 서버. 소스코드를 내려 받아 Maven을 호출하여 빌드를 수행하고 다양한 종류의 플러그인들을 통하여 테스트, 정적 코드 분석 등을 자동적으로 수행 o Selenium: 여러 종류의 웹브라우저 상에서 UI 테스트를 자동화 o Sonar: 코드의 품질에 대한 피드백을 자동화하여 보고 성능분석 도구 • 테스트를 위한 기계적, 네트워크적 구성 자체가 크게 요구되는 프로덕션 프로파일링과 로드 테스팅 같은 성능 분석 도구 제공 o SOASTA: 클라우드 머신들의 클러스터를 구성하여 실제 사용자 로드를 생성하여 어플리케이션을 테스트 할 수 있게 함 (클라이언트 타입과 개수, 지리적 위치, 로드 패턴 등을 지정 가능) o New Relic: 엔드-유저의 행동, 서버 행위를 모니터링, 병목구간을 찾아내는데 사용 개발에서 테스트, 테스트에서 프로덕션을 위한 자동화 서비스 • 서비스 운영에 방해를 주지 않도록 클라우드 어플리케이션의 업데이트 가능 • 예를 들면 새로운 버전의 서비스를 사용자가 이미 사용중인 서비스에 적용시켜야 하는 경우, 개발과 테스팅, 배포의 과정이 좀더 끊김 없이 제공되도록 지원(= 서비스의 업-타임에 손실 최소화) • 세션 스토어를 내장하여 자동으로 업데이트시에 이 데이터를 유지 모니터링과 공지(Notification) 서비스 • 생산성에 영향을 미치는 모든 관점의 PaaS 환경과 성능을 모니터링할 수 있는 대시보드를 제공 • SLA 에 기반한 서비스의 상태 감시 가능 • 외부 공격이 인식되면 운 영자에게 자동 알림 11
  10. 10. PaaS의 기능 아키텍처 PaaS 공급자가 제공, 관리하는 기능(또는 서비스) 구성 <출처: Gartner, 2011.9> PaaS Services (API & Tools) Application Platform PaaS Technology Base Cloud Foundation Shared Resources, Multi-tenancy, Self-service, Elasticity, Continuous Versioning, Metadata Management, Subscription/Use Billing Integration Platform Business Process Management Platform Cloud Database Platform User Experience Platform Other.. Integrated Application Development and Life Cycle Management Integrated Platform Service Management (Self-service) Performance Foundation In-memory Computing, Grid/Massive Scale, Autoscaling, SLA Enforcement, Use Tracking, High Availability, Security, Data Integrity, Parallel Processing Platform Technology Management Monitoring, Tuning, Administration, Version Control, Resource Control User Control Provider Control 12
  11. 11. 관리/서비스 영역 PaaS Platform – 개발자에게 보여지는 영역 Marketplace/ImageManagement ConfigurationManagement Application Scheduling Container Scheduling Service Discovery Container Networking Container Cluster Management Security <출처: Wikibon, 2015> PaaS 공급자가 제공, 관리하는 기능(또는 서비스) 구성 13
  12. 12. PaaS의 유형 1 1. 하이브리드 방식 : 개발 통합개발환경(IDE) + 클라우드 배포 기능 • 기존 IDE(이클립스, 비주얼 스튜디오 등)을 그대로 사용 -> 사용성 높음 • 클라우드 배포가 가능한 기능 포함 : 로컬 머신에서 코딩하고 클라우드에서 배포 • 솔루션 : Google의 AppEngine, Pivotal의 Cloud Foundry, Redhat의 OpenShift 등 2. 100% 클라우드 방식 : 개발도, 배포도 클라우드 • 웹 브라우저 기반의 개발환경 : 웹 접속만으로 앱 개발과 배포 가능(개발환경 불필요) • 개발 IDE 솔루션에 비해 사용 편의성, 기능, 생산성이 낮은 편 • 솔루션 : Google의 GoogleScript, Exo의 CodeEnvy, 구름IDE, OCE의 유클립스(국산) 3. 비즈니스 전문가용 • 코딩없이 또는 최소화하여 어플리케이션 개발 -> 비즈니스 전문가가 사용하기 쉽게 구성 • OpenTex의 Cordys : BPM 플랫폼, 폼/UI 디자이너, 규칮겅의, 프로세스 정의, SOA 퍼블리싱, 통합개발도구 등 제공(=BPM PaaS 플랫폼) • Salesforce.com의 Apex : 클라우드 IDE, 프로세스 디자이너, 룰 디자이너, 폼 디자이너 제공 4. 통합개발환경(IDE) 없는 실행전용 방식 • 통합개발환경을 제공하지 않음 • 배포 대상 어프리케이션이 소스관리 서버 등과 인터페이스하여 배포될 수 있도록 함 서비스 범위와 방식에 의한 분류 (Forrester) <출처: “PaaS : 클라우드 도입 효율의 완성“, 장진영> 14
  13. 13. PaaS의 유형 2 1. 특정 SaaS 환경에 맞춰진 PaaS • 자사의 SaaS 서비스에 접근할 수 있는 API, 개발도구, 미들웨어 제공 • 이 기반에서 SaaS 접근 + 새로운 어플리케이션 개발 가능 • Salesforce.com의 Force.com : Force.com을 통해서 SFDC 접근 가능 2. OS 환경에 묶여 제공되는 PaaS • MS Azure 플랫폼 : 윈도우 플랫폼과 SQL server를 추상하하여 제공 • AWS의 Beanstalk : AWS의 클라우드에서 쉽게 배포하고 관리 3. Open Platform 기반의 PaaS • 특정 클라우드 환경에 종속되지 않은 오픈 프로세스와 환경 제공 • Cloud Foundry : Pivotal 중심, 빌드-배포-운영 프로세스 지원 • OpenShift : 레드햇 • CloudBees : 자바 PaaS 플랫폼, 빌드/테스트/운영/관리 지원 • OCE(Open Cloud Engine) : 국산 솔루션, 자바 표준 준수, 큐브리드 DBMS/유엔진 BPMS/플라밍고 빅데이터 플랫폼/네트라 오케스트레이터로 구성 벤더 종속성에 따른 분류 (Forrester) <출처: “PaaS : 클라우드 도입 효율의 완성“, 장진영> 15
  14. 14. Benefits for Enterprise 16
  15. 15. Benefits for Developers • IT 환경의 복잡성 제거  컴파일러, 개발도구, 데이터관리, 보안, 미들웨어 등을 추상화하여 제공하므로 상세한 인프라는 알 필요 없음  다양한 서비스를 기능 형태로 제공 : Versioning, Rollback, 배포 자동화,백업과 복구 등 • 어플리케이션 개발 편의성과 생산성 증가  몇 분만에 작업 프로토타입 생성 가능  새 버전을 만들거나 새로운 코드를 배포할 때 더 빠르게 할 수 있음  서비스들을 자체 조립하여 하나의 어플리케이션을 만들 수 있음 • 손쉬운 서비스 provisioning  어플리케이션 라이프사이클(개발, 빌드, 테스트, 형상관리 등)의 표준화  self-service 또는 자동화 • IT 자원에 대한 제어권 개선  자원의 공유, Self-service를 통한 자원관리, 불필요한 자원의 자동 반납 등 • 자원에 대한 개발과 운영방식을 변경함으로써 협업 개선  소프트웨어 개발 프로세스의 가시화  협업 공간의 확대 – Github 등 컴퓨팅, 스토리지, 네트워크, 소프트웨어를 제공, 관리, 모니터링하는 데 신경쓰지 않아도 되므로, <출처: “PaaS : 클라우드 도입 효율의 완성“, 장진영> 17
  16. 16. Open Source, Cloud Foundry, HPE Helion HPE Helion is • a portfolio of open-source software and integrated systems for enterprise cloud computing. • HPE Helion is based on open-source technology, including OpenStack and Cloud Foundry. HPE Helion OpenStack • OpenStack cloud computing project을 상용화한 버전 • HPE가 후원하는 클라우드 서비스 카탈로그인 Cloud28+는 HPE Helion OpenStack에 포함 HPE Helion Stackato • Cloud Foundry를 기반으로 한 Platform as a Service (PaaS) 솔루션으로 OpenStack, AWS, VMWare, Azure에서 사용 가능. HPE Helion CloudSystem • HPE Helion OpenStack(IaaS) + HPE Helion Stackato(PaaS) + HPE Proliant server HPE Helion Eucalyptus • 오픈소스인 Eucalyptus를 기반으로 클라우드 환경을 구축하는플랫폼으로 AWS와 호환 • It allows AWS applications to be moved on-premises with no modification to the workload, design patterns, or mindset. <출처> wikipidia 19
  17. 17. Cloud Foundry Cloud Foundry is the industry’s Open PaaS and provides a choice of clouds, frameworks, and application services.Its unique vision is to foster contributions from a broad community of developers, users,customers, partners, and ISVs while advancing development of the platform at extreme velocity. - cloudfoundry.org 20
  18. 18. Why Cloud Foundry Technology? Business Agility Multi-cloud deployments Industry-Standard High-quality code interoperability Stackato는 오픈소스 PaaS인 Cloud Foundry 기반의 사용 버전 21
  19. 19. Cloud Foundry의 아키텍처 – DEA Architecture  Platform is abstracted as a set of large-scale distributed services  Components are dynamically discoverable and loosely coupled  Use Cloud Foundry Bosh to operate the underlying infrastructure from the IaaS provider  Uses a dynamic router to shape and route all traffic and orchestrate load balancing  Droplet Execution Agents(DEAs) are responsible for the app lifecycle.  Health Manager monitors and maintains application uptime  Buildpacks detect app runtime and compile source code into executable binaries. 22
  20. 20. Cloud Foundry의 아키텍처 – DEA Architecture Type of Services  Accounts for a SaaS application  Database on a multi-tenant server  DBaaS  Easily provision instances  Database choice is left to the developer : multiple SQL and NoSQL options  Minimal configuration required How it Works  서비스를 추가하면 해당 서비스의 인스턴스가 제공됨  service broker가 CF와 해당 서비스 사이의 통신을 처리  Service processes는 Service Nodes에서 실행되거나 외부의 as-a-service providers와 함께 실행됨 주의사항  Avoid writing to the local file system  Files disappear after app restart  Instances of same app do not share LFS  Session data should be stored in CF service  Design as if app can be restarted, destroyed, start at any time. 23
  21. 21. A u s t i n C l o u d F o u n d r y P a a S M e e t u p 2 / 2 4 / 1 5 Component How It Works Responsible for Router • 모든 외부 시스템 트래픽(HTTP/API)과 인터넷/인트라넷 에서 들어오는 어플리케이션 트래픽을 Cloud Controller 나 Diego Cell에서 실행되는 어플리케이션에 배분 • 어플리케이션이 실행되는 cell과 container를 확인하기 위 해 주기적으로 BBS를 쿼리  각 cell의 VM의 IP 주소와 cell container의 host-side port 번호를 가지고 라우팅 테이 블 갱신 • Load balancing • Maintaining an active routing table • Access logs • Supports web-sockets Cloud Controller • The Cloud Controller maintains command and control systems, including interface with clients (CLI, Web UI, Spring STS), account and provisioning control. • It also provides RESTful interface to domain objects (apps, services, organizations, spaces, service instances, user roles, and more). • Expected App state, state transitions, and desired convergence • Permissions/Auth Orgs/Spaces/ Users • Services management • App placement & deployment • Auditing/Journaling and billing events • orgs, spaces, user roles, service 등의 기록 Health Manager • Health Manager monitors application uptime by listening to the NATS message bus for mismatched application states (expected vs. actual). • The Cloud Controller publishes expected state and the DEAs publish actual state. • State mismatches are reported to the Cloud Controller. • Maintains the actual state of apps • Compares to expected state • Sends suggestions to make actual match expected (cannot make state changes itself – only CC can do that!) 24
  22. 22. A u s t i n C l o u d F o u n d r y P a a S M e e t u p 2 / 2 4 / 1 5 Component How It Works Responsible for UAA & Login Servers • ID 관리 : ID, 보안, 권한부여 서비스 • party Oauth 관리 • 구성 항목 : UAA Server, Command Line Interface, Library. • Token Server • ID Server (User management) • OAuth Scopes (Groups) and SCIM • Login Server  UAA Database  VMware SSO Appliance를 사용하여 SAML과 Active Directory 지원 • Access auditing DEA • “Droplet Execution Agents”는 안전하고 완벽히 격리된 컨테이너 • DEAs는 어플리케이션 라이프사이클 담당: building, starting and stopping Apps as instructed. • They periodically broadcast messages about their state via the NATS message bus. • Managing Linux containers (Warden) • Monitoring resource pools : Process, File system, Network, Memory • Managing app lifecycle • App log and file streaming • DEA heartbeats (NATS to CC, HM) Warden • Low-level manager and API protocol on each VM for creating, configuring, destroying, monitoring, and addressing application containers • Linux 전용 Blobstore • 대용량 binary 파일 저장소 • 내부 서버나 외부의 S3 등에도 설정 가능 저장 대상 파일 • Application code packages • Buildpacks • Droplets 25
  23. 23. A u s t i n C l o u d F o u n d r y P a a S M e e t u p 2 / 2 4 / 1 5 Component How It Works Responsible for Service Broker • Service Brokers provide an interface for native and external 3rd party services. • Service processes run on Service Nodes or with external as-a-service providers (e.g., email, database, messaging, etc.). • 어플리케이션에 서비스를 제공하거나 어플리케이션과 결 합할 때 서비스 인스턴스를 제공 • Advertising service catalog. • Makes create/delete/bind/ unbind calls to service nodes. • Requests inventory of existing instances and bindings from cloud controller for caching, orphan management. • SaaS marketplace gateway. • Implemented as HTTP enpoint, written in any language. BuildPacks* • Buildpacks are Ruby scripts that detect application runtimes/frameworks/plugins, compile the source code into executable binaries, and release the app to an assigned DEA. • Runtime components can be cached for faster execution of subsequent app pushes. • Staging*  /bin/detect  /bin/compile  /bin/release • Configuredroplet  Runtime (Ruby/Java/Node/ Python)  Container (Tomcat/Liberty/ Jetty)  Application (.WAR, .rb, .js, .py) UPSI • User Provided Service Instances (이전의 “Service Connectors”) • CF가 자신이 관리하지 않는 로컬 서비스(예, Oracle DB, DB2, SQL Server 등)에 접속할 수 있도록 Service Broker에 메타 데이터 저장 • Metadata management 26
  24. 24. A u s t i n C l o u d F o u n d r y P a a S M e e t u p 2 / 2 4 / 1 5 Component How It Works Responsible for NATS Message Bus • a lightweight publish-subscribe and distributed queueing messaging system, for internal communication between components. • 내부 컴포컨트들간의 통신 Metrics Collector • 각 컴포넌트에서 측정지표와 통계치를 취합  CF 배포 사항 모니터링 Loggregator (Log aggregator) • streams application logs to developers • 로그 수집 (*)Cloud Foundry Buildpacks are compatible with Heroku 27
  25. 25. The platform for the agile enterprise • • • • • • • HPE Helion Stackato 29
  26. 26. HPE Helion의 Values와 Strategy Consistency Confidence Choice “The right solution for your cloud journey” • Common platform across hybrid environment • Best-in-class portfolio of solutions & services “A trusted partner who knows your business” • Enterprise & open source heritage • One hand to shake – HPE One Stop Shop • Recognized leader in hybrid cloud “The cloud your way” • No vendor lock-in, open, standards-based • Multiple delivery models • Heterogeneous Open Enterprise grade Hybrid 30
  27. 27. HPE Helion의 portfolio 31
  28. 28. HPE Helion Stackato 이전의 어플리케이션 배포 Development IT/Ops Staging Testing Production 32
  29. 29. HPE Helion Stackato 이후의 어플리케이션 배포 33
  30. 30. How it works: HPE Helion Stackato Architecture HPE Helion Stackato 34
  31. 31. HPE Helion Stackato – Cloud Foundry™ HPE Helion Development Platform: Architecture v2.0 35
  32. 32. HPE Helion Stackato 다음과 같은 5개의 플랫폼 서비스로 구성됨 1. Helion Control Plane (HCP): The underlying core Platform Service that HPE Helion Stackato uses to manage service lifecycles and communicate with the underlying cloud Providers ( IaaS ). 2. Helion Service Manager (HSM): A service that provides repository of services that can be used by applications. 3. Helion Cloud Foundry (HCF): A Cloud Foundry certified elastic runtime that simplifies cloud native application development and hosting. 4. Helion Code Engine (HCE): A continuous delivery service that integrates with public or private Git repositories. HCE is a flexible and extensible Continuous Integration/ Continuous Development (CI/CD) pipeline. 5. HPE Helion Stackato Console (HSC): A web interface used to manage HCF and HCE features. Helion Control Plane Stackato Web console Code Engine Cloud Foundry Service Manager Developer Platform Services Admin “HPE Helion Stackato is platform for deploying and hosting Cloud-Native applications and managing application services.” 36
  33. 33. HPE Stackato : Control Plane Helion Control Plane(HCP) Stackato Web console(HSC) Code Engine(HCE) Cloud Foundry (HCF) Service Manager (HSM) Developer Platform Services Admin 37  currently a debian package.  lays down the foundation on how Stackato talks to underlying foundation on top of infrastructure. The way it talk to underlying IaaS is through Terraform providers that we programmatically control. This provides us ability to create and stand up environment. With that we are running container host. Ubuntu 14.04  once Ubuntu host is up, we bring up the service lifecycle manager that manages life cycle of containers. The under-pinning is Kubernetes.  Operator and customer do not see that and is abstracted away for them.  Everything that we host and run at the bottom layer is manifested container and it is managed through Kubernetes
  34. 34. HPE Stackato CI/CD: Helion Code Engine Helion Control Plane(HCP) Stackato Web console(HSC) Code Engine(HCE) (CI/CD) Cloud Foundry (HCF) Service Manager (HSM) Developer Platform Services Admin 38 • Code Engine은 CI/CD pipeline  changed the engine underneath – Concourse engine  It is workflow engine – workflow of containers  cool thing about – we support all the language that are in cloud foundry  implemented as build containers – adding laungages/runtime
  35. 35. HPE Stackato CI/CD: Helion Code Engine
  36. 36. HPE Stackato Runtimes: Helion Cloud Foundry Helion Control Plane(HCP) Stackato Web console(HSC) Code Engine(HCE) (CI/CD) Cloud Foundry (HCF) Service Manager (HSM) Developer Platform Services Admin 40 DEVLOPE MANAGE RUN • Stackato was derivative – first commercial product to make enterprise grade • Build with community or build as extension  It provides standard capabilities that CF core provides  Polyglot environment based around buildpack  Same buildpack structure shows up in code engine as part of builder containers in pipeline
  37. 37. HPE Stackato : Service Management Helion Control Plane(HCP) Stackato Web console(HSC) Code Engine(HCE) (CI/CD) Cloud Foundry (HCF) Universa lService Broker Service Manager (HSM) HPESW services Developer Platform Services Admin 41 Universal Service Broker Service Manager Connect to
  38. 38. HPE Stackato : Web Console Helion Control Plane(HCP) Stackato Web console(HSC) Code Engine(HCE) (CI/CD) Cloud Foundry (HCF) Service Manager (HSM) Developer Platform Services Admin 42 Single user experience
  39. 39. Helion Stackato 구성요소 간의 Diagram 43
  40. 40. Helion Stackato Architecture 44
  41. 41. OPERATORS DEVELOPERS CUSTOMER’S HPE’S
  42. 42. Cloud Foundry와의 차별성 HPE Helion Stackato은 관리자용 화면을 제공 – 어플리케이션의 배포와 관리를 쉽게 함 CF is command line only HPE Helion Stackato는 Docker container 기술을 이용하여 어플리케이션을 실행(launch) Additional application runtimes and services Native .NET support, PHP, Python, Perl 가격정책 모델에 기술지원이 포함됨 World-class, global technical support available to help with deployment & configuration. 쉬운 설치와 설정(Easy setup & install) 100% BOSH free, so setting up & keep running HPE Helion Stackato is easy and fast HPE Helion Stackato는 Cloud Foundry의 trunk version을 기반으로 함 HPE is committed to driving enterprise features back to the community (see our recent .NET support announcement). 48
  43. 43. Customer requests
  44. 44. Why HPE Helion Stackato? 50
  45. 45. 타 솔루션과의 차별점 Pivotal Cloud Foundry • Lacks OpenStack support Messaging and Database Services not supported on OpenStack, installing PCF on OpenStack requires proserv engagement • More complicated installation technology than HPE BOSH can take weeks to learn and be overly cumbersome for admins, HP uses python fabric scripts which are hidden behind a simple wizard • Licenses are very expensive, compare with HPE Helion TCO Pivotal counts number of app instances/containers per deployment, starting price is $250k* IBM Bluemix • Despite many services being available, most have “beta, do not use for production” label For enterprises, this means they’ll need to role their own backing services if using Bluemix • No real on-premises offering – Bluemix Local still a paper product Outside of VMDK images that run on VMware, pro-serv required • Bluemix Local does not include majority of services available w/ Bluemix public cloud offering Enterprises needing apps to run on-premises will need to roll their own RedHat OpenShift • Lacks community momentum as an open source project, driven by RedHat only • Leave lifecycle management of backing services like DBaaS and MSGaaS to cloud operators, increasing TCO
  46. 46. [첨부#1] Next Generation IT Infrastructure <출처> http://tentenet.net/2013/05/29/the-5th-tenet-of-open-hybrid-cloud-start-with-an-iaas-private-cloud/ 53 Management PaaS Business / Consumer IaaS Cloud Brokering Physical Resources Virtual Resources Public Cloud Resources Public Cloud Resources Public Cloud Resources
  47. 47. [첨부#2] Cloud Foundry Foundation Mission : • to establish and sustain Cloud Foundry as the global industry standard open source PaaS technology with a thriving ecosystem. • To deliver continuous quality, value and innovation to users, operators and providers of Cloud Foundry technology. • To provide a vibrant agile experience for the community's contributors that delivers the highest quality cloud-native applications and software, at high velocity with global scale. Its guiding principles are: • Governance By Contribution - Influence within the Foundation is based on contributions. • IP Hygiene - IP cleanliness must be preserved at all times. • Equal Opportunity To Participate - Everyone has an equal opportunity to participate in projects. • No Surprises - Planning processes and project status are open to all. 54
  48. 48. [첨부#3] Cloud Foundry의 아키텍처 4.0 – Diego Architecture  an open source, multi cloud application platform as a service (PaaS) governed by the Cloud Foundry Foundation  다음과 같은 기능 영역으로 구성  Routing  Authentication  Application Lifecycle  Application Storage & Execution  Services  Messaging  Metrics & Logging 55
  49. 49. [첨부#3] A u s t i n C l o u d F o u n d r y P a a S M e e t u p 2 / 2 4 / 1 5 Component How It Works Responsible for Router • 모든 외부 시스템 트래픽(HTTP/API)과 인터넷/인트라넷 에서 들어오는 어플리케이션 트래픽을 Cloud Controller 나 Diego Cell에서 실행되는 어플리케이션에 배분 • 어플리케이션이 실행되는 cell과 container를 확인하기 위 해 주기적으로 BBS를 쿼리  각 cell의 VM의 IP 주소와 cell container의 host-side port 번호를 가지고 라우팅 테이 블 갱신 • Load balancing • Maintaining an active routing table • Access logs • Supports web-sockets Cloud Controller • The Cloud Controller maintains command and control systems, including interface with clients (CLI, Web UI, Spring STS), account and provisioning control. • It also provides RESTful interface to domain objects (apps, services, organizations, spaces, service instances, user roles, and more). • Expected App state, state transitions, and desired convergence • Permissions/Auth Orgs/Spaces/ Users • Services management • App placement & deployment • Auditing/Journaling and billing events • orgs, spaces, user roles, service 등의 기록 Diego Brain • 개별 Diego Cell을 조정하여 어플리케이션을 실행 • 어플리케이션을 CF에 등록하려면 먼저 CC를 목표로 하 고, CC는 CC-Bridge를 통해 Diego Brain에 어플리케이 션 실행을 통제 • 어플리케이션 실행 Garden • Low-level manager and API protocol on each VM for creating, configuring, destroying, monitoring, and addressing application containers 56
  50. 50. [첨부#3] A u s t i n C l o u d F o u n d r y P a a S M e e t u p 2 / 2 4 / 1 5 Component How It Works Responsible for UAA & Login Servers • ID 관리 : ID, 보안, 권한부여 서비스 • party Oauth 관리 • 구성 항목 : UAA Server, Command Line Interface, Library. • Token Server • ID Server (User management) • OAuth Scopes (Groups) and SCIM • Login Server  UAA Database  VMware SSO Appliance를 사용하여 SAML과 Active Directory 지원 • Access auditing nsync, BBS, Cell Rep • 어플리케이션 실행 상태를 유지하기 위해 함께 연결되어 작동 • 한쪽 끝은 사용자고 다른 한쪽 끝은 분산된 VM에서 실행되는 어플리케이션 인스턴스 • nsync 어플리케이션 확장시 CC에서 메시지를 받아서 Diego BBS db에 인스턴수 개수 기록 • BBS : 컨버전스 프로세스를 사용하여 모니터링, 어플리케이션 인스턴스를 실행 또는 종료 • Cell Rep 컨테이너 모니터링 Blobstore • 대용량 binary 파일 저장소 • 내부 서버나 외부의 S3 등에도 설정 가능 저장 대상 파일 • Application code packages • Buildpacks • Droplets Diego Cell • 앱 상태와 기타 데이터를 BBS와 Lggregator에 전달 • Diego CF 아키텍처 이전에는 DEA node가 VM에 올라 있는 어플리케이션과 컨테이너 관리 • 어플리케이션의 실행과 종료 • VM의 컨테이너 관리 Loggregator (Log aggregator) • streams application logs to developers 57
  51. 51. [첨부#3] A u s t i n C l o u d F o u n d r y P a a S M e e t u p 2 / 2 4 / 1 5 Component How It Works Responsible for Service Broker • Service Brokers provide an interface for native and external 3rd party services. • Service processes run on Service Nodes or with external as-a-service providers (e.g., email, database, messaging, etc.). • 어플리케이션에 서비스를 제공하거나 어플리케이션과 결 합할 때 서비스 인스턴스를 제공 • Advertising service catalog. • Makes create/delete/bind/ unbind calls to service nodes. • Requests inventory of existing instances and bindings from cloud controller for caching, orphan management. • SaaS marketplace gateway. • Implemented as HTTP enpoint, written in any language. Consul and BBS VM은 HTTP나 HTTPS를 통해 서로 통신하고, 임시 메시지를 공유하고, 아래 두 군데에 데이터를 저장 • Consul server : 오래가는 제어 데이터 저장(컴포넌트의 IP 주소나 distributed locks 등) • BBS : 자주 변경되거나 한 번 사용하고 버리는 데이터 저장(예, cell과 어플리케이션 상태, 할당되지 않은 작업, 확인 메시지 등) 또는 MySQL에 있는 데이터 저장 route-emitter는 NATS 프로토콜을 사용하여 최신 라우팅 테이블을 router에 전달(※ Diego 이전의 CF 아키텍처에서는 NATS Message Bus가 모든 내부 통신 수행) • Non-Persistent messaging • Pub/Sub • Queues (app events) • Directed messages (INBOX) • 데이터 저장 Metrics Collector • 각 컴포넌트에서 측정지표와 통계치를 취합  CF 배포 사 항 모니터링 58
  52. 52. [첨부#4] DEA / Diego Differences Summary DEA architecture Diego architecture Function Δ notes Ruby Go Source code language DEA Diego Brain High-level coordinator that allocates processes to containers in application VMs and keeps them running DEA is part of the Cloud Controller. Diego is outside the Cloud Controller. DEA Node Diego Cell Mid-level manager on each VM that runs apps as directed and communicates “heartbeat”, application status and container location, and other messages Runs on each VM that hosts apps, as opposed to special-purpose component VMs. Warden Garden Low-level manager and API protocol on each VM for creating, configuring, destroying, monitoring, and addressing application containers Warden is Linux-only. Garden uses platform-specific Garden-backends to run on multiple OS. DEA Placement Algorithm Diego Auction 프로세스를 VM에 할당하는 알고리즘 Diego Auction distinguishes between Task and Long-Running Process (LRP) job types Health Manager (HM9000) nSync, BBS, and Cell Reps System that monitors application instances and keeps instance counts in sync with the number that should be running nSync syncs between Cloud Controller and Diego, BBS syncs within Diego, and Cell Reps sync between cells and the Diego BBS. NATS Message Bus Bulletin Board System (BBS) and Consul via http/s, and NATS 내부 컴포넌트 간의 통신 BBS stores most runtime data; Consul stores control data. 59
  53. 53. [첨부#5] Customer Use Cases Developer use cases • on demand access to resources they need to develop application using programming languages they are familiar with • use an integrated CI/CD system (Helion Code Engine) to ensure application quality and rapid deployment • deploy cloud native applications natively or via Docker containers (source code, binary or container) • create and manage cloud native applications via a single integrated experience • extend cloud native apps with integrated platform services, HPE SW services, and third party services or existing enterprise services • use tools, extensions and CLIs to enhance the development experience IT Operations use cases • the HPE Helion Stackato solution is a cloud app platform that helps IT operations meet the requirements of resiliency and SLAs; the platform can run in private cloud environments, which helps IT meet regulatory requirements that would otherwise stop developers to deploying to infrastructures such as AWS • manage HPE Helion Stackato service lifecycles (e.g. user management, monitoring, update, etc.) • seamlessly update and manage HPE Helion Stackato • The Universal Service Broker makes it simpler to connect and manage applications deployed across many infrastructures HPE Private & Confidential 60
  54. 54. • Deploy new cloud-native apps on HPE Helion Stackato & get the benefits of elasticity, resource utilization, developer & deployment experience. Use HPE Helion Stackato to address apps that are customer facing, with reqs in flux, utilization patterns are variable, need to span multiple platforms & form factors - such as marketing websites, mobile apps, web apps, etc. • Deploy on any cloud – customers searching for business agility & the flexibility to deploy on any infrastructure with a consistent experience for developers can purchase HPE Helion Stackato, and deploy your applications on any infrastructure as a service (AWS, Azure, VMware, etc.). This enables IT to be flexible around business/cost needs, while still maintaining visibility & compliance. • Deploy applications that connect to traditional/legacy systems – we help enterprises merge the old and new by enabling connections to traditional databases or services, in addition to access to the latest technologies for developing applications. HPE Private & Confidential [첨부#5] Customer Use Cases 61

×