サーバーラックを導入して1年が経ちました【西田の戯言。】

ふと、師走のこの時期、1年前何してたかなぁとか思ってたら、ちょうど去年の今日、サーバーラックを導入していました。今回はその話をしようと思います。今回はかなりブログです。

サーバーラック

通信研究会では1年前、42Uのサーバーラックを導入しました。導入理由は、ここ1年で急増したラックサーバーおよびネットワーク機器を集約し、運用・管理を容易にすること。まあ、この理由は建前で、本当の理由としては「見た目が良くてかっこいいから」。

これまで通信研究会では、部室内の複数箇所にサーバーが分散して設置されており、機器が増えるにつれて配線も複雑化し、どのサーバーがどのスイッチに接続されているのかを把握するだけでも手間がかかる状況でした。特に、試行錯誤しながら色々遊んでいたこともあり、把握できている部分と、把握できていない部分と。ややこしいし複雑。まあ無計画に拡張していったがゆえの結末なのですが。

そこでサーバーラックを導入。段階的にサーバーの集約作業を進め、現時点では通信研究会に存在するほぼすべてのラックサーバーをラック内に収容しています。物理的な設置場所を統一したことで、電源系統・ネットワーク系統の整理が進み、機器構成を俯瞰しやすくなりました。

特にネットワーク面での改善は大きく、それまで雑多に敷設されていたケーブル類は、ラック内のスイッチを中心とした構成へと再構成され、整理されました。更に、サーバーがラックに集約されたことで、ネットワークの構成把握やトラブルシュートが容易になっています。どうもこういうのをトポロジの簡素化みたいな感じで表現するみたいですが、難しい言葉はわからないです。

結果として、単に機器を「まとめた」だけで、ネットワーク全体が簡素化される形となりました。

また、ラック化によって部員それぞれの運用面の意識にも変化がありました。サーバーの増設や入れ替えを前提としたスペース管理など、インフラとしての設計を考える機会が増えています。これまでは場当たり的になりがちだった部分も、ある程度「構造を持った運用」に移行できたのは評価できそう。

さらにさらに、導入したタイミングが年末だったということもあり、サーバー集約は部室の大掃除という意味でも効果的でした。部室の模様替えもできましたし。

結果として、この42Uサーバーラックは、通信研究会の「顔」となりました。私が通研のHPのトップの画像にサーバーラックを選んだのも、見た目のインパクトでしたからね。

課題

物理面でサーバーが集約できたのは非常に良いことです。しかし、別の課題も存在しています。ソフトウェア面です。

現在、通信研究会では、ネットワーク運用に関して、部員自身のノウハウや知識に依存しているという大きな問題があります。これはすなわち、運用面で明文化されたルールが存在しないということです。

部員たちはルールとして「ポート開放をしないこと」のみを決まりとしています。これは、セキュリティを担保するための取り組みですが、部内ネットワークにおいてこれ以外のルールがありません。結果、いくつかの問題が発生しています。

まず一つが、無秩序に確保された固定IPたち。通信研究会では、IPアドレスの固定について明確なルールがなく、各々好きなIPアドレスを固定しています。部内ネットワークのローカルIPアドレスはクラスA(10.0.0.0)であるため、1,677万7,214のIPアドレスが使用可能です。

しかし、やはり192.168.x.xで慣れた部員たちは、10.0.0.xという番号を取りがちです。結果、1670万以上あるIPアドレスのリソースはその殆どを持て余し、10.0.0.1~10.0.0.255を取り合っている状況。しかも無秩序に。

もちろんこうなってくると問題になるのがIPアドレスの衝突です。基本的に、稼働状態のホスト同士でIPアドレスの衝突が発生した場合、pingが導通しないのですぐに気づきます。他方で、元々そのIPアドレスを持っていたデバイスがメンテナンスやなんやでネットワークと切断されていた時、新しいホストが同じIPアドレスを設定してしまうとまあ大変。事故ります。


IPアドレスの取得状況をここ数日調査して、部員の意識としてわかったのが以下のようなポイントです。

  • IPアドレスを決めるのが面倒なので、DHCPから降ってきたIPアドレスをそのまま固定している
  • わかりやすいので、キリの良い番号から連番で付番している
  • 連番で取得しようとしたら、別のホストが使っていたので飛び地でIPアドレスを取得している

こうなるともう無秩序です。

こういうホストが不特定多数となってしまうような運用においては、IPアドレスの割当はDHCPに任せるのが定石かと思いますが、そうしてしまうと活動の関係上、SSH等で決め打ちでIPアドレスを決めたいということも多く困ります。

問題を「IPアドレスの衝突を回避したい」ということに絞れば、解決策はDHCPですが、IPアドレスを固定したいという運用上の要求がどうしても矛盾してしまうわけです。

こうした問題をどうにかソフトウェアで解決する知恵を共有できないかと、最近私は考えているのです。とりあえず、Googleのスプシで今は管理してもらってます。

まあ、部員たちもうすぐネットワーク更新を含めた大規模な再構成を予定しているようですしそのタイミングでルールぎめをしっかりとすることは重要ですね。

ルールをなんとなーーーーーく決めることができたら、またここで共有します。ほなまた。


この記事を書いた人

西田(総合情報学部 情報学科 2021年入学)

通信研究会OB。当ホームページの保守運用を支援しています。組み込み系のソフトウェアエンジニア。応用情報技術者・修習技術者。

関連エントリ

blog.2-net.jp

blog.2-net.jp