本文へスキップ
メニュー

Zenix

1つの申請で、ワークスペース全体を。

ID、アクセスポリシー、コンピュートを連携します。承認済みプロファイルに基づくワークスペースを、一人ひとりに提供します。

ワークスペースの申請から始めます。

利用者が業務環境を申請します。その申請は、ID、ネットワーク、リソースと同じオーケストレーションプロセスに入ります。

申請、ID、ネットワーク、コンピュート、アクセス、インサイトが、Zenixコアと相互につながります。
  • 作業の種類ごとの承認済みプロファイル
  • ID、ネットワーク、コンピュートを1つのフローに
  • 利用者体験と共に捉えるリソース使用率

業務のために。
進め方を変える。

Zenixが複雑さを明確な次の一歩に変える3つの場面。

目的を絞ったシステム。
より大きな全体像の一部。

Zenixは、利用者の申請をID、ネットワーク、マシン、アクセスにつなぎます。ITがプロファイルとポリシーを定義し、利用者には役割に合うワークスペースを提供します。GPU管理は、インフラの準備と利用という広いプロセスの中に位置付けられます。

ワークスペースのレイヤー。

Zenixは、組織のインフラを人が実際に使えるワークスペースに変えます。TitansチームがITと役割、リソースプロファイル、アクセスポリシーを定め、再利用できるサービスにつなぎます。研究、エンジニアリング、日常運用に、申請からサポートまで共通の経路を提供します。

01

業務フローの全体像

例:GPU環境を必要とするチームに研究者が参加します。既存のITプロファイルに沿って、準備、アクセス、サポート、使用状況のレビューを進めます。特定の顧客、ハードウェア仕様、完了時間を示すものではありません。

  1. ワークスペースのプロファイルを準備

    管理者が管理済みイメージを選び、対象の役割とグループに合わせてCPU、メモリ、GPU、ストレージの要件を定義します。サービス責任者が利用資格とリソース上限を合意します。

    再利用できるワークスペース定義を整え、利用資格、上限、必要な承認をプロジェクトで定めます。

  2. IDとネットワークアクセスを連携

    研究者が申請すると、合意した環境に必要なID、グループ所属、役割別ネットワークルールを作成または接続します。

    IDとアクセスをワークスペースに関連付けます。プロバイダーとの接続と既存アカウントの取り扱いを、実装時に検証します。

  3. 作業環境を割り当て

    プロファイルが仮想マシンとGPU割り当ての要件を示します。インフラ責任者が、機器、仮想化、ストレージで環境を提供できるか確認します。

    環境は利用者に関連付けます。リソース不足やプロビジョニング段階の失敗に対する対応を、プロジェクトで定義します。

  4. ワークスペースに入り、利用

    専用クライアントなしでブラウザーから利用します。運用側が活動と使用率を確認し、問題はチケットや社内チャットで報告できます。

    ワークスペースにアクセスとサポートの経路を用意します。反復作業では、依頼種別ごとに合意した境界内でITエージェントを利用できます。

  5. リソースの継続利用を確認

    運用担当者が、利用の少ないリソースをワークロード責任者と確認します。推奨や自動回収を適用する前に、長時間の計算処理、データ保全、解放ポリシーを考慮します。

    容量の判断は、利用状況と所有者に結び付けて行います。アイドルの信号は評価が必要な材料であり、作業完了を証明するものではありません。

申請が、ID、リソース、アクセス、サポートを定義済みのワークスペースプロセスにつなぎます。完了、障害対応、回収ルールを選んだ環境で検証します。

02

内側にある機能

利用開始手続きとID

アカウント作成、グループへの所属、役割に基づく権限を、プロビジョニング申請と連携します。IT部門が一度定義したルールを、以後の申請にも再利用します。

入力
利用者の申請、選択したプロファイル、関連する役割またはグループ。
出力
アカウントをワークスペースと別管理するのではなく、IDと権限の情報をプロビジョニングに関連付けます。

プロファイル別のネットワークアクセス

ネットワーク構成とアクセスルールを利用環境の一部として設定します。ポリシーでIDと許可されたリソースをつなぎ、マシンの作成を超えたプロビジョニングを行います。

入力
利用者の役割、許可されたリソース、プロファイルのネットワーク要件。
出力
利用者の環境に関連付けた、ワークスペースのアクセスルールとネットワーク構成。

コンピュートプロファイル

CPU、メモリ、GPU、ストレージのテンプレートで、チーム、講座、役割に提供する環境を定義します。クォータとグループ割り当てにより、ニーズと責任者に応じた配分を支えます。

入力
選択した業務の種類に応じて事前に定義した、CPU、メモリ、GPU、ストレージの要件。
出力
プロファイルに基づく仮想マシンの割り当て。実際のインフラで利用できるかを確認します。

共有GPU管理

割り当て、使用率、負荷の画面が、ハードウェアと利用者を結びます。インフラチームは、空き容量、ワークロード、拡張申請を文脈と共に確認できます。

