Monthly Archives: 6月 2012

Red Hat 6.3 リリース(2012年6月21日)

先日、レッドハット6.3がリリースされた模様。
レッドハット、「Red Hat Enterprise Linux 6.3」をリリース
Red Hat、RHEL 6.3 を公開―仮想化スケーラビリティの新時代を告げる
リリース内容を確認してみる。

 

 

 

1. スケーラビリティ向上

スケーラビリティも大幅に向上している。1仮想マシンあたりの最大仮想CPU(vCPU)数は、これまでの64個から160個へと拡張された。「これはVMware ESX 5.0の最大32 vCPUと比べて驚くべきスケーラビリティだ」(Red Hat発表文より)。同様に、1仮想マシンあたりの最大メモリ容量も、512GBから2TBへと拡張されている。

1仮想マシンで必要なCPUやメモリをはるかに超えた気がする。
そこそこの規模のDBサーバであっても、すべてのデータをメモリに載せる事ができる規模だな。

 

2. 可用性向上

可用性という点では、Red Hat は「Dynamic CPU Hotplug」も提供を開始する。これは仮想ゲストが稼働状態のときに、仮想 CPU を追加できるテクノロジーだ。

「以前であれば、CPU の追加には一瞬とはいえ仮想ゲストをシャットダウンする必要があった。だが 6.3 では稼働させたままで拡張が可能だ。同様に、仮想ゲスト稼働時にディスクボリュームサイズを変更することも可能になった」

これも良いアップデート。サービスレベルが向上するな。
そのほかにも色々な部分が改善された模様。

 

3. CentOS6.3について

Redhatがリリースされるといつも期待してしまうCentOS。
CentOS6.2はRedhat6.2のリリース後2週間での対応となったが、
CentOS6.3はいつごろリリースされるのだろうか。楽しみだ。

 

 


ファーストサーバの障害ついて勝手に考えてみる。

ファストサーバの障害についての中間報告を読み、勝手にいろいろ考えてみた。データ消失とセキュリティ事故は絶対避けなければならない障害なので、日々のルーティーン作業・様々な障害対応・依頼対応で忙殺される中で、万が一をいかに考え危機感を持って作業を進めるかが非常に大切だと改めて実感。あとマルチサイトにする等、独自にバックアップを取得しておく重要性も。クラウドは比較的安価で楽だが、大切なデータをどのように守るか今一度考える必要がありそう。

 

原因1:脆弱性対策のための更新プログラムの不具合について

原因1:脆弱性対策のための更新プログラムの不具合
脆弱性対策のためのメンテナンスが必要となる都度、メンテナンスのための更新プログラムを作成しており、今回も更新プログラムを作成しています。

そのプログラムの記述において、ファイル削除コマンドを停止させるための記述漏れと、メンテナンスの対象となるサーバー群を指定するための記述漏れが発生していました。

削除系のコマンドが入る作業は作業ミス時の影響が大きいことから、最新の注意が必要である。そもそもファイル削除コマンドを停止させるために記述が必要となる(当該コマンドのコメントアウトとか?)時点でリスクが高い。通常そのような汎用手順にはしないはずなので、推測だが、過去の類似のプログラム(削除コマンドが入ったもの)を流用したとかなのかな。過去の類似プログラムの流用は生産性向上には非常に重要だが、安易にコピペしてしまうと非常に危険だ。またメンテナンスの対象となるサーバ群の指定漏れというのも同様で、指定しないと通常は動作しないはずなので、推測だがこれも過去の流用によるものなのかな。再発防止案としては、作業手順書にメンテナンス対象サーバを明記したり・削除系コマンドの有無のチェックボックス、あるいはどのプログラムから流用したかの記載等が考えられる。作業手順書と実際のプログラムに差異があったとかいう初歩的な問題だとすると、ソースコードから作業対象サーバと削除コマンド部分をgrepして、手順書に貼り付けるとかかな。全ての作業の全てのプログラムのソースコードレビューは困難だと思うので。

 

原因2:メンテナンス時の検証手順について

原因2:メンテナンス時の検証手順
メンテナンスに際しては、検証環境でまず動作確認を行うという手順が定められていましたが、プログラム実行後の動作確認を行う対象は、あくまでも当該メンテナンス対象サーバー群を確認すれば足りるとされていたため、検証環境下で対象サーバー以外に影響が及んだことの確認がないまま、動作確認上は問題なしと判定され本番環境での実施が行われました。

