iRODS 분석

2017. 3. 13Dr. Suntae Kim

목차

• iRODS 프롤로그• iRODS 활용사례• iRODS 개요• iRODS 특징• iRODS 아키텍처• iRODS Rule-Oriented Programming• iRODS Rule System• iRODS 테스트

iRODS 프롤로그

데이터셋 + 워크플로우

• The end goal is reproducible data-driven research. – It should be possible for a researcher to publish data sets

and workflows that are used to analyze the data sets. – A second researcher should be able to reexecute the workflow

and obtain the same result. – Conversely, a third researcher should be able to change the

input parameters for the workflow, compare analyses and save the new version of the results.

– A data management system that provides this capability must manage not only data sets, but also workflows.

• The preservation and dissemination of publicly funded data sets should also include the preservation and dissemination of the policies that are used to manage those data sets.

Object storage

• Object storage = object-based storage– computer data storage architecture that manages data as objects, as opposed to

other storage architectures like file systems which manage data as a file hierarchy and block storage which manages data as blocks within sectors and tracks.

• Each object typically includes – the data itself, – a variable amount of metadata, and – a globally unique identifier.

• Object storage systems allow – retention of massive amounts of unstructured data. – Object storage is used for purposes such as storing photos on Facebook, songs

on Spotify, or files in online collaboration services, such as Dropbox.

• Object storage is one technology being used in research environments today as a storage resource of iRODS.

Object storage & silent data

• An object storage system can execute policies that dictate geographical data replication and placement.

• Once the policy is attached to a data object, it is maintained regardless of site failures, network failures or storage element failures.

• Each object is protected from silent data corruption caused by storage element failures through evaluation of a checksum, which is checked each time the data are served.

Policy-based data management systems

사람 개입의필요성이 없이

iRODS 활용사례

활용 사례

The Wellcome Trust Sanger Institute 사례

The Wellcome Trust Sanger Institute 사례

• single-sign on• 내구성• HPC• 메타데이터

National Institute of Environmental Health Sciences

유동 세포분석

시료 조제 시트

세포 감염표면 분액및 라벨 수집

중합효소연쇄 반응

• 규칙적인 워크플로우• 보고• 비용청구

NASA Atmospheric Science Data Center

• 저장소 마이그레이션• Publication• Federation

Goddard Space Flight Center

University College London

UNIVERSITY COLLEGE LONDON (UCL)

• UCL, RANKED CONSISTENTLY AS ONE OF THE TOP FIVE UNIVERSITIES• 1만명 직원, 1만5천명 학생, 연구자 5천명• 100개이상의 부서와 연구소, 연구센터 보유• 노벨상을 25명 배출하고 세계 Top5 대학에 들어가는 대학

• UCL에 있는 UCL 정보서비스부 연구데이터 서비스 파트장 Dr. J. Max Wilkinson

• “프로젝트를 통해 생산되는 연구 데이터를 장기간 재사용 가능하도록 보존해야 한다. 이와 관련된 개별 연구자의 부담을 덜어주는 것이 목표”

• 이를 위해서, 제안서를 요구했고 21개 제안서를 받았다는 이야기가 이어진다. 그중에 DDN의 제안서가 채택되었단다. DDN 제안서는 GRIDScaler®, WOS® 그리고 iRODS를 포함

UNIVERSITY COLLEGE LONDON (UCL)

• several unique Technical and Cultural Challenges• On the technical side :

– 다양한 유형의 데이터, 생산되는 속도와 데이터의 규모가 빠르게성장

– 여러 개의 USB나 서로 다른 장소의 탈부착 가능한 하드디스크에데이터 저장

– 다른 사례로서, 연구가 진행되는 현장의 컴퓨터 알고리즘들이 서로 전달하는, 매우 잘 정의된 데이터를 대량으로 생산하고 있음

– 대부분의 연구 프로젝트를 증명할 수 있는 가치있는 데이터가하드디스크에 있으며, 소멸되고 있음

• è ‘data-intensive’ 환경의 연구자들을 지원하기 위해, 데이터은 안전하게 보관하고, 선진적인 데이터 관리가 가능하게하고, 최고수준의 저장소 솔루션을 사용하도록 함

Funder 요구와 UCL 대응

• UCL, along with many other UK research intensive institutes, is faced with increasingly stringent requirements for the management of project data outputs by UK Research Councils and other funding bodies in the United Kingdom.

• As grant funding in the UK supports best practice, it was critical to have a proven data management plan that documented how UCL would preserve data for sometimes decades while ensuring maximum appropriate access and reuse by third parties.

도전 사항 요약

• Improve the sharing & access of project-based research

• Transition the IT responsibilities fromresearch teams back to IT

• Address the rapid growth of data, in both volume and velocity

• Comply with funding agencies’ data preservation regulations

• Source an end-to-end solution with flexible, highly scalable architecture

100GB 100GB

100GB

100GB

100GB

100GB

100GB

100GB

100GB

100GB

100GBWhile some researchers thought 100GB was a large amount of data, others clamored for more than 100TB to support a particular project.

제안서 내용 : “We had a simple services proposition that would eliminate the need for research teams to manage racks of servers and data storage devices,” says Wilkinson. “Of course, this meant we’d need a highly scalable storage infrastructure that could grow to 100PB without creating a large storage footprint or excessive administrative overhead.”

