Ansibleのインベントリを確認できます
導入を開始する前に、Ansibleがどのように設定され、BeeGFS on NetAppソリューションの導入に使用されるかについて理解しておいてください。
Ansibleインベントリは、導入するBeeGFSファイルシステムのファイルノードとブロックノードをリストしたディレクトリ構造です。これには、目的のBeeGFSファイルシステムを記述するホスト、グループ、および変数が含まれます。Ansibleインベントリは、Ansibleコントロールノードに格納する必要があります。コントロールノードとは、Ansibleプレイブックの実行に使用されるファイルノードとブロックノードにアクセスできる任意のマシンです。サンプルインベントリはからダウンロードできます "NetApp EシリーズBeeGFS GitHub"。
Ansibleのモジュールとロール
Ansibleインベントリに記載されている構成を適用するには、エンドツーエンドのソリューションを導入するNetApp EシリーズAnsibleコレクション(から入手可能)に含まれているさまざまなAnsibleモジュールとロールを使用し "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インベントリは通常、およびのファイルと inventory.yml、 `group_vars`ホストを特定のグループ(場合によっては他のグループ)に割り当てるファイルで構成され `host_vars`ます。
|
|
このサブセクションの内容を含むファイルは、例としてのみ作成しないでください。 |
この構成は構成プロファイルに基づいて事前定義されていますが、以下に示すように、すべてがAnsibleインベントリとしてどのようにレイアウトされるかについて一般的に理解しておく必要があります。
# BeeGFS HA (High Availability) cluster inventory.
all:
children:
# Ansible group representing all block nodes:
eseries_storage_systems:
hosts:
netapp01:
netapp02:
# Ansible group representing all file nodes:
ha_cluster:
children:
meta_01: # Group representing a metadata service with ID 01.
hosts:
beegfs_01: # This service is preferred on the first file node.
beegfs_02: # And can failover to the second file node.
meta_02: # Group representing a metadata service with ID 02.
hosts:
beegfs_02: # This service is preferred on the second file node.
beegfs_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>
- i2b: <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:
netapp01:
eseries_storage_pool_configuration:
- name: beegfs_m1_m2_m5_m6
raid_level: raid1
criteria_drive_count: 4
common_volume_configuration:
segment_size_kb: 128
volumes:
- size: 21.25
owning_controller: A
このレイアウトでは、各リソースのBeeGFSサービス、ネットワーク、ストレージの構成を1か所で定義できます。バックグラウンドでは、BeeGFSロールは、このインベントリ構造に基づいて各ファイルおよびブロックノードに必要な設定を集約します。
|
|
各サービスのBeeGFS数値と文字列ノードIDは、グループ名に基づいて自動的に設定されます。したがって、グループ名を一意にするための一般的なAnsibleの要件に加えて、BeeGFSサービスを表すグループは、グループが表すBeeGFSサービスのタイプに一意の番号で終わる必要があります。たとえば、meta_01とstor_01は許可されますが、meta_01とmeta_01は許可されません。 |