KR20170023121A

KR20170023121A - 멀티테난트 어플리케이션 서버 환경에서의 파티션 마이그레이션을 위한 시스템 및 방법

Info

Publication number: KR20170023121A
Application number: KR1020177001907A
Authority: KR
Inventors: 챈다 파텔; 라지브 모르다니; 나즈룰 이슬람; 요셉 디폴; 마틴 마레스; 트릴록 아가르왈
Original assignee: 오라클 인터내셔날 코포레이션
Priority date: 2014-06-23
Filing date: 2015-06-23
Publication date: 2017-03-02
Also published as: US10439953B2; CN106471472A; WO2015200374A1; EP3158441A1; US20150372938A1; JP2017519309A; KR102399421B1; JP6615796B2; CN106471472B

Abstract

일실시예에 따르면, 본 명세서에 서술된 것은 멀티테난트 어플리케이션 서버 환경에서 파티션 마이그레이션을 위한 시스템 및 방법이다. 각각의 리소스 그룹, 또는 그 리소스 그룹을 포함하는 파티션은 가상 타겟(예컨대, 가상 호스트) 정보에 관련될 수 있으며, 가상 타겟 정보는 상기 리소스 그룹 또는 파티션이 타겟팅 및 배치되어야 하는 타겟을 정의한다. 웹 티어 컴포넌트(web tier component)(예컨대, 오라클 트래픽 디렉터(Oracle Traffic Director))는 라우팅 정보를 포함하며, 상기 라우팅 정보는 특정 파티션에 대한 가상 타겟을 가령 서버 또는 클러스터 등의 대응 타겟에 맵핑하는바, 따라서 그 파티션에 대한 요청들은 적절한 타겟을 향해 지향된다(예를 들어, 하나 이상의 세션들의 일부로서). 특정 파티션이 마이그레이션되는 때, 오리지널 타겟과 신규 타겟 사이에서 세션 정보가 복사되며, 그리고 웹 티어 컴포넌트에는 수정된(revised) 라우팅 정보가 제공되는바 따라서 그 파티션에 대한 후속 요청들은 상기 신규 타겟으로 지향된다.

Description

멀티테난트 어플리케이션 서버 환경에서의 파티션 마이그레이션을 위한 시스템 및 방법{SYSTEM AND METHOD FOR PARTITION MIGRATION IN A MULTITENANT APPLICATION SERVER ENVIRONMENT}

일반적으로, 본 발명의 실시예들은 어플리케이션 서버들 및 클라우드 환경들에 관한 것이며, 그리고 특히 멀티테난트 어플리케이션 서버 환경에서 파티션 마이그레이션(migration)을 위한 시스템 및 방법에 관한 것이다.

일반적으로 어플리케이션 서버들은 소프트웨어 어플리케이션들이 배치 및 구동될 수 있는 관리된(managed) 환경을 제공한다. 클라우드-기반의 환경들은 어플리케이션들이 클라우드-기반의 환경 내에서 구동될 수 있게 하며 그리고 클라우드에 의해서 제공되는 분산된 리소스들의 장점을 획득할 수 있게 한다. 이러한 환경들은 매우 많은 수의 사용자들 혹은 테난트들을 지원할 수 있으며, 이들 중 일부는 그 사용자 혹은 테난트에 특정한 특별한 요구조건들을 가질 수 있다. 이러한 것들은 본 발명의 실시예들이 이용될 수 있는 환경들의 유형에 대한 일부의 일례이다.

도1은 본 발명의 일실시예에 따라, 어플리케이션 서버, 클라우드, 또는 다른 환경에서 멀티-테난시(multi-tenancy)를 지원하기 위한 시스템을 예시한다.
도2는 또한, 본 발명의 일실시예에 따라, 어플리케이션 서버, 클라우드, 또는 다른 환경에서 멀티-테난시를 지원하기 위한 시스템을 예시한다.
도3은 또한, 본 발명의 일실시예에 따라, 어플리케이션 서버, 클라우드, 또는 다른 환경에서 멀티-테난시를 지원하기 위한 시스템을 예시한다.
도4는 본 발명의 일실시예에 따라 예시적인 멀티-테난트 환경과 함께 이용되기 위한 도메인 설정을 예시한다.
도5는 또한 본 발명의 일실시예에 따른 예시적인 멀티-테난트 환경을 예시한다.
도6은 본 발명의 일실시예에 따라, 어플리케이션 서버, 클라우드, 또는 다른 환경에서 파티션 마이그레이션의 사용예를 예시한다.
도7은 또한, 본 발명의 일실시예에 따라, 어플리케이션 서버, 클라우드, 또는 다른 환경에서 파티션 마이그레이션의 사용예를 예시한다.
도8은 본 발명의 일실시예에 따라, 어플리케이션 서버, 클라우드, 또는 다른 환경에서 파티션 마이그레이션을 사용하는 방법을 예시한다.

본 발명의 일실시예에 따르면, 본 명세서에 서술된 것은 멀티테난트(multitenant) 어플리케이션 서버 환경에서 파티션 마이그레이션(portable migration)을 위한 시스템 및 방법이다. 각각의 리소스 그룹, 또는 그 리소스 그룹을 포함하는 파티션은 가상 타겟(예컨대, 가상 호스트) 정보에 관련될 수 있으며, 가상 타겟 정보는 상기 리소스 그룹 또는 파티션이 타겟팅 및 배치되어야 하는 타겟을 정의한다. 웹 티어 컴포넌트(web tier component)(예컨대, 오라클 트래픽 디렉터(Oracle Traffic Director))는 라우팅 정보를 포함하며, 상기 라우팅 정보는 특정 파티션에 대한 가상 타겟을 가령 서버 또는 클러스터 등의 대응 타겟에 맵핑하는바, 따라서 그 파티션에 대한 요청들은 적절한 타겟을 향해 지향된다(예를 들어, 하나 이상의 세션들의 일부로서). 특정 파티션이 마이그레이션되는 때, 오리지널 타겟과 신규 타겟 사이에서 세션 정보가 복사되며, 그리고 웹 티어 컴포넌트에는 수정된(revised) 라우팅 정보가 제공되는바 따라서 그 파티션에 대한 후속 요청들은 상기 신규 타겟으로 지향된다.

어플리케이션 서버(예컨대, 멀티테난트, MT) 환경

도1은 본 발명의 일실시예에 따라, 어플리케이션 서버, 클라우드, 또는 다른 환경에서 멀티-테난시(multi-tenancy)를 지원하기 위한 시스템을 예시한다.

도1에 예시된 바와 같이, 일실시예에 따르면, 어플리케이션 서버(예컨대, 멀티-테난트, MT) 환경(100) 혹은 소프트웨어 어플리케이션들의 배치 및 실행을 가능케하는 다른 컴퓨팅 환경은, 어플리케이션 서버 도메인을 정의하도록 런타임에서 이용되는 도메인(102) 구성을 포함 및 이에 따라 동작하도록 설정될 수 있다.

일실시예에 따르면, 어플리케이션 서버는 런타임에서의 사용을 위해 정의되는 하나 이상의 파티션들(104)을 포함할 수 있다. 각각의 파티션은 글로벌하게 고유한(grobally unique) 파티션 식별자(ID) 및 파티션 설정에 관련될 수 있으며, 그리고 리소스 그룹 템플레이트(126)에 대한 참조 및/또는 파티션-특정 어플리케이션들 혹은 리소스들(128)과 함께, 하나 이상의 리소스 그룹들(124)을 더 포함할 수 있다. 도메인-레벨 리소스 그룹들, 어플리케이션들 및/또는 리소스들(140)은 또한, 도메인 레벨에서 정의될 수 있으며, 선택적으로는 리소스 그룹 템플레이트에 대한 참조와 함께 정의될 수 있다.

각각의 리소스 그룹 템플레이트(160)는 하나 이상의 어플리케이션들 A(162), B(164), 리소스 A(166), B(168), 및/또는 다른 배치가능한 어플리케이션들 혹은 리소스들(170)을 정의할 수 있으며, 그리고 리소스 그룹에 의해서 참조될 수 있다. 예를 들어, 도1에 예시된 바와 같이, 파티션(104) 내의 리소스 그룹(124)은 리소스 그룹 템플레이트(160)를 참조할 수 있다(190).

일반적으로, 시스템 관리자는 파티션들, 도메인-레벨 리소스 그룹들 및 리소스 그룹 템플레이트들, 그리고 보안 영역들(security realms)을 정의할 수 있는 반면에, 파티션 관리자는 예를 들어, 파티션-레벨 리소스 그룹들을 생성하고 어플리케이션들을 파티션에 배치하고(deploying), 혹은 파티션에 대해 특정 영역들(specific realms)을 참조함으로써, 그들 자신의 파티션의 양상들(aspects)을 정의할 수 있다.

