web-dev-qa-db-ja.com

インフラストラクチャに関するアドバイス-アプリケーションサーバーとネットワークサーバー

サーバーインフラストラクチャに関するアドバイスをお願いします。ネットワークインフラストラクチャ（MSエコシステム上に構築）をアップグレードし、これまでに2つのサーバー（ISAサーバー）は含まない）があります。1台のマシンがExchange、IIS、SQLなどのアプリケーションサービスを提供します。 。、他のマシンはネットワークサービス（ドメインコントローラー、DNS、DHCP、証明書などのネットワークサービス、ファイルサーバーでもあります。両方のサーバーはローカルサブネット192.168.xx上にあります）を提供します.

アプリケーションサーバーは、ISA特定のサービス（Exchangeサーバーなど）のサーバー）を介したサーバー公開ルールを介して外部から部分的にアクセスできました。このセットアップは中小規模の組織向けであるため、パフォーマンスは向上しません。問題。

今度は古いハードウェアをアップグレードします。現在のサーバーインフラストラクチャを確認することをお勧めします。必要なものは次のとおりです。

  • ドメインコントローラー
  • ネットワークサービス（DNS、DHCP、...）
  • Exchangeサーバー
  • SQLサーバー
  • IIS
  • TFS
  • ファイルサーバー
  • 更新サービス
  • 認証局
  • もっと何か、しかしほとんど重要ではない-

現在の2サーバーインフラストラクチャ（いくつかの公開サービスを備えたローカルネットワーク上のアプリケーションサーバー用に1台のマシン）と1台のマシンをDC、ネットワークとファイルサーバー、または1台のサーバー内のすべて（ただしExchangeとDCは、これまでのところ良くありません）、またはまったく異なるもの、またはアプリケーションサーバーをDMZに保持するなどです。ところで、DC =とファイルサーバーを1台のマシンに？

コメントとNextraztusとGolmaalの回答の後に追加：

仮想化に関しては、私は間違いなくHyper-Vを使用しています-私は完全にMSの人であり、WfW 3.1以降Windows用に開発しており、過去10年間は​​ASP.NETとWindowsカーネルIFSを使用しています（はい、2つのまったく異なる世界です） 、C＃および純粋なC）。

標準のセットアップは、システムおよび重要なデータ用のRAID 10、「通常の」データ用のRAID5です。

私はそれを声に出して認めることをほとんど恐れていますが、仮想化に関していくつかの個人的な問題があります-そしてこれを克服するのを手伝っていただければ幸いです:)私はそれを開発、特にWindowsのチェックビルドを備えたカーネルdevelopmnetに昼夜使用しています、私はAzureでの作業で使用しています（Azureが提供するほぼすべてのサービス、VM、Webサイト、Webロール、キャッシュなどを使用しています）が、ここでは、私はまだ持っていたいと「感じています」実際の物理サーバー。

これまでのところ、仮想化によって自由度が増します。必要な数のサーバーを使用でき、必要に応じて関心の分離を行うことができるため、イメージ全体をバックアップできます。

仮想化なしで、システムがSSDで実行される、これらのデータがRAID 10で実行される、これらのデータがRAID 5で実行される（必要に応じて、データボリュームに特に新しいディスクを追加できる）などを指定できます。質問、そしてあなたは本当に大丈夫だと思われますが、はるかに低いコストに加えて、すべてを仮想化することの本当の利点は何ですか？

編集2：

DCはそのままにしておく必要があることは理解できます（ただし、ネットワークサービス、特にDNSとDHCPでは問題ありません）-しかし、ほとんどすべてのサーバーの役割を別々のサーバーに公開する方がよいと思われるのはなぜですか？サーバー、SQLサーバーから別のサーバー、TFSから別のサーバー-私が考えることができる唯一の理由は負荷分散ですが、それが問題ではない場合は...？逆に、たとえばTFSはで実行することでメリットが得られることがわかります。 SQL Serverを備えたマシン、IISおよびExchange。

exchangedomain-controllerinfrastructurenetwork-topology
1
Robert Goldwein

クラスタリング/ HAが主な関心事ではない中小規模のセットアップでは（特に、複数のライセンスに伴う複雑さとコスト、より高い/エンタープライズバージョンの必要性などのため）、仮想化は魅力的なオプションに見えない場合があります。とはいえ、それはすべてユーザーの数と操作の重要性に依存します。 「この設定は中小規模の組織向けなので、パフォーマンスは問題ありません」とおっしゃっていたので、クラスタリングやHAなどは不要だと思います。結局、それはすべて許容可能なダウンタイムに依存します。

4台のVM（各Windows Server 2008ライセンスは1台の物理サーバーまたは2台の仮想サーバーのいずれかで実行できます））を実行する2台の物理サーバーを使用します。

Server 1:
   VM1:
      PDC
      Network Services
      File Server (Use DFS replication)
   VM2:
      SQL Server

Server 2:
   VM3:
      Secondary Domain Controller (global catalog; backup dhcp etc)
      File Server (Use DFS replication)
   VM4:
      Exchange

VM1またはVM3のいずれかで他のサービスを実行できます。清算ISAそして3番目の物理サーバー（ローエンド）に行きます;それにpfSenseをインストールし、ファイアウォール、アンチウイルス、キャッシング、VPNなどを備えた本格的なTMG/UMGにします。 dnsexit.comのようなcosが提供するメールリレー/バックアップサービスを利用してください。Exchangeのフェイルオーバーを実現するための最も安価な方法です（期待に応じて）。

