SystemLink Enterpriseを1つまたは複数のリモートMongoDBデータベースにアクセスするように構成することにより、拡張性と耐障害性を強化することができます。

以下の条件の場合に既存のMongoDBデータを移行する必要があります。
  • 2023-10より前のSystemLink Enterpriseバージョンからアップグレードする場合。
  • global.mongodb.installをtrueに設定します。

移行条件の詳細については、リリースノートを参照してください。

  1. SystemLink Enterpriseを初めてインストールする場合は、以下の表に記載されているデータベースをプロビジョニングします。
  2. systemlink-secrets.yamlを開きます。
  3. 各データベースのパスワードを設定します。
    メモ すべてのデータベースに対して 1セットの資格情報を使用するには、各データベースのデータベースフィールドを空白のままにします。
    表 16. MongoDBインスタンスの構成パラメータ
    サービス データベース ユーザ パスワード
    alarmservice nialarm nialarm alarmservice.secrets.mongodb.servicePassword
    assetservice niapm niapm assetservice.secrets.mongodb.servicePassword
    comments comments nicomments comments.secrets.mongodb.servicePassword
    dataframeservice nidataframe nidataframe dataframeservice.secrets.mongodb.servicePassword
    fileingestion files files fileingestion.secrets.mongodb.servicePassword
    filescdc (optional) files files fileingestioncdc.secrets.mongodb.password
    feedservice nifeeds nifeeds feedservice.secrets.mongodb.servicePassword
    nbexecservice ninbexec ninbexec nbexecservice.secrets.mongodb.servicePassword
    notification ninotification ninotification notification.secrets.mongodb.servicePassword
    repository nirepo nirepo repository.secrets.mongodb.servicePassword
    routinescheduletrigger niroutinescheduletrigger niroutinescheduletrigger routinescheduletrigger.secrets.mongodb.servicePassword
    routineservice niroutines niroutines routineservice.secrets.mongodb.servicePassword
    saltmaster minions minions saltmaster.secrets.mongodb.minionsPassword
    saltmaster pillars pillars saltmaster.secrets.mongodb.pillarsPassword
    specificationmanagement (optional) specifications nispecificationmanagement specificationmanagement.secrets.mongodb.servicePassword
    systems nisystemsmanagement nisystems systems.secrets.mongodb.servicePassword
    systemsstate nisystemsstate nisystemsstate systemsstate.secrets.mongodb.servicePassword
    tags tags tags tags.secrets.mongodb.servicePassword
    taghistorian taghistorian taghistorian taghistorian.secrets.mongodb.servicePassword
    userdata niuserdata niuserdata userdata.secrets.mongodb.servicePassword
    userservices keyservices keyservice userservices.secrets.mongodb.keyServicePassword
    userservices users userservice userservices.secrets.mongodb.userServicePassword
    webappservices webapps webapps webappservices.secrets.mongodb.servicePassword
    workorder (optional) workorders niworkorder workorder.secrets.mongodb.servicePassword
  4. NIサポートに連絡して、以下を確認します。
    • デプロイするMongoDBインスタンスの数。
    • 特定のインスタンスに接続する必要があるサービス。
  5. デプロイメント用のMongoDB接続文字列を構成します。接続文字列の形式の詳細については、以下の表を参照してください。
    表 17. デプロイメントの形式に応じた構成手順
    デプロイメントの形式 構成手順
    デプロイメントに1つのMongoDBインスタンスがある。
    1. systemlink-secrets.yamlファイルを開きます。
    2. global.secrets.mongodb.connection_stringを適切な接続文字列の値に設定します。
    すべてのサービスがこの文字列でそのインスタンスに接続します。
    デプロイメントに複数のMongoDBインスタンスがある。

    MongoDBインスタンスの構成パラメータ表の各サービスについて、接続文字列を構成します。

    1. systemlink-values.yamlファイルを開きます。
    2. <service_name>.mongodb.connection_stringを、そのサービスが接続するMongoDBインスタンスの適切な値に設定します。
    3. <service_name>を、MongoDBインスタンスの構成パラメータ表のサービス列の値に置き換えます。

    たとえば、アラームサービスの接続文字列を構成するには、alarmservice.mongodb.connection_string値を設定します。userservicesなど、表に複数回示されているサービスでは、接続文字列を1回のみ設定します。
    メモ <username>、<password>、<database>などの山括弧で囲まれたプレースホルダは、デプロイ時にSystemLinkによって値が動的に代入されます。これらのプレースホルダを手動で書き換える必要はありません。特に他の注記がない限り、記載どおりに文字列を入力してください。
    表 18. MongoDBタイプに応じた接続文字列
    MongoDBタイプ 接続文字列
    MongoDB Atlas mongodb+srv://<username>:<password>@my-atlas-cluster.mongodb.net/<database>
    MongoDB Community mongodb://<username>:<password>@my-mongodb-cluster-0,my-mongodb-cluster-1,my-mongodb-cluster-2/<database>?replicaSet=rs0
    MongoDB Community - 1セットの資格情報を使用 mongodb://myusername:mypassword@my-mongodb-cluster-0,my-mongodb-cluster-1,my-mongodb-cluster-2/<database>?replicaSet=rs0

    以下の規定があります。

    • myusername は、MongoDBインスタンスのユーザ名です。
    • mypassword は、MongoDBインスタンスのパスワードです。
  6. systemlink-values.yamlを開きます。
  7. globals.mongodb.installをfalseに構成します。