100GB

100GB

100GB

100GB

100GB

100GB

100GB

100GB

100GB

100GB

100GB

100GB

100GB

100GB

100GB

100GB

100GB

100GB

100GB

100GB

UNIVERSITY COLLEGE LONDON (UCL)

• In seeking a scalable, resilient storage foundation, UCL issued an RFP to solicit insight on different approaches for consolidating the university’s research data storage infrastructure.

• 다양한 21개 제안서 도착

• 제안서는 폭넓은 주제로 제안되었음– 엄청나게 큰 데이터를 어떻게 처리했는지– 지속적으로 복잡해 지는 환경을 어떻게 해결했는지– 훌륭한 데이터 관리 프레임워크를 어떻게 구현했는지

제안요청서는 이렇게 쓰여져야…

• 제안요청: UCL’s RFP covered a diverse set of requirements to determine each potential solution provider’s respective strengths and limitations.

• 가능하다고 생각하는 것 이상의 것을 요구했음• 하나의 vendor 로 부터, 동기방식의 파일 공유로 부터• 고성능 병렬 파일 시스템 까지, 높은 확장성, 관리하기 단순한

탁력적 저장소에 이르기 까지 요구했음 (Daniel Hanlon, Storage Architect for Research Data Services at University College London)

• è 제안서: Recommendations encompassed a broad storage spectrum, including NAS, SAN, HSM, object storage, asset management solutions and small amounts of spinning disks with lots of back-end tape. è 특정 하드웨어 플랫폼에 종속된 벤더의 제안서는 제외

• It was important to be both data and storage agnostic

결정 요인 및 선택

• data and storage agnostic to support all data and media types without being locked into any particular hardware platform

• 가상의 무제한 확장성 지원과 관리의 용이성 때문에 객체 저장소(object storage) 선호

• 객체 저장소가 뜨는 기술이었음• 제안요청 배경에 대해서 제안업체의 이해도 평가 수행. 기업과 대학

의 환경차이를 모르는 업체도 있었음• 대학이 특정 기술(particular closed technologies)에 종속되는 것을

피해야 한다는 사실을 모름 (Hanlon)• 많은 제안 업체가 탈락했음. 이유는 기술이 부족해서가 아니라 UCL

이 무엇을 원하는지 모르기 때문임• 대학 실적 검토. 쉬운 확장지원. • 오픈소스 활용 검토 (오픈소스 파트너 활동 및 다른 학술적 기관의

참여 가능이 이유)

DataDirect™ Networks (DDN) 선택

• In evaluating DDN, we agreed that their solution – had a simple proposition, – high performance and – low administration overhead.

• DDN 제안내용– GRIDScaler massively scalable parallel file system– Web Object Scaler (WOS)– Another plus for WOS storage was its tight integration with the Integrated Rule-

Oriented Data Management Solution (iRODS).• This open-source solution is ideally suited for research collaboration by making it easier to

organize, share and find collections of data stored in local and remote repositories.

• GRIDScaler File Storage provided the high performance and low latency required for their HPC applications è 고성능 컴퓨팅을 위한 어플리케이션은 적은 대기시간을 원함

• DDN의 솔루션은 같은 저장소에 접근하는 다양한 방법을 제시하기 때문에기존에 존재하던 응용프로그램 코드를 재사용할 수있음 (Hanlon)

기대효과

• DDN’s turnkey distributed storage and collaboration solution è 턴키 분산 스토리지와 협력 솔루션

• The main attraction of DDN WOS is the combination of an efficient object store with edge appliances to ease integration with other storage infrastructure,” says Hanlon. è 효율적인 객체 저장소와 주변 장치들의 조합

• Another big plus for UCL is DDN’s high-density storage capacity, which will enable fitting a lot more disks into existing storage racks, which is crucial to growing while maintaining a small footprint in UCL’s highly-congested, expensive downtown London location. è 넓은 물리적 저장소 공간

최근연구 (iRODS 4.x)

• Bidirectional Integration of Multiple Metadata Sources. 8th iRODS User Group Meeting, University of North Carolina at Chapel Hill. June 2016

• Trustworthy Policies for Distributed Repositories (2016)

• Pluggable Rule Engine Architecture. 7th iRODS User Group Meeting 2015

• A Method for the Systematic Generation of Audit Logs in a Digital Preservation Environment and Its Experimental Implementation In a Production Ready System. 12th International Conference on Digital Preservation 2015

• Policy-Based Data Management: The Future of Reproducible, Data-Driven Research

iRODS 개요

iRODS 개요

• iRODS는 소프트웨어 미들웨어이다. 혹은 사이버인프라스트럭처이다. – 분산된 데이터를 공유가능한 컬렉션으로 조직하는 것이 가

능하다. – 데이터를 하나의 논리적 컬렉션으로 모아 데이터 그리드를

구현할 수 있다.

• 이러한 논리적 컬렉션은 다음과 같은 특성(Properties)을 갖는다.– 무결성(integrity)– 진본성(quthenticity)– 관리 연속성(chain of custody)– 신뢰성(trustworthiness)

iRODS 개요

