サーバー統合：サーバースプロールに対処するための6つのステップ

システム管理者やインフラ管理者であれば、サーバースプロールを経験したことがあるでしょう。過去数年にわたり、仮想化、Docker、クラウドサービスなどの技術がこの課題に対処する手助けをしてきました。それでも、ある時点で「本当にこれらのすべてのサーバーが必要ですか？少なくともいくつかはオフにできるはずでは？」と言う人が出てくるでしょう。この記事はサーバースプロールを防ぐことを目的としているのではなく、一旦発生した後にどのように対処するかに焦点を当てています。データセンター（またはVMコンソール）に入って、オフにできるものと残す必要があるものを特定するのは簡単そうに思えますが、実際にはそうではありません。

1. サーバー統合を通じてどの問題に対処しようとしていますか？

ほとんどのプロジェクトと同様に、サーバー統合プロジェクトの範囲は適切に管理されないと制御を失うことがあります。これは、組織内のサーバーの数を減らすために採用できるいくつかの戦略があるためです。したがって、最初に解決しようとしている問題を知り、その後に統合戦略を決定することが重要です。サーバー統合の取り組みを開始する一般的な理由は次のとおりです：

• 複数のサーバーの管理負担がスタッフの管理能力を超えている
• 2つ以上の組織が統合され、同じ機能を果たすサーバーが多すぎる
• 新しいデータセンターへの移転を準備するため
• サーバー運用コストを削減するため
• 組織のリスクエクスポージャーを削減するため
• ハードウェアライフサイクルの交換に備えるため
• アプリケーションとその基盤となるインフラストラクチャが廃止の準備が整っている。

2. すべてのサーバー（物理および仮想）のインベントリを取る

これは当たり前のことのように思えますが、統合プロジェクトの一環として追加のサーバーが発見されたプロジェクトに参加したことがあります。特定の機能に対して現在の状態とサーバーの数を理解することは非常に重要であり、それにより望ましい最終状態のビジョンを作成できます。以下は、サーバーインベントリの各レコードがどのように見えるかのサンプルです：

最初にこのインベントリを必要以上に複雑にしないことが重要です。技術チームは外部IPアドレス、ファイアウォールルール、RAM、ストレージ、およびCPUタイプなどを知る必要がありますが、この時点では基本的なことを知っているだけで十分です。基本的なインベントリが整ったら、カテゴリ分け（統合の目的のため）に進むことができます。

3. サーバーの機能をカテゴリ分けする

これは比較的簡単な項目の一つです。すべてのシステム管理者は、何らかの方法でサーバーをグループ化します。サーバー統合の取り組みに必要なのは、すべてのプロジェクト担当者が従い理解できる一貫したグループ化システムです。以下は、グループ化システム内での2つのグループ化方法を使用した簡略化されたリストです。グループ化システム内に複数の方法を持つことで、異なる方法で統合の機会を評価することが可能になります。

機能によるグループ化

機能によってサーバーをグループ化すると、類似のワークロードに基づいて統合の機会を評価できます。一度に1つのグループを見ていくことで、どのサーバーを統合できるかを評価するのが容易になります。この方法では、次のような質問をします：

1. このグループ内のすべてのサーバーは%80に近い利用率ですか？そうでない場合、どのワークロードを統合できますか？
2. このグループ内に過剰利用されているサーバーはありますか？
3. 機能内のサーバーを分離しておくビジネス上またはアプリケーション上の理由はありますか？そうでない場合、統合するのが理にかなっていますか？

セキュリティプロファイルによるグループ化

セキュリティプロファイルによってサーバーをグループ化すると、リスク管理を統合の取り組みに組み込むことができます。また、サーバーのワークロードを統合することでセキュリティ問題を引き起こさないようにするためのチェックとバランスを提供します。セキュリティプロファイルに基づいてサーバーをグループ化することで、次のような質問をすることができます：

