- - PR -
DCとメンバサーバについて
| 投稿者 | 投稿内容 | ||||
|---|---|---|---|---|---|
|
投稿日時: 2006-12-14 18:22
DCだけ冗長化してもほかのサーバーがダウンしたら、やっぱり支障があるでしょう。
認証が途切れなくできたとしても、アクセスするDBやFileサーバーがないのですから。 DC は 異なるハードウェアにそっくり復元するのが難しいこともあり、その意味で 複数のDC を建てる意味があると思います。 すなわち、ほかのサーバーにドメインの情報を複製するにはDCに昇格して、 レプリケーション するのが基本だからです。 （2003からはバックアップメディアから構成することも可能ですけど ----これはやったことがないです。） 同じハードウェア構成のサーバーがすんなり入手できるならよいでしょうが、 そうでないなら、唯一のDCがダウンしたらリストアするのは苦労するのでは ないでしょうか？ 2000では少なくともそうでした。 2003は簡単なのかなぁ。 2003でもドメイン情報の伝達はレプリケーションしか使ったことがないので 実際はわかりませんが。 そのため、ハードウェア依存がないように、DCをVMware上で実行しようかなんて こともまじめに検討したことがあります。 結局、それは見送りましたが、環境をまるごとバックアップできるのは結構 便利です。 実際、うちの一部のサーバーではVMwareを採用して、仮想ディスクごと バックアップしています。 一台でDCをまかなおうとするなら、RAID1 & 冗長化電源 定期的なバックアップ は不可欠でしょう。 イメージングによるリストアは機種がことなれば難しいのでは？ in place upgrade という方法はあるでしょうけど、DCには推奨されなかったような 記憶が・・・・ 以上釈迦に説法かもしれません。スレ汚しでした。 | ||||
|
投稿日時: 2006-12-14 19:02
imaging の restore 対象は機器が同じであることが基本だと思っています． なのでまるちねす様の認識は正しいと思います． が，「Server OS 向け」と銘打っている Hot imaging の製品では 定期的な Hot imaging を行うための機能を持っています． なので，Hardware の耐障害性を考慮するだけで良いと思います． というか，そこは前提だと思っていましたので 敢えて言及しませんでした，ゴメンナサイ． | ||||
|
投稿日時: 2006-12-14 23:13
kaz様
Tasuku様 まるちねす様 貴重なご意見ありがとう御座いました。 皆様のご意見を拝見していますと、自分の知識の足らなさや、他人に納得してもらえる 説明能力が足りないことを実感いたしました。 私の気持ちとしてはTasuku様が言われた、 Tasuku様の引用: -------------------------------------------------------------------------------- 「シングル構成をベースとしますが、 可能な限り冗長化は図るべきです。DB, FSの冗長化は多大なコストが かかりますが、DCの冗長化は、Windows Serverの標準機能で、 追加コストも発生しないので、是非、実施すべきと考えます」 -------------------------------------------------------------------------------- ということに尽きます。 DBやFSの冗長化は、例えばサーバーをもう1台づつ用意しDobleTakeや Co-StandbyServerなどのソフトウェアを利用して、 データをミラーリングし、障害時はフェイルオーバーさせるという方法が考えられます。 ただやはりコストが掛かりますので、DBやFSに関してはDATなどのバックアップで 障害対策として凌ぐことにしたいと思います。 上記を踏まえ説明すれば、納得させられそうです。 | ||||
|
投稿日時: 2006-12-15 08:41
おはようございます．
いまさらですが，
database はともかく，file server も DFS-R を利用することで 実は簡単に冗長化できます． backup の採取は別途必要としても，file server の停止に備えて DFS-R で複製しておいて， 一方の file server が障害で停止しても client や user からは ほとんど意識せずに切り替わります． その意味では，「Domain controller 兼 file server ×２ + database server」 の方が現実的に思えたりしてます． 以上，ご参考までに． | ||||
|
投稿日時: 2006-12-15 09:23
そうですね。簡単ついでにDNSサービスも二重化できますし。 # DFS-Rってマルチマスタ対応みたいですけど、 # 複数サーバ間でのロック制御までは対応していないんですよね？ # 正常時にクライアントの参照先が、複数サーバに割り振られたりすると # 排他ロックかからないのでまずいとか、大丈夫とか # そのあたりの情報ご存じないですか | ||||
|
投稿日時: 2006-12-15 17:17
DFS-Rを用いる場合、読み取り専用ならよいのでしょうが、書き込みを行う場合
考慮が必要だと思います。 共有（\\Server\share1 \\Server\Share2....）ごとに一人のユーザーしか 読み書きしない場合はそれぞれの共有をDFSでレプリケーションすればよく、 障害時には自動的に参照先サーバーが切り替わります。 しかし、複数のユーザーがひとつの共有内ファイルを読み書きする場合 あるユーザーはサーバーAを別のユーザーはサーバーBを参照などという具合に 食い違いが生じ、同じファイルを同時に異なるユーザーが編集する場合もありえます。 この際ロックがかかるかどうかはそのファイル（というかアプリケーション）次第 ではないでしょうか。 フォルダ内にロックファイルや作業ファイルを作成し、ロックするタイプは ロックファイルもレプリケートされるため、ロックされるであろうと思われますが、 単なるテキストファイルであれば書込み可能な状態でメモ帳で何重にも開けますし、 ということは保存のタイミングによっては変更結果が破棄され、別のユーザーの 編集結果に置き換えられてしまいます。 マルチマスタレプリケーションがかえってあだになるということです。 また、レプリケートは高速ですが、ごくわずかなタイムラグもあります。 ほぼ同時に複数のユーザー同一のファイルにアクセスするなんてことは、実際は まずないと思いますが、可能性としては排除できません。 このため、DFSでレプリカを作成してはいるけれど、参照先サーバーは一つになるように DFS紹介をメインのサーバーだけは有効、ほかは無効に設定し、障害時には 手動でDFS紹介を切り替える運用をしていました。 クライアントにはDFS紹介パスを一定時間キャッシュする機能がありますので、 キャッシュ時間を予め短く設定しておくか、ログオンしなおしてもらう等が必要です。 | ||||
|
投稿日時: 2006-12-15 17:39
まるちねすさん。
ありがとうございます。 なるほど、マルチマスタ対応の用途は、それなりに限られますね。 # 私も手動切り替えやってました 
| ||||
|
投稿日時: 2006-12-15 17:52
それはレプリケートしていなくても同じことではないでしょうか。 | ||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。