• iRODS는 포괄적인 소프트웨어 인프라스트럭처이다. 다양한 형태의 데이터 관리 응용프로그램을 구현할 수 있다.

– 협력을 통한 데이터 공유를 위한 데이터 그리그구현

– 데이터 출판을 위한 디저틀 도서관 구축– 장기적 데이터 보유를 위한 보존 환경 제공– 데이터 처리를 위한 파이프라인 구축– 실시간 센서 데이터 스트림을 연합하기 위한 시스

템

iRODS 개요

• Open Source Data Management Software

– Data Virtualization : 데이터 오브젝트와 컬렉션 개념 사용

– Data Discovery : 이용자 정의 메타데이터 포함

– Workflow Automation : 각 각의 iRODS 서버는 ‘Rule Engine’을구동함. Rule Engine = event-tirggered background process è 다음 슬라이드에서 자세히

– Secure Collaboration : iRODS provides Secure Collaboration through three technologies: Tickets, Permissions, and Federation è 다음 슬라이드에서 자세히

iRODS 개요

• Open Source Data Management Software– Workflow Automation :

• 각 각의 iRODS 서버는 ‘Rule Engine’을 구동함. Rule Engine = event-tirggered background process

• Rule Engine은 iRODS Rules로 프로그램됨. iRODS Rule 이라는 것은iRODS가 특정 시스템 활동을 구동할 경우 호출(triggered) 되어야 하는 행위(action)을 명시해 놓은 것

• iRODS event tirggers = Policy Enforcement Points(PEPs or PEP)• a rule to transfer ownership of data objects to the project manager

when a user is deleted ; the trigger — or PEP — is the deletion of the user

• Similarly, rules could be written to extract metadata or pre-process data whenever a file is uploaded to an iRODS Resource

• Chaining rules and PEPs allows you to create powerful, customized workflows that save time and prevent human error.

iRODS 개요

• Open Source Data Management Software– Secure Collaboration : iRODS provides Secure Collaboration

through three technologies: Tickets, Permissions, and Federation• iRODS Tickets : Data Objects와 Collection 소유자가 티켓을 발생하여

non-iRODS 이용자들의 접근 권한을 제어할 수 있음. 티켓을 회수할 수 있으며, 특정 횟수 만큼 읽기와 쓰기를 설정할 수 있음

• iRODS Permissions : 유닉스 파일 시스템과 동일 함. Zone의 관리자(들)에의해 정의된 그룹 멤버쉽을 근거로, 정의된 iRODS 이용자들과 그룹에게 제한된 횟수만큼 데이터와 컬렉션에 읽기, 쓰기가 가능하도록 함

• iRODS Federation : single Zone을 넘어서 데이터의 공유와 출판을 확장함. Zone 관리자들이 키를 공유하고, Data Obejct 혹은 Collection의 소유자가외부 Zone의 이용자에게 읽기, 쓰기를 허용하는 방식임. 파일 전송 방식은single zone 내에서의 방식과 유사함. 작은 파일 전송이 아니라면, iRODS server들이 데이터를 보유하고 있는 서버와 요청한 서버 사이의 connection을 중개함. 외부 zone에 적재된 데이터에 접근을 가능하게 함

iRODS 개발 배경

• 웹과 같은 새로운 정보기술과 오늘날의 연구 문제들의증가하는 복잡성과 다학제적 특성에 의해서, 기후 변화부터 나날이 증가하는 세계의 통합 경제에 이르기까지, 연구자들이 효율적으로 협력할 수 있도록 하는, 사이버인프라스트럭쳐 기술에 대한 요구가 급격하게증가

• iRODS 용도– 글로벌한 협력연구 지원– 데이터 관리– 데이터 공유– 데이터 장기 보존

iRODS 요구사항 소스

• iRODS 개발시 요구사항 소스– HPC high performance computing 고성능 컴퓨팅 요구– 보존 커뮤니티 요구사항– 도서관 커뮤니티 요구사항들이 반영됨

• HPC 커뮤니티– 계산과학과 HPC 커뮤니티는 본질적으로 다학제적 연

구 분야이며 여러 사이트와 그룹에 분산되어 있는 매우 큰 데이터 컬렉션을 생성하고 사용

– 따라서, 수 테라바이트의 데이터와 수억개의 파일을보유한 컬렉션을 허용하는 독특한 기능을 갖추어야하는 요구사항이 iRODS에 반영

iRODS 요구사항 소스

• 보존 커뮤니티– long-term preservation of digital information, a

challenging problem that is still an active research area to which iRODS research activities have made significant contributions.

• 도서관 커뮤니티– Descriptive metadata that is essential for

management, discovery, repurposing, as well as controlled sharing and long-term preservation of digital collections.

iRODS 개발 동력

• DICE Storage Resource Broker (SRB) Data Grid technology

• 컴퓨터 과학 분야 노력: active databases, program verification, transactional systems, logic programming, business rule systems, constraint-management systems, workflows, and service-oriented architecture

iRODS 데이터 그리드에서 다루어진도전적 과제들

• 프로토콜 매핑 메커니즘 사용 : 클라이언트의 요청 정보를 특정 업체에서요구하는 프로토콜로 매핑. 저장소 자원들이 사용하는 이질적 접근 프로토콜을 매핑으로 관리한다.