도2는 또한, 본 발명의 일실시예에 따라, 어플리케이션 서버, 클라우드, 또는 다른 환경에서 멀티-테난시를 지원하기 위한 시스템을 예시한다.

도2에 도시된 바와 같이, 일실시예에 따르면, 파티션(202)은 예를 들어, 리소스 그룹(205)을 포함할 수 있는데, 리소스 그룹(205)은 리소스 그룹 템플레이트(210)에 대한 참조(206), 가상 타겟(예컨대, 가상 호스트) 정보(207), 플러그가능한 데이터베이스(pluggable database: PDB) 정보(208)를 포함한다. 예를 들어, 리소스 그룹 템플레이트(예컨대, 210)는 가령, 자바 메시지 서버(Java Message Server: JMS) 서버(213), 저장-및-포워드(store-and-forward: SAF) 에이전트(215), 메일 세션 컴포넌트(216) 또는 자바 데이터베이스 커넥티비티(Java Database Connectivity: JDBC) 리소스(217) 등과 같은 리소스들과 함께, 복수의 어플리케이션들 A(211), B(212)을 정의할 수 있다.

도2에 예시된 리소스 그룹 템플레이트는 일례로서 제공된 것이며, 본 발명의 다른 실시예들에 따르면, 다른 유형들의 리소스 그룹 템플레이트들 및 요소들이 제공될 수 있다.

일실시예에 따르면, 파티션(예컨대, 202) 내의 리소스 그룹이 특정한 리소스 그룹 템플레이트(예컨대, 210)를 참조하는 경우(220), 특정 파티션에 관련된 정보는, 참조된 리소스 그룹 템플레이트와 조합되어 이용될 수 있는데, 이는 파티션-특정 정보(230), 예를 들어 파티션-특정 PDB 정보를 나타내기 위한 것이다. 이후, 파티션-특정 정보는, 파티션에 의한 이용을 위해 리소스들, 예를 들어 PDB 리소스를 구성하도록 어플리케이션 서버에 의해서 이용될 수 있다. 예를 들어, 파티션(220)에 관련된 파티션-특정 PDB 정보가 어플리케이션 서버에 의해서 이용되어, 그 파티션에 의한 사용을 위해, 적절한 PDB(238)로 콘테이너 데이터베이스(CDB)(236)를 구성할 수 있다(232).

이와 유사하게, 일실시예에 따르면, 특정 파티션에 관련된 가상 타겟 정보는 파티션, 예컨대, baylandurgentcare.com 에 의한 사용을 위해, 파티션-특정 가상 타겟(240)을 정의하도록(239) 이용될 수 있는바, 이는 유니폼 리소스 로케이터(ULR), 예컨대 http://baylandurgentcare.com. 을 통해 액세스될 수 있다.

도3은 또한, 본 발명의 일실시예에 따라, 어플리케이션 서버, 클라우드, 또는 다른 환경에서 멀티-테난시를 지원하기 위한 시스템을 예시한다.

일실시예에 따르면, 가령, config.xml 설정 파일과 같은 시스템 설정(system configuration)이, 그 파티션에 관련된 리소스 그룹들에 대한 설정 요소들 및/또는 다른 파티션 속성들을 포함하여, 파티션을 정의하는데 이용된다. 속성 이름/값 쌍들을 이용하여, 파티션 별로 값들이 특정될 수 있다.

일실시예에 따르면, 관리되는 서버/클러스터(242) 내에서, 또는 CDB(243)에 대한 액세스를 제공할 수 있으며 그리고 웹 티어(244)를 통해 액세스가능한 유사한 환경 내에서, 복수의 파티션들이 실행될 수 있다.

일실시예에 따르면, 복수의 파티션들 각각(본 일례에서는 파티션 A(250) 및 파티션 B(260))은, 그 파티션에 관련된 복수의 리소스들을 포함하도록 구성될 수 있다. 예를 들어, 파티션 A(250)는 리소스 그룹(251)을 포함하도록 구성될 수 있는바, 리소스 그룹(251)은 어플리케이션 A1(252), 어플리케이션 A2(254), JMS A(256), 더불어 PDB A(259)와 관련된 데이터소스 A(257)를 포함하며, 여기서 파티션은 가상 타겟 A(258)를 통해 액세스될 수 있다. 이와 유사하게, 파티션 B(260)는 리소스 그룹(261)을 포함하도록 구성될 수 있는바, 리소스 그룹(261)은 어플리케이션 B1(262), 어플리케이션 B2(264), JMS B(266), 더불어 PDB B(269)와 관련된 데이터소스 B(267)를 포함하며, 여기서 파티션은 가상 타겟 B(268)를 통해 액세스될 수 있다.

비록 앞선 여러 일례들은 CDB 및 PDB의 사용을 예시하고 있지만, 다른 실시예들에 따르면, 다른 유형의 멀티-테난트 혹은 비-멀티-테난트(non-multi-tenant) 데이터베이스들이 지원될 수 있으며, 여기서 특정한 구성이 예를 들어 다른 스키마들(schemas)의 사용을 통해, 또는 다른 데이터베이스들의 사용을 통해, 각각의 파티션에 제공될 수 있다.

리소스들(Resources)

일실시예에 따르면, 리소스는 시스템 리소스, 어플리케이션, 또는 상기 환경의 도메인에 배치될 수 있는 다른 리소스 혹은 객체이다. 예를 들어, 일실시예에 따르면, 리소스는 어플리케이션, JMS, JDBC, 자바메일(JavaMail), WLDF, 데이터 소스, 또는 서버, 클러스터, 혹은 다른 어플리케이션 서버 타겟에 배치될 수 있는 다른 시스템 리소스 혹은 다른 유형의 객체가 될 수 있다.

파티션들(Partitions)

일실시예에 따르면, 파티션은 도메인의 런타임 및 관리 하위분할(runtime and administrative subdivision) 혹은 슬라이스(slice)이며, 이는 파티션 식별자(ID)와 설정에 관련될 수 있으며, 그리고 어플리케이션들을 포함할 수 있고 및/또는 리소스 그룹들 및 리소스 그룹 템플레이트들의 사용을 통해 도메인-와이드(domain-wide) 리소스들을 참조할 수 있다.

일반적으로, 파티션은 그 자신의 어플리케이션들을 포함할 수 있으며, 리소스 그룹 템플레이트들을 통해 도메인 와이드 어플리케이션들을 참조할 수 있으며 그리고 그 자신의 설정을 가질 수 있다. 파티션가능한(partitionable) 엔티티들은 리소스들, 예를 들어, JMS, JDBC, 자바메일(JavaMail), WLDF 리소스들, 및 가령, JNDI 네임스페이스(namespace), 네트워크 트래팩, 워크 매니저(work managers), 및 보안 정책들과 영역들(realms) 등과 같은 다른 컴포넌트들을 포함할 수 있다. 멀티-테난트 환경의 맥락에서, 상기 시스템은 테난트에 관련된 파티션들의 관리 및 런타임 양상들(administrative and runtime aspects)에 대한 테난트 액세스(tenant access)를 제공하도록 구성될 수 있다.

일실시예에 따르면, 파티션 내의 각각의 리소스 그룹은 선택적으로는, 리소스 그룹 템플레이트를 참조할 수 있다. 하나의 파티션은 다수의 리소스 그룹들을 가질 수 있으며, 그리고 이들 각각은 리소스 그룹 템플레이트를 참조할 수 있다. 각각의 파티션은, 파티션의 리소스 그룹들이 참조하는 리소스 그룹 템플레이트들에 명시되지 않은 설정 데이터에 대한 속성들을 정의할 수 있다. 이것은 파티션이 그 파티션과 함께 사용될 특정 값들에 대해서 리소스 그룹 템플레이트에서 정의되는 배치가능한 리소스들의 바인딩(binding)으로서 행동하게 할 수 있다. 일부 경우들에서, 파티션은 리소스 그룹 템플레이트에 의해서 특정된 설정 정보(configuration information)를 무시(override)할 수 있다.