入力
利用者とワークロードに関連付けられたGPU割り当てと使用状況の信号。
出力
共有、使用率、負荷を可視化し、容量判断とリソース逼迫の調査を支援します。

システムイメージとバージョン

Gold Imagesは、繰り返し使うワークスペースの管理された出発点です。プロファイルごとにイメージのバージョンを設定し、拡張前に代表的なグループで更新を評価します。

入力
管理されたGold Imageと、ワークスペース用に選択されたバージョン。
出力
再利用できる標準システム構成。更新の確認方法と既存環境への導入方法をチームが定義します。

ブラウザー上のワークスペース

専用クライアントなしで、ブラウザーからワークスペースに入れます。IDと権限が、デスクトップや研究環境へのアクセスを引き続き管理します。

入力
利用者のID、アクセス権限、準備済みマシン。
出力
ブラウザーから作業環境へ入る経路。組織のブラウザーとネットワーク要件を確認します。

サポートとITエージェント

チケットとチャットで利用者を運用担当者につなぎます。ITエージェントは、依頼種別ごとの操作範囲内で、トークン更新やセッションリセットなどの反復作業を支援します。

入力
報告された問題と、その対応に必要なアカウントまたはワークスペースの情報。
出力
運用責任を明確にした、サポート案件または許可済みのエージェント操作。例としてトークン更新やセッションリセットがあります。

監視と容量回収

ダッシュボードが使用状況と傾向を示し、利用の少ないマシンやGPUを特定します。ワークロードのポリシーに応じて、自動または承認の推奨を経て容量をプールに戻します。

入力
活動状況、リソース使用率、未使用容量を特定する合意済みのルール。
出力
利用状況の表示と回収推奨・設定済み操作。ワークロードの保護とデータ保全の判断に従います。
03

つながり続ける情報

これらの情報オブジェクトがワークスペースのプロセスをつなぎます。正確な項目、保存期間、連携形式はプロジェクトで定めます。API仕様ではありません。

利用者、グループ、権限

利用者のID、役割、グループ所属がアクセス権を環境につなぎます。Zenixは、ID、ネットワーク、リソース横断のポリシー変更を説明しています。

ワークスペースの申請、入室、管理ができる人を定め、その権限の変更を確認します。

プロファイルとシステムイメージ

リソースプロファイルが、予定するコンピュート割り当てを定義します。管理されたイメージとそのバージョンにより、繰り返されるワークスペース申請に共通のシステム構成を提供します。

統一された環境を準備し、プロファイルやイメージの更新の影響を確認します。

割り当て済みの環境とリソース

マシン、GPU割り当て、ストレージ、アクセスは、利用者に関連付けた環境に属します。公開プライバシー情報には、割り当てと構成の記録も示されています。

インフラの利用と責任者を結び、容量の割り当てを維持すべきか判断します。

利用、サポート、監査

活動状況、使用率、運用ログ、利用者のメッセージが、ダッシュボードとサポートの情報源になります。エージェントは、自らの操作の説明と監査記録も提供します。

問題を調査し、操作やリソース推奨の根拠を確認します。

04

既存システムとの連携

IDとグループ

既存IDをグループ、役割、権限責任者に対応付けます。セルフサービスを有効にする前に、IDプロバイダー連携と退職時の対応を確認します。

コンピュート、GPU、ストレージ

機器、仮想化、ドライバー、ストレージを必要なプロファイルと照合します。展開の前に明確な互換性一覧を作成します。すべての構成への対応を前提とはしません。

監視システム

使用データをGrafana、Prometheus、OpenTelemetryなどの監視ツールへ連携できます。出力する指標とイベント、送信先、アラート責任者を定義します。

ネットワークとブラウザーアクセス

グループ分離、アクセス経路、ワークスペースの利用条件を整理します。隔離環境では、外部接続に依存するコンポーネントとサービスも評価します。

05

権限、管理、例外

セルフサービスの前にポリシーを

各プロファイルには責任者、対象利用者、リソースのクォータがあります。利用者の申請が権限や容量の制約を回避することはありません。

ITエージェントの操作範囲

許可する操作、承認要件、人へのエスカレーションを定義します。権限変更とリソース回収には、明確なポリシーが必要です。

分離と運用の可視化

ID、分離、クォータで利用者とリソースを結びます。活動ログとテレメトリーにより、アクセス付与と運用を確認できます。

責任あるリソース回収

環境をアイドルと見なす条件、保護するジョブ、回収前のデータ保全を定義します。ワークロード責任者とルールを検証します。

計画どおりに進まないとき

運用担当者はプロファイルとイメージを保守し、アクセスと使用率を確認してサポートを継続します。エージェントには、パスワードリセット、トークン更新、クォータ拡張、セッションリセットが説明されています。自動化と人へのエスカレーションはプロジェクトで定義します。

プロビジョニングの工程が未完了

