リソース(ディスク領域)をリニアに追加するには?

今回はリソースをリニアに追加する話の技術編です。

そもそも、システムにおけるリソースとは何か?について整理しておきます。いろいろな見方があると思いますが、一般的には
・CPU
・メモリ
・ディスク(ストレージ)
でしょう。若干観点は異なりますがネットワークもリソースです。人もリソースでしょ?なんて頓知の効いた突っ込みは今回は無しにしてください(笑)
ちなみに、オラクルで重視しているリソースはCPUです。性能という意味でのメモリやディスクについてはCPUに含まれていると思います。製品コンセプトとしてCPUコストがかなり重視されていて、オプティマイザーもそれを基準にするからです。とはいえ、メモリやディスクのサイジンク絡みでは痛い目をみますが。。。

さて、リソースのうち今回はディスク(ストレージ)の話を中心に展開します。話を絞らないと広大であるのと、今までディスクの話を中心にしてきたからです。気が向いたらCPU、メモリについて書きます(笑)

リニアにリソースを追加するには今までと考えをかなり変える必要があります。大抵のシステムでは1.5倍の見積もり(罪深きエンジニアたちを参照)の積み重ねのためリソース増強を必要としません。仮にリソース増強したシステムでも、「当初とかなりシステムの内容が変わってきた」とか、「かなり利用者が増えた」、などの変化があったことによる増強ではないでしょうか?こういうケースでは説明が成り立つので比較的大規模な改修もしやすいです。とはいえこういう状況だとプロジェクトは増強が急がれて修羅場になりますが(苦笑)

技術的な話に入る前に一番大切なことを記載します。それは、「ハードウェアレイヤーからアプリケーションレイヤーまでリソース増強が前提となるような設計にしなければならない」、ということです。「何を当たり前のことを言っているんだ!」と思う人もいると思いますが、実際にはハードウェアからアプリケーションまで理解して設計思想を合わせるのは結構大変です。そもそもそれだけの幅で話ができる人は少ないですからね。少なくともキーマンを中心に数人で思想を合わせる必要があります。
また、はじめから増強のポリシーを決めておく必要もあります。例えば、増強時にストレージ、OS、アプリケーションのどこまで止められるか、で話は大きく変わります。SLAの定義と言っていいでしょう。以降、その内容について記載していきます。

まず一番ハードウェアレイヤーに近いストレージからです。ハード構成のパターンとしては大きく分けてストレージ(共有ディスク)を使うパターンと、サーバー内部の内蔵ディスクを使うパターンがあります。個人的には内蔵ディスクはスロットも限られているためリニアにディスク追加が難しく、ストレージを用意してSANブートにするほうがいいと思います。内蔵ディスクにOSバイナリーを入れてデータ領域のみを共有することもできますが、できればOS領域もリニアに増強したいのと、例外のない設計にしなければ、1.5倍の見積もりが生まれる可能性が高いからです。そもそも、キチンとバイナリー(システムのための領域)とデータ領域を分けて設計するシステムが少ないというのもあります。
また、話は反れますが内蔵ディスクを使うと故障率も上がってあまりいいことはありませんし、増強もシェルフ単位でできるストレージを用意してしまったほうがやりやすくなります。

結果、ハードウェアレイヤーではストレージを採用すべきですが、ストレージを選定する上でもコンセプトは忘れないようにする必要があります。例えば、EMCのプールの概念です。「EMC CLARiiON Virtual provisioning」というホワイトペーパーがありますが参考になります。Googleで検索すれば出てきます。8ページあたりにプールの話が出てきます。これらを意識して、キチンと設計すればかなり効率的に運用できると思います。

続いてOSレイヤーです。ストレージレイヤーでリニアに容量を増加してもOSが対応できなければ意味がありません。Linuxもwindowsもストレージ(パーティション)のサイズは動的に変更できます。これらの機能がストレージの変更に対応できるかがポイントになります。LinuxでいうとLVMのような機能が該当します。ここでのポイントはOSの再起動の有無です。できることなら再起動しないほうが運用は容易になります。
また、OSの機能を使わずにサードパーティーのボリュームマネージャーを使うことも可能です。シマンテックのVxVMやオラクルのASMになります。これらをうまく使った場合、ストレージレイヤーの仮想化を吸収させることも可能です。注意したいのは、ボリュームマネージャーを使うとそのレイヤーでソフトウェアRAIDが組めるのでストレージの見直す可能性があります。イメージとしては安くて大量のストレージを並べるのか、そこそこ信頼性のあるストレージを使うのかという選択です。ただしソフトウェアRAIDはSANブートと相性がよくありませんので吟味が必要です。
よって上記内容を加味しつつ、OSがどのようにリソース増強に対応できるかがポイントになります。

最後にミドルウェア(アプリケーション)のレイヤーです。ミドルウェアではハードウェア製品に比べ論理と物理の設計を分割できる場合が多いのでリソース増強には比較的リニアに対応しやすいです。とはいえ、RAWデバイスを使って直接ストレージアクセスするような場合は考慮が必要になります。また、アプリケーションはシステムを停止せずにリソースを変更できるかどうかの最後の考慮ポイントになります。ポリシー次第ですが、システムを全く止めずにハードウェアレイヤーから動的にリソース増強できるようにすると大変なので、ある程度レイヤー単位で考えるのはありです。例えば、ストレージは一年単位で購入するのでその時はシステムを停止し、OSやミドルウェアの追加は停止しない、などの考え方です。
す。
その他、オラクルを使うと決まっていれば、少しずつ表領域を追加するということもできます。インスタンスを再起動させずに済むので楽ですが、OSからリソースを追加する場合(LVMを使わない場合など)にはOSを再起動する必要もあるので要件次第で考慮が必要です。また、表領域だけリニアにリソース増強できるようにしても、テーブルのイニシャル値で大きく取ってしまっては意味がないのでオラクルの内部のレイヤーでもポリシーや考え方を整理する必要があります。

さて、ストレージをリニアにリソース増強するのに忘れてはならない技術があります。それはサーバーの仮想化です。サーバーの仮想化はハードウェアレイヤーとOSレイヤーを分断する技術ですが、ストレージも同様です。そのため、サーバーの仮想化技術にはストレージプールのような概念があります。vmwareでいうとデータストアです。このプール領域をうまく使うと効率的に管理できます。

具体的にはゲストOSに対するデータストアの割り当てを変えてLVMで設定を変えるとOSとして使える領域を増やすことができます。また、認識させるデータストアを追加するとOSを再起動させる必要がありますが、新しくデバイスとして認識させられます。Linuxでいうと/dev/XXXが追加させるイメージです。注意したいのは追加の方法によってOSの見え方が違うところです。これらのことを意識して上位レイヤーのミドルウェアを設計すると増強や運用がやりやすくなります。

今回は範囲が広大になってしまったのでコマンド、操作レベルの具体的な内容は書けませんでしたが以上にしたいと思います。文章もブログで書く長さを超えていると思うので大変でした(笑)