0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

サーバ構築(冗長化)

Posted at

本なんか読んで勉強しているとよく「冗長化」って言葉がでてきますよね。
この冗長化というものについてすこしお話してみたいと思います。

☆多岐にわたるのでそれぞれの分野にお詳しいかたからのツッコミお待ちしております。

冗長化とは、多重化と言い換えられます。
できるだけシンプルにここでは2重化と考えてみてください。

サーバ製品には停止しない、停止してもすぐに再稼働できるという要素が求められます。
また障害によってのみならず、パッチ適用などの都合でサーバ停止/再起動などが求められることがあります。
もちろん業務アプリケーションのアップデート/修正なども停止を求められることがあるでしょう。
そのたびにすべての業務を停止することが許されない環境もたくさんあります。
365日24時間の稼働が求められるシステムというのはたくさんあるのです。

サーバやその他システムにはいろいろなものがあり、それらすべてにおいて冗長化を考える必要があります。


電源
PCやサーバは電気が無いと動きませんが、この電源を冗長しようと言うのですね。
サーバは通常、UPS(無停電電源装置)というおおきな電池につながっています。
そしてこのUPSが商用電源に刺さっていることが多いのですけど、さて、どこを冗長化すればいいでしょう。

まずは電源ユニットですね
サーバの内部にある「電源ユニットそのものを2つ搭載します。
これで電源ユニットがひとつ壊れてもサーバは動作を停止しません。
壊れた電源ユニットは多くの場合、サーバを停止することなく新品に入れ替えが可能です。

しかし、その2つの電源ユニットから出たコンセントが同じUPSにつながっていると、そのUPSが壊れたときに同時にアウトとなります。
よってUPSも2つ導入します。

UPSの電池の容量の計算はたいへんです。
どのサーバが最大でどれだけ電気を消費するのか。
そのUPSに接続されるサーバは何台なのか。
運用年数が長いと電池も劣化します。
通常は運用終了の年にどれだけの蓄電性能が残っているかを計算して、その上で接続するサーバを決定します。
このなかで「同じサーバから伸びてきた2系統の電源をどこに挿すのか」を設計する必要があります。
サーバの電源ユニットがアクティブ/スタンバイ方式(片方が壊れたら片方が動き出す)なのか、常時両方通電しているのかなども考慮する必要があります。

最後に、それらUPSが接続されている商用電源です。
これはさすがに施設側の考慮するべき内容ですが、場合によってはこちらで検討する必要があります。
一つは、非常用発電設備の導入です。
停電が発生してn分間復電しない場合に、自動/手動で自家発電設備を稼働し電気を供給します。
大体は石油で動く(らしい)ので、石油の備蓄量で発電可能時間が変わります。
このあたりは、きんでんさんとかそのあたりの業者さんが詳しいですね。

もう一つの方法はCVCFの導入です。
これは建物あるいはサーバルームそのものが巨大な電池に接続されている設備のことです。

商用の電源というものは少しだけですが電圧が上がったり下がったりすることがあります。
本来CVCFは、この電圧を一定にする用途で使われていたのですが、巨大な電池としての役割を担うようになりました。

このように設備まで絡めて考慮する必要があるのが電源の冗長化です。


ネットワーク(スイッチなどの経路)

次に、ネットワーク装置を考えてみましょう。
まずはコアスイッチ(ルータ)です。
これを多重化しておきます。

アクティブ/スタンバイ方式であったりアクティブ/アクティブ方式であったりしますが、
たとえば某大学のネットワークを参考に説明していきましょう。
同規模のサイト(校地=キャンパス)が2拠点あったとして、1拠点に1台ずつコアスイッチを設置し、おのおののトラフィックはおのおののコアスイッチが捌いているが障害を検知した場合即座に片側のスイッチが障害発生側の拠点のトラフィックを捌く、というような設定が考えられます。

次に冗長すべきは建屋スイッチと呼ばれるもので、これは建屋(校舎)ごとに存在するスイッチです。ここまでは建屋ごとのトラフィックをVLANで制御するためにL3が使われていることが多いです。これも2つ設置され、メッシュ状に配線されます。

さらに建屋スイッチからフロアスイッチ(階層ごと)に配送されるためここも冗長化されます。
この配下に教室スイッチがある場合はここもL3で構成されるでしょう。

さらに下位には教室をまとめる教室スイッチがあり、ここまで冗長した例はあまり記憶にありません。よってここまでのL3をすべて多重化しておく必要があります。
もちろん教室に設置されるのが(代替のきく)ただのPCであればそれで良いのですが、場合によっては先生の研究室に設置されたサーバであることもあり、一概に上記のとおりとは言い切れません。

最後に拠点間通信も2重化する必要があります。
そして、インターネットへの出口であるゲートウェイも2重化しているところもたくさんありました。

これに、在宅学生からの接続を受け入れるVPN装置であったりと、まだまだ考えることがあります。

自分で書いていて、気が遠くなってしまいましたので、次へいきましょう。


ネットワーク(その他アプライアンス機器)

