Skip to main content
BeeGFS on NetApp with E-Series Storage
日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

Ansibleのインベントリを確認できます

共同作成者

導入を開始する前に、Ansibleを使用して、第2世代のBeeGFSビルディングブロック設計を使用してNetApp解決策 にBeeGFSを設定して導入する方法を確認してください。

Ansibleインベントリは、ファイルノードとブロックノードの構成を定義し、導入するBeeGFSファイルシステムを表します。インベントリには、目的のBeeGFSファイルシステムを記述するホスト、グループ、および変数が含まれます。サンプルインベントリは、からダウンロードできます "NetApp EシリーズBeeGFS GitHub"。

Ansibleのモジュールとロール

Ansibleインベントリで説明されている構成を適用するには、NetApp EシリーズAnsibleコレクションに含まれるさまざまなAnsibleモジュールとロール、特にBeeGFS HA 7.2ロール（から入手可能）を使用します "NetApp EシリーズBeeGFS GitHub"）を使用してエンドツーエンドの解決策 を導入します。

NetApp EシリーズAnsibleコレクションの各ロールは、NetApp解決策 上のBeeGFSをエンドツーエンドで導入します。これらのロールでは、NetApp E-Series SANtricity 、Host、およびBeeGFSの各コレクションを使用して、HA（High Availability）を使用してBeeGFSファイルシステムを設定できます。その後、ストレージをプロビジョニングしてマッピングし、クラスタストレージを使用できる状態にします。

ロールには詳細なドキュメントが含まれていますが、導入手順では、第2世代のBeeGFSビルディングブロック設計を使用して、ロールを使用してNetApp Verified Architectureを導入する方法について説明します。

メモ 導入手順でAnsibleの使用経験が十分に細かい情報を提供できるようにすることは前提条件ではありませんが、Ansibleと関連する用語についてある程度理解している必要があります。

BeeGFS HAクラスタのインベントリレイアウト

Ansibleのインベントリ構造を使用して、BeeGFS HAクラスタを定義します。

以前のAnsibleの経験がある方は、BeeGFS HAロールでは、各ホストに適用される変数（ファクト）を検出するカスタムメソッドが実装されることに注意してください。これは、複数のサーバで実行可能なリソースを記述したAnsibleインベントリの構築を簡易化するために必要です。

Ansibleのインベントリは通常'host_vars'および'group_vars'のファイルと'特定のグループ（および他のグループに潜在的にグループ）にホストを割り当てる'inventory.yml'ファイルで構成されます

メモ このサブセクションの内容を含むファイルは、例としてのみ作成しないでください。

この構成は構成プロファイルに基づいて事前定義されていますが、以下に示すように、すべてがAnsibleインベントリとしてどのようにレイアウトされるかについて一般的に理解しておく必要があります。

# BeeGFS HA (High Availability) cluster inventory.
all:
  children:
    # Ansible group representing all block nodes:
    eseries_storage_systems:
      hosts:
        ictad22a01:
        ictad22a02:
        ictad22a03:
        ictad22a04:
        ictad22a05:
        ictad22a06:
    # Ansible group representing all file nodes:
    ha_cluster:
      children:
        meta_01:  # Group representing a metadata service with ID 01.
          hosts:
            file_node_01:  # This service is preferred on the first file node.
            file_node_02:  # And can failover to the second file node.
        meta_02:  # Group representing a metadata service with ID 02.
          hosts:
            file_node_02:  # This service is preferred on the second file node.
            file_node_01: # And can failover to the first file node.

サービスごとに'構成を記述するgroup_varsの下に追加ファイルが作成されます

# meta_01 - BeeGFS HA Metadata Resource Group
beegfs_ha_beegfs_meta_conf_resource_group_options:
  connMetaPortTCP: 8015
  connMetaPortUDP: 8015
  tuneBindToNumaZone: 0
floating_ips:
  - i1b: <IP>/<SUBNET_MASK>
  - i4b: <IP>/<SUBNET_MASK>
# Type of BeeGFS service the HA resource group will manage.
beegfs_service: metadata # Choices: management, metadata, storage.
# What block node should be used to create a volume for this service:
beegfs_targets:
  ictad22a01:
    eseries_storage_pool_configuration:
      - name: beegfs_m1_m2_m5_m6
        raid_level: raid1
        criteria_drive_count: 4
        owning_controller: A
        common_volume_configuration:
          segment_size_kb: 128
        volumes:
          - size: 21.25

このレイアウトでは、各リソースのBeeGFSサービス、ネットワーク、ストレージの構成を1か所で定義できます。バックグラウンドでは、BeeGFSロールは、このインベントリ構造に基づいて各ファイルおよびブロックノードに必要な設定を集約します。詳細については、次のブログ記事を参照してください。 "ネットアップがAnsibleでBeeGFSのHA構成の導入を高速化"。

メモ 各サービスのBeeGFS数値と文字列ノードIDは、グループ名に基づいて自動的に設定されます。したがって、グループ名を一意にするための一般的なAnsibleの要件に加えて、BeeGFSサービスを表すグループは、グループが表すBeeGFSサービスのタイプに一意の番号で終わる必要があります。たとえば、meta_01とstor_01は許可されますが、meta_01とmeta_01は許可されません。