このようにして、いくつかの最も重要なサービスのフェイルオーバーを備えたドメインができます。たとえば、PDCが何らかの理由で利用できない場合、VM3が引き継ぎ、クライアントは引き続きファイルにアクセスしてインターネットやメールを使用できます。

適切なバックアップ戦略を使用すると、SQL Server、Exchangeなどの他のサービスの許容可能な制限までダウンタイムを最小限に抑えることができる場合があります。RAID10、SSDなどを使用すると、構成の自由度が高まり、かなりのコストを追加することなく信頼性を向上させることができます。または複雑さ。

お役に立てば幸いです。

編集：

私はExchangeにはあまり詳しくありませんが、DMZに保持する必要があるのは、1つのサーバーであるため、独自のVMに保持するのが理にかなっているかもしれません。IIS-Exchangeと同じVM）。MSエコシステムとAzureに完全に夢中になっていることがわかります。ホストではなく社内のExchangeを使用する特別な理由はありますか？

DFS-それはうまく機能します。私の見解では、それはファイルサーバーのための貧弱な管理者のHAソリューションです。オフラインファイルを実行する必要がない場合は、DFSを試してみてください。

TFSはVM2に対応できます。私はそれを使用していませんが、それがリソースを大量に消費するアプリケーションであることを理解しています。 Hosted Exchangeを使用する場合は、VM4 forTFSを使用してください。

Exchange、SQL Server、TFSを同じ物理マシンで実行する/同じVM）は、私に言わせれば問題ありません。ただし、異なるVMで実行する場合、単一の物理/仮想マシン。私にとって最大の利点は、柔軟性とある程度の安心感です。たとえば、SQL Server管理者が何かをひどく台無しにして、そのマシンを再構築する必要がある場合でも、残りのサービスは中断されることなく機能します。 SQL Server VMをバックアップまたは最初から復元します。

2
Golmaal

@Sargeがコメントで述べたように、仮想化はユースケースに適したルートです。これらはすべてほとんど意見であり、実際に高レベルで見ていることに注意してください。

仮想化プラットフォームを選択してください。

最近はたくさんの選択肢がありますが、個人的には次のいずれかをお勧めします。

  • MicrosoftのHyperV
  • VMWare

それぞれに主要な賛否両論があり、主に価格とライセンス条項があります。ベンダーと協力して、売られ過ぎや売られ過ぎにならないようにします（そして監査のスペクターに失敗しないようにします）。

どの程度冗長にしたいかを決定します

繰り返しになりますが、これを使用する方法はいくつかありますが、最も明白な選択は、2台の強力なサーバーを取得し、決定した仮想化プラットフォームでそれらをクラスター化することです。これは明らかに非常にすぐに非常に高価になる可能性があります。

もう1つのオプションは、適切にバックアップされたSANにすべてを配置することです。1つの障害シナリオは、実際の仮想化を実行するサーバーを失う場合ですが、すべてが適切にコンテナー化されているためです。仮想マシンに移行すると、新しいアイアンが到着するとすぐに稼働状態に戻ることができます。

もちろん、他の失敗モードはSAN死にかけています。適切なバックアップを実行すれば、これは問題ではありません。もちろん、ここにも多くのオプションがあります。

適切なトレーニングを受ける

仮想化はまったく新しいbag-o-wormsであり、時には注意深い手を必要とします。ただし、何かをテストする必要があり、既存のインフラストラクチャを壊すリスクを冒したくない場合は、本当に便利です。どのテクノロジーを選択する場合でも、それを管理する方法について専門能力を開発してください。

デプロイ

物理サーバーを仮想マシンに変換するためのツールはたくさんあります。ほとんどのサービスは単一のサーバーにクラスター化されているため、週末にすべてをセットアップして移動することができない限り、ゲートから多くのメリットを得ることができません。

改善

すべてが元の場所に戻ったら、楽しむことができます。新しい環境では、物事を壊すのははるかに難しいでしょう。いくつかのボタンをクリックするだけで、新しいマシンや新しいアイデアをセットアップして破棄できることを知って、前進して繁栄してください。

アーキテクチャ

私はWindowsのスペシャリストではありませんが、anythingをDCディレクトリサービスは悪いジュジュです。また、ほとんどの場合、2つのDCで役割（RID、PDC、およびIM）を分割し、DCの1つに何かが発生した場合の明らかな冗長性が必要だと聞いています。

明らかに、ライセンスはこれらの種類のものの問題です。しかし実際には、負荷を監視し、職務を常に把握していれば、サーバーを2倍にするのに小さな環境は大した問題にはならないでしょう。また、最近のサーバー、STUPIDはリーズナブルな価格で強力です。

ゴッチャ

仮想化はリソースを共有します。これは明らかですが、言及する必要があります。このルートを使用する場合は、RAM、ハードドライブ、およびその他すべてを最前線に置く必要があります。すべてが共有されるようになるため、ハードウェアのサイズを小さくしないでください。何かがおかしくなり、ストレージのすべてのスペースを使い果たした場合、それを監視しないと、他のマシンが苦しむことになります。

DMZの質問-仮想化することを決定し、何かを公開することを決定した場合は、それらのマシンを別の仮想ネットワークに配置して、適切にセグメント化されたままにする必要があります。

これらの考えのいくつかが役立つことを願っています。

5
Sam