RAIDとは複数のHDDを用いて1つのHDDとして扱うことで、
ディスクの故障に対する耐性やデータ書き込み処理の高速化を
実現する技術であることは、前回の記事で少しだけ触れました。

前回はRAIDを提供するハードウェアとソフトウェアについて、
記しましたので、
今回は、RAID構成を話す予定でしたが、
その前に、RAIDにより提供される機能について話を行いたいと思います。

RAIDにより提供される機能は
大きく二つあります。

1つはHDD故障への耐性です。
通常、HDDが1台しかないと、
HDDの故障とデータの喪失はほぼ同意ですが、
HDDを複数配置して冗長化することにより
もしHDDの一つに故障が発生した場合でも、
残りのHDDに故障が無ければ、データの損失は無く、
故障したHDDを正常なHDDに交換することで、
故障したHDDに配置されていたデータを復元できます。
またRAIDコントローラによっては、
サーバやNASの電源を入れたまま、HDDを交換できる機能である
ホットスワップを有する物もあります。
また、これとは別に、予備のHDDを機器に接続しておいて、
故障が発生した際には、予備のHDDを使用する機能を
ホットスペアといいます。

もう一つはデータ処理の高速化です。
ファイルが一つあったとして、
これがHDDに保存される際には、
いくつものブロックに分けられます。

ファイルA = ブロックA1 + ブロックA2 + ブロックA3 ＋ …… + ブロックn

これをブロック単位でHDDに保存・読込を行います。
1つのHDDに対して、ブロックA1～ブロックnまで配置した場合と
2つのHDDに対して、ブロックA1～ブロックnまでを分散させて配置した場合、
HDD1台当たりのブロック数は後者の方が少ないため、
データへのアクセス速度などが上がります。

次回はRAIDレベルなど話をしたいと思います。

以前、ESXiのインストールを行った際にハマった記事に
少しだけ書いたRAIDを今回のテーマにしたいと思います。

RAIDとは、複数のHDDを1つのHDDのように認識・表示させる技術です。
なぜ、この様な事を行うのか。
これは、システムにハードディスクが一つしかない場合、
ハードディスクが壊れたとき、対応が取れない、というのが、大きな要因です。
また、この他にも、一つのデータを複数のハードディスクに分けて書き込むことが
可能になるため、データ書き込みの高速化も実現可能になります。

主に、企業でサーバやストレージに利用されている技術でしたが、
HDDレコーダーやBlu-rayレコーダーの普及に合わせて、
NAS（ネットワークハードディスクの一種）が普及したため、
消費者向けとしても関連のある技術となりました。

さて、RAIDにはハードウェアRAIDとソフトウェアRAIDがあります。
ハードウェアRAIDはRAIDコントローラや
マザーボード上のチップにコントローラが含まれているオンボードRAIDなどがあります。
（オンボードRAIDはRAIDコントローラに比べて、機能制限があることが多く、
ソフトウェアRAIDとして扱われることもあります）
こちらはRAID管理を行うための処理を機器やチップが行うため、
ソフトウェアRAIDに比べて、高速です。
また、ハードウェアRAIDにより構成されたディスクは、Windowsの様なOS側から
ディスクを確認すると1つのディスクとしか表示されません。
例えば、HDDが2台搭載されているサーバが有るとします。
(ディスクAとディスクBとします)
この2台のHDDでRAID構成をすると、仮想的にHDDができます。
（ディスクV1とします）
Windows側からはディスクV1のみがHDDとして認識されます。

これに対して、ソフトウェアRAIDはWindowsの様なOSの機能の1つとして、
RAIDが提供されます。
こちらはRAID管理を行うための処理をOSが担当しますので、
他の稼働プロセスと同様に処理されるため、
ハードウェアRAIDに比べると、ディスクの書き込みは低速となります。
OSの機能としてRAID構成を行うため、
HDDはサーバに搭載されている分が表示されます。
上述の例でいえば、ディスクAとディスクBが認識されており、
ソフトウェアRAIDとして構成することで、ディスクV1として認識されますが、
ディスクの管理機能で確認すると、表示上はディスクAとディスクBと表示されます。

今回は、RAIDについて、提供する機器・機能からの話をしましたが、
次回は、RAID構成について、もう少し詳しく記述します。

今回はC#とASP.NETの話です。

Webページで登録画面を作成していて、
必須入力項目への入力確認に、
RequiredFieldValidatorクラスを使用しました。

バリデーションを行うコントロール名とエラーメッセージをセットすれば、
指定したコントロールに対して、入力がなされたかクライアント側で確認することができます。

ただし、今回作成している画面が少し厄介で、
ドロップダウンリストの選択した値によって、
必須入力が変更される、という仕様を盛り込んでいました。

そこで、SelectedIndexChangedイベントを使用し、
選択した値が変更した時に、RequiredFieldValidatorの設定を切り替えるようにしました。