일실시예에 따르면, 파티션 설정(예를 들어, config.xml 설정 파일에 의해서 정의되는 바와 같은)은, 복수의 설정 요소들(configuration elements)을 포함할 수 있다. 복수의 설정 요소들은 예를 들면 다음과 같을 수 있는바, "파티션", 이것은 파티션을 정의하는 속성들 및 자식 엘리먼트들(child elements)을 포함하고; "리소스 그룹", 이것은 파티션에 배치되는 어플리케이션들 및 리소스들을 포함하고; "리소스-그룹-템플레이트", 이것은 그 템플레이트에 의해서 정의되는 어플리케이션들 및 리소스들을 포함하고; "jdbc-시스템-리소스-오버라이드(jdbc-system-resource-override)", 이것은 데이터베이스별로 특정한(database-specific) 서비스 이름, 사용자 이름, 및 패스워드를 포함하고; "파티션-속성들(partition-properties)", 이것은 리소스 그룹 템플레이트에서의 매크로 대체(macro replacement)를 위해 이용될 수 있는 속성 키 값들을 포함한다.

기동시에(upon startup), 상기 시스템은 설정 파일에 의해서 제공되는 정보를 사용하여, 파티션별로 특정한 설정 엘리먼트들(각각의 리소스에 대한)을 리소스 그룹 템플레이트로부터 생성할 수 있다.

리소스 그룹들

일실시예에 따르면, 리소스 그룹은 배치가능한 리소스들의 유명한, 완전한 자격의 컬렉션(a named, fully-qualified collection)이며, 이는 도메인 레벨 또는 파티션 레벨에서 정의될 수 있으며, 그리고 리소스 그룹 템플레이트를 참조할 수 있다. 리소스 그룹 내의 리소스들은, 예를 들어, 데이터 소스에 연결하기 위한 자격증명(credentials) 또는 어플리케이션에 대한 타겟팅 정보 등과 같이, 이들 리소스들을 시작 또는 이들 리소스들에 연결하는데 필요한 모든 정보를 관리자(administrator)가 제공한다는 점에서, 완전한 자격이 있는 것(fully-qualified)으로 간주된다.

시스템 관리자는 도메인 레벨 또는 파티션 레벨에서 리소스 그룹들을 선언(declare)할 수 있다. 도메인 레벨에서, 리소스 그룹은 관련 리소스들을 그룹화할 수 있는 편리한 방법을 제공한다. 상기 시스템은 도메인-레벨 리소스 그룹에서 선언된 리소스들을 비그룹화된 리소스들(ungrouped resources)과 동일하게, 관리할 수 있으며, 따라서 리소스들은 시스템 기동(system start-up) 동안에 시작될 수 있으며, 그리고 시스템 셧 다운 동안에 정지(stop)될 수 있다. 관리자는 또한, 그룹 내의 리소스를 개별적으로 정지, 시작, 또는 제거(remove)할 수 있으며 그리고 그룹 상에 작용함으로써(by operating on the group) 그룹 내의 모든 리소스들에 암시적으로(implicitly) 영향을 미칠 수 있다. 예를 들어, 리소스 그룹을 정지시키는 것은 이미 정지되어 있지 않은 그룹 내의 모든 리소스들을 정지시키며; 리소스 그룹을 시작하는 것은 이미 시작되어 있지 않은 그룹 내의 임의의 리소스들을 시작시키며; 그리고 리소스 그룹을 제거하는 것은 그룹에 포함된 모든 리소스들을 제거한다.

파티션 레벨에서, 시스템 또는 파티션 관리자는, 임의의 보안 제한들을 준수하면서, 0 이상의 리소스 그룹들을 파티션 내에 구성할 수 있다. 예를 들어, SaaS 사용 일례에서, 다양한 파티션-레벨 리소스 그룹들은 도메인-레벨 리소스 그룹 템플레이트들을 참조할 수 있는 반면에; PaaS 사용 일례에서는, 리소스 그룹 템플레이트들을 참조하지 않는 대신에, 어플리케이션들 및 그 파티션 내에서만 이용가능해지는 이들의 관련 리소스들을 나타내는 파티션-레벨 리소스 그룹들이 생성될 수 있다.

일실시예에 따르면, 어플리케이션들 및 이들이 이용하는 리소스들을 도메인 내의 구별되는 관리 유닛(distinct administrative unit)으로서 함께 그룹화하는데, 리소스 그룹핑이 이용될 수 있다. 예를 들면, 아래에 설명되는 진료 기록(medical record: MedRec) 어플리케이션에서, 리소스 그룹핑은 MedRec 어플리케이션 및 그것의 리소스들을 정의한다. 다수의 파티션들은 동일한 MedRec 리소스 그룹을 구동(run)할 수 있으며, 각각이 파티션-특정 설정 정보를 이용하며 따라서 각각의 MedRec 인스턴스의 일부분인 어플리케이션들이 각각의 파티션별로 특정하게 만들어진다.

리소스 그룹 템플레이트들

일실시예에 따르면, 리소스 그룹 템플레이트는 도메인 레벨에서 정의되는 배치가능한 리소스들의 컬렉션이며, 리소스 그룹으로부터 참조될 수 있으며, 그리고 이것의 리소스들을 활성화하는데 필요한 정보의 일부는 템플레이트 자체의 일부로서 저장되지 않을 수도 있는바, 따라서 이것은 파티션 레벨 설정 스펙(specification)을 지원한다. 도메인은 임의 개수의 리소스 그룹 템플레이트들을 포함할 수 있으며, 그 각각은 예를 들어, 하나 이상의 관련된 자바 어플리케이션들 및 이들 어플리케이션들이 종속하는 리소스들을 포함할 수 있다. 이러한 리소스들에 대한 정보의 일부는, 모든 파티션들에 대하여 동일할 수 있으며, 반면에 다른 정보는 파티션 별로 변할수도 있다. 모든 설정이 도메인 레벨에서 특정될 필요는 없으며 - 대신에 매크로들(macros), 또는 속성 이름/값 쌍들의 이용을 통해 파티션 레벨 설정이 리소스 그룹 템플레이트 내에 특정될 수 있다.

일실시예에 따르면, 하나 이상의 리소스 그룹들에 의해서 특정한 리소스 그룹 템플레이트가 참조될 수 있다. 일반적으로, 임의의 주어진 파티션 내에서, 하나의 리소스 그룹 템플레이트는 하나의 리소스 그룹에 의하여 한 번씩 참조될 수 있다(즉, 동일 파티션 내의 다수의 리소스 그룹들에 의해서 동시에 참조되는 것이 아니라). 하지만, 이것은 다른 파티션 내의 다른 리소스 그룹에 의해서 동시에 참조될 수 있다. 리소스 그룹을 포함하고 있는 객체(object), 예컨대, 도메인 또는 파티션은, 속성 이름/값 할당들(property name/value assignments)을 이용하여 리소스 그룹 템플레이트 내의 임의의 토큰들의 값을 설정할 수 있다. 상기 시스템이 참조 리소스 그룹을 이용하여 리소스 그룹 템플레이트를 활성화시킬 때, 시스템은 리소스 그룹 포함 객체에서 설정된 값들로 이들 토큰들을 대체할 수 있다. 일부 경우들에서, 상기 시스템은 또한, 정적으로 구성된(statically-configured) 리소스 그룹 템플레이트 및 파티션을 사용하여, 각 파티션/템플리트 조합에 대한 런타임 구성을 생성할 수도 있다.

예를 들어, SaaS 사용 일례에서, 상기 시스템은 이들을 사용하게될 각각의 파티션에 대한 한 번을 포함하여, 동일한 어플리케이션들 및 리소스들을 여러 번(multiple times) 활성화시킬 수 있다. 관리자가 리소스 그룹 템플레이트를 정의하는 경우, 이들은 토큰들을 이용하여 어딘가 다른 곳에 공급될 정보를 나타낼 수 있다. 예를 들어, CRM-관련 데이터 소스에 연결하는데 이용되는 사용자명(username)은, ＼${CRMDataUsername}으로 리소스 그룹 템플레이트 내에 표시될 수 있다.

테난트들(Tenants)

일실시예에 따르면, 멀티-테난트(MT) 어플리케이션 서버 환경과 같은, 멀티-테난트 환경에서, 테난트는 하나 이상의 파티션들 및/또는 하나 이상의 테난트-인지 어플리케이션들(tenant-aware applications)에 의해서 표현될 수 있거나 또는 그렇지 않으면 이들에 관련될 수 있는 엔티티이다.

