Link Search Menu Expand Document
24-Feb-25

Ansibleの2階層データセンター

HPE Arubaは、お客様のニーズに合わせた効果的で柔軟なネットワーク自動化戦略の提供に取り組んでいます。HPE Aruba Networking Developer Hubは、Aruba CentralとAruba Fabric Composerが提供するワークフローベースの自動化に加えて、Ansibleを使用したCXスイッチ構成をサポートする包括的なツールを提供します。

目次

概要

Ansibleは、Red Hatが管理するオープンソースのオーケストレーションフレームワークです。 プロビジョニング、構成管理、アプリケーションの導入を自動化します。

Ansibleのプレイブックでは、SSH経由で複数のREST API呼び出しとCLIコマンドを使用してスイッチを構成するAOS-CX Ansible Collectionを使用して、CXスイッチを自動化します。

このガイドのAnsibleワークフローは、AOS-CX 2層データセンターのターンキー自動化を提供します。プロジェクトの圧縮されたバージョンは、次のgit cloneコマンドを使用してGithub repositoryからAnsibleコントロールマシンにダウンロードできます。

$ git clone https://github.com/aruba/aoscx-ansible-dcn-workflows.git
注：
AOS-CX Ansible Collectionの使用方法の詳細については、HPE ArubaのGetting Started with Ansible and AOS-CXガイドを参照してください。

Ansible Projectの前提条件

このプロジェクトは、Ansibleの作業知識を前提としています。Ansibleオートメーションを初めて使用する場合は、Developer HubでHPE ArubaのGetting Started with Ansible and AOS-CXガイドを参照してください。

Aruba CXの帯域外管理インターフェイスに割り当てられたIPアドレスにSSHで到達可能なネットワーク環境の自動化サーバーまたは仮想マシンが必要です。

AnsibleコントロールノードにはPython3.5+とAnsible 2.13.1+が必要で、AnsibleのInstalling Ansibleガイドを使用してインストールできます。

このプロジェクトにはHPE ArubaのAOS-CX Ansible Collectionが必要です。このコレクションは、HPE Ansibleデータセンターリポジトリのrequirements.ymlファイルを使用してansible-galaxyコマンドを実行することでインストールできます。

$ cd aoscx-ansible-dcn-workflows  
$ ansible-galaxy install -r requirements.yml

このプロジェクトには次のPythonライブラリが必要です。

  • jinja2 2.10+
  • paramiko 2.1.1+
  • pip 6.0+
  • リクエスト 2.2.0+
  • netaddr 0.7.5以降
  • pyaoscx 2.5.1+
  • openpyxl

Pythonライブラリは、HPE Ansibleデータセンターリポジトリのrequirements.txtファイルを使用してpipを実行することでインストールできます。

$ cd aoscx-ansible-dcn-workflows  
$ pip install -r requirements.txt

実行可能なプロジェクト構造

2層データセンタープロジェクトのAnsibleファイルは、Githubの一般的なデータセンターワークフローリポジトリで管理されています。リポジトリには、追加のプロジェクト用のファイルも含まれます。データセンターリポジトリ内でホストされているその他のワークフローの詳細については、 AOS-CX Data Center Automation with Ansible Developer Hub を参照してください。

2層データセンターのワークフローに必要なファイルは、次のリポジトリ構造にリストされています。

configs                                 #生成された構成のディレクトリ
|- sample_configs                       #すべてのワークフローの最終構成の例

templates                               #jinjaのテンプレートを保存する場所
|- 2TierV2                              # 2層DCN V2用のJinja2構成テンプレート
|  |- access.j2                         # Architecture IIバージョン2用アクセススイッチJinja2テンプレート
|  |- core.j2                           #アーキテクチャIIバージョン2用コアスイッチJinja2テンプレート

deploy_2tierv2_dcn.yml                  # Playbook for Architecture II version 2
inventory_2tierv2_dcn.yml               # Architecture IIバージョン2のインベントリ
requirements.txt                        #プロジェクトのPythonライブラリ要件
requirements.yml                        #プロジェクトのギャラクシー収集要件

このガイドの別の章で説明されているように、インベントリファイルとテンプレートファイルは、2層データセンターのプレイブックを実行するために重要です。

2層のデータセンター・トポロジー

Ansibleワークフローは、Aruba Central Two-Tier Data Centerガイドで使用されているのと同じサンプルトポロジを展開します。Aruba Centralガイドからの情報は、参照と読みやすさのためにここで繰り返されます。

HPE Aruba 2層データセンターは、中小規模のデータセンターの要件を満たしています。ネットワークの耐障害性を確保するため、MC-LAG(Multi-chassis Link Aggregation)は両方のスイッチ階層で使用されます。次の図は、この展開ガイドで構成されている物理トポロジと、コンポーネント間の関係をまとめたものです。

2層コア・レイヤー

コア層は、ダウンストリームアクセススイッチへの冗長レイヤ2接続を提供します。VSXのコアスイッチのペアは、各ダウンストリームラックにMC-LAGで構成されています。1つのラックのコア層からアクセス層へのすべてのリンクは、ラックが1台のスイッチで構成されている場合でも、VSXペアのアクセススイッチで構成されている場合でも、同じMC-LAGのメンバになります。MC-LAGは、ネットワークの耐障害性とロードバランシングを提供します。また、コアとアクセス層スイッチ間のループ回避メカニズムの必要性も軽減されます。

データセンターのレイヤ3サービスは、コアレイヤによって提供されます。VLANスイッチ仮想インターフェイス(SVI)はデータセンターサブネットを定義し、Aruba Active Gatewayはデータセンターホストに冗長IPゲートウェイを提供します。コア層は、アップストリーム外部ネットワークへの冗長IP接続も提供します。通常、ファイアウォールは、ポリシーを適用するためにデータセンターと外部ネットワークの間に配置されます。データセンターコアと外部ネットワーク間の冗長化戦略は、デバイスの機能や組織の要件によって異なります。このガイドでは、従来のアクティブ/パッシブ冗長ファイアウォールのペアを、MC-LAGを使用してコアスイッチのペアに接続します。

2層アクセス・レイヤー

アクセス層は、下位のデータセンターのホストへのレイヤ2接続を提供します。

単一のアクセススイッチがTop-of-Rack(ToR)の位置にある場合、アクセスレイヤは標準のLAGを使用してコアレイヤに接続します。1台のToRスイッチで標準のLAGを使用して物理リンクの冗長性を提供できますが、ファームウェアのアップグレードを実行したり、ToRスイッチに障害が発生したりすると、ホスト接続が失われます。

この導入例では、アクセスレイヤでVSXペアのToRスイッチを使用しています。これにより、直接接続されたホストに物理スイッチの冗長性が提供されます。このモデルでは、ToRスイッチの1つに障害が発生した場合や、ファームウェアのアップグレードが実行された場合でも、ホスト接続が中断されません。また、各アクセスレイヤスイッチは、冗長性、ロードバランシング、およびループ回避のためにMC-LAGを使用して各コアスイッチに接続されます。

Table of contents