JP2021530801A - クラウドプラットフォームでのクラスターリソース割り当て及び管理方法 - Google Patents

クラウドプラットフォームでのクラスターリソース割り当て及び管理方法 Download PDF

Info

Publication number
JP2021530801A
JP2021530801A JP2021502745A JP2021502745A JP2021530801A JP 2021530801 A JP2021530801 A JP 2021530801A JP 2021502745 A JP2021502745 A JP 2021502745A JP 2021502745 A JP2021502745 A JP 2021502745A JP 2021530801 A JP2021530801 A JP 2021530801A
Authority
JP
Japan
Prior art keywords
cluster
resource
stage
cloud
cloud platform
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
JP2021502745A
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 JP2021530801A publication Critical patent/JP2021530801A/ja
Pending legal-status Critical Current

Links

Images

Classifications

    • 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/5083—Techniques for rebalancing the load in a distributed system
    • 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/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5044—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering hardware capabilities
    • 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
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/503—Resource availability

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Mathematical Physics (AREA)
  • Stored Programmes (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (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))を提供する。
図１４乃至図１６は、本発明の一実施例によるクラウドプラットフォームシステムのマルチクラスタープロビゾニング及び管理機能を説明するための図面である。
本発明によるクラウドプラットフォームシステムであるカクテルクラウドはBare metal、cloud platform、public cloudなど多様なインフラにコンテナ基盤アプリケーションが動作することができるクラスター環境を自動生成するマルチクラスタープロビゾニング及び管理機能が提供される。この機能はマルチクラウド環境で複数個のクラスターを中央(カクテルクラウド)で遠隔同時プロビゾニングしてコンテナアプリケーション運営環境を生成することであり、遠隔でクラスターのバージョンアップグレードを管理して運営効率性を向上させる(図１４参照)。
図１５を参照すれば、クラスターのバージョンアップグレードの時Orchestration engine、add-onの最新機能が反映され、ＣＬＩ道具を利用して簡便にクラスターノードを追加して障害ノードを入れ替ることができる。そして、クラスターノードバックアップも可能であり、クラスター自動スケーリングも可能である。
図１６は、クラスターが構成されたパブリッククラウドの計定情報を登録して遠隔でクラスターを制御してアプリケーションの配布、運営管理及びクラスターモニタリング機能を遂行することができる例示画面である。
図１７は、本発明の一実施例によるクラウドプラットフォームシステムのマルチクラスタープロビゾニング及び管理方法を示した流れ図である。
マルチクラスタープロビゾニング及び管理のために使用者が入力することができるプロビゾニング及び管理ツール(tool)が提供される。
プロビゾニング及び管理ツールによって使用者のクラスタープロビゾニングが要請されれば(Ｓ４００)、クラウドプラットフォームシステムは、クラスタータイプ情報(例えば、Bare-metal、public cloud、cloud platformなど)を入力するようにする(Ｓ４１０)。使用者によってクラスタータイプ情報が入力されれば、クラスター構成情報が生成される(Ｓ４２０)。具体的に、クラスター構成情報はインスタンス個数、インスタンス遠慮(ＧＰＵ、メモリータイプ)、ネットワーク構成情報、ストレージ構成情報のうちで少なくとも一つを含む。
次に、パブリッククラウドまたはシステム接続情報(接続計定情報、認証情報)が登録されれば(Ｓ４３０)、クラウドプラットフォームシステムはクラスターを生成することか、または変更することかを確認する(Ｓ４４０、S４９０)。
クラスターを生成することなら、クラウドプラットフォームシステムはインスタンス、ネットワーク、ストレージ生成を要請して構成する(Ｓ４５０)。以後、コンテナランタイムソフトウェアが設置される(Ｓ４６０)。そして、クラスター構成情報がセッティングされる(Ｓ４７０)。それではクラスタープロビゾニングが完了される(Ｓ４８０)。
クラスターを変更することなら、クラウドプラットフォームシステムはクラスター構成ヒストリー情報を確認してクラスター構成をアップデートさせる(Ｓ５００、S５１０)。それではクラスター変更が完了される(Ｓ５２０)。
一方、本発明の一実施例によるクラウドプラットフォームシステムは、管理者によってサービスまたは組織別に開発・テスト・運営され、クラスター別資源可用量によってクラスターインフラを割り当てるクラスターリソース割り当て管理機能を提供する。
図１８は、本発明の一実施例によるクラウドプラットフォームシステムのクラスターリソース割り当て管理機能を説明するための図面である。
図１８に示されたように、本クラウドプラットフォームシステムは、サービス/組織使用グループが登録され、サービス/組織所属使用者が割り当てされれば、割り当てされた使用者にクラスターを割り当てる。この時、クラウドプラットフォームシステムは使用可能なクラスター資源を問い合わせして割り当て、サービス/組織クラスター資源量が制限管理される。
図１９は、本発明の一実施例によるクラウドプラットフォームシステムのクラスターリソース割り当て方法を示した流れ図である。
図１９に示されたように、クラスターリソース割り当て要請が入力されれば(Ｓ４００)、サービスグループ情報が生成される(Ｓ４１０)。サービスグループの使用者は追加/削除されることができる(Ｓ４２０)。
次のサービスグループに割り当てるクラスターが選択されて割り当て情報(例えば、ＣＰＵ、メモリー資源割り当て)が入力される(Ｓ４３０)。
それではクラウドプラットフォームシステムがクラスター資源可用量を問い合わせする(Ｓ４４０)。
資源が使用可能ならば、クラウドプラットフォームシステムがサービスグループに資源割り当て情報を登録して資源を割り当てる(Ｓ４５０、S４６０)。ここにクラスターリソース割り当てが完了される(Ｓ４７０)。
資源が不足ならば、クラウドプラットフォームシステムがクラスター資源が加えられるかを確認する(Ｓ４８０)。クラスター資源が追加できれば、クラウドプラットフォームシステムがクラスター資源を追加登録する(Ｓ４９０)。その後、クラウドプラットフォームシステムがサービスグループに資源割り当て情報を登録して資源を割り当ててクラスターリソース割り当てを完了する(Ｓ４５０、S４６０、S４７０)。
仮に、クラスター資源が追加できなければ、可用クラスターを再選択するためにＳ４３０段階に復帰する。
図２０は、本発明の一実施例によるクラウドプラットフォームシステムのクラスターリソース使用方法を示した流れ図である。
先ず、クラスターリソース使用のためにアプリケーション資源使用量が登録される(Ｓ５００、S５１０)。
クラウドプラットフォームシステムはクラスター資源可用量を問い合わせする(Ｓ５２０)。
資源使用ができればアプリケーション資源を割り当てて機動する(Ｓ５３０)。この時、アプリケーション資源使用状態モニタリング及び制御がなされる。
そして、残余リソース割り当て情報がアップデートされる(Ｓ５４０)。それではクラスターリソース使用が完了される(Ｓ５５０)。
図２１は、本発明の一実施例によるクラウドプラットフォームシステムのクラスターリソース返納方法を示した流れ図である。
クラスターリソース返納のためにアプリケーションが終わる(Ｓ５６０、S５７０)。
クラウスプラットフォームシステムは、割り当てリソースを回収して(Ｓ５８０)、クラスター可用リソース情報をアップデートする(Ｓ５９０)。それではクラスターリソース返納が完了される(Ｓ６００)。
一方、上述した本発明の実施例らはコンピューターで実行されることができるプログラムで作成可能であり、コンピューターで読める記録媒体を利用して前記プログラムを動作させる汎用デジタルコンピューターで具現されることができる。前記コンピューターで読める記録媒体は、マグネチック保存媒体(例えば、ロム・フロッピー・ハードディスクなど)、光学的判読媒体(例えば、CD-ROM・DVDなど)及びキャリアウエーブ(例えば、インターネットを通じた伝送)のような保存媒体を含む。
このように本発明によるクラウドプラットフォームでアプリケーションをコンテナ化する方法によれば、隔離されたアプリケーション実行環境を提供し、独立的な資源割り当てが可能であり、同一ホスト上多重アプリケーション運営が可能なだけでなく、ＯＳ水準の仮想化で早い操作が可能であり、少ない大きさのコンテナイメージで配布及びアップデートが効率的であり、どこでも移動が可能である。
また、本発明によるクラウドプラットフォームでのマルチクラスタープロビゾニング及び管理方法によれば、多様なインフラにコンテナ基盤アプリケーションが動作することができるマルチクラスター環境を自動生成することができるし、遠隔でクラスターのバージョンアップグレードを管理して運営効率性を向上させることができる。
今まで本発明に対してその望ましい実施例らを中心によく見た。本発明が属する技術分野で通常の知識を有した者は、本発明が本発明の本質的な特性から脱しない範囲で変形された形態で具現されることができることを理解することができる。それで、開示された実施例らは限定的な観点ではなく、説明的な観点で考慮されなければならない。本発明の範囲は前述した説明ではなく、特許請求範囲に現われているし、それと同等な範囲内にあるすべての差異は本発明に含まれる。
本発明によるクラウドプラットフォームでのクラスターリソース割り当て及び管理方法は、クラスターリソースを効率的に割り当てて管理することができる効果を有する。