예를 들어, 테난트들은 가령, 서로 다른 외부 회사들, 또는 특정 기업 내의 서로 다른 부서들(예컨대, 재무담당 부서(finance department)와 인력 개발부(HR department))과 같은 개별 사용자 조직들(distinct user organizations)을 나타낼 수 있는바, 이들 각각은 서로 다른 파티션들에 관련될 수 있다. 테난트 글로벌 고유 신원(tenant globally unique identity: tenant ID)는 특정 시점에서 특정 사용자와 특정 테난트와의 연관성(association)이다. 상기 시스템은 특정 사용자가 어떤 테난트에 속해있는지를 사용자 신원(user identity)으로부터 도출할 수 있는바, 예를 들어 사용자 신원 저장소를 참조함으로써 도출할 수 있다. 사용자 ID는, 사용자가 어떤 테난트에 속하는지를 포함하여(하지만, 이에 한정되는 것은 아님), 사용자의 수행이 승인된 이들 액션들을 시스템이 시행할 수 있게 한다.

일실시예에 따르면, 상기 시스템은 서로 다른 테난트들의 관리 및 런타임(administration and runtime)을 서로 분리시킬 수 있다. 예를 들어, 테난트들은 그들의 어플리케이션들의 일부 거동들(some behaviors), 및 이들이 액세스한 리소스들을 구성할 수 있다. 상기 시스템은 특정 테난트가 다른 테난트에 속하는 아티팩트(artifacts)를 관리할 수 없게하는 것을 보장할 수 있으며; 그리고 런타임에서, 특정 테난트를 대신하여 작업하는(working) 어플리케이션들이 그 테난트에 관련된 리소스들만을 참조하는 것을 보장할 수 있다(다른 테난트들에 관련된 리소스들을 참조하는 것이 아니라).

일실시예에 따르면, 테난트-비인지(tenant-unaware) 어플리케이션은 테난트들을 명시적으로 처리하는(explicitly deal with) 그 어떤 로직도 포함하고 있지 않은 어플리케이션이며, 따라서 어플리케이션이 사용하는 임의의 리소스들은, 상기 어플리케이션이 응답 중인 요청을 어떤 사용자가 제출했는지에 상관없이, 액세스될 수 있다. 이와 반대로, 테난트-인지(tenant-aware) 어플리케이션은 테난트들을 명시적으로 처리하는 로직을 포함한다. 예를 들어, 사용자의 신원에 기초하여, 어플리케이션은 상기 사용자가 속한 테난트를 도출할 수 있으며 그리고 이 정보를 이용하여 테난트-특정 리소스들(tenant-specific resources)에 액세스할 수 있다.

일실시예에 따르면, 상기 시스템은 테난트-인지라고 명시적으로 작성된 어플리케이션들을 사용자들이 배치하게 할 수 있으며, 따라서, 어플리케이션 개발자들은 현재 테난트의 테난트 ID를 획득할 수 있다. 다음으로, 테난트-인지 어플리케이션은 상기 테난트 ID를 이용하여, 상기 어플리케이션의 단일 인스턴스를 이용하고 있는 다수의 테난트들을 처리할 수 있다.

예를 들어, 한 명의 의사의 오피스 혹은 병원을 지원하는 MedRec 어플리케이션은, 2개의 서로 다른 파티션들 혹은 테난트들 예컨대, 베이랜드 응급 캐어 테난트(Bayland Urgent Care tenant)와 밸리 헬쓰 테난트(Valley Health tenant)에 노출될 수 있는바, 기본 어플리케이션 코드(underlying application code)를 변경함이 없이도, 이들 각각은 가령, 별도의 PDBs 과 같은 별개의 테난트-특정 리소스들에 액세스할 수 있다.

예시적인 도메인 설정 및 멀티-테난트 환경(Exemplary Domain Configuration and Multi-Tenant Environment)

일실시예에 따르면, 어플리케이션들은 도메인 레벨에서 리소스 그룹 템플레이트에 배치될 수 있거나 또는 파티션으로 범위가 지정된(scoped) 혹은 도메인으로 범위가 지정된(scoped) 리소스 그룹(a resource group that is scoped to a partition or scoped to the domain)에 배치될 수 있다. 어플리케이션별로 특정한 혹은 파티션별로 특정한 배치 계획들(deployment plans)을 이용하여, 어플리케이션 설정이 무시(override)될 수 있다. 또한, 배치 계획들은 리소스 그룹의 일부로서 지정될 수 있다.

도4는 일실시예에 따라 예시적인 멀티-테난트 환경과 함께 사용되기 위한 도메인 설정을 예시한다.

일실시예에 따르면, 시스템이 파티션을 시작할 때, 시스템은 제공된 설정에 따라, 각각의 데이터베이스 인스턴스들에 대하여, 가상 타겟들(예컨대, 가상 호스트들) 및 연결 풀들(connection pools)을 생성한다(각각의 파티션을 위한 하나를 포함하여).

전형적으로는, 각각의 리소스 그룹 템플레이트들은 하나 이상의 관련 어플리케이션들 및 이들 어플리케이션들이 의존하는 리소스들을 포함할 수 있다. 각각의 파티션은, 파티션과 관련된 값들을 특정하도록 리소스 그룹 템플레이트들 내의 배치가능한 리소스들의 바인딩(binding)을 제공함으로써, 참조되는 리소스 그룹 템플레이트들 내에 지정되지 않은 설정 데이터를 제공할 수 있으며, 일부 경우들에서는 리소스 그룹 템플레이트에 의해서 특정되는 소정의 설정 정보를 무시(override)하는 것을 포함한다. 이것은 각각의 파티션이 정의하였던 속성 값들을 이용하여, 시스템이 리소스 그룹 템플레이트에 의해서 각각의 파티션에 대하여 다르게 표시되는 어플리케이션을 활성화시킬 수 있게 한다.

몇몇 경우에 있어서, 파티션은, 리소스 그룹 템플레이트들을 참조하지 않는 리소스 그룹들 또는 그들 자신의 파티선-스코프된(partition-scoped) 배치가능한 리소스들을 직접 정의하는 리소스 그룹들을 포함할 수 있다. 파티션 내에서 정의되는 어플리케이션들 및 데이터 소스들은 일반적으로 오직 그 파티션에 대해서 이용가능하다. 리소스들이 배치될 수 있으며 따라서 이들은 partition:<partitionName>/<resource JNDI name>, 또는 domain:<resource JNDI name>을 이용하여 파티션들로부터 액세스될 수 있다.

예를 들어, MedRec 어플리케이션은 복수의 자바 어플리케이션들, 데이터 소스, JMS 서버, 및 메일 세션을 포함할 수 있다. 다수의 테난트들에 대하여 MedRec 어플리케이션을 구동하기 위하여, 시스템 관리자는 단일 MedRec 리소스 그룹 템플레이트(286)를 정의할 수 있으며, 템플레이트 내의 이들 배치가능한 이들 리소스들 선언한다.

도메인-레벨 배치가능 리소스들과 달리, 리소스 그룹 템플레이트 내에서 선언된 배치가능한 리소스들은 템플레이트 내에서 완전하게 설정되지 않을 수도 있으며 또는 있는 그대로(as-is) 활성화되지 않을 수도 있는데, 왜냐하면 이들은 설정 정보의 일부가 부족하기 때문이다.

예를 들어, MedRec 리소스 그룹 템플레이트는 어플리케이션들에 의해서 이용되는 데이터 소스를 선언할 수 있지만, 데이터베이스에 연결하기 위한 URL은 특정하지 않을 수 있다. 서로 다른 테난트들에 관련된 파티션들, 예를 들어 파티션 BUC-A(290)(Bayland Urgent Care, BUC)와 파티션 VH-A(292)(Valley Health, VH)는, MedRec 리소스 그룹 템플레이트를 참조하는(296, 297) MedRec 리소스 그룹(293, 294)을 각각 포함함으로써, 하나 이상의 리소스 그룹 템플레이트들을 참조할 수 있다. 다음으로 이러한 참조는 각각의 테난트에 대해 가상 타겟들/가상 호스트들을 생성하는데(302, 306) 이용될 수 있는바, 이들 가상 호스트들은 Bayland Urgent Care 테난트에 의해서 이용되는 BUC-A 파티션에 관련된 가상 호스트 baylandurgentcare.com(304) 및 Valley Health 테난트에 의해서 이용되는 VH-A 파티션에 관련된 가상 호스트 valleyhealth.com(308)를 포함한다.

도5는 또한, 본 발명의 일실시예에 따른 멀티-테난트 환경을 예시한다. 도5에 예시된 바와 같이, 그리고 2개의 파티션들이 MedRec 리소스 그룹 템플레이트를 참조하는 앞서 설명된 일례들에 연속하여, 본 발명의 일실시예에 따르면, 서브렛 엔진(servlet engine)(310)은 복수의 테난트 환경들을 지원하는데 이용될 수 있는바, 본 일례에서 복수의 테난트 환경들은 Bayland Urgent Care 의사 테난트 환경(Physician tenant environment)(320), 및 Valley Health 의사 테난트 환경(Physician tenant environment)(330)이다.

