Ansibleインベントリを作成します
ファイルノードとブロックノードの設定を定義するには、導入するBeeGFSファイルシステムを表すAnsibleインベントリを作成します。インベントリには、目的のBeeGFSファイルシステムを記述するホスト、グループ、および変数が含まれます。
手順1:すべてのビルディングブロックの構成を定義します
どの構成プロファイルを個別に適用できるかに関係なく、環境 のすべての構成ブロックを定義します。
-
導入環境に適したサブネットアドレッシング方式を選択します。に記載されている利点のため、 "ソフトウェアアーキテクチャ"単一のサブネットアドレッシング方式を使用することを推奨します。
-
Ansibleの制御ノードで、Ansibleのインベントリファイルとプレイブックファイルの格納に使用するディレクトリを特定します。
特に記載がないかぎり、この手順および以降の手順で作成するすべてのファイルとディレクトリは、このディレクトリを基準にして作成されます。
-
次のサブディレクトリを作成します。
「host_vars」
'group_vars'
「パッケージ」
手順2:個々のファイルノードとブロックノードの設定を定義する
環境 の個々のファイルノードおよび個々のビルディングブロックノードの構成を定義します。
-
「host_vars/`」で、「<hostname>.yml」という名前のBeeGFSファイルノードごとに次の内容のファイルを作成します。BeeGFSクラスタのIPおよび奇数で終わるホスト名と偶数で終わるホスト名には、内容に関する注意を払って入力してください。
最初は、ファイルノードのインターフェイス名が、ここに記載されている名前と一致しています(ib0やibs1f0など)。これらのカスタム名は、で設定します [手順4:すべてのファイルノードに適用する設定を定義する]。
ansible_host: “<MANAGEMENT_IP>” eseries_ipoib_interfaces: # Used to configure BeeGFS cluster IP addresses. - name: i1b address: 100.127.100. <NUMBER_FROM_HOSTNAME>/16 - name: i4b address: 100.127.100. <NUMBER_FROM_HOSTNAME>/16 beegfs_ha_cluster_node_ips: - <MANAGEMENT_IP> - <i1b_BEEGFS_CLUSTER_IP> - <i4b_BEEGFS_CLUSTER_IP> # NVMe over InfiniBand storage communication protocol information # For odd numbered file nodes (i.e., h01, h03, ..): eseries_nvme_ib_interfaces: - name: i1a address: 192.168.1.10/24 configure: true - name: i2a address: 192.168.3.10/24 configure: true - name: i3a address: 192.168.5.10/24 configure: true - name: i4a address: 192.168.7.10/24 configure: true # For even numbered file nodes (i.e., h02, h04, ..): # NVMe over InfiniBand storage communication protocol information eseries_nvme_ib_interfaces: - name: i1a address: 192.168.2.10/24 configure: true - name: i2a address: 192.168.4.10/24 configure: true - name: i3a address: 192.168.6.10/24 configure: true - name: i4a address: 192.168.8.10/24 configure: true
BeeGFSクラスタをすでに導入している場合は、静的に設定されたIPアドレス(NVMe/IBで使用するクラスタIPやIPなど)を追加または変更する前に、クラスタを停止する必要があります。これは、変更が適切に反映され、クラスタの処理が中断されないようにするために必要です。 -
「host_vars/`」で、「<hostname>.yml」という名前のBeeGFSブロックノードごとにファイルを作成し、次の内容を入力します。
ストレージアレイ名の末尾が奇数で偶数である場合は、内容に特に注意してください。
ブロックノードごとに1つのファイルを作成し、2つのコントローラ(通常はA)のうちの1つに「<MANAGEMENT _IP>」を指定します。
eseries_system_name: <STORAGE_ARRAY_NAME> eseries_system_api_url: https://<MANAGEMENT_IP>:8443/devmgr/v2/ eseries_initiator_protocol: nvme_ib # For odd numbered block nodes (i.e., a01, a03, ..): eseries_controller_nvme_ib_port: controller_a: - 192.168.1.101 - 192.168.2.101 - 192.168.1.100 - 192.168.2.100 controller_b: - 192.168.3.101 - 192.168.4.101 - 192.168.3.100 - 192.168.4.100 # For even numbered block nodes (i.e., a02, a04, ..): eseries_controller_nvme_ib_port: controller_a: - 192.168.5.101 - 192.168.6.101 - 192.168.5.100 - 192.168.6.100 controller_b: - 192.168.7.101 - 192.168.8.101 - 192.168.7.100 - 192.168.8.100
手順3:すべてのファイルノードとブロックノードに適用する設定を定義する
グループに対応するファイル名に'GROLE_vars'の下にあるホストのグループに共通する構成を定義できますこれにより、複数の場所で共有設定を繰り返す必要がなくなります。
ホストは複数のグループに含めることができ、実行時に、Ansibleは、変数の優先順位ルールに基づいて、特定のホストに適用する変数を選択します。(これらのルールの詳細については、Ansibleのドキュメントを参照してください "変数を使用します". )
ホストとグループの割り当ては、実際のAnsibleインベントリファイルに定義されます。このファイルは、この手順 の末尾に作成されます。
Ansibleでは、すべてのホストに適用する構成は「all」というグループで定義できます。次の内容で'ファイル'group_vars/all.yml'を作成します
ansible_python_interpreter: /usr/bin/python3 beegfs_ha_ntp_server_pools: # Modify the NTP server addressess if desired. - "pool 0.pool.ntp.org iburst maxsources 3" - "pool 1.pool.ntp.org iburst maxsources 3"
手順4:すべてのファイルノードに適用する設定を定義する
ファイル・ノードの共有構成は'ha_cluster'というグループで定義されますこのセクションの手順では'group_vars/ha_cluster.yml`ファイルに含める必要がある構成を構築します
-
ファイルの最上部で'ファイルノードのsudoユーザーとして使用するパスワードを含むデフォルトを定義します
### ha_cluster Ansible group inventory file. # Place all default/common variables for BeeGFS HA cluster resources below. ### Cluster node defaults ansible_ssh_user: root ansible_become_password: <PASSWORD> eseries_ipoib_default_hook_templates: - 99-multihoming.j2 # This is required for single subnet deployments, where static IPs containing multiple IB ports are in the same IPoIB subnet. i.e: cluster IPs, multirail, single subnet, etc. # If the following options are specified, then Ansible will automatically reboot nodes when necessary for changes to take effect: eseries_common_allow_host_reboot: true eseries_common_reboot_test_command: "! systemctl status eseries_nvme_ib.service || systemctl --state=exited | grep eseries_nvme_ib.service" eseries_ib_opensm_options: virt_enabled: "2" virt_max_ports_in_process: "0"
特に本番環境では、パスワードをプレーンテキストで保存しないでください。代わりにAnsible Vaultを使用します(を参照) "Ansible Vaultを使用したコンテンツの暗号化")または'--Ask -bece-pass`オプションを使用してプレイブックを作成します「Ansible」ssh_userがすでに「root」である場合は、オプションで「Ansibleの_ bece_password」を省略できます。 -
必要に応じて、ハイアベイラビリティ(HA)クラスタの名前を設定し、クラスタ内通信用のユーザを指定します。
プライベートIPアドレッシング方式を変更する場合は、デフォルトの「beegfs_ha_mgmtd_floating_ip」も更新する必要があります。これは、後でBeeGFS Managementリソースグループに設定する内容と一致している必要があります。
「beegfs_alert_email_list」を使用して、クラスタ・イベントのアラートを受信する電子メールを1つ以上指定します。
### Cluster information beegfs_ha_firewall_configure: True eseries_beegfs_ha_disable_selinux: True eseries_selinux_state: disabled # The following variables should be adjusted depending on the desired configuration: beegfs_ha_cluster_name: hacluster # BeeGFS HA cluster name. beegfs_ha_cluster_username: hacluster # BeeGFS HA cluster username. beegfs_ha_cluster_password: hapassword # BeeGFS HA cluster username's password. beegfs_ha_cluster_password_sha512_salt: randomSalt # BeeGFS HA cluster username's password salt. beegfs_ha_mgmtd_floating_ip: 100.127.101.0 # BeeGFS management service IP address. # Email Alerts Configuration beegfs_ha_enable_alerts: True beegfs_ha_alert_email_list: ["email@example.com"] # E-mail recipient list for notifications when BeeGFS HA resources change or fail. Often a distribution list for the team responsible for managing the cluster. beegfs_ha_alert_conf_ha_group_options: mydomain: “example.com” # The mydomain parameter specifies the local internet domain name. This is optional when the cluster nodes have fully qualified hostnames (i.e. host.example.com). # Adjusting the following parameters is optional: beegfs_ha_alert_timestamp_format: "%Y-%m-%d %H:%M:%S.%N" #%H:%M:%S.%N beegfs_ha_alert_verbosity: 3 # 1) high-level node activity # 3) high-level node activity + fencing action information + resources (filter on X-monitor) # 5) high-level node activity + fencing action information + resources
一見冗長に見えても'beegfs_ha_gmtd_floating_ip'は'1つのHAクラスタを超えてBeeGFSファイルシステムを拡張する場合に重要です以降のHAクラスタは、BeeGFS管理サービスを追加せずに導入され、最初のクラスタが提供する管理サービスをポイントします。 -
フェンシングエージェントを設定します。(詳細については、を参照してください "Red Hatハイアベイラビリティクラスタでフェンシングを設定します")。次の出力は、一般的なフェンシングエージェントの設定例を示しています。次のいずれかのオプションを選択します。
この手順では、次の点に注意してください。
-
フェンシングはデフォルトで有効になっていますが、フェンシングエージェント_を設定する必要があります。
-
'pcmk_host_map'または'pcmk_host_listに指定されている`<hostname>は'Ansibleインベントリ内のホスト名に対応している必要があります
-
フェンシングなしでBeeGFSクラスタを実行することは、特に本番環境ではサポートされません。これは、ブロックデバイスなどのリソース依存関係を含むBeeGFSサービスが問題 によってフェイルオーバーする際に、ファイルシステムの破損やその他の望ましくない動作や予期しない動作を引き起こす複数のノードによる同時アクセスのリスクがないことを主に保証するためです。フェンシングを無効にする必要がある場合は'BeeGFS HAロールの入門ガイドの一般的な注意事項を参照して'ha_cluster.ymlで'beegfs_cluster_crm_config_options[stonith -enabled "]をfalseに設定します
-
複数のノードレベルのフェンシングデバイスがあり、BeeGFS HAロールでは、Red Hat HAパッケージリポジトリで使用可能なフェンシングエージェントを設定できます。可能な場合は、無停電電源装置(UPS)またはラック配電装置(rPDU)を経由するフェンシングエージェントを使用します。 ベースボード管理コントローラ(BMC)などの一部のフェンシングエージェントや、サーバに組み込まれているその他のライトアウトデバイスは、特定の障害シナリオではフェンス要求に応答しない場合があります。
### Fencing configuration: # OPTION 1: To enable fencing using APC Power Distribution Units (PDUs): beegfs_ha_fencing_agents: fence_apc: - ipaddr: <PDU_IP_ADDRESS> login: <PDU_USERNAME> passwd: <PDU_PASSWORD> pcmk_host_map: "<HOSTNAME>:<PDU_PORT>,<PDU_PORT>;<HOSTNAME>:<PDU_PORT>,<PDU_PORT>" # OPTION 2: To enable fencing using the Redfish APIs provided by the Lenovo XCC (and other BMCs): redfish: &redfish username: <BMC_USERNAME> password: <BMC_PASSWORD> ssl_insecure: 1 # If a valid SSL certificate is not available specify “1”. beegfs_ha_fencing_agents: fence_redfish: - pcmk_host_list: <HOSTNAME> ip: <BMC_IP> <<: *redfish - pcmk_host_list: <HOSTNAME> ip: <BMC_IP> <<: *redfish # For details on configuring other fencing agents see https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/9/html/configuring_and_managing_high_availability_clusters/assembly_configuring-fencing-configuring-and-managing-high-availability-clusters.
-
-
Linux OSで推奨されるパフォーマンス調整を有効にします。
多くのユーザはパフォーマンスパラメータのデフォルト設定を確認できますが、特定のワークロードのデフォルト設定は必要に応じて変更できます。そのため、これらの推奨事項はBeeGFSロールに含まれますが、デフォルトでは有効になっていないため、ユーザーはファイルシステムに適用された調整を認識できません。
パフォーマンス・チューニングを有効にするには'次のように指定
### Performance Configuration: beegfs_ha_enable_performance_tuning: True
-
(オプション)Linux OSのパフォーマンス調整パラメータを必要に応じて調整できます。
調整可能なチューニングパラメータの包括的なリストについては、のBeeGFS HAロールの「Performance Tuning Defaults」セクションを参照してください "EシリーズBeeGFS GitHubサイト"。 デフォルト値は、このファイルのクラスタ内のすべてのノードまたは個 々 のノードのファイルで上書きできます
host_vars
。 -
ブロックノードとファイルノード間の200GB/HDR接続を完全に許可するには、NVIDIA Open Fabrics Enterprise Distribution(MLNX_OFED)のOpen Subnet Manager(OpenSM)パッケージを使用します。に記載されているMLNX_OFEDバージョンは "ファイルノードの要件" 、推奨されるOpenSMパッケージにバンドルされています。Ansibleを使用した導入もサポートされていますが、最初にすべてのファイルノードにMLNX_OFEDドライバをインストールする必要があります。
-
'group_vars/ha_cluster.yml'の次のパラメータを入力します(必要に応じてパッケージを調整します)
### OpenSM package and configuration information eseries_ib_opensm_options: virt_enabled: "2" virt_max_ports_in_process: "0"
-
-
論理InfiniBandポート識別子と基盤となるPCIeデバイスとのマッピングが一貫して行われるように'udev'ルールを設定します
udevルールは'BeeGFSファイル・ノードとして使用される各サーバ・プラットフォームのPCIeトポロジーに固有のものである必要があります
検証済みファイルノードには、次の値を使用します。
### Ensure Consistent Logical IB Port Numbering # OPTION 1: Lenovo SR665 V3 PCIe address-to-logical IB port mapping: eseries_ipoib_udev_rules: "0000:01:00.0": i1a "0000:01:00.1": i1b "0000:41:00.0": i2a "0000:41:00.1": i2b "0000:81:00.0": i3a "0000:81:00.1": i3b "0000:a1:00.0": i4a "0000:a1:00.1": i4b # OPTION 2: Lenovo SR665 PCIe address-to-logical IB port mapping: eseries_ipoib_udev_rules: "0000:41:00.0": i1a "0000:41:00.1": i1b "0000:01:00.0": i2a "0000:01:00.1": i2b "0000:a1:00.0": i3a "0000:a1:00.1": i3b "0000:81:00.0": i4a "0000:81:00.1": i4b
-
(オプション)メタデータターゲット選択アルゴリズムを更新します。
beegfs_ha_beegfs_meta_conf_ha_group_options: tuneTargetChooser: randomrobin
検証テストでは'通常'randomrobinを使用して'パフォーマンス・ベンチマーク中にテスト・ファイルがすべてのBeeGFSストレージ・ターゲットに均等に分散されるようにしました(ベンチマークの詳細については'BeeGFSのサイトを参照してください "BeeGFSシステムのベンチマーク")。実際に使用されている場合は、原因 の番号が小さいターゲットが、番号の大きいターゲットよりも早くいっぱいになる可能性があります。「randomrobin」を省略し、デフォルトの「randomized」値を使用するだけで、利用可能なすべてのターゲットを利用しながら、優れたパフォーマンスを提供できるようになりました。
手順5:共通ブロックノードの設定を定義する
ブロック・ノードの共有構成は'eseries_storage_systems'というグループで定義されますこのセクションの手順では'group_vars/eseries_storage_systems.yml`ファイルに含める必要がある構成を構築します
-
Ansible接続をローカルに設定し、システムパスワードを指定して、SSL証明書を検証するかどうかを指定します。(通常、AnsibleはSSHを使用して管理対象ホストに接続しますが、NetApp Eシリーズストレージシステムがブロックノードとして使用されている場合、モジュールはREST APIを使用して通信します)。 ファイルの上部に、次の情報を追加します。
### eseries_storage_systems Ansible group inventory file. # Place all default/common variables for NetApp E-Series Storage Systems here: ansible_connection: local eseries_system_password: <PASSWORD> eseries_validate_certs: false
プレーンテキストでパスワードを一覧表示することは推奨されません。--extra-bvarsを使用してAnsibleを実行するときに'Ansibleボールトを使用するか'eseries_system_password'を提供します -
最適なパフォーマンスを確保するには、に記載されているバージョンをブロックノードにインストールします "技術要件"。
対応するファイルをからダウンロードします "ネットアップサポートサイト"。これらを手動でアップグレードするか'Ansibleコントロール・ノードのパッケージ/ディレクトリに含めてから'eseries_storage_systemesyml'に以下のパラメータを入力して'Ansibleを使用してアップグレードできます
# Firmware, NVSRAM, and Drive Firmware (modify the filenames as needed): eseries_firmware_firmware: "packages/RCB_11.80GA_6000_64cc0ee3.dlp" eseries_firmware_nvsram: "packages/N6000-880834-D08.dlp"
-
から、ブロックノードに取り付けられているドライブで使用可能な最新のドライブファームウェアをダウンロードしてインストールし "ネットアップサポートサイト"ます。手動でアップグレードするか、Ansible制御ノードのディレクトリに追加してから、の次のパラメータを入力してAnsibleを使用してアップグレードできます
packages/
eseries_storage_systems.yml
。eseries_drive_firmware_firmware_list: - "packages/<FILENAME>.dlp" eseries_drive_firmware_upgrade_drives_online: true
eseries_drive_firmware_upgrade_drivesonlineを'false'に設定すると'アップグレードが高速化されますが'BeeGFSが導入されるまでは実行しないでくださいこれは、アプリケーションエラーを回避するために、アップグレード前にドライブへのすべてのI/Oを停止する必要があるためです。ボリュームを構成する前にオンライン・ドライブ・ファームウェア・アップグレードを実行しても問題が発生しないようにするには'この値を常にtrueに設定することを推奨します -
パフォーマンスを最適化するには、グローバル構成に対して次の変更を行います。
# Global Configuration Defaults eseries_system_cache_block_size: 32768 eseries_system_cache_flush_threshold: 80 eseries_system_default_host_type: linux dm-mp eseries_system_autoload_balance: disabled eseries_system_host_connectivity_reporting: disabled eseries_system_controller_shelf_id: 99 # Required.
-
ボリュームのプロビジョニングと動作を最適化するには、次のパラメータを指定します。
# Storage Provisioning Defaults eseries_volume_size_unit: pct eseries_volume_read_cache_enable: true eseries_volume_read_ahead_enable: false eseries_volume_write_cache_enable: true eseries_volume_write_cache_mirror_enable: true eseries_volume_cache_without_batteries: false eseries_storage_pool_usable_drives: "99:0,99:23,99:1,99:22,99:2,99:21,99:3,99:20,99:4,99:19,99:5,99:18,99:6,99:17,99:7,99:16,99:8,99:15,99:9,99:14,99:10,99:13,99:11,99:12"
「eseries_storage_pool_usable_drives」に指定する値はNetApp EF600ブロックノードに固有であり、新しいボリュームグループにドライブを割り当てる順序を制御します。この順序により、各グループへのI/Oがバックエンドドライブチャネル間で均等に分散されます。