1. セキュリティレベル内のすべてのサーバーは一緒に保つべきですか？
2. 異なるセキュリティレベルの「サーバー1」と「サーバー2」を統合するのは理にかなっていますか？
3. 最もプライベートなサーバーを分離し、これらのサーバーのセキュリティコントロールを強化することで、リスク管理コストを削減できますか？

4. クラウドオプションを検討する

クラウドへの移行は、全体的な統合活動に大きな影響を与える可能性があります。クラウドに移行する利点を活用するために再設計できるワークロードが多数あります。ただし、サーバー統合に焦点を当てており、クラウドに初めて踏み出そうとしている場合、コラボレーションスイートとストレージは、あまり開発時間を投資することなく始めるのに最適な出発点です。Office 365やGSuite（およびその他のサービス）は、メールやファイルサーバーの必要性を排除することで、組織内のサーバーの数を大幅に削減できます。クラウドに移行する優れたオプションには、これまで購入したクライアントサーバーアプリケーションがあります。ほとんどのソフトウェアプロバイダーは、クラウドオプションとオンプレミス版からクラウド版に移行するためのプロフェッショナルサービスを提供しています。社内で開発されたアプリケーションをクラウドに移行する機会があれば、素晴らしいことです。ただし、これらの取り組みは独立したプロジェクトとして扱うことを強くお勧めします。詳細は後で説明します。

5. オンプレミスのすべてを仮想化する

私は2000年代初頭から仮想化の取り組みに参加しています。データベースやドメインコントローラーを仮想化することは悪い慣行と見なされていた時期もありました。しかし、現代の仮想化ソリューションはこれらの古い論争を無意味にします。適切に設計された仮想化ソリューションを使用すると、サーバーの大規模な崩壊を恐れることなく、オンプレミスでホストしているほぼすべてのサーバーを仮想化できます。仮想マシンに十分なリソースを提供すれば、物理サーバーを保持する理由はもはやありません（もちろんハイパーバイザーのホストを除いて）。完全に仮想化された環境は、サーバー統合の取り組みにもる柔軟性をもたらします。

6. 統合計画を作成する

あなたが達成しようとしていることを知り、サーバーをグループ化し、クラウドオプションを評価し、可能な限り多くを仮想化したら、統合計画を書く準備が整います。計画の書き方は、組織ごとに異なります。しかし、少なくともあなたの統合計画には次のセクションが含まれているべきです：

1. 背景 / あなたが解決しようとしている問題
2. 現在のサーバー数 / コスト
3. 将来のサーバー数 / コスト
4. サーバーの統合移動のタイムライン
5. 廃止されるサーバー
6. プロジェクトの終了時に成功がどのように見えるかに関するセクション。
7. 上級IT管理者からの承認

注意すべき点

サーバー統合の取り組みがアプリケーションの再設計を含む場合、これは大きな赤信号です。アプリケーションの再設計が悪いわけではなく、組織が効率を見つける機会がある場合にアプリケーションを再設計するべきではないということではありません。サーバー統合プロジェクトの一環として、アプリケーションの再設計を行うことは悪いアイデアだと思います。なぜなら、ほとんどのアプリケーションの再設計には、新しい再設計されたアプリケーションをホストするための新しいサーバーの立ち上げが必要だからです。大規模な環境では、これには開発、テスト、運用サーバーが含まれます。その後、アプリケーション開発者は新しいシステムを設計し、必要なすべてのテストを実施し、運用を新しいシステムに移行する必要があります。次に、古い環境を廃止し、データの処理方法を決定しなければなりません。アプリケーションの再設計に関する変数が多すぎるため、サーバー統合プロジェクトがそれに依存することはできません。アプリケーションの再設計がサーバー統合の一部である場合、サーバーの数が減るのではなく増えることさえあります。もう一度強調したいのは、アプリケーションの再設計は新しい技術を活用したり、消費されるリソースを減らす機会があるときに通常は良いアイデアであるということです。しかし、アプリケーションの再設計プロジェクトは独立して存在し、サーバー統合からは別のプロジェクトであるべきです。

これらの投稿は私自身の見解であり、必ずしもBMCの立場、戦略、または意見を代表するものではありません。