Case Study
社内システム基盤の増強（公共性の高い施設 様）
メモリ価格が10倍に高騰した年。「入れ替える」のではなく「戻して、足す」ことで、止められない仮想基盤に次の数年分の余裕をつくりました。
「いちばん安い増設は、増設しないことです。使われていない16GBと10TBをまず回収して、それでも足りない分だけを買い足しました。」
—— 門王
本事例は、お客様およびベンダー様との守秘の観点から、業種・所在地・システム名・製品名を伏せて記載しています。
掲載しているのは、同種の課題をお持ちの方の判断材料になる範囲の技術的な内容に限っています。
解決した課題
直面していた状況
- 仮想基盤上のゲストOSが30台規模まで増え、メモリ・ディスクの空きが逼迫
- 社内システムのためバックアップの世代数が多く、容量の増加ペースは今後さらに加速する見込み
- 増設計画の立案から実施まで、1年以上が経過
技術・運用の壁
- 計画時からサーバ用メモリが10倍近くまで高騰し、当初の予算に収まらない
- 止められない基盤のため、停止できるのは計画停電に合わせた年に一度の枠のみ
- 既存ディスクの入れ替えはデータ移行と長時間停止を伴い、その枠に収まらない
門王の処方箋
限られた予算と、年に一度しかない停止機会。その二つの制約の中で、まず「何を買わずに済ませるか」を決めることから始めました。既存の資源を実測に合わせて戻し、それでも足りない分だけを、価格の動きを見ながら買い足しています。
設計・運用のポイント
- 買う前に、眠っている資源を回収：日に100アクセスに満たないゲストにメモリ16GB・ストレージ10TBが割り当てられている例が残っていました。実測に合わせてメモリ4GB・ストレージ300GBまで圧縮し、増設なしでも当面稼働できる状態まで戻しています。
- メモリは最低限、ストレージは先を見て：高騰していたメモリは128GBの増設に絞り、価格が落ち着いているストレージ側は将来の伸びを織り込んで、既存の3倍規模の容量を確保しました。
- 入れ替えではなく、増設という選択：既存ディスクの換装は容量単価では有利に見えても、データ移行と長時間停止がついてきます。既存領域を残したままSANを増設することで、当日の作業を接続と設定に限定しました。
- 重要度でバックアップを分離：世代保持が目的の重要度の低いバックアップは、別途導入したNASへ移設。Synologyの8ベイモデルに16TB×8本を搭載し、拡張ユニット併用で最大18ベイ・432TBまで伸ばせる構成を選定しています。
- 停止枠の同時活用：リソース見直しのために基盤を止める必要があったため、その停電枠に合わせてハイパーバイザのメンテナンスと増設作業もまとめて実施しました。
技術解説：なぜ「入れ替え」ではなく「増設」だったのか
—— 計画から実施まで1年以上かかっています。
増設そのものは1年以上前から決まっていました。ただ、この種の基盤は好きなときに止められません。止められるのは計画停電に合わせた年に一度のタイミングだけで、そこに向けて準備を積み上げていくことになります。結果として、計画と実施の間が1年以上空きました。
—— その間に、メモリ価格が動いたと。
サーバ用メモリは計画当時から10倍近くまで上がっていました。同じ構成で買えば、当然ながら予算に収まりません。そこで増設は128GBに絞り、不足分は「買う」のではなく「取り戻す」ことで埋める方針に切り替えました。
—— 「取り戻す」というのは。
稼働中のゲストOSの割り当てを、1台ずつ実測と突き合わせて見直しました。日に100アクセスもないシステムに、メモリ16GB・ストレージ10TBが割り当てられている——といったケースが残っていたんです。業務上の重要度と、必要なリソース量は別の話です。メモリ4GB・ストレージ300GBまで圧縮したところ、増設をしなくてもしばらく持つ状態まで戻りました。今回はその見直しのために基盤を止める必要があったので、同じ停止枠で増設も済ませておこう、という順番です。
—— ストレージを入れ替えずに増設した理由は。
既存ディスクの換装は、容量あたりの単価だけを見れば有利に見えます。ただ、そこにはデータ移行と、それに伴う長時間の停止がついてきます。停止枠が年に一度しかない環境では、その時間とリスクのほうが高くつきます。既存のSANを残したまま増設する形にすれば、当日の作業は接続と設定だけです。バックアップの世代数が多く、今後さらに増える見込みだったので、増設分は既存容量の3倍規模を確保しました。
—— バックアップを別のNASに分けたのはなぜですか。
すべてのバックアップに同じ性能と信頼性が必要なわけではありません。世代を残しておくこと自体が目的で、復旧速度をそこまで求めない領域は、比較的安価なNASで十分です。導入したのはSynologyの8ベイモデルで、16TBを8本。8ベイで足りているうちから、拡張ユニットを足せば最大18ベイ・432TBまで伸ばせるモデルを選んでいます。次に容量が足りなくなったとき、また筐体ごと入れ替える判断を迫られないようにするためです。
—— 当日の作業はどう進みましたか。
サーバの設置とゲストOSの設定プロファイルは事前に用意していたため、切り替え自体は3時間ほどで完了しました。残りは動作確認に10時間ほどをかけています。前倒しできる作業はすべて停電の前に終わらせておく——限られた停止枠を使い切らないための、基本的な段取りです。
この案件について
今回のご相談は、導入されていたシステムが、門王代表が長年Linux・OSSの開発に携わる中でメンテナとしても関わってきた領域のものであったことから、ベンダー様経由でお声がけいただいたものです。
門王は25年以上にわたるLinux・OSS開発の実績を持ち、Webサイトや業務システムの制作だけでなく、Linuxサーバや仮想基盤の保守・増設もお引き受けしています。既存環境の設計に手を入れる場面こそ、外から一度見直す価値があります。お気軽にご相談ください。