Flexiant Cloud Orchestrator: 付属品

IaaS（仮想データセンター）サービスを提供するために、 ルソニクス 商用オーケストレーターを使用しています 柔軟なクラウド オーケストレーター (FCO)。 このソリューションはかなりユニークなアーキテクチャを備えており、一般に知られている Openstack や CloudStack とは異なります。

KVM、VmWare、Xen、Virtuozzo6/7、および同じ Virtuozzo のコンテナーが計算ノードのハイパーバイザーとしてサポートされます。 サポートされているストレージ オプションには、ローカル、NFS、Ceph、Virtuozzo ストレージが含まれます。

FCO は、単一のインターフェイスからの複数のクラスターの作成と管理をサポートします。 つまり、マウスのクリックで Virtuozzo クラスターと KVM + Ceph クラスターを切り替えて管理できます。

FCO の核となるのはクラウド プロバイダー向けの包括的なソリューションであり、オーケストレーションに加えて、すべての設定、支払いプラグイン、請求書、通知、再販業者、料金表などの請求も含まれます。 ただし、請求部分ではロシアのニュアンスをすべてカバーできるわけではないため、別のソリューションを選択してその使用を放棄しました。

すべてのクラウド リソース (イメージ、ディスク、製品、サーバー、ファイアウォール) に対する権利を配布する柔軟なシステムに非常に満足しています。これらすべてを「共有」して、ユーザー間、さらには異なるクライアントのユーザー間で権利を付与することができます。 各クライアントはクラウド内に複数の独立したデータセンターを作成し、それらを単一のコントロール パネルから管理できます。

アーキテクチャ的には、FCO はいくつかの部分で構成されており、各部分には独自の独立したコードがあり、一部には独自のデータベースがあります。

スカイライン – 管理者およびユーザーインターフェイス
ジェイド – ビジネスロジック、請求、タスク管理
タイガーリリー – サービス コーディネーター。ビジネス ロジックとクラスター間の情報交換を管理および調整します。
XVPマネージャー – クラスター要素の管理: ノード、ストレージ、ネットワーク、仮想マシン。
XVPAエージェント – XVPManager と対話するためにノードにインストールされるエージェント

もちろん、このトピックに興味があれば、各コンポーネントのアーキテクチャに関する詳細なストーリーを一連の記事に含める予定です。

FCO の主な利点は、その「ボックス化」された性質にあります。 シンプルさとミニマリズムがあなたの役に立ちます。 制御ノードには、Ubuntu 上の XNUMX 台の仮想マシンが割り当てられ、そこに必要なパッケージがすべてインストールされます。 すべての設定は、変数値の形式で構成ファイルに配置されます。

# cat /etc/extility/config/vars
…
export LIMIT_MAX_LIST_ADMIN_DEFAULT="30000"
export LIMIT_MAX_LIST_USER_DEFAULT="200"
export LOGDIR="/var/log/extility"
export LOG_FILE="misc.log"
export LOG_FILE_LOG4JHOSTBILLMODULE="hostbillmodule.log"
export LOG_FILE_LOG4JJADE="jade.log"
export LOG_FILE_LOG4JTL="tigerlily.log"
export LOG_FILE_LOG4JXVP="xvpmanager.log"
export LOG_FILE_VARS="misc.log"
…

最初に設定全体がテンプレートで編集され、その後ジェネレーターが起動されます。
#build-config は、vars ファイルを生成し、サービスに設定を再読み取りするよう命令します。 ユーザーインターフェイスは素晴らしく、簡単にブランド化できます。

ご覧のとおり、インターフェイスはユーザーが制御できるウィジェットで構成されています。 ページにウィジェットを簡単に追加/削除できるため、必要なダッシュボードを作成できます。

FCO はその閉鎖的な性質にもかかわらず、高度にカスタマイズ可能なシステムです。 ワークフローを変更するための膨大な数の設定とエントリ ポイントがあります。

1. カスタム プラグインがサポートされています。たとえば、独自の請求方法や外部リソースを作成して、ユーザーに提供することができます。
2. 特定のイベントのカスタム トリガーがサポートされています。たとえば、最初の仮想マシンの作成時にクライアントに追加します。
3. インターフェイスのカスタム ウィジェットがサポートされています。たとえば、YouTube ビデオをユーザー インターフェイスに直接埋め込むことができます。

すべてのカスタマイズは、Lua に基づいた FDL で記述されます。 Lua を知っていれば、FDL は問題ありません。