일실시예에 따르면, 각각의 파티션(321, 331)은 그 테난트 환경에 대한 인커밍 트래픽을 수용하는 서로 다른 가상 타겟을 정의할 수 있으며 그리고 파티션 및 그것의 리소스들(324, 334)에 연결하기 위한 서로 다른 URL(322,332)을 정의할 수 있는데, 본 일례에서는 이러한 리소스들은 bayland urgent care 데이터베이스 또는 valley health 데이터베이스를 각각 포함한다. 데이터베이스 인스턴스는 호환가능한 스키마를 이용할 수 있는데, 왜냐하면 동일한 어플리케이션 코드가 2개의 데이터베이스들에 대하여 실행될 것이기 때문이다. 시스템이 파티션을 시작할 때, 이것은 가상 타겟들 및 각각의 데이터베이스 인스턴스들에 대한 연결 풀들을 생성할 수 있다.

파티션 마이그레이션(Partition Migration)

일실시예에 따르면, 본 명세서에 서술된 것은 멀티테난트(multitenant) 어플리케이션 서버 환경에서 파티션 마이그레이션(portable migration)을 위한 시스템 및 방법이다. 각각의 리소스 그룹, 또는 그 리소스 그룹을 포함하는 파티션은 가상 타겟(예컨대, 가상 호스트) 정보에 관련될 수 있으며, 가상 타겟 정보는 상기 리소스 그룹 또는 파티션이 타겟팅 및 배치되어야 하는 타겟을 정의한다. 웹 티어 컴포넌트(web tier component)(예컨대, 오라클 트래픽 디렉터(Oracle Traffic Director))는 라우팅 정보를 포함하며, 상기 라우팅 정보는 특정 파티션에 대한 가상 타겟을 가령 서버 또는 클러스터 등의 대응 타겟에 맵핑하는바, 따라서 그 파티션에 대한 요청들은 적절한 타겟을 향해 지향된다(예를 들어, 하나 이상의 세션들의 일부로서). 특정 파티션이 마이그레이션되는 때, 오리지널 타겟과 신규 타겟 사이에서 세션 정보가 복사되며, 그리고 웹 티어 컴포넌트에는 수정된(revised) 라우팅 정보가 제공되는바 따라서 그 파티션에 대한 후속 요청들은 상기 신규 타겟으로 지향된다.

일실시예에 따르면, 파티션 마이그레이션은, 파티션이 하나의 타겟으로부터 다른 하나의 타겟으로 마이그레이션될 때 파티션에 관련된 세션들을 상태를 보존하는 것을 포함하여, 심리스 마이그레이션들(seamless migrations)을 제공하는데 이용될 수 있다. 이것은 예를 들어, 기저(underlying)의 컴퓨팅 인프라스트럭처의 문제들로 인하여 커스토머 어플리케이션이 지장을 받지 않음을 보장함에 있어서, 매우 유용할 수 있다.

도6은 일실시예에 따른, 어플리케이션 서버, 클라우드, 또는 다른 환경에서 파티션 마이그레이션의 사용을 예시한다. 도6에 도시된 바와 같이, 일실시예에 따르면, 제 1 또는 오리지널 타겟 클러스터 A(402)는 특정 파티션 A(404)를 포함하는 하나 이상의 파티션들을 포함할 수 있으며, 이는 파티션 설정(406) 및 하나 이상의 파티션별로 특정한 리소스 그룹들, 어플리케이션들 또는 리소스들(408)에 관련된다.

선택적으로는 파티션은 리소스 그룹 템플레이트(410)를 참조할 수 있다.

각각의 리소스 그룹 또는 그 리소스 그룹을 포함하는 파티션은 가상 타겟(예컨대, 가상 호스트) 정보에 관련될 수 있으며, 가상 타겟 정보는 상기 리소스 그룹 또는 파티션이 타겟팅 및 배치되어야 하는 타겟(가령, 가상 타겟 A 420)을 정의한다. 웹 티어 컴포넌트(web tier component)(예컨대, 오라클 트래픽 디렉터(Oracle Traffic Director)와 같은 트랙픽 디렉터)(430)는 라우팅 정보(432)를 포함하며, 상기 라우팅 정보(432)는 특정 파티션에 대한 가상 타겟을 가령 서버 또는 클러스터 등의 대응 타겟에 맵핑하는바, 따라서 그 파티션에 대한 요청들은 적절한 타겟을 향해 지향된다(예를 들어, 하나 이상의 세션들 434의 일부로서).

또한, 예시되어 있는 바와 같이, 상기 시스템은 파티션들이 배치될 수 있는, 제 2 또는 신규 타겟 클러스터 B(442)를 포함할 수 있다.

도7은 또한 일실시예에 따른, 어플리케이션 서버, 클라우드, 또는 다른 환경에서 파티션 마이그레이션의 사용을 예시한다. 도7에 도시된 바와 같이, 일실시예에 따르면, 특정 파티션, 및 현재 동작중인 임의의 세션들을 오리지널 타겟으로부터 신규 타겟으로 마이그레이션(444)시키도록, 표시(indication)가 수신될 수 있다. 일반적으로, 상기 시스템은 오직 특정한 가상 타겟에 관련된 타겟들 사이에서, 예를 들어, 특정한 가상 타겟에 관련된 서로 다른 클러스터 멤버들 사이에서(서로 다른 가상 타겟들 사이에서가 아니라), 파티션들을 마이그레이션시킬 것이다.

이에 응답하여, 특정 파티션이 마이그레이션되는데, 이는 오리지널 타겟과 신규 타겟 사이에서 세션 정보가 복사되는 것을 포함하며 그리고 웹 티어 컴포넌트에는 수정된(revised) 라우팅 정보(446)가 제공되며, 상기 라우팅 정보는 특정 파티션에 대한 가상 타겟을 신규 타겟에 맵핑하는바, 따라서 그 파티션에 대한 후속 요청들은 상기 신규 타겟을 향해 지향된다(448).

예를 들어, 일실시예에 따르면, 어플리케이션 서버 환경은 트래픽 디렉터(예컨대, OTD)에게, 특정한 컴퓨터 클러스터가 (예를 들어, 유지 보수 또는 장애 극복을 이유로) 머지않아(soon) 다운될 것임을 알려줄 수 있으며, 그리고 예상된 신규 클러스터로 요청들을 전송하기 시작할 것을 트래픽 디렉터에게 지시할 수 있다. 그 와중에, 상기 어플리케이션 서버는 세션 정보를 신규 클러스터로 복사할 수 있다. 세션 복제가 일단 완료되면, 어플리케이션 서버 환경은 다운그레이드된 컴퓨터 클러스터를 그것을 설정으로부터 제거할 것을 트래픽 디렉터에게 알려줄 수 있으며, 이것은 또한 임의의 리소스 그룹 타겟팅으로부터 제거될 수 있다.

일실시예에 따르면, 클러스터들이 타겟들로서 이용되는 경우, 상기 시스템은 세션들의 라이브 마이그레이션들(live migrations)을 수행한다. 컴퓨터 서버가 타겟으로 이용되는 경우, 라이브 마이그레이션 기능이 비활성화될 수 있으며 그리고 사용자-제어 수동 마이그레이션이 이용될 수도 있는바 따라서, 임의의 가능한 중단시간(downtime) 또는 세션 정보의 손실이 사용자에게 통보될 수 있다.

도8은 본 발명의 일실시예에 따라, 어플리케이션 서버, 클라우드, 또는 다른 환경에서 파티션 마이그레이션을 사용하는 방법을 예시한다. 도8에 도시된 바와 같이, 일실시예에 따르면, 단계 460에서, 소프트웨어 어플리케이션들의 실행을 위한 도메인, 및 하나 이상의 파티션들과 리소스 그룹들을 포함하는 어플리케이션 서버 환경이 제공되며, 여기서 각각의 파티션은 도메인의 관리 및 런타임 하위분할(administrative and runtime subdivision)을 제공하며 그리고 하나 이상의 리소스 그룹들을 포함할 수 있고, 여기서 각각의 리소스 그룹은 배치가능한 어플리케이션들 또는 리소스 그룹 템플레이트를 참조할 수 있는 리소스들의 컬렉션이다.

