例えば、メモリスペアリングは、予備メモリモジュールを用意して待機させておく仕組みだ。あるモジュールが動作を停止したり、エラーを報告したりすると、予備モジュールが起動され、元のモジュールのデータで再構築される。メモリミラーリングは、あるメモリモジュールの内容を別のモジュールに複製する。どちらの場合も、追加のメモリを購入して設置する必要がある。ただし、それらは特定のワークロード用にプロビジョニングされるわけではない。具体的なコストは、インストールするメモリの量によって決まる。

「単一障害点」とコストのバランス

　ネットワークポートが1つである場合、システムの単一障害点になり得る。あるいは少なくとも、ネットワークを多用する仮想マシン（VM）のボトルネックになる。米Broadcomのクアッドポート（4ポート）GbEカード「Broadcom 5719」のような、280ドルのマルチポートNICを追加すれば、サーバで利用できるNICポートが4つ増える。これらのポートのチーミング（複数のNICポートを1つのNICポートとして扱えるようにする技術）によって、帯域幅を集約したり、あるポートが停止した場合にフェイルオーバーを実現したりできる。個々のポートを特定のワークロード用にプロビジョニングし、ネットワークボトルネックを回避することも可能だ。

　サーバの電源が1台である場合も単一障害点になる可能性があり、サーバは通常、中断のないフェイルオーバーを実現するために冗長電源を使用している。

　冗長電源は“常時オン”のデバイスであり、常に動作して電力を消費する。そのため、システムの電力効率を低下させることにつながる。また、冗長電源は、電源故障時に電力供給を引き継ぐまでに、既に長時間にわたって稼働していることから、その信頼性には疑問の余地がある。一部の組織は、重要度の低いサーバでは単一の電源を選択してコストと消費電力を低く抑える一方、ミッションクリティカルシステムでは予備の電源を350ドルで追加している。

　レジリエンス（運用弾力性）を実現するソフトウェアのコストも計算に入れる必要がある。こうしたソフトウェアにはクラスタリングソフトウェア、ワークロードバランシングツール、VM（仮想マシン）複製ソフトウェアなどがある。こうしたツールのライセンスと展開コスト、機能はさまざまである。このため、自社のレジリエンス要件に最適なツールを選定しよう。ツールのコストは、ライセンスを少数に絞り込むことで軽減できる。こうしたツールではミッションクリティカルサーバだけを保護すればよいからだ。

スケールメリットを生かす

　購入金額が大きい方が、一般的にベンダーに対して強い交渉力を持てる。サーバを1台だけ買うよりも500台買う場合の方が、はるかに譲歩を引き出しやすい。このことが技術更新サイクルの背景にある。設備投資が多額になるものの、通常は大量の機器を一気に買い替える方が、少しずつ買っていくよりも経済的だ。

　大量購入を行う場合、ボリュームディスカウントが適用される前のもともとの単価を把握しておく必要がある。その金額が、取引の価値評価や、競合ベンダーの提案との比較を行うための唯一の基準になる。できれば、サーバベンダーと直接取引するのが望ましい。VAR（付加価値再販業者）は、ハードウェアにマージンを乗せて販売するからだ。

　大量購入による交渉力を生かして、ソフトウェアのライセンス、サービス、保守の契約延長にもつなげたい。1年から3年へ、あるいは3年から5年へのサービス契約の延長は、企業にとって大きな節約になり、売り手にとってもそのコストは比較的小さい。これは交渉事であり、ほとんど何でも交渉次第であることを頭に入れておこう。

　売り手がインストールサポートや古いシステムの撤去について料金を請求する場合、サーバ購入とセットでどちらか（または両方）に関して交渉することが可能だ。無料でインストールと構成、プロビジョニングを行ってもらえば、時間の節約になる。時間はお金だ。また、サーバベンダーは一般的に、顧客の使用済みマシンを中古市場や廃品市場で販売する。これを踏まえ、購入と引き換えに既存システムを無料で撤去してもらえるよう交渉しよう。

　交渉がまとまったら、必ず正式な購入注文書か契約書を作成する。こうした書類が、買い手と売り手の間での拘束力のある全ての合意内容を示すものになるからだ。電話やさらには電子メールによる交渉で取り決められた事項があっても、正式な売買契約書に明記されていなければ、それらは無効となる。署名による契約締結は法務部門に担当してもらうようにする。

　エンタープライズサーバの購入では、よく見落とされるファクターがある。例えば、アプリケーションの相互運用性や、管理プラットフォームのサポートなどがそうだ。こうしたファクターは、ベンダーやサーバの機種を変更するときに問題になる恐れがある。既存のシステム管理プラットフォームが新しいサーバに対応していないかもしれない。その場合、詳細な管理情報が得られず、自動化が中断され、アプリケーションで予期せぬパフォーマンス問題が発生する危険がある。

　どのような技術更新サイクルでも、購入前に重要なアプリケーションの動作を検証する上では、厳しいストレステストとともに概念実証テストが重要な役割を担っている。