何を持って事前確認完了とするかという条件が曖昧だったのが問題だったのかな。中間報告を見る限り、作業対象サーバ郡にはプログラムが適応されていなかったという事だとすれば、推測だが、それで動作問題なし⇒確認終了としていたとか。もしそうなら、再発防止策としては、プログラム適応後の設定差異確認かな。
また、どこまで何をテストをするかは、生産性に非常に関ってくる課題なので必要以上にテストをすると価格に跳ね上がってしまうが、今回の再発防止としては、全ての作業で作業対象以外の正常性確認も実施という事か。正常性確認を効率的に行うツールを作成して、運用負荷を下げる等の工夫が必要となりそう。

 

原因3:メンテナンス仕様について

原因3:メンテナンス仕様
システムを含むデータのバックアップは毎朝6時に取得しております。

しかしながら、脆弱性対策のためのメンテナンスはバックアップをしてあるシステムについても実施しておかないと、メンテナンス実施後にハードウェア障害が発生してバックアップに切り替えた途端に脆弱性対策が講じられていないシステムに戻ってしまうことが過去に発生し、脆弱性対策がなされていないシステムが動き続けていたという反省に立ち、脆弱性対策のメンテナンスに関しては対象サーバー群とそのサーバー群のバックアップ領域に対して同時に更新プログラムを適用するという構造に修正して実施しました。

そのため、今回のメンテナンス実施において、対象サーバー群のデータ消失と同時にバックアップ領域のデータも消失したという事象に至っています。

再発防止としては、正常系で問題ないことが判明した○週間後に、バックアップ環境に適応するとかかな。

 

まとめ

3つの原因について再発防止を考えてみたが、どこのクラウドでも一歩間違えればこのような
障害に直面する可能性があるのではと考えてしまう。特にクラウドは安価なので、人件費も相当削減
しているだろうし。自分も自宅サーバをVPSに移行したが、バックアップをしっかり取得しようと改めて思った。バックアップ用に別会社のクラウドを契約、自社にバックアップ等の対策も重要だと思う。

 


自宅インフラをVPSへ移転予定。

自宅インフラをVPSに移転する事にほぼ決定。
今後は3つのVPSで運用する予定。6月中に移行完了したいところ。

自宅サーバよりサーバの性能も格段に上がるので、
レスポンスも早くなるはず。

○今後のサーバ構成(予定)
・VPS1:さくらのVPS メモリ2GBプランを利用予定。
・VPS2:お名前.comのVPS メモリ2GBプランを利用中。
・VPS3:お名前.comのVPS メモリ2GBプランを利用中。

さくらのVPS


Cloud Core VPSを試してみる

自宅サーバの運用には月額5400円ほど掛かっている。年間約6万5千円。
 (毎月インターネット回線(NTT & アサヒネット)と固定IPに約4400円、電気代に約1000円)

次の自宅サーバ候補としては、
ドスパラで4コア、8GBメモリ、SSD で5万円程度となりそう。
また2年ほどしたら買い替えたくなるから、上記のランニング年間6万5千円とあわせると、
年間9万円程度掛かる事となる。

以下の理由から、自宅サーバの運用を止めてVPSに移行するか考え中。

 ・お名前.comのVPSを使ってみて特に不自由を感じない。
 ・VPSは安い。
 ・いくつかのVPSを利用することで、障害発生時のリスクが分散される。
 ・いくつかのVPSを利用することで、SEO的に有利となる可能性。
   ・IPアドレス分散。
   ・ペナルティ発生時のリスク分散。
 ・家を引越したり、計画停電が発生した時、自宅サーバだと継続運用できない。
 ・自宅サーバを結構楽しんだので満足しつつある。
 ・娘たちが活発に動くようになったので、サーバ設置スペースを減らして部屋を有効活用したい。
 ・あと、いつか遊んでる最中にサーバの電源を抜かれそう。

一旦、さくらのVPSの無料申し込みをしたものの、
障害の多さに驚き、一旦キャンセル。
さくらの障害の情報 一覧

KDDIのCloud Core VPSを試してみる。
月額1000円以下で、メモリ2GBが特徴だ。