단계 462에서, 각각의 리소스 그룹, 또는 그 리소스 그룹을 포함하는 파티션은, 가상 타겟(예컨대, 가상 호스트) 정보와 관련될 수 있으며, 가상 타겟 정보는 상기 리소스 그룹 또는 파티션이 타겟팅 및 배치되어야 하는 타겟을 정의한다.

단계 464에서, 특정 파티션, 및 현재 동작중인 임의의 세션들을 오리지널 타겟으로부터 신규 타겟으로 마이그레이션시키도록, 표시(indication)가 수신된다.

단계 466에서, 특정 파티션이 마이그레이션되는데, 이는 오리지널 타겟과 신규 타겟 사이에서 세션 정보가 복사되는 것을 포함하며 그리고 웹 티어 컴포넌트(예컨대, 오라클 트래픽 디렉터(OTD) 등과 같은 트래픽 디렉터)는 수정된(revised) 라우팅 정보를 제공받으며, 상기 라우팅 정보는 특정 파티션에 대한 가상 타겟을 신규 타겟에 맵핑하는바, 따라서 그 파티션에 대한 후속 요청들은 상기 신규 타겟을 향해 지향된다.

예시적인 구현예들

예시적인 실시예를 서술하는 추가적인 세부사항들이 설명을 위해 아래에 제공된다.

라이브 마이그레이션 개관(Live Migration Overview)(http 및 t3 트래픽에 대해)

일실시예에 따르면, 라이브 마이그레이션 동안, 리소그 그룹이 구동(running)중이다. 관리자는 JMX 커맨드를 이용하여 리소스 그룹 마이그레이션을 개시하며 그리고 가상 타겟 mbean, 기존 타겟, 및 신규 타겟을 파라미터들로 특정한다. 신규 타겟이 가상 타겟에 부가되며 그리고 리소스들이 신규 타겟에 배치된다. 만일, 유효성 에러(validation error)가 발생하면 동작이 중단되며 그리고 사용자는 소스 리소스 그룹을 셧다운(shut down)하고 그리고 논-라이브(non-live) 마이그레이션을 수행할 것을 통보받는다. 만일, 현재 및 신규 타겟이 클러스터인 경우, 세션 복제 및 T3-재라우팅(T3- re-routing)을 위한 클러스터링 APIs 가 시작된다. OTD 재라우팅(OTD re-routing)을 위한 LCM APIs 이 시작되어, 이러한 리소스 그룹(들)을 OTD 가 프론트-엔딩하고 있는지를 내부적으로 결정한다. 특정 타겟에 대한 리소스 그룹 정상 종료(resource group graceful shutdown)를 이용하여, 구형(old) 타겟에 타겟팅된 어플리케이션들/리소스들의 정상 종료(graceful shutdown)가 시작된다. 구형 타겟을 삭제하도록, 가상 타겟에 대한 mbean 설정이 업데이트된다.

논-라이브 마이그레이션 개관(Non-live Migration Overview)(http 및 t3 트래픽에 대해)

일실시예에 따르면, 논-라이브 마이그레이션 동안, 리소스 그룹은 구동중이 아니다. WLS 관리자는 예컨대, JMX 커맨드를 이용하여 리소스 그룹 마이그레이션을 개시하며 그리고 가상 타겟 mbean, 기존 타겟, 및 신규 타겟을 파라미터들로 특정한다. 구형 타겟이 가상 타겟으로부터 제거되며 그리고 신규 타겟이 가상 타겟에 부가되는바, 이는 리소스들/어플들을 신규 타겟에 내부적으로 배치한다. OTD 업데이트를 위한 LCM APIs이 시작되어, 이러한 리소스 그룹(들)을 OTD 가 프론트-엔딩하고 있는지를 내부적으로 결정한다.

리소스 그룹 마이그레이션 API

일실시예에 따르면, new service PortablePartitionManagerMbean 를 이용하여 마이그레이션이 시작될 것이다.

ResourceGroupMigrationTask = migrateResourceGroup(TargetMBean VirtualTarget, TargetMBean currentTarget,

TargetMBean newTarget, long timeout);

동일한 가상 타겟에 대하여 또 다른 마이그레이션 콜(call)이 프로세스되는 동안, 새로운 마이그레이션 콜이 시작된다면, 유효성 예외(validation exception)가 발생할 것이다. 2 개의 동시 마이그레이션 프로세스들을 하나의 리소스 그룹에서 시작하는 것은 불가능하다. ResourceGroupMigrationTask 는 이러한 긴 구동 프로세스의 상태에 관한 정보를 포함한다.

가상 타겟에 신규 타겟을 부가(Adding new target to virtual target)

일실시예에 따르면, 라이브 마이그레이션의 경우, 신규 타겟이 가상 타겟에 부가되며 그리고 RG 내의 어플리케이션 및 리소스들이 신규 타겟에 배치된다. 만일, 임의의 어플리케이션 또는 리소스가 멀티-타겟팅을 지원하지 않는다면, 이들은 유효성 예외를 발생시킬 것이다. 이러한 경우, 리소스 그룹이 라이브 마이그레이션을 지원하지 않음을 보고하고 그리고 논-라이브 마이그레이션을 수행하기 위하여 RG가 먼저 셧다운되어야 함을 보고하면서, 마이그레이션 동작이 중단될 것이다.

세션 복제 및 T3-재라우팅(Session replication and T3-rerouting)

일실시예에 따르면, 신규 타겟이 부가된 이후에, WLS-MT 클러스터링 세션 복제 피처(WLS-MT clustering session replication feature)가 사용되어 구형 클러스터와 신규 클러스터 사이에서 세션들을 동기화할 수 있으며, 여기서 세션 상태들이 새로운 토폴로지-new target 에서 일부 서버들에 복제된다. 그 다음으로, 콜백 이벤트(callback event)가 전송되지만 프로세스는 변경된 세션들의 동기화를 계속한다. 마이그레이션 클러스터링 서브시스템은 연결된 모든 T3 클라이언트들에게 타겟 변경에 대해 통지한다. T3 클라이언트들은 타겟으로부터 새로운 url 들로 재연결할 것이며 그리고 마이그레이션된 어플리케이션과 투명하게(transparently) 통신을 계속할 것이다. 전체 클러스터가 중단되어야하는 경우, 클라이언트는 잘 알려진 주소에 도달할 수 있어야 하고 그리고 라우팅될 새로운 클러스터를 재발견할 수 있어야 한다.

WLS-MT 라이프싸이클을 이용한 HTTP 트래픽 재-라우팅(HTTP traffic re-routing using WLS-MT-lifecycle)

일실시예에 따르면, 마이그레이션 기능은 마이그레이션을 위한 라이프싸이클 모듈의 가용성(availability)을 활용할 수 있는바(leverage), 이는 상이한 언어들로 독립적으로 개발된 컴포넌트들 간의 구성 통합을 제공하고 구성 및 관리를 위해 상이한 아키텍처를 사용하려고 시도한다.

심리스 케이스(Seamless case)

일실시예에 따르면, 심리스 케이스들 동안 어플리케이션 서버는 파티션 마이그레이션 REST 콜로 LCM을 호출할 것이다:

// migrate all partitions associated with the environment

POST

/management/lifecycle/latest/environments/{name}/partitions/{id}/migrate

페이로드에는 파티션이 배치된 새로운 클러스터의 세부 사항과 OTD의 구성 변경을 위해 OTD 플러그인을 호출하는 phase : start-migrate가 포함된다. 다음은 OTD 기능 명세에 명시된 대로 OTD 측에서 일어나는 단계이다.

파티션 마이그레이션이 개시되면, 그 파티션에 대한 관련된 가상 서버의 obj.conf 설정 내의 루트 엔트리(route entry)가 변경되어, 새로운 요청들을 처리할, 기존 풀(existing pool)과는 별개인 새로운 오리진 서버 풀(new origin server pool)이 나열된다. 기존 풀(구형 또는 드레인 풀(drain pool))은 그것의 오리진 서버들에 대한 고정 요청들(sticky requests)만을 처리할 것이다.

이러한 설정 변경 이후에, 그 파티션에 대한 모든 요청에 대하여, OTD는 그것이 고정 요청인지를 먼저 체크할 것이며, 그리고 상기 요청을 처리할 것으로 예측되는 오리진 서버가 구형의 오리진 서버 풀의 일부인지를 체크할 것이다.

만일 그렇다면, 상기 요청은 구형 풀의 특정한 오리진 서버로 라우팅된다. 만일, 상기 구형 오리진 서버가 활성이 아니라면, 이것은 구형 풀의 또 다른 오리진 서버로 라우팅될 것이다.

만일, 상기 요청이 고정 요청이 아니라면, 이것은 새로운 오리진 서버 풀로 라우팅된다.

