Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
本資料はIT運用担当者向けのものです。Linux、kubernetes、docker、クラウドなどの運用知識が必要です。
本ドキュメントでは、SenseLink サービスをクラウド上にデプロイする方法について説明します。Ansible、Bash シェルスクリプトなどを使用して、Diamond プラットフォームや SenseLink サービスを含むすべてのコンポーネントをデプロイします。
デプロイメントの主な手順は、次のとおりです。
マシンの準備
Diamond プラットフォームのデプロイ
SenseLink サービスのデプロイ
インストールパッケージのバックアップ
デプロイメントプロセスを簡素化するため、本ドキュメント内で使用する規則がいくつかあります。
Diamond 環境の SenseLink では、アカウント ubuntu
を使用してすべてのコンポーネントをデプロイします。アカウントが明示されていない限り、すべてのデプロイメントコマンドは ubuntu
ユーザで実行する必要があります。
インストールパッケージは、シードホストの /data/
フォルダに格納します。通常、シードホストは第 1 の Diamond ホストです。このフォルダは、デプロイメント時には BASE_DIR
と呼ばれます。
インストールパッケージを作成するには、ネットワーク内の関連コンポーネントのバイナリ、Docker イメージへのアクセス権、およびスクリプトプロジェクトをデプロイするのに十分な権限が必要です。また、インストーラパッケージは、作成したインストーラスクリプトを実行するマシンの /data
フォルダに格納します。
SenseLink のデプロイは完了しました。この時点で、今後の使用に備えてインストーラパッケージ全体をバックアップすることを推奨します。以下の理由から、インストールパッケージは削除しないでください。
パッケージ内の構成は現行環境で一意になっています。
以下に示す Diamond サービスの設定ファイルとエンドポイント情報は、$install_package_path/diamond/reports に生成されおり、Diamond サービスやリソースを呼び出す際に役立ちます。
report: エンドポイントアドレスとサービス情報を含むリポート
iaasKubeConfig: IaaS API サービスの Kubernetes 形式の設定
lcmKubeConfig: LCM API サービスの Kubernetes 形式の設定
k8sKubeConfig: 現行の k8s クラスタの特権ユーザに関する Kubernetes 設定
sensetimeKubeConfig: 現行の k8s クラスタの一般ユーザに関する Kubernetes 設定
アーカイブや再デプロイ用のサービスやポッドの Kubernetes yaml ファイル
インストーラパッケージが生成済みであることが前提です。Diamond ホストに /data
のフォルダを準備し、フォルダ内にインストーラパッケージがあることを確認します。
手動アーキテクチャの場合、すべてのホストが Diamond デプロイの前提条件を満たしている必要があります。 事前確認処理はデプロイプロセスの中で実行されます。ホストの前提要件は以下のとおりです。
・GPUドライバーがプリインストールされている場合、以下の手順をスキップできます。
・GPUドライバーをDiamondによってインストールする場合、以下の準備が必要です。
config file /etc/modprobe.d/blacklist.conf
Reboot The ECS Hosts
セットアップを開始する前に、$install_package_path/config.yaml
でファイルを構成します。
Diamond のインストールには時間かかるため (1.5~2 時間)、tmux
や screen
を使用してセッションを作成してから次のスクリプトを実行することを推奨します。セッションを作成しない場合、セッションのハングアップが原因でインストールが中断します。
インストーラの実行中、Diamond ワークフローインストーラの高度な実行ステップが表示されます。Diamond ホストで tail -f $install_package_path/setup_diamond.log
を実行してサブコンポーネントの詳細ログを表示することも可能です。
Diamond プラットフォームのインストールが正常に完了すると、ダイヤ型の図が画面に表示されます。Server error
というテキストが出力される場合はインストールが失敗したことを示します。詳細はサブコンポーネントログをご確認ください。問題の修正後、前述したコマンドを再実行します。
Senselink Web サービスでは 80 番ポートが必要になるため、以下のコマンドを使用してk8s クラスタで k8s サービスノードのポート範囲を 1~65535 に変更する必要があります。
ホストの稼働中、Diamond ホストから他のホストに対して ssh の実行が必要になることがよくあります。このようなシナリオ向けにクレデンシャルが設定済みかもしれませんが、設定していない場合は、diamond.key
を Diamond ホストのプライベートキーとして使用できます。すべてのホストには Diamond パブリックキーが設定されています。
以下のスクリプトを実行すると、Diamond キーが現行セッションのプライベートキーのリストに追加されます。
あるいは、ユーザの Diamond キーをホストのプライベートキーとして永続的に使用することもできます。
Diamond ではk8s ワーカーホスト用の k8s kubeconfig は設定されませんが、SenseLink のデプロイでは、ワーカーホストにサービスをデプロイするために k8s kubeconfig が必要です。この問題に対処するには、以下のスクリプトを Diamond ホストで複数回実行し、Diamond ホスト IP と k8s ワーカー IP を host_ip
に割り当てます。
Diamond プラットフォームのインストールが完了すると、Diamond ポータルが稼働します。ポータルサービスは、Kubernetes クラスタにインストールされます。このポータルには http://SLB_IP:30080/ でアクセスできます。
このセクションの内容はオプションであり、クラスタの稼動時に頻繁にホストに対して ssh を実行する場合に便利です。
トラブルシューティングの際に頻繁に使用する k8s コマンドがいくつかあります。それらのコマンドをエイリアスとして設定することで、長いコマンドを入力する必要がなくなります。
Kubernetes 環境の最上位にある senselink
の名前空間に、すべての SenseLink コンポーネントがデプロイされています。つまり、kubectl
を使用して SenseLink リソースに対するクエリを実行する際、-n senselink
をパラメータとして追加する必要があります。
kubectl -n senselink get pods
コマンドを実行すると、SenseLink ホストの senselink
名前空間で、以下のポッドが稼働します。
kubectl -n senselink get services
コマンドを実行すると、SenseLink ホストの senselink
名前空間で、以下のサービスが稼働します。
Diamond ホストでは、クラスタ管理コンポーネントが稼働します。HA 環境以外の場合は、1 台の Diamond ホストで十分です。HA を設定する場合は 3 台の Diamond ホストが必要です。
SenseLink ホストでは、SenseLink サービスが稼働します。HA クラスタとして 3 台のホストが必要です。SenseLink Enterprise Pro 用ホストの最小システム要件を以下に記載します。
ELK ホストでは、Elasticsearch サービスが稼働します。HA クラスタとして 2 台以上のホストが必要です。ELK ホストには大容量ストレージディスクを搭載することを推奨します。 ストレージ容量の要件については、以下の表をご参照ください。
また、 SenseLink ホストの拡張ディスクは、初期化して /data
パスにマウントする必要があります。
下記は300
台のデバイスで25,000従業員が1日に4回顔認証を実施して1.5年間に使う場合のサーバー構成例です。SenseLinkホストとCVホストはそれぞれ3台の構成となっています。
SenseLinkホストとCVホストをスケールアウトして、それぞれ4台の構成にする場合、400
台のデバイスで25,000従業員が1日に4回顔認証を実施して1.5年間に使える見込みです。
SenseLink Enterprise Pro をクラウド上にデプロイするには、3 つの SLB サービスが必要です。1 つは内部用、2 つは外部トラフィック用です。SLB サービスはデプロイで使用されるため、デプロイの前に SLB の構成を設定する必要があります。
外部 SLB によりクラウド内のサービスが外部と繋がり、SenseLink 管理者やすべての Sense デバイスがクラウドサービスにアクセスできるようになります。外部 SLB の構成を以下に記載します。1 番目の外部 SLB はインターネットによるアクセスが可能です。2 番目の外部 SLB には、Web 管理サイトおよび Diamond ポータルサイトの管理者のみがアクセスできます。特に 2 番目の外部 SLB は、イントラネットからのアクセスのみを許可することを推奨します。
内部 SLB は、Kubernetes API の HA サービス用であり、 トラフィックをすべての k8s マスターサーバにルーティングします。これにより、k8s マスターホストがクラッシュしても、現行の k8s クラスタに影響が及ぶことはありません。
SenseLink では、ソリューション内の MongoDB、MySQL、Redis および OSS が活用されます。これらのサービスは、クラウドプロバイダーから購入します。このとき、サービスの仕様が以下に記載する要件を満たしているかを注意して確認する必要があります。 特にデータベースのアカウントに注意が必要です。ユーザやデータベースを作成するには、高い特権
が設定されたアカウントが必要です。
SenseLinkをインストールする前に、データベースの初期化が必要です。高特権のアカウントを使用して、下のSQLでデータベースを初期化してください。
サーバホストに接続するための キーリングデータ がローカルファイルに保存されている場合、keyring_file プラグイン が必要です。 キーリングプラグインがアクティブになっているかを確認するには、SHOW PLUGINS 構文を使用するか、INFORMATION_SCHEMA.PLUGINS テーブルに対してクエリを実行します。以下に例を示します。
デプロイや稼働中、 Diamond ホストからワークロードホストに対して ssh の実行が必要になる場合があります。すべての ECS ホストの /etc/hosts
でニックネームを設定すると、ssh を簡単に実行できるようになります。ニックネームは、ECS の元のホスト名にすることもできます。
root
アカウントを使用して、すべてのホスト (Diamond ホストと SenseLink ホスト) で以下のスクリプトを実行し、ディスクをマウントします。
root
アカウントを使用して、Diamond ホスト で以下のスクリプトを実行し、パスワードなしで sudo を実行できるユーザとして ubuntu を作成し、その他の初期設定を行います。
すべてのホスト で、フォルダ /data
のオーナーを ubuntu
のアカウントに変更する必要があります。
項目
Diamond ホスト
Senselink ホスト
ホスト名
/etc/hosts
にマッピング済み
同左
OS バージョン
Ubuntu 16.04/CentOS 7.4
Ubuntu 16.04/CentOS 7.4
Python バージョン
2.7.15
2.7.12
Diamond SSH キー
/home/ubuntu/authorized_keys
に設定済み
Diamond ホストと同じ
DNS レゾルバ
適切な構成
Diamond ホストと同じ
ディスクボリューム
OS ボリュームが必要
OS ボリュームが必要。少なくとも 1 つのデータボリューム
ディスクの空き容量
100GB
500GB
GPU カード
-
事前にGPUドライバーをインストールか、インストールのためにDiamondに置いておきます
インターネットカード
IP および MAC
IP および MAC
CPU 情報
-
-
メモリ情報
-
-
APT のアップデート
エラーが発生しないこと
エラーが発生しないこと
GPU
ドライバーバージョン
サンプル
Tesla P4
384.183
nvidiaDriverVersion: '384.183'
Tesla P100
410.129
nvidiaDriverVersion: '410.129'
Tesla T4
410.129
nvidiaDriverVersion: '410.129'
項目
説明
例
HOSTS
ホスト名およびすべてのホストの IP をカンマで区切って指定
'hd1h1 192.168.1.201,hd1h2 192.168.1.202,hd1h3 192.168.1.203,hd1h4 192.168.1.204,hd1h5 192.168.1.205,hd1h6 192.168.1.206'
DIAMOND_HOST
Diamond ホスト名
'hd1h1'
MASTER_HOST
k8s マスターのホスト名
'hd1h2, hd1h3, hd1h4'
WORKER_HOST
k8s ワーカーのホスト名
'hd1h1, hd1h5, hd1h6'
LINK_NODE
Senselink ノードのホスト名
'hd1h2, hd1h5, hd1h6'
ELASTICSEARCH_NODE
サービスのログストレージに使用する Elasticsearch ノードのホスト名
'hd1h2, hd1h5, hd1h6' elasticsearch
K8S_MASTER_SLB_IP
k8s マスターホスト用の内部 SLB の IP。k8s マスターホストが 2 つ以上設定されている場合に必要
'192.168.1.300'
SENSELINK_PORTAL_IP
Senselink ポータル用の外部 SLB のドメインまたは IP
'192.168.1.300'
MYSQL_HOST
MySQL リソースの URL
MYSQL_ROOT_USER
高い特権をもつ MySQL のアカウント (許可、作成、挿入など)
-
MYSQL_ROOT_PASSWORD
上記アカウントのパスワード
MONGO_HOST
MongoDB リソースの URL
MONGO_PORT
MongoDB リソースのポート
MONGO_USERNAME
MongoDB のアカウント
-
MONGO_PASSWORD
上記アカウントのパスワード
REDIS_HOST
Redis リソースの URL
REDIS_PASSWORD
上記アカウントのパスワード
MAIL_HOST
電子メールの SMTP アドレス。上記アカウントの変更に関するイベント発生時に、電子メールを送信する際に使用される。
MAIL_PORT
電子メールの SMTP のポート
MAIL_USERNAME
電子メールアカウント
-
MAIL_PASSWORD
電子メールアカウントのパスワード
OSS_ENABLE
Aliyun OSS の有効化
true または false
OSS_ENDPOINT
OSS のエンドポイント。OSS はイメージストレージに使用される。
OSS_ACCESSID
OSS のアクセス ID
OSS_ACCESSKEY
OSS の アクセスキー
OSS_BUCKETNAME
OSS のバケット名
NGINX_ACCESS_CONTROL_ALLOW_ORIGIN
許可するドメイン名の設定
TIME_ZONE
タイムゾーン
GMT+09:00 by default
日付 | 改訂内容 |
2020/06/12 | 初版 |
2020/09/07 | 環境の準備->ホストマシン節 ハードウェア要件を更新 環境の準備->SLBサービス節 不要な外部SLBの記述を削除;SenseLinkポータルのバックエンドポートを80から40080へ変更 付録2->SenseLink サービス節 webのNodePortを80から40080へ変更 |
タイプ | 名称 | インスタンス | ステータス |
pod | apiv2-X | X = リンクノード番号 | Running |
pod | emq | 1 | Running |
pod | feature-X | X = リンクノード番号 | Running |
pod | fs-X | X=1 | Running |
pod | infra2-X | X = リンクノード番号 | Running |
pod | mmo-init-job | 0 | Completed |
pod | openapi-X | X = リンクノード番号 | Running |
pod | opq | 1 | Running |
pod | schedule2 | 1 | Running |
pod | slinkpush | 1 | Running |
pod | sntp | 1 | Running |
pod | sync-X | X = リンクノード番号 | Running |
pod | web-X | X = リンクノード番号 | Running |
pod | tk-X | 1 | Running |
pod | event-X | X = リンクノード番号 | Running |
pod | nebula | X = 1 | Running |
pod | zookeeper | 1 | Running |
pod | websocket | 1 | Running |
名称 | タイプ | 外部 IP | ポート |
apiv2 | ClusterIP | なし | 8080/TCP, 8081/TCP, 20860/TCP |
emq | ClusterIP | なし | 8083/TCP, 8084/TCP, 8883/TCP, 1883/TCP, 18083/TCP, 18084/TCP |
feature | ClusterIP | なし | 50052/TCP |
fs | ClusterIP | なし | 20080/TCP |
infra | ClusterIP | なし | 50009/TCP, 50010/TCP |
mongo | ExternalName | dds-xxxxxxxx.mongodb.japan.rds.aliyuncs.com | なし |
mysql | ExternalName | rm-xxxxxxxx.mysql.japan.rds.aliyuncs.com | なし |
openapi | ClusterIP | なし | 8099/TCP |
opq | ClusterIP | なし | 9001/TCP |
redis | ExternalName | r-xxxxxxxx.redis.japan.rds.aliyuncs.com | なし |
schedule2 | ClusterIP | なし | なし |
slinkpush | ClusterIP | なし | 50055/TCP |
sntp | ClusterIP | なし | 10080/TCP, 50080/TCP |
sync | ClusterIP | なし | 1010/TCP, 50051/TCP |
web | NodePort | なし | 40080:80/TCP |
websocket | ClusterIP | なし | 9000/TCP, 9099/TCP |
zookeeper | ClusterIP | なし | 2181/TCP, 2888/TCP, 3888/TCP |
tk | ClusterIP | なし | 8091/TCP, 50011/TCP, 20880/TCP |
nebula | ClusterIP | なし | 55555/TCP, 20861/TCP |
event | ClusterIP | なし | 8089/TCP, 20870/TCP |
デイリーアクティブデバイス | ログレプリカ (デフォルト) | レグリカあたりのログストレージ | 有効期限 (デフォルト) | ストレージ要件 | 備考 |
100 | 2 | 3 GB | 15 | 100 GB | (ログレプリカ) * (レプリカあたりのストレージ) * (有効期限) |
200 | 2 | 3 GB | 15 | 200 GB |
ホスト名 | 用途 | CPU | メモリ | OS ディスク | 拡張ディスク | 備考 |
ECS 0 | Diamond ホスト | 8 コア | 32 GB | 500 GB | 500 GB | -- |
ECS 1~3 | SenseLink ホスト | 8 コア | 32 GB | 500 GB | 500 GB | -- |
ECS 4~6 | CV ホスト | 16 コア | 120 GB | 500 GB | 500 GB | GPU*2, Nvidia P100 |
用途 | 用途 | リスナー | 外部ポート | ルール | バックエンド ポート | ホスト |
1 番目の外部 SLB | SenseLink ポータル (要認証) | HTTPS | 443 | RoundRobin | 40080 | ECS 1/2/3/4/5/6 |
2 番目の外部 SLB | Diamond ポータル (オプション) | HTTP | 30080 | RoundRobin | 30080 | ECS 1/2/3/4/5/6 |
用途 | リスナー | 外部ポート | ルール | バックエンドポート | ホスト |
Kubernetes HA | TCP または HTTPS | 9443 | RoundRobin | 6443 | ECS 0/1/2 |
サービス | バージョン | アカウント | 備考 |
MySQL | v5.7 | 高い特権 | # setting global variables set global innodb_large_prefix=1; set global log_bin_trust_function_creators=1; |
MongoDB | v4.0 | 高い特権 | --- |
Redis | v5.0 | -- | -- |
OSS | -- | -- | -- |
Diamondのインストールが中断された時に、多くのpodにImageInspectErrorが発生する場合、以下の手順で復旧する可能性があります。
SenseLinkをアクティベーションにする前に、全てのホスト用にライセンスファイルとアクティベーションを準備する必要があります。 当手順はライセンスの更新時も同様です。ライセンスファイルの有効期限が切れる前に、必ず更新を行ってください。
また、ライセンスファイルとアクティベーションコードを申請するために、featureサービスのログからDUIDを取得する必要があります。
ライセンスファイルとアクティベーションコードを手に入れたら、次の処理でホストをアクティベーションできます。
ライセンスファイルがHOSTPATH
にあること
replicas
の数は1となること
Node selectorはapp:senselink feature:enable
であること
ライセンスファイルがHOSTPATH
にあること
replicas
の数はSenseLinkノードの数を同じであること
Node selectorはapp:senselink feature:enable
であること
最後にNode selectorのfeature:enable
を削除します。
オペレーションログのクライアントIPは実際のIPではありません。 SenseLinkポータルIPが外部SLBのIPである場合、オペレーターログのクライアントIPは実際のIPではない可能性があります。この問題を解決するには、外部配置を追加する必要があります。
以下の設定からセッションタイムアウト時間を変更することができます。
PV や PVC を削除できない場合
sk patch pvc infra-claim-infra-1 -p '{"metadata":{"finalizers":null}}'
SenseLink: Apiv2 ポッドでポート番号問題により CrashLoopBackOff が発生する場合
Apiv2 ポッドクラッシュの状況
SenseLink のデプロイ後、 apiv2
ポッドが以下のように CrashLoopBackOff
の状態になりました。
ポッドのログを確認すると、以下に示すような 'java.lang.String' のタイプ値を 'java.lang.Integer' の該当するタイプに変換できない (Failed to convert value of type 'java.lang.String' to required type 'java.lang.Integer') という内容のエラーが何行も表示されます。
Apiv2 ポッドクラッシュの原因
原因は不明ですが、infra-service のキャッシュにより apiv2 の正常動作を妨げられたことが原因であると推測されます。 SenseLink のコンポーネントには動作依存があります。このため、コンポーネントは順番にデプロイされます。今回のケースでは、infra-service が apiv2 の後にデプロイされていました。したがって、この問題は通常発生することはありません。
Apiv2 ポッドのクラッシュ問題の修正
statefulset infra-service と apiv2 を削除してから、apiv2、infra-service の順にデプロイします。
コマンド未検出の状況
現バージョンの Diamond v1.8.3 では、Docker v18.09.2
がコンテナコンポーネントとしてインストールされますが、Ubuntu では APT アップグレードサービスによって Docker が v18.09.7
にアップグレードされることがあります。この変更により、稼働中のコンテナでエラーが発生し、k8s ポッドのエラーを引き起こします。問題のログを精査すると、docker-containerd-shim
が検出されなかったことを示すエラーメッセージを確認できます。
docker-runc
が検出されなかったことを示す別のエラーが表示されることもあります。
コマンド未検出の原因
根本原因は調査されていませんが、新バージョンで別の実行ライブラリ構造が使用されたため、一部のファイルが削除されていました。
コマンド未検出問題の対応策
適切なバージョンの Docker を使用して別の環境を構築することをお勧めします。任意の Docker または k8s ホストの /usr/bin/
フォルダに移動します。 docker-containerd-shim
および docker-runc
ファイルを問題のホストの /usr/bin/
にコピーします。
同じ問題が再び発生しないようにするためには、以下のコマンドを使用して APT のアップグレードサービスを無効にすることをお勧めします。以下のコマンドは、クラスタ内のすべてのホストに対する Diamond パブリックキーを設定するセクションで、デプロイメントガイドに追加されています。
ワークロードマシンにNTPサービスを使用したい場合は、クラウドサービスのNTPサービスマニュアルを参照してください。
kubernetesマスタがサービスダウンまたは何か問題があった場合、kubernetesマスタを再起動しないといけません。ただし、再起動しても、サーバーが正常に起動できますが、k8sはLoad Balanceから情報を取得できません。
kubeの設定がまだ三つのマスタに指しているのは原因となります。
3回目の取得コマンドは待ち状態となってしまって、応答がありませんでした。
ところが、ポート6443は動いています。Load Banlanceをマスタに切り替えて、.kube/config
を修正したら、すぐに応答が帰ってきました。
修正前:
修正後:
修正後、もう一回試したら、応答が予想通りに帰ってきました。
調べた原因として、下記の二つのコンテナが起動されませんでした。
手動でdockerを起動したら
サービスは正常に戻りました。