Sheepdog の構築
先日、会社に既に使わなくなった古いサーバーが何台かあったので、遊びがてらSheepdogを構築してみました。Sheepdog とはKVM 用の分散ストレージで、複数台の機器を一つのストレージ領域として利用できる、今はやり？の技術です。 この分野はあまり詳しくはないのですが、まあVMware に少し似た感じのものなのかなぁと思いながら構築してみました。 構築したCPUスペックはCore2Duo のT8100 のサーバー10台で構築しました。 ブログで細かく説明することは難しいのですが、使い勝手は普通というか良くできています。 ただ、いくつか問題点も多いのが現状です。 まず、現在のバージョンがまだベータ版あること。これは何を意味するかというと、正式版ではないためバグも沢山あるということです。 実際にバグは多いです。 それと、複数台のサーバーを束ねるのでその分CPU スペックも束ねられてパワーアップするのかと思えば、いくら10台20台サーバーを束ねようと、T8100 には変わりはないということ。 なので、大規模な運用を想定している場合は、予めそれなりのスペックのサーバーで構築する必要があります。 あとはオープンソースソフトなので、何かあっても誰も助けてくれません（泣） コミュニティーレベルでの解決になります。 商用やエンタープライズ用途だと、システム構築やソフトウェア開発に相当熟知した人でないと正直厳しいかと・・・ まあ、社内環境レベルなら使えるとは思います。 正式版がこれからなので、今後の発展に期待といったレベルではないかと思います。 昨年、某ホスティング会社で起こったデータが消失してしまう障害のようになってしまうと、取り返しがつかない事態に発展してしまうので、何事も慎重になりがちです。
SSD でサーバ構築【その後】
SSD でサーバーを稼働させて約1ヶ月が経過しましたので、実際の使用感についてお話しします。
今回私が構築したOS はCentOS6.3 で、CPU がIvy Bridge のIntel E3-1270v2 です。
そして搭載したSSD はIntel 520シリーズの120GB です。
6Gbps 対応で価格、性能共にバランスが取れていると思い、購入しました。
SSD にはMLC タイプとSLC タイプが存在し、大まかに分けると、MLC がコンシューマーで、SLC がエンタープライズ（サーバー用途など）に位置付けられていますが、よっぽど書込みが多いシステムじゃない限り、MLC でも問題はないと、勝手に思っています。
なので、自己責任ですね。
しかも、Intel520 シリーズは5年保証なので、そこにも魅力を感じました。
問題の動作とはいうと、至って普通で何も問題なく稼働しているというか、HDD に比べて読み書きの速度は飛躍的に向上しました。（当然の結果です！）
SSD の書き込み制限などを考えると、SSD が壊れる前に、電源などの他のパーツが先に故障するのではないかと思ったりもしていまます。サーバーの冗長化を考える前に、いかにサーバー自体の故障率を下げるかを考える必要があるので、SSD にすることで、HDD よりかは、故障率が下がると期待しています。
あと、CentOS6 でTrim を有効にするには、discard を指定する必要があります。
デフォルトでは、discard は指定されていないので、そのまま使用すると、Trim が対応してくれません。
CentOS6 でSSD を使う方は、くれぐれもご注意を！
HDD もこれからは、本格的に4K の時代に突入しますが、HDD 自体の性能も頭打ちになってきているようですし、サーバーでもSSD を搭載するケースが増えてくると予想しています。通常はSSDで、大容量はHDD でという運用になってくるのではと思っています。
4K HDD にSSD。サーバーも新時代に突入ですね！
SSD でサーバ構築
前回の記事でSSD について少し触れましたが、SSD を搭載した機器でサーバを構築したので、少しレポートします。
SSD とはSolid State Drive の略で、メモリの技術を応用しできたデバイスで、従来のHDD のようにディスクやモーターを持たないため、消費電力も少なく、機械的に駆動する部品が無いため衝撃にも強いとされています。
しかも、読み書きもHDD と比べて速く、I/O 周りの性能向上も期待できます。
正にサーバ向きと思った方も多いと思いますが、いくつか注意点もあります。
まず1点は、長年記憶媒体として実績のあるHDD と比べてまだまだ、歴史が浅いため、どういった問題が起こり得るか、まだまだ謎が多い。
特に、サーバでの運用実績は欠しいですからね。
Intel の320シリーズでは8MB病という問題が発見され、FW で改善はされましたが、この先もこういったFW の問題による不具合は度々報告されると思われます。
そしてもう1点は、Trim コマンドという仕組みが存在することがあげられます。
Trim コマンドとは簡単にいうと、SSD の書き換え回数が多くなっても性能劣化を抑えるもので、Trim に対応していないOS やM/B だと、稼働年数が経つにつれ性能劣化するといわれております。メーカにもよりますが、新品時から性能が半分ほどに落ちるものも存在するようです。
でここで問題なのが、サーバで運用する場合にハードウェアRAID で構成する方も多いと思いますが、大手RAIDカードメーカーでは、まだTrim に対応していないところが多いのです。
というかほとんどが対応していません。
なので、SSD でRAID を構築する場合はTrim に対応していないことを予め知っているうえで、運用する必要があります。
とはいえ、HDD よりも壊れにくく、転送速度なども速いので、サーバに最適な記憶媒体だと思っています。
次回は実際のサーバとしての稼働状態などについて話したいと思います。
中国との関係
最近、尖閣諸島の問題で中国との関係がギクシャクしていて、中国では大規模な反日デモも起こっており、問題の終息が未だ見えません。
中国とサーバー。一見何の関係も無いように思えますが、私が勤務する職場では切っても切れない関係にあるのです。
サーバーなどハードウェアに関しては、日本国内で調達し、OSインストールや簡単な設定等は私たちが行っています。
OS上で動作する各種プログラムなどは、手間がかかる複雑なものになると、中国のプログラマーに外注し作ってもらっています。
その他、自社製品のソフトウェアなども中国のプログラマーに外注をしています。
なぜ、中国なのか？
それは、単に日本と比べて人件費が安いから！
各種工業製品も人件費が安いという理由で外資の工場が次々と中国で増えてきましたが、ソフトウェアなどプログラマーを必要とする業種についても、中国に委託するケースは、増えていると思います。
私たちが頼りにしている中国人の方は、すごく良い人ですし、もちろん反日デモなどにも参加はしておりませんが、各地で起こっている暴動を見ると、心が痛くなると言っていました。
今も現在進行形で、中国のプログラマーに仕事を依頼していますが、お互いなぜかこれまでとは違った雰囲気になっているようにも感じます。
一刻も早く自体が終息してほしいものです。
そういえば最近、自社のサーバーをSSD で構築してみました。
デスクトップPCやノートPCなどのコンシューマー製品ではSSD は普及してきましたが、サーバーの場合は書き込み制限など、耐久性に未知数なところがあるので、なかなか普及していないのが現状です。
SSD で構築したサーバーのレポートは後日報告します。
冗長構成の落とし穴
先日、某クラウドサービスで大規模な障害が発生したことは、皆さんご存知だと思います。
一瞬にして数千社のデータが消えてしまうなんて・・・本当に恐ろしいことで、他人ごとではいられませんでした。
今回の障害の原因は、セキュリティ脆弱性対策の更新プログラムのミスだったそうだが、加えて本番環境と、バックアップ環境を同時に脆弱性対策を適用してしまったので、問題が発生しても、元に戻すことができなかったようだ。
本来なら、インフラのシステムアップデートともなると、本番環境でアップデートしても、バックアップ環境はしばらくそのままにしておいて、本番環境に問題がないことを確認してから、バックアップ環境もアップデートするようにやるものだが、ではなぜ本件では同時にアップデートしてしまったのか？
過去に別の問題が発生した時に、バックアップに切り替えたが、脆弱性対策をしていない状態で稼働し続けたことがあったらしく、それ以降今回のような対応になったのだとか。
クラウドもある意味、サーバーの冗長構成でもあるのだが、今回のように、ハードによる障害ではなく、ソフト側の障害であった場合は、いくらサーバーを冗長構成にしていても、防げるものではない。
そうなると、本番環境の冗長構成にあたる、バックアップ環境が重要になってくるのだが、運用方法によっては、今回の障害のように、何も役に立たないことだってあることも、肝に銘じなければならない。
沢山サーバーを並べても、どんな高価なサーバーであっても、結局は運用次第。
サーバーの冗長構成・・・う～ん、奥が深い！
社内インフラの障害対応
先日、会社のメールが突然受信できなくなった。
遠隔からメールサーバーにPING を飛ばしてみたが、疎通せず、遠隔ログインも行えない。
現地に行って、機器を確認してみると、どのLED も光っておらず完全に停止していた。
一旦サーバーを回収し、調査したところ、電源の故障だった。
このサーバーは導入してから、既に5年を経過しておりそろそろ何かしらの不具合が発生してもおかしくはないと思っていたが、突然起こると少々テンぱってしまうものである。
たまたま電源の保守部材を所持していたので、電源を交換して障害自体は復旧した。
上司には早速このサーバーのリプレイスをした方が良いことを伝え、承諾はしてもらいました。
私の会社ではサービスのサポートをメールで受けているが、最悪少しぐらいなら受信ができなくても直接業務に支障をきたすわけではない（もちろん半日以上使えないとなると問題だが）
これが、メールが会社の業績に大きく関係してくる会社になると、数分間メールが受信できなくなるだけで、億単位で売り上げに影響するところもあるという。
そういった会社になると、サーバーへの冗長化構成に対するコストは惜しまないであろう。
他にもサーバーの用途は色々あるが、その会社に対する可用性を十分に分析し、冗長構成が必要な用途と必要でない用途を明確に分けて必要なところにはコストは惜しまず、そうでないところは“ほどほど”にといった運用をしているのが通例ではないだろうかと思っていたが、そうでもないようである。
某大手上場企業に勤める私の友人が言っていたのを思い出す。
友人の企業は名前を出せば誰もが分かる、大企業だが、サービスインフラに関しては確かに最悪の事態を考えてコストをかけているそうだが、社内インフラに関しては経理が結構渋いようで、冗長構成を図っているものもあまりないようだ。
大企業でさえこの程度なのかと思ったことがある。
とりあえず、今回は大惨事にならなくてほんとに良かった！
さまざまな冗長構成
サーバーの冗長構成といっても、単に2台のサーバーを準備しそれぞれをマスター機・スレーブ機という構成だけが冗長構成ではない。
昨今ではクラウドコンピューティングというシステムが話題になっているが、あれの構成もある意味冗長構成になっているといえる。
クラウドコンピューティングのシステムは複数台の機器をEucalyptus などのクラウド基盤ソフトウェアで束ねたりすることで、万が一1台のサーバーが故障したとしても、サービスには影響しないように高可用性を保っている。
※クラウド基盤ソフトにバグなどがあれば、最悪全停止などもありえるが・・・
また、VMware やXenServer、Hyper-V などを使って、仮想化環境を構築している人も多いと思うが、これらも複数台の機器を束ねたりし統合管理しているので、クラウドコンピューティング同様に高可用性を保っていることを考えれば、冗長構成といえるだろう。
自分自身、社内インフラの運用管理を行っていて、数多くのサーバーを管理しているが、結局のところ100% 安心という構成は存在しないと思っている。
より100% に近づけるためにさまざまな構成を組んだりするわけだが、そのひとつが冗長構成といえるだろう。
ただ、冗長構成を制御しているソフトウェアの潜在的なバグなどの影響で、ある一定条件だと、マイグレーションが走らないとか、もしも複数台の機器で同時に障害が発生したら・・・など、考えたらきりがないのだが、不安はつきないし、より万全にするとそれだけコストも上積みされてくる。
目まぐるしく変化する時代の中で、さまざまな技術やサービスなどが生まれてきて、可用性を高める手段の選択肢も増えてはきたが、要はサーバーが壊れなければ良いだけなのにと考えてしまうことがあるが、こればっかりはしょうがないか・・・
冗長化は必要なのか？
サーバーの管理をしている方に会うと、サーバーの冗長化、すなわち耐障害性に対してどのように取り組んでいるのか？ついつい聞いてしまう。
サーバーといっても、使用用途により重要度が変わってくるので、障害に対する対策もそれぞれ違ってくる。
中には長時間停止しても良いという条件下で使用している場合は、特に冗長化などをする必要がないものも存在するかもしれない（そもそもサーバーと呼んで良いのか？・・・）
私の会社の社内インフラは、基幹系のシステムは基本ハードウェアの冗長化をとっているが、あまり業務に支障を来さないシステムはハードウェアの冗長化はとっていない。
この、業務に支障を来すか来さないかを判断するのも、また難しいものである。
どうせなら、全て冗長化すれば良いのでは？と考えてしまうが、冗長化するにもそれなりのコストがかかってしまう。
結局は費用対効果がどれだけあるのかを検証し、ケースバイケースで冗長化したりしなかったりとしているのが現状だ。
ただ、冗長化をしていないサーバーでもサーバー丸ごと一式を冗長化ではなく、HDD や電源など比較的故障しやすいといわれる部材を冗長化することで、少しは耐障害性も向上すると考えている。HDD の冗長化？とはRAID構成という意味だけどね。
もちろん電源もHDDもホットスワップ対応のサーバーを選定している。
RAIDカードを搭載すると部材点数が多くなるので、理論上、故障率も上がってしまうが、
非RAID構成の場合だと、HDD 故障で即システム（OS）の入れ替えが発生しかねないが、RAID構成の場合だと片側のHDD が故障したぐらいで、システムが故障することまでは
あまり考えられない。ただしHDDが2本同時に故障してしまうとアウトだけどね。
書き疲れたので、続きは次回にします。