구형 풀 엔트리를 제거하도록 설정이 변경될 때까지, 구형 풀은 고정 요청들에 대한 처리를 계속할 것이다. 적절한 시점에서 상기 풀의 드레이닝(draining)을 턴오프하는 것은 관리자(admin)의 책임이 될 것이다.

WLS는 phase : end-migrate 를 특정하는 제 2 파티션 마이그레이션 REST 콜을 이용하여 LCM을 호출할 것인바, phase : end-migrate 는 OTD에서의 설정 변경을 위해 OTD 플러그인을 호출할 것이다.

논-심리스 케이스(Non-seamless case)

일실시예에 따르면, 심리스 케이스(seamless case) 동안, 어플리케이션 서버는 파티션 업데이트 REST 콜을 이용하여 LCM을 호출할 것이다.

// update all partitions associated with the environment

POST

/management/lifecycle/latest/environments/{name}/partitions/{id}/update

페이로드는 파티션이 배치된 새로운 클러스터의 세부 사항을 포함할 것이다. LCM은 그 파티션에 대한 OTD 설정을 업데이트하기 위해 OTD 플러그인(Plugin)에 콜(call)을 위임한다.

정상 종료(Graceful shutdown)

일실시예에 따르면, 본 단계 동안, 리소스 그룹 셧다운 피처를 이용하여 지정된 (구형) 타겟에 대해 리소스 그룹의 정상 종료가 개시된다. 이것은 인플라이트 워크(inflight work)의 처리를 허용할 것이다. 이것은, JMS 메시지, 실행중인 작업(Running jobs), 예약된 태스크(scheduled tasks) 및 JTA 트랜잭션(JTA transactions) 등과 같은 싱글튼 서비스들(singleton services)에서 미처리된 상태(unprocessed state)에 관한 문제점들을 감소시킬 것이다. 리소스 컨테이너들(resource containers)은 그들의 상대적인 정지/중단 콜들(halt/suspend calls)을 서로 다른 방식으로 처리한다. 예를 들어, 데이터소스 컨테이너는 트랜잭션 매니저로부터 그것의 리소스들의 전체 등록해제(full unregister)를 수행할 것인 반면에, JMS 컨테이너는 등록해제(unregister)를 수행하지 않을 것이지만 메시지들의 추가적인 요청들/프로세싱은 차단할 것이다. 모든 리소스 컨테이너들은, 배치취소 동안에(during undeploy) 등록해제 콜들(unregister calls)을 수행한다. 다양한 리소스 컨테이너들의 등록해제 거동은 다양하지만, 대기중인 트랜잭션들이 완료될 때까지 컨테이너가 기다리는 유예 기간(grace period)이 적어도 항상 존재한다.

모든 JTA 트랜잭션들이 완료되었는지를 확인하기(Ensuring all JTA transactions are complete)

일반적으로, 리소스 그룹 마이그레이션이 발생되면, 리소스들에 관련된 모든 트랜잭션들은 마이그레이션이 발생하기 전에 완료될 것이다. 드문 경우이지만 주어진 리소스에 대한 모든 트랜잭션들이 유예 기간이 끝날 때까지 완료되지 않은 경우(예를 들어, 리소스 그룹 마이그레이션이 시작됨과 동시에 데이터베이스가 오랜 시간 동안 사용할 수 없게 된 경우), 리소스들은 계속 마이그레이션될 수 있다. 이것은 리소스 마이그레이션이 단일 도메인으로 제한되고 그리고 오리지널 서버가 리소스를 그것의 새 위치에서 찾을 수 있으며 복구를 수행할 수 있기 때문이다.

EJB 스터브(EJB Stubs)