Claims (3)

  1. クラスターリソース割り当て要請が入力されれば、クラウドプラットフォームシステムがサービスグループ情報を生成する段階と、前記クラウドプラットフォームシステムが前記サービスグループの使用者を追加/削除する段階と、前記サービスグループの使用者に割り当てるクラスターが選択されて割り当て情報が入力される段階と、前記クラウドプラットフォームシステムがクラスター資源可用量を問い合わせする段階と、前記資源可用量問い合わせ結果資源が使用可能ならば、前記クラウドプラットフォームシステムが前記サービスグループに資源割り当て情報を登録して資源を割り当ててクラスターリソース割り当てを完了する段階と、前記資源可用量問い合わせ結果資源が不足ならば、前記クラウドプラットフォームシステムがクラスター資源が加えられるかを確認する段階と、前記クラスター資源が追加できれば、前記クラウドプラットフォームシステムが前記クラスター資源を追加登録する段階と、前記クラウドプラットフォームシステムが前記サービスグループに資源割り当て情報を登録して資源を割り当ててクラスターリソース割り当てを完了する段階と、及び前記クラスター資源が追加できなければ、可用クラスターを再選択する段階と、を含む
    ことを特徴とするクラウドプラットフォームでのクラスターリソース割り当て及び管理方法。
  2. 前記クラスターリソース使用のためにアプリケーション資源使用量が登録される段階と、前記クラウドプラットフォームシステムがクラスター資源可用量を問い合わせする段階と、資源使用ができれば前記クラウドプラットフォームシステムがアプリケーション資源を割り当てて機動する段階と、前記クラウドプラットフォームシステムが残余リソース割り当て情報をアップデートする段階と、及び前記クラスターリソース使用が完了される段階と、をさらに含む
    請求項１に記載のクラウドプラットフォームでのクラスターリソース割り当て及び管理方法。
  3. 前記クラスターリソース返納のためにアプリケーションが終わる段階と、前記クラウドプラットフォームシステムが割り当てリソースを回収する段階と、前記クラウドプラットフォームシステムがクラスター可用リソース情報をアップデートする段階と、及び前記クラスターリソース返納が完了される段階と、をさらに含む
    請求項１に記載のクラウドプラットフォームでのクラスターリソース割り当て及び管理方法。