• 상이한 인증관리시스템들 지원: 인증(authentication) 및 승인허가(authorization) 지원. 데이터 그리드는 모든 접근을 인증하고, 모든 파일에대한 승인허가와 로그들을 공유되는 컬렉션에 기록한다.

• uniform management policies (The policies controlling use, distribution, replication, retention, disposition, authenticity, integrity, and trustworthiness are enforced by the data grid.)

• wide-area-network access • (for moving massive files [through parallel input/output (I/O) streams], • for moving small files (through encapsulation of the file in the initial data

transfer request), • for moving large numbers of small files (aggregation into tar files), and • for minimizing the amount of data sent over the network (execution of

remote procedures such as data subset- ting on each storage resource).)

iRODS 특징

관리 정책과 절차

• iRODS는 새로운 환경에 적응할 수 있는 미들웨어(adaptable middleware)이다. 소프트웨어 코드의 재 작성 없이 관리 정책과 관리 절차들이 동적으로 변경가능하다.

• iRODS 데이터 그리드는– '관리 정책'의 표현은

computer actionable Rules– '관리 절차'의 표현은

sets of remotely executable Micro-services로 함

관리 정책과 절차

• 분산된 컬렉션을 관리하는 동안 69개 active Rules를 시행한다.

• 기관에 특화된 요구사항을 구현하도록 관리 정책을 조율할 수있도록 추가적인 8개 alternate Rules도 제공함

• 마이크로 서비스들에 의해 생성된 상태 정보들은 iCAT이라는메타데이터 목록에 저장됨

• 마이크로 서비스들로 부터의 입력과 출력 정보(81개 Session Variable Attributes와 109개 Persistent State Information Attributes)를 관리

• 185개 마이크로 서비스들을 원하는 관리 절차들로 구현한Actions로 구성함

Data grid technology = SRB

• SRB에 구현되었던 분산된 데이터 관리 및분산된 데이터를 공유가능한 컬렉션으로조직하는 기본 개념이 iRODS에 구현되었다.

Rule Base 복제

• 2014년 현재, Metadata 목록 기능이 부여된 서버의 Rule Base 버전을 기준

으로 iRODS Server의 Rule Base 자동 업데이트를 계획중이다.

• 현재는 각 서버가 다른 규칙 묶음을 실행할지 선택할 수 있도록 되어있다.

따라서 Rule Engine이 데이터에 영향을 미치는 서비스들(operations)을 제

어할 수 있다. 그러므로 저장소 자원에 특화된 정책을 구현하는 것이 가능

하다.

iRODS Client 처리 절차

• 이용자가 인증되며, 이용자의 명령이 실행될 iRODS Server가 식별된다.

• 이용자 요청정보가 식별된 iRODS Server로 전달된다.

• 해당 서버의 Rule Engine은 요청된 서비스들이 실행 가능한지 판단한다.

• 저장소 시스템에 의해 요구되는 프로토콜로 서비스를 변환한다.

• iRODS Clinet에게 서비스 반환값을 전달한다.

• 생성된 상태 정보가 iCAT 메타데이터 목록에 등록된다. (p.17)

Data Grid의 다단계 가상화

• 확장가능한 아키텍처를 만들기 위해서, iRODS Data Grid는 다단

계 가상화를 구현한다.

• 클라이언트는 task로 촉발되는 사건–조건–행위(event-

condition-action) 워크플로우를 만든다.

• 클라이언트로부터 요청된 행위들 (Actions)은 표준 기능들의 묶

음 (sets of standard functions, Micro-services)으로 매핑된다.

• 하나의 클라이언트 요청은 하나의 워크플로우에 함께 묶여있는,

여러 Micro-services 들과 Rules를 호출할 수 있다.

메타데이터 템플릿, 요소유형, JSON

Globus GridFTP Plugin

출처: http://slides.com/irods/globus-gridftp-plugin-for-irods#/5

iRODS 아키텍처

iRODS Framework

• iRODS Data Grid는 분산된 운영 시스템 (distributed operatin system)을 효율적으로구현한다.

• The iRODS Data Grid 지원– 계산 (Micro-services 실행)– 미루었던 실행을 위한 규칙 스케쥴링– 서버들과 저장소 사이의 데이터 이동– 데이터베이스에 상태 정보 저장

• 분산된 서버 간에 데이터를 전송하기 위해, 네트워크를 통해 전송될 데이터는 선형화(linearized) 되어야 한다.

• Remote operations는 Micro-services와 클라이언트 사이에 전달되는 구조화된 정보를 생성한다. 데이터 구조는 Micro-service에 따라 특화되어 있다. – 구조화된 정보가 잘 정의되어 있어야 한다는 요구사항이 실질적인 주요 이익이다. 이렇게 함으로써 여러

Micro-service를 체인으로 묶는 것이 가능하다.– 하나의 Micro-service로 부터 나오는 출력값이 다른 Micro-service에서 요구된 입력값의 형식을 갖게 된다.

• iRODS 프레임워크는 구조화된 정보의 교환을 제어하기 위해 필요한 다양한 방법(mechanisms)을 구현하였다.– 원격 Micro-services 실행, Rule Base 사이의 상호 작용, Rule Engine, Metadata Catalog

(p.19)