アカウントが作成されても、ネットワークとコンピュートの準備完了は保証されません。実際の導入環境で、部分的に完了した申請の表示、安全な再試行、重複防止を検証します。システム横断の補償処理やロールバックは確認すべき要件であり、公開された共通の保証ではありません。

必要な容量を確保できない

申請されたプロファイルを割り当てられない場合、インフラ責任者には明確な対応が必要です。利用者が待つか、申請を変更するか、人の支援を受けるか、その判断者も合意します。使用率の表示は、公開されたスケジューリングや待ち行列の仕組みを意味しません。

処理中でもリソースが未使用に見える

ブラウザー操作や瞬間的な利用が少なくても、長時間ジョブが実行されている場合があります。ワークロードの責任者が、データ保全を含め、回収前に使う判断材料と例外を定義します。製品は自動解放や推奨を提供しますが、安全な運用ポリシーはプロジェクトで定めます。

更新やセッションの問題が業務に影響

管理されたイメージのバージョンと、セッションリセット支援が説明されています。代表的な利用者と、更新の影響や停止したセッションへの許可された対応を検証します。すべての更新やエージェント操作が元に戻せると想定せず、操作ごとに復旧とエスカレーションを定義します。

06

実装と組織への適合

  1. 利用者とプロファイルを選ぶ

    サービス責任者とインフラチームが試験グループ、ワークスペース、成功指標を選びます。有効な申請の定義を合意することが成果です。

  2. プロビジョニングの連鎖をつなぐ

    ID、ネットワーク、コンピュート、ストレージを1つのプロファイルにまとめます。代表的な利用者と、クォータ、権限、ブラウザーからの利用を検証します。

  3. 利用と例外を検証

    繰り返し申請、容量不足、権限変更、未使用リソースを検証します。自動実行するものと運用担当者へ渡すものを合意します。

  4. 測定しながら拡張

    利用データに基づいてグループとプロファイルを追加します。イメージ更新、権限レビュー、リソース回収の定期手順を整えます。

導入環境

実行環境
主権的に管理される施設と隔離ネットワークで、機関をまたいで共有リソースを管理。
アクセスの境界
役割別ポリシー、クォータ、テナント間分離で、リソースを権限のある利用者につなぎます。
対話にご用意いただくもの
コンピュートとGPUの台帳、利用者グループ、必要なワークスペース、割り当てポリシー。

必要なワークスペースを定義

特定グループのイメージ、ブラウザー体験、GPU、ドライバー、仮想化、ストレージ、ネットワークを一体として確認します。コンピュート割り当ての一般的な説明は、あらゆるハードウェアとソフトウェアの組み合わせへの対応を意味しません。

プロビジョニングの各接続を確認

公開資料ではGrafana、Prometheus、OpenTelemetryに言及しています。ID、ネットワーク、コンピュートのコネクターは、データの方向と障害時の動作を含む互換性確認が必要です。公開サイトは、プロバイダーやアダプターの完全な対応表を提供していません。

自動化と回収の権限を設定

権限変更、リソース延長、セッションリセット、容量解放を実行できる担当者を合意します。操作ごとに、エージェントの権限、承認箇所、人へのエスカレーションを定義します。ワークロード責任者は、リソースをプールへ返す前に、アイドル判定ルール、保護対象ジョブ、データ保全も定めます。

導入方法とサービス条件を合意

隔離環境はユースケースとして説明されていますが、導入構成とオフラインAIの提供は確認が必要です。データの保存場所、外部依存、バックアップ、アクセス経路を文書化します。含まれる機能とサービスの確約は顧客の構成と契約に従い、ホームページの指標は個別プロジェクトの保証ではありません。

07

適合性に関する質問

ZenixはGPU管理だけのシステムですか?

いいえ。ID、ネットワーク、マシン、アクセス、監視を調整します。GPUは、ワークスペースのプロファイルに含められるリソースの一種です。

利用者は何をインストールしますか?

専用クライアントなしで、ブラウザーからワークスペースにアクセスします。組織のブラウザー、ネットワーク、アクセス要件は事前に確認します。

GPUをプールへ戻す時期は誰が判断しますか?

インフラチームがワークロード責任者とポリシーを定義します。回収には承認の推奨や設定済み自動化を利用できます。未使用リソースと長時間の計算処理を区別する必要があります。

既存インフラでは何を確認する必要がありますか?

必要なワークスペースと共に確認する、GPUの種類、ドライバー、仮想化、ストレージ、ネットワーク。実際の構成と選択したプロファイルに照らして互換性を評価します。

パイロットの成功はどう評価しますか?

ワークスペースの準備時間、申請完了、アクセス品質、使用率を事前に定義します。同じ利用者グループで導入前後を比較し、目標と保証を区別します。

08

ドキュメントと関連資料

お客様の業務へつなぐ。

1つの業務フロー、情報、それを知る人から始めます。実装への道筋を共に定義します。