JP2021502745A 2018-07-19 2019-07-15 クラウドプラットフォームでのクラスターリソース割り当て及び管理方法 Pending JP2021530801A (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
KR10-2018-0084013 2018-07-19
KR1020180084013A KR101987661B1 (ko) 2018-07-19 2018-07-19 클라우드 플랫폼에서의 클러스터 리소스 할당 및 관리 방법
PCT/KR2019/008697 WO2020017843A1 (ko) 2018-07-19 2019-07-15 클라우드 플랫폼에서의 클러스터 리소스 할당 및 관리 방법

Publications (1)

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

Family

ID=66847128

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2021502745A Pending JP2021530801A (ja) 2018-07-19 2019-07-15 クラウドプラットフォームでのクラスターリソース割り当て及び管理方法

Country Status (6)

Country Link
US (1) US11520639B2 (ja)
JP (1) JP2021530801A (ja)
KR (1) KR101987661B1 (ja)
CN (1) CN112424751A (ja)
SG (1) SG11202100287SA (ja)
WO (1) WO2020017843A1 (ja)

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101987661B1 (ko) 2018-07-19 2019-06-11 나무기술 주식회사 클라우드 플랫폼에서의 클러스터 리소스 할당 및 관리 방법
US10893097B1 (en) * 2019-07-31 2021-01-12 Verizon Patent And Licensing Inc. Methods and devices for discovering and employing distributed computing resources to balance performance priorities
KR102154446B1 (ko) 2019-11-14 2020-09-09 한국전자기술연구원 분산·협업형 컨테이너 플랫폼 환경에서의 자원 균등 배분을 위한 고속 스케줄링 방법
KR102284264B1 (ko) * 2019-11-14 2021-08-02 에스피테크놀러지 주식회사 클라우드 시스템 및 그 제어방법
KR102172607B1 (ko) * 2019-11-15 2020-11-02 한국전자기술연구원 분산·협업형 컨테이너 플랫폼 환경에서의 자원간 균형적 스케일아웃 방법
US11991041B2 (en) * 2019-12-30 2024-05-21 Oracle International Corporation Autonomous terraforming on cloud infrastructures
CN111209118A (zh) * 2020-01-14 2020-05-29 北京三快在线科技有限公司 确定资源余量的方法、装置、存储介质和电子设备
KR102289100B1 (ko) * 2020-05-07 2021-08-11 한전케이디엔주식회사 빅데이터 분석을 위한 컨테이너 기반의 클러스터 구축 방법 및 클러스터 장치
US11550633B2 (en) 2020-10-31 2023-01-10 Nutanix, Inc. Intra-footprint computing cluster bring-up
CN113485788B (zh) * 2021-06-30 2023-08-29 中国民航信息网络股份有限公司 容器资源的分配方法、装置、服务器及计算机存储介质
US11900172B2 (en) 2021-07-30 2024-02-13 Nutanix, Inc. Computing cluster bring-up on public cloud infrastructure using expressed intents
KR102338422B1 (ko) * 2021-07-30 2021-12-10 클로우플레이크(주) Did 기반 클라우드 환경의 협업툴 서비스 제공 방법, 장치 및 시스템
CN113641503B (zh) * 2021-09-01 2024-05-14 上海联蔚盘云科技有限公司 多云多集群的Kubernetes管理系统及方法与设备
US11829780B2 (en) * 2021-09-22 2023-11-28 International Business Machines Corporation Open-source container cluster hot plug adapter
CN113824790B (zh) * 2021-09-23 2024-04-26 信华信技术股份有限公司 一种支持企业级应用的云原生PaaS管理平台
CN114285850A (zh) * 2021-12-27 2022-04-05 北银金融科技有限责任公司 一种基于容器平台的跨集群多租户资源管理系统
CN114090268B (zh) * 2022-01-11 2022-04-15 北京九章云极科技有限公司 容器管理方法及容器管理系统
CN114915460B (zh) * 2022-04-28 2023-05-05 中国人民解放军战略支援部队信息工程大学 一种面向容器云的异构动态扩缩容装置及方法
KR20240003537A (ko) * 2022-07-01 2024-01-09 몬드리안에이아이 주식회사 공유자원 기반 원격 분산 학습 시스템
CN115086335A (zh) * 2022-07-27 2022-09-20 北京思和科创软件有限公司 容器云的节点动态添加方法、装置、电子设备及存储介质
CN115834600B (zh) * 2022-11-03 2023-07-07 中国烟草总公司贵州省公司 一种多云纳管数据同步方法、装置、电子设备和存储介质
CN117278635B (zh) * 2023-11-03 2024-03-19 烽台科技（北京）有限公司 工业靶场的调度方法和工业靶场系统

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016146078A (ja) * 2015-02-09 2016-08-12 日本電信電話株式会社 リソース融通システム及び方法
JP2016189145A (ja) * 2015-03-30 2016-11-04 株式会社ミロク情報サービス 管理装置及び管理方法

Family Cites Families (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7900206B1 (en) * 2004-03-31 2011-03-01 Symantec Operating Corporation Information technology process workflow for data centers
KR101540631B1 (ko) * 2012-12-28 2015-07-30 삼성에스디에스 주식회사 가상 클러스터의 동적 확장 시스템, 방법 및 그 프로그램이 저장된 기록매체
KR101508273B1 (ko) * 2013-03-27 2015-04-07 주식회사 케이티 클라우드 ａｐｉ 키를 이용한 자원 할당 방법 및 이를 위한 장치
KR20150142871A (ko) 2014-06-12 2015-12-23 주홍찬 인터렉티브 푸쉬 클라우드 시스템 장치 및 방법
KR101582751B1 (ko) * 2014-07-01 2016-01-06 울산대학교 산학협력단 협업 작업공간 제공 방법 및 시스템
US10341128B2 (en) * 2016-03-12 2019-07-02 Wipro Limited Method and system for optimizing usage of network resources in a communication network
US10805414B2 (en) * 2016-07-15 2020-10-13 International Business Machines Corporation Dynamic resource broker services
KR101807806B1 (ko) * 2017-05-02 2017-12-11 나무기술 주식회사 클라우드 플랫폼에서 어플리케이션을 컨테이너화하는 방법
KR101826498B1 (ko) * 2017-05-02 2018-02-07 나무기술 주식회사 클라우드 플랫폼 시스템
KR101858715B1 (ko) * 2017-11-10 2018-05-16 베스핀글로벌 주식회사 서비스자원 관리시스템 및 그 방법
KR101987661B1 (ko) * 2018-07-19 2019-06-11 나무기술 주식회사 클라우드 플랫폼에서의 클러스터 리소스 할당 및 관리 방법

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2016146078A (ja) * 2015-02-09 2016-08-12 日本電信電話株式会社 リソース融通システム及び方法
JP2016189145A (ja) * 2015-03-30 2016-11-04 株式会社ミロク情報サービス 管理装置及び管理方法

Also Published As

Publication number Publication date
SG11202100287SA (en) 2021-02-25
US11520639B2 (en) 2022-12-06
KR101987661B1 (ko) 2019-06-11
WO2020017843A1 (ko) 2020-01-23
US20210124624A1 (en) 2021-04-29
CN112424751A (zh) 2021-02-26

Similar Documents

Publication Publication Date Title
JP7011127B2 (ja) クラウドプラットフォームでアプリケーションをコンテナ化する方法
JP2021530801A (ja) クラウドプラットフォームでのクラスターリソース割り当て及び管理方法
JP2021530804A (ja) クラウドプラットフォームでのマルチクラスタープロビゾニング及び管理方法
JP2021530802A (ja) クラウドプラットフォームで複数のクラスター及びアプリケーションをモニタリングする方法
JP7029714B2 (ja) クラウドプラットフォームシステム
JP2021530803A (ja) クラウドプラットフォームでアプリケーションコンテナのボリューム（ストレージ）プロビゾニング方法
US9338067B2 (en) Network resource deployment for cloud-based services
CN104967664A (zh) 云的自动化部署系统和方法
US20130297795A1 (en) Owner command execution in a multi-tenant cloud hosting environment
US10862887B2 (en) Multiple domain authentication using data management and storage node
Cotarelo et al. Running Oracle WebLogic on containers
Trivedi et al. Proposed Framework of Private Cloud Setup in Lab for Teaching and Research
Kaufman et al. Implementing High Availability
Interface Open Cloud Computing Interface-Use cases and requirements for a Cloud API

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: 20220104

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20220401

A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20220816