JP2021530803A - クラウドプラットフォームでアプリケーションコンテナのボリューム（ストレージ）プロビゾニング方法 - Google Patents

クラウドプラットフォームでアプリケーションコンテナのボリューム（ストレージ）プロビゾニング方法 Download PDF

Info

Publication number
JP2021530803A
JP2021530803A JP2021502760A JP2021502760A JP2021530803A JP 2021530803 A JP2021530803 A JP 2021530803A JP 2021502760 A JP2021502760 A JP 2021502760A JP 2021502760 A JP2021502760 A JP 2021502760A JP 2021530803 A JP2021530803 A JP 2021530803A
Authority
JP
Japan
Prior art keywords
volume
cloud
application
cloud platform
insufficient
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2021502760A
Other languages
English (en)
Inventor
ファン クォン、ジェ
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Acornsoft Co Ltd
Namu Tech Co Ltd
Original Assignee
Acornsoft Co Ltd
Namu Tech Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Acornsoft Co Ltd, Namu Tech Co Ltd filed Critical Acornsoft Co Ltd
Publication of JP2021530803A publication Critical patent/JP2021530803A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G06F9/5016—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals the resource being the memory
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
    • G06F3/0604—Improving or facilitating administration, e.g. storage management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0629—Configuration or reconfiguration of storage systems
    • G06F3/0631—Configuration or reconfiguration of storage systems by allocating resources to storage systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
    • G06F3/0662—Virtualisation aspects
    • G06F3/0665—Virtualisation aspects at area level, e.g. provisioning of virtual or logical volumes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
    • G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
    • G06F3/0601—Interfaces specially adapted for storage systems
    • G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
    • G06F3/067—Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5072—Grid computing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5077—Logical partitioning of resources; Management or configuration of virtualized resources
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45579—I/O management, e.g. providing access to device drivers or storage
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Human Computer Interaction (AREA)
  • Mathematical Physics (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Stored Programmes (AREA)

Abstract

アプリケーションコンテナのボリューム割り当てが要請されれば、クラウドプラットフォームシステムが静的ボリューム生成であるか、または動的ボリューム生成であるかを判断する段階と、前記静的ボリューム生成であると、静的ボリューム登録リストを問い合わせし、登録された静的ボリュームが選択されて割り当て容量が入力されれば、可用空間を確認し、前記可用空間が不足ならば保存空間が不足であることを知らせて、再び登録された静的ボリュームが選択されて割り当て容量が入力されることを待機し、前記可用空間が不足ではなくて静的ボリューム容量を割り当てて情報を生成してボリューム割り当てを完了する段階と、及び前記動的ボリューム生成であり割り当て容量が入力されれば、可用空間を確認し、前記可用空間が不足ならば、保存空間が不足であることを知らせて、再び割り当て容量が入力されることを待機し、前記可用空間が不足でなければ保存経路を生成して容量割り当て及び情報を生成してボリューム割り当てを完了する段階と、を含むクラウドプラットフォームでアプリケーションコンテナボリューム(ストレージ)プロビゾニング方法を提供する。【選択図】 図１６

Description

本発明は、クラウドプラットフォームでアプリケーションコンテナのボリューム(ストレージ)プロビゾニング方法に関するものであり、より詳細するようにアプリケーションコンテナに必要な保存空間を割り当てることができるクラウドプラットフォームでアプリケーションコンテナのボリューム(ストレージ)プロビゾニング方法に関するものである。
クラウド(Cloud)はコンピュータサービス事業者サーバーを曇模様で表示する慣行によって‘サービス事業者のサーバー'で通じる。ソフトウェアとデータをインターネットと連結された中央コンピューターに保存してインターネットに接続さえすれば、いつどこでもデータを利用するようにするものである。
このようなクラウドはサービス提供形態によってSalesforce.com・Google e-mailなどのように複数の使用者にオンディマンド(On-demand)で提供されるアプリケーションサービスであるSoftware as a Service(SaaS)、AWS ＲＤＳ・Google App Engineなどのように開発用プラットフォームまたはアプリケーション実行に必要なソフトウェアスタックであるPlatform as a Service(PaaS)、ＡＷＳＥＣ２などのようにサーバーまたはストレージなどを使用者にサービス形態で提供するInfrastructure as a Service(IaaS)などで分けることができる。
また、クラウドは導入と配布形態によってただ一つの団体のみのために運営されるプライベートクラウド(Private cloud)、公開的利用のために開かれたネットワークを通じてレンダリングされるパブリッククラウド(Public cloud)、明らかな実体は維持するが、共に縛られているふたつ以上のクラウドの組合であるハイブリッドクラウド(Hybrid cloud)などでも分けることができる。
一方、エンタープライズクラウド(Enterprise Cloud)の場合企業のビジネスとＩＴ戦略を具現したクラウドでアプリケーションサービスを中心に技術とインフラをオーダーメード化して最適化することが何より重要であり、またアプリケーションを多様なインフラに構成するか、または配布することに容易でなければならない。
これに本出願人は、アプリケーションをコンテナ化する方法を出願して特許登録したことがある(特許出願第１０-２０１７-００５６４８３号)。
ところで、前記出願でアプリケーションコンテナにある保存空間は臨時的であり、再開始時に保存空間内のファイルが削除されることがある。
これに本発明は、このような前記問題点を解決するために創出されたものであり、アプリケーションコンテナに必要な保存空間を割り当てることができるクラウドプラットフォームでアプリケーションコンテナのボリューム(ストレージ)プロビゾニング方法を提供することにその目的がある。
しかし、本発明の技術的課題らは上で言及した課題らに制限されないし、言及されなかったまた他の技術的課題らは下の記載から当業者に明確に理解されることができるであろう。
本発明の実施例によるクラウドプラットフォームでアプリケーションコンテナのボリューム(ストレージ)プロビゾニング方法は、アプリケーションコンテナのボリューム割り当てが要請されれば、前記クラウドプラットフォームシステムが静的ボリューム生成であるか、または動的ボリューム生成であるかを判断する段階と、前記静的ボリューム生成であると、前記クラウドプラットフォームシステムが静的ボリューム登録リストを問い合わせして、登録された静的ボリュームが選択されて割り当て容量が入力されれば、前記クラウドプラットフォームシステムが可用空間を確認し、前記可用空間が不足ならば前記クラウドプラットフォームシステムが保存空間が不足であることを知らせて、再び登録された静的ボリュームが選択されて割り当て容量が入力されることを待機し、前記可用空間が不足ではなければ前記クラウドプラットフォームシステムが静的ボリューム容量を割り当てて情報を生成してボリューム割り当てを完了する段階と、及び前記動的ボリューム生成であり割り当て容量が入力されれば、前記クラウドプラットフォームシステムが可用空間を確認し、前記可用空間が不足ならば、前記クラウドプラットフォームシステムが保存空間が不足であることを知らせて、再び割り当て容量が入力されることを待機し、前記可用空間が不足ではなければ前記クラウドプラットフォームシステムが保存経路を生成して容量割り当て及び情報を生成してボリューム割り当てを完了する段階と、を含む。
本発明によるクラウドプラットフォームでアプリケーションコンテナのボリューム(ストレージ)プロビゾニング方法は、アプリケーションコンテナに必要な保存空間を割り当てることができる効果を有する。
本発明の一実施例によるクラウドプラットフォームシステムの構成図を示す。 図１のクラウド統合部の機能を簡略に示したものである。 図１のサービス管理部の機能を簡略に示したものである。 図１のアプリケーションオーケストレーション部の機能を簡略に示したものである。 本発明の一実施例によるアプリケーションコンテナ化のフレームワークを示す。 図１の開発/運営部の機能を簡略に示したものである。 図１の開発/運営部の機能を簡略に示したものである。 図１の開発/運営部の機能を簡略に示したものである。 図１の開発/運営部の機能を簡略に示したものである。 図１の開発/運営部の機能を簡略に示したものである。 図１の開発/運営部の機能を簡略に示したものである。 本発明の一実施例によるクラウドプラットフォームシステムのアーキテクチャーを示す。 カクテルサーバーの構成とその周辺アーキテクチャーを示す。 本発明の一実施例によるコンテナボリューム(ストレージ)概念図である。 本発明の一実施例によるボリューム情報登録を説明するための図面である。 本発明の一実施例によるクラウドプラットフォームシステムのコンテナボリューム(ストレージ)プロビゾニング方法を示した流れ図である。 本発明の一実施例によるボリューム情報登録画面の例示図である。 本発明の一実施例による登録ボリューム情報現況画面の例示図である。 本発明の一実施例によるボリュームを割り当てるための画面の例示図である。 本発明の一実施例によるボリュームを割り当てるための画面の例示図である。
本発明の長所及び特徴、そしてそれらを達成する方法らは添付される図面と共に詳細に後述されている実施例らを参照すれば明確になるであろう。しかし、本発明は以下で開示される実施例らに限定されるものではなく、また他の多様な形態で具現されることができるし、単に本実施例らは本発明の開示が完全であるようにさせて本発明が属する技術分野で通常の知識を有した者に発明の範疇を完全に知らせてくれるために提供されるものであり、本発明は単に請求項によって定義されるだけである。
明細書全体にわたって同一参照符号は同一構成要素を指称する。
以下、添付された図面らを参考して本発明の実施例によるクラウドプラットフォームシステムに対して説明するようにする。
図１は、本発明の一実施例によるクラウドプラットフォームシステムの構成図を示し、図２は図１のクラウド統合部の機能を簡略に示したものであり、図３は図１のサービス管理部の機能を簡略に示したもので、図４は図１のアプリケーションオーケストレーション部の機能を簡略に示したものである。
図５は、本発明の一実施例によるアプリケーションコンテナ化のフレームワークを示し、図６乃至図１１は図１の開発/運営部の機能を簡略に示したものである。
図１のクラウドプラットフォームシステムは、マルチ/ハイブリッドクラウド統合管理を基盤でアプリケーション可用性・拡張性を保障して開発・運営の効率化のためのビューと道具を提供する。以下、本発明のクラウドプラットフォームシステムを“カクテルクラウド(Cocktail Cloud)”と称することにする。
図１を参照すれば、カクテルクラウドは、クラウド統合部(Cloud Integration)１００・サービス管理部(Service Management)１１０・アプリケーションオーケストレーション部(Orchestration)１２０・開発/運営部(DevOps View)１４０及びＤＢ/保存所１５０を含む。
クラウド統合部(Cloud Integration)１００はマルチ/ハイブリッドクラウドのインフラを自動構成してアプリケーションに提供して管理のための構成情報を同期化する役割を遂行する。
クラウド統合部１００はクラウドプロビジョニング(Cloud Provisioning)とクラウド同期化(Cloud Synchronization)の機能を遂行する。
図２を参照すれば、クラウドプロビジョニング機能はアプリケーションクラスター(カクテルクラスター)にクラウドネットワークインフラを構成及び提供し、アプリケーションにクラウドのコンピュータインフラを構成及び提供する機能である。そして、物理インフラ(Bare Metal)の場合クラスター設定道具を提供する。サポートクラウドはPublicの場合AWS・Azure・Aliyun・Google Computing Engineであり、Privateの場合Openstack・VMWearであり、以外にOn-premise・DatacenterBare Metal Infraがあることができる。
クラウド同期化機能は、クラウドインフラ構成情報を統合構成ＤＢ１６０に保存及び管理し、運営時インフラ変更情報を統合構成ＤＢ１６０と同期化する機能である。
サービス管理部(Service Management)１１０はアプリケーションクラスターを管理する論理的グループとしてクラウド計定と使用者、ネットワーク資源を割り当て及び管理する役割を遂行する。すなわち、サービス管理部１１０は統合計定管理機能・ネットワーク管理機能及び使用者管理機能を遂行する。
図３を参照すれば統合計定管理(Cloud Provider)機能は、マルチクラウド計定及び接続情報を統合管理し、ネットワークとクラウドプロビジョニング構成に使用される機能である。
ネットワーク管理機能はクラウドネットワークを構成してサービスに割り当てる機能である。例えば、AWSのVPC・Subnetであることがある。一つのサービスはマルチクラウドの供給者のネットワークを使ってクラスターを生成してアプリケーションを構成・運営する。
使用者管理機能はサービスを管理するチーム構成員と開発/運営に必要な権限を管理する機能である。ここで、権限は全社サービス管理権限(Admin)、全社サービス問い合わせ権限(Manager)、構成員に割当されたサービス管理権限(DevOps)などを含むことができる。使用者は多くのサービスに構成員で参加可能である。
アプリケーションオーケストレーション部(Orchestration)１２０はアプリケーションの配布と可用性・拡張性を保障する機能としてカクテルクラスター(Cluster)の核心機能を担当する。
アプリケーションオーケストレーション部１２０はアプリケーション配布(Deployment)機能・複製(Replication Control)機能・ローリングアップデート(Rolling Update)機能・スケーリング(Scaling)機能及びモニタリング(Monitoring)機能を遂行する。
図４を参照すればアプリケーション配布機能は、コンテナイメージ基盤の配布で別途設定と構成作業が必要ない容易性を提供し、アプリケーション配布時クラウドインフラを自動プロビジョニングする機能である。
ここで、アプリケーションはコンテナ化されて配布されるようになるが、アプリケーションコンテナ(以下、“コンテナ”と称する)はアプリケーションプロセスにホスト資源を割り当てて隔離して仮想化したＯＳ上の独立システムを言う。
コンテナに使用される核心技術は、Linux（登録商標）のcgroup(control group)とnamespaceである。cgroupはＯＳ上のプロセスにホスト資源を割り当てるために該当プロセスグループを作って資源の割り当て及び管理を遂行する。namespaceはプロセス・ネットワーク・マウンド(mount)などを特定name spaceで隔離する技術である。これによってコンテナはcgroupを通じてアプリケーションプロセスに資源を割り当て、namespaceで隔離したＯＳ上に仮想化された独立システムを言う。
コンテナはハイパーバイザー(Hardware emulator)とゲストＯＳを使わない軽いＯＳ仮想化方式でホスト資源の消耗量がほとんどなく、機動に入る時間が非常に少なくてアプリケーション仮想化に好適な技術である。また、ＯＳ上の仮想化で既存物理サーバー(Bare Metal)・仮想サーバー(Virtual Machine)などインフラに独立的な構成と配布が可能である。
このように既存または新規アプリケーション構成をコンテナで切り替えるためには、コンテナ化(Containerization)過程が隋伴されなければならない。そして、これによる開発・テスト・運営方式の転換及び運営インフラ構成(カクテルクラウドプラットフォーム)最適化作業を並行しなければならない。
既存アプリケーションをコンテナに切り替えるためには、アプリケーションの設定及びソースではない構成の転換が必要であり、配布と運営効率を考慮する時ワークロード(Workload)中心の役割別独立的構成が一般的であり、複製を通じた多重化とスケーリングを考慮した構成が設計されて適用されなければならないであろう。
アプリケーション開発・テスト・運営方式の転換のためにはイメージ基盤のアプリケーションビルド・テスト・配布とベースイメージを通じたアプリケーション構成が標準化されなければならないであろう。
アプリケーションコンテナ運営インフラ構成最適化のためにはコンテナオーケストレーションのためのクラスター中心のインフラが構成され、複製・スケーリングを考慮したコンピュータ容量が算定(予備容量最小化、必要時拡張容易)されなければならないし、共有ストレージ・保安・ネットワークなど関連インフラを構成しなければならないであろう。
図５を参照すればコンテナ化は、大きく分析及び構成設計(Ｓ１００)・コンテナ転換(Ｓ２００)・運営移管(Ｓ３００)で区分される。
分析及び構成設計(Ｓ１００)のためにコンテナ/クラウド導入目的と戦略を考慮して既存アプリケーションのうちでコンテナ転換対象を選定する(Ｓ１１０)。
対象アプリケーションが選定されれば、対象アプリケーションを分析する(Ｓ１２０)。この時、アプリケーション・インフラ・データ・連携構造などのアプリケーション現況及び資料調査をして、開発及び運営・管理者の要求を収集する。そして、コンテナ構成方向・イシュー及び解決方案を導出する。
そして、分離/統合・連携・可用性・拡張性・保安などを考慮して対象アプリケーション別コンテナ構成を設計する(Ｓ１３０)。この時、ベースイメージ・環境変数・包含項目・コメンドなどのイメージビルドテンプレートを定義することができる。
その後、インフラ構成を設計する(Ｓ１４０)。転換インフラ(クラウド/ベアメタル)供給者を選定し、アプリケーションコンテナ別容量を算定する。そして、コンテナクラスターノード数及びインフラ容量を算定し、ストレージ・ネットワーク・保安構成を設計する。
インフラ構成が設計されれば、コンテナ転換方案を樹立する(Ｓ１５０)。この時、アプリケーション別転換詳細方案を樹立し、転換業務及び組織/役割を定義し、転換日程を樹立する。そして、報告及びフィードバックを反映する。
コンテナ転換(Ｓ２００)のためには、繰り返し/漸増的転換(Ｓ２１０)が必要である。辞書テスト(PoC)、アプリケーション別段階的転換など繰り返し的で漸増的に切り替える。
そして、カクテルクラスターを構成(Ｓ２２０)するためにカクテルクラウドプラットフォームを設置及び構成し、ネットワーク・共有ストレージ・保安など基盤インフラを構成する(クラウドの場合カクテルでプロビジョニング)。基盤インフラ割り当て及び使用者登録を通じてカクテルサービスとクラスターを生成し、クラスター構成を検証する。
そして、アプリケーション転換(Ｓ２３０)のためにアプリケーションコンテナを構成し、必要時アプリケーション設定及びソースを変更する。転換コンテナの機能及び設定などを検証し、コンテナ配布イメージビルド及びレジストリに登録する。そして、カクテルサーバーを生成してテストする。
データ転換(Ｓ２４０)のために対象アプリケーションコンテナ切り替え、Persistenceボリューム設定などを通じてカクテルサーバーを設定し、データを抽出してカクテルサーバーに送る。この機種ＤＢソリューション適用の場合データ変換を遂行し、データ整合性を確認する。運営アプリケーションの場合ダウンタイムを最小化するためにデータ同期化ソリューションを適用する。
その後、検証されたコンテナをカクテルサーバーに配布し、アプリケーション機能及び性能テストを遂行し、コンテナ及びインフラにテスト結果を反映する(Ｓ２５０、Ｓ２６０)。
運営移管(Ｓ３００)のために運営配布/オープン(Ｓ３１０)が遂行されるが、具体的に運営カクテルクラスターを生成して転換完了されたイメージを基盤でカクテルサーバーを生成して連携構成する。そして、運営データを移管してアプリケーションをオープンする。このようなアプリケーションコンテナを配布・運営・管理する技術をコンテナオーケストレーション(Orchestration)と称する。
コンテナオーケストレーションは物理/仮想インフラに管理クラスター(Managed Cluster)を構成してアプリケーションコンテナを配布・運営・管理する技術であり、コンテナの軽くて早い起動性と移動性の長所を活用して既存社内、データセンターインフラのクラウド化とプライベート/パブリッククラウドのアプリケーション管理プラットフォームで拡散している。
カクテルクラウドモニタリングビューを通じてアプリケーション及びインフラ運営モニタリングを遂行して性能イシュー及び間違いを反映する(Ｓ３２０)。
開発・運営体系移管及び適用(Ｓ３３０)のためにコンテナ移管結果をレポートし、担当開発及び運営組織にコンテナ基盤開発/運営体系教育を実施し、カクテルクラウドプラットフォーム使用教育を実施する。
これによってコンテナは次のような長所を有する。
第一、コンテナは独立性を有する。
隔離されたアプリケーション実行環境であり、独立的な資源が割り当てされ(ＣＰＵ、Memory、Disk、Networkなど)、同一ホスト上多重アプリケーションが運営される。
第二、コンテナは軽い仮想化を具現する。
ＯＳ水準の仮想化(Non Hypervisor)が可能であり、早い操作が可能で(生成・実行・再始作など)、少ない大きさのコンテナイメージで配布及びアップデートが効率的である。
第三、コンテナは移動性を有する。
インフラは独立的イメージを有して、ベアメタル(Bare Metal)・仮想マシン(Virtual Machine)・クラウド(Cloud)などどこでも移動が可能で、イメージレジストリを通じたオンライン配布及びバージョン管理が可能であり、主要ホストＯＳ(Linux（登録商標）系列、Windows)を支援する。このようなコンテナの移動性はマルチ/ハイブリッドクラウド環境下にアプリケーション運営/開発の生産性及び効率を高めて特に、規格化されたコンテナイメージで異種のインフラにアプリケーション配布及び以前の難しさを解決して特定クラウドに属するロックイン(Lock-in)問題を解決してくれる。
複製機能はアプリケーション安全性と可用性のために初期指定した複製数(多重化)を維持し、アプリケーションコンテナヘルスチェック(Health Check)を通じて異常時再起動する方式でＯＳ再起動方式より早くて効率的である。複製されたアプリケーションはロードバランシングを通じてサービスされる。
ローリングアップデート機能はアプリケーションサービスの中断なしに配布・インフラ変更などのアップデート作業を遂行し、多くのアプリケーション間の依存性がある場合DevOps Viewの作業(job)管理機能を通じて自動化を構成する機能である。
スケーリング機能はアプリケーションのモニタリングを通じてインスタンスのスケーリングをイン(In)/アウト(Out)して、アプリケーションインフラの場合資源容量のスケールを業(Up)/ダウン(Down)する機能である。そして、モニタリング情報を通じてスケーリング自動化を構成する。
モニタリング機能はアプリケーションインスタンス(コンテナ+インフラ)をモニタリングし、臨界値設定を通じたアラームを発生及び管理する機能である。
開発/運営部(DevOps View)１４０はサービス現況機能、クラスターマップ機能、モニタリングビュー機能、リソース管理機能、メータリング機能、作業管理機能、及び全社現況管理/分析機能を含む。それぞれの機能を図６乃至図１１を参照して説明すれば次のようである。
サービス現況機能はカクテルクラウドの全体アプリケーションクラスターの現況をサービス中心に把握することができるビュー(図６参照)を提供する。ここにサービス現況・クラスター現況・モニタリングアラームなどの項目が表示されることができる。
サービス現況ではカクテルクラウドの全体サービス現況を問い合わせすることができるし、サービス内のクラスターの構成現況を総合してクラウド供給者・クラスター・サーバー・クラウドコンポネント・現在月使用費用などを把握することができる。ここでクラスターは、アプリケーションの構成単位を意味し、サービスはクラスターの論理的グループを意味する。
クラスター現況ではクラスターの供給者・リージョン・サーバー・クラウドコンポネント・月使用費用をカード形態で問い合わせ可能であり、物理(Bare Metal)クラスターの場合使用費用は除かれることができる。
モニタリングアラーム表示機能ではクラスター内のアプリケーションとインフラでアラームが発生した場合、クラスターカードで確認が可能である。
クラスターマップ機能はカクテルサーバー(アプリケーション)の構成と状態情報をマップ形態で視覚化して管理することができるビューを提供する(図７参照)。
クラスターマップはクラスターのサーバーとクラウドコンポネント構成をマップ形態で問い合わせ/管理して構成情報の可視性を高める。クラスターマップではカクテルサーバー・クラウドコンポネント・サーバーグループなどの項目を含むことができる。
カクテルサーバーはアプリケーションオーケストレーションの基本単位でロードバランシング・アプリケーションコンテナ・インフラで構成され、マルチ/ハイブリッドクラウド管理に標準化されたインターフェースを提供する。カクテルサーバーはサーバー内のアプリケーション状態と複製、資源使用量を確認してスケーリング・ローリングアップデートなどを管理遂行する。カクテルサーバーは複製機能の有無によってマルチとシングルインスタンスタイプで区分される。AWSではマルチゾーンオプションを支援する。
クラウドコンポネントは供給者が提供するPaaSサービスを管理する。例えば、AWSのＤＢサービスであるＲＤＳであることがある。
サーバーグループはサーバー構成の論理的グループを管理的便宜性を提供する。
モニタリングビュー機能はクラスター内のアプリケーションとインフラの資源容量と状態を確認してクラウドリソースの状態を確認することができる情報を提供する(図８参照)。
モニタリングビューはクラスター内のアプリケーションとインフラに対するモニタリング情報を視覚化して提供し、ＣＰＵ・メモリー・ディスクの平均・ＴＯＰ情報提供で資源の使用量を確認して運営で対応できるようにする。
モニタリングビューはビュー転換(トレンド/データ)項目、対象転換(サーバー/リソース)項目などを含むことができる。
ビュー転換項目でトレンドビュはサーバーと複製されたインスタンス・アプリケーションコンテナに対する時間別モニタリング情報を提供し、データビューは現在時間の平均・ＴＯＰモニタリング数値を提供する。
対象転換項目でモニタリング対象はクラスター内のサーバーとクラウドインフラのリソースで区分される。クラウドリソースは供給者が提供する情報を使用する。
リソース管理機能はアプリケーションを構成するクラウドインフラのリソースを確認して必要時詳細設定を調整することができるビュー(以下、“リソース管理ビュー”と称する)を提供する(図９参照)。
リソース管理ビューはカクテルサーバーを構成するクラウドインフラリソースを確認して設定を詳細的に変更することができる。ここでカクテルサーバーは、アプリケーションオーケストレーションのための基本構成を自動で遂行するが、必要な場合直接クラウドリソースを調整する必要がある時に使用される。
リソース管理ビューはリソース情報/アクション項目を含むが、リソース情報のうちでアプリケーションはコンテナ設定と配布情報を管理する。クラウドリソース情報はロードバランサー・インスタンス(ＶＭ)・保安で構成され、インスタンスは容量とボリュームを管理する。調整が必要なリソース情報はアクションを通じて遂行される。
メータリング機能はアプリケーションが使用するクラウドインフラリソースの費用情報を確認することができるビュー(以下、“メータリングビュー”と称する)を提供する(図１０参照)。メータリングビューはクラスターインフラ使用費用項目・サーバー・リソース別費用項目などを含むことができる。
クラスターインフラ使用費用項目ではクラスターとカクテルサーバーが使用するクラウドリソースの費用現況を確認することができるし、前月・現在月費用情報と翌月推定費用を提供する。また月別で費用増減推移グラフを提供する。
サーバー・リソース別費用項目はカクテルサーバー別で使用するクラウドリソース費用をＴＯＰを基準で提供し、クラウドリソース種類別で使用する費用をＴＯＰを基準で提供する。
作業管理機能は配布・遠隔命令・リソース管理などの運営作業をスケジューリング/自動化することができる管理ビュー(以下、“作業管理ビュー”と称する)を提供する(図１１参照)。
作業管理ビューはアプリケーションとインフラの運営のためのスケジューリング及び一括処理機能を提供する。このような作業管理ビューは作業現況項目、作業管理項目などを含むことができる。
作業管理ビューで作業現況項目は配布・遠隔命令語・リソース管理タスクで区分して各タスクを組み合わせて構成される。ここで配布は、アプリケーション配布、遠隔命令語はＯＳ命令語を遠隔で遂行、リソース管理はスケーリング、状態/設定変更を意味する。
作業管理ビューで作業管理項目は直ちに遂行・スケジューリング・アラーム発生によって遂行方式を設定することができる。アラーム発生による遂行は容量モニタリングの基準値による自動スケーリングなどで使用される。作業管理項目で作業の実行状態とログ確認を提供する。
全社現況管理/分析機能は全社アプリケーション・クラウド・費用現況を把握して分析することができるカクテルダッシュボード(Dashboard)を提供する。
カクテルダッシュボードは全社次元でアプリケーションとクラウドインフラの現況を問い合わせして費用/予算管理、費用最適化分析、統計レポートを提供するビューである。このようなカクテルダッシュボードはアプリケーション現況項目、クラウド現況項目、費用/予算管理、費用最適化分析項目、統計/レポート項目を含むことができる。
アプリケーション現況項目を通じてカクテルサーバー・クラスター・クラウドコンポネントの標準化された要素を基準でアプリケーションとインフラ現況を全社的に把握して問い合わせすることができるし、サービス中心の現況ビューを提供する。
クラウド現況項目を通じて全社で使用するクラウドを供給者・リージョン・リソース別で現況を把握することができるし、インフラ中心の現況ビューを提供する。
費用/予算管理、費用最適化分析項目を通じて全社クラウド費用現況を把握してサービス別予算割り当て/統制と最適化分析を通じてクラウドリソース費用効率化ができる情報を提供する。
統計/レポート項目は分析及び報告に必要な統計情報とレポートビューを提供する。
ＤＢ/保存所１５０でイメージ保存所(レジストリ)１８０はアプリケーションコンテナの登録・共有・ダウンロード・検索・バージョンを管理し、モニタリングＤＢ１７０はアプリケーションとインフラのモニタリング情報を管理し、統合構成ＤＢ(Configuration ManagementＤＢ、ＣＭＤＢ)１６０はプロバイダー・ネットワーク・サービス・クラスター・サーバー・コンポネント・クラウドリソースの構成情報を管理する。
図１２は、本発明の一実施例によるクラウドプラットフォームのアーキテクチャーを示し、図１３はカクテルサーバーの構成とその周辺アーキテクチャーを示す。
図１２を参照すれば、カクテルクラウドはカクテルクラスター２００、プロバイダープラグイン２１０、サーバーマネージャー２２０、DevOpsマネージャー、ＣＭＤＢ１６０、モニタリングＤＢ１７０、イメージレジストリ１８０、ＡＰＩサーバー２９０、使用者コンソール３００を含む。
カクテルクラスター２００はオーケストレーション基盤アーキテクチャーを提供してプロバイダープラグイン２１０はクラウド供給者ＡＰＩ２８０を通じて統合管理のための基本モジュールで使用される。
クラスター２００はノードとマスターで構成され、ノードの場合ワーカー(worker)３１０を通じてマスターの命令語を処理する構造である。ワーカー３１０はマスターとの通信を担当して遂行命令語によってExecutorが支援される。Monitoring Executor３２０はノードとコンテナモニタリング情報を収集して、Command Executor３３０はＯＳとコンテナ命令を遂行する。その外にContainer Engine(Docker)３４０がある。
プロバイダープラグイン２１０はマルチクラウドとBare MetalのためのKubernetes ＡＰＩ支援のためのＡＰＩ Rapperであり、プロバイダー拡張のためのプラグインモジュールで構成される。カクテルサーバーはアプリケーションオーケストレーションの基本単位であり、クラスターマスター２００とプロバイダープラグイン２１０を通じてコンテナとクラウドインフラの複製・スケーリング・ローリングアップデートを遂行する。
カクテルサーバーは図１３に示されたようにコンテナとクラウドインフラで構成されるが、ロードバランサー・インスタンス(ノード)・コンテナ・ボリューム・保安などで構成され、AWSの例えば、ELB・EC２Instance・Security Group・ESBであることがある。カクテルサーバーはクラウド提供者のPaaSのためにクラウドコンポネントを提供する。例えばAWSのＲＤＳであることがある。
サーバーマネージャー２２０はサーバー内のアプリケーションコンテナとインフラのオーケストレーションを遂行する制御モジュールとして、非正常終了されたコンテナを再始作/復旧する複製制御、スケールイン/アウトとインスタンスタイプとボリューム拡張を通じたアップダウンを遂行するスケーリング、アプリケーションコンテナ配布を順次に無中断で遂行するローリングアップデート機能を提供する。
DevOpsマネージャーはマルチクラウドインフラプロビジョニングのための構成管理(Configuration Manager)２３０、マルチクラウド資源の使用量及び費用管理のためのメータリング管理(Metering Manager)２４０、マルチクラウド資源現況及び設定管理のための資源管理(Resource Manager)２５０、コンテナ/インフラモニタリング情報収集及び管理のためのモニタリング管理(Monitoring Manager)２６０、多くの作業タスクを結合して一括遂行して直ちに遂行・遂行時間・イベント発生が遂行条件であり、配布・サーバーアクション・遠隔命令語のタスクのための作業管理(Job Manager)２７０を提供するものとしてDevOpsのためのマネージャーモジュールである。
カクテルクラウドはアプリケーションとインフラの構成情報管理・モニタリング情報管理・アプリケーションコンテナイメージ管理のためのＤＢを提供し、使用者とプログラミングのためのインターフェースを提供する。
ＣＭＤＢ１６０はプロバイダー・ネットワーク・サービス・クラスター・サーバー・コンポネント・クラウドリソースの構成情報を管理する。
モニタリングＤＢ１７０はアプリケーションとインフラのモニタリング情報を管理する。
イメージレジストリ１８０はアプリケーションコンテナの登録・共有・ダウンロード・検索・バージョンを管理する。
ＡＰＩサーバー２９０はカクテルクラウドのすべての機能をＡＰＩ２８０に提供し、企業戦略によるオーダーメード化と他のソリューションとの連携を支援する。
使用者コンソール(Console)３００はWeb GUI形態で提供される。
このようなカクテルクラウドは次のように活用されることができる。
第一、マルチクラウドとして活用されることができる。
カクテルクラウドは標準化コンポネントを通じて異質的で複雑なマルチクラウド環境の統合管理のためのプラットフォームであり、またアプリケーション中心の企業クラウド全量を具現する。具体的に、カクテルクラウドはプロバイダー・ネットワーク・サービス・クラスター・サーバー・クラウドコンポネントを通じて管理対象を標準化して異質的で複雑なマルチクラウドリソースの統合管理(統合計定・資源・費用)する標準化管理コンポネントである。また、アプリケーションはビジネスの核心資源であるが、カクテルクラスターを通じてアプリケーション可用性と拡張性が強化され、カクテルDevOps Viewを通じた開発/運営業務効率化を通じてアプリケーション中心の企業クラウドを具現することができる。
第二、カクテルクラウドは社内、データセンターBare Metalインフラのクラウド化を通じてハイブリッドクラウドを構築/運営の基盤を提供する。また、複雑なハイブリッドインフラの統合管理と開発/運営効率化を提供する。
具体的に社内、データセンターのBare Metalインフラにアプリケーションクラスターを構成してコンテナ基盤のクラウド環境を駆逐することで別途の仮想化のためのプラットフォームが不必要であり、可用性・スケーリングなど拡張性を提供し、既存プライベートとパブリッククラウドを統合管理することができる物理インフラのクラウド化を具現することができる。
また、カクテルクラウドの標準コンポネントを通じて管理し、カクテルクラウドDevOpsビューを通じた開発/運営業務効率化を提供する。
第三、カクテルクラウドはコンテナとＣＩ/ＣＤのための自動化を通じてクラウド上のアプリケーションの効率的管理とマイクロサービスの構築及び運営プラットフォームを提供する。
カクテルクラスターはコンテナを基盤でクラウドインフラでアプリケーション配布及び管理環境を提供(クラウドネイティブアプリケーション)する。ここで、カクテルクラスターはマイクロサービスを駆逐して管理する基本単位である。
カクテルDevOpsビューの作業管理は、アプリケーションをビルドして配布することができる自動化基盤を提供し、コンテナはＣＩ/ＣＤをより軽くて容易に遂行することができる技術である。カクテルクラウドはマルチ/ハイブリッドクラウド上にアプリケーションを配布/運営することができるプラットフォームを提供する。
第四、カクテルクラウドはクラウドサービスブローカーのインフラ再販売及びサービス提供プラットフォームとしても活用されることができる。
パブリッククラウド・データセンターインフラを統合管理して使用者に再販売とクラウド管理プラットフォームをサービス形態で提供するＣＳＢ用プラットフォームをカクテルクラウドで構築・運営し、SaaSのためのマルチテナンシーとビリングシステムを提供し、大きい規模の企業の場合系列会社クラウド提供及び管理プラットフォームで活用可能である。
また、既存データセンター事業者のインフラをクラウド化して提供し、パブリッククラウド提供者に特化されたサービス(カクテルクラウドコンポネント(PaaS))を提供する。
一方、コンテナにある保存空間は臨時的であり再開始時保存空間内のファイルが削除される問題点がある。このような問題で本クラウドプラットフォームシステムは、ボリューム客体を利用して外部の保存空間とコンテナを論理的に連結して使用するコンテナボリューム(ストレージ)プロビゾニング機能を提供する。
本発明のコンテナボリューム(ストレージ)プロビゾニング機能は、ＧＵＩ上で多様な保存ストレージ(nfs、クラウドストレージなど)にボリューム情報を生成し、コンテナに必要な保存空間を割り当て管理する機能である(図１４参照)。
ボリューム情報登録は、図１５に示されたように静的(static)ボリューム生成と動的(dynamic)ボリューム生成で分けられることができるし、静的ボリューム生成は事前に構成した保存空間経路を指定して該当保存空間のみで使用されるものであり、動的ボリューム生成は保存空間草(pool)を生成してコンテナがボリューム要請時必要な空間位動的に割り当てて提供するものである。
図１６は、本発明の一実施例によるクラウドプラットフォームシステムのコンテナボリューム(ストレージ)プロビゾニング方法を示した流れ図である。
先ず、ボリューム割り当てが要請されれば(Ｓ４００)、クラウドプラットフォームシステムは静的ボリューム生成であるか、または動的ボリューム生成であるかを判断する(Ｓ４１０、Ｓ４９０)。
静的ボリューム生成であると、クラウドプラットフォームシステムは、静的ボリューム登録リストを問い合わせする(Ｓ４２０)。登録された静的ボリュームが選択されて容量割り当てが要請されれば(Ｓ４３０、Ｓ４４０)、クラウドプラットフォームシステムは、可用空間を確認する(Ｓ４５０)。可用空間が不足ならば、クラウドプラットフォームシステムは保存空間が不足であることを知らせて(Ｓ４６０)、Ｓ４３０段階に復帰する。反面、可用空間が不足ではなければクラウドプラットフォームシステムは静的ボリューム容量を割り当てて情報を生成してボリューム割り当てを完了する(Ｓ４７０、Ｓ４８０)。
動的ボリューム生成であると、クラウドプラットフォームシステムは、容量割り当てを要請して可用空間を確認する(Ｓ５００、Ｓ５１０)。可用空間が不足ならばクラウドプラットフォームシステムは保存空間が不足であることを知らせて(Ｓ５２０)、Ｓ５００段階に復帰する。反面、可用空間が不足ではなければクラウドプラットフォームシステムは保存経路を生成して容量割り当て及び情報を生成してボリューム割り当てを完了する(Ｓ５３０、Ｓ４８０)。
図１７は、本発明の一実施例によるボリューム情報登録画面の例示図であり、図１８は本発明の一実施例による登録ボリューム情報現況画面の例示図である。
図１７に示されたようにボリューム情報を生成するためにストレージにボリューム使用情報を登録することができる。図１７で登録されたボリューム情報は、図１８の登録ボリューム情報現況で確認することができる。
図１９及び図２０は、本発明の一実施例によるボリュームを割り当てるための画面を示したものであり、図１９は既生成されたボリューム情報を選択してボリューム名前、アクセスモード、割り当て容量を入力するボリューム類型設定機能を含んで、図２０は割り当てたボリュームの経路とコンテナ上の経路をマッピングするボリュームマウント機能を含む。
一方、上述した本発明の実施例らはコンピューターで実行されることができるプログラムで作成可能であり、コンピューターで読める記録媒体を利用して前記プログラムを動作させる汎用デジタルコンピューターで具現されることができる。前記コンピューターで読める記録媒体は、マグネチック保存媒体(例えば、ロム・フロッピー・ハードディスクなど)、光学的判読媒体(例えば、CD-ROM・DVDなど)及びキャリアウエーブ(例えば、インターネットを通じた伝送)のような保存媒体を含む。
このように本発明によるクラウドプラットフォームでアプリケーションをコンテナ化する方法によれば、隔離されたアプリケーション実行環境を提供し、独立的な資源割り当てが可能であり、同一ホスト上の多重アプリケーション運営が可能なだけでなく、ＯＳ水準の仮想化で早い操作が可能であり、少ない大きさのコンテナイメージで配布及びアップデートが効率的であり、どこでも移動が可能である。
また、本発明によるクラウドプラットフォームシステムは外部の保存空間とコンテナを論理的に連結してアプリケーションコンテナに必要な保存空間を割り当てることができる。
今まで本発明に対してその望ましい実施例らを中心によく見た。本発明が属する技術分野で通常の知識を有した者は、本発明が本発明の本質的な特性から脱しない範囲で変形された形態で具現されることができることを理解することができる。それで、開示された実施例らは限定的な観点ではなく、説明的な観点で考慮されなければならない。本発明の範囲は前述した説明ではなく、特許請求範囲に現われているし、それと同等な範囲内にあるすべての差異は本発明に含まれる。
本発明によるクラウドプラットフォームでアプリケーションコンテナのボリューム(ストレージ)プロビゾニング方法は、アプリケーションコンテナに必要な保存空間を割り当てることができる効果を有する。

Claims (1)

  1. アプリケーションコンテナのボリューム割り当てが要請されれば、クラウドプラットフォームシステムが静的ボリューム生成であるか、または動的ボリューム生成であるかを判断する段階と、前記静的ボリューム生成であると、前記クラウドプラットフォームシステムが静的ボリューム登録リストを問い合わせして、登録された静的ボリュームが選択されて割り当て容量が入力されれば、前記クラウドプラットフォームシステムが可用空間を確認し、前記可用空間が不足ならば前記クラウドプラットフォームシステムが保存空間が不足であることを知らせて、再び登録された静的ボリュームが選択されて割り当て容量が入力されることを待機して、前記可用空間が不足ではなければ前記クラウドプラットフォームシステムが静的ボリューム容量を割り当てて情報を生成してボリューム割り当てを完了する段階と、及び前記動的ボリューム生成で割り当て容量が入力されれば、前記クラウドプラットフォームシステムが可用空間を確認し、前記可用空間が不足ならば、前記クラウドプラットフォームシステムが保存空間が不足であることを知らせて、再び割り当て容量が入力されることを待機して、前記可用空間が不足ではなければ前記クラウドプラットフォームシステムが保存経路を生成して容量割り当て及び情報を生成してボリューム割り当てを完了する段階と、を含む
    ことを特徴とするクラウドプラットフォームでアプリケーションコンテナボリューム(ストレージ)プロビゾニング方法。

JP2021502760A 2018-07-19 2019-07-15 クラウドプラットフォームでアプリケーションコンテナのボリューム（ストレージ）プロビゾニング方法 Pending JP2021530803A (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
KR1020180084022A KR101987668B1 (ko) 2018-07-19 2018-07-19 클라우드 플랫폼에서 어플리케이션 컨테이너의 볼륨(스토리지) 프로비저닝 방법
KR10-2018-0084022 2018-07-19
PCT/KR2019/008700 WO2020017846A1 (ko) 2018-07-19 2019-07-15 클라우드 플랫폼에서 어플리케이션 컨테이너의 볼륨(스토리지) 프로비저닝 방법

Publications (1)

Publication Number Publication Date
JP2021530803A true JP2021530803A (ja) 2021-11-11

Family

ID=66846907

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2021502760A Pending JP2021530803A (ja) 2018-07-19 2019-07-15 クラウドプラットフォームでアプリケーションコンテナのボリューム（ストレージ）プロビゾニング方法

Country Status (6)

Country Link
US (1) US11467875B2 (ja)
JP (1) JP2021530803A (ja)
KR (1) KR101987668B1 (ja)
CN (1) CN112424752A (ja)
SG (1) SG11202100293YA (ja)
WO (1) WO2020017846A1 (ja)

Families Citing this family (10)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101987668B1 (ko) 2018-07-19 2019-06-11 나무기술 주식회사 클라우드 플랫폼에서 어플리케이션 컨테이너의 볼륨(스토리지) 프로비저닝 방법
WO2021067091A1 (en) * 2019-10-04 2021-04-08 Zettaset, Inc. Dedicated encrypted container storage
US11340797B2 (en) 2019-10-04 2022-05-24 Zettaset, Inc. Dedicated encrypted container storage
US11079944B2 (en) 2019-10-04 2021-08-03 Zettaset, Inc. Dynamic provisioning of container storage
CN111381833B (zh) * 2020-03-05 2023-05-12 山东汇贸电子口岸有限公司 一种容器化的openstack数据初始化方法
US11172024B2 (en) 2020-03-23 2021-11-09 International Business Machines Corporation Co-location of storage buckets with containerized applications
US11474851B2 (en) * 2020-04-08 2022-10-18 Open Text Holdings, Inc. Systems and methods for efficient scalability and high availability of applications in container orchestration cloud environment
CN111753326B (zh) * 2020-05-22 2024-02-13 湖南麒麟信安科技股份有限公司 一种容器云平台云存储资源加密方法、系统及介质
US11561790B2 (en) * 2021-06-21 2023-01-24 Ciena Corporation Orchestrating multi-level tools for the deployment of a network product
US12014162B2 (en) * 2021-08-31 2024-06-18 Salesforce, Inc. Controlled updates of containers in a distributed application deployment environment

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016157274A1 (ja) * 2015-03-27 2016-10-06 株式会社日立製作所 ストレージ管理計算機

Family Cites Families (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070106714A1 (en) * 2002-10-10 2007-05-10 Rothbarth James N Method and system using an external hard drive to implement back-up files
US8892827B2 (en) * 2011-01-07 2014-11-18 Apple Inc. Cooperative memory management
JP5632082B2 (ja) * 2011-02-02 2014-11-26 株式会社日立製作所 ストレージ装置及びデータ管理方法
US8775774B2 (en) * 2011-08-26 2014-07-08 Vmware, Inc. Management system and methods for object storage system
US8904143B2 (en) * 2011-09-30 2014-12-02 International Business Machines Corporation Obtaining additional data storage from another data storage system
KR20150142871A (ko) 2014-06-12 2015-12-23 주홍찬 인터렉티브 푸쉬 클라우드 시스템 장치 및 방법
US10489177B2 (en) * 2015-02-23 2019-11-26 Red Hat Israel, Ltd. Resource reconciliation in a virtualized computer system
US9479547B1 (en) * 2015-04-13 2016-10-25 RINGR, Inc. Systems and methods for multi-party media management
US10114551B2 (en) * 2016-01-18 2018-10-30 International Business Machines Corporation Space reclamation in asynchronously mirrored space-efficient secondary volumes
US10530703B2 (en) * 2016-08-15 2020-01-07 At&T Intellectual Property I, L.P. Dynamic provisioning of storage in the cloud
KR102212108B1 (ko) * 2016-09-28 2021-02-04 한국전자기술연구원 스토리지 오케스트레이션의 학습형 최적화 대상 볼륨 선정 방법
US10552221B2 (en) * 2016-12-16 2020-02-04 Turbonomic, Inc. Systems, apparatus and methods for managing resources in computer systems
KR101807806B1 (ko) * 2017-05-02 2017-12-11 나무기술 주식회사 클라우드 플랫폼에서 어플리케이션을 컨테이너화하는 방법
KR101987668B1 (ko) * 2018-07-19 2019-06-11 나무기술 주식회사 클라우드 플랫폼에서 어플리케이션 컨테이너의 볼륨(스토리지) 프로비저닝 방법

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016157274A1 (ja) * 2015-03-27 2016-10-06 株式会社日立製作所 ストレージ管理計算機

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
前佛 雅人: "なぜプログラマの役に立つのか いまはじめるＤｏｃｋｅｒ 〜コンテナ技術を身につける〜", ＳＯＦＴＷＡＲＥＤＥＳＩＧＮ, vol. 第316号, JPN6021052776, 18 February 2017 (2017-02-18), JP, pages 38 - 46, ISSN: 0005007094 *

Also Published As

Publication number Publication date
KR101987668B1 (ko) 2019-06-11
WO2020017846A1 (ko) 2020-01-23
CN112424752A (zh) 2021-02-26
SG11202100293YA (en) 2021-02-25
US11467875B2 (en) 2022-10-11
US20210182107A1 (en) 2021-06-17

Similar Documents

Publication Publication Date Title
JP7011127B2 (ja) クラウドプラットフォームでアプリケーションをコンテナ化する方法
JP2021530802A (ja) クラウドプラットフォームで複数のクラスター及びアプリケーションをモニタリングする方法
JP2021530801A (ja) クラウドプラットフォームでのクラスターリソース割り当て及び管理方法
JP2021530804A (ja) クラウドプラットフォームでのマルチクラスタープロビゾニング及び管理方法
JP7029714B2 (ja) クラウドプラットフォームシステム
JP2021530803A (ja) クラウドプラットフォームでアプリケーションコンテナのボリューム（ストレージ）プロビゾニング方法
US10635496B2 (en) Thread pool management
CN112099938A (zh) 使用多维元数据标签集确定分布式计算环境中的资源分配
Moreno-Vozmediano et al. Orchestrating the deployment of high availability services on multi-zone and multi-cloud scenarios
Perri et al. Implementing a scalable and elastic computing environment based on cloud containers
Yoshida et al. Service oriented platform
US20240118800A1 (en) Graphical user interface for workload migration
US20230337062A1 (en) Cellular system observability centralized for all domains and vendors
Sahu et al. A survey on Kubernetes architec-ture and its significance
Pandey et al. Using Platform-as-a-Service (PaaS) for better resource utilization and better quality applications
Trivedi et al. Proposed Framework of Private Cloud Setup in Lab for Teaching and Research
Dinh et al. Dynamic equilibrium capacity across multiple regions in NFV environment
Takano et al. A distributed application execution system for an infrastructure with dynamically configured networks

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20210118

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20220111

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20220404

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20220816

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20230307