ここでは、私たちが使用する最も単純なトリガーの XNUMX つの例を示します。 このトリガーでは、ユーザーが自分のイメージを他のクライアントと共有することはできません。 これは、あるユーザーが他のユーザーのために悪意のあるイメージを作成することを防ぐために行われます。

function register()
    return {"pre_user_api_publish"}
end
   
function pre_user_api_publish(p)  
    if(p==nil) then
        return{
            ref = "cancelPublishImage",
            name = "Cancel publishing",
            description = "Cancel all user’s images publishing",
            triggerType = "PRE_USER_API_CALL",
            triggerOptions = {"publishResource", "publishImage"},
            api = "TRIGGER",
            version = 1,
        }
    end

    -- Turn publishing off
    return {exitState = "CANCEL"}
   
end

register 関数は FCO カーネルによって呼び出されます。 呼び出される関数の名前が返されます。 この関数の「p」パラメータには呼び出しコンテキストが格納され、最初に呼び出されるときは空 (nil) になります。 これにより、トリガーを登録できるようになります。 triggerType では、トリガーが公開操作の前に呼び出され、ユーザーのみに影響を与えることを示します。 もちろん、システム管理者はすべてを公開できます。 triggerOptions では、トリガーが起動される操作の詳細を説明します。

そして重要なのは return {exitState = “CANCEL”} であり、これがトリガーが開発された理由です。 ユーザーがコントロール パネルで画像を共有しようとすると、失敗が返されます。

FCO アーキテクチャでは、あらゆるオブジェクト (ディスク、サーバー、イメージ、ネットワーク、ネットワーク アダプターなど) は、共通のパラメーターを持つリソース エンティティとして表されます。

• リソースUUID
• リソース名
• リソースタイプ
• リソース所有者のUUID
• リソースのステータス (アクティブ、非アクティブ)
• リソースメタデータ
• リソースキー
• リソースを所有する製品の UUID
• リソース VDC

これは、API を使用してすべてのリソースが同じ原則に従って動作する場合に非常に便利です。 製品はプロバイダーによって構成され、クライアントによって注文されます。 請求は当社側で行うため、お客様はパネルから自由に商品を注文することができます。 後ほど請求時に計算されます。 製品は、XNUMX 時間あたりの IP アドレス、XNUMX 時間あたりの追加の GB のディスク、または単なるサーバーにすることができます。

キーを使用して特定のリソースをマークし、そのリソースを操作するロジックを変更できます。 たとえば、XNUMX つの物理ノードを Weight キーでマークし、いくつかのクライアントを同じキーでマークすることで、これらのノードをこれらのクライアントに個別に割り当てることができます。 このメカニズムは、VM の隣にある隣人を好まない VIP クライアントに使用されます。 機能自体はさらに幅広く使用できます。

ライセンス モデルには、物理​​ノードのプロセッサ コアごとに料金が発生します。 コストはクラスターの種類の数にも影響されます。 たとえば、KVM と VMware を併用する場合、ライセンスのコストが増加します。

FCOは本格的な製品であり、その機能は非常に豊富なので、ネットワーク部分の機能について詳しく説明した記事を一度に複数作成する予定です。

このオーケストレーターを数年間使用してきましたが、非常に適していると言えます。 残念ながら、この製品には欠陥がないわけではありません。

• クエリ内のデータ量が増加するとクエリが遅くなり始めたため、データベースを最適化する必要がありました。
• ある事故の後、バグにより復旧メカニズムが機能しなかったため、独自のスクリプト セットを使用して不幸な顧客の車を復旧しなければなりませんでした。
• ノードが利用できないことを検出するメカニズムはコードに組み込まれており、カスタマイズすることはできません。 つまり、ノードが利用できないかどうかを判断するための独自のポリシーを作成することはできません。
• ログは必ずしも詳細に記録されるわけではありません。 特定の問題を理解するために非常に低いレベルまで下げる必要がある場合、一部のコンポーネントにその理由を理解するのに十分なソース コードがない場合があります。

TOTAL： 全体的に商品の印象は良いです。 私たちはオーケストレーター開発者と常に連絡を取り合っています。 彼らは建設的な協力をするつもりです。

FCO はシンプルでありながら幅広い機能を備えています。 今後の記事では、次のトピックについてさらに詳しく掘り下げる予定です。

• FCOでのネットワーキング
• ライブリカバリとFQPプロトコルの提供
• 独自のプラグインとウィジェットを作成する
• ロードバランサーやアクロニスなどの追加サービスの接続
• バックアップ
• ノードの構成と構成のための統合メカニズム
• 仮想マシンのメタデータの処理

ZY 他の側面に興味がある場合は、コメントに書き込んでください。 乞うご期待！

出所： habr.com