• 네트워크를 통해 32MB 이상의 대용량 데이터 이동을 위해, 병령 I/O 관리• 32MB 보다 작은 파일의 전송요구와 함께 데이터를 전송하는 최적화된 프로토콜 사용

데이터베이스에 기술적 메타데이터, 지속적인 상태 정보 저장 및 관리

마이크로 서비스 선정을 제어하는실행가능한 Rules 관리

Rule Engine에 의해 선정된마이크로 서비스의 스케쥴링 관리

Micro-Service의 실행 관리Micro-Service로의 입출력 데이터 관리

iRODS 서버 사이에 메시지 교환을 관리. 서로다른 저장소에서 실행되는 Micro-Service 사이에 메시지를 교환하기위해서는 필수

프레임워크 컴포넌트 사이, 상호작용 조정

iRODS Framework

iRODS 아키텍처

• iRODS 아티텍처 특징 (p.15-16)

– 데이터 그리드 아키텍처 (Data Grid Architecture)는분산된 저장소와 계산자원의 상호작용을 제어하는 클라이언트/서버 모델을 근간으로 함

– 데이터 속성들과 원격 서비스들(operations)에 의해생성된 상태정보를 관리, 유지하기 위해서 데이터베이스 시스템에서 관리되는 메타데이터 목록(Metadata Catalog)을 포함

– 조정가능한 규칙들을 시행 (enforcing and executing)하기 위한 규칙 시스템 (Rule System) 포함

iRODS 아키텍처

• iRODS Server 소프트웨어와 Rule Engine은 데이터가 저장되는 각각의 저장소 시스템에 설치된다.

• 저장소 시스템의 원격 위치는 Internet Protocol (IP) 네트워크 주소에 의해 정의된다.• iRODS Server는 서비스들(operations)을 원격 저장소 시스템에 의해 요구되는 프로

토콜로 변환한다.• Rule Engine은 저장소 시스템에서 수행되는 서비스들을 제어한다.

The components of the iRODS system

The components of the iRODS system

iRODS Data Grid

A client for accessing the Data Grid

Storage System

Storage System

iCAT Metadata Catalogs는 지속적인 상태 정보를 보유하고 있으며, Rule Base는 Rules을 보유하고 있음. Rule Base는 iRODS Server가 설치되는시점에 복제되어 설치됨. 2014년 현재, Metadata 목록 기능이 부여된 서버의 Rule Base 버전을 기준으로 iRODS Server의 Rule Base 자동 업데이트를 계획한다 되어있음

iRODS 서버와 서버는 peer to peer 서버 아키텍처를 가짐으로 서로 정보를 교환 할 수 있음

이용자가 iRODS 서버에 접속을 하면, 해당 서버와 iCAT-enabled 서버(메타데이터 목록을 보유하고 있는 서버)가 정보를 교환함

지속적인 상태 정보- 파일 이름- 파일 위치- 파일 소유자- 파일 checksum- 데이터 만료일 등

100개 이상의 attributes를파일 하나당 사용

iRODS 아키텍처

• Adaptive Middleware Architecture (AMA)– 미들웨어 시작시점에 미리 설정되는 환경을 제외하고,

프로그램 적으로 운영 흐름을 제어하지 못하는 일반적인 미들웨어와 다름

– 프로그래밍 변경 없이, 이용자 커뮤니티의 요구에 부합하도록 미들웨어를 조정할 수 있는 방법 제공

– AMA를 구현하는 다양한 방법론 중, Rule-Oriented Programming (ROP) 방법론 사용(p.15)

iRODS 아키텍처

• ROP 패러다임을 사용하여, 손쉬운 선언적 방식을 사용하여 데이터 관리 기능을커스터마이징하는 방법을 제공함 p.15

• iRODS 데이터 그리드 시스템 안에서 Rules로서 수행되는 프로세스들을 코딩함으로써 가능함.– Rules은 특정 태스크(task)에 의해서

액션(Action)이 호출되는 (invoked) 시점에 수행됨– C-functions은 Rule body 실행 시점에 호출됨

• tasks 흐름수정 방법 2가지– Rules을 실행할 때, 주어진 룰에 새로운 마이크로 서비스들 혹은 Rule 호출을 끼워 넣음으로

써 tasks의 흐름을 수정할 수 있음– 혹은 마이크로 서비스 코드를 변경하고 재컴파일 함으로써 tasks의 흐름을 수정할 수 있음

• 같은 task이지만, 높은 우선순위를 부여함으로써 새로운 Rule을 추가할 수 있음– 이렇게 추가된 Rule을 선제적 규칙 (preemptive Rule) 이라 함– 선제적 규칙은 original Rule 전에 수행되며, 오류 발생 시 original 규칙이 실행됨

iRODS 아키텍처

Rules = processes Action Tasksinvokeperform

Operations = Micro-services= C-functions

control

Modify the flow of tasks

coding

Mapping From Action to Storage Protocol

execute

원격 저장소

Standard Operations는 원격 저장소에서 실행됨. Posix I/O functions를 근간으로 함

• 하나의 주어진 Micro-service는 여러 개의Posix I/O 호출을 실행할 수 있음.

• 그러므로, 하나의 Micro-service는 원하는 하나의 행위(Action)으로 쉽게 묶는 중립적 기능의 수준을 제공함으로써, 절차들의 표현을 단순화 하기 위해 사용됨