클러스터된(clustered) EJBs 및 RMIs 의 경우, 객체의 복제-인지 스터브(object's replica-aware stub)를 이용하여 RG 마이그레이션이 수행된다. 클라이언트가 복제 인식 스터브를 통해 실패한 서비스에 대한 콜을 하면, 상기 스터브는 실패를 감지하고 그리고 다른 복제본(replica)에 대해 콜을 다시 시도한다. 주 서버(primary server)가 실패하면, 클라이언트의 EJB 스터브는 자동으로 추가 요청들을 보조 어플리케이션 서버 인스턴스로 리디렉션한다. 이 시점에서 상기 보조 서버는 복제된 상태 데이터(the replicated state data)를 사용하여 새로운 EJB 인스턴스를 생성하고, 그리고 보조 서버에서 프로세싱이 계속된다. 만일, 클라이언트가 미스디렉션되면(misdirected)(틀린 주/보조 서버 정보), 세션 복제 프레임워크는 상기 복제본을 호스팅하는 서버를 결정하도록 세션 상태 쿼리 프로토콜을 사용할 것이며 그리고 상기 정보를 클라이언트 스터브에 다시 보낼 것이다. 그런 다음 클라이언트 스터브는 해당 요청을 상기 복제본을 호스팅하는 서버로 리디렉션한다.

JMS

만일, 관리자가 JMS config 를 갖는 리소스 그룹의 마이그레이션을 시작하려고 하면 유효성 예외(validation exception)가 발생할 것이다. 마이그레이션 전에 리소스 그룹을 셧다운하라는 메시지가 관리자에게 디스플레이될 것이다. RG 마이그레이션 동안의 데이터 손실을 방지하기 위하여, JMS 서버 또는 SAF 에이전트가 배치취소(undeploy)되거나 제거되기 전에, 어플리케이션 메시지들이 완전히 유실되어야 하고(drained) 그리고 모든 펜딩(pending) 트랜잭션이 완료되어야 한다. 따라서, 리소스 그룹 셧다운이 개시되기 전에, 모든 드레이닝(draining)이 완료되었는지를 확인하는 것은 관리자가 해야할 일이다. 리소스 그룹 마이그레이션이 완료된 이후, 리소스 그룹을 다시 시작하는 것도 관리자의 일이다.

Mbean 설정 변경(MBean Configuration change)

일실시예에 따르면, 어플리케이션이 중단되거나 혹은 타임아웃에 도달하면, ResourceGroup의 타겟, 즉 가상 타겟이 업데이트되어 구형 클러스터를 제거한다. 이것은 마이그레이션 프로세스의 마지막 단계이다.

본 발명은 하나 이상의 프로세서들, 메모리 및/또는 본 발명에 개시된 가르침에 따라 프로그래밍된 컴퓨터 판독가능한 저장 매체를 포함하는 하나 이상의 범용 혹은 특화된 디지털 컴퓨터, 컴퓨팅 디바이스, 머신 혹은 마이크로프로세서를 이용하여 용이하게 구현될 수 있다. 소프트웨어 분야의 당업자에게 자명한 바와 같이, 본 개시 내용의 가르침에 기초하여 해당 기술분야의 프로그래머들에 의해서 적절한 소프트웨어 코딩이 용이하게 준비될 수 있다.

일부 실시예들에서, 본 발명은 컴퓨터 프로그램 제품을 포함하는데 컴퓨터 프로그램 제품은 명령들이 저장되어 있는 비일시적인 저장 매체 또는 컴퓨터 판독가능한 매체이며 이는 본 발명의 임의의 프로세스를 수행하도록 컴퓨터를 프로그래밍하는데 이용될 수 있다. 저장 매체는 플로피 디스크, 광학 디스크, DVD, CD-ROMs, 마이크로드라이브, 자기-광학 디스크, ROMs, RAMs, EPROMs, EEPROMs, DRAMs, VRAMs, 플래시 메모리, 자기 또는 광학 카드, 나노시스템들(분자 메모리 IC를 포함하여), 또는 명령들 및/또는 데이터를 저장하는데 적합한 임의 유형의 매체 혹은 디바이스를 포함하는 임의 유형의 디스크를 포함할 수 있지만 이에 한정되는 것을 아니다.

본 발명에 대한 전술한 서술들은 예시 및 설명을 위한 목적으로 제공되었다. 이것은 본 발명을 속속들이 규명한다던가 또는 개시된 폼 만으로 본 발명을 제한하고자 의도된 것이 아니다. 많은 변형예들 및 수정예들이 해당 기술분야의 당업자에게 자명할 것이다. 본 발명의 원리들 및 그것의 실제적인 적용예를 가장 잘 설명하도록, 이에 의해서 다양한 실시예들에 대하여 그리고 고려되는 특정 사용예에 적합한 다양한 변형들에 대하여 당업자가 본 발명을 이해할 수 있도록, 본 실시예들이 선택 및 서술되었다. 본 발명의 범위는 다음의 청구항들 및 그들의 등가물들에 의해서 정의되도록 의도된다.

Claims

어플리케이션 서버 환경에서 파티션 마이그레이션(partition migration)을 지원하기 위한 시스템으로서,
소프트웨어 어플리케이션들의 실행을 위한 도메인을 갖는 어플리케이션 서버 환경, 및 하나 이상의 파티션들과 리소스 그룹들을 포함하는, 하나 이상의 컴퓨터들을 포함하고,
각각의 파티션은 상기 도메인의 관리 및 런타임 하위분할(administrative and runtime subdivision)을 제공하고 그리고 하나 이상의 리소스 그룹들을 포함할 수 있으며,
각각의 리소스 그룹은 배치가능한 어플리케이션들 또는 리소스 그룹 템플레이트를 참조할 수 있는 리소스들의 컬렉션(collection)이며, 그리고
각각의 리소스 그룹, 또는 그 리소스 그룹을 포함하는 파티션은 가상 타겟 정보에 관련될 수 있으며, 상기 가상 타겟 정보는 상기 리소스 그룹 또는 파티션이 타겟팅 및 배치되어야 하는 타겟을 정의하고, 그리고
웹 티어 컴포넌트(web tier component)는 라우팅 정보를 포함하며, 상기 라우팅 정보는 특정 파티션에 대한 가상 타겟을 서버 또는 클러스터와 같은 대응 타겟에 맵핑하며, 따라서 그 파티션에 대한 요청들은 적절한 타겟을 향해 지향되는 것을 특징으로 하는 파티션 마이그레이션을 지원하기 위한 시스템.
제1항에 있어서,
상기 어플리케이션 서버 또는 클라우드 환경은 자바 EE 어플리케이션 서버를 포함하는 것을 특징으로 하는 파티션 마이그레이션을 지원하기 위한 시스템.
제1항 또는 제2항에 있어서,
특정 파티션이 마이그레이션되는 때에, 오리지널 타겟과 신규 타겟 사이에서 세션 정보가 복제되고, 상기 웹 티어 컴포넌트에는 수정된(revised) 라우팅 정보가 제공되며, 따라서 그 파티션에 대한 후속 요청들은 상기 신규 타겟으로 지향되는 것을 특징으로 하는 파티션 마이그레이션을 지원하기 위한 시스템.
임의의 선행하는 청구항에 있어서,
테난트에 의한 사용을 위해 상기 시스템이 선택적으로는 하나 이상의 파티션들을 상기 테난트와 관련시킬 수 있는 것을 포함하여, 상기 시스템은 클라우드 환경에 제공되어 상기 클라우드 환경에서 동작하는 멀티플 테난트들(multiple tenants)을 지원하는 것을 특징으로 하는 파티션 마이그레이션을 지원하기 위한 시스템.
어플리케이션 서버 환경에서 파티션 마이그레이션을 지원하기 위한 방법으로서,
소프트웨어 어플리케이션들의 실행을 위한 도메인을 갖는 어플리케이션 서버 환경 및 하나 이상의 파티션들과 리소스 그룹들을 하나 이상의 컴퓨터들에 제공하는 단계를 포함하고,
각각의 파티션은 상기 도메인의 관리 및 런타임 하위분할을 제공하고 그리고 리소스 그룹을 포함할 수 있으며,
각각의 리소스 그룹은 배치가능한 어플리케이션들 또는 리소스 그룹 템플레이트를 참조할 수 있는 리소스들의 컬렉션이며, 그리고
각각의 리소스 그룹, 또는 그 리소스 그룹을 포함하는 파티션은 가상 타겟 정보에 관련될 수 있으며, 상기 가상 타겟 정보는 상기 리소스 그룹 또는 파티션이 타겟팅 및 배치되어야 하는 타겟을 정의하고, 그리고
웹 티어 컴포넌트는 라우팅 정보를 포함하며, 상기 라우팅 정보는 특정 파티션에 대한 가상 타겟을 서버 또는 클러스터와 같은 대응 타겟에 맵핑하며, 따라서 그 파티션에 대한 요청들은 적절한 타겟을 향해 지향되는 것을 특징으로 하는 파티션 마이그레이션을 지원하기 위한 방법.
제5항에 있어서,
상기 어플리케이션 서버 또는 클라우드 환경은 자바 EE 어플리케이션 서버를 포함하는 것을 특징으로 하는 파티션 마이그레이션을 지원하기 위한 방법.
제5항 또는 제6항에 있어서,
특정 파티션이 마이그레이션되는 때에, 오리지널 타겟과 신규 타겟 사이에서 세션 정보가 복제되고, 상기 웹 티어 컴포넌트에는 수정된 라우팅 정보가 제공되며, 따라서 그 파티션에 대한 후속 요청들은 상기 신규 타겟으로 지향되는 것을 특징으로 하는 파티션 마이그레이션을 지원하기 위한 방법.
제5항 내지 제7항 중 어느 한 항에 있어서,
테난트에 의한 사용을 위해 상기 시스템이 선택적으로는 하나 이상의 파티션들을 상기 테난트와 관련시킬 수 있는 것을 포함하여, 상기 방법은 클라우드 환경에 제공되어 상기 클라우드 환경에서 동작하는 멀티플 테난트들(multiple tenants)을 지원하는 것을 특징으로 하는 파티션 마이그레이션을 지원하기 위한 방법.
컴퓨터 시스템에 의해서 실행될 때 상기 컴퓨터 시스템으로 하여금 제5항 내지 제8항 중 어느 한 항에 따른 방법을 수행하게 하는, 머신-판독가능한 포맷의 프로그램 명령들을 포함하는 컴퓨터 프로그램.
비-일시적인(non-transitory) 머신-판독가능한 데이터 저장 매체에 저장된 제9항의 컴퓨터 프로그램을 포함하는 컴퓨터 프로그램 제품.
명령들이 저장되어 있는 비-일시적인 컴퓨터 판독가능한 저장 매체로서, 상기 명령들은 하나 이상의 컴퓨터들에 의해서 판독 및 실행될 때 상기 하나 이상의 컴퓨터들로 하여금,
소프트웨어 어플리케이션들의 실행을 위한 도메인을 갖는 어플리케이션 서버 환경 및 하나 이상의 파티션들과 리소스 그룹들을 하나 이상의 컴퓨터들에 제공하는 단계를 실행하게 하며,
각각의 파티션은 상기 도메인의 관리 및 런타임 하위분할을 제공하고 그리고 리소스 그룹을 포함할 수 있으며,
각각의 리소스 그룹은 배치가능한 어플리케이션들 또는 리소스 그룹 템플레이트를 참조할 수 있는 리소스들의 컬렉션이며, 그리고
각각의 리소스 그룹, 또는 그 리소스 그룹을 포함하는 파티션은 가상 타겟 정보에 관련될 수 있으며, 상기 가상 타겟 정보는 상기 리소스 그룹 또는 파티션이 타겟팅 및 배치되어야 하는 타겟을 정의하고, 그리고
웹 티어 컴포넌트는 라우팅 정보를 포함하며, 상기 라우팅 정보는 특정 파티션에 대한 가상 타겟을 서버 또는 클러스터와 같은 대응 타겟에 맵핑하며, 따라서 그 파티션에 대한 요청들은 적절한 타겟을 향해 지향되는 것을 특징으로 하는 비-일시적인 컴퓨터 판독가능한 저장 매체.
제11항에 있어서,
상기 어플리케이션 서버 또는 클라우드 환경은 자바 EE 어플리케이션 서버를 포함하는 것을 특징으로 하는 비-일시적인 컴퓨터 판독가능한 저장 매체.
제11항 또는 제12항에 있어서,
특정 파티션이 마이그레이션되는 때에, 오리지널 타겟과 신규 타겟 사이에서 세션 정보가 복제되고, 상기 웹 티어 컴포넌트에는 수정된 라우팅 정보가 제공되며, 따라서 그 파티션에 대한 후속 요청들은 상기 신규 타겟으로 지향되는 것을 특징으로 하는 비-일시적인 컴퓨터 판독가능한 저장 매체.
제11항 내지 제13항 중 어느 한 항에 있어서,
테난트에 의한 사용을 위해 상기 시스템이 선택적으로는 하나 이상의 파티션들을 상기 테난트와 관련시킬 수 있는 것을 포함하여, 상기 어플리케이션 서버 환경은 클라우드 환경에 제공되어 상기 클라우드 환경에서 동작하는 멀티플 테난트들(multiple tenants)을 지원하는 것을 특징으로 하는 비-일시적인 컴퓨터 판독가능한 저장 매체.