KADOKAWA Connected様

ー　今回のプロジェクトについてお聞かせください。

ところざわサクラタウンのネットワークを構成する大量の機器を構築するという単純なプロジェクトではあったのですが、背景としては、ところざわサクラタウン開業スケジュールに間に合わせるため、建設後の建物内に入場可能になるタイミングに合わせてネットワークを構築する必要があり、それまでに全ての機器の初期設定を完了した状態で用意しなければならない状況でした。全ての機器が広大な敷地内で建設中の建物のどこに設置されるか未確定な状況でもありましたので、現場で全ての機器を1台ずつコンソール接続で設定するということは、スケジュールも含め現実的ではありませんでした。
このような場合にZTPはとても有効だと思うのですが、今回導入の機器ベンダーのZTPについては実績がなく、DHCPサーバー、TFTPサーバー以外のコンポーネントも必要で、かつ、それらを現地でゼロベースの状態から導入するにはリソース不足のため、今回ZTPによる構築リスクは非常に高いと判断しました。

—　SmartCSを検討した背景をお聞かせください。

前述のとおり、最悪の場合は機器を1台ずつコンソールで設定しなければならないと考えていましたが、コンソールといえば、元々導入していたSmartCS自体の構築をAnsibleで自動化したいと考えていた際に「コンソールサーバー経由でAnsibleを実行できる」というセイコーソリューションズ様のプレスリリースを見たことを思い出しました。もしかすると今回のユースケースには当てはまるのではないかと思い、すぐにSmartCSとAnsibleを組み合わせてスイッチの初期設定を自動化できるかどうか検討を始めることにしました。

—　SmartCSを採用された理由についてお聞かせください。

とにかく実際に触ってみないことには判断ができないと思いましたので、SmartCSのAnsibleモジュールを提供いただき動作検証を開始しました。SmartCSのセットアップと簡単な AnsibleのPlaybookを用意しただけで、特に問題なく思いのほかすぐに動作することが確認できました。 SmartCSと対象の機器さえあれば事前に構築が完了できるということで、スケジュールを圧縮することも可能になりますし、現地でぶっつけ本番のZTP失敗リスクもなくせるという点でも要件を満たしているため、採用を即決しました。

—　導入でよかった点をお聞かせください。

SmartCSとAnsibleを組み合わせた方式の導入で良かった点は、機器やベンダー毎に方式や手順が異なったり、DHCPサーバーや TFTPサーバー、専用のソフトウェアコンポーネント等が必要だったり、それなりの環境を用意する必要があるという部分の課題を全てクリアできているところです。
一番のポイントについては、Ansible非対応の機器でもコンソールに繋がってさえいれば自動化を実現できるというところで、今後の構築手段について選択性が広がったと感じます。
Ansibleは構成管理ツールとしても自動化の共通言語としても一般化されていますので、個人的にはZTPより学習コストも低く導入しやすいと感じました。 またシステムソフトウェアのアップデートなど、初期設定後に必要となるタスクを統一することにより作業を効率化できるので、今回のようなケースには最適のソリューションです。

—　今後の期待をお聞かせください。

コンソールログの保管、電源・LANの冗長化や設定投入のシンプルさなど、「NS-2250」の機能面は満足しています。ただ、LANの冗長設定（ボンディング）を使用しているのですが、LAN1とLAN2のどちらが主系として動作しているのか、筐体のLEDなどで分かるようになるとメンテナンスがしやすくなります。変換コネクターの小型化と併せて、ぜひ検討をお願いします。
踏み台サーバーとして導入を検討しているアクセスゲートウェイ「SmartGS」との組み合わせも考えていきたいと思いますので、引き続き手厚いサポートをお願いします。

本日はお忙しい中、貴重なお話をありがとうございました。

※社名および記載されている内容は取材当時のものです。現在の情報とは異なる可能性がありますのでご了承ください。
※記載されている社名、製品名等は各社の商標または登録商標です。