• 새로운 driver를 작성하면 되므로 새로운 저장소 시스템 추가가 가능함

Mapped into the protocol

by driver

Actions 클라이언트

데이터 그리드

Mapped intothe Micro-services

영역flow

Posix I/O 호출은 저장소 디바이스에 위치한 파일의 부분적 입출력을 포함한다. 하지만 Data Grid에 연결된 모든 저장소가 이러한 기능을 제공하지않으므로, 보조 저장소에 파일 캐싱이 필요하다.

• Micro-Service는 C 언어로 작성되며, 특정 운영 시스템에 적합하도록 컴파일 됨

• Micro-Service는 다수의 저장소에서 실행될수 있으며, 실행이 연기되거나 주기적으로 실행될 수 있음

Server-side workflow vs. Client-side workflow

• iRODS 작동방식– 원격 저장소의 워크플로우 실행을 제어할 수 있다. 원격 프로시저들과

의 연결을 서버측 워크플로우라 함 (a server-side workflow)– 이는 클리이언트의 제어하에 있는 계산서버에서 실행되는 워크플로우

(client-side workflows)와 차별화 되는 것이다.– Kepler나 Taverna와 같은 그리드 컴퓨팅 프로세스 관리 시스템이 client-

side workflow이다. 이것들은 컴퓨터에 데이터를 옮기고, 데이터를 처리하고, 결과를 저장소에 옮긴다.

– iRODS는 computation을 저장소로 옮긴다. 이때 computation은 실행될 Rule의 형태이다. 그 다음 Rule을 적용하고 결과를 저장한다. 이것은Rule이 클라이언트로부터 요구되는 워크플로우를 대신함을 의미한다.

가상화 in iRODS

Workflow virtualization

Management policy virtualization

Service virtualization

Rule virtualization

• 끼워 맞춰진 조합된 (nested) Rules sets에 의해 Micro-services를 엮음으로써 워크플로우 개념을 표현함

• 이용자의 요청이 task들의 묶음으로 해석됨• 하나의 action이 실행되기 전에 전처리 관리 정책이 체크됨• Action 수행 후, 후처리 관리 정책이 체크됨. 예를 들어 jpeg 이미지 처리 후, 썸네일 생성

• ?? P.22

• ?? P.22

iRODS 컴포넌트

• C 라이브러리 인터페이스• 자바 입출력 클래스 라이브러리• 유닉스 유형의 쉘 명령

Rule Engine 역할

• 저장소에 위치한 Rule Engine은 Rule Base로 부터 호출할 Rules을 선택한다.

• 또한 환경설정 파일과 Metadata Persistent Repository로 부터 필요로 하는 현재 상태 정보를 조회한다.

• 그리고 세션 메모리에 현재 상태 정보를적재하며, Rules에 의해 지정된 Micro-services를 호출한다.

iRODSRule-Oriented Programming

Rule-Oriented Programming

• Rule-Oriented Programming = lego-block type programming• 레고블록은 Micro-services• Micro-service는 특정한 task를 수행하는 작고, 잘 정의된 프로시저/함수임

Micro-serviceex) createCollection

Micro-serviceex) computeChecksum

Micro-serviceex) replicateObject

task

task

task

수행

수행

수행

chain

Larger macro-level functionality = Action

Micro-serviceex) createCollection

Micro-serviceex) computeChecksum

Micro-serviceex) replicateObject

task

task

task

수행

수행

수행

chain

Action 1

Micro-serviceex) replicateObject

Action 3

Micro-serviceex) do002

task

task

task

수행

수행

수행

chain

Action 2

Micro-service 실행 우선순위 결정

[배경]• Action은 다양한 방법으로 실행될 수 있음• Action은 하나 이상의 Micro-service를 가짐• Micro-service를 엮은 chain에 여러 Action과

관련된 Micro-service가 존재할 수 있음

• [방법1]• 조건(condition) 활용• 조건은 Micro-service chain에 붙음• Triplet <action, condition, chain> = Rule• Quartet “recovery Micro-services chain”

• [방법2]• 우선순위(priority) 활용• 우선순위는 정수로 Rule에 결합되어 있음• 낮은 숫자가 우선순위가 높음• 우선순위는 초기단계에 Rule Files로 부터

Rules들이 읽혀지는 방법과 관련이 있음• 일찍 읽혀 Rule Base에 포함될 수록, 같은

Action을 위한 모든 Rule중에 비해우선순위가 높음 (p.26)

• Action은 Action을 포함 할 수 있으며, 포함된Action이 실행되어야 할때는 시스템이Rule application program을 호출함

Rule-Oriented Programming

• Triplet <action, condition, chain> = Rule• Quartet “recovery Micro-services chain”• Micro-service가 실패할 경우, Action의 실패를 의미함• 이경우, 우선순위가 낮은 Rule을 실행할 수 있음• 실패 이전에 성공한 Micro-service, Action의 결과(파일생성, iCAT에 적재된 메타데이

터 등 부작용)에 대한 처리 방침을 결정해야함• 실패할 경우, 어떠한 변화나 부작용이 없도록 하기 위해서, Rule 디자이너는