初めは、選択した値ごとに、RequiredFieldValidatorのEnabledプロパティに
TrueやFalseをセットしていたのですが、
これだと、Falseのセット漏れが出たりするなぁ、と思い、
一度、ページ内の全てのRequiredFieldValidatorにFalseをセットした後、
必要なコントロールのみ、Trueを設定しようと考えました。

では、どの様にして、全てのRequiredFieldValidatorコントロールに
Falseをセットするのか、考えました。
ASP.NETの各コントロールが継承するクラスにControlクラスが有ります。
このControlクラスには、FindControlというメソッドが有りますが、
これはコントロールのIDでしか探せません。
それに加え、コントロールは階層配置されており、
FindControlメソッドでは、呼出元のコントロールが有する子コントロールが
対象となります。

そこで、下記の記事を参考にし、再帰的に呼び出されるメソッドを作成しました。
下記記事では、IDを使用していますが、今回はクラス名で検索する様にします。

方法: ID を使用してサーバー コントロールにアクセスする

http://msdn.microsoft.com/ja-jp/library/y81z8326(v=vs.100).aspx

上記記事内に記載されているメソッドからの変更点は、
１．引数のIDをクラス名に変更する。
２．コントロールとIDの照合を
コントロールのクラス名と１で変更した引数と照合する。

    public static Control FindControlRecursive(Control rootControl,
                                               string findControlClassName)
    {
        if (rootControl.GetType().Name == findControlClassName)
        {
            return rootControl;
        }

        foreach (System.Web.UI.Control searchControl in rootControl.Controls)
        {
            Control controlToReturn =
                FindControlRecursive(searchControl, findControlClassName);
            if (controlToReturn != null)
            {
                return controlToReturn;
            }
        }
        return null;
    }

このメソッドを実行することで、rootControl以下のコントロールから
検索対象とするクラス名を有するコントロールを取得できます。
後は、取得したコントロールのparentプロパティで、
直近の親コントロールを取得し、
親コントロールが持つ子コントロールをforeachで回し、
GetType().Name で同一のクラス名を持つコントロールのEnabledプロパティに
FALSEをセットすれば、Webページ内のRequiredFieldValidatorオブジェクトを
無効化できます。

ちなみに、呼出元は以下の様なコードを書きました。

    // ページ内のコントロールを対象とする。
    foreach (Control pageChild in Page.Controls)
    {
        // RequiredFieldValidatorクラスのコントロールを検索する。
        var findControl = FindControlRecursive(pageChild,
                                  "RequiredFieldValidator");

        if (findControl != null)
        {
            // 検索結果のコントロールの親コントロールを取得する。
            var parentControl = findControl.Parent;

            // 親コントロールの全てのvalidatorを無効にする。
            foreach (Control childControl in parentControl.Controls)
            {
                If (childControl.GetType().Name == "RequiredFieldValidator")
                {
                    RequiredFieldValidator requiredFieldControl =
                        (RequiredFieldValidator)childControl;
                    requiredFieldControl.Enabled = false;
                }
            }
        }
    }

サーバサイドで同一のクラスを持つコントロールに
一律の操作をする際に、使えると思います。

前回の続きです。

開発用のサーバにVMWare ESXiをインストールさせようとしている社員Ｏ氏。
RAIDの設定に四苦八苦しながらも、なんとかRAIDの設定は行えましたが、
まだまだ続きます。
というより、むしろここからがインストール作業です。

空の環境にインストールする際、特に難しいことはありません。（ないはずでした……）
１．ブート時にCDからインストールするか確認
２．規約事項の確認
３．インストールするハードディスクの確認
この順に確認が出ますので、
それぞれ入力を行います。

が、今回は楽にはいきませんでした。
今回の問題は３のハードディスクでした。

どのハードディスクにインストールするか確認する画面が表示されるのですが、
RAID構成したはずのディスクなのに、物理ハードディスクが二つ見える……

RAID構成が崩れた？　と思い、サーバを再起動させて確認する。
RAID構成は崩れていない。
とりあえず、そのままインストールを続行してみました。
その後の起動で確認すると、RAID構成は崩れたままです。

どういうことだ？　と考える。
まさか、オンボードRAID（＝ソフトウェアRAID）だとよろしくないのか、と思い、
ESXi5.5のインストールマニュアルを探す。
やはりというか、下調べが足りてないというか、
ESXi5.5ではソフトウェアRAIDはサポートしていない、という一文が。
そうですか、マザーボードに載っているタイプのRAIDもアウトですか……

しかし、原因さえわかってしまえば、回避できます。
ということで、BIOSを立ち上げ、HDDモードをAHCIへ。
その後、正常にインストールは完了しました。

正直、ここまで苦戦することになるとは考えてもいませんでした。
ESXiも（バージョンが異なるとはいえ）インストールしたことはありましたから。

それでは、今回の教訓です。
インストールする環境はきちんとマニュアルに目を通しましょう。

前回といい、今回といい、事前に情報さえ持っておけば、
回避できる状況に対し、前にやったことあるし、大丈夫大丈夫と
安易に考えたために、結果として、大火傷してしまいました。

事前準備ってホント重要ですね……