上で書き漏れた部分になります。
どんな部分かといいますと、ファイアウォール装置や負荷分散装置、メールゲートウェイなどのアプライアンス機器ですね。

これらもすべて、上記と同じく2重化の対象となりますがだいたいコイツラは1台でも値段が高いので冗長化を諦められることもあります。


ネットワーク(サーバからスイッチ)

さて、ここまできてやっとサーバをスイッチに接続するのですけど、ここでも冗長性を考えないといけません。
まず、ネットワークケーブルってだいたいLANポートに差し込みますよね。
ケーブルが損傷したら通信ができなくなりますし、LANポートが壊れることだってあります。

そのため、LANポートを2つ搭載して、それぞれを「違う」スイッチに差し込みます。
そう、スイッチが冗長化されているからですね。

もうこれで完璧でしょうか?

いえ、まだあります。
上のLANポートというのはサーバのマザーボードについていたり、別途拡張スロットにネットワークカードを購入して取り付けてあり、1枚のボードに2個ないし4個のLANポートが着いているわけです。
このネットワークカードが壊れたら困りますね。せっかく2本のLANケーブルを刺したのに両方とも通信が止まります。
そこで、ネットワークカードを2枚刺します。
さらに、このカード上でも冗長のためLANポートを2つ(以上)使用します。
よって、一つの通信を冗長化するためにサーバからは最低4本のLANケーブルが伸びることになります。


ディスク
ディスクの冗長化については先日「Raid」の説明で述べました。
これはサーバの内部に内蔵されるHDDのRaidと、サーバ外のディスク装置が考えられます。
ディスク装置、ディスクアレイなどと言い方は様々ですが、例えばNECのiStorageなどの製品など巨大なディスクの集積装置(いっぱいHDDやSSDが刺さっているだけの装置)とディスクアレイコントローラ(いろんな言い方があります。)という制御装置が一体になったものがあります。
この装置のディスクもRaidで構成されており、障害発生時にはアクティブなまま交換ができる様になっっていますし、交換用のディスクがもともと刺さっており、障害検知時には自動で組み込まれるような機構も備えています。
さらにこのディスクアレイコントローラも冗長化される事例もありますね。


冷却ファン
サーバ内部の冷却ファンも可動部品なので壊れることを前提としています。
サーバに搭載される冷却ファンの多くは冗長化に対応しています。
どちらか一つが壊れてものこったファンでサーバ内の空気を流し続けることが可能です。


サーバ
さてここまできてやっとサーバの話をします。

たとえばWebサーバがあるとして、1台でリクエストを捌ききれない場合など、2台なり3台なりで冗長することがあります。
これには負荷分散の目的と障害にそなえた冗長化の2つの側面があります。

前者の場合にはアクティブ/アクティブ方式で負荷分散装置やDNSラウンドロビンなどの手法によって負荷を分散します。
後者の場合も同じではありますが、障害発生時に障害をおこしたサーバを除外する仕組みが必要です。
手動のこともあれば、自動でできることもあります。

また、クラスタという手法もあります。
多くはアクティブ/スタンバイ方式で片方が稼働系、もう片方は待機系として障害検知するとそれらが入れ替わるような方式ですね。

同じクラスタでも、例えばたくさんのサーバを並列に稼働させて処理させ、処理能力を高めるような方法もあります。
Googleのサーバはごくごく初期の頃、中古で買い集めたノートパソコン数台で並列処理させていたと聞きます。
並列処理として構築されたクラスタでも障害発生時には自動で障害を起こしたサーバを除外する仕組みがあります。


仮想化基盤
VMwareを例に取りますと、
ESXiというOSを入れて複数のサーバでクラスタを構成し、その上に仮想のサーバを構築します。
このクラスタのうち1台が障害を起こすと自動的に仮想マシンはほかのESXi上に移動(HA)して再起動します。このとき発生するダウンタイムはサーバの再起動にかかる時間とほぼ変わりません。
また、ESXiに対するパッチ適用などを実施する際には目的のESXi上で稼働するサーバを起動させたまま他のESXiへ移動(vMoption)する仕組みがあります。
このため設計時には、障害発生時に(通常は1台分)ESXiが1台いなくても他のESXiで全仮想サーバのリソースを賄える性能で設計します。


マザーボード(CPU/メモリ)
サーバの部品であるCPUやメモリ、果てはマザーボードそのものまで冗長しようという製品もあります。
フォールトトレランスサーバという名前でNECが出していますね。
マザーボードが内部に2枚存在し、構成するすべてのコンポーネントが2重化されています。
マザーボードが壊れようともCPUが壊れようともサーバは動作を停止することなく、またサーバをシャットダウンすることなく交換が可能となっています。
当然のことながら、めちゃめちゃ高額です。


「サーバやその他システムにはいろいろなものがあり、それらすべてにおいて冗長化を考える必要があります。」
と冒頭で述べたのですが、本当にすべてを冗長化させるとすろと膨大なコストが掛かることになります。
それらシステムのそれぞれの重大性によって冗長性をもたせるべきか、割愛すべきか判断を迫られることもあるでしょう。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?