Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
本資料はIT運用担当者向けのものです。Linux、kubernetes、docker、クラウドなどの運用知識が必要です。
デプロイメントプロセスを簡素化するための前提条件を以下に示します。
Diamond 環境の Mercury では、デプロイの際にアカウント ubuntu
を使用します。
インストーラパッケージは、シードホストの /data
フォルダに作成します。通常、シードホストは、第 1 の Diamond ホストです。
シードマシン: Diamond インストーラをダウンロードして実行するマシンです。シードマシンにできるのは、Linux システムを搭載し、パスワードなしにすべての Diamond ホストにアクセス可能な任意のマシンです。Diamond ホストをシードマシンとして使用することもできます。
Diamond ホスト: Diamond プラットフォームをインストールする 1 台以上のマシンであり、コンポーネントを稼働します。Ubuntu 18.04 / CentOS 7.4 オペレーティングシステムを搭載しています。
ワーキングマシン: Kubernetes クラスタ、Ceph ストレージ、ビジネスミドルウェア、およびアプリケーションをインストールする 1 台以上のマシンです。
デプロイメントアーキテクチャ:
Diamond プラットフォームは、水平展開と最小展開の 2 種類のデプロイメントアーキテクチャに対応しています。この 2 つのデプロイメントアーキテクチャの主な違いは、Diamond ホストの数です。
水平展開: 3 台の Diamond ホストと 1 台以上のワーキングマシン
最小展開: 1 台の Diamond ホストと 1 台以上のワーキングマシン
Diamond プラットフォームをデプロイする際、1 台の Diamond ホスト + 1 台のワーキングマシン
の環境を 1+1
と呼びます。同様に、3+6
の環境は、3 台の Diamond ホスト + 6 台のワーキングマシン
を指します。クラスタ環境を準備する際、以下の環境情報にご注意ください。
Diamond ホストを稼働するための最小システム要件は、8 コア CPU、16GB メモリ、100GB ハードドライブ、Ubuntu 18.04 / CentOS 7.4
です。
テスト環境では、少なくとも 1 台の Diamond ホストが必要です。 HA をセットアップする場合は、3 台の Diamond ホストが必要です。
Mercury ホストを稼働するための最小システム要件は、8 コア CPU、32GB メモリ、100GB ハードドライブ、Ubuntu 16.04 / CentOS 7.4
です。少なくとも 1 台の Mercury ホストが必要です。また、Mercury ホストの 1 つには、2 基のハードディスクが必要です。1 基は OS ディスク用、もう 1 基は Ceph
ディスク用です。2 基めディスクを備えたホストが 4 台以上あると、Ceph
サービスの HA が実現します。
Mercury コンポーネントは、 Diamond K8s 環境の最上位で稼働します。これらのホストは、Diamond 用語でワークロードホストとも呼ばれます。
デプロイメントや稼働中、Diamnod ホストからワークロードホストに対して ssh の実行が必要になることがよくあります。ホストのすべての IP アドレスを覚えるのに比べ、Diamond ホストの /etc/hosts
ファイルでニックネームを設定すると便利です。以下は、ニックネームの一例です。ニックネームを設定することで、ssh [nickname]
を使用して簡単にワークロードホストに接続できます。
次の手順は、クラスタマシンが上記の要件を満たしていることを前提としています。
ベアメタル
デプロイの場合、Diamond ホストに Ubuntu 18.04 / CentOS 7.4が搭載されており、すべての Workload ホストで IPMI が正しく設定されていること。また、IPMI IP、ユーザ、シークレットキーの情報が用意されていること。
手動
デプロイの場合、Diamond ホストに Ubuntu 18.04 / CentOS 7.4が搭載されており、ワークロードホストには ubuntu 16.04 / CentOS 7.4が搭載されていること。また、IP、MAC、ホスト名の情報が用意されていること。
すべてのホスト (Diamond ホストと Mercury ホスト)で、ルート
アカウントを使用して以下のスクリプトを実行し、パスワードなしに sudo を実行できるユーザとして ubuntu
を作成します。すべてのホストに Diamond インストーラのパブリックキーを設定します。次に、ローカルホストファイルで、ホスト名/IP のマッピングを設定します。
本プロジェクト内のスクリプトを使用して、Diamond 環境に Mercury をデプロイします。プロジェクト要件を満たすためには、自動デプロイ向けの Ansible ツールを使用します。これは、Kubernetes 環境の ミドルウェア 層と エンジン 層を対象にしたサービスのデプロイメントです。
group_vars / all.yml ファイルで設定を変更することで、多様な環境でのデプロイメントに対応します。
インベントリファイルでホストを設定し、クラスタ内のポッドの分散を定義します。
このプロジェクトにより、手動による操作を減らし、デプロイメントの自動化を実現することが期待できます。
デプロイメントの主な手順は以下のとおりです。
マシンの準備
インストーラパッケージの作成
デプロイメント構成の作成
Diamond と Mercury のデプロイ
インストールを開始する前に、Diamond のインストールプロセスを理解しておく必要があります。最新のインストールガイドは、 Diamond プラットフォームのデプロイをご参照ください。
デプロイの際に完全なインストールパッケージを入手しているはずですが、まだ入手していない場合は、付録: インストールパッケージの作成 を参照して、インストールパッケージを作成してください。
インストールパッケージをデプロイメントクラスタのシードマシンにコピーします。通常、シードマシンは、第 1 の Diamond ホストです。以下のコマンドを実行して、インストールディレクトリを準備します。
手動モードで Diamond をインストールする場合、クラスタ全体のホスト情報を確認する必要があります。 /data/diamond/configure/pre_flight.sh
にあるスクリプトを使用してすべての関連情報を収集すると、簡単に確認できます。パラメータとして、マシンの IP アドレスをスペースで区切ってスクリプトで指定すると、マシンに関する情報が収集されます。収集されたクラスタのホスト情報が以下の要件を満たしている必要があります。
実行中のスクリプトが終了すると、cluster-info.log
が生成されます。 cluster-info.log
で収集された情報を精査し、すべての条件がみたされているかを確認します。
シードマシンで /data
ディレクトリにログインした後、以下のコマンドを実行してデプロイメントを開始します。デプロイメントプロセス時のすべての出力およびエラー情報は、setup.log
ファイルに保存されます。このファイルは、エラー発生時のトラブルシューティングに役立ちます。
Mercury インストールファイルパッケージの作成は、デプロイメント前にすべてのファイルを準備するプロセスです。インストールのステップとは切り離されたステップです。テスト環境では、通常インストールパッケージはシードマシンで作成します。その後、インストールパッケージを顧客のサイトに移行して、設定とデプロイメントを行います。
インストールパッケージの作成プロセスは、以下の手順で行います。
Diamond インストールパッケージを diamond
ディレクトリにコピーします。
Mercury 自動デプロイスクリプトを mercuryディレクトリにダウンロードします。
Mercury で使用されるイメージファイルを Diamond インストールパッケージにインジェクトします。
その他の最終工程を行います。
インストールパッケージを作成する際、ubuntu
アカウントを使用して以下のコマンドを実行します。
通常、docker コマンドを実行するユーザは、docker
パーミッショングループに追加する必要があります。設定を有効にするには、コンソールをログアウトして、再度ログインする必要があります。その後に、後続のインストールやデプロイメント手順を続行します。
Diamond プラットフォームのインストールプロセスの所要時間は、マシンや選択したコンポーネントに応じて、一般的に 1.5 時間から 2 時間です。そのため、インストールを開始する際に tmux
や screen
ツールを起動すると、セッションが中断してインストールに影響が及ぶといった問題を解決できます。
シードホストの /data
ディレクトリにログインして以下のコマンドを実行し、Diamond プラットフォームのデプロイを開始します。デプロイプロセス中のすべての出力およびエラー情報は、setup_diamond.log
ファイルに記録されるため、エラー発生時のトラブルシューティングに役立ちます。
インストールプログラムの実行中に詳細なログ情報を参照する必要がある場合は、該当する Diamond ホストにログインして tail -f /tmp/*.log
を実行すると、別の Diamond ホスト上にインストールコンポーネントの詳細ログが表示されます。
Diamond プラットフォームのインストールが完了すると、コンソールに文字パターンが表示されます。コンソールに Server error
と表示される場合は、インストール中にエラーが発生したことを示します。報告されたエラーコンポーネントに従い、該当する Diamond ホストで、コンポーネントの詳細なインストールログをご確認ください。 エラーのトラブルシューティング後、インストールコマンドを再度実行すると、エラーが発生した時点から、Diamond のインストールが続行されます。
ホスト稼働中、 Diamond ホストから他のホストに対して ssh の実行が必要になることがよくあります。このシナリオ向けにクレデンシャルを設定済みかもしれませんが、設定していない場合には、diamond.key
を Diamond ホストのプライベートキーとして使用できます。すべてのホストには Diamond パブリックキーが設定されています。
以下のスクリプトを実行すると、Diamond キーが現行セッションのプライベートキーのリストにコピーされます。
あるいは、Diamond キーを永続的にプライベートキーとして使用することもできます。
Diamond の現バージョンでは、k8s ワーカーホストに対する k8s の Kubernetes 構成は設定されませんが、ワーカーホストにサービスをデプロイするために Kubernetes 構成が必要です。この問題に対処するには、Diamond ホストの IP に対して以下のスクリプトを実行します。 通常、このスクリプトは 第1 SenseLink や CV ノードの IP で実行されます。
このセクションの内容はオプションであり、クラスタの稼動時に頻繁にホストに対して ssh を実行する場合に便利です。リモートでの操作には適用しません。
Diamond ホストの K8s 構成の設定
デフォルトでは、Diamond ホストには k8s の Kubernetes 構成は設定されていません。
使用頻度の高いコマンドのエイリアスの設定
トラブルシューティングの際に頻繁に使用するコマンドがいくつかあります。これらをコマンドエイリアスとして設定することで、ポッドの名前空間といった多くのパラメータを入力する必要がなくなります。
Mercuryライセンスの有効期限が切れる前に、必ずライセンスの更新を行ってください。 ライセンスファイルはJCV製品提供窓口またはその他の窓口から提供されます。 下記のコマンドでMercuryのライセンスを更新できます。
1. MercuryライセンスをSenseLink Enterprise Proのdiamondサーバーへアップロードします。
2. zipファイルの場合、zipファイルを圧縮してください。ここで、example.zip
を例として説明します。
3. 圧縮されたライセンスを確認します。
4. ここでは製品名を取得して、メモします。後ろのステップで必要です。
5. 該当するライセンスファイルをオリジナルのCV設定フォルダーにコピーします。
6. 設定ファイルconfig.yml
を確認します
7. 既存のライセンスファイルをバックアップします。
8. 新しいライセンスへ置き換えます。
9. license-config
を削除します。
インストール済みのstatusファイルを削除します。
定義される製品名を変更します。
setup_cv
を実行します。
podsが再起動できない場合、下記のコマンドを実行してください。
エラーの説明: 実行ファイルが検出されない
Diamond v1.4.3 および Diamond v1.5.3 では、インストール環境で使用される Docker のバージョンは v18.09.2
です。Mercury のテスト環境では、いくつかの理由から Docker バージョンが v18.09.7
にアップグレードされています。バージョンのアップグレードにより、特定のアプリケーションパスや実行パスが変更されます。k8s でポッドが稼働したり、Docker を使用してコンテナを直接起動すると、エラーが表示されます。
もしくは
問題の原因
原因はまだ特定されていません。 Docker のバージョンが 18.09.2 から 18.09.7 にアップグレードされたため、一部の実行ファイルが再計画されています。
問題の解決方法
アップグレードが実行されていない環境で、/usr/bin/
ディレクトリを探し、docker-containerd-shim
と docker-runc
ファイルを問題のマシンの /usr/bin/
ディレクトリにコピーします。
この問題の発生を防ぐには、Ubuntu / CentOSマシンで APT 自動アップグレードサービスを無効にします。スクリプトを実行して、このサービスを停止します。以下のスクリプトは、環境デプロイメントスクリプトに組み込まれています。Diamond のデプロイメントパブリックキーを設定する際、このキーをデプロイメントマニュアル内に見つけることができます。
タイムアウトの説明
Diamond のインストール中に発生
問題の説明
デプロイメントで init_data_fs_vdb
のディスクパーティションの初期化を実行中、Error mounting /mnt/locals/xxx/volume0: mount: mount /dev/vdbx on /mnt/locals/xxx/volumevolume0 failed: Structure needs cleaning
というエラーが発生する場合があります。
問題分析
原因は不明です。この問題は毎回発生するわけではありません。同じデプロイメントスクリプトを使用して、初回実行時にエラーが発生する場合もあれば、繰り返し実行した場合にのみエラーが発生する場合もあります。
問題の修正手順
この問題が発生した場合は、fsck ツールを使用して修正します。たとえば、前述した /dev/vdb5
のエラーが発生した場合、関連ノードにログインして sudo fsck.ext4 /dev/vdb5 -y
コマンドを実行すると、問題を修正できます。エラーの修正後、再度デプロイメントを実行します。
問題の説明
インストールパッケージには、すべてのデプロイメントサービスを削除する remove-services.sh
スクリプトが用意されています。これにより、デプロイメント全体をテストしてから、もう一度インストールをやり直すことができます。しかし、remove-services.sh
スクリプトを実行すると、pv の削除時にスクリプトがフリーズします。一定時間待機すると、問題は解決します。
問題分析
問題の修正手順
別のコンソールを開き、以下のコマンドを実行します。pv のステータスが Terminating
になっていることを確認します。これは、pv が削除を完了できないことを示し、削除スクリプトの処理に影響します。
上記例の場合、 以下のように kubectl edit pv local-pv-12bd5454
の pv を編集します。pv の中にある finalizers
フィールドを探し、値を null
に変更します。保存して終了すると、問題が解決します。元のコンソールのスクリプトは、継続して実行されます。
変更後
デプロイメントのテスト中にデプロイメントのテストを最初からやり直すためには、デプロイされたすべてのリソースを完全に削除してデプロイメント前の状態に戻す必要があるがあります。プロジェクトのインストールパッケージには、これに対応したリソース削除スクリプトが用意されています。このスクリプトでは、互換性の多くが考慮されていません。既存のデプロイメント Ansible をインストールし、実行内容を戻すステップにすぎません。Ansible のデプロイメントコンテンツに変更があった場合、削除スクリプトのコンテンツを同時に変更する必要があります。
mercury/bin/remove-services.sh: すべてのコンポーネント、ライセンスサービス、ローカルボリューム、pv、pvc およびエンジン層とインフラ層のラベルの削除に使用
mercury/bin/remove-volumes.sh: データディスクのデータとパーティション情報の削除に使用
すべてのサービスの削除が必要な場合は、インストールパッケージのディレクトリで以下のコマンドを実行します。ホスト部分は該当する IP で置き換える必要があります。
プラットフォームのインストールで成功の鍵を握るのが yaml 設定ファイルです。このファイルを手動で作成するのは大変な作業です。 そのため、Diamond パッケージには、ユーザがウィザードページで順を追って yaml 設定ファイルを作成することができる http サービスが用意されています。このサービスは Docker コンテナに実装されており、Docker 環境であればどこでも実行できます。以下の手順に従って、ローカルでサービスを設定します。
Ubuntu / CentOSホストが以下の要件を満たしているかを確認します。
Ubuntu のバージョンが 18.04 または 16.04 (CentOSのバージョンが7.4)
8002 番ポート経由でブラウザからアクセス可能 (8002 番ポートは下記のコマンドで変更可能)
Docker 環境が設定されていること。設定されていない場合は、ホストでapt install docker.io
を実行
yaml ジェネレータの Docker イメージを /data/diamond/shells/diamond-wizard-image-2019-10-13.tar
から上記ホストにコピーします。
以下のコマンドを実行して、Docker イメージを解凍してホストにロードし、http サービスを開始します。
docker run
コマンドを実行すると、Docer ID が返されます。この ID は、Docker コンテナを削除する際に使用します。
Diamond v1.4.3 を選択し、ウィザードに従って diamond.yaml コンテンツを生成します。
コンテンツを Diamond ホストの /data/diamond/diamond.yaml
にコピーし、既存のファイルコンテンツを置き換えます。
上記の手順が完了したら、以下のコマンドを実行してサービスを削除します。
リモートマシンのユーザ名とパスワード、およびグループ分散を設定します。以下の指示をご参照ください。
IPS モデルは、mercury/apps/roles/engine-default/main.yml で定義します。face_model_version を変更すると、別のモデルセットが使用されます。以下は、246v2 モデルを使用した face_model_version の設定項目の例です。
VerifyModelPath モデルが異なる場合があるため、モデルコレクションに応じてグラフィックカードを設定する必要があります。各種グラフィックカードで使用される特定のモデルコレクションは、以下のとおりです。
デフォルトの CV サービス要件仕様は、 以下に示すように、ホストに 16 コア、120 GB メモリ、500GB データディスク、2 GPU カードを搭載した 3 ノードを対象にしています。
環境によって仕様が異なる場合があるため、利用可能なリソースに応じてサービスの要件仕様を更新する必要があります。たとえば、8 コア 32 GB、100GB ホストの場合、すべての CV サービスで CPU とメモリ消費を削減する必要があります。 要件仕様は、以下の 2 つのファイルに記述されています。
mercury/group_vars/all.yml
mercury/roles/infra-defaults/defaults/mercury-for-smartgate.yml
mercury/group_vars/init_data_fs_vdb.yml
設定ファイルを開くと、以下に示すような yaml コンテンツが表示されます。 replicas
、cpu
、memory
などの用語は、リソース制限を設定するためのフィールです。
原因は不明です。Kubernetes でも同様の問題が発生する場合がありますが、実際の原因は分かっていません ()。ただし、この問題を解決するための対応策はあります。
ブラウザを開き、 に移動すると、Diamond インストール yaml 生成ウィザード ページが表示されます。
を参照して設定ファイルを作成してください。
ソフトウェア
バージョン
Ansible
2.8.0
python
2.7+
日付
改訂内容
2020/06/12
初版
2020/09/03
「付録3: Mercuryライセンスの更新」の最新化
項目
Diamond ホスト
ワークマシン
マシン名
/etc/hosts で IP マッピングを設定
同左
OS のバージョン
Ubuntu 18.04 / CentOS 7.4
Ubuntu 16.04 / CentOS 7.4
搭載された Python バージョン 2
2.7.15+
2.7.12
Diamond パブリックキーの設定
authorized_keys に追加
同左
DNS 設定
IP を正確に解決できること
同左
ディスクボリューム
システムディスク
システムディスクおよび 1 基以上の Ceph ディスク
システムディスクのサイズ
100GB+
50GB+
GPU カード
-
サービスに基づき GPU カードを設定
ネットワークカード
IP と MAC アドレスを表示
IP と MAC アドレスを表示
CPU
4 コア以上
4 コア以上
メモリ
16GB 以上
16GB 以上
APT のアップデート
アップデート時にエラーが発生しないこと
アップデート時にエラーが発生しないこと
GPU モデル | VerifyModelPath |
NVIDIA GeForce GTX 1080 | 246v2 |
NVIDIA Tesla P4 | 246v2 |
NVIDIA Tesla P100 | 247v2 |
サービス | 単位 | CPU | GPU | メモリ | HD |
AlertFeatureDB | 2 + 2 | 4 + 1 | - | 6G + 12G | 1G |
FaceExtractService | 3 | 3 | 1 | 10G | - |
API-Wrapper | 2 | 1 | - | 9G | - |
Cassandra | 3 | 2 | - | 16G | 200G |
MinIO | 2 | 1 | - | 4G | 10G |
Fluentd | 3 | 0. | - | 0.5G | - |