MongoDBデプロイメントを選択する

SystemLinkサービスのほとんどは、MongoDBをプライマリデータベースとして使用します。MongoDBインスタンスは、SystemLink Enterpriseインストールまたは外部インスタンスと同じKubernetesクラスタ内で使用できます。SystemLink Enterpriseバージョン2023-10時点でサービスがサポートしているのは、単一のスタンドアロンMongoDBインスタンスです。

以下の表を使用して、ユースケースに最適なMongoDBデプロイメントを選択してください。
表 19. MongoDBデプロイメントを選択する
デプロイメント 使用目的 詳細
MongoDB Atlas データベースのプロビジョニング、操作、バックアップ、復元操作を簡素化したい場合。 NIでは、以下のガイドラインに従ってデプロイすることを推奨します。
  • 専用クラスタを使用する。
  • 各レプリカに4つのCPUコアと32 GBのメモリがあることを確認します。
  • インスタンス用に512 GBのストレージがあることを確認する。
  • Kubernetesクラスタがクラウドで実行されている場合は、同じクラウドプロバイダリージョンにインスタンスをデプロイする。
メモ Atlasの機能を使用して、より小さなインスタンスを初期化し、必要に応じて自動スケールすることができます。コストが予算を超えないように制限を設定します。
MongoDB Enterprise AdvancedなどのスタンドアロンMongoDBインスタンス データベースを制御する必要があるが、さらにエンタープライズレベルの制御が必要な場合。

NIでは、以下のガイドラインに従ってデプロイすることを推奨します。

  • 専用クラスタを使用する。
  • 各レプリカに4つのCPUコアと32 GBのメモリがあることを確認します。
  • インスタンス用に512 GBのストレージがあることを確認する。
Bitnami MongoDBチャートなどのHelmチャート内のMongoDB
  • SystemLink Enterpriseと同じKubernetesクラスタにデータベースが必要な場合。
  • 組織がMongoDBインスタンスの管理に慣れている場合。

このインスタンスは、テイントと許容を使用して、既存のKubernetesワーカノードまたは専用ワーカノードで実行することができます。

NIでは、デプロイ時に以下のカスタム設定を使用することを推奨します。要求と制限は、Kubernetesワーカノードの他のポッドに合わせて調整できます。
resources:
  requests:
    cpu: 4
    memory: 32Gi
  limits:
    memory: 32Gi

persistence:
  enabled: true
  accessModes:
    - ReadWriteOnce
  size: 512Gi
  annotations: {}