“recovery Micro-service or Action”을 명시해야 함• 실패할 경우, 실패전 성공했던 Micro-service or Action의 결과들도 복구해야함

• iRODS Rule Base 파일들에 Rule들이 담겨 있음.• iRODS Rule Base 파일 확장자는 “.irb“이며, server/config/reConfigs 디렉토리에

위치• 별도의 .irb 파일을 추가하고자 하는 경우, server/config/server.config 파일,

reRuleSet 변수에 ‘,’을 기준으로 여러 개 추가할 수 있음• 왼쪽에서 오른쪽으로 읽히며, 우선순위도 먼저 읽히는 Rule이 높음• 기본은 core.irb 파일

Rule-Oriented Programming

• 어떤 정보를 기반으로 Rule이 작동하는가?• iRODS 클라이언트와 서버의 연결시점부터 종료시점 까지를 세션(session)이라 함• 세션 기간동안 Actions와 Micro-services가 운영되는 두 개의 상태정보 공간 구성• Persistent 상태 정보 (#), Session 상태 정보 ($)• Persistent 상태 정보는 다른 세션에서 공유될 수 있는 정보로서, iCAT 메타데이터 목

록에 지속적으로 존재함• Session 상태 정보는 하나의 세션에서 데이터베이스에 접근하지 않고 Actions와

Micro-services가 상태 정보를 공유하고자 사용

• $ 구조는 복합C구조체이며, Rule Execution Infrastructure (REI)라 불림• 새로운 iRODS 버전이 구현됨에 따라, REI도 진화함• $ 의 물리적 구조를 숨기기 위해, Logical Name Space를 사용함• $ Logical Name Space는 ‘$variables’ 들 정의. 이는 REI 구조체의 값 노드에 매핑됨• 이러한 매핑은 ‘data variable mapping’ 파일 (.dvm 확장자 사용)에 정의 되어 있음.

‘.dvm’ 파일은 server/config/reConfigs 디렉토리에 위치해 있음• $variable 매핑은 시스템이 $variable을 REI 구조체의 경로(path name)로 해석하는 방

법이 정의 되어 있음

Rule-Oriented Programming

• #variables는 iCAT Metadata 목록의 속성집합에 의해정의된 Logical Name Space를 가짐

• iCAT 스키마의 테이블 컬럼과 #variables 매핑은lib/core/include/redsGenQuery.h에 정의 되어 있음

• Variable은 ‘iquest’라 불리는 일반적 쿼리로 접근이 가능

• iCAT 데이터베이스로부터 데이터에 접근하기 위해서‘iquest attrs’를 사용함. 이 쿼리는 persistent 상태 정보 속성 리스트를 제공함

SESSION 상태 정보 변수

룰에서 사용 가능한 세션변수

• 세션 변수들은 7개의 세트로 그룹화 됨• SuserAndConn, SdataObj1, SdataObj2,

SrescInfo, Scollection, SuserAdmin1, SuserAdmin2 p.56-57

Micro-services

• 마이크로 서비스는 간단한 일을 수행하는 잘정의된 프로시져/함수들을 말한다.

• 이하는 마이크로 서비스 네가지 구분– Core Micro-services : 룰 엔진 관리, 워크플로우

생성, 데이터 객체 저수준 관리 등– iCAT Services– Framework Services : 룰기반 원격 데이터베이

스 접근, 이메일 전송, 키-값 속성쌍, 이용자 정의서비스 등

– Module Micro-services : 특정 커뮤니티를 위해개발된 서비스들의 묶음 (HDF 관리, 이미지 속성관리, 웹서비스 상호작용, XML 처리 등)

PERSISTENT 상태 정보 변수

• Micro-services에 의해 생성된 Persistent 상태 정보들은 iCAT 메타데이터 목록에 저장된다.

• iCAT 목록을 질의 할 수 있다.• lib/core/include/rodsGenQuery.h 파일에 쿼리에서 사용할 수 있는 컬럼이 정의되

어 있다.

USER ENVIRONMENT VARIABLES• 각각의 iRODS 데이터 그리드는 메타데이터 목록(iCAT)을 필요로 한다.• iCAT은 하나의 데이터베이스에서 인스턴스로 관리된다.• 데이터베이스는 여러 개의 인스턴스를 관리할 수 있으므로, 우리는 각각의 인스턴스

를 위한 포트번호를 할당한다. 따라서 iRODS 데이터 그리드는 다음과 같이 식별된다.

irodsZone : irodsHost : irodsPort

• i-Commands 환경 변수 리스트 (p.38 참조)• iRODS 환경 파일 위치 (admin 계정으로 설치) : ~/.irods/.irodsEnv

iRODSRule System

iRODS Rule System

• iRODS 규칙들은 두 개의 그룹으로 분류될 수 있음

• System level rules – iRODS 서버에 의해 내부적으로 호출됨– iRODS 프레임워크 안에는 정책집행시점(policy enforcement

points)이 명확하게 정의되어 있음. 이 시점 도달하게 되면core.irb 파일로 부터 읽여진 관련된 정책을 iRODS가 호출함

• User level rules– irules command 혹은 rcExecMyRule API와 같은 클라이언트에

의새 외부적으로 호출됨– 전형적으로 워크플로우 형식의 규칙들로서, 이용자를 대신하여

iRODS 서버가 일련의 Micro-services를 이용자를 대신해 수행하도록 요청할 수 있음

– 데이터가 위치해 있는 서버에서 작업이 이루어지므로 효율적임

iRODS Rule System

• 실행모드에 따라서, 즉시 실행되는 규칙들과 백그라운드에서 나중에 실행되는 규칙들이 있음

• Delayed Execution Service는 Micor-services가 큐에 적제되어 Rule Execution Server에 의해 나중에실행되도록 할수 있음

• irule 명령어는 다음과 같은 입력 파라미터를 갖는다.– irule [—test] [-F inputFile] [ruleBody inputParam outParamDesc]

• irule 명령어는 iRODS 서버에 의해 실행될 사용자 정의 룰을 제공(submit)한다. 규칙을 포함하고 있는 파일은 다음의 세줄을 갖는다.

• 파라미터 설명– ruleBody—실행될 규칙 è 다음 슬라이드 참조– inputParam—입력 파라미터. 입력값이 없을 경우, “null”이라 표기– outParamDesc—출력 파라미터. 출력값이 없을 경우, “null”이라 표기

• irule 명령어 옵션– -test : 테스트 모드 실행. Micor-services는 실행되지 않음. 대신 loopback만 수행– -F inputFile : 입력값으로 파일 읽음– -v : verbose ??– - h : help

iRODS Rule System

• 규칙 예시– acCreateUser||msiCreateUser##acCreateDefaultCollections##msiCommit|msiRollback##msiRollback##nop

• This Rule invokes the following chained Micro-service and Rule: – msiCreateUser /* execute a Micro-service to create a new user */– acCreateDefaultCollections /* execute another Rule to create default collections */ – msiCommit /* register the new state information into the iCAT Metadata Catalog */

• The corresponding recovery Micro-services are: msiRollback– msiRollback /* delete user information from the iCAT Metdata Catalog */ – msiRollback /* delete collection information from the iCAT Metadata Catalog */ – nop /* no operation required */

규칙 구성

• Rule 구성 = – “|”로 구분되는 네개(name, condition, workflow-chain, recovery-chain)의 파트로

구성 된 한줄로 구성되어 있음– actionDef | condition | workflow-chain | recovery-chain

• “actionDef” : 규칙 이름. 다른 규칙이나 외부 함수(functions)에서 호출 시사용되는 식별자

• “condition” : 규칙이 실행되는 조건. 조건이 만족되어야 규칙이 실행됨. 일반적으로 세션 속성들이 조건을 구성하는데 사용됨.

– 조건 예1, $rescName = = demoResc8 è 만약, 저장소(storage resource) 이름이“demoResc8” 일 경우, 규칙이 실행됨

– 조건 예2, $objPath like /x/y/z/* è 데이터 객체나 컬렉션 경로 이름 조건으로서, 만약iRODS 데이터 그리드에 위치한 파일이 컬렉션 /x/y/z 위치에 있으면 규칙이 실행됨

규칙 구성

• “workflow-chain” : Micro-services/Rules의 시퀀스. – Micro-services/Rules 시퀀스는 “##” 기호에 의해 구분됨.

각각은 입출력 파라미터들을 포함할수 있음– 규칙은 다른 규칙을 호출 할 수 있음. 자신 호출도 가능

(recursion)

• “recovery-chain” : workflow-chain에 명시된 Micro-services/Rules 시퀀스 중 하나가 실패했을 경우, 실행될 Micro-services/Rules 시퀀스 시퀀스.– Micro-services/ Rules의 숫자가 workflow-chain의 것과

동일.– 만약 대응되는 Micro-service/Rule이 필요 없는 경우, “nop”

action이 명시되어야 함. workflow-chain 시퀀스 중 하나가실패를 하게되면 recovery-chain의 모든 시퀀스가 실행됨

Example Rules

• 원격 저장소 위치에서 server-side 워크플로우들로서, 수행되는 행위들(actions)의유형을 보여주기 위해, 규칙들 (Rules) 이제공된다.

• irods/clients/icommands/test 위치에Rule 예제들이 있음

• 규칙들의 구성• 규칙을 구성하는 마이크로 서비스들의 구

성

규칙, 마이크로 서비스 예

아래 규칙은 iCAT 메타데이터 목록에 쿼리를 보내, 명시된 Condition을 만족하는 파일들의 리스트를 조회한다.

//규칙 - listColl.ir RulemyTestRule(*Action, *Condition) {

acGetIcatResults(*Action,*Condition,*B); //마이크로 서비스foreach ( *B ) {

msiPrintKeyValPair(stdout,*B); //마이크로 서비스writeLine(stdout,*K); //마이크로 서비스

}}

INPUT *Action=list,*Condition="COLL_NAME = ‘/tempZone/home/rods/loopTest' ", *K="--------------------------" OUTPUT *Action, ruleExecOut

The “listColl.ir” Rule invokes the Micro-services:

iRODS 테스트

IRODS 설치 및 운영

• iRODS is split into two packages: – the core server software – the database plugin specific to the type of

database used (PostgreSQL in our case)

References

• iRODS Primer: Integrated Rule-Oriented Data System (2014)

Book in Synthesis Lectures on Information Concepts Retreival and Services – January 2010